From xen-devel-bounces@lists.xenproject.org Wed Apr 01 00:28:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 00:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJREe-0007qR-18; Wed, 01 Apr 2020 00:28:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJREc-0007qM-9H
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 00:27:58 +0000
X-Inumbo-ID: a2a300b4-73af-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a2a300b4-73af-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 00:27:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ev8MWHVBObLDhZn6nEqWqmhVHAvsP8A4hmeOZueiCmc=; b=csgTaNEfoDT84ksFpt2HAZdl3
 Q5Uz5MpYEMEiJ6ZTnuQRzwtOi8UAVzRH+o57Ra+5/f86FcXxqe30F139m7Y8mL3zI6C1NtAeVPYCi
 YsDeERQ2gx+4fUnAYd6FSkvmKtvqCwJcO0YQbG9rMA4CWWDrt1SUZHmCSghF6BZ2n8AfQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJREb-000358-3J; Wed, 01 Apr 2020 00:27:57 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJREa-0002FN-QR; Wed, 01 Apr 2020 00:27:56 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJREa-0004vz-P0; Wed, 01 Apr 2020 00:27:56 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149242-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149242: all pass - PUSHED
X-Osstest-Versions-This: ovmf=8c944c938359cffda4c889259b3d2aba69e9ee7b
X-Osstest-Versions-That: ovmf=3000c2963db319d055f474c394b062af910bbb2f
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 00:27:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 8c944c938359cffda4c889259b3d2aba69e9ee7b
baseline version:
 ovmf                 3000c2963db319d055f474c394b062af910bbb2f

Last test of basis   149207  2020-03-30 12:11:22 Z    1 days
Testing same since   149242  2020-03-31 09:59:29 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Fan, ZhijuX <zhijux.fan@intel.com>
  Laszlo Ersek <lersek@redhat.com>
  Liran Alon <liran.alon@oracle.com>
  Maciej Rabeda <maciej.rabeda@linux.intel.com>
  Pete Batard <pete@akeo.ie>
  Zhiju.Fan <zhijux.fan@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   3000c2963d..8c944c9383  8c944c938359cffda4c889259b3d2aba69e9ee7b -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 00:57:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 00:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJRh8-0001ob-8y; Wed, 01 Apr 2020 00:57:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=wqBo=5R=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jJRh7-0001oW-QS
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 00:57:25 +0000
X-Inumbo-ID: c02b8422-73b3-11ea-b58d-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c02b8422-73b3-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 00:57:25 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 5F76F20842;
 Wed,  1 Apr 2020 00:57:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1585702644;
 bh=vbWTEqDv5fC5IeCUzoVOK86jHDSpaBBrd2Gc3H8oz2Y=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=jkJmyL/kl8+SS1X31LEWEZ6odIUYT9bmKLwq5VVlgmqAMftfWdRdzmp+P6G+NtQ9I
 29HR/iXsAcLMq3eD9NdScZIHgnAqScqqgUyVLeAhnscWs1jxllNPGAdIXWEgyaLnhn
 Pm1BS9XHJdBZthwSGqlkbQ8s3DkcBQefVYOG10ck=
Date: Tue, 31 Mar 2020 17:57:23 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
In-Reply-To: <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
Message-ID: <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Peng Fan <peng.fan@nxp.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Wei Xu <xuwei5@hisilicon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, 30 Mar 2020, Julien Grall wrote:
> Hi Stefano,
> 
> On 30/03/2020 17:35, Stefano Stabellini wrote:
> > On Sat, 28 Mar 2020, Julien Grall wrote:
> > > qHi Stefano,
> > > 
> > > On 27/03/2020 02:34, Stefano Stabellini wrote:
> > > > This is a simple implementation of GICD_ICACTIVER / GICD_ISACTIVER
> > > > reads. It doesn't take into account the latest state of interrupts on
> > > > other vCPUs. Only the current vCPU is up-to-date. A full solution is
> > > > not possible because it would require synchronization among all vCPUs,
> > > > which would be very expensive in terms or latency.
> > > 
> > > Your sentence suggests you have number showing that correctly emulating
> > > the
> > > registers would be too slow. Mind sharing them?
> > 
> > No, I don't have any numbers. Would you prefer a different wording or a
> > better explanation? I also realized there is a typo in there (or/of).
> Let me start with I think correctness is more important than speed.
> So I would have expected your commit message to contain some fact why
> synchronization is going to be slow and why this is a problem.
> 
> To give you a concrete example, the implementation of set/way instructions are
> really slow (it could take a few seconds depending on the setup). However,
> this was fine because not implementing them correctly would have a greater
> impact on the guest (corruption) and they are not used often.
> 
> I don't think the performance in our case will be in same order magnitude. It
> is most likely to be in the range of milliseconds (if not less) which I think
> is acceptable for emulation (particularly for the vGIC) and the current uses.

Writing on the mailing list some of our discussions today.

Correctness is not just in terms of compliance to a specification but it
is also about not breaking guests. Introducing latency in the range of
milliseconds, or hundreds of microseconds, would break any latency
sensitive workloads. We don't have numbers so we don't know for certain
the effect that your suggestion would have.

It would be interesting to have those numbers, and I'll add to my TODO
list to run the experiments you suggested, but I'll put it on the
back-burner (from a Xilinx perspective it is low priority as no
customers are affected.)


> So lets take a step back and look how we could implement ISACTIVER/ICACTIVER
> correctly.
> 
> The only thing we need is a snapshot of the interrupts state a given point. I
> originally thought it would be necessary to use domain_pause() which is quite
> heavy, but I think we only need the vCPU to enter in Xen and sync the states
> of the LRs.
> 
> Roughly the code would look like (This is not optimized):
> 
>     for_each_vcpu(d, v)
>     {
>        if ( v->is_running )
>          smp_call_function(do_nothing(), v->cpu);
>     }
> 
>     /* Read the state */
> 
> A few remarks:
>    * The function do_nothing() is basically a NOP.
>    * I am suggesting to use smp_call_function() rather
> smp_send_event_check_cpu() is because we need to know when the vCPU has
> synchronized the LRs. As the function do_nothing() will be call afterwards,
> then we know the the snapshot of the LRs has been done
>    * It would be possible to everything in one vCPU.
>    * We can possibly optimize it for the SGIs/PPIs case
> 
> This is still not perfect, but I don't think the performance would be that
> bad.


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 02:31:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 02:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJT9Z-00039f-HA; Wed, 01 Apr 2020 02:30:53 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJT9X-00039a-LX
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 02:30:51 +0000
X-Inumbo-ID: cd7e9efe-73c0-11ea-ba66-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cd7e9efe-73c0-11ea-ba66-12813bfff9fa;
 Wed, 01 Apr 2020 02:30:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=aBfFMDNLgWv4gSpWP2E+KlyL5wp6mQ5B9V+L6x26vMc=; b=Mu333YyHaFLV9RKD6JcaDX9ZK
 jX4Vk9S6tTW8l+ORPv7UuXmexX/tIYOSH0c86va8Iy7jQ34mloZi5udI6P0tl2PQoS1r8/Z+ey5LY
 2dbEn1TUNR5Z1pcLHyOiwqBVNAl+agnapdsCsA0MMA1ui3o8YvaZ9cWY1QsWSKvxSgikI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJT9W-0006Qr-F4; Wed, 01 Apr 2020 02:30:50 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJT9W-0002E8-5f; Wed, 01 Apr 2020 02:30:50 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJT9W-0005cg-50; Wed, 01 Apr 2020 02:30:50 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149236-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149236: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-amd:guest-start/debian.repeat:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=83019e81d1002650947c3e992508cdab7b89e3f5
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 02:30:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-freebsd10-i386 11 guest-start            fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-freebsd10-amd64 11 guest-start           fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-dom0pvh-xl-amd 20 guest-start/debian.repeat   fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                83019e81d1002650947c3e992508cdab7b89e3f5
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  106 days
Failing since        144880  2019-12-16 20:07:08 Z  106 days  315 attempts
Testing same since   149236  2020-03-31 04:53:48 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Hangjing <lihangjing@baidu.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 55296 lines long.)


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 03:52:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 03:52:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJUQQ-0001HN-KW; Wed, 01 Apr 2020 03:52:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJUQP-0001HI-3y
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 03:52:21 +0000
X-Inumbo-ID: 2b8d4cec-73cc-11ea-ba75-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2b8d4cec-73cc-11ea-ba75-12813bfff9fa;
 Wed, 01 Apr 2020 03:52:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=X1Vt7qqpXU7q5ZcFyIaJg+m2MErMFjBQCoUUDCTY1ro=; b=yC5yMh+TTlDPh2V32TU3qPcfs
 ntFvHAGiuldHF3ZcN2f3SGWW26zMIhCew0be9fq8Ehf0rU8/Y9tGhLfEEy4kicPlLLjFQf4WRaLrs
 PWDgJmMKdOc7dGnyUw+/6CKlb6m2cfL9hP91X0MOafTv04h5VxzfyCJVeETWL/MdJUEcE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJUQG-0007xw-LO; Wed, 01 Apr 2020 03:52:12 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJUQG-000614-Bl; Wed, 01 Apr 2020 03:52:12 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJUQG-0002R5-Az; Wed, 01 Apr 2020 03:52:12 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149238-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149238: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:allowable
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
X-Osstest-Versions-That: linux=736706bee3298208343a76096370e4f6a5c55915
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 03:52:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10   fail REGR. vs. 133580

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 15 guest-saverestore  fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 133580
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 133580
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 133580
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 133580
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 133580
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 133580
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 133580
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08
baseline version:
 linux                736706bee3298208343a76096370e4f6a5c55915

Last test of basis   133580  2019-03-04 19:53:09 Z  393 days
Failing since        133605  2019-03-05 20:03:14 Z  392 days  241 attempts
Testing same since   149238  2020-03-31 07:17:53 Z    0 days    1 attempts

------------------------------------------------------------
6534 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   736706bee329..458ef2a25e0c  458ef2a25e0cbdc216012aa2b9cf549d64133b08 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 06:34:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 06:34:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJWxJ-0005yA-PJ; Wed, 01 Apr 2020 06:34:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJWxI-0005y5-2L
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 06:34:28 +0000
X-Inumbo-ID: d50fa880-73e2-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d50fa880-73e2-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 06:34:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9844EABBD;
 Wed,  1 Apr 2020 06:34:25 +0000 (UTC)
Subject: Re: [PATCH v8 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200320184240.41769-1-roger.pau@citrix.com>
 <20200320184240.41769-2-roger.pau@citrix.com>
 <ee1587a0-7a6c-a1f9-860e-ea93a05d8462@suse.com>
 <20200331164500.GT28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3a8ee855-7659-2a97-bab0-d0e43b171adf@suse.com>
Date: Wed, 1 Apr 2020 08:34:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331164500.GT28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 18:45, Roger Pau Monné wrote:
> On Tue, Mar 31, 2020 at 05:40:59PM +0200, Jan Beulich wrote:
>> On 20.03.2020 19:42, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
>>>              p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
>>>                                    p2m_ram_rw, p2m_ram_logdirty);
>>>  
>>> -            flush_tlb_mask(d->dirty_cpumask);
>>> +            flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
>>>  
>>>              memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
>>>          }
>>> @@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
>>>           * to be read-only, or via hardware-assisted log-dirty.
>>>           */
>>>          p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
>>> -        flush_tlb_mask(d->dirty_cpumask);
>>> +        flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
>>>      }
>>>      return 0;
>>>  }
>>> @@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
>>>       * be read-only, or via hardware-assisted log-dirty.
>>>       */
>>>      p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
>>> -    flush_tlb_mask(d->dirty_cpumask);
>>> +    flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
>>>  }
>>>  
>>>  /************************************************/
>>> @@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
>>>  
>>>      safe_write_pte(p, new);
>>>      if ( old_flags & _PAGE_PRESENT )
>>> -        flush_tlb_mask(d->dirty_cpumask);
>>> +        flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
>>
>> For all four - why FLUSH_TLB? Doesn't the flushing here solely care
>> about guest translations?
> 
> Not on AMD, at least to my understanding, the AMD SDM states:
> 
> "If a hypervisor modifies a nested page table by decreasing permission
> levels, clearing present bits, or changing address translations and
> intends to return to the same ASID, it should use either TLB command
> 011b or 001b."
> 
> It's in section 15.16.1.
> 
> This to my understanding implies that on AMD hardware modifications to
> the NPT require an ASID flush. I assume that on AMD ASIDs also cache
> combined translations, guest linear -> host physical.

I guess I don't follow - I asked about FLUSH_TLB. I agree there needs
to be FLUSH_HVM_ASID_CORE here.

>>> --- a/xen/arch/x86/mm/hap/nested_hap.c
>>> +++ b/xen/arch/x86/mm/hap/nested_hap.c
>>> @@ -84,7 +84,7 @@ nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
>>>      safe_write_pte(p, new);
>>>  
>>>      if (old_flags & _PAGE_PRESENT)
>>> -        flush_tlb_mask(p2m->dirty_cpumask);
>>> +        flush_mask(p2m->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
>>
>> Same here then I guess.
>>
>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>> @@ -896,7 +896,8 @@ static void p2m_pt_change_entry_type_global(struct p2m_domain *p2m,
>>>      unmap_domain_page(tab);
>>>  
>>>      if ( changed )
>>> -         flush_tlb_mask(p2m->domain->dirty_cpumask);
>>> +         flush_mask(p2m->domain->dirty_cpumask,
>>> +                    FLUSH_TLB | FLUSH_HVM_ASID_CORE);
>>
>> Given that this code is used in shadow mode as well, perhaps
>> better to keep it here. Albeit maybe FLUSH_TLB could be dependent
>> upon !hap_enabled()?
>>
>>> --- a/xen/arch/x86/mm/paging.c
>>> +++ b/xen/arch/x86/mm/paging.c
>>> @@ -613,7 +613,7 @@ void paging_log_dirty_range(struct domain *d,
>>>  
>>>      p2m_unlock(p2m);
>>>  
>>> -    flush_tlb_mask(d->dirty_cpumask);
>>> +    flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
>>
>> Same here?
> 
> I'm fine with doing further refinements, but I would like to be on the
> conservative side and keep such flushes.

Well, if hap.c had FLUSH_TLB dropped, for consistency it should
become conditional here, imo.

>>> @@ -993,7 +993,7 @@ static void shadow_blow_tables(struct domain *d)
>>>                                 pagetable_get_mfn(v->arch.shadow_table[i]), 0);
>>>  
>>>      /* Make sure everyone sees the unshadowings */
>>> -    flush_tlb_mask(d->dirty_cpumask);
>>> +    flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
>>
>> Taking this as example, wouldn't it be more consistent overall if
>> paths not being HVM-only would specify FLUSH_HVM_ASID_CORE only
>> for HVM domains?
> 
> I think there's indeed room for improvement here, as it's likely
> possible to drop some of the ASID/VPID flushes. Given that previous to
> this patch we would flush ASIDs on every TLB flush I think the current
> approach is safe, and as said above further improvements can be done
> afterwards.

There's no safety implication from my suggestion. Needless
FLUSH_HVM_ASID_CORE for non-HVM will result in a call to
hvm_flush_guest_tlbs(), with it then causing the generation
to be incremented without there being any vCPU to consume
this, as there's not going to be a VM entry without a prior
context switch on the specific CPU.

>> Also, seeing the large number of conversions, perhaps have another
>> wrapper, e.g. flush_tlb_mask_hvm(), at least for the cases where
>> both flags get specified unconditionally?
> 
> That's fine for me, if you agree with the proposed naming
> (flush_tlb_mask_hvm) I'm happy to introduce the helper.

Well, I couldn't (and still can't) think of a better (yet not
overly long) name, yet I'm also not fully happy with it.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 06:46:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 06:46:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJX8W-0006qm-SQ; Wed, 01 Apr 2020 06:46:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJX8U-0006qh-Ko
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 06:46:02 +0000
X-Inumbo-ID: 70fc2272-73e4-11ea-ba7a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 70fc2272-73e4-11ea-ba7a-12813bfff9fa;
 Wed, 01 Apr 2020 06:45:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=g927PF4bX7+pTfzu7QgVBC3q7zxxI5CzKdiZ1u+D29A=; b=oWuyUs8gqucJFmnWrLeKuyoca
 hBGTE9CZS2V1M3t/KJj549rPIBbWvWfQtB/5gbepxACFNsQOqCyUkGrno5zF3IVBsKF6CDNq7lDnm
 3SxIQI9H6lFoQ0hVE2BYzMTgh+HjuRtWnEoH28ZIkweC7lJMGZ6IJ+C3cOfZ+lTyKNeAY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJX8P-0003JX-3f; Wed, 01 Apr 2020 06:45:57 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJX8O-0005ik-RR; Wed, 01 Apr 2020 06:45:56 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJX8O-0008Dg-QL; Wed, 01 Apr 2020 06:45:56 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149244-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149244: regressions - FAIL
X-Osstest-Failures: linux-5.4:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:regression
 linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:heisenbug
 linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 linux-5.4:test-amd64-amd64-dom0pvh-xl-intel:guest-start:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-dom0pvh-xl-amd:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: linux=462afcd6e7ea94a7027a96a3bb12d0140b0b4216
X-Osstest-Versions-That: linux=122179cb7d648a6f36b20dd6bf34f953cb384c30
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 06:45:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10     fail pass in 149200
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149200

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 12 guest-start        fail baseline untested
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-dom0pvh-xl-amd  2 hosts-allocate        starved in 149200 n/a

version targeted for testing:
 linux                462afcd6e7ea94a7027a96a3bb12d0140b0b4216
baseline version:
 linux                122179cb7d648a6f36b20dd6bf34f953cb384c30

Last test of basis   146121  2020-01-15 17:42:04 Z   76 days
Failing since        146178  2020-01-17 02:59:07 Z   75 days  101 attempts
Testing same since   149052  2020-03-26 11:07:11 Z    5 days    6 attempts

------------------------------------------------------------
1428 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 06:48:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 06:48:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJXAr-00070g-GA; Wed, 01 Apr 2020 06:48:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJXAq-00070a-Dl
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 06:48:28 +0000
X-Inumbo-ID: c9220a7b-73e4-11ea-ba7a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c9220a7b-73e4-11ea-ba7a-12813bfff9fa;
 Wed, 01 Apr 2020 06:48:27 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 65B45AAC7;
 Wed,  1 Apr 2020 06:48:26 +0000 (UTC)
Subject: Re: [PATCH 1/8] xen/guest_access: Harden copy_to_guest_offset to
 prevent const dest operand
To: Julien Grall <julien@xen.org>
References: <20200330192157.1335-1-julien@xen.org>
 <20200330192157.1335-2-julien@xen.org>
 <33a36f0e-5adb-b8af-445c-bab765c84589@suse.com>
 <b5f7037a-5253-b5f2-d5b7-1b90d19021c2@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <2ce142db-dd2d-4ef2-ee18-9d67d491e400@suse.com>
Date: Wed, 1 Apr 2020 08:48:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <b5f7037a-5253-b5f2-d5b7-1b90d19021c2@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 dfaggioli@suse.com, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 21:13, Julien Grall wrote:
> On 31/03/2020 08:26, Jan Beulich wrote:
>> On 30.03.2020 21:21, Julien Grall wrote:
>>> From: Julien Grall <jgrall@amazon.com>
>>>
>>> At the moment, copy_to_guest_offset() will allow the hypervisor to copy
>>> data to guest handle marked const.
>>>
>>> Thankfully, no users of the helper will do that. Rather than hoping this
>>> can be caught during review, harden copy_to_guest_offset() so the build
>>> will fail if such users are introduced.
>>
>> But there are other implications you break:
>>
>>> --- a/xen/include/asm-arm/guest_access.h
>>> +++ b/xen/include/asm-arm/guest_access.h
>>> @@ -126,7 +126,7 @@ int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
>>>     #define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
>>>       const typeof(*(ptr)) *_s = (ptr);                   \
>>> -    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>>> +    typeof(*((hnd).p)) *_d = (hnd).p;                   \
>>>       ((void)((hnd).p == (ptr)));                         \
>>>       __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
>>
>> Until this change, it is "ptr" which all sizes get derived from,
>> i.e. it is the internally used type rather than the handle type
>> which controls this. I'm sure we use this in a few places, to
>> copy to e.g. a handle derived from "void". Compatibility of types
>> (disallowing other than void) is checked by the comparison on the
>> line immediately after the line you change. Yes "_d+(off)" right
>> above here then changes its result. I consider it pretty likely
>> you'd notice this issue once you go beyond just build testing.
> 
> I missed that part. To be honest, it feels wrong to me to have
> "off" != 0 and use a void type for the handle. Would it make
> sense to forbid it?

I don't think so - the idea (aiui) has always been for the Xen
internal object's type to control what gets copied, and hence a
void handle is to be fine for both copy-in and copy-out.

> As a side node, I have updated __copy_to_guest_offset() but
> forgot to update copy_to_guest_offset(). I will look to apply
> the modifications we agree on both side.

Ah, sure.

>> To address this, I guess we need to find an expression along the
>> lines of that comparison, which does not cause any code to be
>> generated, but which verifies the properties we care about. The
>> line you change should be left alone, from all I can tell right
>> now.
> 
> I am not aware of any way before C11 to check if a variable is
> const or not. If we wanted to keep allow void type the handle
> then a possible approach would be:
> 
> #define copy_to_guest_offset(hnd, off, ptr, nr) ({              \
>     const typeof(*(ptr)) *_s = (ptr);                           \
>     typeof(*((hnd).p)) *_d = (hnd).p;                           \
>     size_t mul = (sizeof(*(hnd).p) > 1) ? 1 : sizeof (*_s);     \
>     ((void)((hnd).p == (ptr)));                                 \
>     raw_copy_to_guest(_d + (off) * mul, _s, sizeof(*_s)*(nr));  \
> })
> 
> I don't particularly like it but I could not come up with better so far.

Not very nice indeed, and the conditional expression - at the
first glance being the wrong way round - seems outright
confusing to me. I'll try to find time to experiment some with
this as well, since unless we can find a reasonably neat
solution here, I'm inclined to suggest to leave this as it is
now.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 07:15:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 07:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJXbB-00013s-Uc; Wed, 01 Apr 2020 07:15:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=eFaW=5R=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jJXb9-00013l-Qa
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 07:15:39 +0000
X-Inumbo-ID: 959c081e-73e8-11ea-ba7a-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 959c081e-73e8-11ea-ba7a-12813bfff9fa;
 Wed, 01 Apr 2020 07:15:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585725337;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=zt92ZdPXTcR7HccIGIAe+ToHiK4kl3KB8SiE4gJUiFc=;
 b=V/ddrNy3nLAaWnyZgpuL5iQgSglGa7QiKJEXokgqzSHyqzSBqj4xEe7v
 YCG5Ij2lxNbQVM29NNjRb8sWVUYTEQGsm7xLN6vp7iGFgWodX/Iidw6WL
 F0U3Y6+BR3u1e8Mm6fsHRatiLgtp+hFtTQcnI7syCVfY8n/4Sqfu64xR8 Q=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: MUh0DlED/iE4do8H8sSJ876xUnssoN2n2b/4cb4nn+sZgE9+pMvBzjoCdWo7X2LLCADnkyd7Zz
 +hGyhLpJ6ImPPkZ8VQPirjZ7R5932PdPnQYS+JBft3x+I0MirJs4i6yVZ0E+M9HXRaZt4EPXho
 lSLVavOgBFJ70jirukGo0VE2zj3H4/mWYjo56uSy5s2AH8B5P8Olf470lEMydLqqUhLSISjECY
 4Q8v9ZXU5QHofuyov65ysne3tkjV4xFG6TUM3bJPFyXV2ZvkbPtJPDgA1ATJBVahnx81pHGOrJ
 3UQ=
X-SBRS: 2.7
X-MesageID: 15638724
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,330,1580792400"; d="scan'208";a="15638724"
Date: Wed, 1 Apr 2020 09:15:26 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v8 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200401071526.GU28601@Air-de-Roger>
References: <20200320184240.41769-1-roger.pau@citrix.com>
 <20200320184240.41769-2-roger.pau@citrix.com>
 <ee1587a0-7a6c-a1f9-860e-ea93a05d8462@suse.com>
 <20200331164500.GT28601@Air-de-Roger>
 <3a8ee855-7659-2a97-bab0-d0e43b171adf@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3a8ee855-7659-2a97-bab0-d0e43b171adf@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 01, 2020 at 08:34:23AM +0200, Jan Beulich wrote:
> On 31.03.2020 18:45, Roger Pau Monné wrote:
> > On Tue, Mar 31, 2020 at 05:40:59PM +0200, Jan Beulich wrote:
> >> On 20.03.2020 19:42, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/mm/hap/hap.c
> >>> +++ b/xen/arch/x86/mm/hap/hap.c
> >>> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
> >>>              p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
> >>>                                    p2m_ram_rw, p2m_ram_logdirty);
> >>>  
> >>> -            flush_tlb_mask(d->dirty_cpumask);
> >>> +            flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
> >>>  
> >>>              memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
> >>>          }
> >>> @@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
> >>>           * to be read-only, or via hardware-assisted log-dirty.
> >>>           */
> >>>          p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> >>> -        flush_tlb_mask(d->dirty_cpumask);
> >>> +        flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
> >>>      }
> >>>      return 0;
> >>>  }
> >>> @@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
> >>>       * be read-only, or via hardware-assisted log-dirty.
> >>>       */
> >>>      p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> >>> -    flush_tlb_mask(d->dirty_cpumask);
> >>> +    flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
> >>>  }
> >>>  
> >>>  /************************************************/
> >>> @@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
> >>>  
> >>>      safe_write_pte(p, new);
> >>>      if ( old_flags & _PAGE_PRESENT )
> >>> -        flush_tlb_mask(d->dirty_cpumask);
> >>> +        flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
> >>
> >> For all four - why FLUSH_TLB? Doesn't the flushing here solely care
> >> about guest translations?
> > 
> > Not on AMD, at least to my understanding, the AMD SDM states:
> > 
> > "If a hypervisor modifies a nested page table by decreasing permission
> > levels, clearing present bits, or changing address translations and
> > intends to return to the same ASID, it should use either TLB command
> > 011b or 001b."
> > 
> > It's in section 15.16.1.
> > 
> > This to my understanding implies that on AMD hardware modifications to
> > the NPT require an ASID flush. I assume that on AMD ASIDs also cache
> > combined translations, guest linear -> host physical.
> 
> I guess I don't follow - I asked about FLUSH_TLB. I agree there needs
> to be FLUSH_HVM_ASID_CORE here.

I clearly misread your comment, I'm really sorry.

The main point of this patch was to remove the ASID flush from some of
the flush TLB callers, not to remove TLB flushes. I understand this
was all intertwined together, and now that it's possible to split
those there are a lot of callers that can be further refined. I think
such further improvements should be done in a separate patch, as it's
IMO a tricky area that can trigger very subtle bugs.

> >>> --- a/xen/arch/x86/mm/hap/nested_hap.c
> >>> +++ b/xen/arch/x86/mm/hap/nested_hap.c
> >>> @@ -84,7 +84,7 @@ nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
> >>>      safe_write_pte(p, new);
> >>>  
> >>>      if (old_flags & _PAGE_PRESENT)
> >>> -        flush_tlb_mask(p2m->dirty_cpumask);
> >>> +        flush_mask(p2m->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
> >>
> >> Same here then I guess.
> >>
> >>> --- a/xen/arch/x86/mm/p2m-pt.c
> >>> +++ b/xen/arch/x86/mm/p2m-pt.c
> >>> @@ -896,7 +896,8 @@ static void p2m_pt_change_entry_type_global(struct p2m_domain *p2m,
> >>>      unmap_domain_page(tab);
> >>>  
> >>>      if ( changed )
> >>> -         flush_tlb_mask(p2m->domain->dirty_cpumask);
> >>> +         flush_mask(p2m->domain->dirty_cpumask,
> >>> +                    FLUSH_TLB | FLUSH_HVM_ASID_CORE);
> >>
> >> Given that this code is used in shadow mode as well, perhaps
> >> better to keep it here. Albeit maybe FLUSH_TLB could be dependent
> >> upon !hap_enabled()?
> >>
> >>> --- a/xen/arch/x86/mm/paging.c
> >>> +++ b/xen/arch/x86/mm/paging.c
> >>> @@ -613,7 +613,7 @@ void paging_log_dirty_range(struct domain *d,
> >>>  
> >>>      p2m_unlock(p2m);
> >>>  
> >>> -    flush_tlb_mask(d->dirty_cpumask);
> >>> +    flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
> >>
> >> Same here?
> > 
> > I'm fine with doing further refinements, but I would like to be on the
> > conservative side and keep such flushes.
> 
> Well, if hap.c had FLUSH_TLB dropped, for consistency it should
> become conditional here, imo.
> 
> >>> @@ -993,7 +993,7 @@ static void shadow_blow_tables(struct domain *d)
> >>>                                 pagetable_get_mfn(v->arch.shadow_table[i]), 0);
> >>>  
> >>>      /* Make sure everyone sees the unshadowings */
> >>> -    flush_tlb_mask(d->dirty_cpumask);
> >>> +    flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
> >>
> >> Taking this as example, wouldn't it be more consistent overall if
> >> paths not being HVM-only would specify FLUSH_HVM_ASID_CORE only
> >> for HVM domains?

I could introduce something specific for shadow:

sh_flush_tlb_mask(d, m) \
    flush_mask(m, FLUSH_TLB | (is_hvm_domain(d) ? FLUSH_HVM_ASID_CORE : 0))

And likely a similar macro for hap, that uses hap_enabled.

> > I think there's indeed room for improvement here, as it's likely
> > possible to drop some of the ASID/VPID flushes. Given that previous to
> > this patch we would flush ASIDs on every TLB flush I think the current
> > approach is safe, and as said above further improvements can be done
> > afterwards.
> 
> There's no safety implication from my suggestion. Needless
> FLUSH_HVM_ASID_CORE for non-HVM will result in a call to
> hvm_flush_guest_tlbs(), with it then causing the generation
> to be incremented without there being any vCPU to consume
> this, as there's not going to be a VM entry without a prior
> context switch on the specific CPU.

As said above, I would rather do this in smaller steps, as I already
had plenty of fun with this change, but anyway. I think what I
proposed is correct and already an improvement from the current
status.

Will prepare a new version with your suggestions.

> >> Also, seeing the large number of conversions, perhaps have another
> >> wrapper, e.g. flush_tlb_mask_hvm(), at least for the cases where
> >> both flags get specified unconditionally?
> > 
> > That's fine for me, if you agree with the proposed naming
> > (flush_tlb_mask_hvm) I'm happy to introduce the helper.
> 
> Well, I couldn't (and still can't) think of a better (yet not
> overly long) name, yet I'm also not fully happy with it.

I'm going to use the proposed name unless someone comes up with a
better suggestion that has consensus.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 07:39:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 07:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJXy0-0002kq-VU; Wed, 01 Apr 2020 07:39:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=eFaW=5R=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jJXy0-0002kl-7B
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 07:39:16 +0000
X-Inumbo-ID: e23dfd1e-73eb-11ea-ba7a-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e23dfd1e-73eb-11ea-ba7a-12813bfff9fa;
 Wed, 01 Apr 2020 07:39:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585726755;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=B2kL9Gj6O9Eb6I+ziPIH8mw/albicz9XnjAC/g5MjjE=;
 b=hXxqNuCATN7kbvFt3maw1Zc8Xwt7sPHmlK1xirwf/YHI0WR8Z995pLJh
 xmVj/Ba+ZM1zfsLAR8VeEQbtp6rpAqLP/pQDSjIL6XgS4OeQcNfTChBUh
 A2wpEsPA/D/+0R8rEyfkOlsjTvk0nP9DKLzaEcKRh8gmzmD80Ly+sa4CN k=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: YZog0+0x+O0uPFrHyHbCLFoH4WV+bDm6NPGv5uZTci+X+gjWKrIcOHQ7hRRUMbbtcpyc1DXg6k
 QtfByZ6rV5RjZfLBey4fIGeQh4CioUG+o/HhfeOZ8Smo4TGnKsrze5LkZKPH9epx/UujmtWeR8
 E/hx4B/FnbDpyApCKEuIvgk9V6Y0wGNYhdmmqhNUawE+2fQf+iJF/tdzNWuoP7Uwp1aC8HmEra
 dRMKO5r0Ic+2txnfo2iRucXBdQtAj1uCZBRTrENXIX+geAywF7ocwSfnGu+TC+3Y16T8+tZXOa
 j9o=
X-SBRS: 2.7
X-MesageID: 14994316
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,330,1580792400"; d="scan'208";a="14994316"
Date: Wed, 1 Apr 2020 09:39:05 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: osstest service owner <osstest-admin@xenproject.org>
Subject: Re: [linux-5.4 test] 149244: regressions - FAIL
Message-ID: <20200401073905.GV28601@Air-de-Roger>
References: <osstest-149244-mainreport@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <osstest-149244-mainreport@xen.org>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 01, 2020 at 06:45:56AM +0000, osstest service owner wrote:
> flight 149244 linux-5.4 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/149244/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121

I cannot see anything obviously wrong on the logs, so I'm trying to
get hold on one of the elbling boxes in order to repro.

Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 07:58:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 07:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJYGn-0004NL-Md; Wed, 01 Apr 2020 07:58:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJYGm-0004NE-Ad
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 07:58:40 +0000
X-Inumbo-ID: 986740bc-73ee-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 986740bc-73ee-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 07:58:39 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D4037AFBE;
 Wed,  1 Apr 2020 07:58:37 +0000 (UTC)
Subject: Re: [PATCH v8 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200320184240.41769-1-roger.pau@citrix.com>
 <20200320184240.41769-2-roger.pau@citrix.com>
 <ee1587a0-7a6c-a1f9-860e-ea93a05d8462@suse.com>
 <20200331164500.GT28601@Air-de-Roger>
 <3a8ee855-7659-2a97-bab0-d0e43b171adf@suse.com>
 <20200401071526.GU28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6e07af26-b5fb-3a24-4eb7-bc6e409694cc@suse.com>
Date: Wed, 1 Apr 2020 09:58:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200401071526.GU28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 01.04.2020 09:15, Roger Pau Monné wrote:
> On Wed, Apr 01, 2020 at 08:34:23AM +0200, Jan Beulich wrote:
>> On 31.03.2020 18:45, Roger Pau Monné wrote:
>>> On Tue, Mar 31, 2020 at 05:40:59PM +0200, Jan Beulich wrote:
>>>> On 20.03.2020 19:42, Roger Pau Monne wrote:
>>>>> @@ -993,7 +993,7 @@ static void shadow_blow_tables(struct domain *d)
>>>>>                                 pagetable_get_mfn(v->arch.shadow_table[i]), 0);
>>>>>  
>>>>>      /* Make sure everyone sees the unshadowings */
>>>>> -    flush_tlb_mask(d->dirty_cpumask);
>>>>> +    flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_HVM_ASID_CORE);
>>>>
>>>> Taking this as example, wouldn't it be more consistent overall if
>>>> paths not being HVM-only would specify FLUSH_HVM_ASID_CORE only
>>>> for HVM domains?
> 
> I could introduce something specific for shadow:
> 
> sh_flush_tlb_mask(d, m) \
>     flush_mask(m, FLUSH_TLB | (is_hvm_domain(d) ? FLUSH_HVM_ASID_CORE : 0))

This looks good.

> And likely a similar macro for hap, that uses hap_enabled.

And then there's no point to use it anywhere in hap.c, as that code
runs only when hap_enabled is true. Hence my suggestion to simply
drop FLUSH_TLB there (assuming by "similar" you meant making
FLUSH_TLB conditional there).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 08:06:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 08:06:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJYOT-0005jw-1z; Wed, 01 Apr 2020 08:06:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJYOR-0005jr-TC
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 08:06:35 +0000
X-Inumbo-ID: b334065e-73ef-11ea-ba7b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b334065e-73ef-11ea-ba7b-12813bfff9fa;
 Wed, 01 Apr 2020 08:06:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8447DB3A8;
 Wed,  1 Apr 2020 08:06:32 +0000 (UTC)
Subject: Re: [PATCH] x86/dom0: fix copy of low 1MB data for PVH
To: Roger Pau Monne <roger.pau@citrix.com>
References: <20200331163302.60617-1-roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <914293f7-65c1-5732-c2ce-9db22d2fe1ec@suse.com>
Date: Wed, 1 Apr 2020 10:06:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331163302.60617-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 18:33, Roger Pau Monne wrote:
> The orders of start and end are inverted in order to calculate the
> size of the copy operation.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 08:30:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 08:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJYli-000854-8M; Wed, 01 Apr 2020 08:30:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJYlh-00084z-2l
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 08:30:37 +0000
X-Inumbo-ID: 0f952b78-73f3-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0f952b78-73f3-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 08:30:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=W0SGaUpYB5rE1GPxdFDCD481TsxkiuXMZC7VUn6w8+k=; b=mKNvNpvjpJR/CLkq/LJFbXKPAj
 dmhj3qlIdDl1ieQCVG1a+cHLsCWFLMtqhkxD48tF92lSCNifGJ99daoKFrf7VYqn+1P2Oipwde1xw
 BJRcjWtuur4tgCWsAhAWKKk1q6uVVXEh6zIVkNKSF3UqgbpUAUfn45cL6LM+konEp2IM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJYla-0005pM-4Y; Wed, 01 Apr 2020 08:30:30 +0000
Received: from cpc91226-cmbg18-2-0-cust12.5-4.cable.virginm.net ([82.0.29.13]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJYlZ-0006K5-UR; Wed, 01 Apr 2020 08:30:30 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
Date: Wed, 1 Apr 2020 09:30:27 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Peng Fan <peng.fan@nxp.com>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Wei Xu <xuwei5@hisilicon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 01/04/2020 01:57, Stefano Stabellini wrote:
> On Mon, 30 Mar 2020, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 30/03/2020 17:35, Stefano Stabellini wrote:
>>> On Sat, 28 Mar 2020, Julien Grall wrote:
>>>> qHi Stefano,
>>>>
>>>> On 27/03/2020 02:34, Stefano Stabellini wrote:
>>>>> This is a simple implementation of GICD_ICACTIVER / GICD_ISACTIVER
>>>>> reads. It doesn't take into account the latest state of interrupts on
>>>>> other vCPUs. Only the current vCPU is up-to-date. A full solution is
>>>>> not possible because it would require synchronization among all vCPUs,
>>>>> which would be very expensive in terms or latency.
>>>>
>>>> Your sentence suggests you have number showing that correctly emulating
>>>> the
>>>> registers would be too slow. Mind sharing them?
>>>
>>> No, I don't have any numbers. Would you prefer a different wording or a
>>> better explanation? I also realized there is a typo in there (or/of).
>> Let me start with I think correctness is more important than speed.
>> So I would have expected your commit message to contain some fact why
>> synchronization is going to be slow and why this is a problem.
>>
>> To give you a concrete example, the implementation of set/way instructions are
>> really slow (it could take a few seconds depending on the setup). However,
>> this was fine because not implementing them correctly would have a greater
>> impact on the guest (corruption) and they are not used often.
>>
>> I don't think the performance in our case will be in same order magnitude. It
>> is most likely to be in the range of milliseconds (if not less) which I think
>> is acceptable for emulation (particularly for the vGIC) and the current uses.
> 
> Writing on the mailing list some of our discussions today.
> 
> Correctness is not just in terms of compliance to a specification but it
> is also about not breaking guests. Introducing latency in the range of
> milliseconds, or hundreds of microseconds, would break any latency
> sensitive workloads. We don't have numbers so we don't know for certain
> the effect that your suggestion would have.

You missed part of the discussion. I don't disagree that latency is 
important. However, if an implementation is only 95% reliable, then it 
means 5% of the time your guest may break (corruption, crash, 
deadlock...). At which point the latency is the last of your concern.

> 
> It would be interesting to have those numbers, and I'll add to my TODO
> list to run the experiments you suggested, but I'll put it on the
> back-burner (from a Xilinx perspective it is low priority as no
> customers are affected.)

How about we get a correct implementation merge first and then discuss 
about optimization? This would allow the community to check whether 
there are actually noticeable latency in their workload.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 08:53:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 08:53:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJZ7e-0001NV-F0; Wed, 01 Apr 2020 08:53:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJZ7d-0001NQ-7G
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 08:53:17 +0000
X-Inumbo-ID: 3a3738e6-73f6-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3a3738e6-73f6-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 08:53:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=IWjjmTTTCsj04XURSsMtNB/kMpu+iwDcayN0PjCPOAw=; b=SfYVwS88Re8U6lg/b9IRwMIR9p
 g9gcP6+d2PHB8xIYo+WcCoLzCu7hCpWOaZIOsWjdxdW62PTls/h6zjwJOvEEQrA0DoRkbYOnsWKQz
 YabYQJiYslgfsBYsrVp9PWTAYv2WnhOwR4X5Sa+NyK2WFYNKSpkkz3RKtbvz+uybib3g=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJZ7Z-0006FX-JX; Wed, 01 Apr 2020 08:53:13 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJZ7Z-0007jb-Bj; Wed, 01 Apr 2020 08:53:13 +0000
Subject: Re: [PATCH 1/8] xen/guest_access: Harden copy_to_guest_offset to
 prevent const dest operand
To: Jan Beulich <jbeulich@suse.com>
References: <20200330192157.1335-1-julien@xen.org>
 <20200330192157.1335-2-julien@xen.org>
 <33a36f0e-5adb-b8af-445c-bab765c84589@suse.com>
 <b5f7037a-5253-b5f2-d5b7-1b90d19021c2@xen.org>
 <2ce142db-dd2d-4ef2-ee18-9d67d491e400@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <b5bf5a16-042b-3ca4-d9af-cb7c890ff8f1@xen.org>
Date: Wed, 1 Apr 2020 09:53:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <2ce142db-dd2d-4ef2-ee18-9d67d491e400@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 dfaggioli@suse.com, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 01/04/2020 07:48, Jan Beulich wrote:
> On 31.03.2020 21:13, Julien Grall wrote:
>> On 31/03/2020 08:26, Jan Beulich wrote:
>>> On 30.03.2020 21:21, Julien Grall wrote:
>>>> From: Julien Grall <jgrall@amazon.com>
>>>>
>>>> At the moment, copy_to_guest_offset() will allow the hypervisor to copy
>>>> data to guest handle marked const.
>>>>
>>>> Thankfully, no users of the helper will do that. Rather than hoping this
>>>> can be caught during review, harden copy_to_guest_offset() so the build
>>>> will fail if such users are introduced.
>>>
>>> But there are other implications you break:
>>>
>>>> --- a/xen/include/asm-arm/guest_access.h
>>>> +++ b/xen/include/asm-arm/guest_access.h
>>>> @@ -126,7 +126,7 @@ int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
>>>>      #define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
>>>>        const typeof(*(ptr)) *_s = (ptr);                   \
>>>> -    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>>>> +    typeof(*((hnd).p)) *_d = (hnd).p;                   \
>>>>        ((void)((hnd).p == (ptr)));                         \
>>>>        __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
>>>
>>> Until this change, it is "ptr" which all sizes get derived from,
>>> i.e. it is the internally used type rather than the handle type
>>> which controls this. I'm sure we use this in a few places, to
>>> copy to e.g. a handle derived from "void". Compatibility of types
>>> (disallowing other than void) is checked by the comparison on the
>>> line immediately after the line you change. Yes "_d+(off)" right
>>> above here then changes its result. I consider it pretty likely
>>> you'd notice this issue once you go beyond just build testing.
>>
>> I missed that part. To be honest, it feels wrong to me to have
>> "off" != 0 and use a void type for the handle. Would it make
>> sense to forbid it?
> 
> I don't think so - the idea (aiui) has always been for the Xen
> internal object's type to control what gets copied, and hence a
> void handle is to be fine for both copy-in and copy-out.
> 
>> As a side node, I have updated __copy_to_guest_offset() but
>> forgot to update copy_to_guest_offset(). I will look to apply
>> the modifications we agree on both side.
> 
> Ah, sure.
> 
>>> To address this, I guess we need to find an expression along the
>>> lines of that comparison, which does not cause any code to be
>>> generated, but which verifies the properties we care about. The
>>> line you change should be left alone, from all I can tell right
>>> now.
>>
>> I am not aware of any way before C11 to check if a variable is
>> const or not. If we wanted to keep allow void type the handle
>> then a possible approach would be:
>>
>> #define copy_to_guest_offset(hnd, off, ptr, nr) ({              \
>>      const typeof(*(ptr)) *_s = (ptr);                           \
>>      typeof(*((hnd).p)) *_d = (hnd).p;                           \
>>      size_t mul = (sizeof(*(hnd).p) > 1) ? 1 : sizeof (*_s);     \
>>      ((void)((hnd).p == (ptr)));                                 \
>>      raw_copy_to_guest(_d + (off) * mul, _s, sizeof(*_s)*(nr));  \
>> })
>>
>> I don't particularly like it but I could not come up with better so far.
> 
> Not very nice indeed, and the conditional expression - at the
> first glance being the wrong way round - seems outright
> confusing to me.

It is the correct way. If the handle is a void (sizeof(*(hnd).p) == 1), 
then we need to know the size of the Xen buffer so we can compute the 
offset correctly. Otherwise, as we have the correct type, we can apply 
the offset directly and let the compiler do the math for us.

> I'll try to find time to experiment some with
> this as well, since unless we can find a reasonably neat
> solution here, I'm inclined to suggest to leave this as it is
> now.

It is difficult to catch the hypervisor who errorneously write to 
"const" handler. So I would not like a statu-quo.

A slightly uglier version (with more comments) is going to be better 
than what we currently have.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 09:22:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 09:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJZZv-0003pH-UX; Wed, 01 Apr 2020 09:22:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJZZu-0003pC-AW
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 09:22:30 +0000
X-Inumbo-ID: 4e65359e-73fa-11ea-ba83-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4e65359e-73fa-11ea-ba83-12813bfff9fa;
 Wed, 01 Apr 2020 09:22:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=gjB0F15GMKPMSTmEoWn36mmrMTvBgmHzi8H+l7stqwo=; b=0Ej525B6FAcb9VrF5PenqRhW1f
 1wXH0YvinXe+gT72H03DBv3oRfql6bwFWHAlLcXJ3LbxYydE6WXkAhmYLwTfP+D4jaX4ZxFp6JKt7
 5zAbLGqPClRobQyoX+nRbz/XRjqdqaL8K6Xo3tWRARv36KbkpVDFMu428+cLqNJdg4dE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJZZl-0006pH-OX; Wed, 01 Apr 2020 09:22:21 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJZZl-0001Ct-8Y; Wed, 01 Apr 2020 09:22:21 +0000
Subject: Re: [XEN PATCH v4 02/18] xen/arm: Configure early printk via Kconfig
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-3-anthony.perard@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <77148308-7af0-098d-d7a8-f393350cc69f@xen.org>
Date: Wed, 1 Apr 2020 10:22:18 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-3-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Julien Grall <julien.grall@arm.com>,
 Jan Beulich <jbeulich@suse.com>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Anthony,

On 31/03/2020 11:30, Anthony PERARD wrote:
> At the moment, early printk can only be configured on the make command
> line. It is not very handy because a user has to remove the option
> everytime it is using another command other than compiling the
> hypervisor.
> 
> Furthermore, early printk is one of the few odds one that are not
> using Kconfig.
> 
> So this is about time to move it to Kconfig.
> 
> The new kconfigs options allow a user to eather select a UART driver
> to use at boot time, and set the parameters, or it is still possible
> to select a platform which will set the parameters.
> 
> If CONFIG_EARLY_PRINTK is present in the environment or on the make
> command line, make will return an error.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Tested-by: Stefano Stabellini <sstabellini@kernel.org>

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

> ---
> 
> Notes:
>      v4:
>      - Add range to EARLY_UART_BASE_ADDRESS so that kconfig won't accept
>        address higher than 4G on ARM_32
>      - have EARLY_PRINTK_THUNDERX depends on ARM_64 because the default base
>        address is above 4G
>      - Add deprecation warning to the help of the choice of early printk
>        driver/platform.
>      - in early-printk.txt, add that early printk is available with EXPERT.
>      
>      Patch v3 and early where in "xen/arm: Configure early printk via
>      Kconfig" series.
>      
>      v3:
>      - rename EARLY_PRINK to CONFIG_EARLY_PRINTK in makefile here (which
>        select which object to build).
>      - rename EARLY_UART_BAUD_RATE to EARLY_UART_PL011_BAUD_RATE
>      - typos
>      - drop the list of aliases in early-printk.txt. Kconfig choice menu
>        should be enough.
>      - reword early-printk.txt.
>      - rework how EARLY_PRINTK is set to Y
>        and use that instead of a list of all EARLY_UART_*
>      - Add a check to ask user to use Kconfig to set early printk.
>      - rework the possible choice to have all uart driver and platform
>        specific option together.
>      - have added or reword prompt and help messages of the different
>        options. The platform specific option don't have extended help, the
>        prompt is probably enough.
>        (The non-platform specific options have the help message that Julien
>        have written in the first version.)
>      - have made EARLY_UART_INIT dependent on the value of
>        EARLY_UART_PL011_BAUD_RATE so that there is no need to expose _INIT to
>        users.
> 
>   docs/misc/arm/early-printk.txt                |  71 ++---
>   xen/Kconfig.debug                             |   2 +
>   xen/arch/arm/Kconfig.debug                    | 289 ++++++++++++++++++
>   xen/arch/arm/Makefile                         |   2 +-
>   xen/arch/arm/Rules.mk                         |  74 +----
>   xen/arch/arm/arm32/Makefile                   |   2 +-
>   xen/arch/arm/arm64/Makefile                   |   2 +-
>   .../minios.cfg => xen/arch/x86/Kconfig.debug  |   0
>   8 files changed, 319 insertions(+), 123 deletions(-)
>   create mode 100644 xen/arch/arm/Kconfig.debug
>   copy stubdom/c/minios.cfg => xen/arch/x86/Kconfig.debug (100%)
> 
> diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
> index 89e081e51eaf..aa22826075a4 100644
> --- a/docs/misc/arm/early-printk.txt
> +++ b/docs/misc/arm/early-printk.txt
> @@ -1,64 +1,39 @@
>   How to enable early printk
>   
> -Early printk can only be enabled if debug=y. You may want to enable it if
> -you are debbuging code that executes before the console is initialized.
> +Early printk can only be enabled if CONFIG_DEBUG=y or in EXPERT mode. You
> +may want to enable it if you are debugging code that executes before the
> +console is initialized.
>   
>   Note that selecting this option will limit Xen to a single UART definition.
>   Attempting to boot Xen image on a different platform *will not work*, so this
>   option should not be enable for Xens that are intended to be portable.
>   
> -CONFIG_EARLY_PRINTK=<INC>,<BASE_ADDRESS>,<OTHER_OPTIONS>
> +Select one of the "Early printk via * UART" in the choice possible for
> +"Early printk" in the "Debugging options" of Kconfig. You will then need to
> +set other options, which depends on the driver selected.
>   
> -<INC> and <BASE_ADDRESS> are mandatory arguments:
> +CONFIG_EARLY_UART_BASE_ADDRESS is a mandatory argument, it is the base
> +physical address of the UART to use.
>   
> -  - <INC> is the name of the driver, see xen/arch/arm/arm{32,64}/debug-*.inc
> -    (where <INC> corresponds to the wildcarded *).
> -  - <BASE_ADDRESS> is the base physical address of the UART to use
> +Other options depends on the driver selected:
> +  - 8250
> +    - CONFIG_EARLY_UART_8250_REG_SHIFT is, optionally, the left-shift to
> +      apply to the register offsets within the uart.
> +  - pl011
> +    - CONFIG_EARLY_UART_PL011_BAUD_RATE is, optionally, a baud rate which
> +      should be used to configure the UART at start of day.
>   
> -<OTHER_OPTIONS> varies depending on <INC>:
> +      If CONFIG_EARLY_UART_PL011_BAUD_RATE  is set to 0 then the code will
> +      not try to initialize the UART, so that bootloader or firmware
> +      settings can be used for maximum compatibility.
> +  - scif
> +    - CONFIG_EARLY_UART_SCIF_VERSION_* is, optionally, the interface version
> +      of the UART. Default to version NONE.
>   
> -  - 8250,<BASE_ADDRESS>,<REG_SHIFT>
> -    - <REG_SHIFT> is, optionally, the left-shift to apply to the
> -      register offsets within the uart.
> -  - pl011,<BASE_ADDRESS>,<BAUD_RATE>
> -    - <BAUD_RATE> is, optionally a baud rate which should be used to
> -      configure the UART at start of day.
> -
> -      If <BAUD_RATE> is not given then the code will not try to
> -      initialize the UART, so that bootloader or firmware settings can
> -     be used for maximum compatibility.
> -  - scif,<BASE_ADDRESS>,<VERSION>
> -    - SCIF<VERSION> is, optionally, the interface version of the UART.
> -
> -      If <VERSION> is not given then the default interface version (SCIF)
> -      will be used.
>     - For all other uarts there are no additional options.
>   
>   As a convenience it is also possible to select from a list of
> -predefined configurations using CONFIG_EARLY_PRINTK=mach where mach is
> -the name of the machine:
> -
> -  - brcm: printk with 8250 on Broadcom 7445D0 boards with A15 processors.
> -  - dra7: printk with 8250 on DRA7 platform
> -  - exynos5250: printk with the second UART
> -  - fastmodel: printk on ARM Fastmodel software emulators
> -  - hikey960: printk with pl011 with Hikey 960
> -  - juno: printk with pl011 on Juno platform
> -  - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor)
> -  - midway: printk with the pl011 on Calxeda Midway processors
> -  - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
> -  - omap5432: printk with UART3 on TI OMAP5432 processors
> -  - rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
> -  - seattle: printk with pl011 for AMD Seattle processor
> -  - sun6i: printk with 8250 on Allwinner A31 processors
> -  - sun7i: printk with 8250 on Allwinner A20 processors
> -  - thunderx: printk with pl011 for Cavium ThunderX processor
> -  - vexpress: printk with pl011 for versatile express
> -  - xgene-mcdivitt: printk with 820 on Xgene mcdivitt platform
> -  - xgene-storm: printk with 820 on Xgene storm platform
> -  - zynqmp: printk with Cadence UART for Xilinx ZynqMP SoCs
> -
> -These settings are is hardcoded in xen/arch/arm/Rules.mk,
> -see there when adding support for new machines.
> +predefined configurations available in the list of choice for "Early
> +printk" for specific platform.
>   
>   By default early printk is disabled.
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index b3511e81a275..ee6ee33b69be 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -128,6 +128,8 @@ config XMEM_POOL_POISON
>   	  Poison free blocks with 0xAA bytes and verify them when a block is
>   	  allocated in order to spot use-after-free issues.
>   
> +source "arch/$(SRCARCH)/Kconfig.debug"
> +
>   endif # DEBUG || EXPERT
>   
>   endmenu
> diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
> new file mode 100644
> index 000000000000..35ccd132732b
> --- /dev/null
> +++ b/xen/arch/arm/Kconfig.debug
> @@ -0,0 +1,289 @@
> +choice
> +	bool "Early printk"
> +	optional
> +	help
> +		You may want to enable early printk if you are debugging code
> +		that executes before the console is initialized.
> +
> +		Note that selecting this option will limit Xen to a single UART
> +		definition. Attempting to boot Xen image on a different
> +		platform *will not work*, so this option should not be enable
> +		for Xens that are intended to be portable.
> +
> +		Choose one of the UART drivers for early printk, then you'll
> +		have to specify the parameters, like the base address.
> +
> +		Deprecated: Alternatively, there are platform specific options
> +		which will have default values for the various parameters. But
> +		such option will soon be removed.
> +
> +	config EARLY_UART_CHOICE_8250
> +		select EARLY_UART_8250
> +		bool "Early printk via 8250 UART"
> +		help
> +			Say Y here if you wish the early printk to direct their
> +			output to a 8250 UART. You can use this option to
> +			provide the parameters for the 8250 UART rather than
> +			selecting one of the platform specific options below if
> +			you know the parameters for the port.
> +
> +			This option is preferred over the platform specific
> +			options; the platform specific options are deprecated
> +			and will soon be removed.
> +	config EARLY_UART_CHOICE_CADENCE
> +		select EARLY_UART_CADENCE
> +		depends on ARM_64
> +		bool "Early printk via Cadence UART"
> +		help
> +			Say Y here if you wish the early printk to direct their
> +			output to a Cadence UART. You can use this option to
> +			provide the parameters for the Cadence UART rather than
> +			selecting one of the platform specific options below if
> +			you know the parameters for the port.
> +
> +			This option is preferred over the platform specific
> +			options; the platform specific options are deprecated
> +			and will soon be removed.
> +	config EARLY_UART_CHOICE_EXYNOS4210
> +		select EARLY_UART_EXYNOS4210
> +		depends on ARM_32
> +		bool "Early printk via Exynos4210 UART"
> +		help
> +			Say Y here if you wish the early printk to direct their
> +			output to a Exynos 4210 UART. You can use this option to
> +			provide the parameters for the Exynos 4210 UART rather than
> +			selecting one of the platform specific options below if
> +			you know the parameters for the port.
> +
> +			This option is preferred over the platform specific
> +			options; the platform specific options are deprecated
> +			and will soon be removed.
> +	config EARLY_UART_CHOICE_MESON
> +		select EARLY_UART_MESON
> +		depends on ARM_64
> +		bool "Early printk via MESON UART"
> +		help
> +			Say Y here if you wish the early printk to direct their
> +			output to a MESON UART. You can use this option to
> +			provide the parameters for the MESON UART rather than
> +			selecting one of the platform specific options below if
> +			you know the parameters for the port.
> +
> +			This option is preferred over the platform specific
> +			options; the platform specific options are deprecated
> +			and will soon be removed.
> +	config EARLY_UART_CHOICE_MVEBU
> +		select EARLY_UART_MVEBU
> +		depends on ARM_64
> +		bool "Early printk via MVEBU UART"
> +		help
> +			Say Y here if you wish the early printk to direct their
> +			output to a MVEBU UART. You can use this option to
> +			provide the parameters for the MVEBU UART rather than
> +			selecting one of the platform specific options below if
> +			you know the parameters for the port.
> +
> +			This option is preferred over the platform specific
> +			options; the platform specific options are deprecated
> +			and will soon be removed.
> +	config EARLY_UART_CHOICE_PL011
> +		select EARLY_UART_PL011
> +		bool "Early printk via PL011 UART"
> +		help
> +			Say Y here if you wish the early printk to direct their
> +			output to a PL011 UART. You can use this option to
> +			provide the parameters for the PL011 UART rather than
> +			selecting one of the platform specific options below if
> +			you know the parameters for the port.
> +
> +			This option is preferred over the platform specific
> +			options; the platform specific options are deprecated
> +			and will soon be removed.
> +	config EARLY_UART_CHOICE_SCIF
> +		select EARLY_UART_SCIF
> +		bool "Early printk via SCIF UART"
> +		help
> +			Say Y here if you wish the early printk to direct their
> +			output to a SCIF UART. You can use this option to
> +			provide the parameters for the SCIF UART rather than
> +			selecting one of the platform specific options below if
> +			you know the parameters for the port.
> +
> +			This option is preferred over the platform specific
> +			options; the platform specific options are deprecated
> +			and will soon be removed.
> +
> +	config EARLY_PRINTK_BRCM
> +		bool "Early printk with 8250 on Broadcom 7445D0 boards with A15 processors"
> +		select EARLY_UART_8250
> +	config EARLY_PRINTK_DRA7
> +		bool "Early printk with 8250 on DRA7 platform"
> +		select EARLY_UART_8250
> +	config EARLY_PRINTK_EXYNOS5250
> +		bool "Early printk with the second UART on Exynos5250"
> +		select EARLY_UART_EXYNOS4210
> +		depends on ARM_32
> +	config EARLY_PRINTK_FASTMODEL
> +		bool "Early printk with pl011 on ARM Fastmodel software emulators"
> +		select EARLY_UART_PL011
> +	config EARLY_PRINTK_HIKEY960
> +		bool "Early printk with pl011 with Hikey 960"
> +		select EARLY_UART_PL011
> +	config EARLY_PRINTK_JUNO
> +		bool "Early printk with pl011 on Juno platform"
> +		select EARLY_UART_PL011
> +	config EARLY_PRINTK_LAGER
> +		bool "Early printk with SCIF0 on Renesas Lager board (R-Car H2 processor)"
> +		select EARLY_UART_SCIF
> +	config EARLY_PRINTK_MIDWAY
> +		bool "Early printk with pl011 on Calxeda Midway processors"
> +		select EARLY_UART_PL011
> +	config EARLY_PRINTK_MVEBU
> +		bool "Early printk with MVEBU for Marvell Armada 3700 SoCs"
> +		select EARLY_UART_MVEBU
> +		depends on ARM_64
> +	config EARLY_PRINTK_OMAP5432
> +		bool "Early printk with UART3 on TI OMAP5432 processors"
> +		select EARLY_UART_8250
> +	config EARLY_PRINTK_RCAR3
> +		bool "Early printk with SCIF2 on Renesas R-Car Gen3 processors"
> +		select EARLY_UART_SCIF
> +	config EARLY_PRINTK_SEATTLE
> +		bool "Early printk with pl011 for AMD Seattle processor"
> +		select EARLY_UART_PL011
> +	config EARLY_PRINTK_SUN6I
> +		bool "Early printk with 8250 on Allwinner A31 processors"
> +		select EARLY_UART_8250
> +	config EARLY_PRINTK_SUN7I
> +		bool "Early printk with 8250 on Allwinner A20 processors"
> +		select EARLY_UART_8250
> +	config EARLY_PRINTK_THUNDERX
> +		bool "Early printk with pl011 for Cavium ThunderX processor"
> +		select EARLY_UART_PL011
> +		depends on ARM_64
> +	config EARLY_PRINTK_VEXPRESS
> +		bool "Early printk with pl011 for versatile express"
> +		select EARLY_UART_PL011
> +	config EARLY_PRINTK_XGENE_MCDIVITT
> +		bool "Early printk with 820 on Xgene mcdivitt platform"
> +		select EARLY_UART_8250
> +	config EARLY_PRINTK_XGENE_STORM
> +		bool "Early printk with 820 on Xgene storm platform"
> +		select EARLY_UART_8250
> +	config EARLY_PRINTK_ZYNQMP
> +		bool "Early printk with Cadence UART for Xilinx ZynqMP SoCs"
> +		select EARLY_UART_CADENCE
> +		depends on ARM_64
> +endchoice
> +
> +
> +config EARLY_UART_8250
> +	select EARLY_PRINTK
> +	bool
> +config EARLY_UART_CADENCE
> +	select EARLY_PRINTK
> +	bool
> +config EARLY_UART_EXYNOS4210
> +	select EARLY_PRINTK
> +	bool
> +config EARLY_UART_MESON
> +	select EARLY_PRINTK
> +	bool
> +config EARLY_UART_MVEBU
> +	select EARLY_PRINTK
> +	bool
> +config EARLY_UART_PL011
> +	select EARLY_PRINTK
> +	bool
> +config EARLY_UART_SCIF
> +	select EARLY_PRINTK
> +	bool
> +
> +config EARLY_PRINTK
> +	bool
> +
> +config EARLY_UART_BASE_ADDRESS
> +	depends on EARLY_PRINTK
> +	hex "Early printk, physical base address of debug UART"
> +	range 0x0 0xffffffff if ARM_32
> +	default 0xF040AB00 if EARLY_PRINTK_BRCM
> +	default 0x4806A000 if EARLY_PRINTK_DRA7
> +	default 0x1c090000 if EARLY_PRINTK_FASTMODEL
> +	default 0x12c20000 if EARLY_PRINTK_EXYNOS5250
> +	default 0xfff32000 if EARLY_PRINTK_HIKEY960
> +	default 0x7ff80000 if EARLY_PRINTK_JUNO
> +	default 0xe6e60000 if EARLY_PRINTK_LAGER
> +	default 0xfff36000 if EARLY_PRINTK_MIDWAY
> +	default 0xd0012000 if EARLY_PRINTK_MVEBU
> +	default 0x48020000 if EARLY_PRINTK_OMAP5432
> +	default 0xe6e88000 if EARLY_PRINTK_RCAR3
> +	default 0xe1010000 if EARLY_PRINTK_SEATTLE
> +	default 0x01c28000 if EARLY_PRINTK_SUN6I
> +	default 0x01c28000 if EARLY_PRINTK_SUN7I
> +	default 0x87e024000000 if EARLY_PRINTK_THUNDERX
> +	default 0x1c090000 if EARLY_PRINTK_VEXPRESS
> +	default 0x1c021000 if EARLY_PRINTK_XGENE_MCDIVITT
> +	default 0x1c020000 if EARLY_PRINTK_XGENE_STORM
> +	default 0xff000000 if EARLY_PRINTK_ZYNQMP
> +
> +config EARLY_UART_PL011_BAUD_RATE
> +	depends on EARLY_UART_PL011
> +	int "Early printk UART baud rate for pl011"
> +	help
> +		Optionally sets the baud rate which should be used to configure
> +		the UART at start of day.
> +
> +		If EARLY_UART_PL011_BAUD_RATE is set to 0 then the code will
> +		not try to initialize the UART, so that bootloader or firmware
> +		settings can be used for maximum compatibility.
> +
> +	default 115200 if EARLY_PRINTK_FASTMODEL
> +	default 0
> +
> +config EARLY_UART_INIT
> +	depends on EARLY_UART_PL011 && EARLY_UART_PL011_BAUD_RATE != 0
> +	def_bool y
> +
> +config EARLY_UART_8250_REG_SHIFT
> +	depends on EARLY_UART_8250
> +	int "Early printk, left-shift to apply to the register offsets within the 8250 UART"
> +	help
> +		EARLY_UART_8250_REG_SHIFT is, optionally, the left-shift to
> +		apply to the register offsets within the UART with early
> +		printk.
> +
> +		Default to 0.
> +
> +	default 2 if EARLY_PRINTK_BRCM
> +	default 2 if EARLY_PRINTK_DRA7
> +	default 2 if EARLY_PRINTK_OMAP5432
> +	default 2 if EARLY_PRINTK_SUN6I
> +	default 2 if EARLY_PRINTK_SUN7I
> +	default 2 if EARLY_PRINTK_XGENE_MCDIVITT
> +	default 2 if EARLY_PRINTK_XGENE_STORM
> +	default 0
> +
> +choice EARLY_UART_SCIF_VERSION
> +	prompt "Early printk UART SCIF interface version"
> +	depends on EARLY_UART_SCIF
> +	default EARLY_UART_SCIF_VERSION_NONE
> +	help
> +		Select the interface version of the SCIF UART.
> +
> +		Select EARLY_UART_SCIF_VERSION_NONE to use the default
> +		interface version (SCIF).
> +	config EARLY_UART_SCIF_VERSION_NONE
> +		bool "default SCIF UART interface"
> +	config EARLY_UART_SCIF_VERSION_A
> +		bool "SCIF UART interface version A"
> +endchoice
> +
> +config EARLY_PRINTK_INC
> +	string
> +	default "debug-8250.inc" if EARLY_UART_8250
> +	default "debug-cadence.inc" if EARLY_UART_CADENCE
> +	default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
> +	default "debug-meson.inc" if EARLY_UART_MESON
> +	default "debug-mvebu.inc" if EARLY_UART_MVEBU
> +	default "debug-pl011.inc" if EARLY_UART_PL011
> +	default "debug-scif.inc" if EARLY_UART_SCIF
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 1044c2298a05..12f92a4bd3f9 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -16,7 +16,7 @@ obj-y += device.o
>   obj-y += domain.o
>   obj-y += domain_build.init.o
>   obj-y += domctl.o
> -obj-$(EARLY_PRINTK) += early_printk.o
> +obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
>   obj-y += gic.o
>   obj-y += gic-v2.o
>   obj-$(CONFIG_GICV3) += gic-v3.o
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index faa09ea111ec..3ad284aa71a4 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -18,76 +18,6 @@ CFLAGS-$(CONFIG_ARM_32) += -mcpu=cortex-a15
>   CFLAGS-$(CONFIG_ARM_64) += -mcpu=generic
>   CFLAGS-$(CONFIG_ARM_64) += -mgeneral-regs-only # No fp registers etc
>   
> -EARLY_PRINTK := n
> -
> -ifeq ($(CONFIG_DEBUG),y)
> -
> -# See docs/misc/arm/early-printk.txt for syntax
> -
> -EARLY_PRINTK_brcm           := 8250,0xF040AB00,2
> -EARLY_PRINTK_dra7           := 8250,0x4806A000,2
> -EARLY_PRINTK_fastmodel      := pl011,0x1c090000,115200
> -EARLY_PRINTK_exynos5250     := exynos4210,0x12c20000
> -EARLY_PRINTK_hikey960       := pl011,0xfff32000
> -EARLY_PRINTK_juno           := pl011,0x7ff80000
> -EARLY_PRINTK_lager          := scif,0xe6e60000
> -EARLY_PRINTK_midway         := pl011,0xfff36000
> -EARLY_PRINTK_mvebu          := mvebu,0xd0012000
> -EARLY_PRINTK_omap5432       := 8250,0x48020000,2
> -EARLY_PRINTK_rcar3          := scif,0xe6e88000
> -EARLY_PRINTK_seattle        := pl011,0xe1010000
> -EARLY_PRINTK_sun6i          := 8250,0x01c28000,2
> -EARLY_PRINTK_sun7i          := 8250,0x01c28000,2
> -EARLY_PRINTK_thunderx       := pl011,0x87e024000000
> -EARLY_PRINTK_vexpress       := pl011,0x1c090000
> -EARLY_PRINTK_xgene-mcdivitt := 8250,0x1c021000,2
> -EARLY_PRINTK_xgene-storm    := 8250,0x1c020000,2
> -EARLY_PRINTK_zynqmp         := cadence,0xff000000
> -
> -ifneq ($(EARLY_PRINTK_$(CONFIG_EARLY_PRINTK)),)
> -EARLY_PRINTK_CFG := $(subst $(comma), ,$(EARLY_PRINTK_$(CONFIG_EARLY_PRINTK)))
> -else
> -EARLY_PRINTK_CFG := $(subst $(comma), ,$(CONFIG_EARLY_PRINTK))
> -endif
> -
> -# Extract configuration from string
> -EARLY_PRINTK_INC := $(word 1,$(EARLY_PRINTK_CFG))
> -EARLY_UART_BASE_ADDRESS := $(word 2,$(EARLY_PRINTK_CFG))
> -
> -# UART specific options
> -ifeq ($(EARLY_PRINTK_INC),8250)
> -EARLY_UART_REG_SHIFT := $(word 3,$(EARLY_PRINTK_CFG))
> -endif
> -ifeq ($(EARLY_PRINTK_INC),pl011)
> -ifneq ($(word 3,$(EARLY_PRINTK_CFG)),)
> -EARLY_PRINTK_INIT_UART := y
> -EARLY_PRINTK_BAUD := $(word 3,$(EARLY_PRINTK_CFG))
> -endif
> -endif
> -ifeq ($(EARLY_PRINTK_INC),scif)
> -ifneq ($(word 3,$(EARLY_PRINTK_CFG)),)
> -CFLAGS-y += -DCONFIG_EARLY_UART_SCIF_VERSION_$(word 3,$(EARLY_PRINTK_CFG))
> -else
> -CFLAGS-y += -DCONFIG_EARLY_UART_SCIF_VERSION_NONE
> -endif
> -endif
> -
> -ifneq ($(EARLY_PRINTK_INC),)
> -EARLY_PRINTK := y
> -endif
> -
> -CFLAGS-$(EARLY_PRINTK) += -DCONFIG_EARLY_PRINTK
> -CFLAGS-$(EARLY_PRINTK_INIT_UART) += -DCONFIG_EARLY_UART_INIT
> -CFLAGS-$(EARLY_PRINTK) += -DCONFIG_EARLY_PRINTK_INC=\"debug-$(EARLY_PRINTK_INC).inc\"
> -CFLAGS-$(EARLY_PRINTK) += -DCONFIG_EARLY_UART_PL011_BAUD_RATE=$(EARLY_PRINTK_BAUD)
> -CFLAGS-$(EARLY_PRINTK) += -DCONFIG_EARLY_UART_BASE_ADDRESS=$(EARLY_UART_BASE_ADDRESS)
> -CFLAGS-$(EARLY_PRINTK) += -DCONFIG_EARLY_UART_8250_REG_SHIFT=$(EARLY_UART_REG_SHIFT)
> -
> -else # !CONFIG_DEBUG
> -
> -ifneq ($(CONFIG_EARLY_PRINTK),)
> -# Early printk is dependant on a debug build.
> -$(error CONFIG_EARLY_PRINTK enabled for non-debug build)
> -endif
> -
> +ifneq ($(filter command line environment,$(origin CONFIG_EARLY_PRINTK)),)
> +    $(error You must use 'make menuconfig' to enable/disable early printk now)
>   endif
> diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
> index 539bbef298a7..96105d238307 100644
> --- a/xen/arch/arm/arm32/Makefile
> +++ b/xen/arch/arm/arm32/Makefile
> @@ -1,6 +1,6 @@
>   obj-y += lib/
>   
> -obj-$(EARLY_PRINTK) += debug.o
> +obj-$(CONFIG_EARLY_PRINTK) += debug.o
>   obj-y += domctl.o
>   obj-y += domain.o
>   obj-y += entry.o
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index db8565b71a33..40642ff57494 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -2,7 +2,7 @@ obj-y += lib/
>   
>   obj-y += cache.o
>   obj-$(CONFIG_HARDEN_BRANCH_PREDICTOR) += bpi.o
> -obj-$(EARLY_PRINTK) += debug.o
> +obj-$(CONFIG_EARLY_PRINTK) += debug.o
>   obj-y += domctl.o
>   obj-y += domain.o
>   obj-y += entry.o
> diff --git a/stubdom/c/minios.cfg b/xen/arch/x86/Kconfig.debug
> similarity index 100%
> copy from stubdom/c/minios.cfg
> copy to xen/arch/x86/Kconfig.debug
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 09:25:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 09:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJZcY-0003xD-GR; Wed, 01 Apr 2020 09:25:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJZcW-0003wS-NP
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 09:25:12 +0000
X-Inumbo-ID: af204626-73fa-11ea-ba84-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id af204626-73fa-11ea-ba84-12813bfff9fa;
 Wed, 01 Apr 2020 09:25:11 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1D95CAD7C;
 Wed,  1 Apr 2020 09:25:10 +0000 (UTC)
Subject: Re: [PATCH 1/8] xen/guest_access: Harden copy_to_guest_offset to
 prevent const dest operand
To: Julien Grall <julien@xen.org>
References: <20200330192157.1335-1-julien@xen.org>
 <20200330192157.1335-2-julien@xen.org>
 <33a36f0e-5adb-b8af-445c-bab765c84589@suse.com>
 <b5f7037a-5253-b5f2-d5b7-1b90d19021c2@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <11871e55-481f-b318-bf5d-d9518e180fa9@suse.com>
Date: Wed, 1 Apr 2020 11:25:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <b5f7037a-5253-b5f2-d5b7-1b90d19021c2@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 dfaggioli@suse.com, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 21:13, Julien Grall wrote:
> I am not aware of any way before C11 to check if a variable is
> const or not. If we wanted to keep allow void type the handle
> then a possible approach would be:
> 
> #define copy_to_guest_offset(hnd, off, ptr, nr) ({              \
>     const typeof(*(ptr)) *_s = (ptr);                           \
>     typeof(*((hnd).p)) *_d = (hnd).p;                           \
>     size_t mul = (sizeof(*(hnd).p) > 1) ? 1 : sizeof (*_s);     \
>     ((void)((hnd).p == (ptr)));                                 \
>     raw_copy_to_guest(_d + (off) * mul, _s, sizeof(*_s)*(nr));  \
> })
> 
> I don't particularly like it but I could not come up with better so far.

Having looked at how in particular copy_field_to_guest() (which
doesn't have this issue afaict) works, here's an imo much better
alternative:

@@ -87,6 +87,7 @@
 #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
 })
@@ -143,6 +144,7 @@ static inline void put_guest_handle(void
 #define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
 })

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 09:42:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 09:42:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJZsz-0005Yq-VK; Wed, 01 Apr 2020 09:42:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJZsz-0005Yl-E8
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 09:42:13 +0000
X-Inumbo-ID: 107a7d0e-73fd-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 107a7d0e-73fd-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 09:42:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Ieac/wN7McepiWeegw1+N3duJujkjNNABEbYp1vC6ss=; b=UYOBdMj+OKyWBiwCt0tmIg6S22
 4oULm9bNIKV/u8MECW1Z9xJUYoLfRyDDw5Ba5MRmlmVEPwmiC5sBsTsK5a0lJr5VVs7IWts7N+OrT
 88j2gGDpo1/q/qf4RA5x+bBxUo86C6v+vAeAzKkrjy7955sHJN0pSFr1ZOkHjrYjUVvk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJZsx-0007CW-Sc; Wed, 01 Apr 2020 09:42:11 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJZsx-0002BY-MP; Wed, 01 Apr 2020 09:42:11 +0000
Subject: Re: [XEN PATCH v4 03/18] build,arm: Fix deps check of head.o
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-4-anthony.perard@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <7300607b-2a51-7659-200b-f17e6c3a0287@xen.org>
Date: Wed, 1 Apr 2020 10:42:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-4-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Anthony,

On 31/03/2020 11:30, Anthony PERARD wrote:
> arm*/head.o isn't in obj-y or extra-y, so make don't load the
> associated .*.d file (or .*.cmd file when if_changed will be used).
> There is a workaround where .*.d file is added manually into DEPS.
> 
> Changing DEPS isn't needed, we can simply add head.o into extra-y and
> the dependency files will be loaded.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 09:52:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 09:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJa33-0006Qy-0c; Wed, 01 Apr 2020 09:52:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJa32-0006Qt-Eq
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 09:52:36 +0000
X-Inumbo-ID: 837f781c-73fe-11ea-ba8a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 837f781c-73fe-11ea-ba8a-12813bfff9fa;
 Wed, 01 Apr 2020 09:52:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=1Pr0MG7NZzW99ZS/jmrI/xhXCmb1VSFC/EqDpRZX9zU=; b=ee7rIUyIaKRFZgkqeD/hv5RtLR
 vPX0PO4fW6nHGKMtgZYVcBgw34BG9JSjWFC/RSSWYq40A8dWfuGMFqTI1r76+8vwvUnV+K8wJs3qO
 TnkJGLkoDcdml+KxQHvyQ/usEOMsOEWNTHh7z1EhOPV0qOVPDdjpioNzr/WN02g7O/d8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJa2i-0007OB-Nb; Wed, 01 Apr 2020 09:52:16 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJa2i-0002ft-GN; Wed, 01 Apr 2020 09:52:16 +0000
Subject: Re: [XEN PATCH v4 00/18] xen: Build system improvements
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <af3cf8c6-6915-44e9-5614-3c0dcc31c6a5@xen.org>
Date: Wed, 1 Apr 2020 10:52:13 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-1-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Tim Deegan <tim@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Anthony,

On 31/03/2020 11:30, Anthony PERARD wrote:
> Anthony PERARD (18):
>    xen/arm: Rename all early printk macro
>    xen/arm: Configure early printk via Kconfig
>    build,arm: Fix deps check of head.o

I have merged the first 3 patches.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 09:53:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 09:53:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJa46-0006Vc-BI; Wed, 01 Apr 2020 09:53:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJa44-0006VV-Nb
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 09:53:40 +0000
X-Inumbo-ID: aa2bc100-73fe-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id aa2bc100-73fe-11ea-9e09-bc764e2007e4;
 Wed, 01 Apr 2020 09:53:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=21/R/2NJ0AKJSZg398rGKMrjdex9rZryeAqLLM+m8Ks=; b=D7xXYDcLu8tWdTBn+VlaKKYK8b
 h/zVWbRuBk+W1cZWOpUfCVfdCRK1tkS5QFzNJN+1E9W3Y4yYUb6v3smmjiHSDuaoKrD5p4Mus0N6h
 sQ/kUgATVo2v2z286fFrVgVbPcryy3tZItaTFlilzZuu1vcnveSRVtr59hpeH2yNEb/Q=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJa42-0007Pw-97; Wed, 01 Apr 2020 09:53:38 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJa42-0002iD-34; Wed, 01 Apr 2020 09:53:38 +0000
Subject: Re: [PATCH 2/8] xen/public: sysctl: set_parameter.params and
 debug.keys should be const
To: Jan Beulich <jbeulich@suse.com>
References: <20200330192157.1335-1-julien@xen.org>
 <20200330192157.1335-3-julien@xen.org>
 <81a7f1a5-6fce-a996-9bcb-0fe6dfe05e30@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <e4ded9cd-069e-bceb-d183-3756b9825161@xen.org>
Date: Wed, 1 Apr 2020 10:53:35 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <81a7f1a5-6fce-a996-9bcb-0fe6dfe05e30@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, dfaggioli@suse.com,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 31/03/2020 08:30, Jan Beulich wrote:
> On 30.03.2020 21:21, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> The fields set_parameter.params and debug.keys should never be modified
>> by the hypervisor. So mark them as const.
>>
>> Signed-off-by: Julien Grall <jgrall@amazon.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
>> I am not entirely sure whether we should bump the systcl version for
>> this change. Any thoughts?
> 
> No, it should be left as is - it's about _binary_ compatibility (e.g.
> if structure layout changes, or a sub-function gets dropped). The
> need to potentially address build issues resulting from changes like
> the one here isn't covered by it, but by the __XEN__ / __XEN_TOOLS__
> conditional at the top of the header.

Thank you for the examplanation! I will commit the patch.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 09:54:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 09:54:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJa4s-0006Zl-LD; Wed, 01 Apr 2020 09:54:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=uymO=5R=arm.com=bertrand.marquis@srs-us1.protection.inumbo.net>)
 id 1jJa4q-0006Zb-NL
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 09:54:28 +0000
X-Inumbo-ID: c58c95e6-73fe-11ea-b58d-bc764e2007e4
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown
 [40.107.20.71]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c58c95e6-73fe-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 09:54:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; 
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=j24FPQXR4F2jm4JCTgokRThyryEAd36tC+6O6UQdFzs=;
 b=0sHBPf1zPYM9ZMAaH1u94ZtcqeC9RnCU1WK7DL+Z2gd1aWp17uA19j66WagtRCsCD/qbRaiJ+hz4CpORad9VJjBmdGzbqFgXim737PMKGpl/a3gLwDD3twYVfchTXNoshLW1b3NSnq6kpIijpCAp7XA3wtr8z/RRo76YIZ53lMI=
Received: from AM5PR06CA0014.eurprd06.prod.outlook.com (2603:10a6:206:2::27)
 by VI1PR08MB4381.eurprd08.prod.outlook.com (2603:10a6:803:f8::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Wed, 1 Apr
 2020 09:54:24 +0000
Received: from AM5EUR03FT023.eop-EUR03.prod.protection.outlook.com
 (2603:10a6:206:2:cafe::55) by AM5PR06CA0014.outlook.office365.com
 (2603:10a6:206:2::27) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20 via Frontend
 Transport; Wed, 1 Apr 2020 09:54:24 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was
 verified) header.d=armh.onmicrosoft.com;lists.xenproject.org;
 dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AM5EUR03FT023.mail.protection.outlook.com (10.152.16.169) with
 Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2856.17 via Frontend Transport; Wed, 1 Apr 2020 09:54:23 +0000
Received: ("Tessian outbound af37c2b81632:v50");
 Wed, 01 Apr 2020 09:54:23 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 96f851ec2abb08c7
X-CR-MTA-TID: 64aa7808
Received: from 185bbbe95441.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 9222CF38-2DAB-4E77-853D-A4A1E8CF6FBE.1; 
 Wed, 01 Apr 2020 09:54:18 +0000
Received: from EUR03-AM5-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 185bbbe95441.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 01 Apr 2020 09:54:18 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=hSUs+xzulwYVgFHe8bGlH9Hj3CHCcdoK+6IFJjqspm6O/muWGWZQDtiusbGyx/wVxRNUQJ2v5HPDGobSye81dqKMF3DZRfODH2SfDaE+7toyBJpkiZXV+8oWJg9MSQWwlv2ad3melS+OVqPBAlgxZWzVUcmygZwdBLEz4Sr7ptesJr8UU5AWruQuoPfmttpdoA3Q+QIntVFVsbk++ENsQr3bxmf27YDMsSLdKktKAAm8tBqOBSozB2ULaTojUUHuicZ3Ak7uTXV/r5D/dgYmHs/52aljPNKqK1EFj1UHdJeohphpWXuXq8fDtqe+gu6k1FmqKfUA1ZXJRS6lB48ChQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=j24FPQXR4F2jm4JCTgokRThyryEAd36tC+6O6UQdFzs=;
 b=F3COL1FB5Jcm7bnbcN3MboCrAtPSWjDK5S1U7GzjyDYLGN9UZ+j5wtZiBnd1w6krh3TCEcls3MQEKLdH090OEwqhg+dy9AjNcYHNAlBap4J/3pic3G1hkjNwsX6Sr6RiCLQ6KgWSUK/cRJgADTrZGyVMH26fvlxE7fl1n7gIb23DOC99YjqRKqBlWDkw3PdTbPOxMGo/TCnzFfK+RQ/H45zoJjpBirvrVAPfTzDI9arxdHRoJ97OZtqpw/huCXePt4ufKG+Rl3oW8tITp5PFroWyea3u5wIz+ZuPhld7yNhwYxFqe4vjx/Lpfgwk+WmW9+0EIBtaKGb8Wuog3MEfaA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; 
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=j24FPQXR4F2jm4JCTgokRThyryEAd36tC+6O6UQdFzs=;
 b=0sHBPf1zPYM9ZMAaH1u94ZtcqeC9RnCU1WK7DL+Z2gd1aWp17uA19j66WagtRCsCD/qbRaiJ+hz4CpORad9VJjBmdGzbqFgXim737PMKGpl/a3gLwDD3twYVfchTXNoshLW1b3NSnq6kpIijpCAp7XA3wtr8z/RRo76YIZ53lMI=
Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (20.178.46.80) by
 DB7PR08MB3562.eurprd08.prod.outlook.com (20.177.120.88) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2856.20; Wed, 1 Apr 2020 09:54:16 +0000
Received: from DB7PR08MB3689.eurprd08.prod.outlook.com
 ([fe80::94d7:a242:40b4:cfb5]) by DB7PR08MB3689.eurprd08.prod.outlook.com
 ([fe80::94d7:a242:40b4:cfb5%6]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020
 09:54:16 +0000
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Topic: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Index: AQHWB8CUPtV45V7pfkaBDuUahGESj6hj8BaAgAAXawA=
Date: Wed, 1 Apr 2020 09:54:16 +0000
Message-ID: <A33FEB65-F844-4CA6-BAE0-F0C881CFD381@arm.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
In-Reply-To: <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Authentication-Results-Original: spf=none (sender IP is )
 smtp.mailfrom=Bertrand.Marquis@arm.com; 
x-originating-ip: [82.24.250.194]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: ea31819b-1467-4af5-50d0-08d7d622a870
x-ms-traffictypediagnostic: DB7PR08MB3562:|VI1PR08MB4381:
X-Microsoft-Antispam-PRVS: <VI1PR08MB43813BFE95CF1E63FCB52EFB9DC90@VI1PR08MB4381.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 03607C04F0
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en;
 SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com;
 PTR:; CAT:NONE; SFTY:;
 SFS:(10009020)(4636009)(376002)(39860400002)(396003)(346002)(136003)(366004)(2906002)(186003)(6512007)(8676002)(6506007)(54906003)(2616005)(81156014)(4326008)(36756003)(86362001)(478600001)(316002)(81166006)(53546011)(91956017)(6916009)(64756008)(33656002)(66476007)(66946007)(8936002)(26005)(6486002)(71200400001)(66556008)(66446008)(5660300002)(76116006);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: cIEymwj0fiLqhUon0iYjs61Biyp5htDQCUQWDnVF4bsB1yaVzOxkdaxYVOdoiP6YltbLtE7tw1tTz9iwAn95ljmJTX7mOuJsDJ+ssyN2E67pVv7CYgicakEC8xiacS2QhUoxXDgSLSFMmgtp/GYEPaODvERgnkVVJ6Jk3KbLbNuay9TIq+vjwFpK5Vh4xmuFmGhVX5Q6q/IoqZk6Weukpzn1ydexxkTMskCaZ1ExLpOMOAzdumdRf3HMwwWpZurPi5c+7DRDVh4p6Ye+mn9Q7mpBItzXLwlRHzMJPxOOGUM0YvvoHL5y9+RRi38AmRlXtPocDVFQiBnP+rMumKkPyIB93fF8hIEOty/D3rJ9PB1b0VdcAgUBcAydI9KXz1INTgyiYhJYGQ92RQutb7Gbb4NA5TJsMZP1iTT9znd0r3frEns5R4C6axxDJfTnlteq
x-ms-exchange-antispam-messagedata: cwDf4YP0b8g1qjLIcn9xYdG/qZL5vetr9NkHrAPwcc06rEf9lKLOJZUXaAtQlDoAGtcMnmu1I9tdM6rsNlIQkghibN0EXmxdRfxphTfI8ljcm7skjCkuIPEu/CxpdiUp1MIrkuto3rBd903v9aL5dQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
 boundary="_000_A33FEB65F8444CA6BAE0F0C881CFD381armcom_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3562
Original-Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=Bertrand.Marquis@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT023.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;
 IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;
 PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:;
 SFS:(10009020)(4636009)(396003)(136003)(376002)(39860400002)(346002)(46966005)(36906005)(81156014)(336012)(54906003)(47076004)(26826003)(186003)(316002)(2616005)(53546011)(6862004)(6506007)(81166006)(82740400003)(26005)(6486002)(478600001)(36756003)(45080400002)(86362001)(5660300002)(2906002)(6512007)(33656002)(70206006)(70586007)(8676002)(8936002)(356004)(4326008);
 DIR:OUT; SFP:1101; 
X-MS-Office365-Filtering-Correlation-Id-Prvs: b08cec5e-8eba-4728-74dc-08d7d622a404
X-Forefront-PRVS: 03607C04F0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: C8hQToYeU+YzsqvU6wr5sEdCl7IA51yWkSNeB+MAQE3iW4jhoSfMAmcW9ynfni9uOdKaWNh1BlNxy6UKMwjh/KkN7l7aXl0xp9Mptx/hmMLHanHzfJjUnGOI7roF8WwvnANzSPsnRrtFAlUd0tLdbpeBV+nWJJOhCLNUzHtT5feGruMlZGh6XjJe5d1N4dKE/xkBPFdoFjhTGlSlbmcr5HftEmQ/OwihAZOGDgML/5DQ7StaA7aCuwq7cVXKxURhrYH7gVJCgBQvqO4MqmR2Kna8rR3kqu4Tkp7ao3gyz82qXZ2ThhixOoMh3zfSp64VZnXBoWXcRcNVp0f19LbNognibiwuzBhfnkLbhXggCy+ndjXBc9OXMn22ALwptuaWGfKh3ioWqQcNsS5WWjjvwJJRLJLcey1u9Wyt108mGkkwNzzf0mq2it42uRh5B7RS5WfjWEAx5V3CZ38OmmwCbALOnO5W7vlAc7pO/hYQf6YSM2kINygpCHXKlH5QTYG4xRhQfVFmmDaSTO9/5Po2vQ==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2020 09:54:23.8508 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ea31819b-1467-4af5-50d0-08d7d622a870
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];
 Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4381
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Wei Xu <xuwei5@hisilicon.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 nd <nd@arm.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--_000_A33FEB65F8444CA6BAE0F0C881CFD381armcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



On 1 Apr 2020, at 09:30, Julien Grall <julien@xen.org<mailto:julien@xen.org=
>> wrote:



On 01/04/2020 01:57, Stefano Stabellini wrote:
On Mon, 30 Mar 2020, Julien Grall wrote:
Hi Stefano,

On 30/03/2020 17:35, Stefano Stabellini wrote:
On Sat, 28 Mar 2020, Julien Grall wrote:
qHi Stefano,

On 27/03/2020 02:34, Stefano Stabellini wrote:
This is a simple implementation of GICD_ICACTIVER / GICD_ISACTIVER
reads. It doesn't take into account the latest state of interrupts on
other vCPUs. Only the current vCPU is up-to-date. A full solution is
not possible because it would require synchronization among all vCPUs,
which would be very expensive in terms or latency.

Your sentence suggests you have number showing that correctly emulating
the
registers would be too slow. Mind sharing them?

No, I don't have any numbers. Would you prefer a different wording or a
better explanation? I also realized there is a typo in there (or/of).
Let me start with I think correctness is more important than speed.
So I would have expected your commit message to contain some fact why
synchronization is going to be slow and why this is a problem.

To give you a concrete example, the implementation of set/way instructions =
are
really slow (it could take a few seconds depending on the setup). However,
this was fine because not implementing them correctly would have a greater
impact on the guest (corruption) and they are not used often.

I don't think the performance in our case will be in same order magnitude. =
It
is most likely to be in the range of milliseconds (if not less) which I thi=
nk
is acceptable for emulation (particularly for the vGIC) and the current use=
s.
Writing on the mailing list some of our discussions today.
Correctness is not just in terms of compliance to a specification but it
is also about not breaking guests. Introducing latency in the range of
milliseconds, or hundreds of microseconds, would break any latency
sensitive workloads. We don't have numbers so we don't know for certain
the effect that your suggestion would have.

You missed part of the discussion. I don't disagree that latency is importa=
nt. However, if an implementation is only 95% reliable, then it means 5% of=
 the time your guest may break (corruption, crash, deadlock...). At which p=
oint the latency is the last of your concern.

It would be interesting to have those numbers, and I'll add to my TODO
list to run the experiments you suggested, but I'll put it on the
back-burner (from a Xilinx perspective it is low priority as no
customers are affected.)

How about we get a correct implementation merge first and then discuss abou=
t optimization? This would allow the community to check whether there are a=
ctually noticeable latency in their workload.

Hi,

I am not sure that pushing something with a performance impact to later fix=
 it is the right approach here.

The patch is an improvement compared to the current code and it can be furt=
her improved later to handle more cases (other cores).

If we really have to sync all vCPUs here, this will cost a lot and the resu=
lt will still be the status in the past in fact because nothing will make s=
ure that at the point the guest gets back the value it is still valid.

Cheers

--
Bertrand


--_000_A33FEB65F8444CA6BAE0F0C881CFD381armcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <B244860F5AA4814EAFA57755EAB55673@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break:=
 after-white-space;" class=3D"">
<br class=3D"">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On 1 Apr 2020, at 09:30, Julien Grall &lt;<a href=3D"mailto=
:julien@xen.org" class=3D"">julien@xen.org</a>&gt; wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D""><br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-w=
eight: normal; letter-spacing: normal; text-align: start; text-indent: 0px;=
 text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text=
-stroke-width: 0px; text-decoration: none;" class=3D"">
<br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: normal; l=
etter-spacing: normal; text-align: start; text-indent: 0px; text-transform:=
 none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0=
px; text-decoration: none;" class=3D"">
<span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size=
: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal;=
 letter-spacing: normal; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width:=
 0px; text-decoration: none; float: none; display: inline !important;" clas=
s=3D"">On
 01/04/2020 01:57, Stefano Stabellini wrote:</span><br style=3D"caret-color=
: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal=
; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: non=
e;" class=3D"">
<blockquote type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px;=
 font-style: normal; font-variant-caps: normal; font-weight: normal; letter=
-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration=
: none;" class=3D"">
On Mon, 30 Mar 2020, Julien Grall wrote:<br class=3D"">
<blockquote type=3D"cite" class=3D"">Hi Stefano,<br class=3D"">
<br class=3D"">
On 30/03/2020 17:35, Stefano Stabellini wrote:<br class=3D"">
<blockquote type=3D"cite" class=3D"">On Sat, 28 Mar 2020, Julien Grall wrot=
e:<br class=3D"">
<blockquote type=3D"cite" class=3D"">qHi Stefano,<br class=3D"">
<br class=3D"">
On 27/03/2020 02:34, Stefano Stabellini wrote:<br class=3D"">
<blockquote type=3D"cite" class=3D"">This is a simple implementation of GIC=
D_ICACTIVER / GICD_ISACTIVER<br class=3D"">
reads. It doesn't take into account the latest state of interrupts on<br cl=
ass=3D"">
other vCPUs. Only the current vCPU is up-to-date. A full solution is<br cla=
ss=3D"">
not possible because it would require synchronization among all vCPUs,<br c=
lass=3D"">
which would be very expensive in terms or latency.<br class=3D"">
</blockquote>
<br class=3D"">
Your sentence suggests you have number showing that correctly emulating<br =
class=3D"">
the<br class=3D"">
registers would be too slow. Mind sharing them?<br class=3D"">
</blockquote>
<br class=3D"">
No, I don't have any numbers. Would you prefer a different wording or a<br =
class=3D"">
better explanation? I also realized there is a typo in there (or/of).<br cl=
ass=3D"">
</blockquote>
Let me start with I think correctness is more important than speed.<br clas=
s=3D"">
So I would have expected your commit message to contain some fact why<br cl=
ass=3D"">
synchronization is going to be slow and why this is a problem.<br class=3D"=
">
<br class=3D"">
To give you a concrete example, the implementation of set/way instructions =
are<br class=3D"">
really slow (it could take a few seconds depending on the setup). However,<=
br class=3D"">
this was fine because not implementing them correctly would have a greater<=
br class=3D"">
impact on the guest (corruption) and they are not used often.<br class=3D""=
>
<br class=3D"">
I don't think the performance in our case will be in same order magnitude. =
It<br class=3D"">
is most likely to be in the range of milliseconds (if not less) which I thi=
nk<br class=3D"">
is acceptable for emulation (particularly for the vGIC) and the current use=
s.<br class=3D"">
</blockquote>
Writing on the mailing list some of our discussions today.<br class=3D"">
Correctness is not just in terms of compliance to a specification but it<br=
 class=3D"">
is also about not breaking guests. Introducing latency in the range of<br c=
lass=3D"">
milliseconds, or hundreds of microseconds, would break any latency<br class=
=3D"">
sensitive workloads. We don't have numbers so we don't know for certain<br =
class=3D"">
the effect that your suggestion would have.<br class=3D"">
</blockquote>
<br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: normal; l=
etter-spacing: normal; text-align: start; text-indent: 0px; text-transform:=
 none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0=
px; text-decoration: none;" class=3D"">
<span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size=
: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal;=
 letter-spacing: normal; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width:=
 0px; text-decoration: none; float: none; display: inline !important;" clas=
s=3D"">You
 missed part of the discussion. I don't disagree that latency is important.=
 However, if an implementation is only 95% reliable, then it means 5% of th=
e time your guest may break (corruption, crash, deadlock...). At which poin=
t the latency is the last of your
 concern.</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-w=
eight: normal; letter-spacing: normal; text-align: start; text-indent: 0px;=
 text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text=
-stroke-width: 0px; text-decoration: none;" class=3D"">
<br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: normal; l=
etter-spacing: normal; text-align: start; text-indent: 0px; text-transform:=
 none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0=
px; text-decoration: none;" class=3D"">
<blockquote type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px;=
 font-style: normal; font-variant-caps: normal; font-weight: normal; letter=
-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration=
: none;" class=3D"">
It would be interesting to have those numbers, and I'll add to my TODO<br c=
lass=3D"">
list to run the experiments you suggested, but I'll put it on the<br class=
=3D"">
back-burner (from a Xilinx perspective it is low priority as no<br class=3D=
"">
customers are affected.)<br class=3D"">
</blockquote>
<br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: normal; l=
etter-spacing: normal; text-align: start; text-indent: 0px; text-transform:=
 none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0=
px; text-decoration: none;" class=3D"">
<span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size=
: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal;=
 letter-spacing: normal; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width:=
 0px; text-decoration: none; float: none; display: inline !important;" clas=
s=3D"">How
 about we get a correct implementation merge first and then discuss about o=
ptimization? This would allow the community to check whether there are actu=
ally noticeable latency in their workload.</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;=
" class=3D"">
</div>
</blockquote>
<div><br class=3D"">
</div>
<div>Hi,</div>
<div><br class=3D"">
</div>
<div>I am not sure that pushing something with a performance impact to late=
r fix it is the right approach here.</div>
<div><br class=3D"">
</div>
<div>The patch is an improvement compared to the current code and it can be=
 further improved later to handle more cases (other cores).</div>
<div><br class=3D"">
</div>
<div>If we really have to sync all vCPUs here, this will cost a lot and the=
 result will still be the status in the past in fact because nothing will m=
ake sure that at the point the guest gets back the value it is still valid.=
</div>
<div><br class=3D"">
</div>
<div>Cheers</div>
<div><br class=3D"">
</div>
<div>--</div>
<div>Bertrand</div>
<div><br class=3D"">
</div>
</div>
</body>
</html>

--_000_A33FEB65F8444CA6BAE0F0C881CFD381armcom_--


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 10:14:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 10:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJaO4-0008UO-TH; Wed, 01 Apr 2020 10:14:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=PyEw=5R=nxp.com=andrei.cherechesu@srs-us1.protection.inumbo.net>)
 id 1jJaO3-0008UH-Nd
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 10:14:20 +0000
X-Inumbo-ID: 8b099f2e-7401-11ea-ba8d-12813bfff9fa
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (unknown
 [40.107.3.47]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8b099f2e-7401-11ea-ba8d-12813bfff9fa;
 Wed, 01 Apr 2020 10:14:17 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=UbJGWT0qwPSmnsvSdUE8H4EPX6R5FEPnxljgFWinDLM6wPchAb8siFEHSydkNoro9S73ttBrje5zqh2ibEDLKC7NmG8WBzHgGC0vkT8HV56yE0z+AVB0wIx0AX8znSwWytZPKogYiuCAHemtgb0CwA66gRTImrNVNMtF3OE0vGwkH+aktLD+SF8W7Of3r/7Tgiz2DIpenhg8kFTtpSpjppZV0PZSWooXNCqZAvxB938oQ8RE5l+TrBBipY0GBe05krZbRsfX2mjhVeCFpkLw/faKADXHsDga1Eso7Ci5yqnac3CbIHdgchTemC9KXGQa3v1Edp/S8qrfXuxm5zjGfg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SmoWeB1fzXKECWW1aepoOQ9+RXJTKTh1gm2beSo16o8=;
 b=RjvVVzjmRWkgubTJgTk8+Il9lvx1R+1+fbPRg18r77gy3EyHGFbkk7kHnSrjKktsll0aJctLvIDqntnIPUlab42ARpFMAd3knFQhZHH6fRA0CjFG/A23UbBNLbjADUD4BNt1SO0lQ+YC82oXF646VeRjXcwXsD6oeebXbESRRw34/pChuE9UFAgkw9cFvpF7Wm8TRbVw3cV2oElsu9kPlDHN19oXFqIMy7410sHI0fA1loobNNgzb6b5k+MGLLeglZrCtfk48r+GeURF6Axn1bnfq3Jox6GNQH+Cw0YBn0B4e9orr0oy3jpHP3e0ADAlHCA3RX7aHmeeMOnHE6W75A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass
 header.d=nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SmoWeB1fzXKECWW1aepoOQ9+RXJTKTh1gm2beSo16o8=;
 b=lzYI696iEE+IZVuQ/zQ80jpQSK6xDgrYUdCmHG6vrzqy18o9CpKnLMSn8aTS5fDCoamkxyBNQeKTqbZUtc/oGBhYEF0vWeQmlcXlpLdG/zsZ3Du3CVIYtJa0MSika815ZKjXxXmwIt67EE9FSWJLGgvvfDKEpsIhLmKN4xjzOrM=
Received: from VI1PR04MB5056.eurprd04.prod.outlook.com (20.177.50.141) by
 VI1PR04MB7181.eurprd04.prod.outlook.com (10.186.158.88) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2856.20; Wed, 1 Apr 2020 10:14:14 +0000
Received: from VI1PR04MB5056.eurprd04.prod.outlook.com
 ([fe80::4494:fca6:829e:8fbb]) by VI1PR04MB5056.eurprd04.prod.outlook.com
 ([fe80::4494:fca6:829e:8fbb%3]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020
 10:14:14 +0000
From: Andrei Cherechesu <andrei.cherechesu@nxp.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second
 stage MMU.
Thread-Topic: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second
 stage MMU.
Thread-Index: AdYIDkP0tQYlxDAYTOaajGQHdLFSyw==
Date: Wed, 1 Apr 2020 10:14:14 +0000
Message-ID: <VI1PR04MB505609C8A448B9FF84EDD667F9C90@VI1PR04MB5056.eurprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=andrei.cherechesu@nxp.com; 
x-originating-ip: [78.97.145.157]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 03eb01b5-d456-4759-02d2-08d7d6256e4b
x-ms-traffictypediagnostic: VI1PR04MB7181:
x-microsoft-antispam-prvs: <VI1PR04MB7181FFFEAE409DD9BA4AD0B1F9C90@VI1PR04MB7181.eurprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:VI1PR04MB5056.eurprd04.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10009020)(4636009)(366004)(39860400002)(376002)(346002)(136003)(396003)(33656002)(52536014)(66446008)(966005)(8676002)(8936002)(64756008)(66556008)(66946007)(76116006)(5660300002)(2906002)(66476007)(9686003)(6506007)(44832011)(4326008)(186003)(26005)(316002)(54906003)(81166006)(7696005)(86362001)(55016002)(478600001)(81156014)(6916009)(71200400001)(10126625002);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: t5x/A6NratBnfYbDIGj5fYPiAw8SeQG8aucP/zlYhrdkflWrkWJv68VIxDZwE/ftldNXYvGJapCKsBl3mqNipJTrKLAKMsdVdZZmmuZGAOWZx1udjOcY8me5brHPc/QdcI3nq19zOlGcgrfIX5kqrAKNMpf9paY+jYjVYg+lL2oBd+dM29K7eNs9EjJipBtKfRPf4TzRfZFx2ZT1JOFPEmDGG8/7p1y4jmyr2xd0KcGvVtn9m42c2QNIiQJleP3qgwVUBw6SoYI91o29QqbJ2qTq5wLZNQcUOso2vjo2xV2emnGnS+j7V5ls34/Zl9OCdQ+dx0p7QgWp9UM1KF3Q5dI6m3zRrvRGVfW7W3oaELNON6sEY6lhOjUuPTKpupEE1InvJ52luiA0CTuR1dd7zwnzZ05QpGnxV0rEwmfyTy2pvtBogD1SBzCzUnxcA36+Pl/+tokT6Xy2vr/y4lJKVWzH6MweKmCQ6CgR8nyVlL+R3ymJkNnhy6WSOB6K0gckXuU2kmKiBeFf1KhFNPRVYd+5Edpw3b1tpwjLmRGYvMZe44sdBS9flXNFJBH+WFqUj5SLqYlOoK3T65dQRxFoKQ==
x-ms-exchange-antispam-messagedata: /UsFTZkrRzvETjUUxq6/dd5/pjcuwyHy1DMdsykz91dDjAQ6jGSaw6m4mbewaRawJGG8C1rtDr0m19PtfzPIcMEBvi/SJ/U2ifU7q9tNkYYQ3fY0NdXK1e1YaavND956B0xqxHCbd1RILWMAuOuysw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 03eb01b5-d456-4759-02d2-08d7d6256e4b
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 10:14:14.7738 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ly1RnI2SAgzUbXYe5EJyuJySE5JPC7eCFQjwdfxOeVu2VNQ5QVWxgAaqWi2Pq1aWJbeOOs/wbdKJxJFAYCZVSUw5iDK0bcD0CHQ1j632u18=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB7181
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

And thanks for your help.

> Great to hear!
>=20
>=20
> > However, I am encountering another problem now: in Dom0 and in=20
> > dom0less-booted DomUs, I cannot use /dev/hvc0.
>=20
> For dom0less-booted DomUs it is normal because they don't get a PV consol=
e,
> they get an emulated PL011 UART instead.  Make sure to have a "vpl011" ta=
g in
> device tree to enable it (ImageBuilder generates it by default.) The devi=
ce
> name is usually ttyAMA0.

Ok, understood. I had my vpl011 tag in the dom0less DomUs nodes in the DT,
so that's not the problem. I am able to see DomUs boot prompt when booting
dom0less. The problem is after DomU boots, that I am not able to switch to
its console from Dom0, in order to be able to log in.

> > Even though I'm specifying "console=3Dhvc0" in dom0-bootargs, when dom0=
=20
> > finishes booting, it looks like I cannot use the getty spawned on /dev/=
hvc0.
> >
> > This is the end of the boot log:
> > [    2.947845] random: rngd: uninitialized urandom read (4 bytes read)
> > [    2.958415] random: rngd: uninitialized urandom read (4 bytes read)
> > [    2.965452] random: rngd: uninitialized urandom read (2500 bytes rea=
d)
> > .
> > [    2.972410] random: crng init done
> > Starting OpenBSD Secure Shell server: sshd done.
> > Starting /usr/sbin/xenstored...
> > Setting domain 0 name, domid and JSON config...
> > Done setting up Dom0
> > Starting xenconsoled...
> > Starting QEMU as disk backend for dom0 Starting domain watchdog=20
> > daemon: xenwatchdogd startup
> >
> > [done]
> >
> > Auto Linux BSP 1.0 s32g274aevb /dev/hvc0
> >
> > s32g274aevb login:
> > Auto Linux BSP 1.0 s32g274aevb /dev/ttyLF0
> >
> > s32g274aevb login:
> >
> > ----- END -----
> >
> > It seems that the getty spawned on /dev/ttyLF0 overwrites the one=20
> > spawned on /dev/hvc0. Which I do not understand, since Dom0 should not=
=20
> > have access (?) directly to ttyLF0 (the serial console device on our=20
> > boards). If I remove the line which spawns the getty on ttyLF0 from=20
> > /etc/inittab, the system hangs when waiting for the username, and it do=
es not let me type in any characters. For the record, hvc0 is added to /etc=
/securetty.
> >
> > In a system where I boot DomU via xl from Dom0, I can switch to its=20
> > console with xl console, and hvc0 works there.
> >
> > The problem that comes with this is that I can not use the CTRL-AAA=20
> > command to switch between Dom0 console and DomU console in a dom0less=20
> > case, and I cannot therefore test that the passthrough works. But at le=
ast Dom0 does not have an entry for it under /dev, anymore, and DomU boot p=
rompt tells that the driver has been registered.
>=20
> It looks like there is some kind of interference between the dom0 ttyLF0 =
driver and the Xen serial driver.
>=20
> Is your Xen UART driver marking the device as "used by Xen"? See for inst=
ance the pl011 driver, at the end of
> xen/drivers/char/pl011.c:pl011_dt_uart_init:
>=20
>     dt_device_set_used_by(dev, DOMID_XEN);
>=20
> Devices that are marked as "used by Xen" are not exposed to dom0, so you =
shouldn't see the ttyLF0 device come up in Linux at all.

I've checked my Xen UART Driver and that call is there. So ttyLF0 should be
marked for Xen to use.

I don't have any ideas why this happens.

I've attached the driver [0], if you want to take a look.

[0] https://pastebin.com/PuXi50H0

Thanks,
Andrei Cherechesu,
NXP Semiconductors



From xen-devel-bounces@lists.xenproject.org Wed Apr 01 10:49:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 10:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJawF-0002eJ-32; Wed, 01 Apr 2020 10:49:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJawD-0002eE-EI
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 10:49:37 +0000
X-Inumbo-ID: 76b748b4-7406-11ea-ba94-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 76b748b4-7406-11ea-ba94-12813bfff9fa;
 Wed, 01 Apr 2020 10:49:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=o+Cy/XYWX2FKa8A3/8SP3uYfT0FXEW+BlCdVuLQF1G4=; b=EGxU32JWsLSWV3cEQTCVFoDQT
 5j9MI7Ao0KLGBlcqHyfso7yFApNMeJxIkNoe2r8MVNQazOtpJqw5kYE7iTNgf8G6z9pCLR5CNG5gd
 NmA5Xqhnx7Fmt6Jpilu9KaNfi6+BusFMOXEPpFg97CDzVGcnRGuCV34x2wIjBxwM141BU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJaw5-00007x-LR; Wed, 01 Apr 2020 10:49:29 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJaw5-00006a-4V; Wed, 01 Apr 2020 10:49:29 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJaw5-0002uD-3v; Wed, 01 Apr 2020 10:49:29 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149277-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-coverity test] 149277: all pass - PUSHED
X-Osstest-Versions-This: xen=5af4698d98d881e786c0909b6308f04696586c49
X-Osstest-Versions-That: xen=e19b4b3b55f84e0cfcc02fe5d66965969a81c965
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 10:49:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen                  5af4698d98d881e786c0909b6308f04696586c49
baseline version:
 xen                  e19b4b3b55f84e0cfcc02fe5d66965969a81c965

Last test of basis   149162  2020-03-29 09:24:18 Z    3 days
Testing same since   149277  2020-04-01 09:29:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jason Andryuk <jandryuk@gmail.com>
  Simran Singhal <singhalsimran0@gmail.com>

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
   e19b4b3b55..5af4698d98  5af4698d98d881e786c0909b6308f04696586c49 -> coverity-tested/smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 11:37:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 11:37:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJbg2-0006cT-PK; Wed, 01 Apr 2020 11:36:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJbg2-0006cO-4X
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 11:36:58 +0000
X-Inumbo-ID: 17bf1cae-740d-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 17bf1cae-740d-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 11:36:57 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 887DEAD33;
 Wed,  1 Apr 2020 11:36:56 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH 0/5] x86/p2m: misc page add/remove adjustments
Message-ID: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Date: Wed, 1 Apr 2020 13:36:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The primary change here is patch 2, with the others being cleanup
noticed to be worthwhile along the road.

1: don't ignore p2m_remove_page()'s return value
2: don't assert that the passed in MFN matches for a remove
3: make p2m_remove_page()'s parameters type-safe
4: drop pointless nested variable from guest_physmap_add_entry()
5: use available local variable in guest_physmap_add_entry()

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 11:38:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 11:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJbhZ-0006hC-5e; Wed, 01 Apr 2020 11:38:33 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJbhY-0006h5-AG
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 11:38:32 +0000
X-Inumbo-ID: 4f901d9a-740d-11ea-baa1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4f901d9a-740d-11ea-baa1-12813bfff9fa;
 Wed, 01 Apr 2020 11:38:31 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 607E7ACCA;
 Wed,  1 Apr 2020 11:38:30 +0000 (UTC)
Subject: [PATCH 1/5] x86/p2m: don't ignore p2m_remove_page()'s return value
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Message-ID: <88aa25d4-9772-8a2b-48c4-c0138ef000b9@suse.com>
Date: Wed, 1 Apr 2020 13:38:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It's not very nice to return from guest_physmap_add_entry() after
perhaps already having made some changes to the P2M, but this is pre-
existing practice in the function, and imo better than ignoring errors.

Take the liberty and replace an mfn_add() instance with a local variable
already holding the result (as proven by the check immediately ahead).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -767,8 +767,7 @@ void p2m_final_teardown(struct domain *d
     p2m_teardown_hostp2m(d);
 }
 
-
-static int
+static int __must_check
 p2m_remove_page(struct p2m_domain *p2m, unsigned long gfn_l, unsigned long mfn,
                 unsigned int page_order)
 {
@@ -973,9 +972,9 @@ guest_physmap_add_entry(struct domain *d
                 ASSERT(mfn_valid(omfn));
                 P2M_DEBUG("old gfn=%#lx -> mfn %#lx\n",
                           gfn_x(ogfn) , mfn_x(omfn));
-                if ( mfn_eq(omfn, mfn_add(mfn, i)) )
-                    p2m_remove_page(p2m, gfn_x(ogfn), mfn_x(mfn_add(mfn, i)),
-                                    0);
+                if ( mfn_eq(omfn, mfn_add(mfn, i)) &&
+                     (rc = p2m_remove_page(p2m, gfn_x(ogfn), mfn_x(omfn), 0)) )
+                    goto out;
             }
         }
     }
@@ -997,6 +996,7 @@ guest_physmap_add_entry(struct domain *d
         }
     }
 
+out:
     p2m_unlock(p2m);
 
     return rc;
@@ -2705,9 +2705,9 @@ int p2m_change_altp2m_gfn(struct domain
     if ( gfn_eq(new_gfn, INVALID_GFN) )
     {
         mfn = ap2m->get_entry(ap2m, old_gfn, &t, &a, 0, NULL, NULL);
-        if ( mfn_valid(mfn) )
-            p2m_remove_page(ap2m, gfn_x(old_gfn), mfn_x(mfn), PAGE_ORDER_4K);
-        rc = 0;
+        rc = mfn_valid(mfn)
+             ? p2m_remove_page(ap2m, gfn_x(old_gfn), mfn_x(mfn), PAGE_ORDER_4K)
+             : 0;
         goto out;
     }
 



From xen-devel-bounces@lists.xenproject.org Wed Apr 01 11:39:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 11:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJbiL-0006mG-G2; Wed, 01 Apr 2020 11:39:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJbiJ-0006m9-Ps
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 11:39:19 +0000
X-Inumbo-ID: 6c1cd318-740d-11ea-baa1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6c1cd318-740d-11ea-baa1-12813bfff9fa;
 Wed, 01 Apr 2020 11:39:19 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 487BAACCA;
 Wed,  1 Apr 2020 11:39:18 +0000 (UTC)
Subject: [PATCH 2/5] x86/p2m: don't assert that the passed in MFN matches for
 a remove
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Message-ID: <da2e71b2-085b-390d-69ba-9edcbbf4fcd2@suse.com>
Date: Wed, 1 Apr 2020 13:39:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

guest_physmap_remove_page() gets handed an MFN from the outside, yet
takes the necessary lock to prevent further changes to the GFN <-> MFN
mapping itself. While some callers, in particular guest_remove_page()
(by way of having called get_gfn_query()), hold the GFN lock already,
various others (most notably perhaps the 2nd instance in
xenmem_add_to_physmap_one()) don't. While it also is an option to fix
all the callers, deal with the issue in p2m_remove_page() instead:
Replace the ASSERT() by a conditional and split the loop into two, such
that all checking gets done before any modification would occur.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -773,7 +773,6 @@ p2m_remove_page(struct p2m_domain *p2m,
 {
     unsigned long i;
     gfn_t gfn = _gfn(gfn_l);
-    mfn_t mfn_return;
     p2m_type_t t;
     p2m_access_t a;
 
@@ -784,15 +783,26 @@ p2m_remove_page(struct p2m_domain *p2m,
     ASSERT(gfn_locked_by_me(p2m, gfn));
     P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn_l, mfn);
 
+    for ( i = 0; i < (1UL << page_order); )
+    {
+        unsigned int cur_order;
+        mfn_t mfn_return = p2m->get_entry(p2m, gfn_add(gfn, i), &t, &a, 0,
+                                          &cur_order, NULL);
+
+        if ( p2m_is_valid(t) &&
+             (!mfn_valid(_mfn(mfn)) || mfn + i != mfn_x(mfn_return)) )
+            return -EILSEQ;
+
+        i += (1UL << cur_order) - ((gfn_l + i) & ((1UL << cur_order) - 1));
+    }
+
     if ( mfn_valid(_mfn(mfn)) )
     {
         for ( i = 0; i < (1UL << page_order); i++ )
         {
-            mfn_return = p2m->get_entry(p2m, gfn_add(gfn, i), &t, &a, 0,
-                                        NULL, NULL);
+            p2m->get_entry(p2m, gfn_add(gfn, i), &t, &a, 0, NULL, NULL);
             if ( !p2m_is_grant(t) && !p2m_is_shared(t) && !p2m_is_foreign(t) )
                 set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
-            ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
         }
     }
     return p2m_set_entry(p2m, gfn, INVALID_MFN, page_order, p2m_invalid,


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 11:39:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 11:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJbip-0006pY-Pi; Wed, 01 Apr 2020 11:39:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJbio-0006pP-J4
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 11:39:50 +0000
X-Inumbo-ID: 7e6f9096-740d-11ea-baa1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7e6f9096-740d-11ea-baa1-12813bfff9fa;
 Wed, 01 Apr 2020 11:39:49 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BDB0DACCA;
 Wed,  1 Apr 2020 11:39:48 +0000 (UTC)
Subject: [PATCH 3/5] x86/p2m: make p2m_remove_page()'s parameters type-safe
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Message-ID: <858f22e3-0f4f-08f0-ef67-b8ce67146537@suse.com>
Date: Wed, 1 Apr 2020 13:39:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Also add a couple of blank lines.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -768,11 +768,10 @@ void p2m_final_teardown(struct domain *d
 }
 
 static int __must_check
-p2m_remove_page(struct p2m_domain *p2m, unsigned long gfn_l, unsigned long mfn,
+p2m_remove_page(struct p2m_domain *p2m, gfn_t gfn, mfn_t mfn,
                 unsigned int page_order)
 {
     unsigned long i;
-    gfn_t gfn = _gfn(gfn_l);
     p2m_type_t t;
     p2m_access_t a;
 
@@ -781,7 +780,7 @@ p2m_remove_page(struct p2m_domain *p2m,
         return 0;
 
     ASSERT(gfn_locked_by_me(p2m, gfn));
-    P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn_l, mfn);
+    P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn_x(gfn), mfn_x(mfn));
 
     for ( i = 0; i < (1UL << page_order); )
     {
@@ -790,21 +789,23 @@ p2m_remove_page(struct p2m_domain *p2m,
                                           &cur_order, NULL);
 
         if ( p2m_is_valid(t) &&
-             (!mfn_valid(_mfn(mfn)) || mfn + i != mfn_x(mfn_return)) )
+             (!mfn_valid(mfn) || !mfn_eq(mfn_add(mfn, i), mfn_return)) )
             return -EILSEQ;
 
-        i += (1UL << cur_order) - ((gfn_l + i) & ((1UL << cur_order) - 1));
+        i += (1UL << cur_order) -
+             (gfn_x(gfn_add(gfn, i)) & ((1UL << cur_order) - 1));
     }
 
-    if ( mfn_valid(_mfn(mfn)) )
+    if ( mfn_valid(mfn) )
     {
         for ( i = 0; i < (1UL << page_order); i++ )
         {
             p2m->get_entry(p2m, gfn_add(gfn, i), &t, &a, 0, NULL, NULL);
             if ( !p2m_is_grant(t) && !p2m_is_shared(t) && !p2m_is_foreign(t) )
-                set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
+                set_gpfn_from_mfn(mfn_x(mfn) + i, INVALID_M2P_ENTRY);
         }
     }
+
     return p2m_set_entry(p2m, gfn, INVALID_MFN, page_order, p2m_invalid,
                          p2m->default_access);
 }
@@ -815,9 +816,11 @@ guest_physmap_remove_page(struct domain
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int rc;
+
     gfn_lock(p2m, gfn, page_order);
-    rc = p2m_remove_page(p2m, gfn_x(gfn), mfn_x(mfn), page_order);
+    rc = p2m_remove_page(p2m, gfn, mfn, page_order);
     gfn_unlock(p2m, gfn, page_order);
+
     return rc;
 }
 
@@ -983,7 +986,7 @@ guest_physmap_add_entry(struct domain *d
                 P2M_DEBUG("old gfn=%#lx -> mfn %#lx\n",
                           gfn_x(ogfn) , mfn_x(omfn));
                 if ( mfn_eq(omfn, mfn_add(mfn, i)) &&
-                     (rc = p2m_remove_page(p2m, gfn_x(ogfn), mfn_x(omfn), 0)) )
+                     (rc = p2m_remove_page(p2m, ogfn, omfn, 0)) )
                     goto out;
             }
         }
@@ -2716,7 +2719,7 @@ int p2m_change_altp2m_gfn(struct domain
     {
         mfn = ap2m->get_entry(ap2m, old_gfn, &t, &a, 0, NULL, NULL);
         rc = mfn_valid(mfn)
-             ? p2m_remove_page(ap2m, gfn_x(old_gfn), mfn_x(mfn), PAGE_ORDER_4K)
+             ? p2m_remove_page(ap2m, old_gfn, mfn, PAGE_ORDER_4K)
              : 0;
         goto out;
     }



From xen-devel-bounces@lists.xenproject.org Wed Apr 01 11:40:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 11:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJbjJ-0007YG-61; Wed, 01 Apr 2020 11:40:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJbjH-0007Y2-Rh
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 11:40:19 +0000
X-Inumbo-ID: 901aa42a-740d-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 901aa42a-740d-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 11:40:19 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6A48EAD33;
 Wed,  1 Apr 2020 11:40:18 +0000 (UTC)
Subject: [PATCH 4/5] x86/p2m: drop pointless nested variable from
 guest_physmap_add_entry()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Message-ID: <c31cac8b-99b8-5cfd-bb8b-57ff529d34ad@suse.com>
Date: Wed, 1 Apr 2020 13:40:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

There's an outer scope rc already, and its use for the mem-sharing logic
does not conflict with its use elsewhere in the function.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -905,7 +905,6 @@ guest_physmap_add_entry(struct domain *d
         if ( p2m_is_shared(ot) )
         {
             /* Do an unshare to cleanly take care of all corner cases. */
-            int rc;
             rc = mem_sharing_unshare_page(p2m->domain, gfn_x(gfn_add(gfn, i)));
             if ( rc )
             {



From xen-devel-bounces@lists.xenproject.org Wed Apr 01 11:40:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 11:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJbjq-0007e8-H6; Wed, 01 Apr 2020 11:40:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJbjp-0007dw-9s
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 11:40:53 +0000
X-Inumbo-ID: a3f626fe-740d-11ea-baad-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a3f626fe-740d-11ea-baad-12813bfff9fa;
 Wed, 01 Apr 2020 11:40:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E60F0AD33;
 Wed,  1 Apr 2020 11:40:51 +0000 (UTC)
Subject: [PATCH 5/5] x86/p2m: use available local variable in
 guest_physmap_add_entry()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Message-ID: <3a8a7eb3-4822-0234-47de-c83973b4b5eb@suse.com>
Date: Wed, 1 Apr 2020 13:40:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The domain is being passed in - no need to obtain it from p2m->domain.
Also drop a pointless cast while touching this code anyway.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -905,7 +905,7 @@ guest_physmap_add_entry(struct domain *d
         if ( p2m_is_shared(ot) )
         {
             /* Do an unshare to cleanly take care of all corner cases. */
-            rc = mem_sharing_unshare_page(p2m->domain, gfn_x(gfn_add(gfn, i)));
+            rc = mem_sharing_unshare_page(d, gfn_x(gfn_add(gfn, i)));
             if ( rc )
             {
                 p2m_unlock(p2m);
@@ -922,8 +922,7 @@ guest_physmap_add_entry(struct domain *d
                  * Foreign domains are okay to place an event as they
                  * won't go to sleep.
                  */
-                (void)mem_sharing_notify_enomem(p2m->domain,
-                                                gfn_x(gfn_add(gfn, i)), false);
+                mem_sharing_notify_enomem(d, gfn_x(gfn_add(gfn, i)), false);
                 return rc;
             }
             omfn = p2m->get_entry(p2m, gfn_add(gfn, i),



From xen-devel-bounces@lists.xenproject.org Wed Apr 01 12:00:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 12:00:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJc2Z-00011q-Ge; Wed, 01 Apr 2020 12:00:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJc2Y-00011i-HR
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 12:00:14 +0000
X-Inumbo-ID: 57d0a670-7410-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 57d0a670-7410-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 12:00:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=TZPZs3zGS1yMEvDPHRVoJcmeiKFWg3KWANqV+OaEysY=; b=WGp+2D7xmMuidjn2ycmXfMisHf
 2uoPksTRSw5M+Ym5KdruWaZU0I06LY6gAnl04C9LJc8xgglKOgGYoz/jucUN2K2MMrfi6uFMXnvt9
 jIghZOitIH5eEODPMVscWacOKmLY5/6G7fyMFZG7xeDEni/epXK3ESiuOkaGa/niktJg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJc2S-0001XB-LQ; Wed, 01 Apr 2020 12:00:08 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJc2S-00033S-5I; Wed, 01 Apr 2020 12:00:08 +0000
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
Date: Wed, 1 Apr 2020 13:00:05 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200327185012.1795-2-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 27/03/2020 18:50, Paul Durrant wrote:
> Domain context is state held in the hypervisor that does not come under
> the category of 'HVM state' but is instead 'PV state' that is common
> between PV guests and enlightened HVM guests (i.e. those that have PV
> drivers) such as event channel state, grant entry state, etc.
> 
> To allow enlightened HVM guests to be migrated without their co-operation
> it will be necessary to transfer such state along with the domain's
> memory image, architectural state, etc. This framework is introduced for
> that purpose.
> 
> This patch adds the new public header and the low level implementation,
> entered via the domain_save() or domain_load() functions. Subsequent
> patches will introduce other parts of the framwork, and code that will

Typo: s/framwork/framework/

> make use of it within the current version of the libxc migration stream.
> 
> Signed-off-by: Paul Durrant <paul@xen.org>
> ---
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Wei Liu <wl@xen.org>
> ---
>   xen/common/Makefile       |   1 +
>   xen/common/save.c         | 262 ++++++++++++++++++++++++++++++++++++++
>   xen/include/public/save.h |  74 +++++++++++
>   xen/include/xen/save.h    | 115 +++++++++++++++++
>   4 files changed, 452 insertions(+)
>   create mode 100644 xen/common/save.c
>   create mode 100644 xen/include/public/save.h
>   create mode 100644 xen/include/xen/save.h
> 
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index e8cde65370..90553ba5d7 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -37,6 +37,7 @@ obj-y += radix-tree.o
>   obj-y += rbtree.o
>   obj-y += rcupdate.o
>   obj-y += rwlock.o
> +obj-y += save.o
>   obj-y += shutdown.o
>   obj-y += softirq.o
>   obj-y += sort.o
> diff --git a/xen/common/save.c b/xen/common/save.c
> new file mode 100644
> index 0000000000..bef99452d8
> --- /dev/null
> +++ b/xen/common/save.c
> @@ -0,0 +1,262 @@
> +/*
> + * save.c: Save and restore PV guest state common to all domain types.
> + *
> + * Copyright Amazon.com Inc. or its affiliates.
> + *
> + * 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 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 <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <xen/save.h>
> +
> +struct domain_context {
> +    bool log;
> +    struct domain_save_descriptor desc;
> +    domain_copy_entry copy;

As your new framework is technically an extension of existing one, it 
would be good to explain why we diverge in the definitions.

> +    void *priv;
> +};
> +
> +static struct {
> +    const char *name;
> +    bool per_vcpu;
> +    domain_save_handler save;
> +    domain_load_handler load;
> +} handlers[DOMAIN_SAVE_CODE_MAX + 1];
> +
> +void __init domain_register_save_type(unsigned int tc, const char *name,
> +                                      bool per_vcpu,
> +                                      domain_save_handler save,
> +                                      domain_load_handler load)
> +{
> +    BUG_ON(tc > ARRAY_SIZE(handlers));
> +
> +    ASSERT(!handlers[tc].save);
> +    ASSERT(!handlers[tc].load);
> +
> +    handlers[tc].name = name;
> +    handlers[tc].per_vcpu = per_vcpu;
> +    handlers[tc].save = save;
> +    handlers[tc].load = load;
> +}
> +
> +int domain_save_entry(struct domain_context *c, unsigned int tc,
> +                      const char *name, const struct vcpu *v, void *src,

I realize that 'src' is not const because how you define copy, however I 
would rather prefer if we rework the interface to avoid to keep the 
const in the definition. This may mean to have to define two callback 
rather than one.

> +                      size_t src_len)

On 64-bit architecture, size_t would be 64-bit. But the record is only 
storing 32-bit. Would it make sense to add some sanity check in the code?

> +{
> +    int rc;
> +
> +    if ( c->log && tc != DOMAIN_SAVE_CODE(HEADER) &&
> +         tc != DOMAIN_SAVE_CODE(END) )
> +        gdprintk(XENLOG_INFO, "%pv save: %s (%lu)\n", v, name, src_len);
> +
> +    if ( !IS_ALIGNED(src_len, 8) )

Why not adding an implicit padding? This would avoid to chase error 
during saving because the len wasn't a multiple of 8.

> +        return -EINVAL;
> +
> +    BUG_ON(tc != c->desc.typecode);
> +    BUG_ON(v->vcpu_id != c->desc.instance);

Does the descriptor really need to be filled by domain_save()? Can't it 
be done here, so we can avoid the two BUG_ON()s?

> +    c->desc.length = src_len;
> +
> +    rc = c->copy(c->priv, &c->desc, sizeof(c->desc));
> +    if ( rc )
> +        return rc;
> +
> +    return c->copy(c->priv, src, src_len);
> +}
> +
> +int domain_save(struct domain *d, domain_copy_entry copy, void *priv,
> +                unsigned long mask, bool dry_run)
> +{
> +    struct domain_context c = {
> +        .copy = copy,
> +        .priv = priv,
> +        .log = !dry_run,
> +    };
> +    struct domain_save_header h = {
> +        .magic = DOMAIN_SAVE_MAGIC,
> +        .version = DOMAIN_SAVE_VERSION,
> +    };
> +    struct domain_save_header e;
> +    unsigned int i;
> +    int rc;
> +
> +    ASSERT(d != current->domain);
> +
> +    if ( d->is_dying )
> +        return -EINVAL;
> +
> +    domain_pause(d);
> +
> +    c.desc.typecode = DOMAIN_SAVE_CODE(HEADER);
> +
> +    rc = DOMAIN_SAVE_ENTRY(HEADER, &c, d->vcpu[0], &h, sizeof(h));
> +    if ( rc )
> +        goto out;
> +
> +    for ( i = 0; i < ARRAY_SIZE(handlers); i++ )

AFAIU, with this solution, if there are dependency between records, the 
dependencies will have to a lower "index". I think we may have some 
dependency with guest transparent migration such as we need to restore 
the event ABI before restoring the event channels.

Should we rely on the index for the dependency?

In any case, I think we want to document it.

> +    {
> +        domain_save_handler save = handlers[i].save;
> +
> +        if ( (mask && !test_bit(i, &mask)) || !save )

The type of mask suggests it is not possible to have more than 32 
different types of record if we wanted to be arch agnostic. Even if we 
focus on 64-bit arch, this is only 64 records.

This is not very future proof, but might be ok if this is not exposed 
outside of the hypervisor (I haven't looked at the rest of the series 
yet). However, we at least need a BUILD_BUG_ON() in place. So please 
make sure  DOMAIN_SAVE_CODE_MAX is always less than 64.

Also what if there is a bit set in the mask and the record is not 
existing? Shouldn't we return an error?

> +            continue;
> +
> +        memset(&c.desc, 0, sizeof(c.desc));
> +        c.desc.typecode = i;
> +
> +        if ( handlers[i].per_vcpu )
> +        {
> +            struct vcpu *v;
> +
> +            for_each_vcpu ( d, v )
> +            {
> +                c.desc.instance = v->vcpu_id;
> +
> +                rc = save(v, &c, dry_run);
> +                if ( rc )
> +                    goto out;
> +            }
> +        }
> +        else
> +        {
> +            rc = save(d->vcpu[0], &c, dry_run);
> +            if ( rc )
> +                goto out;
> +        }
> +    }
> +
> +    memset(&c.desc, 0, sizeof(c.desc));
> +    c.desc.typecode = DOMAIN_SAVE_CODE(END);
> +
> +    rc = DOMAIN_SAVE_ENTRY(END, &c, d->vcpu[0], &e, 0);
> +
> + out:
> +    domain_unpause(d);
> +
> +    return rc;
> +}
> +
> +int domain_load_entry(struct domain_context *c, unsigned int tc,
> +                      const char *name, const struct vcpu *v, void *dst,
> +                      size_t dst_len, bool exact)
> +{
> +    int rc;
> +
> +    if ( c->log && tc != DOMAIN_SAVE_CODE(HEADER) &&
> +         tc != DOMAIN_SAVE_CODE(END) )
> +        gdprintk(XENLOG_INFO, "%pv load: %s (%lu)\n", v, name, dst_len);
> +
> +    BUG_ON(tc != c->desc.typecode);
> +    BUG_ON(v->vcpu_id != c->desc.instance);

Is it really warrant to crash the host? What would happen if the values 
were wrong?

> +
> +    if ( (exact ?
> +          (dst_len != c->desc.length) : (dst_len < c->desc.length)) ||

Using ternary in if is really confusing. How about:

dst_len < c->desc.length || (exact && dst_len != c->desc.length) ||

I understand that there would be two check for the exact case but I 
think it is better than a ternary.

However what is the purpose of the param 'exact'? If you set it to false 
how do you know the size you read?

> +         !IS_ALIGNED(c->desc.length, 8) )
> +        return -EINVAL;
> +
> +    rc = c->copy(c->priv, dst, c->desc.length);
> +    if ( rc )
> +        return rc;
> +
> +    if ( !exact )
> +    {
> +        dst += c->desc.length;
> +        memset(dst, 0, dst_len - c->desc.length);
> +    }
> +
> +    return 0;
> +}
> +
> +int domain_load(struct domain *d,  domain_copy_entry copy, void *priv,
> +                unsigned long mask)
> +{
> +    struct domain_context c = {
> +        .copy = copy,
> +        .priv = priv,
> +        .log = true,
> +    };
> +    struct domain_save_header h, e;
> +    int rc;
> +
> +    ASSERT(d != current->domain);
> +
> +    if ( d->is_dying )
> +        return -EINVAL;

What does protect you against the doing dying right after this check?

> +
> +    rc = c.copy(c.priv, &c.desc, sizeof(c.desc));
> +    if ( rc )
> +        return rc;
> +
> +    if ( c.desc.typecode != DOMAIN_SAVE_CODE(HEADER) ||
> +         c.desc.instance != 0 )
> +        return -EINVAL;
> +
> +    rc = DOMAIN_LOAD_ENTRY(HEADER, &c, d->vcpu[0], &h, sizeof(h), true);
> +    if ( rc )
> +        return rc;
> +
> +    if ( h.magic != DOMAIN_SAVE_MAGIC || h.version != DOMAIN_SAVE_VERSION )
> +        return -EINVAL;
> +
> +    domain_pause(d);
> +
> +    for (;;)
> +    {
> +        unsigned int i;
> +        domain_load_handler load;
> +        struct vcpu *v;
> +
> +        rc = c.copy(c.priv, &c.desc, sizeof(c.desc));
> +        if ( rc )
> +            break;
> +
> +        if ( c.desc.typecode == DOMAIN_SAVE_CODE(END) ) {
> +            rc = DOMAIN_LOAD_ENTRY(END, &c, d->vcpu[0], &e, 0, true);
> +            break;
> +        }
> +
> +        rc = -EINVAL;
> +        if ( c.desc.typecode >= ARRAY_SIZE(handlers) ||
> +             c.desc.instance >= d->max_vcpus )

Nothing in the documention suggests that c.desc.instance should be 0 
when the record is for the domain.

> +            break;
> +
> +        i = c.desc.typecode;
> +        load = handlers[i].load;
> +        v = d->vcpu[c.desc.instance];
> +
> +        if ( mask && !test_bit(i, &mask) )
> +        {
> +            /* Sink the data */
> +            rc = c.copy(c.priv, NULL, c.desc.length);
> +            if ( rc )
> +                break;
> +
> +            continue;
> +        }
> +
> +        rc = load ? load(v, &c) : -EOPNOTSUPP;
> +        if ( rc )
> +            break;
> +    }
> +
> +    domain_unpause(d);
> +
> +    return rc;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/public/save.h b/xen/include/public/save.h
> new file mode 100644
> index 0000000000..84981cd0f6
> --- /dev/null
> +++ b/xen/include/public/save.h
> @@ -0,0 +1,74 @@
> +/*
> + * save.h
> + *
> + * Structure definitions for common PV/HVM domain state that is held by
> + * Xen and must be saved along with the domain's memory.
> + *
> + * Copyright Amazon.com Inc. or its affiliates.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __XEN_PUBLIC_SAVE_H__
> +#define __XEN_PUBLIC_SAVE_H__
> +
> +#include "xen.h"
> +
> +/* Each entry is preceded by a descriptor */
> +struct domain_save_descriptor {
> +    uint16_t typecode;
> +    uint16_t instance;
> +    /*
> +     * Entry length not including this descriptor. Entries must be padded
> +     * to a multiple of 8 bytes to make sure descriptors remain correctly
> +     * aligned.
> +     */
> +    uint32_t length;
> +};
> +
> +/*
> + * Each entry has a type associated with it. DECLARE_DOMAIN_SAVE_TYPE
> + * binds these things together.
> + */
> +#define DECLARE_DOMAIN_SAVE_TYPE(_x, _code, _type) \
> +    struct __DOMAIN_SAVE_TYPE_##_x { _type t; char c[_code]; };
> +
> +#define DOMAIN_SAVE_TYPE(_x) \
> +    typeof (((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->t)
> +#define DOMAIN_SAVE_CODE(_x) \
> +    (sizeof (((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->c))
> +#define DOMAIN_SAVE_MASK(_x) (1u << DOMAIN_SAVE_CODE(_x))
> +
> +/* Terminating entry */
> +struct domain_save_end {};
> +DECLARE_DOMAIN_SAVE_TYPE(END, 0, struct domain_save_end);
> +
> +#define DOMAIN_SAVE_MAGIC   0x53415645
> +#define DOMAIN_SAVE_VERSION 0x00000001
> +
> +/* Initial entry */
> +struct domain_save_header {
> +    uint32_t magic;             /* Must be DOMAIN_SAVE_MAGIC */
> +    uint32_t version;           /* Save format version */

Would it make sense to have the version of Xen in the stream?

> +};
> +DECLARE_DOMAIN_SAVE_TYPE(HEADER, 1, struct domain_save_header);
> +
> +#define DOMAIN_SAVE_CODE_MAX 1
> +
> +#endif /* __XEN_PUBLIC_SAVE_H__ */
> diff --git a/xen/include/xen/save.h b/xen/include/xen/save.h
> new file mode 100644
> index 0000000000..d5846f9e68
> --- /dev/null
> +++ b/xen/include/xen/save.h
> @@ -0,0 +1,115 @@
> +/*
> + * save.h: support routines for save/restore
> + *
> + * Copyright Amazon.com Inc. or its affiliates.
> + *
> + * 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 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 <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __XEN_SAVE_H__
> +#define __XEN_SAVE_H__
> +
> +#include <xen/sched.h>
> +#include <xen/types.h>
> +#include <xen/init.h>
> +
> +#include <public/xen.h>
> +#include <public/save.h>
> +
> +struct domain_context;
> +
> +int domain_save_entry(struct domain_context *c, unsigned int tc,
> +                      const char *name, const struct vcpu *v, void *src,
> +                      size_t src_len);
> +
> +#define DOMAIN_SAVE_ENTRY(_x, _c, _v, _src, _len)                        \
> +        domain_save_entry((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_src), \
> +                          (_len));
> +
> +int domain_load_entry(struct domain_context *c, unsigned int tc,
> +                      const char *name, const struct vcpu *v, void *dest,
> +                      size_t dest_len, bool exact);
> +
> +#define DOMAIN_LOAD_ENTRY(_x, _c, _v, _src, _len, _exact)                \
> +        domain_load_entry((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_src), \
> +                          (_len), (_exact));
> +
> +/*
> + * The 'dry_run' flag indicates that the caller of domain_save() (see
> + * below) is not trying to actually acquire the data, only the size
> + * of the data. The save handler can therefore limit work to only that
> + * which is necessary to call DOMAIN_SAVE_ENTRY() with an accurate value
> + * for '_len'.
> + */
> +typedef int (*domain_save_handler)(const struct vcpu *v,
> +                                   struct domain_context *h,
> +                                   bool dry_run);
> +typedef int (*domain_load_handler)(struct vcpu *v,
> +                                   struct domain_context *h);
> +
> +void domain_register_save_type(unsigned int tc, const char *name,
> +                               bool per_vcpu,
> +                               domain_save_handler save,
> +                               domain_load_handler load);
> +
> +#define DOMAIN_REGISTER_SAVE_RESTORE(_x, _per_vcpu, _save, _load) \
> +static int __init __domain_register_##_x##_save_restore(void)     \
> +{                                                                 \
> +    domain_register_save_type(                                    \
> +        DOMAIN_SAVE_CODE(_x),                                     \
> +        #_x,                                                      \
> +        (_per_vcpu),                                              \
> +        &(_save),                                                 \
> +        &(_load));                                                \
> +                                                                  \
> +    return 0;                                                     \
> +}                                                                 \
> +__initcall(__domain_register_##_x##_save_restore);
> +
> +/* Copy callback function */
> +typedef int (*domain_copy_entry)(void *priv, void *data, size_t len);
> +
> +/*
> + * Entry points:
> + *
> + * int domain_save(struct domain *d, domain_copy_entry copy, void *priv,
> + *                 unsigned long mask, bool dry_run);
> + * int domain_load(struct domain *d, domain_copy_entry copy, void *priv,
> + *                 unsigned long mask);
> + *
> + * copy:    This is a callback function provided by the caller that will be
> + *          used to write to (in the save case) or read from (in the load
> + *          case) the context buffer.
> + * priv:    This is a pointer that will be passed to the copy function to
> + *          allow it to identify the context buffer and the current state
> + *          of the save or load operation.
> + * mask:    This is a mask to determine which save record types should be
> + *          copied to or from the buffer.
> + *          If it is zero then all save record types will be copied.
> + *          If it is non-zero then only record types with codes
> + *          corresponding to set bits will be copied. I.e. to copy save
> + *          record 'type', set the bit in position DOMAIN_SAVE_CODE(type).
> + *          DOMAIN_SAVE_CODE(HEADER) and DOMAIN_SAVE_CODE(END) records must
> + *          always be present and thus will be copied regardless of whether
> + *          the bits in those positions are set or not.
> + * dry_run: See the comment concerning (*domain_save) above.
> + *
> + * NOTE: A convenience macro, DOMAIN_SAVE_MASK(type), is defined to support
> + *       setting bits in the mask field.
> + */
> +int domain_save(struct domain *d, domain_copy_entry copy, void *priv,
> +                unsigned long mask, bool dry_run);
> +int domain_load(struct domain *d, domain_copy_entry copy, void *priv,
> +                unsigned long mask);
> +
> +#endif /* __XEN_SAVE_H__ */
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 12:07:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 12:07:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJc9I-0001FK-Fr; Wed, 01 Apr 2020 12:07:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJc9H-0001FF-5i
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 12:07:11 +0000
X-Inumbo-ID: 506d6034-7411-11ea-bab2-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 506d6034-7411-11ea-bab2-12813bfff9fa;
 Wed, 01 Apr 2020 12:07:10 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6B9BFAE84;
 Wed,  1 Apr 2020 12:07:09 +0000 (UTC)
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: Julien Grall <julien@xen.org>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <663f4a01-168a-6ead-8447-45e005e578ce@suse.com>
Date: Wed, 1 Apr 2020 14:07:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 01.04.2020 14:00, Julien Grall wrote:
> On 27/03/2020 18:50, Paul Durrant wrote:
>> +    if ( (exact ?
>> +          (dst_len != c->desc.length) : (dst_len < c->desc.length)) ||
> 
> Using ternary in if is really confusing. How about:
> 
> dst_len < c->desc.length || (exact && dst_len != c->desc.length) ||
> 
> I understand that there would be two check for the exact case but I think it is better than a ternary.

I'm of the opposite opinion, and hence with Paul. While the alternative
you suggest is still reasonable because of the special case here, I
find it confusing / more difficult to read / follow

    if ( (a && b) || (!a && c) )

(and I've seen quite a few instances of such over time) instead of

    if ( a ? b : c )

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 12:11:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 12:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJcDt-00022Y-2M; Wed, 01 Apr 2020 12:11:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJcDs-00022T-74
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 12:11:56 +0000
X-Inumbo-ID: fa413f86-7411-11ea-bab2-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fa413f86-7411-11ea-bab2-12813bfff9fa;
 Wed, 01 Apr 2020 12:11:55 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0C640AE1C;
 Wed,  1 Apr 2020 12:11:53 +0000 (UTC)
Subject: Re: [PATCH 1/5] x86/shim: map and unmap page tables in
 replace_va_mapping
To: Hongyan Xia <hx242@xen.org>, Wei Liu <wl@xen.org>
References: <cover.1584955616.git.hongyxia@amazon.com>
 <1acfafbd8ebada1538c9e06323ef0b3bf3f6897c.1584955616.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <611d0994-27c1-1fdd-0d6b-28f67ce7e486@suse.com>
Date: Wed, 1 Apr 2020 14:11:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <1acfafbd8ebada1538c9e06323ef0b3bf3f6897c.1584955616.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.03.2020 10:41, Hongyan Xia wrote:
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -169,15 +169,19 @@ static void __init replace_va_mapping(struct domain *d, l4_pgentry_t *l4start,
>                                        unsigned long va, mfn_t mfn)
>  {
>      l4_pgentry_t *pl4e = l4start + l4_table_offset(va);
> -    l3_pgentry_t *pl3e = l4e_to_l3e(*pl4e) + l3_table_offset(va);
> -    l2_pgentry_t *pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(va);
> -    l1_pgentry_t *pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(va);
> +    l3_pgentry_t *pl3e = map_l3t_from_l4e(*pl4e) + l3_table_offset(va);
> +    l2_pgentry_t *pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(va);
> +    l1_pgentry_t *pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(va);
>      struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e));
>  
>      put_page_and_type(page);
>  
>      *pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT
>                                                        : COMPAT_L1_PROT));
> +
> +    UNMAP_DOMAIN_PAGE(pl1e);
> +    UNMAP_DOMAIN_PAGE(pl2e);
> +    UNMAP_DOMAIN_PAGE(pl3e);
>  }

I disagree to an approach like this: Why have three pending mappings
when one at a time will do? Map-read/write-unmap three times is what
you want here, even if this is more code churn.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 12:16:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 12:16:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJcI7-0002BV-Ke; Wed, 01 Apr 2020 12:16:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJcI5-0002Ay-KV
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 12:16:17 +0000
X-Inumbo-ID: 965e9738-7412-11ea-bab3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 965e9738-7412-11ea-bab3-12813bfff9fa;
 Wed, 01 Apr 2020 12:16:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=3/IAJlig/Dr1hbYxrTC5MUbHX0aYV7mOk1ur9XignHo=; b=Tk3EqzLHbp8zSPW4MYFq7X9r9b
 i0K3Wmhd5g7i1INePOv19DqegpxjIP2Kk7MbqY1hHNJDnJaFm7e8mmsZBtls3xJI8l1w2XdCtDVgY
 vq2+K87yWHlnO2QsxWSt4zNySWdLKg/heXimOHPfVWuYp/0ugUcioIG8nqra+xqQOqMw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJcI3-0001qa-EA; Wed, 01 Apr 2020 12:16:15 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJcI3-00046W-7c; Wed, 01 Apr 2020 12:16:15 +0000
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: Jan Beulich <jbeulich@suse.com>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
 <663f4a01-168a-6ead-8447-45e005e578ce@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <77e5ef68-0d1e-b2b6-6e21-273ab7b9b707@xen.org>
Date: Wed, 1 Apr 2020 13:16:13 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <663f4a01-168a-6ead-8447-45e005e578ce@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 01/04/2020 13:07, Jan Beulich wrote:
> On 01.04.2020 14:00, Julien Grall wrote:
>> On 27/03/2020 18:50, Paul Durrant wrote:
>>> +    if ( (exact ?
>>> +          (dst_len != c->desc.length) : (dst_len < c->desc.length)) ||
>>
>> Using ternary in if is really confusing. How about:
>>
>> dst_len < c->desc.length || (exact && dst_len != c->desc.length) ||
>>
>> I understand that there would be two check for the exact case but I think it is better than a ternary.
> 
> I'm of the opposite opinion, and hence with Paul. While the alternative
> you suggest is still reasonable because of the special case here, I
> find it confusing / more difficult to read / follow
> 
>      if ( (a && b) || (!a && c) )
> 
> (and I've seen quite a few instances of such over time) instead of
> 
>      if ( a ? b : c )

If the ternary was the only condition and in a single line then it would 
be okay. However, the if is split over 3 lines...

The more stuff you put in an if, then more chance you are going to 
misread/make a mistake (you likely know what I am referring about here ;)).

So if you prefer the ternary, then we should at least write 2 ifs.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 12:19:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 12:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJcLL-0002Ky-9J; Wed, 01 Apr 2020 12:19:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJcLK-0002Kt-17
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 12:19:38 +0000
X-Inumbo-ID: 0d88e66a-7413-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0d88e66a-7413-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 12:19:37 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6A805AD75;
 Wed,  1 Apr 2020 12:19:36 +0000 (UTC)
Subject: Re: [PATCH 2/5] x86_64/mm: map and unmap page tables in m2p_mapped
To: Hongyan Xia <hx242@xen.org>
References: <cover.1584955616.git.hongyxia@amazon.com>
 <9b46a0bae03107fcb192e6590234b9e882965f11.1584955616.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <a83f4eb5-e151-35a5-7e53-d6609c3fcb82@suse.com>
Date: Wed, 1 Apr 2020 14:19:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <9b46a0bae03107fcb192e6590234b9e882965f11.1584955616.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.03.2020 10:41, Hongyan Xia wrote:
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -131,27 +131,33 @@ static int m2p_mapped(unsigned long spfn)
>      unsigned long va;
>      l3_pgentry_t *l3_ro_mpt;
>      l2_pgentry_t *l2_ro_mpt;
> +    int rc = M2P_NO_MAPPED;
>  
>      va = RO_MPT_VIRT_START + spfn * sizeof(*machine_to_phys_mapping);
> -    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
> +    l3_ro_mpt = map_l3t_from_l4e(idle_pg_table[l4_table_offset(va)]);

Along the lines of what I've said for patch 1 - read the l3e
here and unmap again right away. No need for converting
"return" to "goto" further down. Same for the l2e then.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 12:23:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 12:23:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJcPD-00037O-Qy; Wed, 01 Apr 2020 12:23:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJcPC-00037J-7H
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 12:23:38 +0000
X-Inumbo-ID: 9cc41476-7413-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9cc41476-7413-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 12:23:37 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B8AD1AE71;
 Wed,  1 Apr 2020 12:23:36 +0000 (UTC)
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: Julien Grall <julien@xen.org>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
 <663f4a01-168a-6ead-8447-45e005e578ce@suse.com>
 <77e5ef68-0d1e-b2b6-6e21-273ab7b9b707@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <890e451d-3f78-466c-4780-bd58c56abfe7@suse.com>
Date: Wed, 1 Apr 2020 14:23:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <77e5ef68-0d1e-b2b6-6e21-273ab7b9b707@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 01.04.2020 14:16, Julien Grall wrote:
> Hi Jan,
> 
> On 01/04/2020 13:07, Jan Beulich wrote:
>> On 01.04.2020 14:00, Julien Grall wrote:
>>> On 27/03/2020 18:50, Paul Durrant wrote:
>>>> +    if ( (exact ?
>>>> +          (dst_len != c->desc.length) : (dst_len < c->desc.length)) ||
>>>
>>> Using ternary in if is really confusing. How about:
>>>
>>> dst_len < c->desc.length || (exact && dst_len != c->desc.length) ||
>>>
>>> I understand that there would be two check for the exact case but I think it is better than a ternary.
>>
>> I'm of the opposite opinion, and hence with Paul. While the alternative
>> you suggest is still reasonable because of the special case here, I
>> find it confusing / more difficult to read / follow
>>
>>      if ( (a && b) || (!a && c) )
>>
>> (and I've seen quite a few instances of such over time) instead of
>>
>>      if ( a ? b : c )
> 
> If the ternary was the only condition and in a single line then it would be okay. However, the if is split over 3 lines...
> 
> The more stuff you put in an if, then more chance you are going to misread/make a mistake (you likely know what I am referring about here ;)).
> 
> So if you prefer the ternary, then we should at least write 2 ifs.

Since it's || that would be fine (albeit not preferred) by me. If
it was &&, would be be suggesting two nested if()-s (which
generally in reviews we ask to be avoided)? I see nothing wrong
with e.g.

      if ( (a ? b : c) &&
           (x ? y : z) )

Nevertheless I agree that very large conditionals often are more
difficult to read.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 12:29:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 12:29:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJcVC-0003J2-Hv; Wed, 01 Apr 2020 12:29:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJcVB-0003Iv-5y
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 12:29:49 +0000
X-Inumbo-ID: 74935b00-7414-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 74935b00-7414-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 12:29:39 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6D55EAD4B;
 Wed,  1 Apr 2020 12:29:38 +0000 (UTC)
Subject: Re: [PATCH 3/5] x86_64/mm: map and unmap page tables in
 share_hotadd_m2p_table
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1584955616.git.hongyxia@amazon.com>
 <2fa83ef5818805c179757caac99ccf7ab4f7ba3a.1584955616.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f1537005-cac8-cd74-e19c-043219ccab56@suse.com>
Date: Wed, 1 Apr 2020 14:29:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <2fa83ef5818805c179757caac99ccf7ab4f7ba3a.1584955616.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.03.2020 10:41, Hongyan Xia wrote:
> --- a/xen/include/asm-x86/page.h
> +++ b/xen/include/asm-x86/page.h
> @@ -196,6 +196,24 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, unsigned int flags)
>  #define map_l2t_from_l3e(x)        (l2_pgentry_t *)map_domain_page(l3e_get_mfn(x))
>  #define map_l3t_from_l4e(x)        (l3_pgentry_t *)map_domain_page(l4e_get_mfn(x))
>  
> +#define l1e_from_l2e(l2e, off) ({                   \
> +        l1_pgentry_t *l1t = map_l1t_from_l2e(l2e);  \
> +        l1_pgentry_t l1e = l1t[off];                \
> +        UNMAP_DOMAIN_PAGE(l1t);                     \
> +        l1e; })
> +
> +#define l2e_from_l3e(l3e, off) ({                   \
> +        l2_pgentry_t *l2t = map_l2t_from_l3e(l3e);  \
> +        l2_pgentry_t l2e = l2t[off];                \
> +        UNMAP_DOMAIN_PAGE(l2t);                     \
> +        l2e; })
> +
> +#define l3e_from_l4e(l4e, off) ({                   \
> +        l3_pgentry_t *l3t = map_l3t_from_l4e(l4e);  \
> +        l3_pgentry_t l3e = l3t[off];                \
> +        UNMAP_DOMAIN_PAGE(l3t);                     \
> +        l3e; })

There's a reason these are macros rather than inline functions,
I assume? (This reason would be nice to be stated in the
description.)

I don't see why you use UNMAP_DOMAIN_PAGE() rather than
unmap_domain_page() here - the variables in question go out of
scope right afterwards, so the storing of NULL into them is
pointless (and very likely to be eliminated by the compiler
anyway).

Finally the pointers should each be "to const", as you're
only reading through them.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 12:40:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 12:40:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJcfK-0004nh-Iy; Wed, 01 Apr 2020 12:40:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJcfJ-0004nZ-Ec
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 12:40:17 +0000
X-Inumbo-ID: f02afa6a-7415-11ea-bac3-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f02afa6a-7415-11ea-bac3-12813bfff9fa;
 Wed, 01 Apr 2020 12:40:16 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 56103AD75;
 Wed,  1 Apr 2020 12:40:15 +0000 (UTC)
Subject: Re: [PATCH 5/5] x86_64/mm: map and unmap page tables in
 destroy_m2p_mapping
To: Hongyan Xia <hx242@xen.org>, Wei Liu <wl@xen.org>
References: <cover.1584955616.git.hongyxia@amazon.com>
 <7143c2a1e0c7ca46b3ace329d7dcab85e0b5c87c.1584955616.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7981c892-0e5c-03fb-679c-94f023a5c9fc@suse.com>
Date: Wed, 1 Apr 2020 14:40:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7143c2a1e0c7ca46b3ace329d7dcab85e0b5c87c.1584955616.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.03.2020 10:41, Hongyan Xia wrote:
> @@ -297,26 +298,33 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
>              continue;
>          }
>  
> -        l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
> +        l2_ro_mpt = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]);
>          if (!(l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT))
>          {
>              i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
>                      (1UL << (L2_PAGETABLE_SHIFT - 3)) ;
> +            UNMAP_DOMAIN_PAGE(l2_ro_mpt);
>              continue;
>          }
>  
>          pt_pfn = l2e_get_pfn(l2_ro_mpt[l2_table_offset(va)]);
>          if ( hotadd_mem_valid(pt_pfn, info) )
>          {
> +            l2_pgentry_t *l2t;
> +
>              destroy_xen_mappings(rwva, rwva + (1UL << L2_PAGETABLE_SHIFT));
>  
> -            l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
> -            l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_empty());
> +            l2t = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]);

Why a 2nd mapping of the same L3 entry that you've already mapped
into l2_ro_mpt?

> +            l2e_write(&l2t[l2_table_offset(va)], l2e_empty());
> +            UNMAP_DOMAIN_PAGE(l2t);

If this then weren't to go away, it should again be the lowercase
variant imo, as the variable's scope ends here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 12:42:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 12:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJchE-0004un-Vr; Wed, 01 Apr 2020 12:42:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJchE-0004uh-2Y
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 12:42:16 +0000
X-Inumbo-ID: 37180c7e-7416-11ea-bac3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 37180c7e-7416-11ea-bac3-12813bfff9fa;
 Wed, 01 Apr 2020 12:42:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=HfqnF+BnLGW+vtfQUyxipRTA8PszSdNcCt5Y1240FtA=; b=Zm/vav6Jqto39MmmV+X5mSbpK
 6Wc3BnTwo/jRSWqLyUTA2plFPUrNhZpo+0adFVrR1kC5RjJPl960yS57YnEyDtO8wIxPVNGWTXFzR
 QV0N99j8cQzYIDa9NR2q3NuSGu265Dz/2XcdX5oaioqLjXr7JYoX02tM1tXxUP+iztApI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJchC-0002Ly-T6; Wed, 01 Apr 2020 12:42:14 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJchC-0005qq-Hf; Wed, 01 Apr 2020 12:42:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJchC-0002bL-H7; Wed, 01 Apr 2020 12:42:14 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149278-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149278: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=897b6f4b4324b7696602fe386b5ea93506415442
X-Osstest-Versions-That: xen=5af4698d98d881e786c0909b6308f04696586c49
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 12:42:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  897b6f4b4324b7696602fe386b5ea93506415442
baseline version:
 xen                  5af4698d98d881e786c0909b6308f04696586c49

Last test of basis   149240  2020-03-31 08:00:30 Z    1 days
Testing same since   149278  2020-04-01 10:01:56 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Julien Grall <jgrall@amazon.com>
  Julien Grall <julien.grall@arm.com>
  Stefano Stabellini <sstabellini@kernel.org>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   5af4698d98..897b6f4b43  897b6f4b4324b7696602fe386b5ea93506415442 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 13:38:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 13:38:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJdZC-0000wE-Kx; Wed, 01 Apr 2020 13:38:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=eFaW=5R=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jJdZB-0000w9-7v
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 13:38:01 +0000
X-Inumbo-ID: 00ac59da-741e-11ea-bacc-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 00ac59da-741e-11ea-bacc-12813bfff9fa;
 Wed, 01 Apr 2020 13:38:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585748280;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=DdzrpYbUr6wVxb2p2gxB787Cbfg7TTvKh4VHOu/TyzE=;
 b=KR7piUIWjkyImhXEzkXHu2FXPsmWWY8xC4KcS0uZcTn8JNVUDL2Y6suG
 m3AYjUFc4j8CjN5CzBOS6iZ2EE3uf3xXcu/Yg9hsPCUVo7f6+UpLaw+q3
 LIEYUFIICoaGc1z9CqKAX9c0K/Swo4Qt4q3rmAAtadH4uxAZfeeiAW1gy w=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: sZPiwuXttoB/QIfvMQye0xdMLzUrUni/Sx02jv5gzK2YNZYIoANBX9OD53TKRCAAunRPX0c4qB
 RJ/E0i5ZvcsBWhdu0WwA7eFRRll4hWZwPixd4GxXNBOdYVZPIEZh5ZS1hB5XYFNqtNSY2lj5Rt
 k4ueFC+h49ysZVu0fZ64Lq4fuZ/ca4WD0i9tpNGBHUdpO+w4JDYE5NOMWSlUvjTHw1jOcD97j3
 RoLzaWUBl7bUAtYSmJk6Bx01cCvHTxSknHgJVteH0iMeITuvK3VdCBuqxREQ/2mXNW4gc7lWPE
 pro=
X-SBRS: 2.7
X-MesageID: 15325383
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,331,1580792400"; d="scan'208";a="15325383"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH] timeout: adjust timeout when running nested tests
Date: Wed, 1 Apr 2020 15:37:40 +0200
Message-ID: <20200401133740.64685-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Expand the timeouts when the host is nested. The current algorithm
uses base_timeout * 2 ^ nesting_level.

This fixes the issues reported by the nested tests on elbling boxes:

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

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 Osstest/TestSupport.pm | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 1c13e2af..ff749a32 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -436,6 +436,7 @@ END
 
 sub target_adjust_timeout ($$) {
     my ($ho,$timeoutref) = @_; # $ho might be a $gho
+    my $nestinglvl = $ho->{NestingLevel} || $ho->{Host}{NestingLevel};
     my $adjust = sub {
 	my ($factor, $what) = @_;
 	return unless defined $factor;
@@ -450,6 +451,9 @@ sub target_adjust_timeout ($$) {
 	$adjust->(guest_var($ho,$guest_var), "guest variable $guest_var");
     }
     $adjust->(get_target_property($ho,"TimeoutFactor"), "target TimeoutFactor");
+    if ($nestinglvl) {
+        $adjust->(1 << $nestinglvl, "nesting level");
+    }
 }
 
 #---------- running commands eg on targets ----------
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 01 13:42:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 13:42:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJddf-0001jC-8M; Wed, 01 Apr 2020 13:42:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJddd-0001j7-TI
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 13:42:37 +0000
X-Inumbo-ID: a567295a-741e-11ea-bacd-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a567295a-741e-11ea-bacd-12813bfff9fa;
 Wed, 01 Apr 2020 13:42:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=EDTbYLlvg351W5Iqba13qxknwu4V1mwbBXYBfKgreDc=; b=JAtDJ8kss5CKeDuQDfMvuiOXmy
 5sCP+1BoWjTGan+axgpeRq7AvmAuXtvn9PKUgG+VEShl+mHDvcNyPS6g7fN4T9oWdC0DUDwtx+OsB
 Io9KOBO4K2K1DR4/CCI5CVFmN9Y/av+Pr5BvVpew73kw/yQaqnJo+MnN0aSzcBGhpJiw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJddV-0003X4-AJ; Wed, 01 Apr 2020 13:42:29 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJddU-0001ab-Uk; Wed, 01 Apr 2020 13:42:29 +0000
Subject: Re: [PATCH 2/5] xen/common/domctl: introduce
 XEN_DOMCTL_get/setdomaincontext
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-3-paul@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <fc193a54-5d25-ffff-2234-9c0079c605d8@xen.org>
Date: Wed, 1 Apr 2020 14:42:26 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200327185012.1795-3-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 27/03/2020 18:50, Paul Durrant wrote:
> These domctls provide a mechanism to get and set domain context from
> the toolstack.
> 
> Signed-off-by: Paul Durrant <paul@xen.org>
> ---
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Wei Liu <wl@xen.org>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> ---
>   tools/flask/policy/modules/xen.if   |   4 +-
>   tools/libxc/include/xenctrl.h       |  11 +++
>   tools/libxc/xc_domain.c             |  52 +++++++++++++
>   xen/common/domctl.c                 | 115 ++++++++++++++++++++++++++++
>   xen/include/public/domctl.h         |  41 +++++++++-
>   xen/xsm/flask/hooks.c               |   6 ++
>   xen/xsm/flask/policy/access_vectors |   4 +
>   7 files changed, 230 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
> index 8eb2293a52..2bc9db4f64 100644
> --- a/tools/flask/policy/modules/xen.if
> +++ b/tools/flask/policy/modules/xen.if
> @@ -53,7 +53,7 @@ define(`create_domain_common', `
>   	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
>   			set_vnumainfo get_vnumainfo cacheflush
>   			psr_cmt_op psr_alloc soft_reset
> -			resource_map get_cpu_policy };
> +			resource_map get_cpu_policy setcontext };
>   	allow $1 $2:security check_context;
>   	allow $1 $2:shadow enable;
>   	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
> @@ -97,7 +97,7 @@ define(`migrate_domain_out', `
>   	allow $1 $2:hvm { gethvmc getparam };
>   	allow $1 $2:mmu { stat pageinfo map_read };
>   	allow $1 $2:domain { getaddrsize getvcpucontext pause destroy };
> -	allow $1 $2:domain2 gettsc;
> +	allow $1 $2:domain2 { gettsc getcontext };
>   	allow $1 $2:shadow { enable disable logdirty };
>   ')
>   
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index fc6e57a1a0..5c0d0d27a4 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -867,6 +867,17 @@ int xc_domain_hvm_setcontext(xc_interface *xch,
>                                uint8_t *hvm_ctxt,
>                                uint32_t size);
>   
> +int xc_domain_getcontext(xc_interface *xch,
> +                         uint32_t domid,
> +                         uint32_t mask,
> +                         uint8_t *ctxt_buf,

Why do you use uint8_t rather than void here?

> +                         uint32_t size);
> +int xc_domain_setcontext(xc_interface *xch,
> +                         uint32_t domid,
> +                         uint32_t mask,
> +                         uint8_t *ctxt_buf,
> +                         uint32_t size);
> +
>   /**
>    * This function will return guest IO ABI protocol
>    *
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 71829c2bce..15bcf671fc 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -537,6 +537,58 @@ int xc_domain_hvm_setcontext(xc_interface *xch,
>       return ret;
>   }
>   
> +int xc_domain_getcontext(xc_interface *xch,
> +                         uint32_t domid,
> +                         uint32_t mask,
> +                         uint8_t *ctxt_buf,
> +                         uint32_t size)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +    DECLARE_HYPERCALL_BOUNCE(ctxt_buf, size, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> +
> +    if ( xc_hypercall_bounce_pre(xch, ctxt_buf) )
> +        return -1;
> +
> +    domctl.cmd = XEN_DOMCTL_getdomaincontext;
> +    domctl.domain = domid;
> +    domctl.u.domaincontext.mask = mask;
> +    domctl.u.domaincontext.size = size;
> +    set_xen_guest_handle(domctl.u.domaincontext.buffer, ctxt_buf);
> +
> +    ret = do_domctl(xch, &domctl);
> +
> +    xc_hypercall_bounce_post(xch, ctxt_buf);
> +
> +    return !ret ? domctl.u.domaincontext.size : -1;

Looking at the domctl interface, size would be a 32-bit unsigned value. 
However the return is a 32-bit signed value. This is a call for trouble 
if the size is too big.

> +}
> +
> +int xc_domain_setcontext(xc_interface *xch,
> +                         uint32_t domid,
> +                         uint32_t mask,
> +                         uint8_t *ctxt_buf,

The context is not meant to be modified. So this should really be const.

> +                         uint32_t size)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +    DECLARE_HYPERCALL_BOUNCE(ctxt_buf, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +
> +    if ( xc_hypercall_bounce_pre(xch, ctxt_buf) )
> +        return -1;
> +
> +    domctl.cmd = XEN_DOMCTL_setdomaincontext;
> +    domctl.domain = domid;
> +    domctl.u.domaincontext.mask = mask;
> +    domctl.u.domaincontext.size = size;
> +    set_xen_guest_handle(domctl.u.domaincontext.buffer, ctxt_buf);
> +
> +    ret = do_domctl(xch, &domctl);
> +
> +    xc_hypercall_bounce_post(xch, ctxt_buf);
> +
> +    return ret;
> +}
> +
>   int xc_vcpu_getcontext(xc_interface *xch,
>                          uint32_t domid,
>                          uint32_t vcpu,
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index a69b3b59a8..9c39519b04 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -25,6 +25,7 @@
>   #include <xen/hypercall.h>
>   #include <xen/vm_event.h>
>   #include <xen/monitor.h>
> +#include <xen/save.h>
>   #include <asm/current.h>
>   #include <asm/irq.h>
>   #include <asm/page.h>
> @@ -358,6 +359,111 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
>       return ERR_PTR(ret);
>   }
>   
> +struct domctl_context
> +{
> +    void *buffer;
> +    size_t len;
> +    size_t cur;
> +};
> +
> +static int accumulate_size(void *priv, void *data, size_t len)
> +{
> +    struct domctl_context *c = priv;
> +
> +    c->len += len;

What does prevent overflow?

> +
> +    return 0;
> +}
> +
> +static int save_data(void *priv, void *data, size_t len)
> +{
> +    struct domctl_context *c = priv;
> +
> +    if ( c->len - c->cur < len )
> +        return -ENOSPC;
> +
> +    memcpy(c->buffer + c->cur, data, len);
> +    c->cur += len;
> +
> +    return 0;
> +}
> +
> +static int getdomaincontext(struct domain *d,
> +                            struct xen_domctl_domaincontext *dc)
> +{
> +    struct domctl_context c = { };
> +    int rc;
> +
> +    if ( d == current->domain )
> +        return -EPERM;
> +
> +    if ( guest_handle_is_null(dc->buffer) ) /* query for buffer size */
> +
> +    {
> +        if ( dc->size )
> +            return -EINVAL;
> +
> +        /* dry run to acquire buffer size */
> +        rc = domain_save(d, accumulate_size, &c, dc->mask, true);
> +        if ( rc )
> +            return rc;
> +
> +        dc->size = c.len;

len is a size_t (so 64-bit on 64-bit arch) value, but size is 32-bit. So 
we return an error if the stream is going to be bigger than 4G?

> +        return 0;
> +    }
> +
> +    c.len = dc->size;
> +    c.buffer = xmalloc_bytes(c.len);
> +    if ( !c.buffer )
> +        return -ENOMEM;
> +
> +    rc = domain_save(d, save_data, &c, dc->mask, false);
> +
> +    dc->size = c.cur;
> +    if ( !rc && copy_to_guest(dc->buffer, c.buffer, dc->size) )
> +        rc = -EFAULT;
> +
> +    xfree(c.buffer);
> +
> +    return rc;
> +}
> +
> +static int load_data(void *priv, void *data, size_t len)
> +{
> +    struct domctl_context *c = priv;
> +
> +    if ( c->len - c->cur < len )
> +        return -ENODATA;
> +
> +    if ( data )
> +        memcpy(data, c->buffer + c->cur, len);
> +
> +    c->cur += len;
> +
> +    return 0;
> +}
> +
> +static int setdomaincontext(struct domain *d,
> +                            const struct xen_domctl_domaincontext *dc)
> +{
> +    struct domctl_context c = { .len = dc->size };
> +    int rc;
> +
> +    if ( d == current->domain )
> +        return -EPERM;
> +
> +    c.buffer = xmalloc_bytes(c.len);
> +    if ( !c.buffer )
> +        return -ENOMEM;
> +
> +    rc = !copy_from_guest(c.buffer, dc->buffer, c.len) ?
> +        domain_load(d, load_data, &c, dc->mask) : -EFAULT;
> +
> +    xfree(c.buffer);
> +
> +    return rc;
> +}
> +
>   long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>   {
>       long ret = 0;
> @@ -942,6 +1048,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>               copyback = 1;
>           break;
>   
> +    case XEN_DOMCTL_getdomaincontext:
> +        ret = getdomaincontext(d, &op->u.domaincontext);
> +        copyback = !ret;
> +        break;
> +
> +    case XEN_DOMCTL_setdomaincontext:
> +        ret = setdomaincontext(d, &op->u.domaincontext);
> +        break;
> +
>       default:
>           ret = arch_do_domctl(op, d, u_domctl);
>           break;
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 1ad34c35eb..24ed6852cf 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -38,7 +38,7 @@
>   #include "hvm/save.h"
>   #include "memory.h"
>   
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000012
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000013
>   
>   /*
>    * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> @@ -1129,6 +1129,42 @@ struct xen_domctl_vuart_op {
>                                    */
>   };
>   
> +/*
> + * Get/Set domain PV context. The same struct xen_domctl_domaincontext
> + * is used for both commands but with slightly different field semantics
> + * as follows:
> + *
> + * XEN_DOMCTL_getdomaincontext
> + * ---------------------------
> + *
> + * buffer (IN):   The buffer into which the context data should be
> + *                copied, or NULL to query the buffer size that should
> + *                be allocated.
> + * size (IN/OUT): If 'buffer' is NULL then the value passed in must be
> + *                zero, and the value passed out will be the size of the
> + *                buffer to allocate.
> + *                If 'buffer' is non-NULL then the value passed in must
> + *                be the size of the buffer into which data may be copied.
> + * mask (IN):     See comment on domain_save/load() in xen/save.h.
> + *
> + * XEN_DOMCTL_setdomaincontext
> + * ---------------------------
> + *
> + * buffer (IN):   The buffer from which the context data should be
> + *                copied.
> + * size (IN):     The size of the buffer from which data may be copied.
> + *                This data must include DOMAIN_SAVE_CODE_HEADER at the
> + *                start and terminate with a DOMAIN_SAVE_CODE_END record.
> + *                Any data beyond the DOMAIN_SAVE_CODE_END record will be
> + *                ignored.
> + * mask (IN):     See comment on domain_save/load() in xen/save.h.
> + */
> +struct xen_domctl_domaincontext {
> +    uint32_t size;
> +    uint32_t mask;
> +    XEN_GUEST_HANDLE_64(uint8) buffer;

Should not it be a void handle?

Also, in the case of XEN_DOMCTL_setdomaincontext, the buffer is not 
meant to be modified by the hypervisor. So I would rather introduce two 
separate structure so we can enforce the const.

> +};
> +
>   struct xen_domctl {
>       uint32_t cmd;
>   #define XEN_DOMCTL_createdomain                   1
> @@ -1210,6 +1246,8 @@ struct xen_domctl {
>   #define XEN_DOMCTL_vuart_op                      81
>   #define XEN_DOMCTL_get_cpu_policy                82
>   #define XEN_DOMCTL_set_cpu_policy                83
> +#define XEN_DOMCTL_getdomaincontext              84
> +#define XEN_DOMCTL_setdomaincontext              85
>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1270,6 +1308,7 @@ struct xen_domctl {
>           struct xen_domctl_monitor_op        monitor_op;
>           struct xen_domctl_psr_alloc         psr_alloc;
>           struct xen_domctl_vuart_op          vuart_op;
> +        struct xen_domctl_domaincontext     domaincontext;
>           uint8_t                             pad[128];
>       } u;
>   };
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 8af8602b46..d94d0fc125 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -744,6 +744,12 @@ static int flask_domctl(struct domain *d, int cmd)
>       case XEN_DOMCTL_get_cpu_policy:
>           return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_CPU_POLICY);
>   
> +    case XEN_DOMCTL_setdomaincontext:
> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SETCONTEXT);
> +
> +    case XEN_DOMCTL_getdomaincontext:
> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GETCONTEXT);
> +
>       default:
>           return avc_unknown_permission("domctl", cmd);
>       }
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index c055c14c26..fccfb9de82 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -245,6 +245,10 @@ class domain2
>       resource_map
>   # XEN_DOMCTL_get_cpu_policy
>       get_cpu_policy
> +# XEN_DOMCTL_setdomaincontext
> +    setcontext
> +# XEN_DOMCTL_getdomaincontext
> +    getcontext
>   }
>   
>   # Similar to class domain, but primarily contains domctls related to HVM domains
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 13:46:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 13:46:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJdha-0001sX-Ti; Wed, 01 Apr 2020 13:46:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJdhY-0001sP-Uu
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 13:46:41 +0000
X-Inumbo-ID: 36e6c6c4-741f-11ea-bacd-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 36e6c6c4-741f-11ea-bacd-12813bfff9fa;
 Wed, 01 Apr 2020 13:46:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mTxk7T2J5nyCaUpUoe1Vugh+bmltdVSeKBfY8moAOpU=; b=X55wTXML0eQ0W8QZ61m66gqFQC
 pr+6EGLy/OowbahKNZpC17FcPBBwCUI27lfXnPRKUYpBqhEHayd4j15NhYNQ+/0nF9ypDXFkDNXRQ
 vq9lJ8qazmlAKtmlXS5t6dTUTPupODpqCdrKoHn5tlUVN3q9mGRmIyrWzugJVx4ah4tY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJdhT-0003bw-AI; Wed, 01 Apr 2020 13:46:35 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJdhT-0002Du-3V; Wed, 01 Apr 2020 13:46:35 +0000
Subject: Re: [PATCH 2/5] xen/common/domctl: introduce
 XEN_DOMCTL_get/setdomaincontext
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-3-paul@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <24e98077-b9df-8868-328e-c40d7dd60b6c@xen.org>
Date: Wed, 1 Apr 2020 14:46:32 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200327185012.1795-3-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 27/03/2020 18:50, Paul Durrant wrote:
> + * XEN_DOMCTL_getdomaincontext
> + * ---------------------------
> + *
> + * buffer (IN):   The buffer into which the context data should be
> + *                copied, or NULL to query the buffer size that should
> + *                be allocated.
> + * size (IN/OUT): If 'buffer' is NULL then the value passed in must be
> + *                zero, and the value passed out will be the size of the
> + *                buffer to allocate.
> + *                If 'buffer' is non-NULL then the value passed in must
> + *                be the size of the buffer into which data may be copied.
> + * mask (IN):     See comment on domain_save/load() in xen/save.h.
> + *
> + * XEN_DOMCTL_setdomaincontext
> + * ---------------------------
> + *
> + * buffer (IN):   The buffer from which the context data should be
> + *                copied.
> + * size (IN):     The size of the buffer from which data may be copied.
> + *                This data must include DOMAIN_SAVE_CODE_HEADER at the
> + *                start and terminate with a DOMAIN_SAVE_CODE_END record.
> + *                Any data beyond the DOMAIN_SAVE_CODE_END record will be
> + *                ignored.
> + * mask (IN):     See comment on domain_save/load() in xen/save.h.
> + */
> +struct xen_domctl_domaincontext {
> +    uint32_t size;
> +    uint32_t mask;

I actually forgot to comment on the mask. We are restricting ourself to 
32 different type of records. I don't think this is going to fly very far.

But what is the expected use of 'mask'. Are we expecting the toolstack 
to say which records should be saved/restored?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 14:28:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 14:28:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJeLR-0005Dx-GH; Wed, 01 Apr 2020 14:27:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJeLP-0005Ds-U8
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 14:27:51 +0000
X-Inumbo-ID: f79a3a40-7424-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f79a3a40-7424-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 14:27:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=VvgrPNeYcMNwhQYd6I990hlii279DKhGbZhR4/H8Lak=; b=xO93AhaFFVvtdDNfKG70peJD38
 A9Y7qnHx9J2GM647ALHmsP1Ypw+da9diI+T22IJdyzPOL0I8kRp1KM4WtadSjcspPMRjHA/PwO55A
 EknF4QL7ftqveS4pJNECu3J+5RmWxthpBfMhtYtkd5FAw4/oUbJ0YYM4PrvVAfDKfcbM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJeLK-0004Sp-OG; Wed, 01 Apr 2020 14:27:46 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJeLK-00058I-Cx; Wed, 01 Apr 2020 14:27:46 +0000
Subject: Re: [PATCH 4/5] common/domain: add a domain context record for
 shared_info...
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-5-paul@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <8611bb0e-094e-baf5-23b1-206624c14f3e@xen.org>
Date: Wed, 1 Apr 2020 15:27:44 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200327185012.1795-5-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

HI Paul,

On 27/03/2020 18:50, Paul Durrant wrote:
> ... and update xen-ctx to dump some information describing the record.

The commit message should contain a little bit more context why we are 
saving/restore the shared_info.

> 
> NOTE: To allow a sensible definition of the record in public/save.h
>        this patch also adds a definition of the Xen ABI's de-facto page
>        size into public/xen.h.
> 
> Signed-off-by: Paul Durrant <paul@xen.org>
> ---
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Wei Liu <wl@xen.org>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> ---
>   tools/misc/xen-ctx.c      |  8 ++++++
>   xen/common/domain.c       | 55 +++++++++++++++++++++++++++++++++++++++
>   xen/include/public/save.h | 10 ++++++-
>   xen/include/public/xen.h  |  3 +++
>   4 files changed, 75 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/misc/xen-ctx.c b/tools/misc/xen-ctx.c
> index c31dd5d8e9..8f9692843b 100644
> --- a/tools/misc/xen-ctx.c
> +++ b/tools/misc/xen-ctx.c
> @@ -57,6 +57,13 @@ static void dump_header(void)
>              h.magic, h.version);
>   }
>   
> +static void dump_shared_info(void)
> +{
> +    DOMAIN_SAVE_TYPE(SHARED_INFO) s;
> +    READ(s);
> +    printf("    SHARED_INFO: field_width %u\n", s.field_width);
> +}
> +
>   static void dump_end(void)
>   {
>       DOMAIN_SAVE_TYPE(END) e;
> @@ -124,6 +131,7 @@ int main(int argc, char **argv)
>           switch (desc.typecode)
>           {
>           case DOMAIN_SAVE_CODE(HEADER): dump_header(); break;
> +        case DOMAIN_SAVE_CODE(SHARED_INFO): dump_shared_info(); break;
>           case DOMAIN_SAVE_CODE(END): dump_end(); return 0;
>           default:
>               printf("Unknown type %u: skipping\n", desc.typecode);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 3dcd73f67c..484f6bde13 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -33,6 +33,7 @@
>   #include <xen/xenoprof.h>
>   #include <xen/irq.h>
>   #include <xen/argo.h>
> +#include <xen/save.h>
>   #include <asm/debugger.h>
>   #include <asm/p2m.h>
>   #include <asm/processor.h>
> @@ -1646,6 +1647,60 @@ int continue_hypercall_on_cpu(
>       return 0;
>   }
>   
> +static int save_shared_info(const struct vcpu *v, struct domain_context *c,
> +                            bool dry_run)
> +{
> +    struct domain *d = v->domain;
> +    struct domain_shared_info_context ctxt = {};

IHMO, storing 4K worth of data on the stack is a pretty bad idea. 
Looking at the code...

> +
> +    if ( !dry_run )
> +    {
> +        memcpy(ctxt.buffer, d->shared_info, PAGE_SIZE);

... it feels to me the content of the shared_info should be directly 
written in the stream.

> +        ctxt.field_width = has_32bit_shinfo(d) ? 4 : 8;
> +    }
> +
> +    return DOMAIN_SAVE_ENTRY(SHARED_INFO, c, v, &ctxt, sizeof(ctxt));
> +}
> +
> +static int load_shared_info(struct vcpu *v, struct domain_context *c)
> +{
> +    struct domain *d = v->domain;
> +    struct domain_shared_info_context ctxt;
> +    unsigned int i;
> +    int rc;
> +
> +    rc = DOMAIN_LOAD_ENTRY(SHARED_INFO, c, v, &ctxt, sizeof(ctxt), true);
> +    if ( rc )
> +        return rc;
> +
> +    for ( i = 0; i < ARRAY_SIZE(ctxt.pad); i++ )
> +        if ( ctxt.pad[i] )
> +            return -EINVAL;
> +
> +    switch ( ctxt.field_width )
> +    {
> +    case 4:
> +        d->arch.has_32bit_shinfo = 1;

I don't think this will compile on Arm.

> +        break;
> +
> +    case 8:
> +        d->arch.has_32bit_shinfo = 0;
> +        break;
> +
> +    default:
> +        rc = -EINVAL;
> +        break;
> +    }
> +
> +    if ( !rc )
> +        memcpy(d->shared_info, ctxt.buffer, PAGE_SIZE);
> +
> +    return rc;
> +}
> +
> +DOMAIN_REGISTER_SAVE_RESTORE(SHARED_INFO, false, save_shared_info,
> +                             load_shared_info);
> +
>   /*
>    * Local variables:
>    * mode: C
> diff --git a/xen/include/public/save.h b/xen/include/public/save.h
> index 84981cd0f6..ff804a7dbf 100644
> --- a/xen/include/public/save.h
> +++ b/xen/include/public/save.h
> @@ -69,6 +69,14 @@ struct domain_save_header {
>   };
>   DECLARE_DOMAIN_SAVE_TYPE(HEADER, 1, struct domain_save_header);
>   
> -#define DOMAIN_SAVE_CODE_MAX 1
> +struct domain_shared_info_context {
> +    uint8_t buffer[XEN_PAGE_SIZE];

In the load/save code, you are using PAGE_SIZE but here you are using 
XEN_PAGE_SIZE. I don't think there are any promise they will be the same 
value. In particular...

> +    uint8_t field_width;
> +    uint8_t pad[7];
> +};
> +
> +DECLARE_DOMAIN_SAVE_TYPE(SHARED_INFO, 2, struct domain_shared_info_context);
> +
> +#define DOMAIN_SAVE_CODE_MAX 2
>   
>   #endif /* __XEN_PUBLIC_SAVE_H__ */
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 75b1619d0d..cbf603f289 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -37,6 +37,9 @@
>   #error "Unsupported architecture"
>   #endif
>   
> +/* The Xen ABI assumes a page size of 4k. */
> +#define XEN_PAGE_SIZE 4096

... this is not correct. Xen ABI is based on the page granularity used 
by Xen. It happens to be 4KB today but that's because no-one build yet a 
64KB/16KB hypervisor.

If someone tomorrow decides to add support for 64KB, then using 4KB in 
the ABI by default is not going to fly.

Imagine the guest only give access to 4KB region, how do you handle it 
if your minimum granularity in the hypervisor is 64KB?

In theory, it will not require much effort to get Xen on Arm built with 
64KB/16KB support as long as guest is using a page granularity higher 
than what Xen is using.

I would much prefer if we encode the page size in the stream. We can 
then use to retrieve data based on the page size.

Regarding the shared_info itself. Why do you need to know the size in 
tools? Would not it be enough to save the real size in 
domain_shared_info_context?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 14:29:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 14:29:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJeNH-0005K9-TS; Wed, 01 Apr 2020 14:29:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJeNG-0005K2-8E
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 14:29:46 +0000
X-Inumbo-ID: 3b8615b2-7425-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3b8615b2-7425-11ea-9e09-bc764e2007e4;
 Wed, 01 Apr 2020 14:29:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6C259ABC6;
 Wed,  1 Apr 2020 14:29:44 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] guestcopy: evaluate {, __}copy{, _field}_to_guest*() arguments
 just once
Message-ID: <9918b339-e914-7228-5f8e-86c82090b5bd@suse.com>
Date: Wed, 1 Apr 2020 16:29:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

There's nothing wrong with having e.g.

    copy_to_guest(uarg, ptr++, 1);

yet until now this would increment "ptr" twice.

Also drop a pair of unneeded parentheses from every instance at this
occasion.

Fixes: b7954cc59831 ("Enhance guest memory accessor macros so that source operands can be")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Arm side untested so far, as I don't have all the tool chain pieces
available at home.
---
This goes on top of the assumed v2 of Julien's "xen/guest_access: Harden
copy_to_guest_offset to prevent const dest operand".

--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -79,7 +79,7 @@ int access_guest_memory_by_ipa(struct do
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
     void *__maybe_unused _t = (hnd).p;                  \
-    ((void)((hnd).p == (ptr)));                         \
+    (void)((hnd).p == _s);                              \
     raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
 })
 
@@ -106,7 +106,7 @@ int access_guest_memory_by_ipa(struct do
 #define copy_field_to_guest(hnd, ptr, field) ({         \
     const typeof(&(ptr)->field) _s = &(ptr)->field;     \
     void *_d = &(hnd).p->field;                         \
-    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    (void)(&(hnd).p->field == _s);                      \
     raw_copy_to_guest(_d, _s, sizeof(*_s));             \
 })
 
@@ -129,7 +129,7 @@ int access_guest_memory_by_ipa(struct do
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
     void *__maybe_unused _t = (hnd).p;                  \
-    ((void)((hnd).p == (ptr)));                         \
+    (void)((hnd).p == _s);                              \
     __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
 })
 
@@ -146,7 +146,7 @@ int access_guest_memory_by_ipa(struct do
 #define __copy_field_to_guest(hnd, ptr, field) ({       \
     const typeof(&(ptr)->field) _s = &(ptr)->field;     \
     void *_d = &(hnd).p->field;                         \
-    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    (void)(&(hnd).p->field == _s);                      \
     __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
 })
 
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -88,7 +88,7 @@
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
     void *__maybe_unused _t = (hnd).p;                  \
-    ((void)((hnd).p == (ptr)));                         \
+    (void)((hnd).p == _s);                              \
     raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
 })
 
@@ -111,7 +111,7 @@
 #define copy_field_to_guest(hnd, ptr, field) ({         \
     const typeof(&(ptr)->field) _s = &(ptr)->field;     \
     void *_d = &(hnd).p->field;                         \
-    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    (void)(&(hnd).p->field == _s);                      \
     raw_copy_to_guest(_d, _s, sizeof(*_s));             \
 })
 
@@ -139,7 +139,7 @@
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
     void *__maybe_unused _t = (hnd).p;                  \
-    ((void)((hnd).p == (ptr)));                         \
+    (void)((hnd).p == _s);                              \
     __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
 })
 
@@ -157,7 +157,7 @@
 #define __copy_field_to_guest(hnd, ptr, field) ({       \
     const typeof(&(ptr)->field) _s = &(ptr)->field;     \
     void *_d = &(hnd).p->field;                         \
-    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    (void)(&(hnd).p->field == _s);                      \
     __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
 })
 


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 14:33:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 14:33:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJeQn-00067b-EV; Wed, 01 Apr 2020 14:33:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJeQl-00067S-Sz
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 14:33:23 +0000
X-Inumbo-ID: bc7e58ab-7425-11ea-bae1-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bc7e58ab-7425-11ea-bae1-12813bfff9fa;
 Wed, 01 Apr 2020 14:33:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=XlpR//V8NawQ6pIAl8gSrIZmWwkGu9MHFNyEFGEym3c=; b=ioXvKK+ZCcUvlfVP1R8ZidSM4
 OS+Z/RCINOqhJ9O2QfPmZQqWD+TMy+Ey67neNcY6pgGTdCoY8fuT1kB3e0ilkMItb2nizWvidb+KI
 stND1pe0MOX/3pPlZ5LrRWe1Voo3J/d8sQy6fAyV40delzeHGtDdmxVnEl3PBQC6w6KvI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJeQj-0004Zt-Lx; Wed, 01 Apr 2020 14:33:21 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJeQj-0002Uw-BI; Wed, 01 Apr 2020 14:33:21 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJeQj-0000Ep-AO; Wed, 01 Apr 2020 14:33:21 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149268-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149268: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=93f775eaa32ef63df5d07eb6a2c2193ca6d936ac
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 14:33:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              93f775eaa32ef63df5d07eb6a2c2193ca6d936ac
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   75 days
Failing since        146211  2020-01-18 04:18:52 Z   74 days   71 attempts
Testing same since   149234  2020-03-31 04:18:52 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 12464 lines long.)


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 14:51:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 14:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJehc-0007jW-5N; Wed, 01 Apr 2020 14:50:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1qDs=5R=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJeha-0007jR-KH
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 14:50:46 +0000
X-Inumbo-ID: 2a6448f0-7428-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2a6448f0-7428-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 14:50:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0AFE7ABD7;
 Wed,  1 Apr 2020 14:50:44 +0000 (UTC)
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: Paul Durrant <paul@xen.org>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e9b21d59-3a4a-1498-e5f4-45d1420ddbc4@suse.com>
Date: Wed, 1 Apr 2020 16:50:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200327185012.1795-2-paul@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.03.2020 19:50, Paul Durrant wrote:
> Domain context is state held in the hypervisor that does not come under
> the category of 'HVM state' but is instead 'PV state' that is common
> between PV guests and enlightened HVM guests (i.e. those that have PV
> drivers) such as event channel state, grant entry state, etc.

Without looking at the patch details yet, I'm having some difficulty
understanding how this is going to work in a safe/correct manner. I
suppose for LU the system is in a frozen enough state that
snapshotting and copying state like this is okay, but ...

> To allow enlightened HVM guests to be migrated without their co-operation
> it will be necessary to transfer such state along with the domain's
> memory image, architectural state, etc. This framework is introduced for
> that purpose.
> 
> This patch adds the new public header and the low level implementation,
> entered via the domain_save() or domain_load() functions. Subsequent
> patches will introduce other parts of the framwork, and code that will
> make use of it within the current version of the libxc migration stream.

... here you suggest (and patch 5 appears to match this) that this
is going to be used even in "normal" migration streams. All of the
items named are communication vehicles, and hence there are always
two sides that can influence the state. For event channels, the
other side (which isn't paused) or the hardware (for passed through
devices) might signal them, or it (just the former obviously) could
close their end, resulting in a state change also for the domain
being migrated. If this happens after the snapshot was taken, the
state change is lost.

Otoh I'm sure the case was considered, so perhaps I'm simply missing
some crucial aspect (which then could do with spelling out in the
description of the cover letter).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 15:22:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 15:22:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJfCK-0001pL-Sh; Wed, 01 Apr 2020 15:22:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJfCJ-0001pG-Jx
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 15:22:31 +0000
X-Inumbo-ID: 9a7642e8-742c-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9a7642e8-742c-11ea-9e09-bc764e2007e4;
 Wed, 01 Apr 2020 15:22:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=oHB7Gxldi7tqWFdGBvAvG0zMZRz4ObUQhNCLbgD+rOI=; b=vQyNHx/tdw+RxeBD0NFO4O4ni
 R4pxCc6zCKQrg6ytEf6zHWkqXFpxTXKTPyVuGMrSg3K7cPiy/yU5dPyYjp0xSkq6f0AEPnMICmRR/
 3lcElgmlKjdVpMz+kh6axOnGkLsccczVHbhs3bDRQ4mggL9VV9i+K55N3i7gYYPUl5/k8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJfCI-0005Vq-FO; Wed, 01 Apr 2020 15:22:30 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJfCI-0004KZ-5j; Wed, 01 Apr 2020 15:22:30 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJfCI-0005b7-53; Wed, 01 Apr 2020 15:22:30 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149262-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149262: all pass - PUSHED
X-Osstest-Versions-This: ovmf=dd7523b5b123de6f0730f2f2abb207f2a5c1ccd4
X-Osstest-Versions-That: ovmf=8c944c938359cffda4c889259b3d2aba69e9ee7b
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 15:22:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 dd7523b5b123de6f0730f2f2abb207f2a5c1ccd4
baseline version:
 ovmf                 8c944c938359cffda4c889259b3d2aba69e9ee7b

Last test of basis   149242  2020-03-31 09:59:29 Z    1 days
Testing same since   149262  2020-04-01 00:39:27 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@arm.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Sami Mujawar <sami.mujawar@arm.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   8c944c9383..dd7523b5b1  dd7523b5b123de6f0730f2f2abb207f2a5c1ccd4 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 15:46:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 15:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJfZo-0003WH-2N; Wed, 01 Apr 2020 15:46:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=5Uk1=5R=gmail.com=asaffisher.dev@srs-us1.protection.inumbo.net>)
 id 1jJfYE-0003Ud-RN
 for xen-devel@lists.xen.org; Wed, 01 Apr 2020 15:45:10 +0000
X-Inumbo-ID: c485108e-742f-11ea-9e09-bc764e2007e4
Received: from mail-il1-x12a.google.com (unknown [2607:f8b0:4864:20::12a])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c485108e-742f-11ea-9e09-bc764e2007e4;
 Wed, 01 Apr 2020 15:45:10 +0000 (UTC)
Received: by mail-il1-x12a.google.com with SMTP id j9so377026ilr.7
 for <xen-devel@lists.xen.org>; Wed, 01 Apr 2020 08:45:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=7WH1VZMhipii5qGj8FCkDoZc0ZVO53Rd+qcBUFGxmKo=;
 b=Byl1+AQt1qUM2DWFl8PbqdwKSApWrWgtXUfB5P2j8w88c1/lpGWT7HRefnuISdlglc
 MxueS1DtZ4sn4V039gRod8pcQEDiwtp3XkLD6j3HGIipOK3eTr9fVVxgXILtVpeJ/eLp
 kFidsheCM7mCdDvhiSzlmkQdtpmB2gNOVLNFr1agqnuHVI72RMyr4Gqaww9RxUzACGVR
 iQce9yorwPRzzoWhL0yBuRuTfTDxMtazWGkHeNDEFyANfJxMZ0JIevd+GMY/A9qZvEvL
 GecI4RPUH/my8TJ59cgzRThynR6gOht6gsW8XEpxrTMQIC+0LaIB2ey0sneB5VzyvjgO
 fdFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=7WH1VZMhipii5qGj8FCkDoZc0ZVO53Rd+qcBUFGxmKo=;
 b=FWLKYf2hr2//ltjfy5KqNCjtAwjqRTV2ir4CCYvwNUECPzw3cbVNOel+qLcyfeWh9D
 8iWI48MtH5flFKfrMxWYurrgR2AOlNEF39HFQWAOpH3ZyhV1lYUV71i37n1FePel/8v7
 swyUDD1Q3gA2Nj4g0Tyd5xK17D+quUTyu6lkPA1INScOgySxMRfcROKP7tAe/dRbFgDt
 AJzPS42hNtVe3fz9PRekbakYXrUPqxt8CHQ445uynUnuv7Lum3epgrZoOYzxw1ShvcyD
 oJz7fG6dTLPK3JKuW2r9f4pR1pmxYLZw/sKZ8+U4TNaau61Fqf6WtntB2AWRIOe94d/M
 SahQ==
X-Gm-Message-State: ANhLgQ3o7/LrU7cgBUZzxusxc9+TiGHJZdXGeo3BUcLcNXZVwDmYUJnq
 ZctUTKt1jXF+wl8/hsYGHVmeJweiXZvsH61VTjy4kmXZjlw=
X-Google-Smtp-Source: ADFU+vsBYyv9GqtuRMp9MPOwYoo/pwxq07OscYvQIy+HzD7/DyS0SD7QSp9l6frVQApx8GWyaD0kuM9e35E47dto4+Y=
X-Received: by 2002:a92:3b9c:: with SMTP id n28mr22113720ilh.53.1585755909175; 
 Wed, 01 Apr 2020 08:45:09 -0700 (PDT)
MIME-Version: 1.0
From: Asaf Fisher <asaffisher.dev@gmail.com>
Date: Wed, 1 Apr 2020 18:44:58 +0300
Message-ID: <CAHmEStvAQ0SHMYMcS4c43B9uOAU3trvsRJMVtO5CxCr+QXTD9g@mail.gmail.com>
Subject: Make VM save/restore and VM migration work on ARM.
To: xen-devel@lists.xen.org
Content-Type: multipart/alternative; boundary="000000000000aad76805a23c91d7"
X-Mailman-Approved-At: Wed, 01 Apr 2020 15:46:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--000000000000aad76805a23c91d7
Content-Type: text/plain; charset="UTF-8"

Hello!
Just wonder if this Open Work Item is still available?
https://wiki.xenproject.org/wiki/Xen_ARM_TODO
Thank you,
Asaf Fisher

--000000000000aad76805a23c91d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello!<div>Just wonder if this Open Work Item is still=C2=
=A0available?</div><div><a href=3D"https://wiki.xenproject.org/wiki/Xen_ARM=
_TODO">https://wiki.xenproject.org/wiki/Xen_ARM_TODO</a>=C2=A0</div><div>Th=
ank you,</div><div>Asaf Fisher=C2=A0<br></div></div>

--000000000000aad76805a23c91d7--


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 16:05:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 16:05:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJfrJ-0005g2-OE; Wed, 01 Apr 2020 16:04:53 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJfrI-0005fx-L1
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 16:04:52 +0000
X-Inumbo-ID: 81b4c472-7432-11ea-baf8-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 81b4c472-7432-11ea-baf8-12813bfff9fa;
 Wed, 01 Apr 2020 16:04:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=WZgFTQNNNkF7AJ5ZZ+xZm6sT5FPwS6oZPQgzuujVwIY=; b=XSUKDNeohS94zBMzWGdqqdn7S
 g1+nkg2/s6mLqJ4jjGfDgt+5NIx6btPpCjE1lQMzhI02z0gmcYWgpP4ul2E/Erp2j1kl4CBy7gqG0
 cC3+7ioHJrjBjUzq3j2UFJIiaflc+hBGy15WDTPKFpxYoK/6WzPXQ1gQvirYOZhoEvTmg=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJfrB-0006qw-Uc; Wed, 01 Apr 2020 16:04:45 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJfrB-0005og-Gn; Wed, 01 Apr 2020 16:04:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJfrB-00048F-GD; Wed, 01 Apr 2020 16:04:45 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149284-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149284: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=3925402f5dd7ae93010c48688eb64f880c794267
X-Osstest-Versions-That: xen=897b6f4b4324b7696602fe386b5ea93506415442
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 16:04:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  3925402f5dd7ae93010c48688eb64f880c794267
baseline version:
 xen                  897b6f4b4324b7696602fe386b5ea93506415442

Last test of basis   149278  2020-04-01 10:01:56 Z    0 days
Testing same since   149284  2020-04-01 13:01:36 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monné <roger.pau@citrix.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   897b6f4b43..3925402f5d  3925402f5dd7ae93010c48688eb64f880c794267 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 16:14:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 16:14:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJg0S-0006Xd-OH; Wed, 01 Apr 2020 16:14:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OTHm=5R=redhat.com=philmd@srs-us1.protection.inumbo.net>)
 id 1jJg0R-0006XW-8y
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 16:14:19 +0000
X-Inumbo-ID: d6c43aaa-7433-11ea-83d8-bc764e2007e4
Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id d6c43aaa-7433-11ea-83d8-bc764e2007e4;
 Wed, 01 Apr 2020 16:14:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1585757658;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=ao7dCKGnlZKFlEK7iPffU2e9tqVZy7nJlMRwqLi4mW4=;
 b=HbAAIFlG7BOyvOvcZZTq9ptpJUGV6U8QSiJsMhY3SJOcllHoviUkK80hIJL802OymtOERn
 TbnrGjohIpgohKcdhCDpEtgAf47yUg4DBsJAsHEqf0ullfnl9k4NfEp01Ae1fPv88ZS9xW
 4FhJEdnhJidBHB1N9BvC8bm/ZSwnAt8=
Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com
 [209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-257-DjObJuqsPiOgmloFrihLlQ-1; Wed, 01 Apr 2020 12:14:14 -0400
X-MC-Unique: DjObJuqsPiOgmloFrihLlQ-1
Received: by mail-ed1-f70.google.com with SMTP id i61so383886edc.2
 for <xen-devel@lists.xenproject.org>; Wed, 01 Apr 2020 09:14:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:to:cc:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=ao7dCKGnlZKFlEK7iPffU2e9tqVZy7nJlMRwqLi4mW4=;
 b=EEmSAHzgZkawh/2nHVrS0U01d19ysPXjY8A4iWooBT//jGlsM0GBP1rdA+2mTvYw91
 wnbcAvNS5hzIhhtCOzxYqH3P4V/StZPAKC9O4zbv5fMSP7htA4e+XYeCRldvR6VxutyB
 njkE47hMKYoDDhzc7SyTLNyXd/komZAhVVXulkBnZgNc0vNSzunwp9zGolbnf2u6H/Zn
 FVGWXh2ai5M9KVDypdXR6z+GtQyhVUdHroBiLBt3zk4uskaMqXUZW3yi1hwTWgLIPi5S
 9rPZqt+rTEZXXOpkP0IwHLnhlwLCXVWgsXh0Z6bDYMeNTz6ovDDBMD/5XdwVcqkSk0R7
 6WJA==
X-Gm-Message-State: ANhLgQ03Lb2vZg4pKaVH32Yts7Zqsf1/WY3M3M8yIS1oC7cGahI/3r+R
 aEBisOic2YKX15sqsATB8SKJuLgJaJ0wVxDXC/CRKIFfCjw2pbViqZWf7rHoVvwZYw2UiUvxvhZ
 TsnL+DH9msTA1iwIxWZc2hNWpCu0=
X-Received: by 2002:a17:906:e4a:: with SMTP id
 q10mr21678241eji.371.1585757653160; 
 Wed, 01 Apr 2020 09:14:13 -0700 (PDT)
X-Google-Smtp-Source: ADFU+vsjnTYrLetXganFy1+x4jIgAoh3U67ltaGOBxp9JVwwaj8Mw4R++cOP/Du2iwlYwz1vPgCOVQ==
X-Received: by 2002:a17:906:e4a:: with SMTP id
 q10mr21678214eji.371.1585757652855; 
 Wed, 01 Apr 2020 09:14:12 -0700 (PDT)
Received: from [192.168.1.39] (116.red-83-42-57.dynamicip.rima-tde.net.
 [83.42.57.116])
 by smtp.gmail.com with ESMTPSA id f5sm634783ejc.70.2020.04.01.09.14.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 01 Apr 2020 09:14:12 -0700 (PDT)
Subject: Re: [Qemu-devel] [PULL 06/25] xen: create xenstore areas for
 XenDevice-s
To: Anthony PERARD <anthony.perard@citrix.com>, qemu-devel@nongnu.org
References: <20190114135154.16826-1-anthony.perard@citrix.com>
 <20190114135154.16826-7-anthony.perard@citrix.com>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <philmd@redhat.com>
Message-ID: <772fab5a-59ab-050f-9fef-f3b050cfc5cd@redhat.com>
Date: Wed, 1 Apr 2020 18:14:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20190114135154.16826-7-anthony.perard@citrix.com>
Content-Language: en-US
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Paul Durrant <paul@xen.org>,
 Markus Armbruster <armbru@redhat.com>,
 Peter Maydell <peter.maydell@linaro.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Anthony, Paul.

Cc'ing Markus too.

On 1/14/19 2:51 PM, Anthony PERARD wrote:
> From: Paul Durrant <paul.durrant@citrix.com>
> 
> This patch adds a new source module, xen-bus-helper.c, which builds on
> basic libxenstore primitives to provide functions to create (setting
> permissions appropriately) and destroy xenstore areas, and functions to
> 'printf' and 'scanf' nodes therein. The main xen-bus code then uses
> these primitives [1] to initialize and destroy the frontend and backend
> areas for a XenDevice during realize and unrealize respectively.
> 
> The 'xen-block' implementation is extended with a 'get_name' method that
> returns the VBD number. This number is required to 'name' the xenstore
> areas.
> 
> NOTE: An exit handler is also added to make sure the xenstore areas are
>        cleaned up if QEMU terminates without devices being unrealized.
> 
> [1] The 'scanf' functions are actually not yet needed, but they will be
>      needed by code delivered in subsequent patches.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Reviewed-by: Anthony Perard <anthony.perard@citrix.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>   hw/block/xen-block.c            |   9 +
>   hw/xen/Makefile.objs            |   2 +-
>   hw/xen/trace-events             |  12 +-
>   hw/xen/xen-bus-helper.c         | 150 +++++++++++++++
>   hw/xen/xen-bus.c                | 321 +++++++++++++++++++++++++++++++-
>   include/hw/xen/xen-bus-helper.h |  39 ++++
>   include/hw/xen/xen-bus.h        |  12 ++
>   7 files changed, 540 insertions(+), 5 deletions(-)
>   create mode 100644 hw/xen/xen-bus-helper.c
>   create mode 100644 include/hw/xen/xen-bus-helper.h
> 
[...]
> +static void xen_device_exit(Notifier *n, void *data)
> +{
> +    XenDevice *xendev = container_of(n, XenDevice, exit);
> +
> +    xen_device_unrealize(DEVICE(xendev), &error_abort);
>   }
>   
>   static void xen_device_realize(DeviceState *dev, Error **errp)
>   {
>       XenDevice *xendev = XEN_DEVICE(dev);
>       XenDeviceClass *xendev_class = XEN_DEVICE_GET_CLASS(xendev);
> +    XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
>       const char *type = object_get_typename(OBJECT(xendev));
>       Error *local_err = NULL;
>   
> -    trace_xen_device_realize(type);
> +    if (xendev->frontend_id == DOMID_INVALID) {
> +        xendev->frontend_id = xen_domid;
> +    }
> +
> +    if (xendev->frontend_id >= DOMID_FIRST_RESERVED) {
> +        error_setg(errp, "invalid frontend-id");
> +        goto unrealize;
> +    }
> +
> +    if (!xendev_class->get_name) {
> +        error_setg(errp, "get_name method not implemented");
> +        goto unrealize;
> +    }
> +
> +    xendev->name = xendev_class->get_name(xendev, &local_err);
> +    if (local_err) {
> +        error_propagate_prepend(errp, local_err,
> +                                "failed to get device name: ");
> +        goto unrealize;
> +    }
> +
> +    trace_xen_device_realize(type, xendev->name);
> +
> +    xen_device_backend_create(xendev, &local_err);
> +    if (local_err) {
> +        error_propagate(errp, local_err);
> +        goto unrealize;
> +    }
> +
> +    xen_device_frontend_create(xendev, &local_err);
> +    if (local_err) {
> +        error_propagate(errp, local_err);
> +        goto unrealize;
> +    }
>   
>       if (xendev_class->realize) {
>           xendev_class->realize(xendev, &local_err);
> @@ -72,18 +364,43 @@ static void xen_device_realize(DeviceState *dev, Error **errp)
>           }
>       }
>   
> +    xen_device_backend_printf(xendev, "frontend", "%s",
> +                              xendev->frontend_path);
> +    xen_device_backend_printf(xendev, "frontend-id", "%u",
> +                              xendev->frontend_id);
> +    xen_device_backend_printf(xendev, "online", "%u", 1);
> +    xen_device_backend_printf(xendev, "hotplug-status", "connected");
> +
> +    xen_device_backend_set_state(xendev, XenbusStateInitWait);
> +
> +    xen_device_frontend_printf(xendev, "backend", "%s",
> +                               xendev->backend_path);
> +    xen_device_frontend_printf(xendev, "backend-id", "%u",
> +                               xenbus->backend_id);
> +
> +    xen_device_frontend_set_state(xendev, XenbusStateInitialising);
> +
> +    xendev->exit.notify = xen_device_exit;
> +    qemu_add_exit_notifier(&xendev->exit);
>       return;
>   
>   unrealize:
>       xen_device_unrealize(dev, &error_abort);

It seems if unrealize() fails, the error stored in &local_err is never 
reported. Not sure if this can be improved although.

>   }
>   
> +static Property xen_device_props[] = {
> +    DEFINE_PROP_UINT16("frontend-id", XenDevice, frontend_id,
> +                       DOMID_INVALID),
> +    DEFINE_PROP_END_OF_LIST()
> +};
> +
>   static void xen_device_class_init(ObjectClass *class, void *data)
>   {
>       DeviceClass *dev_class = DEVICE_CLASS(class);
>   
>       dev_class->realize = xen_device_realize;
>       dev_class->unrealize = xen_device_unrealize;
> +    dev_class->props = xen_device_props;
>       dev_class->bus_type = TYPE_XEN_BUS;
>   }
>   
[...]



From xen-devel-bounces@lists.xenproject.org Wed Apr 01 16:26:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 16:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJgBp-0007Ql-Se; Wed, 01 Apr 2020 16:26:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=wqBo=5R=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jJgBo-0007Qg-MS
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 16:26:04 +0000
X-Inumbo-ID: 7b54ad88-7435-11ea-9e09-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7b54ad88-7435-11ea-9e09-bc764e2007e4;
 Wed, 01 Apr 2020 16:26:04 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 7E90320857;
 Wed,  1 Apr 2020 16:26:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1585758363;
 bh=jTuiabkMUB+BryK/itTwJrMK6Z5wf/hT7kVol1hb7gw=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=clZEB+sFmPJbcVd5DPsM5tzHFuCkkiJq2kSievgHRDS9v2vx4XYth3dS9jXS8zjka
 Z9fdjOTh9bp6dTgYeX8/LABtEHzt/Qos/57FhiCF//yv8UWctT3twLIqJD/Tw/+N5a
 5i7JwQEl/+QGByqcleONvwFqwirqWt6oeYuszXmo=
Date: Wed, 1 Apr 2020 09:26:03 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Andrei Cherechesu <andrei.cherechesu@nxp.com>
Subject: Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second
 stage MMU.
In-Reply-To: <VI1PR04MB505609C8A448B9FF84EDD667F9C90@VI1PR04MB5056.eurprd04.prod.outlook.com>
Message-ID: <alpine.DEB.2.21.2004010916070.10657@sstabellini-ThinkPad-T480s>
References: <VI1PR04MB505609C8A448B9FF84EDD667F9C90@VI1PR04MB5056.eurprd04.prod.outlook.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 1 Apr 2020, Andrei Cherechesu wrote:
> Hi,
> 
> And thanks for your help.
> 
> > Great to hear!
> > 
> > 
> > > However, I am encountering another problem now: in Dom0 and in 
> > > dom0less-booted DomUs, I cannot use /dev/hvc0.
> > 
> > For dom0less-booted DomUs it is normal because they don't get a PV console,
> > they get an emulated PL011 UART instead.  Make sure to have a "vpl011" tag in
> > device tree to enable it (ImageBuilder generates it by default.) The device
> > name is usually ttyAMA0.
> 
> Ok, understood. I had my vpl011 tag in the dom0less DomUs nodes in the DT,
> so that's not the problem. I am able to see DomUs boot prompt when booting
> dom0less. The problem is after DomU boots, that I am not able to switch to
> its console from Dom0, in order to be able to log in.

It looks like the UART driver in Xen is not working properly; it doesn't
seem to be a dom0less issue.


> > > Even though I'm specifying "console=hvc0" in dom0-bootargs, when dom0 
> > > finishes booting, it looks like I cannot use the getty spawned on /dev/hvc0.
> > >
> > > This is the end of the boot log:
> > > [    2.947845] random: rngd: uninitialized urandom read (4 bytes read)
> > > [    2.958415] random: rngd: uninitialized urandom read (4 bytes read)
> > > [    2.965452] random: rngd: uninitialized urandom read (2500 bytes read)
> > > .
> > > [    2.972410] random: crng init done
> > > Starting OpenBSD Secure Shell server: sshd done.
> > > Starting /usr/sbin/xenstored...
> > > Setting domain 0 name, domid and JSON config...
> > > Done setting up Dom0
> > > Starting xenconsoled...
> > > Starting QEMU as disk backend for dom0 Starting domain watchdog 
> > > daemon: xenwatchdogd startup
> > >
> > > [done]
> > >
> > > Auto Linux BSP 1.0 s32g274aevb /dev/hvc0
> > >
> > > s32g274aevb login:
> > > Auto Linux BSP 1.0 s32g274aevb /dev/ttyLF0
> > >
> > > s32g274aevb login:
> > >
> > > ----- END -----
> > >
> > > It seems that the getty spawned on /dev/ttyLF0 overwrites the one 
> > > spawned on /dev/hvc0. Which I do not understand, since Dom0 should not 
> > > have access (?) directly to ttyLF0 (the serial console device on our 
> > > boards). If I remove the line which spawns the getty on ttyLF0 from 
> > > /etc/inittab, the system hangs when waiting for the username, and it does not let me type in any characters. For the record, hvc0 is added to /etc/securetty.
> > >
> > > In a system where I boot DomU via xl from Dom0, I can switch to its 
> > > console with xl console, and hvc0 works there.
> > >
> > > The problem that comes with this is that I can not use the CTRL-AAA 
> > > command to switch between Dom0 console and DomU console in a dom0less 
> > > case, and I cannot therefore test that the passthrough works. But at least Dom0 does not have an entry for it under /dev, anymore, and DomU boot prompt tells that the driver has been registered.
> > 
> > It looks like there is some kind of interference between the dom0 ttyLF0 driver and the Xen serial driver.
> > 
> > Is your Xen UART driver marking the device as "used by Xen"? See for instance the pl011 driver, at the end of
> > xen/drivers/char/pl011.c:pl011_dt_uart_init:
> > 
> >     dt_device_set_used_by(dev, DOMID_XEN);
> > 
> > Devices that are marked as "used by Xen" are not exposed to dom0, so you shouldn't see the ttyLF0 device come up in Linux at all.
> 
> I've checked my Xen UART Driver and that call is there. So ttyLF0 should be
> marked for Xen to use.
> 
> I don't have any ideas why this happens.
> 
> I've attached the driver [0], if you want to take a look.
> 
> [0] https://pastebin.com/PuXi50H0

I cannot see any issues with the driver. Can you paste the device tree
as dom0 sees it? You can access it from /proc/device-tree (you can
convert it to dts with dtc -I fs -O dts). And also the host device tree?

We should see something like the following (this example is taken from a
Xilinx ZynqMP):

1) host device tree

	serial@ff000000 {
		u-boot,dm-pre-reloc;
		compatible = "cdns,uart-r1p12", "xlnx,xuartps";
		status = "okay";
		interrupt-parent = <0x4>;
		interrupts = <0x0 0x15 0x4>;
		reg = <0x0 0xff000000 0x0 0x1000>;
		clock-names = "uart_clk", "pclk";
		power-domains = <0x26 0x21>;
		clocks = <0x3 0x38 0x3 0x1f>;
		pinctrl-names = "default";
		pinctrl-0 = <0x37>;
		cts-override;
		device_type = "serial";
		port-number = <0x0>;
	};


2) dom0 device tree

    The node is missing
     

The key is that dom0 should not see the UART node in device tree at all.

If Dom0 is seeing the node, then it is a problem with Xen that somehow
is not hiding it (see "Skip nodes used by Xen" under
xen/arch/arm/domain_build.c:handle_node)

If Dom0 is *not* seeing the node, that what is the underlying device
tree node that the dom0 driver is using to bring up /dev/ttyLF0?


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 16:45:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 16:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJgUa-0000gV-Mh; Wed, 01 Apr 2020 16:45:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FQpd=5R=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jJgUZ-0000gQ-Rf
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 16:45:27 +0000
X-Inumbo-ID: 2fedfd2e-7438-11ea-bb07-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2fedfd2e-7438-11ea-bb07-12813bfff9fa;
 Wed, 01 Apr 2020 16:45:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585759526;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=icxvwV4wEtwBIOaM20BsS4ts4bjFZhzkus5WaWxIA/c=;
 b=OybuNcGfVTRsxurYPi4VZHgfVwFWNpV2enRUXZTlNVRjFLpxtu/ApkZZ
 0knbK9bTdmui8avyRsGhgBMbNVCI76goV12oWFd6I+pO3HrvxgA3bjW7o
 hI92rUmYukGNVhwH1PDuGW10IIiTSlaEjwJy5YFIN8gEUBCDAhQbwsvvV c=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: eYHeqXxuJwGIchjVCjPGMrbGOc6JZs7UrUQbDHNm8ShyCrmgfnJJflpb+tn41zYEB3yw0n91cM
 4uO1WMK1W+ZbK9byFRS51kzRqYErkd17MJLYx9in0WqqAP4dzvCKUqt8gISOzSEYCD7heLVYc6
 5ekpm5Y7hXZIOnyn50SZLm1jHO/kjoFYVqwJ5rndrxLaRZ66DhzrURxJJ76pBRtJJErVqiRfVM
 7xVdSueE/kSJq5PC7+KpAYwKoOKhTVqpZw262yr1N6fqHtLham2XgKAcYPLIYhYewH55h2E6ZW
 xZw=
X-SBRS: 2.7
X-MesageID: 15422037
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,332,1580792400"; d="scan'208";a="15422037"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24196.50465.468849.680260@mariner.uk.xensource.com>
Date: Wed, 1 Apr 2020 17:45:21 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] timeout: adjust timeout when running nested tests
In-Reply-To: <20200401133740.64685-1-roger.pau@citrix.com>
References: <20200401133740.64685-1-roger.pau@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("[PATCH] timeout: adjust timeout when running nested tests"):
>  sub target_adjust_timeout ($$) {
>      my ($ho,$timeoutref) = @_; # $ho might be a $gho
> +    my $nestinglvl = $ho->{NestingLevel} || $ho->{Host}{NestingLevel};

I think this wannts to be // not ||.  If you agree I will fix this up
and commit.

Since what this does otherwise is to take all baremetal hosts and give
them an empty Host hash due to autovivification.

> +    if ($nestinglvl) {
> +        $adjust->(1 << $nestinglvl, "nesting level");
> +    }

I still think the use of << is very odd and I can't resist moaning
about it.  But you're the patch author so I will let you choose the
style here.

Ian.


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 16:53:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 16:53:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJgcQ-0001XC-IJ; Wed, 01 Apr 2020 16:53:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=eFaW=5R=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jJgcP-0001X7-G5
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 16:53:33 +0000
X-Inumbo-ID: 5150f36c-7439-11ea-bb07-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5150f36c-7439-11ea-bb07-12813bfff9fa;
 Wed, 01 Apr 2020 16:53:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585760012;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=zX123BAEzGmB/JY6u3KHOvBHHk5VxaoX0VwJa0EQwZ8=;
 b=MdDXRy5zrC97YANRVZfY0JgIhNvVach0IkVk+YOcrpjfQY0OlRGw9x2+
 y6p69UQ0IZFH7ZP6akp1LgpI9GW7sbT73QwqCp9z51rvmt8q3qA+qRb7L
 A060Bb9qn4hqO/ssnXUpSTvv9fIRgpZ/wAc/AMji06sfvoJBe9hAXCsEw I=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: VIq4ZR+3leZ7SXaWn/vSHYaaKM6WWJl3MvHDMnYbCG082glRnGUh4YNqtuaAi2IJ/B/6qSvpq/
 1ucx5EVh4EZLXax6/DYcfeXYW138EzFNFL+6UNCKaficfWtVYqN7OstWuyL0lVCDaYLsO4WiEZ
 aZP0QYg73vd7LJl2v7R1uOcrVhngab34JKh9x/GFyXzLhQtWAaG6BVtQ0JosHyNsnj3tEkj2O+
 W0IUr1S+lMRuGjMyZw1Tfuc35mXdaNZn9Rh8XDpC0nb9hr7KSYpBF4JZq5BZ9Azb6u7rwauCjq
 RG8=
X-SBRS: 2.7
X-MesageID: 15027000
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,332,1580792400"; d="scan'208";a="15027000"
Date: Wed, 1 Apr 2020 18:53:23 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH] timeout: adjust timeout when running nested tests
Message-ID: <20200401165323.GW28601@Air-de-Roger>
References: <20200401133740.64685-1-roger.pau@citrix.com>
 <24196.50465.468849.680260@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <24196.50465.468849.680260@mariner.uk.xensource.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 01, 2020 at 05:45:21PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH] timeout: adjust timeout when running nested tests"):
> >  sub target_adjust_timeout ($$) {
> >      my ($ho,$timeoutref) = @_; # $ho might be a $gho
> > +    my $nestinglvl = $ho->{NestingLevel} || $ho->{Host}{NestingLevel};
> 
> I think this wannts to be // not ||.  If you agree I will fix this up
> and commit.

Yes, I agree.

> Since what this does otherwise is to take all baremetal hosts and give
> them an empty Host hash due to autovivification.
> 
> > +    if ($nestinglvl) {
> > +        $adjust->(1 << $nestinglvl, "nesting level");
> > +    }
> 
> I still think the use of << is very odd and I can't resist moaning
> about it.  But you're the patch author so I will let you choose the
> style here.

Feel free to change to 2 ** $nestinglvl at commit, you are the
maintainer so it's important that you can read the code easily.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 17:02:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 17:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJgl5-0002QO-Lk; Wed, 01 Apr 2020 17:02:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FQpd=5R=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jJgl4-0002QH-1z
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 17:02:30 +0000
X-Inumbo-ID: 914d6ed6-743a-11ea-b4f4-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 914d6ed6-743a-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 17:02:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585760548;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=7azaohadNzDlSs+VA/4tbV5wnDOXgrMFCe3JNGE/aVQ=;
 b=H0duFxXrWcsbLTPYf27AV6J/j0ZaXurr+e8nQvg3yKmKwywCqyx8/yD5
 G3ijhV87iwFdomsxsyMtWc01/u7ImHQqETM6BaCBovTCLT76mN2b92nj/
 8YIeHoQGEfvh0N735Iz/5csVoxxc/nMFrSUEceZttGiu9SXRrtk6Aj+7b s=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Q0opW24jxZWcBJBwQEzqmXXZkC//7cvxYhdoWEd+An7hij7Upyz215mweG/FJ9YVvDr0nqbiMf
 doGZjlW1ogaISq5VVziRMXnzBxvOM8+/lLeuG4l6eLAR5vWHxIL4PqzQ2IdTJHCVzOV+8ceCC+
 AKmNJmSpa+o26IAdfc9hANvBWlOyHjw3jFLYjaIiN2XDa/7lhnXZ/mu5heWh/hNp8KBXG29QFn
 EfIqZDnUwZCagx28Q6L8bIOnyro3isBN+VvrnnSX7d+RURz38/FLgcHCDF+LOKddeArbwJL/BP
 eQ0=
X-SBRS: 2.7
X-MesageID: 15423654
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,332,1580792400"; d="scan'208";a="15423654"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24196.51487.713023.72745@mariner.uk.xensource.com>
Date: Wed, 1 Apr 2020 18:02:23 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] timeout: adjust timeout when running nested tests
In-Reply-To: <20200401165323.GW28601@Air-de-Roger>
References: <20200401133740.64685-1-roger.pau@citrix.com>
 <24196.50465.468849.680260@mariner.uk.xensource.com>
 <20200401165323.GW28601@Air-de-Roger>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <Ian.Jackson@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("Re: [PATCH] timeout: adjust timeout when running nested tests"):
> On Wed, Apr 01, 2020 at 05:45:21PM +0100, Ian Jackson wrote:
> > I think this wannts to be // not ||.  If you agree I will fix this up
> > and commit.
> 
> Yes, I agree.

Thanks, done and pushed.

> > Since what this does otherwise is to take all baremetal hosts and give
> > them an empty Host hash due to autovivification.
> > 
> > > +    if ($nestinglvl) {
> > > +        $adjust->(1 << $nestinglvl, "nesting level");
> > > +    }
> > 
> > I still think the use of << is very odd and I can't resist moaning
> > about it.  But you're the patch author so I will let you choose the
> > style here.
> 
> Feel free to change to 2 ** $nestinglvl at commit, you are the
> maintainer so it's important that you can read the code easily.

I'll keep the version you tested rather than messing about with it...

Ian.


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 17:02:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 17:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJgl0-0002Pb-CO; Wed, 01 Apr 2020 17:02:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N9LQ=5R=gmail.com=dunlapg@srs-us1.protection.inumbo.net>)
 id 1jJgkz-0002PW-37
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 17:02:25 +0000
X-Inumbo-ID: 8e5acf0c-743a-11ea-83d8-bc764e2007e4
Received: from mail-ed1-x533.google.com (unknown [2a00:1450:4864:20::533])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8e5acf0c-743a-11ea-83d8-bc764e2007e4;
 Wed, 01 Apr 2020 17:02:23 +0000 (UTC)
Received: by mail-ed1-x533.google.com with SMTP id a20so792663edj.2
 for <xen-devel@lists.xenproject.org>; Wed, 01 Apr 2020 10:02:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=umich.edu; s=google-2016-06-03;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=cQh6fYzXhvJNcO2hn+pkFEQjxvmHkAHYbfxx6QdgR/s=;
 b=UtWeoNn6IppFL4deq7SnmSTOp4zMnHlpZiM3hsczG9hnEp3OOAwhqLDb5IMpJZdOLl
 pR3oD+Q5HYQnnZ3d0qBklTKTzByJV5arKCjw3en3G+3u89SO9vJP6/JcVSVNhKDpyK4D
 N4yDP7U290s3abXCkjgO8t6LNWSvgpLpgVwvz9VC5SbhMOLnBprxj37/CYzoxFq97113
 UxmMr/0V0n0FcFAsp5D1hZS9LHqDBLS9EapVDL6G2BFwetuqav2MsUqFOYR+j0bWDITr
 7XMSB3uUvlf3pNbBkKarhqLxgVfcZs1sXgnnHGz87kGMqe0n0i+OsA25VnzZQEEajaA9
 TB0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=cQh6fYzXhvJNcO2hn+pkFEQjxvmHkAHYbfxx6QdgR/s=;
 b=mSbTznrF48NIo26tmm5v1fTVWlYrp6cRT6Pk5yIHAIRl8iRO7FVWmeqplUYjwjKWX2
 ZbG8vzFjB84SauXZDLlsPiZXhn0/inSfzOWkXh7qhVNh/UZlIkCMF3lCDngGcNtEJLaM
 H6WsCUWuyW7bAAi40CjShT6AloMkgRgjrMQk57W5T/gslItbNzu1qlO77d/AKJv1RBs4
 HKrjKkbGQO633EUa5OZu7UMkQ80ofUQdqhrkRt7NexQWKyfG2TSfVS71sNbp1bBSgqmx
 dcCu14hWg9IWxZFhDl1iV1RWUsgw1FQ7o1OTdQmv3CdbB0ia+NGwvRM8bBHtNuo/MVVu
 V+eQ==
X-Gm-Message-State: ANhLgQ3O8KTW6UV/CBxS8YEPTHNBHILJFkGbZt8Yu1+C1ANc8QdHiNmN
 UB2IK6k+Oajv0CFjtWKDNsxjDdBBjcPc5xGsyvQ=
X-Google-Smtp-Source: ADFU+vuXAkLwelVjzC+VwiQGabnAxVGQjnoYc12Qeu5R77A+f5AOkeCwuIF4sire6h0QTgErz0hloT9KeglR639oOhc=
X-Received: by 2002:a05:6402:31ad:: with SMTP id
 dj13mr9310871edb.60.1585760543001; 
 Wed, 01 Apr 2020 10:02:23 -0700 (PDT)
MIME-Version: 1.0
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <A33FEB65-F844-4CA6-BAE0-F0C881CFD381@arm.com>
In-Reply-To: <A33FEB65-F844-4CA6-BAE0-F0C881CFD381@arm.com>
From: George Dunlap <dunlapg@umich.edu>
Date: Wed, 1 Apr 2020 18:02:11 +0100
Message-ID: <CAFLBxZYYWOS8D2-YPFWZ2n4RdPTOjfmzMpYby4JYSQ_rJM_zBw@mail.gmail.com>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
Content-Type: multipart/alternative; boundary="000000000000dd526205a23da5c2"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Wei Xu <xuwei5@hisilicon.com>, nd <nd@arm.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--000000000000dd526205a23da5c2
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 1, 2020 at 10:54 AM Bertrand Marquis <Bertrand.Marquis@arm.com>
wrote:

>
>
> On 1 Apr 2020, at 09:30, Julien Grall <julien@xen.org> wrote:
>
>
>
> On 01/04/2020 01:57, Stefano Stabellini wrote:
>
> On Mon, 30 Mar 2020, Julien Grall wrote:
>
> Hi Stefano,
>
> On 30/03/2020 17:35, Stefano Stabellini wrote:
>
> On Sat, 28 Mar 2020, Julien Grall wrote:
>
> qHi Stefano,
>
> On 27/03/2020 02:34, Stefano Stabellini wrote:
>
> This is a simple implementation of GICD_ICACTIVER / GICD_ISACTIVER
> reads. It doesn't take into account the latest state of interrupts on
> other vCPUs. Only the current vCPU is up-to-date. A full solution is
> not possible because it would require synchronization among all vCPUs,
> which would be very expensive in terms or latency.
>
>
> Your sentence suggests you have number showing that correctly emulating
> the
> registers would be too slow. Mind sharing them?
>
>
> No, I don't have any numbers. Would you prefer a different wording or a
> better explanation? I also realized there is a typo in there (or/of).
>
> Let me start with I think correctness is more important than speed.
> So I would have expected your commit message to contain some fact why
> synchronization is going to be slow and why this is a problem.
>
> To give you a concrete example, the implementation of set/way instructions
> are
> really slow (it could take a few seconds depending on the setup). However,
> this was fine because not implementing them correctly would have a greater
> impact on the guest (corruption) and they are not used often.
>
> I don't think the performance in our case will be in same order magnitude.
> It
> is most likely to be in the range of milliseconds (if not less) which I
> think
> is acceptable for emulation (particularly for the vGIC) and the current
> uses.
>
> Writing on the mailing list some of our discussions today.
> Correctness is not just in terms of compliance to a specification but it
> is also about not breaking guests. Introducing latency in the range of
> milliseconds, or hundreds of microseconds, would break any latency
> sensitive workloads. We don't have numbers so we don't know for certain
> the effect that your suggestion would have.
>
>
> You missed part of the discussion. I don't disagree that latency is
> important. However, if an implementation is only 95% reliable, then it
> means 5% of the time your guest may break (corruption, crash, deadlock...).
> At which point the latency is the last of your concern.
>
> It would be interesting to have those numbers, and I'll add to my TODO
> list to run the experiments you suggested, but I'll put it on the
> back-burner (from a Xilinx perspective it is low priority as no
> customers are affected.)
>
>
> How about we get a correct implementation merge first and then discuss
> about optimization? This would allow the community to check whether there
> are actually noticeable latency in their workload.
>
>
> Hi,
>
> I am not sure that pushing something with a performance impact to later
> fix it is the right approach here.
>
> The patch is an improvement compared to the current code and it can be
> further improved later to handle more cases (other cores).
>
> If we really have to sync all vCPUs here, this will cost a lot and the
> result will still be the status in the past in fact because nothing will
> make sure that at the point the guest gets back the value it is still valid.
>

The same is true on real hardware, right?

Looking at this discussion as a non-ARM person, it sounds a bit like ARM
specified this in a way that was useless-but-easy-to-implement-so-why-not;
but it turns out to be useless-but-hard-to-implement virtualized.

On the one hand, I'm sympathetic to Julien's point of view; I very much
don't like the idea of silently changing behavior just because the
specified behavior is inconvenient for us.

On the other hand, I'm sympathetic to Stefano's point of view, that it's
pointless to introduce a load of overhead and jitter to implement behavior
which nobody in their right mind would even want to use (at least
virtualized).

What I think would be *ideal* would be for ARM to change the specification
to make it easier virtualize.  For instance:, by specifying that the
register *may* contain information about other cores, but may not; or, that
the register will contain information on other cores on real hardware, but
not virtualized.

Barring that, I think we should have a centralized place to document
deviations from the spec; and I think changes to this spec should be
coordinated with KVM (and maybe ACRN?), to minimize hypervisor-specific
deviations.

Thoughts?

 -George

--000000000000dd526205a23da5c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 1, 2020 at 10:54 AM Bertr=
and Marquis &lt;<a href=3D"mailto:Bertrand.Marquis@arm.com">Bertrand.Marqui=
s@arm.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">



<div style=3D"overflow-wrap: break-word;">
<br>
<div><br>
<blockquote type=3D"cite">
<div>On 1 Apr 2020, at 09:30, Julien Grall &lt;<a href=3D"mailto:julien@xen=
.org" target=3D"_blank">julien@xen.org</a>&gt; wrote:</div>
<br>
<div><br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;fo=
nt-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:=
start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px;text-decoration:none">
<br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va=
riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te=
xt-decoration:none">
<span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-=
variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
text-decoration:none;float:none;display:inline">On
 01/04/2020 01:57, Stefano Stabellini wrote:</span><br style=3D"font-family=
:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-w=
eight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<blockquote type=3D"cite" style=3D"font-family:Helvetica;font-size:12px;fon=
t-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;text-decoration:none">
On Mon, 30 Mar 2020, Julien Grall wrote:<br>
<blockquote type=3D"cite">Hi Stefano,<br>
<br>
On 30/03/2020 17:35, Stefano Stabellini wrote:<br>
<blockquote type=3D"cite">On Sat, 28 Mar 2020, Julien Grall wrote:<br>
<blockquote type=3D"cite">qHi Stefano,<br>
<br>
On 27/03/2020 02:34, Stefano Stabellini wrote:<br>
<blockquote type=3D"cite">This is a simple implementation of GICD_ICACTIVER=
 / GICD_ISACTIVER<br>
reads. It doesn&#39;t take into account the latest state of interrupts on<b=
r>
other vCPUs. Only the current vCPU is up-to-date. A full solution is<br>
not possible because it would require synchronization among all vCPUs,<br>
which would be very expensive in terms or latency.<br>
</blockquote>
<br>
Your sentence suggests you have number showing that correctly emulating<br>
the<br>
registers would be too slow. Mind sharing them?<br>
</blockquote>
<br>
No, I don&#39;t have any numbers. Would you prefer a different wording or a=
<br>
better explanation? I also realized there is a typo in there (or/of).<br>
</blockquote>
Let me start with I think correctness is more important than speed.<br>
So I would have expected your commit message to contain some fact why<br>
synchronization is going to be slow and why this is a problem.<br>
<br>
To give you a concrete example, the implementation of set/way instructions =
are<br>
really slow (it could take a few seconds depending on the setup). However,<=
br>
this was fine because not implementing them correctly would have a greater<=
br>
impact on the guest (corruption) and they are not used often.<br>
<br>
I don&#39;t think the performance in our case will be in same order magnitu=
de. It<br>
is most likely to be in the range of milliseconds (if not less) which I thi=
nk<br>
is acceptable for emulation (particularly for the vGIC) and the current use=
s.<br>
</blockquote>
Writing on the mailing list some of our discussions today.<br>
Correctness is not just in terms of compliance to a specification but it<br=
>
is also about not breaking guests. Introducing latency in the range of<br>
milliseconds, or hundreds of microseconds, would break any latency<br>
sensitive workloads. We don&#39;t have numbers so we don&#39;t know for cer=
tain<br>
the effect that your suggestion would have.<br>
</blockquote>
<br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va=
riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te=
xt-decoration:none">
<span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-=
variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
text-decoration:none;float:none;display:inline">You
 missed part of the discussion. I don&#39;t disagree that latency is import=
ant. However, if an implementation is only 95% reliable, then it means 5% o=
f the time your guest may break (corruption, crash, deadlock...). At which =
point the latency is the last of your
 concern.</span><br style=3D"font-family:Helvetica;font-size:12px;font-styl=
e:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;=
text-align:start;text-indent:0px;text-transform:none;white-space:normal;wor=
d-spacing:0px;text-decoration:none">
<br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va=
riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te=
xt-decoration:none">
<blockquote type=3D"cite" style=3D"font-family:Helvetica;font-size:12px;fon=
t-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;text-decoration:none">
It would be interesting to have those numbers, and I&#39;ll add to my TODO<=
br>
list to run the experiments you suggested, but I&#39;ll put it on the<br>
back-burner (from a Xilinx perspective it is low priority as no<br>
customers are affected.)<br>
</blockquote>
<br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va=
riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te=
xt-decoration:none">
<span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-=
variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
text-decoration:none;float:none;display:inline">How
 about we get a correct implementation merge first and then discuss about o=
ptimization? This would allow the community to check whether there are actu=
ally noticeable latency in their workload.</span><br style=3D"font-family:H=
elvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-wei=
ght:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tran=
sform:none;white-space:normal;word-spacing:0px;text-decoration:none">
</div>
</blockquote>
<div><br>
</div>
<div>Hi,</div>
<div><br>
</div>
<div>I am not sure that pushing something with a performance impact to late=
r fix it is the right approach here.</div>
<div><br>
</div>
<div>The patch is an improvement compared to the current code and it can be=
 further improved later to handle more cases (other cores).</div>
<div><br>
</div>
<div>If we really have to sync all vCPUs here, this will cost a lot and the=
 result will still be the status in the past in fact because nothing will m=
ake sure that at the point the guest gets back the value it is still valid.=
</div></div></div></blockquote><div><br></div><div>The same is true on real=
 hardware, right?</div><div><br></div><div>Looking at this discussion as a =
non-ARM person, it sounds a bit like ARM specified this in a way that was u=
seless-but-easy-to-implement-so-why-not; but it turns out to be useless-but=
-hard-to-implement virtualized.</div><div><br></div><div>On the one hand, I=
&#39;m sympathetic to Julien&#39;s point of view; I very much don&#39;t lik=
e the idea of silently changing behavior just because the specified behavio=
r is inconvenient for us.</div><div><br></div><div>On the other hand, I&#39=
;m sympathetic to Stefano&#39;s point of view, that it&#39;s pointless to i=
ntroduce a load of overhead and jitter to implement behavior which nobody i=
n their right mind would even want to use (at least virtualized).<br></div>=
<div><br></div><div>What I think would be *ideal* would be for ARM to chang=
e the specification to make it easier virtualize.=C2=A0 For instance:, by s=
pecifying that the register *may* contain information about other cores, bu=
t may not; or, that the register will contain information on other cores on=
 real hardware, but not virtualized.<br></div><div><br></div>Barring that, =
I think we should have a centralized place to document deviations from the =
spec; and I think changes to this spec should be coordinated with KVM (and =
maybe ACRN?), to minimize hypervisor-specific deviations.</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Thoughts?</div><div c=
lass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">=C2=A0-George<br>=
</div></div>

--000000000000dd526205a23da5c2--


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 17:23:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 17:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJh5d-0004LO-2Q; Wed, 01 Apr 2020 17:23:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJh5b-0004LI-I5
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 17:23:43 +0000
X-Inumbo-ID: 88fbf29a-743d-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 88fbf29a-743d-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 17:23:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=dez60WFmQARuimyyHdsmWhscLRipnQ9LRf51YJJGE+I=; b=5n9eFk8tVWchgqfS9WRoIfRlJI
 veW4ucxQ7mhpPCSewnzgCDv9XcmrwchGwOy2XENhb9DN8hNICeI3JQrx8Z0muzIWq0gQpDhF6xkyU
 GiqH0qTqFdLrOGn9vqxlIQGVd8RNVn4r7ZdxJ93slgc/J9GonUHTuvAr/g7MxmX6BXT0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJh5T-0008LD-1C; Wed, 01 Apr 2020 17:23:35 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJh5S-0000Sv-QU; Wed, 01 Apr 2020 17:23:34 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <A33FEB65-F844-4CA6-BAE0-F0C881CFD381@arm.com>
From: Julien Grall <julien@xen.org>
Message-ID: <5e788594-93bd-4bf0-1113-5d55a4f5f8bc@xen.org>
Date: Wed, 1 Apr 2020 18:23:32 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <A33FEB65-F844-4CA6-BAE0-F0C881CFD381@arm.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 "George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
 Wei Xu <xuwei5@hisilicon.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 nd <nd@arm.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 01/04/2020 10:54, Bertrand Marquis wrote:
> 
> 
>> On 1 Apr 2020, at 09:30, Julien Grall <julien@xen.org 
>> <mailto:julien@xen.org>> wrote:
>>
>>
>>
>> On 01/04/2020 01:57, Stefano Stabellini wrote:
>>> On Mon, 30 Mar 2020, Julien Grall wrote:
>>>> Hi Stefano,
>>>>
>>>> On 30/03/2020 17:35, Stefano Stabellini wrote:
>>>>> On Sat, 28 Mar 2020, Julien Grall wrote:
>>>>>> qHi Stefano,
>>>>>>
>>>>>> On 27/03/2020 02:34, Stefano Stabellini wrote:
>>>>>>> This is a simple implementation of GICD_ICACTIVER / GICD_ISACTIVER
>>>>>>> reads. It doesn't take into account the latest state of interrupts on
>>>>>>> other vCPUs. Only the current vCPU is up-to-date. A full solution is
>>>>>>> not possible because it would require synchronization among all 
>>>>>>> vCPUs,
>>>>>>> which would be very expensive in terms or latency.
>>>>>>
>>>>>> Your sentence suggests you have number showing that correctly 
>>>>>> emulating
>>>>>> the
>>>>>> registers would be too slow. Mind sharing them?
>>>>>
>>>>> No, I don't have any numbers. Would you prefer a different wording or a
>>>>> better explanation? I also realized there is a typo in there (or/of).
>>>> Let me start with I think correctness is more important than speed.
>>>> So I would have expected your commit message to contain some fact why
>>>> synchronization is going to be slow and why this is a problem.
>>>>
>>>> To give you a concrete example, the implementation of set/way 
>>>> instructions are
>>>> really slow (it could take a few seconds depending on the setup). 
>>>> However,
>>>> this was fine because not implementing them correctly would have a 
>>>> greater
>>>> impact on the guest (corruption) and they are not used often.
>>>>
>>>> I don't think the performance in our case will be in same order 
>>>> magnitude. It
>>>> is most likely to be in the range of milliseconds (if not less) 
>>>> which I think
>>>> is acceptable for emulation (particularly for the vGIC) and the 
>>>> current uses.
>>> Writing on the mailing list some of our discussions today.
>>> Correctness is not just in terms of compliance to a specification but it
>>> is also about not breaking guests. Introducing latency in the range of
>>> milliseconds, or hundreds of microseconds, would break any latency
>>> sensitive workloads. We don't have numbers so we don't know for certain
>>> the effect that your suggestion would have.
>>
>> You missed part of the discussion. I don't disagree that latency is 
>> important. However, if an implementation is only 95% reliable, then it 
>> means 5% of the time your guest may break (corruption, crash, 
>> deadlock...). At which point the latency is the last of your concern.
>>
>>> It would be interesting to have those numbers, and I'll add to my TODO
>>> list to run the experiments you suggested, but I'll put it on the
>>> back-burner (from a Xilinx perspective it is low priority as no
>>> customers are affected.)
>>
>> How about we get a correct implementation merge first and then discuss 
>> about optimization? This would allow the community to check whether 
>> there are actually noticeable latency in their workload.
> 
> Hi,

Hi,

> I am not sure that pushing something with a performance impact to later 
> fix it is the right approach here.
> 
> The patch is an improvement compared to the current code and it can be 
> further improved later to handle more cases (other cores).

If you read my other answer on this patch you will see that this is 
going to introduce a deadlock in the guest using multiple vCPUs. How is 
it an improvement compare to today?

> If we really have to sync all vCPUs here, this will cost a lot and the 
> result will still be the status in the past in fact because nothing will 
> make sure that at the point the guest gets back the value it is still valid.

I hope you are aware the problem is exactly the same in the hardware. As 
soon as you read the ISACTIVER, then the value may not be correct 
anymore. So I don't see the issue to have an outdated value here.

As I said to Stefano yesterday, I would be happy to compromise as long 
as the implementation does not introduce an outright deadlock in the guest.

At the moment, I don't have a better approach than kick all the vCPUs. 
Feel free to suggest a better one.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 17:56:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 17:56:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJhbQ-0006rD-Qt; Wed, 01 Apr 2020 17:56:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJhbP-0006r8-NF
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 17:56:35 +0000
X-Inumbo-ID: 205c7d22-7442-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 205c7d22-7442-11ea-9e09-bc764e2007e4;
 Wed, 01 Apr 2020 17:56:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ksTC+u7gQ1FJKIeMQAsNPrZmU5yDR8+00nALcVx2r3U=; b=nz7d3RvzzDui4VKNV4Rd7rC164
 VoGfGwTx4axWSE4km2l00C3ewqKZnUM/ForhaRkHv7QnqZHQu6b8+Q7bA/ouwWoe7I3V1CoTGOFVj
 DY6ST7VIRuuWnIay/SPO5+N1O26KLn4Ccs0HOgw28QT3aJQW54biuTBoEu8i+/+AXDBM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJhbM-0000W8-JK; Wed, 01 Apr 2020 17:56:32 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJhbM-0002RV-6f; Wed, 01 Apr 2020 17:56:32 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: George Dunlap <dunlapg@umich.edu>,
 Bertrand Marquis <Bertrand.Marquis@arm.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <A33FEB65-F844-4CA6-BAE0-F0C881CFD381@arm.com>
 <CAFLBxZYYWOS8D2-YPFWZ2n4RdPTOjfmzMpYby4JYSQ_rJM_zBw@mail.gmail.com>
From: Julien Grall <julien@xen.org>
Message-ID: <145579e0-d0d1-b12a-a84f-7698d76d2c04@xen.org>
Date: Wed, 1 Apr 2020 18:56:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CAFLBxZYYWOS8D2-YPFWZ2n4RdPTOjfmzMpYby4JYSQ_rJM_zBw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Wei Xu <xuwei5@hisilicon.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 nd <nd@arm.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 01/04/2020 18:02, George Dunlap wrote:
> 
> 
> On Wed, Apr 1, 2020 at 10:54 AM Bertrand Marquis 
> <Bertrand.Marquis@arm.com <mailto:Bertrand.Marquis@arm.com>> wrote:
> 
> 
> 
>>     On 1 Apr 2020, at 09:30, Julien Grall <julien@xen.org
>>     <mailto:julien@xen.org>> wrote:
>>
>>
>>
>>     On 01/04/2020 01:57, Stefano Stabellini wrote:
>>>     On Mon, 30 Mar 2020, Julien Grall wrote:
>>>>     Hi Stefano,
>>>>
>>>>     On 30/03/2020 17:35, Stefano Stabellini wrote:
>>>>>     On Sat, 28 Mar 2020, Julien Grall wrote:
>>>>>>     qHi Stefano,
>>>>>>
>>>>>>     On 27/03/2020 02:34, Stefano Stabellini wrote:
>>>>>>>     This is a simple implementation of GICD_ICACTIVER /
>>>>>>>     GICD_ISACTIVER
>>>>>>>     reads. It doesn't take into account the latest state of
>>>>>>>     interrupts on
>>>>>>>     other vCPUs. Only the current vCPU is up-to-date. A full
>>>>>>>     solution is
>>>>>>>     not possible because it would require synchronization among
>>>>>>>     all vCPUs,
>>>>>>>     which would be very expensive in terms or latency.
>>>>>>
>>>>>>     Your sentence suggests you have number showing that correctly
>>>>>>     emulating
>>>>>>     the
>>>>>>     registers would be too slow. Mind sharing them?
>>>>>
>>>>>     No, I don't have any numbers. Would you prefer a different
>>>>>     wording or a
>>>>>     better explanation? I also realized there is a typo in there
>>>>>     (or/of).
>>>>     Let me start with I think correctness is more important than speed.
>>>>     So I would have expected your commit message to contain some
>>>>     fact why
>>>>     synchronization is going to be slow and why this is a problem.
>>>>
>>>>     To give you a concrete example, the implementation of set/way
>>>>     instructions are
>>>>     really slow (it could take a few seconds depending on the
>>>>     setup). However,
>>>>     this was fine because not implementing them correctly would have
>>>>     a greater
>>>>     impact on the guest (corruption) and they are not used often.
>>>>
>>>>     I don't think the performance in our case will be in same order
>>>>     magnitude. It
>>>>     is most likely to be in the range of milliseconds (if not less)
>>>>     which I think
>>>>     is acceptable for emulation (particularly for the vGIC) and the
>>>>     current uses.
>>>     Writing on the mailing list some of our discussions today.
>>>     Correctness is not just in terms of compliance to a specification
>>>     but it
>>>     is also about not breaking guests. Introducing latency in the
>>>     range of
>>>     milliseconds, or hundreds of microseconds, would break any latency
>>>     sensitive workloads. We don't have numbers so we don't know for
>>>     certain
>>>     the effect that your suggestion would have.
>>
>>     You missed part of the discussion. I don't disagree that latency
>>     is important. However, if an implementation is only 95% reliable,
>>     then it means 5% of the time your guest may break (corruption,
>>     crash, deadlock...). At which point the latency is the last of
>>     your concern.
>>
>>>     It would be interesting to have those numbers, and I'll add to my
>>>     TODO
>>>     list to run the experiments you suggested, but I'll put it on the
>>>     back-burner (from a Xilinx perspective it is low priority as no
>>>     customers are affected.)
>>
>>     How about we get a correct implementation merge first and then
>>     discuss about optimization? This would allow the community to
>>     check whether there are actually noticeable latency in their workload.
> 
>     Hi,
> 
>     I am not sure that pushing something with a performance impact to
>     later fix it is the right approach here.
> 
>     The patch is an improvement compared to the current code and it can
>     be further improved later to handle more cases (other cores).
> 
>     If we really have to sync all vCPUs here, this will cost a lot and
>     the result will still be the status in the past in fact because
>     nothing will make sure that at the point the guest gets back the
>     value it is still valid.
> 
> 
> The same is true on real hardware, right?
> 
> Looking at this discussion as a non-ARM person, it sounds a bit like ARM 
> specified this in a way that was 
> useless-but-easy-to-implement-so-why-not; but it turns out to be 
> useless-but-hard-to-implement virtualized.
> 
> On the one hand, I'm sympathetic to Julien's point of view; I very much 
> don't like the idea of silently changing behavior just because the 
> specified behavior is inconvenient for us.
> 
> On the other hand, I'm sympathetic to Stefano's point of view, that it's 
> pointless to introduce a load of overhead and jitter to implement 
> behavior which nobody in their right mind would even want to use (at 
> least virtualized).
> 
> What I think would be *ideal* would be for ARM to change the 
> specification to make it easier virtualize.  For instance:, by 
> specifying that the register *may* contain information about other 
> cores, but may not; or, that the register will contain information on 
> other cores on real hardware, but not virtualized.

The goal of those registers is to give you a picture of the interrupts 
activated on your HW. For instance, this is used by Linux to properly 
synchronize pending interrupts as there would be a race otherwise.

I wrote a long e-mail a few months ago explaining why Linux is using it 
and why we should implement correctly [1].

Even on real HW, the value you read may already be incorrect (i.e an 
interrupt may have become pending).

What Stefano implemented is using a snapshot of what Xen thinks is the 
state of the vGIC. I think this is inline with the existing specification.

However, this has a major flaw because this relies on the vCPUs to exit 
for synchronization the HW state and what Xen thinks of the vGIC. We 
have configured the vGIC to not exit when the virtual interrupt is 
backed by an HW interrupt. So we need to rely on another trap for the 
synchronization.

With the NULL scheduler (and even credit2 with only 1 vCPU running per 
pCPU), the number of traps is very limited. So read the I*ACTIVER 
registers may report that an interrupt is actived for a really long time.

The result here is a thread in the guest may be blocked for a long-time.

To be brutally honest, this totally defeat the argument that "this patch 
has a better latency".

> 
> Barring that, I think we should have a centralized place to document 
> deviations from the spec; and I think changes to this spec should be 
> coordinated with KVM (and maybe ACRN?), to minimize hypervisor-specific 
> deviations.

AFAIK, KVM is implementing the ACTIVER registers the same way as 
Stefano's patch. It might be harder (or not possible) to hit the 
deadlock depending on how they configure the vGIC (i.e trap the active 
state) and the scheduling.

As I discussed with Stefano yesterday, I can accept that the state is 
not up-to-date. But I can't ignore the fact this patch is introducing a 
deadlock in some circumstance.

Cheers,

[1] 
https://lore.kernel.org/xen-devel/7289f75f-1ab2-2d42-cd88-1be5306b3072@xen.org/

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 18:06:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 18:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJhkp-0007oF-SF; Wed, 01 Apr 2020 18:06:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJhko-0007oA-At
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 18:06:18 +0000
X-Inumbo-ID: 77abacc8-7443-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 77abacc8-7443-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 18:06:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=8ppXMxDXP1DGQcakID7qIghUpcnwWNzh3F1DL63134s=; b=zSNI74c/lfCgM2jvPbb0MGNpf
 q4CBObK2EoHjeQ4HZgd62oR9jZESUkOcBRj8VSUlpckgwasGZ+Oa2EJtkLmJJN9GMAE9Xq0gNbiex
 52rxOIXUiqNMjBLDMxC7Xobh5PFckbHpaOddJveyDRiSkKDx25Lgf3q2tgji5wQiWK1Qk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJhkg-0000nK-Hy; Wed, 01 Apr 2020 18:06:10 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJhkg-0004Uo-48; Wed, 01 Apr 2020 18:06:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJhkg-0004cO-3U; Wed, 01 Apr 2020 18:06:10 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149260-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149260: regressions - FAIL
X-Osstest-Failures: xen-unstable:test-amd64-i386-qemut-rhel6hvm-amd:guest-start/redhat.repeat:fail:regression
 xen-unstable:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:regression
 xen-unstable:test-armhf-armhf-xl-vhd:guest-start/debian.repeat:fail:regression
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=5af4698d98d881e786c0909b6308f04696586c49
X-Osstest-Versions-That: xen=e19b4b3b55f84e0cfcc02fe5d66965969a81c965
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 18:06:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 149188
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail REGR. vs. 149188
 test-armhf-armhf-xl-vhd     15 guest-start/debian.repeat fail REGR. vs. 149188

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149188
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149188
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 149188
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149188
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149188
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  5af4698d98d881e786c0909b6308f04696586c49
baseline version:
 xen                  e19b4b3b55f84e0cfcc02fe5d66965969a81c965

Last test of basis   149188  2020-03-30 01:51:23 Z    2 days
Failing since        149231  2020-03-31 02:00:20 Z    1 days    2 attempts
Testing same since   149260  2020-04-01 00:06:40 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jason Andryuk <jandryuk@gmail.com>
  Simran Singhal <singhalsimran0@gmail.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      fail    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit 5af4698d98d881e786c0909b6308f04696586c49
Author: Simran Singhal <singhalsimran0@gmail.com>
Date:   Tue Mar 31 08:51:21 2020 +0200

    x86: compress lines for immediate return
    
    Compress two lines into a single line if immediate return statement is found.
    It also remove variables retval, freq, effective, vector, ovf and now
    as they are no longer needed.
    
    Signed-off-by: Simran Singhal <singhalsimran0@gmail.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    Acked-by: Jan Beulich <jbeulich@suse.com>

commit 922f59a4302939471254b91c921daa5bd7c7e3fa
Author: Simran Singhal <singhalsimran0@gmail.com>
Date:   Tue Mar 31 08:50:25 2020 +0200

    x86: remove unnecessary cast on void pointer
    
    Assignment to a typed pointer is sufficient in C.
    No cast is needed.
    
    Also, changed some u64/u32 to uint64_t/uint32_t.
    
    Signed-off-by: Simran Singhal <singhalsimran0@gmail.com>
    Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>

commit f57ae00635da429cee02373dc909542a411a09e5
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Mar 31 08:46:44 2020 +0200

    SVM: split _np_enable VMCB field
    
    The nest paging enable is actually just a single bit within the 64-bit
    VMCB field, which is particularly relevant for uses like the one in
    nsvm_vcpu_vmentry(). Split the field, adding definitions for a few other
    bits at the same time. To be able to generate accessors for bitfields,
    VMCB_ACCESSORS() needs the type part broken out, as typeof() can't be
    applied to bitfields. Unfortunately this means specification of the same
    type in two distinct places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit 2a94100dd5646fb8abcd29f48553ff10d0788cc7
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Mar 30 14:52:12 2020 +0100

    docs/README: Fix a broken url
    
    There was a / missing here.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>

commit 9465fac25ebd46a495ee10c3cebce4d7f4b32b14
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Mar 30 14:51:51 2020 +0100

    docs etc.: https: Fix references to other Xen pages
    
    Change the url scheme to https.  This is all in-tree references to
    xenbits and the main website except for those in Config.mk.
    
    We leave Config.mk alone for now because those urls are used by CI
    systems and we need to check that nothing breaks when we change the
    download method.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>

commit 7e1867b12114602b94f2630a33aa82215b1c895c
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Mar 30 14:43:06 2020 +0100

    docs etc.: https: Fix references to wiki.xen[project].org
    
    Change the url scheme to https.  This is all in-tree references to the
    Xen wiki.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>

commit b72682c602b8d1aaadca439d49cc79c79dbc17bc
Author: Jason Andryuk <jandryuk@gmail.com>
Date:   Thu Mar 12 10:54:17 2020 -0400

    scripts: Use stat to check lock claim
    
    Replace the perl locking check with stat(1).  Stat is able to fstat
    stdin (file descriptor 0) when passed '-' as an argument.  This is now
    used to check $_lockfd.  stat(1) support for '-' was introduced to
    coreutils in 2009.
    
    After A releases its lock, script B will return from flock and execute
    stat.  Since the lockfile has been removed by A, stat prints an error to
    stderr and exits non-zero.  Redirect stderr to /dev/null to avoid
    filling /var/log/xen/xen-hotplug.log with "No such file or directory"
    messages.
    
    Placing the stat call inside the "if" condition ensures we only check
    the stat output when the command completed successfully.
    
    This change removes the only runtime dependency of the xen toolstack on
    perl.
    
    Suggested-by: Ian Jackson <ian.jackson@citrix.com>
    Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
    Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>

commit 4b3f41e9d83209f5334095937aef7763da993781
Author: Simran Singhal <singhalsimran0@gmail.com>
Date:   Sun Mar 29 12:07:47 2020 +0530

    xen/x86: Remove parentheses from return arguments
    
    This patch remove unnecessary parentheses from return arguments.
    
    Signed-off-by: Simran Singhal <singhalsimran0@gmail.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    Acked-by: Jan Beulich <jbeulich@suse.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 19:59:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 19:59:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJjVx-0008DQ-QR; Wed, 01 Apr 2020 19:59:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=PyEw=5R=nxp.com=andrei.cherechesu@srs-us1.protection.inumbo.net>)
 id 1jJjVw-0008DL-T4
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 19:59:05 +0000
X-Inumbo-ID: 3aacd738-7453-11ea-bb34-12813bfff9fa
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown
 [40.107.22.76]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3aacd738-7453-11ea-bb34-12813bfff9fa;
 Wed, 01 Apr 2020 19:59:01 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Dit1T4ukL1hKrCmw2xOjE8IZNyanQ9/LnY8MWgTM0WkcmlWvze7N45IGcXT7FNNuc60TsgaaS1wGBT7ROKnePYZVGqGabrl1umUD0FTNo3Vo3b0CqNW9rG3qWaDwCAvMaBcLRuz8me9yX/nslJS+nP1nXGrAUeM8wCKyxGaNcf10K9o17Iu8bep4RU45IZCgiqcSC+E0Rq9lkoV2RwcNpQBrI9ShtPquxXa91tDXlXigaEKMUGRuL5wENiX1HeZvpB9wQwqUDnXhBvtTU/DdpUkZyJEgWmP6/Qgy3FkzxD/Rpc3fIUHk7yHn7zuZd2lAm+ebJKEWJfTlpTJWEcTQ/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tE/I1emPAL5/KLI63YzUj+lh3fOUhSLYL4/H7Ok4vLI=;
 b=ccOLaAEgw9I8/verDt/dVAk/WJwk8G1HGNnIej4yBg2Qmf66nUKCvMpkocHNVnfYP4tkuaPamIsUCsI6YPDfRhK+6TbVPr/QGCRTOnPBK1w1Hyjs/NMAsm2+HTRCFvo+AO7IlNpw7fvYKF/b1eURGUGyl1DwkQ22IS/K9KL/l4snI3uJxn6jXBLAh4qTaJ6aj6981hcFaRQWdQ576ZkyJW/wAwxjAPIB3oUbyR7gQwwXIpjla/4TfvCf8u2EqouoY2O8lJC6dXt3I+bUesQyDaW7+2a9h/Sb6XIbfQY6Uf/oDQfoPrsTNMNkY27ZYJsMCOuMi2SAlX+K/Cud5bN8mQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass
 header.d=nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tE/I1emPAL5/KLI63YzUj+lh3fOUhSLYL4/H7Ok4vLI=;
 b=iZXgXKr3FUIKx7jzldvug3EJh36hdTFrRqDxPPklmKItWmA3z8BLjETq+4A+MQULxmgo/PBE37ZpffqAZ8+QgRh0oX+8gpnMne6WFnVPw4tFm9d8ttGbsccJ25VMmM2Pvrmvt4qEYFBLo+rdnhnzkjOioEpuH/qFvnnvZGBAZFQ=
Received: from VI1PR04MB5056.eurprd04.prod.outlook.com (20.177.50.141) by
 VI1PR04MB3152.eurprd04.prod.outlook.com (10.170.232.29) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2856.20; Wed, 1 Apr 2020 19:58:59 +0000
Received: from VI1PR04MB5056.eurprd04.prod.outlook.com
 ([fe80::4494:fca6:829e:8fbb]) by VI1PR04MB5056.eurprd04.prod.outlook.com
 ([fe80::4494:fca6:829e:8fbb%3]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020
 19:58:58 +0000
From: Andrei Cherechesu <andrei.cherechesu@nxp.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second
 stage MMU.
Thread-Topic: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second
 stage MMU.
Thread-Index: AdYIX7IDkuxXrVSeSAi3dsrY6od6Mw==
Date: Wed, 1 Apr 2020 19:58:58 +0000
Message-ID: <VI1PR04MB50569D4357FD006DF6359F50F9C90@VI1PR04MB5056.eurprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=andrei.cherechesu@nxp.com; 
x-originating-ip: [78.97.145.157]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 4fcb04f3-fd11-4388-3cfe-08d7d6771e09
x-ms-traffictypediagnostic: VI1PR04MB3152:
x-microsoft-antispam-prvs: <VI1PR04MB315229569AD7521CB2F9D068F9C90@VI1PR04MB3152.eurprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:VI1PR04MB5056.eurprd04.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10009020)(4636009)(39860400002)(346002)(366004)(136003)(396003)(376002)(66446008)(6506007)(8676002)(81156014)(81166006)(478600001)(52536014)(66556008)(33656002)(5660300002)(66946007)(966005)(44832011)(186003)(86362001)(26005)(66476007)(8936002)(76116006)(64756008)(7696005)(316002)(9686003)(71200400001)(4326008)(54906003)(2906002)(6916009)(55016002)(10126625002);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bQFJcfTQvudx4/cOhEmh8WbjwwWg3XdQgKBLcV4AEGejJIEVYP4WhDfRmzq1BUmagocgYWxUWyh55FHs6IAXjyrTv2ABWklLM4nHucjLMMN0Nq4ZcrE298H2ogj43cOHXSoGvklf5LarO9tg90eHLm5cU8XFMSyPf/3xYHk+Kho1VHp2u1umoS75F/J9LrzQ0Fh0nMowy1dgNSs3MaG+pQqb6T2Dqkq9yAPdHdsvHUbrJy7rqGYzq8KY0hqoK9W0oEA80/vu9Du4MQUcl25mZWC6Z7cw7VsQZMTkU0NmfseAExcbMNYrp0bXVSQ0Bt/AStoB2NcmRDJk+KLNeLKvsHkMf1uPYyjd02MXezocA4+HUKb2GUZeZSR7AuK44ZlDrToRPz4amPVzkzFw9x/VYox8QqR6Ma8+gl7JmrIHw/i7tySwVtNxGX4tmReppPvZnHAUi6gQyh7//tBpFN+8gfaJI/joBLO6EnXfSTiSuK0zL6QWiCw+EeMOsuImpKkj9s+LdYLKrcSA2c+klHmY2Wax/Ga06cVgYaY9YM925A5WyBplmj5iSgUT2Ks09e6EMKRFT7gL4tbBSAZPJALPBg==
x-ms-exchange-antispam-messagedata: +Ul17AlkkNIOQYB3WzOGbtVdqlIQb+FBVnGR0zSq7fat0uVrTPmVbZmVNxW90339GuNWqaroMUCiXmlwUZR6H3zrlKOrC2Q7wMtprlwXK5efilf0wKNA1VpWTatTwXJIByRW6gZYuc+SrkEp24yjgg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4fcb04f3-fd11-4388-3cfe-08d7d6771e09
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 19:58:58.8309 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HaAoYRA6zFf+LAUPEZrVGTtUKtmCvlH8vk+sNGT6b/f8L6Zwss/PwzrjCwkdWZBVbx27mzCOD75mOqW8WxN9pAoxEd5qY5r0p/D2cWDQlzI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3152
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

PiBJIGNhbm5vdCBzZWUgYW55IGlzc3VlcyB3aXRoIHRoZSBkcml2ZXIuIENhbiB5b3UgcGFzdGUg
dGhlIGRldmljZSB0cmVlIGFzIGRvbTANCj4gc2VlcyBpdD8gWW91IGNhbiBhY2Nlc3MgaXQgZnJv
bSAvcHJvYy9kZXZpY2UtdHJlZSAoeW91IGNhbiBjb252ZXJ0IGl0IHRvIGR0cw0KPiB3aXRoIGR0
YyAtSSBmcyAtTyBkdHMpLiBBbmQgYWxzbyB0aGUgaG9zdCBkZXZpY2UgdHJlZT8NCj4gDQo+IFdl
IHNob3VsZCBzZWUgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyAodGhpcyBleGFtcGxlIGlz
IHRha2VuIGZyb20gYSBYaWxpbngNCj4gWnlucU1QKToNCj4gDQo+IDEpIGhvc3QgZGV2aWNlIHRy
ZWUNCj4gDQo+ICAgICAgICAgc2VyaWFsQGZmMDAwMDAwIHsNCj4gICAgICAgICAgICAgICAgIHUt
Ym9vdCxkbS1wcmUtcmVsb2M7DQo+ICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImNkbnMs
dWFydC1yMXAxMiIsICJ4bG54LHh1YXJ0cHMiOw0KPiAgICAgICAgICAgICAgICAgc3RhdHVzID0g
Im9rYXkiOw0KPiAgICAgICAgICAgICAgICAgaW50ZXJydXB0LXBhcmVudCA9IDwweDQ+Ow0KPiAg
ICAgICAgICAgICAgICAgaW50ZXJydXB0cyA9IDwweDAgMHgxNSAweDQ+Ow0KPiAgICAgICAgICAg
ICAgICAgcmVnID0gPDB4MCAweGZmMDAwMDAwIDB4MCAweDEwMDA+Ow0KPiAgICAgICAgICAgICAg
ICAgY2xvY2stbmFtZXMgPSAidWFydF9jbGsiLCAicGNsayI7DQo+ICAgICAgICAgICAgICAgICBw
b3dlci1kb21haW5zID0gPDB4MjYgMHgyMT47DQo+ICAgICAgICAgICAgICAgICBjbG9ja3MgPSA8
MHgzIDB4MzggMHgzIDB4MWY+Ow0KPiAgICAgICAgICAgICAgICAgcGluY3RybC1uYW1lcyA9ICJk
ZWZhdWx0IjsNCj4gICAgICAgICAgICAgICAgIHBpbmN0cmwtMCA9IDwweDM3PjsNCj4gICAgICAg
ICAgICAgICAgIGN0cy1vdmVycmlkZTsNCj4gICAgICAgICAgICAgICAgIGRldmljZV90eXBlID0g
InNlcmlhbCI7DQo+ICAgICAgICAgICAgICAgICBwb3J0LW51bWJlciA9IDwweDA+Ow0KPiAgICAg
ICAgIH07DQo+IA0KPiANCj4gMikgZG9tMCBkZXZpY2UgdHJlZQ0KPiANCj4gICAgIFRoZSBub2Rl
IGlzIG1pc3NpbmcNCj4gDQo+IA0KPiBUaGUga2V5IGlzIHRoYXQgZG9tMCBzaG91bGQgbm90IHNl
ZSB0aGUgVUFSVCBub2RlIGluIGRldmljZSB0cmVlIGF0IGFsbC4NCj4gDQo+IElmIERvbTAgaXMg
c2VlaW5nIHRoZSBub2RlLCB0aGVuIGl0IGlzIGEgcHJvYmxlbSB3aXRoIFhlbiB0aGF0IHNvbWVo
b3cgaXMgbm90DQo+IGhpZGluZyBpdCAoc2VlICJTa2lwIG5vZGVzIHVzZWQgYnkgWGVuIiB1bmRl
cg0KPiB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmM6aGFuZGxlX25vZGUpDQo+IA0KPiBJZiBE
b20wIGlzICpub3QqIHNlZWluZyB0aGUgbm9kZSwgdGhhdCB3aGF0IGlzIHRoZSB1bmRlcmx5aW5n
IGRldmljZSB0cmVlIG5vZGUNCj4gdGhhdCB0aGUgZG9tMCBkcml2ZXIgaXMgdXNpbmcgdG8gYnJp
bmcgdXAgL2Rldi90dHlMRjA/DQo+IA0KDQpJIGxvb2tlZCB1bmRlciAvcHJvYy9kZXZpY2UtdHJl
ZSBhbmQgRG9tMCBhY3R1YWxseSBzZWVzIHRoZSBub2RlIGNvcnJlc3BvbmRpbmcNCnRvIHRoZSBz
ZXJpYWwgZGV2aWNlLiBUaGF0IG1lYW5zIFhlbiBpcyBub3QgaGlkaW5nIGl0LiANCg0KSSd2ZSBw
YXN0ZWQgdGhlIGhvc3QgZGV2aWNlIHRyZWUgYXQgWzBdIGFuZCB0aGUgRG9tMCBkZXZpY2UgdHJl
ZSBhdCBbMV0NClswXSBodHRwczovL3Bhc3RlYmluLmNvbS9pcjdWa2ZFUw0KWzFdIGh0dHBzOi8v
cGFzdGViaW4uY29tL1VxUkR5Y0hGDQoNClNvIHRoaXMgaXMgdGhlIGRldmljZSBpbiB0aGUgaG9z
dCBkZXZpY2UgdHJlZToNCg0KICAgIHVhcnQwOnNlcmlhbEA0MDFDODAwMCB7DQogICAgICAgIGNv
bXBhdGlibGUgPSAiZnNsLHMzMi1saW5mbGV4dWFydCI7DQogICAgICAgIHJlZyA9IDwweDAgMHg0
MDFDODAwMCAweDAgMHgzMDAwPjsNCiAgICAgICAgaW50ZXJydXB0cyA9IDwwIDgyIDE+Ow0KICAg
ICAgICBjbG9ja3MgPSA8JmNsa3MgUzMyR0VOMV9DTEtfTElOX0JBVUQ+LA0KICAgICAgICAgICAg
ICAgIDwmY2xrcyBTMzJHRU4xX0NMS19MSU4+Ow0KICAgICAgICBjbG9jay1uYW1lcyA9ICJsaW4i
LCAiaXBnIjsNCiAgICAgICAgZG1hcyA9IDwmZWRtYTAgMCA0PiwNCiAgICAgICAgICAgICAgICA8
JmVkbWEwIDAgMz47DQogICAgICAgIGRtYS1uYW1lcyA9ICJyeCIsICJ0eCI7DQogICAgfTsNCg0K
DQpBbmQgdGhpcyBpcyB0aGUgZGV2aWNlIGluIHRoZSBEb20wIGRldmljZSB0cmVlOg0KDQogICAg
c2VyaWFsQDQwMUM4MDAwIHsNCiAgICAgICAgY2xvY2stbmFtZXMgPSAibGluXDBpcGciOw0KICAg
ICAgICBpbnRlcnJ1cHRzID0gPDB4MDAgMHg1MiAweDAxPjsNCiAgICAgICAgY2xvY2tzID0gPDB4
MDQgMHgyYSAweDA0IDB4MmI+Ow0KICAgICAgICBkbWEtbmFtZXMgPSAicnhcMHR4IjsNCiAgICAg
ICAgY29tcGF0aWJsZSA9ICJmc2wsczMyLWxpbmZsZXh1YXJ0IjsNCiAgICAgICAgcmVnID0gPDB4
MDAgMHg0MDFjODAwMCAweDAwIDB4MzAwMD47DQogICAgICAgIGRtYXMgPSA8MHgwZSAweDAwIDB4
MDQgMHgwZSAweDAwIDB4MDM+Ow0KICAgIH07DQoNCkZyb20gdGhpcyBzdG9yeSBJIGZpZ3VyZWQg
b3V0IHNvbWV0aGluZyBlbHNlOiB0aGF0IEkgd2FzIG5vdCBwYXNzaW5nIHRvIFhlbidzDQpib290
YXJncyAiY29uc29sZT1kdHVhcnQgZHR1YXJ0PXNlcmlhbDAiLiBNYXliZSB0aGF0J3Mgd2h5IFhl
biBpcyBub3QgaGlkaW5nDQp0aGUgbm9kZSBmcm9tIERvbTAgKHNlcmlhbDAgaXMgYW4gYWxpYXMg
dG8gdWFydDApLg0KDQpTbyBJIHdlbnQgb24gYW5kIEkgYWRkZWQgdGhhdCB0byBib290YXJncy4g
QW5kIG5vdyBteSBYZW4gYm9vdCBzdG9wcyBoZXJlDQooREVCVUcgcHJpbnQgb24pOg0KLi4uDQou
Li4NCihYRU4pIGZpeGVkIHVwIG5hbWUgZm9yIHNpdWwyX3JlZ0AweDQ0MDExNzBDIC0+IHNpdWwy
X3JlZw0KKFhFTikgZml4ZWQgdXAgbmFtZSBmb3Igc2l1bDJfcmVnQDB4NDQwMTE3NEMgLT4gc2l1
bDJfcmVnDQooWEVOKSBmaXhlZCB1cCBuYW1lIGZvciB1c2JtaXNjQDQ0MDY0MjAwIC0+IHVzYm1p
c2MNCihYRU4pIGZpeGVkIHVwIG5hbWUgZm9yIHVzYkA0NDA2NDAwMCAtPiB1c2INCihYRU4pIGZp
eGVkIHVwIG5hbWUgZm9yIG1lbW9yeV9ERFIwQDgwMDAwMDAwIC0+IG1lbW9yeV9ERFIwDQooWEVO
KSBmaXhlZCB1cCBuYW1lIGZvciBtZW1vcnlfRERSMUBjMDAwMDAwMCAtPiBtZW1vcnlfRERSMQ0K
KFhFTikgZml4ZWQgdXAgbmFtZSBmb3IgbWVtb3J5X0REUjJAODgwMDAwMDAwIC0+IG1lbW9yeV9E
RFIyDQooWEVOKSAgPC0gdW5mbGF0dGVuX2RldmljZV90cmVlKCkNCihYRU4pIGFkZGluZyBEVCBh
bGlhczpjYW4wOiBzdGVtPWNhbiBpZD0wIG5vZGU9L2ZsZXhjYW5ANDAxQjQwMDANCihYRU4pIGFk
ZGluZyBEVCBhbGlhczpjYW4xOiBzdGVtPWNhbiBpZD0xIG5vZGU9L2ZsZXhjYW5ANDAxQkUwMDAN
CihYRU4pIGFkZGluZyBEVCBhbGlhczpjYW4yOiBzdGVtPWNhbiBpZD0yIG5vZGU9L2ZsZXhjYW5A
NDAyQTgwMDANCihYRU4pIGFkZGluZyBEVCBhbGlhczpjYW4zOiBzdGVtPWNhbiBpZD0zIG5vZGU9
L2ZsZXhjYW5ANDAyQjIwMDANCihYRU4pIGFkZGluZyBEVCBhbGlhczpzZXJpYWwwOiBzdGVtPXNl
cmlhbCBpZD0wIG5vZGU9L3NlcmlhbEA0MDFDODAwMA0KKFhFTikgYWRkaW5nIERUIGFsaWFzOnNl
cmlhbDE6IHN0ZW09c2VyaWFsIGlkPTEgbm9kZT0vc2VyaWFsQDQwMUNDMDAwDQooWEVOKSBhZGRp
bmcgRFQgYWxpYXM6c2VyaWFsMjogc3RlbT1zZXJpYWwgaWQ9MiBub2RlPS9zZXJpYWxANDAyQkMw
MDANCihYRU4pIFBsYXRmb3JtOiBHZW5lcmljIFN5c3RlbQ0KKFhFTikgTG9va2luZyBmb3IgZHR1
YXJ0IGF0ICJzZXJpYWwwIiwgb3B0aW9ucyAiIg0KKFhFTikgRFQ6ICoqIHRyYW5zbGF0aW9uIGZv
ciBkZXZpY2UgL3NlcmlhbEA0MDFDODAwMCAqKg0KKFhFTikgRFQ6IGJ1cyBpcyBkZWZhdWx0IChu
YT0yLCBucz0yKSBvbiAvDQooWEVOKSBEVDogdHJhbnNsYXRpbmcgYWRkcmVzczo8Mz4gMDAwMDAw
MDA8Mz4gNDAxYzgwMDA8Mz4NCihYRU4pIERUOiByZWFjaGVkIHJvb3Qgbm9kZQ0KKFhFTikgZHRf
ZGV2aWNlX2dldF9yYXdfaXJxOiBkZXY9L3NlcmlhbEA0MDFDODAwMCwgaW5kZXg9MA0KKFhFTikg
IGludHNwZWM9MCBpbnRsZW49Mw0KKFhFTikgIGludHNpemU9MyBpbnRsZW49Mw0KKFhFTikgZHRf
aXJxX21hcF9yYXc6IHBhcj0vaW50ZXJydXB0LWNvbnRyb2xsZXJANTA4MDAwMDAsaW50c3BlYz1b
MHgwMDAwMDAwMCAweDAwMDAwMDUyLi4uXSxvaW50c2l6ZT0zDQooWEVOKSBkdF9pcnFfbWFwX3Jh
dzogaXBhcj0vaW50ZXJydXB0LWNvbnRyb2xsZXJANTA4MDAwMDAsIHNpemU9Mw0KKFhFTikgIC0+
IGFkZHJzaXplPTINCihYRU4pICAtPiBnb3QgaXTvv70gDQoNCkkgc3RhcnRlZCBkZWJ1Z2dpbmcg
YW5kIEkgZm91bmQgb3V0IHRoYXQgaXQgaGFuZ3MgaW46DQpjb25zb2xlX2luaXRfcHJlaXJxKCkg
LT4gX19wdXRzdHIoeGVuX2Jhbm5lcigpKSAtPiBzZXJjb25fcHV0cygpIC0+IHNlcmlhbF9wdXRz
KCkgLT4gX19zZXJpYWxfcHV0YygpLA0Kd2hlcmUgaXQgc3BpbnMgYXQgbGluZSAxNzg6ICAgICAg
ICAgDQogICAgICAgIC8qIFN5bmNocm9ub3VzIGZpbml0ZS1jYXBhY2l0eSB0cmFuc21pdHRlci4g
Ki8NCiAgICAgICAgd2hpbGUgKCAhKG4gPSBwb3J0LT5kcml2ZXItPnR4X3JlYWR5KHBvcnQpKSAp
DQogICAgICAgICAgICBjcHVfcmVsYXgoKTsNCiANCldoaWNoIGlzIGEgYml0IHN0cmFuZ2UsIGNv
bnNpZGVyaW5nIHRoYXQgbXkgc2VyaWFsIGRldmljZSBpcyBhc3luY2hyb25vdXMsDQpJIHRoaW5r
IGl0IHNob3VsZCBub3QgZ2V0IHRoZXJlLiBCdXQgaXQgZ2V0cyBvbiB0aGF0ICJlbHNlIiBicmFu
Y2ggYmVjYXVzZQ0KcG9ydC0+dHhidWYgaXMgYWN0dWFsbHkgTlVMTCBhdCBsaW5lIDEyMCB3aGVu
IGl0IHBlcmZvcm1zIHRoZSBjaGVjaywgYW5kDQppdCBkb2VzIG5vdCBlbnRlciB0aGUgYnJhbmNo
IGZvciBhc3luY2hyb25vdXMgdHJhbnNtaXR0ZXJzLg0KDQpUaGFua3MsDQpBbmRyZWkgQ2hlcmVj
aGVzdSwNCk5YUCBTZW1pY29uZHVjdG9ycw0KDQo=


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 20:07:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 20:07:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJjeM-0000lR-Pw; Wed, 01 Apr 2020 20:07:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJjeL-0000lM-3l
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 20:07:45 +0000
X-Inumbo-ID: 6ffe33e0-7454-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6ffe33e0-7454-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 20:07:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=1T/pgLMK5uposDsezqDsKEmT660WQxcaBurxMhqZvE0=; b=w1zLIy5sjN1JLDSUt75Sqj8jk
 EczeUWm2HxxGAsyRoJ9L1kmr2/2YU2dEto4V7zF0t3C4khmpjYS7Q4uTCzZtF/j3MnIeODzrPflKw
 rBjlHWIhH39GuB46w4U/w9+mzKRTFfVRPoR42NIH2DwfZrBM57y54QVZbo6cvQ7xl9fWM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJjeF-0003AW-5S; Wed, 01 Apr 2020 20:07:39 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJjeE-0001wl-PI; Wed, 01 Apr 2020 20:07:38 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJjeE-0004cN-OZ; Wed, 01 Apr 2020 20:07:38 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149296-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149296: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=4de936a38aa96c946f5d39b2760abb8a9853cba3
X-Osstest-Versions-That: xen=3925402f5dd7ae93010c48688eb64f880c794267
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 20:07:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  4de936a38aa96c946f5d39b2760abb8a9853cba3
baseline version:
 xen                  3925402f5dd7ae93010c48688eb64f880c794267

Last test of basis   149284  2020-04-01 13:01:36 Z    0 days
Testing same since   149296  2020-04-01 17:00:36 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   3925402f5d..4de936a38a  4de936a38aa96c946f5d39b2760abb8a9853cba3 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 21:07:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 21:07:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJkaE-0005YX-Ix; Wed, 01 Apr 2020 21:07:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJkaC-0005Xn-PK
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 21:07:32 +0000
X-Inumbo-ID: cd5413d6-745c-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cd5413d6-745c-11ea-b58d-bc764e2007e4;
 Wed, 01 Apr 2020 21:07:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=K6yqWlm/Tg22DNpl5U8tUU3d6gdXz00zPjSVHwLc0kQ=; b=a0XXeOxqFBYXFW46ttfqGiu0pT
 /xx+4SK9Lmo+/zDX7G2Nz619pnTHGZbsB/o0MptubkK++2/kAzFO3w9mqB59TYT7Lzwn7sxK6/br+
 tXvOIMy+t1sAln/sEs9oKDkAyzcNYKmZTgaH6Vlnb4mckHjDVX2plwCobK3OcbQdh0cs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJkaB-0004LZ-KQ; Wed, 01 Apr 2020 21:07:31 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJkaB-0005B1-5R; Wed, 01 Apr 2020 21:07:31 +0000
Subject: Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second
 stage MMU.
To: Andrei Cherechesu <andrei.cherechesu@nxp.com>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <VI1PR04MB50569D4357FD006DF6359F50F9C90@VI1PR04MB5056.eurprd04.prod.outlook.com>
From: Julien Grall <julien@xen.org>
Message-ID: <58232271-be0e-1fcf-85f3-1cc4eac93e6e@xen.org>
Date: Wed, 1 Apr 2020 22:07:29 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <VI1PR04MB50569D4357FD006DF6359F50F9C90@VI1PR04MB5056.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 01/04/2020 20:58, Andrei Cherechesu wrote:
>> I cannot see any issues with the driver. Can you paste the device tree as dom0
>> sees it? You can access it from /proc/device-tree (you can convert it to dts
>> with dtc -I fs -O dts). And also the host device tree?
>>
>> We should see something like the following (this example is taken from a Xilinx
>> ZynqMP):
>>
>> 1) host device tree
>>
>>          serial@ff000000 {
>>                  u-boot,dm-pre-reloc;
>>                  compatible = "cdns,uart-r1p12", "xlnx,xuartps";
>>                  status = "okay";
>>                  interrupt-parent = <0x4>;
>>                  interrupts = <0x0 0x15 0x4>;
>>                  reg = <0x0 0xff000000 0x0 0x1000>;
>>                  clock-names = "uart_clk", "pclk";
>>                  power-domains = <0x26 0x21>;
>>                  clocks = <0x3 0x38 0x3 0x1f>;
>>                  pinctrl-names = "default";
>>                  pinctrl-0 = <0x37>;
>>                  cts-override;
>>                  device_type = "serial";
>>                  port-number = <0x0>;
>>          };
>>
>>
>> 2) dom0 device tree
>>
>>      The node is missing
>>
>>
>> The key is that dom0 should not see the UART node in device tree at all.
>>
>> If Dom0 is seeing the node, then it is a problem with Xen that somehow is not
>> hiding it (see "Skip nodes used by Xen" under
>> xen/arch/arm/domain_build.c:handle_node)
>>
>> If Dom0 is *not* seeing the node, that what is the underlying device tree node
>> that the dom0 driver is using to bring up /dev/ttyLF0?
>>
> 
> I looked under /proc/device-tree and Dom0 actually sees the node corresponding
> to the serial device. That means Xen is not hiding it.
> 
> I've pasted the host device tree at [0] and the Dom0 device tree at [1]
> [0] https://pastebin.com/ir7VkfES
> [1] https://pastebin.com/UqRDycHF
> 
> So this is the device in the host device tree:
> 
>      uart0:serial@401C8000 {
>          compatible = "fsl,s32-linflexuart";
>          reg = <0x0 0x401C8000 0x0 0x3000>;
>          interrupts = <0 82 1>;
>          clocks = <&clks S32GEN1_CLK_LIN_BAUD>,
>                  <&clks S32GEN1_CLK_LIN>;
>          clock-names = "lin", "ipg";
>          dmas = <&edma0 0 4>,
>                  <&edma0 0 3>;
>          dma-names = "rx", "tx";
>      };
> 
> 
> And this is the device in the Dom0 device tree:
> 
>      serial@401C8000 {
>          clock-names = "lin\0ipg";
>          interrupts = <0x00 0x52 0x01>;
>          clocks = <0x04 0x2a 0x04 0x2b>;
>          dma-names = "rx\0tx";
>          compatible = "fsl,s32-linflexuart";
>          reg = <0x00 0x401c8000 0x00 0x3000>;
>          dmas = <0x0e 0x00 0x04 0x0e 0x00 0x03>;
>      };
> 
>  From this story I figured out something else: that I was not passing to Xen's
> bootargs "console=dtuart dtuart=serial0". Maybe that's why Xen is not hiding
> the node from Dom0 (serial0 is an alias to uart0).

Xen is not going to hide the UART from dom0 if it is not used by the 
console driver.

> 
> So I went on and I added that to bootargs. And now my Xen boot stops here
> (DEBUG print on):
> ...
> ...
> (XEN) fixed up name for siul2_reg@0x4401170C -> siul2_reg
> (XEN) fixed up name for siul2_reg@0x4401174C -> siul2_reg
> (XEN) fixed up name for usbmisc@44064200 -> usbmisc
> (XEN) fixed up name for usb@44064000 -> usb
> (XEN) fixed up name for memory_DDR0@80000000 -> memory_DDR0
> (XEN) fixed up name for memory_DDR1@c0000000 -> memory_DDR1
> (XEN) fixed up name for memory_DDR2@880000000 -> memory_DDR2
> (XEN)  <- unflatten_device_tree()
> (XEN) adding DT alias:can0: stem=can id=0 node=/flexcan@401B4000
> (XEN) adding DT alias:can1: stem=can id=1 node=/flexcan@401BE000
> (XEN) adding DT alias:can2: stem=can id=2 node=/flexcan@402A8000
> (XEN) adding DT alias:can3: stem=can id=3 node=/flexcan@402B2000
> (XEN) adding DT alias:serial0: stem=serial id=0 node=/serial@401C8000
> (XEN) adding DT alias:serial1: stem=serial id=1 node=/serial@401CC000
> (XEN) adding DT alias:serial2: stem=serial id=2 node=/serial@402BC000
> (XEN) Platform: Generic System
> (XEN) Looking for dtuart at "serial0", options ""
> (XEN) DT: ** translation for device /serial@401C8000 **
> (XEN) DT: bus is default (na=2, ns=2) on /
> (XEN) DT: translating address:<3> 00000000<3> 401c8000<3>
> (XEN) DT: reached root node
> (XEN) dt_device_get_raw_irq: dev=/serial@401C8000, index=0
> (XEN)  intspec=0 intlen=3
> (XEN)  intsize=3 intlen=3
> (XEN) dt_irq_map_raw: par=/interrupt-controller@50800000,intspec=[0x00000000 0x00000052...],ointsize=3
> (XEN) dt_irq_map_raw: ipar=/interrupt-controller@50800000, size=3
> (XEN)  -> addrsize=2
> (XEN)  -> got it�
> 
> I started debugging and I found out that it hangs in:
> console_init_preirq() -> __putstr(xen_banner()) -> sercon_puts() -> serial_puts() -> __serial_putc(),
> where it spins at line 178:
>          /* Synchronous finite-capacity transmitter. */
>          while ( !(n = port->driver->tx_ready(port)) )
>              cpu_relax();
>   
> Which is a bit strange, considering that my serial device is asynchronous,
> I think it should not get there. But it gets on that "else" branch because
> port->txbuf is actually NULL at line 120 when it performs the check, and
> it does not enter the branch for asynchronous transmitters.

The console is initialized much before the interrupt subsystem is 
initialized. Therefore you need synchronous support for some part of the 
boot.

Also, looking at your driver, you don't seem to call 
serial_async_transmist() in console_init_postirq() (see ns16550.c) so I 
am not sure how asynchronous would work.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 21:11:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 21:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJkdb-0006Ih-39; Wed, 01 Apr 2020 21:11:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJkdZ-0006Ib-TM
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 21:11:01 +0000
X-Inumbo-ID: 4a36b5ca-745d-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4a36b5ca-745d-11ea-b4f4-bc764e2007e4;
 Wed, 01 Apr 2020 21:11:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=DjYNdY2SZPgysMgui8UdB2jjHY5hTObqkW3Cyl+KLOw=; b=LO7Yt17JvA766+Qo6NIrNgnTat
 nBZ1boFA9Kxl3cSgVaDnT41Ddo7RltChePdh3ER/KAatQMtvNxemGMKYIYWQ1ZMdx8cG+WbRke9uY
 YZ1AjO2x97uQ+97RDnAVl9rvgUnqha3PJOSs/PHTQKeR9I+abwbFpL310PlxMVO1QZqw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJkdW-0004P9-OK; Wed, 01 Apr 2020 21:10:58 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJkdW-0005QZ-Hu; Wed, 01 Apr 2020 21:10:58 +0000
Subject: Re: [PATCH 1/8] xen/guest_access: Harden copy_to_guest_offset to
 prevent const dest operand
To: Jan Beulich <jbeulich@suse.com>
References: <20200330192157.1335-1-julien@xen.org>
 <20200330192157.1335-2-julien@xen.org>
 <33a36f0e-5adb-b8af-445c-bab765c84589@suse.com>
 <b5f7037a-5253-b5f2-d5b7-1b90d19021c2@xen.org>
 <11871e55-481f-b318-bf5d-d9518e180fa9@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <16c3a710-c261-1e97-35b5-9d0ef5470e8c@xen.org>
Date: Wed, 1 Apr 2020 22:10:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <11871e55-481f-b318-bf5d-d9518e180fa9@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 dfaggioli@suse.com, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 01/04/2020 10:25, Jan Beulich wrote:
> On 31.03.2020 21:13, Julien Grall wrote:
>> I am not aware of any way before C11 to check if a variable is
>> const or not. If we wanted to keep allow void type the handle
>> then a possible approach would be:
>>
>> #define copy_to_guest_offset(hnd, off, ptr, nr) ({              \
>>      const typeof(*(ptr)) *_s = (ptr);                           \
>>      typeof(*((hnd).p)) *_d = (hnd).p;                           \
>>      size_t mul = (sizeof(*(hnd).p) > 1) ? 1 : sizeof (*_s);     \
>>      ((void)((hnd).p == (ptr)));                                 \
>>      raw_copy_to_guest(_d + (off) * mul, _s, sizeof(*_s)*(nr));  \
>> })
>>
>> I don't particularly like it but I could not come up with better so far.
> 
> Having looked at how in particular copy_field_to_guest() (which
> doesn't have this issue afaict) works, here's an imo much better
> alternative:
> 
> @@ -87,6 +87,7 @@
>   #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
>       const typeof(*(ptr)) *_s = (ptr);                   \
>       char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
> +    void *__maybe_unused _t = (hnd).p;                  \
>       ((void)((hnd).p == (ptr)));                         \
>       raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
>   })
> @@ -143,6 +144,7 @@ static inline void put_guest_handle(void
>   #define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
>       const typeof(*(ptr)) *_s = (ptr);                   \
>       char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
> +    void *__maybe_unused _t = (hnd).p;                  \
>       ((void)((hnd).p == (ptr)));                         \
>       __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
>   })

I actually thought about this one but discarded it because it was using 
unused variable. But I am happy with it, I will have a look to respin 
the patch.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 21:29:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 21:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJkuz-0007Ji-O2; Wed, 01 Apr 2020 21:29:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJkuy-0007Jd-NV
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 21:29:00 +0000
X-Inumbo-ID: cd05a3ba-745f-11ea-bb44-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cd05a3ba-745f-11ea-bb44-12813bfff9fa;
 Wed, 01 Apr 2020 21:29:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Z4kvSBwT4vFIojH8OGTbxZSiguaGsCw+BLZIU40Je74=; b=68xesolY0BS1wDlqGTh5A5YWHr
 Kxq0qrsEJ9Ho/k7QYQG6Y0kdoNnPG+vSKT75Xth1nQZ0nP9AN5SHCWW5cJqv/ZQK3Pn0uBLDJDWZ7
 IXKh9Iu++QCtvf+azzHXUGuxr8Dvtg+JHB/LTzJ/Vn59NgWfQpFJqqeQbh91/OnuB6no=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJkuw-0004kY-Si; Wed, 01 Apr 2020 21:28:58 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJkuw-0006Mk-Lx; Wed, 01 Apr 2020 21:28:58 +0000
Subject: Re: [PATCH] guestcopy: evaluate {,__}copy{,_field}_to_guest*()
 arguments just once
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9918b339-e914-7228-5f8e-86c82090b5bd@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <b07fcc5a-60c1-a831-b4b1-a6de3f82b8b4@xen.org>
Date: Wed, 1 Apr 2020 22:28:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <9918b339-e914-7228-5f8e-86c82090b5bd@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 01/04/2020 15:29, Jan Beulich wrote:
> There's nothing wrong with having e.g.
> 
>      copy_to_guest(uarg, ptr++, 1);
> 
> yet until now this would increment "ptr" twice.

Is there such use in Xen today? I guess not as we would have noticed any 
issue.

> Also drop a pair of unneeded parentheses from every instance at this
> occasion.
> 
> Fixes: b7954cc59831 ("Enhance guest memory accessor macros so that source operands can be")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Arm side untested so far, as I don't have all the tool chain pieces
> available at home.

I will have a look.

> ---
> This goes on top of the assumed v2 of Julien's "xen/guest_access: Harden
> copy_to_guest_offset to prevent const dest operand".
> 
> --- a/xen/include/asm-arm/guest_access.h
> +++ b/xen/include/asm-arm/guest_access.h
> @@ -79,7 +79,7 @@ int access_guest_memory_by_ipa(struct do
>       const typeof(*(ptr)) *_s = (ptr);                   \
>       char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>       void *__maybe_unused _t = (hnd).p;                  \
> -    ((void)((hnd).p == (ptr)));                         \
> +    (void)((hnd).p == _s);                              \

May I ask why this is a problem with 'ptr' but not 'hnd'? Wouldn't it 
theorically possible to have an array of handle?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 21:35:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 21:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJl1U-00088S-HN; Wed, 01 Apr 2020 21:35:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=wqBo=5R=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jJl1S-00088M-Ly
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 21:35:42 +0000
X-Inumbo-ID: bc221be1-7460-11ea-bb45-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bc221be1-7460-11ea-bb45-12813bfff9fa;
 Wed, 01 Apr 2020 21:35:41 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id AE9E820719;
 Wed,  1 Apr 2020 21:35:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1585776940;
 bh=/1T9CY/MEYJpPQwxf69piZx3h6sJ32ZqgDWhAvtuWD8=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=o1V9b2PAirGmIYsv38SQtpe4hpdNT3m8KgD6B9e3wl6ScZHttD2hor5B6OX0M8Fai
 asslDQy5e21+WlgCUD/CMIhqGlfyvYy4fOw0Ix4DKVrZhNOEU38Qe77iC/Zto+Nw98
 FoYes3/1jdHUhpD+Rpd3vNe5vAqjZIO4A9OZ1g4g=
Date: Wed, 1 Apr 2020 14:35:40 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Andrei Cherechesu <andrei.cherechesu@nxp.com>
Subject: Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second
 stage MMU.
In-Reply-To: <VI1PR04MB50569D4357FD006DF6359F50F9C90@VI1PR04MB5056.eurprd04.prod.outlook.com>
Message-ID: <alpine.DEB.2.21.2004011401200.10657@sstabellini-ThinkPad-T480s>
References: <VI1PR04MB50569D4357FD006DF6359F50F9C90@VI1PR04MB5056.eurprd04.prod.outlook.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 1 Apr 2020, Andrei Cherechesu wrote:
> > I cannot see any issues with the driver. Can you paste the device tree as dom0
> > sees it? You can access it from /proc/device-tree (you can convert it to dts
> > with dtc -I fs -O dts). And also the host device tree?
> > 
> > We should see something like the following (this example is taken from a Xilinx
> > ZynqMP):
> > 
> > 1) host device tree
> > 
> >         serial@ff000000 {
> >                 u-boot,dm-pre-reloc;
> >                 compatible = "cdns,uart-r1p12", "xlnx,xuartps";
> >                 status = "okay";
> >                 interrupt-parent = <0x4>;
> >                 interrupts = <0x0 0x15 0x4>;
> >                 reg = <0x0 0xff000000 0x0 0x1000>;
> >                 clock-names = "uart_clk", "pclk";
> >                 power-domains = <0x26 0x21>;
> >                 clocks = <0x3 0x38 0x3 0x1f>;
> >                 pinctrl-names = "default";
> >                 pinctrl-0 = <0x37>;
> >                 cts-override;
> >                 device_type = "serial";
> >                 port-number = <0x0>;
> >         };
> > 
> > 
> > 2) dom0 device tree
> > 
> >     The node is missing
> > 
> > 
> > The key is that dom0 should not see the UART node in device tree at all.
> > 
> > If Dom0 is seeing the node, then it is a problem with Xen that somehow is not
> > hiding it (see "Skip nodes used by Xen" under
> > xen/arch/arm/domain_build.c:handle_node)
> > 
> > If Dom0 is *not* seeing the node, that what is the underlying device tree node
> > that the dom0 driver is using to bring up /dev/ttyLF0?
> > 
> 
> I looked under /proc/device-tree and Dom0 actually sees the node corresponding
> to the serial device. That means Xen is not hiding it. 
> 
> I've pasted the host device tree at [0] and the Dom0 device tree at [1]
> [0] https://pastebin.com/ir7VkfES
> [1] https://pastebin.com/UqRDycHF
> 
> So this is the device in the host device tree:
> 
>     uart0:serial@401C8000 {
>         compatible = "fsl,s32-linflexuart";
>         reg = <0x0 0x401C8000 0x0 0x3000>;
>         interrupts = <0 82 1>;
>         clocks = <&clks S32GEN1_CLK_LIN_BAUD>,
>                 <&clks S32GEN1_CLK_LIN>;
>         clock-names = "lin", "ipg";
>         dmas = <&edma0 0 4>,
>                 <&edma0 0 3>;
>         dma-names = "rx", "tx";
>     };
> 
> 
> And this is the device in the Dom0 device tree:
> 
>     serial@401C8000 {
>         clock-names = "lin\0ipg";
>         interrupts = <0x00 0x52 0x01>;
>         clocks = <0x04 0x2a 0x04 0x2b>;
>         dma-names = "rx\0tx";
>         compatible = "fsl,s32-linflexuart";
>         reg = <0x00 0x401c8000 0x00 0x3000>;
>         dmas = <0x0e 0x00 0x04 0x0e 0x00 0x03>;
>     };

All right, now we know what the problem is :-)

If you are unsure, I would enable CONFIG_DEVICE_TREE_DEBUG and/or add a
printk or two to figure out why Xen is not filtering out the node:


diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4307087536..fa6a108de8 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1486,6 +1486,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
     /* Skip nodes used by Xen */
     if ( dt_device_used_by(node) == DOMID_XEN )
     {
+        printk("DEBUG skipping %s\n",path);
         dt_dprintk("  Skip it (used by Xen)\n");
         return 0;
     }

You might also want to add a printk just before the call to
dt_device_set_used_by(dev, DOMID_XEN) in your uart driver.



> From this story I figured out something else: that I was not passing to Xen's
> bootargs "console=dtuart dtuart=serial0". Maybe that's why Xen is not hiding
> the node from Dom0 (serial0 is an alias to uart0).

Yes, it is worth double-checking that Xen is using the right driver for
the right device and the right device tree node description. Print in
your driver not only that is getting called but also that is getting
called for the right device node.

But console=dtuart dtuart=serial0 seems correct with your device tree.


> So I went on and I added that to bootargs. And now my Xen boot stops here
> (DEBUG print on):
> ...
> ...
> (XEN) fixed up name for siul2_reg@0x4401170C -> siul2_reg
> (XEN) fixed up name for siul2_reg@0x4401174C -> siul2_reg
> (XEN) fixed up name for usbmisc@44064200 -> usbmisc
> (XEN) fixed up name for usb@44064000 -> usb
> (XEN) fixed up name for memory_DDR0@80000000 -> memory_DDR0
> (XEN) fixed up name for memory_DDR1@c0000000 -> memory_DDR1
> (XEN) fixed up name for memory_DDR2@880000000 -> memory_DDR2
> (XEN)  <- unflatten_device_tree()
> (XEN) adding DT alias:can0: stem=can id=0 node=/flexcan@401B4000
> (XEN) adding DT alias:can1: stem=can id=1 node=/flexcan@401BE000
> (XEN) adding DT alias:can2: stem=can id=2 node=/flexcan@402A8000
> (XEN) adding DT alias:can3: stem=can id=3 node=/flexcan@402B2000
> (XEN) adding DT alias:serial0: stem=serial id=0 node=/serial@401C8000
> (XEN) adding DT alias:serial1: stem=serial id=1 node=/serial@401CC000
> (XEN) adding DT alias:serial2: stem=serial id=2 node=/serial@402BC000
> (XEN) Platform: Generic System
> (XEN) Looking for dtuart at "serial0", options ""
> (XEN) DT: ** translation for device /serial@401C8000 **
> (XEN) DT: bus is default (na=2, ns=2) on /
> (XEN) DT: translating address:<3> 00000000<3> 401c8000<3>
> (XEN) DT: reached root node
> (XEN) dt_device_get_raw_irq: dev=/serial@401C8000, index=0
> (XEN)  intspec=0 intlen=3
> (XEN)  intsize=3 intlen=3
> (XEN) dt_irq_map_raw: par=/interrupt-controller@50800000,intspec=[0x00000000 0x00000052...],ointsize=3
> (XEN) dt_irq_map_raw: ipar=/interrupt-controller@50800000, size=3
> (XEN)  -> addrsize=2
> (XEN)  -> got it??? 
> 
> I started debugging and I found out that it hangs in:
> console_init_preirq() -> __putstr(xen_banner()) -> sercon_puts() -> serial_puts() -> __serial_putc(),
> where it spins at line 178:         
>         /* Synchronous finite-capacity transmitter. */
>         while ( !(n = port->driver->tx_ready(port)) )
>             cpu_relax();
>  
> Which is a bit strange, considering that my serial device is asynchronous,
> I think it should not get there. But it gets on that "else" branch because
> port->txbuf is actually NULL at line 120 when it performs the check, and
> it does not enter the branch for asynchronous transmitters.
 
What Xen base version are you using? It is not line 178 on master.

I would look a bit more closely into that driver. For instance, one
question I would ask myself is why is tx_ready not returning 1?
Something is probably not quite right in the initialization of that
driver.


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 21:37:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 21:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJl2k-0008Eu-Vb; Wed, 01 Apr 2020 21:37:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJl2k-0008Ep-H7
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 21:37:02 +0000
X-Inumbo-ID: e7f48a6e-7460-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e7f48a6e-7460-11ea-83d8-bc764e2007e4;
 Wed, 01 Apr 2020 21:36:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=cDoI6ceBJe95ND0WXpyAGPXExzRQQBssMxWWwp1r+XI=; b=m9dAGlzLAsRbNM8CnM5yIrYF2
 Ln96pNrOk2LsRe9lT5R+KyESxrHLU8BSKtT8JzJ0+EBo+ZDH5Jpjy7WM2yJJoT8XUhTGGT/VGFUaj
 EFTEdQ8/mAMi+zuOFCtR3kfv0dVe4phkjL2AvH/3ijM3l3yclmXDbVSl4oMn0K71LwoHU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJl2c-0004uP-9y; Wed, 01 Apr 2020 21:36:54 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJl2c-00085D-2H; Wed, 01 Apr 2020 21:36:54 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJl2c-0006Kl-1A; Wed, 01 Apr 2020 21:36:54 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149264-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149264: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate:fail:nonblocking
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-amd:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=2833ad487cfff7dc33703e4731b75facde1c561e
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 21:36:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-freebsd10-i386 11 guest-start            fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-freebsd10-amd64 11 guest-start           fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 16 guest-localmigrate fail baseline untested
 test-amd64-amd64-dom0pvh-xl-amd 18 guest-localmigrate/x10 fail baseline untested
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 144861
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                2833ad487cfff7dc33703e4731b75facde1c561e
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  107 days
Failing since        144880  2019-12-16 20:07:08 Z  107 days  316 attempts
Testing same since   149264  2020-04-01 02:32:20 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 56117 lines long.)


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 22:00:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 22:00:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJlPb-0002Dc-41; Wed, 01 Apr 2020 22:00:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=46oD=5R=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jJlPZ-0002DW-DB
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 22:00:37 +0000
X-Inumbo-ID: 37710e8e-7464-11ea-bb47-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 37710e8e-7464-11ea-bb47-12813bfff9fa;
 Wed, 01 Apr 2020 22:00:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=6nyrWK1yF9oHz/OXopTejPK3X0T3tRoyoqYe5Go48FU=; b=LCq51/uxgQbCFIpqU/DwI4gikX
 6EZU5KP3VixUGE3BoqL/gHnFGM0HR0UpIsH55TSegetCjkGXCOZt5yzNcbY+JSqLiOyYGduaQu+aS
 8CLD9a9MVyPfoTSyS9hV9GuQqkfjovW5WU79pV2o8Dy25ev9xyi805I1GUI2eCREojWw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJlPP-0005Mw-S8; Wed, 01 Apr 2020 22:00:27 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jJlPP-00005J-L6; Wed, 01 Apr 2020 22:00:27 +0000
Subject: Re: [PATCH 0/8] Fix build with using OCaml 4.06.1 and -safe-string
To: Ian Jackson <ian.jackson@citrix.com>
References: <20200330192157.1335-1-julien@xen.org>
 <24195.9951.944818.756019@mariner.uk.xensource.com>
From: Julien Grall <julien@xen.org>
Message-ID: <b90a8cb4-64a6-bda3-6d9f-3a962105455a@xen.org>
Date: Wed, 1 Apr 2020 23:00:24 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <24195.9951.944818.756019@mariner.uk.xensource.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 "dfaggioli@suse.com" <dfaggioli@suse.com>,
 Christian Lindig <christian.lindig@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, David Scott <dave@recoil.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Ian,

On 31/03/2020 12:17, Ian Jackson wrote:
> Julien Grall writes ("[PATCH 0/8] Fix build with using OCaml 4.06.1 and -safe-string"):
>> This series is meant to solve the build issue reported by Dario when
>> using recent version of OCaml and -safe-string.
> 
> Thanks.  I have reviewed the C tools parts here.  I think the ocaml
> parts ought to have a review from someone familiar with the ocaml FFI.
> 
>> I took the opportunity to harden a bit more the code by using const more
>> often.
> 
> I approve.
> 
> Perhaps we should start building our C code with -Wwrite-strings,
> which makes "" have type const char* ?  Result would be a giant
> constification patch, probably.

So I thought I would give a try and see how far I can go:

    * hypervisor (xen): It is fairly easy to convert, although this is 
touching code that was imported from other projects (such as acpica). I 
need to have a look at whether other projects fixed there code and we 
can backport.
    * libxc: This is pretty trivial, I will send a patch for it
    * libxl: This is where it is getting tricky, the main issue is the 
flexarray framework as we would use it with string (now const char *). I 
thought we could make the interface const, but it looks like there are a 
couple of places where we need to modify the content (such as in 
libxl_json.c). I am not sure yet how to deal with it.

In any case, even if we can't use -Wwrite-strings, I can still send 
patches to use const in more places.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 01 23:25:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Apr 2020 23:25:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJmj6-0000CZ-Ov; Wed, 01 Apr 2020 23:24:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcEj=5R=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJmj5-0000CU-9x
 for xen-devel@lists.xenproject.org; Wed, 01 Apr 2020 23:24:51 +0000
X-Inumbo-ID: fa51b538-746f-11ea-bb56-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fa51b538-746f-11ea-bb56-12813bfff9fa;
 Wed, 01 Apr 2020 23:24:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=eeP6gIKtahV13nUTWA1Cm0UDnvsPt/ELw/fdeJ+U9og=; b=yxEROdLuPFqgLnqHatntxV65s
 ngicXR8CktPIGSGQIuWYAs0KCPLuDd3gT/q3F/DO10Tv0BonawQhlRcnTo8YrakzK/41NxcFLMbqW
 JphzDHwcEVWOAJggz+sIMvcE5H83mcKx3KqW1sv5/zSHDh81KDGlxSJZ/I9uFGWNfe3ZA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJmj1-0006w2-Ih; Wed, 01 Apr 2020 23:24:47 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJmj0-0005Gl-S4; Wed, 01 Apr 2020 23:24:47 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJmj0-0000a7-RT; Wed, 01 Apr 2020 23:24:46 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149266-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149266: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:regression
 linux-linus:build-arm64-pvops:kernel-build:fail:regression
 linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore:fail:allowable
 linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=1a323ea5356edbb3073dc59d51b9e6b86908857d
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 01 Apr 2020 23:24:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine      4 memdisk-try-append       fail REGR. vs. 149238
 build-arm64-pvops             6 kernel-build             fail REGR. vs. 149238

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     15 guest-saverestore        fail REGR. vs. 149238

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

version targeted for testing:
 linux                1a323ea5356edbb3073dc59d51b9e6b86908857d
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    1 days
Testing same since   149266  2020-04-01 03:55:53 Z    0 days    1 attempts

------------------------------------------------------------
624 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  blocked 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  blocked 
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     blocked 
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 blocked 
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 02:09:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 02:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJpIA-0001ne-AD; Thu, 02 Apr 2020 02:09:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9JfQ=5S=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJpI9-0001nZ-H1
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 02:09:13 +0000
X-Inumbo-ID: f13ab744-7486-11ea-bb6c-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f13ab744-7486-11ea-bb6c-12813bfff9fa;
 Thu, 02 Apr 2020 02:09:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Rw4kgQXOI3LcyBBq0FBjpGxUcLbGrh2JVpE2Go1ZtSY=; b=Iabi1E8LWVIhc+oC3icULGBQT
 mkpplk/jY0RxpH2/WmIlTYCVWqAxFBBMUn2ZP2Mc+98JiPj52WUDVgJzGurDKzeC5UToIH4YfBppw
 gGFHEMM+MGg/MEm1GjTar5iMYZC9C+VwJsn4Xuctafnz/sewE5VJszzxmXCb7xql7y/tw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJpI6-0000mA-Mg; Thu, 02 Apr 2020 02:09:10 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJpI6-0004VF-7X; Thu, 02 Apr 2020 02:09:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJpI6-00089U-6p; Thu, 02 Apr 2020 02:09:10 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149270-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149270: regressions - FAIL
X-Osstest-Failures: linux-5.4:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:regression
 linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:heisenbug
 linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 linux-5.4:test-amd64-amd64-xl-rtds:guest-saverestore:fail:heisenbug
 linux-5.4:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug
 linux-5.4:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-5.4:test-amd64-amd64-dom0pvh-xl-intel:guest-start:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-dom0pvh-xl-amd:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: linux=462afcd6e7ea94a7027a96a3bb12d0140b0b4216
X-Osstest-Versions-That: linux=122179cb7d648a6f36b20dd6bf34f953cb384c30
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 02 Apr 2020 02:09:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 149244 pass in 149200
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 149244 pass in 149270
 test-amd64-amd64-xl-rtds     15 guest-saverestore          fail pass in 149244
 test-amd64-amd64-examine      4 memdisk-try-append         fail pass in 149244

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 15 guest-saverestore  fail baseline untested
 test-amd64-amd64-dom0pvh-xl-intel 12 guest-start fail in 149244 baseline untested
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-dom0pvh-xl-amd  2 hosts-allocate        starved in 149200 n/a

version targeted for testing:
 linux                462afcd6e7ea94a7027a96a3bb12d0140b0b4216
baseline version:
 linux                122179cb7d648a6f36b20dd6bf34f953cb384c30

Last test of basis   146121  2020-01-15 17:42:04 Z   77 days
Failing since        146178  2020-01-17 02:59:07 Z   75 days  102 attempts
Testing same since   149052  2020-03-26 11:07:11 Z    6 days    7 attempts

------------------------------------------------------------
1428 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 05:20:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 05:20:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJsGa-0000Qy-Sy; Thu, 02 Apr 2020 05:19:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9JfQ=5S=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJsGZ-0000QE-Sa
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 05:19:47 +0000
X-Inumbo-ID: 9183dafe-74a1-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9183dafe-74a1-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 05:19:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=zvTLZVxy9OnRbN3WHpzrPG//XoYAqIlWEeJbqz4AIpM=; b=1IHQHPqxvMrM+71axni8WoXOx
 94uiIKHRGL1xYkFsQ0Ok8LKNyg+nBhTS8aG1et3H2gxzgdgbi2+oDVK/VVc4VkxCbI29Ku0vk6RXo
 xJjQ+ErjtUpJi+g6oQm6GFofLwm0oWJ+HpQBofBVOmnlNbmdMIAU5g4ccP3rB+4SHxC0M=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJsGY-0004o0-I7; Thu, 02 Apr 2020 05:19:46 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJsGY-0004We-8Z; Thu, 02 Apr 2020 05:19:46 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJsGY-00039a-7z; Thu, 02 Apr 2020 05:19:46 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149292-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149292: all pass - PUSHED
X-Osstest-Versions-This: ovmf=e210fc130e5c9738909dca432bbf8bf277ba6e37
X-Osstest-Versions-That: ovmf=dd7523b5b123de6f0730f2f2abb207f2a5c1ccd4
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 02 Apr 2020 05:19:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

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

Last test of basis   149262  2020-04-01 00:39:27 Z    1 days
Testing same since   149292  2020-04-01 15:23:22 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laszlo Ersek <lersek@redhat.com>
  Liran Alon <liran.alon@oracle.com>
  Maciej Rabeda <maciej.rabeda@linux.intel.com>
  Vitaly Cheptsov <cheptsov@ispras.ru>
  Vitaly Cheptsov <vit9696@protonmail.com>
  Zhichao Gao <zhichao.gao@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   dd7523b5b1..e210fc130e  e210fc130e5c9738909dca432bbf8bf277ba6e37 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 06:20:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 06:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJtCw-00065Q-61; Thu, 02 Apr 2020 06:20:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJtCu-0005mb-9Q
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 06:20:04 +0000
X-Inumbo-ID: fc9699b4-74a9-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fc9699b4-74a9-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 06:20:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id EB418B167;
 Thu,  2 Apr 2020 06:20:01 +0000 (UTC)
Subject: Re: [PATCH] guestcopy: evaluate {,__}copy{,_field}_to_guest*()
 arguments just once
To: Julien Grall <julien@xen.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9918b339-e914-7228-5f8e-86c82090b5bd@suse.com>
 <b07fcc5a-60c1-a831-b4b1-a6de3f82b8b4@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <0c78d386-cb20-51cf-ec2f-4d9345ecf013@suse.com>
Date: Thu, 2 Apr 2020 08:20:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <b07fcc5a-60c1-a831-b4b1-a6de3f82b8b4@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 01.04.2020 23:28, Julien Grall wrote:
> On 01/04/2020 15:29, Jan Beulich wrote:
>> There's nothing wrong with having e.g.
>>
>>      copy_to_guest(uarg, ptr++, 1);
>>
>> yet until now this would increment "ptr" twice.
> 
> Is there such use in Xen today? I guess not as we would have noticed any issue.

I'm not aware of any.

>> --- a/xen/include/asm-arm/guest_access.h
>> +++ b/xen/include/asm-arm/guest_access.h
>> @@ -79,7 +79,7 @@ int access_guest_memory_by_ipa(struct do
>>       const typeof(*(ptr)) *_s = (ptr);                   \
>>       char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>>       void *__maybe_unused _t = (hnd).p;                  \
>> -    ((void)((hnd).p == (ptr)));                         \
>> +    (void)((hnd).p == _s);                              \
> 
> May I ask why this is a problem with 'ptr' but not 'hnd'?
> Wouldn't it theorically possible to have an array of handle?

Theoretically yes, but I view issues with the handle as far less
likely than issues with any of the other parameters (in particular
I don't see what an array of handles could be used for). So yes,
if we want to be eager, we could deal with that one as well.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 07:47:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 07:47:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJuYs-00048J-3l; Thu, 02 Apr 2020 07:46:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJuYq-00047D-VB
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 07:46:48 +0000
X-Inumbo-ID: 1ac6ebe4-74b6-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1ac6ebe4-74b6-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 07:46:47 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 44937AE39;
 Thu,  2 Apr 2020 07:46:46 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86/HVM: expose VM assist hypercall
Message-ID: <cb4a6f8f-eda8-f17c-54e5-af1353d6358c@suse.com>
Date: Thu, 2 Apr 2020 09:46:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In preparation for the addition of VMASST_TYPE_runstate_update_flag
commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
the hypercall for Arm. I consider it not logical that it then isn't also
exposed to x86 HVM guests (with the same single feature permitted to be
enabled as Arm has); Linux actually tries to use it afaict.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -78,6 +78,11 @@ static long hvm_grant_table_op(
 }
 #endif
 
+static long hvm_vm_assist(unsigned int cmd, unsigned int type)
+{
+    return vm_assist(current->domain, cmd, type, HVM_VM_ASSIST_VALID);
+}
+
 static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     const struct vcpu *curr = current;
@@ -128,6 +133,7 @@ static const hypercall_table_t hvm_hyper
 #ifdef CONFIG_GRANT_TABLE
     HVM_CALL(grant_table_op),
 #endif
+    HVM_CALL(vm_assist),
     COMPAT_CALL(vcpu_op),
     HVM_CALL(physdev_op),
     COMPAT_CALL(xen_version),
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -319,6 +319,7 @@ extern unsigned long xen_phys_start;
 #define VM_ASSIST_VALID          NATIVE_VM_ASSIST_VALID
 #define COMPAT_VM_ASSIST_VALID   (NATIVE_VM_ASSIST_VALID & \
                                   ((1UL << COMPAT_BITS_PER_LONG) - 1))
+#define HVM_VM_ASSIST_VALID      (1UL << VMASST_TYPE_runstate_update_flag)
 
 #define ELFSIZE 64
 


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 07:56:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 07:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJuhg-0004yp-0z; Thu, 02 Apr 2020 07:55:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJuhe-0004yk-ES
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 07:55:54 +0000
X-Inumbo-ID: 60745ab8-74b7-11ea-bb88-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 60745ab8-74b7-11ea-bb88-12813bfff9fa;
 Thu, 02 Apr 2020 07:55:53 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id F0DD1AAB8;
 Thu,  2 Apr 2020 07:55:52 +0000 (UTC)
Subject: Ping: [PATCH 4/4] x86/APIC: restrict certain messages to BSP
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <60130f14-3fc5-e40d-fec6-2448fefa6fc4@suse.com>
 <513e4f93-a8a0-ae72-abcc-aa28531eca97@suse.com>
 <bab16aee-bb0c-1e7b-62b8-4a70c54314a8@citrix.com>
 <59fb3a7c-dd03-d9f6-2588-aae300b3d28f@suse.com>
Message-ID: <bca78b96-54a2-8253-0b17-78726781bcc1@suse.com>
Date: Thu, 2 Apr 2020 09:55:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <59fb3a7c-dd03-d9f6-2588-aae300b3d28f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.03.2020 10:10, Jan Beulich wrote:
> On 13.03.2020 17:18, Andrew Cooper wrote:
>> On 13/03/2020 09:26, Jan Beulich wrote:
>>> All CPUs get an equal setting of EOI broadcast suppression; no need to
>>> log one message per CPU, even if it's only in verbose APIC mode.
>>>
>>> Only the BSP is eligible to possibly get ExtINT enabled; no need to log
>>> that it gets disabled on all APs, even if - again - it's only in verbose
>>> APIC mode.
>>
>> How true is this in practice?
> 
> I guess you read "eligible" as "in theory", whereas it is meant as "with
> how our [and in particular this] code is working right now". Even if we
> decided to switch the CPU to handle ExtINT, it still wouldn't need to be
> one message per CPU - it would suffice to issue the message for the one
> CPU getting ExtINT enabled.

Are you okay with the above explanation, and hence willing to give an
ack? If not, what alternative suggestion do you have to limit this
particular part of the log spam on very-many-CPU systems?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 07:57:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 07:57:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJuiz-00054a-CG; Thu, 02 Apr 2020 07:57:17 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJuiy-00054T-7F
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 07:57:16 +0000
X-Inumbo-ID: 90ac5e56-74b7-11ea-bb88-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 90ac5e56-74b7-11ea-bb88-12813bfff9fa;
 Thu, 02 Apr 2020 07:57:14 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 10BC8ADB3;
 Thu,  2 Apr 2020 07:57:14 +0000 (UTC)
Subject: Ping: [PATCH v2] x86/PV: remove unnecessary toggle_guest_pt() overhead
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <47cf43bb-9643-011f-45c2-7cb63c422c3f@suse.com>
Message-ID: <e76ebb11-94c7-9d81-1a1a-9a563bd750a1@suse.com>
Date: Thu, 2 Apr 2020 09:57:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <47cf43bb-9643-011f-45c2-7cb63c422c3f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.12.2019 15:06, Jan Beulich wrote:
> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
> expensive (but still needed only for the toggle_guest_mode() path), the
> effect of the latter on the exit-to-guest path is not insignificant.
> Move the logic into toggle_guest_mode(), on the basis that
> toggle_guest_pt() will always be invoked in pairs, yet we can't safely
> undo the setting of root_pgt_changed during the second of these
> invocations.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: Extend description.

Ping?

> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -365,18 +365,10 @@ bool __init xpti_pcid_enabled(void)
>  
>  static void _toggle_guest_pt(struct vcpu *v)
>  {
> -    const struct domain *d = v->domain;
> -    struct cpu_info *cpu_info = get_cpu_info();
>      unsigned long cr3;
>  
>      v->arch.flags ^= TF_kernel_mode;
>      update_cr3(v);
> -    if ( d->arch.pv.xpti )
> -    {
> -        cpu_info->root_pgt_changed = true;
> -        cpu_info->pv_cr3 = __pa(this_cpu(root_pgt)) |
> -                           (d->arch.pv.pcid ? get_pcid_bits(v, true) : 0);
> -    }
>  
>      /*
>       * Don't flush user global mappings from the TLB. Don't tick TLB clock.
> @@ -384,15 +376,11 @@ static void _toggle_guest_pt(struct vcpu
>       * In shadow mode, though, update_cr3() may need to be accompanied by a
>       * TLB flush (for just the incoming PCID), as the top level page table may
>       * have changed behind our backs. To be on the safe side, suppress the
> -     * no-flush unconditionally in this case. The XPTI CR3 write, if enabled,
> -     * will then need to be a flushing one too.
> +     * no-flush unconditionally in this case.
>       */
>      cr3 = v->arch.cr3;
> -    if ( shadow_mode_enabled(d) )
> -    {
> +    if ( shadow_mode_enabled(v->domain) )
>          cr3 &= ~X86_CR3_NOFLUSH;
> -        cpu_info->pv_cr3 &= ~X86_CR3_NOFLUSH;
> -    }
>      write_cr3(cr3);
>  
>      if ( !(v->arch.flags & TF_kernel_mode) )
> @@ -408,6 +396,8 @@ static void _toggle_guest_pt(struct vcpu
>  
>  void toggle_guest_mode(struct vcpu *v)
>  {
> +    const struct domain *d = v->domain;
> +
>      ASSERT(!is_pv_32bit_vcpu(v));
>  
>      /* %fs/%gs bases can only be stale if WR{FS,GS}BASE are usable. */
> @@ -421,6 +411,21 @@ void toggle_guest_mode(struct vcpu *v)
>      asm volatile ( "swapgs" );
>  
>      _toggle_guest_pt(v);
> +
> +    if ( d->arch.pv.xpti )
> +    {
> +        struct cpu_info *cpu_info = get_cpu_info();
> +
> +        cpu_info->root_pgt_changed = true;
> +        cpu_info->pv_cr3 = __pa(this_cpu(root_pgt)) |
> +                           (d->arch.pv.pcid ? get_pcid_bits(v, true) : 0);
> +        /*
> +         * As in _toggle_guest_pt() the XPTI CR3 write needs to be a TLB-
> +         * flushing one too for shadow mode guests.
> +         */
> +        if ( shadow_mode_enabled(d) )
> +            cpu_info->pv_cr3 &= ~X86_CR3_NOFLUSH;
> +    }
>  }
>  
>  void toggle_guest_pt(struct vcpu *v)
> 



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 08:18:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 08:18:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJv3B-0007IC-Hu; Thu, 02 Apr 2020 08:18:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=X1La=5S=arm.com=bertrand.marquis@srs-us1.protection.inumbo.net>)
 id 1jJv3A-0007I7-8N
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 08:18:08 +0000
X-Inumbo-ID: 79ff6a88-74ba-11ea-b58d-bc764e2007e4
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (unknown
 [2a01:111:f400:fe08::609])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 79ff6a88-74ba-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 08:18:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; 
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=49QIskKHJQLPIVNSMR8LT2XHuYRAqL92AqAUdN6HKhc=;
 b=wG9I/Y0UtkF7ePOFDYtYP2tQzpCSEerwhiky1JwVIil+mGCy31m5w8f9bzZOvwB+NSgSp+p4k2hTc6T3Hcttx44k2K0X1UEaoQFlNPoie/L1w8Pj1Al6nXL5oSGJeh5FYCWL3D5sCgPgZQKqb4n5ztUGiumIm2oajqS0HcNPWVU=
Received: from DB8PR06CA0035.eurprd06.prod.outlook.com (2603:10a6:10:100::48)
 by AM6PR08MB3174.eurprd08.prod.outlook.com (2603:10a6:209:45::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Thu, 2 Apr
 2020 08:18:03 +0000
Received: from DB5EUR03FT007.eop-EUR03.prod.protection.outlook.com
 (2603:10a6:10:100:cafe::41) by DB8PR06CA0035.outlook.office365.com
 (2603:10a6:10:100::48) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20 via Frontend
 Transport; Thu, 2 Apr 2020 08:18:03 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was
 verified) header.d=armh.onmicrosoft.com;lists.xenproject.org;
 dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB5EUR03FT007.mail.protection.outlook.com (10.152.20.148) with
 Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2856.17 via Frontend Transport; Thu, 2 Apr 2020 08:18:03 +0000
Received: ("Tessian outbound e2c88df8bbbe:v50");
 Thu, 02 Apr 2020 08:18:02 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 85b9c7e96a162aeb
X-CR-MTA-TID: 64aa7808
Received: from a2487f2a0395.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 BDAFF981-EDD3-4387-B6F4-130CB090BF0F.1; 
 Thu, 02 Apr 2020 08:17:57 +0000
Received: from EUR01-HE1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a2487f2a0395.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Thu, 02 Apr 2020 08:17:57 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=cgquZ9O/YP/s+uhrBR/I10AXRwsPBYxikxlqyE6w12NFV9gtfYJaLHGE2u0lgcHk12a5ba3n2/5nVrsUcqvA9fY4Z29KwUqaaDqrq7gAk9RGqnvXRDQGmiTAHRift0slY4IsYL3CpTCQY1wmZ4/WD19wkjN/oW19NUkG5nS0wH1Ahwlr+y+rtjYlCi3h+HFR5dBrG6x5nqW5dQ+IaoEwZjrcJUbH44F9mnceCsqHxUcfRXgmgGbVqibVhjtuk4R51zHJmuPgpj7pSRGQP4OAtCTuU5oIgst1b/EEVSh5O/dfUG/iXw/ZU9nsxAwUAEiNFBtLQRLOZi1sxL12Q6UUSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=49QIskKHJQLPIVNSMR8LT2XHuYRAqL92AqAUdN6HKhc=;
 b=CrQ9FQak13jfU0etHoCTdQ6BQXCjlFggQSjmocVqEHwUtcXgWeWTbsaf3gtMfPRTPuyrlicLYevMYqXGZJUKH/XvO8yXsQsBBUPQ7tqgFhI5f3TDvqxKG5Yz3LcO232g9uDSynO7Fs2hxUv4pfsvOi9NIrlL55k2Ck41udjvXdzoHQCJV9atBiBRCOeJmfwOPgIKLNXw6NzOkNHlANPPqnkZPB1OlMscCkrUOzVVZAEeRsvTovoU/tZ8Bo7ZfSekPr+hszv/Ulrupys/5zczR5Nk+YdA/OMqHEZtBnqShLvXMgK+Uh6STH9zBKdoUxshhRV8v0O2NbHwdBEGfNdf7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; 
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=49QIskKHJQLPIVNSMR8LT2XHuYRAqL92AqAUdN6HKhc=;
 b=wG9I/Y0UtkF7ePOFDYtYP2tQzpCSEerwhiky1JwVIil+mGCy31m5w8f9bzZOvwB+NSgSp+p4k2hTc6T3Hcttx44k2K0X1UEaoQFlNPoie/L1w8Pj1Al6nXL5oSGJeh5FYCWL3D5sCgPgZQKqb4n5ztUGiumIm2oajqS0HcNPWVU=
Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (20.178.46.80) by
 DB7PR08MB3452.eurprd08.prod.outlook.com (20.177.120.13) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2856.19; Thu, 2 Apr 2020 08:17:45 +0000
Received: from DB7PR08MB3689.eurprd08.prod.outlook.com
 ([fe80::94d7:a242:40b4:cfb5]) by DB7PR08MB3689.eurprd08.prod.outlook.com
 ([fe80::94d7:a242:40b4:cfb5%6]) with mapi id 15.20.2878.016; Thu, 2 Apr 2020
 08:17:45 +0000
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Topic: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Index: AQHWB8CUPtV45V7pfkaBDuUahGESj6hj8BaAgAAXawCAAH2GAIAA+deA
Date: Thu, 2 Apr 2020 08:17:45 +0000
Message-ID: <760EB332-F1E4-44E0-AB3B-2CEBECDBC1F0@arm.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <A33FEB65-F844-4CA6-BAE0-F0C881CFD381@arm.com>
 <5e788594-93bd-4bf0-1113-5d55a4f5f8bc@xen.org>
In-Reply-To: <5e788594-93bd-4bf0-1113-5d55a4f5f8bc@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Authentication-Results-Original: spf=none (sender IP is )
 smtp.mailfrom=Bertrand.Marquis@arm.com; 
x-originating-ip: [217.140.99.251]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: b50847e4-8c4a-4664-7fb4-08d7d6de5d29
x-ms-traffictypediagnostic: DB7PR08MB3452:|AM6PR08MB3174:
X-Microsoft-Antispam-PRVS: <AM6PR08MB3174F2FD0646F5D6314641259DC60@AM6PR08MB3174.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0361212EA8
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en;
 SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com;
 PTR:; CAT:NONE; SFTY:;
 SFS:(10009020)(4636009)(346002)(396003)(376002)(366004)(136003)(39860400002)(26005)(81156014)(186003)(6486002)(478600001)(6916009)(53546011)(5660300002)(2616005)(33656002)(8936002)(81166006)(71200400001)(54906003)(8676002)(4326008)(36756003)(66476007)(66556008)(64756008)(66446008)(6506007)(76116006)(2906002)(6512007)(316002)(86362001)(91956017)(66946007);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: HTG7ORIy5V6IrrEAp9paLh7z5Cc5M0YmsXrDWw9tBbG1GNkCjB9jk/LEEwS28yQSPFuR129dir1ywwl9WANRGhBgZwYL/Zpcb+hvLitb+mLWtKFd7su8gTp701vqFRQUMxmkZeOfek1j6FAcli7978RDQT5hoN7RMlJkRC/JjVZIFx2/a/KSs1wqxxrqByLZsZQ6YZZSZPHwUbBuZYhOPHfyE+rsGIvKjGjdvojN7CEAK+DYfSf4o0byNiqnj0Fn67L5t6hLwydtbFoRVhz2waov+ykg0QrWmsv4uLSULK+Mdl/HsLoKY4Ck6lAYHR5M/KUniVPX9zvDk5UXJBB4y5XTZ26kd80+OHXoIAVcpKX/MZ1Ku5lQObVjVKJde2wuB+qbEcSshaRH2Oy/9LmucoKVQ9ldiqES0Wf2yey1iTHZkyH6kZ9VC07Ch5Sz2ufG
x-ms-exchange-antispam-messagedata: l5M3CnZ2FNZG7pKb+BLShrLpC0tpPd7l1sd/G7DG6igFI7+rLrCvuMxguDv/Q1OsLIxi5MPh2qLWXQJKHF739B6GqdVwr2cMz5ehCtyFvpXAFHAKX7x9o9AnURWXqpOdBuSP19N7kBUePNn2FNQYIg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <9D47431E199E7944B01D3DFEF39D65F5@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3452
Original-Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=Bertrand.Marquis@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT007.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;
 IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;
 PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:;
 SFS:(10009020)(4636009)(346002)(396003)(136003)(39860400002)(376002)(46966005)(186003)(5660300002)(107886003)(86362001)(8676002)(6512007)(6862004)(26005)(36756003)(81156014)(81166006)(4326008)(356004)(316002)(47076004)(54906003)(70586007)(2906002)(53546011)(70206006)(478600001)(26826003)(8936002)(82740400003)(33656002)(6506007)(2616005)(6486002)(336012);
 DIR:OUT; SFP:1101; 
X-MS-Office365-Filtering-Correlation-Id-Prvs: c5824f1d-694e-4208-950a-08d7d6de52e8
X-Forefront-PRVS: 0361212EA8
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: betu3PLIy/v9OfAfmJUzva3qmu/HLMO5IXq7AY+ysSc0JBVgCDFfMumZBwBopbZ3PQjiNHIpmTpMmuDIqNXeVoQD+UOUN1BxRgH8H+ufVZkWlPRK5NDYi8jd1FiVfRd16hQTpahj03gbuRpUa5NmLo/tZQCMASkJZ1xs9lLHg3VLkAlz515gl7U2kJ0CWDjge9MwG3M/38IJthp8an3g7X5brfA3ZQf8VFr/1qQ06Yb35RLHFEckzzmQW8xcvfDBN/wB6ZqrouyxN9m6Fw+Z5OP4Fv3mlxCntXdH/d44TL3ozT2BZ6vt2+al4Jj61NgFXSJlPSzmXGFjlqIBqTVtKITtouZKgFJMF6AniXUiAO8cKZBpAgjVdZ+7G3T1xPpN96+dQFJX1bWRcEOdxAHyIxc6U/y6q1qbHAdEavS1bSF4UFHHI2rcmzVM/LX8Phr4AxbbZRaCXfmypplfpBrnkqFKuXvSDOB2PW+h6lmuwUSLaVrHNycMUT6FBGkKiCcRWUdKWRlcn/Fmc4FYKqIcAw==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2020 08:18:03.0218 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b50847e4-8c4a-4664-7fb4-08d7d6de5d29
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];
 Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3174
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 "George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
 Wei Xu <xuwei5@hisilicon.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 nd <nd@arm.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gMSBBcHIgMjAyMCwgYXQgMTg6MjMsIEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5v
cmc+IHdyb3RlOg0KPiANCj4gDQo+IA0KPiBPbiAwMS8wNC8yMDIwIDEwOjU0LCBCZXJ0cmFuZCBN
YXJxdWlzIHdyb3RlOg0KPj4+IE9uIDEgQXByIDIwMjAsIGF0IDA5OjMwLCBKdWxpZW4gR3JhbGwg
PGp1bGllbkB4ZW4ub3JnIDxtYWlsdG86anVsaWVuQHhlbi5vcmc+PiB3cm90ZToNCj4+PiANCj4+
PiANCj4+PiANCj4+PiBPbiAwMS8wNC8yMDIwIDAxOjU3LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6DQo+Pj4+IE9uIE1vbiwgMzAgTWFyIDIwMjAsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+Pj4+
IEhpIFN0ZWZhbm8sDQo+Pj4+PiANCj4+Pj4+IE9uIDMwLzAzLzIwMjAgMTc6MzUsIFN0ZWZhbm8g
U3RhYmVsbGluaSB3cm90ZToNCj4+Pj4+PiBPbiBTYXQsIDI4IE1hciAyMDIwLCBKdWxpZW4gR3Jh
bGwgd3JvdGU6DQo+Pj4+Pj4+IHFIaSBTdGVmYW5vLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gMjcv
MDMvMjAyMCAwMjozNCwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOg0KPj4+Pj4+Pj4gVGhpcyBp
cyBhIHNpbXBsZSBpbXBsZW1lbnRhdGlvbiBvZiBHSUNEX0lDQUNUSVZFUiAvIEdJQ0RfSVNBQ1RJ
VkVSDQo+Pj4+Pj4+PiByZWFkcy4gSXQgZG9lc24ndCB0YWtlIGludG8gYWNjb3VudCB0aGUgbGF0
ZXN0IHN0YXRlIG9mIGludGVycnVwdHMgb24NCj4+Pj4+Pj4+IG90aGVyIHZDUFVzLiBPbmx5IHRo
ZSBjdXJyZW50IHZDUFUgaXMgdXAtdG8tZGF0ZS4gQSBmdWxsIHNvbHV0aW9uIGlzDQo+Pj4+Pj4+
PiBub3QgcG9zc2libGUgYmVjYXVzZSBpdCB3b3VsZCByZXF1aXJlIHN5bmNocm9uaXphdGlvbiBh
bW9uZyBhbGwgdkNQVXMsDQo+Pj4+Pj4+PiB3aGljaCB3b3VsZCBiZSB2ZXJ5IGV4cGVuc2l2ZSBp
biB0ZXJtcyBvciBsYXRlbmN5Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gWW91ciBzZW50ZW5jZSBzdWdn
ZXN0cyB5b3UgaGF2ZSBudW1iZXIgc2hvd2luZyB0aGF0IGNvcnJlY3RseSBlbXVsYXRpbmcNCj4+
Pj4+Pj4gdGhlDQo+Pj4+Pj4+IHJlZ2lzdGVycyB3b3VsZCBiZSB0b28gc2xvdy4gTWluZCBzaGFy
aW5nIHRoZW0/DQo+Pj4+Pj4gDQo+Pj4+Pj4gTm8sIEkgZG9uJ3QgaGF2ZSBhbnkgbnVtYmVycy4g
V291bGQgeW91IHByZWZlciBhIGRpZmZlcmVudCB3b3JkaW5nIG9yIGENCj4+Pj4+PiBiZXR0ZXIg
ZXhwbGFuYXRpb24/IEkgYWxzbyByZWFsaXplZCB0aGVyZSBpcyBhIHR5cG8gaW4gdGhlcmUgKG9y
L29mKS4NCj4+Pj4+IExldCBtZSBzdGFydCB3aXRoIEkgdGhpbmsgY29ycmVjdG5lc3MgaXMgbW9y
ZSBpbXBvcnRhbnQgdGhhbiBzcGVlZC4NCj4+Pj4+IFNvIEkgd291bGQgaGF2ZSBleHBlY3RlZCB5
b3VyIGNvbW1pdCBtZXNzYWdlIHRvIGNvbnRhaW4gc29tZSBmYWN0IHdoeQ0KPj4+Pj4gc3luY2hy
b25pemF0aW9uIGlzIGdvaW5nIHRvIGJlIHNsb3cgYW5kIHdoeSB0aGlzIGlzIGEgcHJvYmxlbS4N
Cj4+Pj4+IA0KPj4+Pj4gVG8gZ2l2ZSB5b3UgYSBjb25jcmV0ZSBleGFtcGxlLCB0aGUgaW1wbGVt
ZW50YXRpb24gb2Ygc2V0L3dheSBpbnN0cnVjdGlvbnMgYXJlDQo+Pj4+PiByZWFsbHkgc2xvdyAo
aXQgY291bGQgdGFrZSBhIGZldyBzZWNvbmRzIGRlcGVuZGluZyBvbiB0aGUgc2V0dXApLiBIb3dl
dmVyLA0KPj4+Pj4gdGhpcyB3YXMgZmluZSBiZWNhdXNlIG5vdCBpbXBsZW1lbnRpbmcgdGhlbSBj
b3JyZWN0bHkgd291bGQgaGF2ZSBhIGdyZWF0ZXINCj4+Pj4+IGltcGFjdCBvbiB0aGUgZ3Vlc3Qg
KGNvcnJ1cHRpb24pIGFuZCB0aGV5IGFyZSBub3QgdXNlZCBvZnRlbi4NCj4+Pj4+IA0KPj4+Pj4g
SSBkb24ndCB0aGluayB0aGUgcGVyZm9ybWFuY2UgaW4gb3VyIGNhc2Ugd2lsbCBiZSBpbiBzYW1l
IG9yZGVyIG1hZ25pdHVkZS4gSXQNCj4+Pj4+IGlzIG1vc3QgbGlrZWx5IHRvIGJlIGluIHRoZSBy
YW5nZSBvZiBtaWxsaXNlY29uZHMgKGlmIG5vdCBsZXNzKSB3aGljaCBJIHRoaW5rDQo+Pj4+PiBp
cyBhY2NlcHRhYmxlIGZvciBlbXVsYXRpb24gKHBhcnRpY3VsYXJseSBmb3IgdGhlIHZHSUMpIGFu
ZCB0aGUgY3VycmVudCB1c2VzLg0KPj4+PiBXcml0aW5nIG9uIHRoZSBtYWlsaW5nIGxpc3Qgc29t
ZSBvZiBvdXIgZGlzY3Vzc2lvbnMgdG9kYXkuDQo+Pj4+IENvcnJlY3RuZXNzIGlzIG5vdCBqdXN0
IGluIHRlcm1zIG9mIGNvbXBsaWFuY2UgdG8gYSBzcGVjaWZpY2F0aW9uIGJ1dCBpdA0KPj4+PiBp
cyBhbHNvIGFib3V0IG5vdCBicmVha2luZyBndWVzdHMuIEludHJvZHVjaW5nIGxhdGVuY3kgaW4g
dGhlIHJhbmdlIG9mDQo+Pj4+IG1pbGxpc2Vjb25kcywgb3IgaHVuZHJlZHMgb2YgbWljcm9zZWNv
bmRzLCB3b3VsZCBicmVhayBhbnkgbGF0ZW5jeQ0KPj4+PiBzZW5zaXRpdmUgd29ya2xvYWRzLiBX
ZSBkb24ndCBoYXZlIG51bWJlcnMgc28gd2UgZG9uJ3Qga25vdyBmb3IgY2VydGFpbg0KPj4+PiB0
aGUgZWZmZWN0IHRoYXQgeW91ciBzdWdnZXN0aW9uIHdvdWxkIGhhdmUuDQo+Pj4gDQo+Pj4gWW91
IG1pc3NlZCBwYXJ0IG9mIHRoZSBkaXNjdXNzaW9uLiBJIGRvbid0IGRpc2FncmVlIHRoYXQgbGF0
ZW5jeSBpcyBpbXBvcnRhbnQuIEhvd2V2ZXIsIGlmIGFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkg
OTUlIHJlbGlhYmxlLCB0aGVuIGl0IG1lYW5zIDUlIG9mIHRoZSB0aW1lIHlvdXIgZ3Vlc3QgbWF5
IGJyZWFrIChjb3JydXB0aW9uLCBjcmFzaCwgZGVhZGxvY2suLi4pLiBBdCB3aGljaCBwb2ludCB0
aGUgbGF0ZW5jeSBpcyB0aGUgbGFzdCBvZiB5b3VyIGNvbmNlcm4uDQo+Pj4gDQo+Pj4+IEl0IHdv
dWxkIGJlIGludGVyZXN0aW5nIHRvIGhhdmUgdGhvc2UgbnVtYmVycywgYW5kIEknbGwgYWRkIHRv
IG15IFRPRE8NCj4+Pj4gbGlzdCB0byBydW4gdGhlIGV4cGVyaW1lbnRzIHlvdSBzdWdnZXN0ZWQs
IGJ1dCBJJ2xsIHB1dCBpdCBvbiB0aGUNCj4+Pj4gYmFjay1idXJuZXIgKGZyb20gYSBYaWxpbngg
cGVyc3BlY3RpdmUgaXQgaXMgbG93IHByaW9yaXR5IGFzIG5vDQo+Pj4+IGN1c3RvbWVycyBhcmUg
YWZmZWN0ZWQuKQ0KPj4+IA0KPj4+IEhvdyBhYm91dCB3ZSBnZXQgYSBjb3JyZWN0IGltcGxlbWVu
dGF0aW9uIG1lcmdlIGZpcnN0IGFuZCB0aGVuIGRpc2N1c3MgYWJvdXQgb3B0aW1pemF0aW9uPyBU
aGlzIHdvdWxkIGFsbG93IHRoZSBjb21tdW5pdHkgdG8gY2hlY2sgd2hldGhlciB0aGVyZSBhcmUg
YWN0dWFsbHkgbm90aWNlYWJsZSBsYXRlbmN5IGluIHRoZWlyIHdvcmtsb2FkLg0KPj4gSGksDQo+
IA0KPiBIaSwNCg0KSGksDQoNCj4gDQo+PiBJIGFtIG5vdCBzdXJlIHRoYXQgcHVzaGluZyBzb21l
dGhpbmcgd2l0aCBhIHBlcmZvcm1hbmNlIGltcGFjdCB0byBsYXRlciBmaXggaXQgaXMgdGhlIHJp
Z2h0IGFwcHJvYWNoIGhlcmUuDQo+PiBUaGUgcGF0Y2ggaXMgYW4gaW1wcm92ZW1lbnQgY29tcGFy
ZWQgdG8gdGhlIGN1cnJlbnQgY29kZSBhbmQgaXQgY2FuIGJlIGZ1cnRoZXIgaW1wcm92ZWQgbGF0
ZXIgdG8gaGFuZGxlIG1vcmUgY2FzZXMgKG90aGVyIGNvcmVzKS4NCj4gDQo+IElmIHlvdSByZWFk
IG15IG90aGVyIGFuc3dlciBvbiB0aGlzIHBhdGNoIHlvdSB3aWxsIHNlZSB0aGF0IHRoaXMgaXMg
Z29pbmcgdG8gaW50cm9kdWNlIGEgZGVhZGxvY2sgaW4gdGhlIGd1ZXN0IHVzaW5nIG11bHRpcGxl
IHZDUFVzLiBIb3cgaXMgaXQgYW4gaW1wcm92ZW1lbnQgY29tcGFyZSB0byB0b2RheT8NCg0KSSBm
dWxseSBhZ3JlZSB3aXRoIHRoZSBmYWN0IHRoYXQgYSBkZWFkbG9jayBldmVuIHdpdGggbG93IHBy
b2JhYmlsaXR5IGlzIGEgbm8tZ28uDQpDdXJyZW50IGltcGxlbWVudGF0aW9uIHJldHVybmluZyBh
bHdheXMgMCBpcyBub3QgY3JlYXRpbmcgdGhpcyBkZWFkbG9jayBjYXNlIGJ1dCBjYW4gbWlzbGVh
ZCBpbiB0aGUgb3RoZXIgd2F5IGxldHRpbmcgb24gQ1BVIHRoaW5rIHRoYXQgdGhlIGludGVycnVw
dCBoYXMgYmVlbiBoYW5kbGVkIGFscmVhZHkgd2hlbiBpdCBoYXMgcG9zc2libHkgbm90IGJlZW4u
DQoNCj4gDQo+PiBJZiB3ZSByZWFsbHkgaGF2ZSB0byBzeW5jIGFsbCB2Q1BVcyBoZXJlLCB0aGlz
IHdpbGwgY29zdCBhIGxvdCBhbmQgdGhlIHJlc3VsdCB3aWxsIHN0aWxsIGJlIHRoZSBzdGF0dXMg
aW4gdGhlIHBhc3QgaW4gZmFjdCBiZWNhdXNlIG5vdGhpbmcgd2lsbCBtYWtlIHN1cmUgdGhhdCBh
dCB0aGUgcG9pbnQgdGhlIGd1ZXN0IGdldHMgYmFjayB0aGUgdmFsdWUgaXQgaXMgc3RpbGwgdmFs
aWQuDQo+IA0KPiBJIGhvcGUgeW91IGFyZSBhd2FyZSB0aGUgcHJvYmxlbSBpcyBleGFjdGx5IHRo
ZSBzYW1lIGluIHRoZSBoYXJkd2FyZS4gQXMgc29vbiBhcyB5b3UgcmVhZCB0aGUgSVNBQ1RJVkVS
LCB0aGVuIHRoZSB2YWx1ZSBtYXkgbm90IGJlIGNvcnJlY3QgYW55bW9yZS4gU28gSSBkb24ndCBz
ZWUgdGhlIGlzc3VlIHRvIGhhdmUgYW4gb3V0ZGF0ZWQgdmFsdWUgaGVyZS4NCg0KTWFpbiBkaWZm
ZXJlbmNlIGJlaW5nIHRoYXQgaW4gdGhlIGhhcmR3YXJlIHlvdSBjYW4gc3RpbGwgcG9sbCBmb3Ig
aXQgYW5kIGJlIHN1cmUgdGhhdCBpdCB3b27igJl0IGVuZCB1cCBpbiB5b3VyIGRlYWRsb2NrLg0K
U28gSSBhZ3JlZSwgd2UgbmVlZCB0byBmaW5kIGEgY2xlYW4gc29sdXRpb24gaGVyZS4NCg0KPiAN
Cj4gQXMgSSBzYWlkIHRvIFN0ZWZhbm8geWVzdGVyZGF5LCBJIHdvdWxkIGJlIGhhcHB5IHRvIGNv
bXByb21pc2UgYXMgbG9uZyBhcyB0aGUgaW1wbGVtZW50YXRpb24gZG9lcyBub3QgaW50cm9kdWNl
IGFuIG91dHJpZ2h0IGRlYWRsb2NrIGluIHRoZSBndWVzdC4NCj4gDQo+IEF0IHRoZSBtb21lbnQs
IEkgZG9uJ3QgaGF2ZSBhIGJldHRlciBhcHByb2FjaCB0aGFuIGtpY2sgYWxsIHRoZSB2Q1BVcy4g
RmVlbCBmcmVlIHRvIHN1Z2dlc3QgYSBiZXR0ZXIgb25lLg0KDQpPbmx5IG9uZSB0aGF0IEkgc2Vl
IGlzIHRvIGVuZm9yY2UgYSBzZXJ2aWNlIGludGVycnVwdCB3aGVuIGludGVycnVwdHMgaGF2ZSBi
ZWVuIGhhbmRsZWQgdG8gbWFrZSBzdXJlIHRoYXQgd2UgY2xlYW4gdXAgdGhlIGludGVybmFsIGFj
dGl2ZSBzdGF0dXMgYXMgc29vbiBhcyBpbnRlcnJ1cHQgaGFzIGFjdHVhbGx5IGJlZW4gaGFuZGxl
Lg0KVGhpcyB3b3VsZCBlbnN1cmUgdGhhdCB0aGUgcG9sbGluZyBpcyBiZWhhdmluZyBwcm9wZXJs
eSBmcm9tIHRoZSBndWVzdCBwb2ludCBvZiB2aWV3IGJ1dCB3b3VsZCBwcmV2ZW50IHRoZSBjcm9z
cyBjcHUgc3luYyAoc3RhdHVzIHdpbGwgYmUgcmlnaHQgYXMgc29vbiBhcyB0aGUgaW50ZXJydXB0
IHdpbGwgaGF2ZSBiZWVuIHNlcnZpY2VkKS4NCkJ1dCB0aGUgdHJhZGUgb2ZmIHdpbGwgYmUgYSBi
aWdnZXIgb3ZlcmhlYWQgYnkgZW5mb3JjaW5nIGEgcmV0dXJuIGJhY2sgdG8geGVuIGVhY2ggdGlt
ZSBhbmQgaW50ZXJydXB0IGlzIGhhbmRsZWQgYnkgYSBndWVzdC4NCg0KSSB3aWxsIHRyeSB0byBz
cGVuZCBtb3JlIHRpbWUgb24gdGhpcyBhbmQgZGlzY3VzcyB3aXRoIHRoZSBHSUMgZW5naW5lZXJz
IGF0IEFybSB0byBkaWcgZGVlcGVyIGluIHRoaXMgY2FzZS4NCg0KQ2hlZXJzDQpCZXJ0cmFuZA0K
DQo+IA0KPiBDaGVlcnMsDQo+IA0KPiAtLSANCj4gSnVsaWVuIEdyYWxsDQoNCg==


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 08:22:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 08:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJv7M-00085F-8Q; Thu, 02 Apr 2020 08:22:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJv7K-000856-TK
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 08:22:26 +0000
X-Inumbo-ID: 14ddbf0a-74bb-11ea-bb88-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 14ddbf0a-74bb-11ea-bb88-12813bfff9fa;
 Thu, 02 Apr 2020 08:22:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id F38FDADAB;
 Thu,  2 Apr 2020 08:22:23 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v2 0/2] x86/cpuidle: Cannon Lake adjustments
Message-ID: <e39d4326-57d1-a4b5-3081-76b5160644ae@suse.com>
Date: Thu, 2 Apr 2020 10:22:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

As requested in reply to v1, this is now a pair of patches with
the expectation that only patch 1 would be acked and go in.

1: drop Cannon Lake support
2: support Cannon Lake (again)

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 08:24:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 08:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJv9R-0008Bt-La; Thu, 02 Apr 2020 08:24:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJv9Q-0008Bo-KO
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 08:24:36 +0000
X-Inumbo-ID: 62c9049a-74bb-11ea-bb88-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 62c9049a-74bb-11ea-bb88-12813bfff9fa;
 Thu, 02 Apr 2020 08:24:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 10193ACC6;
 Thu,  2 Apr 2020 08:24:35 +0000 (UTC)
Subject: [PATCH v2 1/2] x86/cpuidle: drop Cannon Lake support
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e39d4326-57d1-a4b5-3081-76b5160644ae@suse.com>
Message-ID: <0a95dc08-d547-a7c0-1a82-d28f7290e93b@suse.com>
Date: Thu, 2 Apr 2020 10:24:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <e39d4326-57d1-a4b5-3081-76b5160644ae@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

As per SDM rev 071 Cannon Lake has
- no CC3 residency MSR at 3FC,
- a CC1 residency MSR ar 660 (like various Atoms),
- a useless (always zero) CC3 residency MSR at 662.
However, this CPU model has been discontinued and isn't a primary target
of Xen anyway. Hence (at least for now) rather than correcting things,
simply drop the case label altogether.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Split from larger patch.

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -180,8 +180,6 @@ static void do_get_hw_residencies(void *
     case 0x4E:
     case 0x55:
     case 0x5E:
-    /* Cannon Lake */
-    case 0x66:
     /* Kaby Lake */
     case 0x8E:
     case 0x9E:



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 08:25:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 08:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJv9q-0008Eg-UK; Thu, 02 Apr 2020 08:25:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJv9o-0008EQ-Vj
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 08:25:01 +0000
X-Inumbo-ID: 716b2c1c-74bb-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 716b2c1c-74bb-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 08:25:00 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9462AADAB;
 Thu,  2 Apr 2020 08:24:59 +0000 (UTC)
Subject: [PATCH v2 2/2] x86/cpuidle: support Cannon Lake (again)
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e39d4326-57d1-a4b5-3081-76b5160644ae@suse.com>
Message-ID: <91bbd232-a96c-6b00-fbaa-ac8094eb0cfe@suse.com>
Date: Thu, 2 Apr 2020 10:24:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <e39d4326-57d1-a4b5-3081-76b5160644ae@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

As per SDM rev 071 Cannon Lake has
- no CC3 residency MSR at 3FC,
- a CC1 residency MSR ar 660 (like various Atoms),
- a useless (always zero) CC3 residency MSR at 662.
Hence it needs a separate case label.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Split. This patch is beign submitted more for completeness than with
    the expectation that it would get acked, as per the v1 feedback.
---
Using the MSR cross reference in the same SDM revision one might even
get the impression that further MSRs are unavailable, but newer CPUs
don't appear to be consistently listed there at all, so may rather be a
doc shortcoming. I've pointed this out to Intel, but I'm not expecting
swift feedback.

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -69,7 +69,7 @@
 #define GET_PC8_RES(val)  GET_HW_RES_IN_NS(0x630, val) /* some Haswells only */
 #define GET_PC9_RES(val)  GET_HW_RES_IN_NS(0x631, val) /* some Haswells only */
 #define GET_PC10_RES(val) GET_HW_RES_IN_NS(0x632, val) /* some Haswells only */
-#define GET_CC1_RES(val)  GET_HW_RES_IN_NS(0x660, val) /* Silvermont only */
+#define GET_CC1_RES(val)  GET_HW_RES_IN_NS(0x660, val)
 #define GET_CC3_RES(val)  GET_HW_RES_IN_NS(0x3FC, val)
 #define GET_CC6_RES(val)  GET_HW_RES_IN_NS(0x3FD, val)
 #define GET_CC7_RES(val)  GET_HW_RES_IN_NS(0x3FE, val) /* SNB onwards */
@@ -201,6 +201,16 @@ static void do_get_hw_residencies(void *
         GET_CC3_RES(hw_res->cc3);
         GET_CC6_RES(hw_res->cc6);
         break;
+    /* Cannon Lake */
+    case 0x66:
+        GET_PC2_RES(hw_res->pc2);
+        GET_PC3_RES(hw_res->pc3);
+        GET_PC6_RES(hw_res->pc6);
+        GET_PC7_RES(hw_res->pc7);
+        GET_CC1_RES(hw_res->cc1);
+        GET_CC6_RES(hw_res->cc6);
+        GET_CC7_RES(hw_res->cc7);
+        break;
     /* Xeon Phi Knights Landing */
     case 0x57:
     /* Xeon Phi Knights Mill */



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 08:41:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 08:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJvPu-0001Rc-ET; Thu, 02 Apr 2020 08:41:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJvPt-0001RX-D5
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 08:41:37 +0000
X-Inumbo-ID: c2c57674-74bd-11ea-bb8b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c2c57674-74bd-11ea-bb8b-12813bfff9fa;
 Thu, 02 Apr 2020 08:41:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E7958AF38;
 Thu,  2 Apr 2020 08:41:33 +0000 (UTC)
Subject: Ping: [PATCH v4] x86: clear RDRAND CPUID bit on AMD family 15h/16h
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <69382ba7-b562-2c8c-1843-b17ce6c512f1@suse.com>
Message-ID: <545d771a-dc8b-3764-e8f4-8871b1a27770@suse.com>
Date: Thu, 2 Apr 2020 10:34:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <69382ba7-b562-2c8c-1843-b17ce6c512f1@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.03.2020 10:08, Jan Beulich wrote:
> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
> 
>     There have been reports of RDRAND issues after resuming from suspend on
>     some AMD family 15h and family 16h systems. This issue stems from a BIOS
>     not performing the proper steps during resume to ensure RDRAND continues
>     to function properly.
> 
>     Update the CPU initialization to clear the RDRAND CPUID bit for any family
>     15h and 16h processor that supports RDRAND. If it is known that the family
>     15h or family 16h system does not have an RDRAND resume issue or that the
>     system will not be placed in suspend, the "cpuid=rdrand" kernel parameter
>     can be used to stop the clearing of the RDRAND CPUID bit.
> 
>     Note, that clearing the RDRAND CPUID bit does not prevent a processor
>     that normally supports the RDRAND instruction from executing it. So any
>     code that determined the support based on family and model won't #UD.
> 
> Warn if no explicit choice was given on affected hardware.
> 
> Check RDRAND functions at boot as well as after S3 resume (the retry
> limit chosen is entirely arbitrary).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Still slightly RFC, and still in particular because of the change to
> parse_xen_cpuid(): Alternative approach suggestions are welcome. But now
> also because with many CPUs there may now be a lot of warnings in case
> of issues.

Ping?

> ---
> v4: Check always, including during boot. Slightly better sanity check,
>     inspired by Linux commit 7879fc4bdc7.
> v3: Add call to warning_add(). If force-enabled, check RDRAND still
>     functioning after S3 resume.
> v2: Re-base.
> 
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -488,6 +488,10 @@ The Speculation Control hardware feature
>  be ignored, e.g. `no-ibrsb`, at which point Xen won't use them itself, and
>  won't offer them to guests.
>  
> +`rdrand` can be used to override the default disabling of the feature on certain
> +AMD systems.  Its negative form can of course also be used to suppress use and
> +exposure of the feature.
> +
>  ### cpuid_mask_cpu
>  > `= fam_0f_rev_[cdefg] | fam_10_rev_[bc] | fam_11_rev_b`
>  
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -4,6 +4,7 @@
>  #include <xen/param.h>
>  #include <xen/smp.h>
>  #include <xen/pci.h>
> +#include <xen/warning.h>
>  #include <asm/io.h>
>  #include <asm/msr.h>
>  #include <asm/processor.h>
> @@ -646,6 +647,25 @@ static void init_amd(struct cpuinfo_x86
>  		if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value))
>  			amd_acpi_c1e_quirk = true;
>  		break;
> +
> +	case 0x15: case 0x16:
> +		/*
> +		 * There are too many Fam15/Fam16 systems where upon resume
> +		 * from S3 firmware fails to re-setup properly functioning
> +		 * RDRAND.  Clear the feature unless force-enabled on the
> +		 * command line.
> +		 */
> +		if (c == &boot_cpu_data &&
> +		    cpu_has(c, X86_FEATURE_RDRAND) &&
> +		    !is_forced_cpu_cap(X86_FEATURE_RDRAND)) {
> +			static const char __initconst text[] =
> +				"RDRAND may cease to work on this hardware upon resume from S3.\n"
> +				"Please choose an explicit cpuid={no-}rdrand setting.\n";
> +
> +			setup_clear_cpu_cap(X86_FEATURE_RDRAND);
> +			warning_add(text);
> +		}
> +		break;
>  	}
>  
>  	display_cacheinfo(c);
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -11,6 +11,7 @@
>  #include <asm/io.h>
>  #include <asm/mpspec.h>
>  #include <asm/apic.h>
> +#include <asm/random.h>
>  #include <asm/setup.h>
>  #include <mach_apic.h>
>  #include <public/sysctl.h> /* for XEN_INVALID_{SOCKET,CORE}_ID */
> @@ -98,6 +99,11 @@ void __init setup_force_cpu_cap(unsigned
>  	__set_bit(cap, boot_cpu_data.x86_capability);
>  }
>  
> +bool is_forced_cpu_cap(unsigned int cap)
> +{
> +	return test_bit(cap, forced_caps);
> +}
> +
>  static void default_init(struct cpuinfo_x86 * c)
>  {
>  	/* Not much we can do here... */
> @@ -498,6 +504,28 @@ void identify_cpu(struct cpuinfo_x86 *c)
>  	printk("\n");
>  #endif
>  
> +	/*
> +	 * If RDRAND is available, make an attempt to check that it actually
> +	 * (still) works.
> +	 */
> +	if (cpu_has(c, X86_FEATURE_RDRAND)) {
> +		unsigned int prev = 0;
> +
> +		for (i = 0; i < 5; ++i)
> +		{
> +			unsigned int cur = arch_get_random();
> +
> +			if (prev && cur != prev)
> +				break;
> +			prev = cur;
> +			cpu_relax();
> +		}
> +
> +		if (i >= 5)
> +			printk(XENLOG_WARNING "CPU%u: RDRAND appears to not work\n",
> +			       smp_processor_id());
> +	}
> +
>  	if (system_state == SYS_STATE_resume)
>  		return;
>  
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -71,6 +71,9 @@ static int __init parse_xen_cpuid(const
>              {
>                  if ( !val )
>                      setup_clear_cpu_cap(mid->bit);
> +                else if ( mid->bit == X86_FEATURE_RDRAND &&
> +                          (cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_RDRAND)) )
> +                    setup_force_cpu_cap(X86_FEATURE_RDRAND);
>                  mid = NULL;
>              }
>  
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -166,6 +166,7 @@ extern const struct x86_cpu_id *x86_matc
>  extern void identify_cpu(struct cpuinfo_x86 *);
>  extern void setup_clear_cpu_cap(unsigned int);
>  extern void setup_force_cpu_cap(unsigned int);
> +extern bool is_forced_cpu_cap(unsigned int);
>  extern void print_cpu_info(unsigned int cpu);
>  extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
>  


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 08:41:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 08:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJvPv-0001Rn-Mm; Thu, 02 Apr 2020 08:41:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJvPu-0001Rg-Jk
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 08:41:38 +0000
X-Inumbo-ID: c425b0ce-74bd-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c425b0ce-74bd-11ea-83d8-bc764e2007e4;
 Thu, 02 Apr 2020 08:41:38 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C514BAFF5;
 Thu,  2 Apr 2020 08:41:36 +0000 (UTC)
Subject: Re: [PATCH v2] x86emul: suppress "not built" warning for test harness
 for run targets
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <4c5af3e1-836f-4104-99a8-79755c8034e1@suse.com>
Message-ID: <3a0f9394-f7d1-94f0-4a81-6240f01348b8@suse.com>
Date: Thu, 2 Apr 2020 10:40:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <4c5af3e1-836f-4104-99a8-79755c8034e1@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.03.2020 17:11, Jan Beulich wrote:
> The run* targets can be used to test whatever the tool chain is capable
> of building, as long as at least the main harness source file builds.
> Don't probe the tools chain, in particular to avoid issuing the warning,
> in this case. While looking into this I also noticed the wording of the
> respective comment isn't quite right, which therefore gets altered at
> the same time.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I guess this is simple enough a change that I'll commit it early
next week, unless I hear otherwise till then.

Jan

> ---
> v2: Also suppress the compiler/assembler probing in this case.
> 
> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -97,11 +97,13 @@ avx512dq-opmask-vecs := 1 2
>  avx512bw-opmask-vecs := 4 8
>  
>  # Suppress building by default of the harness if the compiler can't deal
> -# with any of the extensions used.  Don't alter the "run" target dependencies
> +# with some of the extensions used.  Don't alter the "run" target dependencies
>  # though, as this target needs to be specified manually, and things may work
>  # partially even with older compilers.
>  TARGET-y := $(TARGET)
>  
> +ifeq ($(filter run%,$(MAKECMDGOALS)),)
> +
>  define simd-check-cc
>  TARGET-$(shell echo 'int i;' | $(CC) -x c -c -o /dev/null -m$(1) - || echo y) :=
>  endef
> @@ -116,6 +118,8 @@ ifeq ($(TARGET-y),)
>  $(warning Test harness not built, use newer compiler than "$(CC)" (version $(shell $(CC) -dumpversion)) and an "{evex}" capable assembler)
>  endif
>  
> +endif
> +
>  all: $(TARGET-y)
>  
>  # For AVX and later, have the compiler avoid XMM0 to widen coverage of


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 09:43:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 09:43:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJwNf-0006Pj-2W; Thu, 02 Apr 2020 09:43:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJwNd-0006Pe-UW
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 09:43:21 +0000
X-Inumbo-ID: 6316493e-74c6-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6316493e-74c6-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 09:43:20 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 58B99AB8F;
 Thu,  2 Apr 2020 09:43:19 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86emul: inherit HOSTCC when building 32-bit harness on
 64-bit host
Message-ID: <842a0920-60ed-cf51-7f6c-37af40173160@suse.com>
Date: Thu, 2 Apr 2020 11:43:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We're deliberately bringing XEN_COMPILE_ARCH and XEN_TARGET_ARCH out of
sync in this case, and hence HOSTCC won't get set from CC. Therefore
without this addition HOSTCC would not match a possible make command
line override of CC, but default to "gcc", likely causing the build to
fail for test_x86_emulator.c on systems with too old a gcc.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -268,7 +268,7 @@ install uninstall:
 ifeq ($(XEN_COMPILE_ARCH),x86_64)
 run32: $(addsuffix .h,$(TESTCASES)) $(addsuffix -opmask.h,$(OPMASK))
 run32 clean32: %32:
-	$(MAKE) -C 32 $*
+	$(MAKE) -C 32 HOSTCC=$(HOSTCC) $*
 clean: clean32
 else
 run32 clean32: %32: %


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 09:49:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 09:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJwTz-0006cx-SG; Thu, 02 Apr 2020 09:49:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=/k1p=5S=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jJwTy-0006cs-TQ
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 09:49:54 +0000
X-Inumbo-ID: 4d682c64-74c7-11ea-9e09-bc764e2007e4
Received: from mail-ed1-x532.google.com (unknown [2a00:1450:4864:20::532])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4d682c64-74c7-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 09:49:53 +0000 (UTC)
Received: by mail-ed1-x532.google.com with SMTP id a43so3346499edf.6
 for <xen-devel@lists.xenproject.org>; Thu, 02 Apr 2020 02:49:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=8BXW3HQ9jIN1PK8/Ynmi2J5s9ajXZ+eaVpPcKxTAcNk=;
 b=nBZH0rn0E81F+R2nez36gvWmYGOU2otGb3GoyXWSHIiUIaFomyPmCPd7IIMzZOfpHZ
 lgZaO63OsuspTtdBhmUMgtUZgdDvAYpNTIYlOp8+WR8dz6UTljWpIqNkM/5CJNbP5SXR
 DEUTwy4kcc00Alfysne0FyLXDreE8pQZ+UCRC0OWv6XwBmeb/ypzoVyrqbQApuDtuDYT
 oHWFNrsUBDciPvrAn1/Mq46L0QTsWISeau508A9XP8g1RX0BFqqxiyOrml6iMYkWCxzf
 /2ubLC4SWwprYT+UJE0c0PrGiM3trIwA3+DkSS1u3uPHQz2v94+uysInvjXaZqX49Flc
 6X6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :thread-index:content-language;
 bh=8BXW3HQ9jIN1PK8/Ynmi2J5s9ajXZ+eaVpPcKxTAcNk=;
 b=bakTd4lYKPlXa1oQYgBiGgPWCayr/smgjP7C9vhtQ3Q14Y9dz24IsJ13arkl3T+rxF
 srf4BS8hJpA9zI2ZUF47reXMFRLS/hcNI6UXNtY+U7VwJ5ZHNDKmu+1+nMRK4btEiriQ
 TQE6k8wwgDXBTCBPyJy5QJ6u3b28moi3eed/qhimPmPU85d0AsdQns7hLY9XVDFyNI8U
 5iOLp+lrMb5HPpqqaQNlgyb6zP3UWoqOyfSqOzUEcKDwQpmzAPq98WUTFaMjAbkOicX4
 NCOZDLm7hekgZoEZSW5eA3op6MRhvo+4Eubc9VwTYZjDrH4gfDoNNzwvovJc4jseSbsU
 ugAg==
X-Gm-Message-State: AGi0PubsubDEDCgyPZJEjT0zqN5vaHKNOiK0L7UDnIKoQpstPsObWkEx
 tMIqlMpev1/vcX6Hvb3Uz3k=
X-Google-Smtp-Source: APiQypJOhfeBLGylZMLkCkD7FprWLkParhrlxdKSMnXiT455KLlyVMHvvgdKy8q5UQl8VbbnorBYig==
X-Received: by 2002:aa7:c413:: with SMTP id j19mr2074824edq.100.1585820993093; 
 Thu, 02 Apr 2020 02:49:53 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id d20sm851821edn.12.2020.04.02.02.49.51
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 02 Apr 2020 02:49:52 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: =?utf-8?Q?'Philippe_Mathieu-Daud=C3=A9'?= <philmd@redhat.com>,
 "'Anthony PERARD'" <anthony.perard@citrix.com>, <qemu-devel@nongnu.org>
References: <20190114135154.16826-1-anthony.perard@citrix.com>
 <20190114135154.16826-7-anthony.perard@citrix.com>
 <772fab5a-59ab-050f-9fef-f3b050cfc5cd@redhat.com>
In-Reply-To: <772fab5a-59ab-050f-9fef-f3b050cfc5cd@redhat.com>
Subject: RE: [Qemu-devel] [PULL 06/25] xen: create xenstore areas for
 XenDevice-s
Date: Thu, 2 Apr 2020 10:49:50 +0100
Message-ID: <001001d608d4$0e7b9f40$2b72ddc0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLkG+zb+BC6iV9CP7Z29unUmtxq1wLn4V7uAn6DrKimHjyY8A==
Content-Language: en-gb
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: xen-devel@lists.xenproject.org, 'Markus Armbruster' <armbru@redhat.com>,
 'Peter Maydell' <peter.maydell@linaro.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Philippe Mathieu-Daud=C3=A9 <philmd@redhat.com>
> Sent: 01 April 2020 17:14
> To: Anthony PERARD <anthony.perard@citrix.com>; qemu-devel@nongnu.org
> Cc: xen-devel@lists.xenproject.org; Peter Maydell =
<peter.maydell@linaro.org>; Paul Durrant
> <paul@xen.org>; Markus Armbruster <armbru@redhat.com>
> Subject: Re: [Qemu-devel] [PULL 06/25] xen: create xenstore areas for =
XenDevice-s
>=20
> Hi Anthony, Paul.
>=20
> Cc'ing Markus too.
>=20
> On 1/14/19 2:51 PM, Anthony PERARD wrote:
> > From: Paul Durrant <paul.durrant@citrix.com>
> >
> > This patch adds a new source module, xen-bus-helper.c, which builds =
on
> > basic libxenstore primitives to provide functions to create (setting
> > permissions appropriately) and destroy xenstore areas, and functions =
to
> > 'printf' and 'scanf' nodes therein. The main xen-bus code then uses
> > these primitives [1] to initialize and destroy the frontend and =
backend
> > areas for a XenDevice during realize and unrealize respectively.
> >
> > The 'xen-block' implementation is extended with a 'get_name' method =
that
> > returns the VBD number. This number is required to 'name' the =
xenstore
> > areas.
> >
> > NOTE: An exit handler is also added to make sure the xenstore areas =
are
> >        cleaned up if QEMU terminates without devices being =
unrealized.
> >
> > [1] The 'scanf' functions are actually not yet needed, but they will =
be
> >      needed by code delivered in subsequent patches.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Reviewed-by: Anthony Perard <anthony.perard@citrix.com>
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> >   hw/block/xen-block.c            |   9 +
> >   hw/xen/Makefile.objs            |   2 +-
> >   hw/xen/trace-events             |  12 +-
> >   hw/xen/xen-bus-helper.c         | 150 +++++++++++++++
> >   hw/xen/xen-bus.c                | 321 =
+++++++++++++++++++++++++++++++-
> >   include/hw/xen/xen-bus-helper.h |  39 ++++
> >   include/hw/xen/xen-bus.h        |  12 ++
> >   7 files changed, 540 insertions(+), 5 deletions(-)
> >   create mode 100644 hw/xen/xen-bus-helper.c
> >   create mode 100644 include/hw/xen/xen-bus-helper.h
> >
> [...]
> > +static void xen_device_exit(Notifier *n, void *data)
> > +{
> > +    XenDevice *xendev =3D container_of(n, XenDevice, exit);
> > +
> > +    xen_device_unrealize(DEVICE(xendev), &error_abort);
> >   }
> >
> >   static void xen_device_realize(DeviceState *dev, Error **errp)
> >   {
> >       XenDevice *xendev =3D XEN_DEVICE(dev);
> >       XenDeviceClass *xendev_class =3D XEN_DEVICE_GET_CLASS(xendev);
> > +    XenBus *xenbus =3D =
XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
> >       const char *type =3D object_get_typename(OBJECT(xendev));
> >       Error *local_err =3D NULL;
> >
> > -    trace_xen_device_realize(type);
> > +    if (xendev->frontend_id =3D=3D DOMID_INVALID) {
> > +        xendev->frontend_id =3D xen_domid;
> > +    }
> > +
> > +    if (xendev->frontend_id >=3D DOMID_FIRST_RESERVED) {
> > +        error_setg(errp, "invalid frontend-id");
> > +        goto unrealize;
> > +    }
> > +
> > +    if (!xendev_class->get_name) {
> > +        error_setg(errp, "get_name method not implemented");
> > +        goto unrealize;
> > +    }
> > +
> > +    xendev->name =3D xendev_class->get_name(xendev, &local_err);
> > +    if (local_err) {
> > +        error_propagate_prepend(errp, local_err,
> > +                                "failed to get device name: ");
> > +        goto unrealize;
> > +    }
> > +
> > +    trace_xen_device_realize(type, xendev->name);
> > +
> > +    xen_device_backend_create(xendev, &local_err);
> > +    if (local_err) {
> > +        error_propagate(errp, local_err);
> > +        goto unrealize;
> > +    }
> > +
> > +    xen_device_frontend_create(xendev, &local_err);
> > +    if (local_err) {
> > +        error_propagate(errp, local_err);
> > +        goto unrealize;
> > +    }
> >
> >       if (xendev_class->realize) {
> >           xendev_class->realize(xendev, &local_err);
> > @@ -72,18 +364,43 @@ static void xen_device_realize(DeviceState =
*dev, Error **errp)
> >           }
> >       }
> >
> > +    xen_device_backend_printf(xendev, "frontend", "%s",
> > +                              xendev->frontend_path);
> > +    xen_device_backend_printf(xendev, "frontend-id", "%u",
> > +                              xendev->frontend_id);
> > +    xen_device_backend_printf(xendev, "online", "%u", 1);
> > +    xen_device_backend_printf(xendev, "hotplug-status", =
"connected");
> > +
> > +    xen_device_backend_set_state(xendev, XenbusStateInitWait);
> > +
> > +    xen_device_frontend_printf(xendev, "backend", "%s",
> > +                               xendev->backend_path);
> > +    xen_device_frontend_printf(xendev, "backend-id", "%u",
> > +                               xenbus->backend_id);
> > +
> > +    xen_device_frontend_set_state(xendev, XenbusStateInitialising);
> > +
> > +    xendev->exit.notify =3D xen_device_exit;
> > +    qemu_add_exit_notifier(&xendev->exit);
> >       return;
> >
> >   unrealize:
> >       xen_device_unrealize(dev, &error_abort);
>=20
> It seems if unrealize() fails, the error stored in &local_err is never
> reported. Not sure if this can be improved although.

In this case that's essentially a "don't care". We want to know why the =
realize failed but if the unrealize fails something is probably pretty =
seriously screwed (hence the error_abort).

  Paul



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 09:59:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 09:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJwcj-0007Vq-Un; Thu, 02 Apr 2020 09:58:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=/k1p=5S=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jJwci-0007VJ-1r
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 09:58:56 +0000
X-Inumbo-ID: 9017be02-74c8-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x534.google.com (unknown [2a00:1450:4864:20::534])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9017be02-74c8-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 09:58:55 +0000 (UTC)
Received: by mail-ed1-x534.google.com with SMTP id z65so3420439ede.0
 for <xen-devel@lists.xenproject.org>; Thu, 02 Apr 2020 02:58:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=VUatLEQ93jKESu4XWv1B7dhdA5WTNqPmPRwmAUZfuSQ=;
 b=Flj4hKjoA1YpX/CCcxHmJnYmzfU6cpvGKPGaU2/ank6H2AYcSf+R/QyzbgvNg/oEoa
 K1B+INfjxMX/ucSMoEvLlMCV31V4/sIkNWUhzI63kasbUFAnTGwtZn1zaaBvt/ZFeIIp
 +JPvaRm7UjfMtWouhy0PXiwVWpbNGmmEoBitRPOjHmassRw7exJh2T6cyzu5JbP+2ZlP
 I37A02V9MULlT/l2hK2c9w3g87of4h42wXyczyiFRxdbDlwesWJWxFuaFvuYfygBORkb
 GRp6erGOctSPCnE8eSOJzfRnQbM86Kh6p24ZTgOMCbAIFf0rvVfFiZWvvgWS2Yl1Gr5y
 ZQgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :thread-index:content-language;
 bh=VUatLEQ93jKESu4XWv1B7dhdA5WTNqPmPRwmAUZfuSQ=;
 b=AwwhmZW1cNQ5E7/vSaKUgMD8gqPT0iHxqZr+RHcX5mY/yxrg0yQftG6lJyqDrtUcs7
 IxzVNVoaJVSovJcThR01w43dP1msY+hKChyEXUlfykS3ItWkShDwL1qjafSGC/Yl6Jc9
 DD54msl18k+mRsAh2H5DN7bs1b+F3NuLrdb1nq16lSPYNko21wLr6YA6E51aoqENz1ww
 dkRTT28QPu1f//Uj5YfZId5G8gVjdeF1pgqiRqhKoH66ALlGuXVCL5XmGKdzPEsbhRMC
 a2XkJ/DydQgMZWg2djg3IpP+k4ePqmdMXQMrihLWMMI/xmlCb4Gn70i2Rg1NbHdzcyqh
 XeWg==
X-Gm-Message-State: AGi0PuYaULk723/bF6GOQC4sHUJoMZubN0qb6DnXeMPLll6Eg69K2iKk
 HSPhhyE6m7TJxlF4GQvIL1k=
X-Google-Smtp-Source: APiQypIzosd/kQwuzr0HEHWATfvqNBv2cUzOGeTUAmfURovxHkcaSQb/X6JR99YNcozN+sd6soGZ2Q==
X-Received: by 2002:a17:906:f187:: with SMTP id
 gs7mr2476359ejb.138.1585821534398; 
 Thu, 02 Apr 2020 02:58:54 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id 31sm846881edc.26.2020.04.02.02.58.52
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 02 Apr 2020 02:58:53 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <e9b21d59-3a4a-1498-e5f4-45d1420ddbc4@suse.com>
In-Reply-To: <e9b21d59-3a4a-1498-e5f4-45d1420ddbc4@suse.com>
Subject: RE: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
Date: Thu, 2 Apr 2020 10:58:52 +0100
Message-ID: <001201d608d5$513a7490$f3af5db0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG3I8TZM/MLMEc/e2It3WEXPZVs8AC9qttvAjHRb6Soi+Tb8A==
Content-Language: en-gb
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 01 April 2020 15:51
> To: Paul Durrant <paul@xen.org>
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper =
<andrew.cooper3@citrix.com>; George Dunlap
> <george.dunlap@citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; =
Julien Grall <julien@xen.org>;
> Stefano Stabellini <sstabellini@kernel.org>; Wei Liu <wl@xen.org>
> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for =
save/restore of 'domain' context
>=20
> On 27.03.2020 19:50, Paul Durrant wrote:
> > Domain context is state held in the hypervisor that does not come =
under
> > the category of 'HVM state' but is instead 'PV state' that is common
> > between PV guests and enlightened HVM guests (i.e. those that have =
PV
> > drivers) such as event channel state, grant entry state, etc.
>=20
> Without looking at the patch details yet, I'm having some difficulty
> understanding how this is going to work in a safe/correct manner. I
> suppose for LU the system is in a frozen enough state that
> snapshotting and copying state like this is okay, but ...
>=20
> > To allow enlightened HVM guests to be migrated without their =
co-operation
> > it will be necessary to transfer such state along with the domain's
> > memory image, architectural state, etc. This framework is introduced =
for
> > that purpose.
> >
> > This patch adds the new public header and the low level =
implementation,
> > entered via the domain_save() or domain_load() functions. Subsequent
> > patches will introduce other parts of the framwork, and code that =
will
> > make use of it within the current version of the libxc migration =
stream.
>=20
> ... here you suggest (and patch 5 appears to match this) that this
> is going to be used even in "normal" migration streams.

Well, 'transparent' (or non-cooperative) migration will only work in =
some cases but it definitely does work.

> All of the
> items named are communication vehicles, and hence there are always
> two sides that can influence the state. For event channels, the
> other side (which isn't paused) or the hardware (for passed through
> devices) might signal them, or it (just the former obviously) could
> close their end, resulting in a state change also for the domain
> being migrated. If this happens after the snapshot was taken, the
> state change is lost.

Indeed, which is why we *do* rely on co-operation from the other end of =
the event channels in the migration case. In the initial case it is =
likely we'll veto transparent migration unless all event channels are =
connected to either dom0 or Xen.

>=20
> Otoh I'm sure the case was considered, so perhaps I'm simply missing
> some crucial aspect (which then could do with spelling out in the
> description of the cover letter).
>=20

Does that need to be explained for a series that is just infrastructure? =
The overall design doc is now committed in the repo (although may need =
some expansion in future) so I could point at that.
I don't think I'm giving anything away when I say that EC2's downstream =
code simply (ab)uses HVM save records for transferring the extra state; =
all I'm trying to do here is create something cleaner onto which I can =
re-base and upstream the EC2 code.

  Paul




From xen-devel-bounces@lists.xenproject.org Thu Apr 02 10:19:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 10:19:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJwwL-0000nh-2h; Thu, 02 Apr 2020 10:19:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jJwwJ-0000nc-Ez
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 10:19:11 +0000
X-Inumbo-ID: 646c96db-74cb-11ea-bba1-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 646c96db-74cb-11ea-bba1-12813bfff9fa;
 Thu, 02 Apr 2020 10:19:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585822750;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=3/YZSxwxJdT+2zm3hr8RD7262jgsENAYDbS1h2PY7l0=;
 b=LTTM59bS/ZAVBJaqAjqKzT0aGstBFVXVbfOIjWgwgKrn/c3Q1ybNB6uM
 XnqxAcMiO+8mIPXWPktkg9muDqLwNjIivcpVXFneJFrvHVvOzFA5EQln5
 9opwhr2oaH4uAp40kefI76QGTgVmacB1OWUOqnCZqiU5zSA/ilHb8CuQT w=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Be+7e6xH7LJDnmNx+3cTRqTen6+RPZZZf2wUTt6utz+BsHDh1oMTxEO6hzSNZzZvVLthMmJ30t
 o8+r8BMDuz7Z0Bb3VaiRIhUDOEP6aas/DkNnSNq8xsM7lrPzk4motAvN15jFopO4JusUc6nq1w
 uFCZPy3/cj0IQYGWIG+KlGIAkB7eGV9Dmx+MAzRLLhYRkxB487aSTF73fsMFqgx+6uO2RFSODE
 kXwBrDfw+v3sHnC9JQs6J/vwrrd6bLfjnJiytxEQFfcuGt+kun65X8FBoiJjHjX7GCt8lAD9pk
 gdM=
X-SBRS: 2.7
X-MesageID: 15715926
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15715926"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 1/5] x86/ucode/intel: Remove CPUID from collect_cpu_info()
Date: Thu, 2 Apr 2020 11:18:58 +0100
Message-ID: <20200402101902.28234-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200402101902.28234-1-andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The CPUID instruction is expensive.  No point executing it twice when once
will do fine.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/microcode/intel.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c
index 72bd1ad0bc..f1e64e188b 100644
--- a/xen/arch/x86/cpu/microcode/intel.c
+++ b/xen/arch/x86/cpu/microcode/intel.c
@@ -121,14 +121,12 @@ static int collect_cpu_info(struct cpu_signature *csig)
 
     memset(csig, 0, sizeof(*csig));
 
-    csig->sig = cpuid_eax(0x00000001);
-
     rdmsrl(MSR_IA32_PLATFORM_ID, msr_content);
     csig->pf = 1 << ((msr_content >> 50) & 7);
 
     wrmsrl(MSR_IA32_UCODE_REV, 0x0ULL);
     /* As documented in the SDM: Do a CPUID 1 here */
-    cpuid_eax(1);
+    csig->sig = cpuid_eax(1);
 
     /* get the current revision from MSR 0x8B */
     rdmsrl(MSR_IA32_UCODE_REV, msr_content);
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 10:19:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 10:19:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJwwI-0000nW-QW; Thu, 02 Apr 2020 10:19:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jJwwI-0000nR-0e
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 10:19:10 +0000
X-Inumbo-ID: 639b82e8-74cb-11ea-b58d-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 639b82e8-74cb-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 10:19:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585822749;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=dc9Q1KqMtzHb/7Vp1JB2gXgnUkuZQ+2HrfBCTKTQXRg=;
 b=FJJe1Coc57XRZ+pzZFjfNVByTMqGcMZMc7N1ZbRVhX1d9Arb6oCnBcjY
 f0P1BL1M5oEHA8wmh21C9GS3x2o1DtmMpnnALj4dxxh7OBqIotDqmDugA
 xMb2cImbzQht6vpv92a/ZwDS+4FXAs3d0dnwMJLQej5c6Irjce6k3DZlR E=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: kyipUPC2HfB9xduEOYQJsloT3kkZkzLzewYpWmolnTaVrXX2fmbJYmB2XOPbJJjQpHsl23O7oj
 6FXgtkAAE6tZkbhkNmtT5eEGAnXMcLWVJYQGRuW40PrPpMfTLp3maP2xXled3f5X2ViLrJ+GyP
 IxgiuDV9Vzm2g+wKBg10a00y12AGZLgs4MGxlkbaIZOrj6IFlO+BOz7PbR/cAaEcKrAyWrv6Rz
 Wrq8a6KrdjN/S0n0zbh9Bm2ckT++PV6kZWWys3XFfDqD2p/fSuvxX4mhSnLqg3sSV46uKiyNTh
 5Ks=
X-SBRS: 2.7
X-MesageID: 15277742
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15277742"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 0/5] x86/ucode: Cleanup part 5/n
Date: Thu, 2 Apr 2020 11:18:57 +0100
Message-ID: <20200402101902.28234-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Some fairly minor changes while I wait for more answers from vendors.  I'm
annoyed that I didn't spot patch 2 earlier, because it would have simplied
some of the previous cleanup work.  Oh well...

Andrew Cooper (5):
  x86/ucode/intel: Remove CPUID from collect_cpu_info()
  x86/ucode: Drop ops->match_cpu()
  x86/ucode: Don't try to cope with NULL pointers in apply_microcode()
  x86/ucode: Drop ops->free_patch()
  x86/ucode: Simplify the ops->collect_cpu_info() API

 xen/arch/x86/cpu/microcode/amd.c     | 24 ++++--------------------
 xen/arch/x86/cpu/microcode/core.c    | 18 ++++++++----------
 xen/arch/x86/cpu/microcode/intel.c   | 29 ++++-------------------------
 xen/arch/x86/cpu/microcode/private.h | 18 ++++++------------
 4 files changed, 22 insertions(+), 67 deletions(-)

-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 10:19:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 10:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJwwQ-0000oi-Bc; Thu, 02 Apr 2020 10:19:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jJwwO-0000o3-DI
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 10:19:16 +0000
X-Inumbo-ID: 646c96dd-74cb-11ea-bba1-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 646c96dd-74cb-11ea-bba1-12813bfff9fa;
 Thu, 02 Apr 2020 10:19:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585822751;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=Vam1QDmFn+vR0pBcHWu9YCMoeDedFnU5geNICv7MFCk=;
 b=fkiDtj+pCszF+ZpbwEYQkTSxTRBAyJo7vaGQQMLMKsabyvbIixL0ZuQ/
 b7kSnYKODe5u7VZAkttV6CvMZUuPHT2OJD4sapK/godl6DAepHLXy20HP
 NTe8z2oy45ox9k50jmU/+LomTxGJ6XPh01VC+PPnS8ftYPqRfzI5Mftro 0=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 4PMnMFrvIGSYNQy/QsMzNhJ081TJtVr/ARxMVeRoI0wOaQknR8RRqnlfb3WSkXLIdVpDjPu6t9
 M7a+d4Gf6UmXaCrSD1IcUV1qnIGANOsdxTHIjng8bhcDpJfw2ulRhg55bAUyL1Hvt1Vc7lFlIg
 0IxciUbZV9fqx2LVBSKvjzfDAypY92Hqd1fFV54Hb7efOo1TQ/aDGKHQvPuQCXS1m2P+XFL7Oy
 vaLhBYI9jKAkEZTrJ9QI5tsIhlILE3gDcFpDELyc19QwrZIjBb8vpgeXY+eJQ3OK698HGe8R70
 eNI=
X-SBRS: 2.7
X-MesageID: 15380674
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15380674"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 2/5] x86/ucode: Drop ops->match_cpu()
Date: Thu, 2 Apr 2020 11:18:59 +0100
Message-ID: <20200402101902.28234-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200402101902.28234-1-andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It turns out there are no callers of the hook().  The only callers are the
local, which can easily be rearranged to use the appropriate internal helper.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/microcode/amd.c     |  8 +-------
 xen/arch/x86/cpu/microcode/intel.c   | 11 +----------
 xen/arch/x86/cpu/microcode/private.h |  6 ------
 3 files changed, 2 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index d4763ea776..c9656de55d 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -188,11 +188,6 @@ static enum microcode_match_result microcode_fits(
     return NEW_UCODE;
 }
 
-static bool match_cpu(const struct microcode_patch *patch)
-{
-    return patch && (microcode_fits(patch) == NEW_UCODE);
-}
-
 static void free_patch(struct microcode_patch *patch)
 {
     xfree(patch);
@@ -227,7 +222,7 @@ static int apply_microcode(const struct microcode_patch *patch)
     if ( !patch )
         return -ENOENT;
 
-    if ( !match_cpu(patch) )
+    if ( microcode_fits(patch) != NEW_UCODE )
         return -EINVAL;
 
     if ( check_final_patch_levels(sig) )
@@ -428,5 +423,4 @@ const struct microcode_ops amd_ucode_ops = {
 #endif
     .free_patch                       = free_patch,
     .compare_patch                    = compare_patch,
-    .match_cpu                        = match_cpu,
 };
diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c
index f1e64e188b..315fca9ff2 100644
--- a/xen/arch/x86/cpu/microcode/intel.c
+++ b/xen/arch/x86/cpu/microcode/intel.c
@@ -245,14 +245,6 @@ static enum microcode_match_result microcode_update_match(
     return mc->rev > cpu_sig->rev ? NEW_UCODE : OLD_UCODE;
 }
 
-static bool match_cpu(const struct microcode_patch *patch)
-{
-    if ( !patch )
-        return false;
-
-    return microcode_update_match(patch) == NEW_UCODE;
-}
-
 static void free_patch(struct microcode_patch *patch)
 {
     xfree(patch);
@@ -281,7 +273,7 @@ static int apply_microcode(const struct microcode_patch *patch)
     if ( !patch )
         return -ENOENT;
 
-    if ( !match_cpu(patch) )
+    if ( microcode_update_match(patch) != NEW_UCODE )
         return -EINVAL;
 
     /* write microcode via MSR 0x79 */
@@ -369,5 +361,4 @@ const struct microcode_ops intel_ucode_ops = {
     .apply_microcode                  = apply_microcode,
     .free_patch                       = free_patch,
     .compare_patch                    = compare_patch,
-    .match_cpu                        = match_cpu,
 };
diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h
index df0d0852cd..d31bcf14b1 100644
--- a/xen/arch/x86/cpu/microcode/private.h
+++ b/xen/arch/x86/cpu/microcode/private.h
@@ -60,12 +60,6 @@ struct microcode_ops {
     void (*free_patch)(struct microcode_patch *patch);
 
     /*
-     * Is the microcode patch applicable for the current CPU, and newer than
-     * the currently running patch?
-     */
-    bool (*match_cpu)(const struct microcode_patch *patch);
-
-    /*
      * Given two patches, are they both applicable to the current CPU, and is
      * new a higher revision than old?
      */
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 10:19:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 10:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJwwU-0000px-LU; Thu, 02 Apr 2020 10:19:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jJwwS-0000pc-Vn
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 10:19:21 +0000
X-Inumbo-ID: 6a0cec34-74cb-11ea-9e09-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6a0cec34-74cb-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 10:19:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585822761;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=eZcKbBNzadTU2s5TsuGgFszMTPPeWk2mohwFyrTvSJM=;
 b=GtZaplkanE0grmFBn+4xj8xzuYu9ogeyuiEQWTzOhGumB+EDeG6D4MZp
 N4466XoCzuIgTroJUQmZOAwgLjJKJKKu0DHiHBroRS1TfaL7TiMHvpofk
 SU+jlufOls2JYcExQZ6p1AcqYL+2NkBZijbBqkBfO3d70IViOXf3fl02y 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: mQ5ta3syU40qCuRiz25H7IFZHcb5LaPTsLyu+OecTg5uFvaosagAGd3/k9ggn2tYW8SZcAqiXm
 gzXSFg7f4/7NABosLqKGIVLBZbOxWWN4kuScVVVKwFszZymiE4btkFSZ+MOj3rcGYibhLI7PBm
 mvEeuEAF9ilrFMhh1zvmUOxFNA5E028/P7aAuyoU2NM10l03UfNbgtvqtgvERVFaxBUklPMzZe
 pYDhgJgdIiqEBnG0RHgmGFtGZu4EYTHQaNCcXTcxIPEySsuDichfhSfmnrTFWbGnLkU5qdWftF
 TiE=
X-SBRS: 2.7
X-MesageID: 15041306
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15041306"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 5/5] x86/ucode: Simplify the ops->collect_cpu_info() API
Date: Thu, 2 Apr 2020 11:19:02 +0100
Message-ID: <20200402101902.28234-6-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200402101902.28234-1-andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

All callers pass &this_cpu(cpu_sig) for the cpu_sig parameter, and all
implementations unconditionally return 0.  Simplify it to be void.

Drop the long-stale comment on the AMD side, whose counterpart in
start_update() used to be "collect_cpu_info() doesn't fail so we're fine".

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/microcode/amd.c     |  7 +++----
 xen/arch/x86/cpu/microcode/core.c    | 14 ++++++--------
 xen/arch/x86/cpu/microcode/intel.c   |  5 ++---
 xen/arch/x86/cpu/microcode/private.h |  7 +++++--
 4 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index e23bdef6f2..13bf9f4dee 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -90,9 +90,10 @@ static struct {
     uint16_t id;
 } equiv __read_mostly;
 
-/* See comment in start_update() for cases when this routine fails */
-static int collect_cpu_info(struct cpu_signature *csig)
+static void collect_cpu_info(void)
 {
+    struct cpu_signature *csig = &this_cpu(cpu_sig);
+
     memset(csig, 0, sizeof(*csig));
 
     csig->sig = cpuid_eax(1);
@@ -100,8 +101,6 @@ static int collect_cpu_info(struct cpu_signature *csig)
 
     pr_debug("microcode: CPU%d collect_cpu_info: patch_id=%#x\n",
              smp_processor_id(), csig->rev);
-
-    return 0;
 }
 
 static bool_t verify_patch_size(uint32_t patch_size)
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 53e447ea9a..a220f908b8 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -237,10 +237,9 @@ static const struct microcode_patch *nmi_patch = ZERO_BLOCK_PTR;
  */
 static struct microcode_patch *parse_blob(const char *buf, size_t len)
 {
-    if ( likely(!microcode_ops->collect_cpu_info(&this_cpu(cpu_sig))) )
-        return microcode_ops->cpu_request_microcode(buf, len);
+    microcode_ops->collect_cpu_info();
 
-    return NULL;
+    return microcode_ops->cpu_request_microcode(buf, len);
 }
 
 static void microcode_free_patch(struct microcode_patch *patch)
@@ -306,10 +305,9 @@ static bool wait_cpu_callout(unsigned int nr)
  */
 static int microcode_update_cpu(const struct microcode_patch *patch)
 {
-    int err = microcode_ops->collect_cpu_info(&this_cpu(cpu_sig));
+    int err;
 
-    if ( unlikely(err) )
-        return err;
+    microcode_ops->collect_cpu_info();
 
     spin_lock(&microcode_mutex);
     if ( patch )
@@ -737,7 +735,7 @@ int microcode_update_one(bool start_update)
     if ( !microcode_ops )
         return -EOPNOTSUPP;
 
-    microcode_ops->collect_cpu_info(&this_cpu(cpu_sig));
+    microcode_ops->collect_cpu_info();
 
     if ( start_update && microcode_ops->start_update )
     {
@@ -819,7 +817,7 @@ int __init early_microcode_init(void)
         return -ENODEV;
     }
 
-    microcode_ops->collect_cpu_info(&this_cpu(cpu_sig));
+    microcode_ops->collect_cpu_info();
 
     if ( ucode_mod.mod_end || ucode_blob.size )
         rc = early_microcode_update_cpu();
diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c
index 29745ed55f..a9f4d6e829 100644
--- a/xen/arch/x86/cpu/microcode/intel.c
+++ b/xen/arch/x86/cpu/microcode/intel.c
@@ -115,8 +115,9 @@ static bool signature_matches(const struct cpu_signature *cpu_sig,
     return cpu_sig->pf & ucode_pf;
 }
 
-static int collect_cpu_info(struct cpu_signature *csig)
+static void collect_cpu_info(void)
 {
+    struct cpu_signature *csig = &this_cpu(cpu_sig);
     uint64_t msr_content;
 
     memset(csig, 0, sizeof(*csig));
@@ -133,8 +134,6 @@ static int collect_cpu_info(struct cpu_signature *csig)
     csig->rev = (uint32_t)(msr_content >> 32);
     pr_debug("microcode: collect_cpu_info : sig=%#x, pf=%#x, rev=%#x\n",
              csig->sig, csig->pf, csig->rev);
-
-    return 0;
 }
 
 /*
diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h
index 878f8d805f..dc5c7a81ae 100644
--- a/xen/arch/x86/cpu/microcode/private.h
+++ b/xen/arch/x86/cpu/microcode/private.h
@@ -33,8 +33,11 @@ struct microcode_ops {
     struct microcode_patch *(*cpu_request_microcode)(const void *buf,
                                                      size_t size);
 
-    /* Obtain microcode-relevant details for the current CPU. */
-    int (*collect_cpu_info)(struct cpu_signature *csig);
+    /*
+     * Obtain microcode-relevant details for the current CPU.  Results in
+     * per_cpu(cpu_sig).
+     */
+    void (*collect_cpu_info)(void);
 
     /*
      * Attempt to load the provided patch into the CPU.  Returns an error if
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 10:19:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 10:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJwwU-0000qG-Um; Thu, 02 Apr 2020 10:19:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jJwwT-0000pm-DZ
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 10:19:21 +0000
X-Inumbo-ID: 65c20cf4-74cb-11ea-bba1-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 65c20cf4-74cb-11ea-bba1-12813bfff9fa;
 Thu, 02 Apr 2020 10:19:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585822752;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=6rwZacdltItl9czt/IkZJAdDx3fDf89O2zoFUkCWxII=;
 b=DKuLQ31n4nvhglfk0XMdRtCLNKk0YguB2HElxGt3ggmJQeF9Odffh3v5
 livHxNq7MkopCdbCaJMatxuD1iuM2OZTBkwUf8ifymEH5X7CNlEABylLu
 rowdankaB/H0GK/wqRsSeqoD0o5RNsiphDbjILXdBO/mb0xx0RtvvVFWC c=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 70Hu1c/V3Xo4KeglIpiHkC8ugzcgbwS4wwpPLpvGWqiMgO3cCdF5MPFMqKNra51MkBgKQaGzDE
 GQTm51Y1vqiZbkBhn92eiZ7f4Iq2lcbOSQKJz7219QNpMUpDbyfe8w8EzSvEc4kn6YrEMGmfDv
 miWv7fcjcBSnPsyQ+Q+iJVB32l2aIr3JGmuEmuBR6dJ0cCFoTZawP905WCU/MXqHaWll0tMvPw
 zAG1ZnhSfQShb9Qzfe0sX6IY73GaDLWdPyyRjYaOg7ee4+GNzEjb3Wo/T0lp7F5Pcfi0a7LqRh
 YCw=
X-SBRS: 2.7
X-MesageID: 15380676
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15380676"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 3/5] x86/ucode: Don't try to cope with NULL pointers in
 apply_microcode()
Date: Thu, 2 Apr 2020 11:19:00 +0100
Message-ID: <20200402101902.28234-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200402101902.28234-1-andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

No paths to apply_microcode() pass a NULL pointer, and other hooks don't
tolerate one in the first place.  We can expect the core logic not to pass us
junk, so drop the checks.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/microcode/amd.c   | 3 ---
 xen/arch/x86/cpu/microcode/intel.c | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index c9656de55d..0ca0e9a038 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -219,9 +219,6 @@ static int apply_microcode(const struct microcode_patch *patch)
     struct cpu_signature *sig = &per_cpu(cpu_sig, cpu);
     uint32_t rev, old_rev = sig->rev;
 
-    if ( !patch )
-        return -ENOENT;
-
     if ( microcode_fits(patch) != NEW_UCODE )
         return -EINVAL;
 
diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c
index 315fca9ff2..9cb077b583 100644
--- a/xen/arch/x86/cpu/microcode/intel.c
+++ b/xen/arch/x86/cpu/microcode/intel.c
@@ -270,9 +270,6 @@ static int apply_microcode(const struct microcode_patch *patch)
     struct cpu_signature *sig = &this_cpu(cpu_sig);
     uint32_t rev, old_rev = sig->rev;
 
-    if ( !patch )
-        return -ENOENT;
-
     if ( microcode_update_match(patch) != NEW_UCODE )
         return -EINVAL;
 
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 10:19:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 10:19:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJwwZ-0000sd-DC; Thu, 02 Apr 2020 10:19:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jJwwY-0000sH-Dm
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 10:19:26 +0000
X-Inumbo-ID: 66a5fd6a-74cb-11ea-bba1-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 66a5fd6a-74cb-11ea-bba1-12813bfff9fa;
 Thu, 02 Apr 2020 10:19:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585822754;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=AD6n+KBMI4yDtXDNza0GnMzi5v0BBwM+iL+cgl/2+J8=;
 b=FPgqf9REoOlZW3iJfOwKvCf8O98HDotAbKo3JERkafijXPWJB58onOIq
 FN8MtG/5Mm+CzWpD740ZHRQTpWfnT7Fw7+jYTMZXWYUpHS2QK+2fGT30X
 hEQNYePvtDOeldDa/SeHTnZaiha/sKOtbYlY676D7HFMVHTGgv9hYZJWW c=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: LXGnhvtl0LbEKYegPnMWbxg6dYtw0N7TNPt4EZQAh/8iAKR2rFHd2I9HolsRhvtgw4fZiAlj8b
 G+RZmsKc+Ic7TlvjWBxq55+4YggPVrv/U2+XhlIXTELmyp3c5bXsT4wuAlD3OoiwK35PtK6ahy
 2d7ln0lRIwKlYKpicb7jhKCk7DfID8rC1SzfAk6H9wBp85JFAARrqFOFw7epqEXx6brU4Ie2YS
 6Q85Xy72RLcXbwOXjSm28V6rgf+L7F8UWQoJ+Ve7ZmO5NH1amoe3CRHUHfZLYPo+EmHyIP7cqh
 4vQ=
X-SBRS: 2.7
X-MesageID: 15068042
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15068042"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 4/5] x86/ucode: Drop ops->free_patch()
Date: Thu, 2 Apr 2020 11:19:01 +0100
Message-ID: <20200402101902.28234-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200402101902.28234-1-andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

With the newly cleaned up vendor logic, each struct microcode_patch is a
trivial object in memory with no dependent allocations.

This is unlikely to change moving forwards, and function pointers are
expensive in the days of retpoline.  Move the responsibility to xfree() back
to common code.  If the need does arise in the future, we can consider
reintroducing the hook.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/microcode/amd.c     | 6 ------
 xen/arch/x86/cpu/microcode/core.c    | 4 ++--
 xen/arch/x86/cpu/microcode/intel.c   | 6 ------
 xen/arch/x86/cpu/microcode/private.h | 5 +----
 4 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index 0ca0e9a038..e23bdef6f2 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -188,11 +188,6 @@ static enum microcode_match_result microcode_fits(
     return NEW_UCODE;
 }
 
-static void free_patch(struct microcode_patch *patch)
-{
-    xfree(patch);
-}
-
 static enum microcode_match_result compare_header(
     const struct microcode_patch *new, const struct microcode_patch *old)
 {
@@ -418,6 +413,5 @@ const struct microcode_ops amd_ucode_ops = {
     .start_update                     = start_update,
     .end_update_percpu                = svm_host_osvw_init,
 #endif
-    .free_patch                       = free_patch,
     .compare_patch                    = compare_patch,
 };
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index b3e5913d49..53e447ea9a 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -243,9 +243,9 @@ static struct microcode_patch *parse_blob(const char *buf, size_t len)
     return NULL;
 }
 
-static void microcode_free_patch(struct microcode_patch *microcode_patch)
+static void microcode_free_patch(struct microcode_patch *patch)
 {
-    microcode_ops->free_patch(microcode_patch);
+    xfree(patch);
 }
 
 /* Return true if cache gets updated. Otherwise, return false */
diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c
index 9cb077b583..29745ed55f 100644
--- a/xen/arch/x86/cpu/microcode/intel.c
+++ b/xen/arch/x86/cpu/microcode/intel.c
@@ -245,11 +245,6 @@ static enum microcode_match_result microcode_update_match(
     return mc->rev > cpu_sig->rev ? NEW_UCODE : OLD_UCODE;
 }
 
-static void free_patch(struct microcode_patch *patch)
-{
-    xfree(patch);
-}
-
 static enum microcode_match_result compare_patch(
     const struct microcode_patch *new, const struct microcode_patch *old)
 {
@@ -356,6 +351,5 @@ const struct microcode_ops intel_ucode_ops = {
     .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
     .apply_microcode                  = apply_microcode,
-    .free_patch                       = free_patch,
     .compare_patch                    = compare_patch,
 };
diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h
index d31bcf14b1..878f8d805f 100644
--- a/xen/arch/x86/cpu/microcode/private.h
+++ b/xen/arch/x86/cpu/microcode/private.h
@@ -25,7 +25,7 @@ struct microcode_ops {
      *
      * If one is found, allocate and return a struct microcode_patch
      * encapsulating the appropriate microcode patch.  Does not alias the
-     * original buffer.
+     * original buffer.  Must be suitable to be freed with a single xfree().
      *
      * If one is not found, (nothing matches the current CPU), return NULL.
      * Also may return ERR_PTR(-err), e.g. bad container, out of memory.
@@ -56,9 +56,6 @@ struct microcode_ops {
      */
     void (*end_update_percpu)(void);
 
-    /* Free a patch previously allocated by cpu_request_microcode(). */
-    void (*free_patch)(struct microcode_patch *patch);
-
     /*
      * Given two patches, are they both applicable to the current CPU, and is
      * new a higher revision than old?
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 10:23:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 10:23:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJx0E-000236-0g; Thu, 02 Apr 2020 10:23:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jJx0C-000231-9r
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 10:23:12 +0000
X-Inumbo-ID: f41d9ac2-74cb-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f41d9ac2-74cb-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 10:23:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585822992;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=Y8LCM/pBPhxwBWME6Rc+dCIWJCwOZHigAysnBgEo1j4=;
 b=Iytpkjejcr8F5jqULgVd0P/w33JYnH61zWorOU5GqNC9wHYA+iA07/l7
 LVVMpeGw21/Ek39PfwNUy/Nx5TT/WhEj8/rnd2c5WZYJv4gkxfl4THflV
 vQaixxKCuGXVez/0EUhPZhks7ggRREE3uBD+1l+p0SqR2ey2uBoc7XshV A=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: PmIXRldKAlznqTrSX38cf/QgGDOmpqz3/bd8vTE7VdquFi+PE2RiKriVHyAQpNsi2iMRlCPEwb
 qUrzENRU1hW9bABbz/r2wJRuY0JgSJDeNBOh3ABcEuyaucQexdztUCsXlxy+DPO+kTV6cIOQFE
 S27uX7gM3Z5v8y3Kvs6VQkNoCvjun+ON536efOXO1/tYR8O70Zdgu9SaI+E1b5jhM1c58n/xjQ
 90jO783RAApMckuqzKAOt5uAUrflhX4i9MHeJ//TUuxYDAHW988DP61TxoHi4bJ7QLK6vnFpoe
 zKY=
X-SBRS: 2.7
X-MesageID: 15068231
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15068231"
Subject: Re: [PATCH] x86emul: inherit HOSTCC when building 32-bit harness on
 64-bit host
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <842a0920-60ed-cf51-7f6c-37af40173160@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <09789474-7e62-67cc-0420-7c25b9572bce@citrix.com>
Date: Thu, 2 Apr 2020 11:23:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <842a0920-60ed-cf51-7f6c-37af40173160@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02/04/2020 10:43, Jan Beulich wrote:
> We're deliberately bringing XEN_COMPILE_ARCH and XEN_TARGET_ARCH out of
> sync in this case, and hence HOSTCC won't get set from CC. Therefore
> without this addition HOSTCC would not match a possible make command
> line override of CC, but default to "gcc", likely causing the build to
> fail for test_x86_emulator.c on systems with too old a gcc.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 11:08:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 11:08:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJxi6-0005MW-RR; Thu, 02 Apr 2020 11:08:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ugol=5S=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jJxi6-0005MR-74
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 11:08:34 +0000
X-Inumbo-ID: 4a43daf0-74d2-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4a43daf0-74d2-11ea-83d8-bc764e2007e4;
 Thu, 02 Apr 2020 11:08:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4A2BDAC6E;
 Thu,  2 Apr 2020 11:08:31 +0000 (UTC)
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: paul@xen.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <e9b21d59-3a4a-1498-e5f4-45d1420ddbc4@suse.com>
 <001201d608d5$513a7490$f3af5db0$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <fc7ffa50-5648-f335-02a4-1819d826c193@suse.com>
Date: Thu, 2 Apr 2020 13:08:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <001201d608d5$513a7490$f3af5db0$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 11:58, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 01 April 2020 15:51
>> To: Paul Durrant <paul@xen.org>
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap
>> <george.dunlap@citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; Julien Grall <julien@xen.org>;
>> Stefano Stabellini <sstabellini@kernel.org>; Wei Liu <wl@xen.org>
>> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context
>>
>> On 27.03.2020 19:50, Paul Durrant wrote:
>>> Domain context is state held in the hypervisor that does not come under
>>> the category of 'HVM state' but is instead 'PV state' that is common
>>> between PV guests and enlightened HVM guests (i.e. those that have PV
>>> drivers) such as event channel state, grant entry state, etc.
>>
>> Without looking at the patch details yet, I'm having some difficulty
>> understanding how this is going to work in a safe/correct manner. I
>> suppose for LU the system is in a frozen enough state that
>> snapshotting and copying state like this is okay, but ...
>>
>>> To allow enlightened HVM guests to be migrated without their co-operation
>>> it will be necessary to transfer such state along with the domain's
>>> memory image, architectural state, etc. This framework is introduced for
>>> that purpose.
>>>
>>> This patch adds the new public header and the low level implementation,
>>> entered via the domain_save() or domain_load() functions. Subsequent
>>> patches will introduce other parts of the framwork, and code that will
>>> make use of it within the current version of the libxc migration stream.
>>
>> ... here you suggest (and patch 5 appears to match this) that this
>> is going to be used even in "normal" migration streams.
> 
> Well, 'transparent' (or non-cooperative) migration will only work in some cases but it definitely does work.
> 
>> All of the
>> items named are communication vehicles, and hence there are always
>> two sides that can influence the state. For event channels, the
>> other side (which isn't paused) or the hardware (for passed through
>> devices) might signal them, or it (just the former obviously) could
>> close their end, resulting in a state change also for the domain
>> being migrated. If this happens after the snapshot was taken, the
>> state change is lost.
> 
> Indeed, which is why we *do* rely on co-operation from the other end
> of the event channels in the migration case. In the initial case it
> is likely we'll veto transparent migration unless all event channels
> are connected to either dom0 or Xen.

Co-operation for "normal" migration, iirc, consists of tearing down
and re-establishing everything. There's simply no risk of losing e.g.
events this way.

>> Otoh I'm sure the case was considered, so perhaps I'm simply missing
>> some crucial aspect (which then could do with spelling out in the
>> description of the cover letter).
>>
> 
> Does that need to be explained for a series that is just
> infrastructure?

I think so, yes - this infrastructure is pointless to introduce if
it doesn't allow fulfilling all requirements. Pointing at the design
doc (in the cover letter) may be enough if all aspects are covered
by what's there. I wouldn't have assumed using this infrastructure
also for co-operative migration to also be mentioned there.

Considering the situation with event channels (all closed), doing
what you do for the shared info page is probably going to be fine;
large parts of it are in a known state (or need re-filling on the
destination) anyway. What other plans do you have for non-LU
migration wrt this new infrastructure? If the shared info page is
all that's going to get migrated with its help, I'd wonder whether
the infrastructure wasn't better conditional upon a LU config
option, and the shared info migration was left as it is now.

> The overall design doc is now committed in the repo (although may
> need some expansion in future) so I could point at that.
> I don't think I'm giving anything away when I say that EC2's
> downstream code simply (ab)uses HVM save records for transferring
> the extra state; all I'm trying to do here is create something
> cleaner onto which I can re-base and upstream the EC2 code.

That was my guess, indeed.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 11:22:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 11:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJxvV-0006un-SL; Thu, 02 Apr 2020 11:22:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jJxvU-0006ui-LX
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 11:22:24 +0000
X-Inumbo-ID: 39152e1c-74d4-11ea-bbb2-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 39152e1c-74d4-11ea-bbb2-12813bfff9fa;
 Thu, 02 Apr 2020 11:22:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585826543;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=XmkrE30c4AIpnSY4hot20plgsx2trYGUvHcFv55q0FM=;
 b=EQhsxK3pKYC/3Fd3T8RUIaLxnLgo/3BilnXg8G5Ieqls8widws/qIzmd
 BnMKAL3g1MaZFadNAbC34gL5XxsNaO+8oZe8MEr3quJ+uZu3t987vpqVi
 DNCC5+WUKi5w5ZUW4165yX5TmQRFxfSn2cOD3zPemlGlrds9IgXA1WYqT I=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 8lMofdGJW2ThPHHjO71YLbENLJq7cAPkkbtgJc+qsmqhJAlnSE2p8rBanQb+IqdRl6g880eiie
 1gygY+IBOFjU94WKUzlLF6OprpNNEZythrCYps/wpowS+djiwVoTLbw+H94TmBwYGAqKLGzvcr
 GdpS1yyZUhD8isHVhAlIHLX8TTGva4+YWH0W31zMTan/65QfrxfvVV+YwwbIE7xQu9zGkPLNWE
 P1+t9mR0Q9MLUyEdvLgYx69K2aOLeFdJlvc4kG5QU8DWqKHrFXKpYjVsQmhpm+aqi1oZOwMSMX
 yT4=
X-SBRS: 2.7
X-MesageID: 15043671
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15043671"
Subject: Re: [PATCH v2] x86emul: suppress "not built" warning for test harness
 for run targets
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <4c5af3e1-836f-4104-99a8-79755c8034e1@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <8e5228cf-248b-863f-4faf-16a2b77f6ed0@citrix.com>
Date: Thu, 2 Apr 2020 12:22:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <4c5af3e1-836f-4104-99a8-79755c8034e1@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/03/2020 16:11, Jan Beulich wrote:
> The run* targets can be used to test whatever the tool chain is capable
> of building, as long as at least the main harness source file builds.
> Don't probe the tools chain, in particular to avoid issuing the warning,
> in this case. While looking into this I also noticed the wording of the
> respective comment isn't quite right, which therefore gets altered at
> the same time.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 12:07:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 12:07:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJydE-0001sb-2Q; Thu, 02 Apr 2020 12:07:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+qk0=5S=redhat.com=philmd@srs-us1.protection.inumbo.net>)
 id 1jJydD-0001sW-6J
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 12:07:35 +0000
X-Inumbo-ID: 8934e4cc-74da-11ea-b58d-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 8934e4cc-74da-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 12:07:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1585829253;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=GH9ZctDlOJVXlePIEy/7t69vRL4BBSn3UAVlOi0YVIE=;
 b=bnDDKk50p8DxaYPE1/q/Ij5J1PTiRpQJ6O3nIksZBPSWBTQSTf/g2l+FGlgevS9cuegwTt
 T1Q8jw8BjtUUMsrg1okQRGGT1XGwlKA+Jno9/uzsiXL2iQ0C5x3QwzsxWTqIzo4VVQDGJi
 QBN6UaJ8SnwrimxOYKXy0cncI2xPT1s=
Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com
 [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-269-6E7ADdhYOCKMgTys_FIdiQ-1; Thu, 02 Apr 2020 08:07:26 -0400
X-MC-Unique: 6E7ADdhYOCKMgTys_FIdiQ-1
Received: by mail-ed1-f69.google.com with SMTP id a3so2548527edy.8
 for <xen-devel@lists.xenproject.org>; Thu, 02 Apr 2020 05:07:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:to:cc:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=IvvY/ezh+A+md7a0w8aybV+mbPJAV/52y9KvRJMvL7U=;
 b=uhzJCZIq45pDtDrl9N8B4AjmFNQxba2z9fFq8uIrAw2hH6OqcKCZpuBQ2dY4QxrNH/
 cGFx+jlpTkuYILpq2u36DSac3Pu1TbHnVwP7gqUO+860ijGFTGvWAV8yXYhOK1g7YK3b
 BLW7SZTuoQdDykyThPnfUC1tDn8QOiVU4DAYipq2hhZgE3koVLy/GQRvQbUXHnRCUUCd
 77KgLi4GhrkDRz9/LWdvPl2Gfta0m9jxKE6fvwL4Gv9ik3j4Fxjxg3w+RDQD42LDF8VZ
 jGUuYNIYrn00vm9Tc1WYNjbs1GEkJYWhDCejPnmPkkSPxROlq3k3Amk6kU3qw5xhLxHg
 8ynQ==
X-Gm-Message-State: AGi0Pub9SHLkS2SxHS6Np1qRL/dmkO08We6R3IOCUWRWSlcEJNwMgtcN
 L4eka56PqVwaWg59cupEh6exvFsuhu1Kj+Up6qPX0ygKDJEOF6jsC/ukSTK5Xdi34lb1lm/vV+N
 PQlrTl5OSiYw6M+Gbm94AMoqZIFw=
X-Received: by 2002:a17:906:5003:: with SMTP id
 s3mr2829101ejj.266.1585829244901; 
 Thu, 02 Apr 2020 05:07:24 -0700 (PDT)
X-Google-Smtp-Source: APiQypJLDm9ZnfHA6wKQOZciX7wwCPmBDqT1nlQfHJMQNrxnzwDeBgppafryQKmrd2XqzYIdc24Wsg==
X-Received: by 2002:a17:906:5003:: with SMTP id
 s3mr2829072ejj.266.1585829244579; 
 Thu, 02 Apr 2020 05:07:24 -0700 (PDT)
Received: from [192.168.1.39] (116.red-83-42-57.dynamicip.rima-tde.net.
 [83.42.57.116])
 by smtp.gmail.com with ESMTPSA id e14sm906098edy.84.2020.04.02.05.07.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Apr 2020 05:07:23 -0700 (PDT)
Subject: Re: [Qemu-devel] [PULL 06/25] xen: create xenstore areas for
 XenDevice-s
To: paul@xen.org, 'Anthony PERARD' <anthony.perard@citrix.com>,
 qemu-devel@nongnu.org
References: <20190114135154.16826-1-anthony.perard@citrix.com>
 <20190114135154.16826-7-anthony.perard@citrix.com>
 <772fab5a-59ab-050f-9fef-f3b050cfc5cd@redhat.com>
 <001001d608d4$0e7b9f40$2b72ddc0$@xen.org>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <philmd@redhat.com>
Message-ID: <5f7e6e45-bf73-8a64-81a6-a41cc7b9d747@redhat.com>
Date: Thu, 2 Apr 2020 14:07:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <001001d608d4$0e7b9f40$2b72ddc0$@xen.org>
Content-Language: en-US
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, 'Markus Armbruster' <armbru@redhat.com>,
 'Peter Maydell' <peter.maydell@linaro.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/2/20 11:49 AM, Paul Durrant wrote:
>> -----Original Message-----
>> From: Philippe Mathieu-Daud=C3=A9 <philmd@redhat.com>
>> Sent: 01 April 2020 17:14
>> To: Anthony PERARD <anthony.perard@citrix.com>; qemu-devel@nongnu.org
>> Cc: xen-devel@lists.xenproject.org; Peter Maydell <peter.maydell@linaro.=
org>; Paul Durrant
>> <paul@xen.org>; Markus Armbruster <armbru@redhat.com>
>> Subject: Re: [Qemu-devel] [PULL 06/25] xen: create xenstore areas for Xe=
nDevice-s
>>
>> Hi Anthony, Paul.
>>
>> Cc'ing Markus too.
>>
>> On 1/14/19 2:51 PM, Anthony PERARD wrote:
>>> From: Paul Durrant <paul.durrant@citrix.com>
>>>
>>> This patch adds a new source module, xen-bus-helper.c, which builds on
>>> basic libxenstore primitives to provide functions to create (setting
>>> permissions appropriately) and destroy xenstore areas, and functions to
>>> 'printf' and 'scanf' nodes therein. The main xen-bus code then uses
>>> these primitives [1] to initialize and destroy the frontend and backend
>>> areas for a XenDevice during realize and unrealize respectively.
>>>
>>> The 'xen-block' implementation is extended with a 'get_name' method tha=
t
>>> returns the VBD number. This number is required to 'name' the xenstore
>>> areas.
>>>
>>> NOTE: An exit handler is also added to make sure the xenstore areas are
>>>         cleaned up if QEMU terminates without devices being unrealized.
>>>
>>> [1] The 'scanf' functions are actually not yet needed, but they will be
>>>       needed by code delivered in subsequent patches.
>>>
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>> Reviewed-by: Anthony Perard <anthony.perard@citrix.com>
>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>> ---
>>>    hw/block/xen-block.c            |   9 +
>>>    hw/xen/Makefile.objs            |   2 +-
>>>    hw/xen/trace-events             |  12 +-
>>>    hw/xen/xen-bus-helper.c         | 150 +++++++++++++++
>>>    hw/xen/xen-bus.c                | 321 ++++++++++++++++++++++++++++++=
+-
>>>    include/hw/xen/xen-bus-helper.h |  39 ++++
>>>    include/hw/xen/xen-bus.h        |  12 ++
>>>    7 files changed, 540 insertions(+), 5 deletions(-)
>>>    create mode 100644 hw/xen/xen-bus-helper.c
>>>    create mode 100644 include/hw/xen/xen-bus-helper.h
>>>
>> [...]
>>> +static void xen_device_exit(Notifier *n, void *data)
>>> +{
>>> +    XenDevice *xendev =3D container_of(n, XenDevice, exit);
>>> +
>>> +    xen_device_unrealize(DEVICE(xendev), &error_abort);
>>>    }
>>>
>>>    static void xen_device_realize(DeviceState *dev, Error **errp)
>>>    {
>>>        XenDevice *xendev =3D XEN_DEVICE(dev);
>>>        XenDeviceClass *xendev_class =3D XEN_DEVICE_GET_CLASS(xendev);
>>> +    XenBus *xenbus =3D XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
>>>        const char *type =3D object_get_typename(OBJECT(xendev));
>>>        Error *local_err =3D NULL;
>>>
>>> -    trace_xen_device_realize(type);
>>> +    if (xendev->frontend_id =3D=3D DOMID_INVALID) {
>>> +        xendev->frontend_id =3D xen_domid;
>>> +    }
>>> +
>>> +    if (xendev->frontend_id >=3D DOMID_FIRST_RESERVED) {
>>> +        error_setg(errp, "invalid frontend-id");
>>> +        goto unrealize;
>>> +    }
>>> +
>>> +    if (!xendev_class->get_name) {
>>> +        error_setg(errp, "get_name method not implemented");
>>> +        goto unrealize;
>>> +    }
>>> +
>>> +    xendev->name =3D xendev_class->get_name(xendev, &local_err);
>>> +    if (local_err) {
>>> +        error_propagate_prepend(errp, local_err,
>>> +                                "failed to get device name: ");
>>> +        goto unrealize;
>>> +    }
>>> +
>>> +    trace_xen_device_realize(type, xendev->name);
>>> +
>>> +    xen_device_backend_create(xendev, &local_err);
>>> +    if (local_err) {
>>> +        error_propagate(errp, local_err);
>>> +        goto unrealize;
>>> +    }
>>> +
>>> +    xen_device_frontend_create(xendev, &local_err);
>>> +    if (local_err) {
>>> +        error_propagate(errp, local_err);
>>> +        goto unrealize;
>>> +    }
>>>
>>>        if (xendev_class->realize) {
>>>            xendev_class->realize(xendev, &local_err);
>>> @@ -72,18 +364,43 @@ static void xen_device_realize(DeviceState *dev, E=
rror **errp)
>>>            }
>>>        }
>>>
>>> +    xen_device_backend_printf(xendev, "frontend", "%s",
>>> +                              xendev->frontend_path);
>>> +    xen_device_backend_printf(xendev, "frontend-id", "%u",
>>> +                              xendev->frontend_id);
>>> +    xen_device_backend_printf(xendev, "online", "%u", 1);
>>> +    xen_device_backend_printf(xendev, "hotplug-status", "connected");
>>> +
>>> +    xen_device_backend_set_state(xendev, XenbusStateInitWait);
>>> +
>>> +    xen_device_frontend_printf(xendev, "backend", "%s",
>>> +                               xendev->backend_path);
>>> +    xen_device_frontend_printf(xendev, "backend-id", "%u",
>>> +                               xenbus->backend_id);
>>> +
>>> +    xen_device_frontend_set_state(xendev, XenbusStateInitialising);
>>> +
>>> +    xendev->exit.notify =3D xen_device_exit;
>>> +    qemu_add_exit_notifier(&xendev->exit);
>>>        return;
>>>
>>>    unrealize:
>>>        xen_device_unrealize(dev, &error_abort);
>>
>> It seems if unrealize() fails, the error stored in &local_err is never
>> reported. Not sure if this can be improved although.
>=20
> In this case that's essentially a "don't care". We want to know why the r=
ealize failed but if the unrealize fails something is probably pretty serio=
usly screwed (hence the error_abort).

OK. I was surprised by the singular pattern (which confuses Coccinelle=20
semantic transformations), but it works.

Thanks for the quick feedback Paul!

Regards,

Phil.

>=20
>    Paul
>=20



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 12:43:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 12:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJzC8-00050W-2p; Thu, 02 Apr 2020 12:43:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=6xHX=5S=gmail.com=kevin.buckley.ecs.vuw.ac.nz@srs-us1.protection.inumbo.net>)
 id 1jJzC7-00050R-4G
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 12:43:39 +0000
X-Inumbo-ID: 92d6f196-74df-11ea-9e09-bc764e2007e4
Received: from mail-wr1-x42f.google.com (unknown [2a00:1450:4864:20::42f])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 92d6f196-74df-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 12:43:38 +0000 (UTC)
Received: by mail-wr1-x42f.google.com with SMTP id t7so3979140wrw.12
 for <xen-devel@lists.xenproject.org>; Thu, 02 Apr 2020 05:43:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=Uuthd54xjku6K8Q2Q227K08pkabnP+VFCySgM4kEalQ=;
 b=Td9C5U/hACTCraH7iI7bHObT0Q0XdPVxUmpGRfoPWZDNo5smj0JsMbOfEhtNVrZuc7
 HF/E/pXtp2MAVA0F3rJ+NWWww4wbhCUOxwzM7c1rKuezzu4xcIjD0FBFoB9zcHtvQ6CR
 QhVo0IvaJabfT4uVK8g2uZr5FDaf1N4iNebO7+rUt67kZrODQaScyLkjXVyNA9ZEuD4O
 F2CKLVe85KIGy5N1RHr7bDfNs8WC+0bjWzRJ7eJ5voxFhqu4OAmwLKh+D9PScjamVw7Q
 YfeJiixq4OHw5r1i1Xqx10+z1G+g4w9mc4eoRloS9xAQ7g2W29dIlcr0Efj7JuKmq17b
 8ALw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=Uuthd54xjku6K8Q2Q227K08pkabnP+VFCySgM4kEalQ=;
 b=mw9DDAgTeXCZ4vgRNqQkTqL1nXGl79Md0BQDGkNMYROEJgPeVgR0ffUSjX7GO+cLnb
 nz8wd5VS57G6yriFHNhP/mq4wtAoyap3cZCf4+4Wk1PlzIpTw9rrHmDKaF2JQTbLmek3
 +AVDmIy4geYjRrOm+qNWApLnEwkNsHZgs1TNMhkE0vhbqhxjqBT7n6mIwHQ3Imi2Z30b
 vSIFm12mh8a9STkQtMmvBbXt/msvjTofQpnrz2wmo8/sO+8ZGUXaCgkfRgK8p0NqBleF
 mSyKSgF4bDykML6wCDP2MByb5uPcEyBuzG02loq72GmTNJYTnSp3S6JVTkT/MLvnqD00
 Rphg==
X-Gm-Message-State: AGi0Pubw+lYAr+tYXc5g4ORNyf8gWe5tMdoAuw5D0v3S22/1hkZFWdMX
 bZb/VFYWr946poe4+JF+hicSMi5YuL81CC8FLuQVWGEKJ+Q=
X-Google-Smtp-Source: APiQypLv6jG95UiKFCi60x4POV7E6+Rc2abv5tHdXKjRaz1GVm80lX8RVPEu+A1evt5pVhx19MJnF4foUTTbdRrylsY=
X-Received: by 2002:adf:a2d8:: with SMTP id t24mr3334511wra.366.1585831417250; 
 Thu, 02 Apr 2020 05:43:37 -0700 (PDT)
MIME-Version: 1.0
From: Kevin Buckley <kevin.buckley.ecs.vuw.ac.nz@gmail.com>
Date: Thu, 2 Apr 2020 20:43:26 +0800
Message-ID: <CABwOO=doPdSR1PUPLU-X2R6akDGRgBoqMv_wK_sPpkh9jF6kCQ@mail.gmail.com>
Subject: 4.13: import xen.lowlevel.xc fails with SystemError: bad call flags
To: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hello again,

despite having built a Xen 4.13 with just Python3 on a
Linux From Scratch system,

  http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html

specifically

 http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html#ch-xen


and booted into the Dom0 (Linux 5.5.3, GCC 9.2.0, Python 3.8.1)
without issue, in coming to boot up a DomU, I get the following
terse message


~ # cat /var/log/xen/bootloader.3.log
Traceback (most recent call last):
  File "/usr/lib/xen/bin/pygrub", line 21, in <module>
    import xen.lowlevel.xc
SystemError: bad call flags
~ #

in the wake of these messages during the xl cretate's  pygrub boot:


libxl: error: libxl_bootloader.c:648:bootloader_finished: Domain
3:bootloader failed - consult logfile /var/log/xen/bootloader.3.log
libxl: error: libxl_exec.c:117:libxl_report_child_exitstatus:
bootloader [766] exited with error status 1
libxl: error: libxl_create.c:1420:domcreate_rebuild_done: Domain
3:cannot (re-)build domain: -3
libxl: error: libxl_domain.c:1177:libxl__destroy_domid: Domain
3:Non-existant domain
libxl: error: libxl_domain.c:1131:domain_destroy_callback: Domain
3:Unable to destroy guest
libxl: error: libxl_domain.c:1058:domain_destroy_cb: Domain
3:Destruction of domain failed
libxl: error: libxl_dom.c:40:libxl__domain_type: unable to get domain
type for domid=3
xl: unable to exec console client: No such file or directory
libxl: error: libxl_exec.c:117:libxl_report_child_exitstatus: console
child [767] exited with error status 1


There's a suggestion out on the interweb thing that these

  SystemError: bad call flags

are something to do with Python 3.8, as in this thread I found
when searching for the above:

-------
It's a bug in the Python binding of libcomps. I proposed a fix upstream:
https://github.com/rpm-software-management/libcomps/pull/50

Extract:

> In Python 3.7, import didn't check descriptor flags (METH_KEYWORDS):
> these flags were only checked when the methods were called.
>
> In Python 3.8, the flags are checked at soon as the module is imported,
> which prevents the module to be imported.
-------

Is that likely to be what i am seeing?

I had a gander at

tools/python/xen/lowlevel/xc/xc.c

tools/python/xen/lowlevel/xs/xc.c

but it's not obvious to me where, presumably in,

#if PY_MAJOR_VERSION >= 3
#define INITERROR return NULL
PyMODINIT_FUNC PyInit_xc(void)
#else
#define INITERROR return
PyMODINIT_FUNC initxc(void)
#endif
{

I could start to "play around" with any "descriptor flags"


Any pointers welcome, including "it's not a Python 3.8 thing,
you idiot" responses,
Kevin


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 12:56:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 12:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJzO9-0005vm-8j; Thu, 02 Apr 2020 12:56:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jJzO7-0005vh-5L
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 12:56:03 +0000
X-Inumbo-ID: 4dd483fe-74e1-11ea-b58d-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4dd483fe-74e1-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 12:56:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585832162;
 h=subject:to:references:from:message-id:date:mime-version:
 in-reply-to:content-transfer-encoding;
 bh=p0nro/otG9FvlcbRWEZTTq4craSZautD7iOq2tx3e4E=;
 b=DEEMEyYoz0OLr4ZRVpRcEtBMCrxiKjl5XalOxkSDZ8NMFZtOMfacnutD
 +a611sfGy1O7gMOo5q2AWLpG3nWnGcfRHIgt0oyRVUL4kVDuRrem+hqZ5
 +mJ3a0H1aTO4fSRQM9xgmbNBqsniK6wEdIPko4NYa1BUpjzuJJ+/cND8O 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: YhJserJ4oif0agV9Yy0Udz2wB1yeV6J9pSg+383q2AEyH9vKpnEfvLkaQEFMQ808KAHpuq5l3b
 /QqxbUtP+pdx2cezN6NLROUVaB/Iec0uROqFUz32K61aKlf1S7XdvQ7v40XBxHP2wwJd3VSifG
 bluGpXTNqiJM6dUwDecixvvDQEeCJSBmgUdv99RBVrLswqmANu9ReSvf+NCe9ON8FpEed2IfZY
 qrZcuIpz6ShXqy50a4ocRrsXoAJnotuvFMGxjvmyN51eUWBS7s5n7Cmjbz3/GWdRzzUlbzmgLE
 sjg=
X-SBRS: 2.7
X-MesageID: 15047941
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15047941"
Subject: Re: 4.13: import xen.lowlevel.xc fails with SystemError: bad call
 flags
To: Kevin Buckley <kevin.buckley.ecs.vuw.ac.nz@gmail.com>,
 <xen-devel@lists.xenproject.org>
References: <CABwOO=doPdSR1PUPLU-X2R6akDGRgBoqMv_wK_sPpkh9jF6kCQ@mail.gmail.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <49bb60b5-d64b-393c-bdd2-a4024e695e6e@citrix.com>
Date: Thu, 2 Apr 2020 13:55:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CABwOO=doPdSR1PUPLU-X2R6akDGRgBoqMv_wK_sPpkh9jF6kCQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02/04/2020 13:43, Kevin Buckley wrote:
> Hello again,
>
> despite having built a Xen 4.13 with just Python3 on a
> Linux From Scratch system,
>
>   http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html
>
> specifically
>
>  http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html#ch-xen
>
>
> and booted into the Dom0 (Linux 5.5.3, GCC 9.2.0, Python 3.8.1)
> without issue, in coming to boot up a DomU, I get the following
> terse message
>
>
> ~ # cat /var/log/xen/bootloader.3.log
> Traceback (most recent call last):
>   File "/usr/lib/xen/bin/pygrub", line 21, in <module>
>     import xen.lowlevel.xc
> SystemError: bad call flags
> ~ #
>
> in the wake of these messages during the xl cretate's  pygrub boot:
>
>
> libxl: error: libxl_bootloader.c:648:bootloader_finished: Domain
> 3:bootloader failed - consult logfile /var/log/xen/bootloader.3.log
> libxl: error: libxl_exec.c:117:libxl_report_child_exitstatus:
> bootloader [766] exited with error status 1
> libxl: error: libxl_create.c:1420:domcreate_rebuild_done: Domain
> 3:cannot (re-)build domain: -3
> libxl: error: libxl_domain.c:1177:libxl__destroy_domid: Domain
> 3:Non-existant domain
> libxl: error: libxl_domain.c:1131:domain_destroy_callback: Domain
> 3:Unable to destroy guest
> libxl: error: libxl_domain.c:1058:domain_destroy_cb: Domain
> 3:Destruction of domain failed
> libxl: error: libxl_dom.c:40:libxl__domain_type: unable to get domain
> type for domid=3
> xl: unable to exec console client: No such file or directory
> libxl: error: libxl_exec.c:117:libxl_report_child_exitstatus: console
> child [767] exited with error status 1
>
>
> There's a suggestion out on the interweb thing that these
>
>   SystemError: bad call flags
>
> are something to do with Python 3.8, as in this thread I found
> when searching for the above:
>
> -------
> It's a bug in the Python binding of libcomps. I proposed a fix upstream:
> https://github.com/rpm-software-management/libcomps/pull/50
>
> Extract:
>
>> In Python 3.7, import didn't check descriptor flags (METH_KEYWORDS):
>> these flags were only checked when the methods were called.
>>
>> In Python 3.8, the flags are checked at soon as the module is imported,
>> which prevents the module to be imported.
> -------
>
> Is that likely to be what i am seeing?
>
> I had a gander at
>
> tools/python/xen/lowlevel/xc/xc.c
>
> tools/python/xen/lowlevel/xs/xc.c
>
> but it's not obvious to me where, presumably in,
>
> #if PY_MAJOR_VERSION >= 3
> #define INITERROR return NULL
> PyMODINIT_FUNC PyInit_xc(void)
> #else
> #define INITERROR return
> PyMODINIT_FUNC initxc(void)
> #endif
> {
>
> I could start to "play around" with any "descriptor flags"
>
>
> Any pointers welcome, including "it's not a Python 3.8 thing,
> you idiot" responses,

We've got a fix in staging

https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e19b4b3b55f84e0cfcc02fe5d66965969a81c965

It hasn't been backported to the 4.13 stable tree yet.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 12:57:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 12:57:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJzPO-00061O-KY; Thu, 02 Apr 2020 12:57:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9JfQ=5S=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jJzPN-00061F-7l
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 12:57:21 +0000
X-Inumbo-ID: 7badff3a-74e1-11ea-bbcf-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7badff3a-74e1-11ea-bbcf-12813bfff9fa;
 Thu, 02 Apr 2020 12:57:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=oHeT7HsYjubqXaA84mvfo/zLcjQiRkaV6xomYy2t3w8=; b=xsjY/gQxHFVR1+jd2988C/Zeh
 V9lqJy7qphgvArpO63yG12Y398/bNJJUxMCIuZqXUiNvztQGBVQkAu6AQAxkkQpa0uQD9z0jQZj21
 SUkHqzJTrylZa0Z3b3I3QDv4nb8C0htX5IBZTrxd5XoxJd+TcIWSeG1DppiO91d4PowcY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJzPJ-0005iJ-Lj; Thu, 02 Apr 2020 12:57:17 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jJzPJ-0003GA-1V; Thu, 02 Apr 2020 12:57:17 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jJzPJ-0004Rv-0q; Thu, 02 Apr 2020 12:57:17 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149297-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149297: regressions - FAIL
X-Osstest-Failures: xen-unstable:test-amd64-i386-qemut-rhel6hvm-amd:guest-start/redhat.repeat:fail:regression
 xen-unstable:build-i386-prev:xen-build:fail:regression
 xen-unstable:test-amd64-amd64-dom0pvh-xl-intel:guest-start/debian.repeat:fail:regression
 xen-unstable:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-dom0pvh-xl-amd:guest-start/debian.repeat:fail:nonblocking
X-Osstest-Versions-This: xen=3925402f5dd7ae93010c48688eb64f880c794267
X-Osstest-Versions-That: xen=e19b4b3b55f84e0cfcc02fe5d66965969a81c965
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 02 Apr 2020 12:57:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 149188
 build-i386-prev               6 xen-build                fail REGR. vs. 149188
 test-amd64-amd64-dom0pvh-xl-intel 20 guest-start/debian.repeat fail REGR. vs. 149188

Tests which did not succeed, but are not blocking:
 test-amd64-i386-migrupgrade   1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149151
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149188
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149188
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 149188
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149188
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149188
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-dom0pvh-xl-amd 20 guest-start/debian.repeat fail starved in 149188

version targeted for testing:
 xen                  3925402f5dd7ae93010c48688eb64f880c794267
baseline version:
 xen                  e19b4b3b55f84e0cfcc02fe5d66965969a81c965

Last test of basis   149188  2020-03-30 01:51:23 Z    3 days
Failing since        149231  2020-03-31 02:00:20 Z    2 days    3 attempts
Testing same since   149297  2020-04-01 18:11:01 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jason Andryuk <jandryuk@gmail.com>
  Julien Grall <jgrall@amazon.com>
  Julien Grall <julien.grall@arm.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Simran Singhal <singhalsimran0@gmail.com>
  Stefano Stabellini <sstabellini@kernel.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              fail    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  blocked 
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit 3925402f5dd7ae93010c48688eb64f880c794267
Author: Roger Pau Monné <roger.pau@citrix.com>
Date:   Wed Apr 1 12:36:57 2020 +0200

    x86/dom0: fix copy of low 1MB data for PVH
    
    The orders of start and end are inverted in order to calculate the
    size of the copy operation.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit 753ab41b8b763b58cc3dd940d862bceaf58f7a4c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Apr 1 12:34:33 2020 +0200

    x86emul: support SYSRET
    
    This is to augment SYSCALL, which we've been supporting for quite some
    time.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit 78c87e41f0cdd75c847f41a2768faf41983bdf13
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Apr 1 12:32:17 2020 +0200

    x86emul: vendor specific SYSCALL behavior
    
    AMD CPUs permit the insn everywhere (even outside of protected mode),
    while Intel ones restrict it to 64-bit mode. While at it also comment
    about the apparently missing CPUID bit check.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit 5d515b1c296ebad6889748ea1e49e063453216a3
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Apr 1 12:28:30 2020 +0200

    x86/HVM: fix AMD ECS handling for Fam10
    
    The involved comparison was, very likely inadvertently, converted from
    >= to > when making changes unrelated to the actual family range.
    
    Fixes: 9841eb71ea87 ("x86/cpuid: Drop a guests cached x86 family and model information")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Paul Durrant <paul@xen.org>

commit 897b6f4b4324b7696602fe386b5ea93506415442
Author: Julien Grall <jgrall@amazon.com>
Date:   Mon Mar 30 20:21:53 2020 +0100

    tools/libxc: misc: Mark const the parameter 'params' of xc_set_parameters()
    
    The parameter 'params' of xc_set_parameters() should never be modified.
    So mark it as const.
    
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>

commit 2b8079610ec55413613ad071cc81cd9f97232a7e
Author: Julien Grall <jgrall@amazon.com>
Date:   Mon Mar 30 20:21:52 2020 +0100

    tools/libxc: misc: Mark const the parameter 'keys' of xc_send_debug_keys()
    
    OCaml is using a string to describe the parameter 'keys' of
    xc_send_debug_keys(). Since Ocaml 4.06.01, String_val() will return a
    const char * when using -safe-string. This will result to a build
    failure because xc_send_debug_keys() expects a char *.
    
    The function should never modify the parameter 'keys' and therefore the
    parameter should be const. Unfortunately, this is not directly possible
    because DECLARE_HYPERCALL_BOUNCE() is expecting a non-const variable.
    
    A new macro DECLARE_HYPERCALL_BOUNCE_IN() is introduced and will take
    care of const parameter. The first user will be xc_send_debug_keys() but
    this can be used in more place in the future.
    
    Reported-by: Dario Faggioli <dfaggioli@suse.com>
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>

commit c4336b0b1a35c1a54a21c0cafad39466613a714f
Author: Julien Grall <jgrall@amazon.com>
Date:   Mon Mar 30 20:21:51 2020 +0100

    xen/public: sysctl: set_parameter.params and debug.keys should be const
    
    The fields set_parameter.params and debug.keys should never be modified
    by the hypervisor. So mark them as const.
    
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit dc0b3eb56b9ce3e2b61f0c7d3af5a98b5a586099
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Tue Mar 31 11:30:47 2020 +0100

    build,arm: Fix deps check of head.o
    
    arm*/head.o isn't in obj-y or extra-y, so make don't load the
    associated .*.d file (or .*.cmd file when if_changed will be used).
    There is a workaround where .*.d file is added manually into DEPS.
    
    Changing DEPS isn't needed, we can simply add head.o into extra-y and
    the dependency files will be loaded.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Julien Grall <jgrall@amazon.com>

commit f41eb7ba3e5070b4a7a4f54cac236bf9ff93d798
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Tue Mar 31 11:30:46 2020 +0100

    xen/arm: Configure early printk via Kconfig
    
    At the moment, early printk can only be configured on the make command
    line. It is not very handy because a user has to remove the option
    everytime it is using another command other than compiling the
    hypervisor.
    
    Furthermore, early printk is one of the few odds one that are not
    using Kconfig.
    
    So this is about time to move it to Kconfig.
    
    The new kconfigs options allow a user to eather select a UART driver
    to use at boot time, and set the parameters, or it is still possible
    to select a platform which will set the parameters.
    
    If CONFIG_EARLY_PRINTK is present in the environment or on the make
    command line, make will return an error.
    
    Signed-off-by: Julien Grall <julien.grall@arm.com>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Tested-by: Stefano Stabellini <sstabellini@kernel.org>
    Reviewed-by: Julien Grall <jgrall@amazon.com>

commit 370f44fa73004e9e19cff9b1e65ee7ea61b55700
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Tue Mar 31 11:30:45 2020 +0100

    xen/arm: Rename all early printk macro
    
    We are going to move the generation of the early printk macro into
    Kconfig. This means all macro will be prefix with CONFIG_. We do that
    ahead of the change.
    
    We also take the opportunity to better name some variables, which are
    used by only one driver and wouldn't make sens for other UART driver.
    Thus,
        - EARLY_UART_REG_SHIFT became CONFIG_EARLY_UART_8250_REG_SHIFT
        - EARLY_PRINTK_VERSION_* became CONFIG_EARLY_UART_SCIF_VERSION_*
    
    The other variables are change to have the prefix CONFIG_EARLY_UART_
    when they change a parameter of the driver. So we have now:
        - CONFIG_EARLY_UART_BAUD_RATE
        - CONFIG_EARLY_UART_BASE_ADDRESS
        - CONFIG_EARLY_UART_INIT
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Julien Grall <jgrall@amazon.com>
    Tested-by: Stefano Stabellini <sstabellini@kernel.org>

commit 5af4698d98d881e786c0909b6308f04696586c49
Author: Simran Singhal <singhalsimran0@gmail.com>
Date:   Tue Mar 31 08:51:21 2020 +0200

    x86: compress lines for immediate return
    
    Compress two lines into a single line if immediate return statement is found.
    It also remove variables retval, freq, effective, vector, ovf and now
    as they are no longer needed.
    
    Signed-off-by: Simran Singhal <singhalsimran0@gmail.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    Acked-by: Jan Beulich <jbeulich@suse.com>

commit 922f59a4302939471254b91c921daa5bd7c7e3fa
Author: Simran Singhal <singhalsimran0@gmail.com>
Date:   Tue Mar 31 08:50:25 2020 +0200

    x86: remove unnecessary cast on void pointer
    
    Assignment to a typed pointer is sufficient in C.
    No cast is needed.
    
    Also, changed some u64/u32 to uint64_t/uint32_t.
    
    Signed-off-by: Simran Singhal <singhalsimran0@gmail.com>
    Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>

commit f57ae00635da429cee02373dc909542a411a09e5
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Mar 31 08:46:44 2020 +0200

    SVM: split _np_enable VMCB field
    
    The nest paging enable is actually just a single bit within the 64-bit
    VMCB field, which is particularly relevant for uses like the one in
    nsvm_vcpu_vmentry(). Split the field, adding definitions for a few other
    bits at the same time. To be able to generate accessors for bitfields,
    VMCB_ACCESSORS() needs the type part broken out, as typeof() can't be
    applied to bitfields. Unfortunately this means specification of the same
    type in two distinct places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit 2a94100dd5646fb8abcd29f48553ff10d0788cc7
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Mar 30 14:52:12 2020 +0100

    docs/README: Fix a broken url
    
    There was a / missing here.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>

commit 9465fac25ebd46a495ee10c3cebce4d7f4b32b14
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Mar 30 14:51:51 2020 +0100

    docs etc.: https: Fix references to other Xen pages
    
    Change the url scheme to https.  This is all in-tree references to
    xenbits and the main website except for those in Config.mk.
    
    We leave Config.mk alone for now because those urls are used by CI
    systems and we need to check that nothing breaks when we change the
    download method.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>

commit 7e1867b12114602b94f2630a33aa82215b1c895c
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Mar 30 14:43:06 2020 +0100

    docs etc.: https: Fix references to wiki.xen[project].org
    
    Change the url scheme to https.  This is all in-tree references to the
    Xen wiki.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>

commit b72682c602b8d1aaadca439d49cc79c79dbc17bc
Author: Jason Andryuk <jandryuk@gmail.com>
Date:   Thu Mar 12 10:54:17 2020 -0400

    scripts: Use stat to check lock claim
    
    Replace the perl locking check with stat(1).  Stat is able to fstat
    stdin (file descriptor 0) when passed '-' as an argument.  This is now
    used to check $_lockfd.  stat(1) support for '-' was introduced to
    coreutils in 2009.
    
    After A releases its lock, script B will return from flock and execute
    stat.  Since the lockfile has been removed by A, stat prints an error to
    stderr and exits non-zero.  Redirect stderr to /dev/null to avoid
    filling /var/log/xen/xen-hotplug.log with "No such file or directory"
    messages.
    
    Placing the stat call inside the "if" condition ensures we only check
    the stat output when the command completed successfully.
    
    This change removes the only runtime dependency of the xen toolstack on
    perl.
    
    Suggested-by: Ian Jackson <ian.jackson@citrix.com>
    Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
    Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>

commit 4b3f41e9d83209f5334095937aef7763da993781
Author: Simran Singhal <singhalsimran0@gmail.com>
Date:   Sun Mar 29 12:07:47 2020 +0530

    xen/x86: Remove parentheses from return arguments
    
    This patch remove unnecessary parentheses from return arguments.
    
    Signed-off-by: Simran Singhal <singhalsimran0@gmail.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    Acked-by: Jan Beulich <jbeulich@suse.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 13:11:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 13:11:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jJzdA-0007dM-6g; Thu, 02 Apr 2020 13:11:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=OjdR=5S=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jJzd9-0007dH-2H
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 13:11:35 +0000
X-Inumbo-ID: 791a6ed2-74e3-11ea-b58d-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 791a6ed2-74e3-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 13:11:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585833094;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=OgFQkZch/oM5un8LEmRzT+QveAnBoTeas/B8j4hRfYQ=;
 b=gPCXJ1uqMCKaKPYBW1gFQGvX6Wl5xGKdYvmOa2knnk/FhfGTYdYUeEtK
 J7NCMfzfoNI8kxOve8WT6oCEcUlNg8Q9smXY3ojqigIkH8fTT+r2qizvn
 0WblYoDbd+CoS5luXej6hhyJYSA3qKKxUVybaebY8lEv910TX/HPpdzug s=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: jrYCned0zzmId+3VG51uzDweAkYLKQvprNqgL3yH1dIw8ng0jdhCsTvy25IqzPnpxc4bRNChfr
 Y8Xmx+YTn/ac1cxN7kEjcDL+8SEboZc8wq3Kf3hbwuiEj0npO+0qxWFbX7TkmUAAx5GhYWyRkN
 noiN67KleqeMSoAxSApvDCkzcy0ODUukA56ZKBKld6tHlUdC1PS1RMLxdGrbq9p/v0kam0aniv
 00hfdjBg09FKh4nRPXym0f6CtUJlbLcv/3sJyytjdnVJWcqJLecS+N7odzBYScy+oaqEleLrsM
 /ic=
X-SBRS: 2.7
X-MesageID: 15286998
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15286998"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <qemu-devel@nongnu.org>
Subject: [PATCH for-5.0] xen-block: Fix double qlist remove
Date: Thu, 2 Apr 2020 14:08:19 +0100
Message-ID: <20200402130819.1216125-1-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefano Stabellini <sstabellini@kernel.org>,
 qemu-block@nongnu.org, Paul Durrant <paul@xen.org>, qemu-stable@nongnu.org,
 Max Reitz <mreitz@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>,
 Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
remove") revealed that a request was removed twice from a list, once
in xen_block_finish_request() and a second time in
xen_block_release_request() when both function are called from
xen_block_complete_aio(). But also, the `requests_inflight' counter is
decreased twice, and thus became negative.

This is a bug that was introduced in bfd0d6366043, where a `finished'
list was removed.

This patch simply re-add the `finish' parameter of
xen_block_release_request() so that we can distinguish when we need to
remove a request from the inflight list and when not.

Fixes: bfd0d6366043 ("xen-block: improve response latency")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/block/dataplane/xen-block.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 288a87a814ad..6cc089fc561f 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -123,15 +123,19 @@ static void xen_block_finish_request(XenBlockRequest *request)
     dataplane->requests_inflight--;
 }
 
-static void xen_block_release_request(XenBlockRequest *request)
+static void xen_block_release_request(XenBlockRequest *request, bool finish)
 {
     XenBlockDataPlane *dataplane = request->dataplane;
 
-    QLIST_REMOVE(request, list);
+    if (!finish) {
+        QLIST_REMOVE(request, list);
+    }
     reset_request(request);
     request->dataplane = dataplane;
     QLIST_INSERT_HEAD(&dataplane->freelist, request, list);
-    dataplane->requests_inflight--;
+    if (!finish) {
+        dataplane->requests_inflight--;
+    }
 }
 
 /*
@@ -316,7 +320,7 @@ static void xen_block_complete_aio(void *opaque, int ret)
             error_report_err(local_err);
         }
     }
-    xen_block_release_request(request);
+    xen_block_release_request(request, true);
 
     if (dataplane->more_work) {
         qemu_bh_schedule(dataplane->bh);
@@ -585,7 +589,7 @@ static bool xen_block_handle_requests(XenBlockDataPlane *dataplane)
                     error_report_err(local_err);
                 }
             }
-            xen_block_release_request(request);
+            xen_block_release_request(request, false);
             continue;
         }
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 13:55:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 13:55:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK0JZ-0002gG-NE; Thu, 02 Apr 2020 13:55:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9JfQ=5S=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jK0JY-0002g8-60
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 13:55:24 +0000
X-Inumbo-ID: 94ce3662-74e9-11ea-bbde-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 94ce3662-74e9-11ea-bbde-12813bfff9fa;
 Thu, 02 Apr 2020 13:55:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2ePCXIJS4/lZLKs4gBSoDMmV2Ql5JDeCDMqiOhDJNN0=; b=iV0AXevi5/lLaqTDd1agx2wZA
 9eIyjedWcHrc4QZRi2DcG4lqK8dIp9T6uC9KjjJvWJrfZHnS30QN02qS/k8kaEedi3Vz0LCEE6FQR
 wRZlBPKdgFGOCeyz65XKks95peG8qmMzpBnaxN7QpM+vPuri1eUGrCaTH/sL0joHqc5pY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK0JP-0006oD-RJ; Thu, 02 Apr 2020 13:55:15 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK0JP-0005Tz-5H; Thu, 02 Apr 2020 13:55:15 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jK0JO-0007fU-W0; Thu, 02 Apr 2020 13:55:14 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149314-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149314: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=30d35651816fc044e0559f7f31431fbbd698a0b1
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 02 Apr 2020 13:55:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              30d35651816fc044e0559f7f31431fbbd698a0b1
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   76 days
Failing since        146211  2020-01-18 04:18:52 Z   75 days   72 attempts
Testing same since   149314  2020-04-02 04:19:04 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 12528 lines long.)


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 14:00:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 14:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK0OQ-0003aO-Bp; Thu, 02 Apr 2020 14:00:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=/k1p=5S=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jK0OP-0003aD-OS
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 14:00:25 +0000
X-Inumbo-ID: 4c8363fe-74ea-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x529.google.com (unknown [2a00:1450:4864:20::529])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4c8363fe-74ea-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 14:00:24 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id i16so4191814edy.11
 for <xen-devel@lists.xenproject.org>; Thu, 02 Apr 2020 07:00:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=W2kTrHMHuMppasbECZOZguAiR0e+NxgihS++1XiDv7g=;
 b=TphFknNy6nxLV0xivaaVHo+0Jyhy9kl00RM6L+/7jt3zrflqOMGBzeeZ+Kx6Ihvex1
 Y85Dmx+MR/UkkL34WFHIB9kn7uNxCXDo/GfBVKnGAtW+5/4m4cHNkFBxuWczlj94dB5l
 jPs1dUaMzyRopQBbDp7UWqvU+Qi9Mr+ZVTi61R1RoeDmOpuR4vW4+4Kc+CVrc1IbcZiV
 rfst84bCnqPEe1ALQsMNoQRu6S3qshvWVehLE8huhjM3BN8w/wkEOLUyPcokc06DnUP4
 AGkklANJVJGEjmBf8j/m6rJw8b387GVJyOrxibPg9pA374KugrxetwIpCs4brhm1PNUp
 I4LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :thread-index:content-language;
 bh=W2kTrHMHuMppasbECZOZguAiR0e+NxgihS++1XiDv7g=;
 b=q/MD7pplv0OopJFoHuGXsmM/Gwb2MEez0ExsEAHt5OThhly1ceDzkcZPPd44D11qa0
 CLfdb6WqA80vq628ut/fm1bxfgmOUuN3z0eGjH3Eyg9h3xn7kecj21Cib9WHtslIMTim
 RDLCddNIMINXj+n3ElYTBAAt9GUY4V20QlxG7l2lfAu+mHegraTr6xNzmLOTXrgudyfk
 cfCHCpkLOOfOpEjKem/7+Ac+H1Lq60UpxOtLLGYSQmOOiwiYDm7cDnTjv3GfqMe2FNC5
 IvU+i6qJPzR/jtcdH3KOuOSiP9f23m2AkiCXpWsfNj87FsQuY2SfZz/s2o9xenNK3L/L
 e0EA==
X-Gm-Message-State: AGi0PuYKCP7knBcopjtfHLXVfBK3KokbdTba3ZvY70uXX0d4Vn7gocb1
 1mU1LdeMJQzrc19uP53yECA=
X-Google-Smtp-Source: APiQypL0ra1V+qMPn8oRtc/RPtcl5BX+IL0mAnRHvSf6ehY2c8e2+l9conSVekXn8W3G2f8YDQX/aQ==
X-Received: by 2002:aa7:d781:: with SMTP id s1mr3026465edq.108.1585836023603; 
 Thu, 02 Apr 2020 07:00:23 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id dg9sm957745edb.91.2020.04.02.07.00.22
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 02 Apr 2020 07:00:23 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>,
	"'Julien Grall'" <julien@xen.org>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <e9b21d59-3a4a-1498-e5f4-45d1420ddbc4@suse.com>
 <001201d608d5$513a7490$f3af5db0$@xen.org>
 <fc7ffa50-5648-f335-02a4-1819d826c193@suse.com>
In-Reply-To: <fc7ffa50-5648-f335-02a4-1819d826c193@suse.com>
Subject: RE: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
Date: Thu, 2 Apr 2020 15:00:21 +0100
Message-ID: <001601d608f7$0d6c1620$28444260$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG3I8TZM/MLMEc/e2It3WEXPZVs8AC9qttvAjHRb6QCo/AsTAJpm8RVqGO5h0A=
Content-Language: en-gb
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 02 April 2020 12:08
> To: paul@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper' =
<andrew.cooper3@citrix.com>; 'George Dunlap'
> <george.dunlap@citrix.com>; 'Ian Jackson' <ian.jackson@eu.citrix.com>; =
'Julien Grall'
> <julien@xen.org>; 'Stefano Stabellini' <sstabellini@kernel.org>; 'Wei =
Liu' <wl@xen.org>
> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for =
save/restore of 'domain' context
>=20
> On 02.04.2020 11:58, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: 01 April 2020 15:51
> >> To: Paul Durrant <paul@xen.org>
> >> Cc: xen-devel@lists.xenproject.org; Andrew Cooper =
<andrew.cooper3@citrix.com>; George Dunlap
> >> <george.dunlap@citrix.com>; Ian Jackson =
<ian.jackson@eu.citrix.com>; Julien Grall <julien@xen.org>;
> >> Stefano Stabellini <sstabellini@kernel.org>; Wei Liu <wl@xen.org>
> >> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for =
save/restore of 'domain' context
> >>
> >> On 27.03.2020 19:50, Paul Durrant wrote:
> >>> Domain context is state held in the hypervisor that does not come =
under
> >>> the category of 'HVM state' but is instead 'PV state' that is =
common
> >>> between PV guests and enlightened HVM guests (i.e. those that have =
PV
> >>> drivers) such as event channel state, grant entry state, etc.
> >>
> >> Without looking at the patch details yet, I'm having some =
difficulty
> >> understanding how this is going to work in a safe/correct manner. I
> >> suppose for LU the system is in a frozen enough state that
> >> snapshotting and copying state like this is okay, but ...
> >>
> >>> To allow enlightened HVM guests to be migrated without their =
co-operation
> >>> it will be necessary to transfer such state along with the =
domain's
> >>> memory image, architectural state, etc. This framework is =
introduced for
> >>> that purpose.
> >>>
> >>> This patch adds the new public header and the low level =
implementation,
> >>> entered via the domain_save() or domain_load() functions. =
Subsequent
> >>> patches will introduce other parts of the framwork, and code that =
will
> >>> make use of it within the current version of the libxc migration =
stream.
> >>
> >> ... here you suggest (and patch 5 appears to match this) that this
> >> is going to be used even in "normal" migration streams.
> >
> > Well, 'transparent' (or non-cooperative) migration will only work in =
some cases but it definitely
> does work.
> >
> >> All of the
> >> items named are communication vehicles, and hence there are always
> >> two sides that can influence the state. For event channels, the
> >> other side (which isn't paused) or the hardware (for passed through
> >> devices) might signal them, or it (just the former obviously) could
> >> close their end, resulting in a state change also for the domain
> >> being migrated. If this happens after the snapshot was taken, the
> >> state change is lost.
> >
> > Indeed, which is why we *do* rely on co-operation from the other end
> > of the event channels in the migration case. In the initial case it
> > is likely we'll veto transparent migration unless all event channels
> > are connected to either dom0 or Xen.
>=20
> Co-operation for "normal" migration, iirc, consists of tearing down
> and re-establishing everything. There's simply no risk of losing e.g.
> events this way.

No, indeed, everything basically has to be re-established from scratch =
for normal migration. Transparent migration, as it is implemented at the =
moment, does rely on injecting potentially spurious events on resume. I =
think the alternative would be to have the PV backends send an event =
when they re-connect to a shared ring rather than having Xen do it.

>=20
> >> Otoh I'm sure the case was considered, so perhaps I'm simply =
missing
> >> some crucial aspect (which then could do with spelling out in the
> >> description of the cover letter).
> >>
> >
> > Does that need to be explained for a series that is just
> > infrastructure?
>=20
> I think so, yes - this infrastructure is pointless to introduce if
> it doesn't allow fulfilling all requirements. Pointing at the design
> doc (in the cover letter) may be enough if all aspects are covered
> by what's there. I wouldn't have assumed using this infrastructure
> also for co-operative migration to also be mentioned there.

No, I can mention the plan to use it to replace existing libxc migration =
records in the cover letter even though it is stated in the comment for =
patch #5.

>=20
> Considering the situation with event channels (all closed), doing
> what you do for the shared info page is probably going to be fine;
> large parts of it are in a known state (or need re-filling on the
> destination) anyway. What other plans do you have for non-LU
> migration wrt this new infrastructure?

Well, as discussed above, event channels are one, then there's the grant =
table. The downstream code as a record for the wallclock but I think the =
RTC covers that now that added the code to preserve the offset. We also =
have records for vcpu timers and runstate, but I'm not convinced we =
actually need those.

> If the shared info page is
> all that's going to get migrated with its help, I'd wonder whether
> the infrastructure wasn't better conditional upon a LU config
> option, and the shared info migration was left as it is now.
>=20

The shared info is also migrated for HVM guests so it would have meant =
moving the mapping code around anyway, thus it seems sensible to use the =
new domain context for that for PV guests in their normal migration =
stream anyway.

  Paul



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 14:25:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 14:25:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK0mY-0005KU-Jz; Thu, 02 Apr 2020 14:25:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK0mX-0005KP-MK
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 14:25:21 +0000
X-Inumbo-ID: c819ff5c-74ed-11ea-bbf0-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c819ff5c-74ed-11ea-bbf0-12813bfff9fa;
 Thu, 02 Apr 2020 14:25:20 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 34489AC26;
 Thu,  2 Apr 2020 14:25:19 +0000 (UTC)
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: fix a use after free problem
 in xenstored
To: xen-devel@lists.xenproject.org
References: <20200324101257.20781-1-jgross@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <1599c563-483c-05e1-9dc7-2d2ddf10d9c7@suse.com>
Date: Thu, 2 Apr 2020 16:25:18 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200324101257.20781-1-jgross@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Ping?

On 24.03.20 11:12, Juergen Gross wrote:
> Commit 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object
> twice") introduced a potential use after free problem in
> domain_cleanup(): after calling talloc_unlink() for domain->conn
> domain->conn is set to NULL. The problem is that domain is registered
> as talloc child of domain->conn, so it might be freed by the
> talloc_unlink() call.
> 
> Fixes: 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object twice")
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>   tools/xenstore/xenstored_domain.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index baddaba5df..5858185211 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -214,6 +214,7 @@ static void domain_cleanup(void)
>   {
>   	xc_dominfo_t dominfo;
>   	struct domain *domain;
> +	struct connection *conn;
>   	int notify = 0;
>   
>    again:
> @@ -230,8 +231,10 @@ static void domain_cleanup(void)
>   				continue;
>   		}
>   		if (domain->conn) {
> -			talloc_unlink(talloc_autofree_context(), domain->conn);
> +			/* domain is a talloc child of domain->conn. */
> +			conn = domain->conn;
>   			domain->conn = NULL;
> +			talloc_unlink(talloc_autofree_context(), conn);
>   			notify = 0; /* destroy_domain() fires the watch */
>   			goto again;
>   		}
> 



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 14:25:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 14:25:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK0mw-0005MZ-1u; Thu, 02 Apr 2020 14:25:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK0mu-0005MG-3T
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 14:25:44 +0000
X-Inumbo-ID: d5625c72-74ed-11ea-b4f4-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d5625c72-74ed-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 14:25:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585837543;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=xkRIIxCDsnHRvzf//DqSS43klv06BRzh7Vz62kSJN2w=;
 b=h3pNGXf1vnpqpac6lMDBABsqd/AUN9v5B1hfSS38pnmd80WfMxIwxj0K
 SmzMmd/FcC0LDTCFGUQOg+VbIFyVK0HOfpsAPXXWjFNEe0/Kg75c995N0
 zopBIcgVWbzu8XbVjoWdwiMRFiT3Q3NjmrZm0NglE66qPCqluoG+ZJRqQ 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: kOefqFcTLPMd+GxgH9pEleIj1vPfcPQQoSu1pTWKywyACARgB90j8Aq29dLg9q0NigJabKXtG1
 YL6irxmk5V0wZuVUrT6DubL7+Cj9ZVgnJe8grdBrmOhM/+GlQxIDQcE/VXrtIEhlyByiM7Cmo0
 AtdM3BuBNV2aO57F5amD2DZhg9L6z0ytkPUMUwiHSJ7SBj8w/C0MfLP4c9qAl54KsZRq6+Qhah
 M15Ft4cPBaNPID/HZJ75BricJ/YDGfbtVgO3Y/IMuo4uy/OZya96TR0RSzdog2/MdPudjrbdHn
 qoA=
X-SBRS: 2.7
X-MesageID: 15056056
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,335,1580792400"; d="scan'208";a="15056056"
Subject: Re: [PATCH v4] x86: clear RDRAND CPUID bit on AMD family 15h/16h
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <69382ba7-b562-2c8c-1843-b17ce6c512f1@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <68aa71c6-a41b-9f7c-f3ca-94060fae5db0@citrix.com>
Date: Thu, 2 Apr 2020 15:25:37 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <69382ba7-b562-2c8c-1843-b17ce6c512f1@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul
 Durrant <Paul.Durrant@citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09/03/2020 09:08, Jan Beulich wrote:
> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
>
>     There have been reports of RDRAND issues after resuming from suspend on
>     some AMD family 15h and family 16h systems. This issue stems from a BIOS
>     not performing the proper steps during resume to ensure RDRAND continues
>     to function properly.
>
>     Update the CPU initialization to clear the RDRAND CPUID bit for any family
>     15h and 16h processor that supports RDRAND. If it is known that the family
>     15h or family 16h system does not have an RDRAND resume issue or that the
>     system will not be placed in suspend, the "cpuid=rdrand" kernel parameter

I'm not sure what is best to do here.  The type suggests that this is a
verbatim copy of the Linux commit message, but this tiny detail is Xen
specific.

>     can be used to stop the clearing of the RDRAND CPUID bit.
>
>     Note, that clearing the RDRAND CPUID bit does not prevent a processor
>     that normally supports the RDRAND instruction from executing it. So any
>     code that determined the support based on family and model won't #UD.
>
> Warn if no explicit choice was given on affected hardware.
>
> Check RDRAND functions at boot as well as after S3 resume (the retry
> limit chosen is entirely arbitrary).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

CC'ing Paul & George for 4.14 things:

tl;dr Some AMD system firmware doesn't reinitialise the RNG
configuration on S3, resulting in the RDRAND instruction returning -1
and "data good".

AMD's recommended mitigation is to disable RDRAND entirely.  We can't
identify the problem before an S3 resume and finding the instruction
broken, and can't repair the damage at that point (The MSR needing
fixing has already been locked), and AMD don't have a list of DMI
quirks/equivalent to use to identify the buggy systems on boot.

Also, there is no public statement from AMD on the matter, but one
obvious fallout on Linux systems is systemd looping forever trying to
create a UUID which doesn't already alias in its database.

The impact of this would be substantially less bad if Xen could identify
(a lack of) platform support for S3 at boot, as AMD servers have never
supported S3.  This would reduce the user-nagging to only client
systems, but there isn't an obvious way to do this.

It's a complete mess, but I don't think we should put this out without
some form of release note.

> ---
> Still slightly RFC, and still in particular because of the change to
> parse_xen_cpuid():

FWIW, that is very similar to XenServer's AVX512 off-by-default bodge
until the default vs max policy work is ready.

I don't have a better suggestion right now, but hopefully something
better might become obvious when we've got more users.  Either way, I'm
expecting it to turn into a "switch ( mid->bit )" expression in due course.

> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -4,6 +4,7 @@
>  #include <xen/param.h>
>  #include <xen/smp.h>
>  #include <xen/pci.h>
> +#include <xen/warning.h>
>  #include <asm/io.h>
>  #include <asm/msr.h>
>  #include <asm/processor.h>
> @@ -646,6 +647,25 @@ static void init_amd(struct cpuinfo_x86
>  		if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value))
>  			amd_acpi_c1e_quirk = true;
>  		break;
> +
> +	case 0x15: case 0x16:
> +		/*
> +		 * There are too many Fam15/Fam16 systems where upon resume

"some" systems.

> +		 * from S3 firmware fails to re-setup properly functioning
> +		 * RDRAND.

I think this needs another sentence of explanation.

By the time we can spot the problem, it is too late to take evasive
action, and there is nothing Xen can do to repair the problem.

>   Clear the feature unless force-enabled on the
> +		 * command line.
> +		 */
> +		if (c == &boot_cpu_data &&
> +		    cpu_has(c, X86_FEATURE_RDRAND) &&
> +		    !is_forced_cpu_cap(X86_FEATURE_RDRAND)) {
> +			static const char __initconst text[] =
> +				"RDRAND may cease to work on this hardware upon resume from S3.\n"
> +				"Please choose an explicit cpuid={no-}rdrand setting.\n";
> +
> +			setup_clear_cpu_cap(X86_FEATURE_RDRAND);
> +			warning_add(text);

What do you think to clobbering RDRAND via the CPUMASK registers in this
case?  We've got full control there, and it would stop PV userspace as well.

> +		}
> +		break;
>  	}
>  
>  	display_cacheinfo(c);
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -11,6 +11,7 @@
>  #include <asm/io.h>
>  #include <asm/mpspec.h>
>  #include <asm/apic.h>
> +#include <asm/random.h>
>  #include <asm/setup.h>
>  #include <mach_apic.h>
>  #include <public/sysctl.h> /* for XEN_INVALID_{SOCKET,CORE}_ID */
> @@ -98,6 +99,11 @@ void __init setup_force_cpu_cap(unsigned
>  	__set_bit(cap, boot_cpu_data.x86_capability);
>  }
>  
> +bool is_forced_cpu_cap(unsigned int cap)
> +{
> +	return test_bit(cap, forced_caps);
> +}
> +
>  static void default_init(struct cpuinfo_x86 * c)
>  {
>  	/* Not much we can do here... */
> @@ -498,6 +504,28 @@ void identify_cpu(struct cpuinfo_x86 *c)
>  	printk("\n");
>  #endif
>  
> +	/*
> +	 * If RDRAND is available, make an attempt to check that it actually
> +	 * (still) works.
> +	 */

Do you think it would be helpful to test in the opposite case as well. 
If we come back from S3 and find that RDRAND does actually work, then it
is safe to tell the user that they can re-enable.

> +	if (cpu_has(c, X86_FEATURE_RDRAND)) {
> +		unsigned int prev = 0;
> +
> +		for (i = 0; i < 5; ++i)
> +		{
> +			unsigned int cur = arch_get_random();
> +
> +			if (prev && cur != prev)
> +				break;
> +			prev = cur;
> +			cpu_relax();

Why the relax?  We're not polling hammering the memory bus waiting for
an unknown period of time until something changes.

We simply need up to 5 random numbers as fast as the RNG can produce
them (which is actually quite slow.  RDRAND has ~350 cycle latency minimum.)

~Andrew

> +		}
> +
> +		if (i >= 5)
> +			printk(XENLOG_WARNING "CPU%u: RDRAND appears to not work\n",
> +			       smp_processor_id());
> +	}
> +
>  	if (system_state == SYS_STATE_resume)
>  		return;
>  



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 14:27:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 14:27:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK0oZ-0005XJ-Er; Thu, 02 Apr 2020 14:27:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=/k1p=5S=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jK0oY-0005XA-Le
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 14:27:26 +0000
X-Inumbo-ID: 12cd16c4-74ee-11ea-9e09-bc764e2007e4
Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 12cd16c4-74ee-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 14:27:25 +0000 (UTC)
Received: by mail-ed1-x541.google.com with SMTP id cw6so4348760edb.9
 for <xen-devel@lists.xenproject.org>; Thu, 02 Apr 2020 07:27:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=Gs5s/AzhrQY0MsAWHGCRh7EB5NuuIAx0gTTvncvqfKE=;
 b=gl/EXqahrI3LZRtHXzm7a3z4YJSAdAf27Dc661ub6stokk89cDWUnY7bjUvrGkf96I
 7i/EpB1jiIhkF67ojeY504MXIylH+M4bqUEgn60r3uZd/Oz2etLzEqQ2IaC1+86fhywE
 397kvjfV7wS+/SB1TCSZA5OceOj9TuDjDv92KhtEOAvUYW7744++uJD2GEkpLZRGnvsA
 WL0WovrXoZrfzthEJNHU5W+ywHscfycTaIWJKuAkBvAl1Bnbjv8QCn9Rc7zMoFFkRQOM
 vrxPAn9E707ugzCon5b4FR8a+rOavXIKCvpqmF5J32A3n0Tn4zS78gC2Rsv6uH8oUBSA
 tfPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :thread-index:content-language;
 bh=Gs5s/AzhrQY0MsAWHGCRh7EB5NuuIAx0gTTvncvqfKE=;
 b=ZcEfBtNuLTxegM9UK28IwKsewNes+bVBWDQD4mQL5FG1uctxkNy/fkJXBSY8uahS1I
 P6RUTYOw086QIzEKyqBcNR8Ja9sICZbGYKC1AZbXdedWSACk2R876+lh3q4+qjk/W7o+
 H7XVAjDDx/Tz7mpMpI6R3lVpvWZPZMswCtFGhGiuSSYc6kd6Y0bhs/7MDOLa0QxdpsTj
 RzIJvPJTYvj3v2dNLSc1epxSBDFq3mIoX30rh80zDMdSH4K7oSW6pkitwi6i9JWwJrVf
 9w8fMYFK9sfq4vPRRQ+Du/AHbIcTsoxsqmMQW6eKq1fRDZhO18XZuwoOk6W9GLP32q18
 04Dg==
X-Gm-Message-State: AGi0PubjvizIc+wXf314vCFIET65Oc9mWhnia3LpZS/c7Gv6O5DJG3W3
 l5h3gRpeWx/+DDT7qsqHreQ=
X-Google-Smtp-Source: APiQypLuaThFpCbWKxMrtN/Q9dMNyMZEUOQLRr9AFvW3LtVMOz1qHh5CqF8QMja/YifoHG5k6yQl8w==
X-Received: by 2002:a17:906:eddb:: with SMTP id
 sb27mr3610618ejb.207.1585837645042; 
 Thu, 02 Apr 2020 07:27:25 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id f18sm1127971ejt.25.2020.04.02.07.27.23
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 02 Apr 2020 07:27:24 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Anthony PERARD'" <anthony.perard@citrix.com>,
	<qemu-devel@nongnu.org>
References: <20200402130819.1216125-1-anthony.perard@citrix.com>
In-Reply-To: <20200402130819.1216125-1-anthony.perard@citrix.com>
Subject: RE: [PATCH for-5.0] xen-block: Fix double qlist remove
Date: Thu, 2 Apr 2020 15:27:22 +0100
Message-ID: <001801d608fa$d3f0d3f0$7bd27bd0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLmjVOS2S5Ry01+8mL39/r4UrwBIqZE2WIQ
Content-Language: en-gb
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Kevin Wolf' <kwolf@redhat.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>, qemu-block@nongnu.org,
 qemu-stable@nongnu.org, 'Max Reitz' <mreitz@redhat.com>,
 'Stefan Hajnoczi' <stefanha@redhat.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Anthony PERARD <anthony.perard@citrix.com>
> Sent: 02 April 2020 14:08
> To: qemu-devel@nongnu.org
> Cc: qemu-stable@nongnu.org; Anthony PERARD <anthony.perard@citrix.com>; Stefano Stabellini
> <sstabellini@kernel.org>; Paul Durrant <paul@xen.org>; Stefan Hajnoczi <stefanha@redhat.com>; Kevin
> Wolf <kwolf@redhat.com>; Max Reitz <mreitz@redhat.com>; xen-devel@lists.xenproject.org; qemu-
> block@nongnu.org
> Subject: [PATCH for-5.0] xen-block: Fix double qlist remove
> 
> Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
> remove") revealed that a request was removed twice from a list, once
> in xen_block_finish_request() and a second time in
> xen_block_release_request() when both function are called from
> xen_block_complete_aio(). But also, the `requests_inflight' counter is
> decreased twice, and thus became negative.
> 
> This is a bug that was introduced in bfd0d6366043, where a `finished'
> list was removed.
> 
> This patch simply re-add the `finish' parameter of
> xen_block_release_request() so that we can distinguish when we need to
> remove a request from the inflight list and when not.
> 
> Fixes: bfd0d6366043 ("xen-block: improve response latency")
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

It looks to me like it would just be more straightforward to simply drop the QLIST_REMOVE and requests_inflight-- from
xen_block_release_request() and simply insist that xen_block_finish_request() is called in all cases (which I think means adding one
extra call to it in xen_block_handle_requests()).

  Paul

> ---
>  hw/block/dataplane/xen-block.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
> index 288a87a814ad..6cc089fc561f 100644
> --- a/hw/block/dataplane/xen-block.c
> +++ b/hw/block/dataplane/xen-block.c
> @@ -123,15 +123,19 @@ static void xen_block_finish_request(XenBlockRequest *request)
>      dataplane->requests_inflight--;
>  }
> 
> -static void xen_block_release_request(XenBlockRequest *request)
> +static void xen_block_release_request(XenBlockRequest *request, bool finish)
>  {
>      XenBlockDataPlane *dataplane = request->dataplane;
> 
> -    QLIST_REMOVE(request, list);
> +    if (!finish) {
> +        QLIST_REMOVE(request, list);
> +    }
>      reset_request(request);
>      request->dataplane = dataplane;
>      QLIST_INSERT_HEAD(&dataplane->freelist, request, list);
> -    dataplane->requests_inflight--;
> +    if (!finish) {
> +        dataplane->requests_inflight--;
> +    }
>  }
> 
>  /*
> @@ -316,7 +320,7 @@ static void xen_block_complete_aio(void *opaque, int ret)
>              error_report_err(local_err);
>          }
>      }
> -    xen_block_release_request(request);
> +    xen_block_release_request(request, true);
> 
>      if (dataplane->more_work) {
>          qemu_bh_schedule(dataplane->bh);
> @@ -585,7 +589,7 @@ static bool xen_block_handle_requests(XenBlockDataPlane *dataplane)
>                      error_report_err(local_err);
>                  }
>              }
> -            xen_block_release_request(request);
> +            xen_block_release_request(request, false);
>              continue;
>          }
> 
> --
> Anthony PERARD




From xen-devel-bounces@lists.xenproject.org Thu Apr 02 14:58:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 14:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK1IY-0007zX-51; Thu, 02 Apr 2020 14:58:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK1IW-0007zN-GQ
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 14:58:24 +0000
X-Inumbo-ID: 660b528e-74f2-11ea-b4f4-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 660b528e-74f2-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 14:58:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585839503;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=bNsByaUJDBzaiwE/jquFDrTeBFFX1Nymgn11ncNpHJ8=;
 b=a/WAGPkrShevz4Kj/plF/SU2dpFL45QBFTiW6i1ZziLrEv2bd/tqAavs
 i6gSw+/U9wK+nblTrRLUjbCOY/gRS2uupMitwH1IERnKhDS3a+Sg1r2C6
 9YaMoNSN7XDValBY0kl6leXZs/4ttuxZCnXCNJhctA5iw45MsH2Eko6vr E=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: OKkuyVzuuGQDqwWV1Jp1QdWrZQF2yBnwamIE4C1KESb8GeavZ6qYD7fy1Ttz4hkG6F7kOOANzP
 SARQ3LzLYFEz7+DKtF4ND8L2YLnrycekX7vLC9qiFYv/Hf0qC0ZCZk4g+7vw53oGRGL+miwXRM
 Wpvi2pntPFZwIevHuqj5VVhHBCysQKzsD/5yk3vn8DYQCEe58PI99J2sQFTx9bn4EqAZcES2Kr
 uuc6ex71SvRqDI5/1lqTtiLebbohLcdtVVhAApOhgWTWHSmcPOT4v0aJgJss/J6gHyZIANkw/n
 F3E=
X-SBRS: 2.7
X-MesageID: 15733647
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,336,1580792400"; d="scan'208";a="15733647"
Subject: Re: [PATCH v2 0/2] x86/cpuidle: Cannon Lake adjustments
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <e39d4326-57d1-a4b5-3081-76b5160644ae@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <afe81b7e-4895-89ee-49dd-b6c0130923a1@citrix.com>
Date: Thu, 2 Apr 2020 15:58:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <e39d4326-57d1-a4b5-3081-76b5160644ae@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02/04/2020 09:22, Jan Beulich wrote:
> As requested in reply to v1, this is now a pair of patches with
> the expectation that only patch 1 would be acked and go in.
>
> 1: drop Cannon Lake support
> 2: support Cannon Lake (again)

Dropping Cannon Lake support is only of any incremental benefit if we
drop it from everywhere, and I didn't mean to block this single patch on it.

Consider either A-by.

However, it would be helpful to consider what we could do for better
KCONFIG-able CPU support.

Some downstreams have a separate build for each platform, and some go as
far as cramming Xen into the boot SPI ROM, so space saving is a very
important aspect.

On a different front, being able to compile out support for CPUs without
VMX unrestricted mode, or without CMPXCHG16B would be helpful.

I would certainly like to get CONFIG_{INTEL,AMD} usable even if only so
randconfig can help keep our interfaces clean.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:26:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:26:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK1jr-000213-RB; Thu, 02 Apr 2020 15:26:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9JfQ=5S=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jK1jr-00020y-AH
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:26:39 +0000
X-Inumbo-ID: 53ce8da8-74f6-11ea-bbfd-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 53ce8da8-74f6-11ea-bbfd-12813bfff9fa;
 Thu, 02 Apr 2020 15:26:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=u6TjaBrqmTdJm6m8eL2WHQTZ+3vidyzEI3HCjArhIk0=; b=Kn2qOFD3GPtEpgz/B45eRgNZK
 dA2FmH8g9EhEqmsO9yyY/PwHteGJjbvm4r/jtwfcLVmYjX153RjloInv49dIrEC8jH93qPC1fpm0W
 UusC09Xw2mEHlK73aJcYnWEik+ZOosfguG9tnbhwLqIVfj5Twy7975xJ1GVC7KD8GvY0U=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK1ji-0000BN-9J; Thu, 02 Apr 2020 15:26:30 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK1ji-0003v1-2k; Thu, 02 Apr 2020 15:26:30 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jK1ji-0003iV-23; Thu, 02 Apr 2020 15:26:30 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149303-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149303: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-amd:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=2833ad487cfff7dc33703e4731b75facde1c561e
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 02 Apr 2020 15:26:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-freebsd10-i386 11 guest-start            fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-freebsd10-amd64 11 guest-start           fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-amd 18 guest-localmigrate/x10 fail baseline untested
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 144861
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                2833ad487cfff7dc33703e4731b75facde1c561e
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  108 days
Failing since        144880  2019-12-16 20:07:08 Z  107 days  317 attempts
Testing same since   149264  2020-04-01 02:32:20 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 56117 lines long.)


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK22y-0003ic-5W; Thu, 02 Apr 2020 15:46:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK22w-0003iR-W3
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:23 +0000
X-Inumbo-ID: 198f33e2-74f9-11ea-bc01-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 198f33e2-74f9-11ea-bc01-12813bfff9fa;
 Thu, 02 Apr 2020 15:46:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DBFF9AE39;
 Thu,  2 Apr 2020 15:46:19 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 01/12] xen/vmx: let opt_ept_ad always reflect the current
 setting
Date: Thu,  2 Apr 2020 17:46:05 +0200
Message-Id: <20200402154616.16927-2-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Kevin Tian <kevin.tian@intel.com>,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In case opt_ept_ad has not been set explicitly by the user via command
line or runtime parameter, it is treated as "no" on Avoton cpus.

Change that handling by setting opt_ept_ad to 0 for this cpu type
explicitly if no user value has been set.

By putting this into the (renamed) boot time initialization of vmcs.c
_vmx_cpu_up() can be made static.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/arch/x86/hvm/vmx/vmcs.c        | 22 +++++++++++++++-------
 xen/arch/x86/hvm/vmx/vmx.c         |  4 +---
 xen/include/asm-x86/hvm/vmx/vmcs.h |  3 +--
 3 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 4c23645454..24f2bd6e43 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -315,10 +315,6 @@ static int vmx_init_vmcs_config(void)
 
         if ( !opt_ept_ad )
             _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
-        else if ( /* Work around Erratum AVR41 on Avoton processors. */
-                  boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
-                  opt_ept_ad < 0 )
-            _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
 
         /*
          * Additional sanity checking before using EPT:
@@ -652,7 +648,7 @@ void vmx_cpu_dead(unsigned int cpu)
     vmx_pi_desc_fixup(cpu);
 }
 
-int _vmx_cpu_up(bool bsp)
+static int _vmx_cpu_up(bool bsp)
 {
     u32 eax, edx;
     int rc, bios_locked, cpu = smp_processor_id();
@@ -2108,9 +2104,21 @@ static void vmcs_dump(unsigned char ch)
     printk("**************************************\n");
 }
 
-void __init setup_vmcs_dump(void)
+int __init vmx_vmcs_init(void)
 {
-    register_keyhandler('v', vmcs_dump, "dump VT-x VMCSs", 1);
+    int ret;
+
+    if ( opt_ept_ad < 0 )
+        /* Work around Erratum AVR41 on Avoton processors. */
+        opt_ept_ad = (boot_cpu_data.x86 == 6 &&
+                      boot_cpu_data.x86_model == 0x4d) ? 0 : 1;
+
+    ret = _vmx_cpu_up(true);
+
+    if ( !ret )
+        register_keyhandler('v', vmcs_dump, "dump VT-x VMCSs", 1);
+
+    return ret;
 }
 
 static void __init __maybe_unused build_assertions(void)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 1c398fdb6e..05e99f4bee 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2478,7 +2478,7 @@ const struct hvm_function_table * __init start_vmx(void)
 {
     set_in_cr4(X86_CR4_VMXE);
 
-    if ( _vmx_cpu_up(true) )
+    if ( vmx_vmcs_init() )
     {
         printk("VMX: failed to initialise.\n");
         return NULL;
@@ -2549,8 +2549,6 @@ const struct hvm_function_table * __init start_vmx(void)
         vmx_function_table.get_guest_bndcfgs = vmx_get_guest_bndcfgs;
     }
 
-    setup_vmcs_dump();
-
     lbr_tsx_fixup_check();
     bdf93_fixup_check();
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 95c1dea7b8..906810592f 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -21,11 +21,10 @@
 #include <xen/mm.h>
 
 extern void vmcs_dump_vcpu(struct vcpu *v);
-extern void setup_vmcs_dump(void);
+extern int vmx_vmcs_init(void);
 extern int  vmx_cpu_up_prepare(unsigned int cpu);
 extern void vmx_cpu_dead(unsigned int cpu);
 extern int  vmx_cpu_up(void);
-extern int  _vmx_cpu_up(bool bsp);
 extern void vmx_cpu_down(void);
 
 struct vmcs_struct {
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK22x-0003iW-Tb; Thu, 02 Apr 2020 15:46:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK22w-0003iM-Hp
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:22 +0000
X-Inumbo-ID: 19875c3a-74f9-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 19875c3a-74f9-11ea-83d8-bc764e2007e4;
 Thu, 02 Apr 2020 15:46:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D4755AE37;
 Thu,  2 Apr 2020 15:46:19 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 02/12] xen: add a generic way to include binary files as
 variables
Date: Thu,  2 Apr 2020 17:46:06 +0200
Message-Id: <20200402154616.16927-3-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add a new script xen/tools/binfile for including a binary file at build
time being usable via a pointer and a size variable in the hypervisor.

Make use of that generic tool in xsm.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
---
V3:
- new patch

V4:
- add alignment parameter (Jan Beulich)
- use .Lend instead of . (Jan Beulich)
---
 .gitignore                   |  1 +
 xen/tools/binfile            | 41 +++++++++++++++++++++++++++++++++++++++++
 xen/xsm/flask/Makefile       |  5 ++++-
 xen/xsm/flask/flask-policy.S | 16 ----------------
 4 files changed, 46 insertions(+), 17 deletions(-)
 create mode 100755 xen/tools/binfile
 delete mode 100644 xen/xsm/flask/flask-policy.S

diff --git a/.gitignore b/.gitignore
index 4ca679ddbc..b2624df79a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -313,6 +313,7 @@ xen/test/livepatch/*.livepatch
 xen/tools/kconfig/.tmp_gtkcheck
 xen/tools/kconfig/.tmp_qtcheck
 xen/tools/symbols
+xen/xsm/flask/flask-policy.S
 xen/xsm/flask/include/av_perm_to_string.h
 xen/xsm/flask/include/av_permissions.h
 xen/xsm/flask/include/class_to_string.h
diff --git a/xen/tools/binfile b/xen/tools/binfile
new file mode 100755
index 0000000000..7bb35a5178
--- /dev/null
+++ b/xen/tools/binfile
@@ -0,0 +1,41 @@
+#!/bin/sh
+# usage: binfile [-i] [-a <align>] <target-src.S> <binary-file> <varname>
+# -a <align>  align data at 2^<align> boundary (default: byte alignment)
+# -i          add to .init.rodata (default: .rodata) section
+
+section=""
+align=0
+
+OPTIND=1
+while getopts "ia:" opt; do
+    case "$opt" in
+    i)
+        section=".init"
+        ;;
+    a)
+        align=$OPTARG
+        ;;
+    esac
+done
+
+target=$1
+binsource=$2
+varname=$3
+
+cat <<EOF >$target
+#include <asm/asm_defns.h>
+
+        .section $section.rodata, "a", %progbits
+
+        .p2align $align
+        .global $varname
+$varname:
+        .incbin "$binsource"
+.Lend:
+
+        .type $varname, %object
+        .size $varname, .Lend - $varname
+
+        .global ${varname}_size
+        ASM_INT(${varname}_size, .Lend - $varname)
+EOF
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index b1fd454219..5dc2659859 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -30,6 +30,9 @@ $(AV_H_FILES): $(AV_H_DEPEND)
 obj-bin-$(CONFIG_XSM_FLASK_POLICY) += flask-policy.o
 flask-policy.o: policy.bin
 
+flask-policy.S: $(XEN_ROOT)/xen/tools/binfile
+	$(XEN_ROOT)/xen/tools/binfile -i $@ policy.bin xsm_flask_init_policy
+
 FLASK_BUILD_DIR := $(CURDIR)
 POLICY_SRC := $(FLASK_BUILD_DIR)/xenpolicy-$(XEN_FULLVERSION)
 
@@ -39,4 +42,4 @@ policy.bin: FORCE
 
 .PHONY: clean
 clean::
-	rm -f $(ALL_H_FILES) *.o $(DEPS_RM) policy.* $(POLICY_SRC)
+	rm -f $(ALL_H_FILES) *.o $(DEPS_RM) policy.* $(POLICY_SRC) flask-policy.S
diff --git a/xen/xsm/flask/flask-policy.S b/xen/xsm/flask/flask-policy.S
deleted file mode 100644
index d38aa39964..0000000000
--- a/xen/xsm/flask/flask-policy.S
+++ /dev/null
@@ -1,16 +0,0 @@
-#include <asm/asm_defns.h>
-
-        .section .init.rodata, "a", %progbits
-
-/* const unsigned char xsm_flask_init_policy[] __initconst */
-        .global xsm_flask_init_policy
-xsm_flask_init_policy:
-        .incbin "policy.bin"
-.Lend:
-
-        .type xsm_flask_init_policy, %object
-        .size xsm_flask_init_policy, . - xsm_flask_init_policy
-
-/* const unsigned int __initconst xsm_flask_init_policy_size */
-        .global xsm_flask_init_policy_size
-        ASM_INT(xsm_flask_init_policy_size, .Lend - xsm_flask_init_policy)
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK232-0003j4-Ex; Thu, 02 Apr 2020 15:46:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK231-0003it-HQ
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:27 +0000
X-Inumbo-ID: 198ef396-74f9-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 198ef396-74f9-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 15:46:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D2AB2AC44;
 Thu,  2 Apr 2020 15:46:19 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 03/12] docs: add feature document for Xen hypervisor
 sysfs-like support
Date: Thu,  2 Apr 2020 17:46:07 +0200
Message-Id: <20200402154616.16927-4-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.

In the beginning there should only be basic support: entries can be
added from the hypervisor itself only, there is a simple hypercall
interface to read the data.

Add a feature document for setting the base of a discussion regarding
the desired functionality and the entries to add.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
---
V1:
- remove the "--" prefixes of the sub-commands of the user tool
  (Jan Beulich)
- rename xenfs to xenhypfs (Jan Beulich)
- add "tree" and "write" options to user tool

V2:
- move example tree to the paths description (Ian Jackson)
- specify allowed characters for keys and values (Ian Jackson)

V3:
- correct introduction (writable entries)

V4:
- add list specification
- add entry example (Julien Grall)
- correct date and Xen version (Julien Grall)
- add ARM64 as possible architecture (Julien Grall)
- add version description to the feature doc (Jan Beulich)
---
 docs/features/hypervisorfs.pandoc |  92 +++++++++++++++++++++++++++++++++
 docs/misc/hypfs-paths.pandoc      | 105 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 197 insertions(+)
 create mode 100644 docs/features/hypervisorfs.pandoc
 create mode 100644 docs/misc/hypfs-paths.pandoc

diff --git a/docs/features/hypervisorfs.pandoc b/docs/features/hypervisorfs.pandoc
new file mode 100644
index 0000000000..a0a0ead057
--- /dev/null
+++ b/docs/features/hypervisorfs.pandoc
@@ -0,0 +1,92 @@
+% Hypervisor FS
+% Revision 1
+
+\clearpage
+
+# Basics
+---------------- ---------------------
+         Status: **Supported**
+
+  Architectures: all
+
+     Components: Hypervisor, toolstack
+---------------- ---------------------
+
+# Overview
+
+The Hypervisor FS is a hierarchical name-value store for reporting
+information to guests, especially dom0. It is similar to the Linux
+kernel's sysfs. Entries and directories are created by the hypervisor,
+while the toolstack is able to use a hypercall to query the entry
+values or (if allowed by the hypervisor) to modify them.
+
+# User details
+
+With:
+
+    xenhypfs ls <path>
+
+the user can list the entries of a specific path of the FS. Using:
+
+    xenhypfs cat <path>
+
+the content of an entry can be retrieved. Using:
+
+    xenhypfs write <path> <string>
+
+a writable entry can be modified. With:
+
+    xenhypfs tree
+
+the complete Hypervisor FS entry tree can be printed.
+
+The FS paths are documented in `docs/misc/hypfs-paths.pandoc`.
+
+# Technical details
+
+Access to the hypervisor filesystem is done via the stable new hypercall
+__HYPERVISOR_filesystem_op. This hypercall supports a sub-command
+XEN_HYPFS_OP_get_version which will return the highest version of the
+interface supported by the hypervisor. Additions to the interface need
+to bump the interface version. The hypervisor is required to support the
+previous interface versions, too (this implies that additions will always
+require new sub-commands in order to allow the hypervisor to decide which
+version of the interface to use).
+
+* hypercall interface specification
+    * `xen/include/public/hypfs.h`
+* hypervisor internal files
+    * `xen/include/xen/hypfs.h`
+    * `xen/common/hypfs.c`
+* `libxenhypfs`
+    * `tools/libs/libxenhypfs/*`
+* `xenhypfs`
+    * `tools/misc/xenhypfs.c`
+* path documentation
+    * `docs/misc/hypfs-paths.pandoc`
+
+# Testing
+
+Any new parameters or hardware mitigations should be verified to show up
+correctly in the filesystem.
+
+# Areas for improvement
+
+* More detailed access rights
+* Entries per domain and/or per cpupool
+
+# Known issues
+
+* None
+
+# References
+
+* None
+
+# History
+
+------------------------------------------------------------------------
+Date       Revision Version  Notes
+---------- -------- -------- -------------------------------------------
+2020-01-23 1        Xen 4.14 Document written
+---------- -------- -------- -------------------------------------------
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
new file mode 100644
index 0000000000..b9f50f6998
--- /dev/null
+++ b/docs/misc/hypfs-paths.pandoc
@@ -0,0 +1,105 @@
+# Xenhypfs Paths
+
+This document attempts to define all the paths which are available
+in the Xen hypervisor file system (hypfs).
+
+The hypervisor file system can be accessed via the xenhypfs tool.
+
+## Notation
+
+The hypervisor file system is similar to the Linux kernel's sysfs.
+In this document directories are always specified with a trailing "/".
+
+The following notation conventions apply:
+
+        DIRECTORY/
+
+        PATH = VALUES [TAGS]
+
+The first syntax defines a directory. It normally contains related
+entries and the general scope of the directory is described.
+
+The second syntax defines a file entry containing values which are
+either set by the hypervisor or, if the file is writable, can be set
+by the user.
+
+PATH can contain simple regex constructs following the Perl compatible
+regexp syntax described in pcre(3) or perlre(1).
+
+A hypervisor file system entry name can be any 0-delimited byte string
+not containing any '/' character. The names "." and ".." are reserved
+for file system internal use.
+
+VALUES are strings and can take the following forms:
+
+* STRING -- an arbitrary 0-delimited byte string.
+* INTEGER -- An integer, in decimal representation unless otherwise
+  noted.
+* "a literal string" -- literal strings are contained within quotes.
+* (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
+  separated by a "|" and all the alternatives are enclosed in "(" and
+  ")".
+* {VALUE, VALUE, ... } -- a list of possible values separated by "," and
+  enclosed in "{" and "}".
+
+Additional TAGS may follow as a comma separated set of the following
+tags enclosed in square brackets.
+
+* w -- Path is writable by the user. This capability is usually
+  limited to the control domain (e.g. dom0).
+* ARM | ARM32 | ARM64 | X86: the path is available for the respective
+  architecture only.
+* PV --  Path is valid for PV capable hypervisors only.
+* HVM -- Path is valid for HVM capable hypervisors only.
+* CONFIG_* -- Path is valid only in case the hypervisor was built with
+  the respective config option.
+
+So an entry could look like this:
+
+    /cpu-bugs/active-pv/xpti = ("No"|{"dom0", "domU", "PCID on"}) [w,X86,PV]
+
+Possible values would be "No" or a list of "dom0", "domU", and "PCID on".
+The entry would be writable and it would exist on X86 only and only if the
+hypervisor is configured to support PV guests.
+
+## Example
+
+A populated Xen hypervisor file system might look like the following example:
+
+    /
+        buildinfo/           directory containing build-time data
+            config           contents of .config file used to build Xen
+        cpu-bugs/            x86: directory of cpu bug information
+            l1tf             "Vulnerable" or "Not vulnerable"
+            mds              "Vulnerable" or "Not vulnerable"
+            meltdown         "Vulnerable" or "Not vulnerable"
+            spec-store-bypass "Vulnerable" or "Not vulnerable"
+            spectre-v1       "Vulnerable" or "Not vulnerable"
+            spectre-v2       "Vulnerable" or "Not vulnerable"
+            mitigations/     directory of mitigation settings
+                bti-thunk    "N/A", "RETPOLINE", "LFENCE" or "JMP"
+                spec-ctrl    "No", "IBRS+" or IBRS-"
+                ibpb         "No" or "Yes"
+                l1d-flush    "No" or "Yes"
+                md-clear     "No" or "VERW"
+                l1tf-barrier "No" or "Yes"
+            active-hvm/      directory for mitigations active in hvm doamins
+                msr-spec-ctrl "No" or "Yes"
+                rsb          "No" or "Yes"
+                eager-fpu    "No" or "Yes"
+                md-clear     "No" or "Yes"
+            active-pv/       directory for mitigations active in pv doamins
+                msr-spec-ctrl "No" or "Yes"
+                rsb          "No" or "Yes"
+                eager-fpu    "No" or "Yes"
+                md-clear     "No" or "Yes"
+                xpti         "No" or list of "dom0", "domU", "PCID on"
+                l1tf-shadow  "No" or list of "dom0", "domU"
+        params/              directory with hypervisor parameter values
+                             (boot/runtime parameters)
+
+## General Paths
+
+#### /
+
+The root of the hypervisor file system.
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK232-0003jC-PC; Thu, 02 Apr 2020 15:46:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK231-0003iz-Tk
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:27 +0000
X-Inumbo-ID: 198f33e3-74f9-11ea-bc01-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 198f33e3-74f9-11ea-bc01-12813bfff9fa;
 Thu, 02 Apr 2020 15:46:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 66A66AE4D;
 Thu,  2 Apr 2020 15:46:20 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 06/12] tools: add xenfs tool
Date: Thu,  2 Apr 2020 17:46:10 +0200
Message-Id: <20200402154616.16927-7-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add the xenfs tool for accessing the hypervisor filesystem.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
---
V1:
- rename to xenhypfs
- don't use "--" for subcommands
- add write support

V2:
- escape non-printable characters per default with cat subcommand
  (Ian Jackson)
- add -b option to cat subcommand (Ian Jackson)
- add man page

V3:
- adapt to new hypfs interface

V7:
- added missing bool for ls output
---
 .gitignore              |   1 +
 docs/man/xenhypfs.1.pod |  61 +++++++++++++++
 tools/misc/Makefile     |   6 ++
 tools/misc/xenhypfs.c   | 192 ++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 260 insertions(+)
 create mode 100644 docs/man/xenhypfs.1.pod
 create mode 100644 tools/misc/xenhypfs.c

diff --git a/.gitignore b/.gitignore
index e98c3f056d..fd5610718d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -367,6 +367,7 @@ tools/libxl/test_timedereg
 tools/libxl/test_fdderegrace
 tools/firmware/etherboot/eb-roms.h
 tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
+tools/misc/xenhypfs
 tools/misc/xenwatchdogd
 tools/misc/xen-hvmcrash
 tools/misc/xen-lowmemd
diff --git a/docs/man/xenhypfs.1.pod b/docs/man/xenhypfs.1.pod
new file mode 100644
index 0000000000..37aa488fcc
--- /dev/null
+++ b/docs/man/xenhypfs.1.pod
@@ -0,0 +1,61 @@
+=head1 NAME
+
+xenhypfs - Xen tool to access Xen hypervisor file system
+
+=head1 SYNOPSIS
+
+B<xenhypfs> I<subcommand> [I<options>] [I<args>]
+
+=head1 DESCRIPTION
+
+The B<xenhypfs> program is used to access the Xen hypervisor file system.
+It can be used to show the available entries, to show their contents and
+(if allowed) to modify their contents.
+
+=head1 SUBCOMMANDS
+
+=over 4
+
+=item B<ls> I<path>
+
+List the available entries below I<path>.
+
+=item B<cat> [I<-b>] I<path>
+
+Show the contents of the entry specified by I<path>. Non-printable characters
+other than white space characters (like tab, new line) will be shown as
+B<\xnn> (B<nn> being a two digit hex number) unless the option B<-b> is
+specified.
+
+=item B<write> I<path> I<value>
+
+Set the contents of the entry specified by I<path> to I<value>.
+
+=item B<tree>
+
+Show all the entries of the file system as a tree.
+
+=back
+
+=head1 RETURN CODES
+
+=over 4
+
+=item B<0>
+
+Success
+
+=item B<1>
+
+Invalid usage (e.g. unknown subcommand, unknown option, missing parameter).
+
+=item B<2>
+
+Entry not found while traversing the tree.
+
+=item B<3>
+
+Access right violation.
+
+=back
+
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 63947bfadc..9fdb13597f 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -24,6 +24,7 @@ INSTALL_SBIN-$(CONFIG_X86)     += xen-lowmemd
 INSTALL_SBIN-$(CONFIG_X86)     += xen-mfndump
 INSTALL_SBIN-$(CONFIG_X86)     += xen-ucode
 INSTALL_SBIN                   += xencov
+INSTALL_SBIN                   += xenhypfs
 INSTALL_SBIN                   += xenlockprof
 INSTALL_SBIN                   += xenperf
 INSTALL_SBIN                   += xenpm
@@ -86,6 +87,9 @@ xenperf: xenperf.o
 xenpm: xenpm.o
 	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+xenhypfs: xenhypfs.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenhypfs) $(APPEND_LDFLAGS)
+
 xenlockprof: xenlockprof.o
 	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -94,6 +98,8 @@ xen-hptool.o: CFLAGS += -I$(XEN_ROOT)/tools/libxc $(CFLAGS_libxencall)
 xen-hptool: xen-hptool.o
 	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xenhypfs.o: CFLAGS += $(CFLAGS_libxenhypfs)
+
 # xen-mfndump incorrectly uses libxc internals
 xen-mfndump.o: CFLAGS += -I$(XEN_ROOT)/tools/libxc $(CFLAGS_libxencall)
 xen-mfndump: xen-mfndump.o
diff --git a/tools/misc/xenhypfs.c b/tools/misc/xenhypfs.c
new file mode 100644
index 0000000000..158b901f42
--- /dev/null
+++ b/tools/misc/xenhypfs.c
@@ -0,0 +1,192 @@
+#define _GNU_SOURCE
+#include <ctype.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <xenhypfs.h>
+
+static struct xenhypfs_handle *hdl;
+
+static int usage(void)
+{
+    fprintf(stderr, "usage: xenhypfs ls <path>\n");
+    fprintf(stderr, "       xenhypfs cat [-b] <path>\n");
+    fprintf(stderr, "       xenhypfs write <path> <val>\n");
+    fprintf(stderr, "       xenhypfs tree\n");
+
+    return 1;
+}
+
+static void xenhypfs_print_escaped(char *string)
+{
+    char *c;
+
+    for (c = string; *c; c++) {
+        if (isgraph(*c) || isspace(*c))
+            printf("%c", *c);
+        else
+            printf("\\x%02x", *c);
+    }
+    printf("\n");
+}
+
+static int xenhypfs_cat(int argc, char *argv[])
+{
+    int ret = 0;
+    char *result;
+    char *path;
+    bool bin = false;
+
+    switch (argc) {
+    case 1:
+        path = argv[0];
+        break;
+
+    case 2:
+        if (strcmp(argv[0], "-b"))
+            return usage();
+        bin = true;
+        path = argv[1];
+        break;
+
+    default:
+        return usage();
+    }
+
+    result = xenhypfs_read(hdl, path);
+    if (!result) {
+        perror("could not read");
+        ret = 3;
+    } else {
+        if (!bin)
+            printf("%s\n", result);
+        else
+            xenhypfs_print_escaped(result);
+        free(result);
+    }
+
+    return ret;
+}
+
+static int xenhypfs_wr(char *path, char *val)
+{
+    int ret;
+
+    ret = xenhypfs_write(hdl, path, val);
+    if (ret) {
+        perror("could not write");
+        ret = 3;
+    }
+
+    return ret;
+}
+
+static char *xenhypfs_type(struct xenhypfs_dirent *ent)
+{
+    char *res;
+
+    switch (ent->type) {
+    case xenhypfs_type_dir:
+        res = "<dir>   ";
+        break;
+    case xenhypfs_type_blob:
+        res = "<blob>  ";
+        break;
+    case xenhypfs_type_string:
+        res = "<string>";
+        break;
+    case xenhypfs_type_uint:
+        res = "<uint>  ";
+        break;
+    case xenhypfs_type_int:
+        res = "<int>   ";
+        break;
+    case xenhypfs_type_bool:
+        res = "<bool>  ";
+        break;
+    default:
+        res = "<\?\?\?>   ";
+        break;
+    }
+
+    return res;
+}
+
+static int xenhypfs_ls(char *path)
+{
+    struct xenhypfs_dirent *ent;
+    unsigned int n, i;
+    int ret = 0;
+
+    ent = xenhypfs_readdir(hdl, path, &n);
+    if (!ent) {
+        perror("could not read dir");
+        ret = 3;
+    } else {
+        for (i = 0; i < n; i++)
+            printf("%s r%c %s\n", xenhypfs_type(ent + i),
+                   ent[i].is_writable ? 'w' : '-', ent[i].name);
+
+        free(ent);
+    }
+
+    return ret;
+}
+
+static int xenhypfs_tree_sub(char *path, unsigned int depth)
+{
+    struct xenhypfs_dirent *ent;
+    unsigned int n, i;
+    int ret = 0;
+    char *p;
+
+    ent = xenhypfs_readdir(hdl, path, &n);
+    if (!ent)
+        return 2;
+
+    for (i = 0; i < n; i++) {
+        printf("%*s%s%s\n", depth * 2, "", ent[i].name,
+               ent[i].type == xenhypfs_type_dir ? "/" : "");
+        if (ent[i].type == xenhypfs_type_dir) {
+            asprintf(&p, "%s%s%s", path, (depth == 1) ? "" : "/", ent[i].name);
+            if (xenhypfs_tree_sub(p, depth + 1))
+                ret = 2;
+        }
+    }
+
+    free(ent);
+
+    return ret;
+}
+
+static int xenhypfs_tree(void)
+{
+    printf("/\n");
+
+    return xenhypfs_tree_sub("/", 1);
+}
+
+int main(int argc, char *argv[])
+{
+    int ret;
+
+    hdl = xenhypfs_open(NULL, 0);
+
+    if (!hdl) {
+        fprintf(stderr, "Could not open libxenhypfs\n");
+        ret = 2;
+    } else if (argc >= 3 && !strcmp(argv[1], "cat"))
+        ret = xenhypfs_cat(argc - 2, argv + 2);
+    else if (argc == 3 && !strcmp(argv[1], "ls"))
+        ret = xenhypfs_ls(argv[2]);
+    else if (argc == 4 && !strcmp(argv[1], "write"))
+        ret = xenhypfs_wr(argv[2], argv[3]);
+    else if (argc == 2 && !strcmp(argv[1], "tree"))
+        ret = xenhypfs_tree();
+    else
+        ret = usage();
+
+    xenhypfs_close(hdl);
+
+    return ret;
+}
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK238-0003lt-7t; Thu, 02 Apr 2020 15:46:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK236-0003lB-Gu
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:32 +0000
X-Inumbo-ID: 19c5fed6-74f9-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 19c5fed6-74f9-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 15:46:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D482AAE38;
 Thu,  2 Apr 2020 15:46:19 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 00/12] Add hypervisor sysfs-like support
Date: Thu,  2 Apr 2020 17:46:04 +0200
Message-Id: <20200402154616.16927-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.

This is a first implementation of that idea adding the basic
functionality to hypervisor and tools side. The interface to any
user program making use of that "xen-hypfs" is a new library
"libxenhypfs" with a stable interface.

The series adds read-only nodes with buildinfo data and writable
nodes with runtime parameters. xl is switched to use the new file
system for modifying the runtime parameters and the old sysctl
interface for that purpose is dropped.

Changes in V7:
- old patch 1 already applied
- add new patch 1 (carved out and modified from patch 9)
- addressed review comments
- modified public interface to have a max write size instead of a
  writable flag only

Changes in V6:
- added new patches 1, 10, 11, 12
- addressed review comments
- modified interface for creating nodes for runtime parameters

Changes in V5:
- switched to xsm for privilege check

Changes in V4:
- former patch 2 removed as already committed
- addressed review comments

Changes in V3:
- major rework, especially by supporting binary contents of entries
- added several new patches (1, 2, 7)
- full support of all runtime parameters
- support of writing entries (especially runtime parameters)

Changes in V2:
- all comments to V1 addressed
- added man-page for xenhypfs tool
- added runtime parameter read access for string parameters

Changes in V1:
- renamed xenfs ->xenhypfs
- added writable entries support at the interface level and in the
  xenhypfs tool
- added runtime parameter read access (integer type only for now)
- added docs/misc/hypfs-paths.pandoc for path descriptions

Juergen Gross (12):
  xen/vmx: let opt_ept_ad always reflect the current setting
  xen: add a generic way to include binary files as variables
  docs: add feature document for Xen hypervisor sysfs-like support
  xen: add basic hypervisor filesystem support
  libs: add libxenhypfs
  tools: add xenfs tool
  xen: provide version information in hypfs
  xen: add /buildinfo/config entry to hypervisor filesystem
  xen: add runtime parameter access support to hypfs
  tools/libxl: use libxenhypfs for setting xen runtime parameters
  tools/libxc: remove xc_set_parameters()
  xen: remove XEN_SYSCTL_set_parameter support

 .gitignore                          |   6 +
 docs/features/hypervisorfs.pandoc   |  92 +++++++
 docs/man/xenhypfs.1.pod             |  61 ++++
 docs/misc/hypfs-paths.pandoc        | 163 +++++++++++
 tools/Rules.mk                      |   8 +-
 tools/flask/policy/modules/dom0.te  |   4 +-
 tools/libs/Makefile                 |   1 +
 tools/libs/hypfs/Makefile           |  16 ++
 tools/libs/hypfs/core.c             | 536 ++++++++++++++++++++++++++++++++++++
 tools/libs/hypfs/include/xenhypfs.h |  75 +++++
 tools/libs/hypfs/libxenhypfs.map    |  10 +
 tools/libs/hypfs/xenhypfs.pc.in     |  10 +
 tools/libxc/include/xenctrl.h       |   1 -
 tools/libxc/xc_misc.c               |  21 --
 tools/libxl/Makefile                |   3 +-
 tools/libxl/libxl.c                 |  53 +++-
 tools/libxl/libxl_internal.h        |   1 +
 tools/libxl/xenlight.pc.in          |   2 +-
 tools/misc/Makefile                 |   6 +
 tools/misc/xenhypfs.c               | 192 +++++++++++++
 tools/xl/xl_misc.c                  |   1 -
 xen/arch/arm/traps.c                |   1 +
 xen/arch/arm/xen.lds.S              |  10 +-
 xen/arch/x86/hvm/hypercall.c        |   1 +
 xen/arch/x86/hvm/vmx/vmcs.c         |  54 +++-
 xen/arch/x86/hvm/vmx/vmx.c          |   4 +-
 xen/arch/x86/hypercall.c            |   1 +
 xen/arch/x86/pv/domain.c            |  21 +-
 xen/arch/x86/pv/hypercall.c         |   1 +
 xen/arch/x86/xen.lds.S              |  10 +-
 xen/common/Kconfig                  |  10 +
 xen/common/Makefile                 |  13 +
 xen/common/grant_table.c            |  49 +++-
 xen/common/hypfs.c                  | 381 +++++++++++++++++++++++++
 xen/common/kernel.c                 |  84 +++++-
 xen/common/sysctl.c                 |  36 ---
 xen/drivers/char/console.c          |  61 +++-
 xen/include/Makefile                |   1 +
 xen/include/asm-x86/hvm/vmx/vmcs.h  |   3 +-
 xen/include/public/hypfs.h          | 127 +++++++++
 xen/include/public/sysctl.h         |  19 +-
 xen/include/public/xen.h            |   1 +
 xen/include/xen/hypercall.h         |   8 +
 xen/include/xen/hypfs.h             | 118 ++++++++
 xen/include/xen/kernel.h            |   3 +
 xen/include/xen/lib.h               |   1 -
 xen/include/xen/param.h             | 101 ++++---
 xen/include/xlat.lst                |   2 +
 xen/include/xsm/dummy.h             |   6 +
 xen/include/xsm/xsm.h               |   6 +
 xen/tools/binfile                   |  41 +++
 xen/xsm/dummy.c                     |   1 +
 xen/xsm/flask/Makefile              |   5 +-
 xen/xsm/flask/flask-policy.S        |  16 --
 xen/xsm/flask/hooks.c               |   9 +-
 xen/xsm/flask/policy/access_vectors |   4 +-
 56 files changed, 2284 insertions(+), 187 deletions(-)
 create mode 100644 docs/features/hypervisorfs.pandoc
 create mode 100644 docs/man/xenhypfs.1.pod
 create mode 100644 docs/misc/hypfs-paths.pandoc
 create mode 100644 tools/libs/hypfs/Makefile
 create mode 100644 tools/libs/hypfs/core.c
 create mode 100644 tools/libs/hypfs/include/xenhypfs.h
 create mode 100644 tools/libs/hypfs/libxenhypfs.map
 create mode 100644 tools/libs/hypfs/xenhypfs.pc.in
 create mode 100644 tools/misc/xenhypfs.c
 create mode 100644 xen/common/hypfs.c
 create mode 100644 xen/include/public/hypfs.h
 create mode 100644 xen/include/xen/hypfs.h
 create mode 100755 xen/tools/binfile
 delete mode 100644 xen/xsm/flask/flask-policy.S

-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK238-0003m6-Hp; Thu, 02 Apr 2020 15:46:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK236-0003lK-Ty
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:32 +0000
X-Inumbo-ID: 1a56d96a-74f9-11ea-bc01-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1a56d96a-74f9-11ea-bc01-12813bfff9fa;
 Thu, 02 Apr 2020 15:46:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 63955AE48;
 Thu,  2 Apr 2020 15:46:20 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 05/12] libs: add libxenhypfs
Date: Thu,  2 Apr 2020 17:46:09 +0200
Message-Id: <20200402154616.16927-6-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add the new library libxenhypfs for access to the hypervisor filesystem.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
---
V1:
- rename to libxenhypfs
- add xenhypfs_write()

V3:
- major rework due to new hypervisor interface
- add decompression capability

V4:
- add dependency to libz in pkgconfig file (Wei Liu)

V7:
- don't assume hypervisor's sizeof(bool) is same as in user land
---
 .gitignore                          |   2 +
 tools/Rules.mk                      |   6 +
 tools/libs/Makefile                 |   1 +
 tools/libs/hypfs/Makefile           |  16 ++
 tools/libs/hypfs/core.c             | 536 ++++++++++++++++++++++++++++++++++++
 tools/libs/hypfs/include/xenhypfs.h |  75 +++++
 tools/libs/hypfs/libxenhypfs.map    |  10 +
 tools/libs/hypfs/xenhypfs.pc.in     |  10 +
 8 files changed, 656 insertions(+)
 create mode 100644 tools/libs/hypfs/Makefile
 create mode 100644 tools/libs/hypfs/core.c
 create mode 100644 tools/libs/hypfs/include/xenhypfs.h
 create mode 100644 tools/libs/hypfs/libxenhypfs.map
 create mode 100644 tools/libs/hypfs/xenhypfs.pc.in

diff --git a/.gitignore b/.gitignore
index b2624df79a..e98c3f056d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -109,6 +109,8 @@ tools/libs/evtchn/headers.chk
 tools/libs/evtchn/xenevtchn.pc
 tools/libs/gnttab/headers.chk
 tools/libs/gnttab/xengnttab.pc
+tools/libs/hypfs/headers.chk
+tools/libs/hypfs/xenhypfs.pc
 tools/libs/call/headers.chk
 tools/libs/call/xencall.pc
 tools/libs/foreignmemory/headers.chk
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 9bac15c8d1..711e9598cd 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -19,6 +19,7 @@ XEN_LIBXENGNTTAB   = $(XEN_ROOT)/tools/libs/gnttab
 XEN_LIBXENCALL     = $(XEN_ROOT)/tools/libs/call
 XEN_LIBXENFOREIGNMEMORY = $(XEN_ROOT)/tools/libs/foreignmemory
 XEN_LIBXENDEVICEMODEL = $(XEN_ROOT)/tools/libs/devicemodel
+XEN_LIBXENHYPFS    = $(XEN_ROOT)/tools/libs/hypfs
 XEN_LIBXC          = $(XEN_ROOT)/tools/libxc
 XEN_XENLIGHT       = $(XEN_ROOT)/tools/libxl
 # Currently libxlutil lives in the same directory as libxenlight
@@ -134,6 +135,11 @@ SHDEPS_libxendevicemodel = $(SHLIB_libxentoollog) $(SHLIB_libxentoolcore) $(SHLI
 LDLIBS_libxendevicemodel = $(SHDEPS_libxendevicemodel) $(XEN_LIBXENDEVICEMODEL)/libxendevicemodel$(libextension)
 SHLIB_libxendevicemodel  = $(SHDEPS_libxendevicemodel) -Wl,-rpath-link=$(XEN_LIBXENDEVICEMODEL)
 
+CFLAGS_libxenhypfs = -I$(XEN_LIBXENHYPFS)/include $(CFLAGS_xeninclude)
+SHDEPS_libxenhypfs = $(SHLIB_libxentoollog) $(SHLIB_libxentoolcore) $(SHLIB_xencall)
+LDLIBS_libxenhypfs = $(SHDEPS_libxenhypfs) $(XEN_LIBXENHYPFS)/libxenhypfs$(libextension)
+SHLIB_libxenhypfs  = $(SHDEPS_libxenhypfs) -Wl,-rpath-link=$(XEN_LIBXENHYPFS)
+
 # code which compiles against libxenctrl get __XEN_TOOLS__ and
 # therefore sees the unstable hypercall interfaces.
 CFLAGS_libxenctrl = -I$(XEN_LIBXC)/include $(CFLAGS_libxentoollog) $(CFLAGS_libxenforeignmemory) $(CFLAGS_libxendevicemodel) $(CFLAGS_xeninclude) -D__XEN_TOOLS__
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 88901e7341..69cdfb5975 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -9,6 +9,7 @@ SUBDIRS-y += gnttab
 SUBDIRS-y += call
 SUBDIRS-y += foreignmemory
 SUBDIRS-y += devicemodel
+SUBDIRS-y += hypfs
 
 ifeq ($(CONFIG_RUMP),y)
 SUBDIRS-y := toolcore
diff --git a/tools/libs/hypfs/Makefile b/tools/libs/hypfs/Makefile
new file mode 100644
index 0000000000..06dd449929
--- /dev/null
+++ b/tools/libs/hypfs/Makefile
@@ -0,0 +1,16 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+MAJOR    = 1
+MINOR    = 0
+LIBNAME  := hypfs
+USELIBS  := toollog toolcore call
+
+APPEND_LDFLAGS += -lz
+
+SRCS-y                 += core.c
+
+include ../libs.mk
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENHYPFS)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
diff --git a/tools/libs/hypfs/core.c b/tools/libs/hypfs/core.c
new file mode 100644
index 0000000000..befdc66e96
--- /dev/null
+++ b/tools/libs/hypfs/core.c
@@ -0,0 +1,536 @@
+/*
+ * Copyright (c) 2019 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define __XEN_TOOLS__ 1
+
+#define _GNU_SOURCE
+
+#include <errno.h>
+#include <inttypes.h>
+#include <stdbool.h>
+#include <stdlib.h>
+#include <string.h>
+#include <zlib.h>
+
+#include <xentoollog.h>
+#include <xenhypfs.h>
+#include <xencall.h>
+#include <xentoolcore_internal.h>
+
+#include <xen/xen.h>
+#include <xen/hypfs.h>
+
+#define BUF_SIZE 4096
+
+struct xenhypfs_handle {
+    xentoollog_logger *logger, *logger_tofree;
+    unsigned int flags;
+    xencall_handle *xcall;
+};
+
+xenhypfs_handle *xenhypfs_open(xentoollog_logger *logger,
+                               unsigned open_flags)
+{
+    xenhypfs_handle *fshdl = calloc(1, sizeof(*fshdl));
+
+    if (!fshdl)
+        return NULL;
+
+    fshdl->flags = open_flags;
+    fshdl->logger = logger;
+    fshdl->logger_tofree = NULL;
+
+    if (!fshdl->logger) {
+        fshdl->logger = fshdl->logger_tofree =
+            (xentoollog_logger*)
+            xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
+        if (!fshdl->logger)
+            goto err;
+    }
+
+    fshdl->xcall = xencall_open(fshdl->logger, 0);
+    if (!fshdl->xcall)
+        goto err;
+
+    /* No need to remember supported version, we only support V1. */
+    if (xencall1(fshdl->xcall, __HYPERVISOR_hypfs_op,
+                 XEN_HYPFS_OP_get_version) < 0)
+        goto err;
+
+    return fshdl;
+
+err:
+    xtl_logger_destroy(fshdl->logger_tofree);
+    xencall_close(fshdl->xcall);
+    free(fshdl);
+    return NULL;
+}
+
+int xenhypfs_close(xenhypfs_handle *fshdl)
+{
+    if (!fshdl)
+        return 0;
+
+    xencall_close(fshdl->xcall);
+    xtl_logger_destroy(fshdl->logger_tofree);
+    free(fshdl);
+    return 0;
+}
+
+static int xenhypfs_get_pathbuf(xenhypfs_handle *fshdl, const char *path,
+                                char **path_buf)
+{
+    int ret = -1;
+    int path_sz;
+
+    if (!fshdl) {
+        errno = EBADF;
+        goto out;
+    }
+
+    path_sz = strlen(path) + 1;
+    if (path_sz > XEN_HYPFS_MAX_PATHLEN)
+    {
+        errno = ENAMETOOLONG;
+        goto out;
+    }
+
+    *path_buf = xencall_alloc_buffer(fshdl->xcall, path_sz);
+    if (!*path_buf) {
+        errno = ENOMEM;
+        goto out;
+    }
+    strcpy(*path_buf, path);
+
+    ret = path_sz;
+
+ out:
+    return ret;
+}
+
+static void *xenhypfs_inflate(void *in_data, size_t *sz)
+{
+    unsigned char *workbuf;
+    void *content = NULL;
+    unsigned int out_sz;
+    z_stream z = { .opaque = NULL };
+    int ret;
+
+    workbuf = malloc(BUF_SIZE);
+    if (!workbuf)
+        return NULL;
+
+    z.next_in = in_data;
+    z.avail_in = *sz;
+    ret = inflateInit2(&z, MAX_WBITS + 32); /* 32 == gzip */
+
+    for (*sz = 0; ret == Z_OK; *sz += out_sz) {
+        z.next_out = workbuf;
+        z.avail_out = BUF_SIZE;
+        ret = inflate(&z, Z_SYNC_FLUSH);
+        if (ret != Z_OK && ret != Z_STREAM_END)
+            break;
+
+        out_sz = z.next_out - workbuf;
+        content = realloc(content, *sz + out_sz);
+        if (!content) {
+            ret = Z_MEM_ERROR;
+            break;
+        }
+        memcpy(content + *sz, workbuf, out_sz);
+    }
+
+    inflateEnd(&z);
+    if (ret != Z_STREAM_END) {
+        free(content);
+        content = NULL;
+        errno = EIO;
+    }
+    free(workbuf);
+    return content;
+}
+
+static void xenhypfs_set_attrs(struct xen_hypfs_direntry *entry,
+                               struct xenhypfs_dirent *dirent)
+{
+    dirent->size = entry->content_len;
+
+    switch(entry->type) {
+    case XEN_HYPFS_TYPE_DIR:
+        dirent->type = xenhypfs_type_dir;
+        break;
+    case XEN_HYPFS_TYPE_BLOB:
+        dirent->type = xenhypfs_type_blob;
+        break;
+    case XEN_HYPFS_TYPE_STRING:
+        dirent->type = xenhypfs_type_string;
+        break;
+    case XEN_HYPFS_TYPE_UINT:
+        dirent->type = xenhypfs_type_uint;
+        break;
+    case XEN_HYPFS_TYPE_INT:
+        dirent->type = xenhypfs_type_int;
+        break;
+    case XEN_HYPFS_TYPE_BOOL:
+        dirent->type = xenhypfs_type_bool;
+        break;
+    default:
+        dirent->type = xenhypfs_type_blob;
+    }
+
+    switch (entry->encoding) {
+    case XEN_HYPFS_ENC_PLAIN:
+        dirent->encoding = xenhypfs_enc_plain;
+        break;
+    case XEN_HYPFS_ENC_GZIP:
+        dirent->encoding = xenhypfs_enc_gzip;
+        break;
+    default:
+        dirent->encoding = xenhypfs_enc_plain;
+        dirent->type = xenhypfs_type_blob;
+    }
+
+    dirent->is_writable = entry->max_write_len;
+}
+
+void *xenhypfs_read_raw(xenhypfs_handle *fshdl, const char *path,
+                        struct xenhypfs_dirent **dirent)
+{
+    void *retbuf = NULL, *content = NULL;
+    char *path_buf = NULL;
+    const char *name;
+    struct xen_hypfs_direntry *entry;
+    int ret;
+    int sz, path_sz;
+
+    *dirent = NULL;
+    ret = xenhypfs_get_pathbuf(fshdl, path, &path_buf);
+    if (ret < 0)
+        goto out;
+
+    path_sz = ret;
+
+    for (sz = BUF_SIZE;; sz = sizeof(*entry) + entry->content_len) {
+        if (retbuf)
+            xencall_free_buffer(fshdl->xcall, retbuf);
+
+        retbuf = xencall_alloc_buffer(fshdl->xcall, sz);
+        if (!retbuf) {
+            errno = ENOMEM;
+            goto out;
+        }
+        entry = retbuf;
+
+        ret = xencall5(fshdl->xcall, __HYPERVISOR_hypfs_op, XEN_HYPFS_OP_read,
+                       (unsigned long)path_buf, path_sz,
+                       (unsigned long)retbuf, sz);
+        if (!ret)
+            break;
+
+        if (ret != ENOBUFS) {
+            errno = -ret;
+            goto out;
+        }
+    }
+
+    content = malloc(entry->content_len);
+    if (!content)
+        goto out;
+    memcpy(content, entry + 1, entry->content_len);
+
+    name = strrchr(path, '/');
+    if (!name)
+        name = path;
+    else {
+        name++;
+        if (!*name)
+            name--;
+    }
+    *dirent = calloc(1, sizeof(struct xenhypfs_dirent) + strlen(name) + 1);
+    if (!*dirent) {
+        free(content);
+        content = NULL;
+        errno = ENOMEM;
+        goto out;
+    }
+    (*dirent)->name = (char *)(*dirent + 1);
+    strcpy((*dirent)->name, name);
+    xenhypfs_set_attrs(entry, *dirent);
+
+ out:
+    ret = errno;
+    xencall_free_buffer(fshdl->xcall, path_buf);
+    xencall_free_buffer(fshdl->xcall, retbuf);
+    errno = ret;
+
+    return content;
+}
+
+char *xenhypfs_read(xenhypfs_handle *fshdl, const char *path)
+{
+    char *buf, *ret_buf = NULL;
+    struct xenhypfs_dirent *dirent;
+    int ret;
+
+    buf = xenhypfs_read_raw(fshdl, path, &dirent);
+    if (!buf)
+        goto out;
+
+    switch (dirent->encoding) {
+    case xenhypfs_enc_plain:
+        break;
+    case xenhypfs_enc_gzip:
+        ret_buf = xenhypfs_inflate(buf, &dirent->size);
+        if (!ret_buf)
+            goto out;
+        free(buf);
+        buf = ret_buf;
+        ret_buf = NULL;
+        break;
+    }
+
+    switch (dirent->type) {
+    case xenhypfs_type_dir:
+        errno = EISDIR;
+        break;
+    case xenhypfs_type_blob:
+        errno = EDOM;
+        break;
+    case xenhypfs_type_string:
+        ret_buf = buf;
+        buf = NULL;
+        break;
+    case xenhypfs_type_uint:
+    case xenhypfs_type_bool:
+        switch (dirent->size) {
+        case 1:
+            ret = asprintf(&ret_buf, "%"PRIu8, *(uint8_t *)buf);
+            break;
+        case 2:
+            ret = asprintf(&ret_buf, "%"PRIu16, *(uint16_t *)buf);
+            break;
+        case 4:
+            ret = asprintf(&ret_buf, "%"PRIu32, *(uint32_t *)buf);
+            break;
+        case 8:
+            ret = asprintf(&ret_buf, "%"PRIu64, *(uint64_t *)buf);
+            break;
+        default:
+            ret = -1;
+            errno = EDOM;
+        }
+        if (ret < 0)
+            ret_buf = NULL;
+        break;
+    case xenhypfs_type_int:
+        switch (dirent->size) {
+        case 1:
+            ret = asprintf(&ret_buf, "%"PRId8, *(int8_t *)buf);
+            break;
+        case 2:
+            ret = asprintf(&ret_buf, "%"PRId16, *(int16_t *)buf);
+            break;
+        case 4:
+            ret = asprintf(&ret_buf, "%"PRId32, *(int32_t *)buf);
+            break;
+        case 8:
+            ret = asprintf(&ret_buf, "%"PRId64, *(int64_t *)buf);
+            break;
+        default:
+            ret = -1;
+            errno = EDOM;
+        }
+        if (ret < 0)
+            ret_buf = NULL;
+        break;
+    }
+
+ out:
+    ret = errno;
+    free(buf);
+    free(dirent);
+    errno = ret;
+
+    return ret_buf;
+}
+
+struct xenhypfs_dirent *xenhypfs_readdir(xenhypfs_handle *fshdl,
+                                         const char *path,
+                                         unsigned int *num_entries)
+{
+    void *buf, *curr;
+    int ret;
+    char *names;
+    struct xenhypfs_dirent *ret_buf = NULL, *dirent;
+    unsigned int n = 0, name_sz = 0;
+    struct xen_hypfs_dirlistentry *entry;
+
+    buf = xenhypfs_read_raw(fshdl, path, &dirent);
+    if (!buf)
+        goto out;
+
+    if (dirent->type != xenhypfs_type_dir ||
+        dirent->encoding != xenhypfs_enc_plain) {
+        errno = ENOTDIR;
+        goto out;
+    }
+
+    if (dirent->size) {
+        curr = buf;
+        for (n = 1;; n++) {
+            entry = curr;
+            name_sz += strlen(entry->name) + 1;
+            if (!entry->off_next)
+                break;
+
+            curr += entry->off_next;
+        }
+    }
+
+    ret_buf = malloc(n * sizeof(*ret_buf) + name_sz);
+    if (!ret_buf)
+        goto out;
+
+    *num_entries = n;
+    names = (char *)(ret_buf + n);
+    curr = buf;
+    for (n = 0; n < *num_entries; n++) {
+        entry = curr;
+        xenhypfs_set_attrs(&entry->e, ret_buf + n);
+        ret_buf[n].name = names;
+        strcpy(names, entry->name);
+        names += strlen(entry->name) + 1;
+        curr += entry->off_next;
+    }
+
+ out:
+    ret = errno;
+    free(buf);
+    free(dirent);
+    errno = ret;
+
+    return ret_buf;
+}
+
+int xenhypfs_write(xenhypfs_handle *fshdl, const char *path, const char *val)
+{
+    void *buf = NULL;
+    char *path_buf = NULL, *val_end;
+    int ret, saved_errno;
+    int sz, path_sz;
+    struct xen_hypfs_direntry *entry;
+    uint64_t mask;
+
+    ret = xenhypfs_get_pathbuf(fshdl, path, &path_buf);
+    if (ret < 0)
+        goto out;
+
+    path_sz = ret;
+    ret = -1;
+
+    sz = BUF_SIZE;
+    buf = xencall_alloc_buffer(fshdl->xcall, sz);
+    if (!buf) {
+        errno = ENOMEM;
+        goto out;
+    }
+
+    ret = xencall5(fshdl->xcall, __HYPERVISOR_hypfs_op, XEN_HYPFS_OP_read,
+                   (unsigned long)path_buf, path_sz,
+                   (unsigned long)buf, sizeof(*entry));
+    if (ret && errno != ENOBUFS)
+        goto out;
+    ret = -1;
+    entry = buf;
+    if (!entry->max_write_len) {
+        errno = EACCES;
+        goto out;
+    }
+    if (entry->encoding != XEN_HYPFS_ENC_PLAIN) {
+        /* Writing compressed data currently not supported. */
+        errno = EDOM;
+        goto out;
+    }
+
+    switch (entry->type) {
+    case XEN_HYPFS_TYPE_STRING:
+        if (sz < strlen(val) + 1) {
+            sz = strlen(val) + 1;
+            xencall_free_buffer(fshdl->xcall, buf);
+            buf = xencall_alloc_buffer(fshdl->xcall, sz);
+            if (!buf) {
+                errno = ENOMEM;
+                goto out;
+            }
+        }
+        sz = strlen(val) + 1;
+        strcpy(buf, val);
+        break;
+    case XEN_HYPFS_TYPE_UINT:
+        sz = entry->content_len;
+        errno = 0;
+        *(unsigned long long *)buf = strtoull(val, &val_end, 0);
+        if (errno || !*val || *val_end)
+            goto out;
+        mask = ~0ULL << (8 * sz);
+        if ((*(uint64_t *)buf & mask) && ((*(uint64_t *)buf & mask) != mask)) {
+            errno = ERANGE;
+            goto out;
+        }
+        break;
+    case XEN_HYPFS_TYPE_INT:
+        sz = entry->content_len;
+        errno = 0;
+        *(unsigned long long *)buf = strtoll(val, &val_end, 0);
+        if (errno || !*val || *val_end)
+            goto out;
+        mask = (sz == 8) ? 0 : ~0ULL << (8 * sz);
+        if ((*(uint64_t *)buf & mask) && ((*(uint64_t *)buf & mask) != mask)) {
+            errno = ERANGE;
+            goto out;
+        }
+        break;
+    case XEN_HYPFS_TYPE_BOOL:
+        sz = entry->content_len;
+        *(unsigned long long *)buf = 0;
+        if (!strcmp(val, "1") || !strcmp(val, "on") || !strcmp(val, "yes") ||
+            !strcmp(val, "true") || !strcmp(val, "enable"))
+            *(unsigned long long *)buf = 1;
+        else if (strcmp(val, "0") && strcmp(val, "no") && strcmp(val, "off") &&
+                 strcmp(val, "false") && strcmp(val, "disable")) {
+            errno = EDOM;
+            goto out;
+        }
+        break;
+    default:
+        /* No support for other types (yet). */
+        errno = EDOM;
+        goto out;
+    }
+
+    ret = xencall5(fshdl->xcall, __HYPERVISOR_hypfs_op,
+                   XEN_HYPFS_OP_write_contents,
+                   (unsigned long)path_buf, path_sz,
+                   (unsigned long)buf, sz);
+
+ out:
+    saved_errno = errno;
+    xencall_free_buffer(fshdl->xcall, path_buf);
+    xencall_free_buffer(fshdl->xcall, buf);
+    errno = saved_errno;
+    return ret;
+}
diff --git a/tools/libs/hypfs/include/xenhypfs.h b/tools/libs/hypfs/include/xenhypfs.h
new file mode 100644
index 0000000000..29c69712ce
--- /dev/null
+++ b/tools/libs/hypfs/include/xenhypfs.h
@@ -0,0 +1,75 @@
+/*
+ * Copyright (c) 2019 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef XENHYPFS_H
+#define XENHYPFS_H
+
+#include <stdbool.h>
+#include <stdint.h>
+#include <sys/types.h>
+
+/* Callers who don't care don't need to #include <xentoollog.h> */
+struct xentoollog_logger;
+
+typedef struct xenhypfs_handle xenhypfs_handle;
+
+struct xenhypfs_dirent {
+    char *name;
+    size_t size;
+    enum {
+        xenhypfs_type_dir,
+        xenhypfs_type_blob,
+        xenhypfs_type_string,
+        xenhypfs_type_uint,
+        xenhypfs_type_int,
+        xenhypfs_type_bool
+    } type;
+    enum {
+        xenhypfs_enc_plain,
+        xenhypfs_enc_gzip
+    } encoding;
+    bool is_writable;
+};
+
+xenhypfs_handle *xenhypfs_open(struct xentoollog_logger *logger,
+                               unsigned int open_flags);
+int xenhypfs_close(xenhypfs_handle *fshdl);
+
+/* Returned buffer and dirent should be freed via free(). */
+void *xenhypfs_read_raw(xenhypfs_handle *fshdl, const char *path,
+                        struct xenhypfs_dirent **dirent);
+
+/* Returned buffer should be freed via free(). */
+char *xenhypfs_read(xenhypfs_handle *fshdl, const char *path);
+
+/* Returned buffer should be freed via free(). */
+struct xenhypfs_dirent *xenhypfs_readdir(xenhypfs_handle *fshdl,
+                                         const char *path,
+                                         unsigned int *num_entries);
+
+int xenhypfs_write(xenhypfs_handle *fshdl, const char *path, const char *val);
+
+#endif /* XENHYPFS_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libs/hypfs/libxenhypfs.map b/tools/libs/hypfs/libxenhypfs.map
new file mode 100644
index 0000000000..47f1edda3e
--- /dev/null
+++ b/tools/libs/hypfs/libxenhypfs.map
@@ -0,0 +1,10 @@
+VERS_1.0 {
+	global:
+		xenhypfs_open;
+		xenhypfs_close;
+		xenhypfs_read_raw;
+		xenhypfs_read;
+		xenhypfs_readdir;
+		xenhypfs_write;
+	local: *; /* Do not expose anything by default */
+};
diff --git a/tools/libs/hypfs/xenhypfs.pc.in b/tools/libs/hypfs/xenhypfs.pc.in
new file mode 100644
index 0000000000..92a262c7a2
--- /dev/null
+++ b/tools/libs/hypfs/xenhypfs.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xenhypfs
+Description: The Xenhypfs library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxenhypfs
+Requires.private: xentoolcore,xentoollog,xencall,z
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK23D-0003pF-0z; Thu, 02 Apr 2020 15:46:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK23B-0003oQ-H5
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:37 +0000
X-Inumbo-ID: 19ad44a4-74f9-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 19ad44a4-74f9-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 15:46:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id ECF50AE41;
 Thu,  2 Apr 2020 15:46:19 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 04/12] xen: add basic hypervisor filesystem support
Date: Thu,  2 Apr 2020 17:46:08 +0200
Message-Id: <20200402154616.16927-5-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add the infrastructure for the hypervisor filesystem.

This includes the hypercall interface and the base functions for
entry creation, deletion and modification.

In order not to have to repeat the same pattern multiple times in case
adding a new node should BUG_ON() failure, the helpers for adding a
node (hypfs_add_dir() and hypfs_add_leaf()) get a nofault parameter
causing the BUG() in case of a failure.

When supporting writable leafs the entry's write pointer will need to
be set to the function performing the write to the variable holding the
content. In case there are no special constraints this will be
hypfs_write_bool() for type XEN_HYPFS_TYPE_BOOL and hypfs_write_leaf()
for the other entry types.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V1:
- rename files from filesystem.* to hypfs.*
- add dummy write entry support
- rename hypercall filesystem_op to hypfs_op
- add support for unsigned integer entries

V2:
- test new entry name to be valid

V3:
- major rework, especially by supporting binary contents of entries
- addressed all comments

V4:
- sort #includes alphabetically (Wei Liu)
- add public interface structures to xlat.lst (Jan Beulich)
- let DIRENTRY_SIZE() add 1 for trailing nul byte (Jan Beulich)
- remove hypfs_add_entry() (Jan Beulich)
- len -> ulen (Jan Beulich)
- switch sequence of tests in hypfs_get_entry_rel() (Jan Beulich)
- add const qualifier (Jan Beulich)
- return -ENOBUFS if only direntry but no entry contents are returned
  (Jan Beulich)
- use xmalloc() instead of xzalloc() (Jan Beulich)
- better error handling in hypfs_write_leaf() (Jan Beulich)
- return -EOPNOTSUPP for unknown sub-command (Jan Beulich)
- use plain integers for enum-like constants in public interface
  (Jan Beulich)
- rename XEN_HYPFS_OP_read_contents to XEN_HYPFS_OP_read (Jan Beulich)
- add some comments in include/public/hypfs.h (Jan Beulich)
- use const_char for user parameter path (Jan Beulich)
- add helpers for XEN_HYPFS_TYPE_BOOL and XEN_HYPFS_TYPE_INT entry
  definitions (Jan Beulich)
- make statically defined entries __read_mostly (Jan Beulich)

V5:
- switch to xsm for privilege check

V6:
- use memchr() for testing correct string length (Jan Beulich)
- reject writing to non-string leafs with wrong length (Jan Beulich)
- only support bools of natural size (Julien Grall)
- adjust blank padding in header (Jan Beulich)
- adjust comments in public header (Jan Beulich)
- rename hypfs_string_set() and add comment (Jan Beulich)
- add common HYPFS_INIT helper macro (Jan Beulich)
- really check structures added to xlat.lst (Jan Beulich)
- add missing xsm parts (Jan Beulich)

V7:
- simplify compat check (Jan Beulich)
- add max write size (Jan Beulich)
- better length testing of written string (Jan Beulich)
---
 tools/flask/policy/modules/dom0.te  |   2 +-
 xen/arch/arm/traps.c                |   1 +
 xen/arch/x86/hvm/hypercall.c        |   1 +
 xen/arch/x86/hypercall.c            |   1 +
 xen/arch/x86/pv/hypercall.c         |   1 +
 xen/common/Makefile                 |   1 +
 xen/common/hypfs.c                  | 350 ++++++++++++++++++++++++++++++++++++
 xen/include/Makefile                |   1 +
 xen/include/public/hypfs.h          | 127 +++++++++++++
 xen/include/public/xen.h            |   1 +
 xen/include/xen/hypercall.h         |   8 +
 xen/include/xen/hypfs.h             | 116 ++++++++++++
 xen/include/xlat.lst                |   2 +
 xen/include/xsm/dummy.h             |   6 +
 xen/include/xsm/xsm.h               |   6 +
 xen/xsm/dummy.c                     |   1 +
 xen/xsm/flask/hooks.c               |   6 +
 xen/xsm/flask/policy/access_vectors |   2 +
 18 files changed, 632 insertions(+), 1 deletion(-)
 create mode 100644 xen/common/hypfs.c
 create mode 100644 xen/include/public/hypfs.h
 create mode 100644 xen/include/xen/hypfs.h

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 272f6a4f75..20925e38a2 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -11,7 +11,7 @@ allow dom0_t xen_t:xen {
 	mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
 	writeapic privprofile nonprivprofile kexec firmware sleep frequency
 	getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op
-	getscheduler setscheduler
+	getscheduler setscheduler hypfs_op
 };
 allow dom0_t xen_t:xen2 {
 	resource_op psr_cmt_op psr_alloc pmu_ctrl get_symbol
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 30c4c1830b..efc700b50b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1381,6 +1381,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
 #ifdef CONFIG_ARGO
     HYPERCALL(argo_op, 5),
 #endif
+    HYPERCALL(hypfs_op, 5),
 };
 
 #ifndef NDEBUG
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index cedc7f2ac5..5b15c3a155 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -148,6 +148,7 @@ static const hypercall_table_t hvm_hypercall_table[] = {
 #endif
     HYPERCALL(xenpmu_op),
     COMPAT_CALL(dm_op),
+    HYPERCALL(hypfs_op),
     HYPERCALL(arch_1)
 };
 
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 7f299d45c6..05a3f5e25b 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -73,6 +73,7 @@ const hypercall_args_t hypercall_args_table[NR_hypercalls] =
     ARGS(hvm_op, 2),
     ARGS(dm_op, 3),
 #endif
+    ARGS(hypfs_op, 5),
     ARGS(mca, 1),
     ARGS(arch_1, 1),
 };
diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index 17ddf9ea1f..83907d4f00 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -85,6 +85,7 @@ const hypercall_table_t pv_hypercall_table[] = {
     HYPERCALL(hvm_op),
     COMPAT_CALL(dm_op),
 #endif
+    HYPERCALL(hypfs_op),
     HYPERCALL(mca),
     HYPERCALL(arch_1),
 };
diff --git a/xen/common/Makefile b/xen/common/Makefile
index e8cde65370..022e5f7ca3 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -10,6 +10,7 @@ obj-y += domain.o
 obj-y += event_2l.o
 obj-y += event_channel.o
 obj-y += event_fifo.o
+obj-y += hypfs.o
 obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
 obj-$(CONFIG_GRANT_TABLE) += grant_table.o
 obj-y += guestcopy.o
diff --git a/xen/common/hypfs.c b/xen/common/hypfs.c
new file mode 100644
index 0000000000..986b829934
--- /dev/null
+++ b/xen/common/hypfs.c
@@ -0,0 +1,350 @@
+/******************************************************************************
+ *
+ * hypfs.c
+ *
+ * Simple sysfs-like file system for the hypervisor.
+ */
+
+#include <xen/err.h>
+#include <xen/guest_access.h>
+#include <xen/hypercall.h>
+#include <xen/hypfs.h>
+#include <xen/lib.h>
+#include <xen/rwlock.h>
+#include <public/hypfs.h>
+
+#ifdef CONFIG_COMPAT
+#include <compat/hypfs.h>
+CHECK_hypfs_dirlistentry;
+#endif
+
+#define DIRENTRY_NAME_OFF offsetof(struct xen_hypfs_dirlistentry, name)
+#define DIRENTRY_SIZE(name_len) \
+    (DIRENTRY_NAME_OFF +        \
+     ROUNDUP((name_len) + 1, alignof(struct xen_hypfs_direntry)))
+
+static DEFINE_RWLOCK(hypfs_lock);
+
+HYPFS_DIR_INIT(hypfs_root, "");
+
+static int add_entry(struct hypfs_entry_dir *parent, struct hypfs_entry *new)
+{
+    int ret = -ENOENT;
+    struct hypfs_entry *e;
+
+    write_lock(&hypfs_lock);
+
+    list_for_each_entry ( e, &parent->dirlist, list )
+    {
+        int cmp = strcmp(e->name, new->name);
+
+        if ( cmp > 0 )
+        {
+            ret = 0;
+            list_add_tail(&new->list, &e->list);
+            break;
+        }
+        if ( cmp == 0 )
+        {
+            ret = -EEXIST;
+            break;
+        }
+    }
+
+    if ( ret == -ENOENT )
+    {
+        ret = 0;
+        list_add_tail(&new->list, &parent->dirlist);
+    }
+
+    if ( !ret )
+    {
+        unsigned int sz = strlen(new->name);
+
+        parent->e.size += DIRENTRY_SIZE(sz);
+    }
+
+    write_unlock(&hypfs_lock);
+
+    return ret;
+}
+
+int hypfs_add_dir(struct hypfs_entry_dir *parent,
+                  struct hypfs_entry_dir *dir, bool nofault)
+{
+    int ret;
+
+    ret = add_entry(parent, &dir->e);
+    BUG_ON(nofault && ret);
+
+    return ret;
+}
+
+int hypfs_add_leaf(struct hypfs_entry_dir *parent,
+                   struct hypfs_entry_leaf *leaf, bool nofault)
+{
+    int ret;
+
+    if ( !leaf->content )
+        ret = -EINVAL;
+    else
+        ret = add_entry(parent, &leaf->e);
+    BUG_ON(nofault && ret);
+
+    return ret;
+}
+
+static int hypfs_get_path_user(char *buf,
+                               XEN_GUEST_HANDLE_PARAM(const_char) uaddr,
+                               unsigned long ulen)
+{
+    if ( ulen > XEN_HYPFS_MAX_PATHLEN )
+        return -EINVAL;
+
+    if ( copy_from_guest(buf, uaddr, ulen) )
+        return -EFAULT;
+
+    if ( memchr(buf, 0, ulen) != buf + ulen - 1 )
+        return -EINVAL;
+
+    return 0;
+}
+
+static struct hypfs_entry *hypfs_get_entry_rel(struct hypfs_entry_dir *dir,
+                                               const char *path)
+{
+    const char *end;
+    struct hypfs_entry *entry;
+    unsigned int name_len;
+
+    if ( dir->e.type != XEN_HYPFS_TYPE_DIR )
+        return NULL;
+
+    if ( !*path )
+        return &dir->e;
+
+    end = strchr(path, '/');
+    if ( !end )
+        end = strchr(path, '\0');
+    name_len = end - path;
+
+    list_for_each_entry ( entry, &dir->dirlist, list )
+    {
+        int cmp = strncmp(path, entry->name, name_len);
+        struct hypfs_entry_dir *d = container_of(entry,
+                                                 struct hypfs_entry_dir, e);
+
+        if ( cmp < 0 )
+            return NULL;
+        if ( !cmp && strlen(entry->name) == name_len )
+            return *end ? hypfs_get_entry_rel(d, end + 1) : entry;
+    }
+
+    return NULL;
+}
+
+struct hypfs_entry *hypfs_get_entry(const char *path)
+{
+    if ( path[0] != '/' )
+        return NULL;
+
+    return hypfs_get_entry_rel(&hypfs_root, path + 1);
+}
+
+int hypfs_read_dir(const struct hypfs_entry *entry,
+                   XEN_GUEST_HANDLE_PARAM(void) uaddr)
+{
+    const struct hypfs_entry_dir *d;
+    const struct hypfs_entry *e;
+    unsigned int size = entry->size;
+
+    d = container_of(entry, const struct hypfs_entry_dir, e);
+
+    list_for_each_entry ( e, &d->dirlist, list )
+    {
+        struct xen_hypfs_dirlistentry direntry;
+        unsigned int e_namelen = strlen(e->name);
+        unsigned int e_len = DIRENTRY_SIZE(e_namelen);
+
+        direntry.e.pad = 0;
+        direntry.e.type = e->type;
+        direntry.e.encoding = e->encoding;
+        direntry.e.content_len = e->size;
+        direntry.e.max_write_len = e->max_size;
+        direntry.off_next = list_is_last(&e->list, &d->dirlist) ? 0 : e_len;
+        if ( copy_to_guest(uaddr, &direntry, 1) )
+            return -EFAULT;
+
+        if ( copy_to_guest_offset(uaddr, DIRENTRY_NAME_OFF,
+                                  e->name, e_namelen + 1) )
+            return -EFAULT;
+
+        guest_handle_add_offset(uaddr, e_len);
+
+        ASSERT(e_len <= size);
+        size -= e_len;
+    }
+
+    return 0;
+}
+
+int hypfs_read_leaf(const struct hypfs_entry *entry,
+                    XEN_GUEST_HANDLE_PARAM(void) uaddr)
+{
+    const struct hypfs_entry_leaf *l;
+
+    l = container_of(entry, const struct hypfs_entry_leaf, e);
+
+    return copy_to_guest(uaddr, l->content, entry->size) ? -EFAULT: 0;
+}
+
+static int hypfs_read(const struct hypfs_entry *entry,
+                      XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+    struct xen_hypfs_direntry e;
+    long ret = -EINVAL;
+
+    if ( ulen < sizeof(e) )
+        goto out;
+
+    e.pad = 0;
+    e.type = entry->type;
+    e.encoding = entry->encoding;
+    e.content_len = entry->size;
+    e.max_write_len = entry->max_size;
+
+    ret = -EFAULT;
+    if ( copy_to_guest(uaddr, &e, 1) )
+        goto out;
+
+    ret = -ENOBUFS;
+    if ( ulen < entry->size + sizeof(e) )
+        goto out;
+
+    guest_handle_add_offset(uaddr, sizeof(e));
+
+    ret = entry->read(entry, uaddr);
+
+ out:
+    return ret;
+}
+
+int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
+                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+    char *buf;
+    int ret;
+
+    if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
+         leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
+        return -EDOM;
+
+    buf = xmalloc_array(char, ulen);
+    if ( !buf )
+        return -ENOMEM;
+
+    ret = -EFAULT;
+    if ( copy_from_guest(buf, uaddr, ulen) )
+        goto out;
+
+    ret = -EINVAL;
+    if ( leaf->e.type == XEN_HYPFS_TYPE_STRING &&
+         memchr(buf, 0, ulen) != (buf + ulen - 1) )
+        goto out;
+
+    ret = 0;
+    memcpy(leaf->write_ptr, buf, ulen);
+    leaf->e.size = ulen;
+
+ out:
+    xfree(buf);
+    return ret;
+}
+
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+    bool buf;
+
+    ASSERT(leaf->e.type == XEN_HYPFS_TYPE_BOOL && leaf->e.size == sizeof(bool));
+
+    if ( ulen != leaf->e.max_size )
+        return -EDOM;
+
+    if ( copy_from_guest(&buf, uaddr, ulen) )
+        return -EFAULT;
+
+    *(bool *)leaf->write_ptr = buf;
+
+    return 0;
+}
+
+static int hypfs_write(struct hypfs_entry *entry,
+                       XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+    struct hypfs_entry_leaf *l;
+
+    if ( !entry->write )
+        return -EACCES;
+
+    if ( ulen > entry->max_size )
+        return -ENOSPC;
+
+    l = container_of(entry, struct hypfs_entry_leaf, e);
+
+    return entry->write(l, uaddr, ulen);
+}
+
+long do_hypfs_op(unsigned int cmd,
+                 XEN_GUEST_HANDLE_PARAM(const_char) arg1, unsigned long arg2,
+                 XEN_GUEST_HANDLE_PARAM(void) arg3, unsigned long arg4)
+{
+    int ret;
+    struct hypfs_entry *entry;
+    static char path[XEN_HYPFS_MAX_PATHLEN];
+
+    if ( xsm_hypfs_op(XSM_PRIV) )
+        return -EPERM;
+
+    if ( cmd == XEN_HYPFS_OP_get_version )
+        return XEN_HYPFS_VERSION;
+
+    if ( cmd == XEN_HYPFS_OP_write_contents )
+        write_lock(&hypfs_lock);
+    else
+        read_lock(&hypfs_lock);
+
+    ret = hypfs_get_path_user(path, arg1, arg2);
+    if ( ret )
+        goto out;
+
+    entry = hypfs_get_entry(path);
+    if ( !entry )
+    {
+        ret = -ENOENT;
+        goto out;
+    }
+
+    switch ( cmd )
+    {
+    case XEN_HYPFS_OP_read:
+        ret = hypfs_read(entry, arg3, arg4);
+        break;
+
+    case XEN_HYPFS_OP_write_contents:
+        ret = hypfs_write(entry, arg3, arg4);
+        break;
+
+    default:
+        ret = -EOPNOTSUPP;
+        break;
+    }
+
+ out:
+    if ( cmd == XEN_HYPFS_OP_write_contents )
+        write_unlock(&hypfs_lock);
+    else
+        read_unlock(&hypfs_lock);
+
+    return ret;
+}
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 433bad9055..8b3d339a32 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -9,6 +9,7 @@ headers-y := \
     compat/event_channel.h \
     compat/features.h \
     compat/grant_table.h \
+    compat/hypfs.h \
     compat/kexec.h \
     compat/memory.h \
     compat/nmi.h \
diff --git a/xen/include/public/hypfs.h b/xen/include/public/hypfs.h
new file mode 100644
index 0000000000..f1c1b3e935
--- /dev/null
+++ b/xen/include/public/hypfs.h
@@ -0,0 +1,127 @@
+/******************************************************************************
+ * Xen Hypervisor Filesystem
+ *
+ * Copyright (c) 2019, SUSE Software Solutions Germany GmbH
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __XEN_PUBLIC_HYPFS_H__
+#define __XEN_PUBLIC_HYPFS_H__
+
+#include "xen.h"
+
+/*
+ * Definitions for the __HYPERVISOR_hypfs_op hypercall.
+ */
+
+/* Highest version number of the hypfs interface currently defined. */
+#define XEN_HYPFS_VERSION      1
+
+/* Maximum length of a path in the filesystem. */
+#define XEN_HYPFS_MAX_PATHLEN  1024
+
+struct xen_hypfs_direntry {
+    uint8_t type;
+#define XEN_HYPFS_TYPE_DIR     0
+#define XEN_HYPFS_TYPE_BLOB    1
+#define XEN_HYPFS_TYPE_STRING  2
+#define XEN_HYPFS_TYPE_UINT    3
+#define XEN_HYPFS_TYPE_INT     4
+#define XEN_HYPFS_TYPE_BOOL    5
+    uint8_t encoding;
+#define XEN_HYPFS_ENC_PLAIN    0
+#define XEN_HYPFS_ENC_GZIP     1
+    uint16_t pad;              /* Returned as 0. */
+    uint32_t content_len;      /* Current length of data. */
+    uint32_t max_write_len;    /* Max. length for writes (0 if read-only). */
+};
+
+struct xen_hypfs_dirlistentry {
+    struct xen_hypfs_direntry e;
+    /* Offset in bytes to next entry (0 == this is the last entry). */
+    uint16_t off_next;
+    /* Zero terminated entry name, possibly with some padding for alignment. */
+    char name[XEN_FLEX_ARRAY_DIM];
+};
+
+/*
+ * Hypercall operations.
+ */
+
+/*
+ * XEN_HYPFS_OP_get_version
+ *
+ * Read highest interface version supported by the hypervisor.
+ *
+ * Possible return values:
+ * >0: highest supported interface version
+ * <0: negative Xen errno value
+ */
+#define XEN_HYPFS_OP_get_version     0
+
+/*
+ * XEN_HYPFS_OP_read
+ *
+ * Read a filesystem entry.
+ *
+ * Returns the direntry and contents of an entry in the buffer supplied by the
+ * caller (struct xen_hypfs_direntry with the contents following directly
+ * after it).
+ * The data buffer must be at least the size of the direntry returned. If the
+ * data buffer was not large enough for all the data -ENOBUFS and no entry
+ * data is returned, but the direntry will contain the needed size for the
+ * returned data.
+ * The format of the contents is according to its entry type and encoding.
+ * The contents of a directory are multiple struct xen_hypfs_dirlistentry
+ * items.
+ *
+ * arg1: XEN_GUEST_HANDLE(path name)
+ * arg2: length of path name (including trailing zero byte)
+ * arg3: XEN_GUEST_HANDLE(data buffer written by hypervisor)
+ * arg4: data buffer size
+ *
+ * Possible return values:
+ * 0: success
+ * <0 : negative Xen errno value
+ */
+#define XEN_HYPFS_OP_read              1
+
+/*
+ * XEN_HYPFS_OP_write_contents
+ *
+ * Write contents of a filesystem entry.
+ *
+ * Writes an entry with the contents of a buffer supplied by the caller.
+ * The data type and encoding can't be changed. The size can be changed only
+ * for blobs and strings.
+ *
+ * arg1: XEN_GUEST_HANDLE(path name)
+ * arg2: length of path name (including trailing zero byte)
+ * arg3: XEN_GUEST_HANDLE(content buffer read by hypervisor)
+ * arg4: content buffer size
+ *
+ * Possible return values:
+ * 0: success
+ * <0 : negative Xen errno value
+ */
+#define XEN_HYPFS_OP_write_contents    2
+
+#endif /* __XEN_PUBLIC_HYPFS_H__ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 75b1619d0d..945ef30273 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -130,6 +130,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_argo_op              39
 #define __HYPERVISOR_xenpmu_op            40
 #define __HYPERVISOR_dm_op                41
+#define __HYPERVISOR_hypfs_op             42
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index ad8ad27b23..836a8b1ba8 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -150,6 +150,14 @@ do_dm_op(
     unsigned int nr_bufs,
     XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs);
 
+extern long
+do_hypfs_op(
+    unsigned int cmd,
+    XEN_GUEST_HANDLE_PARAM(const_char) arg1,
+    unsigned long arg2,
+    XEN_GUEST_HANDLE_PARAM(void) arg3,
+    unsigned long arg4);
+
 #ifdef CONFIG_COMPAT
 
 extern int
diff --git a/xen/include/xen/hypfs.h b/xen/include/xen/hypfs.h
new file mode 100644
index 0000000000..85588e2a59
--- /dev/null
+++ b/xen/include/xen/hypfs.h
@@ -0,0 +1,116 @@
+#ifndef __XEN_HYPFS_H__
+#define __XEN_HYPFS_H__
+
+#include <xen/list.h>
+#include <xen/string.h>
+#include <public/hypfs.h>
+
+struct hypfs_entry_leaf;
+
+struct hypfs_entry {
+    unsigned short type;
+    unsigned short encoding;
+    unsigned int size;
+    unsigned int max_size;
+    const char *name;
+    struct list_head list;
+    int (*read)(const struct hypfs_entry *entry,
+                XEN_GUEST_HANDLE_PARAM(void) uaddr);
+    int (*write)(struct hypfs_entry_leaf *leaf,
+                 XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+};
+
+struct hypfs_entry_leaf {
+    struct hypfs_entry e;
+    union {
+        const void *content;
+        void *write_ptr;
+    };
+};
+
+struct hypfs_entry_dir {
+    struct hypfs_entry e;
+    struct list_head dirlist;
+};
+
+#define HYPFS_DIR_INIT(var, nam)                  \
+    struct hypfs_entry_dir __read_mostly var = {  \
+        .e.type = XEN_HYPFS_TYPE_DIR,             \
+        .e.encoding = XEN_HYPFS_ENC_PLAIN,        \
+        .e.name = nam,                            \
+        .e.size = 0,                              \
+        .e.max_size = 0,                          \
+        .e.list = LIST_HEAD_INIT(var.e.list),     \
+        .e.read = hypfs_read_dir,                 \
+        .dirlist = LIST_HEAD_INIT(var.dirlist),   \
+    }
+
+#define HYPFS_VARSIZE_INIT(var, typ, nam, msz)    \
+    struct hypfs_entry_leaf __read_mostly var = { \
+        .e.type = typ,                            \
+        .e.encoding = XEN_HYPFS_ENC_PLAIN,        \
+        .e.name = nam,                            \
+        .e.max_size = msz,                        \
+        .e.read = hypfs_read_leaf,                \
+    }
+
+/* Content and size need to be set via hypfs_string_set_reference(). */
+#define HYPFS_STRING_INIT(var, nam)               \
+    HYPFS_VARSIZE_INIT(var, XEN_HYPFS_TYPE_STRING, nam, 0)
+
+/*
+ * Set content and size of a XEN_HYPFS_TYPE_STRING node. The node will point
+ * to str, so any later modification of *str should be followed by a call
+ * to hypfs_string_set_reference() in order to update the size of the node
+ * data.
+ */
+static inline void hypfs_string_set_reference(struct hypfs_entry_leaf *leaf,
+                                              const char *str)
+{
+    leaf->content = str;
+    leaf->e.size = strlen(str) + 1;
+}
+
+#define HYPFS_FIXEDSIZE_INIT(var, typ, nam, contvar, wr) \
+    struct hypfs_entry_leaf __read_mostly var = {        \
+        .e.type = typ,                                   \
+        .e.encoding = XEN_HYPFS_ENC_PLAIN,               \
+        .e.name = nam,                                   \
+        .e.size = sizeof(contvar),                       \
+        .e.max_size = wr * sizeof(contvar),              \
+        .e.read = hypfs_read_leaf,                       \
+        .content = &contvar,                             \
+    }
+
+#define HYPFS_UINT_INIT(var, nam, contvar)          \
+    HYPFS_FIXEDSIZE_INIT(var, XEN_HYPFS_TYPE_UINT, nam, contvar, 0)
+#define HYPFS_UINT_INIT_WRITABLE(var, nam, contvar) \
+    HYPFS_FIXEDSIZE_INIT(var, XEN_HYPFS_TYPE_UINT, nam, contvar, 1)
+
+#define HYPFS_INT_INIT(var, nam, contvar)           \
+    HYPFS_FIXEDSIZE_INIT(var, XEN_HYPFS_TYPE_INT, nam, contvar, 0)
+#define HYPFS_INT_INIT_WRITABLE(var, nam, contvar)  \
+    HYPFS_FIXEDSIZE_INIT(var, XEN_HYPFS_TYPE_INT, nam, contvar, 1)
+
+#define HYPFS_BOOL_INIT(var, nam, contvar)          \
+    HYPFS_FIXEDSIZE_INIT(var, XEN_HYPFS_TYPE_BOOL, nam, contvar, 0)
+#define HYPFS_BOOL_INIT_WRITABLE(var, nam, contvar) \
+    HYPFS_FIXEDSIZE_INIT(var, XEN_HYPFS_TYPE_BOOL, nam, contvar, 1)
+
+extern struct hypfs_entry_dir hypfs_root;
+
+struct hypfs_entry *hypfs_get_entry(const char *path);
+int hypfs_add_dir(struct hypfs_entry_dir *parent,
+                  struct hypfs_entry_dir *dir, bool nofault);
+int hypfs_add_leaf(struct hypfs_entry_dir *parent,
+                   struct hypfs_entry_leaf *leaf, bool nofault);
+int hypfs_read_dir(const struct hypfs_entry *entry,
+                   XEN_GUEST_HANDLE_PARAM(void) uaddr);
+int hypfs_read_leaf(const struct hypfs_entry *entry,
+                    XEN_GUEST_HANDLE_PARAM(void) uaddr);
+int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
+                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+
+#endif /* __XEN_HYPFS_H__ */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 95f5e5592b..0921d4a8d0 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -86,6 +86,8 @@
 ?	vcpu_hvm_context		hvm/hvm_vcpu.h
 ?	vcpu_hvm_x86_32			hvm/hvm_vcpu.h
 ?	vcpu_hvm_x86_64			hvm/hvm_vcpu.h
+?	hypfs_direntry			hypfs.h
+?	hypfs_dirlistentry		hypfs.h
 ?	kexec_exec			kexec.h
 !	kexec_image			kexec.h
 !	kexec_range			kexec.h
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 295dd67c48..2368acebed 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -434,6 +434,12 @@ static XSM_INLINE int xsm_page_offline(XSM_DEFAULT_ARG uint32_t cmd)
     return xsm_default_action(action, current->domain, NULL);
 }
 
+static XSM_INLINE int xsm_hypfs_op(XSM_DEFAULT_VOID)
+{
+    XSM_ASSERT_ACTION(XSM_PRIV);
+    return xsm_default_action(action, current->domain, NULL);
+}
+
 static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
 {
     return -ENOSYS;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index e22d6160b5..a80bcf3e42 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -127,6 +127,7 @@ struct xsm_operations {
     int (*resource_setup_misc) (void);
 
     int (*page_offline)(uint32_t cmd);
+    int (*hypfs_op)(void);
 
     long (*do_xsm_op) (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op);
 #ifdef CONFIG_COMPAT
@@ -536,6 +537,11 @@ static inline int xsm_page_offline(xsm_default_t def, uint32_t cmd)
     return xsm_ops->page_offline(cmd);
 }
 
+static inline int xsm_hypfs_op(xsm_default_t def)
+{
+    return xsm_ops->hypfs_op();
+}
+
 static inline long xsm_do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
 {
     return xsm_ops->do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 5705e52791..d4cce68089 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -103,6 +103,7 @@ void __init xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, resource_setup_misc);
 
     set_to_dummy_if_null(ops, page_offline);
+    set_to_dummy_if_null(ops, hypfs_op);
     set_to_dummy_if_null(ops, hvm_param);
     set_to_dummy_if_null(ops, hvm_control);
     set_to_dummy_if_null(ops, hvm_param_nested);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8af8602b46..74af7df7d5 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1172,6 +1172,11 @@ static inline int flask_page_offline(uint32_t cmd)
     }
 }
 
+static inline int flask_hypfs_op(void)
+{
+    return domain_has_xen(current->domain, XEN__HYPFS_OP);
+}
+
 static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
@@ -1811,6 +1816,7 @@ static struct xsm_operations flask_ops = {
     .resource_setup_misc = flask_resource_setup_misc,
 
     .page_offline = flask_page_offline,
+    .hypfs_op = flask_hypfs_op,
     .hvm_param = flask_hvm_param,
     .hvm_control = flask_hvm_param,
     .hvm_param_nested = flask_hvm_param_nested,
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index c055c14c26..c9e385fb9b 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -67,6 +67,8 @@ class xen
     lockprof
 # XEN_SYSCTL_cpupool_op
     cpupool_op
+# hypfs hypercall
+    hypfs_op
 # XEN_SYSCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_getinfo, XEN_SYSCTL_sched_id, XEN_DOMCTL_SCHEDOP_getvcpuinfo
     getscheduler
 # XEN_SYSCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_putinfo, XEN_DOMCTL_SCHEDOP_putvcpuinfo
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK23D-0003pe-Al; Thu, 02 Apr 2020 15:46:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK23B-0003oj-U6
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:37 +0000
X-Inumbo-ID: 1a56d96c-74f9-11ea-bc01-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1a56d96c-74f9-11ea-bc01-12813bfff9fa;
 Thu, 02 Apr 2020 15:46:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5C92EAE61;
 Thu,  2 Apr 2020 15:46:21 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 10/12] tools/libxl: use libxenhypfs for setting xen runtime
 parameters
Date: Thu,  2 Apr 2020 17:46:14 +0200
Message-Id: <20200402154616.16927-11-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Instead of xc_set_parameters() use xenhypfs_write() for setting
parameters of the hypervisor.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
 tools/Rules.mk               |  2 +-
 tools/libxl/Makefile         |  3 ++-
 tools/libxl/libxl.c          | 53 +++++++++++++++++++++++++++++++++++++++-----
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/xenlight.pc.in   |  2 +-
 tools/xl/xl_misc.c           |  1 -
 6 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 711e9598cd..ee0f130276 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -180,7 +180,7 @@ CFLAGS += -O2 -fomit-frame-pointer
 endif
 
 CFLAGS_libxenlight = -I$(XEN_XENLIGHT) $(CFLAGS_libxenctrl) $(CFLAGS_xeninclude)
-SHDEPS_libxenlight = $(SHLIB_libxenctrl) $(SHLIB_libxenstore)
+SHDEPS_libxenlight = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) $(SHLIB_libxenhypfs)
 LDLIBS_libxenlight = $(SHDEPS_libxenlight) $(XEN_XENLIGHT)/libxenlight$(libextension)
 SHLIB_libxenlight  = $(SHDEPS_libxenlight) -Wl,-rpath-link=$(XEN_XENLIGHT)
 
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 69fcf21577..a89ebab0b4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxentoollog) $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libxentoolcore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxentoollog) $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenhypfs) $(LDLIBS_libxenstore) $(LDLIBS_libxentoolcore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 ifeq ($(CONFIG_LIBNL),y)
 LIBXL_LIBS += $(LIBNL3_LIBS)
 endif
@@ -33,6 +33,7 @@ CFLAGS_LIBXL += $(CFLAGS_libxentoolcore)
 CFLAGS_LIBXL += $(CFLAGS_libxenevtchn)
 CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
 CFLAGS_LIBXL += $(CFLAGS_libxenguest)
+CFLAGS_LIBXL += $(CFLAGS_libxenhypfs)
 CFLAGS_LIBXL += $(CFLAGS_libxenstore)
 ifeq ($(CONFIG_LIBNL),y)
 CFLAGS_LIBXL += $(LIBNL3_CFLAGS)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f60fd3e4fd..621acc88f3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -663,15 +663,56 @@ int libxl_set_parameters(libxl_ctx *ctx, char *params)
 {
     int ret;
     GC_INIT(ctx);
+    char *par, *val, *end, *path;
+    xenhypfs_handle *hypfs;
 
-    ret = xc_set_parameters(ctx->xch, params);
-    if (ret < 0) {
-        LOGEV(ERROR, ret, "setting parameters");
-        GC_FREE;
-        return ERROR_FAIL;
+    hypfs = xenhypfs_open(ctx->lg, 0);
+    if (!hypfs) {
+        LOGE(ERROR, "opening Xen hypfs");
+        ret = ERROR_FAIL;
+        goto out;
     }
+
+    while (isblank(*params))
+        params++;
+
+    for (par = params; *par; par = end) {
+        end = strchr(par, ' ');
+        if (!end)
+            end = par + strlen(par);
+
+        val = strchr(par, '=');
+        if (val > end)
+            val = NULL;
+        if (!val && !strncmp(par, "no", 2)) {
+            path = libxl__sprintf(gc, "/params/%s", par + 2);
+            path[end - par - 2 + 8] = 0;
+            val = "no";
+            par += 2;
+        } else {
+            path = libxl__sprintf(gc, "/params/%s", par);
+            path[val - par + 8] = 0;
+            val = libxl__strndup(gc, val + 1, end - val - 1);
+        }
+
+	LOG(DEBUG, "setting node \"%s\" to value \"%s\"", path, val);
+        ret = xenhypfs_write(hypfs, path, val);
+        if (ret < 0) {
+            LOGE(ERROR, "setting parameters");
+            ret = ERROR_FAIL;
+            goto out;
+        }
+
+        while (isblank(*end))
+            end++;
+    }
+
+    ret = 0;
+
+out:
+    xenhypfs_close(hypfs);
     GC_FREE;
-    return 0;
+    return ret;
 }
 
 static int fd_set_flags(libxl_ctx *ctx, int fd,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5f39e44cb9..7153beb8f8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -56,6 +56,7 @@
 #define XC_WANT_COMPAT_MAP_FOREIGN_API
 #include <xenctrl.h>
 #include <xenguest.h>
+#include <xenhypfs.h>
 #include <xc_dom.h>
 
 #include <xen-tools/libs.h>
diff --git a/tools/libxl/xenlight.pc.in b/tools/libxl/xenlight.pc.in
index c0f769fd20..6b351ba096 100644
--- a/tools/libxl/xenlight.pc.in
+++ b/tools/libxl/xenlight.pc.in
@@ -9,4 +9,4 @@ Description: The Xenlight library for Xen hypervisor
 Version: @@version@@
 Cflags: -I${includedir}
 Libs: @@libsflag@@${libdir} -lxenlight
-Requires.private: xentoollog,xenevtchn,xencontrol,xenguest,xenstore
+Requires.private: xentoollog,xenevtchn,xencontrol,xenguest,xenstore,xenhypfs
diff --git a/tools/xl/xl_misc.c b/tools/xl/xl_misc.c
index 20ed605f4f..08f0fb6dc9 100644
--- a/tools/xl/xl_misc.c
+++ b/tools/xl/xl_misc.c
@@ -168,7 +168,6 @@ int main_set_parameters(int argc, char **argv)
 
     if (libxl_set_parameters(ctx, params)) {
         fprintf(stderr, "cannot set parameters: %s\n", params);
-        fprintf(stderr, "Use \"xl dmesg\" to look for possible reason.\n");
         return EXIT_FAILURE;
     }
 
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK23H-0003tn-Sn; Thu, 02 Apr 2020 15:46:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK23G-0003sa-IQ
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:42 +0000
X-Inumbo-ID: 1a87c606-74f9-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1a87c606-74f9-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 15:46:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E8619AE52;
 Thu,  2 Apr 2020 15:46:20 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
Date: Thu,  2 Apr 2020 17:46:12 +0200
Message-Id: <20200402154616.16927-9-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add the /buildinfo/config entry to the hypervisor filesystem. This
entry contains the .config file used to build the hypervisor.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V3:
- store data in gzip format
- use binfile mechanism to create data file
- move code to kernel.c

V6:
- add config item for the /buildinfo/config (Jan Beulich)
- make config related variables const in kernel.h (Jan Beulich)

V7:
- update doc (Jan Beulich)
- use "rm -f" in Makefile (Jan Beulich)
---
 .gitignore                   |  2 ++
 docs/misc/hypfs-paths.pandoc |  4 ++++
 xen/common/Kconfig           | 10 ++++++++++
 xen/common/Makefile          | 12 ++++++++++++
 xen/common/kernel.c          | 15 +++++++++++++++
 xen/include/xen/kernel.h     |  3 +++
 6 files changed, 46 insertions(+)

diff --git a/.gitignore b/.gitignore
index fd5610718d..bc8e053ccb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -297,6 +297,8 @@ xen/arch/*/efi/boot.c
 xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
 xen/arch/*/efi/runtime.c
+xen/common/config_data.S
+xen/common/config.gz
 xen/include/headers*.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index e392feff27..f134c505d6 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -133,6 +133,10 @@ Information about the compile domain.
 
 The compiler used to build Xen.
 
+#### /buildinfo/config = STRING [CONFIG_HYPFS_CONFIG]
+
+The contents of the `xen/.config` file at the time of the hypervisor build.
+
 #### /buildinfo/version/
 
 A directory containing version information of the hypervisor.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index a6914fcae9..c3303c8dfe 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -353,6 +353,16 @@ config DOM0_MEM
 
 	  Leave empty if you are not sure what to specify.
 
+config HYPFS_CONFIG
+	bool "Provide hypervisor .config via hypfs entry"
+	default y
+	---help---
+	  When enabled the contents of the .config file used to build the
+	  hypervisor are provided via the hypfs entry /buildinfo/config.
+
+	  Disable this option in case you want to spare some memory or you
+	  want to hide the .config contents from dom0.
+
 config TRACEBUFFER
 	bool "Enable tracing infrastructure" if EXPERT = "y"
 	default y
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 022e5f7ca3..3ae9f3420b 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
 obj-$(CONFIG_ARGO) += argo.o
 obj-y += bitmap.o
 obj-y += bsearch.o
+obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
 obj-$(CONFIG_CORE_PARKING) += core_parking.o
 obj-y += cpu.o
 obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
@@ -73,3 +74,14 @@ obj-$(CONFIG_UBSAN) += ubsan/
 
 obj-$(CONFIG_NEEDS_LIBELF) += libelf/
 obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/
+
+config.gz: ../.config
+	gzip -c $< >$@
+
+config_data.o: config.gz
+
+config_data.S: $(XEN_ROOT)/xen/tools/binfile
+	$(XEN_ROOT)/xen/tools/binfile $@ config.gz xen_config_data
+
+clean::
+	rm -f config_data.S config.gz 2>/dev/null
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index da6e4b4444..4b7bc28afb 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -389,6 +389,16 @@ static HYPFS_STRING_INIT(compile_date, "compile_date");
 static HYPFS_STRING_INIT(compile_domain, "compile_domain");
 static HYPFS_STRING_INIT(extra, "extra");
 
+#ifdef CONFIG_HYPFS_CONFIG
+static struct hypfs_entry_leaf config = {
+    .e.type = XEN_HYPFS_TYPE_STRING,
+    .e.encoding = XEN_HYPFS_ENC_GZIP,
+    .e.name = "config",
+    .e.read = hypfs_read_leaf,
+    .content = &xen_config_data
+};
+#endif
+
 static int __init buildinfo_init(void)
 {
     hypfs_add_dir(&hypfs_root, &buildinfo, true);
@@ -414,6 +424,11 @@ static int __init buildinfo_init(void)
     hypfs_add_leaf(&version, &major, true);
     hypfs_add_leaf(&version, &minor, true);
 
+#ifdef CONFIG_HYPFS_CONFIG
+    config.e.size = xen_config_data_size;
+    hypfs_add_leaf(&buildinfo, &config, true);
+#endif
+
     return 0;
 }
 __initcall(buildinfo_init);
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index 548b64da9f..02e3281f52 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -100,5 +100,8 @@ extern enum system_state {
 
 bool_t is_active_kernel_text(unsigned long addr);
 
+extern const char xen_config_data;
+extern const unsigned int xen_config_data_size;
+
 #endif /* _LINUX_KERNEL_H */
 
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK23I-0003u3-72; Thu, 02 Apr 2020 15:46:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK23G-0003st-UQ
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:42 +0000
X-Inumbo-ID: 1a56d96b-74f9-11ea-bc01-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1a56d96b-74f9-11ea-bc01-12813bfff9fa;
 Thu, 02 Apr 2020 15:46:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7F0CDAE71;
 Thu,  2 Apr 2020 15:46:21 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 11/12] tools/libxc: remove xc_set_parameters()
Date: Thu,  2 Apr 2020 17:46:15 +0200
Message-Id: <20200402154616.16927-12-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

There is no user of xc_set_parameters() left, so remove it.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
 tools/libxc/include/xenctrl.h |  1 -
 tools/libxc/xc_misc.c         | 21 ---------------------
 2 files changed, 22 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 58fa931de1..b882f720f2 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1226,7 +1226,6 @@ int xc_readconsolering(xc_interface *xch,
                        int clear, int incremental, uint32_t *pindex);
 
 int xc_send_debug_keys(xc_interface *xch, const char *keys);
-int xc_set_parameters(xc_interface *xch, const char *params);
 
 typedef struct xen_sysctl_physinfo xc_physinfo_t;
 typedef struct xen_sysctl_cputopo xc_cputopo_t;
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index fe477bf344..3820394413 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -187,27 +187,6 @@ int xc_send_debug_keys(xc_interface *xch, const char *keys)
     return ret;
 }
 
-int xc_set_parameters(xc_interface *xch, const char *params)
-{
-    int ret, len = strlen(params);
-    DECLARE_SYSCTL;
-    DECLARE_HYPERCALL_BOUNCE_IN(params, len);
-
-    if ( xc_hypercall_bounce_pre(xch, params) )
-        return -1;
-
-    sysctl.cmd = XEN_SYSCTL_set_parameter;
-    set_xen_guest_handle(sysctl.u.set_parameter.params, params);
-    sysctl.u.set_parameter.size = len;
-    memset(sysctl.u.set_parameter.pad, 0, sizeof(sysctl.u.set_parameter.pad));
-
-    ret = do_sysctl(xch, &sysctl);
-
-    xc_hypercall_bounce_post(xch, params);
-
-    return ret;
-}
-
 int xc_physinfo(xc_interface *xch,
                 xc_physinfo_t *put_info)
 {
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK23N-00040H-Gc; Thu, 02 Apr 2020 15:46:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK23L-0003xe-Hg
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:47 +0000
X-Inumbo-ID: 1a86b2ac-74f9-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1a86b2ac-74f9-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 15:46:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A62C9AE50;
 Thu,  2 Apr 2020 15:46:20 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 07/12] xen: provide version information in hypfs
Date: Thu,  2 Apr 2020 17:46:11 +0200
Message-Id: <20200402154616.16927-8-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Provide version and compile information in /buildinfo/ node of the
Xen hypervisor file system. As this information is accessible by dom0
only no additional security problem arises.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
V3:
- new patch

V4:
- add __read_mostly annotations (Jan Beulich)
---
 docs/misc/hypfs-paths.pandoc | 45 ++++++++++++++++++++++++++++++++++++++++++++
 xen/common/kernel.c          | 45 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+)

diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index b9f50f6998..e392feff27 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -103,3 +103,48 @@ A populated Xen hypervisor file system might look like the following example:
 #### /
 
 The root of the hypervisor file system.
+
+#### /buildinfo/
+
+A directory containing static information generated while building the
+hypervisor.
+
+#### /buildinfo/changeset = STRING
+
+Git commit of the hypervisor.
+
+#### /buildinfo/compileinfo/
+
+A directory containing information about compilation of Xen.
+
+#### /buildinfo/compileinfo/compile_by = STRING
+
+Information who compiled the hypervisor.
+
+#### /buildinfo/compileinfo/compile_date = STRING
+
+Date of the hypervisor compilation.
+
+#### /buildinfo/compileinfo/compile_domain = STRING
+
+Information about the compile domain.
+
+#### /buildinfo/compileinfo/compiler = STRING
+
+The compiler used to build Xen.
+
+#### /buildinfo/version/
+
+A directory containing version information of the hypervisor.
+
+#### /buildinfo/version/extra = STRING
+
+Extra version information.
+
+#### /buildinfo/version/major = INTEGER
+
+The major version of Xen.
+
+#### /buildinfo/version/minor = INTEGER
+
+The minor version of Xen.
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 22941cec94..da6e4b4444 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -13,6 +13,7 @@
 #include <xen/paging.h>
 #include <xen/guest_access.h>
 #include <xen/hypercall.h>
+#include <xen/hypfs.h>
 #include <xsm/xsm.h>
 #include <asm/current.h>
 #include <public/version.h>
@@ -373,6 +374,50 @@ void __init do_initcalls(void)
         (*call)();
 }
 
+static unsigned int __read_mostly major_version;
+static unsigned int __read_mostly minor_version;
+
+static HYPFS_DIR_INIT(buildinfo, "buildinfo");
+static HYPFS_DIR_INIT(compileinfo, "compileinfo");
+static HYPFS_DIR_INIT(version, "version");
+static HYPFS_UINT_INIT(major, "major", major_version);
+static HYPFS_UINT_INIT(minor, "minor", minor_version);
+static HYPFS_STRING_INIT(changeset, "changeset");
+static HYPFS_STRING_INIT(compiler, "compiler");
+static HYPFS_STRING_INIT(compile_by, "compile_by");
+static HYPFS_STRING_INIT(compile_date, "compile_date");
+static HYPFS_STRING_INIT(compile_domain, "compile_domain");
+static HYPFS_STRING_INIT(extra, "extra");
+
+static int __init buildinfo_init(void)
+{
+    hypfs_add_dir(&hypfs_root, &buildinfo, true);
+
+    hypfs_string_set_reference(&changeset, xen_changeset());
+    hypfs_add_leaf(&buildinfo, &changeset, true);
+
+    hypfs_add_dir(&buildinfo, &compileinfo, true);
+    hypfs_string_set_reference(&compiler, xen_compiler());
+    hypfs_string_set_reference(&compile_by, xen_compile_by());
+    hypfs_string_set_reference(&compile_date, xen_compile_date());
+    hypfs_string_set_reference(&compile_domain, xen_compile_domain());
+    hypfs_add_leaf(&compileinfo, &compiler, true);
+    hypfs_add_leaf(&compileinfo, &compile_by, true);
+    hypfs_add_leaf(&compileinfo, &compile_date, true);
+    hypfs_add_leaf(&compileinfo, &compile_domain, true);
+
+    major_version = xen_major_version();
+    minor_version = xen_minor_version();
+    hypfs_add_dir(&buildinfo, &version, true);
+    hypfs_string_set_reference(&extra, xen_extra_version());
+    hypfs_add_leaf(&version, &extra, true);
+    hypfs_add_leaf(&version, &major, true);
+    hypfs_add_leaf(&version, &minor, true);
+
+    return 0;
+}
+__initcall(buildinfo_init);
+
 # define DO(fn) long do_##fn
 
 #endif
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK23Q-00043s-Sp; Thu, 02 Apr 2020 15:46:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK23Q-00043W-Hk
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:52 +0000
X-Inumbo-ID: 1aed7d02-74f9-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1aed7d02-74f9-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 15:46:24 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CB6CBAEA2;
 Thu,  2 Apr 2020 15:46:21 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 12/12] xen: remove XEN_SYSCTL_set_parameter support
Date: Thu,  2 Apr 2020 17:46:16 +0200
Message-Id: <20200402154616.16927-13-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The functionality of XEN_SYSCTL_set_parameter is available via hypfs
now, so it can be removed.

This allows to remove the kernel_param structure for runtime parameters
by putting the now only used structure element into the hypfs node
structure of the runtime parameters.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
V6:
- new patch

V7:
- only comment out definition of XEN_SYSCTL_set_parameter (Jan Beulich)
---
 tools/flask/policy/modules/dom0.te  |  2 +-
 xen/arch/arm/xen.lds.S              |  5 ----
 xen/arch/x86/xen.lds.S              |  5 ----
 xen/common/hypfs.c                  | 12 +--------
 xen/common/kernel.c                 | 11 --------
 xen/common/sysctl.c                 | 36 --------------------------
 xen/include/public/sysctl.h         | 19 +-------------
 xen/include/xen/hypfs.h             |  2 --
 xen/include/xen/lib.h               |  1 -
 xen/include/xen/param.h             | 50 +++++++------------------------------
 xen/xsm/flask/hooks.c               |  3 ---
 xen/xsm/flask/policy/access_vectors |  2 --
 12 files changed, 12 insertions(+), 136 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 20925e38a2..0a63ce15b6 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -16,7 +16,7 @@ allow dom0_t xen_t:xen {
 allow dom0_t xen_t:xen2 {
 	resource_op psr_cmt_op psr_alloc pmu_ctrl get_symbol
 	get_cpu_levelling_caps get_cpu_featureset livepatch_op
-	coverage_op set_parameter
+	coverage_op
 };
 
 # Allow dom0 to use all XENVER_ subops that have checks.
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index d31bed580d..9a535ca316 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -54,11 +54,6 @@ SECTIONS
        *(.data.rel.ro)
        *(.data.rel.ro.*)
 
-       . = ALIGN(POINTER_ALIGN);
-       __param_start = .;
-       *(.data.param)
-       __param_end = .;
-
        __proc_info_start = .;
        *(.proc.info)
        __proc_info_end = .;
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 21a37f0f57..88f14e5e59 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -128,11 +128,6 @@ SECTIONS
        *(.ex_table.pre)
        __stop___pre_ex_table = .;
 
-       . = ALIGN(POINTER_ALIGN);
-       __param_start = .;
-       *(.data.param)
-       __param_end = .;
-
 #if defined(CONFIG_HAS_VPCI) && defined(CONFIG_LATE_HWDOM)
        . = ALIGN(POINTER_ALIGN);
        __start_vpci_array = .;
diff --git a/xen/common/hypfs.c b/xen/common/hypfs.c
index df951526db..00eb180998 100644
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -300,7 +300,7 @@ int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
         goto out;
 
     p = container_of(leaf, struct param_hypfs, hypfs);
-    ret = p->param->par.func(buf);
+    ret = p->func(buf);
 
     if ( !ret )
         leaf->e.size = ulen;
@@ -379,13 +379,3 @@ long do_hypfs_op(unsigned int cmd,
 
     return ret;
 }
-
-void hypfs_write_lock(void)
-{
-    write_lock(&hypfs_lock);
-}
-
-void hypfs_write_unlock(void)
-{
-    write_unlock(&hypfs_lock);
-}
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 7516242337..876830f5fa 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -196,17 +196,6 @@ static void __init _cmdline_parse(const char *cmdline)
     parse_params(cmdline, __setup_start, __setup_end);
 }
 
-int runtime_parse(const char *line)
-{
-    int ret;
-
-    hypfs_write_lock();
-    ret = parse_params(line, __param_start, __param_end);
-    hypfs_write_unlock();
-
-    return ret;
-}
-
 /**
  *    cmdline_parse -- parses the xen command line.
  * If CONFIG_CMDLINE is set, it would be parsed prior to @cmdline.
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 1c6a817476..ec916424e5 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -471,42 +471,6 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
             copyback = 1;
         break;
 
-    case XEN_SYSCTL_set_parameter:
-    {
-#define XEN_SET_PARAMETER_MAX_SIZE 1023
-        char *params;
-
-        if ( op->u.set_parameter.pad[0] || op->u.set_parameter.pad[1] ||
-             op->u.set_parameter.pad[2] )
-        {
-            ret = -EINVAL;
-            break;
-        }
-        if ( op->u.set_parameter.size > XEN_SET_PARAMETER_MAX_SIZE )
-        {
-            ret = -E2BIG;
-            break;
-        }
-        params = xmalloc_bytes(op->u.set_parameter.size + 1);
-        if ( !params )
-        {
-            ret = -ENOMEM;
-            break;
-        }
-        if ( copy_from_guest(params, op->u.set_parameter.params,
-                             op->u.set_parameter.size) )
-            ret = -EFAULT;
-        else
-        {
-            params[op->u.set_parameter.size] = 0;
-            ret = runtime_parse(params);
-        }
-
-        xfree(params);
-
-        break;
-    }
-
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3a08c512e8..f635c0c2db 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -1026,22 +1026,6 @@ struct xen_sysctl_livepatch_op {
     } u;
 };
 
-/*
- * XEN_SYSCTL_set_parameter
- *
- * Change hypervisor parameters at runtime.
- * The input string is parsed similar to the boot parameters.
- * Parameters are a single string terminated by a NUL byte of max. size
- * characters. Multiple settings can be specified by separating them
- * with blanks.
- */
-
-struct xen_sysctl_set_parameter {
-    XEN_GUEST_HANDLE_64(const_char) params; /* IN: pointer to parameters. */
-    uint16_t size;                          /* IN: size of parameters. */
-    uint16_t pad[3];                        /* IN: MUST be zero. */
-};
-
 #if defined(__i386__) || defined(__x86_64__)
 /*
  * XEN_SYSCTL_get_cpu_policy (x86 specific)
@@ -1106,7 +1090,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_get_cpu_levelling_caps        25
 #define XEN_SYSCTL_get_cpu_featureset            26
 #define XEN_SYSCTL_livepatch_op                  27
-#define XEN_SYSCTL_set_parameter                 28
+/* #define XEN_SYSCTL_set_parameter                 28 */
 #define XEN_SYSCTL_get_cpu_policy                29
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
@@ -1135,7 +1119,6 @@ struct xen_sysctl {
         struct xen_sysctl_cpu_levelling_caps cpu_levelling_caps;
         struct xen_sysctl_cpu_featureset    cpu_featureset;
         struct xen_sysctl_livepatch_op      livepatch;
-        struct xen_sysctl_set_parameter     set_parameter;
 #if defined(__i386__) || defined(__x86_64__)
         struct xen_sysctl_cpu_policy        cpu_policy;
 #endif
diff --git a/xen/include/xen/hypfs.h b/xen/include/xen/hypfs.h
index 3c3b1b056d..c0ab26b02e 100644
--- a/xen/include/xen/hypfs.h
+++ b/xen/include/xen/hypfs.h
@@ -114,7 +114,5 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
                      XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
 int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
                        XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
-void hypfs_write_lock(void);
-void hypfs_write_unlock(void);
 
 #endif /* __XEN_HYPFS_H__ */
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 5d718bbdba..7e425e28cd 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -75,7 +75,6 @@
 struct domain;
 
 void cmdline_parse(const char *cmdline);
-int runtime_parse(const char *line);
 int parse_bool(const char *s, const char *e);
 
 /**
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index 5cf2149279..980528e417 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -27,16 +27,14 @@ struct kernel_param {
 };
 
 struct param_hypfs {
-    const struct kernel_param *param;
     struct hypfs_entry_leaf hypfs;
     void (*init_leaf)(struct param_hypfs *par);
+    int (*func)(const char *);
 };
 
 extern const struct kernel_param __setup_start[], __setup_end[];
-extern const struct kernel_param __param_start[], __param_end[];
 extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
 
-#define __dataparam       __used_section(".data.param")
 #define __paramhypfs      __used_section(".data.paramhypfs")
 
 #define __param(att)      static const att \
@@ -87,7 +85,6 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
         { .name = setup_str_ign,            \
           .type = OPT_IGNORE }
 
-#define __rtparam         __param(__dataparam)
 #define __paramfs         static __paramhypfs \
     __attribute__((__aligned__(sizeof(void *)))) struct param_hypfs
 
@@ -104,28 +101,17 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
 
 /* initfunc needs to set size and content, e.g. via custom_runtime_set_var(). */
 #define custom_runtime_only_param(_name, _var, initfunc) \
-    __rtparam __rtpar_##_var = \
-      { .name = _name, \
-          .type = OPT_CUSTOM, \
-          .par.func = _var }; \
     __paramfs __parfs_##_var = \
-        { .param = &__rtpar_##_var, \
-          .init_leaf = initfunc, \
-          .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
+        { .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
           .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
           .hypfs.e.name = _name, \
           .hypfs.e.read = hypfs_read_leaf, \
-          .hypfs.e.write = hypfs_write_custom }
+          .hypfs.e.write = hypfs_write_custom, \
+          .init_leaf = initfunc, \
+          .func = _var }
 #define boolean_runtime_only_param(_name, _var) \
-    __rtparam __rtpar_##_var = \
-        { .name = _name, \
-          .type = OPT_BOOL, \
-          .len = sizeof(_var) + \
-                 BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
-          .par.var = &_var }; \
     __paramfs __parfs_##_var = \
-        { .param = &__rtpar_##_var, \
-          .hypfs.e.type = XEN_HYPFS_TYPE_BOOL, \
+        { .hypfs.e.type = XEN_HYPFS_TYPE_BOOL, \
           .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
           .hypfs.e.name = _name, \
           .hypfs.e.size = sizeof(_var), \
@@ -134,14 +120,8 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
           .hypfs.e.write = hypfs_write_bool, \
           .hypfs.content = &_var }
 #define integer_runtime_only_param(_name, _var) \
-    __rtparam __rtpar_##_var = \
-        { .name = _name, \
-          .type = OPT_UINT, \
-          .len = sizeof(_var), \
-          .par.var = &_var }; \
     __paramfs __parfs_##_var = \
-        { .param = &__rtpar_##_var, \
-          .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
+        { .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
           .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
           .hypfs.e.name = _name, \
           .hypfs.e.size = sizeof(_var), \
@@ -150,14 +130,8 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
           .hypfs.e.write = hypfs_write_leaf, \
           .hypfs.content = &_var }
 #define size_runtime_only_param(_name, _var) \
-    __rtparam __rtpar_##_var = \
-        { .name = _name, \
-          .type = OPT_SIZE, \
-          .len = sizeof(_var), \
-          .par.var = &_var }; \
     __paramfs __parfs_##_var = \
-        { .param = &__rtpar_##_var, \
-          .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
+        { .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
           .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
           .hypfs.e.name = _name, \
           .hypfs.e.size = sizeof(_var), \
@@ -166,14 +140,8 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
           .hypfs.e.write = hypfs_write_leaf, \
           .hypfs.content = &_var }
 #define string_runtime_only_param(_name, _var) \
-    __rtparam __rtpar_##_var = \
-        { .name = _name, \
-          .type = OPT_STR, \
-          .len = sizeof(_var), \
-          .par.var = &_var }; \
     __paramfs __parfs_##_var = \
-        { .param = &__rtpar_##_var, \
-          .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
+        { .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
           .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
           .hypfs.e.name = _name, \
           .hypfs.e.size = sizeof(_var), \
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 74af7df7d5..11cb8098a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -821,9 +821,6 @@ static int flask_sysctl(int cmd)
     case XEN_SYSCTL_coverage_op:
         return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
                                     XEN2__COVERAGE_OP, NULL);
-    case XEN_SYSCTL_set_parameter:
-        return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
-                                    XEN2__SET_PARAMETER, NULL);
 
     default:
         return avc_unknown_permission("sysctl", cmd);
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index c9e385fb9b..b87c99ea98 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -99,8 +99,6 @@ class xen2
     livepatch_op
 # XEN_SYSCTL_coverage_op
     coverage_op
-# XEN_SYSCTL_set_parameter
-    set_parameter
 }
 
 # Classes domain and domain2 consist of operations that a domain performs on
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:46:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:46:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK23W-000492-E6; Thu, 02 Apr 2020 15:46:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jjwm=5S=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jK23V-00048U-I8
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:46:57 +0000
X-Inumbo-ID: 1aed8482-74f9-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1aed8482-74f9-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 15:46:24 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3777FAE57;
 Thu,  2 Apr 2020 15:46:21 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v7 09/12] xen: add runtime parameter access support to hypfs
Date: Thu,  2 Apr 2020 17:46:13 +0200
Message-Id: <20200402154616.16927-10-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200402154616.16927-1-jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add support to read and modify values of hypervisor runtime parameters
via the hypervisor file system.

As runtime parameters can be modified via a sysctl, too, this path has
to take the hypfs rw_lock as writer.

For custom runtime parameters the connection between the parameter
value and the file system is done via an init function which will set
the initial value (if needed) and the leaf properties.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V3:
- complete rework
- support custom parameters, too
- support parameter writing

V6:
- rewording in docs/misc/hypfs-paths.pandoc (Jan Beulich)
- use memchr() (Jan Beulich)
- use strlcat() (Jan Beulich)
- rework to use a custom parameter init function instead of a reference
  to a content variable, allowing to drop default strings
- style correction (Jan Beulich)
- dropping param_append_str() in favor of a custom function at its only
  use site

V7:
- fine tune some parameter initializations (Jan Beulich)
- call custom_runtime_set_var() after updating the value
- modify alignment in Arm linker script to 4 (Jan Beulich)
---
 docs/misc/hypfs-paths.pandoc |  9 +++++
 xen/arch/arm/xen.lds.S       |  5 +++
 xen/arch/x86/hvm/vmx/vmcs.c  | 32 +++++++++++++++-
 xen/arch/x86/pv/domain.c     | 21 ++++++++++-
 xen/arch/x86/xen.lds.S       |  5 +++
 xen/common/grant_table.c     | 49 ++++++++++++++++++++-----
 xen/common/hypfs.c           | 41 +++++++++++++++++++++
 xen/common/kernel.c          | 27 +++++++++++++-
 xen/drivers/char/console.c   | 61 ++++++++++++++++++++++++++++---
 xen/include/xen/hypfs.h      |  4 ++
 xen/include/xen/param.h      | 87 ++++++++++++++++++++++++++++++++++++++++----
 11 files changed, 314 insertions(+), 27 deletions(-)

diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index f134c505d6..9d46e7e44a 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -152,3 +152,12 @@ The major version of Xen.
 #### /buildinfo/version/minor = INTEGER
 
 The minor version of Xen.
+
+#### /params/
+
+A directory of runtime parameters.
+
+#### /params/*
+
+The individual parameters. The description of the different parameters can be
+found in `docs/misc/xen-command-line.pandoc`.
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index a497f6a48d..d31bed580d 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -89,6 +89,11 @@ SECTIONS
        __start_schedulers_array = .;
        *(.data.schedulers)
        __end_schedulers_array = .;
+
+       . = ALIGN(4);
+       __paramhypfs_start = .;
+       *(.data.paramhypfs)
+       __paramhypfs_end = .;
        *(.data.rel)
        *(.data.rel.*)
        CONSTRUCTORS
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 24f2bd6e43..859c753a14 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -70,6 +70,30 @@ integer_param("ple_window", ple_window);
 static bool __read_mostly opt_ept_pml = true;
 static s8 __read_mostly opt_ept_ad = -1;
 int8_t __read_mostly opt_ept_exec_sp = -1;
+static char opt_ept_setting[24];
+
+static void update_ept_param_append(const char *str, int val)
+{
+    char *pos = opt_ept_setting + strlen(opt_ept_setting);
+
+    snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
+             ",%s=%d", str, val);
+}
+
+static void update_ept_param(void)
+{
+    snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
+    if ( opt_ept_ad >= 0 )
+        update_ept_param_append("ad", opt_ept_ad);
+    if ( opt_ept_exec_sp >= 0 )
+        update_ept_param_append("exec-sp", opt_ept_exec_sp);
+}
+
+static void __init init_ept_param(struct param_hypfs *par)
+{
+    update_ept_param();
+    custom_runtime_set_var(par, opt_ept_setting);
+}
 
 static int __init parse_ept_param(const char *s)
 {
@@ -97,6 +121,9 @@ static int __init parse_ept_param(const char *s)
 }
 custom_param("ept", parse_ept_param);
 
+static int parse_ept_param_runtime(const char *s);
+custom_runtime_only_param("ept", parse_ept_param_runtime, init_ept_param);
+
 static int parse_ept_param_runtime(const char *s)
 {
     struct domain *d;
@@ -115,6 +142,10 @@ static int parse_ept_param_runtime(const char *s)
 
     opt_ept_exec_sp = val;
 
+    update_ept_param();
+    custom_runtime_set_var(param_2_parfs(parse_ept_param_runtime),
+                           opt_ept_setting);
+
     rcu_read_lock(&domlist_read_lock);
     for_each_domain ( d )
     {
@@ -144,7 +175,6 @@ static int parse_ept_param_runtime(const char *s)
 
     return 0;
 }
-custom_runtime_only_param("ept", parse_ept_param_runtime);
 
 /* Dynamic (run-time adjusted) execution control flags. */
 u32 vmx_pin_based_exec_control __read_mostly;
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 70fae43965..7bec22e810 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -20,8 +20,23 @@ static __read_mostly enum {
     PCID_OFF,
     PCID_ALL,
     PCID_XPTI,
-    PCID_NOXPTI
+    PCID_NOXPTI,
+    PCID_END
 } opt_pcid = PCID_XPTI;
+static const char opt_pcid_2_string[PCID_END][7] = {
+    [PCID_OFF] = "off",
+    [PCID_ALL] = "on",
+    [PCID_XPTI] = "xpti",
+    [PCID_NOXPTI] = "noxpti"
+};
+
+static void __init opt_pcid_init(struct param_hypfs *par)
+{
+    custom_runtime_set_var(par, opt_pcid_2_string[opt_pcid]);
+}
+
+static int parse_pcid(const char *s);
+custom_runtime_param("pcid", parse_pcid, opt_pcid_init);
 
 static int parse_pcid(const char *s)
 {
@@ -55,9 +70,11 @@ static int parse_pcid(const char *s)
         break;
     }
 
+    custom_runtime_set_var(param_2_parfs(parse_pcid),
+                           opt_pcid_2_string[opt_pcid]);
+
     return rc;
 }
-custom_runtime_param("pcid", parse_pcid);
 
 static void noreturn continue_nonidle_domain(struct vcpu *v)
 {
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7f9459d683..21a37f0f57 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -279,6 +279,11 @@ SECTIONS
        __start_schedulers_array = .;
        *(.data.schedulers)
        __end_schedulers_array = .;
+
+       . = ALIGN(8);
+       __paramhypfs_start = .;
+       *(.data.paramhypfs)
+       __paramhypfs_end = .;
   } :text
 
   DECL_SECTION(.data) {
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 9fd6e60416..7a63bdd772 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -85,8 +85,17 @@ struct grant_table {
     struct grant_table_arch arch;
 };
 
-static int parse_gnttab_limit(const char *param, const char *arg,
-                              unsigned int *valp)
+#define GRANT_CUSTOM_VAL_SZ  12
+
+static void update_gnttab_par(struct param_hypfs *par, unsigned int val,
+                              char *parval)
+{
+    snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%u", val);
+    custom_runtime_set_var(par, parval);
+}
+
+static int parse_gnttab_limit(struct param_hypfs *par, const char *arg,
+                              unsigned int *valp, char *parval)
 {
     const char *e;
     unsigned long val;
@@ -99,28 +108,50 @@ static int parse_gnttab_limit(const char *param, const char *arg,
         return -ERANGE;
 
     *valp = val;
+    update_gnttab_par(par, val, parval);
 
     return 0;
 }
 
 unsigned int __read_mostly opt_max_grant_frames = 64;
+static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
+
+static void __init gnttab_max_frames_init(struct param_hypfs *par)
+{
+    update_gnttab_par(par, opt_max_grant_frames, opt_max_grant_frames_val);
+}
+
+static int parse_gnttab_max_frames(const char *arg);
+custom_runtime_param("gnttab_max_frames", parse_gnttab_max_frames,
+                     gnttab_max_frames_init);
 
 static int parse_gnttab_max_frames(const char *arg)
 {
-    return parse_gnttab_limit("gnttab_max_frames", arg,
-                              &opt_max_grant_frames);
+    return parse_gnttab_limit(param_2_parfs(parse_gnttab_max_frames),
+                              arg, &opt_max_grant_frames,
+                              opt_max_grant_frames_val);
 }
-custom_runtime_param("gnttab_max_frames", parse_gnttab_max_frames);
 
 static unsigned int __read_mostly opt_max_maptrack_frames = 1024;
+static char __read_mostly opt_max_maptrack_frames_val[GRANT_CUSTOM_VAL_SZ];
 
-static int parse_gnttab_max_maptrack_frames(const char *arg)
+static void __init max_maptrack_frames_init(struct param_hypfs *par)
 {
-    return parse_gnttab_limit("gnttab_max_maptrack_frames", arg,
-                              &opt_max_maptrack_frames);
+    update_gnttab_par(par, opt_max_maptrack_frames,
+                      opt_max_maptrack_frames_val);
 }
+
+static int parse_gnttab_max_maptrack_frames(const char *arg);
 custom_runtime_param("gnttab_max_maptrack_frames",
-                     parse_gnttab_max_maptrack_frames);
+                     parse_gnttab_max_maptrack_frames,
+                     max_maptrack_frames_init);
+
+static int parse_gnttab_max_maptrack_frames(const char *arg)
+{
+    return parse_gnttab_limit(param_2_parfs(parse_gnttab_max_maptrack_frames),
+                              arg, &opt_max_maptrack_frames,
+                              opt_max_maptrack_frames_val);
+}
 
 #ifndef GNTTAB_MAX_VERSION
 #define GNTTAB_MAX_VERSION 2
diff --git a/xen/common/hypfs.c b/xen/common/hypfs.c
index 986b829934..df951526db 100644
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -10,6 +10,7 @@
 #include <xen/hypercall.h>
 #include <xen/hypfs.h>
 #include <xen/lib.h>
+#include <xen/param.h>
 #include <xen/rwlock.h>
 #include <public/hypfs.h>
 
@@ -279,6 +280,36 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
     return 0;
 }
 
+int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
+                       XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+    struct param_hypfs *p;
+    char *buf;
+    int ret;
+
+    buf = xzalloc_array(char, ulen);
+    if ( !buf )
+        return -ENOMEM;
+
+    ret = -EFAULT;
+    if ( copy_from_guest(buf, uaddr, ulen) )
+        goto out;
+
+    ret = -EDOM;
+    if ( memchr(buf, 0, ulen) != (buf + ulen - 1) )
+        goto out;
+
+    p = container_of(leaf, struct param_hypfs, hypfs);
+    ret = p->param->par.func(buf);
+
+    if ( !ret )
+        leaf->e.size = ulen;
+
+ out:
+    xfree(buf);
+    return ret;
+}
+
 static int hypfs_write(struct hypfs_entry *entry,
                        XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
 {
@@ -348,3 +379,13 @@ long do_hypfs_op(unsigned int cmd,
 
     return ret;
 }
+
+void hypfs_write_lock(void)
+{
+    write_lock(&hypfs_lock);
+}
+
+void hypfs_write_unlock(void)
+{
+    write_unlock(&hypfs_lock);
+}
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 4b7bc28afb..7516242337 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -198,7 +198,13 @@ static void __init _cmdline_parse(const char *cmdline)
 
 int runtime_parse(const char *line)
 {
-    return parse_params(line, __param_start, __param_end);
+    int ret;
+
+    hypfs_write_lock();
+    ret = parse_params(line, __param_start, __param_end);
+    hypfs_write_unlock();
+
+    return ret;
 }
 
 /**
@@ -433,6 +439,25 @@ static int __init buildinfo_init(void)
 }
 __initcall(buildinfo_init);
 
+static HYPFS_DIR_INIT(params, "params");
+
+static int __init param_init(void)
+{
+    struct param_hypfs *param;
+
+    hypfs_add_dir(&hypfs_root, &params, true);
+
+    for ( param = __paramhypfs_start; param < __paramhypfs_end; param++ )
+    {
+        if ( param->init_leaf )
+            param->init_leaf(param);
+        hypfs_add_leaf(&params, &param->hypfs, true);
+    }
+
+    return 0;
+}
+__initcall(param_init);
+
 # define DO(fn) long do_##fn
 
 #endif
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 913ae1b66a..b18b431fa8 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -75,12 +75,29 @@ enum con_timestamp_mode
     TSM_DATE_MS,       /* [YYYY-MM-DD HH:MM:SS.mmm] */
     TSM_BOOT,          /* [SSSSSS.uuuuuu] */
     TSM_RAW,           /* [XXXXXXXXXXXXXXXX] */
+    TSM_END
+};
+
+static const char con_timestamp_mode_2_string[TSM_END][7] = {
+    [TSM_NONE] = "none",
+    [TSM_DATE] = "date",
+    [TSM_DATE_MS] = "datems",
+    [TSM_BOOT] = "boot",
+    [TSM_RAW] = "raw"
 };
 
 static enum con_timestamp_mode __read_mostly opt_con_timestamp_mode = TSM_NONE;
 
+static void con_timestamp_mode_upd(struct param_hypfs *par)
+{
+    const char *val = con_timestamp_mode_2_string[opt_con_timestamp_mode];
+
+    custom_runtime_set_var_sz(par, val, 7);
+}
+
 static int parse_console_timestamps(const char *s);
-custom_runtime_param("console_timestamps", parse_console_timestamps);
+custom_runtime_param("console_timestamps", parse_console_timestamps,
+                     con_timestamp_mode_upd);
 
 /* conring_size: allows a large console ring than default (16kB). */
 static uint32_t __initdata opt_conring_size;
@@ -133,16 +150,39 @@ static DEFINE_SPINLOCK(console_lock);
 #define XENLOG_DEFAULT       1 /* XENLOG_WARNING */
 #define XENLOG_GUEST_DEFAULT 1 /* XENLOG_WARNING */
 
+#define LOGLVL_VAL_SZ 16
 static int __read_mostly xenlog_upper_thresh = XENLOG_UPPER_THRESHOLD;
 static int __read_mostly xenlog_lower_thresh = XENLOG_LOWER_THRESHOLD;
+static char xenlog_val[LOGLVL_VAL_SZ];
 static int __read_mostly xenlog_guest_upper_thresh =
     XENLOG_GUEST_UPPER_THRESHOLD;
 static int __read_mostly xenlog_guest_lower_thresh =
     XENLOG_GUEST_LOWER_THRESHOLD;
+static char xenlog_guest_val[LOGLVL_VAL_SZ];
 
 static int parse_loglvl(const char *s);
 static int parse_guest_loglvl(const char *s);
 
+static char *lvl2opt[] = { "none", "error", "warning", "info", "all" };
+
+static void xenlog_update_val(int lower, int upper, char *val)
+{
+    snprintf(val, LOGLVL_VAL_SZ, "%s/%s", lvl2opt[lower], lvl2opt[upper]);
+}
+
+static void __init xenlog_init(struct param_hypfs *par)
+{
+    xenlog_update_val(xenlog_lower_thresh, xenlog_upper_thresh, xenlog_val);
+    custom_runtime_set_var(par, xenlog_val);
+}
+
+static void __init xenlog_guest_init(struct param_hypfs *par)
+{
+    xenlog_update_val(xenlog_guest_lower_thresh, xenlog_guest_upper_thresh,
+                      xenlog_guest_val);
+    custom_runtime_set_var(par, xenlog_guest_val);
+}
+
 /*
  * <lvl> := none|error|warning|info|debug|all
  * loglvl=<lvl_print_always>[/<lvl_print_ratelimit>]
@@ -151,8 +191,8 @@ static int parse_guest_loglvl(const char *s);
  * Similar definitions for guest_loglvl, but applies to guest tracing.
  * Defaults: loglvl=warning ; guest_loglvl=none/warning
  */
-custom_runtime_param("loglvl", parse_loglvl);
-custom_runtime_param("guest_loglvl", parse_guest_loglvl);
+custom_runtime_param("loglvl", parse_loglvl, xenlog_init);
+custom_runtime_param("guest_loglvl", parse_guest_loglvl, xenlog_guest_init);
 
 static atomic_t print_everything = ATOMIC_INIT(0);
 
@@ -173,7 +213,7 @@ static int __parse_loglvl(const char *s, const char **ps)
     return 2; /* sane fallback */
 }
 
-static int _parse_loglvl(const char *s, int *lower, int *upper)
+static int _parse_loglvl(const char *s, int *lower, int *upper, char *val)
 {
     *lower = *upper = __parse_loglvl(s, &s);
     if ( *s == '/' )
@@ -181,18 +221,21 @@ static int _parse_loglvl(const char *s, int *lower, int *upper)
     if ( *upper < *lower )
         *upper = *lower;
 
+    xenlog_update_val(*lower, *upper, val);
+
     return *s ? -EINVAL : 0;
 }
 
 static int parse_loglvl(const char *s)
 {
-    return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh);
+    return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh,
+                         xenlog_val);
 }
 
 static int parse_guest_loglvl(const char *s)
 {
     return _parse_loglvl(s, &xenlog_guest_lower_thresh,
-                         &xenlog_guest_upper_thresh);
+                         &xenlog_guest_upper_thresh, xenlog_guest_val);
 }
 
 static char *loglvl_str(int lvl)
@@ -727,13 +770,17 @@ static int printk_prefix_check(char *p, char **pp)
 
 static int parse_console_timestamps(const char *s)
 {
+    struct param_hypfs *par = param_2_parfs(parse_console_timestamps);
+
     switch ( parse_bool(s, NULL) )
     {
     case 0:
         opt_con_timestamp_mode = TSM_NONE;
+        con_timestamp_mode_upd(par);
         return 0;
     case 1:
         opt_con_timestamp_mode = TSM_DATE;
+        con_timestamp_mode_upd(par);
         return 0;
     }
     if ( *s == '\0' || /* Compat for old booleanparam() */
@@ -750,6 +797,8 @@ static int parse_console_timestamps(const char *s)
     else
         return -EINVAL;
 
+    con_timestamp_mode_upd(par);
+
     return 0;
 }
 
diff --git a/xen/include/xen/hypfs.h b/xen/include/xen/hypfs.h
index 85588e2a59..3c3b1b056d 100644
--- a/xen/include/xen/hypfs.h
+++ b/xen/include/xen/hypfs.h
@@ -112,5 +112,9 @@ int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
                      XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
 int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
                      XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
+                       XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+void hypfs_write_lock(void);
+void hypfs_write_unlock(void);
 
 #endif /* __XEN_HYPFS_H__ */
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index d4578cd27f..5cf2149279 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -1,6 +1,7 @@
 #ifndef _XEN_PARAM_H
 #define _XEN_PARAM_H
 
+#include <xen/hypfs.h>
 #include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/stdbool.h>
@@ -25,10 +26,18 @@ struct kernel_param {
     } par;
 };
 
+struct param_hypfs {
+    const struct kernel_param *param;
+    struct hypfs_entry_leaf hypfs;
+    void (*init_leaf)(struct param_hypfs *par);
+};
+
 extern const struct kernel_param __setup_start[], __setup_end[];
 extern const struct kernel_param __param_start[], __param_end[];
+extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
 
 #define __dataparam       __used_section(".data.param")
+#define __paramhypfs      __used_section(".data.paramhypfs")
 
 #define __param(att)      static const att \
     __attribute__((__aligned__(sizeof(void *)))) struct kernel_param
@@ -79,41 +88,103 @@ extern const struct kernel_param __param_start[], __param_end[];
           .type = OPT_IGNORE }
 
 #define __rtparam         __param(__dataparam)
+#define __paramfs         static __paramhypfs \
+    __attribute__((__aligned__(sizeof(void *)))) struct param_hypfs
+
+#define custom_runtime_set_var_sz(parfs, var, sz) \
+    { \
+        (parfs)->hypfs.content = &(var); \
+        (parfs)->hypfs.e.max_size = sz; \
+        (parfs)->hypfs.e.size = strlen(var) + 1; \
+    }
+#define custom_runtime_set_var(parfs, var) \
+    custom_runtime_set_var_sz(parfs, var, sizeof(var))
 
-#define custom_runtime_only_param(_name, _var) \
+#define param_2_parfs(par) &__parfs_##par
+
+/* initfunc needs to set size and content, e.g. via custom_runtime_set_var(). */
+#define custom_runtime_only_param(_name, _var, initfunc) \
     __rtparam __rtpar_##_var = \
       { .name = _name, \
           .type = OPT_CUSTOM, \
-          .par.func = _var }
+          .par.func = _var }; \
+    __paramfs __parfs_##_var = \
+        { .param = &__rtpar_##_var, \
+          .init_leaf = initfunc, \
+          .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
+          .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+          .hypfs.e.name = _name, \
+          .hypfs.e.read = hypfs_read_leaf, \
+          .hypfs.e.write = hypfs_write_custom }
 #define boolean_runtime_only_param(_name, _var) \
     __rtparam __rtpar_##_var = \
         { .name = _name, \
           .type = OPT_BOOL, \
           .len = sizeof(_var) + \
                  BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
-          .par.var = &_var }
+          .par.var = &_var }; \
+    __paramfs __parfs_##_var = \
+        { .param = &__rtpar_##_var, \
+          .hypfs.e.type = XEN_HYPFS_TYPE_BOOL, \
+          .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+          .hypfs.e.name = _name, \
+          .hypfs.e.size = sizeof(_var), \
+          .hypfs.e.max_size = sizeof(_var), \
+          .hypfs.e.read = hypfs_read_leaf, \
+          .hypfs.e.write = hypfs_write_bool, \
+          .hypfs.content = &_var }
 #define integer_runtime_only_param(_name, _var) \
     __rtparam __rtpar_##_var = \
         { .name = _name, \
           .type = OPT_UINT, \
           .len = sizeof(_var), \
-          .par.var = &_var }
+          .par.var = &_var }; \
+    __paramfs __parfs_##_var = \
+        { .param = &__rtpar_##_var, \
+          .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
+          .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+          .hypfs.e.name = _name, \
+          .hypfs.e.size = sizeof(_var), \
+          .hypfs.e.max_size = sizeof(_var), \
+          .hypfs.e.read = hypfs_read_leaf, \
+          .hypfs.e.write = hypfs_write_leaf, \
+          .hypfs.content = &_var }
 #define size_runtime_only_param(_name, _var) \
     __rtparam __rtpar_##_var = \
         { .name = _name, \
           .type = OPT_SIZE, \
           .len = sizeof(_var), \
-          .par.var = &_var }
+          .par.var = &_var }; \
+    __paramfs __parfs_##_var = \
+        { .param = &__rtpar_##_var, \
+          .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
+          .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+          .hypfs.e.name = _name, \
+          .hypfs.e.size = sizeof(_var), \
+          .hypfs.e.max_size = sizeof(_var), \
+          .hypfs.e.read = hypfs_read_leaf, \
+          .hypfs.e.write = hypfs_write_leaf, \
+          .hypfs.content = &_var }
 #define string_runtime_only_param(_name, _var) \
     __rtparam __rtpar_##_var = \
         { .name = _name, \
           .type = OPT_STR, \
           .len = sizeof(_var), \
-          .par.var = &_var }
+          .par.var = &_var }; \
+    __paramfs __parfs_##_var = \
+        { .param = &__rtpar_##_var, \
+          .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
+          .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+          .hypfs.e.name = _name, \
+          .hypfs.e.size = sizeof(_var), \
+          .hypfs.e.max_size = sizeof(_var), \
+          .hypfs.e.read = hypfs_read_leaf, \
+          .hypfs.e.write = hypfs_write_leaf, \
+          .hypfs.content = &_var }
 
-#define custom_runtime_param(_name, _var) \
+#define custom_runtime_param(_name, _var, initfunc) \
     custom_param(_name, _var); \
-    custom_runtime_only_param(_name, _var)
+    custom_runtime_only_param(_name, _var, initfunc)
 #define boolean_runtime_param(_name, _var) \
     boolean_param(_name, _var); \
     boolean_runtime_only_param(_name, _var)
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 15:53:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 15:53:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK29s-0005fx-6m; Thu, 02 Apr 2020 15:53:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Hi7f=5S=gmail.com=singhalsimran0@srs-us1.protection.inumbo.net>)
 id 1jK29q-0005fs-9z
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 15:53:30 +0000
X-Inumbo-ID: 18b3aa10-74fa-11ea-83d8-bc764e2007e4
Received: from mail-pj1-x1044.google.com (unknown [2607:f8b0:4864:20::1044])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 18b3aa10-74fa-11ea-83d8-bc764e2007e4;
 Thu, 02 Apr 2020 15:53:29 +0000 (UTC)
Received: by mail-pj1-x1044.google.com with SMTP id jz1so3395915pjb.0
 for <xen-devel@lists.xenproject.org>; Thu, 02 Apr 2020 08:53:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=date:from:to:cc:subject:message-id:mime-version:content-disposition
 :user-agent; bh=AVEvemLr4Biqm7wYYR5hPV0RkS9Fxm05rC7rAzhCIwQ=;
 b=ZLl2QTd/xaZzRVjyC9vExivmHH1lBIFoSMe2+9NiNZcGk6mUXIdZJNRBV/J6SbcvAY
 loL72/0S0cUM10GrEyE9QnlGvc3+ooANgqAkR4U8M5mbYVKxx4EC03ttBa4dPc9IKbmK
 l/4GcGtsrdNSy0l2WIK0C1C5W4Awvqb1vFllE+VwjkMX2fINM0f0Pu8alSAEeaYhsn2m
 ylj7GWFxXmZFVkxhox9xYc90Cu2aebndiZaCeuEMIHrFIDYoS748b2ToQhQvHJmWqvta
 64nPrvhJ+2YzNOD5/Xe0Jzb0WDfetkAu7dMwZD8ncrOiJYtommtPQuMj4JdwQTkZaoRs
 yHew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version
 :content-disposition:user-agent;
 bh=AVEvemLr4Biqm7wYYR5hPV0RkS9Fxm05rC7rAzhCIwQ=;
 b=KMIOMvpQlkOyttgC/PvHm7kRrWOrqM5uC4+B4QGdYoCdndfAh7pkNyEYnjAqluXcox
 syKWW3hfo14TyKuRsAAbj96M8JTwGSUL/y3D9nS1mEth0iHuDF7yMMW1sPNYT8wb1P/m
 3hZY55MOrE97AzCS6I58WMaEUSaQ8hUwwnXEhWctoxpFhyGzrDi/x7r3DLD4dzN6F0ta
 bM+sd5JUAKurePVwnT8ZensGmqrpOzLQ+oZeFpriRHyFbCWNVC78Bsn/uV/X4EH/B+74
 NOq9VLPzEBL6Z+ey3WhyuOArmU8rNCr/2yrhpG+/yXCGuZdJx67J+2RwQCFv7xJ3mUN8
 hz7A==
X-Gm-Message-State: AGi0PuZgIjhhS8merHrC9uaGhJTBvhZQNHnoe8FF1D6nJu/uJyQ3Vm0q
 J8XjGtj62/Fx+yssJWIDjS4=
X-Google-Smtp-Source: APiQypIxcMHBSPBknzSwpX6D0tejjsPsEQ3W6AoctFC+0tKCqkvuEbY+lL4K6hMnc6EYa0gcZhUB9w==
X-Received: by 2002:a17:90a:34e:: with SMTP id 14mr4617074pjf.32.1585842808812; 
 Thu, 02 Apr 2020 08:53:28 -0700 (PDT)
Received: from simran-Inspiron-5558 ([2409:4052:99d:cf8:4926:6e0b:60ca:635c])
 by smtp.gmail.com with ESMTPSA id
 x188sm4075889pfx.198.2020.04.02.08.53.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Apr 2020 08:53:28 -0700 (PDT)
Date: Thu, 2 Apr 2020 21:23:22 +0530
From: Simran Singhal <singhalsimran0@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] xen/x86: Use macro DIV_ROUND_UP
Message-ID: <20200402155322.GA16696@simran-Inspiron-5558>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.9.4 (2018-02-28)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Lukasz Hawrylko <lukasz.hawrylko@linux.intel.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Use the DIV_ROUND_UP macro to replace open-coded divisor calculation
(((n) + (d) - 1) /(d)) to improve readability.

Signed-off-by: Simran Singhal <singhalsimran0@gmail.com>
---
 xen/arch/x86/mm.c        | 2 +-
 xen/arch/x86/tboot.c     | 2 +-
 xen/arch/x86/x86_64/mm.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c7617f80e8..a381eac81c 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -240,7 +240,7 @@ static void __init init_frametable_chunk(void *start, void *end)
 void __init init_frametable(void)
 {
     unsigned int sidx, eidx, nidx;
-    unsigned int max_idx = (max_pdx + PDX_GROUP_COUNT - 1) / PDX_GROUP_COUNT;
+    unsigned int max_idx = DIV_ROUND_UP(max_pdx, PDX_GROUP_COUNT);
     struct page_info *end_pg, *top_pg;
 
     BUILD_BUG_ON(XEN_VIRT_END > FRAMETABLE_VIRT_START);
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index 102c3cd203..320e06f129 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -310,7 +310,7 @@ static void tboot_gen_frametable_integrity(const uint8_t key[TB_KEY_SIZE],
                                            vmac_t *mac)
 {
     unsigned int sidx, eidx, nidx;
-    unsigned int max_idx = (max_pdx + PDX_GROUP_COUNT - 1)/PDX_GROUP_COUNT;
+    unsigned int max_idx = DIV_ROUND_UP(max_pdx, PDX_GROUP_COUNT);
     uint8_t nonce[16] = {};
     vmac_ctx_t ctx;
 
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index b7ce833ffc..cee836ec37 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -801,7 +801,7 @@ static int extend_frame_table(struct mem_hotadd_info *info)
     spfn = _mfn(info->spfn);
     epfn = _mfn(info->epfn);
 
-    eidx = (mfn_to_pdx(epfn) + PDX_GROUP_COUNT - 1) / PDX_GROUP_COUNT;
+    eidx = DIV_ROUND_UP(mfn_to_pdx(epfn), PDX_GROUP_COUNT);
     nidx = cidx = mfn_to_pdx(spfn)/PDX_GROUP_COUNT;
 
     ASSERT( mfn_to_pdx(epfn) <= (DIRECTMAP_SIZE >> PAGE_SHIFT) &&
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 16:19:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 16:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK2YV-0007uf-3h; Thu, 02 Apr 2020 16:18:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2q0J=5S=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jK2YU-0007ua-4G
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 16:18:58 +0000
X-Inumbo-ID: a6904a84-74fd-11ea-b58d-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a6904a84-74fd-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 16:18:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585844336;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=1X9TKHRvXg8TwGrsMaRFTevKqbcYo0BBHmbYTPfNqdU=;
 b=Suigc0I/ZbjYk1Nr7eLM1iJx6aOV0HrMvZd218VlDfo1QCOqUdIqchbt
 sGFpjlhoP+PcBAWp07Y4/ET+4ESq1MT9U3ecIXKQtz4KqsP224ZLS2+Z3
 mQ11HJgeY2rf3h5JLF3GSnNAhCyGP4zZygtYuVuPmgPiH16aqxhezk93d M=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: DdBtcH2OPaho30HSSa8wHbjQuci25FrV7qDP13iiW284JaEsMrmwXoID4Ly/LD2bWtqeeKPmzp
 HkWGjvPGHSlDGh7Dhwk3hXuwEw8uGEFVcnJhgAEVy9+LXy9nimyKqfyvI+UKHH4gK5aoIST83u
 Uytcq8/v2oJAz16ik9bCmcd4gxJ7f2NsSYcEWenEbon0e3HgmljUEaU2Gp0iA6v9bVG9B6G5rX
 jiMbA2TA/Wn3j6cEM2MGr/6eWUo1VSWQSl5pODfnbmVHHgC+IoJH+1HyTWU7iOh2jx4qwg6vNs
 DfA=
X-SBRS: 2.7
X-MesageID: 15406123
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,336,1580792400"; d="scan'208";a="15406123"
From: Igor Druzhinin <igor.druzhinin@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH] hvmloader: probe memory below 4G before allocation for OVMF
Date: Thu, 2 Apr 2020 17:18:48 +0100
Message-ID: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
X-Mailer: git-send-email 2.7.4
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Igor Druzhinin <igor.druzhinin@citrix.com>, wl@xen.org,
 andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, jbeulich@suse.com,
 roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The area just below 4G where OVMF image is originally relocated is not
necessarily a hole - it might contain pages preallocated by device model
or the toolstack. By unconditionally populating on top of this memory
the original pages are getting lost while still potentially foreign mapped
in Dom0.

Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
---
That doesn't seem necessary for at least upstream toolstack now.
Alternative might be - to move population of this area to the toolstack
where there is more control over memory layout.
---
 tools/firmware/hvmloader/ovmf.c |  3 ++-
 tools/firmware/hvmloader/util.c | 14 ++++++++++++++
 tools/firmware/hvmloader/util.h |  3 +++
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 23610a0..70d5f70 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -106,7 +106,8 @@ static void ovmf_load(const struct bios_config *config,
     {
         mfn = (uint32_t) (addr >> PAGE_SHIFT);
         addr += PAGE_SIZE;
-        mem_hole_populate_ram(mfn, 1);
+        if ( !mem_probe_ram(mfn) )
+            mem_hole_populate_ram(mfn, 1);
     }
 
     /* Check that source and destination does not overlaps. */
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 0c3f2d2..724cea0 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -398,6 +398,20 @@ int get_mem_mapping_layout(struct e820entry entries[], uint32_t *max_entries)
     return rc;
 }
 
+bool mem_probe_ram(xen_pfn_t mfn)
+{
+    uint32_t tmp, magic = 0xdeadbeef;
+    volatile uint32_t *addr = (volatile uint32_t *)(mfn << PAGE_SHIFT);
+
+    tmp = *addr;
+    *addr = magic;
+    if ( *addr != magic )
+        return 0;
+
+    *addr = tmp;
+    return 1;
+}
+
 void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns)
 {
     static int over_allocated;
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 7bca641..00a7c13 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -194,6 +194,9 @@ int vprintf(const char *fmt, va_list ap);
 /* Buffer output */
 int snprintf(char *buf, size_t size, const char *fmt, ...) __attribute__ ((format (printf, 3, 4)));
 
+/* Probe whether a page is populated with RAM. */
+bool mem_probe_ram(xen_pfn_t mfn);
+
 /* Populate specified memory hole with RAM. */
 void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns);
 
-- 
2.7.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 16:20:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 16:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK2Zr-0000Bi-KP; Thu, 02 Apr 2020 16:20:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK2Zq-0000Bb-Jt
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 16:20:22 +0000
X-Inumbo-ID: d9897686-74fd-11ea-bc03-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d9897686-74fd-11ea-bc03-12813bfff9fa;
 Thu, 02 Apr 2020 16:20:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585844422;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=nDK9zgu5WCMqhvH9QXag8JSS2lIKvQEjK8bix6cbvmY=;
 b=EIaZ7uuQsRlUgzrenD1uBYnSlJCmViYbj8fOSvZzT99c1IBY6lwfK4z0
 LFNz9AD4ZFrOq46bKTThMAA5syhsOzqqAZfeuqKmS8pia4+ObstiFMbgD
 5hA1rw/zhgK0y1CllLF1rT+SGTRGthxqkuszb3oyLCQPIYH6AIiuEMa2J w=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 9WiWOQpCx0ek7t5GdOHLhXgGFJXbOWmFU5sHnM5Jfe+Emc/S9jfuDCamOOYveD6iZ7zHX9iAPk
 hvb2SKzYHsKqtWGDd3h6X6Ls9czuM4Z7iWWmG8y/XuXmDiMLW64ZhDQLBqum37SmmclqUdSDkF
 a3xnou4L63g3QMTYhALrCMvrUOO1dP6wW9Cbtweqcm6GcdzTJLhFHes/ao61PL/uEy0NvEonMh
 bidy+HEMcnUQxD1hjZAnR6fHPwjogd93GoMb17CeU6MR8vszx8hgK5Z5g/egFwAe+ef3szarap
 4pU=
X-SBRS: 2.7
X-MesageID: 15301825
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,336,1580792400"; d="scan'208";a="15301825"
Subject: Re: [PATCH] xen/x86: Use macro DIV_ROUND_UP
To: Simran Singhal <singhalsimran0@gmail.com>, <xen-devel@lists.xenproject.org>
References: <20200402155322.GA16696@simran-Inspiron-5558>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <0fd21c6d-d7d6-ca11-61ad-e96d48d0a8eb@citrix.com>
Date: Thu, 2 Apr 2020 17:20:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200402155322.GA16696@simran-Inspiron-5558>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Lukasz Hawrylko <lukasz.hawrylko@linux.intel.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02/04/2020 16:53, Simran Singhal wrote:
> Use the DIV_ROUND_UP macro to replace open-coded divisor calculation
> (((n) + (d) - 1) /(d)) to improve readability.
>
> Signed-off-by: Simran Singhal <singhalsimran0@gmail.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 17:11:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 17:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK3NJ-0004Jb-84; Thu, 02 Apr 2020 17:11:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9JfQ=5S=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jK3NI-0004JU-3N
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 17:11:28 +0000
X-Inumbo-ID: fb9270be-7504-11ea-bc15-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fb9270be-7504-11ea-bc15-12813bfff9fa;
 Thu, 02 Apr 2020 17:11:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=e0TQ/uOHiLPfvjSCWlM1An2WAECeuMEO7ufNIQM3U0w=; b=r6Psq/E4iZhZVj2G0ovKkB+Xr
 tXZi/CR9KGyRrrFgEKTacH9M8uftykZ4t7bZzNtE4Uq8gKfEEH9Iapi5DcRQQvrWnizZcZloOWD4R
 9yxr9D5ea9eivBDs/ZRYF6E1QtPHykjnAzkhhQz8i52+rO3Ca6PGwTECQ/p1YQP2LrBYU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK3NE-0002lF-ND; Thu, 02 Apr 2020 17:11:24 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK3NE-0001AH-EK; Thu, 02 Apr 2020 17:11:24 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jK3NE-0005py-DQ; Thu, 02 Apr 2020 17:11:24 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149306-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149306: regressions - FAIL
X-Osstest-Failures: linux-linus:build-arm64-pvops:kernel-build:fail:regression
 linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore:fail:allowable
 linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=668f1e9267415153e30bea03828c0530874e92e4
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 02 Apr 2020 17:11:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     15 guest-saverestore        fail REGR. vs. 149238

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

version targeted for testing:
 linux                668f1e9267415153e30bea03828c0530874e92e4
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    2 days
Failing since        149266  2020-04-01 03:55:53 Z    1 days    2 attempts
Testing same since   149306  2020-04-01 23:41:06 Z    0 days    1 attempts

------------------------------------------------------------
976 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  blocked 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  blocked 
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     blocked 
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 blocked 
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 17:17:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 17:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK3TW-0004WL-0h; Thu, 02 Apr 2020 17:17:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=nIMA=5S=chiark.greenend.org.uk=ijackson@srs-us1.protection.inumbo.net>)
 id 1jK3TU-0004WG-Gb
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 17:17:52 +0000
X-Inumbo-ID: e1d9d0f8-7505-11ea-b4f4-bc764e2007e4
Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e1d9d0f8-7505-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 17:17:51 +0000 (UTC)
Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk)
 by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp
 (return-path ijackson@chiark.greenend.org.uk)
 id 1jK3TS-0005Fa-TZ; Thu, 02 Apr 2020 18:17:50 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xenproject.org
Subject: [OSSTEST PATCH 1/2] ts-logs-capture: Cope better with unbootable host
Date: Thu,  2 Apr 2020 18:17:46 +0100
Message-Id: <20200402171747.4662-1-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 2.11.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

If we cannot ssh to the host to fish out its own logs, do not try to
do any of the other log captures which involve ssh'ing to the host.

This includes {fetch,extract}_logs_guest, which tolerated this
situation - so then it's an optimisation.

But it also includes shutdown_guests, which was introduced in
c5f8d41143ab "ts-logs-capture: Fish some logs out of guest filesystem"
and is not tolerant enough.  Since that commit, unbootable hosts have
caused ts-logs-capture to wrongly declare jobs broken.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-logs-capture | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/ts-logs-capture b/ts-logs-capture
index c67856cd..7940aece 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -190,7 +190,7 @@ sub fetch_logs_host () {
             1;
         }) {
             logm("host reboot failed, abandoning log fetches: $@");
-            return;
+            return 0;
         }
 	try_fetch_logs($ho, $logs);
     }
@@ -219,6 +219,8 @@ sub fetch_logs_host () {
          ) {
             try_cmd_output_save($cmd);
         }
+
+    return 1;
 }
 
 sub fetch_xenctx_guest ($) {
@@ -293,8 +295,9 @@ power_state($ho,1);
 find_guests();
 fetch_xenctx_guest($_) foreach @guests;
 serial_fetch_logs($ho);
-fetch_logs_host();
-fetch_logs_guest($_) foreach @guests;
-shutdown_guests();
-extract_logs_guest($_) foreach @allguests;
+if (fetch_logs_host()) {
+    fetch_logs_guest($_) foreach @guests;
+    shutdown_guests();
+    extract_logs_guest($_) foreach @allguests;
+}
 logm("logs captured to $stash");
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 17:17:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 17:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK3Ta-0004Wi-9F; Thu, 02 Apr 2020 17:17:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=nIMA=5S=chiark.greenend.org.uk=ijackson@srs-us1.protection.inumbo.net>)
 id 1jK3TZ-0004Wa-EY
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 17:17:57 +0000
X-Inumbo-ID: e1f9e8f2-7505-11ea-83d8-bc764e2007e4
Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e1f9e8f2-7505-11ea-83d8-bc764e2007e4;
 Thu, 02 Apr 2020 17:17:51 +0000 (UTC)
Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk)
 by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp
 (return-path ijackson@chiark.greenend.org.uk)
 id 1jK3TT-0005Fa-4i; Thu, 02 Apr 2020 18:17:51 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xenproject.org
Subject: [OSSTEST PATCH 2/2] ts-logs-capture: Cope better with unbootable host
 (2)
Date: Thu,  2 Apr 2020 18:17:47 +0100
Message-Id: <20200402171747.4662-2-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200402171747.4662-1-ian.jackson@eu.citrix.com>
References: <20200402171747.4662-1-ian.jackson@eu.citrix.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

shutdown_guests might conceivably fail due to a flaky host.  In that
case we want not to declare the job broken so ts-logs-capture most not
fail.  But in that case we should skip fishing in-guest logs out of
guest fs's.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-logs-capture | 31 +++++++++++++++++++------------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/ts-logs-capture b/ts-logs-capture
index 7940aece..0320a5a5 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -264,17 +264,23 @@ sub fetch_logs_guest ($) {
 }
 
 sub shutdown_guests () {
-    target_cmd_root($ho, <<'END', 180);
-        set -x
-        (
-            ( exec 2>/dev/null; sleep 30 ; echo y ) &
-            ( xl shutdown -a -F -w ; echo y ) &
-        ) | (
-            read x
-            xl list | awk '!/^Domain-0 |^Name / {print $2}' \
-            | xargs -t -r -n1 xl destroy ||:
-        )
+    if (!eval {
+	target_cmd_root($ho, <<'END', 180);
+	    set -x
+	    (
+		( exec 2>/dev/null; sleep 30 ; echo y ) &
+		( xl shutdown -a -F -w ; echo y ) &
+	    ) | (
+		read x
+		xl list | awk '!/^Domain-0 |^Name / {print $2}' \
+		| xargs -t -r -n1 xl destroy ||:
+	    )
 END
+    }) {
+	logm("cannot ensure no guests running, cannot fish their logs");
+	return 0;
+    }
+    return 1;
 }
 
 sub extract_logs_guest ($) {
@@ -297,7 +303,8 @@ fetch_xenctx_guest($_) foreach @guests;
 serial_fetch_logs($ho);
 if (fetch_logs_host()) {
     fetch_logs_guest($_) foreach @guests;
-    shutdown_guests();
-    extract_logs_guest($_) foreach @allguests;
+    if (shutdown_guests()) {
+	extract_logs_guest($_) foreach @allguests;
+    }
 }
 logm("logs captured to $stash");
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 17:20:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 17:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK3Vg-0005M3-S7; Thu, 02 Apr 2020 17:20:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=dnjT=5S=xilinx.com=stefanos@srs-us1.protection.inumbo.net>)
 id 1jK3Vf-0005Lu-20
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 17:20:07 +0000
X-Inumbo-ID: 32045a13-7506-11ea-bc15-12813bfff9fa
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (unknown
 [40.107.77.42]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 32045a13-7506-11ea-bc15-12813bfff9fa;
 Thu, 02 Apr 2020 17:20:06 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ffObcS5vqR1wkFl6VHJdZlBGOTc0yaEwxJF21GoEhkmMN1beEmUAOpZq68Py3yIPnFhCZxmhJblQAXtQeivKndjHxfjN5n+SIbsvD1E++q2eG8ojNeuG71e3l7VYYReuuC06Go5bN5gH7j/8+oep6Px5rmv5OXpcosh+dJGgapbSRJ8msdM1Mdq2zybG+a4xbg46sQzEtmO4byoZnnOyjGbtgmwonj0oLZ0GGhjDNkLh0zFfutyNDk3kyki3OTqbpNMP0DrVEExpcLtHMEN/MOrJgiEWd6FT/7Z2kUS4gplojsYEfqCkCCcMI6Iqks3qQWA5A/OcO817o3mopMStcw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=gcpzF3l6cBRhzFd2948ZXb8FfCjTNb6+Y7pZbkr2fwc=;
 b=C8rsgp4k+b5/0vnYM3+ylR7ud8dv9kJJTc6hzSN5EfhJGQx3lAOu08PdA0MLUmDD+0cRvzJ3JRIaC4XLqn+3cj09MHAdk9q2zAWq7fSSDWtIbLy5gl99kTc2bROzTOmbHL/IrHr1s9MzFg+CwpI1TghAjlGyX0tMQ1X1tHoG2po4RckGXLCb/sfps8AQ+rMu9OmciAXrbr26zxpnodfgNeaJruZqccr0Nf6JHzYcU9uHjn3MaGr5ruy0AYUI3R18GXAy9Ul8ovPR3X9J3cbgRNKQtgR9zJ78bKgH68et8WrKwxnnFH7SUVWYT5yvksucucmHC+d++rWPlvabSvteFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 149.199.60.83) smtp.rcpttodomain=xen.org smtp.mailfrom=xilinx.com;
 dmarc=bestguesspass action=none header.from=xilinx.com; dkim=none (message
 not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=gcpzF3l6cBRhzFd2948ZXb8FfCjTNb6+Y7pZbkr2fwc=;
 b=ba71uuk7Ge5bz96xO0KcTSc2qbpvpvxm6XQQmQSzvT69BNi8atSubBN7PBhcaqyzNmraI+e8zpbb5Hh1Nhp1hkdgFTnPzx7HCtUGUpWBlJJ/flUTg+iga6GKXvXtm+QhmXd4Ztjn6EICGuaO5zvGbGP/Nh2TOmoHH/n8fXupV30=
Received: from DM6PR07CA0043.namprd07.prod.outlook.com (2603:10b6:5:74::20) by
 DM5PR02MB2377.namprd02.prod.outlook.com (2603:10b6:3:52::19) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2878.15; Thu, 2 Apr 2020 17:20:04 +0000
Received: from SN1NAM02FT006.eop-nam02.prod.protection.outlook.com
 (2603:10b6:5:74:cafe::54) by DM6PR07CA0043.outlook.office365.com
 (2603:10b6:5:74::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend
 Transport; Thu, 2 Apr 2020 17:20:04 +0000
Authentication-Results: spf=pass (sender IP is 149.199.60.83)
 smtp.mailfrom=xilinx.com; xen.org; dkim=none (message not signed)
 header.d=none;xen.org; dmarc=bestguesspass action=none
 header.from=xilinx.com;
Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
 149.199.60.83 as permitted sender) receiver=protection.outlook.com;
 client-ip=149.199.60.83; helo=xsj-pvapsmtpgw01;
Received: from xsj-pvapsmtpgw01 (149.199.60.83) by
 SN1NAM02FT006.mail.protection.outlook.com (10.152.72.68) with Microsoft SMTP
 Server id 15.20.2878.15 via Frontend Transport; Thu, 2 Apr 2020 17:20:04
 +0000
Received: from [149.199.38.66] (port=50614 helo=xsj-pvapsmtp01)
 by xsj-pvapsmtpgw01 with esmtp (Exim 4.90)
 (envelope-from <stefano.stabellini@xilinx.com>)
 id 1jK3VW-0002gf-5l; Thu, 02 Apr 2020 10:19:58 -0700
Received: from [127.0.0.1] (helo=localhost)
 by xsj-pvapsmtp01 with smtp (Exim 4.63)
 (envelope-from <stefano.stabellini@xilinx.com>)
 id 1jK3Vc-0006TT-4h; Thu, 02 Apr 2020 10:20:04 -0700
Received: from [172.19.2.220] (helo=localhost)
 by xsj-pvapsmtp01 with esmtp (Exim 4.63)
 (envelope-from <stefanos@xilinx.com>)
 id 1jK3VV-0006Je-FC; Thu, 02 Apr 2020 10:19:57 -0700
Date: Thu, 2 Apr 2020 10:19:57 -0700 (PDT)
From: Stefano Stabellini <stefano.stabellini@xilinx.com>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
In-Reply-To: <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
Message-ID: <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.2.0.1013-23620.005
X-TM-AS-User-Approved-Sender: Yes;Yes
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:149.199.60.83; CTRY:US; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:xsj-pvapsmtpgw01; PTR:unknown-60-83.xilinx.com; CAT:NONE;
 SFTY:;
 SFS:(10009020)(7916004)(4636009)(346002)(136003)(376002)(39860400002)(396003)(46966005)(81166006)(356004)(70586007)(81156014)(70206006)(82740400003)(54906003)(478600001)(9686003)(5660300002)(316002)(336012)(33716001)(8936002)(8676002)(186003)(47076004)(2906002)(9786002)(426003)(26005)(6916009)(44832011)(53546011)(4326008);
 DIR:OUT; SFP:1101; 
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ac95e07a-7faf-4256-dbc6-08d7d72a1576
X-MS-TrafficTypeDiagnostic: DM5PR02MB2377:
X-Microsoft-Antispam-PRVS: <DM5PR02MB23771C5916723181CDF52904A0C60@DM5PR02MB2377.namprd02.prod.outlook.com>
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0361212EA8
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: E+M5blTf9jD1uA6rXJdjqlDDaTDKKZOkSfKCVnjnVKZ+9Gav36aXNISqkFhk2m1Gp8YdIXefySeRBnseKDd0AQMqCPLaXLOp0epXr1W86r9s0EttZmVLOnwtCqQN3lWNENxNBwjUkJOCb/sCJ+GMruU8Rv+falKU2dc2IUoEaYS3XniSK1qrpWxTkfaZKIG4up9N0y+6ggriPAtz6HxFjecIbC1sR0CGe0WBFU90ptv7BmA/GeJtYLYhlrzlFtZzwvB01xBk4T2vMUVQO0ght/sIOWO1NLNrk+KNCmss2fnRciKkpyJNddgMzIu7yGhAQjkAaNxTITRm9bl0BLryIDPnahBJpcG1TNbATvPt5DuYA8LgIfWztcfgYbGfBPwEZqtCMakZ3T0bXN9CES2ihebPlXO2Vkrsd5U9GNj0R5HvT0NMCOSoNHV4wkWTFOBRu5+YAFjqYtl/YGY33IDxJVXqfzterkIIKu3TdlN07chaciAMIHhQi6P9JiEoGFCztb91Lf8nBSJ6jQrPZUhx0A==
X-OriginatorOrg: xilinx.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2020 17:20:04.4814 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ac95e07a-7faf-4256-dbc6-08d7d72a1576
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.60.83];
 Helo=[xsj-pvapsmtpgw01]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB2377
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 George.Dunlap@citrix.com, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 1 Apr 2020, Julien Grall wrote:
> On 01/04/2020 01:57, Stefano Stabellini wrote:
> > On Mon, 30 Mar 2020, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 30/03/2020 17:35, Stefano Stabellini wrote:
> > > > On Sat, 28 Mar 2020, Julien Grall wrote:
> > > > > qHi Stefano,
> > > > > 
> > > > > On 27/03/2020 02:34, Stefano Stabellini wrote:
> > > > > > This is a simple implementation of GICD_ICACTIVER / GICD_ISACTIVER
> > > > > > reads. It doesn't take into account the latest state of interrupts
> > > > > > on
> > > > > > other vCPUs. Only the current vCPU is up-to-date. A full solution is
> > > > > > not possible because it would require synchronization among all
> > > > > > vCPUs,
> > > > > > which would be very expensive in terms or latency.
> > > > > 
> > > > > Your sentence suggests you have number showing that correctly
> > > > > emulating
> > > > > the
> > > > > registers would be too slow. Mind sharing them?
> > > > 
> > > > No, I don't have any numbers. Would you prefer a different wording or a
> > > > better explanation? I also realized there is a typo in there (or/of).
> > > Let me start with I think correctness is more important than speed.
> > > So I would have expected your commit message to contain some fact why
> > > synchronization is going to be slow and why this is a problem.
> > > 
> > > To give you a concrete example, the implementation of set/way instructions
> > > are
> > > really slow (it could take a few seconds depending on the setup). However,
> > > this was fine because not implementing them correctly would have a greater
> > > impact on the guest (corruption) and they are not used often.
> > > 
> > > I don't think the performance in our case will be in same order magnitude.
> > > It
> > > is most likely to be in the range of milliseconds (if not less) which I
> > > think
> > > is acceptable for emulation (particularly for the vGIC) and the current
> > > uses.
> > 
> > Writing on the mailing list some of our discussions today.
> > 
> > Correctness is not just in terms of compliance to a specification but it
> > is also about not breaking guests. Introducing latency in the range of
> > milliseconds, or hundreds of microseconds, would break any latency
> > sensitive workloads. We don't have numbers so we don't know for certain
> > the effect that your suggestion would have.
> 
> You missed part of the discussion. I don't disagree that latency is important.
> However, if an implementation is only 95% reliable, then it means 5% of the
> time your guest may break (corruption, crash, deadlock...). At which point the
> latency is the last of your concern.

Yeah I missed to highlight it, also because I look at it from a slightly
different perspective: I think IRQ latency is part of correctness.

If we have a solution that is not 100% faithful to the specification we
are going to break guests that rely on a faithful implementation of
ISACTIVER.

If we have a solution that is 100% faithful to the specification but
causes latency spikes it breaks RT guests.

But they are different sets of guests, it is not like one is necessarily
a subset of the other: there are guests that cannot tolerate any latency
spikes but they are OK with an imprecise implementation of ISACTIVER.

My preference is a solution that is both spec-faithful and also doesn't
cause any latency spikes. If that is not possible then we'll have to
compromise or come up with "creative" ideas.


> > It would be interesting to have those numbers, and I'll add to my TODO
> > list to run the experiments you suggested, but I'll put it on the
> > back-burner (from a Xilinx perspective it is low priority as no
> > customers are affected.)
> 
> How about we get a correct implementation merge first and then discuss about
> optimization? This would allow the community to check whether there are
> actually noticeable latency in their workload.

A correct implementation to me means that it is correct from both the
specification point of view as well as from a latency point of view. A
patch that potentially introduces latency spikes could cause guest
breakage and I don't think it should be considered correct. The
tests would have to be done beforehand.



In terms of other "creative" ideas, here are some:

One idea, as George suggested, would be to document the interface
deviation. The intention is still to remove any deviation but at least
we would be clear about what we have. Ideally in a single place together
with other hypervisors. This is my preference.

Another idea is that we could crash the guest if GICD_ISACTIVER is read
from a multi-vcpu guest. It is similar to what we already do today but
better because we would do it purposely (not because of a typo) and
because it will work for single vcpu guests at least.

We could also leave it as is (crash all the time) but it implies that
vendors that are seeing issues with Linux today will have to keep
maintaining patches in their private trees until a better solution is
found. This would also be the case if we crash multi-vcpus guests as
previously suggested.


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 17:55:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 17:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK44A-0007qr-Sn; Thu, 02 Apr 2020 17:55:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK44A-0007qm-0j
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 17:55:46 +0000
X-Inumbo-ID: 2ccb3f70-750b-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2ccb3f70-750b-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 17:55:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585850145;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=o/f+h2iqW2yJM7kEztkWaeAwmd8skiPSTm8glelY6IA=;
 b=WyBQ8ipClvahAI+Y+J5/YgNYxPe/y+RK7xp69UwFnUP0SJ7R7LYzLdae
 GedIZ9qH6RoIOFQOOYKY9oVK2fmOGTn2wruZjNWtUzxO44m+XzmJfib/Q
 GVA8gD6lTHjIYNuBjn47ewfjEbw1RMWUkCvMBYc8mVTnPzF6O3p0jI/tt I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: RkuBTBUyUaNBED5uNY288M9IG/dLM6BqV7NKXXzOCrsoFMcjULJ1OD89xtoJX10chE+bw6CXAi
 /R4YAnt5q2wzaqNeiDcFpXKlK1ujCd3x6lzsT2jfn7daDTd/vrKk+dOhIJ3iPnNan6BTJyvaaG
 bolbUJ4ednvmz5zFhE1i9xSwLYL2hiMVRU/R5a2jNKi6uuT7978dAEwFgJCuAAJCeTk4BfhnIF
 eJLVHHB/P46UAuqkcqJX5MZpIbFmRH/PJOXwKkVjCcf9KQikPF5k0XrZmmdB3HvRKZ+EDpPb9N
 CDU=
X-SBRS: 2.7
X-MesageID: 15750170
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,336,1580792400"; d="scan'208";a="15750170"
Subject: Re: [PATCH 4/4] x86/APIC: restrict certain messages to BSP
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <60130f14-3fc5-e40d-fec6-2448fefa6fc4@suse.com>
 <513e4f93-a8a0-ae72-abcc-aa28531eca97@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <76e02143-474f-54c1-bba3-5c5973d7751a@citrix.com>
Date: Thu, 2 Apr 2020 18:55:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <513e4f93-a8a0-ae72-abcc-aa28531eca97@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 13/03/2020 09:26, Jan Beulich wrote:
> All CPUs get an equal setting of EOI broadcast suppression; no need to
> log one message per CPU, even if it's only in verbose APIC mode.
>
> Only the BSP is eligible to possibly get ExtINT enabled; no need to log
> that it gets disabled on all APs, even if - again - it's only in verbose
> APIC mode.
>
> Take the opportunity and introduce a "bsp" parameter to the function, to
> stop using smp_processor_id() to tell BSP from APs.

On further consideration, this is introducing a latent bug.

In a theoretical world where we could take the BSP offline, it is still
the CPU with the ID 0 which needs various of these things setting back up.

You could argue that we could move ExtINT/NMI handling to a different
CPU, and in this case, BSP still isn't the right distinction.  We'd want
something to signify "the processor which is the target of legacy
interrupts", as in such a case, it would specifically no longer be the
CPU we booted on.

OTOH, the adjustment for the NMI watchdog does look to be different. 
AFAICT, that is for deferring the watchdog setup until later in boot, at
which point "the BSP" is the appropriate distinction to use.  (That said
- I'm not sure why anything should need delaying.  I suspect this is
misplaced code to begin with.)

As for the messages being printed, I think that is fine to restrict to
the BSP.

A conversation on LKML has revealed why LVT0.MASK gets sampled - it is
to distinguish between the two virtual wire modes.  LVT0.MASK needs to
stay masked on the BSP if the firmware configured it like that, because
the PIC is wired through an IO-APIC pin which ultimately ends up
delivering an MSI ExtINT interrupt, rather than using the dedicates
sideband bus message to emulate the legacy ExtINT/LINT0 line.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 18:21:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 18:21:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK4T3-0001rV-3h; Thu, 02 Apr 2020 18:21:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=c8Ny=5S=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jK4T1-0001rN-F1
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 18:21:27 +0000
X-Inumbo-ID: c347b250-750e-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c347b250-750e-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 18:21:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585851686;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=RtEitIk98VtKmS0olg/hamwlT2FfwvLItu5dTeyNIEM=;
 b=J2mU8o3PY/3qwaOFbnSyk7PrbkYG5pHxVI8bkhdQey1dz6bvTfM06vYf
 yycT7NB8Djdd4+EtXG/yuI0WC+AjawX9qpUZZsfSyFzSLQvh/7Lw2zoSK
 crcQcaz+nH37DGjipCKRfqoERtGQgfbtAkMQqGj0DoTs8Q+8YUzo530j6 o=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: qAz8DOZtXF27NGIFv0GvcBb/aF6lhHntsM0cllxTNU6kuVoe2iUS5V3BOaBSZUOEa8N5oD/4tl
 wLgAhzjHEvtV/x+mc/OCqLVKt5YHqJbzhACdL1jKwCQJ9sBD542tWZEtRWhfWRLvmLPV8HoQaY
 IQ/6+RB2uy5d/kZhTJo+fariU7ybDJ7MApnXIGzrx93m09X+unmAybzktDlDnQRiIH6M3WHLJr
 KWlm48ONk4GAzrBhnbLzsyZoZjc6s6VW4TntPwNi7uPGwwZk9T4XNnFXYt+aNM+ER847CeCxOy
 aGw=
X-SBRS: 2.7
X-MesageID: 15100624
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,336,1580792400"; d="scan'208";a="15100624"
From: George Dunlap <George.Dunlap@citrix.com>
To: Dario Faggioli <dfaggioli@suse.com>
Subject: Re: [PATCH v2 1/2] xen: credit2: avoid vCPUs to ever reach lower
 credits than idle
Thread-Topic: [PATCH v2 1/2] xen: credit2: avoid vCPUs to ever reach lower
 credits than idle
Thread-Index: AQHV/YMCTAYYiKTeNUaPDRpZJQiNcqhmGmuA
Date: Thu, 2 Apr 2020 18:21:11 +0000
Message-ID: <2645C51C-5994-4FCC-9042-BBC86FA5A22A@citrix.com>
References: <158457508246.11355.6457403441669388939.stgit@Palanthas>
 <158457671301.11355.1086453211878144633.stgit@Palanthas>
In-Reply-To: <158457671301.11355.1086453211878144633.stgit@Palanthas>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <B8AEB96BF84DD647A531C446BAAFFA4E@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Charles Arnold <carnold@suse.com>,
 Tomas Mozes <hydrapolic@gmail.com>, Glen <glenbarney@gmail.com>, Jan
 Beulich <jbeulich@suse.com>, Sarah Newman <srn@prgmr.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gTWFyIDE5LCAyMDIwLCBhdCAxMjoxMSBBTSwgRGFyaW8gRmFnZ2lvbGkgPGRmYWdn
aW9saUBzdXNlLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGVyZSBoYXZlIGJlZW4gcmVwb3J0IG9mIHN0
YWxscyBvZiBndWVzdCB2Q1BVcywgd2hlbiBDcmVkaXQyIHdhcyB1c2VkLg0KPiBJdCBzZWVtZWQg
bGlrZSB0aGVzZSB2Q1BVcyB3ZXJlIG5vdCBnZXR0aW5nIHNjaGVkdWxlZCBmb3IgdmVyeSBsb25n
DQo+IHRpbWUsIGV2ZW4gdW5kZXIgbGlnaHQgbG9hZCBjb25kaXRpb25zIChlLmcuLCBkdXJpbmcg
ZG9tMCBib290KS4NCj4gDQo+IEludmVzdGlnYXRpb25zIGxlZCB0byB0aGUgZGlzY292ZXJ5IHRo
YXQgLS1hbHRob3VnaCByYXJlbHktLSBpdCBjYW4NCj4gaGFwcGVuIHRoYXQgYSB2Q1BVIG1hbmFn
ZXMgdG8gcnVuIGZvciB2ZXJ5IGxvbmcgdGltZXNsaWNlcy4gSW4gQ3JlZGl0MiwNCj4gdGhpcyBt
ZWFucyB0aGF0LCB3aGVuIHJ1bnRpbWUgYWNjb3VudGluZyBoYXBwZW5zLCB0aGUgdkNQVSB3aWxs
IGxvc2UgYQ0KPiBsYXJnZSBxdWFudGl0eSBvZiBjcmVkaXRzLiBUaGlzIGluIHR1cm4gbWF5IGxl
YWQgdG8gdGhlIHZDUFUgaGF2aW5nIGxlc3MNCj4gY3JlZGl0cyB0aGFuIHRoZSBpZGxlIHZDUFVz
ICgtMl4zMCkuIEF0IHRoaXMgcG9pbnQsIHRoZSBzY2hlZHVsZXIgd2lsbA0KPiBwaWNrIHRoZSBp
ZGxlIHZDUFUsIGluc3RlYWQgb2YgdGhlIHJlYWR5IHRvIHJ1biB2Q1BVLCBmb3IgYSBmZXcNCj4g
ImVwb2NocyIsIHdoaWNoIG9mdGVuIHRpbWVzIGlzIGVub3VnaCBmb3IgdGhlIGd1ZXN0IGtlcm5l
bCB0byB0aGluayB0aGUNCj4gdkNQVSBpcyBub3QgcmVzcG9uZGluZyBhbmQgY3Jhc2hpbmcuDQo+
IA0KPiBBbiBleGFtcGxlIG9mIHRoaXMgc2l0dWF0aW9uIGlzIHNob3duIGhlcmUuIEluIGZhY3Qs
IHdlIGNhbiBzZWUgZDB2MQ0KPiBzaXR0aW5nIGluIHRoZSBydW5xdWV1ZSB3aGlsZSBhbGwgdGhl
IENQVXMgYXJlIGlkbGUsIGFzIGl0IGhhcw0KPiAtMTI1NDIzODI3MCBjcmVkaXRzLCB3aGljaCBp
cyBzbWFsbGVyIHRoYW4gLTJeMzAgPSDiiJIxMDczNzQxODI0Og0KPiANCj4gICAgKFhFTikgUnVu
cXVldWUgMDoNCj4gICAgKFhFTikgICBuY3B1cyAgICAgICAgICAgICAgPSAyOA0KPiAgICAoWEVO
KSAgIGNwdXMgICAgICAgICAgICAgICA9IDAtMjcNCj4gICAgKFhFTikgICBtYXhfd2VpZ2h0ICAg
ICAgICAgPSAyNTYNCj4gICAgKFhFTikgICBwaWNrX2JpYXMgICAgICAgICAgPSAyMg0KPiAgICAo
WEVOKSAgIGluc3Rsb2FkICAgICAgICAgICA9IDENCj4gICAgKFhFTikgICBhdmVsb2FkICAgICAg
ICAgICAgPSAyOTMzOTEgKH4xMTElKQ0KPiAgICAoWEVOKSAgIGlkbGVyczogMDAsMDAwMDAwMDAs
MDAwMDAwMDAsMDAwMDAwMDAsMDAwMDAwMDAsMDAwMDAwMDAsMGZmZmZmZmYNCj4gICAgKFhFTikg
ICB0aWNrbGVkOiAwMCwwMDAwMDAwMCwwMDAwMDAwMCwwMDAwMDAwMCwwMDAwMDAwMCwwMDAwMDAw
MCwwMDAwMDAwMA0KPiAgICAoWEVOKSAgIGZ1bGx5IGlkbGUgY29yZXM6IDAwLDAwMDAwMDAwLDAw
MDAwMDAwLDAwMDAwMDAwLDAwMDAwMDAwLDAwMDAwMDAwLDBmZmZmZmZmDQo+ICAgIFsuLi5dDQo+
ICAgIChYRU4pIFJ1bnF1ZXVlIDA6DQo+ICAgIChYRU4pIENQVVswMF0gcnVucT0wLCBzaWJsaW5n
PTAwLC4uLiwgY29yZT0wMCwuLi4NCj4gICAgKFhFTikgQ1BVWzAxXSBydW5xPTAsIHNpYmxpbmc9
MDAsLi4uLCBjb3JlPTAwLC4uLg0KPiAgICBbLi4uXQ0KPiAgICAoWEVOKSBDUFVbMjZdIHJ1bnE9
MCwgc2libGluZz0wMCwuLi4sIGNvcmU9MDAsLi4uDQo+ICAgIChYRU4pIENQVVsyN10gcnVucT0w
LCBzaWJsaW5nPTAwLC4uLiwgY29yZT0wMCwuLi4NCj4gICAgKFhFTikgUlVOUToNCj4gICAgKFhF
TikgICAgIDA6IFswLjFdIGZsYWdzPTAgY3B1PTUgY3JlZGl0PS0xMjU0MjM4MjcwIFt3PTI1Nl0g
bG9hZD0yNjIxNDQgKH4xMDAlKQ0KPiANCj4gV2UgY2VydGFpbmx5IGRvbid0IHdhbnQsIHVuZGVy
IGFueSBjaXJjdW1zdGFuY2UsIHRoaXMgdG8gaGFwcGVuLg0KPiBMZXQncywgdGhlcmVmb3JlLCBk
ZWZpbmUgYSBtaW5pbXVtIGFtb3VudCBvZiBjcmVkaXRzIGEgdkNQVSBjYW4gaGF2ZS4NCj4gRHVy
aW5nIGFjY291bnRpbmcsIHdlIG1ha2Ugc3VyZSB0aGF0LCBmb3IgaG93ZXZlciBsb25nIHRoZSB2
Q1BVIGhhcw0KPiBydW4sIGl0IHdpbGwgbmV2ZXIgZ2V0IHRvIGhhdmUgbGVzcyB0aGFuIHN1Y2gg
bWluaW11bSBhbW91bnQgb2YNCj4gY3JlZGl0cy4gVGhlbiwgd2Ugc2V0IHRoZSBjcmVkaXRzIG9m
IHRoZSBpZGxlIHZDUFUgdG8gYW4gZXZlbg0KPiBzbWFsbGVyIHZhbHVlLg0KPiANCj4gTk9URTog
aW52ZXN0aWdhdGlvbnMgaGF2ZSBiZWVuIGRvbmUgYWJvdXQgX2hvd18gaXQgaXMgcG9zc2libGUg
Zm9yIGENCj4gdkNQVSB0byBleGVjdXRlIGZvciBzbyBtdWNoIHRpbWUgdGhhdCBpdHMgY3JlZGl0
cyBiZWNvbWVzIHNvIGxvdy4gV2hpbGUNCj4gc3RpbGwgbm90IGNvbXBsZXRlbHkgY2xlYXIsIHRo
ZXJlIGFyZSBldmlkZW5jZSB0aGF0Og0KPiAtIGl0IG9ubHkgaGFwcGVucyB2ZXJ5IHJhcmVseSwN
Cj4gLSBpdCBhcHBlYXJzIHRvIGJlIGJvdGggbWFjaGluZSBhbmQgd29ya2xvYWQgc3BlY2lmaWMs
DQo+IC0gaXQgZG9lcyBub3QgbG9vayB0byBiZSBhIENyZWRpdDIgKGUuZy4sIGFzIGl0IGhhcHBl
bnMgd2hlbg0KPiAgcnVubmluZyB3aXRoIENyZWRpdDEgYXMgd2VsbCkgaXNzdWUsIG9yIGEgc2No
ZWR1bGVyIGlzc3VlLg0KPiANCj4gVGhpcyBwYXRjaCBtYWtlcyBDcmVkaXQyIG1vcmUgcm9idXN0
IHRvIGV2ZW50cyBsaWtlIHRoaXMsIHdoYXRldmVyDQo+IHRoZSBjYXVzZSBpcywgYW5kIHNob3Vs
ZCBoZW5jZSBiZSBiYWNrcG9ydGVkIChhcyBmYXIgYXMgcG9zc2libGUpLg0KPiANCj4gUmVwb3J0
ZWQtYnk6IEdsZW4gPGdsZW5iYXJuZXlAZ21haWwuY29tPg0KPiBSZXBvcnRlZC1ieTogVG9tYXMg
TW96ZXMgPGh5ZHJhcG9saWNAZ21haWwuY29tPg0KPiBTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdn
aW9saSA8ZGZhZ2dpb2xpQHN1c2UuY29tPg0KDQpSZXZpZXdlZC1ieTogR2VvcmdlIER1bmxhcCA8
Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPg0KDQo=


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 18:32:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 18:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK4e0-0002kn-6g; Thu, 02 Apr 2020 18:32:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=c8Ny=5S=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jK4dz-0002ki-6l
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 18:32:47 +0000
X-Inumbo-ID: 58f2c21c-7510-11ea-9e09-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 58f2c21c-7510-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 18:32:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585852366;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=zFFgEdH0DiK/DzrRhdSUXSPM1id6Z8HEkf38aksFA0Q=;
 b=NK1TWN4AFsbljmsR4kvgOPJPK4pc77Q8Jz4T/Z+N3q5fE/rGd3CPmymk
 3cg4K7HivUSK5fgMUcbmxkC/UiBjTrd/abQDjsORZNmoaSmPXhzKlmtZ6
 YM2vrFdCYk6FdnIcrPUwIFqRnYeBFdWXOtRl7nJ+niBDlfK1nG+WUMZrZ Y=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: WTMvIHNebKM2DvUcvwqadnBWmW/I7zUN54F1wURYfbNwwANyBqqoAas+vvdKpKyu7mXc0EAW0z
 w43c7lznylb6gruYh6eL6+qfH1ZOx6OKkDsEIkisgNaEF5v9qnZYX2y0qSYZ1ax3BH0QklGd7s
 7cc+r9dj2u5sbBD9Z3GkXYr3WR3WZMEj5q1p1JhRORjiYHw/J78ezhDaiE+2Fzk3Xc76C3aIDV
 wZ+P2vM4RfTXBRQLYElgnXzUtC7i6ghkvbH4jNk9I8wLaOeeZXDPPxths/o3byhfqaZqcxkxq6
 9EQ=
X-SBRS: 2.7
X-MesageID: 15752634
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,336,1580792400"; d="scan'208";a="15752634"
From: George Dunlap <George.Dunlap@citrix.com>
To: Dario Faggioli <dfaggioli@suse.com>
Subject: Re: [PATCH v2 2/2] xen: credit2: fix credit reset happening too few
 times
Thread-Topic: [PATCH v2 2/2] xen: credit2: fix credit reset happening too few
 times
Thread-Index: AQHV/YMFxYzbM+D1bEORIh9fvqIWfahmHaMA
Date: Thu, 2 Apr 2020 18:32:42 +0000
Message-ID: <5C3A27CD-E237-4490-8942-2F82D0C20DCC@citrix.com>
References: <158457508246.11355.6457403441669388939.stgit@Palanthas>
 <158457672023.11355.16720240521867328301.stgit@Palanthas>
In-Reply-To: <158457672023.11355.16720240521867328301.stgit@Palanthas>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <E3EE39656B430C40B6D7EDA24B833A44@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Charles Arnold <carnold@suse.com>,
 Jan Beulich <jbeulich@suse.com>, Glen <glenbarney@gmail.com>,
 Tomas Mozes <hydrapolic@gmail.com>, Sarah Newman <srn@prgmr.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gTWFyIDE5LCAyMDIwLCBhdCAxMjoxMiBBTSwgRGFyaW8gRmFnZ2lvbGkgPGRmYWdn
aW9saUBzdXNlLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGVyZSBpcyBhIGJ1ZyBpbiBjb21taXQgNWU0
YjQxOTk2NjdiOSAoInhlbjogY3JlZGl0Mjogb25seSByZXNldA0KPiBjcmVkaXQgb24gcmVzZXQg
Y29uZGl0aW9uIikuIEluIGZhY3QsIHRoZSBhaW0gb2YgdGhhdCBjb21taXQgd2FzIHRvDQo+IG1h
a2Ugc3VyZSB0aGF0IHdlIGRvIG5vdCBwZXJmb3JtIHRvbyBtYW55IGNyZWRpdCByZXNldCBvcGVy
YXRpb25zDQo+ICh3aGljaCBhcmUgbm90IHN1cGVyIGNoZWFwLCBhbmQgaW4gYW4gaG90LXBhdGgp
LiBCdXQgdGhlIGNoZWNrIHVzZWQNCj4gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYSByZXNldCBpcyBu
ZWNlc3Nhcnkgd2FzIHRoZSB3cm9uZyBvbmUuDQo+IA0KPiBJbiBmYWN0LCBrbm93aW5nIGp1c3Qg
dGhhdCBzb21lIHZDUFVzIGhhdmUgYmVlbiBza2lwcGVkLCB3aGlsZQ0KPiB0cmF2ZXJzaW5nIHRo
ZSBydW5xdWV1ZSAoaW4gcnVucV9jYW5kaWRhdGUoKSksIGlzIG5vdCBlbm91Z2guIFdlDQo+IG5l
ZWQgdG8gY2hlY2sgZXhwbGljaXRseSB3aGV0aGVyIHRoZSBmaXJzdCB2Q1BVIGluIHRoZSBydW5x
dWV1ZQ0KPiBoYXMgYSBuZWdhdGl2ZSBhbW91bnQgb2YgY3JlZGl0Lg0KDQpPaCwgc28gaWYgdGhl
IHRvcCBvZiB0aGUgcnVucXVldWUgaGFzIG5lZ2F0aXZlIGNyZWRpdCwgYnV0IGl04oCZcyBub3Qg
Y2hvc2VuLCB0aGVuIHRoZSBvbmUgd2UgKmRvKiBydW4gaGFzIGV2ZW4gbG93ZXIgY3JlZGl0LiAg
U3RpbGwgbm90IHF1aXRlIHN1cmUgaG93IHRoYXQgbGVhZHMgdG8gYSBzaXR1YXRpb24gd2hlcmUg
Y3JlZGl0IHJlc2V0cyBkb27igJl0IGhhcHBlbiBmb3IgbG9uZyBwZXJpb2RzIG9mIHRpbWUuICBC
dXQgYW55d2F5Li4uDQoNCj4gDQo+IFNpbmNlIGEgdHJhY2UgcmVjb3JkIGlzIGNoYW5nZWQsIHRo
aXMgcGF0Y2ggdXBkYXRlcyB4ZW50cmFjZSBmb3JtYXQgZmlsZQ0KPiBhbmQgeGVuYWx5emUgYXMg
d2VsbA0KPiANCj4gVGhpcyBzaG91bGQgYmUgYmFja3BvcnRlZC4NCj4gDQo+IFNpZ25lZC1vZmYt
Ynk6IERhcmlvIEZhZ2dpb2xpIDxkZmFnZ2lvbGlAc3VzZS5jb20+DQoNCkFja2VkLWJ5OiBHZW9y
Z2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGNpdHJpeC5jb20+DQoNCg==


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 18:53:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 18:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK4xV-0004On-65; Thu, 02 Apr 2020 18:52:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=B+pF=5S=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jK4xU-0004Oi-Jt
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 18:52:56 +0000
X-Inumbo-ID: 284769e4-7513-11ea-bc3a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 284769e4-7513-11ea-bc3a-12813bfff9fa;
 Thu, 02 Apr 2020 18:52:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=nqOwJGrRRu1XmAzvLt99qGVo8a2WMoL6w01/Bt0wwX8=; b=szdqRl8tteJ9bfXffDNBSLPFWO
 zHQmrAe5aMMOfltSxh0nx7+IMh8bquqDXQ+kCQmxLmcbsM0KVujLbHDcyct+v3KV3621VSLTLDfw6
 Ux/J7LmnAq/JCGx9xhzIYU7OLrceX618zTaBGKQ8bZIW+SYebCwtl147kWECsIAb/92s=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jK4xK-0004lk-Po; Thu, 02 Apr 2020 18:52:46 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jK4xK-0000ZW-EX; Thu, 02 Apr 2020 18:52:46 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Stefano Stabellini <stefano.stabellini@xilinx.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
Date: Thu, 2 Apr 2020 19:52:44 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 maz@kernel.org, George.Dunlap@citrix.com, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

(+Marc)

Hi Stefano,

On 02/04/2020 18:19, Stefano Stabellini wrote:
> On Wed, 1 Apr 2020, Julien Grall wrote:
>> On 01/04/2020 01:57, Stefano Stabellini wrote:
>>> On Mon, 30 Mar 2020, Julien Grall wrote:
>>>> Hi Stefano,
>>>>
>>>> On 30/03/2020 17:35, Stefano Stabellini wrote:
>>>>> On Sat, 28 Mar 2020, Julien Grall wrote:
>>>>>> qHi Stefano,
>>>>>>
>>>>>> On 27/03/2020 02:34, Stefano Stabellini wrote:
>>>>>>> This is a simple implementation of GICD_ICACTIVER / GICD_ISACTIVER
>>>>>>> reads. It doesn't take into account the latest state of interrupts
>>>>>>> on
>>>>>>> other vCPUs. Only the current vCPU is up-to-date. A full solution is
>>>>>>> not possible because it would require synchronization among all
>>>>>>> vCPUs,
>>>>>>> which would be very expensive in terms or latency.
>>>>>>
>>>>>> Your sentence suggests you have number showing that correctly
>>>>>> emulating
>>>>>> the
>>>>>> registers would be too slow. Mind sharing them?
>>>>>
>>>>> No, I don't have any numbers. Would you prefer a different wording or a
>>>>> better explanation? I also realized there is a typo in there (or/of).
>>>> Let me start with I think correctness is more important than speed.
>>>> So I would have expected your commit message to contain some fact why
>>>> synchronization is going to be slow and why this is a problem.
>>>>
>>>> To give you a concrete example, the implementation of set/way instructions
>>>> are
>>>> really slow (it could take a few seconds depending on the setup). However,
>>>> this was fine because not implementing them correctly would have a greater
>>>> impact on the guest (corruption) and they are not used often.
>>>>
>>>> I don't think the performance in our case will be in same order magnitude.
>>>> It
>>>> is most likely to be in the range of milliseconds (if not less) which I
>>>> think
>>>> is acceptable for emulation (particularly for the vGIC) and the current
>>>> uses.
>>>
>>> Writing on the mailing list some of our discussions today.
>>>
>>> Correctness is not just in terms of compliance to a specification but it
>>> is also about not breaking guests. Introducing latency in the range of
>>> milliseconds, or hundreds of microseconds, would break any latency
>>> sensitive workloads. We don't have numbers so we don't know for certain
>>> the effect that your suggestion would have.
>>
>> You missed part of the discussion. I don't disagree that latency is important.
>> However, if an implementation is only 95% reliable, then it means 5% of the
>> time your guest may break (corruption, crash, deadlock...). At which point the
>> latency is the last of your concern.
> 
> Yeah I missed to highlight it, also because I look at it from a slightly
> different perspective: I think IRQ latency is part of correctness.
> 
> If we have a solution that is not 100% faithful to the specification we
> are going to break guests that rely on a faithful implementation of
> ISACTIVER.
> 
> If we have a solution that is 100% faithful to the specification but
> causes latency spikes it breaks RT guests.
> 
> But they are different sets of guests, it is not like one is necessarily
> a subset of the other: there are guests that cannot tolerate any latency
> spikes but they are OK with an imprecise implementation of ISACTIVER.
> 
> My preference is a solution that is both spec-faithful and also doesn't
> cause any latency spikes. If that is not possible then we'll have to
> compromise or come up with "creative" ideas.

I do agree that latency is important. However, this needs to be based on 
numbers or a good grasp as to why this would be an issue. Neither of 
these have been provided so far.

As we discussed on Tuesday, the cost for other vCPUs is only going to be 
a trap to the hypervisor and then back again. The cost is likely smaller 
than receiving and forwarding an interrupt.

You actually agreed on this analysis. So can you enlighten me as to why 
receiving an interrupt is a not problem for latency but this is?

> 
>>> It would be interesting to have those numbers, and I'll add to my TODO
>>> list to run the experiments you suggested, but I'll put it on the
>>> back-burner (from a Xilinx perspective it is low priority as no
>>> customers are affected.)
>>
>> How about we get a correct implementation merge first and then discuss about
>> optimization? This would allow the community to check whether there are
>> actually noticeable latency in their workload.
> 
> A correct implementation to me means that it is correct from both the
> specification point of view as well as from a latency point of view. A
> patch that potentially introduces latency spikes could cause guest
> breakage and I don't think it should be considered correct. The
> tests would have to be done beforehand.

In all honesty, writing and testing the implementation would have likely 
took you less than trying to push for "creative" ideas or your patch.

> In terms of other "creative" ideas, here are some:

"creative" ideas should really be the last resort. Correct me if I am 
wrong, but I don't think we are there yet.

> 
> One idea, as George suggested, would be to document the interface
> deviation. The intention is still to remove any deviation but at least
> we would be clear about what we have. Ideally in a single place together
> with other hypervisors. This is my preference.

It is not without saying that deviation from specification should not be 
taken lightly and has risks.

The main risk is you are never going to be able to reliably run an OS on 
Xen unless you manage to get the deviation accepted by the wider 
community and Arm.

> 
> Another idea is that we could crash the guest if GICD_ISACTIVER is read
> from a multi-vcpu guest. It is similar to what we already do today but
> better because we would do it purposely (not because of a typo) and
> because it will work for single vcpu guests at least.
> 
> We could also leave it as is (crash all the time) but it implies that
> vendors that are seeing issues with Linux today will have to keep
> maintaining patches in their private trees until a better solution is
> found. This would also be the case if we crash multi-vcpus guests as
> previously suggested.

The crash only happened when using vGICv3 not vGICv2. But did you look 
at Xen recently? Particularly at the following patch:

xen/arm: Handle unimplemented VGICv3 registers as RAZ/WI

Per the ARM Generic Interrupt Controller Architecture Specification (ARM
IHI 0069E), reserved registers should generally be treated as RAZ/WI.
To simplify the VGICv3 design and improve guest compatibility, treat the
default case for GICD and GICR registers as read_as_zero/write_ignore.

Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Acked-by: Julien Grall <julien@xen.org>

I actually pointed the patch to you during one of our weekly calls. Yet 
we agreed it would still be good to implement the register properly and 
you said you will write a patch.

Anyway, I gave you a solution and also why I think it would still be 
fine in term of IRQ latency. The ball is now in your court.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 19:27:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 19:27:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK5Uu-0006uO-38; Thu, 02 Apr 2020 19:27:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK5Ut-0006uF-A2
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 19:27:27 +0000
X-Inumbo-ID: fb3fae0c-7517-11ea-bc40-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fb3fae0c-7517-11ea-bc40-12813bfff9fa;
 Thu, 02 Apr 2020 19:27:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585855646;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=0/KDRRY/GU4JbKbe1mxyU/E+8AEPozxZ5HNKB69pRC4=;
 b=fnxU6cn6mxnAwB+Z1wOPDlzUT8nSSEz1CLQqJFaj2X4CPnZuUUSyJ94u
 Fo9bYpuGotgLoYNvOhv8gJFGG8fFuuBgi6QWxRmt1F2BINFFTSmr8TXTS
 dJQrG45nOz82NF+Kn71VnuCrFXgHjo3QgTGIlVOSfteiQEtbRBNXN5RYF E=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Th6MFBVPi4reJpgwgDy4jIl3tdZUdSm90d6A04M+n2rtNDZnYhyfTyHG7NRFOabABi2n6T0N87
 kdPfinoDRNw0ES+Qyh/Yz0Ej1eNnD/e6UcjcTCpF8XxIfZDqEeNrmjakjmikAGABauj4a0jSpG
 7pGtO/do74wG+WBc+0zkWYgvWC8jTUD5yqQ/TIVLMSyy4j4B8pJgGjTNDFsI+0dOrfd52pyLxa
 YLgzeFlI8FXh7P7Gm9Bc5nF2yzFNR3zSGetKZc3hbCeVBlPtJ+RjMXca/xSDcHN7wKoKF0DeqG
 yUE=
X-SBRS: 2.7
X-MesageID: 15313881
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,336,1580792400"; d="scan'208";a="15313881"
Subject: Re: [PATCH v2] x86/PV: remove unnecessary toggle_guest_pt() overhead
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <47cf43bb-9643-011f-45c2-7cb63c422c3f@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <61b00d2c-f862-2500-d958-7ff8e8823409@citrix.com>
Date: Thu, 2 Apr 2020 20:27:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <47cf43bb-9643-011f-45c2-7cb63c422c3f@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/12/2019 14:06, Jan Beulich wrote:
> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
> expensive (but still needed only for the toggle_guest_mode() path), the
> effect of the latter on the exit-to-guest path is not insignificant.
> Move the logic into toggle_guest_mode(), on the basis that
> toggle_guest_pt() will always be invoked in pairs, yet we can't safely
> undo the setting of root_pgt_changed during the second of these
> invocations.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Ohhhhh.

I think this is the first time I've actually understood the "overhead"
you're talking about here, but honestly, I still had to work very hard
to figure it out.

If I were writing the commit message, it would be something like this:

Logic such as guest_io_okay() and guest_get_eff_kern_l1e() calls
toggle_guest_pt() in pairs to pull a value out of guest kernel memory,
then return to the previous pagetable context.

This is transparent and doesn't modify the pagetables, so there is no
need to undergo an expensive resync on the return-to-guest path
triggered by setting cpu_info->root_pgt_changed.

Move the logic from _toggle_guest_pt() to toggle_guest_mode(), which is
intending to return to guest context in a different pagetable context.

> ---
> v2: Extend description.
>
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -365,18 +365,10 @@ bool __init xpti_pcid_enabled(void)
>  
>  static void _toggle_guest_pt(struct vcpu *v)
>  {
> -    const struct domain *d = v->domain;
> -    struct cpu_info *cpu_info = get_cpu_info();
>      unsigned long cr3;
>  
>      v->arch.flags ^= TF_kernel_mode;
>      update_cr3(v);
> -    if ( d->arch.pv.xpti )
> -    {
> -        cpu_info->root_pgt_changed = true;
> -        cpu_info->pv_cr3 = __pa(this_cpu(root_pgt)) |
> -                           (d->arch.pv.pcid ? get_pcid_bits(v, true) : 0);
> -    }
>  
>      /*
>       * Don't flush user global mappings from the TLB. Don't tick TLB clock.
> @@ -384,15 +376,11 @@ static void _toggle_guest_pt(struct vcpu
>       * In shadow mode, though, update_cr3() may need to be accompanied by a
>       * TLB flush (for just the incoming PCID), as the top level page table may
>       * have changed behind our backs. To be on the safe side, suppress the
> -     * no-flush unconditionally in this case. The XPTI CR3 write, if enabled,
> -     * will then need to be a flushing one too.
> +     * no-flush unconditionally in this case.
>       */
>      cr3 = v->arch.cr3;
> -    if ( shadow_mode_enabled(d) )
> -    {
> +    if ( shadow_mode_enabled(v->domain) )
>          cr3 &= ~X86_CR3_NOFLUSH;
> -        cpu_info->pv_cr3 &= ~X86_CR3_NOFLUSH;
> -    }
>      write_cr3(cr3);
>  
>      if ( !(v->arch.flags & TF_kernel_mode) )
> @@ -408,6 +396,8 @@ static void _toggle_guest_pt(struct vcpu
>  
>  void toggle_guest_mode(struct vcpu *v)
>  {
> +    const struct domain *d = v->domain;
> +
>      ASSERT(!is_pv_32bit_vcpu(v));
>  
>      /* %fs/%gs bases can only be stale if WR{FS,GS}BASE are usable. */
> @@ -421,6 +411,21 @@ void toggle_guest_mode(struct vcpu *v)
>      asm volatile ( "swapgs" );
>  
>      _toggle_guest_pt(v);
> +
> +    if ( d->arch.pv.xpti )
> +    {
> +        struct cpu_info *cpu_info = get_cpu_info();
> +
> +        cpu_info->root_pgt_changed = true;
> +        cpu_info->pv_cr3 = __pa(this_cpu(root_pgt)) |
> +                           (d->arch.pv.pcid ? get_pcid_bits(v, true) : 0);
> +        /*
> +         * As in _toggle_guest_pt() the XPTI CR3 write needs to be a TLB-
> +         * flushing one too for shadow mode guests.
> +         */
> +        if ( shadow_mode_enabled(d) )
> +            cpu_info->pv_cr3 &= ~X86_CR3_NOFLUSH;
> +    }
>  }
>  

I think this wants a note for anyone trying to follow the logic.

/* Must be called in matching pairs without returning to guest context
inbetween. */

>  void toggle_guest_pt(struct vcpu *v)

If the callers were more complicated than they are, or we might credibly
gain more users, I would suggest it would be worth trying to assert the
"called in pairs" aspect.

However, I can't think of any trivial way to check this, and I don't
think it is worth a complicated check.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 19:49:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 19:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK5q6-00008B-4Q; Thu, 02 Apr 2020 19:49:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK5q4-000084-HB
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 19:49:20 +0000
X-Inumbo-ID: 0aaf6e2e-751b-11ea-bc44-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0aaf6e2e-751b-11ea-bc44-12813bfff9fa;
 Thu, 02 Apr 2020 19:49:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585856959;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=tJwoL6aTNYaILi/LbqxbNGMoSAw9V8aOHaftap4s9bM=;
 b=FCFaWbIbo9X09kOf9oCKquGduQ0fHPXDzU2RQ/oWeH9eiU5WuMrOpgvh
 XT3vHHeDQazCo3dNxUC3ENe4vINFKwAls8p6Hcss67OHWFQhhdNPeQynt
 osIds0byMs5lXBPq5jQjEIC0eApfO4eMCOdOHwQraMrzPUu7KCyCG2hly k=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: sdY2LuPCHrQmywvJLp0ILQqrHF4lI+0tzB21uVV4oBpfM+EGOvIauixN8Uc0eicqLbGTVTobtO
 ZU2TP6th5i75N3o0W+ikk2UurO6dqsV9O0jDtbgf9+Jv1GLSEXualGyGV3CxshMulCdla2MKef
 2PYRiZqmu5ZK/W/domGY3idJhGar00xRu5a2JVKlVg7xLpggsSHOyR86jgZy8TGUIT/SwlkPCM
 UksnUAjd4rxRiK80Hje+15FrHBkpcKIaQjnybFDn807gBuOlfttItk7i/mGnWTOusia//tMu2F
 JhU=
X-SBRS: 2.7
X-MesageID: 15418425
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,336,1580792400"; d="scan'208";a="15418425"
Subject: Re: [PATCH] x86/HVM: expose VM assist hypercall
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <cb4a6f8f-eda8-f17c-54e5-af1353d6358c@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <18adfe82-4882-c835-cd1d-b3069416e0ab@citrix.com>
Date: Thu, 2 Apr 2020 20:49:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <cb4a6f8f-eda8-f17c-54e5-af1353d6358c@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02/04/2020 08:46, Jan Beulich wrote:
> In preparation for the addition of VMASST_TYPE_runstate_update_flag
> commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
> the hypercall for Arm. I consider it not logical that it then isn't also
> exposed to x86 HVM guests (with the same single feature permitted to be
> enabled as Arm has); Linux actually tries to use it afaict.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I'd declare this a bug in 2529c850ea4.  It was clearly intended as a
common feature, and wasn't tested for HVM guests.

However, ...

>
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -78,6 +78,11 @@ static long hvm_grant_table_op(
>  }
>  #endif
>  
> +static long hvm_vm_assist(unsigned int cmd, unsigned int type)
> +{
> +    return vm_assist(current->domain, cmd, type, HVM_VM_ASSIST_VALID);
> +}
> +
>  static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      const struct vcpu *curr = current;
> @@ -128,6 +133,7 @@ static const hypercall_table_t hvm_hyper
>  #ifdef CONFIG_GRANT_TABLE
>      HVM_CALL(grant_table_op),
>  #endif
> +    HVM_CALL(vm_assist),

... this means we've now got 3 stub functions making no-op ABI changes
for the general vm_assist() function.

Renaming it to do_vm_assist(), latch current->domain internally, and an
arch_vm_assist_valid(d) helper can cover the final parameter.

~Andrew

>      COMPAT_CALL(vcpu_op),
>      HVM_CALL(physdev_op),
>      COMPAT_CALL(xen_version),
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -319,6 +319,7 @@ extern unsigned long xen_phys_start;
>  #define VM_ASSIST_VALID          NATIVE_VM_ASSIST_VALID
>  #define COMPAT_VM_ASSIST_VALID   (NATIVE_VM_ASSIST_VALID & \
>                                    ((1UL << COMPAT_BITS_PER_LONG) - 1))
> +#define HVM_VM_ASSIST_VALID      (1UL << VMASST_TYPE_runstate_update_flag)
>  
>  #define ELFSIZE 64
>  



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 20:51:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 20:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK6nc-0005cs-1u; Thu, 02 Apr 2020 20:50:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9JfQ=5S=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jK6nb-0005cn-BW
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 20:50:51 +0000
X-Inumbo-ID: 9f2dc926-7523-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9f2dc926-7523-11ea-b58d-bc764e2007e4;
 Thu, 02 Apr 2020 20:50:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=NUyCOlxPJIg0la8D2yOVsCI1jLofK8x9EjzMxhDbaWs=; b=FEbkuVK1my6q2Omy+RKkHOpys
 +UNdahFLwEOZnjzx3bs1dwWhrFhSk+Qq4h/w6DsVqZ0wPP/RwMpP4znlafOTTQheLLVbbSRw/pGUE
 FAR37HdqzyQpL3+FJM9v+GR51ZXs6FxApwpvhW9b6fERWAZIfVMNS7bzo3sKrFAorOkjc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK6nU-00077M-1m; Thu, 02 Apr 2020 20:50:44 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK6nT-0001l5-KI; Thu, 02 Apr 2020 20:50:43 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jK6nT-0003Nc-Gm; Thu, 02 Apr 2020 20:50:43 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149311-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149311: regressions - FAIL
X-Osstest-Failures: linux-5.4:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:regression
 linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 linux-5.4:test-amd64-amd64-dom0pvh-xl-intel:guest-start:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=73fea3292b4995fe5c20f774421705ada0e62100
X-Osstest-Versions-That: linux=122179cb7d648a6f36b20dd6bf34f953cb384c30
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 02 Apr 2020 20:50:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 146121

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 12 guest-start        fail baseline untested
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                73fea3292b4995fe5c20f774421705ada0e62100
baseline version:
 linux                122179cb7d648a6f36b20dd6bf34f953cb384c30

Last test of basis   146121  2020-01-15 17:42:04 Z   78 days
Failing since        146178  2020-01-17 02:59:07 Z   76 days  103 attempts
Testing same since   149311  2020-04-02 02:13:04 Z    0 days    1 attempts

------------------------------------------------------------
1474 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 22:19:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 22:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK8Ai-0003hZ-9b; Thu, 02 Apr 2020 22:18:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK8Ag-0003hU-VG
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 22:18:47 +0000
X-Inumbo-ID: ea9e8290-752f-11ea-9e09-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ea9e8290-752f-11ea-9e09-bc764e2007e4;
 Thu, 02 Apr 2020 22:18:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585865926;
 h=subject:from:to:cc:references:message-id:date:
 mime-version:in-reply-to;
 bh=V+BYlDbt5VaX6l7UurX0dqUtIwbbe8/5zu3+rWVzfT4=;
 b=EC8o0UJ27/JTOKizZ4d58AjXYQrlFCgup1T3immFx85HOHKKJpE6wx42
 Qh4EZLHB1wO71DkDi3Bz317WbrFBS5ElwAgkuyEfMxFlYJMVSTJwa5U9X
 GomfTX+c6DC0gGfzXEpvoAquLjSr75d3qvqOfu49WJeDf99tir2PlUAN2 U=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 4XDBMQlsE9wvKWjYTz3TcE/hfLAEvWQsoQBrG0lf9GrrblY5xDXUiE3yWo0m21cA+SY7Pa2mqv
 vn5xiogpx+lxFt54wY4ayVwTrkC4PCXk0Nb2eGw7q2cMJ+VBBXNZW2/kWQOzB19/ofaeoV+9y1
 IFS4iDxii5fUk2NBnhAdFcP68WmJv68or4nMt5oUJFzmLXOW4axwdAaoDEDE/fnIhoxQeubI1x
 mhy1cUox6cFSF33Q2sE/7SvQb3Mghy3CqYtW9tCiLoj2jV+oXiJQX7NqMtklqQL7Tiq7ChIE6q
 P1Y=
X-SBRS: 2.7
X-MesageID: 15083595
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,337,1580792400"; d="scan'208,223";a="15083595"
Subject: Re: [Xen-devel] [PATCH 5/5] x86emul: disable FPU/MMX/SIMD insn
 emulation when !HVM
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <7f7a6ba3-7308-b079-2df1-f5b8501b3cc6@suse.com>
 <87154c20-c60e-a215-f7f4-0290fadd90e4@suse.com>
 <dbc03c9d-bfc2-3313-1ffe-8ffe79b2c1e1@citrix.com>
Message-ID: <a016ba7f-f860-9372-caab-d9400c064fd9@citrix.com>
Date: Thu, 2 Apr 2020 23:18:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <dbc03c9d-bfc2-3313-1ffe-8ffe79b2c1e1@citrix.com>
Content-Type: multipart/mixed; boundary="------------9B8F09996F1F184A31746144"
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--------------9B8F09996F1F184A31746144
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On 20/12/2019 16:01, Andrew Cooper wrote:
>> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> I'll be happy to take suggestions allowing to avoid -Wno-unused-label.
> I think I'm going to need a little while to figure out how this works.

So, after having had an evening playing with this, things get massively
simpler when NO_MMX is folded with NO_SIMD.

MMX is a SIMD technology, and I can't see a compelling reason to control
their inclusion separately.  We're either going to want everything or
nothing.

The attached incremental works for me without a single out-of-place
label.  There is some further cleanup which can be done such as not
making the CASE_ macros conditional.  (OTOH, the compile error from
might be helpful to keep in some form).

Thoughts?

~Andrew

--------------9B8F09996F1F184A31746144
Content-Type: text/x-patch; charset="UTF-8"; name="0001-incremental.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="0001-incremental.patch"

>From aa8ea9998c643bc518ec8b4208e20da352a54129 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 2 Apr 2020 23:11:58 +0100
Subject: incremental


diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 71f1d7784e..e954edbc2e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -72,9 +72,6 @@ obj-y += hpet.o
 obj-y += vm_event.o
 obj-y += xstate.o
 
-ifneq ($(CONFIG_HVM),y)
-x86_emulate.o: CFLAGS += -Wno-unused-label
-endif
 x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
 
 efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index 6d5e5b8b2a..21c57941ef 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6172,6 +6172,8 @@ x86_emulate(
 
 #endif
 
+#ifndef X86EMUL_NO_SIMD
+
     CASE_SIMD_SCALAR_FP(, 0x0f, 0x2b):     /* movnts{s,d} xmm,mem */
         host_and_vcpu_must_have(sse4a);
         /* fall through */
@@ -6309,8 +6311,6 @@ x86_emulate(
         insn_bytes = EVEX_PFX_BYTES + 2;
         break;
 
-#ifndef X86EMUL_NO_SIMD
-
     case X86EMUL_OPC_66(0x0f, 0x12):       /* movlpd m64,xmm */
     case X86EMUL_OPC_VEX_66(0x0f, 0x12):   /* vmovlpd m64,xmm,xmm */
     CASE_SIMD_PACKED_FP_VEX(0x0f, 0x13):   /* movlp{s,d} xmm,m64 */
@@ -6445,7 +6445,7 @@ x86_emulate(
             goto done;
         break;
 
-#if !defined(X86EMUL_NO_MMX) && !defined(X86EMUL_NO_SIMD)
+#ifndef X86EMUL_NO_SIMD
 
     case X86EMUL_OPC_66(0x0f, 0x2a):       /* cvtpi2pd mm/m64,xmm */
         if ( ea.type == OP_REG )
@@ -6458,8 +6458,6 @@ x86_emulate(
         op_bytes = (b & 4) && (vex.pfx & VEX_PREFIX_DOUBLE_MASK) ? 16 : 8;
         goto simd_0f_fp;
 
-#endif /* !X86EMUL_NO_MMX && !X86EMUL_NO_SIMD */
-
     CASE_SIMD_SCALAR_FP_VEX(0x0f, 0x2a):   /* {,v}cvtsi2s{s,d} r/m,xmm */
         if ( vex.opcx == vex_none )
         {
@@ -6681,6 +6679,8 @@ x86_emulate(
         op_bytes = 4 << evex.w;
         goto vcomi;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC(0x0f, 0x30): /* wrmsr */
         generate_exception_if(!mode_ring0(), EXC_GP, 0);
         fail_if(ops->write_msr == NULL);
@@ -6862,8 +6862,6 @@ x86_emulate(
         generate_exception_if(!vex.l || vex.w, EXC_UD);
         goto opmask_common;
 
-#endif /* X86EMUL_NO_SIMD */
-
     CASE_SIMD_PACKED_FP_VEX(0x0f, 0x50):   /* movmskp{s,d} xmm,reg */
                                            /* vmovmskp{s,d} {x,y}mm,reg */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xd7):  /* pmovmskb {,x}mm,reg */
@@ -6947,8 +6945,6 @@ x86_emulate(
                          evex.w);
         goto avx512f_all_fp;
 
-#ifndef X86EMUL_NO_SIMD
-
     CASE_SIMD_PACKED_FP_VEX(0x0f, 0x5b):   /* cvt{ps,dq}2{dq,ps} xmm/mem,xmm */
                                            /* vcvt{ps,dq}2{dq,ps} {x,y}mm/mem,{x,y}mm */
     case X86EMUL_OPC_F3(0x0f, 0x5b):       /* cvttps2dq xmm/mem,xmm */
@@ -6979,8 +6975,6 @@ x86_emulate(
         op_bytes = 16 << evex.lr;
         goto simd_zmm;
 
-#endif /* !X86EMUL_NO_SIMD */
-
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x60): /* punpcklbw {,x}mm/mem,{,x}mm */
                                           /* vpunpcklbw {x,y}mm/mem,{x,y}mm,{x,y}mm */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x61): /* punpcklwd {,x}mm/mem,{,x}mm */
@@ -7007,7 +7001,6 @@ x86_emulate(
                                           /* vpackusbw {x,y}mm/mem,{x,y}mm,{x,y}mm */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x6b): /* packsswd {,x}mm/mem,{,x}mm */
                                           /* vpacksswd {x,y}mm/mem,{x,y}mm,{x,y}mm */
-#ifndef X86EMUL_NO_SIMD
     case X86EMUL_OPC_66(0x0f, 0x6c):     /* punpcklqdq xmm/m128,xmm */
     case X86EMUL_OPC_VEX_66(0x0f, 0x6c): /* vpunpcklqdq {x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_66(0x0f, 0x6d):     /* punpckhqdq xmm/m128,xmm */
@@ -7092,7 +7085,6 @@ x86_emulate(
                                           /* vpsubd {x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_66(0x0f, 0xfb):     /* psubq xmm/m128,xmm */
     case X86EMUL_OPC_VEX_66(0x0f, 0xfb): /* vpsubq {x,y}mm/mem,{x,y}mm,{x,y}mm */
-#endif /* !X86EMUL_NO_SIMD */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xfc): /* paddb {,x}mm/mem,{,x}mm */
                                           /* vpaddb {x,y}mm/mem,{x,y}mm,{x,y}mm */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xfd): /* paddw {,x}mm/mem,{,x}mm */
@@ -7100,7 +7092,6 @@ x86_emulate(
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xfe): /* paddd {,x}mm/mem,{,x}mm */
                                           /* vpaddd {x,y}mm/mem,{x,y}mm,{x,y}mm */
     simd_0f_int:
-#ifndef X86EMUL_NO_SIMD
         if ( vex.opcx != vex_none )
         {
     case X86EMUL_OPC_VEX_66(0x0f38, 0x00): /* vpshufb {x,y}mm/mem,{x,y}mm,{x,y}mm */
@@ -7142,14 +7133,11 @@ x86_emulate(
         }
         if ( vex.pfx )
             goto simd_0f_sse2;
-#endif /* !X86EMUL_NO_SIMD */
     simd_0f_mmx:
         host_and_vcpu_must_have(mmx);
         get_fpu(X86EMUL_FPU_mmx);
         goto simd_0f_common;
 
-#ifndef X86EMUL_NO_SIMD
-
     case X86EMUL_OPC_EVEX_66(0x0f, 0xf6): /* vpsadbw [xyz]mm/mem,[xyz]mm,[xyz]mm */
         generate_exception_if(evex.opmsk, EXC_UD);
         /* fall through */
@@ -7243,8 +7231,6 @@ x86_emulate(
         generate_exception_if(!evex.w, EXC_UD);
         goto avx512f_no_sae;
 
-#endif /* X86EMUL_NO_SIMD */
-
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x6e): /* mov{d,q} r/m,{,x}mm */
                                           /* vmov{d,q} r/m,xmm */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x7e): /* mov{d,q} {,x}mm,r/m */
@@ -7286,8 +7272,6 @@ x86_emulate(
         ASSERT(!state->simd_size);
         break;
 
-#ifndef X86EMUL_NO_SIMD
-
     case X86EMUL_OPC_EVEX_66(0x0f, 0x6e): /* vmov{d,q} r/m,xmm */
     case X86EMUL_OPC_EVEX_66(0x0f, 0x7e): /* vmov{d,q} xmm,r/m */
         generate_exception_if((evex.lr || evex.opmsk || evex.brs ||
@@ -7360,15 +7344,11 @@ x86_emulate(
         d |= TwoOp;
         /* fall through */
     case X86EMUL_OPC_66(0x0f, 0xd6):     /* movq xmm,xmm/m64 */
-#endif /* !X86EMUL_NO_SIMD */
-#ifndef X86EMUL_NO_MMX
     case X86EMUL_OPC(0x0f, 0x6f):        /* movq mm/m64,mm */
     case X86EMUL_OPC(0x0f, 0x7f):        /* movq mm,mm/m64 */
-#endif
         op_bytes = 8;
         goto simd_0f_int;
 
-#ifndef X86EMUL_NO_SIMD
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x70):/* pshuf{w,d} $imm8,{,x}mm/mem,{,x}mm */
                                          /* vpshufd $imm8,{x,y}mm/mem,{x,y}mm */
     case X86EMUL_OPC_F3(0x0f, 0x70):     /* pshufhw $imm8,xmm/m128,xmm */
@@ -7377,15 +7357,12 @@ x86_emulate(
     case X86EMUL_OPC_VEX_F2(0x0f, 0x70): /* vpshuflw $imm8,{x,y}mm/mem,{x,y}mm */
         d = (d & ~SrcMask) | SrcMem | TwoOp;
         op_bytes = vex.pfx ? 16 << vex.l : 8;
-#endif
     simd_0f_int_imm8:
         if ( vex.opcx != vex_none )
         {
-#ifndef X86EMUL_NO_SIMD
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0e): /* vpblendw $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0f): /* vpalignr $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x42): /* vmpsadbw $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
-#endif
             if ( vex.l )
             {
     simd_0f_imm8_avx2:
@@ -7393,7 +7370,6 @@ x86_emulate(
             }
             else
             {
-#ifndef X86EMUL_NO_SIMD
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x08): /* vroundps $imm8,{x,y}mm/mem,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x09): /* vroundpd $imm8,{x,y}mm/mem,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0a): /* vroundss $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
@@ -7401,7 +7377,6 @@ x86_emulate(
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0c): /* vblendps $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0d): /* vblendpd $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x40): /* vdpps $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
-#endif
     simd_0f_imm8_avx:
                 host_and_vcpu_must_have(avx);
             }
@@ -7435,8 +7410,6 @@ x86_emulate(
         insn_bytes = PFX_BYTES + 3;
         break;
 
-#ifndef X86EMUL_NO_SIMD
-
     case X86EMUL_OPC_EVEX_66(0x0f, 0x70): /* vpshufd $imm8,[xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_F3(0x0f, 0x70): /* vpshufhw $imm8,[xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_F2(0x0f, 0x70): /* vpshuflw $imm8,[xyz]mm/mem,[xyz]mm{k} */
@@ -8320,6 +8293,8 @@ x86_emulate(
         }
         goto add;
 
+#ifndef X86EMUL_NO_SIMD
+
     CASE_SIMD_ALL_FP_VEX(0x0f, 0xc2):      /* cmp{p,s}{s,d} $imm8,xmm/mem,xmm */
                                            /* vcmp{p,s}{s,d} $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
     CASE_SIMD_PACKED_FP_VEX(0x0f, 0xc6):   /* shufp{s,d} $imm8,xmm/mem,xmm */
@@ -8335,8 +8310,6 @@ x86_emulate(
         }
         goto simd_0f_imm8_avx;
 
-#ifndef X86EMUL_NO_SIMD
-
     CASE_SIMD_ALL_FP(_EVEX, 0x0f, 0xc2): /* vcmp{p,s}{s,d} $imm8,[xyz]mm/mem,[xyz]mm,k{k} */
         generate_exception_if((evex.w != (evex.pfx & VEX_PREFIX_DOUBLE_MASK) ||
                                (ea.type != OP_REG && evex.brs &&
@@ -8372,6 +8345,8 @@ x86_emulate(
         sfence = true;
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xc4):  /* pinsrw $imm8,r32/m16,{,x}mm */
                                            /* vpinsrw $imm8,r32/m16,xmm,xmm */
         generate_exception_if(vex.l, EXC_UD);
@@ -8379,8 +8354,6 @@ x86_emulate(
         ea.type = OP_MEM;
         goto simd_0f_int_imm8;
 
-#ifndef X86EMUL_NO_SIMD
-
     case X86EMUL_OPC_EVEX_66(0x0f, 0xc4):   /* vpinsrw $imm8,r32/m16,xmm,xmm */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x20): /* vpinsrb $imm8,r32/m8,xmm,xmm */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x22): /* vpinsr{d,q} $imm8,r/m,xmm,xmm */
@@ -8398,8 +8371,6 @@ x86_emulate(
         state->simd_size = simd_other;
         goto avx512f_imm8_no_sae;
 
-#endif /* !X86EMUL_NO_SIMD */
-
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xc5):  /* pextrw $imm8,{,x}mm,reg */
                                            /* vpextrw $imm8,xmm,reg */
         generate_exception_if(vex.l, EXC_UD);
@@ -8415,8 +8386,6 @@ x86_emulate(
         insn_bytes = PFX_BYTES + 3;
         goto simd_0f_to_gpr;
 
-#ifndef X86EMUL_NO_SIMD
-
     CASE_SIMD_PACKED_FP(_EVEX, 0x0f, 0xc6): /* vshufp{s,d} $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
         generate_exception_if(evex.w != (evex.pfx & VEX_PREFIX_DOUBLE_MASK),
                               EXC_UD);
@@ -8706,8 +8675,6 @@ x86_emulate(
         op_bytes = 8 << (!!(vex.pfx & VEX_PREFIX_DOUBLE_MASK) + vex.l);
         goto simd_0f_cvt;
 
-#endif /* !X86EMUL_NO_SIMD */
-
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xf7): /* {,v}maskmov{q,dqu} {,x}mm,{,x}mm */
         generate_exception_if(ea.type != OP_REG, EXC_UD);
         if ( vex.opcx != vex_none )
@@ -8811,8 +8778,6 @@ x86_emulate(
         insn_bytes = PFX_BYTES + 3;
         break;
 
-#ifndef X86EMUL_NO_SIMD
-
     case X86EMUL_OPC_VEX_66(0x0f38, 0x19): /* vbroadcastsd xmm/m64,ymm */
     case X86EMUL_OPC_VEX_66(0x0f38, 0x1a): /* vbroadcastf128 m128,ymm */
         generate_exception_if(!vex.l, EXC_UD);
@@ -10233,8 +10198,6 @@ x86_emulate(
         avx512_vlen_check(b & 2);
         goto simd_imm8_zmm;
 
-#endif /* X86EMUL_NO_SIMD */
-
     CASE_SIMD_PACKED_INT(0x0f3a, 0x0f): /* palignr $imm8,{,x}mm/mem,{,x}mm */
         host_and_vcpu_must_have(ssse3);
         if ( vex.pfx )
@@ -10262,8 +10225,6 @@ x86_emulate(
         insn_bytes = PFX_BYTES + 4;
         break;
 
-#ifndef X86EMUL_NO_SIMD
-
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x42): /* vdbpsadbw $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
         generate_exception_if(evex.w, EXC_UD);
         /* fall through */
@@ -11613,9 +11574,11 @@ x86_insn_is_mem_access(const struct x86_emulate_state *state,
     case 0xa4 ... 0xa7: /* MOVS / CMPS */
     case 0xaa ... 0xaf: /* STOS / LODS / SCAS */
     case 0xd7:          /* XLAT */
+#ifndef X86EMUL_NO_SIMD
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xf7): /* MASKMOV{Q,DQU} */
                                           /* VMASKMOVDQU */
         return true;
+#endif
 
     case X86EMUL_OPC(0x0f, 0x01):
         /* Cover CLZERO. */

--------------9B8F09996F1F184A31746144--


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 22:31:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 22:31:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK8Mi-0005DG-FB; Thu, 02 Apr 2020 22:31:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK8Mh-0005DB-EB
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 22:31:11 +0000
X-Inumbo-ID: a6efc2d2-7531-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a6efc2d2-7531-11ea-83d8-bc764e2007e4;
 Thu, 02 Apr 2020 22:31:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585866670;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=c2nQkuxQNUaWQm1e+Z4FNYDbSxWQmDFJ7gTDJN/Vsdw=;
 b=NohrZcyJw2VUHKg+OhWUBdaoPcV9msjfQMD2uY1PAKVtHI/FWz8zn1s5
 OuEfEUIpCQKsBMbSzsEMSuLODA6bSsEjqQZexQHH+B5HgoGhpjSEaKL4Q
 REV7NZGIj1OvZB2lF2dwcRrFUxVtdg+8IL/qtYuxHvwz2ILbU2huo59p0 Y=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: w2wAchyD0EEP5+skqV6pmzbKVV3yiSNoOJujJWgpwPw7K5LXZDdR5BGwQ/ILbe/XOVkqAdj4Mr
 IQMR0NkWrXWAxPAes6VyIL0ENT925pONtMBQup1OwYvCXdiaYP3UJ5O6gSVsi+oI8DwVKN7yQs
 La9NmavEfjvw+btPNHElFaW82S6X7p9IzKmPdyIQ4eJ5VFHzhW1QmdT/VsPPD1yqm3uDbD8tk6
 Ty3SU5yl01xFdZoEEbHh5rOH85V8+xg0u6qkG5WBIuGuwEbsVHwHQU1tChzm1w9GuPHF+99amC
 kkU=
X-SBRS: 2.7
X-MesageID: 15509126
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,337,1580792400"; d="scan'208";a="15509126"
Subject: Re: [PATCH 1/5] x86/p2m: don't ignore p2m_remove_page()'s return value
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
 <88aa25d4-9772-8a2b-48c4-c0138ef000b9@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <6bae2e4a-4bc5-87ad-484c-0debfbc33961@citrix.com>
Date: Thu, 2 Apr 2020 23:31:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <88aa25d4-9772-8a2b-48c4-c0138ef000b9@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 01/04/2020 12:38, Jan Beulich wrote:
> It's not very nice to return from guest_physmap_add_entry() after
> perhaps already having made some changes to the P2M, but this is pre-
> existing practice in the function, and imo better than ignoring errors.
>
> Take the liberty and replace an mfn_add() instance with a local variable
> already holding the result (as proven by the check immediately ahead).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 22:38:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 22:38:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK8Ti-0005R5-CM; Thu, 02 Apr 2020 22:38:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9JfQ=5S=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jK8Tg-0005R0-Nm
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 22:38:24 +0000
X-Inumbo-ID: a6242626-7532-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a6242626-7532-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 22:38:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Message-Id:Subject:To:Sender:
 Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=d4bI8m5wB5DQjCLvfM2duDzQy8K80YCofUsKOyKYndk=; b=1LFIsT6GAd3M2wdRHmK5Iz+jFa
 O1D61vHMBBGJkY3adxVxASSAhiyfVxW4zDTNBtaYaNrqT3xdqyUfhbLGSVY08upGsyVJxSw9N+dJJ
 WF/NVgqWf26ZkdPGS44aD5PQMwm8XoDlwNpeTzPmrRWpi8rgAhgHR+aiJY5OGdvfodgU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK8TZ-0000lS-PJ; Thu, 02 Apr 2020 22:38:17 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK8TZ-0007kG-CR; Thu, 02 Apr 2020 22:38:17 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jK8TZ-0007Be-Bs; Thu, 02 Apr 2020 22:38:17 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Subject: [linux-linus bisection] complete build-arm64-pvops
Message-Id: <E1jK8TZ-0007Be-Bs@osstest.test-lab.xenproject.org>
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 02 Apr 2020 22:38:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

branch xen-unstable
xenbranch xen-unstable
job build-arm64-pvops
testid kernel-build

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  f0b5989745c3e0e92424d36869a97e4e8df7ab13
  Bug not present: 7111951b8d4973bda27ff663f2cf18b663d15b48
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149364/


  (Revision log too long, omitted.)


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

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/build-arm64-pvops.kernel-build --summary-out=tmp/149364.bisection-summary --basis-template=149238 --blessings=real,real-bisect linux-linus build-arm64-pvops kernel-build
Searching for failure / basis pass:
 149306 fail [host=laxton1] / 149238 [host=rochester1] 149198 [host=rochester0] 149158 ok.
Failure / basis pass flights: 149306 / 149158
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Latest 668f1e9267415153e30bea03828c0530874e92e4 c530a75c1e6a472b0eb9558310b518f0dfcd8860
Basis pass e595dd94515ed6bc5ba38fce0f9598db8c0ee9a9 c530a75c1e6a472b0eb9558310b518f0dfcd8860
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#e595dd94515ed6bc5ba38fce0f9598db8c0ee9a9-668f1e9267415153e30bea03828c0530874e92e4 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
Loaded 5162 nodes in revision graph
Searching for test results:
 149198 [host=rochester0]
 149158 pass e595dd94515ed6bc5ba38fce0f9598db8c0ee9a9 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149238 [host=rochester1]
 149320 fail bc82521e3b8e8cfa7e0136080c75a3af3a1b448a c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149331 fail 5b071c59ede04db200d9eccb97701261461e89bf c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149307 pass e595dd94515ed6bc5ba38fce0f9598db8c0ee9a9 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149321 fail 4c0d6d3a7a81fcd2dcb4abf15fe2e13074cf8619 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149322 fail a6af77637adc92aa0725ac14f71ad915c6000609 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149332 fail a7a29f9c361f8542604ef959ae6627f423b7a412 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149309 fail 1a323ea5356edbb3073dc59d51b9e6b86908857d c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149324 fail 49d3b493673a000b5e9fd8bf1b286e847f104fa9 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149266 fail 1a323ea5356edbb3073dc59d51b9e6b86908857d c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149315 fail d63439f575dc3927331d8fbc6448f15902187d38 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149333 fail 3f8e0aae1796363442f6d0b7bc2210a6eecffb2d c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149318 fail 5ae8c0d51ace3bdbfb89c27e7661f081cc9287de c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149306 fail 668f1e9267415153e30bea03828c0530874e92e4 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149326 fail 48bb52c80be0e462328f58ca3a34ecfef3584320 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149334 fail 336aa67bd027f4771c3a7f3d8a3fd15d923f5df5 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149328 fail 93a129eb8c520b032e1823447b2e1badcc650666 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149329 fail 876aa9f527cd0ddc857337aba3683298b3abe6ab c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149342 pass 7111951b8d4973bda27ff663f2cf18b663d15b48 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149336 fail bd734a742d5533fb9190ecd8cf25befc1f759a5b c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149338 pass 570203ec830dd451b8804cdef8036f7fca9f0311 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149341 fail f0b5989745c3e0e92424d36869a97e4e8df7ab13 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149347 fail 668f1e9267415153e30bea03828c0530874e92e4 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149357 pass 7111951b8d4973bda27ff663f2cf18b663d15b48 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149356 fail f0b5989745c3e0e92424d36869a97e4e8df7ab13 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149362 pass 7111951b8d4973bda27ff663f2cf18b663d15b48 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149359 fail f0b5989745c3e0e92424d36869a97e4e8df7ab13 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 149364 fail f0b5989745c3e0e92424d36869a97e4e8df7ab13 c530a75c1e6a472b0eb9558310b518f0dfcd8860
Searching for interesting versions
 Result found: flight 149158 (pass), for basis pass
 Result found: flight 149306 (fail), for basis failure
 Repro found: flight 149307 (pass), for basis pass
 Repro found: flight 149347 (fail), for basis failure
 0 revisions at 7111951b8d4973bda27ff663f2cf18b663d15b48 c530a75c1e6a472b0eb9558310b518f0dfcd8860
No revisions left to test, checking graph state.
 Result found: flight 149342 (pass), for last pass
 Result found: flight 149356 (fail), for first failure
 Repro found: flight 149357 (pass), for last pass
 Repro found: flight 149359 (fail), for first failure
 Repro found: flight 149362 (pass), for last pass
 Repro found: flight 149364 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  f0b5989745c3e0e92424d36869a97e4e8df7ab13
  Bug not present: 7111951b8d4973bda27ff663f2cf18b663d15b48
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149364/


  (Revision log too long, omitted.)

Revision graph left in /home/logs/results/bisect/linux-linus/build-arm64-pvops.kernel-build.{dot,ps,png,html,svg}.
----------------------------------------
149364: tolerable ALL FAIL

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

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-arm64-pvops             6 kernel-build            fail baseline untested


jobs:
 build-arm64-pvops                                            fail    


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



From xen-devel-bounces@lists.xenproject.org Thu Apr 02 22:39:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 22:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK8Ud-0005VT-Rv; Thu, 02 Apr 2020 22:39:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK8Ud-0005VL-1K
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 22:39:23 +0000
X-Inumbo-ID: cb5373f2-7532-11ea-bc74-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cb5373f2-7532-11ea-bc74-12813bfff9fa;
 Thu, 02 Apr 2020 22:39:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585867161;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=iyMTL4rPLTuGPL5Z81bP5Pv/1ZmuqkKFyRMrZTCWA/Q=;
 b=QeBMphujy0xiTYgWzc+VGvizTSrCXhyWlonYxBZEY8gAUitvyrwu1FuM
 jgLowJ7Ts27j4g8ID7vSfdZFrvTm/Q3qfLqmPqrr45S1xnZdQsvJEuf+W
 D7U5ABY8VQuo54coWhjGjTYPzWf0ENbvLYHgbBiwf3NqPFgjjlJnepv1k U=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: RJ0ISx5vEP7UXme5B54Lwkw6plygxLnP70gNWo50TR+xpY/Oy+DZf9WSQ0Yy2XmkZlqmcBoPLj
 jSeUuhmTZTVnIMrIIEMLwN46dEUwQBPAd7phZk8v8TxQqjKBRQ8ER/9eGz4rZSJbeHUVD8c9Kh
 t5D3dIAdiNWcJRFmVzND5EWZCbBa+/46JeLA6gGobKBZgGmNb/hndInCPngZIct5yHn4hsaFUa
 WB619AMXpFKEvGHkqsuzbN7s2CUK1V3EVnlgWWf3e2BgfH5GKWE88sSf2f7okkZ8/57Wd8W15Y
 6jQ=
X-SBRS: 2.7
X-MesageID: 15425264
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,337,1580792400"; d="scan'208";a="15425264"
Subject: Re: [PATCH 2/5] x86/p2m: don't assert that the passed in MFN matches
 for a remove
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
 <da2e71b2-085b-390d-69ba-9edcbbf4fcd2@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <ab4ef9e3-0504-f7cb-d383-4922ac283339@citrix.com>
Date: Thu, 2 Apr 2020 23:39:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <da2e71b2-085b-390d-69ba-9edcbbf4fcd2@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 01/04/2020 12:39, Jan Beulich wrote:
> guest_physmap_remove_page() gets handed an MFN from the outside, yet
> takes the necessary lock to prevent further changes to the GFN <-> MFN
> mapping itself. While some callers, in particular guest_remove_page()
> (by way of having called get_gfn_query()), hold the GFN lock already,
> various others (most notably perhaps the 2nd instance in
> xenmem_add_to_physmap_one()) don't. While it also is an option to fix
> all the callers, deal with the issue in p2m_remove_page() instead:
> Replace the ASSERT() by a conditional and split the loop into two, such
> that all checking gets done before any modification would occur.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 22:43:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 22:43:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK8Ya-0006KE-CJ; Thu, 02 Apr 2020 22:43:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK8YZ-0006K9-6j
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 22:43:27 +0000
X-Inumbo-ID: 5d819236-7533-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5d819236-7533-11ea-83d8-bc764e2007e4;
 Thu, 02 Apr 2020 22:43:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585867406;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=uVYC6oO1ty0lAm57ucXZlupeAKp0WsVoGFvRgui+BAI=;
 b=X5n/ClWclvLisapZLM+p4beGt9OBQh7mwd13flsUdf8GvIwL5gOvxDnZ
 HkEICalqfM9Aw6EpUPAr4RnTNxscqcwCcyBKn7Q0rRzdIA2tFwFUt8g+f
 5F9R2/18IUsxG5QTmEFO0op1IsoO1UVGLG5cz3PPC5/DWqn6E334Q61tQ 0=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: +53wbqHD07bWYySZWpsAtQXeUT1rL2MM1RFWftJ4iFemeyQxufr2KcLaB64Ebvupb5SkAcv9cs
 TslIpVbTilM4jGUqnLMcW/cj5DJ031JTvmR9K0MDZFa1u5cvveZRQ661OhqWPWG8vVenusLWai
 +o/JbbUVQj7RKrSRxrDNS0zPaTz8y8r6ILof0nDihDjGV+O9sdsZCp7Tcavg/SFz16r6pn/Bwx
 DGAbidlFq3aKvdRaSO9XuZ3c9NTN+LXCJYXdABzjARh+6mYIQhq7L21Ts8raQOrmFUIn4FKXvb
 4Vc=
X-SBRS: 2.7
X-MesageID: 15509565
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,337,1580792400"; d="scan'208";a="15509565"
Subject: Re: [PATCH 3/5] x86/p2m: make p2m_remove_page()'s parameters type-safe
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
 <858f22e3-0f4f-08f0-ef67-b8ce67146537@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <ae425c2f-0297-4944-5bd5-03ccdab8fdce@citrix.com>
Date: Thu, 2 Apr 2020 23:43:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <858f22e3-0f4f-08f0-ef67-b8ce67146537@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 01/04/2020 12:39, Jan Beulich wrote:
> @@ -790,21 +789,23 @@ p2m_remove_page(struct p2m_domain *p2m,
>                                            &cur_order, NULL);
>  
>          if ( p2m_is_valid(t) &&
> -             (!mfn_valid(_mfn(mfn)) || mfn + i != mfn_x(mfn_return)) )
> +             (!mfn_valid(mfn) || !mfn_eq(mfn_add(mfn, i), mfn_return)) )
>              return -EILSEQ;
>  
> -        i += (1UL << cur_order) - ((gfn_l + i) & ((1UL << cur_order) - 1));
> +        i += (1UL << cur_order) -
> +             (gfn_x(gfn_add(gfn, i)) & ((1UL << cur_order) - 1));

We're gaining an number of expressions starting to look like this, but
honestly, "gfn_x(gfn) + i" is equally typesafe, shorter, and easier to
read IMO.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 22:45:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 22:45:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK8aR-0006R0-PC; Thu, 02 Apr 2020 22:45:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK8aQ-0006Qu-6s
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 22:45:22 +0000
X-Inumbo-ID: a1fbab36-7533-11ea-bc74-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a1fbab36-7533-11ea-bc74-12813bfff9fa;
 Thu, 02 Apr 2020 22:45:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585867521;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=WmVvjFHqz74Tb/GtnUZsvLt7r1IV5kg1ZHIgxk++gcE=;
 b=hJrRLJBWK21NMK/Rmks87Le7zzxOeyHopIg+LHsyKkxITWiGo215IUMb
 nVlaeQE5k+yP396NjWXcKvfLln5M79RMy3zvMtxVkseAR+orWKjFzjhIi
 wOy2kjJzQdN7q2DvBOKyaye03FX9tdaXUzS44u7PEqFaEGZHrvf4oFgp5 E=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: NPIQlOlRPL7ksXr+lG5+SsAdEl79/iyV4rs4eH0mP7xWr2dZHXyVBuEunun+gcZzRGiHfYu6PJ
 N76q4ZVuKZeT93ETULZADdfwG1p8ex7lC3V8kk0qXThnCKf+pOzOG6Kn32fc9PVnANsFqlR9+f
 e7VSDM+O4hHXWm9Tan8YCT6mEp3h24i/Mzra0OB4Ta8IXvI6EsN9vAUEOB08eUhmGRGDFkDhx3
 GcQu/Z9Qzr9I0EMXdHr05bLBYjfgLUxp+e817kL4Y3K7XNVMpHTTmTIa/jvIcjQVJJQpT29UE6
 LGo=
X-SBRS: 2.7
X-MesageID: 15509610
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,337,1580792400"; d="scan'208";a="15509610"
Subject: Re: [PATCH 4/5] x86/p2m: drop pointless nested variable from
 guest_physmap_add_entry()
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
 <c31cac8b-99b8-5cfd-bb8b-57ff529d34ad@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <e6507e5d-17fd-628c-a8e8-f0c914c18b83@citrix.com>
Date: Thu, 2 Apr 2020 23:45:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <c31cac8b-99b8-5cfd-bb8b-57ff529d34ad@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 01/04/2020 12:40, Jan Beulich wrote:
> There's an outer scope rc already, and its use for the mem-sharing logic
> does not conflict with its use elsewhere in the function.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 22:47:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 22:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK8cb-0006ZI-6q; Thu, 02 Apr 2020 22:47:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK8cZ-0006ZC-AC
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 22:47:35 +0000
X-Inumbo-ID: f16948c2-7533-11ea-b4f4-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f16948c2-7533-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 22:47:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585867654;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=9qjndwR6LrS3lrCmbsd9h17W7vgSHucDbBPEjLvw8g4=;
 b=c/DDm3JIMYHUYWoPEMTHl12NcUYXvBTfbNL8LFyEBAoE3QyKPQLU7BEN
 ZdrorphvSAzq4gfO+lm7l3HQbn0+manqmfEtivZIT91Cbrhr1FICiwjtf
 X0qUqzP0SJXW8R/5w6/1xAcFE/RT2lO8u8zvBnNXq+dXd4dMbmdaBeU/8 I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 3X1dTwt2Sk0NQg48e3B3vtiN9DCjSH2YTL6Jiy84bjCVAh0DqH94nzyOSqB6tiwIcE8jEejvZR
 dVLrrhgPwqIV1S9SfOck9hhQ9NvZiz8M/3ZX0CnXyT4eLJZMJ+taizktOz7An+hlqgSbVzK+Wu
 Url5rpSOFojcTKTON5CFyTSpNqoKJtcdAZ6eoKPl2v9xovrBfYQ01U09v7r06rLg0g/b32miRU
 Yyez7t/8tqLrujKx7a9RJ0jkOygetDJC7Q8JD8IlZe6isM/x6YnbO+7WAi95cdbQpn7A36SQTD
 QuI=
X-SBRS: 2.7
X-MesageID: 15764217
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,337,1580792400"; d="scan'208";a="15764217"
Subject: Re: [PATCH 5/5] x86/p2m: use available local variable in
 guest_physmap_add_entry()
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
 <3a8a7eb3-4822-0234-47de-c83973b4b5eb@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <e4cc2f64-7b08-01a3-8900-6ba5b3aaa0a6@citrix.com>
Date: Thu, 2 Apr 2020 23:47:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <3a8a7eb3-4822-0234-47de-c83973b4b5eb@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 01/04/2020 12:40, Jan Beulich wrote:
> The domain is being passed in - no need to obtain it from p2m->domain.
> Also drop a pointless cast while touching this code anyway.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -905,7 +905,7 @@ guest_physmap_add_entry(struct domain *d
>          if ( p2m_is_shared(ot) )
>          {
>              /* Do an unshare to cleanly take care of all corner cases. */
> -            rc = mem_sharing_unshare_page(p2m->domain, gfn_x(gfn_add(gfn, i)));
> +            rc = mem_sharing_unshare_page(d, gfn_x(gfn_add(gfn, i)));

Same as patch 3.  I'd recommend "gfn_x(gfn) + i" in preference (seeing
as you're cleaning up this line anyway).

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> seeing as you didn't
introduce it, but preferably with it changed.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 23:12:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 23:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK90X-0000VC-9j; Thu, 02 Apr 2020 23:12:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK90W-0000V7-OP
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 23:12:20 +0000
X-Inumbo-ID: 66367de8-7537-11ea-b4f4-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 66367de8-7537-11ea-b4f4-bc764e2007e4;
 Thu, 02 Apr 2020 23:12:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585869139;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=hl8Rx2B8raNOeE6heJ5022T5NWwKk/ZAVJM3cZm2ltQ=;
 b=P9piR1Kb3ZLzjCoD3Ocq8rh2nHIfxxhI49Q0t7lsY112bIsldrSIatFw
 Ke0pfa0e1qLBzOMjiIQ9bsNuPOxU6y4FT/T/NbBVyZMxmZTjCc3draqoT
 Tch8s/MdUOuG31qEohXQrErlASLk0Vfyw24t6XwXR1eRTjX9XS1xTDyaT w=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: MSKd7JIyOPM4daPb7iM0jWDVUgGZiAuiCC+bzleoUIGMSsHqYKjH+Qohnl4ToaAR7XqxbMGlC9
 JQFZBgLGq7s/Wes5dhyp9zgGWO0ZXDgrDIyPnF2w45cK0DYRLpF+STA99/XYr3iscce1rjRImV
 htpUfpf0cm/hGAFPmsP7RsKrTX0+dn4xIusTNb2TtDiITiFggRUelXVmGZNRXW+wWBNxsvRPNA
 1LOwW3sYPFhkjbs8eAIC0bXlOt+aaNZzGRHnF5BKQ8vcBynRJ8tU7pMM36b9il1tVR0cuANZe/
 yOs=
X-SBRS: 2.7
X-MesageID: 15426289
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,337,1580792400"; d="scan'208";a="15426289"
Subject: Re: [PATCH v5 05/10] x86emul: support MOVDIR64B insn
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <81e7aade-9dfb-313a-ad81-30b2703c2136@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <0a02ed6b-d7a0-7152-185f-a5bbc5491c49@citrix.com>
Date: Fri, 3 Apr 2020 00:12:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <81e7aade-9dfb-313a-ad81-30b2703c2136@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <Paul.Durrant@citrix.com>, Wei Liu <wl@xen.org>, Roger Pau
 Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24/03/2020 12:34, Jan Beulich wrote:
> Introduce a new blk() hook, paralleling the rmw() on in certain way, but
> being intended for larger data sizes, and hence its HVM intermediate
> handling function doesn't fall back to splitting the operation if the
> requested virtual address can't be mapped.
>
> Note that SDM revision 071 doesn't specify exception behavior for
> ModRM.mod == 0b11; assuming #UD here.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
> TBD: If we want to avoid depending on correct MTRR settings,
>      hvmemul_map_linear_addr() may need to gain a parameter to allow
>      controlling cachability of the produced mapping(s). Of course the
>      function will also need to be made capable of mapping at least
>      p2m_mmio_direct pages for this and the two ENQCMD insns to be
>      actually useful.

MOVDIR64B isn't the first instruction to demonstrate this corner case,
but we do need to organise something to solve this problem.  I'm
confident it will cause real memory corruption issue for encrypted
memory VMs under introspection.


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 23:39:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 23:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK9QW-0002Fs-KJ; Thu, 02 Apr 2020 23:39:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9JfQ=5S=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jK9QV-0002Fn-I1
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 23:39:11 +0000
X-Inumbo-ID: 265014ec-753b-11ea-bc79-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 265014ec-753b-11ea-bc79-12813bfff9fa;
 Thu, 02 Apr 2020 23:39:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=zBBeFo9lJQw6RQPgOhwz+K7RdAx3dVmfwjRWw/yfAgA=; b=DgHqo6OHv+xzn+uQaC2WRgGho
 yS6FJmyriUzf8K/qKGasgHHNkvm3EAFfxhSpmhXMK8BBbsNAlDcUQC88CsZ5NcwELjlDjDjidPcOM
 E7pw/u/7OdZyDZW4aAxUcP2UWBYGtb7ggyI0r6okL9os9g+lsEgdAPknMsQBjI+8hSyGs=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK9QT-0001w4-7X; Thu, 02 Apr 2020 23:39:09 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jK9QS-0002Dd-SI; Thu, 02 Apr 2020 23:39:09 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jK9QS-0001ve-Rc; Thu, 02 Apr 2020 23:39:08 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149325-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149325: all pass - PUSHED
X-Osstest-Versions-This: ovmf=4deef2d865efdc61d1a53ad7bd48f9dd42560b45
X-Osstest-Versions-That: ovmf=e210fc130e5c9738909dca432bbf8bf277ba6e37
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 02 Apr 2020 23:39:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 4deef2d865efdc61d1a53ad7bd48f9dd42560b45
baseline version:
 ovmf                 e210fc130e5c9738909dca432bbf8bf277ba6e37

Last test of basis   149292  2020-04-01 15:23:22 Z    1 days
Testing same since   149325  2020-04-02 09:40:07 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laszlo Ersek <lersek@redhat.com>
  Maciej Rabeda <maciej.rabeda@linux.intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   e210fc130e..4deef2d865  4deef2d865efdc61d1a53ad7bd48f9dd42560b45 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 02 23:47:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Apr 2020 23:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jK9YH-00037e-Ld; Thu, 02 Apr 2020 23:47:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8h32=5S=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jK9YF-00037Z-OR
 for xen-devel@lists.xenproject.org; Thu, 02 Apr 2020 23:47:11 +0000
X-Inumbo-ID: 44e09282-753c-11ea-83d8-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 44e09282-753c-11ea-83d8-bc764e2007e4;
 Thu, 02 Apr 2020 23:47:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585871231;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=tIJCcD60hixUMDA4iYurBTVCpXAqtfq76n5d3n8AVS4=;
 b=LNmA5ij/EJfc93yJvGNm5U+UVPNQAXifDtY+RVLzP8jA+r4q533++5j4
 0IMIP63ojdBTBQsfPKyTIHPVaO9VtG5A8J9Ag8D9VC3nKf91hnyPe/zsI
 2Yv7mxm9xOPG6ilz80fFcWl1CBxnYWmTVk67HBiCDzFTQS7tbibg7s4Y/ s=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: VBLuxwZmhHqQ48GhSWm8DPHyUnDqWIRm74A0b4UJfiQcNm6Qc4ji5PGBqPQtHuF2IrJlWz0Df1
 RKBzKP3xHWituBHMoB4RZH2cCRdAhJCK3glFQvhwpYcKbUn/efKZyp+HOCpMkkaCplK8T80Qxg
 nzq+YC8rbsjGJh70WDAt891UgyzUJem18N2INskp+nAakyloFwqhoZoSx+iPyRcLFf+U5GnjCl
 pMxKQrRQO1J1JyH51D4GsNTPKmJzJn9ZmeUPxfZ5rl/mquvKaPcBi9bJfbdtnl2heerLhaVN0P
 ayY=
X-SBRS: 2.7
X-MesageID: 15086492
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,337,1580792400"; d="scan'208";a="15086492"
Subject: Re: [PATCH v5 10/10] x86emul: support MCOMMIT
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <e41a2f72-ede5-adec-dc82-65b76368b7f7@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <574bab09-a29e-d77e-96e0-06e57ff524ee@citrix.com>
Date: Fri, 3 Apr 2020 00:47:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <e41a2f72-ede5-adec-dc82-65b76368b7f7@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24/03/2020 12:37, Jan Beulich wrote:
> The dependency on a new EFER bit implies that we need to set that bit
> ourselves in order to be able to successfully invoke the insn.
>
> Also once again introduce the SVM related constants at this occasion.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> RFC: The exact meaning of the PM stating "any errors encountered by
>      those stores have been signaled to associated error logging
>      resources" is unclear. Depending on what this entails, blindly
>      enabling EFER.MCOMMIT may not be a good idea. Hence the RFC.

Not just that.  Its not safe for Xen to ever execute MCOMMIT for
emulation purposes.

>From what I can glean from the documentation, it is intended for
non-volatile RAM, but I can't find anything discussing the error handling.

The fact the instruction can be intercepted in the first place hopefully
means that there must be something Xen can look at to get the real error
indicator.  However, the suggestion is that this will all be platform
specific.


The emulation problem comes from the fact that if Xen has any pending
writes to to NVRAM as part of the emulation path (or an interrupt for
that matter), an error intended for Xen would leak into guest context.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 01:48:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 01:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKBR2-0007Ph-2R; Fri, 03 Apr 2020 01:47:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=UfN3=5T=gmail.com=kevin.buckley.ecs.vuw.ac.nz@srs-us1.protection.inumbo.net>)
 id 1jKBR0-0007Pc-O2
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 01:47:50 +0000
X-Inumbo-ID: 1fef94f8-754d-11ea-9e09-bc764e2007e4
Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1fef94f8-754d-11ea-9e09-bc764e2007e4;
 Fri, 03 Apr 2020 01:47:50 +0000 (UTC)
Received: by mail-wr1-x442.google.com with SMTP id w10so6689474wrm.4
 for <xen-devel@lists.xenproject.org>; Thu, 02 Apr 2020 18:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=6aoVSyUZLXwsf2dSweMcvRNMge3YBSJSwb0zg4UAVwQ=;
 b=oNdFJwdicCNuZNwh9rhP2SBBg07jdDfnoygEX3kl2OSxelUUHNbJdduvvPBqu5sUVp
 zg5p6yN63Gs8kEHXjgYHfOc8tFCePOhEnZ+WQsWtJc1axPNZV9fvlr/7QwQwp2PBoHJz
 KbvgRJ11EEgVRm2PMbvX2jipHhYhjy0NI6r16gXsIeEq8i3lZTix3suK2S0jJ6jPKeT8
 PozSOUebikCupXh9bAuro5JcMJbd06ClndOf68InFjlvAcgAd+sVgK6LAfDm0DOVPD+z
 86nLQ5AL/GwMx4zACgmyAwIPtszKUxQCl5CNsMCnIkZdTDCVciTvkxbD/9nGiswK2DAa
 Lekg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=6aoVSyUZLXwsf2dSweMcvRNMge3YBSJSwb0zg4UAVwQ=;
 b=mM1rOe8/d4ZwFAKx+jssg/JKhFK4FB6u/KJWaKV4jYt0K/g2EUEvcNiZeiJpath6Df
 ywdLwozMm6eXjFKUOBzCIoIpY6SLpyaLyYKIhiyNoTst/b3l/mql6RIX7MFd6CLQSYj2
 CRb2zj1URHRAiZYC1FEA45YwIT0P3NqicGwoikfhQXq5OatYbrhuMh7P8RC3N896dSnr
 TfwzHSiJv5bRJSDUQs6knFKnmLDM2J9Ot0uRFLygChME+a/GKcP/6Cg3WPBVokIz45Gw
 DlkQnKq9Nj12zT6Ha0h3Sot2X7zWLW+AsAWaVzPSlVxGaJelGEkdc14n3zRCWHSdYkYJ
 mL4Q==
X-Gm-Message-State: AGi0PubbeWs9yUY9BpBEwn6KVV8n0QF/6UTJYBC0o/OPbSj4/zkHzkpT
 Zp4kcWLqKDkCpEFgKD41w37mLRbdKphjiHuzXG4=
X-Google-Smtp-Source: APiQypLucwvVEcRZHLQNdVYxG4vCR9gkJToadmkizyV5SdDXp4KB63Qy2EvoDiovsZ9wg0GiV0J0VOVUqxXPW8Jd/xE=
X-Received: by 2002:adf:e70f:: with SMTP id c15mr6665995wrm.217.1585878469375; 
 Thu, 02 Apr 2020 18:47:49 -0700 (PDT)
MIME-Version: 1.0
References: <CABwOO=doPdSR1PUPLU-X2R6akDGRgBoqMv_wK_sPpkh9jF6kCQ@mail.gmail.com>
 <49bb60b5-d64b-393c-bdd2-a4024e695e6e@citrix.com>
In-Reply-To: <49bb60b5-d64b-393c-bdd2-a4024e695e6e@citrix.com>
From: Kevin Buckley <kevin.buckley.ecs.vuw.ac.nz@gmail.com>
Date: Fri, 3 Apr 2020 09:47:37 +0800
Message-ID: <CABwOO=cJqNtWwtoNZwT0NzRDMUxgX5ti_o52AMYhjEXtbj82TQ@mail.gmail.com>
Subject: Re: 4.13: import xen.lowlevel.xc fails with SystemError: bad call
 flags
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, 2 Apr 2020 at 20:56, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> We've got a fix in staging
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e19b4b3b55f84e0cfcc02fe5d66965969a81c965
>
> It hasn't been backported to the 4.13 stable tree yet.
>
> ~Andrew

Bingo!

I guess I must have missed that when scanning the [PATCH ] subject lines

Applied and seen to fix the issue for me

Many thanks,
Kevin


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 05:27:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 05:27:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKErR-0000FR-QT; Fri, 03 Apr 2020 05:27:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=i4CN=5T=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKErQ-0000Eu-Sl
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 05:27:20 +0000
X-Inumbo-ID: c67c3b32-756b-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c67c3b32-756b-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 05:27:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=SvdT182Ptzw54mJaAp0QHLxarNYbl2pKu8UBL4UQTno=; b=LGHTGmkalcbI2/rFj6q5mIr9t
 OvyRw/wwhFloOJCCOHTrtA2IlUyM58cmBoeeNdDG6dB58/QpNctpqt/qTKyqkA9p+W/FoeaSTsQOd
 GxB6GTnVWNQ3+Vc8KX/jcz5OQHtwDEIp0mqv6Xpdjv5T8FiFMFA6j70VppCDeRgjJAPFw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKErJ-00062c-Pi; Fri, 03 Apr 2020 05:27:13 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKErJ-0002PD-EV; Fri, 03 Apr 2020 05:27:13 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKErJ-00014M-Dr; Fri, 03 Apr 2020 05:27:13 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149335-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149335: regressions - FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:regression
 xen-unstable:build-amd64-xsm:xen-build:fail:regression
 xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-dom0pvh-xl-amd:guest-start/debian.repeat:fail:nonblocking
X-Osstest-Versions-This: xen=4de936a38aa96c946f5d39b2760abb8a9853cba3
X-Osstest-Versions-That: xen=e19b4b3b55f84e0cfcc02fe5d66965969a81c965
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 03 Apr 2020 05:27:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail REGR. vs. 149188
 build-amd64-xsm               6 xen-build                fail REGR. vs. 149188

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)     blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)      blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-xsm        1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-xsm       1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  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-xl-qemut-debianhvm-i386-xsm  1 build-check(1)     blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149151
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149188
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 149188
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149188
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149188
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-amd64-amd64-dom0pvh-xl-amd 20 guest-start/debian.repeat fail starved in 149188

version targeted for testing:
 xen                  4de936a38aa96c946f5d39b2760abb8a9853cba3
baseline version:
 xen                  e19b4b3b55f84e0cfcc02fe5d66965969a81c965

Last test of basis   149188  2020-03-30 01:51:23 Z    4 days
Failing since        149231  2020-03-31 02:00:20 Z    3 days    4 attempts
Testing same since   149335  2020-04-02 12:59:35 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jason Andryuk <jandryuk@gmail.com>
  Julien Grall <jgrall@amazon.com>
  Julien Grall <julien.grall@arm.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Simran Singhal <singhalsimran0@gmail.com>
  Stefano Stabellini <sstabellini@kernel.org>

jobs:
 build-amd64-xsm                                              fail    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        blocked 
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         blocked 
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 blocked 
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 blocked 
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  blocked 
 test-amd64-amd64-libvirt-xsm                                 blocked 
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  blocked 
 test-amd64-amd64-xl-xsm                                      blocked 
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       blocked 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 07:32:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 07:32:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKGoc-00024H-M0; Fri, 03 Apr 2020 07:32:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKGob-00024A-B4
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 07:32:33 +0000
X-Inumbo-ID: 473f748a-757d-11ea-bcc0-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 473f748a-757d-11ea-bcc0-12813bfff9fa;
 Fri, 03 Apr 2020 07:32:32 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8E40AAFA1;
 Fri,  3 Apr 2020 07:32:30 +0000 (UTC)
Subject: Re: [PATCH 4/4] x86/APIC: restrict certain messages to BSP
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <60130f14-3fc5-e40d-fec6-2448fefa6fc4@suse.com>
 <513e4f93-a8a0-ae72-abcc-aa28531eca97@suse.com>
 <76e02143-474f-54c1-bba3-5c5973d7751a@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <180550ef-e2be-c8a6-f663-36747bccfbf2@suse.com>
Date: Fri, 3 Apr 2020 09:32:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <76e02143-474f-54c1-bba3-5c5973d7751a@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 19:55, Andrew Cooper wrote:
> On 13/03/2020 09:26, Jan Beulich wrote:
>> All CPUs get an equal setting of EOI broadcast suppression; no need to
>> log one message per CPU, even if it's only in verbose APIC mode.
>>
>> Only the BSP is eligible to possibly get ExtINT enabled; no need to log
>> that it gets disabled on all APs, even if - again - it's only in verbose
>> APIC mode.
>>
>> Take the opportunity and introduce a "bsp" parameter to the function, to
>> stop using smp_processor_id() to tell BSP from APs.
> 
> On further consideration, this is introducing a latent bug.
> 
> In a theoretical world where we could take the BSP offline, it is still
> the CPU with the ID 0 which needs various of these things setting back up.

No. If we took the BSP offline, no CPU with ID 0 would remain
(until such time that the ID would be re-used).

> You could argue that we could move ExtINT/NMI handling to a different
> CPU, and in this case, BSP still isn't the right distinction.  We'd want
> something to signify "the processor which is the target of legacy
> interrupts", as in such a case, it would specifically no longer be the
> CPU we booted on.

I see nothing wrong with calling this new "focus" processor the
BSP again. Post boot the significance of BSP, afaict, reduces
to aspects that aren't really tied to having been the processor
to lead bootup.

The important point is - if we were to allow offlining the BSP,
whichever other one would take its position would _not_ come
through setup_local_APIC(). The adjustments needs would need
doing by other means (quite likely by splitting out some of the
code into a new helper). Hence in setup_local_APIC() itself the
BSP / non-BSP distinction is correct.

> OTOH, the adjustment for the NMI watchdog does look to be different. 
> AFAICT, that is for deferring the watchdog setup until later in boot, at
> which point "the BSP" is the appropriate distinction to use.  (That said
> - I'm not sure why anything should need delaying.  I suspect this is
> misplaced code to begin with.)

Well, in any event - an unrelated aspect, and I think the switch
from smp_processor_id() to bsp is correct there as well.

> As for the messages being printed, I think that is fine to restrict to
> the BSP.

As per above I understand this isn't an ack for the patch. However,
I then don't understand what concrete changes you mean me to make
for it to stand a chance of getting your ack.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 07:43:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 07:43:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKGzH-0002xE-Pl; Fri, 03 Apr 2020 07:43:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKGzG-0002wh-Eo
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 07:43:34 +0000
X-Inumbo-ID: d18f3214-757e-11ea-bcc1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d18f3214-757e-11ea-bcc1-12813bfff9fa;
 Fri, 03 Apr 2020 07:43:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3C3FBADCC;
 Fri,  3 Apr 2020 07:43:32 +0000 (UTC)
Subject: Re: [PATCH] x86/HVM: expose VM assist hypercall
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <cb4a6f8f-eda8-f17c-54e5-af1353d6358c@suse.com>
 <18adfe82-4882-c835-cd1d-b3069416e0ab@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e1837d16-53e1-b382-3c63-c9c60ef26829@suse.com>
Date: Fri, 3 Apr 2020 09:43:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <18adfe82-4882-c835-cd1d-b3069416e0ab@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 21:49, Andrew Cooper wrote:
> On 02/04/2020 08:46, Jan Beulich wrote:
>> In preparation for the addition of VMASST_TYPE_runstate_update_flag
>> commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
>> the hypercall for Arm. I consider it not logical that it then isn't also
>> exposed to x86 HVM guests (with the same single feature permitted to be
>> enabled as Arm has); Linux actually tries to use it afaict.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> I'd declare this a bug in 2529c850ea4.  It was clearly intended as a
> common feature, and wasn't tested for HVM guests.
> 
> However, ...
> 
>>
>> --- a/xen/arch/x86/hvm/hypercall.c
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -78,6 +78,11 @@ static long hvm_grant_table_op(
>>  }
>>  #endif
>>  
>> +static long hvm_vm_assist(unsigned int cmd, unsigned int type)
>> +{
>> +    return vm_assist(current->domain, cmd, type, HVM_VM_ASSIST_VALID);
>> +}
>> +
>>  static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>  {
>>      const struct vcpu *curr = current;
>> @@ -128,6 +133,7 @@ static const hypercall_table_t hvm_hyper
>>  #ifdef CONFIG_GRANT_TABLE
>>      HVM_CALL(grant_table_op),
>>  #endif
>> +    HVM_CALL(vm_assist),
> 
> ... this means we've now got 3 stub functions making no-op ABI changes
> for the general vm_assist() function.

Not sure what you mean with "no-op" here. It's not like the
mask values would all be the same.

> Renaming it to do_vm_assist(), latch current->domain internally, and an
> arch_vm_assist_valid(d) helper can cover the final parameter.

I can certainly do this, but it very much seems to me to be a
request you'd call "scope creep". I was meaning to address the
issue at hand with a minimally invasive change. The bigger
variant you suggest is unlikely to cause backporting issues,
yes, but still ... Anyway, I'll do as you ask, to cut the
discussion short.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 07:52:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 07:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKH7y-0003nE-Mi; Fri, 03 Apr 2020 07:52:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKH7x-0003n9-Eg
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 07:52:33 +0000
X-Inumbo-ID: 127ced57-7580-11ea-bcc1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 127ced57-7580-11ea-bcc1-12813bfff9fa;
 Fri, 03 Apr 2020 07:52:32 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7C2D0AC2C;
 Fri,  3 Apr 2020 07:52:30 +0000 (UTC)
Subject: Re: [PATCH 5/5] x86emul: disable FPU/MMX/SIMD insn emulation when !HVM
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <7f7a6ba3-7308-b079-2df1-f5b8501b3cc6@suse.com>
 <87154c20-c60e-a215-f7f4-0290fadd90e4@suse.com>
 <dbc03c9d-bfc2-3313-1ffe-8ffe79b2c1e1@citrix.com>
 <a016ba7f-f860-9372-caab-d9400c064fd9@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8799ecd8-c27e-2d01-b236-dfa0aedefa14@suse.com>
Date: Fri, 3 Apr 2020 09:52:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <a016ba7f-f860-9372-caab-d9400c064fd9@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 00:18, Andrew Cooper wrote:
> On 20/12/2019 16:01, Andrew Cooper wrote:
>>> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> I'll be happy to take suggestions allowing to avoid -Wno-unused-label.
>> I think I'm going to need a little while to figure out how this works.
> 
> So, after having had an evening playing with this, things get massively
> simpler when NO_MMX is folded with NO_SIMD.
> 
> MMX is a SIMD technology, and I can't see a compelling reason to control
> their inclusion separately.  We're either going to want everything or
> nothing.

I disagree - while MMX is a form of SIMD, what SIMD here means is
anything using the XMM register file and its extensions. Iirc
AMD once considered dropping MMX, and if I'm not mistaken early
Phi's didn't support MMX nor FPU. Hence I view a mode not
allowing MMX but allowing SIMD as a viable one to support.

> The attached incremental works for me without a single out-of-place
> label.  There is some further cleanup which can be done such as not
> making the CASE_ macros conditional.

Well, if we were to follow your alternative model - perhaps.
What I dislike though is something like the last hunk (an #ifdef
around a construct which can already abstract away things, and
which is specifically intended to avoid some #ifdef-ary).

>  (OTOH, the compile error from
> might be helpful to keep in some form).

There looks to be a word missing here, which puts me into trouble
understanding what you mean.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 07:57:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 07:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKHD2-0003xx-9s; Fri, 03 Apr 2020 07:57:48 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKHD1-0003xs-AE
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 07:57:47 +0000
X-Inumbo-ID: cd61b9a8-7580-11ea-bcc1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cd61b9a8-7580-11ea-bcc1-12813bfff9fa;
 Fri, 03 Apr 2020 07:57:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 03C40AC2C;
 Fri,  3 Apr 2020 07:57:43 +0000 (UTC)
Subject: Re: [PATCH v5 05/10] x86emul: support MOVDIR64B insn
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <81e7aade-9dfb-313a-ad81-30b2703c2136@suse.com>
 <0a02ed6b-d7a0-7152-185f-a5bbc5491c49@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <18ef0337-d6c7-3b60-aa2e-a83930cc0902@suse.com>
Date: Fri, 3 Apr 2020 09:57:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <0a02ed6b-d7a0-7152-185f-a5bbc5491c49@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Paul Durrant <Paul.Durrant@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 01:12, Andrew Cooper wrote:
> On 24/03/2020 12:34, Jan Beulich wrote:
>> Introduce a new blk() hook, paralleling the rmw() on in certain way, but
>> being intended for larger data sizes, and hence its HVM intermediate
>> handling function doesn't fall back to splitting the operation if the
>> requested virtual address can't be mapped.
>>
>> Note that SDM revision 071 doesn't specify exception behavior for
>> ModRM.mod == 0b11; assuming #UD here.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks much, but I'm puzzled by you providing this, and hence
would like to double check: You specifically asked that I take
care of the cachability issue for MOVDIRI before you would ack
that change. How come you're not similarly concerned here?

>> ---
>> TBD: If we want to avoid depending on correct MTRR settings,
>>      hvmemul_map_linear_addr() may need to gain a parameter to allow
>>      controlling cachability of the produced mapping(s). Of course the
>>      function will also need to be made capable of mapping at least
>>      p2m_mmio_direct pages for this and the two ENQCMD insns to be
>>      actually useful.
> 
> MOVDIR64B isn't the first instruction to demonstrate this corner case,
> but we do need to organise something to solve this problem.  I'm
> confident it will cause real memory corruption issue for encrypted
> memory VMs under introspection.

Besides the named ones and MOVDIRI, which other ones are you
talking about?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 08:00:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 08:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKHFY-0005Eu-77; Fri, 03 Apr 2020 08:00:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKHFW-0005Ep-VH
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 08:00:22 +0000
X-Inumbo-ID: 2abe0b10-7581-11ea-bcc1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2abe0b10-7581-11ea-bcc1-12813bfff9fa;
 Fri, 03 Apr 2020 08:00:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D7702AE83;
 Fri,  3 Apr 2020 08:00:20 +0000 (UTC)
Subject: Re: [PATCH v5 10/10] x86emul: support MCOMMIT
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <e41a2f72-ede5-adec-dc82-65b76368b7f7@suse.com>
 <574bab09-a29e-d77e-96e0-06e57ff524ee@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <71d182e8-983c-9fa6-3403-ee3212c70c50@suse.com>
Date: Fri, 3 Apr 2020 10:00:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <574bab09-a29e-d77e-96e0-06e57ff524ee@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 01:47, Andrew Cooper wrote:
> On 24/03/2020 12:37, Jan Beulich wrote:
>> The dependency on a new EFER bit implies that we need to set that bit
>> ourselves in order to be able to successfully invoke the insn.
>>
>> Also once again introduce the SVM related constants at this occasion.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> RFC: The exact meaning of the PM stating "any errors encountered by
>>      those stores have been signaled to associated error logging
>>      resources" is unclear. Depending on what this entails, blindly
>>      enabling EFER.MCOMMIT may not be a good idea. Hence the RFC.
> 
> Not just that.  Its not safe for Xen to ever execute MCOMMIT for
> emulation purposes.

I.e. you're suggesting we mustn't even try to emulate it?

> From what I can glean from the documentation, it is intended for
> non-volatile RAM, but I can't find anything discussing the error handling.
> 
> The fact the instruction can be intercepted in the first place hopefully
> means that there must be something Xen can look at to get the real error
> indicator.  However, the suggestion is that this will all be platform
> specific.
> 
> 
> The emulation problem comes from the fact that if Xen has any pending
> writes to to NVRAM as part of the emulation path (or an interrupt for
> that matter), an error intended for Xen would leak into guest context.

I'm afraid all of this is guesswork until it becomes clear how
exactly this error reporting is intended to work.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 08:06:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 08:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKHLS-0005Q5-Ty; Fri, 03 Apr 2020 08:06:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKHLS-0005Q0-1G
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 08:06:30 +0000
X-Inumbo-ID: 051daaf4-7582-11ea-bcc1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 051daaf4-7582-11ea-bcc1-12813bfff9fa;
 Fri, 03 Apr 2020 08:06:28 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3A14BAC2C;
 Fri,  3 Apr 2020 08:06:27 +0000 (UTC)
Subject: Re: [PATCH v2 0/2] x86/cpuidle: Cannon Lake adjustments
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <e39d4326-57d1-a4b5-3081-76b5160644ae@suse.com>
 <afe81b7e-4895-89ee-49dd-b6c0130923a1@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8813266d-cb33-0bb7-16d1-d1bf54142d2b@suse.com>
Date: Fri, 3 Apr 2020 10:06:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <afe81b7e-4895-89ee-49dd-b6c0130923a1@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 16:58, Andrew Cooper wrote:
> On 02/04/2020 09:22, Jan Beulich wrote:
>> As requested in reply to v1, this is now a pair of patches with
>> the expectation that only patch 1 would be acked and go in.
>>
>> 1: drop Cannon Lake support
>> 2: support Cannon Lake (again)
> 
> Dropping Cannon Lake support is only of any incremental benefit if we
> drop it from everywhere, and I didn't mean to block this single patch on it.

How would dropping it from everywhere in one go be any better?
I would see a benefit then only if we added code to refuse
booting there.

> Consider either A-by.

I'm sorry to ask, but "either" here is unclear to me: Do you
mean both of the above, or "the first one here or the original
v1 one"? I don't see a point committing this in two pieces, if
the combination of both is fine by you as well.

> However, it would be helpful to consider what we could do for better
> KCONFIG-able CPU support.

Yes, sure. Future work.

> Some downstreams have a separate build for each platform, and some go as
> far as cramming Xen into the boot SPI ROM, so space saving is a very
> important aspect.

Yes.

> On a different front, being able to compile out support for CPUs without
> VMX unrestricted mode, or without CMPXCHG16B would be helpful.

Yes.

> I would certainly like to get CONFIG_{INTEL,AMD} usable even if only so
> randconfig can help keep our interfaces clean.

And yes again.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 08:15:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 08:15:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKHU0-0006Gc-Rb; Fri, 03 Apr 2020 08:15:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKHTy-0006GX-Vj
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 08:15:18 +0000
X-Inumbo-ID: 40bf3c8e-7583-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 40bf3c8e-7583-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 08:15:18 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BA4E1AC1D;
 Fri,  3 Apr 2020 08:15:16 +0000 (UTC)
Subject: Re: [PATCH v2] x86/PV: remove unnecessary toggle_guest_pt() overhead
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <47cf43bb-9643-011f-45c2-7cb63c422c3f@suse.com>
 <61b00d2c-f862-2500-d958-7ff8e8823409@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6188a128-ac6e-8e89-a3d5-75caea8cf753@suse.com>
Date: Fri, 3 Apr 2020 10:15:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <61b00d2c-f862-2500-d958-7ff8e8823409@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 21:27, Andrew Cooper wrote:
> On 20/12/2019 14:06, Jan Beulich wrote:
>> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
>> expensive (but still needed only for the toggle_guest_mode() path), the
>> effect of the latter on the exit-to-guest path is not insignificant.
>> Move the logic into toggle_guest_mode(), on the basis that
>> toggle_guest_pt() will always be invoked in pairs, yet we can't safely
>> undo the setting of root_pgt_changed during the second of these
>> invocations.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Ohhhhh.
> 
> I think this is the first time I've actually understood the "overhead"
> you're talking about here, but honestly, I still had to work very hard
> to figure it out.
> 
> If I were writing the commit message, it would be something like this:
> 
> Logic such as guest_io_okay() and guest_get_eff_kern_l1e() calls
> toggle_guest_pt() in pairs to pull a value out of guest kernel memory,
> then return to the previous pagetable context.
> 
> This is transparent and doesn't modify the pagetables, so there is no
> need to undergo an expensive resync on the return-to-guest path
> triggered by setting cpu_info->root_pgt_changed.
> 
> Move the logic from _toggle_guest_pt() to toggle_guest_mode(), which is
> intending to return to guest context in a different pagetable context.

Well, I think all of what you say is also being said by my variant,
just in a different way. I'd prefer to stick to my version, but I
could live with using yours if this helps finally getting this in.

>> --- a/xen/arch/x86/pv/domain.c
>> +++ b/xen/arch/x86/pv/domain.c
>> @@ -365,18 +365,10 @@ bool __init xpti_pcid_enabled(void)
>>  
>>  static void _toggle_guest_pt(struct vcpu *v)
>>  {
>> -    const struct domain *d = v->domain;
>> -    struct cpu_info *cpu_info = get_cpu_info();
>>      unsigned long cr3;
>>  
>>      v->arch.flags ^= TF_kernel_mode;
>>      update_cr3(v);
>> -    if ( d->arch.pv.xpti )
>> -    {
>> -        cpu_info->root_pgt_changed = true;
>> -        cpu_info->pv_cr3 = __pa(this_cpu(root_pgt)) |
>> -                           (d->arch.pv.pcid ? get_pcid_bits(v, true) : 0);
>> -    }
>>  
>>      /*
>>       * Don't flush user global mappings from the TLB. Don't tick TLB clock.
>> @@ -384,15 +376,11 @@ static void _toggle_guest_pt(struct vcpu
>>       * In shadow mode, though, update_cr3() may need to be accompanied by a
>>       * TLB flush (for just the incoming PCID), as the top level page table may
>>       * have changed behind our backs. To be on the safe side, suppress the
>> -     * no-flush unconditionally in this case. The XPTI CR3 write, if enabled,
>> -     * will then need to be a flushing one too.
>> +     * no-flush unconditionally in this case.
>>       */
>>      cr3 = v->arch.cr3;
>> -    if ( shadow_mode_enabled(d) )
>> -    {
>> +    if ( shadow_mode_enabled(v->domain) )
>>          cr3 &= ~X86_CR3_NOFLUSH;
>> -        cpu_info->pv_cr3 &= ~X86_CR3_NOFLUSH;
>> -    }
>>      write_cr3(cr3);
>>  
>>      if ( !(v->arch.flags & TF_kernel_mode) )
>> @@ -408,6 +396,8 @@ static void _toggle_guest_pt(struct vcpu
>>  
>>  void toggle_guest_mode(struct vcpu *v)
>>  {
>> +    const struct domain *d = v->domain;
>> +
>>      ASSERT(!is_pv_32bit_vcpu(v));
>>  
>>      /* %fs/%gs bases can only be stale if WR{FS,GS}BASE are usable. */
>> @@ -421,6 +411,21 @@ void toggle_guest_mode(struct vcpu *v)
>>      asm volatile ( "swapgs" );
>>  
>>      _toggle_guest_pt(v);
>> +
>> +    if ( d->arch.pv.xpti )
>> +    {
>> +        struct cpu_info *cpu_info = get_cpu_info();
>> +
>> +        cpu_info->root_pgt_changed = true;
>> +        cpu_info->pv_cr3 = __pa(this_cpu(root_pgt)) |
>> +                           (d->arch.pv.pcid ? get_pcid_bits(v, true) : 0);
>> +        /*
>> +         * As in _toggle_guest_pt() the XPTI CR3 write needs to be a TLB-
>> +         * flushing one too for shadow mode guests.
>> +         */
>> +        if ( shadow_mode_enabled(d) )
>> +            cpu_info->pv_cr3 &= ~X86_CR3_NOFLUSH;
>> +    }
>>  }
>>  
> 
> I think this wants a note for anyone trying to follow the logic.
> 
> /* Must be called in matching pairs without returning to guest context
> inbetween. */
> 
>>  void toggle_guest_pt(struct vcpu *v)

Despite your comment being ahead of it, I understand you mean
it to apply to this line? I'm certainly fine to add this comment,
but it's unrelated to the change at hand - the requirement has
been there before afaict.

> If the callers were more complicated than they are, or we might credibly
> gain more users, I would suggest it would be worth trying to assert the
> "called in pairs" aspect.
> 
> However, I can't think of any trivial way to check this, and I don't
> think it is worth a complicated check.

Indeed I've been trying to think of some reasonable way of doing
so years ago.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 08:22:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 08:22:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKHai-000782-Oi; Fri, 03 Apr 2020 08:22:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKHai-00077v-9u
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 08:22:16 +0000
X-Inumbo-ID: 38effdb3-7584-11ea-bcc7-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 38effdb3-7584-11ea-bcc7-12813bfff9fa;
 Fri, 03 Apr 2020 08:22:14 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1D98EAEAA;
 Fri,  3 Apr 2020 08:22:13 +0000 (UTC)
Subject: Re: [PATCH 3/5] x86/p2m: make p2m_remove_page()'s parameters type-safe
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
 <858f22e3-0f4f-08f0-ef67-b8ce67146537@suse.com>
 <ae425c2f-0297-4944-5bd5-03ccdab8fdce@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <b282f3a8-dd97-8b5b-81ad-0b3673d3621a@suse.com>
Date: Fri, 3 Apr 2020 10:22:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <ae425c2f-0297-4944-5bd5-03ccdab8fdce@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 00:43, Andrew Cooper wrote:
> On 01/04/2020 12:39, Jan Beulich wrote:
>> @@ -790,21 +789,23 @@ p2m_remove_page(struct p2m_domain *p2m,
>>                                            &cur_order, NULL);
>>  
>>          if ( p2m_is_valid(t) &&
>> -             (!mfn_valid(_mfn(mfn)) || mfn + i != mfn_x(mfn_return)) )
>> +             (!mfn_valid(mfn) || !mfn_eq(mfn_add(mfn, i), mfn_return)) )
>>              return -EILSEQ;
>>  
>> -        i += (1UL << cur_order) - ((gfn_l + i) & ((1UL << cur_order) - 1));
>> +        i += (1UL << cur_order) -
>> +             (gfn_x(gfn_add(gfn, i)) & ((1UL << cur_order) - 1));
> 
> We're gaining an number of expressions starting to look like this, but
> honestly, "gfn_x(gfn) + i" is equally typesafe, shorter, and easier to
> read IMO.

Good point - in recent reviews I've commented to the same effect
on patches from Julien. This patch is way too old for me to have
recalled that I did like this here, too. Will switch (also
elsewhere in case I find more that I introduce).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 08:38:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 08:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKHqe-00085R-21; Fri, 03 Apr 2020 08:38:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKHqd-00085M-7B
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 08:38:43 +0000
X-Inumbo-ID: 84b8fc89-7586-11ea-bccd-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 84b8fc89-7586-11ea-bccd-12813bfff9fa;
 Fri, 03 Apr 2020 08:38:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 90C4FAD03;
 Fri,  3 Apr 2020 08:38:39 +0000 (UTC)
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: paul@xen.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <e9b21d59-3a4a-1498-e5f4-45d1420ddbc4@suse.com>
 <001201d608d5$513a7490$f3af5db0$@xen.org>
 <fc7ffa50-5648-f335-02a4-1819d826c193@suse.com>
 <001601d608f7$0d6c1620$28444260$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8b7e9973-0151-088f-de4b-91f450e7e4c7@suse.com>
Date: Fri, 3 Apr 2020 10:38:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <001601d608f7$0d6c1620$28444260$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 16:00, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 02 April 2020 12:08
>>
>> Considering the situation with event channels (all closed), doing
>> what you do for the shared info page is probably going to be fine;
>> large parts of it are in a known state (or need re-filling on the
>> destination) anyway. What other plans do you have for non-LU
>> migration wrt this new infrastructure?
> 
> Well, as discussed above, event channels are one, then there's the grant table. The downstream code as a record for the wallclock but I think the RTC covers that now that added the code to preserve the offset. We also have records for vcpu timers and runstate, but I'm not convinced we actually need those.

Timers may need preserving, but runstate may be avoidable. Depends
on whether the accumulation in time[4] is fine to start from zero
again after (transparent) migration.

>> If the shared info page is
>> all that's going to get migrated with its help, I'd wonder whether
>> the infrastructure wasn't better conditional upon a LU config
>> option, and the shared info migration was left as it is now.
> 
> The shared info is also migrated for HVM guests so it would have meant moving the mapping code around anyway, thus it seems sensible to use the new domain context for that for PV guests in their normal migration stream anyway.

Hmm, okay - I'll see to get to look at the actual code then.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 08:56:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 08:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKI7q-0001GC-QJ; Fri, 03 Apr 2020 08:56:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=DpjN=5T=kernel.org=maz@srs-us1.protection.inumbo.net>)
 id 1jKHym-0000W1-Cq
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 08:47:08 +0000
X-Inumbo-ID: b333f788-7587-11ea-b4f4-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b333f788-7587-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 08:47:07 +0000 (UTC)
Received: from disco-boy.misterjones.org (disco-boy.misterjones.org
 [51.254.78.96])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 0F0D2206E9;
 Fri,  3 Apr 2020 08:47:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1585903627;
 bh=2PhW1qDopiRvO+gz50VePvN+omC3zgLGQ6Up99cw8nk=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=ZCUaq8JHUwyGZnKgKgSoNM9lxn3yTGBjb615H8/5erNU2Ry3onT9cCs4E+F9qv25S
 re2nAvb/qfV7z9FyqbOyobIestDARMcxCMLsSCqtFQLVOnca/JyxYYgq1iJXz6LgYK
 T3eCeh5QoCIX5rQAbyJvg9MydcEQvce8bsbQiyQk=
Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr)
 by disco-boy.misterjones.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from <maz@kernel.org>)
 id 1jKHyj-000Rb4-3P; Fri, 03 Apr 2020 09:47:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 03 Apr 2020 09:47:05 +0100
From: Marc Zyngier <maz@kernel.org>
To: Julien Grall <julien@xen.org>, Stefano Stabellini
 <stefano.stabellini@xilinx.com>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
In-Reply-To: <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
Message-ID: <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
X-Sender: maz@kernel.org
User-Agent: Roundcube Webmail/1.3.10
X-SA-Exim-Connect-IP: 51.254.78.96
X-SA-Exim-Rcpt-To: julien@xen.org, stefano.stabellini@xilinx.com,
 sstabellini@kernel.org, xen-devel@lists.xenproject.org, xuwei5@hisilicon.com,
 peng.fan@nxp.com, George.Dunlap@citrix.com, Bertrand.Marquis@arm.com
X-SA-Exim-Mail-From: maz@kernel.org
X-SA-Exim-Scanned: No (on disco-boy.misterjones.org);
 SAEximRunCond expanded to false
X-Mailman-Approved-At: Fri, 03 Apr 2020 08:56:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 George.Dunlap@citrix.com, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 2020-04-02 19:52, Julien Grall wrote:
> (+Marc)

Thanks for looping me in. Definitely an interesting read, but also a 
very
puzzling one.

> 
> Hi Stefano,
> 
> On 02/04/2020 18:19, Stefano Stabellini wrote:
>> On Wed, 1 Apr 2020, Julien Grall wrote:
>>> On 01/04/2020 01:57, Stefano Stabellini wrote:
>>>> On Mon, 30 Mar 2020, Julien Grall wrote:
>>>>> Hi Stefano,
>>>>> 
>>>>> On 30/03/2020 17:35, Stefano Stabellini wrote:
>>>>>> On Sat, 28 Mar 2020, Julien Grall wrote:
>>>>>>> qHi Stefano,
>>>>>>> 
>>>>>>> On 27/03/2020 02:34, Stefano Stabellini wrote:
>>>>>>>> This is a simple implementation of GICD_ICACTIVER / 
>>>>>>>> GICD_ISACTIVER
>>>>>>>> reads. It doesn't take into account the latest state of 
>>>>>>>> interrupts
>>>>>>>> on
>>>>>>>> other vCPUs. Only the current vCPU is up-to-date. A full 
>>>>>>>> solution is
>>>>>>>> not possible because it would require synchronization among all
>>>>>>>> vCPUs,
>>>>>>>> which would be very expensive in terms or latency.
>>>>>>> 
>>>>>>> Your sentence suggests you have number showing that correctly
>>>>>>> emulating
>>>>>>> the
>>>>>>> registers would be too slow. Mind sharing them?
>>>>>> 
>>>>>> No, I don't have any numbers. Would you prefer a different wording 
>>>>>> or a
>>>>>> better explanation? I also realized there is a typo in there 
>>>>>> (or/of).
>>>>> Let me start with I think correctness is more important than speed.
>>>>> So I would have expected your commit message to contain some fact 
>>>>> why
>>>>> synchronization is going to be slow and why this is a problem.
>>>>> 
>>>>> To give you a concrete example, the implementation of set/way 
>>>>> instructions
>>>>> are
>>>>> really slow (it could take a few seconds depending on the setup). 
>>>>> However,
>>>>> this was fine because not implementing them correctly would have a 
>>>>> greater
>>>>> impact on the guest (corruption) and they are not used often.
>>>>> 
>>>>> I don't think the performance in our case will be in same order 
>>>>> magnitude.
>>>>> It
>>>>> is most likely to be in the range of milliseconds (if not less) 
>>>>> which I
>>>>> think
>>>>> is acceptable for emulation (particularly for the vGIC) and the 
>>>>> current
>>>>> uses.
>>>> 
>>>> Writing on the mailing list some of our discussions today.
>>>> 
>>>> Correctness is not just in terms of compliance to a specification 
>>>> but it
>>>> is also about not breaking guests. Introducing latency in the range 
>>>> of
>>>> milliseconds, or hundreds of microseconds, would break any latency
>>>> sensitive workloads. We don't have numbers so we don't know for 
>>>> certain
>>>> the effect that your suggestion would have.
>>> 
>>> You missed part of the discussion. I don't disagree that latency is 
>>> important.
>>> However, if an implementation is only 95% reliable, then it means 5% 
>>> of the
>>> time your guest may break (corruption, crash, deadlock...). At which 
>>> point the
>>> latency is the last of your concern.
>> 
>> Yeah I missed to highlight it, also because I look at it from a 
>> slightly
>> different perspective: I think IRQ latency is part of correctness.

No. Low latency is a very desirable thing, but it doesn't matter at all 
when
you don't even have functional correctness. To use my favourite car 
analogy,
having a bigger engine doesn't help when you're about to hit the wall 
and
have no breaks... You just hit the wall faster.

>> 
>> If we have a solution that is not 100% faithful to the specification 
>> we
>> are going to break guests that rely on a faithful implementation of
>> ISACTIVER.
>> 
>> If we have a solution that is 100% faithful to the specification but
>> causes latency spikes it breaks RT guests.
>> 
>> But they are different sets of guests, it is not like one is 
>> necessarily
>> a subset of the other: there are guests that cannot tolerate any 
>> latency
>> spikes but they are OK with an imprecise implementation of ISACTIVER.

s/imprecise/massively incorrect/

>> 
>> My preference is a solution that is both spec-faithful and also 
>> doesn't
>> cause any latency spikes. If that is not possible then we'll have to
>> compromise or come up with "creative" ideas.

You want your cake and eat it. Always a good thing to want.

As long as you don't pretend you implement the GIC architecture, expose
something else altogether to the guests and have specific drivers in all
the guest operating systems under the sun, by all mean, be creative.

> I do agree that latency is important. However, this needs to be based
> on numbers or a good grasp as to why this would be an issue. Neither
> of these have been provided so far.
> 
> As we discussed on Tuesday, the cost for other vCPUs is only going to
> be a trap to the hypervisor and then back again. The cost is likely
> smaller than receiving and forwarding an interrupt.
> 
> You actually agreed on this analysis. So can you enlighten me as to
> why receiving an interrupt is a not problem for latency but this is?
> 
>> 
>>>> It would be interesting to have those numbers, and I'll add to my 
>>>> TODO
>>>> list to run the experiments you suggested, but I'll put it on the
>>>> back-burner (from a Xilinx perspective it is low priority as no
>>>> customers are affected.)
>>> 
>>> How about we get a correct implementation merge first and then 
>>> discuss about
>>> optimization? This would allow the community to check whether there 
>>> are
>>> actually noticeable latency in their workload.
>> 
>> A correct implementation to me means that it is correct from both the
>> specification point of view as well as from a latency point of view. A
>> patch that potentially introduces latency spikes could cause guest
>> breakage and I don't think it should be considered correct. The
>> tests would have to be done beforehand.

Please find anything that specifies latency in the GIC spec. Oh wait,
there is none. Because that's a quality of implementation thing, and
not a correctness issue.

> 
> In all honesty, writing and testing the implementation would have
> likely took you less than trying to push for "creative" ideas or your
> patch.
> 
>> In terms of other "creative" ideas, here are some:
> 
> "creative" ideas should really be the last resort. Correct me if I am
> wrong, but I don't think we are there yet.
> 
>> 
>> One idea, as George suggested, would be to document the interface
>> deviation. The intention is still to remove any deviation but at least
>> we would be clear about what we have. Ideally in a single place 
>> together
>> with other hypervisors. This is my preference.
> 
> It is not without saying that deviation from specification should not
> be taken lightly and has risks.
> 
> The main risk is you are never going to be able to reliably run an OS
> on Xen unless you manage to get the deviation accepted by the wider
> community and Arm.

There is just no way I'll ever accept a change to the GIC interrupt 
state
machine for Linux. Feel free to try and convince other OS maintainers.

If you want to be creative, be really creative. Implement a fully PV 
interrupt
controller that gives you simple enough semantics so that you can 
actually be
deterministic. Don't pretend you implement the GIC architecture.

>> Another idea is that we could crash the guest if GICD_ISACTIVER is 
>> read
>> from a multi-vcpu guest. It is similar to what we already do today but
>> better because we would do it purposely (not because of a typo) and
>> because it will work for single vcpu guests at least.
>> 
>> We could also leave it as is (crash all the time) but it implies that
>> vendors that are seeing issues with Linux today will have to keep
>> maintaining patches in their private trees until a better solution is
>> found. This would also be the case if we crash multi-vcpus guests as
>> previously suggested.

OK, that's just insane. Suggesting that guests should be left crashing
because the are doing *the right thing* is just barking mad. I'm all for
exposing guest bugs when they take shortcuts with the architecture, but
blaming the guest for what is just a bug in Xen?

If I was someone developing a product using Xen/ARM, I'd be very worried
about what you have written above. Because it really reads "we don't 
care
about reliability as long as we can show amazing numbers". I really hope
it isn't what you mean.

         M.
-- 
Jazz is not dead. It just smells funny...


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 09:00:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 09:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKIBt-00028q-Ld; Fri, 03 Apr 2020 09:00:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6vR8=5T=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jKIBs-00028i-Ki
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 09:00:40 +0000
X-Inumbo-ID: 967f960e-7589-11ea-bcd3-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 967f960e-7589-11ea-bcd3-12813bfff9fa;
 Fri, 03 Apr 2020 09:00:38 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8972EAEB1;
 Fri,  3 Apr 2020 09:00:37 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org, linux-block@vger.kernel.org,
 linux-kernel@vger.kernel.org
Subject: [PATCH] xen/blkfront: fix memory allocation flags in
 blkfront_setup_indirect()
Date: Fri,  3 Apr 2020 11:00:34 +0200
Message-Id: <20200403090034.8753-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Jens Axboe <axboe@kernel.dk>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, stable@vger.kernel.org,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for
large array allocation") didn't fix the issue it was meant to, as the
flags for allocating the memory are GFP_NOIO, which will lead the
memory allocation falling back to kmalloc().

So instead of GFP_NOIO use GFP_KERNEL and do all the memory allocation
in blkfront_setup_indirect() in a memalloc_noio_{save,restore} section.

Fixes: 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for large array allocation")
Cc: stable@vger.kernel.org
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 drivers/block/xen-blkfront.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 915cf5b6388c..3b889ea950c2 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -47,6 +47,7 @@
 #include <linux/bitmap.h>
 #include <linux/list.h>
 #include <linux/workqueue.h>
+#include <linux/sched/mm.h>
 
 #include <xen/xen.h>
 #include <xen/xenbus.h>
@@ -2189,10 +2190,12 @@ static void blkfront_setup_discard(struct blkfront_info *info)
 
 static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo)
 {
-	unsigned int psegs, grants;
+	unsigned int psegs, grants, memflags;
 	int err, i;
 	struct blkfront_info *info = rinfo->dev_info;
 
+	memflags = memalloc_noio_save();
+
 	if (info->max_indirect_segments == 0) {
 		if (!HAS_EXTRA_REQ)
 			grants = BLKIF_MAX_SEGMENTS_PER_REQUEST;
@@ -2224,7 +2227,7 @@ static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo)
 
 		BUG_ON(!list_empty(&rinfo->indirect_pages));
 		for (i = 0; i < num; i++) {
-			struct page *indirect_page = alloc_page(GFP_NOIO);
+			struct page *indirect_page = alloc_page(GFP_KERNEL);
 			if (!indirect_page)
 				goto out_of_memory;
 			list_add(&indirect_page->lru, &rinfo->indirect_pages);
@@ -2235,15 +2238,15 @@ static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo)
 		rinfo->shadow[i].grants_used =
 			kvcalloc(grants,
 				 sizeof(rinfo->shadow[i].grants_used[0]),
-				 GFP_NOIO);
+				 GFP_KERNEL);
 		rinfo->shadow[i].sg = kvcalloc(psegs,
 					       sizeof(rinfo->shadow[i].sg[0]),
-					       GFP_NOIO);
+					       GFP_KERNEL);
 		if (info->max_indirect_segments)
 			rinfo->shadow[i].indirect_grants =
 				kvcalloc(INDIRECT_GREFS(grants),
 					 sizeof(rinfo->shadow[i].indirect_grants[0]),
-					 GFP_NOIO);
+					 GFP_KERNEL);
 		if ((rinfo->shadow[i].grants_used == NULL) ||
 			(rinfo->shadow[i].sg == NULL) ||
 		     (info->max_indirect_segments &&
@@ -2252,6 +2255,7 @@ static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo)
 		sg_init_table(rinfo->shadow[i].sg, psegs);
 	}
 
+	memalloc_noio_restore(memflags);
 
 	return 0;
 
@@ -2271,6 +2275,9 @@ static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo)
 			__free_page(indirect_page);
 		}
 	}
+
+	memalloc_noio_restore(memflags);
+
 	return -ENOMEM;
 }
 
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 09:09:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 09:09:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKIJv-0002QZ-Ne; Fri, 03 Apr 2020 09:08:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fKXS=5T=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKIJu-0002QU-2n
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 09:08:58 +0000
X-Inumbo-ID: bff27f46-758a-11ea-bcd8-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bff27f46-758a-11ea-bcd8-12813bfff9fa;
 Fri, 03 Apr 2020 09:08:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=USlXGxBQfW6TZRIeGQbE283xJ03bgHQ9rV6twibcHpM=; b=ViK04IDSPu+KaNGgnDxgX+QJd7
 mP+riwE2+EnHzhOYO+WbLD8DkcR6Bc6TcYKkrKKe6VpVHPwuN3hnugyrXy9Y3kNpDKEQGkpLjGl80
 AbY4lzHB8WOcECEeqMu9nlHWWz4owyAR0Vm8RyPxe3JWMmcNDTMLwlauJJQ3pWl/1Td0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKIJq-0002Qx-7U; Fri, 03 Apr 2020 09:08:54 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKIJq-00080G-0x; Fri, 03 Apr 2020 09:08:54 +0000
Subject: Re: [xen-unstable test] 149335: regressions - FAIL
To: osstest service owner <osstest-admin@xenproject.org>,
 xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?=
 <roger.pau@citrix.com>, "ian.jackson@eu.citrix.com"
 <ian.jackson@eu.citrix.com>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 Jan Beulich <jbeulich@suse.com>
References: <osstest-149335-mainreport@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <90c01d6b-1d8f-81de-656e-d97eea302552@xen.org>
Date: Fri, 3 Apr 2020 10:08:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <osstest-149335-mainreport@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 03/04/2020 06:27, osstest service owner wrote:
> flight 149335 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/149335/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>   test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail REGR. vs. 149188
>   build-amd64-xsm               6 xen-build                fail REGR. vs. 149188

I am a bit puzzled with this failure. Looking at the log [1], I only found:

failure (trapped): status 256 at Osstest/TestSupport.pm line 551.

Can anyone spot an issue in the log?

Cheers,

[1] 
http://logs.test-lab.xenproject.org/osstest/logs/149335/build-amd64-xsm/6.ts-xen-build.log

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 09:11:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 09:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKIM3-00039P-4Y; Fri, 03 Apr 2020 09:11:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKIM1-00039K-Ch
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 09:11:09 +0000
X-Inumbo-ID: 0de214aa-758b-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0de214aa-758b-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 09:11:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 432FAADC8;
 Fri,  3 Apr 2020 09:11:07 +0000 (UTC)
Subject: Re: [xen-unstable test] 149335: regressions - FAIL
To: Julien Grall <julien@xen.org>
References: <osstest-149335-mainreport@xen.org>
 <90c01d6b-1d8f-81de-656e-d97eea302552@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8087c371-0488-3a26-379b-af964b4300ce@suse.com>
Date: Fri, 3 Apr 2020 11:11:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <90c01d6b-1d8f-81de-656e-d97eea302552@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 osstest service owner <osstest-admin@xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 11:08, Julien Grall wrote:
> Hi,
> 
> On 03/04/2020 06:27, osstest service owner wrote:
>> flight 149335 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/149335/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>   test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail REGR. vs. 149188
>>   build-amd64-xsm               6 xen-build                fail REGR. vs. 149188
> 
> I am a bit puzzled with this failure. Looking at the log [1], I only found:
> 
> failure (trapped): status 256 at Osstest/TestSupport.pm line 551.
> 
> Can anyone spot an issue in the log?

Yes:

fatal: remote error: git-cache-proxy: git remote died with error exit code 1 // Fetching origin // fatal: unable to access 'https://github.com/krb5/krb5/': The requested URL returned error: 504 // error: Could not fetch origin
fatal: clone of 'https://github.com/krb5/krb5' into submodule path '/home/osstest/build.149335.build-amd64-xsm/xen/tools/firmware/ovmf-dir-remote/CryptoPkg/Library/OpensslLib/openssl/krb5' failed

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 09:13:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 09:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKIO8-0003IP-Li; Fri, 03 Apr 2020 09:13:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fKXS=5T=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKIO7-0003IK-T4
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 09:13:19 +0000
X-Inumbo-ID: 5c150380-758b-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5c150380-758b-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 09:13:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=bBhycdUWxbN/XcZgP00W/lb/2siG9aVTWMKSQAT4K3M=; b=wXumFoze2Joi4ghNPr2d46ZMkP
 632XhlFpfMfrewpczL3Ftt/AA3jdz0IERV/JgdCmvV6Q0EgDysmqLZFnzWn0Ey9kIVb77lhYdA6ZN
 8LUe2Or/2JJat+b3mUhNgNhhcrGlwBx+eO7s8ypdzRVio7vyS1N+PkdfwQXymdz4zJDc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKIO6-0002WX-0K; Fri, 03 Apr 2020 09:13:18 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKIO5-0008Q4-QF; Fri, 03 Apr 2020 09:13:17 +0000
Subject: Re: [xen-unstable test] 149335: regressions - FAIL
To: Jan Beulich <jbeulich@suse.com>
References: <osstest-149335-mainreport@xen.org>
 <90c01d6b-1d8f-81de-656e-d97eea302552@xen.org>
 <8087c371-0488-3a26-379b-af964b4300ce@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <7d7afffb-9b8e-e504-9f23-4aa3d7e55e04@xen.org>
Date: Fri, 3 Apr 2020 10:13:16 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <8087c371-0488-3a26-379b-af964b4300ce@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 osstest service owner <osstest-admin@xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 03/04/2020 10:11, Jan Beulich wrote:
> On 03.04.2020 11:08, Julien Grall wrote:
>> Hi,
>>
>> On 03/04/2020 06:27, osstest service owner wrote:
>>> flight 149335 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/149335/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>    test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail REGR. vs. 149188
>>>    build-amd64-xsm               6 xen-build                fail REGR. vs. 149188
>>
>> I am a bit puzzled with this failure. Looking at the log [1], I only found:
>>
>> failure (trapped): status 256 at Osstest/TestSupport.pm line 551.
>>
>> Can anyone spot an issue in the log?
> 
> Yes:
> 
> fatal: remote error: git-cache-proxy: git remote died with error exit code 1 // Fetching origin // fatal: unable to access 'https://github.com/krb5/krb5/': The requested URL returned error: 504 // error: Could not fetch origin
> fatal: clone of 'https://github.com/krb5/krb5' into submodule path '/home/osstest/build.149335.build-amd64-xsm/xen/tools/firmware/ovmf-dir-remote/CryptoPkg/Library/OpensslLib/openssl/krb5' failed

Thanks! So it is a networking issue. I will ignore this one.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 09:14:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 09:14:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKIPM-0003Nz-1e; Fri, 03 Apr 2020 09:14:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=i4CN=5T=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKIPK-0003Nq-I0
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 09:14:34 +0000
X-Inumbo-ID: 85d0d6ae-758b-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 85d0d6ae-758b-11ea-83d8-bc764e2007e4;
 Fri, 03 Apr 2020 09:14:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=QZYugD6/bxzhnziYbGncmnORkxx7FjzYhnbg+HenssA=; b=EGlKvapbo7HchvsPOf76GVPd5
 gD/PP4wRACOUNwUdH/C4Nf4OSEj3qGHIOXJq6lfYqgie0HlGxJ6TvACtaO0NaCpDhr5t6EaFWHU+l
 ZtrWM3va3cNI5wtiRCB2EGOEGt0sx7VoQE1xyut2+pcxkbLcuj5PvVScjTf2lbD5aRg1U=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKIPF-0002Xa-6p; Fri, 03 Apr 2020 09:14:29 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKIPE-0006LG-Vt; Fri, 03 Apr 2020 09:14:29 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKIPE-0007UD-Uf; Fri, 03 Apr 2020 09:14:28 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149344-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149344: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-intel:guest-start/debian.repeat:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=2833ad487cfff7dc33703e4731b75facde1c561e
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 03 Apr 2020 09:14:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-i386-freebsd10-i386 11 guest-start            fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-freebsd10-amd64 11 guest-start           fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 20 guest-start/debian.repeat fail baseline untested
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 144861
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                2833ad487cfff7dc33703e4731b75facde1c561e
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  108 days
Failing since        144880  2019-12-16 20:07:08 Z  108 days  318 attempts
Testing same since   149264  2020-04-01 02:32:20 Z    2 days    3 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 56117 lines long.)


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 09:14:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 09:14:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKIPP-0003PR-EC; Fri, 03 Apr 2020 09:14:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKIPO-0003PH-HE
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 09:14:38 +0000
X-Inumbo-ID: 8aa3b3ea-758b-11ea-bcd8-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8aa3b3ea-758b-11ea-bcd8-12813bfff9fa;
 Fri, 03 Apr 2020 09:14:38 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B0F0CAA7C;
 Fri,  3 Apr 2020 09:14:36 +0000 (UTC)
Subject: Re: [PATCH 3/5] x86/p2m: make p2m_remove_page()'s parameters type-safe
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
 <858f22e3-0f4f-08f0-ef67-b8ce67146537@suse.com>
 <ae425c2f-0297-4944-5bd5-03ccdab8fdce@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <d6a1dc4a-f6e6-ae2c-81fd-d918087c8328@suse.com>
Date: Fri, 3 Apr 2020 11:14:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <ae425c2f-0297-4944-5bd5-03ccdab8fdce@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 00:43, Andrew Cooper wrote:
> On 01/04/2020 12:39, Jan Beulich wrote:
>> @@ -790,21 +789,23 @@ p2m_remove_page(struct p2m_domain *p2m,
>>                                            &cur_order, NULL);
>>  
>>          if ( p2m_is_valid(t) &&
>> -             (!mfn_valid(_mfn(mfn)) || mfn + i != mfn_x(mfn_return)) )
>> +             (!mfn_valid(mfn) || !mfn_eq(mfn_add(mfn, i), mfn_return)) )
>>              return -EILSEQ;
>>  
>> -        i += (1UL << cur_order) - ((gfn_l + i) & ((1UL << cur_order) - 1));
>> +        i += (1UL << cur_order) -
>> +             (gfn_x(gfn_add(gfn, i)) & ((1UL << cur_order) - 1));
> 
> We're gaining an number of expressions starting to look like this, but
> honestly, "gfn_x(gfn) + i" is equally typesafe, shorter, and easier to
> read IMO.

May I, just like you said for patch 3, imply A-b with this adjusted?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 10:43:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 10:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKJnU-0002BR-Av; Fri, 03 Apr 2020 10:43:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=wV/t=5T=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jKJnS-0002BM-Vk
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 10:43:35 +0000
X-Inumbo-ID: f70bff40-7597-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f70bff40-7597-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 10:43:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585910613;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=tqrHgr3TfceaoT0SIEJ3gkz/24Vy6bsnuZdodHWMsuc=;
 b=aAU+UQ5M08/zs0gRpkNXQ2eVVABbbG5+Syj9rFHjmzoVh1V/IS98q2BL
 PGgCzdSWw9jdHrJTzfXj5f+I5mFn0H3rwNktrgn1JN/JRUFSjeshpMKOz
 93Y8XBp4vVydmCJ1qiUves4UdAgFoUJL5hOCJBXKRl42pDpkY/ZIR2Wxa 8=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 2dlZNTkRsz8G8T3ZHahYS41uXTzP7OoqlFzqN/ffbDPd6mSjO1UtWLLyGrOJpVud6HGeIiIKLv
 F0/Pz0podPwWO/oiM+qKFFVWkx+X09ud6VJUWV1yekiowb/D80a12GF/T3AfMRoIQfSteqyE/L
 ZgFxDQMtFnh/ceVcd8oLwOPyKvHNR3+vLvWKoGcyL0npMEH7V2NSttDIrWUkWERbfQ383ndhFe
 JEqJt0WRjjsdORB/U3I2pzViaOR7I/kZckNgAeKM45FEdW3QT7+i8lZKi8N/mpD6q7rY/I1Zva
 tsY=
X-SBRS: 2.7
X-MesageID: 15785555
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,339,1580792400"; d="scan'208";a="15785555"
From: George Dunlap <George.Dunlap@citrix.com>
To: Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Topic: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Index: AQHWCRLu2U2EJ1WUk0i1KTanKYKpWqhmDBwAgADpHYCAACByAA==
Date: Fri, 3 Apr 2020 10:43:12 +0000
Message-ID: <76A7BB45-6B4A-46F4-8AD7-9141B3BF9BC4@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
In-Reply-To: <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8BC56A9351055940B65C057EB3D3EA47@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Wei Xu <xuwei5@hisilicon.com>,
 "Bertrand.Marquis@arm.com" <Bertrand.Marquis@arm.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


> On Apr 3, 2020, at 9:47 AM, Marc Zyngier <maz@kernel.org> wrote:
>=20
> On 2020-04-02 19:52, Julien Grall wrote:
>> (+Marc)
>=20
> Thanks for looping me in. Definitely an interesting read, but also a very
> puzzling one.

[snip]

> No. Low latency is a very desirable thing, but it doesn't matter at all w=
hen
> you don't even have functional correctness. To use my favourite car analo=
gy,
> having a bigger engine doesn't help when you're about to hit the wall and
> have no breaks... You just hit the wall faster.

[snip]

> s/imprecise/massively incorrect/

[snip]

> There is just no way I'll ever accept a change to the GIC interrupt state
> machine for Linux. Feel free to try and convince other OS maintainers.

[snip]

> If I was someone developing a product using Xen/ARM, I'd be very worried
> about what you have written above. Because it really reads "we don't care
> about reliability as long as we can show amazing numbers". I really hope
> it isn't what you mean.

What's puzzling to me, is that what everyone else in this thread is that wh=
at Stefano is trying to do is to get Xen to be have like KVM.

Are they wrong?  If so, we can just do whatever Linux does.  If not, then y=
ou need to first turn all your imprecations about correctness, smashing int=
o walls, concern for the sanity of maintainers and so on towards your own c=
ode first.

 -George=


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 10:59:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 10:59:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKK2X-00038C-Oq; Fri, 03 Apr 2020 10:59:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=DpjN=5T=kernel.org=maz@srs-us1.protection.inumbo.net>)
 id 1jKK2W-000387-2b
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 10:59:08 +0000
X-Inumbo-ID: 23af32b8-759a-11ea-b58d-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 23af32b8-759a-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 10:59:07 +0000 (UTC)
Received: from disco-boy.misterjones.org (disco-boy.misterjones.org
 [51.254.78.96])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id B411420757;
 Fri,  3 Apr 2020 10:59:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1585911546;
 bh=ahPBuX08756i1V0bRbqbI/eO6SWcFnhmlsp3vme9bnI=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=Wup0wtnmJGpGo8VEii+1XnAUIjbFA2VZObgguHCL7eXn3Nzo/3Tb8bJIv5ssmkcr2
 IwjEgPHfkMOhwF9NAIWHbfB+4UlinlB4Fp9TJ2cNIdI7KD+CgRfcyOv5k2CURiuOGe
 ztwMKLDZ8/Ocqe5TXViWRZjygPtfeG1H2ddV5g88=
Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr)
 by disco-boy.misterjones.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from <maz@kernel.org>)
 id 1jKK2S-000Tji-Ro; Fri, 03 Apr 2020 11:59:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 03 Apr 2020 11:59:04 +0100
From: Marc Zyngier <maz@kernel.org>
To: George Dunlap <George.Dunlap@citrix.com>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
In-Reply-To: <76A7BB45-6B4A-46F4-8AD7-9141B3BF9BC4@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
 <76A7BB45-6B4A-46F4-8AD7-9141B3BF9BC4@citrix.com>
Message-ID: <017cfca3b079356abfcd829756af2fdb@kernel.org>
X-Sender: maz@kernel.org
User-Agent: Roundcube Webmail/1.3.10
X-SA-Exim-Connect-IP: 51.254.78.96
X-SA-Exim-Rcpt-To: George.Dunlap@citrix.com, julien@xen.org,
 stefano.stabellini@xilinx.com, sstabellini@kernel.org,
 xen-devel@lists.xenproject.org, xuwei5@hisilicon.com, peng.fan@nxp.com,
 Bertrand.Marquis@arm.com
X-SA-Exim-Mail-From: maz@kernel.org
X-SA-Exim-Scanned: No (on disco-boy.misterjones.org);
 SAEximRunCond expanded to false
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

George,

On 2020-04-03 11:43, George Dunlap wrote:
>> On Apr 3, 2020, at 9:47 AM, Marc Zyngier <maz@kernel.org> wrote:
>> 
>> On 2020-04-02 19:52, Julien Grall wrote:
>>> (+Marc)
>> 
>> Thanks for looping me in. Definitely an interesting read, but also a 
>> very
>> puzzling one.
> 
> [snip]
> 
>> No. Low latency is a very desirable thing, but it doesn't matter at 
>> all when
>> you don't even have functional correctness. To use my favourite car 
>> analogy,
>> having a bigger engine doesn't help when you're about to hit the wall 
>> and
>> have no breaks... You just hit the wall faster.
> 
> [snip]
> 
>> s/imprecise/massively incorrect/
> 
> [snip]
> 
>> There is just no way I'll ever accept a change to the GIC interrupt 
>> state
>> machine for Linux. Feel free to try and convince other OS maintainers.
> 
> [snip]
> 
>> If I was someone developing a product using Xen/ARM, I'd be very 
>> worried
>> about what you have written above. Because it really reads "we don't 
>> care
>> about reliability as long as we can show amazing numbers". I really 
>> hope
>> it isn't what you mean.
> 
> What's puzzling to me, is that what everyone else in this thread is
> that what Stefano is trying to do is to get Xen to be have like KVM.

Sorry, I don't get what you mean here. KVM at least aims to be 
architecturally
compliant. Is it perfect? Most probably not, as we fix it all the time.

Dealing with the active registers is hard. But as far as I can see,
we do get them right. Do we sacrifice latency over correctness? Yes.

And if you have spotted a problem in the way we handle those, pray tell.

> Are they wrong?  If so, we can just do whatever Linux does.  If not,
> then you need to first turn all your imprecations about correctness,
> smashing into walls, concern for the sanity of maintainers and so on
> towards your own code first.

I'm really sorry, but you see to have the wrong end of the stick here.
I'm not trying to compare Xen to KVM at all. I'm concerned about only
implementing only a small part of the architecture, ignoring the rest,
and letting guests crash, which is what was suggested here.

         M.
-- 
Jazz is not dead. It just smells funny...


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 11:15:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 11:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKKIA-0004jG-6s; Fri, 03 Apr 2020 11:15:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=wV/t=5T=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jKKI9-0004jB-2k
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 11:15:17 +0000
X-Inumbo-ID: 647da05c-759c-11ea-bcf5-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 647da05c-759c-11ea-bcf5-12813bfff9fa;
 Fri, 03 Apr 2020 11:15:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585912515;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=shO6JaSi3oqiACck0/yfCwp+Cr7KmlMQMkq2hVSwc3E=;
 b=PflDSDI8flifUGx/34UgGl0HVxBS+T+url/pgLZCwpe0z8FlXbWA5zsj
 DKQby9X+2OO6Tpw8n0ABTmNPEk93tTu4AGH8a25QGiW/ggWD3vaVB7K1h
 pwoFaDImDNMR/59uG7mHBvTbFSikyOJbDPnIfsnh1bY9ndeujgPxaek1H A=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Y7B0TeHBRHwR4X5szP+x6PETEPnFd1vHE8bwbI7zo2KvOz3kO7CaPa26NT+ie+Ean3n2HEdvuv
 OslpPM0VNZ9yps32vbLc6AFfU81Iy4418HtrugzLnusgELvWUX3hkxD3/qUS9BPismwETJG2ez
 P74WgXWosoRYcI/bCgB4coRflxKCjuP88riD6WT4co1ws6rqhr0sX/kmTOHSk+JcMGBUsY5Iwi
 Av36ZYnZ11q0CfBCaBnyRlmsjABKO2NXTJc7cYzUiln1wFOEFKqE/mir5ZTCdrx+L2cmzO2W0P
 vc8=
X-SBRS: 2.7
X-MesageID: 15531447
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,339,1580792400"; d="scan'208";a="15531447"
From: George Dunlap <George.Dunlap@citrix.com>
To: Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Topic: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Index: AQHWCRLu2U2EJ1WUk0i1KTanKYKpWqhmDBwAgADpHYCAACByAIAABG8AgAAEfwA=
Date: Fri, 3 Apr 2020 11:15:10 +0000
Message-ID: <6831C306-8BD3-4E7A-A45A-7B91E1616DC1@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
 <76A7BB45-6B4A-46F4-8AD7-9141B3BF9BC4@citrix.com>
 <017cfca3b079356abfcd829756af2fdb@kernel.org>
In-Reply-To: <017cfca3b079356abfcd829756af2fdb@kernel.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <F539FB375EB0ED459AC7EEEB0B0AC27C@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Wei Xu <xuwei5@hisilicon.com>,
 "Bertrand.Marquis@arm.com" <Bertrand.Marquis@arm.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDMsIDIwMjAsIGF0IDExOjU5IEFNLCBNYXJjIFp5bmdpZXIgPG1hekBrZXJu
ZWwub3JnPiB3cm90ZToNCj4gDQo+IEdlb3JnZSwNCj4gDQo+IE9uIDIwMjAtMDQtMDMgMTE6NDMs
IEdlb3JnZSBEdW5sYXAgd3JvdGU6DQo+Pj4gT24gQXByIDMsIDIwMjAsIGF0IDk6NDcgQU0sIE1h
cmMgWnluZ2llciA8bWF6QGtlcm5lbC5vcmc+IHdyb3RlOg0KPj4+IE9uIDIwMjAtMDQtMDIgMTk6
NTIsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+Pj4gKCtNYXJjKQ0KPj4+IFRoYW5rcyBmb3IgbG9v
cGluZyBtZSBpbi4gRGVmaW5pdGVseSBhbiBpbnRlcmVzdGluZyByZWFkLCBidXQgYWxzbyBhIHZl
cnkNCj4+PiBwdXp6bGluZyBvbmUuDQo+PiBbc25pcF0NCj4+PiBOby4gTG93IGxhdGVuY3kgaXMg
YSB2ZXJ5IGRlc2lyYWJsZSB0aGluZywgYnV0IGl0IGRvZXNuJ3QgbWF0dGVyIGF0IGFsbCB3aGVu
DQo+Pj4geW91IGRvbid0IGV2ZW4gaGF2ZSBmdW5jdGlvbmFsIGNvcnJlY3RuZXNzLiBUbyB1c2Ug
bXkgZmF2b3VyaXRlIGNhciBhbmFsb2d5LA0KPj4+IGhhdmluZyBhIGJpZ2dlciBlbmdpbmUgZG9l
c24ndCBoZWxwIHdoZW4geW91J3JlIGFib3V0IHRvIGhpdCB0aGUgd2FsbCBhbmQNCj4+PiBoYXZl
IG5vIGJyZWFrcy4uLiBZb3UganVzdCBoaXQgdGhlIHdhbGwgZmFzdGVyLg0KPj4gW3NuaXBdDQo+
Pj4gcy9pbXByZWNpc2UvbWFzc2l2ZWx5IGluY29ycmVjdC8NCj4+IFtzbmlwXQ0KPj4+IFRoZXJl
IGlzIGp1c3Qgbm8gd2F5IEknbGwgZXZlciBhY2NlcHQgYSBjaGFuZ2UgdG8gdGhlIEdJQyBpbnRl
cnJ1cHQgc3RhdGUNCj4+PiBtYWNoaW5lIGZvciBMaW51eC4gRmVlbCBmcmVlIHRvIHRyeSBhbmQg
Y29udmluY2Ugb3RoZXIgT1MgbWFpbnRhaW5lcnMuDQo+PiBbc25pcF0NCj4+PiBJZiBJIHdhcyBz
b21lb25lIGRldmVsb3BpbmcgYSBwcm9kdWN0IHVzaW5nIFhlbi9BUk0sIEknZCBiZSB2ZXJ5IHdv
cnJpZWQNCj4+PiBhYm91dCB3aGF0IHlvdSBoYXZlIHdyaXR0ZW4gYWJvdmUuIEJlY2F1c2UgaXQg
cmVhbGx5IHJlYWRzICJ3ZSBkb24ndCBjYXJlDQo+Pj4gYWJvdXQgcmVsaWFiaWxpdHkgYXMgbG9u
ZyBhcyB3ZSBjYW4gc2hvdyBhbWF6aW5nIG51bWJlcnMiLiBJIHJlYWxseSBob3BlDQo+Pj4gaXQg
aXNuJ3Qgd2hhdCB5b3UgbWVhbi4NCj4+IFdoYXQncyBwdXp6bGluZyB0byBtZSwgaXMgdGhhdCB3
aGF0IGV2ZXJ5b25lIGVsc2UgaW4gdGhpcyB0aHJlYWQgaXMNCj4+IHRoYXQgd2hhdCBTdGVmYW5v
IGlzIHRyeWluZyB0byBkbyBpcyB0byBnZXQgWGVuIHRvIGJlIGhhdmUgbGlrZSBLVk0uDQo+IA0K
PiBTb3JyeSwgSSBkb24ndCBnZXQgd2hhdCB5b3UgbWVhbiBoZXJlLiBLVk0gYXQgbGVhc3QgYWlt
cyB0byBiZSBhcmNoaXRlY3R1cmFsbHkNCj4gY29tcGxpYW50LiBJcyBpdCBwZXJmZWN0PyBNb3N0
IHByb2JhYmx5IG5vdCwgYXMgd2UgZml4IGl0IGFsbCB0aGUgdGltZS4NCj4gDQo+IERlYWxpbmcg
d2l0aCB0aGUgYWN0aXZlIHJlZ2lzdGVycyBpcyBoYXJkLiBCdXQgYXMgZmFyIGFzIEkgY2FuIHNl
ZSwNCj4gd2UgZG8gZ2V0IHRoZW0gcmlnaHQuIERvIHdlIHNhY3JpZmljZSBsYXRlbmN5IG92ZXIg
Y29ycmVjdG5lc3M/IFllcy4NCj4gDQo+IEFuZCBpZiB5b3UgaGF2ZSBzcG90dGVkIGEgcHJvYmxl
bSBpbiB0aGUgd2F5IHdlIGhhbmRsZSB0aG9zZSwgcHJheSB0ZWxsLg0KPiANCj4+IEFyZSB0aGV5
IHdyb25nPyAgSWYgc28sIHdlIGNhbiBqdXN0IGRvIHdoYXRldmVyIExpbnV4IGRvZXMuICBJZiBu
b3QsDQo+PiB0aGVuIHlvdSBuZWVkIHRvIGZpcnN0IHR1cm4gYWxsIHlvdXIgaW1wcmVjYXRpb25z
IGFib3V0IGNvcnJlY3RuZXNzLA0KPj4gc21hc2hpbmcgaW50byB3YWxscywgY29uY2VybiBmb3Ig
dGhlIHNhbml0eSBvZiBtYWludGFpbmVycyBhbmQgc28gb24NCj4+IHRvd2FyZHMgeW91ciBvd24g
Y29kZSBmaXJzdC4NCj4gDQo+IEknbSByZWFsbHkgc29ycnksIGJ1dCB5b3Ugc2VlIHRvIGhhdmUg
dGhlIHdyb25nIGVuZCBvZiB0aGUgc3RpY2sgaGVyZS4NCj4gSSdtIG5vdCB0cnlpbmcgdG8gY29t
cGFyZSBYZW4gdG8gS1ZNIGF0IGFsbC4gSSdtIGNvbmNlcm5lZCBhYm91dCBvbmx5DQo+IGltcGxl
bWVudGluZyBvbmx5IGEgc21hbGwgcGFydCBvZiB0aGUgYXJjaGl0ZWN0dXJlLCBpZ25vcmluZyB0
aGUgcmVzdCwNCj4gYW5kIGxldHRpbmcgZ3Vlc3RzIGNyYXNoLCB3aGljaCBpcyB3aGF0IHdhcyBz
dWdnZXN0ZWQgaGVyZS4NCg0KVGhlIGN1cnJlbnQgc2l0dWF0aW9uIChhcyBJIHVuZGVyc3RhbmQg
aXQpIGlzIHRoYXQgWGVuIG5ldmVyIGltcGxlbWVudGVkIHRoaXMgZnVuY3Rpb25hbGl0eSBhdCBh
bGwuDQoNClN0ZWZhbm8gaGFzIGJlZW4gdHJ5aW5nIHRvIGNvbnZpbmNlIEp1bGllbiB0byBpbXBs
ZW1lbnQgdGhpcyByZWdpc3RlciBLVk3igJlzIHdheSwgd2hpY2ggaGFzIGdvb2QgbGF0ZW5jeSBp
biB0aGUgbWVkaWFuIGNhc2UsIGJ1dCBpbiBwYXJ0aWN1bGFyIGNvbmZpZ3VyYXRpb25zLCBoYXMg
YXJiaXRyYXJpbHkgYmFkIHdvcnN0LWNhc2UgbGF0ZW5jeSBmb3IgbXVsdGktdmNwdSBndWVzdHMu
ICBKdWxpZW4gdGhpbmtzIHdoYXQgS1ZNIGlzIGRvaW5nIGlzIHdyb25nIGFuZCBhZ2FpbnN0IHRo
ZSBzcGVjLCBhbmQgaGFzIGJlZW4gcmVmdXNpbmcgdG8gbGV0IHRoZSBwYXRjaGVzIGluLiANCg0K
SGUgaGFzIHByb3Bvc2VkIGFub3RoZXIgc3VnZ2VzdGlvbiB3aGljaCBpcyBjbG9zZXIgdG8gdGhl
IHNwZWMgaW4gdGVybXMgb2YgZnVuY3Rpb25hbGl0eSwgYW5kIGhhcyBib3VuZGVkIHdvcnN0LWNh
c2UgbGF0ZW5jeSwgYnV0IHdoaWNoIGhhcyB3b3JzZSBsYXRlbmN5IGFuZCB1bmNvbnRyb2xsYWJs
ZSBqaXR0ZXIgaW4gdGhlIG1lZGlhbiBjYXNlIChvciBhdCBsZWFzdCwgc28gU3RlZmFubyBiZWxp
ZXZlcykuDQoNCkFzIGEgY29tcHJvbWlzZSwgU3RlZmFubyBzdWdnZXN0ZWQgaW1wbGVtZW50aW5n
IEtWTeKAmXMgd2F5IGZvciBzaW5nbGUtdmNwdSBndWVzdHMuICBUaGlzIGlzIGEgc3RyaWN0IGlt
cHJvdmVtZW50IG92ZXIgdGhlIGN1cnJlbnQgc2l0dWF0aW9uLCBzaW5jZSBhdCBsZWFzdCBhIGxv
dCBvZiBuZXcgZ3Vlc3RzIHN0YXJ0IHdvcmtpbmcsIHdoaWxlIHRoZXkgaGFzaCBvdXQgd2hhdCB0
byBkbyBhYm91dCBtdWx0aS12Y3B1IGd1ZXN0cy4NCg0KTXkgcHJvcG9zYWwgaGFzIGJlZW4gdG8g
d29yayB3aXRoIEtWTSBkbyBkb2N1bWVudCB0aGlzIGRldmlhdGlvbiBmcm9tIHRoZSBzcGVjIGZv
ciBndWVzdHMgcnVubmluZyB2aXJ0dWFsaXplZC4gIA0KDQpTbyBpdOKAmXMgeW91IGhhdmUgaGF2
ZSB0aGUgd3JvbmcgZW5kIG9mIHRoZSBzdGljazsgeW91ciBjb250ZW1wdCBpcyBtaXNwbGFjZWQu
DQoNCklmIHlvdSBkb27igJl0IHRoaW5rIGl04oCZcyBhIGRldmlhdGlvbiwgdGhlbiBwbGVhc2Ug
aGVscCB1cyBjb252aW5jZSBKdWxpZW4sIHNvIHdlIGNhbiB0YWtlIFN0ZWZhbm/igJlzIHBhdGNo
IGFzLWlzLiAgT3IsIGlmIEp1bGllbiBjb252aW5jZXMgeW91IHRoYXQgS1ZNIGlzIGRldmlhdGlu
ZyBmcm9tIHRoZSBzcGVjLCB0aGVuIGxldOKAmXMgdHJ5IHRvIHdvcmsgdG9nZXRoZXIgdG8gc2Vl
IGhvdyB3ZSBjYW4gaW1wbGVtZW50IHRoZSBuZWNlc3NhcnkgZnVuY3Rpb25hbGl0eSBlZmZpY2ll
bnRseSBpbiBhIHZpcnR1YWxpemVkIGVudmlyb25tZW50Lg0KDQogLUdlb3JnZQ==


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 11:16:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 11:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKKJE-0004n6-HS; Fri, 03 Apr 2020 11:16:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fKXS=5T=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKKJC-0004mx-L4
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 11:16:22 +0000
X-Inumbo-ID: 8b718c65-759c-11ea-bcf5-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8b718c65-759c-11ea-bcf5-12813bfff9fa;
 Fri, 03 Apr 2020 11:16:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=HYKVQQ39BlW/RAyO8aOWuc21eCjz4xTmkiMyoOVuvm4=; b=xN9rxr2/TWSKsjhypvyJTj8jTq
 4o9yPxr0B0dKZftKahuqcypo6w/btxbv+jax18++e1M3GLUU+fzEP+oQT1nppXTZlaiDoNYdiMD+k
 gYdWe11wDqyrVIx96tBW9fCT1BKK+fB191RINhMK3r2YMkP195U77JE/mQwLRYzumDZU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKKJ6-00052N-8n; Fri, 03 Apr 2020 11:16:16 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKKJ6-000874-1e; Fri, 03 Apr 2020 11:16:16 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: George Dunlap <George.Dunlap@citrix.com>, Marc Zyngier <maz@kernel.org>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
 <76A7BB45-6B4A-46F4-8AD7-9141B3BF9BC4@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <fbdba8a3-ede2-7809-68e7-ec6ed41b4f84@xen.org>
Date: Fri, 3 Apr 2020 12:16:13 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <76A7BB45-6B4A-46F4-8AD7-9141B3BF9BC4@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Wei Xu <xuwei5@hisilicon.com>,
 "Bertrand.Marquis@arm.com" <Bertrand.Marquis@arm.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 03/04/2020 11:43, George Dunlap wrote:
> 
>> On Apr 3, 2020, at 9:47 AM, Marc Zyngier <maz@kernel.org> wrote:
>>
>> On 2020-04-02 19:52, Julien Grall wrote:
>>> (+Marc)
>>
>> Thanks for looping me in. Definitely an interesting read, but also a very
>> puzzling one.
> 
> [snip]
> 
>> No. Low latency is a very desirable thing, but it doesn't matter at all when
>> you don't even have functional correctness. To use my favourite car analogy,
>> having a bigger engine doesn't help when you're about to hit the wall and
>> have no breaks... You just hit the wall faster.
> 
> [snip]
> 
>> s/imprecise/massively incorrect/
> 
> [snip]
> 
>> There is just no way I'll ever accept a change to the GIC interrupt state
>> machine for Linux. Feel free to try and convince other OS maintainers.
> 
> [snip]
> 
>> If I was someone developing a product using Xen/ARM, I'd be very worried
>> about what you have written above. Because it really reads "we don't care
>> about reliability as long as we can show amazing numbers". I really hope
>> it isn't what you mean.
> 
> What's puzzling to me, is that what everyone else in this thread is that what Stefano is trying to do is to get Xen to be have like KVM.

This reads to me as "bugs don't exist".

As I actually said in a previous e-mail, our vGIC is significantly 
different compare to KVM. It *might* be possible they are not affected 
because the may trap when a guest is deactivating an interrupt *or* by 
other means.

I didn't look in the details their implementation, but this suggests you 
or Stefano may have. Why do you think Stefano's implementation is 
following what KVM does? If the behavior is the same, was the problem 
reported to KVM ML? What was the answer from the maintainers?

I suspect this was never discussed on KVM ML. So that should really be 
the first step.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 11:28:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 11:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKKUX-0005ju-Q6; Fri, 03 Apr 2020 11:28:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=i4CN=5T=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKKUW-0005jp-Be
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 11:28:04 +0000
X-Inumbo-ID: 2b2997d2-759e-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2b2997d2-759e-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 11:27:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=sQ43LagpubjFVV2SDm0Z21J/M6sYFhx+/RW3lFv5mhU=; b=a0Q0Xymrk3oBYNPnsZAM4i3lR
 IyMpHYlsGSYBT8TVjDYkXhxVKiQEu+zJJRVLxPXAG41TWtu/A96BDflNVj/Dc9D6CYTutNF27u2FK
 7qcRav/xEPc5VEwgRdxppQnhuztG2OBSYIEhrngxsWc0Df4KvxQsyZ/QisYiOVJ0rgWa0=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKKUP-0005Gk-I9; Fri, 03 Apr 2020 11:27:57 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKKUP-0005is-Bu; Fri, 03 Apr 2020 11:27:57 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKKUP-0001lL-Ax; Fri, 03 Apr 2020 11:27:57 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149348-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149348: regressions - FAIL
X-Osstest-Failures: linux-linus:build-arm64-pvops:kernel-build:fail:regression
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=919dce24701f7b34681a6a1d3ef95c9f6c4fb1cc
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 03 Apr 2020 11:27:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-examine      1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)               blocked  n/a
 test-amd64-amd64-dom0pvh-xl-intel 15 guest-saverestore        fail like 149238
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149238
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149238
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149238
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-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-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                919dce24701f7b34681a6a1d3ef95c9f6c4fb1cc
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    3 days
Failing since        149266  2020-04-01 03:55:53 Z    2 days    3 attempts
Testing same since   149348  2020-04-02 17:13:07 Z    0 days    1 attempts

------------------------------------------------------------
1011 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  blocked 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  blocked 
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     blocked 
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 blocked 
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 12:04:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 12:04:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKL35-0000TQ-Rw; Fri, 03 Apr 2020 12:03:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6vR8=5T=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jKL33-0000TK-Vx
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 12:03:46 +0000
X-Inumbo-ID: 2a2da74d-75a3-11ea-bcfe-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2a2da74d-75a3-11ea-bcfe-12813bfff9fa;
 Fri, 03 Apr 2020 12:03:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E6169AC0C;
 Fri,  3 Apr 2020 12:03:42 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2] tools/xenstore: fix a use after free problem in xenstored
Date: Fri,  3 Apr 2020 14:03:40 +0200
Message-Id: <20200403120340.13406-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object
twice") introduced a potential use after free problem in
domain_cleanup(): after calling talloc_unlink() for domain->conn
domain->conn is set to NULL. The problem is that domain is registered
as talloc child of domain->conn, so it might be freed by the
talloc_unlink() call.

With Xenstore being single threaded there are normally no concurrent
memory allocations running and freeing a virtual memory area normally
doesn't result in that area no longer being accessible. A problem
could occur only in case either a signal received results in some
memory allocation done in the signal handler (SIGHUP is a primary
candidate leading to reopening the log file), or in case the talloc
framework would do some internal memory allocation during freeing of
the memory (which would lead to clobbering of the freed domain
structure).

Fixes: 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object twice")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/xenstore/xenstored_domain.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index baddaba5df..5858185211 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -214,6 +214,7 @@ static void domain_cleanup(void)
 {
 	xc_dominfo_t dominfo;
 	struct domain *domain;
+	struct connection *conn;
 	int notify = 0;
 
  again:
@@ -230,8 +231,10 @@ static void domain_cleanup(void)
 				continue;
 		}
 		if (domain->conn) {
-			talloc_unlink(talloc_autofree_context(), domain->conn);
+			/* domain is a talloc child of domain->conn. */
+			conn = domain->conn;
 			domain->conn = NULL;
+			talloc_unlink(talloc_autofree_context(), conn);
 			notify = 0; /* destroy_domain() fires the watch */
 			goto again;
 		}
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 12:33:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 12:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKLVZ-0002rY-9d; Fri, 03 Apr 2020 12:33:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=i4CN=5T=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKLVY-0002rT-QD
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 12:33:12 +0000
X-Inumbo-ID: 4723427d-75a7-11ea-bd01-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4723427d-75a7-11ea-bd01-12813bfff9fa;
 Fri, 03 Apr 2020 12:33:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/3DRRRrupJpHL0HLVbkuPsFvSZTB6Pqtbb4c3UxNsnI=; b=P+xTOM+QcThYxlbqQzVJY8sO/
 PmmyAzdtWpjdZgfsFrfJqEG0by6Y4bsNSwtrIolQgXLMrSTCfFz3Xn02Fse0VIxFlSL4wyKtnXfcP
 X5rbg7iWb/RU3sg0xGqdBCPxXQgS12QreDCGEUSsXgYfS+jgyhdgAJhMWQXaazlQY37Qw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKLVW-0006Tk-NA; Fri, 03 Apr 2020 12:33:10 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKLVW-0001cC-Dd; Fri, 03 Apr 2020 12:33:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKLVW-00036e-D6; Fri, 03 Apr 2020 12:33:10 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149382-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149382: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=009360acc9c90513e4a85c7285d4fd7a665c66e1
X-Osstest-Versions-That: xen=4de936a38aa96c946f5d39b2760abb8a9853cba3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 03 Apr 2020 12:33:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  009360acc9c90513e4a85c7285d4fd7a665c66e1
baseline version:
 xen                  4de936a38aa96c946f5d39b2760abb8a9853cba3

Last test of basis   149296  2020-04-01 17:00:36 Z    1 days
Testing same since   149382  2020-04-03 09:00:32 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  George Dunlap <george.dunlap@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Simran Singhal <singhalsimran0@gmail.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4de936a38a..009360acc9  009360acc9c90513e4a85c7285d4fd7a665c66e1 -> smoke


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 12:33:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 12:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKLVf-0002s8-JE; Fri, 03 Apr 2020 12:33:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=vylu=5T=sunlight.io=anastassios.nanos@srs-us1.protection.inumbo.net>)
 id 1jKLUt-0002qE-GY
 for xen-devel@lists.xen.org; Fri, 03 Apr 2020 12:32:31 +0000
X-Inumbo-ID: 2f02dcde-75a7-11ea-b58d-bc764e2007e4
Received: from mail-lj1-x22d.google.com (unknown [2a00:1450:4864:20::22d])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2f02dcde-75a7-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 12:32:30 +0000 (UTC)
Received: by mail-lj1-x22d.google.com with SMTP id g27so6693093ljn.10
 for <xen-devel@lists.xen.org>; Fri, 03 Apr 2020 05:32:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=sunlight-io.20150623.gappssmtp.com; s=20150623;
 h=mime-version:from:date:message-id:subject:to;
 bh=qIwH+SHm3ZZcmWD/07H3iQrvRIDI3cX7C5cR0fwI3ps=;
 b=uT7hIfTHWUT6CPJiUusm6m5CZ4mw/vUdPHwMxKwD2xRlvQv6odT4tDM0jBGRCvJalh
 szhL1XcI6d1VNocFUJo39GEdB1uNVVqO4L4qwKDZJvzWN+QUfSqB1b/vqCGc1j7G7Yxx
 7SK27NMp2QMpo5kQauKYtjbMZjhNiwW2czPI3rHiON1BeKFkk2z2q++PxMTm3Ya0pwsC
 CpFtf2spbYucsEhQCGg7rvUJOwdiBIWEFIUFWZxSew0Wx2U2xTi2hXOCQ2QHnkzmtrRm
 +SlEFjJKOPewvKgEPHa4T2jvc+2T0z9Ql8bz+7omDSrij8saIPtti+draXG3IWHdYlwS
 EJ4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=qIwH+SHm3ZZcmWD/07H3iQrvRIDI3cX7C5cR0fwI3ps=;
 b=dRVaLZnnl7to901N2l+biKXMp9lXoMadEF/72htehb4tS0MgVTZbo+9EpH5c7qbaTj
 QVxIh+zk1F1TcYNiX05DCcxg5j/CvIJNMFrT5AshHpBqumDyp6CzsS9pqxctqDWmHbUn
 cmU//k/55GVCKufqrytru63KuhH5k5mlNfCawxQodppJTVwTAbGh9gyCwzcdcfrGYNJz
 wFwa/Ld0udYK8TboiipoJ6MPlF/4Q9dc/2pyvNAQg2Ce4DDdZrxUdqr9E6s9pCVfioam
 2aG70xCbkr1SpeJsbYzfVg7fZs5WndV1sA9nxCSsvxKb9rpG3gqEJB/OdgG0T7cgS46t
 U39w==
X-Gm-Message-State: AGi0PuZ+cAukOOwSR0+c8MjntBopjbnw43puLrLjgKHy7aKLuiTkU/A4
 ZmenC14JvosyidQf9HjM56C9AlQgoW6oVwJfMcumLi5ENx9CHQ==
X-Google-Smtp-Source: APiQypKwUjh8jwD0zwgaG7bHwCkAmWPpf0O3UmLC14eehGdggxKOrF3WK+BH3kKA8wrQjWenc+VL2dm4BkQb4Hi9k14=
X-Received: by 2002:a05:651c:96:: with SMTP id 22mr4907093ljq.27.1585917148843; 
 Fri, 03 Apr 2020 05:32:28 -0700 (PDT)
MIME-Version: 1.0
From: Anastassios Nanos <anastassios.nanos@sunlight.io>
Date: Fri, 3 Apr 2020 15:32:17 +0300
Message-ID: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
Subject: Live migration and PV device handling
To: xen-devel@lists.xen.org
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Fri, 03 Apr 2020 12:33:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi all,

I am trying to understand how live-migration happens in xen. I am
looking in the HVM guest case and I have dug into the relevant parts
of the toolstack and the hypervisor regarding memory, vCPU context
etc.

In particular, I am interested in how PV device migration happens. I
assume that the guest is not aware of any suspend/resume operations
being done, nor do its PFNs need to change, so I suspect xenstore
device entries (for VIFs / VBDs) for the guest remain intact. However,
it is not entirely clear to me how xenstore entry migration happens.

As I am probably missing something obvious, could someone point me to
the part of the code where xenstore entries are being copied across to
the destination node?

thanks!
A.


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 12:43:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 12:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKLf0-0003p4-KE; Fri, 03 Apr 2020 12:42:58 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=okFK=5T=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jKLez-0003oz-FH
 for xen-devel@lists.xen.org; Fri, 03 Apr 2020 12:42:57 +0000
X-Inumbo-ID: a3e47dd6-75a8-11ea-bd06-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a3e47dd6-75a8-11ea-bd06-12813bfff9fa;
 Fri, 03 Apr 2020 12:42:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585917776;
 h=subject:to:references:from:message-id:date:mime-version:
 in-reply-to:content-transfer-encoding;
 bh=GB+UzNsb0WpNA5Fk9PHZBaIvSA7QPsTZnOv85s4Ksns=;
 b=eUNzJKg226b8rwXckmHdKrIjskIgcLfC+619zNtUoSI6SRBwXMOqj1d5
 C0c5HmyAE37iM8w+gzL6hc/eoBUDn3uqyNws7AB8mJXCceQZfkuZ9POAc
 InK5YTftBCEkuTnid9XRXIVIg+9PEqXztKV7QOuOOYzFazxVwBvgiW/qS 8=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: XAYd7pj08FBM3tUzRDNos8PJAI3MFLTUU6i4EBPNQZ2CxY0lLMl0mDL5f8I84afq0Y30Y2cSWr
 9pka7dt4VSE+jMzJFFeo1coIZrBzW3XwliIrhKrSfLYHvOZHa8odGjG1Uyf6mJGMsDLaEtY0HJ
 4/exBw1WPPuQWLiJeBx8BPCbwXbHq24bFLqzJSWHq3cjFrIHkRh88TL7rhP2asY44BnuPPWbuE
 82tqSZk3VQUmu5TloWs1mkc8p5VTGrWykr/F9jewTJZuwgnmltsjybUL1hLftgDJtryCmiIkvM
 GEE=
X-SBRS: 2.7
X-MesageID: 15452674
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,339,1580792400"; d="scan'208";a="15452674"
Subject: Re: Live migration and PV device handling
To: Anastassios Nanos <anastassios.nanos@sunlight.io>,
 <xen-devel@lists.xen.org>
References: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
Date: Fri, 3 Apr 2020 13:42:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 13:32, Anastassios Nanos wrote:
> Hi all,
>
> I am trying to understand how live-migration happens in xen. I am
> looking in the HVM guest case and I have dug into the relevant parts
> of the toolstack and the hypervisor regarding memory, vCPU context
> etc.
>
> In particular, I am interested in how PV device migration happens. I
> assume that the guest is not aware of any suspend/resume operations
> being done

Sadly, this assumption is not correct.  HVM guests with PV drivers
currently have to be aware in exactly the same way as PV guests.

Work is in progress to try and address this.  See
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=775a02452ddf3a6889690de90b1a94eb29c3c732
(sorry - for some reason that doc isn't being rendered properly in
https://xenbits.xen.org/docs/ )

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 13:17:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 13:17:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMCP-0006Jb-Cc; Fri, 03 Apr 2020 13:17:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=okFK=5T=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jKMCN-0006JW-PP
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 13:17:27 +0000
X-Inumbo-ID: 76156276-75ad-11ea-bd0e-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 76156276-75ad-11ea-bd0e-12813bfff9fa;
 Fri, 03 Apr 2020 13:17:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585919846;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=ALGvBdmFms4PYlnV2x24j5U+BD1c7rKpbBLtIR/PaNo=;
 b=KaCrRx4Gv3rqTTl1drAT+ItofgDo3K0Btab/iAitPFu+MpYrz3sPf/Ad
 x9xHYPJgK2uIiTE4bpLpqU7KbwaJvUX05VqWuJtdXlpfh03bXYOlUO1Ct
 p2HxJLQNxzBTavQEuFrO3jmRAYistjt0skFEXTHEpao+BFBJhajxOHh48 s=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: cWlfgwN6+VbQVN7Ngd1aAcZy/gYrCr7VgsECTdVCNgWDHbK0eb5lcHzy/A7DFMgslkNzAR1l6V
 I0513dxVlFZ7D91phcBSZBcR3sQ/2KXPhzbq+6NP3o/XAG0NyIX/tKGsXfVjsDb8i4CUPF4ulZ
 jXtcWXurtabtHeUdLtjMX854t+az2DA3EMu+8D3fH6fq+AnDCEyBy7uNPFfKRdljUSyaX59BzM
 ogyXlcYKEFYMUQZiAsPCC8uqMKB6pCMJlFECe/BV0IqIx2SfJMOs0cOhEhU9pUt0nfjl/pYsYe
 LCQ=
X-SBRS: 2.7
X-MesageID: 15538761
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,339,1580792400"; d="scan'208";a="15538761"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] docs: Render .md files using pandoc
Date: Fri, 3 Apr 2020 14:17:20 +0100
Message-ID: <20200403131720.30140-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <paul.durrant@citrix.com>, Ian
 Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This fixes the fact that qemu-deprivilege.md, non-cooperative-migration.md and
xenstore-migration.md don't currently get rendered at all, and are therefore
missing from xenbits.xen.org/docs

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: George Dunlap <George.Dunlap@eu.citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>

Ian - given qemu-deprivilege.md was in 4.12, this wants backporting.  It quite
possibly needs some intermediate prerequisites
---
 docs/Makefile | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index d8ba99b1dc..3eae2dae60 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -15,7 +15,7 @@ RST-SRC-y := $(sort $(filter-out %index.rst,$(shell find * -type f -name '*.rst'
 
 TXTSRC-y := $(sort $(shell find misc -name '*.txt' -print))
 
-PANDOCSRC-y := $(sort $(shell find designs/ features/ misc/ process/ specs/ -name '*.pandoc' -print))
+PANDOCSRC-y := $(sort $(shell find designs/ features/ misc/ process/ specs/ \( -name '*.pandoc' -o -name '*.md' \) -print))
 
 # Documentation targets
 $(foreach i,$(MAN_SECTIONS), \
@@ -24,15 +24,18 @@ $(foreach i,$(MAN_SECTIONS), \
 
 DOC_HTML := html/SUPPORT.html \
             $(patsubst %.pandoc,html/%.html,$(PANDOCSRC-y)) \
+            $(patsubst %.md,html/%.html,$(PANDOCSRC-y)) \
             $(patsubst %.rst,html/%.html,$(RST-SRC-y)) \
             $(patsubst %,html/%.html,$(MAN-SRC-y)) \
             $(patsubst %.txt,html/%.txt,$(TXTSRC-y)) \
             $(patsubst %,html/hypercall/%/index.html,$(DOC_ARCHES))
 DOC_TXT  := $(patsubst %.txt,txt/%.txt,$(TXTSRC-y)) \
             $(patsubst %.pandoc,txt/%.txt,$(PANDOCSRC-y)) \
+            $(patsubst %.md,txt/%.txt,$(PANDOCSRC-y)) \
             $(patsubst %.rst,txt/%.txt,$(RST-SRC-y)) \
             $(patsubst %,txt/%.txt,$(MAN-SRC-y))
 DOC_PDF  := $(patsubst %.pandoc,pdf/%.pdf,$(PANDOCSRC-y)) \
+            $(patsubst %.md,pdf/%.pdf,$(PANDOCSRC-y)) \
             $(patsubst %.rst,pdf/%.pdf,$(RST-SRC-y))
 
 # Top level build targets
@@ -228,12 +231,10 @@ define GENERATE_PANDOC_RULE
 # $(1) is the target documentation format. $(2) is the source format.
 $(call GENERATE_PANDOC_RULE_RAW,$(1)/%.$(1),%.$(2))
 endef
-$(eval $(call GENERATE_PANDOC_RULE,pdf,pandoc))   # pdf/%.pdf: %.pandoc
-$(eval $(call GENERATE_PANDOC_RULE,pdf,rst))      # pdf/%.pdf: %.rst
-$(eval $(call GENERATE_PANDOC_RULE,txt,pandoc))   # txt/%.txt: %.pandoc
-$(eval $(call GENERATE_PANDOC_RULE,txt,rst))      # txt/%.txt: %.rst
-$(eval $(call GENERATE_PANDOC_RULE,html,pandoc))  # html/%.html: %.pandoc
-$(eval $(call GENERATE_PANDOC_RULE,html,rst))     # html/%.html: %.rst
+
+$(foreach dst-fmt,pdf txt html,\
+$(foreach src-fmt,pandoc md rst,\
+$(eval $(call GENERATE_PANDOC_RULE,$(dst-fmt),$(src-fmt)))))
 
 $(eval $(call GENERATE_PANDOC_RULE_RAW,html/SUPPORT.html,$(XEN_ROOT)/SUPPORT.md))
 
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 13:37:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 13:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMVJ-0007vx-19; Fri, 03 Apr 2020 13:37:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKMVH-0007vs-EK
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 13:36:59 +0000
X-Inumbo-ID: 30c385ec-75b0-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 30c385ec-75b0-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 13:36:58 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 497B8AC53;
 Fri,  3 Apr 2020 13:36:56 +0000 (UTC)
Subject: Re: [PATCH 1/5] x86/ucode/intel: Remove CPUID from collect_cpu_info()
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
 <20200402101902.28234-2-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <471c3ec6-ba9a-add7-aa9a-77bb800c01ad@suse.com>
Date: Fri, 3 Apr 2020 15:36:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200402101902.28234-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 12:18, Andrew Cooper wrote:
> The CPUID instruction is expensive.  No point executing it twice when once
> will do fine.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
albeit ...

> --- a/xen/arch/x86/cpu/microcode/intel.c
> +++ b/xen/arch/x86/cpu/microcode/intel.c
> @@ -121,14 +121,12 @@ static int collect_cpu_info(struct cpu_signature *csig)
>  
>      memset(csig, 0, sizeof(*csig));
>  
> -    csig->sig = cpuid_eax(0x00000001);
> -
>      rdmsrl(MSR_IA32_PLATFORM_ID, msr_content);
>      csig->pf = 1 << ((msr_content >> 50) & 7);
>  
>      wrmsrl(MSR_IA32_UCODE_REV, 0x0ULL);
>      /* As documented in the SDM: Do a CPUID 1 here */
> -    cpuid_eax(1);
> +    csig->sig = cpuid_eax(1);

... with this, perhaps make the title say "remove one CPUID ..."
or some such?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 13:38:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 13:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMX2-00081k-Dm; Fri, 03 Apr 2020 13:38:48 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKMX1-00081f-Um
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 13:38:47 +0000
X-Inumbo-ID: 70b4c4e0-75b0-11ea-bd11-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 70b4c4e0-75b0-11ea-bd11-12813bfff9fa;
 Fri, 03 Apr 2020 13:38:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B12E9ADBE;
 Fri,  3 Apr 2020 13:38:44 +0000 (UTC)
Subject: Re: [PATCH 2/5] x86/ucode: Drop ops->match_cpu()
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
 <20200402101902.28234-3-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <9f1dfa7a-056e-2753-14a6-dbf5e3a990db@suse.com>
Date: Fri, 3 Apr 2020 15:38:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200402101902.28234-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 12:18, Andrew Cooper wrote:
> It turns out there are no callers of the hook().  The only callers are the
> local, which can easily be rearranged to use the appropriate internal helper.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 13:42:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 13:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMad-0000PK-1g; Fri, 03 Apr 2020 13:42:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKMac-0000PF-7N
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 13:42:30 +0000
X-Inumbo-ID: f614a808-75b0-11ea-bd15-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f614a808-75b0-11ea-bd15-12813bfff9fa;
 Fri, 03 Apr 2020 13:42:29 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0DE0BAC92;
 Fri,  3 Apr 2020 13:42:28 +0000 (UTC)
Subject: Re: [PATCH 3/5] x86/ucode: Don't try to cope with NULL pointers in
 apply_microcode()
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
 <20200402101902.28234-4-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6940bb7b-9fc4-b5c5-15d4-d44e0e2c758d@suse.com>
Date: Fri, 3 Apr 2020 15:42:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200402101902.28234-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 12:19, Andrew Cooper wrote:
> No paths to apply_microcode() pass a NULL pointer, and other hooks don't
> tolerate one in the first place.  We can expect the core logic not to pass us
> junk, so drop the checks.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 13:44:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 13:44:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMcr-0000Wo-FK; Fri, 03 Apr 2020 13:44:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKMcp-0000Wj-Pt
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 13:44:47 +0000
X-Inumbo-ID: 47f657de-75b1-11ea-bd15-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 47f657de-75b1-11ea-bd15-12813bfff9fa;
 Fri, 03 Apr 2020 13:44:47 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D4D3AABD1;
 Fri,  3 Apr 2020 13:44:45 +0000 (UTC)
Subject: Re: [PATCH 4/5] x86/ucode: Drop ops->free_patch()
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
 <20200402101902.28234-5-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <5c77bdb4-e8c7-f064-83dc-2a538381e602@suse.com>
Date: Fri, 3 Apr 2020 15:44:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200402101902.28234-5-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 12:19, Andrew Cooper wrote:
> With the newly cleaned up vendor logic, each struct microcode_patch is a
> trivial object in memory with no dependent allocations.
> 
> This is unlikely to change moving forwards, and function pointers are
> expensive in the days of retpoline.  Move the responsibility to xfree() back
> to common code.  If the need does arise in the future, we can consider
> reintroducing the hook.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

Yet with the given argumentation, ...

> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -243,9 +243,9 @@ static struct microcode_patch *parse_blob(const char *buf, size_t len)
>      return NULL;
>  }
>  
> -static void microcode_free_patch(struct microcode_patch *microcode_patch)
> +static void microcode_free_patch(struct microcode_patch *patch)
>  {
> -    microcode_ops->free_patch(microcode_patch);
> +    xfree(patch);
>  }

... drop this wrapper as well? (R-b would also cover this)

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 13:46:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 13:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMeN-0000cs-RD; Fri, 03 Apr 2020 13:46:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKMeM-0000ck-HC
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 13:46:22 +0000
X-Inumbo-ID: 804676c9-75b1-11ea-bd15-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 804676c9-75b1-11ea-bd15-12813bfff9fa;
 Fri, 03 Apr 2020 13:46:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 589ECABD1;
 Fri,  3 Apr 2020 13:46:20 +0000 (UTC)
Subject: Re: [PATCH 5/5] x86/ucode: Simplify the ops->collect_cpu_info() API
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200402101902.28234-1-andrew.cooper3@citrix.com>
 <20200402101902.28234-6-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <9c985396-171d-a216-28ec-2daa62150343@suse.com>
Date: Fri, 3 Apr 2020 15:46:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200402101902.28234-6-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 12:19, Andrew Cooper wrote:
> All callers pass &this_cpu(cpu_sig) for the cpu_sig parameter, and all
> implementations unconditionally return 0.  Simplify it to be void.
> 
> Drop the long-stale comment on the AMD side, whose counterpart in
> start_update() used to be "collect_cpu_info() doesn't fail so we're fine".
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 13:49:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 13:49:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMhG-0000m8-AO; Fri, 03 Apr 2020 13:49:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DmfO=5T=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jKMhF-0000m2-Dm
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 13:49:21 +0000
X-Inumbo-ID: eb237644-75b1-11ea-9e09-bc764e2007e4
Received: from mail-ed1-x52e.google.com (unknown [2a00:1450:4864:20::52e])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id eb237644-75b1-11ea-9e09-bc764e2007e4;
 Fri, 03 Apr 2020 13:49:20 +0000 (UTC)
Received: by mail-ed1-x52e.google.com with SMTP id de14so9336956edb.4
 for <xen-devel@lists.xenproject.org>; Fri, 03 Apr 2020 06:49:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=1gfGhVWQXF8hIlG98IuWvoaZAaf3WHOr2ahCGfB2wqQ=;
 b=C1KQZMQ0SJY6zAU+5APpyt39G8J5JVq/J99oyoBlZhq2YXHhlM8NjVZY6dGUaHxWAF
 NYO8jr4vuFyJKYDFVH4vvA/CWF+/jDHMaViHVSY9dbeh/EY2+Uk8qIVOX79dsdtMn8sV
 fQB025kDJclZsk5GfMWq6Tfo/x85jVdbS82+GK6rCh75s2phmT7qE0jmJbM6N3UJslYF
 /LBFnDhxoHRRzB09w4ecMpsHVhtRIjp19O984Cf1g4Z3ejhiSPyPxyPo9t/MVW59rQmv
 HL2NsYIjFhKSitnqJcw3dyh71I7JzIl3V0P9P5W4OPO0sntgYmL5pTWv2Sl22Ru+uYh7
 PR8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=1gfGhVWQXF8hIlG98IuWvoaZAaf3WHOr2ahCGfB2wqQ=;
 b=D0PtlvnkWD0AbP56ov2zcZJ7ceZWOQmuxFvUg8A4ue5yd/om5QD+1Z26fcfkFgaxTa
 07UaQhPmObhoF/ZROwqHk8v53PHboP7hswYpZ/1czOZFDMMzaMtPKJguumOKrsc5JlhJ
 0d574pQZUFRYsq5BHS7jOLRLcviYvY9tTP2tuL9q5gl7I3acLZLX6uDHeFaTNWrQOUoa
 XRsahQvGy++cHpXKk41xy1D0Kbol6WTO19a8g5OlTBOo3o9//FA9q6tagP37Zyeq+SAh
 0XQSxK8nPJULE1OnFYqzOUATmG0OP5KP52tMnrElRDQOMsmiGNXX8fshwYcbEQ+BEFgD
 aPZg==
X-Gm-Message-State: AGi0PubtuVe5Y75GW635RL+cgxPJBqIkCyAPNQPvQqhsypzAx6UP6IcF
 uwn30eXKUAwOzSaYUCJJtpg=
X-Google-Smtp-Source: APiQypIlwiGMdrGhWSuLt7+LBl3g8EASwrqCQgok0i/osWMzUXHNlg65lUJZsdlqHuc70kaEmHR0Lg==
X-Received: by 2002:aa7:c812:: with SMTP id a18mr7594330edt.213.1585921759949; 
 Fri, 03 Apr 2020 06:49:19 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id gl25sm1651756ejb.18.2020.04.03.06.49.18
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 03 Apr 2020 06:49:19 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Andrew Cooper'" <andrew.cooper3@citrix.com>,
 "'Xen-devel'" <xen-devel@lists.xenproject.org>
References: <20200403131720.30140-1-andrew.cooper3@citrix.com>
In-Reply-To: <20200403131720.30140-1-andrew.cooper3@citrix.com>
Subject: RE: [PATCH] docs: Render .md files using pandoc
Date: Fri, 3 Apr 2020 14:49:17 +0100
Message-ID: <000b01d609be$ac4975e0$04dc61a0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQENksyss/2rMKILJ7OFcY8p7A1SCKn4V1oQ
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'George Dunlap' <George.Dunlap@eu.citrix.com>,
 'Ian Jackson' <ian.jackson@citrix.com>,
 'Paul Durrant' <paul.durrant@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Andrew Cooper
> Sent: 03 April 2020 14:17
> To: Xen-devel <xen-devel@lists.xenproject.org>
> Cc: George Dunlap <George.Dunlap@eu.citrix.com>; Andrew Cooper <andrew.cooper3@citrix.com>; Paul
> Durrant <paul.durrant@citrix.com>; Ian Jackson <ian.jackson@citrix.com>
> Subject: [PATCH] docs: Render .md files using pandoc
> 
> This fixes the fact that qemu-deprivilege.md, non-cooperative-migration.md and
> xenstore-migration.md don't currently get rendered at all, and are therefore
> missing from xenbits.xen.org/docs
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: George Dunlap <George.Dunlap@eu.citrix.com>
> CC: Paul Durrant <paul.durrant@citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>
> 

Reviewed-by: Paul Durrant <paul@xen.org>



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 13:53:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 13:53:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMlV-0001Yi-UL; Fri, 03 Apr 2020 13:53:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKMlU-0001YB-LE
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 13:53:44 +0000
X-Inumbo-ID: 88050d1a-75b2-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 88050d1a-75b2-11ea-83d8-bc764e2007e4;
 Fri, 03 Apr 2020 13:53:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A3FC7AC92;
 Fri,  3 Apr 2020 13:53:42 +0000 (UTC)
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: Igor Druzhinin <igor.druzhinin@citrix.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
Date: Fri, 3 Apr 2020 15:53:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com,
 ian.jackson@eu.citrix.com, wl@xen.org, andrew.cooper3@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 18:18, Igor Druzhinin wrote:
> The area just below 4G where OVMF image is originally relocated is not
> necessarily a hole - it might contain pages preallocated by device model
> or the toolstack. By unconditionally populating on top of this memory
> the original pages are getting lost while still potentially foreign mapped
> in Dom0.

When there are pre-allocated pages - have they been orphaned? If
so, shouldn't whoever populated them unpopulate rather than
orphaning them? Or if not - how is the re-use you do safe?

> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -398,6 +398,20 @@ int get_mem_mapping_layout(struct e820entry entries[], uint32_t *max_entries)
>      return rc;
>  }
>  
> +bool mem_probe_ram(xen_pfn_t mfn)
> +{
> +    uint32_t tmp, magic = 0xdeadbeef;
> +    volatile uint32_t *addr = (volatile uint32_t *)(mfn << PAGE_SHIFT);
> +
> +    tmp = *addr;
> +    *addr = magic;
> +    if ( *addr != magic )
> +        return 0;
> +
> +    *addr = tmp;
> +    return 1;
> +}

This looks to probe r/o behavior. If there was a ROM page pre-populated,
wouldn't it then be equally lost once you populate RAM over it? And what
if this is MMIO, i.e. writable but potentially with side effects?

Whether, as you suggest as an alternative, moving populating of this
space to the tool stack is feasible I don't know. If it was, I would
wonder though why it wasn't done like this in the first place.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 13:56:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 13:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMo9-0001fH-CJ; Fri, 03 Apr 2020 13:56:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fKXS=5T=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKMo7-0001fA-Hw
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 13:56:27 +0000
X-Inumbo-ID: e97ecc5c-75b2-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e97ecc5c-75b2-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 13:56:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=w84CXMC3FKYEcCVHoyoaUvM9qcB1pc+leYSMRQEjsUE=; b=mcyL48QgRsa0BAlyz/2mAYGIRJ
 6s8Cia7z914aGUYQYRvXmaz5Sqy/uOHH8pOSOBzMmG49NaQ2NVOd9D1s+xp6JfaXXSdTnZ/iZqU8K
 VtV2g/JjMYVvJIWlPY7QyZ3BpLpmAFjCgdPmoH5AEqPjYN3aIEmYG3s3h4ay846Z2/Pg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKMo5-00083y-Va; Fri, 03 Apr 2020 13:56:25 +0000
Received: from 54-240-197-238.amazon.com ([54.240.197.238]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKMo5-0002ar-P1; Fri, 03 Apr 2020 13:56:25 +0000
Subject: Re: [PATCH v2] tools/xenstore: fix a use after free problem in
 xenstored
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
References: <20200403120340.13406-1-jgross@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <4a934636-3441-42eb-744a-3421eebb6c86@xen.org>
Date: Fri, 3 Apr 2020 14:56:24 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200403120340.13406-1-jgross@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Juergen,

On 03/04/2020 13:03, Juergen Gross wrote:
> Commit 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object
> twice") introduced a potential use after free problem in
> domain_cleanup(): after calling talloc_unlink() for domain->conn
> domain->conn is set to NULL. The problem is that domain is registered
> as talloc child of domain->conn, so it might be freed by the
> talloc_unlink() call.
> 
> With Xenstore being single threaded there are normally no concurrent
> memory allocations running and freeing a virtual memory area normally
> doesn't result in that area no longer being accessible. A problem
> could occur only in case either a signal received results in some
> memory allocation done in the signal handler (SIGHUP is a primary
> candidate leading to reopening the log file), or in case the talloc
> framework would do some internal memory allocation during freeing of
> the memory (which would lead to clobbering of the freed domain
> structure).

Thank you for writing more context!

> 
> Fixes: 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object twice")
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:05:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:05:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKMws-0002b8-At; Fri, 03 Apr 2020 14:05:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKMwq-0002b3-D6
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:05:28 +0000
X-Inumbo-ID: 2b8471aa-75b4-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2b8471aa-75b4-11ea-9e09-bc764e2007e4;
 Fri, 03 Apr 2020 14:05:27 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 49AD4ADE8;
 Fri,  3 Apr 2020 14:05:26 +0000 (UTC)
Subject: Re: [PATCH v7 01/12] xen/vmx: let opt_ept_ad always reflect the
 current setting
To: Juergen Gross <jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-2-jgross@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <ad4beba2-3759-bd86-f6e3-670683083b0a@suse.com>
Date: Fri, 3 Apr 2020 16:05:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200402154616.16927-2-jgross@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 17:46, Juergen Gross wrote:
> In case opt_ept_ad has not been set explicitly by the user via command
> line or runtime parameter, it is treated as "no" on Avoton cpus.
> 
> Change that handling by setting opt_ept_ad to 0 for this cpu type
> explicitly if no user value has been set.
> 
> By putting this into the (renamed) boot time initialization of vmcs.c
> _vmx_cpu_up() can be made static.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
albeit preferably with ...

> @@ -2108,9 +2104,21 @@ static void vmcs_dump(unsigned char ch)
>      printk("**************************************\n");
>  }
>  
> -void __init setup_vmcs_dump(void)
> +int __init vmx_vmcs_init(void)
>  {
> -    register_keyhandler('v', vmcs_dump, "dump VT-x VMCSs", 1);
> +    int ret;
> +
> +    if ( opt_ept_ad < 0 )
> +        /* Work around Erratum AVR41 on Avoton processors. */
> +        opt_ept_ad = (boot_cpu_data.x86 == 6 &&
> +                      boot_cpu_data.x86_model == 0x4d) ? 0 : 1;

... no use of the conditional operator here - the result of the
&& (or its logical inversion to be precise) would be quite fine
to use directly here.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:18:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKN8n-0003Vw-HC; Fri, 03 Apr 2020 14:17:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=i4CN=5T=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKN8m-0003Vr-E9
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:17:48 +0000
X-Inumbo-ID: e40ec576-75b5-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e40ec576-75b5-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 14:17:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=8BMEgmhgnewQ1mEPpwptkXmTVbrPfpFCg19kCTuLyHw=; b=OL0g0PvRxnCO3MBqDnWGFfe6/
 kGHLrKyJFqp1P0oJO6RAjLBD10Dcj85ZboRtUaHIFv7v473TEmN+PSpCvmNdi9Uyrkqp4Iahx5KTB
 d+wOUDQBLWQZ80Hl4346LW4j8fnL8QibBHtJqFYEnLwx6nXnuRWjuXZGZHWMedU2yyCMg=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKN8k-000073-4w; Fri, 03 Apr 2020 14:17:46 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKN8j-0005fZ-T3; Fri, 03 Apr 2020 14:17:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKN8j-0006t5-SQ; Fri, 03 Apr 2020 14:17:45 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149361-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149361: regressions - FAIL
X-Osstest-Failures: linux-5.4:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:regression
 linux-5.4:test-amd64-amd64-xl-rtds:guest-saverestore:fail:allowable
 linux-5.4:test-amd64-amd64-dom0pvh-xl-intel:guest-start:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=ad13e142e024aa194016a32de8b9ba058fe9a6af
X-Osstest-Versions-That: linux=122179cb7d648a6f36b20dd6bf34f953cb384c30
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 03 Apr 2020 14:17:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     15 guest-saverestore        fail REGR. vs. 146121

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 12 guest-start        fail baseline untested
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                ad13e142e024aa194016a32de8b9ba058fe9a6af
baseline version:
 linux                122179cb7d648a6f36b20dd6bf34f953cb384c30

Last test of basis   146121  2020-01-15 17:42:04 Z   78 days
Failing since        146178  2020-01-17 02:59:07 Z   77 days  104 attempts
Testing same since   149361  2020-04-02 21:09:16 Z    0 days    1 attempts

------------------------------------------------------------
1482 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:23:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:23:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNE6-0004Jz-BV; Fri, 03 Apr 2020 14:23:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKNE5-0004Ju-FW
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:23:17 +0000
X-Inumbo-ID: a8ba2f14-75b6-11ea-bd25-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a8ba2f14-75b6-11ea-bd25-12813bfff9fa;
 Fri, 03 Apr 2020 14:23:16 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4CD91AE2A;
 Fri,  3 Apr 2020 14:23:15 +0000 (UTC)
Subject: Re: [PATCH v7 04/12] xen: add basic hypervisor filesystem support
To: Juergen Gross <jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-5-jgross@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7dda5c2c-cb81-2cfa-2cf4-4440b49d401a@suse.com>
Date: Fri, 3 Apr 2020 16:23:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200402154616.16927-5-jgross@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 17:46, Juergen Gross wrote:
> Add the infrastructure for the hypervisor filesystem.
> 
> This includes the hypercall interface and the base functions for
> entry creation, deletion and modification.
> 
> In order not to have to repeat the same pattern multiple times in case
> adding a new node should BUG_ON() failure, the helpers for adding a
> node (hypfs_add_dir() and hypfs_add_leaf()) get a nofault parameter
> causing the BUG() in case of a failure.
> 
> When supporting writable leafs the entry's write pointer will need to
> be set to the function performing the write to the variable holding the
> content. In case there are no special constraints this will be
> hypfs_write_bool() for type XEN_HYPFS_TYPE_BOOL and hypfs_write_leaf()
> for the other entry types.

Seeing your HYPFS_*_INIT_WRITABLE() macros I find this a pretty
strange requirement. Why can't the macros set the write hook right
away?

> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
> +                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
> +{
> +    char *buf;
> +    int ret;
> +
> +    if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
> +         leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
> +        return -EDOM;
> +
> +    buf = xmalloc_array(char, ulen);
> +    if ( !buf )
> +        return -ENOMEM;
> +
> +    ret = -EFAULT;
> +    if ( copy_from_guest(buf, uaddr, ulen) )
> +        goto out;
> +
> +    ret = -EINVAL;
> +    if ( leaf->e.type == XEN_HYPFS_TYPE_STRING &&
> +         memchr(buf, 0, ulen) != (buf + ulen - 1) )
> +        goto out;
> +
> +    ret = 0;
> +    memcpy(leaf->write_ptr, buf, ulen);
> +    leaf->e.size = ulen;
> +
> + out:
> +    xfree(buf);
> +    return ret;
> +}
> +
> +int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
> +                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
> +{
> +    bool buf;
> +
> +    ASSERT(leaf->e.type == XEN_HYPFS_TYPE_BOOL && leaf->e.size == sizeof(bool));
> +
> +    if ( ulen != leaf->e.max_size )

Why max_size here when the ASSERT() checks size?

> +static int hypfs_write(struct hypfs_entry *entry,
> +                       XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
> +{
> +    struct hypfs_entry_leaf *l;
> +
> +    if ( !entry->write )
> +        return -EACCES;
> +
> +    if ( ulen > entry->max_size )
> +        return -ENOSPC;

max_size being zero for non-writable entries, perhaps use -EACCES
also for this special case? Together with the other comment above,
maybe the ->write check wants replacing this way?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:27:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:27:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNHi-0004TF-Sx; Fri, 03 Apr 2020 14:27:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=WUFr=5T=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jKNHh-0004TA-Qx
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:27:01 +0000
X-Inumbo-ID: 2e012966-75b7-11ea-83d8-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2e012966-75b7-11ea-83d8-bc764e2007e4;
 Fri, 03 Apr 2020 14:27:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585924020;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=+JDTvp8Ze6MUvEypihfG/WO0Xnj9Z8kpr9YO5/Wn3A8=;
 b=UEOiomKQSQB7iHZlBJeloWAddNeaLvDrzBhFn6v+rXeiOphtpcG86T0e
 D9lyEx0CCpmmlnTdbb907RZuLcyRcIW73EB3xzBJdKmR7vXFGLsxHFLCi
 aJ/l4xBtrcre2E7oIBHeXqtORK4wzpbluclRn6h8AOFbLq7lDUy2soB9d k=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: l2E2TzRhEu10W9YQR353fk4jcfvYm6ByTkoGDZJ2EyQHJRZ+KOYDOD0WbRaYNaqB3GucbNPMjn
 NPhszXjwnrumCC7HIggRtZEyR0Miqtz3K2u6Q/M1nd/g66gAJ0xYpYrNvkIqRoTgnUwQFcpFRd
 ufG/PRNus7Qw4LEnknnMsG+VJd2dQQtM01Ah+JPHI39d0wliAN1iUkLybleIhXqOIxufQdOJZ/
 Ze2HZxiTWZw8NdT8yiwidzfS6NBwRZXKkZxdffXyXlMHPss215n6kepRadxVZhTfyg1JaooAxf
 8Os=
X-SBRS: 2.7
X-MesageID: 15799997
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15799997"
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: Jan Beulich <jbeulich@suse.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
 <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <bf83ee24-8516-f18c-fabb-0ff2718bf8f5@citrix.com>
Date: Fri, 3 Apr 2020 15:26:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com,
 ian.jackson@eu.citrix.com, wl@xen.org, andrew.cooper3@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 14:53, Jan Beulich wrote:
> On 02.04.2020 18:18, Igor Druzhinin wrote:
>> The area just below 4G where OVMF image is originally relocated is not
>> necessarily a hole - it might contain pages preallocated by device model
>> or the toolstack. By unconditionally populating on top of this memory
>> the original pages are getting lost while still potentially foreign mapped
>> in Dom0.
> 
> When there are pre-allocated pages - have they been orphaned? If
> so, shouldn't whoever populated them unpopulate rather than
> orphaning them? Or if not - how is the re-use you do safe?

There is no signal to the device model when that happens - it has no idea when the
memory it populated and hold a mapping to becomes suddenly unmapped in the guest.
Re-use is safe as the memory prepopulated before OVMF starts has not been put
in use yet until after it's finished initializing.

>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -398,6 +398,20 @@ int get_mem_mapping_layout(struct e820entry entries[], uint32_t *max_entries)
>>      return rc;
>>  }
>>  
>> +bool mem_probe_ram(xen_pfn_t mfn)
>> +{
>> +    uint32_t tmp, magic = 0xdeadbeef;
>> +    volatile uint32_t *addr = (volatile uint32_t *)(mfn << PAGE_SHIFT);
>> +
>> +    tmp = *addr;
>> +    *addr = magic;
>> +    if ( *addr != magic )
>> +        return 0;
>> +
>> +    *addr = tmp;
>> +    return 1;
>> +}
> 
> This looks to probe r/o behavior. If there was a ROM page pre-populated,
> wouldn't it then be equally lost once you populate RAM over it? And what
> if this is MMIO, i.e. writable but potentially with side effects?

I assume if the pages behind it are not r/w there is no other way to avoid
crashing immediately except go and repopulate on top. MMIO is a problematic
corner case I expect device model would try to avoid.

> Whether, as you suggest as an alternative, moving populating of this
> space to the tool stack is feasible I don't know. If it was, I would
> wonder though why it wasn't done like this in the first place.

I expect one complication is to know the type of firmware at the moment
domain is constructed to make sure area is populated for OVMF only. 

Igor



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:28:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:28:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNJW-0004a4-Be; Fri, 03 Apr 2020 14:28:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=i4CN=5T=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKNJU-0004Zx-AI
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:28:52 +0000
X-Inumbo-ID: 6d5f194c-75b7-11ea-bd27-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6d5f194c-75b7-11ea-bd27-12813bfff9fa;
 Fri, 03 Apr 2020 14:28:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=8NpkJX0zP0Ita39Ld9KN5NSZYoFkW28/iZYSaPyoKG8=; b=ZLH6VV0Y+7tUbq6imwbh1GlM6
 h9NZXkF3EWZ2xfjT3uwNC/yEoRfczkmTb+ot4VzRdSyc13MqBFKJSHNmKJJujJ9qFi+1FDFg9TIdC
 f3zYcp3ONLhtyvF8MCDJWAx9SpcMnWpuwh2/KYKyAYVrBvSnqkE+fZxSEkc7S5jTOMfPk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKNJO-0000Kl-3G; Fri, 03 Apr 2020 14:28:46 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKNJN-0005z5-PN; Fri, 03 Apr 2020 14:28:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKNJN-00052k-Oq; Fri, 03 Apr 2020 14:28:45 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149368-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149368: all pass - PUSHED
X-Osstest-Versions-This: ovmf=f73c9adfc68c7ff189b17cb2531a071d4b30cd75
X-Osstest-Versions-That: ovmf=4deef2d865efdc61d1a53ad7bd48f9dd42560b45
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 03 Apr 2020 14:28:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 f73c9adfc68c7ff189b17cb2531a071d4b30cd75
baseline version:
 ovmf                 4deef2d865efdc61d1a53ad7bd48f9dd42560b45

Last test of basis   149325  2020-04-02 09:40:07 Z    1 days
Testing same since   149368  2020-04-03 00:10:25 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@arm.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   4deef2d865..f73c9adfc6  f73c9adfc68c7ff189b17cb2531a071d4b30cd75 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:31:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNLg-0005Jj-Pj; Fri, 03 Apr 2020 14:31:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKNLf-0005Jd-PT
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:31:07 +0000
X-Inumbo-ID: c12311c8-75b7-11ea-bd27-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c12311c8-75b7-11ea-bd27-12813bfff9fa;
 Fri, 03 Apr 2020 14:31:07 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 48F22AEE7;
 Fri,  3 Apr 2020 14:31:05 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: Juergen Gross <jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
Date: Fri, 3 Apr 2020 16:31:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200402154616.16927-9-jgross@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 17:46, Juergen Gross wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -353,6 +353,16 @@ config DOM0_MEM
>  
>  	  Leave empty if you are not sure what to specify.
>  
> +config HYPFS_CONFIG
> +	bool "Provide hypervisor .config via hypfs entry"
> +	default y

My initial reaction was to ask for "depends on HYPFS", but then
I noticed the earlier patch doesn't introduce such. Am I
mis-remembering that it was agreed to make the whole thing
possible to disable at least in EXPERT mode?

> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -389,6 +389,16 @@ static HYPFS_STRING_INIT(compile_date, "compile_date");
>  static HYPFS_STRING_INIT(compile_domain, "compile_domain");
>  static HYPFS_STRING_INIT(extra, "extra");
>  
> +#ifdef CONFIG_HYPFS_CONFIG
> +static struct hypfs_entry_leaf config = {
> +    .e.type = XEN_HYPFS_TYPE_STRING,
> +    .e.encoding = XEN_HYPFS_ENC_GZIP,
> +    .e.name = "config",
> +    .e.read = hypfs_read_leaf,
> +    .content = &xen_config_data
> +};
> +#endif

Would be really good if no open-coded instantiations like this
one would ever have to appear, i.e. if suitable macros were
available. What's preventing use of one of the available ones
here?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:34:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:34:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNOm-0005SD-9R; Fri, 03 Apr 2020 14:34:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKNOl-0005S6-7k
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:34:19 +0000
X-Inumbo-ID: 332ba17c-75b8-11ea-bd27-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 332ba17c-75b8-11ea-bd27-12813bfff9fa;
 Fri, 03 Apr 2020 14:34:18 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 69423AC1D;
 Fri,  3 Apr 2020 14:34:17 +0000 (UTC)
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: Igor Druzhinin <igor.druzhinin@citrix.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
 <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
 <bf83ee24-8516-f18c-fabb-0ff2718bf8f5@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <66e112f8-eab5-6aa7-c94b-81ddbeca3c2e@suse.com>
Date: Fri, 3 Apr 2020 16:34:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <bf83ee24-8516-f18c-fabb-0ff2718bf8f5@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com,
 ian.jackson@eu.citrix.com, wl@xen.org, andrew.cooper3@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 16:26, Igor Druzhinin wrote:
> On 03/04/2020 14:53, Jan Beulich wrote:
>> On 02.04.2020 18:18, Igor Druzhinin wrote:
>>> The area just below 4G where OVMF image is originally relocated is not
>>> necessarily a hole - it might contain pages preallocated by device model
>>> or the toolstack. By unconditionally populating on top of this memory
>>> the original pages are getting lost while still potentially foreign mapped
>>> in Dom0.
>>
>> When there are pre-allocated pages - have they been orphaned? If
>> so, shouldn't whoever populated them unpopulate rather than
>> orphaning them? Or if not - how is the re-use you do safe?
> 
> There is no signal to the device model when that happens - it has no idea when the
> memory it populated and hold a mapping to becomes suddenly unmapped in the guest.
> Re-use is safe as the memory prepopulated before OVMF starts has not been put
> in use yet until after it's finished initializing.

I guess I'm lacking some details here to fully understand what
you're saying: What is it that may pre-populate this range, and
for what purpose?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:39:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNTX-0005cx-SY; Fri, 03 Apr 2020 14:39:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=okFK=5T=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jKNTW-0005cs-AE
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:39:14 +0000
X-Inumbo-ID: e2a317e8-75b8-11ea-bd27-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e2a317e8-75b8-11ea-bd27-12813bfff9fa;
 Fri, 03 Apr 2020 14:39:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585924754;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=2nvEJHeM+uXlBJ87GOBlwG0eiQdSw+zqUjpprZ9Q7aE=;
 b=d19B4Kilbryt20Wr1TFptUqeUvyPRy9uBqAdyC6oiP0DQSw8V4yniawE
 l2q6w3+vy3+CGljewS6eOswYIGmpZAqWmKgU8n1OToFl9VYkRvmZJepvn
 OAMlsbdA2QxDQLFe1cCniW4twtJu5Z6AM10mwwSdAZwkt/kKFmRxQ/1pg w=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 2MPmqgVlZ3I3Ef6wR0V47l6Ex1G2VK82QZn/C8Kc7am+zLeN+xHjG7eyYquoo2BIPnl4O1Vu14
 Q/+jgLe4tkwONcxkkQtLVJsPUZkRlBaZOwBRhDrAWsZkNVkEhUX2Ve3kECRqtxdWxdLa/csgbc
 FCXm+YeMwZujLg59sfGTTl1Yas6KKH168hBf4KJfXJ0xpTGWqaKXLPWP1xz634fKPHm+fDThyF
 hCkAIcpKIhGtGgtnNNDp8PlYgYZsvcGV/wU0EaE7tWelMtJfyZofa3gpksj7eD2CHf13z1oTps
 Bwg=
X-SBRS: 2.7
X-MesageID: 15148598
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15148598"
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: Jan Beulich <jbeulich@suse.com>, Igor Druzhinin <igor.druzhinin@citrix.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
 <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <0faaee38-e314-24a8-b97d-9f000251a63e@citrix.com>
Date: Fri, 3 Apr 2020 15:39:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, wl@xen.org,
 roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 14:53, Jan Beulich wrote:
> On 02.04.2020 18:18, Igor Druzhinin wrote:
>> The area just below 4G where OVMF image is originally relocated is not
>> necessarily a hole - it might contain pages preallocated by device model
>> or the toolstack. By unconditionally populating on top of this memory
>> the original pages are getting lost while still potentially foreign mapped
>> in Dom0.
> When there are pre-allocated pages - have they been orphaned? If
> so, shouldn't whoever populated them unpopulate rather than
> orphaning them? Or if not - how is the re-use you do safe?

So this is a mess.

OVMF is linked to run at a fixed address suitable for native hardware,
which is in the SPI ROM immediately below the 4G boundary (this is
correct).  We also put the framebuffer there (this is not correct).

This was fine for RomBIOS which is located under the 1M boundary.

It is also fine for a fully-emulated VGA device in Qemu, because the the
framebuffer if moved (re-set up actually) when the virtual BAR is moved,
but with a real GPU (SR-IOV in this case), there is no logic to play games.

The problem is entirely caused by the framebuffer in Xen not being like
any real system.  The framebuffer isn't actually in a BAR, and also
doesn't manifest itself in the way that graphics-stolen-ram normally
does, either.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:40:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:40:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNUd-0006KT-89; Fri, 03 Apr 2020 14:40:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=okFK=5T=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jKNUc-0006KL-0o
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:40:22 +0000
X-Inumbo-ID: 0a29cb72-75b9-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0a29cb72-75b9-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 14:40:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585924819;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=08R1lHZV/ONCIf1geiqFMi7ViO+irupyRbwZQRZvMjU=;
 b=Yvf9CRI1dXd/+EguJiY1rZi6zvJlAsgYsz9p1tqZzANAylmXpjpoJfia
 76f2n/iqMLuH3QiQ+mBWcSUib41S7QzZdcyRiVUFOcLVqd3g+dze+ioM6
 ce3vI8RRwV+8D4wuLe8Bc6zsxTOXvqCNhUkYCTbiphpBhkbFrUiBcJkzi E=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: SpqkEqpsfnoYL7v93Ky/HCU8nUolPrkHzjL1qj3BfvLiPKwMq9mGtIzNMi3+dw8Y1w/1KVNwbi
 gYRluvnuoxFMDywvhjNqGqpHKOWkGPBVn7nMiP4RxBjiCb6pbRh8MQIhgVUnYPjLiGPbcF4ugg
 hRq1/fFJtJTnTmYkEliafchxkCgPvmz3Iusuz327v/wO9fuqxjk7kuPsVZAJs0Y2O27hbweInS
 sv14ypFyFjX6oCr38qx6ORly0r3AhzSEg4HLFjepirPbJzCAUiLcuLCUSx8HfTSVsDpfFUdZ3d
 5r0=
X-SBRS: 2.7
X-MesageID: 15800948
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15800948"
Subject: Re: [PATCH 3/5] x86/p2m: make p2m_remove_page()'s parameters type-safe
To: Jan Beulich <jbeulich@suse.com>
References: <3fbe1d2e-034a-31d7-7207-52ef8b335529@suse.com>
 <858f22e3-0f4f-08f0-ef67-b8ce67146537@suse.com>
 <ae425c2f-0297-4944-5bd5-03ccdab8fdce@citrix.com>
 <d6a1dc4a-f6e6-ae2c-81fd-d918087c8328@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <28990129-054a-84eb-223c-935f1929cb9c@citrix.com>
Date: Fri, 3 Apr 2020 15:40:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <d6a1dc4a-f6e6-ae2c-81fd-d918087c8328@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, George
 Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 10:14, Jan Beulich wrote:
> On 03.04.2020 00:43, Andrew Cooper wrote:
>> On 01/04/2020 12:39, Jan Beulich wrote:
>>> @@ -790,21 +789,23 @@ p2m_remove_page(struct p2m_domain *p2m,
>>>                                            &cur_order, NULL);
>>>  
>>>          if ( p2m_is_valid(t) &&
>>> -             (!mfn_valid(_mfn(mfn)) || mfn + i != mfn_x(mfn_return)) )
>>> +             (!mfn_valid(mfn) || !mfn_eq(mfn_add(mfn, i), mfn_return)) )
>>>              return -EILSEQ;
>>>  
>>> -        i += (1UL << cur_order) - ((gfn_l + i) & ((1UL << cur_order) - 1));
>>> +        i += (1UL << cur_order) -
>>> +             (gfn_x(gfn_add(gfn, i)) & ((1UL << cur_order) - 1));
>> We're gaining an number of expressions starting to look like this, but
>> honestly, "gfn_x(gfn) + i" is equally typesafe, shorter, and easier to
>> read IMO.
> May I, just like you said for patch 3, imply A-b with this adjusted?

Yes.  Sorry - it was late when I was reviewing.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:47:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:47:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNbC-0006ZD-0q; Fri, 03 Apr 2020 14:47:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=WUFr=5T=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jKNbB-0006Z8-IO
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:47:09 +0000
X-Inumbo-ID: fe131554-75b9-11ea-bd27-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fe131554-75b9-11ea-bd27-12813bfff9fa;
 Fri, 03 Apr 2020 14:47:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585925229;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=oxPW7MOKegcxbi4LDSye//dOB8eww9B/bng/tIoUMPI=;
 b=FQLpaazv6hAKxSL4X/ILogYeC69QahwyMyZvJ2uytKqWaLSZ6PpS8X3w
 JbnlcOqkSEeU1YLmpa+udALCnvGhk/lZjdteXjlEe6sH/wSw09LMFo9Fg
 EzUHP8BxRGlW9FXYJk6Zl+etvkCXN5khSytkJSPQhD6kxWQiJnDmScHX2 o=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: IVC62dvuwDkLnmhAept02G9gHIYm0ilRdntOg3p+LP+g9oSFnizbSXlEtAAOn5j3JaVNoir7iy
 ZhVuJrzPrQEUEW2q4MZ4dy66n/pr2cVIoGLuJ5OXO+Lq6UA2zQ47iu01NSDmiwz/u3fzmfipwA
 KhNSPF5cSyYFUGXtD1FSJnmNj1AnpQvhMbg6KdhtdnRF2e0NxCi2D8v0ZoSxN21Nqbjzzb/T3P
 nKCYuBTDAr1vZvISfO1HUqCrIgPhZgAT5MBBttxjaKdRhBWCPPqwc3bijrDbf/y7Jp+iejlxbM
 mlw=
X-SBRS: 2.7
X-MesageID: 15360870
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15360870"
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
 <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
 <0faaee38-e314-24a8-b97d-9f000251a63e@citrix.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <9cba6eda-2c7c-9700-a484-c72100b8268f@citrix.com>
Date: Fri, 3 Apr 2020 15:47:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <0faaee38-e314-24a8-b97d-9f000251a63e@citrix.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, wl@xen.org,
 roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 15:39, Andrew Cooper wrote:
> On 03/04/2020 14:53, Jan Beulich wrote:
>> On 02.04.2020 18:18, Igor Druzhinin wrote:
>>> The area just below 4G where OVMF image is originally relocated is not
>>> necessarily a hole - it might contain pages preallocated by device model
>>> or the toolstack. By unconditionally populating on top of this memory
>>> the original pages are getting lost while still potentially foreign mapped
>>> in Dom0.
>> When there are pre-allocated pages - have they been orphaned? If
>> so, shouldn't whoever populated them unpopulate rather than
>> orphaning them? Or if not - how is the re-use you do safe?
> 
> So this is a mess.
> 
> OVMF is linked to run at a fixed address suitable for native hardware,
> which is in the SPI ROM immediately below the 4G boundary (this is
> correct).  We also put the framebuffer there (this is not correct).
> 
> This was fine for RomBIOS which is located under the 1M boundary.
> 
> It is also fine for a fully-emulated VGA device in Qemu, because the the
> framebuffer if moved (re-set up actually) when the virtual BAR is moved,
> but with a real GPU (SR-IOV in this case), there is no logic to play games.
> 
> The problem is entirely caused by the framebuffer in Xen not being like
> any real system.  The framebuffer isn't actually in a BAR, and also
> doesn't manifest itself in the way that graphics-stolen-ram normally
> does, either.

Adding to what Andrew said:

There multiple technical complications that caused this mess.
One of them is that there is no unfortunately a better place for the
framebuffer to be located initially. Second, SR-IOV device
is real and adding a virtual BAR to it is also complicated (due to
compatibility reasons) and NVIDIA decided to avoid that.

Igor


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:51:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNff-0007L4-Np; Fri, 03 Apr 2020 14:51:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKNfe-0007KX-Qi
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:51:46 +0000
X-Inumbo-ID: a3977088-75ba-11ea-bd2a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a3977088-75ba-11ea-bd2a-12813bfff9fa;
 Fri, 03 Apr 2020 14:51:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A6C88AC62;
 Fri,  3 Apr 2020 14:51:44 +0000 (UTC)
Subject: Re: [PATCH v7 09/12] xen: add runtime parameter access support to
 hypfs
To: Juergen Gross <jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-10-jgross@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f08bdac6-122a-9289-3241-a0460a73c686@suse.com>
Date: Fri, 3 Apr 2020 16:51:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200402154616.16927-10-jgross@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 17:46, Juergen Gross wrote:
> V7:
> - fine tune some parameter initializations (Jan Beulich)
> - call custom_runtime_set_var() after updating the value
> - modify alignment in Arm linker script to 4 (Jan Beulich)

I didn't ask for this to be unilaterally 4 - I don't think this
would work on Arm64, seeing that there are pointers inside the
struct. This wants to be pointer size, i.e. 4 for Arm32 but 8
for Arm64.

> --- a/docs/misc/hypfs-paths.pandoc
> +++ b/docs/misc/hypfs-paths.pandoc
> @@ -152,3 +152,12 @@ The major version of Xen.
>  #### /buildinfo/version/minor = INTEGER
>  
>  The minor version of Xen.
> +
> +#### /params/
> +
> +A directory of runtime parameters.
> +
> +#### /params/*
> +
> +The individual parameters. The description of the different parameters can be
> +found in `docs/misc/xen-command-line.pandoc`.

Is .pandoc a useful specification here, or do such extensions get
converted when rendering into different formats?

> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -70,6 +70,30 @@ integer_param("ple_window", ple_window);
>  static bool __read_mostly opt_ept_pml = true;
>  static s8 __read_mostly opt_ept_ad = -1;
>  int8_t __read_mostly opt_ept_exec_sp = -1;
> +static char opt_ept_setting[24];
> +
> +static void update_ept_param_append(const char *str, int val)
> +{
> +    char *pos = opt_ept_setting + strlen(opt_ept_setting);
> +
> +    snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
> +             ",%s=%d", str, val);
> +}
> +
> +static void update_ept_param(void)
> +{
> +    snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
> +    if ( opt_ept_ad >= 0 )
> +        update_ept_param_append("ad", opt_ept_ad);

With the new patch 1, is the if() here really still needed? Then
again, only "exec-sp" is a runtime sub-parameter anyway afaict,
and hence I'd expect only that part of the option should be
displayed (I'm sorry for not having paid attention to this
earlier).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 14:56:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 14:56:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNkU-0007VC-CO; Fri, 03 Apr 2020 14:56:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6vR8=5T=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jKNkT-0007V5-4S
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 14:56:45 +0000
X-Inumbo-ID: 5534275a-75bb-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5534275a-75bb-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 14:56:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0709BABF4;
 Fri,  3 Apr 2020 14:56:43 +0000 (UTC)
Subject: Re: [PATCH v7 01/12] xen/vmx: let opt_ept_ad always reflect the
 current setting
To: Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-2-jgross@suse.com>
 <ad4beba2-3759-bd86-f6e3-670683083b0a@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <57c83aae-9ad0-19c0-b447-6c12ca0f3ff6@suse.com>
Date: Fri, 3 Apr 2020 16:56:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <ad4beba2-3759-bd86-f6e3-670683083b0a@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.20 16:05, Jan Beulich wrote:
> On 02.04.2020 17:46, Juergen Gross wrote:
>> In case opt_ept_ad has not been set explicitly by the user via command
>> line or runtime parameter, it is treated as "no" on Avoton cpus.
>>
>> Change that handling by setting opt_ept_ad to 0 for this cpu type
>> explicitly if no user value has been set.
>>
>> By putting this into the (renamed) boot time initialization of vmcs.c
>> _vmx_cpu_up() can be made static.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> albeit preferably with ...
> 
>> @@ -2108,9 +2104,21 @@ static void vmcs_dump(unsigned char ch)
>>       printk("**************************************\n");
>>   }
>>   
>> -void __init setup_vmcs_dump(void)
>> +int __init vmx_vmcs_init(void)
>>   {
>> -    register_keyhandler('v', vmcs_dump, "dump VT-x VMCSs", 1);
>> +    int ret;
>> +
>> +    if ( opt_ept_ad < 0 )
>> +        /* Work around Erratum AVR41 on Avoton processors. */
>> +        opt_ept_ad = (boot_cpu_data.x86 == 6 &&
>> +                      boot_cpu_data.x86_model == 0x4d) ? 0 : 1;
> 
> ... no use of the conditional operator here - the result of the
> && (or its logical inversion to be precise) would be quite fine
> to use directly here.

Okay.


Juergen



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:00:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:00:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNnl-0008K6-Ug; Fri, 03 Apr 2020 15:00:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=okFK=5T=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jKNnk-0008K0-DY
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:00:08 +0000
X-Inumbo-ID: ce7d38d6-75bb-11ea-b4f4-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ce7d38d6-75bb-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 15:00:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585926007;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=tQpLqXWJRFrEYeOWXr2YZn8mxKFx4q2UL3IzSEzzSRs=;
 b=WPBjqqi1H3oSaIjouEGZ35Dk9yNnoo7M0cIvL1oU/lZemqo+Jvw8k/lj
 tL7BwXoR21hTtpDJeWw+3zvNvmlKLC29DnI/E+aZjT5BCy/W93HoRKEio
 MfAZQORyMVa3aGoVRExTe03g6u6F6LDDZiZrEHy67ewZ/rMo9Oo4VEVu8 w=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: CDK8L/L3HzQ8zPAV/wDwPdp4CSLbird+xk+7lbVrXJI7wMzEfkZ8Mxo0+7i+BR/BTHc3WwCkO+
 6rkcL8774ti9rnNa7r298WffiWm7Kics6PuViIj1rjjh599HmwMDJNZI4sefsoAGYbO8C7ucYr
 XtltTcGcmgcmvfsAB2/Nz1aOrTrkGR7QxV9fi4AdblF3HhzULP2xFHQZUPqXioDPcumURW8xq9
 6IviScbIdxLVSZVEGEcLaTdX8pFb2VlrO1+5VZU2T3DQzz4amI6HBYw1R9m/llX4eJ561sZcAB
 XmY=
X-SBRS: 2.7
X-MesageID: 15361588
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15361588"
Subject: Re: [PATCH v5 10/10] x86emul: support MCOMMIT
To: Jan Beulich <jbeulich@suse.com>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <e41a2f72-ede5-adec-dc82-65b76368b7f7@suse.com>
 <574bab09-a29e-d77e-96e0-06e57ff524ee@citrix.com>
 <71d182e8-983c-9fa6-3403-ee3212c70c50@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <04564584-c60e-6a4a-cc58-5ec0cf1fa1f5@citrix.com>
Date: Fri, 3 Apr 2020 16:00:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <71d182e8-983c-9fa6-3403-ee3212c70c50@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 09:00, Jan Beulich wrote:
> On 03.04.2020 01:47, Andrew Cooper wrote:
>> On 24/03/2020 12:37, Jan Beulich wrote:
>>> The dependency on a new EFER bit implies that we need to set that bit
>>> ourselves in order to be able to successfully invoke the insn.
>>>
>>> Also once again introduce the SVM related constants at this occasion.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> RFC: The exact meaning of the PM stating "any errors encountered by
>>>      those stores have been signaled to associated error logging
>>>      resources" is unclear. Depending on what this entails, blindly
>>>      enabling EFER.MCOMMIT may not be a good idea. Hence the RFC.
>> Not just that.  Its not safe for Xen to ever execute MCOMMIT for
>> emulation purposes.
> I.e. you're suggesting we mustn't even try to emulate it?

Sorry - that's not quite what I intended to mean.

>
>> From what I can glean from the documentation, it is intended for
>> non-volatile RAM, but I can't find anything discussing the error handling.
>>
>> The fact the instruction can be intercepted in the first place hopefully
>> means that there must be something Xen can look at to get the real error
>> indicator.  However, the suggestion is that this will all be platform
>> specific.
>>
>>
>> The emulation problem comes from the fact that if Xen has any pending
>> writes to to NVRAM as part of the emulation path (or an interrupt for
>> that matter), an error intended for Xen would leak into guest context.
> I'm afraid all of this is guesswork until it becomes clear how
> exactly this error reporting is intended to work.

What I meant was that "emulating MCOMMIT can't involve executing an
MCOMMIT instruction".

In some future where we have combined intercept and emulation paths,
whatever ends up existing will still have to reach out to the error
banks directly to figure out what is going on.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:05:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:05:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNsX-0008US-JJ; Fri, 03 Apr 2020 15:05:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKNsX-0008UN-2f
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:05:05 +0000
X-Inumbo-ID: 7ee9b08c-75bc-11ea-bd33-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7ee9b08c-75bc-11ea-bd33-12813bfff9fa;
 Fri, 03 Apr 2020 15:05:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 57A51AC62;
 Fri,  3 Apr 2020 15:05:02 +0000 (UTC)
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: Igor Druzhinin <igor.druzhinin@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
 <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
 <0faaee38-e314-24a8-b97d-9f000251a63e@citrix.com>
 <9cba6eda-2c7c-9700-a484-c72100b8268f@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <050e4847-df42-6e16-3707-19fadbae9229@suse.com>
Date: Fri, 3 Apr 2020 17:05:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <9cba6eda-2c7c-9700-a484-c72100b8268f@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, wl@xen.org,
 roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 16:47, Igor Druzhinin wrote:
> On 03/04/2020 15:39, Andrew Cooper wrote:
>> On 03/04/2020 14:53, Jan Beulich wrote:
>>> On 02.04.2020 18:18, Igor Druzhinin wrote:
>>>> The area just below 4G where OVMF image is originally relocated is not
>>>> necessarily a hole - it might contain pages preallocated by device model
>>>> or the toolstack. By unconditionally populating on top of this memory
>>>> the original pages are getting lost while still potentially foreign mapped
>>>> in Dom0.
>>> When there are pre-allocated pages - have they been orphaned? If
>>> so, shouldn't whoever populated them unpopulate rather than
>>> orphaning them? Or if not - how is the re-use you do safe?
>>
>> So this is a mess.
>>
>> OVMF is linked to run at a fixed address suitable for native hardware,
>> which is in the SPI ROM immediately below the 4G boundary (this is
>> correct).  We also put the framebuffer there (this is not correct).
>>
>> This was fine for RomBIOS which is located under the 1M boundary.
>>
>> It is also fine for a fully-emulated VGA device in Qemu, because the the
>> framebuffer if moved (re-set up actually) when the virtual BAR is moved,
>> but with a real GPU (SR-IOV in this case), there is no logic to play games.

So are you saying OVMF starts out appearing to run in VRAM then
in the OVMF case, until the frame buffer gets moved? If so,
with the logic added by this patch, how would both places end
(old VRAM address, where OVMF lives, and new VRAM address) get
backed by distinct pages? Wouldn't the avoided re-populate
result in the same page having two uses? Or alternatively there
being a hole in OVMF space, which would be a problem if this
was backing runtime memory?

>> The problem is entirely caused by the framebuffer in Xen not being like
>> any real system.  The framebuffer isn't actually in a BAR, and also
>> doesn't manifest itself in the way that graphics-stolen-ram normally
>> does, either.
> 
> Adding to what Andrew said:
> 
> There multiple technical complications that caused this mess.
> One of them is that there is no unfortunately a better place for the
> framebuffer to be located initially. Second, SR-IOV device
> is real and adding a virtual BAR to it is also complicated (due to
> compatibility reasons) and NVIDIA decided to avoid that.

In which case I wonder - aren't you ending up with the MMIO case
that I had mentioned, and that you said is difficult to deal with?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:05:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNt3-000050-TZ; Fri, 03 Apr 2020 15:05:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6vR8=5T=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jKNt2-0008WV-Li
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:05:36 +0000
X-Inumbo-ID: 921de6a0-75bc-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 921de6a0-75bc-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 15:05:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8E5DEAB76;
 Fri,  3 Apr 2020 15:05:34 +0000 (UTC)
Subject: Re: [PATCH v7 04/12] xen: add basic hypervisor filesystem support
To: Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-5-jgross@suse.com>
 <7dda5c2c-cb81-2cfa-2cf4-4440b49d401a@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <d454afb8-40ff-c8a4-7a5a-6f8f4f4f0e4a@suse.com>
Date: Fri, 3 Apr 2020 17:05:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7dda5c2c-cb81-2cfa-2cf4-4440b49d401a@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.20 16:23, Jan Beulich wrote:
> On 02.04.2020 17:46, Juergen Gross wrote:
>> Add the infrastructure for the hypervisor filesystem.
>>
>> This includes the hypercall interface and the base functions for
>> entry creation, deletion and modification.
>>
>> In order not to have to repeat the same pattern multiple times in case
>> adding a new node should BUG_ON() failure, the helpers for adding a
>> node (hypfs_add_dir() and hypfs_add_leaf()) get a nofault parameter
>> causing the BUG() in case of a failure.
>>
>> When supporting writable leafs the entry's write pointer will need to
>> be set to the function performing the write to the variable holding the
>> content. In case there are no special constraints this will be
>> hypfs_write_bool() for type XEN_HYPFS_TYPE_BOOL and hypfs_write_leaf()
>> for the other entry types.
> 
> Seeing your HYPFS_*_INIT_WRITABLE() macros I find this a pretty
> strange requirement. Why can't the macros set the write hook right
> away?

Okay, will expand the macros.

> 
>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>> +                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>> +{
>> +    char *buf;
>> +    int ret;
>> +
>> +    if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>> +         leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>> +        return -EDOM;
>> +
>> +    buf = xmalloc_array(char, ulen);
>> +    if ( !buf )
>> +        return -ENOMEM;
>> +
>> +    ret = -EFAULT;
>> +    if ( copy_from_guest(buf, uaddr, ulen) )
>> +        goto out;
>> +
>> +    ret = -EINVAL;
>> +    if ( leaf->e.type == XEN_HYPFS_TYPE_STRING &&
>> +         memchr(buf, 0, ulen) != (buf + ulen - 1) )
>> +        goto out;
>> +
>> +    ret = 0;
>> +    memcpy(leaf->write_ptr, buf, ulen);
>> +    leaf->e.size = ulen;
>> +
>> + out:
>> +    xfree(buf);
>> +    return ret;
>> +}
>> +
>> +int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
>> +                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>> +{
>> +    bool buf;
>> +
>> +    ASSERT(leaf->e.type == XEN_HYPFS_TYPE_BOOL && leaf->e.size == sizeof(bool));
>> +
>> +    if ( ulen != leaf->e.max_size )
> 
> Why max_size here when the ASSERT() checks size?

Just for consistency with the other write functions.

> 
>> +static int hypfs_write(struct hypfs_entry *entry,
>> +                       XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>> +{
>> +    struct hypfs_entry_leaf *l;
>> +
>> +    if ( !entry->write )
>> +        return -EACCES;
>> +
>> +    if ( ulen > entry->max_size )
>> +        return -ENOSPC;
> 
> max_size being zero for non-writable entries, perhaps use -EACCES
> also for this special case? Together with the other comment above,
> maybe the ->write check wants replacing this way?

Checking the write function being not NULL is a nice security addon,
as I avoid to call into a non existing function. Basically both tests
would be equivalent, but this one is IMO better to avoid crashes.


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:06:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:06:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNuD-0000ES-CB; Fri, 03 Apr 2020 15:06:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=okFK=5T=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jKNuB-0000D6-Gn
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:06:47 +0000
X-Inumbo-ID: bc0a700a-75bc-11ea-bd33-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bc0a700a-75bc-11ea-bd33-12813bfff9fa;
 Fri, 03 Apr 2020 15:06:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585926406;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=Tlppwdnd7Augm4VpWNCEngzyG8J6ZiKDyrkT+O7UC/g=;
 b=Dxu5u1gWwqtsKGd/TB0j/VAeqaatpKQpw23pXO56sxxAmh+6CZ35x1GI
 dJrR6JDaRSDUZJz6K91a1tHDefVgpvF8+WCNvg6jr6ZtuA1m5kavZoTer
 j+AKTN542BxTY17a73+HVRp9nChOKHsJzpkK2c6vRzSStI1Gia+FO5z+f 0=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: iUVjkVtZWP38Hs8DoCPhi7ogNdy1sSRlQIAtV6L3dSNz47pyXhfs0C+cgIA2OTVq23SaS8JyEg
 32BdWbXAshMLmjD+4rooji1cr8CxsKB7Qe3tUAhGooF0YWACnCKR72OSSKdlr0U9zMDki3kcYu
 yhixRv7tMuOAEjQb6h8m5apsM78iefc6lfjRMX/1caaqE0gUgrQRlzteNJU1qvO7ueYG3PzukS
 PyNNmunHkw1Oh/+i1dSWJhFwXbpknf4jHaFqScQ20CbqOr2+pq0LgwM+n9KgEgcvixPw11fJPP
 774=
X-SBRS: 2.7
X-MesageID: 15802556
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15802556"
Subject: Re: [PATCH v2 0/2] x86/cpuidle: Cannon Lake adjustments
To: Jan Beulich <jbeulich@suse.com>
References: <e39d4326-57d1-a4b5-3081-76b5160644ae@suse.com>
 <afe81b7e-4895-89ee-49dd-b6c0130923a1@citrix.com>
 <8813266d-cb33-0bb7-16d1-d1bf54142d2b@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <29ead7aa-19ff-7746-ddc8-df24d126c4f6@citrix.com>
Date: Fri, 3 Apr 2020 16:06:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <8813266d-cb33-0bb7-16d1-d1bf54142d2b@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 09:06, Jan Beulich wrote:
> On 02.04.2020 16:58, Andrew Cooper wrote:
>> On 02/04/2020 09:22, Jan Beulich wrote:
>>> As requested in reply to v1, this is now a pair of patches with
>>> the expectation that only patch 1 would be acked and go in.
>>>
>>> 1: drop Cannon Lake support
>>> 2: support Cannon Lake (again)
>> Dropping Cannon Lake support is only of any incremental benefit if we
>> drop it from everywhere, and I didn't mean to block this single patch on it.
> How would dropping it from everywhere in one go be any better?
> I would see a benefit then only if we added code to refuse
> booting there.
>
>> Consider either A-by.
> I'm sorry to ask, but "either" here is unclear to me: Do you
> mean both of the above, or "the first one here or the original
> v1 one"? I don't see a point committing this in two pieces, if
> the combination of both is fine by you as well.

Pick whichever patch you prefer.

Looking at Linux recently, it appears that Ice Lake inherited some of
the Cannon Lake uarch designs, so while we don't necessarily care about
Cannon Lake CPUs themselves, the same details might be applicable in
later CPUs as well.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:09:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNwl-0000Ol-Ri; Fri, 03 Apr 2020 15:09:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKNwj-0000Og-W6
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:09:26 +0000
X-Inumbo-ID: 1a21534b-75bd-11ea-bd33-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1a21534b-75bd-11ea-bd33-12813bfff9fa;
 Fri, 03 Apr 2020 15:09:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id F1CEFABBD;
 Fri,  3 Apr 2020 15:09:23 +0000 (UTC)
Subject: Re: [PATCH v5 10/10] x86emul: support MCOMMIT
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <e41a2f72-ede5-adec-dc82-65b76368b7f7@suse.com>
 <574bab09-a29e-d77e-96e0-06e57ff524ee@citrix.com>
 <71d182e8-983c-9fa6-3403-ee3212c70c50@suse.com>
 <04564584-c60e-6a4a-cc58-5ec0cf1fa1f5@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7184c1e2-f92e-3f19-4040-5b0c655ebc0f@suse.com>
Date: Fri, 3 Apr 2020 17:09:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <04564584-c60e-6a4a-cc58-5ec0cf1fa1f5@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 17:00, Andrew Cooper wrote:
> On 03/04/2020 09:00, Jan Beulich wrote:
>> On 03.04.2020 01:47, Andrew Cooper wrote:
>>> On 24/03/2020 12:37, Jan Beulich wrote:
>>>> The dependency on a new EFER bit implies that we need to set that bit
>>>> ourselves in order to be able to successfully invoke the insn.
>>>>
>>>> Also once again introduce the SVM related constants at this occasion.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> ---
>>>> RFC: The exact meaning of the PM stating "any errors encountered by
>>>>      those stores have been signaled to associated error logging
>>>>      resources" is unclear. Depending on what this entails, blindly
>>>>      enabling EFER.MCOMMIT may not be a good idea. Hence the RFC.
>>> Not just that.  Its not safe for Xen to ever execute MCOMMIT for
>>> emulation purposes.
>> I.e. you're suggesting we mustn't even try to emulate it?
> 
> Sorry - that's not quite what I intended to mean.
> 
>>
>>> From what I can glean from the documentation, it is intended for
>>> non-volatile RAM, but I can't find anything discussing the error handling.
>>>
>>> The fact the instruction can be intercepted in the first place hopefully
>>> means that there must be something Xen can look at to get the real error
>>> indicator.  However, the suggestion is that this will all be platform
>>> specific.
>>>
>>>
>>> The emulation problem comes from the fact that if Xen has any pending
>>> writes to to NVRAM as part of the emulation path (or an interrupt for
>>> that matter), an error intended for Xen would leak into guest context.
>> I'm afraid all of this is guesswork until it becomes clear how
>> exactly this error reporting is intended to work.
> 
> What I meant was that "emulating MCOMMIT can't involve executing an
> MCOMMIT instruction".

I still don't see why - the error recording is (presumably) not
dependent upon the context in which the insn was issued.

> In some future where we have combined intercept and emulation paths,
> whatever ends up existing will still have to reach out to the error
> banks directly to figure out what is going on.

I.e. you're assuming there's going to be an architectural way to
access those, rather than perhaps many platform specific ones?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:12:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKNzb-0001AV-AR; Fri, 03 Apr 2020 15:12:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6vR8=5T=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jKNza-0001AP-FW
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:12:22 +0000
X-Inumbo-ID: 84222cae-75bd-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 84222cae-75bd-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 15:12:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7934DACC2;
 Fri,  3 Apr 2020 15:12:20 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
Date: Fri, 3 Apr 2020 17:12:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.20 16:31, Jan Beulich wrote:
> On 02.04.2020 17:46, Juergen Gross wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -353,6 +353,16 @@ config DOM0_MEM
>>   
>>   	  Leave empty if you are not sure what to specify.
>>   
>> +config HYPFS_CONFIG
>> +	bool "Provide hypervisor .config via hypfs entry"
>> +	default y
> 
> My initial reaction was to ask for "depends on HYPFS", but then
> I noticed the earlier patch doesn't introduce such. Am I
> mis-remembering that it was agreed to make the whole thing
> possible to disable at least in EXPERT mode?

No, I don't remember that agreement.

And TBH I'm not sure this is a good idea, as that would at once make the
plan to replace at least some sysctl and/or domctl interfaces impossible
(like e.g. the last 3 patches of the series are doing already), or at
least would tie the related functionality to CONFIG_HYPFS.

> 
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -389,6 +389,16 @@ static HYPFS_STRING_INIT(compile_date, "compile_date");
>>   static HYPFS_STRING_INIT(compile_domain, "compile_domain");
>>   static HYPFS_STRING_INIT(extra, "extra");
>>   
>> +#ifdef CONFIG_HYPFS_CONFIG
>> +static struct hypfs_entry_leaf config = {
>> +    .e.type = XEN_HYPFS_TYPE_STRING,
>> +    .e.encoding = XEN_HYPFS_ENC_GZIP,
>> +    .e.name = "config",
>> +    .e.read = hypfs_read_leaf,
>> +    .content = &xen_config_data
>> +};
>> +#endif
> 
> Would be really good if no open-coded instantiations like this
> one would ever have to appear, i.e. if suitable macros were
> available. What's preventing use of one of the available ones
> here?

Right now it is the only case for a non plain encoding. The alternative
would have been to either specify the encoding explicitly at all other
node definitions, or to have a macro for this single instance.


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:13:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKO0o-0001GO-MI; Fri, 03 Apr 2020 15:13:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=okFK=5T=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jKO0n-0001GH-Vy
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:13:38 +0000
X-Inumbo-ID: b106a63c-75bd-11ea-b4f4-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b106a63c-75bd-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 15:13:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585926818;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=2M+SefhsEsAY6CRhSKlMU7ktZYYlZr8Fqsk+v0aaj/A=;
 b=a2NYk4FlEtqWWYSV/dye6NYoh4gZA5YlEJKhwtQ/Hj9K3pYK0UzlCLV8
 Q2MO9GqP+nhSWbbZa5EZI1LnV4kuENq3hEZoYsG459Yd/jC40khR0wDef
 7+rkSb8lYfEBbVigtExl52bU6TzjolAwJylMEJ4W/UmRDc0XPUB5qhR4q 8=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: mnB3MVdMIWfrZDLUD2rA2g+Qvrr56LUDd4rTYiZ1Atr+MMLVuPpp6BGW+cbfGPNJCmjVFYuVS1
 ZY1Ltdr95g2cJvFhPu7+9l5hiCro0zs9kzulQKlrvOvABQB3zkMAZoYKTbL6l6TegaOYqiRwMF
 IjkFbaPjQLyOo3qF4H2iRwTVsqaEWwDuxCVmU9cs8O2LG1jMpp+YOW9b/A9whjUUvXq5naeps4
 xMCbrgv82xCVo1dWzS5eCyXnBLQrUjhar18N86lx98EYzcD8npLTPqYUwl5rmEZSlgULePVo5k
 db4=
X-SBRS: 2.7
X-MesageID: 15122891
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15122891"
Subject: Re: [PATCH v5 05/10] x86emul: support MOVDIR64B insn
To: Jan Beulich <jbeulich@suse.com>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <81e7aade-9dfb-313a-ad81-30b2703c2136@suse.com>
 <0a02ed6b-d7a0-7152-185f-a5bbc5491c49@citrix.com>
 <18ef0337-d6c7-3b60-aa2e-a83930cc0902@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <f5d76dfd-61ea-1c1f-66e6-2bb1fc27be5a@citrix.com>
Date: Fri, 3 Apr 2020 16:13:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <18ef0337-d6c7-3b60-aa2e-a83930cc0902@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Paul
 Durrant <Paul.Durrant@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 08:57, Jan Beulich wrote:
> On 03.04.2020 01:12, Andrew Cooper wrote:
>> On 24/03/2020 12:34, Jan Beulich wrote:
>>> Introduce a new blk() hook, paralleling the rmw() on in certain way, but
>>> being intended for larger data sizes, and hence its HVM intermediate
>>> handling function doesn't fall back to splitting the operation if the
>>> requested virtual address can't be mapped.
>>>
>>> Note that SDM revision 071 doesn't specify exception behavior for
>>> ModRM.mod == 0b11; assuming #UD here.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Thanks much, but I'm puzzled by you providing this, and hence
> would like to double check: You specifically asked that I take
> care of the cachability issue for MOVDIRI before you would ack
> that change. How come you're not similarly concerned here?

This executes the MOVDIR64B instruction directly, so those properties
are taken care of.  (I think?)

The MOVDIRI support just does a memcpy().

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:18:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKO4y-0001Rq-BN; Fri, 03 Apr 2020 15:17:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=WUFr=5T=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jKO4x-0001Rl-E1
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:17:55 +0000
X-Inumbo-ID: 4a7a230c-75be-11ea-bd34-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4a7a230c-75be-11ea-bd34-12813bfff9fa;
 Fri, 03 Apr 2020 15:17:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585927074;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=83j+5Tkowfz8HhhnuYl4Rh0uuDc1nomq8rA+k3VBjCo=;
 b=IK8kQCejkyTLZHjv/FQYZNwQmtgMRuPnX5DLQjHGFprANl6ZksHpbKn2
 MPOCvkygHXNAsxJUKVf5GgtOcImZ3dE2/8fPopb7o6tK1An4EuLjnizAP
 1VK4rS0pgporIv2iwfmsXzQg0cK8JUqnNupG7a0jpz/h7TDU4ahTpkQBl I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: R5j06J1v92J03FOsqkSnNpwx/FtPkGratEXQ+ypJHqmsunTDrFmgn3c/B7iYDDfy31FWfjgKgk
 WSBq66H5hNzBnWg1e+YwDm2hVWWRKkgKJeLWPM73aukeBB2lZXvlOA3tnj9S4fTxwcXOYYHJWe
 9jyHhdWIX13zqZBnBT1253SfSXEcC/quGcHosxxhVSCciCOSZKgZ9SxnKusDJRpkwqt51VfN7i
 GrKqoJwClGou/BIIU5F2R8sy71HKidGk1glm2ZcARzWEDSdAaeN5M38AFfcdhzNmBCNFWbg51H
 2rE=
X-SBRS: 2.7
X-MesageID: 15803287
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15803287"
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
 <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
 <0faaee38-e314-24a8-b97d-9f000251a63e@citrix.com>
 <9cba6eda-2c7c-9700-a484-c72100b8268f@citrix.com>
 <050e4847-df42-6e16-3707-19fadbae9229@suse.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <c4b676a9-58ce-ae11-e13b-aae41b6c27b1@citrix.com>
Date: Fri, 3 Apr 2020 16:17:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <050e4847-df42-6e16-3707-19fadbae9229@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, wl@xen.org,
 roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 16:05, Jan Beulich wrote:
> On 03.04.2020 16:47, Igor Druzhinin wrote:
>> On 03/04/2020 15:39, Andrew Cooper wrote:
>>> On 03/04/2020 14:53, Jan Beulich wrote:
>>>> On 02.04.2020 18:18, Igor Druzhinin wrote:
>>>>> The area just below 4G where OVMF image is originally relocated is not
>>>>> necessarily a hole - it might contain pages preallocated by device model
>>>>> or the toolstack. By unconditionally populating on top of this memory
>>>>> the original pages are getting lost while still potentially foreign mapped
>>>>> in Dom0.
>>>> When there are pre-allocated pages - have they been orphaned? If
>>>> so, shouldn't whoever populated them unpopulate rather than
>>>> orphaning them? Or if not - how is the re-use you do safe?
>>>
>>> So this is a mess.
>>>
>>> OVMF is linked to run at a fixed address suitable for native hardware,
>>> which is in the SPI ROM immediately below the 4G boundary (this is
>>> correct).  We also put the framebuffer there (this is not correct).
>>>
>>> This was fine for RomBIOS which is located under the 1M boundary.
>>>
>>> It is also fine for a fully-emulated VGA device in Qemu, because the the
>>> framebuffer if moved (re-set up actually) when the virtual BAR is moved,
>>> but with a real GPU (SR-IOV in this case), there is no logic to play games.
> 
> So are you saying OVMF starts out appearing to run in VRAM then
> in the OVMF case, until the frame buffer gets moved? If so,
> with the logic added by this patch, how would both places end
> (old VRAM address, where OVMF lives, and new VRAM address) get
> backed by distinct pages? Wouldn't the avoided re-populate
> result in the same page having two uses? Or alternatively there
> being a hole in OVMF space, which would be a problem if this
> was backing runtime memory? 

In normal case (not SR-IOV) VRAM gets evacuated (by PCI logic) before
hvmloader overwrites it. So the issue is avoided. But for SR-IOV VRAM
stays so VRAM area is temporary used to hold OVMF image - until decompression
is complete. With this patch VRAM pages would be used for that purpose
instead new ones.

>>> The problem is entirely caused by the framebuffer in Xen not being like
>>> any real system.  The framebuffer isn't actually in a BAR, and also
>>> doesn't manifest itself in the way that graphics-stolen-ram normally
>>> does, either.
>>
>> Adding to what Andrew said:
>>
>> There multiple technical complications that caused this mess.
>> One of them is that there is no unfortunately a better place for the
>> framebuffer to be located initially. Second, SR-IOV device
>> is real and adding a virtual BAR to it is also complicated (due to
>> compatibility reasons) and NVIDIA decided to avoid that.
> 
> In which case I wonder - aren't you ending up with the MMIO case
> that I had mentioned, and that you said is difficult to deal with?

No, it's VRAM area (normal RAM pages) - not MMIO.

Igor


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:20:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:20:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKO7N-0002Ap-PT; Fri, 03 Apr 2020 15:20:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DmfO=5T=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jKO7M-0002Aj-GF
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:20:24 +0000
X-Inumbo-ID: a371f89a-75be-11ea-b4f4-bc764e2007e4
Received: from mail-wm1-x330.google.com (unknown [2a00:1450:4864:20::330])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a371f89a-75be-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 15:20:23 +0000 (UTC)
Received: by mail-wm1-x330.google.com with SMTP id i19so8161923wmb.0
 for <xen-devel@lists.xenproject.org>; Fri, 03 Apr 2020 08:20:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=paZCOymGUO3uhYNh9MBt/YSXWrRalqdxRoI1h3RgPoU=;
 b=nir+Uytfzgd1nRefyAn0sRuNLpRqDNi+9OfW3hTNnPi/Yu+FJlhhXW6/NemAPGWPPH
 K0rSJi6jQWhr4OZjZxnbSxprl5fr7/N9xBV9ywS+sumIwuy8n0l/TqF17dIJcTQBhts/
 Qy1HYcuw1AXvfHbY/BfIkdPwJimV68p4bhA7+Szt0k+WtYrZBMYODJ+J42N7D2JYOgqP
 F072fztnCOfj8xN8TzrHha0guJbYgOSwNsuYaX4hxDWnKEw5atxm+MptZDUSfUjowDZ7
 n1gIpVGtPjt2hsWG50Wvr0LFIx93nHQWeuxnaJF8QZAKO773gpP6y51OUlqa9LgYi54m
 st+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=paZCOymGUO3uhYNh9MBt/YSXWrRalqdxRoI1h3RgPoU=;
 b=iA4kyciCKZAb8C2tOhDmD5Ht18mQI103gixfdvl97s2Zepa4V3smNhCVQrni7yiQDH
 SqXNuXNrZDY+y6PeVnx5JH5x7RxYNR5ZhG6+aaW7rd5CrtcRKtsBG+sYeYBc165iFs/Z
 tgHhNif9fu9L4m5JrEv1u/PzUsmCVGPETgmkqks6faEUf1kBAaEVJMSIux3Wd6ccvmWM
 r0aSNjUO/7jZJ5GtDijVdvW9u61txfjWi2qP4CrIMRcVUPU3Si0i6fzBr8u41xuQTulq
 R036ZCgsDrfGMyjB4u5S7I1n0X8STcwlz6pzqqr40Y2MQ/6vjN4llfzUWeRCGNU8/osI
 G5Ng==
X-Gm-Message-State: AGi0PubSnhb3ST0aA7HHai3IO01f+PjZ+sATbpddrbuSwGPkP2mGch6R
 +tfuWo3OS86De1uSkE43WKH9W3veih0=
X-Google-Smtp-Source: APiQypLqhwP7eASMSRAAvkljQv0c+We1ZmIbxAbmK+bLdsXWQO9TUrFOCHj5TTVncx/W5l0Wr4GtPg==
X-Received: by 2002:a05:600c:220f:: with SMTP id
 z15mr9712527wml.185.1585927223054; 
 Fri, 03 Apr 2020 08:20:23 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id v9sm477168wrv.18.2020.04.03.08.20.21
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 03 Apr 2020 08:20:22 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-4-paul@xen.org>
 <b94676ab-371b-bb69-0d07-dd38fe22ceba@suse.com>
In-Reply-To: <b94676ab-371b-bb69-0d07-dd38fe22ceba@suse.com>
Subject: RE: [PATCH 3/5] tools/misc: add xen-ctx to present domain context
Date: Fri, 3 Apr 2020 16:20:20 +0100
Message-ID: <001e01d609cb$64913fa0$2db3bee0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQG3I8TZM/MLMEc/e2It3WEXPZVs8AIR6g5qAoK3rZqogKoVMA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'Wei Liu' <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 30 March 2020 11:54
> To: Paul Durrant <paul@xen.org>
> Cc: xen-devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>; Wei Liu <wl@xen.org>
> Subject: Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain context
> 
> On 27.03.2020 19:50, Paul Durrant wrote:
> > This tools is analogous to 'xen-hvmctx' which presents HVM context.
> > Subsequent patches will add 'dump' functions when new records are
> > introduced.
> >
> > Signed-off-by: Paul Durrant <paul@xen.org>
> > ---
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Wei Liu <wl@xen.org>
> > ---
> >  .gitignore           |   1 +
> >  tools/misc/Makefile  |   4 ++
> >  tools/misc/xen-ctx.c | 144 +++++++++++++++++++++++++++++++++++++++++++
> 
> Is xen-ctx a good choice of a name, considering we already have not
> only xen-hvmctx, but also xenctx? If the new functionality isn't a
> good fit for either, perhaps its name would better reflect its
> connection to save/restore records? xen-sr-dump looks pretty clumsy
> to me, but still seems better than a name easily mixed up with
> others.

How about xen-domctx?

  Paul

> 
> Jan



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:25:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:25:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOCG-0002PX-NG; Fri, 03 Apr 2020 15:25:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=i4CN=5T=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKOCF-0002PS-KO
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:25:27 +0000
X-Inumbo-ID: 55097312-75bf-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 55097312-75bf-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 15:25:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Pgae6wTxtqLNBc99FQfS9ARYFFbLWUYzr9Pvdl4ApzI=; b=NJWz9J3rMnnY5wkIYZim6g4xZ
 tQExC1jai1Ynu+6zJ0R5s9V+RMSSEKothcwrue22r7YknGNrDKf7I/uGN0V140DmEnML0G6P0LRq8
 /i639FMTKr+1j+nwVMGbQam1q2ubTx/2u0fV6w5o6h2NqZ5AT4s1W1ri+bzStXhGaDcLk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKOC9-0001Uz-8p; Fri, 03 Apr 2020 15:25:21 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKOC8-0008RH-RI; Fri, 03 Apr 2020 15:25:20 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKOC8-0002NA-Nx; Fri, 03 Apr 2020 15:25:20 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149376-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149376: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=07bb8ff4dd0ca0224754c582390f4a873597c4b9
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 03 Apr 2020 15:25:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  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-xsm   1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 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-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              07bb8ff4dd0ca0224754c582390f4a873597c4b9
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   77 days
Failing since        146211  2020-01-18 04:18:52 Z   76 days   73 attempts
Testing same since   149376  2020-04-03 04:18:50 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 12576 lines long.)


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:25:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOCN-0002Q9-Vs; Fri, 03 Apr 2020 15:25:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=okFK=5T=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jKOCM-0002Pv-Dr
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:25:34 +0000
X-Inumbo-ID: 5c09fc22-75bf-11ea-83d8-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5c09fc22-75bf-11ea-83d8-bc764e2007e4;
 Fri, 03 Apr 2020 15:25:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585927534;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=Tmzw6lZPtJ5N2tMJ0hZu+uKxLACy+mG/3poNcxuMfi8=;
 b=ToXDNFV59eyLpNX5oc313Ix2Donh1WIrPPbIJRZT6CdfYOYuucU56Q1R
 PIt8/YIfSVkTrC+TPuJd+aqIckaj5A8+/KuDYyMkl6bJxlg7kR7rb3bkC
 sLZpMm5Ea00UE90RcB5PHUE88et06JZtoNOnSziudbf5oIwiciRCZA7id c=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: drlfNwjzqM4UosFe3DR6obdD58VHXaWTzaPTo/DWwuan0RJ3JazWEUuCMS3Xg/0e5eVWmeyttc
 cpnfr2QOgdaoUY3EjFCnaGMXlxsL2kgpxNbWADLsNNfcHeBCsCRwA5i6Yh2kXCSiGWriLEPXGA
 QhjCrPl/EZibG/JlQVnm+DiRgQnpSUzVMWav0iMFFEyLHTmGN84ChEkM1ItfayJX+gZOS8QMtf
 srns1oDmDTz8xLWi/gC8zxNtKpFPkOBAi7Q++bgEdYGYxCbhPiYChTg5nN+OQGBm9WJErkoSA5
 UBg=
X-SBRS: 2.7
X-MesageID: 15123676
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15123676"
Subject: Re: [PATCH v5 10/10] x86emul: support MCOMMIT
To: Jan Beulich <jbeulich@suse.com>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <e41a2f72-ede5-adec-dc82-65b76368b7f7@suse.com>
 <574bab09-a29e-d77e-96e0-06e57ff524ee@citrix.com>
 <71d182e8-983c-9fa6-3403-ee3212c70c50@suse.com>
 <04564584-c60e-6a4a-cc58-5ec0cf1fa1f5@citrix.com>
 <7184c1e2-f92e-3f19-4040-5b0c655ebc0f@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <a2440848-cfcb-4628-f78b-a61cf6e4e97f@citrix.com>
Date: Fri, 3 Apr 2020 16:25:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <7184c1e2-f92e-3f19-4040-5b0c655ebc0f@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 16:09, Jan Beulich wrote:
> On 03.04.2020 17:00, Andrew Cooper wrote:
>> On 03/04/2020 09:00, Jan Beulich wrote:
>>> On 03.04.2020 01:47, Andrew Cooper wrote:
>>>> On 24/03/2020 12:37, Jan Beulich wrote:
>>>>> The dependency on a new EFER bit implies that we need to set that bit
>>>>> ourselves in order to be able to successfully invoke the insn.
>>>>>
>>>>> Also once again introduce the SVM related constants at this occasion.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>> ---
>>>>> RFC: The exact meaning of the PM stating "any errors encountered by
>>>>>      those stores have been signaled to associated error logging
>>>>>      resources" is unclear. Depending on what this entails, blindly
>>>>>      enabling EFER.MCOMMIT may not be a good idea. Hence the RFC.
>>>> Not just that.  Its not safe for Xen to ever execute MCOMMIT for
>>>> emulation purposes.
>>> I.e. you're suggesting we mustn't even try to emulate it?
>> Sorry - that's not quite what I intended to mean.
>>
>>>> From what I can glean from the documentation, it is intended for
>>>> non-volatile RAM, but I can't find anything discussing the error handling.
>>>>
>>>> The fact the instruction can be intercepted in the first place hopefully
>>>> means that there must be something Xen can look at to get the real error
>>>> indicator.  However, the suggestion is that this will all be platform
>>>> specific.
>>>>
>>>>
>>>> The emulation problem comes from the fact that if Xen has any pending
>>>> writes to to NVRAM as part of the emulation path (or an interrupt for
>>>> that matter), an error intended for Xen would leak into guest context.
>>> I'm afraid all of this is guesswork until it becomes clear how
>>> exactly this error reporting is intended to work.
>> What I meant was that "emulating MCOMMIT can't involve executing an
>> MCOMMIT instruction".
> I still don't see why - the error recording is (presumably) not
> dependent upon the context in which the insn was issued.

And that is the problem.  This instruction has a 1-bit "everything ok"
vs "something went wrong" feedback.

We can't be telling a guest that something went wrong when in fact it
was Xen doing something unrelated which suffered the error.

>> In some future where we have combined intercept and emulation paths,
>> whatever ends up existing will still have to reach out to the error
>> banks directly to figure out what is going on.
> I.e. you're assuming there's going to be an architectural way to
> access those, rather than perhaps many platform specific ones?

I think we're going to have to wait and see what materialises.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:25:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:25:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOCl-0002U5-9F; Fri, 03 Apr 2020 15:25:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKOCj-0002Tp-Lf
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:25:57 +0000
X-Inumbo-ID: 69f7c292-75bf-11ea-bd39-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 69f7c292-75bf-11ea-bd39-12813bfff9fa;
 Fri, 03 Apr 2020 15:25:57 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 82B15ABEF;
 Fri,  3 Apr 2020 15:25:55 +0000 (UTC)
Subject: Re: [PATCH v5 05/10] x86emul: support MOVDIR64B insn
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <81e7aade-9dfb-313a-ad81-30b2703c2136@suse.com>
 <0a02ed6b-d7a0-7152-185f-a5bbc5491c49@citrix.com>
 <18ef0337-d6c7-3b60-aa2e-a83930cc0902@suse.com>
 <f5d76dfd-61ea-1c1f-66e6-2bb1fc27be5a@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <97d736af-d74d-8a8f-7184-9a3328bd369d@suse.com>
Date: Fri, 3 Apr 2020 17:25:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f5d76dfd-61ea-1c1f-66e6-2bb1fc27be5a@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Paul Durrant <Paul.Durrant@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 17:13, Andrew Cooper wrote:
> On 03/04/2020 08:57, Jan Beulich wrote:
>> On 03.04.2020 01:12, Andrew Cooper wrote:
>>> On 24/03/2020 12:34, Jan Beulich wrote:
>>>> Introduce a new blk() hook, paralleling the rmw() on in certain way, but
>>>> being intended for larger data sizes, and hence its HVM intermediate
>>>> handling function doesn't fall back to splitting the operation if the
>>>> requested virtual address can't be mapped.
>>>>
>>>> Note that SDM revision 071 doesn't specify exception behavior for
>>>> ModRM.mod == 0b11; assuming #UD here.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Thanks much, but I'm puzzled by you providing this, and hence
>> would like to double check: You specifically asked that I take
>> care of the cachability issue for MOVDIRI before you would ack
>> that change. How come you're not similarly concerned here?
> 
> This executes the MOVDIR64B instruction directly, so those properties
> are taken care of.  (I think?)
> 
> The MOVDIRI support just does a memcpy().

Oh, now I understand. I could make MOVDIRI follow suit and actually
use this insn to back emulation.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:28:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOFG-0002in-Na; Fri, 03 Apr 2020 15:28:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKOFG-0002if-25
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:28:34 +0000
X-Inumbo-ID: c70f62dc-75bf-11ea-bd39-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c70f62dc-75bf-11ea-bd39-12813bfff9fa;
 Fri, 03 Apr 2020 15:28:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 06878AEA3;
 Fri,  3 Apr 2020 15:28:32 +0000 (UTC)
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: Igor Druzhinin <igor.druzhinin@citrix.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
 <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
 <0faaee38-e314-24a8-b97d-9f000251a63e@citrix.com>
 <9cba6eda-2c7c-9700-a484-c72100b8268f@citrix.com>
 <050e4847-df42-6e16-3707-19fadbae9229@suse.com>
 <c4b676a9-58ce-ae11-e13b-aae41b6c27b1@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <24e20e5d-c661-3f40-ceb0-e0c6f0a753b2@suse.com>
Date: Fri, 3 Apr 2020 17:28:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <c4b676a9-58ce-ae11-e13b-aae41b6c27b1@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, roger.pau@citrix.com,
 ian.jackson@eu.citrix.com, wl@xen.org, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 17:17, Igor Druzhinin wrote:
> On 03/04/2020 16:05, Jan Beulich wrote:
>> On 03.04.2020 16:47, Igor Druzhinin wrote:
>>> There multiple technical complications that caused this mess.
>>> One of them is that there is no unfortunately a better place for the
>>> framebuffer to be located initially. Second, SR-IOV device
>>> is real and adding a virtual BAR to it is also complicated (due to
>>> compatibility reasons) and NVIDIA decided to avoid that.
>>
>> In which case I wonder - aren't you ending up with the MMIO case
>> that I had mentioned, and that you said is difficult to deal with?
> 
> No, it's VRAM area (normal RAM pages) - not MMIO.

Well, VRAM is still MMIO from the CPU's perspective, just without
any side effects. But if it was another device that was passed
through, couldn't its MMIO similarly end up in that area?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:29:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:29:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOGQ-0002ou-1z; Fri, 03 Apr 2020 15:29:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKOGP-0002om-BB
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:29:45 +0000
X-Inumbo-ID: f134342a-75bf-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f134342a-75bf-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 15:29:43 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B8308ABEF;
 Fri,  3 Apr 2020 15:29:42 +0000 (UTC)
Subject: Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain context
To: paul@xen.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-4-paul@xen.org>
 <b94676ab-371b-bb69-0d07-dd38fe22ceba@suse.com>
 <001e01d609cb$64913fa0$2db3bee0$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f04d7e53-b1d9-a304-a7ac-64238836eca5@suse.com>
Date: Fri, 3 Apr 2020 17:29:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <001e01d609cb$64913fa0$2db3bee0$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'Wei Liu' <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 17:20, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 30 March 2020 11:54
>> To: Paul Durrant <paul@xen.org>
>> Cc: xen-devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>; Wei Liu <wl@xen.org>
>> Subject: Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain context
>>
>> On 27.03.2020 19:50, Paul Durrant wrote:
>>> This tools is analogous to 'xen-hvmctx' which presents HVM context.
>>> Subsequent patches will add 'dump' functions when new records are
>>> introduced.
>>>
>>> Signed-off-by: Paul Durrant <paul@xen.org>
>>> ---
>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>> Cc: Wei Liu <wl@xen.org>
>>> ---
>>>  .gitignore           |   1 +
>>>  tools/misc/Makefile  |   4 ++
>>>  tools/misc/xen-ctx.c | 144 +++++++++++++++++++++++++++++++++++++++++++
>>
>> Is xen-ctx a good choice of a name, considering we already have not
>> only xen-hvmctx, but also xenctx? If the new functionality isn't a
>> good fit for either, perhaps its name would better reflect its
>> connection to save/restore records? xen-sr-dump looks pretty clumsy
>> to me, but still seems better than a name easily mixed up with
>> others.
> 
> How about xen-domctx?

Hmm, maybe. Seeing this is about PV pieces, xen-pvctx might also be
an option.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:31:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:31:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOHs-0003YS-Dg; Fri, 03 Apr 2020 15:31:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6vR8=5T=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jKOHq-0003YK-Qn
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:31:14 +0000
X-Inumbo-ID: 270dbdc8-75c0-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 270dbdc8-75c0-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 15:31:14 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9F4DCAE5C;
 Fri,  3 Apr 2020 15:31:12 +0000 (UTC)
Subject: Re: [PATCH v7 09/12] xen: add runtime parameter access support to
 hypfs
To: Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-10-jgross@suse.com>
 <f08bdac6-122a-9289-3241-a0460a73c686@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <1a68e135-2761-0ccd-11fc-45344a84757d@suse.com>
Date: Fri, 3 Apr 2020 17:31:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f08bdac6-122a-9289-3241-a0460a73c686@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.20 16:51, Jan Beulich wrote:
> On 02.04.2020 17:46, Juergen Gross wrote:
>> V7:
>> - fine tune some parameter initializations (Jan Beulich)
>> - call custom_runtime_set_var() after updating the value
>> - modify alignment in Arm linker script to 4 (Jan Beulich)
> 
> I didn't ask for this to be unilaterally 4 - I don't think this
> would work on Arm64, seeing that there are pointers inside the
> struct. This wants to be pointer size, i.e. 4 for Arm32 but 8
> for Arm64.

Oh, how silly of me. Should be POINTER_ALIGN, of course.

> 
>> --- a/docs/misc/hypfs-paths.pandoc
>> +++ b/docs/misc/hypfs-paths.pandoc
>> @@ -152,3 +152,12 @@ The major version of Xen.
>>   #### /buildinfo/version/minor = INTEGER
>>   
>>   The minor version of Xen.
>> +
>> +#### /params/
>> +
>> +A directory of runtime parameters.
>> +
>> +#### /params/*
>> +
>> +The individual parameters. The description of the different parameters can be
>> +found in `docs/misc/xen-command-line.pandoc`.
> 
> Is .pandoc a useful specification here, or do such extensions get
> converted when rendering into different formats?

I looked into xenstore-paths.pandoc and found references to other docs
like pvcalls.pandoc. So I assumed it is fine this way.

> 
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -70,6 +70,30 @@ integer_param("ple_window", ple_window);
>>   static bool __read_mostly opt_ept_pml = true;
>>   static s8 __read_mostly opt_ept_ad = -1;
>>   int8_t __read_mostly opt_ept_exec_sp = -1;
>> +static char opt_ept_setting[24];
>> +
>> +static void update_ept_param_append(const char *str, int val)
>> +{
>> +    char *pos = opt_ept_setting + strlen(opt_ept_setting);
>> +
>> +    snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>> +             ",%s=%d", str, val);
>> +}
>> +
>> +static void update_ept_param(void)
>> +{
>> +    snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>> +    if ( opt_ept_ad >= 0 )
>> +        update_ept_param_append("ad", opt_ept_ad);
> 
> With the new patch 1, is the if() here really still needed? Then
> again, only "exec-sp" is a runtime sub-parameter anyway afaict,
> and hence I'd expect only that part of the option should be
> displayed (I'm sorry for not having paid attention to this
> earlier).

Oh, you are right. Will change it.


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:31:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:31:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOIH-0003bk-QZ; Fri, 03 Apr 2020 15:31:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKOIF-0003bS-Sx
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:31:39 +0000
X-Inumbo-ID: 36051650-75c0-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 36051650-75c0-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 15:31:39 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2888AADE8;
 Fri,  3 Apr 2020 15:31:38 +0000 (UTC)
Subject: Re: [PATCH v7 04/12] xen: add basic hypervisor filesystem support
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-5-jgross@suse.com>
 <7dda5c2c-cb81-2cfa-2cf4-4440b49d401a@suse.com>
 <d454afb8-40ff-c8a4-7a5a-6f8f4f4f0e4a@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <1b83570b-17ac-9da4-cfee-fbd44c7d3edf@suse.com>
Date: Fri, 3 Apr 2020 17:31:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <d454afb8-40ff-c8a4-7a5a-6f8f4f4f0e4a@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 17:05, Jürgen Groß wrote:
> On 03.04.20 16:23, Jan Beulich wrote:
>> On 02.04.2020 17:46, Juergen Gross wrote:
>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>> +                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>> +{
>>> +    char *buf;
>>> +    int ret;
>>> +
>>> +    if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>> +         leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>> +        return -EDOM;
>>> +
>>> +    buf = xmalloc_array(char, ulen);
>>> +    if ( !buf )
>>> +        return -ENOMEM;
>>> +
>>> +    ret = -EFAULT;
>>> +    if ( copy_from_guest(buf, uaddr, ulen) )
>>> +        goto out;
>>> +
>>> +    ret = -EINVAL;
>>> +    if ( leaf->e.type == XEN_HYPFS_TYPE_STRING &&
>>> +         memchr(buf, 0, ulen) != (buf + ulen - 1) )
>>> +        goto out;
>>> +
>>> +    ret = 0;
>>> +    memcpy(leaf->write_ptr, buf, ulen);
>>> +    leaf->e.size = ulen;
>>> +
>>> + out:
>>> +    xfree(buf);
>>> +    return ret;
>>> +}
>>> +
>>> +int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
>>> +                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>> +{
>>> +    bool buf;
>>> +
>>> +    ASSERT(leaf->e.type == XEN_HYPFS_TYPE_BOOL && leaf->e.size == sizeof(bool));
>>> +
>>> +    if ( ulen != leaf->e.max_size )
>>
>> Why max_size here when the ASSERT() checks size?
> 
> Just for consistency with the other write functions.

In which case perhaps extend the ASSERT() to also check max_size?

>>> +static int hypfs_write(struct hypfs_entry *entry,
>>> +                       XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>> +{
>>> +    struct hypfs_entry_leaf *l;
>>> +
>>> +    if ( !entry->write )
>>> +        return -EACCES;
>>> +
>>> +    if ( ulen > entry->max_size )
>>> +        return -ENOSPC;
>>
>> max_size being zero for non-writable entries, perhaps use -EACCES
>> also for this special case? Together with the other comment above,
>> maybe the ->write check wants replacing this way?
> 
> Checking the write function being not NULL is a nice security addon,
> as I avoid to call into a non existing function. Basically both tests
> would be equivalent, but this one is IMO better to avoid crashes.

In which case perhaps ASSERT(entry->max_size) between the two if()s?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:33:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOKH-0003nU-7P; Fri, 03 Apr 2020 15:33:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6vR8=5T=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jKOKF-0003nP-S7
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:33:43 +0000
X-Inumbo-ID: 7fcba542-75c0-11ea-bd3a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7fcba542-75c0-11ea-bd3a-12813bfff9fa;
 Fri, 03 Apr 2020 15:33:43 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E86E5ABEF;
 Fri,  3 Apr 2020 15:33:41 +0000 (UTC)
Subject: Re: [PATCH v7 04/12] xen: add basic hypervisor filesystem support
To: Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-5-jgross@suse.com>
 <7dda5c2c-cb81-2cfa-2cf4-4440b49d401a@suse.com>
 <d454afb8-40ff-c8a4-7a5a-6f8f4f4f0e4a@suse.com>
 <1b83570b-17ac-9da4-cfee-fbd44c7d3edf@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <2a38a209-de27-1b83-8034-07f6510739e5@suse.com>
Date: Fri, 3 Apr 2020 17:33:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <1b83570b-17ac-9da4-cfee-fbd44c7d3edf@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.20 17:31, Jan Beulich wrote:
> On 03.04.2020 17:05, Jürgen Groß wrote:
>> On 03.04.20 16:23, Jan Beulich wrote:
>>> On 02.04.2020 17:46, Juergen Gross wrote:
>>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>>> +                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>>> +{
>>>> +    char *buf;
>>>> +    int ret;
>>>> +
>>>> +    if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>>> +         leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>>> +        return -EDOM;
>>>> +
>>>> +    buf = xmalloc_array(char, ulen);
>>>> +    if ( !buf )
>>>> +        return -ENOMEM;
>>>> +
>>>> +    ret = -EFAULT;
>>>> +    if ( copy_from_guest(buf, uaddr, ulen) )
>>>> +        goto out;
>>>> +
>>>> +    ret = -EINVAL;
>>>> +    if ( leaf->e.type == XEN_HYPFS_TYPE_STRING &&
>>>> +         memchr(buf, 0, ulen) != (buf + ulen - 1) )
>>>> +        goto out;
>>>> +
>>>> +    ret = 0;
>>>> +    memcpy(leaf->write_ptr, buf, ulen);
>>>> +    leaf->e.size = ulen;
>>>> +
>>>> + out:
>>>> +    xfree(buf);
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
>>>> +                     XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>>> +{
>>>> +    bool buf;
>>>> +
>>>> +    ASSERT(leaf->e.type == XEN_HYPFS_TYPE_BOOL && leaf->e.size == sizeof(bool));
>>>> +
>>>> +    if ( ulen != leaf->e.max_size )
>>>
>>> Why max_size here when the ASSERT() checks size?
>>
>> Just for consistency with the other write functions.
> 
> In which case perhaps extend the ASSERT() to also check max_size?

Okay.

> 
>>>> +static int hypfs_write(struct hypfs_entry *entry,
>>>> +                       XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>>> +{
>>>> +    struct hypfs_entry_leaf *l;
>>>> +
>>>> +    if ( !entry->write )
>>>> +        return -EACCES;
>>>> +
>>>> +    if ( ulen > entry->max_size )
>>>> +        return -ENOSPC;
>>>
>>> max_size being zero for non-writable entries, perhaps use -EACCES
>>> also for this special case? Together with the other comment above,
>>> maybe the ->write check wants replacing this way?
>>
>> Checking the write function being not NULL is a nice security addon,
>> as I avoid to call into a non existing function. Basically both tests
>> would be equivalent, but this one is IMO better to avoid crashes.
> 
> In which case perhaps ASSERT(entry->max_size) between the two if()s?

Okay.


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:33:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOKM-0003or-GJ; Fri, 03 Apr 2020 15:33:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=qJwk=5T=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jKOKL-0003oj-Lk
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:33:49 +0000
X-Inumbo-ID: 82961e4e-75c0-11ea-bd3a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 82961e4e-75c0-11ea-bd3a-12813bfff9fa;
 Fri, 03 Apr 2020 15:33:49 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 04094AA7C;
 Fri,  3 Apr 2020 15:33:48 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
Date: Fri, 3 Apr 2020 17:33:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 17:12, Jürgen Groß wrote:
> On 03.04.20 16:31, Jan Beulich wrote:
>> On 02.04.2020 17:46, Juergen Gross wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -353,6 +353,16 @@ config DOM0_MEM
>>>           Leave empty if you are not sure what to specify.
>>>   +config HYPFS_CONFIG
>>> +    bool "Provide hypervisor .config via hypfs entry"
>>> +    default y
>>
>> My initial reaction was to ask for "depends on HYPFS", but then
>> I noticed the earlier patch doesn't introduce such. Am I
>> mis-remembering that it was agreed to make the whole thing
>> possible to disable at least in EXPERT mode?
> 
> No, I don't remember that agreement.
> 
> And TBH I'm not sure this is a good idea, as that would at once make the
> plan to replace at least some sysctl and/or domctl interfaces impossible
> (like e.g. the last 3 patches of the series are doing already), or at
> least would tie the related functionality to CONFIG_HYPFS.

I think that would be fine - that's what config setting are for.
Someone caring about space may not care about runtime setting of
parameters.

>>> --- a/xen/common/kernel.c
>>> +++ b/xen/common/kernel.c
>>> @@ -389,6 +389,16 @@ static HYPFS_STRING_INIT(compile_date, "compile_date");
>>>   static HYPFS_STRING_INIT(compile_domain, "compile_domain");
>>>   static HYPFS_STRING_INIT(extra, "extra");
>>>   +#ifdef CONFIG_HYPFS_CONFIG
>>> +static struct hypfs_entry_leaf config = {
>>> +    .e.type = XEN_HYPFS_TYPE_STRING,
>>> +    .e.encoding = XEN_HYPFS_ENC_GZIP,
>>> +    .e.name = "config",
>>> +    .e.read = hypfs_read_leaf,
>>> +    .content = &xen_config_data
>>> +};
>>> +#endif
>>
>> Would be really good if no open-coded instantiations like this
>> one would ever have to appear, i.e. if suitable macros were
>> available. What's preventing use of one of the available ones
>> here?
> 
> Right now it is the only case for a non plain encoding. The alternative
> would have been to either specify the encoding explicitly at all other
> node definitions, or to have a macro for this single instance.

Or set the encoding alongside e.size in the init function?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:36:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:36:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOMi-0003zp-Uy; Fri, 03 Apr 2020 15:36:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=WUFr=5T=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jKOMh-0003zk-An
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:36:15 +0000
X-Inumbo-ID: da12e3da-75c0-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id da12e3da-75c0-11ea-83d8-bc764e2007e4;
 Fri, 03 Apr 2020 15:36:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585928174;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=ehC5Zoms2zII/jTyHLjKNjAR4lgbza6Xch3tXf1f8mM=;
 b=LAsoRaUWcGX1HdSOBMEhF3lQzRR0Rhw2ib9LAt51OtxR2lZc6RXxKyCn
 l4T/JO6GuGDKKyAUxtc2PaAF3svgHahSzkn9eAStBDEz/fyp5wl75FRPZ
 wJ3qdfz+kdAeB7yDO37kRje6omH0YGtPsvBsSjFx5KMzexXbNC/V07taQ U=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 1gTVzJ0cZTpS1yZsyQA2/zDk+PGZGOHMc7mqmx6/HBrUwpUVLuE5/gdJvDcw923AH3HjVJr+dp
 FtrRNzI4NvjvVV7z954/c7N3IokfdSAC92pzqYep8M7zHIrijnwCU1NKsRdaCpATJD9OzDWf/5
 VFYcNFiNx8yC2fKwnQVzWJaYWKMmGBTOyp/XLRKS9C53Z2h/062/IdvfUUXstjpJqewCG8wLFg
 PDRUiouukSdYhQtpyzxvtJ9c9I2ohYgtY27XtlJTBsb+u4IVvBKWbJCfjQkscgVlbkxyqnDKpo
 I+M=
X-SBRS: 2.7
X-MesageID: 15549666
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15549666"
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: Jan Beulich <jbeulich@suse.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
 <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
 <0faaee38-e314-24a8-b97d-9f000251a63e@citrix.com>
 <9cba6eda-2c7c-9700-a484-c72100b8268f@citrix.com>
 <050e4847-df42-6e16-3707-19fadbae9229@suse.com>
 <c4b676a9-58ce-ae11-e13b-aae41b6c27b1@citrix.com>
 <24e20e5d-c661-3f40-ceb0-e0c6f0a753b2@suse.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <7827d387-90be-a538-a41c-af104a7b2dd3@citrix.com>
Date: Fri, 3 Apr 2020 16:36:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <24e20e5d-c661-3f40-ceb0-e0c6f0a753b2@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, roger.pau@citrix.com,
 ian.jackson@eu.citrix.com, wl@xen.org, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03/04/2020 16:28, Jan Beulich wrote:
> On 03.04.2020 17:17, Igor Druzhinin wrote:
>> On 03/04/2020 16:05, Jan Beulich wrote:
>>> On 03.04.2020 16:47, Igor Druzhinin wrote:
>>>> There multiple technical complications that caused this mess.
>>>> One of them is that there is no unfortunately a better place for the
>>>> framebuffer to be located initially. Second, SR-IOV device
>>>> is real and adding a virtual BAR to it is also complicated (due to
>>>> compatibility reasons) and NVIDIA decided to avoid that.
>>>
>>> In which case I wonder - aren't you ending up with the MMIO case
>>> that I had mentioned, and that you said is difficult to deal with?
>>
>> No, it's VRAM area (normal RAM pages) - not MMIO.
> 
> Well, VRAM is still MMIO from the CPU's perspective, just without
> any side effects. But if it was another device that was passed
> through, couldn't its MMIO similarly end up in that area?

As Andrew said, Xen VRAM is just normal RAM. It's originally
populated in this area for the lack of a better place (at least now).
It's special and has nothing to do with the device passed through
using conventional PCI mechanisms which BARs will only occupy MMIO hole.

Igor


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:45:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:45:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOVS-0004s7-Rt; Fri, 03 Apr 2020 15:45:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6vR8=5T=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jKOVR-0004s2-Qe
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:45:17 +0000
X-Inumbo-ID: 1cd3ce40-75c2-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1cd3ce40-75c2-11ea-83d8-bc764e2007e4;
 Fri, 03 Apr 2020 15:45:16 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B6358AA7C;
 Fri,  3 Apr 2020 15:45:14 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
Date: Fri, 3 Apr 2020 17:45:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.20 17:33, Jan Beulich wrote:
> On 03.04.2020 17:12, Jürgen Groß wrote:
>> On 03.04.20 16:31, Jan Beulich wrote:
>>> On 02.04.2020 17:46, Juergen Gross wrote:
>>>> --- a/xen/common/Kconfig
>>>> +++ b/xen/common/Kconfig
>>>> @@ -353,6 +353,16 @@ config DOM0_MEM
>>>>            Leave empty if you are not sure what to specify.
>>>>    +config HYPFS_CONFIG
>>>> +    bool "Provide hypervisor .config via hypfs entry"
>>>> +    default y
>>>
>>> My initial reaction was to ask for "depends on HYPFS", but then
>>> I noticed the earlier patch doesn't introduce such. Am I
>>> mis-remembering that it was agreed to make the whole thing
>>> possible to disable at least in EXPERT mode?
>>
>> No, I don't remember that agreement.
>>
>> And TBH I'm not sure this is a good idea, as that would at once make the
>> plan to replace at least some sysctl and/or domctl interfaces impossible
>> (like e.g. the last 3 patches of the series are doing already), or at
>> least would tie the related functionality to CONFIG_HYPFS.
> 
> I think that would be fine - that's what config setting are for.
> Someone caring about space may not care about runtime setting of
> parameters.

So right now it would start with a plain hypfs available or not.

The next step would be in patch 12 to tell the user he will lose the
capability of setting runtime parameters.

Another planned extension would be to control per-cpupool settings,
which would the go away (possibly functionality being unconditionally
available today).

Next would be the lack of being able to control per-domain mitigations
like XPTI or L1TF, which I'd like to add.

Another thing I wanted to add is some debugging stuff (e.g. to switch
lock profiling using hypfs).

And the list will go on.

Does it really make sense to make a central control and information
interface conditional?

I'd like at least a second opinion on that topic.

> 
>>>> --- a/xen/common/kernel.c
>>>> +++ b/xen/common/kernel.c
>>>> @@ -389,6 +389,16 @@ static HYPFS_STRING_INIT(compile_date, "compile_date");
>>>>    static HYPFS_STRING_INIT(compile_domain, "compile_domain");
>>>>    static HYPFS_STRING_INIT(extra, "extra");
>>>>    +#ifdef CONFIG_HYPFS_CONFIG
>>>> +static struct hypfs_entry_leaf config = {
>>>> +    .e.type = XEN_HYPFS_TYPE_STRING,
>>>> +    .e.encoding = XEN_HYPFS_ENC_GZIP,
>>>> +    .e.name = "config",
>>>> +    .e.read = hypfs_read_leaf,
>>>> +    .content = &xen_config_data
>>>> +};
>>>> +#endif
>>>
>>> Would be really good if no open-coded instantiations like this
>>> one would ever have to appear, i.e. if suitable macros were
>>> available. What's preventing use of one of the available ones
>>> here?
>>
>> Right now it is the only case for a non plain encoding. The alternative
>> would have been to either specify the encoding explicitly at all other
>> node definitions, or to have a macro for this single instance.
> 
> Or set the encoding alongside e.size in the init function?

Hmm, that's an option, yes.


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:55:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOes-0005jv-PJ; Fri, 03 Apr 2020 15:55:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6vR8=5T=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jKOer-0005jq-9l
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:55:01 +0000
X-Inumbo-ID: 78e506da-75c3-11ea-bd40-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 78e506da-75c3-11ea-bd40-12813bfff9fa;
 Fri, 03 Apr 2020 15:55:00 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9FE77ABE9;
 Fri,  3 Apr 2020 15:54:58 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: torvalds@linux-foundation.org
Subject: [GIT PULL] xen: branch for v5.7-rc1
Date: Fri,  3 Apr 2020 17:54:57 +0200
Message-Id: <20200403155457.27562-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
 linux-kernel@vger.kernel.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.7-rc1-tag

xen: branch for v5.7-rc1

It contains:

- a cleanup patch removing an unused function
- a small fix for the xen pciback driver
- a series for making the unwinder hyppay with the Xen PV guest idle
  task stacks

Thanks.

Juergen

 arch/x86/xen/smp_pv.c                |   3 +-
 arch/x86/xen/xen-head.S              |  18 ++++-
 drivers/xen/xen-pciback/conf_space.c |   2 +-
 drivers/xen/xen-pciback/conf_space.h |   8 +--
 drivers/xen/xenbus/xenbus_client.c   | 126 ++++++++++++-----------------------
 include/xen/xenbus.h                 |   7 --
 6 files changed, 65 insertions(+), 99 deletions(-)

Juergen Gross (1):
      xen/xenbus: remove unused xenbus_map_ring()

Marek Marczykowski-Górecki (1):
      xen-pciback: fix INTERRUPT_TYPE_* defines

Miroslav Benes (2):
      x86/xen: Make the boot CPU idle task reliable
      x86/xen: Make the secondary CPU idle tasks reliable


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 15:55:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 15:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOfd-0005mp-3o; Fri, 03 Apr 2020 15:55:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DmfO=5T=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jKOfb-0005me-Pv
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 15:55:47 +0000
X-Inumbo-ID: 9494c1cc-75c3-11ea-b58d-bc764e2007e4
Received: from mail-wr1-x435.google.com (unknown [2a00:1450:4864:20::435])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9494c1cc-75c3-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 15:55:46 +0000 (UTC)
Received: by mail-wr1-x435.google.com with SMTP id s8so6988459wrt.7
 for <xen-devel@lists.xenproject.org>; Fri, 03 Apr 2020 08:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=kAK5KeGfSYohh9CF6RBLw/ib08zMtUz/ZOXCfdxUIW0=;
 b=RCeIsUrz/6zBYEDVgBtqAJhdKNtMBeovkf7iun//HG1iq/mPy0v578gTCsUuZkKm2x
 tVxAbi9gejh82tjNjHUEDpdEsSUIOmSxiWcOEDQ9MEQprrb7qha1A7Mpe9QyTe/JumSu
 P+adZbSGiFaqM9gtz7vaeYvAe/pW31OaAavW7jWzx7rbB8bewqz16ZDtxFlH8rwom073
 1GcFpTe2OkAkP+HTkU5kHtyrlCXhMfVcye1H0W7kcIvygJvWk3h+0IeN38FXptqZRT+Y
 t3op7ZP47647HSDeYzYe777FyxkGsvfca6AGtTz2yWNIXZGDvlEAw9Nq6X8ZU9lt61oh
 15uQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=kAK5KeGfSYohh9CF6RBLw/ib08zMtUz/ZOXCfdxUIW0=;
 b=iHWLbNVv1g3tof5XQvZsL6IIBRi6x23y8i06vyl9avpwhlpzfr2QRNthPPaBbMsw45
 5OoAmAF9hCl1dRHVIAtjFOPBfw3izB2NfuXwpeQbXGCt5unmpvaE0Nk8pSXYizREEne9
 3mbPROIPINRqnTX4zexg8WSazTCSyOakRCWJm8bQtzuncw4nqdgb99ojKIucdYPJBTR8
 UJ0e4PpU8QqzgFOasU4sKMHMX5nqnJOsJKG9IaFtSdt08ScGYYN6yYftDK+Pqozi8L0H
 nShPJHb2jy+LMLnjYL6YyOTvp7+6xlo2acrxaHaIgzcnOiWOu7i5Q4wU6OoVAXsy08Ct
 jqZQ==
X-Gm-Message-State: AGi0PuZoyaIfYHWlbLkVfCoVblDNMEzOm48loyaUPbwbODVC1xJZIlIB
 r2AmPqXr0c+tGWeZQ2Zewmc=
X-Google-Smtp-Source: APiQypLjc0R1uBlIXWdEBnBitrykVgB1gnqCsV3emhtzTPpb+8jKZotRabmW49FI+TTeosIwqWXM6w==
X-Received: by 2002:adf:edcf:: with SMTP id v15mr9538603wro.309.1585929345575; 
 Fri, 03 Apr 2020 08:55:45 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id v186sm11919849wme.24.2020.04.03.08.55.44
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 03 Apr 2020 08:55:44 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
In-Reply-To: <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
Subject: RE: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
Date: Fri, 3 Apr 2020 16:55:43 +0100
Message-ID: <002201d609d0$55a76690$00f633b0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQG3I8TZM/MLMEc/e2It3WEXPZVs8AC9qttvAt7KY/2oiG08cA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
[snip]
> > +
> > +#include <xen/save.h>
> > +
> > +struct domain_context {
> > +    bool log;
> > +    struct domain_save_descriptor desc;
> > +    domain_copy_entry copy;
>=20
> As your new framework is technically an extension of existing one, it
> would be good to explain why we diverge in the definitions.
>=20

I don't follow. What is diverging? I explain in the commit comment that =
this is a parallel framework. Do I need to justify why it is not a =
carbon copy of the HVM one?

> > +    void *priv;
> > +};
> > +
> > +static struct {
> > +    const char *name;
> > +    bool per_vcpu;
> > +    domain_save_handler save;
> > +    domain_load_handler load;
> > +} handlers[DOMAIN_SAVE_CODE_MAX + 1];
> > +
> > +void __init domain_register_save_type(unsigned int tc, const char =
*name,
> > +                                      bool per_vcpu,
> > +                                      domain_save_handler save,
> > +                                      domain_load_handler load)
> > +{
> > +    BUG_ON(tc > ARRAY_SIZE(handlers));
> > +
> > +    ASSERT(!handlers[tc].save);
> > +    ASSERT(!handlers[tc].load);
> > +
> > +    handlers[tc].name =3D name;
> > +    handlers[tc].per_vcpu =3D per_vcpu;
> > +    handlers[tc].save =3D save;
> > +    handlers[tc].load =3D load;
> > +}
> > +
> > +int domain_save_entry(struct domain_context *c, unsigned int tc,
> > +                      const char *name, const struct vcpu *v, void =
*src,
>=20
> I realize that 'src' is not const because how you define copy, however =
I
> would rather prefer if we rework the interface to avoid to keep the
> const in the definition. This may mean to have to define two callback
> rather than one.

That seems a bit ugly for the sake of a const but I guess I could create =
a union with a copy_in and copy_out. I'll see how that looks.

>=20
> > +                      size_t src_len)
>=20
> On 64-bit architecture, size_t would be 64-bit. But the record is only
> storing 32-bit. Would it make sense to add some sanity check in the =
code?
>=20

True. Given this is new I think I'll just bump the length to 64-bits.

> > +{
> > +    int rc;
> > +
> > +    if ( c->log && tc !=3D DOMAIN_SAVE_CODE(HEADER) &&
> > +         tc !=3D DOMAIN_SAVE_CODE(END) )
> > +        gdprintk(XENLOG_INFO, "%pv save: %s (%lu)\n", v, name, =
src_len);
> > +
> > +    if ( !IS_ALIGNED(src_len, 8) )
>=20
> Why not adding an implicit padding? This would avoid to chase error
> during saving because the len wasn't a multiple of 8.
>=20

I don't think implicit padding is worth it. This error should only =
happen if a badly defined save record type is added to the code so =
perhaps I ought to add an ASSERT here as well as deal with the error.

> > +        return -EINVAL;
> > +
> > +    BUG_ON(tc !=3D c->desc.typecode);
> > +    BUG_ON(v->vcpu_id !=3D c->desc.instance);
>=20
> Does the descriptor really need to be filled by domain_save()? Can't =
it
> be done here, so we can avoid the two BUG_ON()s?
>=20

Yes it can but this serves as a sanity check that the save code is =
actually doing what it should. Hence why these are BUG_ON()s and not =
error exits.

> > +    c->desc.length =3D src_len;
> > +
> > +    rc =3D c->copy(c->priv, &c->desc, sizeof(c->desc));
> > +    if ( rc )
> > +        return rc;
> > +
> > +    return c->copy(c->priv, src, src_len);
> > +}
> > +
> > +int domain_save(struct domain *d, domain_copy_entry copy, void =
*priv,
> > +                unsigned long mask, bool dry_run)
> > +{
> > +    struct domain_context c =3D {
> > +        .copy =3D copy,
> > +        .priv =3D priv,
> > +        .log =3D !dry_run,
> > +    };
> > +    struct domain_save_header h =3D {
> > +        .magic =3D DOMAIN_SAVE_MAGIC,
> > +        .version =3D DOMAIN_SAVE_VERSION,
> > +    };
> > +    struct domain_save_header e;
> > +    unsigned int i;
> > +    int rc;
> > +
> > +    ASSERT(d !=3D current->domain);
> > +
> > +    if ( d->is_dying )
> > +        return -EINVAL;
> > +
> > +    domain_pause(d);
> > +
> > +    c.desc.typecode =3D DOMAIN_SAVE_CODE(HEADER);
> > +
> > +    rc =3D DOMAIN_SAVE_ENTRY(HEADER, &c, d->vcpu[0], &h, =
sizeof(h));
> > +    if ( rc )
> > +        goto out;
> > +
> > +    for ( i =3D 0; i < ARRAY_SIZE(handlers); i++ )
>=20
> AFAIU, with this solution, if there are dependency between records, =
the
> dependencies will have to a lower "index". I think we may have some
> dependency with guest transparent migration such as we need to restore
> the event ABI before restoring the event channels.
>=20

Is that just a downstream implementation detail though? I would hope =
that there are no ordering dependencies between records.

> Should we rely on the index for the dependency?
>

If we do need ordering dependencies then I guess it would need to be =
explicit.
=20
> In any case, I think we want to document it.
>

I can certainly document that save handlers are invoked in code order.

> > +    {
> > +        domain_save_handler save =3D handlers[i].save;
> > +
> > +        if ( (mask && !test_bit(i, &mask)) || !save )
>=20
> The type of mask suggests it is not possible to have more than 32
> different types of record if we wanted to be arch agnostic. Even if we
> focus on 64-bit arch, this is only 64 records.
>=20
> This is not very future proof, but might be ok if this is not exposed
> outside of the hypervisor (I haven't looked at the rest of the series
> yet). However, we at least need a BUILD_BUG_ON() in place. So please
> make sure  DOMAIN_SAVE_CODE_MAX is always less than 64.
>=20
> Also what if there is a bit set in the mask and the record is not
> existing? Shouldn't we return an error?
>=20

TBH I think 32 will be enough... I would not expect this context space =
to grow very much, if at all, once transparent migration is working. I =
think I'll just drop the mask for now; it's not actually clear to me =
we'll make use of it... just seemed like a nice-to-have.

> > +            continue;
> > +
> > +        memset(&c.desc, 0, sizeof(c.desc));
> > +        c.desc.typecode =3D i;
> > +
> > +        if ( handlers[i].per_vcpu )
> > +        {
> > +            struct vcpu *v;
> > +
> > +            for_each_vcpu ( d, v )
> > +            {
> > +                c.desc.instance =3D v->vcpu_id;
> > +
> > +                rc =3D save(v, &c, dry_run);
> > +                if ( rc )
> > +                    goto out;
> > +            }
> > +        }
> > +        else
> > +        {
> > +            rc =3D save(d->vcpu[0], &c, dry_run);
> > +            if ( rc )
> > +                goto out;
> > +        }
> > +    }
> > +
> > +    memset(&c.desc, 0, sizeof(c.desc));
> > +    c.desc.typecode =3D DOMAIN_SAVE_CODE(END);
> > +
> > +    rc =3D DOMAIN_SAVE_ENTRY(END, &c, d->vcpu[0], &e, 0);
> > +
> > + out:
> > +    domain_unpause(d);
> > +
> > +    return rc;
> > +}
> > +
> > +int domain_load_entry(struct domain_context *c, unsigned int tc,
> > +                      const char *name, const struct vcpu *v, void =
*dst,
> > +                      size_t dst_len, bool exact)
> > +{
> > +    int rc;
> > +
> > +    if ( c->log && tc !=3D DOMAIN_SAVE_CODE(HEADER) &&
> > +         tc !=3D DOMAIN_SAVE_CODE(END) )
> > +        gdprintk(XENLOG_INFO, "%pv load: %s (%lu)\n", v, name, =
dst_len);
> > +
> > +    BUG_ON(tc !=3D c->desc.typecode);
> > +    BUG_ON(v->vcpu_id !=3D c->desc.instance);
>=20
> Is it really warrant to crash the host? What would happen if the =
values
> were wrong?
>=20

It would mean the code is fairly seriously buggy in that the load =
handler is trying to load a record other than the type it registered =
for, or for a vcpu other than the one it was passed.

> > +
> > +    if ( (exact ?
> > +          (dst_len !=3D c->desc.length) : (dst_len < =
c->desc.length)) ||
>=20
> Using ternary in if is really confusing. How about:
>=20
> dst_len < c->desc.length || (exact && dst_len !=3D c->desc.length) ||
>=20
> I understand that there would be two check for the exact case but I
> think it is better than a ternary.

I'm going to re-work this I think.

>=20
> However what is the purpose of the param 'exact'? If you set it to =
false
> how do you know the size you read?

The point of the exact parameter is that whether the caller can only =
consume a record of the correct length, or whether it can handle an =
undersize one which gets zero-padded. (It's the same as the zeroextend =
option in HVM records).

>=20
> > +         !IS_ALIGNED(c->desc.length, 8) )
> > +        return -EINVAL;
> > +
> > +    rc =3D c->copy(c->priv, dst, c->desc.length);
> > +    if ( rc )
> > +        return rc;
> > +
> > +    if ( !exact )
> > +    {
> > +        dst +=3D c->desc.length;
> > +        memset(dst, 0, dst_len - c->desc.length);
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> > +int domain_load(struct domain *d,  domain_copy_entry copy, void =
*priv,
> > +                unsigned long mask)
> > +{
> > +    struct domain_context c =3D {
> > +        .copy =3D copy,
> > +        .priv =3D priv,
> > +        .log =3D true,
> > +    };
> > +    struct domain_save_header h, e;
> > +    int rc;
> > +
> > +    ASSERT(d !=3D current->domain);
> > +
> > +    if ( d->is_dying )
> > +        return -EINVAL;
>=20
> What does protect you against the doing dying right after this check?
>=20

Nothing. It's just to avoid doing pointless work if we can.

> > +
> > +    rc =3D c.copy(c.priv, &c.desc, sizeof(c.desc));
> > +    if ( rc )
> > +        return rc;
> > +
> > +    if ( c.desc.typecode !=3D DOMAIN_SAVE_CODE(HEADER) ||
> > +         c.desc.instance !=3D 0 )
> > +        return -EINVAL;
> > +
> > +    rc =3D DOMAIN_LOAD_ENTRY(HEADER, &c, d->vcpu[0], &h, sizeof(h), =
true);
> > +    if ( rc )
> > +        return rc;
> > +
> > +    if ( h.magic !=3D DOMAIN_SAVE_MAGIC || h.version !=3D =
DOMAIN_SAVE_VERSION )
> > +        return -EINVAL;
> > +
> > +    domain_pause(d);
> > +
> > +    for (;;)
> > +    {
> > +        unsigned int i;
> > +        domain_load_handler load;
> > +        struct vcpu *v;
> > +
> > +        rc =3D c.copy(c.priv, &c.desc, sizeof(c.desc));
> > +        if ( rc )
> > +            break;
> > +
> > +        if ( c.desc.typecode =3D=3D DOMAIN_SAVE_CODE(END) ) {
> > +            rc =3D DOMAIN_LOAD_ENTRY(END, &c, d->vcpu[0], &e, 0, =
true);
> > +            break;
> > +        }
> > +
> > +        rc =3D -EINVAL;
> > +        if ( c.desc.typecode >=3D ARRAY_SIZE(handlers) ||
> > +             c.desc.instance >=3D d->max_vcpus )
>=20
> Nothing in the documention suggests that c.desc.instance should be 0
> when the record is for the domain.
>=20

Ok. I'll put a comment somewhere.

> > +            break;
> > +
> > +        i =3D c.desc.typecode;
> > +        load =3D handlers[i].load;
> > +        v =3D d->vcpu[c.desc.instance];
> > +
> > +        if ( mask && !test_bit(i, &mask) )
> > +        {
> > +            /* Sink the data */
> > +            rc =3D c.copy(c.priv, NULL, c.desc.length);
> > +            if ( rc )
> > +                break;
> > +
> > +            continue;
> > +        }
> > +
> > +        rc =3D load ? load(v, &c) : -EOPNOTSUPP;
> > +        if ( rc )
> > +            break;
> > +    }
> > +
> > +    domain_unpause(d);
> > +
> > +    return rc;
> > +}
> > +
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-file-style: "BSD"
> > + * c-basic-offset: 4
> > + * tab-width: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> > diff --git a/xen/include/public/save.h b/xen/include/public/save.h
> > new file mode 100644
> > index 0000000000..84981cd0f6
> > --- /dev/null
> > +++ b/xen/include/public/save.h
> > @@ -0,0 +1,74 @@
> > +/*
> > + * save.h
> > + *
> > + * Structure definitions for common PV/HVM domain state that is =
held by
> > + * Xen and must be saved along with the domain's memory.
> > + *
> > + * Copyright Amazon.com Inc. or its affiliates.
> > + *
> > + * Permission is hereby granted, free of charge, to any person =
obtaining a copy
> > + * of this software and associated documentation files (the =
"Software"), to
> > + * deal in the Software without restriction, including without =
limitation the
> > + * rights to use, copy, modify, merge, publish, distribute, =
sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the =
Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be =
included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, =
EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF =
MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO =
EVENT SHALL THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR =
OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, =
ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR =
OTHER
> > + * DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#ifndef __XEN_PUBLIC_SAVE_H__
> > +#define __XEN_PUBLIC_SAVE_H__
> > +
> > +#include "xen.h"
> > +
> > +/* Each entry is preceded by a descriptor */
> > +struct domain_save_descriptor {
> > +    uint16_t typecode;
> > +    uint16_t instance;
> > +    /*
> > +     * Entry length not including this descriptor. Entries must be =
padded
> > +     * to a multiple of 8 bytes to make sure descriptors remain =
correctly
> > +     * aligned.
> > +     */
> > +    uint32_t length;
> > +};
> > +
> > +/*
> > + * Each entry has a type associated with it. =
DECLARE_DOMAIN_SAVE_TYPE
> > + * binds these things together.
> > + */
> > +#define DECLARE_DOMAIN_SAVE_TYPE(_x, _code, _type) \
> > +    struct __DOMAIN_SAVE_TYPE_##_x { _type t; char c[_code]; };
> > +
> > +#define DOMAIN_SAVE_TYPE(_x) \
> > +    typeof (((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->t)
> > +#define DOMAIN_SAVE_CODE(_x) \
> > +    (sizeof (((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->c))
> > +#define DOMAIN_SAVE_MASK(_x) (1u << DOMAIN_SAVE_CODE(_x))
> > +
> > +/* Terminating entry */
> > +struct domain_save_end {};
> > +DECLARE_DOMAIN_SAVE_TYPE(END, 0, struct domain_save_end);
> > +
> > +#define DOMAIN_SAVE_MAGIC   0x53415645
> > +#define DOMAIN_SAVE_VERSION 0x00000001
> > +
> > +/* Initial entry */
> > +struct domain_save_header {
> > +    uint32_t magic;             /* Must be DOMAIN_SAVE_MAGIC */
> > +    uint32_t version;           /* Save format version */
>=20
> Would it make sense to have the version of Xen in the stream?
>=20

Why? How would it help?

  Paul



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 16:09:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOsJ-0007HQ-GM; Fri, 03 Apr 2020 16:08:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DmfO=5T=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jKOsI-0007HL-E0
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 16:08:54 +0000
X-Inumbo-ID: 69d09cca-75c5-11ea-83d8-bc764e2007e4
Received: from mail-wr1-x435.google.com (unknown [2a00:1450:4864:20::435])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 69d09cca-75c5-11ea-83d8-bc764e2007e4;
 Fri, 03 Apr 2020 16:08:53 +0000 (UTC)
Received: by mail-wr1-x435.google.com with SMTP id m17so9128806wrw.11
 for <xen-devel@lists.xenproject.org>; Fri, 03 Apr 2020 09:08:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=0y41U1ZJATzuc4am2cSQTNFJJtdkrB4HlZZXeNT5NSE=;
 b=s7ARfL4I1IXzgYPP59bpz8+8apUkk0r2vZT3+CF7nDTkXSIQizEAZV7V5Rq1ZiDXmg
 sxiQ0cNEYmhVcaXSzS56foZ/p5kuOmcvTQofiu5UHUJx8SxlTIBZUVl6nm9sxp7i2KBd
 qv+AtXUXJwZsIkuhLS58CRSIPiNxmIAIhJrWNJioCffHfmF094jXFcOYHtc7vCWGzSEh
 AZklz5trKB+RcocE79T68YG+7TVesQyQ6C+CSu/TpYka804wiOKFQIzPqrTDamk0GIOQ
 11HsoKrrV8I/d5wjGGbC3NAEYJUtGXd4zjhxfxlEgxwihi3Xt4MIWW2S31brg8AtHLsB
 SnRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=0y41U1ZJATzuc4am2cSQTNFJJtdkrB4HlZZXeNT5NSE=;
 b=RVyRAHAz4Xrl5+t7g3dA+p9H6a8iveNDzMZ57txtwDi1NeIhPDJiL/PiLUuNNvuiyz
 e/RTAdkKjZdFs77QrWTIRRkNu083b9UD0rtKFAKfZdr7kCtzBT0AzxWjBmRu1PDHfVhY
 7ivs0XnlaCFWG8s2UvamsHSDW5fXaRdRCDedOTK6/qmY2RS1NUB3cHxAGQxBgjKpsHQ5
 lwsC1sE5AC0AtxS6W9RslO6bHV1J5hMZ9ipww5ZY37R61gkEkxgHW86PkKAlKyP7aBhX
 khCZrMCm7AIbcx31c0hfcxspOGYnl6Mb/tgica85Fr+R5UGjK9I4DR2+as242HN7u6gM
 hlWQ==
X-Gm-Message-State: AGi0PuZJwZvkaWOXT/UffuFxVu7Xin2AllhLPpIoTOR8t4K599c89QxO
 qAzkkXgX36a0GEItDZCNQqE=
X-Google-Smtp-Source: APiQypLUsRj/fOnC+mRYii/6OIpy2RsRbSx6wsMEBLAWiDXF3/8RQt2uuqs7a2oQg4hiE/ELRrWeZw==
X-Received: by 2002:adf:f08b:: with SMTP id n11mr7240484wro.323.1585930132865; 
 Fri, 03 Apr 2020 09:08:52 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id z203sm12131623wmg.12.2020.04.03.09.08.51
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 03 Apr 2020 09:08:52 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-4-paul@xen.org>
 <b94676ab-371b-bb69-0d07-dd38fe22ceba@suse.com>
 <001e01d609cb$64913fa0$2db3bee0$@xen.org>
 <f04d7e53-b1d9-a304-a7ac-64238836eca5@suse.com>
In-Reply-To: <f04d7e53-b1d9-a304-a7ac-64238836eca5@suse.com>
Subject: RE: [PATCH 3/5] tools/misc: add xen-ctx to present domain context
Date: Fri, 3 Apr 2020 17:08:50 +0100
Message-ID: <002301d609d2$2ae8a480$80b9ed80$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQG3I8TZM/MLMEc/e2It3WEXPZVs8AIR6g5qAoK3rZoCJSYWbwIOuLj5qF8YKXA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'Wei Liu' <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 03 April 2020 16:30
> To: paul@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Ian Jackson' =
<ian.jackson@eu.citrix.com>; 'Wei Liu' <wl@xen.org>
> Subject: Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain =
context
>=20
> On 03.04.2020 17:20, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: 30 March 2020 11:54
> >> To: Paul Durrant <paul@xen.org>
> >> Cc: xen-devel@lists.xenproject.org; Ian Jackson =
<ian.jackson@eu.citrix.com>; Wei Liu <wl@xen.org>
> >> Subject: Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain =
context
> >>
> >> On 27.03.2020 19:50, Paul Durrant wrote:
> >>> This tools is analogous to 'xen-hvmctx' which presents HVM =
context.
> >>> Subsequent patches will add 'dump' functions when new records are
> >>> introduced.
> >>>
> >>> Signed-off-by: Paul Durrant <paul@xen.org>
> >>> ---
> >>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>> Cc: Wei Liu <wl@xen.org>
> >>> ---
> >>>  .gitignore           |   1 +
> >>>  tools/misc/Makefile  |   4 ++
> >>>  tools/misc/xen-ctx.c | 144 =
+++++++++++++++++++++++++++++++++++++++++++
> >>
> >> Is xen-ctx a good choice of a name, considering we already have not
> >> only xen-hvmctx, but also xenctx? If the new functionality isn't a
> >> good fit for either, perhaps its name would better reflect its
> >> connection to save/restore records? xen-sr-dump looks pretty clumsy
> >> to me, but still seems better than a name easily mixed up with
> >> others.
> >
> > How about xen-domctx?
>=20
> Hmm, maybe. Seeing this is about PV pieces, xen-pvctx might also be
> an option.

Yes, that would work but it also implies it might only be valid for PV =
domains. I also prefer 'domctx' since it better matches the name I chose =
for the framework.

  Paul



From xen-devel-bounces@lists.xenproject.org Fri Apr 03 16:16:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 16:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKOzn-00085g-Br; Fri, 03 Apr 2020 16:16:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DmfO=5T=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jKOzm-00085b-8N
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 16:16:38 +0000
X-Inumbo-ID: 7e525c14-75c6-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7e525c14-75c6-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 16:16:37 +0000 (UTC)
Received: by mail-ed1-x544.google.com with SMTP id de14so9900617edb.4
 for <xen-devel@lists.xenproject.org>; Fri, 03 Apr 2020 09:16:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=JXnAs7PB0D0XSzaENfgTFNKheDadagnj92ewXtvYShs=;
 b=cftuOYhNNXPnOze2+N+4ekrHOOqIpMdDsmBrNQFgF3R5ypr48DRQe+zy3sxljp1XlE
 0Z3XZYLx59YjRDssTaKtGipNnVuSzfbSq7rtGhXWw5oOsydI5nR0jCHpUG7Whx6aQSgM
 2lYfoa4q02a8DSG4KDxrsqHcxt6CqEegD1EqwpkR1Zw1VZ++jOfV4d274QwowoQRCAdc
 NFkkRNw/f1cxnPv+aIS7KUDRHqeTgoYjOqSXOUVz+pi9FCLCZEt/5mdAeUUVw4ORBb6g
 /xRJFTuoOxIuwqzgDzLjarP/aY9/JSjLqm2XZ/IAT80t6eVQwFCrlQk3+vwqWpCflRI7
 NpEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=JXnAs7PB0D0XSzaENfgTFNKheDadagnj92ewXtvYShs=;
 b=l0pRWxvrLCS2vBAwF0BtpD8EC0pcf/0MoQBSP4+bgcTumSMF+FhMH3AKMJZuSLsd0u
 jdgUBW9Wpi36DfZaLz9osXJdse0tNnNNAo/+1mxTen/lpSZ2HjW6eXafag0/KeiklgZS
 WrUdfO0eRUYIRrLyNetOZ55MKWHADJ81JGWTJdN2mF1g/x+iHgFxM4iUrb6nOMpEP72/
 2umJon80mr6ZhkvfwVJSIaKXHMSDJHp7F27QvqBxytQhuY9aC24ZHmaAkJXYueTGzqiP
 TITvedzIZaQGESpRgSRIyrthXda5B/+h9uaFz3RIQ56LgK9AA0LyK6JzKPTiZx4xwhqe
 wFIg==
X-Gm-Message-State: AGi0PuYxgxb3G96yAUfsCSNOnAQpAJ32R7CO+GAQpexAeGSuXOTWfL5J
 TfqY6Ux7HWBVuBKy7rPMoWY=
X-Google-Smtp-Source: APiQypLgI2LG046VwBNjr2fdyMYsh/9PLXJo0Uhy1WG8oFeeZF+nz+Vqu9XX9gIdkbyKJ1kLz6aBNg==
X-Received: by 2002:a17:906:405b:: with SMTP id
 y27mr9350959ejj.213.1585930596742; 
 Fri, 03 Apr 2020 09:16:36 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id j9sm1474523edl.67.2020.04.03.09.16.35
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 03 Apr 2020 09:16:36 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Igor Druzhinin'" <igor.druzhinin@citrix.com>,
 "'Jan Beulich'" <jbeulich@suse.com>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
 <66ee36a9-b525-50d4-17e8-8a10f6afd55f@suse.com>
 <0faaee38-e314-24a8-b97d-9f000251a63e@citrix.com>
 <9cba6eda-2c7c-9700-a484-c72100b8268f@citrix.com>
 <050e4847-df42-6e16-3707-19fadbae9229@suse.com>
 <c4b676a9-58ce-ae11-e13b-aae41b6c27b1@citrix.com>
 <24e20e5d-c661-3f40-ceb0-e0c6f0a753b2@suse.com>
 <7827d387-90be-a538-a41c-af104a7b2dd3@citrix.com>
In-Reply-To: <7827d387-90be-a538-a41c-af104a7b2dd3@citrix.com>
Subject: RE: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
Date: Fri, 3 Apr 2020 17:16:34 +0100
Message-ID: <002401d609d3$3f6b62c0$be422840$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQG43QgZrYFtbI4DTXRTLQ+qV9/XEwI0/7ePAeAaX+8BZMC3uwEJJlr6Aj+gMhMCf4lRzQIXFG6lqDch/gA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>, ian.jackson@eu.citrix.com,
 xen-devel@lists.xenproject.org, wl@xen.org, roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of =
Igor Druzhinin
> Sent: 03 April 2020 16:36
> To: Jan Beulich <jbeulich@suse.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; roger.pau@citrix.com; =
ian.jackson@eu.citrix.com;
> wl@xen.org; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH] hvmloader: probe memory below 4G before =
allocation for OVMF
>=20
> On 03/04/2020 16:28, Jan Beulich wrote:
> > On 03.04.2020 17:17, Igor Druzhinin wrote:
> >> On 03/04/2020 16:05, Jan Beulich wrote:
> >>> On 03.04.2020 16:47, Igor Druzhinin wrote:
> >>>> There multiple technical complications that caused this mess.
> >>>> One of them is that there is no unfortunately a better place for =
the
> >>>> framebuffer to be located initially. Second, SR-IOV device
> >>>> is real and adding a virtual BAR to it is also complicated (due =
to
> >>>> compatibility reasons) and NVIDIA decided to avoid that.
> >>>
> >>> In which case I wonder - aren't you ending up with the MMIO case
> >>> that I had mentioned, and that you said is difficult to deal with?
> >>
> >> No, it's VRAM area (normal RAM pages) - not MMIO.
> >
> > Well, VRAM is still MMIO from the CPU's perspective, just without
> > any side effects. But if it was another device that was passed
> > through, couldn't its MMIO similarly end up in that area?
>=20
> As Andrew said, Xen VRAM is just normal RAM. It's originally
> populated in this area for the lack of a better place (at least now).
> It's special and has nothing to do with the device passed through
> using conventional PCI mechanisms which BARs will only occupy MMIO =
hole.
>=20

I assume Jan's point is that the guest doesn't access it as if it is =
normal RAM. It's only accessed directly if it is present in a PCI BAR, =
otherwise it is accessed indirectly (via QEMU) in response to accesses =
to the VGA aperture.

  Paul




From xen-devel-bounces@lists.xenproject.org Fri Apr 03 16:18:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 16:18:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKP1t-0008EE-PZ; Fri, 03 Apr 2020 16:18:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NL/P=5T=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jKP1s-0008E8-0R
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 16:18:48 +0000
X-Inumbo-ID: cbe02006-75c6-11ea-b4f4-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cbe02006-75c6-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 16:18:47 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id AAD8020721;
 Fri,  3 Apr 2020 16:18:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1585930727;
 bh=1Z1tLPwdMmtEsVeNe7Zs+sOCeoJdr2OoNTpNXrY1DNw=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=eiggfE5BQnwHebtHB+ygrxNM/p4sEv+qJG/4TvCCYBYroYwcZDC2zX8U0oFuVQffl
 5M6nbuDM6TOWS+GBzNROnL6B8edPbxt5NT/ytQ66soPlufV4iH968dPdWOovZas8Pk
 uMaHzJMntCyh0Mw/qZna9RBJyegaqjSe605ZAWfQ=
Date: Fri, 3 Apr 2020 09:18:40 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
In-Reply-To: <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
Message-ID: <alpine.DEB.2.21.2004030809300.23034@sstabellini-ThinkPad-T480s>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, George.Dunlap@citrix.com,
 Wei Xu <xuwei5@hisilicon.com>, Bertrand.Marquis@arm.com,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 3 Apr 2020, Marc Zyngier wrote:
> > > Yeah I missed to highlight it, also because I look at it from a slightly
> > > different perspective: I think IRQ latency is part of correctness.
> 
> No. Low latency is a very desirable thing, but it doesn't matter at all when
> you don't even have functional correctness.

Hi Marc,

It is good to hear from you. Functional correctness can still lead to
breakage. I wrote more details in last part of this email to explain in
details, it is long but please read it all!

[...]

> Please find anything that specifies latency in the GIC spec. Oh wait,
> there is none. Because that's a quality of implementation thing, and
> not a correctness issue.

The goal of being faithful to the spec is not compliance for the sake of
it. I take neither you nor me actually care about labels with compliance
logos to attach anywhere. The goal is to run guests correctly when
virtualized. Do you agree with me so far?

The difficult question is: what happens when the hypervisor is faithful
to the spec, but guests still break?


> > In all honesty, writing and testing the implementation would have
> > likely took you less than trying to push for "creative" ideas or your
> > patch.
> > 
> > > In terms of other "creative" ideas, here are some:
> > 
> > "creative" ideas should really be the last resort. Correct me if I am
> > wrong, but I don't think we are there yet.
> > 
> > > 
> > > One idea, as George suggested, would be to document the interface
> > > deviation. The intention is still to remove any deviation but at least
> > > we would be clear about what we have. Ideally in a single place together
> > > with other hypervisors. This is my preference.
> > 
> > It is not without saying that deviation from specification should not
> > be taken lightly and has risks.
> > 
> > The main risk is you are never going to be able to reliably run an OS
> > on Xen unless you manage to get the deviation accepted by the wider
> > community and Arm.
> 
> There is just no way I'll ever accept a change to the GIC interrupt state
> machine for Linux. Feel free to try and convince other OS maintainers.
> 
> If you want to be creative, be really creative. Implement a fully PV interrupt
> controller that gives you simple enough semantics so that you can actually be
> deterministic. Don't pretend you implement the GIC architecture.

Last time we looked at KVM, KVM was actually doing what my patch here
does, not what Julien suggested. (In short, my patch is implementing
ISACTIVER accurately only for the current vcpu and not the others;
Julien is suggesting to send an IPI to other pcpus running vcpus so that
the implementation becomes accurate for other vcpus too.)


> > > Another idea is that we could crash the guest if GICD_ISACTIVER is read
> > > from a multi-vcpu guest. It is similar to what we already do today but
> > > better because we would do it purposely (not because of a typo) and
> > > because it will work for single vcpu guests at least.
> > > 
> > > We could also leave it as is (crash all the time) but it implies that
> > > vendors that are seeing issues with Linux today will have to keep
> > > maintaining patches in their private trees until a better solution is
> > > found. This would also be the case if we crash multi-vcpus guests as
> > > previously suggested.
> 
> OK, that's just insane. Suggesting that guests should be left crashing
> because the are doing *the right thing* is just barking mad. I'm all for
> exposing guest bugs when they take shortcuts with the architecture, but
> blaming the guest for what is just a bug in Xen?
> 
> If I was someone developing a product using Xen/ARM, I'd be very worried
> about what you have written above. Because it really reads "we don't care
> about reliability as long as we can show amazing numbers". I really hope
> it isn't what you mean.

It is not what I am saying, and I am glad I have an opportunity to
explain it.

Don't think about low latency numbers as: "great it runs faster!" I
don't care about that. Well, I care, but not that much, certainly not at
the expense of being faithful to the spec.

Customers here are running guests and workloads that fail spectacularly
if they don't get IRQ latency within low deterministic ranges. A latency
spike can cause a severe failure, as bad a failure as a total system
crash.

Today, these guests don't use ISACTIVER at all AFAIK, but let's imagine
that in the future they will. Being latency sensitive guests, I doubt
they'll ever loop over ISACTIVER, but maybe they could call it once at
initialization time or during shutdown of something? Also, let's say
implementing ISACTIVER faithfully with an IPI to another vcpus might
cause a latency spikes (note that we don't have numbers on this).

Does this scenario make sense to you so far?

If we implement ISACTIVER using an IPI we introduce a significant source
of non-determinism. We yank the other vcpu into hypervisor mode when it
could have been running the critical section. It can very well cause one
of those spectacular failures. It might take the engineers putting the
system together a very significant amount of time to figure out the
problem.

Doing what my patch here does might be OK until one of these guests
start to rely on ISACTIVER to be accurate. So far I have not seen any
examples of it, but I agree it could happen, hence, it is risky.
Frankly, I thought that KVM was already behaving the way of my patch and
it was making me feel more confident about this solution.

Finally the last option is to just crash early. It is not blaming the
guest -- it would serve as an early warning that something is not right
and needs to be done about the system. Typically, it is better to fail
early and clearly rather than at some point later more subtly.


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 16:23:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 16:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKP6A-0000bD-E8; Fri, 03 Apr 2020 16:23:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fKXS=5T=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKP69-0000b8-E7
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 16:23:13 +0000
X-Inumbo-ID: 6a39ff2e-75c7-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6a39ff2e-75c7-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 16:23:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=IJFvVntStJYwaHu5kv4zQHFdWi54Kc2oQK1JrPGGqVU=; b=e2H5M1JtaiUDx78IL0Db9VJgrY
 0c2zByt5hY0+X1XoK+YhFmi8e41mvCW0Th+EXGTqGhHfMkyow0BsnyN5pRSXinlWPCPDK/3ycfW/l
 caemyzq/frte1Yak1f63Apx69fSYycZ2JXGttilb6BFlMFAp5ftAIFktyYTUGAI91/8M=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKP62-0003Cb-DJ; Fri, 03 Apr 2020 16:23:06 +0000
Received: from 54-240-197-238.amazon.com ([54.240.197.238]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKP62-00046i-6i; Fri, 03 Apr 2020 16:23:06 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Stefano Stabellini <sstabellini@kernel.org>, Marc Zyngier <maz@kernel.org>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
 <alpine.DEB.2.21.2004030809300.23034@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <55bcb88b-8816-542e-e113-c7cab6507bf4@xen.org>
Date: Fri, 3 Apr 2020 17:23:03 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004030809300.23034@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, George.Dunlap@citrix.com,
 Wei Xu <xuwei5@hisilicon.com>, Bertrand.Marquis@arm.com,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 03/04/2020 17:18, Stefano Stabellini wrote:
> On Fri, 3 Apr 2020, Marc Zyngier wrote:
  > Doing what my patch here does might be OK until one of these guests
> start to rely on ISACTIVER to be accurate. So far I have not seen any
> examples of it, but I agree it could happen, hence, it is risky.

I am only going to answer to this. This is not about *accuracy* but 
deadlock in your guest. I actually wrote a long e-mail on this thread 
explaining the possible deadlock.

It is not because you can't reproduce the deadlock that the dealock is 
not there. When are you going to stop dimissing real bug in your 
implementation?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 16:57:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 16:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKPcu-0003Af-Io; Fri, 03 Apr 2020 16:57:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=4QVj=5T=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jKPcs-0003Aa-R8
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 16:57:02 +0000
X-Inumbo-ID: 22ed39ec-75cc-11ea-bd4f-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 22ed39ec-75cc-11ea-bd4f-12813bfff9fa;
 Fri, 03 Apr 2020 16:57:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585933022;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=RQLS0RDiCFAypcPh+9CLzjxQ/WuZPSOBdWc0aNk1xW0=;
 b=YRZp8lHEkmfhHrzwsWv+FHQGaO1Z1Xd9f2BN0ECCiLQVW2e+B8ER0QLB
 77iHHz/Qnw6Xt6kWKlgkHA49twQksUJLgQ3+SK8YpdYWs0ojklHJtofDe
 Bb1bBF4Voqj3gCEx9la4ZthnIfGU4tqSQI36/TRtyZZcQL+hfhGdv+RQM U=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: TEQBAxK0xM0jsFifeWVZI/0rCOP3mMGLErp2rORRkHbWd9iyyAkxl8rI++qRo6Wyz4Cxb0cHCw
 qhjmwjwp9jG8ztfeFso0s+nqiU/TDQsPNKxvao96LbbjuwpxU9s+YMkbAIbeyhI8Zm/fYpXqO8
 pAqRJFtSrlTK60+VyuKxTrM1lzNOknLdfQawpdmx/HXGVOhiCYniUebYTGo7DWDHdvipGwMkIj
 3jPsY3yWiE2xhxCv8/S2COJ6FoQNnR7+sfH/jW9GvHO9dj+Ro+GTc4ZCeDgk5zpm35LBEyjaBr
 qMo=
X-SBRS: 2.7
X-MesageID: 15158784
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15158784"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24199.27351.756049.773415@mariner.uk.xensource.com>
Date: Fri, 3 Apr 2020 17:56:55 +0100
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] docs: Render .md files using pandoc
In-Reply-To: <20200403131720.30140-1-andrew.cooper3@citrix.com>
References: <20200403131720.30140-1-andrew.cooper3@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 Paul Durrant <paul.durrant@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Andrew Cooper writes ("[PATCH] docs: Render .md files using pandoc"):
> This fixes the fact that qemu-deprivilege.md, non-cooperative-migration.md and
> xenstore-migration.md don't currently get rendered at all, and are therefore
> missing from xenbits.xen.org/docs
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: George Dunlap <George.Dunlap@eu.citrix.com>
> CC: Paul Durrant <paul.durrant@citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>

Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> Ian - given qemu-deprivilege.md was in 4.12, this wants backporting.  It quite
> possibly needs some intermediate prerequisites

Cool.  Can you add a "Backport: 4.12" tag then ?

Thanks,
Ian.


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 16:58:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 16:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKPeL-0003Ff-VN; Fri, 03 Apr 2020 16:58:33 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=4QVj=5T=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jKPeK-0003FY-OA
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 16:58:32 +0000
X-Inumbo-ID: 58f23ef3-75cc-11ea-bd4f-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 58f23ef3-75cc-11ea-bd4f-12813bfff9fa;
 Fri, 03 Apr 2020 16:58:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1585933111;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=VPEZ2kkgQIuLwDdYTTfQYWPvizndUG1Yv6sNqpE7FLg=;
 b=ZvRVUTAJMFX9tU7JalHuJsx+Ty1jMNvXJrfed/0P3kX+LKOaxW1VXKn8
 ACW71dH2/lEK0eNXYhwKxrZG3SisSNOozfjyVDjeCXcikW/mpwnI9C1+J
 xlW+svMVC5xLe6QT4eSlVNBOMZMuABVFRyfAfLSMiPYGqFQk9TW+x7jzM Y=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: +dnmyQUlbGgZw5TKistgX3MO2x8Oiw+qnKGUJF6/kf2C4PXqe6uFyV+EnxpD7YxWGCDaWc4t/M
 6DZadohFau86zlqXnXk+0j7Mwo69Yi8HYedV2pzF4E5shyD7UHju0MFRt3Ojsaqo+kSk2qfHxx
 hT/EZ+weVFQgYjmTNWsoQGXJlPt9rW41wsuBk9g2V7oKe9r0aU9eohtUioI/ufl1DtSJ5K1Xzg
 g1GmEFWtMmAnc3PpYQ07v5MS9CwbB6Hav+Mt91ycyTveBx3GVqv+kUfDaoHcpPE78q7W5xvAB/
 pBA=
X-SBRS: 2.7
X-MesageID: 15556000
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,340,1580792400"; d="scan'208";a="15556000"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24199.27444.602811.605308@mariner.uk.xensource.com>
Date: Fri, 3 Apr 2020 17:58:28 +0100
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] tools/xenstore: fix a use after free problem in
 xenstored
In-Reply-To: <4a934636-3441-42eb-744a-3421eebb6c86@xen.org>
References: <20200403120340.13406-1-jgross@suse.com>
 <4a934636-3441-42eb-744a-3421eebb6c86@xen.org>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Julien Grall writes ("Re: [PATCH v2] tools/xenstore: fix a use after free problem in xenstored"):
> On 03/04/2020 13:03, Juergen Gross wrote:
> > Commit 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object
> > twice") introduced a potential use after free problem in
> > domain_cleanup(): after calling talloc_unlink() for domain->conn
> > domain->conn is set to NULL. The problem is that domain is registered
> > as talloc child of domain->conn, so it might be freed by the
> > talloc_unlink() call.
> > 
> > With Xenstore being single threaded there are normally no concurrent
> > memory allocations running and freeing a virtual memory area normally
> > doesn't result in that area no longer being accessible. A problem
> > could occur only in case either a signal received results in some
> > memory allocation done in the signal handler (SIGHUP is a primary
> > candidate leading to reopening the log file), or in case the talloc
> > framework would do some internal memory allocation during freeing of
> > the memory (which would lead to clobbering of the freed domain
> > structure).
> 
> Thank you for writing more context!
> 
> > 
> > Fixes: 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object twice")
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Julien Grall <jgrall@amazon.com>

Pushed, thanks both.

Ian.


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 17:24:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 17:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKQ3C-0005fi-BS; Fri, 03 Apr 2020 17:24:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fKXS=5T=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKQ3B-0005fd-2X
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 17:24:13 +0000
X-Inumbo-ID: ef0da0e0-75cf-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ef0da0e0-75cf-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 17:24:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tENYr9AEzglSu7pLXwfkYBEAaBIn0u16L19R+hprdhs=; b=gONuvICrV/N6BA+T1OjzDRqgBC
 eXjewtRBStp7+OcuVvjwAijTNihfidvipzT9k7yjDakgdcKRdWf7EncpPB7UiSBOsSzGGX9u1x3DI
 RdKeUsXEcN89ADFCyJjYHOPEdJPtYGACfTM2BNCVcYR54fAAmZFCmmfljbZCVT3Me6Iw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKQ36-0004Sg-07; Fri, 03 Apr 2020 17:24:08 +0000
Received: from 54-240-197-238.amazon.com ([54.240.197.238]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKQ35-00081Q-Km; Fri, 03 Apr 2020 17:24:07 +0000
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: paul@xen.org, xen-devel@lists.xenproject.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
 <002201d609d0$55a76690$00f633b0$@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <acd5fee0-2bf6-4573-8467-38d24827ca1f@xen.org>
Date: Fri, 3 Apr 2020 18:24:05 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <002201d609d0$55a76690$00f633b0$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 03/04/2020 16:55, Paul Durrant wrote:
>> -----Original Message-----
> [snip]
>>> +
>>> +#include <xen/save.h>
>>> +
>>> +struct domain_context {
>>> +    bool log;
>>> +    struct domain_save_descriptor desc;
>>> +    domain_copy_entry copy;
>>
>> As your new framework is technically an extension of existing one, it
>> would be good to explain why we diverge in the definitions.
>>
> 
> I don't follow. What is diverging? I explain in the commit comment that this is a parallel framework. Do I need to justify why it is not a carbon copy of the HVM one?

Well, they are both restoring/saving guest state. The only difference is 
the existing one is focusing on HVM state.

So it would make sense long term to have only one hypercall and tell 
what you want to save. In fact, some of the improvement here would 
definitely make the HVM one nicer to use (at least in the context of LU).

 From the commit message, it is not clear to me why a new framework and 
why the infrastructure is at the same time different but not.

> 
>>> +    void *priv;
>>> +};
>>> +
>>> +static struct {
>>> +    const char *name;
>>> +    bool per_vcpu;
>>> +    domain_save_handler save;
>>> +    domain_load_handler load;
>>> +} handlers[DOMAIN_SAVE_CODE_MAX + 1];
>>> +
>>> +void __init domain_register_save_type(unsigned int tc, const char *name,
>>> +                                      bool per_vcpu,
>>> +                                      domain_save_handler save,
>>> +                                      domain_load_handler load)
>>> +{
>>> +    BUG_ON(tc > ARRAY_SIZE(handlers));
>>> +
>>> +    ASSERT(!handlers[tc].save);
>>> +    ASSERT(!handlers[tc].load);
>>> +
>>> +    handlers[tc].name = name;
>>> +    handlers[tc].per_vcpu = per_vcpu;
>>> +    handlers[tc].save = save;
>>> +    handlers[tc].load = load;
>>> +}
>>> +
>>> +int domain_save_entry(struct domain_context *c, unsigned int tc,
>>> +                      const char *name, const struct vcpu *v, void *src,
>>
>> I realize that 'src' is not const because how you define copy, however I
>> would rather prefer if we rework the interface to avoid to keep the
>> const in the definition. This may mean to have to define two callback
>> rather than one.
> 
> That seems a bit ugly for the sake of a const but I guess I could create a union with a copy_in and copy_out. I'll see how that looks.

I would really like to map the Live-Update as read-only (it is not meant 
to be modified by the new Xen) and therefore adding const here would 
enable us to catch most of the mistake at build rather than during runtime.
>> Why not adding an implicit padding? This would avoid to chase error
>> during saving because the len wasn't a multiple of 8.
>>
> 
> I don't think implicit padding is worth it. This error should only happen if a badly defined save record type is added to the code so perhaps I ought to add an ASSERT here as well as deal with the error.

I wish I would be able to say every error can be caught during review. 
Unfortunately this is not true.

If you define the size dynamically, then a misalignment may not be 
noticed until you go to prod. The implicit padding would at least allow 
you to be more resilient.

It may not be that bad as you would not be able to save the guest. 
Anyway, this would be nice a feature to have but not a must.

> 
>>> +        return -EINVAL;
>>> +
>>> +    BUG_ON(tc != c->desc.typecode);
>>> +    BUG_ON(v->vcpu_id != c->desc.instance);
>>
>> Does the descriptor really need to be filled by domain_save()? Can't it
>> be done here, so we can avoid the two BUG_ON()s?
>>
> 
> Yes it can but this serves as a sanity check that the save code is actually doing what it should. Hence why these are BUG_ON()s and not error exits.

This does not really answer to the question why the c->desc.instance and 
c->desc.typecode are not set here. What is the advantage to do it 
earlier on and still passing the information in parameters? Why not just 
setting them here?

> 
>>> +    c->desc.length = src_len;
>>> +
>>> +    rc = c->copy(c->priv, &c->desc, sizeof(c->desc));
>>> +    if ( rc )
>>> +        return rc;
>>> +
>>> +    return c->copy(c->priv, src, src_len);
>>> +}
>>> +
>>> +int domain_save(struct domain *d, domain_copy_entry copy, void *priv,
>>> +                unsigned long mask, bool dry_run)
>>> +{
>>> +    struct domain_context c = {
>>> +        .copy = copy,
>>> +        .priv = priv,
>>> +        .log = !dry_run,
>>> +    };
>>> +    struct domain_save_header h = {
>>> +        .magic = DOMAIN_SAVE_MAGIC,
>>> +        .version = DOMAIN_SAVE_VERSION,
>>> +    };
>>> +    struct domain_save_header e;
>>> +    unsigned int i;
>>> +    int rc;
>>> +
>>> +    ASSERT(d != current->domain);
>>> +
>>> +    if ( d->is_dying )
>>> +        return -EINVAL;
>>> +
>>> +    domain_pause(d);
>>> +
>>> +    c.desc.typecode = DOMAIN_SAVE_CODE(HEADER);
>>> +
>>> +    rc = DOMAIN_SAVE_ENTRY(HEADER, &c, d->vcpu[0], &h, sizeof(h));
>>> +    if ( rc )
>>> +        goto out;
>>> +
>>> +    for ( i = 0; i < ARRAY_SIZE(handlers); i++ )
>>
>> AFAIU, with this solution, if there are dependency between records, the
>> dependencies will have to a lower "index". I think we may have some
>> dependency with guest transparent migration such as we need to restore
>> the event ABI before restoring the event channels.
>>
> 
> Is that just a downstream implementation detail though? I would hope that there are no ordering dependencies between records.

Until now, I never managed to avoid ordering between records on the Live 
Update side.

In my previous e-mail, I suggested there are dependency between 
restoring the event ABI (such as control page...) and restoring the 
event channels. How do you suggest to solve it without imposing an order 
between records?

>>> +    {
>>> +        domain_save_handler save = handlers[i].save;
>>> +
>>> +        if ( (mask && !test_bit(i, &mask)) || !save )
>>
>> The type of mask suggests it is not possible to have more than 32
>> different types of record if we wanted to be arch agnostic. Even if we
>> focus on 64-bit arch, this is only 64 records.
>>
>> This is not very future proof, but might be ok if this is not exposed
>> outside of the hypervisor (I haven't looked at the rest of the series
>> yet). However, we at least need a BUILD_BUG_ON() in place. So please
>> make sure  DOMAIN_SAVE_CODE_MAX is always less than 64.
>>
>> Also what if there is a bit set in the mask and the record is not
>> existing? Shouldn't we return an error?
>>
> 
> TBH I think 32 will be enough... I would not expect this context space to grow very much, if at all, once transparent migration is working. I think I'll just drop the mask for now; it's not actually clear to me we'll make use of it... just seemed like a nice-to-have.

So far for Live-Update we have 20 records (not counting the Guest 
Tranparent one). We might be able to do without some, but we also didn't 
restore all the states yet.

> 
>>> +            continue;
>>> +
>>> +        memset(&c.desc, 0, sizeof(c.desc));
>>> +        c.desc.typecode = i;
>>> +
>>> +        if ( handlers[i].per_vcpu )
>>> +        {
>>> +            struct vcpu *v;
>>> +
>>> +            for_each_vcpu ( d, v )
>>> +            {
>>> +                c.desc.instance = v->vcpu_id;
>>> +
>>> +                rc = save(v, &c, dry_run);
>>> +                if ( rc )
>>> +                    goto out;
>>> +            }
>>> +        }
>>> +        else
>>> +        {
>>> +            rc = save(d->vcpu[0], &c, dry_run);
>>> +            if ( rc )
>>> +                goto out;
>>> +        }
>>> +    }
>>> +
>>> +    memset(&c.desc, 0, sizeof(c.desc));
>>> +    c.desc.typecode = DOMAIN_SAVE_CODE(END);
>>> +
>>> +    rc = DOMAIN_SAVE_ENTRY(END, &c, d->vcpu[0], &e, 0);
>>> +
>>> + out:
>>> +    domain_unpause(d);
>>> +
>>> +    return rc;
>>> +}
>>> +
>>> +int domain_load_entry(struct domain_context *c, unsigned int tc,
>>> +                      const char *name, const struct vcpu *v, void *dst,
>>> +                      size_t dst_len, bool exact)
>>> +{
>>> +    int rc;
>>> +
>>> +    if ( c->log && tc != DOMAIN_SAVE_CODE(HEADER) &&
>>> +         tc != DOMAIN_SAVE_CODE(END) )
>>> +        gdprintk(XENLOG_INFO, "%pv load: %s (%lu)\n", v, name, dst_len);
>>> +
>>> +    BUG_ON(tc != c->desc.typecode);
>>> +    BUG_ON(v->vcpu_id != c->desc.instance);
>>
>> Is it really warrant to crash the host? What would happen if the values
>> were wrong?
>>
> 
> It would mean the code is fairly seriously buggy in that the load handler is trying to load a record other than the type it registered for, or for a vcpu other than the one it was passed.

I understand that, but is warrant to crash the host? Couldn't you just 
return an error and continue to run?

> 
>>> +
>>> +    if ( (exact ?
>>> +          (dst_len != c->desc.length) : (dst_len < c->desc.length)) ||
>>
>> Using ternary in if is really confusing. How about:
>>
>> dst_len < c->desc.length || (exact && dst_len != c->desc.length) ||
>>
>> I understand that there would be two check for the exact case but I
>> think it is better than a ternary.
> 
> I'm going to re-work this I think.
> 
>>
>> However what is the purpose of the param 'exact'? If you set it to false
>> how do you know the size you read?
> 
> The point of the exact parameter is that whether the caller can only consume a record of the correct length, or whether it can handle an undersize one which gets zero-padded. (It's the same as the zeroextend option in HVM records).
> 
>>
>>> +         !IS_ALIGNED(c->desc.length, 8) )
>>> +        return -EINVAL;
>>> +
>>> +    rc = c->copy(c->priv, dst, c->desc.length);
>>> +    if ( rc )
>>> +        return rc;
>>> +
>>> +    if ( !exact )
>>> +    {
>>> +        dst += c->desc.length;
>>> +        memset(dst, 0, dst_len - c->desc.length);
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +int domain_load(struct domain *d,  domain_copy_entry copy, void *priv,
>>> +                unsigned long mask)
>>> +{
>>> +    struct domain_context c = {
>>> +        .copy = copy,
>>> +        .priv = priv,
>>> +        .log = true,
>>> +    };
>>> +    struct domain_save_header h, e;
>>> +    int rc;
>>> +
>>> +    ASSERT(d != current->domain);
>>> +
>>> +    if ( d->is_dying )
>>> +        return -EINVAL;
>>
>> What does protect you against the doing dying right after this check?
>>
> 
> Nothing. It's just to avoid doing pointless work if we can.

I wasn't thinking about pointless work but whether the rest of the code 
is relying on a sound domain. Is it going to be fine?

[...]

>>> +/* Each entry is preceded by a descriptor */
>>> +struct domain_save_descriptor {
>>> +    uint16_t typecode;
>>> +    uint16_t instance;
>>> +    /*
>>> +     * Entry length not including this descriptor. Entries must be padded
>>> +     * to a multiple of 8 bytes to make sure descriptors remain correctly
>>> +     * aligned.
>>> +     */
>>> +    uint32_t length;
>>> +};
>>> +
>>> +/*
>>> + * Each entry has a type associated with it. DECLARE_DOMAIN_SAVE_TYPE
>>> + * binds these things together.
>>> + */
>>> +#define DECLARE_DOMAIN_SAVE_TYPE(_x, _code, _type) \
>>> +    struct __DOMAIN_SAVE_TYPE_##_x { _type t; char c[_code]; };
>>> +
>>> +#define DOMAIN_SAVE_TYPE(_x) \
>>> +    typeof (((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->t)
>>> +#define DOMAIN_SAVE_CODE(_x) \
>>> +    (sizeof (((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->c))
>>> +#define DOMAIN_SAVE_MASK(_x) (1u << DOMAIN_SAVE_CODE(_x))
>>> +
>>> +/* Terminating entry */
>>> +struct domain_save_end {};
>>> +DECLARE_DOMAIN_SAVE_TYPE(END, 0, struct domain_save_end);
>>> +
>>> +#define DOMAIN_SAVE_MAGIC   0x53415645
>>> +#define DOMAIN_SAVE_VERSION 0x00000001
>>> +
>>> +/* Initial entry */
>>> +struct domain_save_header {
>>> +    uint32_t magic;             /* Must be DOMAIN_SAVE_MAGIC */
>>> +    uint32_t version;           /* Save format version */
>>
>> Would it make sense to have the version of Xen in the stream?
>>
> 
> Why? How would it help?

Let's imagine in 4.14 we introduced a bug in the saving part. This is 
solved in 4.15 but somehow the version is not bumped. How would you 
differentiate the streams saved by Xen 4.14 so you can still migrate?

If you record the version of Xen in the record automatically, then you 
at least have a way to differentiate the two versions.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 17:47:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 17:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKQPF-0007Mu-9w; Fri, 03 Apr 2020 17:47:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fKXS=5T=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKQPE-0007Mp-4U
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 17:47:00 +0000
X-Inumbo-ID: 1e1d06e8-75d3-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1e1d06e8-75d3-11ea-9e09-bc764e2007e4;
 Fri, 03 Apr 2020 17:46:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=4hrk1Am+vnhavcmhPaeER0O9iyM5b3V+bCbNo9fBdHA=; b=bYHiK3b94Bzyb5R3TOVm7tHB0Y
 Li4KS5F6aLbFYAeCvnrWRlXJbf4S2PYvEwY9oHS2NrOxjLByti7rfgitS8a9CfMO6lxmia2rjj0mE
 UfUCHwNl/ByMNC7/T7K+LdhQpLHDDZZ6/HlybqRutJRYZDGR0uNwUg1fhIEXr1FSHabU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKQP7-0004sn-SI; Fri, 03 Apr 2020 17:46:53 +0000
Received: from 54-240-197-238.amazon.com ([54.240.197.238]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKQP7-00018s-Ks; Fri, 03 Apr 2020 17:46:53 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
From: Julien Grall <julien@xen.org>
To: Stefano Stabellini <sstabellini@kernel.org>, Marc Zyngier <maz@kernel.org>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <85acdd9fa8248ddb93f2c5792bf5bd41@kernel.org>
 <alpine.DEB.2.21.2004030809300.23034@sstabellini-ThinkPad-T480s>
 <55bcb88b-8816-542e-e113-c7cab6507bf4@xen.org>
Message-ID: <e2ff2f74-b317-64f5-d8e2-cb0ebc84e47f@xen.org>
Date: Fri, 3 Apr 2020 18:46:51 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <55bcb88b-8816-542e-e113-c7cab6507bf4@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, George.Dunlap@citrix.com,
 Wei Xu <xuwei5@hisilicon.com>, Bertrand.Marquis@arm.com,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 03/04/2020 17:23, Julien Grall wrote:
> 
> 
> On 03/04/2020 17:18, Stefano Stabellini wrote:
>> On Fri, 3 Apr 2020, Marc Zyngier wrote:
>   > Doing what my patch here does might be OK until one of these guests
>> start to rely on ISACTIVER to be accurate. So far I have not seen any
>> examples of it, but I agree it could happen, hence, it is risky.
> 
> I am only going to answer to this. This is not about *accuracy* but 
> deadlock in your guest. I actually wrote a long e-mail on this thread 
> explaining the possible deadlock.
> 
> It is not because you can't reproduce the deadlock that the dealock is 
> not there. When are you going to stop dimissing real bug in your 
> implementation?

So everyone are on the same page. Here the link to the e-mail I wrote 
about the potential problem:

https://lists.xenproject.org/archives/html/xen-devel/2020-03/msg02039.html

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 19:02:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 19:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKRaU-0005Ga-8T; Fri, 03 Apr 2020 19:02:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=i4CN=5T=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKRaT-0005GV-TU
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 19:02:41 +0000
X-Inumbo-ID: b106ca2a-75dd-11ea-bd5e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b106ca2a-75dd-11ea-bd5e-12813bfff9fa;
 Fri, 03 Apr 2020 19:02:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=y/eEHK4u5DrP+M7g1pmyar8H3acN1Pfh6pj+qlgKAkE=; b=rNG99pyDQW+/gNhYfL7xAte6C
 sypHoTStFJVf5N7+564rRmC06T3gl/oviD2xwbA3njXm0ZTMavBGR3qMWKkMMXApCwbysTZvTuSmW
 UuIARK+w8zv7N7mVKH3G1fAP5hib/d8oQUEZJ0Ji1nwzK8crWdj5k8w/tyk/ui9QZZeEg=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKRaS-0006Q3-Dm; Fri, 03 Apr 2020 19:02:40 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKRaR-0001nG-Sy; Fri, 03 Apr 2020 19:02:40 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKRaR-0002SN-SD; Fri, 03 Apr 2020 19:02:39 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149391-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149391: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=0f0f4b7b1f1eb6675bf2b7baac5657e711a20dfc
X-Osstest-Versions-That: xen=009360acc9c90513e4a85c7285d4fd7a665c66e1
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 03 Apr 2020 19:02:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  0f0f4b7b1f1eb6675bf2b7baac5657e711a20dfc
baseline version:
 xen                  009360acc9c90513e4a85c7285d4fd7a665c66e1

Last test of basis   149382  2020-04-03 09:00:32 Z    0 days
Testing same since   149391  2020-04-03 16:02:05 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   009360acc9..0f0f4b7b1f  0f0f4b7b1f1eb6675bf2b7baac5657e711a20dfc -> smoke


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 19:41:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 19:41:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKSC8-0000Ik-8G; Fri, 03 Apr 2020 19:41:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NL/P=5T=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jKSC6-0000If-K9
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 19:41:34 +0000
X-Inumbo-ID: 1f8c777e-75e3-11ea-b4f4-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1f8c777e-75e3-11ea-b4f4-bc764e2007e4;
 Fri, 03 Apr 2020 19:41:33 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id F243B2077D;
 Fri,  3 Apr 2020 19:41:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1585942893;
 bh=eY/OtdelM/0Qj6FVPdtLOXVwNQhOstG4zubd5Negbek=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=JBhtv8ZL0JxBLxxOLC3O0eDG185G0pHgpd53y291Y0UoEKTRokwypzCT5f25dEVRM
 +Y7N2mPidrfXEt+lrIcHitNgw/Z0vDadMXLoMt+b4iIKoX/xfR76vDOG5if3krL6Oj
 VoNKydW7YNiYUlkX4B8TOJOo7zf4DR5u9W3b4yEU=
Date: Fri, 3 Apr 2020 12:41:32 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
In-Reply-To: <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
Message-ID: <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 maz@kernel.org, George.Dunlap@citrix.com, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, 2 Apr 2020, Julien Grall wrote:
> As we discussed on Tuesday, the cost for other vCPUs is only going to be a
> trap to the hypervisor and then back again. The cost is likely smaller than
> receiving and forwarding an interrupt.
> 
> You actually agreed on this analysis. So can you enlighten me as to why
> receiving an interrupt is a not problem for latency but this is?

My answer was that the difference is that an operating system can
disable interrupts, but it cannot disable receiving this special IPI.

 
> The crash only happened when using vGICv3 not vGICv2. But did you look at Xen
> recently? Particularly at the following patch:
> 
> xen/arm: Handle unimplemented VGICv3 registers as RAZ/WI
> 
> Per the ARM Generic Interrupt Controller Architecture Specification (ARM
> IHI 0069E), reserved registers should generally be treated as RAZ/WI.
> To simplify the VGICv3 design and improve guest compatibility, treat the
> default case for GICD and GICR registers as read_as_zero/write_ignore.
> 
> Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
> Acked-by: Julien Grall <julien@xen.org>
> 
> I actually pointed the patch to you during one of our weekly calls. Yet we
> agreed it would still be good to implement the register properly and you said
> you will write a patch.

As you know I cannot reproduce the crash myself, I asked Peng and Wei
for help in that. I cannot be certain Jeff's patch makes a difference,
but looking at the code, if you open
xen/arch/arm/vgic-v3.c:__vgic_v3_distr_common_mmio_read you can see that
the range mistake is still there:


    /* Read the active status of an IRQ via GICD/GICR is not supported */
    case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVER):
    case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
        goto read_as_zero;


So a GICD_ISACTIVER of any register but the first should end up hitting
the default case:

    default:
        printk(XENLOG_G_ERR
               "%pv: %s: unhandled read r%d offset %#08x\n",
               v, name, dabt.reg, reg);
        return 0;
    }

Which returns 0 (IO_ABORT).

Would you be happy to have the range fixed to be:

    case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):

instead?


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 20:28:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 20:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKSup-0003jB-6S; Fri, 03 Apr 2020 20:27:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=dtYi=5T=gmail.com=julien.grall.oss@srs-us1.protection.inumbo.net>)
 id 1jKSuo-0003j6-HA
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 20:27:46 +0000
X-Inumbo-ID: 9386e898-75e9-11ea-b58d-bc764e2007e4
Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9386e898-75e9-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 20:27:45 +0000 (UTC)
Received: by mail-wr1-x441.google.com with SMTP id m17so9992388wrw.11
 for <xen-devel@lists.xenproject.org>; Fri, 03 Apr 2020 13:27:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=3f7O7KO2z8nLuddRofCnPl5Ys+mjQYLJubYsHBW4Xu0=;
 b=tWkO3c8PhW3yy15FmGmQPJkEDUSYID8aya5WfS0BXOhYubkubUGX+hk4PMQZB34jJy
 dkoCK+n2MQUMxHIt3iPVGUiSSYtrT0DAaLzKxVuQy2PFHkG4/oFmpNKBEb+IEFD8PHyR
 uhQYv1V/YHXoYOyEQtAUdQk6St2Mb4qZxPcabFqNEUQV+1HHhA1FebWR3mPu4KXeX1r7
 BU6rqZqRjOj7JamZXkrhCMgFrWRyMz/bau/Ulkgh3qDjS4jcsuw8Uzn3Dexat8D1fxJ9
 Pf9ftQ+0W4NT76NzSnkgyMIcOWd9rP8Ju244wt3jQ1xprdCDsBp8TmUVFrmviucIYS9E
 DzEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=3f7O7KO2z8nLuddRofCnPl5Ys+mjQYLJubYsHBW4Xu0=;
 b=QLIZWWw7uKjmmZGzTigpEihNk33mdAl0JqlJaqTG9gB6xiE6zOQi2ag6MQKr8S8UFv
 kXbc6IO9z1WftWHHEUXbZ4NMWNaMMSteOTJXsg+r7BHlogTNhysu34JLW30ciY2aW/Ac
 jVfMtrVGYf+0Ui71KjbSq7WWfcznZgSrlZ4unO/wHEDRc4hW1t+mp9j4/MLzFG+ko7L6
 QO39g1zZ3PtYKZ4JMfjlSfNEidy0K0s+1H5LU9ax5PtSI4Fwt1XP4Eo8D2cTPDVbZy5f
 aTE3eMq/GiuLIU3K3VInATZWfbY4WLWtJYdxCBmU8syfydPkiLacylcMdByCcVhBItF9
 6tQw==
X-Gm-Message-State: AGi0PuYhm8jdEogM9yYXq9WDGAiY6536M+iTDZPsX7qEfZZteffsSLqn
 BPrlGeYSrVmG3h/9tk6gp7oGoKzx0vekUnXsTuc=
X-Google-Smtp-Source: APiQypI3ApJibhyj0unGji4o4W6CZFDlASEbKdBrt50nWlxoQ/YdKnnKZbJba1lvnFlhxN6FXF70BGGeEgE5UtDvZPg=
X-Received: by 2002:adf:a4c9:: with SMTP id h9mr4714788wrb.426.1585945664772; 
 Fri, 03 Apr 2020 13:27:44 -0700 (PDT)
MIME-Version: 1.0
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
In-Reply-To: <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Fri, 3 Apr 2020 21:27:33 +0100
Message-ID: <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Stefano Stabellini <sstabellini@kernel.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, maz@kernel.org,
 George Dunlap <George.Dunlap@citrix.com>, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini <sstabellini@kernel.org> wrote:
>
> On Thu, 2 Apr 2020, Julien Grall wrote:
> > As we discussed on Tuesday, the cost for other vCPUs is only going to be a
> > trap to the hypervisor and then back again. The cost is likely smaller than
> > receiving and forwarding an interrupt.
> >
> > You actually agreed on this analysis. So can you enlighten me as to why
> > receiving an interrupt is a not problem for latency but this is?
>
> My answer was that the difference is that an operating system can
> disable interrupts, but it cannot disable receiving this special IPI.

An OS can *only* disable its own interrupts, yet interrupts will still
be received by Xen even if the interrupts are masked at the processor
(e.g local_irq_disable()).

You would need to disable interrupts one by one as the GIC level (use
ICENABLER) in order to not receive any interrupts. Yet, Xen may still
receive interrupts for operational purposes (e.g serial, console,
maintainance IRQ...). So trap will happen.

But if your concern is to disturb a vCPU which has interrupts
disabled. Then there is way to mitigate this in an implementation, you
can easily know whether there are interrupts inflight at a given point
for a given vCPU. So you can avoid to IPI if you know there is no
interrupts potentially active.

This is why I clearly written the implementation I suggested was *not*
optimized in the same e-mail as where I made the proposal.

Cheers,


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 20:50:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 20:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKTGh-00061C-8a; Fri, 03 Apr 2020 20:50:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=dSDP=5T=kernel.org=pr-tracker-bot@srs-us1.protection.inumbo.net>)
 id 1jKTGf-000617-9j
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 20:50:21 +0000
X-Inumbo-ID: bae464d1-75ec-11ea-bd6e-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bae464d1-75ec-11ea-bd6e-12813bfff9fa;
 Fri, 03 Apr 2020 20:50:20 +0000 (UTC)
Subject: Re: [GIT PULL] xen: branch for v5.7-rc1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1585947019;
 bh=nqSzCyjbIKQdgBpyZ/g6s47+6ROMV5bNk+xGz6zu8bw=;
 h=From:In-Reply-To:References:Date:To:Cc:From;
 b=1ZO1mXz2CWdYrzMcObLvo7sBmkm8VEnzxgNMLH5w1u0LBOc/dryvxxpx2mxZnE2Iq
 +0NRCB28b7OTfdryymNAu4CR5+cBm5yoWlle+4BKEwsP37u3GHu8s5hwtGTE/xJVZQ
 ruF54mnpoeKfjvOtdmVDT0H3yuNutTxH5d1f//rg=
From: pr-tracker-bot@kernel.org
In-Reply-To: <20200403155457.27562-1-jgross@suse.com>
References: <20200403155457.27562-1-jgross@suse.com>
X-PR-Tracked-List-Id: <linux-kernel.vger.kernel.org>
X-PR-Tracked-Message-Id: <20200403155457.27562-1-jgross@suse.com>
X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
 for-linus-5.7-rc1-tag
X-PR-Tracked-Commit-Id: c3881eb58d56116c79ac4ee4f40fd15ead124c4b
X-PR-Merge-Tree: torvalds/linux.git
X-PR-Merge-Refname: refs/heads/master
X-PR-Merge-Commit-Id: 6cd3d4019ba3f45aa1a87e4e914e81d367b59937
Message-Id: <158594701954.4594.6283769979479835894.pr-tracker-bot@kernel.org>
Date: Fri, 03 Apr 2020 20:50:19 +0000
To: Juergen Gross <jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
 torvalds@linux-foundation.org, linux-kernel@vger.kernel.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The pull request you sent on Fri,  3 Apr 2020 17:54:57 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.7-rc1-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6cd3d4019ba3f45aa1a87e4e914e81d367b59937

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 21:53:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 21:53:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKUFq-0002QL-6u; Fri, 03 Apr 2020 21:53:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DuFS=5T=oracle.com=boris.ostrovsky@srs-us1.protection.inumbo.net>)
 id 1jKUFo-0002QG-VJ
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 21:53:33 +0000
X-Inumbo-ID: 8f09b4e2-75f5-11ea-b58d-bc764e2007e4
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8f09b4e2-75f5-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 21:53:32 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 033LrQuB096116;
 Fri, 3 Apr 2020 21:53:28 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=subject : to : cc :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type : content-transfer-encoding; s=corp-2020-01-29;
 bh=ZmykI1jF/AuRxj1O+Z6blTUcn3zOPYoue5aVA5PrXXE=;
 b=j0Lbeu3CDslkmu4HCqlTJOy1hgXQsrQiAYqWZkENnEDPSZF1rvOW/jJGbxyw6xoEG1wG
 VqolF1XVb/NXWDrW3CctpSZUzeUA8H4WGYXRHbysFxXvrEbzxP7P1af3HOn9MTlcAUwN
 pE/HWWhTavvkI/c6ftbi+vPH6SiSQ7hD4/It5x2BWEF4T0GUvgbUKWz13WqI+Ov3523A
 xwAGFqig7rr3XM0IYC9vFaH+xM8kzJeit4lE0LCmpBHkbOoPF65ebxzLQoO31cut47Qn
 eXhi7246mItUtTIqzptZ/IHlbxgdPftC5nA/6Gdy2/kI227DHTY72KWHjKGljY0ZoqeD cQ== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by userp2120.oracle.com with ESMTP id 303aqj3u9d-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 03 Apr 2020 21:53:28 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 033LqSjn017230;
 Fri, 3 Apr 2020 21:53:27 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by aserp3030.oracle.com with ESMTP id 302g4y8mtb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 03 Apr 2020 21:53:27 +0000
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 033LrPUC020496;
 Fri, 3 Apr 2020 21:53:25 GMT
Received: from [10.39.222.119] (/10.39.222.119)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Fri, 03 Apr 2020 14:53:25 -0700
Subject: Re: [PATCH] xen/blkfront: fix memory allocation flags in
 blkfront_setup_indirect()
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20200403090034.8753-1-jgross@suse.com>
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <1d67be51-776d-dd53-c5db-8b3539505f40@oracle.com>
Date: Fri, 3 Apr 2020 17:53:14 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200403090034.8753-1-jgross@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9580
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 bulkscore=0 suspectscore=0
 mlxscore=0 spamscore=0 malwarescore=0 mlxlogscore=999 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004030169
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9580
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 phishscore=0 clxscore=1011
 malwarescore=0 impostorscore=0 mlxlogscore=999 spamscore=0 mlxscore=0
 priorityscore=1501 lowpriorityscore=0 adultscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004030169
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Jens Axboe <axboe@kernel.dk>, Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 stable@vger.kernel.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


On 4/3/20 5:00 AM, Juergen Gross wrote:
> Commit 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for
> large array allocation") didn't fix the issue it was meant to, as the
> flags for allocating the memory are GFP_NOIO, which will lead the
> memory allocation falling back to kmalloc().
>
> So instead of GFP_NOIO use GFP_KERNEL and do all the memory allocation
> in blkfront_setup_indirect() in a memalloc_noio_{save,restore} section.=

>
> Fixes: 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for lar=
ge array allocation")
> Cc: stable@vger.kernel.org
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>




From xen-devel-bounces@lists.xenproject.org Fri Apr 03 22:32:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 22:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKUrk-0005lb-Jk; Fri, 03 Apr 2020 22:32:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=4svF=5T=oracle.com=dongli.zhang@srs-us1.protection.inumbo.net>)
 id 1jKUrk-0005lW-5L
 for xen-devel@lists.xen.org; Fri, 03 Apr 2020 22:32:44 +0000
X-Inumbo-ID: 08824654-75fb-11ea-b58d-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 08824654-75fb-11ea-b58d-bc764e2007e4;
 Fri, 03 Apr 2020 22:32:43 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 033MHjNZ099109;
 Fri, 3 Apr 2020 22:32:39 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=subject : to :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type : content-transfer-encoding; s=corp-2020-01-29;
 bh=kbuFMLH3xDECqB1AltVVQH9o6tW9Kx9JqJoqt2C7pSc=;
 b=eWTB4oUqqB3BuqgYrRcjhs5pMjVJ2nQkf3+Knkcsv/rGM8/CnARcyuyONahursFYJRgK
 QjO6yi2JZMbsmWKhNPgWIJbBma4TOT8A1gX0Yxp0XKztqt8F6hv07pXmCD3d8l6Fem9m
 g2WYKZulUoDxKgYymMltJf6UvrSyRDSscBZEhH/m1WBe6c4A3vPUZfF8z9ThBsEHStIq
 qiFDSIzsoEmmabNeLCQCj57V7e/s5iuTMNGhxrBsBv8MgfXdXiEaiWNmVQpKkbbEmWqb
 3uZymcD7YmyZptj9IrOIdVGHSTJqNy52uTfwsbftTw4VO97viVN36HLmNU4TQc425NmT wA== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by aserp2120.oracle.com with ESMTP id 303yunp28e-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 03 Apr 2020 22:32:39 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 033MHD54041412;
 Fri, 3 Apr 2020 22:32:38 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by aserp3020.oracle.com with ESMTP id 304sju5vwc-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 03 Apr 2020 22:32:38 +0000
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 033MWbfH004761;
 Fri, 3 Apr 2020 22:32:37 GMT
Received: from [10.159.153.117] (/10.159.153.117)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Fri, 03 Apr 2020 15:32:37 -0700
Subject: Re: Live migration and PV device handling
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anastassios Nanos <anastassios.nanos@sunlight.io>, xen-devel@lists.xen.org
References: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
 <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
From: Dongli Zhang <dongli.zhang@oracle.com>
Message-ID: <d698f1ed-247e-404c-04ce-762c651771d1@oracle.com>
Date: Fri, 3 Apr 2020 15:32:36 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9580
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 adultscore=0 mlxscore=0
 malwarescore=0 phishscore=0 suspectscore=0 mlxlogscore=999 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004030172
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9580
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 lowpriorityscore=0
 malwarescore=0 adultscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0
 suspectscore=0 mlxscore=0 spamscore=0 impostorscore=0 clxscore=1011
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004030172
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Andrew,

On 4/3/20 5:42 AM, Andrew Cooper wrote:
> On 03/04/2020 13:32, Anastassios Nanos wrote:
>> Hi all,
>>
>> I am trying to understand how live-migration happens in xen. I am
>> looking in the HVM guest case and I have dug into the relevant parts
>> of the toolstack and the hypervisor regarding memory, vCPU context
>> etc.
>>
>> In particular, I am interested in how PV device migration happens. I
>> assume that the guest is not aware of any suspend/resume operations
>> being done
> 
> Sadly, this assumption is not correct.  HVM guests with PV drivers
> currently have to be aware in exactly the same way as PV guests.
> 
> Work is in progress to try and address this.  See
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=775a02452ddf3a6889690de90b1a94eb29c3c732
> (sorry - for some reason that doc isn't being rendered properly in
> https://xenbits.xen.org/docs/ )
> 

I read below from the commit:

+* The toolstack choose a randomized domid for initial creation or default
+migration, but preserve the source domid non-cooperative migration.
+Non-Cooperative migration will have to be denied if the domid is
+unavailable on the target host, but randomization of domid on creation
+should hopefully minimize the likelihood of this. Non-Cooperative migration
+to localhost will clearly not be possible.

Does that indicate while scope of domid_t is shared by a single server in old
design, the scope of domid_t is shared by a cluster of server in new design?

That is, the domid should be unique in the cluster of all servers if we expect
non-cooperative migration always succeed?

Thank you very much!

Dongli Zhang


From xen-devel-bounces@lists.xenproject.org Fri Apr 03 23:14:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Apr 2020 23:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKVVq-0000df-Mo; Fri, 03 Apr 2020 23:14:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=i4CN=5T=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKVVp-0000da-JG
 for xen-devel@lists.xenproject.org; Fri, 03 Apr 2020 23:14:09 +0000
X-Inumbo-ID: d2106e60-7600-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d2106e60-7600-11ea-9e09-bc764e2007e4;
 Fri, 03 Apr 2020 23:14:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=T9kFv81FYmwRaXPGy4TJsFlkn8I+FxEXnKNIRw+foj8=; b=40h0/6hYdMGHUL2LQlHh8cr73
 L9FlAwQjVQ9LU5LOPZbWmzWnFvx4ipySnyIJVMYnjGBpg1c6fv5ZPKTR2+yvSWTpf4hj/u/4TjHRo
 ZVE2DL+RYDJaeMxFApjG675M+ElwDJh0qqKSZwarbnOxUaoCAjyMuV1kYf3xdSXBvptUY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKVVo-0002qd-75; Fri, 03 Apr 2020 23:14:08 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKVVn-0008D6-Uh; Fri, 03 Apr 2020 23:14:08 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKVVn-0001nQ-U9; Fri, 03 Apr 2020 23:14:07 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149401-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149401: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
X-Osstest-Versions-That: xen=0f0f4b7b1f1eb6675bf2b7baac5657e711a20dfc
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 03 Apr 2020 23:14:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
baseline version:
 xen                  0f0f4b7b1f1eb6675bf2b7baac5657e711a20dfc

Last test of basis   149391  2020-04-03 16:02:05 Z    0 days
Testing same since   149401  2020-04-03 20:00:45 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Juergen Gross <jgross@suse.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   0f0f4b7b1f..990b6e38d9  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd -> smoke


From xen-devel-bounces@lists.xenproject.org Sat Apr 04 03:58:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 03:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKZwZ-0001bm-7c; Sat, 04 Apr 2020 03:58:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qJcp=5U=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKZwY-0001bc-0Y
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 03:58:02 +0000
X-Inumbo-ID: 796f6cd4-7628-11ea-bdc8-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 796f6cd4-7628-11ea-bdc8-12813bfff9fa;
 Sat, 04 Apr 2020 03:57:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=yPIzPM0a+7zObH5oTC2CVGeUlh2fBdK3wqbDzLHWs4o=; b=pXTX3jlbSQgvLSAcpv6jfxlIq
 mUk9ZaXUXJcRHHvLpq0Q+SpvYA7ydUS27rt//SBqTBmeOgVB+QjDxpBPM+K8oofP9VMNNub7SwWSJ
 G/ISuxQkLJHZz6i6UeMtLD40Jw41c66uB2BfoaXGyG2V0vBkDbr0A2D8OBO/AFBLtEpM0=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKZwV-0005Ak-Eo; Sat, 04 Apr 2020 03:57:59 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKZwV-0006Np-45; Sat, 04 Apr 2020 03:57:59 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKZwV-00069V-3M; Sat, 04 Apr 2020 03:57:59 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149378-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149378: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore.2:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=4de936a38aa96c946f5d39b2760abb8a9853cba3
X-Osstest-Versions-That: xen=e19b4b3b55f84e0cfcc02fe5d66965969a81c965
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 04 Apr 2020 03:57:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149151
 test-amd64-amd64-dom0pvh-xl-intel 17 guest-saverestore.2      fail like 149151
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149188
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149188
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149188
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149188
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149188
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  4de936a38aa96c946f5d39b2760abb8a9853cba3
baseline version:
 xen                  e19b4b3b55f84e0cfcc02fe5d66965969a81c965

Last test of basis   149188  2020-03-30 01:51:23 Z    5 days
Failing since        149231  2020-03-31 02:00:20 Z    4 days    5 attempts
Testing same since   149335  2020-04-02 12:59:35 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jason Andryuk <jandryuk@gmail.com>
  Julien Grall <jgrall@amazon.com>
  Julien Grall <julien.grall@arm.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Simran Singhal <singhalsimran0@gmail.com>
  Stefano Stabellini <sstabellini@kernel.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   e19b4b3b55..4de936a38a  4de936a38aa96c946f5d39b2760abb8a9853cba3 -> master


From xen-devel-bounces@lists.xenproject.org Sat Apr 04 06:18:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 06:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKc7n-000575-Dk; Sat, 04 Apr 2020 06:17:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qJcp=5U=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKc7m-000570-41
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 06:17:46 +0000
X-Inumbo-ID: fcf3ab84-763b-11ea-bdd7-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fcf3ab84-763b-11ea-bdd7-12813bfff9fa;
 Sat, 04 Apr 2020 06:17:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=LhXe5qot6F1tPLNzN4twR+oYXpyWtLAI6wGDqdj3jV4=; b=Fd++D1G2bVdX0AxfCQ8YbIRiz
 8Dyj4MlRdK03PbIWPlBhU3o52WNMgbi66O7/EfsMNQ1ewk2K/UckuxZdxCtqnlfe/EWMzEapXFsR+
 XmCQ9Bqt++uYgJFAwJybk0T/iHHxPqTnAZf4ZcyKrAwO9U80NjB5bCPwS9m5eJGSMEHNg=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKc7g-0008OA-Gd; Sat, 04 Apr 2020 06:17:40 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKc7g-0006Ij-6s; Sat, 04 Apr 2020 06:17:40 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKc7g-0002dW-6C; Sat, 04 Apr 2020 06:17:40 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149383-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149383: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=5142ca078d1cbc0f77b0f385d28cdb3e504e62bd
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 04 Apr 2020 06:17:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                5142ca078d1cbc0f77b0f385d28cdb3e504e62bd
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  109 days
Failing since        144880  2019-12-16 20:07:08 Z  109 days  319 attempts
Testing same since   149383  2020-04-03 09:16:40 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Elazar Leibovich <elazar.leibovich@oracle.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Liran Alon <liran.alon@oracle.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Bolshakov <r.bolshakov@yadro.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 56508 lines long.)


From xen-devel-bounces@lists.xenproject.org Sat Apr 04 10:07:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 10:07:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKfi2-0006wB-OC; Sat, 04 Apr 2020 10:07:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qJcp=5U=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKfi1-0006w5-ME
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 10:07:25 +0000
X-Inumbo-ID: 145f6fea-765c-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 145f6fea-765c-11ea-9e09-bc764e2007e4;
 Sat, 04 Apr 2020 10:07:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=TCSqjNtkz6wnUyEhbwAQ/MxabV9rA+h7NtZDvnZCpi8=; b=nyzJUFoJWJDXb3pfuyC/bSXFn
 vWamAxZvDLDga/SJhuOjgJ8lm/S2tjogGxvN31WiiaZ5wgszNdLm8KDVV8CNmwFfLkEQcM7KVyGWe
 JJUmE8aOmzFL3WbvBRQytJntRxWnmbgWw6S73sFASxl0w7ZG1VBDFf1TKyy8f0LwS4ZfA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKfhz-0004o7-M4; Sat, 04 Apr 2020 10:07:23 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKfhz-0002Uq-8P; Sat, 04 Apr 2020 10:07:23 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKfhz-0005zz-5C; Sat, 04 Apr 2020 10:07:23 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149386-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149386: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:regression
 linux-linus:build-arm64-pvops:kernel-build:fail:regression
 linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=bef7b2a7be28638770972ab2709adf11d601c11a
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 04 Apr 2020 10:07:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine      4 memdisk-try-append       fail REGR. vs. 149238
 build-arm64-pvops             6 kernel-build             fail REGR. vs. 149238

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)               blocked  n/a
 test-arm64-arm64-examine      1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)               blocked  n/a
 test-amd64-amd64-dom0pvh-xl-intel 15 guest-saverestore        fail like 149238
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149238
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149238
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149238
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-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-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                bef7b2a7be28638770972ab2709adf11d601c11a
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    4 days
Failing since        149266  2020-04-01 03:55:53 Z    3 days    4 attempts
Testing same since   149386  2020-04-03 11:30:09 Z    0 days    1 attempts

------------------------------------------------------------
1335 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  blocked 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  blocked 
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     blocked 
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 blocked 
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Sat Apr 04 10:27:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 10:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKg10-00007V-9k; Sat, 04 Apr 2020 10:27:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKg0z-00007Q-2O
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 10:27:01 +0000
X-Inumbo-ID: d19e12da-765e-11ea-be07-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d19e12da-765e-11ea-be07-12813bfff9fa;
 Sat, 04 Apr 2020 10:27:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:
 Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=TkOcH+NhGB6tD0EoyOqmB42AFmfEEhuMkkI9bucOE8E=; b=2wa69OUTE0q4FttFYy6y/+08kj
 lyDJ+KM0xEoCBaV9yhXVSZTZBGDwMkhBuOWOi6VQloZLMcWRpUX/LEAU7Uc96LS0kMF49c1PyiSex
 rDcsbR7Qj/E1Cu+/JwGHw9N9pdp3Pv+4W9113qTgsAysTX/MztjZTA+i/Zq2Si34htUo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKg0x-00059y-Fl; Sat, 04 Apr 2020 10:26:59 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKg0x-0005h7-5Y; Sat, 04 Apr 2020 10:26:59 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 0/3] xen/x86: Simplify init_ioapic()
Date: Sat,  4 Apr 2020 11:26:53 +0100
Message-Id: <20200404102656.29730-1-julien@xen.org>
X-Mailer: git-send-email 2.17.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Hi all,

The main goal of this small series is to simplify init_ioapic().

Cheers,

Julien Grall (3):
  xen/x86: ioapic: Use true/false in bad_ioapic_register()
  xen/x86: ioapic: Rename init_ioapic_mappings() to ioapic_init()
  xen/x86: ioapic: Simplify ioapic_init()

 xen/arch/x86/apic.c           |  2 +-
 xen/arch/x86/io_apic.c        | 65 ++++++++++++++++-------------------
 xen/include/asm-x86/io_apic.h |  2 +-
 3 files changed, 32 insertions(+), 37 deletions(-)

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 10:27:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 10:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKg13-00007m-Hy; Sat, 04 Apr 2020 10:27:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKg12-00007c-35
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 10:27:04 +0000
X-Inumbo-ID: d34b573c-765e-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d34b573c-765e-11ea-83d8-bc764e2007e4;
 Sat, 04 Apr 2020 10:27:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:
 References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tfFVWRUSZu9j4nuBTdDQtZgNGvWVZ0KeLmsF37oncn4=; b=lYSb1LSDsK4LQLRmC/221C9uaQ
 cpIoJrN20CpRgoVrxhB1I0hcGplKKYi862PDbJ03iBd8wBb0oxv7+5V4dXKhW3bwQeJbN+1FdQfPQ
 15qKvMlcn/wYP834CWsFI5XkyoJdzW0gKv71V5xzdiHUxQVXGBilRtAbemEoDtSosrgQ=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKg10-0005AO-2Z; Sat, 04 Apr 2020 10:27:02 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKg0z-0005h7-Os; Sat, 04 Apr 2020 10:27:02 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 2/3] xen/x86: ioapic: Rename init_ioapic_mappings() to
 ioapic_init()
Date: Sat,  4 Apr 2020 11:26:55 +0100
Message-Id: <20200404102656.29730-3-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404102656.29730-1-julien@xen.org>
References: <20200404102656.29730-1-julien@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

The function init_ioapic_mappings() is doing more than initialization
mappings. It is also initialization the number of IRQs/GSIs supported.

So rename the function to ioapic_init().

Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

---
    Changes in v2:
        - Rename to ioapic_init() rather than init_ioapic().
        - Add Roger's reviewed-by
        - Add Jan's acked-by
---
 xen/arch/x86/apic.c           | 2 +-
 xen/arch/x86/io_apic.c        | 2 +-
 xen/include/asm-x86/io_apic.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index cde67cd87e..71f4efb2fe 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -978,7 +978,7 @@ __next:
         boot_cpu_physical_apicid = get_apic_id();
     x86_cpu_to_apicid[0] = get_apic_id();
 
-    init_ioapic_mappings();
+    ioapic_init();
 }
 
 /*****************************************************************************
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 9868933287..8233eb44e1 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2537,7 +2537,7 @@ static __init bool bad_ioapic_register(unsigned int idx)
     return false;
 }
 
-void __init init_ioapic_mappings(void)
+void __init ioapic_init(void)
 {
     unsigned long ioapic_phys;
     unsigned int i, idx = FIX_IO_APIC_BASE_0;
diff --git a/xen/include/asm-x86/io_apic.h b/xen/include/asm-x86/io_apic.h
index 998905186b..e006b2b8dd 100644
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -180,7 +180,7 @@ extern int io_apic_get_version (int ioapic);
 extern int io_apic_get_redir_entries (int ioapic);
 extern int io_apic_set_pci_routing (int ioapic, int pin, int irq, int edge_level, int active_high_low);
 
-extern void init_ioapic_mappings(void);
+extern void ioapic_init(void);
 
 extern void ioapic_suspend(void);
 extern void ioapic_resume(void);
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 10:27:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 10:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKg15-00008D-QQ; Sat, 04 Apr 2020 10:27:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKg13-00007y-V8
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 10:27:05 +0000
X-Inumbo-ID: d21e80dc-765e-11ea-be07-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d21e80dc-765e-11ea-be07-12813bfff9fa;
 Sat, 04 Apr 2020 10:27:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=O8qi6CyUcG6jB4s0EzoV2dMvYHGdJrUt2FlFqXtPOl8=; b=YlH0HS7iY7bQCuXO+2W9jQewuq
 9DBzxuGAVlalJMPEKMMvBaMGojlJDJXFcseVSdRSadg7AjhSDt6P+gUKexJ4kGxx62OyBkYpmOrDg
 BSQ1IC0EkeiC7dbc+SQetgs/mzoi0hVZL5zY/Jx9n5YBFtmYpjr3obwlrRTeIULJ5gs8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKg0y-0005A3-Or; Sat, 04 Apr 2020 10:27:00 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKg0y-0005h7-FD; Sat, 04 Apr 2020 10:27:00 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 1/3] xen/x86: ioapic: Use true/false in
 bad_ioapic_register()
Date: Sat,  4 Apr 2020 11:26:54 +0100
Message-Id: <20200404102656.29730-2-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404102656.29730-1-julien@xen.org>
References: <20200404102656.29730-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

bad_ioapic_register() is returning a bool, so we should switch to
true/false.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Wei Liu <wl@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>

---
    Changes in v2:
        - Add Wei's reviewed-by
        - Fix typo
        - Add Jan's acked-by
---
 xen/arch/x86/io_apic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index e98e08e9c8..9868933287 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2531,10 +2531,10 @@ static __init bool bad_ioapic_register(unsigned int idx)
     {
         printk(KERN_WARNING "I/O APIC %#x registers return all ones, skipping!\n",
                mp_ioapics[idx].mpc_apicaddr);
-        return 1;
+        return true;
     }
 
-    return 0;
+    return false;
 }
 
 void __init init_ioapic_mappings(void)
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 10:27:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 10:27:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKg1A-00009w-77; Sat, 04 Apr 2020 10:27:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKg18-00009X-VH
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 10:27:10 +0000
X-Inumbo-ID: d3dd9e94-765e-11ea-be07-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d3dd9e94-765e-11ea-be07-12813bfff9fa;
 Sat, 04 Apr 2020 10:27:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=DJghX+ClWFBEitlSEELmqx/5BPYM3zMSGVJh1wbvZ88=; b=TuJHMQQh4eitbo26HRtC5Q6B8O
 csvGa7LKROzysYT28ACKFjztwxcx1O6sAjCpbKA25n0JRkMn06iMIJDR6Yx42szv24YAtm6+VWGby
 tAfZ0aYaYqX5g6+30z6pLqa6a8d2KIwDqIO1Zxt7vnQOv8PP0RA3cDaFgiQhHQo1Xca0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKg11-0005AU-B2; Sat, 04 Apr 2020 10:27:03 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKg11-0005h7-28; Sat, 04 Apr 2020 10:27:03 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 3/3] xen/x86: ioapic: Simplify ioapic_init()
Date: Sat,  4 Apr 2020 11:26:56 +0100
Message-Id: <20200404102656.29730-4-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404102656.29730-1-julien@xen.org>
References: <20200404102656.29730-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Since commit 9facd54a45 "x86/ioapic: Add register level checks to detect
bogus io-apic entries", Xen is able to cope with IO APICs not mapped in
the fixmap.

Therefore the whole logic to allocate a fake page for some IO APICs is
unnecessary.

With the logic removed, the code can be simplified a lot as we don't
need to go through all the IO APIC if SMP has not been detected or a
bogus zero IO-APIC address has been detected.

To avoid another level of tabulation, the simplification is now moved in
its own function.

Signed-off-by: Julien Grall <jgrall@amazon.com>

---
    Changes in v2:
        - Don't set ioapic_phys twice in a row
        - Rename init_ioapic_mappings() to ioapic_init_mappings()
        - Use paddr_t rather than unsigned long
        - Move nr_irq_gsis = 0 in ioapic_init_mappings()
---
 xen/arch/x86/io_apic.c | 61 +++++++++++++++++++-----------------------
 1 file changed, 28 insertions(+), 33 deletions(-)

diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 8233eb44e1..878ee5192d 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2537,34 +2537,26 @@ static __init bool bad_ioapic_register(unsigned int idx)
     return false;
 }
 
-void __init ioapic_init(void)
+static void __init ioapic_init_mappings(void)
 {
-    unsigned long ioapic_phys;
     unsigned int i, idx = FIX_IO_APIC_BASE_0;
-    union IO_APIC_reg_01 reg_01;
 
-    if ( smp_found_config )
-        nr_irqs_gsi = 0;
+    nr_irqs_gsi = 0;
+
     for ( i = 0; i < nr_ioapics; i++ )
     {
-        if ( smp_found_config )
-        {
-            ioapic_phys = mp_ioapics[i].mpc_apicaddr;
-            if ( !ioapic_phys )
-            {
-                printk(KERN_ERR "WARNING: bogus zero IO-APIC address "
-                       "found in MPTABLE, disabling IO/APIC support!\n");
-                smp_found_config = false;
-                skip_ioapic_setup = true;
-                goto fake_ioapic_page;
-            }
-        }
-        else
+        union IO_APIC_reg_01 reg_01;
+        paddr_t ioapic_phys = mp_ioapics[i].mpc_apicaddr;
+
+        if ( !ioapic_phys )
         {
- fake_ioapic_page:
-            ioapic_phys = __pa(alloc_xenheap_page());
-            clear_page(__va(ioapic_phys));
+            printk(KERN_ERR
+                   "WARNING: bogus zero IO-APIC address found in MPTABLE, disabling IO/APIC support!\n");
+            smp_found_config = false;
+            skip_ioapic_setup = true;
+            break;
         }
+
         set_fixmap_nocache(idx, ioapic_phys);
         apic_printk(APIC_VERBOSE, "mapped IOAPIC to %08Lx (%08lx)\n",
                     __fix_to_virt(idx), ioapic_phys);
@@ -2576,19 +2568,22 @@ void __init ioapic_init(void)
             continue;
         }
 
-        if ( smp_found_config )
-        {
-            /* The number of IO-APIC IRQ registers (== #pins): */
-            reg_01.raw = io_apic_read(i, 1);
-            nr_ioapic_entries[i] = reg_01.bits.entries + 1;
-            nr_irqs_gsi += nr_ioapic_entries[i];
-
-            if ( rangeset_add_singleton(mmio_ro_ranges,
-                                        ioapic_phys >> PAGE_SHIFT) )
-                printk(KERN_ERR "Failed to mark IO-APIC page %lx read-only\n",
-                       ioapic_phys);
-        }
+        /* The number of IO-APIC IRQ registers (== #pins): */
+        reg_01.raw = io_apic_read(i, 1);
+        nr_ioapic_entries[i] = reg_01.bits.entries + 1;
+        nr_irqs_gsi += nr_ioapic_entries[i];
+
+        if ( rangeset_add_singleton(mmio_ro_ranges,
+                                    ioapic_phys >> PAGE_SHIFT) )
+            printk(KERN_ERR "Failed to mark IO-APIC page %lx read-only\n",
+                   ioapic_phys);
     }
+}
+
+void __init ioapic_init(void)
+{
+    if ( smp_found_config )
+        ioapic_init_mappings();
 
     nr_irqs_gsi = max(nr_irqs_gsi, highest_gsi() + 1);
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 12:00:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 12:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKhTI-0008EB-1S; Sat, 04 Apr 2020 12:00:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qJcp=5U=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKhTG-0008E2-Td
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 12:00:18 +0000
X-Inumbo-ID: d6a0c6c6-766b-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d6a0c6c6-766b-11ea-83d8-bc764e2007e4;
 Sat, 04 Apr 2020 12:00:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=TY0ci3o6V0VXa9mk5MQhweFtO6mVHkRq2404q8HBCLs=; b=4OYYklV3zBu62dslA3ESLp28n
 VUO+Fm1KVNt7NqpnpAlOb8T0Y4W+2uxz//jBRMYATippakYPw2sNjCZC9SAwMPo+X0X8ZairSsJ6J
 xwO9LXEoKlryOY8LawKK9BsnMlnmDrPNlxIWvckOtk5ILXdrdzqi4+2aCloMmHO5PtdOA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKhTA-0006us-1I; Sat, 04 Apr 2020 12:00:12 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKhT9-00080t-Im; Sat, 04 Apr 2020 12:00:11 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKhT9-0001wD-I3; Sat, 04 Apr 2020 12:00:11 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149388-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149388: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-5.4:test-amd64-amd64-xl-rtds:guest-saverestore:fail:heisenbug
 linux-5.4:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:heisenbug
 linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 linux-5.4:test-amd64-amd64-xl-rtds:guest-saverestore.2:fail:allowable
 linux-5.4:test-amd64-amd64-dom0pvh-xl-intel:guest-start:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=ad13e142e024aa194016a32de8b9ba058fe9a6af
X-Osstest-Versions-That: linux=122179cb7d648a6f36b20dd6bf34f953cb384c30
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 04 Apr 2020 12:00:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds    15 guest-saverestore fail in 149361 pass in 149388
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail in 149361 pass in 149388
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149361

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     17 guest-saverestore.2      fail REGR. vs. 146121

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 12 guest-start fail in 149361 baseline untested
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                ad13e142e024aa194016a32de8b9ba058fe9a6af
baseline version:
 linux                122179cb7d648a6f36b20dd6bf34f953cb384c30

Last test of basis   146121  2020-01-15 17:42:04 Z   79 days
Failing since        146178  2020-01-17 02:59:07 Z   78 days  105 attempts
Testing same since   149361  2020-04-02 21:09:16 Z    1 days    2 attempts

------------------------------------------------------------
1482 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   122179cb7d64..ad13e142e024  ad13e142e024aa194016a32de8b9ba058fe9a6af -> tested/linux-5.4


From xen-devel-bounces@lists.xenproject.org Sat Apr 04 12:05:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 12:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKhYe-0008Rn-Q3; Sat, 04 Apr 2020 12:05:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qJcp=5U=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKhYe-0008Ri-09
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 12:05:52 +0000
X-Inumbo-ID: 9db79168-766c-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9db79168-766c-11ea-b58d-bc764e2007e4;
 Sat, 04 Apr 2020 12:05:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=S2v+xF7RK1/KpEq2x5H8mwOdMIYa1NiG6hzfYilS8DI=; b=i7cb6dfmUZ3B1fcLgHJDiQ9Cm
 bxwwMs3Hjk+oGZ4D7DsK2P/8w2qstI1p/+bu6R9TQVUUKBtQKmGDR5q5wiXO5gkpMO00WqP6vk1qW
 We/5OMhiWaIHUiPFc5F0C3J4hLITKc3Px3rTBoZAb6rCfkS3/89rJaBw072wC7SVI5ZyM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKhYY-00071O-3w; Sat, 04 Apr 2020 12:05:46 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKhYX-0008NQ-Md; Sat, 04 Apr 2020 12:05:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKhYX-0005Po-Ly; Sat, 04 Apr 2020 12:05:45 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149393-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149393: all pass - PUSHED
X-Osstest-Versions-This: ovmf=ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a
X-Osstest-Versions-That: ovmf=f73c9adfc68c7ff189b17cb2531a071d4b30cd75
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 04 Apr 2020 12:05:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

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

Last test of basis   149368  2020-04-03 00:10:25 Z    1 days
Testing same since   149393  2020-04-03 17:09:33 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Abner Chang <abner.chang@hpe.com>
  Daniel Schaefer <daniel.schaefer@hpe.com>
  Zhichao Gao <zhichao.gao@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   f73c9adfc6..ef5dcba975  ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:06:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKiVH-0004ug-2c; Sat, 04 Apr 2020 13:06:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKiVG-0004u6-3g
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:06:26 +0000
X-Inumbo-ID: 16b2fcb3-7675-11ea-be20-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 16b2fcb3-7675-11ea-be20-12813bfff9fa;
 Sat, 04 Apr 2020 13:06:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=nL6FEJ5/y1biweD0xTmxlZW+q9AMSw7C93G6n4hYeOo=; b=fPJB9cIEFzj89LEBO2XnYQwQKO
 8/LadqNF6qb4kAHJqBGnQQ7MzGG2pj3nL7OFSwMal5dYS9oR/Nu15AojMMyZ8SHKAmAzJu77ziDft
 WJQsxbsZvVMtjTSBnmxnBQDw39Q7sHzvjqhEYa2o5xf/fqje5Wx2K258sUObYSyNNddU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiVE-00089p-IU; Sat, 04 Apr 2020 13:06:24 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiVE-0007aO-8R; Sat, 04 Apr 2020 13:06:24 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
Date: Sat,  4 Apr 2020 14:06:13 +0100
Message-Id: <20200404130613.26428-1-julien@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
data to guest handle marked const.

Thankfully, no users of the helper will do that. Rather than hoping this
can be caught during review, harden copy_to_guest_offset() so the build
will fail if such users are introduced.

There is no easy way to check whether a const is NULL in C99. The
approach used is to introduce an unused variable that is non-const and
assign the handle. If the handle were const, this would fail at build
because without an explicit cast, it is not possible to assign a const
variable to a non-const variable.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>

---
    Changes in v2:
        - Use a void * variable to check the handle is not const.
---
 xen/include/asm-arm/guest_access.h | 9 +++++++++
 xen/include/asm-x86/guest_access.h | 9 +++++++++
 2 files changed, 18 insertions(+)

diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
index 8997a1cbfe..4046d50347 100644
--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -74,10 +74,14 @@ int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
 /*
  * Copy an array of objects to guest context via a guest handle,
  * specifying an offset into the guest array.
+ *
+ * The variable _t is only here to catch at build time whether we are
+ * copying back to a const guest handle.
  */
 #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
 })
@@ -124,9 +128,14 @@ int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
 #define guest_handle_okay(hnd, nr) (1)
 #define guest_handle_subrange_okay(hnd, first, last) (1)
 
+/*
+ * The variable _t is only here to catch at build time whether we are
+ * copying back to a const guest handle.
+ */
 #define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
 })
diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index ca700c959a..0b58f2baee 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -83,10 +83,14 @@
 /*
  * Copy an array of objects to guest context via a guest handle,
  * specifying an offset into the guest array.
+ *
+ * The variable _t is only here to catch at build time whether we are
+ * copying back to a const guest handle.
  */
 #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
 })
@@ -134,9 +138,14 @@
                      (last)-(first)+1,                  \
                      sizeof(*(hnd).p)))
 
+/*
+ * The variable _t is only here to catch at build time whether we are
+ * copying back to a const guest handle.
+ */
 #define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
 })
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:10:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKiZD-0005kF-NO; Sat, 04 Apr 2020 13:10:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKiZC-0005k8-97
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:10:30 +0000
X-Inumbo-ID: a85a84d2-7675-11ea-be20-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a85a84d2-7675-11ea-be20-12813bfff9fa;
 Sat, 04 Apr 2020 13:10:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=4VwITlkqRN4GqzEgtdlKqEdC4RiRaC+guw213SFaL9U=; b=snZrxGQbIXL9cpzFkiSijBvmUG
 TvkFKypJEF94cqef1WB9f6dhMJUnZVnxIwQjF+d+MxGMmBP6mX1+j7AjyI1t1U+WNNkND3DxS9lZu
 DWKG6ZHcWt2tXyjT3KUpCGn5Qrn235G1jhBx8pjRqxStOg/vCMAGClk0AMlt1y8whKS8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZA-0008FW-Po; Sat, 04 Apr 2020 13:10:28 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZA-0007rM-Gd; Sat, 04 Apr 2020 13:10:28 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 1/7] xen/guest_access: Add missing emacs magics
Date: Sat,  4 Apr 2020 14:10:11 +0100
Message-Id: <20200404131017.27330-2-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404131017.27330-1-julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Add missing emacs magics for xen/guest_access.h and
asm-x86/guest_access.h.

Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/include/asm-x86/guest_access.h | 8 ++++++++
 xen/include/xen/guest_access.h     | 8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index 0b58f2baee..9ee275d01f 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -175,3 +175,11 @@
 })
 
 #endif /* __ASM_X86_GUEST_ACCESS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/guest_access.h b/xen/include/xen/guest_access.h
index 09989df819..ef9aaa3efc 100644
--- a/xen/include/xen/guest_access.h
+++ b/xen/include/xen/guest_access.h
@@ -33,3 +33,11 @@ char *safe_copy_string_from_guest(XEN_GUEST_HANDLE(char) u_buf,
                                   size_t size, size_t max_size);
 
 #endif /* __XEN_GUEST_ACCESS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:10:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKiZE-0005kS-Vr; Sat, 04 Apr 2020 13:10:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKiZD-0005kH-Pl
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:10:31 +0000
X-Inumbo-ID: a96112d8-7675-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a96112d8-7675-11ea-9e09-bc764e2007e4;
 Sat, 04 Apr 2020 13:10:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=IbfxDvUU3r+UopRQDKG0coR2ogjCp6rmXPtnRoSVZOs=; b=MEVkTDcoXfkDtJsYM62DK5Npnf
 b6aXYCgdZW1mTq6uwWOcRIjKviemkf5SYW+E2L1Fguuvg5CwHjudNHIgdmmO8K69NG77lRwnDCFyf
 g9HkB5K6SwZGBl9cY2D4vBuut2kBYAunJwVyLXfWg577EvmtNho+g8q9qvmrXoeG45sA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZC-0008Fn-So; Sat, 04 Apr 2020 13:10:30 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZC-0007rM-Jx; Sat, 04 Apr 2020 13:10:30 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 3/7] xen/arm: decode: Re-order the includes
Date: Sat,  4 Apr 2020 14:10:13 +0100
Message-Id: <20200404131017.27330-4-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404131017.27330-1-julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Julien Grall <jgrall@amazon.com>, Stefano Stabellini <sstabellini@kernel.org>,
 julien@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

We usually have xen/ includes first and then asm/. They are also ordered
alphabetically among themselves.

Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/arch/arm/decode.c | 5 +++--
 xen/arch/arm/kernel.c | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c
index 8b1e15d118..144793c8ce 100644
--- a/xen/arch/arm/decode.c
+++ b/xen/arch/arm/decode.c
@@ -17,11 +17,12 @@
  * GNU General Public License for more details.
  */
 
-#include <xen/types.h>
+#include <xen/lib.h>
 #include <xen/sched.h>
+#include <xen/types.h>
+
 #include <asm/current.h>
 #include <asm/guest_access.h>
-#include <xen/lib.h>
 
 #include "decode.h"
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index f95fa392af..032923853f 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -5,6 +5,7 @@
  */
 #include <xen/domain_page.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
 #include <xen/gunzip.h>
 #include <xen/init.h>
 #include <xen/lib.h>
@@ -14,7 +15,6 @@
 #include <xen/vmap.h>
 
 #include <asm/byteorder.h>
-#include <asm/guest_access.h>
 #include <asm/kernel.h>
 #include <asm/setup.h>
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:10:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:10:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKiZI-0005ld-93; Sat, 04 Apr 2020 13:10:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKiZH-0005lH-9D
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:10:35 +0000
X-Inumbo-ID: a85a84d3-7675-11ea-be20-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a85a84d3-7675-11ea-be20-12813bfff9fa;
 Sat, 04 Apr 2020 13:10:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=fO7x3voDfHss5ovu96vgspZrv+9jBsYOHqKTD7O91Lk=; b=15fkMMHZt27vNi6fAMQpUUxxIt
 mu+JDXBfBsTWXYn4TL2a2AFhGM9buz1+0ObCKj7Lq1EMuwOHRtOtPEgD0AON6jNbut0lw/PAYNw8B
 alMtDT6PScVirmIWHGiycu6qVSqyWyCZEw8aWuwIE2TXB1QWX4y3eny12pzSB1In/cV4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZ9-0008FU-6B; Sat, 04 Apr 2020 13:10:27 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZ8-0007rM-SZ; Sat, 04 Apr 2020 13:10:27 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/7] xen: Consolidate asm-*/guest_access.h in
 xen/guest_access.h
Date: Sat,  4 Apr 2020 14:10:10 +0100
Message-Id: <20200404131017.27330-1-julien@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Hi all,

A lot of the helpers implemented in asm-*/guest_access.h are implemented
the same way. This series aims to avoid the duplication and implement
them only once in xen/guest_access.h.

Cheers,

Julien Grall (7):
  xen/guest_access: Add missing emacs magics
  xen/arm: kernel: Re-order the includes
  xen/arm: decode: Re-order the includes
  xen/arm: guestcopy: Re-order the includes
  xen: include xen/guest_access.h rather than asm/guest_access.h
  xen/guest_access: Consolidate guest access helpers in
    xen/guest_access.h
  xen/guest_access: Fix coding style in xen/guest_access.h

 xen/arch/arm/decode.c                |   7 +-
 xen/arch/arm/domain.c                |   2 +-
 xen/arch/arm/guest_walk.c            |   3 +-
 xen/arch/arm/guestcopy.c             |   5 +-
 xen/arch/arm/kernel.c                |  12 +--
 xen/arch/arm/vgic-v3-its.c           |   2 +-
 xen/arch/x86/hvm/svm/svm.c           |   2 +-
 xen/arch/x86/hvm/viridian/viridian.c |   2 +-
 xen/arch/x86/hvm/vmx/vmx.c           |   2 +-
 xen/common/libelf/libelf-loader.c    |   2 +-
 xen/include/asm-arm/guest_access.h   | 132 ------------------------
 xen/include/asm-x86/guest_access.h   | 129 ++---------------------
 xen/include/xen/guest_access.h       | 149 +++++++++++++++++++++++++++
 xen/lib/x86/private.h                |   2 +-
 14 files changed, 178 insertions(+), 273 deletions(-)

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:10:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:10:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKiZK-0005mZ-I4; Sat, 04 Apr 2020 13:10:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKiZJ-0005mM-SN
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:10:37 +0000
X-Inumbo-ID: ac7c9e60-7675-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ac7c9e60-7675-11ea-9e09-bc764e2007e4;
 Sat, 04 Apr 2020 13:10:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2KVd9Es5qkvi4krAUOXQh+SiaZpifjYJb0HSi4zdhJ4=; b=QtNq3JJ3b6BYsCZc02bpUPJ5WF
 +YY/18cBJ3E3gBQ+KbEIvJIILWYh9M7TeCfk7mQhFqHc5Kx9Mv7cCzV6KiV+1LJU5OPB64K6anWaS
 qIFhN3X9jV19yPmmNBMKqNz9dsVrmLa9XH8Ttrs2EURqPeZyVkAVqDCvkkkh+/G/YYA8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZH-0008GB-TI; Sat, 04 Apr 2020 13:10:35 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZH-0007rM-GY; Sat, 04 Apr 2020 13:10:35 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
Date: Sat,  4 Apr 2020 14:10:16 +0100
Message-Id: <20200404131017.27330-7-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404131017.27330-1-julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Most of the helpers to access guest memory are implemented the same way
on Arm and x86. The only differences are:
    - guest_handle_{from, to}_param(): while on x86 XEN_GUEST_HANDLE()
      and XEN_GUEST_HANDLE_PARAM() are the same, they are not on Arm. It
      is still fine to use the Arm implementation on x86.
    - __clear_guest_offset(): Interestingly the prototype does not match
      between the x86 and Arm. However, the Arm one is bogus. So the x86
      implementation can be used.
    - guest_handle{,_subrange}_okay(): They are validly differing
      because Arm is only supporting auto-translated guest and therefore
      handles are always valid.

While it would be possible to adjust the coding style at the same, this
is left for a follow-up patch so 'diff' can be used to check the
consolidation was done correctly.

Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/include/asm-arm/guest_access.h | 131 ----------------------------
 xen/include/asm-x86/guest_access.h | 125 --------------------------
 xen/include/xen/guest_access.h     | 135 +++++++++++++++++++++++++++++
 3 files changed, 135 insertions(+), 256 deletions(-)

diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
index 93d56868f1..53766386d3 100644
--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -23,102 +23,6 @@ int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
 #define __raw_copy_from_guest raw_copy_from_guest
 #define __raw_clear_guest raw_clear_guest
 
-/* Remainder copied from x86 -- could be common? */
-
-/* Is the guest handle a NULL reference? */
-#define guest_handle_is_null(hnd)        ((hnd).p == NULL)
-
-/* Offset the given guest handle into the array it refers to. */
-#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
-#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
-
-/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
- * to the specified type of XEN_GUEST_HANDLE_PARAM. */
-#define guest_handle_cast(hnd, type) ({         \
-    type *_x = (hnd).p;                         \
-    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
-})
-
-/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
-#define guest_handle_to_param(hnd, type) ({                  \
-    typeof((hnd).p) _x = (hnd).p;                            \
-    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
-    (void)(&_x == &_y.p);                                    \
-    _y;                                                      \
-})
-
-
-/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
-#define guest_handle_from_param(hnd, type) ({               \
-    typeof((hnd).p) _x = (hnd).p;                           \
-    XEN_GUEST_HANDLE(type) _y = { _x };                     \
-    /* type checking: make sure that the pointers inside    \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
-     * the same type, then return hnd */                    \
-    (void)(&_x == &_y.p);                                   \
-    _y;                                                     \
-})
-
-#define guest_handle_for_field(hnd, type, fld)          \
-    ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
-
-#define guest_handle_from_ptr(ptr, type)        \
-    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
-#define const_guest_handle_from_ptr(ptr, type)  \
-    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
-
-/*
- * Copy an array of objects to guest context via a guest handle,
- * specifying an offset into the guest array.
- *
- * The variable _t is only here to catch at build time whether we are
- * copying back to a const guest handle.
- */
-#define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
-    const typeof(*(ptr)) *_s = (ptr);                   \
-    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
-    void *__maybe_unused _t = (hnd).p;                  \
-    ((void)((hnd).p == (ptr)));                         \
-    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
-})
-
-/*
- * Clear an array of objects in guest context via a guest handle,
- * specifying an offset into the guest array.
- */
-#define clear_guest_offset(hnd, off, nr) ({    \
-    void *_d = (hnd).p;                        \
-    raw_clear_guest(_d+(off), nr);             \
-})
-
-/*
- * Copy an array of objects from guest context via a guest handle,
- * specifying an offset into the guest array.
- */
-#define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
-    const typeof(*(ptr)) *_s = (hnd).p;                 \
-    typeof(*(ptr)) *_d = (ptr);                         \
-    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
-})
-
-/* Copy sub-field of a structure to guest context via a guest handle. */
-#define copy_field_to_guest(hnd, ptr, field) ({         \
-    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
-    void *_d = &(hnd).p->field;                         \
-    ((void)(&(hnd).p->field == &(ptr)->field));         \
-    raw_copy_to_guest(_d, _s, sizeof(*_s));             \
-})
-
-/* Copy sub-field of a structure from guest context via a guest handle. */
-#define copy_field_from_guest(ptr, hnd, field) ({       \
-    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
-    typeof(&(ptr)->field) _d = &(ptr)->field;           \
-    raw_copy_from_guest(_d, _s, sizeof(*_d));           \
-})
-
 /*
  * Pre-validate a guest handle.
  * Allows use of faster __copy_* functions.
@@ -127,41 +31,6 @@ int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
 #define guest_handle_okay(hnd, nr) (1)
 #define guest_handle_subrange_okay(hnd, first, last) (1)
 
-/*
- * The variable _t is only here to catch at build time whether we are
- * copying back to a const guest handle.
- */
-#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
-    const typeof(*(ptr)) *_s = (ptr);                   \
-    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
-    void *__maybe_unused _t = (hnd).p;                  \
-    ((void)((hnd).p == (ptr)));                         \
-    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
-})
-
-#define __clear_guest_offset(hnd, off, ptr, nr) ({      \
-    __raw_clear_guest(_d+(off), nr);  \
-})
-
-#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
-    const typeof(*(ptr)) *_s = (hnd).p;                 \
-    typeof(*(ptr)) *_d = (ptr);                         \
-    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
-})
-
-#define __copy_field_to_guest(hnd, ptr, field) ({       \
-    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
-    void *_d = &(hnd).p->field;                         \
-    ((void)(&(hnd).p->field == &(ptr)->field));         \
-    __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
-})
-
-#define __copy_field_from_guest(ptr, hnd, field) ({     \
-    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
-    typeof(&(ptr)->field) _d = &(ptr)->field;           \
-    __raw_copy_from_guest(_d, _s, sizeof(*_d));         \
-})
-
 #endif /* __ASM_ARM_GUEST_ACCESS_H__ */
 /*
  * Local variables:
diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index 5c3dfc47b6..08c9fbbc78 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -38,95 +38,6 @@
      clear_user_hvm((dst), (len)) :             \
      clear_user((dst), (len)))
 
-/* Is the guest handle a NULL reference? */
-#define guest_handle_is_null(hnd)        ((hnd).p == NULL)
-
-/* Offset the given guest handle into the array it refers to. */
-#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
-#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
-
-/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
- * to the specified type of XEN_GUEST_HANDLE_PARAM. */
-#define guest_handle_cast(hnd, type) ({         \
-    type *_x = (hnd).p;                         \
-    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
-})
-
-/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
-#define guest_handle_to_param(hnd, type) ({                  \
-    typeof((hnd).p) _x = (hnd).p;                            \
-    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
-    (void)(&_x == &_y.p);                                    \
-    _y;                                                      \
-})
-
-/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
-#define guest_handle_from_param(hnd, type) ({               \
-    typeof((hnd).p) _x = (hnd).p;                           \
-    XEN_GUEST_HANDLE(type) _y = { _x };                     \
-    /* type checking: make sure that the pointers inside    \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
-     * the same type, then return hnd */                    \
-    (void)(&_x == &_y.p);                                   \
-    _y;                                                     \
-})
-
-#define guest_handle_for_field(hnd, type, fld)          \
-    ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
-
-#define guest_handle_from_ptr(ptr, type)        \
-    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
-#define const_guest_handle_from_ptr(ptr, type)  \
-    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
-
-/*
- * Copy an array of objects to guest context via a guest handle,
- * specifying an offset into the guest array.
- *
- * The variable _t is only here to catch at build time whether we are
- * copying back to a const guest handle.
- */
-#define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
-    const typeof(*(ptr)) *_s = (ptr);                   \
-    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
-    void *__maybe_unused _t = (hnd).p;                  \
-    ((void)((hnd).p == (ptr)));                         \
-    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
-})
-
-/*
- * Copy an array of objects from guest context via a guest handle,
- * specifying an offset into the guest array.
- */
-#define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
-    const typeof(*(ptr)) *_s = (hnd).p;                 \
-    typeof(*(ptr)) *_d = (ptr);                         \
-    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
-})
-
-#define clear_guest_offset(hnd, off, nr) ({    \
-    void *_d = (hnd).p;                        \
-    raw_clear_guest(_d+(off), nr);             \
-})
-
-/* Copy sub-field of a structure to guest context via a guest handle. */
-#define copy_field_to_guest(hnd, ptr, field) ({         \
-    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
-    void *_d = &(hnd).p->field;                         \
-    ((void)(&(hnd).p->field == &(ptr)->field));         \
-    raw_copy_to_guest(_d, _s, sizeof(*_s));             \
-})
-
-/* Copy sub-field of a structure from guest context via a guest handle. */
-#define copy_field_from_guest(ptr, hnd, field) ({       \
-    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
-    typeof(&(ptr)->field) _d = &(ptr)->field;           \
-    raw_copy_from_guest(_d, _s, sizeof(*_d));           \
-})
-
 /*
  * Pre-validate a guest handle.
  * Allows use of faster __copy_* functions.
@@ -140,42 +51,6 @@
                      (last)-(first)+1,                  \
                      sizeof(*(hnd).p)))
 
-/*
- * The variable _t is only here to catch at build time whether we are
- * copying back to a const guest handle.
- */
-#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
-    const typeof(*(ptr)) *_s = (ptr);                   \
-    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
-    void *__maybe_unused _t = (hnd).p;                  \
-    ((void)((hnd).p == (ptr)));                         \
-    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
-})
-
-#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
-    const typeof(*(ptr)) *_s = (hnd).p;                 \
-    typeof(*(ptr)) *_d = (ptr);                         \
-    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
-})
-
-#define __clear_guest_offset(hnd, off, nr) ({    \
-    void *_d = (hnd).p;                          \
-    __raw_clear_guest(_d+(off), nr);             \
-})
-
-#define __copy_field_to_guest(hnd, ptr, field) ({       \
-    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
-    void *_d = &(hnd).p->field;                         \
-    ((void)(&(hnd).p->field == &(ptr)->field));         \
-    __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
-})
-
-#define __copy_field_from_guest(ptr, hnd, field) ({     \
-    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
-    typeof(&(ptr)->field) _d = &(ptr)->field;           \
-    __raw_copy_from_guest(_d, _s, sizeof(*_d));         \
-})
-
 #endif /* __ASM_X86_GUEST_ACCESS_H__ */
 /*
  * Local variables:
diff --git a/xen/include/xen/guest_access.h b/xen/include/xen/guest_access.h
index ef9aaa3efc..f724f995c3 100644
--- a/xen/include/xen/guest_access.h
+++ b/xen/include/xen/guest_access.h
@@ -11,6 +11,99 @@
 #include <xen/types.h>
 #include <public/xen.h>
 
+/* Is the guest handle a NULL reference? */
+#define guest_handle_is_null(hnd)        ((hnd).p == NULL)
+
+/* Offset the given guest handle into the array it refers to. */
+#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
+#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
+
+/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
+ * to the specified type of XEN_GUEST_HANDLE_PARAM. */
+#define guest_handle_cast(hnd, type) ({         \
+    type *_x = (hnd).p;                         \
+    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
+})
+
+/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
+#define guest_handle_to_param(hnd, type) ({                  \
+    typeof((hnd).p) _x = (hnd).p;                            \
+    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)(&_x == &_y.p);                                    \
+    _y;                                                      \
+})
+
+/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
+#define guest_handle_from_param(hnd, type) ({               \
+    typeof((hnd).p) _x = (hnd).p;                           \
+    XEN_GUEST_HANDLE(type) _y = { _x };                     \
+    /* type checking: make sure that the pointers inside    \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
+     * the same type, then return hnd */                    \
+    (void)(&_x == &_y.p);                                   \
+    _y;                                                     \
+})
+
+#define guest_handle_for_field(hnd, type, fld)          \
+    ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
+
+#define guest_handle_from_ptr(ptr, type)        \
+    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
+#define const_guest_handle_from_ptr(ptr, type)  \
+    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
+
+/*
+ * Copy an array of objects to guest context via a guest handle,
+ * specifying an offset into the guest array.
+ *
+ * The variable _t is only here to catch at build time whether we are
+ * copying back to a const guest handle.
+ */
+#define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    void *__maybe_unused _t = (hnd).p;                  \
+    ((void)((hnd).p == (ptr)));                         \
+    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
+})
+
+/*
+ * Clear an array of objects in guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define clear_guest_offset(hnd, off, nr) ({    \
+    void *_d = (hnd).p;                        \
+    raw_clear_guest(_d+(off), nr);             \
+})
+
+/*
+ * Copy an array of objects from guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+/* Copy sub-field of a structure to guest context via a guest handle. */
+#define copy_field_to_guest(hnd, ptr, field) ({         \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    raw_copy_to_guest(_d, _s, sizeof(*_s));             \
+})
+
+/* Copy sub-field of a structure from guest context via a guest handle. */
+#define copy_field_from_guest(ptr, hnd, field) ({       \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    raw_copy_from_guest(_d, _s, sizeof(*_d));           \
+})
+
 #define copy_to_guest(hnd, ptr, nr)                     \
     copy_to_guest_offset(hnd, 0, ptr, nr)
 
@@ -20,6 +113,48 @@
 #define clear_guest(hnd, nr)                            \
     clear_guest_offset(hnd, 0, nr)
 
+/*
+ * The __copy_* functions should only be used after the guest handle has
+ * been pre-validated via guest_handle_okay() and
+ * guest_handle_subrange_okay().
+ */
+
+/*
+ * The variable _t is only here to catch at build time whether we are
+ * copying back to a const guest handle.
+ */
+#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    void *__maybe_unused _t = (hnd).p;                  \
+    ((void)((hnd).p == (ptr)));                         \
+    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
+})
+
+#define __clear_guest_offset(hnd, off, nr) ({    \
+    void *_d = (hnd).p;                          \
+    __raw_clear_guest(_d + (off), nr);           \
+})
+
+#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+#define __copy_field_to_guest(hnd, ptr, field) ({       \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
+})
+
+#define __copy_field_from_guest(ptr, hnd, field) ({     \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    __raw_copy_from_guest(_d, _s, sizeof(*_d));         \
+})
+
 #define __copy_to_guest(hnd, ptr, nr)                   \
     __copy_to_guest_offset(hnd, 0, ptr, nr)
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:10:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKiZN-0005oY-VK; Sat, 04 Apr 2020 13:10:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKiZM-0005nk-9I
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:10:40 +0000
X-Inumbo-ID: a8b10442-7675-11ea-be20-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a8b10442-7675-11ea-be20-12813bfff9fa;
 Sat, 04 Apr 2020 13:10:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=OCcHpjmQmhgOeKrDB+npwO03tYkJM3G16mLTFLIt6vs=; b=f/JfCmsrAcCypyBAiMdT1pYYlh
 yWlrNssjI//3TehSSFHdVMD5v6CeVPaM3FsHVQ2kxFLYrxdiBEQ12S4Pv4EcYt2ml/pxVScbHPioP
 UAS5CcC/aGD3YNPcYpbVk2RUKqJgdgruCYbtUiNG6SvMZutW5Cwq07onWvRiJD/01qBA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZB-0008Fa-R9; Sat, 04 Apr 2020 13:10:29 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZB-0007rM-IJ; Sat, 04 Apr 2020 13:10:29 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 2/7] xen/arm: kernel: Re-order the includes
Date: Sat,  4 Apr 2020 14:10:12 +0100
Message-Id: <20200404131017.27330-3-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404131017.27330-1-julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Julien Grall <jgrall@amazon.com>, Stefano Stabellini <sstabellini@kernel.org>,
 julien@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

We usually have xen/ includes first and then asm/. They are also ordered
alphabetically among themselves.

Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/arch/arm/kernel.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 8eff074836..f95fa392af 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -3,20 +3,20 @@
  *
  * Copyright (C) 2011 Citrix Systems, Inc.
  */
+#include <xen/domain_page.h>
 #include <xen/errno.h>
+#include <xen/gunzip.h>
 #include <xen/init.h>
 #include <xen/lib.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/mm.h>
-#include <xen/domain_page.h>
 #include <xen/sched.h>
-#include <asm/byteorder.h>
-#include <asm/setup.h>
-#include <xen/libfdt/libfdt.h>
-#include <xen/gunzip.h>
 #include <xen/vmap.h>
 
+#include <asm/byteorder.h>
 #include <asm/guest_access.h>
 #include <asm/kernel.h>
+#include <asm/setup.h>
 
 #define UIMAGE_MAGIC          0x27051956
 #define UIMAGE_NMLEN          32
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:10:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKiZP-0005pQ-8U; Sat, 04 Apr 2020 13:10:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKiZN-0005oN-Pd
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:10:41 +0000
X-Inumbo-ID: ad8c47ce-7675-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ad8c47ce-7675-11ea-83d8-bc764e2007e4;
 Sat, 04 Apr 2020 13:10:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=96KKJCpdFR7vcoVbtVCMECvOok+zumfKbz+sn1zOelQ=; b=Bx9n5y4PjUGHo9AVvHd2x09TNy
 TzNfGgA1U4JsvJ0O5lI95rOe59MG2dt7/T6KkhncRsXe7kXnJoEUo5FclmYSB1CDHd4AAZil3WNIX
 sIKH/nJQa9hxaOzdGEbR0i1bMo/tRHBXwR1yhUD9VL0Za4XDcSOs2rh69HPsMFd3nBJk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZJ-0008GL-Dm; Sat, 04 Apr 2020 13:10:37 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZJ-0007rM-4v; Sat, 04 Apr 2020 13:10:37 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 7/7] xen/guest_access: Fix coding style in xen/guest_access.h
Date: Sat,  4 Apr 2020 14:10:17 +0100
Message-Id: <20200404131017.27330-8-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404131017.27330-1-julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

    * Add space before and after operator
    * Align \
    * Format comments

No functional changes expected.

Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/include/xen/guest_access.h | 40 +++++++++++++++++++---------------
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/xen/include/xen/guest_access.h b/xen/include/xen/guest_access.h
index f724f995c3..24f03a84ff 100644
--- a/xen/include/xen/guest_access.h
+++ b/xen/include/xen/guest_access.h
@@ -18,20 +18,24 @@
 #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
 #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
 
-/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
- * to the specified type of XEN_GUEST_HANDLE_PARAM. */
+/*
+ * Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
+ * to the specified type of XEN_GUEST_HANDLE_PARAM.
+ */
 #define guest_handle_cast(hnd, type) ({         \
     type *_x = (hnd).p;                         \
-    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
+    (XEN_GUEST_HANDLE_PARAM(type)) { _x };      \
 })
 
 /* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
 #define guest_handle_to_param(hnd, type) ({                  \
     typeof((hnd).p) _x = (hnd).p;                            \
     XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
-    /* type checking: make sure that the pointers inside     \
+    /*                                                       \
+     * type checking: make sure that the pointers inside     \
      * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
+     * the same type, then return hnd.                       \
+     */                                                      \
     (void)(&_x == &_y.p);                                    \
     _y;                                                      \
 })
@@ -40,9 +44,11 @@
 #define guest_handle_from_param(hnd, type) ({               \
     typeof((hnd).p) _x = (hnd).p;                           \
     XEN_GUEST_HANDLE(type) _y = { _x };                     \
-    /* type checking: make sure that the pointers inside    \
+    /*                                                      \
+     * type checking: make sure that the pointers inside    \
      * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
-     * the same type, then return hnd */                    \
+     * the same type, then return hnd.                      \
+     */                                                     \
     (void)(&_x == &_y.p);                                   \
     _y;                                                     \
 })
@@ -123,12 +129,12 @@
  * The variable _t is only here to catch at build time whether we are
  * copying back to a const guest handle.
  */
-#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
-    const typeof(*(ptr)) *_s = (ptr);                   \
-    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
-    void *__maybe_unused _t = (hnd).p;                  \
-    ((void)((hnd).p == (ptr)));                         \
-    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
+#define __copy_to_guest_offset(hnd, off, ptr, nr) ({        \
+    const typeof(*(ptr)) *_s = (ptr);                       \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;              \
+    void *__maybe_unused _t = (hnd).p;                      \
+    ((void)((hnd).p == (ptr)));                             \
+    __raw_copy_to_guest(_d + (off), _s, sizeof(*_s) * (nr));\
 })
 
 #define __clear_guest_offset(hnd, off, nr) ({    \
@@ -136,10 +142,10 @@
     __raw_clear_guest(_d + (off), nr);           \
 })
 
-#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
-    const typeof(*(ptr)) *_s = (hnd).p;                 \
-    typeof(*(ptr)) *_d = (ptr);                         \
-    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+#define __copy_from_guest_offset(ptr, hnd, off, nr) ({          \
+    const typeof(*(ptr)) *_s = (hnd).p;                         \
+    typeof(*(ptr)) *_d = (ptr);                                 \
+    __raw_copy_from_guest(_d, _s + (off), sizeof (*_d) * (nr)); \
 })
 
 #define __copy_field_to_guest(hnd, ptr, field) ({       \
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:10:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:10:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKiZS-0005s6-HH; Sat, 04 Apr 2020 13:10:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKiZR-0005rB-9S
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:10:45 +0000
X-Inumbo-ID: a9f79992-7675-11ea-be20-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a9f79992-7675-11ea-be20-12813bfff9fa;
 Sat, 04 Apr 2020 13:10:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=+tO8vmyclMR2riCnUA1LGwK2u7jI5ubOgyvQNM5VRyc=; b=0HRt2MmEAEkY8+v/JkVp5wObIA
 H4TmInyiNODwo2V9hmAd/TwLKeZw7sJa3Wf7mV7F/X5mhAT0QCCCmVxELf5JLEQ1H7skBlfp4pYO0
 h4NVVQRnSjABlYi+TIiVgOp834+aST6jJbEHfeUQgvBw/CkGxIxI1TCJ84rnXu4oxvXM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZD-0008Fw-UH; Sat, 04 Apr 2020 13:10:31 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZD-0007rM-La; Sat, 04 Apr 2020 13:10:31 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 4/7] xen/arm: guestcopy: Re-order the includes
Date: Sat,  4 Apr 2020 14:10:14 +0100
Message-Id: <20200404131017.27330-5-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404131017.27330-1-julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Julien Grall <jgrall@amazon.com>, Stefano Stabellini <sstabellini@kernel.org>,
 julien@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

We usually have xen/ includes first and then asm/. They are also ordered
alphabetically among themselves.

Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/arch/arm/guestcopy.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 7a0f3e9d5f..c8023e2bca 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -1,7 +1,8 @@
-#include <xen/lib.h>
 #include <xen/domain_page.h>
+#include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/sched.h>
+
 #include <asm/current.h>
 #include <asm/guest_access.h>
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:10:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:10:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKiZX-0005vN-R9; Sat, 04 Apr 2020 13:10:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKiZW-0005uY-9g
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:10:50 +0000
X-Inumbo-ID: abf13c0a-7675-11ea-be20-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id abf13c0a-7675-11ea-be20-12813bfff9fa;
 Sat, 04 Apr 2020 13:10:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=3TNR7ldYljZZcx1x7OLW4LGPIWLoF2a6IJjm2LPtFSs=; b=LOBkKd6QLC9U68DkJii93KqBIO
 XI4MvnFuoczBqtJCCRyQ6w19PwxWS9q4mnVoAC8oX7kO1jaSEyFz0AcT3Nd6zgRpB3hB2zsBjrSAd
 Eh2hL93k2Ow1FD4PIVCk0TCuiGhtTd+HzV+3Qom7lgHHB5FB7MbIama2TeVsJ7p3HKg8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZG-0008G9-1N; Sat, 04 Apr 2020 13:10:34 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKiZF-0007rM-Oh; Sat, 04 Apr 2020 13:10:33 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 5/7] xen: include xen/guest_access.h rather than
 asm/guest_access.h
Date: Sat,  4 Apr 2020 14:10:15 +0100
Message-Id: <20200404131017.27330-6-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200404131017.27330-1-julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Only a few places are actually including asm/guest_access.h. While this
is fine today, a follow-up patch will want to move most of the helpers
from asm/guest_access.h to xen/guest_access.h.

To prepare the move, everyone should include xen/guest_access.h rather
than asm/guest_access.h.

Interestingly, asm-arm/guest_access.h includes xen/guest_access.h. The
inclusion is now removed as no-one but the latter should include the
former.

Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/arch/arm/decode.c                |  2 +-
 xen/arch/arm/domain.c                |  2 +-
 xen/arch/arm/guest_walk.c            |  3 ++-
 xen/arch/arm/guestcopy.c             |  2 +-
 xen/arch/arm/vgic-v3-its.c           |  2 +-
 xen/arch/x86/hvm/svm/svm.c           |  2 +-
 xen/arch/x86/hvm/viridian/viridian.c |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c           |  2 +-
 xen/common/libelf/libelf-loader.c    |  2 +-
 xen/include/asm-arm/guest_access.h   |  1 -
 xen/include/asm-x86/guest_access.h   | 22 ++++++++++++----------
 xen/lib/x86/private.h                |  2 +-
 12 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c
index 144793c8ce..792c2e92a7 100644
--- a/xen/arch/arm/decode.c
+++ b/xen/arch/arm/decode.c
@@ -17,12 +17,12 @@
  * GNU General Public License for more details.
  */
 
+#include <xen/guest_access.h>
 #include <xen/lib.h>
 #include <xen/sched.h>
 #include <xen/types.h>
 
 #include <asm/current.h>
-#include <asm/guest_access.h>
 
 #include "decode.h"
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2190d908eb..b062c232b6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -12,6 +12,7 @@
 #include <xen/bitops.h>
 #include <xen/errno.h>
 #include <xen/grant_table.h>
+#include <xen/guest_access.h>
 #include <xen/hypercall.h>
 #include <xen/init.h>
 #include <xen/lib.h>
@@ -26,7 +27,6 @@
 #include <asm/current.h>
 #include <asm/event.h>
 #include <asm/gic.h>
-#include <asm/guest_access.h>
 #include <asm/guest_atomics.h>
 #include <asm/irq.h>
 #include <asm/p2m.h>
diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
index a1cdd7f4af..b4496c4c86 100644
--- a/xen/arch/arm/guest_walk.c
+++ b/xen/arch/arm/guest_walk.c
@@ -16,8 +16,9 @@
  */
 
 #include <xen/domain_page.h>
+#include <xen/guest_access.h>
 #include <xen/sched.h>
-#include <asm/guest_access.h>
+
 #include <asm/guest_walk.h>
 #include <asm/short-desc.h>
 
diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index c8023e2bca..32681606d8 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -1,10 +1,10 @@
 #include <xen/domain_page.h>
+#include <xen/guest_access.h>
 #include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/sched.h>
 
 #include <asm/current.h>
-#include <asm/guest_access.h>
 
 #define COPY_flush_dcache   (1U << 0)
 #define COPY_from_guest     (0U << 1)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 6e153c698d..58d939b85f 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -32,6 +32,7 @@
 #include <xen/bitops.h>
 #include <xen/config.h>
 #include <xen/domain_page.h>
+#include <xen/guest_access.h>
 #include <xen/lib.h>
 #include <xen/init.h>
 #include <xen/softirq.h>
@@ -39,7 +40,6 @@
 #include <xen/sched.h>
 #include <xen/sizes.h>
 #include <asm/current.h>
-#include <asm/guest_access.h>
 #include <asm/mmio.h>
 #include <asm/gic_v3_defs.h>
 #include <asm/gic_v3_its.h>
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 888f504a94..9e14a451eb 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -16,6 +16,7 @@
  * this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <xen/guest_access.h>
 #include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/trace.h>
@@ -34,7 +35,6 @@
 #include <asm/cpufeature.h>
 #include <asm/processor.h>
 #include <asm/amd.h>
-#include <asm/guest_access.h>
 #include <asm/debugreg.h>
 #include <asm/msr.h>
 #include <asm/i387.h>
diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viridian/viridian.c
index 977c1bc54f..dc7183a546 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -5,12 +5,12 @@
  * Hypervisor Top Level Functional Specification for more information.
  */
 
+#include <xen/guest_access.h>
 #include <xen/sched.h>
 #include <xen/version.h>
 #include <xen/hypercall.h>
 #include <xen/domain_page.h>
 #include <xen/param.h>
-#include <asm/guest_access.h>
 #include <asm/guest/hyperv-tlfs.h>
 #include <asm/paging.h>
 #include <asm/p2m.h>
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 1c398fdb6e..98e9c91ea3 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -15,6 +15,7 @@
  * this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <xen/guest_access.h>
 #include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/param.h>
@@ -31,7 +32,6 @@
 #include <asm/regs.h>
 #include <asm/cpufeature.h>
 #include <asm/processor.h>
-#include <asm/guest_access.h>
 #include <asm/debugreg.h>
 #include <asm/msr.h>
 #include <asm/p2m.h>
diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 0f468727d0..629cc0d3e6 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -16,7 +16,7 @@
  */
 
 #ifdef __XEN__
-#include <asm/guest_access.h>
+#include <xen/guest_access.h>
 #endif
 
 #include "libelf-private.h"
diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
index 4046d50347..93d56868f1 100644
--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -1,7 +1,6 @@
 #ifndef __ASM_ARM_GUEST_ACCESS_H__
 #define __ASM_ARM_GUEST_ACCESS_H__
 
-#include <xen/guest_access.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
 
diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index 9ee275d01f..5c3dfc47b6 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -54,22 +54,24 @@
 
 /* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
 #define guest_handle_to_param(hnd, type) ({                  \
+    typeof((hnd).p) _x = (hnd).p;                            \
+    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
     /* type checking: make sure that the pointers inside     \
      * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
      * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
+    (void)(&_x == &_y.p);                                    \
+    _y;                                                      \
 })
 
 /* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
-#define guest_handle_from_param(hnd, type) ({                \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
+#define guest_handle_from_param(hnd, type) ({               \
+    typeof((hnd).p) _x = (hnd).p;                           \
+    XEN_GUEST_HANDLE(type) _y = { _x };                     \
+    /* type checking: make sure that the pointers inside    \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
+     * the same type, then return hnd */                    \
+    (void)(&_x == &_y.p);                                   \
+    _y;                                                     \
 })
 
 #define guest_handle_for_field(hnd, type, fld)          \
diff --git a/xen/lib/x86/private.h b/xen/lib/x86/private.h
index b793181464..2d53bd3ced 100644
--- a/xen/lib/x86/private.h
+++ b/xen/lib/x86/private.h
@@ -4,12 +4,12 @@
 #ifdef __XEN__
 
 #include <xen/bitops.h>
+#include <xen/guest_access.h>
 #include <xen/kernel.h>
 #include <xen/lib.h>
 #include <xen/nospec.h>
 #include <xen/types.h>
 
-#include <asm/guest_access.h>
 #include <asm/msr-index.h>
 
 #define copy_to_buffer_offset copy_to_guest_offset
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:13:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKicN-0006Vt-BG; Sat, 04 Apr 2020 13:13:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKicL-0006Vn-La
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:13:45 +0000
X-Inumbo-ID: 1cc2e3a0-7676-11ea-be20-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1cc2e3a0-7676-11ea-be20-12813bfff9fa;
 Sat, 04 Apr 2020 13:13:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Rtn2dIqkhpIfVgInY36chc0bEHX9bJJHJxfP9lteREM=; b=wI5BwdS0HKmympD9izz2RDcQ8s
 Br/mhTyDo6e24BAC+eWC3o3guScSRovab+Veq4Yew3uW6R4OClRYJgw+I+P5bhD8PClRP5mK6hpNL
 6jbQK0P3g4eP+FWoJMroUUfh+R2WwinQPcYKlyoBREZm8J5aneJ6RadGYSqp+V5M3DaU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKicE-0008Lj-TE; Sat, 04 Apr 2020 13:13:38 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKicE-0008AH-JI; Sat, 04 Apr 2020 13:13:38 +0000
Subject: Re: [PATCH 0/7] xen: Consolidate asm-*/guest_access.h in
 xen/guest_access.h
To: xen-devel@lists.xenproject.org
References: <20200404131017.27330-1-julien@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <02ace867-646b-adf5-c341-92d9042340a3@xen.org>
Date: Sat, 4 Apr 2020 14:13:35 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200404131017.27330-1-julien@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 04/04/2020 14:10, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Hi all,
> 
> A lot of the helpers implemented in asm-*/guest_access.h are implemented
> the same way. This series aims to avoid the duplication and implement
> them only once in xen/guest_access.h.

I forgot to mention this is based on "xen/guest_access: Harden 
*copy_to_guest_offset() to prevent const dest operand" [1].

This will also clash with Jan's patch "guestcopy: evaluate 
{,__}copy{,_field}_to_guest*() arguments just once" [2]. I am happy to 
rebase this series on top of it.

Cheers,

[1] https://lore.kernel.org/xen-devel/20200404130613.26428-1-julien@xen.org/
[2] 
https://lore.kernel.org/xen-devel/9918b339-e914-7228-5f8e-86c82090b5bd@suse.com/

> 
> Cheers,
> 
> Julien Grall (7):
>    xen/guest_access: Add missing emacs magics
>    xen/arm: kernel: Re-order the includes
>    xen/arm: decode: Re-order the includes
>    xen/arm: guestcopy: Re-order the includes
>    xen: include xen/guest_access.h rather than asm/guest_access.h
>    xen/guest_access: Consolidate guest access helpers in
>      xen/guest_access.h
>    xen/guest_access: Fix coding style in xen/guest_access.h
> 
>   xen/arch/arm/decode.c                |   7 +-
>   xen/arch/arm/domain.c                |   2 +-
>   xen/arch/arm/guest_walk.c            |   3 +-
>   xen/arch/arm/guestcopy.c             |   5 +-
>   xen/arch/arm/kernel.c                |  12 +--
>   xen/arch/arm/vgic-v3-its.c           |   2 +-
>   xen/arch/x86/hvm/svm/svm.c           |   2 +-
>   xen/arch/x86/hvm/viridian/viridian.c |   2 +-
>   xen/arch/x86/hvm/vmx/vmx.c           |   2 +-
>   xen/common/libelf/libelf-loader.c    |   2 +-
>   xen/include/asm-arm/guest_access.h   | 132 ------------------------
>   xen/include/asm-x86/guest_access.h   | 129 ++---------------------
>   xen/include/xen/guest_access.h       | 149 +++++++++++++++++++++++++++
>   xen/lib/x86/private.h                |   2 +-
>   14 files changed, 178 insertions(+), 273 deletions(-)
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:29:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:29:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKirX-0007by-Vn; Sat, 04 Apr 2020 13:29:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7qE9=5U=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jKirW-0007bG-Uq
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:29:26 +0000
X-Inumbo-ID: 4dc76f14-7678-11ea-be2c-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4dc76f14-7678-11ea-be2c-12813bfff9fa;
 Sat, 04 Apr 2020 13:29:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=5bL3GFubuOGwDp8XOe3oyzA/8NUs5aknVt/f2hv3X0A=; b=MjQlHGfkcGA04/TOOKmpxakj4A
 gEyM0hXrRgXAEt92a9D+tBfBYVliUmGXbAXB1s3YzMK7eZ9pDJVuOuFgzKn26urXDbfgO2gGv/u9j
 8DQBhI2wW9DmtHp7XlEzoCsApVYYHIcVC4gSxYA11oAB4iQn4o3Z2qwvNfWpBSJVh7/k=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKirV-0000D7-0S; Sat, 04 Apr 2020 13:29:25 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jKirU-0000Qb-Ny; Sat, 04 Apr 2020 13:29:24 +0000
Subject: Re: [PATCH] guestcopy: evaluate {,__}copy{,_field}_to_guest*()
 arguments just once
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9918b339-e914-7228-5f8e-86c82090b5bd@suse.com>
 <b07fcc5a-60c1-a831-b4b1-a6de3f82b8b4@xen.org>
 <0c78d386-cb20-51cf-ec2f-4d9345ecf013@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <e0af3b99-d1c3-738f-b455-cb5362b4c64e@xen.org>
Date: Sat, 4 Apr 2020 14:29:22 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <0c78d386-cb20-51cf-ec2f-4d9345ecf013@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 02/04/2020 07:20, Jan Beulich wrote:
> On 01.04.2020 23:28, Julien Grall wrote:
>> On 01/04/2020 15:29, Jan Beulich wrote:
>>> There's nothing wrong with having e.g.
>>>
>>>       copy_to_guest(uarg, ptr++, 1);
>>>
>>> yet until now this would increment "ptr" twice.
>>
>> Is there such use in Xen today? I guess not as we would have noticed any issue.
> 
> I'm not aware of any.

I have looked at the existing callers in staging and can't find such 
pattern as well.

> 
>>> --- a/xen/include/asm-arm/guest_access.h
>>> +++ b/xen/include/asm-arm/guest_access.h
>>> @@ -79,7 +79,7 @@ int access_guest_memory_by_ipa(struct do
>>>        const typeof(*(ptr)) *_s = (ptr);                   \
>>>        char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>>>        void *__maybe_unused _t = (hnd).p;                  \
>>> -    ((void)((hnd).p == (ptr)));                         \
>>> +    (void)((hnd).p == _s);                              \
>>
>> May I ask why this is a problem with 'ptr' but not 'hnd'?
>> Wouldn't it theorically possible to have an array of handle?
> 
> Theoretically yes, but I view issues with the handle as far less
> likely than issues with any of the other parameters (in particular
> I don't see what an array of handles could be used for). So yes,
> if we want to be eager, we could deal with that one as well.

That's a fair point. I am happy either way.

I have also resent my patch (see [1]). This patch still applies on top 
of it and I have compile tested for arm32, arm64 and x86.

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,


[1] https://lore.kernel.org/xen-devel/20200404130613.26428-1-julien@xen.org/

> 
> Jan
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 04 13:59:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 13:59:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKjKQ-0001ca-GU; Sat, 04 Apr 2020 13:59:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qJcp=5U=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKjKO-0001cV-QM
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 13:59:16 +0000
X-Inumbo-ID: 7817e182-767c-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7817e182-767c-11ea-b58d-bc764e2007e4;
 Sat, 04 Apr 2020 13:59:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=8gbACX62BL2z3Nko+heUadre+spNyR3l+OSmTzHdsi8=; b=P+5pVAsYXI/U1C1kY1F7bV8QP
 1BQYYz3Euh2JWwv1VNQSpVzkPm0QFPW8mCf3IA+jLw7PpUNR5P625u+e38LnTLTWGZeSbRELTfevb
 c6w+vNNCEmML6I5hovW0dVnrE2c9ZpNY80cZMZ8q9ARyBvGnIZRw+MvctWL8tIld7EZ0Q=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKjKM-0000lX-U4; Sat, 04 Apr 2020 13:59:14 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKjKM-0004Kg-HH; Sat, 04 Apr 2020 13:59:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKjKM-0002hE-Ga; Sat, 04 Apr 2020 13:59:14 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149407-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149407: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=bc210e7ab25945895ea112a62b3435bd2b6b0e8d
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 04 Apr 2020 13:59:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              bc210e7ab25945895ea112a62b3435bd2b6b0e8d
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   78 days
Failing since        146211  2020-01-18 04:18:52 Z   77 days   74 attempts
Testing same since   149407  2020-04-04 04:18:49 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 13073 lines long.)


From xen-devel-bounces@lists.xenproject.org Sat Apr 04 23:30:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Apr 2020 23:30:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKsEj-0004vR-V6; Sat, 04 Apr 2020 23:30:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qJcp=5U=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKsEj-0004oY-0u
 for xen-devel@lists.xenproject.org; Sat, 04 Apr 2020 23:30:01 +0000
X-Inumbo-ID: 30370514-76cc-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 30370514-76cc-11ea-b58d-bc764e2007e4;
 Sat, 04 Apr 2020 23:29:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=u7Qy4YfJ29XPH3yJPTCIG8Md9rVE+75meb81CZyGE+M=; b=P9AfgXdIm49BSio51X1LhscfI
 n6InQl5IWUtHBYjrOQ7IF3hLnFUypD4NOg9OEPLAsC1DolWtschSDtrhgkwKd89WNe7lYkzSIbR2l
 bJy2lPlOke+Dv/YTVP7dfuShLBRWZZ1Enlx3u0/Fl2NInWDuuaBvQUVpcEdZSEDP4FIXY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKsEb-0003l5-Uq; Sat, 04 Apr 2020 23:29:54 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKsEb-0000hf-Mx; Sat, 04 Apr 2020 23:29:53 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKsEb-0001wc-Lf; Sat, 04 Apr 2020 23:29:53 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149406-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149406: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 xen-unstable:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
X-Osstest-Versions-That: xen=4de936a38aa96c946f5d39b2760abb8a9853cba3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 04 Apr 2020 23:29:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149378

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10   fail like 149335
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149378
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149378
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149378
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149378
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149378
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149378
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149378
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149378
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149378
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
baseline version:
 xen                  4de936a38aa96c946f5d39b2760abb8a9853cba3

Last test of basis   149378  2020-04-03 05:30:42 Z    1 days
Testing same since   149406  2020-04-04 04:00:10 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  George Dunlap <george.dunlap@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Simran Singhal <singhalsimran0@gmail.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4de936a38a..990b6e38d9  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd -> master


From xen-devel-bounces@lists.xenproject.org Sun Apr 05 02:43:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Apr 2020 02:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKvFj-0007KH-JK; Sun, 05 Apr 2020 02:43:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1oUj=5V=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKvFi-0007KC-8e
 for xen-devel@lists.xenproject.org; Sun, 05 Apr 2020 02:43:14 +0000
X-Inumbo-ID: 2c27a06c-76e7-11ea-bee8-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2c27a06c-76e7-11ea-bee8-12813bfff9fa;
 Sun, 05 Apr 2020 02:43:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=LS2SSD5amKsUBRquUQ2E1mTdgcKcMhh0eL+JuPMLdY4=; b=587ilI8+i5J+0BHuC2/5wUW3a
 3OkMeaSIe+3BR31SeFGSnCuBxrEj4w6ceTNzlCapXdH0Hk6InD9Z24fn0YlVw/nDAgKtvQkTr6ZKX
 vOHCQB16Vb1hN1jWPjQu7scGuE5FNLXuUN05CaDedvRB9G3zPR0CT4hMnXuLcwX+gmBBo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKvFX-0004NJ-IZ; Sun, 05 Apr 2020 02:43:03 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKvFX-0001ZN-3u; Sun, 05 Apr 2020 02:43:03 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKvFX-00008q-1r; Sun, 05 Apr 2020 02:43:03 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149409-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149409: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 05 Apr 2020 02:43:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail baseline untested
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  110 days
Failing since        144880  2019-12-16 20:07:08 Z  110 days  320 attempts
Testing same since   149409  2020-04-04 06:19:20 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Elazar Leibovich <elazar.leibovich@oracle.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Liran Alon <liran.alon@oracle.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Luwei Kang <luwei.kang@intel.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Bolshakov <r.bolshakov@yadro.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 56901 lines long.)


From xen-devel-bounces@lists.xenproject.org Sun Apr 05 06:43:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Apr 2020 06:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jKz0J-0001Jt-Ku; Sun, 05 Apr 2020 06:43:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1oUj=5V=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jKz0J-0001Jo-6o
 for xen-devel@lists.xenproject.org; Sun, 05 Apr 2020 06:43:35 +0000
X-Inumbo-ID: c4b37b1e-7708-11ea-bef5-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c4b37b1e-7708-11ea-bef5-12813bfff9fa;
 Sun, 05 Apr 2020 06:43:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=1CiziQggPdvmmne0g8X+X33Zp5FxULcvnUyybXVJmW4=; b=IAFR65M2MAlr4JvjRAjZsryQF
 gqozqkOufxYQo5f/Vdvh6z3j0O62f8Ef1SQFwM+fKiK2ruSk4Szg6S/585JtPiy6CBPK1YY9uFYoX
 zlC+GtWxWDEe9KH9UiK8sLT4Ji8/rtEiEI9qtIb9hnZ6YoOIjLpK5VquNT4r71zxDwwYw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKz0G-0000yD-UZ; Sun, 05 Apr 2020 06:43:32 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jKz0G-0003ne-HN; Sun, 05 Apr 2020 06:43:32 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jKz0G-0005Qj-Gi; Sun, 05 Apr 2020 06:43:32 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149434-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149434: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=bc210e7ab25945895ea112a62b3435bd2b6b0e8d
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 05 Apr 2020 06:43:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              bc210e7ab25945895ea112a62b3435bd2b6b0e8d
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   79 days
Failing since        146211  2020-01-18 04:18:52 Z   78 days   75 attempts
Testing same since   149407  2020-04-04 04:18:49 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 13073 lines long.)


From xen-devel-bounces@lists.xenproject.org Sun Apr 05 09:57:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Apr 2020 09:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jL226-0008TH-Px; Sun, 05 Apr 2020 09:57:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1oUj=5V=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jL225-0008TC-LU
 for xen-devel@lists.xenproject.org; Sun, 05 Apr 2020 09:57:37 +0000
X-Inumbo-ID: dc8d4ccc-7723-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id dc8d4ccc-7723-11ea-9e09-bc764e2007e4;
 Sun, 05 Apr 2020 09:57:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=wzztjlN/EiyRaD8KaD0flNsDW7kodlZcbKSZQ4Jsvh0=; b=jiTVgmepJvJ4mIWoGsaEXdb1q
 CiMSnQK/PUdbMG2BasHLQYsM/y4lZDeT7ZMVALfqm5TS//Qhut3nzbgwnCZtDWEZ2Sw4xv5Evn0/f
 VAIFFtlLe41JOec1SHpr5HMVPI9U2p1yZOnqYNuCFUUO7/KE+Fz14a210oKRoMGdu6jpQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jL21x-00054u-CC; Sun, 05 Apr 2020 09:57:29 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jL21x-00062H-1t; Sun, 05 Apr 2020 09:57:29 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jL21x-0000Xi-0u; Sun, 05 Apr 2020 09:57:29 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149413-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149413: regressions - trouble: broken/fail/pass
X-Osstest-Failures: linux-linus:test-amd64-i386-libvirt:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-freebsd10-i386:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-pvshim:<job status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-pair:<job status>:broken:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-raw:<job status>:broken:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-xsm:<job status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-pair:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-xsm:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-shadow:<job status>:broken:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:host-install(4):broken:regression
 linux-linus:test-amd64-i386-examine:capture-logs:broken:regression
 linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-examine:reboot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-raw:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-shadow:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-freebsd10-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-pair:capture-logs/src_host(12):broken:nonblocking
 linux-linus:test-amd64-i386-pair:capture-logs/dst_host(13):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-pair:capture-logs/src_host(12):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-pair:capture-logs/dst_host(13):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-raw:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-freebsd10-i386:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:capture-logs(5):broken:nonblocking
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=5364abc57993b3bf60c41923cb98a8f1a594e749
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 05 Apr 2020 09:57:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt         <job status>                 broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow    <job status>         broken
 test-amd64-i386-xl-qemuu-ovmf-amd64    <job status>                 broken
 test-amd64-i386-xl-qemuu-win7-amd64    <job status>                 broken
 test-amd64-i386-qemut-rhel6hvm-amd    <job status>                 broken
 test-amd64-i386-xl-qemut-win7-amd64    <job status>                 broken
 test-amd64-i386-freebsd10-i386    <job status>                 broken
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict    <job status>    broken
 test-amd64-i386-xl-qemuu-ws16-amd64    <job status>                 broken
 test-amd64-i386-xl-pvshim       <job status>                 broken
 test-amd64-i386-libvirt-pair    <job status>                 broken
 test-amd64-i386-qemuu-rhel6hvm-amd    <job status>                 broken
 test-amd64-i386-xl-raw          <job status>                 broken
 test-amd64-i386-freebsd10-amd64    <job status>                 broken
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm    <job status>    broken
 test-amd64-i386-libvirt-xsm     <job status>                 broken
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm    <job status>       broken
 test-amd64-i386-pair            <job status>                 broken
 test-amd64-i386-xl              <job status>                 broken
 test-amd64-i386-xl-qemut-debianhvm-amd64    <job status>                broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64    <job status>                broken
 test-amd64-i386-xl-qemut-ws16-amd64    <job status>                 broken
 test-amd64-i386-xl-xsm          <job status>                 broken
 test-amd64-i386-xl-shadow       <job status>                 broken
 test-amd64-i386-qemuu-rhel6hvm-intel    <job status>                 broken
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm    <job status>             broken
 test-amd64-i386-qemut-rhel6hvm-intel    <job status>                 broken
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm    <job status>             broken
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 4 host-install(4) broken REGR. vs. 149238
 test-amd64-i386-examine       9 capture-logs           broken REGR. vs. 149238
 test-amd64-i386-xl-pvshim     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-examine       8 reboot                   fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-libvirt       7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-shadow     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-pair         10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-pair         11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-raw        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-libvirt-xsm   7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-freebsd10-i386  7 xen-boot               fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl            7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-xsm        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot          fail REGR. vs. 149238

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-pvshim     8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemuu-ws16-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-shadow     8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-freebsd10-amd64  8 capture-logs(8)    broken blocked in 149238
 test-amd64-i386-libvirt       8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemut-ws16-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-pair     12 capture-logs/src_host(12) broken blocked in 149238
 test-amd64-i386-pair     13 capture-logs/dst_host(13) broken blocked in 149238
 test-amd64-i386-libvirt-pair 12 capture-logs/src_host(12) broken blocked in 149238
 test-amd64-i386-libvirt-pair 13 capture-logs/dst_host(13) broken blocked in 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-raw        8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-qemut-rhel6hvm-intel 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-libvirt-xsm   8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-freebsd10-i386  8 capture-logs(8)     broken blocked in 149238
 test-amd64-i386-xl            8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-win7-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemut-win7-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-qemut-rhel6hvm-amd  8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-xsm        8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 5 capture-logs(5) broken never pass
 test-amd64-amd64-dom0pvh-xl-intel 15 guest-saverestore        fail like 149238
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149238
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                5364abc57993b3bf60c41923cb98a8f1a594e749
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    5 days
Failing since        149266  2020-04-01 03:55:53 Z    4 days    5 attempts
Testing same since   149413  2020-04-04 10:10:11 Z    0 days    1 attempts

------------------------------------------------------------
1519 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            broken  
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         broken  
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  broken  
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  broken  
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       broken  
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     broken  
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     broken  
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          broken  
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          broken  
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         broken  
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      fail    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 broken  
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    broken  
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       broken  
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              broken  
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    broken  
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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

broken-job test-amd64-i386-libvirt broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken
broken-job test-amd64-i386-xl-qemuu-ovmf-amd64 broken
broken-job test-amd64-i386-xl-qemuu-win7-amd64 broken
broken-job test-amd64-i386-qemut-rhel6hvm-amd broken
broken-job test-amd64-i386-xl-qemut-win7-amd64 broken
broken-job test-amd64-i386-freebsd10-i386 broken
broken-job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken
broken-job test-amd64-i386-xl-qemuu-ws16-amd64 broken
broken-job test-amd64-i386-xl-pvshim broken
broken-job test-amd64-i386-libvirt-pair broken
broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken
broken-job test-amd64-i386-xl-raw broken
broken-job test-amd64-i386-freebsd10-amd64 broken
broken-job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm broken
broken-job test-amd64-i386-libvirt-xsm broken
broken-job test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm broken
broken-job test-amd64-i386-pair broken
broken-job test-amd64-i386-xl broken
broken-job test-amd64-i386-xl-qemut-debianhvm-amd64 broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-amd64 broken
broken-job test-amd64-i386-xl-qemut-ws16-amd64 broken
broken-job test-amd64-i386-xl-xsm broken
broken-job test-amd64-i386-xl-shadow broken
broken-job test-amd64-i386-qemuu-rhel6hvm-intel broken
broken-job test-amd64-i386-xl-qemut-debianhvm-i386-xsm broken
broken-job test-amd64-i386-qemut-rhel6hvm-intel broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken
broken-step test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict host-install(4)
broken-step test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict capture-logs(5)
broken-step test-amd64-i386-examine capture-logs
broken-step test-amd64-i386-qemuu-rhel6hvm-intel capture-logs(8)
broken-step test-amd64-i386-xl-pvshim capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-ws16-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-shadow capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 capture-logs(8)
broken-step test-amd64-i386-freebsd10-amd64 capture-logs(8)
broken-step test-amd64-i386-libvirt capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-debianhvm-i386-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-qemut-ws16-amd64 capture-logs(8)
broken-step test-amd64-i386-pair capture-logs/src_host(12)
broken-step test-amd64-i386-pair capture-logs/dst_host(13)
broken-step test-amd64-i386-libvirt-pair capture-logs/src_host(12)
broken-step test-amd64-i386-libvirt-pair capture-logs/dst_host(13)
broken-step test-amd64-i386-xl-qemut-debianhvm-i386-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-raw capture-logs(8)
broken-step test-amd64-i386-qemut-rhel6hvm-intel capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow capture-logs(8)
broken-step test-amd64-i386-libvirt-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm capture-logs(8)
broken-step test-amd64-i386-freebsd10-i386 capture-logs(8)
broken-step test-amd64-i386-xl capture-logs(8)
broken-step test-amd64-i386-qemuu-rhel6hvm-amd capture-logs(8)
broken-step test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-win7-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-qemut-win7-amd64 capture-logs(8)
broken-step test-amd64-i386-qemut-rhel6hvm-amd capture-logs(8)
broken-step test-amd64-i386-xl-xsm capture-logs(8)

Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Sun Apr 05 10:29:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Apr 2020 10:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jL2WR-0002bb-Jw; Sun, 05 Apr 2020 10:28:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1oUj=5V=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jL2WQ-0002bW-2v
 for xen-devel@lists.xenproject.org; Sun, 05 Apr 2020 10:28:58 +0000
X-Inumbo-ID: 3eb8483a-7728-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3eb8483a-7728-11ea-83d8-bc764e2007e4;
 Sun, 05 Apr 2020 10:28:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=aWg+3LSXTVjYqgwMg5UjQxHwl9v/OLDAyCcMCHg8tAo=; b=suBFEF7McRjcYDcOenIz5qG0m
 BdxAb9pPR7WtfFe/+50xU6JQvo19+4ykxKVg/VIDI6+id1RTUhTTOYiDdBet0lcxYDAbk1wvUXd06
 KP7F4EBtGgP7uG4W8oQHBOz4Gc9mlyR/s1mAIG50JeQjD+iK0hfF+QtfrJfOJ1jmKnBDU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jL2WK-0005jH-3G; Sun, 05 Apr 2020 10:28:52 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jL2WJ-0007Ly-Ed; Sun, 05 Apr 2020 10:28:51 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jL2WJ-0004aC-Dw; Sun, 05 Apr 2020 10:28:51 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149438-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-coverity test] 149438: all pass - PUSHED
X-Osstest-Versions-This: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
X-Osstest-Versions-That: xen=5af4698d98d881e786c0909b6308f04696586c49
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 05 Apr 2020 10:28:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
baseline version:
 xen                  5af4698d98d881e786c0909b6308f04696586c49

Last test of basis   149277  2020-04-01 09:29:59 Z    4 days
Testing same since   149438  2020-04-05 09:19:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  George Dunlap <george.dunlap@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Julien Grall <jgrall@amazon.com>
  Julien Grall <julien.grall@arm.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Simran Singhal <singhalsimran0@gmail.com>
  Stefano Stabellini <sstabellini@kernel.org>

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
   5af4698d98..990b6e38d9  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd -> coverity-tested/smoke


From xen-devel-bounces@lists.xenproject.org Sun Apr 05 14:48:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Apr 2020 14:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jL6ZS-0006GX-SY; Sun, 05 Apr 2020 14:48:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=r+i1=5V=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jL6ZR-0006GS-O7
 for xen-devel@lists.xenproject.org; Sun, 05 Apr 2020 14:48:21 +0000
X-Inumbo-ID: 7e129a98-774c-11ea-9e09-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7e129a98-774c-11ea-9e09-bc764e2007e4;
 Sun, 05 Apr 2020 14:48:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586098101;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=dv7fqLatEFV0k1yOtzP7ztFZ59iUfIbrYnd0MPag2ps=;
 b=hXtDTzW+aZCbpnz/5zHJl+Fy0vni+TLuqEHpnwAm/I57Ff8fxvU+u2RO
 dDQ3Z2fbgG72aE/mQKAhlVHuOicQF1SMA6R1eGlPIsN7Qf2+AGOoGnUzn
 i40cApAPDnODYyJBQ2ILuRmPOXTSeGXB87mVyMs/RgeT/mMqUtmKB8RRu M=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: OTHzUEhP62QBg4fFXvVb8uLmJK4qIDBWTjJMhyx6rJ5hjDe984Z4B71UT5CN/ip7l05rl1qvtj
 i1ypHqgOvRSotw6Q1MsIc4YWL4kOqSUukzDm3RFybCHCR2WcqgvrTVAUFzGuJpDY22A49LehDw
 KJDhWtqGpMEZPJGCa4nstvpOmAeXBeRaHYUNfPNA8UGkN7mwWeMF40VQzeC2twL/j4I+AEHqs0
 zkdJ9zz8xt5nafVu4kDlPbt56V5246SHmYrbqOVwNHJjd/7RIJBkyZs1EFyWt2iqdmKnZj9OQW
 UIw=
X-SBRS: 2.7
X-MesageID: 15208741
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,348,1580792400"; d="scan'208";a="15208741"
Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for
 OVMF
To: <xen-devel@lists.xenproject.org>
References: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <ae48819e-31f8-06ce-fe2e-e3f55af846ef@citrix.com>
Date: Sun, 5 Apr 2020 15:48:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <1585844328-30654-1-git-send-email-igor.druzhinin@citrix.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, wl@xen.org,
 jbeulich@suse.com, roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02/04/2020 17:18, Igor Druzhinin wrote:
> The area just below 4G where OVMF image is originally relocated is not
> necessarily a hole - it might contain pages preallocated by device model
> or the toolstack. By unconditionally populating on top of this memory
> the original pages are getting lost while still potentially foreign mapped
> in Dom0.
> 
> Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
> ---
> That doesn't seem necessary for at least upstream toolstack now.
> Alternative might be - to move population of this area to the toolstack
> where there is more control over memory layout.
> ---

Thanks for the discussion, please ignore this patch. We found a better way how
deal with our problem locally. We will introduce a reserved region within
MMIO hole that is managed similarly to stolen memory.

Igor


From xen-devel-bounces@lists.xenproject.org Sun Apr 05 15:33:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Apr 2020 15:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jL7Gs-0001jf-Ho; Sun, 05 Apr 2020 15:33:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1oUj=5V=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jL7Gr-0001ja-8n
 for xen-devel@lists.xenproject.org; Sun, 05 Apr 2020 15:33:13 +0000
X-Inumbo-ID: c16435e4-7752-11ea-bf4c-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c16435e4-7752-11ea-bf4c-12813bfff9fa;
 Sun, 05 Apr 2020 15:33:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2DXtIUUnRIMYyH1waPfFNN7L2HTNJSniSMwIxZn0i9c=; b=6h39b+j6BFzYoncFHVURz/aqr
 Hjji9Ra5DWiE4jEjvZvqd/iiRli2G6PYS6vBcmuvj6Qx7+H/Z/DoFlVhRuBPjLsBv8ABx+YAJO5zM
 FGBDyeedWgg6lwXg+rbsyTkDND91Q4kyfqvJrAXx32VoPGw0BDTNNDY7EkSy4QTbAlNME=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jL7Go-00034r-1t; Sun, 05 Apr 2020 15:33:10 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jL7Gn-0005Dx-Ow; Sun, 05 Apr 2020 15:33:09 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jL7Gn-0002AI-OI; Sun, 05 Apr 2020 15:33:09 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149431-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149431: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 xen-unstable:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate:fail:heisenbug
 xen-unstable:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:guest-start/debianhvm.repeat:fail:heisenbug
 xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
X-Osstest-Versions-That: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 05 Apr 2020 15:33:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds   16 guest-localmigrate fail in 149406 pass in 149431
 test-amd64-amd64-dom0pvh-xl-intel 16 guest-localmigrate    fail pass in 149406
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 guest-start/debianhvm.repeat fail pass in 149406
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149406

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149406
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail in 149406 blocked in 149431
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149406
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149406
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149406
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149406
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149406
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149406
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149406
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149406
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149406
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
baseline version:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd

Last test of basis   149431  2020-04-05 01:51:23 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Sun Apr 05 18:56:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Apr 2020 18:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLAR9-000171-Mr; Sun, 05 Apr 2020 18:56:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1oUj=5V=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLAR8-00016w-LH
 for xen-devel@lists.xenproject.org; Sun, 05 Apr 2020 18:56:02 +0000
X-Inumbo-ID: 16b0d806-776f-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 16b0d806-776f-11ea-83d8-bc764e2007e4;
 Sun, 05 Apr 2020 18:55:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tWQuPgVyTuD57DgwUVHRwfItjQsd/4x+/xaPiLOe9R4=; b=VaLd+8aViiZk7+o0ErHID+FFX
 3CzSd8yaZMu3USe6FGkbvdT/vArr/lQW5UxT/10+YYHi7iic8euoBSR9V//ZfWMCkXjOYsWlsgNTd
 VfG7lVn8eWOyu1Ak691tAPTbqA7YpDBKii7UTVOPIdfz6SINhbaskuC4TnvWM1/Ca0YJo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLAR5-0007Ol-36; Sun, 05 Apr 2020 18:55:59 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLAR4-0004Fn-PQ; Sun, 05 Apr 2020 18:55:58 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLAR4-0003X1-OQ; Sun, 05 Apr 2020 18:55:58 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149432-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149432: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 qemu-mainline:test-armhf-armhf-xl-rtds:guest-stop:fail:heisenbug
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 05 Apr 2020 18:55:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds   16 guest-localmigrate fail in 149409 pass in 149432
 test-armhf-armhf-xl-rtds     15 guest-stop                 fail pass in 149409

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail in 149409 baseline untested
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 144861
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  111 days
Failing since        144880  2019-12-16 20:07:08 Z  110 days  321 attempts
Testing same since   149409  2020-04-04 06:19:20 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Elazar Leibovich <elazar.leibovich@oracle.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Liran Alon <liran.alon@oracle.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Luwei Kang <luwei.kang@intel.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Bolshakov <r.bolshakov@yadro.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 56901 lines long.)


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 01:50:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 01:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLGtY-0002xx-Mr; Mon, 06 Apr 2020 01:49:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=zgfQ=5W=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLGtX-0002xs-PM
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 01:49:47 +0000
X-Inumbo-ID: e3a1102c-77a8-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e3a1102c-77a8-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 01:49:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=FaE2lTakT4fX/vtF+zNCXSiXwKLEvG82ZQQNJ3Eqe20=; b=2/gAJZNe4KEHUiDEvffGC9D8R
 23qgn+O9E+SH9oCZ7f6W88IDdgqgaZ8ezwGpBgO1UH/ImVTsXU6vx8xEpeE5Pf0TxVPoRTW9HBLUx
 akc0h+K9pRbavgy+spz7qxOJyFJWK4tAy4LrNgiLiE2O64/oiQG6HZ8Z77mFRn3DrTBt4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLGtU-0003S6-9j; Mon, 06 Apr 2020 01:49:44 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLGtU-00065p-0R; Mon, 06 Apr 2020 01:49:44 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLGtT-0006Ox-VU; Mon, 06 Apr 2020 01:49:43 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149439-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149439: regressions - trouble: broken/fail/pass
X-Osstest-Failures: linux-linus:test-amd64-i386-freebsd10-i386:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-shadow:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:<job status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-pair:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-xsm:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-pair:<job status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:<job status>:broken:regression
 linux-linus:test-amd64-i386-libvirt:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-xsm:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-raw:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-pvshim:<job status>:broken:regression
 linux-linus:test-amd64-i386-examine:capture-logs:broken:regression
 linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-examine:reboot:fail:regression
 linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-boot:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-raw:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-i386-xl-pvshim:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-freebsd10-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-shadow:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-pair:capture-logs/src_host(12):broken:nonblocking
 linux-linus:test-amd64-i386-pair:capture-logs/dst_host(13):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-pair:capture-logs/src_host(12):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-pair:capture-logs/dst_host(13):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-raw:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-freebsd10-i386:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=4c205c84e249e0a91dcfabe461d77667ec9b2d05
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 06 Apr 2020 01:49:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386    <job status>                 broken
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm    <job status>             broken
 test-amd64-i386-xl              <job status>                 broken
 test-amd64-i386-xl-qemuu-ovmf-amd64    <job status>                 broken
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict    <job status>    broken
 test-amd64-i386-xl-shadow       <job status>                 broken
 test-amd64-i386-xl-qemut-debianhvm-amd64    <job status>                broken
 test-amd64-i386-qemuu-rhel6hvm-amd    <job status>                 broken
 test-amd64-i386-libvirt-pair    <job status>                 broken
 test-amd64-i386-xl-qemuu-ws16-amd64    <job status>                 broken
 test-amd64-i386-libvirt-xsm     <job status>                 broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64    <job status>                broken
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm    <job status>             broken
 test-amd64-i386-xl-qemuu-win7-amd64    <job status>                 broken
 test-amd64-i386-pair            <job status>                 broken
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm    <job status>       broken
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm    <job status>    broken
 test-amd64-i386-xl-qemut-ws16-amd64    <job status>                 broken
 test-amd64-i386-freebsd10-amd64    <job status>                 broken
 test-amd64-i386-qemut-rhel6hvm-intel    <job status>                 broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow    <job status>         broken
 test-amd64-i386-qemuu-rhel6hvm-intel    <job status>                 broken
 test-amd64-i386-qemut-rhel6hvm-amd    <job status>                 broken
 test-amd64-i386-libvirt         <job status>                 broken
 test-amd64-i386-xl-xsm          <job status>                 broken
 test-amd64-i386-xl-raw          <job status>                 broken
 test-amd64-i386-xl-qemut-win7-amd64    <job status>                 broken
 test-amd64-i386-xl-pvshim       <job status>                 broken
 test-amd64-i386-examine       9 capture-logs           broken REGR. vs. 149238
 test-amd64-i386-xl-pvshim     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-examine       8 reboot                   fail REGR. vs. 149238
 test-amd64-i386-libvirt       7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-shadow     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-pair         10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-pair         11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-raw        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-libvirt-xsm   7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl            7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-xsm        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-freebsd10-i386  7 xen-boot               fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot          fail REGR. vs. 149238

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim     8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemuu-ws16-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-qemuu-rhel6hvm-intel 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-freebsd10-amd64  8 capture-logs(8)    broken blocked in 149238
 test-amd64-i386-libvirt       8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-shadow     8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-pair     12 capture-logs/src_host(12) broken blocked in 149238
 test-amd64-i386-pair     13 capture-logs/dst_host(13) broken blocked in 149238
 test-amd64-i386-libvirt-pair 12 capture-logs/src_host(12) broken blocked in 149238
 test-amd64-i386-libvirt-pair 13 capture-logs/dst_host(13) broken blocked in 149238
 test-amd64-i386-xl-qemut-ws16-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-raw        8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-qemut-rhel6hvm-intel 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-libvirt-xsm   8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl            8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-win7-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-freebsd10-i386  8 capture-logs(8)     broken blocked in 149238
 test-amd64-i386-xl-qemut-win7-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-qemut-rhel6hvm-amd  8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-xsm        8 capture-logs(8)       broken blocked in 149238
 test-amd64-amd64-dom0pvh-xl-intel 15 guest-saverestore        fail like 149238
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                4c205c84e249e0a91dcfabe461d77667ec9b2d05
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    5 days
Failing since        149266  2020-04-01 03:55:53 Z    4 days    6 attempts
Testing same since   149439  2020-04-05 10:05:52 Z    0 days    1 attempts

------------------------------------------------------------
1565 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            broken  
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         broken  
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  broken  
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  broken  
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       broken  
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     broken  
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     broken  
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          broken  
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          broken  
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         broken  
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      fail    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 broken  
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    broken  
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       broken  
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              broken  
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    broken  
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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

broken-job test-amd64-i386-freebsd10-i386 broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken
broken-job test-amd64-i386-xl broken
broken-job test-amd64-i386-xl-qemuu-ovmf-amd64 broken
broken-job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken
broken-job test-amd64-i386-xl-shadow broken
broken-job test-amd64-i386-xl-qemut-debianhvm-amd64 broken
broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken
broken-job test-amd64-i386-libvirt-pair broken
broken-job test-amd64-i386-xl-qemuu-ws16-amd64 broken
broken-job test-amd64-i386-libvirt-xsm broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-amd64 broken
broken-job test-amd64-i386-xl-qemut-debianhvm-i386-xsm broken
broken-job test-amd64-i386-xl-qemuu-win7-amd64 broken
broken-job test-amd64-i386-pair broken
broken-job test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm broken
broken-job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm broken
broken-job test-amd64-i386-xl-qemut-ws16-amd64 broken
broken-job test-amd64-i386-freebsd10-amd64 broken
broken-job test-amd64-i386-qemut-rhel6hvm-intel broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken
broken-job test-amd64-i386-qemuu-rhel6hvm-intel broken
broken-job test-amd64-i386-qemut-rhel6hvm-amd broken
broken-job test-amd64-i386-libvirt broken
broken-job test-amd64-i386-xl-xsm broken
broken-job test-amd64-i386-xl-raw broken
broken-job test-amd64-i386-xl-qemut-win7-amd64 broken
broken-job test-amd64-i386-xl-pvshim broken
broken-step test-amd64-i386-examine capture-logs
broken-step test-amd64-i386-xl-pvshim capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-ws16-amd64 capture-logs(8)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 capture-logs(8)
broken-step test-amd64-i386-freebsd10-amd64 capture-logs(8)
broken-step test-amd64-i386-libvirt capture-logs(8)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-shadow capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-debianhvm-i386-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict capture-logs(8)
broken-step test-amd64-i386-pair capture-logs/src_host(12)
broken-step test-amd64-i386-pair capture-logs/dst_host(13)
broken-step test-amd64-i386-libvirt-pair capture-logs/src_host(12)
broken-step test-amd64-i386-libvirt-pair capture-logs/dst_host(13)
broken-step test-amd64-i386-xl-qemut-ws16-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-qemut-debianhvm-i386-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-raw capture-logs(8)
broken-step test-amd64-i386-qemut-rhel6hvm-intel capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow capture-logs(8)
broken-step test-amd64-i386-libvirt-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm capture-logs(8)
broken-step test-amd64-i386-xl capture-logs(8)
broken-step test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-win7-amd64 capture-logs(8)
broken-step test-amd64-i386-freebsd10-i386 capture-logs(8)
broken-step test-amd64-i386-xl-qemut-win7-amd64 capture-logs(8)
broken-step test-amd64-i386-qemut-rhel6hvm-amd capture-logs(8)
broken-step test-amd64-i386-qemuu-rhel6hvm-amd capture-logs(8)
broken-step test-amd64-i386-xl-xsm capture-logs(8)

Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 07:31:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 07:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLMDr-0006OG-Df; Mon, 06 Apr 2020 07:31:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=zgfQ=5W=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLMDq-0006OB-In
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 07:31:06 +0000
X-Inumbo-ID: 920df4ac-77d8-11ea-bfcf-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 920df4ac-77d8-11ea-bfcf-12813bfff9fa;
 Mon, 06 Apr 2020 07:31:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Wx1TCfNFNwkWIEzVF8/bTTsuQqwHiihHLDQYBki5t8k=; b=H82ZDOHmKeZdaylBFK2iIw8sE
 UDJF31UwEj2NZ34inEpDMa3X0Dj8ECeSkhhihX+GPuCxGr+OFTRIsdVy5v/PG/ZkMwbaASn9PRRDV
 XaunJ16+XPDaNK+m+N7iAfrpi9nksoPx6ffoX9ysSU9B04MLgfnAGNWeiEnoG8c4lEKUU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLMDn-0002rh-AK; Mon, 06 Apr 2020 07:31:03 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLMDm-0003tZ-V1; Mon, 06 Apr 2020 07:31:03 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLMDm-0007p7-UP; Mon, 06 Apr 2020 07:31:02 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149455-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149455: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=bc210e7ab25945895ea112a62b3435bd2b6b0e8d
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 06 Apr 2020 07:31:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              bc210e7ab25945895ea112a62b3435bd2b6b0e8d
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   80 days
Failing since        146211  2020-01-18 04:18:52 Z   79 days   76 attempts
Testing same since   149407  2020-04-04 04:18:49 Z    2 days    3 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 13073 lines long.)


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 07:40:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 07:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLMNA-0007Fx-Cn; Mon, 06 Apr 2020 07:40:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=etk8=5W=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLMN8-0007Fr-UM
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 07:40:43 +0000
X-Inumbo-ID: ea6ddec2-77d9-11ea-9e09-bc764e2007e4
Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ea6ddec2-77d9-11ea-9e09-bc764e2007e4;
 Mon, 06 Apr 2020 07:40:41 +0000 (UTC)
Received: by mail-ed1-x541.google.com with SMTP id w26so18015722edu.7
 for <xen-devel@lists.xenproject.org>; Mon, 06 Apr 2020 00:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=aFQrE65ZynsGQgKaw/uB4/EYtHsyrntpjl9oZ1hzedM=;
 b=YMnx72uknjlGZXWV17Lw9MoK34HIfBWN48VTwJynrsBljLLVbBiuDjmYM4UpoUQLCN
 D3uPEb1sbCBeaVLb85H87ISnlsxCTZ2PVe+AfbUdQ+Hk1khCijN89yvdx/5QVtbPYrPt
 5lizR3Zs9MxlIa0frAibWetzzBxUb0yKb96iVzzxB5IBUKywl13T4sToIQCqZa/ahA56
 TETCKV2jfMQmWPMe4TXhnAE262Y4UDHsHu8xmxgk4ZWt84UenogAGl9bylUFnCj162FE
 hgWhNuO20x86ehJVFhogAl9twpf6rUpXCHMtZpimPi6s9rBZIxSNw1dM/4PPwJOtuaEg
 dOBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=aFQrE65ZynsGQgKaw/uB4/EYtHsyrntpjl9oZ1hzedM=;
 b=k64zHujvmLssnk5us9gmg2s6r+opRN1DduYJfGWeNnYsulkROfb31txXTrVQT75PiY
 anvw0kigQBikz1IJ2azioPmQBVIWt5DPtfbiJfCvjpcaOQDxF6OvZAzaSdAaN3BWYiEq
 PSKF/PJOgV5FUU47dulWMR4shaYHv99CnqBwBHC4WJ3fI0vXLh+AZRB7aujcbzPCgyZa
 gvR2wMjEVJ1t9CrEevnJ6EBkPudJAztrweOaPAvby/eL/OAC464aQW+lMdrFm4UA8Z8s
 PoOo+sbVOW7TEVxzYhC+tO26FDl6lZ6pMUl+dn/Brod9kF/ru/NGwBs1ySC86W0L1km4
 pV+Q==
X-Gm-Message-State: AGi0PubTLBYiHrWuHloKafdQz8xpk8THn1CqnRSU7yaTp0+6X9ZUGmhl
 pW3k0cpQnIEHrpHJz0djiLo=
X-Google-Smtp-Source: APiQypIm4klUzoFnHSneIdVAhAnozUhDDop8taGrepSTQIeR051gK2VI/teudcpuobJNkKp1v8FA5A==
X-Received: by 2002:a17:906:2443:: with SMTP id
 a3mr19115631ejb.291.1586158840919; 
 Mon, 06 Apr 2020 00:40:40 -0700 (PDT)
Received: from CBGR90WXYV0 (54-240-197-238.amazon.com. [54.240.197.238])
 by smtp.gmail.com with ESMTPSA id d13sm1807135ejt.74.2020.04.06.00.40.39
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 06 Apr 2020 00:40:40 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-6-julien@xen.org>
In-Reply-To: <20200404131017.27330-6-julien@xen.org>
Subject: RE: [PATCH 5/7] xen: include xen/guest_access.h rather than
 asm/guest_access.h
Date: Mon, 6 Apr 2020 08:40:39 +0100
Message-ID: <001201d60be6$ab976e20$02c64a60$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQHjDao9mfUo56zNNvPnoPfBojMtUAMctY5mqDjLfhA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Kevin Tian' <kevin.tian@intel.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Jun Nakajima' <jun.nakajima@intel.com>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Julien Grall' <jgrall@amazon.com>, 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>,
 'Volodymyr Babchuk' <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?'Roger_Pau_Monn=C3=A9'?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 04 April 2020 14:10
> To: xen-devel@lists.xenproject.org
> Cc: julien@xen.org; Julien Grall <jgrall@amazon.com>; Stefano =
Stabellini <sstabellini@kernel.org>;
> Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>; Andrew Cooper =
<andrew.cooper3@citrix.com>; George
> Dunlap <george.dunlap@citrix.com>; Ian Jackson =
<ian.jackson@eu.citrix.com>; Jan Beulich
> <jbeulich@suse.com>; Wei Liu <wl@xen.org>; Roger Pau Monn=C3=A9 =
<roger.pau@citrix.com>; Paul Durrant
> <paul@xen.org>; Jun Nakajima <jun.nakajima@intel.com>; Kevin Tian =
<kevin.tian@intel.com>
> Subject: [PATCH 5/7] xen: include xen/guest_access.h rather than =
asm/guest_access.h
>=20
> From: Julien Grall <jgrall@amazon.com>
>=20
> Only a few places are actually including asm/guest_access.h. While =
this
> is fine today, a follow-up patch will want to move most of the helpers
> from asm/guest_access.h to xen/guest_access.h.
>=20
> To prepare the move, everyone should include xen/guest_access.h rather
> than asm/guest_access.h.
>=20
> Interestingly, asm-arm/guest_access.h includes xen/guest_access.h. The
> inclusion is now removed as no-one but the latter should include the
> former.
>=20
> Signed-off-by: Julien Grall <jgrall@amazon.com>
> ---
>  xen/arch/arm/decode.c                |  2 +-
>  xen/arch/arm/domain.c                |  2 +-
>  xen/arch/arm/guest_walk.c            |  3 ++-
>  xen/arch/arm/guestcopy.c             |  2 +-
>  xen/arch/arm/vgic-v3-its.c           |  2 +-
>  xen/arch/x86/hvm/svm/svm.c           |  2 +-
>  xen/arch/x86/hvm/viridian/viridian.c |  2 +-
>  xen/arch/x86/hvm/vmx/vmx.c           |  2 +-
>  xen/common/libelf/libelf-loader.c    |  2 +-
>  xen/include/asm-arm/guest_access.h   |  1 -
>  xen/include/asm-x86/guest_access.h   | 22 ++++++++++++----------
>  xen/lib/x86/private.h                |  2 +-
>  12 files changed, 23 insertions(+), 21 deletions(-)
>=20
> diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c
> index 144793c8ce..792c2e92a7 100644
> --- a/xen/arch/arm/decode.c
> +++ b/xen/arch/arm/decode.c
> @@ -17,12 +17,12 @@
>   * GNU General Public License for more details.
>   */
>=20
> +#include <xen/guest_access.h>
>  #include <xen/lib.h>
>  #include <xen/sched.h>
>  #include <xen/types.h>
>=20
>  #include <asm/current.h>
> -#include <asm/guest_access.h>
>=20
>  #include "decode.h"
>=20
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 2190d908eb..b062c232b6 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -12,6 +12,7 @@
>  #include <xen/bitops.h>
>  #include <xen/errno.h>
>  #include <xen/grant_table.h>
> +#include <xen/guest_access.h>
>  #include <xen/hypercall.h>
>  #include <xen/init.h>
>  #include <xen/lib.h>
> @@ -26,7 +27,6 @@
>  #include <asm/current.h>
>  #include <asm/event.h>
>  #include <asm/gic.h>
> -#include <asm/guest_access.h>
>  #include <asm/guest_atomics.h>
>  #include <asm/irq.h>
>  #include <asm/p2m.h>
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index a1cdd7f4af..b4496c4c86 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -16,8 +16,9 @@
>   */
>=20
>  #include <xen/domain_page.h>
> +#include <xen/guest_access.h>
>  #include <xen/sched.h>
> -#include <asm/guest_access.h>
> +
>  #include <asm/guest_walk.h>
>  #include <asm/short-desc.h>
>=20
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index c8023e2bca..32681606d8 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -1,10 +1,10 @@
>  #include <xen/domain_page.h>
> +#include <xen/guest_access.h>
>  #include <xen/lib.h>
>  #include <xen/mm.h>
>  #include <xen/sched.h>
>=20
>  #include <asm/current.h>
> -#include <asm/guest_access.h>
>=20
>  #define COPY_flush_dcache   (1U << 0)
>  #define COPY_from_guest     (0U << 1)
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index 6e153c698d..58d939b85f 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -32,6 +32,7 @@
>  #include <xen/bitops.h>
>  #include <xen/config.h>
>  #include <xen/domain_page.h>
> +#include <xen/guest_access.h>
>  #include <xen/lib.h>
>  #include <xen/init.h>
>  #include <xen/softirq.h>
> @@ -39,7 +40,6 @@
>  #include <xen/sched.h>
>  #include <xen/sizes.h>
>  #include <asm/current.h>
> -#include <asm/guest_access.h>
>  #include <asm/mmio.h>
>  #include <asm/gic_v3_defs.h>
>  #include <asm/gic_v3_its.h>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 888f504a94..9e14a451eb 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -16,6 +16,7 @@
>   * this program; If not, see <http://www.gnu.org/licenses/>.
>   */
>=20
> +#include <xen/guest_access.h>
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  #include <xen/trace.h>
> @@ -34,7 +35,6 @@
>  #include <asm/cpufeature.h>
>  #include <asm/processor.h>
>  #include <asm/amd.h>
> -#include <asm/guest_access.h>
>  #include <asm/debugreg.h>
>  #include <asm/msr.h>
>  #include <asm/i387.h>
> diff --git a/xen/arch/x86/hvm/viridian/viridian.c =
b/xen/arch/x86/hvm/viridian/viridian.c
> index 977c1bc54f..dc7183a546 100644
> --- a/xen/arch/x86/hvm/viridian/viridian.c
> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> @@ -5,12 +5,12 @@
>   * Hypervisor Top Level Functional Specification for more =
information.
>   */
>=20
> +#include <xen/guest_access.h>
>  #include <xen/sched.h>
>  #include <xen/version.h>
>  #include <xen/hypercall.h>
>  #include <xen/domain_page.h>
>  #include <xen/param.h>
> -#include <asm/guest_access.h>
>  #include <asm/guest/hyperv-tlfs.h>
>  #include <asm/paging.h>
>  #include <asm/p2m.h>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 1c398fdb6e..98e9c91ea3 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -15,6 +15,7 @@
>   * this program; If not, see <http://www.gnu.org/licenses/>.
>   */
>=20
> +#include <xen/guest_access.h>
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  #include <xen/param.h>
> @@ -31,7 +32,6 @@
>  #include <asm/regs.h>
>  #include <asm/cpufeature.h>
>  #include <asm/processor.h>
> -#include <asm/guest_access.h>
>  #include <asm/debugreg.h>
>  #include <asm/msr.h>
>  #include <asm/p2m.h>
> diff --git a/xen/common/libelf/libelf-loader.c =
b/xen/common/libelf/libelf-loader.c
> index 0f468727d0..629cc0d3e6 100644
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -16,7 +16,7 @@
>   */
>=20
>  #ifdef __XEN__
> -#include <asm/guest_access.h>
> +#include <xen/guest_access.h>
>  #endif
>=20
>  #include "libelf-private.h"
> diff --git a/xen/include/asm-arm/guest_access.h =
b/xen/include/asm-arm/guest_access.h
> index 4046d50347..93d56868f1 100644
> --- a/xen/include/asm-arm/guest_access.h
> +++ b/xen/include/asm-arm/guest_access.h
> @@ -1,7 +1,6 @@
>  #ifndef __ASM_ARM_GUEST_ACCESS_H__
>  #define __ASM_ARM_GUEST_ACCESS_H__
>=20
> -#include <xen/guest_access.h>
>  #include <xen/errno.h>
>  #include <xen/sched.h>
>=20
> diff --git a/xen/include/asm-x86/guest_access.h =
b/xen/include/asm-x86/guest_access.h
> index 9ee275d01f..5c3dfc47b6 100644
> --- a/xen/include/asm-x86/guest_access.h
> +++ b/xen/include/asm-x86/guest_access.h
> @@ -54,22 +54,24 @@
>=20
>  /* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
>  #define guest_handle_to_param(hnd, type) ({                  \
> +    typeof((hnd).p) _x =3D (hnd).p;                            \
> +    XEN_GUEST_HANDLE_PARAM(type) _y =3D { _x };                \
>      /* type checking: make sure that the pointers inside     \
>       * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
>       * the same type, then return hnd */                     \
> -    (void)((typeof(&(hnd).p)) 0 =3D=3D                           \
> -        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
> -    (hnd);                                                   \
> +    (void)(&_x =3D=3D &_y.p);                                    \
> +    _y;                                                      \
>  })
>=20
>  /* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
> -#define guest_handle_from_param(hnd, type) ({                \
> -    /* type checking: make sure that the pointers inside     \
> -     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
> -     * the same type, then return hnd */                     \
> -    (void)((typeof(&(hnd).p)) 0 =3D=3D                           \
> -        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
> -    (hnd);                                                   \
> +#define guest_handle_from_param(hnd, type) ({               \
> +    typeof((hnd).p) _x =3D (hnd).p;                           \
> +    XEN_GUEST_HANDLE(type) _y =3D { _x };                     \
> +    /* type checking: make sure that the pointers inside    \
> +     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
> +     * the same type, then return hnd */                    \
> +    (void)(&_x =3D=3D &_y.p);                                   \
> +    _y;                                                     \
>  })
>=20

The commit comment would have the reader believe that this patch is just =
some changes in header file inclusion. These last two hunks are =
something else so I would suggest they get split out into a separate =
patch.

  Paul

>  #define guest_handle_for_field(hnd, type, fld)          \
> diff --git a/xen/lib/x86/private.h b/xen/lib/x86/private.h
> index b793181464..2d53bd3ced 100644
> --- a/xen/lib/x86/private.h
> +++ b/xen/lib/x86/private.h
> @@ -4,12 +4,12 @@
>  #ifdef __XEN__
>=20
>  #include <xen/bitops.h>
> +#include <xen/guest_access.h>
>  #include <xen/kernel.h>
>  #include <xen/lib.h>
>  #include <xen/nospec.h>
>  #include <xen/types.h>
>=20
> -#include <asm/guest_access.h>
>  #include <asm/msr-index.h>
>=20
>  #define copy_to_buffer_offset copy_to_guest_offset
> --
> 2.17.1




From xen-devel-bounces@lists.xenproject.org Mon Apr 06 07:50:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 07:50:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLMWY-00089w-Gm; Mon, 06 Apr 2020 07:50:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=etk8=5W=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLMWX-00089r-97
 for xen-devel@lists.xen.org; Mon, 06 Apr 2020 07:50:25 +0000
X-Inumbo-ID: 4597a3ea-77db-11ea-9e09-bc764e2007e4
Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4597a3ea-77db-11ea-9e09-bc764e2007e4;
 Mon, 06 Apr 2020 07:50:24 +0000 (UTC)
Received: by mail-ed1-x544.google.com with SMTP id v1so18026106edq.8
 for <xen-devel@lists.xen.org>; Mon, 06 Apr 2020 00:50:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=4qcawpa47PB085W508PsWHKMkbC38SCDQTtKqzAFNL8=;
 b=BCSbcKn1M8QpQlXF6aqW0yfFzjAwC8oFGFrGk3I+ZzJU3kmlqc94ijU1we3BNYjbXP
 AYZobo97H18P27hI/e4Gy+Wou9uLdQ+cZro1YMexYPX7/sxZn8N70VnaWHsvPYneajNG
 IH8LyoP7+lD11mqc/+8xvL4mn7nN7TLVxDrYOJyafOxd2pTnXa3NOsLtxM3N9NDC8ZHZ
 MVaNWXXm/t1+9sJD7bZTxOf/Mprf6hKXtEwItDsGB397vsS5l1ygQjDjYo+8lS/nqRmK
 vZ3WGuxDOeoK8mZE1NWEQSp88cdFRiKzGCc/dL2urkh6+7H/tRXWvjI22/euAWpTx9rY
 90ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject
 :date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=4qcawpa47PB085W508PsWHKMkbC38SCDQTtKqzAFNL8=;
 b=LO4Yx4CbdwEo0kd4a153QtM0dQiLovH/Gj24523AQQsD4ufeNb8JbcBevsaaL5h1t4
 A+tIwSSgz9C20B3BURjPIKdp+w7ErjxFIwhauuMGyaPWU0OyhnyspM3pTuaFMTUUnoac
 jXDhKjodhx6iRsMc5BX/CtFPsS/wau6n1SURqbjzqCsUn0bPWCT9YD3atHdZ8489/gj6
 G80Lpx+TXFPS/MkpTWzt+wcPLdOwzfZNBjmIpcwBMlMJGno8/UvSBDhPjKHPzaryD5aM
 6bxnmsuuZH6o0B5qYubhlX7X4p60YEu1pCrlnyO8pVVZHOn9xFQgTd0DtG7IRhlUjWW7
 EOig==
X-Gm-Message-State: AGi0PuaNasm8VUghIj6ekgcXkYtBArjH13YXlsbKk7phupwce0JN69pc
 e0f3TWx3W/OAqqqr3bfAfIM=
X-Google-Smtp-Source: APiQypI0EUWBKYbznEtKPNz5UwUrsSO/J4XDLwMPOMVoE1DefD8K8rZJMluaXdDHLYWcnpOIlJlXag==
X-Received: by 2002:a17:906:5c43:: with SMTP id
 c3mr19671805ejr.3.1586159423195; 
 Mon, 06 Apr 2020 00:50:23 -0700 (PDT)
Received: from CBGR90WXYV0 (54-240-197-238.amazon.com. [54.240.197.238])
 by smtp.gmail.com with ESMTPSA id s4sm2429352edw.19.2020.04.06.00.50.22
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 06 Apr 2020 00:50:22 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Dongli Zhang'" <dongli.zhang@oracle.com>,
 "'Andrew Cooper'" <andrew.cooper3@citrix.com>,
 "'Anastassios Nanos'" <anastassios.nanos@sunlight.io>,
 <xen-devel@lists.xen.org>
References: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
 <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
 <d698f1ed-247e-404c-04ce-762c651771d1@oracle.com>
In-Reply-To: <d698f1ed-247e-404c-04ce-762c651771d1@oracle.com>
Subject: RE: Live migration and PV device handling
Date: Mon, 6 Apr 2020 08:50:21 +0100
Message-ID: <001301d60be8$06afa1a0$140ee4e0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJ9hFEeoa99jEIZ37IjX6uiVjJ3WQHz1sx0AqxQcWKm98VpMA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of =
Dongli Zhang
> Sent: 03 April 2020 23:33
> To: Andrew Cooper <andrew.cooper3@citrix.com>; Anastassios Nanos =
<anastassios.nanos@sunlight.io>; xen-
> devel@lists.xen.org
> Subject: Re: Live migration and PV device handling
>=20
> Hi Andrew,
>=20
> On 4/3/20 5:42 AM, Andrew Cooper wrote:
> > On 03/04/2020 13:32, Anastassios Nanos wrote:
> >> Hi all,
> >>
> >> I am trying to understand how live-migration happens in xen. I am
> >> looking in the HVM guest case and I have dug into the relevant =
parts
> >> of the toolstack and the hypervisor regarding memory, vCPU context
> >> etc.
> >>
> >> In particular, I am interested in how PV device migration happens. =
I
> >> assume that the guest is not aware of any suspend/resume operations
> >> being done
> >
> > Sadly, this assumption is not correct.  HVM guests with PV drivers
> > currently have to be aware in exactly the same way as PV guests.
> >
> > Work is in progress to try and address this.  See
> > =
https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3D775a02452d=
df3a6889690de90b1a94eb29c3c732
> > (sorry - for some reason that doc isn't being rendered properly in
> > https://xenbits.xen.org/docs/ )
> >
>=20
> I read below from the commit:
>=20
> +* The toolstack choose a randomized domid for initial creation or =
default
> +migration, but preserve the source domid non-cooperative migration.
> +Non-Cooperative migration will have to be denied if the domid is
> +unavailable on the target host, but randomization of domid on =
creation
> +should hopefully minimize the likelihood of this. Non-Cooperative =
migration
> +to localhost will clearly not be possible.
>=20
> Does that indicate while scope of domid_t is shared by a single server =
in old
> design, the scope of domid_t is shared by a cluster of server in new =
design?
>=20
> That is, the domid should be unique in the cluster of all servers if =
we expect
> non-cooperative migration always succeed?
>=20

That would be necessary to guarantee success (or rather guarantee no =
failure due to domid clash) but the scope of xl/libxl is single serve, =
hence randomization is the best we have to reduce clashes to a minimum.

  Paul



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 07:55:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 07:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLMb4-0008Li-9O; Mon, 06 Apr 2020 07:55:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=zgfQ=5W=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLMb3-0008Ld-PX
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 07:55:05 +0000
X-Inumbo-ID: e88611af-77db-11ea-bfd0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e88611af-77db-11ea-bfd0-12813bfff9fa;
 Mon, 06 Apr 2020 07:54:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=zRrbznSLn1Po2X2wdForfulw6GTNFD71ojxcHL3+n1k=; b=EBFJBCBJ4lIsnDoDoTIz2hv9d
 Ps36ZiEUUNXI0iSB+C9A4J7S0DzCSSeAu+/7NgdzHyWogo3KAA0imgxO6j2kKs1BLoTsSO8Ks88P5
 8W2JvLUQZB4j9OyxznwA9MeH+cOqp1ncE3xa1x2B/COP8xup5TsZIVqts3+cLrBaus5/w=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLMav-0003JK-9B; Mon, 06 Apr 2020 07:54:57 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLMau-0005A6-Ue; Mon, 06 Apr 2020 07:54:57 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLMau-0007sh-U3; Mon, 06 Apr 2020 07:54:56 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149447-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149447: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-amd:guest-start/debian.repeat:fail:nonblocking
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 06 Apr 2020 07:54:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds   16 guest-localmigrate fail in 149409 pass in 149447
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149409

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-amd 20 guest-start/debian.repeat fail baseline untested
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail in 149409 baseline untested
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 144861
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  111 days
Failing since        144880  2019-12-16 20:07:08 Z  111 days  322 attempts
Testing same since   149409  2020-04-04 06:19:20 Z    2 days    3 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Elazar Leibovich <elazar.leibovich@oracle.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Liran Alon <liran.alon@oracle.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Luwei Kang <luwei.kang@intel.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Bolshakov <r.bolshakov@yadro.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 56901 lines long.)


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 08:17:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 08:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLMwL-00029G-ND; Mon, 06 Apr 2020 08:17:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Lhp/=5W=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jLMwJ-00029B-Kj
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 08:17:03 +0000
X-Inumbo-ID: fc9594e6-77de-11ea-bfd5-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fc9594e6-77de-11ea-bfd5-12813bfff9fa;
 Mon, 06 Apr 2020 08:16:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586161019;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=5pHG+Clk9GGLPdJQKpggaAZW3Q+Tf++1CLgU5tkdt9E=;
 b=RermtGnwyOAi5rVAEX2GPNEye5kYI75Cg+zpEUXtT3ASN3QmcFO8l+qr
 zSAAhwbhiOLvEe8ZLaLFFf8VUQJmPNPfQMVqCIAK9tP0N8T3gsFkOQEeH
 +wrz0+ZEgdNYkNyhZ0zWgRDvrmCjFALo0WE1utpr5dr4G94mVY9NgNZcF k=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: S0ZaVdOmSpMen520XGvGllSvFqBFrCHUWeyOMkZJOp0Wa+mh5B/uTdmmP9M7N0yxjapSvje53W
 bH6CDhha7KvQStjC6XMcXRyybAiRtxp3bU5IAUwL9bAi3zG+Jv5MmFG192HGaRBcYcXgAihZsx
 LFn5PoUN4DwdmSrYXjMVm5cqiRgETdieL9Fq6w/C1sellsT4n/CdcH31q+2fh1qJhZfzjmrrf5
 /guyyUFVowbksTRIN5M/rP7mKqVrkxD0fD3HTn7C43xVU20UjLXp+3ZBs0X/URuavRtTMlNEVM
 dNM=
X-SBRS: 2.7
X-MesageID: 15541691
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15541691"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH OSSTEST] linux: enable x2APIC kernel support
Date: Mon, 6 Apr 2020 10:16:36 +0200
Message-ID: <20200406081636.78027-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Without it Linux is not able to parse the x2APIC ACPI MADT entries
crafted by Xen when booted in PVH mode, following log is from one of
the dom0pvh jobs:

ACPI: x2apic entry ignored
ACPI: x2apic entry ignored
ACPI: x2apic entry ignored
ACPI: x2apic entry ignored
IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
IOAPIC[1]: apic_id 1, version 17, address 0xfec20000, GSI 24-55
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
Using ACPI (MADT) for SMP configuration information
smpboot: Boot CPU (id 0) not listed by BIOS
smpboot: Allowing 1 CPUs, 0 hotplug CPUs

Note that PVH mode only creates x2APIC entries for simplicity, and
because x2APIC mode is always provided to PVH guests. Not adding
x2APIC support forces Linux to boot in UP mode, since x2APIC entries
contain the information of additional processors available on the
system.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 ts-kernel-build | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-kernel-build b/ts-kernel-build
index 89cdafcb..6c8f1d6a 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -622,6 +622,9 @@ esac
 # Disable components that don't build
 setopt CONFIG_TEGRA_HOST1X n
 
+# Enable x2APIC support for PVH mode
+setopt CONFIG_X86_X2APIC y
+
 exit 0
 END
 }
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 08:27:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 08:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLN60-00031V-Nx; Mon, 06 Apr 2020 08:27:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=etk8=5W=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLN60-00031Q-4o
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 08:27:04 +0000
X-Inumbo-ID: 646e82de-77e0-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 646e82de-77e0-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 08:27:03 +0000 (UTC)
Received: by mail-ed1-x541.google.com with SMTP id a43so18172980edf.6
 for <xen-devel@lists.xenproject.org>; Mon, 06 Apr 2020 01:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=AmBPbhV6g2IaLOFOkpSmZFKlFd1m/HMJ+BA2WDmUJIU=;
 b=lTZ4RrDEQ2e0sj/upAp4GgAOsH5JOj4MUaMfKU3Ou4LheVKzHOC6GOErLoTVROgoYm
 yCBULJxRqJJplz4j0JD267G7DbqY8+4fIZ/RtQv6H4QLf10Z6ae8Q7hPMqF7+bTdB+mu
 eDpv0doFswVf6wRKTmpfuMG7AhJbMqdQ+D1pzXAcAin4I8XP9mcaUBHVgqh9wB0nkFCX
 zzzPWwgm9xTUnNY8dSZ54ickVKb+HRAGloPuJZnEZjgAP4rBII58lndi5GoQCghJ4dB5
 f3YJUydhhRq1nDe4AR0uLuCbZV2En7bOYPiZ54qEbwtrtkZm7GeD98jCtb4K9IqO7gK7
 gWjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=AmBPbhV6g2IaLOFOkpSmZFKlFd1m/HMJ+BA2WDmUJIU=;
 b=Dwpn93e6Czg5iJokBEkKQJOb39QEjaGXsG4jyWSwwK0sgIFZt5oQdbp6M1iifY7Nkb
 PykUdVmssi8PmboSGZJL1B/YAS1B3dIrCPoQo17H8n2G123H9XIoqS2UmsXFCjb1txzI
 1N13EwW34Iy54cJH5LmDK9QvgLUwa+E662jfa4kqADdvuv3Igess28xEQ+i4McEjFR2E
 qrx4Ir3+7TAzDp7Mo1l1cyf9bzgKO2RvMlsg0riQJeNX39PecP9CLjWWrI28xBz5NeDT
 zU7ikQAHFN13THrd6cS+x6oZFtuKHWyUn7ePLzpkrk87sHL9VmILMNIQD38dbqhDfPRV
 jzXQ==
X-Gm-Message-State: AGi0Pua4MDrc+HnQBLU8u7iH9J7cq7fEwNbe2TdtOpCcmZvrR18e9xJe
 TQsbzewHvos4AZSRpImdzYI=
X-Google-Smtp-Source: APiQypLguW7BSWBLjVfkgWMNjzRjxwD9bbYIpW5CSxqaTLRUWdMuWOITt5p37kuc8zt5X+Ib2B7zBg==
X-Received: by 2002:a17:906:4d4d:: with SMTP id
 b13mr1352105ejv.6.1586161622483; 
 Mon, 06 Apr 2020 01:27:02 -0700 (PDT)
Received: from CBGR90WXYV0 (54-240-197-238.amazon.com. [54.240.197.238])
 by smtp.gmail.com with ESMTPSA id p17sm2776308ejn.5.2020.04.06.01.27.01
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 06 Apr 2020 01:27:01 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
 <002201d609d0$55a76690$00f633b0$@xen.org>
 <acd5fee0-2bf6-4573-8467-38d24827ca1f@xen.org>
In-Reply-To: <acd5fee0-2bf6-4573-8467-38d24827ca1f@xen.org>
Subject: RE: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
Date: Mon, 6 Apr 2020 09:27:00 +0100
Message-ID: <001701d60bed$25606f80$70214e80$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQG3I8TZM/MLMEc/e2It3WEXPZVs8AC9qttvAt7KY/0Cn78SegKGUxSNqGN7zjA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 03 April 2020 18:24
> To: paul@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' =
<george.dunlap@citrix.com>; 'Ian
> Jackson' <ian.jackson@eu.citrix.com>; 'Jan Beulich' =
<jbeulich@suse.com>; 'Stefano Stabellini'
> <sstabellini@kernel.org>; 'Wei Liu' <wl@xen.org>
> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for =
save/restore of 'domain' context
>=20
> Hi Paul,
>=20
> On 03/04/2020 16:55, Paul Durrant wrote:
> >> -----Original Message-----
> > [snip]
> >>> +
> >>> +#include <xen/save.h>
> >>> +
> >>> +struct domain_context {
> >>> +    bool log;
> >>> +    struct domain_save_descriptor desc;
> >>> +    domain_copy_entry copy;
> >>
> >> As your new framework is technically an extension of existing one, =
it
> >> would be good to explain why we diverge in the definitions.
> >>
> >
> > I don't follow. What is diverging? I explain in the commit comment =
that this is a parallel
> framework. Do I need to justify why it is not a carbon copy of the HVM =
one?
>=20
> Well, they are both restoring/saving guest state. The only difference =
is
> the existing one is focusing on HVM state.
>=20
> So it would make sense long term to have only one hypercall and tell
> what you want to save. In fact, some of the improvement here would
> definitely make the HVM one nicer to use (at least in the context of =
LU).
>=20

I guess we could move the HVM save records over to the new framework, =
but it works for the moment so I don't want to bring it into scope now.

>  From the commit message, it is not clear to me why a new framework =
and
> why the infrastructure is at the same time different but not.
>=20

An alternative would be to move the HVM save code into common code and =
then try to adapt it. I think that would result in more code churn and =
ultimately be harder to review. The extra infrastructure introduced here =
is fairly minimal and, for the moment, only targeting PV state. As I =
said above there's nothing stopping the HVM records being ported over =
later once any initial issues have been shaken out.

  Paul





From xen-devel-bounces@lists.xenproject.org Mon Apr 06 08:27:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 08:27:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLN67-00032L-22; Mon, 06 Apr 2020 08:27:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=leFb=5W=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jLN66-000325-9g
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 08:27:10 +0000
X-Inumbo-ID: 672752a8-77e0-11ea-bfd7-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 672752a8-77e0-11ea-bfd7-12813bfff9fa;
 Mon, 06 Apr 2020 08:27:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9DFAFAB8F;
 Mon,  6 Apr 2020 08:27:06 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2] tools/libxl: make default of max event channels dependant
 on vcpus
Date: Mon,  6 Apr 2020 10:27:04 +0200
Message-Id: <20200406082704.13994-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Since Xen 4.4 the maximum number of event channels for a guest is
defaulting to 1023. For large guests with lots of vcpus this is not
enough, as e.g. the Linux kernel uses 7 event channels per vcpu,
limiting the guest to about 140 vcpus.

Instead of requiring to specify the allowed number of event channels
via the "event_channels" domain config option, make the default
depend on the maximum number of vcpus of the guest. This will require
to use the "event_channels" domain config option in fewer cases as
before.

As different guests will have differing needs the calculation of the
maximum number of event channels can be a rough estimate only,
currently based on the Linux kernel requirements. Nevertheless it is
much better than the static upper limit of today as more guests will
boot just fine with the new approach.

In order not to regress current configs use 1023 as the minimum
default setting.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2:
- use max() instead of min()
- clarify commit message a little bit
---
 tools/libxl/libxl_create.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e7cb2dbc2b..c025b21894 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -226,7 +226,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
             b_info->iomem[i].gfn = b_info->iomem[i].start;
 
     if (!b_info->event_channels)
-        b_info->event_channels = 1023;
+        b_info->event_channels = max(1023, b_info->max_vcpus * 8 + 255);
 
     libxl__arch_domain_build_info_setdefault(gc, b_info);
     libxl_defbool_setdefault(&b_info->dm_restrict, false);
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 08:27:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 08:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLN6f-00039A-CG; Mon, 06 Apr 2020 08:27:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=/g5+=5W=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jLN6e-00038v-EC
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 08:27:44 +0000
X-Inumbo-ID: 7bfe6752-77e0-11ea-bfd7-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7bfe6752-77e0-11ea-bfd7-12813bfff9fa;
 Mon, 06 Apr 2020 08:27:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=uS79rdr2gTc56AOSoA+CLXOyDTk2U5AqZbWu/xQvh8c=; b=O4CfVD7XRNpMLEozF9my9xjmQB
 VBw8WnWjq2OhNuhqbVShM/2dGmZaLNhjMKCmha/bw2q/OGhkCAXGN+xCjl87ynTQy+ZgaNExT06Nk
 j6TJdJRtnm2TUpGDvY4kE9i6bB6EG3FAJvg4GNBCbWmNo1wZ9NPjl2SOdyL70kGhWjOo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jLN6b-0004TV-S3; Mon, 06 Apr 2020 08:27:41 +0000
Received: from 54-240-197-232.amazon.com ([54.240.197.232]
 helo=freeip.amazon.com) by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jLN6b-0003tR-Ht; Mon, 06 Apr 2020 08:27:41 +0000
Message-ID: <636251f68db5e094f0c4dd5871eb4146dadb1589.camel@xen.org>
Subject: Re: [Xen-devel] [PATCH 0/5] use new API for Xen page tables
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Date: Mon, 06 Apr 2020 09:27:39 +0100
In-Reply-To: <cover.1584955616.git.hongyxia@amazon.com>
References: <cover.1584955616.git.hongyxia@amazon.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Wei Liu <wl@xen.org>,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Ping.

On Mon, 2020-03-23 at 09:41 +0000, Hongyan Xia wrote:
> From: Hongyan Xia <hongyxia@amazon.com>
> 
> This small series is basically just rewriting functions using the new
> API to map and unmap PTEs. Each patch is independent.
> 
> Apart from mapping and unmapping page tables, no other functional
> change
> intended.
> 
> Wei Liu (5):
>   x86/shim: map and unmap page tables in replace_va_mapping
>   x86_64/mm: map and unmap page tables in m2p_mapped
>   x86_64/mm: map and unmap page tables in share_hotadd_m2p_table
>   x86_64/mm: map and unmap page tables in destroy_compat_m2p_mapping
>   x86_64/mm: map and unmap page tables in destroy_m2p_mapping
> 
>  xen/arch/x86/pv/shim.c     | 10 ++++---
>  xen/arch/x86/x86_64/mm.c   | 55 +++++++++++++++++++++++++-----------
> --
>  xen/include/asm-x86/page.h | 18 +++++++++++++
>  3 files changed, 62 insertions(+), 21 deletions(-)
> 



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 08:40:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 08:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLNJF-0004lj-JT; Mon, 06 Apr 2020 08:40:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=QfxX=5W=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jLNJD-0004ld-VS
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 08:40:43 +0000
X-Inumbo-ID: 4d029390-77e2-11ea-bfdb-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4d029390-77e2-11ea-bfdb-12813bfff9fa;
 Mon, 06 Apr 2020 08:40:43 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 92FE7AB8F;
 Mon,  6 Apr 2020 08:40:41 +0000 (UTC)
Message-ID: <53c972a1b3efddcefe458fc6ddbd0e973e3107a4.camel@suse.com>
Subject: Re: [PATCH v2 2/2] xen: credit2: fix credit reset happening too few
 times
From: Dario Faggioli <dfaggioli@suse.com>
To: George Dunlap <George.Dunlap@citrix.com>
Date: Mon, 06 Apr 2020 10:40:39 +0200
In-Reply-To: <5C3A27CD-E237-4490-8942-2F82D0C20DCC@citrix.com>
References: <158457508246.11355.6457403441669388939.stgit@Palanthas>
 <158457672023.11355.16720240521867328301.stgit@Palanthas>
 <5C3A27CD-E237-4490-8942-2F82D0C20DCC@citrix.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-6ZGUQcKLXzS2s+iTp0Cu"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Charles Arnold <carnold@suse.com>,
 Jan Beulich <jbeulich@suse.com>, Glen <glenbarney@gmail.com>,
 Tomas Mozes <hydrapolic@gmail.com>, Sarah Newman <srn@prgmr.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-6ZGUQcKLXzS2s+iTp0Cu
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2020-04-02 at 18:32 +0000, George Dunlap wrote:
> > On Mar 19, 2020, at 12:12 AM, Dario Faggioli <dfaggioli@suse.com>
> > wrote:
> >=20
> > There is a bug in commit 5e4b4199667b9 ("xen: credit2: only reset
> > credit on reset condition"). In fact, the aim of that commit was to
> > make sure that we do not perform too many credit reset operations
> > (which are not super cheap, and in an hot-path). But the check used
> > to determine whether a reset is necessary was the wrong one.
> >=20
> > In fact, knowing just that some vCPUs have been skipped, while
> > traversing the runqueue (in runq_candidate()), is not enough. We
> > need to check explicitly whether the first vCPU in the runqueue
> > has a negative amount of credit.
>=20
> Oh, so if the top of the runqueue has negative credit, but it=E2=80=99s n=
ot
> chosen, then the one we *do* run has even lower credit.  Still not
> quite sure how that leads to a situation where credit resets don=E2=80=99=
t
> happen for long periods of time.  But anyway...
>=20
Fact is, without this patch, we wouldn't call reset_credit() if we
"skipped" a vcpu/unit.

That means we skip all the times we did not pick the head of the
runqueue, even if the one we picked also have negative credits (as the
check for 'skipped_units =3D=3D 0' was the first condition of the '&&').

That's what was making us skip resets. :-)

> Acked-by: George Dunlap <george.dunlap@citrix.com>
>=20
Thanks and Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-6ZGUQcKLXzS2s+iTp0Cu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6K6wgACgkQFkJ4iaW4
c+73Vg/+KrLZmRstE268vLvy2M9bKUw3Pr9FGzRXAypRR/DddFHkwd7pIUg/ZyHf
vlduSMrieInj7KRbx5C5mS0al5TUe8jdAswbAmbrQPCViTDnmajJIN4/QO/ySMz7
gTUCpoO0hytAdPxZk/sra+vmJvaeIKusZstTjoj3QUekhxJ1Zll4ZlkL/fEyswv8
XGFql5Ek4FmGemnHVP4ltYitlV4UpvmCCiDgj3Ok72TkqZZCVTf/wfe4KSVP6YHu
AMRnvky31an6fC7tb/KOiOCCApaIGZQnxgxKyH9kC7RW+n93mMFbG2GYbKxtPnJm
uG4JdtzrjW+h+xjT8o1wypks/dEXygFE4qHAOElIRzYBbI1n0T0RdoDQyN4BN+oP
1iFqlzV3qHpjvr8OM9fPJsJTah6qY6TXZS/jNWO6a+Lev5LFiBwCmznDI/1CQ2bO
tJJ37p0FcEvpgpaF0tloIJKcp3DNntjiMlXZuncCuieh/gnzwRhBrCNrGU3+/vxJ
wN3Kdrnhtp921ujnomDw5lO64BEhFES7YJPAI/6wacSLXM1jjHT+XfKZw6LmzO8F
GIGPXevVH5vcHSctUo4d1D46g0qT8gfGDIm12K03dyhZR5V5vh861cgUwE0xqtxd
0+OrtDz2dV94U598qHZyf6PjgTqTc8C/2uRan8KcYoZMqm8+v48=
=9+8d
-----END PGP SIGNATURE-----

--=-6ZGUQcKLXzS2s+iTp0Cu--



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 08:52:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 08:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLNU4-0005p4-4T; Mon, 06 Apr 2020 08:51:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=glNc=5W=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLNU2-0005oy-Hc
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 08:51:54 +0000
X-Inumbo-ID: dd1afc3c-77e3-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id dd1afc3c-77e3-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 08:51:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Rs4q5BylTNraN+j0XjUsuGksYpP/Fnjb0R58wRrNrw0=; b=eFakgQtBq543a5kOsN4iBYKn8e
 A0xOmFHY9dmnJ0lBhDdwZdLuuU0A9cmc6FIT80V/Xc/a20+OM40cgSXCme5Uh0osKhhhv7QtfcWcq
 zLbd/m3ib22rQX/078g4UbDHFzbPX4Fwvbanrh+Bu5Mlh1eTLS0B7l4/KImsp6FPIgEg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLNTs-0004xN-Gs; Mon, 06 Apr 2020 08:51:44 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLNTs-0005Wf-9S; Mon, 06 Apr 2020 08:51:44 +0000
Subject: Re: [PATCH 5/7] xen: include xen/guest_access.h rather than
 asm/guest_access.h
To: paul@xen.org, xen-devel@lists.xenproject.org
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-6-julien@xen.org>
 <001201d60be6$ab976e20$02c64a60$@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <7fc71644-3f4d-bbac-f593-fab86bfb2ff9@xen.org>
Date: Mon, 6 Apr 2020 09:51:41 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <001201d60be6$ab976e20$02c64a60$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Kevin Tian' <kevin.tian@intel.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Jun Nakajima' <jun.nakajima@intel.com>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Julien Grall' <jgrall@amazon.com>, 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>,
 'Volodymyr Babchuk' <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?B?J1JvZ2VyIFBhdSBNb25uw6kn?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 06/04/2020 08:40, Paul Durrant wrote:
>> diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
>> index 9ee275d01f..5c3dfc47b6 100644
>> --- a/xen/include/asm-x86/guest_access.h
>> +++ b/xen/include/asm-x86/guest_access.h
>> @@ -54,22 +54,24 @@
>>
>>   /* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
>>   #define guest_handle_to_param(hnd, type) ({                  \
>> +    typeof((hnd).p) _x = (hnd).p;                            \
>> +    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
>>       /* type checking: make sure that the pointers inside     \
>>        * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
>>        * the same type, then return hnd */                     \
>> -    (void)((typeof(&(hnd).p)) 0 ==                           \
>> -        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
>> -    (hnd);                                                   \
>> +    (void)(&_x == &_y.p);                                    \
>> +    _y;                                                      \
>>   })
>>
>>   /* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
>> -#define guest_handle_from_param(hnd, type) ({                \
>> -    /* type checking: make sure that the pointers inside     \
>> -     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
>> -     * the same type, then return hnd */                     \
>> -    (void)((typeof(&(hnd).p)) 0 ==                           \
>> -        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
>> -    (hnd);                                                   \
>> +#define guest_handle_from_param(hnd, type) ({               \
>> +    typeof((hnd).p) _x = (hnd).p;                           \
>> +    XEN_GUEST_HANDLE(type) _y = { _x };                     \
>> +    /* type checking: make sure that the pointers inside    \
>> +     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
>> +     * the same type, then return hnd */                    \
>> +    (void)(&_x == &_y.p);                                   \
>> +    _y;                                                     \
>>   })
>>
> 
> The commit comment would have the reader believe that this patch is just some changes in header file inclusion. These last two hunks are something else so I would suggest they get split out into a separate patch.

These two chunks were meant to be squashed in patch #6, but I messed up 
the rebase. I will fix on the next version.

Sorry for that.

Cheers,

> 
>    Paul
> 
>>   #define guest_handle_for_field(hnd, type, fld)          \
>> diff --git a/xen/lib/x86/private.h b/xen/lib/x86/private.h
>> index b793181464..2d53bd3ced 100644
>> --- a/xen/lib/x86/private.h
>> +++ b/xen/lib/x86/private.h
>> @@ -4,12 +4,12 @@
>>   #ifdef __XEN__
>>
>>   #include <xen/bitops.h>
>> +#include <xen/guest_access.h>
>>   #include <xen/kernel.h>
>>   #include <xen/lib.h>
>>   #include <xen/nospec.h>
>>   #include <xen/types.h>
>>
>> -#include <asm/guest_access.h>
>>   #include <asm/msr-index.h>
>>
>>   #define copy_to_buffer_offset copy_to_guest_offset
>> --
>> 2.17.1
> 
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 09:03:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 09:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLNep-0006of-7k; Mon, 06 Apr 2020 09:03:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Lhp/=5W=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jLNeo-0006oa-4z
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 09:03:02 +0000
X-Inumbo-ID: 6a91bb4a-77e5-11ea-bfdb-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6a91bb4a-77e5-11ea-bfdb-12813bfff9fa;
 Mon, 06 Apr 2020 09:03:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586163781;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=7NHbB9BsfudNyev+nKE/1EJEWNA2WPr4keczYxzGBKc=;
 b=RbKVbDRAYuhvAYeNQMWxKjcAktSPJR+aq9K8XeflwCq1zlw2E+rKqgNq
 QfmiFOkJrZexDvEVCbWqOrPjFBjrFQMIzzLLlQ15N/Cd/TZjkii3+jcW1
 V1XC7VX63PBojEukve4rehiDl88jWJF/iJ3NnHZ5MB7Pm+vZiSFdZkIoF A=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: sfPgwiT0RDqtOpIx8BpsOCGBpAYrEzJ8byAffdFSgPLT9oxrM1pLGxV1YpTJCLmm+D5/KjNwTc
 4UshXQsueyUHBq1QxYi9jubJ5prBv2AV1sK3XdnCfpQ5nvwcoAgTHamzh1kzvb9Msqal7Yq7ju
 qkhW17FkqJq6jUNmkeLMrG3DrtG4VCWd4pl8ZCS6WZTcR9wCZPK+yuKDj30clW5wGNYiAOrJNF
 kaoORMq+5pf6CxfxkMZjiwGVrinU52Ub1BjdqlJR6wPq5FyizUbdSQa9w4AHuCK67Qe5lhHDdp
 LIU=
X-SBRS: 2.7
X-MesageID: 15445372
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15445372"
Date: Mon, 6 Apr 2020 11:02:50 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH] xen/blkfront: fix memory allocation flags in
 blkfront_setup_indirect()
Message-ID: <20200406090250.GX28601@Air-de-Roger>
References: <20200403090034.8753-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200403090034.8753-1-jgross@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Jens Axboe <axboe@kernel.dk>, Stefano Stabellini <sstabellini@kernel.org>,
 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
 stable@vger.kernel.org, linux-block@vger.kernel.org,
 xen-devel@lists.xenproject.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 03, 2020 at 11:00:34AM +0200, Juergen Gross wrote:
> Commit 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for
> large array allocation") didn't fix the issue it was meant to, as the
> flags for allocating the memory are GFP_NOIO, which will lead the
> memory allocation falling back to kmalloc().
> 
> So instead of GFP_NOIO use GFP_KERNEL and do all the memory allocation
> in blkfront_setup_indirect() in a memalloc_noio_{save,restore} section.
> 
> Fixes: 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for large array allocation")
> Cc: stable@vger.kernel.org
> Signed-off-by: Juergen Gross <jgross@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks!


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 09:08:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 09:08:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLNjd-0006zR-SB; Mon, 06 Apr 2020 09:08:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=etk8=5W=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLNjd-0006zM-49
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 09:08:01 +0000
X-Inumbo-ID: 1c97f390-77e6-11ea-9e09-bc764e2007e4
Received: from mail-ed1-x52e.google.com (unknown [2a00:1450:4864:20::52e])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1c97f390-77e6-11ea-9e09-bc764e2007e4;
 Mon, 06 Apr 2020 09:07:59 +0000 (UTC)
Received: by mail-ed1-x52e.google.com with SMTP id o1so18337610edv.1
 for <xen-devel@lists.xenproject.org>; Mon, 06 Apr 2020 02:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=IfL/XX9GkpiX/cPju57u0wHepVMIT6Ru2TzDa6jdcUE=;
 b=WY6VAeVsE0LmMnXdolNJMD8OTecWtVcQCmbVKADyzX7uzVzKPDePpvP4N6un2qqMIZ
 KxvSZbVC91KzbB5KpDCES8YiTx+NMvcFlf/nfMB+4jEnoK9p8+hytH5yTxSldfExcj0F
 PFVmCs3suEYzeoGNlZM5ysjLL9Q/igMR+Q+4/EXb6DBP3kEX+mJVxPbNhqoOQKWy1i7Y
 t2Ic+U2IW5apR2bSvoRzXSL80qoikIEJ5/SGaJ9ZK7MkkOckRXjrwDCRlz0PLa3CYL0j
 h/7zhVocK9b4wIj8kKtRIq+h9HGFf+mbijhRF6wWTXf77osXDhL6H4uh7EHwKxSSQN9j
 uOIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=IfL/XX9GkpiX/cPju57u0wHepVMIT6Ru2TzDa6jdcUE=;
 b=nGo/8CJ5Mn/O1ozsswau+gTodQ/7LRY29juMps3YLwwsjXH3q3pNrQU665WYu2S5HI
 q/Zey7sTosgVaq9GEOy4cXjBcSkE0SARlQ4HrT8WYlyoC7EkJ1tF5FjOPoTiEEiIGVNU
 +eHpMXd/7e0uyCBEiHAeMfwLLdkGbwAg4r37n4vgIcmwpuR70tBmDCjdM5XNA3Sd7pcZ
 akfb0tSgGegRqn70/I1uO3AoWE2LyX7xTPJP2tR3ObDANxQ9gpJMqyHVeebS8kyq33lm
 zMtu5izYYf89YxOE97bC9zGjoY9wef9B2ZZ/uLCcRQPVeA+uUNU8nsV01Cc2HNoJ6UIJ
 VfuQ==
X-Gm-Message-State: AGi0PuaVTOWArMh7/hGc0FzYOOKGKecwhl6LM3M4OFPB42l4XT98q1qh
 QJJFqXF0Tv/dRJKIbuk2VHg=
X-Google-Smtp-Source: APiQypLf0/qysZZEtWDSufajWJuXRlIkZ90c85i2/B2V6SVJeZxkBqPYQcPMRqvxuZ7hQ0eAj6ydiw==
X-Received: by 2002:a17:906:a94a:: with SMTP id
 hh10mr20076968ejb.338.1586164078870; 
 Mon, 06 Apr 2020 02:07:58 -0700 (PDT)
Received: from CBGR90WXYV0 (54-240-197-238.amazon.com. [54.240.197.238])
 by smtp.gmail.com with ESMTPSA id j6sm265275ejs.88.2020.04.06.02.07.57
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 06 Apr 2020 02:07:58 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-3-paul@xen.org>
 <fc193a54-5d25-ffff-2234-9c0079c605d8@xen.org>
In-Reply-To: <fc193a54-5d25-ffff-2234-9c0079c605d8@xen.org>
Subject: RE: [PATCH 2/5] xen/common/domctl: introduce
 XEN_DOMCTL_get/setdomaincontext
Date: Mon, 6 Apr 2020 10:07:57 +0100
Message-ID: <002501d60bf2$dda86480$98f92d80$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQG3I8TZM/MLMEc/e2It3WEXPZVs8AMpgZPTAkjvhuWofgieMA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>,
 'Daniel De Graaf' <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 01 April 2020 14:42
> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>; Ian Jackson <ian.jackson@eu.citrix.com>; Wei Liu
> <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap <george.dunlap@citrix.com>; Jan
> Beulich <jbeulich@suse.com>; Stefano Stabellini <sstabellini@kernel.org>
> Subject: Re: [PATCH 2/5] xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
> 
> Hi Paul,
> 
> On 27/03/2020 18:50, Paul Durrant wrote:
> > These domctls provide a mechanism to get and set domain context from
> > the toolstack.
> >
> > Signed-off-by: Paul Durrant <paul@xen.org>
> > ---
> > Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Wei Liu <wl@xen.org>
> > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: George Dunlap <george.dunlap@citrix.com>
> > Cc: Jan Beulich <jbeulich@suse.com>
> > Cc: Julien Grall <julien@xen.org>
> > Cc: Stefano Stabellini <sstabellini@kernel.org>
> > ---
> >   tools/flask/policy/modules/xen.if   |   4 +-
> >   tools/libxc/include/xenctrl.h       |  11 +++
> >   tools/libxc/xc_domain.c             |  52 +++++++++++++
> >   xen/common/domctl.c                 | 115 ++++++++++++++++++++++++++++
> >   xen/include/public/domctl.h         |  41 +++++++++-
> >   xen/xsm/flask/hooks.c               |   6 ++
> >   xen/xsm/flask/policy/access_vectors |   4 +
> >   7 files changed, 230 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
> > index 8eb2293a52..2bc9db4f64 100644
> > --- a/tools/flask/policy/modules/xen.if
> > +++ b/tools/flask/policy/modules/xen.if
> > @@ -53,7 +53,7 @@ define(`create_domain_common', `
> >   	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
> >   			set_vnumainfo get_vnumainfo cacheflush
> >   			psr_cmt_op psr_alloc soft_reset
> > -			resource_map get_cpu_policy };
> > +			resource_map get_cpu_policy setcontext };
> >   	allow $1 $2:security check_context;
> >   	allow $1 $2:shadow enable;
> >   	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
> > @@ -97,7 +97,7 @@ define(`migrate_domain_out', `
> >   	allow $1 $2:hvm { gethvmc getparam };
> >   	allow $1 $2:mmu { stat pageinfo map_read };
> >   	allow $1 $2:domain { getaddrsize getvcpucontext pause destroy };
> > -	allow $1 $2:domain2 gettsc;
> > +	allow $1 $2:domain2 { gettsc getcontext };
> >   	allow $1 $2:shadow { enable disable logdirty };
> >   ')
> >
> > diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> > index fc6e57a1a0..5c0d0d27a4 100644
> > --- a/tools/libxc/include/xenctrl.h
> > +++ b/tools/libxc/include/xenctrl.h
> > @@ -867,6 +867,17 @@ int xc_domain_hvm_setcontext(xc_interface *xch,
> >                                uint8_t *hvm_ctxt,
> >                                uint32_t size);
> >
> > +int xc_domain_getcontext(xc_interface *xch,
> > +                         uint32_t domid,
> > +                         uint32_t mask,
> > +                         uint8_t *ctxt_buf,
> 
> Why do you use uint8_t rather than void here?
> 
> > +                         uint32_t size);
> > +int xc_domain_setcontext(xc_interface *xch,
> > +                         uint32_t domid,
> > +                         uint32_t mask,
> > +                         uint8_t *ctxt_buf,
> > +                         uint32_t size);
> > +
> >   /**
> >    * This function will return guest IO ABI protocol
> >    *
> > diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> > index 71829c2bce..15bcf671fc 100644
> > --- a/tools/libxc/xc_domain.c
> > +++ b/tools/libxc/xc_domain.c
> > @@ -537,6 +537,58 @@ int xc_domain_hvm_setcontext(xc_interface *xch,
> >       return ret;
> >   }
> >
> > +int xc_domain_getcontext(xc_interface *xch,
> > +                         uint32_t domid,
> > +                         uint32_t mask,
> > +                         uint8_t *ctxt_buf,
> > +                         uint32_t size)
> > +{
> > +    int ret;
> > +    DECLARE_DOMCTL;
> > +    DECLARE_HYPERCALL_BOUNCE(ctxt_buf, size, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> > +
> > +    if ( xc_hypercall_bounce_pre(xch, ctxt_buf) )
> > +        return -1;
> > +
> > +    domctl.cmd = XEN_DOMCTL_getdomaincontext;
> > +    domctl.domain = domid;
> > +    domctl.u.domaincontext.mask = mask;
> > +    domctl.u.domaincontext.size = size;
> > +    set_xen_guest_handle(domctl.u.domaincontext.buffer, ctxt_buf);
> > +
> > +    ret = do_domctl(xch, &domctl);
> > +
> > +    xc_hypercall_bounce_post(xch, ctxt_buf);
> > +
> > +    return !ret ? domctl.u.domaincontext.size : -1;
> 
> Looking at the domctl interface, size would be a 32-bit unsigned value.
> However the return is a 32-bit signed value. This is a call for trouble
> if the size is too big.
> 
> > +}
> > +
> > +int xc_domain_setcontext(xc_interface *xch,
> > +                         uint32_t domid,
> > +                         uint32_t mask,
> > +                         uint8_t *ctxt_buf,
> 
> The context is not meant to be modified. So this should really be const.
> 

All of the above were basically inherited via cut'n'paste from the HVM save code. I'll re-work it.

> > +                         uint32_t size)
> > +{
> > +    int ret;
> > +    DECLARE_DOMCTL;
> > +    DECLARE_HYPERCALL_BOUNCE(ctxt_buf, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
> > +
> > +    if ( xc_hypercall_bounce_pre(xch, ctxt_buf) )
> > +        return -1;
> > +
> > +    domctl.cmd = XEN_DOMCTL_setdomaincontext;
> > +    domctl.domain = domid;
> > +    domctl.u.domaincontext.mask = mask;
> > +    domctl.u.domaincontext.size = size;
> > +    set_xen_guest_handle(domctl.u.domaincontext.buffer, ctxt_buf);
> > +
> > +    ret = do_domctl(xch, &domctl);
> > +
> > +    xc_hypercall_bounce_post(xch, ctxt_buf);
> > +
> > +    return ret;
> > +}
> > +
> >   int xc_vcpu_getcontext(xc_interface *xch,
> >                          uint32_t domid,
> >                          uint32_t vcpu,
> > diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> > index a69b3b59a8..9c39519b04 100644
> > --- a/xen/common/domctl.c
> > +++ b/xen/common/domctl.c
> > @@ -25,6 +25,7 @@
> >   #include <xen/hypercall.h>
> >   #include <xen/vm_event.h>
> >   #include <xen/monitor.h>
> > +#include <xen/save.h>
> >   #include <asm/current.h>
> >   #include <asm/irq.h>
> >   #include <asm/page.h>
> > @@ -358,6 +359,111 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
> >       return ERR_PTR(ret);
> >   }
> >
> > +struct domctl_context
> > +{
> > +    void *buffer;
> > +    size_t len;
> > +    size_t cur;
> > +};
> > +
> > +static int accumulate_size(void *priv, void *data, size_t len)
> > +{
> > +    struct domctl_context *c = priv;
> > +
> > +    c->len += len;
> 
> What does prevent overflow?
> 

Good point. That needs to be checked.

> > +
> > +    return 0;
> > +}
> > +
> > +static int save_data(void *priv, void *data, size_t len)
> > +{
> > +    struct domctl_context *c = priv;
> > +
> > +    if ( c->len - c->cur < len )
> > +        return -ENOSPC;
> > +
> > +    memcpy(c->buffer + c->cur, data, len);
> > +    c->cur += len;
> > +
> > +    return 0;
> > +}
> > +
> > +static int getdomaincontext(struct domain *d,
> > +                            struct xen_domctl_domaincontext *dc)
> > +{
> > +    struct domctl_context c = { };
> > +    int rc;
> > +
> > +    if ( d == current->domain )
> > +        return -EPERM;
> > +
> > +    if ( guest_handle_is_null(dc->buffer) ) /* query for buffer size */
> > +
> > +    {
> > +        if ( dc->size )
> > +            return -EINVAL;
> > +
> > +        /* dry run to acquire buffer size */
> > +        rc = domain_save(d, accumulate_size, &c, dc->mask, true);
> > +        if ( rc )
> > +            return rc;
> > +
> > +        dc->size = c.len;
> 
> len is a size_t (so 64-bit on 64-bit arch) value, but size is 32-bit. So
> we return an error if the stream is going to be bigger than 4G?
> 

I'd hope a 4G stream is unlikely but I'll expand size to 64 bits.

> > +        return 0;
> > +    }
> > +
> > +    c.len = dc->size;
> > +    c.buffer = xmalloc_bytes(c.len);
> > +    if ( !c.buffer )
> > +        return -ENOMEM;
> > +
> > +    rc = domain_save(d, save_data, &c, dc->mask, false);
> > +
> > +    dc->size = c.cur;
> > +    if ( !rc && copy_to_guest(dc->buffer, c.buffer, dc->size) )
> > +        rc = -EFAULT;
> > +
> > +    xfree(c.buffer);
> > +
> > +    return rc;
> > +}
> > +
> > +static int load_data(void *priv, void *data, size_t len)
> > +{
> > +    struct domctl_context *c = priv;
> > +
> > +    if ( c->len - c->cur < len )
> > +        return -ENODATA;
> > +
> > +    if ( data )
> > +        memcpy(data, c->buffer + c->cur, len);
> > +
> > +    c->cur += len;
> > +
> > +    return 0;
> > +}
> > +
> > +static int setdomaincontext(struct domain *d,
> > +                            const struct xen_domctl_domaincontext *dc)
> > +{
> > +    struct domctl_context c = { .len = dc->size };
> > +    int rc;
> > +
> > +    if ( d == current->domain )
> > +        return -EPERM;
> > +
> > +    c.buffer = xmalloc_bytes(c.len);
> > +    if ( !c.buffer )
> > +        return -ENOMEM;
> > +
> > +    rc = !copy_from_guest(c.buffer, dc->buffer, c.len) ?
> > +        domain_load(d, load_data, &c, dc->mask) : -EFAULT;
> > +
> > +    xfree(c.buffer);
> > +
> > +    return rc;
> > +}
> > +
> >   long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> >   {
> >       long ret = 0;
> > @@ -942,6 +1048,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> >               copyback = 1;
> >           break;
> >
> > +    case XEN_DOMCTL_getdomaincontext:
> > +        ret = getdomaincontext(d, &op->u.domaincontext);
> > +        copyback = !ret;
> > +        break;
> > +
> > +    case XEN_DOMCTL_setdomaincontext:
> > +        ret = setdomaincontext(d, &op->u.domaincontext);
> > +        break;
> > +
> >       default:
> >           ret = arch_do_domctl(op, d, u_domctl);
> >           break;
> > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> > index 1ad34c35eb..24ed6852cf 100644
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -38,7 +38,7 @@
> >   #include "hvm/save.h"
> >   #include "memory.h"
> >
> > -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000012
> > +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000013
> >
> >   /*
> >    * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> > @@ -1129,6 +1129,42 @@ struct xen_domctl_vuart_op {
> >                                    */
> >   };
> >
> > +/*
> > + * Get/Set domain PV context. The same struct xen_domctl_domaincontext
> > + * is used for both commands but with slightly different field semantics
> > + * as follows:
> > + *
> > + * XEN_DOMCTL_getdomaincontext
> > + * ---------------------------
> > + *
> > + * buffer (IN):   The buffer into which the context data should be
> > + *                copied, or NULL to query the buffer size that should
> > + *                be allocated.
> > + * size (IN/OUT): If 'buffer' is NULL then the value passed in must be
> > + *                zero, and the value passed out will be the size of the
> > + *                buffer to allocate.
> > + *                If 'buffer' is non-NULL then the value passed in must
> > + *                be the size of the buffer into which data may be copied.
> > + * mask (IN):     See comment on domain_save/load() in xen/save.h.
> > + *
> > + * XEN_DOMCTL_setdomaincontext
> > + * ---------------------------
> > + *
> > + * buffer (IN):   The buffer from which the context data should be
> > + *                copied.
> > + * size (IN):     The size of the buffer from which data may be copied.
> > + *                This data must include DOMAIN_SAVE_CODE_HEADER at the
> > + *                start and terminate with a DOMAIN_SAVE_CODE_END record.
> > + *                Any data beyond the DOMAIN_SAVE_CODE_END record will be
> > + *                ignored.
> > + * mask (IN):     See comment on domain_save/load() in xen/save.h.
> > + */
> > +struct xen_domctl_domaincontext {
> > +    uint32_t size;
> > +    uint32_t mask;
> > +    XEN_GUEST_HANDLE_64(uint8) buffer;
> 
> Should not it be a void handle?
>

Perhaps.
 
> Also, in the case of XEN_DOMCTL_setdomaincontext, the buffer is not
> meant to be modified by the hypervisor. So I would rather introduce two
> separate structure so we can enforce the const.
> 

Can handles be meaningfully const?

  Paul



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 09:08:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 09:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLNjz-00071K-4e; Mon, 06 Apr 2020 09:08:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=glNc=5W=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLNjx-00071C-WD
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 09:08:22 +0000
X-Inumbo-ID: 292a9400-77e6-11ea-bfdb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 292a9400-77e6-11ea-bfdb-12813bfff9fa;
 Mon, 06 Apr 2020 09:08:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=f/czkPuAxgbvkU7yHJ3kEfADYS05yG6g7KfewQSoHO4=; b=C853642AhlLU0dHqeerZLrAmQ7
 UfLi1gFyFjlVeY8ciPLTppEixyfHR9BVYHpNSDdXSfsKrl+LYMRgth0Uyt9wQW2j3r2Vg4Mv7FLxm
 TLOIIHkixNzmcHfeEreLgIWFvDyFLbOWvJvkO4N+oPyn8z27GMclyKoRLv5kV4xQdmOQ=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLNjt-0005Lt-PQ; Mon, 06 Apr 2020 09:08:17 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLNjt-0006bO-IQ; Mon, 06 Apr 2020 09:08:17 +0000
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: paul@xen.org, xen-devel@lists.xenproject.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
 <002201d609d0$55a76690$00f633b0$@xen.org>
 <acd5fee0-2bf6-4573-8467-38d24827ca1f@xen.org>
 <001701d60bed$25606f80$70214e80$@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <e2e25069-36e5-b965-8f66-59a460369e88@xen.org>
Date: Mon, 6 Apr 2020 10:08:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <001701d60bed$25606f80$70214e80$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 06/04/2020 09:27, Paul Durrant wrote:
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Sent: 03 April 2020 18:24
>> To: paul@xen.org; xen-devel@lists.xenproject.org
>> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' <george.dunlap@citrix.com>; 'Ian
>> Jackson' <ian.jackson@eu.citrix.com>; 'Jan Beulich' <jbeulich@suse.com>; 'Stefano Stabellini'
>> <sstabellini@kernel.org>; 'Wei Liu' <wl@xen.org>
>> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context
>>
>> Hi Paul,
>>
>> On 03/04/2020 16:55, Paul Durrant wrote:
>>>> -----Original Message-----
>>> [snip]
>>>>> +
>>>>> +#include <xen/save.h>
>>>>> +
>>>>> +struct domain_context {
>>>>> +    bool log;
>>>>> +    struct domain_save_descriptor desc;
>>>>> +    domain_copy_entry copy;
>>>>
>>>> As your new framework is technically an extension of existing one, it
>>>> would be good to explain why we diverge in the definitions.
>>>>
>>>
>>> I don't follow. What is diverging? I explain in the commit comment that this is a parallel
>> framework. Do I need to justify why it is not a carbon copy of the HVM one?
>>
>> Well, they are both restoring/saving guest state. The only difference is
>> the existing one is focusing on HVM state.
>>
>> So it would make sense long term to have only one hypercall and tell
>> what you want to save. In fact, some of the improvement here would
>> definitely make the HVM one nicer to use (at least in the context of LU).
>>
> 
> I guess we could move the HVM save records over to the new framework, but it works for the moment so I don't want to bring it into scope now.

And I agree, hence why I say "long term" :).

> 
>>   From the commit message, it is not clear to me why a new framework and
>> why the infrastructure is at the same time different but not.
>>
> 
> An alternative would be to move the HVM save code into common code and then try to adapt it. I think that would result in more code churn and ultimately be harder to review. The extra infrastructure introduced here is fairly minimal and, for the moment, only targeting PV state. As I said above there's nothing stopping the HVM records being ported over later once any initial issues have been shaken out.

Code churn is always going to necessary one day or another if we want to 
consolidate the two.

Having two frameworks is not without risks. There are a few unknown to 
be answered:
   * Is there any dependency between the two? If yes, what is the ordering?
   * The name of the hypercall does not say anything about "PV". So a 
contributor could think it would be fine to save/restore new HVM state 
in the new generic hypercall. Is it going to be an issue? If so, how do 
we prevent it?
   * Are we going to deprecate the existing framework?

I am not suggesting we should not go with two frameworks, but the 
reasons and implications are not clear to me. Hence, why I think the 
commit message should be expanded with some rationale.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 09:18:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 09:18:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLNtY-0007xQ-4B; Mon, 06 Apr 2020 09:18:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=etk8=5W=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLNtW-0007xL-Ln
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 09:18:14 +0000
X-Inumbo-ID: 8a491a8a-77e7-11ea-9e09-bc764e2007e4
Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8a491a8a-77e7-11ea-9e09-bc764e2007e4;
 Mon, 06 Apr 2020 09:18:13 +0000 (UTC)
Received: by mail-ed1-x542.google.com with SMTP id cw6so18295191edb.9
 for <xen-devel@lists.xenproject.org>; Mon, 06 Apr 2020 02:18:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=Tx7rBNCXnlpHQrdNaaPu8h1N1job7kKMdjUxxhmPvMI=;
 b=et5yYcI3kUwJcncifL5Zxkeul2/yVG1+EIVgHGQk45PdQlFUVR0Kre+N2m6EQ2aoov
 OGfUUsb3xW+e4vL3ThjXgnKS0Hk7ZPXsXn/xnqYX0w9cR9hTzbVqDNC+3UIc805lPgjt
 BM+nAj1OpKwMJzlcvpJESaISj9/S/x83RBHgF9Brk4ctGTnbfQBP/DETYqGqecY24iJ1
 69PO8gJW1g/+7+N2ixSa2oHOg34n7xiUnRWLxqJnYMVwZm5O2NjKUnLg6iEUvSmZMM5G
 mrMqrHxsCf/GQHq+Cft+xYE3boJlk6GzQqKqCPzRJiOPy0YE7tZQLX5VGuEHT6UInIPs
 4e8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=Tx7rBNCXnlpHQrdNaaPu8h1N1job7kKMdjUxxhmPvMI=;
 b=ZnMprCnaJoP+Q01L43d+nOodm1hC7aDKUwQxU5E8g4AdS+YboBjvA5oZs5Oci/bIKB
 P/yHhd5P1wLAfHOUJgqTVR+GWGZG64RvYhMBJEgAksaFqyKcijxwWwhjwtoz/JGrHRQn
 r+aCXyTjMX3jJvxt/dx21MNjFJ0YotgeJqch4CVLm+Pq+C1WALUU13dq95JQafzAoltS
 0crRpK1ggnvOyL/1y+358dgBSs0zrGd6D40eURZTLwScq+yQqFTm107SmLaZvaP4leZp
 G6tpKPwaAxnhWV7b1Zd6Nn/gLAkR8cPbADUBgfKRGj74XNEvVZARnRoUpDXSIkl7PV97
 ORgg==
X-Gm-Message-State: AGi0PuZIhiR1ls7xF1VvvgMHQ/V1W0n+1lGwNII8FMGe2MwiT4hufNVL
 d9MHz7eq5MXEPekqUQDao5Q=
X-Google-Smtp-Source: APiQypLt124LSi+NXS22VGoVs7pgQEBqkmeGCcXdMn0JcQ129IZpxIJ5PNBkyQ7UUGlsiuSQ2Gsipg==
X-Received: by 2002:aa7:d999:: with SMTP id u25mr18804209eds.210.1586164692515; 
 Mon, 06 Apr 2020 02:18:12 -0700 (PDT)
Received: from CBGR90WXYV0 (54-240-197-238.amazon.com. [54.240.197.238])
 by smtp.gmail.com with ESMTPSA id c5sm242346edt.40.2020.04.06.02.18.11
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 06 Apr 2020 02:18:11 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
 <002201d609d0$55a76690$00f633b0$@xen.org>
 <acd5fee0-2bf6-4573-8467-38d24827ca1f@xen.org>
 <001701d60bed$25606f80$70214e80$@xen.org>
 <e2e25069-36e5-b965-8f66-59a460369e88@xen.org>
In-Reply-To: <e2e25069-36e5-b965-8f66-59a460369e88@xen.org>
Subject: RE: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
Date: Mon, 6 Apr 2020 10:18:10 +0100
Message-ID: <002701d60bf4$4b640460$e22c0d20$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQG3I8TZM/MLMEc/e2It3WEXPZVs8AC9qttvAt7KY/0Cn78SegKGUxSNAT1JVvEC2KVtyahC20mg
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 06 April 2020 10:08
> To: paul@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' =
<george.dunlap@citrix.com>; 'Ian
> Jackson' <ian.jackson@eu.citrix.com>; 'Jan Beulich' =
<jbeulich@suse.com>; 'Stefano Stabellini'
> <sstabellini@kernel.org>; 'Wei Liu' <wl@xen.org>
> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for =
save/restore of 'domain' context
>=20
> Hi Paul,
>=20
> On 06/04/2020 09:27, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Julien Grall <julien@xen.org>
> >> Sent: 03 April 2020 18:24
> >> To: paul@xen.org; xen-devel@lists.xenproject.org
> >> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' =
<george.dunlap@citrix.com>; 'Ian
> >> Jackson' <ian.jackson@eu.citrix.com>; 'Jan Beulich' =
<jbeulich@suse.com>; 'Stefano Stabellini'
> >> <sstabellini@kernel.org>; 'Wei Liu' <wl@xen.org>
> >> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for =
save/restore of 'domain' context
> >>
> >> Hi Paul,
> >>
> >> On 03/04/2020 16:55, Paul Durrant wrote:
> >>>> -----Original Message-----
> >>> [snip]
> >>>>> +
> >>>>> +#include <xen/save.h>
> >>>>> +
> >>>>> +struct domain_context {
> >>>>> +    bool log;
> >>>>> +    struct domain_save_descriptor desc;
> >>>>> +    domain_copy_entry copy;
> >>>>
> >>>> As your new framework is technically an extension of existing =
one, it
> >>>> would be good to explain why we diverge in the definitions.
> >>>>
> >>>
> >>> I don't follow. What is diverging? I explain in the commit comment =
that this is a parallel
> >> framework. Do I need to justify why it is not a carbon copy of the =
HVM one?
> >>
> >> Well, they are both restoring/saving guest state. The only =
difference is
> >> the existing one is focusing on HVM state.
> >>
> >> So it would make sense long term to have only one hypercall and =
tell
> >> what you want to save. In fact, some of the improvement here would
> >> definitely make the HVM one nicer to use (at least in the context =
of LU).
> >>
> >
> > I guess we could move the HVM save records over to the new =
framework, but it works for the moment so
> I don't want to bring it into scope now.
>=20
> And I agree, hence why I say "long term" :).
>=20
> >
> >>   From the commit message, it is not clear to me why a new =
framework and
> >> why the infrastructure is at the same time different but not.
> >>
> >
> > An alternative would be to move the HVM save code into common code =
and then try to adapt it. I think
> that would result in more code churn and ultimately be harder to =
review. The extra infrastructure
> introduced here is fairly minimal and, for the moment, only targeting =
PV state. As I said above
> there's nothing stopping the HVM records being ported over later once =
any initial issues have been
> shaken out.
>=20
> Code churn is always going to necessary one day or another if we want =
to
> consolidate the two.
>=20
> Having two frameworks is not without risks. There are a few unknown to
> be answered:
>    * Is there any dependency between the two? If yes, what is the =
ordering?

There isn't any dependency at the moment so need I say anything? If an =
ordering dependency is introduced by a future patch then surely that =
would be time to call it out.

>    * The name of the hypercall does not say anything about "PV". So a
> contributor could think it would be fine to save/restore new HVM state
> in the new generic hypercall. Is it going to be an issue? If so, how =
do
> we prevent it?

The commit message says:

"Domain context is state held in the hypervisor that does not come under
the category of 'HVM state' but is instead 'PV state' that is common
between PV guests and enlightened HVM guests (i.e. those that have PV
drivers) such as event channel state, grant entry state, etc."

Do you think this should also appear in a comment? Do we really care? =
Nothing fundamentally prevents the mechanism being used for HVM state, =
but that may introduce an ordering dependency.

>    * Are we going to deprecate the existing framework?
>=20

There is no intention as yet.

> I am not suggesting we should not go with two frameworks, but the
> reasons and implications are not clear to me. Hence, why I think the
> commit message should be expanded with some rationale.
>=20

Ok, I can add a paragraph to try to explain a little more.

  Paul



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 09:24:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 09:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLNzZ-0000L4-U7; Mon, 06 Apr 2020 09:24:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=glNc=5W=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLNzY-0000Kr-K5
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 09:24:28 +0000
X-Inumbo-ID: 69c7627a-77e8-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 69c7627a-77e8-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 09:24:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=fvy6vfuH+8nE3SpAK4tUpE0tV15nZY/imx4NaGXvdSk=; b=yIyBtwkkiGAtkHtEJhVV9Sg4U9
 EgOqxfB5noBQIwR2Ug/u/Xz5TX08NuMIztUqg22al3exdsPPS7KiWN9eAkrWplbHj3D0yNjglqgOA
 EK/Svt/+AxpFirCF4sVwJIU8ZzUJjA6IMO5iOBUOKkdzLVnpXd+elkjPoyxT8I0wz9pM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLNzX-0005hu-7g; Mon, 06 Apr 2020 09:24:27 +0000
Received: from 54-240-197-231.amazon.com ([54.240.197.231]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLNzX-0007X1-0m; Mon, 06 Apr 2020 09:24:27 +0000
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
References: <20200406082704.13994-1-jgross@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
Date: Mon, 6 Apr 2020 10:24:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200406082704.13994-1-jgross@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jurgen,

On 06/04/2020 09:27, Juergen Gross wrote:
> Since Xen 4.4 the maximum number of event channels for a guest is
> defaulting to 1023. For large guests with lots of vcpus this is not
> enough, as e.g. the Linux kernel uses 7 event channels per vcpu,
> limiting the guest to about 140 vcpus.

Large guests on which arch? Which type of guests?

> Instead of requiring to specify the allowed number of event channels
> via the "event_channels" domain config option, make the default
> depend on the maximum number of vcpus of the guest. This will require
> to use the "event_channels" domain config option in fewer cases as
> before.
> 
> As different guests will have differing needs the calculation of the
> maximum number of event channels can be a rough estimate only,
> currently based on the Linux kernel requirements.

I am not overly happy to extend the default numbers of event channels 
for everyone based on Linux behavior on a given setup. Yes you have more 
guests that would be able to run, but at the expense of allowing a guest 
to use more xen memory.

For instance, I don't think this limit increase is necessary on Arm.

> Nevertheless it is
> much better than the static upper limit of today as more guests will
> boot just fine with the new approach.
> 
> In order not to regress current configs use 1023 as the minimum
> default setting.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> V2:
> - use max() instead of min()
> - clarify commit message a little bit
> ---
>   tools/libxl/libxl_create.c | 2 +-

The documentation should be updated.

>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e7cb2dbc2b..c025b21894 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -226,7 +226,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>               b_info->iomem[i].gfn = b_info->iomem[i].start;
>   
>       if (!b_info->event_channels)
> -        b_info->event_channels = 1023;
> +        b_info->event_channels = max(1023, b_info->max_vcpus * 8 + 255);

What is the 255 for?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 09:51:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 09:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLOP3-0002nq-CP; Mon, 06 Apr 2020 09:50:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=glNc=5W=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLOP2-0002nl-QF
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 09:50:48 +0000
X-Inumbo-ID: 16ac21d0-77ec-11ea-bfdb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 16ac21d0-77ec-11ea-bfdb-12813bfff9fa;
 Mon, 06 Apr 2020 09:50:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=0W92GQ2KYsJSiOqtNt+eIN9zwerXYnj/05lFW5sQ33w=; b=zJweDKdPZIbIWPejE4PqQZHMGc
 UR//5z6uNReRTONq/jpiIt6HETG2X6eMgma8M6uex5z2wFIAjTIVPPTq0IFRxvVSx//RCSG+NyLzm
 YFxEB+gDeQELsCTpaBJ6qLtl0crEHkZTjPac/ebAj+EEY2UINN5BWZZXn8hCj00fFEgA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLOOw-0006FR-Rk; Mon, 06 Apr 2020 09:50:42 +0000
Received: from 54-240-197-231.amazon.com ([54.240.197.231]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLOOw-0000aC-GJ; Mon, 06 Apr 2020 09:50:42 +0000
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: paul@xen.org, xen-devel@lists.xenproject.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
 <002201d609d0$55a76690$00f633b0$@xen.org>
 <acd5fee0-2bf6-4573-8467-38d24827ca1f@xen.org>
 <001701d60bed$25606f80$70214e80$@xen.org>
 <e2e25069-36e5-b965-8f66-59a460369e88@xen.org>
 <002701d60bf4$4b640460$e22c0d20$@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <ac273b12-36f4-ca5c-c18b-7a59d2b84e2e@xen.org>
Date: Mon, 6 Apr 2020 10:50:40 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <002701d60bf4$4b640460$e22c0d20$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 06/04/2020 10:18, Paul Durrant wrote:
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Sent: 06 April 2020 10:08
>> To: paul@xen.org; xen-devel@lists.xenproject.org
>> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' <george.dunlap@citrix.com>; 'Ian
>> Jackson' <ian.jackson@eu.citrix.com>; 'Jan Beulich' <jbeulich@suse.com>; 'Stefano Stabellini'
>> <sstabellini@kernel.org>; 'Wei Liu' <wl@xen.org>
>> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context
>>
>> Hi Paul,
>>
>> On 06/04/2020 09:27, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Julien Grall <julien@xen.org>
>>>> Sent: 03 April 2020 18:24
>>>> To: paul@xen.org; xen-devel@lists.xenproject.org
>>>> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' <george.dunlap@citrix.com>; 'Ian
>>>> Jackson' <ian.jackson@eu.citrix.com>; 'Jan Beulich' <jbeulich@suse.com>; 'Stefano Stabellini'
>>>> <sstabellini@kernel.org>; 'Wei Liu' <wl@xen.org>
>>>> Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context
>>>>
>>>> Hi Paul,
>>>>
>>>> On 03/04/2020 16:55, Paul Durrant wrote:
>>>>>> -----Original Message-----
>>>>> [snip]
>>>>>>> +
>>>>>>> +#include <xen/save.h>
>>>>>>> +
>>>>>>> +struct domain_context {
>>>>>>> +    bool log;
>>>>>>> +    struct domain_save_descriptor desc;
>>>>>>> +    domain_copy_entry copy;
>>>>>>
>>>>>> As your new framework is technically an extension of existing one, it
>>>>>> would be good to explain why we diverge in the definitions.
>>>>>>
>>>>>
>>>>> I don't follow. What is diverging? I explain in the commit comment that this is a parallel
>>>> framework. Do I need to justify why it is not a carbon copy of the HVM one?
>>>>
>>>> Well, they are both restoring/saving guest state. The only difference is
>>>> the existing one is focusing on HVM state.
>>>>
>>>> So it would make sense long term to have only one hypercall and tell
>>>> what you want to save. In fact, some of the improvement here would
>>>> definitely make the HVM one nicer to use (at least in the context of LU).
>>>>
>>>
>>> I guess we could move the HVM save records over to the new framework, but it works for the moment so
>> I don't want to bring it into scope now.
>>
>> And I agree, hence why I say "long term" :).
>>
>>>
>>>>    From the commit message, it is not clear to me why a new framework and
>>>> why the infrastructure is at the same time different but not.
>>>>
>>>
>>> An alternative would be to move the HVM save code into common code and then try to adapt it. I think
>> that would result in more code churn and ultimately be harder to review. The extra infrastructure
>> introduced here is fairly minimal and, for the moment, only targeting PV state. As I said above
>> there's nothing stopping the HVM records being ported over later once any initial issues have been
>> shaken out.
>>
>> Code churn is always going to necessary one day or another if we want to
>> consolidate the two.
>>
>> Having two frameworks is not without risks. There are a few unknown to
>> be answered:
>>     * Is there any dependency between the two? If yes, what is the ordering?
> 
> There isn't any dependency at the moment so need I say anything? If an ordering dependency is introduced by a future patch then surely that would be time to call it out.

If we don't spell out a dependency now, then the risk is we have to 
modify the toolstack at the same time as spelling out the dependency.

I am not sure whether this matters thought. This would only affect the 
save part as the restore part should be just reading records one by one.

> 
>>     * The name of the hypercall does not say anything about "PV". So a
>> contributor could think it would be fine to save/restore new HVM state
>> in the new generic hypercall. Is it going to be an issue? If so, how do
>> we prevent it?
> 
> The commit message says:
> 
> "Domain context is state held in the hypervisor that does not come under
> the category of 'HVM state' but is instead 'PV state' that is common
> between PV guests and enlightened HVM guests (i.e. those that have PV
> drivers) such as event channel state, grant entry state, etc."

This does not seem to cover all the cases. For instance, where would you 
save IOREQ servers information?

> 
> Do you think this should also appear in a comment? Do we really care? Nothing fundamentally prevents the mechanism being used for HVM state, but that may introduce an ordering dependency.

I don't particularly like the idea to let the contributor decide where 
"HVM context" or as part of the "Domain context".

This is  going to result to unwanted dependency and possibly 
bikeshedding on where they should be saved.

My preference would be to mark the existing framework as deprecated and 
force all the new states to be saved as part of the new "Domain Context".

> 
>>     * Are we going to deprecate the existing framework?
>>
> 
> There is no intention as yet.
> 
>> I am not suggesting we should not go with two frameworks, but the
>> reasons and implications are not clear to me. Hence, why I think the
>> commit message should be expanded with some rationale.
>>
> 
> Ok, I can add a paragraph to try to explain a little more.

That would be appreciated. Thank you!

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:17:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLOp8-0004ep-JC; Mon, 06 Apr 2020 10:17:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=leFb=5W=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jLOp7-0004ek-N7
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:17:45 +0000
X-Inumbo-ID: dabc0007-77ef-11ea-bfdc-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id dabc0007-77ef-11ea-bfdc-12813bfff9fa;
 Mon, 06 Apr 2020 10:17:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7AE66AC11;
 Mon,  6 Apr 2020 10:17:42 +0000 (UTC)
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus
To: Julien Grall <julien@xen.org>, xen-devel@lists.xenproject.org
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
Date: Mon, 6 Apr 2020 12:17:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.20 11:24, Julien Grall wrote:
> Hi Jurgen,
> 
> On 06/04/2020 09:27, Juergen Gross wrote:
>> Since Xen 4.4 the maximum number of event channels for a guest is
>> defaulting to 1023. For large guests with lots of vcpus this is not
>> enough, as e.g. the Linux kernel uses 7 event channels per vcpu,
>> limiting the guest to about 140 vcpus.
> 
> Large guests on which arch? Which type of guests?

I'm pretty sure this applies to x86 only. I'm not aware of event
channels being used on ARM for IPIs.

> 
>> Instead of requiring to specify the allowed number of event channels
>> via the "event_channels" domain config option, make the default
>> depend on the maximum number of vcpus of the guest. This will require
>> to use the "event_channels" domain config option in fewer cases as
>> before.
>>
>> As different guests will have differing needs the calculation of the
>> maximum number of event channels can be a rough estimate only,
>> currently based on the Linux kernel requirements.
> 
> I am not overly happy to extend the default numbers of event channels 
> for everyone based on Linux behavior on a given setup. Yes you have more 
> guests that would be able to run, but at the expense of allowing a guest 
> to use more xen memory.

The resulting number would be larger than today only for guests with
more than 96 vcpus. So I don't think the additional amount of memory
is really that problematic.

> 
> For instance, I don't think this limit increase is necessary on Arm.
> 
>> Nevertheless it is
>> much better than the static upper limit of today as more guests will
>> boot just fine with the new approach.
>>
>> In order not to regress current configs use 1023 as the minimum
>> default setting.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> V2:
>> - use max() instead of min()
>> - clarify commit message a little bit
>> ---
>>   tools/libxl/libxl_create.c | 2 +-
> 
> The documentation should be updated.

Oh, indeed.

> 
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index e7cb2dbc2b..c025b21894 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -226,7 +226,7 @@ int libxl__domain_build_info_setdefault(libxl__gc 
>> *gc,
>>               b_info->iomem[i].gfn = b_info->iomem[i].start;
>>       if (!b_info->event_channels)
>> -        b_info->event_channels = 1023;
>> +        b_info->event_channels = max(1023, b_info->max_vcpus * 8 + 255);
> 
> What is the 255 for?

Just some headroom for e.g. pv devices.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:34:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:34:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLP5Y-0006Ef-VA; Mon, 06 Apr 2020 10:34:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=etk8=5W=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLP5X-0006Dv-AL
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:34:43 +0000
X-Inumbo-ID: 399892c2-77f2-11ea-83d8-bc764e2007e4
Received: from mail-ed1-x52a.google.com (unknown [2a00:1450:4864:20::52a])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 399892c2-77f2-11ea-83d8-bc764e2007e4;
 Mon, 06 Apr 2020 10:34:42 +0000 (UTC)
Received: by mail-ed1-x52a.google.com with SMTP id i7so18627622edq.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Apr 2020 03:34:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=/tizzWJs5e6Ab/lVHKm8KWTHNiolqrfaHVSwx1YqY78=;
 b=PerD7SJHPtbxcXK8LDRB8CZlLnE+R5QKHmkFzmPkuTSQLt5UetVuMcY3hZ5baVeur7
 UxWvnkcXVIhDDTN5CKuMLzO2lvOk2NjULOUsQRXSdHF8+1Pc276CN8nTjWHxYg/U6XVe
 bEcCuH2SU6jXlSxrS4P3cX9WM2glS+gtEouebv6C94Lsf46hk89b35HliAIRGHJakwWc
 t3+z4GYeBtmsmMZwU11twmxL5dB6sjy8YjMmpoA10dn4/7VLBY4+FM1oo5IxEUqYq5Nv
 MR0UQ42upDFTx+vtU/oUwQ1xE4YM65XK/Lc3U9XcL5EgowGp8fqI/6Lm6UqPIRAs9Juy
 SXSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=/tizzWJs5e6Ab/lVHKm8KWTHNiolqrfaHVSwx1YqY78=;
 b=son75/4KdMKNSuSHxeCiJIDRbHTMHoCrZjmfK7f9sVzgY015pxvpCkSJ8CqHIT4Rgh
 aVA5LzLz1Bx2EFV6E+smZgAoPpKSuHwsiU5TjIuwHLejKvuVpOH1ADIbzmy5aIbj/oN2
 3vmY3iXLxq33LdIrSlCH4Se4p6EKHhMzuhcgJ5cATAYZodzv4yV9GrpUrqelqJGrBPNw
 fFHbuvz963VgGcAvaFTyOQ+uu6McgFS3hE1KWoF0eRQ/8bejGyI9qyv5c/aQ/o0wI/yo
 h9GhajQ2z2fdYcE11aEo/gKXwunYJ//lQ8ECmitn0VLEZFx7Azx38nnDCjgeRX8uB/yV
 jtpA==
X-Gm-Message-State: AGi0PubFemGvJR4Z81KqPrFVUvRpjM0P5KmJ4ID78X7BFyzLgzUbJpCJ
 516Qok3goHTpOg1EiewDjLQ=
X-Google-Smtp-Source: APiQypJRf3BpcrOFrGc7Q/vQcdvtByznoLWA09BWyLVbOChPFKT2tLytGFwGqQGkBsOur/3WSQDgxA==
X-Received: by 2002:a05:6402:17fb:: with SMTP id
 t27mr19253041edy.305.1586169281637; 
 Mon, 06 Apr 2020 03:34:41 -0700 (PDT)
Received: from CBGR90WXYV0 (54-240-197-238.amazon.com. [54.240.197.238])
 by smtp.gmail.com with ESMTPSA id b2sm2884607ejv.61.2020.04.06.03.34.40
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 06 Apr 2020 03:34:41 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
 <002201d609d0$55a76690$00f633b0$@xen.org>
 <acd5fee0-2bf6-4573-8467-38d24827ca1f@xen.org>
 <001701d60bed$25606f80$70214e80$@xen.org>
 <e2e25069-36e5-b965-8f66-59a460369e88@xen.org>
 <002701d60bf4$4b640460$e22c0d20$@xen.org>
 <ac273b12-36f4-ca5c-c18b-7a59d2b84e2e@xen.org>
In-Reply-To: <ac273b12-36f4-ca5c-c18b-7a59d2b84e2e@xen.org>
Subject: RE: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
Date: Mon, 6 Apr 2020 11:34:39 +0100
Message-ID: <002801d60bfe$fab5de70$f0219b50$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQG3I8TZM/MLMEc/e2It3WEXPZVs8AC9qttvAt7KY/0Cn78SegKGUxSNAT1JVvEC2KVtyQKYWtbpAi2RjHuoHMJVgA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
[snip]
> >>     * The name of the hypercall does not say anything about "PV". So a
> >> contributor could think it would be fine to save/restore new HVM state
> >> in the new generic hypercall. Is it going to be an issue? If so, how do
> >> we prevent it?
> >
> > The commit message says:
> >
> > "Domain context is state held in the hypervisor that does not come under
> > the category of 'HVM state' but is instead 'PV state' that is common
> > between PV guests and enlightened HVM guests (i.e. those that have PV
> > drivers) such as event channel state, grant entry state, etc."
> 
> This does not seem to cover all the cases. For instance, where would you
> save IOREQ servers information?
> 

Ok, I agree that is ambiguous. I'd still call it PV state but of course it does only relate to HVM guests.

> >
> > Do you think this should also appear in a comment? Do we really care? Nothing fundamentally prevents
> the mechanism being used for HVM state, but that may introduce an ordering dependency.
> 
> I don't particularly like the idea to let the contributor decide where
> "HVM context" or as part of the "Domain context".
> 
> This is  going to result to unwanted dependency and possibly
> bikeshedding on where they should be saved.
> 
> My preference would be to mark the existing framework as deprecated and
> force all the new states to be saved as part of the new "Domain Context".
> 

I'm ok with that. Any others have any opinion to the contrary?

> >
> >>     * Are we going to deprecate the existing framework?
> >>
> >
> > There is no intention as yet.
> >
> >> I am not suggesting we should not go with two frameworks, but the
> >> reasons and implications are not clear to me. Hence, why I think the
> >> commit message should be expanded with some rationale.
> >>
> >
> > Ok, I can add a paragraph to try to explain a little more.
> 
> That would be appreciated. Thank you!
> 

I'll mention the deprecation of the HVM context interface there too.

  Paul



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:37:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLP83-0006MF-DH; Mon, 06 Apr 2020 10:37:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=glNc=5W=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLP81-0006MA-Ha
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:37:17 +0000
X-Inumbo-ID: 950acc1b-77f2-11ea-bfdd-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 950acc1b-77f2-11ea-bfdd-12813bfff9fa;
 Mon, 06 Apr 2020 10:37:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=b/baU/L0piSeiuYqWPSUAgTbQcqIbDeLoRYBEkry69s=; b=qCWmgxARXJOuHGVDSP4wovB/9f
 4ogD9orKYRvY9iVkUwZGAj6IDjWndEnJTpJea9Y1hLsBfI0CEtW6XxMo36cLeZPV1MNqbMJKi8iCP
 XVdiEz+UY8KqMgHtG4xqwZDX71mqSLCM/pVHuvlBfmPr/tc20BWP7/bcUGtteDX/mfiQ=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLP7y-0007DZ-Qi; Mon, 06 Apr 2020 10:37:14 +0000
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLP7y-0003QW-K1; Mon, 06 Apr 2020 10:37:14 +0000
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 xen-devel@lists.xenproject.org
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <26161282-7bad-5888-16c9-634647e6fde8@xen.org>
Date: Mon, 6 Apr 2020 11:37:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Juergen,

On 06/04/2020 11:17, Jürgen Groß wrote:
> On 06.04.20 11:24, Julien Grall wrote:
>> Hi Jurgen,
>>
>> On 06/04/2020 09:27, Juergen Gross wrote:
>>> Since Xen 4.4 the maximum number of event channels for a guest is
>>> defaulting to 1023. For large guests with lots of vcpus this is not
>>> enough, as e.g. the Linux kernel uses 7 event channels per vcpu,
>>> limiting the guest to about 140 vcpus.
>>
>> Large guests on which arch? Which type of guests?
> 
> I'm pretty sure this applies to x86 only. I'm not aware of event
> channels being used on ARM for IPIs.

How about the guest types?

> 
>>
>>> Instead of requiring to specify the allowed number of event channels
>>> via the "event_channels" domain config option, make the default
>>> depend on the maximum number of vcpus of the guest. This will require
>>> to use the "event_channels" domain config option in fewer cases as
>>> before.
>>>
>>> As different guests will have differing needs the calculation of the
>>> maximum number of event channels can be a rough estimate only,
>>> currently based on the Linux kernel requirements.
>>
>> I am not overly happy to extend the default numbers of event channels 
>> for everyone based on Linux behavior on a given setup. Yes you have 
>> more guests that would be able to run, but at the expense of allowing 
>> a guest to use more xen memory.
> 
> The resulting number would be larger than today only for guests with
> more than 96 vcpus. So I don't think the additional amount of memory
> is really that problematic.
This is not a very forward looking argument. For Arm, we limit to 128 
vCPUs at the moment but it would be possible to support many more (I 
think our vGIC implementation support up to 4096 vCPUs).

So even if your change impacts a small subset, each architectures should 
be able to make the decision on the limit and not imposed by x86 Linux PV.

> 
>>
>> For instance, I don't think this limit increase is necessary on Arm.
>>
>>> Nevertheless it is
>>> much better than the static upper limit of today as more guests will
>>> boot just fine with the new approach.
>>>
>>> In order not to regress current configs use 1023 as the minimum
>>> default setting.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>> V2:
>>> - use max() instead of min()
>>> - clarify commit message a little bit
>>> ---
>>>   tools/libxl/libxl_create.c | 2 +-
>>
>> The documentation should be updated.
> 
> Oh, indeed.
> 
>>
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>>> index e7cb2dbc2b..c025b21894 100644
>>> --- a/tools/libxl/libxl_create.c
>>> +++ b/tools/libxl/libxl_create.c
>>> @@ -226,7 +226,7 @@ int libxl__domain_build_info_setdefault(libxl__gc 
>>> *gc,
>>>               b_info->iomem[i].gfn = b_info->iomem[i].start;
>>>       if (!b_info->event_channels)
>>> -        b_info->event_channels = 1023;
>>> +        b_info->event_channels = max(1023, b_info->max_vcpus * 8 + 
>>> 255);
>>
>> What is the 255 for?
> 
> Just some headroom for e.g. pv devices.

That should really be explained in the commit message and a comment.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:40:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:40:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPB7-00077m-1H; Mon, 06 Apr 2020 10:40:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=67tO=5W=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jLPB6-00077f-3S
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:40:28 +0000
X-Inumbo-ID: 06fefd64-77f3-11ea-bfdd-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 06fefd64-77f3-11ea-bfdd-12813bfff9fa;
 Mon, 06 Apr 2020 10:40:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586169627;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=tSOjzafDR2Zh/2lViSYHkC7V4IQH+KhVu82itd5Otig=;
 b=HF/oMN2QHt6nhcWUBIhw26/GnHzsF3kSsTZD3P9Bkwt+hoOEd1OcOofB
 J52kvOPkqXvjX4MMUhO4HyeqVRcOqAhlbQQXGTrZwk7EW7WFHVGjFTX3O
 TzgzlQ4S2bH16chVK6fssho4A0ch9nTHXm9WbhVavwY5sQ1Vh5RO3aquz g=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: qppJu21dNTtVjJxmXVRKFSiAibCrzziKxUDHe19vu6WE+A23f+tHmTGnwl3rIeqSf6gOvIJ4ZS
 oz4f17R5/2OqP9eOVO6NC2GXBN7DPc5RdRuDZ96ySqE7L6esNrRJP+QBs8oH8ULGbnPlMHWKpp
 cPClGtMzrj4isqZdsVsuzFMNmMZqsoHjyQPCD2WUna5mgXCRQWz7J7jC8LMLUGaDQv1iSsPoQ2
 VAD0Bf8bV3T+hh9azW1qOKxk8w/Ay+PkCRc3L5U1p6y81SOwYB72x/q7Lf7iOt3K6DCJWX2ka1
 jgE=
X-SBRS: 2.7
X-MesageID: 15236009
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15236009"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24203.1813.529481.963091@mariner.uk.xensource.com>
Date: Mon, 6 Apr 2020 11:40:21 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH OSSTEST] linux: enable x2APIC kernel support
In-Reply-To: <20200406081636.78027-1-roger.pau@citrix.com>
References: <20200406081636.78027-1-roger.pau@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("[PATCH OSSTEST] linux: enable x2APIC kernel support"):
> Without it Linux is not able to parse the x2APIC ACPI MADT entries
> crafted by Xen when booted in PVH mode, following log is from one of
> the dom0pvh jobs:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

And pushed to pretest.

Thanks,
Ian.


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:47:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPI0-0007L8-R0; Mon, 06 Apr 2020 10:47:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=leFb=5W=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jLPHz-0007Ky-Va
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:47:36 +0000
X-Inumbo-ID: 0576fa18-77f4-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0576fa18-77f4-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 10:47:34 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 885F8AB8B;
 Mon,  6 Apr 2020 10:47:32 +0000 (UTC)
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus
To: Julien Grall <julien@xen.org>, xen-devel@lists.xenproject.org
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
 <26161282-7bad-5888-16c9-634647e6fde8@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com>
Date: Mon, 6 Apr 2020 12:47:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <26161282-7bad-5888-16c9-634647e6fde8@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.20 12:37, Julien Grall wrote:
> Hi Juergen,
> 
> On 06/04/2020 11:17, Jürgen Groß wrote:
>> On 06.04.20 11:24, Julien Grall wrote:
>>> Hi Jurgen,
>>>
>>> On 06/04/2020 09:27, Juergen Gross wrote:
>>>> Since Xen 4.4 the maximum number of event channels for a guest is
>>>> defaulting to 1023. For large guests with lots of vcpus this is not
>>>> enough, as e.g. the Linux kernel uses 7 event channels per vcpu,
>>>> limiting the guest to about 140 vcpus.
>>>
>>> Large guests on which arch? Which type of guests?
>>
>> I'm pretty sure this applies to x86 only. I'm not aware of event
>> channels being used on ARM for IPIs.
> 
> How about the guest types?

PV and HVM with PV enhancements.

> 
>>
>>>
>>>> Instead of requiring to specify the allowed number of event channels
>>>> via the "event_channels" domain config option, make the default
>>>> depend on the maximum number of vcpus of the guest. This will require
>>>> to use the "event_channels" domain config option in fewer cases as
>>>> before.
>>>>
>>>> As different guests will have differing needs the calculation of the
>>>> maximum number of event channels can be a rough estimate only,
>>>> currently based on the Linux kernel requirements.
>>>
>>> I am not overly happy to extend the default numbers of event channels 
>>> for everyone based on Linux behavior on a given setup. Yes you have 
>>> more guests that would be able to run, but at the expense of allowing 
>>> a guest to use more xen memory.
>>
>> The resulting number would be larger than today only for guests with
>> more than 96 vcpus. So I don't think the additional amount of memory
>> is really that problematic.
> This is not a very forward looking argument. For Arm, we limit to 128 
> vCPUs at the moment but it would be possible to support many more (I 
> think our vGIC implementation support up to 4096 vCPUs).
> 
> So even if your change impacts a small subset, each architectures should 
> be able to make the decision on the limit and not imposed by x86 Linux PV.

Okay, what about moving the default setting of b_info->event_channels
into libxl__arch_domain_build_info_setdefault() then?

> 
>>
>>>
>>> For instance, I don't think this limit increase is necessary on Arm.
>>>
>>>> Nevertheless it is
>>>> much better than the static upper limit of today as more guests will
>>>> boot just fine with the new approach.
>>>>
>>>> In order not to regress current configs use 1023 as the minimum
>>>> default setting.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>> V2:
>>>> - use max() instead of min()
>>>> - clarify commit message a little bit
>>>> ---
>>>>   tools/libxl/libxl_create.c | 2 +-
>>>
>>> The documentation should be updated.
>>
>> Oh, indeed.
>>
>>>
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>>>> index e7cb2dbc2b..c025b21894 100644
>>>> --- a/tools/libxl/libxl_create.c
>>>> +++ b/tools/libxl/libxl_create.c
>>>> @@ -226,7 +226,7 @@ int 
>>>> libxl__domain_build_info_setdefault(libxl__gc *gc,
>>>>               b_info->iomem[i].gfn = b_info->iomem[i].start;
>>>>       if (!b_info->event_channels)
>>>> -        b_info->event_channels = 1023;
>>>> +        b_info->event_channels = max(1023, b_info->max_vcpus * 8 + 
>>>> 255);
>>>
>>> What is the 255 for?
>>
>> Just some headroom for e.g. pv devices.
> 
> That should really be explained in the commit message and a comment.

Okay.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:48:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPIS-0007NZ-3P; Mon, 06 Apr 2020 10:48:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=67tO=5W=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jLPIQ-0007NR-4Q
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:48:02 +0000
X-Inumbo-ID: 15c70958-77f4-11ea-b58d-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 15c70958-77f4-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 10:48:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586170081;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=+FxSjw+m9HFUsArNeL5T/ZDFIv0ZrDYMqf3vIQVGFBw=;
 b=iAPUvDn+/obqzUc2fXwnFm0nKVUiTbkiaoNbKA0T1T3VMZEFK7m6YfEF
 OnQH9NJrP4Aq1UuYbazAjzpQde82c391HMBEBL5q9X862qTsEr9OL3idw
 IW0uV7XJsldluwrn3lOrOxpPDxUHG+SleHSWT7se7C9nS0dmIPalJ83w+ I=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: myNmmaxtbnPF+Ruyhvh4lPC6S5Yrn1cFbnTB0F47izTu/3YWBOf8XRRKRrsgX0elzKLp5LbuYb
 mWS9xzjMUpmv4Hd8UtlRlZmCZgI+X4hpOomcvNI92mTyP+JcvUJasA9MelY0+1DGwsoE+Ptwxf
 WP/+M/cL2yCobWjwaBWtAMWHOHlOWQurKHoKOIcdCqu0355+8Y0IGNc0kkX4AuJ8SRKCPL6wsS
 UgKw2xdr0mJcEAR8wgVLq1OiPyoWr161LVgCgeDUsBnDfy0XgywT3u7q4Nh1kQhDRfRi4bPq1w
 SZU=
X-SBRS: 2.7
X-MesageID: 15630710
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15630710"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-ID: <24203.2251.628483.557280@mariner.uk.xensource.com>
Date: Mon, 6 Apr 2020 11:47:39 +0100
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus
In-Reply-To: <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

J�rgen Gro� writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
> On 06.04.20 11:24, Julien Grall wrote:
> > Large guests on which arch? Which type of guests?
> 
> I'm pretty sure this applies to x86 only. I'm not aware of event
> channels being used on ARM for IPIs.

Should this be arch-dependent then ?  It seems like the figure is just
a heuristic anyway, and ...

> The resulting number would be larger than today only for guests with
> more than 96 vcpus. So I don't think the additional amount of memory
> is really that problematic.

Julien, are there likely to be any ARM guests now which have anywhere
near that number of vcpus ?  If not do we know now what such guests
are likely to be like ?

If this is all hypothetical on ARM it would seem silly to make this
arch-specific for the benefit of ARM given that the ARM implementation
would be entirely guesswork.  Maybe we should postpone that
specialisation until we know better what the ARM function should be
like for these large numbers of vcpus.

If ARM folks want to have a different formula for the default then
that is of course fine but I wonder whether this might do ARMk more
harm than good in this case.

Ian.


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:52:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:52:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPMl-0008DY-LU; Mon, 06 Apr 2020 10:52:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Lhp/=5W=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jLPMj-0008DT-Vb
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:52:30 +0000
X-Inumbo-ID: b527096c-77f4-11ea-83d8-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b527096c-77f4-11ea-83d8-bc764e2007e4;
 Mon, 06 Apr 2020 10:52:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586170350;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=FKW0021sBVGsf/MWs/HqraFUmc5nZ05OA5hZTNbg8+8=;
 b=B1iAic32gQPXa+IDB6LncHvY7az1WlhvJYbDoPLiCKpbqbIe1NgANpzN
 q5WHm/1Ym0b/zgmRoVzsNy6qrZsmlqoeJC5e3MBISjL2EVIi/xgRBuJZx
 1yuTFq1fYaedbYt0kozlI92q4f4D86kTp3KIEh+/r9D9YB0HCInhBvyaX k=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: zXu7PZ9EShbzjs6BDBuYgs9wS9X68TxAa3isJObPyaGEsjox0lH6Z/d0HsTYc9y9zA87IoYOa2
 Nsz0A1X+AaLvU/kvb4ws1qfrHBzLTYhcYgGa9mE/vhJnaa6yLenuATizKn5Qb6C7Sw/Mu5yEUB
 ItZ5/K9H3pfOdfQ6PMIEgs34HTjw6T7FtN4NGWaigGei3Whb4BvJe5o+fHwWWy4KfbZMfLja0X
 iI+XSkbimswLBF8YSEYRlU7JQdxzcrk09DpFX9Vqn5iS/TtPbx3/LHNhJzOg7gCVgwZocHSZPC
 1vw=
X-SBRS: 2.7
X-MesageID: 15449735
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15449735"
Date: Mon, 6 Apr 2020 12:52:19 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Subject: Re: [PATCH v13 1/3] xen/mem_sharing: VM forking
Message-ID: <20200406105219.GY28601@Air-de-Roger>
References: <cover.1585579955.git.tamas.lengyel@intel.com>
 <f40757694decdfdbd5a264be4c277ba824261874.1585579955.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <f40757694decdfdbd5a264be4c277ba824261874.1585579955.git.tamas.lengyel@intel.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Tamas
 K Lengyel <tamas@tklengyel.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Mar 30, 2020 at 08:02:08AM -0700, Tamas K Lengyel wrote:
> VM forking is the process of creating a domain with an empty memory space and a
> parent domain specified from which to populate the memory when necessary. For
> the new domain to be functional the VM state is copied over as part of the fork
> operation (HVM params, hap allocation, etc).
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> +static int bring_up_vcpus(struct domain *cd, struct domain *d)
> +{
> +    unsigned int i;
> +    int ret = -EINVAL;
> +
> +    if ( d->max_vcpus != cd->max_vcpus ||
> +        (ret = cpupool_move_domain(cd, d->cpupool)) )
> +        return ret;
> +
> +    for ( i = 0; i < cd->max_vcpus; i++ )
> +    {
> +        if ( !d->vcpu[i] || cd->vcpu[i] )
> +            continue;
> +
> +        if ( !vcpu_create(cd, i) )
> +            return -EINVAL;
> +    }
> +
> +    domain_update_node_affinity(cd);
> +    return 0;
> +}
> +
> +static int copy_vcpu_settings(struct domain *cd, struct domain *d)

Nit: AFAICT *d can be constified.

> +{
> +    unsigned int i;
> +    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> +    int ret = -EINVAL;
> +
> +    for ( i = 0; i < cd->max_vcpus; i++ )
> +    {
> +        const struct vcpu *d_vcpu = d->vcpu[i];
> +        struct vcpu *cd_vcpu = cd->vcpu[i];
> +        struct vcpu_runstate_info runstate;
> +        mfn_t vcpu_info_mfn;
> +
> +        if ( !d_vcpu || !cd_vcpu )
> +            continue;
> +
> +        /* Copy & map in the vcpu_info page if the guest uses one */
> +        vcpu_info_mfn = d_vcpu->vcpu_info_mfn;
> +        if ( !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
> +        {
> +            mfn_t new_vcpu_info_mfn = cd_vcpu->vcpu_info_mfn;
> +
> +            /* Allocate & map the page for it if it hasn't been already */
> +            if ( mfn_eq(new_vcpu_info_mfn, INVALID_MFN) )
> +            {
> +                gfn_t gfn = mfn_to_gfn(d, vcpu_info_mfn);
> +                unsigned long gfn_l = gfn_x(gfn);
> +                struct page_info *page;
> +
> +                if ( !(page = alloc_domheap_page(cd, 0)) )
> +                    return -ENOMEM;
> +
> +                new_vcpu_info_mfn = page_to_mfn(page);
> +                set_gpfn_from_mfn(mfn_x(new_vcpu_info_mfn), gfn_l);
> +
> +                ret = p2m->set_entry(p2m, gfn, new_vcpu_info_mfn,
> +                                     PAGE_ORDER_4K, p2m_ram_rw,
> +                                     p2m->default_access, -1);
> +                if ( ret )
> +                    return ret;
> +
> +                ret = map_vcpu_info(cd_vcpu, gfn_l,
> +                                    PAGE_OFFSET(d_vcpu->vcpu_info));
> +                if ( ret )
> +                    return ret;
> +            }
> +
> +            copy_domain_page(new_vcpu_info_mfn, vcpu_info_mfn);
> +        }
> +
> +        /* Setup the vCPU runstate area */
> +        if ( !guest_handle_is_null(runstate_guest(d_vcpu)) )
> +        {
> +            runstate_guest(cd_vcpu) = runstate_guest(d_vcpu);
> +            vcpu_runstate_get(cd_vcpu, &runstate);
> +            __copy_to_guest(runstate_guest(cd_vcpu), &runstate, 1);

I just realized there's no need to copy the runstate area contents
here, since they will get copied anyway in schedule_tail before
resuming execution og cd_vcpu as long as runstate_guest is set.

Note that the vcpu_info needs to be copied since it contains event
channel info which is not unconditionally updated on context switch
IIRC.

> +        }
> +
> +        /*
> +         * TODO: to support VMs with PV interfaces copy additional
> +         * settings here, such as PV timers.
> +         */
> +    }
> +
> +    return 0;
> +}
> +
> +static int fork_hap_allocation(struct domain *cd, struct domain *d)
> +{
> +    int rc;
> +    bool preempted;
> +    unsigned long mb = hap_get_allocation(d);
> +
> +    if ( mb == hap_get_allocation(cd) )
> +        return 0;
> +
> +    paging_lock(cd);
> +    rc = hap_set_allocation(cd, mb << (20 - PAGE_SHIFT), &preempted);
> +    paging_unlock(cd);
> +
> +    return preempted ? -ERESTART : rc;
> +}
> +
> +static void copy_tsc(struct domain *cd, struct domain *d)
> +{
> +    uint32_t tsc_mode;
> +    uint32_t gtsc_khz;
> +    uint32_t incarnation;
> +    uint64_t elapsed_nsec;
> +
> +    tsc_get_info(d, &tsc_mode, &elapsed_nsec, &gtsc_khz, &incarnation);
> +    /* Don't bump incarnation on set */
> +    tsc_set_info(cd, tsc_mode, elapsed_nsec, gtsc_khz, incarnation - 1);
> +}
> +
> +static int copy_special_pages(struct domain *cd, struct domain *d)
> +{
> +    mfn_t new_mfn, old_mfn;
> +    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> +    static const unsigned int params[] =
> +    {
> +        HVM_PARAM_STORE_PFN,
> +        HVM_PARAM_IOREQ_PFN,
> +        HVM_PARAM_BUFIOREQ_PFN,
> +        HVM_PARAM_CONSOLE_PFN
> +    };
> +    unsigned int i;
> +    int rc;
> +
> +    for ( i = 0; i < ARRAY_SIZE(params); i++ )
> +    {
> +        p2m_type_t t;
> +        uint64_t value = 0;
> +        struct page_info *page;
> +
> +        if ( hvm_get_param(cd, params[i], &value) || !value )

Don't you need to use d here instead of cd? You want to check whether
the parent has this parameter set in order to copy it to the child I
think.

With that:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:52:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPMv-0008EM-UK; Mon, 06 Apr 2020 10:52:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=67tO=5W=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jLPMu-0008E2-P3
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:52:40 +0000
X-Inumbo-ID: bbccc63a-77f4-11ea-bfdd-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bbccc63a-77f4-11ea-bfdd-12813bfff9fa;
 Mon, 06 Apr 2020 10:52:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586170359;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=dOt/vdl1r5KXrsqdH0pv+VkO8BnaCTJNerPzdw66VMI=;
 b=OksiYLwrx3TU5C2h9CpLdGok4NXe4jsNYBV+C7ceIz6T9LDilV3n828G
 g237fpVVFmMmKUUXNXj7ayhkuLqAcvkBsZEQEGWzpOPoARxqJrAIXGXtX
 z6YX//Icb7GaLX69JRIbrw9RsnOOhyYEfY7mM1moNnu+tE3H6UMfKGnIC E=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 3aaEiyEbz4RPsvcA6IOyDBGLKcXCi3m9z/JuZ+ck+NkFXZ/DjlWw1/qJLXTQnA9ntL0ryu1MdJ
 y0qTxrs6km/IxODIEqOW1RO8f7RbG3tKSjnkqJKECo0JFxrvwTRKTddHPqpepQOCl1jpGM5RcO
 oSUnlgtpyTYXXrn8+8pLBuVPL+r1dkAs11dq1Lq5OPsESdI0EABv1TK+SdxYL0cbvmudmy/25d
 fRoYGomKb6sfD7yhzQfhaxeKbpLHjLqrHwrGfmZ4ROA9G0BI+qkgZc7Dcy9I27HC+56utCjs57
 PrA=
X-SBRS: 2.7
X-MesageID: 15547686
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15547686"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-ID: <24203.2546.728186.463143@mariner.uk.xensource.com>
Date: Mon, 6 Apr 2020 11:52:34 +0100
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus
In-Reply-To: <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com>
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
 <26161282-7bad-5888-16c9-634647e6fde8@xen.org>
 <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

J�rgen Gro� writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
> Okay, what about moving the default setting of b_info->event_channels
> into libxl__arch_domain_build_info_setdefault() then?

FTAOD, if this satisfies ARM maintainers then I am content with it,
even though I doubt the utility.

I guess you should make two patches 1. duplicate the existing formula
(no functional change) 2. change the x86 formula.

I would ack the first and be guided by x86 folks for the 2nd.

Ian.


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:55:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:55:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPPO-0008RD-Fq; Mon, 06 Apr 2020 10:55:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=glNc=5W=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLPPN-0008R8-Dl
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:55:13 +0000
X-Inumbo-ID: 1711cd42-77f5-11ea-bfe0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1711cd42-77f5-11ea-bfe0-12813bfff9fa;
 Mon, 06 Apr 2020 10:55:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ALOb53CJgR/xUQbjndxjgrmwWEL/vJ2c+U6npk60U74=; b=UI6HF78oMzORvpRVV4HJbyxkMX
 cuytyXMW1HnU6taPwA7LwIaXDj2ujqPqrRzl1e/kYTWeog1ZUhl6z6A5ntV+VZtloa3tiD91WF8pZ
 nFGTTTe3ZEfJ+s0i41DHHr6r+Fx7ntaMJcHlxJ3k/H4Z5HzRuqWIs4l8PDq57lLbpre8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLPPM-0007ZW-6r; Mon, 06 Apr 2020 10:55:12 +0000
Received: from 54-240-197-231.amazon.com ([54.240.197.231]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLPPM-0004SS-0X; Mon, 06 Apr 2020 10:55:12 +0000
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus
To: Ian Jackson <ian.jackson@citrix.com>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
 <24203.2251.628483.557280@mariner.uk.xensource.com>
From: Julien Grall <julien@xen.org>
Message-ID: <fd09220a-7470-4679-ce16-f4553579171b@xen.org>
Date: Mon, 6 Apr 2020 11:55:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <24203.2251.628483.557280@mariner.uk.xensource.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Ian,

On 06/04/2020 11:47, Ian Jackson wrote:
> Jürgen Groß writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
>> On 06.04.20 11:24, Julien Grall wrote:
>>> Large guests on which arch? Which type of guests?
>>
>> I'm pretty sure this applies to x86 only. I'm not aware of event
>> channels being used on ARM for IPIs.
> 
> Should this be arch-dependent then ?  It seems like the figure is just
> a heuristic anyway, and ...
> 
>> The resulting number would be larger than today only for guests with
>> more than 96 vcpus. So I don't think the additional amount of memory
>> is really that problematic.
> 
> Julien, are there likely to be any ARM guests now which have anywhere
> near that number of vcpus ?  If not do we know now what such guests
> are likely to be like ?

We are meant to support up to 128 vCPUs. But our implementation can 
support up to 4096 vCPUs on vGICv3.

> 
> If this is all hypothetical on ARM it would seem silly to make this
> arch-specific for the benefit of ARM given that the ARM implementation
> would be entirely guesswork.  Maybe we should postpone that
> specialisation until we know better what the ARM function should be
> like for these large numbers of vcpus.

There are no correlation between event channels and vCPUs. The number of 
event channels only depends on the number of frontend you have in your 
guest. So...

> If ARM folks want to have a different formula for the default then
> that is of course fine but I wonder whether this might do ARMk more
> harm than good in this case.

... 1023 event channels is going to be plenty enough for most of the use 
cases.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:57:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPRT-00008M-T0; Mon, 06 Apr 2020 10:57:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Lhp/=5W=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jLPRS-00008H-4j
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:57:22 +0000
X-Inumbo-ID: 638f6706-77f5-11ea-bfe0-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 638f6706-77f5-11ea-bfe0-12813bfff9fa;
 Mon, 06 Apr 2020 10:57:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586170642;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=XDRe6vJTxuvFJHLETgFyGVKLbvcSRm8LOY2Y/LB+8Dc=;
 b=Psx2+DqGZwCn7n2uPcZyRBPP7rs4D1OscB8DtyBdmmhfnq9cl/d6q3B0
 9pCN7k9cbnojiG5P99jaZhLLRnKHmm4Vsl+EPY8nwa1kT93xcJIRAZFLl
 hT+AxAgMzw0nWCgJSh/9xUs37lNQNohqXGaEERmr0qtxbIEwAHY/6l65B g=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: RzQnE3D2qTDpzsTNz5rDF8WYSgEars9fppLl2JkG23CqvMl1xt4L2G3K6+t+rJiBA7Nx9JOfdd
 DzJG/HK0BK4aKwyYBiInKVLBm9OWaAzJw6ueqKeg8w1Daq15o/2b7d/gRLE3QIhdDWJEY1HzUQ
 G7kvvrbTA3T2TFHkqaFqbSmcmeFdMH2CL38ItnuII5xrLPzNx1qfuSd3Lkhr798rcwlEFmmw+z
 8g4N6rgq6KF/z5n2MlI+UuIVps2LdGqjVtuATp/06v8/SM7y+KYEyoqtusd7WsT2hZAi5ZJv+I
 cjw=
X-SBRS: 2.7
X-MesageID: 15236532
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15236532"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v9 0/3] x86/guest: use assisted TLB flush in guest mode
Date: Mon, 6 Apr 2020 12:57:00 +0200
Message-ID: <20200406105703.79201-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George
 Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hello,

This is the remaining of the assisted TLB flush series. This last set of
patches enable the usage of the Xen assisted flush when running nested
on Xen.

Thanks, Roger.

Roger Pau Monne (3):
  x86/tlb: introduce a flush HVM ASIDs flag
  x86/tlb: allow disabling the TLB clock
  x86/tlb: use Xen L0 assisted TLB flush when available

 xen/arch/x86/flushtlb.c                | 25 +++++++++++++++++--------
 xen/arch/x86/guest/hypervisor.c        | 14 ++++++++++++++
 xen/arch/x86/guest/xen/xen.c           |  6 ++++++
 xen/arch/x86/mm/hap/hap.c              |  8 ++++----
 xen/arch/x86/mm/hap/nested_hap.c       |  2 +-
 xen/arch/x86/mm/hap/private.h          |  5 +++++
 xen/arch/x86/mm/p2m-pt.c               |  2 +-
 xen/arch/x86/mm/paging.c               |  3 ++-
 xen/arch/x86/mm/shadow/common.c        | 18 +++++++++---------
 xen/arch/x86/mm/shadow/hvm.c           |  2 +-
 xen/arch/x86/mm/shadow/multi.c         | 17 +++++++++--------
 xen/arch/x86/mm/shadow/private.h       |  6 ++++++
 xen/arch/x86/smp.c                     |  7 +++++++
 xen/include/asm-x86/flushtlb.h         | 23 ++++++++++++++++++++++-
 xen/include/asm-x86/guest/hypervisor.h | 17 +++++++++++++++++
 15 files changed, 121 insertions(+), 34 deletions(-)

-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:57:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:57:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPRX-00008z-5L; Mon, 06 Apr 2020 10:57:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Lhp/=5W=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jLPRV-00008g-E6
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:57:25 +0000
X-Inumbo-ID: 6518fa74-77f5-11ea-b4f4-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6518fa74-77f5-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 10:57:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586170644;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=9AoFeQ4Hx4qMcFij7oaHaCN2kCAeoDB4eddv9fPacXQ=;
 b=IFdtRjUaKwPWaYdEy7bFtXHjayJ7foI5VZfzh1xOKfl21Z3noAoGHhu4
 UWYNMf0TrOdCyJ8liyvELN//fYAmJAL2ZoLLNAGnUIXBc5hPYKeXONF2G
 nTbZ11q6Hsk6GzCaMeh+ggL/dXhQfdT9wzQayrk6t2/cTgFNmb8gXelGH E=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 5J1Vx7Hd6MlFZSlEgQyif/Os/WnMxWSisV+TGhIi3K4d7rU1k/1T1I/D7+KuvqS+npLvVfp5UC
 cUqvEyqs94U9nLZ8zaGa7kIi1ng7rQDn9dveB3JcdjT2GdX1RCRGlvhbnbimadSePH81WnylBV
 /HN8J+oETNzqUBE7s4qVXK7+3QXiEpcRv7OEuQCKSmmRS/QgcXvX4NVjPphw/Uiukn8XGbb6lk
 ++6BgL4XhAY+1w2cUvJnOM49rL9/JOZ/zIL/0xkqqC34XCg/KP2+uQvE0rFxAbaKWQ2FYlL7pO
 NCc=
X-SBRS: 2.7
X-MesageID: 15209158
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15209158"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Date: Mon, 6 Apr 2020 12:57:01 +0200
Message-ID: <20200406105703.79201-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200406105703.79201-1-roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George
 Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Introduce a specific flag to request a HVM guest linear TLB flush,
which is an ASID/VPID tickle that forces a guest linear to guest
physical TLB flush for all HVM guests.

This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't require linear
TLB flushes as Xen doesn't modify the guest page tables in that case
(ie: when using HAP). Note that shadow paging code already takes care
of issuing the necessary flushes when the shadow page tables are
modified.

In order to keep the previous behavior modify all shadow code TLB
flushes to also flush the guest linear to physical TLB if the guest is
HVM. I haven't looked at each specific shadow code TLB flush in order
to figure out whether it actually requires a guest TLB flush or not,
so there might be room for improvement in that regard.

Also perform ASID/VPID flushes when modifying the p2m tables as it's a
requirement for AMD hardware. Finally keep the flush in
switch_cr3_cr4, as it's not clear whether code could rely on
switch_cr3_cr4 also performing a guest linear TLB flush. A following
patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to
not be necessary.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v8:
 - Don't flush host TLB on HAP changes.
 - Introduce a helper for shadow changes that only flushes ASIDs/VPIDs
   when the guest is HVM.
 - Introduce a helper for HAP that only flushes ASIDs/VPIDs.

Changes since v7:
 - Do not perform an ASID flush in filtered_flush_tlb_mask: the
   requested flush is related to the page need_tlbflush field and not
   to p2m changes (applies to both callers).

Changes since v6:
 - Add ASID/VPID flushes when modifying the p2m.
 - Keep the ASID/VPID flush in switch_cr3_cr4.

Changes since v5:
 - Rename FLUSH_GUESTS_TLB to FLUSH_HVM_ASID_CORE.
 - Clarify commit message.
 - Define FLUSH_HVM_ASID_CORE to 0 when !CONFIG_HVM.
---
 xen/arch/x86/flushtlb.c          |  6 ++++--
 xen/arch/x86/mm/hap/hap.c        |  8 ++++----
 xen/arch/x86/mm/hap/nested_hap.c |  2 +-
 xen/arch/x86/mm/hap/private.h    |  5 +++++
 xen/arch/x86/mm/p2m-pt.c         |  2 +-
 xen/arch/x86/mm/paging.c         |  3 ++-
 xen/arch/x86/mm/shadow/common.c  | 18 +++++++++---------
 xen/arch/x86/mm/shadow/hvm.c     |  2 +-
 xen/arch/x86/mm/shadow/multi.c   | 17 +++++++++--------
 xen/arch/x86/mm/shadow/private.h |  6 ++++++
 xen/include/asm-x86/flushtlb.h   |  6 ++++++
 11 files changed, 48 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 03f92c23dc..c81e53c0ae 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -59,8 +59,6 @@ static u32 pre_flush(void)
         raise_softirq(NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ);
 
  skip_clocktick:
-    hvm_flush_guest_tlbs();
-
     return t2;
 }
 
@@ -118,6 +116,7 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
     local_irq_save(flags);
 
     t = pre_flush();
+    hvm_flush_guest_tlbs();
 
     old_cr4 = read_cr4();
     ASSERT(!(old_cr4 & X86_CR4_PCIDE) || !(old_cr4 & X86_CR4_PGE));
@@ -221,6 +220,9 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
             do_tlb_flush();
     }
 
+    if ( flags & FLUSH_HVM_ASID_CORE )
+        hvm_flush_guest_tlbs();
+
     if ( flags & FLUSH_CACHE )
     {
         const struct cpuinfo_x86 *c = &current_cpu_data;
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index a6d5e39b02..12856245be 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
             p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
                                   p2m_ram_rw, p2m_ram_logdirty);
 
-            flush_tlb_mask(d->dirty_cpumask);
+            hap_flush_tlb_mask(d->dirty_cpumask);
 
             memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
         }
@@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
          * to be read-only, or via hardware-assisted log-dirty.
          */
         p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
-        flush_tlb_mask(d->dirty_cpumask);
+        hap_flush_tlb_mask(d->dirty_cpumask);
     }
     return 0;
 }
@@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
      * be read-only, or via hardware-assisted log-dirty.
      */
     p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
-    flush_tlb_mask(d->dirty_cpumask);
+    hap_flush_tlb_mask(d->dirty_cpumask);
 }
 
 /************************************************/
@@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
 
     safe_write_pte(p, new);
     if ( old_flags & _PAGE_PRESENT )
-        flush_tlb_mask(d->dirty_cpumask);
+        hap_flush_tlb_mask(d->dirty_cpumask);
 
     paging_unlock(d);
 
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index abe5958a52..02a5ae75c0 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -84,7 +84,7 @@ nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
     safe_write_pte(p, new);
 
     if (old_flags & _PAGE_PRESENT)
-        flush_tlb_mask(p2m->dirty_cpumask);
+        hap_flush_tlb_mask(p2m->dirty_cpumask);
 
     paging_unlock(d);
 
diff --git a/xen/arch/x86/mm/hap/private.h b/xen/arch/x86/mm/hap/private.h
index 973fbe8be5..7ee8480d83 100644
--- a/xen/arch/x86/mm/hap/private.h
+++ b/xen/arch/x86/mm/hap/private.h
@@ -47,4 +47,9 @@ unsigned long hap_p2m_ga_to_gfn_4_levels(struct vcpu *v,
     struct p2m_domain *p2m, unsigned long cr3,
     paddr_t ga, uint32_t *pfec, unsigned int *page_order);
 
+static inline void hap_flush_tlb_mask(const cpumask_t *mask)
+{
+    flush_mask(mask, FLUSH_HVM_ASID_CORE);
+}
+
 #endif /* __HAP_PRIVATE_H__ */
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index eb66077496..c90032dc88 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -896,7 +896,7 @@ static void p2m_pt_change_entry_type_global(struct p2m_domain *p2m,
     unmap_domain_page(tab);
 
     if ( changed )
-         flush_tlb_mask(p2m->domain->dirty_cpumask);
+         flush_mask(p2m->domain->dirty_cpumask, FLUSH_HVM_ASID_CORE);
 }
 
 static int p2m_pt_change_entry_type_range(struct p2m_domain *p2m,
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index 469bb76429..d0bccaf7eb 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d,
 
     p2m_unlock(p2m);
 
-    flush_tlb_mask(d->dirty_cpumask);
+    flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) |
+                                 FLUSH_HVM_ASID_CORE);
 }
 
 /*
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 75dd414a6e..467e0d3fe1 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -363,7 +363,7 @@ static int oos_remove_write_access(struct vcpu *v, mfn_t gmfn,
     }
 
     if ( ftlb )
-        flush_tlb_mask(d->dirty_cpumask);
+        sh_flush_tlb_mask(d, d->dirty_cpumask);
 
     return 0;
 }
@@ -939,7 +939,7 @@ static void _shadow_prealloc(struct domain *d, unsigned int pages)
                 /* See if that freed up enough space */
                 if ( d->arch.paging.shadow.free_pages >= pages )
                 {
-                    flush_tlb_mask(d->dirty_cpumask);
+                    sh_flush_tlb_mask(d, d->dirty_cpumask);
                     return;
                 }
             }
@@ -993,7 +993,7 @@ static void shadow_blow_tables(struct domain *d)
                                pagetable_get_mfn(v->arch.shadow_table[i]), 0);
 
     /* Make sure everyone sees the unshadowings */
-    flush_tlb_mask(d->dirty_cpumask);
+    sh_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 void shadow_blow_tables_per_domain(struct domain *d)
@@ -1102,7 +1102,7 @@ mfn_t shadow_alloc(struct domain *d,
         if ( unlikely(!cpumask_empty(&mask)) )
         {
             perfc_incr(shadow_alloc_tlbflush);
-            flush_tlb_mask(&mask);
+            sh_flush_tlb_mask(d, &mask);
         }
         /* Now safe to clear the page for reuse */
         clear_domain_page(page_to_mfn(sp));
@@ -2293,7 +2293,7 @@ void sh_remove_shadows(struct domain *d, mfn_t gmfn, int fast, int all)
 
     /* Need to flush TLBs now, so that linear maps are safe next time we
      * take a fault. */
-    flush_tlb_mask(d->dirty_cpumask);
+    sh_flush_tlb_mask(d, d->dirty_cpumask);
 
     paging_unlock(d);
 }
@@ -3008,7 +3008,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d, unsigned long gfn,
         {
             sh_remove_all_shadows_and_parents(d, mfn);
             if ( sh_remove_all_mappings(d, mfn, _gfn(gfn)) )
-                flush_tlb_mask(d->dirty_cpumask);
+                sh_flush_tlb_mask(d, d->dirty_cpumask);
         }
     }
 
@@ -3048,7 +3048,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d, unsigned long gfn,
                 }
                 omfn = mfn_add(omfn, 1);
             }
-            flush_tlb_mask(&flushmask);
+            sh_flush_tlb_mask(d, &flushmask);
 
             if ( npte )
                 unmap_domain_page(npte);
@@ -3335,7 +3335,7 @@ int shadow_track_dirty_vram(struct domain *d,
         }
     }
     if ( flush_tlb )
-        flush_tlb_mask(d->dirty_cpumask);
+        sh_flush_tlb_mask(d, d->dirty_cpumask);
     goto out;
 
 out_sl1ma:
@@ -3405,7 +3405,7 @@ bool shadow_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
     }
 
     /* Flush TLBs on all CPUs with dirty vcpu state. */
-    flush_tlb_mask(mask);
+    sh_flush_tlb_mask(d, mask);
 
     /* Done. */
     for_each_vcpu ( d, v )
diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c
index 1e6024c71f..149f346a48 100644
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -591,7 +591,7 @@ static void validate_guest_pt_write(struct vcpu *v, mfn_t gmfn,
 
     if ( rc & SHADOW_SET_FLUSH )
         /* Need to flush TLBs to pick up shadow PT changes */
-        flush_tlb_mask(d->dirty_cpumask);
+        sh_flush_tlb_mask(d, d->dirty_cpumask);
 
     if ( rc & SHADOW_SET_ERROR )
     {
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index f6b1628742..17af28cdbd 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3067,7 +3067,7 @@ static int sh_page_fault(struct vcpu *v,
         perfc_incr(shadow_rm_write_flush_tlb);
         smp_wmb();
         atomic_inc(&d->arch.paging.shadow.gtable_dirty_version);
-        flush_tlb_mask(d->dirty_cpumask);
+        sh_flush_tlb_mask(d, d->dirty_cpumask);
     }
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
@@ -3576,7 +3576,8 @@ static bool sh_invlpg(struct vcpu *v, unsigned long linear)
     if ( mfn_to_page(sl1mfn)->u.sh.type
          == SH_type_fl1_shadow )
     {
-        flush_tlb_local();
+        flush_local(FLUSH_TLB |
+                    (is_hvm_domain(v->domain) ? FLUSH_HVM_ASID_CORE : 0));
         return false;
     }
 
@@ -3811,7 +3812,7 @@ sh_update_linear_entries(struct vcpu *v)
          * table entry. But, without this change, it would fetch the wrong
          * value due to a stale TLB.
          */
-        flush_tlb_local();
+        flush_local(FLUSH_TLB | (is_hvm_domain(d) ? FLUSH_HVM_ASID_CORE : 0));
     }
 }
 
@@ -4012,7 +4013,7 @@ sh_update_cr3(struct vcpu *v, int do_locking, bool noflush)
      * (old) shadow linear maps in the writeable mapping heuristics. */
 #if GUEST_PAGING_LEVELS == 2
     if ( sh_remove_write_access(d, gmfn, 2, 0) != 0 )
-        flush_tlb_mask(d->dirty_cpumask);
+        sh_flush_tlb_mask(d, d->dirty_cpumask);
     sh_set_toplevel_shadow(v, 0, gmfn, SH_type_l2_shadow);
 #elif GUEST_PAGING_LEVELS == 3
     /* PAE guests have four shadow_table entries, based on the
@@ -4036,7 +4037,7 @@ sh_update_cr3(struct vcpu *v, int do_locking, bool noflush)
             }
         }
         if ( flush )
-            flush_tlb_mask(d->dirty_cpumask);
+            sh_flush_tlb_mask(d, d->dirty_cpumask);
         /* Now install the new shadows. */
         for ( i = 0; i < 4; i++ )
         {
@@ -4057,7 +4058,7 @@ sh_update_cr3(struct vcpu *v, int do_locking, bool noflush)
     }
 #elif GUEST_PAGING_LEVELS == 4
     if ( sh_remove_write_access(d, gmfn, 4, 0) != 0 )
-        flush_tlb_mask(d->dirty_cpumask);
+        sh_flush_tlb_mask(d, d->dirty_cpumask);
     sh_set_toplevel_shadow(v, 0, gmfn, SH_type_l4_shadow);
     if ( !shadow_mode_external(d) && !is_pv_32bit_domain(d) )
     {
@@ -4503,7 +4504,7 @@ static void sh_pagetable_dying(paddr_t gpa)
         }
     }
     if ( flush )
-        flush_tlb_mask(d->dirty_cpumask);
+        sh_flush_tlb_mask(d, d->dirty_cpumask);
 
     /* Remember that we've seen the guest use this interface, so we
      * can rely on it using it in future, instead of guessing at
@@ -4540,7 +4541,7 @@ static void sh_pagetable_dying(paddr_t gpa)
         mfn_to_page(gmfn)->pagetable_dying = true;
         shadow_unhook_mappings(d, smfn, 1/* user pages only */);
         /* Now flush the TLB: we removed toplevel mappings. */
-        flush_tlb_mask(d->dirty_cpumask);
+        sh_flush_tlb_mask(d, d->dirty_cpumask);
     }
 
     /* Remember that we've seen the guest use this interface, so we
diff --git a/xen/arch/x86/mm/shadow/private.h b/xen/arch/x86/mm/shadow/private.h
index e8b028a365..2404ca4ff8 100644
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -818,6 +818,12 @@ static inline int sh_check_page_has_no_refs(struct page_info *page)
 bool shadow_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
                       void *ctxt);
 
+static inline void sh_flush_tlb_mask(const struct domain *d,
+                                     const cpumask_t *mask)
+{
+    flush_mask(mask, FLUSH_TLB | (is_hvm_domain(d) ? FLUSH_HVM_ASID_CORE : 0));
+}
+
 #endif /* _XEN_SHADOW_PRIVATE_H */
 
 /*
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 2cfe4e6e97..579dc56803 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -105,6 +105,12 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4);
 #define FLUSH_VCPU_STATE 0x1000
  /* Flush the per-cpu root page table */
 #define FLUSH_ROOT_PGTBL 0x2000
+#if CONFIG_HVM
+ /* Flush all HVM guests linear TLB (using ASID/VPID) */
+#define FLUSH_HVM_ASID_CORE 0x4000
+#else
+#define FLUSH_HVM_ASID_CORE 0
+#endif
 
 /* Flush local TLBs/caches. */
 unsigned int flush_area_local(const void *va, unsigned int flags);
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:57:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPRY-00009r-Dd; Mon, 06 Apr 2020 10:57:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Lhp/=5W=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jLPRX-000091-8F
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:57:27 +0000
X-Inumbo-ID: 66ad2392-77f5-11ea-bfe0-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 66ad2392-77f5-11ea-bfe0-12813bfff9fa;
 Mon, 06 Apr 2020 10:57:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586170646;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=SLpvoVsWt67jFwvCZiFaJg06hvegnu8vLcBh7inaYr4=;
 b=O/tbEHWoAs/DqStOxa7VlUj0QSDR10FZyV/7Hd1FMw7QIUQ+HJL0Bo+2
 H7dO5QXTAxg0QMs03XZwMqAUUwyQeEAGEArFrn1k1DTT0eaYQAyYFJm66
 AsDWc5et9GH9llRk6gJjybMZM7SZZfCIucPw2S3LF2fLyVl0MptVv7cWN E=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: oBkXzs5NtNtc2WHWTKuxL+fQm+WmpKv4bybTLnkIgQkgWIWIEQZlgU1cFLBERc70XYMOKc1kGF
 fVYhawOkiF0W/tVNtLKNz5ew3IO/eZbLY1osZVfQZxew8yFP2o/1lG9C6Rh+iuQDRIBm4nVGAL
 hiwEWHOcA0Mi2VuRcxenY4uaw/UCRhbNvoONY+1XS7uDWw4gX9LXT6SMqfaxiNlAwfl5CrITme
 dHt5GMNfPOZoE6Z9SIy3YpmdPBrwwE/CwmwRqKg+ozOdnotSxxAumcxy6acK6PI58A64Sv/wuT
 2y4=
X-SBRS: 2.7
X-MesageID: 15547813
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15547813"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v9 2/3] x86/tlb: allow disabling the TLB clock
Date: Mon, 6 Apr 2020 12:57:02 +0200
Message-ID: <20200406105703.79201-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200406105703.79201-1-roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.

This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes: Xen itself for example offers a HVMOP_flush_tlbs hypercall in
order to perform a TLB flush without having to IPI each CPU. When
using such mechanisms it's no longer possible to keep a timestamp of
the flushes on each CPU, as they are performed by the underlying
hypervisor.

Offer a boolean in order to signal Xen that the timestamped TLB
shouldn't be used. This avoids keeping the timestamps of the flushes,
and also forces NEED_FLUSH to always return true.

No functional change intended, as this change doesn't introduce any
user that disables the timestamped TLB.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/flushtlb.c        | 19 +++++++++++++------
 xen/include/asm-x86/flushtlb.h | 17 ++++++++++++++++-
 2 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index c81e53c0ae..22b2e84329 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -32,6 +32,9 @@
 u32 tlbflush_clock = 1U;
 DEFINE_PER_CPU(u32, tlbflush_time);
 
+/* Signals whether the TLB flush clock is in use. */
+bool __read_mostly tlb_clk_enabled = true;
+
 /*
  * pre_flush(): Increment the virtual TLB-flush clock. Returns new clock value.
  * 
@@ -82,12 +85,13 @@ static void post_flush(u32 t)
 static void do_tlb_flush(void)
 {
     unsigned long flags, cr4;
-    u32 t;
+    u32 t = 0;
 
     /* This non-reentrant function is sometimes called in interrupt context. */
     local_irq_save(flags);
 
-    t = pre_flush();
+    if ( tlb_clk_enabled )
+        t = pre_flush();
 
     if ( use_invpcid )
         invpcid_flush_all();
@@ -99,7 +103,8 @@ static void do_tlb_flush(void)
     else
         write_cr3(read_cr3());
 
-    post_flush(t);
+    if ( tlb_clk_enabled )
+        post_flush(t);
 
     local_irq_restore(flags);
 }
@@ -107,7 +112,7 @@ static void do_tlb_flush(void)
 void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
 {
     unsigned long flags, old_cr4;
-    u32 t;
+    u32 t = 0;
 
     /* Throughout this function we make this assumption: */
     ASSERT(!(cr4 & X86_CR4_PCIDE) || !(cr4 & X86_CR4_PGE));
@@ -115,7 +120,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
     /* This non-reentrant function is sometimes called in interrupt context. */
     local_irq_save(flags);
 
-    t = pre_flush();
+    if ( tlb_clk_enabled )
+        t = pre_flush();
     hvm_flush_guest_tlbs();
 
     old_cr4 = read_cr4();
@@ -168,7 +174,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
     if ( cr4 & X86_CR4_PCIDE )
         invpcid_flush_all_nonglobals();
 
-    post_flush(t);
+    if ( tlb_clk_enabled )
+        post_flush(t);
 
     local_irq_restore(flags);
 }
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 579dc56803..724455ae0c 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -21,10 +21,21 @@ extern u32 tlbflush_clock;
 /* Time at which each CPU's TLB was last flushed. */
 DECLARE_PER_CPU(u32, tlbflush_time);
 
-#define tlbflush_current_time() tlbflush_clock
+/* TLB clock is in use. */
+extern bool tlb_clk_enabled;
+
+static inline uint32_t tlbflush_current_time(void)
+{
+    /* Returning 0 from tlbflush_current_time will always force a flush. */
+    return tlb_clk_enabled ? tlbflush_clock : 0;
+}
 
 static inline void page_set_tlbflush_timestamp(struct page_info *page)
 {
+    /* Avoid the write if the TLB clock is disabled. */
+    if ( !tlb_clk_enabled )
+        return;
+
     /*
      * Prevent storing a stale time stamp, which could happen if an update
      * to tlbflush_clock plus a subsequent flush IPI happen between the
@@ -67,6 +78,10 @@ static inline void tlbflush_filter(cpumask_t *mask, uint32_t page_timestamp)
 {
     unsigned int cpu;
 
+    /* Short-circuit: there's no need to iterate if the clock is disabled. */
+    if ( !tlb_clk_enabled )
+        return;
+
     for_each_cpu ( cpu, mask )
         if ( !NEED_FLUSH(per_cpu(tlbflush_time, cpu), page_timestamp) )
             __cpumask_clear_cpu(cpu, mask);
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 10:57:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 10:57:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPRb-0000Bn-Qc; Mon, 06 Apr 2020 10:57:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Lhp/=5W=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jLPRa-0000BF-FA
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 10:57:30 +0000
X-Inumbo-ID: 68100e48-77f5-11ea-b4f4-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 68100e48-77f5-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 10:57:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586170648;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=6xDyV2T4eBxzsTghP88Qw+tODGijc2LN55Bf5M9CvYA=;
 b=haNmC880Ns7yHoponrGs/0JRRaF6eKsZaKTmaM2nUbJe6jE8oQxrIKzz
 txX3atsbHerz/VAPsOWvUQC26uzuIBBrQQaKg/hgHL9jBV7NEYAtk4Bpr
 XIsLD81RSDvxr7vF7bTKxwVnBuS4B3TPbNuk8fK7U1dX6/cglHPy674r6 A=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Anvi2ZOdYknQIEGho41bTjypWjKonVD29NSd2wDbK8eQmuKHpxE6v+TKcC6l2EqWvFM0igmNXJ
 aulG5GKZfszW5IttEr4duACQ2VvcR6+7h6oCq7wJtXZ26s1g9am7s+NtKDEL94jn6wMX2Xqce4
 NPle+pv8OtNlwSND5IX6HiCeN2KYn2knLnjQ/vYKxqVYAUrBSnphDCVIk5gXhh+1gIGqZ493Au
 9Lc8u3663HvQYWmPX2V744Jf9tD0Cjtt+YmNotSFwHlKQdbQQp7APgtUwYIJHoJP2S38uhjVaY
 Xeg=
X-SBRS: 2.7
X-MesageID: 15630973
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15630973"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v9 3/3] x86/tlb: use Xen L0 assisted TLB flush when available
Date: Mon, 6 Apr 2020 12:57:03 +0200
Message-ID: <20200406105703.79201-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200406105703.79201-1-roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.

The following figures are from a PV guest running `make -j32 xen` in
shim mode with 32 vCPUs and HAP.

Using x2APIC and ALLBUT shorthand:
real	4m35.973s
user	4m35.110s
sys	36m24.117s

Using L0 assisted flush:
real    1m2.596s
user    4m34.818s
sys     5m16.374s

The implementation adds a new hook to hypervisor_ops so other
enlightenments can also implement such assisted flush just by filling
the hook.

Note that the Xen implementation completely ignores the dirty CPU mask
and the linear address passed in, and always performs a global TLB
flush on all vCPUs. This is a limitation of the hypercall provided by
Xen. Also note that local TLB flushes are not performed using the
assisted TLB flush, only remote ones.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Changes since v5:
 - Clarify commit message.
 - Test for assisted flush at setup, do this for all hypervisors.
 - Return EOPNOTSUPP if assisted flush is not available.

Changes since v4:
 - Adjust order calculation.

Changes since v3:
 - Use an alternative call for the flush hook.

Changes since v1:
 - Add a L0 assisted hook to hypervisor ops.
---
 xen/arch/x86/guest/hypervisor.c        | 14 ++++++++++++++
 xen/arch/x86/guest/xen/xen.c           |  6 ++++++
 xen/arch/x86/smp.c                     |  7 +++++++
 xen/include/asm-x86/guest/hypervisor.h | 17 +++++++++++++++++
 4 files changed, 44 insertions(+)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 647cdb1367..e46de42ded 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -18,6 +18,7 @@
  *
  * Copyright (c) 2019 Microsoft.
  */
+#include <xen/cpumask.h>
 #include <xen/init.h>
 #include <xen/types.h>
 
@@ -51,6 +52,10 @@ void __init hypervisor_setup(void)
 {
     if ( ops.setup )
         ops.setup();
+
+    /* Check if assisted flush is available and disable the TLB clock if so. */
+    if ( !hypervisor_flush_tlb(cpumask_of(smp_processor_id()), NULL, 0) )
+        tlb_clk_enabled = false;
 }
 
 int hypervisor_ap_setup(void)
@@ -73,6 +78,15 @@ void __init hypervisor_e820_fixup(struct e820map *e820)
         ops.e820_fixup(e820);
 }
 
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+                         unsigned int order)
+{
+    if ( ops.flush_tlb )
+        return alternative_call(ops.flush_tlb, mask, va, order);
+
+    return -EOPNOTSUPP;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index e74fd1e995..3bc01c8723 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -324,12 +324,18 @@ static void __init e820_fixup(struct e820map *e820)
         pv_shim_fixup_e820(e820);
 }
 
+static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int order)
+{
+    return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
+}
+
 static const struct hypervisor_ops __initconstrel ops = {
     .name = "Xen",
     .setup = setup,
     .ap_setup = ap_setup,
     .resume = resume,
     .e820_fixup = e820_fixup,
+    .flush_tlb = flush_tlb,
 };
 
 const struct hypervisor_ops *__init xg_probe(void)
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index bcead5d01b..1d9fec65de 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -15,6 +15,7 @@
 #include <xen/perfc.h>
 #include <xen/spinlock.h>
 #include <asm/current.h>
+#include <asm/guest.h>
 #include <asm/smp.h>
 #include <asm/mc146818rtc.h>
 #include <asm/flushtlb.h>
@@ -268,6 +269,12 @@ void flush_area_mask(const cpumask_t *mask, const void *va, unsigned int flags)
     if ( (flags & ~FLUSH_ORDER_MASK) &&
          !cpumask_subset(mask, cpumask_of(cpu)) )
     {
+        if ( cpu_has_hypervisor &&
+             !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID |
+                         FLUSH_ORDER_MASK)) &&
+             !hypervisor_flush_tlb(mask, va, (flags - 1) & FLUSH_ORDER_MASK) )
+            return;
+
         spin_lock(&flush_lock);
         cpumask_and(&flush_cpumask, mask, &cpu_online_map);
         cpumask_clear_cpu(cpu, &flush_cpumask);
diff --git a/xen/include/asm-x86/guest/hypervisor.h b/xen/include/asm-x86/guest/hypervisor.h
index ade10e74ea..77a1d21824 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -19,6 +19,8 @@
 #ifndef __X86_HYPERVISOR_H__
 #define __X86_HYPERVISOR_H__
 
+#include <xen/cpumask.h>
+
 #include <asm/e820.h>
 
 struct hypervisor_ops {
@@ -32,6 +34,8 @@ struct hypervisor_ops {
     void (*resume)(void);
     /* Fix up e820 map */
     void (*e820_fixup)(struct e820map *e820);
+    /* L0 assisted TLB flush */
+    int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int order);
 };
 
 #ifdef CONFIG_GUEST
@@ -41,6 +45,14 @@ void hypervisor_setup(void);
 int hypervisor_ap_setup(void);
 void hypervisor_resume(void);
 void hypervisor_e820_fixup(struct e820map *e820);
+/*
+ * L0 assisted TLB flush.
+ * mask: cpumask of the dirty vCPUs that should be flushed.
+ * va: linear address to flush, or NULL for global flushes.
+ * order: order of the linear address pointed by va.
+ */
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+                         unsigned int order);
 
 #else
 
@@ -52,6 +64,11 @@ static inline void hypervisor_setup(void) { ASSERT_UNREACHABLE(); }
 static inline int hypervisor_ap_setup(void) { return 0; }
 static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
 static inline void hypervisor_e820_fixup(struct e820map *e820) {}
+static inline int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+                                       unsigned int order)
+{
+    return -EOPNOTSUPP;
+}
 
 #endif  /* CONFIG_GUEST */
 
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 11:00:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 11:00:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPU6-00017u-9g; Mon, 06 Apr 2020 11:00:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=06X9=5W=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jLPU4-0000v6-L5
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 11:00:04 +0000
X-Inumbo-ID: c3e7cba3-77f5-11ea-bfe0-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c3e7cba3-77f5-11ea-bfe0-12813bfff9fa;
 Mon, 06 Apr 2020 11:00:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586170803;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=4hx5mGuHDzA5+dvvT4cVCkiCfX8ylquIvcCMnoby8o8=;
 b=AlT2GZlaPxuKcV9GX4kHCs+T2VidspOwSNV7/SIeYJD88XWKeSPZeTni
 hMQsZM52CW6M/btB8wxvoPyldho7EQUC9qMR8XEtZXCRBW5hOzE9fhiGd
 R56gfmol9r4Bnu8Ny1URAa2UdqyjS5BMmlWvpc6rbmHJ+I3jl4+7rhssd g=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: vzlJoJoPAWg3TfMFYrWLraz7UQzkYEFdlGGQmtyLH3Nt97LUS2ei0GJtf75z6whm2zpnCVqbKg
 IBJDVMR9rghkcT7KNpbYdfbCNOK97ABA+rihv4x55SWwFLeutrij99+YxiPQCXwL88XhjP8Bka
 0D8doIQw2ZfOrEey/y+p/kNmNQM0aHstCNclMfWLi5rBTmOoCBOMcZP0BaXycD0eDG5UqDdJNP
 rw35MtUdb7UYmSffiu/kglPgSDxVq2F1tl1nOEpblMtLp1NEnwWM6FMJuL4PGsKc9sAC5VfsT6
 +YM=
X-SBRS: 2.7
X-MesageID: 15547921
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15547921"
Date: Mon, 6 Apr 2020 11:59:54 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: <paul@xen.org>
Subject: Re: [PATCH for-5.0] xen-block: Fix double qlist remove
Message-ID: <20200406105954.GT4088@perard.uk.xensource.com>
References: <20200402130819.1216125-1-anthony.perard@citrix.com>
 <001801d608fa$d3f0d3f0$7bd27bd0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <001801d608fa$d3f0d3f0$7bd27bd0$@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Kevin Wolf' <kwolf@redhat.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>, qemu-block@nongnu.org,
 qemu-stable@nongnu.org, qemu-devel@nongnu.org, 'Max Reitz' <mreitz@redhat.com>,
 'Stefan Hajnoczi' <stefanha@redhat.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 02, 2020 at 03:27:22PM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Anthony PERARD <anthony.perard@citrix.com>
> > Sent: 02 April 2020 14:08
> > To: qemu-devel@nongnu.org
> > Cc: qemu-stable@nongnu.org; Anthony PERARD <anthony.perard@citrix.com>; Stefano Stabellini
> > <sstabellini@kernel.org>; Paul Durrant <paul@xen.org>; Stefan Hajnoczi <stefanha@redhat.com>; Kevin
> > Wolf <kwolf@redhat.com>; Max Reitz <mreitz@redhat.com>; xen-devel@lists.xenproject.org; qemu-
> > block@nongnu.org
> > Subject: [PATCH for-5.0] xen-block: Fix double qlist remove
> > 
> > Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
> > remove") revealed that a request was removed twice from a list, once
> > in xen_block_finish_request() and a second time in
> > xen_block_release_request() when both function are called from
> > xen_block_complete_aio(). But also, the `requests_inflight' counter is
> > decreased twice, and thus became negative.
> > 
> > This is a bug that was introduced in bfd0d6366043, where a `finished'
> > list was removed.
> > 
> > This patch simply re-add the `finish' parameter of
> > xen_block_release_request() so that we can distinguish when we need to
> > remove a request from the inflight list and when not.
> > 
> > Fixes: bfd0d6366043 ("xen-block: improve response latency")
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> It looks to me like it would just be more straightforward to simply drop the QLIST_REMOVE and requests_inflight-- from
> xen_block_release_request() and simply insist that xen_block_finish_request() is called in all cases (which I think means adding one
> extra call to it in xen_block_handle_requests()).

I'm thinking of going further than that. I've notice another bug, in
case of error in xen_block_do_aio(), xen_block_finish_request() is
called without ever calling send_response() or release_request(). I
think that mean a leak of request.

So, I'm thinking of creating a function that would do finish_request(),
send_response(), release_request(), has I believe those operations needs
to be done together anyway.

I'll rework the patch.

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 11:00:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 11:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPUD-0001CP-Ii; Mon, 06 Apr 2020 11:00:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=67tO=5W=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jLPUB-0001Bw-NO
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 11:00:11 +0000
X-Inumbo-ID: c8957230-77f5-11ea-bfe0-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c8957230-77f5-11ea-bfe0-12813bfff9fa;
 Mon, 06 Apr 2020 11:00:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586170812;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=2FwxIFRYXkcgeQXPV7OgRwJs+V0kS3Mqn0XwObKBG48=;
 b=ApaOGw7bssfePSFvJPGh750LuW0gc1tdAUCB/TR81KrsZD9reoYEPzx3
 ShHnmS7VNCpSXOJhGOQw7VFxUEL7ScHmkva9Z0VE3RFEU71dc2VbNjZq9
 7r9IHOmZt9k3Y+RFBkI4oPKRjGkLt164FeY59VeIbHe02FwuZNuDrfZEh w=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: CXQ0V6V+QwygP6k4DhewJzCrtODy10VYOvIE8aHWZj1eikKuR0dgG8uwzQBWrO1ilJ2J4+forw
 /4LPpyj7Q9/O8bJfOrHuPMjOspa3F4VIpqMkCFBYeaXcGkroa8Up6Ele5aMGnUQ3VQUbhK7AbS
 Nv7fqcLQoKoiosVsJWVuRtJD5S+6Msq44u3y7cxBvVjYwIFw4mu13RgunU2/gvTyZ2ttfVWFXW
 s0DBbwBTdphtoKE76YGCZOqlZkh9BfQNQcrISFtRXW6XrdC1wqt0X8Zp4vpIWvQXogurZBFS2Q
 g40=
X-SBRS: 2.7
X-MesageID: 15236678
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,350,1580792400"; d="scan'208";a="15236678"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-ID: <24203.2996.819908.965198@mariner.uk.xensource.com>
Date: Mon, 6 Apr 2020 12:00:04 +0100
To: Julien Grall <julien@xen.org>, Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus [and 1 more messages]
In-Reply-To: <24203.2546.728186.463143@mariner.uk.xensource.com>,
 <fd09220a-7470-4679-ce16-f4553579171b@xen.org>
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
 <24203.2251.628483.557280@mariner.uk.xensource.com>
 <fd09220a-7470-4679-ce16-f4553579171b@xen.org>
 <26161282-7bad-5888-16c9-634647e6fde8@xen.org>
 <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com>
 <24203.2546.728186.463143@mariner.uk.xensource.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Anthony Perard <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
> There are no correlation between event channels and vCPUs. The number of 
> event channels only depends on the number of frontend you have in your 
> guest. So...
> 
> Hi Ian,
> 
> On 06/04/2020 11:47, Ian Jackson wrote:
> > If ARM folks want to have a different formula for the default then
> > that is of course fine but I wonder whether this might do ARMk more
> > harm than good in this case.
> 
> ... 1023 event channels is going to be plenty enough for most of the use 
> cases.

OK, thanks for the quick reply.

So, J�rgen, I think everyone will be happy with this:

Ian Jackson writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
> I guess you should make two patches 1. duplicate the existing formula
> (no functional change) 2. change the x86 formula.
> 
> I would ack the first and be guided by x86 folks for the 2nd.

Ian.


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 11:01:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 11:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPVh-0001O2-V9; Mon, 06 Apr 2020 11:01:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8YOW=5W=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLPVg-0001NR-IK
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 11:01:44 +0000
X-Inumbo-ID: 001faff4-77f6-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 001faff4-77f6-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 11:01:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DEC70AB8B;
 Mon,  6 Apr 2020 11:01:41 +0000 (UTC)
Subject: Re: [PATCH v2] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
To: Julien Grall <julien@xen.org>
References: <20200404130613.26428-1-julien@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <391ef401-b5d3-2f95-5fe3-c32f372dcc92@suse.com>
Date: Mon, 6 Apr 2020 13:01:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200404130613.26428-1-julien@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 xen-devel@lists.xenproject.org, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 04.04.2020 15:06, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
> data to guest handle marked const.
> 
> Thankfully, no users of the helper will do that. Rather than hoping this
> can be caught during review, harden copy_to_guest_offset() so the build
> will fail if such users are introduced.
> 
> There is no easy way to check whether a const is NULL in C99. The
> approach used is to introduce an unused variable that is non-const and
> assign the handle. If the handle were const, this would fail at build
> because without an explicit cast, it is not possible to assign a const
> variable to a non-const variable.
> 
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Julien Grall <jgrall@amazon.com>

I'm not convinced it is a good idea to add (recurring) comments
like you do - there are more aspects of these macros that would
be worth commenting on, and commenting on some but not all may
give the wrong impression of all subtleties being covered (also
for others).

In any event I'd like to ask that each header gain such a
comment only once, with the other being a tiny reference to the
one "complete" instance.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 11:03:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 11:03:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPXR-0001WX-B3; Mon, 06 Apr 2020 11:03:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=leFb=5W=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jLPXQ-0001WR-Cy
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 11:03:32 +0000
X-Inumbo-ID: 405b27e2-77f6-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 405b27e2-77f6-11ea-83d8-bc764e2007e4;
 Mon, 06 Apr 2020 11:03:31 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A3078AD4B;
 Mon,  6 Apr 2020 11:03:30 +0000 (UTC)
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus [and 1 more messages]
To: Ian Jackson <ian.jackson@citrix.com>, Julien Grall <julien@xen.org>
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
 <24203.2251.628483.557280@mariner.uk.xensource.com>
 <fd09220a-7470-4679-ce16-f4553579171b@xen.org>
 <26161282-7bad-5888-16c9-634647e6fde8@xen.org>
 <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com>
 <24203.2546.728186.463143@mariner.uk.xensource.com>
 <24203.2996.819908.965198@mariner.uk.xensource.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <f0102e04-29be-1e4d-2264-11601013b725@suse.com>
Date: Mon, 6 Apr 2020 13:03:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <24203.2996.819908.965198@mariner.uk.xensource.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.20 13:00, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
>> There are no correlation between event channels and vCPUs. The number of
>> event channels only depends on the number of frontend you have in your
>> guest. So...
>>
>> Hi Ian,
>>
>> On 06/04/2020 11:47, Ian Jackson wrote:
>>> If ARM folks want to have a different formula for the default then
>>> that is of course fine but I wonder whether this might do ARMk more
>>> harm than good in this case.
>>
>> ... 1023 event channels is going to be plenty enough for most of the use
>> cases.
> 
> OK, thanks for the quick reply.
> 
> So, Jürgen, I think everyone will be happy with this:
> 
> Ian Jackson writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
>> I guess you should make two patches 1. duplicate the existing formula
>> (no functional change) 2. change the x86 formula.
>>
>> I would ack the first and be guided by x86 folks for the 2nd.

Okay, thanks. Will do that.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 11:03:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 11:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPXh-0001Ym-Jc; Mon, 06 Apr 2020 11:03:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8YOW=5W=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLPXf-0001YZ-OH
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 11:03:47 +0000
X-Inumbo-ID: 49827a14-77f6-11ea-bfe0-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 49827a14-77f6-11ea-bfe0-12813bfff9fa;
 Mon, 06 Apr 2020 11:03:47 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 030BBAD41;
 Mon,  6 Apr 2020 11:03:46 +0000 (UTC)
Subject: Re: [PATCH 0/5] use new API for Xen page tables
To: Hongyan Xia <hx242@xen.org>
References: <cover.1584955616.git.hongyxia@amazon.com>
 <636251f68db5e094f0c4dd5871eb4146dadb1589.camel@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <0f072eca-bd34-ebb7-706f-9dc688c991ad@suse.com>
Date: Mon, 6 Apr 2020 13:03:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <636251f68db5e094f0c4dd5871eb4146dadb1589.camel@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.2020 10:27, Hongyan Xia wrote:
> Ping.

Does this somehow imply you didn't get my replies sent on the 1st?

Jan

> On Mon, 2020-03-23 at 09:41 +0000, Hongyan Xia wrote:
>> From: Hongyan Xia <hongyxia@amazon.com>
>>
>> This small series is basically just rewriting functions using the new
>> API to map and unmap PTEs. Each patch is independent.
>>
>> Apart from mapping and unmapping page tables, no other functional
>> change
>> intended.
>>
>> Wei Liu (5):
>>   x86/shim: map and unmap page tables in replace_va_mapping
>>   x86_64/mm: map and unmap page tables in m2p_mapped
>>   x86_64/mm: map and unmap page tables in share_hotadd_m2p_table
>>   x86_64/mm: map and unmap page tables in destroy_compat_m2p_mapping
>>   x86_64/mm: map and unmap page tables in destroy_m2p_mapping
>>
>>  xen/arch/x86/pv/shim.c     | 10 ++++---
>>  xen/arch/x86/x86_64/mm.c   | 55 +++++++++++++++++++++++++-----------
>> --
>>  xen/include/asm-x86/page.h | 18 +++++++++++++
>>  3 files changed, 62 insertions(+), 21 deletions(-)
>>
> 



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 11:11:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 11:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPew-0002SQ-IE; Mon, 06 Apr 2020 11:11:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8YOW=5W=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLPev-0002SL-Mr
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 11:11:17 +0000
X-Inumbo-ID: 55ab008a-77f7-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 55ab008a-77f7-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 11:11:17 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 89554ADE8;
 Mon,  6 Apr 2020 11:11:15 +0000 (UTC)
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus [and 1 more messages]
To: Ian Jackson <ian.jackson@citrix.com>
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
 <24203.2251.628483.557280@mariner.uk.xensource.com>
 <fd09220a-7470-4679-ce16-f4553579171b@xen.org>
 <26161282-7bad-5888-16c9-634647e6fde8@xen.org>
 <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com>
 <24203.2546.728186.463143@mariner.uk.xensource.com>
 <24203.2996.819908.965198@mariner.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <799396b3-0304-e149-cc3f-45c5a46c7c0c@suse.com>
Date: Mon, 6 Apr 2020 13:11:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <24203.2996.819908.965198@mariner.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Anthony Perard <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.2020 13:00, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
>> There are no correlation between event channels and vCPUs. The number of 
>> event channels only depends on the number of frontend you have in your 
>> guest. So...
>>
>> Hi Ian,
>>
>> On 06/04/2020 11:47, Ian Jackson wrote:
>>> If ARM folks want to have a different formula for the default then
>>> that is of course fine but I wonder whether this might do ARMk more
>>> harm than good in this case.
>>
>> ... 1023 event channels is going to be plenty enough for most of the use 
>> cases.
> 
> OK, thanks for the quick reply.
> 
> So, Jürgen, I think everyone will be happy with this:

I don't think I will be - my prior comment still holds on there not
being any grounds to use a specific OS kernel's (and to be precise
a specific OS kernel version's) requirements for determining
defaults. If there was to be such a dependency, then OS kernel
[variant] should be part of the inputs to such a (set of) formula(s).

Jan

> Ian Jackson writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
>> I guess you should make two patches 1. duplicate the existing formula
>> (no functional change) 2. change the x86 formula.
>>
>> I would ack the first and be guided by x86 folks for the 2nd.
> 
> Ian.
> 



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 11:18:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 11:18:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLPmA-0002fi-B2; Mon, 06 Apr 2020 11:18:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=zgfQ=5W=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLPm9-0002ey-2G
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 11:18:45 +0000
X-Inumbo-ID: 5f7e43a0-77f8-11ea-bfe2-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5f7e43a0-77f8-11ea-bfe2-12813bfff9fa;
 Mon, 06 Apr 2020 11:18:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ZDnIADp+NYjqgIRzx/3WbveueF9h/f8Yy/V+NfKnBR4=; b=inY6nHA7aQME5U9iUOapH5srl
 70SpHRNM1+xipn4IS2oc3Iunr65Eg0K5piSYSiwUeOTVFWaPpUcAP5HcyLPX7ruq6CB8O2kf9JPbC
 m4cc+ubVty0jzgrw65qOvs03zaw6TjVjDlS0u0iNSQ/g+9BxyL3Mu3NPWK2c5wUwpJ//k=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLPm6-00085v-CI; Mon, 06 Apr 2020 11:18:42 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLPm5-0005M3-OE; Mon, 06 Apr 2020 11:18:41 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLPm5-00013c-NQ; Mon, 06 Apr 2020 11:18:41 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149451-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149451: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
X-Osstest-Versions-That: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 06 Apr 2020 11:18:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     16 guest-localmigrate           fail  like 149406
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149431
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149431
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149431
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149431
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149431
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149431
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149431
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149431
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149431
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
baseline version:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd

Last test of basis   149451  2020-04-06 01:51:54 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 11:53:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 11:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLQJY-0005od-4e; Mon, 06 Apr 2020 11:53:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8YOW=5W=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLQJX-0005oY-8z
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 11:53:15 +0000
X-Inumbo-ID: 32228b64-77fd-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 32228b64-77fd-11ea-83d8-bc764e2007e4;
 Mon, 06 Apr 2020 11:53:14 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D853BAEA8;
 Mon,  6 Apr 2020 11:53:12 +0000 (UTC)
Subject: Re: [Xen-devel] [PATCH v2 2/2] xen: credit2: fix credit reset
 happening too few times
To: Dario Faggioli <dfaggioli@suse.com>
References: <158457508246.11355.6457403441669388939.stgit@Palanthas>
 <158457672023.11355.16720240521867328301.stgit@Palanthas>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f7ac7ae4-b31b-0e65-6a44-82e4aa7848d6@suse.com>
Date: Mon, 6 Apr 2020 13:53:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <158457672023.11355.16720240521867328301.stgit@Palanthas>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Charles Arnold <carnold@suse.com>,
 Glen <glenbarney@gmail.com>, George Dunlap <george.dunlap@citrix.com>,
 Tomas Mozes <hydrapolic@gmail.com>, Sarah Newman <srn@prgmr.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 19.03.2020 01:12, Dario Faggioli wrote:
> @@ -3328,12 +3325,9 @@ runq_candidate(struct csched2_runqueue_data *rqd,
>                          (unsigned char *)&d);
>          }
>  
> -        /* Only consider units that are allowed to run on this processor. */
> +        /* Only consider vcpus that are allowed to run on this processor. */
>          if ( !cpumask_test_cpu(cpu, svc->unit->cpu_hard_affinity) )

While backporting this to 4.12 I noticed that this is a presumably
unintended comment adjustment.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 11:54:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 11:54:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLQKR-0005rl-FJ; Mon, 06 Apr 2020 11:54:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=leFb=5W=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jLQKP-0005rc-Ot
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 11:54:09 +0000
X-Inumbo-ID: 52c7f9bc-77fd-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 52c7f9bc-77fd-11ea-83d8-bc764e2007e4;
 Mon, 06 Apr 2020 11:54:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 01EFAAC52;
 Mon,  6 Apr 2020 11:54:08 +0000 (UTC)
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus [and 1 more messages]
To: Jan Beulich <jbeulich@suse.com>, Ian Jackson <ian.jackson@citrix.com>
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
 <24203.2251.628483.557280@mariner.uk.xensource.com>
 <fd09220a-7470-4679-ce16-f4553579171b@xen.org>
 <26161282-7bad-5888-16c9-634647e6fde8@xen.org>
 <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com>
 <24203.2546.728186.463143@mariner.uk.xensource.com>
 <24203.2996.819908.965198@mariner.uk.xensource.com>
 <799396b3-0304-e149-cc3f-45c5a46c7c0c@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <c85e15d2-3d3f-7d7f-eb7a-af5270df2e2d@suse.com>
Date: Mon, 6 Apr 2020 13:54:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <799396b3-0304-e149-cc3f-45c5a46c7c0c@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.20 13:11, Jan Beulich wrote:
> On 06.04.2020 13:00, Ian Jackson wrote:
>> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
>>> There are no correlation between event channels and vCPUs. The number of
>>> event channels only depends on the number of frontend you have in your
>>> guest. So...
>>>
>>> Hi Ian,
>>>
>>> On 06/04/2020 11:47, Ian Jackson wrote:
>>>> If ARM folks want to have a different formula for the default then
>>>> that is of course fine but I wonder whether this might do ARMk more
>>>> harm than good in this case.
>>>
>>> ... 1023 event channels is going to be plenty enough for most of the use
>>> cases.
>>
>> OK, thanks for the quick reply.
>>
>> So, Jürgen, I think everyone will be happy with this:
> 
> I don't think I will be - my prior comment still holds on there not
> being any grounds to use a specific OS kernel's (and to be precise
> a specific OS kernel version's) requirements for determining
> defaults. If there was to be such a dependency, then OS kernel
> [variant] should be part of the inputs to such a (set of) formula(s).

IMO this kind of trying to be perfect will completely block a sane
heuristic for being able to boot large guests at all.

The patch isn't about to find an as stringent as possible upper
boundary for huge guests, but a sane value being able to boot most of
those.

And how should Xen know the OS kernel needs exactly after all?

And it is not that we talking about megabytes of additional memory. A
guest with 256 vcpus will just be able to use additional 36 memory
pages. The maximum non-PV domain (the probably only relevant case
of another OS than Linux being used) with 128 vcpus would "waste"
32 kB. In case the guest misbehaves.

The alternative would be to do nothing and having to let the user
experience a somewhat cryptic guest crash. He could google for a
possible solution which would probably end in a rather high static
limit resulting in wasting even more memory.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 13:16:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 13:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLRbX-0003ye-9R; Mon, 06 Apr 2020 13:15:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9GA=5W=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jLRbW-0003yY-AS
 for xen-devel@lists.xen.org; Mon, 06 Apr 2020 13:15:54 +0000
X-Inumbo-ID: bdc3a288-7808-11ea-b4f4-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bdc3a288-7808-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 13:15:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586178953;
 h=subject:to:references:cc:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=43uLD/0MVWyZ8H9pok8ak2jCqyJ6D+/XeX6YdRq1LJE=;
 b=PfqELVhj+zAxV8hTp1o4ciE7Sjt27F/MB+Bj5o83K3fJUIWfHaOtn+vB
 FwFpDvl445Kwiu4v545cOpQGS87RDRBWSC45GEZQiCMydgs/g6pYEFT5p
 ivi8qOCPeKPn61l5ZxTH8FXAwbghKANXoO1BoCEPOn00qqAwSAi+FtFHJ w=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: g9mwFGVCsw54ChHTbnndR6O41r4/+DGHRDhVxMD00VdRYolyZ7Y9lWTOE0y+H77aGWcvbPq8LQ
 6W3SnQ5Mh865THRANb/2BssN7s0ZPZOe9A4D46DEKuE1JFXYrXRS5k76YarPcVkOx+TLRpmAOg
 3wHsBDBydV9jPm6PAdr2TzB4uLJLUYNt6YGFK3s38Se9R5M7mwCvqDmqQSDTjNgCilJ5G3kjAO
 Kh/EW2sYUMQH7ZUKlMpXddAFMAX2npbd4xCQpDGjv3YYPMrdFCdmptFHalXQ3nOkMsu/Fw6MBK
 uM4=
X-SBRS: 2.7
X-MesageID: 15245679
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,351,1580792400"; d="scan'208";a="15245679"
Subject: Re: Live migration and PV device handling
To: <xen-devel@lists.xen.org>
References: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
 <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
 <d698f1ed-247e-404c-04ce-762c651771d1@oracle.com>
 <001301d60be8$06afa1a0$140ee4e0$@xen.org>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <391f80f6-6038-2d2c-cf0f-bdbda27af378@citrix.com>
Date: Mon, 6 Apr 2020 14:15:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <001301d60be8$06afa1a0$140ee4e0$@xen.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Dongli Zhang' <dongli.zhang@oracle.com>, 'Anastassios
 Nanos' <anastassios.nanos@sunlight.io>, paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06/04/2020 08:50, Paul Durrant wrote:
>> -----Original Message-----
>> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Dongli Zhang
>> Sent: 03 April 2020 23:33
>> To: Andrew Cooper <andrew.cooper3@citrix.com>; Anastassios Nanos <anastassios.nanos@sunlight.io>; xen-
>> devel@lists.xen.org
>> Subject: Re: Live migration and PV device handling
>>
>> Hi Andrew,
>>
>> On 4/3/20 5:42 AM, Andrew Cooper wrote:
>>> On 03/04/2020 13:32, Anastassios Nanos wrote:
>>>> Hi all,
>>>>
>>>> I am trying to understand how live-migration happens in xen. I am
>>>> looking in the HVM guest case and I have dug into the relevant parts
>>>> of the toolstack and the hypervisor regarding memory, vCPU context
>>>> etc.
>>>>
>>>> In particular, I am interested in how PV device migration happens. I
>>>> assume that the guest is not aware of any suspend/resume operations
>>>> being done
>>> Sadly, this assumption is not correct.  HVM guests with PV drivers
>>> currently have to be aware in exactly the same way as PV guests.
>>>
>>> Work is in progress to try and address this.  See
>>> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=775a02452ddf3a6889690de90b1a94eb29c3c732
>>> (sorry - for some reason that doc isn't being rendered properly in
>>> https://xenbits.xen.org/docs/ )

Document rendering now fixed.

https://xenbits.xen.org/docs/unstable/designs/non-cooperative-migration.html

>> I read below from the commit:
>>
>> +* The toolstack choose a randomized domid for initial creation or default
>> +migration, but preserve the source domid non-cooperative migration.
>> +Non-Cooperative migration will have to be denied if the domid is
>> +unavailable on the target host, but randomization of domid on creation
>> +should hopefully minimize the likelihood of this. Non-Cooperative migration
>> +to localhost will clearly not be possible.
>>
>> Does that indicate while scope of domid_t is shared by a single server in old
>> design, the scope of domid_t is shared by a cluster of server in new design?
>>
>> That is, the domid should be unique in the cluster of all servers if we expect
>> non-cooperative migration always succeed?
>>
> That would be necessary to guarantee success (or rather guarantee no failure due to domid clash) but the scope of xl/libxl is single serve, hence randomization is the best we have to reduce clashes to a minimum.

domid's are inherently a local concept and will remain so, but a
toolstack managing multiple servers and wanting to use this version of
non-cooperative migration will have to manage domid's cluster wide.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 14:03:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 14:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLSLk-00084V-9S; Mon, 06 Apr 2020 14:03:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=06X9=5W=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jLSLi-00084P-Ft
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 14:03:38 +0000
X-Inumbo-ID: 68d1b8ee-780f-11ea-bfee-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 68d1b8ee-780f-11ea-bfee-12813bfff9fa;
 Mon, 06 Apr 2020 14:03:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586181817;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=EEshw7iunLfDK0/dpc5kHUSg2CNL4OfRL0BhwgBTPaA=;
 b=dW06BYZuE15rwCSMSu9afHUWXKWodBnLAJJR69v7KKOLWnO0vcPJjrRE
 gmcu1/+d/YTLk4U8szQKik+VDtlP/Y/Y2z4439OCKS9gR+MuMCVLvP1r4
 4hfE7jtGkiQGqlENmj/QaYh3Cty+4a9tz14asalMtVH5p5HGr/eTX/XOL 4=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 9MrkKpqrOxmbABMEeQD23ezG2y0rspYc7sVNOVR8yJg58ralCaIY2RCz60VQkbDU5tHapZQcWP
 1TkP4qAgGWf8oyzgFUOq7VrQJLgd3s49bPrSqjERNw6iwf/4PP3Rc/voNOGhrTR259UK5k4tsE
 67HkjHkD2zIHr8y5qI3FuzHTjykg/9SHmwbuE6jN9t748FIXdmbPgZ1JrurLl5h94Afd2QS4s2
 tWC3yTh8b1QjOn25r5m699zLhUF7Zruxhi0JxGGng/UMFOWm6qJF2eCebMMuhgQm21SPo71NKE
 ofI=
X-SBRS: 2.7
X-MesageID: 15642675
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,351,1580792400"; d="scan'208";a="15642675"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <qemu-devel@nongnu.org>
Subject: [PATCH v2 for-5.0] xen-block: Fix double qlist remove and request leak
Date: Mon, 6 Apr 2020 15:02:17 +0100
Message-ID: <20200406140217.1441858-1-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200406105954.GT4088@perard.uk.xensource.com>
References: <20200406105954.GT4088@perard.uk.xensource.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefano Stabellini <sstabellini@kernel.org>,
 qemu-block@nongnu.org, Paul Durrant <paul@xen.org>, qemu-stable@nongnu.org,
 Max Reitz <mreitz@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>,
 Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
remove") revealed that a request was removed twice from a list, once
in xen_block_finish_request() and a second time in
xen_block_release_request() when both function are called from
xen_block_complete_aio(). But also, the `requests_inflight' counter is
decreased twice, and thus became negative.

This is a bug that was introduced in bfd0d6366043, where a `finished'
list was removed.

That commit also introduced a leak of request in xen_block_do_aio().
That function calls xen_block_finish_request() but the request is
never released after that.

To fix both issue, we do two changes:
- we squash finish_request() and release_request() together as we want
  to remove a request from 'inflight' list to add it to 'freelist'.
- before releasing a request, we need to let now the result to the
  other end, thus we should call xen_block_send_response() before
  releasing a request.

The first change fix the double QLIST_REMOVE() as we remove the extra
call. The second change makes the leak go away because if we want to
call finish_request(), we need to call a function that do all of
finish, send response, and release.

Fixes: bfd0d6366043 ("xen-block: improve response latency")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/block/dataplane/xen-block.c | 48 ++++++++++++----------------------
 1 file changed, 16 insertions(+), 32 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 288a87a814ad..5f8f15778ba5 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -64,6 +64,8 @@ struct XenBlockDataPlane {
     AioContext *ctx;
 };
 
+static int xen_block_send_response(XenBlockRequest *request);
+
 static void reset_request(XenBlockRequest *request)
 {
     memset(&request->req, 0, sizeof(request->req));
@@ -115,23 +117,26 @@ static XenBlockRequest *xen_block_start_request(XenBlockDataPlane *dataplane)
     return request;
 }
 
-static void xen_block_finish_request(XenBlockRequest *request)
+static void xen_block_complete_request(XenBlockRequest *request)
 {
     XenBlockDataPlane *dataplane = request->dataplane;
 
-    QLIST_REMOVE(request, list);
-    dataplane->requests_inflight--;
-}
+    if (xen_block_send_response(request)) {
+        Error *local_err = NULL;
 
-static void xen_block_release_request(XenBlockRequest *request)
-{
-    XenBlockDataPlane *dataplane = request->dataplane;
+        xen_device_notify_event_channel(dataplane->xendev,
+                                        dataplane->event_channel,
+                                        &local_err);
+        if (local_err) {
+            error_report_err(local_err);
+        }
+    }
 
     QLIST_REMOVE(request, list);
+    dataplane->requests_inflight--;
     reset_request(request);
     request->dataplane = dataplane;
     QLIST_INSERT_HEAD(&dataplane->freelist, request, list);
-    dataplane->requests_inflight--;
 }
 
 /*
@@ -246,7 +251,6 @@ static int xen_block_copy_request(XenBlockRequest *request)
 }
 
 static int xen_block_do_aio(XenBlockRequest *request);
-static int xen_block_send_response(XenBlockRequest *request);
 
 static void xen_block_complete_aio(void *opaque, int ret)
 {
@@ -286,7 +290,6 @@ static void xen_block_complete_aio(void *opaque, int ret)
     }
 
     request->status = request->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
-    xen_block_finish_request(request);
 
     switch (request->req.operation) {
     case BLKIF_OP_WRITE:
@@ -306,17 +309,8 @@ static void xen_block_complete_aio(void *opaque, int ret)
     default:
         break;
     }
-    if (xen_block_send_response(request)) {
-        Error *local_err = NULL;
 
-        xen_device_notify_event_channel(dataplane->xendev,
-                                        dataplane->event_channel,
-                                        &local_err);
-        if (local_err) {
-            error_report_err(local_err);
-        }
-    }
-    xen_block_release_request(request);
+    xen_block_complete_request(request);
 
     if (dataplane->more_work) {
         qemu_bh_schedule(dataplane->bh);
@@ -420,8 +414,8 @@ static int xen_block_do_aio(XenBlockRequest *request)
     return 0;
 
 err:
-    xen_block_finish_request(request);
     request->status = BLKIF_RSP_ERROR;
+    xen_block_complete_request(request);
     return -1;
 }
 
@@ -575,17 +569,7 @@ static bool xen_block_handle_requests(XenBlockDataPlane *dataplane)
                 break;
             };
 
-            if (xen_block_send_response(request)) {
-                Error *local_err = NULL;
-
-                xen_device_notify_event_channel(dataplane->xendev,
-                                                dataplane->event_channel,
-                                                &local_err);
-                if (local_err) {
-                    error_report_err(local_err);
-                }
-            }
-            xen_block_release_request(request);
+            xen_block_complete_request(request);
             continue;
         }
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 14:08:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 14:08:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLSQX-0008Fi-VG; Mon, 06 Apr 2020 14:08:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=/51Y=5W=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jLSQW-0008Fc-Ng
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 14:08:36 +0000
X-Inumbo-ID: 1af12654-7810-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1af12654-7810-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 14:08:36 +0000 (UTC)
Received: by mail-ed1-x544.google.com with SMTP id a43so19368843edf.6
 for <xen-devel@lists.xenproject.org>; Mon, 06 Apr 2020 07:08:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=TTw3UrfbySzK+JDBPHarGUZASDNeWpzrpP2iHm36uoU=;
 b=Xa+yNmGCB3Jq8xF6WAm3A2oovOL8D5CEkouUOOELE0TvENSUxM4KWdsc/eoO5OamGx
 6DffZRpPkInDYa7mqkSW01puNZE5vrAgdyQr3ohZgJd5gSP5hvloJgQiNxjS1/RfxhsS
 CoJFH69dLW/WvCwTIpDzoJ/E8ZuOyrIyFRdUz0DEXyPH2oADEaahRb7H/tgAtW2WJSc5
 M04j/xxHZDroEPGnpGXkpn0iqHv7cIT7XJ/gIkNFFMY42GvsqnX1W5OHfxYrH/jjuTEh
 9UPr8t94sXZVVRr9MUD14jmaNeSExR3Ladr7L0gzklZUwe9TEXIp9sbxPKlEDRFJfd/f
 ar5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=TTw3UrfbySzK+JDBPHarGUZASDNeWpzrpP2iHm36uoU=;
 b=OnSMJv7M3LKqplruwhJlGQ8vspb3y7n8L925y2hIwD01Ng9wWE5fNdqYy0u6CPpALv
 cW9Kkth5STdwPLbE0PTeffHxop4h6p67/6pK1TuNpyDLI70yK+kx8Vm1IpK7km/t70PH
 hr179LKBd1c/QTt1wc7QEkdRNbXNM3t63MOMQ/T/Aq+TDkkKhbAYI1Po5NcQC5nUIFIF
 FdWG6ygD8pEozwrjIVICgyjz/Ejpcw7++5K413d1dFp0VJ/nQG03LZ8sa7sngxYqvqnt
 dup7WSxTjjoRwNnauaAWNb47zlpmgrwguWUBv19NEGZlncdAjLqpbIqhfpOVi7ljGfPZ
 U9KQ==
X-Gm-Message-State: AGi0PuaheZ8Qnz77eRMjTrwPWoSlwTLVKnchbiG+FX4RU5H9DhV63l/A
 5HxMjmJaySjQ9YlJ8dPIiSKw38VKTLc=
X-Google-Smtp-Source: APiQypJBZQOsZRgt/jye73SAu0vWAtCpiBGKhYh74oEOItp+jN97kPeBLp8EKA5hV+g9txVoK+ux4Q==
X-Received: by 2002:a50:d2c6:: with SMTP id q6mr19680881edg.265.1586182114080; 
 Mon, 06 Apr 2020 07:08:34 -0700 (PDT)
Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com.
 [209.85.221.49])
 by smtp.gmail.com with ESMTPSA id v19sm2423966edl.76.2020.04.06.07.08.32
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Apr 2020 07:08:33 -0700 (PDT)
Received: by mail-wr1-f49.google.com with SMTP id w15so11388826wrv.10
 for <xen-devel@lists.xenproject.org>; Mon, 06 Apr 2020 07:08:32 -0700 (PDT)
X-Received: by 2002:adf:94c6:: with SMTP id 64mr24786959wrr.386.1586182112301; 
 Mon, 06 Apr 2020 07:08:32 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1585579955.git.tamas.lengyel@intel.com>
 <f40757694decdfdbd5a264be4c277ba824261874.1585579955.git.tamas.lengyel@intel.com>
 <20200406105219.GY28601@Air-de-Roger>
In-Reply-To: <20200406105219.GY28601@Air-de-Roger>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Mon, 6 Apr 2020 08:07:56 -0600
X-Gmail-Original-Message-ID: <CABfawhk9STnn95+O7SnxEzA9KA4u=0pWBZLJ1SLaQ=7eVrFWUg@mail.gmail.com>
Message-ID: <CABfawhk9STnn95+O7SnxEzA9KA4u=0pWBZLJ1SLaQ=7eVrFWUg@mail.gmail.com>
Subject: Re: [PATCH v13 1/3] xen/mem_sharing: VM forking
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 6, 2020 at 4:52 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.com> =
wrote:
>
> On Mon, Mar 30, 2020 at 08:02:08AM -0700, Tamas K Lengyel wrote:
> > VM forking is the process of creating a domain with an empty memory spa=
ce and a
> > parent domain specified from which to populate the memory when necessar=
y. For
> > the new domain to be functional the VM state is copied over as part of =
the fork
> > operation (HVM params, hap allocation, etc).
> >
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> > Acked-by: Jan Beulich <jbeulich@suse.com>
> > +static int bring_up_vcpus(struct domain *cd, struct domain *d)
> > +{
> > +    unsigned int i;
> > +    int ret =3D -EINVAL;
> > +
> > +    if ( d->max_vcpus !=3D cd->max_vcpus ||
> > +        (ret =3D cpupool_move_domain(cd, d->cpupool)) )
> > +        return ret;
> > +
> > +    for ( i =3D 0; i < cd->max_vcpus; i++ )
> > +    {
> > +        if ( !d->vcpu[i] || cd->vcpu[i] )
> > +            continue;
> > +
> > +        if ( !vcpu_create(cd, i) )
> > +            return -EINVAL;
> > +    }
> > +
> > +    domain_update_node_affinity(cd);
> > +    return 0;
> > +}
> > +
> > +static int copy_vcpu_settings(struct domain *cd, struct domain *d)
>
> Nit: AFAICT *d can be constified.

Sure.

>
> > +{
> > +    unsigned int i;
> > +    struct p2m_domain *p2m =3D p2m_get_hostp2m(cd);
> > +    int ret =3D -EINVAL;
> > +
> > +    for ( i =3D 0; i < cd->max_vcpus; i++ )
> > +    {
> > +        const struct vcpu *d_vcpu =3D d->vcpu[i];
> > +        struct vcpu *cd_vcpu =3D cd->vcpu[i];
> > +        struct vcpu_runstate_info runstate;
> > +        mfn_t vcpu_info_mfn;
> > +
> > +        if ( !d_vcpu || !cd_vcpu )
> > +            continue;
> > +
> > +        /* Copy & map in the vcpu_info page if the guest uses one */
> > +        vcpu_info_mfn =3D d_vcpu->vcpu_info_mfn;
> > +        if ( !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
> > +        {
> > +            mfn_t new_vcpu_info_mfn =3D cd_vcpu->vcpu_info_mfn;
> > +
> > +            /* Allocate & map the page for it if it hasn't been alread=
y */
> > +            if ( mfn_eq(new_vcpu_info_mfn, INVALID_MFN) )
> > +            {
> > +                gfn_t gfn =3D mfn_to_gfn(d, vcpu_info_mfn);
> > +                unsigned long gfn_l =3D gfn_x(gfn);
> > +                struct page_info *page;
> > +
> > +                if ( !(page =3D alloc_domheap_page(cd, 0)) )
> > +                    return -ENOMEM;
> > +
> > +                new_vcpu_info_mfn =3D page_to_mfn(page);
> > +                set_gpfn_from_mfn(mfn_x(new_vcpu_info_mfn), gfn_l);
> > +
> > +                ret =3D p2m->set_entry(p2m, gfn, new_vcpu_info_mfn,
> > +                                     PAGE_ORDER_4K, p2m_ram_rw,
> > +                                     p2m->default_access, -1);
> > +                if ( ret )
> > +                    return ret;
> > +
> > +                ret =3D map_vcpu_info(cd_vcpu, gfn_l,
> > +                                    PAGE_OFFSET(d_vcpu->vcpu_info));
> > +                if ( ret )
> > +                    return ret;
> > +            }
> > +
> > +            copy_domain_page(new_vcpu_info_mfn, vcpu_info_mfn);
> > +        }
> > +
> > +        /* Setup the vCPU runstate area */
> > +        if ( !guest_handle_is_null(runstate_guest(d_vcpu)) )
> > +        {
> > +            runstate_guest(cd_vcpu) =3D runstate_guest(d_vcpu);
> > +            vcpu_runstate_get(cd_vcpu, &runstate);
> > +            __copy_to_guest(runstate_guest(cd_vcpu), &runstate, 1);
>
> I just realized there's no need to copy the runstate area contents
> here, since they will get copied anyway in schedule_tail before
> resuming execution og cd_vcpu as long as runstate_guest is set.
>
> Note that the vcpu_info needs to be copied since it contains event
> channel info which is not unconditionally updated on context switch
> IIRC.

OK

>
> > +        }
> > +
> > +        /*
> > +         * TODO: to support VMs with PV interfaces copy additional
> > +         * settings here, such as PV timers.
> > +         */
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> > +static int fork_hap_allocation(struct domain *cd, struct domain *d)
> > +{
> > +    int rc;
> > +    bool preempted;
> > +    unsigned long mb =3D hap_get_allocation(d);
> > +
> > +    if ( mb =3D=3D hap_get_allocation(cd) )
> > +        return 0;
> > +
> > +    paging_lock(cd);
> > +    rc =3D hap_set_allocation(cd, mb << (20 - PAGE_SHIFT), &preempted)=
;
> > +    paging_unlock(cd);
> > +
> > +    return preempted ? -ERESTART : rc;
> > +}
> > +
> > +static void copy_tsc(struct domain *cd, struct domain *d)
> > +{
> > +    uint32_t tsc_mode;
> > +    uint32_t gtsc_khz;
> > +    uint32_t incarnation;
> > +    uint64_t elapsed_nsec;
> > +
> > +    tsc_get_info(d, &tsc_mode, &elapsed_nsec, &gtsc_khz, &incarnation)=
;
> > +    /* Don't bump incarnation on set */
> > +    tsc_set_info(cd, tsc_mode, elapsed_nsec, gtsc_khz, incarnation - 1=
);
> > +}
> > +
> > +static int copy_special_pages(struct domain *cd, struct domain *d)
> > +{
> > +    mfn_t new_mfn, old_mfn;
> > +    struct p2m_domain *p2m =3D p2m_get_hostp2m(cd);
> > +    static const unsigned int params[] =3D
> > +    {
> > +        HVM_PARAM_STORE_PFN,
> > +        HVM_PARAM_IOREQ_PFN,
> > +        HVM_PARAM_BUFIOREQ_PFN,
> > +        HVM_PARAM_CONSOLE_PFN
> > +    };
> > +    unsigned int i;
> > +    int rc;
> > +
> > +    for ( i =3D 0; i < ARRAY_SIZE(params); i++ )
> > +    {
> > +        p2m_type_t t;
> > +        uint64_t value =3D 0;
> > +        struct page_info *page;
> > +
> > +        if ( hvm_get_param(cd, params[i], &value) || !value )
>
> Don't you need to use d here instead of cd? You want to check whether
> the parent has this parameter set in order to copy it to the child I
> think.

Indeed, I probably made this error in one of the revisions when I
renamed the variable.

>
> With that:
>
> Reviewed-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>

Thanks,
Tamas


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 14:35:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 14:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLSq9-0002DF-8e; Mon, 06 Apr 2020 14:35:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=etk8=5W=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLSq7-0002DA-AP
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 14:35:03 +0000
X-Inumbo-ID: cc99845c-7813-11ea-83d8-bc764e2007e4
Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cc99845c-7813-11ea-83d8-bc764e2007e4;
 Mon, 06 Apr 2020 14:35:02 +0000 (UTC)
Received: by mail-ed1-x541.google.com with SMTP id de14so19480283edb.4
 for <xen-devel@lists.xenproject.org>; Mon, 06 Apr 2020 07:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=r6CtmB4j4V2k6M3wBOMBHNekQuJS84n0cWUZYh7Xr0s=;
 b=pdkdQ5URjzKugWUK7rOnvbHEaUCOEJXeYvpH3jkGjwv3zAkjCOLid1O5lPDqlfAhrl
 FheawOsD6wLlZI6bgbMmM579MLQqy5eXjkVO8BVXtFKPxagQCTqdg3CptY8ot2vk8CW1
 4yZogXe7f2uIMYGVprtEQZnVmpbqt77vyHw/2jAAcFb6jpRAnsP7Ac6RBhMQ9wxkrsv5
 3Y2okln5rTfDBGrYtxqSdSot+kSxlpUpwBdPAbvRcHxgae2LGVYw0gUbA8Zc1oAcruKZ
 H7WO8SxvltFZbISarudq56eGPMAVasZhrayHHox61ZbYn6dR1CUiGL3PKikWZkNGEAiE
 B17Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=r6CtmB4j4V2k6M3wBOMBHNekQuJS84n0cWUZYh7Xr0s=;
 b=DwImrMzPBAwtlXMeOT2g5JRnv94aFtnWQz4ZJZM4rNJvN3MoNeXecDpMvTt0I2Eyhg
 wAg4pLrvi8SoZ74SFmk+BlBeC5eExRtvwyjMVPoNUwxYjKdeUQHphikY4jAy5EFt6qag
 5JHKkKCHtll2PkzR4QLfjHW62DW64VKJGHSIFX3UR27lxCh3L+JzproEGjClhOmGKaM/
 xCgj40Uv47D7/eazJ5Q6IuDzEXdHQckZ4souQPN6sZRw0LnwMo2EvV9UYPk4NGMueydL
 1pLkSgbzxlVM6hCMeshlvBEjKjfLQ7x7eIDbXJt5Nx+08287aBbnWfl2E7UpWbM5PbHi
 AxIw==
X-Gm-Message-State: AGi0PuYTVBINe+NwEPuLRUWmQ0HG6gJa59UQL0OzorBAxXtsLDVMTfbX
 ug8VNIflwYVLINH5F/68WJs=
X-Google-Smtp-Source: APiQypKcJbxoUZFcZkGGrcOhxkkoYgyDyAYDNNzeMEuP8jE+elB+gIFwl7Rnnr6glCfhHrKy1rzmFw==
X-Received: by 2002:aa7:c609:: with SMTP id h9mr19021258edq.93.1586183701711; 
 Mon, 06 Apr 2020 07:35:01 -0700 (PDT)
Received: from CBGR90WXYV0 (54-240-197-238.amazon.com. [54.240.197.238])
 by smtp.gmail.com with ESMTPSA id t25sm2427160edi.11.2020.04.06.07.35.00
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 06 Apr 2020 07:35:01 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Anthony PERARD'" <anthony.perard@citrix.com>,
	<qemu-devel@nongnu.org>
References: <20200406105954.GT4088@perard.uk.xensource.com>
 <20200406140217.1441858-1-anthony.perard@citrix.com>
In-Reply-To: <20200406140217.1441858-1-anthony.perard@citrix.com>
Subject: RE: [PATCH v2 for-5.0] xen-block: Fix double qlist remove and request
 leak
Date: Mon, 6 Apr 2020 15:34:59 +0100
Message-ID: <002901d60c20$8dcc94d0$a965be70$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQId5Ykq0Zul8aMjLjRNg1HUybzDSQHmJUNIp81CgpA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Kevin Wolf' <kwolf@redhat.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>, qemu-block@nongnu.org,
 qemu-stable@nongnu.org, 'Max Reitz' <mreitz@redhat.com>,
 'Stefan Hajnoczi' <stefanha@redhat.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Anthony PERARD <anthony.perard@citrix.com>
> Sent: 06 April 2020 15:02
> To: qemu-devel@nongnu.org
> Cc: qemu-stable@nongnu.org; Anthony PERARD <anthony.perard@citrix.com>; Stefano Stabellini
> <sstabellini@kernel.org>; Paul Durrant <paul@xen.org>; Stefan Hajnoczi <stefanha@redhat.com>; Kevin
> Wolf <kwolf@redhat.com>; Max Reitz <mreitz@redhat.com>; xen-devel@lists.xenproject.org; qemu-
> block@nongnu.org
> Subject: [PATCH v2 for-5.0] xen-block: Fix double qlist remove and request leak
> 
> Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
> remove") revealed that a request was removed twice from a list, once
> in xen_block_finish_request() and a second time in
> xen_block_release_request() when both function are called from
> xen_block_complete_aio(). But also, the `requests_inflight' counter is
> decreased twice, and thus became negative.
> 
> This is a bug that was introduced in bfd0d6366043

NIT: I guess you should quote the patch title here as well.

> , where a `finished'
> list was removed.
> 
> That commit also introduced a leak of request in xen_block_do_aio().
> That function calls xen_block_finish_request() but the request is
> never released after that.
> 
> To fix both issue, we do two changes:
> - we squash finish_request() and release_request() together as we want
>   to remove a request from 'inflight' list to add it to 'freelist'.
> - before releasing a request, we need to let now the result to the
>   other end,

"we need to let the other end know the result"

> thus we should call xen_block_send_response() before
>   releasing a request.
> 
> The first change fix the double QLIST_REMOVE() as we remove the extra

s/fix/fixes

> call. The second change makes the leak go away because if we want to
> call finish_request(), we need to call a function that do all of

s/do/does

> finish, send response, and release.
> 
> Fixes: bfd0d6366043 ("xen-block: improve response latency")
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

The code looks ok, so with the cosmetic fixes...

Reviewed-by: Paul Durrant <paul@xen.org>



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 15:20:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 15:20:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLTYC-0006Bu-Cp; Mon, 06 Apr 2020 15:20:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=rOh1=5W=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jLTYB-0006Bl-2o
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 15:20:35 +0000
X-Inumbo-ID: 259c7fcc-781a-11ea-b4f4-bc764e2007e4
Received: from mga07.intel.com (unknown [134.134.136.100])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 259c7fcc-781a-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 15:20:28 +0000 (UTC)
IronPort-SDR: 5Ytmwc35Ff1HNhDdbajRk2vpL68TBqYP5rBDztSeYXeZB9ntEENuzEsq0nWbop99vh/5Yd4s4v
 Rp18rsf7Savw==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 06 Apr 2020 08:20:28 -0700
IronPort-SDR: C1kEkknVL+EwGT4VssxJpsPEQS+PS07Nltr3u13rfjHwpSma1aBBw79siZXBFXG0oT2oKJJBAV
 l/Jwj32/Cmgw==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,351,1580803200"; d="scan'208";a="269107418"
Received: from jreyna-mobl.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.25.73])
 by orsmga002.jf.intel.com with ESMTP; 06 Apr 2020 08:20:25 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v14 1/3] xen/mem_sharing: VM forking
Date: Mon,  6 Apr 2020 08:20:03 -0700
Message-Id: <423e48743b969f2fe65c1101e32cc1c958912c99.1586185752.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <cover.1586185752.git.tamas.lengyel@intel.com>
References: <cover.1586185752.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Tamas K Lengyel <tamas@tklengyel.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

VM forking is the process of creating a domain with an empty memory space and a
parent domain specified from which to populate the memory when necessary. For
the new domain to be functional the VM state is copied over as part of the fork
operation (HVM params, hap allocation, etc).

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
---
v14: constify some function inputs
     minor fixes pointed out by Roger
---
 xen/arch/x86/domain.c             |  13 ++
 xen/arch/x86/hvm/hvm.c            |   4 +-
 xen/arch/x86/mm/hap/hap.c         |   3 +-
 xen/arch/x86/mm/mem_sharing.c     | 342 ++++++++++++++++++++++++++++++
 xen/arch/x86/mm/p2m.c             |   9 +-
 xen/include/asm-arm/page.h        |   1 +
 xen/include/asm-x86/hap.h         |   1 +
 xen/include/asm-x86/hvm/hvm.h     |   2 +
 xen/include/asm-x86/mem_sharing.h |  18 ++
 xen/include/asm-x86/page.h        |   1 +
 xen/include/public/memory.h       |   5 +
 xen/include/xen/sched.h           |   1 +
 12 files changed, 395 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 683bc619aa..a008d7df1c 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2211,6 +2211,19 @@ int domain_relinquish_resources(struct domain *d)
             ret = relinquish_shared_pages(d);
             if ( ret )
                 return ret;
+
+            /*
+             * If the domain is forked, decrement the parent's pause count
+             * and release the domain.
+             */
+            if ( mem_sharing_is_fork(d) )
+            {
+                struct domain *parent = d->parent;
+
+                d->parent = NULL;
+                domain_unpause(parent);
+                put_domain(parent);
+            }
         }
 #endif
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a3d115b650..304b3d1562 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1917,7 +1917,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
     }
 #endif
 
-    /* Spurious fault? PoD and log-dirty also take this path. */
+    /* Spurious fault? PoD, log-dirty and VM forking also take this path. */
     if ( p2m_is_ram(p2mt) )
     {
         rc = 1;
@@ -4377,7 +4377,7 @@ static int hvm_allow_get_param(struct domain *d,
     return rc;
 }
 
-static int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value)
+int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value)
 {
     int rc;
 
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index a6d5e39b02..814d0c3253 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -321,8 +321,7 @@ static void hap_free_p2m_page(struct domain *d, struct page_info *pg)
 }
 
 /* Return the size of the pool, rounded up to the nearest MB */
-static unsigned int
-hap_get_allocation(struct domain *d)
+unsigned int hap_get_allocation(struct domain *d)
 {
     unsigned int pg = d->arch.paging.hap.total_pages
         + d->arch.paging.hap.p2m_pages;
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index f49f27a3ef..64cd706e5a 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -22,6 +22,7 @@
 
 #include <xen/types.h>
 #include <xen/domain_page.h>
+#include <xen/event.h>
 #include <xen/spinlock.h>
 #include <xen/rwlock.h>
 #include <xen/mm.h>
@@ -36,6 +37,8 @@
 #include <asm/altp2m.h>
 #include <asm/atomic.h>
 #include <asm/event.h>
+#include <asm/hap.h>
+#include <asm/hvm/hvm.h>
 #include <xsm/xsm.h>
 
 #include "mm-locks.h"
@@ -1443,6 +1446,309 @@ static inline int mem_sharing_control(struct domain *d, bool enable)
     return 0;
 }
 
+/*
+ * Forking a page only gets called when the VM faults due to no entry being
+ * in the EPT for the access. Depending on the type of access we either
+ * populate the physmap with a shared entry for read-only access or
+ * fork the page if its a write access.
+ *
+ * The client p2m is already locked so we only need to lock
+ * the parent's here.
+ */
+int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
+{
+    int rc = -ENOENT;
+    shr_handle_t handle;
+    struct domain *parent = d->parent;
+    struct p2m_domain *p2m;
+    unsigned long gfn_l = gfn_x(gfn);
+    mfn_t mfn, new_mfn;
+    p2m_type_t p2mt;
+    struct page_info *page;
+
+    if ( !mem_sharing_is_fork(d) )
+        return -ENOENT;
+
+    if ( !unsharing )
+    {
+        /* For read-only accesses we just add a shared entry to the physmap */
+        while ( parent )
+        {
+            if ( !(rc = nominate_page(parent, gfn, 0, &handle)) )
+                break;
+
+            parent = parent->parent;
+        }
+
+        if ( !rc )
+        {
+            /* The client's p2m is already locked */
+            p2m = p2m_get_hostp2m(parent);
+
+            p2m_lock(p2m);
+            rc = add_to_physmap(parent, gfn_l, handle, d, gfn_l, false);
+            p2m_unlock(p2m);
+
+            if ( !rc )
+                return 0;
+        }
+    }
+
+    /*
+     * If it's a write access (ie. unsharing) or if adding a shared entry to
+     * the physmap failed we'll fork the page directly.
+     */
+    p2m = p2m_get_hostp2m(d);
+    parent = d->parent;
+
+    while ( parent )
+    {
+        mfn = get_gfn_query(parent, gfn_l, &p2mt);
+
+        /* We can't fork grant memory from the parent, only regular ram */
+        if ( mfn_valid(mfn) && p2m_is_ram(p2mt) )
+            break;
+
+        put_gfn(parent, gfn_l);
+        parent = parent->parent;
+    }
+
+    if ( !parent )
+        return -ENOENT;
+
+    if ( !(page = alloc_domheap_page(d, 0)) )
+    {
+        put_gfn(parent, gfn_l);
+        return -ENOMEM;
+    }
+
+    new_mfn = page_to_mfn(page);
+    copy_domain_page(new_mfn, mfn);
+    set_gpfn_from_mfn(mfn_x(new_mfn), gfn_l);
+
+    put_gfn(parent, gfn_l);
+
+    return p2m->set_entry(p2m, gfn, new_mfn, PAGE_ORDER_4K, p2m_ram_rw,
+                          p2m->default_access, -1);
+}
+
+static int bring_up_vcpus(struct domain *cd, struct domain *d)
+{
+    unsigned int i;
+    int ret = -EINVAL;
+
+    if ( d->max_vcpus != cd->max_vcpus ||
+        (ret = cpupool_move_domain(cd, d->cpupool)) )
+        return ret;
+
+    for ( i = 0; i < cd->max_vcpus; i++ )
+    {
+        if ( !d->vcpu[i] || cd->vcpu[i] )
+            continue;
+
+        if ( !vcpu_create(cd, i) )
+            return -EINVAL;
+    }
+
+    domain_update_node_affinity(cd);
+    return 0;
+}
+
+static int copy_vcpu_settings(struct domain *cd, const struct domain *d)
+{
+    unsigned int i;
+    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
+    int ret = -EINVAL;
+
+    for ( i = 0; i < cd->max_vcpus; i++ )
+    {
+        const struct vcpu *d_vcpu = d->vcpu[i];
+        struct vcpu *cd_vcpu = cd->vcpu[i];
+        mfn_t vcpu_info_mfn;
+
+        if ( !d_vcpu || !cd_vcpu )
+            continue;
+
+        /* Copy & map in the vcpu_info page if the guest uses one */
+        vcpu_info_mfn = d_vcpu->vcpu_info_mfn;
+        if ( !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
+        {
+            mfn_t new_vcpu_info_mfn = cd_vcpu->vcpu_info_mfn;
+
+            /* Allocate & map the page for it if it hasn't been already */
+            if ( mfn_eq(new_vcpu_info_mfn, INVALID_MFN) )
+            {
+                gfn_t gfn = mfn_to_gfn(d, vcpu_info_mfn);
+                unsigned long gfn_l = gfn_x(gfn);
+                struct page_info *page;
+
+                if ( !(page = alloc_domheap_page(cd, 0)) )
+                    return -ENOMEM;
+
+                new_vcpu_info_mfn = page_to_mfn(page);
+                set_gpfn_from_mfn(mfn_x(new_vcpu_info_mfn), gfn_l);
+
+                ret = p2m->set_entry(p2m, gfn, new_vcpu_info_mfn,
+                                     PAGE_ORDER_4K, p2m_ram_rw,
+                                     p2m->default_access, -1);
+                if ( ret )
+                    return ret;
+
+                ret = map_vcpu_info(cd_vcpu, gfn_l,
+                                    PAGE_OFFSET(d_vcpu->vcpu_info));
+                if ( ret )
+                    return ret;
+            }
+
+            copy_domain_page(new_vcpu_info_mfn, vcpu_info_mfn);
+        }
+
+        /*
+         * TODO: to support VMs with PV interfaces copy additional
+         * settings here, such as PV timers.
+         */
+    }
+
+    return 0;
+}
+
+static int fork_hap_allocation(struct domain *cd, struct domain *d)
+{
+    int rc;
+    bool preempted;
+    unsigned long mb = hap_get_allocation(d);
+
+    if ( mb == hap_get_allocation(cd) )
+        return 0;
+
+    paging_lock(cd);
+    rc = hap_set_allocation(cd, mb << (20 - PAGE_SHIFT), &preempted);
+    paging_unlock(cd);
+
+    return preempted ? -ERESTART : rc;
+}
+
+static void copy_tsc(struct domain *cd, struct domain *d)
+{
+    uint32_t tsc_mode;
+    uint32_t gtsc_khz;
+    uint32_t incarnation;
+    uint64_t elapsed_nsec;
+
+    tsc_get_info(d, &tsc_mode, &elapsed_nsec, &gtsc_khz, &incarnation);
+    /* Don't bump incarnation on set */
+    tsc_set_info(cd, tsc_mode, elapsed_nsec, gtsc_khz, incarnation - 1);
+}
+
+static int copy_special_pages(struct domain *cd, struct domain *d)
+{
+    mfn_t new_mfn, old_mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
+    static const unsigned int params[] =
+    {
+        HVM_PARAM_STORE_PFN,
+        HVM_PARAM_IOREQ_PFN,
+        HVM_PARAM_BUFIOREQ_PFN,
+        HVM_PARAM_CONSOLE_PFN
+    };
+    unsigned int i;
+    int rc;
+
+    for ( i = 0; i < ARRAY_SIZE(params); i++ )
+    {
+        p2m_type_t t;
+        uint64_t value = 0;
+        struct page_info *page;
+
+        if ( hvm_get_param(d, params[i], &value) || !value )
+            continue;
+
+        old_mfn = get_gfn_query_unlocked(d, value, &t);
+        new_mfn = get_gfn_query_unlocked(cd, value, &t);
+
+        /* Allocate the page and map it in if it's not present */
+        if ( mfn_eq(new_mfn, INVALID_MFN) )
+        {
+            if ( !(page = alloc_domheap_page(cd, 0)) )
+                return -ENOMEM;
+
+            new_mfn = page_to_mfn(page);
+            set_gpfn_from_mfn(mfn_x(new_mfn), value);
+
+            rc = p2m->set_entry(p2m, _gfn(value), new_mfn, PAGE_ORDER_4K,
+                                p2m_ram_rw, p2m->default_access, -1);
+            if ( rc )
+                return rc;
+        }
+
+        copy_domain_page(new_mfn, old_mfn);
+    }
+
+    old_mfn = _mfn(virt_to_mfn(d->shared_info));
+    new_mfn = _mfn(virt_to_mfn(cd->shared_info));
+    copy_domain_page(new_mfn, old_mfn);
+
+    return 0;
+}
+
+static int copy_settings(struct domain *cd, struct domain *d)
+{
+    int rc;
+
+    if ( (rc = copy_vcpu_settings(cd, d)) )
+        return rc;
+
+    if ( (rc = hvm_copy_context_and_params(cd, d)) )
+        return rc;
+
+    if ( (rc = copy_special_pages(cd, d)) )
+        return rc;
+
+    copy_tsc(cd, d);
+
+    return rc;
+}
+
+static int fork(struct domain *cd, struct domain *d)
+{
+    int rc = -EBUSY;
+
+    if ( !cd->controller_pause_count )
+        return rc;
+
+    if ( !cd->parent )
+    {
+        if ( !get_domain(d) )
+        {
+            ASSERT_UNREACHABLE();
+            return -EBUSY;
+        }
+
+        domain_pause(d);
+        cd->max_pages = d->max_pages;
+        cd->parent = d;
+    }
+
+    /* This is preemptible so it's the first to get done */
+    if ( (rc = fork_hap_allocation(cd, d)) )
+        goto done;
+
+    if ( (rc = bring_up_vcpus(cd, d)) )
+        goto done;
+
+    rc = copy_settings(cd, d);
+
+ done:
+    if ( rc && rc != -ERESTART )
+    {
+        domain_unpause(d);
+        put_domain(d);
+        cd->parent = NULL;
+    }
+
+    return rc;
+}
+
 int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 {
     int rc;
@@ -1697,6 +2003,42 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
         rc = debug_gref(d, mso.u.debug.u.gref);
         break;
 
+    case XENMEM_sharing_op_fork:
+    {
+        struct domain *pd;
+
+        rc = -EINVAL;
+        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[2] )
+            goto out;
+
+        rc = rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_domain,
+                                               &pd);
+        if ( rc )
+            goto out;
+
+        rc = -EINVAL;
+        if ( pd->max_vcpus != d->max_vcpus )
+        {
+            rcu_unlock_domain(pd);
+            goto out;
+        }
+
+        if ( !mem_sharing_enabled(pd) && (rc = mem_sharing_control(pd, true)) )
+        {
+            rcu_unlock_domain(pd);
+            goto out;
+        }
+
+        rc = fork(d, pd);
+
+        if ( rc == -ERESTART )
+            rc = hypercall_create_continuation(__HYPERVISOR_memory_op,
+                                               "lh", XENMEM_sharing_op,
+                                               arg);
+        rcu_unlock_domain(pd);
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3c052de606..b8727e267d 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -509,6 +509,12 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn_l,
 
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order, NULL);
 
+    /* Check if we need to fork the page */
+    if ( (q & P2M_ALLOC) && p2m_is_hole(*t) &&
+         !mem_sharing_fork_page(p2m->domain, gfn, q & P2M_UNSHARE) )
+        mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order, NULL);
+
+    /* Check if we need to unshare the page */
     if ( (q & P2M_UNSHARE) && p2m_is_shared(*t) )
     {
         ASSERT(p2m_is_hostp2m(p2m));
@@ -588,7 +594,8 @@ struct page_info *p2m_get_page_from_gfn(
             return page;
 
         /* Error path: not a suitable GFN at all */
-        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_pod(*t) )
+        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_pod(*t) &&
+             !mem_sharing_is_fork(p2m->domain) )
             return NULL;
     }
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 37e1d9aadb..4ea8e97247 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -12,6 +12,7 @@
 #define PADDR_BITS              40
 #endif
 #define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
+#define PAGE_OFFSET(ptr)        ((vaddr_t)(ptr) & ~PAGE_MASK)
 
 #define VADDR_BITS              32
 #define VADDR_MASK              (~0UL)
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index b94bfb4ed0..1bf07e49fe 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -45,6 +45,7 @@ int   hap_track_dirty_vram(struct domain *d,
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
 int hap_set_allocation(struct domain *d, unsigned int pages, bool *preempted);
+unsigned int hap_get_allocation(struct domain *d);
 
 #endif /* XEN_HAP_H */
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index b007b2e343..f283c7d187 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -336,6 +336,8 @@ unsigned long hvm_cr4_guest_valid_bits(const struct domain *d, bool restore);
 
 int hvm_copy_context_and_params(struct domain *src, struct domain *dst);
 
+int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value);
+
 #ifdef CONFIG_HVM
 
 #define hvm_get_guest_tsc(v) hvm_get_guest_tsc_fixed(v, 0)
diff --git a/xen/include/asm-x86/mem_sharing.h b/xen/include/asm-x86/mem_sharing.h
index 53b7929d0e..cf7a12f4d2 100644
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -77,6 +77,14 @@ static inline int mem_sharing_unshare_page(struct domain *d,
     return rc;
 }
 
+static inline bool mem_sharing_is_fork(const struct domain *d)
+{
+    return d->parent;
+}
+
+int mem_sharing_fork_page(struct domain *d, gfn_t gfn,
+                          bool unsharing);
+
 /*
  * If called by a foreign domain, possible errors are
  *   -EBUSY -> ring full
@@ -130,6 +138,16 @@ static inline int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
     return -EOPNOTSUPP;
 }
 
+static inline bool mem_sharing_is_fork(const struct domain *d)
+{
+    return false;
+}
+
+static inline int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool lock)
+{
+    return -EOPNOTSUPP;
+}
+
 #endif
 
 #endif /* __MEM_SHARING_H__ */
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index c98d8f5ede..eb73a0fc23 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -10,6 +10,7 @@
 #define PAGE_SIZE           (_AC(1,L) << PAGE_SHIFT)
 #define PAGE_MASK           (~(PAGE_SIZE-1))
 #define PAGE_FLAG_MASK      (~0)
+#define PAGE_OFFSET(ptr)    ((unsigned long)(ptr) & ~PAGE_MASK)
 
 #define PAGE_ORDER_4K       0
 #define PAGE_ORDER_2M       9
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 126d0ff06e..5ee4e0da12 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -482,6 +482,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_access_op_t);
 #define XENMEM_sharing_op_add_physmap       6
 #define XENMEM_sharing_op_audit             7
 #define XENMEM_sharing_op_range_share       8
+#define XENMEM_sharing_op_fork              9
 
 #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
 #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
@@ -532,6 +533,10 @@ struct xen_mem_sharing_op {
                 uint32_t gref;     /* IN: gref to debug         */
             } u;
         } debug;
+        struct mem_sharing_op_fork {      /* OP_FORK */
+            domid_t parent_domain;        /* IN: parent's domain id */
+            uint16_t pad[3];              /* Must be set to 0 */
+        } fork;
     } u;
 };
 typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 4b78291d51..195e7ee583 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -481,6 +481,7 @@ struct domain
     /* Memory sharing support */
 #ifdef CONFIG_MEM_SHARING
     struct vm_event_domain *vm_event_share;
+    struct domain *parent; /* VM fork parent */
 #endif
     /* Memory paging support */
 #ifdef CONFIG_HAS_MEM_PAGING
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 15:20:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 15:20:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLTY7-0006Bd-3p; Mon, 06 Apr 2020 15:20:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=rOh1=5W=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jLTY6-0006BY-9I
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 15:20:30 +0000
X-Inumbo-ID: 24811b48-781a-11ea-b58d-bc764e2007e4
Received: from mga07.intel.com (unknown [134.134.136.100])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 24811b48-781a-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 15:20:27 +0000 (UTC)
IronPort-SDR: XIiqsisxI72wJZ/PRUgpGkHiabbwWmRrhjgycE8n0ztIguqcPfPj02yW2YflPy0MoIPkFUvjLT
 2CVA4nG6GKHA==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 06 Apr 2020 08:20:25 -0700
IronPort-SDR: 9IozPP4DkbW6YrY4kMONlX7Ploi5w5o9SNlEnFhv0XLkG6GA35I26le7dp/Lifw4qEgKUxyD88
 WOvGzEFpf1yA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,351,1580803200"; d="scan'208";a="269107409"
Received: from jreyna-mobl.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.25.73])
 by orsmga002.jf.intel.com with ESMTP; 06 Apr 2020 08:20:24 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v14 0/3] VM forking
Date: Mon,  6 Apr 2020 08:20:02 -0700
Message-Id: <cover.1586185752.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Tamas K Lengyel <tamas@tklengyel.com>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>, Julien Grall <julien@xen.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The following series implements VM forking for Intel HVM guests to allow for
the fast creation of identical VMs without the assosciated high startup costs
of booting or restoring the VM from a savefile.

JIRA issue: https://xenproject.atlassian.net/browse/XEN-89

The fork operation is implemented as part of the "xl fork-vm" command:
    xl fork-vm -C <config> -Q <qemu-save-file> -m <max-vcpus> <parent_domid>
    
By default a fully functional fork is created. The user is in charge however to
create the appropriate config file for the fork and to generate the QEMU save
file before the fork-vm call is made. The config file needs to give the
fork a new name at minimum but other settings may also require changes. Certain
settings in the config file of both the parent and the fork have to be set to
default. Details are documented.

The interface also allows to split the forking into two steps:
    xl fork-vm --launch-dm no \
               -m <max-vcpus> \
               -p <parent_domid>
    xl fork-vm --launch-dm late \
               -C <config_file_for_fork> \
               -Q <qemu_save_file> \
               <fork_domid>

The split creation model is useful when the VM needs to be created as fast as
possible. The forked VM can be unpaused without the device model being launched
to be monitored and accessed via VMI. Note however that without its device
model running (depending on what is executing in the VM) it is bound to
misbehave or even crash when its trying to access devices that would be
emulated by QEMU. We anticipate that for certain use-cases this would be an
acceptable situation, in case for example when fuzzing is performed of code
segments that don't access such devices.

Launching the device model requires the QEMU Xen savefile to be generated
manually from the parent VM. This can be accomplished simply by connecting to
its QMP socket and issuing the "xen-save-devices-state" command. For example
using the standard tool socat these commands can be used to generate the file:
    socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-<parent_domid>
    { "execute": "qmp_capabilities" }
    { "execute": "xen-save-devices-state", \
        "arguments": { "filename": "/path/to/save/qemu_state", \
                        "live": false} }

At runtime the forked VM starts running with an empty p2m which gets lazily
populated when the VM generates EPT faults, similar to how altp2m views are
populated. If the memory access is a read-only access, the p2m entry is
populated with a memory shared entry with its parent. For write memory accesses
or in case memory sharing wasn't possible (for example in case a reference is
held by a third party), a new page is allocated and the page contents are
copied over from the parent VM. Forks can be further forked if needed, thus
allowing for further memory savings.

A VM fork reset hypercall is also added that allows the fork to be reset to the
state it was just after a fork, also accessible via xl:
    xl fork-vm --fork-reset -p <fork_domid>

This is an optimization for cases where the forks are very short-lived and run
without a device model, so resetting saves some time compared to creating a
brand new fork provided the fork has not aquired a lot of memory. If the fork
has a lot of memory deduplicated it is likely going to be faster to create a
new fork from scratch and asynchronously destroying the old one.

The series has been tested with Windows VMs and functions as expected. Linux
VMs when forked from a running VM will have a frozen VNC screen. Linux VMs at
this time can only be forked with a working device model when the parent VM was
restored from a snapshot using "xl restore -p". This is a known limitation.
Also note that PVHVM/PVH Linux guests have not been tested. Forking most likely
works but PV devices and drivers would require additional wiring to set things
up properly since the guests are unaware of the forking taking place, unlike
the save/restore routine where the guest is made aware of the procedure.

Forking time has been measured to be 0.0007s, device model launch to be around
1s depending largely on the number of devices being emulated. Fork resets have
been measured to be 0.0001s under the optimal circumstances.

New in v14:
    minor adjustments

Patch 1 implements the VM fork
Patch 2 implements fork reset operation
Patch 3 adds the toolstack-side code implementing VM forking and reset

Tamas K Lengyel (3):
  xen/mem_sharing: VM forking
  x86/mem_sharing: reset a fork
  xen/tools: VM forking toolstack side

 docs/man/xl.1.pod.in              |  44 ++++
 tools/libxc/include/xenctrl.h     |  13 +
 tools/libxc/xc_memshr.c           |  22 ++
 tools/libxl/libxl.h               |  11 +
 tools/libxl/libxl_create.c        | 361 ++++++++++++++-----------
 tools/libxl/libxl_dm.c            |   2 +-
 tools/libxl/libxl_dom.c           |  43 ++-
 tools/libxl/libxl_internal.h      |   7 +
 tools/libxl/libxl_types.idl       |   1 +
 tools/libxl/libxl_x86.c           |  41 +++
 tools/xl/Makefile                 |   2 +-
 tools/xl/xl.h                     |   5 +
 tools/xl/xl_cmdtable.c            |  15 ++
 tools/xl/xl_forkvm.c              | 147 +++++++++++
 tools/xl/xl_vmcontrol.c           |  14 +
 xen/arch/x86/domain.c             |  13 +
 xen/arch/x86/hvm/hvm.c            |   4 +-
 xen/arch/x86/mm/hap/hap.c         |   3 +-
 xen/arch/x86/mm/mem_sharing.c     | 419 ++++++++++++++++++++++++++++++
 xen/arch/x86/mm/p2m.c             |   9 +-
 xen/include/asm-arm/page.h        |   1 +
 xen/include/asm-x86/hap.h         |   1 +
 xen/include/asm-x86/hvm/hvm.h     |   2 +
 xen/include/asm-x86/mem_sharing.h |  18 ++
 xen/include/asm-x86/page.h        |   1 +
 xen/include/public/memory.h       |   6 +
 xen/include/xen/sched.h           |   1 +
 27 files changed, 1035 insertions(+), 171 deletions(-)
 create mode 100644 tools/xl/xl_forkvm.c

-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 15:20:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 15:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLTYH-0006Cg-LR; Mon, 06 Apr 2020 15:20:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=rOh1=5W=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jLTYG-0006CW-34
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 15:20:40 +0000
X-Inumbo-ID: 269a11f0-781a-11ea-b58d-bc764e2007e4
Received: from mga07.intel.com (unknown [134.134.136.100])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 269a11f0-781a-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 15:20:30 +0000 (UTC)
IronPort-SDR: GhH0YJG6sfeZhz6iYWXyp1Q5S5oWMWFeaBlVhPbu67Kjnwg2F5GZrmcvhPrMiHqkjR5hEK5WHu
 pPiDi9OR1tvQ==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 06 Apr 2020 08:20:29 -0700
IronPort-SDR: IGomPIhvUSQNWJQ7dXK23HNYO8qZVxDtB0mJ/W8oKndbVv65oLeSLeKn0pCQbDiDNPk+iMPm15
 CVRiYzN44ixw==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,351,1580803200"; d="scan'208";a="269107424"
Received: from jreyna-mobl.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.25.73])
 by orsmga002.jf.intel.com with ESMTP; 06 Apr 2020 08:20:28 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v14 2/3] x86/mem_sharing: reset a fork
Date: Mon,  6 Apr 2020 08:20:04 -0700
Message-Id: <44e660066f03a39354dbe5d328f30779b8ebc935.1586185752.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <cover.1586185752.git.tamas.lengyel@intel.com>
References: <cover.1586185752.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Implement hypercall that allows a fork to shed all memory that got allocated
for it during its execution and re-load its vCPU context from the parent VM.
This allows the forked VM to reset into the same state the parent VM is in a
faster way then creating a new fork would be. Measurements show about a 2x
speedup during normal fuzzing operations. Performance may vary depending how
much memory got allocated for the forked VM. If it has been completely
deduplicated from the parent VM then creating a new fork would likely be more
performant.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
v12: remove continuation & add comment back
     address style issues pointed out by Jan
---
 xen/arch/x86/mm/mem_sharing.c | 77 +++++++++++++++++++++++++++++++++++
 xen/include/public/memory.h   |  1 +
 2 files changed, 78 insertions(+)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 64cd706e5a..85951b7bea 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1749,6 +1749,61 @@ static int fork(struct domain *cd, struct domain *d)
     return rc;
 }
 
+/*
+ * The fork reset operation is intended to be used on short-lived forks only.
+ * There is no hypercall continuation operation implemented for this reason.
+ * For forks that obtain a larger memory footprint it is likely going to be
+ * more performant to create a new fork instead of resetting an existing one.
+ *
+ * TODO: In case this hypercall would become useful on forks with larger memory
+ * footprints the hypercall continuation should be implemented (or if this
+ * feature needs to be become "stable").
+ */
+static int mem_sharing_fork_reset(struct domain *d, struct domain *pd)
+{
+    int rc;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    struct page_info *page, *tmp;
+
+    domain_pause(d);
+
+    /* need recursive lock because we will free pages */
+    spin_lock_recursive(&d->page_alloc_lock);
+    page_list_for_each_safe(page, tmp, &d->page_list)
+    {
+        p2m_type_t p2mt;
+        p2m_access_t p2ma;
+        mfn_t mfn = page_to_mfn(page);
+        gfn_t gfn = mfn_to_gfn(d, mfn);
+
+        mfn = __get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
+                                    0, NULL, false);
+
+        /* only reset pages that are sharable */
+        if ( !p2m_is_sharable(p2mt) )
+            continue;
+
+        /* take an extra reference or just skip if can't for whatever reason */
+        if ( !get_page(page, d) )
+            continue;
+
+        /* forked memory is 4k, not splitting large pages so this must work */
+        rc = p2m->set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
+                            p2m_invalid, p2m_access_rwx, -1);
+        ASSERT(!rc);
+
+        put_page_alloc_ref(page);
+        put_page(page);
+    }
+    spin_unlock_recursive(&d->page_alloc_lock);
+
+    rc = copy_settings(d, pd);
+
+    domain_unpause(d);
+
+    return rc;
+}
+
 int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 {
     int rc;
@@ -2039,6 +2094,28 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
         break;
     }
 
+    case XENMEM_sharing_op_fork_reset:
+    {
+        struct domain *pd;
+
+        rc = -EINVAL;
+        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[2] )
+            goto out;
+
+        rc = -ENOSYS;
+        if ( !d->parent )
+            goto out;
+
+        rc = rcu_lock_live_remote_domain_by_id(d->parent->domain_id, &pd);
+        if ( rc )
+            goto out;
+
+        rc = mem_sharing_fork_reset(d, pd);
+
+        rcu_unlock_domain(pd);
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 5ee4e0da12..d36d64b8dc 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -483,6 +483,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_access_op_t);
 #define XENMEM_sharing_op_audit             7
 #define XENMEM_sharing_op_range_share       8
 #define XENMEM_sharing_op_fork              9
+#define XENMEM_sharing_op_fork_reset        10
 
 #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
 #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 15:20:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 15:20:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLTYM-0006ES-3s; Mon, 06 Apr 2020 15:20:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=rOh1=5W=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jLTYL-0006E7-2i
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 15:20:45 +0000
X-Inumbo-ID: 27aeaa10-781a-11ea-b4f4-bc764e2007e4
Received: from mga07.intel.com (unknown [134.134.136.100])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 27aeaa10-781a-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 15:20:32 +0000 (UTC)
IronPort-SDR: wj0O4nDzf0X2Y+TBIZXvUPlTXb1vY/eNvr86B+CPPz4Y0MeOjkDLVB6ugCF9zDUOMsglBhhqsi
 z1aTrlqYgayw==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 06 Apr 2020 08:20:30 -0700
IronPort-SDR: wjjx1A6vhpUoMOQL5BVde1kE96g0vtu/ThMj+xNP25jfVlHOkAE/pweGCFYFcVh4G21h+Vh62r
 ubeKK1BcMRrg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,351,1580803200"; d="scan'208";a="269107437"
Received: from jreyna-mobl.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.25.73])
 by orsmga002.jf.intel.com with ESMTP; 06 Apr 2020 08:20:29 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v14 3/3] xen/tools: VM forking toolstack side
Date: Mon,  6 Apr 2020 08:20:05 -0700
Message-Id: <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <cover.1586186121.git.tamas.lengyel@intel.com>
References: <cover.1586186121.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
 docs/man/xl.1.pod.in          |  44 +++++
 tools/libxc/include/xenctrl.h |  13 ++
 tools/libxc/xc_memshr.c       |  22 +++
 tools/libxl/libxl.h           |  11 ++
 tools/libxl/libxl_create.c    | 361 +++++++++++++++++++---------------
 tools/libxl/libxl_dm.c        |   2 +-
 tools/libxl/libxl_dom.c       |  43 +++-
 tools/libxl/libxl_internal.h  |   7 +
 tools/libxl/libxl_types.idl   |   1 +
 tools/libxl/libxl_x86.c       |  41 ++++
 tools/xl/Makefile             |   2 +-
 tools/xl/xl.h                 |   5 +
 tools/xl/xl_cmdtable.c        |  15 ++
 tools/xl/xl_forkvm.c          | 144 ++++++++++++++
 tools/xl/xl_vmcontrol.c       |  14 ++
 15 files changed, 559 insertions(+), 166 deletions(-)
 create mode 100644 tools/xl/xl_forkvm.c

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 09339282e6..59c03c6427 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -708,6 +708,50 @@ above).
 
 =back
 
+=item B<fork-vm> [I<OPTIONS>] I<domain-id>
+
+Create a fork of a running VM.  The domain will be paused after the operation
+and remains paused while forks of it exist.  Experimental and x86 only.
+Forks can only be made of domains with HAP enabled and on Intel hardware.  The
+parent domain must be created with the xl toolstack and its configuration must
+not manually define max_grant_frames, max_maptrack_frames or max_event_channels.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-p>
+
+Leave the fork paused after creating it.
+
+=item B<--launch-dm>
+
+Specify whether the device model (QEMU) should be launched for the fork. Late
+launch allows to start the device model for an already running fork.
+
+=item B<-C>
+
+The config file to use when launching the device model.  Currently required when
+launching the device model.  Most config settings MUST match the parent domain
+exactly, only change VM name, disk path and network configurations.
+
+=item B<-Q>
+
+The path to the qemu save file to use when launching the device model.  Currently
+required when launching the device model.
+
+=item B<--fork-reset>
+
+Perform a reset operation of an already running fork.  Note that resetting may
+be less performant then creating a new fork depending on how much memory the
+fork has deduplicated during its runtime.
+
+=item B<--max-vcpus>
+
+Specify the max-vcpus matching the parent domain when not launching the dm.
+
+=back
+
 =item B<sharing> [I<domain-id>]
 
 Display the number of shared pages for a specified domain. If no domain is
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 58fa931de1..631750a242 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2225,6 +2225,19 @@ int xc_memshr_range_share(xc_interface *xch,
                           uint64_t first_gfn,
                           uint64_t last_gfn);
 
+int xc_memshr_fork(xc_interface *xch,
+                   uint32_t source_domain,
+                   uint32_t client_domain);
+
+/*
+ * Note: this function is only intended to be used on short-lived forks that
+ * haven't yet aquired a lot of memory. In case the fork has a lot of memory
+ * it is likely more performant to create a new fork with xc_memshr_fork.
+ *
+ * With VMs that have a lot of memory this call may block for a long time.
+ */
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain);
+
 /* Debug calls: return the number of pages referencing the shared frame backing
  * the input argument. Should be one or greater.
  *
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index 97e2e6a8d9..d0e4ee225b 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -239,6 +239,28 @@ int xc_memshr_debug_gref(xc_interface *xch,
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_fork;
+    mso.u.fork.parent_domain = pdomid;
+
+    return xc_memshr_memop(xch, domid, &mso);
+}
+
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+    mso.op = XENMEM_sharing_op_fork_reset;
+
+    return xc_memshr_memop(xch, domid, &mso);
+}
+
 int xc_memshr_audit(xc_interface *xch)
 {
     xen_mem_sharing_op_t mso;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 71709dc585..088e81c78b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2666,6 +2666,17 @@ int libxl_psr_get_hw_info(libxl_ctx *ctx, libxl_psr_feat_type type,
                           unsigned int lvl, unsigned int *nr,
                           libxl_psr_hw_info **info);
 void libxl_psr_hw_info_list_free(libxl_psr_hw_info *list, unsigned int nr);
+
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                uint32_t domid,
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 #endif
 
 /* misc */
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e7cb2dbc2b..5705b6e3a5 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -538,12 +538,12 @@ out:
     return ret;
 }
 
-int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
-                       libxl__domain_build_state *state,
-                       uint32_t *domid, bool soft_reset)
+static int libxl__domain_make_xs_entries(libxl__gc *gc, libxl_domain_config *d_config,
+                                         libxl__domain_build_state *state,
+                                         uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, rc, nb_vm;
+    int rc, nb_vm;
     const char *dom_type;
     char *uuid_string;
     char *dom_path, *vm_path, *libxl_path;
@@ -555,9 +555,6 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     /* convenience aliases */
     libxl_domain_create_info *info = &d_config->c_info;
-    libxl_domain_build_info *b_info = &d_config->b_info;
-
-    assert(soft_reset || *domid == INVALID_DOMID);
 
     uuid_string = libxl__uuid2string(gc, info->uuid);
     if (!uuid_string) {
@@ -565,137 +562,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         goto out;
     }
 
-    if (!soft_reset) {
-        struct xen_domctl_createdomain create = {
-            .ssidref = info->ssidref,
-            .max_vcpus = b_info->max_vcpus,
-            .max_evtchn_port = b_info->event_channels,
-            .max_grant_frames = b_info->max_grant_frames,
-            .max_maptrack_frames = b_info->max_maptrack_frames,
-        };
-
-        if (info->type != LIBXL_DOMAIN_TYPE_PV) {
-            create.flags |= XEN_DOMCTL_CDF_hvm;
-            create.flags |=
-                libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
-            create.flags |=
-                libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
-        }
-
-        assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
-        LOG(DETAIL, "passthrough: %s",
-            libxl_passthrough_to_string(info->passthrough));
-
-        if (info->passthrough != LIBXL_PASSTHROUGH_DISABLED)
-            create.flags |= XEN_DOMCTL_CDF_iommu;
-
-        if (info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT)
-            create.iommu_opts |= XEN_DOMCTL_IOMMU_no_sharept;
-
-        /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
-        libxl_uuid_copy(ctx, (libxl_uuid *)&create.handle, &info->uuid);
-
-        ret = libxl__arch_domain_prepare_config(gc, d_config, &create);
-        if (ret < 0) {
-            LOGED(ERROR, *domid, "fail to get domain config");
-            rc = ERROR_FAIL;
-            goto out;
-        }
-
-        for (;;) {
-            uint32_t local_domid;
-            bool recent;
-
-            if (info->domid == RANDOM_DOMID) {
-                uint16_t v;
-
-                ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
-                if (ret < 0)
-                    break;
-
-                v &= DOMID_MASK;
-                if (!libxl_domid_valid_guest(v))
-                    continue;
-
-                local_domid = v;
-            } else {
-                local_domid = info->domid; /* May not be valid */
-            }
-
-            ret = xc_domain_create(ctx->xch, &local_domid, &create);
-            if (ret < 0) {
-                /*
-                 * If we generated a random domid and creation failed
-                 * because that domid already exists then simply try
-                 * again.
-                 */
-                if (errno == EEXIST && info->domid == RANDOM_DOMID)
-                    continue;
-
-                LOGED(ERROR, local_domid, "domain creation fail");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /* A new domain now exists */
-            *domid = local_domid;
-
-            rc = libxl__is_domid_recent(gc, local_domid, &recent);
-            if (rc)
-                goto out;
-
-            /* The domid is not recent, so we're done */
-            if (!recent)
-                break;
-
-            /*
-             * If the domid was specified then there's no point in
-             * trying again.
-             */
-            if (libxl_domid_valid_guest(info->domid)) {
-                LOGED(ERROR, local_domid, "domain id recently used");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /*
-             * The domain is recent and so cannot be used. Clear domid
-             * here since, if xc_domain_destroy() fails below there is
-             * little point calling it again in the error path.
-             */
-            *domid = INVALID_DOMID;
-
-            ret = xc_domain_destroy(ctx->xch, local_domid);
-            if (ret < 0) {
-                LOGED(ERROR, local_domid, "domain destroy fail");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /* The domain was successfully destroyed, so we can try again */
-        }
-
-        rc = libxl__arch_domain_save_config(gc, d_config, state, &create);
-        if (rc < 0)
-            goto out;
-    }
-
-    /*
-     * If soft_reset is set the the domid will have been valid on entry.
-     * If it was not set then xc_domain_create() should have assigned a
-     * valid value. Either way, if we reach this point, domid should be
-     * valid.
-     */
-    assert(libxl_domid_valid_guest(*domid));
-
-    ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
-    if (ret < 0) {
-        LOGED(ERROR, *domid, "domain move fail");
-        rc = ERROR_FAIL;
-        goto out;
-    }
-
-    dom_path = libxl__xs_get_dompath(gc, *domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         rc = ERROR_FAIL;
         goto out;
@@ -703,12 +570,12 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     vm_path = GCSPRINTF("/vm/%s", uuid_string);
     if (!vm_path) {
-        LOGD(ERROR, *domid, "cannot allocate create paths");
+        LOGD(ERROR, domid, "cannot allocate create paths");
         rc = ERROR_FAIL;
         goto out;
     }
 
-    libxl_path = libxl__xs_libxl_path(gc, *domid);
+    libxl_path = libxl__xs_libxl_path(gc, domid);
     if (!libxl_path) {
         rc = ERROR_FAIL;
         goto out;
@@ -719,10 +586,10 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     roperm[0].id = 0;
     roperm[0].perms = XS_PERM_NONE;
-    roperm[1].id = *domid;
+    roperm[1].id = domid;
     roperm[1].perms = XS_PERM_READ;
 
-    rwperm[0].id = *domid;
+    rwperm[0].id = domid;
     rwperm[0].perms = XS_PERM_NONE;
 
 retry_transaction:
@@ -740,7 +607,7 @@ retry_transaction:
                     noperm, ARRAY_SIZE(noperm));
 
     xs_write(ctx->xsh, t, GCSPRINTF("%s/vm", dom_path), vm_path, strlen(vm_path));
-    rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
+    rc = libxl__domain_rename(gc, domid, 0, info->name, t);
     if (rc)
         goto out;
 
@@ -830,7 +697,7 @@ retry_transaction:
 
     vm_list = libxl_list_vm(ctx, &nb_vm);
     if (!vm_list) {
-        LOGD(ERROR, *domid, "cannot get number of running guests");
+        LOGD(ERROR, domid, "cannot get number of running guests");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -854,7 +721,7 @@ retry_transaction:
             t = 0;
             goto retry_transaction;
         }
-        LOGED(ERROR, *domid, "domain creation ""xenstore transaction commit failed");
+        LOGED(ERROR, domid, "domain creation ""xenstore transaction commit failed");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -866,6 +733,155 @@ retry_transaction:
     return rc;
 }
 
+int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
+                       libxl__domain_build_state *state,
+                       uint32_t *domid, bool soft_reset)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret, rc;
+
+    /* convenience aliases */
+    libxl_domain_create_info *info = &d_config->c_info;
+    libxl_domain_build_info *b_info = &d_config->b_info;
+
+    assert(soft_reset || *domid == INVALID_DOMID);
+
+    if (!soft_reset) {
+        struct xen_domctl_createdomain create = {
+            .ssidref = info->ssidref,
+            .max_vcpus = b_info->max_vcpus,
+            .max_evtchn_port = b_info->event_channels,
+            .max_grant_frames = b_info->max_grant_frames,
+            .max_maptrack_frames = b_info->max_maptrack_frames,
+        };
+
+        if (info->type != LIBXL_DOMAIN_TYPE_PV) {
+            create.flags |= XEN_DOMCTL_CDF_hvm;
+            create.flags |=
+                libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+            create.flags |=
+                libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
+        }
+
+        assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
+        LOG(DETAIL, "passthrough: %s",
+            libxl_passthrough_to_string(info->passthrough));
+
+        if (info->passthrough != LIBXL_PASSTHROUGH_DISABLED)
+            create.flags |= XEN_DOMCTL_CDF_iommu;
+
+        if (info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT)
+            create.iommu_opts |= XEN_DOMCTL_IOMMU_no_sharept;
+
+        /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
+        libxl_uuid_copy(ctx, (libxl_uuid *)&create.handle, &info->uuid);
+
+        ret = libxl__arch_domain_prepare_config(gc, d_config, &create);
+        if (ret < 0) {
+            LOGED(ERROR, *domid, "fail to get domain config");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        for (;;) {
+            uint32_t local_domid;
+            bool recent;
+
+            if (info->domid == RANDOM_DOMID) {
+                uint16_t v;
+
+                ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
+                if (ret < 0)
+                    break;
+
+                v &= DOMID_MASK;
+                if (!libxl_domid_valid_guest(v))
+                    continue;
+
+                local_domid = v;
+            } else {
+                local_domid = info->domid; /* May not be valid */
+            }
+
+            ret = xc_domain_create(ctx->xch, &local_domid, &create);
+            if (ret < 0) {
+                /*
+                 * If we generated a random domid and creation failed
+                 * because that domid already exists then simply try
+                 * again.
+                 */
+                if (errno == EEXIST && info->domid == RANDOM_DOMID)
+                    continue;
+
+                LOGED(ERROR, local_domid, "domain creation fail");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* A new domain now exists */
+            *domid = local_domid;
+
+            rc = libxl__is_domid_recent(gc, local_domid, &recent);
+            if (rc)
+                goto out;
+
+            /* The domid is not recent, so we're done */
+            if (!recent)
+                break;
+
+            /*
+             * If the domid was specified then there's no point in
+             * trying again.
+             */
+            if (libxl_domid_valid_guest(info->domid)) {
+                LOGED(ERROR, local_domid, "domain id recently used");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /*
+             * The domain is recent and so cannot be used. Clear domid
+             * here since, if xc_domain_destroy() fails below there is
+             * little point calling it again in the error path.
+             */
+            *domid = INVALID_DOMID;
+
+            ret = xc_domain_destroy(ctx->xch, local_domid);
+            if (ret < 0) {
+                LOGED(ERROR, local_domid, "domain destroy fail");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* The domain was successfully destroyed, so we can try again */
+        }
+
+        rc = libxl__arch_domain_save_config(gc, d_config, state, &create);
+        if (rc < 0)
+            goto out;
+    }
+
+    /*
+     * If soft_reset is set the the domid will have been valid on entry.
+     * If it was not set then xc_domain_create() should have assigned a
+     * valid value. Either way, if we reach this point, domid should be
+     * valid.
+     */
+    assert(libxl_domid_valid_guest(*domid));
+
+    ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
+    if (ret < 0) {
+        LOGED(ERROR, *domid, "domain move fail");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl__domain_make_xs_entries(gc, d_config, state, *domid);
+
+out:
+    return rc;
+}
+
 static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
                              libxl_domain_build_info *b_info)
 {
@@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
     ret = libxl__domain_config_setdefault(gc,d_config,domid);
     if (ret) goto error_out;
 
-    ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
-                             dcs->soft_reset);
-    if (ret) {
-        LOGD(ERROR, domid, "cannot make domain: %d", ret);
+    if ( !d_config->dm_restore_file )
+    {
+        ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
+                                 dcs->soft_reset);
         dcs->guest_domid = domid;
+
+        if (ret) {
+            LOGD(ERROR, domid, "cannot make domain: %d", ret);
+            ret = ERROR_FAIL;
+            goto error_out;
+        }
+    } else if ( dcs->guest_domid != INVALID_DOMID ) {
+        domid = dcs->guest_domid;
+
+        ret = libxl__domain_make_xs_entries(gc, d_config, &dcs->build_state, domid);
+        if (ret) {
+            LOGD(ERROR, domid, "cannot make domain: %d", ret);
+            ret = ERROR_FAIL;
+            goto error_out;
+        }
+    } else {
+        LOGD(ERROR, domid, "cannot make domain");
         ret = ERROR_FAIL;
         goto error_out;
     }
 
-    dcs->guest_domid = domid;
     dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
 
     /* post-4.13 todo: move these next bits of defaulting to
@@ -1236,7 +1268,7 @@ static void initiate_domain_create(libxl__egc *egc,
     if (ret)
         goto error_out;
 
-    if (restore_fd >= 0 || dcs->soft_reset) {
+    if (restore_fd >= 0 || dcs->soft_reset || d_config->dm_restore_file) {
         LOGD(DEBUG, domid, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
     } else  {
@@ -1312,7 +1344,16 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->sdss.dm.callback = domcreate_devmodel_started;
     dcs->sdss.callback = domcreate_devmodel_started;
 
-    if (restore_fd < 0 && !dcs->soft_reset) {
+    if (restore_fd < 0 && !dcs->soft_reset && !d_config->dm_restore_file) {
+        rc = libxl__domain_build(gc, d_config, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    if ( d_config->dm_restore_file ) {
+        dcs->srs.dcs = dcs;
+        dcs->srs.ao = ao;
+        state->forked_vm = true;
         rc = libxl__domain_build(gc, d_config, domid, state);
         domcreate_rebuild_done(egc, dcs, rc);
         return;
@@ -1510,6 +1551,7 @@ static void domcreate_rebuild_done(libxl__egc *egc,
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
 
     if (ret) {
         LOGD(ERROR, domid, "cannot (re-)build domain: %d", ret);
@@ -1517,6 +1559,9 @@ static void domcreate_rebuild_done(libxl__egc *egc,
         goto error_out;
     }
 
+    if ( d_config->dm_restore_file )
+        state->saved_state = GCSPRINTF("%s", d_config->dm_restore_file);
+
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     libxl__multidev_begin(ao, &dcs->multidev);
@@ -1947,7 +1992,7 @@ static void domain_create_cb(libxl__egc *egc,
                              libxl__domain_create_state *dcs,
                              int rc, uint32_t domid);
 
-static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+int libxl__do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid, int restore_fd, int send_back_fd,
                             const libxl_domain_restore_params *params,
                             const libxl_asyncop_how *ao_how,
@@ -1960,6 +2005,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     GCNEW(cdcs);
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.guest_domid = *domid;
+
     libxl_domain_config_init(&cdcs->dcs.guest_config_saved);
     libxl_domain_config_copy(ctx, &cdcs->dcs.guest_config_saved, d_config);
     cdcs->dcs.restore_fd = cdcs->dcs.libxc_fd = restore_fd;
@@ -2204,8 +2251,8 @@ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             const libxl_asyncprogress_how *aop_console_how)
 {
     unset_disk_colo_restore(d_config);
-    return do_domain_create(ctx, d_config, domid, -1, -1, NULL,
-                            ao_how, aop_console_how);
+    return libxl__do_domain_create(ctx, d_config, domid, -1, -1, NULL,
+                                  ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
@@ -2221,8 +2268,8 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
         unset_disk_colo_restore(d_config);
     }
 
-    return do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
-                            params, ao_how, aop_console_how);
+    return libxl__do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
+                                   params, ao_how, aop_console_how);
 }
 
 int libxl_domain_soft_reset(libxl_ctx *ctx,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index f4007bbe50..b615f1fc88 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2803,7 +2803,7 @@ static void device_model_spawn_outcome(libxl__egc *egc,
 
     libxl__domain_build_state *state = dmss->build_state;
 
-    if (state->saved_state) {
+    if (state->saved_state && !state->forked_vm) {
         ret2 = unlink(state->saved_state);
         if (ret2) {
             LOGED(ERROR, dmss->guest_domid, "%s: failed to remove device-model state %s",
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 71cb578923..3bc7117b99 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -249,9 +249,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *xs_domid, *con_domid;
-    int rc;
+    int rc = 0;
     uint64_t size;
 
+    if ( state->forked_vm )
+        goto skip_fork;
+
     if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) {
         LOG(ERROR, "Couldn't set max vcpu count");
         return ERROR_FAIL;
@@ -362,7 +365,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         }
     }
 
-
     rc = libxl__arch_extra_memory(gc, info, &size);
     if (rc < 0) {
         LOGE(ERROR, "Couldn't get arch extra constant memory size");
@@ -374,6 +376,11 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         return ERROR_FAIL;
     }
 
+    rc = libxl__arch_domain_create(gc, d_config, domid);
+    if ( rc )
+        goto out;
+
+skip_fork:
     xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
     state->store_domid = xs_domid ? atoi(xs_domid) : 0;
     free(xs_domid);
@@ -385,8 +392,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
 
-    rc = libxl__arch_domain_create(gc, d_config, domid);
-
+out:
     return rc;
 }
 
@@ -444,6 +450,9 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char **ents;
     int i, rc;
 
+    if ( state->forked_vm )
+        goto skip_fork;
+
     if (info->num_vnuma_nodes && !info->num_vcpu_soft_affinity) {
         rc = set_vnuma_affinity(gc, domid, info);
         if (rc)
@@ -466,6 +475,7 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
         }
     }
 
+skip_fork:
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
@@ -728,14 +738,16 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
                                 int console_evtchn, unsigned long *console_mfn,
-                                domid_t store_domid, domid_t console_domid)
+                                domid_t store_domid, domid_t console_domid,
+                                bool forked_vm)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
     uint64_t str_mfn, cons_mfn;
     int i;
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if ( info->type == LIBXL_DOMAIN_TYPE_HVM && !forked_vm )
+    {
         va_map = xc_map_foreign_range(handle, domid,
                                       XC_PAGE_SIZE, PROT_READ | PROT_WRITE,
                                       HVM_INFO_PFN);
@@ -1051,6 +1063,23 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
     struct xc_dom_image *dom = NULL;
     bool device_model = info->type == LIBXL_DOMAIN_TYPE_HVM ? true : false;
 
+    if ( state->forked_vm )
+    {
+        rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
+                                  &state->store_mfn, state->console_port,
+                                  &state->console_mfn, state->store_domid,
+                                  state->console_domid, state->forked_vm);
+
+        if ( rc )
+            return rc;
+
+        return xc_dom_gnttab_seed(ctx->xch, domid, true,
+                                  state->console_mfn,
+                                  state->store_mfn,
+                                  state->console_domid,
+                                  state->store_domid);
+    }
+
     xc_dom_loginit(ctx->xch);
 
     /*
@@ -1175,7 +1204,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
     rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
                                &state->store_mfn, state->console_port,
                                &state->console_mfn, state->store_domid,
-                               state->console_domid);
+                               state->console_domid, false);
     if (rc != 0) {
         LOG(ERROR, "hvm build set params failed");
         goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5f39e44cb9..d05ff31e83 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1374,6 +1374,7 @@ typedef struct {
 
     char *saved_state;
     int dm_monitor_fd;
+    bool forked_vm;
 
     libxl__file_reference pv_kernel;
     libxl__file_reference pv_ramdisk;
@@ -4818,6 +4819,12 @@ _hidden int libxl__domain_pvcontrol(libxl__egc *egc,
 /* Check whether a domid is recent */
 int libxl__is_domid_recent(libxl__gc *gc, uint32_t domid, bool *recent);
 
+_hidden int libxl__do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                    uint32_t *domid, int restore_fd, int send_back_fd,
+                                    const libxl_domain_restore_params *params,
+                                    const libxl_asyncop_how *ao_how,
+                                    const libxl_asyncprogress_how *aop_console_how);
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7c473be74..2bb5e6319e 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -958,6 +958,7 @@ libxl_domain_config = Struct("domain_config", [
     ("on_watchdog", libxl_action_on_shutdown),
     ("on_crash", libxl_action_on_shutdown),
     ("on_soft_reset", libxl_action_on_shutdown),
+    ("dm_restore_file", string, {'const': True}),
     ], dir=DIR_IN)
 
 libxl_diskinfo = Struct("diskinfo", [
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index f8bc828e62..f4312411fc 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -2,6 +2,7 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
+#include <xen-xsm/flask/flask.h>
 
 int libxl__arch_domain_prepare_config(libxl__gc *gc,
                                       libxl_domain_config *d_config,
@@ -842,6 +843,46 @@ int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
     return rc;
 }
 
+/*
+ * The parent domain is expected to be created with default settings for
+ * - max_evtch_port
+ * - max_grant_frames
+ * - max_maptrack_frames
+ */
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
+{
+    int rc;
+    struct xen_domctl_createdomain create = {0};
+    create.flags |= XEN_DOMCTL_CDF_hvm;
+    create.flags |= XEN_DOMCTL_CDF_hap;
+    create.flags |= XEN_DOMCTL_CDF_oos_off;
+    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
+    create.ssidref = SECINITSID_DOMU;
+    create.max_vcpus = max_vcpus;
+    create.max_evtchn_port = 1023;
+    create.max_grant_frames = LIBXL_MAX_GRANT_FRAMES_DEFAULT;
+    create.max_maptrack_frames = LIBXL_MAX_MAPTRACK_FRAMES_DEFAULT;
+
+    if ( (rc = xc_domain_create(ctx->xch, domid, &create)) )
+        return rc;
+
+    if ( (rc = xc_memshr_fork(ctx->xch, pdomid, *domid)) )
+        xc_domain_destroy(ctx->xch, *domid);
+
+    return rc;
+}
+
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                uint32_t domid,
+                                const libxl_asyncprogress_how *aop_console_how)
+{
+    return libxl__do_domain_create(ctx, d_config, &domid, -1, -1, 0, 0, aop_console_how);
+}
+
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid)
+{
+    return xc_memshr_fork_reset(ctx->xch, domid);
+}
 
 /*
  * Local variables:
diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index af4912e67a..073222233b 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -15,7 +15,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
 CFLAGS_XL += $(CFLAGS_libxenlight)
 CFLAGS_XL += -Wshadow
 
-XL_OBJS-$(CONFIG_X86) = xl_psr.o
+XL_OBJS-$(CONFIG_X86) = xl_psr.o xl_forkvm.o
 XL_OBJS = xl.o xl_cmdtable.o xl_sxp.o xl_utils.o $(XL_OBJS-y)
 XL_OBJS += xl_parse.o xl_cpupool.o xl_flask.o
 XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 06569c6c4a..1105c34b15 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -31,6 +31,7 @@ struct cmd_spec {
 };
 
 struct domain_create {
+    uint32_t ddomid; /* fork launch dm for this domid */
     int debug;
     int daemonize;
     int monitor; /* handle guest reboots etc */
@@ -45,6 +46,7 @@ struct domain_create {
     const char *config_file;
     char *extra_config; /* extra config string */
     const char *restore_file;
+    const char *dm_restore_file;
     char *colo_proxy_script;
     bool userspace_colo_proxy;
     int migrate_fd; /* -1 means none */
@@ -128,6 +130,8 @@ int main_pciassignable_remove(int argc, char **argv);
 int main_pciassignable_list(int argc, char **argv);
 #ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
 int main_restore(int argc, char **argv);
+int main_fork_launch_dm(int argc, char **argv);
+int main_fork_reset(int argc, char **argv);
 int main_migrate_receive(int argc, char **argv);
 int main_save(int argc, char **argv);
 int main_migrate(int argc, char **argv);
@@ -212,6 +216,7 @@ int main_psr_cat_cbm_set(int argc, char **argv);
 int main_psr_cat_show(int argc, char **argv);
 int main_psr_mba_set(int argc, char **argv);
 int main_psr_mba_show(int argc, char **argv);
+int main_fork_vm(int argc, char **argv);
 #endif
 int main_qemu_monitor_command(int argc, char **argv);
 
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 08335394e5..ef634abf32 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -187,6 +187,21 @@ struct cmd_spec cmd_table[] = {
       "Restore a domain from a saved state",
       "- for internal use only",
     },
+#if defined(__i386__) || defined(__x86_64__)
+    { "fork-vm",
+      &main_fork_vm, 0, 1,
+      "Fork a domain from the running parent domid. Experimental. Most config settings must match parent.",
+      "[options] <Domid>",
+      "-h                           Print this help.\n"
+      "-C <config>                  Use config file for VM fork.\n"
+      "-Q <qemu-save-file>          Use qemu save file for VM fork.\n"
+      "--launch-dm <yes|no|late>    Launch device model (QEMU) for VM fork.\n"
+      "--fork-reset                 Reset VM fork.\n"
+      "--max-vcpus                  Specify max-vcpus matching the parent domain when not launching dm\n"
+      "-p                           Do not unpause fork VM after operation.\n"
+      "-d                           Enable debug messages.\n"
+    },
+#endif
 #endif
     { "dump-core",
       &main_dump_core, 0, 1,
diff --git a/tools/xl/xl_forkvm.c b/tools/xl/xl_forkvm.c
new file mode 100644
index 0000000000..e78dbb2ccd
--- /dev/null
+++ b/tools/xl/xl_forkvm.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright 2020 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <sys/utsname.h>
+#include <time.h>
+#include <unistd.h>
+
+#include <libxl.h>
+#include <libxl_utils.h>
+#include <libxlutil.h>
+
+#include "xl.h"
+#include "xl_utils.h"
+#include "xl_parse.h"
+
+int main_fork_vm(int argc, char **argv)
+{
+    int rc, debug = 0;
+    uint32_t domid_in = INVALID_DOMID, domid_out = INVALID_DOMID;
+    int launch_dm = 1;
+    bool reset = 0;
+    bool pause = 0;
+    const char *config_file = NULL;
+    const char *dm_restore_file = NULL;
+    uint32_t max_vcpus = 0;
+
+    int opt;
+    static struct option opts[] = {
+        {"launch-dm", 1, 0, 'l'},
+        {"fork-reset", 0, 0, 'r'},
+        {"max-vcpus", 1, 0, 'm'},
+        COMMON_LONG_OPTS
+    };
+
+    SWITCH_FOREACH_OPT(opt, "phdC:Q:l:rm:V:", opts, "fork-vm", 1) {
+    case 'd':
+        debug = 1;
+        break;
+    case 'p':
+        pause = 1;
+        break;
+    case 'm':
+        max_vcpus = atoi(optarg);
+        break;
+    case 'C':
+        config_file = optarg;
+        break;
+    case 'Q':
+        dm_restore_file = optarg;
+        break;
+    case 'l':
+        if ( !strcmp(optarg, "no") )
+            launch_dm = 0;
+        if ( !strcmp(optarg, "yes") )
+            launch_dm = 1;
+        if ( !strcmp(optarg, "late") )
+            launch_dm = 2;
+        break;
+    case 'r':
+        reset = 1;
+        break;
+    case 'V':
+        fprintf(stderr, "Unimplemented option(s)\n");
+        return EXIT_FAILURE;
+    }
+
+    if (argc-optind == 1) {
+        domid_in = atoi(argv[optind]);
+    } else {
+        help("fork-vm");
+        return EXIT_FAILURE;
+    }
+
+    if (launch_dm && (!config_file || !dm_restore_file)) {
+        fprintf(stderr, "Currently you must provide both -C and -Q options\n");
+        return EXIT_FAILURE;
+    }
+
+    if (reset) {
+        domid_out = domid_in;
+        if (libxl_domain_fork_reset(ctx, domid_in) == EXIT_FAILURE)
+            return EXIT_FAILURE;
+    }
+
+    if (launch_dm == 2 || reset) {
+        domid_out = domid_in;
+        rc = EXIT_SUCCESS;
+    } else {
+        if ( !max_vcpus )
+        {
+            fprintf(stderr, "Currently you must parent's max_vcpu for this option\n");
+            return EXIT_FAILURE;
+        }
+
+        rc = libxl_domain_fork_vm(ctx, domid_in, max_vcpus, &domid_out);
+    }
+
+    if (rc == EXIT_SUCCESS) {
+        if ( launch_dm ) {
+            struct domain_create dom_info;
+            memset(&dom_info, 0, sizeof(dom_info));
+            dom_info.ddomid = domid_out;
+            dom_info.dm_restore_file = dm_restore_file;
+            dom_info.debug = debug;
+            dom_info.paused = pause;
+            dom_info.config_file = config_file;
+            dom_info.migrate_fd = -1;
+            dom_info.send_back_fd = -1;
+            rc = create_domain(&dom_info) < 0 ? EXIT_FAILURE : EXIT_SUCCESS;
+        } else if ( !pause )
+            rc = libxl_domain_unpause(ctx, domid_out, NULL);
+    }
+
+    if (rc == EXIT_SUCCESS)
+        fprintf(stderr, "fork-vm command successfully returned domid: %u\n", domid_out);
+    else if ( domid_out != INVALID_DOMID )
+        libxl_domain_destroy(ctx, domid_out, 0);
+
+    return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 2e2d427492..782fbbc24b 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -676,6 +676,12 @@ int create_domain(struct domain_create *dom_info)
 
     int restoring = (restore_file || (migrate_fd >= 0));
 
+#if defined(__i386__) || defined(__x86_64__)
+    /* VM forking */
+    uint32_t ddomid = dom_info->ddomid; // launch dm for this domain iff set
+    const char *dm_restore_file = dom_info->dm_restore_file;
+#endif
+
     libxl_domain_config_init(&d_config);
 
     if (restoring) {
@@ -926,6 +932,14 @@ start:
          * restore/migrate-receive it again.
          */
         restoring = 0;
+#if defined(__i386__) || defined(__x86_64__)
+    } else if ( ddomid ) {
+        d_config.dm_restore_file = dm_restore_file;
+        ret = libxl_domain_fork_launch_dm(ctx, &d_config, ddomid,
+                                          autoconnect_console_how);
+        domid = ddomid;
+        ddomid = INVALID_DOMID;
+#endif
     } else if (domid_soft_reset != INVALID_DOMID) {
         /* Do soft reset. */
         ret = libxl_domain_soft_reset(ctx, &d_config, domid_soft_reset,
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 16:43:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 16:43:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLUpx-00051k-Vn; Mon, 06 Apr 2020 16:43:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=06X9=5W=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jLUpx-00051f-BP
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 16:43:01 +0000
X-Inumbo-ID: ac08d493-7825-11ea-8009-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ac08d493-7825-11ea-8009-12813bfff9fa;
 Mon, 06 Apr 2020 16:43:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586191380;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=V0pcs+DTT828lXmv+zTuLlbM/UljVqclagyv2mraHC4=;
 b=Fn6yir0xdEDpKS/DIU2lK7ev/lErUvTaMstJrkMRZSv32u8kcMgBPIPN
 m1m8rF1cRhKpA13rzdsH+Ux6+cSCU4P2Cqnw7WgsdPvuVyBM7KTi/n7hS
 KyZUsfr+Vc14n5UG6LTFea8iKYqmqceBD6kxzgDo9AIiwkKF1e3nqCPqY M=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: GcdWCG7OfnvmLebgWzrPsAFm5ZmqvOKQ5DO+Eo4/ijuUCD7RxgrZCc3T+Sfol/kqgkVx7hPlMt
 KvzwoZ3n+mEu7vtQJaWDHZLCxDScLg1tGCiaUsRa4yOo9KskD2FFqsFp+QpVcIMh03y9S3gN/K
 o6ooAZVdlEAjGJPrYVvFhgqdtcYqP2vwKc9M1PGeakLa5vcJ6ID044Gap3v6zvuvTMxcCt02Nw
 mabpmtNqrOmOVJnZvJiuvpH6o1pXnQLOPuTNBisVZlXRFVkt6BIz1EbKyWrmVbHn+rOkz2eeDT
 AGY=
X-SBRS: 2.7
X-MesageID: 15654926
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,351,1580792400"; d="scan'208";a="15654926"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <qemu-devel@nongnu.org>
Subject: [PATCH for-5.0] xen-block: Fix uninitialized variable
Date: Mon, 6 Apr 2020 17:42:07 +0100
Message-ID: <20200406164207.1446817-1-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefano Stabellini <sstabellini@kernel.org>,
 qemu-block@nongnu.org, Paul Durrant <paul@xen.org>,
 Max Reitz <mreitz@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Since 7f5d9b206d1e ("object-add: don't create return value if
failed"), qmp_object_add() don't write any value in 'ret_data', thus
has random data. Then qobject_unref() fails and abort().

Fix by initialising 'ret_data' properly.

Fixes: 5f07c4d60d09 ("qapi: Flatten object-add")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/block/xen-block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 07bb32e22b51..99cb4c67cb09 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -860,7 +860,7 @@ static XenBlockIOThread *xen_block_iothread_create(const char *id,
     XenBlockIOThread *iothread = g_new(XenBlockIOThread, 1);
     Error *local_err = NULL;
     QDict *opts;
-    QObject *ret_data;
+    QObject *ret_data = NULL;
 
     iothread->id = g_strdup(id);
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 16:50:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 16:50:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLUxW-0005qu-Ss; Mon, 06 Apr 2020 16:50:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=oxme=5W=redhat.com=philmd@srs-us1.protection.inumbo.net>)
 id 1jLUxV-0005qp-PR
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 16:50:49 +0000
X-Inumbo-ID: c49d4294-7826-11ea-8009-12813bfff9fa
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id c49d4294-7826-11ea-8009-12813bfff9fa;
 Mon, 06 Apr 2020 16:50:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1586191848;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=orytk2Y2xJ8Iin2kpqW6vpjbDaz8+RpHVBd36rCh+ls=;
 b=Yu8rT/I6H85EkZlC+UsRG7E7sd5RfT45MprPegzbyRew1mMnIBfMvEAF2wmUqTqiZDRoW4
 KmmMQxxMDP90gI78fZUxqiHdbqDrqOHK1hVMG0BwDW8TmoW6jROqGH656ZsSCJ+31aiwUI
 XCsTP+uSChs1yd15qZFvLLU50wA8kL0=
Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com
 [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-277-xzCExvTfPnW00nkoSHP3zg-1; Mon, 06 Apr 2020 12:50:44 -0400
X-MC-Unique: xzCExvTfPnW00nkoSHP3zg-1
Received: by mail-wr1-f72.google.com with SMTP id w12so80584wrl.23
 for <xen-devel@lists.xenproject.org>; Mon, 06 Apr 2020 09:50:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:to:cc:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=orytk2Y2xJ8Iin2kpqW6vpjbDaz8+RpHVBd36rCh+ls=;
 b=diWof5/mpZkNF+/EpfQ9gxho2jJGMEjcdBzcONGLe2K0Mat8XUI6EByUmHbufLw1Jn
 52NOig7Q9hg2wEXixQZz7z5GofDM5WVm6WV5/XAUe/ci94lEszGQtVB052xdCG33Xoxa
 lsR7Mvjtlu9cTSyF2J/kC/pDFFXPD2P62gH9lCrB/hlfG/ZqrXin0VtP5Wb1+imXqBYl
 vZVVzYRAN05r2wYT8bIPn9XO2LmrTlY8usV1IA0fidBqLE8lmtRlTqGEwiqQQp4e3Xh7
 DCZgP6xtoBxrazcip5ReT/wsryZVtO+8r6lyYFS7tAmjT9HZ7tLjK4DcpbLDUHN+9DGW
 l/gQ==
X-Gm-Message-State: AGi0PuYgJgxYafp7LDZsfuCABEeKMb0F589zyZ6u2OGBz/W9KiXttvBK
 NGUYfpGtVM30Dn5OXGKtDodIWtzdyv32D4BD5t5OjXfKpizf2zIIyHx9Dxij0NAi30RbQpFkjVI
 TpXZaVovrGebNKUWuXCKSS7EsjEU=
X-Received: by 2002:a05:600c:2112:: with SMTP id
 u18mr90558wml.112.1586191843565; 
 Mon, 06 Apr 2020 09:50:43 -0700 (PDT)
X-Google-Smtp-Source: APiQypIagRZGzpqiXca97dqed7Bqei3oXsmnxZYsP6eT1lEFxcv0AXz4A/MsQHGOCzuPNiPyb2Dwqg==
X-Received: by 2002:a05:600c:2112:: with SMTP id
 u18mr90541wml.112.1586191843333; 
 Mon, 06 Apr 2020 09:50:43 -0700 (PDT)
Received: from [192.168.1.39] (116.red-83-42-57.dynamicip.rima-tde.net.
 [83.42.57.116])
 by smtp.gmail.com with ESMTPSA id i97sm22827109wri.1.2020.04.06.09.50.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Apr 2020 09:50:42 -0700 (PDT)
Subject: Re: [PATCH for-5.0] xen-block: Fix uninitialized variable
To: Anthony PERARD <anthony.perard@citrix.com>, qemu-devel@nongnu.org,
 Markus Armbruster <armbru@redhat.com>
References: <20200406164207.1446817-1-anthony.perard@citrix.com>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <philmd@redhat.com>
Message-ID: <325e0ffb-2f1b-cbfd-6b24-0d912a9aabe2@redhat.com>
Date: Mon, 6 Apr 2020 18:50:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200406164207.1446817-1-anthony.perard@citrix.com>
Content-Language: en-US
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefano Stabellini <sstabellini@kernel.org>,
 qemu-block@nongnu.org, Paul Durrant <paul@xen.org>,
 Max Reitz <mreitz@redhat.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/6/20 6:42 PM, Anthony PERARD wrote:
> Since 7f5d9b206d1e ("object-add: don't create return value if
> failed"), qmp_object_add() don't write any value in 'ret_data', thus
> has random data. Then qobject_unref() fails and abort().
> 
> Fix by initialising 'ret_data' properly.

Or move qobject_unref() after the error check?

-- >8 --
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 07bb32e22b..f3f1cbef65 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -869,7 +869,6 @@ static XenBlockIOThread 
*xen_block_iothread_create(const char *id,
      qdict_put_str(opts, "id", id);
      qmp_object_add(opts, &ret_data, &local_err);
      qobject_unref(opts);
-    qobject_unref(ret_data);

      if (local_err) {
          error_propagate(errp, local_err);
@@ -878,6 +877,7 @@ static XenBlockIOThread 
*xen_block_iothread_create(const char *id,
          g_free(iothread);
          return NULL;
      }
+    qobject_unref(ret_data);

      return iothread;
  }
---

> 
> Fixes: 5f07c4d60d09 ("qapi: Flatten object-add")
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>   hw/block/xen-block.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
> index 07bb32e22b51..99cb4c67cb09 100644
> --- a/hw/block/xen-block.c
> +++ b/hw/block/xen-block.c
> @@ -860,7 +860,7 @@ static XenBlockIOThread *xen_block_iothread_create(const char *id,
>       XenBlockIOThread *iothread = g_new(XenBlockIOThread, 1);
>       Error *local_err = NULL;
>       QDict *opts;
> -    QObject *ret_data;
> +    QObject *ret_data = NULL;
>   
>       iothread->id = g_strdup(id);
>   
> 



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:16:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:16:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVMa-0007c0-44; Mon, 06 Apr 2020 17:16:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=06X9=5W=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jLVMY-0007bv-LY
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 17:16:42 +0000
X-Inumbo-ID: 61a0dbb6-782a-11ea-800b-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 61a0dbb6-782a-11ea-800b-12813bfff9fa;
 Mon, 06 Apr 2020 17:16:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586193401;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=dw9qolkhXIn6b0T6yhcbrD/aJmWH4v6hLGN3vF3fBK8=;
 b=bAO2VbE3nnYP6pJLUEMrYvo/wDZeC1zAcuuYiewhT3ZoT0iUE7FJwLug
 coDy3OnCGGlLnOGhes1le7TAAxGlnrpZ7yMVgo3Jl5I+JKjNIULoxBydZ
 tWXk3y3DgQEklNhkUnHrtEtYzc9+pvvGzgYU3ydJC9e2e+7jV9Y8k77qH w=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 61p/Hxv70zQnfNanLwCuMtI/mdPU1ZSSxLjAFfIgef6sApVUYnSJHMAYfOnW8uANV8AS2N0yIT
 Vf5v+Gaf8ayKF/U65vNby/Q7N4/I0KbK6CJoGwtUDEig5ia3pGgahxl5DxhFbP2iIkmEJTVTRr
 GlWxFF0NpRtXbvUqwyXTeoER8101SH6FWaDPaopeKkipPXDaLfWYySeqtr8JnNpaUepwhNdNxD
 Xty56atu35YBojAZtk94S+7IiroEpM1m7hWd6TBP5Q/no0osAtmn6sfC030hQzwynqpZg1JS85
 9lk=
X-SBRS: 2.7
X-MesageID: 15573591
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,351,1580792400"; d="scan'208";a="15573591"
Date: Mon, 6 Apr 2020 18:16:37 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= <philmd@redhat.com>
Subject: Re: [PATCH for-5.0] xen-block: Fix uninitialized variable
Message-ID: <20200406171637.GU4088@perard.uk.xensource.com>
References: <20200406164207.1446817-1-anthony.perard@citrix.com>
 <325e0ffb-2f1b-cbfd-6b24-0d912a9aabe2@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <325e0ffb-2f1b-cbfd-6b24-0d912a9aabe2@redhat.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefano Stabellini <sstabellini@kernel.org>,
 qemu-block@nongnu.org, Paul Durrant <paul@xen.org>, qemu-devel@nongnu.org,
 Markus Armbruster <armbru@redhat.com>, xen-devel@lists.xenproject.org,
 Max Reitz <mreitz@redhat.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 06, 2020 at 06:50:41PM +0200, Philippe Mathieu-Daud� wrote:
> On 4/6/20 6:42 PM, Anthony PERARD wrote:
> > Since 7f5d9b206d1e ("object-add: don't create return value if
> > failed"), qmp_object_add() don't write any value in 'ret_data', thus
> > has random data. Then qobject_unref() fails and abort().
> > 
> > Fix by initialising 'ret_data' properly.
> 
> Or move qobject_unref() after the error check?
> 
> -- >8 --
> diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
> index 07bb32e22b..f3f1cbef65 100644
> --- a/hw/block/xen-block.c
> +++ b/hw/block/xen-block.c
> @@ -869,7 +869,6 @@ static XenBlockIOThread *xen_block_iothread_create(const
> char *id,
>      qdict_put_str(opts, "id", id);
>      qmp_object_add(opts, &ret_data, &local_err);
>      qobject_unref(opts);
> -    qobject_unref(ret_data);
> 
>      if (local_err) {
>          error_propagate(errp, local_err);
> @@ -878,6 +877,7 @@ static XenBlockIOThread *xen_block_iothread_create(const
> char *id,
>          g_free(iothread);
>          return NULL;
>      }
> +    qobject_unref(ret_data);

That won't help, qmp_object_add() doesn't change the value of ret_data
at all. The other users of qmp_object_add() passes an initialised
'ret_data', so we should do the same I think.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:17:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVN6-0007fO-EW; Mon, 06 Apr 2020 17:17:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=t1eN=5W=gmail.com=tamas.k.lengyel@srs-us1.protection.inumbo.net>)
 id 1jLVN5-0007fC-6v
 for xen-devel@lists.xen.org; Mon, 06 Apr 2020 17:17:15 +0000
X-Inumbo-ID: 751441f6-782a-11ea-9e09-bc764e2007e4
Received: from mail-wr1-x432.google.com (unknown [2a00:1450:4864:20::432])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 751441f6-782a-11ea-9e09-bc764e2007e4;
 Mon, 06 Apr 2020 17:17:14 +0000 (UTC)
Received: by mail-wr1-x432.google.com with SMTP id k1so406132wrm.3
 for <xen-devel@lists.xen.org>; Mon, 06 Apr 2020 10:17:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=+OPct1KjAk/W161QAuAlNNDHiF+Nzw97Vme4IELTBuY=;
 b=o50vP1igvMSUBQMBAI4BWO4cYHpBsdOT/Og4hXof4QhvwTzec27TrARs97W68yC9Vu
 cJ6twbYJzm9vpQu5CsvnsGjoBS8KjKSTer4sXUVm+WEDgJfeQIxaeEIBIY/PO46YafDx
 aDEYehdPM2gs9Pi/YRB9gTsZbjozvADjqYVw7GAp73nVsEGmTkiN9JLk7QyJHRRsVUlw
 U2ZdHuRaC8w/gIl85OTBPGEKekJkU20bIbVbjzvyS9oCG4Y+XW7FiJQV9sRc/q53pQ4Y
 N71bDXoOMR4Nb+QyJyWYAhtjSUXvGpSzrq2NLIgishnRAwHgAos0W1ZGkhpwzGe3Zfvr
 qraw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=+OPct1KjAk/W161QAuAlNNDHiF+Nzw97Vme4IELTBuY=;
 b=OK/v9DfiSv3vxwvgvIZLkitoUKoZqfHT6Wtbwj21wGysLw9ifTOv+TRYCtiT0uyp41
 w9nrgyeM4CqMEHKBwG7l5F1HpQADYq6wLaT9qgBaf3TSWg+sPDpQBR7taFnJYUiW1WvC
 APHVIWeqiIxqJadube5/sz7onuU1prXFgqLtTaIh9hdnEWNxSZ33ddGIicwG4ZOuMKWT
 FSXuzPbe8I6CbRLk+tygNNmlDw+gemBN6b1VGoq7rgJt8DNEW9eBS5daTUr44Sf+4NfO
 cjNbH4Gilz5jAJ+LlV9IDW3t8j0xQRF0QIJh1FpGB2WQiGhakM9w3HblWLtLPKzw11JP
 drxQ==
X-Gm-Message-State: AGi0PuaeMJvaRD8XLjRenHueYHX/8zXTAB3PV1ANYSZH55UAys0MG27+
 bc6MP6UdKgrMETxW9Hl6WddUEDPZBLt0W6zCGxw=
X-Google-Smtp-Source: APiQypKwPzHgkZj6LDS8jxtDhjQ+kuOWpthELdhABhYX1QzMnN2Pfjo6rXfY/79DEnGxUKpGW2pp9j4xv9unmejenuk=
X-Received: by 2002:adf:eac1:: with SMTP id o1mr261145wrn.182.1586193433261;
 Mon, 06 Apr 2020 10:17:13 -0700 (PDT)
MIME-Version: 1.0
References: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
 <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
In-Reply-To: <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Date: Mon, 6 Apr 2020 11:16:36 -0600
Message-ID: <CABfawhn_hw=o5j+G9VfqPK6opytqt=q2-cz4GjNgCTA5zBvNrA@mail.gmail.com>
Subject: Re: Live migration and PV device handling
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xen.org>,
 Anastassios Nanos <anastassios.nanos@sunlight.io>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 3, 2020 at 6:44 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 03/04/2020 13:32, Anastassios Nanos wrote:
> > Hi all,
> >
> > I am trying to understand how live-migration happens in xen. I am
> > looking in the HVM guest case and I have dug into the relevant parts
> > of the toolstack and the hypervisor regarding memory, vCPU context
> > etc.
> >
> > In particular, I am interested in how PV device migration happens. I
> > assume that the guest is not aware of any suspend/resume operations
> > being done
>
> Sadly, this assumption is not correct.  HVM guests with PV drivers
> currently have to be aware in exactly the same way as PV guests.
>
> Work is in progress to try and address this.  See
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=775a02452ddf3a6889690de90b1a94eb29c3c732
> (sorry - for some reason that doc isn't being rendered properly in
> https://xenbits.xen.org/docs/ )

That proposal is very interesting - first time it came across my radar
- but I dislike the idea that domain IDs need to be preserved for
uncooperative migration to work. Ideally I would be able to take
advantage of the same plumbing to perform forking of VMs with PV
drivers where preserving the domain id is impossible since its still
in use.

Tamas


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:24:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVTo-00006F-7W; Mon, 06 Apr 2020 17:24:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9GA=5W=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jLVTn-00006A-7S
 for xen-devel@lists.xen.org; Mon, 06 Apr 2020 17:24:11 +0000
X-Inumbo-ID: 6d3b3cd6-782b-11ea-b4f4-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6d3b3cd6-782b-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 17:24:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586193850;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=zv5Ps5xjHsXAYaOwPaDrmUzWPCet1fFLdpUcET3SQR4=;
 b=cOyHeIZ7dHoKdwqNIKU6J7mQcTnMU2q3VJxosSZZpSCbF0+fapF33zSj
 BgGnz0RGOjoCuRrf7r9No8WnrKZl5JqnhwIhaUX3gSYJwekQlZwQZMgID
 E0j0Wz8mpO3N1fkgPpNDuY9zadLXgvlHICaTGeQ+vdC2mQRzsWEUf/oX2 E=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 8JaVI4NcjVacnUnmjnqArloL3ZLuonP9J9vRjIWDS8LejwhizPCK5V1LWpYoHB6la7+PzxLgw7
 tXs2ntKJ75EBL88jTceIzfCbravw22ki1oXf+dpCQ4dEhPMX3DjC8z8UrCF2N0+kBqML+xYJ7X
 rHTJ2HybX7VjWfqhPczhGET5JnrA0ZU2ZedIQw05EgjxnNAj0vjoD1s7jrY9oDo8lz8JaK5Tx9
 EPH8xVUaoY2CAovH3C10V4SZ4hoPfCZ1XfgugKMtofBJgogAgb5DCTOcl7tmPbYlRHVU24JeuC
 7+s=
X-SBRS: 2.7
X-MesageID: 15264431
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,351,1580792400"; d="scan'208";a="15264431"
Subject: Re: Live migration and PV device handling
To: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
References: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
 <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
 <CABfawhn_hw=o5j+G9VfqPK6opytqt=q2-cz4GjNgCTA5zBvNrA@mail.gmail.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <6bb7eb58-01c6-00e4-672e-83d5fcb87ea0@citrix.com>
Date: Mon, 6 Apr 2020 18:24:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CABfawhn_hw=o5j+G9VfqPK6opytqt=q2-cz4GjNgCTA5zBvNrA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xen.org>,
 Anastassios Nanos <anastassios.nanos@sunlight.io>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06/04/2020 18:16, Tamas K Lengyel wrote:
> On Fri, Apr 3, 2020 at 6:44 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 03/04/2020 13:32, Anastassios Nanos wrote:
>>> Hi all,
>>>
>>> I am trying to understand how live-migration happens in xen. I am
>>> looking in the HVM guest case and I have dug into the relevant parts
>>> of the toolstack and the hypervisor regarding memory, vCPU context
>>> etc.
>>>
>>> In particular, I am interested in how PV device migration happens. I
>>> assume that the guest is not aware of any suspend/resume operations
>>> being done
>> Sadly, this assumption is not correct.  HVM guests with PV drivers
>> currently have to be aware in exactly the same way as PV guests.
>>
>> Work is in progress to try and address this.  See
>> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=775a02452ddf3a6889690de90b1a94eb29c3c732
>> (sorry - for some reason that doc isn't being rendered properly in
>> https://xenbits.xen.org/docs/ )
> That proposal is very interesting - first time it came across my radar
> - but I dislike the idea that domain IDs need to be preserved for
> uncooperative migration to work.

The above restriction is necessary to work with existing guests, which
is an implementation requirement of the folks driving the work.

> Ideally I would be able to take
> advantage of the same plumbing to perform forking of VMs with PV
> drivers where preserving the domain id is impossible since its still
> in use.

We would of course like to make changes to remove the above restriction
in the longterm.  The problem is that it is not a trivial thing to fix. 
Various things were discussed in Chicago, but I don't recall if any of
the plans made their way onto xen-devel.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:27:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:27:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVWq-0000Fd-Pt; Mon, 06 Apr 2020 17:27:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=zgfQ=5W=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLVWp-0000FY-P8
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 17:27:19 +0000
X-Inumbo-ID: d9f9d5c6-782b-11ea-800d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d9f9d5c6-782b-11ea-800d-12813bfff9fa;
 Mon, 06 Apr 2020 17:27:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=WH78+oljqyiccsCqsgXH7b2K3uqBVsRSi+g8n7mWBEg=; b=FsinFbfdwlhwcBQbBfbXwe8vu
 j7K+oq9iFMMLvY+RR3He485YzETHLlhJP9uLiPWF27ES4asjXLfRoz/LIaoPHt/OYER6JQqtshAEE
 YsL0kmWsMSQAebkTZda3z3Yl0UtQvj9DphkVcF8p/JLzSavHX200o9xb8ARv1eWWxmZvE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLVWi-0007Sm-4g; Mon, 06 Apr 2020 17:27:12 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLVWh-0001Ih-OC; Mon, 06 Apr 2020 17:27:11 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLVWh-0003SQ-NY; Mon, 06 Apr 2020 17:27:11 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149452-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149452: regressions - trouble: broken/fail/pass
X-Osstest-Failures: linux-linus:test-amd64-i386-freebsd10-amd64:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-freebsd10-i386:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-pvshim:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-raw:<job status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-xsm:<job status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-pair:<job status>:broken:regression
 linux-linus:test-amd64-i386-pair:<job status>:broken:regression
 linux-linus:test-amd64-i386-libvirt:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:<job status>:broken:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl:<job status>:broken:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-xsm:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:<job status>:broken:regression
 linux-linus:test-amd64-i386-xl-shadow:<job status>:broken:regression
 linux-linus:test-amd64-i386-examine:capture-logs:broken:regression
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:capture-logs(16):broken:regression
 linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-examine:reboot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-raw:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:xen-boot:fail:regression
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-i386-xl-pvshim:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-freebsd10-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-shadow:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-pair:capture-logs/src_host(12):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-pair:capture-logs/dst_host(13):broken:nonblocking
 linux-linus:test-amd64-i386-pair:capture-logs/src_host(12):broken:nonblocking
 linux-linus:test-amd64-i386-pair:capture-logs/dst_host(13):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-raw:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-freebsd10-i386:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-i386-xl-xsm:capture-logs(8):broken:nonblocking
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=a10c9c710f9ecea87b9f4bbb837467893b4bef01
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 06 Apr 2020 17:27:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64    <job status>                 broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64    <job status>                broken
 test-amd64-i386-freebsd10-i386    <job status>                 broken
 test-amd64-i386-xl-pvshim       <job status>                 broken
 test-amd64-i386-xl-raw          <job status>                 broken
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm    <job status>       broken
 test-amd64-i386-xl-qemuu-ws16-amd64    <job status>                 broken
 test-amd64-i386-xl-xsm          <job status>                 broken
 test-amd64-i386-libvirt-pair    <job status>                 broken
 test-amd64-i386-pair            <job status>                 broken
 test-amd64-i386-libvirt         <job status>                 broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow    <job status>         broken
 test-amd64-i386-qemut-rhel6hvm-intel    <job status>                 broken
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm    <job status>    broken
 test-amd64-amd64-dom0pvh-xl-intel    <job status>                 broken
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict    <job status>    broken
 test-amd64-i386-qemuu-rhel6hvm-amd    <job status>                 broken
 test-amd64-i386-qemuu-rhel6hvm-intel    <job status>                 broken
 test-amd64-i386-xl              <job status>                 broken
 test-amd64-i386-qemut-rhel6hvm-amd    <job status>                 broken
 test-amd64-i386-xl-qemut-ws16-amd64    <job status>                 broken
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm    <job status>             broken
 test-amd64-i386-xl-qemuu-ovmf-amd64    <job status>                 broken
 test-amd64-i386-xl-qemut-win7-amd64    <job status>                 broken
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm    <job status>             broken
 test-amd64-i386-libvirt-xsm     <job status>                 broken
 test-amd64-i386-xl-qemut-debianhvm-amd64    <job status>                broken
 test-amd64-i386-xl-qemuu-win7-amd64    <job status>                 broken
 test-amd64-i386-xl-shadow       <job status>                 broken
 test-amd64-i386-examine       9 capture-logs           broken REGR. vs. 149238
 test-amd64-amd64-dom0pvh-xl-intel 16 capture-logs(16)  broken REGR. vs. 149238
 test-amd64-i386-xl-pvshim     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-examine       8 reboot                   fail REGR. vs. 149238
 test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-libvirt       7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-shadow     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-pair         10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-pair         11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-libvirt-xsm   7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl            7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-raw        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-xsm        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-freebsd10-i386  7 xen-boot               fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot          fail REGR. vs. 149238

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim     8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemuu-ws16-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-qemuu-rhel6hvm-intel 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-freebsd10-amd64  8 capture-logs(8)    broken blocked in 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-libvirt       8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-shadow     8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-libvirt-pair 12 capture-logs/src_host(12) broken blocked in 149238
 test-amd64-i386-libvirt-pair 13 capture-logs/dst_host(13) broken blocked in 149238
 test-amd64-i386-pair     12 capture-logs/src_host(12) broken blocked in 149238
 test-amd64-i386-pair     13 capture-logs/dst_host(13) broken blocked in 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-qemut-rhel6hvm-intel 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-libvirt-xsm   8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-qemut-ws16-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl            8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-xl-raw        8 capture-logs(8)       broken blocked in 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-qemuu-win7-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-freebsd10-i386  8 capture-logs(8)     broken blocked in 149238
 test-amd64-i386-xl-qemut-win7-amd64 8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-qemut-rhel6hvm-amd  8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  8 capture-logs(8) broken blocked in 149238
 test-amd64-i386-xl-xsm        8 capture-logs(8)       broken blocked in 149238
 test-amd64-amd64-dom0pvh-xl-intel 15 guest-saverestore        fail like 149238
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149238
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149238
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                a10c9c710f9ecea87b9f4bbb837467893b4bef01
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    6 days
Failing since        149266  2020-04-01 03:55:53 Z    5 days    7 attempts
Testing same since   149452  2020-04-06 01:54:46 Z    0 days    1 attempts

------------------------------------------------------------
1640 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            broken  
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         broken  
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  broken  
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  broken  
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       broken  
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     broken  
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     broken  
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          broken  
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          broken  
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         broken  
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      fail    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-dom0pvh-xl-intel                            broken  
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 broken  
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    broken  
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       broken  
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              broken  
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    broken  
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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

broken-job test-amd64-i386-freebsd10-amd64 broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-amd64 broken
broken-job test-amd64-i386-freebsd10-i386 broken
broken-job test-amd64-i386-xl-pvshim broken
broken-job test-amd64-i386-xl-raw broken
broken-job test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm broken
broken-job test-amd64-i386-xl-qemuu-ws16-amd64 broken
broken-job test-amd64-i386-xl-xsm broken
broken-job test-amd64-i386-libvirt-pair broken
broken-job test-amd64-i386-pair broken
broken-job test-amd64-i386-libvirt broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken
broken-job test-amd64-i386-qemut-rhel6hvm-intel broken
broken-job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm broken
broken-job test-amd64-amd64-dom0pvh-xl-intel broken
broken-job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken
broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken
broken-job test-amd64-i386-qemuu-rhel6hvm-intel broken
broken-job test-amd64-i386-xl broken
broken-job test-amd64-i386-qemut-rhel6hvm-amd broken
broken-job test-amd64-i386-xl-qemut-ws16-amd64 broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken
broken-job test-amd64-i386-xl-qemuu-ovmf-amd64 broken
broken-job test-amd64-i386-xl-qemut-win7-amd64 broken
broken-job test-amd64-i386-xl-qemut-debianhvm-i386-xsm broken
broken-job test-amd64-i386-libvirt-xsm broken
broken-job test-amd64-i386-xl-qemut-debianhvm-amd64 broken
broken-job test-amd64-i386-xl-qemuu-win7-amd64 broken
broken-job test-amd64-i386-xl-shadow broken
broken-step test-amd64-i386-examine capture-logs
broken-step test-amd64-i386-xl-pvshim capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-ws16-amd64 capture-logs(8)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel capture-logs(8)
broken-step test-amd64-i386-freebsd10-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 capture-logs(8)
broken-step test-amd64-i386-libvirt capture-logs(8)
broken-step test-amd64-i386-xl-shadow capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-debianhvm-i386-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict capture-logs(8)
broken-step test-amd64-i386-libvirt-pair capture-logs/src_host(12)
broken-step test-amd64-i386-libvirt-pair capture-logs/dst_host(13)
broken-step test-amd64-i386-pair capture-logs/src_host(12)
broken-step test-amd64-i386-pair capture-logs/dst_host(13)
broken-step test-amd64-i386-xl-qemut-debianhvm-i386-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 capture-logs(8)
broken-step test-amd64-i386-qemut-rhel6hvm-intel capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow capture-logs(8)
broken-step test-amd64-i386-libvirt-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemut-ws16-amd64 capture-logs(8)
broken-step test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm capture-logs(8)
broken-step test-amd64-i386-xl capture-logs(8)
broken-step test-amd64-i386-xl-raw capture-logs(8)
broken-step test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm capture-logs(8)
broken-step test-amd64-i386-xl-qemuu-win7-amd64 capture-logs(8)
broken-step test-amd64-i386-freebsd10-i386 capture-logs(8)
broken-step test-amd64-i386-xl-qemut-win7-amd64 capture-logs(8)
broken-step test-amd64-i386-qemut-rhel6hvm-amd capture-logs(8)
broken-step test-amd64-i386-qemuu-rhel6hvm-amd capture-logs(8)
broken-step test-amd64-i386-xl-xsm capture-logs(8)
broken-step test-amd64-amd64-dom0pvh-xl-intel capture-logs(16)

Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:27:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVX5-0000I6-86; Mon, 06 Apr 2020 17:27:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8YOW=5W=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLVX4-0000Ht-9V
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 17:27:34 +0000
X-Inumbo-ID: e636e806-782b-11ea-800d-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e636e806-782b-11ea-800d-12813bfff9fa;
 Mon, 06 Apr 2020 17:27:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 04FA6BD06;
 Mon,  6 Apr 2020 17:27:30 +0000 (UTC)
Subject: Re: [PATCH v2 3/3] xen/x86: ioapic: Simplify ioapic_init()
To: Julien Grall <julien@xen.org>
References: <20200404102656.29730-1-julien@xen.org>
 <20200404102656.29730-4-julien@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <a7e761a8-118a-3d84-16a2-5428bc0d22c8@suse.com>
Date: Mon, 6 Apr 2020 15:24:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200404102656.29730-4-julien@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 04.04.2020 12:26, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Since commit 9facd54a45 "x86/ioapic: Add register level checks to detect
> bogus io-apic entries", Xen is able to cope with IO APICs not mapped in
> the fixmap.
> 
> Therefore the whole logic to allocate a fake page for some IO APICs is
> unnecessary.
> 
> With the logic removed, the code can be simplified a lot as we don't
> need to go through all the IO APIC if SMP has not been detected or a
> bogus zero IO-APIC address has been detected.
> 
> To avoid another level of tabulation, the simplification is now moved in
> its own function.
> 
> Signed-off-by: Julien Grall <jgrall@amazon.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:29:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:29:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVYt-0000TC-Ld; Mon, 06 Apr 2020 17:29:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8YOW=5W=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLVYt-0000T7-1m
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 17:29:27 +0000
X-Inumbo-ID: 297409f0-782c-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 297409f0-782c-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 17:29:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A7533B1EA4;
 Mon,  6 Apr 2020 17:29:23 +0000 (UTC)
Subject: Re: [PATCH 2/5] xen/common/domctl: introduce
 XEN_DOMCTL_get/setdomaincontext
To: paul@xen.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-3-paul@xen.org>
 <fc193a54-5d25-ffff-2234-9c0079c605d8@xen.org>
 <002501d60bf2$dda86480$98f92d80$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <a555b215-b758-300b-5188-402e839f2bcd@suse.com>
Date: Mon, 6 Apr 2020 14:46:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <002501d60bf2$dda86480$98f92d80$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 'Daniel De Graaf' <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.2020 11:07, Paul Durrant wrote:
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Sent: 01 April 2020 14:42
>>
>> On 27/03/2020 18:50, Paul Durrant wrote:
>> Also, in the case of XEN_DOMCTL_setdomaincontext, the buffer is not
>> meant to be modified by the hypervisor. So I would rather introduce two
>> separate structure so we can enforce the const.
> 
> Can handles be meaningfully const?

Yes, see e.g. Julien's recent patch to force honoring const-ness
in some cases where it wasn't enforced so far. Luckily there
look to not have crept in any violators.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:31:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:31:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVbB-0001EI-3U; Mon, 06 Apr 2020 17:31:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=t1eN=5W=gmail.com=tamas.k.lengyel@srs-us1.protection.inumbo.net>)
 id 1jLVb9-0001ED-Vq
 for xen-devel@lists.xen.org; Mon, 06 Apr 2020 17:31:48 +0000
X-Inumbo-ID: 7d90057a-782c-11ea-9e09-bc764e2007e4
Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7d90057a-782c-11ea-9e09-bc764e2007e4;
 Mon, 06 Apr 2020 17:31:47 +0000 (UTC)
Received: by mail-wm1-x343.google.com with SMTP id j19so166986wmi.2
 for <xen-devel@lists.xen.org>; Mon, 06 Apr 2020 10:31:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=QtQEmnvIRNjTWAGtotK8vr5aL1WEPMTRa/UAOoQ/pSk=;
 b=q7Vu5MbnAyAdq/X/v95seSyLeDOQk8rxYf+a67Xnw4wEm5iwv2I9i+vchjZoNsEHgD
 du9Y9hb9L/kmiuRzQaWSv2efPtKcOoTFKkuVfmzR4uFlEHCVI3geAXV/w/G7F7Nr+yax
 U5FSg0SxRBKqOQhmPv/MoQxkm9nRYLlYhfgCFO0UDFKkLA+aRro7pRIbqxASFisOATFh
 0yNIeDS7PY7mYo4r+ZHcSgJcZtY6sbKvTcQ/GSrtkiCmZh0EVubXhadxbImZoxKfB44c
 qdDTY2AUETLxAWoincuEiBYClnfsjOg2BnKQigVyOgByxLgiDzJJ+BXHb6uzqQyHGI/2
 ZQOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=QtQEmnvIRNjTWAGtotK8vr5aL1WEPMTRa/UAOoQ/pSk=;
 b=ATXo26cFknS9/jxheynSbV/DGAbt6w14G4B/zr9lBdf+X6gjubRFdu3ixxkP8/SFOa
 1p9hF/j7PAukkwjmADJU0/D28BbSdDvyG9KbhccCuPLoeFTm1DdRcWhODP2MG142t+m6
 Hk/HpYbwQxBU/0RyJq3JSVjc4MVcmipve3BfHmkNTMo3jqlGnEyD+ZnNEVhnbpwclws+
 DHkM5JJ1VJEOCb1FuMq/V3bFgSyC7YZMuU++gXiwU5M/KltwGviOdIW+oiqkT3rgbSbB
 pL37Ys/2dVwTKuKaMoFfZgVCk64TD0vlxAFSmZCHYc6wSxMwhiSGyJ0Ipb3XqwSh8loD
 202g==
X-Gm-Message-State: AGi0PuYCN5niYOOmx5mvpcuhXdXBuVyw5EJn9czqdWcfP4cLH9JLGLrx
 r11QQMtGc8k3VvBYFKtSXhpq2pKEvSmKSzkr004=
X-Google-Smtp-Source: APiQypIbzVcQhtuKPx/sWYXqksN+tCLZDAk0hzlSjQiNX5GtwWG/GDjtfexjX56TkPBmMZS9LXKn4lmLqLhrYWNb/MQ=
X-Received: by 2002:a7b:c842:: with SMTP id c2mr457489wml.154.1586194306477;
 Mon, 06 Apr 2020 10:31:46 -0700 (PDT)
MIME-Version: 1.0
References: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
 <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
 <CABfawhn_hw=o5j+G9VfqPK6opytqt=q2-cz4GjNgCTA5zBvNrA@mail.gmail.com>
 <6bb7eb58-01c6-00e4-672e-83d5fcb87ea0@citrix.com>
In-Reply-To: <6bb7eb58-01c6-00e4-672e-83d5fcb87ea0@citrix.com>
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Date: Mon, 6 Apr 2020 11:31:10 -0600
Message-ID: <CABfawh=6z-pxgrj1M3JbG-9H=iR78rTwt8+MUf_6-Sd5kqyhdA@mail.gmail.com>
Subject: Re: Live migration and PV device handling
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xen.org>,
 Anastassios Nanos <anastassios.nanos@sunlight.io>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 6, 2020 at 11:24 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 06/04/2020 18:16, Tamas K Lengyel wrote:
> > On Fri, Apr 3, 2020 at 6:44 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >> On 03/04/2020 13:32, Anastassios Nanos wrote:
> >>> Hi all,
> >>>
> >>> I am trying to understand how live-migration happens in xen. I am
> >>> looking in the HVM guest case and I have dug into the relevant parts
> >>> of the toolstack and the hypervisor regarding memory, vCPU context
> >>> etc.
> >>>
> >>> In particular, I am interested in how PV device migration happens. I
> >>> assume that the guest is not aware of any suspend/resume operations
> >>> being done
> >> Sadly, this assumption is not correct.  HVM guests with PV drivers
> >> currently have to be aware in exactly the same way as PV guests.
> >>
> >> Work is in progress to try and address this.  See
> >> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=775a02452ddf3a6889690de90b1a94eb29c3c732
> >> (sorry - for some reason that doc isn't being rendered properly in
> >> https://xenbits.xen.org/docs/ )
> > That proposal is very interesting - first time it came across my radar
> > - but I dislike the idea that domain IDs need to be preserved for
> > uncooperative migration to work.
>
> The above restriction is necessary to work with existing guests, which
> is an implementation requirement of the folks driving the work.
>
> > Ideally I would be able to take
> > advantage of the same plumbing to perform forking of VMs with PV
> > drivers where preserving the domain id is impossible since its still
> > in use.
>
> We would of course like to make changes to remove the above restriction
> in the longterm.  The problem is that it is not a trivial thing to fix.
> Various things were discussed in Chicago, but I don't recall if any of
> the plans made their way onto xen-devel.

Yea I imagine trying to get this to work with existing PV drivers is
not possible in any other way. But if we can update the PV driver code
such that in the longterm it can work without preserving the domain
ID, that would be worthwhile.

Tamas


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:35:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:35:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVeP-0001OU-KY; Mon, 06 Apr 2020 17:35:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8YOW=5W=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLVeO-0001OO-Jx
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 17:35:08 +0000
X-Inumbo-ID: f522e4a4-782c-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f522e4a4-782c-11ea-83d8-bc764e2007e4;
 Mon, 06 Apr 2020 17:35:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 73AD1C1AA;
 Mon,  6 Apr 2020 17:35:05 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
Date: Mon, 6 Apr 2020 14:29:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 03.04.2020 17:45, Jürgen Groß wrote:
> On 03.04.20 17:33, Jan Beulich wrote:
>> On 03.04.2020 17:12, Jürgen Groß wrote:
>>> On 03.04.20 16:31, Jan Beulich wrote:
>>>> On 02.04.2020 17:46, Juergen Gross wrote:
>>>>> --- a/xen/common/Kconfig
>>>>> +++ b/xen/common/Kconfig
>>>>> @@ -353,6 +353,16 @@ config DOM0_MEM
>>>>>            Leave empty if you are not sure what to specify.
>>>>>    +config HYPFS_CONFIG
>>>>> +    bool "Provide hypervisor .config via hypfs entry"
>>>>> +    default y
>>>>
>>>> My initial reaction was to ask for "depends on HYPFS", but then
>>>> I noticed the earlier patch doesn't introduce such. Am I
>>>> mis-remembering that it was agreed to make the whole thing
>>>> possible to disable at least in EXPERT mode?
>>>
>>> No, I don't remember that agreement.
>>>
>>> And TBH I'm not sure this is a good idea, as that would at once make the
>>> plan to replace at least some sysctl and/or domctl interfaces impossible
>>> (like e.g. the last 3 patches of the series are doing already), or at
>>> least would tie the related functionality to CONFIG_HYPFS.
>>
>> I think that would be fine - that's what config setting are for.
>> Someone caring about space may not care about runtime setting of
>> parameters.
> 
> So right now it would start with a plain hypfs available or not.
> 
> The next step would be in patch 12 to tell the user he will lose the
> capability of setting runtime parameters.
> 
> Another planned extension would be to control per-cpupool settings,
> which would the go away (possibly functionality being unconditionally
> available today).
> 
> Next would be the lack of being able to control per-domain mitigations
> like XPTI or L1TF, which I'd like to add.
> 
> Another thing I wanted to add is some debugging stuff (e.g. to switch
> lock profiling using hypfs).
> 
> And the list will go on.

Understood.

> Does it really make sense to make a central control and information
> interface conditional?

None of the above may be of interest to e.g. embedded use cases.

> I'd like at least a second opinion on that topic.

Yes, further opinions would surely help.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:43:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVmY-0002FT-Gu; Mon, 06 Apr 2020 17:43:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=06X9=5W=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jLVmX-0002FO-KC
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 17:43:33 +0000
X-Inumbo-ID: 220da138-782e-11ea-9e09-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 220da138-782e-11ea-9e09-bc764e2007e4;
 Mon, 06 Apr 2020 17:43:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586195012;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=bphNPG/A+OeRKQoZBapDV/s73PtCWQsb127JQKMzOao=;
 b=F+RmdHBQTFFvzkacoZ3/hXM4lHdqVhQlhLDNjDFEZMtdAclAtlf9pWPz
 I1HvQ6g7p/fg8nuz7E4S0fh9g9db5IuO7lIMVVhOUzIg6LSSlZOhh0xmm
 OBrOQUt7sj9mtfGjJWM/wH8t23ghBmKTth1JO0PTwM8XQjuntye+76OrB w=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: hlwK8qzoKR3mA9SudDYB7JPSpQopwHfmD0RVWef2oBdIhmk3ijC0+3/s95S//l+6oEL8dsmgt8
 Uawkk1KEd8fi+ZuOC2BZ4QpNt5FC6GCEnEYZVho/chg/F8dlrZg6czj8gXIe8lUROYGsHwZkaq
 j+SraWWkJVFvNOLDyIeXhcspFxknIP0pUJllzFYn+l6GGDxL4WPszJx8A11HSq8WY4tHdX3CRE
 deaNLxX6QujMrG3H3CELbEh71lmlOeoZdd433K4tta+A+L6EstblMI3iZN47kIqjhMffSiFRmf
 4N0=
X-SBRS: 2.7
X-MesageID: 15918507
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,351,1580792400"; d="scan'208";a="15918507"
Date: Mon, 6 Apr 2020 18:43:23 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [RFC] hw/usb/xen-usb.c: Pass struct usbback_req* to
 usbback_packet_complete()
Message-ID: <20200406174323.GV4088@perard.uk.xensource.com>
References: <20200323164318.26567-1-peter.maydell@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200323164318.26567-1-peter.maydell@linaro.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org, Stefano
 Stabellini <sstabellini@kernel.org>, qemu-devel@nongnu.org,
 Gerd Hoffmann <kraxel@redhat.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Mar 23, 2020 at 04:43:18PM +0000, Peter Maydell wrote:
> The function usbback_packet_complete() currently takes a USBPacket*,
> which must be a pointer to the packet field within a struct
> usbback_req; the function uses container_of() to get the struct
> usbback_req* given the USBPacket*.
> 
> This is unnecessarily confusing (and in particular it confuses the
> Coverity Scan analysis, resulting in the false positive CID 1421919
> where it thinks that we write off the end of the structure). Since
> both callsites already have the pointer to the struct usbback_req,
> just pass that in directly.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> This is an RFC because:
>  * I'm not very familiar with the Xen bits of QEMU
>  * the main rationale here is to change something that's
>    confusing Coverity -- the code as it stands isn't wrong
>  * the only testing I've done is "make check"
> Still, the change seems like a good thing to me as a human reader...
> 
> PS: QEMU's MAINTAINERS file stanza for Xen doesn't pick up
> that this file is Xen related, so it could use an extra F: line.

Looks good,
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:44:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVn7-0002Hk-RT; Mon, 06 Apr 2020 17:44:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8YOW=5W=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLVn6-0002Ha-E5
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 17:44:08 +0000
X-Inumbo-ID: 36bc1b1e-782e-11ea-8012-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 36bc1b1e-782e-11ea-8012-12813bfff9fa;
 Mon, 06 Apr 2020 17:44:07 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E6CB1B41E;
 Mon,  6 Apr 2020 17:44:04 +0000 (UTC)
Subject: Re: [PATCH v2] tools/libxl: make default of max event channels
 dependant on vcpus [and 1 more messages]
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
References: <20200406082704.13994-1-jgross@suse.com>
 <afc7e988-3b51-bbee-cba8-af30a7605dc4@xen.org>
 <d1b095db-064e-bccf-b55d-d85fecb3045a@suse.com>
 <24203.2251.628483.557280@mariner.uk.xensource.com>
 <fd09220a-7470-4679-ce16-f4553579171b@xen.org>
 <26161282-7bad-5888-16c9-634647e6fde8@xen.org>
 <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com>
 <24203.2546.728186.463143@mariner.uk.xensource.com>
 <24203.2996.819908.965198@mariner.uk.xensource.com>
 <799396b3-0304-e149-cc3f-45c5a46c7c0c@suse.com>
 <c85e15d2-3d3f-7d7f-eb7a-af5270df2e2d@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <b769c6e8-586f-7d3b-1e5d-d5c948ac7971@suse.com>
Date: Mon, 6 Apr 2020 14:09:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <c85e15d2-3d3f-7d7f-eb7a-af5270df2e2d@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.2020 13:54, Jürgen Groß wrote:
> On 06.04.20 13:11, Jan Beulich wrote:
>> On 06.04.2020 13:00, Ian Jackson wrote:
>>> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"):
>>>> There are no correlation between event channels and vCPUs. The number of
>>>> event channels only depends on the number of frontend you have in your
>>>> guest. So...
>>>>
>>>> Hi Ian,
>>>>
>>>> On 06/04/2020 11:47, Ian Jackson wrote:
>>>>> If ARM folks want to have a different formula for the default then
>>>>> that is of course fine but I wonder whether this might do ARMk more
>>>>> harm than good in this case.
>>>>
>>>> ... 1023 event channels is going to be plenty enough for most of the use
>>>> cases.
>>>
>>> OK, thanks for the quick reply.
>>>
>>> So, Jürgen, I think everyone will be happy with this:
>>
>> I don't think I will be - my prior comment still holds on there not
>> being any grounds to use a specific OS kernel's (and to be precise
>> a specific OS kernel version's) requirements for determining
>> defaults. If there was to be such a dependency, then OS kernel
>> [variant] should be part of the inputs to such a (set of) formula(s).
> 
> IMO this kind of trying to be perfect will completely block a sane
> heuristic for being able to boot large guests at all.

This isn't about being perfect - I'm suggesting to leave the
default alone, not to improve the calculation, not the least
because I've been implying ...

> The patch isn't about to find an as stringent as possible upper
> boundary for huge guests, but a sane value being able to boot most of
> those.
> 
> And how should Xen know the OS kernel needs exactly after all?

... the answer of "It can#t" to this question.

> And it is not that we talking about megabytes of additional memory. A
> guest with 256 vcpus will just be able to use additional 36 memory
> pages. The maximum non-PV domain (the probably only relevant case
> of another OS than Linux being used) with 128 vcpus would "waste"
> 32 kB. In case the guest misbehaves.

Any extra page counts, or else - where do you draw the line? Any
single page may decide between Xen (not) being out of memory,
and hence also not being able to fulfill certain other requests.

> The alternative would be to do nothing and having to let the user
> experience a somewhat cryptic guest crash. He could google for a
> possible solution which would probably end in a rather high static
> limit resulting in wasting even more memory.

I realize this. Otoh more people running into this will improve
the chances of later ones finding useful suggestions. Of course
there's also nothing wrong with trying to make the error less
cryptic.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:47:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:47:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLVpx-0002Tz-DL; Mon, 06 Apr 2020 17:47:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=cgVF=5W=amazon.com=prvs=358faf7b1=havanur@srs-us1.protection.inumbo.net>)
 id 1jLVpw-0002Ts-0z
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 17:47:04 +0000
X-Inumbo-ID: 9f9b5afa-782e-11ea-9e09-bc764e2007e4
Received: from smtp-fw-6002.amazon.com (unknown [52.95.49.90])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9f9b5afa-782e-11ea-9e09-bc764e2007e4;
 Mon, 06 Apr 2020 17:47:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586195224; x=1617731224;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=yt7gmqo213JWZVFnM8byFy2ysrSg+zGPA3A8NyH1JJ4=;
 b=gJRhG1RN2VoNFelKhK0Psaa70xp8zvxo8d52ujb8LjLhUSbQO2foOmPQ
 kI+hcWc/0VyIwFtFAZLsprt4GWmnkZfwnqaFpKDiOnMSgPk1s+pIEt7xV
 gaXbDIXnPehqdjjhPh+vGs28HFopfNmI4VlfRCb6GoYwStJQgIdtZvfPJ Q=;
IronPort-SDR: wXaBkS8KeQutAy+Z1aUTCeUfMxYLWhgmOLeT3NaO3yt3fIw9ol26w6vw6ES9ZUUq8MKnEzf+0G
 HJTFgFGT5MDA==
X-IronPort-AV: E=Sophos;i="5.72,351,1580774400"; d="scan'208";a="24338296"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-1e-303d0b0e.us-east-1.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP;
 06 Apr 2020 17:46:47 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166])
 by email-inbound-relay-1e-303d0b0e.us-east-1.amazon.com (Postfix) with ESMTPS
 id 4C188A20B4; Mon,  6 Apr 2020 17:46:44 +0000 (UTC)
Received: from EX13D36EUC002.ant.amazon.com (10.43.164.99) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Mon, 6 Apr 2020 17:46:44 +0000
Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by
 EX13D36EUC002.ant.amazon.com (10.43.164.99) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Mon, 6 Apr 2020 17:46:43 +0000
Received: from dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com
 (172.19.122.179) by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP
 Server id 15.0.1497.2 via Frontend Transport; Mon, 6 Apr 2020 17:46:42 +0000
Received: by dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com (Postfix,
 from userid 11119479)
 id 8556B83D91; Mon,  6 Apr 2020 17:46:42 +0000 (UTC)
From: Harsha Shamsundara Havanur <havanur@amazon.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Mon, 6 Apr 2020 17:46:36 +0000
Message-ID: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Harsha Shamsundara Havanur <havanur@amazon.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It was observed that PCI MMIO and/or IO BARs were programmed with
BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
register) enabled, during PCI setup phase. This resulted in
spurious and premature bus transactions as soon as the lower bar of
the 64 bit bar is programmed. It is highly recommended that BARs be
programmed whilst decode bits are cleared to avoid spurious bus
transactions.

This patch address the issue by deferring enablement of memory and
I/O decode in command register until all the resources, like interrupts
I/O and/or MMIO BARs for all the PCI device functions are programmed.
PCI bus memory and I/O space is enabled in command register after
all the resources like interrupts, I/O and/or MMIO BARs are
programmed for all valid device functions. PCI BUS MASTER is kept
disabled in the bootloader as this needs to be enabled by the guest
OS driver once it initializes and takes control of the device.

Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
Ack-by: Paul Durrant <pdurrant@amazon.com>
---
 tools/firmware/hvmloader/pci.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 0b708bf578..0f31866453 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -84,6 +84,7 @@ void pci_setup(void)
     uint32_t vga_devfn = 256;
     uint16_t class, vendor_id, device_id;
     unsigned int bar, pin, link, isa_irq;
+    uint8_t pci_devfn_decode_type[256] = {};
 
     /* Resources assignable to PCI devices via BARs. */
     struct resource {
@@ -289,9 +290,14 @@ void pci_setup(void)
                    devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
         }
 
-        /* Enable bus mastering. */
+        /*
+         * Disable bus mastering, memory and I/O space, which is typical device
+         * reset state. It is recommended that BAR programming be done whilst
+         * decode bits are cleared to avoid spurious DMAs and bus transactions.
+         * Bus master should be enabled by guest driver when it deems fit.
+         */
         cmd = pci_readw(devfn, PCI_COMMAND);
-        cmd |= PCI_COMMAND_MASTER;
+        cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
         pci_writew(devfn, PCI_COMMAND, cmd);
     }
 
@@ -503,10 +509,9 @@ void pci_setup(void)
         if ( (bar_reg == PCI_ROM_ADDRESS) ||
              ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
               PCI_BASE_ADDRESS_SPACE_MEMORY) )
-            cmd |= PCI_COMMAND_MEMORY;
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
         else
-            cmd |= PCI_COMMAND_IO;
-        pci_writew(devfn, PCI_COMMAND, cmd);
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_IO;
     }
 
     if ( pci_hi_mem_start )
@@ -530,6 +535,15 @@ void pci_setup(void)
         cmd |= PCI_COMMAND_IO;
         pci_writew(vga_devfn, PCI_COMMAND, cmd);
     }
+
+    /* Enable memory and I/O space. */
+    for ( devfn = 0; devfn < 256; devfn++ )
+        if ( pci_devfn_decode_type[devfn] )
+        {
+            cmd = pci_readw(devfn, PCI_COMMAND);
+            cmd |= pci_devfn_decode_type[devfn];
+            pci_writew(devfn, PCI_COMMAND, cmd);
+        }
 }
 
 /*
-- 
2.16.6



From xen-devel-bounces@lists.xenproject.org Mon Apr 06 17:58:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 17:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLW0z-0003OK-LP; Mon, 06 Apr 2020 17:58:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LGem=5W=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jLW0y-0003OF-ST
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 17:58:28 +0000
X-Inumbo-ID: 377b2f20-7830-11ea-b58d-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 377b2f20-7830-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 17:58:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586195908;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=b90tbljqrYl/NyUKv3eHvQxLAFAIcLjdWNjpd9IRw8A=;
 b=SPMiAEpub1kfPS3nt26t6vTddhsjQMx8d0CGH1DxMM70DASi1fi3RF5b
 jxBDrVSD1wcaCWJaPK82RGZGMzWOSvCMw0Vbxeck9dhbOlMY1pyzU7hQl
 d1f4oD05Q7GH3t08HNUJ2luvxqLR7Qv0pfSzpXgyEKVHhP0fIHl2fqAVN 0=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 1eXr4NGxF1AI+Kv8PhvDt3xzc3eU8w2je92/qY9rMAQjP/lkBuPwh4hNSRxfDVxvUa4dobVmdL
 uSXcS03i1dIIH/pHJhjgIDKJYeLl+PzNSAJEuUJpEs2YWNjAMzpDCDDSURlyvymq9N/PSLoi//
 JAdUzdvePb3cRUHX8ksvZTVFNJ+OYk2u+alhX7qeGPwpyVXiPghcpEnCi6ISaUeDLqYtew/Eoi
 cSmqq2r4qP5JiTSUWQJiFlBwY+TWp8S6qlfpTHcWYJJIMZQgP1oYTEeGUH5/0b1OwyVon8/bVA
 Ess=
X-SBRS: 2.7
X-MesageID: 15237662
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,352,1580792400"; d="scan'208";a="15237662"
From: George Dunlap <George.Dunlap@citrix.com>
To: Julien Grall <julien.grall.oss@gmail.com>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Topic: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Index: AQHWCRLu2U2EJ1WUk0i1KTanKYKpWqhmDBwAgAGf9wCAAAzcgIAEjVGA
Date: Mon, 6 Apr 2020 17:58:23 +0000
Message-ID: <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
In-Reply-To: <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <E71A56E852E3604E84BE9F44A5AA6055@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDMsIDIwMjAsIGF0IDk6MjcgUE0sIEp1bGllbiBHcmFsbCA8anVsaWVuLmdy
YWxsLm9zc0BnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gRnJpLCAzIEFwciAyMDIwIGF0IDIw
OjQxLCBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+IHdyb3RlOg0K
Pj4gDQo+PiBPbiBUaHUsIDIgQXByIDIwMjAsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+PiBBcyB3
ZSBkaXNjdXNzZWQgb24gVHVlc2RheSwgdGhlIGNvc3QgZm9yIG90aGVyIHZDUFVzIGlzIG9ubHkg
Z29pbmcgdG8gYmUgYQ0KPj4+IHRyYXAgdG8gdGhlIGh5cGVydmlzb3IgYW5kIHRoZW4gYmFjayBh
Z2Fpbi4gVGhlIGNvc3QgaXMgbGlrZWx5IHNtYWxsZXIgdGhhbg0KPj4+IHJlY2VpdmluZyBhbmQg
Zm9yd2FyZGluZyBhbiBpbnRlcnJ1cHQuDQo+Pj4gDQo+Pj4gWW91IGFjdHVhbGx5IGFncmVlZCBv
biB0aGlzIGFuYWx5c2lzLiBTbyBjYW4geW91IGVubGlnaHRlbiBtZSBhcyB0byB3aHkNCj4+PiBy
ZWNlaXZpbmcgYW4gaW50ZXJydXB0IGlzIGEgbm90IHByb2JsZW0gZm9yIGxhdGVuY3kgYnV0IHRo
aXMgaXM/DQo+PiANCj4+IE15IGFuc3dlciB3YXMgdGhhdCB0aGUgZGlmZmVyZW5jZSBpcyB0aGF0
IGFuIG9wZXJhdGluZyBzeXN0ZW0gY2FuDQo+PiBkaXNhYmxlIGludGVycnVwdHMsIGJ1dCBpdCBj
YW5ub3QgZGlzYWJsZSByZWNlaXZpbmcgdGhpcyBzcGVjaWFsIElQSS4NCj4gDQo+IEFuIE9TIGNh
biAqb25seSogZGlzYWJsZSBpdHMgb3duIGludGVycnVwdHMsIHlldCBpbnRlcnJ1cHRzIHdpbGwg
c3RpbGwNCj4gYmUgcmVjZWl2ZWQgYnkgWGVuIGV2ZW4gaWYgdGhlIGludGVycnVwdHMgYXJlIG1h
c2tlZCBhdCB0aGUgcHJvY2Vzc29yDQo+IChlLmcgbG9jYWxfaXJxX2Rpc2FibGUoKSkuDQo+IA0K
PiBZb3Ugd291bGQgbmVlZCB0byBkaXNhYmxlIGludGVycnVwdHMgb25lIGJ5IG9uZSBhcyB0aGUg
R0lDIGxldmVsICh1c2UNCj4gSUNFTkFCTEVSKSBpbiBvcmRlciB0byBub3QgcmVjZWl2ZSBhbnkg
aW50ZXJydXB0cy4gWWV0LCBYZW4gbWF5IHN0aWxsDQo+IHJlY2VpdmUgaW50ZXJydXB0cyBmb3Ig
b3BlcmF0aW9uYWwgcHVycG9zZXMgKGUuZyBzZXJpYWwsIGNvbnNvbGUsDQo+IG1haW50YWluYW5j
ZSBJUlEuLi4pLiBTbyB0cmFwIHdpbGwgaGFwcGVuLg0KDQpJIHRoaW5rIFN0ZWZhbm/igJlzIGFz
c2VydGlvbiBpcyB0aGF0IHRoZSB1c2VycyBoZSBoYXMgaW4gbWluZCB3aWxsIGJlIGNvbmZpZ3Vy
aW5nIHRoZSBzeXN0ZW0gc3VjaCB0aGF0IFJUIHdvcmtsb2FkcyBnZXQgYSBtaW5pbXVtIG51bWJl
ciBvZiBoeXBlcnZpc29yLXJlbGF0ZWQgaW50ZXJydXB0cyBwb3NzaWJsZS4gIE9uIGEgNC1jb3Jl
IHN5c3RlbSwgeW91IGNvdWxkICBoYXZlIG5vbi1SVCB3b3JrbG9hZHMgcnVubmluZyBvbiBjb3Jl
cyAwLTEsIGFuZCBSVCB3b3JrbG9hZHMgcnVubmluZyB3aXRoIHRoZSBOVUxMIHNjaGVkdWxlciBv
biBjb3JlcyAyLTMuICBJbiBzdWNoIGEgc3lzdGVtLCB5b3XigJlkIG9idmlvdXNseSBhcnJhbmdl
IHRoYXQgc2VyaWFsIGFuZCBtYWludGVuYW5jZSBJUlFzIGFyZSBkZWxpdmVyZWQgdG8gY29yZXMg
MC0xLg0KDQpKdWxpZW4sIEkgdGhpbmsgeW91ciBhcmd1bWVudCBhYm92ZSBhYm91dCBpbnRlcnJ1
cHRzIHNvbWV3aGF0IHVuZGVybWluZXMgeW91ciBwb2ludCBhYm91dCBkZWFkbG9jay4gIFlvdXIg
YmFzaWMgYXJndW1lbnQgaXMsIHRoYXQgYSBndWVzdCB3aWxsIGJlIGludGVycnVwdGVkIGJ5IFhl
biBxdWl0ZSBmcmVxdWVudGx5IGFueXdheSBmb3IgbG90cyBvZiByZWFzb25zOyBhZGRpbmcgb25l
IG1vcmUgdG8gdGhlIGxpc3Qgc2hvdWxkbuKAmXQgbWVhc3VyYWJseSBpbmNyZWFzZSB0aGUgaml0
dGVyLiAgQnV0IGlmIGl04oCZcyB0cnVlIHRoYXQgYSBndWVzdCB3aWxsIGJlIGludGVycnVwdGVk
IGJ5IFhlbiBmcmVxdWVudGx5LCB0aGVuIGRlYWRsb2NrIHNob3VsZG7igJl0IGJlIG11Y2ggb2Yg
YW4gaXNzdWU7IGFuZCBpbnNvZmFyIGFzIGRlYWRsb2NrIGlzIGFuIGlzc3VlLCBpdOKAmXMgYmVj
YXVzZSB0aGVyZSB3ZXJlIG5vIGludGVycnVwdHMg4oCUIGFuZCB0aHVzLCBhZGRpbmcgYW4gZXh0
cmEgSVBJIHdpbGwgaGF2ZSBhIHN0YXRpc3RpY2FsbHkgc2lnbmlmaWNhbnQgZWZmZWN0IG9uIGpp
dHRlci4NCg0KT24gdGhlIG90aGVyIGhhZCwgU3RlZmFub+KAmXMgYXJndW1lbnQgYWJvdXQgZGVh
ZGxvY2sgKGlmIEkgdW5kZXJzdGFuZCBoaW0gY29ycmVjdGx5KSBoYXMgYmVlbiB0aGF0IGd1ZXN0
cyBzaG91bGRu4oCZdCByZWFsbHkgYmUgc3Bpbm5pbmcgb24gdGhhdCByZWdpc3RlciBhbnl3YXku
ICBCdXQgaXQgc291bmRzIGZyb20gSnVsaWVu4oCZcyBvdGhlciBlbWFpbCB0aGF0IHBlcmhhcHMg
c3Bpbm5pbmcgb24gdGhlIHJlZ2lzdGVyIGlzIGV4YWN0bHkgd2hhdCBuZXdlciB2ZXJzaW9ucyBv
ZiBMaW51eCBkbyDigJQgc28gTGludXggd291bGQgY2VydGFpbmx5IGhhbmcgb24gc3VjaCBzeXN0
ZW1zIGlmIFN0ZWZhbm/igJlzIGFzc2VydGlvbiBhYm91dCB0aGUgbG93IG51bWJlciBvZiBYZW4t
cmVsYXRlZCBpbnRlcnJ1cHRzIGlzIHRydWUuDQoNCklmIHRoZSBsYXR0ZXIgaXMgdHJ1ZSwgdGhl
biBpdCBzb3VuZHMgbGlrZSBhZGRyZXNzaW5nIHRoZSBkZWFkbG9jayBpc3N1ZSB3aWxsIGJlIG5l
Y2Vzc2FyeT8gIEFuZCBzbyBlZmZvcnQgbmVlZHMgdG8gYmUgcHV0IHRvd2FyZHMgZmlndXJpbmcg
b3V0IGhvdyB0byBtaW5pbWl6ZSBqaXR0ZXIgZHVlIHRvIFhlbi1yZWxhdGVkIElQSXMuDQoNCldl
aSBYdSAvIFBlbmcgRmFuLCBhbnkgb3BpbmlvbnMgaGVyZT8NCg0KIC0gR2VvcmdlDQoNCg==


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 18:04:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 18:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLW6Z-0004Hf-BN; Mon, 06 Apr 2020 18:04:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8YOW=5W=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLW6Y-0004Ha-F2
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 18:04:14 +0000
X-Inumbo-ID: 05817e4c-7831-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 05817e4c-7831-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 18:04:13 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 12565B254;
 Mon,  6 Apr 2020 18:04:11 +0000 (UTC)
Subject: Re: [PATCH 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: paul@xen.org
References: <20200327185012.1795-1-paul@xen.org>
 <20200327185012.1795-2-paul@xen.org>
 <5a26a89a-6422-b41d-daac-8f33a48ae23b@xen.org>
 <002201d609d0$55a76690$00f633b0$@xen.org>
 <acd5fee0-2bf6-4573-8467-38d24827ca1f@xen.org>
 <001701d60bed$25606f80$70214e80$@xen.org>
 <e2e25069-36e5-b965-8f66-59a460369e88@xen.org>
 <002701d60bf4$4b640460$e22c0d20$@xen.org>
 <ac273b12-36f4-ca5c-c18b-7a59d2b84e2e@xen.org>
 <002801d60bfe$fab5de70$f0219b50$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <0d53ddbd-461d-99a8-5534-5d84da7524b7@suse.com>
Date: Mon, 6 Apr 2020 14:43:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <002801d60bfe$fab5de70$f0219b50$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.2020 12:34, Paul Durrant wrote:
>>> Do you think this should also appear in a comment? Do we really care? Nothing fundamentally prevents
>> the mechanism being used for HVM state, but that may introduce an ordering dependency.
>>
>> I don't particularly like the idea to let the contributor decide where
>> "HVM context" or as part of the "Domain context".
>>
>> This is  going to result to unwanted dependency and possibly
>> bikeshedding on where they should be saved.
>>
>> My preference would be to mark the existing framework as deprecated and
>> force all the new states to be saved as part of the new "Domain Context".
> 
> I'm ok with that. Any others have any opinion to the contrary?

Well, not in principle, but I won't have a firm opinion until I've
actually looked at (relevant parts of) the patches.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 18:06:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 18:06:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLW93-0004PE-QO; Mon, 06 Apr 2020 18:06:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9GA=5W=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jLW92-0004OL-SV
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 18:06:48 +0000
X-Inumbo-ID: 61a36ece-7831-11ea-b4f4-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 61a36ece-7831-11ea-b4f4-bc764e2007e4;
 Mon, 06 Apr 2020 18:06:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586196407;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=EmCYMXXV/FWMrAk5qPTjZe9gmczYRMuUlGuyXr4tuRs=;
 b=Z3fhDzPzEee0JdVwKZ422ubkOCJCsWCcB1YDoWKDQdwp//581H9ORTYl
 thGwTQRVrqDwvT4sjqHpIH0TajinNsJHvCoB3Er/PAp5Fbk69L/Larq+i
 hbktqsc4nqqx8Bk2UONWHcDysJE5jeUf4WaVfaMkpUkbpoeRFvNTuRM9m k=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: yhqYQjmxDg4Vnxs2f6GQSkPyU/dkx1k58Ai/uxWGJsJR3WEEcYBdCG+1MILtmwaxIxcbXK74X7
 ukU4VN6789gNHO/YdEmnet0A9U4zPBsoDt6SIKrmvx2njYfr2BFz/LjoNaz+xRwuXRqWKUyWjQ
 M3klRCUgpoy81lsvPYPRWGDEK3FAz1t6bUkS5X5fOCBLDeaAXSZCpgZu4Ust7gjm42hXvz+c5f
 GTb8FfgikOblaA4p9oZLbbzy/Y7TMm5v3tn85ZJUJM+ZkueJTgLZEVK7Uj2+8uS/w6eEORP/Cp
 yMw=
X-SBRS: 2.7
X-MesageID: 15919822
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,352,1580792400"; d="scan'208";a="15919822"
Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: Harsha Shamsundara Havanur <havanur@amazon.com>,
 <xen-devel@lists.xenproject.org>
References: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <6a112896-9d22-eca1-f406-7bfa3f047b40@citrix.com>
Date: Mon, 6 Apr 2020 19:06:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06/04/2020 18:46, Harsha Shamsundara Havanur wrote:
> It was observed that PCI MMIO and/or IO BARs were programmed with
> BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> register) enabled, during PCI setup phase. This resulted in
> spurious and premature bus transactions as soon as the lower bar of
> the 64 bit bar is programmed. It is highly recommended that BARs be
> programmed whilst decode bits are cleared to avoid spurious bus
> transactions.

What kinds of spurious transactions?

Keeping memory and I/O decoding disabled until the BARs are set up is a
no-brainer, but busmastering is a more complicated subject.  Therefore,
it would be helpful to know exactly what you've seen in the way of
spurious transactions.

>
> This patch address the issue by deferring enablement of memory and
> I/O decode in command register until all the resources, like interrupts
> I/O and/or MMIO BARs for all the PCI device functions are programmed.
> PCI bus memory and I/O space is enabled in command register after
> all the resources like interrupts, I/O and/or MMIO BARs are
> programmed for all valid device functions. PCI BUS MASTER is kept
> disabled in the bootloader as this needs to be enabled by the guest
> OS driver once it initializes and takes control of the device.

Has this been tested with an Intel integrated graphics card?  These have
a habit of hitting a platform reset line if busmaster is ever disabled.

A lot of this will depend on what Qemu does behind the scenes, and
whether disabling busmastering gets reflected in the real device.

>
> Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
> Ack-by: Paul Durrant <pdurrant@amazon.com>

Acked-by

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 18:47:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 18:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLWmK-0007hg-9q; Mon, 06 Apr 2020 18:47:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=glNc=5W=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLWmJ-0007hb-0s
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 18:47:23 +0000
X-Inumbo-ID: 0c84dce2-7837-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0c84dce2-7837-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 18:47:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2kMAMW9JGbdWzdSupY+MQQ3YO0zAP6olnmtHB0HOmSc=; b=fSEUM/Aa6OBwYi/jFWpWmZW0Ms
 QrWoqnZrPopokx3F/YVMIfsr/nNG+KKtGYbjmva4I5X0T7H2aYkeXuyLhig3PgmQrDgtcQwuvDa5j
 4Bou95Y09vaKR9Xyyk0qjz9/oaPmKb/zjkb5IzkkCJ3Iai1YYMFY9KeipJTeQew1cUc4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLWmD-0000es-1d; Mon, 06 Apr 2020 18:47:17 +0000
Received: from 54-240-197-231.amazon.com ([54.240.197.231]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLWmC-00088G-MA; Mon, 06 Apr 2020 18:47:16 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: George Dunlap <George.Dunlap@citrix.com>,
 Julien Grall <julien.grall.oss@gmail.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
Date: Mon, 6 Apr 2020 19:47:14 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 06/04/2020 18:58, George Dunlap wrote:
> 
> 
>> On Apr 3, 2020, at 9:27 PM, Julien Grall <julien.grall.oss@gmail.com> wrote:
>>
>> On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>
>>> On Thu, 2 Apr 2020, Julien Grall wrote:
>>>> As we discussed on Tuesday, the cost for other vCPUs is only going to be a
>>>> trap to the hypervisor and then back again. The cost is likely smaller than
>>>> receiving and forwarding an interrupt.
>>>>
>>>> You actually agreed on this analysis. So can you enlighten me as to why
>>>> receiving an interrupt is a not problem for latency but this is?
>>>
>>> My answer was that the difference is that an operating system can
>>> disable interrupts, but it cannot disable receiving this special IPI.
>>
>> An OS can *only* disable its own interrupts, yet interrupts will still
>> be received by Xen even if the interrupts are masked at the processor
>> (e.g local_irq_disable()).
>>
>> You would need to disable interrupts one by one as the GIC level (use
>> ICENABLER) in order to not receive any interrupts. Yet, Xen may still
>> receive interrupts for operational purposes (e.g serial, console,
>> maintainance IRQ...). So trap will happen.
> 
> I think Stefano’s assertion is that the users he has in mind will be configuring the system such that RT workloads get a minimum number of hypervisor-related interrupts possible.  On a 4-core system, you could  have non-RT workloads running on cores 0-1, and RT workloads running with the NULL scheduler on cores 2-3.  In such a system, you’d obviously arrange that serial and maintenance IRQs are delivered to cores 0-1.
Well maintenance IRQs are per pCPU so you can't route to another one...

But, I think you missed my point that local_irq_disable() from the guest 
will not prevent the hypervisor to receive interrupts *even* the one 
routed to the vCPU itself. They will just not be delivered to the guest 
context until local_irq_enable() is called.

> 
> Julien, I think your argument above about interrupts somewhat undermines your point about deadlock.  Your basic argument is, that a guest will be interrupted by Xen quite frequently anyway for lots of reasons; adding one more to the list shouldn’t measurably increase the jitter.  But if it’s true that a guest will be interrupted by Xen frequently, then deadlock shouldn’t be much of an issue; and insofar as deadlock is an issue, it’s because there were no interrupts — and thus, adding an extra IPI will have a statistically significant effect on jitter.

I presented two way to disable interrupts because Stefano's e-mail was 
not clear enough which one he was referring to. So I was hoping to safe 
some round-trip, but it looks like I muddle my point.

If Stefano was referring to critical sections where interrupts are 
masked using local_irq_disable(). Then, you are not going to limit the 
numbers of traps at all (see why above). So the point here was moot.

I don't believe Stefano was referring to the second case as disabling 
interrupts at the GIC level will require to trap in the hypervisor. But 
I thought I would mention it.

Regarding the livelock (Marc pointed out it wasn't a deadlock), there 
are multiple conflicting use cases. In an ideal world, there will be 
limited reasons to interrupts the guest. And yes it will result to a 
livelock.

In a less ideal world, there will some time be interruptions. But you 
don't know when. If you look at determinism then, I am afraid that 
Stefano's implementation is not because you don't know when the vCPU 
will exit.

> 
> On the other had, Stefano’s argument about deadlock (if I understand him correctly) has been that guests shouldn’t really be spinning on that register anyway.  But it sounds from Julien’s other email that perhaps spinning on the register is exactly what newer versions of Linux do — so Linux would certainly hang on such systems if Stefano’s assertion about the low number of Xen-related interrupts is true.

Rather than playing the game "one person's word against the other 
person's word", from Linux 5.4:

do {
     unsigned long flags;

     /*
      * Wait until we're out of the critical section.  This might
      * give the wrong answer due to the lack of memory barriers.
      */
     while (irqd_irq_inprogress(&desc->irq_data))
         cpu_relax();

     /* Ok, that indicated we're done: double-check carefully. */
     raw_spin_lock_irqsave(&desc->lock, flags);
     inprogress = irqd_irq_inprogress(&desc->irq_data);

     /*
      * If requested and supported, check at the chip whether it
      * is in flight at the hardware level, i.e. already pending
      * in a CPU and waiting for service and acknowledge.
      */
     if (!inprogress && sync_chip) {
         /*
          * Ignore the return code. inprogress is only updated
          * when the chip supports it.
          */
         __irq_get_irqchip_state(irqd, IRQCHIP_STATE_ACTIVE,
                                 &inprogress);
     }
     raw_spin_unlock_irqrestore(&desc->lock, flags);
     /* Oops, that failed? */
} while (inprogress);

> 
> If the latter is true, then it sounds like addressing the deadlock issue will be necessary?  And so effort needs to be put towards figuring out how to minimize jitter due to Xen-related IPIs.
Here what I wrote before:

"
A few remarks:
     * The function do_nothing() is basically a NOP.
     * I am suggesting to use smp_call_function() rather
smp_send_event_check_cpu() is because we need to know when the vCPU has
synchronized the LRs. As the function do_nothing() will be call
afterwards, then we know the the snapshot of the LRs has been done
     * It would be possible to everything in one vCPU.
     * We can possibly optimize it for the SGIs/PPIs case

This is still not perfect, but I don't think the performance would be
that bad.
"

"
But if your concern is to disturb a vCPU which has interrupts
disabled. Then there is way to mitigate this in an implementation, you
can easily know whether there are interrupts inflight at a given point
for a given vCPU. So you can avoid to IPI if you know there is no
interrupts potentially active.
"

I am looking forward to hear about the potential improvements.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 19:17:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 19:17:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLXFW-0001jV-Vk; Mon, 06 Apr 2020 19:17:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=zgfQ=5W=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLXFV-0001jQ-NL
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 19:17:33 +0000
X-Inumbo-ID: 440288aa-783b-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 440288aa-783b-11ea-b58d-bc764e2007e4;
 Mon, 06 Apr 2020 19:17:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=TSPCe5hrxMKSDQ3302iyrOyRnGWIXfN5ApgMKS7ALGM=; b=nuRRF3BgCbTACKUvgpE9ySVsL
 wuqxk6H9P2CVgpDYZ43adgwyXmfuAr6ghlGnncbjkp2xZYaArHt+GF5VeyBnlrsuq6XvJfntgLnoZ
 22+gI9FgZbDqL8wfOh2M3Ogl0X7upyvxleNBVpTKRt1hlgbrVXM5cL1asVxyDRkK0AsKU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLXFU-0001GV-G1; Mon, 06 Apr 2020 19:17:32 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLXFU-000483-6W; Mon, 06 Apr 2020 19:17:32 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLXFU-0008Ce-5v; Mon, 06 Apr 2020 19:17:32 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149462-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149462: all pass - PUSHED
X-Osstest-Versions-This: ovmf=ee026ea78b0e32a9ffbaf0040afe91de8ae2179c
X-Osstest-Versions-That: ovmf=ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 06 Apr 2020 19:17:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

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

Last test of basis   149393  2020-04-03 17:09:33 Z    3 days
Testing same since   149462  2020-04-06 12:09:20 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Leif Lindholm <leif@nuviainc.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   ef5dcba975..ee026ea78b  ee026ea78b0e32a9ffbaf0040afe91de8ae2179c -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Mon Apr 06 23:49:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Apr 2020 23:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLbUp-0006dH-Ou; Mon, 06 Apr 2020 23:49:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=zgfQ=5W=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLbUp-0006dC-9y
 for xen-devel@lists.xenproject.org; Mon, 06 Apr 2020 23:49:39 +0000
X-Inumbo-ID: 4415a3c4-7861-11ea-804c-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4415a3c4-7861-11ea-804c-12813bfff9fa;
 Mon, 06 Apr 2020 23:49:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=7JYoRjY6MmpCkL1PnfXd6ekJEtiSfiuG8TEpLzN/8P8=; b=w/eGI05qkhDu23ymfzWe5H9l5
 8JstnMXbiZNRCfNGrJTj0A6RwbEuQSfwY8r+cxX+7K/6gMrV15DMtdjO0vOw7HPJxgdmhonzcQrDa
 qEuSCUgqDA/C/T9dJ68r0hWgftdldl3QsQWBMVudGDlzt1ehYQGMuNeyPfOwqO/8sBPvs=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLbUj-0006SD-HN; Mon, 06 Apr 2020 23:49:33 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLbUi-0007FF-VI; Mon, 06 Apr 2020 23:49:33 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLbUi-0006ff-Um; Mon, 06 Apr 2020 23:49:32 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149458-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149458: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-amd:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 06 Apr 2020 23:49:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds   16 guest-localmigrate fail in 149409 pass in 149458
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149409

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-amd 18 guest-localmigrate/x10 fail baseline untested
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail in 149409 baseline untested
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 144861
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  112 days
Failing since        144880  2019-12-16 20:07:08 Z  112 days  323 attempts
Testing same since   149409  2020-04-04 06:19:20 Z    2 days    4 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Elazar Leibovich <elazar.leibovich@oracle.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Liran Alon <liran.alon@oracle.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Luwei Kang <luwei.kang@intel.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Bolshakov <r.bolshakov@yadro.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 56901 lines long.)


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 03:05:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 03:05:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLeXv-0000hc-GQ; Tue, 07 Apr 2020 03:05:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=VNrn=5X=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLeXt-0000hW-R9
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 03:05:01 +0000
X-Inumbo-ID: 8e6ebd96-787c-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8e6ebd96-787c-11ea-9e09-bc764e2007e4;
 Tue, 07 Apr 2020 03:04:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=uYl1M36B6FDZ+5tHmuWX+ejv9x7wnKhiNxBUQyLRn3k=; b=F2Apj2Ir30r7D+fhretMQ2rHL
 lMWDWPfVyq5pbNL1622OY8VlJQIDCTSZjddrS6yjSSKuxndmK4zGEbC2YUd+rVYrghqI408E6a0pu
 A0T5XPgFzt+5qAQOYFJYAuSNkJWoFOXzVXRo//+kxrR4FgcOzquFcu35MOCGWESZlzGdw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLeXm-000747-Ih; Tue, 07 Apr 2020 03:04:54 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLeXl-00084e-W0; Tue, 07 Apr 2020 03:04:54 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLeXl-0004jR-VF; Tue, 07 Apr 2020 03:04:53 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149469-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149469: regressions - trouble: broken/fail/pass
X-Osstest-Failures: linux-linus:test-amd64-amd64-dom0pvh-xl-amd:<job
 status>:broken:regression
 linux-linus:test-amd64-i386-libvirt-pair:<job status>:broken:regression
 linux-linus:test-amd64-amd64-dom0pvh-xl-amd:host-install(4):broken:regression
 linux-linus:test-amd64-i386-libvirt-pair:host-install/dst_host(5):broken:regression
 linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-examine:reboot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-raw:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:xen-boot:fail:regression
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=b6ff10700d1bf33c4323d34eca1e80bc8a69f9f5
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 07 Apr 2020 03:04:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-dom0pvh-xl-amd    <job status>                 broken
 test-amd64-i386-libvirt-pair    <job status>                 broken
 test-amd64-amd64-dom0pvh-xl-amd  4 host-install(4)     broken REGR. vs. 149238
 test-amd64-i386-libvirt-pair 5 host-install/dst_host(5) broken REGR. vs. 149238
 test-amd64-i386-xl-pvshim     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-examine       8 reboot                   fail REGR. vs. 149238
 test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-shadow     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-libvirt       7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-pair         10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-pair         11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-libvirt-xsm   7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl            7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-raw        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-xsm        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-freebsd10-i386  7 xen-boot               fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot          fail REGR. vs. 149238

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 15 guest-saverestore        fail like 149238
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149238
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149238
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                b6ff10700d1bf33c4323d34eca1e80bc8a69f9f5
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    6 days
Failing since        149266  2020-04-01 03:55:53 Z    5 days    8 attempts
Testing same since   149469  2020-04-06 17:45:44 Z    0 days    1 attempts

------------------------------------------------------------
1645 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       fail    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              broken  
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 broken  
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       fail    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    fail    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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

broken-job test-amd64-amd64-dom0pvh-xl-amd broken
broken-job test-amd64-i386-libvirt-pair broken
broken-step test-amd64-amd64-dom0pvh-xl-amd host-install(4)
broken-step test-amd64-i386-libvirt-pair host-install/dst_host(5)

Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 05:27:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 05:27:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLglf-0003pW-Bb; Tue, 07 Apr 2020 05:27:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=NSkr=5X=redhat.com=armbru@srs-us1.protection.inumbo.net>)
 id 1jLgld-0003pR-Kk
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 05:27:21 +0000
X-Inumbo-ID: 73551709-7890-11ea-806f-12813bfff9fa
Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id 73551709-7890-11ea-806f-12813bfff9fa;
 Tue, 07 Apr 2020 05:27:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1586237239;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=5fGOb894axs0XJifkvixqa9caiiR06E1mZ3Cl7g6RL0=;
 b=MPGsUvg+5CPu+3cenDoNG8AUhrwKyEgvrT9r7gP11wY9/uyBDA+DB2Ms75JT9m25HOlKX8
 PG9wzZPLdb/lRQD9IqjT0bgNkZZOdcFKYG+Xo5/h8h2SGa1X7I5d+phM3mbLoDFqIi/tp3
 qd/gROWYxCj7uS/4TRsJ0nsOu75Ui3c=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-154-08nPnoCOPy27oa8vmU-_wg-1; Tue, 07 Apr 2020 01:27:17 -0400
X-MC-Unique: 08nPnoCOPy27oa8vmU-_wg-1
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com
 [10.5.11.16])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E5852800D50;
 Tue,  7 Apr 2020 05:27:15 +0000 (UTC)
Received: from blackfin.pond.sub.org (ovpn-113-20.ams2.redhat.com
 [10.36.113.20])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id 6FED15C1BB;
 Tue,  7 Apr 2020 05:27:15 +0000 (UTC)
Received: by blackfin.pond.sub.org (Postfix, from userid 1000)
 id E3E9811385C8; Tue,  7 Apr 2020 07:27:13 +0200 (CEST)
From: Markus Armbruster <armbru@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [PATCH for-5.0] xen-block: Fix uninitialized variable
References: <20200406164207.1446817-1-anthony.perard@citrix.com>
 <325e0ffb-2f1b-cbfd-6b24-0d912a9aabe2@redhat.com>
 <20200406171637.GU4088@perard.uk.xensource.com>
Date: Tue, 07 Apr 2020 07:27:13 +0200
In-Reply-To: <20200406171637.GU4088@perard.uk.xensource.com> (Anthony PERARD's
 message of "Mon, 6 Apr 2020 18:16:37 +0100")
Message-ID: <87imibzwzy.fsf@dusky.pond.sub.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefano Stabellini <sstabellini@kernel.org>,
 qemu-block@nongnu.org, Paul Durrant <paul@xen.org>, qemu-devel@nongnu.org,
 Max Reitz <mreitz@redhat.com>, xen-devel@lists.xenproject.org,
 Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@redhat.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Anthony PERARD <anthony.perard@citrix.com> writes:

> On Mon, Apr 06, 2020 at 06:50:41PM +0200, Philippe Mathieu-Daud=C3=A9 wro=
te:
>> On 4/6/20 6:42 PM, Anthony PERARD wrote:
>> > Since 7f5d9b206d1e ("object-add: don't create return value if
>> > failed"), qmp_object_add() don't write any value in 'ret_data', thus
>> > has random data. Then qobject_unref() fails and abort().
>> >=20
>> > Fix by initialising 'ret_data' properly.
>>=20
>> Or move qobject_unref() after the error check?
>>=20
>> -- >8 --
>> diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
>> index 07bb32e22b..f3f1cbef65 100644
>> --- a/hw/block/xen-block.c
>> +++ b/hw/block/xen-block.c
>> @@ -869,7 +869,6 @@ static XenBlockIOThread *xen_block_iothread_create(c=
onst
>> char *id,
>>      qdict_put_str(opts, "id", id);
>>      qmp_object_add(opts, &ret_data, &local_err);
>>      qobject_unref(opts);
>> -    qobject_unref(ret_data);
>>=20
>>      if (local_err) {
>>          error_propagate(errp, local_err);
>> @@ -878,6 +877,7 @@ static XenBlockIOThread *xen_block_iothread_create(c=
onst
>> char *id,
>>          g_free(iothread);
>>          return NULL;
>>      }
>> +    qobject_unref(ret_data);
>
> That won't help, qmp_object_add() doesn't change the value of ret_data
> at all. The other users of qmp_object_add() passes an initialised
> 'ret_data', so we should do the same I think.

Since the QMP core does it, other callers should do it, too.

For QAPI commands that don't return anything, the marshaller should not
use @ret_data, let alone store through it.  qmp_object_add() complies.
Thus, assert(!ret_data) would do.  qobject_unref(ret_data) is also
correct.

Reviewed-by: Markus Armbruster <armbru@redhat.com>



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 06:37:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 06:37:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLhrF-0001Go-8e; Tue, 07 Apr 2020 06:37:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=VNrn=5X=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLhrD-0001Gj-Q8
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 06:37:11 +0000
X-Inumbo-ID: 3165f3e4-789a-11ea-8073-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3165f3e4-789a-11ea-8073-12813bfff9fa;
 Tue, 07 Apr 2020 06:37:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=xdP5Ij8tNPomp6+WPHN1QD8/GpsHeTc06Ub+tCT/oI0=; b=2pF2sKn2kMaOIdkIb/QBTzGWQ
 Dv++FUCQpJaMY2Wi5a3iYww3W3JzHoqPdZ91pxKpMvwrcYevxdQbCD1Em2chsqAn/5d6C3tkGcERK
 MKDeTea6MrvyeRcIRVHFTax1UIwnWsz53AWVd7JZnbq+/1aPh6LQAabnAJCTU74y+HxLA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLhr5-000397-Ec; Tue, 07 Apr 2020 06:37:03 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLhr5-0006Ue-3Q; Tue, 07 Apr 2020 06:37:03 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLhr5-0004Q3-2U; Tue, 07 Apr 2020 06:37:03 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149482-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149482: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=88011ed280c4f946a7b8e7ffcea2335eb075de60
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 07 Apr 2020 06:37:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              88011ed280c4f946a7b8e7ffcea2335eb075de60
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   81 days
Failing since        146211  2020-01-18 04:18:52 Z   80 days   77 attempts
Testing same since   149482  2020-04-07 04:18:51 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 13213 lines long.)


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 07:00:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 07:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLiDk-0003eK-8H; Tue, 07 Apr 2020 07:00:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=VNrn=5X=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLiDi-0003eF-RI
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 07:00:26 +0000
X-Inumbo-ID: 74817100-789d-11ea-8076-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 74817100-789d-11ea-8076-12813bfff9fa;
 Tue, 07 Apr 2020 07:00:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mSVALuns/ZDhpkbXmje5gyWX20bmfLej8JK3kt24bg8=; b=XWzKxBJ/DVL3Z+HTUPEkbfylZ
 q9jzLZen8cTSVM5H+82kKfbvL5oXldx8WVSy9GOreh/biZciRrrSNJ5qYKCYlVoYaGKwHhf6e8epm
 +tw+y1VdLiCyltrc69odmPilCh+Vk4aCoK8mdvuA7K0WZJ0i3+RsxzxSXgmisq6LU3+wk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLiDg-0003bn-F4; Tue, 07 Apr 2020 07:00:24 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLiDg-0007Id-24; Tue, 07 Apr 2020 07:00:24 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLiDg-0001EW-0l; Tue, 07 Apr 2020 07:00:24 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149477-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149477: all pass - PUSHED
X-Osstest-Versions-This: ovmf=48f0e94921d83b8204f1025412e071b000394f04
X-Osstest-Versions-That: ovmf=ee026ea78b0e32a9ffbaf0040afe91de8ae2179c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 07 Apr 2020 07:00:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 48f0e94921d83b8204f1025412e071b000394f04
baseline version:
 ovmf                 ee026ea78b0e32a9ffbaf0040afe91de8ae2179c

Last test of basis   149462  2020-04-06 12:09:20 Z    0 days
Testing same since   149477  2020-04-07 01:39:26 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Michael Kubacki <michael.kubacki@microsoft.com>
  Sean Brogan <sean.brogan@microsoft.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   ee026ea78b..48f0e94921  48f0e94921d83b8204f1025412e071b000394f04 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 07:33:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 07:33:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLijw-0006Tn-T9; Tue, 07 Apr 2020 07:33:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=xamf=5X=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLijv-0006Ti-L5
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 07:33:43 +0000
X-Inumbo-ID: 1b1a579e-78a2-11ea-83d8-bc764e2007e4
Received: from mail-ed1-x52a.google.com (unknown [2a00:1450:4864:20::52a])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1b1a579e-78a2-11ea-83d8-bc764e2007e4;
 Tue, 07 Apr 2020 07:33:42 +0000 (UTC)
Received: by mail-ed1-x52a.google.com with SMTP id cf14so2740037edb.13
 for <xen-devel@lists.xenproject.org>; Tue, 07 Apr 2020 00:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=Ftxk7s3a+m4QXLU226g63n99y4nDxX2y/xQ5q86Zf+Q=;
 b=mgjeBAs+a8483OGUVMKYrNbTRRc+cNx8/Vc6rIl6d1uTj5tPuyDD4CMTUIbTJhkO8u
 BIL2brLZTBHQ+9TTRRilOBAGaZbFpEipUyAfVc+NdTfdG770IwOAdqOWMrUxkTlEIbok
 9a3WlWbNOXnlh+vjLjBZP5qDLAYy0LjAT37dUZxAKSR5n1E7N4vFOpGO1oYmO5rl7K4T
 APfA0ebb51kEHUDEKRkFF5+wM4F5/t9Rib+1sdpeUNvPMTTl8eHp8a8M+NiGUYT1J+FX
 AL78IfbGg05h4A1/uDdv5HOpEttuozsxyesUq8VgzVjAGSIAHYd54tBOTiCI4sATglzw
 MaEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=Ftxk7s3a+m4QXLU226g63n99y4nDxX2y/xQ5q86Zf+Q=;
 b=uLoD8wEF/3jXuwxTBipAAU/58mwBCmxxHblgzLZhibimluIge9xcb2dEeD8WsPZcvd
 7Pn/KGLJblt8ku20g2XOhim+truG+iFhBo75PzYef0+kPbrz2Yoo/kUWDwcctwBC6jvJ
 PbtFVSIEElTyBTWewpI1GiL3IPqxAnhRWYPQULGTumhBIkJPallmFl6CPjCwyytLsCmB
 vjJhOM2/5vJstEcCOzIk6qgL1BDMR82nbawL9FF2glsUMcw/QwfHFiXWCcJvwxoEb7f1
 4eVdWk5eaONereLBkbdubnOn7zweCqlAQwxoYyBEEEQ6GF1lHtuJkTXTjDnwt6IbWc2j
 T1TA==
X-Gm-Message-State: AGi0Puaw13jEMGcJhw3sr3ZO6uRaPEAqHLN/Ym6CHpP/ahVE9eDecLYO
 tZS0y8B2bSPrJ8Rjyqtxj18=
X-Google-Smtp-Source: APiQypKfF8gpIMMiSXi0BSTTFpOoM7jQgJCCELmtJSXQkhYBpMG07SbBAd/Y+QNg0TacopBudKhM4w==
X-Received: by 2002:a17:907:2143:: with SMTP id
 rk3mr771035ejb.50.1586244821862; 
 Tue, 07 Apr 2020 00:33:41 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.188])
 by smtp.gmail.com with ESMTPSA id o27sm1769336ejc.23.2020.04.07.00.33.40
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 07 Apr 2020 00:33:41 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Andrew Cooper'" <andrew.cooper3@citrix.com>,
 "'Harsha Shamsundara Havanur'" <havanur@amazon.com>,
 <xen-devel@lists.xenproject.org>
References: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
 <6a112896-9d22-eca1-f406-7bfa3f047b40@citrix.com>
In-Reply-To: <6a112896-9d22-eca1-f406-7bfa3f047b40@citrix.com>
Subject: RE: [XEN PATCH] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Tue, 7 Apr 2020 08:33:39 +0100
Message-ID: <001301d60cae$dc3e94e0$94bbbea0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQLv5qvTmuvbc0jpqBdZKffFHl7s5gFvtzJgpi4QzNA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'Jan Beulich' <jbeulich@suse.com>, 'Wei Liu' <wl@xen.org>,
 =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of =
Andrew Cooper
> Sent: 06 April 2020 19:07
> To: Harsha Shamsundara Havanur <havanur@amazon.com>; =
xen-devel@lists.xenproject.org
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>; Wei Liu <wl@xen.org>; Jan =
Beulich <jbeulich@suse.com>;
> Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after =
all resource allocation
>=20
> On 06/04/2020 18:46, Harsha Shamsundara Havanur wrote:
> > It was observed that PCI MMIO and/or IO BARs were programmed with
> > BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> > register) enabled, during PCI setup phase. This resulted in
> > spurious and premature bus transactions as soon as the lower bar of
> > the 64 bit bar is programmed. It is highly recommended that BARs be
> > programmed whilst decode bits are cleared to avoid spurious bus
> > transactions.
>=20
> What kinds of spurious transactions?
>=20
> Keeping memory and I/O decoding disabled until the BARs are set up is =
a
> no-brainer, but busmastering is a more complicated subject.  =
Therefore,
> it would be helpful to know exactly what you've seen in the way of
> spurious transactions.
>=20

I think you know of some GPU h/w that doesn't necessarily stop DMAing =
after an FLR. There is no reason why hvmloader, or anything else until =
the function driver loads, needs BME to be on. As you say mem and io =
decodes are no-brainers, yet without this patch hvmloader enables them =
after the first BAR on the device is programmed, thus causing much fun =
for device models when the subsequent BARs are programmed.

> >
> > This patch address the issue by deferring enablement of memory and
> > I/O decode in command register until all the resources, like =
interrupts
> > I/O and/or MMIO BARs for all the PCI device functions are =
programmed.
> > PCI bus memory and I/O space is enabled in command register after
> > all the resources like interrupts, I/O and/or MMIO BARs are
> > programmed for all valid device functions. PCI BUS MASTER is kept
> > disabled in the bootloader as this needs to be enabled by the guest
> > OS driver once it initializes and takes control of the device.
>=20
> Has this been tested with an Intel integrated graphics card?  These =
have
> a habit of hitting a platform reset line if busmaster is ever =
disabled.
>=20

No, we don't have suitable h/w for that AFAIK. If that is the case then =
we ought to quirk it.

> A lot of this will depend on what Qemu does behind the scenes, and
> whether disabling busmastering gets reflected in the real device.
>=20

When I last looked at upstream QEMU modifications to the BME bit were =
echoed through.

> >
> > Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
> > Ack-by: Paul Durrant <pdurrant@amazon.com>
>=20
> Acked-by

This was a little premature as I have not yet looked at the re-based =
code.

  Paul

>=20
> ~Andrew




From xen-devel-bounces@lists.xenproject.org Tue Apr 07 07:49:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 07:49:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLiyV-0007Pr-5B; Tue, 07 Apr 2020 07:48:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=xamf=5X=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLiyU-0007Pm-F3
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 07:48:46 +0000
X-Inumbo-ID: 350825e4-78a4-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x531.google.com (unknown [2a00:1450:4864:20::531])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 350825e4-78a4-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 07:48:45 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id bd14so2810156edb.10
 for <xen-devel@lists.xenproject.org>; Tue, 07 Apr 2020 00:48:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=BpJsjoxc5HkdNx9gaBUk+4EZId6vwzHIBI/AbHwIbLk=;
 b=kEiSYJLJqpcbbK9n+iz6x+NLCjvysKGZRJRdLLp5+xTMk+YOieP8NHpQi/VJH48s/N
 AD0wqvzRs301XWSeDmuvArWwKGXLgX8uREYqcV7Jggh7U8h+ruLbzHlSan4VSC4XC7ZG
 o9cmJTEOCNk835LOTrWz7fB9vUlbqJf2R5I5gh/5jXA/ul2PkNrRNxu/zlhHUXtliy7T
 dfqU4Xa/NCmy86wt70u6N2QsfRPo+h5fx/PlxQUlrmNDS5HyTlqBaguor5aszAPsZlDQ
 dDCGDobohRx8ZmT0GCaW6yrvF+VEhvgct6NjfMfgig5o+TG/mU7V80G1Ac4Vnt1CzHMr
 rnTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=BpJsjoxc5HkdNx9gaBUk+4EZId6vwzHIBI/AbHwIbLk=;
 b=DQx3vMn4ex/TIrp6gGq1r7z2yppEB4FvDdliM46vXYDlgVERnFPjJazO3uVAZuZYRY
 u3rH9sRSWkkw1fL40K4DhDl/DjwhafhyJQI8Y+gmOSw8ksVFOWarTqVHBsjlvZSPRXSV
 xN4pBMwDbO39WlZqCCCMBNLjRf/AgAU0vsje82zUxOGLAjEPu3F7ZUxsKqAGtaTvoBTg
 ZfZZ42NnlLcH3yLqT0tCy/mtno+7CFsDUoEBbJEfHunRgOEAU57B/dJH9kTym11sxnC1
 zgGGUh2sKOz6gxWxtL5zXM0I2kCpnLQc7aEb+1xDbegUpOrtT4BUwItFvQ3XInJJLKcv
 Cr6A==
X-Gm-Message-State: AGi0PuZWBl3QQ3ZNu/SeeMRo8Dd8HNwz+hhE+FF6Jn/rcc4YzN9IqGn5
 oTXmcXZmBmnEVP2im+Npp6g=
X-Google-Smtp-Source: APiQypIqfX/9YqiiJF/sDHt9Z88sBfwWCDnWEIFfW6fopp1e2HaUFKMR9PVGHtuB1wC4jUsUZABzig==
X-Received: by 2002:a50:9d06:: with SMTP id v6mr833681ede.189.1586245724241;
 Tue, 07 Apr 2020 00:48:44 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id o27sm1772775ejc.23.2020.04.07.00.48.42
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 07 Apr 2020 00:48:43 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Harsha Shamsundara Havanur'" <havanur@amazon.com>,
 <xen-devel@lists.xenproject.org>
References: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
In-Reply-To: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
Subject: RE: [XEN PATCH] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Tue, 7 Apr 2020 08:48:42 +0100
Message-ID: <001501d60cb0$f60e0660$e22a1320$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQLv5qvTmuvbc0jpqBdZKffFHl7s5qY5kH1Q
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>, 'Jan Beulich' <jbeulich@suse.com>,
 'Wei Liu' <wl@xen.org>,
 =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of =
Harsha Shamsundara Havanur
> Sent: 06 April 2020 18:47
> To: xen-devel@lists.xenproject.org
> Cc: Wei Liu <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; =
Ian Jackson
> <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>; Harsha =
Shamsundara Havanur
> <havanur@amazon.com>; Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Subject: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all =
resource allocation
>=20
> It was observed that PCI MMIO and/or IO BARs were programmed with
> BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> register) enabled, during PCI setup phase. This resulted in
> spurious and premature bus transactions as soon as the lower bar of
> the 64 bit bar is programmed. It is highly recommended that BARs be
> programmed whilst decode bits are cleared to avoid spurious bus
> transactions.
>=20

It's not so much spurious transactions that are the issue. I think =
"spurious and premature bus transactions" should be replaced with =
"incorrect mappings being created".

I believe the PCI spec says all three bits should be clear after reset =
anyway, and BAR programming whilst decodes are enabled causes problems =
for emulators such as QEMU which need to create and destroy mappings =
between the gaddr being programming into the virtual BAR and the maddr =
programmed into the physical BAR.
Specifically the case we see is that a 64-bit memory BAR is programmed =
by writing the lower half and then the upper half. After the first write =
the BAR is mapped to an address under 4G that happens to contain RAM, =
which is displaced by the mapping. After the second write the BAR is =
re-mapped to the intended location but the RAM displaced by the other =
mapping is not restored. The OS then continues to boot and function =
until at some point it happens to try to use that RAM at which point it =
suffers a page fault and crashes. It was only by noticing that the =
faulting address lay within the transient BAR mapping that we figured =
out what was happening.

> This patch address the issue by deferring enablement of memory and
> I/O decode in command register until all the resources, like =
interrupts
> I/O and/or MMIO BARs for all the PCI device functions are programmed.
> PCI bus memory and I/O space is enabled in command register after
> all the resources like interrupts, I/O and/or MMIO BARs are
> programmed for all valid device functions. PCI BUS MASTER is kept
> disabled in the bootloader as this needs to be enabled by the guest
> OS driver once it initializes and takes control of the device.
>=20
> Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
> Ack-by: Paul Durrant <pdurrant@amazon.com>

With the comment fixed as I suggest, you can replace this with:

Reviewed-by: Paul Durrant <paul@xen.org>

> ---
>  tools/firmware/hvmloader/pci.c | 24 +++++++++++++++++++-----
>  1 file changed, 19 insertions(+), 5 deletions(-)
>=20
> diff --git a/tools/firmware/hvmloader/pci.c =
b/tools/firmware/hvmloader/pci.c
> index 0b708bf578..0f31866453 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -84,6 +84,7 @@ void pci_setup(void)
>      uint32_t vga_devfn =3D 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    uint8_t pci_devfn_decode_type[256] =3D {};
>=20
>      /* Resources assignable to PCI devices via BARs. */
>      struct resource {
> @@ -289,9 +290,14 @@ void pci_setup(void)
>                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
>          }
>=20
> -        /* Enable bus mastering. */
> +        /*
> +         * Disable bus mastering, memory and I/O space, which is =
typical device
> +         * reset state. It is recommended that BAR programming be =
done whilst
> +         * decode bits are cleared to avoid spurious DMAs and bus =
transactions.
> +         * Bus master should be enabled by guest driver when it deems =
fit.
> +         */
>          cmd =3D pci_readw(devfn, PCI_COMMAND);
> -        cmd |=3D PCI_COMMAND_MASTER;
> +        cmd &=3D ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | =
PCI_COMMAND_IO);
>          pci_writew(devfn, PCI_COMMAND, cmd);
>      }
>=20
> @@ -503,10 +509,9 @@ void pci_setup(void)
>          if ( (bar_reg =3D=3D PCI_ROM_ADDRESS) ||
>               ((bar_data & PCI_BASE_ADDRESS_SPACE) =3D=3D
>                PCI_BASE_ADDRESS_SPACE_MEMORY) )
> -            cmd |=3D PCI_COMMAND_MEMORY;
> +            pci_devfn_decode_type[devfn] |=3D PCI_COMMAND_MEMORY;
>          else
> -            cmd |=3D PCI_COMMAND_IO;
> -        pci_writew(devfn, PCI_COMMAND, cmd);
> +            pci_devfn_decode_type[devfn] |=3D PCI_COMMAND_IO;
>      }
>=20
>      if ( pci_hi_mem_start )
> @@ -530,6 +535,15 @@ void pci_setup(void)
>          cmd |=3D PCI_COMMAND_IO;
>          pci_writew(vga_devfn, PCI_COMMAND, cmd);
>      }
> +
> +    /* Enable memory and I/O space. */
> +    for ( devfn =3D 0; devfn < 256; devfn++ )
> +        if ( pci_devfn_decode_type[devfn] )
> +        {
> +            cmd =3D pci_readw(devfn, PCI_COMMAND);
> +            cmd |=3D pci_devfn_decode_type[devfn];
> +            pci_writew(devfn, PCI_COMMAND, cmd);
> +        }
>  }
>=20
>  /*
> --
> 2.16.6
>=20




From xen-devel-bounces@lists.xenproject.org Tue Apr 07 07:57:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 07:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLj6x-0008GO-1p; Tue, 07 Apr 2020 07:57:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=xamf=5X=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLj6v-0008GJ-Ih
 for xen-devel@lists.xen.org; Tue, 07 Apr 2020 07:57:29 +0000
X-Inumbo-ID: 6cfd839e-78a5-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x543.google.com (unknown [2a00:1450:4864:20::543])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6cfd839e-78a5-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 07:57:28 +0000 (UTC)
Received: by mail-ed1-x543.google.com with SMTP id bd14so2837302edb.10
 for <xen-devel@lists.xen.org>; Tue, 07 Apr 2020 00:57:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=Z7YRSb4yLjZs81UPY/uAg5rHoSzHk+7pDkG4BTJpYdw=;
 b=HtdIcLr0ShEMyyTU5DzMnimrhfjHxudent5A2IpjW+WiJbtTwDDPEYPpxtZYZM/yLE
 ivET7vU6doYmqm8VwKni851ibBg6btzi/y3TzVlRPy0tTgiOFvzeysECMxfewIniUbOR
 4OHFV5fn770HzTiwrDBJAJWnZriyP6Za996Xc0aT7gRk32hxPYL8UkAIiVerHWgtj7Zn
 KN1ORToW03VWv8/Ov6UnIjXBdYRs4hO6JHJulNaxfwT1F7DL3ka60GfmoUBfzGt0xOU9
 zMnMUagrm59e33cAAPkO22W3s5iNFNRFQ8Si0jzwDDtFwdcAikMdmNPlPrh+iA2B5XfI
 idFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=Z7YRSb4yLjZs81UPY/uAg5rHoSzHk+7pDkG4BTJpYdw=;
 b=JleZq/GDyRCe3s7SBMn6sN4qSMeGMB+5K9A0/aCE/d2OITZmAbdCiOau8AeRgzccvm
 bCXB9n19pSNzgx6msPS8O8YPVLts6RMNGFZg216NItQYMRlu9GuOl5F1TPo3N0ZtxzyY
 z0gOyiyS+LS0w5IoAiXa+8Hgu/bXkeFcN6XxK8ZNKJKcjzAFYcBSNX8X8HmMiPXmpby/
 sJHzNtUt20z4OtPvaH6bJOGlclcrLfPptll+sYfddJ6yhz4EwesAQWnOYBsYiyPDEVYZ
 d0VvjR47QaMfgPSqJq/fklsd5w9YGTa+9UJ+29rvxwj7nUz/r5HLi/Qxc+7GOxZVdk1M
 berw==
X-Gm-Message-State: AGi0PuY0zFyO1xPJG8TuPaj1Ww9WhhOR0Si0wNKaVKUy7/ntZmfK5pgO
 SG+aZha4J3BtHMlPP0ZJlhs=
X-Google-Smtp-Source: APiQypL94iRtfr+RPm3FB+rUuthS5tgF/qEmQ1bC2Jh7dpPTQVTQTUlhSVh9Cpwbm215iPr3O6DcWA==
X-Received: by 2002:a17:907:2148:: with SMTP id
 rk8mr822305ejb.121.1586246247730; 
 Tue, 07 Apr 2020 00:57:27 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id o15sm3172337ejb.71.2020.04.07.00.57.26
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 07 Apr 2020 00:57:27 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Tamas K Lengyel'" <tamas.k.lengyel@gmail.com>,
 "'Andrew Cooper'" <andrew.cooper3@citrix.com>
References: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
 <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
 <CABfawhn_hw=o5j+G9VfqPK6opytqt=q2-cz4GjNgCTA5zBvNrA@mail.gmail.com>
 <6bb7eb58-01c6-00e4-672e-83d5fcb87ea0@citrix.com>
 <CABfawh=6z-pxgrj1M3JbG-9H=iR78rTwt8+MUf_6-Sd5kqyhdA@mail.gmail.com>
In-Reply-To: <CABfawh=6z-pxgrj1M3JbG-9H=iR78rTwt8+MUf_6-Sd5kqyhdA@mail.gmail.com>
Subject: RE: Live migration and PV device handling
Date: Tue, 7 Apr 2020 08:57:24 +0100
Message-ID: <001701d60cb2$2e1b2050$8a5160f0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJ9hFEeoa99jEIZ37IjX6uiVjJ3WQHz1sx0Aou5H5YBoD4wYAHAlangpt9WlvA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Anastassios Nanos' <anastassios.nanos@sunlight.io>,
 'Xen-devel' <xen-devel@lists.xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of =
Tamas K Lengyel
> Sent: 06 April 2020 18:31
> To: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Xen-devel <xen-devel@lists.xen.org>; Anastassios Nanos =
<anastassios.nanos@sunlight.io>
> Subject: Re: Live migration and PV device handling
>=20
> On Mon, Apr 6, 2020 at 11:24 AM Andrew Cooper =
<andrew.cooper3@citrix.com> wrote:
> >
> > On 06/04/2020 18:16, Tamas K Lengyel wrote:
> > > On Fri, Apr 3, 2020 at 6:44 AM Andrew Cooper =
<andrew.cooper3@citrix.com> wrote:
> > >> On 03/04/2020 13:32, Anastassios Nanos wrote:
> > >>> Hi all,
> > >>>
> > >>> I am trying to understand how live-migration happens in xen. I =
am
> > >>> looking in the HVM guest case and I have dug into the relevant =
parts
> > >>> of the toolstack and the hypervisor regarding memory, vCPU =
context
> > >>> etc.
> > >>>
> > >>> In particular, I am interested in how PV device migration =
happens. I
> > >>> assume that the guest is not aware of any suspend/resume =
operations
> > >>> being done
> > >> Sadly, this assumption is not correct.  HVM guests with PV =
drivers
> > >> currently have to be aware in exactly the same way as PV guests.
> > >>
> > >> Work is in progress to try and address this.  See
> > >> =
https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3D775a02452d=
df3a6889690de90b1a94eb29c3c732
> > >> (sorry - for some reason that doc isn't being rendered properly =
in
> > >> https://xenbits.xen.org/docs/ )
> > > That proposal is very interesting - first time it came across my =
radar
> > > - but I dislike the idea that domain IDs need to be preserved for
> > > uncooperative migration to work.
> >
> > The above restriction is necessary to work with existing guests, =
which
> > is an implementation requirement of the folks driving the work.
> >
> > > Ideally I would be able to take
> > > advantage of the same plumbing to perform forking of VMs with PV
> > > drivers where preserving the domain id is impossible since its =
still
> > > in use.
> >
> > We would of course like to make changes to remove the above =
restriction
> > in the longterm.  The problem is that it is not a trivial thing to =
fix.
> > Various things were discussed in Chicago, but I don't recall if any =
of
> > the plans made their way onto xen-devel.
>=20
> Yea I imagine trying to get this to work with existing PV drivers is
> not possible in any other way.

No, as the doc says, the domid forms part of the protocol, hence being =
visible to the guest, and the guest may sample and use the value when =
making certain hypercalls (only some enforce use of DOMID_SELF). Thus =
faking it without risking a guest crash is going to be difficult.

> But if we can update the PV driver code
> such that in the longterm it can work without preserving the domain
> ID, that would be worthwhile.
>=20

I think that ship has sailed. It would probably be simpler and cheaper =
to just get virtio working with Xen.

  Paul




From xen-devel-bounces@lists.xenproject.org Tue Apr 07 07:57:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 07:57:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLj78-0008HR-AK; Tue, 07 Apr 2020 07:57:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLj77-0008HE-3B
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 07:57:41 +0000
X-Inumbo-ID: 73df50e8-78a5-11ea-807b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 73df50e8-78a5-11ea-807b-12813bfff9fa;
 Tue, 07 Apr 2020 07:57:40 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 85E02AC37;
 Tue,  7 Apr 2020 07:57:38 +0000 (UTC)
Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: Harsha Shamsundara Havanur <havanur@amazon.com>
References: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7aa78875-a69d-08bd-a3c6-8df58de75bb8@suse.com>
Date: Tue, 7 Apr 2020 09:57:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.2020 19:46, Harsha Shamsundara Havanur wrote:
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -84,6 +84,7 @@ void pci_setup(void)
>      uint32_t vga_devfn = 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    uint8_t pci_devfn_decode_type[256] = {};

256 bytes of new stack space consumption looks quite a lot to me.
Did you consider using two 256-bit bitmaps instead, totaling to
an extra 64 bytes of stack space needed?

> It was observed that PCI MMIO and/or IO BARs were programmed with
> BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> register) enabled, during PCI setup phase. This resulted in
> spurious and premature bus transactions as soon as the lower bar of
> the 64 bit bar is programmed. It is highly recommended that BARs be
> programmed whilst decode bits are cleared to avoid spurious bus
> transactions.
> 
> This patch address the issue by deferring enablement of memory and
> I/O decode in command register until all the resources, like interrupts
> I/O and/or MMIO BARs for all the PCI device functions are programmed.
> PCI bus memory and I/O space is enabled in command register after
> all the resources like interrupts, I/O and/or MMIO BARs are
> programmed for all valid device functions. PCI BUS MASTER is kept
> disabled in the bootloader as this needs to be enabled by the guest
> OS driver once it initializes and takes control of the device.

Identifying the commit that introduced the issue, even if very old,
would be nice (bbfa22f8c9ca). From looking at current code I first
got the impression that it might have been a result of splitting a
loop, as the main issue is that the bits get set after a first
BAR got programmed, without considering that there might be more.
However, the original commit looks to have assumed that there's
at most one BAR or each type per device (which may have been true
back then for just the few emulated devices there were).

> @@ -289,9 +290,14 @@ void pci_setup(void)
>                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
>          }
>  
> -        /* Enable bus mastering. */
> +        /*
> +         * Disable bus mastering, memory and I/O space, which is typical device
> +         * reset state. It is recommended that BAR programming be done whilst
> +         * decode bits are cleared to avoid spurious DMAs and bus transactions.
> +         * Bus master should be enabled by guest driver when it deems fit.
> +         */
>          cmd = pci_readw(devfn, PCI_COMMAND);
> -        cmd |= PCI_COMMAND_MASTER;
> +        cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
>          pci_writew(devfn, PCI_COMMAND, cmd);
>      }

I agree with Andrew that there doesn't look to be a reason to
fiddle with bus mastering here. This is the more that you don't
re-enable it later.

I'm also curious whether there are actually devices getting
handed to the domain (and hence hvmloader) with the memory
and/or I/O decode bits set. This would look to be wrong to me,
and would perhaps want fixing wherever they get set prematurely.
(This isn't to say that, to be on the safe side, we couldn't
also re-clear them here. Maybe there should be a warning issued
if either bit is set?)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 08:05:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 08:05:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLjEi-0001JY-Hw; Tue, 07 Apr 2020 08:05:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLjEh-0001JT-Kh
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 08:05:31 +0000
X-Inumbo-ID: 8c6253e4-78a6-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8c6253e4-78a6-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 08:05:30 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E351AAC2C;
 Tue,  7 Apr 2020 08:05:28 +0000 (UTC)
Subject: Re: [PATCH 1/7] xen/guest_access: Add missing emacs magics
To: Julien Grall <julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-2-julien@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3c0afc2d-59b0-28ec-66e6-575d02a8667e@suse.com>
Date: Tue, 7 Apr 2020 10:05:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200404131017.27330-2-julien@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 04.04.2020 15:10, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Add missing emacs magics for xen/guest_access.h and
> asm-x86/guest_access.h.
> 
> Signed-off-by: Julien Grall <jgrall@amazon.com>

I don't think these are "missing"; as per ./CODING_STYLE they're
permitted, but not required (and I continue to question why one
form of such a comment should be preferred over possible other
forms other editors may support). Nevertheless, as this is in
line with what we have elsewhere:

Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 08:07:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 08:07:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLjGF-0001PU-UJ; Tue, 07 Apr 2020 08:07:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=EZeS=5X=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jLjGE-0001PP-ML
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 08:07:06 +0000
X-Inumbo-ID: c417aa33-78a6-11ea-8080-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c417aa33-78a6-11ea-8080-12813bfff9fa;
 Tue, 07 Apr 2020 08:07:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586246825;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=pQdh1gvDSpFzuBGCjU1Wj2YzyLi0zYbQ0gaBTtoFB0E=;
 b=aylC6BDb5xcLs8WIbTTtQVumnKTT2Gg6tm1GJdhMoLc13UXtibA9L2WA
 m1PwN0oWRd2dTUOD9YlWzHlk449pnJi2OHWY0OBeLboc1NCOnOYiAs8R7
 NZLo0fTp/Z6xKur7sNsjo9BihtGqf71bT2SfTpbAnoq3E822WrTnDQ0xG M=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: jofPe0U9Oo40EKbzecQgTdX4PhgnXR6GXnBnnuJ5A+Wo2gW53yOFQ4vtHzqTuayETBJLsvAUdx
 QwE/mFDG44T3vvVImAuJwGXVfer+eRVf3+tNMLzm0QI9uZVyDuKgLjOyHLbctPM0yvrYv1rZ1H
 sKwK5O/f91Bixkgx1yWpfsIkpf3tysf2qx9cR4DURRYZMn6v4nw24FXTQlwmoKso33ByDOqudd
 m4N7PCayIccV2WobLQd257lVzPUbPnU8e4wTF+7OeNZBLn8kXk+GAJQBesQXYCmf/N0tTpYACu
 RDo=
X-SBRS: 2.7
X-MesageID: 15269146
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,353,1580792400"; d="scan'208";a="15269146"
Date: Tue, 7 Apr 2020 10:06:51 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: <paul@xen.org>
Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
Message-ID: <20200407080651.GZ28601@Air-de-Roger>
References: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
 <001501d60cb0$f60e0660$e22a1320$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <001501d60cb0$f60e0660$e22a1320$@xen.org>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Wei Liu' <wl@xen.org>, 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>, 'Jan
 Beulich' <jbeulich@suse.com>, 'Harsha Shamsundara Havanur' <havanur@amazon.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 08:48:42AM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Harsha Shamsundara Havanur
> > Sent: 06 April 2020 18:47
> > To: xen-devel@lists.xenproject.org
> > Cc: Wei Liu <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; Ian Jackson
> > <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>; Harsha Shamsundara Havanur
> > <havanur@amazon.com>; Roger Pau Monné <roger.pau@citrix.com>
> > Subject: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all resource allocation
> > 
> > It was observed that PCI MMIO and/or IO BARs were programmed with
> > BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> > register) enabled, during PCI setup phase. This resulted in
> > spurious and premature bus transactions as soon as the lower bar of
> > the 64 bit bar is programmed. It is highly recommended that BARs be
> > programmed whilst decode bits are cleared to avoid spurious bus
> > transactions.
> > 
> 
> It's not so much spurious transactions that are the issue. I think "spurious and premature bus transactions" should be replaced with "incorrect mappings being created".
> 
> I believe the PCI spec says all three bits should be clear after reset anyway, and BAR programming whilst decodes are enabled causes problems for emulators such as QEMU which need to create and destroy mappings between the gaddr being programming into the virtual BAR and the maddr programmed into the physical BAR.
> Specifically the case we see is that a 64-bit memory BAR is programmed by writing the lower half and then the upper half. After the first write the BAR is mapped to an address under 4G that happens to contain RAM, which is displaced by the mapping. After the second write the BAR is re-mapped to the intended location but the RAM displaced by the other mapping is not restored. The OS then continues to boot and function until at some point it happens to try to use that RAM at which point it suffers a page fault and crashes. It was only by noticing that the faulting address lay within the transient BAR mapping that we figured out what was happening.

In order to fix this isn't it enough to just disable memory and IO
decodes, leaving bus mastering as it is?

I assume there is (or was) some reason why bus master is enabled by
hvmloader in the first place?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 08:14:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 08:14:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLjNN-0002Fo-Ny; Tue, 07 Apr 2020 08:14:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLjNM-0002Fj-0z
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 08:14:28 +0000
X-Inumbo-ID: cbe0bbf4-78a7-11ea-8080-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cbe0bbf4-78a7-11ea-8080-12813bfff9fa;
 Tue, 07 Apr 2020 08:14:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E6EDCAC44;
 Tue,  7 Apr 2020 08:14:24 +0000 (UTC)
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Julien Grall <julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
Date: Tue, 7 Apr 2020 10:14:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200404131017.27330-7-julien@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 04.04.2020 15:10, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Most of the helpers to access guest memory are implemented the same way
> on Arm and x86. The only differences are:
>     - guest_handle_{from, to}_param(): while on x86 XEN_GUEST_HANDLE()
>       and XEN_GUEST_HANDLE_PARAM() are the same, they are not on Arm. It
>       is still fine to use the Arm implementation on x86.
>     - __clear_guest_offset(): Interestingly the prototype does not match
>       between the x86 and Arm. However, the Arm one is bogus. So the x86
>       implementation can be used.
>     - guest_handle{,_subrange}_okay(): They are validly differing
>       because Arm is only supporting auto-translated guest and therefore
>       handles are always valid.

While I'm fine in principle with such consolidation, I'm afraid I
really need to ask for some historical background to be added
here. It may very well be that there's a reason for the separation
(likely to be found in the removed ia64 or ppc ports), which may
then provide a hint at why future ports may want to have these
separated. If such reasons exist, I'd prefer to avoid the back and
forth between headers. What we could do in such a case is borrow
Linux'es asm-generic/ concept, and move the "typical"
implementation there. (And of course if there were no noticable
reasons for the split, the change as it is would be fine in
general; saying so without having looked at the details of it,
yet).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 08:14:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 08:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLjNr-0002ID-1I; Tue, 07 Apr 2020 08:14:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=xamf=5X=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLjNp-0002Hv-IT
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 08:14:57 +0000
X-Inumbo-ID: ddb39338-78a7-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x530.google.com (unknown [2a00:1450:4864:20::530])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ddb39338-78a7-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 08:14:56 +0000 (UTC)
Received: by mail-ed1-x530.google.com with SMTP id i7so2953719edq.3
 for <xen-devel@lists.xenproject.org>; Tue, 07 Apr 2020 01:14:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=GvBGbEtL/o2TGRn5fzILkgJlVz9MkJoa+0PNtpzeMic=;
 b=cqN8ZO20v/NGIx4mmHckw7ZHF48JsKY1tdn/v27VTCOP3oXPB8gmca/nlR7GynKL+2
 z5tElnjoP4I0onP+z7pd27djQsC6Wn0LEH/smZdJtY7tM1VNCQF+xMjg2dWtKwYq3IEl
 cWjw0RmSHZHLIsuebvNbTdedukwKckCmGqtMQZUlO7K++Cp3n+DgtQNmvtrQY12kGbRA
 BmfArLLFp70wwLifH5ypE1qN1laS6ghss22KUzS5crIoEE/EyRsHKOp5ZmUc94E6/yYf
 B6JhxYO+thLG5wtziwiSqmstBqDhz6RKTPjA0kYqMX0qcnwzFKDQXDZbye0Vf/Mh2cpv
 JAYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=GvBGbEtL/o2TGRn5fzILkgJlVz9MkJoa+0PNtpzeMic=;
 b=rk1Lc9NbrujTFlM4oXgHpJPN+ab7uedvnEkMjsGvZpoZ2SBSOIlaEn0qkb5oNqIG6O
 CJK8kiGA2lCQlPWWhqtSyC4YHjG+Jh8qWav8VymnX4kIJtL132+Nqzv/llbYXcedgzkP
 tp/wo7x3ZGTicA55bECWE2fjAp9XU4DJsoWD1QI9IofWoYEibHECiWKuOYUnmfCiMaY7
 BJthYlJXm0BjcpLJclEhw4Ty8v7RK5sQf2Dt8gKt3GDEPmVsb+Bk9DCLk5oSP9ppO+6A
 QefKR+7SvqdLrdfkKwnfqqKRdJ19q/PURg766cZK5k7/hX9zErp8fpc85epBlPUCKVKa
 YTUw==
X-Gm-Message-State: AGi0PuZrLGiublB/KmfU0Mmij9MD0STMAX2IdgXHbHeWSwsLvnOuGqgT
 nabB4W6WmnP6tmQzf4NrdUs=
X-Google-Smtp-Source: APiQypIaGCKeRfqPwa7UVJqF+K25P0xlHwvXuJp8eK2VtvR/AZiSDdJxvSHJf6tVDnKBOd9nIVz2ww==
X-Received: by 2002:a50:9ae4:: with SMTP id p91mr875810edb.114.1586247295824; 
 Tue, 07 Apr 2020 01:14:55 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id fi2sm25184ejb.25.2020.04.07.01.14.54
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 07 Apr 2020 01:14:55 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= <roger.pau@citrix.com>
References: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
 <001501d60cb0$f60e0660$e22a1320$@xen.org>
 <20200407080651.GZ28601@Air-de-Roger>
In-Reply-To: <20200407080651.GZ28601@Air-de-Roger>
Subject: RE: [XEN PATCH] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Tue, 7 Apr 2020 09:14:53 +0100
Message-ID: <001801d60cb4$9ed4c880$dc7e5980$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQLv5qvTmuvbc0jpqBdZKffFHl7s5gIUTdiAAfeGA2+mGTxCoA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Wei Liu' <wl@xen.org>, 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>, 'Jan Beulich' <jbeulich@suse.com>,
 'Harsha Shamsundara Havanur' <havanur@amazon.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Sent: 07 April 2020 09:07
> To: paul@xen.org
> Cc: 'Harsha Shamsundara Havanur' <havanur@amazon.com>; =
xen-devel@lists.xenproject.org; 'Wei Liu'
> <wl@xen.org>; 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'Ian =
Jackson' <ian.jackson@eu.citrix.com>;
> 'Jan Beulich' <jbeulich@suse.com>
> Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after =
all resource allocation
>=20
> On Tue, Apr 07, 2020 at 08:48:42AM +0100, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf =
Of Harsha Shamsundara Havanur
> > > Sent: 06 April 2020 18:47
> > > To: xen-devel@lists.xenproject.org
> > > Cc: Wei Liu <wl@xen.org>; Andrew Cooper =
<andrew.cooper3@citrix.com>; Ian Jackson
> > > <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>; =
Harsha Shamsundara Havanur
> > > <havanur@amazon.com>; Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> > > Subject: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after =
all resource allocation
> > >
> > > It was observed that PCI MMIO and/or IO BARs were programmed with
> > > BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> > > register) enabled, during PCI setup phase. This resulted in
> > > spurious and premature bus transactions as soon as the lower bar =
of
> > > the 64 bit bar is programmed. It is highly recommended that BARs =
be
> > > programmed whilst decode bits are cleared to avoid spurious bus
> > > transactions.
> > >
> >
> > It's not so much spurious transactions that are the issue. I think =
"spurious and premature bus
> transactions" should be replaced with "incorrect mappings being =
created".
> >
> > I believe the PCI spec says all three bits should be clear after =
reset anyway, and BAR programming
> whilst decodes are enabled causes problems for emulators such as QEMU =
which need to create and destroy
> mappings between the gaddr being programming into the virtual BAR and =
the maddr programmed into the
> physical BAR.
> > Specifically the case we see is that a 64-bit memory BAR is =
programmed by writing the lower half and
> then the upper half. After the first write the BAR is mapped to an =
address under 4G that happens to
> contain RAM, which is displaced by the mapping. After the second write =
the BAR is re-mapped to the
> intended location but the RAM displaced by the other mapping is not =
restored. The OS then continues to
> boot and function until at some point it happens to try to use that =
RAM at which point it suffers a
> page fault and crashes. It was only by noticing that the faulting =
address lay within the transient BAR
> mapping that we figured out what was happening.
>=20
> In order to fix this isn't it enough to just disable memory and IO
> decodes, leaving bus mastering as it is?
>=20
> I assume there is (or was) some reason why bus master is enabled by
> hvmloader in the first place?
>=20

I admit it is a while since I went mining for the reason BME was being =
set but IIRC the commit that added the original code did not state why =
it was done.

In the past I have run with local hacks disabling it whilst playing with =
GPU pass-through and not noticed it causing any problems. There is an =
argument to say that hvmloader should perhaps leave it alone but there =
is no good reason I can think of why it ought to be enabling it.

  Paul

> Thanks, Roger.



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 08:17:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 08:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLjPs-0002Sf-Fa; Tue, 07 Apr 2020 08:17:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLjPr-0002SZ-AV
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 08:17:03 +0000
X-Inumbo-ID: 286f1f00-78a8-11ea-8083-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 286f1f00-78a8-11ea-8083-12813bfff9fa;
 Tue, 07 Apr 2020 08:17:02 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 64BF0AC2C;
 Tue,  7 Apr 2020 08:17:00 +0000 (UTC)
Subject: Re: [PATCH 7/7] xen/guest_access: Fix coding style in
 xen/guest_access.h
To: Julien Grall <julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-8-julien@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f7d640aa-51da-830b-51e8-6257868b278e@suse.com>
Date: Tue, 7 Apr 2020 10:17:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200404131017.27330-8-julien@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 04.04.2020 15:10, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
>     * Add space before and after operator
>     * Align \
>     * Format comments

To be honest, despite the reason you give for the split in patch 6,
I'd rather see code movement like this to do formatting adjustments
right away. But if you're convinced the split is better, I'm not
meaning to insist.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 08:25:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 08:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLjXm-0003Kj-BO; Tue, 07 Apr 2020 08:25:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=EZeS=5X=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jLjXl-0003Ke-2u
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 08:25:13 +0000
X-Inumbo-ID: 4c687357-78a9-11ea-8084-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4c687357-78a9-11ea-8084-12813bfff9fa;
 Tue, 07 Apr 2020 08:25:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586247913;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=vU0xvymaevMHBY0bhB4R2dWfQ1hXtORbHvMpPmJVCBQ=;
 b=LyiNXG3yxThIjDd/WEvD/WGIKEj4CkbGoIMcRzVuzUfnyqEyX8QPKBYc
 MmTtRVY4+ZQVALdonO7ufSAtP4cxYToOxn31+iK7OwfQE4N+SNnlsSKRv
 bezJGMwaAIonqx4A5uB9w193nr1nWDWuRwxZeLRVJx5BEGkn143Npa3gu w=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: q+PgQ9jKtZ7EG/4aQi+1ENb+7Ml/t9mI8MufE0k4+FyeEc/7WjDU01LqyI3rjktkNioiRHuucB
 V6GPCK4Mpc2pENpud5NcWMfXALuRoiEs2DqfhWulf/pzo7zC7nWweXq1LX+fwOdB2htRbREYdl
 p5g2ljKdFpUBOa8RWqW8nwkRgdh+tw3xzAb314mtGYlWlJyr25dZm+p6QYMnYmy40sc0YfgSYO
 EBrXhbWn65brZ2r2rbhMX62yXelkQyn7fcL8V0j/CfTyKbl61KwD9UL181ACgD/DPLZaz2y0nl
 VL8=
X-SBRS: 2.7
X-MesageID: 15296331
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,353,1580792400"; d="scan'208";a="15296331"
Date: Tue, 7 Apr 2020 10:25:01 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: <paul@xen.org>
Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
Message-ID: <20200407082501.GA28601@Air-de-Roger>
References: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
 <001501d60cb0$f60e0660$e22a1320$@xen.org>
 <20200407080651.GZ28601@Air-de-Roger>
 <001801d60cb4$9ed4c880$dc7e5980$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <001801d60cb4$9ed4c880$dc7e5980$@xen.org>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Wei Liu' <wl@xen.org>, 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>, 'Jan
 Beulich' <jbeulich@suse.com>, 'Harsha Shamsundara Havanur' <havanur@amazon.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 09:14:53AM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Roger Pau Monné <roger.pau@citrix.com>
> > Sent: 07 April 2020 09:07
> > To: paul@xen.org
> > Cc: 'Harsha Shamsundara Havanur' <havanur@amazon.com>; xen-devel@lists.xenproject.org; 'Wei Liu'
> > <wl@xen.org>; 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'Ian Jackson' <ian.jackson@eu.citrix.com>;
> > 'Jan Beulich' <jbeulich@suse.com>
> > Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all resource allocation
> > 
> > On Tue, Apr 07, 2020 at 08:48:42AM +0100, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Harsha Shamsundara Havanur
> > > > Sent: 06 April 2020 18:47
> > > > To: xen-devel@lists.xenproject.org
> > > > Cc: Wei Liu <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; Ian Jackson
> > > > <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>; Harsha Shamsundara Havanur
> > > > <havanur@amazon.com>; Roger Pau Monné <roger.pau@citrix.com>
> > > > Subject: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all resource allocation
> > > >
> > > > It was observed that PCI MMIO and/or IO BARs were programmed with
> > > > BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> > > > register) enabled, during PCI setup phase. This resulted in
> > > > spurious and premature bus transactions as soon as the lower bar of
> > > > the 64 bit bar is programmed. It is highly recommended that BARs be
> > > > programmed whilst decode bits are cleared to avoid spurious bus
> > > > transactions.
> > > >
> > >
> > > It's not so much spurious transactions that are the issue. I think "spurious and premature bus
> > transactions" should be replaced with "incorrect mappings being created".
> > >
> > > I believe the PCI spec says all three bits should be clear after reset anyway, and BAR programming
> > whilst decodes are enabled causes problems for emulators such as QEMU which need to create and destroy
> > mappings between the gaddr being programming into the virtual BAR and the maddr programmed into the
> > physical BAR.
> > > Specifically the case we see is that a 64-bit memory BAR is programmed by writing the lower half and
> > then the upper half. After the first write the BAR is mapped to an address under 4G that happens to
> > contain RAM, which is displaced by the mapping. After the second write the BAR is re-mapped to the
> > intended location but the RAM displaced by the other mapping is not restored. The OS then continues to
> > boot and function until at some point it happens to try to use that RAM at which point it suffers a
> > page fault and crashes. It was only by noticing that the faulting address lay within the transient BAR
> > mapping that we figured out what was happening.
> > 
> > In order to fix this isn't it enough to just disable memory and IO
> > decodes, leaving bus mastering as it is?
> > 
> > I assume there is (or was) some reason why bus master is enabled by
> > hvmloader in the first place?
> > 
> 
> I admit it is a while since I went mining for the reason BME was being set but IIRC the commit that added the original code did not state why it was done.
> 
> In the past I have run with local hacks disabling it whilst playing with GPU pass-through and not noticed it causing any problems. There is an argument to say that hvmloader should perhaps leave it alone but there is no good reason I can think of why it ought to be enabling it.

IMO forcefully disabling decodings (and enabling them afterwards if
already enabled) and leaving bus mastering as-is would be better.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 08:27:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 08:27:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLjZe-0003Sr-RV; Tue, 07 Apr 2020 08:27:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLjZd-0003Sl-N5
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 08:27:09 +0000
X-Inumbo-ID: 9196f5a6-78a9-11ea-8084-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9196f5a6-78a9-11ea-8084-12813bfff9fa;
 Tue, 07 Apr 2020 08:27:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4CCFFAC77;
 Tue,  7 Apr 2020 08:27:06 +0000 (UTC)
Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: paul@xen.org
References: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
 <001501d60cb0$f60e0660$e22a1320$@xen.org>
 <20200407080651.GZ28601@Air-de-Roger>
 <001801d60cb4$9ed4c880$dc7e5980$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <d37faf63-b8bf-17bf-006e-26a32d8f5e62@suse.com>
Date: Tue, 7 Apr 2020 10:27:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <001801d60cb4$9ed4c880$dc7e5980$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Wei Liu' <wl@xen.org>, 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'Harsha Shamsundara Havanur' <havanur@amazon.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?B?J1JvZ2VyIFBhdSBNb25uw6kn?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 10:14, Paul Durrant wrote:
>> -----Original Message-----
>> From: Roger Pau Monné <roger.pau@citrix.com>
>> Sent: 07 April 2020 09:07
>> To: paul@xen.org
>> Cc: 'Harsha Shamsundara Havanur' <havanur@amazon.com>; xen-devel@lists.xenproject.org; 'Wei Liu'
>> <wl@xen.org>; 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'Ian Jackson' <ian.jackson@eu.citrix.com>;
>> 'Jan Beulich' <jbeulich@suse.com>
>> Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all resource allocation
>>
>> On Tue, Apr 07, 2020 at 08:48:42AM +0100, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Harsha Shamsundara Havanur
>>>> Sent: 06 April 2020 18:47
>>>> To: xen-devel@lists.xenproject.org
>>>> Cc: Wei Liu <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; Ian Jackson
>>>> <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>; Harsha Shamsundara Havanur
>>>> <havanur@amazon.com>; Roger Pau Monné <roger.pau@citrix.com>
>>>> Subject: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all resource allocation
>>>>
>>>> It was observed that PCI MMIO and/or IO BARs were programmed with
>>>> BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
>>>> register) enabled, during PCI setup phase. This resulted in
>>>> spurious and premature bus transactions as soon as the lower bar of
>>>> the 64 bit bar is programmed. It is highly recommended that BARs be
>>>> programmed whilst decode bits are cleared to avoid spurious bus
>>>> transactions.
>>>>
>>>
>>> It's not so much spurious transactions that are the issue. I think "spurious and premature bus
>> transactions" should be replaced with "incorrect mappings being created".
>>>
>>> I believe the PCI spec says all three bits should be clear after reset anyway, and BAR programming
>> whilst decodes are enabled causes problems for emulators such as QEMU which need to create and destroy
>> mappings between the gaddr being programming into the virtual BAR and the maddr programmed into the
>> physical BAR.
>>> Specifically the case we see is that a 64-bit memory BAR is programmed by writing the lower half and
>> then the upper half. After the first write the BAR is mapped to an address under 4G that happens to
>> contain RAM, which is displaced by the mapping. After the second write the BAR is re-mapped to the
>> intended location but the RAM displaced by the other mapping is not restored. The OS then continues to
>> boot and function until at some point it happens to try to use that RAM at which point it suffers a
>> page fault and crashes. It was only by noticing that the faulting address lay within the transient BAR
>> mapping that we figured out what was happening.
>>
>> In order to fix this isn't it enough to just disable memory and IO
>> decodes, leaving bus mastering as it is?
>>
>> I assume there is (or was) some reason why bus master is enabled by
>> hvmloader in the first place?
>>
> 
> I admit it is a while since I went mining for the reason BME
> was being set but IIRC the commit that added the original code
> did not state why it was done.

I can second this observation, but this is not a reason to drop
the enabling again without suitable justification. If there are
babbling devices, perhaps they should be quirked rather than,
as you did suggest in reply to Andrew, ones which require it
enabled? (If such a requirement indeed exists, I assume they
would get handed to hvmloader with the bit already set, in
which case a middle ground may be to simply leave the bit
alone rather than force-enabling or force-disabling it. But
again the commit adding the enabling would stand against this,
because it likely was done for a reason even if that reason is
not stated in the commit.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 08:29:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 08:29:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLjcA-0003as-9i; Tue, 07 Apr 2020 08:29:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLjc8-0003an-J5
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 08:29:44 +0000
X-Inumbo-ID: eea01246-78a9-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id eea01246-78a9-11ea-83d8-bc764e2007e4;
 Tue, 07 Apr 2020 08:29:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 75CD2ABE2;
 Tue,  7 Apr 2020 08:29:42 +0000 (UTC)
Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <f7b9e16e394e7e94700ed690f0c9fbd7ce7b5c74.1586195196.git.havanur@amazon.com>
 <001501d60cb0$f60e0660$e22a1320$@xen.org>
 <20200407080651.GZ28601@Air-de-Roger>
 <001801d60cb4$9ed4c880$dc7e5980$@xen.org>
 <20200407082501.GA28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <eb510436-21dd-1dce-8a25-815884c75b18@suse.com>
Date: Tue, 7 Apr 2020 10:29:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200407082501.GA28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Wei Liu' <wl@xen.org>, paul@xen.org,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'Harsha Shamsundara Havanur' <havanur@amazon.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 10:25, Roger Pau Monné wrote:
> IMO forcefully disabling decodings (and enabling them afterwards if
> already enabled) and leaving bus mastering as-is would be better.

Limiting this to the "already enabled" case may not be enough:
Devices needed for guest booting may need them to be enabled
even if prior to BAR assignment they were turned off. That's
what a BIOS would typically do, too. I've seen quite a few
BIOS setups actually where one could chose whether the BIOS
would do so just for what it recognized as boot devices, or
for all of them.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 08:55:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 08:55:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLk0l-0006BG-To; Tue, 07 Apr 2020 08:55:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=VNrn=5X=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLk0k-0006BB-GZ
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 08:55:10 +0000
X-Inumbo-ID: 7aac9d4c-78ad-11ea-8084-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7aac9d4c-78ad-11ea-8084-12813bfff9fa;
 Tue, 07 Apr 2020 08:55:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ssbn2sayrhVtJDs1IX8v3wGFap1G2/bAOgEvtg3q2sM=; b=pMiNfsPMTeR9x7IWOIFPZ8GxG
 AtrgWtyCWBWN0cfb0IUXDe0/UMNhnx0NjXZV1bX2JsR723OP7FrYXxbZBW4Q3gWM8EtHBuaPIgZ/z
 n0JlFRA0mGWD52VdJv/igIor8UB7CzowgOCSGx/n3dwNkEuhbj2MjyaGjFHhcWvrSV8Xg=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLk0g-0006M7-S2; Tue, 07 Apr 2020 08:55:06 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLk0g-0003Et-E8; Tue, 07 Apr 2020 08:55:06 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLk0g-0000gR-DU; Tue, 07 Apr 2020 08:55:06 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149475-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149475: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=53ef8a92eb04ee19640f5aad3bff36cd4a36c250
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 07 Apr 2020 08:55:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail baseline untested
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                53ef8a92eb04ee19640f5aad3bff36cd4a36c250
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  112 days
Failing since        144880  2019-12-16 20:07:08 Z  112 days  324 attempts
Testing same since   149475  2020-04-07 00:07:23 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Elazar Leibovich <elazar.leibovich@oracle.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Liran Alon <liran.alon@oracle.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Luwei Kang <luwei.kang@intel.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Bolshakov <r.bolshakov@yadro.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 57203 lines long.)


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 09:01:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 09:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLk71-00073Z-TW; Tue, 07 Apr 2020 09:01:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=SCBO=5X=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLk6z-00073U-VL
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 09:01:37 +0000
X-Inumbo-ID: 634c6866-78ae-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 634c6866-78ae-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 09:01:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=z652YeEs/2kLzM0La3yrghnyvCLBH662Wd6GthnNSeI=; b=DZGBbvmffetRjur8md4SMKuFhU
 r0lvU9oTcdCWrooIEUSnbYVSW8VkKck2tt3wRhynO9eGxKAXqeXT5zglUAkwL7uyDsq3rM5A1+yY9
 eq7VdVcmMdoz1kz5mdjZYjAD5gI+SeEDQ84ZEN025HA4451JHvLWXxt43mLipzkRg24E=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLk6v-0006Ve-KC; Tue, 07 Apr 2020 09:01:33 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLk6v-0007ZZ-D4; Tue, 07 Apr 2020 09:01:33 +0000
Subject: Re: [PATCH v2] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
To: Jan Beulich <jbeulich@suse.com>
References: <20200404130613.26428-1-julien@xen.org>
 <391ef401-b5d3-2f95-5fe3-c32f372dcc92@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <c3e3db55-46bf-8df9-a934-64543a23c80a@xen.org>
Date: Tue, 7 Apr 2020 10:01:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <391ef401-b5d3-2f95-5fe3-c32f372dcc92@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 xen-devel@lists.xenproject.org, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 06/04/2020 12:01, Jan Beulich wrote:
> On 04.04.2020 15:06, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
>> data to guest handle marked const.
>>
>> Thankfully, no users of the helper will do that. Rather than hoping this
>> can be caught during review, harden copy_to_guest_offset() so the build
>> will fail if such users are introduced.
>>
>> There is no easy way to check whether a const is NULL in C99. The
>> approach used is to introduce an unused variable that is non-const and
>> assign the handle. If the handle were const, this would fail at build
>> because without an explicit cast, it is not possible to assign a const
>> variable to a non-const variable.
>>
>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Julien Grall <jgrall@amazon.com>
> 
> I'm not convinced it is a good idea to add (recurring) comments
> like you do - there are more aspects of these macros that would
> be worth commenting on, and commenting on some but not all may
> give the wrong impression of all subtleties being covered (also
> for others).

I thought you would say that, but I don't think I am the best person to 
describe all the other subtetly of the code. Yet I didn't want to not 
comment the oddity of using a maybe_unused variable.

> 
> In any event I'd like to ask that each header gain such a
> comment only once, with the other being a tiny reference to the
> one "complete" instance.

I am not entirely sure how this would look like. We would need to rely 
on _t having the same meaning across all the headers. This is quite easy 
to miss during review, so my preference still sticks to multiple comments.

Although I can reduce the size of the comment to one on top of the 
definition of _t. Something like: "Check if the handler is not const".

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 09:06:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 09:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLkBv-0007Dv-KH; Tue, 07 Apr 2020 09:06:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLkBv-0007Dq-6t
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 09:06:43 +0000
X-Inumbo-ID: 18e4c1fa-78af-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 18e4c1fa-78af-11ea-83d8-bc764e2007e4;
 Tue, 07 Apr 2020 09:06:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B5EDCAC26;
 Tue,  7 Apr 2020 09:06:40 +0000 (UTC)
Subject: Re: [PATCH v2] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
To: Julien Grall <julien@xen.org>
References: <20200404130613.26428-1-julien@xen.org>
 <391ef401-b5d3-2f95-5fe3-c32f372dcc92@suse.com>
 <c3e3db55-46bf-8df9-a934-64543a23c80a@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <814d1dba-980c-3436-842a-df504909e1f6@suse.com>
Date: Tue, 7 Apr 2020 11:06:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <c3e3db55-46bf-8df9-a934-64543a23c80a@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 xen-devel@lists.xenproject.org, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 11:01, Julien Grall wrote:
> Hi Jan,
> 
> On 06/04/2020 12:01, Jan Beulich wrote:
>> On 04.04.2020 15:06, Julien Grall wrote:
>>> From: Julien Grall <jgrall@amazon.com>
>>>
>>> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
>>> data to guest handle marked const.
>>>
>>> Thankfully, no users of the helper will do that. Rather than hoping this
>>> can be caught during review, harden copy_to_guest_offset() so the build
>>> will fail if such users are introduced.
>>>
>>> There is no easy way to check whether a const is NULL in C99. The
>>> approach used is to introduce an unused variable that is non-const and
>>> assign the handle. If the handle were const, this would fail at build
>>> because without an explicit cast, it is not possible to assign a const
>>> variable to a non-const variable.
>>>
>>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>>> Signed-off-by: Julien Grall <jgrall@amazon.com>
>>
>> I'm not convinced it is a good idea to add (recurring) comments
>> like you do - there are more aspects of these macros that would
>> be worth commenting on, and commenting on some but not all may
>> give the wrong impression of all subtleties being covered (also
>> for others).
> 
> I thought you would say that, but I don't think I am the best
> person to describe all the other subtetly of the code. Yet I
> didn't want to not comment the oddity of using a maybe_unused
> variable.

Well, to me the "__maybe_unused" is telling enough.

>> In any event I'd like to ask that each header gain such a
>> comment only once, with the other being a tiny reference to the
>> one "complete" instance.
> 
> I am not entirely sure how this would look like. We would need
> to rely on _t having the same meaning across all the headers.
> This is quite easy to miss during review, so my preference
> still sticks to multiple comments.

Well, I did say "each header" exactly because of this.

> Although I can reduce the size of the comment to one on top
> of the definition of _t. Something like: "Check if the handler
> is not const".

Ah yes, that would seem better (with s/handler/handle/ of course).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 09:09:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 09:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLkE9-0007LO-1I; Tue, 07 Apr 2020 09:09:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=SCBO=5X=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLkE8-0007LI-9z
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 09:09:00 +0000
X-Inumbo-ID: 6aefdcc8-78af-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6aefdcc8-78af-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 09:08:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=a+WfNd0zQdZIopu9/x/mXg2bGpCCMzzOfxTMamiPr0g=; b=LE8G9hH8lXRjem32tsye+So94V
 5YUNQ+1VmEz2yBl9Q/frFPjbPzqU9yZOMu6f95B/gS1/VKLykrMXFzx4BkzcjjXYThSW5u/NPJOFZ
 f9CX8M0SUVvQJmexcDcp8LhZYDs3ZCBJZ4mlRKomOg5elgbA/oem7/lOcZ8TLplKFMp0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLkE5-0006ez-NO; Tue, 07 Apr 2020 09:08:57 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLkE5-00086X-GR; Tue, 07 Apr 2020 09:08:57 +0000
Subject: Re: [PATCH 7/7] xen/guest_access: Fix coding style in
 xen/guest_access.h
To: Jan Beulich <jbeulich@suse.com>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-8-julien@xen.org>
 <f7d640aa-51da-830b-51e8-6257868b278e@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <b6341ade-c3e5-e7b2-3727-9cda2619ca60@xen.org>
Date: Tue, 7 Apr 2020 10:08:55 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f7d640aa-51da-830b-51e8-6257868b278e@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 07/04/2020 09:17, Jan Beulich wrote:
> On 04.04.2020 15:10, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>>      * Add space before and after operator
>>      * Align \
>>      * Format comments
> 
> To be honest, despite the reason you give for the split in patch 6,
> I'd rather see code movement like this to do formatting adjustments
> right away.

Thank you for thinking I can move code and also modify coding style at 
the same time :).

However I know mistakes can be easily made and may not be caught during 
review (possibly leading to an XSA). So I tend to adhere to the KISS 
principle.

> But if you're convinced the split is better, I'm not
> meaning to insist.

I will keep the code as-is unless someone else think it is bad idea.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 09:16:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 09:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLkLU-0008At-Ro; Tue, 07 Apr 2020 09:16:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Vrvj=5X=amazon.de=prvs=35999e6e1=mheyne@srs-us1.protection.inumbo.net>)
 id 1jLkLT-0008Ao-7p
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 09:16:35 +0000
X-Inumbo-ID: 783a978c-78b0-11ea-8086-12813bfff9fa
Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 783a978c-78b0-11ea-8086-12813bfff9fa;
 Tue, 07 Apr 2020 09:16:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1586250992; x=1617786992;
 h=subject:from:to:cc:references:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=s/GBJ+Z7huKjAQYz7kemBNGpmflj5qV1JRIPYIE+Ans=;
 b=lAL1DaXa34+eQCgQWK7Y3OR9Nt9sAkew3Pj4KmHKKsrlHLsqKn+6NRFM
 UWtInrMNnXnlmEAT7cq6jwQKTFoCAMtO9nvBusEfqPj9HVLbQhwWaUhDa
 WJykuDvxqdDohnnZTcU7r7sWKd2K/q3rUws1nODuBt2kKmOQWBmH618SH s=;
IronPort-SDR: YsI3VwZCBvwU2QBHeIXbAZSKOJ8xt1EWbR6/hbqPjhOWoL2OIWg6+elR5bOaLMoZSuauYBKl9m
 Fxx0ocjm7Pug==
X-IronPort-AV: E=Sophos;i="5.72,353,1580774400"; d="scan'208";a="24813890"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO
 email-inbound-relay-2a-c5104f52.us-west-2.amazon.com) ([10.43.8.2])
 by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP;
 07 Apr 2020 09:16:19 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2a-c5104f52.us-west-2.amazon.com (Postfix) with ESMTPS
 id 43796A1E61; Tue,  7 Apr 2020 09:16:18 +0000 (UTC)
Received: from EX13D08EUC004.ant.amazon.com (10.43.164.176) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 7 Apr 2020 09:16:17 +0000
Received: from [192.168.4.136] (10.43.162.147) by EX13D08EUC004.ant.amazon.com
 (10.43.164.176) with Microsoft SMTP Server (TLS) id 15.0.1497.2;
 Tue, 7 Apr 2020 09:16:14 +0000
Subject: Re: [PATCH 0/3] Cleanup IOREQ server on exit
From: Maximilian Heyne <mheyne@amazon.de>
To: <xen-devel@lists.xenproject.org>
References: <20200313123316.122003-1-mheyne@amazon.de>
Message-ID: <6f476505-5e85-8a8a-d6d7-db56ea921637@amazon.de>
Date: Tue, 7 Apr 2020 11:16:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20200313123316.122003-1-mheyne@amazon.de>
Content-Language: en-US
X-Originating-IP: [10.43.162.147]
X-ClientProxiedBy: EX13D42UWA002.ant.amazon.com (10.43.160.16) To
 EX13D08EUC004.ant.amazon.com (10.43.164.176)
Precedence: Bulk
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: base64
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@citrix.com>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Q291bGQgc29tZW9uZSBwbGVhc2UgaGF2ZSBhIGxvb2sgYXQgdGhpcyBwYXRjaD8gSXQgc29sdmVz
IGFuIGFjdHVhbCBpc3N1ZToKVHJ5IHNvZnQtcmVzZXQgd2l0aCBxZW11LXhlbi10cmFkaXRpb25h
bCBhbmQgaXQgd2lsbCBmYWlsLgoKT24gMy8xMy8yMCAxOjMzIFBNLCBNYXhpbWlsaWFuIEhleW5l
IHdyb3RlOgo+IEZvbGxvd2luZyB1cCBvbiBjb21taXQgOWMwZWVkNjEgKCJxZW11LXRyYWQ6IHN0
b3AgdXNpbmcgdGhlIGRlZmF1bHQgSU9SRVEKPiBzZXJ2ZXIiKSwgY2xlYW4gdXAgdGhlIElPUkVR
IHNlcnZlciBvbiBleGl0LiBUaGlzIGZpeGVzIGEgYnVnIHdpdGggc29mdC1yZXNldAo+IHRoYXQg
c2hvd3MgdXAgYXMgImJpbmQgaW50ZXJkb21haW4gaW9jdGwgZXJyb3IgMjIiIGJlY2F1c2UgdGhl
IGV2ZW50IGNoYW5uZWxzCj4gd2VyZSBub3QgY2xvc2VkIGF0IHRoZSBzb2Z0LXJlc2V0IGFuZCBj
YW4ndCBiZSBib3VuZCBhZ2Fpbi4KPiAKPiBGb3IgdGhpcyBJIHVzZWQgdGhlIGV4aXQgbm90aWZp
ZXJzIGZyb20gUUVNVSB0aGF0IEkgYmFja3BvcnRlZCB0b2dldGhlciB3aXRoIHRoZQo+IHJlcXVp
cmVkIGdlbmVyaWMgbm90aWZpZXIgbGlzdHMuCj4gCj4gQW50aG9ueSBMaWd1b3JpICgxKToKPiAg
ICBBZGQgc3VwcG9ydCBmb3IgZ2VuZXJpYyBub3RpZmllciBsaXN0cwo+IAo+IEdlcmQgSG9mZm1h
bm4gKDEpOgo+ICAgIEFkZCBleGl0IG5vdGlmaWVycy4KPiAKPiBNYXhpbWlsaWFuIEhleW5lICgx
KToKPiAgICB4ZW46IGNsZWFudXAgSU9SRVEgc2VydmVyIG9uIGV4aXQKPiAKPiAgIE1ha2VmaWxl
ICAgICAgICAgICAgfCAgMSArCj4gICBody94ZW5fbWFjaGluZV9mdi5jIHwgMTEgKysrKysrKysr
KysKPiAgIG5vdGlmeS5jICAgICAgICAgICAgfCAzOSArKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysKPiAgIG5vdGlmeS5oICAgICAgICAgICAgfCA0MyArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCj4gICBzeXMtcXVldWUuaCAgICAgICAgIHwg
IDUgKysrKysKPiAgIHN5c2VtdS5oICAgICAgICAgICAgfCAgNSArKysrKwo+ICAgdmwuYyAgICAg
ICAgICAgICAgICB8IDIwICsrKysrKysrKysrKysrKysrKysrCj4gICA3IGZpbGVzIGNoYW5nZWQs
IDEyNCBpbnNlcnRpb25zKCspCj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgbm90aWZ5LmMKPiAgIGNy
ZWF0ZSBtb2RlIDEwMDY0NCBub3RpZnkuaAo+IAoKCgpBbWF6b24gRGV2ZWxvcG1lbnQgQ2VudGVy
IEdlcm1hbnkgR21iSApLcmF1c2Vuc3RyLiAzOAoxMDExNyBCZXJsaW4KR2VzY2hhZWZ0c2Z1ZWhy
dW5nOiBDaHJpc3RpYW4gU2NobGFlZ2VyLCBKb25hdGhhbiBXZWlzcwpFaW5nZXRyYWdlbiBhbSBB
bXRzZ2VyaWNodCBDaGFybG90dGVuYnVyZyB1bnRlciBIUkIgMTQ5MTczIEIKU2l0ejogQmVybGlu
ClVzdC1JRDogREUgMjg5IDIzNyA4NzkKCgo=



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 11:07:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 11:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLm4x-0000s3-C9; Tue, 07 Apr 2020 11:07:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLm4v-0000ry-If
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 11:07:37 +0000
X-Inumbo-ID: fc6f9a52-78bf-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fc6f9a52-78bf-11ea-9e09-bc764e2007e4;
 Tue, 07 Apr 2020 11:07:36 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 59125AC44;
 Tue,  7 Apr 2020 11:07:34 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86/PoD: correct ordering of checks in p2m_pod_zero_check()
Message-ID: <5da96b29-7f80-4bfd-eb30-5547f415d2b8@suse.com>
Date: Tue, 7 Apr 2020 13:07:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <paul@xen.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit 0537d246f8db ("mm: add 'is_special_page' inline function...")
moved the is_special_page() checks first in its respective changes to
PoD code. While this is fine for p2m_pod_zero_check_superpage(), the
validity of the MFN is inferred in both cases from the p2m_is_ram()
check, which therefore also needs to come first in this 2nd instance.

Take the opportunity and address latent UB here as well - transform
the MFN into struct page_info * only after having established that
this is a valid page.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I will admit that this was build tested only. I did observe the crash
late yesterday while in the office, but got around to analyzing it only
today, where I'm again restricted in what I can reasonably test.

--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -877,23 +877,25 @@ p2m_pod_zero_check(struct p2m_domain *p2
     for ( i = 0; i < count; i++ )
     {
         p2m_access_t a;
-        struct page_info *pg;
 
         mfns[i] = p2m->get_entry(p2m, gfns[i], types + i, &a,
                                  0, NULL, NULL);
-        pg = mfn_to_page(mfns[i]);
 
         /*
          * If this is ram, and not a pagetable or a special page, and
          * probably not mapped elsewhere, map it; otherwise, skip.
          */
-        if ( !is_special_page(pg) && p2m_is_ram(types[i]) &&
-             (pg->count_info & PGC_allocated) &&
-             !(pg->count_info & PGC_page_table) &&
-             ((pg->count_info & PGC_count_mask) <= max_ref) )
-            map[i] = map_domain_page(mfns[i]);
-        else
-            map[i] = NULL;
+        map[i] = NULL;
+        if ( p2m_is_ram(types[i]) )
+        {
+            const struct page_info *pg = mfn_to_page(mfns[i]);
+
+            if ( !is_special_page(pg) &&
+                 (pg->count_info & PGC_allocated) &&
+                 !(pg->count_info & PGC_page_table) &&
+                 ((pg->count_info & PGC_count_mask) <= max_ref) )
+                map[i] = map_domain_page(mfns[i]);
+        }
     }
 
     /*


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 11:51:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 11:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLmkq-0004nU-NG; Tue, 07 Apr 2020 11:50:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=4X4i=5X=redhat.com=mreitz@srs-us1.protection.inumbo.net>)
 id 1jLmko-0004nP-UE
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 11:50:54 +0000
X-Inumbo-ID: 08fbd122-78c6-11ea-83d8-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 08fbd122-78c6-11ea-83d8-bc764e2007e4;
 Tue, 07 Apr 2020 11:50:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1586260253;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=s+ndHbvTrKbk1V3apW4mI/ReUGW9N1uahO4VqkkPWYE=;
 b=ERV2hMqX8XCAxKHMnXPfe4FRETGJNWx4rPjt5URlbCH79a9kw675dvFjv/NZZZahXmQAtb
 o8E8Mp/li7aFLNlbx1JxXt6UTkaelMcolw52l6LD6ki3qwODuywiLmhQpbNpbVxO9iOXC4
 ZKTokq5mm9EHI6jIgLJbyA0njDeMOUw=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-374-QrNCYp35OjCW_eca-8YWTg-1; Tue, 07 Apr 2020 07:50:46 -0400
X-MC-Unique: QrNCYp35OjCW_eca-8YWTg-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com
 [10.5.11.15])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F0C388017F4;
 Tue,  7 Apr 2020 11:50:44 +0000 (UTC)
Received: from dresden.str.redhat.com (ovpn-114-84.ams2.redhat.com
 [10.36.114.84])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id 6823C5E000;
 Tue,  7 Apr 2020 11:50:38 +0000 (UTC)
Subject: Re: [PATCH v2 for-5.0] xen-block: Fix double qlist remove and request
 leak
To: Anthony PERARD <anthony.perard@citrix.com>, qemu-devel@nongnu.org
References: <20200406105954.GT4088@perard.uk.xensource.com>
 <20200406140217.1441858-1-anthony.perard@citrix.com>
From: Max Reitz <mreitz@redhat.com>
Autocrypt: addr=mreitz@redhat.com; prefer-encrypt=mutual; keydata=
 mQENBFXOJlcBCADEyyhOTsoa/2ujoTRAJj4MKA21dkxxELVj3cuILpLTmtachWj7QW+TVG8U
 /PsMCFbpwsQR7oEy8eHHZwuGQsNpEtNC2G/L8Yka0BIBzv7dEgrPzIu+W3anZXQW4702+uES
 U29G8TP/NGfXRRHGlbBIH9KNUnOSUD2vRtpOLXkWsV5CN6vQFYgQfFvmp5ZpPeUe6xNplu8V
 mcTw8OSEDW/ZnxJc8TekCKZSpdzYoxfzjm7xGmZqB18VFwgJZlIibt1HE0EB4w5GsD7x5ekh
 awIe3RwoZgZDLQMdOitJ1tUc8aqaxvgA4tz6J6st8D8pS//m1gAoYJWGwwIVj1DjTYLtABEB
 AAG0HU1heCBSZWl0eiA8bXJlaXR6QHJlZGhhdC5jb20+iQFTBBMBCAA9AhsDBQkSzAMABQsJ
 CAcCBhUICQoLAgQWAgMBAh4BAheABQJVzie5FRhoa3A6Ly9rZXlzLmdudXBnLm5ldAAKCRD0
 B9sAYdXPQDcIB/9uNkbYEex1rHKz3mr12uxYMwLOOFY9fstP5aoVJQ1nWQVB6m2cfKGdcRe1
 2/nFaHSNAzT0NnKz2MjhZVmcrpyd2Gp2QyISCfb1FbT82GMtXFj1wiHmPb3CixYmWGQUUh+I
 AvUqsevLA+WihgBUyaJq/vuDVM1/K9Un+w+Tz5vpeMidlIsTYhcsMhn0L9wlCjoucljvbDy/
 8C9L2DUdgi3XTa0ORKeflUhdL4gucWoAMrKX2nmPjBMKLgU7WLBc8AtV+84b9OWFML6NEyo4
 4cP7cM/07VlJK53pqNg5cHtnWwjHcbpGkQvx6RUx6F1My3y52vM24rNUA3+ligVEgPYBuQEN
 BFXOJlcBCADAmcVUNTWT6yLWQHvxZ0o47KCP8OcLqD+67T0RCe6d0LP8GsWtrJdeDIQk+T+F
 xO7DolQPS6iQ6Ak2/lJaPX8L0BkEAiMuLCKFU6Bn3lFOkrQeKp3u05wCSV1iKnhg0UPji9V2
 W5eNfy8F4ZQHpeGUGy+liGXlxqkeRVhLyevUqfU0WgNqAJpfhHSGpBgihUupmyUg7lfUPeRM
 DzAN1pIqoFuxnN+BRHdAecpsLcbR8sQddXmDg9BpSKozO/JyBmaS1RlquI8HERQoe6EynJhd
 64aICHDfj61rp+/0jTIcevxIIAzW70IadoS/y3DVIkuhncgDBvGbF3aBtjrJVP+5ABEBAAGJ
 ASUEGAEIAA8FAlXOJlcCGwwFCRLMAwAACgkQ9AfbAGHVz0CbFwf9F/PXxQR9i4N0iipISYjU
 sxVdjJOM2TMut+ZZcQ6NSMvhZ0ogQxJ+iEQ5OjnIputKvPVd5U7WRh+4lF1lB/NQGrGZQ1ic
 alkj6ocscQyFwfib+xIe9w8TG1CVGkII7+TbS5pXHRxZH1niaRpoi/hYtgzkuOPp35jJyqT/
 /ELbqQTDAWcqtJhzxKLE/ugcOMK520dJDeb6x2xVES+S5LXby0D4juZlvUj+1fwZu+7Io5+B
 bkhSVPb/QdOVTpnz7zWNyNw+OONo1aBUKkhq2UIByYXgORPFnbfMY7QWHcjpBVw9MgC4tGeF
 R4bv+1nAMMxKmb5VvQCExr0eFhJUAHAhVg==
Message-ID: <49d00051-13fc-e0b0-26e3-b1171ed876d3@redhat.com>
Date: Tue, 7 Apr 2020 13:50:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200406140217.1441858-1-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="qyisY4yAYPrHI5GTSgH4kc3EHGf19lNaU"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefano Stabellini <sstabellini@kernel.org>,
 qemu-block@nongnu.org, Paul Durrant <paul@xen.org>, qemu-stable@nongnu.org,
 Stefan Hajnoczi <stefanha@redhat.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qyisY4yAYPrHI5GTSgH4kc3EHGf19lNaU
Content-Type: multipart/mixed; boundary="ENINMToKaB9vrevpYUVwgT5QDWFcdQ7c9"

--ENINMToKaB9vrevpYUVwgT5QDWFcdQ7c9
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 06.04.20 16:02, Anthony PERARD wrote:
> Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
> remove") revealed that a request was removed twice from a list, once
> in xen_block_finish_request() and a second time in
> xen_block_release_request() when both function are called from
> xen_block_complete_aio(). But also, the `requests_inflight' counter is
> decreased twice, and thus became negative.
>=20
> This is a bug that was introduced in bfd0d6366043, where a `finished'
> list was removed.
>=20
> That commit also introduced a leak of request in xen_block_do_aio().
> That function calls xen_block_finish_request() but the request is
> never released after that.
>=20
> To fix both issue, we do two changes:
> - we squash finish_request() and release_request() together as we want
>   to remove a request from 'inflight' list to add it to 'freelist'.
> - before releasing a request, we need to let now the result to the
>   other end, thus we should call xen_block_send_response() before
>   releasing a request.
>=20
> The first change fix the double QLIST_REMOVE() as we remove the extra
> call. The second change makes the leak go away because if we want to
> call finish_request(), we need to call a function that do all of
> finish, send response, and release.
>=20
> Fixes: bfd0d6366043 ("xen-block: improve response latency")
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/block/dataplane/xen-block.c | 48 ++++++++++++----------------------
>  1 file changed, 16 insertions(+), 32 deletions(-)

I=E2=80=99m going to send a pull request today anyway, so I hope you won=E2=
=80=99t mind
and let me take this patch to my branch (with Paul=E2=80=99s suggestions
incorporated):

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Max


--ENINMToKaB9vrevpYUVwgT5QDWFcdQ7c9--

--qyisY4yAYPrHI5GTSgH4kc3EHGf19lNaU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEkb62CjDbPohX0Rgp9AfbAGHVz0AFAl6MaQwACgkQ9AfbAGHV
z0BjKwgAnZBIpnb2xRgxK0fvRt9/6YyEOdhcb5vq9CV934FypodV/gEqa0hZIRuB
2owjDzIBxxwkIFhqyeCjhDfRM4hp69j+VAZKXmDv4ch+PItoVSDjri0b7VC6q7FM
KjV7mv++yHhLwkNfSURA/TKs+JgARs0MAfjmsKmq9Kx2QvN/u7SSMujkHVVZ7jLT
ihq7HjTo3g41tcg8fTTEpRpKOPI+XV4DXp90X4hVyu84FKVs/aBm/yVcyPad7rUu
x6adT75hwQ4GDtFcVp6REaHnHGTnqOEGcXBCaH65dWpJrXIYYfUs2ASGVV8C+4+a
2X3nfrbK01OpxSrnCgisATtHzxVIRw==
=FZi0
-----END PGP SIGNATURE-----

--qyisY4yAYPrHI5GTSgH4kc3EHGf19lNaU--



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 12:39:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 12:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLnVV-0008Hs-A7; Tue, 07 Apr 2020 12:39:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=xamf=5X=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jLnVT-0008Hn-9Q
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 12:39:07 +0000
X-Inumbo-ID: c4c3cf12-78cc-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x536.google.com (unknown [2a00:1450:4864:20::536])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c4c3cf12-78cc-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 12:39:06 +0000 (UTC)
Received: by mail-ed1-x536.google.com with SMTP id a43so3845561edf.6
 for <xen-devel@lists.xenproject.org>; Tue, 07 Apr 2020 05:39:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=kvGztbBbTNmcvaXcaGHJxX88VkfFCPsYdD8uwpJUUkc=;
 b=N4uhEcMHIqmAIJCZcTrGRsc4OhkMUIeoD0d8DNT51CVJVNqso91uePRAARNfQXwKGo
 fo3hUyEJ5+WIkok2e3LEdnMeUqJqU5sUip/X1+cCkhLY4UgZKDvjva+tInd2ISFm7ERk
 YnjHg1mavBqW63pPLAFjzIXhM8D5CgTgEXng5gReV2GXaLJC6/2MHHyKfze4YCZQeN0e
 xrl8nQWwCewf01e6rVIKZ/sGr+WFnacxnW/0djm5z7/YII0D5UnaExi7j7bx48SSB4dM
 SLnvTgCaOdkAdekZ/TCIpZbWOmoYdpFX7cn2Fyx3oNsp8klY4gfw5bvE2hVm4Ly7VH3O
 rsBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=kvGztbBbTNmcvaXcaGHJxX88VkfFCPsYdD8uwpJUUkc=;
 b=J6Ij0EYkVRj1ZQZMDtA6PR71aBIlOmOTqHwS7SKryxRVeFVhoUWNvZUKbBfs23/fKc
 P6R1orPMCx1HCaQqw60ppWDmm1kN+wWjoM5AUN7dbttezCQy1cgaA+t31eyg0Lad4s7W
 KAEMgfCM1gzvzR5ula/rBvi0GMLf4D1wRSL9kD7RsqAt1BZ7HmTEeFwkRZNFbe7RlDqx
 bcydEPjFSwnEj+4pE9aP4H2HmmmjiHKrwgdYfu68fdN/qwBuDNuypLcNGlKk59xpsu0L
 8HxYf3jzOKZFQj5jy7cNa1HLfzxpk4JuOZnM/9RuwaFMkyFP/pary4lvKjbel0qloRUZ
 Icgg==
X-Gm-Message-State: AGi0PuY1Lk/DhegRllzFOWzUeF9oTuJxUEC5UaE4yrIM3kppFEvCUXxX
 4CNwBW3wJMUx0hOZCywEsVc=
X-Google-Smtp-Source: APiQypINmbTIxfSwodacflcNMQCPdJWUnDRo+xzCHTbZ2UeihRO9Xowxdm3DJi7bkWNMcbZB0jIXrA==
X-Received: by 2002:a17:906:848d:: with SMTP id
 m13mr1919740ejx.348.1586263145457; 
 Tue, 07 Apr 2020 05:39:05 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id h14sm3251288ejt.1.2020.04.07.05.39.04
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 07 Apr 2020 05:39:04 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>,
	<xen-devel@lists.xenproject.org>
References: <5da96b29-7f80-4bfd-eb30-5547f415d2b8@suse.com>
In-Reply-To: <5da96b29-7f80-4bfd-eb30-5547f415d2b8@suse.com>
Subject: RE: [PATCH] x86/PoD: correct ordering of checks in
 p2m_pod_zero_check()
Date: Tue, 7 Apr 2020 13:39:03 +0100
Message-ID: <002401d60cd9$85f54a90$91dfdfb0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQIwdhvhy/cDqSF8hSPabZmm4ojCOKe4xjog
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>, 'Wei Liu' <wl@xen.org>,
 =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 07 April 2020 12:08
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; Roger Pau Monn=C3=A9 =
<roger.pau@citrix.com>; Wei Liu
> <wl@xen.org>; Paul Durrant <paul@xen.org>
> Subject: [PATCH] x86/PoD: correct ordering of checks in =
p2m_pod_zero_check()
>=20
> Commit 0537d246f8db ("mm: add 'is_special_page' inline function...")
> moved the is_special_page() checks first in its respective changes to
> PoD code. While this is fine for p2m_pod_zero_check_superpage(), the
> validity of the MFN is inferred in both cases from the p2m_is_ram()
> check, which therefore also needs to come first in this 2nd instance.
>=20
> Take the opportunity and address latent UB here as well - transform
> the MFN into struct page_info * only after having established that
> this is a valid page.
>=20
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Paul Durrant <paul@xen.org>

...with a suggestion below

> ---
> I will admit that this was build tested only. I did observe the crash
> late yesterday while in the office, but got around to analyzing it =
only
> today, where I'm again restricted in what I can reasonably test.
>=20
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -877,23 +877,25 @@ p2m_pod_zero_check(struct p2m_domain *p2
>      for ( i =3D 0; i < count; i++ )
>      {
>          p2m_access_t a;
> -        struct page_info *pg;
>=20
>          mfns[i] =3D p2m->get_entry(p2m, gfns[i], types + i, &a,
>                                   0, NULL, NULL);
> -        pg =3D mfn_to_page(mfns[i]);
>=20
>          /*
>           * If this is ram, and not a pagetable or a special page, and
>           * probably not mapped elsewhere, map it; otherwise, skip.
>           */
> -        if ( !is_special_page(pg) && p2m_is_ram(types[i]) &&
> -             (pg->count_info & PGC_allocated) &&
> -             !(pg->count_info & PGC_page_table) &&
> -             ((pg->count_info & PGC_count_mask) <=3D max_ref) )
> -            map[i] =3D map_domain_page(mfns[i]);
> -        else
> -            map[i] =3D NULL;
> +        map[i] =3D NULL;
> +        if ( p2m_is_ram(types[i]) )
> +        {
> +            const struct page_info *pg =3D mfn_to_page(mfns[i]);

Perhaps have local scope stack variable for count_info too?

> +
> +            if ( !is_special_page(pg) &&
> +                 (pg->count_info & PGC_allocated) &&
> +                 !(pg->count_info & PGC_page_table) &&
> +                 ((pg->count_info & PGC_count_mask) <=3D max_ref) )
> +                map[i] =3D map_domain_page(mfns[i]);
> +        }
>      }
>=20
>      /*



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 12:45:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 12:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLnbz-0000g5-1l; Tue, 07 Apr 2020 12:45:51 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLnbx-0000g0-Lz
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 12:45:49 +0000
X-Inumbo-ID: b46219e8-78cd-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b46219e8-78cd-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 12:45:48 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A44E7AD2B;
 Tue,  7 Apr 2020 12:45:46 +0000 (UTC)
Subject: Re: [PATCH] x86/PoD: correct ordering of checks in
 p2m_pod_zero_check()
To: paul@xen.org
References: <5da96b29-7f80-4bfd-eb30-5547f415d2b8@suse.com>
 <002401d60cd9$85f54a90$91dfdfb0$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <a2641109-18af-e17f-048b-a35b7fd8ef1b@suse.com>
Date: Tue, 7 Apr 2020 14:45:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <002401d60cd9$85f54a90$91dfdfb0$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?B?J1JvZ2VyIFBhdSBNb25uw6kn?= <roger.pau@citrix.com>,
 'Wei Liu' <wl@xen.org>, 'Andrew Cooper' <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 14:39, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 07 April 2020 12:08
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com>; Wei Liu
>> <wl@xen.org>; Paul Durrant <paul@xen.org>
>> Subject: [PATCH] x86/PoD: correct ordering of checks in p2m_pod_zero_check()
>>
>> Commit 0537d246f8db ("mm: add 'is_special_page' inline function...")
>> moved the is_special_page() checks first in its respective changes to
>> PoD code. While this is fine for p2m_pod_zero_check_superpage(), the
>> validity of the MFN is inferred in both cases from the p2m_is_ram()
>> check, which therefore also needs to come first in this 2nd instance.
>>
>> Take the opportunity and address latent UB here as well - transform
>> the MFN into struct page_info * only after having established that
>> this is a valid page.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Reviewed-by: Paul Durrant <paul@xen.org>

Thanks.

> ...with a suggestion below
> 
>> ---
>> I will admit that this was build tested only. I did observe the crash
>> late yesterday while in the office, but got around to analyzing it only
>> today, where I'm again restricted in what I can reasonably test.
>>
>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -877,23 +877,25 @@ p2m_pod_zero_check(struct p2m_domain *p2
>>      for ( i = 0; i < count; i++ )
>>      {
>>          p2m_access_t a;
>> -        struct page_info *pg;
>>
>>          mfns[i] = p2m->get_entry(p2m, gfns[i], types + i, &a,
>>                                   0, NULL, NULL);
>> -        pg = mfn_to_page(mfns[i]);
>>
>>          /*
>>           * If this is ram, and not a pagetable or a special page, and
>>           * probably not mapped elsewhere, map it; otherwise, skip.
>>           */
>> -        if ( !is_special_page(pg) && p2m_is_ram(types[i]) &&
>> -             (pg->count_info & PGC_allocated) &&
>> -             !(pg->count_info & PGC_page_table) &&
>> -             ((pg->count_info & PGC_count_mask) <= max_ref) )
>> -            map[i] = map_domain_page(mfns[i]);
>> -        else
>> -            map[i] = NULL;
>> +        map[i] = NULL;
>> +        if ( p2m_is_ram(types[i]) )
>> +        {
>> +            const struct page_info *pg = mfn_to_page(mfns[i]);
> 
> Perhaps have local scope stack variable for count_info too?

I'd view this as useful only if ...

>> +
>> +            if ( !is_special_page(pg) &&

... this could then also be made make use of it.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 13:27:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 13:27:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLoGS-0003yZ-7R; Tue, 07 Apr 2020 13:27:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+Iuu=5X=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jLoGQ-0003yU-Ua
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 13:27:38 +0000
X-Inumbo-ID: 8c11f35e-78d3-11ea-9e09-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8c11f35e-78d3-11ea-9e09-bc764e2007e4;
 Tue, 07 Apr 2020 13:27:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586266058;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=HFK0JCEQulhb7pY2LjrwzdaGUMOEOlcM47IPVKd2dkA=;
 b=S+xVGQfDjVEr46vNxSsWsDVAuDlWzFglWQ+sH+roKeu/etIlHtE86pC7
 o9AKW+m/jH/1tHkr4kVzQshLDq5+bk8YIYHVJwOABbgwLWZ1o6QnzAFFS
 IoHaUEaOvsXT09ULrrTN12JysAxqqEX3fbydNyCfGUMlVOYTt9Tnmou/t c=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: eSdLFT4xH8aCgUjy/BwWIkNlTNaErAO49LhuMuMuc9o2PrSN0tgHuQCorNffnj1COK7/ClogFc
 LaToiTg2U2DaaHjINCFuRkEulXfwN8g1V+T6D+DnrzMaob7IwAd0VWzTr0YT1kMZyra9u3s8AL
 7jqU1EW+4w2Kkkk1wA1mUx9/y5nFQl1K96TNrp6hGQ2x4piOA6t+LbV8qitfN7P3awy3051GMv
 HzlK1Xp1CvSWNRLeU+euIynZI6advA8H6uaoVkilWunHEek/XEyITysYdD+AWuVCukPIrgZwc0
 lWo=
X-SBRS: 2.7
X-MesageID: 15310640
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,354,1580792400"; d="scan'208";a="15310640"
Subject: Re: [PATCH] x86/PoD: correct ordering of checks in
 p2m_pod_zero_check()
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <5da96b29-7f80-4bfd-eb30-5547f415d2b8@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <8780ba3d-11dc-4a88-34cb-6b0fe7fe01bd@citrix.com>
Date: Tue, 7 Apr 2020 14:27:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <5da96b29-7f80-4bfd-eb30-5547f415d2b8@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <paul@xen.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07/04/2020 12:07, Jan Beulich wrote:
> Commit 0537d246f8db ("mm: add 'is_special_page' inline function...")
> moved the is_special_page() checks first in its respective changes to
> PoD code. While this is fine for p2m_pod_zero_check_superpage(), the
> validity of the MFN is inferred in both cases from the p2m_is_ram()
> check, which therefore also needs to come first in this 2nd instance.
>
> Take the opportunity and address latent UB here as well - transform
> the MFN into struct page_info * only after having established that
> this is a valid page.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 13:48:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 13:48:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLoal-0005dD-0E; Tue, 07 Apr 2020 13:48:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=WJ2g=5X=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jLoai-0005d8-V2
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 13:48:36 +0000
X-Inumbo-ID: 79efa524-78d6-11ea-80cb-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 79efa524-78d6-11ea-80cb-12813bfff9fa;
 Tue, 07 Apr 2020 13:48:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DA223AC79;
 Tue,  7 Apr 2020 13:48:33 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] config: use mini-os master for unstable
Date: Tue,  7 Apr 2020 15:48:31 +0200
Message-Id: <20200407134831.22354-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We haven't used mini-os master for about 2 years now due to a stubdom
test failing [1]. Booting a guest with mini-os master used for building
stubdom didn't reveal any problem, so use master for unstable in order
to let OSStest find any problems not showing up in the local test.

[1]: https://lists.xen.org/archives/html/minios-devel/2018-04/msg00015.html

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index dc6e7d03df..0f303c79b2 100644
--- a/Config.mk
+++ b/Config.mk
@@ -245,7 +245,7 @@ MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= 20d2e5a125e34fc8501026613a71549b2a1a3e54
 QEMU_UPSTREAM_REVISION ?= master
-MINIOS_UPSTREAM_REVISION ?= 0b4b7897e08b967a09bed2028a79fabff82342dd
+MINIOS_UPSTREAM_REVISION ?= master
 
 SEABIOS_UPSTREAM_REVISION ?= rel-1.13.0
 
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 14:28:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 14:28:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLpDS-0000UP-4r; Tue, 07 Apr 2020 14:28:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jrji=5X=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jLpDR-0000UK-MK
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 14:28:37 +0000
X-Inumbo-ID: 11933314-78dc-11ea-80d4-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 11933314-78dc-11ea-80d4-12813bfff9fa;
 Tue, 07 Apr 2020 14:28:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=XSa4awPWjTVr+eLrRBq6LVZN76LNyL5MtqRIO6BS2hg=; b=HdPbhcGs0fO4G+FpiLcxVfhMaJ
 85hLM2pzS4T6hfVHb72hrwQgP/m4G/zrRgbWyfA9UHDCIW7zSJ553I3/1k3isT7BTaj7D6G95p4VB
 okueUvnvrGzUBshqVjMm4+8x1mfGpYPPTAWdbZlib02bJqi3Htb9vVBUaXoiIK/QNZI4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jLpDQ-0004bY-04; Tue, 07 Apr 2020 14:28:36 +0000
Received: from 54-240-197-225.amazon.com ([54.240.197.225]
 helo=freeip.amazon.com) by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jLpDP-0003nm-M0; Tue, 07 Apr 2020 14:28:35 +0000
Message-ID: <ba6260f7684f862b0e0e1892d2fd0d307134cbd3.camel@xen.org>
Subject: Re: [PATCH 0/5] use new API for Xen page tables
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Date: Tue, 07 Apr 2020 15:28:33 +0100
In-Reply-To: <0f072eca-bd34-ebb7-706f-9dc688c991ad@suse.com>
References: <cover.1584955616.git.hongyxia@amazon.com>
 <636251f68db5e094f0c4dd5871eb4146dadb1589.camel@xen.org>
 <0f072eca-bd34-ebb7-706f-9dc688c991ad@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, 2020-04-06 at 13:03 +0200, Jan Beulich wrote:
> On 06.04.2020 10:27, Hongyan Xia wrote:
> > Ping.
> 
> Does this somehow imply you didn't get my replies sent on the 1st?
> 
> Jan

Apologies. Somehow your replies ended up in a separate thread. There is
a problem with my email client.

Hongyan



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 14:35:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 14:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLpJz-0001Iv-QJ; Tue, 07 Apr 2020 14:35:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Xgsb=5X=gmail.com=tamas.k.lengyel@srs-us1.protection.inumbo.net>)
 id 1jLpJy-0001Iq-Ev
 for xen-devel@lists.xen.org; Tue, 07 Apr 2020 14:35:22 +0000
X-Inumbo-ID: 021ed090-78dd-11ea-b4f4-bc764e2007e4
Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 021ed090-78dd-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 14:35:21 +0000 (UTC)
Received: by mail-wm1-x344.google.com with SMTP id r26so2094164wmh.0
 for <xen-devel@lists.xen.org>; Tue, 07 Apr 2020 07:35:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=6AkO9je8fw7ePQbnFn4N6Q9r4E8QTnJnaiQDp7fp6hA=;
 b=gKQQtrfH6ylO+pHx4qNk7WcwbZDQdMxviCT5l8BWq/H/auzsF7BzuaHEjvBSYuLGi3
 G+fydbxtqnwRXKLdUasoLDrfIQBrfw0bc/tN+Mhwav8z9hvoTkauP4XG852lym9i+gIO
 rfbnu5dkqw1YMPOUets6Y0V9R0vtjSuhWGepFCHtAEIYTzvup7sOmIwRvNXqfOicRREA
 4oER8TRYjTr3CdoYS36CkzzVJ33AAEMG/T+coYLhCt1xg4Ucautz9whru8K0tvOw3Ia1
 p/IVjn44hs/UyJ+azj7/RUBbnRRXYS3fanBH7oczx2t74x+9g3jTOOiSI2wuRc11SdKl
 GX/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=6AkO9je8fw7ePQbnFn4N6Q9r4E8QTnJnaiQDp7fp6hA=;
 b=d8rVHSGS6o9RWIwUDGeE2i8JCOU5+GYBc50LcMUAqJu/rRHlG0Mu66dmmk2AhGuou0
 p24T0fdKvvqpoztGnKhX3QSuIdY5E+OdoHjvjOVDjwFESNBr8qzduZhb22LmvGi922Wi
 IKFjrHrbYz6TGDx39cO+yRzfEXYRungvCoIF63M0IAL7DKjeysFqEPudwXTUKtcOjWTT
 9DCMuCm2HwMucda1lTkIcCz0UAQCRfmXYOl23Y9Dl+rvTBDMqL7g2ZN0aTVpJ5tR2exu
 j3fdgvKZ7QM2N20HocjQPHx0RxK4ZPO5yxBDCsYHk9OtpSJi9jjLxwGOYdJBA5QpSb6v
 0H6g==
X-Gm-Message-State: AGi0PuZrQA3gKFyhDnyMr/xKB3bN1krVaparpaW0ShSSsOCypqOBKoF2
 I5pjVD4xuksZUWhD3UcUZv+v+juNmyUbTb+GT74=
X-Google-Smtp-Source: APiQypJz2AIqNdXSnIjgMDjfnid3CO5g20TDr+7LoWlouyrQ5009MtKqlR8J2kp7axBV6WbusQb9KaQVMvTrP6Lqm8I=
X-Received: by 2002:a7b:c842:: with SMTP id c2mr2839038wml.154.1586270120284; 
 Tue, 07 Apr 2020 07:35:20 -0700 (PDT)
MIME-Version: 1.0
References: <CABB6KG-UCdPTa3yM57JB13G=Yebe8chuQKvKkNbtoGRSZ9Ypsw@mail.gmail.com>
 <a8c56ab0-bc51-fa1c-c63f-cb9ada8a1823@citrix.com>
 <CABfawhn_hw=o5j+G9VfqPK6opytqt=q2-cz4GjNgCTA5zBvNrA@mail.gmail.com>
 <6bb7eb58-01c6-00e4-672e-83d5fcb87ea0@citrix.com>
 <CABfawh=6z-pxgrj1M3JbG-9H=iR78rTwt8+MUf_6-Sd5kqyhdA@mail.gmail.com>
 <001701d60cb2$2e1b2050$8a5160f0$@xen.org>
In-Reply-To: <001701d60cb2$2e1b2050$8a5160f0$@xen.org>
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Date: Tue, 7 Apr 2020 08:34:43 -0600
Message-ID: <CABfawh=ViONrSak4L-nW7LigHvuAsY2-6xoWfzx65tbn0mFo=w@mail.gmail.com>
Subject: Re: Live migration and PV device handling
To: Paul Durrant <paul@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anastassios Nanos <anastassios.nanos@sunlight.io>,
 Xen-devel <xen-devel@lists.xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 7, 2020 at 1:57 AM Paul Durrant <xadimgnik@gmail.com> wrote:
>
> > -----Original Message-----
> > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of T=
amas K Lengyel
> > Sent: 06 April 2020 18:31
> > To: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: Xen-devel <xen-devel@lists.xen.org>; Anastassios Nanos <anastassios=
.nanos@sunlight.io>
> > Subject: Re: Live migration and PV device handling
> >
> > On Mon, Apr 6, 2020 at 11:24 AM Andrew Cooper <andrew.cooper3@citrix.co=
m> wrote:
> > >
> > > On 06/04/2020 18:16, Tamas K Lengyel wrote:
> > > > On Fri, Apr 3, 2020 at 6:44 AM Andrew Cooper <andrew.cooper3@citrix=
.com> wrote:
> > > >> On 03/04/2020 13:32, Anastassios Nanos wrote:
> > > >>> Hi all,
> > > >>>
> > > >>> I am trying to understand how live-migration happens in xen. I am
> > > >>> looking in the HVM guest case and I have dug into the relevant pa=
rts
> > > >>> of the toolstack and the hypervisor regarding memory, vCPU contex=
t
> > > >>> etc.
> > > >>>
> > > >>> In particular, I am interested in how PV device migration happens=
. I
> > > >>> assume that the guest is not aware of any suspend/resume operatio=
ns
> > > >>> being done
> > > >> Sadly, this assumption is not correct.  HVM guests with PV drivers
> > > >> currently have to be aware in exactly the same way as PV guests.
> > > >>
> > > >> Work is in progress to try and address this.  See
> > > >> https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3D775=
a02452ddf3a6889690de90b1a94eb29c3c732
> > > >> (sorry - for some reason that doc isn't being rendered properly in
> > > >> https://xenbits.xen.org/docs/ )
> > > > That proposal is very interesting - first time it came across my ra=
dar
> > > > - but I dislike the idea that domain IDs need to be preserved for
> > > > uncooperative migration to work.
> > >
> > > The above restriction is necessary to work with existing guests, whic=
h
> > > is an implementation requirement of the folks driving the work.
> > >
> > > > Ideally I would be able to take
> > > > advantage of the same plumbing to perform forking of VMs with PV
> > > > drivers where preserving the domain id is impossible since its stil=
l
> > > > in use.
> > >
> > > We would of course like to make changes to remove the above restricti=
on
> > > in the longterm.  The problem is that it is not a trivial thing to fi=
x.
> > > Various things were discussed in Chicago, but I don't recall if any o=
f
> > > the plans made their way onto xen-devel.
> >
> > Yea I imagine trying to get this to work with existing PV drivers is
> > not possible in any other way.
>
> No, as the doc says, the domid forms part of the protocol, hence being vi=
sible to the guest, and the guest may sample and use the value when making =
certain hypercalls (only some enforce use of DOMID_SELF). Thus faking it wi=
thout risking a guest crash is going to be difficult.
>
> > But if we can update the PV driver code
> > such that in the longterm it can work without preserving the domain
> > ID, that would be worthwhile.
> >
>
> I think that ship has sailed. It would probably be simpler and cheaper to=
 just get virtio working with Xen.

That would certainly make sense to me. That would reduce the
maintenance overhead considerably if we all converged on a single
standard.

Tamas


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 14:54:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 14:54:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLpcR-0002zQ-NZ; Tue, 07 Apr 2020 14:54:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=A3/I=5X=amazon.com=prvs=3592f0f2d=apanyaki@srs-us1.protection.inumbo.net>)
 id 1jLpay-0002yC-CT
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 14:52:56 +0000
X-Inumbo-ID: 76a93d54-78df-11ea-80e0-12813bfff9fa
Received: from smtp-fw-6002.amazon.com (unknown [52.95.49.90])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 76a93d54-78df-11ea-80e0-12813bfff9fa;
 Tue, 07 Apr 2020 14:52:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586271176; x=1617807176;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=fuZU/PcKM2BThpIUfo8RBS5NjdqgDeyPc6BFhgapiCU=;
 b=HsKEHpLS44NI1eI+UVX+8MfmJ1hOBHaC9yA4XknAuc7uc2DNng0sYboD
 gpOGDhiR8aSx8yprejKt85CMFEagQk7+QmzEGsQQeaS0Rsec4W7MBws4y
 2xllXI97lF0KYn4vzimydOXuHBLvB6EBkNLq+LDMZ5aKGaoW01/XVV/jX E=;
IronPort-SDR: aOF8GNGFw8FJ12itdCObFyLqHsXurAEtRUloY3kX6AteniGjd0hxc58L2YtIl8c2nxViRK4Nxu
 zpwIMMdSBCMg==
X-IronPort-AV: E=Sophos;i="5.72,354,1580774400"; d="scan'208";a="24488295"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP;
 07 Apr 2020 14:52:43 +0000
Received: from EX13MTAUEB002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])
 by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (Postfix) with ESMTPS
 id 4DA4A285250; Tue,  7 Apr 2020 14:52:41 +0000 (UTC)
Received: from EX13D08UEB004.ant.amazon.com (10.43.60.142) by
 EX13MTAUEB002.ant.amazon.com (10.43.60.12) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 7 Apr 2020 14:52:41 +0000
Received: from EX13MTAUEA002.ant.amazon.com (10.43.61.77) by
 EX13D08UEB004.ant.amazon.com (10.43.60.142) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 7 Apr 2020 14:52:41 +0000
Received: from dev-dsk-apanyaki-1a-fc7fd022.eu-west-1.amazon.com
 (10.15.114.143) by mail-relay.amazon.com (10.43.61.169) with Microsoft SMTP
 Server id 15.0.1497.2 via Frontend Transport; Tue, 7 Apr 2020 14:52:41 +0000
Received: by dev-dsk-apanyaki-1a-fc7fd022.eu-west-1.amazon.com (Postfix,
 from userid 9665405)
 id E1BC926074; Tue,  7 Apr 2020 14:52:40 +0000 (UTC)
From: Andrew Panyakin <apanyaki@amazon.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH] libxc/migration: Abort migration on precopy policy request
Date: Tue, 7 Apr 2020 14:52:22 +0000
Message-ID: <eb85d7fee920b54eea3b4c0e77ab40593613ccc4.1586270820.git.apanyaki@amazon.com>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-Mailman-Approved-At: Tue, 07 Apr 2020 14:54:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <paul@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>, Andrew Panyakin <apanyaki@amazon.com>,
 David Woodhouse <dwmw@amazon.co.uk>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

libxc defines XGS_POLICY_ABORT for precopy policy to signal that migration
should be aborted (eg. if the estimated pause time is too huge for the
instance). Default simple precopy policy never returns that, but it could be
overriden with a custom one.

Signed-off-by: Andrew Panyakin <apanyaki@amazon.com>
---
 tools/libxc/xc_sr_save.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index fa736a311f..507274ce22 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -560,6 +560,12 @@ static int send_memory_live(struct xc_sr_context *ctx)
 
     }
 
+    if ( policy_decision == XGS_POLICY_ABORT ) {
+        PERROR("Abort precopy loop");
+        rc = -1;
+        goto out;
+    }
+
  out:
     xc_set_progress_prefix(xch, NULL);
     free(progress_str);
-- 
2.16.6



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 15:11:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 15:11:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLpsg-0004e0-Bf; Tue, 07 Apr 2020 15:11:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jrji=5X=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jLpse-0004dv-7N
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 15:11:12 +0000
X-Inumbo-ID: 0420c18c-78e2-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0420c18c-78e2-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 15:11:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=z6mqr4qdQIveaoR2pIq+0I4zCsrNy11zbSfKfbq572w=; b=QpW13FtqaCRJob5JatcTZLyEJ8
 ygNMyZSfceI/4kc9gJN3HbQwd60OIX+WKTTYncxAb9z9LvWJjo6SlLPaP1qLJVmRy57qKTPcosM1D
 qLPdThgcpf0rpZoWCBSqNmpGO1A6oK2pW3mDcKdUkyoWsexUaB57O4Og0Ga55Sg5E0zY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jLpsb-0005PS-HB; Tue, 07 Apr 2020 15:11:09 +0000
Received: from 54-240-197-225.amazon.com ([54.240.197.225]
 helo=freeip.amazon.com) by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jLpsb-0006qp-7L; Tue, 07 Apr 2020 15:11:09 +0000
Message-ID: <7a5e9095c1c927819d248d5227d2511676781855.camel@xen.org>
Subject: Re: [PATCH 3/5] x86_64/mm: map and unmap page tables in
 share_hotadd_m2p_table
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Date: Tue, 07 Apr 2020 16:11:07 +0100
In-Reply-To: <f1537005-cac8-cd74-e19c-043219ccab56@suse.com>
References: <cover.1584955616.git.hongyxia@amazon.com>
 <2fa83ef5818805c179757caac99ccf7ab4f7ba3a.1584955616.git.hongyxia@amazon.com>
 <f1537005-cac8-cd74-e19c-043219ccab56@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 2020-04-01 at 14:29 +0200, Jan Beulich wrote:
> On 23.03.2020 10:41, Hongyan Xia wrote:
> > --- a/xen/include/asm-x86/page.h
> > +++ b/xen/include/asm-x86/page.h
> > @@ -196,6 +196,24 @@ static inline l4_pgentry_t
> > l4e_from_paddr(paddr_t pa, unsigned int flags)
> >  #define map_l2t_from_l3e(x)        (l2_pgentry_t
> > *)map_domain_page(l3e_get_mfn(x))
> >  #define map_l3t_from_l4e(x)        (l3_pgentry_t
> > *)map_domain_page(l4e_get_mfn(x))
> >  
> > +#define l1e_from_l2e(l2e, off) ({                   \
> > +        l1_pgentry_t *l1t = map_l1t_from_l2e(l2e);  \
> > +        l1_pgentry_t l1e = l1t[off];                \
> > +        UNMAP_DOMAIN_PAGE(l1t);                     \
> > +        l1e; })
> > +
> > +#define l2e_from_l3e(l3e, off) ({                   \
> > +        l2_pgentry_t *l2t = map_l2t_from_l3e(l3e);  \
> > +        l2_pgentry_t l2e = l2t[off];                \
> > +        UNMAP_DOMAIN_PAGE(l2t);                     \
> > +        l2e; })
> > +
> > +#define l3e_from_l4e(l4e, off) ({                   \
> > +        l3_pgentry_t *l3t = map_l3t_from_l4e(l4e);  \
> > +        l3_pgentry_t l3e = l3t[off];                \
> > +        UNMAP_DOMAIN_PAGE(l3t);                     \
> > +        l3e; })
> 
> There's a reason these are macros rather than inline functions,
> I assume? (This reason would be nice to be stated in the
> description.)

Actually no specific reasons, just to keep them as macros to be
consistent with other helpers above. Fairly trivial to convert them
into inline functions if this is desired.

> I don't see why you use UNMAP_DOMAIN_PAGE() rather than
> unmap_domain_page() here - the variables in question go out of
> scope right afterwards, so the storing of NULL into them is
> pointless (and very likely to be eliminated by the compiler
> anyway).

My intention is to just avoid using the lower case one altogether, so
that one day when we need to expand any function or macros we do not
need to look back at the code and worry about whether any lower case
ones need to be converted to upper case (sometimes for large functions
this may not be trivial), and the compiler can deal with the extra
nullification anyway.

> Finally the pointers should each be "to const", as you're
> only reading through them.

Good point. Will const qualify in next revision.

Thanks,
Hongyan



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 15:14:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 15:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLpw2-0004n2-SM; Tue, 07 Apr 2020 15:14:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=71dA=5X=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jLpw1-0004mx-MW
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 15:14:41 +0000
X-Inumbo-ID: 80bd6268-78e2-11ea-80ea-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 80bd6268-78e2-11ea-80ea-12813bfff9fa;
 Tue, 07 Apr 2020 15:14:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 54013AC77;
 Tue,  7 Apr 2020 15:14:39 +0000 (UTC)
Subject: Re: [PATCH 3/5] x86_64/mm: map and unmap page tables in
 share_hotadd_m2p_table
To: Hongyan Xia <hx242@xen.org>
References: <cover.1584955616.git.hongyxia@amazon.com>
 <2fa83ef5818805c179757caac99ccf7ab4f7ba3a.1584955616.git.hongyxia@amazon.com>
 <f1537005-cac8-cd74-e19c-043219ccab56@suse.com>
 <7a5e9095c1c927819d248d5227d2511676781855.camel@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <0d0fb4e9-c27e-a8b2-8fc7-602bc535b655@suse.com>
Date: Tue, 7 Apr 2020 17:14:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7a5e9095c1c927819d248d5227d2511676781855.camel@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 17:11, Hongyan Xia wrote:
> On Wed, 2020-04-01 at 14:29 +0200, Jan Beulich wrote:
>> On 23.03.2020 10:41, Hongyan Xia wrote:
>>> --- a/xen/include/asm-x86/page.h
>>> +++ b/xen/include/asm-x86/page.h
>>> @@ -196,6 +196,24 @@ static inline l4_pgentry_t
>>> l4e_from_paddr(paddr_t pa, unsigned int flags)
>>>  #define map_l2t_from_l3e(x)        (l2_pgentry_t
>>> *)map_domain_page(l3e_get_mfn(x))
>>>  #define map_l3t_from_l4e(x)        (l3_pgentry_t
>>> *)map_domain_page(l4e_get_mfn(x))
>>>  
>>> +#define l1e_from_l2e(l2e, off) ({                   \
>>> +        l1_pgentry_t *l1t = map_l1t_from_l2e(l2e);  \
>>> +        l1_pgentry_t l1e = l1t[off];                \
>>> +        UNMAP_DOMAIN_PAGE(l1t);                     \
>>> +        l1e; })
>>> +
>>> +#define l2e_from_l3e(l3e, off) ({                   \
>>> +        l2_pgentry_t *l2t = map_l2t_from_l3e(l3e);  \
>>> +        l2_pgentry_t l2e = l2t[off];                \
>>> +        UNMAP_DOMAIN_PAGE(l2t);                     \
>>> +        l2e; })
>>> +
>>> +#define l3e_from_l4e(l4e, off) ({                   \
>>> +        l3_pgentry_t *l3t = map_l3t_from_l4e(l4e);  \
>>> +        l3_pgentry_t l3e = l3t[off];                \
>>> +        UNMAP_DOMAIN_PAGE(l3t);                     \
>>> +        l3e; })
>>
>> There's a reason these are macros rather than inline functions,
>> I assume? (This reason would be nice to be stated in the
>> description.)
> 
> Actually no specific reasons, just to keep them as macros to be
> consistent with other helpers above. Fairly trivial to convert them
> into inline functions if this is desired.

Where possible this would be the preferred route for new helpers.

>> I don't see why you use UNMAP_DOMAIN_PAGE() rather than
>> unmap_domain_page() here - the variables in question go out of
>> scope right afterwards, so the storing of NULL into them is
>> pointless (and very likely to be eliminated by the compiler
>> anyway).
> 
> My intention is to just avoid using the lower case one altogether, so
> that one day when we need to expand any function or macros we do not
> need to look back at the code and worry about whether any lower case
> ones need to be converted to upper case (sometimes for large functions
> this may not be trivial), and the compiler can deal with the extra
> nullification anyway.

I don't agree with this goal; perhaps others on Cc have an opinion?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 15:22:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 15:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLq3t-0005dh-O2; Tue, 07 Apr 2020 15:22:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DsZW=5X=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jLq3s-0005dc-4M
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 15:22:48 +0000
X-Inumbo-ID: a2714d88-78e3-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a2714d88-78e3-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 15:22:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586272967;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=p4pqrvqLWTeQJ2N/iED4+aXuC2skShBJ4HGL3c8YB1Y=;
 b=TAzEuqlaknaOmP2fRZRgeyybFDHw8gYHvdWaiXLiASbPrzvdoxgm2h3Y
 dmij6fRihwTThCBRtDvTPW26POTmyOAcg9kaiQ9obpe9FiMf2pBVAGgaP
 85vYxdYbAyQWP6UNs1sV2kB/X3DJVZgIEdELuWoTVl0W1YPybMmx2gEDu Q=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 5+opBNhuKZjxrRGFQXvAaJMdbcrJU69J57N5qV2v5aq49GjtbNrkEyM5Jmgq3OiYKidpOMYe78
 wdi0th0m74HMsZ7tDLtfOBtLwmPvmz0Ne4665Fi9FXXkm0HXsaK6t2IsYaREOpq50ZCa7emJ4V
 iSQCYz0wsi/QRa8stCQJtuca3iMxokWAcCbU99E+KIN4cgvgRWNz1HfbldysuqtLyP3XY7bGew
 zXEAgcrWH4Dd1EK2yrTr0GMlWofR2KN1vO+FUBzk2cxYdaNg490IcIBRXUVUWOCAChZGbiiZGL
 56Q=
X-SBRS: 2.7
X-MesageID: 15974520
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,355,1580792400"; d="scan'208";a="15974520"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <qemu-devel@nongnu.org>
Subject: [PULL 0/3] xen queue for 5.0
Date: Tue, 7 Apr 2020 16:22:34 +0100
Message-ID: <20200407152237.1468704-1-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The following changes since commit 8f0d25c464a1989d606f7b988d07b1147dfcde33:

  Merge remote-tracking branch 'remotes/philmd-gitlab/tags/acceptance-fixes-20200407' into staging (2020-04-07 15:10:11 +0100)

are available in the Git repository at:

  https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git tags/pull-xen-20200407

for you to fetch changes up to 758af9cfabfb000eb00e42b9738e655b18fdd812:

  MAINTAINERS: Add xen-usb.c to Xen section (2020-04-07 16:13:26 +0100)

----------------------------------------------------------------
Xen queue for QEMU 5.0

- Fix for xen-block.
- A fix for a Coverity false positive in xen-usb.
- Update MAINTAINERS to add xen-usb.c to Xen section.

----------------------------------------------------------------
Anthony PERARD (2):
      xen-block: Fix uninitialized variable
      MAINTAINERS: Add xen-usb.c to Xen section

Peter Maydell (1):
      hw/usb/xen-usb.c: Pass struct usbback_req* to usbback_packet_complete()

 MAINTAINERS          |  1 +
 hw/block/xen-block.c |  2 +-
 hw/usb/xen-usb.c     | 10 ++++------
 3 files changed, 6 insertions(+), 7 deletions(-)


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 15:22:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 15:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLq3z-0005e5-0Q; Tue, 07 Apr 2020 15:22:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DsZW=5X=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jLq3x-0005dz-0b
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 15:22:53 +0000
X-Inumbo-ID: a3390742-78e3-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a3390742-78e3-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 15:22:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586272967;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=Qg827KIvdKEzs6jvNwGqMNXyL08iW2Xpsw7/s+ZIo+U=;
 b=NAlyRtDBCStIB2MhWCpu9WXHiCFu58eFDpy9cpRVUYxy0ZO6dd8nx5sZ
 Uvoo+r5bOPZhovwYzSQa6BlRgqQ3TXTGrdxVxqyUUXwAdcPdMeNVuwo8/
 SIWFb4LCUC2UwY12IlDjEzSy4buv4DMelBjK3GlC1pKfn0yDp5pmvw0+G I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: kEEUF3m5QJdGP+nVunsvGYsRB0qPKBIMKb/0kGJ3Ad5qvTmdLxzqw07ltbH+HjkMS71Lrl6qAZ
 yaqI6F3eG7Ljvf+RIJ4y5SPiYNj2f/YSQoguctmkfywB1hHd8dYISMCx2YiySk4t6THD2BQCLP
 knLe7MnbkruiyE3zrnKMGimmjyRfL/DuVm0FlJIL58nV+zkLXePqoukx+rwJVM+fHTfww1YqlB
 xHvSG8Zx8+xBzBZrflAGWY1Q724URub+FE+lbwk29Fg0NiOIHzB4pSav/fbtBaxYHZbvF4WFqP
 4ps=
X-SBRS: 2.7
X-MesageID: 15974527
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,355,1580792400"; d="scan'208";a="15974527"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <qemu-devel@nongnu.org>
Subject: [PULL 2/3] xen-block: Fix uninitialized variable
Date: Tue, 7 Apr 2020 16:22:36 +0100
Message-ID: <20200407152237.1468704-3-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200407152237.1468704-1-anthony.perard@citrix.com>
References: <20200407152237.1468704-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Since 7f5d9b206d1e ("object-add: don't create return value if
failed"), qmp_object_add() don't write any value in 'ret_data', thus
has random data. Then qobject_unref() fails and abort().

Fix by initialising 'ret_data' properly.

Fixes: 5f07c4d60d09 ("qapi: Flatten object-add")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20200406164207.1446817-1-anthony.perard@citrix.com>
---
 hw/block/xen-block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 07bb32e22b51..99cb4c67cb09 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -860,7 +860,7 @@ static XenBlockIOThread *xen_block_iothread_create(const char *id,
     XenBlockIOThread *iothread = g_new(XenBlockIOThread, 1);
     Error *local_err = NULL;
     QDict *opts;
-    QObject *ret_data;
+    QObject *ret_data = NULL;
 
     iothread->id = g_strdup(id);
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 15:22:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 15:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLq42-0005f4-9w; Tue, 07 Apr 2020 15:22:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DsZW=5X=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jLq42-0005ex-0H
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 15:22:58 +0000
X-Inumbo-ID: a7b114cc-78e3-11ea-9e09-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a7b114cc-78e3-11ea-9e09-bc764e2007e4;
 Tue, 07 Apr 2020 15:22:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586272977;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=qk1Y4jepw5ZUFH8O7s3prQyFWb+r4UOxrpJ04Jwz6vo=;
 b=GgoZGmKK8TkTo9wAHfUFKoEhYh/MDrfWcpPNJ1Y1JIrfmIqy8rvZHY6u
 tDz9e0Zt3WTw0El01IYb5I6lf/dU8Kg4GAtR8ANDISHSNhpdNtDjL51Be
 1aPnNz1EtCJYRY/0RaJjs3A5Bie29mmW5vJPCeCDNnXTysbMZT7Q//di9 4=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: uJfw3vKfJcYjs2uYVUJY2Vqq4/96T8V+v/wBgcIrMvNqvt5u1WxRVXNo6wLv9KOa+i4hoW+dp1
 nvxF367qo1JJakgKbTVrvv124fXRlU1hiM1DezCI8AD65BnARTYJPyEmjXkdZgyRbUAPLfm430
 /CqeFeUgiyHOPAsksTFtT24nF7GshbMxRELlvxmk1s+L6BEaASJLDYHTQE2n+Y7VatC/LvrAG/
 BpEnnGqdJeavXRQqX6usRCNYpETrfT8sLyjQPmM533ZTEbdhPsXW4syivaAfud+3Jo0h/T81q/
 KP4=
X-SBRS: 2.7
X-MesageID: 15534900
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,355,1580792400"; d="scan'208";a="15534900"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <qemu-devel@nongnu.org>
Subject: [PULL 1/3] hw/usb/xen-usb.c: Pass struct usbback_req* to
 usbback_packet_complete()
Date: Tue, 7 Apr 2020 16:22:35 +0100
Message-ID: <20200407152237.1468704-2-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200407152237.1468704-1-anthony.perard@citrix.com>
References: <20200407152237.1468704-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Peter Maydell <peter.maydell@linaro.org>

The function usbback_packet_complete() currently takes a USBPacket*,
which must be a pointer to the packet field within a struct
usbback_req; the function uses container_of() to get the struct
usbback_req* given the USBPacket*.

This is unnecessarily confusing (and in particular it confuses the
Coverity Scan analysis, resulting in the false positive CID 1421919
where it thinks that we write off the end of the structure). Since
both callsites already have the pointer to the struct usbback_req,
just pass that in directly.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20200323164318.26567-1-peter.maydell@linaro.org>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/usb/xen-usb.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 1fc2f32ce93d..961190d0f78c 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -347,13 +347,11 @@ static int32_t usbback_xlat_status(int status)
     return -ESHUTDOWN;
 }
 
-static void usbback_packet_complete(USBPacket *packet)
+static void usbback_packet_complete(struct usbback_req *usbback_req)
 {
-    struct usbback_req *usbback_req;
+    USBPacket *packet = &usbback_req->packet;
     int32_t status;
 
-    usbback_req = container_of(packet, struct usbback_req, packet);
-
     QTAILQ_REMOVE(&usbback_req->stub->submit_q, usbback_req, q);
 
     status = usbback_xlat_status(packet->status);
@@ -566,7 +564,7 @@ static void usbback_dispatch(struct usbback_req *usbback_req)
 
     usb_handle_packet(usbback_req->stub->dev, &usbback_req->packet);
     if (usbback_req->packet.status != USB_RET_ASYNC) {
-        usbback_packet_complete(&usbback_req->packet);
+        usbback_packet_complete(usbback_req);
     }
     return;
 
@@ -993,7 +991,7 @@ static void xen_bus_complete(USBPort *port, USBPacket *packet)
 
     usbif = usbback_req->usbif;
     TR_REQ(&usbif->xendev, "\n");
-    usbback_packet_complete(packet);
+    usbback_packet_complete(usbback_req);
 }
 
 static USBPortOps xen_usb_port_ops = {
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 15:23:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 15:23:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLq47-0005gw-Jb; Tue, 07 Apr 2020 15:23:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DsZW=5X=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jLq47-0005gf-19
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 15:23:03 +0000
X-Inumbo-ID: a8d342d0-78e3-11ea-9e09-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a8d342d0-78e3-11ea-9e09-bc764e2007e4;
 Tue, 07 Apr 2020 15:22:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586272978;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=zpD/qULcUWjnXe5Pei47zmPvZSaeufrHyKCovEQ8IY0=;
 b=fBP35TLK1W/7PZUQGPLuBQDyE/1dS3G8hMgq+nJfTCgrE2B8oNJ+B30z
 5zTkLiCo/P1IFfN2L7Mj9WkQ4zCYhByMmsmKqzAW5b2v2ZKVPIblSkG/Y
 GUG6+MICz7W/hpKtC+l5Pl2kHsE6rJULOcbrNMuiT5X4NglJXI93mzfoP I=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: kIpJUdp/ueeziAdKh5CGN0J6Of7NJxXM7lkAmrFurtwL8Nti4/kW70mNzCLO/YPcuUrkSBnyju
 hOF6Jspwi3Xkj/jXa0FPpfunPEQRgsAup8Eto8FuPJqlIK/0knMN1H429JH7VaUHURz/KgN/Ea
 XkzvyPWPQZ+Up7cJv2GF+q9Hh27bPlEZxtTGJyjkroE/fsDBaWYSEoVsuZggKe23bYe1EDPO1h
 JgFukRRiHec3wCj2Fjqoe8xuvbxriSu1WnXngqD3AbMNLELlA7KKs70KShHxsWTh9Saf1EMVzV
 PKk=
X-SBRS: 2.7
X-MesageID: 15534906
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,355,1580792400"; d="scan'208";a="15534906"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <qemu-devel@nongnu.org>
Subject: [PULL 3/3] MAINTAINERS: Add xen-usb.c to Xen section
Date: Tue, 7 Apr 2020 16:22:37 +0100
Message-ID: <20200407152237.1468704-4-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200407152237.1468704-1-anthony.perard@citrix.com>
References: <20200407152237.1468704-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Paul Durrant <paul@xen.org>
Message-Id: <20200406165043.1447837-1-anthony.perard@citrix.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9d156d73b31e..839959f7e4ac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -440,6 +440,7 @@ F: hw/9pfs/xen-9p*
 F: hw/char/xen_console.c
 F: hw/display/xenfb.c
 F: hw/net/xen_nic.c
+F: hw/usb/xen-usb.c
 F: hw/block/xen*
 F: hw/block/dataplane/xen*
 F: hw/xen/
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 16:11:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 16:11:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLqob-0001zf-K2; Tue, 07 Apr 2020 16:11:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=ebmU=5X=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jLqoa-0001za-3b
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 16:11:04 +0000
X-Inumbo-ID: 6065b5b2-78ea-11ea-b58d-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6065b5b2-78ea-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 16:11:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586275862;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=y02V0vARKPxRDBC/3qJTQ6bXE7wJu8cF8gG8o3JrO8E=;
 b=GjS7cyATX3uYDn7nhkjaMmGZbwAxKgiLkTBxjZMG1wqt4Jzf0vUij+uf
 R6ThD2oDBK/b84MmlxHFI06VAFatwJzIUr6qgkEZUCp2RdmOwJDnPm9dm
 Z0VW0iOgb5YU+jIiA4Tu7og9bHFhdZOY/nbDzB4E55+G7XTKKyvrQePJJ I=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: qWGVzOX9dYdpiiwxttFGoBDa9XVQB0PtSa6rNhJFRDZaGJJiEUEz2W8CSnZU4dKFBy7k4uBMYw
 7kBxk3ZWgRfX4aqWF1txQdsR1QywuZH2o2F46Bm2wdUiRU0B1hp+LST3qLs92PoTHoXAbn2ile
 L5YRaMoyorpQA1lJv2yvMH1I92u7ke2hZgNpVA3dmxB1hn3KVsEZ0KlBwzIwhCx+jrVUwsPQkD
 SNJMLsaL2CM6/+j7CFw6LOT1TYMwHz39b/8Jo9a4yTaMe74JR7WVWT+EX80SE6HXv7/FJquv1u
 oNA=
X-SBRS: 2.7
X-MesageID: 15715915
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,355,1580792400"; d="scan'208";a="15715915"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24204.42515.354583.921270@mariner.uk.xensource.com>
Date: Tue, 7 Apr 2020 17:10:59 +0100
To: Dmitry Isaykin <isaikin-dmitry@yandex.ru>
Subject: Re: [PATCH] tools/xl: Remove the filelock when building VM if
 autoballooning is off
In-Reply-To: <20190311103622.20143-1-isaikin-dmitry@yandex.ru>
References: <20190311103622.20143-1-isaikin-dmitry@yandex.ru>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Dmitry Isaykin writes ("[PATCH] tools/xl: Remove the filelock when building VM if autoballooning is off"):
> The presence of this filelock does not allow building several VMs at the same
> time. This filelock was added to prevent other xl instances from using memory
> freeed for the currently building VM in autoballoon mode.
> 
> Signed-off-by: Dmitry Isaykin <isaikin-dmitry@yandex.ru>

Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>

This was deferred due to the Xen 4.13 freeze.  I found it in a todo
list of mine.  I think it should be committed and I will do so soon
unless someone objects.

Sorry for the delay, Dmitry!

Regards,
Ian.

>  tools/xl/xl_vmcontrol.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
> index a1d633795c..2b42bb487d 100644
> --- a/tools/xl/xl_vmcontrol.c
> +++ b/tools/xl/xl_vmcontrol.c
> @@ -873,9 +873,11 @@ int create_domain(struct domain_create *dom_info)
>  start:
>      assert(domid == INVALID_DOMID);
>  
> -    rc = acquire_lock();
> -    if (rc < 0)
> -        goto error_out;
> +    if (autoballoon) {
> +        rc = acquire_lock();
> +        if (rc < 0)
> +            goto error_out;
> +    }
>  
>      if (domid_soft_reset == INVALID_DOMID) {
>          if (!freemem(domid, &d_config.b_info)) {
> @@ -935,7 +937,8 @@ start:
>      if ( ret )
>          goto error_out;
>  
> -    release_lock();
> +    if (autoballoon)
> +        release_lock();
>  
>      if (restore_fd_to_close >= 0) {
>          if (close(restore_fd_to_close))
> @@ -1109,7 +1112,8 @@ start:
>      }
>  
>  error_out:
> -    release_lock();
> +    if (autoballoon)
> +        release_lock();
>      if (libxl_domid_valid_guest(domid)) {
>          libxl_domain_destroy(ctx, domid, 0);
>          domid = INVALID_DOMID;
> -- 
> 2.17.1
> 


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 16:15:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 16:15:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLqsn-00028n-42; Tue, 07 Apr 2020 16:15:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=AqR/=5X=chiark.greenend.org.uk=ijackson@srs-us1.protection.inumbo.net>)
 id 1jLqsm-00028i-BW
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 16:15:24 +0000
X-Inumbo-ID: fb9dd302-78ea-11ea-9e09-bc764e2007e4
Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fb9dd302-78ea-11ea-9e09-bc764e2007e4;
 Tue, 07 Apr 2020 16:15:23 +0000 (UTC)
Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk)
 by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp
 (return-path ijackson@chiark.greenend.org.uk)
 id 1jLqsk-0003Hn-25; Tue, 07 Apr 2020 17:15:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] MAINTAINERS: Remove all S: entries
Date: Tue,  7 Apr 2020 17:15:19 +0100
Message-Id: <20200407161519.16493-1-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 ian.jackson@eu.citrix.com, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Feature support status is tracked in SUPPORT.md nowadays.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 MAINTAINERS | 60 ------------------------------------------------------------
 1 file changed, 60 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8a4c869704..e784169d1b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -69,16 +69,6 @@ Descriptions of section entries:
 	L: Mailing list that is relevant to this area
 	W: Web-page with status/info
 	T: SCM tree type and location.  Type is one of: git, hg, quilt, stgit.
-	S: Status, one of the following:
-	   Supported:	Someone is actually paid to look after this.
-	   Maintained:	Someone actually looks after it.
-	   Odd Fixes:	It has a maintainer but they don't have time to do
-			much other than throw the odd patch in. See below..
-	   Orphan:	No current maintainer [but maybe you could take the
-			role as you write your new code].
-	   Obsolete:	Old code. Something tagged obsolete generally means
-			it has been replaced by a better system and you
-			should be using that.
 	F: Files and directories with wildcard patterns.
 	   A trailing slash includes all files and subdirectory files.
 	   F:	drivers/net/	all files in and below drivers/net
@@ -194,7 +184,6 @@ Maintainers List (try to look for most precise areas first)
 
 ACPI
 M:	Jan Beulich <jbeulich@suse.com>
-S:	Supported
 F:	xen/arch/x86/acpi/
 F:	xen/drivers/acpi/
 F:	xen/include/acpi/
@@ -203,19 +192,16 @@ F:	tools/libacpi/
 AMD IOMMU
 M:	Jan Beulich <jbeulich@suse.com>
 M:	Andrew Cooper <andrew.cooper3@citrix.com>
-S:	Maintained
 F:	xen/drivers/passthrough/amd/
 
 AMD SVM
 M:	Jan Beulich <jbeulich@suse.com>
 M:	Andrew Cooper <andrew.cooper3@citrix.com>
-S:	Supported
 F:	xen/arch/x86/hvm/svm/
 F:	xen/arch/x86/cpu/vpmu_amd.c
 
 ARGO
 M:	Christopher Clark <christopher.w.clark@gmail.com>
-S:	Maintained
 F:	xen/include/public/argo.h
 F:	xen/include/xen/argo.h
 F:	xen/common/argo.c
@@ -223,7 +209,6 @@ F:	xen/common/argo.c
 ARINC653 SCHEDULER
 M:	Josh Whitehead <josh.whitehead@dornerworks.com>
 M:	Stewart Hildebrand <stewart.hildebrand@dornerworks.com>
-S:	Supported
 L:	xen-devel@dornerworks.com
 F:	xen/common/sched/arinc653.c
 F:	tools/libxc/xc_arinc653.c
@@ -232,7 +217,6 @@ ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
 M:	Stefano Stabellini <sstabellini@kernel.org>
 M:	Julien Grall <julien@xen.org>
 R:	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
-S:	Supported
 L:	xen-devel@lists.xenproject.org
 F:	docs/misc/arm/
 F:	xen/arch/arm/
@@ -252,14 +236,12 @@ F:	xen/include/public/arch-arm.h
 Change Log
 M:	Paul Durrant <paul@xen.org>
 R:	Community Manager <community.manager@xenproject.org>
-S:	Maintained
 F:	CHANGELOG.md
 
 Continuous Integration (CI)
 M:	Doug Goldstein <cardoe@cardoe.com>
 W:	https://gitlab.com/xen-project/xen
 W:	https://travis-ci.org/xen-project/xen
-S:	Supported
 F:	.gitlab-ci.yml
 F:	.travis.yml
 F:	automation/
@@ -268,13 +250,11 @@ F:	scripts/travis-build
 CPU POOLS
 M:	Juergen Gross <jgross@suse.com>
 M:	Dario Faggioli <dfaggioli@suse.com>
-S:	Supported
 F:	xen/common/sched/cpupool.c
 
 DEVICE TREE
 M:	Stefano Stabellini <sstabellini@kernel.org>
 M:	Julien Grall <julien@xen.org>
-S:	Supported
 F:	xen/common/libfdt/
 F:	xen/common/device_tree.c
 F:	xen/include/xen/libfdt/
@@ -283,7 +263,6 @@ F:	xen/drivers/passthrough/device_tree.c
 
 EFI
 M:	Jan Beulich <jbeulich@suse.com>
-S:	Supported
 F:	xen/arch/x86/efi/
 F:	xen/common/efi/
 F:	xen/include/efi/
@@ -292,30 +271,25 @@ F:	xen/include/asm-x86/x86_*/efi*.h
 
 GDBSX DEBUGGER
 M:	Elena Ufimtseva <elena.ufimtseva@oracle.com>
-S:	Supported
 F:	xen/arch/x86/debug.c
 F:	tools/debugger/gdbsx/
 
 GOLANG BINDINGS
 M:	George Dunlap <george.dunlap@citrix.com>
-S:	Maintained
 F:	tools/golang
 
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
 R:	Lukasz Hawrylko <lukasz.hawrylko@linux.intel.com>
-S:	Odd Fixes
 F:	xen/arch/x86/tboot.c
 F:	xen/include/asm-x86/tboot.h
 
 INTEL(R) VT FOR DIRECTED I/O (VT-D)
 M:	Kevin Tian <kevin.tian@intel.com>
-S:	Supported
 F:	xen/drivers/passthrough/vtd/
 
 INTEL(R) VT FOR X86 (VT-X)
 M:	Jun Nakajima <jun.nakajima@intel.com>
 M:	Kevin Tian <kevin.tian@intel.com>
-S:	Supported
 F:	xen/arch/x86/hvm/vmx/
 F:	xen/arch/x86/mm/p2m-ept.c
 F:	xen/include/asm-x86/hvm/vmx/
@@ -324,7 +298,6 @@ F:	xen/arch/x86/cpu/vpmu_intel.c
 IOMMU VENDOR INDEPENDENT CODE
 M:	Jan Beulich <jbeulich@suse.com>
 M:	Paul Durrant <paul@xen.org>
-S:	Supported
 F:	xen/drivers/passthrough/
 X:	xen/drivers/passthrough/amd/
 X:	xen/drivers/passthrough/arm/
@@ -334,18 +307,15 @@ F:	xen/include/xen/iommu.h
 
 KCONFIG
 M:	Doug Goldstein <cardoe@cardoe.com>
-S:	Supported
 F:	docs/misc/kconfig{,-language}.txt
 F:	xen/tools/kconfig/
 
 KDD DEBUGGER
 M:	Tim Deegan <tim@xen.org>
-S:	Odd Fixes
 F:	tools/debugger/kdd/
 
 KEXEC
 M:	Andrew Cooper <andrew.cooper3@citrix.com>
-S:	Supported
 F:	xen/common/{kexec,kimage}.c
 F:	xen/include/{kexec,kimage}.h
 F:	xen/arch/x86/machine_kexec.c
@@ -355,14 +325,12 @@ LIBXENLIGHT
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
 M:	Wei Liu <wl@xen.org>
 M:	Anthony PERARD <anthony.perard@citrix.com>
-S:	Supported
 F:	tools/libxl/
 F:	tools/xl/
 
 LIVEPATCH
 M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 M:	Ross Lagerwall <ross.lagerwall@citrix.com>
-S:	Supported
 F:	docs/misc/livepatch.pandoc
 F:	tools/misc/xen-livepatch.c
 F:	xen/arch/*/livepatch*
@@ -374,7 +342,6 @@ F:	xen/test/livepatch/*
 
 MINI-OS
 M:	Samuel Thibault <samuel.thibault@ens-lyon.org>
-S:	Supported
 L:	minios-devel@lists.xenproject.org
 T:	git https://xenbits.xenproject.org/git-http/mini-os.git
 F:	config/MiniOS.mk
@@ -382,18 +349,15 @@ F:	config/MiniOS.mk
 OCAML TOOLS
 M:	Christian Lindig <christian.lindig@citrix.com>
 M:	David Scott <dave@recoil.org>
-S:	Supported
 F:	tools/ocaml/
 
 OVMF UPSTREAM
 M:	Anthony PERARD <anthony.perard@citrix.com>
 M:	Wei Liu <wl@xen.org>
-S:	Supported
 T:	git https://xenbits.xenproject.org/git-http/ovmf.git
 
 POWER MANAGEMENT
 M:	Jan Beulich <jbeulich@suse.com>
-S:	Supported
 F:	xen/arch/x86/acpi/
 X:	xen/arch/x86/acpi/boot.c
 X:	xen/arch/x86/acpi/lib.c
@@ -402,29 +366,24 @@ F:	xen/include/acpi/cpufreq/
 
 PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS
 M:	Juergen Gross <jgross@suse.com>
-S:	Supported
 F:	xen/include/public/io/
 
 PYTHON BINDINGS
 M:	Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
-S:	Supported
 F:	tools/python
 
 QEMU-DM
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
-S:	Supported
 T:	git https://xenbits.xenproject.org/git-http/qemu-xen-traditional.git
 
 QEMU UPSTREAM
 M:	Stefano Stabellini <sstabellini@kernel.org>
 M:	Anthony Perard <anthony.perard@citrix.com>
-S:	Supported
 T:	git https://xenbits.xenproject.org/git-http/qemu-xen.git
 
 REMUS
 M:	Shriram Rajagopalan <rshriram@cs.ubc.ca>
 M:	Yang Hongyang <imhy.yang@gmail.com>
-S:	Maintained
 F:	docs/README.remus
 F:	tools/libxl/libxl_remus_*
 F:	tools/libxl/libxl_netbuffer.c
@@ -435,37 +394,31 @@ F:	tools/hotplug/Linux/block-drbd-probe
 RTDS SCHEDULER
 M:	Dario Faggioli <dfaggioli@suse.com>
 M:	Meng Xu <mengxu@cis.upenn.edu>
-S:	Supported
 F:	xen/common/sched/rt.c
 
 SCHEDULING
 M:	George Dunlap <george.dunlap@citrix.com>
 M:	Dario Faggioli <dfaggioli@suse.com>
-S:	Supported
 F:	xen/common/sched/
 
 SEABIOS UPSTREAM
 M:	Wei Liu <wl@xen.org>
-S:	Supported
 T:	git https://xenbits.xenproject.org/git-http/seabios.git
 
 STUB DOMAINS
 M:	Samuel Thibault <samuel.thibault@ens-lyon.org>
-S:	Supported
 F:	config/Stubdom.mk.in
 F:	m4/stubdom.m4
 F:	stubdom/
 
 TEE MEDIATORS
 M:	Volodymyr Babchuk <volodymyr_babchuk@epam.com>
-S:	Supported
 F:	xen/arch/arm/tee/
 F:	xen/include/asm-arm/tee
 
 TOOLSTACK
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
 M:	Wei Liu <wl@xen.org>
-S:	Supported
 F:	autogen.sh
 F:	config/*.in
 F:	install.sh
@@ -483,7 +436,6 @@ VM EVENT, MEM ACCESS and MONITOR
 M:	Tamas K Lengyel <tamas@tklengyel.com>
 R:	Alexandru Isaila <aisaila@bitdefender.com>
 R:	Petre Pircalabu <ppircalabu@bitdefender.com>
-S:	Supported
 F:	tools/tests/xen-access
 F:	xen/arch/*/monitor.c
 F:	xen/arch/*/vm_event.c
@@ -502,14 +454,12 @@ F:	xen/include/asm-x86/hvm/vm_event.h
 
 VPCI
 M:	Roger Pau Monné <roger.pau@citrix.com>
-S:	Supported
 F:	xen/drivers/vpci/
 F:	xen/include/xen/vpci.h
 
 VTPM
 M:	Daniel De Graaf <dgdegra@tycho.nsa.gov>
 M:	Quan Xu <quan.xu0@gmail.com>
-S:	Supported
 F:	extras/mini-os/tpm*
 F:	extras/mini-os/include/tpm*
 F:	stubdom/vtpm/
@@ -521,7 +471,6 @@ M:	Jan Beulich <jbeulich@suse.com>
 M:	Andrew Cooper <andrew.cooper3@citrix.com>
 R:	Wei Liu <wl@xen.org>
 R:	Roger Pau Monné <roger.pau@citrix.com>
-S:	Supported
 L:	xen-devel@lists.xenproject.org
 F:	xen/arch/x86/
 F:	xen/include/asm-x86/
@@ -539,7 +488,6 @@ F:	tools/tests/x86_emulator/
 
 X86 I/O EMULATION
 M:	Paul Durrant <paul@xen.org>
-S:	Supported
 F:	xen/arch/x86/hvm/emulate.c
 F:	xen/arch/x86/hvm/intercept.c
 F:	xen/arch/x86/hvm/io.c
@@ -553,28 +501,23 @@ X86 MEMORY MANAGEMENT
 M:	Jan Beulich <jbeulich@suse.com>
 M:	Andrew Cooper <andrew.cooper3@citrix.com>
 R:	George Dunlap <george.dunlap@citrix.com>
-S:	Supported
 F:	xen/arch/x86/mm/
 
 X86 MEMORY PAGING
-S:	Orphaned
 F:	xen/arch/x86/mm/mem_paging.c
 
 X86 MEMORY SHARING
 M:	Tamas K Lengyel <tamas@tklengyel.com>
-S:	Odd Fixes
 F:	xen/arch/x86/mm/mem_sharing.c
 F:	tools/tests/mem-sharing/
 
 X86 SHADOW PAGETABLES
 M:	Tim Deegan <tim@xen.org>
-S:	Maintained
 F:	xen/arch/x86/mm/shadow/
 
 X86 VIRIDIAN ENLIGHTENMENTS
 M:	Paul Durrant <paul@xen.org>
 M:	Wei Liu <wl@xen.org>
-S:	Supported
 F:	xen/arch/x86/guest/hyperv/
 F:	xen/arch/x86/hvm/viridian/
 F:	xen/include/asm-x86/guest/hyperv.h
@@ -584,14 +527,12 @@ F:	xen/include/asm-x86/hvm/viridian.h
 
 XENTRACE
 M:	George Dunlap <george.dunlap@citrix.com>
-S:	Supported
 F:	tools/xentrace/
 F:	xen/common/trace.c
 F:	xen/include/xen/trace.h
 
 XSM/FLASK
 M:	Daniel De Graaf <dgdegra@tycho.nsa.gov>
-S:	Supported
 F:	tools/flask/
 F:	xen/include/xsm/
 F:	xen/xsm/
@@ -606,7 +547,6 @@ M:	Julien Grall <julien@xen.org>
 M:	Stefano Stabellini <sstabellini@kernel.org>
 M:	Wei Liu <wl@xen.org>
 L:	xen-devel@lists.xenproject.org
-S:	Supported
 F:	*
 F:	*/
 V:	xen-maintainers-1
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 16:16:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 16:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLqtq-0002D4-FM; Tue, 07 Apr 2020 16:16:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LBKk=5X=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jLqtp-0002Cz-SE
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 16:16:29 +0000
X-Inumbo-ID: 22bc2916-78eb-11ea-b4f4-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 22bc2916-78eb-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 16:16:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586276189;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=qsdtDSUBfo1nVHXLINQJJ5a/TXMpEYae9DK1jrNyKXI=;
 b=WbQAM+fWF0cUULy/5rDFz1H2vdGKNp74Gjkx7HtOLLT2ukPlsAKXabjt
 ueUbUmPPdp+jP6uTZtH1h0Mi3WbOxCxUBfeasDF7dyKhuqcy5oWswDX1i
 akIsF5QDejvOSu1Oelkdf6T9SjkvrHwFHc9nEiq8cPJKsi7Uqfii3ZLlw o=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: CffjwMus1Vp0KI+QEGbbXyQ24IlQK3g927kNMSANe+TcJ6P5uGd0rbMjGpKOfaPKOfQtCXmnO2
 FKjFQ3wAsqi3MMx7Pou206QYvaxf6V9e5Fx4mc5vpSl7SGS0vtGp8hEI4DtohzjEYjHUYDTdg0
 y0iyaejuseEFcaBoPznq5CXZLgXFBSSrgIQpkedWtozua2NpQtPH0XQVIibiW9V0FbxLv9qYS/
 iEPHj7zoXbFEVfTskzHX5zThV//insLRAlDIOex6uaiDqB+8fSwPxlFvtih02DNYu74mu8Auyh
 i/I=
X-SBRS: 2.7
X-MesageID: 15539618
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,355,1580792400"; d="scan'208";a="15539618"
From: George Dunlap <George.Dunlap@citrix.com>
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Topic: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Index: AQHWCRLu2U2EJ1WUk0i1KTanKYKpWqhmDBwAgAGf9wCAAAzcgIAEjVGAgAANpgCAAWgwAA==
Date: Tue, 7 Apr 2020 16:16:24 +0000
Message-ID: <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
In-Reply-To: <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <42700E388FCCE541A2D8B3204744D34C@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDYsIDIwMjAsIGF0IDc6NDcgUE0sIEp1bGllbiBHcmFsbCA8anVsaWVuQHhl
bi5vcmc+IHdyb3RlOg0KPiANCj4gT24gMDYvMDQvMjAyMCAxODo1OCwgR2VvcmdlIER1bmxhcCB3
cm90ZToNCj4+PiBPbiBBcHIgMywgMjAyMCwgYXQgOToyNyBQTSwgSnVsaWVuIEdyYWxsIDxqdWxp
ZW4uZ3JhbGwub3NzQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gT24gRnJpLCAzIEFwciAy
MDIwIGF0IDIwOjQxLCBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+
IHdyb3RlOg0KPj4+PiANCj4+Pj4gT24gVGh1LCAyIEFwciAyMDIwLCBKdWxpZW4gR3JhbGwgd3Jv
dGU6DQo+Pj4+PiBBcyB3ZSBkaXNjdXNzZWQgb24gVHVlc2RheSwgdGhlIGNvc3QgZm9yIG90aGVy
IHZDUFVzIGlzIG9ubHkgZ29pbmcgdG8gYmUgYQ0KPj4+Pj4gdHJhcCB0byB0aGUgaHlwZXJ2aXNv
ciBhbmQgdGhlbiBiYWNrIGFnYWluLiBUaGUgY29zdCBpcyBsaWtlbHkgc21hbGxlciB0aGFuDQo+
Pj4+PiByZWNlaXZpbmcgYW5kIGZvcndhcmRpbmcgYW4gaW50ZXJydXB0Lg0KPj4+Pj4gDQo+Pj4+
PiBZb3UgYWN0dWFsbHkgYWdyZWVkIG9uIHRoaXMgYW5hbHlzaXMuIFNvIGNhbiB5b3UgZW5saWdo
dGVuIG1lIGFzIHRvIHdoeQ0KPj4+Pj4gcmVjZWl2aW5nIGFuIGludGVycnVwdCBpcyBhIG5vdCBw
cm9ibGVtIGZvciBsYXRlbmN5IGJ1dCB0aGlzIGlzPw0KPj4+PiANCj4+Pj4gTXkgYW5zd2VyIHdh
cyB0aGF0IHRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgYW4gb3BlcmF0aW5nIHN5c3RlbSBjYW4NCj4+
Pj4gZGlzYWJsZSBpbnRlcnJ1cHRzLCBidXQgaXQgY2Fubm90IGRpc2FibGUgcmVjZWl2aW5nIHRo
aXMgc3BlY2lhbCBJUEkuDQo+Pj4gDQo+Pj4gQW4gT1MgY2FuICpvbmx5KiBkaXNhYmxlIGl0cyBv
d24gaW50ZXJydXB0cywgeWV0IGludGVycnVwdHMgd2lsbCBzdGlsbA0KPj4+IGJlIHJlY2VpdmVk
IGJ5IFhlbiBldmVuIGlmIHRoZSBpbnRlcnJ1cHRzIGFyZSBtYXNrZWQgYXQgdGhlIHByb2Nlc3Nv
cg0KPj4+IChlLmcgbG9jYWxfaXJxX2Rpc2FibGUoKSkuDQo+Pj4gDQo+Pj4gWW91IHdvdWxkIG5l
ZWQgdG8gZGlzYWJsZSBpbnRlcnJ1cHRzIG9uZSBieSBvbmUgYXMgdGhlIEdJQyBsZXZlbCAodXNl
DQo+Pj4gSUNFTkFCTEVSKSBpbiBvcmRlciB0byBub3QgcmVjZWl2ZSBhbnkgaW50ZXJydXB0cy4g
WWV0LCBYZW4gbWF5IHN0aWxsDQo+Pj4gcmVjZWl2ZSBpbnRlcnJ1cHRzIGZvciBvcGVyYXRpb25h
bCBwdXJwb3NlcyAoZS5nIHNlcmlhbCwgY29uc29sZSwNCj4+PiBtYWludGFpbmFuY2UgSVJRLi4u
KS4gU28gdHJhcCB3aWxsIGhhcHBlbi4NCj4+IEkgdGhpbmsgU3RlZmFub+KAmXMgYXNzZXJ0aW9u
IGlzIHRoYXQgdGhlIHVzZXJzIGhlIGhhcyBpbiBtaW5kIHdpbGwgYmUgY29uZmlndXJpbmcgdGhl
IHN5c3RlbSBzdWNoIHRoYXQgUlQgd29ya2xvYWRzIGdldCBhIG1pbmltdW0gbnVtYmVyIG9mIGh5
cGVydmlzb3ItcmVsYXRlZCBpbnRlcnJ1cHRzIHBvc3NpYmxlLiAgT24gYSA0LWNvcmUgc3lzdGVt
LCB5b3UgY291bGQgIGhhdmUgbm9uLVJUIHdvcmtsb2FkcyBydW5uaW5nIG9uIGNvcmVzIDAtMSwg
YW5kIFJUIHdvcmtsb2FkcyBydW5uaW5nIHdpdGggdGhlIE5VTEwgc2NoZWR1bGVyIG9uIGNvcmVz
IDItMy4gIEluIHN1Y2ggYSBzeXN0ZW0sIHlvdeKAmWQgb2J2aW91c2x5IGFycmFuZ2UgdGhhdCBz
ZXJpYWwgYW5kIG1haW50ZW5hbmNlIElSUXMgYXJlIGRlbGl2ZXJlZCB0byBjb3JlcyAwLTEuDQo+
IFdlbGwgbWFpbnRlbmFuY2UgSVJRcyBhcmUgcGVyIHBDUFUgc28geW91IGNhbid0IHJvdXRlIHRv
IGFub3RoZXIgb25lLi4uDQo+IA0KPiBCdXQsIEkgdGhpbmsgeW91IG1pc3NlZCBteSBwb2ludCB0
aGF0IGxvY2FsX2lycV9kaXNhYmxlKCkgZnJvbSB0aGUgZ3Vlc3Qgd2lsbCBub3QgcHJldmVudCB0
aGUgaHlwZXJ2aXNvciB0byByZWNlaXZlIGludGVycnVwdHMgKmV2ZW4qIHRoZSBvbmUgcm91dGVk
IHRvIHRoZSB2Q1BVIGl0c2VsZi4gVGhleSB3aWxsIGp1c3Qgbm90IGJlIGRlbGl2ZXJlZCB0byB0
aGUgZ3Vlc3QgY29udGV4dCB1bnRpbCBsb2NhbF9pcnFfZW5hYmxlKCkgaXMgY2FsbGVkLg0KDQpN
eSB1bmRlcnN0YW5kaW5nLCBmcm9tIFN0ZWZhbm8gd2FzIHRoYXQgd2hhdCBoaXMgY3VzdG9tZXJz
IGFyZSBjb25jZXJuZWQgYWJvdXQgaXMgdGhlIHRpbWUgYmV0d2VlbiB0aGUgdGltZSBhIHBoeXNp
Y2FsIElSUSBpcyBkZWxpdmVyZWQgdG8gdGhlIGd1ZXN0IGFuZCB0aGUgdGltZSB0aGUgZ3Vlc3Qg
T1MgY2FuIHJlc3BvbmQgYXBwcm9wcmlhdGVseS4gIFRoZSBrZXkgdGhpbmcgaGVyZSBpc27igJl0
IG5lY2Vzc2FyaWx5IHNwZWVkLCBidXQgcHJlZGljdGFiaWxpdHkg4oCUIHN5c3RlbSBkZXNpZ25l
cnMgbmVlZCB0byBrbm93IHRoYXQsIHdpdGggYSBoaWdoIHByb2JhYmlsaXR5LCB0aGVpciBpbnRl
cnJ1cHQgcm91dGluZXMgd2lsbCBjb21wbGV0ZSB3aXRoaW4gWCBhbW91bnQgb2YgY3ljbGVzLg0K
DQpGdXJ0aGVyIGludGVycnVwdHMgZGVsaXZlcmVkIHRvIGEgZ3Vlc3QgYXJlIG5vdCBhIHByb2Js
ZW0gaW4gdGhpcyBzY2VuYXJpbywgaWYgdGhlIGd1ZXN0IGNhbiBkaXNhYmxlIHRoZW0gdW50aWwg
dGhlIGNyaXRpY2FsIElSUSBoYXMgYmVlbiBoYW5kbGVkLg0KDQpYZW4tcmVsYXRlZCBJUElzLCBo
b3dldmVyLCBjb3VsZCBwb3RlbnRpYWxseSBjYXVzZSBhIHByb2JsZW0gaWYgbm90IG1pdGlnYXRl
ZC4gIENvbnNpZGVyIGEgZ3Vlc3Qgd2hlcmUgdmNwdSAxIGxvb3BzIG92ZXIgdGhlIHJlZ2lzdGVy
LCB3aGlsZSB2Y3B1IDIgaXMgaGFuZGxpbmcgYSBsYXRlbmN5LWNyaXRpY2FsIElSUS4gIEEgbmFp
dmUgaW1wbGVtZW50YXRpb24gbWlnaHQgc2VuZCBhbiBJUEkgZXZlcnkgdGltZSB2Y3B1IDEgZG9l
cyBhIHJlYWQsIHNwYW1taW5nIHZjcHUgMiB3aXRoIGRvemVucyBvZiBJUElzLiAgVGhlbiBhbiBJ
UlEgcm91dGluZSB3aGljaCByZWxpYWJseSBmaW5pc2hlcyB3ZWxsIHdpdGhpbiB0aGUgcmVxdWly
ZWQgdGltZSBub3JtYWxseSBzdWRkZW5seSBvdmVycnVucyBhbmQgY2F1c2VzIGFuIGlzc3VlLg0K
DQpJIGRvbuKAmXQga25vdyB3aGF0IG1haW50ZW5hbmNlIElSUXMgYXJlLCBidXQgaWYgdGhleSBv
bmx5IGhhcHBlbiBpbnRlcm1pdHRlbnRseSwgaXTigJlzIHBvc3NpYmxlIHRoYXQgeW914oCZZCBu
ZXZlciBnZXQgbW9yZSB0aGFuIGEgc2luZ2xlIG9uZSBpbiBhIGxhdGVuY3ktY3JpdGljYWwgSVJR
IHJvdXRpbmU7IGFuZCBhcyBzdWNoLCB0aGUgdmFyaWF0aWJpbGl0eSBpbiBleGVjdXRpb24gdGlt
ZSAoaml0dGVyKSB3b3VsZG7igJl0IGJlIGFuIGlzc3VlIGluIHByYWN0aWNlLiAgQnV0IGV2ZXJ5
IHRpbWUgeW91IGFkZCBhIG5ldyB1bmJsb2NrYWJsZSBJUEksIHlvdSBpbmNyZWFzZSB0aGlzIGpp
dHRlcjsgcGFydGljdWxhcmx5IGlmIHRoaXMgdW5ibG9ja2FibGUgSVBJIG1pZ2h0IGJlIHJlcGVh
dGVkIGFuIGFyYml0cmFyeSBudW1iZXIgb2YgdGltZXMuDQoNCihTdGVmYW5vLCBsZXQgbWUga25v
dyBpZiBJ4oCZdmUgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcuKQ0KDQpTbyBzdGVwcGluZyBiYWNr
IGEgbW9tZW50LCBoZXJl4oCZcyBhbGwgdGhlIHBvc3NpYmxlIGlkZWFzIHRoYXQgSSB0aGluayBo
YXZlIGJlZW4gZGlzY3Vzc2VkIChvciBhcmUgdGhlcmUgaW1wbGljaXRseSkgc28gZmFyLg0KDQox
LiBbRGVmYXVsdF0gRG8gbm90aGluZzsgZ3Vlc3RzIHVzaW5nIHRoaXMgcmVnaXN0ZXIgY29udGlu
dWUgY3Jhc2hpbmcNCg0KMi4gTWFrZSB0aGUgST9BQ1RJVkVSIHJlZ2lzdGVycyBSWldJLg0KDQoz
LiBNYWtlIEk/QUNUSVZFUiByZXR1cm4gdGhlIG1vc3QgcmVjZW50IGtub3duIHZhbHVlOyBpLmUu
IEtWTeKAmXMgY3VycmVudCBiZWhhdmlvciAoYXMgZmFyIGFzIHdlIHVuZGVyc3RhbmQgaXQpDQoN
CjQuIFVzZSBhIHNpbXBsZSBJUEkgd2l0aCBkb19ub29wIHRvIHVwZGF0ZSBJP0FDVElWRVINCg0K
NGEuICBVc2UgYW4gSVBJLCBidXQgY29tZSB1cCB3aXRoIGNsZXZlciB0cmlja3MgdG8gYXZvaWQg
aW50ZXJydXB0aW5nIGd1ZXN0cyBoYW5kbGluZyBJUlFzLg0KDQo1LiBUcmFwIHRvIFhlbiBvbiBn
dWVzdCBFT0ksIHNvIHRoYXQgd2Uga25vdyB3aGVuIHRoZSANCg0KNi4gU29tZSBjbGV2ZXIgcGFy
YXZpcnR1YWxpemVkIG9wdGlvbg0KDQpPYnZpb3VzbHkgbm9ib2R5IHdhbnRzICMxLCBhbmQgIzMg
aXMgY2xlYXJseSBub3QgcmVhbGx5IGFuIG9wdGlvbiBub3cgZWl0aGVyLg0KDQojMiBpcyBub3Qg
Z3JlYXQsIGJ1dCBpdOKAmXMgc2ltcGxlIGFuZCBxdWljayB0byBpbXBsZW1lbnQgZm9yIG5vdy4g
IEp1bGllbiwgSeKAmW0gbm90IHN1cmUgeW91ciBwb3NpdGlvbiBvbiB0aGlzIG9uZTogWW91IHJl
amVjdGVkIHRoZSBpZGVhIGJhY2sgaW4gdjEgb2YgdGhpcyBwYXRjaCBzZXJpZXMsIGJ1dCBzZWVt
ZWQgdG8gcmVmZXIgdG8gaXQgYWdhaW4gZWFybGllciBpbiB0aGlzIHRocmVhZC4NCg0KIzQgaXMg
cmVsYXRpdmVseSBxdWljayB0byBpbXBsZW1lbnQgYSDigJxkdW1i4oCdIHZlcnNpb24sIGJ1dCBz
dWNoIGEg4oCcZHVtYuKAnSB2ZXJzaW9uIGhhcyBhIGhpZ2ggcmlzayBvZiBjYXVzaW5nIHVuYWNj
ZXB0YWJsZSBqaXR0ZXIgKG9yIGF0IGxlYXN0LCBzbyBTdGVmYW5vIGJlbGlldmVzKS4NCg0KIzRh
IG9yICM2IGFyZSBmdXJ0aGVyIHBvdGVudGlhbCBsaW5lcyB0byBleHBsb3JlLCBidXQgd291bGQg
cmVxdWlyZSBhIGxvdCBvZiBhZGRpdGlvbmFsIGRlc2lnbiB0byBnZXQgd29ya2luZyByaWdodC4N
Cg0KSSB0aGluayBpZiBJIHVuZGVyc3RhbmQgU3RlZmFub+KAmXMgUG9WLCB0aGVuICM1IHdvdWxk
IGFjdHVhbGx5IGJlIGFjY2VwdGFibGUg4oCUIHRoZSBvdmVyYWxsIGFtb3VudCBvZiB0aW1lIHNw
ZW50IGluIHRoZSBoeXBlcnZpc29yIHdvdWxkIHByb2JhYmx5IGJlIGdyZWF0ZXIsIGJ1dCBpdCB3
b3VsZCBiZSBib3VuZGVkIGFuZCBwcmVkaWN0YWJsZTogb25jZSBzb21lb25lIGdvdCB0aGVpciBJ
UlEgaGFuZGxlciB3b3JraW5nIHJlbGlhYmx5LCBpdCB3b3VsZCBsaWtlbHkgY29udGludWUgdG8g
d29yay4NCg0KSXQgc291bmRzIGxpa2UgIzUgbWlnaHQgYmUgcHJldHR5IHF1aWNrIHRvIGltcGxl
bWVudDsgYW5kIHRoZW4gYXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlIGlmIHNvbWVvbmUgd2Fu
dHMgdG8gaW1wcm92ZSBwZXJmb3JtYW5jZSwgdGhleSBjYW4gd29yayBvbiA0YSBvciA2Lg0KDQpB
bnkgdGhvdWdodHM/ICBBbnl0aGluZyBJ4oCZbSBtaXNzaW5nPw0KDQogLUdlb3JnZQ==


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 16:23:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 16:23:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLr0w-00036l-E9; Tue, 07 Apr 2020 16:23:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Jrji=5X=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jLr0u-00036g-Un
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 16:23:48 +0000
X-Inumbo-ID: 28caa020-78ec-11ea-80fe-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 28caa020-78ec-11ea-80fe-12813bfff9fa;
 Tue, 07 Apr 2020 16:23:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=LQGP1fTF3C6QjA4Ix13jNx+O7KOuOlh/xXaCviki9NA=; b=fzoD0DuRc2B6lxQGmTO9zjKmoF
 +vRPO998bWz3ph9Z8GdNVb5UItpRm/Hml49mryPr5pJNzFbovCJ0wYG2hwIq1gL+s77LxVbi346f6
 unv9RYx3/GoDMghXS7i8JfksMKdFOslTWFOgRrFKPEvBFVQQ70hUopSm2V3pMg9r+2A0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jLr0s-0007JB-Hu; Tue, 07 Apr 2020 16:23:46 +0000
Received: from 54-240-197-225.amazon.com ([54.240.197.225]
 helo=freeip.amazon.com) by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jLr0s-0002yN-79; Tue, 07 Apr 2020 16:23:46 +0000
Message-ID: <6507a4a619c80afce01f2eaeef1f0d772aaadfef.camel@xen.org>
Subject: Re: [PATCH 5/5] x86_64/mm: map and unmap page tables in
 destroy_m2p_mapping
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>
Date: Tue, 07 Apr 2020 17:23:44 +0100
In-Reply-To: <7981c892-0e5c-03fb-679c-94f023a5c9fc@suse.com>
References: <cover.1584955616.git.hongyxia@amazon.com>
 <7143c2a1e0c7ca46b3ace329d7dcab85e0b5c87c.1584955616.git.hongyxia@amazon.com>
 <7981c892-0e5c-03fb-679c-94f023a5c9fc@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 2020-04-01 at 14:40 +0200, Jan Beulich wrote:
> On 23.03.2020 10:41, Hongyan Xia wrote:
> > @@ -297,26 +298,33 @@ static void destroy_m2p_mapping(struct
> > mem_hotadd_info *info)
> >              continue;
> >          }
> >  
> > -        l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
> > +        l2_ro_mpt =
> > map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]);
> >          if (!(l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) &
> > _PAGE_PRESENT))
> >          {
> >              i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
> >                      (1UL << (L2_PAGETABLE_SHIFT - 3)) ;
> > +            UNMAP_DOMAIN_PAGE(l2_ro_mpt);
> >              continue;
> >          }
> >  
> >          pt_pfn = l2e_get_pfn(l2_ro_mpt[l2_table_offset(va)]);
> >          if ( hotadd_mem_valid(pt_pfn, info) )
> >          {
> > +            l2_pgentry_t *l2t;
> > +
> >              destroy_xen_mappings(rwva, rwva + (1UL <<
> > L2_PAGETABLE_SHIFT));
> >  
> > -            l2_ro_mpt =
> > l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
> > -            l2e_write(&l2_ro_mpt[l2_table_offset(va)],
> > l2e_empty());
> > +            l2t =
> > map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]);
> 
> Why a 2nd mapping of the same L3 entry that you've already mapped
> into l2_ro_mpt?
> > +            l2e_write(&l2t[l2_table_offset(va)], l2e_empty());
> > +            UNMAP_DOMAIN_PAGE(l2t);
> 
> If this then weren't to go away, it should again be the lowercase
> variant imo, as the variable's scope ends here.

Hmm, I don't see a reason why l2_ro_mpt needs to be mapped again either
(and don't see why it was re-derived in the original code), so yes, I
think the map and unmap can just be dropped. Will revise.

Hongyan



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 16:25:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 16:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLr2f-0003Cv-RA; Tue, 07 Apr 2020 16:25:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qcBw=5X=arm.com=bertrand.marquis@srs-us1.protection.inumbo.net>)
 id 1jLr2d-0003C8-Qi
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 16:25:36 +0000
X-Inumbo-ID: 67430612-78ec-11ea-9e09-bc764e2007e4
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown
 [2a01:111:f400:fe0c::60d])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 67430612-78ec-11ea-9e09-bc764e2007e4;
 Tue, 07 Apr 2020 16:25:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; 
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tB4PXvXZNP2UaS5EULefivloK69BEJlzmNqNjToyoCE=;
 b=2s0OTm9IFA/bP0chJZ0R2FMTcamhPk0z+Vm9Rm8jeclOc1SSx3fM1W4GAvAgFC9vG+arS4wDAfkL+54OzpFcPIfB8EA1gQGEjb8xAuBC9deV4DVB7Rkkv9M613RExxe47KeOYq7BQeYZg/853YZ8TKHG47Lv/kjPRearFt8kJ6M=
Received: from DB6P193CA0010.EURP193.PROD.OUTLOOK.COM (2603:10a6:6:29::20) by
 AM6PR08MB3589.eurprd08.prod.outlook.com (2603:10a6:20b:46::17) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2878.20; Tue, 7 Apr 2020 16:25:31 +0000
Received: from DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com
 (2603:10a6:6:29:cafe::be) by DB6P193CA0010.outlook.office365.com
 (2603:10a6:6:29::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend
 Transport; Tue, 7 Apr 2020 16:25:31 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was
 verified) header.d=armh.onmicrosoft.com;lists.xenproject.org;
 dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB5EUR03FT052.mail.protection.outlook.com (10.152.21.82) with
 Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2856.17 via Frontend Transport; Tue, 7 Apr 2020 16:25:31 +0000
Received: ("Tessian outbound 9e48e1321951:v50");
 Tue, 07 Apr 2020 16:25:30 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 0351e1a34d49761e
X-CR-MTA-TID: 64aa7808
Received: from 90945b710d4e.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 2D81F675-6A6F-498F-BFFD-1C2A677B7E57.1; 
 Tue, 07 Apr 2020 16:25:25 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 90945b710d4e.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Tue, 07 Apr 2020 16:25:25 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=V4mvOKstC87TOInv2eB4PZPE1xJW8H3ZlMqwF3kkivYEo3UOBvY30Un1wvjl63o1CEOX+bx2bDsK96y8j6sYSM0b38fYjHLozhkjJQLe2qy+UPPklhAW0ineA8Vh4rP2Vz0SOsiu09uEaB9wCtkPMhCIxkPVrlEdiUh51HyaHU9G3k2SM7yMy1X8x+x7xgvjZa9J6GZHTTgoz/al890yykTuIvQytWF/x97Dd4j+60yHkHOEjLWztPkUJmGniyD6dhpHO4RgKEIPbcLjT8ODFOVvWINH2v+3YY7/WOtMug6E1xikG6YEkH3uVrkJs6EfWh8eM7oef6zSI/Zpr2LPNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tB4PXvXZNP2UaS5EULefivloK69BEJlzmNqNjToyoCE=;
 b=b1mJxq2fbjBTD+4/EQJisV5vNSjD/W+Jn75uBwDq7hkV+rwtf4f3obCxqAz700VzIQQBy0d8PVZSFUE1Lo75trKaFK5USdZC1y5U77kddImmq0EtEA64bZz0dwTOLlxPy7f0cQmK3Kl6uyaMFKOyFZs+BsPsas7YeOgAt4400dBr874Oi6Vx96gHf7UDg0Hv3AFOzbAIsNIo18UoY3AV6oJr6DmSmOj6xVP1Cswr5hG1QFHnnQOUq/MxjJoD/rgyOEFQzCo/l1K6rKe6kIQsCgQPiMDkZ2gyVG2ByPqArjM51wcnZPdTPozdkOv5InecJXck18ne3+u6PCs2jOSEXg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; 
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tB4PXvXZNP2UaS5EULefivloK69BEJlzmNqNjToyoCE=;
 b=2s0OTm9IFA/bP0chJZ0R2FMTcamhPk0z+Vm9Rm8jeclOc1SSx3fM1W4GAvAgFC9vG+arS4wDAfkL+54OzpFcPIfB8EA1gQGEjb8xAuBC9deV4DVB7Rkkv9M613RExxe47KeOYq7BQeYZg/853YZ8TKHG47Lv/kjPRearFt8kJ6M=
Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (20.178.46.80) by
 DB7PR08MB3321.eurprd08.prod.outlook.com (52.134.111.140) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2878.20; Tue, 7 Apr 2020 16:25:23 +0000
Received: from DB7PR08MB3689.eurprd08.prod.outlook.com
 ([fe80::94d7:a242:40b4:cfb5]) by DB7PR08MB3689.eurprd08.prod.outlook.com
 ([fe80::94d7:a242:40b4:cfb5%6]) with mapi id 15.20.2878.021; Tue, 7 Apr 2020
 16:25:23 +0000
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: George Dunlap <George.Dunlap@citrix.com>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Topic: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Index: AQHWB8CUPtV45V7pfkaBDuUahGESj6hj8BaAgAImRYCAABntAIABn/cAgAAM24CABI1SgIAADaYAgAFoMACAAAKBAA==
Date: Tue, 7 Apr 2020 16:25:23 +0000
Message-ID: <C92DBD17-A2FF-48CC-AE75-228BF51F41C2@arm.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
In-Reply-To: <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Authentication-Results-Original: spf=none (sender IP is )
 smtp.mailfrom=Bertrand.Marquis@arm.com; 
x-originating-ip: [82.24.250.194]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: e566b781-acaa-4561-5d7b-08d7db104a79
x-ms-traffictypediagnostic: DB7PR08MB3321:|AM6PR08MB3589:
X-Microsoft-Antispam-PRVS: <AM6PR08MB3589D704FA1D80A692D22F239DC30@AM6PR08MB3589.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882;
x-forefront-prvs: 036614DD9C
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en;
 SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com;
 PTR:; CAT:NONE; SFTY:;
 SFS:(10009020)(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(186003)(71200400001)(6506007)(33656002)(6512007)(4326008)(6486002)(6916009)(91956017)(36756003)(5660300002)(26005)(2616005)(86362001)(8936002)(76116006)(66446008)(81166006)(64756008)(2906002)(66556008)(66946007)(478600001)(54906003)(316002)(8676002)(66476007)(81156014)(53546011);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: Mg0+EFqyVhyzvRr0HJsJMH5uVN3fVqcHTCgEjCI1Lkpt5Z1xR3I7eeWClwJqdqkHheF68XEQHm05bFFtJL/8yiAFp3KyN6h4AUab8qatYnqOsJFIF3maPGxkUbno20CknWmv1p3FhexIURZ7+rv9LPpbViOxTdXdWxU1jQi/u96f4OnN/6N3t4Cidx+yBxz1lAKfkqy67Y/KzZyWoC50EpgylioKZZiOvERhIW/1KVxsb0uH+ytZL5D6WbzHNgkAFcNgTqTXiAH3Rihhe5L8hrBV3qKnzwdFxNpwWSOHuJtXxopNV2eQRysPj1rNiYGYA8GceJdgIIKMYGHPnxQc31IkLPAEQiKPJPlxjgcM5aR4AbEE2e+3pHWkNxK5EHtbO3YhyKbCu2cliPgfqkQKan0CIB9dpLj0Xl6LqxmsU1lZsCFVqQ+SgdZGnJoCVp8N
x-ms-exchange-antispam-messagedata: Q/rbLm9Y4/qJ5BxtBKWN5ZsEUhwLGC/QhEM17erfekSPjGvD1w9+vip2RjtgT3w3afFvuFi0rODDCF4spH+1XIdwImEOmChAY1Dh/7TlYG17tyJUWcV+aTEOamrbqiyYjRDUG5luyfokEM2tuwlpgA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
 boundary="_000_C92DBD17A2FF48CCAE75228BF51F41C2armcom_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3321
Original-Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=Bertrand.Marquis@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;
 IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;
 PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:;
 SFS:(10009020)(4636009)(39860400002)(396003)(376002)(136003)(346002)(46966005)(70206006)(70586007)(47076004)(2906002)(6862004)(33656002)(26826003)(478600001)(26005)(33964004)(4326008)(36756003)(336012)(186003)(45080400002)(6506007)(53546011)(2616005)(6486002)(8936002)(30864003)(5660300002)(8676002)(316002)(356004)(82740400003)(81156014)(54906003)(6512007)(81166006)(86362001);
 DIR:OUT; SFP:1101; 
X-MS-Office365-Filtering-Correlation-Id-Prvs: e9b7b160-3e55-46c6-4799-08d7db1045f4
X-Forefront-PRVS: 036614DD9C
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: zbDWLnR+WtfSa8IDsenS/7HTn8/kzemL3CwH4SQgqNqn96f1YHX0ENkhnnnUgzT5E67CeMg/1V445pqSNfo62nUC5+2y+2/EhyQC4Yu81KaePY3rweQWXVCSTr0fI+HpgngLpgq9f1VGA8v+YDazw85uydmSF0u9rSN5NTW2Wo0ZnVyZYr/EZLDwJpVScfaLivpgSCFWx8S8XnRr+GAq1XtnWHOhwVPhHs81HFCFt9R+rcFdISjImNcKy0A49JY3erjnnYlwAtWBhJhEIDlfSReJdulauIgH8W4rp+8nW7QdYm7fKIvQAeRQ1YsCmKmlRoI60tPILUjjpSatQ7OK05cV1fmA0bGBY9NHucBjbeT83uVz/LwE1RYo9vmVgAB4BvXguvE3pkr+KAIoXOnvM2N+p9XCzm9IZMsC6RzIMcXSSqBhqL/ArPf3vk9175uLi4yp7u8Yjy/nXe4RO3xk/HdvC/lR9MuT9rpuIfycqjP+g6Z6c2INXIXHk67GMPNGjg5w7uMz2KIH0OzBEp6/Ig==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 16:25:31.1571 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e566b781-acaa-4561-5d7b-08d7db104a79
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];
 Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3589
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, "maz@kernel.org" <maz@kernel.org>,
 Wei Xu <xuwei5@hisilicon.com>, nd <nd@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--_000_C92DBD17A2FF48CCAE75228BF51F41C2armcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCk9uIDcgQXByIDIwMjAsIGF0IDE3OjE2LCBHZW9yZ2UgRHVubGFwIDxHZW9yZ2UuRHVubGFw
QGNpdHJpeC5jb208bWFpbHRvOkdlb3JnZS5EdW5sYXBAY2l0cml4LmNvbT4+IHdyb3RlOg0KDQoN
Cg0KT24gQXByIDYsIDIwMjAsIGF0IDc6NDcgUE0sIEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5v
cmc8bWFpbHRvOmp1bGllbkB4ZW4ub3JnPj4gd3JvdGU6DQoNCk9uIDA2LzA0LzIwMjAgMTg6NTgs
IEdlb3JnZSBEdW5sYXAgd3JvdGU6DQpPbiBBcHIgMywgMjAyMCwgYXQgOToyNyBQTSwgSnVsaWVu
IEdyYWxsIDxqdWxpZW4uZ3JhbGwub3NzQGdtYWlsLmNvbTxtYWlsdG86anVsaWVuLmdyYWxsLm9z
c0BnbWFpbC5jb20+PiB3cm90ZToNCg0KT24gRnJpLCAzIEFwciAyMDIwIGF0IDIwOjQxLCBTdGVm
YW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc8bWFpbHRvOnNzdGFiZWxsaW5p
QGtlcm5lbC5vcmc+PiB3cm90ZToNCg0KT24gVGh1LCAyIEFwciAyMDIwLCBKdWxpZW4gR3JhbGwg
d3JvdGU6DQpBcyB3ZSBkaXNjdXNzZWQgb24gVHVlc2RheSwgdGhlIGNvc3QgZm9yIG90aGVyIHZD
UFVzIGlzIG9ubHkgZ29pbmcgdG8gYmUgYQ0KdHJhcCB0byB0aGUgaHlwZXJ2aXNvciBhbmQgdGhl
biBiYWNrIGFnYWluLiBUaGUgY29zdCBpcyBsaWtlbHkgc21hbGxlciB0aGFuDQpyZWNlaXZpbmcg
YW5kIGZvcndhcmRpbmcgYW4gaW50ZXJydXB0Lg0KDQpZb3UgYWN0dWFsbHkgYWdyZWVkIG9uIHRo
aXMgYW5hbHlzaXMuIFNvIGNhbiB5b3UgZW5saWdodGVuIG1lIGFzIHRvIHdoeQ0KcmVjZWl2aW5n
IGFuIGludGVycnVwdCBpcyBhIG5vdCBwcm9ibGVtIGZvciBsYXRlbmN5IGJ1dCB0aGlzIGlzPw0K
DQpNeSBhbnN3ZXIgd2FzIHRoYXQgdGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBhbiBvcGVyYXRpbmcg
c3lzdGVtIGNhbg0KZGlzYWJsZSBpbnRlcnJ1cHRzLCBidXQgaXQgY2Fubm90IGRpc2FibGUgcmVj
ZWl2aW5nIHRoaXMgc3BlY2lhbCBJUEkuDQoNCkFuIE9TIGNhbiAqb25seSogZGlzYWJsZSBpdHMg
b3duIGludGVycnVwdHMsIHlldCBpbnRlcnJ1cHRzIHdpbGwgc3RpbGwNCmJlIHJlY2VpdmVkIGJ5
IFhlbiBldmVuIGlmIHRoZSBpbnRlcnJ1cHRzIGFyZSBtYXNrZWQgYXQgdGhlIHByb2Nlc3Nvcg0K
KGUuZyBsb2NhbF9pcnFfZGlzYWJsZSgpKS4NCg0KWW91IHdvdWxkIG5lZWQgdG8gZGlzYWJsZSBp
bnRlcnJ1cHRzIG9uZSBieSBvbmUgYXMgdGhlIEdJQyBsZXZlbCAodXNlDQpJQ0VOQUJMRVIpIGlu
IG9yZGVyIHRvIG5vdCByZWNlaXZlIGFueSBpbnRlcnJ1cHRzLiBZZXQsIFhlbiBtYXkgc3RpbGwN
CnJlY2VpdmUgaW50ZXJydXB0cyBmb3Igb3BlcmF0aW9uYWwgcHVycG9zZXMgKGUuZyBzZXJpYWws
IGNvbnNvbGUsDQptYWludGFpbmFuY2UgSVJRLi4uKS4gU28gdHJhcCB3aWxsIGhhcHBlbi4NCkkg
dGhpbmsgU3RlZmFub+KAmXMgYXNzZXJ0aW9uIGlzIHRoYXQgdGhlIHVzZXJzIGhlIGhhcyBpbiBt
aW5kIHdpbGwgYmUgY29uZmlndXJpbmcgdGhlIHN5c3RlbSBzdWNoIHRoYXQgUlQgd29ya2xvYWRz
IGdldCBhIG1pbmltdW0gbnVtYmVyIG9mIGh5cGVydmlzb3ItcmVsYXRlZCBpbnRlcnJ1cHRzIHBv
c3NpYmxlLiAgT24gYSA0LWNvcmUgc3lzdGVtLCB5b3UgY291bGQgIGhhdmUgbm9uLVJUIHdvcmts
b2FkcyBydW5uaW5nIG9uIGNvcmVzIDAtMSwgYW5kIFJUIHdvcmtsb2FkcyBydW5uaW5nIHdpdGgg
dGhlIE5VTEwgc2NoZWR1bGVyIG9uIGNvcmVzIDItMy4gIEluIHN1Y2ggYSBzeXN0ZW0sIHlvdeKA
mWQgb2J2aW91c2x5IGFycmFuZ2UgdGhhdCBzZXJpYWwgYW5kIG1haW50ZW5hbmNlIElSUXMgYXJl
IGRlbGl2ZXJlZCB0byBjb3JlcyAwLTEuDQpXZWxsIG1haW50ZW5hbmNlIElSUXMgYXJlIHBlciBw
Q1BVIHNvIHlvdSBjYW4ndCByb3V0ZSB0byBhbm90aGVyIG9uZS4uLg0KDQpCdXQsIEkgdGhpbmsg
eW91IG1pc3NlZCBteSBwb2ludCB0aGF0IGxvY2FsX2lycV9kaXNhYmxlKCkgZnJvbSB0aGUgZ3Vl
c3Qgd2lsbCBub3QgcHJldmVudCB0aGUgaHlwZXJ2aXNvciB0byByZWNlaXZlIGludGVycnVwdHMg
KmV2ZW4qIHRoZSBvbmUgcm91dGVkIHRvIHRoZSB2Q1BVIGl0c2VsZi4gVGhleSB3aWxsIGp1c3Qg
bm90IGJlIGRlbGl2ZXJlZCB0byB0aGUgZ3Vlc3QgY29udGV4dCB1bnRpbCBsb2NhbF9pcnFfZW5h
YmxlKCkgaXMgY2FsbGVkLg0KDQpNeSB1bmRlcnN0YW5kaW5nLCBmcm9tIFN0ZWZhbm8gd2FzIHRo
YXQgd2hhdCBoaXMgY3VzdG9tZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQgaXMgdGhlIHRpbWUgYmV0
d2VlbiB0aGUgdGltZSBhIHBoeXNpY2FsIElSUSBpcyBkZWxpdmVyZWQgdG8gdGhlIGd1ZXN0IGFu
ZCB0aGUgdGltZSB0aGUgZ3Vlc3QgT1MgY2FuIHJlc3BvbmQgYXBwcm9wcmlhdGVseS4gIFRoZSBr
ZXkgdGhpbmcgaGVyZSBpc27igJl0IG5lY2Vzc2FyaWx5IHNwZWVkLCBidXQgcHJlZGljdGFiaWxp
dHkg4oCUIHN5c3RlbSBkZXNpZ25lcnMgbmVlZCB0byBrbm93IHRoYXQsIHdpdGggYSBoaWdoIHBy
b2JhYmlsaXR5LCB0aGVpciBpbnRlcnJ1cHQgcm91dGluZXMgd2lsbCBjb21wbGV0ZSB3aXRoaW4g
WCBhbW91bnQgb2YgY3ljbGVzLg0KDQpGdXJ0aGVyIGludGVycnVwdHMgZGVsaXZlcmVkIHRvIGEg
Z3Vlc3QgYXJlIG5vdCBhIHByb2JsZW0gaW4gdGhpcyBzY2VuYXJpbywgaWYgdGhlIGd1ZXN0IGNh
biBkaXNhYmxlIHRoZW0gdW50aWwgdGhlIGNyaXRpY2FsIElSUSBoYXMgYmVlbiBoYW5kbGVkLg0K
DQpYZW4tcmVsYXRlZCBJUElzLCBob3dldmVyLCBjb3VsZCBwb3RlbnRpYWxseSBjYXVzZSBhIHBy
b2JsZW0gaWYgbm90IG1pdGlnYXRlZC4gIENvbnNpZGVyIGEgZ3Vlc3Qgd2hlcmUgdmNwdSAxIGxv
b3BzIG92ZXIgdGhlIHJlZ2lzdGVyLCB3aGlsZSB2Y3B1IDIgaXMgaGFuZGxpbmcgYSBsYXRlbmN5
LWNyaXRpY2FsIElSUS4gIEEgbmFpdmUgaW1wbGVtZW50YXRpb24gbWlnaHQgc2VuZCBhbiBJUEkg
ZXZlcnkgdGltZSB2Y3B1IDEgZG9lcyBhIHJlYWQsIHNwYW1taW5nIHZjcHUgMiB3aXRoIGRvemVu
cyBvZiBJUElzLiAgVGhlbiBhbiBJUlEgcm91dGluZSB3aGljaCByZWxpYWJseSBmaW5pc2hlcyB3
ZWxsIHdpdGhpbiB0aGUgcmVxdWlyZWQgdGltZSBub3JtYWxseSBzdWRkZW5seSBvdmVycnVucyBh
bmQgY2F1c2VzIGFuIGlzc3VlLg0KDQpJIGRvbuKAmXQga25vdyB3aGF0IG1haW50ZW5hbmNlIElS
UXMgYXJlLCBidXQgaWYgdGhleSBvbmx5IGhhcHBlbiBpbnRlcm1pdHRlbnRseSwgaXTigJlzIHBv
c3NpYmxlIHRoYXQgeW914oCZZCBuZXZlciBnZXQgbW9yZSB0aGFuIGEgc2luZ2xlIG9uZSBpbiBh
IGxhdGVuY3ktY3JpdGljYWwgSVJRIHJvdXRpbmU7IGFuZCBhcyBzdWNoLCB0aGUgdmFyaWF0aWJp
bGl0eSBpbiBleGVjdXRpb24gdGltZSAoaml0dGVyKSB3b3VsZG7igJl0IGJlIGFuIGlzc3VlIGlu
IHByYWN0aWNlLiAgQnV0IGV2ZXJ5IHRpbWUgeW91IGFkZCBhIG5ldyB1bmJsb2NrYWJsZSBJUEks
IHlvdSBpbmNyZWFzZSB0aGlzIGppdHRlcjsgcGFydGljdWxhcmx5IGlmIHRoaXMgdW5ibG9ja2Fi
bGUgSVBJIG1pZ2h0IGJlIHJlcGVhdGVkIGFuIGFyYml0cmFyeSBudW1iZXIgb2YgdGltZXMuDQoN
CihTdGVmYW5vLCBsZXQgbWUga25vdyBpZiBJ4oCZdmUgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcu
KQ0KDQpTbyBzdGVwcGluZyBiYWNrIGEgbW9tZW50LCBoZXJl4oCZcyBhbGwgdGhlIHBvc3NpYmxl
IGlkZWFzIHRoYXQgSSB0aGluayBoYXZlIGJlZW4gZGlzY3Vzc2VkIChvciBhcmUgdGhlcmUgaW1w
bGljaXRseSkgc28gZmFyLg0KDQoxLiBbRGVmYXVsdF0gRG8gbm90aGluZzsgZ3Vlc3RzIHVzaW5n
IHRoaXMgcmVnaXN0ZXIgY29udGludWUgY3Jhc2hpbmcNCg0KMi4gTWFrZSB0aGUgST9BQ1RJVkVS
IHJlZ2lzdGVycyBSWldJLg0KDQozLiBNYWtlIEk/QUNUSVZFUiByZXR1cm4gdGhlIG1vc3QgcmVj
ZW50IGtub3duIHZhbHVlOyBpLmUuIEtWTeKAmXMgY3VycmVudCBiZWhhdmlvciAoYXMgZmFyIGFz
IHdlIHVuZGVyc3RhbmQgaXQpDQoNCjQuIFVzZSBhIHNpbXBsZSBJUEkgd2l0aCBkb19ub29wIHRv
IHVwZGF0ZSBJP0FDVElWRVINCg0KNGEuICBVc2UgYW4gSVBJLCBidXQgY29tZSB1cCB3aXRoIGNs
ZXZlciB0cmlja3MgdG8gYXZvaWQgaW50ZXJydXB0aW5nIGd1ZXN0cyBoYW5kbGluZyBJUlFzLg0K
DQo1LiBUcmFwIHRvIFhlbiBvbiBndWVzdCBFT0ksIHNvIHRoYXQgd2Uga25vdyB3aGVuIHRoZQ0K
DQpUaGlzIGlzIHBvc3NpYmxlIHRvIGRvIG9uIGEgcGVyIGludGVycnVwdCBiYXNpcyBvciB3aGVu
IGFsbCBpbnRlcnJ1cHRzIGluIExSIHJlZ2lzdGVycyBoYXZlIGFsbCBiZWVuIGhhbmRsZWQgKG1h
aW50ZW5hbmNlIGludGVycnVwdCB3aGVuIHRoZXJlIGlzIG5vdGhpbmcgbGVmdCB0byBoYW5kbGUg
aW4gTFIgcmVnaXN0ZXJzLCB1c2VkIHRvIGZpcmUgb3RoZXIgaW50ZXJydXB0cyBpZiB3ZSBoYXZl
IG1vcmUgcGVuZGluZyBpbnRlcnJ1cHRzIHRoZW4gbnVtYmVyIG9mIExSIHJlZ2lzdGVycykuDQoN
Ck1heWJlIGEgc29sdXRpb24gbWFraW5nIHN1cmUgd2UgZ2V0IGEgbWFpbnRlbmFuY2UgaW50ZXJy
dXB0cyBvbmNlIGFsbCBpbnRlcnJ1cHRzIGluIExSIHJlZ2lzdGVycyBoYXZlIGJlZW4gaGFuZGxl
ZCBjb3VsZCBiZSBhIGdvb2QgbWl0aWdhdGlvbiA/DQoNClRoaXMgY291bGQgYWxsb3cgdG8gbm90
IHN5bmMgb3RoZXIgY29yZXMgYnV0IHdvdWxkIG1ha2Ugc3VyZSB0aGUgdGltZSB1bnRpbCB3ZSB3
aWxsIGNsZWFudXAgYWN0aXZlIGludGVycnVwdHMgaXMgbGltaXRlZCBzbyB0aGUgcG9sbGVyIGNv
dWxkIGJlIHN1cmUgdG8gaGF2ZSBhdCBzb21lIGFjY2VwdGFibGUgcG9pbnQgaW4gdGltZSB0aGUg
aW5mb3JtYXRpb24uDQoNCg0KNi4gU29tZSBjbGV2ZXIgcGFyYXZpcnR1YWxpemVkIG9wdGlvbg0K
DQpPYnZpb3VzbHkgbm9ib2R5IHdhbnRzICMxLCBhbmQgIzMgaXMgY2xlYXJseSBub3QgcmVhbGx5
IGFuIG9wdGlvbiBub3cgZWl0aGVyLg0KDQojMiBpcyBub3QgZ3JlYXQsIGJ1dCBpdOKAmXMgc2lt
cGxlIGFuZCBxdWljayB0byBpbXBsZW1lbnQgZm9yIG5vdy4gIEp1bGllbiwgSeKAmW0gbm90IHN1
cmUgeW91ciBwb3NpdGlvbiBvbiB0aGlzIG9uZTogWW91IHJlamVjdGVkIHRoZSBpZGVhIGJhY2sg
aW4gdjEgb2YgdGhpcyBwYXRjaCBzZXJpZXMsIGJ1dCBzZWVtZWQgdG8gcmVmZXIgdG8gaXQgYWdh
aW4gZWFybGllciBpbiB0aGlzIHRocmVhZC4NCg0KIzQgaXMgcmVsYXRpdmVseSBxdWljayB0byBp
bXBsZW1lbnQgYSDigJxkdW1i4oCdIHZlcnNpb24sIGJ1dCBzdWNoIGEg4oCcZHVtYuKAnSB2ZXJz
aW9uIGhhcyBhIGhpZ2ggcmlzayBvZiBjYXVzaW5nIHVuYWNjZXB0YWJsZSBqaXR0ZXIgKG9yIGF0
IGxlYXN0LCBzbyBTdGVmYW5vIGJlbGlldmVzKS4NCg0KIzRhIG9yICM2IGFyZSBmdXJ0aGVyIHBv
dGVudGlhbCBsaW5lcyB0byBleHBsb3JlLCBidXQgd291bGQgcmVxdWlyZSBhIGxvdCBvZiBhZGRp
dGlvbmFsIGRlc2lnbiB0byBnZXQgd29ya2luZyByaWdodC4NCg0KSSB0aGluayBpZiBJIHVuZGVy
c3RhbmQgU3RlZmFub+KAmXMgUG9WLCB0aGVuICM1IHdvdWxkIGFjdHVhbGx5IGJlIGFjY2VwdGFi
bGUg4oCUIHRoZSBvdmVyYWxsIGFtb3VudCBvZiB0aW1lIHNwZW50IGluIHRoZSBoeXBlcnZpc29y
IHdvdWxkIHByb2JhYmx5IGJlIGdyZWF0ZXIsIGJ1dCBpdCB3b3VsZCBiZSBib3VuZGVkIGFuZCBw
cmVkaWN0YWJsZTogb25jZSBzb21lb25lIGdvdCB0aGVpciBJUlEgaGFuZGxlciB3b3JraW5nIHJl
bGlhYmx5LCBpdCB3b3VsZCBsaWtlbHkgY29udGludWUgdG8gd29yay4NCg0KSXQgc291bmRzIGxp
a2UgIzUgbWlnaHQgYmUgcHJldHR5IHF1aWNrIHRvIGltcGxlbWVudDsgYW5kIHRoZW4gYXQgc29t
ZSBwb2ludCBpbiB0aGUgZnV0dXJlIGlmIHNvbWVvbmUgd2FudHMgdG8gaW1wcm92ZSBwZXJmb3Jt
YW5jZSwgdGhleSBjYW4gd29yayBvbiA0YSBvciA2Lg0KDQpJIGFncmVlIHRoaXMgY291bGQgYmUg
YSBnb29kIG1pdGlnYXRpb24uDQoNCkJlcnRyYW5kDQoNCg==

--_000_C92DBD17A2FF48CCAE75228BF51F41C2armcom_
Content-Type: text/html; charset="utf-8"
Content-ID: <2B1082411A78124897887E561E2947D6@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz
PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u
IDcgQXByIDIwMjAsIGF0IDE3OjE2LCBHZW9yZ2UgRHVubGFwICZsdDs8YSBocmVmPSJtYWlsdG86
R2VvcmdlLkR1bmxhcEBjaXRyaXguY29tIiBjbGFzcz0iIj5HZW9yZ2UuRHVubGFwQGNpdHJpeC5j
b208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3
bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw
KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu
b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu
b25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsi
IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg
dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg
d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0i
Ij4NCk9uIEFwciA2LCAyMDIwLCBhdCA3OjQ3IFBNLCBKdWxpZW4gR3JhbGwgJmx0OzxhIGhyZWY9
Im1haWx0bzpqdWxpZW5AeGVuLm9yZyIgY2xhc3M9IiI+anVsaWVuQHhlbi5vcmc8L2E+Jmd0OyB3
cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAwNi8wNC8yMDIwIDE4OjU4LCBH
ZW9yZ2UgRHVubGFwIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gQXByIDMsIDIw
MjAsIGF0IDk6MjcgUE0sIEp1bGllbiBHcmFsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1bGllbi5n
cmFsbC5vc3NAZ21haWwuY29tIiBjbGFzcz0iIj5qdWxpZW4uZ3JhbGwub3NzQGdtYWlsLmNvbTwv
YT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIEZyaSwgMyBBcHIg
MjAyMCBhdCAyMDo0MSwgU3RlZmFubyBTdGFiZWxsaW5pICZsdDs8YSBocmVmPSJtYWlsdG86c3N0
YWJlbGxpbmlAa2VybmVsLm9yZyIgY2xhc3M9IiI+c3N0YWJlbGxpbmlAa2VybmVsLm9yZzwvYT4m
Z3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi
PjxiciBjbGFzcz0iIj4NCk9uIFRodSwgMiBBcHIgMjAyMCwgSnVsaWVuIEdyYWxsIHdyb3RlOjxi
ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkFzIHdlIGRpc2N1
c3NlZCBvbiBUdWVzZGF5LCB0aGUgY29zdCBmb3Igb3RoZXIgdkNQVXMgaXMgb25seSBnb2luZyB0
byBiZSBhPGJyIGNsYXNzPSIiPg0KdHJhcCB0byB0aGUgaHlwZXJ2aXNvciBhbmQgdGhlbiBiYWNr
IGFnYWluLiBUaGUgY29zdCBpcyBsaWtlbHkgc21hbGxlciB0aGFuPGJyIGNsYXNzPSIiPg0KcmVj
ZWl2aW5nIGFuZCBmb3J3YXJkaW5nIGFuIGludGVycnVwdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQpZb3UgYWN0dWFsbHkgYWdyZWVkIG9uIHRoaXMgYW5hbHlzaXMuIFNvIGNhbiB5b3Ug
ZW5saWdodGVuIG1lIGFzIHRvIHdoeTxiciBjbGFzcz0iIj4NCnJlY2VpdmluZyBhbiBpbnRlcnJ1
cHQgaXMgYSBub3QgcHJvYmxlbSBmb3IgbGF0ZW5jeSBidXQgdGhpcyBpcz88YnIgY2xhc3M9IiI+
DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpNeSBhbnN3ZXIgd2FzIHRoYXQgdGhlIGRp
ZmZlcmVuY2UgaXMgdGhhdCBhbiBvcGVyYXRpbmcgc3lzdGVtIGNhbjxiciBjbGFzcz0iIj4NCmRp
c2FibGUgaW50ZXJydXB0cywgYnV0IGl0IGNhbm5vdCBkaXNhYmxlIHJlY2VpdmluZyB0aGlzIHNw
ZWNpYWwgSVBJLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkFu
IE9TIGNhbiAqb25seSogZGlzYWJsZSBpdHMgb3duIGludGVycnVwdHMsIHlldCBpbnRlcnJ1cHRz
IHdpbGwgc3RpbGw8YnIgY2xhc3M9IiI+DQpiZSByZWNlaXZlZCBieSBYZW4gZXZlbiBpZiB0aGUg
aW50ZXJydXB0cyBhcmUgbWFza2VkIGF0IHRoZSBwcm9jZXNzb3I8YnIgY2xhc3M9IiI+DQooZS5n
IGxvY2FsX2lycV9kaXNhYmxlKCkpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCllvdSB3
b3VsZCBuZWVkIHRvIGRpc2FibGUgaW50ZXJydXB0cyBvbmUgYnkgb25lIGFzIHRoZSBHSUMgbGV2
ZWwgKHVzZTxiciBjbGFzcz0iIj4NCklDRU5BQkxFUikgaW4gb3JkZXIgdG8gbm90IHJlY2VpdmUg
YW55IGludGVycnVwdHMuIFlldCwgWGVuIG1heSBzdGlsbDxiciBjbGFzcz0iIj4NCnJlY2VpdmUg
aW50ZXJydXB0cyBmb3Igb3BlcmF0aW9uYWwgcHVycG9zZXMgKGUuZyBzZXJpYWwsIGNvbnNvbGUs
PGJyIGNsYXNzPSIiPg0KbWFpbnRhaW5hbmNlIElSUS4uLikuIFNvIHRyYXAgd2lsbCBoYXBwZW4u
PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KSSB0aGluayBTdGVmYW5v4oCZcyBhc3NlcnRp
b24gaXMgdGhhdCB0aGUgdXNlcnMgaGUgaGFzIGluIG1pbmQgd2lsbCBiZSBjb25maWd1cmluZyB0
aGUgc3lzdGVtIHN1Y2ggdGhhdCBSVCB3b3JrbG9hZHMgZ2V0IGEgbWluaW11bSBudW1iZXIgb2Yg
aHlwZXJ2aXNvci1yZWxhdGVkIGludGVycnVwdHMgcG9zc2libGUuICZuYnNwO09uIGEgNC1jb3Jl
IHN5c3RlbSwgeW91IGNvdWxkICZuYnNwO2hhdmUgbm9uLVJUIHdvcmtsb2FkcyBydW5uaW5nIG9u
IGNvcmVzIDAtMSwgYW5kDQogUlQgd29ya2xvYWRzIHJ1bm5pbmcgd2l0aCB0aGUgTlVMTCBzY2hl
ZHVsZXIgb24gY29yZXMgMi0zLiAmbmJzcDtJbiBzdWNoIGEgc3lzdGVtLCB5b3XigJlkIG9idmlv
dXNseSBhcnJhbmdlIHRoYXQgc2VyaWFsIGFuZCBtYWludGVuYW5jZSBJUlFzIGFyZSBkZWxpdmVy
ZWQgdG8gY29yZXMgMC0xLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCldlbGwgbWFpbnRl
bmFuY2UgSVJRcyBhcmUgcGVyIHBDUFUgc28geW91IGNhbid0IHJvdXRlIHRvIGFub3RoZXIgb25l
Li4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQnV0LCBJIHRoaW5rIHlvdSBtaXNzZWQg
bXkgcG9pbnQgdGhhdCBsb2NhbF9pcnFfZGlzYWJsZSgpIGZyb20gdGhlIGd1ZXN0IHdpbGwgbm90
IHByZXZlbnQgdGhlIGh5cGVydmlzb3IgdG8gcmVjZWl2ZSBpbnRlcnJ1cHRzICpldmVuKiB0aGUg
b25lIHJvdXRlZCB0byB0aGUgdkNQVSBpdHNlbGYuIFRoZXkgd2lsbCBqdXN0IG5vdCBiZSBkZWxp
dmVyZWQgdG8gdGhlIGd1ZXN0IGNvbnRleHQgdW50aWwgbG9jYWxfaXJxX2VuYWJsZSgpIGlzIGNh
bGxlZC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt
ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy
Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv
cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj
b3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg
Y2xhc3M9IiI+TXkNCiB1bmRlcnN0YW5kaW5nLCBmcm9tIFN0ZWZhbm8gd2FzIHRoYXQgd2hhdCBo
aXMgY3VzdG9tZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQgaXMgdGhlIHRpbWUgYmV0d2VlbiB0aGUg
dGltZSBhIHBoeXNpY2FsIElSUSBpcyBkZWxpdmVyZWQgdG8gdGhlIGd1ZXN0IGFuZCB0aGUgdGlt
ZSB0aGUgZ3Vlc3QgT1MgY2FuIHJlc3BvbmQgYXBwcm9wcmlhdGVseS4gJm5ic3A7VGhlIGtleSB0
aGluZyBoZXJlIGlzbuKAmXQgbmVjZXNzYXJpbHkgc3BlZWQsIGJ1dCBwcmVkaWN0YWJpbGl0eQ0K
IOKAlCBzeXN0ZW0gZGVzaWduZXJzIG5lZWQgdG8ga25vdyB0aGF0LCB3aXRoIGEgaGlnaCBwcm9i
YWJpbGl0eSwgdGhlaXIgaW50ZXJydXB0IHJvdXRpbmVzIHdpbGwgY29tcGxldGUgd2l0aGluIFgg
YW1vdW50IG9mIGN5Y2xlcy48L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs
IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg
bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246
IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt
YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl
ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l
OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z
cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0
LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7
IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBm
bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5GdXJ0aGVy
DQogaW50ZXJydXB0cyBkZWxpdmVyZWQgdG8gYSBndWVzdCBhcmUgbm90IGEgcHJvYmxlbSBpbiB0
aGlzIHNjZW5hcmlvLCBpZiB0aGUgZ3Vlc3QgY2FuIGRpc2FibGUgdGhlbSB1bnRpbCB0aGUgY3Jp
dGljYWwgSVJRIGhhcyBiZWVuIGhhbmRsZWQuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6
IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm
b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0
OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0
LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg
d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k
ZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io
MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z
dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y
bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh
dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg
MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs
OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh
Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv
bjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9
IiI+WGVuLXJlbGF0ZWQNCiBJUElzLCBob3dldmVyLCBjb3VsZCBwb3RlbnRpYWxseSBjYXVzZSBh
IHByb2JsZW0gaWYgbm90IG1pdGlnYXRlZC4gJm5ic3A7Q29uc2lkZXIgYSBndWVzdCB3aGVyZSB2
Y3B1IDEgbG9vcHMgb3ZlciB0aGUgcmVnaXN0ZXIsIHdoaWxlIHZjcHUgMiBpcyBoYW5kbGluZyBh
IGxhdGVuY3ktY3JpdGljYWwgSVJRLiAmbmJzcDtBIG5haXZlIGltcGxlbWVudGF0aW9uIG1pZ2h0
IHNlbmQgYW4gSVBJIGV2ZXJ5IHRpbWUgdmNwdSAxIGRvZXMgYSByZWFkLCBzcGFtbWluZyB2Y3B1
DQogMiB3aXRoIGRvemVucyBvZiBJUElzLiAmbmJzcDtUaGVuIGFuIElSUSByb3V0aW5lIHdoaWNo
IHJlbGlhYmx5IGZpbmlzaGVzIHdlbGwgd2l0aGluIHRoZSByZXF1aXJlZCB0aW1lIG5vcm1hbGx5
IHN1ZGRlbmx5IG92ZXJydW5zIGFuZCBjYXVzZXMgYW4gaXNzdWUuPC9zcGFuPjxiciBzdHlsZT0i
Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z
aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246
IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh
Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6
IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0
LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog
MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250
LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy
dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu
b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7
IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNv
bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg
dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt
YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl
eHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0
YW50OyIgY2xhc3M9IiI+SQ0KIGRvbuKAmXQga25vdyB3aGF0IG1haW50ZW5hbmNlIElSUXMgYXJl
LCBidXQgaWYgdGhleSBvbmx5IGhhcHBlbiBpbnRlcm1pdHRlbnRseSwgaXTigJlzIHBvc3NpYmxl
IHRoYXQgeW914oCZZCBuZXZlciBnZXQgbW9yZSB0aGFuIGEgc2luZ2xlIG9uZSBpbiBhIGxhdGVu
Y3ktY3JpdGljYWwgSVJRIHJvdXRpbmU7IGFuZCBhcyBzdWNoLCB0aGUgdmFyaWF0aWJpbGl0eSBp
biBleGVjdXRpb24gdGltZSAoaml0dGVyKSB3b3VsZG7igJl0IGJlIGFuIGlzc3VlIGluIHByYWN0
aWNlLg0KICZuYnNwO0J1dCBldmVyeSB0aW1lIHlvdSBhZGQgYSBuZXcgdW5ibG9ja2FibGUgSVBJ
LCB5b3UgaW5jcmVhc2UgdGhpcyBqaXR0ZXI7IHBhcnRpY3VsYXJseSBpZiB0aGlzIHVuYmxvY2th
YmxlIElQSSBtaWdodCBiZSByZXBlYXRlZCBhbiBhcmJpdHJhcnkgbnVtYmVyIG9mIHRpbWVzLjwv
c3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06
IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K
PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFu
IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh
OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5
OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPihTdGVmYW5vLA0KIGxldCBtZSBrbm93IGlm
IEnigJl2ZSBtaXN1bmRlcnN0b29kIHNvbWV0aGluZy4pPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQt
Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx
MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt
d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg
dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt
ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy
Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv
cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj
b3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg
Y2xhc3M9IiI+U28NCiBzdGVwcGluZyBiYWNrIGEgbW9tZW50LCBoZXJl4oCZcyBhbGwgdGhlIHBv
c3NpYmxlIGlkZWFzIHRoYXQgSSB0aGluayBoYXZlIGJlZW4gZGlzY3Vzc2VkIChvciBhcmUgdGhl
cmUgaW1wbGljaXRseSkgc28gZmFyLjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io
MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z
dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y
bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh
dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs
IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg
bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246
IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp
OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v
cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7
IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6
IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v
bmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPjEu
DQogW0RlZmF1bHRdIERvIG5vdGhpbmc7IGd1ZXN0cyB1c2luZyB0aGlzIHJlZ2lzdGVyIGNvbnRp
bnVlIGNyYXNoaW5nPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt
YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl
ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l
OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm
b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh
Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10
cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNs
YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6
IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Mi4NCiBNYWtlIHRo
ZSBJP0FDVElWRVIgcmVnaXN0ZXJzIFJaV0kuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6
IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm
b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0
OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0
LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg
d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k
ZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io
MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z
dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y
bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh
dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg
MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs
OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh
Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv
bjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9
IiI+My4NCiBNYWtlIEk/QUNUSVZFUiByZXR1cm4gdGhlIG1vc3QgcmVjZW50IGtub3duIHZhbHVl
OyBpLmUuIEtWTeKAmXMgY3VycmVudCBiZWhhdmlvciAoYXMgZmFyIGFzIHdlIHVuZGVyc3RhbmQg
aXQpPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p
bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt
dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n
OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9
IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06
IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K
PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2
ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt
Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs
OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v
bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRp
c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+NC4NCiBVc2UgYSBzaW1wbGUgSVBJ
IHdpdGggZG9fbm9vcCB0byB1cGRhdGUgST9BQ1RJVkVSPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQt
Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx
MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt
d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg
dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt
ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy
Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv
cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj
b3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg
Y2xhc3M9IiI+NGEuDQogJm5ic3A7VXNlIGFuIElQSSwgYnV0IGNvbWUgdXAgd2l0aCBjbGV2ZXIg
dHJpY2tzIHRvIGF2b2lkIGludGVycnVwdGluZyBndWVzdHMgaGFuZGxpbmcgSVJRcy48L3NwYW4+
PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBz
dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg
Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu
b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt
YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp
dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut
d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls
ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u
dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt
YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp
Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt
c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s
aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj41Lg0KIFRyYXAgdG8gWGVuIG9uIGd1ZXN0IEVPSSwg
c28gdGhhdCB3ZSBrbm93IHdoZW4gdGhlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg
MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog
bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs
ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw
eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog
bm9uZTsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0i
Ij4NCjwvZGl2Pg0KPGRpdj5UaGlzIGlzIHBvc3NpYmxlIHRvIGRvIG9uIGEgcGVyIGludGVycnVw
dCBiYXNpcyBvciB3aGVuIGFsbCBpbnRlcnJ1cHRzIGluIExSIHJlZ2lzdGVycyBoYXZlIGFsbCBi
ZWVuIGhhbmRsZWQgKG1haW50ZW5hbmNlIGludGVycnVwdCB3aGVuIHRoZXJlIGlzIG5vdGhpbmcg
bGVmdCB0byBoYW5kbGUgaW4gTFIgcmVnaXN0ZXJzLCB1c2VkIHRvIGZpcmUgb3RoZXIgaW50ZXJy
dXB0cyBpZiB3ZSBoYXZlIG1vcmUgcGVuZGluZyBpbnRlcnJ1cHRzIHRoZW4NCiBudW1iZXIgb2Yg
TFIgcmVnaXN0ZXJzKS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pk1h
eWJlIGEgc29sdXRpb24gbWFraW5nIHN1cmUgd2UgZ2V0IGEgbWFpbnRlbmFuY2UgaW50ZXJydXB0
cyBvbmNlIGFsbCBpbnRlcnJ1cHRzIGluIExSIHJlZ2lzdGVycyBoYXZlIGJlZW4gaGFuZGxlZCBj
b3VsZCBiZSBhIGdvb2QgbWl0aWdhdGlvbiA/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KPGRpdj5UaGlzIGNvdWxkIGFsbG93IHRvIG5vdCBzeW5jIG90aGVyIGNvcmVzIGJ1dCB3
b3VsZCBtYWtlIHN1cmUgdGhlIHRpbWUgdW50aWwgd2Ugd2lsbCBjbGVhbnVwIGFjdGl2ZSBpbnRl
cnJ1cHRzIGlzIGxpbWl0ZWQgc28gdGhlIHBvbGxlciBjb3VsZCBiZSBzdXJlIHRvIGhhdmUgYXQg
c29tZSBhY2NlcHRhYmxlIHBvaW50IGluIHRpbWUgdGhlIGluZm9ybWF0aW9uLjwvZGl2Pg0KPGJy
IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz
PSIiPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl
bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8
c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl
dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j
YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlz
cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj42Lg0KIFNvbWUgY2xldmVyIHBhcmF2
aXJ0dWFsaXplZCBvcHRpb248L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs
IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg
bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246
IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt
YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl
ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l
OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z
cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0
LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7
IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBm
bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5PYnZpb3Vz
bHkNCiBub2JvZHkgd2FudHMgIzEsIGFuZCAjMyBpcyBjbGVhcmx5IG5vdCByZWFsbHkgYW4gb3B0
aW9uIG5vdyBlaXRoZXIuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw
KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu
b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu
b25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsi
IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm
b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh
Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10
cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxv
YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+IzINCiBpcyBu
b3QgZ3JlYXQsIGJ1dCBpdOKAmXMgc2ltcGxlIGFuZCBxdWljayB0byBpbXBsZW1lbnQgZm9yIG5v
dy4gJm5ic3A7SnVsaWVuLCBJ4oCZbSBub3Qgc3VyZSB5b3VyIHBvc2l0aW9uIG9uIHRoaXMgb25l
OiBZb3UgcmVqZWN0ZWQgdGhlIGlkZWEgYmFjayBpbiB2MSBvZiB0aGlzIHBhdGNoIHNlcmllcywg
YnV0IHNlZW1lZCB0byByZWZlciB0byBpdCBhZ2FpbiBlYXJsaWVyIGluIHRoaXMgdGhyZWFkLjwv
c3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06
IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K
PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFu
IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh
OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5
OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiM0DQogaXMgcmVsYXRpdmVseSBxdWljayB0
byBpbXBsZW1lbnQgYSDigJxkdW1i4oCdIHZlcnNpb24sIGJ1dCBzdWNoIGEg4oCcZHVtYuKAnSB2
ZXJzaW9uIGhhcyBhIGhpZ2ggcmlzayBvZiBjYXVzaW5nIHVuYWNjZXB0YWJsZSBqaXR0ZXIgKG9y
IGF0IGxlYXN0LCBzbyBTdGVmYW5vIGJlbGlldmVzKS48L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1j
b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy
cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13
ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7
IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y
bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0
ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6
IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm
b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0
OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0
LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg
d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k
ZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn
YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250
LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu
b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y
ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv
cmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj
bGFzcz0iIj4jNGENCiBvciAjNiBhcmUgZnVydGhlciBwb3RlbnRpYWwgbGluZXMgdG8gZXhwbG9y
ZSwgYnV0IHdvdWxkIHJlcXVpcmUgYSBsb3Qgb2YgYWRkaXRpb25hbCBkZXNpZ24gdG8gZ2V0IHdv
cmtpbmcgcmlnaHQuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt
YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl
ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l
OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm
b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh
Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10
cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNs
YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6
IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SQ0KIHRoaW5rIGlm
IEkgdW5kZXJzdGFuZCBTdGVmYW5v4oCZcyBQb1YsIHRoZW4gIzUgd291bGQgYWN0dWFsbHkgYmUg
YWNjZXB0YWJsZSDigJQgdGhlIG92ZXJhbGwgYW1vdW50IG9mIHRpbWUgc3BlbnQgaW4gdGhlIGh5
cGVydmlzb3Igd291bGQgcHJvYmFibHkgYmUgZ3JlYXRlciwgYnV0IGl0IHdvdWxkIGJlIGJvdW5k
ZWQgYW5kIHByZWRpY3RhYmxlOiBvbmNlIHNvbWVvbmUgZ290IHRoZWlyIElSUSBoYW5kbGVyIHdv
cmtpbmcgcmVsaWFibHksIGl0IHdvdWxkDQogbGlrZWx5IGNvbnRpbnVlIHRvIHdvcmsuPC9zcGFu
PjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl
dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j
YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIg
c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7
IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog
bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0
LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5
bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv
bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu
bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SXQNCiBzb3VuZHMgbGlrZSAjNSBtaWdodCBiZSBw
cmV0dHkgcXVpY2sgdG8gaW1wbGVtZW50OyBhbmQgdGhlbiBhdCBzb21lIHBvaW50IGluIHRoZSBm
dXR1cmUgaWYgc29tZW9uZSB3YW50cyB0byBpbXByb3ZlIHBlcmZvcm1hbmNlLCB0aGV5IGNhbiB3
b3JrIG9uIDRhIG9yIDYuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw
KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu
b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu
b25lOyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2PkkgYWdyZWUgdGhpcyBjb3VsZCBiZSBhIGdvb2QgbWl0aWdhdGlvbi48
L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkJlcnRyYW5kPC9kaXY+DQo8
L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_C92DBD17A2FF48CCAE75228BF51F41C2armcom_--


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 16:50:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 16:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLrQq-0005by-WA; Tue, 07 Apr 2020 16:50:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=SCBO=5X=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLrQq-0005bt-62
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 16:50:36 +0000
X-Inumbo-ID: e64bf416-78ef-11ea-8106-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e64bf416-78ef-11ea-8106-12813bfff9fa;
 Tue, 07 Apr 2020 16:50:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=jTtR1Tdu/+D8Lt6sLyo0KquOKG38GAh856s/Ck7xiII=; b=w484DSlpuppmbvykPQP9b+X/6y
 wwoRRXoShrmEYgTierX5+6CHw3q65BwhJAzU9oEmJS0dwWXbQYdFS+YcEFVDQ1clZvna7RZmLCi8/
 ta4AgLRzA0uygXNX9Rv3H/+ps6ZpHQNDh3HnEbGPaxP3Ks5Kc8p/YlxYrmvsBhIJuYho=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLrQg-0007nN-Vo; Tue, 07 Apr 2020 16:50:26 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLrQg-0004X7-Jh; Tue, 07 Apr 2020 16:50:26 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: George Dunlap <George.Dunlap@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
Date: Tue, 7 Apr 2020 17:50:24 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 07/04/2020 17:16, George Dunlap wrote:
> 
> 
>> On Apr 6, 2020, at 7:47 PM, Julien Grall <julien@xen.org> wrote:
>>
>> On 06/04/2020 18:58, George Dunlap wrote:
>>>> On Apr 3, 2020, at 9:27 PM, Julien Grall <julien.grall.oss@gmail.com> wrote:
>>>>
>>>> On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>>>
>>>>> On Thu, 2 Apr 2020, Julien Grall wrote:
>>>>>> As we discussed on Tuesday, the cost for other vCPUs is only going to be a
>>>>>> trap to the hypervisor and then back again. The cost is likely smaller than
>>>>>> receiving and forwarding an interrupt.
>>>>>>
>>>>>> You actually agreed on this analysis. So can you enlighten me as to why
>>>>>> receiving an interrupt is a not problem for latency but this is?
>>>>>
>>>>> My answer was that the difference is that an operating system can
>>>>> disable interrupts, but it cannot disable receiving this special IPI.
>>>>
>>>> An OS can *only* disable its own interrupts, yet interrupts will still
>>>> be received by Xen even if the interrupts are masked at the processor
>>>> (e.g local_irq_disable()).
>>>>
>>>> You would need to disable interrupts one by one as the GIC level (use
>>>> ICENABLER) in order to not receive any interrupts. Yet, Xen may still
>>>> receive interrupts for operational purposes (e.g serial, console,
>>>> maintainance IRQ...). So trap will happen.
>>> I think Stefano’s assertion is that the users he has in mind will be configuring the system such that RT workloads get a minimum number of hypervisor-related interrupts possible.  On a 4-core system, you could  have non-RT workloads running on cores 0-1, and RT workloads running with the NULL scheduler on cores 2-3.  In such a system, you’d obviously arrange that serial and maintenance IRQs are delivered to cores 0-1.
>> Well maintenance IRQs are per pCPU so you can't route to another one...
>>
>> But, I think you missed my point that local_irq_disable() from the guest will not prevent the hypervisor to receive interrupts *even* the one routed to the vCPU itself. They will just not be delivered to the guest context until local_irq_enable() is called.
> 
> My understanding, from Stefano was that what his customers are concerned about is the time between the time a physical IRQ is delivered to the guest and the time the guest OS can respond appropriately.  The key thing here isn’t necessarily speed, but predictability — system designers need to know that, with a high probability, their interrupt routines will complete within X amount of cycles.
> 
> Further interrupts delivered to a guest are not a problem in this scenario, if the guest can disable them until the critical IRQ has been handled.

You keep saying a guest can disable interrupts, but it can't do it via 
local_irq_disable(). So what method are you thinking? Disabling at the 
GIC level? That is involving traps and most likely not going to help 
with predictability...

> 
> Xen-related IPIs, however, could potentially cause a problem if not mitigated.  Consider a guest where vcpu 1 loops over the register, while vcpu 2 is handling a latency-critical IRQ.  A naive implementation might send an IPI every time vcpu 1 does a read, spamming vcpu 2 with dozens of IPIs.  Then an IRQ routine which reliably finishes well within the required time normally suddenly overruns and causes an issue.

I never suggested the naive implementation would be perfect. That's why 
I said it can be optimized...

> 
> I don’t know what maintenance IRQs are, but if they only happen intermittently, it’s possible that you’d never get more than a single one in a latency-critical IRQ routine; and as such, the variatibility in execution time (jitter) wouldn’t be an issue in practice.  But every time you add a new unblockable IPI, you increase this jitter; particularly if this unblockable IPI might be repeated an arbitrary number of times.
> 
> (Stefano, let me know if I’ve misunderstood something.)
> 
> So stepping back a moment, here’s all the possible ideas that I think have been discussed (or are there implicitly) so far.
> 
> 1. [Default] Do nothing; guests using this register continue crashing
> 
> 2. Make the I?ACTIVER registers RZWI.
> 
> 3. Make I?ACTIVER return the most recent known value; i.e. KVM’s current behavior (as far as we understand it)
> 
> 4. Use a simple IPI with do_noop to update I?ACTIVER
> 
> 4a.  Use an IPI, but come up with clever tricks to avoid interrupting guests handling IRQs.
> 
> 5. Trap to Xen on guest EOI, so that we know when the
> 
> 6. Some clever paravirtualized option

7. Use an IPI if we are confident the interrupts may be active.

> 
> Obviously nobody wants #1, and #3 is clearly not really an option now either.
> 
> #2 is not great, but it’s simple and quick to implement for now.  Julien, I’m not sure your position on this one: You rejected the idea back in v1 of this patch series, but seemed to refer to it again earlier in this thread.
> 
> #4 is relatively quick to implement a “dumb” version, but such a “dumb” version has a high risk of causing unacceptable jitter (or at least, so Stefano believes).
> 
> #4a or #6 are further potential lines to explore, but would require a lot of additional design to get working right.
> 
> I think if I understand Stefano’s PoV, then #5 would actually be acceptable — the overall amount of time spent in the hypervisor would probably be greater, but it would be bounded and predictable: once someone got their IRQ handler working reliably, it would likely continue to work.
> It sounds like #5 might be pretty quick to implement; and then at some point in the future if someone wants to improve performance, they can work on 4a or 6.
With the existing solution, you may only trap when receiving the next 
interrupts. But with your approach you are now trapping once when 
deactivate and potentially trapping soon after when receiving an 
interrupts. So you increase cost per-interrupts.

While I agree this is going to make Stefano's customers happy, you are 
also going to make unhappy anyone with workload using an high numbers of 
interrupts (e.g media).

Given that none of Stefano's customer are actually using ISACTIVER 
today, it feels to me it is wrong to add pain for everyone else.

It feels to me we want to either implement 4. or 7. and then optimize it 
based on feedback.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 16:52:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 16:52:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLrT2-0005jl-D9; Tue, 07 Apr 2020 16:52:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=SCBO=5X=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLrT1-0005jg-Mt
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 16:52:51 +0000
X-Inumbo-ID: 37cf6d04-78f0-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 37cf6d04-78f0-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 16:52:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ynhspTrE83H9C4Y4unnFhl+Pa/HKUi6A/isy3rJPAJA=; b=UkWdIFD7bufSYi4ky5q9zIXwpC
 LHRHzFzEkWpoEh+QLKkMMyxzIWnDUK1hRdKD2bk7vOqFzabmUDQK99rspfgjj5wXfhIGdXcqoGDvd
 Fv/CqQJCh9bM4x0qC5KTcwXmijEcrmBfj4g0zyTTnOU+wfNYE7SRpHLT8fnppiN3tjWg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLrSw-0007rL-Cb; Tue, 07 Apr 2020 16:52:46 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLrSw-0004bT-5Q; Tue, 07 Apr 2020 16:52:46 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Bertrand Marquis <Bertrand.Marquis@arm.com>,
 George Dunlap <George.Dunlap@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <C92DBD17-A2FF-48CC-AE75-228BF51F41C2@arm.com>
From: Julien Grall <julien@xen.org>
Message-ID: <33b8ee9f-fa24-3b79-7d7b-2b82b3f21a5e@xen.org>
Date: Tue, 7 Apr 2020 17:52:43 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <C92DBD17-A2FF-48CC-AE75-228BF51F41C2@arm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
 nd <nd@arm.com>, xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 07/04/2020 17:25, Bertrand Marquis wrote:
> This is possible to do on a per interrupt basis or when all interrupts 
> in LR registers have all been handled (maintenance interrupt when there 
> is nothing left to handle in LR registers, used to fire other interrupts 
> if we have more pending interrupts then number of LR registers).
> 
> Maybe a solution making sure we get a maintenance interrupts once all 
> interrupts in LR registers have been handled could be a good mitigation ?

The chance of having multiple interrupts inflight is fairly limited. So 
effectively, you will trap for every interrupts.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 16:56:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 16:56:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLrWo-0005sl-UY; Tue, 07 Apr 2020 16:56:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=SCBO=5X=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLrWn-0005sg-N6
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 16:56:45 +0000
X-Inumbo-ID: c3279e58-78f0-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c3279e58-78f0-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 16:56:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=DPJefoKUrnvkPnUtarwCC5UV8bsQZr+MpiHqDI2k2hg=; b=hCraj/nVWgiaOlpSRtnhN7eiqk
 DT30uhU97+M5mrPwVjfwI53qR6edSQ39FIjAnMBCU/t/CYSFt+180DSd/T0Elg5Q2VQU6KrVkl79q
 m2/QKgVlwOwTVOxQCcH/PeQKA+UQ5SRzLIhoghqzmZmS2zDrKBENBFk10FztY8olp99w=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLrWi-0007vE-LF; Tue, 07 Apr 2020 16:56:40 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLrWi-00054v-Dl; Tue, 07 Apr 2020 16:56:40 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
From: Julien Grall <julien@xen.org>
To: George Dunlap <George.Dunlap@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
Message-ID: <50c565ed-801b-76bd-5e53-af92fdd5d116@xen.org>
Date: Tue, 7 Apr 2020 17:56:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 07/04/2020 17:50, Julien Grall wrote:
> 
> 
> On 07/04/2020 17:16, George Dunlap wrote:
>>
>>
>>> On Apr 6, 2020, at 7:47 PM, Julien Grall <julien@xen.org> wrote:
>>>
>>> On 06/04/2020 18:58, George Dunlap wrote:
>>>>> On Apr 3, 2020, at 9:27 PM, Julien Grall 
>>>>> <julien.grall.oss@gmail.com> wrote:
>>>>>
>>>>> On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini 
>>>>> <sstabellini@kernel.org> wrote:
>>>>>>
>>>>>> On Thu, 2 Apr 2020, Julien Grall wrote:
>>>>>>> As we discussed on Tuesday, the cost for other vCPUs is only 
>>>>>>> going to be a
>>>>>>> trap to the hypervisor and then back again. The cost is likely 
>>>>>>> smaller than
>>>>>>> receiving and forwarding an interrupt.
>>>>>>>
>>>>>>> You actually agreed on this analysis. So can you enlighten me as 
>>>>>>> to why
>>>>>>> receiving an interrupt is a not problem for latency but this is?
>>>>>>
>>>>>> My answer was that the difference is that an operating system can
>>>>>> disable interrupts, but it cannot disable receiving this special IPI.
>>>>>
>>>>> An OS can *only* disable its own interrupts, yet interrupts will still
>>>>> be received by Xen even if the interrupts are masked at the processor
>>>>> (e.g local_irq_disable()).
>>>>>
>>>>> You would need to disable interrupts one by one as the GIC level (use
>>>>> ICENABLER) in order to not receive any interrupts. Yet, Xen may still
>>>>> receive interrupts for operational purposes (e.g serial, console,
>>>>> maintainance IRQ...). So trap will happen.
>>>> I think Stefano’s assertion is that the users he has in mind will be 
>>>> configuring the system such that RT workloads get a minimum number 
>>>> of hypervisor-related interrupts possible.  On a 4-core system, you 
>>>> could  have non-RT workloads running on cores 0-1, and RT workloads 
>>>> running with the NULL scheduler on cores 2-3.  In such a system, 
>>>> you’d obviously arrange that serial and maintenance IRQs are 
>>>> delivered to cores 0-1.
>>> Well maintenance IRQs are per pCPU so you can't route to another one...
>>>
>>> But, I think you missed my point that local_irq_disable() from the 
>>> guest will not prevent the hypervisor to receive interrupts *even* 
>>> the one routed to the vCPU itself. They will just not be delivered to 
>>> the guest context until local_irq_enable() is called.
>>
>> My understanding, from Stefano was that what his customers are 
>> concerned about is the time between the time a physical IRQ is 
>> delivered to the guest and the time the guest OS can respond 
>> appropriately.  The key thing here isn’t necessarily speed, but 
>> predictability — system designers need to know that, with a high 
>> probability, their interrupt routines will complete within X amount of 
>> cycles.
>>
>> Further interrupts delivered to a guest are not a problem in this 
>> scenario, if the guest can disable them until the critical IRQ has 
>> been handled.
> 
> You keep saying a guest can disable interrupts, but it can't do it via 
> local_irq_disable(). So what method are you thinking? Disabling at the 
> GIC level? That is involving traps and most likely not going to help 
> with predictability...

Just to clear I meant interrupts to be received by Xen including the one 
routed to that vCPU.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 17:30:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 17:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLs3N-0000ca-NU; Tue, 07 Apr 2020 17:30:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=VNrn=5X=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLs3M-0000cV-OT
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 17:30:24 +0000
X-Inumbo-ID: 72cec7ce-78f5-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 72cec7ce-78f5-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 17:30:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=gA22FJsgVJ1Bk3e7MDGAqArTqLYzy3cINpOZTz7X9+Y=; b=XzB7QQmz9dCqT0+vjCg06q8gC
 Y2jdzi4OPP6KXsFEIvJkmT10L1kHWkKHgIYri2eZMVYWNMHawBNQvFT5FrZGl/xtuqcAHkg1Q8zTx
 L0jO+7jm4hfe3rwLslH/RIhT59exPUIC3tR3sHtv17RzATrX+euT0Eqt1C8oWuXHn/eRk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLs3F-00008K-FV; Tue, 07 Apr 2020 17:30:17 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLs3F-0003OK-2p; Tue, 07 Apr 2020 17:30:17 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLs3F-0006sp-2C; Tue, 07 Apr 2020 17:30:17 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149478-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149478: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore.2:fail:heisenbug
 xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug
 xen-unstable:test-amd64-amd64-dom0pvh-xl-amd:guest-start/debian.repeat:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
X-Osstest-Versions-That: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 07 Apr 2020 17:30:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-dom0pvh-xl-intel 17 guest-saverestore.2   fail pass in 149451
 test-amd64-amd64-examine      4 memdisk-try-append         fail pass in 149451
 test-amd64-amd64-dom0pvh-xl-amd 20 guest-start/debian.repeat fail pass in 149451

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     16 guest-localmigrate           fail  like 149451
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149451
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149451
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149451
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149451
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149451
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149451
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149451
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149451
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149451
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
baseline version:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd

Last test of basis   149478  2020-04-07 01:51:22 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 17:38:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 17:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLsBP-0000rE-Ou; Tue, 07 Apr 2020 17:38:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=SCBO=5X=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLsBO-0000r9-H6
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 17:38:42 +0000
X-Inumbo-ID: 9f5e1a6e-78f6-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9f5e1a6e-78f6-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 17:38:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mTUhw75EAcIsBdxvOhBuDMN2uHNORvVO9OdgrVxBkgI=; b=Gi9kP/nXnKoRQLfOY5k33XING8
 j7Kx8WyZqCsmNzdsoAIFN/IEQ/s14uQK+6oOz8guPSiqK+pilHZHy3Hpp3pNn/smrSHO7o5GLsqDk
 0c0U+vpzfaaBYyXHlfTmq4nHboqnZ6uo8buX8XXn4NMLCRQJuc293rKcEa1FSq91WJwM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLsBK-0000JQ-8f; Tue, 07 Apr 2020 17:38:38 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLsBJ-00087A-Ve; Tue, 07 Apr 2020 17:38:38 +0000
Subject: Re: [PATCH] MAINTAINERS: Remove all S: entries
To: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org
References: <20200407161519.16493-1-ian.jackson@eu.citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <e768f715-7d39-539d-f44f-863f9bff0576@xen.org>
Date: Tue, 7 Apr 2020 18:38:36 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200407161519.16493-1-ian.jackson@eu.citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 07/04/2020 17:15, Ian Jackson wrote:
> Feature support status is tracked in SUPPORT.md nowadays.

I don't think we track everything the same way. At least...

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>   MAINTAINERS | 60 ------------------------------------------------------------
>   1 file changed, 60 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8a4c869704..e784169d1b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -69,16 +69,6 @@ Descriptions of section entries:
>   	L: Mailing list that is relevant to this area
>   	W: Web-page with status/info
>   	T: SCM tree type and location.  Type is one of: git, hg, quilt, stgit.
> -	S: Status, one of the following:
> -	   Supported:	Someone is actually paid to look after this.
> -	   Maintained:	Someone actually looks after it.

... we don't have a way to track code that are maintained but no-one is 
paid.

IHMO, this is an important to track as a contributor should not expect 
the same level of support between someone that is paid for it and 
someone that is not.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 17:38:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 17:38:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLsBd-0000sT-0y; Tue, 07 Apr 2020 17:38:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=ZKm6=5X=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jLsBb-0000sG-87
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 17:38:55 +0000
X-Inumbo-ID: a686552c-78f6-11ea-8122-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a686552c-78f6-11ea-8122-12813bfff9fa;
 Tue, 07 Apr 2020 17:38:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:
 Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=eiF4aa0zQ/96ZjFZ+g49/zBFkKngySOJIsCL/9n+Y/o=; b=q+0mrVusowxJha5vrF842VlQF3
 XNpEvAyfh4gHdVzrqProQu6c7omtRkAjdWPOwOgGcGrOQrFevh8xnrNOA2UM4DvbULwYuCk/cSMj+
 gzDZhwSZkSWl57A9+YuaxCM63fGCsaIfKOOwNDtkAbNH1Fw2/ocd86OYu9AJnbiNxt2k=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBW-0000Ja-VB; Tue, 07 Apr 2020 17:38:50 +0000
Received: from 54-240-197-232.amazon.com ([54.240.197.232]
 helo=u2f063a87eabd5f.cbg10.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBW-00088J-Le; Tue, 07 Apr 2020 17:38:50 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 0/5] domain context infrastructure
Date: Tue,  7 Apr 2020 18:38:42 +0100
Message-Id: <20200407173847.1595-1-paul@xen.org>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Durrant <pdurrant@amazon.com>

Paul Durrant (5):
  xen/common: introduce a new framework for save/restore of 'domain'
    context
  xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
  tools/misc: add xen-domctx to present domain context
  common/domain: add a domain context record for shared_info...
  tools/libxc: make use of domain context SHARED_INFO record...

 .gitignore                             |   1 +
 tools/flask/policy/modules/xen.if      |   4 +-
 tools/libxc/include/xenctrl.h          |   5 +
 tools/libxc/xc_domain.c                |  54 ++++
 tools/libxc/xc_sr_common.h             |   7 +-
 tools/libxc/xc_sr_common_x86.c         |  59 +++++
 tools/libxc/xc_sr_common_x86.h         |   4 +
 tools/libxc/xc_sr_common_x86_pv.c      |  53 ++++
 tools/libxc/xc_sr_common_x86_pv.h      |   3 +
 tools/libxc/xc_sr_restore_x86_pv.c     |  40 ++-
 tools/libxc/xc_sr_save_x86_pv.c        |  26 +-
 tools/libxc/xg_save_restore.h          |   1 +
 tools/misc/Makefile                    |   4 +
 tools/misc/xen-domctx.c                | 156 ++++++++++++
 xen/common/Makefile                    |   1 +
 xen/common/domain.c                    |  81 ++++++
 xen/common/domctl.c                    | 117 +++++++++
 xen/common/save.c                      | 329 +++++++++++++++++++++++++
 xen/include/public/arch-arm/hvm/save.h |   5 +
 xen/include/public/arch-x86/hvm/save.h |   5 +
 xen/include/public/domctl.h            |  44 +++-
 xen/include/public/save.h              |  92 +++++++
 xen/include/xen/save.h                 | 152 ++++++++++++
 xen/xsm/flask/hooks.c                  |   6 +
 xen/xsm/flask/policy/access_vectors    |   4 +
 25 files changed, 1201 insertions(+), 52 deletions(-)
 create mode 100644 tools/misc/xen-domctx.c
 create mode 100644 xen/common/save.c
 create mode 100644 xen/include/public/save.h
 create mode 100644 xen/include/xen/save.h
---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Cc: Wei Liu <wl@xen.org>
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 17:38:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 17:38:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLsBf-0000tI-Ap; Tue, 07 Apr 2020 17:38:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=ZKm6=5X=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jLsBe-0000tC-Sb
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 17:38:58 +0000
X-Inumbo-ID: a9098328-78f6-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a9098328-78f6-11ea-9e09-bc764e2007e4;
 Tue, 07 Apr 2020 17:38:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
 In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Ps875/EWiRlLqTbL2/+Wxcz2/Dd5l8riK/3CroagOVs=; b=AXG13KXWJn19cdDUsxn5hH5ABl
 3zH4Mzm/3hDY3LiNP0x31d5U1G6k8taDV4mVvB7xC9czHJayCQe2hANh++MeovQluvPnrgfQ8EHTm
 pojFqePAurgx/dw9YXq1Q7lV+7e7sgsNrCU7RLo6+bkU8WWTPV8KtkxT6bLvX1uI0xWM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBd-0000K5-EN; Tue, 07 Apr 2020 17:38:57 +0000
Received: from 54-240-197-232.amazon.com ([54.240.197.232]
 helo=u2f063a87eabd5f.cbg10.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBd-00088J-5a; Tue, 07 Apr 2020 17:38:57 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 4/5] common/domain: add a domain context record for
 shared_info...
Date: Tue,  7 Apr 2020 18:38:46 +0100
Message-Id: <20200407173847.1595-5-paul@xen.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200407173847.1595-1-paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

... and update xen-domctx to dump some information describing the record.

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wl@xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>

v2:
 - Drop the header change to define a 'Xen' page size and instead use a
   variable length struct now that the framework makes this is feasible
 - Guard use of 'has_32bit_shinfo' in common code with CONFIG_COMPAT
---
 tools/misc/xen-domctx.c   | 11 ++++++
 xen/common/domain.c       | 81 +++++++++++++++++++++++++++++++++++++++
 xen/include/public/save.h | 10 ++++-
 3 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/tools/misc/xen-domctx.c b/tools/misc/xen-domctx.c
index d663522a8b..a8d3922321 100644
--- a/tools/misc/xen-domctx.c
+++ b/tools/misc/xen-domctx.c
@@ -59,6 +59,16 @@ static void dump_header(struct domain_save_descriptor *desc)
     off += desc->length;
 }
 
+static void dump_shared_info(struct domain_save_descriptor *desc)
+{
+    DOMAIN_SAVE_TYPE(SHARED_INFO) s;
+    READ(s);
+    printf("    SHARED_INFO: field_width %u buffer size: %lu\n",
+           s.field_width, desc->length - sizeof(s));
+
+    off += desc->length;
+}
+
 static void dump_end(struct domain_save_descriptor *desc)
 {
     DOMAIN_SAVE_TYPE(END) e;
@@ -125,6 +135,7 @@ int main(int argc, char **argv)
         switch (desc.typecode)
         {
         case DOMAIN_SAVE_CODE(HEADER): dump_header(&desc); break;
+        case DOMAIN_SAVE_CODE(SHARED_INFO): dump_shared_info(&desc); break;
         case DOMAIN_SAVE_CODE(END): dump_end(&desc); return 0;
         default:
             printf("Unknown type %u: skipping\n", desc.typecode);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 3dcd73f67c..8b72462e07 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -33,6 +33,7 @@
 #include <xen/xenoprof.h>
 #include <xen/irq.h>
 #include <xen/argo.h>
+#include <xen/save.h>
 #include <asm/debugger.h>
 #include <asm/p2m.h>
 #include <asm/processor.h>
@@ -1646,6 +1647,86 @@ int continue_hypercall_on_cpu(
     return 0;
 }
 
+static int save_shared_info(const struct vcpu *v, struct domain_context *c,
+                            bool dry_run)
+{
+    struct domain *d = v->domain;
+    struct domain_shared_info_context ctxt = {};
+    size_t hdr_size = offsetof(typeof(ctxt), buffer);
+    size_t size = hdr_size + PAGE_SIZE;
+    int rc;
+
+    rc = DOMAIN_SAVE_BEGIN(SHARED_INFO, c, v, size);
+    if ( rc )
+        return rc;
+
+    if ( !dry_run )
+        ctxt.field_width =
+#ifdef CONFIG_COMPAT
+            has_32bit_shinfo(d) ? 4 :
+#endif
+            8;
+
+    rc = domain_save_data(c, &ctxt, hdr_size);
+    if ( rc )
+        return rc;
+
+    rc = domain_save_data(c, d->shared_info, PAGE_SIZE);
+    if ( rc )
+        return rc;
+
+    return domain_save_end(c);
+}
+
+static int load_shared_info(struct vcpu *v, struct domain_context *c)
+{
+    struct domain *d = v->domain;
+    struct domain_shared_info_context ctxt = {};
+    size_t hdr_size = offsetof(typeof(ctxt), buffer);
+    size_t size = hdr_size + PAGE_SIZE;
+    unsigned int i;
+    int rc;
+
+    rc = DOMAIN_LOAD_BEGIN(SHARED_INFO, c, v, size, true);
+    if ( rc )
+        return rc;
+
+    rc = domain_load_data(c, &ctxt, hdr_size);
+    if ( rc )
+        return rc;
+
+    for ( i = 0; i < ARRAY_SIZE(ctxt.pad); i++ )
+        if ( ctxt.pad[i] )
+            return -EINVAL;
+
+    switch ( ctxt.field_width )
+    {
+#ifdef CONFIG_COMPAT
+    case 4:
+        d->arch.has_32bit_shinfo = 1;
+        break;
+#endif
+    case 8:
+#ifdef CONFIG_COMPAT
+        d->arch.has_32bit_shinfo = 0;
+#endif
+        break;
+
+    default:
+        rc = -EINVAL;
+        break;
+    }
+
+    rc = domain_load_data(c, d->shared_info, PAGE_SIZE);
+    if ( rc )
+        return rc;
+
+    return domain_load_end(c);
+}
+
+DOMAIN_REGISTER_SAVE_RESTORE(SHARED_INFO, false, save_shared_info,
+                             load_shared_info);
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/public/save.h b/xen/include/public/save.h
index 7e5f8752bd..ed994a8765 100644
--- a/xen/include/public/save.h
+++ b/xen/include/public/save.h
@@ -79,6 +79,14 @@ struct domain_save_header {
 };
 DECLARE_DOMAIN_SAVE_TYPE(HEADER, 1, struct domain_save_header);
 
-#define DOMAIN_SAVE_CODE_MAX 1
+struct domain_shared_info_context {
+    uint8_t field_width;
+    uint8_t pad[7];
+    uint8_t buffer[]; /* Implementation specific size */
+};
+
+DECLARE_DOMAIN_SAVE_TYPE(SHARED_INFO, 2, struct domain_shared_info_context);
+
+#define DOMAIN_SAVE_CODE_MAX 2
 
 #endif /* __XEN_PUBLIC_SAVE_H__ */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 17:39:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 17:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLsBh-0000uO-KU; Tue, 07 Apr 2020 17:39:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=ZKm6=5X=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jLsBg-0000ts-8E
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 17:39:00 +0000
X-Inumbo-ID: a676ad8e-78f6-11ea-8122-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a676ad8e-78f6-11ea-8122-12813bfff9fa;
 Tue, 07 Apr 2020 17:38:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:
 References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=sUupaxZe1m2wsdVWEzsPraTd+XGtEAcP1dSKKA8pr8Y=; b=q+fzA2Z+09+F7KEUbp/OSvrfy4
 usYZ1zrMioIRKAZFi8+zCmWBGxPO69g2PklYDR1duDXq+lCoyISqQkjb/P0FYZUq2YsuJQy+1QjFI
 peVzmkbqLoFAoiGCgZR0qKG61ENVESl9sxLsfLbHTD+FH/mky1XTgcis3u95ddcUUVO4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBZ-0000Jc-1P; Tue, 07 Apr 2020 17:38:53 +0000
Received: from 54-240-197-232.amazon.com ([54.240.197.232]
 helo=u2f063a87eabd5f.cbg10.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBY-00088J-H6; Tue, 07 Apr 2020 17:38:52 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 1/5] xen/common: introduce a new framework for save/restore
 of 'domain' context
Date: Tue,  7 Apr 2020 18:38:43 +0100
Message-Id: <20200407173847.1595-2-paul@xen.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200407173847.1595-1-paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.

Currently there is a framework (entered via the hvm_save/load() functions)
that allows a domain's 'HVM' (architectural) state to be transferred but
'PV' state is also common with pure PV guests and so this framework is not
really suitable.

This patch adds the new public header and low level implementation of a new
common framework, entered via the domain_save/load() functions. Subsequent
patches will introduce other parts of the framework, and code that will
make use of it within the current version of the libxc migration stream.

This patch also marks the HVM-only framework as deprecated in favour of the
new framework.

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Wei Liu <wl@xen.org>
Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>

v2:
 - Allow multi-stage save/load to avoid the need to double-buffer
 - Get rid of the masks and add an 'ignore' flag instead
 - Create copy function union to preserve const save buffer
 - Deprecate HVM-only framework
---
 xen/common/Makefile                    |   1 +
 xen/common/save.c                      | 329 +++++++++++++++++++++++++
 xen/include/public/arch-arm/hvm/save.h |   5 +
 xen/include/public/arch-x86/hvm/save.h |   5 +
 xen/include/public/save.h              |  84 +++++++
 xen/include/xen/save.h                 | 152 ++++++++++++
 6 files changed, 576 insertions(+)
 create mode 100644 xen/common/save.c
 create mode 100644 xen/include/public/save.h
 create mode 100644 xen/include/xen/save.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index e8cde65370..90553ba5d7 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -37,6 +37,7 @@ obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += rcupdate.o
 obj-y += rwlock.o
+obj-y += save.o
 obj-y += shutdown.o
 obj-y += softirq.o
 obj-y += sort.o
diff --git a/xen/common/save.c b/xen/common/save.c
new file mode 100644
index 0000000000..6cdac3785b
--- /dev/null
+++ b/xen/common/save.c
@@ -0,0 +1,329 @@
+/*
+ * save.c: Save and restore PV guest state common to all domain types.
+ *
+ * Copyright Amazon.com Inc. or its affiliates.
+ *
+ * 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 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 <http://www.gnu.org/licenses/>.
+ */
+
+#include <xen/save.h>
+
+union domain_copy_entry {
+    domain_write_entry write;
+    domain_read_entry read;
+};
+
+struct domain_context {
+    bool log;
+    struct domain_save_descriptor desc;
+    size_t data_len;
+    union domain_copy_entry copy;
+    void *priv;
+};
+
+static struct {
+    const char *name;
+    bool per_vcpu;
+    domain_save_handler save;
+    domain_load_handler load;
+} handlers[DOMAIN_SAVE_CODE_MAX + 1];
+
+void __init domain_register_save_type(unsigned int tc, const char *name,
+                                      bool per_vcpu,
+                                      domain_save_handler save,
+                                      domain_load_handler load)
+{
+    BUG_ON(tc > ARRAY_SIZE(handlers));
+
+    ASSERT(!handlers[tc].save);
+    ASSERT(!handlers[tc].load);
+
+    handlers[tc].name = name;
+    handlers[tc].per_vcpu = per_vcpu;
+    handlers[tc].save = save;
+    handlers[tc].load = load;
+}
+
+int domain_save_begin(struct domain_context *c, unsigned int tc,
+                      const char *name, const struct vcpu *v, size_t len)
+{
+    int rc;
+
+    if ( c->log )
+        gdprintk(XENLOG_INFO, "%pv save: %s (%lu)\n", v, name,
+                 (unsigned long)len);
+
+    BUG_ON(tc != c->desc.typecode);
+    BUG_ON(v->vcpu_id != c->desc.vcpu_id);
+
+    ASSERT(!c->data_len);
+    c->data_len = c->desc.length = len;
+
+    rc = c->copy.write(c->priv, &c->desc, sizeof(c->desc));
+    if ( rc )
+        return rc;
+
+    c->desc.length = 0;
+
+    return 0;
+}
+
+int domain_save_data(struct domain_context *c, const void *src, size_t len)
+{
+    if ( c->desc.length + len > c->data_len )
+        return -ENOSPC;
+
+    c->desc.length += len;
+
+    return c->copy.write(c->priv, src, len);
+}
+
+int domain_save_end(struct domain_context *c)
+{
+    /*
+     * If desc.length does not match the length specified in
+     * domain_save_begin(), there should have been more data.
+     */
+    if ( c->desc.length != c->data_len )
+        return -EIO;
+
+    c->data_len = 0;
+
+    return 0;
+}
+
+int domain_save(struct domain *d, domain_write_entry write, void *priv,
+                bool dry_run)
+{
+    struct domain_context c = {
+        .copy.write = write,
+        .priv = priv,
+        .log = !dry_run,
+    };
+    struct domain_save_header h = {
+        .magic = DOMAIN_SAVE_MAGIC,
+        .version = DOMAIN_SAVE_VERSION,
+    };
+    struct domain_save_header e;
+    unsigned int i;
+    int rc;
+
+    ASSERT(d != current->domain);
+
+    if ( d->is_dying )
+        return -EINVAL;
+
+    domain_pause(d);
+
+    c.desc.typecode = DOMAIN_SAVE_CODE(HEADER);
+
+    rc = DOMAIN_SAVE_ENTRY(HEADER, &c, d->vcpu[0], &h, sizeof(h));
+    if ( rc )
+        goto out;
+
+    for ( i = 0; i < ARRAY_SIZE(handlers); i++ )
+    {
+        domain_save_handler save = handlers[i].save;
+
+        if ( !save )
+            continue;
+
+        memset(&c.desc, 0, sizeof(c.desc));
+        c.desc.typecode = i;
+
+        if ( handlers[i].per_vcpu )
+        {
+            struct vcpu *v;
+
+            for_each_vcpu ( d, v )
+            {
+                c.desc.vcpu_id = v->vcpu_id;
+
+                rc = save(v, &c, dry_run);
+                if ( rc )
+                    goto out;
+            }
+        }
+        else
+        {
+            rc = save(d->vcpu[0], &c, dry_run);
+            if ( rc )
+                goto out;
+        }
+    }
+
+    memset(&c.desc, 0, sizeof(c.desc));
+    c.desc.typecode = DOMAIN_SAVE_CODE(END);
+
+    rc = DOMAIN_SAVE_ENTRY(END, &c, d->vcpu[0], &e, 0);
+
+ out:
+    domain_unpause(d);
+
+    return rc;
+}
+
+int domain_load_begin(struct domain_context *c, unsigned int tc,
+                      const char *name, const struct vcpu *v, size_t len,
+                      bool exact)
+{
+    if ( c->log )
+        gdprintk(XENLOG_INFO, "%pv load: %s (%lu)\n", v, name,
+                 (unsigned long)len);
+
+    BUG_ON(tc != c->desc.typecode);
+    BUG_ON(v->vcpu_id != c->desc.vcpu_id);
+
+    if ( (exact && (len != c->desc.length)) ||
+         (len < c->desc.length) )
+        return -EINVAL;
+
+    ASSERT(!c->data_len);
+    c->data_len = len;
+
+    return 0;
+}
+
+int domain_load_data(struct domain_context *c, void *dst, size_t len)
+{
+    size_t copy_len = min_t(size_t, len, c->desc.length);
+    int rc;
+
+    if ( c->data_len < len )
+        return -ENODATA;
+
+    c->data_len -= len;
+    c->desc.length -= copy_len;
+
+    rc = c->copy.read(c->priv, dst, copy_len);
+    if ( rc )
+        return rc;
+
+    /* Zero extend if the descriptor is exhausted */
+    len -= copy_len;
+    if ( len )
+    {
+        dst += copy_len;
+        memset(dst, 0, len);
+    }
+
+    return 0;
+}
+
+int domain_load_end(struct domain_context *c)
+{
+    /* If data_len is non-zero there is unread data */
+    if ( c->data_len )
+        return -EIO;
+
+    return 0;
+}
+
+int domain_load(struct domain *d, domain_read_entry read, void *priv)
+{
+    struct domain_context c = {
+        .copy.read = read,
+        .priv = priv,
+        .log = true,
+    };
+    struct domain_save_header h;
+    int rc;
+
+    ASSERT(d != current->domain);
+
+    if ( d->is_dying )
+        return -EINVAL;
+
+    rc = c.copy.read(c.priv, &c.desc, sizeof(c.desc));
+    if ( rc )
+        return rc;
+
+    if ( c.desc.typecode != DOMAIN_SAVE_CODE(HEADER) || c.desc.vcpu_id ||
+         c.desc.flags )
+        return -EINVAL;
+
+    rc = DOMAIN_LOAD_ENTRY(HEADER, &c, d->vcpu[0], &h, sizeof(h), true);
+    if ( rc )
+        return rc;
+
+    if ( h.magic != DOMAIN_SAVE_MAGIC || h.version != DOMAIN_SAVE_VERSION )
+        return -EINVAL;
+
+    domain_pause(d);
+
+    for (;;)
+    {
+        unsigned int i;
+        unsigned int flags;
+        domain_load_handler load;
+        struct vcpu *v;
+
+        rc = c.copy.read(c.priv, &c.desc, sizeof(c.desc));
+        if ( rc )
+            break;
+
+        rc = -EINVAL;
+
+        flags = c.desc.flags;
+        if ( flags & ~DOMAIN_SAVE_FLAG_IGNORE )
+            break;
+
+        if ( c.desc.typecode == DOMAIN_SAVE_CODE(END) ) {
+            if ( !(flags & DOMAIN_SAVE_FLAG_IGNORE) )
+                rc = DOMAIN_LOAD_ENTRY(END, &c, d->vcpu[0], NULL, 0, true);
+
+            break;
+        }
+
+        i = c.desc.typecode;
+        if ( i >= ARRAY_SIZE(handlers) )
+            break;
+
+        if ( (!handlers[i].per_vcpu && c.desc.vcpu_id) ||
+             (c.desc.vcpu_id >= d->max_vcpus) )
+            break;
+
+        v = d->vcpu[c.desc.vcpu_id];
+
+        if ( flags & DOMAIN_SAVE_FLAG_IGNORE )
+        {
+            /* Sink the data */
+            rc = domain_load_entry(&c, c.desc.typecode, "IGNORED",
+                                   v, NULL, c.desc.length, true);
+            if ( rc )
+                break;
+
+            continue;
+        }
+
+        load = handlers[i].load;
+
+        rc = load ? load(v, &c) : -EOPNOTSUPP;
+        if ( rc )
+            break;
+    }
+
+    domain_unpause(d);
+
+    return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
index 75b8e65bcb..d5b0c15203 100644
--- a/xen/include/public/arch-arm/hvm/save.h
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -26,6 +26,11 @@
 #ifndef __XEN_PUBLIC_HVM_SAVE_ARM_H__
 #define __XEN_PUBLIC_HVM_SAVE_ARM_H__
 
+/*
+ * Further use of HVM state is deprecated. New state records should only
+ * be added to the domain state header: public/save.h
+ */
+
 #endif
 
 /*
diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h
index 773a380bc2..e61e2dbcd7 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -648,6 +648,11 @@ struct hvm_msr {
  */
 #define HVM_SAVE_CODE_MAX 20
 
+/*
+ * Further use of HVM state is deprecated. New state records should only
+ * be added to the domain state header: public/save.h
+ */
+
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
 
 /*
diff --git a/xen/include/public/save.h b/xen/include/public/save.h
new file mode 100644
index 0000000000..7e5f8752bd
--- /dev/null
+++ b/xen/include/public/save.h
@@ -0,0 +1,84 @@
+/*
+ * save.h
+ *
+ * Structure definitions for common PV/HVM domain state that is held by
+ * Xen and must be saved along with the domain's memory.
+ *
+ * Copyright Amazon.com Inc. or its affiliates.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_SAVE_H__
+#define __XEN_PUBLIC_SAVE_H__
+
+#include "xen.h"
+
+/* Each entry is preceded by a descriptor */
+struct domain_save_descriptor {
+    uint16_t typecode;
+    /*
+     * Each entry will contain either to global or per-vcpu domain state.
+     * Entries relating to global state should have zero in this field.
+     */
+    uint16_t vcpu_id;
+    uint32_t flags;
+    /*
+     * When restoring state this flag can be set in a descriptor to cause
+     * its content to be ignored.
+     *
+     * NOTE: It is invalid to set this flag for HEADER or END records (see
+     *       below).
+     */
+#define _DOMAIN_SAVE_FLAG_IGNORE 0
+#define DOMAIN_SAVE_FLAG_IGNORE (1u << _DOMAIN_SAVE_FLAG_IGNORE)
+
+    /* Entry length not including this descriptor */
+    uint64_t length;
+};
+
+/*
+ * Each entry has a type associated with it. DECLARE_DOMAIN_SAVE_TYPE
+ * binds these things together.
+ */
+#define DECLARE_DOMAIN_SAVE_TYPE(_x, _code, _type) \
+    struct __DOMAIN_SAVE_TYPE_##_x { char c[_code]; _type t; };
+
+#define DOMAIN_SAVE_CODE(_x) \
+    (sizeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->c))
+#define DOMAIN_SAVE_TYPE(_x) \
+    typeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->t)
+
+/* Terminating entry */
+struct domain_save_end {};
+DECLARE_DOMAIN_SAVE_TYPE(END, 0, struct domain_save_end);
+
+#define DOMAIN_SAVE_MAGIC   0x53415645
+#define DOMAIN_SAVE_VERSION 0x00000001
+
+/* Initial entry */
+struct domain_save_header {
+    uint32_t magic;             /* Must be DOMAIN_SAVE_MAGIC */
+    uint32_t version;           /* Save format version */
+};
+DECLARE_DOMAIN_SAVE_TYPE(HEADER, 1, struct domain_save_header);
+
+#define DOMAIN_SAVE_CODE_MAX 1
+
+#endif /* __XEN_PUBLIC_SAVE_H__ */
diff --git a/xen/include/xen/save.h b/xen/include/xen/save.h
new file mode 100644
index 0000000000..879bbb4390
--- /dev/null
+++ b/xen/include/xen/save.h
@@ -0,0 +1,152 @@
+/*
+ * save.h: support routines for save/restore
+ *
+ * Copyright Amazon.com Inc. or its affiliates.
+ *
+ * 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 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 <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __XEN_SAVE_H__
+#define __XEN_SAVE_H__
+
+#include <xen/sched.h>
+#include <xen/types.h>
+#include <xen/init.h>
+
+#include <public/xen.h>
+#include <public/save.h>
+
+struct domain_context;
+
+int domain_save_begin(struct domain_context *c, unsigned int tc,
+                      const char *name, const struct vcpu *v, size_t len);
+
+#define DOMAIN_SAVE_BEGIN(_x, _c, _v, _len) \
+        domain_save_begin((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_len))
+
+int domain_save_data(struct domain_context *c, const void *data, size_t len);
+int domain_save_end(struct domain_context *c);
+
+static inline int domain_save_entry(struct domain_context *c,
+                                    unsigned int tc, const char *name,
+                                    const struct vcpu *v, const void *src,
+                                    size_t len)
+{
+    int rc;
+
+    rc = domain_save_begin(c, tc, name, v, len);
+    if ( rc )
+        return rc;
+
+    rc = domain_save_data(c, src, len);
+    if ( rc )
+        return rc;
+
+    return domain_save_end(c);
+}
+
+#define DOMAIN_SAVE_ENTRY(_x, _c, _v, _src, _len) \
+    domain_save_entry((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_src), (_len))
+
+int domain_load_begin(struct domain_context *c, unsigned int tc,
+                      const char *name, const struct vcpu *v, size_t len,
+                      bool exact);
+
+#define DOMAIN_LOAD_BEGIN(_x, _c, _v, _len, _exact) \
+        domain_load_begin((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_len), \
+                          (_exact));
+
+int domain_load_data(struct domain_context *c, void *data, size_t len);
+int domain_load_end(struct domain_context *c);
+
+static inline int domain_load_entry(struct domain_context *c,
+                                    unsigned int tc, const char *name,
+                                    const struct vcpu *v, void *dst,
+                                    size_t len, bool exact)
+{
+    int rc;
+
+    rc = domain_load_begin(c, tc, name, v, len, exact);
+    if ( rc )
+        return rc;
+
+    rc = domain_load_data(c, dst, len);
+    if ( rc )
+        return rc;
+
+    return domain_load_end(c);
+}
+
+#define DOMAIN_LOAD_ENTRY(_x, _c, _v, _dst, _len, _exact) \
+    domain_load_entry((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_dst), (_len), \
+                          (_exact))
+
+/*
+ * The 'dry_run' flag indicates that the caller of domain_save() (see
+ * below) is not trying to actually acquire the data, only the size
+ * of the data. The save handler can therefore limit work to only that
+ * which is necessary to call DOMAIN_SAVE_BEGIN/ENTRY() with an accurate
+ * value for '_len'.
+ */
+typedef int (*domain_save_handler)(const struct vcpu *v,
+                                   struct domain_context *h,
+                                   bool dry_run);
+typedef int (*domain_load_handler)(struct vcpu *v,
+                                   struct domain_context *h);
+
+void domain_register_save_type(unsigned int tc, const char *name,
+                               bool per_vcpu,
+                               domain_save_handler save,
+                               domain_load_handler load);
+
+/*
+ * Register save and restore handlers. Save handlers will be invoked
+ * in order of DOMAIN_SAVE_CODE().
+ */
+#define DOMAIN_REGISTER_SAVE_RESTORE(_x, _per_vcpu, _save, _load) \
+static int __init __domain_register_##_x##_save_restore(void)     \
+{                                                                 \
+    domain_register_save_type(                                    \
+        DOMAIN_SAVE_CODE(_x),                                     \
+        #_x,                                                      \
+        (_per_vcpu),                                              \
+        &(_save),                                                 \
+        &(_load));                                                \
+                                                                  \
+    return 0;                                                     \
+}                                                                 \
+__initcall(__domain_register_##_x##_save_restore);
+
+/* Copy callback functions */
+typedef int (*domain_write_entry)(void *priv, const void *data, size_t len);
+typedef int (*domain_read_entry)(void *priv, void *data, size_t len);
+
+/*
+ * Entry points:
+ *
+ * int domain_save(struct domain *d, domain_copy_entry copy, void *priv,
+ *                 bool dry_run);
+ * int domain_load(struct domain *d, domain_copy_entry copy, void *priv);
+ *
+ * write/read: This is a callback function provided by the caller that will
+ *             be used to write to (in the save case) or read from (in the
+ *             load case) the context buffer.
+ * priv:       This is a pointer that will be passed to the copy function to
+ *             allow it to identify the context buffer and the current state
+ *             of the save or load operation.
+ */
+int domain_save(struct domain *d, domain_write_entry write, void *priv,
+                bool dry_run);
+int domain_load(struct domain *d, domain_read_entry read, void *priv);
+
+#endif /* __XEN_SAVE_H__ */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 17:39:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 17:39:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLsBn-0000x2-24; Tue, 07 Apr 2020 17:39:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=ZKm6=5X=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jLsBl-0000wR-8M
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 17:39:05 +0000
X-Inumbo-ID: a7ccf22e-78f6-11ea-8122-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a7ccf22e-78f6-11ea-8122-12813bfff9fa;
 Tue, 07 Apr 2020 17:38:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
 In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=NoImRX3eY+SbLgUw7UBsBIQQ9vFVsWZzEUGCK32pEkU=; b=WDHfIR4+Ci6snrNcyyALiyBXHc
 7GOixTx2dYdvSbRu4ZMfg9QzMWbnwB/R6lMaFdy34oD2LSnCHjKJAqsMEb8QaY21Tz/Tpie5MevAs
 H9gmVFMNc/yd2h9FYdijfeZ1VXo9CSAEBiHzPYmgLRk0/SVSvVECJxXSnJDvi5nFF48M=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBb-0000Jv-QQ; Tue, 07 Apr 2020 17:38:55 +0000
Received: from 54-240-197-232.amazon.com ([54.240.197.232]
 helo=u2f063a87eabd5f.cbg10.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBb-00088J-Hi; Tue, 07 Apr 2020 17:38:55 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 3/5] tools/misc: add xen-domctx to present domain context
Date: Tue,  7 Apr 2020 18:38:45 +0100
Message-Id: <20200407173847.1595-4-paul@xen.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200407173847.1595-1-paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This tool is analogous to 'xen-hvmctx' which presents HVM context.
Subsequent patches will add 'dump' functions when new records are
introduced.

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wl@xen.org>

v2:
 - Change name from 'xen-ctx' to 'xen-domctx'
---
 .gitignore              |   1 +
 tools/misc/Makefile     |   4 ++
 tools/misc/xen-domctx.c | 145 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 150 insertions(+)
 create mode 100644 tools/misc/xen-domctx.c

diff --git a/.gitignore b/.gitignore
index 4ca679ddbc..744c0529bb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -208,6 +208,7 @@ tools/misc/xen_cpuperf
 tools/misc/xen-cpuid
 tools/misc/xen-detect
 tools/misc/xen-diag
+tools/misc/xen-domctx
 tools/misc/xen-tmem-list-parse
 tools/misc/xen-livepatch
 tools/misc/xenperf
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 63947bfadc..ef25524354 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -30,6 +30,7 @@ INSTALL_SBIN                   += xenpm
 INSTALL_SBIN                   += xenwatchdogd
 INSTALL_SBIN                   += xen-livepatch
 INSTALL_SBIN                   += xen-diag
+INSTALL_SBIN                   += xen-domctx
 INSTALL_SBIN += $(INSTALL_SBIN-y)
 
 # Everything to be installed in a private bin/
@@ -108,6 +109,9 @@ xen-livepatch: xen-livepatch.o
 xen-diag: xen-diag.o
 	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+xen-domctx: xen-domctx.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 xen-lowmemd: xen-lowmemd.o
 	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
diff --git a/tools/misc/xen-domctx.c b/tools/misc/xen-domctx.c
new file mode 100644
index 0000000000..d663522a8b
--- /dev/null
+++ b/tools/misc/xen-domctx.c
@@ -0,0 +1,145 @@
+/*
+ * xen-domctx.c
+ *
+ * Print out domain save records in a human-readable way.
+ *
+ * Copyright Amazon.com Inc. or its affiliates.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include <inttypes.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <errno.h>
+
+#include <xenctrl.h>
+#include <xen/xen.h>
+#include <xen/domctl.h>
+#include <xen/save.h>
+
+static void *buf = NULL;
+static size_t len, off;
+
+#define READ(_x) do {                                                   \
+    if ( len - off < sizeof (_x) )                                      \
+    {                                                                   \
+        fprintf(stderr,                                                 \
+                "Error: need another %lu bytes, only %lu available\n",  \
+                sizeof(_x), len - off);                                 \
+        exit(1);                                                        \
+    }                                                                   \
+    memcpy(&(_x), buf + off, sizeof (_x));                              \
+} while (0)
+
+static void dump_header(struct domain_save_descriptor *desc)
+{
+    DOMAIN_SAVE_TYPE(HEADER) h;
+    READ(h);
+    printf("    HEADER: magic %#x, version %u\n",
+           h.magic, h.version);
+
+    off += desc->length;
+}
+
+static void dump_end(struct domain_save_descriptor *desc)
+{
+    DOMAIN_SAVE_TYPE(END) e;
+    READ(e);
+    printf("    END\n");
+}
+
+int main(int argc, char **argv)
+{
+    uint32_t domid;
+    unsigned int entry;
+    xc_interface *xch;
+    int rc;
+
+    if ( argc != 2 || !argv[1] || (rc = atoi(argv[1])) < 0 )
+    {
+        fprintf(stderr, "usage: %s <domid>\n", argv[0]);
+        exit(1);
+    }
+    domid = rc;
+
+    xch = xc_interface_open(0,0,0);
+    if ( !xch )
+    {
+        fprintf(stderr, "Error: can't open libxc handle\n");
+        exit(1);
+    }
+
+    rc = xc_domain_getcontext(xch, domid, NULL, &len);
+    if ( rc < 0 )
+    {
+        fprintf(stderr, "Error: can't get record length for dom %u: %s\n",
+                domid, strerror(errno));
+        exit(1);
+    }
+
+    buf = malloc(len);
+    if ( !buf )
+    {
+        fprintf(stderr, "Error: can't allocate %lu bytes\n", len);
+        exit(1);
+    }
+
+    rc = xc_domain_getcontext(xch, domid, buf, &len);
+    if ( rc < 0 )
+    {
+        fprintf(stderr, "Error: can't get domain record for dom %u: %s\n",
+                domid, strerror(errno));
+        exit(1);
+    }
+    off = 0;
+
+    printf("Domain save records for d%u\n", domid);
+
+    entry = 0;
+    for (;;) {
+        struct domain_save_descriptor desc;
+
+        READ(desc);
+        printf("[%u] type %u v%u, length %lu\n", entry++,
+               desc.typecode, desc.vcpu_id, (unsigned long)desc.length);
+        off += sizeof(desc);
+
+        switch (desc.typecode)
+        {
+        case DOMAIN_SAVE_CODE(HEADER): dump_header(&desc); break;
+        case DOMAIN_SAVE_CODE(END): dump_end(&desc); return 0;
+        default:
+            printf("Unknown type %u: skipping\n", desc.typecode);
+            off += desc.length;
+            break;
+        }
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 17:39:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 17:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLsBs-0000za-BC; Tue, 07 Apr 2020 17:39:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=ZKm6=5X=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jLsBq-0000yd-8Y
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 17:39:10 +0000
X-Inumbo-ID: a808f42c-78f6-11ea-8122-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a808f42c-78f6-11ea-8122-12813bfff9fa;
 Tue, 07 Apr 2020 17:38:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
 In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Z1elA0lD7gZxiRrnC8vcJ37IU6sE2cBRKl8cN8x+k6w=; b=1HY+8lqR7v91p/05Us2yTfnmKA
 mfUjRfkmcMrDC2y4NJ/zuOw0QwodHnWuVp193ywwPo2p/mTA6xmm0XwoWuyUHqUOYzCyY1t+oSQwl
 fU560xZ4Vb1PtiCaQUO/wToZuonylFXPNNO5NwVuiwUmWIBiD97Y7svraykl4e9XZb98=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBa-0000Jp-PJ; Tue, 07 Apr 2020 17:38:54 +0000
Received: from 54-240-197-232.amazon.com ([54.240.197.232]
 helo=u2f063a87eabd5f.cbg10.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBa-00088J-GF; Tue, 07 Apr 2020 17:38:54 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 2/5] xen/common/domctl: introduce
 XEN_DOMCTL_get/setdomaincontext
Date: Tue,  7 Apr 2020 18:38:44 +0100
Message-Id: <20200407173847.1595-3-paul@xen.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200407173847.1595-1-paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

These domctls provide a mechanism to get and set domain context from
the toolstack.

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wl@xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>

v2:
 - drop mask parameter
 - const-ify some more buffers
---
 tools/flask/policy/modules/xen.if   |   4 +-
 tools/libxc/include/xenctrl.h       |   5 ++
 tools/libxc/xc_domain.c             |  54 +++++++++++++
 xen/common/domctl.c                 | 117 ++++++++++++++++++++++++++++
 xen/include/public/domctl.h         |  44 ++++++++++-
 xen/xsm/flask/hooks.c               |   6 ++
 xen/xsm/flask/policy/access_vectors |   4 +
 7 files changed, 231 insertions(+), 3 deletions(-)

diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index 8eb2293a52..2bc9db4f64 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -53,7 +53,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
 			set_vnumainfo get_vnumainfo cacheflush
 			psr_cmt_op psr_alloc soft_reset
-			resource_map get_cpu_policy };
+			resource_map get_cpu_policy setcontext };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
@@ -97,7 +97,7 @@ define(`migrate_domain_out', `
 	allow $1 $2:hvm { gethvmc getparam };
 	allow $1 $2:mmu { stat pageinfo map_read };
 	allow $1 $2:domain { getaddrsize getvcpucontext pause destroy };
-	allow $1 $2:domain2 gettsc;
+	allow $1 $2:domain2 { gettsc getcontext };
 	allow $1 $2:shadow { enable disable logdirty };
 ')
 
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 58fa931de1..06ca8e9a74 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -867,6 +867,11 @@ int xc_domain_hvm_setcontext(xc_interface *xch,
                              uint8_t *hvm_ctxt,
                              uint32_t size);
 
+int xc_domain_getcontext(xc_interface *xch, uint32_t domid,
+                         void *ctxt_buf, size_t *size);
+int xc_domain_setcontext(xc_interface *xch, uint32_t domid,
+                         const void *ctxt_buf, size_t size);
+
 /**
  * This function will return guest IO ABI protocol
  *
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 71829c2bce..212d1489dd 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -537,6 +537,60 @@ int xc_domain_hvm_setcontext(xc_interface *xch,
     return ret;
 }
 
+int xc_domain_getcontext(xc_interface *xch, uint32_t domid,
+                         void *ctxt_buf, size_t *size)
+{
+    int ret;
+    DECLARE_DOMCTL;
+    DECLARE_HYPERCALL_BOUNCE(ctxt_buf, *size, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+    if ( xc_hypercall_bounce_pre(xch, ctxt_buf) )
+        return -1;
+
+    domctl.cmd = XEN_DOMCTL_getdomaincontext;
+    domctl.domain = domid;
+    domctl.u.getdomaincontext.size = *size;
+    set_xen_guest_handle(domctl.u.setdomaincontext.buffer, ctxt_buf);
+
+    ret = do_domctl(xch, &domctl);
+
+    xc_hypercall_bounce_post(xch, ctxt_buf);
+
+    if ( ret )
+        return ret;
+
+    *size = domctl.u.getdomaincontext.size;
+    if ( *size != domctl.u.getdomaincontext.size )
+    {
+        errno = EOVERFLOW;
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_domain_setcontext(xc_interface *xch, uint32_t domid,
+                         const void *ctxt_buf, size_t size)
+{
+    int ret;
+    DECLARE_DOMCTL;
+    DECLARE_HYPERCALL_BOUNCE_IN(ctxt_buf, size);
+
+    if ( xc_hypercall_bounce_pre(xch, ctxt_buf) )
+        return -1;
+
+    domctl.cmd = XEN_DOMCTL_setdomaincontext;
+    domctl.domain = domid;
+    domctl.u.setdomaincontext.size = size;
+    set_xen_guest_handle(domctl.u.setdomaincontext.buffer, ctxt_buf);
+
+    ret = do_domctl(xch, &domctl);
+
+    xc_hypercall_bounce_post(xch, ctxt_buf);
+
+    return ret;
+}
+
 int xc_vcpu_getcontext(xc_interface *xch,
                        uint32_t domid,
                        uint32_t vcpu,
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a69b3b59a8..2e5c6a46d9 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -25,6 +25,7 @@
 #include <xen/hypercall.h>
 #include <xen/vm_event.h>
 #include <xen/monitor.h>
+#include <xen/save.h>
 #include <asm/current.h>
 #include <asm/irq.h>
 #include <asm/page.h>
@@ -358,6 +359,113 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
     return ERR_PTR(ret);
 }
 
+struct domctl_context
+{
+    void *buffer;
+    size_t len;
+    size_t cur;
+};
+
+static int accumulate_size(void *priv, const void *data, size_t len)
+{
+    struct domctl_context *c = priv;
+
+    if ( c->len + len < c->len )
+        return -EOVERFLOW;
+
+    c->len += len;
+
+    return 0;
+}
+
+static int save_data(void *priv, const void *data, size_t len)
+{
+    struct domctl_context *c = priv;
+
+    if ( c->len - c->cur < len )
+        return -ENOSPC;
+
+    memcpy(c->buffer + c->cur, data, len);
+    c->cur += len;
+
+    return 0;
+}
+
+static int getdomaincontext(struct domain *d,
+                            struct xen_domctl_getdomaincontext *gdc)
+{
+    struct domctl_context c = { };
+    int rc;
+
+    if ( d == current->domain )
+        return -EPERM;
+
+    if ( guest_handle_is_null(gdc->buffer) ) /* query for buffer size */
+    {
+        if ( gdc->size )
+            return -EINVAL;
+
+        /* dry run to acquire buffer size */
+        rc = domain_save(d, accumulate_size, &c, true);
+        if ( rc )
+            return rc;
+
+        gdc->size = c.len;
+        return 0;
+    }
+
+    c.len = gdc->size;
+    c.buffer = xmalloc_bytes(c.len);
+    if ( !c.buffer )
+        return -ENOMEM;
+
+    rc = domain_save(d, save_data, &c, false);
+
+    gdc->size = c.cur;
+    if ( !rc && copy_to_guest(gdc->buffer, c.buffer, gdc->size) )
+        rc = -EFAULT;
+
+    xfree(c.buffer);
+
+    return rc;
+}
+
+static int load_data(void *priv, void *data, size_t len)
+{
+    struct domctl_context *c = priv;
+
+    if ( c->len - c->cur < len )
+        return -ENODATA;
+
+    if ( data )
+        memcpy(data, c->buffer + c->cur, len);
+
+    c->cur += len;
+
+    return 0;
+}
+
+static int setdomaincontext(struct domain *d,
+                            const struct xen_domctl_setdomaincontext *sdc)
+{
+    struct domctl_context c = { .len = sdc->size };
+    int rc;
+
+    if ( d == current->domain )
+        return -EPERM;
+
+    c.buffer = xmalloc_bytes(c.len);
+    if ( !c.buffer )
+        return -ENOMEM;
+
+    rc = !copy_from_guest(c.buffer, sdc->buffer, c.len) ?
+        domain_load(d, load_data, &c) : -EFAULT;
+
+    xfree(c.buffer);
+
+    return rc;
+}
+
 long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
@@ -942,6 +1050,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             copyback = 1;
         break;
 
+    case XEN_DOMCTL_getdomaincontext:
+        ret = getdomaincontext(d, &op->u.getdomaincontext);
+        copyback = !ret;
+        break;
+
+    case XEN_DOMCTL_setdomaincontext:
+        ret = setdomaincontext(d, &op->u.setdomaincontext);
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 1ad34c35eb..8ab39acf0c 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -38,7 +38,7 @@
 #include "hvm/save.h"
 #include "memory.h"
 
-#define XEN_DOMCTL_INTERFACE_VERSION 0x00000012
+#define XEN_DOMCTL_INTERFACE_VERSION 0x00000013
 
 /*
  * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
@@ -1129,6 +1129,44 @@ struct xen_domctl_vuart_op {
                                  */
 };
 
+/*
+ * Get/Set domain PV context. The same struct xen_domctl_domaincontext
+ * is used for both commands but with slightly different field semantics
+ * as follows:
+ *
+ * XEN_DOMCTL_getdomaincontext
+ * ---------------------------
+ *
+ * buffer (IN):   The buffer into which the context data should be
+ *                copied, or NULL to query the buffer size that should
+ *                be allocated.
+ * size (IN/OUT): If 'buffer' is NULL then the value passed in must be
+ *                zero, and the value passed out will be the size of the
+ *                buffer to allocate.
+ *                If 'buffer' is non-NULL then the value passed in must
+ *                be the size of the buffer into which data may be copied.
+ */
+struct xen_domctl_getdomaincontext {
+    uint64_t size;
+    XEN_GUEST_HANDLE_64(void) buffer;
+};
+
+/* XEN_DOMCTL_setdomaincontext
+ * ---------------------------
+ *
+ * buffer (IN):   The buffer from which the context data should be
+ *                copied.
+ * size (IN):     The size of the buffer from which data may be copied.
+ *                This data must include DOMAIN_SAVE_CODE_HEADER at the
+ *                start and terminate with a DOMAIN_SAVE_CODE_END record.
+ *                Any data beyond the DOMAIN_SAVE_CODE_END record will be
+ *                ignored.
+ */
+struct xen_domctl_setdomaincontext {
+    uint64_t size;
+    XEN_GUEST_HANDLE_64(const_void) buffer;
+};
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -1210,6 +1248,8 @@ struct xen_domctl {
 #define XEN_DOMCTL_vuart_op                      81
 #define XEN_DOMCTL_get_cpu_policy                82
 #define XEN_DOMCTL_set_cpu_policy                83
+#define XEN_DOMCTL_getdomaincontext              84
+#define XEN_DOMCTL_setdomaincontext              85
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1270,6 +1310,8 @@ struct xen_domctl {
         struct xen_domctl_monitor_op        monitor_op;
         struct xen_domctl_psr_alloc         psr_alloc;
         struct xen_domctl_vuart_op          vuart_op;
+        struct xen_domctl_getdomaincontext  getdomaincontext;
+        struct xen_domctl_setdomaincontext  setdomaincontext;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8af8602b46..d94d0fc125 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -744,6 +744,12 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_get_cpu_policy:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_CPU_POLICY);
 
+    case XEN_DOMCTL_setdomaincontext:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SETCONTEXT);
+
+    case XEN_DOMCTL_getdomaincontext:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GETCONTEXT);
+
     default:
         return avc_unknown_permission("domctl", cmd);
     }
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index c055c14c26..fccfb9de82 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -245,6 +245,10 @@ class domain2
     resource_map
 # XEN_DOMCTL_get_cpu_policy
     get_cpu_policy
+# XEN_DOMCTL_setdomaincontext
+    setcontext
+# XEN_DOMCTL_getdomaincontext
+    getcontext
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 17:39:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 17:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLsBw-00011q-L4; Tue, 07 Apr 2020 17:39:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=ZKm6=5X=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jLsBv-00011A-8j
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 17:39:15 +0000
X-Inumbo-ID: a9687fae-78f6-11ea-8122-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a9687fae-78f6-11ea-8122-12813bfff9fa;
 Tue, 07 Apr 2020 17:38:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
 In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Q2rIXcUFs3l8U7hmdpz4Jn++ooIAw0V/fXHD3NFbNzU=; b=BvBtO5Y/ntoShIdAIY+Mqo/JSK
 92IGBsG3n140xv2nkusxnRR3vQWyG0fQ17AqE4fFbqzhiMnb2JJ4/2tT1bAKdgj940HMxph7XX1Oo
 PRr9P6/GdraH5wZRU/QJ27UShK40sSz4bpMdFSivXh0Gh6gpvDrWPOGHqG8gojLOLyWI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBe-0000KD-FY; Tue, 07 Apr 2020 17:38:58 +0000
Received: from 54-240-197-232.amazon.com ([54.240.197.232]
 helo=u2f063a87eabd5f.cbg10.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jLsBe-00088J-71; Tue, 07 Apr 2020 17:38:58 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 5/5] tools/libxc: make use of domain context SHARED_INFO
 record...
Date: Tue,  7 Apr 2020 18:38:47 +0100
Message-Id: <20200407173847.1595-6-paul@xen.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200407173847.1595-1-paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

... in the save/restore code.

This patch replaces direct mapping of the shared_info_frame (retrieved
using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
SHARED_INFO record.

No modifications are made to the definition of the migration stream at
this point. Subsequent patches will define a record in the libxc domain
image format for passing domain context and convert the save/restore code
to use that.

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wl@xen.org>

v2:
 - Re-based (now making use of DOMAIN_SAVE_FLAG_IGNORE)
---
 tools/libxc/xc_sr_common.h         |  7 +++-
 tools/libxc/xc_sr_common_x86.c     | 59 ++++++++++++++++++++++++++++++
 tools/libxc/xc_sr_common_x86.h     |  4 ++
 tools/libxc/xc_sr_common_x86_pv.c  | 53 +++++++++++++++++++++++++++
 tools/libxc/xc_sr_common_x86_pv.h  |  3 ++
 tools/libxc/xc_sr_restore_x86_pv.c | 40 ++++++++------------
 tools/libxc/xc_sr_save_x86_pv.c    | 26 ++-----------
 tools/libxc/xg_save_restore.h      |  1 +
 8 files changed, 144 insertions(+), 49 deletions(-)

diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 5dd51ccb15..db6519cdcc 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -287,6 +287,11 @@ struct xc_sr_context
     {
         struct /* x86 */
         {
+            struct {
+                void *buffer;
+                unsigned int len;
+            } domain_context;
+
             struct /* x86 PV guest. */
             {
                 /* 4 or 8; 32 or 64 bit domain */
@@ -314,7 +319,7 @@ struct xc_sr_context
                 /* The guest pfns containing the p2m leaves */
                 xen_pfn_t *p2m_pfns;
 
-                /* Read-only mapping of guests shared info page */
+                /* Pointer to shared_info (located in context buffer) */
                 shared_info_any_t *shinfo;
 
                 /* p2m generation count for verifying validity of local p2m. */
diff --git a/tools/libxc/xc_sr_common_x86.c b/tools/libxc/xc_sr_common_x86.c
index 011684df97..e87dc0f0f3 100644
--- a/tools/libxc/xc_sr_common_x86.c
+++ b/tools/libxc/xc_sr_common_x86.c
@@ -42,6 +42,65 @@ int handle_x86_tsc_info(struct xc_sr_context *ctx, struct xc_sr_record *rec)
     return 0;
 }
 
+int x86_get_context(struct xc_sr_context *ctx)
+{
+    xc_interface *xch = ctx->xch;
+    size_t len = 0;
+    int rc;
+
+    if ( ctx->x86.domain_context.buffer )
+    {
+        ERROR("Domain context already present");
+        return -1;
+    }
+
+    rc = xc_domain_getcontext(xch, ctx->domid, NULL, &len);
+    if ( rc < 0 )
+    {
+        PERROR("Unable to get size of domain context");
+        return -1;
+    }
+
+    ctx->x86.domain_context.buffer = malloc(len);
+    if ( ctx->x86.domain_context.buffer == NULL )
+    {
+        PERROR("Unable to allocate memory for domain context");
+        return -1;
+    }
+
+    rc = xc_domain_getcontext(xch, ctx->domid,
+                              ctx->x86.domain_context.buffer, &len);
+    if ( rc < 0 )
+    {
+        PERROR("Unable to get domain context");
+        return -1;
+    }
+
+    ctx->x86.domain_context.len = len;
+
+    return 0;
+}
+
+int x86_set_context(struct xc_sr_context *ctx)
+{
+    xc_interface *xch = ctx->xch;
+
+    if ( !ctx->x86.domain_context.buffer )
+    {
+        ERROR("Domain context not present");
+        return -1;
+    }
+
+    return xc_domain_setcontext(xch, ctx->domid,
+                                ctx->x86.domain_context.buffer,
+                                ctx->x86.domain_context.len);
+}
+
+void x86_cleanup(struct xc_sr_context *ctx)
+{
+    free(ctx->x86.domain_context.buffer);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_sr_common_x86.h b/tools/libxc/xc_sr_common_x86.h
index ebc4355bd1..501c9e52ba 100644
--- a/tools/libxc/xc_sr_common_x86.h
+++ b/tools/libxc/xc_sr_common_x86.h
@@ -14,6 +14,10 @@ int write_x86_tsc_info(struct xc_sr_context *ctx);
  */
 int handle_x86_tsc_info(struct xc_sr_context *ctx, struct xc_sr_record *rec);
 
+int x86_get_context(struct xc_sr_context *ctx);
+int x86_set_context(struct xc_sr_context *ctx);
+void x86_cleanup(struct xc_sr_context *ctx);
+
 #endif
 /*
  * Local variables:
diff --git a/tools/libxc/xc_sr_common_x86_pv.c b/tools/libxc/xc_sr_common_x86_pv.c
index d3d425cb82..7354fd6052 100644
--- a/tools/libxc/xc_sr_common_x86_pv.c
+++ b/tools/libxc/xc_sr_common_x86_pv.c
@@ -182,6 +182,59 @@ int x86_pv_map_m2p(struct xc_sr_context *ctx)
     return rc;
 }
 
+int x86_pv_get_shinfo(struct xc_sr_context *ctx)
+{
+    unsigned int off = 0;
+    struct domain_save_descriptor *desc;
+    int rc;
+
+    rc = x86_get_context(ctx);
+    if ( rc )
+        return rc;
+
+    do {
+        if ( ctx->x86.domain_context.len - off < sizeof(*desc) )
+            return -1;
+
+        desc = ctx->x86.domain_context.buffer + off;
+        off += sizeof(*desc);
+
+        switch (desc->typecode)
+        {
+        case DOMAIN_SAVE_CODE(SHARED_INFO):
+        {
+            DOMAIN_SAVE_TYPE(SHARED_INFO) *s;
+
+            if ( ctx->x86.domain_context.len - off < sizeof(*s) )
+                return -1;
+
+            s = ctx->x86.domain_context.buffer + off;
+            ctx->x86.pv.shinfo = (shared_info_any_t *)s->buffer;
+            /* fall through */
+        }
+        case DOMAIN_SAVE_CODE(HEADER):
+            off += desc->length;
+            /* fall through */
+        case DOMAIN_SAVE_CODE(END):
+            break;
+        default:
+            desc->flags |= DOMAIN_SAVE_FLAG_IGNORE;
+            off += desc->length;
+            break;
+        }
+    } while ( desc->typecode != DOMAIN_SAVE_CODE(END) );
+
+    if ( !ctx->x86.pv.shinfo )
+        return -1;
+
+    return 0;
+}
+
+int x86_pv_set_shinfo(struct xc_sr_context *ctx)
+{
+    return ctx->x86.pv.shinfo ? x86_set_context(ctx) : -1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_sr_common_x86_pv.h b/tools/libxc/xc_sr_common_x86_pv.h
index 2ed03309af..01442f48fb 100644
--- a/tools/libxc/xc_sr_common_x86_pv.h
+++ b/tools/libxc/xc_sr_common_x86_pv.h
@@ -97,6 +97,9 @@ int x86_pv_domain_info(struct xc_sr_context *ctx);
  */
 int x86_pv_map_m2p(struct xc_sr_context *ctx);
 
+int x86_pv_get_shinfo(struct xc_sr_context *ctx);
+int x86_pv_set_shinfo(struct xc_sr_context *ctx);
+
 #endif
 /*
  * Local variables:
diff --git a/tools/libxc/xc_sr_restore_x86_pv.c b/tools/libxc/xc_sr_restore_x86_pv.c
index 904ccc462a..4dbc7f0da5 100644
--- a/tools/libxc/xc_sr_restore_x86_pv.c
+++ b/tools/libxc/xc_sr_restore_x86_pv.c
@@ -864,8 +864,7 @@ static int handle_shared_info(struct xc_sr_context *ctx,
 {
     xc_interface *xch = ctx->xch;
     unsigned int i;
-    int rc = -1;
-    shared_info_any_t *guest_shinfo = NULL;
+    int rc;
     const shared_info_any_t *old_shinfo = rec->data;
 
     if ( !ctx->x86.pv.restore.seen_pv_info )
@@ -878,39 +877,30 @@ static int handle_shared_info(struct xc_sr_context *ctx,
     {
         ERROR("X86_PV_SHARED_INFO record wrong size: length %u"
               ", expected 4096", rec->length);
-        goto err;
+        return -1;
     }
 
-    guest_shinfo = xc_map_foreign_range(
-        xch, ctx->domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
-        ctx->dominfo.shared_info_frame);
-    if ( !guest_shinfo )
-    {
-        PERROR("Failed to map Shared Info at mfn %#lx",
-               ctx->dominfo.shared_info_frame);
-        goto err;
-    }
+    rc = x86_pv_get_shinfo(ctx);
+    if ( rc )
+        return rc;
 
-    MEMCPY_FIELD(guest_shinfo, old_shinfo, vcpu_info, ctx->x86.pv.width);
-    MEMCPY_FIELD(guest_shinfo, old_shinfo, arch, ctx->x86.pv.width);
+    MEMCPY_FIELD(ctx->x86.pv.shinfo, old_shinfo, vcpu_info,
+                 ctx->x86.pv.width);
+    MEMCPY_FIELD(ctx->x86.pv.shinfo, old_shinfo, arch, ctx->x86.pv.width);
 
-    SET_FIELD(guest_shinfo, arch.pfn_to_mfn_frame_list_list,
+    SET_FIELD(ctx->x86.pv.shinfo, arch.pfn_to_mfn_frame_list_list,
               0, ctx->x86.pv.width);
 
-    MEMSET_ARRAY_FIELD(guest_shinfo, evtchn_pending, 0, ctx->x86.pv.width);
+    MEMSET_ARRAY_FIELD(ctx->x86.pv.shinfo, evtchn_pending, 0,
+                       ctx->x86.pv.width);
     for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ )
-        SET_FIELD(guest_shinfo, vcpu_info[i].evtchn_pending_sel,
+        SET_FIELD(ctx->x86.pv.shinfo, vcpu_info[i].evtchn_pending_sel,
                   0, ctx->x86.pv.width);
 
-    MEMSET_ARRAY_FIELD(guest_shinfo, evtchn_mask, 0xff, ctx->x86.pv.width);
-
-    rc = 0;
+    MEMSET_ARRAY_FIELD(ctx->x86.pv.shinfo, evtchn_mask, 0xff,
+                       ctx->x86.pv.width);
 
- err:
-    if ( guest_shinfo )
-        munmap(guest_shinfo, PAGE_SIZE);
-
-    return rc;
+    return x86_pv_set_shinfo(ctx);
 }
 
 /* restore_ops function. */
diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
index f3ccf5bb4b..7c4fcffa92 100644
--- a/tools/libxc/xc_sr_save_x86_pv.c
+++ b/tools/libxc/xc_sr_save_x86_pv.c
@@ -9,25 +9,6 @@ static inline bool is_canonical_address(xen_vaddr_t vaddr)
     return ((int64_t)vaddr >> 47) == ((int64_t)vaddr >> 63);
 }
 
-/*
- * Maps the guests shared info page.
- */
-static int map_shinfo(struct xc_sr_context *ctx)
-{
-    xc_interface *xch = ctx->xch;
-
-    ctx->x86.pv.shinfo = xc_map_foreign_range(
-        xch, ctx->domid, PAGE_SIZE, PROT_READ, ctx->dominfo.shared_info_frame);
-    if ( !ctx->x86.pv.shinfo )
-    {
-        PERROR("Failed to map shared info frame at mfn %#lx",
-               ctx->dominfo.shared_info_frame);
-        return -1;
-    }
-
-    return 0;
-}
-
 /*
  * Copy a list of mfns from a guest, accounting for differences between guest
  * and toolstack width.  Can fail if truncation would occur.
@@ -1041,7 +1022,7 @@ static int x86_pv_setup(struct xc_sr_context *ctx)
     if ( rc )
         return rc;
 
-    rc = map_shinfo(ctx);
+    rc = x86_pv_get_shinfo(ctx);
     if ( rc )
         return rc;
 
@@ -1112,12 +1093,11 @@ static int x86_pv_cleanup(struct xc_sr_context *ctx)
     if ( ctx->x86.pv.p2m )
         munmap(ctx->x86.pv.p2m, ctx->x86.pv.p2m_frames * PAGE_SIZE);
 
-    if ( ctx->x86.pv.shinfo )
-        munmap(ctx->x86.pv.shinfo, PAGE_SIZE);
-
     if ( ctx->x86.pv.m2p )
         munmap(ctx->x86.pv.m2p, ctx->x86.pv.nr_m2p_frames * PAGE_SIZE);
 
+    x86_cleanup(ctx);
+
     return 0;
 }
 
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 303081df0d..296b523963 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -19,6 +19,7 @@
 
 #include <xen/foreign/x86_32.h>
 #include <xen/foreign/x86_64.h>
+#include <xen/save.h>
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 07 18:16:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 18:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLsm0-0004ho-Qr; Tue, 07 Apr 2020 18:16:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LBKk=5X=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jLslz-0004hj-Dv
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 18:16:31 +0000
X-Inumbo-ID: e6bee7da-78fb-11ea-812c-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e6bee7da-78fb-11ea-812c-12813bfff9fa;
 Tue, 07 Apr 2020 18:16:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586283389;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=STImqcdMefvLzQcK1dkcfoTo/4dDxme+5qJq/zzX+Ic=;
 b=ZdSWgahPbE7iKm+rg4AOhSLUWWNlYuZNddJQV6BKJMxFXzQUdG2tzWj9
 xesxDEF2NYHjSJR0NFTubFRp61zgCPlIrJr8T58b6Mev2bnNPB8eO/3H9
 GWOJFzDd1Dudm5BQf+lP9UVnkBe75dU5Bf/y8MqKnWFUmh/BDAXfhY6vI I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 51v1yYWQi3g6kaG83D3u07tzf811P4WzSvHCCHji9BCQ2dsVmT0O2/wz/KU04MPtMNCw8gmc3t
 AGdMBCZ/O6bWSR4PMKp5HOHxvnx/CBUopp0gCrhapNWEfXLKNjO946fZDP+Y9T8X9QV9rlH7Vw
 YvAAxk3TTwmw0UZam5CIoeINSa8Hy+l+peYN7e/nwoWTW5D/mktGeaEPiCvLkxFpaV+r1ZIN2X
 oL6Bs0wA2Xb076AiqaqYfTs63yVADYPhJqMcggivvPZ5Z7OmtS75no1XwoWEk9xchU3PuYyoGZ
 mSY=
X-SBRS: 2.7
X-MesageID: 15987249
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,356,1580792400"; d="scan'208";a="15987249"
From: George Dunlap <George.Dunlap@citrix.com>
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Topic: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Index: AQHWCRLu2U2EJ1WUk0i1KTanKYKpWqhmDBwAgAGf9wCAAAzcgIAEjVGAgAANpgCAAWgwAIAACYAAgAAYCYA=
Date: Tue, 7 Apr 2020 18:16:25 +0000
Message-ID: <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
In-Reply-To: <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <10DFC6CA537A29429BCC536E450D014E@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDcsIDIwMjAsIGF0IDU6NTAgUE0sIEp1bGllbiBHcmFsbCA8anVsaWVuQHhl
bi5vcmc+IHdyb3RlOg0KPiANCj4gDQo+IA0KPiBPbiAwNy8wNC8yMDIwIDE3OjE2LCBHZW9yZ2Ug
RHVubGFwIHdyb3RlOg0KPj4+IE9uIEFwciA2LCAyMDIwLCBhdCA3OjQ3IFBNLCBKdWxpZW4gR3Jh
bGwgPGp1bGllbkB4ZW4ub3JnPiB3cm90ZToNCj4+PiANCj4+PiBPbiAwNi8wNC8yMDIwIDE4OjU4
LCBHZW9yZ2UgRHVubGFwIHdyb3RlOg0KPj4+Pj4gT24gQXByIDMsIDIwMjAsIGF0IDk6MjcgUE0s
IEp1bGllbiBHcmFsbCA8anVsaWVuLmdyYWxsLm9zc0BnbWFpbC5jb20+IHdyb3RlOg0KPj4+Pj4g
DQo+Pj4+PiBPbiBGcmksIDMgQXByIDIwMjAgYXQgMjA6NDEsIFN0ZWZhbm8gU3RhYmVsbGluaSA8
c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4gd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gVGh1LCAy
IEFwciAyMDIwLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+Pj4+Pj4+IEFzIHdlIGRpc2N1c3NlZCBv
biBUdWVzZGF5LCB0aGUgY29zdCBmb3Igb3RoZXIgdkNQVXMgaXMgb25seSBnb2luZyB0byBiZSBh
DQo+Pj4+Pj4+IHRyYXAgdG8gdGhlIGh5cGVydmlzb3IgYW5kIHRoZW4gYmFjayBhZ2Fpbi4gVGhl
IGNvc3QgaXMgbGlrZWx5IHNtYWxsZXIgdGhhbg0KPj4+Pj4+PiByZWNlaXZpbmcgYW5kIGZvcndh
cmRpbmcgYW4gaW50ZXJydXB0Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gWW91IGFjdHVhbGx5IGFncmVl
ZCBvbiB0aGlzIGFuYWx5c2lzLiBTbyBjYW4geW91IGVubGlnaHRlbiBtZSBhcyB0byB3aHkNCj4+
Pj4+Pj4gcmVjZWl2aW5nIGFuIGludGVycnVwdCBpcyBhIG5vdCBwcm9ibGVtIGZvciBsYXRlbmN5
IGJ1dCB0aGlzIGlzPw0KPj4+Pj4+IA0KPj4+Pj4+IE15IGFuc3dlciB3YXMgdGhhdCB0aGUgZGlm
ZmVyZW5jZSBpcyB0aGF0IGFuIG9wZXJhdGluZyBzeXN0ZW0gY2FuDQo+Pj4+Pj4gZGlzYWJsZSBp
bnRlcnJ1cHRzLCBidXQgaXQgY2Fubm90IGRpc2FibGUgcmVjZWl2aW5nIHRoaXMgc3BlY2lhbCBJ
UEkuDQo+Pj4+PiANCj4+Pj4+IEFuIE9TIGNhbiAqb25seSogZGlzYWJsZSBpdHMgb3duIGludGVy
cnVwdHMsIHlldCBpbnRlcnJ1cHRzIHdpbGwgc3RpbGwNCj4+Pj4+IGJlIHJlY2VpdmVkIGJ5IFhl
biBldmVuIGlmIHRoZSBpbnRlcnJ1cHRzIGFyZSBtYXNrZWQgYXQgdGhlIHByb2Nlc3Nvcg0KPj4+
Pj4gKGUuZyBsb2NhbF9pcnFfZGlzYWJsZSgpKS4NCj4+Pj4+IA0KPj4+Pj4gWW91IHdvdWxkIG5l
ZWQgdG8gZGlzYWJsZSBpbnRlcnJ1cHRzIG9uZSBieSBvbmUgYXMgdGhlIEdJQyBsZXZlbCAodXNl
DQo+Pj4+PiBJQ0VOQUJMRVIpIGluIG9yZGVyIHRvIG5vdCByZWNlaXZlIGFueSBpbnRlcnJ1cHRz
LiBZZXQsIFhlbiBtYXkgc3RpbGwNCj4+Pj4+IHJlY2VpdmUgaW50ZXJydXB0cyBmb3Igb3BlcmF0
aW9uYWwgcHVycG9zZXMgKGUuZyBzZXJpYWwsIGNvbnNvbGUsDQo+Pj4+PiBtYWludGFpbmFuY2Ug
SVJRLi4uKS4gU28gdHJhcCB3aWxsIGhhcHBlbi4NCj4+Pj4gSSB0aGluayBTdGVmYW5v4oCZcyBh
c3NlcnRpb24gaXMgdGhhdCB0aGUgdXNlcnMgaGUgaGFzIGluIG1pbmQgd2lsbCBiZSBjb25maWd1
cmluZyB0aGUgc3lzdGVtIHN1Y2ggdGhhdCBSVCB3b3JrbG9hZHMgZ2V0IGEgbWluaW11bSBudW1i
ZXIgb2YgaHlwZXJ2aXNvci1yZWxhdGVkIGludGVycnVwdHMgcG9zc2libGUuICBPbiBhIDQtY29y
ZSBzeXN0ZW0sIHlvdSBjb3VsZCAgaGF2ZSBub24tUlQgd29ya2xvYWRzIHJ1bm5pbmcgb24gY29y
ZXMgMC0xLCBhbmQgUlQgd29ya2xvYWRzIHJ1bm5pbmcgd2l0aCB0aGUgTlVMTCBzY2hlZHVsZXIg
b24gY29yZXMgMi0zLiAgSW4gc3VjaCBhIHN5c3RlbSwgeW914oCZZCBvYnZpb3VzbHkgYXJyYW5n
ZSB0aGF0IHNlcmlhbCBhbmQgbWFpbnRlbmFuY2UgSVJRcyBhcmUgZGVsaXZlcmVkIHRvIGNvcmVz
IDAtMS4NCj4+PiBXZWxsIG1haW50ZW5hbmNlIElSUXMgYXJlIHBlciBwQ1BVIHNvIHlvdSBjYW4n
dCByb3V0ZSB0byBhbm90aGVyIG9uZS4uLg0KPj4+IA0KPj4+IEJ1dCwgSSB0aGluayB5b3UgbWlz
c2VkIG15IHBvaW50IHRoYXQgbG9jYWxfaXJxX2Rpc2FibGUoKSBmcm9tIHRoZSBndWVzdCB3aWxs
IG5vdCBwcmV2ZW50IHRoZSBoeXBlcnZpc29yIHRvIHJlY2VpdmUgaW50ZXJydXB0cyAqZXZlbiog
dGhlIG9uZSByb3V0ZWQgdG8gdGhlIHZDUFUgaXRzZWxmLiBUaGV5IHdpbGwganVzdCBub3QgYmUg
ZGVsaXZlcmVkIHRvIHRoZSBndWVzdCBjb250ZXh0IHVudGlsIGxvY2FsX2lycV9lbmFibGUoKSBp
cyBjYWxsZWQuDQo+PiBNeSB1bmRlcnN0YW5kaW5nLCBmcm9tIFN0ZWZhbm8gd2FzIHRoYXQgd2hh
dCBoaXMgY3VzdG9tZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQgaXMgdGhlIHRpbWUgYmV0d2VlbiB0
aGUgdGltZSBhIHBoeXNpY2FsIElSUSBpcyBkZWxpdmVyZWQgdG8gdGhlIGd1ZXN0IGFuZCB0aGUg
dGltZSB0aGUgZ3Vlc3QgT1MgY2FuIHJlc3BvbmQgYXBwcm9wcmlhdGVseS4gIFRoZSBrZXkgdGhp
bmcgaGVyZSBpc27igJl0IG5lY2Vzc2FyaWx5IHNwZWVkLCBidXQgcHJlZGljdGFiaWxpdHkg4oCU
IHN5c3RlbSBkZXNpZ25lcnMgbmVlZCB0byBrbm93IHRoYXQsIHdpdGggYSBoaWdoIHByb2JhYmls
aXR5LCB0aGVpciBpbnRlcnJ1cHQgcm91dGluZXMgd2lsbCBjb21wbGV0ZSB3aXRoaW4gWCBhbW91
bnQgb2YgY3ljbGVzLg0KPj4gRnVydGhlciBpbnRlcnJ1cHRzIGRlbGl2ZXJlZCB0byBhIGd1ZXN0
IGFyZSBub3QgYSBwcm9ibGVtIGluIHRoaXMgc2NlbmFyaW8sIGlmIHRoZSBndWVzdCBjYW4gZGlz
YWJsZSB0aGVtIHVudGlsIHRoZSBjcml0aWNhbCBJUlEgaGFzIGJlZW4gaGFuZGxlZC4NCj4gDQo+
IFlvdSBrZWVwIHNheWluZyBhIGd1ZXN0IGNhbiBkaXNhYmxlIGludGVycnVwdHMsIGJ1dCBpdCBj
YW4ndCBkbyBpdCB2aWEgbG9jYWxfaXJxX2Rpc2FibGUoKS4gU28gd2hhdCBtZXRob2QgYXJlIHlv
dSB0aGlua2luZz8gRGlzYWJsaW5nIGF0IHRoZSBHSUMgbGV2ZWw/IFRoYXQgaXMgaW52b2x2aW5n
IHRyYXBzIGFuZCBtb3N0IGxpa2VseSBub3QgZ29pbmcgdG8gaGVscCB3aXRoIHByZWRpY3RhYmls
aXR5Li4uDQoNClNvIHlvdeKAmWxsIGhhdmUgdG8gZm9yZ2l2ZSBtZSBmb3IgbWFraW5nIGVkdWNh
dGVkIGd1ZXNzZXMgaGVyZSwgYXMgSeKAmW0gdHJ5aW5nIHRvIGNvbGxlY3QgYWxsIHRoZSBpbmZv
cm1hdGlvbi4gIE9uIHg4NiwgaWYgeW91IHVzZSBkZXZpY2UgcGFzcy10aHJvdWdoIG9uIGEgc3lz
dGVtIHdpdGggYSB2aXJ0dWFsaXplZCBBUElDIGFuZCBwb3N0ZWQgaW50ZXJydXB0cywgdGhlbiB3
aGVuIHdoZW4gdGhlIGRldmljZSBnZW5lcmF0ZXMgaW50ZXJydXB0cywgdGhvc2UgYXJlIGRlbGl2
ZXJlZCBkaXJlY3RseSB0byB0aGUgZ3Vlc3Qgd2l0aG91dCBpbnZvbHZlbWVudCBvZiBYZW47IGFu
ZCB3aGVuIHRoZSBndWVzdCBkaXNhYmxlcyBpbnRlcnJ1cHRzIGluIHRoZSB2QVBJQywgdGhvc2Ug
aW50ZXJydXB0cyB3aWxsIGJlIGRpc2FibGVkLCBhbmQgYmUgZGVsaXZlcmVkIHdoZW4gdGhlIGd1
ZXN0IHJlLWVuYWJsZXMgaW50ZXJydXB0cy4gIEdpdmVuIHdoYXQgU3RlZmFubyBzYWlkIGFib3V0
IGRpc2FibGluZyBpbnRlcnJ1cHRzLCBJIGFzc3VtZWQgdGhhdCBBUk0gaGFkIHRoZSBzYW1lIHNv
cnQgb2YgZnVuY3Rpb25hbGl0eS4gIElzIHRoYXQgbm90IHRoZSBjYXNlPw0KDQo+PiBYZW4tcmVs
YXRlZCBJUElzLCBob3dldmVyLCBjb3VsZCBwb3RlbnRpYWxseSBjYXVzZSBhIHByb2JsZW0gaWYg
bm90IG1pdGlnYXRlZC4gQ29uc2lkZXIgYSBndWVzdCB3aGVyZSB2Y3B1IDEgbG9vcHMgb3ZlciB0
aGUgcmVnaXN0ZXIsIHdoaWxlIHZjcHUgMiBpcyBoYW5kbGluZyBhIGxhdGVuY3ktY3JpdGljYWwg
SVJRLiAgQSBuYWl2ZSBpbXBsZW1lbnRhdGlvbiBtaWdodCBzZW5kIGFuIElQSSBldmVyeSB0aW1l
IHZjcHUgMSBkb2VzIGEgcmVhZCwgc3BhbW1pbmcgdmNwdSAyIHdpdGggZG96ZW5zIG9mIElQSXMu
ICBUaGVuIGFuIElSUSByb3V0aW5lIHdoaWNoIHJlbGlhYmx5IGZpbmlzaGVzIHdlbGwgd2l0aGlu
IHRoZSByZXF1aXJlZCB0aW1lIG5vcm1hbGx5IHN1ZGRlbmx5IG92ZXJydW5zIGFuZCBjYXVzZXMg
YW4gaXNzdWUuDQo+IA0KPiBJIG5ldmVyIHN1Z2dlc3RlZCB0aGUgbmFpdmUgaW1wbGVtZW50YXRp
b24gd291bGQgYmUgcGVyZmVjdC4gVGhhdCdzIHdoeSBJIHNhaWQgaXQgY2FuIGJlIG9wdGltaXpl
ZC4uLg0KDQpJdCBkaWRu4oCZdCBzZWVtIHRvIG1lIHRoYXQgeW91IHVuZGVyc3Rvb2Qgd2hhdCBT
dGVmYW5v4oCZcyBjb25jZXJucyB3ZXJlOyBzbyBJIHdhcyB0cnlpbmcgdG8gZXhwbGFpbiB0aGUg
c2l0dWF0aW9uIGhlIGlzIHRyeWluZyB0byBhdm9pZCAoYXMgd2VsbCBhcyBtYWtpbmcgc3VyZSB0
aGF0IEkgaGFkIGEgY2xlYXIgdW5kZXJzdGFuZGluZyBteXNlbGYpLiAgVGhlIHJlYXNvbiBJIHNh
aWQg4oCcYSBuYWl2ZSBpbXBsZW1lbnRhdGlvbuKAnSB3YXMgdG8gbWFrZSBjbGVhciB0aGF0IEkg
a25ldyB0aGF04oCZcyBub3Qgd2hhdCB5b3Ugd2VyZSBzdWdnZXN0aW5nLiA6LSkNCg0KPj4gSSBk
b27igJl0IGtub3cgd2hhdCBtYWludGVuYW5jZSBJUlFzIGFyZSwgYnV0IGlmIHRoZXkgb25seSBo
YXBwZW4gaW50ZXJtaXR0ZW50bHksIGl04oCZcyBwb3NzaWJsZSB0aGF0IHlvdeKAmWQgbmV2ZXIg
Z2V0IG1vcmUgdGhhbiBhIHNpbmdsZSBvbmUgaW4gYSBsYXRlbmN5LWNyaXRpY2FsIElSUSByb3V0
aW5lOyBhbmQgYXMgc3VjaCwgdGhlIHZhcmlhdGliaWxpdHkgaW4gZXhlY3V0aW9uIHRpbWUgKGpp
dHRlcikgd291bGRu4oCZdCBiZSBhbiBpc3N1ZSBpbiBwcmFjdGljZS4gIEJ1dCBldmVyeSB0aW1l
IHlvdSBhZGQgYSBuZXcgdW5ibG9ja2FibGUgSVBJLCB5b3UgaW5jcmVhc2UgdGhpcyBqaXR0ZXI7
IHBhcnRpY3VsYXJseSBpZiB0aGlzIHVuYmxvY2thYmxlIElQSSBtaWdodCBiZSByZXBlYXRlZCBh
biBhcmJpdHJhcnkgbnVtYmVyIG9mIHRpbWVzLg0KPj4gKFN0ZWZhbm8sIGxldCBtZSBrbm93IGlm
IEnigJl2ZSBtaXN1bmRlcnN0b29kIHNvbWV0aGluZy4pDQo+PiBTbyBzdGVwcGluZyBiYWNrIGEg
bW9tZW50LCBoZXJl4oCZcyBhbGwgdGhlIHBvc3NpYmxlIGlkZWFzIHRoYXQgSSB0aGluayBoYXZl
IGJlZW4gZGlzY3Vzc2VkIChvciBhcmUgdGhlcmUgaW1wbGljaXRseSkgc28gZmFyLg0KPj4gMS4g
W0RlZmF1bHRdIERvIG5vdGhpbmc7IGd1ZXN0cyB1c2luZyB0aGlzIHJlZ2lzdGVyIGNvbnRpbnVl
IGNyYXNoaW5nDQo+PiAyLiBNYWtlIHRoZSBJP0FDVElWRVIgcmVnaXN0ZXJzIFJaV0kuDQo+PiAz
LiBNYWtlIEk/QUNUSVZFUiByZXR1cm4gdGhlIG1vc3QgcmVjZW50IGtub3duIHZhbHVlOyBpLmUu
IEtWTeKAmXMgY3VycmVudCBiZWhhdmlvciAoYXMgZmFyIGFzIHdlIHVuZGVyc3RhbmQgaXQpDQo+
PiA0LiBVc2UgYSBzaW1wbGUgSVBJIHdpdGggZG9fbm9vcCB0byB1cGRhdGUgST9BQ1RJVkVSDQo+
PiA0YS4gIFVzZSBhbiBJUEksIGJ1dCBjb21lIHVwIHdpdGggY2xldmVyIHRyaWNrcyB0byBhdm9p
ZCBpbnRlcnJ1cHRpbmcgZ3Vlc3RzIGhhbmRsaW5nIElSUXMuDQo+PiA1LiBUcmFwIHRvIFhlbiBv
biBndWVzdCBFT0ksIHNvIHRoYXQgd2Uga25vdyB3aGVuIHRoZQ0KPj4gNi4gU29tZSBjbGV2ZXIg
cGFyYXZpcnR1YWxpemVkIG9wdGlvbg0KPiANCj4gNy4gVXNlIGFuIElQSSBpZiB3ZSBhcmUgY29u
ZmlkZW50IHRoZSBpbnRlcnJ1cHRzIG1heSBiZSBhY3RpdmUuDQoNCkkgZG9u4oCZdCB1bmRlcnN0
YW5kIHRoaXMgb25lLiAgSG93IGlzIGl0IGRpZmZlcmVudCB0aGFuIDQgb3IgNGE/ICBBbmQgaW4g
cGFydGljdWxhciwgaG93IGRvZXMgaXQgZXZhbHVhdGUgb24gdGhlIOKAnGhvdyBtdWNoIGFkZGl0
aW9uYWwgZGVzaWduIHdvcmsgd291bGQgaXQgdGFrZeKAnSBjcml0ZXJpYT8NCg0KIC1HZW9yZ2UN
Cg0K


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 18:52:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 18:52:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLtKb-0007rl-QS; Tue, 07 Apr 2020 18:52:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=VNrn=5X=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLtKa-0007rg-RM
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 18:52:16 +0000
X-Inumbo-ID: e370c940-7900-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e370c940-7900-11ea-83d8-bc764e2007e4;
 Tue, 07 Apr 2020 18:52:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=J8QUelkImtwK8dTNqVdGqj7N+hc/G2U2JS9Cj5gIr3c=; b=ZDkWg7zcXiHxioX10IslBeEJh
 x+PuvfyNd5vm5Y7x86UHpmig0ODTMvHHnE95yecF0Se1NunvHDQ+w1tkPJtdiYnXp47PTkshDs4j3
 W2n5New/uwS1RUuWHWxKgxAs5HUQa1Wm/2t0v1bN0bdAQaOaKvp9GEpDCIz56Og6UGYgc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLtKU-0001oX-RJ; Tue, 07 Apr 2020 18:52:10 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLtKU-0005ts-Dj; Tue, 07 Apr 2020 18:52:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLtKU-0001Y9-DB; Tue, 07 Apr 2020 18:52:10 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149485-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149485: all pass - PUSHED
X-Osstest-Versions-This: ovmf=aab6a9c9aebb1f6614e72e98bdf6b5af93a43527
X-Osstest-Versions-That: ovmf=48f0e94921d83b8204f1025412e071b000394f04
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 07 Apr 2020 18:52:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 aab6a9c9aebb1f6614e72e98bdf6b5af93a43527
baseline version:
 ovmf                 48f0e94921d83b8204f1025412e071b000394f04

Last test of basis   149477  2020-04-07 01:39:26 Z    0 days
Testing same since   149485  2020-04-07 08:40:39 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@arm.com>
  Jiewen Yao <Jiewen.yao@intel.com>
  Liming Gao <liming.gao@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   48f0e94921..aab6a9c9ae  aab6a9c9aebb1f6614e72e98bdf6b5af93a43527 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 19:59:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 19:59:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLuNK-0004LR-68; Tue, 07 Apr 2020 19:59:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=SCBO=5X=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jLuNJ-0004LM-6K
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 19:59:09 +0000
X-Inumbo-ID: 3d67ce68-790a-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3d67ce68-790a-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 19:59:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=jPFsBjxd3Doql0+ud0QNs2WdFtGfq29Yfg2hYU/951s=; b=5A1ZJUatge1GZKR4wHZzjFlaja
 nzBbLrJFZxNGjRNe++Y+SiGE1KOkSdXnAluErfwdAS5D1BuLYtEOuUqx1xvDKXJCtxrtKZIVbG8YN
 3WbPIzf8isRWIHFmJZRy6QB1UJIbfICC5QBi1m30EC3ImyspcwAr3k1iB76ZNx5nlOOc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLuNC-00037b-0b; Tue, 07 Apr 2020 19:59:02 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jLuNB-0008EN-Ke; Tue, 07 Apr 2020 19:59:01 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: George Dunlap <George.Dunlap@citrix.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
 <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <057f48b7-84be-0bc5-773d-d01a79181b20@xen.org>
Date: Tue, 7 Apr 2020 20:58:59 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
 Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi George,

On 07/04/2020 19:16, George Dunlap wrote:
> 
> 
>> On Apr 7, 2020, at 5:50 PM, Julien Grall <julien@xen.org> wrote:
>>
>>
>>
>> On 07/04/2020 17:16, George Dunlap wrote:
>>>> On Apr 6, 2020, at 7:47 PM, Julien Grall <julien@xen.org> wrote:
>>>>
>>>> On 06/04/2020 18:58, George Dunlap wrote:
>>>>>> On Apr 3, 2020, at 9:27 PM, Julien Grall <julien.grall.oss@gmail.com> wrote:
>>>>>>
>>>>>> On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>>>>>
>>>>>>> On Thu, 2 Apr 2020, Julien Grall wrote:
>>>>>>>> As we discussed on Tuesday, the cost for other vCPUs is only going to be a
>>>>>>>> trap to the hypervisor and then back again. The cost is likely smaller than
>>>>>>>> receiving and forwarding an interrupt.
>>>>>>>>
>>>>>>>> You actually agreed on this analysis. So can you enlighten me as to why
>>>>>>>> receiving an interrupt is a not problem for latency but this is?
>>>>>>>
>>>>>>> My answer was that the difference is that an operating system can
>>>>>>> disable interrupts, but it cannot disable receiving this special IPI.
>>>>>>
>>>>>> An OS can *only* disable its own interrupts, yet interrupts will still
>>>>>> be received by Xen even if the interrupts are masked at the processor
>>>>>> (e.g local_irq_disable()).
>>>>>>
>>>>>> You would need to disable interrupts one by one as the GIC level (use
>>>>>> ICENABLER) in order to not receive any interrupts. Yet, Xen may still
>>>>>> receive interrupts for operational purposes (e.g serial, console,
>>>>>> maintainance IRQ...). So trap will happen.
>>>>> I think Stefano’s assertion is that the users he has in mind will be configuring the system such that RT workloads get a minimum number of hypervisor-related interrupts possible.  On a 4-core system, you could  have non-RT workloads running on cores 0-1, and RT workloads running with the NULL scheduler on cores 2-3.  In such a system, you’d obviously arrange that serial and maintenance IRQs are delivered to cores 0-1.
>>>> Well maintenance IRQs are per pCPU so you can't route to another one...
>>>>
>>>> But, I think you missed my point that local_irq_disable() from the guest will not prevent the hypervisor to receive interrupts *even* the one routed to the vCPU itself. They will just not be delivered to the guest context until local_irq_enable() is called.
>>> My understanding, from Stefano was that what his customers are concerned about is the time between the time a physical IRQ is delivered to the guest and the time the guest OS can respond appropriately.  The key thing here isn’t necessarily speed, but predictability — system designers need to know that, with a high probability, their interrupt routines will complete within X amount of cycles.
>>> Further interrupts delivered to a guest are not a problem in this scenario, if the guest can disable them until the critical IRQ has been handled.
>>
>> You keep saying a guest can disable interrupts, but it can't do it via local_irq_disable(). So what method are you thinking? Disabling at the GIC level? That is involving traps and most likely not going to help with predictability...
> 
> So you’ll have to forgive me for making educated guesses here, as I’m trying to collect all the information.  On x86, if you use device pass-through on a system with a virtualized APIC and posted interrupts, then when when the device generates interrupts, those are delivered directly to the guest without involvement of Xen; and when the guest disables interrupts in the vAPIC, those interrupts will be disabled, and be delivered when the guest re-enables interrupts.  Given what Stefano said about disabling interrupts, I assumed that ARM had the same sort of functionality.  Is that not the case?

Posted interrupts are only present in GICv4 and onwards. GICv4 only 
supports direct injections for LPIs (e.g MSIs) and GICv4.1 added support 
for direct injection of SGIs (aka IPIs).

Xen on Arm does not support any posted interrupts at all and, I don't 
believe Stefano has HW (at least in production) using GICv4.

> 
>>> Xen-related IPIs, however, could potentially cause a problem if not mitigated. Consider a guest where vcpu 1 loops over the register, while vcpu 2 is handling a latency-critical IRQ.  A naive implementation might send an IPI every time vcpu 1 does a read, spamming vcpu 2 with dozens of IPIs.  Then an IRQ routine which reliably finishes well within the required time normally suddenly overruns and causes an issue.
>>
>> I never suggested the naive implementation would be perfect. That's why I said it can be optimized...
> 
> It didn’t seem to me that you understood what Stefano’s concerns were; so I was trying to explain the situation he is trying to avoid (as well as making sure that I had a clear understanding myself).  The reason I said “a naive implementation” was to make clear that I knew that’s not what you were suggesting. :-)

I know Stefano's concerns, sorry it was not clear enough :).

> 
>>> I don’t know what maintenance IRQs are, but if they only happen intermittently, it’s possible that you’d never get more than a single one in a latency-critical IRQ routine; and as such, the variatibility in execution time (jitter) wouldn’t be an issue in practice.  But every time you add a new unblockable IPI, you increase this jitter; particularly if this unblockable IPI might be repeated an arbitrary number of times.
>>> (Stefano, let me know if I’ve misunderstood something.)
>>> So stepping back a moment, here’s all the possible ideas that I think have been discussed (or are there implicitly) so far.
>>> 1. [Default] Do nothing; guests using this register continue crashing
>>> 2. Make the I?ACTIVER registers RZWI.
>>> 3. Make I?ACTIVER return the most recent known value; i.e. KVM’s current behavior (as far as we understand it)
>>> 4. Use a simple IPI with do_noop to update I?ACTIVER
>>> 4a.  Use an IPI, but come up with clever tricks to avoid interrupting guests handling IRQs.
>>> 5. Trap to Xen on guest EOI, so that we know when the
>>> 6. Some clever paravirtualized option
>>
>> 7. Use an IPI if we are confident the interrupts may be active.
> 
> I don’t understand this one.  How is it different than 4 or 4a?  And in particular, how does it evaluate on the “how much additional design work would it take” criteria?

Let me start with, if we want to have a vGIC to rule them all, then I am 
afraid you are going to have to compromise. We can discuss about 
tailoring the vGIC but I think before that we need a vGIC that is 
faithfull with the spec (e.g differentiating level vs edge interrupts, 
handling activer...). Note that Arm spent some effort to get a new vGIC 
merged but this was never made a first class citizen.

However, even if you tailor the vGIC, you are not going to be able to 
avoid IPI in some occasions. This would happen when using event 
channels, in-guest IPI... Another example is when enabling an interrupt, 
although I realize that our vGIC does not do it today meaning that a 
pending interrupt while disabled will not be forwarded until the vCPU exit.

Furthermore, implementing a write to I{C,S}ACTIVER (to 
activate/de-activate) is going to be very difficult (to not say 
impossible) to do without IPI.

If you are worry about a vCPU been interrupted in critical section, then 
I think you should tailor your guest to avoid using those registers.

An alternative would be to use spinlock/mutex within the code to prevent 
a VCPU to access the vGIC registers while another vCPU don't want to be 
interrupted.

Regarding, 4a. The only way I could think of would be to trap the 
instructions that mask/unmask interrupts. If I read correctly the Armv8 
spec, it is not possible to do it.

7. is basically 4.a the goal would be to avoid interrupts the vCPU has 
much as possible but you may be wrong sometimes. Obviously we want to be 
correct most of the times.

I understand this may not be the ideal solution, but this is probably 
the best we could come with and does not involve a lot of work because 
we have already all the information in place (we know when an interrupt 
was injected to a vCPU).

The next best solution is to prevent in your guest to modify some 
registers of the vGIC at the same time as another vCPU is in a critical 
section.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 20:06:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 20:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLuUP-0005IB-5Y; Tue, 07 Apr 2020 20:06:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=AwYI=5X=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jLuUN-0005I4-V1
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 20:06:27 +0000
X-Inumbo-ID: 43ab3cb4-790b-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 43ab3cb4-790b-11ea-9e09-bc764e2007e4;
 Tue, 07 Apr 2020 20:06:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=Zr5IApQcCInFwdnEtALP5nQ4dY4ehW1qoQI0xBQ6AwE=; b=4qn/zeixTOUXRklkKCQZUcLUA7
 3ByqjkWux/U2m52f1P0caTJYLfCXz5/MRVdKZIg2npTqMsJlANfffwXFf3Eoe45v+g6zXvcXLVakG
 u36BPecMG0rgrW0rSck6zvgMYp9X0jJH6bElsngjv72UVMCizEuaao8se+6FhEgkogKo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jLuUN-0003Kx-2J; Tue, 07 Apr 2020 20:06:27 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jLuUM-0000Nh-On; Tue, 07 Apr 2020 20:06:26 +0000
Date: Tue, 7 Apr 2020 21:06:23 +0100
From: Wei Liu <wl@xen.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH] config: use mini-os master for unstable
Message-ID: <20200407200623.lkrosait3iaxrjt5@debian>
References: <20200407134831.22354-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200407134831.22354-1-jgross@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 03:48:31PM +0200, Juergen Gross wrote:
> We haven't used mini-os master for about 2 years now due to a stubdom
> test failing [1]. Booting a guest with mini-os master used for building
> stubdom didn't reveal any problem, so use master for unstable in order
> to let OSStest find any problems not showing up in the local test.
> 
> [1]: https://lists.xen.org/archives/html/minios-devel/2018-04/msg00015.html
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Acked-by: Wei Liu <wl@xen.org>

And applied.


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 20:22:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 20:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLukE-0006vX-O7; Tue, 07 Apr 2020 20:22:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=AwYI=5X=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jLukD-0006vS-Nk
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 20:22:49 +0000
X-Inumbo-ID: 8c689e86-790d-11ea-814e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8c689e86-790d-11ea-814e-12813bfff9fa;
 Tue, 07 Apr 2020 20:22:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=9cb0Ngob3m4Rf98EgXfN468qBc1kGCEo4ujhwcMP7iA=; b=idLaRNiukHqqeA46NJGDlGWTI9
 6FOFhV89kw4u2OEJIk4TvHSciHo5a0G1BigVtjNSg3Pq5d4TPUlvXBPj6Z3h89dbeEIIaUr3Wl6wv
 kHsHqih+V5Q3jwcWxWliOwOlRwGrAxpxW4X4o6E/8jXomdlbdooYevqIeCkyyeLMTcUc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jLukB-0003fI-ER; Tue, 07 Apr 2020 20:22:47 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jLukB-0001YH-5D; Tue, 07 Apr 2020 20:22:47 +0000
Date: Tue, 7 Apr 2020 21:22:44 +0100
From: Wei Liu <wl@xen.org>
To: Andrew Panyakin <apanyaki@amazon.com>
Subject: Re: [XEN PATCH] libxc/migration: Abort migration on precopy policy
 request
Message-ID: <20200407202244.a6isag63njejbshe@debian>
References: <eb85d7fee920b54eea3b4c0e77ab40593613ccc4.1586270820.git.apanyaki@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <eb85d7fee920b54eea3b4c0e77ab40593613ccc4.1586270820.git.apanyaki@amazon.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org,
 David Woodhouse <dwmw@amazon.co.uk>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 02:52:22PM +0000, Andrew Panyakin wrote:
> libxc defines XGS_POLICY_ABORT for precopy policy to signal that migration
> should be aborted (eg. if the estimated pause time is too huge for the
> instance). Default simple precopy policy never returns that, but it could be
> overriden with a custom one.
> 

Right. I think this is a real problem.

> Signed-off-by: Andrew Panyakin <apanyaki@amazon.com>
> ---
>  tools/libxc/xc_sr_save.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
> index fa736a311f..507274ce22 100644
> --- a/tools/libxc/xc_sr_save.c
> +++ b/tools/libxc/xc_sr_save.c
> @@ -560,6 +560,12 @@ static int send_memory_live(struct xc_sr_context *ctx)
>  
>      }
>  
> +    if ( policy_decision == XGS_POLICY_ABORT ) {

The { should be on a new line.

> +        PERROR("Abort precopy loop");
> +        rc = -1;
> +        goto out;

There is no need to have "goto out" here.

These can be fixed easily while committing, so no need to resend yet. I
will give other people a chance to comment.

Wei.

> +    }
> +
>   out:
>      xc_set_progress_prefix(xch, NULL);
>      free(progress_str);
> -- 
> 2.16.6
> 


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 21:12:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 21:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLvVj-0002Vx-OB; Tue, 07 Apr 2020 21:11:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8HNH=5X=linaro.org=peter.maydell@srs-us1.protection.inumbo.net>)
 id 1jLvVi-0002Vr-KG
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 21:11:54 +0000
X-Inumbo-ID: 67c1155c-7914-11ea-b4f4-bc764e2007e4
Received: from mail-ot1-x32f.google.com (unknown [2607:f8b0:4864:20::32f])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 67c1155c-7914-11ea-b4f4-bc764e2007e4;
 Tue, 07 Apr 2020 21:11:53 +0000 (UTC)
Received: by mail-ot1-x32f.google.com with SMTP id n25so2052715otr.10
 for <xen-devel@lists.xenproject.org>; Tue, 07 Apr 2020 14:11:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=ZF78cAxWWyzqoXTU57AUohvpqTrNrT5K78HteKJY98g=;
 b=Abpe3g/XjHufKxAYzAHWMa2yguPVjhOXtPxlarHEZwrc4Ceihfvccx2aYmQCbktruP
 32YSqkqrLSCBy6t7um29EcfPP654DmlBoW6B0zFTAfcy0C+P6mHIL0OBDbykPwe/0bO9
 PEOyesXhHpMO36MaOSp99yE3Nu8d1fkFRxV50RmUL8S0Ve++VCylWKGQESECLF//E5dE
 JCLht8f16xE3mgOqfCgR+h4Icg1W/GsNlbkQGlmTism8/1q85iwjLf/Nk9kjbWhDbqoR
 mkYPUlkUNXGhajvbmJE+meWbMxx/xmumuMuSAKA1pvThyVBRp2+6jgdlnKBjMrh2BGiw
 X3eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=ZF78cAxWWyzqoXTU57AUohvpqTrNrT5K78HteKJY98g=;
 b=oos1x8nptau3M6rpbBxrKZX64Rg4FOhfrHDW8MPPUzi3F81Wj84oVF7qoqGrXafZIz
 67LpO+dWF8jWQcW0Z7mXM9vKyjJgJGwAnFvI4g+HWALRNx5DwS/zi5QEok8BlF7pqvtr
 d3mqG95DFlFhj/97j4+RtYsoHp/7m2FqZ6tUnyVZRc+O8E1x+/ReYFjnzbJEDmDrb6ss
 ZmHY9yYPYLHbNtEuBpGx3/BOnRkKr7OPaGKg78KMRNCO6Sw6xl3feZqlaAR3QyRjwHQv
 F7YQ6Vn7KKbUn3GLesumXs2MRUMY3zVCc7l170SuKU5VOW4oDCavmNPGYMkF3CKtZTOI
 C9Sg==
X-Gm-Message-State: AGi0Pub6mrNl8qKzSvaIDKVODbWvaqCzZjaihQhq0VluhJwFam4jYrlw
 VIDPXek4S09srLE7Qv6hwuYFyefRUREUY9oiVorNgjc3Ejw=
X-Google-Smtp-Source: APiQypK8p6e6oM4bpyu/uq9uLFkMMODhc7LrF7Sg8rUqfqaF21YfXZCCzSxtcqu/buWJ1G7TPmlNVgUf2sPmml9fEKo=
X-Received: by 2002:a05:6830:11d5:: with SMTP id
 v21mr3289337otq.91.1586293913150; 
 Tue, 07 Apr 2020 14:11:53 -0700 (PDT)
MIME-Version: 1.0
References: <20200407152237.1468704-1-anthony.perard@citrix.com>
In-Reply-To: <20200407152237.1468704-1-anthony.perard@citrix.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 7 Apr 2020 22:11:42 +0100
Message-ID: <CAFEAcA_q7hN90Y4FgnmzJvvc=pmyb-Fi-zCHz-Z7phu1KOsW=w@mail.gmail.com>
Subject: Re: [PULL 0/3] xen queue for 5.0
To: Anthony PERARD <anthony.perard@citrix.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "open list:X86" <xen-devel@lists.xenproject.org>,
 QEMU Developers <qemu-devel@nongnu.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, 7 Apr 2020 at 16:22, Anthony PERARD <anthony.perard@citrix.com> wrote:
>
> The following changes since commit 8f0d25c464a1989d606f7b988d07b1147dfcde33:
>
>   Merge remote-tracking branch 'remotes/philmd-gitlab/tags/acceptance-fixes-20200407' into staging (2020-04-07 15:10:11 +0100)
>
> are available in the Git repository at:
>
>   https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git tags/pull-xen-20200407
>
> for you to fetch changes up to 758af9cfabfb000eb00e42b9738e655b18fdd812:
>
>   MAINTAINERS: Add xen-usb.c to Xen section (2020-04-07 16:13:26 +0100)
>
> ----------------------------------------------------------------
> Xen queue for QEMU 5.0
>
> - Fix for xen-block.
> - A fix for a Coverity false positive in xen-usb.
> - Update MAINTAINERS to add xen-usb.c to Xen section.
>

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/5.0
for any user-visible changes.

-- PMM


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 22:06:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 22:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLwMr-0006b7-3F; Tue, 07 Apr 2020 22:06:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=A3/I=5X=amazon.com=prvs=3592f0f2d=apanyaki@srs-us1.protection.inumbo.net>)
 id 1jLwMp-0006aa-27
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 22:06:47 +0000
X-Inumbo-ID: 1241670a-791c-11ea-83d8-bc764e2007e4
Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1241670a-791c-11ea-83d8-bc764e2007e4;
 Tue, 07 Apr 2020 22:06:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586297206; x=1617833206;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=7lrS4ajv1ecolBDc1hjRWYWeZ/nLCJnkPuqNmCNTG4g=;
 b=aej6GlYkko6QsU/1+zf5URdhTaAy5NkeMKcfGWVLPwLBPhSVccuc1HNB
 Fd7A7YMYZY5pXH/z8XNwwCp0Ql0x4aq+wR1v5ebC969xq+tzri0g/DoE5
 FWqUs5+hWEobiBKeVQBolhRuCSeyDsLg1NKYkLoc17cv8letviuQXTRQh A=;
IronPort-SDR: WH6IT/k2I5+/psCkfUs0vAztv23ZN1gzg4bcBMx8bO7xc1huGXDwfeIKHZRwwtcY9IrK0OV6tR
 fvLxN8RsjMIw==
X-IronPort-AV: E=Sophos;i="5.72,356,1580774400"; d="scan'208";a="35840602"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-1a-67b371d8.us-east-1.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP;
 07 Apr 2020 22:06:45 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166])
 by email-inbound-relay-1a-67b371d8.us-east-1.amazon.com (Postfix) with ESMTPS
 id 2C7D6A2A59; Tue,  7 Apr 2020 22:06:43 +0000 (UTC)
Received: from EX13D26EUB002.ant.amazon.com (10.43.166.9) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 7 Apr 2020 22:06:43 +0000
Received: from 38f9d35285e8.ant.amazon.com (10.43.162.171) by
 EX13D26EUB002.ant.amazon.com (10.43.166.9) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 7 Apr 2020 22:06:39 +0000
Subject: Re: [XEN PATCH] libxc/migration: Abort migration on precopy policy
 request
To: Wei Liu <wl@xen.org>
References: <eb85d7fee920b54eea3b4c0e77ab40593613ccc4.1586270820.git.apanyaki@amazon.com>
 <20200407202244.a6isag63njejbshe@debian>
From: "Panyakin, Andrew" <apanyaki@amazon.com>
Message-ID: <9930fbd5-10f7-5f92-348b-8856ecad3768@amazon.com>
Date: Wed, 8 Apr 2020 00:06:22 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200407202244.a6isag63njejbshe@debian>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.43.162.171]
X-ClientProxiedBy: EX13D18UWC003.ant.amazon.com (10.43.162.237) To
 EX13D26EUB002.ant.amazon.com (10.43.166.9)
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Andrew
 Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 David Woodhouse <dwmw@amazon.co.uk>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/7/20 10:22 PM, Wei Liu wrote:
> On Tue, Apr 07, 2020 at 02:52:22PM +0000, Andrew Panyakin wrote:
>> libxc defines XGS_POLICY_ABORT for precopy policy to signal that migration
>> should be aborted (eg. if the estimated pause time is too huge for the
>> instance). Default simple precopy policy never returns that, but it could be
>> overriden with a custom one.
>>
> 
> Right. I think this is a real problem.
> 
>> Signed-off-by: Andrew Panyakin <apanyaki@amazon.com>
>> ---
>>  tools/libxc/xc_sr_save.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
>> index fa736a311f..507274ce22 100644
>> --- a/tools/libxc/xc_sr_save.c
>> +++ b/tools/libxc/xc_sr_save.c
>> @@ -560,6 +560,12 @@ static int send_memory_live(struct xc_sr_context *ctx)
>>
>>      }
>>
>> +    if ( policy_decision == XGS_POLICY_ABORT ) {
> 
> The { should be on a new line.
> 
>> +        PERROR("Abort precopy loop");
>> +        rc = -1;
>> +        goto out;
> 
> There is no need to have "goto out" here.

I was considering two more examples of "goto out" in a branch right before the label:
- send_domain_memory_nonlive,
- send_domain_memory_live.

Isn't it done this way to simplify the function extension: you won't need to add "goto out" to previous branch when adding new code?

> 
> These can be fixed easily while committing, so no need to resend yet. I
> will give other people a chance to comment.
> 
> Wei.
> 
>> +    }
>> +
>>   out:
>>      xc_set_progress_prefix(xch, NULL);
>>      free(progress_str);
>> --
>> 2.16.6
>>


-- 
Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 22:25:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 22:25:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLwed-0008EA-NR; Tue, 07 Apr 2020 22:25:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+Iuu=5X=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jLwec-0008E4-P7
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 22:25:10 +0000
X-Inumbo-ID: a36c727c-791e-11ea-8176-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a36c727c-791e-11ea-8176-12813bfff9fa;
 Tue, 07 Apr 2020 22:25:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586298309;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=MnvuEYljmUlFky9bY4yxK7vaoBPZmfAm1/NLaWhCGh8=;
 b=QiUk16lZbip9/LnCrkAmrdfZuDIckGWCStPzheUDc1Ir8cNdUnCqaoky
 A0ShtDclNoOrWFeFDZUU1cIU1RIuYcIzQ1zjlSZPuGaBxvovdPhyG/VXe
 VPzcAR+I9C2MpMXl7ocAugguzvA89xjVFsWCyDQXPYRgX1tZplK7vNMP2 c=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: VpzEnEWIvdt5N2mSJbBl/phfDdz2QszAmsfopVtK8/lP8A8/Yysu33YhwERgxXW0npxRRjQsQ5
 2bRUk7Prw0n/7s/F5GS2pobjd2qKkH/mj4ITBpdOz7xXloGgWLkKzDn6DQ/hfJyNY43rq66yZI
 mJgtqxQ5n1Fqee3/5TIGAk5bSh6xoM6Wgzp9TA3cy/HPwrb+nvMkuxzCjr+dognnrmx+1L1KJu
 HTxjotI5dmsmeOvacDWRJ4nuYvz+pNWv06icPqrI31XNrLUlIowjezKzQ4jepQlruOpMyriA+3
 etU=
X-SBRS: 2.7
X-MesageID: 15345650
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,356,1580792400"; d="scan'208";a="15345650"
Subject: Re: [XEN PATCH] libxc/migration: Abort migration on precopy policy
 request
To: "Panyakin, Andrew" <apanyaki@amazon.com>, Wei Liu <wl@xen.org>
References: <eb85d7fee920b54eea3b4c0e77ab40593613ccc4.1586270820.git.apanyaki@amazon.com>
 <20200407202244.a6isag63njejbshe@debian>
 <9930fbd5-10f7-5f92-348b-8856ecad3768@amazon.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <17a92041-8639-2e4a-3d68-f77bd040b080@citrix.com>
Date: Tue, 7 Apr 2020 23:25:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <9930fbd5-10f7-5f92-348b-8856ecad3768@amazon.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Ian Jackson <ian.jackson@eu.citrix.com>,
 David Woodhouse <dwmw@amazon.co.uk>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07/04/2020 23:06, Panyakin, Andrew wrote:
> On 4/7/20 10:22 PM, Wei Liu wrote:
>>> +        PERROR("Abort precopy loop");
>>> +        rc = -1;
>>> +        goto out;
>> There is no need to have "goto out" here.
> I was considering two more examples of "goto out" in a branch right before the label:
> - send_domain_memory_nonlive,
> - send_domain_memory_live.
>
> Isn't it done this way to simplify the function extension: you won't need to add "goto out" to previous branch when adding new code?

I'd recommend leaving the goto out like this.  Less effort for the next
person editing this code to think about.

>> These can be fixed easily while committing, so no need to resend yet. I
>> will give other people a chance to comment.

None of the copy policy was done well.  If Amazon have a usecase then
lets put it in.  (Talking of - I wonder why XenServer's usecase hasn't
tripped over this...  This was put into to help negotiate two live
streams at once, but this is an error case which surely ought to trigger.)

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 07 23:56:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Apr 2020 23:56:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLy4I-000727-Ov; Tue, 07 Apr 2020 23:55:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=VNrn=5X=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLy4H-000722-Li
 for xen-devel@lists.xenproject.org; Tue, 07 Apr 2020 23:55:45 +0000
X-Inumbo-ID: 4bae7604-792b-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4bae7604-792b-11ea-b58d-bc764e2007e4;
 Tue, 07 Apr 2020 23:55:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=m7giRba655q+XtrZ8FFXEk5Oe8f1DWPh9bqUXuxRvps=; b=S/UvMQCfGZXSSsk8c92qkQ07p
 2NBHyleA7A2UlKqkmhajyVVqMD1mwos23khcvl9uk9W85XBmGiCWwBba5Svxqj/QnLkwQHp0KhBEf
 +Lv4kTsyi/30wwmqtI7EwM5/LzWYkJSFlw99je9ojXm8A+Bv6IxlbrIDSaLBrEH2Ms/LQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLy4G-0007ms-Lf; Tue, 07 Apr 2020 23:55:44 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLy4G-0007AE-CS; Tue, 07 Apr 2020 23:55:44 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLy4G-0007mS-Bp; Tue, 07 Apr 2020 23:55:44 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149499-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149499: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=e013e8514389b739153016349e49f5a78e34ddf0
X-Osstest-Versions-That: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 07 Apr 2020 23:55:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  e013e8514389b739153016349e49f5a78e34ddf0
baseline version:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd

Last test of basis   149401  2020-04-03 20:00:45 Z    4 days
Testing same since   149499  2020-04-07 21:00:41 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Juergen Gross <jgross@suse.com>
  Wei Liu <wl@xen.org>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   990b6e38d9..e013e85143  e013e8514389b739153016349e49f5a78e34ddf0 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 00:50:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 00:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jLyva-0004Jg-Qt; Wed, 08 Apr 2020 00:50:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jLyva-0004Jb-Da
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 00:50:50 +0000
X-Inumbo-ID: fa3aff4c-7932-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fa3aff4c-7932-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 00:50:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=dNGISrm2DnCZXxHE3tLFZttm6VtKdVKjj0McHGy6+XM=; b=15A1/e7b3mnBUVIxQ3go6RS2J
 w8cYUrX9L4LFzzSApLEx0QJ1VQ0E8z95+5QBBX7UJROCOWl1LYZPwibBRa8QS/efscSUAhRffKKMM
 TF7b/C7qQ1MkMmG04osmi4vOaWTKyxH1WVNQEvVLChLRc8cVXYI5ChseY5gct7F6/nmvw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLyvT-0000zk-4W; Wed, 08 Apr 2020 00:50:43 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jLyvS-0008RI-JO; Wed, 08 Apr 2020 00:50:42 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jLyvS-00083K-Ie; Wed, 08 Apr 2020 00:50:42 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149497-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149497: all pass - PUSHED
X-Osstest-Versions-This: ovmf=9bb1f080c45f7253f9270662d55865a8718cebc8
X-Osstest-Versions-That: ovmf=aab6a9c9aebb1f6614e72e98bdf6b5af93a43527
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 00:50:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 9bb1f080c45f7253f9270662d55865a8718cebc8
baseline version:
 ovmf                 aab6a9c9aebb1f6614e72e98bdf6b5af93a43527

Last test of basis   149485  2020-04-07 08:40:39 Z    0 days
Testing same since   149497  2020-04-07 19:10:25 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Michael Kubacki <michael.kubacki@microsoft.com>
  Sean Brogan <sean.brogan@microsoft.com>
  Shenglei Zhang <shenglei.zhang@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   aab6a9c9ae..9bb1f080c4  9bb1f080c45f7253f9270662d55865a8718cebc8 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 02:35:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 02:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM0YF-0006xT-Ry; Wed, 08 Apr 2020 02:34:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jM0YF-0006xO-Fm
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 02:34:51 +0000
X-Inumbo-ID: 8490dd70-7941-11ea-81aa-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8490dd70-7941-11ea-81aa-12813bfff9fa;
 Wed, 08 Apr 2020 02:34:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=RmQpnY7/7onJrEoeMjerbrP1TdawDhEPYVhKph6WOpI=; b=hIEYSUmh1/ZPGvaZXTCl9Uv+G
 9sETsf21/H84aXMs/Ln8Pux6cAToVixEMoTk8By+fDW2U1h7OFxtbN3oow6oQOImukZr+8a2ICSE8
 QL7BPsJqQXwoa22PXyGZprC5Wh0m5x5yPfLNBFgNGSp5Xmet3zQ0wYz6iWUCjqnR1HyN0=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM0YC-0007tB-Th; Wed, 08 Apr 2020 02:34:48 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM0YC-0003Fb-Ht; Wed, 08 Apr 2020 02:34:48 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jM0YC-0001HU-Gv; Wed, 08 Apr 2020 02:34:48 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149480-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149480: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-examine:reboot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-raw:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 linux-linus:test-armhf-armhf-xl-rtds:guest-start:fail:allowable
 linux-linus:test-amd64-amd64-dom0pvh-xl-intel:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=7e63420847ae5f1036e4f7c42f0b3282e73efbc2
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 02:34:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-pvshim     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-examine       8 reboot                   fail REGR. vs. 149238
 test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-shadow     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-libvirt-xsm   7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-libvirt       7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl            7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-raw        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-xsm        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-freebsd10-i386  7 xen-boot               fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-pair         10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-pair         11 xen-boot/dst_host        fail REGR. vs. 149238

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149238
 test-armhf-armhf-xl-rtds     12 guest-start              fail REGR. vs. 149238

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 15 guest-saverestore        fail like 149238
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149238
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                7e63420847ae5f1036e4f7c42f0b3282e73efbc2
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    7 days
Failing since        149266  2020-04-01 03:55:53 Z    6 days    9 attempts
Testing same since   149480  2020-04-07 03:08:07 Z    0 days    1 attempts

------------------------------------------------------------
1657 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       fail    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-dom0pvh-xl-intel                            fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       fail    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    fail    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 04:54:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 04:54:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2ip-0001Or-NS; Wed, 08 Apr 2020 04:53:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jM2io-0001Om-93
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 04:53:54 +0000
X-Inumbo-ID: f0a8f5f2-7954-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f0a8f5f2-7954-11ea-9e09-bc764e2007e4;
 Wed, 08 Apr 2020 04:53:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=N73ufXxP6MmJH01eIHOqCMasTtmqXZoIdmgB280zBM4=; b=okTKL8M7W0wYnbmdm2KPNr79k
 QuzodjVt0JLjQR71qR342n7F/sxNQtooMwncMywP3RdndL4GcgMlVS9p1J7ZzX3QiPv6KypQTtYg8
 EnI2WjKxc/IrQhutZByanZtI5bkLyNCMLVQqpYM4Egueer+5biwompEFbvCPux/8KIAcU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM2ik-0002Cn-Ol; Wed, 08 Apr 2020 04:53:50 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM2ik-0005Cj-BI; Wed, 08 Apr 2020 04:53:50 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jM2ik-0003Fy-Ad; Wed, 08 Apr 2020 04:53:50 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149487-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149487: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression
 qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression
 qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression
 qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression
 qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression
 qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 qemu-mainline:test-amd64-amd64-dom0pvh-xl-intel:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=53ef8a92eb04ee19640f5aad3bff36cd4a36c250
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 04:53:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 144861
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install     fail REGR. vs. 144861
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt-pair 21 guest-start/debian       fail REGR. vs. 144861
 test-amd64-amd64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-libvirt      12 guest-start              fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-libvirt-pair 21 guest-start/debian      fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 144861
 test-amd64-i386-libvirt-xsm  12 guest-start              fail REGR. vs. 144861
 test-armhf-armhf-libvirt     12 guest-start              fail REGR. vs. 144861
 test-arm64-arm64-libvirt-xsm 12 guest-start              fail REGR. vs. 144861
 test-amd64-amd64-libvirt-vhd 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-xl-vhd      10 debian-di-install        fail REGR. vs. 144861
 test-armhf-armhf-libvirt-raw 10 debian-di-install        fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 144861

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds   16 guest-localmigrate fail in 149475 pass in 149487
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149475

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail in 149475 baseline untested
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 144861
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass

version targeted for testing:
 qemuu                53ef8a92eb04ee19640f5aad3bff36cd4a36c250
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  113 days
Failing since        144880  2019-12-16 20:07:08 Z  113 days  325 attempts
Testing same since   149475  2020-04-07 00:07:23 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Elazar Leibovich <elazar.leibovich@oracle.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Liran Alon <liran.alon@oracle.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Luwei Kang <luwei.kang@intel.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Bolshakov <r.bolshakov@yadro.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           fail    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 fail    
 test-arm64-arm64-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 fail    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 57203 lines long.)


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2tw-0002cx-8z; Wed, 08 Apr 2020 05:05:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2tv-0002cp-6F
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:23 +0000
X-Inumbo-ID: 8c4f2958-7956-11ea-81bb-12813bfff9fa
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8c4f2958-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:22 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 038548DP191274;
 Wed, 8 Apr 2020 05:05:11 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=vzLY3W6pyhiry0YbTLA6k/8Hm1Z7yOv34dOpb5FTaTE=;
 b=qr0UjqR9noiEapG/2uGPeaa+qlAvFcUPOv8/v5srmCWNf6Yyqwn4Y3EB8vYUlynBtqLi
 PnTYirPsZIADmW/KoizPSQxBfFMySPcOBhJ1chkvIMKvwRawLUlqwDxtB+tTKShD0qN7
 3+Hw2lIB85sESp0QzrA82nr8Wvaf6+wQbp9gvzSxL6Qf/bdDYRNNkgZvjUVrzkq4EJig
 w2JpoTyPnomhqeeIc5Gz5M0R6v5ChJwHobiL/5/HGKRS2d8je9idVLQY8gye0GyaFN87
 njqBnrlrHSu8VZsQUMb/oY1mmXNw96ID+tuzQ0VkP+zaev/YJKYafcRfJBuiiP/GxNOR /Q== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by aserp2120.oracle.com with ESMTP id 3091m0s0s6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:10 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852Yjo062439;
 Wed, 8 Apr 2020 05:05:10 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])
 by userp3020.oracle.com with ESMTP id 3091mh1kg9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:10 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0385589q022152;
 Wed, 8 Apr 2020 05:05:08 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:08 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 08/26] x86/paravirt: Stash native pv-ops
Date: Tue,  7 Apr 2020 22:03:05 -0700
Message-Id: <20200408050323.4237-9-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 suspectscore=0 bulkscore=0
 mlxlogscore=986 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Introduce native_pv_ops where we stash the pv_ops array before
hypervisor specific hooks have modified it.

native_pv_ops get used when switching between paravirt and native
pv-ops at runtime.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/paravirt_types.h |  4 ++++
 arch/x86/kernel/paravirt.c            | 10 ++++++++++
 arch/x86/kernel/setup.c               |  2 ++
 3 files changed, 16 insertions(+)

diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index f1153f53c529..bc935eec7ec6 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -339,6 +339,7 @@ extern struct paravirt_patch_template pv_ops;
 
 #ifdef CONFIG_PARAVIRT_RUNTIME
 #define PVRT_SUFFIX ".runtime"
+extern struct paravirt_patch_template native_pv_ops;
 #else
 #define PVRT_SUFFIX ""
 #endif
@@ -775,6 +776,9 @@ extern struct paravirt_patch_site __parainstructions[],
 #ifdef CONFIG_PARAVIRT_RUNTIME
 extern struct paravirt_patch_site __parainstructions_runtime[],
 	__parainstructions_runtime_end[];
+void paravirt_ops_init(void);
+#else
+static inline void paravirt_ops_init(void) { }
 #endif
 
 #endif	/* __ASSEMBLY__ */
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index c131ba4e70ef..8c511cc4d4f4 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -458,5 +458,15 @@ NOKPROBE_SYMBOL(native_set_debugreg);
 NOKPROBE_SYMBOL(native_load_idt);
 #endif
 
+#ifdef CONFIG_PARAVIRT_RUNTIME
+__ro_after_init struct paravirt_patch_template native_pv_ops;
+
+void __init paravirt_ops_init(void)
+{
+	native_pv_ops = pv_ops;
+}
+EXPORT_SYMBOL(native_pv_ops);
+#endif
+
 EXPORT_SYMBOL(pv_ops);
 EXPORT_SYMBOL_GPL(pv_info);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e6b545047f38..2746a6a78fe7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -43,6 +43,7 @@
 #include <asm/unwind.h>
 #include <asm/vsyscall.h>
 #include <linux/vmalloc.h>
+#include <asm/paravirt_types.h>
 
 /*
  * max_low_pfn_mapped: highest directly mapped pfn < 4 GB
@@ -831,6 +832,7 @@ void __init setup_arch(char **cmdline_p)
 	boot_cpu_data.x86_phys_bits = MAX_PHYSMEM_BITS;
 #endif
 
+	paravirt_ops_init();
 	/*
 	 * If we have OLPC OFW, we might end up relocating the fixmap due to
 	 * reserve_top(), so do this before touching the ioremap area.
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2tv-0002cm-08; Wed, 08 Apr 2020 05:05:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2tu-0002ch-MX
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:22 +0000
X-Inumbo-ID: 8c093cfe-7956-11ea-b4f4-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8c093cfe-7956-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 05:05:21 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853ldR191183;
 Wed, 8 Apr 2020 05:05:06 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=9tI0JiEef8to344a69A5BaCsrTLQkt/TJVKmTnFs63o=;
 b=cymcX7cssNqc00recnMFSS2WRHjmFb+WkYX/rdlb2DTEEo/1m5i0n7hDKVgpoqne9dgn
 qV1fq5CSllni2nW8Do8aEIZhVjZ8agzgViY1rUV1JF5H+iB6BJ3DhfFb/tj85Neao/JM
 UbaVGFXzb3MRcA0skHvewC8LLUGflolD4ki3Io32ZblIdAcM/dOjL0uK+npq1AsJQpiv
 PSoqZvsLMGnuFEHxqgAokUGAbjWncy15IVg27Xwes+Gn1YoKQe/F9sRwPfea2sYw8xQa
 0v3LPO37oQizGXncjiBA6XzhmWHHck7+6W6fBNpbaWygDfMk5OaOnmcap0yxwdwkaxkI RA== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by aserp2120.oracle.com with ESMTP id 3091m0s0ru-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:06 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852XvD062260;
 Wed, 8 Apr 2020 05:05:06 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userp3020.oracle.com with ESMTP id 3091mh1kc5-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:05 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 038554hD007324;
 Wed, 8 Apr 2020 05:05:04 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:04 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 05/26] x86/alternatives: Rename alternatives_smp*,
 smp_alt_module
Date: Tue,  7 Apr 2020 22:03:02 -0700
Message-Id: <20200408050323.4237-6-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 suspectscore=2 bulkscore=0
 mlxlogscore=999 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=2 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Rename alternatives_smp_module_*(), smp_alt_module to reflect
their new purpose.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/alternative.h | 10 +++---
 arch/x86/kernel/alternative.c      | 54 +++++++++++++++---------------
 arch/x86/kernel/module.c           |  8 ++---
 3 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
index 8235bbb746d9..db91a7731d87 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -75,11 +75,11 @@ extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
 
 struct module;
 
-extern void alternatives_smp_module_add(struct module *mod, char *name,
-					void *locks, void *locks_end,
-					void *text, void *text_end);
-extern void alternatives_smp_module_del(struct module *mod);
-extern int alternatives_text_reserved(void *start, void *end);
+void alternatives_module_add(struct module *mod, char *name,
+			     void *locks, void *locks_end,
+			     void *text, void *text_end);
+void alternatives_module_del(struct module *mod);
+int alternatives_text_reserved(void *start, void *end);
 #ifdef CONFIG_SMP
 extern void alternatives_enable_smp(void);
 #else
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 32aa1ddf441d..4157f848b537 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -477,7 +477,7 @@ static inline void alternatives_smp_unlock(const s32 *start, const s32 *end,
 					   u8 *text, u8 *text_end) { }
 #endif	/* CONFIG_SMP */
 
-struct smp_alt_module {
+struct alt_module {
 	/* what is this ??? */
 	struct module	*mod;
 	char		*name;
@@ -492,14 +492,14 @@ struct smp_alt_module {
 
 	struct list_head next;
 };
-static LIST_HEAD(smp_alt_modules);
 
-void __init_or_module alternatives_smp_module_add(struct module *mod,
-						  char *name,
-						  void *locks, void *locks_end,
-						  void *text,  void *text_end)
+static LIST_HEAD(alt_modules);
+
+void __init_or_module alternatives_module_add(struct module *mod, char *name,
+					      void *locks, void *locks_end,
+					      void *text,  void *text_end)
 {
-	struct smp_alt_module *smp;
+	struct alt_module *alt;
 
 #ifdef CONFIG_SMP
 	/* Patch to UP if other cpus not imminent. */
@@ -511,36 +511,36 @@ void __init_or_module alternatives_smp_module_add(struct module *mod,
 
 	mutex_lock(&text_mutex);
 
-	smp = kzalloc(sizeof(*smp), GFP_KERNEL | __GFP_NOFAIL);
+	alt = kzalloc(sizeof(*alt), GFP_KERNEL | __GFP_NOFAIL);
 
-	smp->mod	= mod;
-	smp->name	= name;
+	alt->mod	= mod;
+	alt->name	= name;
 
 	if (num_possible_cpus() != 1 || uniproc_patched) {
 		/* Remember only if we'll need to undo it. */
-		smp->locks	= locks;
-		smp->locks_end	= locks_end;
+		alt->locks	= locks;
+		alt->locks_end	= locks_end;
 	}
 
-	smp->text	= text;
-	smp->text_end	= text_end;
+	alt->text	= text;
+	alt->text_end	= text_end;
 	DPRINTK("locks %p -> %p, text %p -> %p, name %s\n",
-		smp->locks, smp->locks_end,
-		smp->text, smp->text_end, smp->name);
+		alt->locks, alt->locks_end,
+		alt->text, alt->text_end, alt->name);
 
-	list_add_tail(&smp->next, &smp_alt_modules);
+	list_add_tail(&alt->next, &alt_modules);
 
 	if (uniproc_patched)
 		alternatives_smp_unlock(locks, locks_end, text, text_end);
 	mutex_unlock(&text_mutex);
 }
 
-void __init_or_module alternatives_smp_module_del(struct module *mod)
+void __init_or_module alternatives_module_del(struct module *mod)
 {
-	struct smp_alt_module *item;
+	struct alt_module *item;
 
 	mutex_lock(&text_mutex);
-	list_for_each_entry(item, &smp_alt_modules, next) {
+	list_for_each_entry(item, &alt_modules, next) {
 		if (mod != item->mod)
 			continue;
 		list_del(&item->next);
@@ -553,7 +553,7 @@ void __init_or_module alternatives_smp_module_del(struct module *mod)
 #ifdef CONFIG_SMP
 void alternatives_enable_smp(void)
 {
-	struct smp_alt_module *mod;
+	struct alt_module *mod;
 
 	/* Why bother if there are no other CPUs? */
 	BUG_ON(num_possible_cpus() == 1);
@@ -565,7 +565,7 @@ void alternatives_enable_smp(void)
 		BUG_ON(num_online_cpus() != 1);
 		clear_cpu_cap(&boot_cpu_data, X86_FEATURE_UP);
 		clear_cpu_cap(&cpu_data(0), X86_FEATURE_UP);
-		list_for_each_entry(mod, &smp_alt_modules, next)
+		list_for_each_entry(mod, &alt_modules, next)
 			alternatives_smp_lock(mod->locks, mod->locks_end,
 					      mod->text, mod->text_end);
 		uniproc_patched = false;
@@ -580,14 +580,14 @@ void alternatives_enable_smp(void)
  */
 int alternatives_text_reserved(void *start, void *end)
 {
-	struct smp_alt_module *mod;
+	struct alt_module *mod;
 	const s32 *poff;
 	u8 *text_start = start;
 	u8 *text_end = end;
 
 	lockdep_assert_held(&text_mutex);
 
-	list_for_each_entry(mod, &smp_alt_modules, next) {
+	list_for_each_entry(mod, &alt_modules, next) {
 		if (mod->text > text_end || mod->text_end < text_start)
 			continue;
 		for (poff = mod->locks; poff < mod->locks_end; poff++) {
@@ -734,9 +734,9 @@ void __init alternative_instructions(void)
 
 	apply_alternatives(__alt_instructions, __alt_instructions_end);
 
-	alternatives_smp_module_add(NULL, "core kernel",
-				    __smp_locks, __smp_locks_end,
-				    _text, _etext);
+	alternatives_module_add(NULL, "core kernel",
+				__smp_locks, __smp_locks_end,
+				_text, _etext);
 
 	if (!uniproc_patched || num_possible_cpus() == 1) {
 		free_init_pages("SMP alternatives",
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 658ea60ce324..fc3d35198b09 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -251,9 +251,9 @@ int module_finalize(const Elf_Ehdr *hdr,
 	if (locks && text) {
 		void *lseg = (void *)locks->sh_addr;
 		void *tseg = (void *)text->sh_addr;
-		alternatives_smp_module_add(me, me->name,
-					    lseg, lseg + locks->sh_size,
-					    tseg, tseg + text->sh_size);
+		alternatives_module_add(me, me->name,
+					lseg, lseg + locks->sh_size,
+					tseg, tseg + text->sh_size);
 	}
 
 	if (para) {
@@ -278,5 +278,5 @@ int module_finalize(const Elf_Ehdr *hdr,
 
 void module_arch_cleanup(struct module *mod)
 {
-	alternatives_smp_module_del(mod);
+	alternatives_module_del(mod);
 }
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2u0-0002dr-HM; Wed, 08 Apr 2020 05:05:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2tz-0002dK-HM
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:27 +0000
X-Inumbo-ID: 8c093e98-7956-11ea-9e09-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8c093e98-7956-11ea-9e09-bc764e2007e4;
 Wed, 08 Apr 2020 05:05:21 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853tXb191207;
 Wed, 8 Apr 2020 05:04:59 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : mime-version : content-transfer-encoding;
 s=corp-2020-01-29; bh=gEHA9nx+P2Ept/nnZJ17DEilIouWJcKCIoMOvLrgo7U=;
 b=dwADO76B6vyzwqtdoXeIlwaxqVZQMSnNBam+TctIiRToIoKUqiF9ff/rdW4nswrnoVXf
 LqtZc8ZIJwHi4WqQ1PtdUff0JHwT9kQYFrXeCqYTa1rT8hMAWktj0PlnQeX6fOYag+Vd
 pBe27mf8+o64sXWgrZAq8BnD3+13rAIDHPmp0MgUwnSNQsmWXbBv4i3lHAH1A3rg7HaO
 l6joM8aTubnbQd5fjWdUG1Wg0tBf58rERzrpIZmG7BWOWgmGRd4sTk/FUa1mGSZ4cdUh
 njagTvBUGP5DSwstjTEk6O80pHwZ2XAc1e9qsO9U8L5UoIYMhU87qlaORuwqdRFDatA/ Zw== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by aserp2120.oracle.com with ESMTP id 3091m0s0r9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:04:59 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03851Xb2100769;
 Wed, 8 Apr 2020 05:04:58 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by aserp3020.oracle.com with ESMTP id 3091m2hu00-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:04:58 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03854oaP015085;
 Wed, 8 Apr 2020 05:04:53 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:04:50 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 00/26] Runtime paravirt patching
Date: Tue,  7 Apr 2020 22:02:57 -0700
Message-Id: <20200408050323.4237-1-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 mlxscore=0
 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1011
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

A KVM host (or another hypervisor) might advertise paravirtualized
features and optimization hints (ex KVM_HINTS_REALTIME) which might
become stale over the lifetime of the guest. For instance, the
host might go from being undersubscribed to being oversubscribed
(or the other way round) and it would make sense for the guest
switch pv-ops based on that.

This lockorture splat that I saw on the guest while testing this is
indicative of the problem:

  [ 1136.461522] watchdog: BUG: soft lockup - CPU#8 stuck for 22s! [lock_torture_wr:12865]
  [ 1136.461542] CPU: 8 PID: 12865 Comm: lock_torture_wr Tainted: G W L 5.4.0-rc7+ #77
  [ 1136.461546] RIP: 0010:native_queued_spin_lock_slowpath+0x15/0x220

(Caused by an oversubscribed host but using mismatched native pv_lock_ops
on the gues.)

This series addresses the problem by doing paravirt switching at runtime.

We keep an interesting subset of pv-ops (pv_lock_ops only for now,
but PV-TLB ops are also good candidates) in .parainstructions.runtime,
while discarding the .parainstructions as usual at init. This is then
used for switching back and forth between native and paravirt mode.
([1] lists some representative numbers of the increased memory
footprint.)

Mechanism: the patching itself is done using stop_machine(). That is
not ideal -- text_poke_stop_machine() was replaced with INT3+emulation
via text_poke_bp(), but I'm using this to address two issues:
 1) emulation in text_poke() can only easily handle a small set
 of instructions and this is problematic for inlined pv-ops (and see
 a possible alternatives use-case below.)
 2) paravirt patching might have inter-dependendent ops (ex.
 lock.queued_lock_slowpath, lock.queued_lock_unlock are paired and
 need to be updated atomically.)

The alternative use-case is a runtime version of apply_alternatives()
(not posted with this patch-set) that can be used for some safe subset
of X86_FEATUREs. This could be useful in conjunction with the ongoing
late microcode loading work that Mihai Carabas and others have been
working on.

Also, there are points of similarity with the ongoing static_call work
which does rewriting of indirect calls. The difference here is that
we need to switch a group of calls atomically and given that
some of them can be inlined, need to handle a wider variety of opcodes.

To patch safely we need to satisfy these constraints:

 - No references to insn sequences under replacement on any kernel stack
   once replacement is in progress. Without this constraint we might end
   up returning to an address that is in the middle of an instruction.

 - handle inter-dependent ops: as above, lock.queued_lock_unlock(),
   lock.queued_lock_slowpath() and the rest of the pv_lock_ops are
   a good example.

 - handle a broader set of insns than CALL and JMP: some pv-ops end up
   getting inlined. Alternatives can contain arbitrary instructions.

 - locking operations can be called from interrupt handlers which means
   we cannot trivially use IPIs for flushing.

Handling these, necessitates that target pv-ops not be preemptible.
Once that is a given (for safety these need to be explicitly whitelisted
in runtime_patch()), use a state-machine with the primary CPU doing the
patching and secondary CPUs in a sync_core() loop. 

In case we hit an INT3/BP (in NMI or thread-context) we makes forward
progress by continuing the patching instead of emulating.

One remaining issue is inter-dependent pv-ops which are also executed in
the NMI handler -- patching can potentially deadlock in case of multiple
NMIs. Handle these by pushing some of this work in the NMI handler where
we know it will be uninterrupted.

There are four main sets of patches in this series:

 1. PV-ops management (patches 1-10, 20): mostly infrastructure and
 refactoring pieces to make paravirt patching usable at runtime. For the
 most part scoped under CONFIG_PARAVIRT_RUNTIME.

 Patches 1-7, to persist part of parainstructions in memory:
  "x86/paravirt: Specify subsection in PVOP macros"
  "x86/paravirt: Allow paravirt patching post-init"
  "x86/paravirt: PVRTOP macros for PARAVIRT_RUNTIME"
  "x86/alternatives: Refactor alternatives_smp_module*
  "x86/alternatives: Rename alternatives_smp*, smp_alt_module
  "x86/alternatives: Remove stale symbols
  "x86/paravirt: Persist .parainstructions.runtime"

 Patches 8-10, develop the inerfaces to safely switch pv-ops:
  "x86/paravirt: Stash native pv-ops"
  "x86/paravirt: Add runtime_patch()"
  "x86/paravirt: Add primitives to stage pv-ops"

 Patch 20 enables switching of pv_lock_ops:
  "x86/paravirt: Enable pv-spinlocks in runtime_patch()"

 2. Non-emulated text poking (patches 11-19)

 Patches 11-13 are mostly refactoring to split __text_poke() into map,
 unmap and poke/memcpy phases with the poke portion being re-entrant
  "x86/alternatives: Remove return value of text_poke*()"
  "x86/alternatives: Use __get_unlocked_pte() in text_poke()"
  "x86/alternatives: Split __text_poke()"

 Patches 15, 17 add the actual poking state-machine:
  "x86/alternatives: Non-emulated text poking"
  "x86/alternatives: Add patching logic in text_poke_site()"

 with patches 14 and 18 containing the pieces for BP handling:
  "x86/alternatives: Handle native insns in text_poke_loc*()"
  "x86/alternatives: Handle BP in non-emulated text poking"

 and patch 19 provides the ability to use the state-machine above in an
 NMI context (fixes some potential deadlocks when handling inter-
 dependent operations and multiple NMIs):
  "x86/alternatives: NMI safe runtime patching".

 Patch 16 provides the interface (paravirt_runtime_patch()) to use the
 poking mechanism developed above and patch 21 adds a selftest:
  "x86/alternatives: Add paravirt patching at runtime"
  "x86/alternatives: Paravirt runtime selftest"

 3. KVM guest changes to be able to use this (patches 22-23,25-26):
  "kvm/paravirt: Encapsulate KVM pv switching logic"
  "x86/kvm: Add worker to trigger runtime patching"
  "x86/kvm: Guest support for dynamic hints"
  "x86/kvm: Add hint change notifier for KVM_HINT_REALTIME".

 4. KVM host changes to notify the guest of a change (patch 24):
  "x86/kvm: Support dynamic CPUID hints"

Testing:
With paravirt patching, the code is mostly stable on Intel and AMD
systems under kernbench and locktorture with paravirt toggling (with,
without synthetic NMIs) in the background.

Queued spinlock performance for locktorture is also on expected lines:
 [ 1533.221563] Writes:  Total: 1048759000  Max/Min: 0/0   Fail: 0 
 # toggle PV spinlocks

 [ 1594.713699] Writes:  Total: 1111660545  Max/Min: 0/0   Fail: 0 
 # PV spinlocks (in ~60 seconds) = 62,901,545

 # toggle native spinlocks
 [ 1656.117175] Writes:  Total: 1113888840  Max/Min: 0/0   Fail: 0 
  # native spinlocks (in ~60 seconds) = 2,228,295

The alternatives testing is more limited with it being used to rewrite
mostly harmless X86_FEATUREs with load in the background.

Patches also at:

ssh://git@github.com/terminus/linux.git alternatives-rfc-upstream-v1

Please review.

Thanks
Ankur

[1] The precise change in memory footprint depends on config options
but the following example inlines queued_spin_unlock() (which forms
the bulk of the added state). The added footprint is the size of the
.parainstructions.runtime section:

 $ objdump -h vmlinux|grep .parainstructions
 Idx Name              		Size      VMA               
 	LMA                File-off  Algn
  27 .parainstructions 		0001013c  ffffffff82895000
  	0000000002895000   01c95000  2**3
  28 .parainstructions.runtime  0000cd2c  ffffffff828a5140
  	00000000028a5140   01ca5140  2**3

  $ size vmlinux                                         
  text       data       bss        dec      hex       filename
  13726196   12302814   14094336   40123346 2643bd2   vmlinux

Ankur Arora (26):
  x86/paravirt: Specify subsection in PVOP macros
  x86/paravirt: Allow paravirt patching post-init
  x86/paravirt: PVRTOP macros for PARAVIRT_RUNTIME
  x86/alternatives: Refactor alternatives_smp_module*
  x86/alternatives: Rename alternatives_smp*, smp_alt_module
  x86/alternatives: Remove stale symbols
  x86/paravirt: Persist .parainstructions.runtime
  x86/paravirt: Stash native pv-ops
  x86/paravirt: Add runtime_patch()
  x86/paravirt: Add primitives to stage pv-ops
  x86/alternatives: Remove return value of text_poke*()
  x86/alternatives: Use __get_unlocked_pte() in text_poke()
  x86/alternatives: Split __text_poke()
  x86/alternatives: Handle native insns in text_poke_loc*()
  x86/alternatives: Non-emulated text poking
  x86/alternatives: Add paravirt patching at runtime
  x86/alternatives: Add patching logic in text_poke_site()
  x86/alternatives: Handle BP in non-emulated text poking
  x86/alternatives: NMI safe runtime patching
  x86/paravirt: Enable pv-spinlocks in runtime_patch()
  x86/alternatives: Paravirt runtime selftest
  kvm/paravirt: Encapsulate KVM pv switching logic
  x86/kvm: Add worker to trigger runtime patching
  x86/kvm: Support dynamic CPUID hints
  x86/kvm: Guest support for dynamic hints
  x86/kvm: Add hint change notifier for KVM_HINT_REALTIME

 Documentation/virt/kvm/api.rst        |  17 +
 Documentation/virt/kvm/cpuid.rst      |   9 +-
 arch/x86/Kconfig                      |  14 +
 arch/x86/Kconfig.debug                |  13 +
 arch/x86/entry/entry_64.S             |   5 +
 arch/x86/include/asm/alternative.h    |  20 +-
 arch/x86/include/asm/kvm_host.h       |   6 +
 arch/x86/include/asm/kvm_para.h       |  17 +
 arch/x86/include/asm/paravirt.h       |  10 +-
 arch/x86/include/asm/paravirt_types.h | 230 ++++--
 arch/x86/include/asm/text-patching.h  |  18 +-
 arch/x86/include/uapi/asm/kvm_para.h  |   2 +
 arch/x86/kernel/Makefile              |   1 +
 arch/x86/kernel/alternative.c         | 987 +++++++++++++++++++++++---
 arch/x86/kernel/kvm.c                 | 191 ++++-
 arch/x86/kernel/module.c              |  42 +-
 arch/x86/kernel/paravirt.c            |  16 +-
 arch/x86/kernel/paravirt_patch.c      |  61 ++
 arch/x86/kernel/pv_selftest.c         | 264 +++++++
 arch/x86/kernel/pv_selftest.h         |  15 +
 arch/x86/kernel/setup.c               |   2 +
 arch/x86/kernel/vmlinux.lds.S         |  16 +
 arch/x86/kvm/cpuid.c                  |   3 +-
 arch/x86/kvm/x86.c                    |  39 +
 include/asm-generic/kvm_para.h        |  12 +
 include/asm-generic/vmlinux.lds.h     |   8 +
 include/linux/kvm_para.h              |   5 +
 include/linux/mm.h                    |  16 +-
 include/linux/preempt.h               |  17 +
 include/uapi/linux/kvm.h              |   4 +
 kernel/locking/lock_events.c          |   2 +-
 mm/memory.c                           |   9 +-
 32 files changed, 1850 insertions(+), 221 deletions(-)
 create mode 100644 arch/x86/kernel/pv_selftest.c
 create mode 100644 arch/x86/kernel/pv_selftest.h

-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2u2-0002ez-Uw; Wed, 08 Apr 2020 05:05:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2u0-0002dl-49
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:28 +0000
X-Inumbo-ID: 8c67c17b-7956-11ea-81bb-12813bfff9fa
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8c67c17b-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:22 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853kcS191152;
 Wed, 8 Apr 2020 05:05:16 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=f3lI3rU1/Ay+Euh85CO5VhgXpZoiQo2cE1fiMRnLh1w=;
 b=nMq6d/oDWDkNt2ukCGxAciCrkLF9QtnmmkiNw9DRJnvr/apWes/2eAGiQcGqMSCJVtmo
 M6AtPpl2ujYjQf5RDs/ynkxYwT9oSpQgxsfAqkfYM3b0ktBcH6b5z2SyZWM2/IcvPU0Q
 ocfvrZ3Cx8jlOay/V59oyr80m0cPdV01ga90ZR0ZRoz2qZCBTheZFVMeTUWz4GOlnssG
 SSLKEhsbansJomlmhFH0Bu4iSxQ4+844Zl0p2Ssk3gqZecDCRH8tvncx2cWmCY+MBahS
 9fFyUtYO5a4JeZxrmJbEfjc0ZKNjEFNDNmbY4C7ivOd/gfozUSL3n9ED7t1mddqW8YD0 aQ== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by aserp2120.oracle.com with ESMTP id 3091m0s0sj-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:16 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853LB1158807;
 Wed, 8 Apr 2020 05:05:15 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by userp3030.oracle.com with ESMTP id 3091m01fvx-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:15 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03855DaW015230;
 Wed, 8 Apr 2020 05:05:13 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:12 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 10/26] x86/paravirt: Add primitives to stage pv-ops
Date: Tue,  7 Apr 2020 22:03:07 -0700
Message-Id: <20200408050323.4237-11-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 mlxlogscore=999 phishscore=0 spamscore=0 adultscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add paravirt_stage_alt() which conditionally selects between a paravirt
or native pv-op and then stages it for later patching.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/paravirt_types.h |  6 +++
 arch/x86/include/asm/text-patching.h  |  3 ++
 arch/x86/kernel/alternative.c         | 58 +++++++++++++++++++++++++++
 3 files changed, 67 insertions(+)

diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 3b9f6c105397..0c4ca7ad719c 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -350,6 +350,12 @@ extern struct paravirt_patch_template native_pv_ops;
 #define PARAVIRT_PATCH(x)					\
 	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
 
+#define paravirt_stage_alt(do_stage, op, opfn)				\
+	(text_poke_pv_stage(PARAVIRT_PATCH(op),				\
+			    (do_stage) ? (opfn) : (native_pv_ops.op)))
+
+#define paravirt_stage_zero() text_poke_pv_stage_zero()
+
 /*
  * Neat trick to map patch type back to the call within the
  * corresponding structure.
diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h
index e2ef241c261e..706e61e6967d 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -55,6 +55,9 @@ extern void text_poke_bp(void *addr, const void *opcode, size_t len, const void
 extern void text_poke_queue(void *addr, const void *opcode, size_t len, const void *emulate);
 extern void text_poke_finish(void);
 
+bool text_poke_pv_stage(u8 type, void *opfn);
+void text_poke_pv_stage_zero(void);
+
 #define INT3_INSN_SIZE		1
 #define INT3_INSN_OPCODE	0xCC
 
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 8189ac21624c..0c335af9ee28 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -1307,3 +1307,61 @@ void __ref text_poke_bp(void *addr, const void *opcode, size_t len, const void *
 	text_poke_loc_init(&tp, addr, opcode, len, emulate);
 	text_poke_bp_batch(&tp, 1);
 }
+
+#ifdef CONFIG_PARAVIRT_RUNTIME
+struct paravirt_stage_entry {
+	void *dest;	/* pv_op destination */
+	u8 type;	/* pv_op type */
+};
+
+/*
+ * We don't anticipate many pv-ops being written at runtime.
+ */
+#define PARAVIRT_STAGE_MAX 8
+struct paravirt_stage {
+	struct paravirt_stage_entry ops[PARAVIRT_STAGE_MAX];
+	u32 count;
+};
+
+/* Protected by text_mutex */
+static struct paravirt_stage pv_stage;
+
+/**
+ * text_poke_pv_stage - Stage paravirt-op for poking.
+ * @addr: address in struct paravirt_patch_template
+ * @type: pv-op type
+ * @opfn: destination of the pv-op
+ *
+ * Return: staging status.
+ */
+bool text_poke_pv_stage(u8 type, void *opfn)
+{
+	if (system_state == SYSTEM_BOOTING) { /* Passthrough */
+		PARAVIRT_PATCH_OP(pv_ops, type) = (long)opfn;
+		goto out;
+	}
+
+	lockdep_assert_held(&text_mutex);
+
+	if (PARAVIRT_PATCH_OP(pv_ops, type) == (long)opfn)
+		goto out;
+
+	if (pv_stage.count >= PARAVIRT_STAGE_MAX)
+		goto out;
+
+	pv_stage.ops[pv_stage.count].type = type;
+	pv_stage.ops[pv_stage.count].dest = opfn;
+
+	pv_stage.count++;
+
+	return true;
+out:
+	return false;
+}
+
+void text_poke_pv_stage_zero(void)
+{
+	lockdep_assert_held(&text_mutex);
+	pv_stage.count = 0;
+}
+#endif /* CONFIG_PARAVIRT_RUNTIME */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2u6-0002gm-72; Wed, 08 Apr 2020 05:05:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2u4-0002fs-H4
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:32 +0000
X-Inumbo-ID: 8c730c42-7956-11ea-b4f4-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8c730c42-7956-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 05:05:22 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 038544lW191251;
 Wed, 8 Apr 2020 05:05:09 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=Q/x63j7IF9jNQkX6xMMSEc7WXp2MrGiG0gMNWP0OfWM=;
 b=ECcLHHKM1Y3f/mNjqQHcNekCfZwy7o5zdSSQAxLfqjPZMM2CwYlwO9ziEEQME73MsHEU
 L++tyOqLrBEz+TPthoQ2QMk9tFdULvWDh4X7mSjd1qCUoYVZk28ix7ZtaRdJ1F2vD2PG
 eMan5188ae3P/oVnDlkKI+g407m/RDHzMPH9B1nDUdn9BJAV5875XtLNojw57f/axCcB
 AQtKmdYasSQzu01XH4kHhT8ck/rfDnFf6wPrMCXiNGxOZ70jmj13uXWotmQoRbM+QzS6
 IgK8/idFBsVRyi7CG4lOSpSf8+0yp0jR+s01UpXhsN41QuU9tT4s+LayyeXT4pPfCgK2 7A== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by aserp2120.oracle.com with ESMTP id 3091m0s0s4-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:09 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853Kcm158669;
 Wed, 8 Apr 2020 05:05:08 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userp3030.oracle.com with ESMTP id 3091m01frk-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:08 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 038557fF007332;
 Wed, 8 Apr 2020 05:05:07 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:07 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 07/26] x86/paravirt: Persist .parainstructions.runtime
Date: Tue,  7 Apr 2020 22:03:04 -0700
Message-Id: <20200408050323.4237-8-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 mlxlogscore=999 phishscore=0 spamscore=0 adultscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Persist .parainstructions.runtime in memory. We will use it to
patch paravirt-ops at runtime.

The extra memory footprint depends on chosen config options but the
inlined queued_spin_unlock() presents an edge case:

 $ objdump -h vmlinux|grep .parainstructions
 Idx Name              		Size      VMA
 	LMA                File-off  Algn
  27 .parainstructions 		0001013c  ffffffff82895000
  	0000000002895000   01c95000  2**3
  28 .parainstructions.runtime  0000cd2c  ffffffff828a5140
  	00000000028a5140   01ca5140  2**3

(The added footprint is the size of the .parainstructions.runtime
section.)

  $ size vmlinux
  text       data       bss        dec      hex       filename
  13726196   12302814   14094336   40123346 2643bd2   vmlinux

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/alternative.h |  1 +
 arch/x86/kernel/alternative.c      | 16 +++++++++++++++-
 arch/x86/kernel/module.c           | 28 +++++++++++++++++++++++-----
 3 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
index db91a7731d87..d19546c14ff6 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -76,6 +76,7 @@ extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
 struct module;
 
 void alternatives_module_add(struct module *mod, char *name,
+			     void *para, void *para_end,
 			     void *locks, void *locks_end,
 			     void *text, void *text_end);
 void alternatives_module_del(struct module *mod);
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 09e4ee0e09a2..8189ac21624c 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -482,6 +482,12 @@ struct alt_module {
 	struct module	*mod;
 	char		*name;
 
+#ifdef CONFIG_PARAVIRT_RUNTIME
+	/* ptrs to paravirt sites */
+	struct paravirt_patch_site *para;
+	struct paravirt_patch_site *para_end;
+#endif
+
 	/* ptrs to lock prefixes */
 	const s32	*locks;
 	const s32	*locks_end;
@@ -496,6 +502,7 @@ struct alt_module {
 static LIST_HEAD(alt_modules);
 
 void __init_or_module alternatives_module_add(struct module *mod, char *name,
+					      void *para, void *para_end,
 					      void *locks, void *locks_end,
 					      void *text,  void *text_end)
 {
@@ -506,7 +513,7 @@ void __init_or_module alternatives_module_add(struct module *mod, char *name,
 	if (!noreplace_smp && (num_present_cpus() == 1 || setup_max_cpus <= 1))
 		uniproc_patched = true;
 #endif
-	if (!uniproc_patched)
+	if (!IS_ENABLED(CONFIG_PARAVIRT_RUNTIME) && !uniproc_patched)
 		return;
 
 	mutex_lock(&text_mutex);
@@ -516,6 +523,11 @@ void __init_or_module alternatives_module_add(struct module *mod, char *name,
 	alt->mod	= mod;
 	alt->name	= name;
 
+#ifdef CONFIG_PARAVIRT_RUNTIME
+	alt->para	= para;
+	alt->para_end	= para_end;
+#endif
+
 	if (num_possible_cpus() != 1 || uniproc_patched) {
 		/* Remember only if we'll need to undo it. */
 		alt->locks	= locks;
@@ -733,6 +745,8 @@ void __init alternative_instructions(void)
 	apply_alternatives(__alt_instructions, __alt_instructions_end);
 
 	alternatives_module_add(NULL, "core kernel",
+				__parainstructions_runtime,
+				__parainstructions_runtime_end,
 				__smp_locks, __smp_locks_end,
 				_text, _etext);
 
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index fc3d35198b09..7b2632184c11 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -248,12 +248,30 @@ int module_finalize(const Elf_Ehdr *hdr,
 		void *aseg = (void *)alt->sh_addr;
 		apply_alternatives(aseg, aseg + alt->sh_size);
 	}
-	if (locks && text) {
-		void *lseg = (void *)locks->sh_addr;
-		void *tseg = (void *)text->sh_addr;
+	if (para_run || (locks && text)) {
+		void *pseg, *pseg_end;
+		void *lseg, *lseg_end;
+		void *tseg, *tseg_end;
+
+		pseg = pseg_end = NULL;
+		lseg = lseg_end = NULL;
+		tseg = tseg_end = NULL;
+		if (para_run) {
+			pseg = (void *)para_run->sh_addr;
+			pseg_end = pseg + para_run->sh_size;
+		}
+
+		if (locks && text) {
+			tseg = (void *)text->sh_addr;
+			tseg_end = tseg + text->sh_size;
+
+			lseg = (void *)locks->sh_addr;
+			lseg_end = lseg + locks->sh_size;
+		}
 		alternatives_module_add(me, me->name,
-					lseg, lseg + locks->sh_size,
-					tseg, tseg + text->sh_size);
+					pseg, pseg_end,
+					lseg, lseg_end,
+					tseg, tseg_end);
 	}
 
 	if (para) {
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2u6-0002h5-GG; Wed, 08 Apr 2020 05:05:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2u5-0002gJ-4B
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:33 +0000
X-Inumbo-ID: 8c67c17c-7956-11ea-81bb-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8c67c17c-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:22 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853GBi179620;
 Wed, 8 Apr 2020 05:05:16 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=kG41Wdi3xZl8bLDCQdMVBGXBcfy0aVqVcUlxPKtO2Qo=;
 b=xWXrvfUdB9tuJuQ2V9qdp8V5Bz/bz2ImxUQMZguPeBGwXxeXQYy1NSxRzY5PefUFgpCi
 DE348mVzKuUk1tMCueBWHccBpShi3itMcbUNJlD7HQhzAmsa08nAPhzy6973ZKTzTfVQ
 WbbNP2PNksH1Xt5HpceILIVsYBjThZn8GmaQPXJ7/cVAn3dWpMcXfJ+nzcncLVFMkK/s
 LunZLiI+/yDjmOTe811yfyRavy6AoS80i5en5ECYf7zgvFKOwGItBp1etljPK9ypTOOE
 WlgQIgH+NA20KP2M/zAXvrlZiP8WfH2UQlOeF4HKb5cnflfwZj4/IurCxH++yE9rr9eR uA== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2120.oracle.com with ESMTP id 3091mnh14d-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:16 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853Lv7159055;
 Wed, 8 Apr 2020 05:05:16 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
 by userp3030.oracle.com with ESMTP id 3091m01fwa-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:16 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03855FqY030510;
 Wed, 8 Apr 2020 05:05:15 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:14 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 11/26] x86/alternatives: Remove return value of
 text_poke*()
Date: Tue,  7 Apr 2020 22:03:08 -0700
Message-Id: <20200408050323.4237-12-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 mlxlogscore=813 phishscore=0 spamscore=0 adultscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 mlxlogscore=873 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0
 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Various text_poke() variants don't return a useful value. Remove it.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/text-patching.h |  4 ++--
 arch/x86/kernel/alternative.c        | 11 +++++------
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h
index 706e61e6967d..04778c2bc34e 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -46,9 +46,9 @@ extern void text_poke_early(void *addr, const void *opcode, size_t len);
  * On the local CPU you need to be protected against NMI or MCE handlers seeing
  * an inconsistent instruction while you patch.
  */
-extern void *text_poke(void *addr, const void *opcode, size_t len);
+extern void text_poke(void *addr, const void *opcode, size_t len);
 extern void text_poke_sync(void);
-extern void *text_poke_kgdb(void *addr, const void *opcode, size_t len);
+extern void text_poke_kgdb(void *addr, const void *opcode, size_t len);
 extern int poke_int3_handler(struct pt_regs *regs);
 extern void text_poke_bp(void *addr, const void *opcode, size_t len, const void *emulate);
 
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 0c335af9ee28..8c79a3dc5e72 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -805,7 +805,7 @@ void __init_or_module text_poke_early(void *addr, const void *opcode,
 __ro_after_init struct mm_struct *poking_mm;
 __ro_after_init unsigned long poking_addr;
 
-static void *__text_poke(void *addr, const void *opcode, size_t len)
+static void __text_poke(void *addr, const void *opcode, size_t len)
 {
 	bool cross_page_boundary = offset_in_page(addr) + len > PAGE_SIZE;
 	struct page *pages[2] = {NULL};
@@ -906,7 +906,6 @@ static void *__text_poke(void *addr, const void *opcode, size_t len)
 
 	pte_unmap_unlock(ptep, ptl);
 	local_irq_restore(flags);
-	return addr;
 }
 
 /**
@@ -925,11 +924,11 @@ static void *__text_poke(void *addr, const void *opcode, size_t len)
  * by registering a module notifier, and ordering module removal and patching
  * trough a mutex.
  */
-void *text_poke(void *addr, const void *opcode, size_t len)
+void text_poke(void *addr, const void *opcode, size_t len)
 {
 	lockdep_assert_held(&text_mutex);
 
-	return __text_poke(addr, opcode, len);
+	__text_poke(addr, opcode, len);
 }
 
 /**
@@ -946,9 +945,9 @@ void *text_poke(void *addr, const void *opcode, size_t len)
  * Context: should only be used by kgdb, which ensures no other core is running,
  *	    despite the fact it does not hold the text_mutex.
  */
-void *text_poke_kgdb(void *addr, const void *opcode, size_t len)
+void text_poke_kgdb(void *addr, const void *opcode, size_t len)
 {
-	return __text_poke(addr, opcode, len);
+	__text_poke(addr, opcode, len);
 }
 
 static void do_sync_core(void *info)
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uA-0002k6-RM; Wed, 08 Apr 2020 05:05:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2u9-0002j8-Hx
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:37 +0000
X-Inumbo-ID: 8c9f7de0-7956-11ea-83d8-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8c9f7de0-7956-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 05:05:22 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853kJT191170;
 Wed, 8 Apr 2020 05:05:03 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=YqkpSF+xaj87ukpBfxxbSQruerieQm4kGvLikr6EByg=;
 b=JdkjanUuxwOILdkRa92kgljdqWjdgneiBkVZJxAeqNWM1rn046UVVjh8q+hLyr1jCaw5
 efBQTN7ituKdbN9KZYhmSd6bCobGZy4Ai8YbCGV7w+NxE1HICzDkva4dKA2R+PUxPIzC
 shywYoahTgQ9oCJkap9TlaUAxYpHeIGVf+XMEFvzEXjWP7PfrP/slqcx10d7fz1KStg2
 kcTlKOfFWU0p6o2YZbGTWkmxDBVRKFs1+6jB2CTRjJvQ3gD2DZgw1BPb+x1v8dy4x7qv
 J0Dv+ro6jQX3SXKG0NtTYkrxjdavZEFEdN+7kyhodZuYxmp5MbHHWuEIxUhLyQuwPcF6 vg== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by aserp2120.oracle.com with ESMTP id 3091m0s0rs-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:02 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852XPH062239;
 Wed, 8 Apr 2020 05:05:02 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
 by userp3020.oracle.com with ESMTP id 3091mh1k6d-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:02 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03854w5i030423;
 Wed, 8 Apr 2020 05:04:59 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:04:57 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 02/26] x86/paravirt: Allow paravirt patching post-init
Date: Tue,  7 Apr 2020 22:02:59 -0700
Message-Id: <20200408050323.4237-3-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 suspectscore=0 bulkscore=0
 mlxlogscore=999 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Paravirt-ops are patched at init to convert indirect calls into
direct calls and in some cases, to inline the target at the call-site.
This is done by way of PVOP* macros which save the call-site
information via compile time annotations.

Pull this state out in .parainstructions.runtime for some pv-ops such
that they can be used for runtime patching.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/Kconfig                      | 12 ++++++++++++
 arch/x86/include/asm/paravirt_types.h |  5 +++++
 arch/x86/include/asm/text-patching.h  |  5 +++++
 arch/x86/kernel/alternative.c         |  2 ++
 arch/x86/kernel/module.c              | 10 +++++++++-
 arch/x86/kernel/vmlinux.lds.S         | 16 ++++++++++++++++
 include/asm-generic/vmlinux.lds.h     |  8 ++++++++
 7 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1edf788d301c..605619938f08 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -764,6 +764,18 @@ config PARAVIRT
 	  over full virtualization.  However, when run without a hypervisor
 	  the kernel is theoretically slower and slightly larger.
 
+config PARAVIRT_RUNTIME
+	bool "Enable paravirtualized ops to be patched at runtime"
+	depends on PARAVIRT
+	help
+	  Enable the paravirtualized guest kernel to switch pv-ops based on
+	  changed host conditions, potentially improving performance
+	  significantly.
+
+	  This would increase the memory footprint of the running kernel
+	  slightly (depending mostly on whether lock and unlock are inlined
+	  or not.)
+
 config PARAVIRT_XXL
 	bool
 
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 37e8f27a3b9d..00e4a062ca10 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -723,6 +723,11 @@ struct paravirt_patch_site {
 extern struct paravirt_patch_site __parainstructions[],
 	__parainstructions_end[];
 
+#ifdef CONFIG_PARAVIRT_RUNTIME
+extern struct paravirt_patch_site __parainstructions_runtime[],
+	__parainstructions_runtime_end[];
+#endif
+
 #endif	/* __ASSEMBLY__ */
 
 #endif	/* _ASM_X86_PARAVIRT_TYPES_H */
diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h
index 67315fa3956a..e2ef241c261e 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -18,6 +18,11 @@ static inline void apply_paravirt(struct paravirt_patch_site *start,
 #define __parainstructions_end	NULL
 #endif
 
+#ifndef CONFIG_PARAVIRT_RUNTIME
+#define __parainstructions_runtime	NULL
+#define __parainstructions_runtime_end	NULL
+#endif
+
 /*
  * Currently, the max observed size in the kernel code is
  * JUMP_LABEL_NOP_SIZE/RELATIVEJUMP_SIZE, which are 5.
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 7867dfb3963e..fdfda1375f82 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -740,6 +740,8 @@ void __init alternative_instructions(void)
 #endif
 
 	apply_paravirt(__parainstructions, __parainstructions_end);
+	apply_paravirt(__parainstructions_runtime,
+		       __parainstructions_runtime_end);
 
 	restart_nmi();
 	alternatives_patched = 1;
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index d5c72cb877b3..658ea60ce324 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -222,7 +222,7 @@ int module_finalize(const Elf_Ehdr *hdr,
 		    struct module *me)
 {
 	const Elf_Shdr *s, *text = NULL, *alt = NULL, *locks = NULL,
-		*para = NULL, *orc = NULL, *orc_ip = NULL;
+		*para = NULL, *para_run = NULL, *orc = NULL, *orc_ip = NULL;
 	char *secstrings = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
 
 	for (s = sechdrs; s < sechdrs + hdr->e_shnum; s++) {
@@ -234,6 +234,9 @@ int module_finalize(const Elf_Ehdr *hdr,
 			locks = s;
 		if (!strcmp(".parainstructions", secstrings + s->sh_name))
 			para = s;
+		if (!strcmp(".parainstructions.runtime",
+			    secstrings + s->sh_name))
+			para_run = s;
 		if (!strcmp(".orc_unwind", secstrings + s->sh_name))
 			orc = s;
 		if (!strcmp(".orc_unwind_ip", secstrings + s->sh_name))
@@ -257,6 +260,11 @@ int module_finalize(const Elf_Ehdr *hdr,
 		void *pseg = (void *)para->sh_addr;
 		apply_paravirt(pseg, pseg + para->sh_size);
 	}
+	if (para_run) {
+		void *pseg = (void *)para_run->sh_addr;
+
+		apply_paravirt(pseg, pseg + para_run->sh_size);
+	}
 
 	/* make jump label nops */
 	jump_label_apply_nops(me);
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 1bf7e312361f..7f5b8f6ab96e 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -269,6 +269,7 @@ SECTIONS
 	.parainstructions : AT(ADDR(.parainstructions) - LOAD_OFFSET) {
 		__parainstructions = .;
 		*(.parainstructions)
+		PARAVIRT_DISCARD(.parainstructions.runtime)
 		__parainstructions_end = .;
 	}
 
@@ -348,6 +349,21 @@ SECTIONS
 		__smp_locks_end = .;
 	}
 
+#ifdef CONFIG_PARAVIRT_RUNTIME
+	/*
+	 * .parainstructions.runtime sticks around in memory after
+	 * init so it doesn't need to be page-aligned but everything
+	 * around us is so we will be too.
+	 */
+	. = ALIGN(8);
+	.parainstructions.runtime : AT(ADDR(.parainstructions.runtime) - \
+								LOAD_OFFSET) {
+		__parainstructions_runtime = .;
+		PARAVIRT_KEEP(.parainstructions.runtime)
+		__parainstructions_runtime_end = .;
+	}
+#endif
+
 #ifdef CONFIG_X86_64
 	.data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) {
 		NOSAVE_DATA
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 71e387a5fe90..6b009d5ce51f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -135,6 +135,14 @@
 #define MEM_DISCARD(sec) *(.mem##sec)
 #endif
 
+#if defined(CONFIG_PARAVIRT_RUNTIME)
+#define PARAVIRT_KEEP(sec)	*(sec)
+#define PARAVIRT_DISCARD(sec)
+#else
+#define PARAVIRT_KEEP(sec)
+#define PARAVIRT_DISCARD(sec)	*(sec)
+#endif
+
 #ifdef CONFIG_FTRACE_MCOUNT_RECORD
 /*
  * The ftrace call sites are logged to a section whose name depends on the
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uB-0002kV-4h; Wed, 08 Apr 2020 05:05:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uA-0002jQ-4V
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:38 +0000
X-Inumbo-ID: 8c753620-7956-11ea-81bb-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8c753620-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:22 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853MYK179629;
 Wed, 8 Apr 2020 05:05:07 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=wXWzqKpXP4X1QYluyMKcRS0Im/RDUvqYRVQBv1BS7nY=;
 b=alK3sFDt1Pwv7BYgZTwY8xnWBnHMLyJyt9SlwdNVAK2rna7XJu9iH2Y4DM6F0e9VfnC3
 GBqgu4QeDotoIm1NugkOTmgOqQb8NWWI3q5AvR/VAr/yW4T5A9roFCPiUgvbdkJf2VYr
 F0uBX8fTAVhVvjGNnf90CpBJP5UeILeKgH/DFfNpGbja2gaUn/33CY4yQCYCUjHrZ1x+
 9+GQAaIiiFoEj2zgpzDOmZOCBpdD17bAzpbXUZu+hER4VtI+Ue9QyHVrw3rsHvCXl3RO
 mhfNnyC1wWZofzLK34HV/83fsKsCqIOOP8jU05D0+FNlDl7JqAlacAHsF/SSoud5ZyCd GQ== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by userp2120.oracle.com with ESMTP id 3091mnh140-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:07 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03851X9K100807;
 Wed, 8 Apr 2020 05:05:06 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
 by aserp3020.oracle.com with ESMTP id 3091m2huh7-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:06 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 038556XE030455;
 Wed, 8 Apr 2020 05:05:06 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:05 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 06/26] x86/alternatives: Remove stale symbols
Date: Tue,  7 Apr 2020 22:03:03 -0700
Message-Id: <20200408050323.4237-7-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 mlxscore=0
 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 mlxlogscore=999 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0
 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

__start_parainstructions and __stop_parainstructions aren't
defined, remove them.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/kernel/alternative.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 4157f848b537..09e4ee0e09a2 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -623,8 +623,6 @@ void __init_or_module apply_paravirt(struct paravirt_patch_site *start,
 		text_poke_early(p->instr, insn_buff, p->len);
 	}
 }
-extern struct paravirt_patch_site __start_parainstructions[],
-	__stop_parainstructions[];
 #endif	/* CONFIG_PARAVIRT */
 
 /*
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uF-0002ot-LK; Wed, 08 Apr 2020 05:05:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uE-0002np-IR
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:42 +0000
X-Inumbo-ID: 8ca1c8ca-7956-11ea-b58d-bc764e2007e4
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8ca1c8ca-7956-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 05:05:22 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853MYL179629;
 Wed, 8 Apr 2020 05:05:13 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=ZGw+hgAAF68C57Q7ZOripu6KHJbA5oEpyXh43CXBxZY=;
 b=AlnOo69NHgytLqrqPenbwiO51OpjhQm6qCRzV044f8RNfXL639+j9+y4lJ1hDyZW/UmJ
 hLXcRRBSui97Qw4QuVYDUMVEjBk9jFHguLdJw8P21Nln8iACE1ScZwMoS6ya9yIShqab
 vsVwbFuUeu9oodd3WT/WD4bTepdiwomDvs9WcyTN3mi6JVaGJz3Tc967HJV+Uo1ZJhxJ
 2TyMGCpZCeQJR4Uix5ZSjbPjc1n0ucB2dUw3TQm3oHWvqv9lxrSy8o365UX+m4GJUcK6
 c6qFYtvnLzekrWD7m5COhXYsddWMeclqCbgOKYV4cyGs+WZI9yDH0o1gNJSPg839s7p9 pA== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2120.oracle.com with ESMTP id 3091mnh148-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:13 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853KZ9158671;
 Wed, 8 Apr 2020 05:05:13 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by userp3030.oracle.com with ESMTP id 3091m01fuy-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:13 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03855AVI015225;
 Wed, 8 Apr 2020 05:05:10 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:09 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 09/26] x86/paravirt: Add runtime_patch()
Date: Tue,  7 Apr 2020 22:03:06 -0700
Message-Id: <20200408050323.4237-10-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 mlxlogscore=999 phishscore=0 spamscore=0 adultscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 mlxlogscore=999 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0
 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

runtime_patch() generates insn sequences for patching supported pv_ops.
It does this by calling paravirt_patch_default() or native_patch()
dpending on if the target is a paravirt or native pv-op.

In addition, runtime_patch() also whitelists pv-ops that are safe to
patch at runtime.

The static conditions that need to be satisfied to patch safely:
 - Insn sequences under replacement need to execute without preemption.
   This is meant to avoid scenarios where a call-site (ex.
   lock.vcpu_is_preempted) switches between the following sequences:

  lock.vcpu_is_preempted = __raw_callee_save___kvm_vcpu_is_preempted
    0: e8 31 e6 ff ff		callq  0xffffffffffffe636
    4: 66 90			xchg   %ax,%ax      # NOP2

  lock.vcpu_is_preempted = __raw_callee_save___native_vcpu_is_preempted
    0: 31 c0			xor   %rax, %rax
    2: 0f 1f 44 00 00		nopl   0x0(%rax)    # NOP5

   If kvm_vcpu_is_preempted() were preemptible, then, post patching
   we would return to address 4 above, which is in the middle of an
   instruction for native_vcpu_is_preempted().

   Even if this were to be made safe (ex. by changing the NOP2 to be a
   prefix instead of a suffix), it would still not be enough -- since
   we do not want any code from the switched out pv-op to be executing
   after the pv-op has been switched out.

 - Entered only at the beginning: this allows us to use text_poke()
   which uses INT3 as a barrier.

We don't store the address inside any call-sites so the second can be
assumed.

Guaranteeing the first condition boils down to stating that any pv-op
being patched cannot be present/referenced from any call-stack in the
system. pv-ops that are not obviously non-preemptible need to be
enclosed in preempt_disable_runtime_patch()/preempt_enable_runtime_patch().

This should be sufficient because runtime_patch() itself is called from
a stop_machine() context which would would be enough to flush out any
non-preemptible sequences.

Note that preemption in the host is okay: stop_machine() would unwind
any pv-ops sleeping in the host.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/paravirt_types.h |  8 +++++
 arch/x86/kernel/paravirt.c            |  6 +---
 arch/x86/kernel/paravirt_patch.c      | 49 +++++++++++++++++++++++++++
 include/linux/preempt.h               | 17 ++++++++++
 4 files changed, 75 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index bc935eec7ec6..3b9f6c105397 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -350,6 +350,12 @@ extern struct paravirt_patch_template native_pv_ops;
 #define PARAVIRT_PATCH(x)					\
 	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
 
+/*
+ * Neat trick to map patch type back to the call within the
+ * corresponding structure.
+ */
+#define PARAVIRT_PATCH_OP(ops, type) (*(long *)(&((long **)&(ops))[type]))
+
 #define paravirt_type(op)				\
 	[paravirt_typenum] "i" (PARAVIRT_PATCH(op)),	\
 	[paravirt_opptr] "i" (&(pv_ops.op))
@@ -383,6 +389,8 @@ unsigned paravirt_patch_default(u8 type, void *insn_buff, unsigned long addr, un
 unsigned paravirt_patch_insns(void *insn_buff, unsigned len, const char *start, const char *end);
 
 unsigned native_patch(u8 type, void *insn_buff, unsigned long addr, unsigned len);
+int runtime_patch(u8 type, void *insn_buff, void *op, unsigned long addr,
+		  unsigned int len);
 
 int paravirt_disable_iospace(void);
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 8c511cc4d4f4..c4128436b05a 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -117,11 +117,7 @@ void __init native_pv_lock_init(void)
 unsigned paravirt_patch_default(u8 type, void *insn_buff,
 				unsigned long addr, unsigned len)
 {
-	/*
-	 * Neat trick to map patch type back to the call within the
-	 * corresponding structure.
-	 */
-	void *opfunc = *((void **)&pv_ops + type);
+	void *opfunc = (void *)PARAVIRT_PATCH_OP(pv_ops, type);
 	unsigned ret;
 
 	if (opfunc == NULL)
diff --git a/arch/x86/kernel/paravirt_patch.c b/arch/x86/kernel/paravirt_patch.c
index 3eff63c090d2..3eb8c0e720b4 100644
--- a/arch/x86/kernel/paravirt_patch.c
+++ b/arch/x86/kernel/paravirt_patch.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <linux/stringify.h>
+#include <linux/errno.h>
 
 #include <asm/paravirt.h>
 #include <asm/asm-offsets.h>
@@ -124,3 +125,51 @@ unsigned int native_patch(u8 type, void *insn_buff, unsigned long addr,
 
 	return paravirt_patch_default(type, insn_buff, addr, len);
 }
+
+#ifdef CONFIG_PARAVIRT_RUNTIME
+/**
+ * runtime_patch - Generate patching code for a native/paravirt op
+ * @type: op type to generate code for
+ * @insn_buff: destination buffer
+ * @op: op target
+ * @addr: call site address
+ * @len: length of insn_buff
+ *
+ * Note that pv-ops are only suitable for runtime patching if they are
+ * non-preemptible. This is necessary for two reasons: we don't want to
+ * be overwriting insn sequences which might be referenced from call-stacks
+ * (and thus would be returned to), and we want patching to act as a barrier
+ * so no code from now stale paravirt ops should execute after an op has
+ * changed.
+ *
+ * Return: size of insn sequence on success, -EINVAL on error.
+ */
+int runtime_patch(u8 type, void *insn_buff, void *op,
+		  unsigned long addr, unsigned int len)
+{
+	void *native_op;
+	int used = 0;
+
+	/* Nothing whitelisted for now. */
+	switch (type) {
+	default:
+		pr_warn("type=%d unsuitable for runtime-patching\n", type);
+		return -EINVAL;
+	}
+
+	if (PARAVIRT_PATCH_OP(pv_ops, type) != (long)op)
+		PARAVIRT_PATCH_OP(pv_ops, type) = (long)op;
+
+	native_op = (void *)PARAVIRT_PATCH_OP(native_pv_ops, type);
+
+	/*
+	 * Use native_patch() to get the right insns if we are switching
+	 * back to a native_op.
+	 */
+	if (op == native_op)
+		used = native_patch(type, insn_buff, addr, len);
+	else
+		used = paravirt_patch_default(type, insn_buff, addr, len);
+	return used;
+}
+#endif /* CONFIG_PARAVIRT_RUNTIME */
diff --git a/include/linux/preempt.h b/include/linux/preempt.h
index bc3f1aecaa19..c569d077aab2 100644
--- a/include/linux/preempt.h
+++ b/include/linux/preempt.h
@@ -203,6 +203,13 @@ do { \
 		__preempt_schedule(); \
 } while (0)
 
+/*
+ * preempt_enable_no_resched() so we don't add any preemption points until
+ * after the caller has returned.
+ */
+#define preempt_enable_runtime_patch()	preempt_enable_no_resched()
+#define preempt_disable_runtime_patch()	preempt_disable()
+
 #else /* !CONFIG_PREEMPTION */
 #define preempt_enable() \
 do { \
@@ -217,6 +224,12 @@ do { \
 } while (0)
 
 #define preempt_check_resched() do { } while (0)
+
+/*
+ * NOP, if there's no preemption.
+ */
+#define preempt_disable_runtime_patch()	do { } while (0)
+#define preempt_enable_runtime_patch()	do { } while (0)
 #endif /* CONFIG_PREEMPTION */
 
 #define preempt_disable_notrace() \
@@ -250,6 +263,8 @@ do { \
 #define preempt_enable_notrace()		barrier()
 #define preemptible()				0
 
+#define preempt_disable_runtime_patch()	do { } while (0)
+#define preempt_enable_runtime_patch()	do { } while (0)
 #endif /* CONFIG_PREEMPT_COUNT */
 
 #ifdef MODULE
@@ -260,6 +275,8 @@ do { \
 #undef preempt_enable_no_resched
 #undef preempt_enable_no_resched_notrace
 #undef preempt_check_resched
+#undef preempt_disable_runtime_patch
+#undef preempt_enable_runtime_patch
 #endif
 
 #define preempt_set_need_resched() \
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uG-0002q1-Ux; Wed, 08 Apr 2020 05:05:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uF-0002oQ-53
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:43 +0000
X-Inumbo-ID: 8dca44f3-7956-11ea-81bb-12813bfff9fa
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8dca44f3-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:24 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03854h69013027;
 Wed, 8 Apr 2020 05:05:18 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=8QxNSgJ0TIVxhxX6u30CrqzHaWwQp1Js8M95AGUtpXc=;
 b=vI5EI8HOwXwI5eQetVqe1UeC1FDR5h2Wq2Yc4V02ynbY+QJ5s5gshLf87NcS/xzV5QOo
 Gxmf6Vle0gmY8WBM7etujGZBUqGtXtK1X6cQzgXXz0qUt/rOZqrM4I7h/EmNpLtA8kVU
 rXTBt/ChGhsl6vAhJJASdRwQwK0zmTX9YsmKvblCa/Y0h7xD3BPSovfFcl/75PqYbkD7
 gBYSc9aJ+v3Rzov2jFcgMCyVPXAvnQL5E3hd1TQJY93DhmCkgtqATrczQaTw63J/BWNy
 UpTY/JGIya+qIoWXiyPI34jM69Qs0NZVo5Y/v2bge1U6jQZnHztNJNjgbCHjywWIB7PE /A== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by userp2130.oracle.com with ESMTP id 3091m390xf-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:18 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852XTl062344;
 Wed, 8 Apr 2020 05:05:17 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userp3020.oracle.com with ESMTP id 3091mh1kmn-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:17 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03855GdY007447;
 Wed, 8 Apr 2020 05:05:16 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:16 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 12/26] x86/alternatives: Use __get_unlocked_pte() in
 text_poke()
Date: Tue,  7 Apr 2020 22:03:09 -0700
Message-Id: <20200408050323.4237-13-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 suspectscore=0 bulkscore=0
 mlxlogscore=702 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=763
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

text_poke() uses get_locked_pte() to map poking_addr. However, this
introduces a dependency on locking code which precludes using
text_poke() to modify qspinlock primitives.

Accesses to this pte (and poking_addr) are protected by text_mutex
so we can safely switch to __get_unlocked_pte() here. Note that
we do need to be careful that we do not try to modify the poking_addr
from multiple contexts simultaneously (ex. INT3 or NMI context.)

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/kernel/alternative.c |  9 ++++-----
 include/linux/mm.h            | 16 ++++++++++++++--
 mm/memory.c                   |  9 ++++++---
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 8c79a3dc5e72..0344e49a4ade 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -812,7 +812,6 @@ static void __text_poke(void *addr, const void *opcode, size_t len)
 	temp_mm_state_t prev;
 	unsigned long flags;
 	pte_t pte, *ptep;
-	spinlock_t *ptl;
 	pgprot_t pgprot;
 
 	/*
@@ -846,10 +845,11 @@ static void __text_poke(void *addr, const void *opcode, size_t len)
 	pgprot = __pgprot(pgprot_val(PAGE_KERNEL) & ~_PAGE_GLOBAL);
 
 	/*
-	 * The lock is not really needed, but this allows to avoid open-coding.
+	 * text_poke() might be used to poke spinlock primitives so do this
+	 * unlocked. This does mean that we need to be careful that no other
+	 * context (ex. INT3 handler) is simultaneously writing to this pte.
 	 */
-	ptep = get_locked_pte(poking_mm, poking_addr, &ptl);
-
+	ptep = __get_unlocked_pte(poking_mm, poking_addr);
 	/*
 	 * This must not fail; preallocated in poking_init().
 	 */
@@ -904,7 +904,6 @@ static void __text_poke(void *addr, const void *opcode, size_t len)
 	 */
 	BUG_ON(memcmp(addr, opcode, len));
 
-	pte_unmap_unlock(ptep, ptl);
 	local_irq_restore(flags);
 }
 
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 7dd5c4ccbf85..d4a652c2e269 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1895,8 +1895,20 @@ static inline int pte_devmap(pte_t pte)
 
 int vma_wants_writenotify(struct vm_area_struct *vma, pgprot_t vm_page_prot);
 
-extern pte_t *__get_locked_pte(struct mm_struct *mm, unsigned long addr,
-			       spinlock_t **ptl);
+pte_t *__get_pte(struct mm_struct *mm, unsigned long addr, spinlock_t **ptl);
+
+static inline pte_t *__get_unlocked_pte(struct mm_struct *mm,
+					unsigned long addr)
+{
+	return __get_pte(mm, addr, NULL);
+}
+
+static inline pte_t *__get_locked_pte(struct mm_struct *mm,
+				      unsigned long addr, spinlock_t **ptl)
+{
+	return __get_pte(mm, addr, ptl);
+}
+
 static inline pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr,
 				    spinlock_t **ptl)
 {
diff --git a/mm/memory.c b/mm/memory.c
index 586271f3efc6..7acfe9512084 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1407,8 +1407,8 @@ void zap_vma_ptes(struct vm_area_struct *vma, unsigned long address,
 }
 EXPORT_SYMBOL_GPL(zap_vma_ptes);
 
-pte_t *__get_locked_pte(struct mm_struct *mm, unsigned long addr,
-			spinlock_t **ptl)
+pte_t *__get_pte(struct mm_struct *mm, unsigned long addr,
+		 spinlock_t **ptl)
 {
 	pgd_t *pgd;
 	p4d_t *p4d;
@@ -1427,7 +1427,10 @@ pte_t *__get_locked_pte(struct mm_struct *mm, unsigned long addr,
 		return NULL;
 
 	VM_BUG_ON(pmd_trans_huge(*pmd));
-	return pte_alloc_map_lock(mm, pmd, addr, ptl);
+	if (likely(ptl))
+		return pte_alloc_map_lock(mm, pmd, addr, ptl);
+	else
+		return pte_alloc_map(mm, pmd, addr);
 }
 
 /*
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uK-0002sv-8B; Wed, 08 Apr 2020 05:05:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uJ-0002sQ-IO
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:47 +0000
X-Inumbo-ID: 9087e8a2-7956-11ea-b58d-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9087e8a2-7956-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 05:05:29 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853ldS191183;
 Wed, 8 Apr 2020 05:05:22 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=BeFWvYA7XIlpPY3jCn3WOorYd4LJtWrT9UyxM8q4o68=;
 b=auE3HQCWrQ+mTWzjzKVzofN4aU72M02C0tq5tNvEj4eZaVcWC6iqezU+lJkUo5962rlA
 4ZF60eMjEPMJ/A+8xOPnVl/EcZMjVmy4P1EQt2LIUz1XimSSpXMqTTHEoyRPWWueCrSf
 dtyPCZWNXf9wQpZMuGhmod9YAnk8TApPTY89QWpUzPyBn9D9WOLqI17P+nDESrlNKk6o
 8EzKhFq6WMDGbcm8hkad6UGs+rc7rm+V1z6dR9vdiS1flnJyUIY05WrkQ4GntkRrYyB3
 U2JU5+ly+cjPGtpBoV6957nPGgXe4v3R7Y0Qx/scVGjvo/UwzNxEdXC/XsDjF6GrmEoA /A== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by aserp2120.oracle.com with ESMTP id 3091m0s0su-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:22 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852YOP062381;
 Wed, 8 Apr 2020 05:05:21 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
 by userp3020.oracle.com with ESMTP id 3091mh1kq2-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:21 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03855KuN030519;
 Wed, 8 Apr 2020 05:05:20 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:20 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 15/26] x86/alternatives: Non-emulated text poking
Date: Tue,  7 Apr 2020 22:03:12 -0700
Message-Id: <20200408050323.4237-16-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 suspectscore=0 bulkscore=0
 mlxlogscore=999 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Patching at runtime needs to handle interdependent pv-ops: as an example,
lock.queued_lock_slowpath(), lock.queued_lock_unlock() and the other
pv_lock_ops are paired and so need to be updated atomically. This is
difficult with emulation because non-patching CPUs could be executing in
critical sections.
(We could apply INT3 everywhere first and then use RCU to force a
barrier but given that spinlocks are everywhere, it still might mean a
lot of time in emulation.)

Second, locking operations can be called from interrupt handlers which
means we cannot trivially use IPIs to introduce a pipeline sync step on
non-patching CPUs.

Third, some pv-ops can be inlined and so we would need to emulate a
broader set of operations than CALL, JMP, NOP*.

Introduce the core state-machine with the actual poking and pipeline
sync stubbed out. This executes via stop_machine() with the primary CPU
carrying out a text_poke_bp() style three-staged algorithm.

The control flow diagram below shows CPU0 as the primary which does the
patching, while the rest of the CPUs (CPUx) execute the sync loop in
text_poke_sync_finish().

 CPU0				    CPUx
 ----                               ----

 patch_worker()			    patch_worker()

   /* Traversal, insn-gen */	      text_poke_sync_finish()
   tps.patch_worker()		      /*
  				       * wait until:
     /* for each patch-site */ 	       *  tps->state == PATCH_DONE
     text_poke_site()		       */
       poke_sync()

  	   ...				       ...

   smp_store_release(&tps->state, PATCH_DONE)

Commits further on flesh out the rest of the code.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
sync_one() uses the following for pipeline synchronization:

+       if (in_nmi())
+               cpuid_eax(1);
+       else
+               sync_core();

The if (in_nmi()) clause is meant to be executed from NMI contexts.
Reading through past LKML discussions cpuid_eax() is probably a
bad choice -- at least in so far as Xen PV is concerned. What
would be a good primitive to use insead?

Also, given that we do handle the nested NMI case, does it make sense
to just use native_iret() (via sync_core()) in NMI contexts well?

---
 arch/x86/kernel/alternative.c | 247 ++++++++++++++++++++++++++++++++++
 1 file changed, 247 insertions(+)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 004fe86f463f..452d4081eded 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -979,6 +979,26 @@ void text_poke_sync(void)
 	on_each_cpu(do_sync_core, NULL, 1);
 }
 
+static void __maybe_unused sync_one(void)
+{
+	/*
+	 * We might be executing in NMI context, and so cannot use
+	 * IRET as a synchronizing instruction.
+	 *
+	 * We could use native_write_cr2() but that is not guaranteed
+	 * to work on Xen-PV -- it is emulated by Xen and might not
+	 * execute an iret (or similar synchronizing instruction)
+	 * internally.
+	 *
+	 * cpuid() would trap as well. Unclear if that's a solution
+	 * either.
+	 */
+	if (in_nmi())
+		cpuid_eax(1);
+	else
+		sync_core();
+}
+
 struct text_poke_loc {
 	s32 rel_addr; /* addr := _stext + rel_addr */
 	union {
@@ -1351,6 +1371,233 @@ void __ref text_poke_bp(void *addr, const void *opcode, size_t len, const void *
 	text_poke_bp_batch(&tp, 1);
 }
 
+struct text_poke_state;
+typedef void (*patch_worker_t)(struct text_poke_state *tps);
+
+/*
+ *                        +-----------possible-BP----------+
+ *                        |                                |
+ *         +--write-INT3--+   +--suffix--+   +-insn-prefix-+
+ *        /               | _/           |__/              |
+ *       /                v'             v                 v
+ * PATCH_SYNC_0    PATCH_SYNC_1    PATCH_SYNC_2   *PATCH_SYNC_DONE*
+ *       \                                                    |`----> PATCH_DONE
+ *        `----------<---------<---------<---------<----------+
+ *
+ * We start in state PATCH_SYNC_DONE and loop through PATCH_SYNC_* states
+ * to end at PATCH_DONE. The primary drives these in text_poke_site()
+ * with patch_worker() making the final transition to PATCH_DONE.
+ * All transitions but the last iteration need to be globally observed.
+ *
+ * On secondary CPUs, text_poke_sync_finish() waits in a cpu_relax()
+ * loop waiting for a transition to PATCH_SYNC_0 at which point it would
+ * start observing transitions until PATCH_SYNC_DONE.
+ * Eventually the master moves to PATCH_DONE and secondary CPUs finish.
+ */
+enum patch_state {
+	/*
+	 * Add an artificial state that we can do a bitwise operation
+	 * over all the PATCH_SYNC_* states.
+	 */
+	PATCH_SYNC_x = 4,
+	PATCH_SYNC_0 = PATCH_SYNC_x | 0,	/* Serialize INT3 */
+	PATCH_SYNC_1 = PATCH_SYNC_x | 1,	/* Serialize rest */
+	PATCH_SYNC_2 = PATCH_SYNC_x | 2,	/* Serialize first opcode */
+	PATCH_SYNC_DONE = PATCH_SYNC_x | 3,	/* Site done, and start state */
+
+	PATCH_DONE = 8,				/* End state */
+};
+
+/*
+ * State for driving text-poking via stop_machine().
+ */
+struct text_poke_state {
+	/* Whatever we are poking */
+	void *stage;
+
+	/* Modules to be processed. */
+	struct list_head *head;
+
+	/*
+	 * Accesses to sync_ack_map are ordered by the primary
+	 * via tps.state.
+	 */
+	struct cpumask sync_ack_map;
+
+	/*
+	 * Generates insn sequences for call-sites to be patched and
+	 * calls text_poke_site() to do the actual poking.
+	 */
+	patch_worker_t	patch_worker;
+
+	/*
+	 * Where are we in the patching state-machine.
+	 */
+	enum patch_state state;
+
+	unsigned int primary_cpu; /* CPU doing the patching. */
+	unsigned int num_acks; /* Number of Acks needed. */
+};
+
+static struct text_poke_state text_poke_state;
+
+/**
+ * poke_sync() - transitions to the specified state.
+ *
+ * @tps - struct text_poke_state *
+ * @state - one of PATCH_SYNC_* states
+ * @offset - offset to be patched
+ * @insns - insns to write
+ * @len - length of insn sequence
+ */
+static void poke_sync(struct text_poke_state *tps, int state, int offset,
+		      const char *insns, int len)
+{
+	/*
+	 * STUB: no patching or synchronization, just go through the
+	 * motions.
+	 */
+	smp_store_release(&tps->state, state);
+}
+
+/**
+ * text_poke_site() - called on the primary to patch a single call site.
+ *
+ * Returns after switching tps->state to PATCH_SYNC_DONE.
+ */
+static void __maybe_unused text_poke_site(struct text_poke_state *tps,
+					  struct text_poke_loc *tp)
+{
+	const unsigned char int3 = INT3_INSN_OPCODE;
+	temp_mm_state_t prev_mm;
+	pte_t *ptep;
+	int offset;
+
+	__text_poke_map(text_poke_addr(tp), tp->native.len, &prev_mm, &ptep);
+
+	offset = offset_in_page(text_poke_addr(tp));
+
+	/*
+	 * All secondary CPUs are waiting in tps->state == PATCH_SYNC_DONE
+	 * to move to PATCH_SYNC_0. Poke the INT3 and wait until all CPUs
+	 * are known to have observed PATCH_SYNC_0.
+	 *
+	 * The earliest we can hit an INT3 is just after the first poke.
+	 */
+	poke_sync(tps, PATCH_SYNC_0, offset, &int3, INT3_INSN_SIZE);
+
+	/* Poke remaining */
+	poke_sync(tps, PATCH_SYNC_1, offset + INT3_INSN_SIZE,
+		  tp->text + INT3_INSN_SIZE, tp->native.len - INT3_INSN_SIZE);
+
+	/*
+	 * Replace the INT3 with the first opcode and force the serializing
+	 * instruction for the last time. Any secondaries in the BP
+	 * handler should be able to move past the INT3 handler after this.
+	 * (See poke_int3_native() for details on this.)
+	 */
+	poke_sync(tps, PATCH_SYNC_2, offset, tp->text, INT3_INSN_SIZE);
+
+	/*
+	 * Force all CPUS to observe PATCH_SYNC_DONE (in the BP handler or
+	 * in text_poke_site()), so they know that this iteration is done
+	 * and it is safe to exit the wait-until-a-sync-is-required loop.
+	 */
+	poke_sync(tps, PATCH_SYNC_DONE, 0, NULL, 0);
+
+	/*
+	 * Unmap the poking_addr, poking_mm.
+	 */
+	__text_poke_unmap(text_poke_addr(tp), tp->text, tp->native.len,
+			  &prev_mm, ptep);
+}
+
+/**
+ * text_poke_sync_finish() -- called to synchronize the CPU pipeline
+ * on secondary CPUs for all patch sites.
+ *
+ * Called in thread context with tps->state == PATCH_SYNC_DONE.
+ * Returns with tps->state == PATCH_DONE.
+ */
+static void text_poke_sync_finish(struct text_poke_state *tps)
+{
+	while (true) {
+		enum patch_state state;
+
+		state = READ_ONCE(tps->state);
+
+		/*
+		 * We aren't doing any actual poking yet, so we don't
+		 * handle any other states.
+		 */
+		if (state == PATCH_DONE)
+			break;
+
+		/*
+		 * Relax here while the primary makes up its mind on
+		 * whether it is done or not.
+		 */
+		cpu_relax();
+	}
+}
+
+static int patch_worker(void *t)
+{
+	int cpu = smp_processor_id();
+	struct text_poke_state *tps = t;
+
+	if (cpu == tps->primary_cpu) {
+		/*
+		 * Generates insns and calls text_poke_site() to do the poking
+		 * and sync.
+		 */
+		tps->patch_worker(tps);
+
+		/*
+		 * We are done patching. Switch the state to PATCH_DONE
+		 * so the secondaries can exit.
+		 */
+		smp_store_release(&tps->state, PATCH_DONE);
+	} else {
+		/* Secondary CPUs spin in a sync_core() state-machine. */
+		text_poke_sync_finish(tps);
+	}
+	return 0;
+}
+
+/**
+ * text_poke_late() -- late patching via stop_machine().
+ *
+ * Called holding the text_mutex.
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
+{
+	int ret;
+
+	lockdep_assert_held(&text_mutex);
+
+	if (system_state != SYSTEM_RUNNING)
+		return -EINVAL;
+
+	text_poke_state.stage = stage;
+	text_poke_state.num_acks = cpumask_weight(cpu_online_mask);
+	text_poke_state.head = &alt_modules;
+
+	text_poke_state.patch_worker = worker;
+	text_poke_state.state = PATCH_SYNC_DONE; /* Start state */
+	text_poke_state.primary_cpu = smp_processor_id();
+
+	/*
+	 * Run the worker on all online CPUs. Don't need to do anything
+	 * for offline CPUs as they come back online with a clean cache.
+	 */
+	ret = stop_machine(patch_worker, &text_poke_state, cpu_online_mask);
+
+	return ret;
+}
+
 #ifdef CONFIG_PARAVIRT_RUNTIME
 struct paravirt_stage_entry {
 	void *dest;	/* pv_op destination */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uL-0002v1-PL; Wed, 08 Apr 2020 05:05:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uK-0002so-4x
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:48 +0000
X-Inumbo-ID: 8c4f2959-7956-11ea-81bb-12813bfff9fa
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8c4f2959-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:23 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03854BNo012923;
 Wed, 8 Apr 2020 05:04:59 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=skSK5dc4HZd1ygvZWCZ0mvu5/IDpVFbzIohZL2fpedY=;
 b=p4M4l8mnkF/etgUggs6AvVrpqtHrBab+6kS2BRdp7uKb7mxGmfZxSjdhraVPNVIOBqW1
 9SsaF2ylBowJOGLHnPtacyQU8Iu1M2C729hNOxufFVU93m1m+cPlYGbixXwwcAptu91a
 Dn7Ljb7dgX5WW5iaPA9CEvwfhOV/51yb4VF9MJYDR7G5sIw8yzijv+pZP4rdMgdHm+uE
 Ul8vqHxMUpyE+BWirc2G54VFigebcGKqdiqjiSB/OQraTshP5IDeg1J9KANEDdF7e95c
 rQTAkrvuRgoaIPmCw1NiQKZoAdBT2OYIgd96D8d+7Iya26gRJrIFVYatZXQuwbpqUWnH dA== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by userp2130.oracle.com with ESMTP id 3091m390vy-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:04:59 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852glC148201;
 Wed, 8 Apr 2020 05:04:58 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by aserp3030.oracle.com with ESMTP id 3091kgj6ng-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:04:58 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03854tSP015092;
 Wed, 8 Apr 2020 05:04:56 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:04:55 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 01/26] x86/paravirt: Specify subsection in PVOP macros
Date: Tue,  7 Apr 2020 22:02:58 -0700
Message-Id: <20200408050323.4237-2-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0
 bulkscore=0 suspectscore=0
 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Allow PVOP macros to specify a subsection such that _paravirt_alt() can
optionally put sites in .parainstructions.*.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/paravirt_types.h | 158 +++++++++++++++++---------
 1 file changed, 102 insertions(+), 56 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 732f62e04ddb..37e8f27a3b9d 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -337,6 +337,9 @@ struct paravirt_patch_template {
 extern struct pv_info pv_info;
 extern struct paravirt_patch_template pv_ops;
 
+/* Sub-section for .parainstructions */
+#define PV_SUFFIX ""
+
 #define PARAVIRT_PATCH(x)					\
 	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
 
@@ -350,9 +353,9 @@ extern struct paravirt_patch_template pv_ops;
  * Generate some code, and mark it as patchable by the
  * apply_paravirt() alternate instruction patcher.
  */
-#define _paravirt_alt(insn_string, type, clobber)	\
+#define _paravirt_alt(sec, insn_string, type, clobber)	\
 	"771:\n\t" insn_string "\n" "772:\n"		\
-	".pushsection .parainstructions,\"a\"\n"	\
+	".pushsection .parainstructions" sec ",\"a\"\n"	\
 	_ASM_ALIGN "\n"					\
 	_ASM_PTR " 771b\n"				\
 	"  .byte " type "\n"				\
@@ -361,8 +364,9 @@ extern struct paravirt_patch_template pv_ops;
 	".popsection\n"
 
 /* Generate patchable code, with the default asm parameters. */
-#define paravirt_alt(insn_string)					\
-	_paravirt_alt(insn_string, "%c[paravirt_typenum]", "%c[paravirt_clobber]")
+#define paravirt_alt(sec, insn_string)					\
+	_paravirt_alt(sec, insn_string, "%c[paravirt_typenum]",		\
+		      "%c[paravirt_clobber]")
 
 /* Simple instruction patching code. */
 #define NATIVE_LABEL(a,x,b) "\n\t.globl " a #x "_" #b "\n" a #x "_" #b ":\n\t"
@@ -414,7 +418,7 @@ int paravirt_disable_iospace(void);
  * unfortunately, are quite a bit (r8 - r11)
  *
  * The call instruction itself is marked by placing its start address
- * and size into the .parainstructions section, so that
+ * and size into the .parainstructions* sections, so that
  * apply_paravirt() in arch/i386/kernel/alternative.c can do the
  * appropriate patching under the control of the backend pv_init_ops
  * implementation.
@@ -512,7 +516,7 @@ int paravirt_disable_iospace(void);
 	})
 
 
-#define ____PVOP_CALL(rettype, op, clbr, call_clbr, extra_clbr,		\
+#define ____PVOP_CALL(sec, rettype, op, clbr, call_clbr, extra_clbr,	\
 		      pre, post, ...)					\
 	({								\
 		rettype __ret;						\
@@ -522,7 +526,7 @@ int paravirt_disable_iospace(void);
 		/* since this condition will never hold */		\
 		if (sizeof(rettype) > sizeof(unsigned long)) {		\
 			asm volatile(pre				\
-				     paravirt_alt(PARAVIRT_CALL)	\
+				     paravirt_alt(sec, PARAVIRT_CALL)	\
 				     post				\
 				     : call_clbr, ASM_CALL_CONSTRAINT	\
 				     : paravirt_type(op),		\
@@ -532,7 +536,7 @@ int paravirt_disable_iospace(void);
 			__ret = (rettype)((((u64)__edx) << 32) | __eax); \
 		} else {						\
 			asm volatile(pre				\
-				     paravirt_alt(PARAVIRT_CALL)	\
+				     paravirt_alt(sec, PARAVIRT_CALL)	\
 				     post				\
 				     : call_clbr, ASM_CALL_CONSTRAINT	\
 				     : paravirt_type(op),		\
@@ -544,22 +548,22 @@ int paravirt_disable_iospace(void);
 		__ret;							\
 	})
 
-#define __PVOP_CALL(rettype, op, pre, post, ...)			\
-	____PVOP_CALL(rettype, op, CLBR_ANY, PVOP_CALL_CLOBBERS,	\
+#define __PVOP_CALL(sec, rettype, op, pre, post, ...)			\
+	____PVOP_CALL(sec, rettype, op, CLBR_ANY, PVOP_CALL_CLOBBERS,	\
 		      EXTRA_CLOBBERS, pre, post, ##__VA_ARGS__)
 
-#define __PVOP_CALLEESAVE(rettype, op, pre, post, ...)			\
-	____PVOP_CALL(rettype, op.func, CLBR_RET_REG,			\
+#define __PVOP_CALLEESAVE(sec, rettype, op, pre, post, ...)		\
+	____PVOP_CALL(sec, rettype, op.func, CLBR_RET_REG,		\
 		      PVOP_CALLEE_CLOBBERS, ,				\
 		      pre, post, ##__VA_ARGS__)
 
 
-#define ____PVOP_VCALL(op, clbr, call_clbr, extra_clbr, pre, post, ...)	\
+#define ____PVOP_VCALL(sec, op, clbr, call_clbr, extra_clbr, pre, post, ...)	\
 	({								\
 		PVOP_VCALL_ARGS;					\
 		PVOP_TEST_NULL(op);					\
 		asm volatile(pre					\
-			     paravirt_alt(PARAVIRT_CALL)		\
+			     paravirt_alt(sec, PARAVIRT_CALL)		\
 			     post					\
 			     : call_clbr, ASM_CALL_CONSTRAINT		\
 			     : paravirt_type(op),			\
@@ -568,85 +572,127 @@ int paravirt_disable_iospace(void);
 			     : "memory", "cc" extra_clbr);		\
 	})
 
-#define __PVOP_VCALL(op, pre, post, ...)				\
-	____PVOP_VCALL(op, CLBR_ANY, PVOP_VCALL_CLOBBERS,		\
+#define __PVOP_VCALL(sec, op, pre, post, ...)				\
+	____PVOP_VCALL(sec, op, CLBR_ANY, PVOP_VCALL_CLOBBERS,		\
 		       VEXTRA_CLOBBERS,					\
 		       pre, post, ##__VA_ARGS__)
 
-#define __PVOP_VCALLEESAVE(op, pre, post, ...)				\
-	____PVOP_VCALL(op.func, CLBR_RET_REG,				\
+#define __PVOP_VCALLEESAVE(sec, op, pre, post, ...)			\
+	____PVOP_VCALL(sec, op.func, CLBR_RET_REG,			\
 		      PVOP_VCALLEE_CLOBBERS, ,				\
 		      pre, post, ##__VA_ARGS__)
 
 
 
-#define PVOP_CALL0(rettype, op)						\
-	__PVOP_CALL(rettype, op, "", "")
-#define PVOP_VCALL0(op)							\
-	__PVOP_VCALL(op, "", "")
+#define _PVOP_CALL0(sec, rettype, op)					\
+	__PVOP_CALL(sec, rettype, op, "", "")
+#define _PVOP_VCALL0(sec, op)						\
+	__PVOP_VCALL(sec, op, "", "")
 
-#define PVOP_CALLEE0(rettype, op)					\
-	__PVOP_CALLEESAVE(rettype, op, "", "")
-#define PVOP_VCALLEE0(op)						\
-	__PVOP_VCALLEESAVE(op, "", "")
+#define _PVOP_CALLEE0(sec, rettype, op)					\
+	__PVOP_CALLEESAVE(sec, rettype, op, "", "")
+#define _PVOP_VCALLEE0(sec, op)						\
+	__PVOP_VCALLEESAVE(sec, op, "", "")
 
 
-#define PVOP_CALL1(rettype, op, arg1)					\
-	__PVOP_CALL(rettype, op, "", "", PVOP_CALL_ARG1(arg1))
-#define PVOP_VCALL1(op, arg1)						\
-	__PVOP_VCALL(op, "", "", PVOP_CALL_ARG1(arg1))
+#define _PVOP_CALL1(sec, rettype, op, arg1)				\
+	__PVOP_CALL(sec, rettype, op, "", "", PVOP_CALL_ARG1(arg1))
+#define _PVOP_VCALL1(sec, op, arg1)					\
+	__PVOP_VCALL(sec, op, "", "", PVOP_CALL_ARG1(arg1))
 
-#define PVOP_CALLEE1(rettype, op, arg1)					\
-	__PVOP_CALLEESAVE(rettype, op, "", "", PVOP_CALL_ARG1(arg1))
-#define PVOP_VCALLEE1(op, arg1)						\
-	__PVOP_VCALLEESAVE(op, "", "", PVOP_CALL_ARG1(arg1))
+#define _PVOP_CALLEE1(sec, rettype, op, arg1)				\
+	__PVOP_CALLEESAVE(sec, rettype, op, "", "", PVOP_CALL_ARG1(arg1))
+#define _PVOP_VCALLEE1(sec, op, arg1)					\
+	__PVOP_VCALLEESAVE(sec, op, "", "", PVOP_CALL_ARG1(arg1))
 
-
-#define PVOP_CALL2(rettype, op, arg1, arg2)				\
-	__PVOP_CALL(rettype, op, "", "", PVOP_CALL_ARG1(arg1),		\
+#define _PVOP_CALL2(sec, rettype, op, arg1, arg2)			\
+	__PVOP_CALL(sec, rettype, op, "", "", PVOP_CALL_ARG1(arg1),	\
 		    PVOP_CALL_ARG2(arg2))
-#define PVOP_VCALL2(op, arg1, arg2)					\
-	__PVOP_VCALL(op, "", "", PVOP_CALL_ARG1(arg1),			\
+#define _PVOP_VCALL2(sec, op, arg1, arg2)				\
+	__PVOP_VCALL(sec, op, "", "", PVOP_CALL_ARG1(arg1),		\
 		     PVOP_CALL_ARG2(arg2))
 
-#define PVOP_CALLEE2(rettype, op, arg1, arg2)				\
-	__PVOP_CALLEESAVE(rettype, op, "", "", PVOP_CALL_ARG1(arg1),	\
+#define _PVOP_CALLEE2(sec, rettype, op, arg1, arg2)			\
+	__PVOP_CALLEESAVE(sec, rettype, op, "", "", PVOP_CALL_ARG1(arg1), \
 			  PVOP_CALL_ARG2(arg2))
-#define PVOP_VCALLEE2(op, arg1, arg2)					\
-	__PVOP_VCALLEESAVE(op, "", "", PVOP_CALL_ARG1(arg1),		\
+#define _PVOP_VCALLEE2(sec, op, arg1, arg2)				\
+	__PVOP_VCALLEESAVE(sec, op, "", "", PVOP_CALL_ARG1(arg1),	\
 			   PVOP_CALL_ARG2(arg2))
 
 
-#define PVOP_CALL3(rettype, op, arg1, arg2, arg3)			\
-	__PVOP_CALL(rettype, op, "", "", PVOP_CALL_ARG1(arg1),		\
+#define _PVOP_CALL3(sec, rettype, op, arg1, arg2, arg3)			\
+	__PVOP_CALL(sec, rettype, op, "", "", PVOP_CALL_ARG1(arg1),	\
 		    PVOP_CALL_ARG2(arg2), PVOP_CALL_ARG3(arg3))
-#define PVOP_VCALL3(op, arg1, arg2, arg3)				\
-	__PVOP_VCALL(op, "", "", PVOP_CALL_ARG1(arg1),			\
+#define _PVOP_VCALL3(sec, op, arg1, arg2, arg3)				\
+	__PVOP_VCALL(sec, op, "", "", PVOP_CALL_ARG1(arg1),		\
 		     PVOP_CALL_ARG2(arg2), PVOP_CALL_ARG3(arg3))
 
 /* This is the only difference in x86_64. We can make it much simpler */
 #ifdef CONFIG_X86_32
-#define PVOP_CALL4(rettype, op, arg1, arg2, arg3, arg4)			\
-	__PVOP_CALL(rettype, op,					\
+#define _PVOP_CALL4(sec, rettype, op, arg1, arg2, arg3, arg4)		\
+	__PVOP_CALL(sec, rettype, op,					\
 		    "push %[_arg4];", "lea 4(%%esp),%%esp;",		\
 		    PVOP_CALL_ARG1(arg1), PVOP_CALL_ARG2(arg2),		\
 		    PVOP_CALL_ARG3(arg3), [_arg4] "mr" ((u32)(arg4)))
-#define PVOP_VCALL4(op, arg1, arg2, arg3, arg4)				\
-	__PVOP_VCALL(op,						\
+#define _PVOP_VCALL4(sec, op, arg1, arg2, arg3, arg4)			\
+	__PVOP_VCALL(sec, op,						\
 		    "push %[_arg4];", "lea 4(%%esp),%%esp;",		\
 		    "0" ((u32)(arg1)), "1" ((u32)(arg2)),		\
 		    "2" ((u32)(arg3)), [_arg4] "mr" ((u32)(arg4)))
 #else
-#define PVOP_CALL4(rettype, op, arg1, arg2, arg3, arg4)			\
-	__PVOP_CALL(rettype, op, "", "",				\
+#define _PVOP_CALL4(sec, rettype, op, arg1, arg2, arg3, arg4)		\
+	__PVOP_CALL(sec, rettype, op, "", "",				\
 		    PVOP_CALL_ARG1(arg1), PVOP_CALL_ARG2(arg2),		\
 		    PVOP_CALL_ARG3(arg3), PVOP_CALL_ARG4(arg4))
-#define PVOP_VCALL4(op, arg1, arg2, arg3, arg4)				\
-	__PVOP_VCALL(op, "", "",					\
+#define _PVOP_VCALL4(sec, op, arg1, arg2, arg3, arg4)			\
+	__PVOP_VCALL(sec, op, "", "",					\
 		     PVOP_CALL_ARG1(arg1), PVOP_CALL_ARG2(arg2),	\
 		     PVOP_CALL_ARG3(arg3), PVOP_CALL_ARG4(arg4))
 #endif
 
+/*
+ * PVOP macros for .parainstructions
+ */
+#define PVOP_CALL0(rettype, op)						\
+	_PVOP_CALL0(PV_SUFFIX, rettype, op)
+#define PVOP_VCALL0(op)							\
+	_PVOP_VCALL0(PV_SUFFIX, op)
+
+#define PVOP_CALLEE0(rettype, op)					\
+	_PVOP_CALLEE0(PV_SUFFIX, rettype, op)
+#define PVOP_VCALLEE0(op)						\
+	_PVOP_VCALLEE0(PV_SUFFIX, op)
+
+#define PVOP_CALL1(rettype, op, arg1)					\
+	_PVOP_CALL1(PV_SUFFIX, rettype, op, arg1)
+#define PVOP_VCALL1(op, arg1)						\
+	_PVOP_VCALL1(PV_SUFFIX, op, arg1)
+
+#define PVOP_CALLEE1(rettype, op, arg1)					\
+	_PVOP_CALLEE1(PV_SUFFIX, rettype, op, arg1)
+#define PVOP_VCALLEE1(op, arg1)						\
+	_PVOP_VCALLEE1(PV_SUFFIX, op, arg1)
+
+#define PVOP_CALL2(rettype, op, arg1, arg2)				\
+	_PVOP_CALL2(PV_SUFFIX, rettype, op, arg1, arg2)
+#define PVOP_VCALL2(op, arg1, arg2)					\
+	_PVOP_VCALL2(PV_SUFFIX, op, arg1, arg2)
+
+#define PVOP_CALLEE2(rettype, op, arg1, arg2)				\
+	_PVOP_CALLEE2(PV_SUFFIX, rettype, op, arg1, arg2)
+#define PVOP_VCALLEE2(op, arg1, arg2)					\
+	_PVOP_VCALLEE2(PV_SUFFIX, op, arg1, arg2)
+
+#define PVOP_CALL3(rettype, op, arg1, arg2, arg3)			\
+	_PVOP_CALL3(PV_SUFFIX, rettype, op, arg1, arg2, arg3)
+#define PVOP_VCALL3(op, arg1, arg2, arg3)				\
+	_PVOP_VCALL3(PV_SUFFIX, op, arg1, arg2, arg3)
+
+#define PVOP_CALL4(rettype, op, arg1, arg2, arg3, arg4)			\
+	_PVOP_CALL4(PV_SUFFIX, rettype, op, arg1, arg2, arg3, arg4)
+#define PVOP_VCALL4(op, arg1, arg2, arg3, arg4)				\
+	_PVOP_VCALL4(PV_SUFFIX, op, arg1, arg2, arg3, arg4)
+
 /* Lazy mode for batching updates / context switch */
 enum paravirt_lazy_mode {
 	PARAVIRT_LAZY_NONE,
@@ -667,7 +713,7 @@ u64 _paravirt_ident_64(u64);
 
 #define paravirt_nop	((void *)_paravirt_nop)
 
-/* These all sit in the .parainstructions section to tell us what to patch. */
+/* These all sit in .parainstructions* sections to tell us what to patch. */
 struct paravirt_patch_site {
 	u8 *instr;		/* original instructions */
 	u8 type;		/* type of this instruction */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uQ-00030P-4L; Wed, 08 Apr 2020 05:05:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uO-0002yJ-IS
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:52 +0000
X-Inumbo-ID: 91086a2c-7956-11ea-b4f4-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 91086a2c-7956-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 05:05:30 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03854gSa191662;
 Wed, 8 Apr 2020 05:05:24 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=oFQu5c5XJMNWspifH0eo8iyuqi9GZvEBODJQANlcAEo=;
 b=cHnvTrtu81AYis8bhTT0uEby3pTuev6G236CP0PzsfSaOXZPYSInf2z4ytK/OtlP6l24
 Lqi3soKd+woQHGRwBladzfjWwRG2mMJiBf5q0t5K8EPT8EPGhaBSBmky2zhwDcMKpVSP
 AAwuDpZW8mEghBQKJXTcrojf3l5DiOFTj6Z/hRPELctygYmKOxqDrr9GLWPsIYm094qi
 IOpH5F7Ex36yPu5jdMQNcVLsQ+ePyT41+S9Df0QQ6H1+9kX7uxdU3Fm5nlrsEVBGHMHj
 DDWUYplrA9rMgTvIwH9LSQkK1sa2aRpXCCa/GSuBz4lkk4MycLL5tMA60Ghjs06yJO/2 RQ== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by aserp2120.oracle.com with ESMTP id 3091m0s0sw-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:23 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03851W8H100632;
 Wed, 8 Apr 2020 05:05:23 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by aserp3020.oracle.com with ESMTP id 3091m2hv9g-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:23 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03855MKx007459;
 Wed, 8 Apr 2020 05:05:22 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:22 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 17/26] x86/alternatives: Add patching logic in
 text_poke_site()
Date: Tue,  7 Apr 2020 22:03:14 -0700
Message-Id: <20200408050323.4237-18-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 mlxscore=0
 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add actual poking and pipeline sync logic in poke_sync(). This is called
from text_poke_site()).

The patching logic is similar to that in text_poke_bp_batch() where we
patch the first byte with an INT3, which serves as a barrier, then patch
the remaining bytes and then come back and fixup the first byte.

The first and the last steps are single byte writes and are thus
atomic, and the second step is protected because the INT3 serves
as a barrier.

Between each of these steps is a global pipeline sync which ensures that
remote pipelines flush out any stale opcodes that they might have cached.
This is driven from poke_sync() where the primary introduces a sync_core()
on secondary CPUs for every PATCH_SYNC_* state change. The corresponding
loop on the secondary executes in text_poke_sync_site().

Note that breakpoints are not handled yet.

 CPU0                                CPUx
 ----                                ----

 patch_worker()                      patch_worker()

   /* Traversal, insn-gen */           text_poke_sync_finish()
   tps.patch_worker()                    /* wait until:
     /* = paravirt_worker() */            *  tps->state == PATCH_DONE
                                          */
                  /* for each patch-site */
     generate_paravirt()
       runtime_patch()
     text_poke_site()                    text_poke_sync_site()
        poke_sync()                       /* for each:
          __text_do_poke()                 *  PATCH_SYNC_[012] */
          sync_one()                       sync_one()
          ack()                            ack()
          wait_for_acks()

           ...                                 ...

  smp_store_release(&tps->state, PATCH_DONE)

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/kernel/alternative.c | 103 +++++++++++++++++++++++++++++++---
 1 file changed, 95 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 1c5acdc4f349..7fdaae9edbf0 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -1441,27 +1441,57 @@ struct text_poke_state {
 
 static struct text_poke_state text_poke_state;
 
+static void wait_for_acks(struct text_poke_state *tps)
+{
+	int cpu = smp_processor_id();
+
+	cpumask_set_cpu(cpu, &tps->sync_ack_map);
+
+	/* Wait until all CPUs are known to have observed the state change. */
+	while (cpumask_weight(&tps->sync_ack_map) < tps->num_acks)
+		cpu_relax();
+}
+
 /**
- * poke_sync() - transitions to the specified state.
+ * poke_sync() - carries out one poke-step for a single site and
+ * transitions to the specified state.
+ * Called with the target populated in poking_mm and poking_addr.
  *
  * @tps - struct text_poke_state *
  * @state - one of PATCH_SYNC_* states
  * @offset - offset to be patched
  * @insns - insns to write
  * @len - length of insn sequence
+ *
+ * Returns after all CPUs have observed the state change and called
+ * sync_core().
  */
 static void poke_sync(struct text_poke_state *tps, int state, int offset,
 		      const char *insns, int len)
 {
+	if (len)
+		__text_do_poke(offset, insns, len);
 	/*
-	 * STUB: no patching or synchronization, just go through the
-	 * motions.
+	 * Stores to tps.sync_ack_map are ordered with
+	 * smp_load_acquire(tps->state) in text_poke_sync_site()
+	 * so we can safely clear the cpumask.
 	 */
 	smp_store_release(&tps->state, state);
+
+	cpumask_clear(&tps->sync_ack_map);
+
+	/*
+	 * Introduce a synchronizing instruction in local and remote insn
+	 * streams. This flushes any stale cached uops from CPU pipelines.
+	 */
+	sync_one();
+
+	wait_for_acks(tps);
 }
 
 /**
  * text_poke_site() - called on the primary to patch a single call site.
+ * The interlocking sync work on the secondary is done in text_poke_sync_site().
  *
  * Called in thread context with tps->state == PATCH_SYNC_DONE where it
  * takes tps->state through different PATCH_SYNC_* states, returning
@@ -1514,6 +1544,43 @@ static void __maybe_unused text_poke_site(struct text_poke_state *tps,
 			  &prev_mm, ptep);
 }
 
+/**
+ * text_poke_sync_site() -- called to synchronize the CPU pipeline
+ * on secondary CPUs for each patch site.
+ *
+ * Called in thread context with tps->state == PATCH_SYNC_0.
+ *
+ * Returns after having observed tps->state == PATCH_SYNC_DONE.
+ */
+static void text_poke_sync_site(struct text_poke_state *tps)
+{
+	int cpu = smp_processor_id();
+	int prevstate = -1;
+	int acked;
+
+	/*
+	 * In thread context we arrive here expecting tps->state to move
+	 * in-order from PATCH_SYNC_{0 -> 1 -> 2} -> PATCH_SYNC_DONE.
+	 */
+	do {
+		/*
+		 * Wait until there's some work for us to do.
+		 */
+		smp_cond_load_acquire(&tps->state,
+				      prevstate != VAL);
+
+		prevstate = READ_ONCE(tps->state);
+
+		if (prevstate < PATCH_SYNC_DONE) {
+			acked = cpumask_test_cpu(cpu, &tps->sync_ack_map);
+
+			BUG_ON(acked);
+			sync_one();
+			cpumask_set_cpu(cpu, &tps->sync_ack_map);
+		}
+	} while (prevstate < PATCH_SYNC_DONE);
+}
+
 /**
  * text_poke_sync_finish() -- called to synchronize the CPU pipeline
  * on secondary CPUs for all patch sites.
@@ -1525,6 +1592,7 @@ static void text_poke_sync_finish(struct text_poke_state *tps)
 {
 	while (true) {
 		enum patch_state state;
+		int cpu = smp_processor_id();
 
 		state = READ_ONCE(tps->state);
 
@@ -1535,11 +1603,24 @@ static void text_poke_sync_finish(struct text_poke_state *tps)
 		if (state == PATCH_DONE)
 			break;
 
-		/*
-		 * Relax here while the primary makes up its mind on
-		 * whether it is done or not.
-		 */
-		cpu_relax();
+		if (state == PATCH_SYNC_DONE) {
+			/*
+			 * Ack that we've seen the end of this iteration
+			 * and then wait until everybody's ready to move
+			 * to the next iteration or exit.
+			 */
+			cpumask_set_cpu(cpu, &tps->sync_ack_map);
+			smp_cond_load_acquire(&tps->state,
+					      (state != VAL));
+		} else if (state == PATCH_SYNC_0) {
+			/*
+			 * PATCH_SYNC_1, PATCH_SYNC_2 are handled
+			 * inside text_poke_sync_site().
+			 */
+			text_poke_sync_site(tps);
+		} else {
+			BUG();
+		}
 	}
 }
 
@@ -1549,6 +1630,12 @@ static int patch_worker(void *t)
 	struct text_poke_state *tps = t;
 
 	if (cpu == tps->primary_cpu) {
+		/*
+		 * The init state is PATCH_SYNC_DONE. Wait until the
+		 * secondaries have assembled before we start patching.
+		 */
+		wait_for_acks(tps);
+
 		/*
 		 * Generates insns and calls text_poke_site() to do the poking
 		 * and sync.
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uQ-000310-G1; Wed, 08 Apr 2020 05:05:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uP-0002zD-4v
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:53 +0000
X-Inumbo-ID: 90330a76-7956-11ea-81bb-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 90330a76-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:28 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853CfU179598;
 Wed, 8 Apr 2020 05:05:21 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=632WiNiqidlUZOdyno4pYxOiJK2oE9HYRPcYujYQMXU=;
 b=Rt+HodiYBj5Vb8Zcpm5nlLZpKAa6m/3Me62if7vHull0ZIhUTtFjGOAn/+tC+6LZx/s5
 fWpl9LbV8Yuyja7tnLkLiXAHctrL58Ve4BTXafjLRAM/XX3zy8q/UIj2/ReIGVT2IBuH
 oM+WGXSm1tZkS2XoxZpFTkj1VIebdFyTCIcZnizTL6m+tmMN2LmnT2VJ3tPL9TziklGz
 EAHBitysknFBJmR4mH6Jh/4m9KSZ7GiZiN4mFr57C7s3/0vzhRjmK/pDDi8bZjTJ/kfo
 Vvh1eEiPIFAbNsqCP8LamGtP0+lgmmfW13oBvy75XnqPHLHyzzKUIQi9as99IYUqMZjr zQ== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by userp2120.oracle.com with ESMTP id 3091mnh14q-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:21 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03851Wbv100720;
 Wed, 8 Apr 2020 05:05:21 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by aserp3020.oracle.com with ESMTP id 3091m2hv5d-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:20 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03855Jem015242;
 Wed, 8 Apr 2020 05:05:19 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:18 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 14/26] x86/alternatives: Handle native insns in
 text_poke_loc*()
Date: Tue,  7 Apr 2020 22:03:11 -0700
Message-Id: <20200408050323.4237-15-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 mlxscore=0
 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 mlxlogscore=999 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0
 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Intended to handle scenarios where we might want to patch arbitrary
instructions (ex. inlined opcodes in pv_lock_ops.)

Users for native mode (as opposed to emulated) are introduced in
later patches.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/text-patching.h |  4 +-
 arch/x86/kernel/alternative.c        | 61 ++++++++++++++++++++--------
 2 files changed, 45 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h
index 04778c2bc34e..c4b2814f2f9d 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -25,10 +25,10 @@ static inline void apply_paravirt(struct paravirt_patch_site *start,
 
 /*
  * Currently, the max observed size in the kernel code is
- * JUMP_LABEL_NOP_SIZE/RELATIVEJUMP_SIZE, which are 5.
+ * NOP7 for indirect call, which is 7.
  * Raise it if needed.
  */
-#define POKE_MAX_OPCODE_SIZE	5
+#define POKE_MAX_OPCODE_SIZE	7
 
 extern void text_poke_early(void *addr, const void *opcode, size_t len);
 
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 337aad8c2521..004fe86f463f 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -981,8 +981,15 @@ void text_poke_sync(void)
 
 struct text_poke_loc {
 	s32 rel_addr; /* addr := _stext + rel_addr */
-	s32 rel32;
-	u8 opcode;
+	union {
+		struct {
+			s32 rel32;
+			u8 opcode;
+		} emulated;
+		struct {
+			u8 len;
+		} native;
+	};
 	const u8 text[POKE_MAX_OPCODE_SIZE];
 };
 
@@ -990,6 +997,7 @@ struct bp_patching_desc {
 	struct text_poke_loc *vec;
 	int nr_entries;
 	atomic_t refs;
+	bool native;
 };
 
 static struct bp_patching_desc *bp_desc;
@@ -1071,10 +1079,13 @@ int notrace poke_int3_handler(struct pt_regs *regs)
 			goto out_put;
 	}
 
-	len = text_opcode_size(tp->opcode);
+	if (desc->native)
+		BUG();
+
+	len = text_opcode_size(tp->emulated.opcode);
 	ip += len;
 
-	switch (tp->opcode) {
+	switch (tp->emulated.opcode) {
 	case INT3_INSN_OPCODE:
 		/*
 		 * Someone poked an explicit INT3, they'll want to handle it,
@@ -1083,12 +1094,12 @@ int notrace poke_int3_handler(struct pt_regs *regs)
 		goto out_put;
 
 	case CALL_INSN_OPCODE:
-		int3_emulate_call(regs, (long)ip + tp->rel32);
+		int3_emulate_call(regs, (long)ip + tp->emulated.rel32);
 		break;
 
 	case JMP32_INSN_OPCODE:
 	case JMP8_INSN_OPCODE:
-		int3_emulate_jmp(regs, (long)ip + tp->rel32);
+		int3_emulate_jmp(regs, (long)ip + tp->emulated.rel32);
 		break;
 
 	default:
@@ -1134,6 +1145,7 @@ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries
 		.vec = tp,
 		.nr_entries = nr_entries,
 		.refs = ATOMIC_INIT(1),
+		.native = false,
 	};
 	unsigned char int3 = INT3_INSN_OPCODE;
 	unsigned int i;
@@ -1161,7 +1173,7 @@ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries
 	 * Second step: update all but the first byte of the patched range.
 	 */
 	for (do_sync = 0, i = 0; i < nr_entries; i++) {
-		int len = text_opcode_size(tp[i].opcode);
+		int len = text_opcode_size(tp[i].emulated.opcode);
 
 		if (len - INT3_INSN_SIZE > 0) {
 			text_poke(text_poke_addr(&tp[i]) + INT3_INSN_SIZE,
@@ -1205,11 +1217,25 @@ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries
 }
 
 static void text_poke_loc_init(struct text_poke_loc *tp, void *addr,
-			       const void *opcode, size_t len, const void *emulate)
+			       const void *opcode, size_t len,
+			       const void *emulate, bool native)
 {
 	struct insn insn;
 
+	memset((void *)tp, 0, sizeof(*tp));
 	memcpy((void *)tp->text, opcode, len);
+
+	tp->rel_addr = addr - (void *)_stext;
+
+	/*
+	 * Native mode: when we might be poking
+	 * arbitrary (perhaps) multiple instructions.
+	 */
+	if (native) {
+		tp->native.len = (u8)len;
+		return;
+	}
+
 	if (!emulate)
 		emulate = opcode;
 
@@ -1219,31 +1245,30 @@ static void text_poke_loc_init(struct text_poke_loc *tp, void *addr,
 	BUG_ON(!insn_complete(&insn));
 	BUG_ON(len != insn.length);
 
-	tp->rel_addr = addr - (void *)_stext;
-	tp->opcode = insn.opcode.bytes[0];
+	tp->emulated.opcode = insn.opcode.bytes[0];
 
-	switch (tp->opcode) {
+	switch (tp->emulated.opcode) {
 	case INT3_INSN_OPCODE:
 		break;
 
 	case CALL_INSN_OPCODE:
 	case JMP32_INSN_OPCODE:
 	case JMP8_INSN_OPCODE:
-		tp->rel32 = insn.immediate.value;
+		tp->emulated.rel32 = insn.immediate.value;
 		break;
 
 	default: /* assume NOP */
 		switch (len) {
 		case 2: /* NOP2 -- emulate as JMP8+0 */
 			BUG_ON(memcmp(emulate, ideal_nops[len], len));
-			tp->opcode = JMP8_INSN_OPCODE;
-			tp->rel32 = 0;
+			tp->emulated.opcode = JMP8_INSN_OPCODE;
+			tp->emulated.rel32 = 0;
 			break;
 
 		case 5: /* NOP5 -- emulate as JMP32+0 */
 			BUG_ON(memcmp(emulate, ideal_nops[NOP_ATOMIC5], len));
-			tp->opcode = JMP32_INSN_OPCODE;
-			tp->rel32 = 0;
+			tp->emulated.opcode = JMP32_INSN_OPCODE;
+			tp->emulated.rel32 = 0;
 			break;
 
 		default: /* unknown instruction */
@@ -1299,7 +1324,7 @@ void __ref text_poke_queue(void *addr, const void *opcode, size_t len, const voi
 	text_poke_flush(addr);
 
 	tp = &tp_vec[tp_vec_nr++];
-	text_poke_loc_init(tp, addr, opcode, len, emulate);
+	text_poke_loc_init(tp, addr, opcode, len, emulate, false);
 }
 
 /**
@@ -1322,7 +1347,7 @@ void __ref text_poke_bp(void *addr, const void *opcode, size_t len, const void *
 		return;
 	}
 
-	text_poke_loc_init(&tp, addr, opcode, len, emulate);
+	text_poke_loc_init(&tp, addr, opcode, len, emulate, false);
 	text_poke_bp_batch(&tp, 1);
 }
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uV-00036Z-1Z; Wed, 08 Apr 2020 05:05:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uT-00034v-Iw
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:57 +0000
X-Inumbo-ID: 91e0d808-7956-11ea-b4f4-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 91e0d808-7956-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 05:05:31 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853tXe191207;
 Wed, 8 Apr 2020 05:05:25 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=CcwUPFYBMcHTPmOlaOoTSoN9P8fiON3G468Rwi+IExw=;
 b=PWi7i/Tl/Y/4IqFE9IYynQEmMUAL6h7KzUdGeQ8aowN7A2vG8aYJ2y1RPUpSFuJ3Al9p
 YwS1TqaOr8c7YrFYOyShMVhWKNWUtudifHat6cRswuPKLXRwcDy1ydKrAXiPIjl6lopM
 RMjHL24gyXWl/nW8A2qcjwXVsP1PZ3/0r+Im3dLJe5hFqWgI0VDvD9B0ICCD6mvtFn3w
 T50v9VWj4ITUUPDhFU4ejXZXdJYGwsLCualChOYeup/fi8BrQuX5+Iys4L4ZzuqJoJTd
 s99H+9vRPTV9un6VQffzowPsPPsbizyuvOJDx6hBeNIF4jIAX6jEt3+aYp275E6ry4xO kA== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by aserp2120.oracle.com with ESMTP id 3091m0s0sx-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:25 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852gSW148301;
 Wed, 8 Apr 2020 05:05:24 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
 by aserp3030.oracle.com with ESMTP id 3091kgj7gq-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:24 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03855OXP030617;
 Wed, 8 Apr 2020 05:05:24 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:23 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 18/26] x86/alternatives: Handle BP in non-emulated text
 poking
Date: Tue,  7 Apr 2020 22:03:15 -0700
Message-Id: <20200408050323.4237-19-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0
 bulkscore=0 suspectscore=0
 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Handle breakpoints if we hit an INT3 either by way of an NMI while
patching a site in the NMI handling path, or if we are patching text
in text_poke_site() (executes on the primary), or in the pipeline sync
path in text_poke_sync_site() (executes on secondary CPUs.)
(The last two are not expected to happen, but see below.)

The handling on the primary CPU is to update the insn stream locally
such that we can return to the primary patching loop but not force
the secondary CPUs to execute sync_core().

>From my reading of the Intel spec and the thread which laid down the
INT3 approach: https//lore.kernel.org/lkml/4B4D02B8.5020801@zytor.com,
skipping the sync_core() would mean that remote pipelines -- if they
have relevant uops cached would not see the updated instruction and
would continue to execute stale uops.

This is safe because the primary eventually gets back to the patching
loop in text_poke_site() and resumes the state-machine, re-writing
some of the insn sequences just written in the BP handling and forcing
the secondary CPUs to execute sync_core().

The handling on the secondary, is to call text_poke_sync_site() just as
in thread-context, so it contains acking the patch states such that the
primary can continue making forward progress. This can be called in a
re-entrant fashion.

Note that this does mean that we cannot handle any patches in
text_poke_sync_site() itself since that would end up being called
recursively in the BP handler.

Control flow diagram with the BP handler:

 CPU0-BP                             CPUx-BP
 -------                             -------

 poke_int3_native()                  poke_int3_native()
   __text_do_poke()         	       text_poke_sync_site()
   sync_one()               	        /* for state in:
                                         *  [PATCH_SYNC_y.._SYNC_DONE) */
                                         sync_one()
                                         ack()


 CPU0                                CPUx
 ----                                ----

 patch_worker()                      patch_worker()

   /* Traversal, insn-gen */           text_poke_sync_finish()
   tps.patch_worker()                    /* wait until:
     /* = paravirt_worker() */            *  tps->state == PATCH_DONE
                                          */
                 /* for each patch-site */
     generate_paravirt()
       runtime_patch()
     text_poke_site()                    text_poke_sync_site()
        poke_sync()                       /* for state in:
          __text_do_poke()                 *  [PATCH_SYNC_0..PATCH_SYNC_y]
          sync_one()                       */
          ack()                            sync_one()
          wait_for_acks()                  ack()

           ...                                 ...

   smp_store_release(&tps->state, PATCH_DONE)

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/kernel/alternative.c | 145 ++++++++++++++++++++++++++++++++--
 1 file changed, 137 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 7fdaae9edbf0..c68d940356a2 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -1055,6 +1055,8 @@ static int notrace patch_cmp(const void *key, const void *elt)
 }
 NOKPROBE_SYMBOL(patch_cmp);
 
+static void poke_int3_native(struct pt_regs *regs,
+			     struct text_poke_loc *tp);
 int notrace poke_int3_handler(struct pt_regs *regs)
 {
 	struct bp_patching_desc *desc;
@@ -1099,8 +1101,11 @@ int notrace poke_int3_handler(struct pt_regs *regs)
 			goto out_put;
 	}
 
-	if (desc->native)
-		BUG();
+	if (desc->native) {
+		poke_int3_native(regs, tp);
+		ret = 1; /* handled */
+		goto out_put;
+	}
 
 	len = text_opcode_size(tp->emulated.opcode);
 	ip += len;
@@ -1469,8 +1474,15 @@ static void wait_for_acks(struct text_poke_state *tps)
 static void poke_sync(struct text_poke_state *tps, int state, int offset,
 		      const char *insns, int len)
 {
-	if (len)
+	if (len) {
+		/*
+		 * Note that we could hit a BP right after patching memory
+		 * below. This could happen before the state change further
+		 * down. The primary BP handler allows us to make
+		 * forward-progress in that case.
+		 */
 		__text_do_poke(offset, insns, len);
+	}
 	/*
 	 * Stores to tps.sync_ack_map are ordered with
 	 * smp_load_acquire(tps->state) in text_poke_sync_site()
@@ -1504,11 +1516,22 @@ static void __maybe_unused text_poke_site(struct text_poke_state *tps,
 	temp_mm_state_t prev_mm;
 	pte_t *ptep;
 	int offset;
+	struct bp_patching_desc desc = {
+		.vec = tp,
+		.nr_entries = 1,
+		.native = true,
+		.refs = ATOMIC_INIT(1),
+	};
 
 	__text_poke_map(text_poke_addr(tp), tp->native.len, &prev_mm, &ptep);
 
 	offset = offset_in_page(text_poke_addr(tp));
 
+	/*
+	 * For INT3 use the same exclusion logic as BP emulation path.
+	 */
+	smp_store_release(&bp_desc, &desc); /* rcu_assign_pointer */
+
 	/*
 	 * All secondary CPUs are waiting in tps->state == PATCH_SYNC_DONE
 	 * to move to PATCH_SYNC_0. Poke the INT3 and wait until all CPUs
@@ -1537,6 +1560,19 @@ static void __maybe_unused text_poke_site(struct text_poke_state *tps,
 	 */
 	poke_sync(tps, PATCH_SYNC_DONE, 0, NULL, 0);
 
+	/*
+	 * All CPUs have ack'd PATCH_SYNC_DONE. So there can be no
+	 * laggard CPUs executing BP handlers. Reset bp_desc.
+	 */
+	WRITE_ONCE(bp_desc, NULL); /* RCU_INIT_POINTER */
+
+	/*
+	 * We've already done the synchronization so this should not
+	 * race.
+	 */
+	if (!atomic_dec_and_test(&desc.refs))
+		atomic_cond_read_acquire(&desc.refs, !VAL);
+
 	/*
 	 * Unmap the poking_addr, poking_mm.
 	 */
@@ -1548,7 +1584,8 @@ static void __maybe_unused text_poke_site(struct text_poke_state *tps,
  * text_poke_sync_site() -- called to synchronize the CPU pipeline
  * on secondary CPUs for each patch site.
  *
- * Called in thread context with tps->state == PATCH_SYNC_0.
+ * Called in thread context with tps->state == PATCH_SYNC_0 and in
+ * BP context with tps->state < PATCH_SYNC_DONE.
  *
  * Returns after having observed tps->state == PATCH_SYNC_DONE.
  */
@@ -1561,6 +1598,26 @@ static void text_poke_sync_site(struct text_poke_state *tps)
 	/*
 	 * In thread context we arrive here expecting tps->state to move
 	 * in-order from PATCH_SYNC_{0 -> 1 -> 2} -> PATCH_SYNC_DONE.
+	 *
+	 * We could also arrive here in BP-context some point after having
+	 * observed bp_patching.nr_entries (and after poking the first INT3.)
+	 * This could happen by way of an NMI while we are patching a site
+	 * that'll get executed in the NMI handler, or if we hit a site
+	 * being patched in text_poke_sync_site().
+	 *
+	 * Just as thread-context, the BP handler calls text_poke_sync_site()
+	 * to keep the primary's state-machine moving forward until it has
+	 * finished patching the call-site. At that point it is safe to
+	 * unwind the contexts.
+	 *
+	 * The second case, where we are patching a site in
+	 * text_poke_sync_site(), could end up in recursive BP handlers
+	 * and is not handled.
+	 *
+	 * Note that unlike thread-context where the start state can only
+	 * be PATCH_SYNC_0, in the BP-context, the start state could be any
+	 * PATCH_SYNC_x, so long as (state < PATCH_SYNC_DONE) since once a
+	 * CPU has acked PATCH_SYNC_2, there is no INT3 left for it to observe.
 	 */
 	do {
 		/*
@@ -1571,16 +1628,88 @@ static void text_poke_sync_site(struct text_poke_state *tps)
 
 		prevstate = READ_ONCE(tps->state);
 
-		if (prevstate < PATCH_SYNC_DONE) {
-			acked = cpumask_test_cpu(cpu, &tps->sync_ack_map);
-
-			BUG_ON(acked);
+		/*
+		 * As described above, text_poke_sync_site() gets called
+		 * from both thread-context and potentially in a re-entrant
+		 * fashion in BP-context. Accordingly expect to potentially
+		 * enter and exit this loop twice.
+		 *
+		 * Concretely, this means we need to handle the case where we
+		 * see an already acked state at BP/NMI entry and, see a
+		 * state discontinuity when returning to thread-context from
+		 * BP-context which would return after having observed
+		 * tps->state == PATCH_SYNC_DONE.
+		 *
+		 * Help this along by always exiting with tps->state ==
+		 * PATCH_SYNC_DONE but without acking it. Not acking it in
+		 * text_poke_sync_site(), guarantees that the state can only
+		 * forward once all secondary CPUs have exited both thread
+		 * and BP-contexts.
+		 */
+		acked = cpumask_test_cpu(cpu, &tps->sync_ack_map);
+		if (prevstate < PATCH_SYNC_DONE && !acked) {
 			sync_one();
 			cpumask_set_cpu(cpu, &tps->sync_ack_map);
 		}
 	} while (prevstate < PATCH_SYNC_DONE);
 }
 
+static void poke_int3_native(struct pt_regs *regs,
+			     struct text_poke_loc *tp)
+{
+	int cpu = smp_processor_id();
+	struct text_poke_state *tps = &text_poke_state;
+
+	if (cpu != tps->primary_cpu) {
+		/*
+		 * We came here from the sync loop in text_poke_sync_site().
+		 * Continue syncing. The primary is waiting.
+		 */
+		text_poke_sync_site(tps);
+	} else {
+		int offset = offset_in_page(text_poke_addr(tp));
+
+		/*
+		 * We are in the primary context and have hit the INT3 barrier
+		 * either ourselves or via an NMI.
+		 *
+		 * The secondary CPUs at this time are either in the original
+		 * text_poke_sync_site() loop or after having hit an NMI->INT3
+		 * themselves in the BP text_poke_sync_site() loop.
+		 *
+		 * The minimum that we need to do here is to update the local
+		 * insn stream such that we can return to the primary loop.
+		 * Without executing sync_core() on the secondary CPUs it is
+		 * possible that some of them might be executing stale uops in
+		 * their respective pipelines.
+		 *
+		 * This should be safe because we will get back to the patching
+		 * loop in text_poke_site() in due course and will resume
+		 * the state-machine where we left off including by re-writing
+		 * some of the insns sequences just written here.
+		 *
+		 * Note that we continue to be in poking_mm context and so can
+		 * safely call __text_do_poke() here.
+		 */
+		__text_do_poke(offset + INT3_INSN_SIZE,
+			       tp->text + INT3_INSN_SIZE,
+			       tp->native.len - INT3_INSN_SIZE);
+		__text_do_poke(offset, tp->text, INT3_INSN_SIZE);
+
+		/*
+		 * We only introduce a serializing instruction locally. As
+		 * noted above, the secondary CPUs can stay where they are --
+		 * potentially executing in the now stale INT3.) This is fine
+		 * because the primary will force the sync_core() on the
+		 * secondary CPUs once it returns.
+		 */
+		sync_one();
+	}
+
+	/* A new start */
+	regs->ip -= INT3_INSN_SIZE;
+}
+
 /**
  * text_poke_sync_finish() -- called to synchronize the CPU pipeline
  * on secondary CPUs for all patch sites.
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:05:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uV-00037G-Dn; Wed, 08 Apr 2020 05:05:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uU-00035W-51
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:05:58 +0000
X-Inumbo-ID: 9099010a-7956-11ea-81bb-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9099010a-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:29 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 038543Ku180070;
 Wed, 8 Apr 2020 05:05:23 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=9yuxA5IXffsHO48sJ1wSgMyLJZle9AjoqPIszA4NVpU=;
 b=TQKqFBITBOYFQPzrNmpK8lt+fAndAJZKKrFX4BoBfb3k0yVhyuTFG+bMvg1kjTKqqkWy
 0No7sGhvNNEA4WExF8iTf8oZ4ynJpKO7oVj5T82k4fJ4H4eiDDhx2ii1PaDE/ZJkjuAG
 9XqgH0YcYoLaJCMHDEPIUridLwfcI/eI7UrondSX711ga15j3ojbzxmjOeqxrhwCzrCb
 2EKHdqYbPZh8gkWroa37MP20onJ8TiMCnXkNm6oPl0xnrjcZACdDeECz4ERk5QF7757e
 aLRLRT0ZzSH3iWAPQ0uPPJsPOY8PD22Z+N4NiVmO/qZq/FSZJwwkC3Mn2Wbi5Tsx9M7I DQ== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by userp2120.oracle.com with ESMTP id 3091mnh14t-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:23 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852XvE062261;
 Wed, 8 Apr 2020 05:05:23 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])
 by userp3020.oracle.com with ESMTP id 3091mh1kr2-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:22 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03855LAJ022165;
 Wed, 8 Apr 2020 05:05:21 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:21 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 16/26] x86/alternatives: Add paravirt patching at runtime
Date: Tue,  7 Apr 2020 22:03:13 -0700
Message-Id: <20200408050323.4237-17-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 suspectscore=0 bulkscore=0
 mlxlogscore=999 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 mlxlogscore=999 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0
 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add paravirt_patch_runtime() which uses text_poke_late() to patch
paravirt sites.

Also add paravirt_worker() which does the actual insn generation
generate_paravirt() (which uses runtime_patch() to generate the
appropriate native or paravirt insn sequences) and then calls
text_poke_site() to do the actual poking.

 CPU0                                CPUx
 ----                                ----

 patch_worker()                      patch_worker()

   /* Traversal, insn-gen */           text_poke_sync_finish()
   tps.patch_worker()
     /* = paravirt_worker() */         /*
                                        * wait until:
     /* for each patch-site */          *  tps->state == PATCH_DONE
     generate_paravirt()                */
       runtime_patch()
     text_poke_site()
       poke_sync()

           ...                                 ...

   smp_store_release(&tps->state, PATCH_DONE)

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/text-patching.h |  2 +
 arch/x86/kernel/alternative.c        | 98 +++++++++++++++++++++++++++-
 2 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h
index c4b2814f2f9d..e86709a8287e 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -21,6 +21,8 @@ static inline void apply_paravirt(struct paravirt_patch_site *start,
 #ifndef CONFIG_PARAVIRT_RUNTIME
 #define __parainstructions_runtime	NULL
 #define __parainstructions_runtime_end	NULL
+#else
+int paravirt_runtime_patch(void);
 #endif
 
 /*
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 452d4081eded..1c5acdc4f349 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -1463,7 +1463,9 @@ static void poke_sync(struct text_poke_state *tps, int state, int offset,
 /**
  * text_poke_site() - called on the primary to patch a single call site.
  *
- * Returns after switching tps->state to PATCH_SYNC_DONE.
+ * Called in thread context with tps->state == PATCH_SYNC_DONE where it
+ * takes tps->state through different PATCH_SYNC_* states, returning
+ * after having switched the tps->state back to PATCH_SYNC_DONE.
  */
 static void __maybe_unused text_poke_site(struct text_poke_state *tps,
 					  struct text_poke_loc *tp)
@@ -1598,6 +1600,16 @@ static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
 	return ret;
 }
 
+/*
+ * Check if this address is still in scope of this module's .text section.
+ */
+static bool __maybe_unused stale_address(struct alt_module *am, u8 *p)
+{
+	if (p < am->text || p >= am->text_end)
+		return true;
+	return false;
+}
+
 #ifdef CONFIG_PARAVIRT_RUNTIME
 struct paravirt_stage_entry {
 	void *dest;	/* pv_op destination */
@@ -1654,4 +1666,88 @@ void text_poke_pv_stage_zero(void)
 	lockdep_assert_held(&text_mutex);
 	pv_stage.count = 0;
 }
+
+/**
+ * generate_paravirt - fill up the insn sequence for a pv-op.
+ *
+ * @tp - address of struct text_poke_loc
+ * @op - the pv-op entry for this location
+ * @site - patch site (kernel or module text)
+ */
+static void generate_paravirt(struct text_poke_loc *tp,
+			      struct paravirt_stage_entry *op,
+			      struct paravirt_patch_site *site)
+{
+	unsigned int used;
+
+	BUG_ON(site->len > POKE_MAX_OPCODE_SIZE);
+
+	text_poke_loc_init(tp, site->instr, site->instr, site->len, NULL, true);
+
+	/*
+	 * Paravirt patches can patch calls (ex. mmu.tlb_flush),
+	 * callee_saves(ex. queued_spin_unlock).
+	 *
+	 * runtime_patch() calls native_patch(), or paravirt_patch()
+	 * based on the destination.
+	 */
+	used = runtime_patch(site->type, (void *)tp->text, op->dest,
+			     (unsigned long)site->instr, site->len);
+
+	/* No good way to recover. */
+	BUG_ON(used < 0);
+
+	/* Pad the rest with nops */
+	add_nops((void *)tp->text + used, site->len - used);
+}
+
+/**
+ * paravirt_worker - generate the paravirt patching
+ * insns and calls text_poke_site() to do the actual patching.
+ */
+static void paravirt_worker(struct text_poke_state *tps)
+{
+	struct paravirt_patch_site *site;
+	struct paravirt_stage *stage = tps->stage;
+	struct paravirt_stage_entry *op = &stage->ops[0];
+	struct alt_module *am;
+	struct text_poke_loc tp;
+	int i;
+
+	list_for_each_entry(am, tps->head, next) {
+		for (site = am->para; site < am->para_end; site++) {
+			if (stale_address(am, site->instr))
+				continue;
+
+			for (i = 0;  i < stage->count; i++) {
+				if (op[i].type != site->type)
+					continue;
+
+				generate_paravirt(&tp, &op[i], site);
+
+				text_poke_site(tps, &tp);
+			}
+		}
+	}
+}
+
+/**
+ * paravirt_runtime_patch() -- patch pv-ops, including paired ops.
+ *
+ * Called holding the text_mutex.
+ *
+ * Modify possibly multiple mutually-dependent pv-op callsites
+ * (ex. pv_lock_ops) using stop_machine().
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+int paravirt_runtime_patch(void)
+{
+	lockdep_assert_held(&text_mutex);
+
+	if (!pv_stage.count)
+		return -EINVAL;
+
+	return text_poke_late(paravirt_worker, &pv_stage);
+}
 #endif /* CONFIG_PARAVIRT_RUNTIME */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:06:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uZ-0003Dm-Si; Wed, 08 Apr 2020 05:06:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uY-0003C7-IU
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:06:02 +0000
X-Inumbo-ID: 94a55730-7956-11ea-9e09-bc764e2007e4
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 94a55730-7956-11ea-9e09-bc764e2007e4;
 Wed, 08 Apr 2020 05:05:36 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03854HmH012943;
 Wed, 8 Apr 2020 05:05:27 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=3KrJyMdl6FuU/9RrwZPu8LutFkDCWnKoiuaiLyLQY8k=;
 b=Nz0B0/o9yL4G/oeYKXgml5AlpwAqrxs9OSYyfd/2t3KASsuXVslfpk3aV4siEspeImVv
 hF5mZp00cKk33qyWWIWzgx7Z/2TQbCIg4+L+xdwnRQHABYbAaX8eoRfCCmAuRRNxd8Yw
 b9h2KmNAKrdNawOdsrEQ9YaTpzcLbV4+S29wLj8mtcKjr+8OuLKxgVlpROe8Uc7ntEYy
 plZiZePsltN5gQ4IzVpPOcYcmZwK2LMz2g5CfWO4pPFGbQEi7yhGvMUP7T5/BxCphx9t
 ZQkM0P06aEe4dKlyv9maop2wZsC0FwJjCcQC7CvJv65TbINE/KWXveQRy4d4cNgM292g JA== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by userp2130.oracle.com with ESMTP id 3091m390xw-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:27 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03851WbQ100696;
 Wed, 8 Apr 2020 05:05:26 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
 by aserp3020.oracle.com with ESMTP id 3091m2hvdm-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:26 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03855PX9030620;
 Wed, 8 Apr 2020 05:05:25 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:25 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 19/26] x86/alternatives: NMI safe runtime patching
Date: Tue,  7 Apr 2020 22:03:16 -0700
Message-Id: <20200408050323.4237-20-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 mlxscore=0
 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Runtime patching can deadlock with multiple simultaneous NMIs.
This can happen while patching inter-dependent pv-ops which are
used in the NMI path (ex pv_lock_ops):

 CPU0   			    CPUx
 ----                               ----

 patch_worker()                     patch_worker()

   /* Traversal, insn-gen */          text_poke_sync_finish()
   tps.patch_worker()                   /* wait until:
     /* = paravirt_worker() */           *  tps->state == PATCH_DONE
                                         */
           /* start-patching:lock.spin_unlock */
      generate_paravirt()
        runtime_patch()

      text_poke_site()                  text_poke_sync_site()
        poke_sync()                      /* for state in:
          __text_do_poke()                *  PATCH_SYNC_[012]
	  ==NMI==                         */
	                                 ==NMI==
         tries-to-acquire:nmi_lock       acquires:nmi_lock
                                         tries-to-release:nmi_lock
					 ==BP==
   				         text_poke_sync_site()

      /* waiting-for:nmi_lock */    /* waiting-for:patched-spin_unlock() */

A similar deadlock exists if two secondary CPUs get an NMI as well.

Fix this by patching NMI-unsafe ops in an NMI context. Given that the
NMI entry code ensures that NMIs do not nest, we are guaranteed that
this can be done atomically.

We do this by registering a local NMI handler (text_poke_nmi()) and
triggering a local NMI on the primary (via patch_worker_nmi()) which
then calls the same worker (tps->patch_worker()) as in thread-context.

On the secondary, we continue with the pipeline sync loop (via
text_poke_sync_finish()) in thread-context; however, if there is an
NMI on the secondary, we call text_poke_sync_finish() in the handler
which continues the work that was being done in thread-context.

Also note that text_poke_nmi() always executes first so we know that
it takes priority over any arbitrary code executing in the installed
NMI handlers.

 CPU0                                CPUx
 ----                                ----

 patch_worker(nmi=true)              patch_worker(nmi=true)

   patch_worker_nmi() -> triggers NMI   text_poke_sync_finish()
   /* wait for return from NMI */         /* wait until:
            ...                            *  tps->state == PATCH_DONE
                                           */

   smp_store_release(&tps->state,
                     PATCH_DONE)
                                          /* for each patch-site */

                                          text_poke_sync_site()
 CPU0-NMI                                 /* for each:
 --------                                  *  PATCH_SYNC_[012]
                                           */
 text_poke_nmi()                            sync_one()
   /* Traversal, insn-gen */                ack()
   tps.patch_worker()
   /* = paravirt_worker() */                ...

   /* for each patch-site */

     generate_paravirt()
       runtime_patch()

     text_poke_site()
       poke_sync()
         __text_do_poke()
         sync_one()
         ack()
         wait_for_acks()

          ...


Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/text-patching.h |   2 +-
 arch/x86/kernel/alternative.c        | 120 ++++++++++++++++++++++++++-
 2 files changed, 117 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h
index e86709a8287e..9ba329bf9479 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -22,7 +22,7 @@ static inline void apply_paravirt(struct paravirt_patch_site *start,
 #define __parainstructions_runtime	NULL
 #define __parainstructions_runtime_end	NULL
 #else
-int paravirt_runtime_patch(void);
+int paravirt_runtime_patch(bool nmi);
 #endif
 
 /*
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index c68d940356a2..385c3e6ea925 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -1442,6 +1442,14 @@ struct text_poke_state {
 
 	unsigned int primary_cpu; /* CPU doing the patching. */
 	unsigned int num_acks; /* Number of Acks needed. */
+
+	/*
+	 * To synchronize with the NMI handler.
+	 */
+	atomic_t nmi_work;
+
+	/* Ensure this is patched atomically against NMIs. */
+	bool nmi_context;
 };
 
 static struct text_poke_state text_poke_state;
@@ -1715,6 +1723,7 @@ static void poke_int3_native(struct pt_regs *regs,
  * on secondary CPUs for all patch sites.
  *
  * Called in thread context with tps->state == PATCH_SYNC_DONE.
+ * Also might be called from NMI context with an arbitrary tps->state.
  * Returns with tps->state == PATCH_DONE.
  */
 static void text_poke_sync_finish(struct text_poke_state *tps)
@@ -1741,6 +1750,12 @@ static void text_poke_sync_finish(struct text_poke_state *tps)
 			cpumask_set_cpu(cpu, &tps->sync_ack_map);
 			smp_cond_load_acquire(&tps->state,
 					      (state != VAL));
+		} else if (in_nmi() && (state & PATCH_SYNC_x)) {
+			/*
+			 * Called in case of NMI so we should be ready
+			 * to be called with any PATCH_SYNC_x.
+			 */
+			text_poke_sync_site(tps);
 		} else if (state == PATCH_SYNC_0) {
 			/*
 			 * PATCH_SYNC_1, PATCH_SYNC_2 are handled
@@ -1753,6 +1768,91 @@ static void text_poke_sync_finish(struct text_poke_state *tps)
 	}
 }
 
+/*
+ * text_poke_nmi() - primary CPU comes here (via self NMI) and the
+ * secondary (if there's an NMI.)
+ *
+ * By placing this NMI handler first, we can restrict execution of any
+ * NMI code that might be under patching.
+ * Local NMI handling also does not go through any locking code so it
+ * should be safe to install one.
+ *
+ * In both these roles the state-machine is identical to the one that
+ * we had in task context.
+ */
+static int text_poke_nmi(unsigned int val, struct pt_regs *regs)
+{
+	int ret, cpu = smp_processor_id();
+	struct text_poke_state *tps = &text_poke_state;
+
+	/*
+	 * We came here because there's a text-poke handler
+	 * installed. Get out if there's no work assigned yet.
+	 */
+	if (atomic_read(&tps->nmi_work) == 0)
+		return NMI_DONE;
+
+	if (cpu == tps->primary_cpu) {
+		/*
+		 * Do what we came here for. We can safely patch: any
+		 * secondary CPUs executing in NMI context have been
+		 * captured in the code below and are doing useful
+		 * work.
+		 */
+		tps->patch_worker(tps);
+
+		/*
+		 * Both the primary and the secondary CPUs are done (in NMI
+		 * or thread context.) Mark work done so any future NMIs can
+		 * skip this and go to the real handler.
+		 */
+		atomic_dec(&tps->nmi_work);
+
+		/*
+		 * The NMI was self-induced, consume it.
+		 */
+		ret = NMI_HANDLED;
+	} else {
+		/*
+		 * Unexpected NMI on a secondary CPU: do sync_core()
+		 * work until done.
+		 */
+		text_poke_sync_finish(tps);
+
+		/*
+		 * The NMI was spontaneous, not self-induced.
+		 * Don't consume it.
+		 */
+		ret = NMI_DONE;
+	}
+
+	return ret;
+}
+
+/*
+ * patch_worker_nmi() - sets up an NMI handler to do the
+ * patching work.
+ * This stops any NMIs from interrupting any code that might
+ * be getting patched.
+ */
+static void __maybe_unused patch_worker_nmi(void)
+{
+	atomic_set(&text_poke_state.nmi_work, 1);
+	/*
+	 * We could just use apic->send_IPI_self here. However, for reasons
+	 * that I don't understand, apic->send_IPI() or apic->send_IPI_mask()
+	 * work but apic->send_IPI_self (which internally does apic_write())
+	 * does not.
+	 */
+	apic->send_IPI(smp_processor_id(), NMI_VECTOR);
+
+	/*
+	 * Barrier to ensure that we do actually execute the NMI
+	 * before exiting.
+	 */
+	atomic_cond_read_acquire(&text_poke_state.nmi_work, !VAL);
+}
+
 static int patch_worker(void *t)
 {
 	int cpu = smp_processor_id();
@@ -1769,7 +1869,10 @@ static int patch_worker(void *t)
 		 * Generates insns and calls text_poke_site() to do the poking
 		 * and sync.
 		 */
-		tps->patch_worker(tps);
+		if (!tps->nmi_context)
+			tps->patch_worker(tps);
+		else
+			patch_worker_nmi();
 
 		/*
 		 * We are done patching. Switch the state to PATCH_DONE
@@ -1790,7 +1893,8 @@ static int patch_worker(void *t)
  *
  * Return: 0 on success, -errno on failure.
  */
-static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
+static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage,
+					 bool nmi)
 {
 	int ret;
 
@@ -1807,12 +1911,20 @@ static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
 	text_poke_state.state = PATCH_SYNC_DONE; /* Start state */
 	text_poke_state.primary_cpu = smp_processor_id();
 
+	text_poke_state.nmi_context = nmi;
+
+	if (nmi)
+		register_nmi_handler(NMI_LOCAL, text_poke_nmi,
+				     NMI_FLAG_FIRST, "text_poke_nmi");
 	/*
 	 * Run the worker on all online CPUs. Don't need to do anything
 	 * for offline CPUs as they come back online with a clean cache.
 	 */
 	ret = stop_machine(patch_worker, &text_poke_state, cpu_online_mask);
 
+	if (nmi)
+		unregister_nmi_handler(NMI_LOCAL, "text_poke_nmi");
+
 	return ret;
 }
 
@@ -1957,13 +2069,13 @@ static void paravirt_worker(struct text_poke_state *tps)
  *
  * Return: 0 on success, -errno on failure.
  */
-int paravirt_runtime_patch(void)
+int paravirt_runtime_patch(bool nmi)
 {
 	lockdep_assert_held(&text_mutex);
 
 	if (!pv_stage.count)
 		return -EINVAL;
 
-	return text_poke_late(paravirt_worker, &pv_stage);
+	return text_poke_late(paravirt_worker, &pv_stage, nmi);
 }
 #endif /* CONFIG_PARAVIRT_RUNTIME */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:06:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2ua-0003Eg-Dl; Wed, 08 Apr 2020 05:06:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uZ-0003Cn-53
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:06:03 +0000
X-Inumbo-ID: 94cf9aae-7956-11ea-81bb-12813bfff9fa
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 94cf9aae-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:36 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 038553d4013457;
 Wed, 8 Apr 2020 05:05:28 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=RT2DLUiFIblGAhj2vsdXWMs47UzEg77Wx4rwQqNvIys=;
 b=vt9sy4IT0ona61EF6lrQB6+fOd4n1UUP16sabHo45o2Fj3qC6LzIzwKRjy/UGHKp6UtX
 qFSd5YSVzautGXeCr2eAJwfIK/iGXCJNeAxcoDO3I7m5gSP91p4n0pb5kTTgdsi0yjOx
 qo22FkosRIApaeM6Fz6ilxR/dtoXxhOalPa8lPluAeNfJBYl4kG5bLmjOE/87zZNyJBJ
 gyT8RCVnfUfcfVutEDgu5tGajHjyK4ZwDhUOdnggz0MB/ArZELsxKKhJSr8EvqA/iPGM
 LytegfsDsU5SPuZ1H7lB9GSPk4DwMfVvQ5OLU8BwvFvA+C8d07oHuaLcCOsQnaN6BFRD jw== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2130.oracle.com with ESMTP id 3091m390y1-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:28 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853M4I159232;
 Wed, 8 Apr 2020 05:05:28 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userp3030.oracle.com with ESMTP id 3091m01g4f-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:27 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03855QOv007470;
 Wed, 8 Apr 2020 05:05:26 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:26 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 20/26] x86/paravirt: Enable pv-spinlocks in runtime_patch()
Date: Tue,  7 Apr 2020 22:03:17 -0700
Message-Id: <20200408050323.4237-21-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 mlxlogscore=999 phishscore=0 spamscore=0 adultscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Enable runtime patching of paravirt spinlocks. These can be trivially
enabled because pv_lock_ops are never preemptible -- preemption is
disabled at entry to spin_lock*().

Note that a particular CPU instance might get preempted in the host but
because runtime_patching() is called via stop_machine(), the migration
thread would flush out any kernel threads preempted in the host.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/paravirt.h  | 10 +++++-----
 arch/x86/kernel/paravirt_patch.c | 12 ++++++++++++
 kernel/locking/lock_events.c     |  2 +-
 3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 694d8daf4983..cb3d0a91c060 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -642,27 +642,27 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 static __always_inline void pv_queued_spin_lock_slowpath(struct qspinlock *lock,
 							u32 val)
 {
-	PVOP_VCALL2(lock.queued_spin_lock_slowpath, lock, val);
+	PVRTOP_VCALL2(lock.queued_spin_lock_slowpath, lock, val);
 }
 
 static __always_inline void pv_queued_spin_unlock(struct qspinlock *lock)
 {
-	PVOP_VCALLEE1(lock.queued_spin_unlock, lock);
+	PVRTOP_VCALLEE1(lock.queued_spin_unlock, lock);
 }
 
 static __always_inline void pv_wait(u8 *ptr, u8 val)
 {
-	PVOP_VCALL2(lock.wait, ptr, val);
+	PVRTOP_VCALL2(lock.wait, ptr, val);
 }
 
 static __always_inline void pv_kick(int cpu)
 {
-	PVOP_VCALL1(lock.kick, cpu);
+	PVRTOP_VCALL1(lock.kick, cpu);
 }
 
 static __always_inline bool pv_vcpu_is_preempted(long cpu)
 {
-	return PVOP_CALLEE1(bool, lock.vcpu_is_preempted, cpu);
+	return PVRTOP_CALLEE1(bool, lock.vcpu_is_preempted, cpu);
 }
 
 void __raw_callee_save___native_queued_spin_unlock(struct qspinlock *lock);
diff --git a/arch/x86/kernel/paravirt_patch.c b/arch/x86/kernel/paravirt_patch.c
index 3eb8c0e720b4..3f8606f2811c 100644
--- a/arch/x86/kernel/paravirt_patch.c
+++ b/arch/x86/kernel/paravirt_patch.c
@@ -152,6 +152,18 @@ int runtime_patch(u8 type, void *insn_buff, void *op,
 
 	/* Nothing whitelisted for now. */
 	switch (type) {
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+	/*
+	 * Preemption is always disabled in the lifetime of a spinlock
+	 * (whether held or while waiting to acquire.)
+	 */
+	case PARAVIRT_PATCH(lock.queued_spin_lock_slowpath):
+	case PARAVIRT_PATCH(lock.queued_spin_unlock):
+	case PARAVIRT_PATCH(lock.wait):
+	case PARAVIRT_PATCH(lock.kick):
+	case PARAVIRT_PATCH(lock.vcpu_is_preempted):
+		break;
+#endif
 	default:
 		pr_warn("type=%d unsuitable for runtime-patching\n", type);
 		return -EINVAL;
diff --git a/kernel/locking/lock_events.c b/kernel/locking/lock_events.c
index fa2c2f951c6b..c3057e82e6f9 100644
--- a/kernel/locking/lock_events.c
+++ b/kernel/locking/lock_events.c
@@ -115,7 +115,7 @@ static const struct file_operations fops_lockevent = {
 	.llseek = default_llseek,
 };
 
-#ifdef CONFIG_PARAVIRT_SPINLOCKS
+#if defined(CONFIG_PARAVIRT_SPINLOCKS) && !defined(CONFIG_PARAVIRT_RUNTIME)
 #include <asm/paravirt.h>
 
 static bool __init skip_lockevent(const char *name)
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:06:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uf-0003Lh-Sk; Wed, 08 Apr 2020 05:06:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2ue-0003JU-54
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:06:08 +0000
X-Inumbo-ID: 949270ca-7956-11ea-81bb-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 949270ca-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:35 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03854CmS180113;
 Wed, 8 Apr 2020 05:05:30 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=7QyLiBCO3vyvqJ8QQH0U81XYGVivm5nwHGLYsFlNJAo=;
 b=AvHVQP9qtew1hsN6EtCaOeF520A4+Z8TUiZF8HI5faa0Jz1VTdsvMiJby5SU8RUz1GIi
 Rg7/4ShQivVruZUqr7xq5Zo5D65mgdKB0GzTlFD1YqCjZqnXWqZVYy6AbPPQA8DcQ9w6
 nb8znQ4P7Cgfx/4eWvv5Co9yR3rhKguPsyGKTvdcq+RXTH7hGYWKx4rlfUfNxTY2kMyp
 jH65pvII+gGiUkKYMJUofuBTG0cihFr4kMmZSaPbLnay6cPDpOUebP8eRjiWZ18zM8Do
 sJDeBhv3oYGnjqdviRm8ykKGhEvBOZE88dP/yx/gC9JPyQDY4ir2oY0TfZnbZUoc8nA/ Yw== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by userp2120.oracle.com with ESMTP id 3091mnh150-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:30 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852X3K062284;
 Wed, 8 Apr 2020 05:05:29 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userp3020.oracle.com with ESMTP id 3091mh1kvb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:29 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03855SHY007473;
 Wed, 8 Apr 2020 05:05:28 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:27 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 21/26] x86/alternatives: Paravirt runtime selftest
Date: Tue,  7 Apr 2020 22:03:18 -0700
Message-Id: <20200408050323.4237-22-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 suspectscore=0 bulkscore=0
 mlxlogscore=999 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 mlxlogscore=999 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0
 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add a selftest that triggers paravirt_runtime_patch() which
toggles between the paravirt and native pv_lock_ops.

The selftest also register an NMI handler, which exercises the
patched pv-ops by spin-lock operations. These are triggered via
artificially sent NMIs.

And last, introduce patch sites in the primary and secondary
patching code which are hit while during the patching process.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/Kconfig.debug        |  13 ++
 arch/x86/kernel/Makefile      |   1 +
 arch/x86/kernel/alternative.c |  20 +++
 arch/x86/kernel/kvm.c         |   4 +-
 arch/x86/kernel/pv_selftest.c | 264 ++++++++++++++++++++++++++++++++++
 arch/x86/kernel/pv_selftest.h |  15 ++
 6 files changed, 315 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/kernel/pv_selftest.c
 create mode 100644 arch/x86/kernel/pv_selftest.h

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 2e74690b028a..82a8e3fa68c7 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -252,6 +252,19 @@ config X86_DEBUG_FPU
 
 	  If unsure, say N.
 
+config DEBUG_PARAVIRT_SELFTEST
+	bool "Enable paravirt runtime selftest"
+	depends on PARAVIRT
+	depends on PARAVIRT_RUNTIME
+	depends on PARAVIRT_SPINLOCKS
+	depends on KVM_GUEST
+	help
+	  This option enables sanity testing of the runtime paravirtualized
+	  patching code. Triggered via debugfs.
+
+	  Might help diagnose patching problems in different
+	  configurations and loads.
+
 config PUNIT_ATOM_DEBUG
 	tristate "ATOM Punit debug driver"
 	depends on PCI
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index ba89cabe5fcf..ed3c93681f12 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -114,6 +114,7 @@ obj-$(CONFIG_APB_TIMER)		+= apb_timer.o
 
 obj-$(CONFIG_AMD_NB)		+= amd_nb.o
 obj-$(CONFIG_DEBUG_NMI_SELFTEST) += nmi_selftest.o
+obj-$(CONFIG_DEBUG_PARAVIRT_SELFTEST) += pv_selftest.o
 
 obj-$(CONFIG_KVM_GUEST)		+= kvm.o kvmclock.o
 obj-$(CONFIG_PARAVIRT)		+= paravirt.o paravirt_patch.o
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 385c3e6ea925..26407d7a54db 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -26,6 +26,7 @@
 #include <asm/insn.h>
 #include <asm/io.h>
 #include <asm/fixmap.h>
+#include "pv_selftest.h"
 
 int __read_mostly alternatives_patched;
 
@@ -1549,6 +1550,12 @@ static void __maybe_unused text_poke_site(struct text_poke_state *tps,
 	 */
 	poke_sync(tps, PATCH_SYNC_0, offset, &int3, INT3_INSN_SIZE);
 
+	/*
+	 * We have an INT3 in place; execute a contrived selftest that
+	 * has an insn sequence that is under patching.
+	 */
+	pv_selftest_primary();
+
 	/* Poke remaining */
 	poke_sync(tps, PATCH_SYNC_1, offset + INT3_INSN_SIZE,
 		  tp->text + INT3_INSN_SIZE, tp->native.len - INT3_INSN_SIZE);
@@ -1634,6 +1641,19 @@ static void text_poke_sync_site(struct text_poke_state *tps)
 		smp_cond_load_acquire(&tps->state,
 				      prevstate != VAL);
 
+		/*
+		 * Send an NMI to one of the other CPUs.
+		 */
+		pv_selftest_send_nmi();
+
+		/*
+		 * We have an INT3 in place; execute a contrived selftest that
+		 * has an insn sequence that is under patching.
+		 *
+		 * Note that this function is also called from BP fixup but
+		 * is just an NOP when called from there.
+		 */
+		pv_selftest_secondary();
 		prevstate = READ_ONCE(tps->state);
 
 		/*
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 6efe0410fb72..e56d263159d7 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -779,7 +779,7 @@ arch_initcall(kvm_alloc_cpumask);
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 
 /* Kick a cpu by its apicid. Used to wake up a halted vcpu */
-static void kvm_kick_cpu(int cpu)
+void kvm_kick_cpu(int cpu)
 {
 	int apicid;
 	unsigned long flags = 0;
@@ -790,7 +790,7 @@ static void kvm_kick_cpu(int cpu)
 
 #include <asm/qspinlock.h>
 
-static void kvm_wait(u8 *ptr, u8 val)
+void kvm_wait(u8 *ptr, u8 val)
 {
 	unsigned long flags;
 
diff --git a/arch/x86/kernel/pv_selftest.c b/arch/x86/kernel/pv_selftest.c
new file mode 100644
index 000000000000..e522f444bd6e
--- /dev/null
+++ b/arch/x86/kernel/pv_selftest.c
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/delay.h>
+#include <linux/irq.h>
+#include <linux/spinlock.h>
+#include <linux/debugfs.h>
+#include <linux/memory.h>
+#include <linux/nmi.h>
+#include <linux/uaccess.h>
+#include <asm/apic.h>
+#include <asm/text-patching.h>
+#include <asm/paravirt.h>
+#include <asm/paravirt_types.h>
+#include "pv_selftest.h"
+
+static int nmi_selftest;
+static bool cond_state;
+
+#define SELFTEST_PARAVIRT	1
+static int test_mode;
+
+/*
+ * Mark this and the following functions __always_inline to ensure
+ * we generate multiple patch sites that can be hit independently
+ * in thread, NMI etc contexts.
+ */
+static __always_inline void selftest_pv(void)
+{
+	struct qspinlock test;
+
+	memset(&test, 0, sizeof(test));
+
+	test.locked = _Q_LOCKED_VAL;
+
+	/*
+	 * Sits directly in the path of the test.
+	 *
+	 * The primary sets up an INT3 instruction at pv_queued_spin_unlock().
+	 * Both the primary and secondary CPUs should hit that in both
+	 * thread and NMI contexts.
+	 *
+	 * Additionally, this also gets inlined in nmi_pv_callback() so we
+	 * should hit this with nmi_selftest.
+	 *
+	 * The fixup takes place in poke_int3_native().
+	 */
+	pv_queued_spin_unlock(&test);
+}
+
+static __always_inline void patch_selftest(void)
+{
+	if (test_mode == SELFTEST_PARAVIRT)
+		selftest_pv();
+}
+
+static DEFINE_PER_CPU(int, selftest_count);
+void pv_selftest_secondary(void)
+{
+	/*
+	 * On the secondary we execute the same code in both the
+	 * thread-context and the BP-context and so would hit this
+	 * recursively if we do inside the fixup context.
+	 *
+	 * So we trigger the selftest only if it's not ongoing already
+	 * (thus allowing the thread or NMI context, but excluding
+	 * the INT3 handling path.)
+	 */
+	if (this_cpu_read(selftest_count))
+		return;
+
+	this_cpu_inc(selftest_count);
+
+	patch_selftest();
+
+	this_cpu_dec(selftest_count);
+}
+
+void pv_selftest_primary(void)
+{
+	patch_selftest();
+}
+
+/*
+ * We only come here if nmi_selftest > 0.
+ *  - nmi_selftest >= 1: execute a pv-op that will be patched
+ *  - nmi_selftest >= 2: execute a paired pv-op that is also contended
+ *  - nmi_selftest >= 3: add lock contention
+ */
+static int nmi_callback(unsigned int val, struct pt_regs *regs)
+{
+	static DEFINE_SPINLOCK(nmi_spin);
+
+	if (!nmi_selftest)
+		goto out;
+
+	patch_selftest();
+
+	if (nmi_selftest >= 2) {
+		/*
+		 * Depending on whether CONFIG_[UN]INLINE_SPIN_* are
+		 * defined or not, these would get patched or just
+		 * create race conditions between via NMIs.
+		 */
+		spin_lock(&nmi_spin);
+
+		/* Dilate the critical section to force contention. */
+		if (nmi_selftest >= 3)
+			udelay(1);
+
+		spin_unlock(&nmi_spin);
+	}
+
+	/*
+	 * nmi_selftest > 0, but we should really have a bitmap where
+	 * to check if this really was destined for us or not.
+	 */
+	return NMI_HANDLED;
+out:
+	return NMI_DONE;
+}
+
+void pv_selftest_register(void)
+{
+	register_nmi_handler(NMI_LOCAL, nmi_callback,
+			     0, "paravirt_nmi_selftest");
+}
+
+void pv_selftest_unregister(void)
+{
+	unregister_nmi_handler(NMI_LOCAL, "paravirt_nmi_selftest");
+}
+
+void pv_selftest_send_nmi(void)
+{
+	int cpu = smp_processor_id();
+	/* NMI or INT3 */
+	if (nmi_selftest && !in_interrupt())
+		apic->send_IPI(cpu + 1 % num_online_cpus(), NMI_VECTOR);
+}
+
+/*
+ * Just declare these locally here instead of having them be
+ * exposed to the whole world.
+ */
+void kvm_wait(u8 *ptr, u8 val);
+void kvm_kick_cpu(int cpu);
+bool __raw_callee_save___kvm_vcpu_is_preempted(long cpu);
+static void pv_spinlocks(void)
+{
+	paravirt_stage_alt(cond_state,
+			   lock.queued_spin_lock_slowpath,
+			   __pv_queued_spin_lock_slowpath);
+	paravirt_stage_alt(cond_state, lock.queued_spin_unlock.func,
+			   PV_CALLEE_SAVE(__pv_queued_spin_unlock).func);
+	paravirt_stage_alt(cond_state, lock.wait, kvm_wait);
+	paravirt_stage_alt(cond_state, lock.kick, kvm_kick_cpu);
+
+	paravirt_stage_alt(cond_state,
+			   lock.vcpu_is_preempted.func,
+			   PV_CALLEE_SAVE(__kvm_vcpu_is_preempted).func);
+}
+
+void pv_trigger(void)
+{
+	bool nmi_mode = nmi_selftest ? true : false;
+	int ret;
+
+	pr_debug("%s: nmi=%d; NMI-mode=%d\n", __func__, nmi_selftest, nmi_mode);
+
+	mutex_lock(&text_mutex);
+
+	paravirt_stage_zero();
+	pv_spinlocks();
+
+	/*
+	 * paravirt patching for pv_locks can potentially deadlock
+	 * if we are running with nmi_mode=false and we get an NMI.
+	 *
+	 * For the sake of testing that path, we risk it. However, if
+	 * we are generating synthetic NMIs (nmi_selftest > 0) then
+	 * run with nmi_mode=true.
+	 */
+	ret = paravirt_runtime_patch(nmi_mode);
+
+	/*
+	 * Flip the state so we switch the pv_lock_ops on the next test.
+	 */
+	cond_state = !cond_state;
+
+	mutex_unlock(&text_mutex);
+
+	pr_debug("%s: nmi=%d; NMI-mode=%d, ret=%d\n", __func__, nmi_selftest,
+		 nmi_mode, ret);
+}
+
+static void pv_selftest_trigger(void)
+{
+	test_mode = SELFTEST_PARAVIRT;
+	pv_trigger();
+}
+
+static ssize_t pv_selftest_write(struct file *file, const char __user *ubuf,
+				 size_t count, loff_t *ppos)
+{
+	pv_selftest_register();
+	pv_selftest_trigger();
+	pv_selftest_unregister();
+
+	return count;
+}
+
+static ssize_t pv_nmi_read(struct file *file, char __user *ubuf,
+			   size_t count, loff_t *ppos)
+{
+	char buf[32];
+	unsigned int len;
+
+	len = snprintf(buf, sizeof(buf), "%d\n", nmi_selftest);
+	return simple_read_from_buffer(ubuf, count, ppos, buf, len);
+}
+
+static ssize_t pv_nmi_write(struct file *file, const char __user *ubuf,
+			    size_t count, loff_t *ppos)
+{
+	char buf[32];
+	unsigned int len;
+	unsigned int enabled;
+
+	len = min(sizeof(buf) - 1, count);
+	if (copy_from_user(buf, ubuf, len))
+		return -EFAULT;
+
+	buf[len] = '\0';
+	if (kstrtoint(buf, 0, &enabled))
+		return -EINVAL;
+
+	nmi_selftest = enabled > 3 ? 3 : enabled;
+
+	return count;
+}
+
+static const struct file_operations pv_selftest_fops = {
+	.read = NULL,
+	.write = pv_selftest_write,
+	.llseek = default_llseek,
+};
+
+static const struct file_operations pv_nmi_fops = {
+	.read = pv_nmi_read,
+	.write = pv_nmi_write,
+	.llseek = default_llseek,
+};
+
+static int __init pv_selftest_init(void)
+{
+	struct dentry *d = debugfs_create_dir("pv_selftest", NULL);
+
+	debugfs_create_file("toggle", 0600, d, NULL, &pv_selftest_fops);
+	debugfs_create_file("nmi", 0600, d, NULL, &pv_nmi_fops);
+
+	return 0;
+}
+
+late_initcall(pv_selftest_init);
diff --git a/arch/x86/kernel/pv_selftest.h b/arch/x86/kernel/pv_selftest.h
new file mode 100644
index 000000000000..5afa0f7db5cc
--- /dev/null
+++ b/arch/x86/kernel/pv_selftest.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _PVR_SELFTEST_H
+#define _PVR_SELFTEST_H
+
+#ifdef CONFIG_DEBUG_PARAVIRT_SELFTEST
+void pv_selftest_send_nmi(void);
+void pv_selftest_primary(void);
+void pv_selftest_secondary(void);
+#else
+static inline void pv_selftest_send_nmi(void) { }
+static inline void pv_selftest_primary(void) { }
+static inline void pv_selftest_secondary(void) { }
+#endif /*! CONFIG_DEBUG_PARAVIRT_SELFTEST */
+
+#endif /* _PVR_SELFTEST_H */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:06:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uk-0003Qn-79; Wed, 08 Apr 2020 05:06:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uj-0003Pa-5N
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:06:13 +0000
X-Inumbo-ID: 95c4995a-7956-11ea-81bb-12813bfff9fa
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 95c4995a-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:37 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 038543dJ012900;
 Wed, 8 Apr 2020 05:05:32 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=kgW9iCiG5LItARQCVcpvzlvJOL8EYizS/WgTMkqF5GQ=;
 b=B6xflBgt96z3OrC1orNU/7h9/R5v5aKEPszgWArvG/YKVpuevq436ajAtgFfMwwdSjz0
 qZ7szdFGT7K5dCH8fbEDuMV7ugSL0fmHYKseM8dvx37f8AQsc3UsdMHIQF7jtDV3zk7R
 6h1PtbnmbtR7f5lhdQjlpxnf475s3S1o8AunH6alLl8VdqfsQrWo5obLyFLDKU9XF/2Y
 nf2f6XasqEBFPrCnC1Z3c7eAYzDdMYy7rMkts1JewP/sftLhmdV22oay8ytjJwHUm1O+
 gKqGihxgS0ZEkpoFHmiB7Z9NlvPtwIpjjHwX1F9KKqC0ifLje9IrxufEFjigj0nILJUn BA== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by userp2130.oracle.com with ESMTP id 3091m390y4-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:32 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03851VPa100593;
 Wed, 8 Apr 2020 05:05:31 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by aserp3020.oracle.com with ESMTP id 3091m2hvn7-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:31 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03855UrV007479;
 Wed, 8 Apr 2020 05:05:30 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:30 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 23/26] x86/kvm: Add worker to trigger runtime patching
Date: Tue,  7 Apr 2020 22:03:20 -0700
Message-Id: <20200408050323.4237-24-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 mlxscore=0
 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Make __pv_init_lock_hash() conditional on either paravirt spinlocks
being enabled (via kvm_pv_spinlock()) or if paravirt spinlocks
might get enabled (runtime patching via CONFIG_PARAVIRT_RUNTIME.)

Also add a handler for CPUID reprobe which can trigger this patching.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/kernel/kvm.c | 34 +++++++++++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 31f5ecfd3907..1cb7eab805a6 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -35,6 +35,7 @@
 #include <asm/hypervisor.h>
 #include <asm/tlb.h>
 #include <asm/cpuidle_haltpoll.h>
+#include <asm/text-patching.h>
 
 static int kvmapf = 1;
 
@@ -909,12 +910,15 @@ void __init kvm_spinlock_init(void)
 	if (num_possible_cpus() == 1)
 		return;
 
-	if (!kvm_pv_spinlock())
-		return;
-
-	__pv_init_lock_hash();
+	/*
+	 * Allocate if pv_spinlocks are enabled or if we might
+	 * end up patching them in later.
+	 */
+	if (kvm_pv_spinlock() || IS_ENABLED(CONFIG_PARAVIRT_RUNTIME))
+		__pv_init_lock_hash();
 }
-
+#else	/* !CONFIG_PARAVIRT_SPINLOCKS */
+static inline bool kvm_pv_spinlock(void) { return false; }
 #endif	/* CONFIG_PARAVIRT_SPINLOCKS */
 
 #ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL
@@ -952,3 +956,23 @@ void arch_haltpoll_disable(unsigned int cpu)
 }
 EXPORT_SYMBOL_GPL(arch_haltpoll_disable);
 #endif
+
+#ifdef CONFIG_PARAVIRT_RUNTIME
+void kvm_trigger_reprobe_cpuid(struct work_struct *work)
+{
+	mutex_lock(&text_mutex);
+
+	paravirt_stage_zero();
+
+	kvm_pv_steal_clock();
+	kvm_pv_tlb();
+	paravirt_runtime_patch(false);
+
+	paravirt_stage_zero();
+
+	kvm_pv_spinlock();
+	paravirt_runtime_patch(true);
+
+	mutex_unlock(&text_mutex);
+}
+#endif /* CONFIG_PARAVIRT_RUNTIME */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:06:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uo-0003W9-Jj; Wed, 08 Apr 2020 05:06:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2uo-0003Ve-5X
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:06:18 +0000
X-Inumbo-ID: 9802e0e6-7956-11ea-81bb-12813bfff9fa
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9802e0e6-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:41 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03854Mlq012951;
 Wed, 8 Apr 2020 05:05:36 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=81g/IY4OEO7xOgYmvx3qGX7bGeeG6xG4uYi0m0I9NiU=;
 b=y3BkAb4cOA19nTsI29w6A52wve6TE0t+BHCi9ZdjwQtnGqWvgh7IabI/Dix1L+vltL6+
 mntY0r37PP1IWDBBTy+2YBtG9v4se2ceir0lqHohVla5X8su6jF8zFNfMLzZHJqbyeU1
 P7wxRQe4TE0yGiwyi12K4n95THbgAXKolLnwQ3PAUfmZ/K9Uh2xPVQCki4weMbQtx+gK
 fM3gayV6jAxZK8ngqPZw4OgFn+fyHMWVmJgWb8KULlqVOON31XdqW9E6VL3Q1lXgInRw
 vPrlF4p/kqvG774Zn14qeO8bBeToxilc59nm88kTTuGYfJpVwnNZlH0PLwkmJY8IM9Md xA== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2130.oracle.com with ESMTP id 3091m390y9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:36 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853K3u158680;
 Wed, 8 Apr 2020 05:05:36 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])
 by userp3030.oracle.com with ESMTP id 3091m01g8r-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:36 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03855YJq022238;
 Wed, 8 Apr 2020 05:05:34 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:34 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 26/26] x86/kvm: Add hint change notifier for
 KVM_HINT_REALTIME
Date: Tue,  7 Apr 2020 22:03:23 -0700
Message-Id: <20200408050323.4237-27-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 mlxlogscore=999 phishscore=0 spamscore=0 adultscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, Joao Martins <joao.m.martins@oracle.com>,
 xen-devel@lists.xenproject.org, kvm@vger.kernel.org, peterz@infradead.org,
 hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add a blocking notifier that triggers when the host sends a hint
change notification.

Suggested-by: Joao Martins <joao.m.martins@oracle.com>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/kvm_para.h | 10 ++++++++++
 arch/x86/kernel/kvm.c           | 16 ++++++++++++++++
 include/asm-generic/kvm_para.h  |  8 ++++++++
 3 files changed, 34 insertions(+)

diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 5a7ca5639c2e..54c3c7a3225e 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -2,6 +2,7 @@
 #ifndef _ASM_X86_KVM_PARA_H
 #define _ASM_X86_KVM_PARA_H
 
+#include <linux/notifier.h>
 #include <asm/processor.h>
 #include <asm/alternative.h>
 #include <uapi/asm/kvm_para.h>
@@ -96,6 +97,9 @@ extern void kvm_disable_steal_time(void);
 void do_async_page_fault(struct pt_regs *regs, unsigned long error_code, unsigned long address);
 void kvm_callback_vector(struct pt_regs *regs);
 
+void kvm_realtime_notifier_register(struct notifier_block *nb);
+void kvm_realtime_notifier_unregister(struct notifier_block *nb);
+
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 void __init kvm_spinlock_init(void);
 #else /* !CONFIG_PARAVIRT_SPINLOCKS */
@@ -137,6 +141,14 @@ static inline void kvm_disable_steal_time(void)
 {
 	return;
 }
+
+static inline void kvm_realtime_notifier_register(struct notifier_block *nb)
+{
+}
+
+static inline void kvm_realtime_notifier_unregister(struct notifier_block *nb)
+{
+}
 #endif
 
 #endif /* _ASM_X86_KVM_PARA_H */
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 163b7a7ec5f9..35ba4a837027 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -951,6 +951,20 @@ void __init kvm_spinlock_init(void)
 static inline bool kvm_pv_spinlock(void) { return false; }
 #endif	/* CONFIG_PARAVIRT_SPINLOCKS */
 
+static BLOCKING_NOTIFIER_HEAD(realtime_notifier);
+
+void kvm_realtime_notifier_register(struct notifier_block *nb)
+{
+	blocking_notifier_chain_register(&realtime_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(kvm_realtime_notifier_register);
+
+void kvm_realtime_notifier_unregister(struct notifier_block *nb)
+{
+	blocking_notifier_chain_unregister(&realtime_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(kvm_realtime_notifier_unregister);
+
 #ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL
 
 static void kvm_disable_host_haltpoll(void *i)
@@ -1004,6 +1018,8 @@ void kvm_trigger_reprobe_cpuid(struct work_struct *work)
 	paravirt_runtime_patch(true);
 
 	mutex_unlock(&text_mutex);
+
+	blocking_notifier_call_chain(&realtime_notifier, 0, NULL);
 }
 
 static DECLARE_WORK(trigger_reprobe, kvm_trigger_reprobe_cpuid);
diff --git a/include/asm-generic/kvm_para.h b/include/asm-generic/kvm_para.h
index 4a575299ad62..d443531b49ac 100644
--- a/include/asm-generic/kvm_para.h
+++ b/include/asm-generic/kvm_para.h
@@ -33,4 +33,12 @@ static inline bool kvm_para_available(void)
 	return false;
 }
 
+static inline void kvm_realtime_notifier_register(struct notifier_block *nb)
+{
+}
+
+static inline void kvm_realtime_notifier_unregister(struct notifier_block *nb)
+{
+}
+
 #endif
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:06:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:06:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2uu-0003dN-4u; Wed, 08 Apr 2020 05:06:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2ut-0003c2-5c
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:06:23 +0000
X-Inumbo-ID: 98167b38-7956-11ea-81bb-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 98167b38-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:05:41 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852xa5179539;
 Wed, 8 Apr 2020 05:05:36 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=7Qqvi8ilezudja6Xt6TMpZeT8QAYzWIZNCTpskFpIKg=;
 b=PlrYMSP2h6k1ZitVeuybm/+AYAE+sB8vRMB0+kQOvow5oszNXceJgjEAAvFiIlmk8dfT
 43T9eS07CTuXT5UodAkvV/QFJS1fQXtS2c29x/cctBkqEX6jmAfoJcWHJC0DTzKAUQWR
 iUbfgYI6KmSYNMk70LnKGdaOG/+UOyrjPqDPs2t9xMboURdOeol/NYZGkwptOCiG14T0
 sbJWNxq07XmOG8CdPD29AbXQVHyC/cFAqZVn9RBzyVvGYcPANFGGd78XxPiAgZ4dOBxM
 VvAY06D+9EnXtAWkr8uALBZMh621nLJ+hx8OYkjVKw5z/RXOjk5BS3CqcxHaLinqXVoO jQ== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by userp2120.oracle.com with ESMTP id 3091mnh158-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:36 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852gSb148301;
 Wed, 8 Apr 2020 05:05:35 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])
 by aserp3030.oracle.com with ESMTP id 3091kgj7qp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:35 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03855Xes022191;
 Wed, 8 Apr 2020 05:05:33 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:33 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 25/26] x86/kvm: Guest support for dynamic hints
Date: Tue,  7 Apr 2020 22:03:22 -0700
Message-Id: <20200408050323.4237-26-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0
 bulkscore=0 suspectscore=0
 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 mlxlogscore=999 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0
 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

If the hypervisor supports KVM_FEATURE_DYNAMIC_HINTS, then register a
callback vector (currently chosen to be HYPERVISOR_CALLBACK_VECTOR.)
The callback triggers on a change in the active hints which are
are exported via KVM CPUID in %ecx.

Trigger re-evaluation of KVM_HINTS based on change in their active
status.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/Kconfig                |  1 +
 arch/x86/entry/entry_64.S       |  5 +++
 arch/x86/include/asm/kvm_para.h |  7 ++++
 arch/x86/kernel/kvm.c           | 58 ++++++++++++++++++++++++++++++---
 include/asm-generic/kvm_para.h  |  4 +++
 include/linux/kvm_para.h        |  5 +++
 6 files changed, 76 insertions(+), 4 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e0629558b6b5..23b239d184fc 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -810,6 +810,7 @@ config KVM_GUEST
 	select PARAVIRT_CLOCK
 	select ARCH_CPUIDLE_HALTPOLL
 	select PARAVIRT_RUNTIME
+	select X86_HV_CALLBACK_VECTOR
 	default y
 	---help---
 	  This option enables various optimizations for running under the KVM
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 0e9504fabe52..96b2a243c54f 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1190,6 +1190,11 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
 	acrn_hv_callback_vector acrn_hv_vector_handler
 #endif
 
+#if IS_ENABLED(CONFIG_KVM_GUEST)
+apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
+	kvm_callback_vector kvm_do_callback
+#endif
+
 idtentry debug			do_debug		has_error_code=0	paranoid=1 shift_ist=IST_INDEX_DB ist_offset=DB_STACK_OFFSET
 idtentry int3			do_int3			has_error_code=0	create_gap=1
 idtentry stack_segment		do_stack_segment	has_error_code=1
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 9b4df6eaa11a..5a7ca5639c2e 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -88,11 +88,13 @@ static inline long kvm_hypercall4(unsigned int nr, unsigned long p1,
 bool kvm_para_available(void);
 unsigned int kvm_arch_para_features(void);
 unsigned int kvm_arch_para_hints(void);
+unsigned int kvm_arch_para_active_hints(void);
 void kvm_async_pf_task_wait(u32 token, int interrupt_kernel);
 void kvm_async_pf_task_wake(u32 token);
 u32 kvm_read_and_reset_pf_reason(void);
 extern void kvm_disable_steal_time(void);
 void do_async_page_fault(struct pt_regs *regs, unsigned long error_code, unsigned long address);
+void kvm_callback_vector(struct pt_regs *regs);
 
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 void __init kvm_spinlock_init(void);
@@ -121,6 +123,11 @@ static inline unsigned int kvm_arch_para_hints(void)
 	return 0;
 }
 
+static inline unsigned int kvm_arch_para_active_hints(void)
+{
+	return 0;
+}
+
 static inline u32 kvm_read_and_reset_pf_reason(void)
 {
 	return 0;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 1cb7eab805a6..163b7a7ec5f9 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -25,6 +25,8 @@
 #include <linux/nmi.h>
 #include <linux/swait.h>
 #include <linux/memory.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
 #include <asm/timer.h>
 #include <asm/cpu.h>
 #include <asm/traps.h>
@@ -438,7 +440,7 @@ static void __init sev_map_percpu_data(void)
 static bool pv_tlb_flush_supported(void)
 {
 	return (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) &&
-		!kvm_para_has_hint(KVM_HINTS_REALTIME) &&
+		!kvm_para_has_active_hint(KVM_HINTS_REALTIME) &&
 		kvm_para_has_feature(KVM_FEATURE_STEAL_TIME));
 }
 
@@ -463,7 +465,7 @@ static bool pv_ipi_supported(void)
 static bool pv_sched_yield_supported(void)
 {
 	return (kvm_para_has_feature(KVM_FEATURE_PV_SCHED_YIELD) &&
-		!kvm_para_has_hint(KVM_HINTS_REALTIME) &&
+		!kvm_para_has_active_hint(KVM_HINTS_REALTIME) &&
 	    kvm_para_has_feature(KVM_FEATURE_STEAL_TIME));
 }
 
@@ -568,7 +570,7 @@ static void kvm_smp_send_call_func_ipi(const struct cpumask *mask)
 static void __init kvm_smp_prepare_cpus(unsigned int max_cpus)
 {
 	native_smp_prepare_cpus(max_cpus);
-	if (kvm_para_has_hint(KVM_HINTS_REALTIME))
+	if (kvm_para_has_active_hint(KVM_HINTS_REALTIME))
 		static_branch_disable(&virt_spin_lock_key);
 }
 
@@ -654,6 +656,13 @@ static bool kvm_pv_tlb(void)
 	return cond;
 }
 
+#ifdef CONFIG_PARAVIRT_RUNTIME
+static bool has_dynamic_hint;
+static void __init kvm_register_callback_vector(void);
+#else
+#define has_dynamic_hint false
+#endif /* CONFIG_PARAVIRT_RUNTIME */
+
 static void __init kvm_guest_init(void)
 {
 	int i;
@@ -674,6 +683,12 @@ static void __init kvm_guest_init(void)
 	if (kvm_para_has_feature(KVM_FEATURE_PV_EOI))
 		apic_set_eoi_write(kvm_guest_apic_eoi_write);
 
+	if (IS_ENABLED(CONFIG_PARAVIRT_RUNTIME) &&
+	    kvm_para_has_feature(KVM_FEATURE_DYNAMIC_HINTS)) {
+		kvm_register_callback_vector();
+		has_dynamic_hint = true;
+	}
+
 #ifdef CONFIG_SMP
 	smp_ops.smp_prepare_cpus = kvm_smp_prepare_cpus;
 	smp_ops.smp_prepare_boot_cpu = kvm_smp_prepare_boot_cpu;
@@ -729,12 +744,27 @@ unsigned int kvm_arch_para_features(void)
 	return cpuid_eax(kvm_cpuid_base() | KVM_CPUID_FEATURES);
 }
 
+/*
+ * Universe of hints that's ever been given to this guest.
+ */
 unsigned int kvm_arch_para_hints(void)
 {
 	return cpuid_edx(kvm_cpuid_base() | KVM_CPUID_FEATURES);
 }
 EXPORT_SYMBOL_GPL(kvm_arch_para_hints);
 
+/*
+ * Currently active set of hints. Reading can race with modifications.
+ */
+unsigned int kvm_arch_para_active_hints(void)
+{
+	if (has_dynamic_hint)
+		return cpuid_ecx(kvm_cpuid_base() | KVM_CPUID_FEATURES);
+	else
+		return kvm_arch_para_hints();
+}
+EXPORT_SYMBOL_GPL(kvm_arch_para_active_hints);
+
 static uint32_t __init kvm_detect(void)
 {
 	return kvm_cpuid_base();
@@ -878,7 +908,7 @@ static inline bool kvm_para_lock_ops(void)
 {
 	/* Does host kernel support KVM_FEATURE_PV_UNHALT? */
 	return kvm_para_has_feature(KVM_FEATURE_PV_UNHALT) &&
-		!kvm_para_has_hint(KVM_HINTS_REALTIME);
+		!kvm_para_has_active_hint(KVM_HINTS_REALTIME);
 }
 
 static bool kvm_pv_spinlock(void)
@@ -975,4 +1005,24 @@ void kvm_trigger_reprobe_cpuid(struct work_struct *work)
 
 	mutex_unlock(&text_mutex);
 }
+
+static DECLARE_WORK(trigger_reprobe, kvm_trigger_reprobe_cpuid);
+
+void __irq_entry kvm_do_callback(struct pt_regs *regs)
+{
+	struct pt_regs *old_regs = set_irq_regs(regs);
+
+	irq_enter();
+	inc_irq_stat(irq_hv_callback_count);
+
+	schedule_work(&trigger_reprobe);
+	irq_exit();
+	set_irq_regs(old_regs);
+}
+
+static void __init kvm_register_callback_vector(void)
+{
+	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, kvm_callback_vector);
+	wrmsrl(MSR_KVM_HINT_VECTOR, HYPERVISOR_CALLBACK_VECTOR);
+}
 #endif /* CONFIG_PARAVIRT_RUNTIME */
diff --git a/include/asm-generic/kvm_para.h b/include/asm-generic/kvm_para.h
index 728e5c5706c4..4a575299ad62 100644
--- a/include/asm-generic/kvm_para.h
+++ b/include/asm-generic/kvm_para.h
@@ -24,6 +24,10 @@ static inline unsigned int kvm_arch_para_hints(void)
 	return 0;
 }
 
+static inline unsigned int kvm_arch_para_active_hints(void)
+{
+	return 0;
+}
 static inline bool kvm_para_available(void)
 {
 	return false;
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index f23b90b02898..c98d3944d25a 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -14,4 +14,9 @@ static inline bool kvm_para_has_hint(unsigned int feature)
 {
 	return !!(kvm_arch_para_hints() & (1UL << feature));
 }
+
+static inline bool kvm_para_has_active_hint(unsigned int feature)
+{
+	return !!(kvm_arch_para_active_hints() & BIT(feature));
+}
 #endif /* __LINUX_KVM_PARA_H */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:07:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:07:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2vi-0004MP-I6; Wed, 08 Apr 2020 05:07:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2vh-0004LP-7U
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:07:13 +0000
X-Inumbo-ID: caca5ace-7956-11ea-81bb-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id caca5ace-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:07:08 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 038531q8179572;
 Wed, 8 Apr 2020 05:07:02 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=ssuzsbfGr+UP4f7vc9tDGOuDdiCw4ECans2QkELpN/o=;
 b=DF5tG1seAt9KkNyuEPs859A3/N7Z5Dar4IGAhqpC5aYgjyyzMmHQn2AgDX0IqU+sT+1N
 VPSFr3N9FFpywMgFiXOwNJjP4KRUz4E5dqFIQBBgcTeN1XDH/Qf2MIeCw3oHJPnZQR5g
 RbYyfAucvn8uNWXH1a4jczS6/aI/30fojyT6nK27iuR0uBc5uRV90g0xQnw4FSOy05rY
 bgc6dDRPE5jDAtPuXWv/w9+qGvQ4KpKgqOVtIJQygxNkOe5o/CLl7AlTk33O5iSA1q2l
 kDYYEav/L+kMFa1SgqKpRk657rjE6DP7bVbfSKLT00HjKegvGXYtTFrR4+7WFCtIugbS RA== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by userp2120.oracle.com with ESMTP id 3091mnh19q-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:07:02 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852fSY148154;
 Wed, 8 Apr 2020 05:05:01 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by aserp3030.oracle.com with ESMTP id 3091kgj6st-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:01 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03854xi6007309;
 Wed, 8 Apr 2020 05:04:59 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:04:59 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 03/26] x86/paravirt: PVRTOP macros for PARAVIRT_RUNTIME
Date: Tue,  7 Apr 2020 22:03:00 -0700
Message-Id: <20200408050323.4237-4-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0
 bulkscore=0 suspectscore=0
 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=752
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 mlxlogscore=813 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0
 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Define PVRT* macros which can be used to put pv-ops in
.parainstructions.runtime.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/paravirt_types.h | 49 +++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 00e4a062ca10..f1153f53c529 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -337,6 +337,12 @@ struct paravirt_patch_template {
 extern struct pv_info pv_info;
 extern struct paravirt_patch_template pv_ops;
 
+#ifdef CONFIG_PARAVIRT_RUNTIME
+#define PVRT_SUFFIX ".runtime"
+#else
+#define PVRT_SUFFIX ""
+#endif
+
 /* Sub-section for .parainstructions */
 #define PV_SUFFIX ""
 
@@ -693,6 +699,49 @@ int paravirt_disable_iospace(void);
 #define PVOP_VCALL4(op, arg1, arg2, arg3, arg4)				\
 	_PVOP_VCALL4(PV_SUFFIX, op, arg1, arg2, arg3, arg4)
 
+/*
+ * PVRTOP macros for .parainstructions.runtime
+ */
+#define PVRTOP_CALL0(rettype, op)					\
+	_PVOP_CALL0(PVRT_SUFFIX, rettype, op)
+#define PVRTOP_VCALL0(op)						\
+	_PVOP_VCALL0(PVRT_SUFFIX, op)
+
+#define PVRTOP_CALLEE0(rettype, op)					\
+	_PVOP_CALLEE0(PVRT_SUFFIX, rettype, op)
+#define PVRTOP_VCALLEE0(op)						\
+	_PVOP_VCALLEE0(PVRT_SUFFIX, op)
+
+#define PVRTOP_CALL1(rettype, op, arg1)					\
+	_PVOP_CALL1(PVRT_SUFFIX, rettype, op, arg1)
+#define PVRTOP_VCALL1(op, arg1)						\
+	_PVOP_VCALL1(PVRT_SUFFIX, op, arg1)
+
+#define PVRTOP_CALLEE1(rettype, op, arg1)				\
+	_PVOP_CALLEE1(PVRT_SUFFIX, rettype, op, arg1)
+#define PVRTOP_VCALLEE1(op, arg1)					\
+	_PVOP_VCALLEE1(PVRT_SUFFIX, op, arg1)
+
+#define PVRTOP_CALL2(rettype, op, arg1, arg2)				\
+	_PVOP_CALL2(PVRT_SUFFIX, rettype, op, arg1, arg2)
+#define PVRTOP_VCALL2(op, arg1, arg2)					\
+	_PVOP_VCALL2(PVRT_SUFFIX, op, arg1, arg2)
+
+#define PVRTOP_CALLEE2(rettype, op, arg1, arg2)				\
+	_PVOP_CALLEE2(PVRT_SUFFIX, rettype, op, arg1, arg2)
+#define PVRTOP_VCALLEE2(op, arg1, arg2)					\
+	_PVOP_VCALLEE2(PVRT_SUFFIX, op, arg1, arg2)
+
+#define PVRTOP_CALL3(rettype, op, arg1, arg2, arg3)			\
+	_PVOP_CALL3(PVRT_SUFFIX, rettype, op, arg1, arg2, arg3)
+#define PVRTOP_VCALL3(op, arg1, arg2, arg3)				\
+	_PVOP_VCALL3(PVRT_SUFFIX, op, arg1, arg2, arg3)
+
+#define PVRTOP_CALL4(rettype, op, arg1, arg2, arg3, arg4)		\
+	_PVOP_CALL4(PVRT_SUFFIX, rettype, op, arg1, arg2, arg3, arg4)
+#define PVRTOP_VCALL4(op, arg1, arg2, arg3, arg4)			\
+	_PVOP_VCALL4(PVRT_SUFFIX, op, arg1, arg2, arg3, arg4)
+
 /* Lazy mode for batching updates / context switch */
 enum paravirt_lazy_mode {
 	PARAVIRT_LAZY_NONE,
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:07:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:07:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2vm-0004Ou-Qz; Wed, 08 Apr 2020 05:07:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2vm-0004OS-7l
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:07:18 +0000
X-Inumbo-ID: ccaca142-7956-11ea-81bb-12813bfff9fa
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ccaca142-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:07:10 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03854F75012937;
 Wed, 8 Apr 2020 05:07:03 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=b9ZDBcnjVqZYjAykwqlmE2xiwEK9dL8itGzqN60MSKM=;
 b=yvqh2h8fRSDw2IhBIhVmT8Jhg9RgCzoi3zM12GriJP7fRL7dt2B//8NqeTUyB00lh8X8
 IGGhpQ/2Bon2IuLfRqt9DwjBZXJ7PQf6SkIEadHvUmDYV4eToQQetFRQVdux8EYCGWin
 l4bX6zTIsPz9IeO2nXSUunQMy7sO4/t/ONz7K9g+FfZP5LYPCJQMbi+k5CH5htsMNWBq
 nM/zMdP6NNwLvJLu83EW/rx0DSl3EEyxneBAuHj+sm1CQ3GM4d717qkNjFOP/vZu6+yN
 Zy9Y59GZbOzSafi2urXoMJmSD4oLAPKhMSTKhg0MLR6pb+ZS74PmsNVFAya2wIY3SGoA qQ== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2130.oracle.com with ESMTP id 3091m3914c-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:07:03 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03853Ksr158690;
 Wed, 8 Apr 2020 05:05:03 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userp3030.oracle.com with ESMTP id 3091m01fjb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:03 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 038551MG007321;
 Wed, 8 Apr 2020 05:05:01 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:01 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 04/26] x86/alternatives: Refactor alternatives_smp_module*
Date: Tue,  7 Apr 2020 22:03:01 -0700
Message-Id: <20200408050323.4237-5-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 mlxlogscore=999 phishscore=0 spamscore=0 adultscore=0 suspectscore=2
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=2 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Refactor alternatives_smp_module* logic to make it available for
holding generic late patching state.

Most of the changes are to pull the module handling logic out
from CONFIG_SMP. In addition now we unconditionally call
alternatives_smp_module_add() and make the decision on patching
for UP or not there.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/include/asm/alternative.h | 13 ++-----
 arch/x86/kernel/alternative.c      | 55 ++++++++++++++++--------------
 2 files changed, 32 insertions(+), 36 deletions(-)

diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
index 13adca37c99a..8235bbb746d9 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -75,24 +75,15 @@ extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
 
 struct module;
 
-#ifdef CONFIG_SMP
 extern void alternatives_smp_module_add(struct module *mod, char *name,
 					void *locks, void *locks_end,
 					void *text, void *text_end);
 extern void alternatives_smp_module_del(struct module *mod);
-extern void alternatives_enable_smp(void);
 extern int alternatives_text_reserved(void *start, void *end);
-extern bool skip_smp_alternatives;
+#ifdef CONFIG_SMP
+extern void alternatives_enable_smp(void);
 #else
-static inline void alternatives_smp_module_add(struct module *mod, char *name,
-					       void *locks, void *locks_end,
-					       void *text, void *text_end) {}
-static inline void alternatives_smp_module_del(struct module *mod) {}
 static inline void alternatives_enable_smp(void) {}
-static inline int alternatives_text_reserved(void *start, void *end)
-{
-	return 0;
-}
 #endif	/* CONFIG_SMP */
 
 #define b_replacement(num)	"664"#num
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index fdfda1375f82..32aa1ddf441d 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -470,6 +470,13 @@ static void alternatives_smp_unlock(const s32 *start, const s32 *end,
 	}
 }
 
+static bool uniproc_patched;	/* protected by text_mutex */
+#else	/* !CONFIG_SMP */
+#define uniproc_patched false
+static inline void alternatives_smp_unlock(const s32 *start, const s32 *end,
+					   u8 *text, u8 *text_end) { }
+#endif	/* CONFIG_SMP */
+
 struct smp_alt_module {
 	/* what is this ??? */
 	struct module	*mod;
@@ -486,7 +493,6 @@ struct smp_alt_module {
 	struct list_head next;
 };
 static LIST_HEAD(smp_alt_modules);
-static bool uniproc_patched = false;	/* protected by text_mutex */
 
 void __init_or_module alternatives_smp_module_add(struct module *mod,
 						  char *name,
@@ -495,23 +501,27 @@ void __init_or_module alternatives_smp_module_add(struct module *mod,
 {
 	struct smp_alt_module *smp;
 
-	mutex_lock(&text_mutex);
+#ifdef CONFIG_SMP
+	/* Patch to UP if other cpus not imminent. */
+	if (!noreplace_smp && (num_present_cpus() == 1 || setup_max_cpus <= 1))
+		uniproc_patched = true;
+#endif
 	if (!uniproc_patched)
-		goto unlock;
+		return;
 
-	if (num_possible_cpus() == 1)
-		/* Don't bother remembering, we'll never have to undo it. */
-		goto smp_unlock;
+	mutex_lock(&text_mutex);
 
-	smp = kzalloc(sizeof(*smp), GFP_KERNEL);
-	if (NULL == smp)
-		/* we'll run the (safe but slow) SMP code then ... */
-		goto unlock;
+	smp = kzalloc(sizeof(*smp), GFP_KERNEL | __GFP_NOFAIL);
 
 	smp->mod	= mod;
 	smp->name	= name;
-	smp->locks	= locks;
-	smp->locks_end	= locks_end;
+
+	if (num_possible_cpus() != 1 || uniproc_patched) {
+		/* Remember only if we'll need to undo it. */
+		smp->locks	= locks;
+		smp->locks_end	= locks_end;
+	}
+
 	smp->text	= text;
 	smp->text_end	= text_end;
 	DPRINTK("locks %p -> %p, text %p -> %p, name %s\n",
@@ -519,9 +529,9 @@ void __init_or_module alternatives_smp_module_add(struct module *mod,
 		smp->text, smp->text_end, smp->name);
 
 	list_add_tail(&smp->next, &smp_alt_modules);
-smp_unlock:
-	alternatives_smp_unlock(locks, locks_end, text, text_end);
-unlock:
+
+	if (uniproc_patched)
+		alternatives_smp_unlock(locks, locks_end, text, text_end);
 	mutex_unlock(&text_mutex);
 }
 
@@ -540,6 +550,7 @@ void __init_or_module alternatives_smp_module_del(struct module *mod)
 	mutex_unlock(&text_mutex);
 }
 
+#ifdef CONFIG_SMP
 void alternatives_enable_smp(void)
 {
 	struct smp_alt_module *mod;
@@ -561,6 +572,7 @@ void alternatives_enable_smp(void)
 	}
 	mutex_unlock(&text_mutex);
 }
+#endif /* CONFIG_SMP */
 
 /*
  * Return 1 if the address range is reserved for SMP-alternatives.
@@ -588,7 +600,6 @@ int alternatives_text_reserved(void *start, void *end)
 
 	return 0;
 }
-#endif /* CONFIG_SMP */
 
 #ifdef CONFIG_PARAVIRT
 void __init_or_module apply_paravirt(struct paravirt_patch_site *start,
@@ -723,21 +734,15 @@ void __init alternative_instructions(void)
 
 	apply_alternatives(__alt_instructions, __alt_instructions_end);
 
-#ifdef CONFIG_SMP
-	/* Patch to UP if other cpus not imminent. */
-	if (!noreplace_smp && (num_present_cpus() == 1 || setup_max_cpus <= 1)) {
-		uniproc_patched = true;
-		alternatives_smp_module_add(NULL, "core kernel",
-					    __smp_locks, __smp_locks_end,
-					    _text, _etext);
-	}
+	alternatives_smp_module_add(NULL, "core kernel",
+				    __smp_locks, __smp_locks_end,
+				    _text, _etext);
 
 	if (!uniproc_patched || num_possible_cpus() == 1) {
 		free_init_pages("SMP alternatives",
 				(unsigned long)__smp_locks,
 				(unsigned long)__smp_locks_end);
 	}
-#endif
 
 	apply_paravirt(__parainstructions, __parainstructions_end);
 	apply_paravirt(__parainstructions_runtime,
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:07:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2vx-0004UY-4o; Wed, 08 Apr 2020 05:07:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2vw-0004UD-7u
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:07:28 +0000
X-Inumbo-ID: d59d9162-7956-11ea-81bb-12813bfff9fa
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d59d9162-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:07:25 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 038553bq013448;
 Wed, 8 Apr 2020 05:07:19 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=jtenwkhxJwQP2uq2B69E8Rt6lQLXw7OMtcgth/iQeLE=;
 b=rRyPLGp4AV4NTgpv3HbnBcQ7xi+6GgDMb68GyvXgeEhCjSMF6ysWqwYzf7YpGW/uJiQW
 Fl8krSNYEc/p+LC9gyJHE1S5WR1iuo0vMrP3nJHdB8saF1Jw3mo2oqfIgWRhYKvPF1p7
 Uw2FQ74MmTPitiYxcvgIQ0kbhOLcwOuoFK5RFTT3vpoyc/2D0JHD7bMk8ZvhhaJGCrSm
 wC7lni75F9GI7ehsae7NyFMzWCwJjHBVrugyTPdblSdk89Z5pO5iQ3RDD2uiPIcdPfTJ
 ktNEWQUDZ2W1eLam26fvFBy1P/ka5AIDkRC8dGg8z918WC1UQ3hSAKntgBBIJe8Lk9lZ sg== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by userp2130.oracle.com with ESMTP id 3091m39155-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:07:19 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03851WCB100753;
 Wed, 8 Apr 2020 05:05:18 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by aserp3020.oracle.com with ESMTP id 3091m2hv20-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:18 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03855H45007452;
 Wed, 8 Apr 2020 05:05:17 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:17 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 13/26] x86/alternatives: Split __text_poke()
Date: Tue,  7 Apr 2020 22:03:10 -0700
Message-Id: <20200408050323.4237-14-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 mlxscore=0
 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=873
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=934
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Separate __text_poke() into map, memcpy and unmap portions,
(__text_poke_map(), __text_do_poke() and __text_poke_unmap().)

Do this to separate the non-reentrant bits from the reentrant
__text_do_poke(). __text_poke_map()/_unmap() modify poking_mm,
poking_addr and do the pte-mapping and thus are non-reentrant.

This allows __text_do_poke() to be safely called from an INT3
context with __text_poke_map()/_unmap() being called at the
start and the end of the patching of a call-site instead of
doing that for each stage of the three patching stages.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/kernel/alternative.c | 46 +++++++++++++++++++++++++----------
 1 file changed, 33 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 0344e49a4ade..337aad8c2521 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -805,13 +805,12 @@ void __init_or_module text_poke_early(void *addr, const void *opcode,
 __ro_after_init struct mm_struct *poking_mm;
 __ro_after_init unsigned long poking_addr;
 
-static void __text_poke(void *addr, const void *opcode, size_t len)
+static void __text_poke_map(void *addr, size_t len,
+			    temp_mm_state_t *prev_mm, pte_t **ptep)
 {
 	bool cross_page_boundary = offset_in_page(addr) + len > PAGE_SIZE;
 	struct page *pages[2] = {NULL};
-	temp_mm_state_t prev;
-	unsigned long flags;
-	pte_t pte, *ptep;
+	pte_t pte;
 	pgprot_t pgprot;
 
 	/*
@@ -836,8 +835,6 @@ static void __text_poke(void *addr, const void *opcode, size_t len)
 	 */
 	BUG_ON(!pages[0] || (cross_page_boundary && !pages[1]));
 
-	local_irq_save(flags);
-
 	/*
 	 * Map the page without the global bit, as TLB flushing is done with
 	 * flush_tlb_mm_range(), which is intended for non-global PTEs.
@@ -849,30 +846,42 @@ static void __text_poke(void *addr, const void *opcode, size_t len)
 	 * unlocked. This does mean that we need to be careful that no other
 	 * context (ex. INT3 handler) is simultaneously writing to this pte.
 	 */
-	ptep = __get_unlocked_pte(poking_mm, poking_addr);
+	*ptep = __get_unlocked_pte(poking_mm, poking_addr);
 	/*
 	 * This must not fail; preallocated in poking_init().
 	 */
-	VM_BUG_ON(!ptep);
+	VM_BUG_ON(!*ptep);
 
 	pte = mk_pte(pages[0], pgprot);
-	set_pte_at(poking_mm, poking_addr, ptep, pte);
+	set_pte_at(poking_mm, poking_addr, *ptep, pte);
 
 	if (cross_page_boundary) {
 		pte = mk_pte(pages[1], pgprot);
-		set_pte_at(poking_mm, poking_addr + PAGE_SIZE, ptep + 1, pte);
+		set_pte_at(poking_mm, poking_addr + PAGE_SIZE, *ptep + 1, pte);
 	}
 
 	/*
 	 * Loading the temporary mm behaves as a compiler barrier, which
 	 * guarantees that the PTE will be set at the time memcpy() is done.
 	 */
-	prev = use_temporary_mm(poking_mm);
+	*prev_mm = use_temporary_mm(poking_mm);
+}
 
+/*
+ * Do the actual poke. Needs to be re-entrant as this can be called
+ * via INT3 context as well.
+ */
+static void __text_do_poke(unsigned long offset, const void *opcode, size_t len)
+{
 	kasan_disable_current();
-	memcpy((u8 *)poking_addr + offset_in_page(addr), opcode, len);
+	memcpy((u8 *)poking_addr + offset, opcode, len);
 	kasan_enable_current();
+}
 
+static void __text_poke_unmap(void *addr, const void *opcode, size_t len,
+			      temp_mm_state_t *prev_mm, pte_t *ptep)
+{
+	bool cross_page_boundary = offset_in_page(addr) + len > PAGE_SIZE;
 	/*
 	 * Ensure that the PTE is only cleared after the instructions of memcpy
 	 * were issued by using a compiler barrier.
@@ -888,7 +897,7 @@ static void __text_poke(void *addr, const void *opcode, size_t len)
 	 * instruction that already allows the core to see the updated version.
 	 * Xen-PV is assumed to serialize execution in a similar manner.
 	 */
-	unuse_temporary_mm(prev);
+	unuse_temporary_mm(*prev_mm);
 
 	/*
 	 * Flushing the TLB might involve IPIs, which would require enabled
@@ -903,7 +912,18 @@ static void __text_poke(void *addr, const void *opcode, size_t len)
 	 * fundamentally screwy; there's nothing we can really do about that.
 	 */
 	BUG_ON(memcmp(addr, opcode, len));
+}
 
+static void __text_poke(void *addr, const void *opcode, size_t len)
+{
+	temp_mm_state_t prev_mm;
+	unsigned long flags;
+	pte_t *ptep;
+
+	local_irq_save(flags);
+	__text_poke_map(addr, len, &prev_mm, &ptep);
+	__text_do_poke(offset_in_page(addr), opcode, len);
+	__text_poke_unmap(addr, opcode, len, &prev_mm, ptep);
 	local_irq_restore(flags);
 }
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:07:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:07:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2w8-0004Yt-In; Wed, 08 Apr 2020 05:07:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2w6-0004YC-M0
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:07:38 +0000
X-Inumbo-ID: dd4c6e4c-7956-11ea-81bb-12813bfff9fa
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id dd4c6e4c-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:07:38 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 038542I1012889;
 Wed, 8 Apr 2020 05:07:32 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=BUklSOLzYwRiPoSEy5WnSrk9xDtG8YVnZFCF9aTkapM=;
 b=HAM6OV/lJ8vmGWaH8HEJdwRVp6ooCzYRoUgChfSW/OrSpqxiPml6ta3JoC90TxAKpbMs
 /Aw45BvATgx0Gcb944Wm1+NEmIyniu3IdIy9ErStnhlW3Bc0dWmZTJdB3sq08USIeKo/
 aqkvcvZA2mZGOwjMug+1v+JOivODST/9JEJwD93eAR9vuYHZGeissmTBP4cMlxdEJan1
 U/qEsbPmwI1VaIxk6TYSwbVGnWc9dH2xDJBKxKQYq17Er/B8vs95H2Zsew/xzl6XYBFB
 TbYIeOc2t3aZfJw6LgrJ1ZcG29Oaic0u0EqByPailVmBhykZpOmmRBElQQBF1OUqBn75 CQ== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by userp2130.oracle.com with ESMTP id 3091m3915p-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:07:32 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03851Wqa100631;
 Wed, 8 Apr 2020 05:05:31 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])
 by aserp3020.oracle.com with ESMTP id 3091m2hvmg-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:31 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03855TSJ022184;
 Wed, 8 Apr 2020 05:05:29 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:29 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 22/26] kvm/paravirt: Encapsulate KVM pv switching logic
Date: Tue,  7 Apr 2020 22:03:19 -0700
Message-Id: <20200408050323.4237-23-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 mlxscore=0
 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

KVM pv-ops are dependent on KVM features/hints which are exposed
via CPUID. Decouple the probing and the enabling of these ops from
__init so they can be called post-init as well.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 arch/x86/Kconfig      |  1 +
 arch/x86/kernel/kvm.c | 87 ++++++++++++++++++++++++++++++-------------
 2 files changed, 63 insertions(+), 25 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 605619938f08..e0629558b6b5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -809,6 +809,7 @@ config KVM_GUEST
 	depends on PARAVIRT
 	select PARAVIRT_CLOCK
 	select ARCH_CPUIDLE_HALTPOLL
+	select PARAVIRT_RUNTIME
 	default y
 	---help---
 	  This option enables various optimizations for running under the KVM
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index e56d263159d7..31f5ecfd3907 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -24,6 +24,7 @@
 #include <linux/debugfs.h>
 #include <linux/nmi.h>
 #include <linux/swait.h>
+#include <linux/memory.h>
 #include <asm/timer.h>
 #include <asm/cpu.h>
 #include <asm/traps.h>
@@ -262,12 +263,20 @@ do_async_page_fault(struct pt_regs *regs, unsigned long error_code, unsigned lon
 }
 NOKPROBE_SYMBOL(do_async_page_fault);
 
+static bool kvm_pv_io_delay(void)
+{
+	bool cond = kvm_para_has_feature(KVM_FEATURE_NOP_IO_DELAY);
+
+	paravirt_stage_alt(cond, cpu.io_delay, kvm_io_delay);
+
+	return cond;
+}
+
 static void __init paravirt_ops_setup(void)
 {
 	pv_info.name = "KVM";
 
-	if (kvm_para_has_feature(KVM_FEATURE_NOP_IO_DELAY))
-		pv_ops.cpu.io_delay = kvm_io_delay;
+	kvm_pv_io_delay();
 
 #ifdef CONFIG_X86_IO_APIC
 	no_timer_check = 1;
@@ -432,6 +441,15 @@ static bool pv_tlb_flush_supported(void)
 		kvm_para_has_feature(KVM_FEATURE_STEAL_TIME));
 }
 
+static bool kvm_pv_steal_clock(void)
+{
+	bool cond = kvm_para_has_feature(KVM_FEATURE_STEAL_TIME);
+
+	paravirt_stage_alt(cond, time.steal_clock, kvm_steal_clock);
+
+	return cond;
+}
+
 static DEFINE_PER_CPU(cpumask_var_t, __pv_cpu_mask);
 
 #ifdef CONFIG_SMP
@@ -624,6 +642,17 @@ static void kvm_flush_tlb_others(const struct cpumask *cpumask,
 	native_flush_tlb_others(flushmask, info);
 }
 
+static bool kvm_pv_tlb(void)
+{
+	bool cond = pv_tlb_flush_supported();
+
+	paravirt_stage_alt(cond, mmu.flush_tlb_others,
+			   kvm_flush_tlb_others);
+	paravirt_stage_alt(cond, mmu.tlb_remove_table,
+			   tlb_remove_table);
+	return cond;
+}
+
 static void __init kvm_guest_init(void)
 {
 	int i;
@@ -635,16 +664,11 @@ static void __init kvm_guest_init(void)
 	if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF))
 		x86_init.irqs.trap_init = kvm_apf_trap_init;
 
-	if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
+	if (kvm_pv_steal_clock())
 		has_steal_clock = 1;
-		pv_ops.time.steal_clock = kvm_steal_clock;
-	}
 
-	if (pv_tlb_flush_supported()) {
-		pv_ops.mmu.flush_tlb_others = kvm_flush_tlb_others;
-		pv_ops.mmu.tlb_remove_table = tlb_remove_table;
+	if (kvm_pv_tlb())
 		pr_info("KVM setup pv remote TLB flush\n");
-	}
 
 	if (kvm_para_has_feature(KVM_FEATURE_PV_EOI))
 		apic_set_eoi_write(kvm_guest_apic_eoi_write);
@@ -849,33 +873,46 @@ asm(
 
 #endif
 
+static inline bool kvm_para_lock_ops(void)
+{
+	/* Does host kernel support KVM_FEATURE_PV_UNHALT? */
+	return kvm_para_has_feature(KVM_FEATURE_PV_UNHALT) &&
+		!kvm_para_has_hint(KVM_HINTS_REALTIME);
+}
+
+static bool kvm_pv_spinlock(void)
+{
+	bool cond = kvm_para_lock_ops();
+	bool preempt_cond = cond &&
+			kvm_para_has_feature(KVM_FEATURE_STEAL_TIME);
+
+	paravirt_stage_alt(cond, lock.queued_spin_lock_slowpath,
+			   __pv_queued_spin_lock_slowpath);
+	paravirt_stage_alt(cond, lock.queued_spin_unlock.func,
+			   PV_CALLEE_SAVE(__pv_queued_spin_unlock).func);
+	paravirt_stage_alt(cond, lock.wait, kvm_wait);
+	paravirt_stage_alt(cond, lock.kick, kvm_kick_cpu);
+
+	paravirt_stage_alt(preempt_cond,
+			   lock.vcpu_is_preempted.func,
+			   PV_CALLEE_SAVE(__kvm_vcpu_is_preempted).func);
+	return cond;
+}
+
 /*
  * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
  */
 void __init kvm_spinlock_init(void)
 {
-	/* Does host kernel support KVM_FEATURE_PV_UNHALT? */
-	if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
-		return;
-
-	if (kvm_para_has_hint(KVM_HINTS_REALTIME))
-		return;
 
 	/* Don't use the pvqspinlock code if there is only 1 vCPU. */
 	if (num_possible_cpus() == 1)
 		return;
 
-	__pv_init_lock_hash();
-	pv_ops.lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
-	pv_ops.lock.queued_spin_unlock =
-		PV_CALLEE_SAVE(__pv_queued_spin_unlock);
-	pv_ops.lock.wait = kvm_wait;
-	pv_ops.lock.kick = kvm_kick_cpu;
+	if (!kvm_pv_spinlock())
+		return;
 
-	if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
-		pv_ops.lock.vcpu_is_preempted =
-			PV_CALLEE_SAVE(__kvm_vcpu_is_preempted);
-	}
+	__pv_init_lock_hash();
 }
 
 #endif	/* CONFIG_PARAVIRT_SPINLOCKS */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:07:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:07:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM2w9-0004Zd-Rh; Wed, 08 Apr 2020 05:07:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=sdaI=5Y=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jM2w8-0004Yf-1m
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 05:07:40 +0000
X-Inumbo-ID: ddfba5f6-7956-11ea-81bb-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ddfba5f6-7956-11ea-81bb-12813bfff9fa;
 Wed, 08 Apr 2020 05:07:39 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 038531WJ179569;
 Wed, 8 Apr 2020 05:07:33 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : in-reply-to : references : mime-version :
 content-transfer-encoding; s=corp-2020-01-29;
 bh=KVN+YCf5xOl2+mEkv4Kw5562VW/mACAX0RWsY+6VPF0=;
 b=O56kEp6CQgL39BRDHove3tAhSFX2lvkADbjJWBm5rDMDLICBVmPc4d2u9AFCkVA4D9DC
 7KcyKyyjfEqQ3Ed+a+i5xCgUVsR4Rtx0vBZ03hEmvRQgvk+ls6Y9CfLfzTtmBGGeZ4s7
 n4TC4mYp78RaJwzlLr/v/XXYr3IKpqAJbHiaU2pIq0cTPiCU4/wndYJK9TCL1Ql918Ve
 WLq+jXywMB3Za0bcGyXnnv+gtAvoAOR/3xn9qZ1TFwLyJ+N9SLQ9As8kJxdezHkkIEnm
 fNjALKL/oE1JPgg/mXLr5Z/2HjqsZQOhD3HzqnuSrVOkO31+wXlUzlKFbCyLN8KUKaEh 0g== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by userp2120.oracle.com with ESMTP id 3091mnh1b2-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:07:33 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03852gtx148283;
 Wed, 8 Apr 2020 05:05:32 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
 by aserp3030.oracle.com with ESMTP id 3091kgj7pg-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 08 Apr 2020 05:05:32 +0000
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
 by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03855W7k030624;
 Wed, 8 Apr 2020 05:05:32 GMT
Received: from monad.ca.oracle.com (/10.156.75.81)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 07 Apr 2020 22:05:31 -0700
From: Ankur Arora <ankur.a.arora@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [RFC PATCH 24/26] x86/kvm: Support dynamic CPUID hints
Date: Tue,  7 Apr 2020 22:03:21 -0700
Message-Id: <20200408050323.4237-25-ankur.a.arora@oracle.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0
 bulkscore=0 suspectscore=0
 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9584
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 mlxlogscore=999 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0
 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004080037
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Change in the state of a KVM hint like KVM_HINTS_REALTIME can lead
to significant performance impact. Given that the hint might not be
stable across the lifetime of a guest, dynamic hints allow the host
to inform the guest if the hint changes.

Do this via KVM CPUID leaf in %ecx.  If the guest has registered a
callback via MSR_KVM_HINT_VECTOR, the hint change is notified to it by
means of a callback triggered via vcpu ioctl KVM_CALLBACK.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
The callback vector is currently tied in with the hint notification
and can (should) be made more generic such that we could deliver
arbitrary callbacks on it.

One use might be for TSC frequency switching notifications support for
emulated Hyper-V guests.

---
 Documentation/virt/kvm/api.rst       | 17 ++++++++++++
 Documentation/virt/kvm/cpuid.rst     |  9 +++++--
 arch/x86/include/asm/kvm_host.h      |  6 +++++
 arch/x86/include/uapi/asm/kvm_para.h |  2 ++
 arch/x86/kvm/cpuid.c                 |  3 ++-
 arch/x86/kvm/x86.c                   | 39 ++++++++++++++++++++++++++++
 include/uapi/linux/kvm.h             |  4 +++
 7 files changed, 77 insertions(+), 3 deletions(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index efbbe570aa9b..40a9b22d6979 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -4690,6 +4690,17 @@ KVM_PV_VM_VERIFY
   Verify the integrity of the unpacked image. Only if this succeeds,
   KVM is allowed to start protected VCPUs.
 
+4.126 KVM_CALLBACK
+------------------
+
+:Capability: KVM_CAP_CALLBACK
+:Architectures: x86
+:Type: vcpu ioctl
+:Parameters: none
+:Returns: 0 on success, -1 on error
+
+Queues a callback on the guess's vcpu if a callback has been regisered.
+
 
 5. The kvm_run structure
 ========================
@@ -6109,3 +6120,9 @@ KVM can therefore start protected VMs.
 This capability governs the KVM_S390_PV_COMMAND ioctl and the
 KVM_MP_STATE_LOAD MP_STATE. KVM_SET_MP_STATE can fail for protected
 guests when the state change is invalid.
+
+8.24 KVM_CAP_CALLBACK
+
+Architectures: x86_64
+
+This capability indicates that the ioctl KVM_CALLBACK is available.
diff --git a/Documentation/virt/kvm/cpuid.rst b/Documentation/virt/kvm/cpuid.rst
index 01b081f6e7ea..5a997c9e74c0 100644
--- a/Documentation/virt/kvm/cpuid.rst
+++ b/Documentation/virt/kvm/cpuid.rst
@@ -86,6 +86,9 @@ KVM_FEATURE_PV_SCHED_YIELD        13          guest checks this feature bit
                                               before using paravirtualized
                                               sched yield.
 
+KVM_FEATURE_DYNAMIC_HINTS	  14	      guest handles feature hints
+					      changing under it.
+
 KVM_FEATURE_CLOCSOURCE_STABLE_BIT 24          host will warn if no guest-side
                                               per-cpu warps are expeced in
                                               kvmclock
@@ -93,9 +96,11 @@ KVM_FEATURE_CLOCSOURCE_STABLE_BIT 24          host will warn if no guest-side
 
 ::
 
-      edx = an OR'ed group of (1 << flag)
+      ecx, edx = an OR'ed group of (1 << flag)
 
-Where ``flag`` here is defined as below:
+Where the ``flag`` in ecx is currently applicable hints, and ``flag`` in
+edx is the union of all hints ever provided to the guest, both drawn from
+the set listed below:
 
 ================== ============ =================================
 flag               value        meaning
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 42a2d0d3984a..4f061550274d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -723,6 +723,8 @@ struct kvm_vcpu_arch {
 	bool nmi_injected;    /* Trying to inject an NMI this entry */
 	bool smi_pending;    /* SMI queued after currently running handler */
 
+	bool callback_pending;	/* Callback queued after running handler */
+
 	struct kvm_mtrr mtrr_state;
 	u64 pat;
 
@@ -982,6 +984,10 @@ struct kvm_arch {
 
 	struct kvm_pmu_event_filter *pmu_event_filter;
 	struct task_struct *nx_lpage_recovery_thread;
+
+	struct {
+		u8 vector;
+	} callback;
 };
 
 struct kvm_vm_stat {
diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h
index 2a8e0b6b9805..bf016e232f2f 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -31,6 +31,7 @@
 #define KVM_FEATURE_PV_SEND_IPI	11
 #define KVM_FEATURE_POLL_CONTROL	12
 #define KVM_FEATURE_PV_SCHED_YIELD	13
+#define KVM_FEATURE_DYNAMIC_HINTS	14
 
 #define KVM_HINTS_REALTIME      0
 
@@ -50,6 +51,7 @@
 #define MSR_KVM_STEAL_TIME  0x4b564d03
 #define MSR_KVM_PV_EOI_EN      0x4b564d04
 #define MSR_KVM_POLL_CONTROL	0x4b564d05
+#define MSR_KVM_HINT_VECTOR	0x4b564d06
 
 struct kvm_steal_time {
 	__u64 steal;
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 901cd1fdecd9..db6a4c4d9430 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -712,7 +712,8 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
 			     (1 << KVM_FEATURE_ASYNC_PF_VMEXIT) |
 			     (1 << KVM_FEATURE_PV_SEND_IPI) |
 			     (1 << KVM_FEATURE_POLL_CONTROL) |
-			     (1 << KVM_FEATURE_PV_SCHED_YIELD);
+			     (1 << KVM_FEATURE_PV_SCHED_YIELD) |
+			     (1 << KVM_FEATURE_DYNAMIC_HINTS);
 
 		if (sched_info_on())
 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b8124b562dea..838d033bf5ba 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1282,6 +1282,7 @@ static const u32 emulated_msrs_all[] = {
 
 	MSR_K7_HWCR,
 	MSR_KVM_POLL_CONTROL,
+	MSR_KVM_HINT_VECTOR,
 };
 
 static u32 emulated_msrs[ARRAY_SIZE(emulated_msrs_all)];
@@ -2910,7 +2911,15 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
 
 		vcpu->arch.msr_kvm_poll_control = data;
 		break;
+	case MSR_KVM_HINT_VECTOR: {
+		u8 vector = (u8)data;
 
+		if ((u64)data > 0xffUL)
+			return 1;
+
+		vcpu->kvm->arch.callback.vector = vector;
+		break;
+	}
 	case MSR_IA32_MCG_CTL:
 	case MSR_IA32_MCG_STATUS:
 	case MSR_IA32_MC0_CTL ... MSR_IA32_MCx_CTL(KVM_MAX_MCE_BANKS) - 1:
@@ -3156,6 +3165,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
 	case MSR_KVM_POLL_CONTROL:
 		msr_info->data = vcpu->arch.msr_kvm_poll_control;
 		break;
+	case MSR_KVM_HINT_VECTOR:
+		msr_info->data = vcpu->kvm->arch.callback.vector;
+		break;
 	case MSR_IA32_P5_MC_ADDR:
 	case MSR_IA32_P5_MC_TYPE:
 	case MSR_IA32_MCG_CAP:
@@ -3373,6 +3385,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_GET_MSR_FEATURES:
 	case KVM_CAP_MSR_PLATFORM_INFO:
 	case KVM_CAP_EXCEPTION_PAYLOAD:
+	case KVM_CAP_CALLBACK:
 		r = 1;
 		break;
 	case KVM_CAP_SYNC_REGS:
@@ -3721,6 +3734,20 @@ static int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu,
 	return 0;
 }
 
+static int kvm_vcpu_ioctl_callback(struct kvm_vcpu *vcpu)
+{
+	/*
+	 * Has the guest setup a callback?
+	 */
+	if (vcpu->kvm->arch.callback.vector) {
+		vcpu->arch.callback_pending = true;
+		kvm_make_request(KVM_REQ_EVENT, vcpu);
+		return 0;
+	} else {
+		return -EINVAL;
+	}
+}
+
 static int kvm_vcpu_ioctl_nmi(struct kvm_vcpu *vcpu)
 {
 	kvm_inject_nmi(vcpu);
@@ -4611,6 +4638,10 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 		r = 0;
 		break;
 	}
+	case KVM_CALLBACK: {
+		r = kvm_vcpu_ioctl_callback(vcpu);
+		break;
+	}
 	default:
 		r = -EINVAL;
 	}
@@ -7737,6 +7768,14 @@ static int inject_pending_event(struct kvm_vcpu *vcpu)
 		--vcpu->arch.nmi_pending;
 		vcpu->arch.nmi_injected = true;
 		kvm_x86_ops.set_nmi(vcpu);
+	} else if (vcpu->arch.callback_pending) {
+		if (kvm_x86_ops.interrupt_allowed(vcpu)) {
+			vcpu->arch.callback_pending = false;
+			kvm_queue_interrupt(vcpu,
+					    vcpu->kvm->arch.callback.vector,
+					    false);
+			kvm_x86_ops.set_irq(vcpu);
+		}
 	} else if (kvm_cpu_has_injectable_intr(vcpu)) {
 		/*
 		 * Because interrupts can be injected asynchronously, we are
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 428c7dde6b4b..5401c056742c 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1017,6 +1017,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_S390_VCPU_RESETS 179
 #define KVM_CAP_S390_PROTECTED 180
 #define KVM_CAP_PPC_SECURE_GUEST 181
+#define KVM_CAP_CALLBACK	182
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1518,6 +1519,9 @@ struct kvm_pv_cmd {
 /* Available with KVM_CAP_S390_PROTECTED */
 #define KVM_S390_PV_COMMAND		_IOWR(KVMIO, 0xc5, struct kvm_pv_cmd)
 
+/* Available with  KVM_CAP_CALLBACK */
+#define KVM_CALLBACK		  _IO(KVMIO,  0xc6)
+
 /* Secure Encrypted Virtualization command */
 enum sev_cmd_id {
 	/* Guest initialization commands */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 05:20:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 05:20:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM38j-0006hM-Pw; Wed, 08 Apr 2020 05:20:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=UgfH=5Y=huawei.com=yanaijie@srs-us1.protection.inumbo.net>)
 id 1jM0ki-0007sQ-Gr
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 02:47:44 +0000
X-Inumbo-ID: 50d8264e-7943-11ea-81ab-12813bfff9fa
Received: from huawei.com (unknown [45.249.212.32])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 50d8264e-7943-11ea-81ab-12813bfff9fa;
 Wed, 08 Apr 2020 02:47:42 +0000 (UTC)
Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59])
 by Forcepoint Email with ESMTP id 80D4727C189A174B8870;
 Wed,  8 Apr 2020 10:47:40 +0800 (CST)
Received: from huawei.com (10.175.124.28) by DGGEMS406-HUB.china.huawei.com
 (10.3.19.206) with Microsoft SMTP Server id 14.3.487.0; Wed, 8 Apr 2020
 10:47:31 +0800
From: Jason Yan <yanaijie@huawei.com>
To: <boris.ostrovsky@oracle.com>, <jgross@suse.com>, <sstabellini@kernel.org>, 
 <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>, <hpa@zytor.com>, 
 <x86@kernel.org>, <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/xen: make xen_pvmmu_arch_setup() static
Date: Wed, 8 Apr 2020 10:46:05 +0800
Message-ID: <20200408024605.42394-1-yanaijie@huawei.com>
X-Mailer: git-send-email 2.17.2
MIME-Version: 1.0
Content-Type: text/plain
X-Originating-IP: [10.175.124.28]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Wed, 08 Apr 2020 05:20:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Jason Yan <yanaijie@huawei.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Fix the following sparse warning:

arch/x86/xen/setup.c:998:12: warning: symbol 'xen_pvmmu_arch_setup' was not
declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
---
 arch/x86/xen/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 33b0e20df7fc..1a2d8a50dac4 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -985,7 +985,7 @@ void xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_pvmmu_arch_setup(void)
+static void __init xen_pvmmu_arch_setup(void)
 {
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
-- 
2.17.2



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 06:15:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 06:15:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM3zH-0002W8-Se; Wed, 08 Apr 2020 06:14:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jM3zH-0002W3-67
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 06:14:59 +0000
X-Inumbo-ID: 427ab374-7960-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 427ab374-7960-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 06:14:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/v3ceeKZFgfPobd/V2eJ8zJt8j76psqZB10eO0vNYik=; b=QNSoKXoFR4jBScqGi+S69xY5S
 aMMtV49lHsmO5uhOT4bT8JJVsKZlU+iOcaE42Vpioqy8ugM/veQ5gmZzM3+KcIt6w81+2zIJi8Mfx
 089R97UKaL6ctMqHPMhgi9b7dA7VgnFQyNjDKyRxeBosrfBo++YMRcx+98oGHyE+Bk1A0=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM3zA-0004PU-Gg; Wed, 08 Apr 2020 06:14:52 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM3zA-0000pQ-6R; Wed, 08 Apr 2020 06:14:52 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jM3zA-0006ye-5s; Wed, 08 Apr 2020 06:14:52 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149508-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149508: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=24b7ac78173517b37bb2cf06b2bcac4305411f0a
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 06:14:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      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-armhf-armhf-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              24b7ac78173517b37bb2cf06b2bcac4305411f0a
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   82 days
Failing since        146211  2020-01-18 04:18:52 Z   81 days   78 attempts
Testing same since   149508  2020-04-08 04:19:29 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 13495 lines long.)


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 07:12:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 07:12:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM4sy-0007Qb-T9; Wed, 08 Apr 2020 07:12:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jM4sy-0007QW-3O
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 07:12:32 +0000
X-Inumbo-ID: 4cf2822a-7968-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4cf2822a-7968-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 07:12:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=gjL2vQSGS7iPJ0/fOUmRM9Ceo7XeBTlARZjmpuEXGew=; b=B2C9m3K6moO0xkvq+8KXS6Guo
 J6A+0ncLGBYX5igwPlzS173uqX24B2JurRwwBnKLfvImIu3SHimwuUFdQKxf89kpNv6E8eJVzACEU
 1E0IUypp8GWQuX3y2kZQUeaJ/9cPHsqv6wCIIyMhg9To7lEhL2avwb4VepUd4Qo8lvqmE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM4sr-0005VY-Uz; Wed, 08 Apr 2020 07:12:25 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM4sr-0003o3-Kf; Wed, 08 Apr 2020 07:12:25 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jM4sr-0002zF-Jx; Wed, 08 Apr 2020 07:12:25 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149504-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149504: all pass - PUSHED
X-Osstest-Versions-This: ovmf=3ab0dadd6618b7808a27e65d83aa3668462afcf2
X-Osstest-Versions-That: ovmf=9bb1f080c45f7253f9270662d55865a8718cebc8
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 07:12:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 3ab0dadd6618b7808a27e65d83aa3668462afcf2
baseline version:
 ovmf                 9bb1f080c45f7253f9270662d55865a8718cebc8

Last test of basis   149497  2020-04-07 19:10:25 Z    0 days
Testing same since   149504  2020-04-08 01:40:39 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Guomin Jiang <guomin.jiang@intel.com>
  GuoMinJ <newexplorerj@gmail.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   9bb1f080c4..3ab0dadd66  3ab0dadd6618b7808a27e65d83aa3668462afcf2 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 07:45:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 07:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM5Om-0001To-N3; Wed, 08 Apr 2020 07:45:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jM5Ol-0001Tj-RN
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 07:45:23 +0000
X-Inumbo-ID: e5af1952-796c-11ea-81c0-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e5af1952-796c-11ea-81c0-12813bfff9fa;
 Wed, 08 Apr 2020 07:45:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3424DABEC;
 Wed,  8 Apr 2020 07:45:19 +0000 (UTC)
Subject: Re: [PATCH] MAINTAINERS: Remove all S: entries
To: Ian Jackson <ian.jackson@eu.citrix.com>
References: <20200407161519.16493-1-ian.jackson@eu.citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <5eea22b1-878e-7529-3442-f2ff9517be8c@suse.com>
Date: Wed, 8 Apr 2020 09:45:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200407161519.16493-1-ian.jackson@eu.citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 18:15, Ian Jackson wrote:
> Feature support status is tracked in SUPPORT.md nowadays.

It is, yes.

> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -69,16 +69,6 @@ Descriptions of section entries:
>  	L: Mailing list that is relevant to this area
>  	W: Web-page with status/info
>  	T: SCM tree type and location.  Type is one of: git, hg, quilt, stgit.
> -	S: Status, one of the following:
> -	   Supported:	Someone is actually paid to look after this.
> -	   Maintained:	Someone actually looks after it.
> -	   Odd Fixes:	It has a maintainer but they don't have time to do
> -			much other than throw the odd patch in. See below..
> -	   Orphan:	No current maintainer [but maybe you could take the
> -			role as you write your new code].
> -	   Obsolete:	Old code. Something tagged obsolete generally means
> -			it has been replaced by a better system and you
> -			should be using that.

I agree with Julien: What we express here is not really overlapping
with SUPPORT.md - the may be cases where this is so, but there are
also ones where it's not.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 08:01:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 08:01:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM5dp-0003bQ-Av; Wed, 08 Apr 2020 08:00:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jM5do-0003bL-3E
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 08:00:56 +0000
X-Inumbo-ID: 12047fea-796f-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 12047fea-796f-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 08:00:54 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9D864AD2C;
 Wed,  8 Apr 2020 08:00:52 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86/EFI: also fill boot_tsc_stamp on the xen.efi boot path
Message-ID: <7ed6f7cc-c540-88fb-6073-10ef1a2da6e7@suse.com>
Date: Wed, 8 Apr 2020 10:00:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit e3a379c35eff ("x86/time: always count s_time from Xen boot")
introducing this missed adjusting this path as well.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -8,6 +8,7 @@
 #include <asm/edd.h>
 #include <asm/microcode.h>
 #include <asm/msr.h>
+#include <asm/setup.h>
 
 static struct file __initdata ucode;
 static multiboot_info_t __initdata mbi = {
@@ -673,6 +674,8 @@ static void __init efi_arch_cpu(void)
     uint32_t eax = cpuid_eax(0x80000000);
     uint32_t *caps = boot_cpu_data.x86_capability;
 
+    boot_tsc_stamp = rdtsc();
+
     caps[cpufeat_word(X86_FEATURE_HYPERVISOR)] = cpuid_ecx(1);
 
     if ( (eax >> 16) == 0x8000 && eax > 0x80000000 )
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -10,6 +10,7 @@ extern char __2M_init_start[], __2M_init
 extern char __2M_rwdata_start[], __2M_rwdata_end[];
 
 extern unsigned long xenheap_initial_phys_start;
+extern uint64_t boot_tsc_stamp;
 
 void early_cpu_init(void);
 void early_time_init(void);


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 08:40:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 08:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM6Fm-0006rN-PL; Wed, 08 Apr 2020 08:40:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=M0gu=5Y=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jM6Fl-0006rI-Qv
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 08:40:09 +0000
X-Inumbo-ID: 8d8e0c12-7974-11ea-b58d-bc764e2007e4
Received: from mail-wm1-x330.google.com (unknown [2a00:1450:4864:20::330])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8d8e0c12-7974-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 08:40:09 +0000 (UTC)
Received: by mail-wm1-x330.google.com with SMTP id h2so4262808wmb.4
 for <xen-devel@lists.xenproject.org>; Wed, 08 Apr 2020 01:40:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=+qE9XoupkITSIvgnncMclC0UqTdwG7DHScX5XnqacAE=;
 b=cyF12knWEDym9wgKgtzie97jiX8UUDFQn8uHVYrtPUvsYx7YXKJbwmZiU2LjcO2dJ9
 pwBfwHvP6bpCqYMrHRB7in8eBFA56RmDffeHXaSJb/RaZjjOq2kM28xWYtaKomLCX79I
 5ZFB6S6SJTCz/Zf2tFkU1Mrwfvc8CtQ0PGOR/heBVF3nARUXrzgTu0k1RloQ6lOVy16P
 MppIi9PuKgHk6w5aMPqjCVTvRpqLGrofT5djnSROCbSw3ALEvY/iwu0YBOfpRbNmUvKl
 kZaxczAVEISy1fVU4mAKLHuCBds9uBIBcfsbWD+EKPBig4cX3FOWaZt3vGQVEx/dT2ua
 FCOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=+qE9XoupkITSIvgnncMclC0UqTdwG7DHScX5XnqacAE=;
 b=jI6Xlho4ynD39s4PFJmM3dCori/EGyrgEuipnwa88bJ6lGmJOprK7xgVxFMDZlo9l6
 8gxcLgnpcwxLqx2aSYDScXio14UnGpd+/23SPmtzDSi5yqqJ1TIf5hZ5qE+onF4HoqyD
 OcBTxGSp8QFBszyA3Rj7p0sP+TCfbZny/X+FumP2tABeO/QsZUtiR4v82eakyDFsBclx
 wvxsdhfANm7Rh1MarIz5ZBAYD8zifzMrx87GZ3ukp54oPDHXv7RBSD9bQHHK66mtvMXq
 gyVsJcAsNjNKDdJBa6rHvtkQ61k4fAqCPPVtrCtjZ43qpbAM24EXwQLhOWq2fGL/TckH
 b5Ig==
X-Gm-Message-State: AGi0PubfPX1TDEczgXtWPM25ygNHQv8g1zqSzW7J915NKPBCXR/wyLl+
 s8tcm9R+q0lQlxWKMKgN05w=
X-Google-Smtp-Source: APiQypKBnZx9SX7tcr7LXwcBq4Lfo7QxCE52mSRmfX+GHxwqW/ShhJVMyPtdLyFjxvdBiBkXAjrXhA==
X-Received: by 2002:a1c:5605:: with SMTP id k5mr3695219wmb.83.1586335208070;
 Wed, 08 Apr 2020 01:40:08 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.190])
 by smtp.gmail.com with ESMTPSA id f4sm17483044wrp.80.2020.04.08.01.40.06
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 08 Apr 2020 01:40:07 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Maximilian Heyne'" <mheyne@amazon.de>, <xen-devel@lists.xenproject.org>
References: <20200313123316.122003-1-mheyne@amazon.de>
 <6f476505-5e85-8a8a-d6d7-db56ea921637@amazon.de>
In-Reply-To: <6f476505-5e85-8a8a-d6d7-db56ea921637@amazon.de>
Subject: RE: [PATCH 0/3] Cleanup IOREQ server on exit
Date: Wed, 8 Apr 2020 09:40:06 +0100
Message-ID: <004601d60d81$4e7c4e80$eb74eb80$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQGvBAjA7hxOW9V3ZNauiodGQFqJFQEiCWftqLPpwbA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Ian Jackson' <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Maximilian Heyne <mheyne@amazon.de>
> Sent: 07 April 2020 10:16
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson <ian.jackson@citrix.com>; Paul Durrant <paul@xen.org>
> Subject: Re: [PATCH 0/3] Cleanup IOREQ server on exit
> 
> Could someone please have a look at this patch? It solves an actual issue:
> Try soft-reset with qemu-xen-traditional and it will fail.
> 

I'll take a look today.

Ian, obviously we know that qemu trad is largely dead but this series does address a serious shortcoming. Could you take a look?

  Paul



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 08:44:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 08:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM6Jt-00070n-BS; Wed, 08 Apr 2020 08:44:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=D8Jc=5Y=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jM6Jr-00070h-LF
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 08:44:23 +0000
X-Inumbo-ID: 24b41c3a-7975-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 24b41c3a-7975-11ea-9e09-bc764e2007e4;
 Wed, 08 Apr 2020 08:44:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C6413AFCA;
 Wed,  8 Apr 2020 08:44:19 +0000 (UTC)
Subject: Re: [PATCH] x86/xen: make xen_pvmmu_arch_setup() static
To: Jason Yan <yanaijie@huawei.com>, boris.ostrovsky@oracle.com,
 sstabellini@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
 hpa@zytor.com, x86@kernel.org, xen-devel@lists.xenproject.org
References: <20200408024605.42394-1-yanaijie@huawei.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <4a950af3-5e8f-ef8b-0fa8-3289589797d0@suse.com>
Date: Wed, 8 Apr 2020 10:44:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200408024605.42394-1-yanaijie@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.20 04:46, Jason Yan wrote:
> Fix the following sparse warning:
> 
> arch/x86/xen/setup.c:998:12: warning: symbol 'xen_pvmmu_arch_setup' was not
> declared. Should it be static?
> 
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 09:33:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 09:33:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM74f-0002d3-Dk; Wed, 08 Apr 2020 09:32:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+IwF=5Y=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jM74e-0002cy-DR
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 09:32:44 +0000
X-Inumbo-ID: e5553a91-797b-11ea-81c8-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e5553a91-797b-11ea-81c8-12813bfff9fa;
 Wed, 08 Apr 2020 09:32:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=x+4HWmtllqDCRx1xPuUnILUMTVv4l5Lmhf8TpyvyUk8=; b=4+EJJtiXcl3w73LbqwI6cGQmmx
 jlDUXdD1Vo5FhaPiIUce6eZUnSxRxeI9gFQHC9HIdaDdW7wLvO7hdrzI+PYGmAVlmFfFehYR4dg1s
 7cCridNj7ZHauS7yiAQ92PomfblsPFzmH+czBRJt0oml1hv8J+R4euvImzy+aps0vD2g=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jM74b-0000Ep-Cm; Wed, 08 Apr 2020 09:32:41 +0000
Received: from 54-240-197-230.amazon.com ([54.240.197.230]
 helo=freeip.amazon.com) by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jM74b-0006Jp-2D; Wed, 08 Apr 2020 09:32:41 +0000
Message-ID: <e4f62e4ce7aba9c4b64437864859181f67e07d3d.camel@xen.org>
Subject: Re: [PATCH 3/5] x86_64/mm: map and unmap page tables in
 share_hotadd_m2p_table
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Date: Wed, 08 Apr 2020 10:32:39 +0100
In-Reply-To: <f1537005-cac8-cd74-e19c-043219ccab56@suse.com>
References: <cover.1584955616.git.hongyxia@amazon.com>
 <2fa83ef5818805c179757caac99ccf7ab4f7ba3a.1584955616.git.hongyxia@amazon.com>
 <f1537005-cac8-cd74-e19c-043219ccab56@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 2020-04-01 at 14:29 +0200, Jan Beulich wrote:
> On 23.03.2020 10:41, Hongyan Xia wrote:
> > --- a/xen/include/asm-x86/page.h
> > +++ b/xen/include/asm-x86/page.h
> > @@ -196,6 +196,24 @@ static inline l4_pgentry_t
> > l4e_from_paddr(paddr_t pa, unsigned int flags)
> >  #define map_l2t_from_l3e(x)        (l2_pgentry_t
> > *)map_domain_page(l3e_get_mfn(x))
> >  #define map_l3t_from_l4e(x)        (l3_pgentry_t
> > *)map_domain_page(l4e_get_mfn(x))
> >  
> > +#define l1e_from_l2e(l2e, off) ({                   \
> > +        l1_pgentry_t *l1t = map_l1t_from_l2e(l2e);  \
> > +        l1_pgentry_t l1e = l1t[off];                \
> > +        UNMAP_DOMAIN_PAGE(l1t);                     \
> > +        l1e; })
> > +
> > +#define l2e_from_l3e(l3e, off) ({                   \
> > +        l2_pgentry_t *l2t = map_l2t_from_l3e(l3e);  \
> > +        l2_pgentry_t l2e = l2t[off];                \
> > +        UNMAP_DOMAIN_PAGE(l2t);                     \
> > +        l2e; })
> > +
> > +#define l3e_from_l4e(l4e, off) ({                   \
> > +        l3_pgentry_t *l3t = map_l3t_from_l4e(l4e);  \
> > +        l3_pgentry_t l3e = l3t[off];                \
> > +        UNMAP_DOMAIN_PAGE(l3t);                     \
> > +        l3e; })
> 
> There's a reason these are macros rather than inline functions,
> I assume? (This reason would be nice to be stated in the
> description.)

While converting them into inline functions, I realised I cannot do
that due to the header mess. Converting into inline functions needs the
domain_page.h header, which opens a can of worms if I include it here
(page.h). Keeping them as macros works around this issue.

I will add this in the description.

Hongyan



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 09:47:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 09:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM7Il-0003ZO-Q4; Wed, 08 Apr 2020 09:47:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Cg4/=5Y=bitdefender.com=aisaila@srs-us1.protection.inumbo.net>)
 id 1jM7Ij-0003ZJ-VW
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 09:47:18 +0000
X-Inumbo-ID: ed8a68e6-797d-11ea-b4f4-bc764e2007e4
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown
 [40.107.8.134]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ed8a68e6-797d-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 09:47:15 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=PuxM8ygOJ2VMbeHzXveIbdLzPmB6JqsM9KVsyDtvVwVtVj4QRKhoxk8X0ZIOjF+NHvXqPTCqg/XAf1+QuyhrpjnjNw8/cHpRnqOMtfpEBuzr5nolGJbXXi2fAkJQaCrjQX/YDYaDW9AWPjZlfp84jIKbY2JW+4ASPls1ID6gNHf4b+bgvdNUQb5uC/nevVwYupH9tqzZxEmF0vBAsXrfB7IvC514NDguJbpoYUjQ7BxcsTsCyj4v0DVOKfRetE7JtaPKMcLRqFroOAOu5LskHvPbUjFnvG2CEBXHeX5AlKa8vR1mTnKNH5gq8FTtnkt1xpdcmDYtG/LRXtPUkNuW6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=B5qvTFxkwcg/ENk0gdVb/Vv3benjWxZKfzMcCu4dYso=;
 b=Fp6BJMNx5aCE2z1+XQJhYFf0kV3S3WHR375axAgJp0uaWZEtYn4V197Kaoyjous6qxT4vkgzuo51nAgodFrLNzjXHMwNGlUx42QezGhDAxsu0m1xwXIO6dHimFUOAQt7ViP9/syHiqESKEWnN/ANgGzB8sSGup+1qLietPnW/8KC9rfzZ/lP4JomHUvdh2fTZqrWNOceb9sQLhbeq+hstLFlvV6XdGtkuuCvTaBY7MD6SJu27KBpXNiMW0SEU3KvshTvAaxPg+z0MNHw9WVQtRv6kZTaZYVeGg+htEXYF2raaErqPMLz2MSwveOmMTVE+4NE4fLmRRGBw1XP+WDmag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=bitdefender.com; dmarc=pass action=none
 header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=B5qvTFxkwcg/ENk0gdVb/Vv3benjWxZKfzMcCu4dYso=;
 b=wn6tDsPqukUJ1DxNBcsKZmc32CMKPBmLAyRI2fRm2SYSOvPzt7a/CIuA2wy6FaIGAnIh2rlo4yZjqvVhxkfvl504GUaA12zyMhjXVF1AJlzCs7N9cgQSd56qoTTcEq+DmGwibXr/zMmmgSYpeSE3qsDNjNuDmAEJ1YAFWRXn4Zo=
Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=aisaila@bitdefender.com; 
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com (2603:10a6:20b:86::23)
 by AM6PR02MB4802.eurprd02.prod.outlook.com (2603:10a6:20b:32::31)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Wed, 8 Apr
 2020 09:47:13 +0000
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::4101:6057:7eb0:e005]) by AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::4101:6057:7eb0:e005%7]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020
 09:47:13 +0000
Subject: Ping: [PATCH V7] x86/altp2m: Hypercall to set altp2m view visibility
To: xen-devel@lists.xenproject.org, Kevin Tian <kevin.tian@intel.com>
References: <20200330065434.5952-1-aisaila@bitdefender.com>
From: Isaila Alexandru <aisaila@bitdefender.com>
Organization: BD
Message-ID: <b4b2d0cd-8e4b-713a-ce4c-048c6896d95e@bitdefender.com>
Date: Wed, 8 Apr 2020 12:47:11 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
In-Reply-To: <20200330065434.5952-1-aisaila@bitdefender.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: VE1PR03CA0017.eurprd03.prod.outlook.com
 (2603:10a6:802:a0::29) To AM6PR02MB5223.eurprd02.prod.outlook.com
 (2603:10a6:20b:86::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.0.105] (82.77.232.39) by
 VE1PR03CA0017.eurprd03.prod.outlook.com (2603:10a6:802:a0::29) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2900.15 via Frontend Transport; Wed, 8 Apr 2020 09:47:12 +0000
X-Originating-IP: [82.77.232.39]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c7adb68f-d42e-4824-62bf-08d7dba1d0a0
X-MS-TrafficTypeDiagnostic: AM6PR02MB4802:|AM6PR02MB4802:
X-Microsoft-Antispam-PRVS: <AM6PR02MB4802245ED6DA5C45630495DCABC00@AM6PR02MB4802.eurprd02.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:422;
X-Forefront-PRVS: 0367A50BB1
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:AM6PR02MB5223.eurprd02.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10019020)(136003)(376002)(346002)(396003)(39850400004)(366004)(4326008)(2906002)(66476007)(30864003)(66946007)(186003)(2616005)(956004)(5660300002)(16526019)(7416002)(36756003)(26005)(31696002)(53546011)(54906003)(6916009)(478600001)(316002)(86362001)(31686004)(66556008)(16576012)(8936002)(81166007)(36916002)(81156014)(8676002)(52116002)(6486002);
 DIR:OUT; SFP:1102; 
Received-SPF: None (protection.outlook.com: bitdefender.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 9IBonMD+9aBX8z2BbjLtM53TLhs9arrzKQPc05vOBReXWD0WQXBN7L3BfzAwjRZP5admikHMkM3oY7eBjNFKGSLfbO754crEzcdO8YZ5SvhoFD63EBgunuaRf5W4nLcd2n+0rpDz5yKgsxGUB3kDgLkPsocGZEAaty+bJk0wY5oncakN48KqwlnmcV+yruaqEKLLapnlCKX1yDHkFzRHlsQ7y9rPKkhG/omB+YaaQSPJ0JTDO87TKnvlxh7WHm+p7aosPUQ7DMRCtzWn9VPY+YLEPDWujXYophWNBIwhdoKNoezDIfFTVEMV8XYmnDXdH1ustNZ2E0FwzL4jEYb21dtOObM4W+e1KYLNXodf6g1VkUAmi4Gb1XdMtPU00mFRojh4WfpMFThIEzMVH4khiZ1FLYMHR1n3VrBo0UaBdWvVdcdqpuFf6QAgSoJH+SgI
X-MS-Exchange-AntiSpam-MessageData: WTPHTDBVJVNfrjL0iedzX6GJLJ2LtOV4rlWrXaic97tBau0QJDUI5XuA8j7820kaH0rn3Yamn5kfNOvoeVE6g/5rrgPr5Q2Xt7M7fzTJ2C0tVO3iSkqmR2TZdrN2dgC5vvMiBTIxqgscr6kkrPrYkA==
X-MS-Exchange-Transport-Forked: True
X-OriginatorOrg: bitdefender.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c7adb68f-d42e-4824-62bf-08d7dba1d0a0
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2020 09:47:13.3973 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: VLMshRC62CPkIOGcBVXDyF10Of3QPmtczu2cJPujCIDxPOS7y6g/Z87ZWiNOBE5X8Ecq4QhzY4SAX4R8JIeq0fXA/kzllohE2zAwVl+KqOc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR02MB4802
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
 George Dunlap <George.Dunlap@eu.citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Kevin,

This is a kind reminder if you can have another look at the new version 
of this patch.

Thanks,
Alex

On 30.03.2020 09:54, Alexandru Isaila wrote:
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
> 
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
> This is done by having a separate arch.altp2m_working_eptp that is
> populated and made invalid in the same places as altp2m_eptp. This is
> written to EPTP_LIST_ADDR.
> The views are made in/visible by marking them with INVALID_MFN or
> copying them back from altp2m_eptp.
> To have consistency the visibility also applies to
> p2m_switch_domain_altp2m_by_id().
> 
> The usage of this hypercall is aimed at dom0 having a logic with a number of views
> created and at some time there is a need to be sure that only some of the views
> can be switched, saving the rest and making them visible when the time
> is right.
> 
> Note: If altp2m mode is set to mixed the guest is able to change the view
> visibility and then call vmfunc.
> 
> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
> ---
> CC: Ian Jackson <ian.jackson@eu.citrix.com>
> CC: Wei Liu <wl@xen.org>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: George Dunlap <George.Dunlap@eu.citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: "Roger Pau Monné" <roger.pau@citrix.com>
> CC: Jun Nakajima <jun.nakajima@intel.com>
> CC: Kevin Tian <kevin.tian@intel.com>
> ---
> Changes since V6:
> 	- Update commit message.
> 
> Changes since V5:
> 	- Change idx type from uint16_t to unsigned int
> 	- Add rc var and dropped the err return from p2m_get_suppress_ve().
> 
> Changes since V4:
> 	- Move p2m specific things from hvm to p2m.c
> 	- Add comment for altp2m_idx bounds check
> 	- Add altp2m_list_lock/unlock().
> 
> Changes since V3:
> 	- Change var name form altp2m_idx to idx to shorten line length
> 	- Add bounds check for idx
> 	- Update commit message
> 	- Add comment in xenctrl.h.
> 
> Changes since V2:
> 	- Drop hap_enabled() check
> 	- Reduce the indentation depth in hvm.c
> 	- Fix assignment indentation
> 	- Drop pad2.
> 
> Changes since V1:
> 	- Drop double view from title.
> ---
>   tools/libxc/include/xenctrl.h   |  7 +++++++
>   tools/libxc/xc_altp2m.c         | 24 +++++++++++++++++++++++
>   xen/arch/x86/hvm/hvm.c          | 14 ++++++++++++++
>   xen/arch/x86/hvm/vmx/vmx.c      |  2 +-
>   xen/arch/x86/mm/hap/hap.c       | 15 +++++++++++++++
>   xen/arch/x86/mm/p2m-ept.c       |  1 +
>   xen/arch/x86/mm/p2m.c           | 34 +++++++++++++++++++++++++++++++--
>   xen/include/asm-x86/domain.h    |  1 +
>   xen/include/asm-x86/p2m.h       |  4 ++++
>   xen/include/public/hvm/hvm_op.h |  9 +++++++++
>   10 files changed, 108 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index fc6e57a1a0..2e6e652678 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1943,6 +1943,13 @@ int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
>                            xen_pfn_t new_gfn);
>   int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
>                                  uint32_t vcpuid, uint16_t *p2midx);
> +/*
> + * Set view visibility for xc_altp2m_switch_to_view and vmfunc.
> + * Note: If altp2m mode is set to mixed the guest is able to change the view
> + * visibility and then call vmfunc.
> + */
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> +                             uint16_t view_id, bool visible);
>   
>   /**
>    * Mem paging operations.
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 46fb725806..6987c9541f 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -410,3 +410,27 @@ int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
>       xc_hypercall_buffer_free(handle, arg);
>       return rc;
>   }
> +
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> +                             uint16_t view_id, bool visible)
> +{
> +    int rc;
> +
> +    DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +    arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +    if ( arg == NULL )
> +        return -1;
> +
> +    arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +    arg->cmd = HVMOP_altp2m_set_visibility;
> +    arg->domain = domid;
> +    arg->u.set_visibility.altp2m_idx = view_id;
> +    arg->u.set_visibility.visible = visible;
> +
> +    rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> +                  HYPERCALL_BUFFER_AS_ARG(arg));
> +
> +    xc_hypercall_buffer_free(handle, arg);
> +    return rc;
> +}
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index a3d115b650..375e9cf368 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4511,6 +4511,7 @@ static int do_altp2m_op(
>       case HVMOP_altp2m_get_mem_access:
>       case HVMOP_altp2m_change_gfn:
>       case HVMOP_altp2m_get_p2m_idx:
> +    case HVMOP_altp2m_set_visibility:
>           break;
>   
>       default:
> @@ -4788,6 +4789,19 @@ static int do_altp2m_op(
>           break;
>       }
>   
> +    case HVMOP_altp2m_set_visibility:
> +    {
> +        unsigned int idx = a.u.set_visibility.altp2m_idx;
> +
> +        if ( a.u.set_visibility.pad )
> +            rc = -EINVAL;
> +        else if ( !altp2m_active(d) )
> +            rc = -EOPNOTSUPP;
> +        else
> +            rc = p2m_set_altp2m_view_visibility(d, idx,
> +                                                a.u.set_visibility.visible);
> +    }
> +
>       default:
>           ASSERT_UNREACHABLE();
>       }
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index d265ed46ad..bb44ef39a1 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2140,7 +2140,7 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
>       {
>           v->arch.hvm.vmx.secondary_exec_control |= mask;
>           __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
> -        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
> +        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_working_eptp));
>   
>           if ( cpu_has_vmx_virt_exceptions )
>           {
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index a6d5e39b02..372c84da9b 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -493,8 +493,17 @@ int hap_enable(struct domain *d, u32 mode)
>               goto out;
>           }
>   
> +        if ( (d->arch.altp2m_working_eptp = alloc_xenheap_page()) == NULL )
> +        {
> +            rv = -ENOMEM;
> +            goto out;
> +        }
> +
>           for ( i = 0; i < MAX_EPTP; i++ )
> +        {
>               d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +            d->arch.altp2m_working_eptp[i] = mfn_x(INVALID_MFN);
> +        }
>   
>           for ( i = 0; i < MAX_ALTP2M; i++ )
>           {
> @@ -528,6 +537,12 @@ void hap_final_teardown(struct domain *d)
>               d->arch.altp2m_eptp = NULL;
>           }
>   
> +        if ( d->arch.altp2m_working_eptp )
> +        {
> +            free_xenheap_page(d->arch.altp2m_working_eptp);
> +            d->arch.altp2m_working_eptp = NULL;
> +        }
> +
>           for ( i = 0; i < MAX_ALTP2M; i++ )
>               p2m_teardown(d->arch.altp2m_p2m[i]);
>       }
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index eb0f0edfef..6539ca619b 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1368,6 +1368,7 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>       ept = &p2m->ept;
>       ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
>       d->arch.altp2m_eptp[array_index_nospec(i, MAX_EPTP)] = ept->eptp;
> +    d->arch.altp2m_working_eptp[array_index_nospec(i, MAX_EPTP)] = ept->eptp;
>   }
>   
>   unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp)
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index d93c418bcf..0526bff5b2 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2515,6 +2515,7 @@ void p2m_flush_altp2m(struct domain *d)
>       {
>           p2m_reset_altp2m(d, i, ALTP2M_DEACTIVATE);
>           d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +        d->arch.altp2m_working_eptp[i] = mfn_x(INVALID_MFN);
>       }
>   
>       altp2m_list_unlock(d);
> @@ -2634,7 +2635,9 @@ int p2m_destroy_altp2m_by_id(struct domain *d, unsigned int idx)
>           {
>               p2m_reset_altp2m(d, idx, ALTP2M_DEACTIVATE);
>               d->arch.altp2m_eptp[array_index_nospec(idx, MAX_EPTP)] =
> -            mfn_x(INVALID_MFN);
> +                mfn_x(INVALID_MFN);
> +            d->arch.altp2m_working_eptp[array_index_nospec(idx, MAX_EPTP)] =
> +                mfn_x(INVALID_MFN);
>               rc = 0;
>           }
>       }
> @@ -2661,7 +2664,7 @@ int p2m_switch_domain_altp2m_by_id(struct domain *d, unsigned int idx)
>       rc = -EINVAL;
>       altp2m_list_lock(d);
>   
> -    if ( d->arch.altp2m_eptp[idx] != mfn_x(INVALID_MFN) )
> +    if ( d->arch.altp2m_working_eptp[idx] != mfn_x(INVALID_MFN) )
>       {
>           for_each_vcpu( d, v )
>               if ( idx != vcpu_altp2m(v).p2midx )
> @@ -3145,6 +3148,33 @@ int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, bool *suppress_ve,
>   
>       return rc;
>   }
> +
> +int p2m_set_altp2m_view_visibility(struct domain *d, unsigned int altp2m_idx,
> +                                   uint8_t visible)
> +{
> +    int rc = 0;
> +
> +    altp2m_list_lock(d);
> +
> +    /*
> +     * Eptp index is correlated with altp2m index and should not exceed
> +     * min(MAX_ALTP2M, MAX_EPTP).
> +     */
> +    if ( altp2m_idx >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) ||
> +         d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] ==
> +         mfn_x(INVALID_MFN) )
> +        rc = -EINVAL;
> +    else if ( visible )
> +        d->arch.altp2m_working_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] =
> +            d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)];
> +    else
> +        d->arch.altp2m_working_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] =
> +            mfn_x(INVALID_MFN);
> +
> +    altp2m_list_unlock(d);
> +
> +    return rc;
> +}
>   #endif
>   
>   /*
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 105adf96eb..800e12eae5 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -327,6 +327,7 @@ struct arch_domain
>       struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
>       mm_lock_t altp2m_list_lock;
>       uint64_t *altp2m_eptp;
> +    uint64_t *altp2m_working_eptp;
>   #endif
>   
>       /* NB. protected by d->event_lock and by irq_desc[irq].lock */
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index a2c6049834..ace3573ae8 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -898,6 +898,10 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int idx,
>   int p2m_altp2m_propagate_change(struct domain *d, gfn_t gfn,
>                                   mfn_t mfn, unsigned int page_order,
>                                   p2m_type_t p2mt, p2m_access_t p2ma);
> +
> +/* Set a specific p2m view visibility */
> +int p2m_set_altp2m_view_visibility(struct domain *d, unsigned int idx,
> +                                   uint8_t visible);
>   #else
>   struct p2m_domain *p2m_get_altp2m(struct vcpu *v);
>   static inline void p2m_altp2m_check(struct vcpu *v, uint16_t idx) {}
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index b599d3cbd0..870ec52060 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -318,6 +318,12 @@ struct xen_hvm_altp2m_get_vcpu_p2m_idx {
>       uint16_t altp2m_idx;
>   };
>   
> +struct xen_hvm_altp2m_set_visibility {
> +    uint16_t altp2m_idx;
> +    uint8_t visible;
> +    uint8_t pad;
> +};
> +
>   struct xen_hvm_altp2m_op {
>       uint32_t version;   /* HVMOP_ALTP2M_INTERFACE_VERSION */
>       uint32_t cmd;
> @@ -350,6 +356,8 @@ struct xen_hvm_altp2m_op {
>   #define HVMOP_altp2m_get_p2m_idx          14
>   /* Set the "Supress #VE" bit for a range of pages */
>   #define HVMOP_altp2m_set_suppress_ve_multi 15
> +/* Set visibility for a given altp2m view */
> +#define HVMOP_altp2m_set_visibility       16
>       domid_t domain;
>       uint16_t pad1;
>       uint32_t pad2;
> @@ -367,6 +375,7 @@ struct xen_hvm_altp2m_op {
>           struct xen_hvm_altp2m_suppress_ve_multi    suppress_ve_multi;
>           struct xen_hvm_altp2m_vcpu_disable_notify  disable_notify;
>           struct xen_hvm_altp2m_get_vcpu_p2m_idx     get_vcpu_p2m_idx;
> +        struct xen_hvm_altp2m_set_visibility       set_visibility;
>           uint8_t pad[64];
>       } u;
>   };
> 


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 10:34:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 10:34:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM81q-0007ds-22; Wed, 08 Apr 2020 10:33:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jM81o-0007dj-DC
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 10:33:52 +0000
X-Inumbo-ID: 6cc9ffbc-7984-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6cc9ffbc-7984-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 10:33:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tGKjBT7AovFKycAPP2gUz1xCJBfTE5jIC3WxmO/ESMo=; b=hUI9qgdvsdcvNEaQxGJRBIyOz
 e0+OlRp3mfpJmrYzN27ebJh78fT97vjSqdheEXXoNkEgYPXY3KTM+7Rqfr7YdRzyJHR0MaSrJN/Rk
 bcnCGJUfMUySbGDOdZw+ck+KpLwBIIOiqY840cNN8iYhXAmgcV69bIuCdwyQvtygabgdg=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM81h-0001Tc-Cs; Wed, 08 Apr 2020 10:33:45 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM81h-0005Uw-5U; Wed, 08 Apr 2020 10:33:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jM81h-0007jc-4t; Wed, 08 Apr 2020 10:33:45 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149502-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149502: regressions - FAIL
X-Osstest-Failures: xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=e013e8514389b739153016349e49f5a78e34ddf0
X-Osstest-Versions-That: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 10:33:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149431
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149478
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149478
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149478
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149478
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149478
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149478
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149478
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149478
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149478
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  e013e8514389b739153016349e49f5a78e34ddf0
baseline version:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd

Last test of basis   149478  2020-04-07 01:51:22 Z    1 days
Testing same since   149502  2020-04-08 00:06:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Juergen Gross <jgross@suse.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        fail    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit e013e8514389b739153016349e49f5a78e34ddf0
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Apr 7 15:48:31 2020 +0200

    config: use mini-os master for unstable
    
    We haven't used mini-os master for about 2 years now due to a stubdom
    test failing [1]. Booting a guest with mini-os master used for building
    stubdom didn't reveal any problem, so use master for unstable in order
    to let OSStest find any problems not showing up in the local test.
    
    [1]: https://lists.xen.org/archives/html/minios-devel/2018-04/msg00015.html
    
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Acked-by: Wei Liu <wl@xen.org>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:05:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM8WE-0001iB-Kf; Wed, 08 Apr 2020 11:05:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LAz7=5Y=infradead.org=peterz@srs-us1.protection.inumbo.net>)
 id 1jM8WE-0001i6-0I
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:05:18 +0000
X-Inumbo-ID: ce01660e-7988-11ea-b58d-bc764e2007e4
Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ce01660e-7988-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 11:05:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version
 :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-Transfer-Encoding:Content-ID:Content-Description;
 bh=oqUjbefYS3Yk7lY8aXBkaPJgSKoP23s64kxD/fHCpR8=; b=ugEMl3nwCKlvAWACI3gmebiipt
 8/1xS63dnZ7clRpRx+bkMlxjyy8k+YsGj2MI+19jCGbSbjP9/Mh5p/Sq4Ns9IBZ0gRBma6VKHMr/o
 XEW41GFTJDDlVx/mihtetBghKO/Pe9haIl5N9JxwKET5XHndOUhNK/ybyUXpJEQJAjk2gFBFkRJZB
 +02sNenIRFkYFGQEGXc6iwLxT+UnA4UTLIsWcXvI4Ai5zcYW6wgFbgT0qxY+3I8cqsnpMr251t/ZG
 vDz6HI4/lhpMzkmvbNWol4H34lr5aKfXny5PMY1OzXL/BXXZbLP430nCgbEc5TvjOztIXWIfYYJ1u
 pLlISIDg==;
Received: from j217100.upc-j.chello.nl ([24.132.217.100]
 helo=noisy.programming.kicks-ass.net)
 by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux))
 id 1jM8W0-0007ea-8z; Wed, 08 Apr 2020 11:05:04 +0000
Received: from hirez.programming.kicks-ass.net
 (hirez.programming.kicks-ass.net [192.168.1.225])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 9ACC7300130;
 Wed,  8 Apr 2020 13:05:01 +0200 (CEST)
Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000)
 id 8BE212BA90A60; Wed,  8 Apr 2020 13:05:01 +0200 (CEST)
Date: Wed, 8 Apr 2020 13:05:01 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Ankur Arora <ankur.a.arora@oracle.com>
Subject: Re: [RFC PATCH 09/26] x86/paravirt: Add runtime_patch()
Message-ID: <20200408110501.GS20713@hirez.programming.kicks-ass.net>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <20200408050323.4237-10-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200408050323.4237-10-ankur.a.arora@oracle.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, hpa@zytor.com, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 10:03:06PM -0700, Ankur Arora wrote:
> +/*
> + * preempt_enable_no_resched() so we don't add any preemption points until
> + * after the caller has returned.
> + */
> +#define preempt_enable_runtime_patch()	preempt_enable_no_resched()
> +#define preempt_disable_runtime_patch()	preempt_disable()

NAK, this is probably a stright preemption bug, also, afaict, there
aren't actually any users of this in the patch-set.


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:11:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM8cD-0002YI-Eh; Wed, 08 Apr 2020 11:11:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LAz7=5Y=infradead.org=peterz@srs-us1.protection.inumbo.net>)
 id 1jM8cC-0002YB-Gb
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:11:28 +0000
X-Inumbo-ID: b0117714-7989-11ea-83d8-bc764e2007e4
Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b0117714-7989-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 11:11:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version
 :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-Transfer-Encoding:Content-ID:Content-Description;
 bh=CGYxPY0UmZ+KsvjUaaa1RrlD6l1Y5r/qTWBeIw/gLCU=; b=qL3pjtMbis9rU768jBizcb/Iy5
 lkgPZ7sOpK/DsPBuKBnqJPwEoh7EzhRMARN9MxfFoYYI+3cRY8PVXlVrCrA0udfxR5EDjqMc0V+re
 nLC3SDkLS8Utb2VXyecpgZfXVUU5LMrwtS04bHrIHbiRDeITZiyVdGtK48rrTsO5hjWT0m0UeuXg1
 tqHJFc/BZHLjSBL8q/xUAIWPg4h93yY40YdgaGCVageZbXlihC5CmwwZiGswbW56qbS7qUjqaFCUs
 xSCtdr8d62RmcMAbt4O+MdMpNnruGMaaKjQTvSpcNi0aZG7iWT2tmw1b7zea1c4rmvcajFYLhz76g
 i4M6h/2g==;
Received: from j217100.upc-j.chello.nl ([24.132.217.100]
 helo=noisy.programming.kicks-ass.net)
 by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux))
 id 1jM8c8-0005fM-F0; Wed, 08 Apr 2020 11:11:24 +0000
Received: from hirez.programming.kicks-ass.net
 (hirez.programming.kicks-ass.net [192.168.1.225])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id C0CD1300130;
 Wed,  8 Apr 2020 13:11:22 +0200 (CEST)
Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000)
 id AC0CC2B120793; Wed,  8 Apr 2020 13:11:22 +0200 (CEST)
Date: Wed, 8 Apr 2020 13:11:22 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Ankur Arora <ankur.a.arora@oracle.com>
Subject: Re: [RFC PATCH 14/26] x86/alternatives: Handle native insns in
 text_poke_loc*()
Message-ID: <20200408111122.GT20713@hirez.programming.kicks-ass.net>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <20200408050323.4237-15-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200408050323.4237-15-ankur.a.arora@oracle.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, hpa@zytor.com, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote:
>  struct text_poke_loc {
>  	s32 rel_addr; /* addr := _stext + rel_addr */
> -	s32 rel32;
> -	u8 opcode;
> +	union {
> +		struct {
> +			s32 rel32;
> +			u8 opcode;
> +		} emulated;
> +		struct {
> +			u8 len;
> +		} native;
> +	};
>  	const u8 text[POKE_MAX_OPCODE_SIZE];
>  };

NAK, this grows the structure from 16 to 20 bytes.


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:13:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM8eE-0002g5-TO; Wed, 08 Apr 2020 11:13:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LAz7=5Y=infradead.org=peterz@srs-us1.protection.inumbo.net>)
 id 1jM8eD-0002g0-91
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:13:33 +0000
X-Inumbo-ID: f79952fa-7989-11ea-b58d-bc764e2007e4
Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f79952fa-7989-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 11:13:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version
 :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-Transfer-Encoding:Content-ID:Content-Description;
 bh=owW3+5nk1emkhI4cOviK2xmpja0Eslb3d5NnNfm4ABY=; b=oteVl0qlOAfP5bhgb67Zr9x8Uc
 bRuCew67l9BV+/JRZuTjgTOAHnBFS5SKoNK/HOyOWZ59WupxVuibCY5+05oGbheDiG5HWHmy8S4cY
 +f2xrfMQsZOvUZYjTabyUzPGHWusJiCu9h6qxdvvNWt8LZz5G6NWmIgJo/wOSFsGaPB/EH1LWEyba
 Uxs0oqH+RwuSDxacMYmzB3oEW+Nr+dQgn9MZPS9f+gEO3+8AdQmbcC07SK3Pp7nDys4oWPuoeuDtv
 ySERjY/R8FKfZKJ7RXVPmUhhFomNX8N+JCj4eARuV9FGrPbDsyi2jNOaJLHBEZLyhuKvECYTaU5Ar
 fS+QjguQ==;
Received: from j217100.upc-j.chello.nl ([24.132.217.100]
 helo=noisy.programming.kicks-ass.net)
 by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux))
 id 1jM8e4-0005mx-Gs; Wed, 08 Apr 2020 11:13:24 +0000
Received: from hirez.programming.kicks-ass.net
 (hirez.programming.kicks-ass.net [192.168.1.225])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id E0E2E300130;
 Wed,  8 Apr 2020 13:13:22 +0200 (CEST)
Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000)
 id 944032BA90A62; Wed,  8 Apr 2020 13:13:22 +0200 (CEST)
Date: Wed, 8 Apr 2020 13:13:22 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Ankur Arora <ankur.a.arora@oracle.com>
Subject: Re: [RFC PATCH 15/26] x86/alternatives: Non-emulated text poking
Message-ID: <20200408111322.GU20713@hirez.programming.kicks-ass.net>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <20200408050323.4237-16-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200408050323.4237-16-ankur.a.arora@oracle.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, hpa@zytor.com, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 10:03:12PM -0700, Ankur Arora wrote:
> +static void __maybe_unused sync_one(void)
> +{
> +	/*
> +	 * We might be executing in NMI context, and so cannot use
> +	 * IRET as a synchronizing instruction.
> +	 *
> +	 * We could use native_write_cr2() but that is not guaranteed
> +	 * to work on Xen-PV -- it is emulated by Xen and might not
> +	 * execute an iret (or similar synchronizing instruction)
> +	 * internally.
> +	 *
> +	 * cpuid() would trap as well. Unclear if that's a solution
> +	 * either.
> +	 */
> +	if (in_nmi())
> +		cpuid_eax(1);
> +	else
> +		sync_core();
> +}

That's not thinking staight; what do you think the INT3 does when it
happens inside an NMI ?


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:15:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM8gD-0002nz-DK; Wed, 08 Apr 2020 11:15:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jM8gC-0002nt-3X
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:15:36 +0000
X-Inumbo-ID: 43e14212-798a-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 43e14212-798a-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 11:15:34 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1109FAD5F;
 Wed,  8 Apr 2020 11:15:32 +0000 (UTC)
Subject: Re: [PATCH v14 0/3] VM forking
To: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 Anthony PERARD <anthony.perard@citrix.com>
References: <cover.1586185752.git.tamas.lengyel@intel.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3dcb79f6-7d90-ced1-51d4-f5b6a32a64e9@suse.com>
Date: Wed, 8 Apr 2020 13:15:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <cover.1586185752.git.tamas.lengyel@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Tamas K Lengyel <tamas@tklengyel.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.2020 17:20, Tamas K Lengyel wrote:
> The following series implements VM forking for Intel HVM guests to allow for
> the fast creation of identical VMs without the assosciated high startup costs
> of booting or restoring the VM from a savefile.
> 
> JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
> 
> The fork operation is implemented as part of the "xl fork-vm" command:
>     xl fork-vm -C <config> -Q <qemu-save-file> -m <max-vcpus> <parent_domid>
>     
> By default a fully functional fork is created. The user is in charge however to
> create the appropriate config file for the fork and to generate the QEMU save
> file before the fork-vm call is made. The config file needs to give the
> fork a new name at minimum but other settings may also require changes. Certain
> settings in the config file of both the parent and the fork have to be set to
> default. Details are documented.
> 
> The interface also allows to split the forking into two steps:
>     xl fork-vm --launch-dm no \
>                -m <max-vcpus> \
>                -p <parent_domid>
>     xl fork-vm --launch-dm late \
>                -C <config_file_for_fork> \
>                -Q <qemu_save_file> \
>                <fork_domid>
> 
> The split creation model is useful when the VM needs to be created as fast as
> possible. The forked VM can be unpaused without the device model being launched
> to be monitored and accessed via VMI. Note however that without its device
> model running (depending on what is executing in the VM) it is bound to
> misbehave or even crash when its trying to access devices that would be
> emulated by QEMU. We anticipate that for certain use-cases this would be an
> acceptable situation, in case for example when fuzzing is performed of code
> segments that don't access such devices.
> 
> Launching the device model requires the QEMU Xen savefile to be generated
> manually from the parent VM. This can be accomplished simply by connecting to
> its QMP socket and issuing the "xen-save-devices-state" command. For example
> using the standard tool socat these commands can be used to generate the file:
>     socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-<parent_domid>
>     { "execute": "qmp_capabilities" }
>     { "execute": "xen-save-devices-state", \
>         "arguments": { "filename": "/path/to/save/qemu_state", \
>                         "live": false} }
> 
> At runtime the forked VM starts running with an empty p2m which gets lazily
> populated when the VM generates EPT faults, similar to how altp2m views are
> populated. If the memory access is a read-only access, the p2m entry is
> populated with a memory shared entry with its parent. For write memory accesses
> or in case memory sharing wasn't possible (for example in case a reference is
> held by a third party), a new page is allocated and the page contents are
> copied over from the parent VM. Forks can be further forked if needed, thus
> allowing for further memory savings.
> 
> A VM fork reset hypercall is also added that allows the fork to be reset to the
> state it was just after a fork, also accessible via xl:
>     xl fork-vm --fork-reset -p <fork_domid>
> 
> This is an optimization for cases where the forks are very short-lived and run
> without a device model, so resetting saves some time compared to creating a
> brand new fork provided the fork has not aquired a lot of memory. If the fork
> has a lot of memory deduplicated it is likely going to be faster to create a
> new fork from scratch and asynchronously destroying the old one.
> 
> The series has been tested with Windows VMs and functions as expected. Linux
> VMs when forked from a running VM will have a frozen VNC screen. Linux VMs at
> this time can only be forked with a working device model when the parent VM was
> restored from a snapshot using "xl restore -p". This is a known limitation.
> Also note that PVHVM/PVH Linux guests have not been tested. Forking most likely
> works but PV devices and drivers would require additional wiring to set things
> up properly since the guests are unaware of the forking taking place, unlike
> the save/restore routine where the guest is made aware of the procedure.
> 
> Forking time has been measured to be 0.0007s, device model launch to be around
> 1s depending largely on the number of devices being emulated. Fork resets have
> been measured to be 0.0001s under the optimal circumstances.
> 
> New in v14:
>     minor adjustments
> 
> Patch 1 implements the VM fork
> Patch 2 implements fork reset operation
> Patch 3 adds the toolstack-side code implementing VM forking and reset
> 
> Tamas K Lengyel (3):
>   xen/mem_sharing: VM forking
>   x86/mem_sharing: reset a fork

I've applied these two, but ...

>   xen/tools: VM forking toolstack side

... since this one doesn't have any ack or alike I'll defer to
the tool stack maintainers here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:17:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM8iO-0002w1-QD; Wed, 08 Apr 2020 11:17:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LAz7=5Y=infradead.org=peterz@srs-us1.protection.inumbo.net>)
 id 1jM8iN-0002vv-SO
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:17:51 +0000
X-Inumbo-ID: 9571be40-798a-11ea-83d8-bc764e2007e4
Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9571be40-798a-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 11:17:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version
 :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-Transfer-Encoding:Content-ID:Content-Description;
 bh=3YJqaOoM4AXHXL0XANzFtbQE1EpTeXAe0og/pFKkpCA=; b=I26DyJnGGGzpg8aW0CSl3TSO8/
 fCLcInYqjvbFiDB3N97TYX+H95E7s7uhQVs1LywnJrxvQAyQKrsXOH4HCqon7QCoisfEoaw6RVFDS
 NQOCO/S4ycVdQoxRL46SZ2UfRTHDCE0HFlkAY/BrTNmWRge1970iZq7hPoYzBfUytDGspcPrPDjhj
 lDsRcJWFs6qo8zxx5srQ71V1LToOn2jGFgto63isvIjWn9uZp/yp5qMXQVuaeLYT2wjloOAyaBt4C
 CZadKhWG7I0rpK07+OqaLbMseS8zTcP0JuX9+Fe8qNltNOQHzKTM5TMcUHTWVQtPsjS20OYk7jLcj
 W3k8stdA==;
Received: from j217100.upc-j.chello.nl ([24.132.217.100]
 helo=noisy.programming.kicks-ass.net)
 by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux))
 id 1jM8iL-0000RC-Gm; Wed, 08 Apr 2020 11:17:49 +0000
Received: from hirez.programming.kicks-ass.net
 (hirez.programming.kicks-ass.net [192.168.1.225])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id C4D5B300130;
 Wed,  8 Apr 2020 13:17:47 +0200 (CEST)
Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000)
 id B0E612BA90A63; Wed,  8 Apr 2020 13:17:47 +0200 (CEST)
Date: Wed, 8 Apr 2020 13:17:47 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Ankur Arora <ankur.a.arora@oracle.com>
Subject: Re: [RFC PATCH 14/26] x86/alternatives: Handle native insns in
 text_poke_loc*()
Message-ID: <20200408111747.GV20713@hirez.programming.kicks-ass.net>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <20200408050323.4237-15-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200408050323.4237-15-ankur.a.arora@oracle.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, hpa@zytor.com, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote:
> @@ -1071,10 +1079,13 @@ int notrace poke_int3_handler(struct pt_regs *regs)
>  			goto out_put;
>  	}
>  
> -	len = text_opcode_size(tp->opcode);
> +	if (desc->native)
> +		BUG();
> +

Subject: x86/alternatives: Handle native insns in text_poke_loc*()

That's not really handling, is it..


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:22:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM8n9-0003oW-L7; Wed, 08 Apr 2020 11:22:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jM8n8-0003oM-Di
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:22:46 +0000
X-Inumbo-ID: 4308724c-798b-11ea-81ce-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4308724c-798b-11ea-81ce-12813bfff9fa;
 Wed, 08 Apr 2020 11:22:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=bIYToYQT7yKCp/SPUmOo5TEA8gCvNbAzIp2Msi3Q2xs=; b=L0Cdzuz5jFv6o3BH9Xn1AiZ48
 zkz6/1gz4rKZ5iOEwPY6YEeuTF0Yr/qp8FGjrNHaP0wnky++Ec122mRdK8JfrzmiGxd2rFL6DQqdz
 ij8a9PB9wtYuD96Ruu+qKRX0l5LeywgvOqw8LaXQhXCqlL07Z5UWm8qvFY6JecKxNYBEM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM8n3-0002SQ-Pi; Wed, 08 Apr 2020 11:22:41 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jM8n3-0007YS-9C; Wed, 08 Apr 2020 11:22:41 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jM8n3-0006sv-8V; Wed, 08 Apr 2020 11:22:41 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149517-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-coverity test] 149517: all pass - PUSHED
X-Osstest-Versions-This: xen=e013e8514389b739153016349e49f5a78e34ddf0
X-Osstest-Versions-That: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 11:22:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen                  e013e8514389b739153016349e49f5a78e34ddf0
baseline version:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd

Last test of basis   149438  2020-04-05 09:19:59 Z    3 days
Testing same since   149517  2020-04-08 09:19:14 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Juergen Gross <jgross@suse.com>
  Wei Liu <wl@xen.org>

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
   990b6e38d9..e013e85143  e013e8514389b739153016349e49f5a78e34ddf0 -> coverity-tested/smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:23:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:23:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM8o4-0003t1-Vb; Wed, 08 Apr 2020 11:23:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LAz7=5Y=infradead.org=peterz@srs-us1.protection.inumbo.net>)
 id 1jM8o3-0003su-Lw
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:23:43 +0000
X-Inumbo-ID: 64c524b6-798b-11ea-b4f4-bc764e2007e4
Received: from merlin.infradead.org (unknown [2001:8b0:10b:1231::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 64c524b6-798b-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 11:23:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version:
 References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-Transfer-Encoding:Content-ID:Content-Description;
 bh=4ZLX7MfSUqHHEvMTIVvOx5yn0LV+2MvDcxCOdLfIT5s=; b=nkszLrTMFN8ogtJBJVVDqDDkIX
 eSArLLy1rOFEHGcIv2pr37OPq3pKTdTYcNgnodxsyyLNWOD3DAjqhsiDqkAyH4oQ6l9V2pQn72kPD
 mILd26jF+lKPcN8g3yoW3x8kS4c26LjWz7lIqFKXpkhg3jfFTpiwXP0YUs0eTbaTntgpaIHbizTaA
 9TrGdyDOTCx/MILvvo54NNBGXTQ5n+B6MPfI6sgngiGeJc7xDpCcKRQpmsNEboGHcz6r5hsgA97Y6
 +tgOqOBPKlkwCWrUoph4w02SlhpL1VEdCekvbk2tenz9RfmrZBEfICuPRptBcDh4bWpIXzaNm5/sg
 1n6I1bdA==;
Received: from j217100.upc-j.chello.nl ([24.132.217.100]
 helo=noisy.programming.kicks-ass.net)
 by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux))
 id 1jM8ns-0000Iw-4E; Wed, 08 Apr 2020 11:23:32 +0000
Received: from hirez.programming.kicks-ass.net
 (hirez.programming.kicks-ass.net [192.168.1.225])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 302BA300478;
 Wed,  8 Apr 2020 13:23:29 +0200 (CEST)
Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000)
 id 1C0332BA90A63; Wed,  8 Apr 2020 13:23:29 +0200 (CEST)
Date: Wed, 8 Apr 2020 13:23:29 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Ankur Arora <ankur.a.arora@oracle.com>
Subject: Re: [RFC PATCH 15/26] x86/alternatives: Non-emulated text poking
Message-ID: <20200408112329.GW20713@hirez.programming.kicks-ass.net>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <20200408050323.4237-16-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200408050323.4237-16-ankur.a.arora@oracle.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, hpa@zytor.com, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 10:03:12PM -0700, Ankur Arora wrote:
> +static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
> +{
> +	int ret;
> +
> +	lockdep_assert_held(&text_mutex);
> +
> +	if (system_state != SYSTEM_RUNNING)
> +		return -EINVAL;
> +
> +	text_poke_state.stage = stage;
> +	text_poke_state.num_acks = cpumask_weight(cpu_online_mask);
> +	text_poke_state.head = &alt_modules;
> +
> +	text_poke_state.patch_worker = worker;
> +	text_poke_state.state = PATCH_SYNC_DONE; /* Start state */
> +	text_poke_state.primary_cpu = smp_processor_id();
> +
> +	/*
> +	 * Run the worker on all online CPUs. Don't need to do anything
> +	 * for offline CPUs as they come back online with a clean cache.
> +	 */
> +	ret = stop_machine(patch_worker, &text_poke_state, cpu_online_mask);

This.. that on its own is almost a reason to NAK the entire thing. We're
all working very hard to get rid of stop_machine() and you're adding
one.

Worse, stop_machine() is notoriously crap on over-committed virt, the
exact scenario where you want it.

> +
> +	return ret;
> +}


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:25:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM8pa-00040i-Ak; Wed, 08 Apr 2020 11:25:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jM8pY-00040c-HI
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:25:16 +0000
X-Inumbo-ID: 9e6951d8-798b-11ea-81d0-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9e6951d8-798b-11ea-81d0-12813bfff9fa;
 Wed, 08 Apr 2020 11:25:15 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 21824AF2C;
 Wed,  8 Apr 2020 11:25:14 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: Roger Pau Monne <roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <9c7ec98b-bd2d-4fbf-530a-2164dbbee200@suse.com>
Date: Wed, 8 Apr 2020 13:25:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200406105703.79201-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.2020 12:57, Roger Pau Monne wrote:
> Introduce a specific flag to request a HVM guest linear TLB flush,
> which is an ASID/VPID tickle that forces a guest linear to guest
> physical TLB flush for all HVM guests.
> 
> This was previously unconditionally done in each pre_flush call, but
> that's not required: HVM guests not using shadow don't require linear
> TLB flushes as Xen doesn't modify the guest page tables in that case
> (ie: when using HAP). Note that shadow paging code already takes care
> of issuing the necessary flushes when the shadow page tables are
> modified.
> 
> In order to keep the previous behavior modify all shadow code TLB
> flushes to also flush the guest linear to physical TLB if the guest is
> HVM. I haven't looked at each specific shadow code TLB flush in order
> to figure out whether it actually requires a guest TLB flush or not,
> so there might be room for improvement in that regard.
> 
> Also perform ASID/VPID flushes when modifying the p2m tables as it's a
> requirement for AMD hardware. Finally keep the flush in
> switch_cr3_cr4, as it's not clear whether code could rely on
> switch_cr3_cr4 also performing a guest linear TLB flush. A following
> patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to
> not be necessary.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
with one really minor remark:

> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d,
>  
>      p2m_unlock(p2m);
>  
> -    flush_tlb_mask(d->dirty_cpumask);
> +    flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) |
> +                                 FLUSH_HVM_ASID_CORE);

In cases where one case is assumed to be more likely than the other
putting the more likely one first can be viewed as a mild hint to
the compiler, and hence an extra ! may be warranted in an if() or
a conditional expression. Here, however, I don't think we can
really consider one case more likely than the other, and hence I'd
suggest to avoid the !, flipping the other two expressions
accordingly. I may take the liberty to adjust this while committing
(if I'm to be the one).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:34:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:34:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM8xy-0004sB-5c; Wed, 08 Apr 2020 11:33:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jM8xx-0004s6-9I
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:33:57 +0000
X-Inumbo-ID: d472d7da-798c-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d472d7da-798c-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 11:33:56 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 28EB5AF40;
 Wed,  8 Apr 2020 11:33:54 +0000 (UTC)
Subject: Re: [XEN PATCH v4 04/18] xen/build: include include/config/auto.conf
 in main Makefile
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-5-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <caf9aa56-1bc4-b24a-2a88-1c825ca8805e@suse.com>
Date: Wed, 8 Apr 2020 13:33:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-5-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:30, Anthony PERARD wrote:
> --- a/xen/scripts/Kbuild.include
> +++ b/xen/scripts/Kbuild.include
> @@ -32,3 +32,8 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || e
>  # Usage:
>  # $(MAKE) $(clean) dir
>  clean := -f $(BASEDIR)/scripts/Makefile.clean clean -C
> +
> +# Shorthand for kconfig
> +# Usage:
> +# $(MAKE) $(kconfig) target
> +kconfig = -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"

Is this going to be needed outside of xen/Makefile? If not, I'd
like to ask that it be local to xen/Makefile. With the adjustment
or with a reply clarifying to future plans
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:36:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:36:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM908-00050S-L0; Wed, 08 Apr 2020 11:36:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jM907-00050M-P5
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:36:11 +0000
X-Inumbo-ID: 251ba0b8-798d-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 251ba0b8-798d-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 11:36:11 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 59F2BAF48;
 Wed,  8 Apr 2020 11:36:09 +0000 (UTC)
Subject: Re: [XEN PATCH v4 05/18] xen/build: use new $(c_flags) and $(a_flags)
 instead of $(CFLAGS)
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-6-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e096f692-7c67-707a-4ed2-156d725a43ad@suse.com>
Date: Wed, 8 Apr 2020 13:36:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-6-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Tim Deegan <tim@xen.org>,
 xen-devel@lists.xenproject.org, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:30, Anthony PERARD wrote:
> In a later patch ("xen/build: have the root Makefile generates the
> CFLAGS), we want to generate the CFLAGS in xen/Makefile, then export
> it and have Rules.mk use a CFLAGS from the environment variables. That
> changes the flavor of the CFLAGS and flags intended for one target
> (like -D__OBJECT_FILE__ and -M%) gets propagated and duplicated. So we
> start by moving such flags out of $(CFLAGS) and into $(c_flags) which
> is to be modified by only Rules.mk.
> 
> __OBJECT_FILE__ is only used by arch/x86/mm/*.c files, so having it in
> $(c_flags) is enough, we don't need it in $(a_flags).
> 
> For include/Makefile and as-insn we can keep using CFLAGS, but since
> it doesn't have -M* flags anymore there is no need to filter them out.
> 
> The XEN_BUILD_EFI tests in arch/x86/Makefile was filtering out
> CFLAGS-y, but according to dd40177c1bc8 ("x86-64/EFI: add CFLAGS to
> check compile"), it was done to filter out -MF. CFLAGS doesn't
> have those flags anymore, so no filtering is needed.
> 
> This is inspired by the way Kbuild generates CFLAGS for each targets.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:36:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM90Y-00052t-2M; Wed, 08 Apr 2020 11:36:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LAz7=5Y=infradead.org=peterz@srs-us1.protection.inumbo.net>)
 id 1jM90W-00052i-B4
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:36:36 +0000
X-Inumbo-ID: 335b7d7e-798d-11ea-b58d-bc764e2007e4
Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 335b7d7e-798d-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 11:36:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version
 :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-Transfer-Encoding:Content-ID:Content-Description;
 bh=BmUpeBD+1tkdQ4tsE6HQqpMf3ktolc1V6p/HWEY98HY=; b=Qi5xW5e0IyX3C7czAvN4b9USKe
 Vw9AbT0hUhEsMc1N29Rjr5JF4PixkRwKoB2k7CHbQKlhhwdI1gHZDWzkIC/T4W3XpYwGK22A3OD5f
 YKOR/wZquke/IPYf/tjWI2lDstAxcpTdxYF/D0CVP6LcMHwWMxOEMFYdGFZiwekJE6baYqsYbNNdj
 VG6eu4ZlrMcD4swRR19FENQfTY/PhgNUrGXs7/3vtIkFJ8qruO7bPZyDME/fAI98LYIqRAeuyV57a
 adom5zNbI+HwxK7C/0/zE6K+9Pmygi92/oQ7XoIP89JEZTSZylxoRwf+X6weK/tFwvTqc0h2UD0Bx
 weCYpnBw==;
Received: from j217100.upc-j.chello.nl ([24.132.217.100]
 helo=noisy.programming.kicks-ass.net)
 by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux))
 id 1jM90T-0003t1-3O; Wed, 08 Apr 2020 11:36:33 +0000
Received: from hirez.programming.kicks-ass.net
 (hirez.programming.kicks-ass.net [192.168.1.225])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 400EE304DB2;
 Wed,  8 Apr 2020 13:36:31 +0200 (CEST)
Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000)
 id 2C1832BA90A66; Wed,  8 Apr 2020 13:36:31 +0200 (CEST)
Date: Wed, 8 Apr 2020 13:36:31 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Ankur Arora <ankur.a.arora@oracle.com>
Subject: Re: [RFC PATCH 19/26] x86/alternatives: NMI safe runtime patching
Message-ID: <20200408113631.GX20713@hirez.programming.kicks-ass.net>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <20200408050323.4237-20-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200408050323.4237-20-ankur.a.arora@oracle.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, hpa@zytor.com, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 10:03:16PM -0700, Ankur Arora wrote:
> @@ -1807,12 +1911,20 @@ static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
>  	text_poke_state.state = PATCH_SYNC_DONE; /* Start state */
>  	text_poke_state.primary_cpu = smp_processor_id();
>  
> +	text_poke_state.nmi_context = nmi;
> +
> +	if (nmi)
> +		register_nmi_handler(NMI_LOCAL, text_poke_nmi,
> +				     NMI_FLAG_FIRST, "text_poke_nmi");
>  	/*
>  	 * Run the worker on all online CPUs. Don't need to do anything
>  	 * for offline CPUs as they come back online with a clean cache.
>  	 */
>  	ret = stop_machine(patch_worker, &text_poke_state, cpu_online_mask);
>  
> +	if (nmi)
> +		unregister_nmi_handler(NMI_LOCAL, "text_poke_nmi");
> +
>  	return ret;
>  }

This is completely bonghits crazy.


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 11:50:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 11:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM9E7-0006hz-D7; Wed, 08 Apr 2020 11:50:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jM9E5-0006hu-Lh
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 11:50:37 +0000
X-Inumbo-ID: 28de8218-798f-11ea-81d1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 28de8218-798f-11ea-81d1-12813bfff9fa;
 Wed, 08 Apr 2020 11:50:36 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 77059ABC2;
 Wed,  8 Apr 2020 11:50:34 +0000 (UTC)
Subject: Re: [XEN PATCH v4 06/18] xen/build: have the root Makefile generates
 the CFLAGS
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-7-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <a2b16a74-4eed-eeae-d791-fa9fd4e63d08@suse.com>
Date: Wed, 8 Apr 2020 13:50:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-7-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:30, Anthony PERARD wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -115,6 +115,64 @@ $(KCONFIG_CONFIG):
>  include/config/%.conf include/config/%.conf.cmd: $(KCONFIG_CONFIG)
>  	$(MAKE) $(kconfig) syncconfig
>  
> +ifeq ($(CONFIG_DEBUG),y)
> +CFLAGS += -O1
> +else
> +CFLAGS += -O2
> +endif
> +
> +ifeq ($(CONFIG_FRAME_POINTER),y)
> +CFLAGS += -fno-omit-frame-pointer
> +else
> +CFLAGS += -fomit-frame-pointer
> +endif
> +
> +CFLAGS += -nostdinc -fno-builtin -fno-common
> +CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
> +$(call cc-option-add,CFLAGS,CC,-Wvla)
> +CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
> +CFLAGS-$(CONFIG_DEBUG_INFO) += -g
> +
> +ifneq ($(CONFIG_CC_IS_CLANG),y)
> +# Clang doesn't understand this command line argument, and doesn't appear to
> +# have an suitable alternative.  The resulting compiled binary does function,

I realize you only move this, but it would still be nice to adjust
this to "... a suitable alternative" on this occasion.

> +# but has an excessively large symbol table.
> +CFLAGS += -Wa,--strip-local-absolute
> +endif
> +
> +AFLAGS += -D__ASSEMBLY__
> +
> +CFLAGS += $(CFLAGS-y)
> +# allow extra CFLAGS externally via EXTRA_CFLAGS_XEN_CORE
> +CFLAGS += $(EXTRA_CFLAGS_XEN_CORE)
> +
> +# Most CFLAGS are safe for assembly files:
> +#  -std=gnu{89,99} gets confused by #-prefixed end-of-line comments
> +#  -flto makes no sense and annoys clang
> +AFLAGS += $(filter-out -std=gnu% -flto,$(CFLAGS)) $(AFLAGS-y)
> +
> +# LDFLAGS are only passed directly to $(LD)
> +LDFLAGS += $(LDFLAGS_DIRECT) $(LDFLAGS-y)
> +
> +ifeq ($(CONFIG_UBSAN),y)
> +CFLAGS_UBSAN := -fsanitize=undefined
> +else
> +CFLAGS_UBSAN :=
> +endif
> +
> +ifeq ($(CONFIG_LTO),y)
> +CFLAGS += -flto
> +LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
> +endif
> +
> +include $(BASEDIR)/arch/$(TARGET_ARCH)/arch.mk
> +
> +# define new variables to avoid the ones defines in Config.mk

s/defines/defined/

> @@ -140,10 +95,19 @@ obj-bin-y :=
>  endif
>  
>  # Always build obj-bin files as binary even if they come from C source. 
> -$(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
> +# FIXME LTO broken, but we would need a different way to filter -flto out
> +# $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))

While you mention this in the description, I'm still not overly
happy with it getting commented out. What's wrong with making the
construct simply act on c_flags?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 12:00:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 12:00:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM9Nu-0007dR-NJ; Wed, 08 Apr 2020 12:00:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jM9Nt-0007dM-Or
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 12:00:45 +0000
X-Inumbo-ID: 93b09256-7990-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 93b09256-7990-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 12:00:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 49E93AE12;
 Wed,  8 Apr 2020 12:00:43 +0000 (UTC)
Subject: Re: [XEN PATCH v4 07/18] build: Introduce documentation for xen
 Makefiles
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-8-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <0a5f89d5-de77-c548-972f-231061419e51@suse.com>
Date: Wed, 8 Apr 2020 14:00:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-8-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:30, Anthony PERARD wrote:
> This start explainning the variables that can be used in the many
> Makefiles in xen/.
> 
> Most of the document copies and modifies text from Linux v5.4 document
> linux.git/Documentation/kbuild/makefiles.rst. Modification are mostly
> to avoid mentioning kbuild. Thus I've added the SPDX tag which was
> only in index.rst in linux.git.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
with one question:

> +Compilation flags
> +-----------------
> +
> +    CFLAGS-y and AFLAGS-y
> +	These two flags apply only to the makefile in which they
> +	are assigned. They are used for all the normal cc, as and ld
> +	invocations happening during a recursive build.
> +
> +	$(CFLAGS-y) is necessary because the top Makefile owns the
> +	variable $(XEN_CFLAGS) and uses it for compilation flags for the
> +	entire tree. And the variable $(CFLAGS) is modified by Config.mk
> +	which evaluated in every subdirs.
> +
> +	CFLAGS-y specifies options for compiling with $(CC).
> +	AFLAGS-y specifies assembler options.

Is it perhaps worth mentioning that c_flags and a_flags should
not be fiddled with by individual Makefile-s?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 12:05:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 12:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM9Sm-0007nm-AS; Wed, 08 Apr 2020 12:05:48 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jM9Sl-0007nh-0u
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 12:05:47 +0000
X-Inumbo-ID: 46a98926-7991-11ea-81da-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 46a98926-7991-11ea-81da-12813bfff9fa;
 Wed, 08 Apr 2020 12:05:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C0CFBAB89;
 Wed,  8 Apr 2020 12:05:43 +0000 (UTC)
Subject: Re: [XEN PATCH v4 08/18] xen/build: introduce if_changed and
 if_changed_rule
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-9-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <45e19a69-2f9e-a264-0129-539d362487a4@suse.com>
Date: Wed, 8 Apr 2020 14:05:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-9-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:30, Anthony PERARD wrote:
> The if_changed macro from Linux, in addition to check if any files
> needs an update, check if the command line has changed since the last
> invocation. The latter will force a rebuild if any options to the
> executable have changed.
> 
> if_changed_rule checks dependencies like if_changed, but execute
> rule_$(1) instead of cmd_$(1) when a target needs to be rebuilt. A rule_
> macro can call more than one cmd_ macro. One of the cmd_ macro in a
> rule need to be call using a macro that record the command line, so
> cmd_and_record is introduced. It is similar to cmd_and_fixup from
> Linux but without a call to fixdep which we don't have yet. (We will
> later replace cmd_and_record by cmd_and_fixup.)
> 
> Example of a rule_ macro:
> define rule_cc_o_c
>     $(call cmd_and_record,cc_o_o)
>     $(call cmd,objcopy)
> endef
> 
> This needs one of the call to use cmd_and_record, otherwise no .*.cmd
> file will be created, and the target will keep been rebuilt.
> 
> In order for if_changed to works correctly, we need to load the .%.cmd
> files that the macro generates, this is done by adding targets in to
> the $(targets) variable. We use intermediate_targets to add %.init.o
> dependency %.o to target since there aren't in obj-y.
> 
> We also add $(MAKECMDGOALS) to targets so that when running for
> example `make common/memory.i`, make will load the associated .%.cmd
> dependency file.
> 
> Beside the if_changed*, we import the machinery used for a "beautify
> output". The important one is when running make with V=2 which help to
> debug the makefiles by printing why a target is been rebuilt, via the
> $(echo-why) macro.
> 
> if_changed and if_changed_rule aren't used yet.
> 
> Most of this code is copied from Linux v5.4, including the
> documentation.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
with ...

> --- a/docs/misc/xen-makefiles/makefiles.rst
> +++ b/docs/misc/xen-makefiles/makefiles.rst
> @@ -85,3 +85,102 @@ Compilation flags
>  
>  	CFLAGS-y specifies options for compiling with $(CC).
>  	AFLAGS-y specifies assembler options.
> +
> +
> +Build system infrastructure
> +===========================
> +
> +This chapter describe some of the macro used when building Xen.
> +
> +Macros
> +------
> +
> +
> +    if_changed
> +	if_changed is the infrastructure used for the following commands.
> +
> +	Usage::
> +
> +		target: source(s) FORCE
> +			$(call if_changed,ld/objcopy/...)
> +
> +	When the rule is evaluated, it is checked to see if any files
> +	need an update, or the command line has changed since the last
> +	invocation. The latter will force a rebuild if any options
> +	to the executable have changed.
> +	Any target that utilises if_changed must be listed in $(targets),
> +	otherwise the command line check will fail, and the target will
> +	always be built.
> +	if_changed may be used in conjunction with custom commands as
> +	defined in "Custom commands".
> +
> +	Note: It is a typical mistake to forget the FORCE prerequisite.
> +	Another common pitfall is that whitespace is sometimes
> +	significant; for instance, the below will fail (note the extra space
> +	after the comma)::
> +
> +		target: source(s) FORCE
> +
> +	**WRONG!**	$(call if_changed, ld/objcopy/...)
> +
> +        Note:
> +	      if_changed should not be used more than once per target.
> +              It stores the executed command in a corresponding .cmd

... the odd mixing of tabs and spaces here taken care of (I didn't
check if there are more) and ...

> +
> +        file and multiple calls would result in overwrites and

... the apparently stray blank like here dropped.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 12:09:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 12:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM9Vx-0007wh-Qv; Wed, 08 Apr 2020 12:09:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LAz7=5Y=infradead.org=peterz@srs-us1.protection.inumbo.net>)
 id 1jM9Vw-0007wc-CA
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 12:09:04 +0000
X-Inumbo-ID: bc4908f0-7991-11ea-b4f4-bc764e2007e4
Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bc4908f0-7991-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 12:09:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version
 :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-Transfer-Encoding:Content-ID:Content-Description;
 bh=gWpqrb8j/D9PpMGOmBmpJQdVRqYpPCNDUmBBgbEqzPI=; b=rFulLNFAwNEVG4GU0BsmdMg7eK
 t6FVtq8m9hscYZajwJqdZl0pQo8RG/h2U6x8LaG/OUIrwk18XgbKlhR5sH+WiMaUkyF8v6NidJRDN
 JPUpGvXOtQtWrOPXkfxNK/ijhbmmDn37wiBgzbBX+biffyRpwoKqgCXhpgwcszQ1b40icDbkUKgZt
 gmu/qHBTOYhZOPscGlEGNvR5GUfLUaiMhLCbDtMwrbC9Bb1I2G2fveRJORZQjMkBBZM7+9d9qkgqi
 IS9N9w3AZn8HsaiEPr7sydKOZJubXh8l9d/eX+QmafvEV9XBQiJWIA4aXabhy+f5caPQ9auA9NHSu
 /vNODE1g==;
Received: from j217100.upc-j.chello.nl ([24.132.217.100]
 helo=noisy.programming.kicks-ass.net)
 by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux))
 id 1jM9Vr-0006nF-9T; Wed, 08 Apr 2020 12:08:59 +0000
Received: from hirez.programming.kicks-ass.net
 (hirez.programming.kicks-ass.net [192.168.1.225])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 151B030604B;
 Wed,  8 Apr 2020 14:08:56 +0200 (CEST)
Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000)
 id 08E112BA90A73; Wed,  8 Apr 2020 14:08:56 +0200 (CEST)
Date: Wed, 8 Apr 2020 14:08:56 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Ankur Arora <ankur.a.arora@oracle.com>
Subject: Re: [RFC PATCH 00/26] Runtime paravirt patching
Message-ID: <20200408120856.GY20713@hirez.programming.kicks-ass.net>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, hpa@zytor.com, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote:
> A KVM host (or another hypervisor) might advertise paravirtualized
> features and optimization hints (ex KVM_HINTS_REALTIME) which might
> become stale over the lifetime of the guest. For instance, the
> host might go from being undersubscribed to being oversubscribed
> (or the other way round) and it would make sense for the guest
> switch pv-ops based on that.

So what, the paravirt spinlock stuff works just fine when you're not
oversubscribed.

> We keep an interesting subset of pv-ops (pv_lock_ops only for now,
> but PV-TLB ops are also good candidates)

The PV-TLB ops also work just fine when not oversubscribed. IIRC
kvm_flush_tlb_others() is pretty much the same in that case.

> in .parainstructions.runtime,
> while discarding the .parainstructions as usual at init. This is then
> used for switching back and forth between native and paravirt mode.
> ([1] lists some representative numbers of the increased memory
> footprint.)
> 
> Mechanism: the patching itself is done using stop_machine(). That is
> not ideal -- text_poke_stop_machine() was replaced with INT3+emulation
> via text_poke_bp(), but I'm using this to address two issues:
>  1) emulation in text_poke() can only easily handle a small set
>  of instructions and this is problematic for inlined pv-ops (and see
>  a possible alternatives use-case below.)
>  2) paravirt patching might have inter-dependendent ops (ex.
>  lock.queued_lock_slowpath, lock.queued_lock_unlock are paired and
>  need to be updated atomically.)

And then you hope that the spinlock state transfers.. That is that both
implementations agree what an unlocked spinlock looks like.

Suppose the native one was a ticket spinlock, where unlocked means 'head
== tail' while the paravirt one is a test-and-set spinlock, where
unlocked means 'val == 0'.

That just happens to not be the case now, but it was for a fair while.

> The alternative use-case is a runtime version of apply_alternatives()
> (not posted with this patch-set) that can be used for some safe subset
> of X86_FEATUREs. This could be useful in conjunction with the ongoing
> late microcode loading work that Mihai Carabas and others have been
> working on.

The whole late-microcode loading stuff is crazy already; you're making
it take double bonghits.

> Also, there are points of similarity with the ongoing static_call work
> which does rewriting of indirect calls.

Only in so far as that code patching is involved. An analogy would be
comparing having a beer with shooting dope. They're both 'drugs'.

> The difference here is that
> we need to switch a group of calls atomically and given that
> some of them can be inlined, need to handle a wider variety of opcodes.
> 
> To patch safely we need to satisfy these constraints:
> 
>  - No references to insn sequences under replacement on any kernel stack
>    once replacement is in progress. Without this constraint we might end
>    up returning to an address that is in the middle of an instruction.

Both ftrace and optprobes have that issue, neither of them are quite as
crazy as this.

>  - handle inter-dependent ops: as above, lock.queued_lock_unlock(),
>    lock.queued_lock_slowpath() and the rest of the pv_lock_ops are
>    a good example.

While I'm sure this is a fun problem, why are we solving it?

>  - handle a broader set of insns than CALL and JMP: some pv-ops end up
>    getting inlined. Alternatives can contain arbitrary instructions.

So can optprobes.

>  - locking operations can be called from interrupt handlers which means
>    we cannot trivially use IPIs for flushing.

Heck, some NMI handlers use locks..

> Handling these, necessitates that target pv-ops not be preemptible.

I don't think that is a correct inferrence.

> Once that is a given (for safety these need to be explicitly whitelisted
> in runtime_patch()), use a state-machine with the primary CPU doing the
> patching and secondary CPUs in a sync_core() loop. 
> 
> In case we hit an INT3/BP (in NMI or thread-context) we makes forward
> progress by continuing the patching instead of emulating.
> 
> One remaining issue is inter-dependent pv-ops which are also executed in
> the NMI handler -- patching can potentially deadlock in case of multiple
> NMIs. Handle these by pushing some of this work in the NMI handler where
> we know it will be uninterrupted.

I'm just seeing a lot of bonghits without sane rationale. Why is any of
this important?


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 12:28:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 12:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jM9oS-0001CM-KU; Wed, 08 Apr 2020 12:28:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=D8Jc=5Y=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jM9oR-0001Bc-SL
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 12:28:11 +0000
X-Inumbo-ID: 67d6e8c0-7994-11ea-81db-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 67d6e8c0-7994-11ea-81db-12813bfff9fa;
 Wed, 08 Apr 2020 12:28:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 66C7CAC44;
 Wed,  8 Apr 2020 12:28:07 +0000 (UTC)
Subject: Re: [RFC PATCH 00/26] Runtime paravirt patching
To: Ankur Arora <ankur.a.arora@oracle.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <d7f8bff3-526a-6a84-2e81-677cfbac0111@suse.com>
Date: Wed, 8 Apr 2020 14:28:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, kvm@vger.kernel.org, peterz@infradead.org,
 hpa@zytor.com, virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 bp@alien8.de, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, namit@vmware.com, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.20 07:02, Ankur Arora wrote:
> A KVM host (or another hypervisor) might advertise paravirtualized
> features and optimization hints (ex KVM_HINTS_REALTIME) which might
> become stale over the lifetime of the guest. For instance, the

Then this hint is wrong if it can't be guaranteed.

> host might go from being undersubscribed to being oversubscribed
> (or the other way round) and it would make sense for the guest
> switch pv-ops based on that.

I think using pvops for such a feature change is just wrong.

What comes next? Using pvops for being able to migrate a guest from an
Intel to an AMD machine?

...

> There are four main sets of patches in this series:
> 
>   1. PV-ops management (patches 1-10, 20): mostly infrastructure and
>   refactoring pieces to make paravirt patching usable at runtime. For the
>   most part scoped under CONFIG_PARAVIRT_RUNTIME.
> 
>   Patches 1-7, to persist part of parainstructions in memory:
>    "x86/paravirt: Specify subsection in PVOP macros"
>    "x86/paravirt: Allow paravirt patching post-init"
>    "x86/paravirt: PVRTOP macros for PARAVIRT_RUNTIME"
>    "x86/alternatives: Refactor alternatives_smp_module*
>    "x86/alternatives: Rename alternatives_smp*, smp_alt_module
>    "x86/alternatives: Remove stale symbols
>    "x86/paravirt: Persist .parainstructions.runtime"
> 
>   Patches 8-10, develop the inerfaces to safely switch pv-ops:
>    "x86/paravirt: Stash native pv-ops"
>    "x86/paravirt: Add runtime_patch()"
>    "x86/paravirt: Add primitives to stage pv-ops"
> 
>   Patch 20 enables switching of pv_lock_ops:
>    "x86/paravirt: Enable pv-spinlocks in runtime_patch()"
> 
>   2. Non-emulated text poking (patches 11-19)
> 
>   Patches 11-13 are mostly refactoring to split __text_poke() into map,
>   unmap and poke/memcpy phases with the poke portion being re-entrant
>    "x86/alternatives: Remove return value of text_poke*()"
>    "x86/alternatives: Use __get_unlocked_pte() in text_poke()"
>    "x86/alternatives: Split __text_poke()"
> 
>   Patches 15, 17 add the actual poking state-machine:
>    "x86/alternatives: Non-emulated text poking"
>    "x86/alternatives: Add patching logic in text_poke_site()"
> 
>   with patches 14 and 18 containing the pieces for BP handling:
>    "x86/alternatives: Handle native insns in text_poke_loc*()"
>    "x86/alternatives: Handle BP in non-emulated text poking"
> 
>   and patch 19 provides the ability to use the state-machine above in an
>   NMI context (fixes some potential deadlocks when handling inter-
>   dependent operations and multiple NMIs):
>    "x86/alternatives: NMI safe runtime patching".
> 
>   Patch 16 provides the interface (paravirt_runtime_patch()) to use the
>   poking mechanism developed above and patch 21 adds a selftest:
>    "x86/alternatives: Add paravirt patching at runtime"
>    "x86/alternatives: Paravirt runtime selftest"
> 
>   3. KVM guest changes to be able to use this (patches 22-23,25-26):
>    "kvm/paravirt: Encapsulate KVM pv switching logic"
>    "x86/kvm: Add worker to trigger runtime patching"
>    "x86/kvm: Guest support for dynamic hints"
>    "x86/kvm: Add hint change notifier for KVM_HINT_REALTIME".
> 
>   4. KVM host changes to notify the guest of a change (patch 24):
>    "x86/kvm: Support dynamic CPUID hints"
> 
> Testing:
> With paravirt patching, the code is mostly stable on Intel and AMD
> systems under kernbench and locktorture with paravirt toggling (with,
> without synthetic NMIs) in the background.
> 
> Queued spinlock performance for locktorture is also on expected lines:
>   [ 1533.221563] Writes:  Total: 1048759000  Max/Min: 0/0   Fail: 0
>   # toggle PV spinlocks
> 
>   [ 1594.713699] Writes:  Total: 1111660545  Max/Min: 0/0   Fail: 0
>   # PV spinlocks (in ~60 seconds) = 62,901,545
> 
>   # toggle native spinlocks
>   [ 1656.117175] Writes:  Total: 1113888840  Max/Min: 0/0   Fail: 0
>    # native spinlocks (in ~60 seconds) = 2,228,295
> 
> The alternatives testing is more limited with it being used to rewrite
> mostly harmless X86_FEATUREs with load in the background.
> 
> Patches also at:
> 
> ssh://git@github.com/terminus/linux.git alternatives-rfc-upstream-v1
> 
> Please review.
> 
> Thanks
> Ankur
> 
> [1] The precise change in memory footprint depends on config options
> but the following example inlines queued_spin_unlock() (which forms
> the bulk of the added state). The added footprint is the size of the
> .parainstructions.runtime section:
> 
>   $ objdump -h vmlinux|grep .parainstructions
>   Idx Name              		Size      VMA
>   	LMA                File-off  Algn
>    27 .parainstructions 		0001013c  ffffffff82895000
>    	0000000002895000   01c95000  2**3
>    28 .parainstructions.runtime  0000cd2c  ffffffff828a5140
>    	00000000028a5140   01ca5140  2**3
> 
>    $ size vmlinux
>    text       data       bss        dec      hex       filename
>    13726196   12302814   14094336   40123346 2643bd2   vmlinux
> 
> Ankur Arora (26):
>    x86/paravirt: Specify subsection in PVOP macros
>    x86/paravirt: Allow paravirt patching post-init
>    x86/paravirt: PVRTOP macros for PARAVIRT_RUNTIME
>    x86/alternatives: Refactor alternatives_smp_module*
>    x86/alternatives: Rename alternatives_smp*, smp_alt_module
>    x86/alternatives: Remove stale symbols
>    x86/paravirt: Persist .parainstructions.runtime
>    x86/paravirt: Stash native pv-ops
>    x86/paravirt: Add runtime_patch()
>    x86/paravirt: Add primitives to stage pv-ops
>    x86/alternatives: Remove return value of text_poke*()
>    x86/alternatives: Use __get_unlocked_pte() in text_poke()
>    x86/alternatives: Split __text_poke()
>    x86/alternatives: Handle native insns in text_poke_loc*()
>    x86/alternatives: Non-emulated text poking
>    x86/alternatives: Add paravirt patching at runtime
>    x86/alternatives: Add patching logic in text_poke_site()
>    x86/alternatives: Handle BP in non-emulated text poking
>    x86/alternatives: NMI safe runtime patching
>    x86/paravirt: Enable pv-spinlocks in runtime_patch()
>    x86/alternatives: Paravirt runtime selftest
>    kvm/paravirt: Encapsulate KVM pv switching logic
>    x86/kvm: Add worker to trigger runtime patching
>    x86/kvm: Support dynamic CPUID hints
>    x86/kvm: Guest support for dynamic hints
>    x86/kvm: Add hint change notifier for KVM_HINT_REALTIME
> 
>   Documentation/virt/kvm/api.rst        |  17 +
>   Documentation/virt/kvm/cpuid.rst      |   9 +-
>   arch/x86/Kconfig                      |  14 +
>   arch/x86/Kconfig.debug                |  13 +
>   arch/x86/entry/entry_64.S             |   5 +
>   arch/x86/include/asm/alternative.h    |  20 +-
>   arch/x86/include/asm/kvm_host.h       |   6 +
>   arch/x86/include/asm/kvm_para.h       |  17 +
>   arch/x86/include/asm/paravirt.h       |  10 +-
>   arch/x86/include/asm/paravirt_types.h | 230 ++++--
>   arch/x86/include/asm/text-patching.h  |  18 +-
>   arch/x86/include/uapi/asm/kvm_para.h  |   2 +
>   arch/x86/kernel/Makefile              |   1 +
>   arch/x86/kernel/alternative.c         | 987 +++++++++++++++++++++++---
>   arch/x86/kernel/kvm.c                 | 191 ++++-
>   arch/x86/kernel/module.c              |  42 +-
>   arch/x86/kernel/paravirt.c            |  16 +-
>   arch/x86/kernel/paravirt_patch.c      |  61 ++
>   arch/x86/kernel/pv_selftest.c         | 264 +++++++
>   arch/x86/kernel/pv_selftest.h         |  15 +
>   arch/x86/kernel/setup.c               |   2 +
>   arch/x86/kernel/vmlinux.lds.S         |  16 +
>   arch/x86/kvm/cpuid.c                  |   3 +-
>   arch/x86/kvm/x86.c                    |  39 +
>   include/asm-generic/kvm_para.h        |  12 +
>   include/asm-generic/vmlinux.lds.h     |   8 +
>   include/linux/kvm_para.h              |   5 +
>   include/linux/mm.h                    |  16 +-
>   include/linux/preempt.h               |  17 +
>   include/uapi/linux/kvm.h              |   4 +
>   kernel/locking/lock_events.c          |   2 +-
>   mm/memory.c                           |   9 +-
>   32 files changed, 1850 insertions(+), 221 deletions(-)
>   create mode 100644 arch/x86/kernel/pv_selftest.c
>   create mode 100644 arch/x86/kernel/pv_selftest.h
> 

Quite a lot of code churn and hacks for a problem which should not
occur on a well administrated machine.

Especially the NMI dependencies make me not wanting to Ack this series.


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 12:40:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 12:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMA0J-0002jX-QC; Wed, 08 Apr 2020 12:40:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMA0I-0002jS-36
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 12:40:26 +0000
X-Inumbo-ID: 1e14b382-7996-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1e14b382-7996-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 12:40:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2273CAB89;
 Wed,  8 Apr 2020 12:40:23 +0000 (UTC)
Subject: Re: [XEN PATCH v4 10/18] xen/build: use if_changed on built_in.o
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-11-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <072ffe9d-88c0-144f-a9ab-c83869ad34e2@suse.com>
Date: Wed, 8 Apr 2020 14:40:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-11-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:30, Anthony PERARD wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -130,15 +130,24 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
>  c_flags += $(CFLAGS-y)
>  a_flags += $(CFLAGS-y) $(AFLAGS-y)
>  
> -built_in.o: $(obj-y) $(extra-y)
> -ifeq ($(obj-y),)
> -	$(CC) $(c_flags) -c -x c /dev/null -o $@
> -else
> +quiet_cmd_ld_builtin = LD      $@
>  ifeq ($(CONFIG_LTO),y)
> -	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
> +cmd_ld_builtin = \
> +    $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
>  else
> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
> +cmd_ld_builtin = \
> +    $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
>  endif

How about going yet one step further and doing away with the
ifeq here altogether:

cmd_ld_builtin-y = \
    $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
cmd_ld_builtin-$(CONFIG_LTO) = \
    $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))

> +quiet_cmd_cc_builtin = LD      $@
> +cmd_cc_builtin = \
> +    $(CC) $(XEN_CFLAGS) -c -x c /dev/null -o $@
> +
> +built_in.o: $(obj-y) $(extra-y) FORCE
> +ifeq ($(obj-y),)
> +	$(call if_changed,cc_builtin)
> +else
> +	$(call if_changed,ld_builtin)

	$(call if_changed,ld_builtin-y)

?

As an aside (not something you introduce) this makes it even more
prominent that the use of $(XEN_LDFLAGS) is asymmetric here, for
whatever reason (if any). Of course there's other redundancy
between the two commands which could be eliminated.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 12:46:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 12:46:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMA6Q-0002vd-OZ; Wed, 08 Apr 2020 12:46:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMA6P-0002vY-BN
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 12:46:45 +0000
X-Inumbo-ID: 006a88c4-7997-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 006a88c4-7997-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 12:46:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BEDFCACB8;
 Wed,  8 Apr 2020 12:46:42 +0000 (UTC)
Subject: Re: [XEN PATCH v4 12/18] xen/build: factorise generation of the
 linker scripts
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-13-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <af0121cc-c282-ceb0-b5e8-44ac0ba6ebfb@suse.com>
Date: Wed, 8 Apr 2020 14:46:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-13-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:30, Anthony PERARD wrote:
> In Arm and X86 makefile, generating the linker script is the same, so
> we can simply have both call the same macro.
> 
> We need to add *.lds files into extra-y so that Rules.mk can find the
> .*.cmd dependency file and load it.
> 
> Change made to the command line:
> - Use of $(CPP) instead of $(CC) -E
> - Remove -Ui386.
>   We don't compile Xen for i386 anymore, so that macro is never
>   defined. Also it doesn't make sense on Arm.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 
> Notes:
>     v4:
>     - fix rebuild by adding FORCE as dependency
>     - Use $(CPP)
>     - remove -Ui386
>     - avoid using "define" for cmd_cc_lds_S, as adding '; \' on each line is
>       still mandatory for if_changed (or cmd) macro to work.

I still don't believe in there being a need for "; \" there. This
actually breaks things, after all:

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -236,6 +236,12 @@ cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
>  %.s: %.S FORCE
>  	$(call if_changed,cpp_s_S)
>  
> +# Linker scripts, .lds.S -> .lds
> +quiet_cmd_cc_lds_S = LDS     $@
> +cmd_cc_lds_S = $(CPP) -P $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<; \
> +    sed -e 's/.*\.lds\.o:/$(@F):/g' <$(dot-target).d >$(dot-target).d.new; \
> +    mv -f $(dot-target).d.new $(dot-target).d

if $(CPP) or sed fail, previously the whole rule would have failed,
which no longer is the case with your use of semicolons. There
ought to be a solution to this, ideally one better than adding
"set -e" as the first command ("define" would at least deal with
the multi-line make issue, but without it being clear to me why the
semicolons would be needed I don't think I can suggest anything
there at the moment).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 12:54:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 12:54:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAE7-0003m6-Jq; Wed, 08 Apr 2020 12:54:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMAE6-0003m1-8i
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 12:54:42 +0000
X-Inumbo-ID: 1c7c2e72-7998-11ea-81e1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1c7c2e72-7998-11ea-81e1-12813bfff9fa;
 Wed, 08 Apr 2020 12:54:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3F373ACB8;
 Wed,  8 Apr 2020 12:54:39 +0000 (UTC)
Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-15-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
Date: Wed, 8 Apr 2020 14:54:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-15-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:30, Anthony PERARD wrote:
> We want to use the same rune to build mm/*/guest_*.o as the one use to
> build every other *.o object. The consequence it that file symbols that
> the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
> 
> (1) Currently we have those two file symbols:
>     guest_walk.c
>     guest_walk_2.o
> (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have:
>     arch/x86/mm/guest_walk.c
>     guest_walk_2.o
> 
> The order in which those symbols are present may be different.
> 
> Currently, in case (1) ./symbols chooses the *.o symbol (object file
> name). But in case (2), may choose the *.c symbol (source file name with
> path component) if it is first
> 
> We want to have ./symbols choose the object file name symbol in both
> cases.

I guess the reason for wanting this is somehow connected to the
statement at the beginning of the description, but I can't seem
to be able to make the connection.

> So this patch changes that ./symbols prefer the "object file
> name" symbol over the "source file name with path component" symbols.
> 
> The new intended order of preference is:
>     - first object file name symbol
>     - first source file name with path components symbol
>     - last source file name without any path component symbol

Isn't this going to lead to ambiguities again when
CONFIG_ENFORCE_UNIQUE_SYMBOLS? Several object files (in different
dirs) are named the same, after all. Static symbols with the same
name in such objects would hence resolve to the same kallsyms
name.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:02:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMALg-0004eP-EI; Wed, 08 Apr 2020 13:02:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMALf-0004eK-G8
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:02:31 +0000
X-Inumbo-ID: 345f3db2-7999-11ea-81e3-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 345f3db2-7999-11ea-81e3-12813bfff9fa;
 Wed, 08 Apr 2020 13:02:30 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1BBEDAE17;
 Wed,  8 Apr 2020 13:02:29 +0000 (UTC)
Subject: Re: [XEN PATCH v4 15/18] xen/build: use if_changed to build guest_%.o
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-16-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <9bf47db9-e3cf-fffd-cfb2-18dec2317c91@suse.com>
Date: Wed, 8 Apr 2020 15:02:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-16-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:30, Anthony PERARD wrote:
> Use if_changed for building all guest_%.o objects, and make use of
> command that already exist.
> 
> This patch make a change to the way guest_%.o files are built, and now
> run the same commands that enforce unique symbols. But with patch
> "xen,symbols: rework file symbols selection", ./symbols should still
> select the file symbols directive intended to be used for guest_%.o
> objects.

I'm having trouble making the connection between the change to the
symbols tool and the adjustments made here:

> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -11,11 +11,13 @@ obj-y += p2m.o p2m-pt.o
>  obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
>  obj-y += paging.o
>  
> -guest_walk_%.o: guest_walk.c Makefile
> -	$(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@

The original rules didn't do anything special to arrange for the
resulting kallsyms names; these arrangements instead live at the
top of the respective source files, in the form of asm()-s.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:13:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:13:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAWR-0005X0-BN; Wed, 08 Apr 2020 13:13:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=7Out=5Y=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jMAWQ-0005Wv-FE
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:13:38 +0000
X-Inumbo-ID: c16e48c9-799a-11ea-81e3-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c16e48c9-799a-11ea-81e3-12813bfff9fa;
 Wed, 08 Apr 2020 13:13:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586351617;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=dbBGIPqFa69AUcUcoG6gXS/NYSjqqvaGNUEdPnRQty8=;
 b=DmBy6VjmhjjPoL/n+aeLz2EryYW9uKbyRdJ6DD7aB3y2aIOkNWuwbrOu
 /zPcK9+s71L9TamJ5f6BlEKogthlD31yEWBoYshesNoqsRvyAU2fWngT/
 Q4VgOKeN2MUBOQqGqCCt1I4feYWXCjOE9Kw+RDRW9B+ZJtS4FqWWMjxf3 A=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: N1S6I25XaK5Xfn0ILqrtQKiLXZrH7wfZuQmiz4ZaN4mFYmn6cOo54tmV6OQ1kuz5IqJC3bFaH+
 hghFS7sSDANfUoPWiWxBRYqxNqXmVYdQfaRLeBVTtFN/dAngeU4tyBZlHqZDeAXnoMKaNXi80V
 8gGJSgXRgBlqXN58+hM8maHCbQFrn+8otlPzjGPlyjdoPQCAYa0HajBdrw4bXNXHclHaCJR+BG
 yFGtBcdcSW8XOdOx8msVYFzYfpvKMhuFP6jWMhTYV/NXM60iz+oM7nQLfHqk3pnqvjwP+gNOmA
 sgQ=
X-SBRS: 2.7
X-MesageID: 16033973
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,358,1580792400"; d="scan'208";a="16033973"
Subject: Re: [XEN PATCH v4 10/18] xen/build: use if_changed on built_in.o
To: Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-11-anthony.perard@citrix.com>
 <072ffe9d-88c0-144f-a9ab-c83869ad34e2@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <71ee52de-af4a-2b1b-4080-d42af6ac6399@citrix.com>
Date: Wed, 8 Apr 2020 14:13:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <072ffe9d-88c0-144f-a9ab-c83869ad34e2@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08/04/2020 13:40, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -130,15 +130,24 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
>>  c_flags += $(CFLAGS-y)
>>  a_flags += $(CFLAGS-y) $(AFLAGS-y)
>>  
>> -built_in.o: $(obj-y) $(extra-y)
>> -ifeq ($(obj-y),)
>> -	$(CC) $(c_flags) -c -x c /dev/null -o $@
>> -else
>> +quiet_cmd_ld_builtin = LD      $@
>>  ifeq ($(CONFIG_LTO),y)
>> -	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
>> +cmd_ld_builtin = \
>> +    $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
>>  else
>> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
>> +cmd_ld_builtin = \
>> +    $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
>>  endif
> How about going yet one step further and doing away with the
> ifeq here altogether:
>
> cmd_ld_builtin-y = \
>     $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
> cmd_ld_builtin-$(CONFIG_LTO) = \
>     $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))

Please don't.

Logic like this is substantially harder to follow than a plain if/else
construct, and clarity is of far higher importance than optimising the
line count in the build system.

This trick only works for trivial cases, and interferes with diff's when
the logic inevitably becomes less trivial.  LTO support in particular
needs a complete overhaul, but there is no way I'm going to touch that
with a barge pole until this series is in place.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:28:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:28:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAkU-0006TT-P8; Wed, 08 Apr 2020 13:28:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMAkT-0006TO-FW
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:28:09 +0000
X-Inumbo-ID: c90127a2-799c-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c90127a2-799c-11ea-9e09-bc764e2007e4;
 Wed, 08 Apr 2020 13:28:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 02CE4AF59;
 Wed,  8 Apr 2020 13:28:06 +0000 (UTC)
Subject: Re: [XEN PATCH v4 16/18] build,xsm: Fix multiple call
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-17-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <809cba94-cebf-29c6-39d5-31ec41bdbdc4@suse.com>
Date: Wed, 8 Apr 2020 15:28:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-17-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:31, Anthony PERARD wrote:
> Both script mkflask.sh and mkaccess_vector.sh generates multiple
> files. Exploits the 'multi-target pattern rule' trick to call each
> scripts only once.

Isn't this a general fix, which may even want backporting? If so,
this would better be at or near the beginning of the series.

> --- a/xen/xsm/flask/Makefile
> +++ b/xen/xsm/flask/Makefile
> @@ -26,14 +26,14 @@ mkflask := policy/mkflask.sh
>  quiet_cmd_mkflask = MKFLASK $@
>  cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND)
>  
> -$(FLASK_H_FILES): $(FLASK_H_DEPEND) $(mkflask) FORCE
> +$(patsubst include/%,\%/%,$(FLASK_H_FILES)): $(FLASK_H_DEPEND) $(mkflask) FORCE

Since what $(FLASK_H_FILES) contains is well under our control,
how about the simpler

$(subst include/,%/,$(FLASK_H_FILES)): ...

? Preferably with this and preferably with it moved ahead
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:34:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:34:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAq4-0007IT-Fe; Wed, 08 Apr 2020 13:33:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=D8Jc=5Y=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMAq4-0007IO-1n
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:33:56 +0000
X-Inumbo-ID: 97b4ae98-799d-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 97b4ae98-799d-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 13:33:55 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2B99FAE59;
 Wed,  8 Apr 2020 13:33:53 +0000 (UTC)
Subject: Re: [RFC PATCH 00/26] Runtime paravirt patching
To: Peter Zijlstra <peterz@infradead.org>,
 Ankur Arora <ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <20200408120856.GY20713@hirez.programming.kicks-ass.net>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <bcf8206d-5a41-4e6b-1832-75ba1d6367e4@suse.com>
Date: Wed, 8 Apr 2020 15:33:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200408120856.GY20713@hirez.programming.kicks-ass.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: hpa@zytor.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 x86@kernel.org, linux-kernel@vger.kernel.org,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.20 14:08, Peter Zijlstra wrote:
> On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote:
>> Mechanism: the patching itself is done using stop_machine(). That is
>> not ideal -- text_poke_stop_machine() was replaced with INT3+emulation
>> via text_poke_bp(), but I'm using this to address two issues:
>>   1) emulation in text_poke() can only easily handle a small set
>>   of instructions and this is problematic for inlined pv-ops (and see
>>   a possible alternatives use-case below.)
>>   2) paravirt patching might have inter-dependendent ops (ex.
>>   lock.queued_lock_slowpath, lock.queued_lock_unlock are paired and
>>   need to be updated atomically.)
> 
> And then you hope that the spinlock state transfers.. That is that both
> implementations agree what an unlocked spinlock looks like.
> 
> Suppose the native one was a ticket spinlock, where unlocked means 'head
> == tail' while the paravirt one is a test-and-set spinlock, where
> unlocked means 'val == 0'.
> 
> That just happens to not be the case now, but it was for a fair while.

Sure? This would mean that before spinlock-pvops are being set no lock
is allowed to be used in the kernel, because this would block the boot
time transition of the lock variant to use.

Another problem I'm seeing is that runtime pvops patching would rely on
the fact that stop_machine() isn't guarded by a spinlock.


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:35:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:35:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMArP-0007OJ-RY; Wed, 08 Apr 2020 13:35:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMArO-0007OC-UV
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:35:18 +0000
X-Inumbo-ID: c91ea858-799d-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c91ea858-799d-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 13:35:18 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A3DE0AC90;
 Wed,  8 Apr 2020 13:35:16 +0000 (UTC)
Subject: Re: [XEN PATCH v4 10/18] xen/build: use if_changed on built_in.o
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-11-anthony.perard@citrix.com>
 <072ffe9d-88c0-144f-a9ab-c83869ad34e2@suse.com>
 <71ee52de-af4a-2b1b-4080-d42af6ac6399@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <03b74c20-54bb-06dd-8020-16da4b3bf521@suse.com>
Date: Wed, 8 Apr 2020 15:35:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <71ee52de-af4a-2b1b-4080-d42af6ac6399@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.2020 15:13, Andrew Cooper wrote:
> On 08/04/2020 13:40, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -130,15 +130,24 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
>>>  c_flags += $(CFLAGS-y)
>>>  a_flags += $(CFLAGS-y) $(AFLAGS-y)
>>>  
>>> -built_in.o: $(obj-y) $(extra-y)
>>> -ifeq ($(obj-y),)
>>> -	$(CC) $(c_flags) -c -x c /dev/null -o $@
>>> -else
>>> +quiet_cmd_ld_builtin = LD      $@
>>>  ifeq ($(CONFIG_LTO),y)
>>> -	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
>>> +cmd_ld_builtin = \
>>> +    $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
>>>  else
>>> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
>>> +cmd_ld_builtin = \
>>> +    $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
>>>  endif
>> How about going yet one step further and doing away with the
>> ifeq here altogether:
>>
>> cmd_ld_builtin-y = \
>>     $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
>> cmd_ld_builtin-$(CONFIG_LTO) = \
>>     $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
> 
> Please don't.
> 
> Logic like this is substantially harder to follow than a plain if/else
> construct, and clarity is of far higher importance than optimising the
> line count in the build system.

I could maybe see the argument if the two definitions were far apart.
This suggestion isn't about line count at all, but about clarity. In
particular because of the need to use ifeq(,) rather than simple "if"
constructs, I view this list model as the better alternative in all
cases where it can be made use of.

> This trick only works for trivial cases, and interferes with diff's when
> the logic inevitably becomes less trivial.

It may, but whether it actually will can't be known until such time
as it would get touched. The suggested model may very well also be
suitable then.

Anyway, Anthony, I'm not going to insist. This is just another aspect
where we would better generally settle on the preferred style to use.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:37:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAtA-0007Vx-8q; Wed, 08 Apr 2020 13:37:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+IwF=5Y=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jMAt9-0007Vq-95
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:37:07 +0000
X-Inumbo-ID: 0a00489a-799e-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0a00489a-799e-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 13:37:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=m4Xjo1WtOaJtxjj9jlr6A8OdmVj3Yp3r3aK1VRe2/Fw=; b=nGUyarFnJF7GarI266T3emtype
 ltusAvzGAe0xJM27gGyBfcphfo9ZEfwSColsY+DROrgCoD+/NUsy8KrN/SqPvgQpPezfgk5St4spX
 NVK5xL4VAR5dCZW4A3Mh4xOeAcCk99twxy4mMc9x1aEZnDF+X2sqsLIgUVkY0aVrzY8E=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAt8-00057Z-Gg; Wed, 08 Apr 2020 13:37:06 +0000
Received: from 54-240-197-233.amazon.com ([54.240.197.233]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAt8-0005ee-6p; Wed, 08 Apr 2020 13:37:06 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 0/5] use new API for Xen page tables
Date: Wed,  8 Apr 2020 14:36:50 +0100
Message-Id: <cover.1586352238.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

This small series is basically just rewriting functions using the new
API to map and unmap PTEs. Each patch is independent.

Apart from mapping and unmapping page tables, no other functional change
intended.

---
Changed in v2:
- I kept UNMAP_DOMAIN_PAGE() for now in v2, but I if people say
  in some cases it is an overkill and unmap_domain_page() should be
  used, I am okay with that and can make the change.
- code cleanup and style fixes.
- unmap as early as possible.

Wei Liu (5):
  x86/shim: map and unmap page tables in replace_va_mapping
  x86_64/mm: map and unmap page tables in m2p_mapped
  x86_64/mm: map and unmap page tables in share_hotadd_m2p_table
  x86_64/mm: map and unmap page tables in destroy_compat_m2p_mapping
  x86_64/mm: map and unmap page tables in destroy_m2p_mapping

 xen/arch/x86/pv/shim.c     |  9 ++++---
 xen/arch/x86/x86_64/mm.c   | 55 ++++++++++++++++++++++----------------
 xen/include/asm-x86/page.h | 13 +++++++++
 3 files changed, 50 insertions(+), 27 deletions(-)

-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:37:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAtD-0007X0-LR; Wed, 08 Apr 2020 13:37:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+IwF=5Y=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jMAtB-0007WY-RF
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:37:09 +0000
X-Inumbo-ID: 0ad08a5a-799e-11ea-81eb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0ad08a5a-799e-11ea-81eb-12813bfff9fa;
 Wed, 08 Apr 2020 13:37:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=okmq5d3yLNx2nVi7NHGnb7kjUiX+Maxtj+okHFgjkpY=; b=VOUn1n2GY6f0hdKEf/6A2qCOgj
 BKfqZE9LLjSXL3He4sli5dpbintAbIw2vBdIXr61jyakVLAYqiH3YTiyirzRPySKdZXTUvlu2Pl8L
 3nE07BIcbBJBstE3JoSKcCVEuBfO4vZlHt/oRSQvfW0ax3Yzbc6765MyZ/tmaW7e6Sjs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAt9-00057f-UP; Wed, 08 Apr 2020 13:37:07 +0000
Received: from 54-240-197-233.amazon.com ([54.240.197.233]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAt9-0005ee-Ka; Wed, 08 Apr 2020 13:37:07 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 1/5] x86/shim: map and unmap page tables in
 replace_va_mapping
Date: Wed,  8 Apr 2020 14:36:51 +0100
Message-Id: <7638095024ec3379a8d9ddadfe47e36da168e4dd.1586352238.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Also, introduce lYe_from_lXe() macros which do not rely on the direct
map when walking page tables. Unfortunately, they cannot be inline
functions due to the header dependency on domain_page.h, so keep them as
macros just like map_lYt_from_lXe().

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed in v2:
- unmap as early as possible instead of unmapping all at the end.
- use lYe_from_lXe() macros and lift them from a later patch to this
  patch.
- const qualify pointers in new macros.
---
 xen/arch/x86/pv/shim.c     |  9 +++++----
 xen/include/asm-x86/page.h | 13 +++++++++++++
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index ed2ece8a8a..28d2076065 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -168,16 +168,17 @@ const struct platform_bad_page *__init pv_shim_reserved_pages(unsigned int *size
 static void __init replace_va_mapping(struct domain *d, l4_pgentry_t *l4start,
                                       unsigned long va, mfn_t mfn)
 {
-    l4_pgentry_t *pl4e = l4start + l4_table_offset(va);
-    l3_pgentry_t *pl3e = l4e_to_l3e(*pl4e) + l3_table_offset(va);
-    l2_pgentry_t *pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(va);
-    l1_pgentry_t *pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(va);
+    l4_pgentry_t l4e = l4start[l4_table_offset(va)];
+    l3_pgentry_t l3e = l3e_from_l4e(l4e, l3_table_offset(va));
+    l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(va));
+    l1_pgentry_t *pl1e = map_l1t_from_l2e(l2e) + l1_table_offset(va);
     struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e));
 
     put_page_and_type(page);
 
     *pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT
                                                       : COMPAT_L1_PROT));
+    UNMAP_DOMAIN_PAGE(pl1e);
 }
 
 static void evtchn_reserve(struct domain *d, unsigned int port)
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index c98d8f5ede..1e16f3980d 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -196,6 +196,19 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, unsigned int flags)
 #define map_l2t_from_l3e(x)        (l2_pgentry_t *)map_domain_page(l3e_get_mfn(x))
 #define map_l3t_from_l4e(x)        (l3_pgentry_t *)map_domain_page(l4e_get_mfn(x))
 
+/* Unlike lYe_to_lXe(), lXe_from_lYe() do not rely on the direct map. */
+#define l2e_from_l3e(l3e, offset) ({                        \
+        const l2_pgentry_t *l2t = map_l2t_from_l3e(l3e);    \
+        l2_pgentry_t l2e = l2t[offset];                     \
+        UNMAP_DOMAIN_PAGE(l2t);                             \
+        l2e; })
+
+#define l3e_from_l4e(l4e, offset) ({                        \
+        const l3_pgentry_t *l3t = map_l3t_from_l4e(l4e);    \
+        l3_pgentry_t l3e = l3t[offset];                     \
+        UNMAP_DOMAIN_PAGE(l3t);                             \
+        l3e; })
+
 /* Given a virtual address, get an entry offset into a page table. */
 #define l1_table_offset(a)         \
     (((a) >> L1_PAGETABLE_SHIFT) & (L1_PAGETABLE_ENTRIES - 1))
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:37:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:37:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAtH-0007Z5-UB; Wed, 08 Apr 2020 13:37:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+IwF=5Y=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jMAtG-0007Yh-RP
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:37:14 +0000
X-Inumbo-ID: 0ad08a5b-799e-11ea-81eb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0ad08a5b-799e-11ea-81eb-12813bfff9fa;
 Wed, 08 Apr 2020 13:37:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=+zFaUj7bu8w84ctYQkaYIoA6o69FZPkcrEvCQXkz0lM=; b=Y+JTz/pMmTycAmcsfr7cfN7XPO
 +rXB2rfXPGUQKdoHhd/+GNTecVhz1eVrBj+iS7YcVGRRUnyXDh7IknmC3nhqgSp9bHm1W8qimR9JT
 5uI+TZOACxCUs3cRG0JMxxln5Yl99LbITO2oEPri/MYfjag7nC6NZHHy0j3u/XYetsg0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAtB-00057k-Ba; Wed, 08 Apr 2020 13:37:09 +0000
Received: from 54-240-197-233.amazon.com ([54.240.197.233]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAtB-0005ee-1u; Wed, 08 Apr 2020 13:37:09 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 2/5] x86_64/mm: map and unmap page tables in m2p_mapped
Date: Wed,  8 Apr 2020 14:36:52 +0100
Message-Id: <e8a945defb5a4209d1f10b5f98b16a854a911c5c.1586352238.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed in v2:
- avoid adding goto labels, simply get the PTE and unmap quickly.
- code style fixes.
---
 xen/arch/x86/x86_64/mm.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index cee836ec37..8e0caa7327 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -129,14 +129,14 @@ static mfn_t alloc_hotadd_mfn(struct mem_hotadd_info *info)
 static int m2p_mapped(unsigned long spfn)
 {
     unsigned long va;
-    l3_pgentry_t *l3_ro_mpt;
-    l2_pgentry_t *l2_ro_mpt;
+    l3_pgentry_t l3e_ro_mpt;
+    l2_pgentry_t l2e_ro_mpt;
 
     va = RO_MPT_VIRT_START + spfn * sizeof(*machine_to_phys_mapping);
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
+    l3e_ro_mpt = l3e_from_l4e(idle_pg_table[l4_table_offset(va)],
+                              l3_table_offset(va));
 
-    switch ( l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
-             (_PAGE_PRESENT |_PAGE_PSE))
+    switch ( l3e_get_flags(l3e_ro_mpt) & (_PAGE_PRESENT | _PAGE_PSE) )
     {
         case _PAGE_PSE|_PAGE_PRESENT:
             return M2P_1G_MAPPED;
@@ -146,9 +146,9 @@ static int m2p_mapped(unsigned long spfn)
         default:
             return M2P_NO_MAPPED;
     }
-    l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
+    l2e_ro_mpt = l2e_from_l3e(l3e_ro_mpt, l2_table_offset(va));
 
-    if (l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT)
+    if ( l2e_get_flags(l2e_ro_mpt) & _PAGE_PRESENT )
         return M2P_2M_MAPPED;
 
     return M2P_NO_MAPPED;
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:37:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAtN-0007b8-6z; Wed, 08 Apr 2020 13:37:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+IwF=5Y=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jMAtL-0007ag-Rd
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:37:19 +0000
X-Inumbo-ID: 0c80ea34-799e-11ea-81eb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0c80ea34-799e-11ea-81eb-12813bfff9fa;
 Wed, 08 Apr 2020 13:37:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=dvAgEAJTUQsFmV9V5FW8EQm/8m/fPeE0c4VRVxGpgO8=; b=YCViXq8NbDg7s2LFuKE1ZbOwSe
 5PWb4xt0x7YgkFUYoxpdrjRQNt7NALBaJ4XcIpn7uWLFWcimvRreF2BMeCtDZmRhDX521dZEpQLoa
 pEeHV8CtcLigIlja5PbRrjZFBtzOsraGOY7jy3nTmTd4fUoecXIZImu3bk2SMNIQukTs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAtC-00057r-OY; Wed, 08 Apr 2020 13:37:10 +0000
Received: from 54-240-197-233.amazon.com ([54.240.197.233]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAtC-0005ee-FG; Wed, 08 Apr 2020 13:37:10 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 3/5] x86_64/mm: map and unmap page tables in
 share_hotadd_m2p_table
Date: Wed,  8 Apr 2020 14:36:53 +0100
Message-Id: <9bf2df7cfd65eb783afeab7d27b98b1a99233a3c.1586352238.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Fetch lYe by mapping and unmapping lXe instead of using the direct map,
which is now done via the lYe_from_lXe() helpers.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed in v2:
- the introduction of the macros is now lifted to a previous patch.
---
 xen/arch/x86/x86_64/mm.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 8e0caa7327..d23c7e4f5b 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -167,14 +167,14 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
           v += n << PAGE_SHIFT )
     {
         n = L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES;
-        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-            l3_table_offset(v)];
+        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+                           l3_table_offset(v));
         if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
             continue;
         if ( !(l3e_get_flags(l3e) & _PAGE_PSE) )
         {
             n = L1_PAGETABLE_ENTRIES;
-            l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+            l2e = l2e_from_l3e(l3e, l2_table_offset(v));
             if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
                 continue;
             m2p_start_mfn = l2e_get_mfn(l2e);
@@ -195,11 +195,11 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
           v != RDWR_COMPAT_MPT_VIRT_END;
           v += 1 << L2_PAGETABLE_SHIFT )
     {
-        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-            l3_table_offset(v)];
+        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+                           l3_table_offset(v));
         if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
             continue;
-        l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+        l2e = l2e_from_l3e(l3e, l2_table_offset(v));
         if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
             continue;
         m2p_start_mfn = l2e_get_mfn(l2e);
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:37:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:37:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAtS-0007d3-Fu; Wed, 08 Apr 2020 13:37:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+IwF=5Y=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jMAtQ-0007cS-Rl
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:37:24 +0000
X-Inumbo-ID: 0cb3f0e7-799e-11ea-81eb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0cb3f0e7-799e-11ea-81eb-12813bfff9fa;
 Wed, 08 Apr 2020 13:37:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=yTTvkNyII5BhLnC2cgeRtkKq0z4LVuvF6ZWlS86jsoM=; b=H8F6bWhl6k4TUyEYYh8V1A31Lh
 9MN86iMcWSd/slqnG3BKiB94QqaIaYKInUiyNgbeQAG26SsLuIirq3zhdrmHB6wxTaMoYumTjh3ic
 fPa0CUCwtSTTpE4gr8do7U6VnEMUIxypqY4Uw8a3MUO29pahR5SlbX7i/M60UiYdEXE0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAtE-000580-5j; Wed, 08 Apr 2020 13:37:12 +0000
Received: from 54-240-197-233.amazon.com ([54.240.197.233]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAtD-0005ee-SQ; Wed, 08 Apr 2020 13:37:12 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 4/5] x86_64/mm: map and unmap page tables in
 destroy_compat_m2p_mapping
Date: Wed,  8 Apr 2020 14:36:54 +0100
Message-Id: <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed in v2:
- there is pretty much no point in keeping l3_ro_mpt mapped, just fetch
  the l3e instead, which also cleans up the code.
---
 xen/arch/x86/x86_64/mm.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index d23c7e4f5b..ae8f4dd0b9 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -220,7 +220,7 @@ static void destroy_compat_m2p_mapping(struct mem_hotadd_info *info)
     unsigned long i, va, rwva, pt_pfn;
     unsigned long smap = info->spfn, emap = info->spfn;
 
-    l3_pgentry_t *l3_ro_mpt;
+    l3_pgentry_t l3e_ro_mpt;
     l2_pgentry_t *l2_ro_mpt;
 
     if ( smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2) )
@@ -229,11 +229,13 @@ static void destroy_compat_m2p_mapping(struct mem_hotadd_info *info)
     if ( emap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2) )
         emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
 
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(HIRO_COMPAT_MPT_VIRT_START)]);
+    l3e_ro_mpt = l3e_from_l4e(idle_pg_table[
+                                  l4_table_offset(HIRO_COMPAT_MPT_VIRT_START)],
+                              l3_table_offset(HIRO_COMPAT_MPT_VIRT_START));
 
-    ASSERT(l3e_get_flags(l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)]) & _PAGE_PRESENT);
+    ASSERT(l3e_get_flags(l3e_ro_mpt) & _PAGE_PRESENT);
 
-    l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)]);
+    l2_ro_mpt = map_l2t_from_l3e(l3e_ro_mpt);
 
     for ( i = smap; i < emap; )
     {
@@ -255,6 +257,8 @@ static void destroy_compat_m2p_mapping(struct mem_hotadd_info *info)
         i += 1UL << (L2_PAGETABLE_SHIFT - 2);
     }
 
+    UNMAP_DOMAIN_PAGE(l2_ro_mpt);
+
     return;
 }
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:37:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMAtX-0007fR-Oh; Wed, 08 Apr 2020 13:37:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+IwF=5Y=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jMAtV-0007eh-Rr
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:37:29 +0000
X-Inumbo-ID: 0e2f8bb0-799e-11ea-81eb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0e2f8bb0-799e-11ea-81eb-12813bfff9fa;
 Wed, 08 Apr 2020 13:37:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=pS3pgi5Klg6x1TQCoaRjBJz3s7LqDZEopgSLc7HSHmg=; b=nOifHnRenAwQ5G2IJdOrbzXvfv
 PljG74G9y0ObU1VAQ14wwi7J1ivQKw8Idf4P4DpJRrGKVWtg9h4n8CL5k0Eio1wUlXaHR9Iz7PzO/
 JU6k7IZjTbCvWR81csZBp6yhmbKej68ZPBCarFgq+GM1CUL4u9ZSXng1W2q+Talmqu2Y=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAtF-000587-JW; Wed, 08 Apr 2020 13:37:13 +0000
Received: from 54-240-197-233.amazon.com ([54.240.197.233]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jMAtF-0005ee-AA; Wed, 08 Apr 2020 13:37:13 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 5/5] x86_64/mm: map and unmap page tables in
 destroy_m2p_mapping
Date: Wed,  8 Apr 2020 14:36:55 +0100
Message-Id: <1f6bde6f67ef214a3d4ffa81f0c55c4416c8edd4.1586352238.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586352238.git.hongyxia@amazon.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed in v2:
- no point in re-mapping l2t because it is exactly the same as
  l2_ro_mpt.
- point l2_ro_mpt to the entry instead of doing l2_table_offset() all
  the time.
---
 xen/arch/x86/x86_64/mm.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index ae8f4dd0b9..ec5269e7fc 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -268,7 +268,8 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
     unsigned long i, va, rwva;
     unsigned long smap = info->spfn, emap = info->epfn;
 
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
+    l3_ro_mpt = map_l3t_from_l4e(
+                    idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
 
     /*
      * No need to clean m2p structure existing before the hotplug
@@ -290,26 +291,30 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
             continue;
         }
 
-        l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
-        if (!(l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT))
+        l2_ro_mpt = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]) +
+                    l2_table_offset(va);
+        if ( !(l2e_get_flags(*l2_ro_mpt) & _PAGE_PRESENT) )
         {
             i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
                     (1UL << (L2_PAGETABLE_SHIFT - 3)) ;
+            UNMAP_DOMAIN_PAGE(l2_ro_mpt);
             continue;
         }
 
-        pt_pfn = l2e_get_pfn(l2_ro_mpt[l2_table_offset(va)]);
+        pt_pfn = l2e_get_pfn(*l2_ro_mpt);
         if ( hotadd_mem_valid(pt_pfn, info) )
         {
             destroy_xen_mappings(rwva, rwva + (1UL << L2_PAGETABLE_SHIFT));
 
-            l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
-            l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_empty());
+            l2e_write(l2_ro_mpt, l2e_empty());
         }
         i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
               (1UL << (L2_PAGETABLE_SHIFT - 3));
+        UNMAP_DOMAIN_PAGE(l2_ro_mpt);
     }
 
+    UNMAP_DOMAIN_PAGE(l3_ro_mpt);
+
     destroy_compat_m2p_mapping(info);
 
     /* Brute-Force flush all TLB */
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:53:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:53:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMB8c-0001Af-6e; Wed, 08 Apr 2020 13:53:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMB8b-0001Aa-3C
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:53:05 +0000
X-Inumbo-ID: 43f69be2-79a0-11ea-81f0-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 43f69be2-79a0-11ea-81f0-12813bfff9fa;
 Wed, 08 Apr 2020 13:53:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A617FACF0;
 Wed,  8 Apr 2020 13:53:01 +0000 (UTC)
Subject: Re: [XEN PATCH v4 17/18] build, include: rework compat-build-source.py
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-18-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <57d9630d-d70e-bb20-1d8b-307d2bbc740f@suse.com>
Date: Wed, 8 Apr 2020 15:53:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-18-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:31, Anthony PERARD wrote:
> Improvement are:
> - give the path to xlat.lst as argument
> - include `grep -v` in compat-build-source.py script, we don't need to
>   write this in several scripted language.
> - have 'xlat.lst' path as a variable.

The change looks okay, but I'm unsure whether it's really worthwhile.
I specifically dislike the last point above, as it makes things less
easy to read. I might be willing to ack a patch with this part taken
out again; faod I'm not meaning to nak the patch in its current form,
but I guess I'm also not going to ack it.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:55:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMBAt-0001HP-Km; Wed, 08 Apr 2020 13:55:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMBAs-0001HK-Vn
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:55:27 +0000
X-Inumbo-ID: 98fbdd64-79a0-11ea-81f0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 98fbdd64-79a0-11ea-81f0-12813bfff9fa;
 Wed, 08 Apr 2020 13:55:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=n2hNrZ6e0wLym7CfGcohWNpsE14+Y3Lfslszfd0i+sA=; b=BIQmK9kbAwiSB5kZqxLPLJC9N
 gRRHVNIVE7ezemZm0YBhhBN4BspqIfY+x4G/VVDDNRPMY44x5LgVMK0hfR0x18Ys/SUoF/ekc+Tml
 7vVHgMQ5uy6dwt8OIFnq4ph5DVTnPUws+Yiob9QBdMl1Ki4jkKxDYQSRf7w6oyTXA6Qgw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMBAr-0005Te-Fj; Wed, 08 Apr 2020 13:55:25 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMBAq-0005ht-W6; Wed, 08 Apr 2020 13:55:25 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMBAq-0005i0-VQ; Wed, 08 Apr 2020 13:55:24 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149523-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149523: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=9be0b2747bc7381c684cfbdd3fa2e40badefbeef
X-Osstest-Versions-That: xen=e013e8514389b739153016349e49f5a78e34ddf0
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 13:55:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  9be0b2747bc7381c684cfbdd3fa2e40badefbeef
baseline version:
 xen                  e013e8514389b739153016349e49f5a78e34ddf0

Last test of basis   149499  2020-04-07 21:00:41 Z    0 days
Testing same since   149523  2020-04-08 12:00:53 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   e013e85143..9be0b2747b  9be0b2747bc7381c684cfbdd3fa2e40badefbeef -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 13:56:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 13:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMBBV-0001LZ-3j; Wed, 08 Apr 2020 13:56:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=N8iV=5Y=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMBBT-0001LO-UI
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 13:56:03 +0000
X-Inumbo-ID: af21d1c1-79a0-11ea-81f0-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id af21d1c1-79a0-11ea-81f0-12813bfff9fa;
 Wed, 08 Apr 2020 13:56:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8C20EACF0;
 Wed,  8 Apr 2020 13:56:01 +0000 (UTC)
Subject: Re: [XEN PATCH v4 18/18] build, include: rework compat-build-header.py
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-19-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7bd39b51-5dee-40f5-1524-f36aad6b7d06@suse.com>
Date: Wed, 8 Apr 2020 15:56:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331103102.1105674-19-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 12:31, Anthony PERARD wrote:
> Replace a mix of shell script and python script by all python script.
> 
> Remove the unnecessary "grep -v '^# [0-9]'". It is to hide the
> linemarkers generated by the preprocessor. But adding -P inhibit there
> generation, thus the grep isn't needed anymore.
> 
> gcc -E -P and clang -E -P have different behavior. While both don't
> generates linemarkers, gcc also removes all empty lines while clang
> keep them all. We don't need those empty lines, so we don't generates
> them in the final compat/%.h headers. (This replace `uniq` which was
> only de-duplicating empty line.)
> 
> The only changes in the final generated headers it that they don't
> have empty lines anymore.

Making them harder to read? While typically no-one needs to look at
their contents, in case of problems it helps if generated files are
half way accessible to a human as well.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 14:13:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 14:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMBS4-00036Y-As; Wed, 08 Apr 2020 14:13:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=G77i=5Y=linutronix.de=tglx@srs-us1.protection.inumbo.net>)
 id 1jMBS2-00036T-Ll
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 14:13:10 +0000
X-Inumbo-ID: 120e48c0-79a3-11ea-b4f4-bc764e2007e4
Received: from Galois.linutronix.de (unknown [2a0a:51c0:0:12e:550::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 120e48c0-79a3-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 14:13:08 +0000 (UTC)
Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11]
 helo=nanos.tec.linutronix.de)
 by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <tglx@linutronix.de>)
 id 1jMBRr-0007Ob-HA; Wed, 08 Apr 2020 16:12:59 +0200
Received: by nanos.tec.linutronix.de (Postfix, from userid 1000)
 id A83CE10069D; Wed,  8 Apr 2020 16:12:58 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Ankur Arora <ankur.a.arora@oracle.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org
Subject: Re: [RFC PATCH 00/26] Runtime paravirt patching
In-Reply-To: <20200408050323.4237-1-ankur.a.arora@oracle.com>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
Date: Wed, 08 Apr 2020 16:12:58 +0200
Message-ID: <87k12qawwl.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
 SHORTCIRCUIT=-0.0001
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Ankur Arora <ankur.a.arora@oracle.com> writes:
> A KVM host (or another hypervisor) might advertise paravirtualized
> features and optimization hints (ex KVM_HINTS_REALTIME) which might
> become stale over the lifetime of the guest. For instance, the
> host might go from being undersubscribed to being oversubscribed
> (or the other way round) and it would make sense for the guest
> switch pv-ops based on that.

If your host changes his advertised behaviour then you want to fix the
host setup or find a competent admin.

> This lockorture splat that I saw on the guest while testing this is
> indicative of the problem:
>
>   [ 1136.461522] watchdog: BUG: soft lockup - CPU#8 stuck for 22s! [lock_torture_wr:12865]
>   [ 1136.461542] CPU: 8 PID: 12865 Comm: lock_torture_wr Tainted: G W L 5.4.0-rc7+ #77
>   [ 1136.461546] RIP: 0010:native_queued_spin_lock_slowpath+0x15/0x220
>
> (Caused by an oversubscribed host but using mismatched native pv_lock_ops
> on the gues.)

And this illustrates what? The fact that you used a misconfigured setup.

> This series addresses the problem by doing paravirt switching at
> runtime.

You're not addressing the problem. Your fixing the symptom, which is
wrong to begin with.

> The alternative use-case is a runtime version of apply_alternatives()
> (not posted with this patch-set) that can be used for some safe subset
> of X86_FEATUREs. This could be useful in conjunction with the ongoing
> late microcode loading work that Mihai Carabas and others have been
> working on.

This has been discussed to death before and there is no safe subset as
long as this hasn't been resolved:

  https://lore.kernel.org/lkml/alpine.DEB.2.21.1909062237580.1902@nanos.tec.linutronix.de/

Thanks,

        tglx


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 14:27:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 14:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMBgB-000442-DC; Wed, 08 Apr 2020 14:27:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMBg9-00043x-RP
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 14:27:45 +0000
X-Inumbo-ID: 1c26fda0-79a5-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1c26fda0-79a5-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 14:27:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=z7UmB42u9W2v+5HBm2CFSIjoEC8weTry7G8OeMc/zaU=; b=iSV1PbvkRLpMSGDs67pw7d2hr
 97t7p8XzVbKCJ2t5LxJY0TwHqhUUFPj9CClhRchYLRQYWjkmYs0aLQZU/+7Jyf+8INQgNE1d2ZHlb
 VEt9ihjR83g+ZErlurB+O7m12f76mzTNq47UN3RYQYBOvMTuYsplTRu9ambJOsa4oECPE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMBg7-0006BI-G1; Wed, 08 Apr 2020 14:27:43 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMBg7-0007Y1-6w; Wed, 08 Apr 2020 14:27:43 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMBg7-0001kr-6G; Wed, 08 Apr 2020 14:27:43 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149505-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149505: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-i386-examine:reboot:fail:regression
 linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-raw:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=63bef48fd6c9d3f1ba4f0e23b4da1e007db6a3c0
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 14:27:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine       8 reboot                   fail REGR. vs. 149238
 test-amd64-i386-xl-pvshim     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-shadow     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-libvirt-xsm   7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-libvirt       7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl            7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-raw        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-xsm        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-freebsd10-i386  7 xen-boot               fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-pair         10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-pair         11 xen-boot/dst_host        fail REGR. vs. 149238

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

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

version targeted for testing:
 linux                63bef48fd6c9d3f1ba4f0e23b4da1e007db6a3c0
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    8 days
Failing since        149266  2020-04-01 03:55:53 Z    7 days   10 attempts
Testing same since   149505  2020-04-08 02:37:33 Z    0 days    1 attempts

------------------------------------------------------------
1720 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       fail    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       fail    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    fail    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 14:49:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 14:49:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMC14-0005m0-Ag; Wed, 08 Apr 2020 14:49:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LAz7=5Y=infradead.org=peterz@srs-us1.protection.inumbo.net>)
 id 1jMC12-0005lt-7D
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 14:49:20 +0000
X-Inumbo-ID: 1c04b03a-79a8-11ea-b4f4-bc764e2007e4
Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1c04b03a-79a8-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 14:49:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Transfer-Encoding
 :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:
 Sender:Reply-To:Content-ID:Content-Description;
 bh=N8ykcQQ3SOpdB5xsAT3pwV11DGg8xQH7SevAPGdtwTg=; b=YOq7ZrDsmTyGEBcCI6BSDKkjsL
 I0uT/nJsD58Z+VHPMPAHi0wRyC61w6xXBMjcZFL/2mAsz2fbtr2mmjek7SrHTS63SneNCwGwzHyPL
 S6MegKRHQ/nk/fGNaJ8Yz3jQF01jD37BeyYMXiT7eN6emnX4N2gqwsKwlbXITRiIhFb2j8OdeEA6i
 EFM6XQ1O24xEkXwi2ZPKN/MNkvCJD42WZQ91uLBB3Kz9N8eWpkQrZbjuPLmlGMfjS+qjHTXkSzn8v
 TUIi2+UWQ5UwjS0BvK/up5CVJDBsoMmz8NqwVB+LGs7/FnCAsL8VncXNigzzuY1EjQvss6OMnwXmk
 pkaGs/vw==;
Received: from j217100.upc-j.chello.nl ([24.132.217.100]
 helo=noisy.programming.kicks-ass.net)
 by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux))
 id 1jMC0r-00044L-OE; Wed, 08 Apr 2020 14:49:09 +0000
Received: from hirez.programming.kicks-ass.net
 (hirez.programming.kicks-ass.net [192.168.1.225])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 4BFC5305FB6;
 Wed,  8 Apr 2020 16:49:07 +0200 (CEST)
Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000)
 id 3E3F52BA90A66; Wed,  8 Apr 2020 16:49:07 +0200 (CEST)
Date: Wed, 8 Apr 2020 16:49:07 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
Subject: Re: [RFC PATCH 00/26] Runtime paravirt patching
Message-ID: <20200408144907.GL20730@hirez.programming.kicks-ass.net>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <20200408120856.GY20713@hirez.programming.kicks-ass.net>
 <bcf8206d-5a41-4e6b-1832-75ba1d6367e4@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <bcf8206d-5a41-4e6b-1832-75ba1d6367e4@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: hpa@zytor.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 x86@kernel.org, linux-kernel@vger.kernel.org,
 Ankur Arora <ankur.a.arora@oracle.com>,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 03:33:52PM +0200, J�rgen Gro� wrote:
> On 08.04.20 14:08, Peter Zijlstra wrote:
> > On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote:
> > > Mechanism: the patching itself is done using stop_machine(). That is
> > > not ideal -- text_poke_stop_machine() was replaced with INT3+emulation
> > > via text_poke_bp(), but I'm using this to address two issues:
> > >   1) emulation in text_poke() can only easily handle a small set
> > >   of instructions and this is problematic for inlined pv-ops (and see
> > >   a possible alternatives use-case below.)
> > >   2) paravirt patching might have inter-dependendent ops (ex.
> > >   lock.queued_lock_slowpath, lock.queued_lock_unlock are paired and
> > >   need to be updated atomically.)
> > 
> > And then you hope that the spinlock state transfers.. That is that both
> > implementations agree what an unlocked spinlock looks like.
> > 
> > Suppose the native one was a ticket spinlock, where unlocked means 'head
> > == tail' while the paravirt one is a test-and-set spinlock, where
> > unlocked means 'val == 0'.
> > 
> > That just happens to not be the case now, but it was for a fair while.
> 
> Sure? This would mean that before spinlock-pvops are being set no lock
> is allowed to be used in the kernel, because this would block the boot
> time transition of the lock variant to use.

Hurm.. true. I suppose I completely forgot how paravirt spinlocks looked
before it got rewritten.

> Another problem I'm seeing is that runtime pvops patching would rely on
> the fact that stop_machine() isn't guarded by a spinlock.

It can't be, stop_machine() relies on scheduling. But yes, that another
variation of 'stuff uses spinlocks'.


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 14:51:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 14:51:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMC3I-0006VV-Oe; Wed, 08 Apr 2020 14:51:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMC3H-0006VQ-Pf
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 14:51:39 +0000
X-Inumbo-ID: 73453b26-79a8-11ea-81fb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 73453b26-79a8-11ea-81fb-12813bfff9fa;
 Wed, 08 Apr 2020 14:51:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=TSBMarnZxPIfGwmd17wvLD3GElVlOtZ02VgHXEmW3jM=; b=do2ruf41QBJoKwj/nPf+DiJz2
 RZKq+O5gpQMtS8ZspyBm9CPVtSnsxCt6P7w7tAy+Yjn/Et7V4lj6MdABpjT4P/SvGQq30C2uCaIrb
 lwNqbAGpaWop6B3RXcHytm8sx8LsXANe9kHTTMb3/s2fQS9jNdhK6viNrHDKQgl2VflJQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMC3G-0006bd-57; Wed, 08 Apr 2020 14:51:38 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMC3F-0008Td-P2; Wed, 08 Apr 2020 14:51:37 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMC3F-0000gi-ON; Wed, 08 Apr 2020 14:51:37 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149513-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149513: all pass - PUSHED
X-Osstest-Versions-This: ovmf=d6f99b2ac4296662720db76d7c23d224f5288df3
X-Osstest-Versions-That: ovmf=3ab0dadd6618b7808a27e65d83aa3668462afcf2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 14:51:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 d6f99b2ac4296662720db76d7c23d224f5288df3
baseline version:
 ovmf                 3ab0dadd6618b7808a27e65d83aa3668462afcf2

Last test of basis   149504  2020-04-08 01:40:39 Z    0 days
Testing same since   149513  2020-04-08 07:13:07 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Guomin Jiang <guomin.jiang@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   3ab0dadd66..d6f99b2ac4  d6f99b2ac4296662720db76d7c23d224f5288df3 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 14:57:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 14:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMC8K-0006jE-DO; Wed, 08 Apr 2020 14:56:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=M0gu=5Y=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jMC8I-0006j9-P7
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 14:56:50 +0000
X-Inumbo-ID: 2cc45be0-79a9-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x531.google.com (unknown [2a00:1450:4864:20::531])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2cc45be0-79a9-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 14:56:50 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id cw6so8862687edb.9
 for <xen-devel@lists.xenproject.org>; Wed, 08 Apr 2020 07:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=w2bNjyeNbR8dDoyFIG9+onqF8z4JwEVYO6Q75i1PMZM=;
 b=SW95wqrmyF4y8WQHhmplrhdX5fZoNfOK0Laa8q5teEl3xiVDy8o5KLIIrzIBGG2r1m
 t4fGlPMZ/CshRUj+AJckuMRMqVlZy7KvQeAJMqgN9pmvvf4QevbGKZBubjHGtHNEPv8A
 FeSOCJ3mj89xFPNoaWVyGNdPUD67qFKiZhR31pNlJQCjQv+03M6zF3d8yTkiYeooc8lQ
 uwSbT8es28tFIKosC85D8O0WzAD3QB/UVOJ/nQ1FYD7Zhx6Fem9iBHQyv6wk2tkEeWwI
 IjYqaoFgmzVhTvAWAk9G5qttbEbLxM51d3jarO28i/Pgs/T75c6BpodnPUxsoMTqTnBf
 SwBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=w2bNjyeNbR8dDoyFIG9+onqF8z4JwEVYO6Q75i1PMZM=;
 b=BFyeFSBON1eE/WTYjcZZhXwZFTAgMovR42Ty8zb5fWFbyp6bAK7Ir71iWaREVHEZbK
 aToikT425M7crih+5wQecPgAO2VJG4vgtN+spH4kSePl/ZA0qJsdUBTCyqnRCXleJoNX
 oG1cs8rVIXy9LuyQRI30as29Nl5uT7NjpwslWL10jKT2D8LzlHAfIsU/Ig59BgDtYB+H
 GHosp284PU5UHdVhH2CMJpDy5cUYKzk9bzKKyvP2wqXJZKkUiFGFjfCxGBrX3auy4mM6
 V/G4S1FPESHrx5tc/FaAQshe2cGMQER7ygSCHkYE1IrzCzpEvsyUR0WcIFMOb1JHUwBa
 rE2A==
X-Gm-Message-State: AGi0PuaaS8buQl0qKWG3EJ9DnnbFyg1XqMGZwbLcXwmt8J4VR0yZItz6
 HODLWoqpgJvOg4kULfFFyfk=
X-Google-Smtp-Source: APiQypLVSpvlUPHxjdaaLBZa4OzXmNMbDhxKM1yp8xyc7mWY5FOzuOxU9Q75L4JlTNnenEXWoeZBZA==
X-Received: by 2002:a50:ef16:: with SMTP id m22mr6943938eds.82.1586357809248; 
 Wed, 08 Apr 2020 07:56:49 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id i23sm2953133edr.54.2020.04.08.07.56.48
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 08 Apr 2020 07:56:48 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Maximilian Heyne'" <mheyne@amazon.de>, <xen-devel@lists.xenproject.org>
References: <20200313123316.122003-1-mheyne@amazon.de>
 <20200313123316.122003-4-mheyne@amazon.de>
In-Reply-To: <20200313123316.122003-4-mheyne@amazon.de>
Subject: RE: [PATCH 3/3] xen: cleanup IOREQ server on exit
Date: Wed, 8 Apr 2020 15:56:47 +0100
Message-ID: <004c01d60db5$eddfff10$c99ffd30$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQGvBAjA7hxOW9V3ZNauiodGQFqJFQH4ZnISqK2Qu8A=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Ian Jackson' <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Maximilian Heyne <mheyne@amazon.de>
> Sent: 13 March 2020 12:33
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson <ian.jackson@citrix.com>; Paul Durrant <paul@xen.org>
> Subject: [PATCH 3/3] xen: cleanup IOREQ server on exit
> 
> Use the backported Notifier interface to register an atexit handler to
> cleanup the IOREQ server. This is required since Xen commit a5a180f9
> ("x86/domain: don't destroy IOREQ servers on soft reset") is introduced
> which requires Qemu to explicitly close the IOREQ server.
> 
> This is can be seen as a backport of ba7fdd64 ("xen: cleanup IOREQ
> server on exit").
> 
> Signed-off-by: Maximilian Heyne <mheyne@amazon.de>

Reviewed-by: Paul Durrant <paul@xen.org>



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 14:57:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 14:57:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMC9A-0006mM-Nw; Wed, 08 Apr 2020 14:57:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=M0gu=5Y=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jMC99-0006mD-P6
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 14:57:43 +0000
X-Inumbo-ID: 4c70981e-79a9-11ea-9e09-bc764e2007e4
Received: from mail-ed1-x52c.google.com (unknown [2a00:1450:4864:20::52c])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4c70981e-79a9-11ea-9e09-bc764e2007e4;
 Wed, 08 Apr 2020 14:57:43 +0000 (UTC)
Received: by mail-ed1-x52c.google.com with SMTP id cf14so8851489edb.13
 for <xen-devel@lists.xenproject.org>; Wed, 08 Apr 2020 07:57:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=iU9yuaCYEfkEruhBpR6BbCuUDHAUpY1V9lTjdRCjxp4=;
 b=quGFHcBOXAeiXqefIaUP3hW0kMAyU9VoW30fxwynsKKHXirq7M9FF1pgze28xA5TLO
 uiMZJjsLEg4JxbHqrOe0ruvljZLbQyCJrPBLIibGoDq7j0oo13Z7XDirf2JDupPu80fy
 xP6uBygZIshl2Pt5Q3b74dphBCaPCYuP14L/nne6qveKNME/0Of75UdLhvSxX2U8rMZb
 D/cosQBWZgYazJdjgUS1HSSX5D7EMtRfQRyQkergTJqSpWE/FlzauSz7OeEdTew8IosS
 IDYzOouU5yKcUW+A5+8uDo/w8HYK5e37uLrzT9J9w8+NyZtm/Xp9c3Eaw13SY3ML20gA
 7nGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=iU9yuaCYEfkEruhBpR6BbCuUDHAUpY1V9lTjdRCjxp4=;
 b=ly7dR1DxBPGtFaxQWlLTHzQjlC/xvzc4nJc3manF/akDRLENBO4hYE01ZumZUQJ+lo
 QRCLCHbXOGr8wpzqs6NUILLl90sBboyzYsuRo9vySOxj/ZE32V2K3eoT2ksI++wMjj5Q
 wHSKpdDWO1KjHiT/P2LJLgCu6VGu0Y/RM3E3gBul6UX6WfX2Mpj7PdcDJsFESzsfc0lr
 +ts8upion7fhnktAhpLRPqaDyFv17SCGX8b2bLfeNsusOdbPRknE0vENuUBuJ70Avy7f
 OLWD1QxmzEJa+gAtQ6pQKppQxUym8dj9ghHowHaxuCDaWmQxMD3wElWopb/54RBT6D++
 hNuw==
X-Gm-Message-State: AGi0PubAUankk9TjSsRa8zAkAYNrdjJ4JYozvUYaAxajWM580ZEfYWy3
 dSDjge7XztrZlSIk2JSijjNF4lngkQY=
X-Google-Smtp-Source: APiQypLRzwKJfYaMrc0+ovdIMO40fHh5F2dS5HTJYjip3Ql+wp0ZaGlLdLOXU6AxTYshW0F5IvFSaA==
X-Received: by 2002:a05:6402:74c:: with SMTP id
 p12mr7011533edy.138.1586357862398; 
 Wed, 08 Apr 2020 07:57:42 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.188])
 by smtp.gmail.com with ESMTPSA id f12sm2926999edw.42.2020.04.08.07.57.41
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 08 Apr 2020 07:57:41 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Maximilian Heyne'" <mheyne@amazon.de>, <xen-devel@lists.xenproject.org>
References: <20200313123316.122003-1-mheyne@amazon.de>
 <20200313123316.122003-3-mheyne@amazon.de>
In-Reply-To: <20200313123316.122003-3-mheyne@amazon.de>
Subject: RE: [PATCH 2/3] Add exit notifiers.
Date: Wed, 8 Apr 2020 15:57:40 +0100
Message-ID: <004d01d60db6$0dab56f0$290204d0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQGvBAjA7hxOW9V3ZNauiodGQFqJFQFuc8TGqLHwPvA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Ian Jackson' <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Maximilian Heyne <mheyne@amazon.de>
> Sent: 13 March 2020 12:33
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson <ian.jackson@citrix.com>; Paul Durrant <paul@xen.org>
> Subject: [PATCH 2/3] Add exit notifiers.
> 
> From: Gerd Hoffmann <kraxel@redhat.com>
> 
> Hook up any cleanup work which needs to be done here.  Advantages over
> using atexit(3):
> 
>   (1) You get passed in a pointer to the notifier.  If you embed that
>       into your state struct you can use container_of() to get get your
>       state info.
>   (2) You can unregister, say when un-plugging a device.
> 
> [ v2: move code out of #ifndef _WIN32 ]
> 
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> (cherry picked from commit fd42deeb4cb42f90084046e3ebdb4383953195e3)
> Signed-off-by: Maximilian Heyne <mheyne@amazon.de>

Reviewed-by: Paul Durrant <paul@xen.org>



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 14:58:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 14:58:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMCAK-0006uU-2s; Wed, 08 Apr 2020 14:58:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=M0gu=5Y=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jMCAI-0006uJ-8r
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 14:58:54 +0000
X-Inumbo-ID: 767b6e90-79a9-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x52d.google.com (unknown [2a00:1450:4864:20::52d])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 767b6e90-79a9-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 14:58:53 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id w26so8902382edu.7
 for <xen-devel@lists.xenproject.org>; Wed, 08 Apr 2020 07:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=suXtvA5OH/OvrDQAp9g5amE6tOxdRRZdjEbMaemYZPc=;
 b=VbFNnTR2EeykN/HOIRCIYlAL+ecmfZhClRYWOs9Xx6q9us/Iu/uz1xRKwHLBPpqi1i
 Mzs+FlLPKFpf3Lu+GYccQZ7nMTrAuzhwZUpi4Dlnn/YuxNkja+2gAO97K0SpP6Hg6Q70
 sUCxba0Kt0s24Zhs042Il915Gj/QCmI//wjuTS+kGpanTNQSPqL7wTN5fYDRvSsYsmVn
 DNmzeKBIgnEokUEB0uf3zWrmPlTxVgGnQCTynHiaO/DRFHXk8rzH85DfcwzJM92S//2/
 XvYuZp/eJr1/N+t99qZbJ7TsdX2qz1qd87VtWfEPyVbI3lwA0rXXmWQBpkcWCbOKwqul
 QtIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=suXtvA5OH/OvrDQAp9g5amE6tOxdRRZdjEbMaemYZPc=;
 b=gP5KQxq4jOSxuWqX6yu9ybtpBSGLneNNIHo/fZPg/zJxCW/lITcJ+XkNKzoYoN6IFZ
 Oheqp04Bt4QbFkUxf+MvHHQN+EO2hmjMHCzahvW4S25Ppq0z+KMo2ltf6edySNgNXXwc
 JjBEOQh993wsEY5YVZZ1z0r+vfKGKdan0wC5fVvqAHvQBK3gfkQffMU0ctcmhcmW/wve
 0rzNIDe51/4TpkFD7865sqjpzceGBv/29NxUn1m64Yus6NA2bRZ1qTYva+m/SzMSn/hE
 iqOvDk63eBbT81nFzmkHMVCnpZYwVnR3uHl+49GexSKyuyPYCX9ZFzPIvkg/XRNyK8vw
 FkpA==
X-Gm-Message-State: AGi0PuZh97a7/n2GZXisOdjS5jOoGxKJmXH3kQ8WI3UyIQmnNf+nZCXJ
 0IAQSIqcPCbWf3sA8ysribc=
X-Google-Smtp-Source: APiQypJUXjypaGch+rfihl7yi++SeC9ELa6upHhA4gng9vGt8MQj+SOC2i9z4V8emv0CeKLxFxddVg==
X-Received: by 2002:a50:cd5a:: with SMTP id d26mr6977219edj.65.1586357932991; 
 Wed, 08 Apr 2020 07:58:52 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id j11sm3484243ejk.39.2020.04.08.07.58.51
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 08 Apr 2020 07:58:52 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Maximilian Heyne'" <mheyne@amazon.de>, <xen-devel@lists.xenproject.org>
References: <20200313123316.122003-1-mheyne@amazon.de>
 <20200313123316.122003-2-mheyne@amazon.de>
In-Reply-To: <20200313123316.122003-2-mheyne@amazon.de>
Subject: RE: [PATCH 1/3] Add support for generic notifier lists
Date: Wed, 8 Apr 2020 15:58:51 +0100
Message-ID: <004e01d60db6$37bfbd50$a73f37f0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQGvBAjA7hxOW9V3ZNauiodGQFqJFQKOg3fxqKjv89A=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Ian Jackson' <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Maximilian Heyne <mheyne@amazon.de>
> Sent: 13 March 2020 12:33
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson <ian.jackson@citrix.com>; Paul Durrant <paul@xen.org>
> Subject: [PATCH 1/3] Add support for generic notifier lists
> 
> From: Anthony Liguori <aliguori@us.ibm.com>
> 
> Notifiers are data-less callbacks and a notifier list is a list of registered
> notifiers that all are interested in a particular event.
> 
> We'll use this in a few patches to implement mouse change notification.
> 
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> ---
> v1 -> v2
>  - Do not do memory allocations by placing list nodes in notifier
> 
> [cherry-picked from d1e70c5e6d1472856c52969301247fe8c3c8389d
>     conflicts: used the sys-qeue interface and added required
>     LIST_REMOVE_SAFE function to that]
> Signed-off-by: Maximilian Heyne <mheyne@amazon.de>

Reviewed-by: Paul Durrant <paul@xen.org>



From xen-devel-bounces@lists.xenproject.org Wed Apr 08 15:11:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 15:11:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMCM7-0008Uk-7K; Wed, 08 Apr 2020 15:11:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=R2Jl=5Y=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jMCM6-0008Uf-GB
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 15:11:06 +0000
X-Inumbo-ID: 2aafcacc-79ab-11ea-b58d-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2aafcacc-79ab-11ea-b58d-bc764e2007e4;
 Wed, 08 Apr 2020 15:11:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586358665;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=47sudtv4L0YN5eAfyUUWFTWPESVTDToDhDV7GhOaRlM=;
 b=TXsycODaIWXOaaDOhk4O5583pwTKfKhQzQZJd+Is03aRVNWrISGcYUPS
 4ITZ7TljbfaDpI8X+8XCj5F/Qxi6JJeoIrVB3aqhamHWx+2lkHsudtjWB
 SzDXe0A9anwU6E8MVVfwgydl5exKCn+SYlNWJGTdxFbDl6imTzd10ZOlj c=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: bPu/vWIgR6pI1yXfJ9AMTd90z7/PxywPQTwz7BHxR6exy9oXngoM0Dugf1mI6LmOIwI/OjY4Qz
 YJHjbWHtpxvWGlyD6lWm1VH7w3SLjsdbMy6nRTo+2+ru9X6+i3A0+ZlVE/tn5eGOXDaOoAXaIr
 wh7t0myf3A6JWlHKZJHsl5JKFLCbSPk59l83S1kb05wRi1lBEb8deBdo4Zncfot5jZBRKZUheK
 1TKrmdTRbT6DEdMd0IRtr2G8cygaljC18hbwz9cNAZ+Ts4HWMrwJhU0QCDIdk7TlrvJgL9nC35
 PRI=
X-SBRS: 2.7
X-MesageID: 15700857
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,359,1580792400"; d="scan'208";a="15700857"
Date: Wed, 8 Apr 2020 17:10:55 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200408151055.GB28601@Air-de-Roger>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <9c7ec98b-bd2d-4fbf-530a-2164dbbee200@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9c7ec98b-bd2d-4fbf-530a-2164dbbee200@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
> On 06.04.2020 12:57, Roger Pau Monne wrote:
> > Introduce a specific flag to request a HVM guest linear TLB flush,
> > which is an ASID/VPID tickle that forces a guest linear to guest
> > physical TLB flush for all HVM guests.
> > 
> > This was previously unconditionally done in each pre_flush call, but
> > that's not required: HVM guests not using shadow don't require linear
> > TLB flushes as Xen doesn't modify the guest page tables in that case
> > (ie: when using HAP). Note that shadow paging code already takes care
> > of issuing the necessary flushes when the shadow page tables are
> > modified.
> > 
> > In order to keep the previous behavior modify all shadow code TLB
> > flushes to also flush the guest linear to physical TLB if the guest is
> > HVM. I haven't looked at each specific shadow code TLB flush in order
> > to figure out whether it actually requires a guest TLB flush or not,
> > so there might be room for improvement in that regard.
> > 
> > Also perform ASID/VPID flushes when modifying the p2m tables as it's a
> > requirement for AMD hardware. Finally keep the flush in
> > switch_cr3_cr4, as it's not clear whether code could rely on
> > switch_cr3_cr4 also performing a guest linear TLB flush. A following
> > patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to
> > not be necessary.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> with one really minor remark:
> 
> > --- a/xen/arch/x86/mm/paging.c
> > +++ b/xen/arch/x86/mm/paging.c
> > @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d,
> >  
> >      p2m_unlock(p2m);
> >  
> > -    flush_tlb_mask(d->dirty_cpumask);
> > +    flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) |
> > +                                 FLUSH_HVM_ASID_CORE);
> 
> In cases where one case is assumed to be more likely than the other
> putting the more likely one first can be viewed as a mild hint to
> the compiler, and hence an extra ! may be warranted in an if() or
> a conditional expression. Here, however, I don't think we can
> really consider one case more likely than the other, and hence I'd
> suggest to avoid the !, flipping the other two expressions
> accordingly. I may take the liberty to adjust this while committing
> (if I'm to be the one).

That's fine, thanks. Somehow '!hap -> flush' was clearer in my mind.

Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 15:54:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 15:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMD2N-0003Pb-Ur; Wed, 08 Apr 2020 15:54:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoLl=5Y=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMD2M-0003PW-O2
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 15:54:46 +0000
X-Inumbo-ID: 445d1488-79b1-11ea-8206-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 445d1488-79b1-11ea-8206-12813bfff9fa;
 Wed, 08 Apr 2020 15:54:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ej4PkrTTsoieQ+0RiCS9IzBRl/38bJi27hslu8hkVbE=; b=CFx3QKJ9qUlRVbOWNj+zGkG8XZ
 4qlF7R3qakwEJAhnpEshakjXdpdyIq0JkJsXloLePATOup/Qy3w/y7V52nDzpIoxB7dhU/bgrPQ8q
 VseLPX0J0KZkVTvBLqObcyl6XLHtsdbZnzJAl/bALtLvUD7wBNJwpZdfwyIldhKuWcvk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMD2D-0007pI-0D; Wed, 08 Apr 2020 15:54:37 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMD2C-0006kz-P8; Wed, 08 Apr 2020 15:54:36 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <80eb22d5-a78e-3f47-5b82-4244369931a3@xen.org>
Date: Wed, 8 Apr 2020 16:54:34 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, maz@kernel.org, George.Dunlap@citrix.com,
 Wei Xu <xuwei5@hisilicon.com>, Bertrand.Marquis@arm.com,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Stefano,

On 03/04/2020 20:41, Stefano Stabellini wrote:
> On Thu, 2 Apr 2020, Julien Grall wrote:
> As you know I cannot reproduce the crash myself, I asked Peng and Wei
> for help in that. I cannot be certain Jeff's patch makes a difference,
> but looking at the code, if you open
> xen/arch/arm/vgic-v3.c:__vgic_v3_distr_common_mmio_read you can see that
> the range mistake is still there:
> 
> 
>      /* Read the active status of an IRQ via GICD/GICR is not supported */
>      case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVER):
>      case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
>          goto read_as_zero;
> 
> 
> So a GICD_ISACTIVER of any register but the first should end up hitting
> the default case:
> 
>      default:
>          printk(XENLOG_G_ERR
>                 "%pv: %s: unhandled read r%d offset %#08x\n",
>                 v, name, dabt.reg, reg);
>          return 0;
>      }
> 
> Which returns 0 (IO_ABORT).
> 
> Would you be happy to have the range fixed to be:
> 
>      case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
> 
> instead?

I don't particularly like it, but it is not going to make any difference 
for Linux < 5.4. So I am not opposed to it.

However, I am a bit worry the vGIC is still going to be a pile of hack.
So I think we should continue the discussion about making it better. 
This includes how to implement I{C, S}ACTIVER properly and what sort of 
use-cases we want to support.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 16:42:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 16:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMDlu-0007vH-Kx; Wed, 08 Apr 2020 16:41:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMDls-0007uB-L6
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 16:41:48 +0000
X-Inumbo-ID: d2150b68-79b7-11ea-8210-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d2150b68-79b7-11ea-8210-12813bfff9fa;
 Wed, 08 Apr 2020 16:41:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=GC1apgvmXLf7JCcAkktApY1fz+HhZcl2qjcCIYXm0Mk=; b=GHJwItLD08MeLFCwa4pMLz/76
 /qFwZHd9f9L5zXj6mtZDIgcUZAoXXDAYb7ueXIhv4MZIcN4VgY9vvp77ssVZa7+KUeAkSDlssSvdO
 au6Q4Yu9zqMU2iriLR+bDiALSFS5oYpY77BDzP/Ak5gUtvpeGINfaI8CqGEVQCmT9nUAo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMDlj-0000n6-LQ; Wed, 08 Apr 2020 16:41:39 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMDlj-0005cG-Cl; Wed, 08 Apr 2020 16:41:39 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMDlj-00043M-C8; Wed, 08 Apr 2020 16:41:39 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149510-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149510: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-armhf-armhf-xl-rtds:guest-stop:fail:allowable
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: qemuu=f3bac27cc1e303e1860cc55b9b6889ba39dee587
X-Osstest-Versions-That: qemuu=7697ac55fcc6178fd8fd8aa22baed13a0c8ca942
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 16:41:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds     15 guest-stop               fail REGR. vs. 144861

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

version targeted for testing:
 qemuu                f3bac27cc1e303e1860cc55b9b6889ba39dee587
baseline version:
 qemuu                7697ac55fcc6178fd8fd8aa22baed13a0c8ca942

Last test of basis   144861  2019-12-16 13:06:24 Z  114 days
Failing since        144880  2019-12-16 20:07:08 Z  113 days  326 attempts
Testing same since   149510  2020-04-08 05:00:53 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Michael S. Tsirkin" <mst@redhat.com>
  Aarushi Mehta <mehta.aaru20@gmail.com>
  Adrian Moreno <amorenoz@redhat.com>
  Adrien GRASSEIN <adrien.grassein@smile.fr>
  Alberto Garcia <berto@igalia.com>
  Aleksandar Markovic <aleksandar.m.mail@gmail.com>
  Aleksandar Markovic <amarkovic@wavecomp.com>
  Alex Bennée <alex.bennee@linaro.org>
  Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Bulekov <alxndr@bu.edu>
  Alexander Popov <alex.popov@linux.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Alexey Romko <nevilad@yahoo.com>
  Alistair Francis <alistair.francis@wdc.com>
  Alistair Francis <alistair@alistair23.me>
  Andrea Bolognani <abologna@redhat.com>
  Andreas Schwab <schwab@suse.de>
  Andrew Jeffery <andrew@aj.id.au>
  Andrew Jones <drjones@redhat.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Anton V. Boyarshinov <boyarsh@altlinux.org>
  Anup Patel <anup.patel@wdc.com>
  Aravinda Prasad <arawinda.p@gmail.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Atish Patra <atish.patra@wdc.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Babu Moger <babu.moger@amd.com>
  BALATON Zoltan <balaton@eik.bme.hu>
  Basil Salman <basil@daynix.com>
  bauerchen <bauerchen@tencent.com>
  Beata Michalska <beata.michalska@linaro.org>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bharata B Rao <bharata@linux.ibm.com>
  Bin Meng <bmeng.cn@gmail.com>
  Cameron Esfahani <dirty@apple.com>
  Carlos Santos <casantos@redhat.com>
  Cathy Zhang <cathy.zhang@intel.com>
  Changbin Du <changbin.du@gmail.com>
  Chen Qun <kuhn.chenqun@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Christophe de Dinechin <dinechin@redhat.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cleber Rosa <crosa@redhat.com>
  Clement Deschamps <clement.deschamps@greensocs.com>
  Cole Robinson <crobinso@redhat.com>
  Colin Xu <colin.xu@intel.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cohuck@redhat.com>
  Cornelia Huck <cohuck@redhat.com> #s390x
  Cédric Le Goater <clg@fr.ibm.com>
  Cédric Le Goater <clg@kaod.org>
  Damien Hedde <damien.hedde@greensocs.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Edmondson <david.edmondson@oracle.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Gibson <david@gibson.dropbear.id.au> (ppc parts)
  David Hildenbrand <david@redhat.com>
  David Vrabel <david.vrabel@nutanix.com>
  Denis Plotnikov <dplotnikov@virtuozzo.com>
  Dmitry Fleytman <dmitry.fleytman@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eiichi Tsukata <devel@etsukata.com>
  Elazar Leibovich <elazar.leibovich@oracle.com>
  Emilio G. Cota <cota@braap.org>
  Eric Auger <eric.auger@redhat.com>
  Eric Blake <eblake@redhat.com>
  Eric Ren <renzhen@linux.alibaba.com>
  Eryu Guan <eguan@linux.alibaba.com>
  Fabiano Rosas <farosas@linux.ibm.com>
  Fangrui Song <i@maskray.me>
  Felipe Franciosi <felipe@nutanix.com>
  Filip Bozuta <Filip.Bozuta@rt-rk.com>
  Finn Thain <fthain@telegraphics.com.au>
  Florian Florensa <fflorensa@online.net>
  Francisco Iglesias <francisco.iglesias@xilinx.com>
  Francisco Iglesias <frasse.iglesias@gmail.com>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
  Gavin Shan <gshan@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kurz <groug@kaod.org>
  Guenter Roeck <linux@roeck-us.net>
  Guoyi Tu <tu.guoyi@h3c.com>
  Halil Pasic <pasic@linux.ibm.com>
  Han Han <hhan@redhat.com>
  Helge Deller <deller@gmx.de>
  Hervé Poussineau <hpoussin@reactos.org>
  Heyi Guo <guoheyi@huawei.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Huacai Chen <chenhc@lemote.com>
  Igor Mammedov <imammedo@redhat.com>
  Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
  Jafar Abdi <cafer.abdi@gmail.com>
  Jaijun Chen <chenjiajun8@huawei.com>
  James Clarke <jrtc27@jrtc27.com>
  James Hogan <jhogan@kernel.org>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Kiszka <jan.kiszka@web.de>
  Janosch Frank <frankja@linux.ibm.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Andryuk <jandryuk@gmail.com>
  Jason Wang <jasowang@redhat.com>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Jens Freimann <jfreimann@redhat.com>
  Jiahui Cen <cenjiahui@huawei.com>
  Jiajun Chen <chenjiajun8@huawei.com>
  Jiaxun Yang <jiaxun.yang@flygoat.com>
  Jiufei Xue <jiufei.xue@linux.alibaba.com>
  Joe Richey <joerichey@google.com>
  Joel Stanley <joel@jms.id.au>
  Johannes Berg <johannes.berg@intel.com>
  John Arbuckle <programmingkidx@gmail.com>
  John Snow <jsnow@redhat.com>
  Josh Kunz <jkz@google.com>
  Juan Quintela <quintela@redhat.com>
  Julia Suvorova <jusual@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Jun Piao <piaojun@huawei.com>
  Kashyap Chamarthy <kchamart@redhat.com>
  Keith Packard <keithp@keithp.com>
  Keqian Zhu <zhukeqian1@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <frederic.konrad@adacore.com>
  Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
  Laszlo Ersek <lersek@redhat.com>
  Laurent Vivier <laurent@vivier.eu>
  Laurent Vivier <lvivier@redhat.com>
  Leif Lindholm <leif@nuviainc.com>
  Leonardo Bras <leonardo@ibm.com>
  Leonardo Bras <leonardo@linux.ibm.com>
  Li Feng <fengli@smartx.com>
  Li Hangjing <lihangjing@baidu.com>
  Li Qiang <liq3ea@163.com>
  Li Qiang <liq3ea@gmail.com>
  Liam Merwick <liam.merwick@oracle.com>
  Liang Yan <lyan@suse.com>
  Liran Alon <liran.alon@oracle.com>
  Lirong Yuan <yuanzi@google.com>
  Liu Bo <bo.liu@linux.alibaba.com>
  Liu Jingqi <jingqi.liu@intel.com>
  Liu Yi L <yi.l.liu@intel.com>
  Longpeng <longpeng2@huawei.com>
  Luc Michel <luc.michel@greensocs.com>
  Lukas Straub <lukasstraub2@web.de>
  Lukáš Doktor <ldoktor@redhat.com>
  Luwei Kang <luwei.kang@intel.com>
  Mahesh Salgaonkar <mahesh@linux.ibm.com>
  Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
  Marc Hartmayer <mhartmay@linux.ibm.com>
  Marc Zyngier <maz@kernel.org>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
  Marek Dolata <mkdolata@us.ibm.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Kaiser <martin@kaiser.cx>
  Masahiro Yamada <masahiroy@kernel.org>
  Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
  Matt Borgerson <contact@mborgerson.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Matthias Lüscher <lueschem@gmail.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Rolnik <mrolnik@gmail.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Micky Yun Chan (michiboo) <chanmickyyun@gmail.com>
  Micky Yun Chan <chanmickyyun@gmail.com>
  Miklos Szeredi <mszeredi@redhat.com>
  Minwoo Im <minwoo.im.dev@gmail.com>
  Miroslav Rezanina <mrezanin@redhat.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  mkdolata@us.ibm.com <mkdolata@us.ibm.com>
  Moger, Babu <Babu.Moger@amd.com>
  Nathan Chancellor <natechancellor@gmail.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Erdmann <n@nirf.de>
  Niek Linnenbank <nieklinnenbank@gmail.com>
  Nikola Pavlica <pavlica.nikola@gmail.com>
  Oksana Vohchana <ovoshcha@redhat.com>
  Palmer Dabbelt <palmer@sifive.com>
  Palmer Dabbelt <palmerdabbelt@google.com>
  Pan Nengyuan <pannengyuan@huawei.com>
  PanNengyuan <pannengyuan@huawei.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul@xen.org>
  Paul Durrant <pdurrant@amazon.com>
  Pavel Dovgalyuk <pavel.dovgaluk@gmail.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peng Tao <tao.peng@linux.alibaba.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Turschmid <peter.turschm@nutanix.com>
  Peter Wu <peter@lekensteyn.nl>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  piaojun <piaojun@huawei.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Rajnesh Kanwal <rajnesh.kanwal49@gmail.com>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Rene Stange <rsta2@o2online.de>
  Richard Henderson <richard.henderson@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Robert Foley <robert.foley@linaro.org>
  Robert Hoo <robert.hu@linux.intel.com>
  Roman Bolshakov <r.bolshakov@yadro.com>
  Roman Kapl <rka@sysgo.com>
  Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
  Salvador Fandino <salvador@qindel.com>
  Sameeh Jubran <sjubran@redhat.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Scott Cheloha <cheloha@linux.vnet.ibm.com>
  Sergio Lopez <slp@redhat.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
  ShihPo Hung <shihpo.hung@sifive.com>
  Shivaprasad G Bhat <sbhat@linux.ibm.com>
  Simon Veith <sveith@amazon.de>
  Simran Singhal <singhalsimran0@gmail.com>
  Stafford Horne <shorne@gmail.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefan Reiter <s.reiter@proxmox.com>
  Stefan Weil <sw@weilnetz.de>
  Stefano Garzarella <sgarzare@redhat.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Sunil Muthuswamy <sunilmut@microsoft.com>
  Suraj Jitindar Singh <sjitindarsingh@gmail.com>
  Sven Schnelle <svens@stackframe.org>
  Tao Xu <tao3.xu@intel.com>
  Taylor Simpson <tsimpson@quicinc.com>
  Thomas Huth <thuth@redhat.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tobias Koch <tobias.koch@nonterra.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vincent DEHORS <vincent.dehors@smile.fr>
  Vincent Fazio <vfazio@gmail.com>
  Vitaly Chikunov <vt@altlinux.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Vivek Goyal <vgoyal@redhat.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Volker Rümelin <vr_qemu@t-online.de>
  Wainer dos Santos Moschetta <wainersm@redhat.com>
  wangyong <wang.yongD@h3c.com>
  Wei Yang <richardw.yang@linux.intel.com>
  Willian Rampazzo <willianr@gmail.com>
  Willian Rampazzo <willianr@redhat.com>
  Willian Rampazzo <wrampazz@redhat.com>
  Xiang Zheng <zhengxiang9@huawei.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>
  Xiaoyao Li <xiaoyao.li@intel.com>
  Xinyu Li <precinct@mail.ustc.edu.cn>
  Yi Sun <yi.y.sun@linux.intel.com>
  Ying Fang <fangying1@huawei.com>
  Yiting Wang <yiting.wang@windriver.com>
  Yongbok Kim <yongbok.kim@mips.com>
  Yoshinori Sato <ysato@users.sourceforge.jp>
  Yu-Chen Lin <npes87184@gmail.com>
  Yu-Chen Lin <yuchenlin@synology.com>
  Yuri Benditovich <yuri.benditovich@daynix.com>
  Yury Kotov <yury-kotov@yandex-team.ru>
  Yuval Shaia <yuval.shaia.ml@gmail.com>
  Yuval Shaia <yuval.shaia@oracle.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhang Chen <chen.zhang@intel.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   7697ac55fc..f3bac27cc1  f3bac27cc1e303e1860cc55b9b6889ba39dee587 -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 19:13:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 19:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMG7w-00039f-KS; Wed, 08 Apr 2020 19:12:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=MCEd=5Y=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMG7v-00039Z-0a
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 19:12:43 +0000
X-Inumbo-ID: e7f0340c-79cc-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e7f0340c-79cc-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 19:12:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=SQU3mmwtWQQpjwkd50UQqJDRlk+XhJeACIK1tBP3yAI=; b=P4015HAMapLPuZOxcE0qxC5Ws
 e+mZ2ABC/6cQEbcEU4xYP5eFDWuavf0eTRf4IzsyJO5Vm6i6gV8eUusSO2u1+guWKI9ZAEg28Au3n
 DPedfSLS927NA0rTvNPPPAriGyr1wvRLniSh/4vxNrBBUHF2TEwcgb6nTfyetUZhAZies=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMG7n-0003ij-KJ; Wed, 08 Apr 2020 19:12:35 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMG7n-0003Dq-Bn; Wed, 08 Apr 2020 19:12:35 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMG7n-0005qW-B7; Wed, 08 Apr 2020 19:12:35 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149514-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149514: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=de850633a01fa06515a89a184d6e9769c160d932
X-Osstest-Versions-That: linux=ad13e142e024aa194016a32de8b9ba058fe9a6af
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 08 Apr 2020 19:12:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                de850633a01fa06515a89a184d6e9769c160d932
baseline version:
 linux                ad13e142e024aa194016a32de8b9ba058fe9a6af

Last test of basis   149388  2020-04-03 14:19:58 Z    5 days
Testing same since   149514  2020-04-08 07:39:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alex Deucher <alexander.deucher@amd.com>
  Alexander Usyskin <alexander.usyskin@intel.com>
  Amritha Nambiar <amritha.nambiar@intel.com>
  Andrew Morton <akpm@linux-foundation.org>
  Barry Marson <bmarson@redhat.com>
  Bibby Hsieh <bibby.hsieh@mediatek.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Chanwoo Choi <cw00.choi@samsung.com>
  Dan Carpenter <dan.carpenter@oracle.com>
  Daniel Jordan <daniel.m.jordan@oracle.com>
  David Howells <dhowells@redhat.com>
  David S. Miller <davem@davemloft.net>
  Dennis Dalessandro <dennis.dalessandro@intel.com>
  Eric Dumazet <edumazet@google.com>
  Eugene Syromiatnikov <esyr@redhat.com>
  Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
  franky.lin@broadcom.com
  Geoffrey Allott <geoffrey@allott.email>
  George Spelvin <lkml@sdf.org>
  Gerd Hoffmann <kraxel@redhat.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Guenter Roeck <linux@roeck-us.net>
  Hans de Goede <hdegoede@redhat.com>
  Herbert Xu <herbert@gondor.apana.org.au>
  James Zhu <James.Zhu@amd.com>
  Jason Gunthorpe <jgg@mellanox.com>
  Kalle Valo <kvalo@codeaurora.org>
  Keith Busch <kbusch@kernel.org>
  Kelsey Skunberg <kelsey.skunberg@gmail.com>
  Kishon Vijay Abraham I <kishon@ti.com>
  Len Brown <len.brown@intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  Luca Coelho <luciano.coelho@intel.com>
  Mario Kleiner <mario.kleiner.de@gmail.com>
  Masahiro Yamada <masahiroy@kernel.org>
  Matthew Wilcox (Oracle) <willy@infradead.org>
  Matthias Brugger <matthias.bgg@gmail.com>
  Mika Westerberg <mika.westerberg@linux.intel.com>
  Mike Marciniszyn <mike.marciniszyn@intel.com>
  Mike Snitzer <snitzer@redhat.com>
  Mordechay Goodstein <mordechay.goodstein@intel.com>
  Neal Cardwell <ncardwell@google.com>
  Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
  Prabhath Sajeepa <psajeepa@purestorage.com>
  Randy Dunlap <rdunlap@infradead.org>
  Saeed Mahameed <saeedm@mellanox.com>
  Sam Ravnborg <sam@ravnborg.org>
  Sasha Levin <sashal@kernel.org>
  Sebastian Reichel <sebastian.reichel@collabora.com>
  Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
  syzbot+b055b1a6b2b958707a21@syzkaller.appspotmail.com
  Takashi Iwai <tiwai@suse.de>
  Tariq Toukan <tariqt@mellanox.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Wolfram Sang <wsa@the-dreams.de>
  Yuchung Cheng <ycheng@google.com>
  YueHaibing <yuehaibing@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   ad13e142e024..de850633a01f  de850633a01fa06515a89a184d6e9769c160d932 -> tested/linux-5.4


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 21:43:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 21:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMITa-0006l3-6j; Wed, 08 Apr 2020 21:43:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoLl=5Y=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMITY-0006ky-D4
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 21:43:12 +0000
X-Inumbo-ID: f18b2408-79e1-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f18b2408-79e1-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 21:43:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=noqLO1n+HEk8U4fvBfhk4GrzTuofVKVFTUacRMkJtag=; b=uq0H3U7QRnJDokYNiDLzJ+coah
 gjpL2sViGxU6FIU396WxD1AVPsz2vMdaBE+ft3YbYFLcf/hXVihpjhMuFJAO0yAxNCRSHPjZ0NTzI
 OLKrsHqpcqh6/clR5WQjPH/k0D7/5VALHAUTHur039oZ0rHE33tB1af+RPOjHTCeeMbI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMITU-0006cs-Rw; Wed, 08 Apr 2020 21:43:08 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMITU-0000rp-Kp; Wed, 08 Apr 2020 21:43:08 +0000
Subject: Re: [PATCH 1/7] xen/guest_access: Add missing emacs magics
To: Jan Beulich <jbeulich@suse.com>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-2-julien@xen.org>
 <3c0afc2d-59b0-28ec-66e6-575d02a8667e@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <cec52e14-364a-cfa0-0dff-ee530eab969b@xen.org>
Date: Wed, 8 Apr 2020 22:43:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <3c0afc2d-59b0-28ec-66e6-575d02a8667e@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 07/04/2020 09:05, Jan Beulich wrote:
> On 04.04.2020 15:10, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> Add missing emacs magics for xen/guest_access.h and
>> asm-x86/guest_access.h.
>>
>> Signed-off-by: Julien Grall <jgrall@amazon.com>
> 
> I don't think these are "missing"; as per ./CODING_STYLE they're
> permitted, but not required (and I continue to question why one
> form of such a comment should be preferred over possible other
> forms other editors may support). Nevertheless, as this is in
> line with what we have elsewhere:

I can remove the "missing" words if you prefer.

> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thank you!

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 08 22:06:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Apr 2020 22:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMIpW-000059-Bi; Wed, 08 Apr 2020 22:05:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoLl=5Y=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMIpU-000054-8f
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 22:05:52 +0000
X-Inumbo-ID: 1c49039c-79e5-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1c49039c-79e5-11ea-b4f4-bc764e2007e4;
 Wed, 08 Apr 2020 22:05:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mlsQ908AR2lDN85oulzrYNoct8fWffwtlHqQYVJXvEE=; b=10WTinFDs6RUX7lb2OZfuNiK5N
 6qxaX7bPF3uaiBa3Q4qTsWc9g3mvN3ZnnaKkbhdMVhfT/x1N4duUZ6N54OMDJ4BkkNElmoSA+gRJW
 cEmh+6rKGZUteyYjCTxdEiXG60paGkuJNYnk/AaAi0WZ/LdnTDzVHkOLHnVzSD3AYCC0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMIpQ-00074U-Dg; Wed, 08 Apr 2020 22:05:48 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMIpQ-00022r-6c; Wed, 08 Apr 2020 22:05:48 +0000
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Jan Beulich <jbeulich@suse.com>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
Date: Wed, 8 Apr 2020 23:05:45 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 07/04/2020 09:14, Jan Beulich wrote:
> On 04.04.2020 15:10, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> Most of the helpers to access guest memory are implemented the same way
>> on Arm and x86. The only differences are:
>>      - guest_handle_{from, to}_param(): while on x86 XEN_GUEST_HANDLE()
>>        and XEN_GUEST_HANDLE_PARAM() are the same, they are not on Arm. It
>>        is still fine to use the Arm implementation on x86.
>>      - __clear_guest_offset(): Interestingly the prototype does not match
>>        between the x86 and Arm. However, the Arm one is bogus. So the x86
>>        implementation can be used.
>>      - guest_handle{,_subrange}_okay(): They are validly differing
>>        because Arm is only supporting auto-translated guest and therefore
>>        handles are always valid.
> 
> While I'm fine in principle with such consolidation, I'm afraid I
> really need to ask for some historical background to be added
> here. It may very well be that there's a reason for the separation
> (likely to be found in the removed ia64 or ppc ports), which may
> then provide a hint at why future ports may want to have these
> separated. If such reasons exist, I'd prefer to avoid the back and
> forth between headers. What we could do in such a case is borrow
> Linux'es asm-generic/ concept, and move the "typical"
> implementation there. (And of course if there were no noticable
> reasons for the split, the change as it is would be fine in
> general; saying so without having looked at the details of it,
> yet).

Looking at the history, ia64 and ppc used to include a common header 
called xen/xencomm.h from asm/guest_access.h.

This has now disappeared with the removal of the two ports.

Regarding future arch, the fact arm and x86 gives me some confidence we 
are unlikely going to get a new ABI for an arch. Do you see any reason to?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 00:23:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 00:23:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMKy8-0003Wv-11; Thu, 09 Apr 2020 00:22:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Jqn0=5Z=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMKy7-0003Wq-6A
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 00:22:55 +0000
X-Inumbo-ID: 3d94c547-79f8-11ea-8269-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3d94c547-79f8-11ea-8269-12813bfff9fa;
 Thu, 09 Apr 2020 00:22:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=C4j6ncZ0YSXBvlwJYJz9lCZpmf3ADWZ31HRAihdtITY=; b=2QeWwyWWaecsArzgSJw/umKF5
 GGClMb+IhYPkLELxMKRg/CzW83Xb5z5wTVpdLTmB7qYH3tL/NWAGxetm/Pf6bFjrihK5M9Gq1qVNT
 wjc7Y83HnlszajMlPd7ei8M9O8m4R/4WHtFC6KS7UpEcweyMGjSv+EQ5WPz7PIXz0DScA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMKy0-0001mV-8Z; Thu, 09 Apr 2020 00:22:48 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMKxz-0002qN-Vj; Thu, 09 Apr 2020 00:22:48 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMKxz-0003cG-VB; Thu, 09 Apr 2020 00:22:47 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149528-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149528: all pass - PUSHED
X-Osstest-Versions-This: ovmf=d4bc5378e003e53a1c76d106997cec4af46a133a
X-Osstest-Versions-That: ovmf=d6f99b2ac4296662720db76d7c23d224f5288df3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 09 Apr 2020 00:22:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

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

Last test of basis   149513  2020-04-08 07:13:07 Z    0 days
Testing same since   149528  2020-04-08 15:10:19 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laszlo Ersek <lersek@redhat.com>
  Vitaly Cheptsov <vit9696@protonmail.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   d6f99b2ac4..d4bc5378e0  d4bc5378e003e53a1c76d106997cec4af46a133a -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 01:27:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 01:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMLy5-0003Lv-3U; Thu, 09 Apr 2020 01:26:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NCxt=5Z=xilinx.com=stefanos@srs-us1.protection.inumbo.net>)
 id 1jMLy3-0003Lo-Kv
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 01:26:55 +0000
X-Inumbo-ID: 30d3970e-7a01-11ea-827d-12813bfff9fa
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (unknown
 [40.107.94.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 30d3970e-7a01-11ea-827d-12813bfff9fa;
 Thu, 09 Apr 2020 01:26:53 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=nVZeVgyqvAilg/f19R5YfwCEva8xBltPtxQaXx9pzZvuvgqoPHwXsKGqKarQSj6RPwzU4loZbOiZ5UVPnLwO5MHsgsTFe9RSPtihP2SmsdVRxJL145S4RJ5Mnoiv7git+x94uUqa7n7luruxZuRouB7Vh1oiboaEY1++bEr30XQu7aQVWUoOQ8UbgwN9TJ1CN0l5WmoHhwlKt342U5qP2bps/lhGGRG/7QEDVbVqXsJIVbukuAFkywl8RfNAFPHFU3ljvbVQy6gHIfUNr1QSyj+sIkzl/yjnt0utcrg7KNNqCexR4EZWPJl77kJVLv+S7uJhpQopnix27uGNoSoyGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=pZKETr1xPfw30uvqxW0Zvzg/Y16m7mj44aDv41twrLM=;
 b=eL7v8uk3lRynKT5uk9jdsj4PZ2F5RLeqI2mL4D5NqSEGlwvByrO8AnYWF3peEYyL/s7y2C76S4fBVsSCOVzHDw7fEws56JiJFp7WLUt5AwBYvrWG++ATfiF8+yumrVCY3v4q0MCMUt47ylJk+YjNC6hVTuMqT3ciHAa2FUpErsH+be01N81c6yQPf0f9webjHbyDTRjMs75KzmXfvg4sGZyleIvZ+9wYoTrhZRqiiiIFV+yiJwo+TEQ7n3ONATcrbzAp7X6uTl9IvVfiIJErRjtGQuAKbUFgas3gdzn+Z5qmuwbPeNTPPwM2OGaMc5YgVE+TqzAxZv+wAnoR/yd5/Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 149.199.60.83) smtp.rcpttodomain=kernel.org smtp.mailfrom=xilinx.com;
 dmarc=bestguesspass action=none header.from=xilinx.com; dkim=none (message
 not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=pZKETr1xPfw30uvqxW0Zvzg/Y16m7mj44aDv41twrLM=;
 b=gySa33Lpzgwdb1bhfq8PCrjPTvqJLy55tNF3CCiRb8HG9epQcCOfVHZrHVbD+yyOI9ilXkJkAEO+oRW91m7jfrRg+BrZ/U1UvlsTSf8DdScUDCfaDEXm8CX+DkBuXDPrzF9/wLIpPjwB9KBbrcRD3Dt3S1F/6eZNie/QLCor0T0=
Received: from CY1PR07CA0010.namprd07.prod.outlook.com
 (2a01:111:e400:c60a::20) by MWHPR02MB2335.namprd02.prod.outlook.com
 (2603:10b6:300:5b::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Thu, 9 Apr
 2020 01:26:52 +0000
Received: from CY1NAM02FT061.eop-nam02.prod.protection.outlook.com
 (2a01:111:e400:c60a:cafe::8c) by CY1PR07CA0010.outlook.office365.com
 (2a01:111:e400:c60a::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend
 Transport; Thu, 9 Apr 2020 01:26:51 +0000
Authentication-Results: spf=pass (sender IP is 149.199.60.83)
 smtp.mailfrom=xilinx.com; kernel.org; dkim=none (message not signed)
 header.d=none;kernel.org; dmarc=bestguesspass action=none
 header.from=xilinx.com;
Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
 149.199.60.83 as permitted sender) receiver=protection.outlook.com;
 client-ip=149.199.60.83; helo=xsj-pvapsmtpgw01;
Received: from xsj-pvapsmtpgw01 (149.199.60.83) by
 CY1NAM02FT061.mail.protection.outlook.com (10.152.75.30) with Microsoft SMTP
 Server id 15.20.2900.15 via Frontend Transport; Thu, 9 Apr 2020 01:26:51
 +0000
Received: from [149.199.38.66] (port=45750 helo=xsj-pvapsmtp01)
 by xsj-pvapsmtpgw01 with esmtp (Exim 4.90)
 (envelope-from <stefano.stabellini@xilinx.com>)
 id 1jMLxa-0008LI-Ru; Wed, 08 Apr 2020 18:26:26 -0700
Received: from [127.0.0.1] (helo=localhost)
 by xsj-pvapsmtp01 with smtp (Exim 4.63)
 (envelope-from <stefano.stabellini@xilinx.com>)
 id 1jMLxz-0003Nc-5U; Wed, 08 Apr 2020 18:26:51 -0700
Received: from xsj-pvapsmtp01 (smtp2.xilinx.com [149.199.38.66])
 by xsj-smtp-dlp2.xlnx.xilinx.com (8.13.8/8.13.1) with ESMTP id 0391QfTC023870; 
 Wed, 8 Apr 2020 18:26:41 -0700
Received: from [172.19.2.220] (helo=localhost)
 by xsj-pvapsmtp01 with esmtp (Exim 4.63)
 (envelope-from <stefanos@xilinx.com>)
 id 1jMLxp-0003MZ-83; Wed, 08 Apr 2020 18:26:41 -0700
Date: Wed, 8 Apr 2020 18:26:40 -0700 (PDT)
From: Stefano Stabellini <stefano.stabellini@xilinx.com>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
In-Reply-To: <057f48b7-84be-0bc5-773d-d01a79181b20@xen.org>
Message-ID: <alpine.DEB.2.21.2004081642070.28673@sstabellini-ThinkPad-T480s>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
 <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
 <057f48b7-84be-0bc5-773d-d01a79181b20@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-153681251-1586392437=:28673"
Content-ID: <alpine.DEB.2.21.2004081734160.28673@sstabellini-ThinkPad-T480s>
X-RCIS-Action: ALLOW
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.2.0.1013-23620.005
X-TM-AS-User-Approved-Sender: Yes;Yes
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:149.199.60.83; CTRY:US; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:xsj-pvapsmtpgw01; PTR:unknown-60-83.xilinx.com; CAT:NONE;
 SFTY:;
 SFS:(10009020)(4636009)(7916004)(136003)(396003)(39850400004)(346002)(376002)(46966005)(478600001)(336012)(44832011)(426003)(8936002)(5660300002)(316002)(9686003)(8676002)(6916009)(186003)(33964004)(9786002)(33716001)(47076004)(82740400003)(2906002)(356004)(70586007)(81166007)(70206006)(26005)(54906003)(4326008)(81156014);
 DIR:OUT; SFP:1101; 
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e30524be-d0f8-435c-ecca-08d7dc2514a8
X-MS-TrafficTypeDiagnostic: MWHPR02MB2335:
X-Microsoft-Antispam-PRVS: <MWHPR02MB23350A2EE89CEE9B50E360FBA0C10@MWHPR02MB2335.namprd02.prod.outlook.com>
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0368E78B5B
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: OkBVunBpazyWDq/xqEzj0J5crpzutK7+86jUAppV1aXGGwZULaWEJc2D0H+ZJnt0eqGvVjChrsCCXun6rp76z2RvjjQrrXGptc62NEe35vMotOW6LELBAJ314EnitV4sAaVEGirboagO5BR93B4pU9o7Z/eQpfqlmWGBn0tsd+gAaBSuDLQcZP3ySooMCNd7UQ05TC7sqcKOzdqDWuUk2JjJvjk+BnyB4nYdBjgMJXzITcwtjLgGxfpMILTkt6hDZfrf269NSzHZBo+C9AEoCqDTkzcJeG2d7OewehT8a0IqK/aMGwDivmvwPRXS9moXSA6xjsx1ygVotBTYxjtvb8+Hh7eZRgoNmGqyj1Vvt7v05e8INZrNcWNmLbwiTyYHDDC5UFVKT22hYUDNqDKKnsJOz0jRl6Y+KLiCZZrnfGE51Mj0WOxgGW7YygeSXeyBBSj6XexuFzaFLS9zwIkzYKNt0GAoLQK7BDvM9eejgJT9ftGAlriQJbvNC9gXeRtlhYzkZSlQZr2asMLvrtKTPA==
X-OriginatorOrg: xilinx.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2020 01:26:51.4590 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e30524be-d0f8-435c-ecca-08d7dc2514a8
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.60.83];
 Helo=[xsj-pvapsmtpgw01]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2335
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, George Dunlap <George.Dunlap@citrix.com>,
 Wei Xu <xuwei5@hisilicon.com>, Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-153681251-1586392437=:28673
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.21.2004081734161.28673@sstabellini-ThinkPad-T480s>

On Tue, 7 Apr 2020, Julien Grall wrote:
> > > > I don=E2=80=99t know what maintenance IRQs are, but if they only ha=
ppen
> > > > intermittently, it=E2=80=99s possible that you=E2=80=99d never get =
more than a single
> > > > one in a latency-critical IRQ routine; and as such, the variatibili=
ty in
> > > > execution time (jitter) wouldn=E2=80=99t be an issue in practice.  =
But every
> > > > time you add a new unblockable IPI, you increase this jitter;
> > > > particularly if this unblockable IPI might be repeated an arbitrary
> > > > number of times.
> > > > (Stefano, let me know if I=E2=80=99ve misunderstood something.)
> > > > So stepping back a moment, here=E2=80=99s all the possible ideas th=
at I think
> > > > have been discussed (or are there implicitly) so far.
> > > > 1. [Default] Do nothing; guests using this register continue crashi=
ng
> > > > 2. Make the I?ACTIVER registers RZWI.
> > > > 3. Make I?ACTIVER return the most recent known value; i.e. KVM=E2=
=80=99s current
> > > > behavior (as far as we understand it)
> > > > 4. Use a simple IPI with do_noop to update I?ACTIVER
> > > > 4a.  Use an IPI, but come up with clever tricks to avoid interrupti=
ng
> > > > guests handling IRQs.
> > > > 5. Trap to Xen on guest EOI, so that we know when the
> > > > 6. Some clever paravirtualized option
> > >=20
> > > 7. Use an IPI if we are confident the interrupts may be active.
> >=20
> > I don=E2=80=99t understand this one.  How is it different than 4 or 4a?=
  And in
> > particular, how does it evaluate on the =E2=80=9Chow much additional de=
sign work
> > would it take=E2=80=9D criteria?
>=20
> Let me start with, if we want to have a vGIC to rule them all, then I am
> afraid you are going to have to compromise. We can discuss about tailorin=
g the
> vGIC but I think before that we need a vGIC that is faithfull with the sp=
ec
> (e.g differentiating level vs edge interrupts, handling activer...). Note=
 that
> Arm spent some effort to get a new vGIC merged but this was never made a =
first
> class citizen.
>=20
> However, even if you tailor the vGIC, you are not going to be able to avo=
id
> IPI in some occasions. This would happen when using event channels, in-gu=
est
> IPI... Another example is when enabling an interrupt, although I realize =
that
> our vGIC does not do it today meaning that a pending interrupt while disa=
bled
> will not be forwarded until the vCPU exit.
>=20
> Furthermore, implementing a write to I{C,S}ACTIVER (to activate/de-activa=
te)
> is going to be very difficult (to not say impossible) to do without IPI.
>=20
> If you are worry about a vCPU been interrupted in critical section, then =
I
> think you should tailor your guest to avoid using those registers.

Let's call it option 8 "tell the user that she needs to modify her
kernel."


> An alternative would be to use spinlock/mutex within the code to prevent =
a
> VCPU to access the vGIC registers while another vCPU don't want to be
> interrupted.
>=20
> Regarding, 4a. The only way I could think of would be to trap the instruc=
tions
> that mask/unmask interrupts. If I read correctly the Armv8 spec, it is no=
t
> possible to do it.
>=20
> 7. is basically 4.a the goal would be to avoid interrupts the vCPU has mu=
ch as
> possible but you may be wrong sometimes. Obviously we want to be correct =
most
> of the times.
>
> I understand this may not be the ideal solution, but this is probably the=
 best
> we could come with and does not involve a lot of work because we have alr=
eady
> all the information in place (we know when an interrupt was injected to a
> vCPU).
>=20
> The next best solution is to prevent in your guest to modify some registe=
rs of
> the vGIC at the same time as another vCPU is in a critical section.

Let's call this option 9.


I am just thinking out loud here :)


- 2 "Make the I?ACTIVER registers RZWI"

  As far as I can tell it should prevent the livelock because it would
  never return an ACTIVE state. It could be improved by returning the
  latest ACTIVE information for local interrupts and returning zero for
  interrupts routed to other pcpus. Not perfect but an option.


- 5 "maintenance interrupt"

  This is good for jitter sensitive guests but not the best for the
  others. We could enable it conditionally: enable maintenance
  interrupts only for certain vcpus/pcpus but it is not great to have to
  make this kind of difference in the implementation. However, it is
  possible. Let's see if we can come up with something better.


- 7 "optimized IPI"
=20
  A tiny chance of causing issues. Let's see if we can come up with
  anything better.


- 8 "tell the user to fix modify the kernel"

  We could do it in addition to 7. The issue is really how we do it.
  A warning message if DEBUG && if sched=3D=3Dnull? That doesn't sound
  right. We could introduce a new nojitter=3Dtrue command line option for
  Xen? It wouldn't really change the behavior of Xen, but it would
  enable this warning. Or, it could enable the warning and also switch
  the implementation of I?ACTIVER to option 2.


- 9 "prevent I?ACTIVER during critical sections"

  This could be good but I have a difficult time thinking of how we
  could implement it. How do we tell that the other vcpu is in or out of
  the critical section?

  (I was brainstorming a way to re-enable trapping the idling
  instruction WFI temporarily so that the other vcpu would definitely
  trap into Xen again when it is out of the critical section. But it
  doesn't seem possible from the spec.)
--8323329-153681251-1586392437=:28673--


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 02:15:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 02:15:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMMiu-00080A-52; Thu, 09 Apr 2020 02:15:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JlmV=5Z=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jMMit-000805-Do
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 02:15:19 +0000
X-Inumbo-ID: f4d98282-7a07-11ea-83d8-bc764e2007e4
Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f4d98282-7a07-11ea-83d8-bc764e2007e4;
 Thu, 09 Apr 2020 02:15:18 +0000 (UTC)
Received: by mail-ed1-x542.google.com with SMTP id de14so11346394edb.4
 for <xen-devel@lists.xenproject.org>; Wed, 08 Apr 2020 19:15:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=g/ZTzRBMT/z8axlNjU2tqX/Vh8WlckNT6HnenloXRvY=;
 b=P/ViD9F7phyD9N1INX7lCreWwcWtU6+kttvpJHay3n71amr2IgboOUc1VJc4xZqUDX
 o5jGKbbRL/ofwzUrd1FMCgIA1ZPQRpNlhvmuhVqqOb1ubYHwLTQwPIFpT7dmNfALDqkj
 /wt4z+UBzDdDgMSZhCkSZs7/cesgq4ATH51omt/vTxSZdRd9XosZgfpwL+6E9HustzSO
 0X/IGzwi81DI6fs7dNNKhdJiWa4MNVSruE5oCOJDmbSeHJt0YSokJDVU7uI4IZgAEvCy
 O/3pvVJgRehiL9L7sUvREL1G1vpVqMwTFZ2bwuWkzz+saFz/xFCluSd/wIEeFLQVR5UE
 1yVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=g/ZTzRBMT/z8axlNjU2tqX/Vh8WlckNT6HnenloXRvY=;
 b=R7GIAUFg8KDPeqRXmPhhCz0HdOzKUoKbzbqvAaYZtTBPJ/t1ctLwvMXRoAgeakfV18
 IxPnjFa9ereqZbrFgmKq7Vn6MPzK5sd9NNyCjXYDRph29pM1KWYehL0Q0GlPU2vAk/EN
 sQzcnqK8wbdqs4qfsPeW7kuJX576vtRIsZsSSqmVPFpefrPGdqTM2oZkXliisb0wZWpx
 1bGY1vJ/A44tW2VbsYA5ta1cZrpgaXPocKlPEggEciRIZl7HL8ofKv7qegXi/6jICZ7K
 uoWka6jho1AFML8RYfIrv6q0lPU4Bkr2BN+zV+qcdv5e/3YlPP+VPqvxG36krGfTvXGD
 Fp8A==
X-Gm-Message-State: AGi0PuY3Iym7DRQADU9hYdOrHqzaNOiHYWJpVH/abdE8xbU8InwCOReE
 nPWVNuItsKaZIcLu0Rl0jRwyPWnnBK4=
X-Google-Smtp-Source: APiQypLVi9swsaQcLypLzsuZQi5Qwsxp0hyNHRga+PVQfsea/UE+0DX4aIyVw2a747eElbXdtsaLAw==
X-Received: by 2002:a17:906:eb98:: with SMTP id
 mh24mr9092222ejb.375.1586398517162; 
 Wed, 08 Apr 2020 19:15:17 -0700 (PDT)
Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com.
 [209.85.221.42])
 by smtp.gmail.com with ESMTPSA id c19sm2868439ejd.48.2020.04.08.19.15.15
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Apr 2020 19:15:15 -0700 (PDT)
Received: by mail-wr1-f42.google.com with SMTP id w10so10032829wrm.4
 for <xen-devel@lists.xenproject.org>; Wed, 08 Apr 2020 19:15:15 -0700 (PDT)
X-Received: by 2002:adf:ea06:: with SMTP id q6mr8725001wrm.301.1586398515103; 
 Wed, 08 Apr 2020 19:15:15 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1586185752.git.tamas.lengyel@intel.com>
 <3dcb79f6-7d90-ced1-51d4-f5b6a32a64e9@suse.com>
In-Reply-To: <3dcb79f6-7d90-ced1-51d4-f5b6a32a64e9@suse.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Wed, 8 Apr 2020 20:14:38 -0600
X-Gmail-Original-Message-ID: <CABfawhmyvx04+CTPaDaKXN4vuSJw8t2gx9ow3ZFhv5A62Ue4Jg@mail.gmail.com>
Message-ID: <CABfawhmyvx04+CTPaDaKXN4vuSJw8t2gx9ow3ZFhv5A62Ue4Jg@mail.gmail.com>
Subject: Re: [PATCH v14 0/3] VM forking
To: Jan Beulich <jbeulich@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 8, 2020 at 5:15 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 06.04.2020 17:20, Tamas K Lengyel wrote:
> > The following series implements VM forking for Intel HVM guests to allow for
> > the fast creation of identical VMs without the assosciated high startup costs
> > of booting or restoring the VM from a savefile.
> >
> > JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
> >
> > The fork operation is implemented as part of the "xl fork-vm" command:
> >     xl fork-vm -C <config> -Q <qemu-save-file> -m <max-vcpus> <parent_domid>
> >
> > By default a fully functional fork is created. The user is in charge however to
> > create the appropriate config file for the fork and to generate the QEMU save
> > file before the fork-vm call is made. The config file needs to give the
> > fork a new name at minimum but other settings may also require changes. Certain
> > settings in the config file of both the parent and the fork have to be set to
> > default. Details are documented.
> >
> > The interface also allows to split the forking into two steps:
> >     xl fork-vm --launch-dm no \
> >                -m <max-vcpus> \
> >                -p <parent_domid>
> >     xl fork-vm --launch-dm late \
> >                -C <config_file_for_fork> \
> >                -Q <qemu_save_file> \
> >                <fork_domid>
> >
> > The split creation model is useful when the VM needs to be created as fast as
> > possible. The forked VM can be unpaused without the device model being launched
> > to be monitored and accessed via VMI. Note however that without its device
> > model running (depending on what is executing in the VM) it is bound to
> > misbehave or even crash when its trying to access devices that would be
> > emulated by QEMU. We anticipate that for certain use-cases this would be an
> > acceptable situation, in case for example when fuzzing is performed of code
> > segments that don't access such devices.
> >
> > Launching the device model requires the QEMU Xen savefile to be generated
> > manually from the parent VM. This can be accomplished simply by connecting to
> > its QMP socket and issuing the "xen-save-devices-state" command. For example
> > using the standard tool socat these commands can be used to generate the file:
> >     socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-<parent_domid>
> >     { "execute": "qmp_capabilities" }
> >     { "execute": "xen-save-devices-state", \
> >         "arguments": { "filename": "/path/to/save/qemu_state", \
> >                         "live": false} }
> >
> > At runtime the forked VM starts running with an empty p2m which gets lazily
> > populated when the VM generates EPT faults, similar to how altp2m views are
> > populated. If the memory access is a read-only access, the p2m entry is
> > populated with a memory shared entry with its parent. For write memory accesses
> > or in case memory sharing wasn't possible (for example in case a reference is
> > held by a third party), a new page is allocated and the page contents are
> > copied over from the parent VM. Forks can be further forked if needed, thus
> > allowing for further memory savings.
> >
> > A VM fork reset hypercall is also added that allows the fork to be reset to the
> > state it was just after a fork, also accessible via xl:
> >     xl fork-vm --fork-reset -p <fork_domid>
> >
> > This is an optimization for cases where the forks are very short-lived and run
> > without a device model, so resetting saves some time compared to creating a
> > brand new fork provided the fork has not aquired a lot of memory. If the fork
> > has a lot of memory deduplicated it is likely going to be faster to create a
> > new fork from scratch and asynchronously destroying the old one.
> >
> > The series has been tested with Windows VMs and functions as expected. Linux
> > VMs when forked from a running VM will have a frozen VNC screen. Linux VMs at
> > this time can only be forked with a working device model when the parent VM was
> > restored from a snapshot using "xl restore -p". This is a known limitation.
> > Also note that PVHVM/PVH Linux guests have not been tested. Forking most likely
> > works but PV devices and drivers would require additional wiring to set things
> > up properly since the guests are unaware of the forking taking place, unlike
> > the save/restore routine where the guest is made aware of the procedure.
> >
> > Forking time has been measured to be 0.0007s, device model launch to be around
> > 1s depending largely on the number of devices being emulated. Fork resets have
> > been measured to be 0.0001s under the optimal circumstances.
> >
> > New in v14:
> >     minor adjustments
> >
> > Patch 1 implements the VM fork
> > Patch 2 implements fork reset operation
> > Patch 3 adds the toolstack-side code implementing VM forking and reset
> >
> > Tamas K Lengyel (3):
> >   xen/mem_sharing: VM forking
> >   x86/mem_sharing: reset a fork
>
> I've applied these two, but ...
>
> >   xen/tools: VM forking toolstack side
>
> ... since this one doesn't have any ack or alike I'll defer to
> the tool stack maintainers here.
>

Thanks! I haven't got much feedback on the toolstack side in a while
now. We had a discussion on the design of the xl interface early on
but that was about it. Hopefully the tool stack maintainers get a
chance to look at it and get it merged now that the hypervisor side is
done.

Tamas


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 02:31:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 02:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMMxy-0001JC-Vv; Thu, 09 Apr 2020 02:30:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Jqn0=5Z=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMMxw-0001J7-Sq
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 02:30:52 +0000
X-Inumbo-ID: 20f1d804-7a0a-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 20f1d804-7a0a-11ea-9e09-bc764e2007e4;
 Thu, 09 Apr 2020 02:30:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=DzDtLI7lTIhIY3k5hrh0qCjJtadVMlZM/j4+ZynCNGU=; b=x5cF3bgqbrY51noJ4xILjQ53w
 r3/ieWIza4Wyeu+IY1WnJsmYECVd4YdMuh/UffAl1G0vXWXKlP70OgN9gW4/WkmRK+NjJdoQ6EiZX
 GcuAVAXpYURuECy3vUOY5KfTRtreqIjSZT/zvG0hYk/LzszGMX54OYVhEV21T78NAayyI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMMxu-0000dd-MK; Thu, 09 Apr 2020 02:30:50 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMMxt-0005yV-RG; Thu, 09 Apr 2020 02:30:50 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMMxt-0002pP-Pq; Thu, 09 Apr 2020 02:30:49 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149520-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149520: regressions - FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:guest-saverestore:fail:regression
 xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:debian-hvm-install:fail:heisenbug
 xen-unstable:test-armhf-armhf-xl-vhd:leak-check/check:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=e013e8514389b739153016349e49f5a78e34ddf0
X-Osstest-Versions-That: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 09 Apr 2020 02:30:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail in 149502 pass in 149520
 test-armhf-armhf-xl-vhd      18 leak-check/check           fail pass in 149502

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149431
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149478
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149478
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149478
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149478
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149478
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149478
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149478
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149478
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149478
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  e013e8514389b739153016349e49f5a78e34ddf0
baseline version:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd

Last test of basis   149478  2020-04-07 01:51:22 Z    2 days
Testing same since   149502  2020-04-08 00:06:59 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Juergen Gross <jgross@suse.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        fail    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      fail    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit e013e8514389b739153016349e49f5a78e34ddf0
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Apr 7 15:48:31 2020 +0200

    config: use mini-os master for unstable
    
    We haven't used mini-os master for about 2 years now due to a stubdom
    test failing [1]. Booting a guest with mini-os master used for building
    stubdom didn't reveal any problem, so use master for unstable in order
    to let OSStest find any problems not showing up in the local test.
    
    [1]: https://lists.xen.org/archives/html/minios-devel/2018-04/msg00015.html
    
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Acked-by: Wei Liu <wl@xen.org>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 03:13:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 03:13:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMNdX-0004dR-HG; Thu, 09 Apr 2020 03:13:51 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Jqn0=5Z=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMNdW-0004dM-Tc
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 03:13:50 +0000
X-Inumbo-ID: 20e806ca-7a10-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 20e806ca-7a10-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 03:13:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Message-Id:Subject:To:Sender:
 Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=bMbmW2CtEZNJ/q4HXbs2j3iEtrCdPx60GPua4ozWe4Q=; b=QzcGfpm1RU1JK/WI3fSp1di5pU
 /C9W7V+qQFTnRl61nzdWnYrFIb1IL3iU+L8x6BHhzFSDwZG6C5c60rPOU2clipazexDS4d/n/qWlS
 evIaOnDcm/ulmoYm1MDxzrcMHq5iyQBb0r1pRlkWyR0tCq1sTzyd7wf8opn+YFc8YxkM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMNdT-0001Sj-I5; Thu, 09 Apr 2020 03:13:47 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMNdT-0007i4-5t; Thu, 09 Apr 2020 03:13:47 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMNdT-00020X-5L; Thu, 09 Apr 2020 03:13:47 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Subject: [linux-linus bisection] complete test-amd64-i386-xl-pvshim
Message-Id: <E1jMNdT-00020X-5L@osstest.test-lab.xenproject.org>
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 09 Apr 2020 03:13:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-pvshim
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  6cd3d4019ba3f45aa1a87e4e914e81d367b59937
  Bug not present: 0adb8bc0391f1fa7820529c0200fb0c4912fe365
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149546/


  commit 6cd3d4019ba3f45aa1a87e4e914e81d367b59937
  Merge: 0adb8bc0391f c3881eb58d56
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Apr 3 12:51:46 2020 -0700
  
      Merge tag 'for-linus-5.7-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
      
      Pull xen updates from Juergen Gross:
      
       - a cleanup patch removing an unused function
      
       - a small fix for the xen pciback driver
      
       - a series for making the unwinder hyppay with the Xen PV guest idle
         task stacks
      
      * tag 'for-linus-5.7-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
        x86/xen: Make the secondary CPU idle tasks reliable
        x86/xen: Make the boot CPU idle task reliable
        xen-pciback: fix INTERRUPT_TYPE_* defines
        xen/xenbus: remove unused xenbus_map_ring()
  
  commit c3881eb58d56116c79ac4ee4f40fd15ead124c4b
  Author: Miroslav Benes <mbenes@suse.cz>
  Date:   Thu Mar 26 10:26:03 2020 +0100
  
      x86/xen: Make the secondary CPU idle tasks reliable
      
      The unwinder reports the secondary CPU idle tasks' stack on XEN PV as
      unreliable, which affects at least live patching.
      cpu_initialize_context() sets up the context of the CPU through
      VCPUOP_initialise hypercall. After it is woken up, the idle task starts
      in cpu_bringup_and_idle() function and its stack starts at the offset
      right below pt_regs. The unwinder correctly detects the end of stack
      there but it is confused by NULL return address in the last frame.
      
      Introduce a wrapper in assembly, which just calls
      cpu_bringup_and_idle(). The return address is thus pushed on the stack
      and the wrapper contains the annotation hint for the unwinder regarding
      the stack state.
      
      Signed-off-by: Miroslav Benes <mbenes@suse.cz>
      Reviewed-by: Juergen Gross <jgross@suse.com>
      Signed-off-by: Juergen Gross <jgross@suse.com>
  
  commit 2f62f36e62daec43aa7b9633ef7f18e042a80bed
  Author: Miroslav Benes <mbenes@suse.cz>
  Date:   Thu Mar 26 10:26:02 2020 +0100
  
      x86/xen: Make the boot CPU idle task reliable
      
      The unwinder reports the boot CPU idle task's stack on XEN PV as
      unreliable, which affects at least live patching. There are two reasons
      for this. First, the task does not follow the x86 convention that its
      stack starts at the offset right below saved pt_regs. It allows the
      unwinder to easily detect the end of the stack and verify it. Second,
      startup_xen() function does not store the return address before jumping
      to xen_start_kernel() which confuses the unwinder.
      
      Amend both issues by moving the starting point of initial stack in
      startup_xen() and storing the return address before the jump, which is
      exactly what call instruction does.
      
      Signed-off-by: Miroslav Benes <mbenes@suse.cz>
      Reviewed-by: Juergen Gross <jgross@suse.com>
      Signed-off-by: Juergen Gross <jgross@suse.com>
  
  commit 69086bd698574501a59073b07b629f2a00b82552
  Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Date:   Fri Mar 20 04:09:18 2020 +0100
  
      xen-pciback: fix INTERRUPT_TYPE_* defines
      
      xen_pcibk_get_interrupt_type() assumes INTERRUPT_TYPE_NONE being 0
      (initialize ret to 0 and return as INTERRUPT_TYPE_NONE).
      Fix the definition to make INTERRUPT_TYPE_NONE really 0, and also shift
      other values to not leave holes.
      But also, do not assume INTERRUPT_TYPE_NONE being 0 anymore to avoid
      similar confusions in the future.
      
      Fixes: 476878e4b2be ("xen-pciback: optionally allow interrupt enable flag writes")
      Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
      Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
      Signed-off-by: Juergen Gross <jgross@suse.com>
  
  commit b28089a7ad9d07b1b35e2b781a66a200f8b8e20d
  Author: Juergen Gross <jgross@suse.com>
  Date:   Mon Mar 9 16:54:41 2020 +0100
  
      xen/xenbus: remove unused xenbus_map_ring()
      
      xenbus_map_ring() is used nowhere in the tree, remove it.
      xenbus_unmap_ring() is used only locally, so make it static and move it
      up.
      
      Signed-off-by: Juergen Gross <jgross@suse.com>
      Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: Juergen Gross <jgross@suse.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-pvshim.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-pvshim.xen-boot --summary-out=tmp/149546.bisection-summary --basis-template=149238 --blessings=real,real-bisect linux-linus test-amd64-i386-xl-pvshim xen-boot
Searching for failure / basis pass:
 149505 fail [host=huxelrebe0] / 149386 ok.
Failure / basis pass flights: 149505 / 149386
(tree with no url: minios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 63bef48fd6c9d3f1ba4f0e23b4da1e007db6a3c0 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9bb1f080c45f7253f9270662d55865a8718cebc8 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
Basis pass bef7b2a7be28638770972ab2709adf11d601c11a c530a75c1e6a472b0eb9558310b518f0dfcd8860 4deef2d865efdc61d1a53ad7bd48f9dd42560b45 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 e19b4b3b55f84e0cfcc02fe5d66965969a81c965
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#bef7b2a7be28638770972ab2709adf11d601c11a-63bef48fd6c9d3f1ba4f0e23b4da1e007db6a3c0 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#4deef2d865efdc61d1a53ad7bd48f9dd42560b45-9bb1f080c45f7253f9270662d55865a8718cebc8 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#6a3b59ab9c7dc00331c21346052dfa6a0df45aa3-6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 git://xenbits.xen.org/xen.git#e19b4b3b55f84e0cfcc02fe5d66965969a81c965-990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
Loaded 3077437 nodes in revision graph
Searching for test results:
 149386 pass bef7b2a7be28638770972ab2709adf11d601c11a c530a75c1e6a472b0eb9558310b518f0dfcd8860 4deef2d865efdc61d1a53ad7bd48f9dd42560b45 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 e19b4b3b55f84e0cfcc02fe5d66965969a81c965
 149480 fail 7e63420847ae5f1036e4f7c42f0b3282e73efbc2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ee026ea78b0e32a9ffbaf0040afe91de8ae2179c d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149516 pass bef7b2a7be28638770972ab2709adf11d601c11a c530a75c1e6a472b0eb9558310b518f0dfcd8860 0a44fd316537573247a7576101e5ae5e8dc5e73c d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 bb2a34fd740e9a26be9e2244f1a5b4cef439e5a8
 149536 pass d8836005236425cf3cfcc8967abd1d5c21f607f8 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 6b8836aa65947e58ba2b58573cece03754ad68f6
 149505 fail 63bef48fd6c9d3f1ba4f0e23b4da1e007db6a3c0 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9bb1f080c45f7253f9270662d55865a8718cebc8 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149538 pass 0adb8bc0391f1fa7820529c0200fb0c4912fe365 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149518 fail 854e80bcfdafb8d99d308e21798cd0116338783d c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149540 fail 6cd3d4019ba3f45aa1a87e4e914e81d367b59937 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149524 fail 63bef48fd6c9d3f1ba4f0e23b4da1e007db6a3c0 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9bb1f080c45f7253f9270662d55865a8718cebc8 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149506 pass bef7b2a7be28638770972ab2709adf11d601c11a c530a75c1e6a472b0eb9558310b518f0dfcd8860 4deef2d865efdc61d1a53ad7bd48f9dd42560b45 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 e19b4b3b55f84e0cfcc02fe5d66965969a81c965
 149511 fail 7e63420847ae5f1036e4f7c42f0b3282e73efbc2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ee026ea78b0e32a9ffbaf0040afe91de8ae2179c d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149542 pass 0adb8bc0391f1fa7820529c0200fb0c4912fe365 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149526 pass d8836005236425cf3cfcc8967abd1d5c21f607f8 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 c81fb4e4a35cbee4f373387c4ed527676f6dc4b1
 149543 fail 6cd3d4019ba3f45aa1a87e4e914e81d367b59937 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149529 fail ff2ae607c6f329d11a3b0528801ea7474be8c3e9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149544 pass 0adb8bc0391f1fa7820529c0200fb0c4912fe365 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149546 fail 6cd3d4019ba3f45aa1a87e4e914e81d367b59937 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
Searching for interesting versions
 Result found: flight 149386 (pass), for basis pass
 Result found: flight 149505 (fail), for basis failure
 Repro found: flight 149506 (pass), for basis pass
 Repro found: flight 149524 (fail), for basis failure
 0 revisions at 0adb8bc0391f1fa7820529c0200fb0c4912fe365 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef5dcba975ee3b4c29b19ad0b23d371a2cd9d60a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6a3b59ab9c7dc00331c21346052dfa6a0df45aa3 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
No revisions left to test, checking graph state.
 Result found: flight 149538 (pass), for last pass
 Result found: flight 149540 (fail), for first failure
 Repro found: flight 149542 (pass), for last pass
 Repro found: flight 149543 (fail), for first failure
 Repro found: flight 149544 (pass), for last pass
 Repro found: flight 149546 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  6cd3d4019ba3f45aa1a87e4e914e81d367b59937
  Bug not present: 0adb8bc0391f1fa7820529c0200fb0c4912fe365
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149546/


  commit 6cd3d4019ba3f45aa1a87e4e914e81d367b59937
  Merge: 0adb8bc0391f c3881eb58d56
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Apr 3 12:51:46 2020 -0700
  
      Merge tag 'for-linus-5.7-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
      
      Pull xen updates from Juergen Gross:
      
       - a cleanup patch removing an unused function
      
       - a small fix for the xen pciback driver
      
       - a series for making the unwinder hyppay with the Xen PV guest idle
         task stacks
      
      * tag 'for-linus-5.7-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
        x86/xen: Make the secondary CPU idle tasks reliable
        x86/xen: Make the boot CPU idle task reliable
        xen-pciback: fix INTERRUPT_TYPE_* defines
        xen/xenbus: remove unused xenbus_map_ring()
  
  commit c3881eb58d56116c79ac4ee4f40fd15ead124c4b
  Author: Miroslav Benes <mbenes@suse.cz>
  Date:   Thu Mar 26 10:26:03 2020 +0100
  
      x86/xen: Make the secondary CPU idle tasks reliable
      
      The unwinder reports the secondary CPU idle tasks' stack on XEN PV as
      unreliable, which affects at least live patching.
      cpu_initialize_context() sets up the context of the CPU through
      VCPUOP_initialise hypercall. After it is woken up, the idle task starts
      in cpu_bringup_and_idle() function and its stack starts at the offset
      right below pt_regs. The unwinder correctly detects the end of stack
      there but it is confused by NULL return address in the last frame.
      
      Introduce a wrapper in assembly, which just calls
      cpu_bringup_and_idle(). The return address is thus pushed on the stack
      and the wrapper contains the annotation hint for the unwinder regarding
      the stack state.
      
      Signed-off-by: Miroslav Benes <mbenes@suse.cz>
      Reviewed-by: Juergen Gross <jgross@suse.com>
      Signed-off-by: Juergen Gross <jgross@suse.com>
  
  commit 2f62f36e62daec43aa7b9633ef7f18e042a80bed
  Author: Miroslav Benes <mbenes@suse.cz>
  Date:   Thu Mar 26 10:26:02 2020 +0100
  
      x86/xen: Make the boot CPU idle task reliable
      
      The unwinder reports the boot CPU idle task's stack on XEN PV as
      unreliable, which affects at least live patching. There are two reasons
      for this. First, the task does not follow the x86 convention that its
      stack starts at the offset right below saved pt_regs. It allows the
      unwinder to easily detect the end of the stack and verify it. Second,
      startup_xen() function does not store the return address before jumping
      to xen_start_kernel() which confuses the unwinder.
      
      Amend both issues by moving the starting point of initial stack in
      startup_xen() and storing the return address before the jump, which is
      exactly what call instruction does.
      
      Signed-off-by: Miroslav Benes <mbenes@suse.cz>
      Reviewed-by: Juergen Gross <jgross@suse.com>
      Signed-off-by: Juergen Gross <jgross@suse.com>
  
  commit 69086bd698574501a59073b07b629f2a00b82552
  Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Date:   Fri Mar 20 04:09:18 2020 +0100
  
      xen-pciback: fix INTERRUPT_TYPE_* defines
      
      xen_pcibk_get_interrupt_type() assumes INTERRUPT_TYPE_NONE being 0
      (initialize ret to 0 and return as INTERRUPT_TYPE_NONE).
      Fix the definition to make INTERRUPT_TYPE_NONE really 0, and also shift
      other values to not leave holes.
      But also, do not assume INTERRUPT_TYPE_NONE being 0 anymore to avoid
      similar confusions in the future.
      
      Fixes: 476878e4b2be ("xen-pciback: optionally allow interrupt enable flag writes")
      Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
      Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
      Signed-off-by: Juergen Gross <jgross@suse.com>
  
  commit b28089a7ad9d07b1b35e2b781a66a200f8b8e20d
  Author: Juergen Gross <jgross@suse.com>
  Date:   Mon Mar 9 16:54:41 2020 +0100
  
      xen/xenbus: remove unused xenbus_map_ring()
      
      xenbus_map_ring() is used nowhere in the tree, remove it.
      xenbus_unmap_ring() is used only locally, so make it static and move it
      up.
      
      Signed-off-by: Juergen Gross <jgross@suse.com>
      Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: Juergen Gross <jgross@suse.com>

pnmtopng: 220 colors found
Revision graph left in /home/logs/results/bisect/linux-linus/test-amd64-i386-xl-pvshim.xen-boot.{dot,ps,png,html,svg}.
----------------------------------------
149546: tolerable ALL FAIL

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

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-pvshim     7 xen-boot                fail baseline untested


jobs:
 test-amd64-i386-xl-pvshim                                    fail    


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



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 05:16:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 05:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMPYO-0006GX-Vt; Thu, 09 Apr 2020 05:16:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Y/8s=5Y=gmail.com=neilsikka@srs-us1.protection.inumbo.net>)
 id 1jMHY1-0001zP-2h
 for xen-devel@lists.xenproject.org; Wed, 08 Apr 2020 20:43:45 +0000
X-Inumbo-ID: a319340c-79d9-11ea-83d8-bc764e2007e4
Received: from mail-ed1-x529.google.com (unknown [2a00:1450:4864:20::529])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a319340c-79d9-11ea-83d8-bc764e2007e4;
 Wed, 08 Apr 2020 20:43:44 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id cw6so10436472edb.9
 for <xen-devel@lists.xenproject.org>; Wed, 08 Apr 2020 13:43:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=Bben0FhFH556SaeVe3u+5c8WrOFDEewcwW5ZzLIk32U=;
 b=AKXRSbMLnEka5p/M3davmok66tukIpm4ifVtvKoARUvZNamYhgA69j266ZWK+jmbim
 MBFwdLUPmYR5UkzW7MgMZi1rxrnxmvIbaLtDIOnKCTG8orstVMKFuqNPUfJ7XLo/Mmr2
 GLj4VwBE4kZwa946yPKhKZd70tR/0vl0NrBBTeECQt/TGJgEOQOTPJftPSKyMR9NH5jW
 6GeDwWgWpsH3oyFDQBplpgb4dvbYUFV7PlaOmWt4Rpx0O6bZOcXNcTHkzwwjR4IG2Bu4
 BiuOyWYMCOGKUBGagXqs9DL3BKMn9BND0+JTAtuLtmJChBYjaok5a20ZHrbemB2ONd4S
 faug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=Bben0FhFH556SaeVe3u+5c8WrOFDEewcwW5ZzLIk32U=;
 b=EYewf/ssLm8nAAz+P0YYMYnBNuOE2lSA0rLWZUGwFHVqEHmzzPYlqKjPZ8KG+sx6Dq
 GMHphoEWPiVeIAs4sVzNlMpfSADT3wW7Oc41ZXGGJ4XBTTtEJI2k08FvqelnAgnA4nxM
 l9u4ycE5tuHARv8ytmrwyBvY1zSJLi/EYH+LLquAcs66PXSGV3ePwIl6I6pYP83wATWC
 00MeagpTQ8oLUB0YGyIiIGOWrfWjDJcBGl15zoiXF3n/hhNV79SRUhO9Z/3xn7L3MoHU
 cTXmOc7bpcZ8G2jaH2m11b1t1NSkqxGdbklO0ChUqdip48qqGXtx4dMLrT2bXxvUwlrv
 dJMA==
X-Gm-Message-State: AGi0PuaKRN+TQv6mf06tv80QwOhlNKwaZfySwv4XBeJoAkeTIbc6WsEg
 BxfulVFBy2NFppQTHkFGp6JX1YnO75GiR60g1vGezuNZlKk=
X-Google-Smtp-Source: APiQypLVSadprimQJ+cw5n0dtPJz4OpOb9sbRu9s9iKE6JUUEr+O6J/DGMOzDoBdDEMe2hIdQlgSDJS81vTyTsBxobQ=
X-Received: by 2002:a17:906:365a:: with SMTP id
 r26mr8316749ejb.343.1586378623071; 
 Wed, 08 Apr 2020 13:43:43 -0700 (PDT)
MIME-Version: 1.0
From: Neil Sikka <neilsikka@gmail.com>
Date: Wed, 8 Apr 2020 16:43:32 -0400
Message-ID: <CAHPMNWdvuZFuSMsr3ZQ8U0PZ3mB+Uq3hYryu+DtJsB1UV4bi_w@mail.gmail.com>
Subject: xen-network-common.sh MAC address assignment
To: Xen-devel <xen-devel@lists.xenproject.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Thu, 09 Apr 2020 05:16:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hello,
Why does git commit f400f2993b52e820d0da24a2e49a8fdfab0d2827, make
xen-network-common.sh set a static MAC address for the virtual device
as shown below?

ip link set dev ${dev} address fe:ff:ff:ff:ff:ff || true

I see the high order byte is 0xFE, which has the broadcast flag unset,
thereby signifying a unicast MAC address (as stated in the comment
right before this line). But shouldnt the device have a random MAC
address? Is there any reason why a hardcoded MAC is assigned? FYI, in
rewriting this script with a randomized MAC, my VM cannot communicate
with my host, so this might have something to do with my problem.

Thanks.

-- 
My Blog: http://www.neilscomputerblog.blogspot.com/
Twitter: @neilsikka


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 06:19:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 06:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMQWa-0002m9-Nc; Thu, 09 Apr 2020 06:18:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=NeOZ=5Z=lst.de=hch@srs-us1.protection.inumbo.net>)
 id 1jMQWZ-0002m4-6p
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 06:18:51 +0000
X-Inumbo-ID: f93bf2e8-7a29-11ea-8290-12813bfff9fa
Received: from verein.lst.de (unknown [213.95.11.211])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f93bf2e8-7a29-11ea-8290-12813bfff9fa;
 Thu, 09 Apr 2020 06:18:48 +0000 (UTC)
Received: by verein.lst.de (Postfix, from userid 2407)
 id 7A3A668C4E; Thu,  9 Apr 2020 08:18:46 +0200 (CEST)
Date: Thu, 9 Apr 2020 08:18:46 +0200
From: Christoph Hellwig <hch@lst.de>
To: Wei Liu <wei.liu2@citrix.com>
Subject: Use of VM_IOREMAP in xenbus
Message-ID: <20200409061846.GA30241@lst.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
 Bob Liu <bob.liu@oracle.com>, Paul Durrant <paul.durrant@citrix.com>,
 David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Wei,

commit ccc9d90a9a8b5 ("xenbus_client: Extend interface to support
multi-page ring") addes a use of vmap in what is now
xenbus_map_ring_valloc_hvm, and uses the VM_IOREMAP flag that is
only really intended for implementing ioremap.  Do you remember
what the reason is that this flag was used?



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 06:31:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 06:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMQiO-0004Jg-NT; Thu, 09 Apr 2020 06:31:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMQiN-0004Jb-Ip
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 06:31:03 +0000
X-Inumbo-ID: aea8634a-7a2b-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id aea8634a-7a2b-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 06:31:02 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 66A18AC65;
 Thu,  9 Apr 2020 06:31:00 +0000 (UTC)
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Julien Grall <julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
 <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
Date: Thu, 9 Apr 2020 08:30:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.2020 00:05, Julien Grall wrote:
> Hi Jan,
> 
> On 07/04/2020 09:14, Jan Beulich wrote:
>> On 04.04.2020 15:10, Julien Grall wrote:
>>> From: Julien Grall <jgrall@amazon.com>
>>>
>>> Most of the helpers to access guest memory are implemented the same way
>>> on Arm and x86. The only differences are:
>>>      - guest_handle_{from, to}_param(): while on x86 XEN_GUEST_HANDLE()
>>>        and XEN_GUEST_HANDLE_PARAM() are the same, they are not on Arm. It
>>>        is still fine to use the Arm implementation on x86.
>>>      - __clear_guest_offset(): Interestingly the prototype does not match
>>>        between the x86 and Arm. However, the Arm one is bogus. So the x86
>>>        implementation can be used.
>>>      - guest_handle{,_subrange}_okay(): They are validly differing
>>>        because Arm is only supporting auto-translated guest and therefore
>>>        handles are always valid.
>>
>> While I'm fine in principle with such consolidation, I'm afraid I
>> really need to ask for some historical background to be added
>> here. It may very well be that there's a reason for the separation
>> (likely to be found in the removed ia64 or ppc ports), which may
>> then provide a hint at why future ports may want to have these
>> separated. If such reasons exist, I'd prefer to avoid the back and
>> forth between headers. What we could do in such a case is borrow
>> Linux'es asm-generic/ concept, and move the "typical"
>> implementation there. (And of course if there were no noticable
>> reasons for the split, the change as it is would be fine in
>> general; saying so without having looked at the details of it,
>> yet).
> 
> Looking at the history, ia64 and ppc used to include a common
> header called xen/xencomm.h from asm/guest_access.h.
> 
> This has now disappeared with the removal of the two ports.
> 
> Regarding future arch, the fact arm and x86 gives me some confidence
> we are unlikely going to get a new ABI for an arch. Do you see any
> reason to?

Well, there surely had be a reason for ia64 and ppc to use a
different approach. I don't see why a new port may not also want
to go that route instead of the x86/Arm one.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 06:37:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 06:37:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMQoy-0004Wc-KQ; Thu, 09 Apr 2020 06:37:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMQox-0004WX-By
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 06:37:51 +0000
X-Inumbo-ID: a20bf0d8-7a2c-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a20bf0d8-7a2c-11ea-83d8-bc764e2007e4;
 Thu, 09 Apr 2020 06:37:50 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0D9ADAC64;
 Thu,  9 Apr 2020 06:37:49 +0000 (UTC)
Subject: Re: Use of VM_IOREMAP in xenbus
To: Christoph Hellwig <hch@lst.de>, Wei Liu <wl@xen.org>
References: <20200409061846.GA30241@lst.de>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <8074b77d-d784-95ee-8d47-069827855876@suse.com>
Date: Thu, 9 Apr 2020 08:37:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200409061846.GA30241@lst.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Konrad Wilk <konrad.wilk@oracle.com>, "Durrant, Paul" <pdurrant@amazon.com>,
 linux-kernel@vger.kernel.org, Bob Liu <bob.liu@oracle.com>,
 xen-devel@lists.xenproject.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Adjusting recipient list (dropping David, new mail addresses for Wei and
Paul).

On 09.04.20 08:18, Christoph Hellwig wrote:
> Hi Wei,
> 
> commit ccc9d90a9a8b5 ("xenbus_client: Extend interface to support
> multi-page ring") addes a use of vmap in what is now
> xenbus_map_ring_valloc_hvm, and uses the VM_IOREMAP flag that is
> only really intended for implementing ioremap.  Do you remember
> what the reason is that this flag was used?
> 

Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 06:49:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 06:49:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMQzr-0005Pt-NP; Thu, 09 Apr 2020 06:49:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMQzq-0005Po-84
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 06:49:06 +0000
X-Inumbo-ID: 34054c5e-7a2e-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 34054c5e-7a2e-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 06:49:05 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id AB19BAB5F;
 Thu,  9 Apr 2020 06:49:03 +0000 (UTC)
Subject: Re: [linux-linus bisection] complete test-amd64-i386-xl-pvshim
To: osstest service owner <osstest-admin@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <E1jMNdT-00020X-5L@osstest.test-lab.xenproject.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <80929638-1cf7-0ad7-aec4-bf2def058f42@suse.com>
Date: Thu, 9 Apr 2020 08:49:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <E1jMNdT-00020X-5L@osstest.test-lab.xenproject.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.20 05:13, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-i386-xl-pvshim
> testid xen-boot
> 
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>    Bug introduced:  6cd3d4019ba3f45aa1a87e4e914e81d367b59937
>    Bug not present: 0adb8bc0391f1fa7820529c0200fb0c4912fe365
>    Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149546/
> 
> 
>    commit 6cd3d4019ba3f45aa1a87e4e914e81d367b59937
>    Merge: 0adb8bc0391f c3881eb58d56
>    Author: Linus Torvalds <torvalds@linux-foundation.org>
>    Date:   Fri Apr 3 12:51:46 2020 -0700
>    
>        Merge tag 'for-linus-5.7-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
>        
>        Pull xen updates from Juergen Gross:
>        
>         - a cleanup patch removing an unused function
>        
>         - a small fix for the xen pciback driver
>        
>         - a series for making the unwinder hyppay with the Xen PV guest idle
>           task stacks

Looking into this one.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 07:00:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 07:00:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMRAX-0006yJ-PB; Thu, 09 Apr 2020 07:00:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMRAW-0006yC-4n
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 07:00:08 +0000
X-Inumbo-ID: bebfc742-7a2f-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bebfc742-7a2f-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 07:00:07 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 66991AC64;
 Thu,  9 Apr 2020 07:00:05 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org, x86@kernel.org,
 linux-kernel@vger.kernel.org
Subject: [PATCH] x86/xen: fix booting 32-bit pv guest
Date: Thu,  9 Apr 2020 09:00:01 +0200
Message-Id: <20200409070001.16675-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@linutronix.de>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
introduced a regression for booting 32 bit Xen PV guests: the address
of the initial stack needs to be a virtual one.

Fixes: 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/xen-head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7d1c4fcbe8f7..1ba601df3a37 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -38,7 +38,7 @@ SYM_CODE_START(startup_xen)
 #ifdef CONFIG_X86_64
 	mov initial_stack(%rip), %rsp
 #else
-	mov pa(initial_stack), %esp
+	mov initial_stack, %esp
 #endif
 
 #ifdef CONFIG_X86_64
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 07:31:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 07:31:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMRf3-00012q-Va; Thu, 09 Apr 2020 07:31:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMRf3-00012i-98
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 07:31:41 +0000
X-Inumbo-ID: 26d51144-7a34-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 26d51144-7a34-11ea-83d8-bc764e2007e4;
 Thu, 09 Apr 2020 07:31:40 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id AD43CAD93;
 Thu,  9 Apr 2020 07:31:38 +0000 (UTC)
Subject: Re: [xen-unstable test] 149520: regressions - FAIL
To: osstest service owner <osstest-admin@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <osstest-149520-mainreport@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <74b51d2e-4480-8aea-9069-1214333e799f@suse.com>
Date: Thu, 9 Apr 2020 09:31:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <osstest-149520-mainreport@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.20 04:30, osstest service owner wrote:
> flight 149520 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/149520/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>   test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478
>   test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478

Is it possible to get the ioemu-stubdom binary used in those tests?

I'm seeing a crash in:

http://logs.test-lab.xenproject.org/osstest/logs/149520/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/huxelrebe1---var-log-xen-qemu-dm-debianhvm.guest.osstest.log

and I'd like to get symbol+offset for the stack backtrace.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 07:32:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 07:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMRfi-00016H-9U; Thu, 09 Apr 2020 07:32:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Jqn0=5Z=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMRfh-000168-DF
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 07:32:21 +0000
X-Inumbo-ID: 3abbd42c-7a34-11ea-8296-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3abbd42c-7a34-11ea-8296-12813bfff9fa;
 Thu, 09 Apr 2020 07:32:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=yOS7dbKGBEO1Uvh95+X33pc3WUEnRLRZFkbAvOD6HRU=; b=m+RlugXn/mX8VT1xTZRQBvmL1
 bUx5WMc2hpR37XsAlS8FHlu4JaTUZQtE7cqEXiO9Vf4mqLr5NaQIas72RxURWvFICFzx8eWW810il
 +vT4dAitSWqySxXvtVJGWgVEHTwpde5td98kHl1pfYM/OnjRlaXc+gwrW8XVV3dvp5OLM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMRfY-0006rw-Pn; Thu, 09 Apr 2020 07:32:12 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMRfY-0000xI-B7; Thu, 09 Apr 2020 07:32:12 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMRfY-0005gB-AV; Thu, 09 Apr 2020 07:32:12 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149550-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149550: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=5d6059f8ec16d64f240dc5e6413ca55a3b46b3f7
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 09 Apr 2020 07:32:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 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-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       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      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              5d6059f8ec16d64f240dc5e6413ca55a3b46b3f7
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   83 days
Failing since        146211  2020-01-18 04:18:52 Z   82 days   79 attempts
Testing same since   149550  2020-04-09 04:21:30 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 14162 lines long.)


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 07:41:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 07:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMRow-0002Qk-Gb; Thu, 09 Apr 2020 07:41:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMRov-0002Qf-Jd
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 07:41:53 +0000
X-Inumbo-ID: 93d441ba-7a35-11ea-8296-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 93d441ba-7a35-11ea-8296-12813bfff9fa;
 Thu, 09 Apr 2020 07:41:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B195CADA3;
 Thu,  9 Apr 2020 07:41:50 +0000 (UTC)
From: Jan Beulich <jbeulich@suse.com>
Subject: preparations for 4.13.1 and 4.12.3
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Message-ID: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
Date: Thu, 9 Apr 2020 09:41:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Anthony Perard <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

All,

the releases are due in a week or two. Please point out backports
you find missing from the respective staging branches, but which
you consider relevant. (Ian, I notice there haven't been any
tools side backports at all so far. Julien, Stefano - same for
Arm.)

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 07:52:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 07:52:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMRyx-0003Th-32; Thu, 09 Apr 2020 07:52:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMRyw-0003Tc-Bn
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 07:52:14 +0000
X-Inumbo-ID: 0603433e-7a37-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0603433e-7a37-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 07:52:13 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 95B74AE52;
 Thu,  9 Apr 2020 07:52:11 +0000 (UTC)
Subject: Re: preparations for 4.13.1 and 4.12.3
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <7ae5179c-8d48-bb83-8250-43a558a04ba5@suse.com>
Date: Thu, 9 Apr 2020 09:52:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Anthony Perard <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.20 09:41, Jan Beulich wrote:
> All,
> 
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)
> 
> Jan
> 

Commit bb2a34fd740e9a26be9e2244f1a5b4cef439e5a8 should be backported
to both IMO (tools patch).


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 08:00:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 08:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMS6u-0004rT-Bw; Thu, 09 Apr 2020 08:00:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMS6s-0004rO-Ck
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 08:00:26 +0000
X-Inumbo-ID: 2b68e9ac-7a38-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2b68e9ac-7a38-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 08:00:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 49AC5AE3A;
 Thu,  9 Apr 2020 08:00:24 +0000 (UTC)
Subject: Re: [xen-unstable test] 149520: regressions - FAIL
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
References: <osstest-149520-mainreport@xen.org>
 <74b51d2e-4480-8aea-9069-1214333e799f@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <277afcf8-fc0f-de37-ab61-0b1bff54c125@suse.com>
Date: Thu, 9 Apr 2020 10:00:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <74b51d2e-4480-8aea-9069-1214333e799f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 osstest service owner <osstest-admin@xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.2020 09:31, Jürgen Groß wrote:
> On 09.04.20 04:30, osstest service owner wrote:
>> flight 149520 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/149520/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>   test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478
>>   test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478
> 
> Is it possible to get the ioemu-stubdom binary used in those tests?

Isn't this the usr/local/lib/xen/boot/ioemu-stubdom.gz in
http://logs.test-lab.xenproject.org/osstest/logs/149520/build-amd64-xsm/build/dist.tar.gz

Jan

> I'm seeing a crash in:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/149520/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/huxelrebe1---var-log-xen-qemu-dm-debianhvm.guest.osstest.log
> 
> and I'd like to get symbol+offset for the stack backtrace.
> 
> 
> Juergen
> 



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 08:01:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 08:01:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMS7r-0004wV-QI; Thu, 09 Apr 2020 08:01:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=EhrS=5Z=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMS7q-0004wN-EM
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 08:01:26 +0000
X-Inumbo-ID: 4f5fa116-7a38-11ea-8297-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4f5fa116-7a38-11ea-8297-12813bfff9fa;
 Thu, 09 Apr 2020 08:01:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=c8bafAo2f3ikeNGrWsY9uPFP69WXt7upLB6rKy3D7zs=; b=wvW9OZXPJ/a+8KOzmfs6e0+fVb
 akVjaMsiXNiDbK1FOxbNl6RkACpu5R6PIusgsMNxFRtLlWcfmijUPtUKHKkvcCHoT6lzbXFkLXEOb
 ExRt7d4siEZHVh6aRHfHSqN1BN6n8XQx6OfZ0rjOQeuAO7tosG5GrFVQ56c8id5Za46I=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMS7n-00082t-4a; Thu, 09 Apr 2020 08:01:23 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMS7m-00042X-Sw; Thu, 09 Apr 2020 08:01:23 +0000
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Jan Beulich <jbeulich@suse.com>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
 <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
 <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <c8e66108-7ac1-fb51-841f-21886b731f04@xen.org>
Date: Thu, 9 Apr 2020 09:01:20 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 09/04/2020 07:30, Jan Beulich wrote:
> On 09.04.2020 00:05, Julien Grall wrote:
>> Hi Jan,
>>
>> On 07/04/2020 09:14, Jan Beulich wrote:
>>> On 04.04.2020 15:10, Julien Grall wrote:
>>>> From: Julien Grall <jgrall@amazon.com>
>>>>
>>>> Most of the helpers to access guest memory are implemented the same way
>>>> on Arm and x86. The only differences are:
>>>>       - guest_handle_{from, to}_param(): while on x86 XEN_GUEST_HANDLE()
>>>>         and XEN_GUEST_HANDLE_PARAM() are the same, they are not on Arm. It
>>>>         is still fine to use the Arm implementation on x86.
>>>>       - __clear_guest_offset(): Interestingly the prototype does not match
>>>>         between the x86 and Arm. However, the Arm one is bogus. So the x86
>>>>         implementation can be used.
>>>>       - guest_handle{,_subrange}_okay(): They are validly differing
>>>>         because Arm is only supporting auto-translated guest and therefore
>>>>         handles are always valid.
>>>
>>> While I'm fine in principle with such consolidation, I'm afraid I
>>> really need to ask for some historical background to be added
>>> here. It may very well be that there's a reason for the separation
>>> (likely to be found in the removed ia64 or ppc ports), which may
>>> then provide a hint at why future ports may want to have these
>>> separated. If such reasons exist, I'd prefer to avoid the back and
>>> forth between headers. What we could do in such a case is borrow
>>> Linux'es asm-generic/ concept, and move the "typical"
>>> implementation there. (And of course if there were no noticable
>>> reasons for the split, the change as it is would be fine in
>>> general; saying so without having looked at the details of it,
>>> yet).
>>
>> Looking at the history, ia64 and ppc used to include a common
>> header called xen/xencomm.h from asm/guest_access.h.
>>
>> This has now disappeared with the removal of the two ports.
>>
>> Regarding future arch, the fact arm and x86 gives me some confidence
>> we are unlikely going to get a new ABI for an arch. Do you see any
>> reason to?
> 
> Well, there surely had be a reason for ia64 and ppc to use a
> different approach. 

This was introduced way before my time in Xen. AFAICT, you were already 
part of the community when 'xencomm' were alive.

There are not much information about it only nor in the commits. So do 
you mind sharing a bit more what 'xencomm' meant to be and why it wasn't 
introduced on x86?

> I don't see why a new port may not also want
> to go that route instead of the x86/Arm one.
I could accept that someone would want to reinvent a new ABI from 
scratch for just an hypothetical new arch. However it would be quite an 
effort to reinvent XEN_GUEST_HANDLE(). The chance is RISC-V is only 
going to re-use what Arm did as Arm already did with x86.

I would like to avoid to introduce a new directory asm-generic with just 
one header in it. Maybe you have some other headers in mind?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 08:07:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 08:07:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMSDF-0005AQ-Fa; Thu, 09 Apr 2020 08:07:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMSDD-0005AL-RP
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 08:06:59 +0000
X-Inumbo-ID: 1570fc38-7a39-11ea-8298-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1570fc38-7a39-11ea-8298-12813bfff9fa;
 Thu, 09 Apr 2020 08:06:58 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 84EC2ACA4;
 Thu,  9 Apr 2020 08:06:56 +0000 (UTC)
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Julien Grall <julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
 <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
 <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
 <c8e66108-7ac1-fb51-841f-21886b731f04@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f02f09ec-b643-8321-e235-ce0ee5526ab3@suse.com>
Date: Thu, 9 Apr 2020 10:06:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <c8e66108-7ac1-fb51-841f-21886b731f04@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.2020 10:01, Julien Grall wrote:
> Hi,
> 
> On 09/04/2020 07:30, Jan Beulich wrote:
>> On 09.04.2020 00:05, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 07/04/2020 09:14, Jan Beulich wrote:
>>>> On 04.04.2020 15:10, Julien Grall wrote:
>>>>> From: Julien Grall <jgrall@amazon.com>
>>>>>
>>>>> Most of the helpers to access guest memory are implemented the same way
>>>>> on Arm and x86. The only differences are:
>>>>>       - guest_handle_{from, to}_param(): while on x86 XEN_GUEST_HANDLE()
>>>>>         and XEN_GUEST_HANDLE_PARAM() are the same, they are not on Arm. It
>>>>>         is still fine to use the Arm implementation on x86.
>>>>>       - __clear_guest_offset(): Interestingly the prototype does not match
>>>>>         between the x86 and Arm. However, the Arm one is bogus. So the x86
>>>>>         implementation can be used.
>>>>>       - guest_handle{,_subrange}_okay(): They are validly differing
>>>>>         because Arm is only supporting auto-translated guest and therefore
>>>>>         handles are always valid.
>>>>
>>>> While I'm fine in principle with such consolidation, I'm afraid I
>>>> really need to ask for some historical background to be added
>>>> here. It may very well be that there's a reason for the separation
>>>> (likely to be found in the removed ia64 or ppc ports), which may
>>>> then provide a hint at why future ports may want to have these
>>>> separated. If such reasons exist, I'd prefer to avoid the back and
>>>> forth between headers. What we could do in such a case is borrow
>>>> Linux'es asm-generic/ concept, and move the "typical"
>>>> implementation there. (And of course if there were no noticable
>>>> reasons for the split, the change as it is would be fine in
>>>> general; saying so without having looked at the details of it,
>>>> yet).
>>>
>>> Looking at the history, ia64 and ppc used to include a common
>>> header called xen/xencomm.h from asm/guest_access.h.
>>>
>>> This has now disappeared with the removal of the two ports.
>>>
>>> Regarding future arch, the fact arm and x86 gives me some confidence
>>> we are unlikely going to get a new ABI for an arch. Do you see any
>>> reason to?
>>
>> Well, there surely had be a reason for ia64 and ppc to use a
>> different approach. 
> 
> This was introduced way before my time in Xen. AFAICT, you were
> already part of the community when 'xencomm' were alive.

I was, but I was never actively involved in ia64 or ppc work.

> There are not much information about it only nor in the commits.
> So do you mind sharing a bit more what 'xencomm' meant to be
> and why it wasn't introduced on x86?

If I had details, I would have provided at least some hints already.

>> I don't see why a new port may not also want
>> to go that route instead of the x86/Arm one.
> I could accept that someone would want to reinvent a new ABI
> from scratch for just an hypothetical new arch. However it would
> be quite an effort to reinvent XEN_GUEST_HANDLE(). The chance is
> RISC-V is only going to re-use what Arm did as Arm already did
> with x86.
> 
> I would like to avoid to introduce a new directory asm-generic
> with just one header in it. Maybe you have some other headers in
> mind?

I recall having wondered a few times whether we shouldn't use this
concept elsewhere. One case iirc was bitops stuff. Looking over
the Linux ones, some atomic and barrier fallback implementations
may also sensibly live there, and there are likely more.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 08:57:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 08:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMSzL-0000tx-K9; Thu, 09 Apr 2020 08:56:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMSzJ-0000ts-RO
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 08:56:41 +0000
X-Inumbo-ID: 07389d4a-7a40-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 07389d4a-7a40-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 08:56:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8BF6CAB5F;
 Thu,  9 Apr 2020 08:56:39 +0000 (UTC)
Subject: Re: [xen-unstable test] 149520: regressions - FAIL
To: Jan Beulich <jbeulich@suse.com>
References: <osstest-149520-mainreport@xen.org>
 <74b51d2e-4480-8aea-9069-1214333e799f@suse.com>
 <277afcf8-fc0f-de37-ab61-0b1bff54c125@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <36780b96-6db0-ab80-9bb2-d028d6856552@suse.com>
Date: Thu, 9 Apr 2020 10:56:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <277afcf8-fc0f-de37-ab61-0b1bff54c125@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 osstest service owner <osstest-admin@xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.20 10:00, Jan Beulich wrote:
> On 09.04.2020 09:31, Jürgen Groß wrote:
>> On 09.04.20 04:30, osstest service owner wrote:
>>> flight 149520 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>    test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478
>>>    test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478
>>
>> Is it possible to get the ioemu-stubdom binary used in those tests?
> 
> Isn't this the usr/local/lib/xen/boot/ioemu-stubdom.gz in
> http://logs.test-lab.xenproject.org/osstest/logs/149520/build-amd64-xsm/build/dist.tar.gz

No, the crashed one was a 32-bit stubdom, while this file is a 64-bit
one. According to the log the path should be fine, but the file in no
way matches the crashed one.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 09:00:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 09:00:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMT3F-0001lC-B1; Thu, 09 Apr 2020 09:00:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMT3E-0001l6-Fq
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 09:00:44 +0000
X-Inumbo-ID: 97eebbb3-7a40-11ea-829b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 97eebbb3-7a40-11ea-829b-12813bfff9fa;
 Thu, 09 Apr 2020 09:00:43 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5F3B4AEC5;
 Thu,  9 Apr 2020 09:00:42 +0000 (UTC)
Subject: Re: [xen-unstable test] 149520: regressions - FAIL
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
References: <osstest-149520-mainreport@xen.org>
 <74b51d2e-4480-8aea-9069-1214333e799f@suse.com>
 <277afcf8-fc0f-de37-ab61-0b1bff54c125@suse.com>
 <36780b96-6db0-ab80-9bb2-d028d6856552@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <c58d88e0-04ce-500d-9216-8b3746a8d03d@suse.com>
Date: Thu, 9 Apr 2020 11:00:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <36780b96-6db0-ab80-9bb2-d028d6856552@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 osstest service owner <osstest-admin@xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.2020 10:56, Jürgen Groß wrote:
> On 09.04.20 10:00, Jan Beulich wrote:
>> On 09.04.2020 09:31, Jürgen Groß wrote:
>>> On 09.04.20 04:30, osstest service owner wrote:
>>>> flight 149520 xen-unstable real [real]
>>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/
>>>>
>>>> Regressions :-(
>>>>
>>>> Tests which did not succeed and are blocking,
>>>> including tests which could not be run:
>>>>    test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478
>>>>    test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478
>>>
>>> Is it possible to get the ioemu-stubdom binary used in those tests?
>>
>> Isn't this the usr/local/lib/xen/boot/ioemu-stubdom.gz in
>> http://logs.test-lab.xenproject.org/osstest/logs/149520/build-amd64-xsm/build/dist.tar.gz
> 
> No, the crashed one was a 32-bit stubdom, while this file is a 64-bit
> one. According to the log the path should be fine, but the file in no
> way matches the crashed one.

Then look under http://logs.test-lab.xenproject.org/osstest/logs/149520/build-i386-xsm/build/
or any of the other http://logs.test-lab.xenproject.org/osstest/logs/149520/build-*/build/?
I'm pretty sure all produced binaries get collected and made available.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 09:28:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 09:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMTTv-0003aZ-TR; Thu, 09 Apr 2020 09:28:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=EhrS=5Z=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMTTu-0003aU-7q
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 09:28:18 +0000
X-Inumbo-ID: 71ddda58-7a44-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 71ddda58-7a44-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 09:28:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=8kp5cilarZI2IdGcOQHvhDJzG1/Yatb76O8KHEXL7T0=; b=wLxG7X55RbD0FJkXETK+bxZQwL
 7Jvb5eJEyOvYqYSycy/7GFPJcWEipRg60Az/ruPo+9l7h02j0k3iErmhpKJjj6+1UUcQS/5WSfv3w
 9oxpEftB2qVYaqOYLHlbhx0QjWqu3KYjloUz7Xr0zDFzo7fcrvqtymajmXByZ1bEEKaQ=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMTTr-0001JS-15; Thu, 09 Apr 2020 09:28:15 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMTTq-00022A-PU; Thu, 09 Apr 2020 09:28:14 +0000
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Jan Beulich <jbeulich@suse.com>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
 <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
 <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
 <c8e66108-7ac1-fb51-841f-21886b731f04@xen.org>
 <f02f09ec-b643-8321-e235-ce0ee5526ab3@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <69deb8f4-bafe-734c-f6fa-de41ecf539d2@xen.org>
Date: Thu, 9 Apr 2020 10:28:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f02f09ec-b643-8321-e235-ce0ee5526ab3@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 09/04/2020 09:06, Jan Beulich wrote:
> On 09.04.2020 10:01, Julien Grall wrote:
>> Hi,
>>
>> On 09/04/2020 07:30, Jan Beulich wrote:
>>> On 09.04.2020 00:05, Julien Grall wrote:
>>> I don't see why a new port may not also want
>>> to go that route instead of the x86/Arm one.
>> I could accept that someone would want to reinvent a new ABI
>> from scratch for just an hypothetical new arch. However it would
>> be quite an effort to reinvent XEN_GUEST_HANDLE(). The chance is
>> RISC-V is only going to re-use what Arm did as Arm already did
>> with x86.
>>
>> I would like to avoid to introduce a new directory asm-generic
>> with just one header in it. Maybe you have some other headers in
>> mind?
> 
> I recall having wondered a few times whether we shouldn't use this
> concept elsewhere. One case iirc was bitops stuff. Looking over
> the Linux ones, some atomic and barrier fallback implementations
> may also sensibly live there, and there are likely more.

In theory it makes sense but, in the current state of Xen, 'asm-generic' 
means they are common to Arm and x86. This is basically the same 
definition as for the directory 'xen'. So how do you draw a line which 
files go where?

To be honest, I don't think we can draw a line without a 3rd 
architecture. So I would recommend to wait until then to create an 
asm-generic directory.

Meanwhile, I still think the consolidation in xen/ is useful as it makes 
easier to maintain. It is also going to make easier for RISCv (or a new 
arch) as they don't have to worry about duplication (if any).

In the event they decide to purse their own route, then it is not going 
to be a massive pain to move part of xen/guest_access.h in 
asm-generic/guest_access.h and include the latter from {xen, asm} 
/guest_access.h.

Cheers,


-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 09:42:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 09:42:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMThK-00059x-EP; Thu, 09 Apr 2020 09:42:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMThJ-00059m-6i
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 09:42:09 +0000
X-Inumbo-ID: 60ff8734-7a46-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 60ff8734-7a46-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 09:42:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 018D7AC24;
 Thu,  9 Apr 2020 09:42:06 +0000 (UTC)
Subject: Re: [PATCH v2 1/5] x86/shim: map and unmap page tables in
 replace_va_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <7638095024ec3379a8d9ddadfe47e36da168e4dd.1586352238.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <ddbad9f5-307e-7b1d-0cc7-cd7ed684f680@suse.com>
Date: Thu, 9 Apr 2020 11:42:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7638095024ec3379a8d9ddadfe47e36da168e4dd.1586352238.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.2020 15:36, Hongyan Xia wrote:
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -168,16 +168,17 @@ const struct platform_bad_page *__init pv_shim_reserved_pages(unsigned int *size
>  static void __init replace_va_mapping(struct domain *d, l4_pgentry_t *l4start,
>                                        unsigned long va, mfn_t mfn)
>  {
> -    l4_pgentry_t *pl4e = l4start + l4_table_offset(va);
> -    l3_pgentry_t *pl3e = l4e_to_l3e(*pl4e) + l3_table_offset(va);
> -    l2_pgentry_t *pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(va);
> -    l1_pgentry_t *pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(va);
> +    l4_pgentry_t l4e = l4start[l4_table_offset(va)];
> +    l3_pgentry_t l3e = l3e_from_l4e(l4e, l3_table_offset(va));
> +    l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(va));
> +    l1_pgentry_t *pl1e = map_l1t_from_l2e(l2e) + l1_table_offset(va);
>      struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e));
>  
>      put_page_and_type(page);
>  
>      *pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT
>                                                        : COMPAT_L1_PROT));
> +    UNMAP_DOMAIN_PAGE(pl1e);
>  }

As said before, here and below I think it should be unmap_domain_page().

> --- a/xen/include/asm-x86/page.h
> +++ b/xen/include/asm-x86/page.h
> @@ -196,6 +196,19 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, unsigned int flags)
>  #define map_l2t_from_l3e(x)        (l2_pgentry_t *)map_domain_page(l3e_get_mfn(x))
>  #define map_l3t_from_l4e(x)        (l3_pgentry_t *)map_domain_page(l4e_get_mfn(x))
>  
> +/* Unlike lYe_to_lXe(), lXe_from_lYe() do not rely on the direct map. */
> +#define l2e_from_l3e(l3e, offset) ({                        \
> +        const l2_pgentry_t *l2t = map_l2t_from_l3e(l3e);    \
> +        l2_pgentry_t l2e = l2t[offset];                     \
> +        UNMAP_DOMAIN_PAGE(l2t);                             \
> +        l2e; })
> +
> +#define l3e_from_l4e(l4e, offset) ({                        \
> +        const l3_pgentry_t *l3t = map_l3t_from_l4e(l4e);    \
> +        l3_pgentry_t l3e = l3t[offset];                     \
> +        UNMAP_DOMAIN_PAGE(l3t);                             \
> +        l3e; })

I think l1e_from_l2e() should be introduced at the same time, even
if for now it's unused. I also think, like we do elsewhere, that
macro-local variables would better have _ suffixes, to avoid
possible variable aliasing issues.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 09:42:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 09:42:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMThK-00059r-6G; Thu, 09 Apr 2020 09:42:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=7Ryc=5Z=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jMThI-00059h-Lv
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 09:42:08 +0000
X-Inumbo-ID: 5fd92f86-7a46-11ea-82a1-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5fd92f86-7a46-11ea-82a1-12813bfff9fa;
 Thu, 09 Apr 2020 09:42:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586425326;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=+uf2awDyEnaXI/3JjExta3Qxvv+TksGEoqixqNzCH7w=;
 b=PAYC0vPKFrn8ZkJfkvG0TtI07JlmkTLj9jQcl5W1mLhzR9Djf9A78KMI
 nJ6RoJj0bIyaLfjLRVxbqFZzw0QtfRBd9UU4ogNrsanpFUh4XKhovGxH0
 jiaYt4h7xogMKWjkwXv1QS4OVTs0eIEwcsRKPInq5LdlgNBx4XYp0i2qX M=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 12bL7UfDp48cTDfK6rg6dkSj7OuFZU1AucseVrh9YC7Ni3fLeBe67cE0V73fiK29Hhl2CillX+
 Fst7NN+0jeeWz0DDClUXVEqlY1U8W+Ti27YOAP7hLi9qAmqBBaVSRS1uUSvXNZ8pU5RyFhYDHG
 AkaWczAwy2gUt+4KbYoEfe4NZ1WdnXRAO/+bLOigUOzBAgJ0z0IrrvVVkd2UoOfcNABktKVC4N
 O6IBUq5OcPjG1A2q7I2rg72jr5NQEgNcar3PK9Zrq/bT5AuyeT1JKiO9o3xhjA8ectL5fWdcHo
 dKc=
X-SBRS: 2.7
X-MesageID: 15825521
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,362,1580792400"; d="scan'208";a="15825521"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH] sched: fix scheduler_disable() with core scheduling
Date: Thu, 9 Apr 2020 10:41:37 +0100
Message-ID: <20200409094137.13836-1-sergey.dyasli@citrix.com>
X-Mailer: git-send-email 2.17.1
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sergey Dyasli <sergey.dyasli@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In core-scheduling mode, Xen might crash when entering ACPI S5 state.
This happens in sched_slave() during is_idle_unit(next) check because
next->vcpu_list is stale and points to an already freed memory.

This situation happens shortly after scheduler_disable() is called if
some CPU is still inside sched_slave() softirq. Current logic simply
returns prev->next_task from sched_wait_rendezvous_in() which causes
the described crash because next_task->vcpu_list has become invalid.

Fix the crash by returning NULL from sched_wait_rendezvous_in() in
the case when scheduler_disable() has been called.

Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
---
CC: Juergen Gross <jgross@suse.com>
CC: Dario Faggioli <dfaggioli@suse.com>
CC: George Dunlap <george.dunlap@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
---
 xen/common/sched/core.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 626861a3fe..d4a6489929 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2484,19 +2484,15 @@ static struct sched_unit *sched_wait_rendezvous_in(struct sched_unit *prev,
 
         *lock = pcpu_schedule_lock_irq(cpu);
 
-        if ( unlikely(!scheduler_active) )
-        {
-            ASSERT(is_idle_unit(prev));
-            atomic_set(&prev->next_task->rendezvous_out_cnt, 0);
-            prev->rendezvous_in_cnt = 0;
-        }
-
         /*
          * Check for scheduling resource switched. This happens when we are
          * moved away from our cpupool and cpus are subject of the idle
          * scheduler now.
+         *
+         * This is also a bail out case when scheduler_disable() has been
+         * called.
          */
-        if ( unlikely(sr != get_sched_res(cpu)) )
+        if ( unlikely(sr != get_sched_res(cpu) || !scheduler_active) )
         {
             ASSERT(is_idle_unit(prev));
             atomic_set(&prev->next_task->rendezvous_out_cnt, 0);
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 09:50:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 09:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMTpM-00067R-Fl; Thu, 09 Apr 2020 09:50:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Jqn0=5Z=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMTpL-00067M-9L
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 09:50:27 +0000
X-Inumbo-ID: 866a1e84-7a47-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 866a1e84-7a47-11ea-83d8-bc764e2007e4;
 Thu, 09 Apr 2020 09:50:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=pb+PGNM5Vfry4b70fXLqD+RrWYCJGTH+1/vYt6idMr4=; b=AWX+p4nl4BJQLEKpyRusk/eeh
 nzQFSBw/jnTscrq9YwCvu3d5PJZn9xJ9s/gNxTJfLNxtth/vNFC8BuVIwbqpPxn0DgqHrGkCV+WgD
 NI2vuHa7Ko0l2iclPz98NjIQk5zKkRUMvzhjXwgiXNeukaqnFr1ne8qmjR9+eaMDEuT8s=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMTpE-0001iz-8l; Thu, 09 Apr 2020 09:50:20 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMTpD-0000XT-Tg; Thu, 09 Apr 2020 09:50:20 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMTpD-0002A2-So; Thu, 09 Apr 2020 09:50:19 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149527-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149527: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-i386-examine:reboot:fail:regression
 linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-raw:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore.2:fail:allowable
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=f5e94d10e4c468357019e5c28d48499f677b284f
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 09 Apr 2020 09:50:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine       8 reboot                   fail REGR. vs. 149238
 test-amd64-i386-xl-pvshim     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 149238
 test-amd64-i386-xl-shadow     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-libvirt-xsm   7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt       7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl            7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-raw        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-xsm        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-freebsd10-i386  7 xen-boot               fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-pair         10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-pair         11 xen-boot/dst_host        fail REGR. vs. 149238

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     17 guest-saverestore.2      fail REGR. vs. 149238

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149238
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149238
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                f5e94d10e4c468357019e5c28d48499f677b284f
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z    9 days
Failing since        149266  2020-04-01 03:55:53 Z    8 days   11 attempts
Testing same since   149527  2020-04-08 14:38:13 Z    0 days    1 attempts

------------------------------------------------------------
1746 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       fail    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       fail    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    fail    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 10:23:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 10:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMULG-0000JF-5S; Thu, 09 Apr 2020 10:23:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMULE-0000J6-4m
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 10:23:24 +0000
X-Inumbo-ID: 241db132-7a4c-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 241db132-7a4c-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 10:23:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D055AAC24;
 Thu,  9 Apr 2020 10:23:21 +0000 (UTC)
Subject: Re: [xen-unstable test] 149520: regressions - FAIL
To: Jan Beulich <jbeulich@suse.com>
References: <osstest-149520-mainreport@xen.org>
 <74b51d2e-4480-8aea-9069-1214333e799f@suse.com>
 <277afcf8-fc0f-de37-ab61-0b1bff54c125@suse.com>
 <36780b96-6db0-ab80-9bb2-d028d6856552@suse.com>
 <c58d88e0-04ce-500d-9216-8b3746a8d03d@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <f7298d04-ba2c-13cc-7f9b-f57e94340fe3@suse.com>
Date: Thu, 9 Apr 2020 12:23:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <c58d88e0-04ce-500d-9216-8b3746a8d03d@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 osstest service owner <osstest-admin@xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.20 11:00, Jan Beulich wrote:
> On 09.04.2020 10:56, Jürgen Groß wrote:
>> On 09.04.20 10:00, Jan Beulich wrote:
>>> On 09.04.2020 09:31, Jürgen Groß wrote:
>>>> On 09.04.20 04:30, osstest service owner wrote:
>>>>> flight 149520 xen-unstable real [real]
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/
>>>>>
>>>>> Regressions :-(
>>>>>
>>>>> Tests which did not succeed and are blocking,
>>>>> including tests which could not be run:
>>>>>     test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478
>>>>>     test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478
>>>>
>>>> Is it possible to get the ioemu-stubdom binary used in those tests?
>>>
>>> Isn't this the usr/local/lib/xen/boot/ioemu-stubdom.gz in
>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/build-amd64-xsm/build/dist.tar.gz
>>
>> No, the crashed one was a 32-bit stubdom, while this file is a 64-bit
>> one. According to the log the path should be fine, but the file in no
>> way matches the crashed one.
> 
> Then look under http://logs.test-lab.xenproject.org/osstest/logs/149520/build-i386-xsm/build/
> or any of the other http://logs.test-lab.xenproject.org/osstest/logs/149520/build-*/build/?
> I'm pretty sure all produced binaries get collected and made available.

Yes, there it could be found.

I'm still struggling to understand why the stubdom is built as 32-bit
binary for this test.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 10:35:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 10:35:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMUX7-0001DF-A3; Thu, 09 Apr 2020 10:35:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMUX6-0001DA-8K
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 10:35:40 +0000
X-Inumbo-ID: da5bb088-7a4d-11ea-82a8-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id da5bb088-7a4d-11ea-82a8-12813bfff9fa;
 Thu, 09 Apr 2020 10:35:38 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 337BDAE17;
 Thu,  9 Apr 2020 10:35:37 +0000 (UTC)
Subject: Re: [xen-unstable test] 149520: regressions - FAIL
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
References: <osstest-149520-mainreport@xen.org>
 <74b51d2e-4480-8aea-9069-1214333e799f@suse.com>
 <277afcf8-fc0f-de37-ab61-0b1bff54c125@suse.com>
 <36780b96-6db0-ab80-9bb2-d028d6856552@suse.com>
 <c58d88e0-04ce-500d-9216-8b3746a8d03d@suse.com>
 <f7298d04-ba2c-13cc-7f9b-f57e94340fe3@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <d65728ee-5287-3e90-ef44-5c3bb8f6ed77@suse.com>
Date: Thu, 9 Apr 2020 12:35:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f7298d04-ba2c-13cc-7f9b-f57e94340fe3@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 osstest service owner <osstest-admin@xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.2020 12:23, Jürgen Groß wrote:
> On 09.04.20 11:00, Jan Beulich wrote:
>> On 09.04.2020 10:56, Jürgen Groß wrote:
>>> On 09.04.20 10:00, Jan Beulich wrote:
>>>> On 09.04.2020 09:31, Jürgen Groß wrote:
>>>>> On 09.04.20 04:30, osstest service owner wrote:
>>>>>> flight 149520 xen-unstable real [real]
>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/
>>>>>>
>>>>>> Regressions :-(
>>>>>>
>>>>>> Tests which did not succeed and are blocking,
>>>>>> including tests which could not be run:
>>>>>>     test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478
>>>>>>     test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478
>>>>>
>>>>> Is it possible to get the ioemu-stubdom binary used in those tests?
>>>>
>>>> Isn't this the usr/local/lib/xen/boot/ioemu-stubdom.gz in
>>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/build-amd64-xsm/build/dist.tar.gz
>>>
>>> No, the crashed one was a 32-bit stubdom, while this file is a 64-bit
>>> one. According to the log the path should be fine, but the file in no
>>> way matches the crashed one.
>>
>> Then look under http://logs.test-lab.xenproject.org/osstest/logs/149520/build-i386-xsm/build/
>> or any of the other http://logs.test-lab.xenproject.org/osstest/logs/149520/build-*/build/?
>> I'm pretty sure all produced binaries get collected and made available.
> 
> Yes, there it could be found.
> 
> I'm still struggling to understand why the stubdom is built as 32-bit
> binary for this test.

Aiui in test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
the first amd64 stands for the host (Xen) architecture, the
last for the guest one, and the i386 for the tool stack's. I
assume the stubdom binary chosen is picked based on the tool
stack properties, despite it running in a different domain.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 11:17:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 11:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMVBB-0004Xi-Pf; Thu, 09 Apr 2020 11:17:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMVBA-0004Xd-PM
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 11:17:04 +0000
X-Inumbo-ID: a3c5d7a0-7a53-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a3c5d7a0-7a53-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 11:17:04 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 76887ADBE;
 Thu,  9 Apr 2020 11:17:02 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <9c7ec98b-bd2d-4fbf-530a-2164dbbee200@suse.com>
 <20200408151055.GB28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <00c10f30-5502-2b43-b394-efa8137cf264@suse.com>
Date: Thu, 9 Apr 2020 13:16:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200408151055.GB28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.2020 17:10, Roger Pau Monné wrote:
> On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
>> On 06.04.2020 12:57, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm/paging.c
>>> +++ b/xen/arch/x86/mm/paging.c
>>> @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d,
>>>  
>>>      p2m_unlock(p2m);
>>>  
>>> -    flush_tlb_mask(d->dirty_cpumask);
>>> +    flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) |
>>> +                                 FLUSH_HVM_ASID_CORE);
>>
>> In cases where one case is assumed to be more likely than the other
>> putting the more likely one first can be viewed as a mild hint to
>> the compiler, and hence an extra ! may be warranted in an if() or
>> a conditional expression. Here, however, I don't think we can
>> really consider one case more likely than the other, and hence I'd
>> suggest to avoid the !, flipping the other two expressions
>> accordingly. I may take the liberty to adjust this while committing
>> (if I'm to be the one).
> 
> That's fine, thanks. Somehow '!hap -> flush' was clearer in my mind.

Thinking about it with the other HVM-related changes in v9, shouldn't
this then be

    flush_mask(d->dirty_cpumask, (hap_enabled(d) ? 0 : FLUSH_TLB) |
                                 (is_hvm_domain(d) ? FLUSH_HVM_ASID_CORE : 0));

Or wait - the only caller lives in hap.c. As a result the FLUSH_TLB
part can be dropped altogether. And I question the need of flushing
guest TLBs - this is purely a p2m operation. I'll go look at the
history of this function, but for now I think the call should be
dropped (albeit then maybe better in a separate patch).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 11:41:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 11:41:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMVYq-0006vD-Vy; Thu, 09 Apr 2020 11:41:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Mt6Q=5Z=canonical.com=colin.king@srs-us1.protection.inumbo.net>)
 id 1jMVYp-0006v8-Uj
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 11:41:31 +0000
X-Inumbo-ID: 0e6b5f50-7a57-11ea-b4f4-bc764e2007e4
Received: from youngberry.canonical.com (unknown [91.189.89.112])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0e6b5f50-7a57-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 11:41:31 +0000 (UTC)
Received: from 1.general.cking.uk.vpn ([10.172.193.212] helo=localhost)
 by youngberry.canonical.com with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2)
 (envelope-from <colin.king@canonical.com>)
 id 1jMVYc-0004rk-7i; Thu, 09 Apr 2020 11:41:18 +0000
From: Colin King <colin.king@canonical.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
 Bjorn Helgaas <bhelgaas@google.com>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
 "H . Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
 xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org
Subject: [PATCH] xen/pci: remove redundant assignment to variable irq
Date: Thu,  9 Apr 2020 12:41:18 +0100
Message-Id: <20200409114118.249461-1-colin.king@canonical.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Colin Ian King <colin.king@canonical.com>

The variable irq is being initialized with a value that is never read
and it is being updated later with a new value.  The initialization is
redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 arch/x86/pci/xen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 91220cc25854..80272eb49230 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -63,7 +63,7 @@ static int xen_pcifront_enable_irq(struct pci_dev *dev)
 static int xen_register_pirq(u32 gsi, int gsi_override, int triggering,
 			     bool set_pirq)
 {
-	int rc, pirq = -1, irq = -1;
+	int rc, pirq = -1, irq;
 	struct physdev_map_pirq map_irq;
 	int shareable = 0;
 	char *name;
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 11:54:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 11:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMVld-0007rT-6u; Thu, 09 Apr 2020 11:54:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMVlc-0007rO-2W
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 11:54:44 +0000
X-Inumbo-ID: e5e9e7de-7a58-11ea-82b4-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e5e9e7de-7a58-11ea-82b4-12813bfff9fa;
 Thu, 09 Apr 2020 11:54:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DF44DAE30;
 Thu,  9 Apr 2020 11:54:40 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: Roger Pau Monne <roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
Date: Thu, 9 Apr 2020 13:54:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200406105703.79201-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 06.04.2020 12:57, Roger Pau Monne wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
>              p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
>                                    p2m_ram_rw, p2m_ram_logdirty);
>  
> -            flush_tlb_mask(d->dirty_cpumask);
> +            hap_flush_tlb_mask(d->dirty_cpumask);
>  
>              memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
>          }
> @@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
>           * to be read-only, or via hardware-assisted log-dirty.
>           */
>          p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> -        flush_tlb_mask(d->dirty_cpumask);
> +        hap_flush_tlb_mask(d->dirty_cpumask);
>      }
>      return 0;
>  }
> @@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
>       * be read-only, or via hardware-assisted log-dirty.
>       */
>      p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> -    flush_tlb_mask(d->dirty_cpumask);
> +    hap_flush_tlb_mask(d->dirty_cpumask);
>  }
>  
>  /************************************************/
> @@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
>  
>      safe_write_pte(p, new);
>      if ( old_flags & _PAGE_PRESENT )
> -        flush_tlb_mask(d->dirty_cpumask);
> +        hap_flush_tlb_mask(d->dirty_cpumask);
>  
>      paging_unlock(d);
>  

Following up on my earlier mail about paging_log_dirty_range(), I'm
now of the opinion that all of these flushes should go away too. I
can only assume that they got put where they are when HAP code was
cloned from the shadow one. These are only p2m operations, and hence
p2m level TLB flushing is all that's needed here.

> --- a/xen/arch/x86/mm/hap/nested_hap.c
> +++ b/xen/arch/x86/mm/hap/nested_hap.c
> @@ -84,7 +84,7 @@ nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
>      safe_write_pte(p, new);
>  
>      if (old_flags & _PAGE_PRESENT)
> -        flush_tlb_mask(p2m->dirty_cpumask);
> +        hap_flush_tlb_mask(p2m->dirty_cpumask);

Same here then presumably.

As suggested in my earlier reply, the plain removals of flush
invocations would probably better be split out into a separate
patch.

> --- a/xen/arch/x86/mm/hap/private.h
> +++ b/xen/arch/x86/mm/hap/private.h
> @@ -47,4 +47,9 @@ unsigned long hap_p2m_ga_to_gfn_4_levels(struct vcpu *v,
>      struct p2m_domain *p2m, unsigned long cr3,
>      paddr_t ga, uint32_t *pfec, unsigned int *page_order);
>  
> +static inline void hap_flush_tlb_mask(const cpumask_t *mask)
> +{
> +    flush_mask(mask, FLUSH_HVM_ASID_CORE);
> +}

With the above introduction of this would then become unnecessary.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 12:24:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 12:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMWEB-0001vx-LD; Thu, 09 Apr 2020 12:24:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=6Jhw=5Z=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jMWEA-0001vs-Bs
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 12:24:14 +0000
X-Inumbo-ID: 04c5b153-7a5d-11ea-82b6-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 04c5b153-7a5d-11ea-82b6-12813bfff9fa;
 Thu, 09 Apr 2020 12:24:13 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 69218AE38;
 Thu,  9 Apr 2020 12:24:11 +0000 (UTC)
Subject: Re: [PATCH v5 03/10] x86: determine HAVE_AS_* just once
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <6fa81b4d-528d-5c33-50c5-a18396b4383a@suse.com>
 <2c83b876-6fd8-1315-3b28-b45e877187aa@suse.com>
 <7147e3a1-b237-7a2b-d623-b364704d0096@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <cc03fe98-64c1-71c4-146a-ec60d6100f94@suse.com>
Date: Thu, 9 Apr 2020 14:24:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7147e3a1-b237-7a2b-d623-b364704d0096@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Anthony PERARD <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 25.03.2020 22:12, Andrew Cooper wrote:
> On 24/03/2020 12:33, Jan Beulich wrote:
>> With the exception of HAVE_AS_QUOTED_SYM, populate the results into a
>> generated header instead of (at least once per [sub]directory) into
>> CFLAGS. This results in proper rebuilds (via make dependencies) in case
>> the compiler used changes between builds. It additionally eases
>> inspection of which assembler features were actually found usable.
>>
>> Some trickery is needed to avoid header generation itself to try to
>> include the to-be/not-yet-generated header.
>>
>> Since the definitions in generated/config.h, previously having been
>> command line options, might even affect xen/config.h or its descendants,
>> move adding of the -include option for the latter after inclusion of the
>> per-arch Rules.mk. Use the occasion to also move the most general -I
>> option to the common Rules.mk.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Given the work of Anthony's which is already committed in staging, I'd
> really prefer this patch to look something like
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=WIP.x86/asm&id=95ef9f80ed6359e89f988121521c421b7e9528de
> 
> That avoids all fragile games with includes, and is the position we want
> to be in, longterm.

I've thought about this some more, and not just because of the issue
with tool chain updates (or downgrades) I'm not convinced this is the
way to go, irrespective of whether Linux does. I've gone through
Linux'es Kconfig documentation again, and I couldn't find a hint that
this is supposed to cover other than user choices. Determining tool
chain capabilities at build (rather than configure) time seems quite
a bit more reliable to me. IOW there ought to be a clear distinction
between "what kind of kernel [or hypervisor] do I want" and "how does
the kernel [hypervisor] get built".

When it comes to certain user choices requiring certain tool chain
capabilities, then the help text should point this out and the build
should probably be made fail if the prereqs aren't met (alternatively
behavior like that of our xen.efi building could be chosen, with a
warning issued during the build process).

If we (and perhaps also they) clearly stated that the intention is
to also latch system properties (like userland ./configure would do),
and if the intended behavior was clearly spelled out when it comes
to any of those latched properties changing, then I might change my
opinion.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 12:34:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 12:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMWOJ-0002oc-PG; Thu, 09 Apr 2020 12:34:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMWOI-0002oX-PX
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 12:34:42 +0000
X-Inumbo-ID: 7c18c1c6-7a5e-11ea-82b8-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7c18c1c6-7a5e-11ea-82b8-12813bfff9fa;
 Thu, 09 Apr 2020 12:34:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 86ED1AF8A;
 Thu,  9 Apr 2020 12:34:40 +0000 (UTC)
Subject: Re: [xen-unstable test] 149520: regressions - FAIL
To: Jan Beulich <jbeulich@suse.com>
References: <osstest-149520-mainreport@xen.org>
 <74b51d2e-4480-8aea-9069-1214333e799f@suse.com>
 <277afcf8-fc0f-de37-ab61-0b1bff54c125@suse.com>
 <36780b96-6db0-ab80-9bb2-d028d6856552@suse.com>
 <c58d88e0-04ce-500d-9216-8b3746a8d03d@suse.com>
 <f7298d04-ba2c-13cc-7f9b-f57e94340fe3@suse.com>
 <d65728ee-5287-3e90-ef44-5c3bb8f6ed77@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <c2e7afa8-5d17-4c8c-e94b-f647c6797d40@suse.com>
Date: Thu, 9 Apr 2020 14:34:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <d65728ee-5287-3e90-ef44-5c3bb8f6ed77@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 osstest service owner <osstest-admin@xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.20 12:35, Jan Beulich wrote:
> On 09.04.2020 12:23, Jürgen Groß wrote:
>> On 09.04.20 11:00, Jan Beulich wrote:
>>> On 09.04.2020 10:56, Jürgen Groß wrote:
>>>> On 09.04.20 10:00, Jan Beulich wrote:
>>>>> On 09.04.2020 09:31, Jürgen Groß wrote:
>>>>>> On 09.04.20 04:30, osstest service owner wrote:
>>>>>>> flight 149520 xen-unstable real [real]
>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/
>>>>>>>
>>>>>>> Regressions :-(
>>>>>>>
>>>>>>> Tests which did not succeed and are blocking,
>>>>>>> including tests which could not be run:
>>>>>>>      test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478
>>>>>>>      test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478
>>>>>>
>>>>>> Is it possible to get the ioemu-stubdom binary used in those tests?
>>>>>
>>>>> Isn't this the usr/local/lib/xen/boot/ioemu-stubdom.gz in
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/build-amd64-xsm/build/dist.tar.gz
>>>>
>>>> No, the crashed one was a 32-bit stubdom, while this file is a 64-bit
>>>> one. According to the log the path should be fine, but the file in no
>>>> way matches the crashed one.
>>>
>>> Then look under http://logs.test-lab.xenproject.org/osstest/logs/149520/build-i386-xsm/build/
>>> or any of the other http://logs.test-lab.xenproject.org/osstest/logs/149520/build-*/build/?
>>> I'm pretty sure all produced binaries get collected and made available.
>>
>> Yes, there it could be found.
>>
>> I'm still struggling to understand why the stubdom is built as 32-bit
>> binary for this test.
> 
> Aiui in test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> the first amd64 stands for the host (Xen) architecture, the
> last for the guest one, and the i386 for the tool stack's. I
> assume the stubdom binary chosen is picked based on the tool
> stack properties, despite it running in a different domain.

I have managed to reproduce the problem.

It happens only in 32-bit ioemu-stubdom, not in 64-bit.

It happens only with the guest's vif configured with "type=ioemu".

This makes Mini-OS commit d225f4012d69a19 suspicious, and I think
I have found a double free() in it.

Will send a patch.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 12:51:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 12:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMWds-0004Q0-CD; Thu, 09 Apr 2020 12:50:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMWdr-0004Pv-7J
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 12:50:47 +0000
X-Inumbo-ID: bafb0ba4-7a60-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bafb0ba4-7a60-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 12:50:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E2908AE30;
 Thu,  9 Apr 2020 12:50:44 +0000 (UTC)
Subject: Re: [PATCH] sched: fix scheduler_disable() with core scheduling
To: Sergey Dyasli <sergey.dyasli@citrix.com>, xen-devel@lists.xenproject.org
References: <20200409094137.13836-1-sergey.dyasli@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <8db96ff6-53e3-8c01-0737-5181ccc348ab@suse.com>
Date: Thu, 9 Apr 2020 14:50:44 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200409094137.13836-1-sergey.dyasli@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.20 11:41, Sergey Dyasli wrote:
> In core-scheduling mode, Xen might crash when entering ACPI S5 state.
> This happens in sched_slave() during is_idle_unit(next) check because
> next->vcpu_list is stale and points to an already freed memory.
> 
> This situation happens shortly after scheduler_disable() is called if
> some CPU is still inside sched_slave() softirq. Current logic simply
> returns prev->next_task from sched_wait_rendezvous_in() which causes
> the described crash because next_task->vcpu_list has become invalid.
> 
> Fix the crash by returning NULL from sched_wait_rendezvous_in() in
> the case when scheduler_disable() has been called.
> 
> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>

Good catch!

Have you seen any further problems (e.g. with cpu on/offlining) with
this patch applied?

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 12:56:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 12:56:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMWjF-0004au-0x; Thu, 09 Apr 2020 12:56:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=EhrS=5Z=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMWjD-0004ap-7i
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 12:56:19 +0000
X-Inumbo-ID: 7fdc7751-7a61-11ea-82bb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7fdc7751-7a61-11ea-82bb-12813bfff9fa;
 Thu, 09 Apr 2020 12:56:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=QnIf7sO8JBb4sRdDD/0aB6hF2HLlJWmgiq5xYz30oX0=; b=zwNsSZ+SICPwt5+5PjaSbsbqGv
 NuLjf40to+5Nc14GDn+jr0ZjXYFUgMWMYyh1CU8bjssEzB6g6KttDKrgQhCtsBJpZ4D3G8CJ3/P7w
 RtWXc7FfxcZr3PZd6o+uqvwgja8+3m69DTzTmBMnzEqY5oVWcTUR0V3ShKQ8PGeav1Zo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMWj5-0005Kq-CA; Thu, 09 Apr 2020 12:56:11 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMWj5-0006wk-18; Thu, 09 Apr 2020 12:56:11 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Stefano Stabellini <stefano.stabellini@xilinx.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
 <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
 <057f48b7-84be-0bc5-773d-d01a79181b20@xen.org>
 <alpine.DEB.2.21.2004081642070.28673@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <914c421a-02cf-375b-a3fa-1c5e934cdeb3@xen.org>
Date: Thu, 9 Apr 2020 13:56:08 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004081642070.28673@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, George Dunlap <George.Dunlap@citrix.com>,
 Wei Xu <xuwei5@hisilicon.com>, Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 09/04/2020 02:26, Stefano Stabellini wrote:
> On Tue, 7 Apr 2020, Julien Grall wrote:
>>>>> I don’t know what maintenance IRQs are, but if they only happen
>>>>> intermittently, it’s possible that you’d never get more than a single
>>>>> one in a latency-critical IRQ routine; and as such, the variatibility in
>>>>> execution time (jitter) wouldn’t be an issue in practice.  But every
>>>>> time you add a new unblockable IPI, you increase this jitter;
>>>>> particularly if this unblockable IPI might be repeated an arbitrary
>>>>> number of times.
>>>>> (Stefano, let me know if I’ve misunderstood something.)
>>>>> So stepping back a moment, here’s all the possible ideas that I think
>>>>> have been discussed (or are there implicitly) so far.
>>>>> 1. [Default] Do nothing; guests using this register continue crashing
>>>>> 2. Make the I?ACTIVER registers RZWI.
>>>>> 3. Make I?ACTIVER return the most recent known value; i.e. KVM’s current
>>>>> behavior (as far as we understand it)
>>>>> 4. Use a simple IPI with do_noop to update I?ACTIVER
>>>>> 4a.  Use an IPI, but come up with clever tricks to avoid interrupting
>>>>> guests handling IRQs.
>>>>> 5. Trap to Xen on guest EOI, so that we know when the
>>>>> 6. Some clever paravirtualized option
>>>>
>>>> 7. Use an IPI if we are confident the interrupts may be active.
>>>
>>> I don’t understand this one.  How is it different than 4 or 4a?  And in
>>> particular, how does it evaluate on the “how much additional design work
>>> would it take” criteria?
>>
>> Let me start with, if we want to have a vGIC to rule them all, then I am
>> afraid you are going to have to compromise. We can discuss about tailoring the
>> vGIC but I think before that we need a vGIC that is faithfull with the spec
>> (e.g differentiating level vs edge interrupts, handling activer...). Note that
>> Arm spent some effort to get a new vGIC merged but this was never made a first
>> class citizen.
>>
>> However, even if you tailor the vGIC, you are not going to be able to avoid
>> IPI in some occasions. This would happen when using event channels, in-guest
>> IPI... Another example is when enabling an interrupt, although I realize that
>> our vGIC does not do it today meaning that a pending interrupt while disabled
>> will not be forwarded until the vCPU exit.
>>
>> Furthermore, implementing a write to I{C,S}ACTIVER (to activate/de-activate)
>> is going to be very difficult (to not say impossible) to do without IPI.
>>
>> If you are worry about a vCPU been interrupted in critical section, then I
>> think you should tailor your guest to avoid using those registers.
> 
> Let's call it option 8 "tell the user that she needs to modify her
> kernel."
> 
> 
>> An alternative would be to use spinlock/mutex within the code to prevent a
>> VCPU to access the vGIC registers while another vCPU don't want to be
>> interrupted.
>>
>> Regarding, 4a. The only way I could think of would be to trap the instructions
>> that mask/unmask interrupts. If I read correctly the Armv8 spec, it is not
>> possible to do it.
>>
>> 7. is basically 4.a the goal would be to avoid interrupts the vCPU has much as
>> possible but you may be wrong sometimes. Obviously we want to be correct most
>> of the times.
>>
>> I understand this may not be the ideal solution, but this is probably the best
>> we could come with and does not involve a lot of work because we have already
>> all the information in place (we know when an interrupt was injected to a
>> vCPU).
>>
>> The next best solution is to prevent in your guest to modify some registers of
>> the vGIC at the same time as another vCPU is in a critical section.
> 
> Let's call this option 9.
> 
> 
> I am just thinking out loud here :)

Thank you for thinking out loud. Sadly, as I pointed out before, there 
are other part of the vGIC facing the same problems (e.g I{S,C}ENABLER, 
sending SGIs, sending event channels).

So can you enlighten me why I{S,C}ENABLER is that much a concern over 
the other?

> 
> 
> - 2 "Make the I?ACTIVER registers RZWI"
> 
>    As far as I can tell it should prevent the livelock because it would
>    never return an ACTIVE state. It could be improved by returning the
>    latest ACTIVE information for local interrupts and returning zero for
>    interrupts routed to other pcpus. Not perfect but an option.

How a partial implementation will help? Wouldn't this make more 
difficult for a developper?

Bear in mind that on GICv3 you can read the information all the 
re-distributors information (not only yours).

> 
> 
> - 5 "maintenance interrupt"
> 
>    This is good for jitter sensitive guests but not the best for the
>    others. We could enable it conditionally: enable maintenance
>    interrupts only for certain vcpus/pcpus but it is not great to have to
>    make this kind of difference in the implementation. However, it is
>    possible. Let's see if we can come up with something better.
> 
> 
> - 7 "optimized IPI"
>   
>    A tiny chance of causing issues. Let's see if we can come up with
>    anything better.
> 
> 
> - 8 "tell the user to fix modify the kernel"
> 
>    We could do it in addition to 7. The issue is really how we do it.
>    A warning message if DEBUG && if sched==null? That doesn't sound
>    right. We could introduce a new nojitter=true command line option for
>    Xen? It wouldn't really change the behavior of Xen, but it would
>    enable this warning. Or, it could enable the warning and also switch
>    the implementation of I?ACTIVER to option 2.

This is not a sched=null specific problem. The problem would exactly be 
the same when you are dedicating a pCPU to a vCPU on credit and credit2.

> 
> 
> - 9 "prevent I?ACTIVER during critical sections"
> 
>    This could be good but I have a difficult time thinking of how we
>    could implement it. How do we tell that the other vcpu is in or out of
>    the critical section?

I believe you misread what I wrote. I didn't suggest Xen would do it but 
the guest will do it. As the vCPUs belongs to the same guest.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 13:00:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 13:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMWnP-0005PT-Jd; Thu, 09 Apr 2020 13:00:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=EhrS=5Z=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMWnO-0005PO-PW
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 13:00:38 +0000
X-Inumbo-ID: 1bd40466-7a62-11ea-82bb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1bd40466-7a62-11ea-82bb-12813bfff9fa;
 Thu, 09 Apr 2020 13:00:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=yZzXbob8CmPmLLKUYerA6jZ4V2JVSnNCJdv+dslrjlk=; b=p+uHpaa4GyrOba5sZSbIRDu6t4
 HGcTSdfsuc5fJgYGT9m8z7MX5D/bVVOi9Cuukk/myQy5IfAlTb4HhaTXH42w0M8Ulvpuldwz4K9rt
 eO8G/t223s0uqRDZbmgg2Co/0JonoTQ97u5N9dGs64uv1xQIWDdMDzl6Emsgc6j6N5hY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMWnI-0005SH-VN; Thu, 09 Apr 2020 13:00:32 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMWnI-0007Iw-Ky; Thu, 09 Apr 2020 13:00:32 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
From: Julien Grall <julien@xen.org>
To: Stefano Stabellini <stefano.stabellini@xilinx.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
 <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
 <057f48b7-84be-0bc5-773d-d01a79181b20@xen.org>
 <alpine.DEB.2.21.2004081642070.28673@sstabellini-ThinkPad-T480s>
 <914c421a-02cf-375b-a3fa-1c5e934cdeb3@xen.org>
Message-ID: <3b002deb-5a80-3dc4-9462-649135cfbd29@xen.org>
Date: Thu, 9 Apr 2020 14:00:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <914c421a-02cf-375b-a3fa-1c5e934cdeb3@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, George Dunlap <George.Dunlap@citrix.com>,
 Wei Xu <xuwei5@hisilicon.com>, Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 09/04/2020 13:56, Julien Grall wrote:
> 
> 
> On 09/04/2020 02:26, Stefano Stabellini wrote:
>> On Tue, 7 Apr 2020, Julien Grall wrote:
>>>>>> I don’t know what maintenance IRQs are, but if they only happen
>>>>>> intermittently, it’s possible that you’d never get more than a single
>>>>>> one in a latency-critical IRQ routine; and as such, the 
>>>>>> variatibility in
>>>>>> execution time (jitter) wouldn’t be an issue in practice.  But every
>>>>>> time you add a new unblockable IPI, you increase this jitter;
>>>>>> particularly if this unblockable IPI might be repeated an arbitrary
>>>>>> number of times.
>>>>>> (Stefano, let me know if I’ve misunderstood something.)
>>>>>> So stepping back a moment, here’s all the possible ideas that I think
>>>>>> have been discussed (or are there implicitly) so far.
>>>>>> 1. [Default] Do nothing; guests using this register continue crashing
>>>>>> 2. Make the I?ACTIVER registers RZWI.
>>>>>> 3. Make I?ACTIVER return the most recent known value; i.e. KVM’s 
>>>>>> current
>>>>>> behavior (as far as we understand it)
>>>>>> 4. Use a simple IPI with do_noop to update I?ACTIVER
>>>>>> 4a.  Use an IPI, but come up with clever tricks to avoid interrupting
>>>>>> guests handling IRQs.
>>>>>> 5. Trap to Xen on guest EOI, so that we know when the
>>>>>> 6. Some clever paravirtualized option
>>>>>
>>>>> 7. Use an IPI if we are confident the interrupts may be active.
>>>>
>>>> I don’t understand this one.  How is it different than 4 or 4a?  And in
>>>> particular, how does it evaluate on the “how much additional design 
>>>> work
>>>> would it take” criteria?
>>>
>>> Let me start with, if we want to have a vGIC to rule them all, then I am
>>> afraid you are going to have to compromise. We can discuss about 
>>> tailoring the
>>> vGIC but I think before that we need a vGIC that is faithfull with 
>>> the spec
>>> (e.g differentiating level vs edge interrupts, handling activer...). 
>>> Note that
>>> Arm spent some effort to get a new vGIC merged but this was never 
>>> made a first
>>> class citizen.
>>>
>>> However, even if you tailor the vGIC, you are not going to be able to 
>>> avoid
>>> IPI in some occasions. This would happen when using event channels, 
>>> in-guest
>>> IPI... Another example is when enabling an interrupt, although I 
>>> realize that
>>> our vGIC does not do it today meaning that a pending interrupt while 
>>> disabled
>>> will not be forwarded until the vCPU exit.
>>>
>>> Furthermore, implementing a write to I{C,S}ACTIVER (to 
>>> activate/de-activate)
>>> is going to be very difficult (to not say impossible) to do without IPI.
>>>
>>> If you are worry about a vCPU been interrupted in critical section, 
>>> then I
>>> think you should tailor your guest to avoid using those registers.
>>
>> Let's call it option 8 "tell the user that she needs to modify her
>> kernel."
>>
>>
>>> An alternative would be to use spinlock/mutex within the code to 
>>> prevent a
>>> VCPU to access the vGIC registers while another vCPU don't want to be
>>> interrupted.
>>>
>>> Regarding, 4a. The only way I could think of would be to trap the 
>>> instructions
>>> that mask/unmask interrupts. If I read correctly the Armv8 spec, it 
>>> is not
>>> possible to do it.
>>>
>>> 7. is basically 4.a the goal would be to avoid interrupts the vCPU 
>>> has much as
>>> possible but you may be wrong sometimes. Obviously we want to be 
>>> correct most
>>> of the times.
>>>
>>> I understand this may not be the ideal solution, but this is probably 
>>> the best
>>> we could come with and does not involve a lot of work because we have 
>>> already
>>> all the information in place (we know when an interrupt was injected 
>>> to a
>>> vCPU).
>>>
>>> The next best solution is to prevent in your guest to modify some 
>>> registers of
>>> the vGIC at the same time as another vCPU is in a critical section.
>>
>> Let's call this option 9.
>>
>>
>> I am just thinking out loud here :)
> 
> Thank you for thinking out loud. Sadly, as I pointed out before, there 
> are other part of the vGIC facing the same problems (e.g I{S,C}ENABLER, 
> sending SGIs, sending event channels).
> 
> So can you enlighten me why I{S,C}ENABLER is that much a concern over 
> the other?

To be clear, I am not saying I{S,C}ENABLER should not be a concern. But 
I would prefer if we focus on a generic solution if the problem is wider.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 13:21:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 13:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMX7n-00076A-Hv; Thu, 09 Apr 2020 13:21:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Jqn0=5Z=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMX7l-000765-Rv
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 13:21:41 +0000
X-Inumbo-ID: 0bbfbf0e-7a65-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0bbfbf0e-7a65-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 13:21:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ms5tHXeJytJdAIA7fYAY3qwTujNYfoRJv+sxXUj1RXA=; b=gB6pFNYftZk5laEkqrD58D7ST
 kBKbXGFOP9ttEePvtcOgd36CtzyuTjRJobdha9VuMLvEC4ZcC9H7YTvKzBq5W7Q81LdGHmdwarePw
 2l8Az/Vyoy8Z7pNYV7vv3flh6B8aK9z5TUcAdkM7s3w2TJi0yOdBCuEgA+4QAdViRK52o=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMX7j-0005qF-5e; Thu, 09 Apr 2020 13:21:39 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMX7i-0003Lu-VE; Thu, 09 Apr 2020 13:21:39 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMX7i-00014z-UX; Thu, 09 Apr 2020 13:21:38 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149547-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149547: regressions - FAIL
X-Osstest-Failures: xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:debian-hvm-install:fail:regression
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=9be0b2747bc7381c684cfbdd3fa2e40badefbeef
X-Osstest-Versions-That: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 09 Apr 2020 13:21:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     16 guest-localmigrate           fail  like 149478
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149478
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149478
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149478
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149478
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149478
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149478
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149478
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149478
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149478
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  9be0b2747bc7381c684cfbdd3fa2e40badefbeef
baseline version:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd

Last test of basis   149478  2020-04-07 01:51:22 Z    2 days
Failing since        149502  2020-04-08 00:06:59 Z    1 days    3 attempts
Testing same since   149547  2020-04-09 02:36:26 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Julien Grall <jgrall@amazon.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        fail    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit 9be0b2747bc7381c684cfbdd3fa2e40badefbeef
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Apr 8 13:12:28 2020 +0200

    x86/PoD: correct ordering of checks in p2m_pod_zero_check()
    
    Commit 0537d246f8db ("mm: add 'is_special_page' inline function...")
    moved the is_special_page() checks first in its respective changes to
    PoD code. While this is fine for p2m_pod_zero_check_superpage(), the
    validity of the MFN is inferred in both cases from the p2m_is_ram()
    check, which therefore also needs to come first in this 2nd instance.
    
    Take the opportunity and address latent UB here as well - transform
    the MFN into struct page_info * only after having established that
    this is a valid page.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit d3ff3e48db4a59d1972bcdeb08cac22048d14b27
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Apr 8 13:11:24 2020 +0200

    x86/HVM: __hvm_copy()'s size parameter is an unsigned quantity
    
    There are no negative sizes. Make the function's parameter as well as
    that of its derivates "unsigned int". Similarly make its local "count"
    variable "unsigned int", and drop "todo" altogether. Don't use min_t()
    anymore to calculate "count". Restrict its scope as well as that of
    other local variables of the function.
    
    While at it I've also noticed that {copy_{from,to},clear}_user_hvm()
    have been returning "unsigned long" for no apparent reason, as their
    respective "size" parameters have already been "unsigned int". Adjust
    this as well as a slightly wrong comment there at the same time.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Paul Durrant <pdurrant@amzn.com>

commit c8dbdb32cef8e8ef796c925e91e347ea83735790
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date:   Wed Apr 8 13:03:50 2020 +0200

    mem_sharing: reset a fork
    
    Implement hypercall that allows a fork to shed all memory that got allocated
    for it during its execution and re-load its vCPU context from the parent VM.
    This allows the forked VM to reset into the same state the parent VM is in a
    faster way then creating a new fork would be. Measurements show about a 2x
    speedup during normal fuzzing operations. Performance may vary depending how
    much memory got allocated for the forked VM. If it has been completely
    deduplicated from the parent VM then creating a new fork would likely be more
    performant.
    
    Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
    Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

commit 41548c5472a3ea514cb0173f2576096970358263
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date:   Wed Apr 8 12:59:58 2020 +0200

    mem_sharing: VM forking
    
    VM forking is the process of creating a domain with an empty memory space and a
    parent domain specified from which to populate the memory when necessary. For
    the new domain to be functional the VM state is copied over as part of the fork
    operation (HVM params, hap allocation, etc).
    
    Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
    Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Julien Grall <jgrall@amazon.com>

commit e013e8514389b739153016349e49f5a78e34ddf0
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Apr 7 15:48:31 2020 +0200

    config: use mini-os master for unstable
    
    We haven't used mini-os master for about 2 years now due to a stubdom
    test failing [1]. Booting a guest with mini-os master used for building
    stubdom didn't reveal any problem, so use master for unstable in order
    to let OSStest find any problems not showing up in the local test.
    
    [1]: https://lists.xen.org/archives/html/minios-devel/2018-04/msg00015.html
    
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Acked-by: Wei Liu <wl@xen.org>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:12:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:12:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMXvK-0002oV-Ca; Thu, 09 Apr 2020 14:12:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMXvI-0002oI-RA
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:12:52 +0000
X-Inumbo-ID: 2efc5962-7a6c-11ea-82d6-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2efc5962-7a6c-11ea-82d6-12813bfff9fa;
 Thu, 09 Apr 2020 14:12:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E6972AD72;
 Thu,  9 Apr 2020 14:12:43 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 1/3] mini-os: fix double free() in netfront
Date: Thu,  9 Apr 2020 16:12:38 +0200
Message-Id: <20200409141240.28876-2-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200409141240.28876-1-jgross@suse.com>
References: <20200409141240.28876-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, samuel.thibault@ens-lyon.org, wl@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit d225f4012d69a19 ("Save/Restore Support: Add suspend/restore
support for netfront") introduced a regression in form of freeing a
netfront device structure twice.

Fix that.

Coverity-ID: 1433637
Fixes: d225f4012d69a19 ("Save/Restore Support: Add suspend/restore support for netfront")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 netfront.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/netfront.c b/netfront.c
index 50b3a57..fe7bb62 100644
--- a/netfront.c
+++ b/netfront.c
@@ -584,8 +584,6 @@ void shutdown_netfront(struct netfront_dev *dev)
     list->refcount--;
     if (list->refcount == 0) {
         _shutdown_netfront(dev);
-        free(dev->nodename);
-        free(dev);
 
         to_del = list;
         if (to_del == dev_list) {
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:12:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:12:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMXvF-0002nv-2C; Thu, 09 Apr 2020 14:12:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMXvD-0002nk-T3
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:12:47 +0000
X-Inumbo-ID: 2f0d72f6-7a6c-11ea-82d6-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2f0d72f6-7a6c-11ea-82d6-12813bfff9fa;
 Thu, 09 Apr 2020 14:12:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0607EAE59;
 Thu,  9 Apr 2020 14:12:43 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 2/3] mini-os: fix double free() in xenbus
Date: Thu,  9 Apr 2020 16:12:39 +0200
Message-Id: <20200409141240.28876-3-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200409141240.28876-1-jgross@suse.com>
References: <20200409141240.28876-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, samuel.thibault@ens-lyon.org, wl@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit 973ad0c4de1b48 ("Save/Restore Support: Add suspend/restore
support for xenbus") introduced a double free of some memory and leaked
another memory allocation.

Fix those.

Coverity-ID: 1433640
Fixes: 973ad0c4de1b48 ("Save/Restore Support: Add suspend/restore support for xenbus")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xenbus/xenbus.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
index d72dc3a..b12cef7 100644
--- a/xenbus/xenbus.c
+++ b/xenbus/xenbus.c
@@ -413,9 +413,11 @@ void resume_xenbus(int canceled)
 
             rep = xenbus_msg_reply(XS_WATCH, XBT_NIL, req, ARRAY_SIZE(req));
             msg = errmsg(rep);
-            if (msg)
+            if (msg) {
                 xprintk("error on XS_WATCH: %s\n", msg);
-            free(rep);
+                free(msg);
+            } else
+                free(rep);
         }
     }
 
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:12:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:12:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMXvD-0002nl-QN; Thu, 09 Apr 2020 14:12:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMXvC-0002nf-Jx
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:12:46 +0000
X-Inumbo-ID: 2ef84fb6-7a6c-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2ef84fb6-7a6c-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 14:12:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CD799AD6C;
 Thu,  9 Apr 2020 14:12:43 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 0/3] mini-os: fix several double frees and memory leaks
Date: Thu,  9 Apr 2020 16:12:37 +0200
Message-Id: <20200409141240.28876-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, samuel.thibault@ens-lyon.org, wl@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This series fixes two double free() introduced by suspend/resume
patches and several memory leaks.

Juergen Gross (3):
  mini-os: fix double free() in netfront
  mini-os: fix double free() in xenbus
  mini-os: fix several memory leaks related to xenbus

 blkfront.c       |  4 ++--
 console/xenbus.c |  2 +-
 fbfront.c        |  4 ++--
 netfront.c       |  4 +---
 pcifront.c       | 28 +++++++++++++---------------
 shutdown.c       |  2 +-
 xenbus/xenbus.c  |  8 ++++++--
 7 files changed, 26 insertions(+), 26 deletions(-)

-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:13:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:13:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMXvR-0002sl-TY; Thu, 09 Apr 2020 14:13:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMXvR-0002sX-HH
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:13:01 +0000
X-Inumbo-ID: 2f29d108-7a6c-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2f29d108-7a6c-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 14:12:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2EF93AF6E;
 Thu,  9 Apr 2020 14:12:44 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 3/3] mini-os: fix several memory leaks related to xenbus
Date: Thu,  9 Apr 2020 16:12:40 +0200
Message-Id: <20200409141240.28876-4-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200409141240.28876-1-jgross@suse.com>
References: <20200409141240.28876-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, samuel.thibault@ens-lyon.org, wl@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

There are several instances of calls to xenbus functions which don't
test for an error and in consequence are not freeing the returned
error strings, or which are just not freeing the string after e.g.
printing it.

Fix that by either adding the needed calls of free().

Coverity-ID: 1433632
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 blkfront.c       |  4 ++--
 console/xenbus.c |  2 +-
 fbfront.c        |  4 ++--
 netfront.c       |  2 +-
 pcifront.c       | 28 +++++++++++++---------------
 shutdown.c       |  2 +-
 xenbus/xenbus.c  |  2 ++
 7 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/blkfront.c b/blkfront.c
index f747216..834a978 100644
--- a/blkfront.c
+++ b/blkfront.c
@@ -200,7 +200,7 @@ done:
 
         snprintf(path, sizeof(path), "%s/state", dev->backend);
 
-        xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
+        free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
 
         msg = NULL;
         state = xenbus_read_integer(path);
@@ -208,7 +208,7 @@ done:
             msg = xenbus_wait_for_state_change(path, &state, &dev->events);
         if (msg != NULL || state != XenbusStateConnected) {
             printk("backend not available, state=%d\n", state);
-            xenbus_unwatch_path_token(XBT_NIL, path, path);
+            free(xenbus_unwatch_path_token(XBT_NIL, path, path));
             goto error;
         }
 
diff --git a/console/xenbus.c b/console/xenbus.c
index 654b469..05fc31c 100644
--- a/console/xenbus.c
+++ b/console/xenbus.c
@@ -164,7 +164,7 @@ done:
         char path[strlen(dev->backend) + strlen("/state") + 1];
         snprintf(path, sizeof(path), "%s/state", dev->backend);
         
-	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
+	free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
         msg = NULL;
         state = xenbus_read_integer(path);
         while (msg == NULL && state < XenbusStateConnected)
diff --git a/fbfront.c b/fbfront.c
index 9cc07b4..d3b3848 100644
--- a/fbfront.c
+++ b/fbfront.c
@@ -163,7 +163,7 @@ done:
 
         snprintf(path, sizeof(path), "%s/state", dev->backend);
 
-        xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
+        free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
 
         err = NULL;
         state = xenbus_read_integer(path);
@@ -530,7 +530,7 @@ done:
 
         snprintf(path, sizeof(path), "%s/state", dev->backend);
 
-        xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
+        free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
 
         err = NULL;
         state = xenbus_read_integer(path);
diff --git a/netfront.c b/netfront.c
index fe7bb62..66f2bbc 100644
--- a/netfront.c
+++ b/netfront.c
@@ -513,7 +513,7 @@ done:
             err = xenbus_wait_for_state_change(path, &state, &dev->events);
         if (state != XenbusStateConnected) {
             printk("backend not avalable, state=%d\n", state);
-            xenbus_unwatch_path_token(XBT_NIL, path, path);
+            free(xenbus_unwatch_path_token(XBT_NIL, path, path));
             goto error;
         }
 
diff --git a/pcifront.c b/pcifront.c
index 0fc5b30..5642356 100644
--- a/pcifront.c
+++ b/pcifront.c
@@ -70,28 +70,28 @@ void pcifront_watches(void *opaque)
 
     while (1) {
         printk("pcifront_watches: waiting for backend path to appear %s\n", path);
-        xenbus_watch_path_token(XBT_NIL, path, path, &events);
+        free(xenbus_watch_path_token(XBT_NIL, path, path, &events));
         while ((err = xenbus_read(XBT_NIL, path, &be_path)) != NULL) {
             free(err);
             xenbus_wait_for_watch(&events);
         }
-        xenbus_unwatch_path_token(XBT_NIL, path, path);
+        free(xenbus_unwatch_path_token(XBT_NIL, path, path));
         printk("pcifront_watches: waiting for backend to get into the right state %s\n", be_path);
         be_state = (char *) malloc(strlen(be_path) +  7);
         snprintf(be_state, strlen(be_path) +  7, "%s/state", be_path);
-        xenbus_watch_path_token(XBT_NIL, be_state, be_state, &events);
+        free(xenbus_watch_path_token(XBT_NIL, be_state, be_state, &events));
         while ((err = xenbus_read(XBT_NIL, be_state, &msg)) != NULL || msg[0] > '4') {
             free(msg);
             free(err);
             xenbus_wait_for_watch(&events);
         }
-        xenbus_unwatch_path_token(XBT_NIL, be_state, be_state);
+        free(xenbus_unwatch_path_token(XBT_NIL, be_state, be_state));
         if (init_pcifront(NULL) == NULL) {
             free(be_state);
             free(be_path);
             continue;
         }
-        xenbus_watch_path_token(XBT_NIL, be_state, be_state, &events);
+        free(xenbus_watch_path_token(XBT_NIL, be_state, be_state, &events));
         state = XenbusStateConnected;
         printk("pcifront_watches: waiting for backend events %s\n", be_state);
         while ((err = xenbus_wait_for_state_change(be_state, &state, &events)) == NULL &&
@@ -103,10 +103,9 @@ void pcifront_watches(void *opaque)
                 if ((err = xenbus_switch_state(XBT_NIL, fe_state, XenbusStateReconfiguring)) != NULL) {
                     printk("pcifront_watches: error changing state to %d: %s\n",
                             XenbusStateReconfiguring, err);
-                    if (!strcmp(err, "ENOENT")) {
-                        xenbus_write(XBT_NIL, fe_state, "7");
-                        free(err);
-                    }
+                    if (!strcmp(err, "ENOENT"))
+                        free(xenbus_write(XBT_NIL, fe_state, "7"));
+                    free(err);
                 }
             } else if (state == XenbusStateReconfigured) {
                 printk("pcifront_watches: writing %s %d\n", fe_state, XenbusStateConnected);
@@ -114,10 +113,9 @@ void pcifront_watches(void *opaque)
                 if ((err = xenbus_switch_state(XBT_NIL, fe_state, XenbusStateConnected)) != NULL) {
                     printk("pcifront_watches: error changing state to %d: %s\n",
                             XenbusStateConnected, err);
-                    if (!strcmp(err, "ENOENT")) {
-                        xenbus_write(XBT_NIL, fe_state, "4");
-                        free(err);
-                    }
+                    if (!strcmp(err, "ENOENT"))
+                        free(xenbus_write(XBT_NIL, fe_state, "4"));
+                    free(err);
                 }
             } else if (state == XenbusStateClosing)
                 break;
@@ -135,7 +133,7 @@ void pcifront_watches(void *opaque)
         pcidev = NULL;
     }
 
-    xenbus_unwatch_path_token(XBT_NIL, path, path);
+    free(xenbus_unwatch_path_token(XBT_NIL, path, path));
 }
 
 struct pcifront_dev *init_pcifront(char *_nodename)
@@ -243,7 +241,7 @@ done:
         XenbusState state;
         snprintf(path, sizeof(path), "%s/state", dev->backend);
 
-        xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
+        free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
 
         err = NULL;
         state = xenbus_read_integer(path);
diff --git a/shutdown.c b/shutdown.c
index c7c92cb..4c0b13c 100644
--- a/shutdown.c
+++ b/shutdown.c
@@ -71,7 +71,7 @@ static void shutdown_thread(void *p)
     char *shutdown, *err;
     unsigned int shutdown_reason;
 
-    xenbus_watch_path_token(XBT_NIL, path, token, &events);
+    free(xenbus_watch_path_token(XBT_NIL, path, token, &events));
 
     for ( ;; ) {
         xenbus_wait_for_watch(&events);
diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
index b12cef7..9e61930 100644
--- a/xenbus/xenbus.c
+++ b/xenbus/xenbus.c
@@ -198,6 +198,8 @@ exit:
         }
         if (msg == NULL && msg2 != NULL)
             msg = msg2;
+        else
+            free(msg2);
     } while (retry);
 
     return msg;
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:28:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYAL-00048K-EP; Thu, 09 Apr 2020 14:28:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VOqT=5Z=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMYAK-00048B-5o
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:28:24 +0000
X-Inumbo-ID: 5e2c2c2e-7a6e-11ea-82d8-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5e2c2c2e-7a6e-11ea-82d8-12813bfff9fa;
 Thu, 09 Apr 2020 14:28:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
 MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=88CLnI9d7vqlxpuj08ZyNiGa+C1+B5g5kceeRwldYQw=; b=po8LC+iHiziy3E2x/Sb34Szt44
 iStb7gSnx4kP/LR9uZ+C2vryyP6l98PNHg54l8mzGKJORo1GC7Dl6jHR3cTCFKvbnJZY72/dZhAR4
 w8fdyOBDM8fhMhaDd4yJNPaUl23wnaPUU6iM0ZN92lVm/ppPnP/rGK4KXDrHgdMMLsPk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYAC-0007As-PA; Thu, 09 Apr 2020 14:28:16 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYAC-00041C-Ep; Thu, 09 Apr 2020 14:28:16 +0000
Date: Thu, 9 Apr 2020 15:28:13 +0100
From: Wei Liu <wl@xen.org>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Subject: Re: Use of VM_IOREMAP in xenbus
Message-ID: <20200409142813.lbxembj7b63b2wmi@debian>
References: <20200409061846.GA30241@lst.de>
 <8074b77d-d784-95ee-8d47-069827855876@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8074b77d-d784-95ee-8d47-069827855876@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Konrad Wilk <konrad.wilk@oracle.com>, "Durrant, Paul" <pdurrant@amazon.com>,
 linux-kernel@vger.kernel.org, Bob Liu <bob.liu@oracle.com>,
 xen-devel@lists.xenproject.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Christoph Hellwig <hch@lst.de>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Christoph

On Thu, Apr 09, 2020 at 08:37:48AM +0200, J�rgen Gro� wrote:
> Adjusting recipient list (dropping David, new mail addresses for Wei and
> Paul).
> 
> On 09.04.20 08:18, Christoph Hellwig wrote:
> > Hi Wei,
> > 
> > commit ccc9d90a9a8b5 ("xenbus_client: Extend interface to support
> > multi-page ring") addes a use of vmap in what is now
> > xenbus_map_ring_valloc_hvm, and uses the VM_IOREMAP flag that is
> > only really intended for implementing ioremap.  Do you remember
> > what the reason is that this flag was used?
> > 

I don't remember the reason. I can that flag can be dropped per your
reasoning.

Wei.

> 
> Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:30:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:30:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYCj-0004rv-Sk; Thu, 09 Apr 2020 14:30:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VOqT=5Z=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMYCi-0004rp-8j
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:30:52 +0000
X-Inumbo-ID: b690e030-7a6e-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b690e030-7a6e-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 14:30:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=TcXAQwYo1T1uzYbPEEq6FUW+WO1mQOQ5F8v24cUA3R4=; b=1XCpEbu8v1+nsFhte31j7Kc0Jo
 ysCkHQP88nlIPGQzW0EEZJp+lJQrQOis9qTq0cvTCzGIeZPsJkyuxtSBsnlqh/F7R92wMQmEkAUfQ
 4FkbxeTScV/A4E9F5tKUTHWKWp22ieR/VFu54yIkEXZ8qGQqd0VwS0Wj2yguYUgl1Vzc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYCg-0007Do-K7; Thu, 09 Apr 2020 14:30:50 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYCg-00049J-BT; Thu, 09 Apr 2020 14:30:50 +0000
Date: Thu, 9 Apr 2020 15:30:47 +0100
From: Wei Liu <wl@xen.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH 0/3] mini-os: fix several double frees and memory leaks
Message-ID: <20200409143047.o4ncbup7stcmjjh3@debian>
References: <20200409141240.28876-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200409141240.28876-1-jgross@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 wl@xen.org, samuel.thibault@ens-lyon.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 09, 2020 at 04:12:37PM +0200, Juergen Gross wrote:
> This series fixes two double free() introduced by suspend/resume
> patches and several memory leaks.
> 
> Juergen Gross (3):
>   mini-os: fix double free() in netfront
>   mini-os: fix double free() in xenbus
>   mini-os: fix several memory leaks related to xenbus

Acked-by: Wei Liu <wl@xen.org>

Thanks for fixing these bugs.


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:32:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:32:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYER-000505-Af; Thu, 09 Apr 2020 14:32:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VOqT=5Z=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMYEQ-000500-Ad
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:32:38 +0000
X-Inumbo-ID: f5d80958-7a6e-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f5d80958-7a6e-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 14:32:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=+wsKpVx4Upuyd7YJmc5eSbEDOgYg5uNqWxGLpeT+A7k=; b=sREoCa/1uLtetSfSa7NekqAbkW
 m0h1icn5G+lJbtY3hlxejp3R+nzCD5lU2+6tCmvVWWHN9xB6H7LtP3vUCsGZuZNMt2pLCP9Km1zJ0
 K1SZvRUD2y8EaafCQTw9L0q2uTYhYJChp23zg8ifOwePi+PzzmKwSrdWD/BzrVQI6Gig=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYEP-0007Gb-55; Thu, 09 Apr 2020 14:32:37 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYEO-0004Cb-SE; Thu, 09 Apr 2020 14:32:37 +0000
Date: Thu, 9 Apr 2020 15:32:33 +0100
From: Wei Liu <wl@xen.org>
To: "Panyakin, Andrew" <apanyaki@amazon.com>
Subject: Re: [XEN PATCH] libxc/migration: Abort migration on precopy policy
 request
Message-ID: <20200409143233.qarpf2vgynqqgrht@debian>
References: <eb85d7fee920b54eea3b4c0e77ab40593613ccc4.1586270820.git.apanyaki@amazon.com>
 <20200407202244.a6isag63njejbshe@debian>
 <9930fbd5-10f7-5f92-348b-8856ecad3768@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9930fbd5-10f7-5f92-348b-8856ecad3768@amazon.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org,
 David Woodhouse <dwmw@amazon.co.uk>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 12:06:22AM +0200, Panyakin, Andrew wrote:
> On 4/7/20 10:22 PM, Wei Liu wrote:
> > On Tue, Apr 07, 2020 at 02:52:22PM +0000, Andrew Panyakin wrote:
> >> libxc defines XGS_POLICY_ABORT for precopy policy to signal that migration
> >> should be aborted (eg. if the estimated pause time is too huge for the
> >> instance). Default simple precopy policy never returns that, but it could be
> >> overriden with a custom one.
> >>
> > 
> > Right. I think this is a real problem.
> > 
> >> Signed-off-by: Andrew Panyakin <apanyaki@amazon.com>
> >> ---
> >>  tools/libxc/xc_sr_save.c | 6 ++++++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
> >> index fa736a311f..507274ce22 100644
> >> --- a/tools/libxc/xc_sr_save.c
> >> +++ b/tools/libxc/xc_sr_save.c
> >> @@ -560,6 +560,12 @@ static int send_memory_live(struct xc_sr_context *ctx)
> >>
> >>      }
> >>
> >> +    if ( policy_decision == XGS_POLICY_ABORT ) {
> > 
> > The { should be on a new line.
> > 
> >> +        PERROR("Abort precopy loop");
> >> +        rc = -1;
> >> +        goto out;
> > 
> > There is no need to have "goto out" here.
> 
> I was considering two more examples of "goto out" in a branch right before the label:
> - send_domain_memory_nonlive,
> - send_domain_memory_live.
> 
> Isn't it done this way to simplify the function extension: you won't need to add "goto out" to previous branch when adding new code?

I'm not too fussed about this. Let's keep goto out.

Acked-by: Wei Liu <wl@xen.org>

I will apply this patch shortly.

Wei.


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:33:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:33:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYF0-00054o-P1; Thu, 09 Apr 2020 14:33:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9neF=5Z=ens-lyon.org=samuel.thibault@srs-us1.protection.inumbo.net>)
 id 1jMYEz-00054b-NA
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:33:13 +0000
X-Inumbo-ID: 06cd4584-7a6f-11ea-b58d-bc764e2007e4
Received: from hera.aquilenet.fr (unknown [2a0c:e300::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 06cd4584-7a6f-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 14:33:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id B0F682FEF;
 Thu,  9 Apr 2020 16:33:05 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id IMM8uDMPC8o7; Thu,  9 Apr 2020 16:33:04 +0200 (CEST)
Received: from function.home (unknown
 [IPv6:2a01:cb19:956:1b00:9eb6:d0ff:fe88:c3c7])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 473002FBC;
 Thu,  9 Apr 2020 16:33:04 +0200 (CEST)
Received: from samy by function.home with local (Exim 4.93)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1jMYEo-001zWn-L7; Thu, 09 Apr 2020 16:33:02 +0200
Date: Thu, 9 Apr 2020 16:33:02 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH 1/3] mini-os: fix double free() in netfront
Message-ID: <20200409143302.4kcbb3rf7rfxqkhq@function>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org, wl@xen.org
References: <20200409141240.28876-1-jgross@suse.com>
 <20200409141240.28876-2-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200409141240.28876-2-jgross@suse.com>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 wl@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Juergen Gross, le jeu. 09 avril 2020 16:12:38 +0200, a ecrit:
> Commit d225f4012d69a19 ("Save/Restore Support: Add suspend/restore
> support for netfront") introduced a regression in form of freeing a
> netfront device structure twice.
> 
> Fix that.
> 
> Coverity-ID: 1433637
> Fixes: d225f4012d69a19 ("Save/Restore Support: Add suspend/restore support for netfront")
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  netfront.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/netfront.c b/netfront.c
> index 50b3a57..fe7bb62 100644
> --- a/netfront.c
> +++ b/netfront.c
> @@ -584,8 +584,6 @@ void shutdown_netfront(struct netfront_dev *dev)
>      list->refcount--;
>      if (list->refcount == 0) {
>          _shutdown_netfront(dev);
> -        free(dev->nodename);
> -        free(dev);
>  
>          to_del = list;
>          if (to_del == dev_list) {
> -- 
> 2.16.4
> 


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:34:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:34:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYG5-0005Ct-4h; Thu, 09 Apr 2020 14:34:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9neF=5Z=ens-lyon.org=samuel.thibault@srs-us1.protection.inumbo.net>)
 id 1jMYG4-0005Ck-6w
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:34:20 +0000
X-Inumbo-ID: 2f11eb44-7a6f-11ea-82d8-12813bfff9fa
Received: from hera.aquilenet.fr (unknown [185.233.100.1])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2f11eb44-7a6f-11ea-82d8-12813bfff9fa;
 Thu, 09 Apr 2020 14:34:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 90E5A2FEF;
 Thu,  9 Apr 2020 16:34:13 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CPzKiQ9A8oKS; Thu,  9 Apr 2020 16:34:12 +0200 (CEST)
Received: from function.home (unknown
 [IPv6:2a01:cb19:956:1b00:9eb6:d0ff:fe88:c3c7])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 3875C2FBC;
 Thu,  9 Apr 2020 16:34:12 +0200 (CEST)
Received: from samy by function.home with local (Exim 4.93)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1jMYFv-001zXk-Bz; Thu, 09 Apr 2020 16:34:11 +0200
Date: Thu, 9 Apr 2020 16:34:11 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH 2/3] mini-os: fix double free() in xenbus
Message-ID: <20200409143411.xa6ar7do64y7mpzf@function>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org, wl@xen.org
References: <20200409141240.28876-1-jgross@suse.com>
 <20200409141240.28876-3-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200409141240.28876-3-jgross@suse.com>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 wl@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Juergen Gross, le jeu. 09 avril 2020 16:12:39 +0200, a ecrit:
> Commit 973ad0c4de1b48 ("Save/Restore Support: Add suspend/restore
> support for xenbus") introduced a double free of some memory and leaked
> another memory allocation.
> 
> Fix those.
> 
> Coverity-ID: 1433640
> Fixes: 973ad0c4de1b48 ("Save/Restore Support: Add suspend/restore support for xenbus")
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  xenbus/xenbus.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
> index d72dc3a..b12cef7 100644
> --- a/xenbus/xenbus.c
> +++ b/xenbus/xenbus.c
> @@ -413,9 +413,11 @@ void resume_xenbus(int canceled)
>  
>              rep = xenbus_msg_reply(XS_WATCH, XBT_NIL, req, ARRAY_SIZE(req));
>              msg = errmsg(rep);
> -            if (msg)
> +            if (msg) {
>                  xprintk("error on XS_WATCH: %s\n", msg);
> -            free(rep);
> +                free(msg);
> +            } else
> +                free(rep);
>          }
>      }
>  
> -- 
> 2.16.4
> 


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:35:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYHJ-0005K2-Fe; Thu, 09 Apr 2020 14:35:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9neF=5Z=ens-lyon.org=samuel.thibault@srs-us1.protection.inumbo.net>)
 id 1jMYHI-0005Jt-AW
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:35:36 +0000
X-Inumbo-ID: 5cc8ecc2-7a6f-11ea-82d9-12813bfff9fa
Received: from hera.aquilenet.fr (unknown [185.233.100.1])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5cc8ecc2-7a6f-11ea-82d9-12813bfff9fa;
 Thu, 09 Apr 2020 14:35:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 46C4A2FEF;
 Thu,  9 Apr 2020 16:35:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id gVfgDPR9TGcI; Thu,  9 Apr 2020 16:35:28 +0200 (CEST)
Received: from function.home (unknown
 [IPv6:2a01:cb19:956:1b00:9eb6:d0ff:fe88:c3c7])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id ED6A32FBC;
 Thu,  9 Apr 2020 16:35:27 +0200 (CEST)
Received: from samy by function.home with local (Exim 4.93)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1jMYH9-001zYH-6l; Thu, 09 Apr 2020 16:35:27 +0200
Date: Thu, 9 Apr 2020 16:35:27 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH 3/3] mini-os: fix several memory leaks related to xenbus
Message-ID: <20200409143527.co3uensu2czln3mf@function>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org, wl@xen.org
References: <20200409141240.28876-1-jgross@suse.com>
 <20200409141240.28876-4-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200409141240.28876-4-jgross@suse.com>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 wl@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Juergen Gross, le jeu. 09 avril 2020 16:12:40 +0200, a ecrit:
> There are several instances of calls to xenbus functions which don't
> test for an error and in consequence are not freeing the returned
> error strings, or which are just not freeing the string after e.g.
> printing it.
> 
> Fix that by either adding the needed calls of free().
> 
> Coverity-ID: 1433632
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  blkfront.c       |  4 ++--
>  console/xenbus.c |  2 +-
>  fbfront.c        |  4 ++--
>  netfront.c       |  2 +-
>  pcifront.c       | 28 +++++++++++++---------------
>  shutdown.c       |  2 +-
>  xenbus/xenbus.c  |  2 ++
>  7 files changed, 22 insertions(+), 22 deletions(-)
> 
> diff --git a/blkfront.c b/blkfront.c
> index f747216..834a978 100644
> --- a/blkfront.c
> +++ b/blkfront.c
> @@ -200,7 +200,7 @@ done:
>  
>          snprintf(path, sizeof(path), "%s/state", dev->backend);
>  
> -        xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
> +        free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
>  
>          msg = NULL;
>          state = xenbus_read_integer(path);
> @@ -208,7 +208,7 @@ done:
>              msg = xenbus_wait_for_state_change(path, &state, &dev->events);
>          if (msg != NULL || state != XenbusStateConnected) {
>              printk("backend not available, state=%d\n", state);
> -            xenbus_unwatch_path_token(XBT_NIL, path, path);
> +            free(xenbus_unwatch_path_token(XBT_NIL, path, path));
>              goto error;
>          }
>  
> diff --git a/console/xenbus.c b/console/xenbus.c
> index 654b469..05fc31c 100644
> --- a/console/xenbus.c
> +++ b/console/xenbus.c
> @@ -164,7 +164,7 @@ done:
>          char path[strlen(dev->backend) + strlen("/state") + 1];
>          snprintf(path, sizeof(path), "%s/state", dev->backend);
>          
> -	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
> +	free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
>          msg = NULL;
>          state = xenbus_read_integer(path);
>          while (msg == NULL && state < XenbusStateConnected)
> diff --git a/fbfront.c b/fbfront.c
> index 9cc07b4..d3b3848 100644
> --- a/fbfront.c
> +++ b/fbfront.c
> @@ -163,7 +163,7 @@ done:
>  
>          snprintf(path, sizeof(path), "%s/state", dev->backend);
>  
> -        xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
> +        free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
>  
>          err = NULL;
>          state = xenbus_read_integer(path);
> @@ -530,7 +530,7 @@ done:
>  
>          snprintf(path, sizeof(path), "%s/state", dev->backend);
>  
> -        xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
> +        free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
>  
>          err = NULL;
>          state = xenbus_read_integer(path);
> diff --git a/netfront.c b/netfront.c
> index fe7bb62..66f2bbc 100644
> --- a/netfront.c
> +++ b/netfront.c
> @@ -513,7 +513,7 @@ done:
>              err = xenbus_wait_for_state_change(path, &state, &dev->events);
>          if (state != XenbusStateConnected) {
>              printk("backend not avalable, state=%d\n", state);
> -            xenbus_unwatch_path_token(XBT_NIL, path, path);
> +            free(xenbus_unwatch_path_token(XBT_NIL, path, path));
>              goto error;
>          }
>  
> diff --git a/pcifront.c b/pcifront.c
> index 0fc5b30..5642356 100644
> --- a/pcifront.c
> +++ b/pcifront.c
> @@ -70,28 +70,28 @@ void pcifront_watches(void *opaque)
>  
>      while (1) {
>          printk("pcifront_watches: waiting for backend path to appear %s\n", path);
> -        xenbus_watch_path_token(XBT_NIL, path, path, &events);
> +        free(xenbus_watch_path_token(XBT_NIL, path, path, &events));
>          while ((err = xenbus_read(XBT_NIL, path, &be_path)) != NULL) {
>              free(err);
>              xenbus_wait_for_watch(&events);
>          }
> -        xenbus_unwatch_path_token(XBT_NIL, path, path);
> +        free(xenbus_unwatch_path_token(XBT_NIL, path, path));
>          printk("pcifront_watches: waiting for backend to get into the right state %s\n", be_path);
>          be_state = (char *) malloc(strlen(be_path) +  7);
>          snprintf(be_state, strlen(be_path) +  7, "%s/state", be_path);
> -        xenbus_watch_path_token(XBT_NIL, be_state, be_state, &events);
> +        free(xenbus_watch_path_token(XBT_NIL, be_state, be_state, &events));
>          while ((err = xenbus_read(XBT_NIL, be_state, &msg)) != NULL || msg[0] > '4') {
>              free(msg);
>              free(err);
>              xenbus_wait_for_watch(&events);
>          }
> -        xenbus_unwatch_path_token(XBT_NIL, be_state, be_state);
> +        free(xenbus_unwatch_path_token(XBT_NIL, be_state, be_state));
>          if (init_pcifront(NULL) == NULL) {
>              free(be_state);
>              free(be_path);
>              continue;
>          }
> -        xenbus_watch_path_token(XBT_NIL, be_state, be_state, &events);
> +        free(xenbus_watch_path_token(XBT_NIL, be_state, be_state, &events));
>          state = XenbusStateConnected;
>          printk("pcifront_watches: waiting for backend events %s\n", be_state);
>          while ((err = xenbus_wait_for_state_change(be_state, &state, &events)) == NULL &&
> @@ -103,10 +103,9 @@ void pcifront_watches(void *opaque)
>                  if ((err = xenbus_switch_state(XBT_NIL, fe_state, XenbusStateReconfiguring)) != NULL) {
>                      printk("pcifront_watches: error changing state to %d: %s\n",
>                              XenbusStateReconfiguring, err);
> -                    if (!strcmp(err, "ENOENT")) {
> -                        xenbus_write(XBT_NIL, fe_state, "7");
> -                        free(err);
> -                    }
> +                    if (!strcmp(err, "ENOENT"))
> +                        free(xenbus_write(XBT_NIL, fe_state, "7"));
> +                    free(err);
>                  }
>              } else if (state == XenbusStateReconfigured) {
>                  printk("pcifront_watches: writing %s %d\n", fe_state, XenbusStateConnected);
> @@ -114,10 +113,9 @@ void pcifront_watches(void *opaque)
>                  if ((err = xenbus_switch_state(XBT_NIL, fe_state, XenbusStateConnected)) != NULL) {
>                      printk("pcifront_watches: error changing state to %d: %s\n",
>                              XenbusStateConnected, err);
> -                    if (!strcmp(err, "ENOENT")) {
> -                        xenbus_write(XBT_NIL, fe_state, "4");
> -                        free(err);
> -                    }
> +                    if (!strcmp(err, "ENOENT"))
> +                        free(xenbus_write(XBT_NIL, fe_state, "4"));
> +                    free(err);
>                  }
>              } else if (state == XenbusStateClosing)
>                  break;
> @@ -135,7 +133,7 @@ void pcifront_watches(void *opaque)
>          pcidev = NULL;
>      }
>  
> -    xenbus_unwatch_path_token(XBT_NIL, path, path);
> +    free(xenbus_unwatch_path_token(XBT_NIL, path, path));
>  }
>  
>  struct pcifront_dev *init_pcifront(char *_nodename)
> @@ -243,7 +241,7 @@ done:
>          XenbusState state;
>          snprintf(path, sizeof(path), "%s/state", dev->backend);
>  
> -        xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
> +        free(xenbus_watch_path_token(XBT_NIL, path, path, &dev->events));
>  
>          err = NULL;
>          state = xenbus_read_integer(path);
> diff --git a/shutdown.c b/shutdown.c
> index c7c92cb..4c0b13c 100644
> --- a/shutdown.c
> +++ b/shutdown.c
> @@ -71,7 +71,7 @@ static void shutdown_thread(void *p)
>      char *shutdown, *err;
>      unsigned int shutdown_reason;
>  
> -    xenbus_watch_path_token(XBT_NIL, path, token, &events);
> +    free(xenbus_watch_path_token(XBT_NIL, path, token, &events));
>  
>      for ( ;; ) {
>          xenbus_wait_for_watch(&events);
> diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
> index b12cef7..9e61930 100644
> --- a/xenbus/xenbus.c
> +++ b/xenbus/xenbus.c
> @@ -198,6 +198,8 @@ exit:
>          }
>          if (msg == NULL && msg2 != NULL)
>              msg = msg2;
> +        else
> +            free(msg2);
>      } while (retry);
>  
>      return msg;
> -- 
> 2.16.4
> 


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:41:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYMn-0006Bz-C8; Thu, 09 Apr 2020 14:41:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=4Z0E=5Z=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jMYMl-0006Bu-UR
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:41:15 +0000
X-Inumbo-ID: 29b711c8-7a70-11ea-83d8-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 29b711c8-7a70-11ea-83d8-bc764e2007e4;
 Thu, 09 Apr 2020 14:41:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586443275;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=U9nhpmPZ6JuRsqnojv644Dh58/++8b9NG2ayup812Cg=;
 b=ArSJobM7rd7jcny7SKly3yJTkKfY8LzdKQy5KeWEQtCRwVJrOn7Z/onv
 3afAe6wJ7FmHDEXo4oLaNTuxsbEXQYKM3ZSjyU6WdGFWPiAN9gLCve8QS
 9VxYKTr81wJk8YbPJl4u9sxq9WKdOVBShL9ljZCbtpvZav/T3RB/7CnLd 0=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 7C5UzvExn1WPg9tyiDIg9gio6aXGgph42YHQ1TL3eB/Jc7XRRR3Ax+BwuUu5zu6dP8eu0/hnKg
 8Xe6DLz8mzmoqoN6PhM/oO5lYq2521h4tlYiVdscWZxJA4cxhe7teUStV4WYFU6xjaimV219Se
 M85fFEPMcT519YOIR0k5OQ0yvDANJRNd6I+OWpoQ9x/EVJsdDNsGP/kB99IGsC5Kpx67riq/+l
 2/lRRxs/iJaQQyqvh8+gFPIYMkwyomkArHFESG/VCDMeb+lMFi45R8oqtiGz94wuHSnQqf5lPz
 8OQ=
X-SBRS: 2.7
X-MesageID: 15455393
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,363,1580792400"; d="scan'208";a="15455393"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24207.13317.34414.413073@mariner.uk.xensource.com>
Date: Thu, 9 Apr 2020 15:41:09 +0100
To: Wei Liu <wl@xen.org>, "Panyakin, Andrew" <apanyaki@amazon.com>
Subject: Re: [XEN PATCH] libxc/migration: Abort migration on precopy policy
 request [and 1 more messages]
In-Reply-To: <9930fbd5-10f7-5f92-348b-8856ecad3768@amazon.com>,
 <20200409143233.qarpf2vgynqqgrht@debian>
References: <eb85d7fee920b54eea3b4c0e77ab40593613ccc4.1586270820.git.apanyaki@amazon.com>
 <20200407202244.a6isag63njejbshe@debian>
 <9930fbd5-10f7-5f92-348b-8856ecad3768@amazon.com>
 <20200409143233.qarpf2vgynqqgrht@debian>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>, David
 Woodhouse <dwmw@amazon.co.uk>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Panyakin, Andrew writes ("Re: [XEN PATCH] libxc/migration: Abort migration on precopy policy request"):
> On 4/7/20 10:22 PM, Wei Liu wrote:
> > There is no need to have "goto out" here.
> 
> I was considering two more examples of "goto out" in a branch right before the label:
> - send_domain_memory_nonlive,
> - send_domain_memory_live.
> 
> Isn't it done this way to simplify the function extension: you won't need to add "goto out" to previous branch when adding new code?

Quite so.

Wei Liu writes ("Re: [XEN PATCH] libxc/migration: Abort migration on precopy policy request"):
> I'm not too fussed about this. Let's keep goto out.

Good :-).

> Acked-by: Wei Liu <wl@xen.org>
> 
> I will apply this patch shortly.

Thanks,
Ian.


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:44:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:44:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYQH-0006Or-3B; Thu, 09 Apr 2020 14:44:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=VuOD=5Z=oracle.com=boris.ostrovsky@srs-us1.protection.inumbo.net>)
 id 1jMYQF-0006Om-RX
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:44:51 +0000
X-Inumbo-ID: aad417f6-7a70-11ea-b58d-bc764e2007e4
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id aad417f6-7a70-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 14:44:51 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 039EeKK4060061;
 Thu, 9 Apr 2020 14:44:37 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=subject : to : cc :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type : content-transfer-encoding; s=corp-2020-01-29;
 bh=VTF5rzoS67jGgvr3WONUoqlugTDPyKjLN90Y48dLo9s=;
 b=G+wqJ3CeYZSIigcMpcz9XR+n7ibh2+/ALDXGHW6uitOFrluEyAuIrSdqwDTZd0iab1e+
 VMziR4aslIqHV54auFKqqc6dISQKiu/7Cwnjeu0CZQvngF61lVt6dQDvEAKkmo+SzvOH
 nh1SuZei2t0/yWyy5rd2Gbd+mYc0nLJT2c5eNDo9Cnz5tNK2QglWPfJdeHUvSxrANyA1
 6zynWBznVHkxWQ9u1ejSU/RyiNHF8GJdhfgY4NPWe1Zr6QqAJUBaveVaFW9IkWNDZ9w7
 P0+dvwDO9Tx0hXm58ODihI/vTinf+4npyUkvEqjFJ64w2E1VNVeoYHjqvQkSTYzByTSS hQ== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by userp2130.oracle.com with ESMTP id 3091m3hx1k-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 09 Apr 2020 14:44:37 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 039Eat7Q023906;
 Thu, 9 Apr 2020 14:44:36 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
 by aserp3030.oracle.com with ESMTP id 309ag4se2c-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 09 Apr 2020 14:44:36 +0000
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
 by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 039EiU7P004126;
 Thu, 9 Apr 2020 14:44:30 GMT
Received: from [10.39.247.246] (/10.39.247.246)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Thu, 09 Apr 2020 07:44:30 -0700
Subject: Re: [PATCH] x86/xen: fix booting 32-bit pv guest
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
 x86@kernel.org, linux-kernel@vger.kernel.org
References: <20200409070001.16675-1-jgross@suse.com>
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Autocrypt: addr=boris.ostrovsky@oracle.com; keydata=
 xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV
 PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M
 MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5
 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM
 d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom
 woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2
 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2
 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS
 Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP
 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry
 b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8
 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g
 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z
 JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS
 VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK
 jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE
 qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9
 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/
 kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T
 m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB
 nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o
 hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB
 Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q
 yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz
 kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4
 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i
 BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC
 gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw
 XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ
 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK
 kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4
 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G
 jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh
 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ
 PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj
 u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu
 qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd
 t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4
 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh
 Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ
 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM
 Jg6OxFYd01z+a+oL
Message-ID: <ee2aa0c4-b633-a5e6-436c-0776407c98ac@oracle.com>
Date: Thu, 9 Apr 2020 10:44:25 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200409070001.16675-1-jgross@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 spamscore=0 malwarescore=0
 phishscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004090115
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0
 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999
 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004090115
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Thomas Gleixner <tglx@linutronix.de>,
 Stefano Stabellini <sstabellini@kernel.org>, Borislav Petkov <bp@alien8.de>,
 Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


On 4/9/20 3:00 AM, Juergen Gross wrote:
> Commit 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
> introduced a regression for booting 32 bit Xen PV guests: the address
> of the initial stack needs to be a virtual one.
>
> Fixes: 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
> Signed-off-by: Juergen Gross <jgross@suse.com>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


> ---
>  arch/x86/xen/xen-head.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7d1c4fcbe8f7..1ba601df3a37 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -38,7 +38,7 @@ SYM_CODE_START(startup_xen)
>  #ifdef CONFIG_X86_64


While at it, I'd swap the ifdefs and fold x86_64 case into the one below.


>  	mov initial_stack(%rip), %rsp
>  #else
> -	mov pa(initial_stack), %esp
> +	mov initial_stack, %esp
>  #endif
>  
>  #ifdef CONFIG_X86_64





From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:46:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYRl-0006Uk-G2; Thu, 09 Apr 2020 14:46:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VOqT=5Z=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMYRj-0006Ue-NK
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:46:23 +0000
X-Inumbo-ID: e1a96a06-7a70-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e1a96a06-7a70-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 14:46:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=MueWrmTDF935mg6/uFP0Trw3f8XXT6pdzcfV97Yoy9U=; b=PmOVjou0fwPoR7TYZMdsUxyZJc
 wkN58zTBTdOZfFbcf+RqyaLEcqFET3oWjbMOgqkQncQJpIssc3TyXBGWOPoDikm6VIIijtuq7dlRm
 Sc3UMrPgJqLNokRbLe547/swDrTGmdeC7MQuH9RWjRvcN2+MHucmxAhovmEvh6g5r4QE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYRg-0007Y6-P5; Thu, 09 Apr 2020 14:46:20 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYRg-0005d5-FM; Thu, 09 Apr 2020 14:46:20 +0000
Date: Thu, 9 Apr 2020 15:46:17 +0100
From: Wei Liu <wl@xen.org>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org, wl@xen.org
Subject: Re: [PATCH 3/3] mini-os: fix several memory leaks related to xenbus
Message-ID: <20200409144617.6hjxykngc7d2zbxu@debian>
References: <20200409141240.28876-1-jgross@suse.com>
 <20200409141240.28876-4-jgross@suse.com>
 <20200409143527.co3uensu2czln3mf@function>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200409143527.co3uensu2czln3mf@function>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 09, 2020 at 04:35:27PM +0200, Samuel Thibault wrote:
> Juergen Gross, le jeu. 09 avril 2020 16:12:40 +0200, a ecrit:
> > There are several instances of calls to xenbus functions which don't
> > test for an error and in consequence are not freeing the returned
> > error strings, or which are just not freeing the string after e.g.
> > printing it.
> > 
> > Fix that by either adding the needed calls of free().
> > 
> > Coverity-ID: 1433632
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Thanks for your review, Samuel.

I have pushed these patches with your Rbs.

Wei.


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 14:53:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 14:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYY6-0007M4-9l; Thu, 09 Apr 2020 14:52:58 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lf15=5Z=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMYY5-0007Lz-OE
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 14:52:57 +0000
X-Inumbo-ID: cc42c990-7a71-11ea-82df-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cc42c990-7a71-11ea-82df-12813bfff9fa;
 Thu, 09 Apr 2020 14:52:57 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 02BAEAD10;
 Thu,  9 Apr 2020 14:52:54 +0000 (UTC)
Subject: Re: [PATCH] x86/xen: fix booting 32-bit pv guest
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel@lists.xenproject.org, x86@kernel.org, linux-kernel@vger.kernel.org
References: <20200409070001.16675-1-jgross@suse.com>
 <ee2aa0c4-b633-a5e6-436c-0776407c98ac@oracle.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <cce1a59b-983f-85aa-95a4-f7b5bc82c39e@suse.com>
Date: Thu, 9 Apr 2020 16:52:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <ee2aa0c4-b633-a5e6-436c-0776407c98ac@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Thomas Gleixner <tglx@linutronix.de>,
 Stefano Stabellini <sstabellini@kernel.org>, Borislav Petkov <bp@alien8.de>,
 Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.20 16:44, Boris Ostrovsky wrote:
> 
> On 4/9/20 3:00 AM, Juergen Gross wrote:
>> Commit 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
>> introduced a regression for booting 32 bit Xen PV guests: the address
>> of the initial stack needs to be a virtual one.
>>
>> Fixes: 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> 
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> 
>> ---
>>   arch/x86/xen/xen-head.S | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
>> index 7d1c4fcbe8f7..1ba601df3a37 100644
>> --- a/arch/x86/xen/xen-head.S
>> +++ b/arch/x86/xen/xen-head.S
>> @@ -38,7 +38,7 @@ SYM_CODE_START(startup_xen)
>>   #ifdef CONFIG_X86_64
> 
> 
> While at it, I'd swap the ifdefs and fold x86_64 case into the one below.

I wanted to remove 32-bit PV support from the kernel soon, so I think
this can wait until then. :-)


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 15:01:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 15:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMYg0-0008F8-5P; Thu, 09 Apr 2020 15:01:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VOqT=5Z=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMYfz-0008F3-3D
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 15:01:07 +0000
X-Inumbo-ID: efc1e85a-7a72-11ea-82e5-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id efc1e85a-7a72-11ea-82e5-12813bfff9fa;
 Thu, 09 Apr 2020 15:01:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=kL/5SKsbj68QSQOVj/aONby2Tnq7faYx2YAo5fYxhag=; b=XZF3tADBEDCd4V5U6HbLiBVriZ
 n8d+N8/ecufOkD1kjtGVD3cBUT8/fRJXNht4BfFp3jhOKwl0IVl1z1kljIcWOdN6XC1giodJyi7xr
 pmkRvcpJDuYBsCUC6lnw6t63WB4fUlr+BAeBqYXakcbQw6yNZ6Rxs+BcpatpoNr1Cj+M=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYfw-0007rg-4t; Thu, 09 Apr 2020 15:01:04 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMYfv-0006ct-RZ; Thu, 09 Apr 2020 15:01:04 +0000
Date: Thu, 9 Apr 2020 16:01:01 +0100
From: Wei Liu <wl@xen.org>
To: Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH] tools/xl: Remove the filelock when building VM if
 autoballooning is off
Message-ID: <20200409150101.f76ebwucffuagcr7@debian>
References: <20190311103622.20143-1-isaikin-dmitry@yandex.ru>
 <24204.42515.354583.921270@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24204.42515.354583.921270@mariner.uk.xensource.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Dmitry Isaykin <isaikin-dmitry@yandex.ru>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 07, 2020 at 05:10:59PM +0100, Ian Jackson wrote:
> Dmitry Isaykin writes ("[PATCH] tools/xl: Remove the filelock when building VM if autoballooning is off"):
> > The presence of this filelock does not allow building several VMs at the same
> > time. This filelock was added to prevent other xl instances from using memory
> > freeed for the currently building VM in autoballoon mode.
> > 
> > Signed-off-by: Dmitry Isaykin <isaikin-dmitry@yandex.ru>
> 
> Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> This was deferred due to the Xen 4.13 freeze.  I found it in a todo
> list of mine.  I think it should be committed and I will do so soon
> unless someone objects.
> 
> Sorry for the delay, Dmitry!
> 

I applied a reconstructed version of this patch -- the version I got
from lore.k.o doesn't apply cleanly.

Wei.


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 15:26:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 15:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMZ4G-0001YY-8a; Thu, 09 Apr 2020 15:26:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VOqT=5Z=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMZ4E-0001YT-Ut
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 15:26:10 +0000
X-Inumbo-ID: 703fc1fc-7a76-11ea-82ef-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 703fc1fc-7a76-11ea-82ef-12813bfff9fa;
 Thu, 09 Apr 2020 15:26:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=n/dJPlKyygqQLWVhnrVABh+dMENl/NBSwN+Vm2uJUV4=; b=DKyiUdXN+dg104FIVw9r4NIZ4O
 mBszrNWYhKP44bQNc5LMEWhJAkoWlikYXoAiA2fHvdBrd3SaLrG7D0saxJn4XdSU37TeaZOxUQ/yq
 Ah2ZorLS0KU2tMgl9+P+fBHx1azBiH1QsbSckJnXuKPj3kmATAri1lLUl5/SBcKLDtPU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMZ4C-0008KS-5k; Thu, 09 Apr 2020 15:26:08 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMZ4B-0008SI-Re; Thu, 09 Apr 2020 15:26:08 +0000
Date: Thu, 9 Apr 2020 16:26:05 +0100
From: Wei Liu <wl@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86/EFI: also fill boot_tsc_stamp on the xen.efi boot path
Message-ID: <20200409152605.t4dka3yt6xndoib4@debian>
References: <7ed6f7cc-c540-88fb-6073-10ef1a2da6e7@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7ed6f7cc-c540-88fb-6073-10ef1a2da6e7@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 10:00:48AM +0200, Jan Beulich wrote:
> Commit e3a379c35eff ("x86/time: always count s_time from Xen boot")
> introducing this missed adjusting this path as well.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 15:42:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 15:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMZKN-0003A7-AB; Thu, 09 Apr 2020 15:42:51 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VOqT=5Z=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMZKL-0003A2-Kn
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 15:42:49 +0000
X-Inumbo-ID: c3697290-7a78-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c3697290-7a78-11ea-83d8-bc764e2007e4;
 Thu, 09 Apr 2020 15:42:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=Io9Mqkd/hAbqiWh1sT0gO8kc42yU9ideP2Ttfj3rUbY=; b=lzuEGzps/ZZHg7Ds+/Pesk0/7G
 20lY9Wf8fyIff3/PEHPZWZmhLyTU4WL9iynY2Q9lkBkHEEDWlo5OvgmIol3hMtbgoRFKV8hVmGV0U
 svKo5aM/MeCgNdz3cs3/e5DI1gUb89zHttYO/EVwx6Fpq+MrtgEVSxaQ9wRgq4YEiSZg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMZKI-0000DP-IP; Thu, 09 Apr 2020 15:42:46 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMZKI-00018f-8s; Thu, 09 Apr 2020 15:42:46 +0000
Date: Thu, 9 Apr 2020 16:42:43 +0100
From: Wei Liu <wl@xen.org>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
Message-ID: <20200409154243.6ouh7r37fwm32mjg@debian>
References: <cover.1586186121.git.tamas.lengyel@intel.com>
 <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> Add necessary bits to implement "xl fork-vm" commands. The command allows the
> user to specify how to launch the device model allowing for a late-launch model
> in which the user can execute the fork without the device model and decide to
> only later launch it.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> ---
[...]
>  
> +int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
> +                       libxl__domain_build_state *state,
> +                       uint32_t *domid, bool soft_reset)

It would have been nice if you could split the refactoring out to a
separate patch.

>  static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
>                               libxl_domain_build_info *b_info)
>  {
> @@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
>      ret = libxl__domain_config_setdefault(gc,d_config,domid);
>      if (ret) goto error_out;
>  
> -    ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> -                             dcs->soft_reset);
> -    if (ret) {
> -        LOGD(ERROR, domid, "cannot make domain: %d", ret);
> +    if ( !d_config->dm_restore_file )
> +    {
> +        ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> +                                 dcs->soft_reset);
>          dcs->guest_domid = domid;
> +
> +        if (ret) {
> +            LOGD(ERROR, domid, "cannot make domain: %d", ret);
> +            ret = ERROR_FAIL;
> +            goto error_out;
> +        }
> +    } else if ( dcs->guest_domid != INVALID_DOMID ) {

Coding style issue here.

There are quite a few of them.  I won't point them out one by one
though. Let's focus on the interface first.

>  
> +/*
> + * The parent domain is expected to be created with default settings for
> + * - max_evtch_port
> + * - max_grant_frames
> + * - max_maptrack_frames
> + */
> +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> +{
> +    int rc;
> +    struct xen_domctl_createdomain create = {0};
> +    create.flags |= XEN_DOMCTL_CDF_hvm;
> +    create.flags |= XEN_DOMCTL_CDF_hap;
> +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> +    create.ssidref = SECINITSID_DOMU;
> +    create.max_vcpus = max_vcpus;


Some questions:

Why does the caller need to specify the number of vcpus?

Since the parent (source) domain is around, can you retrieve its domain
configuration such that you know its max_vcpus and other information
including max_evtchn_port and maptrack frames?

Wei.


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 15:52:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 15:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMZTT-00043B-Ap; Thu, 09 Apr 2020 15:52:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=tj/S=5Z=gmail.com=tamas.k.lengyel@srs-us1.protection.inumbo.net>)
 id 1jMZTR-000436-JD
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 15:52:13 +0000
X-Inumbo-ID: 13b64722-7a7a-11ea-83d8-bc764e2007e4
Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 13b64722-7a7a-11ea-83d8-bc764e2007e4;
 Thu, 09 Apr 2020 15:52:12 +0000 (UTC)
Received: by mail-wr1-x442.google.com with SMTP id c15so12432097wro.11
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 08:52:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=QMi/kgXe+kpH7J8/wvBqGD8s0I8/bpxLewJ9YdGEXSw=;
 b=Dgc4iuvXF5iqeWJOx2Mn0elICKzTD/R7SL4OiqNd9/vt94gFF6HmLb0qbIG/YUfUV/
 aDKMPKp78X6Tsw3/+z890PrDBEqYgUCE5EuNcDIV/MG8GmhMmsM+1GEyg/XrHMqXyioi
 C2uPg8QIl3fYKmF+CTW+nw3NTiNATsESmcutfkVBFaLkKXALi4dl8YKMI+Zv/TTO8Ltj
 UAMz7wZybg7X8acWzZjOMQwQ/80Q8IxD+/3XVTzi0AJ7Y0cJuapUjhUczzAqcBjpndGI
 TE4RFNJI77c45e96tjzNkNz8BWwyxL+Ya1QyjkptcrFGqJ51Ta6nT2nAVFU5qKMxNYqe
 98Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=QMi/kgXe+kpH7J8/wvBqGD8s0I8/bpxLewJ9YdGEXSw=;
 b=jvv+yrMNpINqUBIHObdEPmvzHNO/vP3eMuTlDypFeKP7z17v+uTRGF2W5yszDMaxhU
 U+WZ+2Hxql74AXVXZs8oLNpK08YAgXGYc9wS732WWL3soIbybTCdYMkxhOk8T/fMO8h3
 n1uWHyqzRDFd1xP8FanAtbyLCwZ12H3i8LqqKXAh/c0MujIrhLviyMB6eSthPXyiTBp1
 fmh9Xq3OgLJ3TNOCViicuVDV8PKPKbOFdbKAZVR+Y2g7NYMye9di0WL4OQLid4K2dg7p
 7czMLBsHGjvoklWC82MnQBdhKT2eKKvBrpq4UKQPJ6GxJg9Fo1UaxnCJ/eT+o865e7/1
 t+6w==
X-Gm-Message-State: AGi0Pua/X9D1dlaQddYuhUyC7By/3mbgTS8ldhBPL7ivAjOr0Lrrc61F
 gxkRXGmxPB1FP7vFDjqBAOOeU+0S8ano3LSEmxY=
X-Google-Smtp-Source: APiQypLSJTcB/83afBzptjsEIeRNSVdaCp6IIx1l6CT3r/gPgrK0sYYsZvfUjhCyguCOMkQqUdzfFIMbVYPzmPnloKY=
X-Received: by 2002:adf:e811:: with SMTP id o17mr6573940wrm.390.1586447531921; 
 Thu, 09 Apr 2020 08:52:11 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1586186121.git.tamas.lengyel@intel.com>
 <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
 <20200409154243.6ouh7r37fwm32mjg@debian>
In-Reply-To: <20200409154243.6ouh7r37fwm32mjg@debian>
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Date: Thu, 9 Apr 2020 09:51:35 -0600
Message-ID: <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
To: Wei Liu <wl@xen.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 9, 2020 at 9:43 AM Wei Liu <wl@xen.org> wrote:
>
> On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> > Add necessary bits to implement "xl fork-vm" commands. The command allows the
> > user to specify how to launch the device model allowing for a late-launch model
> > in which the user can execute the fork without the device model and decide to
> > only later launch it.
> >
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> > ---
> [...]
> >
> > +int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
> > +                       libxl__domain_build_state *state,
> > +                       uint32_t *domid, bool soft_reset)
>
> It would have been nice if you could split the refactoring out to a
> separate patch.

I found the toolstack to be way harder to work with then the
hypervisor code-base. Splitting the patches would have been nice but I
don't even know how to begin that since it's all such a spaghetti.

>
> >  static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
> >                               libxl_domain_build_info *b_info)
> >  {
> > @@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
> >      ret = libxl__domain_config_setdefault(gc,d_config,domid);
> >      if (ret) goto error_out;
> >
> > -    ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > -                             dcs->soft_reset);
> > -    if (ret) {
> > -        LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > +    if ( !d_config->dm_restore_file )
> > +    {
> > +        ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > +                                 dcs->soft_reset);
> >          dcs->guest_domid = domid;
> > +
> > +        if (ret) {
> > +            LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > +            ret = ERROR_FAIL;
> > +            goto error_out;
> > +        }
> > +    } else if ( dcs->guest_domid != INVALID_DOMID ) {
>
> Coding style issue here.
>
> There are quite a few of them.  I won't point them out one by one
> though. Let's focus on the interface first.

Do we have an automatic formatter we could just run on this code-base?
I don't know what style issue you are referring to and given that the
coding style here is different here compared to the hypervisor I find
it very hard to figure it out what other issues you spotted. Please
report them because I won't be able to spot them manually. To me it
all looks fine as-is.

> >
> > +/*
> > + * The parent domain is expected to be created with default settings for
> > + * - max_evtch_port
> > + * - max_grant_frames
> > + * - max_maptrack_frames
> > + */
> > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> > +{
> > +    int rc;
> > +    struct xen_domctl_createdomain create = {0};
> > +    create.flags |= XEN_DOMCTL_CDF_hvm;
> > +    create.flags |= XEN_DOMCTL_CDF_hap;
> > +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> > +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > +    create.ssidref = SECINITSID_DOMU;
> > +    create.max_vcpus = max_vcpus;
>
>
> Some questions:
>
> Why does the caller need to specify the number of vcpus?
>
> Since the parent (source) domain is around, can you retrieve its domain
> configuration such that you know its max_vcpus and other information
> including max_evtchn_port and maptrack frames?

Because we want to avoid having to issue an extra hypercall for these.
Normally these pieces of information will be available for the user
and won't change, so we save time by not querying for it every time a
fork is created. Remember, we might be creating thousands of forks in
a very short time, so those extra hypercalls add up.

Tamas


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 16:22:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 16:22:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMZwO-000723-Vi; Thu, 09 Apr 2020 16:22:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VOqT=5Z=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMZwN-00071y-VV
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 16:22:08 +0000
X-Inumbo-ID: 41574146-7a7e-11ea-82fc-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 41574146-7a7e-11ea-82fc-12813bfff9fa;
 Thu, 09 Apr 2020 16:22:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=AwqjL1FahRghq/bC8cpaviKJV0RDfIDk/SyOyf4MbwM=; b=yapafI3v6kUtG8LW1RY/jG+K+s
 SE2VXB9JPQmRcObwcbLy7bjPmgfSBuOMPn4yLWf6vw24hRgBpy5dnS3dC132er0uStXElfoXnYT2Y
 kaUeuAF2b3dvSMaD8o6ymE3fqpjTsKSuKiXdLlkDL64aeHeJxXik6etpNkyZgQKP6/5M=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMZwI-0001W8-B6; Thu, 09 Apr 2020 16:22:02 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMZwI-0003k7-1W; Thu, 09 Apr 2020 16:22:02 +0000
Date: Thu, 9 Apr 2020 17:21:59 +0100
From: Wei Liu <wl@xen.org>
To: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
Message-ID: <20200409162159.cb2h7a6tmkbaduay@debian>
References: <cover.1586186121.git.tamas.lengyel@intel.com>
 <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
 <20200409154243.6ouh7r37fwm32mjg@debian>
 <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 09, 2020 at 09:51:35AM -0600, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 9:43 AM Wei Liu <wl@xen.org> wrote:
> >
> > On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> > > Add necessary bits to implement "xl fork-vm" commands. The command allows the
> > > user to specify how to launch the device model allowing for a late-launch model
> > > in which the user can execute the fork without the device model and decide to
> > > only later launch it.
> > >
> > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> > > ---
> > [...]
> > >
> > > +int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
> > > +                       libxl__domain_build_state *state,
> > > +                       uint32_t *domid, bool soft_reset)
> >
> > It would have been nice if you could split the refactoring out to a
> > separate patch.
> 
> I found the toolstack to be way harder to work with then the
> hypervisor code-base. Splitting the patches would have been nice but I
> don't even know how to begin that since it's all such a spaghetti.

In this case you've split out some code from a function to make a new
function. That is a self-contained task, which can be in its own patch.

> 
> >
> > >  static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
> > >                               libxl_domain_build_info *b_info)
> > >  {
> > > @@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
> > >      ret = libxl__domain_config_setdefault(gc,d_config,domid);
> > >      if (ret) goto error_out;
> > >
> > > -    ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > > -                             dcs->soft_reset);
> > > -    if (ret) {
> > > -        LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > > +    if ( !d_config->dm_restore_file )
> > > +    {
> > > +        ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > > +                                 dcs->soft_reset);
> > >          dcs->guest_domid = domid;
> > > +
> > > +        if (ret) {
> > > +            LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > > +            ret = ERROR_FAIL;
> > > +            goto error_out;
> > > +        }
> > > +    } else if ( dcs->guest_domid != INVALID_DOMID ) {
> >
> > Coding style issue here.
> >
> > There are quite a few of them.  I won't point them out one by one
> > though. Let's focus on the interface first.
> 
> Do we have an automatic formatter we could just run on this code-base?
> I don't know what style issue you are referring to and given that the
> coding style here is different here compared to the hypervisor I find
> it very hard to figure it out what other issues you spotted. Please
> report them because I won't be able to spot them manually. To me it
> all looks fine as-is.

I feel your pain. There was work in progress to provide a style checker,
but we're not there yet.

Xen and libxc share one coding style while libxl and xl share another.
There is a CODING_STYLE file under libxl directory.  The problem here is
you should not have spaces inside ().

Generally I think pointing out coding style issues tend to distract
people from discussing more important things, so I would leave them last
to fix.

> 
> > >
> > > +/*
> > > + * The parent domain is expected to be created with default settings for
> > > + * - max_evtch_port
> > > + * - max_grant_frames
> > > + * - max_maptrack_frames
> > > + */
> > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> > > +{
> > > +    int rc;
> > > +    struct xen_domctl_createdomain create = {0};
> > > +    create.flags |= XEN_DOMCTL_CDF_hvm;
> > > +    create.flags |= XEN_DOMCTL_CDF_hap;
> > > +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > +    create.ssidref = SECINITSID_DOMU;
> > > +    create.max_vcpus = max_vcpus;
> >
> >
> > Some questions:
> >
> > Why does the caller need to specify the number of vcpus?
> >
> > Since the parent (source) domain is around, can you retrieve its domain
> > configuration such that you know its max_vcpus and other information
> > including max_evtchn_port and maptrack frames?
> 
> Because we want to avoid having to issue an extra hypercall for these.
> Normally these pieces of information will be available for the user
> and won't change, so we save time by not querying for it every time a
> fork is created. Remember, we might be creating thousands of forks in
> a very short time, so those extra hypercalls add up.

I see. Speed is a big concern to you.

What I was referring to doesn't require issuing hypercalls but requires
calling libxl_retrieve_domain_configuration. That's likely to be even
slower than making a hypercall.

I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
supported (as in Xen's support statement) going forward, because it is
leaky.

I can see two solutions: 1. batch forking to reduce the number of
queries needed; 2. make a proper domctl which duplicates the source
domain structure inside Xen.

Both of these require extra work. I think option 2 is better. But this
is not asking you to do the work now. See below.

While we want to make libxl APIs stable, we've had cases like COLO which
we explicitly declared unstable.  Seeing this is a niche feature, this
probably falls into the same category. In that case we reserve the right
to rework the interface when necessary.

Ian and Anthony, your opinions?

Wei.


> 
> Tamas


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 16:57:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 16:57:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMaUY-0001PQ-Vi; Thu, 09 Apr 2020 16:57:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Jqn0=5Z=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMaUX-0001PD-HY
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 16:57:25 +0000
X-Inumbo-ID: 2c13590a-7a83-11ea-8301-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2c13590a-7a83-11ea-8301-12813bfff9fa;
 Thu, 09 Apr 2020 16:57:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=RVjd7HllrmdukUL00UylhqwdPCaRb5DK1aES3FbQhKA=; b=LXDcqc9trs/aNs+fgdGjD+K1b
 HCvsdhJ1PCY68GZ1uKgBq6Gke0sWWtco3BfjpopEPYWJ88R282gYdgmwMT+7IH3imngQfC1Q0p79p
 AooCRnIjvm/3EmBskAy+vT+D+NNNlgmjhBw1qn011SCXuzsTRay19GzGnsXJyR2Y+9R9I=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMaUQ-0002Bm-HE; Thu, 09 Apr 2020 16:57:18 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMaUQ-0006gv-69; Thu, 09 Apr 2020 16:57:18 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMaUQ-00049d-5T; Thu, 09 Apr 2020 16:57:18 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149553-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.13-testing test] 149553: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.13-testing:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=181614a71070ee1dfb8d1fb954ca6127c24691a3
X-Osstest-Versions-That: xen=d3f3e447676667ef30b48708d359c8f8b13a9a03
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 09 Apr 2020 16:57:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 148126
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat    fail  like 148190
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass

version targeted for testing:
 xen                  181614a71070ee1dfb8d1fb954ca6127c24691a3
baseline version:
 xen                  d3f3e447676667ef30b48708d359c8f8b13a9a03

Last test of basis   148190  2020-03-06 20:43:40 Z   33 days
Testing same since   149553  2020-04-09 07:42:33 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  George Dunlap <george.dunlap@citrix.com>
  Igor Druzhinin <igor.druzhinin@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Julien Grall <jgrall@amazon.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Pu Wen <puwen@hygon.cn>
  Roger Pau Monné <roger.pau@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   d3f3e44767..181614a710  181614a71070ee1dfb8d1fb954ca6127c24691a3 -> stable-4.13


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 17:00:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 17:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMaXb-0002Ml-3P; Thu, 09 Apr 2020 17:00:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=tj/S=5Z=gmail.com=tamas.k.lengyel@srs-us1.protection.inumbo.net>)
 id 1jMaXa-0002Mf-3W
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 17:00:34 +0000
X-Inumbo-ID: 9f9ab882-7a83-11ea-83d8-bc764e2007e4
Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9f9ab882-7a83-11ea-83d8-bc764e2007e4;
 Thu, 09 Apr 2020 17:00:33 +0000 (UTC)
Received: by mail-wr1-x443.google.com with SMTP id 31so12752502wre.5
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 10:00:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=3IBPIWUiLj5pDwqbXqjaiDM2AWTTIB3K7o5/BNKahDk=;
 b=YzBMxcQtLtseF08kd1LuMQ/f9WyQ+9AVyyHKcZrh9eX7LaALst8mtjF3NI7hVD2R7B
 rpRKOovVA6U85DAvFJYrzCEHd9D8E3Ps+OCqI1jK7rbxWThwZy1nEuI5PKdvIbGintoA
 sI+D46Q3p3T89mrvGR+29SX7njSqVRMzg4s8EwZa1gZVGXRJREXBiG+i+6BrpQeNAReb
 VaqKVxPSURzNkCzHq4Y8GctKPcmb4q3T+ptBJ/+taYYRNguGg58p/Aot+2BnHu0vpg1s
 haoVPs2rLd9+sI+q/C6Wp2rHNVtrt+0TRogFpjBkWGHvs+EfoHa4udUnLWg5D76r6X9i
 6oXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=3IBPIWUiLj5pDwqbXqjaiDM2AWTTIB3K7o5/BNKahDk=;
 b=UYatsiKJ+IjZ6T6pMaQA+IqaeA8MtUQANI57ZOUMIY4y1ze/RYAv/qsvraDKzYZcda
 Nn3ejqNMfVM5rq3ku6JlYk3zsfKO+diFUFZzH4DLCOAhTfoEwD0O+SWHWYPTbDISLnS1
 EV7L93p2TwoYXjbIAnY7+Q3ypwR59CFEwo00+oYgHy832TjJ3nKSM6IeMhoH/2YQhdye
 RceEVg+IGgkIDghSlwP7vuP1oRySoKZp1A2SohvxqerimfE2nqmJZ0WGcige6mvfQl+s
 Q+Olux4wP++AT5Gsz/pD1hPWTSCoVFVPLXgoFR1YTE1kWcHyPqfnS/wUXcjZR3UgdGI1
 x1UQ==
X-Gm-Message-State: AGi0PuZjpAQ0nDO9nJUqTcR14uHoW89BmwXDfMV8umxQevzNxXW9kbcz
 k+x20nzEqzSiapb+lxMndCS/0Eh+qnD+31/AO3k/y8B3
X-Google-Smtp-Source: APiQypI6RrfOA0psMIS6YNgqDStmYdSCR/ADXG8GxfBHOY//acTZ+pGKcyeeOIBLDMP0jeL+Qe6DSjna6UQCuO95P7A=
X-Received: by 2002:adf:e811:: with SMTP id o17mr111989wrm.390.1586451631922; 
 Thu, 09 Apr 2020 10:00:31 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1586186121.git.tamas.lengyel@intel.com>
 <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
 <20200409154243.6ouh7r37fwm32mjg@debian>
 <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
 <20200409162159.cb2h7a6tmkbaduay@debian>
In-Reply-To: <20200409162159.cb2h7a6tmkbaduay@debian>
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Date: Thu, 9 Apr 2020 10:59:55 -0600
Message-ID: <CABfawhnaDS=nGn3+NqoY_nWXvu0cfsAmpYjiv9VqkT6C0Ow1FA@mail.gmail.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
To: Wei Liu <wl@xen.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 9, 2020 at 10:22 AM Wei Liu <wl@xen.org> wrote:
>
> On Thu, Apr 09, 2020 at 09:51:35AM -0600, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 9:43 AM Wei Liu <wl@xen.org> wrote:
> > >
> > > On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> > > > Add necessary bits to implement "xl fork-vm" commands. The command allows the
> > > > user to specify how to launch the device model allowing for a late-launch model
> > > > in which the user can execute the fork without the device model and decide to
> > > > only later launch it.
> > > >
> > > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> > > > ---
> > > [...]
> > > >
> > > > +int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
> > > > +                       libxl__domain_build_state *state,
> > > > +                       uint32_t *domid, bool soft_reset)
> > >
> > > It would have been nice if you could split the refactoring out to a
> > > separate patch.
> >
> > I found the toolstack to be way harder to work with then the
> > hypervisor code-base. Splitting the patches would have been nice but I
> > don't even know how to begin that since it's all such a spaghetti.
>
> In this case you've split out some code from a function to make a new
> function. That is a self-contained task, which can be in its own patch.
>
> >
> > >
> > > >  static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
> > > >                               libxl_domain_build_info *b_info)
> > > >  {
> > > > @@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
> > > >      ret = libxl__domain_config_setdefault(gc,d_config,domid);
> > > >      if (ret) goto error_out;
> > > >
> > > > -    ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > > > -                             dcs->soft_reset);
> > > > -    if (ret) {
> > > > -        LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > > > +    if ( !d_config->dm_restore_file )
> > > > +    {
> > > > +        ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > > > +                                 dcs->soft_reset);
> > > >          dcs->guest_domid = domid;
> > > > +
> > > > +        if (ret) {
> > > > +            LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > > > +            ret = ERROR_FAIL;
> > > > +            goto error_out;
> > > > +        }
> > > > +    } else if ( dcs->guest_domid != INVALID_DOMID ) {
> > >
> > > Coding style issue here.
> > >
> > > There are quite a few of them.  I won't point them out one by one
> > > though. Let's focus on the interface first.
> >
> > Do we have an automatic formatter we could just run on this code-base?
> > I don't know what style issue you are referring to and given that the
> > coding style here is different here compared to the hypervisor I find
> > it very hard to figure it out what other issues you spotted. Please
> > report them because I won't be able to spot them manually. To me it
> > all looks fine as-is.
>
> I feel your pain. There was work in progress to provide a style checker,
> but we're not there yet.
>
> Xen and libxc share one coding style while libxl and xl share another.
> There is a CODING_STYLE file under libxl directory.  The problem here is
> you should not have spaces inside ().
>
> Generally I think pointing out coding style issues tend to distract
> people from discussing more important things, so I would leave them last
> to fix.

I agree. I would highly prefer if we would get to a spot where they
wouldn't even have to be pointed out other then "run this command to
fix up the style". I submitted an astyle template already for Xen,
others prefer clang to do it, yet it's been like a year and doesn't
look like we will go anywhere with either. Just a waste of time IMHO.

>
> >
> > > >
> > > > +/*
> > > > + * The parent domain is expected to be created with default settings for
> > > > + * - max_evtch_port
> > > > + * - max_grant_frames
> > > > + * - max_maptrack_frames
> > > > + */
> > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> > > > +{
> > > > +    int rc;
> > > > +    struct xen_domctl_createdomain create = {0};
> > > > +    create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > +    create.flags |= XEN_DOMCTL_CDF_hap;
> > > > +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > > +    create.ssidref = SECINITSID_DOMU;
> > > > +    create.max_vcpus = max_vcpus;
> > >
> > >
> > > Some questions:
> > >
> > > Why does the caller need to specify the number of vcpus?
> > >
> > > Since the parent (source) domain is around, can you retrieve its domain
> > > configuration such that you know its max_vcpus and other information
> > > including max_evtchn_port and maptrack frames?
> >
> > Because we want to avoid having to issue an extra hypercall for these.
> > Normally these pieces of information will be available for the user
> > and won't change, so we save time by not querying for it every time a
> > fork is created. Remember, we might be creating thousands of forks in
> > a very short time, so those extra hypercalls add up.
>
> I see. Speed is a big concern to you.
>
> What I was referring to doesn't require issuing hypercalls but requires
> calling libxl_retrieve_domain_configuration. That's likely to be even
> slower than making a hypercall.

Right. We only want to parse the domain config if the device model is
being launched.

>
> I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> supported (as in Xen's support statement) going forward, because it is
> leaky.

What do you mean by leaky?

>
> I can see two solutions: 1. batch forking to reduce the number of
> queries needed; 2. make a proper domctl which duplicates the source
> domain structure inside Xen.

I've attempted to do that by extending the domain create hypercall so
that this information can be copied in the hypervisor. That approach
was very unpopular.

>
> Both of these require extra work. I think option 2 is better. But this
> is not asking you to do the work now. See below.
>
> While we want to make libxl APIs stable, we've had cases like COLO which
> we explicitly declared unstable.  Seeing this is a niche feature, this
> probably falls into the same category. In that case we reserve the right
> to rework the interface when necessary.

I'm fine with making this declared unstable. The hypervisor side bits
are also declared experimental and aren't even compiled in the normal
case.

Thanks,
Tamas


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 17:11:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 17:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMai1-0003GP-5P; Thu, 09 Apr 2020 17:11:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VOqT=5Z=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMahz-0003GK-RE
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 17:11:19 +0000
X-Inumbo-ID: 2075f4e9-7a85-11ea-8304-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2075f4e9-7a85-11ea-8304-12813bfff9fa;
 Thu, 09 Apr 2020 17:11:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=5mpcOQQOB6uuwLR/vKr4Lzr8sQYc2hhojgeuL5hZkqA=; b=kXu69VddbAV/FaQPdLAxsD1UiB
 2ZtX+lWo+LTWbJQ0WksysDsbdzHgj1OiLOlp0eIv3aKhyjAmRrgeo4fOZgCGyjlmjJBKarjmNaRbi
 D51UmIzPzJHKwsfZhFf0mbZ6aOqMPl8lyTPDzRyzolitbCfuDpNPhCGCzJNy0ua6G75c=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMahw-0002Uc-3v; Thu, 09 Apr 2020 17:11:16 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMahv-0007qh-R4; Thu, 09 Apr 2020 17:11:16 +0000
Date: Thu, 9 Apr 2020 18:11:13 +0100
From: Wei Liu <wl@xen.org>
To: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
Message-ID: <20200409171113.cajvhjlftadqqq73@debian>
References: <cover.1586186121.git.tamas.lengyel@intel.com>
 <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
 <20200409154243.6ouh7r37fwm32mjg@debian>
 <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
 <20200409162159.cb2h7a6tmkbaduay@debian>
 <CABfawhnaDS=nGn3+NqoY_nWXvu0cfsAmpYjiv9VqkT6C0Ow1FA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABfawhnaDS=nGn3+NqoY_nWXvu0cfsAmpYjiv9VqkT6C0Ow1FA@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
[...]
> >
> > >
> > > > >
> > > > > +/*
> > > > > + * The parent domain is expected to be created with default settings for
> > > > > + * - max_evtch_port
> > > > > + * - max_grant_frames
> > > > > + * - max_maptrack_frames
> > > > > + */
> > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> > > > > +{
> > > > > +    int rc;
> > > > > +    struct xen_domctl_createdomain create = {0};
> > > > > +    create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > +    create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > > > +    create.ssidref = SECINITSID_DOMU;
> > > > > +    create.max_vcpus = max_vcpus;
> > > >
> > > >
> > > > Some questions:
> > > >
> > > > Why does the caller need to specify the number of vcpus?
> > > >
> > > > Since the parent (source) domain is around, can you retrieve its domain
> > > > configuration such that you know its max_vcpus and other information
> > > > including max_evtchn_port and maptrack frames?
> > >
> > > Because we want to avoid having to issue an extra hypercall for these.
> > > Normally these pieces of information will be available for the user
> > > and won't change, so we save time by not querying for it every time a
> > > fork is created. Remember, we might be creating thousands of forks in
> > > a very short time, so those extra hypercalls add up.
> >
> > I see. Speed is a big concern to you.
> >
> > What I was referring to doesn't require issuing hypercalls but requires
> > calling libxl_retrieve_domain_configuration. That's likely to be even
> > slower than making a hypercall.
> 
> Right. We only want to parse the domain config if the device model is
> being launched.
> 
> >
> > I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> > supported (as in Xen's support statement) going forward, because it is
> > leaky.
> 
> What do you mean by leaky?

It requires the caller to specify the number of max_vcpus. The reason
for doing that is because you want to avoid extra hypercall(s). There is
nothing that stops someone from coming along in the future claiming some
other parameters are required because of the same concern you have
today. It is an optimisation, not a must-have in terms of functionality.

To me the number shouldn't be specified by the caller in the first
place. It is like forking a process somehow requires you to specify how
many threads it will have.

> 
> >
> > I can see two solutions: 1. batch forking to reduce the number of
> > queries needed; 2. make a proper domctl which duplicates the source
> > domain structure inside Xen.
> 
> I've attempted to do that by extending the domain create hypercall so
> that this information can be copied in the hypervisor. That approach
> was very unpopular.
> 

Sigh. Sorry I haven't had the chance to read previous discussions.
-ETIME.

Wei.


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 17:31:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 17:31:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMb1Z-0004uj-Tx; Thu, 09 Apr 2020 17:31:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=tj/S=5Z=gmail.com=tamas.k.lengyel@srs-us1.protection.inumbo.net>)
 id 1jMb1Y-0004ue-AZ
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 17:31:32 +0000
X-Inumbo-ID: f35245fe-7a87-11ea-b58d-bc764e2007e4
Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f35245fe-7a87-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 17:31:31 +0000 (UTC)
Received: by mail-wr1-x441.google.com with SMTP id 65so12867528wrl.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 10:31:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=9U+SFmuVEKPMqiO9SbKMssciL9jadcOK/xDYub/uv1I=;
 b=V/OyE5hmj6LQQGdEsKsiSdf2Yn8qMxTwFsXz7yi2fe/XA/wWMDXc/gipbktcvexdjy
 PyxyBa9b1ntg+TET0L+rQ4m0Uq8gtCwqyba3fFX1QukQzBiqW0QP1ZtoRvZaIOVqgON2
 toN8QYfl89Ad8urTVA6QAwCyG7xZNXtx3/muLsiOFOs2dmDSdp4/G68qCBTKplEyG3K2
 OnJ1kGRW3IwDYMajgsP6TBQwQOxap9oIdjGGn4fjv24ZdeHXC7hTd0ZFB7HR4SuKI13z
 +wKV2aOUbKR9RhIvUvME38FCQkwSY4s/gUxf0jgeLZWT45YY4hFjuhRL3j/mPw0ND1fR
 ZRwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=9U+SFmuVEKPMqiO9SbKMssciL9jadcOK/xDYub/uv1I=;
 b=n9zwwxItTotzx9QSjJEQREdPNDlF+lQbnFLnzRRGHHg+9D/roptj55cfyaTmLZ/qYc
 xup0wkBuruKo7ajys5UgBbIKzwg4wjbY5LJ76SFjVnLJ+hFqquKqUnYNJie8moQStaYV
 Fhr6LVfMLPwGbGKjW1JJKXAVfqrGKuLaoZ4VwQF0Nt/Yi/4tZdTdpKClrXXA2BJvoN3d
 snfBebgNAbAigM1ZCS7uiwBhJF8neT15FbOuvkJm5jhaEMblyQYcAW/ThEJbvl7RnSXw
 n22uWvj3XKx2ikEEdhar8w7aAgp6SO6iinCKXNMU/VQRcwpfcOlwlKxTqQGQ6cwYXZAn
 Lfew==
X-Gm-Message-State: AGi0PuYF3SOSxZSAWhhBbinghCpho/GeMvJPYccyNsREnTT19SsrxStO
 yhM5OUTikg4KGjnOZasxHm5mZaCCPo7uJh/yDjI=
X-Google-Smtp-Source: APiQypJULY5PYda9001iWJpn46eAoX4Zlz8zIssKQSBC9rXsJS96PujHqvVxt32uHDC3KKIZVtkAPOkdY6TXrzlhXUY=
X-Received: by 2002:adf:f98b:: with SMTP id f11mr197952wrr.259.1586453490540; 
 Thu, 09 Apr 2020 10:31:30 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1586186121.git.tamas.lengyel@intel.com>
 <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
 <20200409154243.6ouh7r37fwm32mjg@debian>
 <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
 <20200409162159.cb2h7a6tmkbaduay@debian>
 <CABfawhnaDS=nGn3+NqoY_nWXvu0cfsAmpYjiv9VqkT6C0Ow1FA@mail.gmail.com>
 <20200409171113.cajvhjlftadqqq73@debian>
In-Reply-To: <20200409171113.cajvhjlftadqqq73@debian>
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Date: Thu, 9 Apr 2020 11:30:54 -0600
Message-ID: <CABfawhmdSdC2kKzE5jLLCtkR9Pb4mcT6iRdzv0s=v0mQiju_Kg@mail.gmail.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
To: Wei Liu <wl@xen.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 9, 2020 at 11:11 AM Wei Liu <wl@xen.org> wrote:
>
> On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> [...]
> > >
> > > >
> > > > > >
> > > > > > +/*
> > > > > > + * The parent domain is expected to be created with default settings for
> > > > > > + * - max_evtch_port
> > > > > > + * - max_grant_frames
> > > > > > + * - max_maptrack_frames
> > > > > > + */
> > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> > > > > > +{
> > > > > > +    int rc;
> > > > > > +    struct xen_domctl_createdomain create = {0};
> > > > > > +    create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > +    create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > > > > +    create.ssidref = SECINITSID_DOMU;
> > > > > > +    create.max_vcpus = max_vcpus;
> > > > >
> > > > >
> > > > > Some questions:
> > > > >
> > > > > Why does the caller need to specify the number of vcpus?
> > > > >
> > > > > Since the parent (source) domain is around, can you retrieve its domain
> > > > > configuration such that you know its max_vcpus and other information
> > > > > including max_evtchn_port and maptrack frames?
> > > >
> > > > Because we want to avoid having to issue an extra hypercall for these.
> > > > Normally these pieces of information will be available for the user
> > > > and won't change, so we save time by not querying for it every time a
> > > > fork is created. Remember, we might be creating thousands of forks in
> > > > a very short time, so those extra hypercalls add up.
> > >
> > > I see. Speed is a big concern to you.
> > >
> > > What I was referring to doesn't require issuing hypercalls but requires
> > > calling libxl_retrieve_domain_configuration. That's likely to be even
> > > slower than making a hypercall.
> >
> > Right. We only want to parse the domain config if the device model is
> > being launched.
> >
> > >
> > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> > > supported (as in Xen's support statement) going forward, because it is
> > > leaky.
> >
> > What do you mean by leaky?
>
> It requires the caller to specify the number of max_vcpus. The reason
> for doing that is because you want to avoid extra hypercall(s). There is
> nothing that stops someone from coming along in the future claiming some
> other parameters are required because of the same concern you have
> today. It is an optimisation, not a must-have in terms of functionality.
>
> To me the number shouldn't be specified by the caller in the first
> place. It is like forking a process somehow requires you to specify how
> many threads it will have.

I agree. It's not how I wanted to have the interface work but
unfortunately this was the least "ugly" of the possible solutions
given the circumstances.

> >
> > >
> > > I can see two solutions: 1. batch forking to reduce the number of
> > > queries needed; 2. make a proper domctl which duplicates the source
> > > domain structure inside Xen.
> >
> > I've attempted to do that by extending the domain create hypercall so
> > that this information can be copied in the hypervisor. That approach
> > was very unpopular.
> >
>
> Sigh. Sorry I haven't had the chance to read previous discussions.
> -ETIME.

Sigh indeed.

Tamas


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 17:41:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 17:41:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMbAt-0005nR-UJ; Thu, 09 Apr 2020 17:41:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1Iid=5Z=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jMbAr-0005nM-Tb
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 17:41:09 +0000
X-Inumbo-ID: 4bcfd43e-7a89-11ea-b4f4-bc764e2007e4
Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4bcfd43e-7a89-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 17:41:09 +0000 (UTC)
Received: by mail-wm1-x342.google.com with SMTP id y24so601708wma.4
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 10:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=E5eep34qFM9WTUXMciMCrMC8mHfKlQON/nFhYf3jFqg=;
 b=ODOhJQQZ2cFHEdxIqvQv6xyJOshCXluZ3X/m2XbmUlkBFUXbhqC+gO95cz3qfNM5Rg
 IF0msiyf6IEAX/DfqN0XbF24R6kxFGr29ZCyhTLenP1xYzpXWy3tGoz439pAh/Zq2xIW
 2ugE7mSM2J06StaBuLztuOyQGd2hU/3OFyhUXahNh0KMyIR0oRJIvVDn+p6QFQGhkWYL
 HaAG7qUmyvn9gM1RB0923n0KMKrLuVoiu6ay0YEYPjDrs26KQAw3Qcq156k1pHEJlYV5
 mj4306ZKR9GU3yNd8JIuDlEcZuH/YrdxKjlaYOHjlYSnFPxF19gyR0rL11YAzZzF7s9h
 Y5rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:date:message-id
 :mime-version:content-transfer-encoding;
 bh=E5eep34qFM9WTUXMciMCrMC8mHfKlQON/nFhYf3jFqg=;
 b=SE325lX1nAxZRpGeOYFXI7Dalu0QGWAVzMDmMyRtdL9ipESWHNVYPhTamwofD+F9b4
 6ZF0WeAp2P7GbK6ZB4KCNDGuHk+tSGbQLLx4SA7kDZGamJuHPFqFraIIH01HX+qCiz0R
 p+ihOEBmjxXGVx6qHLp0nKN8KJ809QLvKULCisDta0G+Yw/PjhKm4Oip6DQ70frZw/Q8
 Cu741vF58yc8O6gelVWOeqauvRYaDqw/S3hE2V+Lels016j772yz+lI+YDEyumndh5+O
 N6wbDqvFfF+5biM1ppaKz957zf3nBn1mHcd2J2OoYSRI8ubBn7YN+tTW/dhXv4zeTV/F
 8FeQ==
X-Gm-Message-State: AGi0PubEwFwziePUxolZgkEReitC+tBt7mL9iNbZjShyXVUlmBD6tRPw
 BuhkBLM+eyXX8NRPigPKVTZI/uDz
X-Google-Smtp-Source: APiQypJpL/MirOXRsXiJ3Pr0IuG+zLESLV8Ljo43hy0WukG7hYWBrPgAWnp8khz1z/5UK8b/CtSrAg==
X-Received: by 2002:a1c:4c0f:: with SMTP id z15mr941417wmf.95.1586454068385;
 Thu, 09 Apr 2020 10:41:08 -0700 (PDT)
Received: from localhost.localdomain (44.142.6.51.dyn.plus.net. [51.6.142.44])
 by smtp.gmail.com with ESMTPSA id
 c18sm40086006wrx.5.2020.04.09.10.41.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Apr 2020 10:41:07 -0700 (PDT)
From: Wei Liu <wl@xen.org>
X-Google-Original-From: Wei Liu <liuwe@microsoft.com>
To: Xen Development List <xen-devel@lists.xenproject.org>
Subject: [PATCH v5 0/3] Xen on Hyper-V: Implement L0 assisted TLB flush
Date: Thu,  9 Apr 2020 18:41:01 +0100
Message-Id: <20200409174104.23946-1-liuwe@microsoft.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <liuwe@microsoft.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Michael Kelley <mikelley@microsoft.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi all

This seris is based on Roger's L0 assisted flush series v9. In patch 1 I
dropped FLUSH_TLB_FLAGS_MASK per Jan's request. Other than that, nothing
is changed.

Wei.

Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Wei Liu <wl@xen.org>
Cc: Roger Pau Monné <roger.pau@citrix.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Paul Durrant <pdurrant@amazon.com>

Wei Liu (3):
  x86/hypervisor: pass flags to hypervisor_flush_tlb
  x86/hyperv: skeleton for L0 assisted TLB flush
  x86/hyperv: L0 assisted TLB flush

 xen/arch/x86/guest/hyperv/Makefile     |   2 +
 xen/arch/x86/guest/hyperv/hyperv.c     |  17 ++
 xen/arch/x86/guest/hyperv/private.h    |  12 ++
 xen/arch/x86/guest/hyperv/tlb.c        | 214 +++++++++++++++++++++++++
 xen/arch/x86/guest/hyperv/util.c       |  75 +++++++++
 xen/arch/x86/guest/hypervisor.c        |   4 +-
 xen/arch/x86/guest/xen/xen.c           |   2 +-
 xen/arch/x86/smp.c                     |   2 +-
 xen/include/asm-x86/guest/hypervisor.h |  10 +-
 9 files changed, 329 insertions(+), 9 deletions(-)
 create mode 100644 xen/arch/x86/guest/hyperv/tlb.c
 create mode 100644 xen/arch/x86/guest/hyperv/util.c

-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 17:41:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 17:41:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMbAy-0005o3-6U; Thu, 09 Apr 2020 17:41:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1Iid=5Z=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jMbAw-0005nd-UW
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 17:41:14 +0000
X-Inumbo-ID: 4c808572-7a89-11ea-b4f4-bc764e2007e4
Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4c808572-7a89-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 17:41:10 +0000 (UTC)
Received: by mail-wr1-x444.google.com with SMTP id c15so12812157wro.11
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 10:41:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=wCPmXjDpRWok5TonwMVFK8+g7QHuptr6hywfXNboPyw=;
 b=O9cCtAz7/p3AvJ8doG7y5GZ7RPff25wtbtUKNKxFMr6wPZgOV+QZqAVcK4k64Ic9Yy
 dHwp9hQIeix9yRQRaNRYTyUJLPyk2Eyjp2ZxSini8N/6I57BWcTsUO4zFsoIbbfHNg/b
 JB9bUoVsJxBIu1uDIw7DLYafemuaps9NySImtrOdlGXRopSZ+TVPRBitNUl0+1OUHVN9
 BazVY8eiV12Eyfd+8cEOrlsPx+5XZwQhwCM7Ifo481NZWo3PNuk/EuURM00P2/kYybZe
 ICdjGkH7TuygQCew3hcPwS546ripXyb+9+oxoqx0kh/x/qnjJy8wXle+vm5w6bk4XwWo
 0zOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:date:message-id
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=wCPmXjDpRWok5TonwMVFK8+g7QHuptr6hywfXNboPyw=;
 b=bXR2hCqOfnkgZ/gqoxsBTYsj/BNQFPvnAj1LEuyieD11vveYJxcNZD1ld0v9liKgr8
 snUCJIVSPBTC/KFYAdtXbdT7iPG00+VGexsTT4+3eSfvj0I9JEUevH1/AxvHWyYvZuG3
 QRQh3eaEZ5KuzbXqwMIJx4Hf7mnVnNu54amZEoiZJ4uhqdpfnXk6fDVXh0m5pRTTHCxi
 G1PzmnFE1+9YVbm2+2Ng9kpZJxF4uC21JsJqHAFkaVbZ+Q5uKFlr/oHJhH2CHl5kuynK
 Y3gJjWfLGXbNIpoINO5pVZAlpnc0grQAPRYBFxzJ1i4qjqny2+eHB782ThKyRj+l6LUt
 ITsg==
X-Gm-Message-State: AGi0PubLFAsYc2aRnMZaheeK646pZ4kS/LOWD4qwEfDvQBtC8LYLZwYV
 woLk8x0ZTRyx20cCJsDqHvF38lSR
X-Google-Smtp-Source: APiQypJa3J31R9nVK7hXUvQcecFUXQdIH/hJQqh6LVJXbR1H+7hRKIOgSQlN6BbmpXJO+y+Rz6nW8w==
X-Received: by 2002:a5d:5273:: with SMTP id l19mr307445wrc.42.1586454069405;
 Thu, 09 Apr 2020 10:41:09 -0700 (PDT)
Received: from localhost.localdomain (44.142.6.51.dyn.plus.net. [51.6.142.44])
 by smtp.gmail.com with ESMTPSA id
 c18sm40086006wrx.5.2020.04.09.10.41.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Apr 2020 10:41:08 -0700 (PDT)
From: Wei Liu <wl@xen.org>
X-Google-Original-From: Wei Liu <liuwe@microsoft.com>
To: Xen Development List <xen-devel@lists.xenproject.org>
Subject: [PATCH v5 1/3] x86/hypervisor: pass flags to hypervisor_flush_tlb
Date: Thu,  9 Apr 2020 18:41:02 +0100
Message-Id: <20200409174104.23946-2-liuwe@microsoft.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200409174104.23946-1-liuwe@microsoft.com>
References: <20200409174104.23946-1-liuwe@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <liuwe@microsoft.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Michael Kelley <mikelley@microsoft.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hyper-V's L0 assisted flush has fine-grained control over what gets
flushed. We need all the flags available to make the best decisions
possible.

No functional change because Xen's implementation doesn't care about
what is passed to it.

Signed-off-by: Wei Liu <liuwe@microsoft.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Paul Durrant <pdurrant@amazon.com>
---
v5:
1. Drop FLUSH_TLB_FLAGS_MASK

v2:
1. Introduce FLUSH_TLB_FLAGS_MASK
---
 xen/arch/x86/guest/hypervisor.c        |  4 ++--
 xen/arch/x86/guest/xen/xen.c           |  2 +-
 xen/arch/x86/smp.c                     |  2 +-
 xen/include/asm-x86/guest/hypervisor.h | 10 +++++-----
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index e46de42ded..366af1d650 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -79,10 +79,10 @@ void __init hypervisor_e820_fixup(struct e820map *e820)
 }
 
 int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
-                         unsigned int order)
+                         unsigned int flags)
 {
     if ( ops.flush_tlb )
-        return alternative_call(ops.flush_tlb, mask, va, order);
+        return alternative_call(ops.flush_tlb, mask, va, flags);
 
     return -EOPNOTSUPP;
 }
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 3bc01c8723..2ff63d370a 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -324,7 +324,7 @@ static void __init e820_fixup(struct e820map *e820)
         pv_shim_fixup_e820(e820);
 }
 
-static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int order)
+static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int flags)
 {
     return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
 }
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 1d9fec65de..6f1aaa2106 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -272,7 +272,7 @@ void flush_area_mask(const cpumask_t *mask, const void *va, unsigned int flags)
         if ( cpu_has_hypervisor &&
              !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID |
                          FLUSH_ORDER_MASK)) &&
-             !hypervisor_flush_tlb(mask, va, (flags - 1) & FLUSH_ORDER_MASK) )
+             !hypervisor_flush_tlb(mask, va, flags) )
             return;
 
         spin_lock(&flush_lock);
diff --git a/xen/include/asm-x86/guest/hypervisor.h b/xen/include/asm-x86/guest/hypervisor.h
index 77a1d21824..0a6c3b47ab 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -35,7 +35,7 @@ struct hypervisor_ops {
     /* Fix up e820 map */
     void (*e820_fixup)(struct e820map *e820);
     /* L0 assisted TLB flush */
-    int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int order);
+    int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int flags);
 };
 
 #ifdef CONFIG_GUEST
@@ -48,11 +48,11 @@ void hypervisor_e820_fixup(struct e820map *e820);
 /*
  * L0 assisted TLB flush.
  * mask: cpumask of the dirty vCPUs that should be flushed.
- * va: linear address to flush, or NULL for global flushes.
- * order: order of the linear address pointed by va.
+ * va: linear address to flush, or NULL for entire address space.
+ * flags: flags for flushing, including the order of va.
  */
 int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
-                         unsigned int order);
+                         unsigned int flags);
 
 #else
 
@@ -65,7 +65,7 @@ static inline int hypervisor_ap_setup(void) { return 0; }
 static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
 static inline void hypervisor_e820_fixup(struct e820map *e820) {}
 static inline int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
-                                       unsigned int order)
+                                       unsigned int flags)
 {
     return -EOPNOTSUPP;
 }
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 17:41:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 17:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMbB3-0005pp-Ja; Thu, 09 Apr 2020 17:41:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1Iid=5Z=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jMbB1-0005pJ-VG
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 17:41:19 +0000
X-Inumbo-ID: 4d2034fa-7a89-11ea-b58d-bc764e2007e4
Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4d2034fa-7a89-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 17:41:11 +0000 (UTC)
Received: by mail-wm1-x343.google.com with SMTP id e26so605420wmk.5
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 10:41:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=Fc9JPgSv78+xCG8xAroRJyffb4ZlYuUW9C+bIDq7Dig=;
 b=b6jNlZ9zleAiNfWsT/73k8KaW+Vtjqmo7KQIln61Cd/lVRDilYJeC3KsqZ5WDjViWu
 J0tB2ZylSKq7ZZGlS/85n/hMuuJtI0XVqO+semrQKFYQzQtL7iiF2jERcux9jdbCFpm7
 hsn+l9Gn3CixYI1FRnYBQ/Xw66atQbOor+BCbprih1tOn9lAmQOFfEfFF+/LlcDWPb6y
 Jma0lC/AD9k0kUao5a62qAzAmCg9Ju34YuUn2kxFuSroQN6IPkerfDjb8TVFXMenZbHT
 ycQpKiNXxbI8DAAAdXamGMpzUhNLqd1wsG1lOHL8pejBTa+Oix+UaUv9J7XwCQvi2+La
 7V3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:date:message-id
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=Fc9JPgSv78+xCG8xAroRJyffb4ZlYuUW9C+bIDq7Dig=;
 b=SAToBnAGZBDIxb98yn7H4XXckn20ibYcBZbkyDkHPS5VcZi65ENEvN3R/4yXhrHsEn
 o9b5jLCbDydyNV3Olqti06gTRIBaKnmnjN91Ia2aZbEuz7G/vuI4GTjR70/JNGK7lLOk
 /UTpxr12T5T47J0m5jpxxkdbyWwcnA+iJBEBA8PbkMnKRqSA1nZ8KMTa4TaZPryL7WxP
 Tj+BkC7I3yW25uyecVFnyoI52WjW7LBY2/K5Nx0bSQA7gdapg4oCJEZchKRouku2g56q
 GR6CBRAAH6jK2QpX8b7Ml6DlSJAyzMLXKMw+qLwwIyxpF9+WGww9f3B4wpXW4GaqJTKf
 lnTA==
X-Gm-Message-State: AGi0PuYOVRR1HidSIqL+GGNjZHU/YlJ2P7yCIzTjLCZSAGSV8rWkLw/K
 0L0G4p3eTGgPAiT0ZXNqI5FgZNoq
X-Google-Smtp-Source: APiQypL6APmlptFTWAB/yog5obeCEbBAMDRInyAVp2hItq5HRAsKod8iunumJ0Cum0i49tgkkqpkLQ==
X-Received: by 2002:a1c:dc8b:: with SMTP id t133mr935246wmg.117.1586454070535; 
 Thu, 09 Apr 2020 10:41:10 -0700 (PDT)
Received: from localhost.localdomain (44.142.6.51.dyn.plus.net. [51.6.142.44])
 by smtp.gmail.com with ESMTPSA id
 c18sm40086006wrx.5.2020.04.09.10.41.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Apr 2020 10:41:10 -0700 (PDT)
From: Wei Liu <wl@xen.org>
X-Google-Original-From: Wei Liu <liuwe@microsoft.com>
To: Xen Development List <xen-devel@lists.xenproject.org>
Subject: [PATCH v5 2/3] x86/hyperv: skeleton for L0 assisted TLB flush
Date: Thu,  9 Apr 2020 18:41:03 +0100
Message-Id: <20200409174104.23946-3-liuwe@microsoft.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200409174104.23946-1-liuwe@microsoft.com>
References: <20200409174104.23946-1-liuwe@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <liuwe@microsoft.com>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Michael Kelley <mikelley@microsoft.com>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Implement a basic hook for L0 assisted TLB flush. The hook needs to
check if prerequisites are met. If they are not met, it returns an error
number to fall back to native flushes.

Introduce a new variable to indicate if hypercall page is ready.

Signed-off-by: Wei Liu <liuwe@microsoft.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Paul Durrant <pdurrant@amazon.com>
---
v3:
1. Change hv_hcall_page_ready to hcall_page_ready
---
 xen/arch/x86/guest/hyperv/Makefile  |  1 +
 xen/arch/x86/guest/hyperv/hyperv.c  | 17 ++++++++++++
 xen/arch/x86/guest/hyperv/private.h |  4 +++
 xen/arch/x86/guest/hyperv/tlb.c     | 41 +++++++++++++++++++++++++++++
 4 files changed, 63 insertions(+)
 create mode 100644 xen/arch/x86/guest/hyperv/tlb.c

diff --git a/xen/arch/x86/guest/hyperv/Makefile b/xen/arch/x86/guest/hyperv/Makefile
index 68170109a9..18902c33e9 100644
--- a/xen/arch/x86/guest/hyperv/Makefile
+++ b/xen/arch/x86/guest/hyperv/Makefile
@@ -1 +1,2 @@
 obj-y += hyperv.o
+obj-y += tlb.o
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c
index 5ad16cf0fe..91a6782cd9 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -33,6 +33,8 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
 DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
 DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
 
+static bool __read_mostly hcall_page_ready;
+
 static uint64_t generate_guest_id(void)
 {
     union hv_guest_os_id id = {};
@@ -119,6 +121,8 @@ static void __init setup_hypercall_page(void)
     BUG_ON(!hypercall_msr.enable);
 
     set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
+
+    hcall_page_ready = true;
 }
 
 static int setup_hypercall_pcpu_arg(void)
@@ -199,11 +203,24 @@ static void __init e820_fixup(struct e820map *e820)
         panic("Unable to reserve Hyper-V hypercall range\n");
 }
 
+static int flush_tlb(const cpumask_t *mask, const void *va,
+                     unsigned int flags)
+{
+    if ( !(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED) )
+        return -EOPNOTSUPP;
+
+    if ( !hcall_page_ready || !this_cpu(hv_input_page) )
+        return -ENXIO;
+
+    return hyperv_flush_tlb(mask, va, flags);
+}
+
 static const struct hypervisor_ops __initconstrel ops = {
     .name = "Hyper-V",
     .setup = setup,
     .ap_setup = ap_setup,
     .e820_fixup = e820_fixup,
+    .flush_tlb = flush_tlb,
 };
 
 /*
diff --git a/xen/arch/x86/guest/hyperv/private.h b/xen/arch/x86/guest/hyperv/private.h
index 956eff831f..509bedaafa 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -22,10 +22,14 @@
 #ifndef __XEN_HYPERV_PRIVIATE_H__
 #define __XEN_HYPERV_PRIVIATE_H__
 
+#include <xen/cpumask.h>
 #include <xen/percpu.h>
 
 DECLARE_PER_CPU(void *, hv_input_page);
 DECLARE_PER_CPU(void *, hv_vp_assist);
 DECLARE_PER_CPU(unsigned int, hv_vp_index);
 
+int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
+                     unsigned int flags);
+
 #endif /* __XEN_HYPERV_PRIVIATE_H__  */
diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
new file mode 100644
index 0000000000..48f527229e
--- /dev/null
+++ b/xen/arch/x86/guest/hyperv/tlb.c
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * arch/x86/guest/hyperv/tlb.c
+ *
+ * Support for TLB management using hypercalls
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 <http://www.gnu.org/licenses/>.
+ *
+ * Copyright (c) 2020 Microsoft.
+ */
+
+#include <xen/cpumask.h>
+#include <xen/errno.h>
+
+#include "private.h"
+
+int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
+                     unsigned int flags)
+{
+    return -EOPNOTSUPP;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 17:41:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 17:41:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMbB7-0005rZ-T9; Thu, 09 Apr 2020 17:41:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=1Iid=5Z=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jMbB6-0005rE-UR
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 17:41:24 +0000
X-Inumbo-ID: 4de4d7ba-7a89-11ea-b4f4-bc764e2007e4
Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4de4d7ba-7a89-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 17:41:12 +0000 (UTC)
Received: by mail-wm1-x341.google.com with SMTP id v8so3051587wma.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 10:41:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=2F2O9s9Zc4ZX68a+NmydCfhV6kbxcg3bJyRTM2EJKps=;
 b=PtGMG9droI7XIjQ+z7/jmhIzwj3aDP5imKw8R4niozPTHOihg4ZSsKLJhL2fFMyt//
 uVWy8OsDn+dmphxVETgTfckskIC6WCq7paX317/iT5a3TBfMazokvn6hOU7J12wjl9tb
 QgEQJajBYyMslFm4ljZwBdFghgcfRA9jcgT2/WJABcdHD1H+cqrUUWGHMhaOB+Jg5YCM
 qJhi83TKn/JbG844Zotlppt9h0xXRDsLEFto2DrF+wm4ytp/mATlvMaXkgnO2y1CQImZ
 OGHZXkxzkreP4rnh6NhYXKfTB6eWGL/S7q8p/FORGmgI3DQ8+03hU3C2+RTWDkFwdQZI
 IKQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:date:message-id
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=2F2O9s9Zc4ZX68a+NmydCfhV6kbxcg3bJyRTM2EJKps=;
 b=o+he5oSl3+NZgMiVztqaP1jS1P9/YEbsUhJ0uq1HEf8q8f6KVkqGxUIAoZOmMMjHg/
 HMfXU0OBWr/2dPIwTl94JabSX90mIJdoiuroW/waWIOyNVziEWZk8frooXBQX4Jh1imJ
 Cs6qQTix/2CwndCZ7n1fZKjpV8Wtlh2vXmiD9stRZyuz9f62NlDnxnw4863Zdlgl8i0p
 bA40AqoHK6NQE22AzlFY87xlelSKJ3LcHRLO/ANodzhxhHcy9wOCwA0Z0EH8jbQ5uNL8
 BXpIurtHuaIYoqb+zcQw5UsoX7bLKo1w4d2TxpQmE+0Sik1lDhJt/rPYfXxqHcFmiHV0
 9qJA==
X-Gm-Message-State: AGi0PuZfDf0bCSJnTNEK2RHWiP2bzTX90bSQ8L1GIXoHpirPWFlzevbQ
 eUeXsvXBDPq3LWrEjQmOohJrBS2Q
X-Google-Smtp-Source: APiQypKENGDAcq7izSS9ZXcR1OI/JnkXG7tdY5qav/XOGEjtXlBwQZVuieT69eLvsQJbPo/gculqxw==
X-Received: by 2002:a1c:1d84:: with SMTP id d126mr928975wmd.119.1586454071634; 
 Thu, 09 Apr 2020 10:41:11 -0700 (PDT)
Received: from localhost.localdomain (44.142.6.51.dyn.plus.net. [51.6.142.44])
 by smtp.gmail.com with ESMTPSA id
 c18sm40086006wrx.5.2020.04.09.10.41.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Apr 2020 10:41:11 -0700 (PDT)
From: Wei Liu <wl@xen.org>
X-Google-Original-From: Wei Liu <liuwe@microsoft.com>
To: Xen Development List <xen-devel@lists.xenproject.org>
Subject: [PATCH v5 3/3] x86/hyperv: L0 assisted TLB flush
Date: Thu,  9 Apr 2020 18:41:04 +0100
Message-Id: <20200409174104.23946-4-liuwe@microsoft.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200409174104.23946-1-liuwe@microsoft.com>
References: <20200409174104.23946-1-liuwe@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <liuwe@microsoft.com>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Michael Kelley <mikelley@microsoft.com>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
of several hypercalls:

 * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
 * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
 * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
 * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX

Pick the most efficient hypercalls available.

Signed-off-by: Wei Liu <liuwe@microsoft.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Paul Durrant <pdurrant@amazon.com>
---
v4:
1. Fix bank mask generation.
2. Fix page order calculation.
3. Remove types.h from private.h.
4. Add a note about nmi and mc handling.

v3:
1. Address more comments.
2. Fix usage of max_vp_index.
3. Use the fill_gva_list algorithm from Linux.

v2:
1. Address Roger and Jan's comments re types etc.
2. Fix pointer arithmetic.
3. Misc improvement to code.
---
 xen/arch/x86/guest/hyperv/Makefile  |   1 +
 xen/arch/x86/guest/hyperv/private.h |   8 ++
 xen/arch/x86/guest/hyperv/tlb.c     | 175 +++++++++++++++++++++++++++-
 xen/arch/x86/guest/hyperv/util.c    |  75 ++++++++++++
 4 files changed, 258 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/x86/guest/hyperv/util.c

diff --git a/xen/arch/x86/guest/hyperv/Makefile b/xen/arch/x86/guest/hyperv/Makefile
index 18902c33e9..0e39410968 100644
--- a/xen/arch/x86/guest/hyperv/Makefile
+++ b/xen/arch/x86/guest/hyperv/Makefile
@@ -1,2 +1,3 @@
 obj-y += hyperv.o
 obj-y += tlb.o
+obj-y += util.o
diff --git a/xen/arch/x86/guest/hyperv/private.h b/xen/arch/x86/guest/hyperv/private.h
index 509bedaafa..354fc7f685 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -29,7 +29,15 @@ DECLARE_PER_CPU(void *, hv_input_page);
 DECLARE_PER_CPU(void *, hv_vp_assist);
 DECLARE_PER_CPU(unsigned int, hv_vp_index);
 
+static inline unsigned int hv_vp_index(unsigned int cpu)
+{
+    return per_cpu(hv_vp_index, cpu);
+}
+
 int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
                      unsigned int flags);
 
+/* Returns number of banks, -ev if error */
+int cpumask_to_vpset(struct hv_vpset *vpset, const cpumask_t *mask);
+
 #endif /* __XEN_HYPERV_PRIVIATE_H__  */
diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
index 48f527229e..1d723d6ee6 100644
--- a/xen/arch/x86/guest/hyperv/tlb.c
+++ b/xen/arch/x86/guest/hyperv/tlb.c
@@ -19,17 +19,190 @@
  * Copyright (c) 2020 Microsoft.
  */
 
+#include <xen/cpu.h>
 #include <xen/cpumask.h>
 #include <xen/errno.h>
 
+#include <asm/guest/hyperv.h>
+#include <asm/guest/hyperv-hcall.h>
+#include <asm/guest/hyperv-tlfs.h>
+
 #include "private.h"
 
+/*
+ * It is possible to encode up to 4096 pages using the lower 12 bits
+ * in an element of gva_list
+ */
+#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
+
+static unsigned int fill_gva_list(uint64_t *gva_list, const void *va,
+                                  unsigned int order)
+{
+    unsigned long cur = (unsigned long)va;
+    /* end is 1 past the range to be flushed */
+    unsigned long end = cur + (PAGE_SIZE << order);
+    unsigned int n = 0;
+
+    do {
+        unsigned long diff = end - cur;
+
+        gva_list[n] = cur & PAGE_MASK;
+
+        /*
+         * Use lower 12 bits to encode the number of additional pages
+         * to flush
+         */
+        if ( diff >= HV_TLB_FLUSH_UNIT )
+        {
+            gva_list[n] |= ~PAGE_MASK;
+            cur += HV_TLB_FLUSH_UNIT;
+        }
+        else
+        {
+            gva_list[n] |= (diff - 1) >> PAGE_SHIFT;
+            cur = end;
+        }
+
+        n++;
+    } while ( cur < end );
+
+    return n;
+}
+
+static uint64_t flush_tlb_ex(const cpumask_t *mask, const void *va,
+                             unsigned int flags)
+{
+    struct hv_tlb_flush_ex *flush = this_cpu(hv_input_page);
+    int nr_banks;
+    unsigned int max_gvas, order = (flags - 1) & FLUSH_ORDER_MASK;
+    uint64_t *gva_list;
+
+    if ( !flush || local_irq_is_enabled() )
+    {
+        ASSERT_UNREACHABLE();
+        return ~0ULL;
+    }
+
+    if ( !(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED) )
+        return ~0ULL;
+
+    flush->address_space = 0;
+    flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
+    if ( !(flags & FLUSH_TLB_GLOBAL) )
+        flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
+
+    nr_banks = cpumask_to_vpset(&flush->hv_vp_set, mask);
+    if ( nr_banks < 0 )
+        return ~0ULL;
+
+    max_gvas =
+        (PAGE_SIZE - sizeof(*flush) - nr_banks *
+         sizeof(flush->hv_vp_set.bank_contents[0])) /
+        sizeof(uint64_t);       /* gva is represented as uint64_t */
+
+    /*
+     * Flush the entire address space if va is NULL or if there is not
+     * enough space for gva_list.
+     */
+    if ( !va || (PAGE_SIZE << order) / HV_TLB_FLUSH_UNIT > max_gvas )
+        return hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX, 0,
+                                   nr_banks, virt_to_maddr(flush), 0);
+
+    /*
+     * The calculation of gva_list address requires the structure to
+     * be 64 bits aligned.
+     */
+    BUILD_BUG_ON(sizeof(*flush) % sizeof(uint64_t));
+    gva_list = (uint64_t *)flush + sizeof(*flush) / sizeof(uint64_t) + nr_banks;
+
+    return hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX,
+                               fill_gva_list(gva_list, va, order),
+                               nr_banks, virt_to_maddr(flush), 0);
+}
+
+/* Maximum number of gvas for hv_tlb_flush */
+#define MAX_GVAS ((PAGE_SIZE - sizeof(struct hv_tlb_flush)) / sizeof(uint64_t))
+
 int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
                      unsigned int flags)
 {
-    return -EOPNOTSUPP;
+    unsigned long irq_flags;
+    struct hv_tlb_flush *flush = this_cpu(hv_input_page);
+    unsigned int order = (flags - 1) & FLUSH_ORDER_MASK;
+    uint64_t ret;
+
+    if ( !flush || cpumask_empty(mask) )
+    {
+        ASSERT_UNREACHABLE();
+        return -EINVAL;
+    }
+
+    /* TODO: may need to check if in #NMI or #MC and fallback to native path */
+
+    local_irq_save(irq_flags);
+
+    flush->address_space = 0;
+    flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
+    flush->processor_mask = 0;
+    if ( !(flags & FLUSH_TLB_GLOBAL) )
+        flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
+
+    if ( cpumask_equal(mask, &cpu_online_map) )
+        flush->flags |= HV_FLUSH_ALL_PROCESSORS;
+    else
+    {
+        unsigned int cpu;
+
+        /*
+         * Normally VP indices are in ascending order and match Xen's
+         * idea of CPU ids. Check the last index to see if VP index is
+         * >= 64. If so, we can skip setting up parameters for
+         * non-applicable hypercalls without looking further.
+         */
+        if ( hv_vp_index(cpumask_last(mask)) >= 64 )
+            goto do_ex_hypercall;
+
+        for_each_cpu ( cpu, mask )
+        {
+            unsigned int vpid = hv_vp_index(cpu);
+
+            if ( vpid >= ms_hyperv.max_vp_index )
+            {
+                local_irq_restore(irq_flags);
+                return -ENXIO;
+            }
+
+            if ( vpid >= 64 )
+                goto do_ex_hypercall;
+
+            __set_bit(vpid, &flush->processor_mask);
+        }
+    }
+
+    /*
+     * Flush the entire address space if va is NULL or if there is not
+     * enough space for gva_list.
+     */
+    if ( !va || (PAGE_SIZE << order) / HV_TLB_FLUSH_UNIT > MAX_GVAS )
+        ret = hv_do_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE,
+                              virt_to_maddr(flush), 0);
+    else
+        ret = hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST,
+                                  fill_gva_list(flush->gva_list, va, order),
+                                  0, virt_to_maddr(flush), 0);
+    goto done;
+
+ do_ex_hypercall:
+    ret = flush_tlb_ex(mask, va, flags);
+
+ done:
+    local_irq_restore(irq_flags);
+
+    return ret & HV_HYPERCALL_RESULT_MASK ? -ENXIO : 0;
 }
 
+#undef MAX_GVAS
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/guest/hyperv/util.c b/xen/arch/x86/guest/hyperv/util.c
new file mode 100644
index 0000000000..bec61c2afd
--- /dev/null
+++ b/xen/arch/x86/guest/hyperv/util.c
@@ -0,0 +1,75 @@
+/******************************************************************************
+ * arch/x86/guest/hyperv/util.c
+ *
+ * Hyper-V utility functions
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 <http://www.gnu.org/licenses/>.
+ *
+ * Copyright (c) 2020 Microsoft.
+ */
+
+#include <xen/cpu.h>
+#include <xen/cpumask.h>
+#include <xen/errno.h>
+
+#include <asm/guest/hyperv.h>
+#include <asm/guest/hyperv-tlfs.h>
+
+#include "private.h"
+
+int cpumask_to_vpset(struct hv_vpset *vpset,
+                     const cpumask_t *mask)
+{
+    int nr = 1;
+    unsigned int cpu, vcpu_bank, vcpu_offset;
+    unsigned int max_banks = ms_hyperv.max_vp_index / 64;
+
+    /* Up to 64 banks can be represented by valid_bank_mask */
+    if ( max_banks > 64 )
+        return -E2BIG;
+
+    /* Clear all banks to avoid flushing unwanted CPUs */
+    for ( vcpu_bank = 0; vcpu_bank < max_banks; vcpu_bank++ )
+        vpset->bank_contents[vcpu_bank] = 0;
+
+    vpset->format = HV_GENERIC_SET_SPARSE_4K;
+
+    for_each_cpu ( cpu, mask )
+    {
+        unsigned int vcpu = hv_vp_index(cpu);
+
+        vcpu_bank = vcpu / 64;
+        vcpu_offset = vcpu % 64;
+
+        __set_bit(vcpu_offset, &vpset->bank_contents[vcpu_bank]);
+
+        if ( vcpu_bank >= nr )
+            nr = vcpu_bank + 1;
+    }
+
+    /* Some banks may be empty but that's ok */
+    vpset->valid_bank_mask = ~0ULL >> (64 - nr);
+
+    return nr;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 18:00:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 18:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMbSv-000760-Im; Thu, 09 Apr 2020 17:59:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Jqn0=5Z=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMbSu-00075v-3Q
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 17:59:48 +0000
X-Inumbo-ID: e3065d3a-7a8b-11ea-8319-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e3065d3a-7a8b-11ea-8319-12813bfff9fa;
 Thu, 09 Apr 2020 17:59:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Un2cVn5ZwaqDhIGMxwsNqcNOJaqkFHIuyxYcwDKlbN0=; b=q1V8E5WmNzSWMcXJWhaH23Q04
 ILbOTAJ1Tz7yE/10FzRW71U71mb0twjkkGjPhluIms4d+Eo/J7dWPNJQXbw+aa5zc0YebEIY+k//n
 bN1pEORfYrY884IwTjiyhpSrsZt38mFIbaHLvHwTKQHglykiHIMea/ZVVoFby7jyxRGSo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMbSn-0003Pd-DQ; Thu, 09 Apr 2020 17:59:41 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMbSn-0001Ls-1F; Thu, 09 Apr 2020 17:59:41 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMbSn-0000wB-0Z; Thu, 09 Apr 2020 17:59:41 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149568-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149568: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=4fb402b486121c0110dd8cbc2ef2791ab9c1af73
X-Osstest-Versions-That: xen=9be0b2747bc7381c684cfbdd3fa2e40badefbeef
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 09 Apr 2020 17:59:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  4fb402b486121c0110dd8cbc2ef2791ab9c1af73
baseline version:
 xen                  9be0b2747bc7381c684cfbdd3fa2e40badefbeef

Last test of basis   149523  2020-04-08 12:00:53 Z    1 days
Testing same since   149568  2020-04-09 15:00:37 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Panyakin <apanyaki@amazon.com>
  Dmitry Isaykin <isaikin-dmitry@yandex.ru>
  Wei Liu <wl@xen.org>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   9be0b2747b..4fb402b486  4fb402b486121c0110dd8cbc2ef2791ab9c1af73 -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 18:01:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 18:01:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMbUK-0007vU-Va; Thu, 09 Apr 2020 18:01:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=0x02=5Z=invisiblethingslab.com=marmarek@srs-us1.protection.inumbo.net>)
 id 1jMbUJ-0007vO-PY
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 18:01:15 +0000
X-Inumbo-ID: 1a5d4fe6-7a8c-11ea-8319-12813bfff9fa
Received: from out2-smtp.messagingengine.com (unknown [66.111.4.26])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1a5d4fe6-7a8c-11ea-8319-12813bfff9fa;
 Thu, 09 Apr 2020 18:01:14 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailout.nyi.internal (Postfix) with ESMTP id 5E4155C1780;
 Thu,  9 Apr 2020 14:01:14 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute3.internal (MEProxy); Thu, 09 Apr 2020 14:01:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gRT/1G
 S2FNE/8Wz1ufJKMIEmWJdN8Pr16tSQgYlosk0=; b=rI99I94ieaKiZqAKXxB6X6
 R2NlVaYYO7Kxgfb/kMvwPw0+BuD5/dlhWCE1u0b5mT0XQCQhYCvSvm5AWsftdMna
 RwBNcZM/WihKx6o6B640AwU3ACdHizg6NphPBNNEk3U4ZOlNfc046wg63tnQrl29
 TQ0plNll24D+ilqVcEIuMaY3cr9lM5/P2UB+9QnDUz+Oh6qL8m6dOhxdtKPjqKlV
 ColNi7OEJIhG01hGSFwTZSFgIAcKPsiZDdc73pVEx4nfJZ7dFI/kl6AgTGstrS6E
 sh6VT0rt2NLPi/fe/c32JysRhRhG//OfLcTdPxwLtUxtT2/7k7/Y5u6WqFi+TQhw
 ==
X-ME-Sender: <xms:6mKPXsO1aGDudd6wuRaPvrhwImHnXpyN4RwS4UJ9dtZ8NBHCscAPiw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelgdduudegucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk
 ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh
 hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucfkphepledurdeihedrfeegrdef
 feenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrg
 hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: <xmx:6mKPXug8uI_RR_rkK7gU5fNZG9FIwqN1hysr51P8Nmw3h_Y4rW-1bg>
 <xmx:6mKPXjT7BNxhU_XrZ9IK3G7PH2lu0HDHdYbxnqNTe40z1aWF-1oS1Q>
 <xmx:6mKPXpqgENYCxrvEwrHBlNwOQBZFhrKGDIPH3xnMh9-T-3rf4PSfqQ>
 <xmx:6mKPXhyhiqZD2h4mwn-GDyHQ_dAoClgzkMPt61t-oeixBxxO7obCYQ>
Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33])
 by mail.messagingengine.com (Postfix) with ESMTPA id EF6B6306005C;
 Thu,  9 Apr 2020 14:01:12 -0400 (EDT)
Date: Thu, 9 Apr 2020 20:01:09 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: preparations for 4.13.1 and 4.12.3
Message-ID: <20200409180109.GK2995@mail-itl>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="Bzq2cJcN05fcPrs+"
Content-Disposition: inline
In-Reply-To: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--Bzq2cJcN05fcPrs+
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: preparations for 4.13.1 and 4.12.3

On Thu, Apr 09, 2020 at 09:41:49AM +0200, Jan Beulich wrote:
> All,
>=20
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)

Proposed backports (tools):

0d99c909d7 libxl: wait for console path before firing console_available
d094e95fb7 libxl: fix cleanup bug in initiate_domain_create()
1f706eace3 libxl: create domain 'error' node in xenstore
e19b4b3b55 tools/python: mismatch between pyxc_methods flags and PyObject d=
efinitions
1430c5a8ca tools/python: Python 3 compatibility

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

--Bzq2cJcN05fcPrs+
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl6PYuUACgkQ24/THMrX
1yw/Mwf+Ns82HujB6laFsidLGACV6xGcbI2eK1zMjoH972p/6ZDTK4f/BVL2y4Pa
8GT5E5p1XbtB+eM3OyZCwD5rj61X0yf4NxEFB6VRb7qKWiAKewMsgwPrTlVrdLsu
RYwlbTHYEHCq9ABCDWMBrIxGT7hFQnqxEjASbmbExAN48Q2JmN1+zuy64utkquao
QibnHVUDEl+Rti0Q+gFrHK3vbil1Dx8uEX+zjCISxav9I/gRZI7Je8YZGz7PIyuz
Ta04O5uKXMXqQWOCTOO8iSl2arzX4s80kj183fdhPCLuHgOUfNftcQuauD07FJMk
ib0UYgy3pt5eLe9R7OZnEXtUbrq6bg==
=nggg
-----END PGP SIGNATURE-----

--Bzq2cJcN05fcPrs+--


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 19:39:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 19:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMd1X-0006rJ-QO; Thu, 09 Apr 2020 19:39:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Jqn0=5Z=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMd1W-0006rE-F6
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 19:39:38 +0000
X-Inumbo-ID: d6bdc5e7-7a99-11ea-834a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d6bdc5e7-7a99-11ea-834a-12813bfff9fa;
 Thu, 09 Apr 2020 19:39:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=lGBfu5Sa2/+LyPCaOCWmpXXX3KpOCXmOM9o52kzz/O4=; b=ix0S8iIIllrOr/j36snfDG5hY
 yPutObtrxqReZmQyVDAEI3PP69QjNOuohlWS+yQlgDKPyRxgbdaKK1nr+pXHd3s6eZtPKN4+cOBGS
 01YNi5yQdX0+3pX3R4MfZDbEuVqlrwTC1efus2Qo7CAoG6wgTd/A1zcQfCxmPiyw2aJ14=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMd1S-0005O4-2x; Thu, 09 Apr 2020 19:39:34 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMd1R-0006XI-Nb; Thu, 09 Apr 2020 19:39:33 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMd1R-0001px-Mr; Thu, 09 Apr 2020 19:39:33 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149554-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.12-testing test] 149554: regressions - FAIL
X-Osstest-Failures: xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-saverestore.2:fail:regression
 xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=c1a1c4e8fb54038aee36305531426da4e3ad3872
X-Osstest-Versions-That: xen=824bdb432fc8831ee4684e45361a78faee4548ed
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 09 Apr 2020 19:39:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2    16 guest-saverestore.2      fail REGR. vs. 148185

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 xen                  c1a1c4e8fb54038aee36305531426da4e3ad3872
baseline version:
 xen                  824bdb432fc8831ee4684e45361a78faee4548ed

Last test of basis   148185  2020-03-06 18:13:31 Z   34 days
Testing same since   149554  2020-04-09 07:42:33 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  George Dunlap <george.dunlap@citrix.com>
  Igor Druzhinin <igor.druzhinin@citrix.com>
  Jan Beulich <jbeulich@suse.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit c1a1c4e8fb54038aee36305531426da4e3ad3872
Author: Dario Faggioli <dfaggioli@suse.com>
Date:   Thu Apr 9 09:36:51 2020 +0200

    credit2: fix credit reset happening too few times
    
    There is a bug in commit 5e4b4199667b9 ("xen: credit2: only reset
    credit on reset condition"). In fact, the aim of that commit was to
    make sure that we do not perform too many credit reset operations
    (which are not super cheap, and in an hot-path). But the check used
    to determine whether a reset is necessary was the wrong one.
    
    In fact, knowing just that some vCPUs have been skipped, while
    traversing the runqueue (in runq_candidate()), is not enough. We
    need to check explicitly whether the first vCPU in the runqueue
    has a negative amount of credit.
    
    Since a trace record is changed, this patch updates xentrace format file
    and xenalyze as well
    
    This should be backported.
    
    Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
    Acked-by: George Dunlap <george.dunlap@citrix.com>
    master commit: dae7b62e976b28af9c8efa150618c25501bf1650
    master date: 2020-04-03 10:46:53 +0200

commit 4c69d1c2dbe0ad1f5343852d9e596fe870892a6c
Author: Dario Faggioli <dfaggioli@suse.com>
Date:   Thu Apr 9 09:36:08 2020 +0200

    credit2: avoid vCPUs to ever reach lower credits than idle
    
    There have been report of stalls of guest vCPUs, when Credit2 was used.
    It seemed like these vCPUs were not getting scheduled for very long
    time, even under light load conditions (e.g., during dom0 boot).
    
    Investigations led to the discovery that --although rarely-- it can
    happen that a vCPU manages to run for very long timeslices. In Credit2,
    this means that, when runtime accounting happens, the vCPU will lose a
    large quantity of credits. This in turn may lead to the vCPU having less
    credits than the idle vCPUs (-2^30). At this point, the scheduler will
    pick the idle vCPU, instead of the ready to run vCPU, for a few
    "epochs", which often times is enough for the guest kernel to think the
    vCPU is not responding and crashing.
    
    An example of this situation is shown here. In fact, we can see d0v1
    sitting in the runqueue while all the CPUs are idle, as it has
    -1254238270 credits, which is smaller than -2^30 = −1073741824:
    
        (XEN) Runqueue 0:
        (XEN)   ncpus              = 28
        (XEN)   cpus               = 0-27
        (XEN)   max_weight         = 256
        (XEN)   pick_bias          = 22
        (XEN)   instload           = 1
        (XEN)   aveload            = 293391 (~111%)
        (XEN)   idlers: 00,00000000,00000000,00000000,00000000,00000000,0fffffff
        (XEN)   tickled: 00,00000000,00000000,00000000,00000000,00000000,00000000
        (XEN)   fully idle cores: 00,00000000,00000000,00000000,00000000,00000000,0fffffff
        [...]
        (XEN) Runqueue 0:
        (XEN) CPU[00] runq=0, sibling=00,..., core=00,...
        (XEN) CPU[01] runq=0, sibling=00,..., core=00,...
        [...]
        (XEN) CPU[26] runq=0, sibling=00,..., core=00,...
        (XEN) CPU[27] runq=0, sibling=00,..., core=00,...
        (XEN) RUNQ:
        (XEN)     0: [0.1] flags=0 cpu=5 credit=-1254238270 [w=256] load=262144 (~100%)
    
    We certainly don't want, under any circumstance, this to happen.
    Let's, therefore, define a minimum amount of credits a vCPU can have.
    During accounting, we make sure that, for however long the vCPU has
    run, it will never get to have less than such minimum amount of
    credits. Then, we set the credits of the idle vCPU to an even
    smaller value.
    
    NOTE: investigations have been done about _how_ it is possible for a
    vCPU to execute for so much time that its credits becomes so low. While
    still not completely clear, there are evidence that:
    - it only happens very rarely,
    - it appears to be both machine and workload specific,
    - it does not look to be a Credit2 (e.g., as it happens when
      running with Credit1 as well) issue, or a scheduler issue.
    
    This patch makes Credit2 more robust to events like this, whatever
    the cause is, and should hence be backported (as far as possible).
    
    Reported-by: Glen <glenbarney@gmail.com>
    Reported-by: Tomas Mozes <hydrapolic@gmail.com>
    Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
    Reviewed-by: George Dunlap <george.dunlap@citrix.com>
    master commit: 36f3662f27dec32d76c0edb4c6b62b9628d6869d
    master date: 2020-04-03 10:45:43 +0200

commit 9a082e14c66947f0acc4ca05d563b76a50571638
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Apr 9 09:35:24 2020 +0200

    x86/ucode/amd: Fix more potential buffer overruns with microcode parsing
    
    cpu_request_microcode() doesn't know the buffer is at least 4 bytes long
    before inspecting UCODE_MAGIC.
    
    install_equiv_cpu_table() doesn't know the boundary of the buffer it is
    interpreting as an equivalency table.  This case was clearly observed at one
    point in the past, given the subsequent overrun detection, but without
    comprehending that the damage was already done.
    
    Make the logic consistent with container_fast_forward() and pass size_left in
    to install_equiv_cpu_table().
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    master commit: 718d1432000079ea7120f6cb770372afe707ce27
    master date: 2020-04-01 14:00:12 +0100

commit e282e87f151adab1b269cafc404e0f554d896a45
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Apr 9 09:34:19 2020 +0200

    x86/HVM: fix AMD ECS handling for Fam10
    
    The involved comparison was, very likely inadvertently, converted from
    >= to > when making changes unrelated to the actual family range.
    
    Fixes: 9841eb71ea87 ("x86/cpuid: Drop a guests cached x86 family and model information")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    master commit: 5d515b1c296ebad6889748ea1e49e063453216a3
    master date: 2020-04-01 12:28:30 +0200

commit f3264407d0feadd948359242ac346567d8afa23a
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Apr 9 09:33:20 2020 +0200

    x86/ucode/amd: Fix potential buffer overrun with equiv table handling
    
    find_equiv_cpu_id() loops until it finds a 0 installed_cpu entry.  Well formed
    AMD microcode containers have this property.
    
    Extend the checking in install_equiv_cpu_table() to reject tables which don't
    have a sentinal at the end.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    master commit: 1f97b6b9f1b5978659c5735954c37c130e7bb151
    master date: 2020-03-27 13:13:26 +0000

commit 736c67bc46a333b24a9b0ffc902768ab96505ad6
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Apr 9 09:32:36 2020 +0200

    libx86/CPUID: fix (not just) leaf 7 processing
    
    x86_cpuid_policy_fill_native() should, as it did originally, iterate
    over all subleaves here as well as over all main leaves. Switch to
    using a "<= MIN()"-based approach similar to that used in
    x86_cpuid_copy_to_buffer(). Also follow this for the extended main
    leaves then.
    
    Fixes: 1bd2b750537b ("libx86: Fix 32bit stubdom build of x86_cpuid_policy_fill_native()")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: eb0bad81fceb3e81df5f73441771b49b732edf56
    master date: 2020-03-27 11:40:59 +0100

commit 94f0bb7c3ff63b7322849cd80ed0d6c2b9998ee4
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Apr 9 09:31:45 2020 +0200

    x86/ucode: Fix error paths in apply_microcode()
    
    In the unlikley case that patch application completes, but the resutling
    revision isn't expected, sig->rev doesn't get updated to match reality.
    
    It will get adjusted the next time collect_cpu_info() gets called, but in the
    meantime Xen might operate on a stale value.  Nothing good will come of this.
    
    Rewrite the logic to always update the stashed revision, before worrying about
    whether the attempt was a success or failure.
    
    Take the opportunity to make the printk() messages as consistent as possible.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    master commit: d2a0a96cf76603b2e2b87c3ce80c3f9d098327d4
    master date: 2020-03-26 18:57:45 +0000

commit 4c187457d1890067350c1770b84b75cea1d97214
Author: Igor Druzhinin <igor.druzhinin@citrix.com>
Date:   Thu Apr 9 09:30:58 2020 +0200

    x86/shim: fix ballooning up the guest
    
    args.preempted is meaningless here as it doesn't signal whether the
    hypercall was preempted before. Use start_extent instead which is
    correct (as long as the hypercall was invoked in a "normal" way).
    
    Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
    master commit: 76dbabb59eeaa78e9f57407e5b15a6606488333e
    master date: 2020-03-18 12:55:54 +0100

commit 3c37292c844a23beffc802192600386e2ea6888c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Apr 9 09:30:14 2020 +0200

    x86/vPMU: don't blindly assume IA32_PERF_CAPABILITIES MSR exists
    
    Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
    be consulted first.
    
    Reported-by: Farrah Chen <farrah.chen@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 15c39c7c913f26fba40231e103ce1ffa6101e7c9
    master date: 2020-02-26 17:35:48 +0100

commit 813757cf12eab38f3f86fc76a59d9e11749b4b27
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Apr 9 09:29:00 2020 +0200

    AMD/IOMMU: fix off-by-one in amd_iommu_get_paging_mode() callers
    
    amd_iommu_get_paging_mode() expects a count, not a "maximum possible"
    value. Prior to b4f042236ae0 dropping the reference, the use of our mis-
    named "max_page" in amd_iommu_domain_init() may have lead to such a
    misunderstanding. In an attempt to avoid such confusion in the future,
    rename the function's parameter and - while at it - convert it to an
    inline function.
    
    Also replace a literal 4 by an expression tying it to a wider use
    constant, just like amd_iommu_quarantine_init() does.
    
    Fixes: ea38867831da ("x86 / iommu: set up a scratch page in the quarantine domain")
    Fixes: b4f042236ae0 ("AMD/IOMMU: Cease using a dynamic height for the IOMMU pagetables")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: b75b3c62fe4afe381c6f74a07f614c0b39fe2f5d
    master date: 2020-03-16 11:24:29 +0100
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 20:49:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 20:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMe6P-0004Bo-Is; Thu, 09 Apr 2020 20:48:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FLbM=5Z=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jMe6O-0004Bj-HV
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 20:48:44 +0000
X-Inumbo-ID: 7fc72e3a-7aa3-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7fc72e3a-7aa3-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 20:48:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586465323;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=Rjn5z8tWEI99ZKW9mjsqO/GepQite5MHo/l5hfVY1Fs=;
 b=fQdHRPTsRNlU+6vRy+p/qZO2izJNcm+U+x40CDsgyHLD+tz9lx/hH49R
 HVjyWnXwOp7k3r2+60Phr6Cs/lM9ZoDXpON2EGrj7YwaDNgetHZ1GMizB
 phI44y5hKDGHlnFCnOyp9QMpjYybg4Cbmx7S4EF+3SWphPsPMbQbPF7PQ I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: b+SjthSYtJLMM4n2lAsuXONT/NfCpd7Z+uKq7sV2uVHwrI+kph2WgSBq/un3YY4uTh9IGYpRxE
 wusKBy1vsZa7a0n+CwyNjGLBjNlOxqc7BLVtzrBiv8ScB/MX1q3QKLFDhM6SvymFuOgHVOKR0w
 EXmJhL+EW692/sWxt44j9ETH5rudUfNb1wOYZYK37/kKoc4B6Tj018uOGXD/Wf17tip/JsM9Vj
 3SdgUJO/ZTmuAlRb82j+nSNvweSARYzFQ9LOfUyDcrbAZlMn3pnWRxpS4SL8FZwPUlLc43cpqZ
 3oA=
X-SBRS: 2.7
X-MesageID: 16135641
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,364,1580792400"; d="scan'208";a="16135641"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/mem_sharing: Fix build folloing VM Fork work
Date: Thu, 9 Apr 2020 21:48:37 +0100
Message-ID: <20200409204837.7017-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Tamas K Lengyel <tamas@tklengyel.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

A default build fails with:

  mem_sharing.c: In function ‘copy_special_pages’:
  mem_sharing.c:1649:9: error: ‘HVM_PARAM_STORE_PFN’ undeclared (first use in this function)
           HVM_PARAM_STORE_PFN,
           ^~~~~~~~~~~~~~~~~~~

I suspect this is a rebasing issue with respect to c/s 12f0c69f2709 "x86/HVM:
reduce hvm.h include dependencies".

Fixes: 41548c5472a "mem_sharing: VM forking"
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Tamas K Lengyel <tamas@tklengyel.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/mm/mem_sharing.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 85951b7bea..e572e9e39d 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -41,6 +41,8 @@
 #include <asm/hvm/hvm.h>
 #include <xsm/xsm.h>
 
+#include <public/hvm/params.h>
+
 #include "mm-locks.h"
 
 static shr_handle_t next_handle = 1;
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 09 21:25:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 21:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMefP-0007OW-FV; Thu, 09 Apr 2020 21:24:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JlmV=5Z=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jMefO-0007OR-Fi
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 21:24:54 +0000
X-Inumbo-ID: 8d5d8044-7aa8-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8d5d8044-7aa8-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 21:24:53 +0000 (UTC)
Received: by mail-ed1-x542.google.com with SMTP id dk4so1757008edb.13
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 14:24:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=GImh+BuHdjMuc/1Sw1GaPIx1uPXReGwki6MVmkPisT8=;
 b=W4ueCqGgyRYyHsR4+Yx3BoeUY0sZs7aLj29f3jSy252G/8bw7jnL7Jfz49w/C3ERv+
 aCnheSk+7Me7wprsBLvwy7IUPccS5J8emuYoKFIP/boFEFHD3qiDWYC8rFWTE9Lb+Toc
 D/Q8EQ7Zl6tjX9suHYfdahUkW5rMtN1X0/KWak1IvO0zcZFt6spLEHzhB4/9sylW1omj
 l0SjWhxe5n/dbBlV1Fr4IE3hO5roGlbjJ2s/RaM/Rp6c/9FDDWN9nFDojqeCtnlUkBQ2
 cWgsoqRuVVqfBxPxGubzCVLMgt/Eam36Tjde0HRtx3myh+7X7+g6m+d5ISi9/iCUlFGU
 LzCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=GImh+BuHdjMuc/1Sw1GaPIx1uPXReGwki6MVmkPisT8=;
 b=g1wvxXD5dtoLWDYR8RQNha1+YsejC0m5AlqioF3f3c7bDK9rxS0YylfKBVewT29GGH
 INwO5gSXLIg9SvqIZiRLbUpXUAW+1lcYtSDUeGK1qDhT21SpRnYzxGt4xxTz3YDMpip0
 ca2xPcq+y+kBiQek8zZc/3N2+AzgvmDgmdSTbsL9vgqd8/VwA5w39OsYp3l4Z5vTb9ju
 B5ZELSVcDhtcH0kPKVvzrmC2jSO/I7s7CpMR/xYzdYgVN+BOQ7tbb6q4AjBifV1qXYIE
 +wHJuKN8rGIIo4a5pnrr7cE8/RN9xE+0vHtDxq1O9Txg0wzx2C3dM1+TWJw1SVj7vRN/
 Ie0A==
X-Gm-Message-State: AGi0PubeboTSv57BXV/HIjiprSkoUISMO4PJ67gyhlzJGt9NCoqsZKSK
 SMDEZqaEkTtn1jLF6pfHzWpEjWw6Kg0=
X-Google-Smtp-Source: APiQypKF04Tmc0LjV/7uKCZGwkv00ozDdFiu1WOzP76yFH9NPkR9y4NRBMVefG7UGJA05X6YVxPQUg==
X-Received: by 2002:a17:906:3509:: with SMTP id r9mr1033450eja.5.1586467492565; 
 Thu, 09 Apr 2020 14:24:52 -0700 (PDT)
Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com.
 [209.85.221.49])
 by smtp.gmail.com with ESMTPSA id e25sm3715623ejl.4.2020.04.09.14.24.52
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Apr 2020 14:24:52 -0700 (PDT)
Received: by mail-wr1-f49.google.com with SMTP id v5so13715122wrp.12
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 14:24:52 -0700 (PDT)
X-Received: by 2002:adf:ea06:: with SMTP id q6mr1191089wrm.301.1586467491693; 
 Thu, 09 Apr 2020 14:24:51 -0700 (PDT)
MIME-Version: 1.0
References: <20200409204837.7017-1-andrew.cooper3@citrix.com>
In-Reply-To: <20200409204837.7017-1-andrew.cooper3@citrix.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Thu, 9 Apr 2020 15:24:13 -0600
X-Gmail-Original-Message-ID: <CABfawhnhfTScVDRxezP3qRarBczCPs2EVmLZMnN-FMpxyWN8XQ@mail.gmail.com>
Message-ID: <CABfawhnhfTScVDRxezP3qRarBczCPs2EVmLZMnN-FMpxyWN8XQ@mail.gmail.com>
Subject: Re: [PATCH] x86/mem_sharing: Fix build folloing VM Fork work
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper <andrew.cooper3@citrix.com> wr=
ote:
>
> A default build fails with:
>
>   mem_sharing.c: In function =E2=80=98copy_special_pages=E2=80=99:
>   mem_sharing.c:1649:9: error: =E2=80=98HVM_PARAM_STORE_PFN=E2=80=99 unde=
clared (first use in this function)
>            HVM_PARAM_STORE_PFN,
>            ^~~~~~~~~~~~~~~~~~~
>
> I suspect this is a rebasing issue with respect to c/s 12f0c69f2709 "x86/=
HVM:
> reduce hvm.h include dependencies".
>
> Fixes: 41548c5472a "mem_sharing: VM forking"
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

So staging definitely compiles for me both with and without
CONFIG_MEM_SHARING enabled. By default its off, so this shouldn't even
be compiled so I'm curious what's happening in your build. That said,
I have no objection to the extra include if it turns out to be
actually necessary.

Tamas


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 22:05:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 22:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMfIG-0002EZ-J4; Thu, 09 Apr 2020 22:05:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FLbM=5Z=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jMfIG-0002EU-5y
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 22:05:04 +0000
X-Inumbo-ID: 292ed0cc-7aae-11ea-b4f4-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 292ed0cc-7aae-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 22:05:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586469903;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to;
 bh=OVRLhuWnX6yyR2IYlyeCHNC0ARBS8rk78i+ijDJxFzg=;
 b=gvHmEhZ0Lz3s6e86zIkO5auDrIVZOelSjvOWM5wwGnOWzWEQ6TcpwxuS
 Fy96OqrPN2Y9MqJdSCFFc1HLZEHc/Jlm4hcDlErVhD/UVpx5IPK2O+sQH
 gQ+cCHkOb6SAbPXAwZmB9RfqBWLkBS+OAQATvFEcsusdCKfzPJ/323PSw w=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: kCzUH5RuVsu0N8AQyIcbQ2/XNvdqRWdobxa3kkiEutI/XAOJcd5xkAp+sHYS2WGD9OgoXyEcAj
 p92Xsw9rBzsxETO/TINM1pnwtayppOXEAhBbzARkTKR0eomGgWcubm84S6Y+RaQd3C9enjVlGV
 Bju3OebTj9u2OoIXNTQNrmQE6O6HxG9w55b2Bir1/rar6xr/bqBUbCOy9tOEMuTj/Bf/GGYg8B
 68WhDNmdZj2tkzEal7UuRt1wUdHoMXWyhHtFEKNap9QYnldsF5xoCMb3Y+HjW0wPC4Cf+M80qg
 MR0=
X-SBRS: 2.7
X-MesageID: 15703688
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,364,1580792400"; d="scan'208";a="15703688"
Subject: Re: [PATCH] x86/mem_sharing: Fix build folloing VM Fork work
To: Tamas K Lengyel <tamas@tklengyel.com>
References: <20200409204837.7017-1-andrew.cooper3@citrix.com>
 <CABfawhnhfTScVDRxezP3qRarBczCPs2EVmLZMnN-FMpxyWN8XQ@mail.gmail.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <769887ee-c381-ff58-bdf9-bd1a3032cbfb@citrix.com>
Date: Thu, 9 Apr 2020 23:04:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CABfawhnhfTScVDRxezP3qRarBczCPs2EVmLZMnN-FMpxyWN8XQ@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------0C9AF3EAE1EEA1FAF626E9EB"
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--------------0C9AF3EAE1EEA1FAF626E9EB
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On 09/04/2020 22:24, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> A default build fails with:
>>
>>   mem_sharing.c: In function ‘copy_special_pages’:
>>   mem_sharing.c:1649:9: error: ‘HVM_PARAM_STORE_PFN’ undeclared (first use in this function)
>>            HVM_PARAM_STORE_PFN,
>>            ^~~~~~~~~~~~~~~~~~~
>>
>> I suspect this is a rebasing issue with respect to c/s 12f0c69f2709 "x86/HVM:
>> reduce hvm.h include dependencies".
>>
>> Fixes: 41548c5472a "mem_sharing: VM forking"
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> So staging definitely compiles for me both with and without
> CONFIG_MEM_SHARING enabled. By default its off, so this shouldn't even
> be compiled so I'm curious what's happening in your build. That said,
> I have no objection to the extra include if it turns out to be
> actually necessary.

Exact config attached.  I've just double checked that staging fails.

We should get  to the bottom of exactly what is going on here, if it
isn't the obvious thing.

~Andrew

--------------0C9AF3EAE1EEA1FAF626E9EB
Content-Type: text/plain; charset="UTF-8"; name=".config-debug"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=".config-debug"

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIFhlbi94
ODYgNC4xNC11bnN0YWJsZSBDb25maWd1cmF0aW9uCiMKQ09ORklHX0NDX0lTX0dDQz15CkNP
TkZJR19HQ0NfVkVSU0lPTj02MDMwMApDT05GSUdfQ0xBTkdfVkVSU0lPTj0wCkNPTkZJR19D
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEU9eQpDT05GSUdfWDg2XzY0PXkKQ09ORklHX1g4
Nj15CkNPTkZJR19BUkNIX0RFRkNPTkZJRz0iYXJjaC94ODYvY29uZmlncy94ODZfNjRfZGVm
Y29uZmlnIgpDT05GSUdfSU5ESVJFQ1RfVEhVTks9eQoKIwojIEFyY2hpdGVjdHVyZSBGZWF0
dXJlcwojCkNPTkZJR19OUl9DUFVTPTI1NgpDT05GSUdfUFY9eQpDT05GSUdfUFZfTElORUFS
X1BUPXkKQ09ORklHX0hWTT15CkNPTkZJR19TSEFET1dfUEFHSU5HPXkKIyBDT05GSUdfQklH
TUVNIGlzIG5vdCBzZXQKQ09ORklHX0hWTV9GRVA9eQpDT05GSUdfVEJPT1Q9eQojIENPTkZJ
R19YRU5fQUxJR05fREVGQVVMVCBpcyBub3Qgc2V0CkNPTkZJR19YRU5fQUxJR05fMk09eQpD
T05GSUdfR1VFU1Q9eQpDT05GSUdfWEVOX0dVRVNUPXkKQ09ORklHX1BWSF9HVUVTVD15CkNP
TkZJR19QVl9TSElNPXkKIyBDT05GSUdfUFZfU0hJTV9FWENMVVNJVkUgaXMgbm90IHNldApD
T05GSUdfSFlQRVJWX0dVRVNUPXkKQ09ORklHX01FTV9TSEFSSU5HPXkKIyBlbmQgb2YgQXJj
aGl0ZWN0dXJlIEZlYXR1cmVzCgojCiMgQ29tbW9uIEZlYXR1cmVzCiMKQ09ORklHX0NPTVBB
VD15CkNPTkZJR19DT1JFX1BBUktJTkc9eQpDT05GSUdfR1JBTlRfVEFCTEU9eQpDT05GSUdf
SEFTX0FMVEVSTkFUSVZFPXkKQ09ORklHX0hBU19FWF9UQUJMRT15CkNPTkZJR19IQVNfRkFT
VF9NVUxUSVBMWT15CkNPTkZJR19NRU1fQUNDRVNTX0FMV0FZU19PTj15CkNPTkZJR19NRU1f
QUNDRVNTPXkKQ09ORklHX0hBU19NRU1fUEFHSU5HPXkKQ09ORklHX0hBU19QRFg9eQpDT05G
SUdfSEFTX1VCU0FOPXkKQ09ORklHX0hBU19LRVhFQz15CkNPTkZJR19IQVNfSU9QT1JUUz15
CkNPTkZJR19IQVNfU0NIRURfR1JBTlVMQVJJVFk9eQpDT05GSUdfTkVFRFNfTElCRUxGPXkK
CiMKIyBTcGVjdWxhdGl2ZSBoYXJkZW5pbmcKIwpDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVO
X0FSUkFZPXkKQ09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9CUkFOQ0g9eQojIGVuZCBvZiBT
cGVjdWxhdGl2ZSBoYXJkZW5pbmcKCkNPTkZJR19LRVhFQz15CiMgQ09ORklHX0VGSV9TRVRf
VklSVFVBTF9BRERSRVNTX01BUCBpcyBub3Qgc2V0CkNPTkZJR19YRU5PUFJPRj15CkNPTkZJ
R19YU009eQpDT05GSUdfWFNNX0ZMQVNLPXkKQ09ORklHX1hTTV9GTEFTS19BVkNfU1RBVFM9
eQpDT05GSUdfWFNNX0ZMQVNLX1BPTElDWT15CkNPTkZJR19YU01fU0lMTz15CiMgQ09ORklH
X1hTTV9EVU1NWV9ERUZBVUxUIGlzIG5vdCBzZXQKIyBDT05GSUdfWFNNX0ZMQVNLX0RFRkFV
TFQgaXMgbm90IHNldApDT05GSUdfWFNNX1NJTE9fREVGQVVMVD15CiMgQ09ORklHX0xBVEVf
SFdET00gaXMgbm90IHNldApDT05GSUdfQVJHTz15CgojCiMgU2NoZWR1bGVycwojCkNPTkZJ
R19TQ0hFRF9DUkVESVQ9eQpDT05GSUdfU0NIRURfQ1JFRElUMj15CkNPTkZJR19TQ0hFRF9S
VERTPXkKQ09ORklHX1NDSEVEX0FSSU5DNjUzPXkKQ09ORklHX1NDSEVEX05VTEw9eQpDT05G
SUdfU0NIRURfQ1JFRElUX0RFRkFVTFQ9eQojIENPTkZJR19TQ0hFRF9DUkVESVQyX0RFRkFV
TFQgaXMgbm90IHNldAojIENPTkZJR19TQ0hFRF9SVERTX0RFRkFVTFQgaXMgbm90IHNldAoj
IENPTkZJR19TQ0hFRF9BUklOQzY1M19ERUZBVUxUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NI
RURfTlVMTF9ERUZBVUxUIGlzIG5vdCBzZXQKQ09ORklHX1NDSEVEX0RFRkFVTFQ9ImNyZWRp
dCIKIyBlbmQgb2YgU2NoZWR1bGVycwoKQ09ORklHX0NSWVBUTz15CkNPTkZJR19MSVZFUEFU
Q0g9eQpDT05GSUdfRkFTVF9TWU1CT0xfTE9PS1VQPXkKQ09ORklHX0VORk9SQ0VfVU5JUVVF
X1NZTUJPTFM9eQpDT05GSUdfQ01ETElORT0iIgpDT05GSUdfRE9NMF9NRU09IiIKQ09ORklH
X1RSQUNFQlVGRkVSPXkKIyBlbmQgb2YgQ29tbW9uIEZlYXR1cmVzCgojCiMgRGV2aWNlIERy
aXZlcnMKIwpDT05GSUdfQUNQST15CkNPTkZJR19BQ1BJX0xFR0FDWV9UQUJMRVNfTE9PS1VQ
PXkKQ09ORklHX05VTUE9eQpDT05GSUdfSEFTX05TMTY1NTA9eQpDT05GSUdfSEFTX0VIQ0k9
eQpDT05GSUdfSEFTX0NQVUZSRVE9eQpDT05GSUdfSEFTX1BBU1NUSFJPVUdIPXkKQ09ORklH
X0hBU19QQ0k9eQpDT05GSUdfVklERU89eQpDT05GSUdfVkdBPXkKQ09ORklHX0hBU19WUENJ
PXkKIyBlbmQgb2YgRGV2aWNlIERyaXZlcnMKCiMKIyBEZXByZWNhdGVkIEZ1bmN0aW9uYWxp
dHkKIwojIENPTkZJR19QVl9MRFRfUEFHSU5HIGlzIG5vdCBzZXQKIyBlbmQgb2YgRGVwcmVj
YXRlZCBGdW5jdGlvbmFsaXR5CgpDT05GSUdfRVhQRVJUPSJ5IgpDT05GSUdfQVJDSF9TVVBQ
T1JUU19JTlQxMjg9eQoKIwojIERlYnVnZ2luZyBPcHRpb25zCiMKQ09ORklHX0RFQlVHPXkK
IyBDT05GSUdfQ1JBU0hfREVCVUcgaXMgbm90IHNldApDT05GSUdfR0RCU1g9eQpDT05GSUdf
REVCVUdfSU5GTz15CkNPTkZJR19GUkFNRV9QT0lOVEVSPXkKIyBDT05GSUdfREVCVUdfTE9D
S19QUk9GSUxFIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX0xPQ0tTPXkKIyBDT05GSUdfUEVS
Rl9DT1VOVEVSUyBpcyBub3Qgc2V0CkNPTkZJR19WRVJCT1NFX0RFQlVHPXkKQ09ORklHX1ND
UlVCX0RFQlVHPXkKIyBDT05GSUdfVUJTQU4gaXMgbm90IHNldAojIENPTkZJR19ERUJVR19U
UkFDRSBpcyBub3Qgc2V0CkNPTkZJR19YTUVNX1BPT0xfUE9JU09OPXkKIyBlbmQgb2YgRGVi
dWdnaW5nIE9wdGlvbnMK
--------------0C9AF3EAE1EEA1FAF626E9EB--


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 22:39:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 22:39:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMfpA-0004in-4P; Thu, 09 Apr 2020 22:39:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JlmV=5Z=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jMfp9-0004ii-94
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 22:39:03 +0000
X-Inumbo-ID: e9188686-7ab2-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e9188686-7ab2-11ea-b58d-bc764e2007e4;
 Thu, 09 Apr 2020 22:39:02 +0000 (UTC)
Received: by mail-ed1-x544.google.com with SMTP id z65so274551ede.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 15:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=60WcPQqUKk5AonSBYJ/LZClYE6Z1dNBYiPXvDTlvKqw=;
 b=UoRYI0Tf18hLHyQMKeWgULSqdr/G1PruNHXO5x1BNo6x/yv8KDg19NWgE1XjcjprWY
 TU3jnmX2TbdgPNwHqk50qRwTxMgav6e7zHjUctshzzqaUGuALqTa1BrQDTAaHjfU3er6
 OFmYGLsGTpiNu+KKeDRqzxZvYbdXpdjAuZ9VfKb43psUoXOm0zic9glLrjMwyw25DVjf
 GTNASi7CJ0NM/+u5VRuEmkD6J4rZrpoFxjrduob4kD5aK1J25Aou1ehFTBufPyqFhXcf
 1mJ2SW3Re856svOHGFZeQmSltDuBmoQXu0JVOD5F8wVdMisnd0YZe8m8Xtv8saHYiLyr
 En1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=60WcPQqUKk5AonSBYJ/LZClYE6Z1dNBYiPXvDTlvKqw=;
 b=GvsykP6u9Wv9hfdOAeOYUx3K2vV/UlSQsZBhSi7Wz8NNE6SaXXh/CHpndBJwSjbpKN
 XMC0RZvLDB3Ore+VBxm867qTSqSXPf+RVpYRB6SHG3LlL3bFwUl3HFz91cc0JzDYmWiG
 fGXw1aVjFphmBcCkTcccjizWw/JH2VyTwcwfwt2Hm9+y9FndPyCibe5qypPRR7bipWS4
 e/O2AUH01SL8wPgC25ynvuGaOW1/wAvRVbcRm8FYAVChmpPg9aCh6c+Mf35xr9fsA5l1
 33I1W4+Ognbw8oXS1VfWT/Mhe1bUCPrpupSQN1UhpiDUIVmm6LDJdbS7Hno1reDpeplS
 IfNg==
X-Gm-Message-State: AGi0PuamBQcbHAaPbw47aTD5R5JgbLyKfgU+xUZbmUFAdU9RSE/aWjFG
 2nw1cJqEsa7ZNOkxA7F6ECKF623TYxA=
X-Google-Smtp-Source: APiQypKzdvfnikVVLuCRZPSVRxYwd0oTG7ud8TEHpOdm+rdwg2ZkWvTIijt6KC91oOnqLifJXCKGRw==
X-Received: by 2002:aa7:d513:: with SMTP id y19mr2287973edq.362.1586471941627; 
 Thu, 09 Apr 2020 15:39:01 -0700 (PDT)
Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com.
 [209.85.221.45])
 by smtp.gmail.com with ESMTPSA id ga1sm2561ejb.65.2020.04.09.15.39.00
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Apr 2020 15:39:00 -0700 (PDT)
Received: by mail-wr1-f45.google.com with SMTP id f13so48399wrm.13
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 15:39:00 -0700 (PDT)
X-Received: by 2002:adf:f98b:: with SMTP id f11mr1332170wrr.259.1586471940001; 
 Thu, 09 Apr 2020 15:39:00 -0700 (PDT)
MIME-Version: 1.0
References: <20200409204837.7017-1-andrew.cooper3@citrix.com>
 <CABfawhnhfTScVDRxezP3qRarBczCPs2EVmLZMnN-FMpxyWN8XQ@mail.gmail.com>
 <769887ee-c381-ff58-bdf9-bd1a3032cbfb@citrix.com>
In-Reply-To: <769887ee-c381-ff58-bdf9-bd1a3032cbfb@citrix.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Thu, 9 Apr 2020 16:38:24 -0600
X-Gmail-Original-Message-ID: <CABfawh=UPcyHRgNvsA8wNwV798e3RL_FhSF6ZrOrx89up4w+fQ@mail.gmail.com>
Message-ID: <CABfawh=UPcyHRgNvsA8wNwV798e3RL_FhSF6ZrOrx89up4w+fQ@mail.gmail.com>
Subject: Re: [PATCH] x86/mem_sharing: Fix build folloing VM Fork work
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper <andrew.cooper3@citrix.com> wr=
ote:
>
> On 09/04/2020 22:24, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper <andrew.cooper3@citrix.com=
> wrote:
> >> A default build fails with:
> >>
> >>   mem_sharing.c: In function =E2=80=98copy_special_pages=E2=80=99:
> >>   mem_sharing.c:1649:9: error: =E2=80=98HVM_PARAM_STORE_PFN=E2=80=99 u=
ndeclared (first use in this function)
> >>            HVM_PARAM_STORE_PFN,
> >>            ^~~~~~~~~~~~~~~~~~~
> >>
> >> I suspect this is a rebasing issue with respect to c/s 12f0c69f2709 "x=
86/HVM:
> >> reduce hvm.h include dependencies".
> >>
> >> Fixes: 41548c5472a "mem_sharing: VM forking"
> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > So staging definitely compiles for me both with and without
> > CONFIG_MEM_SHARING enabled. By default its off, so this shouldn't even
> > be compiled so I'm curious what's happening in your build. That said,
> > I have no objection to the extra include if it turns out to be
> > actually necessary.
>
> Exact config attached.  I've just double checked that staging fails.
>
> We should get  to the bottom of exactly what is going on here, if it
> isn't the obvious thing.

Strange, with your config it does produce the error. With "echo
CONFIG_MEM_SHARING=3Dy > .config && XEN_CONFIG_EXPERT=3Dy make
olddefconfig && make" it does compile.

Tamas


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 23:00:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 23:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMg9t-00075x-0e; Thu, 09 Apr 2020 23:00:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FLbM=5Z=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jMg9r-00075s-4q
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 23:00:27 +0000
X-Inumbo-ID: e56f69a2-7ab5-11ea-8382-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e56f69a2-7ab5-11ea-8382-12813bfff9fa;
 Thu, 09 Apr 2020 23:00:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586473225;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=qsCljqHfqOYQgRx/j72JrDk5S6xLjMHFrL7UGwyVWMo=;
 b=YEglQ+ZdL4JkrTxk8GLnhvAOh0DAAQyhVYdVjmI3y6LAvyFfa12ZOCQC
 wj8+YmVpli8M/NQegBXT3QmEjB6QdgLEstcIoEotb1+sn4x2axe8YfxPq
 weQIXch9fhaJRkfK+vaFXSoWRQaBnt7g7+eWgs55H2kP+QL/HRyM04vCY o=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 0CXPQm+I7qF7PS4eJWI68nPRcDi6fBvRIJzi0NrVkN7fsA2KdtP+Nw3lS1OgyH7GgmZ60rYk75
 Y9PQp/JHemWZ0VExuFJn1EaHyxbY+raEExC1asct4XLfJFpasjXMBF3BpivLXfva0NQhDSZifx
 lsjQ2jEHa0tr9pjV3k1fYkmSR8jrhClbSeIG9jExV+J+rp+rzyui0EDM3/8yfu+c886mRkCCcL
 rzZcz66kk0sQvYuX7NcZuKZzMD1uPrc91uLCoGR5Xk7Be/mAIB+1cGMfZxBS9LFxEZeclQdwas
 F6c=
X-SBRS: 2.7
X-MesageID: 15876183
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,364,1580792400"; d="scan'208";a="15876183"
Subject: Re: [PATCH] x86/mem_sharing: Fix build folloing VM Fork work
To: Tamas K Lengyel <tamas@tklengyel.com>
References: <20200409204837.7017-1-andrew.cooper3@citrix.com>
 <CABfawhnhfTScVDRxezP3qRarBczCPs2EVmLZMnN-FMpxyWN8XQ@mail.gmail.com>
 <769887ee-c381-ff58-bdf9-bd1a3032cbfb@citrix.com>
 <CABfawh=UPcyHRgNvsA8wNwV798e3RL_FhSF6ZrOrx89up4w+fQ@mail.gmail.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <a89b2a51-8c54-4a35-4f77-e31018936534@citrix.com>
Date: Fri, 10 Apr 2020 00:00:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CABfawh=UPcyHRgNvsA8wNwV798e3RL_FhSF6ZrOrx89up4w+fQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09/04/2020 23:38, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 09/04/2020 22:24, Tamas K Lengyel wrote:
>>> On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> A default build fails with:
>>>>
>>>>   mem_sharing.c: In function ‘copy_special_pages’:
>>>>   mem_sharing.c:1649:9: error: ‘HVM_PARAM_STORE_PFN’ undeclared (first use in this function)
>>>>            HVM_PARAM_STORE_PFN,
>>>>            ^~~~~~~~~~~~~~~~~~~
>>>>
>>>> I suspect this is a rebasing issue with respect to c/s 12f0c69f2709 "x86/HVM:
>>>> reduce hvm.h include dependencies".
>>>>
>>>> Fixes: 41548c5472a "mem_sharing: VM forking"
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> So staging definitely compiles for me both with and without
>>> CONFIG_MEM_SHARING enabled. By default its off, so this shouldn't even
>>> be compiled so I'm curious what's happening in your build. That said,
>>> I have no objection to the extra include if it turns out to be
>>> actually necessary.
>> Exact config attached.  I've just double checked that staging fails.
>>
>> We should get  to the bottom of exactly what is going on here, if it
>> isn't the obvious thing.
> Strange, with your config it does produce the error. With "echo
> CONFIG_MEM_SHARING=y > .config && XEN_CONFIG_EXPERT=y make
> olddefconfig && make" it does compile.

You lose XEN_CONFIG_EXPERT=y in the second make, so it rewrites your
.config behind your back.  (This behaviour is totally obnoxious).

Diff the current config against original?

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 09 23:24:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Apr 2020 23:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMgX2-0000P7-FV; Thu, 09 Apr 2020 23:24:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JlmV=5Z=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jMgX1-0000P1-31
 for xen-devel@lists.xenproject.org; Thu, 09 Apr 2020 23:24:23 +0000
X-Inumbo-ID: 3e0556b4-7ab9-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x543.google.com (unknown [2a00:1450:4864:20::543])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3e0556b4-7ab9-11ea-b4f4-bc764e2007e4;
 Thu, 09 Apr 2020 23:24:22 +0000 (UTC)
Received: by mail-ed1-x543.google.com with SMTP id e5so343718edq.5
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 16:24:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=QycfvTbWwW+iyuTJiBcOd+/nNNukvsofmFoMp8DmCFM=;
 b=Otuws/WKNqIWqTFbH9wqGyasiqtmVSMuqr/6RD3+k8lLRDztA1BIpCnoIvmuSHsOZi
 eNyx3BXC40686Na69d/xb7Z7kHnbhhf8eBOcHl1ytJvpx5huvbYaLOhDWLKx+lH6pWrB
 gaNVEA1w+JQUJF5gX++1PkUVrxAQZEmNr04ILjeFsU9jLYSmx/os9uEK0H0b6M0XHtSM
 uxECtJzuAh+Aeb6jSFcMnbah2iNbGZWn1wzTCQg8cT47RlfXdZpEGnX5TZHV6yxyNePc
 lJemlMvZmtO82eb/OayBnSiOPyE+4VXqZa41mrEpaHPlSI0TQeXAGRLuiVylsjp5Mm1A
 5dzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=QycfvTbWwW+iyuTJiBcOd+/nNNukvsofmFoMp8DmCFM=;
 b=ZNx/Mu1b+lZlcJHUxI5FJfSDP4RFAWJioD+CGMx184npqNUS+195VTAShVt4yZKKiF
 O0wecPa0ROJHXX4NkJmtxcb12zUXJu9UfU8u+BiYoTGhOaH4d2Jr8YxMy8dK2C0myVxV
 oZV/FHWfklsVhJ1gRi0H6PzM8puawnYhKP2Mh4hDE/eTRZuOLpTP73Ad88zVphIbI8EZ
 ELPX7wS0nFv4Zz4+5nU+f6u3PqJl9WsdM19nBXr4RQh292uxzYXk4ZeRc3gX6xNtJP6o
 zSKgYmThBbA9M7C9KKekEFjFJNLm5B832g5tXbJvyRKFFN6VoaIlHTKGhj4mNYLb0JF5
 qEUw==
X-Gm-Message-State: AGi0PubojACfGe1RHGFyPVgdmjcDWVG+ZJhan0KaEx8LfxFU3uzCeCA6
 +UYfqWsSsaEo4nQ9s3xJAkJ2Z3ONdmg=
X-Google-Smtp-Source: APiQypJRCpBE2KvBpWQ2C/2YOtFadVR2u55caWtz9xhiPKB2RviaWQf2k7Tm6VBmQFfA1inaG+U8hw==
X-Received: by 2002:a17:906:d1c3:: with SMTP id
 bs3mr1348687ejb.334.1586474660560; 
 Thu, 09 Apr 2020 16:24:20 -0700 (PDT)
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com.
 [209.85.221.47])
 by smtp.gmail.com with ESMTPSA id n62sm26355edc.74.2020.04.09.16.24.19
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Apr 2020 16:24:20 -0700 (PDT)
Received: by mail-wr1-f47.google.com with SMTP id h9so239487wrc.8
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 16:24:19 -0700 (PDT)
X-Received: by 2002:adf:eac1:: with SMTP id o1mr1663352wrn.182.1586474659175; 
 Thu, 09 Apr 2020 16:24:19 -0700 (PDT)
MIME-Version: 1.0
References: <20200409204837.7017-1-andrew.cooper3@citrix.com>
 <CABfawhnhfTScVDRxezP3qRarBczCPs2EVmLZMnN-FMpxyWN8XQ@mail.gmail.com>
 <769887ee-c381-ff58-bdf9-bd1a3032cbfb@citrix.com>
 <CABfawh=UPcyHRgNvsA8wNwV798e3RL_FhSF6ZrOrx89up4w+fQ@mail.gmail.com>
 <a89b2a51-8c54-4a35-4f77-e31018936534@citrix.com>
In-Reply-To: <a89b2a51-8c54-4a35-4f77-e31018936534@citrix.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Thu, 9 Apr 2020 17:23:44 -0600
X-Gmail-Original-Message-ID: <CABfawhm4Tdcp7QWqOyUXb_7Ag9yuQ93E3knH6joG4TDyXbgufA@mail.gmail.com>
Message-ID: <CABfawhm4Tdcp7QWqOyUXb_7Ag9yuQ93E3knH6joG4TDyXbgufA@mail.gmail.com>
Subject: Re: [PATCH] x86/mem_sharing: Fix build folloing VM Fork work
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 9, 2020 at 5:00 PM Andrew Cooper <andrew.cooper3@citrix.com> wr=
ote:
>
> On 09/04/2020 23:38, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper <andrew.cooper3@citrix.com=
> wrote:
> >> On 09/04/2020 22:24, Tamas K Lengyel wrote:
> >>> On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper <andrew.cooper3@citrix.c=
om> wrote:
> >>>> A default build fails with:
> >>>>
> >>>>   mem_sharing.c: In function =E2=80=98copy_special_pages=E2=80=99:
> >>>>   mem_sharing.c:1649:9: error: =E2=80=98HVM_PARAM_STORE_PFN=E2=80=99=
 undeclared (first use in this function)
> >>>>            HVM_PARAM_STORE_PFN,
> >>>>            ^~~~~~~~~~~~~~~~~~~
> >>>>
> >>>> I suspect this is a rebasing issue with respect to c/s 12f0c69f2709 =
"x86/HVM:
> >>>> reduce hvm.h include dependencies".
> >>>>
> >>>> Fixes: 41548c5472a "mem_sharing: VM forking"
> >>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>> So staging definitely compiles for me both with and without
> >>> CONFIG_MEM_SHARING enabled. By default its off, so this shouldn't eve=
n
> >>> be compiled so I'm curious what's happening in your build. That said,
> >>> I have no objection to the extra include if it turns out to be
> >>> actually necessary.
> >> Exact config attached.  I've just double checked that staging fails.
> >>
> >> We should get  to the bottom of exactly what is going on here, if it
> >> isn't the obvious thing.
> > Strange, with your config it does produce the error. With "echo
> > CONFIG_MEM_SHARING=3Dy > .config && XEN_CONFIG_EXPERT=3Dy make
> > olddefconfig && make" it does compile.
>
> You lose XEN_CONFIG_EXPERT=3Dy in the second make, so it rewrites your
> .config behind your back.  (This behaviour is totally obnoxious).

I also compiled with export XEN_CONFIG_EXPERT=3Dy and it compiles fine.

> Diff the current config against original?

drt@t0:~/workspace/xen/xen$ diff .config .config-debug
6c6
< CONFIG_GCC_VERSION=3D80300
---
> CONFIG_GCC_VERSION=3D60300
25,28c25,32
< CONFIG_XEN_ALIGN_DEFAULT=3Dy
< # CONFIG_XEN_ALIGN_2M is not set
< # CONFIG_XEN_GUEST is not set
< # CONFIG_HYPERV_GUEST is not set
---
> # CONFIG_XEN_ALIGN_DEFAULT is not set
> CONFIG_XEN_ALIGN_2M=3Dy
> CONFIG_GUEST=3Dy
> CONFIG_XEN_GUEST=3Dy
> CONFIG_PVH_GUEST=3Dy
> CONFIG_PV_SHIM=3Dy
> # CONFIG_PV_SHIM_EXCLUSIVE is not set
> CONFIG_HYPERV_GUEST=3Dy
61,62c65,74
< # CONFIG_XSM is not set
< # CONFIG_ARGO is not set
---
> CONFIG_XSM=3Dy
> CONFIG_XSM_FLASK=3Dy
> CONFIG_XSM_FLASK_AVC_STATS=3Dy
> CONFIG_XSM_FLASK_POLICY=3Dy
> CONFIG_XSM_SILO=3Dy
> # CONFIG_XSM_DUMMY_DEFAULT is not set
> # CONFIG_XSM_FLASK_DEFAULT is not set
> CONFIG_XSM_SILO_DEFAULT=3Dy
> # CONFIG_LATE_HWDOM is not set
> CONFIG_ARGO=3Dy
72,73c84,85
< # CONFIG_SCHED_CREDIT_DEFAULT is not set
< CONFIG_SCHED_CREDIT2_DEFAULT=3Dy
---
> CONFIG_SCHED_CREDIT_DEFAULT=3Dy
> # CONFIG_SCHED_CREDIT2_DEFAULT is not set
77c89
< CONFIG_SCHED_DEFAULT=3D"credit2"
---
> CONFIG_SCHED_DEFAULT=3D"credit"

Tamas


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 00:58:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 00:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMi0C-0008Q6-Cr; Fri, 10 Apr 2020 00:58:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=5/QT=52=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jMi0A-0008Q1-Qk
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 00:58:34 +0000
X-Inumbo-ID: 66a871b6-7ac6-11ea-83d8-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 66a871b6-7ac6-11ea-83d8-bc764e2007e4;
 Fri, 10 Apr 2020 00:58:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586480312;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=wGth6PMI1MAXOrsQjOxcdiLOjZYHKsUhNzPRHjBy9fU=;
 b=HV9enyLyMIkkX0opvnl2nKfWLJ3OJnc76RwnmjXSQKV+VtOufPh0J9Kl
 cYrysSPDRLBeakICSgV1YbyEVdTRQodxzZKv9ajlLaZviHIfbD6eTf8h0
 fYO0sGMM9kerlAyYlDxckNrVtv/0ze1ZG11quUsIZCEpsIAFmVAUHhcVu M=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 3jDhGpUFKgTyx4jFb806c7YeroKRwDGEQenkN3bXfr8oD92c3I7ReZ8KpawvOgyzt+VGjnreTT
 Gcrh0BBx60oP6j4Ssz7mbDV8Ok5BMs7lCGDI6T+c1DjfmcqmPVP2JG+tdCnqDFqnOcup8eyXL0
 Jww8gPv2dwDJ1rKKvqxhkWe3c0XDajDB3Dvob01cqFiOQ/fyNuAPOlFbnJCBVF3a7qMhWndcs2
 +Vuf9Y5ZFdP5+xZmhdONN1Z2pzR0CEHfBX6mSOyzbHEoQc9yABNvz3iHUbRNn5Y3GbRW3oo2SC
 mF8=
X-SBRS: 2.7
X-MesageID: 15488991
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,364,1580792400"; d="scan'208";a="15488991"
Subject: Re: [PATCH] x86/mem_sharing: Fix build folloing VM Fork work
To: Tamas K Lengyel <tamas@tklengyel.com>
References: <20200409204837.7017-1-andrew.cooper3@citrix.com>
 <CABfawhnhfTScVDRxezP3qRarBczCPs2EVmLZMnN-FMpxyWN8XQ@mail.gmail.com>
 <769887ee-c381-ff58-bdf9-bd1a3032cbfb@citrix.com>
 <CABfawh=UPcyHRgNvsA8wNwV798e3RL_FhSF6ZrOrx89up4w+fQ@mail.gmail.com>
 <a89b2a51-8c54-4a35-4f77-e31018936534@citrix.com>
 <CABfawhm4Tdcp7QWqOyUXb_7Ag9yuQ93E3knH6joG4TDyXbgufA@mail.gmail.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <be90b42c-5e7b-fda3-9c57-29cea0dc66d5@citrix.com>
Date: Fri, 10 Apr 2020 01:58:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CABfawhm4Tdcp7QWqOyUXb_7Ag9yuQ93E3knH6joG4TDyXbgufA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 10/04/2020 00:23, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 5:00 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 09/04/2020 23:38, Tamas K Lengyel wrote:
>>> On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> On 09/04/2020 22:24, Tamas K Lengyel wrote:
>>>>> On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>>> A default build fails with:
>>>>>>
>>>>>>   mem_sharing.c: In function ‘copy_special_pages’:
>>>>>>   mem_sharing.c:1649:9: error: ‘HVM_PARAM_STORE_PFN’ undeclared (first use in this function)
>>>>>>            HVM_PARAM_STORE_PFN,
>>>>>>            ^~~~~~~~~~~~~~~~~~~
>>>>>>
>>>>>> I suspect this is a rebasing issue with respect to c/s 12f0c69f2709 "x86/HVM:
>>>>>> reduce hvm.h include dependencies".
>>>>>>
>>>>>> Fixes: 41548c5472a "mem_sharing: VM forking"
>>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> So staging definitely compiles for me both with and without
>>>>> CONFIG_MEM_SHARING enabled. By default its off, so this shouldn't even
>>>>> be compiled so I'm curious what's happening in your build. That said,
>>>>> I have no objection to the extra include if it turns out to be
>>>>> actually necessary.
>>>> Exact config attached.  I've just double checked that staging fails.
>>>>
>>>> We should get  to the bottom of exactly what is going on here, if it
>>>> isn't the obvious thing.
>>> Strange, with your config it does produce the error. With "echo
>>> CONFIG_MEM_SHARING=y > .config && XEN_CONFIG_EXPERT=y make
>>> olddefconfig && make" it does compile.
>> You lose XEN_CONFIG_EXPERT=y in the second make, so it rewrites your
>> .config behind your back.  (This behaviour is totally obnoxious).
> I also compiled with export XEN_CONFIG_EXPERT=y and it compiles fine.
>
>> Diff the current config against original?
> drt@t0:~/workspace/xen/xen$ diff .config .config-debug
> 6c6
> < CONFIG_GCC_VERSION=80300
> ---
>> CONFIG_GCC_VERSION=60300

;-(

I occasionally forget that `diff` defaults to unreadable.

>> # CONFIG_XEN_ALIGN_DEFAULT is not set
>> CONFIG_XEN_ALIGN_2M=y
>> CONFIG_GUEST=y
>> CONFIG_XEN_GUEST=y
>> CONFIG_PVH_GUEST=y
>> CONFIG_PV_SHIM=y
>> # CONFIG_PV_SHIM_EXCLUSIVE is not set
>> CONFIG_HYPERV_GUEST=y
> 61,62c65,74
> < # CONFIG_XSM is not set

With XSM compiled out, xsm/dummy.h is used, and has to include
public/hvm/params.h to get XEN_ALTP2M_* for xsm_hvm_altp2mhvm_op(), and
this bleeds through into everything which includes xsm/xsm.h, which is
basically everything.

Are you happy for me to fix up the commit message to this effect,
replacing the previous guesswork?

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 01:44:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 01:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMihx-0006gz-12; Fri, 10 Apr 2020 01:43:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMihv-0006gu-Gd
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 01:43:47 +0000
X-Inumbo-ID: b70aa4ac-7acc-11ea-838f-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b70aa4ac-7acc-11ea-838f-12813bfff9fa;
 Fri, 10 Apr 2020 01:43:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Message-Id:Subject:To:Sender:
 Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=IgQw27TUy8ZBlh2/1CDoLLp1cAe7OgZkd7+klEvHKVY=; b=Pvz7NvWGU4vOG4sLtOAeKUz32V
 Z7l0a3wjQGv2sR9vwkqtzuQDYGEo+Gb7DRQigu2EYIBQAH5sf7RhXx6puEUgolT+vMb/i+MqofDZA
 tBci/sCpEkw0mMuFXsmI7icsNsNImCBADR893T7G34f80wpIgOYXu3NZ3aZuXyvhSsoU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMihs-0000Vv-Tq; Fri, 10 Apr 2020 01:43:44 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMihs-0003xC-HI; Fri, 10 Apr 2020 01:43:44 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMihs-0002Kg-Fs; Fri, 10 Apr 2020 01:43:44 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Subject: [xen-unstable bisection] complete
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
Message-Id: <E1jMihs-0002Kg-Fs@osstest.test-lab.xenproject.org>
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 01:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  e013e8514389b739153016349e49f5a78e34ddf0
  Bug not present: 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149585/


  commit e013e8514389b739153016349e49f5a78e34ddf0
  Author: Juergen Gross <jgross@suse.com>
  Date:   Tue Apr 7 15:48:31 2020 +0200
  
      config: use mini-os master for unstable
      
      We haven't used mini-os master for about 2 years now due to a stubdom
      test failing [1]. Booting a guest with mini-os master used for building
      stubdom didn't reveal any problem, so use master for unstable in order
      to let OSStest find any problems not showing up in the local test.
      
      [1]: https://lists.xen.org/archives/html/minios-devel/2018-04/msg00015.html
      
      Signed-off-by: Juergen Gross <jgross@suse.com>
      Acked-by: Wei Liu <wl@xen.org>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/149585.bisection-summary --basis-template=149478 --blessings=real,real-bisect xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 149547 fail [host=huxelrebe1] / 149478 [host=elbling1] 149451 [host=debina0] 149431 [host=elbling0] 149406 [host=albana1] 149378 [host=debina1] 149297 [host=fiano0] 149260 [host=pinot1] 149231 [host=chardonnay0] 149188 [host=debina0] 149151 [host=fiano1] 149121 [host=chardonnay1] 149068 [host=albana0] 149029 [host=italia0] 148980 [host=huxelrebe0] 148925 ok.
Failure / basis pass flights: 149547 / 148925
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 9be0b2747bc7381c684cfbdd3fa2e40badefbeef
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 60d6ba1916dce0622a53b00dbae3c01d0761057e
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e41\
 0bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#60d6ba1916dce0622a53b00dbae3c01d0761057e-9be0b2747bc7381c684cfbdd3fa2e40badefbeef
Loaded 5001 nodes in revision graph
Searching for test results:
 148826 [host=albana0]
 148873 [host=rimava1]
 148925 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 60d6ba1916dce0622a53b00dbae3c01d0761057e
 148980 [host=huxelrebe0]
 149029 [host=italia0]
 149068 [host=albana0]
 149121 [host=chardonnay1]
 149151 [host=fiano1]
 149188 [host=debina0]
 149231 [host=chardonnay0]
 149260 [host=pinot1]
 149297 [host=fiano0]
 149335 []
 149378 [host=debina1]
 149406 [host=albana1]
 149431 [host=elbling0]
 149451 [host=debina0]
 149478 [host=elbling1]
 149502 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
 149549 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 37053578e8bd57de9d114b19a29f5ab1533d6071
 149537 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
 149539 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 5af4698d98d881e786c0909b6308f04696586c49
 149566 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 9be0b2747bc7381c684cfbdd3fa2e40badefbeef
 149520 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
 149552 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 4853f03dee2ed17cc421260d669377db253f0dac
 149541 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 98eb0c994ca828da7f38f0ee04c57a0ae24068a5
 149521 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 60d6ba1916dce0622a53b00dbae3c01d0761057e
 149562 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 60d6ba1916dce0622a53b00dbae3c01d0761057e
 149545 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 41cebdd1a6b5e880c768a4af69724851e6a06108
 149557 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6b8836aa65947e58ba2b58573cece03754ad68f6
 149584 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149547 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 9be0b2747bc7381c684cfbdd3fa2e40badefbeef
 149561 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149571 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
 149574 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
 149581 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
 149585 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
Searching for interesting versions
 Result found: flight 148925 (pass), for basis pass
 Result found: flight 149547 (fail), for basis failure
 Repro found: flight 149562 (pass), for basis pass
 Repro found: flight 149566 (fail), for basis failure
 0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
No revisions left to test, checking graph state.
 Result found: flight 149561 (pass), for last pass
 Result found: flight 149571 (fail), for first failure
 Repro found: flight 149574 (pass), for last pass
 Repro found: flight 149581 (fail), for first failure
 Repro found: flight 149584 (pass), for last pass
 Repro found: flight 149585 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  e013e8514389b739153016349e49f5a78e34ddf0
  Bug not present: 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149585/


  commit e013e8514389b739153016349e49f5a78e34ddf0
  Author: Juergen Gross <jgross@suse.com>
  Date:   Tue Apr 7 15:48:31 2020 +0200
  
      config: use mini-os master for unstable
      
      We haven't used mini-os master for about 2 years now due to a stubdom
      test failing [1]. Booting a guest with mini-os master used for building
      stubdom didn't reveal any problem, so use master for unstable in order
      to let OSStest find any problems not showing up in the local test.
      
      [1]: https://lists.xen.org/archives/html/minios-devel/2018-04/msg00015.html
      
      Signed-off-by: Juergen Gross <jgross@suse.com>
      Acked-by: Wei Liu <wl@xen.org>

Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
149585: tolerable ALL FAIL

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

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail baseline untested


jobs:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    


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



From xen-devel-bounces@lists.xenproject.org Fri Apr 10 02:20:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 02:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMjGs-0001Br-5R; Fri, 10 Apr 2020 02:19:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=TlO0=52=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jMjGq-0001Bm-Tn
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 02:19:53 +0000
X-Inumbo-ID: c26be518-7ad1-11ea-83d8-bc764e2007e4
Received: from mail-ed1-x543.google.com (unknown [2a00:1450:4864:20::543])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c26be518-7ad1-11ea-83d8-bc764e2007e4;
 Fri, 10 Apr 2020 02:19:52 +0000 (UTC)
Received: by mail-ed1-x543.google.com with SMTP id x62so781051ede.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 19:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=PpPT7lPl20frKGDc10gigFzLYju/84WLlJyhaR5CkVI=;
 b=xnPWxXf4KPbFcCK10glq5HWbhBlhup8tz3s+iUvtnbLIvImgb+Cl4YM5rjnagjh0w+
 IlAWGNi1onf64o9GnGWlJTq/4/XcYxAnfrmuFqBMDq9GLdhQo1VihwqknayUuzxBc+JG
 x205MjvQz81MWywJLh+s3aK2GQPyXuRQBxRWbGGCKiE9ZAjYdrXMBvyJs/RTZ3qYdMy9
 7XQy8/foMFZtlL4ENIlXtzNd2ygOZ2kVShxKQFDpqrNCx1v3gmzmbCtnkhgGuPSYhrBi
 ob9tzB+bs+DIGqYKemr0tVckpBISUDYSdo6eWXQtgt+xYaY3MDt1SunwOlA/Ni3K7IQ3
 /j4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=PpPT7lPl20frKGDc10gigFzLYju/84WLlJyhaR5CkVI=;
 b=KWqq9AVeSxsRysgZHkPoV6wn2OiMOhg07y1UsTxHD3tx/m0AFIXnqofECqauDt4PbS
 9zKlZ4Ew/cuuLI/f9OBlz+OcHgpDsXCzI07l9EokeOEZ+8E74FZGRYO5d9hdGV11OMJF
 ljjAX+6el/mTXbufsLnq6+Mmqyi0mm/3em1OWbVfQy6oKzncKfeGkWq0FcLmDA/wU9VK
 go9rZhaKzsZx+wLYtXP790wj/hjgboW3yI7K/csGPkb8fCWPELg5wSHs2xHGiO7Ev4MY
 IRLQx1k5u/wvfsCXNwBAdxUcORnBlHAfhxXM6tz9cMyXQBn9m+h+P0/NDnXhVMrUyjR6
 ySZw==
X-Gm-Message-State: AGi0PuabqMujNlYAStBcnRlqV35mvL31fH84ZTb6r+CRSl+Xr5hIfrSa
 LeOOCkq7tLKV/daN1W5lQrH/hU/wDJA=
X-Google-Smtp-Source: APiQypKPaprPFUJs5TSkDLeUyuvSoR45P6vfAcuftpOpBNuctrK8pLYOdSWZl4holExL6tgPKjv1dw==
X-Received: by 2002:a17:906:4004:: with SMTP id
 v4mr1812633ejj.265.1586485190729; 
 Thu, 09 Apr 2020 19:19:50 -0700 (PDT)
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com.
 [209.85.221.47])
 by smtp.gmail.com with ESMTPSA id w3sm27638ejf.21.2020.04.09.19.19.49
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Apr 2020 19:19:50 -0700 (PDT)
Received: by mail-wr1-f47.google.com with SMTP id j2so695635wrs.9
 for <xen-devel@lists.xenproject.org>; Thu, 09 Apr 2020 19:19:49 -0700 (PDT)
X-Received: by 2002:adf:eac1:: with SMTP id o1mr2274313wrn.182.1586485189257; 
 Thu, 09 Apr 2020 19:19:49 -0700 (PDT)
MIME-Version: 1.0
References: <20200409204837.7017-1-andrew.cooper3@citrix.com>
 <CABfawhnhfTScVDRxezP3qRarBczCPs2EVmLZMnN-FMpxyWN8XQ@mail.gmail.com>
 <769887ee-c381-ff58-bdf9-bd1a3032cbfb@citrix.com>
 <CABfawh=UPcyHRgNvsA8wNwV798e3RL_FhSF6ZrOrx89up4w+fQ@mail.gmail.com>
 <a89b2a51-8c54-4a35-4f77-e31018936534@citrix.com>
 <CABfawhm4Tdcp7QWqOyUXb_7Ag9yuQ93E3knH6joG4TDyXbgufA@mail.gmail.com>
 <be90b42c-5e7b-fda3-9c57-29cea0dc66d5@citrix.com>
In-Reply-To: <be90b42c-5e7b-fda3-9c57-29cea0dc66d5@citrix.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Thu, 9 Apr 2020 20:19:12 -0600
X-Gmail-Original-Message-ID: <CABfawhnayMsu8QV-_fcn4GGpURW0=4txNKKTFUpBBkUOC8knYg@mail.gmail.com>
Message-ID: <CABfawhnayMsu8QV-_fcn4GGpURW0=4txNKKTFUpBBkUOC8knYg@mail.gmail.com>
Subject: Re: [PATCH] x86/mem_sharing: Fix build folloing VM Fork work
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 9, 2020 at 6:58 PM Andrew Cooper <andrew.cooper3@citrix.com> wr=
ote:
>
> On 10/04/2020 00:23, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 5:00 PM Andrew Cooper <andrew.cooper3@citrix.com=
> wrote:
> >> On 09/04/2020 23:38, Tamas K Lengyel wrote:
> >>> On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper <andrew.cooper3@citrix.c=
om> wrote:
> >>>> On 09/04/2020 22:24, Tamas K Lengyel wrote:
> >>>>> On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper <andrew.cooper3@citrix=
.com> wrote:
> >>>>>> A default build fails with:
> >>>>>>
> >>>>>>   mem_sharing.c: In function =E2=80=98copy_special_pages=E2=80=99:
> >>>>>>   mem_sharing.c:1649:9: error: =E2=80=98HVM_PARAM_STORE_PFN=E2=80=
=99 undeclared (first use in this function)
> >>>>>>            HVM_PARAM_STORE_PFN,
> >>>>>>            ^~~~~~~~~~~~~~~~~~~
> >>>>>>
> >>>>>> I suspect this is a rebasing issue with respect to c/s 12f0c69f270=
9 "x86/HVM:
> >>>>>> reduce hvm.h include dependencies".
> >>>>>>
> >>>>>> Fixes: 41548c5472a "mem_sharing: VM forking"
> >>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>>> So staging definitely compiles for me both with and without
> >>>>> CONFIG_MEM_SHARING enabled. By default its off, so this shouldn't e=
ven
> >>>>> be compiled so I'm curious what's happening in your build. That sai=
d,
> >>>>> I have no objection to the extra include if it turns out to be
> >>>>> actually necessary.
> >>>> Exact config attached.  I've just double checked that staging fails.
> >>>>
> >>>> We should get  to the bottom of exactly what is going on here, if it
> >>>> isn't the obvious thing.
> >>> Strange, with your config it does produce the error. With "echo
> >>> CONFIG_MEM_SHARING=3Dy > .config && XEN_CONFIG_EXPERT=3Dy make
> >>> olddefconfig && make" it does compile.
> >> You lose XEN_CONFIG_EXPERT=3Dy in the second make, so it rewrites your
> >> .config behind your back.  (This behaviour is totally obnoxious).
> > I also compiled with export XEN_CONFIG_EXPERT=3Dy and it compiles fine.
> >
> >> Diff the current config against original?
> > drt@t0:~/workspace/xen/xen$ diff .config .config-debug
> > 6c6
> > < CONFIG_GCC_VERSION=3D80300
> > ---
> >> CONFIG_GCC_VERSION=3D60300
>
> ;-(
>
> I occasionally forget that `diff` defaults to unreadable.
>
> >> # CONFIG_XEN_ALIGN_DEFAULT is not set
> >> CONFIG_XEN_ALIGN_2M=3Dy
> >> CONFIG_GUEST=3Dy
> >> CONFIG_XEN_GUEST=3Dy
> >> CONFIG_PVH_GUEST=3Dy
> >> CONFIG_PV_SHIM=3Dy
> >> # CONFIG_PV_SHIM_EXCLUSIVE is not set
> >> CONFIG_HYPERV_GUEST=3Dy
> > 61,62c65,74
> > < # CONFIG_XSM is not set
>
> With XSM compiled out, xsm/dummy.h is used, and has to include
> public/hvm/params.h to get XEN_ALTP2M_* for xsm_hvm_altp2mhvm_op(), and
> this bleeds through into everything which includes xsm/xsm.h, which is
> basically everything.
>
> Are you happy for me to fix up the commit message to this effect,
> replacing the previous guesswork?

Of course. Thanks for deciphering this.

Acked-by: Tamas K Lengyel <tamas@tklengyel.com>


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 02:28:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 02:28:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMjPP-00024G-7Q; Fri, 10 Apr 2020 02:28:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMjPN-00024B-Jr
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 02:28:41 +0000
X-Inumbo-ID: fa4fbae4-7ad2-11ea-8395-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fa4fbae4-7ad2-11ea-8395-12813bfff9fa;
 Fri, 10 Apr 2020 02:28:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=73dtU3B+tP+EPTtQ+qJXSc4ek9LxlwunObPq/aYasWU=; b=ufqS8XDzTj1rxgwcioPl+Hpso
 bMM8REjPTEaak3S0u8uvuMBBmtogwuD7JmmZ5ja0TwC3DLBvHtmxVF7dD2CT6tTHdsklxSoG8VWvx
 U9taSxKtMHb3hbc73fjH06Ln4tmZNlryHwruYkxricaSjU7JMJ6t7maxsrkE772JbvcSA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMjPG-0001nf-MX; Fri, 10 Apr 2020 02:28:34 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMjPG-0005XV-EU; Fri, 10 Apr 2020 02:28:34 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMjPG-0003Y0-Dx; Fri, 10 Apr 2020 02:28:34 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149556-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.11-testing test] 149556: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=affb032b9b2624b67ffc7fb246a915dd08074b3f
X-Osstest-Versions-That: xen=6bc54c0696c0f6f639598363d284c7188a9e20ae
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 02:28:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass

version targeted for testing:
 xen                  affb032b9b2624b67ffc7fb246a915dd08074b3f
baseline version:
 xen                  6bc54c0696c0f6f639598363d284c7188a9e20ae

Last test of basis   148127  2020-03-05 11:05:50 Z   35 days
Testing same since   149556  2020-04-09 08:42:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  George Dunlap <george.dunlap@citrix.com>
  Igor Druzhinin <igor.druzhinin@citrix.com>
  Jan Beulich <jbeulich@suse.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   6bc54c0696..affb032b9b  affb032b9b2624b67ffc7fb246a915dd08074b3f -> stable-4.11


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 03:11:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 03:11:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMk48-00067p-UK; Fri, 10 Apr 2020 03:10:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=voSZ=52=intel.com=kevin.tian@srs-us1.protection.inumbo.net>)
 id 1jMk48-00067k-K7
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 03:10:48 +0000
X-Inumbo-ID: de9420be-7ad8-11ea-b58d-bc764e2007e4
Received: from mga11.intel.com (unknown [192.55.52.93])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id de9420be-7ad8-11ea-b58d-bc764e2007e4;
 Fri, 10 Apr 2020 03:10:45 +0000 (UTC)
IronPort-SDR: 6JR7cs07gVnpnY+bQ036tEGjtDdfQHNx95MzT20QO1uEhTWS+qs1Qsf90pmt1mLkQ1LEkKwfp/
 GAx89Vfh7RVA==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga005.fm.intel.com ([10.253.24.32])
 by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Apr 2020 20:10:44 -0700
IronPort-SDR: DUuzUbgaOsJudgTOZyjo+/hCvX1nRhahu2pqxq2qcp8cfJL1N4Ph0jR0hAMMbwU3kfGKOqko7f
 0eEG7GqPX+VQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,364,1580803200"; d="scan'208";a="452249577"
Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206])
 by fmsmga005.fm.intel.com with ESMTP; 09 Apr 2020 20:10:44 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by
 FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Thu, 9 Apr 2020 20:10:45 -0700
Received: from shsmsx106.ccr.corp.intel.com (10.239.4.159) by
 fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Thu, 9 Apr 2020 20:10:44 -0700
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.225]) by
 SHSMSX106.ccr.corp.intel.com ([169.254.10.89]) with mapi id 14.03.0439.000;
 Fri, 10 Apr 2020 11:10:43 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Alexandru Isaila <aisaila@bitdefender.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: RE: [PATCH V7] x86/altp2m: Hypercall to set altp2m view visibility
Thread-Topic: [PATCH V7] x86/altp2m: Hypercall to set altp2m view visibility
Thread-Index: AQHWBmAqvbfK20G+VkmZChseDW67eahxtMBA
Date: Fri, 10 Apr 2020 03:10:42 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D813897@SHSMSX104.ccr.corp.intel.com>
References: <20200330065434.5952-1-aisaila@bitdefender.com>
In-Reply-To: <20200330065434.5952-1-aisaila@bitdefender.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, "Nakajima,
 Jun" <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
 George Dunlap <George.Dunlap@eu.citrix.com>, Andrew
 Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Jan Beulich <jbeulich@suse.com>,
 =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

PiBGcm9tOiBBbGV4YW5kcnUgSXNhaWxhIDxhaXNhaWxhQGJpdGRlZmVuZGVyLmNvbT4NCj4gU2Vu
dDogTW9uZGF5LCBNYXJjaCAzMCwgMjAyMCAyOjU1IFBNDQo+IA0KPiBBdCB0aGlzIG1vbWVudCBh
IGd1ZXN0IGNhbiBjYWxsIHZtZnVuYyB0byBjaGFuZ2UgdGhlIGFsdHAybSB2aWV3LiBUaGlzDQo+
IHNob3VsZCBiZSBsaW1pdGVkIGluIG9yZGVyIHRvIGF2b2lkIGFueSB1bndhbnRlZCB2aWV3IHN3
aXRjaC4NCj4gDQo+IFRoZSBuZXcgeGNfYWx0cDJtX3NldF92aXNpYmlsaXR5KCkgc29sdmVzIHRo
aXMgYnkgbWFraW5nIHZpZXdzIGludmlzaWJsZQ0KPiB0byB2bWZ1bmMuDQo+IFRoaXMgaXMgZG9u
ZSBieSBoYXZpbmcgYSBzZXBhcmF0ZSBhcmNoLmFsdHAybV93b3JraW5nX2VwdHAgdGhhdCBpcw0K
PiBwb3B1bGF0ZWQgYW5kIG1hZGUgaW52YWxpZCBpbiB0aGUgc2FtZSBwbGFjZXMgYXMgYWx0cDJt
X2VwdHAuIFRoaXMgaXMNCj4gd3JpdHRlbiB0byBFUFRQX0xJU1RfQUREUi4NCj4gVGhlIHZpZXdz
IGFyZSBtYWRlIGluL3Zpc2libGUgYnkgbWFya2luZyB0aGVtIHdpdGggSU5WQUxJRF9NRk4gb3IN
Cj4gY29weWluZyB0aGVtIGJhY2sgZnJvbSBhbHRwMm1fZXB0cC4NCj4gVG8gaGF2ZSBjb25zaXN0
ZW5jeSB0aGUgdmlzaWJpbGl0eSBhbHNvIGFwcGxpZXMgdG8NCj4gcDJtX3N3aXRjaF9kb21haW5f
YWx0cDJtX2J5X2lkKCkuDQo+IA0KPiBUaGUgdXNhZ2Ugb2YgdGhpcyBoeXBlcmNhbGwgaXMgYWlt
ZWQgYXQgZG9tMCBoYXZpbmcgYSBsb2dpYyB3aXRoIGEgbnVtYmVyIG9mDQo+IHZpZXdzDQo+IGNy
ZWF0ZWQgYW5kIGF0IHNvbWUgdGltZSB0aGVyZSBpcyBhIG5lZWQgdG8gYmUgc3VyZSB0aGF0IG9u
bHkgc29tZSBvZiB0aGUNCj4gdmlld3MNCj4gY2FuIGJlIHN3aXRjaGVkLCBzYXZpbmcgdGhlIHJl
c3QgYW5kIG1ha2luZyB0aGVtIHZpc2libGUgd2hlbiB0aGUgdGltZQ0KPiBpcyByaWdodC4NCj4g
DQo+IE5vdGU6IElmIGFsdHAybSBtb2RlIGlzIHNldCB0byBtaXhlZCB0aGUgZ3Vlc3QgaXMgYWJs
ZSB0byBjaGFuZ2UgdGhlIHZpZXcNCj4gdmlzaWJpbGl0eSBhbmQgdGhlbiBjYWxsIHZtZnVuYy4N
Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IEFsZXhhbmRydSBJc2FpbGEgPGFpc2FpbGFAYml0ZGVmZW5k
ZXIuY29tPg0KPiAtLS0NCj4gQ0M6IElhbiBKYWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXgu
Y29tPg0KPiBDQzogV2VpIExpdSA8d2xAeGVuLm9yZz4NCj4gQ0M6IEFuZHJldyBDb29wZXIgPGFu
ZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQo+IENDOiBHZW9yZ2UgRHVubGFwIDxHZW9yZ2UuRHVu
bGFwQGV1LmNpdHJpeC5jb20+DQo+IENDOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+
DQo+IENDOiBKdWxpZW4gR3JhbGwgPGp1bGllbkB4ZW4ub3JnPg0KPiBDQzogS29ucmFkIFJ6ZXN6
dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPg0KPiBDQzogU3RlZmFubyBTdGFiZWxs
aW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0KPiBDQzogIlJvZ2VyIFBhdSBNb25uw6kiIDxy
b2dlci5wYXVAY2l0cml4LmNvbT4NCj4gQ0M6IEp1biBOYWthamltYSA8anVuLm5ha2FqaW1hQGlu
dGVsLmNvbT4NCj4gQ0M6IEtldmluIFRpYW4gPGtldmluLnRpYW5AaW50ZWwuY29tPg0KPiAtLS0N
Cj4gQ2hhbmdlcyBzaW5jZSBWNjoNCj4gCS0gVXBkYXRlIGNvbW1pdCBtZXNzYWdlLg0KPiANCj4g
Q2hhbmdlcyBzaW5jZSBWNToNCj4gCS0gQ2hhbmdlIGlkeCB0eXBlIGZyb20gdWludDE2X3QgdG8g
dW5zaWduZWQgaW50DQo+IAktIEFkZCByYyB2YXIgYW5kIGRyb3BwZWQgdGhlIGVyciByZXR1cm4g
ZnJvbSBwMm1fZ2V0X3N1cHByZXNzX3ZlKCkuDQo+IA0KPiBDaGFuZ2VzIHNpbmNlIFY0Og0KPiAJ
LSBNb3ZlIHAybSBzcGVjaWZpYyB0aGluZ3MgZnJvbSBodm0gdG8gcDJtLmMNCj4gCS0gQWRkIGNv
bW1lbnQgZm9yIGFsdHAybV9pZHggYm91bmRzIGNoZWNrDQo+IAktIEFkZCBhbHRwMm1fbGlzdF9s
b2NrL3VubG9jaygpLg0KPiANCj4gQ2hhbmdlcyBzaW5jZSBWMzoNCj4gCS0gQ2hhbmdlIHZhciBu
YW1lIGZvcm0gYWx0cDJtX2lkeCB0byBpZHggdG8gc2hvcnRlbiBsaW5lIGxlbmd0aA0KPiAJLSBB
ZGQgYm91bmRzIGNoZWNrIGZvciBpZHgNCj4gCS0gVXBkYXRlIGNvbW1pdCBtZXNzYWdlDQo+IAkt
IEFkZCBjb21tZW50IGluIHhlbmN0cmwuaC4NCj4gDQo+IENoYW5nZXMgc2luY2UgVjI6DQo+IAkt
IERyb3AgaGFwX2VuYWJsZWQoKSBjaGVjaw0KPiAJLSBSZWR1Y2UgdGhlIGluZGVudGF0aW9uIGRl
cHRoIGluIGh2bS5jDQo+IAktIEZpeCBhc3NpZ25tZW50IGluZGVudGF0aW9uDQo+IAktIERyb3Ag
cGFkMi4NCj4gDQo+IENoYW5nZXMgc2luY2UgVjE6DQo+IAktIERyb3AgZG91YmxlIHZpZXcgZnJv
bSB0aXRsZS4NCj4gLS0tDQo+ICB0b29scy9saWJ4Yy9pbmNsdWRlL3hlbmN0cmwuaCAgIHwgIDcg
KysrKysrKw0KPiAgdG9vbHMvbGlieGMveGNfYWx0cDJtLmMgICAgICAgICB8IDI0ICsrKysrKysr
KysrKysrKysrKysrKysrDQo+ICB4ZW4vYXJjaC94ODYvaHZtL2h2bS5jICAgICAgICAgIHwgMTQg
KysrKysrKysrKysrKysNCj4gIHhlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jICAgICAgfCAgMiAr
LQ0KPiAgeGVuL2FyY2gveDg2L21tL2hhcC9oYXAuYyAgICAgICB8IDE1ICsrKysrKysrKysrKysr
Kw0KPiAgeGVuL2FyY2gveDg2L21tL3AybS1lcHQuYyAgICAgICB8ICAxICsNCj4gIHhlbi9hcmNo
L3g4Ni9tbS9wMm0uYyAgICAgICAgICAgfCAzNCArKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrLS0NCj4gIHhlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmggICAgfCAgMSArDQo+ICB4ZW4v
aW5jbHVkZS9hc20teDg2L3AybS5oICAgICAgIHwgIDQgKysrKw0KPiAgeGVuL2luY2x1ZGUvcHVi
bGljL2h2bS9odm1fb3AuaCB8ICA5ICsrKysrKysrKw0KPiAgMTAgZmlsZXMgY2hhbmdlZCwgMTA4
IGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMv
bGlieGMvaW5jbHVkZS94ZW5jdHJsLmggYi90b29scy9saWJ4Yy9pbmNsdWRlL3hlbmN0cmwuaA0K
PiBpbmRleCBmYzZlNTdhMWEwLi4yZTZlNjUyNjc4IDEwMDY0NA0KPiAtLS0gYS90b29scy9saWJ4
Yy9pbmNsdWRlL3hlbmN0cmwuaA0KPiArKysgYi90b29scy9saWJ4Yy9pbmNsdWRlL3hlbmN0cmwu
aA0KPiBAQCAtMTk0Myw2ICsxOTQzLDEzIEBAIGludCB4Y19hbHRwMm1fY2hhbmdlX2dmbih4Y19p
bnRlcmZhY2UgKmhhbmRsZSwNCj4gdWludDMyX3QgZG9taWQsDQo+ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgeGVuX3Bmbl90IG5ld19nZm4pOw0KPiAgaW50IHhjX2FsdHAybV9nZXRfdmNwdV9w
Mm1faWR4KHhjX2ludGVyZmFjZSAqaGFuZGxlLCB1aW50MzJfdCBkb21pZCwNCj4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB2Y3B1aWQsIHVpbnQxNl90ICpwMm1pZHgp
Ow0KPiArLyoNCj4gKyAqIFNldCB2aWV3IHZpc2liaWxpdHkgZm9yIHhjX2FsdHAybV9zd2l0Y2hf
dG9fdmlldyBhbmQgdm1mdW5jLg0KPiArICogTm90ZTogSWYgYWx0cDJtIG1vZGUgaXMgc2V0IHRv
IG1peGVkIHRoZSBndWVzdCBpcyBhYmxlIHRvIGNoYW5nZSB0aGUgdmlldw0KPiArICogdmlzaWJp
bGl0eSBhbmQgdGhlbiBjYWxsIHZtZnVuYy4NCj4gKyAqLw0KPiAraW50IHhjX2FsdHAybV9zZXRf
dmlzaWJpbGl0eSh4Y19pbnRlcmZhY2UgKmhhbmRsZSwgdWludDMyX3QgZG9taWQsDQo+ICsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNl90IHZpZXdfaWQsIGJvb2wgdmlzaWJsZSk7
DQo+IA0KPiAgLyoqDQo+ICAgKiBNZW0gcGFnaW5nIG9wZXJhdGlvbnMuDQo+IGRpZmYgLS1naXQg
YS90b29scy9saWJ4Yy94Y19hbHRwMm0uYyBiL3Rvb2xzL2xpYnhjL3hjX2FsdHAybS5jDQo+IGlu
ZGV4IDQ2ZmI3MjU4MDYuLjY5ODdjOTU0MWYgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2xpYnhjL3hj
X2FsdHAybS5jDQo+ICsrKyBiL3Rvb2xzL2xpYnhjL3hjX2FsdHAybS5jDQo+IEBAIC00MTAsMyAr
NDEwLDI3IEBAIGludCB4Y19hbHRwMm1fZ2V0X3ZjcHVfcDJtX2lkeCh4Y19pbnRlcmZhY2UNCj4g
KmhhbmRsZSwgdWludDMyX3QgZG9taWQsDQo+ICAgICAgeGNfaHlwZXJjYWxsX2J1ZmZlcl9mcmVl
KGhhbmRsZSwgYXJnKTsNCj4gICAgICByZXR1cm4gcmM7DQo+ICB9DQo+ICsNCj4gK2ludCB4Y19h
bHRwMm1fc2V0X3Zpc2liaWxpdHkoeGNfaW50ZXJmYWNlICpoYW5kbGUsIHVpbnQzMl90IGRvbWlk
LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MTZfdCB2aWV3X2lkLCBib29s
IHZpc2libGUpDQo+ICt7DQo+ICsgICAgaW50IHJjOw0KPiArDQo+ICsgICAgREVDTEFSRV9IWVBF
UkNBTExfQlVGRkVSKHhlbl9odm1fYWx0cDJtX29wX3QsIGFyZyk7DQo+ICsNCj4gKyAgICBhcmcg
PSB4Y19oeXBlcmNhbGxfYnVmZmVyX2FsbG9jKGhhbmRsZSwgYXJnLCBzaXplb2YoKmFyZykpOw0K
PiArICAgIGlmICggYXJnID09IE5VTEwgKQ0KPiArICAgICAgICByZXR1cm4gLTE7DQo+ICsNCj4g
KyAgICBhcmctPnZlcnNpb24gPSBIVk1PUF9BTFRQMk1fSU5URVJGQUNFX1ZFUlNJT047DQo+ICsg
ICAgYXJnLT5jbWQgPSBIVk1PUF9hbHRwMm1fc2V0X3Zpc2liaWxpdHk7DQo+ICsgICAgYXJnLT5k
b21haW4gPSBkb21pZDsNCj4gKyAgICBhcmctPnUuc2V0X3Zpc2liaWxpdHkuYWx0cDJtX2lkeCA9
IHZpZXdfaWQ7DQo+ICsgICAgYXJnLT51LnNldF92aXNpYmlsaXR5LnZpc2libGUgPSB2aXNpYmxl
Ow0KPiArDQo+ICsgICAgcmMgPSB4ZW5jYWxsMihoYW5kbGUtPnhjYWxsLCBfX0hZUEVSVklTT1Jf
aHZtX29wLCBIVk1PUF9hbHRwMm0sDQo+ICsgICAgICAgICAgICAgICAgICBIWVBFUkNBTExfQlVG
RkVSX0FTX0FSRyhhcmcpKTsNCj4gKw0KPiArICAgIHhjX2h5cGVyY2FsbF9idWZmZXJfZnJlZSho
YW5kbGUsIGFyZyk7DQo+ICsgICAgcmV0dXJuIHJjOw0KPiArfQ0KPiBkaWZmIC0tZ2l0IGEveGVu
L2FyY2gveDg2L2h2bS9odm0uYyBiL3hlbi9hcmNoL3g4Ni9odm0vaHZtLmMNCj4gaW5kZXggYTNk
MTE1YjY1MC4uMzc1ZTljZjM2OCAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gveDg2L2h2bS9odm0u
Yw0KPiArKysgYi94ZW4vYXJjaC94ODYvaHZtL2h2bS5jDQo+IEBAIC00NTExLDYgKzQ1MTEsNyBA
QCBzdGF0aWMgaW50IGRvX2FsdHAybV9vcCgNCj4gICAgICBjYXNlIEhWTU9QX2FsdHAybV9nZXRf
bWVtX2FjY2VzczoNCj4gICAgICBjYXNlIEhWTU9QX2FsdHAybV9jaGFuZ2VfZ2ZuOg0KPiAgICAg
IGNhc2UgSFZNT1BfYWx0cDJtX2dldF9wMm1faWR4Og0KPiArICAgIGNhc2UgSFZNT1BfYWx0cDJt
X3NldF92aXNpYmlsaXR5Og0KPiAgICAgICAgICBicmVhazsNCj4gDQo+ICAgICAgZGVmYXVsdDoN
Cj4gQEAgLTQ3ODgsNiArNDc4OSwxOSBAQCBzdGF0aWMgaW50IGRvX2FsdHAybV9vcCgNCj4gICAg
ICAgICAgYnJlYWs7DQo+ICAgICAgfQ0KPiANCj4gKyAgICBjYXNlIEhWTU9QX2FsdHAybV9zZXRf
dmlzaWJpbGl0eToNCj4gKyAgICB7DQo+ICsgICAgICAgIHVuc2lnbmVkIGludCBpZHggPSBhLnUu
c2V0X3Zpc2liaWxpdHkuYWx0cDJtX2lkeDsNCj4gKw0KPiArICAgICAgICBpZiAoIGEudS5zZXRf
dmlzaWJpbGl0eS5wYWQgKQ0KPiArICAgICAgICAgICAgcmMgPSAtRUlOVkFMOw0KPiArICAgICAg
ICBlbHNlIGlmICggIWFsdHAybV9hY3RpdmUoZCkgKQ0KPiArICAgICAgICAgICAgcmMgPSAtRU9Q
Tk9UU1VQUDsNCj4gKyAgICAgICAgZWxzZQ0KPiArICAgICAgICAgICAgcmMgPSBwMm1fc2V0X2Fs
dHAybV92aWV3X3Zpc2liaWxpdHkoZCwgaWR4LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgYS51LnNldF92aXNpYmlsaXR5LnZpc2libGUpOw0KPiAr
ICAgIH0NCj4gKw0KPiAgICAgIGRlZmF1bHQ6DQo+ICAgICAgICAgIEFTU0VSVF9VTlJFQUNIQUJM
RSgpOw0KPiAgICAgIH0NCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5j
IGIveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMNCj4gaW5kZXggZDI2NWVkNDZhZC4uYmI0NGVm
MzlhMSAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMNCj4gKysrIGIv
eGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMNCj4gQEAgLTIxNDAsNyArMjE0MCw3IEBAIHN0YXRp
YyB2b2lkIHZteF92Y3B1X3VwZGF0ZV92bWZ1bmNfdmUoc3RydWN0DQo+IHZjcHUgKnYpDQo+ICAg
ICAgew0KPiAgICAgICAgICB2LT5hcmNoLmh2bS52bXguc2Vjb25kYXJ5X2V4ZWNfY29udHJvbCB8
PSBtYXNrOw0KPiAgICAgICAgICBfX3Ztd3JpdGUoVk1fRlVOQ1RJT05fQ09OVFJPTCwNCj4gVk1Y
X1ZNRlVOQ19FUFRQX1NXSVRDSElORyk7DQo+IC0gICAgICAgIF9fdm13cml0ZShFUFRQX0xJU1Rf
QUREUiwgdmlydF90b19tYWRkcihkLT5hcmNoLmFsdHAybV9lcHRwKSk7DQo+ICsgICAgICAgIF9f
dm13cml0ZShFUFRQX0xJU1RfQUREUiwgdmlydF90b19tYWRkcihkLQ0KPiA+YXJjaC5hbHRwMm1f
d29ya2luZ19lcHRwKSk7DQoNCklzICJhbHRwMm1fdmlzaWJsZV9lcHRwIiBtb3JlIGFjY3VyYXRl
IGhlcmU/ICd3b3JraW5nJyBpcyBhIGJpdCBtaXNsZWFkaW5nDQpzaW5jZSBldmVuIGludmlzaWJs
ZSBlcHRwIGNvdWxkIHN0aWxsIHdvcmsgYnV0IGp1c3Qgbm90IGRpcmVjdGx5IHRvZ2dlZCBieQ0K
dm1mdW5jLi4uDQoNCm90aGVyd2lzZSwgDQoJUmV2aWV3ZWQtYnk6IEtldmluIFRpYW4gPGtldmlu
LnRpYW5AaW50ZWwuY29tPg0KDQo+IA0KPiAgICAgICAgICBpZiAoIGNwdV9oYXNfdm14X3ZpcnRf
ZXhjZXB0aW9ucyApDQo+ICAgICAgICAgIHsNCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9t
bS9oYXAvaGFwLmMgYi94ZW4vYXJjaC94ODYvbW0vaGFwL2hhcC5jDQo+IGluZGV4IGE2ZDVlMzli
MDIuLjM3MmM4NGRhOWIgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9oYXAvaGFwLmMN
Cj4gKysrIGIveGVuL2FyY2gveDg2L21tL2hhcC9oYXAuYw0KPiBAQCAtNDkzLDggKzQ5MywxNyBA
QCBpbnQgaGFwX2VuYWJsZShzdHJ1Y3QgZG9tYWluICpkLCB1MzIgbW9kZSkNCj4gICAgICAgICAg
ICAgIGdvdG8gb3V0Ow0KPiAgICAgICAgICB9DQo+IA0KPiArICAgICAgICBpZiAoIChkLT5hcmNo
LmFsdHAybV93b3JraW5nX2VwdHAgPSBhbGxvY194ZW5oZWFwX3BhZ2UoKSkgPT0gTlVMTCApDQo+
ICsgICAgICAgIHsNCj4gKyAgICAgICAgICAgIHJ2ID0gLUVOT01FTTsNCj4gKyAgICAgICAgICAg
IGdvdG8gb3V0Ow0KPiArICAgICAgICB9DQo+ICsNCj4gICAgICAgICAgZm9yICggaSA9IDA7IGkg
PCBNQVhfRVBUUDsgaSsrICkNCj4gKyAgICAgICAgew0KPiAgICAgICAgICAgICAgZC0+YXJjaC5h
bHRwMm1fZXB0cFtpXSA9IG1mbl94KElOVkFMSURfTUZOKTsNCj4gKyAgICAgICAgICAgIGQtPmFy
Y2guYWx0cDJtX3dvcmtpbmdfZXB0cFtpXSA9IG1mbl94KElOVkFMSURfTUZOKTsNCj4gKyAgICAg
ICAgfQ0KPiANCj4gICAgICAgICAgZm9yICggaSA9IDA7IGkgPCBNQVhfQUxUUDJNOyBpKysgKQ0K
PiAgICAgICAgICB7DQo+IEBAIC01MjgsNiArNTM3LDEyIEBAIHZvaWQgaGFwX2ZpbmFsX3RlYXJk
b3duKHN0cnVjdCBkb21haW4gKmQpDQo+ICAgICAgICAgICAgICBkLT5hcmNoLmFsdHAybV9lcHRw
ID0gTlVMTDsNCj4gICAgICAgICAgfQ0KPiANCj4gKyAgICAgICAgaWYgKCBkLT5hcmNoLmFsdHAy
bV93b3JraW5nX2VwdHAgKQ0KPiArICAgICAgICB7DQo+ICsgICAgICAgICAgICBmcmVlX3hlbmhl
YXBfcGFnZShkLT5hcmNoLmFsdHAybV93b3JraW5nX2VwdHApOw0KPiArICAgICAgICAgICAgZC0+
YXJjaC5hbHRwMm1fd29ya2luZ19lcHRwID0gTlVMTDsNCj4gKyAgICAgICAgfQ0KPiArDQo+ICAg
ICAgICAgIGZvciAoIGkgPSAwOyBpIDwgTUFYX0FMVFAyTTsgaSsrICkNCj4gICAgICAgICAgICAg
IHAybV90ZWFyZG93bihkLT5hcmNoLmFsdHAybV9wMm1baV0pOw0KPiAgICAgIH0NCj4gZGlmZiAt
LWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9wMm0tZXB0LmMgYi94ZW4vYXJjaC94ODYvbW0vcDJtLWVw
dC5jDQo+IGluZGV4IGViMGYwZWRmZWYuLjY1MzljYTYxOWIgMTAwNjQ0DQo+IC0tLSBhL3hlbi9h
cmNoL3g4Ni9tbS9wMm0tZXB0LmMNCj4gKysrIGIveGVuL2FyY2gveDg2L21tL3AybS1lcHQuYw0K
PiBAQCAtMTM2OCw2ICsxMzY4LDcgQEAgdm9pZCBwMm1faW5pdF9hbHRwMm1fZXB0KHN0cnVjdCBk
b21haW4gKmQsDQo+IHVuc2lnbmVkIGludCBpKQ0KPiAgICAgIGVwdCA9ICZwMm0tPmVwdDsNCj4g
ICAgICBlcHQtPm1mbiA9IHBhZ2V0YWJsZV9nZXRfcGZuKHAybV9nZXRfcGFnZXRhYmxlKHAybSkp
Ow0KPiAgICAgIGQtPmFyY2guYWx0cDJtX2VwdHBbYXJyYXlfaW5kZXhfbm9zcGVjKGksIE1BWF9F
UFRQKV0gPSBlcHQtPmVwdHA7DQo+ICsgICAgZC0+YXJjaC5hbHRwMm1fd29ya2luZ19lcHRwW2Fy
cmF5X2luZGV4X25vc3BlYyhpLCBNQVhfRVBUUCldID0gZXB0LQ0KPiA+ZXB0cDsNCj4gIH0NCj4g
DQo+ICB1bnNpZ25lZCBpbnQgcDJtX2ZpbmRfYWx0cDJtX2J5X2VwdHAoc3RydWN0IGRvbWFpbiAq
ZCwgdWludDY0X3QgZXB0cCkNCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYyBi
L3hlbi9hcmNoL3g4Ni9tbS9wMm0uYw0KPiBpbmRleCBkOTNjNDE4YmNmLi4wNTI2YmZmNWIyIDEw
MDY0NA0KPiAtLS0gYS94ZW4vYXJjaC94ODYvbW0vcDJtLmMNCj4gKysrIGIveGVuL2FyY2gveDg2
L21tL3AybS5jDQo+IEBAIC0yNTE1LDYgKzI1MTUsNyBAQCB2b2lkIHAybV9mbHVzaF9hbHRwMm0o
c3RydWN0IGRvbWFpbiAqZCkNCj4gICAgICB7DQo+ICAgICAgICAgIHAybV9yZXNldF9hbHRwMm0o
ZCwgaSwgQUxUUDJNX0RFQUNUSVZBVEUpOw0KPiAgICAgICAgICBkLT5hcmNoLmFsdHAybV9lcHRw
W2ldID0gbWZuX3goSU5WQUxJRF9NRk4pOw0KPiArICAgICAgICBkLT5hcmNoLmFsdHAybV93b3Jr
aW5nX2VwdHBbaV0gPSBtZm5feChJTlZBTElEX01GTik7DQo+ICAgICAgfQ0KPiANCj4gICAgICBh
bHRwMm1fbGlzdF91bmxvY2soZCk7DQo+IEBAIC0yNjM0LDcgKzI2MzUsOSBAQCBpbnQgcDJtX2Rl
c3Ryb3lfYWx0cDJtX2J5X2lkKHN0cnVjdCBkb21haW4gKmQsDQo+IHVuc2lnbmVkIGludCBpZHgp
DQo+ICAgICAgICAgIHsNCj4gICAgICAgICAgICAgIHAybV9yZXNldF9hbHRwMm0oZCwgaWR4LCBB
TFRQMk1fREVBQ1RJVkFURSk7DQo+ICAgICAgICAgICAgICBkLT5hcmNoLmFsdHAybV9lcHRwW2Fy
cmF5X2luZGV4X25vc3BlYyhpZHgsIE1BWF9FUFRQKV0gPQ0KPiAtICAgICAgICAgICAgbWZuX3go
SU5WQUxJRF9NRk4pOw0KPiArICAgICAgICAgICAgICAgIG1mbl94KElOVkFMSURfTUZOKTsNCj4g
KyAgICAgICAgICAgIGQtPmFyY2guYWx0cDJtX3dvcmtpbmdfZXB0cFthcnJheV9pbmRleF9ub3Nw
ZWMoaWR4LCBNQVhfRVBUUCldDQo+ID0NCj4gKyAgICAgICAgICAgICAgICBtZm5feChJTlZBTElE
X01GTik7DQo+ICAgICAgICAgICAgICByYyA9IDA7DQo+ICAgICAgICAgIH0NCj4gICAgICB9DQo+
IEBAIC0yNjYxLDcgKzI2NjQsNyBAQCBpbnQgcDJtX3N3aXRjaF9kb21haW5fYWx0cDJtX2J5X2lk
KHN0cnVjdA0KPiBkb21haW4gKmQsIHVuc2lnbmVkIGludCBpZHgpDQo+ICAgICAgcmMgPSAtRUlO
VkFMOw0KPiAgICAgIGFsdHAybV9saXN0X2xvY2soZCk7DQo+IA0KPiAtICAgIGlmICggZC0+YXJj
aC5hbHRwMm1fZXB0cFtpZHhdICE9IG1mbl94KElOVkFMSURfTUZOKSApDQo+ICsgICAgaWYgKCBk
LT5hcmNoLmFsdHAybV93b3JraW5nX2VwdHBbaWR4XSAhPSBtZm5feChJTlZBTElEX01GTikgKQ0K
PiAgICAgIHsNCj4gICAgICAgICAgZm9yX2VhY2hfdmNwdSggZCwgdiApDQo+ICAgICAgICAgICAg
ICBpZiAoIGlkeCAhPSB2Y3B1X2FsdHAybSh2KS5wMm1pZHggKQ0KPiBAQCAtMzE0NSw2ICszMTQ4
LDMzIEBAIGludCBwMm1fZ2V0X3N1cHByZXNzX3ZlKHN0cnVjdCBkb21haW4gKmQsIGdmbl90DQo+
IGdmbiwgYm9vbCAqc3VwcHJlc3NfdmUsDQo+IA0KPiAgICAgIHJldHVybiByYzsNCj4gIH0NCj4g
Kw0KPiAraW50IHAybV9zZXRfYWx0cDJtX3ZpZXdfdmlzaWJpbGl0eShzdHJ1Y3QgZG9tYWluICpk
LCB1bnNpZ25lZCBpbnQNCj4gYWx0cDJtX2lkeCwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdWludDhfdCB2aXNpYmxlKQ0KPiArew0KPiArICAgIGludCByYyA9IDA7DQo+
ICsNCj4gKyAgICBhbHRwMm1fbGlzdF9sb2NrKGQpOw0KPiArDQo+ICsgICAgLyoNCj4gKyAgICAg
KiBFcHRwIGluZGV4IGlzIGNvcnJlbGF0ZWQgd2l0aCBhbHRwMm0gaW5kZXggYW5kIHNob3VsZCBu
b3QgZXhjZWVkDQo+ICsgICAgICogbWluKE1BWF9BTFRQMk0sIE1BWF9FUFRQKS4NCj4gKyAgICAg
Ki8NCj4gKyAgICBpZiAoIGFsdHAybV9pZHggPj0gbWluKEFSUkFZX1NJWkUoZC0+YXJjaC5hbHRw
Mm1fcDJtKSwgTUFYX0VQVFApIHx8DQo+ICsgICAgICAgICBkLT5hcmNoLmFsdHAybV9lcHRwW2Fy
cmF5X2luZGV4X25vc3BlYyhhbHRwMm1faWR4LCBNQVhfRVBUUCldID09DQo+ICsgICAgICAgICBt
Zm5feChJTlZBTElEX01GTikgKQ0KPiArICAgICAgICByYyA9IC1FSU5WQUw7DQo+ICsgICAgZWxz
ZSBpZiAoIHZpc2libGUgKQ0KPiArICAgICAgICBkLT5hcmNoLmFsdHAybV93b3JraW5nX2VwdHBb
YXJyYXlfaW5kZXhfbm9zcGVjKGFsdHAybV9pZHgsDQo+IE1BWF9FUFRQKV0gPQ0KPiArICAgICAg
ICAgICAgZC0+YXJjaC5hbHRwMm1fZXB0cFthcnJheV9pbmRleF9ub3NwZWMoYWx0cDJtX2lkeCwg
TUFYX0VQVFApXTsNCj4gKyAgICBlbHNlDQo+ICsgICAgICAgIGQtPmFyY2guYWx0cDJtX3dvcmtp
bmdfZXB0cFthcnJheV9pbmRleF9ub3NwZWMoYWx0cDJtX2lkeCwNCj4gTUFYX0VQVFApXSA9DQo+
ICsgICAgICAgICAgICBtZm5feChJTlZBTElEX01GTik7DQo+ICsNCj4gKyAgICBhbHRwMm1fbGlz
dF91bmxvY2soZCk7DQo+ICsNCj4gKyAgICByZXR1cm4gcmM7DQo+ICt9DQo+ICAjZW5kaWYNCj4g
DQo+ICAvKg0KPiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaCBiL3hl
bi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgNCj4gaW5kZXggMTA1YWRmOTZlYi4uODAwZTEyZWFl
NSAxMDA2NDQNCj4gLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaA0KPiArKysgYi94
ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oDQo+IEBAIC0zMjcsNiArMzI3LDcgQEAgc3RydWN0
IGFyY2hfZG9tYWluDQo+ICAgICAgc3RydWN0IHAybV9kb21haW4gKmFsdHAybV9wMm1bTUFYX0FM
VFAyTV07DQo+ICAgICAgbW1fbG9ja190IGFsdHAybV9saXN0X2xvY2s7DQo+ICAgICAgdWludDY0
X3QgKmFsdHAybV9lcHRwOw0KPiArICAgIHVpbnQ2NF90ICphbHRwMm1fd29ya2luZ19lcHRwOw0K
PiAgI2VuZGlmDQo+IA0KPiAgICAgIC8qIE5CLiBwcm90ZWN0ZWQgYnkgZC0+ZXZlbnRfbG9jayBh
bmQgYnkgaXJxX2Rlc2NbaXJxXS5sb2NrICovDQo+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9h
c20teDg2L3AybS5oIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9wMm0uaA0KPiBpbmRleCBhMmM2MDQ5
ODM0Li5hY2UzNTczYWU4IDEwMDY0NA0KPiAtLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L3AybS5o
DQo+ICsrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvcDJtLmgNCj4gQEAgLTg5OCw2ICs4OTgsMTAg
QEAgaW50IHAybV9jaGFuZ2VfYWx0cDJtX2dmbihzdHJ1Y3QgZG9tYWluICpkLA0KPiB1bnNpZ25l
ZCBpbnQgaWR4LA0KPiAgaW50IHAybV9hbHRwMm1fcHJvcGFnYXRlX2NoYW5nZShzdHJ1Y3QgZG9t
YWluICpkLCBnZm5fdCBnZm4sDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1m
bl90IG1mbiwgdW5zaWduZWQgaW50IHBhZ2Vfb3JkZXIsDQo+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHAybV90eXBlX3QgcDJtdCwgcDJtX2FjY2Vzc190IHAybWEpOw0KPiArDQo+
ICsvKiBTZXQgYSBzcGVjaWZpYyBwMm0gdmlldyB2aXNpYmlsaXR5ICovDQo+ICtpbnQgcDJtX3Nl
dF9hbHRwMm1fdmlld192aXNpYmlsaXR5KHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBp
ZHgsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4X3QgdmlzaWJs
ZSk7DQo+ICAjZWxzZQ0KPiAgc3RydWN0IHAybV9kb21haW4gKnAybV9nZXRfYWx0cDJtKHN0cnVj
dCB2Y3B1ICp2KTsNCj4gIHN0YXRpYyBpbmxpbmUgdm9pZCBwMm1fYWx0cDJtX2NoZWNrKHN0cnVj
dCB2Y3B1ICp2LCB1aW50MTZfdCBpZHgpIHt9DQo+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9w
dWJsaWMvaHZtL2h2bV9vcC5oDQo+IGIveGVuL2luY2x1ZGUvcHVibGljL2h2bS9odm1fb3AuaA0K
PiBpbmRleCBiNTk5ZDNjYmQwLi44NzBlYzUyMDYwIDEwMDY0NA0KPiAtLS0gYS94ZW4vaW5jbHVk
ZS9wdWJsaWMvaHZtL2h2bV9vcC5oDQo+ICsrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9odm0vaHZt
X29wLmgNCj4gQEAgLTMxOCw2ICszMTgsMTIgQEAgc3RydWN0IHhlbl9odm1fYWx0cDJtX2dldF92
Y3B1X3AybV9pZHggew0KPiAgICAgIHVpbnQxNl90IGFsdHAybV9pZHg7DQo+ICB9Ow0KPiANCj4g
K3N0cnVjdCB4ZW5faHZtX2FsdHAybV9zZXRfdmlzaWJpbGl0eSB7DQo+ICsgICAgdWludDE2X3Qg
YWx0cDJtX2lkeDsNCj4gKyAgICB1aW50OF90IHZpc2libGU7DQo+ICsgICAgdWludDhfdCBwYWQ7
DQo+ICt9Ow0KPiArDQo+ICBzdHJ1Y3QgeGVuX2h2bV9hbHRwMm1fb3Agew0KPiAgICAgIHVpbnQz
Ml90IHZlcnNpb247ICAgLyogSFZNT1BfQUxUUDJNX0lOVEVSRkFDRV9WRVJTSU9OICovDQo+ICAg
ICAgdWludDMyX3QgY21kOw0KPiBAQCAtMzUwLDYgKzM1Niw4IEBAIHN0cnVjdCB4ZW5faHZtX2Fs
dHAybV9vcCB7DQo+ICAjZGVmaW5lIEhWTU9QX2FsdHAybV9nZXRfcDJtX2lkeCAgICAgICAgICAx
NA0KPiAgLyogU2V0IHRoZSAiU3VwcmVzcyAjVkUiIGJpdCBmb3IgYSByYW5nZSBvZiBwYWdlcyAq
Lw0KPiAgI2RlZmluZSBIVk1PUF9hbHRwMm1fc2V0X3N1cHByZXNzX3ZlX211bHRpIDE1DQo+ICsv
KiBTZXQgdmlzaWJpbGl0eSBmb3IgYSBnaXZlbiBhbHRwMm0gdmlldyAqLw0KPiArI2RlZmluZSBI
Vk1PUF9hbHRwMm1fc2V0X3Zpc2liaWxpdHkgICAgICAgMTYNCj4gICAgICBkb21pZF90IGRvbWFp
bjsNCj4gICAgICB1aW50MTZfdCBwYWQxOw0KPiAgICAgIHVpbnQzMl90IHBhZDI7DQo+IEBAIC0z
NjcsNiArMzc1LDcgQEAgc3RydWN0IHhlbl9odm1fYWx0cDJtX29wIHsNCj4gICAgICAgICAgc3Ry
dWN0IHhlbl9odm1fYWx0cDJtX3N1cHByZXNzX3ZlX211bHRpICAgIHN1cHByZXNzX3ZlX211bHRp
Ow0KPiAgICAgICAgICBzdHJ1Y3QgeGVuX2h2bV9hbHRwMm1fdmNwdV9kaXNhYmxlX25vdGlmeSAg
ZGlzYWJsZV9ub3RpZnk7DQo+ICAgICAgICAgIHN0cnVjdCB4ZW5faHZtX2FsdHAybV9nZXRfdmNw
dV9wMm1faWR4ICAgICBnZXRfdmNwdV9wMm1faWR4Ow0KPiArICAgICAgICBzdHJ1Y3QgeGVuX2h2
bV9hbHRwMm1fc2V0X3Zpc2liaWxpdHkgICAgICAgc2V0X3Zpc2liaWxpdHk7DQo+ICAgICAgICAg
IHVpbnQ4X3QgcGFkWzY0XTsNCj4gICAgICB9IHU7DQo+ICB9Ow0KPiAtLQ0KPiAyLjE3LjENCg0K


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 06:24:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 06:24:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMn5g-00053L-PR; Fri, 10 Apr 2020 06:24:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=L1Sz=52=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jMn5g-00053G-1f
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 06:24:36 +0000
X-Inumbo-ID: f0ed61e2-7af3-11ea-83b3-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f0ed61e2-7af3-11ea-83b3-12813bfff9fa;
 Fri, 10 Apr 2020 06:24:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6BD58AC77;
 Fri, 10 Apr 2020 06:24:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: torvalds@linux-foundation.org
Subject: [GIT PULL] xen: branch for v5.7-rc1
Date: Fri, 10 Apr 2020 08:24:30 +0200
Message-Id: <20200410062430.20949-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
 linux-kernel@vger.kernel.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.7-rc1b-tag

xen: branch for v5.7-rc1b

This is a second batch of Xen related patches:

- two cleanup patches
- a patch to fix a boot regression introduced earlier in 5.7
- a patch to fix wrong usage of memory allocation flags

Thanks.

Juergen

 arch/x86/xen/setup.c                  |  2 +-
 arch/x86/xen/xen-head.S               |  2 +-
 drivers/block/xen-blkfront.c          | 17 +++++--
 drivers/xen/events/events_2l.c        | 16 +++---
 drivers/xen/events/events_base.c      | 93 ++++++++++++++++++-----------------
 drivers/xen/events/events_fifo.c      | 22 ++++-----
 drivers/xen/events/events_internal.h  | 30 +++++------
 drivers/xen/evtchn.c                  | 13 ++---
 drivers/xen/gntdev-common.h           |  3 +-
 drivers/xen/gntdev.c                  |  2 +-
 drivers/xen/pvcalls-back.c            |  5 +-
 drivers/xen/pvcalls-front.c           | 15 +++---
 drivers/xen/xen-pciback/xenbus.c      |  7 +--
 drivers/xen/xen-scsiback.c            |  3 +-
 drivers/xen/xenbus/xenbus_client.c    |  6 +--
 include/xen/events.h                  | 22 ++++-----
 include/xen/interface/event_channel.h |  2 +-
 include/xen/xenbus.h                  |  5 +-
 18 files changed, 142 insertions(+), 123 deletions(-)

Jason Yan (1):
      x86/xen: make xen_pvmmu_arch_setup() static

Juergen Gross (2):
      xen/blkfront: fix memory allocation flags in blkfront_setup_indirect()
      x86/xen: fix booting 32-bit pv guest

Yan Yankovskyi (1):
      xen: Use evtchn_type_t as a type for event channels


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 06:44:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 06:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMnOg-0006hD-I6; Fri, 10 Apr 2020 06:44:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=ievq=52=bitdefender.com=aisaila@srs-us1.protection.inumbo.net>)
 id 1jMnOe-0006h8-VR
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 06:44:13 +0000
X-Inumbo-ID: af4f1f48-7af6-11ea-83b3-12813bfff9fa
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown
 [40.107.22.100]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id af4f1f48-7af6-11ea-83b3-12813bfff9fa;
 Fri, 10 Apr 2020 06:44:11 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=OT78v4F2Dlj3todmwRp4v7a8w6SP3gqgeHl5rwXihVjOP8FOsj0dEYy0yYGevY96MYQ/vfM1F49afpzppDCqiGFiiYPJ0oU8zVeRc6+bZgzXiFoyEr/jrXyi0yqUKrV/DjLr8Up6C/QK0UnwMDoJWFTpuy+Ge6Fig3sN32P7OPM7UcC/RbIFjMtebm17qd73uWdJQu2rgz89ijtBaHqfSW/3jCLxMJrta3LtUd+UdhBFxItvWSSVZ5f/VYMHa3wCE/QSvNFIsEIsvqOj4bcYkrhgyRVbYANJ/ehjpCqdGMPG0JoRmApyS5EaTw52hHhrvs+horxelaHysQ5QPZB3Bg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=g4Qrqahw16njwMMCAjAlS5t+9HBXe7nEJBv3Kid+mrE=;
 b=bd7vl3NMBpPFGZu/Y+VDejVTbzyPKLL+7lLgU/sjrcgahmMNxek4pElyf4gcAR93tTJ/wWIRjz8zsiSgrGS7kPkAgHdsVjuQErbfd+xkUp0AEE55MMiEkyJnQFYE5on4fI/jy6d7Qd2dOdfX2uPnLv+HPkX1qqGKUrpfp/kJ+Fp1AZ2QFzK6oahTOBEJjEjFTJSKS/GNpLS9SJcao22fkPNxhwqb4FrFqT6WkUWN33RctZ9gTyoCkt4Uivmc9BgViJLyCF4s0GYqO59kop78+EnoYP63hC48WZI4PbtULUQZ36398fja0OvkHRqFcwf65Dqf3m650ooejiG5ma328w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=bitdefender.com; dmarc=pass action=none
 header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=g4Qrqahw16njwMMCAjAlS5t+9HBXe7nEJBv3Kid+mrE=;
 b=ZGeo+nPvfFLvwTyXbdfTdRYnUOY4rN83BwJ4SvGw8C8c003IcIRVhLR/E5Rbg17GQCEW44E0b8NZl++GGK//8na2hpXftcPWK0OXRrJyEzygsN+CgY4d/pBUz62NfygyegGraKii82kr1v2EtbAxta35OBalyfv4H/XgP+7idjM=
Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=aisaila@bitdefender.com; 
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com (2603:10a6:20b:86::23)
 by AM6PR02MB4280.eurprd02.prod.outlook.com (2603:10a6:20b:41::32)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Fri, 10 Apr
 2020 06:44:09 +0000
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208]) by AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208%4]) with mapi id 15.20.2900.015; Fri, 10 Apr 2020
 06:44:09 +0000
Subject: Re: [PATCH V7] x86/altp2m: Hypercall to set altp2m view visibility
To: "Tian, Kevin" <kevin.tian@intel.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <20200330065434.5952-1-aisaila@bitdefender.com>
 <AADFC41AFE54684AB9EE6CBC0274A5D19D813897@SHSMSX104.ccr.corp.intel.com>
From: Isaila Alexandru <aisaila@bitdefender.com>
Organization: BD
Message-ID: <8e30cf60-d309-dc0b-f2d5-cdd6bea2b81d@bitdefender.com>
Date: Fri, 10 Apr 2020 09:44:07 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D19D813897@SHSMSX104.ccr.corp.intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: VI1PR06CA0120.eurprd06.prod.outlook.com
 (2603:10a6:803:8c::49) To AM6PR02MB5223.eurprd02.prod.outlook.com
 (2603:10a6:20b:86::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.0.107] (82.77.232.39) by
 VI1PR06CA0120.eurprd06.prod.outlook.com (2603:10a6:803:8c::49) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2900.15 via Frontend Transport; Fri, 10 Apr 2020 06:44:08 +0000
X-Originating-IP: [82.77.232.39]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 1f539ed7-43bd-4ae0-b40f-08d7dd1a925f
X-MS-TrafficTypeDiagnostic: AM6PR02MB4280:|AM6PR02MB4280:
X-Microsoft-Antispam-PRVS: <AM6PR02MB4280747B9FEB6EDD9A3F6B67ABDE0@AM6PR02MB4280.eurprd02.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:6430;
X-Forefront-PRVS: 0369E8196C
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:AM6PR02MB5223.eurprd02.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10019020)(39850400004)(136003)(396003)(366004)(376002)(346002)(36916002)(316002)(5660300002)(81156014)(16526019)(2616005)(86362001)(8676002)(52116002)(26005)(956004)(16576012)(186003)(110136005)(8936002)(54906003)(2906002)(66946007)(31686004)(478600001)(66476007)(7416002)(53546011)(31696002)(6486002)(66556008)(4326008)(36756003);
 DIR:OUT; SFP:1102; 
Received-SPF: None (protection.outlook.com: bitdefender.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: MzscsD8MVKOjc+kGgIWDNPRYdh4yDdGT1aKeKsI4haqLKne16XNKUpzG2DnhaQS0cAR+rHcK58Vbvh/HIlXJhTwgk8zg2xkt+HnVN/KUm3WJCyMibCVd+MhkDE6gGI5dz7M1JYC8bIYl42s5xeQPQ8s+y6bhzKAmjj612NiZR5qmgFcVA9o8y9rN/HB0EIERJ1Yxu5LK0Mpparf82aQUCl/1CozX9XHvAq1cWw+waNc8FsDnf680uAdgUgEzNo6Nwz2T2QcZ4QgyBQCN/7ZFDLNSmjyvpFHDlY1hH7Rxmfz8Nmokb6KfZDdozEksgJXlRoPUKexU1SFR2mfUVsL+b7deMoHp4B5kSJLEAhbisl8Jc558maHJS9M5bQIlSag3KI87rGLQ/paxUiDc15Ry6o9pYiVQiLHGgoAU0zJCCgt7MTjjKW3l6QcRV0GMCYwp
X-MS-Exchange-AntiSpam-MessageData: DHPnu8UKWfR/I/Aj8u3qAW+uKJN18hau6kCnlLdc2+of9j3PMbC274FLTMNJBkYOZzVNyMNDQfqUpY6YgiQliV28wea5EP66/JaD8/RXI9Lpy54nM3PM1m258dq7GjygbTHg5WrTAwr/5swx90ywzg==
X-MS-Exchange-Transport-Forked: True
X-OriginatorOrg: bitdefender.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f539ed7-43bd-4ae0-b40f-08d7dd1a925f
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2020 06:44:09.2907 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: jGfh5wJCOqvaRLVsOdPZDscvQuDck4PZgsUfkItJAAx579PpnI8OmbjWR6EIKxdPz87LeAHXwNNZKSozzS9vTnN/4bl/kNBKR8MutyoddEw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR02MB4280
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>,
 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
 George Dunlap <George.Dunlap@eu.citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, "Nakajima,
 Jun" <jun.nakajima@intel.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 10.04.2020 06:10, Tian, Kevin wrote:

>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index a3d115b650..375e9cf368 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4511,6 +4511,7 @@ static int do_altp2m_op(
>>       case HVMOP_altp2m_get_mem_access:
>>       case HVMOP_altp2m_change_gfn:
>>       case HVMOP_altp2m_get_p2m_idx:
>> +    case HVMOP_altp2m_set_visibility:
>>           break;
>>
>>       default:
>> @@ -4788,6 +4789,19 @@ static int do_altp2m_op(
>>           break;
>>       }
>>
>> +    case HVMOP_altp2m_set_visibility:
>> +    {
>> +        unsigned int idx = a.u.set_visibility.altp2m_idx;
>> +
>> +        if ( a.u.set_visibility.pad )
>> +            rc = -EINVAL;
>> +        else if ( !altp2m_active(d) )
>> +            rc = -EOPNOTSUPP;
>> +        else
>> +            rc = p2m_set_altp2m_view_visibility(d, idx,
>> +                                                a.u.set_visibility.visible);
>> +    }
>> +
>>       default:
>>           ASSERT_UNREACHABLE();
>>       }
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index d265ed46ad..bb44ef39a1 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2140,7 +2140,7 @@ static void vmx_vcpu_update_vmfunc_ve(struct
>> vcpu *v)
>>       {
>>           v->arch.hvm.vmx.secondary_exec_control |= mask;
>>           __vmwrite(VM_FUNCTION_CONTROL,
>> VMX_VMFUNC_EPTP_SWITCHING);
>> -        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
>> +        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d-
>>> arch.altp2m_working_eptp));
> 
> Is "altp2m_visible_eptp" more accurate here? 'working' is a bit misleading
> since even invisible eptp could still work but just not directly togged by
> vmfunc...

Yes, you are right and I can change this before it is commited.

> 
> otherwise,
> 	Reviewed-by: Kevin Tian <kevin.tian@intel.com>

Thanks for the review,

Alex


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 06:49:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 06:49:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMnTv-0006rv-73; Fri, 10 Apr 2020 06:49:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=ievq=52=bitdefender.com=aisaila@srs-us1.protection.inumbo.net>)
 id 1jMnTu-0006rq-3P
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 06:49:38 +0000
X-Inumbo-ID: 705fc909-7af7-11ea-83b5-12813bfff9fa
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown
 [40.107.22.108]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 705fc909-7af7-11ea-83b5-12813bfff9fa;
 Fri, 10 Apr 2020 06:49:36 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=CQmEJBGoNvfAErpPz1bFvHQhLvmdcM7osWln+t3DfYR5vEUgNOgIk6Aom56Lfhi0ziGdN3dgDlEqx0lBxREmc9lhes3tTzbObRZCEhAG4oTZnJnIJpYmhNUtT/5KoowjPFwWgb/6n3DSz3qomubhwDNZvGThYq8Fv+3s6givhoSnQvGeRfzVnHoTnZvxPxH2evX9ku+U+3ZqVn7MuxfoFMT09IgYtTUHWIeipGb3MHEGyjTVRcsy92a/PdLqQ5x2qAzPrx3FIUQEIv23O60YAPSTvAXrGJuEXTMb4F6dn9zRdzRBKNMWEIAelNw5iqdeJ4Iiv3MqfUR4eE0HZ5z0+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=eNXxErwibcVBbWqFcwxt1afnMzaxHzBRJ2aM0urBRwg=;
 b=lLTs+/7x86WNmF4BdSfPqA0EyaBw++KpsvgBgADXO5o12HOgfUBXfZb4cvbk0B2Zi+laRZ075RlXs+Hm7svrOh3P8IkT8BZfbLDBKIqj869IQURCfygqXPMqrrBiWTuUxozRljkdFnbjHDhUpKGWzrAGXyHq1RM4Ve03a25oq+cDTB9M/qrZOfB4uxRVi7+kYz4ULbaAKWrxPA4Kof5PLXo0n58rwMcOZZ9b5z+SA07GP6bUv9ZmJAhq6lFT6GZ3AwzGTZ+Ycv7qRQOQ3sZ9jVuzeK69ZtiTHFqQcsuhwD6zBuLysL518yzsJI4go16acgir3ws78xHvQBrCKPcMHw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=bitdefender.com; dmarc=pass action=none
 header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=eNXxErwibcVBbWqFcwxt1afnMzaxHzBRJ2aM0urBRwg=;
 b=VBmY9QVlAUxCdJCr/egPqj6d/fg7Z6srxz5oE52tiWJN75cWz+WDD2dP4XoV9wzG9fuAjhKjj85PIklHRnaoRpsgk35Gp9beReQbl1UCBx+0P19zk4n+0cl9Agzy+OVvuJhYGZ6gXPo46wupdIhRwySqqMfB6qpgVDk39quZcZg=
Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=aisaila@bitdefender.com; 
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com (2603:10a6:20b:86::23)
 by AM6PR02MB4117.eurprd02.prod.outlook.com (2603:10a6:20b:42::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Fri, 10 Apr
 2020 06:49:34 +0000
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208]) by AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208%4]) with mapi id 15.20.2900.015; Fri, 10 Apr 2020
 06:49:34 +0000
Subject: Re: [PATCH V7] x86/altp2m: Hypercall to set altp2m view visibility
To: xen-devel@lists.xenproject.org
References: <20200330065434.5952-1-aisaila@bitdefender.com>
From: Isaila Alexandru <aisaila@bitdefender.com>
Organization: BD
Message-ID: <b5e549ec-f4a4-aca8-ff14-6bb09a601c40@bitdefender.com>
Date: Fri, 10 Apr 2020 09:49:32 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
In-Reply-To: <20200330065434.5952-1-aisaila@bitdefender.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: VI1PR0501CA0045.eurprd05.prod.outlook.com
 (2603:10a6:800:60::31) To AM6PR02MB5223.eurprd02.prod.outlook.com
 (2603:10a6:20b:86::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.0.107] (82.77.232.39) by
 VI1PR0501CA0045.eurprd05.prod.outlook.com (2603:10a6:800:60::31) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend
 Transport; Fri, 10 Apr 2020 06:49:33 +0000
X-Originating-IP: [82.77.232.39]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 7afca22d-41cc-46df-e638-08d7dd1b544e
X-MS-TrafficTypeDiagnostic: AM6PR02MB4117:|AM6PR02MB4117:
X-Microsoft-Antispam-PRVS: <AM6PR02MB41170F469666DB3FCFAB28C3ABDE0@AM6PR02MB4117.eurprd02.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:538;
X-Forefront-PRVS: 0369E8196C
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:AM6PR02MB5223.eurprd02.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10019020)(346002)(39850400004)(366004)(396003)(136003)(376002)(6916009)(5660300002)(6486002)(8936002)(81156014)(36916002)(956004)(86362001)(478600001)(7416002)(8676002)(2906002)(316002)(52116002)(4326008)(36756003)(2616005)(31696002)(26005)(16526019)(186003)(53546011)(66476007)(54906003)(66946007)(31686004)(16576012)(66556008)(30864003);
 DIR:OUT; SFP:1102; 
Received-SPF: None (protection.outlook.com: bitdefender.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 2kpMZdXzGRbSj/dG10o87G5CJ80ZtgfQIkgqNX4nT8onzjDK3O4mT+bhWUC1tY/WqDBl7p7SI5wizstrVBOLOiVAj0rp0j+nVPIaMlxSQPcNp8NMQa45LG/vbQ9b6s54OD8BvjH31RX6QyjCm2TtpfVvrE3gwF56XJXx+luclPj4K48Fyt9NOCgOlNT+iIgP3navJGRXEJ6BYXVFxj4D0Bc2tAzkZR+ig5dNc930hqPAEj5COPvNKPkLjRtv+LyDe+SLlFzXO/1ndcaifkh9H2prjh8z9xsGASrRypLPlzgmSU4G2rH9dD0qwDFj/7bjt2qyWUGeyKz70wgAnSrdQPPXT2xcplijAaK3vhU0F26XvTfP3LOcvG01FtlpI8FrNloKbXfeGfuAiVdnDyyT5AeFNp7Hw03U6MorqJXf6C2GyEdX2A2Bf86QotKe4ozv
X-MS-Exchange-AntiSpam-MessageData: 7YCXonfESXpNsnGG8R7PiwqpTU5g7X9yRtlZfObDIKdVLWcqsG6GSpM8pTy1h8Guo7qqmUzn8HS3FB9ku1QrZn3oMluwtLg2ZQ5hJY3BjRDUsgRtKPmZmtMPyaV+1XfxF83FFFiWnwiGmG28CQazXg==
X-MS-Exchange-Transport-Forked: True
X-OriginatorOrg: bitdefender.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7afca22d-41cc-46df-e638-08d7dd1b544e
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2020 06:49:34.6805 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: dYUwv0aQfaJPyYxBcYVmIkrWDlCIY471/oyHgHelzVNUdOoLXZPn5BJ/a3unByVTOYVa7ia7f3WQUpbYjI/Ycl3frZJ2yZ+SA7WN1vo+RGw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR02MB4117
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
 George Dunlap <George.Dunlap@eu.citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Are there any more r-b needed for this patch?

Thanks,
Alex

On 30.03.2020 09:54, Alexandru Isaila wrote:
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
> 
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
> This is done by having a separate arch.altp2m_working_eptp that is
> populated and made invalid in the same places as altp2m_eptp. This is
> written to EPTP_LIST_ADDR.
> The views are made in/visible by marking them with INVALID_MFN or
> copying them back from altp2m_eptp.
> To have consistency the visibility also applies to
> p2m_switch_domain_altp2m_by_id().
> 
> The usage of this hypercall is aimed at dom0 having a logic with a number of views
> created and at some time there is a need to be sure that only some of the views
> can be switched, saving the rest and making them visible when the time
> is right.
> 
> Note: If altp2m mode is set to mixed the guest is able to change the view
> visibility and then call vmfunc.
> 
> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
> ---
> CC: Ian Jackson <ian.jackson@eu.citrix.com>
> CC: Wei Liu <wl@xen.org>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: George Dunlap <George.Dunlap@eu.citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: "Roger Pau Monné" <roger.pau@citrix.com>
> CC: Jun Nakajima <jun.nakajima@intel.com>
> CC: Kevin Tian <kevin.tian@intel.com>
> ---
> Changes since V6:
> 	- Update commit message.
> 
> Changes since V5:
> 	- Change idx type from uint16_t to unsigned int
> 	- Add rc var and dropped the err return from p2m_get_suppress_ve().
> 
> Changes since V4:
> 	- Move p2m specific things from hvm to p2m.c
> 	- Add comment for altp2m_idx bounds check
> 	- Add altp2m_list_lock/unlock().
> 
> Changes since V3:
> 	- Change var name form altp2m_idx to idx to shorten line length
> 	- Add bounds check for idx
> 	- Update commit message
> 	- Add comment in xenctrl.h.
> 
> Changes since V2:
> 	- Drop hap_enabled() check
> 	- Reduce the indentation depth in hvm.c
> 	- Fix assignment indentation
> 	- Drop pad2.
> 
> Changes since V1:
> 	- Drop double view from title.
> ---
>   tools/libxc/include/xenctrl.h   |  7 +++++++
>   tools/libxc/xc_altp2m.c         | 24 +++++++++++++++++++++++
>   xen/arch/x86/hvm/hvm.c          | 14 ++++++++++++++
>   xen/arch/x86/hvm/vmx/vmx.c      |  2 +-
>   xen/arch/x86/mm/hap/hap.c       | 15 +++++++++++++++
>   xen/arch/x86/mm/p2m-ept.c       |  1 +
>   xen/arch/x86/mm/p2m.c           | 34 +++++++++++++++++++++++++++++++--
>   xen/include/asm-x86/domain.h    |  1 +
>   xen/include/asm-x86/p2m.h       |  4 ++++
>   xen/include/public/hvm/hvm_op.h |  9 +++++++++
>   10 files changed, 108 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index fc6e57a1a0..2e6e652678 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1943,6 +1943,13 @@ int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
>                            xen_pfn_t new_gfn);
>   int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
>                                  uint32_t vcpuid, uint16_t *p2midx);
> +/*
> + * Set view visibility for xc_altp2m_switch_to_view and vmfunc.
> + * Note: If altp2m mode is set to mixed the guest is able to change the view
> + * visibility and then call vmfunc.
> + */
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> +                             uint16_t view_id, bool visible);
>   
>   /**
>    * Mem paging operations.
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 46fb725806..6987c9541f 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -410,3 +410,27 @@ int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
>       xc_hypercall_buffer_free(handle, arg);
>       return rc;
>   }
> +
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> +                             uint16_t view_id, bool visible)
> +{
> +    int rc;
> +
> +    DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +    arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +    if ( arg == NULL )
> +        return -1;
> +
> +    arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +    arg->cmd = HVMOP_altp2m_set_visibility;
> +    arg->domain = domid;
> +    arg->u.set_visibility.altp2m_idx = view_id;
> +    arg->u.set_visibility.visible = visible;
> +
> +    rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> +                  HYPERCALL_BUFFER_AS_ARG(arg));
> +
> +    xc_hypercall_buffer_free(handle, arg);
> +    return rc;
> +}
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index a3d115b650..375e9cf368 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4511,6 +4511,7 @@ static int do_altp2m_op(
>       case HVMOP_altp2m_get_mem_access:
>       case HVMOP_altp2m_change_gfn:
>       case HVMOP_altp2m_get_p2m_idx:
> +    case HVMOP_altp2m_set_visibility:
>           break;
>   
>       default:
> @@ -4788,6 +4789,19 @@ static int do_altp2m_op(
>           break;
>       }
>   
> +    case HVMOP_altp2m_set_visibility:
> +    {
> +        unsigned int idx = a.u.set_visibility.altp2m_idx;
> +
> +        if ( a.u.set_visibility.pad )
> +            rc = -EINVAL;
> +        else if ( !altp2m_active(d) )
> +            rc = -EOPNOTSUPP;
> +        else
> +            rc = p2m_set_altp2m_view_visibility(d, idx,
> +                                                a.u.set_visibility.visible);
> +    }
> +
>       default:
>           ASSERT_UNREACHABLE();
>       }
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index d265ed46ad..bb44ef39a1 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2140,7 +2140,7 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
>       {
>           v->arch.hvm.vmx.secondary_exec_control |= mask;
>           __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
> -        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
> +        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_working_eptp));
>   
>           if ( cpu_has_vmx_virt_exceptions )
>           {
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index a6d5e39b02..372c84da9b 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -493,8 +493,17 @@ int hap_enable(struct domain *d, u32 mode)
>               goto out;
>           }
>   
> +        if ( (d->arch.altp2m_working_eptp = alloc_xenheap_page()) == NULL )
> +        {
> +            rv = -ENOMEM;
> +            goto out;
> +        }
> +
>           for ( i = 0; i < MAX_EPTP; i++ )
> +        {
>               d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +            d->arch.altp2m_working_eptp[i] = mfn_x(INVALID_MFN);
> +        }
>   
>           for ( i = 0; i < MAX_ALTP2M; i++ )
>           {
> @@ -528,6 +537,12 @@ void hap_final_teardown(struct domain *d)
>               d->arch.altp2m_eptp = NULL;
>           }
>   
> +        if ( d->arch.altp2m_working_eptp )
> +        {
> +            free_xenheap_page(d->arch.altp2m_working_eptp);
> +            d->arch.altp2m_working_eptp = NULL;
> +        }
> +
>           for ( i = 0; i < MAX_ALTP2M; i++ )
>               p2m_teardown(d->arch.altp2m_p2m[i]);
>       }
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index eb0f0edfef..6539ca619b 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1368,6 +1368,7 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>       ept = &p2m->ept;
>       ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
>       d->arch.altp2m_eptp[array_index_nospec(i, MAX_EPTP)] = ept->eptp;
> +    d->arch.altp2m_working_eptp[array_index_nospec(i, MAX_EPTP)] = ept->eptp;
>   }
>   
>   unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp)
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index d93c418bcf..0526bff5b2 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2515,6 +2515,7 @@ void p2m_flush_altp2m(struct domain *d)
>       {
>           p2m_reset_altp2m(d, i, ALTP2M_DEACTIVATE);
>           d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +        d->arch.altp2m_working_eptp[i] = mfn_x(INVALID_MFN);
>       }
>   
>       altp2m_list_unlock(d);
> @@ -2634,7 +2635,9 @@ int p2m_destroy_altp2m_by_id(struct domain *d, unsigned int idx)
>           {
>               p2m_reset_altp2m(d, idx, ALTP2M_DEACTIVATE);
>               d->arch.altp2m_eptp[array_index_nospec(idx, MAX_EPTP)] =
> -            mfn_x(INVALID_MFN);
> +                mfn_x(INVALID_MFN);
> +            d->arch.altp2m_working_eptp[array_index_nospec(idx, MAX_EPTP)] =
> +                mfn_x(INVALID_MFN);
>               rc = 0;
>           }
>       }
> @@ -2661,7 +2664,7 @@ int p2m_switch_domain_altp2m_by_id(struct domain *d, unsigned int idx)
>       rc = -EINVAL;
>       altp2m_list_lock(d);
>   
> -    if ( d->arch.altp2m_eptp[idx] != mfn_x(INVALID_MFN) )
> +    if ( d->arch.altp2m_working_eptp[idx] != mfn_x(INVALID_MFN) )
>       {
>           for_each_vcpu( d, v )
>               if ( idx != vcpu_altp2m(v).p2midx )
> @@ -3145,6 +3148,33 @@ int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, bool *suppress_ve,
>   
>       return rc;
>   }
> +
> +int p2m_set_altp2m_view_visibility(struct domain *d, unsigned int altp2m_idx,
> +                                   uint8_t visible)
> +{
> +    int rc = 0;
> +
> +    altp2m_list_lock(d);
> +
> +    /*
> +     * Eptp index is correlated with altp2m index and should not exceed
> +     * min(MAX_ALTP2M, MAX_EPTP).
> +     */
> +    if ( altp2m_idx >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) ||
> +         d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] ==
> +         mfn_x(INVALID_MFN) )
> +        rc = -EINVAL;
> +    else if ( visible )
> +        d->arch.altp2m_working_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] =
> +            d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)];
> +    else
> +        d->arch.altp2m_working_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] =
> +            mfn_x(INVALID_MFN);
> +
> +    altp2m_list_unlock(d);
> +
> +    return rc;
> +}
>   #endif
>   
>   /*
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 105adf96eb..800e12eae5 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -327,6 +327,7 @@ struct arch_domain
>       struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
>       mm_lock_t altp2m_list_lock;
>       uint64_t *altp2m_eptp;
> +    uint64_t *altp2m_working_eptp;
>   #endif
>   
>       /* NB. protected by d->event_lock and by irq_desc[irq].lock */
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index a2c6049834..ace3573ae8 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -898,6 +898,10 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int idx,
>   int p2m_altp2m_propagate_change(struct domain *d, gfn_t gfn,
>                                   mfn_t mfn, unsigned int page_order,
>                                   p2m_type_t p2mt, p2m_access_t p2ma);
> +
> +/* Set a specific p2m view visibility */
> +int p2m_set_altp2m_view_visibility(struct domain *d, unsigned int idx,
> +                                   uint8_t visible);
>   #else
>   struct p2m_domain *p2m_get_altp2m(struct vcpu *v);
>   static inline void p2m_altp2m_check(struct vcpu *v, uint16_t idx) {}
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index b599d3cbd0..870ec52060 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -318,6 +318,12 @@ struct xen_hvm_altp2m_get_vcpu_p2m_idx {
>       uint16_t altp2m_idx;
>   };
>   
> +struct xen_hvm_altp2m_set_visibility {
> +    uint16_t altp2m_idx;
> +    uint8_t visible;
> +    uint8_t pad;
> +};
> +
>   struct xen_hvm_altp2m_op {
>       uint32_t version;   /* HVMOP_ALTP2M_INTERFACE_VERSION */
>       uint32_t cmd;
> @@ -350,6 +356,8 @@ struct xen_hvm_altp2m_op {
>   #define HVMOP_altp2m_get_p2m_idx          14
>   /* Set the "Supress #VE" bit for a range of pages */
>   #define HVMOP_altp2m_set_suppress_ve_multi 15
> +/* Set visibility for a given altp2m view */
> +#define HVMOP_altp2m_set_visibility       16
>       domid_t domain;
>       uint16_t pad1;
>       uint32_t pad2;
> @@ -367,6 +375,7 @@ struct xen_hvm_altp2m_op {
>           struct xen_hvm_altp2m_suppress_ve_multi    suppress_ve_multi;
>           struct xen_hvm_altp2m_vcpu_disable_notify  disable_notify;
>           struct xen_hvm_altp2m_get_vcpu_p2m_idx     get_vcpu_p2m_idx;
> +        struct xen_hvm_altp2m_set_visibility       set_visibility;
>           uint8_t pad[64];
>       } u;
>   };
> 


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 07:38:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 07:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMoF4-0002Zd-5P; Fri, 10 Apr 2020 07:38:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMoF3-0002ZY-CL
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 07:38:21 +0000
X-Inumbo-ID: 3f9b3ecd-7afe-11ea-83c0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3f9b3ecd-7afe-11ea-83c0-12813bfff9fa;
 Fri, 10 Apr 2020 07:38:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=CCsgA5NXGgF5gDQi8fTwS9qFKVygd9HVPn8qugm6kRY=; b=QH578UH2yJ0E8uGxdEpMObdia
 Ae4T2rtMHQE2rqxkfV4BDqDSchf73WF8tRAhFM9IbrAX0BBwpLSsA0/xOI+o3So7cmb8Q5k7J68bK
 Vr+2DG5FWaO1jvD3GCPnShK7XbYy6dxaWI/9+79ONB8Am/Z+h7C9YjaMdW8WmA/x3KIX0=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMoF1-0008AZ-RB; Fri, 10 Apr 2020 07:38:19 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMoF1-0002l6-G2; Fri, 10 Apr 2020 07:38:19 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMoF1-0004G4-FK; Fri, 10 Apr 2020 07:38:19 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149560-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149560: all pass - PUSHED
X-Osstest-Versions-This: ovmf=e4004e8e505a9ca697b1d5aaee9b3ae25cdc3b21
X-Osstest-Versions-That: ovmf=d4bc5378e003e53a1c76d106997cec4af46a133a
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 07:38:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

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

Last test of basis   149528  2020-04-08 15:10:19 Z    1 days
Testing same since   149560  2020-04-09 10:09:22 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Eugene Cohen <eugene@nuviainc.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   d4bc5378e0..e4004e8e50  e4004e8e505a9ca697b1d5aaee9b3ae25cdc3b21 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 08:01:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 08:01:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMobN-0005Sn-SR; Fri, 10 Apr 2020 08:01:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=jpUU=52=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jMobL-0005Si-QP
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 08:01:23 +0000
X-Inumbo-ID: 778239f0-7b01-11ea-83c2-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 778239f0-7b01-11ea-83c2-12813bfff9fa;
 Fri, 10 Apr 2020 08:01:22 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03A7x6eB075611;
 Fri, 10 Apr 2020 07:59:06 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=subject : to : cc :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type; s=corp-2020-01-29;
 bh=Vn77qQ/QtYjjjSJLX26c89JaXFFW6kj4kfyV1dn80ek=;
 b=Iy/P563WEWlNAwggjq9YimbljE/IPyWi/pnOOfOXuQEOrrMEDAy8F7JZ9WeDBzgvZ6UP
 aI+tyITemHYTKTsxxiRSGKPQ41lPflujP3sN29iKpW4AfW5vvhbWEmmcocJSQy6ZPcvd
 cjorJkufOuTAt49DEwW+YR3nZDIEMa7ci21E8nmrDlESch9p8mfCbdrbwDqAQ0Is3wrS
 J3KUec6u/5xJ/MRrl56eECyLcCWz63ac3bVxrbPp08jpBs0LgPz0pyHyW4cAN44QwSx8
 x/hxsN7ou0rIZV3iOkkGmXnS9B9eqVCoJ4IofaKu3SsWvPYAORsH79wFp7XSdswoZ0es fw== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by userp2120.oracle.com with ESMTP id 309gw4h696-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Apr 2020 07:59:06 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03A7upq3153841;
 Fri, 10 Apr 2020 07:57:01 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by aserp3030.oracle.com with ESMTP id 309ag713n5-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Apr 2020 07:57:01 +0000
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03A7usJ4026272;
 Fri, 10 Apr 2020 07:56:54 GMT
Received: from [10.159.135.41] (/10.159.135.41)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Fri, 10 Apr 2020 00:56:54 -0700
Subject: Re: [RFC PATCH 00/26] Runtime paravirt patching
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 linux-kernel@vger.kernel.org, x86@kernel.org
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <d7f8bff3-526a-6a84-2e81-677cfbac0111@suse.com>
From: Ankur Arora <ankur.a.arora@oracle.com>
Message-ID: <9e35c408-e294-ecb6-d927-ba5e9ca4f41e@oracle.com>
Date: Fri, 10 Apr 2020 00:56:52 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <d7f8bff3-526a-6a84-2e81-677cfbac0111@suse.com>
Content-Type: multipart/mixed; boundary="------------E32DC4ADFA44A8E05F9A4BBF"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 spamscore=0 malwarescore=0
 phishscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004100066
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 priorityscore=1501 bulkscore=0
 phishscore=0 lowpriorityscore=0 impostorscore=0 clxscore=1015
 suspectscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 mlxscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004100066
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, kvm@vger.kernel.org, peterz@infradead.org,
 hpa@zytor.com, virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 bp@alien8.de, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, namit@vmware.com, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is a multi-part message in MIME format.
--------------E32DC4ADFA44A8E05F9A4BBF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

So, first thanks for the quick comments even though some of my choices
were straight NAKs (or maybe because of that!)

Second, I clearly did a bad job of motivating the series. Let me try
to address the motivation comments first and then I can address the
technical concerns separately.

[ I'm collating all the motivation comments below. ]


>> A KVM host (or another hypervisor) might advertise paravirtualized
>> features and optimization hints (ex KVM_HINTS_REALTIME) which might
>> become stale over the lifetime of the guest. For instance, the 

Thomas> If your host changes his advertised behaviour then you want to
Thomas> fix the host setup or find a competent admin.

Juergen> Then this hint is wrong if it can't be guaranteed.

I agree, the hint behaviour is wrong and the host shouldn't be giving
hints it can only temporarily honor.
The host problem is hard to fix though: the behaviour change is
either because of a guest migration or in case of a hosted guest,
cloud economics -- customers want to go to a 2-1 or worse VCPU-CPU
ratio at times of low load.

I had an offline discussion with Paolo Bonzini where he agreed that
it makes sense to make KVM_HINTS_REALTIME a dynamic hint rather than
static as it is now. (That was really the starting point for this
series.)

>> host might go from being undersubscribed to being oversubscribed
>> (or the other way round) and it would make sense for the guest
>> switch pv-ops based on that.

Juergen> I think using pvops for such a feature change is just wrong.
Juergen> What comes next? Using pvops for being able to migrate a guest
Juergen> from an Intel to an AMD machine?

My statement about switching pv-ops was too broadly worded. What
I meant to say was that KVM guests choose pv_lock_ops to be native
or paravirt based on undersubscribed/oversubscribed hint at boot,
and this choice should be available at run-time as well.

KVM chooses between native/paravirt spinlocks at boot based on this
reasoning (from commit b2798ba0b8):
"Waiman Long mentioned that:
> Generally speaking, unfair lock performs well for VMs with a small
> number of vCPUs. Native qspinlock may perform better than pvqspinlock
> if there is vCPU pinning and there is no vCPU over-commitment.
"

PeterZ> So what, the paravirt spinlock stuff works just fine when
PeterZ> you're not oversubscribed.
Yeah, the paravirt spinlocks work fine for both under and oversubscribed
hosts, but they are more expensive and that extra cost provides no benefits
when CPUs are pinned.
For instance, pvqueued spin_unlock() is a call+locked cmpxchg as opposed
to just a movb $0, (%rdi).

This difference shows up in kernbench running on a KVM guest with native
and paravirt spinlocks. I ran with 8 and 64 CPU guests with CPUs pinned.

The native version performs same or better.

8 CPU       Native  (std-dev)  Paravirt (std-dev)
             -----------------  -----------------
-j  4: sys  151.89  ( 0.2462)  160.14   ( 4.8366)    +5.4%
-j 32: sys  162.715 (11.4129)  170.225  (11.1138)    +4.6%
-j  0: sys  164.193 ( 9.4063)  170.843  ( 8.9651)    +4.0%


64 CPU       Native  (std-dev)  Paravirt (std-dev)
             -----------------  -----------------
-j  32: sys 209.448 (0.37009)  210.976   (0.4245)    +0.7%
-j 256: sys 267.401 (61.0928)  285.73   (78.8021)    +6.8%
-j   0: sys 286.313 (56.5978)  307.721  (70.9758)    +7.4%

In all cases the pv_kick, pv_wait numbers were minimal as expected.
The lock_slowpath counts were higher with PV but AFAICS the native
and paravirt lock_slowpath are not directly comparable.

Detailed kernbench numbers attached.

Thanks
Ankur

--------------E32DC4ADFA44A8E05F9A4BBF
Content-Type: text/plain; charset=UTF-8;
 name="8-cpus.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="8-cpus.txt"

OC1jcHUtcGlubmVkLG5hdGl2ZQo9PT09PT09PT09PT09PT09PT0KCkF2ZXJhZ2UgSGFsZiBs
b2FkIC1qIDQgUnVuIChzdGQgZGV2aWF0aW9uKToKRWxhcHNlZCBUaW1lIDMwMy42ODYgKDAu
NzM3NjUyKQpVc2VyIFRpbWUgMTAzMi4yNCAoMi44MTMzKQpTeXN0ZW0gVGltZSAxNTEuODkg
KDAuMjQ2MjcyKQpQZXJjZW50IENQVSAzODkuMiAoMC40NDcyMTQpCkNvbnRleHQgU3dpdGNo
ZXMgMTkzNTAuNCAoODIuMTc4NSkKU2xlZXBzIDEyNTg4NSAoMTQ4LjMzOCkKCkF2ZXJhZ2Ug
T3B0aW1hbCBsb2FkIC1qIDMyIFJ1biAoc3RkIGRldmlhdGlvbik6CkVsYXBzZWQgVGltZSAx
ODcuMDY4ICgwLjM1ODQyNykKVXNlciBUaW1lIDExMzAuMzMgKDEwMy40MDUpClN5c3RlbSBU
aW1lIDE2Mi43MTUgKDExLjQxMjkpClBlcmNlbnQgQ1BVIDU2OS4xICgxODkuNjMzKQpDb250
ZXh0IFN3aXRjaGVzIDE0MzMwMSAoMTMwNjU2KQpTbGVlcHMgMTI2OTM4ICgxMTMyLjgzKQoK
QXZlcmFnZSBNYXhpbWFsIGxvYWQgLWogUnVuIChzdGQgZGV2aWF0aW9uKToKRWxhcHNlZCBU
aW1lIDE4OS4wOTggKDAuMzE2ODEyKQpVc2VyIFRpbWUgMTE2Ni41OSAoOTguNDQ1NCkKU3lz
dGVtIFRpbWUgMTY0LjE5MyAoOS40MDYzKQpQZXJjZW50IENQVSA2MjcuMTMzICgxNzQuMTY5
KQpDb250ZXh0IFN3aXRjaGVzIDIyMjI3MCAoMTU2MDA1KQpTbGVlcHMgMTIyNTYyICg2NDcw
LjkzKQoKOC1jcHUtcGlubmVkLCBwdgo9PT09PT09PT09PT09PT09CgpBdmVyYWdlIEhhbGYg
bG9hZCAtaiA0IFJ1biAoc3RkIGRldmlhdGlvbik6CkVsYXBzZWQgVGltZSAzMDkuODcyICg1
Ljg4MikKVXNlciBUaW1lIDEwNDUuOCAoMTguNTI5NSkKU3lzdGVtIFRpbWUgMTYwLjE0ICg0
LjgzNjY5KQpQZXJjZW50IENQVSAzODguOCAoMC40NDcyMTQpCkNvbnRleHQgU3dpdGNoZXMg
NDEyMTUuNCAoNjc5LjUyMikKU2xlZXBzIDEyMjM2OSAoNDc3LjU5MykKCkF2ZXJhZ2UgT3B0
aW1hbCBsb2FkIC1qIDMyIFJ1biAoc3RkIGRldmlhdGlvbik6CkVsYXBzZWQgVGltZSAxOTAu
MSAoMC4zNzc4MjMpClVzZXIgVGltZSAxMTQ0ICgxMDQuMjQ4KQpTeXN0ZW0gVGltZSAxNzAu
MjI1ICgxMS4xMTM4KQpQZXJjZW50IENQVSA1NjguMiAoMTg5LjEwNykKCkF2ZXJhZ2UgTWF4
aW1hbCBsb2FkIC1qIFJ1biAoc3RkIGRldmlhdGlvbik6CkVsYXBzZWQgVGltZSAxOTEuNjA2
ICgwLjEwODMwNSkKVXNlciBUaW1lIDExNzguODMgKDk3LjkwOCkKU3lzdGVtIFRpbWUgMTcw
Ljg0MyAoOC45NjUxKQpQZXJjZW50IENQVSA2MjUuOCAoMTczLjQ5KQpDb250ZXh0IFN3aXRj
aGVzIDIzNDg3OCAoMTQ5NDc5KQpTbGVlcHMgMTIwNTQyICg2MDczLjc5KQo=
--------------E32DC4ADFA44A8E05F9A4BBF
Content-Type: text/plain; charset=UTF-8;
 name="64-cpus.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="64-cpus.txt"

NjQtY3B1LXBpbm5lZCwgbmF0aXZlCj09PT09PT09PT09PT09PT09PT09PQoKQXZlcmFnZSBI
YWxmIGxvYWQgLWogMzIgUnVuIChzdGQgZGV2aWF0aW9uKToKRWxhcHNlZCBUaW1lIDU0LjMw
NiAoMC4xMzQ4MzMpClVzZXIgVGltZSAxMDcyLjc1ICgxLjM0NTk4KQpTeXN0ZW0gVGltZSAy
MDkuNDQ4ICgwLjM3MDA5NSkKUGVyY2VudCBDUFUgMjM2MC40ICg0LjAzNzMzKQpDb250ZXh0
IFN3aXRjaGVzIDI2OTk5ICg5OS41NDE0KQpTbGVlcHMgMTIyNDA4ICgxODQuODcpCgpBdmVy
YWdlIE9wdGltYWwgbG9hZCAtaiAyNTYgUnVuIChzdGQgZGV2aWF0aW9uKToKRWxhcHNlZCBU
aW1lIDM5LjQyNCAoMC4xNTA1OTkpClVzZXIgVGltZSAxMTQwLjkxICg3MS44NzIyKQpTeXN0
ZW0gVGltZSAyNjcuNDAxICg2MS4wOTI4KQpQZXJjZW50IENQVSAzMTI1LjkgKDgwNi45NikK
Q29udGV4dCBTd2l0Y2hlcyAxMjk2NjIgKDEwODIxNykKU2xlZXBzIDEyMTc2NyAoNjk5LjE5
OCkKCkF2ZXJhZ2UgTWF4aW1hbCBsb2FkIC1qIFJ1biAoc3RkIGRldmlhdGlvbik6CkVsYXBz
ZWQgVGltZSA0MS41NjIgKDAuMjA2MDgzKQpVc2VyIFRpbWUgMTE3NC42OCAoNzUuOTM0MikK
U3lzdGVtIFRpbWUgMjg2LjMxMyAoNTYuNTk3OCkKUGVyY2VudCBDUFUgMzMzOS44NyAoNzE5
LjA2MikKQ29udGV4dCBTd2l0Y2hlcyAyMDM0MjggKDEzODUzNikKU2xlZXBzIDExOTA2NiAo
Mzk5My41OCkKCjY0LWNwdS1waW5uZWQsIHB2Cj09PT09PT09PT09PT09PT0KQXZlcmFnZSBI
YWxmIGxvYWQgLWogMzIgUnVuIChzdGQgZGV2aWF0aW9uKToKRWxhcHNlZCBUaW1lIDU1LjE0
ICgwLjA4OTQ0MjcpClVzZXIgVGltZSAxMDcxLjk5ICgxLjQzMzM1KQpTeXN0ZW0gVGltZSAy
MTAuOTc2ICgwLjQyNDU5NCkKUGVyY2VudCBDUFUgMjMyNiAoNC41Mjc2OSkKQ29udGV4dCBT
d2l0Y2hlcyAzNzU0NC44ICgyMjAuOTY5KQpTbGVlcHMgMTE1NTI3ICg5NC43MTM4KQoKQXZl
cmFnZSBPcHRpbWFsIGxvYWQgLWogMjU2IFJ1biAoc3RkIGRldmlhdGlvbik6CkVsYXBzZWQg
VGltZSA0MC41NCAoMC4yNDY3NzkpClVzZXIgVGltZSAxMTM3LjQxICg2OC45NzczKQpTeXN0
ZW0gVGltZSAyODUuNzMgKDc4LjgwMjEpClBlcmNlbnQgQ1BVIDMwOTAuNyAoODA2LjIxOCkK
Q29udGV4dCBTd2l0Y2hlcyAxMzkwNTkgKDEwNzAwNikKU2xlZXBzIDExNjk2MiAoMTUxOC41
NikKCkF2ZXJhZ2UgTWF4aW1hbCBsb2FkIC1qIFJ1biAoc3RkIGRldmlhdGlvbik6CkVsYXBz
ZWQgVGltZSA0Mi42ODIgKDAuMTcwOTM5KQpVc2VyIFRpbWUgMTE3MS42NCAoNzQuNjY2MykK
U3lzdGVtIFRpbWUgMzA3LjcyMSAoNzAuOTc1OCkKUGVyY2VudCBDUFUgMzMwMy4yNyAoNzE3
LjQxOCkKQ29udGV4dCBTd2l0Y2hlcyAyMTM0MzAgKDEzODYxNikKU2xlZXBzIDExNTE0MyAo
MjkzMC4wMykKCg==
--------------E32DC4ADFA44A8E05F9A4BBF--


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 09:21:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 09:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMpqH-0003SI-AQ; Fri, 10 Apr 2020 09:20:53 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=jpUU=52=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jMpqF-0003SD-KX
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 09:20:51 +0000
X-Inumbo-ID: 90d65fc1-7b0c-11ea-83cd-12813bfff9fa
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 90d65fc1-7b0c-11ea-83cd-12813bfff9fa;
 Fri, 10 Apr 2020 09:20:50 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03A9I03u163963;
 Fri, 10 Apr 2020 09:20:39 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=subject : to : cc :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type : content-transfer-encoding; s=corp-2020-01-29;
 bh=ZiMAGX9H6/bxifsNfICnPVI+DpfXz2fXmOgWWDhAIGs=;
 b=URNDPhpqwrILErIj8YR6JA/6KPolE9057heYVoGx1E2KsMSuczEpoH9lc47r5EdeJrDy
 DS/TvyhTAVOaH30H33Hi7f13yysfKCEhjwv+Ms0wuVMQTj2kPWDM2UJALEXv5y4iMAIZ
 7lWTQLOtyfMnxvX1JQa1XPTqmIrz4hPB3rAp53QiGQmj09X6ehMz+j4zk5gGtlkA/+de
 1L1JstrBp5kNCqKqh4COhvntvlhDwx0A5sw9oDNicIw5j6MsY67lEgUEruQC8O6ZrWd0
 UFoxIEvlVvfzx4AfgalJtTinuJqRmMsJz+32ezG3us8mH88H5KNRPk2vEeEeJb/naXzi 7A== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by aserp2120.oracle.com with ESMTP id 3091m15qc6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Apr 2020 09:20:38 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03A9HfoA078660;
 Fri, 10 Apr 2020 09:18:38 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])
 by aserp3020.oracle.com with ESMTP id 3091mbsyyu-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Apr 2020 09:18:38 +0000
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
 by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03A9IZbe025444;
 Fri, 10 Apr 2020 09:18:35 GMT
Received: from [10.159.147.187] (/10.159.147.187)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Fri, 10 Apr 2020 02:18:35 -0700
Subject: Re: [RFC PATCH 00/26] Runtime paravirt patching
To: Peter Zijlstra <peterz@infradead.org>
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <20200408120856.GY20713@hirez.programming.kicks-ass.net>
From: Ankur Arora <ankur.a.arora@oracle.com>
Message-ID: <99d80ba2-9bc9-143f-0f9a-7178c619a2e2@oracle.com>
Date: Fri, 10 Apr 2020 02:18:33 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200408120856.GY20713@hirez.programming.kicks-ass.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 mlxscore=0
 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004100078
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004100078
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, hpa@zytor.com, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
 virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 namit@vmware.com, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, bp@alien8.de, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 2020-04-08 5:08 a.m., Peter Zijlstra wrote:
> On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote:
>> A KVM host (or another hypervisor) might advertise paravirtualized
>> features and optimization hints (ex KVM_HINTS_REALTIME) which might
>> become stale over the lifetime of the guest. For instance, the
>> host might go from being undersubscribed to being oversubscribed
>> (or the other way round) and it would make sense for the guest
>> switch pv-ops based on that.
> 
> So what, the paravirt spinlock stuff works just fine when you're not
> oversubscribed.
> 
>> We keep an interesting subset of pv-ops (pv_lock_ops only for now,
>> but PV-TLB ops are also good candidates)
> 
> The PV-TLB ops also work just fine when not oversubscribed. IIRC
> kvm_flush_tlb_others() is pretty much the same in that case.
> 
>> in .parainstructions.runtime,
>> while discarding the .parainstructions as usual at init. This is then
>> used for switching back and forth between native and paravirt mode.
>> ([1] lists some representative numbers of the increased memory
>> footprint.)
>>
>> Mechanism: the patching itself is done using stop_machine(). That is
>> not ideal -- text_poke_stop_machine() was replaced with INT3+emulation
>> via text_poke_bp(), but I'm using this to address two issues:
>>   1) emulation in text_poke() can only easily handle a small set
>>   of instructions and this is problematic for inlined pv-ops (and see
>>   a possible alternatives use-case below.)
>>   2) paravirt patching might have inter-dependendent ops (ex.
>>   lock.queued_lock_slowpath, lock.queued_lock_unlock are paired and
>>   need to be updated atomically.)
> 
> And then you hope that the spinlock state transfers.. That is that both
> implementations agree what an unlocked spinlock looks like.
> 
> Suppose the native one was a ticket spinlock, where unlocked means 'head
> == tail' while the paravirt one is a test-and-set spinlock, where
> unlocked means 'val == 0'.
> 
> That just happens to not be the case now, but it was for a fair while.
> 
>> The alternative use-case is a runtime version of apply_alternatives()
>> (not posted with this patch-set) that can be used for some safe subset
>> of X86_FEATUREs. This could be useful in conjunction with the ongoing
>> late microcode loading work that Mihai Carabas and others have been
>> working on.
> 
> The whole late-microcode loading stuff is crazy already; you're making
> it take double bonghits.
That's fair. I was talking in a fairly limited sense, ex making static_cpu_has()
catch up with boot_cpu_has() after a microcode update but I should have
specified that.

> 
>> Also, there are points of similarity with the ongoing static_call work
>> which does rewriting of indirect calls.
> 
> Only in so far as that code patching is involved. An analogy would be
> comparing having a beer with shooting dope. They're both 'drugs'.
I meant closer to updating indirect pointers, like static_call_update()
semantics. But of course I don't know static_call code well enough.

> 
>> The difference here is that
>> we need to switch a group of calls atomically and given that
>> some of them can be inlined, need to handle a wider variety of opcodes.
>>
>> To patch safely we need to satisfy these constraints:
>>
>>   - No references to insn sequences under replacement on any kernel stack
>>     once replacement is in progress. Without this constraint we might end
>>     up returning to an address that is in the middle of an instruction.
> 
> Both ftrace and optprobes have that issue, neither of them are quite as
> crazy as this.
I did look at ftrace. Will look at optprobes. Thanks.

> 
>>   - handle inter-dependent ops: as above, lock.queued_lock_unlock(),
>>     lock.queued_lock_slowpath() and the rest of the pv_lock_ops are
>>     a good example.
> 
> While I'm sure this is a fun problem, why are we solving it?
> 
>>   - handle a broader set of insns than CALL and JMP: some pv-ops end up
>>     getting inlined. Alternatives can contain arbitrary instructions.
> 
> So can optprobes.> 
>>   - locking operations can be called from interrupt handlers which means
>>     we cannot trivially use IPIs for flushing.
> 
> Heck, some NMI handlers use locks..
This does handle the NMI locking problem. The solution -- doing it
in the NMI handler was of course pretty ugly.

>> Handling these, necessitates that target pv-ops not be preemptible.
> 
> I don't think that is a correct inferrence.The non-preemptibility requirement was to ensure that any pv-op under
replacement not be under execution after it is patched out.
(Not a concern for pv_lock_ops.)

Ensuring that we don't return to an address in the middle of an instruction
could be done by moving the NOPs in the prefix, but I couldn't think of
any other way to ensure that a function not be under execution.

Thanks
Ankur

>> Once that is a given (for safety these need to be explicitly whitelisted
>> in runtime_patch()), use a state-machine with the primary CPU doing the
>> patching and secondary CPUs in a sync_core() loop.
>>
>> In case we hit an INT3/BP (in NMI or thread-context) we makes forward
>> progress by continuing the patching instead of emulating.
>>
>> One remaining issue is inter-dependent pv-ops which are also executed in
>> the NMI handler -- patching can potentially deadlock in case of multiple
>> NMIs. Handle these by pushing some of this work in the NMI handler where
>> we know it will be uninterrupted.
> 
> I'm just seeing a lot of bonghits without sane rationale. Why is any of
> this important?
> 


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 09:32:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 09:32:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMq1q-0004Mn-Ej; Fri, 10 Apr 2020 09:32:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=jpUU=52=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jMq1o-0004Mi-MZ
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 09:32:48 +0000
X-Inumbo-ID: 3d14a1ba-7b0e-11ea-83d0-12813bfff9fa
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3d14a1ba-7b0e-11ea-83d0-12813bfff9fa;
 Fri, 10 Apr 2020 09:32:47 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03A9JBhs020013;
 Fri, 10 Apr 2020 09:32:39 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=subject : to : cc :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type : content-transfer-encoding; s=corp-2020-01-29;
 bh=Ums9rtORUoERTp+Sz6iCrEwniL6ascuI/F+Lp1A7/ic=;
 b=CZPq7nfVZcUVlHkIyoJG8scMCIvrBwYLJGNHvjq7v7oPL6CeT692fSrNnI3a4cf/2e2/
 nkiSWISFGfNfUKL1jJCEDin+hLjlnDcSskNlcamFKBCl3E3EJGlVIKWIEhv/4qsgwDtL
 j0SkHd0SRWkTW2Xr8PzQay6ZKoNzIOe/DhrEgcQSSlN4Ri9e0Ywr7iez/9bs1ZJ9yuWV
 jKMAq3d4a8bRDkcHjJYenh75w9qAjdW6WNPuABHlRvA4vmkyyopbQ6HjFngr6TmWNIT5
 F3HZC1+Rwh+W6OyNrHVRY97Gk7P+WeUmZenQutNR7hRUy4/u/W/+hZoa5pDcDvJCtHDn IA== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2120.oracle.com with ESMTP id 309gw4hmbq-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Apr 2020 09:32:39 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03A9HUTx162777;
 Fri, 10 Apr 2020 09:32:39 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userp3030.oracle.com with ESMTP id 3091m6wc8m-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Apr 2020 09:32:39 +0000
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03A9WbL9024236;
 Fri, 10 Apr 2020 09:32:37 GMT
Received: from [10.159.147.187] (/10.159.147.187)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Fri, 10 Apr 2020 02:32:37 -0700
Subject: Re: [RFC PATCH 00/26] Runtime paravirt patching
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 linux-kernel@vger.kernel.org, x86@kernel.org
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <d7f8bff3-526a-6a84-2e81-677cfbac0111@suse.com>
From: Ankur Arora <ankur.a.arora@oracle.com>
Message-ID: <37d755a7-8fc9-8cc8-5627-027a8479b6c7@oracle.com>
Date: Fri, 10 Apr 2020 02:32:35 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <d7f8bff3-526a-6a84-2e81-677cfbac0111@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 mlxlogscore=999 phishscore=0 spamscore=0 adultscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004100078
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 priorityscore=1501 bulkscore=0
 phishscore=0 lowpriorityscore=0 impostorscore=0 clxscore=1015
 suspectscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 mlxscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004100078
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, kvm@vger.kernel.org, peterz@infradead.org,
 hpa@zytor.com, virtualization@lists.linux-foundation.org, pbonzini@redhat.com,
 bp@alien8.de, mhiramat@kernel.org, jpoimboe@redhat.com,
 mihai.carabas@oracle.com, namit@vmware.com, vkuznets@redhat.com,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 2020-04-08 5:28 a.m., Jürgen Groß wrote:
> On 08.04.20 07:02, Ankur Arora wrote:
[ snip ]
> 
> Quite a lot of code churn and hacks for a problem which should not
> occur on a well administrated machine.
Yeah, I agree the patch set is pretty large and clearly the NMI or
the stop_machine() are completely out. That said, as I wrote in my
other mail I think the problem is still worth solving.

> Especially the NMI dependencies make me not wanting to Ack this series.
The NMI solution did turn out to be pretty ugly.

I was using it to solve two problems: avoid a deadlock where an NMI handler
could use a lock while the stop_machine() thread is trying to rewrite the
corresponding call-sites. And, needed to ensure that we don't lock
and unlock using mismatched primitives.


Thanks
Ankur

> 
> 
> Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 09:56:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 09:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMqOQ-00064P-GJ; Fri, 10 Apr 2020 09:56:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=jpUU=52=oracle.com=ankur.a.arora@srs-us1.protection.inumbo.net>)
 id 1jMqOP-00064K-4e
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 09:56:09 +0000
X-Inumbo-ID: 7fb44086-7b11-11ea-b58d-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7fb44086-7b11-11ea-b58d-bc764e2007e4;
 Fri, 10 Apr 2020 09:56:08 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03A9m0PQ019162;
 Fri, 10 Apr 2020 09:55:52 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=subject : to : cc :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type : content-transfer-encoding; s=corp-2020-01-29;
 bh=+j4nVnTBKtnC+KblRX66YHb6IlYtAvRa7OKedO6wFUY=;
 b=n8k8BwVyAZaoxrwteX4mhvLojvFE9ZUqvKNwt1zMTctsor5jugQOkAF/PAA7/PCslOxS
 tf6cRkWb6gaq2FV5AvZqP8gFwqJOReXtF2iU3KTj2fkXtUodavq9RkBpEJdgZfNVor6r
 JfY14be72Wg73Wd2wD7WzNdxINLOcPvCuRIjKQWGclWcqZHSn0OMzldzQLLeA7Mi59uz
 yh/6F+/Sly9WC3OleFcyHPoCP9Ov9+gOtVLHkGQPQ8ICh6NUaAzEDb/whgNlfxv4tZNO
 IMm4zfXsxfCXj+ige65H4YUBDBcP/0T35gmrjTjzOIJhfcu14/l0F9VWEdPQmouPx4SQ NQ== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by aserp2120.oracle.com with ESMTP id 3091m15t4a-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Apr 2020 09:55:52 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03A9lUh6037240;
 Fri, 10 Apr 2020 09:55:52 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userp3030.oracle.com with ESMTP id 3091m6y7tp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Apr 2020 09:55:51 +0000
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03A9tmBN032589;
 Fri, 10 Apr 2020 09:55:48 GMT
Received: from [10.159.147.187] (/10.159.147.187)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Fri, 10 Apr 2020 02:55:47 -0700
Subject: Re: [RFC PATCH 00/26] Runtime paravirt patching
To: Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
 x86@kernel.org
References: <20200408050323.4237-1-ankur.a.arora@oracle.com>
 <87k12qawwl.fsf@nanos.tec.linutronix.de>
From: Ankur Arora <ankur.a.arora@oracle.com>
Message-ID: <c13ce409-790d-18dd-d941-673e9bb797c3@oracle.com>
Date: Fri, 10 Apr 2020 02:55:44 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <87k12qawwl.fsf@nanos.tec.linutronix.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 mlxlogscore=999 phishscore=0 spamscore=0 adultscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004100081
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9586
 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxlogscore=999 mlxscore=0
 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004100081
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 peterz@infradead.org, hpa@zytor.com, virtualization@lists.linux-foundation.org,
 pbonzini@redhat.com, namit@vmware.com, mhiramat@kernel.org,
 jpoimboe@redhat.com, mihai.carabas@oracle.com, bp@alien8.de,
 vkuznets@redhat.com, boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 2020-04-08 7:12 a.m., Thomas Gleixner wrote:
> Ankur Arora <ankur.a.arora@oracle.com> writes:
>> A KVM host (or another hypervisor) might advertise paravirtualized
>> features and optimization hints (ex KVM_HINTS_REALTIME) which might
>> become stale over the lifetime of the guest. For instance, the
>> host might go from being undersubscribed to being oversubscribed
>> (or the other way round) and it would make sense for the guest
>> switch pv-ops based on that.
> 
> If your host changes his advertised behaviour then you want to fix the
> host setup or find a competent admin.
> 
>> This lockorture splat that I saw on the guest while testing this is
>> indicative of the problem:
>>
>>    [ 1136.461522] watchdog: BUG: soft lockup - CPU#8 stuck for 22s! [lock_torture_wr:12865]
>>    [ 1136.461542] CPU: 8 PID: 12865 Comm: lock_torture_wr Tainted: G W L 5.4.0-rc7+ #77
>>    [ 1136.461546] RIP: 0010:native_queued_spin_lock_slowpath+0x15/0x220
>>
>> (Caused by an oversubscribed host but using mismatched native pv_lock_ops
>> on the gues.)
> 
> And this illustrates what? The fact that you used a misconfigured setup.
> 
>> This series addresses the problem by doing paravirt switching at
>> runtime.
> 
> You're not addressing the problem. Your fixing the symptom, which is
> wrong to begin with.
> 
>> The alternative use-case is a runtime version of apply_alternatives()
>> (not posted with this patch-set) that can be used for some safe subset
>> of X86_FEATUREs. This could be useful in conjunction with the ongoing
>> late microcode loading work that Mihai Carabas and others have been
>> working on.
> 
> This has been discussed to death before and there is no safe subset as
> long as this hasn't been resolved:
> 
>    https://lore.kernel.org/lkml/alpine.DEB.2.21.1909062237580.1902@nanos.tec.linutronix.de/
Thanks. I was thinking of fairly limited subset: ex re-evaluate
X86_FEATURE_ALWAYS to make sure static_cpu_has() reflects reality
but I guess that has second order effects here.

Ankur

> 
> Thanks,
> 
>          tglx
> 


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 10:02:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 10:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMqUQ-0006y7-6z; Fri, 10 Apr 2020 10:02:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=aV0t=52=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMqUO-0006y2-MN
 for xen-devel@lists.xen.org; Fri, 10 Apr 2020 10:02:20 +0000
X-Inumbo-ID: 5da6f8de-7b12-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5da6f8de-7b12-11ea-b4f4-bc764e2007e4;
 Fri, 10 Apr 2020 10:02:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=b5m7xqWitjr7zEwfWpyeTn6OUrRAcNRFol6uLJeYYIw=; b=T0J37rmM3ZunVhJg1vVa+1Akqd
 /r1dcRHTig+wiozuoH+g1eObfSrmMWotoc3gnygwZIpema215RTgZIBw1Y6ZjIawzJ7Xm5ooOV/aE
 hdOkKz4jfBv4tv9KSKgZQ9H6FnejnXu044mseNu/WU7eeNrtUfm2xGNDPG4hQcuFg69A=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMqUN-00033h-Oj; Fri, 10 Apr 2020 10:02:19 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMqUN-0007cC-IM; Fri, 10 Apr 2020 10:02:19 +0000
Subject: Re: Make VM save/restore and VM migration work on ARM.
To: Asaf Fisher <asaffisher.dev@gmail.com>, xen-devel@lists.xen.org,
 Stefano Stabellini <sstabellini@kernel.org>
References: <CAHmEStvAQ0SHMYMcS4c43B9uOAU3trvsRJMVtO5CxCr+QXTD9g@mail.gmail.com>
From: Julien Grall <julien@xen.org>
Message-ID: <7938c6e2-f488-70eb-8d17-1b6e23f127e3@xen.org>
Date: Fri, 10 Apr 2020 11:02:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CAHmEStvAQ0SHMYMcS4c43B9uOAU3trvsRJMVtO5CxCr+QXTD9g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 01/04/2020 16:44, Asaf Fisher wrote:
> Hello!

Hello,

Apologies for the late answer.

> Just wonder if this Open Work Item is still available?
> https://wiki.xenproject.org/wiki/Xen_ARM_TODO

Yes, there was some effort in the past but this wasn't yet upstreamed. I 
can point you to the existing work if you are interested to pick-up.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 10:05:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 10:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMqX4-00075C-Lj; Fri, 10 Apr 2020 10:05:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMqX2-000757-Ki
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 10:05:04 +0000
X-Inumbo-ID: bd5ffe76-7b12-11ea-83d4-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bd5ffe76-7b12-11ea-83d4-12813bfff9fa;
 Fri, 10 Apr 2020 10:05:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ebWE5MzUgeaePOjphujDFoXhL0T9e23SjgSAQMdwZm8=; b=u/7+lLAb7N6Zb8Q7jAxjSzUS1
 UeWn4hkjiGviQQlxbP1Aka9tEISkMO7Egwedv8MFCP5hbTfE+hECywNPY5ytBrXJBdsSIgjxWlQF0
 dXCGxnUGEVbmOUA+s8ZBnyqRdHxxzaE8ZrvPUB10+Fd/wPbXfU8HqRXANBx+pu3AXXHLM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMqWy-000363-Qm; Fri, 10 Apr 2020 10:05:00 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMqWy-0000hU-Gs; Fri, 10 Apr 2020 10:05:00 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMqWy-00073U-GA; Fri, 10 Apr 2020 10:05:00 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149559-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149559: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-i386-examine:reboot:fail:regression
 linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-raw:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-armhf-armhf-xl-rtds:guest-stop:fail:allowable
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=5d30bcacd91af6874481129797af364a53cd9b46
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 10:05:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine       8 reboot                   fail REGR. vs. 149238
 test-amd64-i386-xl-pvshim     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 149238
 test-amd64-i386-xl-shadow     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-libvirt-xsm   7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt       7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl            7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-raw        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-xsm        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-freebsd10-i386  7 xen-boot               fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-pair         10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-pair         11 xen-boot/dst_host        fail REGR. vs. 149238

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds     15 guest-stop               fail REGR. vs. 149238

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

version targeted for testing:
 linux                5d30bcacd91af6874481129797af364a53cd9b46
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z   10 days
Failing since        149266  2020-04-01 03:55:53 Z    9 days   12 attempts
Testing same since   149559  2020-04-09 09:56:09 Z    1 days    1 attempts

------------------------------------------------------------
1777 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       fail    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       fail    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    fail    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 11:00:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 11:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMrOW-0003RX-Ef; Fri, 10 Apr 2020 11:00:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMrOU-0003RS-Hl
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 11:00:18 +0000
X-Inumbo-ID: 75d5f132-7b1a-11ea-83e5-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 75d5f132-7b1a-11ea-83e5-12813bfff9fa;
 Fri, 10 Apr 2020 11:00:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=bJvipZhfx5TO6v1tHMCxkA5M/sBNJXIPYUFNkF5/xVQ=; b=Nsk8EZTMx3935MwzSZGtTcPsE
 kLf68eZq+teXsKGCmbjZDdTnCufYBDImDkU43RxeLXa8p/sLwBUxTaVC5Ukv27dIWmv8poAvtM1Io
 3FtHtJqhwG8DUN8seP7GmGap5lVGLfLGFQs2jBQ8khaPGwZZ4Gg6tp8x4Ob4MFbVzLJTg=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMrOS-00049O-6V; Fri, 10 Apr 2020 11:00:16 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMrOR-0003Fc-UQ; Fri, 10 Apr 2020 11:00:16 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMrOR-0007Xa-Tk; Fri, 10 Apr 2020 11:00:15 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149564-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149564: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: qemuu=bb2e2bfc075b62cd6bb46486012d2afa7e59ed5a
X-Osstest-Versions-That: qemuu=f3bac27cc1e303e1860cc55b9b6889ba39dee587
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 11:00:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu                bb2e2bfc075b62cd6bb46486012d2afa7e59ed5a
baseline version:
 qemuu                f3bac27cc1e303e1860cc55b9b6889ba39dee587

Last test of basis   149510  2020-04-08 05:00:53 Z    2 days
Testing same since   149564  2020-04-09 12:36:42 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Max Filippov <jcmvbkbc@gmail.com>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Henderson <richard.henderson@linaro.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   f3bac27cc1..bb2e2bfc07  bb2e2bfc075b62cd6bb46486012d2afa7e59ed5a -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 11:27:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 11:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMroJ-0005Cu-Ms; Fri, 10 Apr 2020 11:26:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=aV0t=52=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMroI-0005Cp-P2
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 11:26:58 +0000
X-Inumbo-ID: 3055487a-7b1e-11ea-83ec-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3055487a-7b1e-11ea-83ec-12813bfff9fa;
 Fri, 10 Apr 2020 11:26:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=KUeTVCdLNng3fF60Gdjp3cnkGW2bzHR6Bi8mwsqtNWc=; b=li+uMMdHOQ7Ut5vqWDJ/yqcRuN
 c/Vs2DxiIBIHARk/Jut8HB46nVFQIhoFDn7mY0Fn4Jz+ifpxPRShMJu4YUkK4TK2cposLes7avnoA
 QMJ1JA1Sg4PFl4/GfKEU6a6a+MEZe4EtLNdBJhoX+ldpk9zD8WgCpI1B2yp7Opwo2fdI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMroF-0004db-U9; Fri, 10 Apr 2020 11:26:55 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMroF-0003sF-ND; Fri, 10 Apr 2020 11:26:55 +0000
Subject: Re: [PATCH v2 3/3] xen/x86: ioapic: Simplify ioapic_init()
To: Jan Beulich <jbeulich@suse.com>
References: <20200404102656.29730-1-julien@xen.org>
 <20200404102656.29730-4-julien@xen.org>
 <a7e761a8-118a-3d84-16a2-5428bc0d22c8@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <56911e1b-8620-de40-72d0-f7ccf50bf97f@xen.org>
Date: Fri, 10 Apr 2020 12:26:53 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <a7e761a8-118a-3d84-16a2-5428bc0d22c8@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 06/04/2020 14:24, Jan Beulich wrote:
> On 04.04.2020 12:26, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> Since commit 9facd54a45 "x86/ioapic: Add register level checks to detect
>> bogus io-apic entries", Xen is able to cope with IO APICs not mapped in
>> the fixmap.
>>
>> Therefore the whole logic to allocate a fake page for some IO APICs is
>> unnecessary.
>>
>> With the logic removed, the code can be simplified a lot as we don't
>> need to go through all the IO APIC if SMP has not been detected or a
>> bogus zero IO-APIC address has been detected.
>>
>> To avoid another level of tabulation, the simplification is now moved in
>> its own function.
>>
>> Signed-off-by: Julien Grall <jgrall@amazon.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thank you! I took the liberty to push them.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 11:28:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 11:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMrpL-0005HX-1C; Fri, 10 Apr 2020 11:28:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=aV0t=52=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMrpJ-0005HO-TN
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 11:28:01 +0000
X-Inumbo-ID: 560036e8-7b1e-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 560036e8-7b1e-11ea-83d8-bc764e2007e4;
 Fri, 10 Apr 2020 11:28:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=g/0yaXsGcoV++GdV2/dhrZhYXRkX4pkr6cgnL0KdZLo=; b=M0W5pHCEvkOwZsO7rx3UpQw7Xa
 8xucXdSE9MbJUtTTglQHvHgGrwN0lSEiXxxrvO3a2oU4EmSPzikdAqizfMEAPjPy+fYar3hOybcHf
 1M2Xy+mzR3TkW/KnRI/DJLi+n1x8o2i4DCuQDCsIGh/21wW/gxuwRVJGU1qnfWfat9vU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMrpH-0004eW-9J; Fri, 10 Apr 2020 11:27:59 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMrpH-0003u1-2c; Fri, 10 Apr 2020 11:27:59 +0000
Subject: Re: preparations for 4.13.1 and 4.12.3
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
 <7ae5179c-8d48-bb83-8250-43a558a04ba5@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <eed12c79-d2e9-d4b9-4440-f5a787003834@xen.org>
Date: Fri, 10 Apr 2020 12:27:57 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7ae5179c-8d48-bb83-8250-43a558a04ba5@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 09/04/2020 08:52, Jürgen Groß wrote:
> On 09.04.20 09:41, Jan Beulich wrote:
>> All,
>>
>> the releases are due in a week or two. Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant. (Ian, I notice there haven't been any
>> tools side backports at all so far. Julien, Stefano - same for
>> Arm.)
>>
>> Jan
>>
> 
> Commit bb2a34fd740e9a26be9e2244f1a5b4cef439e5a8 should be backported
> to both IMO (tools patch).

I was going to suggest this one as well :).

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 11:38:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 11:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMrz9-0006Eg-5p; Fri, 10 Apr 2020 11:38:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=aV0t=52=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMrz7-0006Eb-Hl
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 11:38:09 +0000
X-Inumbo-ID: c0589822-7b1f-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c0589822-7b1f-11ea-b58d-bc764e2007e4;
 Fri, 10 Apr 2020 11:38:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=73ESszSL0YvhVkT76Opw1FgG4bSXlvJZrXBAFzm3Dvo=; b=wLAtsZ5kRIYdK/FdgY0372PYLL
 +3HE7kalKUr+3Ou6fGl0O3zZAUIH0d6VO6+Q5KRpUr/E1nZBGDTPSfds52qOi8YX83+DkP34uJU7t
 YlOjQAOTnrH6UTwmakFufBz5/NNqcPRJO23aEHSRY6lkk+BjhvW9WVhSsc98SgtpfpJ4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMrz5-0004rE-Ps; Fri, 10 Apr 2020 11:38:07 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMrz5-0004de-JT; Fri, 10 Apr 2020 11:38:07 +0000
Subject: Re: preparations for 4.13.1 and 4.12.3
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <86c6ffb6-22d0-cbce-8682-dac37697bbfd@xen.org>
Date: Fri, 10 Apr 2020 12:38:05 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 09/04/2020 08:41, Jan Beulich wrote:
> All,

Hi Jan & Stefano,

> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)

Below a list of suggested backport for Arm for 4.12 and 4.13:

b4637ed6cd5375f04ac51d6b900a9ccad6c6c03a  xen/arm: initialize vpl011 
flag register
b31666c8912bf18d9eff963b06d856e7e818ff34  xen/arm: during efi boot, 
improve the check for usable memory
f14f55b7ee295277c8dd09e37e0fa0902ccf7eb4  xen/arm: remove physical timer 
offset
3c601c5f056fba055b7a1438b84b69fc649275c3  xen/arm: Sign extend 
TimerValue when computing the CompareValue

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 11:56:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 11:56:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMsH6-0007rA-Oe; Fri, 10 Apr 2020 11:56:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=kGWp=52=huawei.com=yuehaibing@srs-us1.protection.inumbo.net>)
 id 1jMsH5-0007r5-FV
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 11:56:43 +0000
X-Inumbo-ID: 5472a7d0-7b22-11ea-9e09-bc764e2007e4
Received: from huawei.com (unknown [45.249.212.35])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5472a7d0-7b22-11ea-9e09-bc764e2007e4;
 Fri, 10 Apr 2020 11:56:39 +0000 (UTC)
Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.60])
 by Forcepoint Email with ESMTP id 036C678809575001BBEA;
 Fri, 10 Apr 2020 19:56:34 +0800 (CST)
Received: from localhost (10.173.223.234) by DGGEMS409-HUB.china.huawei.com
 (10.3.19.209) with Microsoft SMTP Server id 14.3.487.0; Fri, 10 Apr 2020
 19:56:23 +0800
From: YueHaibing <yuehaibing@huawei.com>
To: <boris.ostrovsky@oracle.com>, <jgross@suse.com>, <sstabellini@kernel.org>
Subject: [PATCH -next] xen/pvcalls: Make pvcalls_back_global static
Date: Fri, 10 Apr 2020 19:56:20 +0800
Message-ID: <20200410115620.33024-1-yuehaibing@huawei.com>
X-Mailer: git-send-email 2.10.2.windows.1
MIME-Version: 1.0
Content-Type: text/plain
X-Originating-IP: [10.173.223.234]
X-CFilter-Loop: Reflected
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, YueHaibing <yuehaibing@huawei.com>,
 linux-kernel@vger.kernel.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Fix sparse warning:

drivers/xen/pvcalls-back.c:30:3: warning:
 symbol 'pvcalls_back_global' was not declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/xen/pvcalls-back.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index cf4ce3e9358d..4807704f8d69 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -24,7 +24,7 @@
 #define PVCALLS_VERSIONS "1"
 #define MAX_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
 
-struct pvcalls_back_global {
+static struct pvcalls_back_global {
 	struct list_head frontends;
 	struct semaphore frontends_lock;
 } pvcalls_back_global;
-- 
2.17.1




From xen-devel-bounces@lists.xenproject.org Fri Apr 10 14:06:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 14:06:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMuIf-0001Xv-Gn; Fri, 10 Apr 2020 14:06:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMuIe-0001Xo-JZ
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 14:06:28 +0000
X-Inumbo-ID: 74f4a8ac-7b34-11ea-8420-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 74f4a8ac-7b34-11ea-8420-12813bfff9fa;
 Fri, 10 Apr 2020 14:06:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=eG6K/WxNVO79iRj9y0bf81q/advWi7xa+S7UsM1uC5M=; b=pqKnB04Pv7m5FqC/vlYoiVXbP
 3g1wS0kcb4nGvEsgyjFQW5x3piU/il1figySrdAeTDvvRUSuSljQ8z/oj0nIS0xrnQ6LaLqUe/5za
 w3oCifrf8XuN/HDbvz/6i3Oe1LR/o2godJ5VNMCgNGpTUaA2wjMt1GpoEPtAIi0TXLpQc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMuIX-0007js-Ki; Fri, 10 Apr 2020 14:06:21 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMuIX-00051z-EC; Fri, 10 Apr 2020 14:06:21 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMuIX-0006du-Da; Fri, 10 Apr 2020 14:06:21 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149599-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149599: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=13dcb32b6b585d9a29997e81c0a9610cf1a7f64d
X-Osstest-Versions-That: xen=4fb402b486121c0110dd8cbc2ef2791ab9c1af73
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 14:06:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  13dcb32b6b585d9a29997e81c0a9610cf1a7f64d
baseline version:
 xen                  4fb402b486121c0110dd8cbc2ef2791ab9c1af73

Last test of basis   149568  2020-04-09 15:00:37 Z    0 days
Testing same since   149599  2020-04-10 12:00:31 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4fb402b486..13dcb32b6b  13dcb32b6b585d9a29997e81c0a9610cf1a7f64d -> smoke


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 15:24:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 15:24:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMvW8-0007wY-Al; Fri, 10 Apr 2020 15:24:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=PXqy=52=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jMvW6-0007wT-Ib
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 15:24:26 +0000
X-Inumbo-ID: 5cd1e086-7b3f-11ea-b58d-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5cd1e086-7b3f-11ea-b58d-bc764e2007e4;
 Fri, 10 Apr 2020 15:24:26 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 4565C206F7;
 Fri, 10 Apr 2020 15:24:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586532265;
 bh=YAh7F8xqHYA/YYq63Fw4pG/inlVkd2YY4Y0mqVN0Y9w=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=k70eLZfHUtQ2Pbb5jyVkNmqTFx2MpQUakHbDZZpZWO2N4NBDibqs0LkdKrIzhFHZ3
 Rf30ZtpeU9sXmnwd+wMYlsXOscYDGX4MEWNvnTLSChicge4pmgTiZ6Bm1dGPca4P/s
 iMni8Bwaz8wnaZa4Gw4hCgjc0MW876J1QILgRfBw=
Date: Fri, 10 Apr 2020 08:24:18 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: YueHaibing <yuehaibing@huawei.com>
Subject: Re: [PATCH -next] xen/pvcalls: Make pvcalls_back_global static
In-Reply-To: <20200410115620.33024-1-yuehaibing@huawei.com>
Message-ID: <alpine.DEB.2.21.2004100824020.19608@sstabellini-ThinkPad-T480s>
References: <20200410115620.33024-1-yuehaibing@huawei.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
 sstabellini@kernel.org, linux-kernel@vger.kernel.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 10 Apr 2020, YueHaibing wrote:
> Fix sparse warning:
> 
> drivers/xen/pvcalls-back.c:30:3: warning:
>  symbol 'pvcalls_back_global' was not declared. Should it be static?
> 
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  drivers/xen/pvcalls-back.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> index cf4ce3e9358d..4807704f8d69 100644
> --- a/drivers/xen/pvcalls-back.c
> +++ b/drivers/xen/pvcalls-back.c
> @@ -24,7 +24,7 @@
>  #define PVCALLS_VERSIONS "1"
>  #define MAX_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
>  
> -struct pvcalls_back_global {
> +static struct pvcalls_back_global {
>  	struct list_head frontends;
>  	struct semaphore frontends_lock;
>  } pvcalls_back_global;
> -- 
> 2.17.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 15:48:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 15:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMvtk-0001I4-Hx; Fri, 10 Apr 2020 15:48:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=GzMl=52=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMvtj-0001Hz-FM
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 15:48:51 +0000
X-Inumbo-ID: c5dffd30-7b42-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c5dffd30-7b42-11ea-b58d-bc764e2007e4;
 Fri, 10 Apr 2020 15:48:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=MbjZiJT4MsHufnABM9++cHzByJdCSvF0l4Esc+wq8YE=; b=sxRA2SjCj5SwXMktMdh6bBSmo1
 JIMO0bkQJet9MXbjHmUQ6U9z0O1VS0g+Ex5nVqKnL7ZKGCFIRcEB9DaGA3PhLewzqmwD1M5OE/CFd
 sY8p7y8zLzdATtuAuo9iecqOWLI3JmFTs7kNoFtSO6bSIB9FwOYyg+6P/uaSJ8NvRTI4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMvte-0001DV-DN; Fri, 10 Apr 2020 15:48:46 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMvte-00032J-3T; Fri, 10 Apr 2020 15:48:46 +0000
Date: Fri, 10 Apr 2020 16:48:43 +0100
From: Wei Liu <wl@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200410154843.ocpl4gpqt5hsifba@debian>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
> On 06.04.2020 12:57, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
> >              p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
> >                                    p2m_ram_rw, p2m_ram_logdirty);
> >  
> > -            flush_tlb_mask(d->dirty_cpumask);
> > +            hap_flush_tlb_mask(d->dirty_cpumask);
> >  
> >              memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
> >          }
> > @@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
> >           * to be read-only, or via hardware-assisted log-dirty.
> >           */
> >          p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> > -        flush_tlb_mask(d->dirty_cpumask);
> > +        hap_flush_tlb_mask(d->dirty_cpumask);
> >      }
> >      return 0;
> >  }
> > @@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
> >       * be read-only, or via hardware-assisted log-dirty.
> >       */
> >      p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> > -    flush_tlb_mask(d->dirty_cpumask);
> > +    hap_flush_tlb_mask(d->dirty_cpumask);
> >  }
> >  
> >  /************************************************/
> > @@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
> >  
> >      safe_write_pte(p, new);
> >      if ( old_flags & _PAGE_PRESENT )
> > -        flush_tlb_mask(d->dirty_cpumask);
> > +        hap_flush_tlb_mask(d->dirty_cpumask);
> >  
> >      paging_unlock(d);
> >  
> 
> Following up on my earlier mail about paging_log_dirty_range(), I'm
> now of the opinion that all of these flushes should go away too. I
> can only assume that they got put where they are when HAP code was
> cloned from the shadow one. These are only p2m operations, and hence
> p2m level TLB flushing is all that's needed here.
> 
> > --- a/xen/arch/x86/mm/hap/nested_hap.c
> > +++ b/xen/arch/x86/mm/hap/nested_hap.c
> > @@ -84,7 +84,7 @@ nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
> >      safe_write_pte(p, new);
> >  
> >      if (old_flags & _PAGE_PRESENT)
> > -        flush_tlb_mask(p2m->dirty_cpumask);
> > +        hap_flush_tlb_mask(p2m->dirty_cpumask);
> 
> Same here then presumably.
> 
> As suggested in my earlier reply, the plain removals of flush
> invocations would probably better be split out into a separate
> patch.
> 
> > --- a/xen/arch/x86/mm/hap/private.h
> > +++ b/xen/arch/x86/mm/hap/private.h
> > @@ -47,4 +47,9 @@ unsigned long hap_p2m_ga_to_gfn_4_levels(struct vcpu *v,
> >      struct p2m_domain *p2m, unsigned long cr3,
> >      paddr_t ga, uint32_t *pfec, unsigned int *page_order);
> >  
> > +static inline void hap_flush_tlb_mask(const cpumask_t *mask)
> > +{
> > +    flush_mask(mask, FLUSH_HVM_ASID_CORE);
> > +}
> 
> With the above introduction of this would then become unnecessary.

I had planned to make the required adjustment(s) and commit v9 today.
But seeing your comment it appears v10 is warranted.

Wei.

> 
> Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 16:06:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 16:06:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMwAo-0003QB-3T; Fri, 10 Apr 2020 16:06:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Kp13=52=gmail.com=tamas.k.lengyel@srs-us1.protection.inumbo.net>)
 id 1jMwAm-0003Q4-HP
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 16:06:28 +0000
X-Inumbo-ID: 3bae40e2-7b45-11ea-9e09-bc764e2007e4
Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3bae40e2-7b45-11ea-9e09-bc764e2007e4;
 Fri, 10 Apr 2020 16:06:27 +0000 (UTC)
Received: by mail-wm1-x342.google.com with SMTP id x25so2933106wmc.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Apr 2020 09:06:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=TPw51Hof7zADERBFMw1m8fWmcFJDPsgUk+pPk9vhUPs=;
 b=Er0c+Mx2GIMRfslXl8xRXJd1YQb4BR5MRYFlO3akAI2gU5NY2UTofP4qEuZcOMFMTf
 uRR89lm73mUZN2KLwYzQE9mPqlhq4qy/gxPASLYYFecqgFzYXqM9OUEyN9Bw7B4gNBhm
 IeTxeypLF4Q2sEaidIsGyNlxGE3gIKTxxOD7Kyj1SFFkxfVG1spQryl/mGZcfBwahPz/
 z8ee+4OF96XV+PHw121Sp7D+AeHVdEUOYB6pqCpFj+YQhL+0FhG2d49r3m9UWetHTsd4
 bJMMD5EPLb6ngs1rZOBczMzFuKEmMvUYgFdHIoWP7rnaoNyI6urt/LPC896YyWeOLmhv
 00wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=TPw51Hof7zADERBFMw1m8fWmcFJDPsgUk+pPk9vhUPs=;
 b=Xalwbhfydm2bEBODCCEJKZ2BdQGRjhO3pqIV5czFbHekiLkjL8UX9z4Ef0f4jpcQfx
 GrqSNbIRKb59DC2HzuGBF96aLnBmvdsSIynPEsHoGxp4qnBbHpwRd4HlTtzSLLtfz/91
 5sqsZFp82b7P2VarSf1vMBX50RBaRi05IttyLlv/U8ZoAJ37wNfL4UXZCvbADJYyarju
 p+zFv+BDZwUK764pQ4EMNdIwLJa2Jy1m8hXT2ZhsShxSjEY/0oodla7god7LaBuOPuY7
 qTtArFIGs+CERUqoroHuF0t9Qdyfm1S/bh9mLEx6z049wIuv8xZmWG67ygEyRrDrp9jn
 OaVw==
X-Gm-Message-State: AGi0PuZuiDUzRzxd9lbdDTtBWbTp8s5Jb/p0RzW4Px/R4SIiRBY+Hhof
 FaIQUdhhQPjTZOfknhSthk0Kkflk5C12R1o70Bo=
X-Google-Smtp-Source: APiQypLe8lMWqD2OCW/uTg6gryuaIWhhqRiEMyuTw2rXlbR2F8efn6bwcXgho2Oge022h3rWwVdupiWjKKxAxviCt0I=
X-Received: by 2002:a1c:3105:: with SMTP id x5mr6120914wmx.51.1586534786823;
 Fri, 10 Apr 2020 09:06:26 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1586186121.git.tamas.lengyel@intel.com>
 <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
 <20200409154243.6ouh7r37fwm32mjg@debian>
 <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
 <20200409162159.cb2h7a6tmkbaduay@debian>
 <CABfawhnaDS=nGn3+NqoY_nWXvu0cfsAmpYjiv9VqkT6C0Ow1FA@mail.gmail.com>
 <20200409171113.cajvhjlftadqqq73@debian>
 <CABfawhmdSdC2kKzE5jLLCtkR9Pb4mcT6iRdzv0s=v0mQiju_Kg@mail.gmail.com>
In-Reply-To: <CABfawhmdSdC2kKzE5jLLCtkR9Pb4mcT6iRdzv0s=v0mQiju_Kg@mail.gmail.com>
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Date: Fri, 10 Apr 2020 10:05:50 -0600
Message-ID: <CABfawhnw2O6GPXEwk0-vAkAVpwn95F-pcpahOpQUo23Luz7eFg@mail.gmail.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
To: Wei Liu <wl@xen.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 9, 2020 at 11:30 AM Tamas K Lengyel
<tamas.k.lengyel@gmail.com> wrote:
>
> On Thu, Apr 9, 2020 at 11:11 AM Wei Liu <wl@xen.org> wrote:
> >
> > On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> > [...]
> > > >
> > > > >
> > > > > > >
> > > > > > > +/*
> > > > > > > + * The parent domain is expected to be created with default settings for
> > > > > > > + * - max_evtch_port
> > > > > > > + * - max_grant_frames
> > > > > > > + * - max_maptrack_frames
> > > > > > > + */
> > > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> > > > > > > +{
> > > > > > > +    int rc;
> > > > > > > +    struct xen_domctl_createdomain create = {0};
> > > > > > > +    create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > > +    create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > > +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > > +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > > > > > +    create.ssidref = SECINITSID_DOMU;
> > > > > > > +    create.max_vcpus = max_vcpus;
> > > > > >
> > > > > >
> > > > > > Some questions:
> > > > > >
> > > > > > Why does the caller need to specify the number of vcpus?
> > > > > >
> > > > > > Since the parent (source) domain is around, can you retrieve its domain
> > > > > > configuration such that you know its max_vcpus and other information
> > > > > > including max_evtchn_port and maptrack frames?
> > > > >
> > > > > Because we want to avoid having to issue an extra hypercall for these.
> > > > > Normally these pieces of information will be available for the user
> > > > > and won't change, so we save time by not querying for it every time a
> > > > > fork is created. Remember, we might be creating thousands of forks in
> > > > > a very short time, so those extra hypercalls add up.
> > > >
> > > > I see. Speed is a big concern to you.
> > > >
> > > > What I was referring to doesn't require issuing hypercalls but requires
> > > > calling libxl_retrieve_domain_configuration. That's likely to be even
> > > > slower than making a hypercall.
> > >
> > > Right. We only want to parse the domain config if the device model is
> > > being launched.
> > >
> > > >
> > > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> > > > supported (as in Xen's support statement) going forward, because it is
> > > > leaky.
> > >
> > > What do you mean by leaky?
> >
> > It requires the caller to specify the number of max_vcpus. The reason
> > for doing that is because you want to avoid extra hypercall(s). There is
> > nothing that stops someone from coming along in the future claiming some
> > other parameters are required because of the same concern you have
> > today. It is an optimisation, not a must-have in terms of functionality.
> >
> > To me the number shouldn't be specified by the caller in the first
> > place. It is like forking a process somehow requires you to specify how
> > many threads it will have.
>
> I agree. It's not how I wanted to have the interface work but
> unfortunately this was the least "ugly" of the possible solutions
> given the circumstances.

By the way, it would be trivial to query the parent in case max_vcpus
is not provided by the user. But I would still like to keep the option
available to skip that step if the number is known already. Let me
know if you would like me to add that.

Thanks,
Tamas


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 16:19:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 16:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMwNA-0004Ku-9z; Fri, 10 Apr 2020 16:19:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=GzMl=52=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jMwN8-0004Kp-LP
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 16:19:14 +0000
X-Inumbo-ID: 048c0340-7b47-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 048c0340-7b47-11ea-83d8-bc764e2007e4;
 Fri, 10 Apr 2020 16:19:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=bDuCXj6Cx3wsUo3dxC/aTCJROiZb6qW1qvw0uxTljl8=; b=DCddFyGiPCcxL9xILYKo+2wVIM
 8sR1umK3vMYWZqReEJObF4iuFuWZQCDRUB0YpsJdYvYhJ+5Y2u/VAAr/ca0E5dD7zy8wfWivAsLAl
 NHAZXj+gqaIzKhFCry8i8V5Xu4vuqelXn1TDMN9aQaknij+IV6m/25bZ7rFcvWbFVdvY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMwN3-0002Kc-6J; Fri, 10 Apr 2020 16:19:09 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jMwN2-00058T-Tf; Fri, 10 Apr 2020 16:19:09 +0000
Date: Fri, 10 Apr 2020 17:19:06 +0100
From: Wei Liu <wl@xen.org>
To: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
Message-ID: <20200410161906.tjonj2btem5nqkpp@debian>
References: <cover.1586186121.git.tamas.lengyel@intel.com>
 <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
 <20200409154243.6ouh7r37fwm32mjg@debian>
 <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
 <20200409162159.cb2h7a6tmkbaduay@debian>
 <CABfawhnaDS=nGn3+NqoY_nWXvu0cfsAmpYjiv9VqkT6C0Ow1FA@mail.gmail.com>
 <20200409171113.cajvhjlftadqqq73@debian>
 <CABfawhmdSdC2kKzE5jLLCtkR9Pb4mcT6iRdzv0s=v0mQiju_Kg@mail.gmail.com>
 <CABfawhnw2O6GPXEwk0-vAkAVpwn95F-pcpahOpQUo23Luz7eFg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABfawhnw2O6GPXEwk0-vAkAVpwn95F-pcpahOpQUo23Luz7eFg@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 10, 2020 at 10:05:50AM -0600, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 11:30 AM Tamas K Lengyel
> <tamas.k.lengyel@gmail.com> wrote:
> >
> > On Thu, Apr 9, 2020 at 11:11 AM Wei Liu <wl@xen.org> wrote:
> > >
> > > On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> > > [...]
> > > > >
> > > > > >
> > > > > > > >
> > > > > > > > +/*
> > > > > > > > + * The parent domain is expected to be created with default settings for
> > > > > > > > + * - max_evtch_port
> > > > > > > > + * - max_grant_frames
> > > > > > > > + * - max_maptrack_frames
> > > > > > > > + */
> > > > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> > > > > > > > +{
> > > > > > > > +    int rc;
> > > > > > > > +    struct xen_domctl_createdomain create = {0};
> > > > > > > > +    create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > > > +    create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > > > +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > > > +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > > > > > > +    create.ssidref = SECINITSID_DOMU;
> > > > > > > > +    create.max_vcpus = max_vcpus;
> > > > > > >
> > > > > > >
> > > > > > > Some questions:
> > > > > > >
> > > > > > > Why does the caller need to specify the number of vcpus?
> > > > > > >
> > > > > > > Since the parent (source) domain is around, can you retrieve its domain
> > > > > > > configuration such that you know its max_vcpus and other information
> > > > > > > including max_evtchn_port and maptrack frames?
> > > > > >
> > > > > > Because we want to avoid having to issue an extra hypercall for these.
> > > > > > Normally these pieces of information will be available for the user
> > > > > > and won't change, so we save time by not querying for it every time a
> > > > > > fork is created. Remember, we might be creating thousands of forks in
> > > > > > a very short time, so those extra hypercalls add up.
> > > > >
> > > > > I see. Speed is a big concern to you.
> > > > >
> > > > > What I was referring to doesn't require issuing hypercalls but requires
> > > > > calling libxl_retrieve_domain_configuration. That's likely to be even
> > > > > slower than making a hypercall.
> > > >
> > > > Right. We only want to parse the domain config if the device model is
> > > > being launched.
> > > >
> > > > >
> > > > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> > > > > supported (as in Xen's support statement) going forward, because it is
> > > > > leaky.
> > > >
> > > > What do you mean by leaky?
> > >
> > > It requires the caller to specify the number of max_vcpus. The reason
> > > for doing that is because you want to avoid extra hypercall(s). There is
> > > nothing that stops someone from coming along in the future claiming some
> > > other parameters are required because of the same concern you have
> > > today. It is an optimisation, not a must-have in terms of functionality.
> > >
> > > To me the number shouldn't be specified by the caller in the first
> > > place. It is like forking a process somehow requires you to specify how
> > > many threads it will have.
> >
> > I agree. It's not how I wanted to have the interface work but
> > unfortunately this was the least "ugly" of the possible solutions
> > given the circumstances.
> 
> By the way, it would be trivial to query the parent in case max_vcpus
> is not provided by the user. But I would still like to keep the option
> available to skip that step if the number is known already. Let me
> know if you would like me to add that.

I'm still waiting for Ian and Anthony to chime in to see whether they
agree to keep this interface unstable.

At the end of the day, if it is unstable, I don't really care that much.
I'm happy to let you (the developer and user) have more say in that
case.  I will instead divert my (limited) time to code that your patch
touches which is also used by other stable functions.

Wei.

> 
> Thanks,
> Tamas


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 16:21:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 16:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMwPI-00054S-No; Fri, 10 Apr 2020 16:21:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Kp13=52=gmail.com=tamas.k.lengyel@srs-us1.protection.inumbo.net>)
 id 1jMwPH-00054M-EI
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 16:21:27 +0000
X-Inumbo-ID: 534a388a-7b47-11ea-b58d-bc764e2007e4
Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 534a388a-7b47-11ea-b58d-bc764e2007e4;
 Fri, 10 Apr 2020 16:21:26 +0000 (UTC)
Received: by mail-wm1-x341.google.com with SMTP id e26so2939489wmk.5
 for <xen-devel@lists.xenproject.org>; Fri, 10 Apr 2020 09:21:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=cnMzUHdiTqnOVirdhY4+hp8JnHcBsGj3wbW2WQ7nszs=;
 b=LZMwwox8qZbuYFAwd9kVhKNUyecvbcCKdJvYiNdPMixoeHhbWOnLVPLqHuq96f0wkh
 VQqc61CS9MJJmOPgM9+vpqIw6rSP4IwcqbfCsWIQrhcAO6mxXCHcEXMItl0UelMAsRI2
 IxPRvZCMd2oHSWfL19pGLg3PCTTBOy0ate1UeS0QrWii8cPycnEgp6N+5I8b46FnwQ3/
 c51K8vFTzXlbdBfR4B9UUp5at2S0+zt60N9xdGQCRhTVl6GKIN43xUNeB+6FbZz2SMCX
 CVAs31nX86RRecwAxF1hW6f9b8ko136HOB+YjxKuu7m8DzJxvOpubdcd6WPRC2ctSFMH
 3REg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=cnMzUHdiTqnOVirdhY4+hp8JnHcBsGj3wbW2WQ7nszs=;
 b=PxxuaFfel0LyhEPS//vLQg0mwSvPYSyBi0EYYtg2aMZPgJI5/ttQJYzGDjeAAUNQWC
 rF3GX4E6HeHDl0GgPmTLdtGr1Yh1cFk/nMIzNbz9oDpfeCw9aoAINQ6UuSeDIkxKEgdB
 FBLbe7/+OZzKS8Fcr8/fz5CbingDNuJF+MccPsoczMy7HfpFpaxhjRrENRzozC6bmiDQ
 JYTXdiJuytr3p2mF29QEUQArwu/yIDEdd0UnE9c9RcDfaVytQZkkGAITR4slEkDYqn1U
 z5eaz7Dl7L3qT7DrAWpEWsJXxheTdfFtsTKcxqM0mclSo8wgWrOuupQWOmpmmoZuU8Fx
 3Y+g==
X-Gm-Message-State: AGi0PuZ+sNckOpWJDYw6CWrvW7ROAXW5yDA6avXmBMJMNrxAJ7WMVQ8M
 V4WR2SYGcJkYnEk7AoDaEkv87ZOIPNSYA5LTqP4=
X-Google-Smtp-Source: APiQypJgKYyjw3S8e8Nnx7QeHF3q9wjfColeTyQ9dALPXT1oFGkHLgBwXD0R/k63tCxJBDaat3VgW3lwZgYA4Y/2MgE=
X-Received: by 2002:a1c:4c10:: with SMTP id z16mr5916107wmf.77.1586535685453; 
 Fri, 10 Apr 2020 09:21:25 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1586186121.git.tamas.lengyel@intel.com>
 <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
 <20200409154243.6ouh7r37fwm32mjg@debian>
 <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
 <20200409162159.cb2h7a6tmkbaduay@debian>
 <CABfawhnaDS=nGn3+NqoY_nWXvu0cfsAmpYjiv9VqkT6C0Ow1FA@mail.gmail.com>
 <20200409171113.cajvhjlftadqqq73@debian>
 <CABfawhmdSdC2kKzE5jLLCtkR9Pb4mcT6iRdzv0s=v0mQiju_Kg@mail.gmail.com>
 <CABfawhnw2O6GPXEwk0-vAkAVpwn95F-pcpahOpQUo23Luz7eFg@mail.gmail.com>
 <20200410161906.tjonj2btem5nqkpp@debian>
In-Reply-To: <20200410161906.tjonj2btem5nqkpp@debian>
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Date: Fri, 10 Apr 2020 10:20:49 -0600
Message-ID: <CABfawhn2=-WiEyT--Z-h-mYBSc2uwU8X7VGaTmc6GRzOAEXzLQ@mail.gmail.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
To: Wei Liu <wl@xen.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 10, 2020 at 10:19 AM Wei Liu <wl@xen.org> wrote:
>
> On Fri, Apr 10, 2020 at 10:05:50AM -0600, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 11:30 AM Tamas K Lengyel
> > <tamas.k.lengyel@gmail.com> wrote:
> > >
> > > On Thu, Apr 9, 2020 at 11:11 AM Wei Liu <wl@xen.org> wrote:
> > > >
> > > > On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> > > > [...]
> > > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > +/*
> > > > > > > > > + * The parent domain is expected to be created with default settings for
> > > > > > > > > + * - max_evtch_port
> > > > > > > > > + * - max_grant_frames
> > > > > > > > > + * - max_maptrack_frames
> > > > > > > > > + */
> > > > > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> > > > > > > > > +{
> > > > > > > > > +    int rc;
> > > > > > > > > +    struct xen_domctl_createdomain create = {0};
> > > > > > > > > +    create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > > > > +    create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > > > > +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > > > > +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > > > > > > > +    create.ssidref = SECINITSID_DOMU;
> > > > > > > > > +    create.max_vcpus = max_vcpus;
> > > > > > > >
> > > > > > > >
> > > > > > > > Some questions:
> > > > > > > >
> > > > > > > > Why does the caller need to specify the number of vcpus?
> > > > > > > >
> > > > > > > > Since the parent (source) domain is around, can you retrieve its domain
> > > > > > > > configuration such that you know its max_vcpus and other information
> > > > > > > > including max_evtchn_port and maptrack frames?
> > > > > > >
> > > > > > > Because we want to avoid having to issue an extra hypercall for these.
> > > > > > > Normally these pieces of information will be available for the user
> > > > > > > and won't change, so we save time by not querying for it every time a
> > > > > > > fork is created. Remember, we might be creating thousands of forks in
> > > > > > > a very short time, so those extra hypercalls add up.
> > > > > >
> > > > > > I see. Speed is a big concern to you.
> > > > > >
> > > > > > What I was referring to doesn't require issuing hypercalls but requires
> > > > > > calling libxl_retrieve_domain_configuration. That's likely to be even
> > > > > > slower than making a hypercall.
> > > > >
> > > > > Right. We only want to parse the domain config if the device model is
> > > > > being launched.
> > > > >
> > > > > >
> > > > > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> > > > > > supported (as in Xen's support statement) going forward, because it is
> > > > > > leaky.
> > > > >
> > > > > What do you mean by leaky?
> > > >
> > > > It requires the caller to specify the number of max_vcpus. The reason
> > > > for doing that is because you want to avoid extra hypercall(s). There is
> > > > nothing that stops someone from coming along in the future claiming some
> > > > other parameters are required because of the same concern you have
> > > > today. It is an optimisation, not a must-have in terms of functionality.
> > > >
> > > > To me the number shouldn't be specified by the caller in the first
> > > > place. It is like forking a process somehow requires you to specify how
> > > > many threads it will have.
> > >
> > > I agree. It's not how I wanted to have the interface work but
> > > unfortunately this was the least "ugly" of the possible solutions
> > > given the circumstances.
> >
> > By the way, it would be trivial to query the parent in case max_vcpus
> > is not provided by the user. But I would still like to keep the option
> > available to skip that step if the number is known already. Let me
> > know if you would like me to add that.
>
> I'm still waiting for Ian and Anthony to chime in to see whether they
> agree to keep this interface unstable.
>
> At the end of the day, if it is unstable, I don't really care that much.
> I'm happy to let you (the developer and user) have more say in that
> case.  I will instead divert my (limited) time to code that your patch
> touches which is also used by other stable functions.

SGTM

Thanks,
Tamas


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 16:35:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 16:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMwd8-0006Ed-PL; Fri, 10 Apr 2020 16:35:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMwd6-0006EY-T9
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 16:35:44 +0000
X-Inumbo-ID: 524107aa-7b49-11ea-845a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 524107aa-7b49-11ea-845a-12813bfff9fa;
 Fri, 10 Apr 2020 16:35:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=itT+dRX4mPgJ/XeGU+pRPVH3FVzudovy5KI0PfG3aF4=; b=bsPV/BjtrkY08MzbstxZ41erl
 4lMipj3C23PX9wj4eioYye4440HCUSvHr4Weocth3POTQsC9cAel2g3pGZBrXjys5yjAzPEUVDIhj
 MezYR0lHK5DbSrvX3I9L0JuTT3NtEGMhWJDaeat2yvudUuIQgoDQ4M/wU34A0OvsPEoFs=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMwd4-0002ex-Sb; Fri, 10 Apr 2020 16:35:42 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMwd4-0006C8-Ic; Fri, 10 Apr 2020 16:35:42 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMwd4-0007B1-I0; Fri, 10 Apr 2020 16:35:42 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149565-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149565: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:debian-hvm-install:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:debian-hvm-install:fail:heisenbug
 xen-unstable:test-armhf-armhf-xl-rtds:guest-start:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=9be0b2747bc7381c684cfbdd3fa2e40badefbeef
X-Osstest-Versions-That: xen=990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 16:35:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail in 149547 pass in 149565
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail in 149547 pass in 149565
 test-armhf-armhf-xl-rtds     12 guest-start                fail pass in 149547

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     16 guest-localmigrate  fail in 149547 like 149478
 test-armhf-armhf-xl-rtds    13 migrate-support-check fail in 149547 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 149547 never pass
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149431
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149478
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149478
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149478
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149478
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149478
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149478
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149478
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149478
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149478
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  9be0b2747bc7381c684cfbdd3fa2e40badefbeef
baseline version:
 xen                  990b6e38d93c6e60f9d81e8b71ddfd209fca00bd

Last test of basis   149478  2020-04-07 01:51:22 Z    3 days
Failing since        149502  2020-04-08 00:06:59 Z    2 days    4 attempts
Testing same since   149547  2020-04-09 02:36:26 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Julien Grall <jgrall@amazon.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   990b6e38d9..9be0b2747b  9be0b2747bc7381c684cfbdd3fa2e40badefbeef -> master


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 16:37:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 16:37:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMweZ-0006KT-5x; Fri, 10 Apr 2020 16:37:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=PXqy=52=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jMweY-0006KM-Qi
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 16:37:14 +0000
X-Inumbo-ID: 888a97c2-7b49-11ea-83d8-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 888a97c2-7b49-11ea-83d8-bc764e2007e4;
 Fri, 10 Apr 2020 16:37:14 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 98BE820769;
 Fri, 10 Apr 2020 16:37:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586536633;
 bh=5PS9fYIZDPDoLe+uz2ZQEmHmHiSdkQspw450gTNWdbM=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=VJRmePrBvXI8TCXivjL7StG5JYI6ck+HVHkozi7pLdtzcwDDp209h84iWc0le6if/
 PeZ6Qa9KaUvpVjNQ5RHEIK3SOGx927wx0hz4bkaMq+ltfXIL+1okr8OTqKFtKvLIGV
 q2sASmkee9Qg5JJDQpMTB9k6jlUERFmXVS6ATtHw=
Date: Fri, 10 Apr 2020 09:37:13 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>, jbeulich@suse.com
Subject: Re: preparations for 4.13.1 and 4.12.3
In-Reply-To: <86c6ffb6-22d0-cbce-8682-dac37697bbfd@xen.org>
Message-ID: <alpine.DEB.2.21.2004100926350.19608@sstabellini-ThinkPad-T480s>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
 <86c6ffb6-22d0-cbce-8682-dac37697bbfd@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Ian Jackson <ian.jackson@citrix.com>,
 Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 10 Apr 2020, Julien Grall wrote:
> On 09/04/2020 08:41, Jan Beulich wrote:
> > All,
> 
> Hi Jan & Stefano,
> 
> > the releases are due in a week or two. Please point out backports
> > you find missing from the respective staging branches, but which
> > you consider relevant. (Ian, I notice there haven't been any
> > tools side backports at all so far. Julien, Stefano - same for
> > Arm.)
> 
> Below a list of suggested backport for Arm for 4.12 and 4.13:
> 
> b4637ed6cd5375f04ac51d6b900a9ccad6c6c03a  xen/arm: initialize vpl011 flag
> register
> b31666c8912bf18d9eff963b06d856e7e818ff34  xen/arm: during efi boot, improve
> the check for usable memory
> f14f55b7ee295277c8dd09e37e0fa0902ccf7eb4  xen/arm: remove physical timer
> offset
> 3c601c5f056fba055b7a1438b84b69fc649275c3  xen/arm: Sign extend TimerValue when
> computing the CompareValue


Thanks! I did these four and also the following:

69da7d5440c609c57c5bba9a73b91c62ba2852e6 xen/arm: Handle unimplemented VGICv3 registers as RAZ/WI



Jan,

I think the following could be a good candidate. It also touches x86 so
I thought I should ask you.

6827bea2b3b99153821b8b7446bdced27f720188 dom0-build: fix build with clang5


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 16:49:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 16:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMwqm-0007Lk-LN; Fri, 10 Apr 2020 16:49:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=PXqy=52=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jMwql-0007Lf-3A
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 16:49:51 +0000
X-Inumbo-ID: 4a0bc00c-7b4b-11ea-845b-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4a0bc00c-7b4b-11ea-845b-12813bfff9fa;
 Fri, 10 Apr 2020 16:49:50 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id EB7E720769;
 Fri, 10 Apr 2020 16:49:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586537389;
 bh=NMyKX9Vm5M/+ytGCVt+HkWqn+19KHLHUeuCyTsgRHlM=;
 h=From:To:Cc:Subject:Date:From;
 b=uA+q4ygfO0274XjDCULhgww7Ac4ysWw4MHcR/hQfhkRuq39SjMsSKBYjyKa1HNB5X
 qRHi2GqI7UhsB6vF0QWRUfXAWgxM4r2fYGPcBtgeNWtuj1QPs2uvgxbsM5ZrIwWN2t
 CWfgdyx8sJVebVYxInki81zZQNrli/Uf1/qcjwqE=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2] Introduce a description of a new optional tag for Backports
Date: Fri, 10 Apr 2020 09:49:42 -0700
Message-Id: <20200410164942.9747-1-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, sstabellini@kernel.org, julien@xen.org,
 konrad.wilk@oracle.com, andrew.cooper3@citrix.com, george.dunlap@citrix.com,
 jbeulich@suse.com, Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Create a new document under docs/process to describe our special tags.
For now, only add the new backport tag.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wl@xen.org>
CC: jbeulich@suse.com
CC: george.dunlap@citrix.com
CC: julien@xen.org
CC: lars.kurth@citrix.com
CC: andrew.cooper3@citrix.com
CC: konrad.wilk@oracle.com

---

This is the original thread: https://marc.info/?l=xen-devel&m=157324027614941

The backport tag was agreed upon. George requested the file to be
renamed to something more generic, where we could add more information
later.

I kept the original content and acked-by. I renamed the file to
tags.pandoc.
---
 docs/process/tags.pandoc | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 docs/process/tags.pandoc

diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
new file mode 100644
index 0000000000..e570efdcc8
--- /dev/null
+++ b/docs/process/tags.pandoc
@@ -0,0 +1,23 @@
+Backport Tag
+------------
+
+A backport tag is an optional tag in the commit message to request a
+given commit to be backported to the stable trees:
+
+    Backport: all
+
+It marks a commit for being a candidate for backports to all relevant
+trees.
+
+    Backport: 4.9+
+
+It marks a commit for being a candidate for backports to all stable
+trees from 4.9 onward.
+
+Maintainers request the Backport tag to be added on commit.
+Contributors are also welcome to mark their patches with the Backport
+tag when they deem appropriate. Maintainers will request for it to be
+removed when that is not the case.
+
+Please note that the Backport tag is a **request** for backport, which
+will still need to be evaluated by the stable tree maintainers.
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 10 16:51:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 16:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMwrx-00083a-1E; Fri, 10 Apr 2020 16:51:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMwrv-00083T-2k
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 16:51:03 +0000
X-Inumbo-ID: 72e50f0e-7b4b-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 72e50f0e-7b4b-11ea-b58d-bc764e2007e4;
 Fri, 10 Apr 2020 16:50:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=acKjyXD6C+OZpBBfa+z2rDf3KUiwvVM4A5A1/7MLve8=; b=NCrwhQt7n/YCZxSNz0WUY0AlX
 Pn9Vbgv3pkXDx4rwagf9gznLrBnRZb1spWI7yGxHFPZet3MVsyjllA8k0q0PUC5afIggrZvqeZVOT
 Z4qEQe5mRarPyZDY2J5Zn6wD+QUTK5CKNWzsaluZwW34U4boRiVogR8UJGoQslr09ErXc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMwro-0002xd-LV; Fri, 10 Apr 2020 16:50:56 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMwro-000756-CZ; Fri, 10 Apr 2020 16:50:56 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMwro-0000v3-Bs; Fri, 10 Apr 2020 16:50:56 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149590-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149590: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=967f4eebdcfed014fb8ad4569e9a04cdc731e9a6
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 16:50:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              967f4eebdcfed014fb8ad4569e9a04cdc731e9a6
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   84 days
Failing since        146211  2020-01-18 04:18:52 Z   83 days   80 attempts
Testing same since   149590  2020-04-10 04:19:50 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 14316 lines long.)


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 17:35:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 17:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMxYy-000306-KD; Fri, 10 Apr 2020 17:35:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMxYx-000301-EM
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 17:35:31 +0000
X-Inumbo-ID: ab9ed4be-7b51-11ea-8484-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ab9ed4be-7b51-11ea-8484-12813bfff9fa;
 Fri, 10 Apr 2020 17:35:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Sgx/Qi1l36NXzxpskBUHotRbmUdG7xg4v25IJwGnO6A=; b=wZuahQfNLYInynhpTli//bWar
 P1pFDD6/6nVoWI+sxgpsYSqkTXeb3L4QrMSjD69q1cIUAoa5iSLgTNLbx+oXjdNiCJdKZLfqkKtKg
 SmgtS46lIzVVU3kQJ1xdGyk2apJwpaYLpTGKO/SS0Gw+dTkt0Jkql6kBZHmrBHbqD3oYw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMxYu-0003o2-Qs; Fri, 10 Apr 2020 17:35:28 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMxYu-00016a-FW; Fri, 10 Apr 2020 17:35:28 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMxYu-0003j1-EL; Fri, 10 Apr 2020 17:35:28 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149602-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149602: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
X-Osstest-Versions-That: xen=13dcb32b6b585d9a29997e81c0a9610cf1a7f64d
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 17:35:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3
baseline version:
 xen                  13dcb32b6b585d9a29997e81c0a9610cf1a7f64d

Last test of basis   149599  2020-04-10 12:00:31 Z    0 days
Testing same since   149602  2020-04-10 15:01:12 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Tamas K Lengyel <tamas@tklengyel.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   13dcb32b6b..7372466b21  7372466b21c3b6c96bb7a52754e432bac883a1e3 -> smoke


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 17:52:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 17:52:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMxou-0004dC-7x; Fri, 10 Apr 2020 17:52:00 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=aV0t=52=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMxos-0004d7-UK
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 17:51:58 +0000
X-Inumbo-ID: f916e9d2-7b53-11ea-848c-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f916e9d2-7b53-11ea-848c-12813bfff9fa;
 Fri, 10 Apr 2020 17:51:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ABR9blzkQkfLbEGXMOr+wFV/u+UvWq0fc0fLjKHJPBU=; b=g7NG9yDOT8RPAbVbXL8OmgEd/0
 JjkJy8EKxKbZwwTDSXqX6bJlrc354eYQWR68TFzBHc344Q2v0mTyjw3+5XutsrWlKB/4xQsUoMEc2
 KotKqUSyrb6W8x59b/dqASgYblXg1LqDDJ9gQmWNbClKK9IqisZgmnKqR2yw81Cfgc6o=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMxon-000479-TD; Fri, 10 Apr 2020 17:51:53 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMxon-0002kL-FB; Fri, 10 Apr 2020 17:51:53 +0000
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20200410164942.9747-1-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <2e4f1b20-34fa-dd77-9dcc-648be406119e@xen.org>
Date: Fri, 10 Apr 2020 18:51:50 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200410164942.9747-1-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
 george.dunlap@citrix.com, jbeulich@suse.com,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Stefano,

On 10/04/2020 17:49, Stefano Stabellini wrote:
> Create a new document under docs/process to describe our special tags.
> For now, only add the new backport tag.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Acked-by: Wei Liu <wl@xen.org>

Acked-by: Julien Grall <jgrall@amazon.com>

It would be good to get an ack by from Jan as he is the maintainer for 
stable's branch.

Cheers,

> CC: jbeulich@suse.com
> CC: george.dunlap@citrix.com
> CC: julien@xen.org
> CC: lars.kurth@citrix.com
> CC: andrew.cooper3@citrix.com
> CC: konrad.wilk@oracle.com
> 
> ---
> 
> This is the original thread: https://marc.info/?l=xen-devel&m=157324027614941
> 
> The backport tag was agreed upon. George requested the file to be
> renamed to something more generic, where we could add more information
> later.
> 
> I kept the original content and acked-by. I renamed the file to
> tags.pandoc.
> ---
>   docs/process/tags.pandoc | 23 +++++++++++++++++++++++
>   1 file changed, 23 insertions(+)
>   create mode 100644 docs/process/tags.pandoc
> 
> diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
> new file mode 100644
> index 0000000000..e570efdcc8
> --- /dev/null
> +++ b/docs/process/tags.pandoc
> @@ -0,0 +1,23 @@
> +Backport Tag
> +------------
> +
> +A backport tag is an optional tag in the commit message to request a
> +given commit to be backported to the stable trees:
> +
> +    Backport: all
> +
> +It marks a commit for being a candidate for backports to all relevant
> +trees.
> +
> +    Backport: 4.9+
> +
> +It marks a commit for being a candidate for backports to all stable
> +trees from 4.9 onward.
> +
> +Maintainers request the Backport tag to be added on commit.
> +Contributors are also welcome to mark their patches with the Backport
> +tag when they deem appropriate. Maintainers will request for it to be
> +removed when that is not the case.
> +
> +Please note that the Backport tag is a **request** for backport, which
> +will still need to be evaluated by the stable tree maintainers.
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 17:54:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 17:54:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMxrJ-0004jf-Ly; Fri, 10 Apr 2020 17:54:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=aV0t=52=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jMxrI-0004jX-4r
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 17:54:28 +0000
X-Inumbo-ID: 520643ee-7b54-11ea-848c-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 520643ee-7b54-11ea-848c-12813bfff9fa;
 Fri, 10 Apr 2020 17:54:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/sNfJL63uebK9Fb+NoDdGH3FuUqqSE6D3BXp4IAxY5o=; b=TqN471cWYq/q20V+5P4PPE6oCM
 BcyrZKwHNggj1Y/qHoBXQnoFufaBRmtyDoPZwPujZjZIiPtC0RHA+QkDJ2ac+0Dh9IX+ESy3HG6Fb
 Lyt6zpGNo2wlu6QFzaWY0mhwmQbsj1pfHi50C0prm07ClUCfiuAU1sTerydWz0OKVuVY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMxrG-0004AP-FR; Fri, 10 Apr 2020 17:54:26 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jMxrG-0002rr-9M; Fri, 10 Apr 2020 17:54:26 +0000
Subject: Re: preparations for 4.13.1 and 4.12.3
To: Stefano Stabellini <sstabellini@kernel.org>, jbeulich@suse.com
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
 <86c6ffb6-22d0-cbce-8682-dac37697bbfd@xen.org>
 <alpine.DEB.2.21.2004100926350.19608@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <cb32ed05-072f-87a9-a6ed-83a9062df5a5@xen.org>
Date: Fri, 10 Apr 2020 18:54:24 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004100926350.19608@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Stefano,

On 10/04/2020 17:37, Stefano Stabellini wrote:
> On Fri, 10 Apr 2020, Julien Grall wrote:
>> On 09/04/2020 08:41, Jan Beulich wrote:
>>> All,
>>
>> Hi Jan & Stefano,
>>
>>> the releases are due in a week or two. Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant. (Ian, I notice there haven't been any
>>> tools side backports at all so far. Julien, Stefano - same for
>>> Arm.)
>>
>> Below a list of suggested backport for Arm for 4.12 and 4.13:
>>
>> b4637ed6cd5375f04ac51d6b900a9ccad6c6c03a  xen/arm: initialize vpl011 flag
>> register
>> b31666c8912bf18d9eff963b06d856e7e818ff34  xen/arm: during efi boot, improve
>> the check for usable memory
>> f14f55b7ee295277c8dd09e37e0fa0902ccf7eb4  xen/arm: remove physical timer
>> offset
>> 3c601c5f056fba055b7a1438b84b69fc649275c3  xen/arm: Sign extend TimerValue when
>> computing the CompareValue
> 
> 
> Thanks! I did these four and also the following:
> 
> 69da7d5440c609c57c5bba9a73b91c62ba2852e6 xen/arm: Handle unimplemented VGICv3 registers as RAZ/WI

I saw it and forgot to add it in the list :$.

> 
> 
> 
> Jan,
> 
> I think the following could be a good candidate. It also touches x86 so
> I thought I should ask you.
> 
> 6827bea2b3b99153821b8b7446bdced27f720188 dom0-build: fix build with clang5

If we are backporting build fixes for newer compilers, shouldn't we 
backport all of them?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 18:16:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 18:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMyCN-0006Uw-NS; Fri, 10 Apr 2020 18:16:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMyCM-0006Ur-Tm
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 18:16:14 +0000
X-Inumbo-ID: 5bb20417-7b57-11ea-849b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5bb20417-7b57-11ea-849b-12813bfff9fa;
 Fri, 10 Apr 2020 18:16:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=+kcJGcr9SaCmwmdLYFFQCcPWCQSt/shGyZuY3KvkRvU=; b=XFdUmDrevEcg7Iic/uzWouTQk
 D/mSCba1m0/L1VrhZJu6iKdwqXjPg3sklG8OmUvIxH1qqFmA+mImd/zw0vhwtn3txQ4zm8vkgfX78
 sCNzV9rR+a+EIP5FHtCqzuGMiCuessk+Ce4ATankbHUM+YQN12SoOENOhdXLMfvB50Oz0=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMyCK-0004mu-1r; Fri, 10 Apr 2020 18:16:12 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMyCJ-0002Iz-LC; Fri, 10 Apr 2020 18:16:11 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMyCJ-0006Fb-KV; Fri, 10 Apr 2020 18:16:11 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149583-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.12-testing test] 149583: regressions - FAIL
X-Osstest-Failures: xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-saverestore.2:fail:regression
 xen-4.12-testing:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:heisenbug
 xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=c1a1c4e8fb54038aee36305531426da4e3ad3872
X-Osstest-Versions-That: xen=824bdb432fc8831ee4684e45361a78faee4548ed
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 18:16:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2    16 guest-saverestore.2      fail REGR. vs. 148185

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail pass in 149554

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 xen                  c1a1c4e8fb54038aee36305531426da4e3ad3872
baseline version:
 xen                  824bdb432fc8831ee4684e45361a78faee4548ed

Last test of basis   148185  2020-03-06 18:13:31 Z   34 days
Testing same since   149554  2020-04-09 07:42:33 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  George Dunlap <george.dunlap@citrix.com>
  Igor Druzhinin <igor.druzhinin@citrix.com>
  Jan Beulich <jbeulich@suse.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          fail    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit c1a1c4e8fb54038aee36305531426da4e3ad3872
Author: Dario Faggioli <dfaggioli@suse.com>
Date:   Thu Apr 9 09:36:51 2020 +0200

    credit2: fix credit reset happening too few times
    
    There is a bug in commit 5e4b4199667b9 ("xen: credit2: only reset
    credit on reset condition"). In fact, the aim of that commit was to
    make sure that we do not perform too many credit reset operations
    (which are not super cheap, and in an hot-path). But the check used
    to determine whether a reset is necessary was the wrong one.
    
    In fact, knowing just that some vCPUs have been skipped, while
    traversing the runqueue (in runq_candidate()), is not enough. We
    need to check explicitly whether the first vCPU in the runqueue
    has a negative amount of credit.
    
    Since a trace record is changed, this patch updates xentrace format file
    and xenalyze as well
    
    This should be backported.
    
    Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
    Acked-by: George Dunlap <george.dunlap@citrix.com>
    master commit: dae7b62e976b28af9c8efa150618c25501bf1650
    master date: 2020-04-03 10:46:53 +0200

commit 4c69d1c2dbe0ad1f5343852d9e596fe870892a6c
Author: Dario Faggioli <dfaggioli@suse.com>
Date:   Thu Apr 9 09:36:08 2020 +0200

    credit2: avoid vCPUs to ever reach lower credits than idle
    
    There have been report of stalls of guest vCPUs, when Credit2 was used.
    It seemed like these vCPUs were not getting scheduled for very long
    time, even under light load conditions (e.g., during dom0 boot).
    
    Investigations led to the discovery that --although rarely-- it can
    happen that a vCPU manages to run for very long timeslices. In Credit2,
    this means that, when runtime accounting happens, the vCPU will lose a
    large quantity of credits. This in turn may lead to the vCPU having less
    credits than the idle vCPUs (-2^30). At this point, the scheduler will
    pick the idle vCPU, instead of the ready to run vCPU, for a few
    "epochs", which often times is enough for the guest kernel to think the
    vCPU is not responding and crashing.
    
    An example of this situation is shown here. In fact, we can see d0v1
    sitting in the runqueue while all the CPUs are idle, as it has
    -1254238270 credits, which is smaller than -2^30 = −1073741824:
    
        (XEN) Runqueue 0:
        (XEN)   ncpus              = 28
        (XEN)   cpus               = 0-27
        (XEN)   max_weight         = 256
        (XEN)   pick_bias          = 22
        (XEN)   instload           = 1
        (XEN)   aveload            = 293391 (~111%)
        (XEN)   idlers: 00,00000000,00000000,00000000,00000000,00000000,0fffffff
        (XEN)   tickled: 00,00000000,00000000,00000000,00000000,00000000,00000000
        (XEN)   fully idle cores: 00,00000000,00000000,00000000,00000000,00000000,0fffffff
        [...]
        (XEN) Runqueue 0:
        (XEN) CPU[00] runq=0, sibling=00,..., core=00,...
        (XEN) CPU[01] runq=0, sibling=00,..., core=00,...
        [...]
        (XEN) CPU[26] runq=0, sibling=00,..., core=00,...
        (XEN) CPU[27] runq=0, sibling=00,..., core=00,...
        (XEN) RUNQ:
        (XEN)     0: [0.1] flags=0 cpu=5 credit=-1254238270 [w=256] load=262144 (~100%)
    
    We certainly don't want, under any circumstance, this to happen.
    Let's, therefore, define a minimum amount of credits a vCPU can have.
    During accounting, we make sure that, for however long the vCPU has
    run, it will never get to have less than such minimum amount of
    credits. Then, we set the credits of the idle vCPU to an even
    smaller value.
    
    NOTE: investigations have been done about _how_ it is possible for a
    vCPU to execute for so much time that its credits becomes so low. While
    still not completely clear, there are evidence that:
    - it only happens very rarely,
    - it appears to be both machine and workload specific,
    - it does not look to be a Credit2 (e.g., as it happens when
      running with Credit1 as well) issue, or a scheduler issue.
    
    This patch makes Credit2 more robust to events like this, whatever
    the cause is, and should hence be backported (as far as possible).
    
    Reported-by: Glen <glenbarney@gmail.com>
    Reported-by: Tomas Mozes <hydrapolic@gmail.com>
    Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
    Reviewed-by: George Dunlap <george.dunlap@citrix.com>
    master commit: 36f3662f27dec32d76c0edb4c6b62b9628d6869d
    master date: 2020-04-03 10:45:43 +0200

commit 9a082e14c66947f0acc4ca05d563b76a50571638
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Apr 9 09:35:24 2020 +0200

    x86/ucode/amd: Fix more potential buffer overruns with microcode parsing
    
    cpu_request_microcode() doesn't know the buffer is at least 4 bytes long
    before inspecting UCODE_MAGIC.
    
    install_equiv_cpu_table() doesn't know the boundary of the buffer it is
    interpreting as an equivalency table.  This case was clearly observed at one
    point in the past, given the subsequent overrun detection, but without
    comprehending that the damage was already done.
    
    Make the logic consistent with container_fast_forward() and pass size_left in
    to install_equiv_cpu_table().
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    master commit: 718d1432000079ea7120f6cb770372afe707ce27
    master date: 2020-04-01 14:00:12 +0100

commit e282e87f151adab1b269cafc404e0f554d896a45
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Apr 9 09:34:19 2020 +0200

    x86/HVM: fix AMD ECS handling for Fam10
    
    The involved comparison was, very likely inadvertently, converted from
    >= to > when making changes unrelated to the actual family range.
    
    Fixes: 9841eb71ea87 ("x86/cpuid: Drop a guests cached x86 family and model information")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    master commit: 5d515b1c296ebad6889748ea1e49e063453216a3
    master date: 2020-04-01 12:28:30 +0200

commit f3264407d0feadd948359242ac346567d8afa23a
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Apr 9 09:33:20 2020 +0200

    x86/ucode/amd: Fix potential buffer overrun with equiv table handling
    
    find_equiv_cpu_id() loops until it finds a 0 installed_cpu entry.  Well formed
    AMD microcode containers have this property.
    
    Extend the checking in install_equiv_cpu_table() to reject tables which don't
    have a sentinal at the end.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    master commit: 1f97b6b9f1b5978659c5735954c37c130e7bb151
    master date: 2020-03-27 13:13:26 +0000

commit 736c67bc46a333b24a9b0ffc902768ab96505ad6
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Apr 9 09:32:36 2020 +0200

    libx86/CPUID: fix (not just) leaf 7 processing
    
    x86_cpuid_policy_fill_native() should, as it did originally, iterate
    over all subleaves here as well as over all main leaves. Switch to
    using a "<= MIN()"-based approach similar to that used in
    x86_cpuid_copy_to_buffer(). Also follow this for the extended main
    leaves then.
    
    Fixes: 1bd2b750537b ("libx86: Fix 32bit stubdom build of x86_cpuid_policy_fill_native()")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: eb0bad81fceb3e81df5f73441771b49b732edf56
    master date: 2020-03-27 11:40:59 +0100

commit 94f0bb7c3ff63b7322849cd80ed0d6c2b9998ee4
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Apr 9 09:31:45 2020 +0200

    x86/ucode: Fix error paths in apply_microcode()
    
    In the unlikley case that patch application completes, but the resutling
    revision isn't expected, sig->rev doesn't get updated to match reality.
    
    It will get adjusted the next time collect_cpu_info() gets called, but in the
    meantime Xen might operate on a stale value.  Nothing good will come of this.
    
    Rewrite the logic to always update the stashed revision, before worrying about
    whether the attempt was a success or failure.
    
    Take the opportunity to make the printk() messages as consistent as possible.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    master commit: d2a0a96cf76603b2e2b87c3ce80c3f9d098327d4
    master date: 2020-03-26 18:57:45 +0000

commit 4c187457d1890067350c1770b84b75cea1d97214
Author: Igor Druzhinin <igor.druzhinin@citrix.com>
Date:   Thu Apr 9 09:30:58 2020 +0200

    x86/shim: fix ballooning up the guest
    
    args.preempted is meaningless here as it doesn't signal whether the
    hypercall was preempted before. Use start_extent instead which is
    correct (as long as the hypercall was invoked in a "normal" way).
    
    Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
    master commit: 76dbabb59eeaa78e9f57407e5b15a6606488333e
    master date: 2020-03-18 12:55:54 +0100

commit 3c37292c844a23beffc802192600386e2ea6888c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Apr 9 09:30:14 2020 +0200

    x86/vPMU: don't blindly assume IA32_PERF_CAPABILITIES MSR exists
    
    Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
    be consulted first.
    
    Reported-by: Farrah Chen <farrah.chen@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 15c39c7c913f26fba40231e103ce1ffa6101e7c9
    master date: 2020-02-26 17:35:48 +0100

commit 813757cf12eab38f3f86fc76a59d9e11749b4b27
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Apr 9 09:29:00 2020 +0200

    AMD/IOMMU: fix off-by-one in amd_iommu_get_paging_mode() callers
    
    amd_iommu_get_paging_mode() expects a count, not a "maximum possible"
    value. Prior to b4f042236ae0 dropping the reference, the use of our mis-
    named "max_page" in amd_iommu_domain_init() may have lead to such a
    misunderstanding. In an attempt to avoid such confusion in the future,
    rename the function's parameter and - while at it - convert it to an
    inline function.
    
    Also replace a literal 4 by an expression tying it to a wider use
    constant, just like amd_iommu_quarantine_init() does.
    
    Fixes: ea38867831da ("x86 / iommu: set up a scratch page in the quarantine domain")
    Fixes: b4f042236ae0 ("AMD/IOMMU: Cease using a dynamic height for the IOMMU pagetables")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: b75b3c62fe4afe381c6f74a07f614c0b39fe2f5d
    master date: 2020-03-16 11:24:29 +0100
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Fri Apr 10 19:01:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Apr 2020 19:01:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jMyuL-000254-GN; Fri, 10 Apr 2020 19:01:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fqfT=52=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jMyuJ-00024x-Ud
 for xen-devel@lists.xenproject.org; Fri, 10 Apr 2020 19:01:39 +0000
X-Inumbo-ID: b1dffde2-7b5d-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b1dffde2-7b5d-11ea-b4f4-bc764e2007e4;
 Fri, 10 Apr 2020 19:01:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=nMV9uS6Rbhe2sbUYCOfNnqKkkmzVZc7aN/na9X8B4Fg=; b=6Hh5DPGx6JkZ6fuYiO7t12dex
 ad4he52DfgV8aL/t5GjixbtcM7FWVMcztjp/Cq5+Y+/u9dby01/p1/2NpMzIIn1LEz2kLdk7jj7+r
 OEd3Ifh6GZ/NuqBCzXlgu8joOfdI0cOMY0Z270eriPByJP+AAOcwKwGWm95xvVSb0mWk8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMyuD-0005tg-8M; Fri, 10 Apr 2020 19:01:33 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jMyuC-000420-Vg; Fri, 10 Apr 2020 19:01:33 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jMyuC-0007FB-V4; Fri, 10 Apr 2020 19:01:32 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149594-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149594: all pass - PUSHED
X-Osstest-Versions-This: ovmf=a5d8a399635d86c8155a252874fbf3c0e6613d34
X-Osstest-Versions-That: ovmf=e4004e8e505a9ca697b1d5aaee9b3ae25cdc3b21
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 10 Apr 2020 19:01:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

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

Last test of basis   149560  2020-04-09 10:09:22 Z    1 days
Testing same since   149594  2020-04-10 07:41:48 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Leendert van Doorn <leendert@microsoft.com>
  Leif Lindholm <leif@nuviainc.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   e4004e8e50..a5d8a39963  a5d8a399635d86c8155a252874fbf3c0e6613d34 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 01:20:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 01:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jN4ov-0001cj-VD; Sat, 11 Apr 2020 01:20:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+Nm9=53=kernel.org=pr-tracker-bot@srs-us1.protection.inumbo.net>)
 id 1jN4ou-0001ce-9O
 for xen-devel@lists.xenproject.org; Sat, 11 Apr 2020 01:20:28 +0000
X-Inumbo-ID: a01e3c6a-7b92-11ea-b4f4-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a01e3c6a-7b92-11ea-b4f4-bc764e2007e4;
 Sat, 11 Apr 2020 01:20:27 +0000 (UTC)
Subject: Re: [GIT PULL] xen: branch for v5.7-rc1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586568026;
 bh=iqJZVbs51UGDnqdGVU5/jtBGKszBWnavKyMrnA8OuoI=;
 h=From:In-Reply-To:References:Date:To:Cc:From;
 b=na8C7w3eu94yAlZRV/XZDZ4vkGtwQTzLcgHTuiJpmuCdK015QDUFgXNp1IAOsNJO9
 YX9rgxTmvjl7kiPx2sS6nOYrmBKmuzzDCkJwm/P5G5bHU8/dEPN6TCFYNTinWpQxjr
 SBwR8ZgDKErH4YZfQHutm7Paf4oX0ZrV23/Q3jSA=
From: pr-tracker-bot@kernel.org
In-Reply-To: <20200410062430.20949-1-jgross@suse.com>
References: <20200410062430.20949-1-jgross@suse.com>
X-PR-Tracked-List-Id: <linux-kernel.vger.kernel.org>
X-PR-Tracked-Message-Id: <20200410062430.20949-1-jgross@suse.com>
X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
 for-linus-5.7-rc1b-tag
X-PR-Tracked-Commit-Id: d6f34f4c6b4a962eb7a86c923fea206f866a40be
X-PR-Merge-Tree: torvalds/linux.git
X-PR-Merge-Refname: refs/heads/master
X-PR-Merge-Commit-Id: e6383b185a998861cadb2f95d97cfe29945b9c32
Message-Id: <158656802668.16442.9324878577683276685.pr-tracker-bot@kernel.org>
Date: Sat, 11 Apr 2020 01:20:26 +0000
To: Juergen Gross <jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
 torvalds@linux-foundation.org, linux-kernel@vger.kernel.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The pull request you sent on Fri, 10 Apr 2020 08:24:30 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.7-rc1b-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e6383b185a998861cadb2f95d97cfe29945b9c32

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 01:20:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 01:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jN4ol-0001cP-Mt; Sat, 11 Apr 2020 01:20:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=bNzu=53=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jN4ok-0001cK-HM
 for xen-devel@lists.xenproject.org; Sat, 11 Apr 2020 01:20:18 +0000
X-Inumbo-ID: 969c146e-7b92-11ea-84fc-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 969c146e-7b92-11ea-84fc-12813bfff9fa;
 Sat, 11 Apr 2020 01:20:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=yafl0yIDJeTTR5kj4UBcu579Lr6CcNcrU8CGRlQBFpI=; b=rsPzdT1ajMyvyAiy66yV2t42w
 viv8p2RB/dR62SlSa9hpZgo3ggIIcYUyVH7f2oRmiI5HcHsvON30X560lqBLkPt43MwABotPG14rm
 QeoSe4D4vE/7d4epFXg1Q478xn5R094gaEjeOyg2ndWiL4SP9rYBi36WdFC8iCEYA9PsQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jN4oc-0001Ex-Po; Sat, 11 Apr 2020 01:20:10 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jN4oc-0004w3-BD; Sat, 11 Apr 2020 01:20:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jN4oc-00031d-AU; Sat, 11 Apr 2020 01:20:10 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149598-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149598: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=8bac3ba57eecc466b7e73dabf7d19328a59f684e
X-Osstest-Versions-That: qemuu=bb2e2bfc075b62cd6bb46486012d2afa7e59ed5a
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 11 Apr 2020 01:20:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149564

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

version targeted for testing:
 qemuu                8bac3ba57eecc466b7e73dabf7d19328a59f684e
baseline version:
 qemuu                bb2e2bfc075b62cd6bb46486012d2afa7e59ed5a

Last test of basis   149564  2020-04-09 12:36:42 Z    1 days
Testing same since   149598  2020-04-10 11:02:26 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Peter Maydell <peter.maydell@linaro.org>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  Richard Henderson <richard.henderson@linaro.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   bb2e2bfc07..8bac3ba57e  8bac3ba57eecc466b7e73dabf7d19328a59f684e -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 03:21:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 03:21:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jN6i5-00039r-HC; Sat, 11 Apr 2020 03:21:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=bNzu=53=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jN6i4-00039m-8P
 for xen-devel@lists.xenproject.org; Sat, 11 Apr 2020 03:21:32 +0000
X-Inumbo-ID: 8502a55e-7ba3-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8502a55e-7ba3-11ea-83d8-bc764e2007e4;
 Sat, 11 Apr 2020 03:21:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=J84OmpOQhDQa3V4oq7n94usWrK362X/MgRsj+RglYzg=; b=0HI6RgSnjev2LOJQkcdAV3rzk
 EELdIsxCRrnqkqwXs7ZpP0Vg95zBhtEIafFhZEFaqJyz4+fXl8zdNyjvH6N4Aek7W3RIC0gav4kmj
 dfufU/b92Plz2vtotMkVZlACYVytNgNZCI1HEyA8YJlr9n1HjHlhrSXVPgHOUqY16a+UU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jN6hu-0003v6-Mj; Sat, 11 Apr 2020 03:21:22 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jN6hu-0005BR-Fq; Sat, 11 Apr 2020 03:21:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jN6hu-0007KO-FC; Sat, 11 Apr 2020 03:21:22 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149596-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149596: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-i386-examine:reboot:fail:regression
 linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-libvirt-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-raw:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:xen-boot:fail:regression
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-xsm:xen-boot:fail:regression
 linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:xen-boot:fail:regression
 linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:xen-boot:fail:regression
 linux-linus:test-amd64-amd64-libvirt:guest-saverestore:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/src_host:fail:regression
 linux-linus:test-amd64-i386-pair:xen-boot/dst_host:fail:regression
 linux-linus:test-amd64-amd64-pair:guest-migrate/dst_host/src_host/debian.repeat:fail:regression
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=c0cc271173b2e1c2d8d0ceaef14e4dfa79eefc0d
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 11 Apr 2020 03:21:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine       8 reboot                   fail REGR. vs. 149238
 test-amd64-i386-xl-pvshim     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 149238
 test-amd64-i386-xl-shadow     7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-libvirt-xsm   7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot  fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot     fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-libvirt       7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl            7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-xl-raw        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot           fail REGR. vs. 149238
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238
 test-amd64-i386-xl-xsm        7 xen-boot                 fail REGR. vs. 149238
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot         fail REGR. vs. 149238
 test-amd64-i386-freebsd10-i386  7 xen-boot               fail REGR. vs. 149238
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot          fail REGR. vs. 149238
 test-amd64-amd64-libvirt     15 guest-saverestore        fail REGR. vs. 149238
 test-amd64-i386-pair         10 xen-boot/src_host        fail REGR. vs. 149238
 test-amd64-i386-pair         11 xen-boot/dst_host        fail REGR. vs. 149238
 test-amd64-amd64-pair 24 guest-migrate/dst_host/src_host/debian.repeat fail REGR. vs. 149238

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

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

version targeted for testing:
 linux                c0cc271173b2e1c2d8d0ceaef14e4dfa79eefc0d
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z   10 days
Failing since        149266  2020-04-01 03:55:53 Z    9 days   13 attempts
Testing same since   149596  2020-04-10 10:07:06 Z    0 days    1 attempts

------------------------------------------------------------
1789 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       fail    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      fail    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 fail    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       fail    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              fail    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    fail    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 04:49:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 04:49:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jN84w-0001Pp-AQ; Sat, 11 Apr 2020 04:49:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=bNzu=53=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jN84u-0001Pk-UI
 for xen-devel@lists.xenproject.org; Sat, 11 Apr 2020 04:49:12 +0000
X-Inumbo-ID: c5ff2940-7baf-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c5ff2940-7baf-11ea-b4f4-bc764e2007e4;
 Sat, 11 Apr 2020 04:49:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=DQIdsUPTYZzYZInoiAOuYp63AeGYQG7zXaxAU5Nve5o=; b=oQVtKVUWwvkBYBR8QcblbYjPp
 F7MJbdhjWqUYpg3UJdnsfUY84ykawXGoc/SfDZAA5l7X3dm+aWO3JhLIOLRHCccXCbc/U9X9FSuO7
 27aVF4cSpYgs70ZKVTk1iMb75FTqh4rRZ3n8rp+luVMifsaAlMOjliDukBAp76B5RwV60=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jN84n-0005kN-Li; Sat, 11 Apr 2020 04:49:05 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jN84m-0002BY-Fy; Sat, 11 Apr 2020 04:49:04 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jN84m-0007v4-FH; Sat, 11 Apr 2020 04:49:04 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149604-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.13-testing test] 149604: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.13-testing:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 xen-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=736da59cbe2752502ad863b6e71eb83352e22276
X-Osstest-Versions-That: xen=181614a71070ee1dfb8d1fb954ca6127c24691a3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 11 Apr 2020 04:49:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149553

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 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-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass

version targeted for testing:
 xen                  736da59cbe2752502ad863b6e71eb83352e22276
baseline version:
 xen                  181614a71070ee1dfb8d1fb954ca6127c24691a3

Last test of basis   149553  2020-04-09 07:42:33 Z    1 days
Testing same since   149604  2020-04-10 16:36:52 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Julien Grall <julien@xen.org>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   181614a710..736da59cbe  736da59cbe2752502ad863b6e71eb83352e22276 -> stable-4.13


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 10:27:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 10:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNDM4-0003y9-Cl; Sat, 11 Apr 2020 10:27:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=bNzu=53=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNDM3-0003y4-Nq
 for xen-devel@lists.xenproject.org; Sat, 11 Apr 2020 10:27:15 +0000
X-Inumbo-ID: 026b637e-7bdf-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 026b637e-7bdf-11ea-b58d-bc764e2007e4;
 Sat, 11 Apr 2020 10:27:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=vWe7iMbd7kQg2nQlBAhV5esBI+SQbsU/5tSuh8CJ+jY=; b=W5uzseXjRS5mlLCgkfctlAAvE
 uQZf3hwGpsHIKmW2mxECuDQLfCnjGbyh//qo6PlgZ089iCC9rzQ6WkIcTjFQUlfa/ZTIlRhjE0C3K
 6w9OcLp4yzKpRppz3kRFPC542MurByGjjYgu0l474BrqHXPPVoZ0/9zJmthKHDoCYplis=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNDM1-0004ag-Du; Sat, 11 Apr 2020 10:27:13 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNDM1-0005tf-2V; Sat, 11 Apr 2020 10:27:13 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNDM0-0000GJ-VO; Sat, 11 Apr 2020 10:27:12 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149605-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149605: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=13dcb32b6b585d9a29997e81c0a9610cf1a7f64d
X-Osstest-Versions-That: xen=9be0b2747bc7381c684cfbdd3fa2e40badefbeef
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 11 Apr 2020 10:27:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149565
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149565
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149565
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149565
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149565
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149565
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149565
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149565
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149565
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149565
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  13dcb32b6b585d9a29997e81c0a9610cf1a7f64d
baseline version:
 xen                  9be0b2747bc7381c684cfbdd3fa2e40badefbeef

Last test of basis   149565  2020-04-09 13:36:58 Z    1 days
Testing same since   149605  2020-04-10 16:36:53 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Panyakin <apanyaki@amazon.com>
  Dmitry Isaykin <isaikin-dmitry@yandex.ru>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   9be0b2747b..13dcb32b6b  13dcb32b6b585d9a29997e81c0a9610cf1a7f64d -> master


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 11:33:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 11:33:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNEOM-0001EW-St; Sat, 11 Apr 2020 11:33:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=bNzu=53=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNEOL-0001EN-F2
 for xen-devel@lists.xenproject.org; Sat, 11 Apr 2020 11:33:41 +0000
X-Inumbo-ID: 4a4f8cde-7be8-11ea-8563-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4a4f8cde-7be8-11ea-8563-12813bfff9fa;
 Sat, 11 Apr 2020 11:33:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=kLOKw3LDlWNOo7ucl9osbB1NWW/5Vqolq7lPEMyYoDg=; b=HN5IXc2uCbeNMdVL8o7TBjoTp
 0uaob2IvJZq3fZD7cCctVxOcW3x/4NkDANlnCOHFMOOUlfDaSEzprO7AXQzjbmRwgjhwVcvnP5yZ0
 QHjOZImNZROM3hqroTaPNEsE5atcBpSTFlueE0yOO+YLlOkbLXPRU9pqFLHrPE8ZLjCPQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNEOJ-0005pO-Hp; Sat, 11 Apr 2020 11:33:39 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNEOJ-0008Mk-9Q; Sat, 11 Apr 2020 11:33:39 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNEOJ-00074o-8r; Sat, 11 Apr 2020 11:33:39 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149607-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.12-testing test] 149607: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=e8c8071f4ac2cce6f2a0ef75ea53720a7744e875
X-Osstest-Versions-That: xen=824bdb432fc8831ee4684e45361a78faee4548ed
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 11 Apr 2020 11:33:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  e8c8071f4ac2cce6f2a0ef75ea53720a7744e875
baseline version:
 xen                  824bdb432fc8831ee4684e45361a78faee4548ed

Last test of basis   148185  2020-03-06 18:13:31 Z   35 days
Failing since        149554  2020-04-09 07:42:33 Z    2 days    3 attempts
Testing same since   149607  2020-04-10 18:18:00 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  George Dunlap <george.dunlap@citrix.com>
  Igor Druzhinin <igor.druzhinin@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Julien Grall <julien@xen.org>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   824bdb432f..e8c8071f4a  e8c8071f4ac2cce6f2a0ef75ea53720a7744e875 -> stable-4.12


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 11:46:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 11:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNEaL-0002Jw-Dg; Sat, 11 Apr 2020 11:46:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=bNzu=53=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNEaK-0002Jr-O2
 for xen-devel@lists.xenproject.org; Sat, 11 Apr 2020 11:46:04 +0000
X-Inumbo-ID: 029bfca4-7bea-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 029bfca4-7bea-11ea-b4f4-bc764e2007e4;
 Sat, 11 Apr 2020 11:45:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=piMC41sTE21/E/mLzjXk13YriP2tUGUH3rdELFsCDqc=; b=YWXKICsLvWRPf/V5XKhCHKOAy
 UhcBp4m8Csjs1qeX26JJXa1/fog9DlnBwYb2RR9/95SLINVOK+Mkeh1YianRgTG3JLmeZd2Q01RkC
 hQzbPLvPEfxex7ynJKry4NuVhodqQk9t9E9/du4UcgycFg2ZzsEVwG9elM6Dye/u8kFzM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNEaE-000651-5F; Sat, 11 Apr 2020 11:45:58 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNEaD-0000Iv-Tb; Sat, 11 Apr 2020 11:45:57 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNEaD-0002XR-T0; Sat, 11 Apr 2020 11:45:57 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149615-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149615: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=f68601dd720786e98b74c55e89f934a8e218dc34
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 11 Apr 2020 11:45:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              f68601dd720786e98b74c55e89f934a8e218dc34
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   85 days
Failing since        146211  2020-01-18 04:18:52 Z   84 days   81 attempts
Testing same since   149615  2020-04-11 04:18:43 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 14341 lines long.)


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 14:11:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 14:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNGqX-0005mB-1Y; Sat, 11 Apr 2020 14:10:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=u1+c=53=gmail.com=asaffisher.dev@srs-us1.protection.inumbo.net>)
 id 1jNGqW-0005m6-3G
 for xen-devel@lists.xen.org; Sat, 11 Apr 2020 14:10:56 +0000
X-Inumbo-ID: 423f145e-7bfe-11ea-b58d-bc764e2007e4
Received: from mail-io1-xd32.google.com (unknown [2607:f8b0:4864:20::d32])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 423f145e-7bfe-11ea-b58d-bc764e2007e4;
 Sat, 11 Apr 2020 14:10:55 +0000 (UTC)
Received: by mail-io1-xd32.google.com with SMTP id w1so4504408iot.7
 for <xen-devel@lists.xen.org>; Sat, 11 Apr 2020 07:10:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=SYnSHfrgOF4GTQDV7WSKSR4bvytGSvXB2i4xtH3btGo=;
 b=UEmKtAEcsl9IuijxoyXMCF603F3Vm5a3mWJZghqQEL2JmXsCP4fmZbpHT4TF2Nv+9f
 fKGJo94Y6bWYHdKktWryBFyETiVmd0y7ckS67uxmnq+ZuKSMiKZcp3Oqm0gUtfPpqhvy
 Avvm7ax9mfd/1DAbETJTx5ZdKeSuWtRO2tLp8AUSDmSun8vJNHFbSqUslX9WfDUaA2Yw
 l5oBy5jHva4Zj8LXlSFD9bE1CvDnWc6EF2ak2e9/pxIXdTWaz1sjzfq1Io0E8kWVWy1W
 Fi0apuXgsVebpWfLR6U5ebDMxrqbegvWaEMMrgIp7FO1IzB7IGvEW8rHHnmn96SfBZ/s
 LqAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=SYnSHfrgOF4GTQDV7WSKSR4bvytGSvXB2i4xtH3btGo=;
 b=D8ZwfGFeA0g/3iItS39DMnR7ppanFHKZpkyMa3sTUMeRZJJJ/tam73gKtzM5KjcuZB
 R+Uiil6oILzx2z0Q2kjrEM0Wbp0hMdhJ1lj0GXIFjCfWYNFW/ZmiMAij3xix/5ezEaI2
 VBBjbgMoMALP+gkG+OfpdDCwdPEJUXWcB1Azhb/vYtwg9I27orNlvj7+FRg97OH1GgJC
 O0iURUPXXgUUGu1VQY3s9ridbzVBsO2YOA/WI55BBvC3EOb8CA9m44p1TjwxRrnBsEdj
 c1nThWXFiroBxr1QXAiTBeLxL9rQmZC4xwyFeTSoRqXWcpThKtlaHpRzmWou5i3hYYMj
 8Fcw==
X-Gm-Message-State: AGi0Pua32ZKDSDPBXhkd2BVeWM6jKFTLStUHrCw0k/jR/cv1h52I+96I
 ZdxM5crI7Dj1p7NxF3CE11c4+n0uEs5MkOTWLmo3pZfk
X-Google-Smtp-Source: APiQypJqwxYBftsQ4oNxMiCWHIZBpPHog176jHLFzRSFutM0IXyuVLu0qM07K2x9o1Ga/Fd7qg3N8zdI3UiOoxY4Bn4=
X-Received: by 2002:a05:6602:2402:: with SMTP id
 s2mr8702559ioa.69.1586614254552; 
 Sat, 11 Apr 2020 07:10:54 -0700 (PDT)
MIME-Version: 1.0
From: Asaf Fisher <asaffisher.dev@gmail.com>
Date: Sat, 11 Apr 2020 17:10:43 +0300
Message-ID: <CAHmESttxVE+E93svHBEwCE1pNYc9Lxkb+L2vm2jGwbBwOEMOXA@mail.gmail.com>
Subject: XEN 4.11 PV questions
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/alternative; boundary="00000000000009cf9105a3046b51"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--00000000000009cf9105a3046b51
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,
In general I have a intel family 6 model 94 and xen does not support so I
want to add support to it.
For the question:

I=E2=80=99m trying to understand exactly how and when dom0=E2=80=99s vCPU g=
ets a runtime
and where in the code is like the =E2=80=9Cvmenter=E2=80=9D(I know there is=
 no such a thing
in pv..)

So:
1. I got 2 pCPUs and I see that after the secondary cpu gets setup it goes
into and idle loop and wait for a task.

2. When primary cpu finishes init xen, it unpauses dom0 and therefore
schedule it=E2=80=99s vCPU and call the wake function on the credit schedul=
er.
I=E2=80=99m getting a hard time understanding what the wake do... does it p=
ut a
tasklet in the percpu section and then the pCPU see it in its tasklet on
the idle loop? If not what really happens? If yes, how what is the code
flow that causes the dom0 code to be executed? Is it a context switch? If
so where? Or is it just a function call?(I think it=E2=80=99s highly unlike=
ly)

Another hypothesis of mine is that the tasklet is just for callbacks and
not for guests? And do_softirq actually causes scheduling and eventually
causes the cpu to run dom0? I REALLY want to know where the hell is the
last line before a cpu gets into the dom0 context xD

Thanks! I will appreciate the help so much!

--00000000000009cf9105a3046b51
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hello,</div><div dir=3D"auto">In general I have a intel f=
amily 6 model 94 and xen does not support so I want to add support to it.</=
div><div dir=3D"auto">For the question:</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">I=E2=80=99m trying to understand exactly how and when dom0=
=E2=80=99s vCPU gets a runtime and where in the code is like the =E2=80=9Cv=
menter=E2=80=9D(I know there is no such a thing in pv..)=C2=A0</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">So:</div><div dir=3D"auto">1. I got =
2 pCPUs and I see that after the secondary cpu gets setup it goes into and =
idle loop and wait for a task.=C2=A0</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">2. When primary cpu finishes init xen, it unpauses dom0 and th=
erefore schedule it=E2=80=99s vCPU and call the wake function on the credit=
 scheduler.</div><div dir=3D"auto">I=E2=80=99m getting a hard time understa=
nding what the wake do... does it put a tasklet in the percpu section and t=
hen the pCPU see it in its tasklet on the idle loop? If not what really hap=
pens? If yes, how what is the code flow that causes the dom0 code to be exe=
cuted? Is it a context switch? If so where? Or is it just a function call?(=
I think it=E2=80=99s highly unlikely)=C2=A0</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Another hypothesis of mine is that the tasklet is just =
for callbacks and not for guests? And do_softirq actually causes scheduling=
 and eventually causes the cpu to run dom0? I REALLY want to know where the=
 hell is the last line before a cpu gets into the dom0 context xD=C2=A0</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">Thanks! I will appreciate t=
he help so much!</div>

--00000000000009cf9105a3046b51--


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 17:03:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 17:03:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNJX4-0002u7-WE; Sat, 11 Apr 2020 17:03:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=aaZy=53=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jNJX3-0002u2-Oq
 for xen-devel@lists.xen.org; Sat, 11 Apr 2020 17:03:01 +0000
X-Inumbo-ID: 4c2d3d98-7c16-11ea-b58d-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4c2d3d98-7c16-11ea-b58d-bc764e2007e4;
 Sat, 11 Apr 2020 17:03:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586624581;
 h=subject:to:references:from:message-id:date:mime-version:
 in-reply-to:content-transfer-encoding;
 bh=lX0gEFd+llQd3iCLBmuTrQiufaicbK9rCs3Gnvs4jZ4=;
 b=TOLSZrnOG6fJOOICwrn7BdzDKJ7PM7QZ4N1rhMpLvvyuBFu6ohDEdYWN
 4n4kGQEBes6mH6U/5wkDBWAUxpVHtHKGW2FpvsMOQscSnDY4hgdVPwvi/
 oAGHB9WZQ78nrD/+oLJViVvsIbSJgKlsDaau6wRNdDgu+dlj5P1VCeWt8 M=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: tjTLgeqH4zgdl4zlRoGMyIBB5q7a0CYMjuPV9jX3bb80EwoAoycZ+pSH5PSlU8mmY6r0KjVNsD
 GwkPuX5dtUysj6bsjQftR/mwhPzGVgdRzfMvOZC0PuGJp/cg1HRdrejW0wXEisZ5qJcCs7aFUy
 lzKhkwYlV+T9r5d2X5wDehXwiZtXfFKS/oNrsEYIZZefm62LlBdTS6gmNYCyNs15AMX6a4bV8a
 8M+hx5T6AUaACBfYWPre/Ke2hXUrrlwSPpNSjjk+pSbft4Ccp1yMC1ttJKUDqS7e6u+oAiyjya
 gao=
X-SBRS: 2.7
X-MesageID: 15518887
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,371,1580792400"; d="scan'208";a="15518887"
Subject: Re: XEN 4.11 PV questions
To: Asaf Fisher <asaffisher.dev@gmail.com>, "xen-devel@lists.xen.org"
 <xen-devel@lists.xen.org>
References: <CAHmESttxVE+E93svHBEwCE1pNYc9Lxkb+L2vm2jGwbBwOEMOXA@mail.gmail.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <2713ff72-9560-7a1b-3aef-3513fda14b85@citrix.com>
Date: Sat, 11 Apr 2020 18:02:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAHmESttxVE+E93svHBEwCE1pNYc9Lxkb+L2vm2jGwbBwOEMOXA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 11/04/2020 15:10, Asaf Fisher wrote:
> Hello,
> In general I have a intel family 6 model 94 and xen does not support
> so I want to add support to it.

Model 94 (== 0x5e) is Skylake, which has been around for quite a while
now.  (Alternatively, if you mean 0x94, I'm not sure that is even a
production CPU.)

Which CPU do you have, and what is actually going wrong?

> For the question:
>
> I’m trying to understand exactly how and when dom0’s vCPU gets a
> runtime and where in the code is like the “vmenter”(I know there is no
> such a thing in pv..)

Mechanically, PV guests running under Xen is just like regular
userspace.  You get there via IRET/SYSRET.

>
> So:
> 1. I got 2 pCPUs and I see that after the secondary cpu gets setup it
> goes into and idle loop and wait for a task. 
>
> 2. When primary cpu finishes init xen, it unpauses dom0 and therefore
> schedule it’s vCPU and call the wake function on the credit scheduler.
> I’m getting a hard time understanding what the wake do... does it put
> a tasklet in the percpu section and then the pCPU see it in its
> tasklet on the idle loop? If not what really happens? If yes, how what
> is the code flow that causes the dom0 code to be executed? Is it a
> context switch? If so where? Or is it just a function call?(I think
> it’s highly unlikely)

During Xen's boot, all APs start up and starts running the idle vCPU
(there is actually one idle vcpu for each CPU in the system).  This is
idle loop.

The very end of Xen's boot path unpauses dom0 (marks the scheduler
softirq pending), and runs the idle vCPU.  At this point, d0v0 is the
only non-idle and runnable vcpu in the system.

As a softirq is pending, the idle loop processes that first before going
to sleep.  This runs the schedule() function which finds d0v0 ready to
run, and context switches to it.

On x86, we have per-CPU stacks, not per-vCPU stacks, so context switch
involves playing with state at the base of the current stack, rather
than changing to a different stack.  After all of this is done, the end
of context_switch() invokes  d->arch.ctxt_switch->tail() which, for PV
guests, which resets the stack pointer to the base, and executes
ret_from_intr().  This is now in assembly code, and eventually IRET's to
dom0's entrypoint.

~Andrew


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 18:41:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 18:41:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNL3r-0002PS-P1; Sat, 11 Apr 2020 18:40:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=bNzu=53=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNL3q-0002PN-2v
 for xen-devel@lists.xenproject.org; Sat, 11 Apr 2020 18:40:58 +0000
X-Inumbo-ID: f7199a6e-7c23-11ea-85ff-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f7199a6e-7c23-11ea-85ff-12813bfff9fa;
 Sat, 11 Apr 2020 18:40:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=XSoxBIMB0I+c4HvlxGXDhYVTcNR/QiRlR0yMdIq4WzQ=; b=mWOBVIa4OqiGtKrED9WDfa5KA
 H2bY+i6H8bG/dH+qKOp0myOU5ZNMFqeL/1UlNKRcQHaTlPIUxjfElq09vCBXsnQbMN13esdeZwJOh
 cOFkQ3o6S/mHFdrzT+sF7CXDEe/Djf95wSUolZ48wFPhExDzC66xkpOXlQCY8iYHg3lMY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNL3h-0005yV-Ma; Sat, 11 Apr 2020 18:40:49 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNL3h-0005iZ-EL; Sat, 11 Apr 2020 18:40:49 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNL3h-00011v-Do; Sat, 11 Apr 2020 18:40:49 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149614-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149614: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore:fail:allowable
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94
X-Osstest-Versions-That: linux=458ef2a25e0cbdc216012aa2b9cf549d64133b08
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 11 Apr 2020 18:40:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     15 guest-saverestore        fail REGR. vs. 149238
 test-armhf-armhf-xl-rtds    16 guest-start/debian.repeat fail REGR. vs. 149238

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149238
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149238
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149238
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149238
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149238
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149238
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149238
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94
baseline version:
 linux                458ef2a25e0cbdc216012aa2b9cf549d64133b08

Last test of basis   149238  2020-03-31 07:17:53 Z   11 days
Failing since        149266  2020-04-01 03:55:53 Z   10 days   14 attempts
Testing same since   149614  2020-04-11 03:23:30 Z    0 days    1 attempts

------------------------------------------------------------
1855 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   458ef2a25e0c..5b8b9d0c6d0e  5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sat Apr 11 22:55:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Apr 2020 22:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNP2D-0005Sd-SP; Sat, 11 Apr 2020 22:55:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=bNzu=53=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNP2D-0005SX-Es
 for xen-devel@lists.xenproject.org; Sat, 11 Apr 2020 22:55:33 +0000
X-Inumbo-ID: 8bb54344-7c47-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8bb54344-7c47-11ea-b58d-bc764e2007e4;
 Sat, 11 Apr 2020 22:55:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=r2NKaHzP8gn071Dz+ntF+QHOh0J10oC5XcpVVT+JMlY=; b=Y4nbMGWO1LJLMkNeal3Ras4o9
 d7ZgEDYLozAbichFVQO6irF+/UEcFZzEaKj8N4p/nPiz04AXXkeogTtX/rp8DwZ85VkpqGmvvPpUO
 3Nqv3VSROj3/zlfQXcOuhQ+N/GJpVjVFwLvRLfkumcB0Fgimgv0znQ+BWZnF0UE2ECFHU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNP2B-0002Ny-Dj; Sat, 11 Apr 2020 22:55:31 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNP2B-000358-5M; Sat, 11 Apr 2020 22:55:31 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNP2B-0003WC-4l; Sat, 11 Apr 2020 22:55:31 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149619-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149619: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
X-Osstest-Versions-That: xen=13dcb32b6b585d9a29997e81c0a9610cf1a7f64d
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 11 Apr 2020 22:55:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149605
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149605
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149605
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149605
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149605
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149605
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149605
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149605
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149605
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149605
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3
baseline version:
 xen                  13dcb32b6b585d9a29997e81c0a9610cf1a7f64d

Last test of basis   149605  2020-04-10 16:36:53 Z    1 days
Testing same since   149619  2020-04-11 10:29:16 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Tamas K Lengyel <tamas@tklengyel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   13dcb32b6b..7372466b21  7372466b21c3b6c96bb7a52754e432bac883a1e3 -> master


From xen-devel-bounces@lists.xenproject.org Sun Apr 12 00:36:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 00:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNQbf-0005YK-D2; Sun, 12 Apr 2020 00:36:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NHv3=54=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNQbd-0005YF-OX
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 00:36:13 +0000
X-Inumbo-ID: 98f6cf38-7c55-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 98f6cf38-7c55-11ea-9e09-bc764e2007e4;
 Sun, 12 Apr 2020 00:36:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=yFaa4rbbkytj2PS0d1WHSnR+ZFBz7jUelrfywxya8HU=; b=kR+J2ofbjnkt1y9wEZa63dxnd
 GGhRQkGiY7oAO6dRT8czY6q4siAJA+mcqqYbDsqQ1tFUbgM56FbNv2YnU9htYh3FrJ+sRbfhKVu2p
 urB6vqNrSWHJOxpIVJWHXbuP1Q6m4hvZjA22AUD+FJD7vcsVLewFQ+70lza0+pSgPFDWA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNQbW-0004pD-Iu; Sun, 12 Apr 2020 00:36:06 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNQbW-0002Fg-AK; Sun, 12 Apr 2020 00:36:06 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNQbW-0003kc-9M; Sun, 12 Apr 2020 00:36:06 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149624-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149624: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=17e1e49814096a3daaa8e5a73acd56a0f30bdc18
X-Osstest-Versions-That: qemuu=8bac3ba57eecc466b7e73dabf7d19328a59f684e
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 12 Apr 2020 00:36:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu                17e1e49814096a3daaa8e5a73acd56a0f30bdc18
baseline version:
 qemuu                8bac3ba57eecc466b7e73dabf7d19328a59f684e

Last test of basis   149598  2020-04-10 11:02:26 Z    1 days
Testing same since   149624  2020-04-11 16:43:30 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefan Hajnoczi <stefanha@redhat.com>
  Ying Fang <fangying1@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   8bac3ba57e..17e1e49814  17e1e49814096a3daaa8e5a73acd56a0f30bdc18 -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Sun Apr 12 03:27:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 03:27:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNTH2-0005DD-Qr; Sun, 12 Apr 2020 03:27:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NHv3=54=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNTH1-0005D8-Lq
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 03:27:07 +0000
X-Inumbo-ID: 776cbb94-7c6d-11ea-86fa-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 776cbb94-7c6d-11ea-86fa-12813bfff9fa;
 Sun, 12 Apr 2020 03:26:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=U/Xk9wMwJlDkGdPBLRfUAlqZLDAr/RYAH9QOnDYTWoY=; b=4ZdX0HsTFT8n28PgQIXl8UzmZ
 uZd3dbGmsCNTRFXXAX2SJVLZMuIQXPVKrlBIZhoC6GHetXlzPPFoeLMBqZNmYi4WgQ4rdylSW+XaZ
 0xHtBDXFAPVI25bII3w6hq+olqVHExSn3uNi0K7eT/sMEFkPnJ/4fRu1AxeKMVzYHhNH4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNTGs-0004QI-8u; Sun, 12 Apr 2020 03:26:58 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNTGr-0000WA-Rt; Sun, 12 Apr 2020 03:26:57 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNTGr-0003k1-R3; Sun, 12 Apr 2020 03:26:57 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149626-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149626: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=b753101a4ac0b906064a72feec43f5b80a1fe2e5
X-Osstest-Versions-That: linux=5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 12 Apr 2020 03:26:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                b753101a4ac0b906064a72feec43f5b80a1fe2e5
baseline version:
 linux                5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94

Last test of basis   149614  2020-04-11 03:23:30 Z    0 days
Testing same since   149626  2020-04-11 19:09:05 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Borislav Petkov <bp@suse.de>
  Fangrui Song <maskray@google.com>
  H. Peter Anvin (Intel) <hpa@zytor.com>
  Herbert Xu <herbert@gondor.apana.org.au>
  Ingo Molnar <mingo@kernel.org>
  Jani Nikula <jani.nikula@intel.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jeremy Cline <jcline@redhat.com>
  Kees Cook <keescook@chromium.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Masahiro Yamada <masahiroy@kernel.org>
  Masahiro Yamada <yamada.masahiro@socionext.com>
  Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
  Nathan Chancellor <natechancellor@gmail.com>
  Nathan Chancellor <natechancellor@gmail.com> # build
  Nick Desaulniers <ndesaulniers@google.com>
  Sedat Dilek <sedat.dilek@gmail.com>
  Thomas Bogendoerfer <tsbogend@alpha.franken.de>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   5b8b9d0c6d0e..b753101a4ac0  b753101a4ac0b906064a72feec43f5b80a1fe2e5 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sun Apr 12 06:18:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 06:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNVwG-0002LZ-Th; Sun, 12 Apr 2020 06:17:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NHv3=54=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNVwG-0002LU-1P
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 06:17:52 +0000
X-Inumbo-ID: 5482fdba-7c85-11ea-870b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5482fdba-7c85-11ea-870b-12813bfff9fa;
 Sun, 12 Apr 2020 06:17:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=xscarfMGgoMIYHbL5r1zVzaF08NhIc600OObRoauFd0=; b=UOHj4kiYLmm1UvpMKNYJU5Zz/
 50AEhHHWwOYBrYAQRXrmDQ0MUNGMdp+R85YhCEwxzYliSnCgBX/rMKcZ1+gVCYgf0NtdibjD15JTR
 gA3H7XigxT1M/9C8rNzXQgwpe4azpO5q6EEjtFZLqYr8ww8uBrt4tCEa37nhZ/QOa+aNU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNVwB-00088v-JT; Sun, 12 Apr 2020 06:17:47 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNVwB-0001js-9T; Sun, 12 Apr 2020 06:17:47 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNVwB-0003sn-8s; Sun, 12 Apr 2020 06:17:47 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149629-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149629: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=f68601dd720786e98b74c55e89f934a8e218dc34
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 12 Apr 2020 06:17:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              f68601dd720786e98b74c55e89f934a8e218dc34
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   86 days
Failing since        146211  2020-01-18 04:18:52 Z   85 days   82 attempts
Testing same since   149615  2020-04-11 04:18:43 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 14341 lines long.)


From xen-devel-bounces@lists.xenproject.org Sun Apr 12 10:13:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 10:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNZcJ-0004yC-9w; Sun, 12 Apr 2020 10:13:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NHv3=54=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNZcI-0004y7-Lz
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 10:13:30 +0000
X-Inumbo-ID: 3dd6409c-7ca6-11ea-8740-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3dd6409c-7ca6-11ea-8740-12813bfff9fa;
 Sun, 12 Apr 2020 10:13:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=qFXSerCG82WKiqv/bNE83LgKPCwMLZ295kryQX39xq4=; b=L8lrEYZmMJjJuXLiD5r1ZSMdq
 WKpz9bSOvh7Cu4hNRNdcUvoU6CgSiDAWs5j0l1SudaGadzGnN3nAAUDQQaQMwxgzWVWgqONb2h26N
 nyrUjzbbTiH4BEDlNZFT9l3zkDxg6rRUndQjqKWEDSO7WuIlOPm3fHjvzo9I42TAC9Z1E=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNZcA-0004t2-WC; Sun, 12 Apr 2020 10:13:23 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNZcA-0006Lg-Mc; Sun, 12 Apr 2020 10:13:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNZcA-00085v-Lx; Sun, 12 Apr 2020 10:13:22 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149630-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-coverity test] 149630: all pass - PUSHED
X-Osstest-Versions-This: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
X-Osstest-Versions-That: xen=e013e8514389b739153016349e49f5a78e34ddf0
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 12 Apr 2020 10:13:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3
baseline version:
 xen                  e013e8514389b739153016349e49f5a78e34ddf0

Last test of basis   149517  2020-04-08 09:19:14 Z    4 days
Testing same since   149630  2020-04-12 09:19:20 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Andrew Panyakin <apanyaki@amazon.com>
  Dmitry Isaykin <isaikin-dmitry@yandex.ru>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>
  Tamas K Lengyel <tamas@tklengyel.com>
  Wei Liu <wl@xen.org>

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
   e013e85143..7372466b21  7372466b21c3b6c96bb7a52754e432bac883a1e3 -> coverity-tested/smoke


From xen-devel-bounces@lists.xenproject.org Sun Apr 12 12:37:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 12:37:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNbrP-0007ix-F2; Sun, 12 Apr 2020 12:37:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NHv3=54=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNbrO-0007is-5k
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 12:37:14 +0000
X-Inumbo-ID: 524b8de8-7cba-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 524b8de8-7cba-11ea-b58d-bc764e2007e4;
 Sun, 12 Apr 2020 12:37:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=CQoRoLiZFAoact4zZQebj2W7nOhURol8a06/2Mza+vE=; b=PZQ/LSJIAAdHitFkOzKE//3uo
 8ZVOGFE6XIB9+OxOua/i3nXySO9f9wZlKHZ73rd9vX1U89bQrLDurRalbMppJI/EeWJuOTr3+Nskw
 Z1+uLV3DN659V+bIB5O6NreDCPQ3lBhEmeKnRg7jqbeYt38q2UIQJKDxBdJUtH8ULLlIQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNbrH-0007lx-4Y; Sun, 12 Apr 2020 12:37:07 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNbrG-0003ec-T2; Sun, 12 Apr 2020 12:37:06 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNbrG-0007iw-Qs; Sun, 12 Apr 2020 12:37:06 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149627-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149627: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:depriv-audit-qemu/create:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
X-Osstest-Versions-That: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 12 Apr 2020 12:37:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 15 depriv-audit-qemu/create fail pass in 149619

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149619
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149619
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149619
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149619
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149619
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149619
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149619
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149619
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149619
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149619
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3
baseline version:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3

Last test of basis   149627  2020-04-12 01:52:22 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Sun Apr 12 15:06:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 15:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNeBE-0002s7-1p; Sun, 12 Apr 2020 15:05:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NHv3=54=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNeBD-0002s2-EG
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 15:05:51 +0000
X-Inumbo-ID: 1571eccc-7ccf-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1571eccc-7ccf-11ea-b4f4-bc764e2007e4;
 Sun, 12 Apr 2020 15:05:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=maMMomLZq2skydb0uDoCc/OxKyx9lNgEGdSamKgNxnU=; b=OX3euZ7aGwc3efFt+UX/Htnyo
 Pwtw2dLiNesS+63hdl1HN0qtx/UewsyR7pUtdM9QJn8MNknUEenqB+jNzUV13Nz9WHtqY6ECx+4Z6
 w+dfY6zFlQ0WSQjQ+xBsJlftMEAuL38lEC25TyYNKaxDoQvE7d7q8wO0+T79M+kkI745c=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNeB6-0002Fm-IS; Sun, 12 Apr 2020 15:05:44 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNeB6-0007bg-9W; Sun, 12 Apr 2020 15:05:44 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNeB6-00006m-8k; Sun, 12 Apr 2020 15:05:44 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149628-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149628: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=b032227c62939b5481bcd45442b36dfa263f4a7c
X-Osstest-Versions-That: linux=b753101a4ac0b906064a72feec43f5b80a1fe2e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 12 Apr 2020 15:05:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                b032227c62939b5481bcd45442b36dfa263f4a7c
baseline version:
 linux                b753101a4ac0b906064a72feec43f5b80a1fe2e5

Last test of basis   149626  2020-04-11 19:09:05 Z    0 days
Testing same since   149628  2020-04-12 03:29:33 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexandru Ardelean <alexandru.ardelean@analog.com>
  Beniamin Bia <beniamin.bia@analog.com>
  Christoph Hellwig <hch@lst.de>
  Dragos Bogdan <dragos.bogdan@analog.com>
  Grygorii Strashko <grygorii.strashko@ti.com>
  Kishon Vijay Abraham I <kishon@ti.com>
  Ley Foon Tan <ley.foon.tan@intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   b753101a4ac0..b032227c6293  b032227c62939b5481bcd45442b36dfa263f4a7c -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sun Apr 12 21:10:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 21:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNjrd-0006iP-SP; Sun, 12 Apr 2020 21:10:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=pqw0=54=gmail.com=philippe.mathieu.daude@srs-us1.protection.inumbo.net>)
 id 1jNjrc-0006fm-UO
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 21:10:00 +0000
X-Inumbo-ID: f7fc3d0e-7d01-11ea-9e09-bc764e2007e4
Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f7fc3d0e-7d01-11ea-9e09-bc764e2007e4;
 Sun, 12 Apr 2020 21:10:00 +0000 (UTC)
Received: by mail-wr1-x443.google.com with SMTP id f13so8369660wrm.13
 for <xen-devel@lists.xenproject.org>; Sun, 12 Apr 2020 14:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=78jL4VADjrh0P46dW2DeDq44Jyf+SdDfu3arjlW7LnM=;
 b=OxkjuSkWJAFZSnNM8yGetjkdEAeKalwtCudr2Vh2d27xI1BS4ILr7L9uBODjpRJkpH
 R6D8YXX/p+XUqNrFQIAz93kwaViDm5mQpiBuOecCeCVBz4yojSdNqw6Ipl46gFGlzf9r
 g8Cm0L+Z0C4mTbJh2CzJAY1wv+iIGBJ1VnGSQPeoXju8w0uYyAB0pz5E8h0xKz80Mxci
 z074B0Y4PP1p9TvlgPyvgyIT792lXRCe/qHu6rPI5r6pePkQJmyeyZz3JKxyhm2cJYbS
 4YYIUqsp56tehGunUkN7pmQHzZn5tu03tfUy2aBHiRpXOWFa841s50yv6YsU3qC+BikH
 QIjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:date:message-id
 :mime-version:content-transfer-encoding;
 bh=78jL4VADjrh0P46dW2DeDq44Jyf+SdDfu3arjlW7LnM=;
 b=Ga/4cHxs3+okKoKq8o7zgcJsqb1xlhZSAaTg6aH06B4htNT9ZFuWAjGsnCkX9wgKMZ
 GV0Pz7KyTEsbHdPPVAXl9CKXlKfp+Pd2viqJlxu/3A9HRhIl7H2tLeU+W3NR5jowUjj4
 PBGjOeKbA28/Wtauh1gdO4Z3SrcNMkgeUgUNzCWAQt0t0E3CxGOg1JrAyi21v+OB5CK6
 U+qs6i5aMUgvmiVQo2OQINkPu3O1Ak9hJFoizH0K+jgAEqPpOS2KU2OMO0R40n90uHwS
 lyHZommzsMvbEmgnfXpe5Y75CLRHkGoLHJ4XWVIY8eZF9VesPHgkqYIHP6RrmP12ZeCU
 Bk2Q==
X-Gm-Message-State: AGi0Pub2Ynko8rYK+/R7BhhhyCb52Eo53Mp4hYNrOvh+T3RXETIVz14t
 /jLGZHR6Y6Bj1b+q/TiLhbE=
X-Google-Smtp-Source: APiQypIHokdZHj3hxylpnNFCsDn0s/aQ6M1SC93tjDE0SBCneBZJc3wwsTL0+EuIZJCPMwTTJMFunQ==
X-Received: by 2002:a5d:61c5:: with SMTP id q5mr5945448wrv.260.1586725799424; 
 Sun, 12 Apr 2020 14:09:59 -0700 (PDT)
Received: from localhost.localdomain (116.red-83-42-57.dynamicip.rima-tde.net.
 [83.42.57.116])
 by smtp.gmail.com with ESMTPSA id o16sm12553602wrs.44.2020.04.12.14.09.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 12 Apr 2020 14:09:58 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
To: qemu-devel@nongnu.org
Subject: [PATCH-for-5.1 0/3] various: Remove unnecessary casts
Date: Sun, 12 Apr 2020 23:09:51 +0200
Message-Id: <20200412210954.32313-1-f4bug@amsat.org>
X-Mailer: git-send-email 2.21.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>,
 John Snow <jsnow@redhat.com>, Richard Henderson <rth@twiddle.net>,
 =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>,
 =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Remove unnecessary casts using coccinelle scripts.

The CPU()/OBJECT() patches don't introduce logical change,
The DEVICE() one removes various OBJECT_CHECK() calls.

Philippe Mathieu-Daudé (3):
  target: Remove unnecessary CPU() cast
  various: Remove unnecessary OBJECT() cast
  hw: Remove unnecessary DEVICE() cast

 hw/core/bus.c                       | 2 +-
 hw/display/artist.c                 | 2 +-
 hw/display/cg3.c                    | 2 +-
 hw/display/sm501.c                  | 2 +-
 hw/display/tcx.c                    | 4 ++--
 hw/display/vga-isa.c                | 2 +-
 hw/i2c/imx_i2c.c                    | 2 +-
 hw/i2c/mpc_i2c.c                    | 2 +-
 hw/ide/ahci-allwinner.c             | 2 +-
 hw/ide/piix.c                       | 2 +-
 hw/ipmi/smbus_ipmi.c                | 2 +-
 hw/microblaze/petalogix_ml605_mmu.c | 8 ++++----
 hw/misc/macio/pmu.c                 | 2 +-
 hw/net/ftgmac100.c                  | 3 +--
 hw/net/imx_fec.c                    | 2 +-
 hw/nubus/nubus-device.c             | 2 +-
 hw/pci-host/bonito.c                | 2 +-
 hw/ppc/spapr.c                      | 2 +-
 hw/s390x/sclp.c                     | 2 +-
 hw/sh4/sh_pci.c                     | 2 +-
 hw/xen/xen-legacy-backend.c         | 2 +-
 monitor/misc.c                      | 3 +--
 qom/object.c                        | 4 ++--
 target/ppc/mmu_helper.c             | 2 +-
 24 files changed, 29 insertions(+), 31 deletions(-)

-- 
2.21.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 12 21:10:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 21:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNjro-0007Jb-Ex; Sun, 12 Apr 2020 21:10:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=pqw0=54=gmail.com=philippe.mathieu.daude@srs-us1.protection.inumbo.net>)
 id 1jNjrm-0007JW-Q3
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 21:10:10 +0000
X-Inumbo-ID: fc3c0584-7d01-11ea-b4f4-bc764e2007e4
Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fc3c0584-7d01-11ea-b4f4-bc764e2007e4;
 Sun, 12 Apr 2020 21:10:07 +0000 (UTC)
Received: by mail-wr1-x442.google.com with SMTP id i10so8378368wrv.10
 for <xen-devel@lists.xenproject.org>; Sun, 12 Apr 2020 14:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=gsYbEjd4TD9Bp8EbfBEbuZbEWy++c7aKNJLdJ3YG81s=;
 b=F6MwD2LXNz5qSiQ9U7sN6titbvBTVPwW+WPnxAgReHxGMCEM+dPMLI2rDyI1SBuexA
 8X4en7LsPicU3CvVdJfUwpaYkWQJx/9JDE36m/vCG9tt4oNnclZvSGLtxDh9g2nqvVen
 egUlGG7jm5W4bkUTTQyk2IrVD5095MR2BaBB1nrA2tWvi4Uo2j7P5Aid8G1fMkGhrHgp
 3JcUjkFFHKzGHqOa5WPhvPjQa5uJtWQqbZ7u6YajqffuNp4Y4eS18QQqe3TejYDaLL/v
 NSSfd4k/Trj0zKPV1XsX0isvHEDohvQeLjdKEdbJp37tNHLfgAKiMGDBvJ9cRKFn6wia
 3pRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:date:message-id
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=gsYbEjd4TD9Bp8EbfBEbuZbEWy++c7aKNJLdJ3YG81s=;
 b=WRmDogn4LuWT0Xz02wTwnftnBgR3gI9W+VKWKb7W3oeV44FyjB3lHHWIfKb3KB2oAF
 OgvHcz9JMHP3yPHvXflG+Eo+0lcGoCP7eXf0RcrAnL86mqTc05St65n9n38w+9BFrn0d
 spcp9c/TmxHMTbuqCRULftW/zky8YtjK/uwCdrfs/HPhSLTVwOPdx6XOankDE4/7cBJ1
 9BJ5oESubbdIwInQHVXdekhdPyBq+sAsvpobVoML7FxHbginFxii6vS6SEh0Nk6ZHHd4
 gdXAUzfQ2JzcMSpOtGSQ0+D841syz2yOx+CDMT2UmQkfD36pwkGInQoah14BfJKwL7rY
 4uwA==
X-Gm-Message-State: AGi0PubCGJzTPiDng7EvtoeeC/eyA7no0wvbH/ylwI1EYjoPXt4jyESp
 RBJsQjTnKgFgbvCzp+9sd24=
X-Google-Smtp-Source: APiQypIWuuzEDhgrL5dFuOMcEExPN7XGYetuwcVi65TL0H1PSMXhw1g00339hVtTvTn98WKI8byMwQ==
X-Received: by 2002:a5d:69c9:: with SMTP id s9mr15764392wrw.307.1586725806483; 
 Sun, 12 Apr 2020 14:10:06 -0700 (PDT)
Received: from localhost.localdomain (116.red-83-42-57.dynamicip.rima-tde.net.
 [83.42.57.116])
 by smtp.gmail.com with ESMTPSA id o16sm12553602wrs.44.2020.04.12.14.10.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 12 Apr 2020 14:10:05 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
To: qemu-devel@nongnu.org
Subject: [PATCH-for-5.1 2/3] various: Remove unnecessary OBJECT() cast
Date: Sun, 12 Apr 2020 23:09:53 +0200
Message-Id: <20200412210954.32313-3-f4bug@amsat.org>
X-Mailer: git-send-email 2.21.1
In-Reply-To: <20200412210954.32313-1-f4bug@amsat.org>
References: <20200412210954.32313-1-f4bug@amsat.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>,
 John Snow <jsnow@redhat.com>, Richard Henderson <rth@twiddle.net>,
 =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>,
 =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The OBJECT() macro is defined as:

  #define OBJECT(obj) ((Object *)(obj))

Remove unnecessary OBJECT() casts.

Patch created mechanically using spatch with this script:

  @@
  typedef Object;
  Object *o;
  @@
  -   OBJECT(o)
  +   o

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/core/bus.c                       | 2 +-
 hw/ide/ahci-allwinner.c             | 2 +-
 hw/ipmi/smbus_ipmi.c                | 2 +-
 hw/microblaze/petalogix_ml605_mmu.c | 8 ++++----
 hw/s390x/sclp.c                     | 2 +-
 monitor/misc.c                      | 3 +--
 qom/object.c                        | 4 ++--
 7 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/hw/core/bus.c b/hw/core/bus.c
index 3dc0a825f0..4ea5870de8 100644
--- a/hw/core/bus.c
+++ b/hw/core/bus.c
@@ -25,7 +25,7 @@
 
 void qbus_set_hotplug_handler(BusState *bus, Object *handler, Error **errp)
 {
-    object_property_set_link(OBJECT(bus), OBJECT(handler),
+    object_property_set_link(OBJECT(bus), handler,
                              QDEV_HOTPLUG_HANDLER_PROPERTY, errp);
 }
 
diff --git a/hw/ide/ahci-allwinner.c b/hw/ide/ahci-allwinner.c
index bb8393d2b6..8536b9eb5a 100644
--- a/hw/ide/ahci-allwinner.c
+++ b/hw/ide/ahci-allwinner.c
@@ -90,7 +90,7 @@ static void allwinner_ahci_init(Object *obj)
     SysbusAHCIState *s = SYSBUS_AHCI(obj);
     AllwinnerAHCIState *a = ALLWINNER_AHCI(obj);
 
-    memory_region_init_io(&a->mmio, OBJECT(obj), &allwinner_ahci_mem_ops, a,
+    memory_region_init_io(&a->mmio, obj, &allwinner_ahci_mem_ops, a,
                           "allwinner-ahci", ALLWINNER_AHCI_MMIO_SIZE);
     memory_region_add_subregion(&s->ahci.mem, ALLWINNER_AHCI_MMIO_OFF,
                                 &a->mmio);
diff --git a/hw/ipmi/smbus_ipmi.c b/hw/ipmi/smbus_ipmi.c
index 2a9470d9df..f1a0148755 100644
--- a/hw/ipmi/smbus_ipmi.c
+++ b/hw/ipmi/smbus_ipmi.c
@@ -329,7 +329,7 @@ static void smbus_ipmi_init(Object *obj)
 {
     SMBusIPMIDevice *sid = SMBUS_IPMI(obj);
 
-    ipmi_bmc_find_and_link(OBJECT(obj), (Object **) &sid->bmc);
+    ipmi_bmc_find_and_link(obj, (Object **) &sid->bmc);
 }
 
 static void smbus_ipmi_get_fwinfo(struct IPMIInterface *ii, IPMIFwInfo *info)
diff --git a/hw/microblaze/petalogix_ml605_mmu.c b/hw/microblaze/petalogix_ml605_mmu.c
index 0a2640c40b..52dcea9abd 100644
--- a/hw/microblaze/petalogix_ml605_mmu.c
+++ b/hw/microblaze/petalogix_ml605_mmu.c
@@ -150,9 +150,9 @@ petalogix_ml605_init(MachineState *machine)
     qdev_set_nic_properties(eth0, &nd_table[0]);
     qdev_prop_set_uint32(eth0, "rxmem", 0x1000);
     qdev_prop_set_uint32(eth0, "txmem", 0x1000);
-    object_property_set_link(OBJECT(eth0), OBJECT(ds),
+    object_property_set_link(OBJECT(eth0), ds,
                              "axistream-connected", &error_abort);
-    object_property_set_link(OBJECT(eth0), OBJECT(cs),
+    object_property_set_link(OBJECT(eth0), cs,
                              "axistream-control-connected", &error_abort);
     qdev_init_nofail(eth0);
     sysbus_mmio_map(SYS_BUS_DEVICE(eth0), 0, AXIENET_BASEADDR);
@@ -163,9 +163,9 @@ petalogix_ml605_init(MachineState *machine)
     cs = object_property_get_link(OBJECT(eth0),
                                   "axistream-control-connected-target", NULL);
     qdev_prop_set_uint32(dma, "freqhz", 100 * 1000000);
-    object_property_set_link(OBJECT(dma), OBJECT(ds),
+    object_property_set_link(OBJECT(dma), ds,
                              "axistream-connected", &error_abort);
-    object_property_set_link(OBJECT(dma), OBJECT(cs),
+    object_property_set_link(OBJECT(dma), cs,
                              "axistream-control-connected", &error_abort);
     qdev_init_nofail(dma);
     sysbus_mmio_map(SYS_BUS_DEVICE(dma), 0, AXIDMA_BASEADDR);
diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index f0c35aa57a..bae9d2350f 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -288,7 +288,7 @@ void s390_sclp_init(void)
 
     object_property_add_child(qdev_get_machine(), TYPE_SCLP, new,
                               NULL);
-    object_unref(OBJECT(new));
+    object_unref(new);
     qdev_init_nofail(DEVICE(new));
 }
 
diff --git a/monitor/misc.c b/monitor/misc.c
index 6c45fa490f..57af5fa5a4 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -1839,8 +1839,7 @@ void object_add_completion(ReadLineState *rs, int nb_args, const char *str)
 static int qdev_add_hotpluggable_device(Object *obj, void *opaque)
 {
     GSList **list = opaque;
-    DeviceState *dev = (DeviceState *)object_dynamic_cast(OBJECT(obj),
-                                                          TYPE_DEVICE);
+    DeviceState *dev = (DeviceState *)object_dynamic_cast(obj, TYPE_DEVICE);
 
     if (dev == NULL) {
         return 0;
diff --git a/qom/object.c b/qom/object.c
index 1812f79224..9893cc5459 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -762,7 +762,7 @@ Object *object_new_with_propv(const char *typename,
         }
     }
 
-    object_unref(OBJECT(obj));
+    object_unref(obj);
     return obj;
 
  error:
@@ -1689,7 +1689,7 @@ void object_property_add_child(Object *obj, const char *name,
         return;
     }
 
-    type = g_strdup_printf("child<%s>", object_get_typename(OBJECT(child)));
+    type = g_strdup_printf("child<%s>", object_get_typename(child));
 
     op = object_property_add(obj, name, type, object_get_child_property, NULL,
                              object_finalize_child_property, child, &local_err);
-- 
2.21.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 12 21:10:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 21:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNjrj-0007Da-52; Sun, 12 Apr 2020 21:10:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=pqw0=54=gmail.com=philippe.mathieu.daude@srs-us1.protection.inumbo.net>)
 id 1jNjrh-00072p-Qs
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 21:10:05 +0000
X-Inumbo-ID: fa21079a-7d01-11ea-83d8-bc764e2007e4
Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fa21079a-7d01-11ea-83d8-bc764e2007e4;
 Sun, 12 Apr 2020 21:10:03 +0000 (UTC)
Received: by mail-wr1-x443.google.com with SMTP id i10so8378278wrv.10
 for <xen-devel@lists.xenproject.org>; Sun, 12 Apr 2020 14:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=eWubfF2iDWfZ1hbsO/IXecVFoz0dDRJS/Xj5DAW2JNo=;
 b=TKsyfLjrtirKrDYfamB6nSrrR1fPhrULfxHjh5dsXKznOBbWceZZrZQvEgoeZxVwzh
 lyJwOD9688ualAfVSJptSzKTDdFxJmthHKBJK+Zzg977Bw1z5adwWSDk7qwbN0r+btX/
 VgcDBQWB1idyVqirNa1KnHS0CTnRxSpja5/oIGNROIK0uS38xV2hbPpj/ESifO26aecS
 t++f3fH9j6yhpg5IpeK0CdEbMOlUMsAvicHE/sEEZptPqxP5EE1D4KJgdxQse8zEOmnv
 WuYFZdR7TlOo5Wtd9u6MzWOwp5xvBCfBKt/2HASpFTnxjpmuCx3jFscSZH0JywZchrBM
 nEZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:date:message-id
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=eWubfF2iDWfZ1hbsO/IXecVFoz0dDRJS/Xj5DAW2JNo=;
 b=oLwgYip9i337YhuotGWwIUz46Bo2ZhGvhRAhvB+a/MR8qSbgO35KCUtuLw08YS15Td
 w0EK4xzo8bDxhiOHoam7cvUn217oKI1fMn0c9whksqDOJRzohVEWkKeX31jy6EUU2l0J
 MekdU+OfZoLXduBIKyR/CJ/8YIiHJZrAarytmAauHSA+FU9bNzx7VHxoGzMutMpUGcaI
 r+V/McGP+ROQYJgcYVml42ybUewa9XVAbbf0mtfrXwRhAwKYdEe5vFqi+RimrXD1jcqi
 drIdSThKeXlJtZhLwUD0a/LCv/lQa/ojcHEa2YHM/Dk/jVyarrVbj/cFGVxqq0eOLZW+
 SZ+g==
X-Gm-Message-State: AGi0PuZim3CAfxE22fM38hSGO7J+ZnWbQEy4VmN1IAsbglvty16C9d44
 aQIyI4Lj1Exh4FtGlXpRk1Q=
X-Google-Smtp-Source: APiQypIm1u1/S0kMjoDLIIDr4V7cLU5DYZtELtqiKjq5NrnqQBzkjtQPdfba4f3psDwbQLE84Uft9A==
X-Received: by 2002:adf:cc8c:: with SMTP id p12mr15464439wrj.165.1586725803042; 
 Sun, 12 Apr 2020 14:10:03 -0700 (PDT)
Received: from localhost.localdomain (116.red-83-42-57.dynamicip.rima-tde.net.
 [83.42.57.116])
 by smtp.gmail.com with ESMTPSA id o16sm12553602wrs.44.2020.04.12.14.09.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 12 Apr 2020 14:10:02 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
To: qemu-devel@nongnu.org
Subject: [PATCH-for-5.1 1/3] target: Remove unnecessary CPU() cast
Date: Sun, 12 Apr 2020 23:09:52 +0200
Message-Id: <20200412210954.32313-2-f4bug@amsat.org>
X-Mailer: git-send-email 2.21.1
In-Reply-To: <20200412210954.32313-1-f4bug@amsat.org>
References: <20200412210954.32313-1-f4bug@amsat.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>,
 John Snow <jsnow@redhat.com>, Richard Henderson <rth@twiddle.net>,
 =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>,
 =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The CPU() macro is defined as:

  #define CPU(obj) ((CPUState *)(obj))

Remove an unnecessary CPU() cast.

Patch created mechanically using spatch with this script:

  @@
  typedef CPUState;
  CPUState *s;
  @@
  -   CPU(s)
  +   s

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 target/ppc/mmu_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
index 86c667b094..8972714775 100644
--- a/target/ppc/mmu_helper.c
+++ b/target/ppc/mmu_helper.c
@@ -1820,7 +1820,7 @@ static inline void do_invalidate_BAT(CPUPPCState *env, target_ulong BATu,
     if (((end - base) >> TARGET_PAGE_BITS) > 1024) {
         /* Flushing 1024 4K pages is slower than a complete flush */
         LOG_BATS("Flush all BATs\n");
-        tlb_flush(CPU(cs));
+        tlb_flush(cs);
         LOG_BATS("Flush done\n");
         return;
     }
-- 
2.21.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 12 21:10:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 21:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNjrt-0007LO-Mt; Sun, 12 Apr 2020 21:10:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=pqw0=54=gmail.com=philippe.mathieu.daude@srs-us1.protection.inumbo.net>)
 id 1jNjrr-0007Ke-Qk
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 21:10:15 +0000
X-Inumbo-ID: fe600202-7d01-11ea-83d8-bc764e2007e4
Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fe600202-7d01-11ea-83d8-bc764e2007e4;
 Sun, 12 Apr 2020 21:10:10 +0000 (UTC)
Received: by mail-wm1-x344.google.com with SMTP id a201so7887445wme.1
 for <xen-devel@lists.xenproject.org>; Sun, 12 Apr 2020 14:10:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=WI0uWQVZOcYqeJp2uBcJ0303+lu8M+R0XXUdzA9Q1p0=;
 b=cU4DzG8kqqs2TjXHLis6XOLzgrHN02vjMnOKSSYfhhMP5l2oHzFAmyge2FXQqc0/1i
 N6yLdtTkguIoUJcfLqkaoRKNXonCZ8hf4DgB1/xooDdxVwjG6CPclbRsrHZRtqVI87sR
 tCXasUn8FS1JgRT+D72CoZgi/gx/QS7dzvZkJNQ6zgX06fXEFNAcWY2tqCfVvh5rRXnB
 VRgijZIy9TYGoUwOZnZwFAwJs+W/cdTZqJpo1FCu2F4tdTKGNfSl++HIcDcanPqtqOhz
 2GzCk4XvwggWeph1f0Se74nYxhgV2VuJ8WTt09Upfu813qdRiWl+q6FS8CL78q2yO/Wr
 x6NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:date:message-id
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=WI0uWQVZOcYqeJp2uBcJ0303+lu8M+R0XXUdzA9Q1p0=;
 b=ZzV6sA4jZeqvEiVcqMcIy/O7O/zOZUJPb6gO4bGIpYoOfQSGcasCXHYFg/sf/ubWY1
 gs5o4oN1bYPgohqgwHsbCZ20nEiK3NHQ/RPCZWujYaGiisGpuYTwMNGwOcplvWFUFnD2
 G28h6hpclDfEskydrSdMCeUYvfEYUjHItUsrSzm1DqImsD9XQtbXQN1mEa8QQoRIsKW3
 tmvF5uqCr+MfbGhLeA+ycvBvlwTNWwjHNPdnzxfPCKZsHfPA/Hj0X4vUvy6xfuhS0xQL
 oFLcd/ISUi5AAHSVGLsAVNN09X8SzQx9J9PM2f/crBR07Q4I5ALt9gzm1aNpsr6EKGxp
 I20w==
X-Gm-Message-State: AGi0PualF7xo3/5Cg18xO1CZkGUsQ/67AyvIck7xLoaBXC+2sVOqlt9n
 liaD0S2jdaxSCaSSn+ATcog=
X-Google-Smtp-Source: APiQypIrq14R99vJly/PYAexLmQqsxEa8wp1zM7rRr5lpI2rH6ZjOKGWrjdugVpiztcSWyteedvnlA==
X-Received: by 2002:a1c:1904:: with SMTP id 4mr15496465wmz.21.1586725809996;
 Sun, 12 Apr 2020 14:10:09 -0700 (PDT)
Received: from localhost.localdomain (116.red-83-42-57.dynamicip.rima-tde.net.
 [83.42.57.116])
 by smtp.gmail.com with ESMTPSA id o16sm12553602wrs.44.2020.04.12.14.10.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 12 Apr 2020 14:10:09 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
To: qemu-devel@nongnu.org
Subject: [PATCH-for-5.1 3/3] hw: Remove unnecessary DEVICE() cast
Date: Sun, 12 Apr 2020 23:09:54 +0200
Message-Id: <20200412210954.32313-4-f4bug@amsat.org>
X-Mailer: git-send-email 2.21.1
In-Reply-To: <20200412210954.32313-1-f4bug@amsat.org>
References: <20200412210954.32313-1-f4bug@amsat.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>,
 John Snow <jsnow@redhat.com>, Richard Henderson <rth@twiddle.net>,
 =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>,
 =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The DEVICE() macro is defined as:

  #define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)

Remove unnecessary DEVICE() casts.

Patch created mechanically using spatch with this script:

  @@
  typedef DeviceState;
  DeviceState *s;
  @@
  -   DEVICE(s)
  +   s

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/display/artist.c         | 2 +-
 hw/display/cg3.c            | 2 +-
 hw/display/sm501.c          | 2 +-
 hw/display/tcx.c            | 4 ++--
 hw/display/vga-isa.c        | 2 +-
 hw/i2c/imx_i2c.c            | 2 +-
 hw/i2c/mpc_i2c.c            | 2 +-
 hw/ide/piix.c               | 2 +-
 hw/misc/macio/pmu.c         | 2 +-
 hw/net/ftgmac100.c          | 3 +--
 hw/net/imx_fec.c            | 2 +-
 hw/nubus/nubus-device.c     | 2 +-
 hw/pci-host/bonito.c        | 2 +-
 hw/ppc/spapr.c              | 2 +-
 hw/sh4/sh_pci.c             | 2 +-
 hw/xen/xen-legacy-backend.c | 2 +-
 16 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/hw/display/artist.c b/hw/display/artist.c
index 753dbb9a77..7e2a4556bd 100644
--- a/hw/display/artist.c
+++ b/hw/display/artist.c
@@ -1353,7 +1353,7 @@ static void artist_realizefn(DeviceState *dev, Error **errp)
     s->cursor_height = 32;
     s->cursor_width = 32;
 
-    s->con = graphic_console_init(DEVICE(dev), 0, &artist_ops, s);
+    s->con = graphic_console_init(dev, 0, &artist_ops, s);
     qemu_console_resize(s->con, s->width, s->height);
 }
 
diff --git a/hw/display/cg3.c b/hw/display/cg3.c
index a1ede10394..f7f1c199ce 100644
--- a/hw/display/cg3.c
+++ b/hw/display/cg3.c
@@ -321,7 +321,7 @@ static void cg3_realizefn(DeviceState *dev, Error **errp)
 
     sysbus_init_irq(sbd, &s->irq);
 
-    s->con = graphic_console_init(DEVICE(dev), 0, &cg3_ops, s);
+    s->con = graphic_console_init(dev, 0, &cg3_ops, s);
     qemu_console_resize(s->con, s->width, s->height);
 }
 
diff --git a/hw/display/sm501.c b/hw/display/sm501.c
index de0ab9d977..2a564889bd 100644
--- a/hw/display/sm501.c
+++ b/hw/display/sm501.c
@@ -1839,7 +1839,7 @@ static void sm501_init(SM501State *s, DeviceState *dev,
                                 &s->twoD_engine_region);
 
     /* create qemu graphic console */
-    s->con = graphic_console_init(DEVICE(dev), 0, &sm501_ops, s);
+    s->con = graphic_console_init(dev, 0, &sm501_ops, s);
 }
 
 static const VMStateDescription vmstate_sm501_state = {
diff --git a/hw/display/tcx.c b/hw/display/tcx.c
index 76de16e8ea..1fb45b1aab 100644
--- a/hw/display/tcx.c
+++ b/hw/display/tcx.c
@@ -868,9 +868,9 @@ static void tcx_realizefn(DeviceState *dev, Error **errp)
     sysbus_init_irq(sbd, &s->irq);
 
     if (s->depth == 8) {
-        s->con = graphic_console_init(DEVICE(dev), 0, &tcx_ops, s);
+        s->con = graphic_console_init(dev, 0, &tcx_ops, s);
     } else {
-        s->con = graphic_console_init(DEVICE(dev), 0, &tcx24_ops, s);
+        s->con = graphic_console_init(dev, 0, &tcx24_ops, s);
     }
     s->thcmisc = 0;
 
diff --git a/hw/display/vga-isa.c b/hw/display/vga-isa.c
index 0633ed382c..3aaeeeca1e 100644
--- a/hw/display/vga-isa.c
+++ b/hw/display/vga-isa.c
@@ -74,7 +74,7 @@ static void vga_isa_realizefn(DeviceState *dev, Error **errp)
                                         0x000a0000,
                                         vga_io_memory, 1);
     memory_region_set_coalescing(vga_io_memory);
-    s->con = graphic_console_init(DEVICE(dev), 0, s->hw_ops, s);
+    s->con = graphic_console_init(dev, 0, s->hw_ops, s);
 
     memory_region_add_subregion(isa_address_space(isadev),
                                 VBE_DISPI_LFB_PHYSICAL_ADDRESS,
diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
index 30b9aea247..2e02e1c4fa 100644
--- a/hw/i2c/imx_i2c.c
+++ b/hw/i2c/imx_i2c.c
@@ -305,7 +305,7 @@ static void imx_i2c_realize(DeviceState *dev, Error **errp)
                           IMX_I2C_MEM_SIZE);
     sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->iomem);
     sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->irq);
-    s->bus = i2c_init_bus(DEVICE(dev), NULL);
+    s->bus = i2c_init_bus(dev, NULL);
 }
 
 static void imx_i2c_class_init(ObjectClass *klass, void *data)
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
index 0aa1be3ce7..9a724f3a3e 100644
--- a/hw/i2c/mpc_i2c.c
+++ b/hw/i2c/mpc_i2c.c
@@ -332,7 +332,7 @@ static void mpc_i2c_realize(DeviceState *dev, Error **errp)
     memory_region_init_io(&i2c->iomem, OBJECT(i2c), &i2c_ops, i2c,
                           "mpc-i2c", 0x14);
     sysbus_init_mmio(SYS_BUS_DEVICE(dev), &i2c->iomem);
-    i2c->bus = i2c_init_bus(DEVICE(dev), "i2c");
+    i2c->bus = i2c_init_bus(dev, "i2c");
 }
 
 static void mpc_i2c_class_init(ObjectClass *klass, void *data)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 3b2de4c312..b402a93636 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -193,7 +193,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev, bool aux)
             blk_unref(blk);
         }
     }
-    qdev_reset_all(DEVICE(dev));
+    qdev_reset_all(dev);
     return 0;
 }
 
diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
index b8466a4a3f..4b7def9096 100644
--- a/hw/misc/macio/pmu.c
+++ b/hw/misc/macio/pmu.c
@@ -758,7 +758,7 @@ static void pmu_realize(DeviceState *dev, Error **errp)
 
     if (s->has_adb) {
         qbus_create_inplace(&s->adb_bus, sizeof(s->adb_bus), TYPE_ADB_BUS,
-                            DEVICE(dev), "adb.0");
+                            dev, "adb.0");
         s->adb_poll_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL, pmu_adb_poll, s);
         s->adb_poll_mask = 0xffff;
         s->autopoll_rate_ms = 20;
diff --git a/hw/net/ftgmac100.c b/hw/net/ftgmac100.c
index 041ed21017..25ebee7ec2 100644
--- a/hw/net/ftgmac100.c
+++ b/hw/net/ftgmac100.c
@@ -1035,8 +1035,7 @@ static void ftgmac100_realize(DeviceState *dev, Error **errp)
     qemu_macaddr_default_if_unset(&s->conf.macaddr);
 
     s->nic = qemu_new_nic(&net_ftgmac100_info, &s->conf,
-                          object_get_typename(OBJECT(dev)), DEVICE(dev)->id,
-                          s);
+                          object_get_typename(OBJECT(dev)), dev->id, s);
     qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
 }
 
diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
index a35c33683e..7adcc9df65 100644
--- a/hw/net/imx_fec.c
+++ b/hw/net/imx_fec.c
@@ -1323,7 +1323,7 @@ static void imx_eth_realize(DeviceState *dev, Error **errp)
 
     s->nic = qemu_new_nic(&imx_eth_net_info, &s->conf,
                           object_get_typename(OBJECT(dev)),
-                          DEVICE(dev)->id, s);
+                          dev->id, s);
 
     qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
 }
diff --git a/hw/nubus/nubus-device.c b/hw/nubus/nubus-device.c
index 01ccad9e8e..ffe78a8823 100644
--- a/hw/nubus/nubus-device.c
+++ b/hw/nubus/nubus-device.c
@@ -156,7 +156,7 @@ void nubus_register_rom(NubusDevice *dev, const uint8_t *rom, uint32_t size,
 
 static void nubus_device_realize(DeviceState *dev, Error **errp)
 {
-    NubusBus *nubus = NUBUS_BUS(qdev_get_parent_bus(DEVICE(dev)));
+    NubusBus *nubus = NUBUS_BUS(qdev_get_parent_bus(dev));
     NubusDevice *nd = NUBUS_DEVICE(dev);
     char *name;
     hwaddr slot_offset;
diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
index cc6545c8a8..f212796044 100644
--- a/hw/pci-host/bonito.c
+++ b/hw/pci-host/bonito.c
@@ -606,7 +606,7 @@ static void bonito_pcihost_realize(DeviceState *dev, Error **errp)
     BonitoState *bs = BONITO_PCI_HOST_BRIDGE(dev);
 
     memory_region_init(&bs->pci_mem, OBJECT(dev), "pci.mem", BONITO_PCILO_SIZE);
-    phb->bus = pci_register_root_bus(DEVICE(dev), "pci",
+    phb->bus = pci_register_root_bus(dev, "pci",
                                      pci_bonito_set_irq, pci_bonito_map_irq,
                                      dev, &bs->pci_mem, get_system_io(),
                                      0x28, 32, TYPE_PCI_BUS);
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 9a2bd501aa..3337f5e79c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -4031,7 +4031,7 @@ static void spapr_phb_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
     /* hotplug hooks should check it's enabled before getting this far */
     assert(drc);
 
-    spapr_drc_attach(drc, DEVICE(dev), &local_err);
+    spapr_drc_attach(drc, dev, &local_err);
     if (local_err) {
         error_propagate(errp, local_err);
         return;
diff --git a/hw/sh4/sh_pci.c b/hw/sh4/sh_pci.c
index 08f2fc1dde..0a3e86f949 100644
--- a/hw/sh4/sh_pci.c
+++ b/hw/sh4/sh_pci.c
@@ -129,7 +129,7 @@ static void sh_pci_device_realize(DeviceState *dev, Error **errp)
     for (i = 0; i < 4; i++) {
         sysbus_init_irq(sbd, &s->irq[i]);
     }
-    phb->bus = pci_register_root_bus(DEVICE(dev), "pci",
+    phb->bus = pci_register_root_bus(dev, "pci",
                                      sh_pci_set_irq, sh_pci_map_irq,
                                      s->irq,
                                      get_system_memory(),
diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
index 4a373b2373..f9d013811a 100644
--- a/hw/xen/xen-legacy-backend.c
+++ b/hw/xen/xen-legacy-backend.c
@@ -705,7 +705,7 @@ int xen_be_init(void)
 
     xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
     qdev_init_nofail(xen_sysdev);
-    xen_sysbus = qbus_create(TYPE_XENSYSBUS, DEVICE(xen_sysdev), "xen-sysbus");
+    xen_sysbus = qbus_create(TYPE_XENSYSBUS, xen_sysdev, "xen-sysbus");
     qbus_set_bus_hotplug_handler(xen_sysbus, &error_abort);
 
     return 0;
-- 
2.21.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 12 22:02:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 22:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNkgm-0003EM-6J; Sun, 12 Apr 2020 22:02:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=6Dwh=54=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jNkgl-0003EF-JE
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 22:02:51 +0000
X-Inumbo-ID: 57e82190-7d09-11ea-b58d-bc764e2007e4
Received: from mail-qv1-xf43.google.com (unknown [2607:f8b0:4864:20::f43])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 57e82190-7d09-11ea-b58d-bc764e2007e4;
 Sun, 12 Apr 2020 22:02:47 +0000 (UTC)
Received: by mail-qv1-xf43.google.com with SMTP id q73so3616609qvq.2
 for <xen-devel@lists.xenproject.org>; Sun, 12 Apr 2020 15:02:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=EYuJy7ICD2kfNTKAB5E+SVFDtpQL5zTM1dMZH8Nfw14=;
 b=ADa+qUn5NQzV1qu4k6654JciCe63UHdb3SDQW9LOG4BvO3u9NLetoxp0KDUSNTWaZf
 jKCsdqZxSu2snqj/vc4AULhFMgKyThQMhgmvUYdYRFvuPFbA6yiVhO1izoacj1i8toQl
 XeNMrwTWDu33P2mT3SbSyQ4E0GE8gsVshcSdYpdbuGLYBU4u9yXTC6Fz4AMhx9E5hI6v
 7C0B7Z/TWEsx9/pLK7Kanm/o4JsW6e76sRiDuaHAQGFrd3PS05vdEhM0BJE3KLzSDhng
 4UU80/mYEMJsZm8YvEe0ggSQ0mCcCJetaT61TDJW9uys377wmFyfaBdOjgRURcDMp8Mv
 Ssrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=EYuJy7ICD2kfNTKAB5E+SVFDtpQL5zTM1dMZH8Nfw14=;
 b=uXtcnXXXR7yzBMzektehxuZMWVuOWZINBrrODBaq18TsCUgI1QRCp+zlK3r2VWeX1F
 xpNrg2fqE5GooXCrCR+xNdTAoPSQwy9ZsozqlNSXI9b/xTa46kSPqlwNG+oVIuLlIQ6h
 ua8EPG2Ps+Qy6Qwug74Gk7E7Vmot+Qc2iOvkVVeXxJ5VXXMR0zru2kAEn1gjkZLDbWXe
 KgE3WQtAE2OTfN/7JVgw380yrKRbshQwiAjvzbNuBZoI3Y4UuRw3q7cZgg9G0wEHSqV1
 UKJIVy6Urag3MonBXBPXaKzyYn0J0jRl3tI9Ejnul4NZyLZALDwP7gJXD2NHWs/FMmQW
 0TCQ==
X-Gm-Message-State: AGi0PuadroHCD4lUZlsZRgC1Sw+p+NMszvln0TyxKtUeMpsjRhnogiNM
 LNgGaRKHW7+IjvjRGWc0b9WANF7s
X-Google-Smtp-Source: APiQypKOSKazjyYGBfbvqjoDULajgQ4tkzHcgT01amGgnMryarJC3NHwfSK8I5N3KYiDpNCYXdpyVQ==
X-Received: by 2002:a05:6214:1e5:: with SMTP id
 c5mr14095258qvu.79.1586728966528; 
 Sun, 12 Apr 2020 15:02:46 -0700 (PDT)
Received: from four.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id
 s14sm3691128qts.70.2020.04.12.15.02.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 12 Apr 2020 15:02:45 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 1/4] golang/xenlight: add NameToDomid and DomidToName util
 functions
Date: Sun, 12 Apr 2020 18:02:39 -0400
Message-Id: <e2d8d6c1293c8251be881cd471265aa8188ae2ae.1586727061.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586727061.git.rosbrookn@ainfosec.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1586727061.git.rosbrookn@ainfosec.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Many exported functions in xenlight require a domid as an argument. Make
it easier for package users to use these functions by adding wrappers
for the libxl utility functions libxl_name_to_domid and
libxl_domid_to_name.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 tools/golang/xenlight/xenlight.go | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go
index 3f1b0baa0c..8492bcec4e 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -20,6 +20,7 @@ package xenlight
 #cgo LDFLAGS: -lxenlight -lyajl -lxentoollog
 #include <stdlib.h>
 #include <libxl.h>
+#include <libxl_utils.h>
 */
 import "C"
 
@@ -124,6 +125,28 @@ func (ctx *Context) Close() error {
 
 type Domid uint32
 
+// NameToDomid returns the Domid for a domain, given its name, if it exists.
+func (Ctx *Context) NameToDomid(name string) (Domid, error) {
+	var domid C.uint32_t
+
+	cname := C.CString(name)
+	defer C.free(unsafe.Pointer(cname))
+
+	if ret := C.libxl_name_to_domid(Ctx.ctx, cname, &domid); ret != 0 {
+		return ^Domid(0), Error(ret)
+	}
+
+	return Domid(domid), nil
+}
+
+// DomidToName returns the name for a domain, given its domid.
+func (Ctx *Context) DomidToName(domid Domid) string {
+	cname := C.libxl_domid_to_name(Ctx.ctx, C.uint32_t(domid))
+	defer C.free(unsafe.Pointer(cname))
+
+	return C.GoString(cname)
+}
+
 // Devid is a device ID.
 type Devid int
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 12 22:02:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 22:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNkgh-0003E6-UJ; Sun, 12 Apr 2020 22:02:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=6Dwh=54=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jNkgg-0003E1-Md
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 22:02:46 +0000
X-Inumbo-ID: 571dbffe-7d09-11ea-9e09-bc764e2007e4
Received: from mail-qv1-xf32.google.com (unknown [2607:f8b0:4864:20::f32])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 571dbffe-7d09-11ea-9e09-bc764e2007e4;
 Sun, 12 Apr 2020 22:02:45 +0000 (UTC)
Received: by mail-qv1-xf32.google.com with SMTP id p19so3623064qve.0
 for <xen-devel@lists.xenproject.org>; Sun, 12 Apr 2020 15:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id;
 bh=X1ne37QH5/7OmlCnIJ9e1GSI+c/VrIQVzdX6oGyg7XE=;
 b=PcYpRlmrntk2nNpdruBe+8QT6kBRVGy/4f2NtIqN/cE3TnwsXLBz9ueY9MNg1Hq7Gq
 CpEMoxFQ4RzPTsiVx7DtBtl25oXHS5bII+xf6Lwd0gUvMKHoAEQaLqYiKZ4Ns9nIfK3A
 zSZIhDDYBeU7XDUYu6jrZW8XsX67dlYmmdop3VnRRQOaZOP11cV46dzUgCw6fJVMOBb7
 AeQKi7aZHE8TKMWPDUZokOJVAYydt4b8NYsmBgNBTc8dLnSAEKqulEPUEAc7qu9l2hKY
 DA8pCDGeQIju/upJK7VKk5/iNoqMbfFyEXSaBzX2G9ML3b+/TJbmN7lVJ57p7B7/CMtK
 P/UQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id;
 bh=X1ne37QH5/7OmlCnIJ9e1GSI+c/VrIQVzdX6oGyg7XE=;
 b=MiAJ32ARHji8GJ7RnTL3keQsxEPwnrrfuMJT5+djutEd8wogesfnLnhViXUoBVVBXE
 oNHcc9BNyN7wX4RGN61ma8Hk/SaI4r/3yy2sIjkG6W6xdsK7F1gDvvJ9hduAz16fsYiq
 YjeWN8AS8Wd8N+x2mcnvPZxPFcLAVaib66UNsXfLzDPYOW8FrEwng/z2QxkOfPACvj9u
 SZ0LqLJzgqrdP1+jJ01w/+nkrREP33TNVmf1bQs8yI2YiGj24Ly0eMsmJN4w8/yiPaEI
 7ls/bLQekaxQDDuJIdBh3ZjiC/RLqEHI5avZtJ938wyFcCIcWF/pWOoM4d5hx4GC06gp
 Qliw==
X-Gm-Message-State: AGi0PuYTC7QRWu06n6oZ41FdvAe5ZC8zsd9rTwLpnRw53CfdRgwf4kFS
 qH9ZhEmMGd/qW0u8IlFQkhtmbhzx
X-Google-Smtp-Source: APiQypIrmw56dwVAmnbts3VpWk0tDXbp3qfR35plRd9ylvB7nGLIvQSeYtHgdPfqopzFnP9WGHt1IQ==
X-Received: by 2002:ad4:4b62:: with SMTP id m2mr14546040qvx.130.1586728965212; 
 Sun, 12 Apr 2020 15:02:45 -0700 (PDT)
Received: from four.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id
 s14sm3691128qts.70.2020.04.12.15.02.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 12 Apr 2020 15:02:44 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/4] More wrappers for xenlight Go package
Date: Sun, 12 Apr 2020 18:02:38 -0400
Message-Id: <cover.1586727061.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This series adds wrappers to the xenlight package for various libxl
functions, which are now trivial to add with the generated types and
marshaling helpers. In particular, these are functions that would allow 
redctl to begin making the transition to using the xenlight package. For
reference, I have started an experimental branch where I am using these
functions in redctl [1].

[1] https://gitlab.com/enr0n/redctl/-/blob/1bdf7b515654cc030e095f3a630a24530f930c00/internal/server/xenlight_xen_driver.go

Nick Rosbrook (4):
  golang/xenlight: add NameToDomid and DomidToName util functions
  golang/xenlight: add DeviceNicAdd/Remove wrappers
  golang/xenlight: add DevicePciAdd/Remove wrappers
  golang/xenlight: add DeviceUsbdevAdd/Remove wrappers

 tools/golang/xenlight/xenlight.go | 125 ++++++++++++++++++++++++++++++
 1 file changed, 125 insertions(+)

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 12 22:02:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 22:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNkgr-0003F9-Et; Sun, 12 Apr 2020 22:02:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=6Dwh=54=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jNkgq-0003Et-JU
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 22:02:56 +0000
X-Inumbo-ID: 58aeefa0-7d09-11ea-b4f4-bc764e2007e4
Received: from mail-qv1-xf43.google.com (unknown [2607:f8b0:4864:20::f43])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 58aeefa0-7d09-11ea-b4f4-bc764e2007e4;
 Sun, 12 Apr 2020 22:02:48 +0000 (UTC)
Received: by mail-qv1-xf43.google.com with SMTP id v38so3606207qvf.6
 for <xen-devel@lists.xenproject.org>; Sun, 12 Apr 2020 15:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=C5Z/EnHHQ5Xpy674QajNb7wsUJqqHSMnmxzzSFt1iQQ=;
 b=MX/Q6FfLCQ5XTurVk020jRSRyuuilXNSsBai31olDuDsraqXF1lGZzQn+BwtH4lbMF
 q0Rj6sCHgYga6RnOGwPn7u8CXcW5jo/Z2H+x18AFRaRvaPzNjE38FqBGQwOZ4Q3ETFPX
 M4fraq3B0ZLxY+3TFH8jWYClekWROyeb/r3zs9FnIQMz/2Gp+RzEZcc6HvlHt2UyAJdt
 KAt1dBVyuqs75pE2e+KR1FiKf9TBJcilmzCsd1Eep8lAz5RzbRBrBsJLxZSzQm46ncqO
 zGOyFM2U20EgHH5t9gn9OMS6Daz5w4J1oVeLLETydITTYhPtWykgvp3iMXdjyb0GeoGY
 VcQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=C5Z/EnHHQ5Xpy674QajNb7wsUJqqHSMnmxzzSFt1iQQ=;
 b=n831loBBNNqke7AqYfna+NLcxz3BNkMBQrPT/oGJXB6/ww/xUWcxnvC2sGA4OJSLuN
 XsIZ26TfNl1gO9aZxIeJwhj3u/D1IB7+TZQ6VC5tgwUsEMvnsBkJiqfwI+BwtWZK+CN3
 OcOfcTtvwHn4NcnUZNhYs08Wpv7/GwPd+CDZibdwvnNxiUxKooxJSKROdMhoWQaOP011
 8IYVmxPpgyPVxzliED6qsjX1sNpL8jnKi5qrg/mVJQt1TsqowNIkXwLiAv9FpAOA6Cc3
 DyzKWNvf2lYdpsvb4G9CZyUrsZQCAq2W2RxSyhsz6JgCHEM9SV/Q0uTHX3f7nuZC7SPT
 rrgw==
X-Gm-Message-State: AGi0PuaiQ8bAUbsoQMY1naeqeG25nnzVslzh+OsFWoRpcaUdMWsuGh8x
 Y1CbdeCcFFSb86oeilzMNazccuZA
X-Google-Smtp-Source: APiQypIS/w2ctfqHkQIrT294kCGqJR6TnqQmLIUCoTCg63aIBkpeaw0jq/qYc2pAYJtgwrZmFDMcaQ==
X-Received: by 2002:ad4:5184:: with SMTP id b4mr14550655qvp.221.1586728967851; 
 Sun, 12 Apr 2020 15:02:47 -0700 (PDT)
Received: from four.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id
 s14sm3691128qts.70.2020.04.12.15.02.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 12 Apr 2020 15:02:47 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 2/4] golang/xenlight: add DeviceNicAdd/Remove wrappers
Date: Sun, 12 Apr 2020 18:02:40 -0400
Message-Id: <87323a6eb60fd908ea2f792c9754cb88b283c5a6.1586727061.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586727061.git.rosbrookn@ainfosec.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1586727061.git.rosbrookn@ainfosec.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add DeviceNicAdd and DeviceNicRemove as wrappers for
libxl_device_nic_add and libxl_device_nic_remove.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 tools/golang/xenlight/xenlight.go | 34 +++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go
index 8492bcec4e..a56f913b81 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -1068,3 +1068,37 @@ func (Ctx *Context) PrimaryConsoleGetTty(domid uint32) (path string, err error)
 	path = C.GoString(cpath)
 	return
 }
+
+// DeviceNicAdd adds a nic to a domain.
+func (Ctx *Context) DeviceNicAdd(domid Domid, nic *DeviceNic) error {
+	var cnic C.libxl_device_nic
+
+	if err := nic.toC(&cnic); err != nil {
+		return err
+	}
+	defer C.libxl_device_nic_dispose(&cnic)
+
+	ret := C.libxl_device_nic_add(Ctx.ctx, C.uint32_t(domid), &cnic, nil)
+	if ret != 0 {
+		return Error(ret)
+	}
+
+	return nil
+}
+
+// DeviceNicRemove removes a nic from a domain.
+func (Ctx *Context) DeviceNicRemove(domid Domid, nic *DeviceNic) error {
+	var cnic C.libxl_device_nic
+
+	if err := nic.toC(&cnic); err != nil {
+		return err
+	}
+	defer C.libxl_device_nic_dispose(&cnic)
+
+	ret := C.libxl_device_nic_remove(Ctx.ctx, C.uint32_t(domid), &cnic, nil)
+	if ret != 0 {
+		return Error(ret)
+	}
+
+	return nil
+}
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 12 22:03:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 22:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNkgw-0003Gh-Ng; Sun, 12 Apr 2020 22:03:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=6Dwh=54=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jNkgv-0003GM-Jg
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 22:03:01 +0000
X-Inumbo-ID: 597b2f70-7d09-11ea-83d8-bc764e2007e4
Received: from mail-qt1-x842.google.com (unknown [2607:f8b0:4864:20::842])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 597b2f70-7d09-11ea-83d8-bc764e2007e4;
 Sun, 12 Apr 2020 22:02:49 +0000 (UTC)
Received: by mail-qt1-x842.google.com with SMTP id z90so5859322qtd.10
 for <xen-devel@lists.xenproject.org>; Sun, 12 Apr 2020 15:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=xQseH+w2yE4yJYVdULOAupSEFUC15dIoKjSVtzW1RYQ=;
 b=mbXds/yMXXI77oozv1GEuKTLmqLlNMAuQy5DVvhXLICyJHvTtY/UBdkRokROlrE5iu
 ZZg4GrhROG5Aan+JfINU5GFQWhgErhwCAi7xcsj4m55nmWOpFSrkB2u7rY3KWAusdXuR
 XZErv2fJ0Jut+rjwSbd8tBDO9H+zCBFH+oNY+hOnyAYPjKlxDAglE3gAnu4a7NBU8s+7
 tF342TiNmwKvsMG2apnmqUyxALTHOaro2HI41a/EFWeZcQpWLeMlD2USNh3BpcZ47Tqj
 Gmebw/A5qgWNivdalS8VnZy62AHTOlnCpt0EDd3PB3znoZJ9wtMDzrgxxiHNTQNd3EQb
 aAoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=xQseH+w2yE4yJYVdULOAupSEFUC15dIoKjSVtzW1RYQ=;
 b=lx58xuDUR7Nohsqs/Bxt30Jr9+tvusQ6dZ6bfc7zb44sBkyv8/F3ZYsTdQr5GOCYTa
 vbPsex0jLSahZ242UcA42tylGmIM/iOnO5P1oScDVwamieQDbLFFuIgzdl1jPLwC0S5N
 loycoacAo4jisazzg2KPRccYB87r7441wjbyikN/clPSLa5JBbP28b1wFdHrff9xZtT/
 yXq7foFiKOst/WiduSNQlpU3Dova2T6o773R2y2UhgfAvggbGfqBw+Lxgk8rYWy9ZM2A
 BUQtxDkzOX1pu7pZlYadQplb//osnh8t5HeSSPiUSdVGmLe1ERQg8kfM+mF05eap02Zc
 2sbQ==
X-Gm-Message-State: AGi0PubBP5zaFYg5ge7OM6B1RiQu9li5X++U5uZRSOe4QDja3NjeOPH6
 0H3JCpRzK1RmR5vAjTJhsqfX7q6o
X-Google-Smtp-Source: APiQypIacsGj1YC3T0eoqwBQppzvgi5VJQQlNAtetUcTtfDHNvyORLAg2oT9k2X/6y9Ww/MHRv7E5w==
X-Received: by 2002:ac8:6d23:: with SMTP id r3mr8470311qtu.84.1586728969148;
 Sun, 12 Apr 2020 15:02:49 -0700 (PDT)
Received: from four.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id
 s14sm3691128qts.70.2020.04.12.15.02.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 12 Apr 2020 15:02:48 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 3/4] golang/xenlight: add DevicePciAdd/Remove wrappers
Date: Sun, 12 Apr 2020 18:02:41 -0400
Message-Id: <7f03220c9db0a377cd26c0c96d8a10981ec47282.1586727061.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586727061.git.rosbrookn@ainfosec.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1586727061.git.rosbrookn@ainfosec.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add DevicePciAdd and DevicePciRemove as wrappers for
libxl_device_pci_add and libxl_device_pci remove.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 tools/golang/xenlight/xenlight.go | 34 +++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go
index a56f913b81..c94b046667 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -1102,3 +1102,37 @@ func (Ctx *Context) DeviceNicRemove(domid Domid, nic *DeviceNic) error {
 
 	return nil
 }
+
+// DevicePciAdd is used to passthrough a PCI device to a domain.
+func (Ctx *Context) DevicePciAdd(domid Domid, pci *DevicePci) error {
+	var cpci C.libxl_device_pci
+
+	if err := pci.toC(&cpci); err != nil {
+		return err
+	}
+	defer C.libxl_device_pci_dispose(&cpci)
+
+	ret := C.libxl_device_pci_add(Ctx.ctx, C.uint32_t(domid), &cpci, nil)
+	if ret != 0 {
+		return Error(ret)
+	}
+
+	return nil
+}
+
+// DevicePciRemove removes a PCI device from a domain.
+func (Ctx *Context) DevicePciRemove(domid Domid, pci *DevicePci) error {
+	var cpci C.libxl_device_pci
+
+	if err := pci.toC(&cpci); err != nil {
+		return err
+	}
+	defer C.libxl_device_pci_dispose(&cpci)
+
+	ret := C.libxl_device_pci_remove(Ctx.ctx, C.uint32_t(domid), &cpci, nil)
+	if ret != 0 {
+		return Error(ret)
+	}
+
+	return nil
+}
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 12 22:03:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Apr 2020 22:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNkh1-0003IG-0J; Sun, 12 Apr 2020 22:03:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=6Dwh=54=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jNkh0-0003I2-KT
 for xen-devel@lists.xenproject.org; Sun, 12 Apr 2020 22:03:06 +0000
X-Inumbo-ID: 5a4a57c8-7d09-11ea-b4f4-bc764e2007e4
Received: from mail-qt1-x841.google.com (unknown [2607:f8b0:4864:20::841])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5a4a57c8-7d09-11ea-b4f4-bc764e2007e4;
 Sun, 12 Apr 2020 22:02:51 +0000 (UTC)
Received: by mail-qt1-x841.google.com with SMTP id o10so5871336qtr.6
 for <xen-devel@lists.xenproject.org>; Sun, 12 Apr 2020 15:02:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=NmfxgsNf5K3mmZ2//UrmLn1WOxxwaw+HLr7AjrHfqbU=;
 b=mTZ++ghtU3U7tbwnc840P55CJPNfQ0mqSErJPkR0X0pz/kLBYCkRiAqgqIZp6SpFMZ
 4K6o1jBamZWs9TZJWsZcteuRYhhWDYMFi6XPDVJ349EcHyvgRphuC5Bf8L3+wGBBl+ys
 ZFBRHGodTmxTiBM8BsWFv3ZdQHHiOGOzMMamo2M/eeFW9L9dPsyeFegM3K1frkkLaGgM
 f1lHnLuiu6DXEx2wxhg+jB2/4Zet6gYXkWRVAEMbF6UJk74hIBHfnf4pndG0xsYxGnlr
 /0SjvsMVPdQyWUufGVWD0dntbxMr8BkPaypY/5VvZ/F39LeNkkvfQdnuC0AJJPDYzLdJ
 ePjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=NmfxgsNf5K3mmZ2//UrmLn1WOxxwaw+HLr7AjrHfqbU=;
 b=fczmwOQMl54BD2932+XPCEfC8IoImwSidKUZ5LaMn+kXG0vuAh9riDHMo5FCLMA/MB
 gqvtu7kSNPC3PAO73UuadD8zSmFIuhSg7ELSPdiRh2oL/eDcbZns1I1SkiZiObcZGwgS
 Kt869qDZZNVRV3tsiG0L56GWg/ldxQLGmAHKlziCHllCYZJgq+Dy0jbPmV0hYAUfjUQH
 +2uQWCVNrLv8hUp84F5p+X3yp0ZAdAM8/uEKkGj54sFcdto3x+hcFNnk7bt8S0veWcyH
 dxk3MEcBTvmxiAaOf80i5k4ZQGBLLJmR4IreoDrc66QKV9chMJUgc4Ze79zSolXlGfgV
 KijA==
X-Gm-Message-State: AGi0PuZc4HzUuo1z65Sh9p/oqbfSSnOdGwPr+HjeaujN9X97x9siVr10
 u0etOeHkJs27mIf2e6oNqZtuILJ/
X-Google-Smtp-Source: APiQypJEOq8uosf+DmUlGSZcUywLdkAauXybwVTg5BSsXmX6ad/GcygkPdbJtukykyKqpaopmaqZ0w==
X-Received: by 2002:ac8:43c3:: with SMTP id w3mr9103038qtn.350.1586728970375; 
 Sun, 12 Apr 2020 15:02:50 -0700 (PDT)
Received: from four.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id
 s14sm3691128qts.70.2020.04.12.15.02.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 12 Apr 2020 15:02:49 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 4/4] golang/xenlight: add DeviceUsbdevAdd/Remove wrappers
Date: Sun, 12 Apr 2020 18:02:42 -0400
Message-Id: <1fcd31482f5183f29e9d949c6e17183b6b101c8b.1586727061.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586727061.git.rosbrookn@ainfosec.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1586727061.git.rosbrookn@ainfosec.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add DeviceUsbdevAdd and DeviceUsbdevRemove as wrappers for
libxl_device_usbdev_add and libxl_device_usbdev_remove.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 tools/golang/xenlight/xenlight.go | 34 +++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go
index c94b046667..2d45d2bd48 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -1136,3 +1136,37 @@ func (Ctx *Context) DevicePciRemove(domid Domid, pci *DevicePci) error {
 
 	return nil
 }
+
+// DeviceUsbdevAdd adds a USB device to a domain.
+func (Ctx *Context) DeviceUsbdevAdd(domid Domid, usbdev *DeviceUsbdev) error {
+	var cusbdev C.libxl_device_usbdev
+
+	if err := usbdev.toC(&cusbdev); err != nil {
+		return err
+	}
+	defer C.libxl_device_usbdev_dispose(&cusbdev)
+
+	ret := C.libxl_device_usbdev_add(Ctx.ctx, C.uint32_t(domid), &cusbdev, nil)
+	if ret != 0 {
+		return Error(ret)
+	}
+
+	return nil
+}
+
+// DeviceUsbdevRemove removes a USB device from a domain.
+func (Ctx *Context) DeviceUsbdevRemove(domid Domid, usbdev *DeviceUsbdev) error {
+	var cusbdev C.libxl_device_usbdev
+
+	if err := usbdev.toC(&cusbdev); err != nil {
+		return err
+	}
+	defer C.libxl_device_usbdev_dispose(&cusbdev)
+
+	ret := C.libxl_device_usbdev_remove(Ctx.ctx, C.uint32_t(domid), &cusbdev, nil)
+	if ret != 0 {
+		return Error(ret)
+	}
+
+	return nil
+}
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 13 00:45:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 00:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNnE6-0008RB-2O; Mon, 13 Apr 2020 00:45:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=F6Pd=55=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNnE4-0008R6-4D
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 00:45:24 +0000
X-Inumbo-ID: 0a42032c-7d20-11ea-87ec-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0a42032c-7d20-11ea-87ec-12813bfff9fa;
 Mon, 13 Apr 2020 00:45:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=+HPkDkcR7LBTJE3X0CggNcYbKVYTIeD5tNsMSAe4tlg=; b=z3pjn4K6KE8r+QTM4InLgBUD0
 tPsjogBhflCAvh+B2EgzuDX4sdOyVGc0fWInRG6sBLo1NxJNGfwrtlnwT1PxB/mcNbKy0AiE0daj5
 6OyWe5HU27tuEKU7fb8pG/DhADJYniZQVNWmsShJUTik33KXTKVMDGzkLbVu1LLcOm0Eo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNnDv-0005tc-11; Mon, 13 Apr 2020 00:45:15 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNnDu-00037F-A0; Mon, 13 Apr 2020 00:45:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNnDu-0003kv-9B; Mon, 13 Apr 2020 00:45:14 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149631-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149631: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=4f8a3cc1183c442daee6cc65360e3385021131e4
X-Osstest-Versions-That: linux=b032227c62939b5481bcd45442b36dfa263f4a7c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 13 Apr 2020 00:45:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                4f8a3cc1183c442daee6cc65360e3385021131e4
baseline version:
 linux                b032227c62939b5481bcd45442b36dfa263f4a7c

Last test of basis   149628  2020-04-12 03:29:33 Z    0 days
Testing same since   149631  2020-04-12 17:39:35 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrei Vagin <avagin@gmail.com>
  Aubrey Li <aubrey.li@intel.com>
  Aubrey Li <aubrey.li@linux.intel.com>
  Aurelien Aptel <aaptel@suse.com>
  Borislav Petkov <bp@suse.de>
  Christian Brauner <christian.brauner@ubuntu.com>
  Dmitry Safonov <dima@arista.com>
  Huaixin Chang <changhuaixin@linux.alibaba.com>
  Ian Rogers <irogers@google.com>
  Ingo Molnar <mingo@kernel.org>
  Jan Kara <jack@suse.cz>
  Jann Horn <jannh@google.com>
  Jiri Olsa <jolsa@kernel.org>
  Kan Liang <kan.liang@linux.intel.com>
  Kees Cook <keescook@chromium.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Long Li <longli@microsoft.com>
  Mel Gorman <mgorman@suse.de>
  Michael Kerrisk (man-pages) <mtk.manpages@gmail.com>
  Michael Kerrisk <mtk.manpages@gmail.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Shilovsky <pshilov@microsoft.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Peter Zijlstra <peterz@infradead.org>
  Qian Cai <cai@lca.pw>
  Sean Christopherson <sean.j.christopherson@intel.com>
  Sebastian Andrzej Siewior <bigeasy@linutronix.de>
  Song Liu <songliubraving@fb.com>
  Steve French <stfrench@microsoft.com>
  Thomas Gleixner <tglx@linutronix.de>
  Trond Myklebust <trond.myklebust@hammerspace.com>
  Valentin Schneider <valentin.schneider@arm.com>
  Vincent Donnefort <vincent.donnefort@arm.com>
  Vincenzo Frascino <vincenzo.frascino@arm.com>
  Will Deacon <will@kernel.org>
  Xiaoyao Li <xiaoyao.li@intel.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   b032227c6293..4f8a3cc1183c  4f8a3cc1183c442daee6cc65360e3385021131e4 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 06:12:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 06:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNsJu-0004ba-E8; Mon, 13 Apr 2020 06:11:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=F6Pd=55=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNsJt-0004bV-Q3
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 06:11:45 +0000
X-Inumbo-ID: a28e95d3-7d4d-11ea-8807-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a28e95d3-7d4d-11ea-8807-12813bfff9fa;
 Mon, 13 Apr 2020 06:11:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=RTIGtUN3/nS+Uz9Bn1Te0Pdph0uAROuIzivJ3180AkY=; b=rBt+NYwpTAOAg95+NkYhaIHPs
 We0SJ8ErbCLY+Glr315aY6j8zxoEzvFZRSjTlgjtsvbm9/9WdWHFRJuTvKm36cpj22BFdxzj2gNuL
 o4jBqT6rQ2EP65MuAHDTOv++fU6c4FiLUnq0oX7akYp0RxvT4+JSqDLv4zZ8X53oH1Lw8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNsJm-0000vd-D0; Mon, 13 Apr 2020 06:11:38 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNsJl-0001TI-Vi; Mon, 13 Apr 2020 06:11:38 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNsJl-00048j-U7; Mon, 13 Apr 2020 06:11:37 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149633-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149633: all pass - PUSHED
X-Osstest-Versions-This: ovmf=48b6c60cc6a234d971d7ca97f7cd0ca9a9499de5
X-Osstest-Versions-That: ovmf=a5d8a399635d86c8155a252874fbf3c0e6613d34
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 13 Apr 2020 06:11:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 48b6c60cc6a234d971d7ca97f7cd0ca9a9499de5
baseline version:
 ovmf                 a5d8a399635d86c8155a252874fbf3c0e6613d34

Last test of basis   149594  2020-04-10 07:41:48 Z    2 days
Testing same since   149633  2020-04-13 01:39:17 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Shenglei Zhang <shenglei.zhang@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   a5d8a39963..48b6c60cc6  48b6c60cc6a234d971d7ca97f7cd0ca9a9499de5 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 06:38:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 06:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNsjP-0006NW-J3; Mon, 13 Apr 2020 06:38:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=F6Pd=55=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNsjO-0006NR-Tz
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 06:38:06 +0000
X-Inumbo-ID: 5358e00e-7d51-11ea-880a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5358e00e-7d51-11ea-880a-12813bfff9fa;
 Mon, 13 Apr 2020 06:38:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=31JY2LmCAraP+ODdxJVPsbnQwcGsbr+pteFH/ZxC68s=; b=GsA15pFJKRb2X2LH+bIR+kvRH
 qoJIvxC1mdpZK404nsJSeMyc/tPfQMa/xwaX4thXjKLVebn5Z7xtEvYZkMbgLa02GnFX+eyW0u8ct
 o25m1KhnHV95qxRSCfqrUqOgUVVSpqYpchoEIB6mUKNGT/7c59zGP4CeNikO5ePoGkqYU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNsjK-0001Ri-V4; Mon, 13 Apr 2020 06:38:02 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNsjK-000360-DM; Mon, 13 Apr 2020 06:38:02 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNsjK-0003W3-CN; Mon, 13 Apr 2020 06:38:02 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149635-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149635: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=7118bdee1550b6022e7362402ca8204add4cf80b
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 13 Apr 2020 06:38:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              7118bdee1550b6022e7362402ca8204add4cf80b
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   87 days
Failing since        146211  2020-01-18 04:18:52 Z   86 days   83 attempts
Testing same since   149635  2020-04-13 04:19:36 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 14534 lines long.)


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 06:52:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 06:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNswu-0007wW-Sz; Mon, 13 Apr 2020 06:52:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=n3x4=55=bitdefender.com=aisaila@srs-us1.protection.inumbo.net>)
 id 1jNswu-0007wR-0V
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 06:52:04 +0000
X-Inumbo-ID: 460f77bc-7d53-11ea-880b-12813bfff9fa
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown
 [40.107.8.92]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 460f77bc-7d53-11ea-880b-12813bfff9fa;
 Mon, 13 Apr 2020 06:52:00 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Bcj9gA+uXzoIeibzmhDpzZYembPu4QViG2aE0iBiEDfYStEYHlmXN7JJqGqPSRSLGn8GdILElWpqQ0Kw0KydKh6emKCMn8AIT9U7FzTGqTVykt6ZTq8JuJS8qEZcjPX3lzzJ/LCwyaS+3t8WvcjKKPSFGbJp6CLWbuirkgyaBS8d1D4vcfPW6Wm1KbEUIro5m00qvia4Cxqo3NaCtoNs0svX13zFgSUcgK/DZ0lQTmp2LSw2q/cR6TDGaKtOzXuC6ACXd4eK3pTQFiQJ6kc+EzzxdEkSnvx7te7Wj9M4mfAbaVQRLhemjxI8WfJG8PxUQCcdHcUa+UOFQiMDzB5dgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7QzEw+1BvDSeBTXaXGXByBYUrTmWqSehZ2H4OfyBOHg=;
 b=KVYjEkp47nTsBBb3EqZAFU0Q/mYyNhMnBYpb8Vy8g35HQMfHXRZtKID3iNZakrW2E/DJH4KDGi+RENNQPcKWYMikYG7rqwCT+Ti4uGes11sH9E1qR6zGoLjudHCuk92JS+7Ie2SaOi9qLAErhQRfXKHQm8GafWLYO4iETvCo20AX/wofsMz4YS7gvwBtOwBV1kVo7YSuKmjjklb/5ODNIAFSokcmwQ2KQ8t1w9BZlPbtqE4gZLxmTwrzU3MRVxMqHapZnyrqh/A35OTnJUb0xP/FPQtkf0DOG4AotYF5E4wnMJuRzs2fy/McTKhkMis2oBp2HidSitJUFQ8l+3qqVA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=bitdefender.com; dmarc=pass action=none
 header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7QzEw+1BvDSeBTXaXGXByBYUrTmWqSehZ2H4OfyBOHg=;
 b=ZraW7d4Tmjyj33ALoHrArBP0S0NyCH8N5LISH/AYsoQZxOOCbd/SrACL7YBCGGmVkBJot0Kz8rMvc8ijpSRLt2o2BXSxaElGsn3VDQzIHmHRjtfJm7sUlCKTb6cFHLc0yXVcjpE7U/pak4K1GlrrMt8jEKjxghXwujRN5IKsWYU=
Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=aisaila@bitdefender.com; 
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com (2603:10a6:20b:86::23)
 by AM6PR02MB4689.eurprd02.prod.outlook.com (2603:10a6:20b:35::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17; Mon, 13 Apr
 2020 06:51:57 +0000
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208]) by AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208%4]) with mapi id 15.20.2900.028; Mon, 13 Apr 2020
 06:51:57 +0000
From: Alexandru Isaila <aisaila@bitdefender.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH V8] x86/altp2m: Hypercall to set altp2m view visibility
Date: Mon, 13 Apr 2020 09:51:13 +0300
Message-Id: <20200413065113.27744-1-aisaila@bitdefender.com>
X-Mailer: git-send-email 2.17.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: VI1PR0602CA0021.eurprd06.prod.outlook.com
 (2603:10a6:800:bc::31) To AM6PR02MB5223.eurprd02.prod.outlook.com
 (2603:10a6:20b:86::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from aisaila-Latitude-E5570.dsd.bitdefender.biz (82.77.232.39) by
 VI1PR0602CA0021.eurprd06.prod.outlook.com (2603:10a6:800:bc::31) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17 via Frontend
 Transport; Mon, 13 Apr 2020 06:51:56 +0000
X-Mailer: git-send-email 2.17.1
X-Originating-IP: [82.77.232.39]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 1b8c8f5f-608e-4e17-a7a3-08d7df77289a
X-MS-TrafficTypeDiagnostic: AM6PR02MB4689:|AM6PR02MB4689:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <AM6PR02MB468999B2C607A478F6717D4AABDD0@AM6PR02MB4689.eurprd02.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:386;
X-Forefront-PRVS: 037291602B
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:AM6PR02MB5223.eurprd02.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10019020)(366004)(7416002)(6916009)(6506007)(2616005)(956004)(54906003)(52116002)(1076003)(30864003)(2906002)(66556008)(6486002)(498600001)(66476007)(66946007)(8676002)(8936002)(6666004)(5660300002)(186003)(26005)(16526019)(86362001)(81156014)(6512007)(36756003)(4326008);
 DIR:OUT; SFP:1102; 
Received-SPF: None (protection.outlook.com: bitdefender.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: PYZMv6BmDK3AbNuq8d0SMrDUapeuCLXBHSyLTKQFpba8QuNnDPuhb1TNIvdZZudmfhSqZxeuxqQU6ooWYxyv5ZKPZFuKBRfx/sUuewG3Rt7GrxKYiJ4frW/X2Fn8LfWGkSqhuiH1EgtiLgWtmub5heepJIkjkCzt397Hn1u9kXUGhgD02FJtpdnK/1zh/l8zvTt6/FoTYBg1sB4nH7+J3v97+WRIKfgX/GBFpgmtOsHoP/iFP/lcaWkbw81Fj4+lHeV8oYKtzSo8AB8jvqvqiAIRl6eRjBKS0Xy2WxYSaMwI0i63SsyrdJ6fP5HPxxoHxc/talSWLzmIVCsT+gKVkMtYw5a1CqtmiFsDHtQlKZbLTPOK0poRkYc2QnuTmCScJhnzmVwhaLYFXzSRCGs5x2WgJ/Zf2dHyux87qnDZObAmzo0zLqOqT0mWIT0DSwG5
X-MS-Exchange-AntiSpam-MessageData: U3fUp0HCWWuOb2+Oj2uTe2xxSOLbkold5K046vn/paMWt4/ej2TOICoHBfBxm0H9oG/X83+uUu9nUTDPN/hiG6Ejh3UXGFWcKc/GVVEcj21lHZmxl7jZS8bi5ZzJ4R3CIf6Gfq7/q9HXT9PoiIpiOQ==
X-OriginatorOrg: bitdefender.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b8c8f5f-608e-4e17-a7a3-08d7df77289a
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2020 06:51:57.3259 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Bm4O3U3gnubf4XDWSVVZAGMZqaMKLrLM6SCZXjwR3LTbMk8/j3mMF5Vl/dfHadV2p664Nh7nLbsjZPylMud+WZ/ejzKvJLOokViDuZKLg2I=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR02MB4689
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 George Dunlap <George.Dunlap@eu.citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.

The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.
This is done by having a separate arch.altp2m_working_eptp that is
populated and made invalid in the same places as altp2m_eptp. This is
written to EPTP_LIST_ADDR.
The views are made in/visible by marking them with INVALID_MFN or
copying them back from altp2m_eptp.
To have consistency the visibility also applies to
p2m_switch_domain_altp2m_by_id().

The usage of this hypercall is aimed at dom0 having a logic with a number of views
created and at some time there is a need to be sure that only some of the views
can be switched, saving the rest and making them visible when the time
is right.

Note: If altp2m mode is set to mixed the guest is able to change the view
visibility and then call vmfunc.

Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
---
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wl@xen.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: George Dunlap <George.Dunlap@eu.citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: "Roger Pau Monné" <roger.pau@citrix.com>
CC: Jun Nakajima <jun.nakajima@intel.com>
CC: Kevin Tian <kevin.tian@intel.com>
---
Changes since V7:
	- Change altp2m_working_eptp to altp2m_visible_eptp
	- Rebase.

Changes since V6:
	- Update commit message.

Changes since V5:
	- Change idx type from uint16_t to unsigned int
	- Add rc var and dropped the err return from p2m_get_suppress_ve().

Changes since V4:
	- Move p2m specific things from hvm to p2m.c
	- Add comment for altp2m_idx bounds check
	- Add altp2m_list_lock/unlock().

Changes since V3:
	- Change var name form altp2m_idx to idx to shorten line length
	- Add bounds check for idx
	- Update commit message
	- Add comment in xenctrl.h.

Changes since V2:
	- Drop hap_enabled() check
	- Reduce the indentation depth in hvm.c
	- Fix assignment indentation
	- Drop pad2.

Changes since V1:
	- Drop double view from title.
---
 tools/libxc/include/xenctrl.h   |  7 +++++++
 tools/libxc/xc_altp2m.c         | 24 +++++++++++++++++++++++
 xen/arch/x86/hvm/hvm.c          | 14 ++++++++++++++
 xen/arch/x86/hvm/vmx/vmx.c      |  2 +-
 xen/arch/x86/mm/hap/hap.c       | 15 +++++++++++++++
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m.c           | 34 +++++++++++++++++++++++++++++++--
 xen/include/asm-x86/domain.h    |  1 +
 xen/include/asm-x86/p2m.h       |  4 ++++
 xen/include/public/hvm/hvm_op.h |  9 +++++++++
 10 files changed, 108 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 58fa931de1..5f25c5a6d4 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1943,6 +1943,13 @@ int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
                          xen_pfn_t new_gfn);
 int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
                                uint32_t vcpuid, uint16_t *p2midx);
+/*
+ * Set view visibility for xc_altp2m_switch_to_view and vmfunc.
+ * Note: If altp2m mode is set to mixed the guest is able to change the view
+ * visibility and then call vmfunc.
+ */
+int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
+                             uint16_t view_id, bool visible);
 
 /** 
  * Mem paging operations.
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 46fb725806..6987c9541f 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -410,3 +410,27 @@ int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
     xc_hypercall_buffer_free(handle, arg);
     return rc;
 }
+
+int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
+                             uint16_t view_id, bool visible)
+{
+    int rc;
+
+    DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+
+    arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+    if ( arg == NULL )
+        return -1;
+
+    arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+    arg->cmd = HVMOP_altp2m_set_visibility;
+    arg->domain = domid;
+    arg->u.set_visibility.altp2m_idx = view_id;
+    arg->u.set_visibility.visible = visible;
+
+    rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+                  HYPERCALL_BUFFER_AS_ARG(arg));
+
+    xc_hypercall_buffer_free(handle, arg);
+    return rc;
+}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 827c5fa89d..6f6f3f73a8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4509,6 +4509,7 @@ static int do_altp2m_op(
     case HVMOP_altp2m_get_mem_access:
     case HVMOP_altp2m_change_gfn:
     case HVMOP_altp2m_get_p2m_idx:
+    case HVMOP_altp2m_set_visibility:
         break;
 
     default:
@@ -4786,6 +4787,19 @@ static int do_altp2m_op(
         break;
     }
 
+    case HVMOP_altp2m_set_visibility:
+    {
+        unsigned int idx = a.u.set_visibility.altp2m_idx;
+
+        if ( a.u.set_visibility.pad )
+            rc = -EINVAL;
+        else if ( !altp2m_active(d) )
+            rc = -EOPNOTSUPP;
+        else
+            rc = p2m_set_altp2m_view_visibility(d, idx,
+                                                a.u.set_visibility.visible);
+    }
+
     default:
         ASSERT_UNREACHABLE();
     }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 1c398fdb6e..869339062b 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2140,7 +2140,7 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
     {
         v->arch.hvm.vmx.secondary_exec_control |= mask;
         __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
-        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
+        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_visible_eptp));
 
         if ( cpu_has_vmx_virt_exceptions )
         {
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 814d0c3253..052ae35c6f 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -492,8 +492,17 @@ int hap_enable(struct domain *d, u32 mode)
             goto out;
         }
 
+        if ( (d->arch.altp2m_visible_eptp = alloc_xenheap_page()) == NULL )
+        {
+            rv = -ENOMEM;
+            goto out;
+        }
+
         for ( i = 0; i < MAX_EPTP; i++ )
+        {
             d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+            d->arch.altp2m_visible_eptp[i] = mfn_x(INVALID_MFN);
+        }
 
         for ( i = 0; i < MAX_ALTP2M; i++ )
         {
@@ -527,6 +536,12 @@ void hap_final_teardown(struct domain *d)
             d->arch.altp2m_eptp = NULL;
         }
 
+        if ( d->arch.altp2m_visible_eptp )
+        {
+            free_xenheap_page(d->arch.altp2m_visible_eptp);
+            d->arch.altp2m_visible_eptp = NULL;
+        }
+
         for ( i = 0; i < MAX_ALTP2M; i++ )
             p2m_teardown(d->arch.altp2m_p2m[i]);
     }
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index eb0f0edfef..293f3e9419 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1368,6 +1368,7 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
     ept = &p2m->ept;
     ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
     d->arch.altp2m_eptp[array_index_nospec(i, MAX_EPTP)] = ept->eptp;
+    d->arch.altp2m_visible_eptp[array_index_nospec(i, MAX_EPTP)] = ept->eptp;
 }
 
 unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index b8727e267d..4c1507d3a4 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2533,6 +2533,7 @@ void p2m_flush_altp2m(struct domain *d)
     {
         p2m_reset_altp2m(d, i, ALTP2M_DEACTIVATE);
         d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+        d->arch.altp2m_visible_eptp[i] = mfn_x(INVALID_MFN);
     }
 
     altp2m_list_unlock(d);
@@ -2652,7 +2653,9 @@ int p2m_destroy_altp2m_by_id(struct domain *d, unsigned int idx)
         {
             p2m_reset_altp2m(d, idx, ALTP2M_DEACTIVATE);
             d->arch.altp2m_eptp[array_index_nospec(idx, MAX_EPTP)] =
-            mfn_x(INVALID_MFN);
+                mfn_x(INVALID_MFN);
+            d->arch.altp2m_visible_eptp[array_index_nospec(idx, MAX_EPTP)] =
+                mfn_x(INVALID_MFN);
             rc = 0;
         }
     }
@@ -2679,7 +2682,7 @@ int p2m_switch_domain_altp2m_by_id(struct domain *d, unsigned int idx)
     rc = -EINVAL;
     altp2m_list_lock(d);
 
-    if ( d->arch.altp2m_eptp[idx] != mfn_x(INVALID_MFN) )
+    if ( d->arch.altp2m_visible_eptp[idx] != mfn_x(INVALID_MFN) )
     {
         for_each_vcpu( d, v )
             if ( idx != vcpu_altp2m(v).p2midx )
@@ -3163,6 +3166,33 @@ int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, bool *suppress_ve,
 
     return rc;
 }
+
+int p2m_set_altp2m_view_visibility(struct domain *d, unsigned int altp2m_idx,
+                                   uint8_t visible)
+{
+    int rc = 0;
+
+    altp2m_list_lock(d);
+
+    /*
+     * Eptp index is correlated with altp2m index and should not exceed
+     * min(MAX_ALTP2M, MAX_EPTP).
+     */
+    if ( altp2m_idx >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) ||
+         d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] ==
+         mfn_x(INVALID_MFN) )
+        rc = -EINVAL;
+    else if ( visible )
+        d->arch.altp2m_visible_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] =
+            d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)];
+    else
+        d->arch.altp2m_visible_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] =
+            mfn_x(INVALID_MFN);
+
+    altp2m_list_unlock(d);
+
+    return rc;
+}
 #endif
 
 /*
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 105adf96eb..4192c636b1 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -327,6 +327,7 @@ struct arch_domain
     struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
     mm_lock_t altp2m_list_lock;
     uint64_t *altp2m_eptp;
+    uint64_t *altp2m_visible_eptp;
 #endif
 
     /* NB. protected by d->event_lock and by irq_desc[irq].lock */
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index a2c6049834..ace3573ae8 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -898,6 +898,10 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int idx,
 int p2m_altp2m_propagate_change(struct domain *d, gfn_t gfn,
                                 mfn_t mfn, unsigned int page_order,
                                 p2m_type_t p2mt, p2m_access_t p2ma);
+
+/* Set a specific p2m view visibility */
+int p2m_set_altp2m_view_visibility(struct domain *d, unsigned int idx,
+                                   uint8_t visible);
 #else
 struct p2m_domain *p2m_get_altp2m(struct vcpu *v);
 static inline void p2m_altp2m_check(struct vcpu *v, uint16_t idx) {}
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index b599d3cbd0..870ec52060 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -318,6 +318,12 @@ struct xen_hvm_altp2m_get_vcpu_p2m_idx {
     uint16_t altp2m_idx;
 };
 
+struct xen_hvm_altp2m_set_visibility {
+    uint16_t altp2m_idx;
+    uint8_t visible;
+    uint8_t pad;
+};
+
 struct xen_hvm_altp2m_op {
     uint32_t version;   /* HVMOP_ALTP2M_INTERFACE_VERSION */
     uint32_t cmd;
@@ -350,6 +356,8 @@ struct xen_hvm_altp2m_op {
 #define HVMOP_altp2m_get_p2m_idx          14
 /* Set the "Supress #VE" bit for a range of pages */
 #define HVMOP_altp2m_set_suppress_ve_multi 15
+/* Set visibility for a given altp2m view */
+#define HVMOP_altp2m_set_visibility       16
     domid_t domain;
     uint16_t pad1;
     uint32_t pad2;
@@ -367,6 +375,7 @@ struct xen_hvm_altp2m_op {
         struct xen_hvm_altp2m_suppress_ve_multi    suppress_ve_multi;
         struct xen_hvm_altp2m_vcpu_disable_notify  disable_notify;
         struct xen_hvm_altp2m_get_vcpu_p2m_idx     get_vcpu_p2m_idx;
+        struct xen_hvm_altp2m_set_visibility       set_visibility;
         uint8_t pad[64];
     } u;
 };
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 13 07:00:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 07:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNt4w-0000Ne-Sp; Mon, 13 Apr 2020 07:00:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=n3x4=55=bitdefender.com=aisaila@srs-us1.protection.inumbo.net>)
 id 1jNt4u-0000NY-TN
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 07:00:20 +0000
X-Inumbo-ID: 6f26e9ea-7d54-11ea-83d8-bc764e2007e4
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown
 [40.107.7.110]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6f26e9ea-7d54-11ea-83d8-bc764e2007e4;
 Mon, 13 Apr 2020 07:00:19 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=WmHsnktGpm/4RtRCqmwPItiFu0h9lQ7xjpp+mhVQlIwS7b/I2oMoN51q1ghyT2HzxyM/3V5UGZrHG5tOU1PF0tGs7j9qo8EQFKopBIRAGcYNT1cC3zWjdQhOsN0BoGTCe21/5vc8+HXIUfxVRNwMBG+JJXp/zrybfD4amy5mGEon52v4IUo37ixJ+IwzIyWAFyvJxUEdAVH187QOdzuG0D2Oab0a+EFJZyCJH2Jq8NFiXi2N4z0BsqApV5IihoXSnTaWKmP3YQGMB9ffD82F4olZjhe/QCslOfSkbHQCVOXBB9vM/Mpr4KFzwaav5/vOWt4t8sZVAmVNS0sazxj0mQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SafQphNT1Pm3M9lWzNSligRP0oeu4NwqvRmlAwwQqZE=;
 b=Fpgv5Oa/6pGNxDsRoydOxtQnkeo4gBx5IlTjTR0YiADdRDbUTA54EgdGNo7kBpicO2lxjD0pLaRJKxQSENPXcjYAuFpWuoyPaPeDXv+hI5VM7HHxnGg3YhbgWfzAaGE8Vg5DQ8I85myAxEQ2eFvinpNJfbcNjUFTqO4rfcH30NyFlhuI63x0dHbT5eQJ+ZhMtJqaTcQfLy1DicUSv9YCVb4k6tMzewnrSl26kuQcTW1YS5+168Ev86hRXJjUBaR6aHT/3oD6Fx007PtKiJ1r/PRi0Jel1Ft9XIj8whQEVuiV+a3rzwVDIvMy7VZH7fY+VWkTY/1L9hpyqb1JbB/nlw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=bitdefender.com; dmarc=pass action=none
 header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SafQphNT1Pm3M9lWzNSligRP0oeu4NwqvRmlAwwQqZE=;
 b=Kn6uuU0R4hXtTloVsxJls4gJ6R4k67QQxRgckQa1JowUm93Tq98rKl7dA7+iFa3nGKMbFN7dLLRpEMTMSvfic3V6qGme5YHXbEXcXUafLkr7D4Tp6RDs52phatpZ/srxsFeO3w95W/DX9UguxfS5lKVbNZ12mvou/KW3uhrsvic=
Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=aisaila@bitdefender.com; 
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com (2603:10a6:20b:86::23)
 by AM6PR02MB5285.eurprd02.prod.outlook.com (2603:10a6:20b:6f::31)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Mon, 13 Apr
 2020 07:00:16 +0000
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208]) by AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208%4]) with mapi id 15.20.2900.028; Mon, 13 Apr 2020
 07:00:16 +0000
Subject: Ping: [PATCH V8] x86/altp2m: Hypercall to set altp2m view visibility
To: xen-devel@lists.xenproject.org, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>
References: <20200413065113.27744-1-aisaila@bitdefender.com>
From: Isaila Alexandru <aisaila@bitdefender.com>
Organization: BD
Message-ID: <3da2ec70-bb04-08a8-6c23-824155f464d3@bitdefender.com>
Date: Mon, 13 Apr 2020 10:00:14 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
In-Reply-To: <20200413065113.27744-1-aisaila@bitdefender.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: VI1PR0901CA0096.eurprd09.prod.outlook.com
 (2603:10a6:800:7e::22) To AM6PR02MB5223.eurprd02.prod.outlook.com
 (2603:10a6:20b:86::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.0.107] (82.77.232.39) by
 VI1PR0901CA0096.eurprd09.prod.outlook.com (2603:10a6:800:7e::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend
 Transport; Mon, 13 Apr 2020 07:00:15 +0000
X-Originating-IP: [82.77.232.39]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ab6acadd-d046-42af-39da-08d7df7851de
X-MS-TrafficTypeDiagnostic: AM6PR02MB5285:|AM6PR02MB5285:
X-Microsoft-Antispam-PRVS: <AM6PR02MB5285F6C67641BA0ED7EF6A31ABDD0@AM6PR02MB5285.eurprd02.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:538;
X-Forefront-PRVS: 037291602B
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:AM6PR02MB5223.eurprd02.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10019020)(39840400004)(366004)(136003)(376002)(396003)(346002)(26005)(66946007)(66476007)(66556008)(316002)(2906002)(36756003)(54906003)(31696002)(16576012)(478600001)(110136005)(86362001)(36916002)(53546011)(52116002)(30864003)(186003)(16526019)(6486002)(2616005)(956004)(5660300002)(81156014)(31686004)(8676002)(8936002)(4326008)(7416002);
 DIR:OUT; SFP:1102; 
Received-SPF: None (protection.outlook.com: bitdefender.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: +15Sx42RVVrQXhoMGQccMYKD5fHO7eDQ6FCQsqiOWAQlF3ltX/hfEmtb2Iu0c1Mdd9oMApQZBMfhPdoat+ff7Q+/GgGSIIqFWjL2+Fk20MZ1OkwCF4sOPkr7ZQ2E04m7bFkAAwCnP3759k/VawrxbYR3RqS5ori1puR/I7W4dO7Mg68nuZKQYbUMhFDKerrYYfaXwCfGTYdwCLB4iqlJqo33gyYousk9nDMf7JIaOHbS6IBKKBQgs6FJ7APuw/dWBo8Y2bDBx4M0F+V0fZHeCsBRRhg0dTVirtEtkTxSQd/PG4wisrNWYmJJ1Z/3vMuV9JiK5isc0aRqhkWlJHbVT/p35pMN8aYy+zZIDsHi1gdtYRhi4lOIDT4C4fbCeNEV6JeBBVpK5hqYyqsqKll9JOjie8Z90IUcPn5MHUUMUG2xeNIIpkgf7XPvARQqx9P+
X-MS-Exchange-AntiSpam-MessageData: W5hzGOoRjX7gIa8edJPu6eXkHBR8x8S/ngBjSCva2nUTaSuOnr0qCuMBc+CT3Y+0ZjKNAIsxc9lb9WpODcbGxaNVxQTV3s73jLaERxNad4s3vocb5Ab78dFzfwu6oUmxCvjAlCxZ1QvXH/KHBjuiuA==
X-MS-Exchange-Transport-Forked: True
X-OriginatorOrg: bitdefender.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab6acadd-d046-42af-39da-08d7df7851de
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2020 07:00:16.4229 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: agB1O05PRUu2udmz9ggw2FQwHMB7EtVvTPfANGnuM6gKL3uOcmZ60QhvLhdJWFvCdyrzeNKTRUCfM4oiZ1FVylQzf8bpNHa281CNcVtwZf8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR02MB5285
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Jun Nakajima <jun.nakajima@intel.com>,
 George Dunlap <George.Dunlap@eu.citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

I need a review for the tools bits in this patch.

Thanks,
Alex

On 13.04.2020 09:51, Alexandru Isaila wrote:
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
> 
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
> This is done by having a separate arch.altp2m_working_eptp that is
> populated and made invalid in the same places as altp2m_eptp. This is
> written to EPTP_LIST_ADDR.
> The views are made in/visible by marking them with INVALID_MFN or
> copying them back from altp2m_eptp.
> To have consistency the visibility also applies to
> p2m_switch_domain_altp2m_by_id().
> 
> The usage of this hypercall is aimed at dom0 having a logic with a number of views
> created and at some time there is a need to be sure that only some of the views
> can be switched, saving the rest and making them visible when the time
> is right.
> 
> Note: If altp2m mode is set to mixed the guest is able to change the view
> visibility and then call vmfunc.
> 
> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> ---
> CC: Ian Jackson <ian.jackson@eu.citrix.com>
> CC: Wei Liu <wl@xen.org>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: George Dunlap <George.Dunlap@eu.citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: "Roger Pau Monné" <roger.pau@citrix.com>
> CC: Jun Nakajima <jun.nakajima@intel.com>
> CC: Kevin Tian <kevin.tian@intel.com>
> ---
> Changes since V7:
> 	- Change altp2m_working_eptp to altp2m_visible_eptp
> 	- Rebase.
> 
> Changes since V6:
> 	- Update commit message.
> 
> Changes since V5:
> 	- Change idx type from uint16_t to unsigned int
> 	- Add rc var and dropped the err return from p2m_get_suppress_ve().
> 
> Changes since V4:
> 	- Move p2m specific things from hvm to p2m.c
> 	- Add comment for altp2m_idx bounds check
> 	- Add altp2m_list_lock/unlock().
> 
> Changes since V3:
> 	- Change var name form altp2m_idx to idx to shorten line length
> 	- Add bounds check for idx
> 	- Update commit message
> 	- Add comment in xenctrl.h.
> 
> Changes since V2:
> 	- Drop hap_enabled() check
> 	- Reduce the indentation depth in hvm.c
> 	- Fix assignment indentation
> 	- Drop pad2.
> 
> Changes since V1:
> 	- Drop double view from title.
> ---
>   tools/libxc/include/xenctrl.h   |  7 +++++++
>   tools/libxc/xc_altp2m.c         | 24 +++++++++++++++++++++++
>   xen/arch/x86/hvm/hvm.c          | 14 ++++++++++++++
>   xen/arch/x86/hvm/vmx/vmx.c      |  2 +-
>   xen/arch/x86/mm/hap/hap.c       | 15 +++++++++++++++
>   xen/arch/x86/mm/p2m-ept.c       |  1 +
>   xen/arch/x86/mm/p2m.c           | 34 +++++++++++++++++++++++++++++++--
>   xen/include/asm-x86/domain.h    |  1 +
>   xen/include/asm-x86/p2m.h       |  4 ++++
>   xen/include/public/hvm/hvm_op.h |  9 +++++++++
>   10 files changed, 108 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 58fa931de1..5f25c5a6d4 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1943,6 +1943,13 @@ int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
>                            xen_pfn_t new_gfn);
>   int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
>                                  uint32_t vcpuid, uint16_t *p2midx);
> +/*
> + * Set view visibility for xc_altp2m_switch_to_view and vmfunc.
> + * Note: If altp2m mode is set to mixed the guest is able to change the view
> + * visibility and then call vmfunc.
> + */
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> +                             uint16_t view_id, bool visible);
>   
>   /**
>    * Mem paging operations.
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 46fb725806..6987c9541f 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -410,3 +410,27 @@ int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
>       xc_hypercall_buffer_free(handle, arg);
>       return rc;
>   }
> +
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> +                             uint16_t view_id, bool visible)
> +{
> +    int rc;
> +
> +    DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +    arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +    if ( arg == NULL )
> +        return -1;
> +
> +    arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +    arg->cmd = HVMOP_altp2m_set_visibility;
> +    arg->domain = domid;
> +    arg->u.set_visibility.altp2m_idx = view_id;
> +    arg->u.set_visibility.visible = visible;
> +
> +    rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> +                  HYPERCALL_BUFFER_AS_ARG(arg));
> +
> +    xc_hypercall_buffer_free(handle, arg);
> +    return rc;
> +}
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 827c5fa89d..6f6f3f73a8 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4509,6 +4509,7 @@ static int do_altp2m_op(
>       case HVMOP_altp2m_get_mem_access:
>       case HVMOP_altp2m_change_gfn:
>       case HVMOP_altp2m_get_p2m_idx:
> +    case HVMOP_altp2m_set_visibility:
>           break;
>   
>       default:
> @@ -4786,6 +4787,19 @@ static int do_altp2m_op(
>           break;
>       }
>   
> +    case HVMOP_altp2m_set_visibility:
> +    {
> +        unsigned int idx = a.u.set_visibility.altp2m_idx;
> +
> +        if ( a.u.set_visibility.pad )
> +            rc = -EINVAL;
> +        else if ( !altp2m_active(d) )
> +            rc = -EOPNOTSUPP;
> +        else
> +            rc = p2m_set_altp2m_view_visibility(d, idx,
> +                                                a.u.set_visibility.visible);
> +    }
> +
>       default:
>           ASSERT_UNREACHABLE();
>       }
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 1c398fdb6e..869339062b 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2140,7 +2140,7 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
>       {
>           v->arch.hvm.vmx.secondary_exec_control |= mask;
>           __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
> -        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
> +        __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_visible_eptp));
>   
>           if ( cpu_has_vmx_virt_exceptions )
>           {
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index 814d0c3253..052ae35c6f 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -492,8 +492,17 @@ int hap_enable(struct domain *d, u32 mode)
>               goto out;
>           }
>   
> +        if ( (d->arch.altp2m_visible_eptp = alloc_xenheap_page()) == NULL )
> +        {
> +            rv = -ENOMEM;
> +            goto out;
> +        }
> +
>           for ( i = 0; i < MAX_EPTP; i++ )
> +        {
>               d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +            d->arch.altp2m_visible_eptp[i] = mfn_x(INVALID_MFN);
> +        }
>   
>           for ( i = 0; i < MAX_ALTP2M; i++ )
>           {
> @@ -527,6 +536,12 @@ void hap_final_teardown(struct domain *d)
>               d->arch.altp2m_eptp = NULL;
>           }
>   
> +        if ( d->arch.altp2m_visible_eptp )
> +        {
> +            free_xenheap_page(d->arch.altp2m_visible_eptp);
> +            d->arch.altp2m_visible_eptp = NULL;
> +        }
> +
>           for ( i = 0; i < MAX_ALTP2M; i++ )
>               p2m_teardown(d->arch.altp2m_p2m[i]);
>       }
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index eb0f0edfef..293f3e9419 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1368,6 +1368,7 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>       ept = &p2m->ept;
>       ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
>       d->arch.altp2m_eptp[array_index_nospec(i, MAX_EPTP)] = ept->eptp;
> +    d->arch.altp2m_visible_eptp[array_index_nospec(i, MAX_EPTP)] = ept->eptp;
>   }
>   
>   unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp)
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index b8727e267d..4c1507d3a4 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2533,6 +2533,7 @@ void p2m_flush_altp2m(struct domain *d)
>       {
>           p2m_reset_altp2m(d, i, ALTP2M_DEACTIVATE);
>           d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +        d->arch.altp2m_visible_eptp[i] = mfn_x(INVALID_MFN);
>       }
>   
>       altp2m_list_unlock(d);
> @@ -2652,7 +2653,9 @@ int p2m_destroy_altp2m_by_id(struct domain *d, unsigned int idx)
>           {
>               p2m_reset_altp2m(d, idx, ALTP2M_DEACTIVATE);
>               d->arch.altp2m_eptp[array_index_nospec(idx, MAX_EPTP)] =
> -            mfn_x(INVALID_MFN);
> +                mfn_x(INVALID_MFN);
> +            d->arch.altp2m_visible_eptp[array_index_nospec(idx, MAX_EPTP)] =
> +                mfn_x(INVALID_MFN);
>               rc = 0;
>           }
>       }
> @@ -2679,7 +2682,7 @@ int p2m_switch_domain_altp2m_by_id(struct domain *d, unsigned int idx)
>       rc = -EINVAL;
>       altp2m_list_lock(d);
>   
> -    if ( d->arch.altp2m_eptp[idx] != mfn_x(INVALID_MFN) )
> +    if ( d->arch.altp2m_visible_eptp[idx] != mfn_x(INVALID_MFN) )
>       {
>           for_each_vcpu( d, v )
>               if ( idx != vcpu_altp2m(v).p2midx )
> @@ -3163,6 +3166,33 @@ int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, bool *suppress_ve,
>   
>       return rc;
>   }
> +
> +int p2m_set_altp2m_view_visibility(struct domain *d, unsigned int altp2m_idx,
> +                                   uint8_t visible)
> +{
> +    int rc = 0;
> +
> +    altp2m_list_lock(d);
> +
> +    /*
> +     * Eptp index is correlated with altp2m index and should not exceed
> +     * min(MAX_ALTP2M, MAX_EPTP).
> +     */
> +    if ( altp2m_idx >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) ||
> +         d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] ==
> +         mfn_x(INVALID_MFN) )
> +        rc = -EINVAL;
> +    else if ( visible )
> +        d->arch.altp2m_visible_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] =
> +            d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)];
> +    else
> +        d->arch.altp2m_visible_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] =
> +            mfn_x(INVALID_MFN);
> +
> +    altp2m_list_unlock(d);
> +
> +    return rc;
> +}
>   #endif
>   
>   /*
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 105adf96eb..4192c636b1 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -327,6 +327,7 @@ struct arch_domain
>       struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
>       mm_lock_t altp2m_list_lock;
>       uint64_t *altp2m_eptp;
> +    uint64_t *altp2m_visible_eptp;
>   #endif
>   
>       /* NB. protected by d->event_lock and by irq_desc[irq].lock */
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index a2c6049834..ace3573ae8 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -898,6 +898,10 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int idx,
>   int p2m_altp2m_propagate_change(struct domain *d, gfn_t gfn,
>                                   mfn_t mfn, unsigned int page_order,
>                                   p2m_type_t p2mt, p2m_access_t p2ma);
> +
> +/* Set a specific p2m view visibility */
> +int p2m_set_altp2m_view_visibility(struct domain *d, unsigned int idx,
> +                                   uint8_t visible);
>   #else
>   struct p2m_domain *p2m_get_altp2m(struct vcpu *v);
>   static inline void p2m_altp2m_check(struct vcpu *v, uint16_t idx) {}
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index b599d3cbd0..870ec52060 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -318,6 +318,12 @@ struct xen_hvm_altp2m_get_vcpu_p2m_idx {
>       uint16_t altp2m_idx;
>   };
>   
> +struct xen_hvm_altp2m_set_visibility {
> +    uint16_t altp2m_idx;
> +    uint8_t visible;
> +    uint8_t pad;
> +};
> +
>   struct xen_hvm_altp2m_op {
>       uint32_t version;   /* HVMOP_ALTP2M_INTERFACE_VERSION */
>       uint32_t cmd;
> @@ -350,6 +356,8 @@ struct xen_hvm_altp2m_op {
>   #define HVMOP_altp2m_get_p2m_idx          14
>   /* Set the "Supress #VE" bit for a range of pages */
>   #define HVMOP_altp2m_set_suppress_ve_multi 15
> +/* Set visibility for a given altp2m view */
> +#define HVMOP_altp2m_set_visibility       16
>       domid_t domain;
>       uint16_t pad1;
>       uint32_t pad2;
> @@ -367,6 +375,7 @@ struct xen_hvm_altp2m_op {
>           struct xen_hvm_altp2m_suppress_ve_multi    suppress_ve_multi;
>           struct xen_hvm_altp2m_vcpu_disable_notify  disable_notify;
>           struct xen_hvm_altp2m_get_vcpu_p2m_idx     get_vcpu_p2m_idx;
> +        struct xen_hvm_altp2m_set_visibility       set_visibility;
>           uint8_t pad[64];
>       } u;
>   };
> 


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 08:01:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 08:01:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNu1s-0005l0-He; Mon, 13 Apr 2020 08:01:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=F6Pd=55=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNu1r-0005kv-K3
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 08:01:15 +0000
X-Inumbo-ID: eee07c8e-7d5c-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id eee07c8e-7d5c-11ea-9e09-bc764e2007e4;
 Mon, 13 Apr 2020 08:01:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=DB62TPGCx4k1tq+V0kP7A2jOwdAyXfL6oNXLUrZCKeo=; b=UIJ30OZmBA8ngWFrvDjAVRIF+
 pFwF9m2iOZNqqHmPxYwVHs98ovkWFgrRRVl2Qq5bowf1WBcRBJvGnIGyuc0fVLKQV7uz3T4TC+AmW
 OFZd8WykrOiCuztFYU6H+w/jW3F6WhUVjLyP8z0SCUoI+ym2N1jKkq5uCff5SF3hB3bUU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNu1k-0003Xn-DC; Mon, 13 Apr 2020 08:01:08 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNu1k-0007xg-4u; Mon, 13 Apr 2020 08:01:08 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNu1k-0000Wx-4H; Mon, 13 Apr 2020 08:01:08 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149632-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149632: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-armhf-armhf-xl-rtds:guest-start.2:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=8f3d9f354286745c751374f5f1fcafee6b3f3136
X-Osstest-Versions-That: linux=4f8a3cc1183c442daee6cc65360e3385021131e4
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 13 Apr 2020 08:01:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                8f3d9f354286745c751374f5f1fcafee6b3f3136
baseline version:
 linux                4f8a3cc1183c442daee6cc65360e3385021131e4

Last test of basis   149631  2020-04-12 17:39:35 Z    0 days
Testing same since   149632  2020-04-13 01:08:56 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Linus Torvalds <torvalds@linux-foundation.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   4f8a3cc1183c..8f3d9f354286  8f3d9f354286745c751374f5f1fcafee6b3f3136 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 09:42:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 09:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNvbM-0005IJ-4K; Mon, 13 Apr 2020 09:42:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=F6Pd=55=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNvbK-0005IE-Vj
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 09:41:59 +0000
X-Inumbo-ID: 0486ec18-7d6b-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0486ec18-7d6b-11ea-b58d-bc764e2007e4;
 Mon, 13 Apr 2020 09:41:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tmLbJzDwoxs0B3GLsza3hkXUTDwhWjRg0Fe/wl60Gj0=; b=GkKVx7mZlS1JPaOaNxv2QvepX
 pRMZNZ7W1Sf/HLN6exIgwI3XDqkEPvZlfwwV+ifyAfdcoMPtMpKU4c7YsbQsJi/O2U/MXWJGY1Dsy
 FtcnhN8xMSBiYyDq7SjfQuOjZu705LMmGfQsuKYaATUKv0u3SEZfbkywC2ImIOC88iyno=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNvbJ-0005R3-MQ; Mon, 13 Apr 2020 09:41:57 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNvbJ-0005YI-DX; Mon, 13 Apr 2020 09:41:57 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNvbJ-00033C-Cs; Mon, 13 Apr 2020 09:41:57 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149636-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149636: all pass - PUSHED
X-Osstest-Versions-This: ovmf=776ec4ea3cbf027d258904a1d0a5b9821d07f2ef
X-Osstest-Versions-That: ovmf=48b6c60cc6a234d971d7ca97f7cd0ca9a9499de5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 13 Apr 2020 09:41:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 776ec4ea3cbf027d258904a1d0a5b9821d07f2ef
baseline version:
 ovmf                 48b6c60cc6a234d971d7ca97f7cd0ca9a9499de5

Last test of basis   149633  2020-04-13 01:39:17 Z    0 days
Testing same since   149636  2020-04-13 06:12:47 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Dong, Eric <eric.dong@intel.com>
  Eric Dong <eric.dong@intel.com>
  Guomin Jiang <guomin.jiang@intel.com>
  Ray Ni <niruiyu@users.noreply.github.com>
  Ray Ni <ray.ni@intel.com>
  Shenglei Zhang <shenglei.zhang@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   48b6c60cc6..776ec4ea3c  776ec4ea3cbf027d258904a1d0a5b9821d07f2ef -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 12:36:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 12:36:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNyJo-00021D-SQ; Mon, 13 Apr 2020 12:36:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=pMlu=55=qubes-os.org=frederic.pierret@srs-us1.protection.inumbo.net>)
 id 1jNyJn-000218-Hl
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 12:36:03 +0000
X-Inumbo-ID: 54e1771a-7d83-11ea-882f-12813bfff9fa
Received: from sender4-of-o53.zoho.com (unknown [136.143.188.53])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 54e1771a-7d83-11ea-882f-12813bfff9fa;
 Mon, 13 Apr 2020 12:36:01 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1586781352; cv=none; 
 d=zohomail.com; s=zohoarc; 
 b=URT4ApyJH9amVLiaLSYaw57F9uCpTWyKxsPl34oflcpUmtg2p4WEWREBPNpMbTbnK1x3emOOWzNfG4I6m556+BGi/dxKmMA4uPJtmeBnmzxqlhHbK2jI1dO//XNcSsJzn81VxfqbYA5G60VD/DLVsCkF5Eij6K/9d7WBF/Wq4bE=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;
 s=zohoarc; t=1586781352;
 h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:MIME-Version:Message-ID:Subject:To;
 bh=B++eaGNam0FxBVZre8TLB+VO2JQ+stYGRCXlTtSwji0=; 
 b=PI0hG2vGh1Jacd3QytBJxwOaEe72zlJRPnLxGu+3h/5jWT8h4tTHkbcyA7M1vZhw1FPOrghFM95VspEGEMuXDfankhybKPGPevnpKs0Xtr7kRLhR7hJasqerOEFAr9CN1/h1W147K8ImoZti5ZMFflyURZdtqVThdCSJaMhRBPE=
ARC-Authentication-Results: i=1; mx.zohomail.com;
 dkim=pass  header.i=qubes-os.org;
 spf=pass  smtp.mailfrom=frederic.pierret@qubes-os.org;
 dmarc=pass header.from=<frederic.pierret@qubes-os.org>
 header.from=<frederic.pierret@qubes-os.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1586781352; 
 s=s; d=qubes-os.org; i=frederic.pierret@qubes-os.org;
 h=From:To:Cc:Message-ID:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding;
 bh=B++eaGNam0FxBVZre8TLB+VO2JQ+stYGRCXlTtSwji0=;
 b=Vw6Awvh5xzJpfznhRXSvdmRdaTs0ecMplK9U9YbHWel0dJPtTWXZg6bMj3pnJMZU
 2pwabRVZYXIdimTTxYgmkGbT9lfiW+n34pHw5jAze9UJ28ySBvUhSq9lMfn56QGL66O
 1YavpT7oYIr47FHLWkWOooX1csDP2RVHnLw2l08Y=
Received: from localhost.localdomain (92.188.110.153 [92.188.110.153]) by
 mx.zohomail.com with SMTPS id 1586781351454814.489105458741;
 Mon, 13 Apr 2020 05:35:51 -0700 (PDT)
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Pierret=20=28fepitre=29?=
 <frederic.pierret@qubes-os.org>
To: boris.ostrovsky@oracle.com, jgross@suse.com, sstabellini@kernel.org,
 tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org,
 hpa@zytor.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Message-ID: <20200413123535.10884-1-frederic.pierret@qubes-os.org>
Subject: [PATCH] xen x86: fix early boot crash with gcc-10
Date: Mon, 13 Apr 2020 14:35:35 +0200
X-Mailer: git-send-email 2.25.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-ZohoMailClient: External
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Pierret=20=28fepitre=29?=
 <frederic.pierret@qubes-os.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The change fixes boot failure on VM where kernel (at least v5.4 and v5.6)
is built with gcc-10 and STACKPROTECTOR_STRONG enabled:

```
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: =
cpu_bringup_and_idle+0x93/0xa0
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.4.31-1.qubes.x86_64 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/201=
4
Call Trace:
  dump_stack+0x64/0x88
   panic+0x10b/0x2ed
   ? cpu_bringup_and_idle+0x93/0xa0
   __stack_chk_fail+0x15/0x20
   cpu_bringup_and_idle+0x93/0xa
```
The change makes successfully booting the VM. The VM is hosted by
KVM hypervisor and is running Xen into.

Based on work done by Sergei Trofimovich: https://lkml.org/lkml/2020/3/26/1=
133

Signed-off-by: Fr=C3=A9d=C3=A9ric Pierret (fepitre) <frederic.pierret@qubes=
-os.org>
---
 arch/x86/xen/smp_pv.c          | 2 +-
 include/linux/compiler-gcc.h   | 1 +
 include/linux/compiler_types.h | 4 ++++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 8fb8a50a28b4..5c8ee4a5bb0c 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -88,7 +88,7 @@ static void cpu_bringup(void)
 =09local_irq_enable();
 }
=20
-asmlinkage __visible void cpu_bringup_and_idle(void)
+asmlinkage __visible void __no_stack_protector cpu_bringup_and_idle(void)
 {
 =09cpu_bringup();
 =09boot_init_stack_canary();
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index d7ee4c6bad48..fb67c743138c 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -172,3 +172,4 @@
 #endif
=20
 #define __no_fgcse __attribute__((optimize("-fno-gcse")))
+#define __no_stack_protector __attribute__((optimize("-fno-stack-protector=
")))
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.=
h
index e970f97a7fcb..069c981eddb0 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -203,6 +203,10 @@ struct ftrace_likely_data {
 #define asm_inline asm
 #endif
=20
+#ifndef __no_stack_protector
+# define __no_stack_protector
+#endif
+
 #ifndef __no_fgcse
 # define __no_fgcse
 #endif
--=20
2.25.1




From xen-devel-bounces@lists.xenproject.org Mon Apr 13 13:18:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 13:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNyym-0005Ix-FC; Mon, 13 Apr 2020 13:18:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=F6Pd=55=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jNyyk-0005Is-Ua
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 13:18:22 +0000
X-Inumbo-ID: 3bb61510-7d89-11ea-883a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3bb61510-7d89-11ea-883a-12813bfff9fa;
 Mon, 13 Apr 2020 13:18:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=828gnsGfx/VzCtAZK+gA2zBwPjpcL+yrciCQ7S1UdLg=; b=brOVrflB5G4uKAB++PxzMIK2L
 afaIY/dOVfjgAkWLOZ92Y2ED0vsmI1rdnk2apd2O21aCR+kxA9sW3f9mmz7AgDRagu8zYi3mmyVXO
 lbApXx8MYSAw1aCFoBndQZz4O4+d9rFZ/ZjizAinMcZyZONzJJt1wmw5uGe+I/EGmkp1Q=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNyyd-0001Fn-6s; Mon, 13 Apr 2020 13:18:15 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jNyyc-0000EY-UQ; Mon, 13 Apr 2020 13:18:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jNyyc-0004VB-SW; Mon, 13 Apr 2020 13:18:14 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149634-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149634: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:depriv-audit-qemu/create:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
X-Osstest-Versions-That: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 13 Apr 2020 13:18:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 15 depriv-audit-qemu/create fail in 149627 pass in 149634
 test-amd64-amd64-xl-rtds     16 guest-localmigrate         fail pass in 149627

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds  18 guest-localmigrate/x10 fail in 149627 like 149619
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149627
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149627
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149627
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149627
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149627
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149627
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149627
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149627
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149627
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3
baseline version:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3

Last test of basis   149634  2020-04-13 01:52:00 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Mon Apr 13 14:21:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 14:21:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jNzxO-0002P1-Ex; Mon, 13 Apr 2020 14:21:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=geSq=55=alien8.de=bp@srs-us1.protection.inumbo.net>)
 id 1jNzxM-0002Ow-Gk
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 14:21:00 +0000
X-Inumbo-ID: fe7511c0-7d91-11ea-9e09-bc764e2007e4
Received: from mail.skyhub.de (unknown [5.9.137.197])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fe7511c0-7d91-11ea-9e09-bc764e2007e4;
 Mon, 13 Apr 2020 14:20:58 +0000 (UTC)
Received: from zn.tnic (p200300EC2F06C900CDC4EA77E1BD02DC.dip0.t-ipconnect.de
 [IPv6:2003:ec:2f06:c900:cdc4:ea77:e1bd:2dc])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 2BCCC1EC05D6;
 Mon, 13 Apr 2020 16:20:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim;
 t=1586787657;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=EvqjNnYQ7o0idjKHDUx8jEi5/BB6c/YUkQH5OCgKrQg=;
 b=UA4vS/uvqDIJ6vpmf30WbVO8rgXk8eXQu4ujQ2VCo1rCrpDDYBVSLLoi3ez1bRyVdLPfL7
 u57Ej8KqhFZa3VC0EB2VAXawNjozEJL1QQ6eNfjRk9inXTO6vd+45v71N3nX0AtFybp5lR
 6WHStVd7PcMDbDV0AfyR/x6sMOIehpk=
Date: Mon, 13 Apr 2020 16:20:51 +0200
From: Borislav Petkov <bp@alien8.de>
To: =?utf-8?Q?Fr=C3=A9d=C3=A9ric_Pierret_=28fepitre=29?=
 <frederic.pierret@qubes-os.org>
Subject: Re: [PATCH] xen x86: fix early boot crash with gcc-10
Message-ID: <20200413142051.GC3772@zn.tnic>
References: <20200413123535.10884-1-frederic.pierret@qubes-os.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200413123535.10884-1-frederic.pierret@qubes-os.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, sstabellini@kernel.org, x86@kernel.org,
 linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
 xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, tglx@linutronix.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 13, 2020 at 02:35:35PM +0200, Frédéric Pierret (fepitre) wrote:
> The change fixes boot failure on VM where kernel (at least v5.4 and v5.6)
> is built with gcc-10 and STACKPROTECTOR_STRONG enabled:
> 
> ```
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: cpu_bringup_and_idle+0x93/0xa0
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.4.31-1.qubes.x86_64 #1
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014
> Call Trace:
>   dump_stack+0x64/0x88
>    panic+0x10b/0x2ed
>    ? cpu_bringup_and_idle+0x93/0xa0
>    __stack_chk_fail+0x15/0x20
>    cpu_bringup_and_idle+0x93/0xa
> ```
> The change makes successfully booting the VM. The VM is hosted by
> KVM hypervisor and is running Xen into.
> 
> Based on work done by Sergei Trofimovich: https://lkml.org/lkml/2020/3/26/1133

I was waiting for the merge window to finish to queue his patch. That is
done now, you can rebase yours ontop.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 14:40:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 14:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jO0GX-00043t-VM; Mon, 13 Apr 2020 14:40:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=bkRy=55=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jO0GW-00043m-0D
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 14:40:48 +0000
X-Inumbo-ID: c33489f8-7d94-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c33489f8-7d94-11ea-b58d-bc764e2007e4;
 Mon, 13 Apr 2020 14:40:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=iG1fEbVBVOASbBGIGoNkV4/Ci4Hax3sGlwZy/6m68GA=; b=aimsvq7amG3V1KoBufqyW/7PXa
 CJWCR9uf/ZvjaWFu2pJLEutevKUAOdt+g0OnYI0Q9ShFiFKZBy1IIwL/jMvGbJ8nbMtPQaOsODq0G
 tQQVYZVxI18b2qhAKYwvf7ttd2ZAKGIqQaQ/p0+HbJH65RCa3Dv6YbIjRwUfamuZ+Kic=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jO0GR-0002t5-S7; Mon, 13 Apr 2020 14:40:43 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jO0GR-0006P1-IS; Mon, 13 Apr 2020 14:40:43 +0000
Date: Mon, 13 Apr 2020 15:40:40 +0100
From: Wei Liu <wl@xen.org>
To: Alexandru Isaila <aisaila@bitdefender.com>
Subject: Re: [PATCH V8] x86/altp2m: Hypercall to set altp2m view visibility
Message-ID: <20200413144040.xaprxsniujid53zf@debian>
References: <20200413065113.27744-1-aisaila@bitdefender.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200413065113.27744-1-aisaila@bitdefender.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wl@xen.org>,
 George Dunlap <George.Dunlap@eu.citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 13, 2020 at 09:51:13AM +0300, Alexandru Isaila wrote:
[...]
> ---
>  tools/libxc/include/xenctrl.h   |  7 +++++++
>  tools/libxc/xc_altp2m.c         | 24 +++++++++++++++++++++++

Acked-by: Wei Liu <wl@xen.org>

>  xen/arch/x86/hvm/hvm.c          | 14 ++++++++++++++
>  xen/arch/x86/hvm/vmx/vmx.c      |  2 +-
>  xen/arch/x86/mm/hap/hap.c       | 15 +++++++++++++++
>  xen/arch/x86/mm/p2m-ept.c       |  1 +
>  xen/arch/x86/mm/p2m.c           | 34 +++++++++++++++++++++++++++++++--
>  xen/include/asm-x86/domain.h    |  1 +
>  xen/include/asm-x86/p2m.h       |  4 ++++
>  xen/include/public/hvm/hvm_op.h |  9 +++++++++
>  10 files changed, 108 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 58fa931de1..5f25c5a6d4 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1943,6 +1943,13 @@ int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
>                           xen_pfn_t new_gfn);
>  int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
>                                 uint32_t vcpuid, uint16_t *p2midx);
> +/*
> + * Set view visibility for xc_altp2m_switch_to_view and vmfunc.
> + * Note: If altp2m mode is set to mixed the guest is able to change the view
> + * visibility and then call vmfunc.
> + */
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> +                             uint16_t view_id, bool visible);
>  
>  /** 
>   * Mem paging operations.
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 46fb725806..6987c9541f 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -410,3 +410,27 @@ int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
>      xc_hypercall_buffer_free(handle, arg);
>      return rc;
>  }
> +
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> +                             uint16_t view_id, bool visible)
> +{
> +    int rc;
> +
> +    DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +    arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +    if ( arg == NULL )
> +        return -1;
> +
> +    arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +    arg->cmd = HVMOP_altp2m_set_visibility;
> +    arg->domain = domid;
> +    arg->u.set_visibility.altp2m_idx = view_id;
> +    arg->u.set_visibility.visible = visible;
> +
> +    rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> +                  HYPERCALL_BUFFER_AS_ARG(arg));
> +
> +    xc_hypercall_buffer_free(handle, arg);
> +    return rc;
> +}
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 14:46:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 14:46:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jO0M2-0004F3-PF; Mon, 13 Apr 2020 14:46:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=F6Pd=55=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jO0M2-0004Ey-Dn
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 14:46:30 +0000
X-Inumbo-ID: 8b7d5ebc-7d95-11ea-8854-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8b7d5ebc-7d95-11ea-8854-12813bfff9fa;
 Mon, 13 Apr 2020 14:46:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ftuT3bDNXuzAGSnbequSmAUINZ4zVMzeRZGj2f71NFQ=; b=m10Iz2P8TH2UNCLsuNPTSfj3B
 u0FGke/HC31XHR27GAwp8QuXDQe/pVMj42ef9UYj6OAglVTnPkhAEZ24k38jTbHdBZ49TJHPyU4eW
 pDAoZ30QTqtynoe9EeqHPa+P/IxZUjPLKVdQioALHwJPVnHH/oKJH3VcPjv1jiYIMb5Iw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jO0Lv-00030Q-1N; Mon, 13 Apr 2020 14:46:23 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jO0Lu-0004ct-P2; Mon, 13 Apr 2020 14:46:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jO0Lu-0001tk-OR; Mon, 13 Apr 2020 14:46:22 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149638-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149638: all pass - PUSHED
X-Osstest-Versions-This: ovmf=bd6aa93296de36c5afabd34e4fa4083bccb8488d
X-Osstest-Versions-That: ovmf=776ec4ea3cbf027d258904a1d0a5b9821d07f2ef
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 13 Apr 2020 14:46:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 bd6aa93296de36c5afabd34e4fa4083bccb8488d
baseline version:
 ovmf                 776ec4ea3cbf027d258904a1d0a5b9821d07f2ef

Last test of basis   149636  2020-04-13 06:12:47 Z    0 days
Testing same since   149638  2020-04-13 10:09:17 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Zhiguang Liu <zhiguang.liu@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   776ec4ea3c..bd6aa93296  bd6aa93296de36c5afabd34e4fa4083bccb8488d -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 15:03:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 15:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jO0cY-0005sv-A2; Mon, 13 Apr 2020 15:03:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=pMlu=55=qubes-os.org=frederic.pierret@srs-us1.protection.inumbo.net>)
 id 1jO0cX-0005sq-Bt
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 15:03:33 +0000
X-Inumbo-ID: f0209514-7d97-11ea-8858-12813bfff9fa
Received: from sender4-of-o53.zoho.com (unknown [136.143.188.53])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f0209514-7d97-11ea-8858-12813bfff9fa;
 Mon, 13 Apr 2020 15:03:32 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1586790203; cv=none; 
 d=zohomail.com; s=zohoarc; 
 b=NPb69smhNgO1P+KkviAiFToL+vKMqi7jVNTqvd+/2gnCbcv9y24R8zOws8A9OkHdGd4WmPuQPLlMakVNy1rUWrd0/p+jJmfMfV9zlWQA7pnRx2Py8/FadIUhgudpHY/NRqsSnTR/iFNS6Uf2vbnFW7intpBJv8O3naTSNT5Id3A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;
 s=zohoarc; t=1586790203;
 h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To;
 bh=9Pzk0cVzBCKcfGlQdKKLQ1SX00CFPc0gWvmG8POseOM=; 
 b=MFesFXbunyENNW1kui0k53JuRrrpwJH+11cLWpTcneejw5V5mk3Sw5hR0p5Eg6+C9ARxHNJ5lj9DAey+hIWjqUo3eSQm0EI6MEqg7BjJB+o7PGDkCDtBAyiJdi/MuEFXpW93FRg3ePdfgbavNAQq8lfMVjweEj2wCh7rHbZdBGs=
ARC-Authentication-Results: i=1; mx.zohomail.com;
 dkim=pass  header.i=qubes-os.org;
 spf=pass  smtp.mailfrom=frederic.pierret@qubes-os.org;
 dmarc=pass header.from=<frederic.pierret@qubes-os.org>
 header.from=<frederic.pierret@qubes-os.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1586790203; 
 s=s; d=qubes-os.org; i=frederic.pierret@qubes-os.org;
 h=From:To:Cc:Message-ID:Subject:Date:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding;
 bh=9Pzk0cVzBCKcfGlQdKKLQ1SX00CFPc0gWvmG8POseOM=;
 b=lQnrmEWviXsFurbfdGrSiWqbpl0fOrpU4MuSD2vtweWTqg8TBjCgvbLrOuC/dhRQ
 JqjaLXKKqWMIyNocT3CibI/HG3VPrcWN93/mREwU1NLSGgp5QQ29Dfr0z4RjPgdxNaG
 7BoCdkKZdl1RHX6/4wjqRYrnmtykfuv1SUDX10y4=
Received: from localhost.localdomain (92.188.110.153 [92.188.110.153]) by
 mx.zohomail.com with SMTPS id 1586790200760672.0712336468074;
 Mon, 13 Apr 2020 08:03:20 -0700 (PDT)
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Pierret=20=28fepitre=29?=
 <frederic.pierret@qubes-os.org>
To: boris.ostrovsky@oracle.com, jgross@suse.com, sstabellini@kernel.org,
 tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org,
 hpa@zytor.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Message-ID: <20200413150314.13974-1-frederic.pierret@qubes-os.org>
Subject: [PATCH v2] xen x86: fix early boot crash with gcc-10
Date: Mon, 13 Apr 2020 17:03:14 +0200
X-Mailer: git-send-email 2.25.2
In-Reply-To: <20200413142051.GC3772@zn.tnic>
References: <20200413142051.GC3772@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-ZohoMailClient: External
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Pierret=20=28fepitre=29?=
 <frederic.pierret@qubes-os.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The change fixes boot failure on VM where kernel (at least v5.4 and v5.6)
is built with gcc-10 and STACKPROTECTOR_STRONG enabled:

```
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: =
cpu_bringup_and_idle+0x93/0xa0
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.4.31-1.qubes.x86_64 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/201=
4
Call Trace:
  dump_stack+0x64/0x88
   panic+0x10b/0x2ed
   ? cpu_bringup_and_idle+0x93/0xa0
   __stack_chk_fail+0x15/0x20
   cpu_bringup_and_idle+0x93/0xa
```
The change makes successfully booting the VM. The VM is hosted by
KVM hypervisor and is running Xen into.

Based on work done by Sergei Trofimovich: https://lkml.org/lkml/2020/3/26/1=
133

Signed-off-by: Fr=C3=A9d=C3=A9ric Pierret (fepitre) <frederic.pierret@qubes=
-os.org>
---
 arch/x86/xen/smp_pv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 8fb8a50a28b4..5c8ee4a5bb0c 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -88,7 +88,7 @@ static void cpu_bringup(void)
 =09local_irq_enable();
 }
=20
-asmlinkage __visible void cpu_bringup_and_idle(void)
+asmlinkage __visible void __no_stack_protector cpu_bringup_and_idle(void)
 {
 =09cpu_bringup();
 =09boot_init_stack_canary();
--=20
2.25.2




From xen-devel-bounces@lists.xenproject.org Mon Apr 13 15:10:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 15:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jO0j0-0006i9-3e; Mon, 13 Apr 2020 15:10:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=F6Pd=55=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jO0iy-0006i4-Ki
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 15:10:12 +0000
X-Inumbo-ID: db5c9d5a-7d98-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id db5c9d5a-7d98-11ea-83d8-bc764e2007e4;
 Mon, 13 Apr 2020 15:10:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=USZ9YlFjuTCiKojIr/FwBx1oFtWd5A5o7FdIakHccpQ=; b=i9x0XlCNfjd8bCqPhWSFaX11p
 UOexSmw1R3MFlye/oG/rS7+bJnvO5JtjAQCwHsgbs/P81z85iWbcG03/2m020C1FUV0xJzrSlmS39
 Mn0CozYTzhhbV5vmu64yyF4AoYb1MYfhsT2ht4NgN8ZbqcEalYDVQ0+xKT9dC8qDLjOa8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jO0ir-0003T3-EX; Mon, 13 Apr 2020 15:10:05 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jO0ir-0005aL-6k; Mon, 13 Apr 2020 15:10:05 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jO0ir-0002RH-64; Mon, 13 Apr 2020 15:10:05 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149637-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149637: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=bc844d58f697dff3ded4b410094ee89f5cedc04c
X-Osstest-Versions-That: linux=de850633a01fa06515a89a184d6e9769c160d932
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 13 Apr 2020 15:10:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149514

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                bc844d58f697dff3ded4b410094ee89f5cedc04c
baseline version:
 linux                de850633a01fa06515a89a184d6e9769c160d932

Last test of basis   149514  2020-04-08 07:39:59 Z    5 days
Testing same since   149637  2020-04-13 09:10:52 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alex Vesker <valex@mellanox.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Shevchenko <andy.shevchenko@gmail.com>
  Anson Huang <Anson.Huang@nxp.com>
  Arnd Bergmann <arnd@arndb.de>
  Avihai Horon <avihaih@mellanox.com>
  Bart Van Assche <bvanassche@acm.org>
  Bernard Metzler <bmt@zurich.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Chuanhong Guo <gch981213@gmail.com>
  Cong Wang <xiyou.wangcong@gmail.com>
  Daniel Vetter <daniel.vetter@ffwll.ch>
  David Ahern <dsahern@kernel.org>
  David S. Miller <davem@davemloft.net>
  Dennis Dalessandro <dennis.dalessandro@intel.com>
  Felipe Balbi <balbi@kernel.org>
  Florian Fainelli <f.fainelli@gmail.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Hans de Goede <hdegoede@redhat.com>
  Heiner Kallweit <hkallweit1@gmail.com>
  Herat Ramani <herat@chelsio.com>
  Herbert Xu <herbert@gondor.apana.org.au>
  Ido Schimmel <idosch@mellanox.com>
  Ilya Dryomov <idryomov@gmail.com>
  Jarod Wilson <jarod@redhat.com>
  Jason A. Donenfeld <Jason@zx2c4.com>
  Jason Gunthorpe <jgg@mellanox.com>
  Jason Wang <jasowang@redhat.com>
  Jens Axboe <axboe@kernel.dk>
  Jisheng Zhang <Jisheng.Zhang@synaptics.com>
  Joerg Roedel <jroedel@suse.de>
  Kaike Wan <kaike.wan@intel.com>
  Kees Cook <keescook@chromium.org>
  Leon Romanovsky <leonro@mellanox.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lu Baolu <baolu.lu@linux.intel.com>
  Luis Henriques <lhenriques@suse.com>
  Marc Kleine-Budde <mkl@pengutronix.de>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Martin Kaiser <martin@kaiser.cx>
  Oleksij Rempel <o.rempel@pengutronix.de>
  Paul Cercueil <paul@crapouillou.net>
  Petr Machata <petrm@mellanox.com>
  Qiujun Huang <hqjagain@gmail.com>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
  René van Dorst <opensource@vdorst.com>
  Richard Palethorpe <rpalethorpe@suse.com>
  Sam Ravnborg <sam@ravnborg.org>
  Shawn Guo <shawnguo@kernel.org>
  Sultan Alsawaf <sultan@kerneltoast.com>
  Sven Schnelle <svens@linux.ibm.com>
  Theodore Ts'o <tytso@mit.edu>
  Thinh Nguyen <Thinh.Nguyen@synopsys.com>
  Thinh Nguyen <thinhn@synopsys.com>
  Vasily Gorbik <gor@linux.ibm.com>
  Will Deacon <will@kernel.org>
  Xiubo Li <xiubli@redhat.com>
  Yafang Shao <laoar.shao@gmail.com>
  Yury Norov <yury.norov@gmail.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   de850633a01f..bc844d58f697  bc844d58f697dff3ded4b410094ee89f5cedc04c -> tested/linux-5.4


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 17:41:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 17:41:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jO35X-0002Le-Mo; Mon, 13 Apr 2020 17:41:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=geSq=55=alien8.de=bp@srs-us1.protection.inumbo.net>)
 id 1jO35W-0002LZ-UX
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 17:41:38 +0000
X-Inumbo-ID: 0610868d-7dae-11ea-8886-12813bfff9fa
Received: from mail.skyhub.de (unknown [5.9.137.197])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0610868d-7dae-11ea-8886-12813bfff9fa;
 Mon, 13 Apr 2020 17:41:37 +0000 (UTC)
Received: from zn.tnic (p200300EC2F06C90094DE0BDBF95A27C8.dip0.t-ipconnect.de
 [IPv6:2003:ec:2f06:c900:94de:bdb:f95a:27c8])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 111041EC0A02;
 Mon, 13 Apr 2020 19:41:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim;
 t=1586799696;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=Gc71y0cM8+tCsVwGa6HMo9kNdRtGev9oBI43iMJtcF8=;
 b=QlfEDmYJMey1yNVo645/4JcSkWdZcGpFSZ9EqumxKdxRVN3ySYXLtmr4pm7D5WU3Uvb0e+
 9fuaFwAaWbly5fAj5YWAl74qHDx51jn5MrfYhaTQOcWvjwCfRLPGgFB89kbxynd+RN4czu
 0SJLDsmAS77rKFsro5fk3uViVVABcRM=
Date: Mon, 13 Apr 2020 19:41:30 +0200
From: Borislav Petkov <bp@alien8.de>
To: boris.ostrovsky@oracle.com, jgross@suse.com
Subject: Re: [PATCH v2] xen x86: fix early boot crash with gcc-10
Message-ID: <20200413174130.GE3772@zn.tnic>
References: <20200413142051.GC3772@zn.tnic>
 <20200413150314.13974-1-frederic.pierret@qubes-os.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200413150314.13974-1-frederic.pierret@qubes-os.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: sstabellini@kernel.org, xen-devel@lists.xenproject.org, x86@kernel.org,
 linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
 =?utf-8?Q?Fr=C3=A9d=C3=A9ric_Pierret_=28fepitre=29?=
 <frederic.pierret@qubes-os.org>, tglx@linutronix.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 13, 2020 at 05:03:14PM +0200, Frédéric Pierret (fepitre) wrote:
> The change fixes boot failure on VM where kernel (at least v5.4 and v5.6)
> is built with gcc-10 and STACKPROTECTOR_STRONG enabled:
> 
> ```
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: cpu_bringup_and_idle+0x93/0xa0
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.4.31-1.qubes.x86_64 #1
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014
> Call Trace:
>   dump_stack+0x64/0x88
>    panic+0x10b/0x2ed
>    ? cpu_bringup_and_idle+0x93/0xa0
>    __stack_chk_fail+0x15/0x20
>    cpu_bringup_and_idle+0x93/0xa
> ```
> The change makes successfully booting the VM. The VM is hosted by
> KVM hypervisor and is running Xen into.
> 
> Based on work done by Sergei Trofimovich: https://lkml.org/lkml/2020/3/26/1133
> 
> Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org>
> ---
>  arch/x86/xen/smp_pv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
> index 8fb8a50a28b4..5c8ee4a5bb0c 100644
> --- a/arch/x86/xen/smp_pv.c
> +++ b/arch/x86/xen/smp_pv.c
> @@ -88,7 +88,7 @@ static void cpu_bringup(void)
>  	local_irq_enable();
>  }
>  
> -asmlinkage __visible void cpu_bringup_and_idle(void)
> +asmlinkage __visible void __no_stack_protector cpu_bringup_and_idle(void)
>  {
>  	cpu_bringup();
>  	boot_init_stack_canary();
> -- 

Boris O, Jürgen,

you guys might wanna wait a bit with this one:

https://lkml.kernel.org/r/20200413163540.GD3772@zn.tnic

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 18:49:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 18:49:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jO49O-0007Lw-MA; Mon, 13 Apr 2020 18:49:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=F6Pd=55=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jO49N-0007Lr-Rq
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 18:49:41 +0000
X-Inumbo-ID: 870895b4-7db7-11ea-889b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 870895b4-7db7-11ea-889b-12813bfff9fa;
 Mon, 13 Apr 2020 18:49:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=JKGoEyqlCSNJ1+HpPvq/W1TNr2pLBcSZvOuQNP6oVBs=; b=qx/cOEINNfs+ZFvmyC2CM8vmM
 bAvs8fNugRQsej8allX8cy4oLoLFhZcWXTcVaaaoLmUGC5LCZhi3iIG54MWuObgrMPAREb7lS3HdF
 GhJF31faAQOYXDkaVYfoAAPyULatgDFWcnOHMeh/Lga+Rp+0rRxLL+1GmjHy114VDmkCE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jO49K-00089u-Bb; Mon, 13 Apr 2020 18:49:38 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jO49K-0005g6-2k; Mon, 13 Apr 2020 18:49:38 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jO49K-0005qH-2C; Mon, 13 Apr 2020 18:49:38 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149639-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149639: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=792cb70eb062c75dbbb2f2fcdec1f939287d44ef
X-Osstest-Versions-That: qemuu=17e1e49814096a3daaa8e5a73acd56a0f30bdc18
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 13 Apr 2020 18:49:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu                792cb70eb062c75dbbb2f2fcdec1f939287d44ef
baseline version:
 qemuu                17e1e49814096a3daaa8e5a73acd56a0f30bdc18

Last test of basis   149624  2020-04-11 16:43:30 Z    2 days
Testing same since   149639  2020-04-13 12:37:00 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  lixinyu <precinct@mail.ustc.edu.cn>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Henderson <richard.henderson@linaro.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   17e1e49814..792cb70eb0  792cb70eb062c75dbbb2f2fcdec1f939287d44ef -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Mon Apr 13 21:35:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Apr 2020 21:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jO6is-000418-SC; Mon, 13 Apr 2020 21:34:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FM5Z=55=amazon.com=prvs=365775788=havanur@srs-us1.protection.inumbo.net>)
 id 1jO6ir-000413-CF
 for xen-devel@lists.xenproject.org; Mon, 13 Apr 2020 21:34:29 +0000
X-Inumbo-ID: 8deb51a2-7dce-11ea-83d8-bc764e2007e4
Received: from smtp-fw-6002.amazon.com (unknown [52.95.49.90])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8deb51a2-7dce-11ea-83d8-bc764e2007e4;
 Mon, 13 Apr 2020 21:34:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586813669; x=1618349669;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=BzyFTp5WLQkEdTo4lXN7rHGYWuK7IsljElBsa+AyKLw=;
 b=XO6LwSzFkYm+oFmlvaeidbvrzfFw1E3kuqu5YkNtaCCMQB7+c86mnKkI
 7H8KqFuipYLbxA14LSsf09ScsCptoxfmbtCcE1dc75rxPTMidy7jQtiqR
 WECNVDPrJ8lA02dmynQ+5rZBx7jQZJXG4eKNyuGQFVN8wu4JJ1C0nTyl4 k=;
IronPort-SDR: LridPP+I3tG8SzS+cneoKwiKuNf4DSkdo1px7IJMhWX3RIfVHjgoUlpvtuq07ROuLOy1yNLGGQ
 YIuvGoc0qDDQ==
X-IronPort-AV: E=Sophos;i="5.72,380,1580774400"; d="scan'208";a="25305926"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-1d-5dd976cd.us-east-1.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP;
 13 Apr 2020 21:34:16 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166])
 by email-inbound-relay-1d-5dd976cd.us-east-1.amazon.com (Postfix) with ESMTPS
 id BCB2AA2000; Mon, 13 Apr 2020 21:34:14 +0000 (UTC)
Received: from EX13D36EUC003.ant.amazon.com (10.43.164.158) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Mon, 13 Apr 2020 21:34:14 +0000
Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by
 EX13D36EUC003.ant.amazon.com (10.43.164.158) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Mon, 13 Apr 2020 21:34:12 +0000
Received: from dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com
 (172.19.122.179) by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP
 Server id 15.0.1497.2 via Frontend Transport; Mon, 13 Apr 2020 21:34:12 +0000
Received: by dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com (Postfix,
 from userid 11119479)
 id E6D91839A5; Mon, 13 Apr 2020 21:34:11 +0000 (UTC)
From: Harsha Shamsundara Havanur <havanur@amazon.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Mon, 13 Apr 2020 21:33:42 +0000
Message-ID: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Harsha Shamsundara Havanur <havanur@amazon.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It was observed that PCI MMIO and/or IO BARs were programmed with
BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
register) enabled, during PCI setup phase. This resulted in
incorrect memory mapping as soon as the lower half of the 64 bit bar
is programmed, which displaced any RAM mappings under 4G. After the
upper half is programmed PCI memory mapping is restored to its
intended mapping but the RAM displaced is not restored. The OS then
continues to boot and function until it tries to access the displaced
RAM at which point it suffers a page fault and crashes.

This patch address the issue by deferring enablement of memory and
I/O decode in command register until all the resources, like interrupts
I/O and/or MMIO BARs for all the PCI device functions are programmed.

Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
Reviewed-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
 tools/firmware/hvmloader/pci.c | 35 +++++++++++++++++++++++++++--------
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 0b708bf578..f74471b255 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -84,6 +84,7 @@ void pci_setup(void)
     uint32_t vga_devfn = 256;
     uint16_t class, vendor_id, device_id;
     unsigned int bar, pin, link, isa_irq;
+    uint8_t pci_devfn_decode_type[256] = {};
 
     /* Resources assignable to PCI devices via BARs. */
     struct resource {
@@ -120,6 +121,9 @@ void pci_setup(void)
      */
     bool allow_memory_relocate = 1;
 
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY != PCI_COMMAND_MEMORY);
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_IO);
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_MASTER);
     s = xenstore_read(HVM_XS_ALLOW_MEMORY_RELOCATE, NULL);
     if ( s )
         allow_memory_relocate = strtoll(s, NULL, 0);
@@ -289,9 +293,22 @@ void pci_setup(void)
                    devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
         }
 
-        /* Enable bus mastering. */
+        /*
+         * Disable bus mastering, memory and I/O space, which is typical device
+         * reset state. It is recommended that BAR programming be done whilst
+         * decode bits are cleared to avoid incorrect mappings being created,
+         * when 64-bit memory BAR is programmed first by writing the lower half
+         * and then the upper half, which first maps to an address under 4G
+         * replacing any RAM mapped in that address, which is not restored
+         * back after the upper half is written and PCI memory is correctly
+         * mapped to its intended high mem address.
+         *
+         * Capture the state of bus master to restore it back once BAR
+         * programming is completed.
+         */
         cmd = pci_readw(devfn, PCI_COMMAND);
-        cmd |= PCI_COMMAND_MASTER;
+        pci_devfn_decode_type[devfn] = cmd & ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
+        cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
         pci_writew(devfn, PCI_COMMAND, cmd);
     }
 
@@ -503,10 +520,9 @@ void pci_setup(void)
         if ( (bar_reg == PCI_ROM_ADDRESS) ||
              ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
               PCI_BASE_ADDRESS_SPACE_MEMORY) )
-            cmd |= PCI_COMMAND_MEMORY;
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
         else
-            cmd |= PCI_COMMAND_IO;
-        pci_writew(devfn, PCI_COMMAND, cmd);
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_IO;
     }
 
     if ( pci_hi_mem_start )
@@ -526,10 +542,13 @@ void pci_setup(void)
          * has IO enabled, even if there is no I/O BAR on that
          * particular device.
          */
-        cmd = pci_readw(vga_devfn, PCI_COMMAND);
-        cmd |= PCI_COMMAND_IO;
-        pci_writew(vga_devfn, PCI_COMMAND, cmd);
+        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
     }
+
+    /* Enable memory and I/O space. Restore saved BUS MASTER state */
+    for ( devfn = 0; devfn < 256; devfn++ )
+        if ( pci_devfn_decode_type[devfn] )
+            pci_writew(devfn, PCI_COMMAND, pci_devfn_decode_type[devfn]);
 }
 
 /*
-- 
2.16.6



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 00:27:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 00:27:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jO9QL-0001L6-6q; Tue, 14 Apr 2020 00:27:33 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qlbo=56=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jO9QJ-0001L1-Mu
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 00:27:31 +0000
X-Inumbo-ID: b615c032-7de6-11ea-88d0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b615c032-7de6-11ea-88d0-12813bfff9fa;
 Tue, 14 Apr 2020 00:27:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=PF+VB7SHRcfp+dw9o6Pv44DFI7MA9qWzJ8RraboiHdo=; b=EUo8mfPXDTHCQUV/01dcJA/Ba
 kuQPKQECOt7E+ZQT61xWY+fyqelD43Vgn+QjH832eG4hLjMDX98yhxzZ6WxHFW+ysWgWoPDJzOdXL
 2pNfmzk7q3HT2WmeMCA9m34xAzVVRpQzqzVHCi7/QeGp5H2VraXeFnommJKAFBHlirfMA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jO9QB-0006fp-Mg; Tue, 14 Apr 2020 00:27:23 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jO9QB-0000rh-Co; Tue, 14 Apr 2020 00:27:23 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jO9QB-0007ah-C9; Tue, 14 Apr 2020 00:27:23 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149640-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149640: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=e33d61cc9aef14f21fbf16c0e3cf01d2e2965717
X-Osstest-Versions-That: qemuu=792cb70eb062c75dbbb2f2fcdec1f939287d44ef
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 14 Apr 2020 00:27:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149639

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

version targeted for testing:
 qemuu                e33d61cc9aef14f21fbf16c0e3cf01d2e2965717
baseline version:
 qemuu                792cb70eb062c75dbbb2f2fcdec1f939287d44ef

Last test of basis   149639  2020-04-13 12:37:00 Z    0 days
Testing same since   149640  2020-04-13 19:07:25 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexander Duyck <alexander.h.duyck@linux.intel.com>
  Bauerchen <bauerchen@tencent.com>
  Bruce Rogers <brogers@suse.com>
  Igor Mammedov <imammedo@redhat.com>
  Olaf Hering <olaf@aepfle.de>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   792cb70eb0..e33d61cc9a  e33d61cc9aef14f21fbf16c0e3cf01d2e2965717 -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 02:31:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 02:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOBMA-0006Ug-Ss; Tue, 14 Apr 2020 02:31:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Htbk=56=ozlabs.org=dgibson@srs-us1.protection.inumbo.net>)
 id 1jOBM8-0006Ua-MA
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 02:31:21 +0000
X-Inumbo-ID: e0207e9c-7df7-11ea-b4f4-bc764e2007e4
Received: from ozlabs.org (unknown [203.11.71.1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e0207e9c-7df7-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 02:31:17 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1007)
 id 491TwQ2XQSz9s71; Tue, 14 Apr 2020 12:26:43 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=gibson.dropbear.id.au; s=201602; t=1586831398;
 bh=HmsWa8K/94DvliAFszW4AdoanaFl0AvpTunVNJ3j37E=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=F1gbgrLBXGerhx/EuvZz/DHPqzbBqAmokvVRav+nq7l0m1DAecodD/KDke/MsFPvz
 iEti/u5rxIs2t/PxD7CIs09dbTUeaUM3VNz4q+E+TQYT0xOZFylOeK6blOHXt4szoN
 OXpqW+zYFxxiAgHAlnQIKojbsvMwgW9ihAH2csPU=
Date: Tue, 14 Apr 2020 12:07:35 +1000
From: David Gibson <david@gibson.dropbear.id.au>
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= <f4bug@amsat.org>
Subject: Re: [PATCH-for-5.1 3/3] hw: Remove unnecessary DEVICE() cast
Message-ID: <20200414020735.GF48061@umbus.fritz.box>
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-4-f4bug@amsat.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="ahP6B03r4gLOj5uD"
Content-Disposition: inline
In-Reply-To: <20200412210954.32313-4-f4bug@amsat.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, qemu-devel@nongnu.org,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org,
 Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?iso-8859-1?Q?C=E9dric?= Le Goater <clg@kaod.org>,
 John Snow <jsnow@redhat.com>, Richard Henderson <rth@twiddle.net>,
 Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--ahP6B03r4gLOj5uD
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 12, 2020 at 11:09:54PM +0200, Philippe Mathieu-Daud=E9 wrote:
> The DEVICE() macro is defined as:
>=20
>   #define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)
>=20
> Remove unnecessary DEVICE() casts.
>=20
> Patch created mechanically using spatch with this script:
>=20
>   @@
>   typedef DeviceState;
>   DeviceState *s;
>   @@
>   -   DEVICE(s)
>   +   s
>=20
> Signed-off-by: Philippe Mathieu-Daud=E9 <f4bug@amsat.org>

ppc parts

Acked-by: David Gibson <david@gibson.dropbear.id.au>

> ---
>  hw/display/artist.c         | 2 +-
>  hw/display/cg3.c            | 2 +-
>  hw/display/sm501.c          | 2 +-
>  hw/display/tcx.c            | 4 ++--
>  hw/display/vga-isa.c        | 2 +-
>  hw/i2c/imx_i2c.c            | 2 +-
>  hw/i2c/mpc_i2c.c            | 2 +-
>  hw/ide/piix.c               | 2 +-
>  hw/misc/macio/pmu.c         | 2 +-
>  hw/net/ftgmac100.c          | 3 +--
>  hw/net/imx_fec.c            | 2 +-
>  hw/nubus/nubus-device.c     | 2 +-
>  hw/pci-host/bonito.c        | 2 +-
>  hw/ppc/spapr.c              | 2 +-
>  hw/sh4/sh_pci.c             | 2 +-
>  hw/xen/xen-legacy-backend.c | 2 +-
>  16 files changed, 17 insertions(+), 18 deletions(-)
>=20
> diff --git a/hw/display/artist.c b/hw/display/artist.c
> index 753dbb9a77..7e2a4556bd 100644
> --- a/hw/display/artist.c
> +++ b/hw/display/artist.c
> @@ -1353,7 +1353,7 @@ static void artist_realizefn(DeviceState *dev, Erro=
r **errp)
>      s->cursor_height =3D 32;
>      s->cursor_width =3D 32;
> =20
> -    s->con =3D graphic_console_init(DEVICE(dev), 0, &artist_ops, s);
> +    s->con =3D graphic_console_init(dev, 0, &artist_ops, s);
>      qemu_console_resize(s->con, s->width, s->height);
>  }
> =20
> diff --git a/hw/display/cg3.c b/hw/display/cg3.c
> index a1ede10394..f7f1c199ce 100644
> --- a/hw/display/cg3.c
> +++ b/hw/display/cg3.c
> @@ -321,7 +321,7 @@ static void cg3_realizefn(DeviceState *dev, Error **e=
rrp)
> =20
>      sysbus_init_irq(sbd, &s->irq);
> =20
> -    s->con =3D graphic_console_init(DEVICE(dev), 0, &cg3_ops, s);
> +    s->con =3D graphic_console_init(dev, 0, &cg3_ops, s);
>      qemu_console_resize(s->con, s->width, s->height);
>  }
> =20
> diff --git a/hw/display/sm501.c b/hw/display/sm501.c
> index de0ab9d977..2a564889bd 100644
> --- a/hw/display/sm501.c
> +++ b/hw/display/sm501.c
> @@ -1839,7 +1839,7 @@ static void sm501_init(SM501State *s, DeviceState *=
dev,
>                                  &s->twoD_engine_region);
> =20
>      /* create qemu graphic console */
> -    s->con =3D graphic_console_init(DEVICE(dev), 0, &sm501_ops, s);
> +    s->con =3D graphic_console_init(dev, 0, &sm501_ops, s);
>  }
> =20
>  static const VMStateDescription vmstate_sm501_state =3D {
> diff --git a/hw/display/tcx.c b/hw/display/tcx.c
> index 76de16e8ea..1fb45b1aab 100644
> --- a/hw/display/tcx.c
> +++ b/hw/display/tcx.c
> @@ -868,9 +868,9 @@ static void tcx_realizefn(DeviceState *dev, Error **e=
rrp)
>      sysbus_init_irq(sbd, &s->irq);
> =20
>      if (s->depth =3D=3D 8) {
> -        s->con =3D graphic_console_init(DEVICE(dev), 0, &tcx_ops, s);
> +        s->con =3D graphic_console_init(dev, 0, &tcx_ops, s);
>      } else {
> -        s->con =3D graphic_console_init(DEVICE(dev), 0, &tcx24_ops, s);
> +        s->con =3D graphic_console_init(dev, 0, &tcx24_ops, s);
>      }
>      s->thcmisc =3D 0;
> =20
> diff --git a/hw/display/vga-isa.c b/hw/display/vga-isa.c
> index 0633ed382c..3aaeeeca1e 100644
> --- a/hw/display/vga-isa.c
> +++ b/hw/display/vga-isa.c
> @@ -74,7 +74,7 @@ static void vga_isa_realizefn(DeviceState *dev, Error *=
*errp)
>                                          0x000a0000,
>                                          vga_io_memory, 1);
>      memory_region_set_coalescing(vga_io_memory);
> -    s->con =3D graphic_console_init(DEVICE(dev), 0, s->hw_ops, s);
> +    s->con =3D graphic_console_init(dev, 0, s->hw_ops, s);
> =20
>      memory_region_add_subregion(isa_address_space(isadev),
>                                  VBE_DISPI_LFB_PHYSICAL_ADDRESS,
> diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
> index 30b9aea247..2e02e1c4fa 100644
> --- a/hw/i2c/imx_i2c.c
> +++ b/hw/i2c/imx_i2c.c
> @@ -305,7 +305,7 @@ static void imx_i2c_realize(DeviceState *dev, Error *=
*errp)
>                            IMX_I2C_MEM_SIZE);
>      sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->iomem);
>      sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->irq);
> -    s->bus =3D i2c_init_bus(DEVICE(dev), NULL);
> +    s->bus =3D i2c_init_bus(dev, NULL);
>  }
> =20
>  static void imx_i2c_class_init(ObjectClass *klass, void *data)
> diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
> index 0aa1be3ce7..9a724f3a3e 100644
> --- a/hw/i2c/mpc_i2c.c
> +++ b/hw/i2c/mpc_i2c.c
> @@ -332,7 +332,7 @@ static void mpc_i2c_realize(DeviceState *dev, Error *=
*errp)
>      memory_region_init_io(&i2c->iomem, OBJECT(i2c), &i2c_ops, i2c,
>                            "mpc-i2c", 0x14);
>      sysbus_init_mmio(SYS_BUS_DEVICE(dev), &i2c->iomem);
> -    i2c->bus =3D i2c_init_bus(DEVICE(dev), "i2c");
> +    i2c->bus =3D i2c_init_bus(dev, "i2c");
>  }
> =20
>  static void mpc_i2c_class_init(ObjectClass *klass, void *data)
> diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> index 3b2de4c312..b402a93636 100644
> --- a/hw/ide/piix.c
> +++ b/hw/ide/piix.c
> @@ -193,7 +193,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev, bool a=
ux)
>              blk_unref(blk);
>          }
>      }
> -    qdev_reset_all(DEVICE(dev));
> +    qdev_reset_all(dev);
>      return 0;
>  }
> =20
> diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
> index b8466a4a3f..4b7def9096 100644
> --- a/hw/misc/macio/pmu.c
> +++ b/hw/misc/macio/pmu.c
> @@ -758,7 +758,7 @@ static void pmu_realize(DeviceState *dev, Error **err=
p)
> =20
>      if (s->has_adb) {
>          qbus_create_inplace(&s->adb_bus, sizeof(s->adb_bus), TYPE_ADB_BU=
S,
> -                            DEVICE(dev), "adb.0");
> +                            dev, "adb.0");
>          s->adb_poll_timer =3D timer_new_ms(QEMU_CLOCK_VIRTUAL, pmu_adb_p=
oll, s);
>          s->adb_poll_mask =3D 0xffff;
>          s->autopoll_rate_ms =3D 20;
> diff --git a/hw/net/ftgmac100.c b/hw/net/ftgmac100.c
> index 041ed21017..25ebee7ec2 100644
> --- a/hw/net/ftgmac100.c
> +++ b/hw/net/ftgmac100.c
> @@ -1035,8 +1035,7 @@ static void ftgmac100_realize(DeviceState *dev, Err=
or **errp)
>      qemu_macaddr_default_if_unset(&s->conf.macaddr);
> =20
>      s->nic =3D qemu_new_nic(&net_ftgmac100_info, &s->conf,
> -                          object_get_typename(OBJECT(dev)), DEVICE(dev)-=
>id,
> -                          s);
> +                          object_get_typename(OBJECT(dev)), dev->id, s);
>      qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
>  }
> =20
> diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
> index a35c33683e..7adcc9df65 100644
> --- a/hw/net/imx_fec.c
> +++ b/hw/net/imx_fec.c
> @@ -1323,7 +1323,7 @@ static void imx_eth_realize(DeviceState *dev, Error=
 **errp)
> =20
>      s->nic =3D qemu_new_nic(&imx_eth_net_info, &s->conf,
>                            object_get_typename(OBJECT(dev)),
> -                          DEVICE(dev)->id, s);
> +                          dev->id, s);
> =20
>      qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
>  }
> diff --git a/hw/nubus/nubus-device.c b/hw/nubus/nubus-device.c
> index 01ccad9e8e..ffe78a8823 100644
> --- a/hw/nubus/nubus-device.c
> +++ b/hw/nubus/nubus-device.c
> @@ -156,7 +156,7 @@ void nubus_register_rom(NubusDevice *dev, const uint8=
_t *rom, uint32_t size,
> =20
>  static void nubus_device_realize(DeviceState *dev, Error **errp)
>  {
> -    NubusBus *nubus =3D NUBUS_BUS(qdev_get_parent_bus(DEVICE(dev)));
> +    NubusBus *nubus =3D NUBUS_BUS(qdev_get_parent_bus(dev));
>      NubusDevice *nd =3D NUBUS_DEVICE(dev);
>      char *name;
>      hwaddr slot_offset;
> diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
> index cc6545c8a8..f212796044 100644
> --- a/hw/pci-host/bonito.c
> +++ b/hw/pci-host/bonito.c
> @@ -606,7 +606,7 @@ static void bonito_pcihost_realize(DeviceState *dev, =
Error **errp)
>      BonitoState *bs =3D BONITO_PCI_HOST_BRIDGE(dev);
> =20
>      memory_region_init(&bs->pci_mem, OBJECT(dev), "pci.mem", BONITO_PCIL=
O_SIZE);
> -    phb->bus =3D pci_register_root_bus(DEVICE(dev), "pci",
> +    phb->bus =3D pci_register_root_bus(dev, "pci",
>                                       pci_bonito_set_irq, pci_bonito_map_=
irq,
>                                       dev, &bs->pci_mem, get_system_io(),
>                                       0x28, 32, TYPE_PCI_BUS);
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 9a2bd501aa..3337f5e79c 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -4031,7 +4031,7 @@ static void spapr_phb_plug(HotplugHandler *hotplug_=
dev, DeviceState *dev,
>      /* hotplug hooks should check it's enabled before getting this far */
>      assert(drc);
> =20
> -    spapr_drc_attach(drc, DEVICE(dev), &local_err);
> +    spapr_drc_attach(drc, dev, &local_err);
>      if (local_err) {
>          error_propagate(errp, local_err);
>          return;
> diff --git a/hw/sh4/sh_pci.c b/hw/sh4/sh_pci.c
> index 08f2fc1dde..0a3e86f949 100644
> --- a/hw/sh4/sh_pci.c
> +++ b/hw/sh4/sh_pci.c
> @@ -129,7 +129,7 @@ static void sh_pci_device_realize(DeviceState *dev, E=
rror **errp)
>      for (i =3D 0; i < 4; i++) {
>          sysbus_init_irq(sbd, &s->irq[i]);
>      }
> -    phb->bus =3D pci_register_root_bus(DEVICE(dev), "pci",
> +    phb->bus =3D pci_register_root_bus(dev, "pci",
>                                       sh_pci_set_irq, sh_pci_map_irq,
>                                       s->irq,
>                                       get_system_memory(),
> diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
> index 4a373b2373..f9d013811a 100644
> --- a/hw/xen/xen-legacy-backend.c
> +++ b/hw/xen/xen-legacy-backend.c
> @@ -705,7 +705,7 @@ int xen_be_init(void)
> =20
>      xen_sysdev =3D qdev_create(NULL, TYPE_XENSYSDEV);
>      qdev_init_nofail(xen_sysdev);
> -    xen_sysbus =3D qbus_create(TYPE_XENSYSBUS, DEVICE(xen_sysdev), "xen-=
sysbus");
> +    xen_sysbus =3D qbus_create(TYPE_XENSYSBUS, xen_sysdev, "xen-sysbus");
>      qbus_set_bus_hotplug_handler(xen_sysbus, &error_abort);
> =20
>      return 0;

--=20
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

--ahP6B03r4gLOj5uD
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAl6VGucACgkQbDjKyiDZ
s5KoIhAAqcK6HrObC31z9u8JjLG9LjEA5kk7/mHXFJlQKMzbaUPmPKy/BC+QgFQ6
fJ55NL/NdQRQpwJTQGFl6o2oFmbZHRXF8cgZvlXD/1QCNVcqdOkDV9wWfB2DuOny
rxeb6A86iunkfnLEb6gA0CFZcUt0Em3bU73GGKkA+/1Q/0mq/BXx5tlJx8+NNnCs
jqeuZwgqyDy1RyjwtL5UL0ai49BQbUpwH+WMqQnnNRIzgDvWkb0+vo7GYeNfzK7v
FCrz2XvCJ0HCPsAtt3eVItl8ZFR7iUqsio3C7pCZKW20+c+1B0iq4ydJdzu6fPgR
hbY7pJWzwRng8qL1/tGy84Bh41vv67W/VMb6JL3RYn36SWYzjp7UnjF7IFrWY6/E
QTR/aw8K4XZiV2kMMyMDeE1hoMTqjaUC601jqbVp6M3PYrPq9dL6HKXXILjpVpxS
zfIrMhb/JsCkW7Kcnvps3wJ2yPJ9ByibIQRHVahFVv7niAYrKSPavnUYkxjKvJoX
WO/sl89qW57rOGbO45goK7aMbyleOe4qmxlrI9p7DEZYicwZEzS4lsLUEfzKb1O+
4A5n4jiwXr1zBgisy54f48pTdxKG7SGuBtmPPWVpmO/lCGUzey9J9LUM9qYiiHwO
fLPRSGBJwYvqAuQGpI16BDKTeWJYpCC358/N4U1iy9apJ8H39Nk=
=WzAC
-----END PGP SIGNATURE-----

--ahP6B03r4gLOj5uD--


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 02:32:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 02:32:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOBMv-0006Zi-D2; Tue, 14 Apr 2020 02:32:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Htbk=56=ozlabs.org=dgibson@srs-us1.protection.inumbo.net>)
 id 1jOBMt-0006Yu-Us
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 02:32:07 +0000
X-Inumbo-ID: 050f548a-7df8-11ea-83d8-bc764e2007e4
Received: from ozlabs.org (unknown [203.11.71.1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 050f548a-7df8-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 02:32:05 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1007)
 id 491Twy4ztKz9sV1; Tue, 14 Apr 2020 12:25:10 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=gibson.dropbear.id.au; s=201602; t=1586831426;
 bh=/kHCQs6uMq+5u4/mtGXY7lBRycSbLGC1KTKNOnBA2Y4=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=c02G4tpwBKtSX4Cy8dl3mWquRLc7WiCQh5osqLeugliTuijy/MqJw6vfNgSiAPsAB
 H0YZVfk8CA0NZX5GT9p219pJeA47NIauIGJIowvaA560ShRZvHfBEXyj1poiCf1JRv
 eqv3brG/NrRLimiYlJ5uPxblFDSFWPQwtvkelr1A=
Date: Tue, 14 Apr 2020 12:06:34 +1000
From: David Gibson <david@gibson.dropbear.id.au>
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= <f4bug@amsat.org>
Subject: Re: [PATCH-for-5.1 1/3] target: Remove unnecessary CPU() cast
Message-ID: <20200414020634.GE48061@umbus.fritz.box>
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-2-f4bug@amsat.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="65ImJOski3p8EhYV"
Content-Disposition: inline
In-Reply-To: <20200412210954.32313-2-f4bug@amsat.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, qemu-devel@nongnu.org,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org,
 Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?iso-8859-1?Q?C=E9dric?= Le Goater <clg@kaod.org>,
 John Snow <jsnow@redhat.com>, Richard Henderson <rth@twiddle.net>,
 Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--65ImJOski3p8EhYV
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 12, 2020 at 11:09:52PM +0200, Philippe Mathieu-Daud=E9 wrote:
> The CPU() macro is defined as:
>=20
>   #define CPU(obj) ((CPUState *)(obj))
>=20
> Remove an unnecessary CPU() cast.
>=20
> Patch created mechanically using spatch with this script:
>=20
>   @@
>   typedef CPUState;
>   CPUState *s;
>   @@
>   -   CPU(s)
>   +   s
>=20
> Signed-off-by: Philippe Mathieu-Daud=E9 <f4bug@amsat.org>

Acked-by: David Gibson <david@gibson.dropbear.id.au>

> ---
>  target/ppc/mmu_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>=20
> diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
> index 86c667b094..8972714775 100644
> --- a/target/ppc/mmu_helper.c
> +++ b/target/ppc/mmu_helper.c
> @@ -1820,7 +1820,7 @@ static inline void do_invalidate_BAT(CPUPPCState *e=
nv, target_ulong BATu,
>      if (((end - base) >> TARGET_PAGE_BITS) > 1024) {
>          /* Flushing 1024 4K pages is slower than a complete flush */
>          LOG_BATS("Flush all BATs\n");
> -        tlb_flush(CPU(cs));
> +        tlb_flush(cs);
>          LOG_BATS("Flush done\n");
>          return;
>      }

--=20
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

--65ImJOski3p8EhYV
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAl6VGqoACgkQbDjKyiDZ
s5KKyg/9FKEqC9D+alWv+8iNCU4sWOQEsmLKphUN1iQEQx1mOEnwEWoegLrG9pUK
mwn+RgxzzFhb2w5xatd+CDz2NzGNYfNNjOiraIrEWWKaPwK9Lz3xLw2J9ChxWcTs
BCb9Tpjl2dwIMYFW4GaLevqosEDRE0Z0IoVKGpyrlVnDLmRWX3ajL1g6KeFILh0c
TBWZlu0/WoHUIk8YZQHWtWQinxOoutnQzshdD4vxpX6qQ6ujrIhbyUFObWNJICse
A2pwFIA41B3rTESPKkxMeFoNXiWcEyd0Jk4qZvJRP0EI5TgLwkFFYogCGFYNS+Z7
UgPPvjgfGd/XbKXuf8sXjUcZgxg6M2lu8nbZ/fsRTTZV33Cjf9scAISZpLkH9bJ1
e4Ln3ge1xIUjhnQvsJ86nzHQLUPE9B1c9XHLYPI8xvDRy3Iup1DvZFi2zqZeMxP6
w0BO5X9OXBJLfo9d3O5UhsOe7fPfojFhHSp1PMovJzhRovcs40eWrJbbl6eJ0pA4
AIJeFYhPxdG/FYCdHPaDS6yIuAgrDHI0v/LXv9aQrfs4qa+ImpUosZwIY8CplZDa
HrM1GoVtuK9RcT/hANmrzlOg+dBFmQJ7IgimXNnVxBgMFQywio61NLYFrhJgfMTq
4mgomt1X+/UMWLjTmnBfgGap+QMG9ORP+H5M7RpHrwcnIjJ6vnI=
=dPwq
-----END PGP SIGNATURE-----

--65ImJOski3p8EhYV--


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 06:28:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 06:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOF3Y-0000EX-Nw; Tue, 14 Apr 2020 06:28:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOF3W-0000EO-V4
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 06:28:22 +0000
X-Inumbo-ID: 22a86de4-7e19-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 22a86de4-7e19-11ea-9e09-bc764e2007e4;
 Tue, 14 Apr 2020 06:28:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4E3A5AD75;
 Tue, 14 Apr 2020 06:28:19 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: Wei Liu <wl@xen.org>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200410154843.ocpl4gpqt5hsifba@debian>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <2e5b9e8e-f768-005f-5310-0cd4b9312461@suse.com>
Date: Tue, 14 Apr 2020 08:28:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200410154843.ocpl4gpqt5hsifba@debian>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 10.04.2020 17:48, Wei Liu wrote:
> On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
>> On 06.04.2020 12:57, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm/hap/private.h
>>> +++ b/xen/arch/x86/mm/hap/private.h
>>> @@ -47,4 +47,9 @@ unsigned long hap_p2m_ga_to_gfn_4_levels(struct vcpu *v,
>>>      struct p2m_domain *p2m, unsigned long cr3,
>>>      paddr_t ga, uint32_t *pfec, unsigned int *page_order);
>>>  
>>> +static inline void hap_flush_tlb_mask(const cpumask_t *mask)
>>> +{
>>> +    flush_mask(mask, FLUSH_HVM_ASID_CORE);
>>> +}
>>
>> With the above introduction of this would then become unnecessary.
> 
> I had planned to make the required adjustment(s) and commit v9 today.

Actually I came to make these comments in the course of preparing
to commit the series, while making the small adjustments.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 06:35:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 06:35:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOFA3-000159-Ho; Tue, 14 Apr 2020 06:35:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOFA2-000153-GN
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 06:35:06 +0000
X-Inumbo-ID: 13d21454-7e1a-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 13d21454-7e1a-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 06:35:06 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 18FC1AB3D;
 Tue, 14 Apr 2020 06:35:04 +0000 (UTC)
Subject: Re: preparations for 4.13.1 and 4.12.3
To: Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
 <86c6ffb6-22d0-cbce-8682-dac37697bbfd@xen.org>
 <alpine.DEB.2.21.2004100926350.19608@sstabellini-ThinkPad-T480s>
 <cb32ed05-072f-87a9-a6ed-83a9062df5a5@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <593b2b99-60af-ea19-e1ae-76bdae60cb84@suse.com>
Date: Tue, 14 Apr 2020 08:35:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <cb32ed05-072f-87a9-a6ed-83a9062df5a5@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 10.04.2020 19:54, Julien Grall wrote:
> On 10/04/2020 17:37, Stefano Stabellini wrote:
>> I think the following could be a good candidate. It also touches x86 so
>> I thought I should ask you.
>>
>> 6827bea2b3b99153821b8b7446bdced27f720188 dom0-build: fix build with clang5

Hmm, I didn't think anyone but me had noticed the issue, or else
I would have expected some support in getting this in faster than
it actually went in (half a yer? more?), so I had rather decided
against.

> If we are backporting build fixes for newer compilers, shouldn't we backport all of them?

Probably; I'm not sure I'd call clang5 "newer" though. Aren't they
at v9 or v10 now? Irrespective of this - are you aware of other
"newer compiler" changes? Normally I would pick such up, at the
very least for the newest of the stable trees, but generally for
all of them since sooner or later we'd be hit by people trying to
build older (by the time) trees with new tool chains.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 06:36:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 06:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOFB2-00019W-U7; Tue, 14 Apr 2020 06:36:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qlbo=56=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOFB1-00019O-83
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 06:36:07 +0000
X-Inumbo-ID: 36995a6a-7e1a-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 36995a6a-7e1a-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 06:36:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=1y05afY5VmVYdnWC5rNo8aweo8h4pxdn7sQM/co/Twk=; b=Z1CEfj6voDLCpFK+VzU9jsmjS
 Ov2sYmwknHC/miMHx5MNBrMICqBwjFwSvkWzwUZLly34SyKkM4jqKCwjHNNCchWKYOqZe6E01p/9J
 uoAFdeTAvAyY/6xk4tIgVdZFz8ZW+lCGttgRJvQ3ji5y30qPnfvEebnMROeB3bn8XcKEY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOFAx-0001zx-Lv; Tue, 14 Apr 2020 06:36:03 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOFAx-0008Qy-8B; Tue, 14 Apr 2020 06:36:03 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOFAx-0000aR-6x; Tue, 14 Apr 2020 06:36:03 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149643-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149643: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=7118bdee1550b6022e7362402ca8204add4cf80b
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 14 Apr 2020 06:36:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-xsm  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-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       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-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              7118bdee1550b6022e7362402ca8204add4cf80b
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   88 days
Failing since        146211  2020-01-18 04:18:52 Z   87 days   84 attempts
Testing same since   149635  2020-04-13 04:19:36 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 14534 lines long.)


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 06:57:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 06:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOFVs-0002ta-Tm; Tue, 14 Apr 2020 06:57:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qlbo=56=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOFVr-0002tV-FY
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 06:57:39 +0000
X-Inumbo-ID: 36f98d6a-7e1d-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 36f98d6a-7e1d-11ea-9e09-bc764e2007e4;
 Tue, 14 Apr 2020 06:57:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=OJ1kAblAD3KRb743rC3ELK3M8dC3c7d8vugW8QBwTMM=; b=IZvrGVU/nJQTVmCpoDoEgzGTL
 Ii9dZ89jGeZBUz7Guhncl4orKpLFS6bbei1OLuzwHovscJcLlGkGIsFvCP6I2vVj5VUtegVHKr75w
 Js+I1hvnveI/zuuyE5n5Pixpir1OD2KEcijEoldbAh8fkkJJ8S6jI/9DwzOst9qEqwVDU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOFVk-0002Px-Ol; Tue, 14 Apr 2020 06:57:32 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOFVk-0001GV-CE; Tue, 14 Apr 2020 06:57:32 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOFVk-0006n5-BY; Tue, 14 Apr 2020 06:57:32 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149641-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149641: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=14e5526b51910efd62cd31cd95b49baca975c83f
X-Osstest-Versions-That: qemuu=e33d61cc9aef14f21fbf16c0e3cf01d2e2965717
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 14 Apr 2020 06:57:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu                14e5526b51910efd62cd31cd95b49baca975c83f
baseline version:
 qemuu                e33d61cc9aef14f21fbf16c0e3cf01d2e2965717

Last test of basis   149640  2020-04-13 19:07:25 Z    0 days
Testing same since   149641  2020-04-14 00:36:57 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  David Hildenbrand <david@redhat.com>
  Michael S. Tsirkin <mst@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Raphael Norwitz <raphael.norwitz@nutanix.com>
  Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   e33d61cc9a..14e5526b51  14e5526b51910efd62cd31cd95b49baca975c83f -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 07:14:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 07:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOFm5-0004bn-EX; Tue, 14 Apr 2020 07:14:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=akv/=56=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jOFm4-0004bh-4o
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 07:14:24 +0000
X-Inumbo-ID: 90e41686-7e1f-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x52b.google.com (unknown [2a00:1450:4864:20::52b])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 90e41686-7e1f-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 07:14:23 +0000 (UTC)
Received: by mail-ed1-x52b.google.com with SMTP id s10so7522666edy.9
 for <xen-devel@lists.xenproject.org>; Tue, 14 Apr 2020 00:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=UPl8Vc08yZvXnj9e+clalIg/qDk+S78wH0kNLz1cnTM=;
 b=cDC/AWhYs8VeclpczMQ+nWKlkHo+6TNqJh0NrHl5/bs0WriSFIdo3XBsaUD7ePRZHe
 NEW9SqTY4oaqIC2Y/EaS4yfPk3Uv4LuVEi3oLJy03dqZVz/J3BrAP3NgBtwgGzUeQlHe
 qQi9H4zrpUQIS9tpRFllWKDfMd6EzHU99W78oJiqDrWWwDyYS5qa0OkpPi8V95m9p8Um
 FHdTbD+1XAY38mrLapjh6w5wbslEhc9mdhUmpcK2hDNeWCgPBLQZWiH9FbWRTdVOOKB9
 dI5qDksUntfo2FUhoDWEi8zY5e4XYPgugP2/Xd7gHznBjNehL1/JodqE67TYC4gr1sw8
 AGrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=UPl8Vc08yZvXnj9e+clalIg/qDk+S78wH0kNLz1cnTM=;
 b=A1QgBtJo4MqmcVGdYJm4zSD10ra+T03Of2YkPGlYd41ATgtfy1yZzfvcSF3OD1vvSX
 SjGn9aX3is8sw7nnBxIZVXTeaIumtthrvWx6rzvr1xak5NLv4FnGd0HFXIesflYLpDH0
 SVEazG48O4E0Ezy6eI77UdLzNzNPOovvIJK6ZueTU9tYdasfrUrxVx/5apO3bLXb8PgF
 leT++0nxlCz7bzfO52V8lgWkhSCraEyJqYjhxEgKHEsnHDJJwMI7LzxdbxEQ7UiSXv0x
 1mcPqqn8IWNLW0SH1yGwVHMP/7l1wIDzCCXJJ5K9XaiO9gmp2lWO3cspy7/mJ+ycWPAv
 b25Q==
X-Gm-Message-State: AGi0PuY7fRwnO8whKNVRuA5owrZck93aN2eL5fCGqtzxTVuiRtJnvIeL
 HieO9D16AFgJt4X2fT760TU=
X-Google-Smtp-Source: APiQypLHMbamzeoV0tCSAZIWZTN7JIFW698jKJ43W/2gz9gP/YIzqn3fve8VHf/Z7HPLTQ3RWL1aEQ==
X-Received: by 2002:a17:907:1185:: with SMTP id
 uz5mr19460491ejb.335.1586848462436; 
 Tue, 14 Apr 2020 00:14:22 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id k33sm1600483edc.18.2020.04.14.00.14.18
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 14 Apr 2020 00:14:21 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: =?utf-8?Q?'Philippe_Mathieu-Daud=C3=A9'?= <f4bug@amsat.org>,
 <qemu-devel@nongnu.org>
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-4-f4bug@amsat.org>
In-Reply-To: <20200412210954.32313-4-f4bug@amsat.org>
Subject: RE: [PATCH-for-5.1 3/3] hw: Remove unnecessary DEVICE() cast
Date: Tue, 14 Apr 2020 08:14:18 +0100
Message-ID: <004101d6122c$52094ad0$f61be070$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQLGp+eFp3IRGcFg/miJ8dc6gyP15QIEt8vKpobi2pA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Peter Maydell' <peter.maydell@linaro.org>,
 'David Hildenbrand' <david@redhat.com>, 'Jason Wang' <jasowang@redhat.com>,
 'Mark Cave-Ayland' <mark.cave-ayland@ilande.co.uk>,
 'BALATON Zoltan' <balaton@eik.bme.hu>, 'Gerd Hoffmann' <kraxel@redhat.com>,
 "'Edgar E. Iglesias'" <edgar.iglesias@gmail.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>, qemu-block@nongnu.org,
 'Markus Armbruster' <armbru@redhat.com>, 'Halil Pasic' <pasic@linux.ibm.com>,
 'Christian Borntraeger' <borntraeger@de.ibm.com>,
 'Aleksandar Markovic' <aleksandar.qemu.devel@gmail.com>,
 'Joel Stanley' <joel@jms.id.au>, 'Anthony Perard' <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, 'David Gibson' <david@gibson.dropbear.id.au>,
 =?utf-8?Q?'Philippe_Mathieu-Daud=C3=A9'?= <philmd@redhat.com>,
 'Eduardo Habkost' <ehabkost@redhat.com>, 'Corey Minyard' <minyard@acm.org>,
 "'Dr. David Alan Gilbert'" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, 'Peter Chubb' <peter.chubb@nicta.com.au>,
 =?utf-8?Q?'C=C3=A9dric_Le_Goater'?= <clg@kaod.org>,
 'John Snow' <jsnow@redhat.com>, 'Richard Henderson' <rth@twiddle.net>,
 "=?utf-8?Q?'Daniel_P._Berrang=C3=A9'?=" <berrange@redhat.com>,
 'Andrew Jeffery' <andrew@aj.id.au>, 'Cornelia Huck' <cohuck@redhat.com>,
 'Laurent Vivier' <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 'Paolo Bonzini' <pbonzini@redhat.com>, 'Aurelien Jarno' <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Philippe Mathieu-Daud=C3=A9 <philippe.mathieu.daude@gmail.com> =
On Behalf Of Philippe Mathieu-Daud=C3=A9
> Sent: 12 April 2020 22:10
> To: qemu-devel@nongnu.org
> Cc: Richard Henderson <rth@twiddle.net>; Halil Pasic =
<pasic@linux.ibm.com>; Peter Chubb
> <peter.chubb@nicta.com.au>; C=C3=A9dric Le Goater <clg@kaod.org>; =
David Gibson
> <david@gibson.dropbear.id.au>; Eduardo Habkost <ehabkost@redhat.com>; =
Anthony Perard
> <anthony.perard@citrix.com>; BALATON Zoltan <balaton@eik.bme.hu>; =
xen-devel@lists.xenproject.org;
> Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>; =
qemu-block@nongnu.org; Corey Minyard
> <minyard@acm.org>; Daniel P. Berrang=C3=A9 <berrange@redhat.com>; =
Christian Borntraeger
> <borntraeger@de.ibm.com>; Philippe Mathieu-Daud=C3=A9 =
<philmd@redhat.com>; Stefano Stabellini
> <sstabellini@kernel.org>; Mark Cave-Ayland =
<mark.cave-ayland@ilande.co.uk>; qemu-arm@nongnu.org; qemu-
> ppc@nongnu.org; Jason Wang <jasowang@redhat.com>; Markus Armbruster =
<armbru@redhat.com>; qemu-
> s390x@nongnu.org; Dr. David Alan Gilbert <dgilbert@redhat.com>; Joel =
Stanley <joel@jms.id.au>; David
> Hildenbrand <david@redhat.com>; Aurelien Jarno <aurelien@aurel32.net>; =
Laurent Vivier
> <laurent@vivier.eu>; Peter Maydell <peter.maydell@linaro.org>; =
Cornelia Huck <cohuck@redhat.com>;
> Paolo Bonzini <pbonzini@redhat.com>; Andrew Jeffery <andrew@aj.id.au>; =
John Snow <jsnow@redhat.com>;
> Edgar E. Iglesias <edgar.iglesias@gmail.com>; Gerd Hoffmann =
<kraxel@redhat.com>; Paul Durrant
> <paul@xen.org>; Philippe Mathieu-Daud=C3=A9 <f4bug@amsat.org>
> Subject: [PATCH-for-5.1 3/3] hw: Remove unnecessary DEVICE() cast
>=20
> The DEVICE() macro is defined as:
>=20
>   #define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)
>=20
> Remove unnecessary DEVICE() casts.
>=20
> Patch created mechanically using spatch with this script:
>=20
>   @@
>   typedef DeviceState;
>   DeviceState *s;
>   @@
>   -   DEVICE(s)
>   +   s
>=20
> Signed-off-by: Philippe Mathieu-Daud=C3=A9 <f4bug@amsat.org>

Xen part...

Acked-by: Paul Durrant <paul@xen.org>





From xen-devel-bounces@lists.xenproject.org Tue Apr 14 07:42:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 07:42:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOGDM-00074c-R2; Tue, 14 Apr 2020 07:42:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOGDM-00074X-5T
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 07:42:36 +0000
X-Inumbo-ID: 810fdc50-7e23-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 810fdc50-7e23-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 07:42:34 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CB051AE2D;
 Tue, 14 Apr 2020 07:42:32 +0000 (UTC)
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: Harsha Shamsundara Havanur <havanur@amazon.com>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
Date: Tue, 14 Apr 2020 09:42:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 13.04.2020 23:33, Harsha Shamsundara Havanur wrote:
> It was observed that PCI MMIO and/or IO BARs were programmed with
> BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> register) enabled, during PCI setup phase. This resulted in
> incorrect memory mapping as soon as the lower half of the 64 bit bar
> is programmed, which displaced any RAM mappings under 4G. After the
> upper half is programmed PCI memory mapping is restored to its
> intended mapping but the RAM displaced is not restored. The OS then
> continues to boot and function until it tries to access the displaced
> RAM at which point it suffers a page fault and crashes.
> 
> This patch address the issue by deferring enablement of memory and
> I/O decode in command register until all the resources, like interrupts
> I/O and/or MMIO BARs for all the PCI device functions are programmed.
> 
> Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
> Reviewed-by: Paul Durrant <pdurrant@amazon.com>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
>  tools/firmware/hvmloader/pci.c | 35 +++++++++++++++++++++++++++--------
>  1 file changed, 27 insertions(+), 8 deletions(-)

There not being any description of what has changed in v2, I also
can't easily judge whether keeping the two tags above was
legitimate. In any event you don't seem to have taken care of all
review feedback (whether by making changes to the patch or by
replying verbally).

> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -84,6 +84,7 @@ void pci_setup(void)
>      uint32_t vga_devfn = 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    uint8_t pci_devfn_decode_type[256] = {};
>  
>      /* Resources assignable to PCI devices via BARs. */
>      struct resource {
> @@ -120,6 +121,9 @@ void pci_setup(void)
>       */
>      bool allow_memory_relocate = 1;
>  
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY != PCI_COMMAND_MEMORY);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_IO);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_MASTER);

This looks like a copy-and-paste mistake - are you sure you've
build-tested this? (This alone likely invalidates the tags, as
per above.)

> @@ -289,9 +293,22 @@ void pci_setup(void)
>                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
>          }
>  
> -        /* Enable bus mastering. */
> +        /*
> +         * Disable bus mastering, memory and I/O space, which is typical device
> +         * reset state. It is recommended that BAR programming be done whilst
> +         * decode bits are cleared to avoid incorrect mappings being created,
> +         * when 64-bit memory BAR is programmed first by writing the lower half
> +         * and then the upper half, which first maps to an address under 4G
> +         * replacing any RAM mapped in that address, which is not restored
> +         * back after the upper half is written and PCI memory is correctly
> +         * mapped to its intended high mem address.
> +         *
> +         * Capture the state of bus master to restore it back once BAR
> +         * programming is completed.
> +         */
>          cmd = pci_readw(devfn, PCI_COMMAND);
> -        cmd |= PCI_COMMAND_MASTER;
> +        pci_devfn_decode_type[devfn] = cmd & ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
> +        cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);

The disabling of MASTER was put under question in v1 already.

> @@ -526,10 +542,13 @@ void pci_setup(void)
>           * has IO enabled, even if there is no I/O BAR on that
>           * particular device.
>           */
> -        cmd = pci_readw(vga_devfn, PCI_COMMAND);
> -        cmd |= PCI_COMMAND_IO;
> -        pci_writew(vga_devfn, PCI_COMMAND, cmd);
> +        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
>      }
> +
> +    /* Enable memory and I/O space. Restore saved BUS MASTER state */
> +    for ( devfn = 0; devfn < 256; devfn++ )
> +        if ( pci_devfn_decode_type[devfn] )
> +            pci_writew(devfn, PCI_COMMAND, pci_devfn_decode_type[devfn]);

You effectively clear the upper 8 bits here, rather than retaining
them.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 07:52:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 07:52:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOGMh-0007wH-SH; Tue, 14 Apr 2020 07:52:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOGMg-0007wC-Aj
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 07:52:14 +0000
X-Inumbo-ID: d98ea284-7e24-11ea-88fa-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d98ea284-7e24-11ea-88fa-12813bfff9fa;
 Tue, 14 Apr 2020 07:52:12 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B39DDAC12;
 Tue, 14 Apr 2020 07:52:10 +0000 (UTC)
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200410164942.9747-1-sstabellini@kernel.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
Date: Tue, 14 Apr 2020 09:52:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200410164942.9747-1-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, julien@xen.org, konrad.wilk@oracle.com,
 andrew.cooper3@citrix.com, george.dunlap@citrix.com,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 10.04.2020 18:49, Stefano Stabellini wrote:
> Create a new document under docs/process to describe our special tags.
> For now, only add the new backport tag.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Acked-by: Wei Liu <wl@xen.org>
> CC: jbeulich@suse.com
> CC: george.dunlap@citrix.com
> CC: julien@xen.org
> CC: lars.kurth@citrix.com
> CC: andrew.cooper3@citrix.com
> CC: konrad.wilk@oracle.com
> 
> ---
> 
> This is the original thread: https://marc.info/?l=xen-devel&m=157324027614941
> 
> The backport tag was agreed upon.

Well, sort of.

> George requested the file to be
> renamed to something more generic, where we could add more information
> later.
> 
> I kept the original content and acked-by. I renamed the file to
> tags.pandoc.
> ---
>  docs/process/tags.pandoc | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>  create mode 100644 docs/process/tags.pandoc
> 
> diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
> new file mode 100644
> index 0000000000..e570efdcc8
> --- /dev/null
> +++ b/docs/process/tags.pandoc
> @@ -0,0 +1,23 @@
> +Backport Tag
> +------------
> +
> +A backport tag is an optional tag in the commit message to request a
> +given commit to be backported to the stable trees:

Insert "fully maintained"?

> +    Backport: all
> +
> +It marks a commit for being a candidate for backports to all relevant
> +trees.

I'm unconvinced of the utility of this form - what "all" resolves to
changes over time. There's almost always a first version where a
particular issue was introduced. If we want this to be generally
useful, imo we shouldn't limit the scope of the tag to the upstream
maintained stable trees.

> +    Backport: 4.9+
> +
> +It marks a commit for being a candidate for backports to all stable
> +trees from 4.9 onward.
> +
> +Maintainers request the Backport tag to be added on commit.
> +Contributors are also welcome to mark their patches with the Backport
> +tag when they deem appropriate. Maintainers will request for it to be
> +removed when that is not the case.
> +
> +Please note that the Backport tag is a **request** for backport, which
> +will still need to be evaluated by the stable tree maintainers.

Now that we see more widespread use of the Fixes: tag, with there
being effectively some overlap between the information conveyed I
think there should be some mention of this. Not the least there's the
risk of the Backport: one to become stale when a flaky commit gets
backported - the Fixes: tag doesn't have this issue.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 07:53:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 07:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOGNV-000808-9t; Tue, 14 Apr 2020 07:53:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=18iO=56=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOGNU-000801-2k
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 07:53:04 +0000
X-Inumbo-ID: f6352126-7e24-11ea-88fa-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f6352126-7e24-11ea-88fa-12813bfff9fa;
 Tue, 14 Apr 2020 07:53:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586850782;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=CFt85BU1qwoXszX5XYJ/HQmnvGzfLzj1No+G8/T/n/g=;
 b=EK8LJH+FtS8FiPSuwfrnkhhY6CUC0mLOHzLLk/Adth0pj6C8gdmPRJ5y
 pgCDP+2qivgl/gRMk3+QesIWu3RQnFIdjvIE4qdcWq/1zFwn+8Za3OQWE
 UG46/G4ThiVySkS5V0HpS6KGV5q3gtbGRK9ojEahCPklKfahyQLmwJYQK I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 5/iclHshC0egJG/nk0FkVyQyHns2TW5GKgLrtkCMQ4STKhdXgEeEuf4CxDhkYOMlohX+UOwc0t
 D9S+NFDjymi4049FdNMHu9mMieqEIFxDRZCgP2Stgz9rKy23R9YYLM/xPJM29r4/9npeU4Qq2c
 Kqd7RxPBEavIB/6yN81+PCiiyl0Bu9J68hEi0nm4aD42DRRV4QRNdS5UirC2lYr7OYEeumbLZ7
 dpbKsulbGhSRIecd3mYaRzqGbzXr9Hbq++RkWUhnRPl+hwprknJvisWygRh+eCaKzTdpPbOQA/
 ZRg=
X-SBRS: 2.7
X-MesageID: 16296411
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,381,1580792400"; d="scan'208";a="16296411"
Date: Tue, 14 Apr 2020 09:52:45 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200414075245.GC28601@Air-de-Roger>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
> On 06.04.2020 12:57, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
> >              p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
> >                                    p2m_ram_rw, p2m_ram_logdirty);
> >  
> > -            flush_tlb_mask(d->dirty_cpumask);
> > +            hap_flush_tlb_mask(d->dirty_cpumask);
> >  
> >              memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
> >          }
> > @@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
> >           * to be read-only, or via hardware-assisted log-dirty.
> >           */
> >          p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> > -        flush_tlb_mask(d->dirty_cpumask);
> > +        hap_flush_tlb_mask(d->dirty_cpumask);
> >      }
> >      return 0;
> >  }
> > @@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
> >       * be read-only, or via hardware-assisted log-dirty.
> >       */
> >      p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> > -    flush_tlb_mask(d->dirty_cpumask);
> > +    hap_flush_tlb_mask(d->dirty_cpumask);
> >  }
> >  
> >  /************************************************/
> > @@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
> >  
> >      safe_write_pte(p, new);
> >      if ( old_flags & _PAGE_PRESENT )
> > -        flush_tlb_mask(d->dirty_cpumask);
> > +        hap_flush_tlb_mask(d->dirty_cpumask);
> >  
> >      paging_unlock(d);
> >  
> 
> Following up on my earlier mail about paging_log_dirty_range(), I'm
> now of the opinion that all of these flushes should go away too. I
> can only assume that they got put where they are when HAP code was
> cloned from the shadow one. These are only p2m operations, and hence
> p2m level TLB flushing is all that's needed here.

IIRC without those ASID flushes NPT won't work correctly, as I think
it relies on those flushes when updating the p2m.

We could see about moving those flushes inside the NPT functions that
modify the p2m, AFAICT p2m_pt_set_entry which calls
p2m->write_p2m_entry relies on the later doing the ASID flushes, as it
doesn't perform any.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 08:02:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 08:02:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOGWG-00011f-Vv; Tue, 14 Apr 2020 08:02:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=18iO=56=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOGWF-00011a-Lz
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 08:02:07 +0000
X-Inumbo-ID: 3babb5fa-7e26-11ea-b58d-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3babb5fa-7e26-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 08:02:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586851327;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=l5g8loIidFzbiBQ70AnP8vDOO60Pey9SqyRaP/IVSOI=;
 b=IQuzjCWkn1e1n0HdVkU4/y8UAujgfyV0HcBr5BwiCwg4M8bOIQhe7XDS
 Ep1m2UUfMJmo5Xip4tg5w3mmq6kE5/3XghDfl4Eh0kSDHNUfEXvKE25i4
 GTHSMt1hjMw3uLXuoGcG30kUMCeRHRVT93sxHCs2S0cQyYQwB8c0OoXCW 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: wlKJPaEW0Fww8VnTFA14ERq+EzmvyMsrwweCRquRIicpqZYI+7aI6hVkOUk4KIlvaFfIABYjO8
 xvOb+QzexkgPFEjLXNFnGpf+v78tz5LBb5+JJNybzTCkMfUuL/LemRc/IYbYIJ5D7iJsKM8Oy7
 NTzFdhWxr/0qYGzMZ/0Jkp58ui5TlBL2xZE500T+G5LuvDeF58ZiZp8LhsaIHLsu1TxupZNFa7
 6ILrTaPSP1Hb/jNp/MNDajUv8BuQnkdxZmze81kRIv+1/Ypo2kb+UdNH1y8CnCiO48c45QIXJ3
 71k=
X-SBRS: 2.7
X-MesageID: 15610179
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,381,1580792400"; d="scan'208";a="15610179"
Date: Tue, 14 Apr 2020 10:01:58 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200414080158.GD28601@Air-de-Roger>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <9c7ec98b-bd2d-4fbf-530a-2164dbbee200@suse.com>
 <20200408151055.GB28601@Air-de-Roger>
 <00c10f30-5502-2b43-b394-efa8137cf264@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <00c10f30-5502-2b43-b394-efa8137cf264@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 09, 2020 at 01:16:57PM +0200, Jan Beulich wrote:
> On 08.04.2020 17:10, Roger Pau Monné wrote:
> > On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
> >> On 06.04.2020 12:57, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/mm/paging.c
> >>> +++ b/xen/arch/x86/mm/paging.c
> >>> @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d,
> >>>  
> >>>      p2m_unlock(p2m);
> >>>  
> >>> -    flush_tlb_mask(d->dirty_cpumask);
> >>> +    flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) |
> >>> +                                 FLUSH_HVM_ASID_CORE);
> >>
> >> In cases where one case is assumed to be more likely than the other
> >> putting the more likely one first can be viewed as a mild hint to
> >> the compiler, and hence an extra ! may be warranted in an if() or
> >> a conditional expression. Here, however, I don't think we can
> >> really consider one case more likely than the other, and hence I'd
> >> suggest to avoid the !, flipping the other two expressions
> >> accordingly. I may take the liberty to adjust this while committing
> >> (if I'm to be the one).
> > 
> > That's fine, thanks. Somehow '!hap -> flush' was clearer in my mind.
> 
> Thinking about it with the other HVM-related changes in v9, shouldn't
> this then be
> 
>     flush_mask(d->dirty_cpumask, (hap_enabled(d) ? 0 : FLUSH_TLB) |
>                                  (is_hvm_domain(d) ? FLUSH_HVM_ASID_CORE : 0));
> 
> Or wait - the only caller lives in hap.c. As a result the FLUSH_TLB
> part can be dropped altogether. And I question the need of flushing
> guest TLBs - this is purely a p2m operation. I'll go look at the
> history of this function, but for now I think the call should be
> dropped (albeit then maybe better in a separate patch).

The ASID flush needs to stay unless it's moved into p2m_pt_set_entry,
as p2m_pt_set_entry itself doesn't perform any ASID flush and won't
work correctly.

I think it's safe to remove the TLB flush, as the code is only called
from HAP, and hence is not used by shadow (which is what would require
a plain TLB flush). The placement of this function seems misleading to
me, as it looks like it's used by both shadow and HAP. It might be
better to move it to hap.c if it's only to be used by HAP code.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 08:10:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 08:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOGeA-0001sp-99; Tue, 14 Apr 2020 08:10:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=18iO=56=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOGe9-0001sk-KC
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 08:10:17 +0000
X-Inumbo-ID: 5fb1ea7c-7e27-11ea-88fe-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5fb1ea7c-7e27-11ea-88fe-12813bfff9fa;
 Tue, 14 Apr 2020 08:10:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586851816;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=Dmkv7ANemtWkRfszIgcvzoiAzRjJkLWxduuhPLm4LpY=;
 b=hOMbzYUPqS+dYnCA1sy/eZCnR5qLQZGrloU/BCGmc60B+gsN57NVA3j2
 TIAj4oAp+5+opwHIEpcGOr9A7jT7UDTJqZtwWbl+1KaAKGJOaQVVtSbDQ
 3uCcVvrmTME2Dd295qINhSA/8IbHL/gAFbPWdjCITUcRfIFgvj3bixzLO E=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Xm+bSiccrd9b5XFiUoZiFx1I5UUy0o50k8INvA9nC0nSfwmWfcm4yAsq+KfRadmck/wi9850Lr
 Jp4pRh1AP0RDusPK/QPXfRVuppvqXdwi5+q8HKL9tgNjTYaeeXKqEUVNuEPzqQH8ZbZZ5YlLlz
 m3g47ShJ94nTv//35u00Ao6NhXnsKHzjZ6Byf5utVeZAtqyWaATy2pgo6UAQQPQXT9l0W5W+Uc
 qJtUtBgkZy9ZxhGbU84t+yTDTBSt/8+4TUwt39Edp0JVeWigZZkJn1aBAnR9UyiduCKM15IP0D
 vhg=
X-SBRS: 2.7
X-MesageID: 16297269
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="16297269"
Date: Tue, 14 Apr 2020 10:10:09 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Harsha Shamsundara Havanur <havanur@amazon.com>
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
Message-ID: <20200414081009.GE28601@Air-de-Roger>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>, Andrew
 Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 13, 2020 at 09:33:42PM +0000, Harsha Shamsundara Havanur wrote:
> It was observed that PCI MMIO and/or IO BARs were programmed with
> BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> register) enabled, during PCI setup phase. This resulted in
> incorrect memory mapping as soon as the lower half of the 64 bit bar
> is programmed, which displaced any RAM mappings under 4G. After the
> upper half is programmed PCI memory mapping is restored to its
> intended mapping but the RAM displaced is not restored. The OS then
> continues to boot and function until it tries to access the displaced
> RAM at which point it suffers a page fault and crashes.
> 
> This patch address the issue by deferring enablement of memory and
> I/O decode in command register until all the resources, like interrupts
> I/O and/or MMIO BARs for all the PCI device functions are programmed.
> 
> Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
> Reviewed-by: Paul Durrant <pdurrant@amazon.com>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
>  tools/firmware/hvmloader/pci.c | 35 +++++++++++++++++++++++++++--------
>  1 file changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index 0b708bf578..f74471b255 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -84,6 +84,7 @@ void pci_setup(void)
>      uint32_t vga_devfn = 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    uint8_t pci_devfn_decode_type[256] = {};
>  
>      /* Resources assignable to PCI devices via BARs. */
>      struct resource {
> @@ -120,6 +121,9 @@ void pci_setup(void)
>       */
>      bool allow_memory_relocate = 1;
>  
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY != PCI_COMMAND_MEMORY);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_IO);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_MASTER);
>      s = xenstore_read(HVM_XS_ALLOW_MEMORY_RELOCATE, NULL);
>      if ( s )
>          allow_memory_relocate = strtoll(s, NULL, 0);
> @@ -289,9 +293,22 @@ void pci_setup(void)
>                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
>          }
>  
> -        /* Enable bus mastering. */
> +        /*
> +         * Disable bus mastering, memory and I/O space, which is typical device
> +         * reset state. It is recommended that BAR programming be done whilst
> +         * decode bits are cleared to avoid incorrect mappings being created,
> +         * when 64-bit memory BAR is programmed first by writing the lower half
> +         * and then the upper half, which first maps to an address under 4G
> +         * replacing any RAM mapped in that address, which is not restored
> +         * back after the upper half is written and PCI memory is correctly
> +         * mapped to its intended high mem address.
> +         *
> +         * Capture the state of bus master to restore it back once BAR
> +         * programming is completed.
> +         */
>          cmd = pci_readw(devfn, PCI_COMMAND);
> -        cmd |= PCI_COMMAND_MASTER;
> +        pci_devfn_decode_type[devfn] = cmd & ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
> +        cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
>          pci_writew(devfn, PCI_COMMAND, cmd);
>      }
>  
> @@ -503,10 +520,9 @@ void pci_setup(void)
>          if ( (bar_reg == PCI_ROM_ADDRESS) ||
>               ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
>                PCI_BASE_ADDRESS_SPACE_MEMORY) )
> -            cmd |= PCI_COMMAND_MEMORY;
> +            pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
>          else
> -            cmd |= PCI_COMMAND_IO;
> -        pci_writew(devfn, PCI_COMMAND, cmd);
> +            pci_devfn_decode_type[devfn] |= PCI_COMMAND_IO;
>      }
>  
>      if ( pci_hi_mem_start )
> @@ -526,10 +542,13 @@ void pci_setup(void)
>           * has IO enabled, even if there is no I/O BAR on that
>           * particular device.
>           */
> -        cmd = pci_readw(vga_devfn, PCI_COMMAND);
> -        cmd |= PCI_COMMAND_IO;
> -        pci_writew(vga_devfn, PCI_COMMAND, cmd);
> +        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
>      }
> +
> +    /* Enable memory and I/O space. Restore saved BUS MASTER state */
> +    for ( devfn = 0; devfn < 256; devfn++ )
> +        if ( pci_devfn_decode_type[devfn] )
> +            pci_writew(devfn, PCI_COMMAND, pci_devfn_decode_type[devfn]);

Why don't you enable the decoding after done with programming all the
BARs on the device in the loop above? Is there any reason to defer
this until all devices have been programmed?

If so, I think you would also need to introduce a pre-loop that
disables all of this for all devices before programming the BARs, or
else you are still programming BARs while some devices might have the
bus mastering or decoding bits enabled.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 08:20:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 08:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOGo5-0002ly-FU; Tue, 14 Apr 2020 08:20:33 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=18iO=56=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOGo4-0002ls-7Q
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 08:20:32 +0000
X-Inumbo-ID: ce115998-7e28-11ea-8900-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ce115998-7e28-11ea-8900-12813bfff9fa;
 Tue, 14 Apr 2020 08:20:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586852431;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=qK2JTElt5GA8MpcUjRoDtZIdfr5xjLSwBZneS5Mz884=;
 b=HIIj7IypKRbIqChfDJPy/VKO4LVSQYglXT5FmiXqwQai3KovTlgGYhiv
 5eRUVTEj8fZuGsj0x1MvUk3zwTnVs84EPft7HQ8yIzL5PAbfKQ3TxYKVT
 SqDQg1V7YYO3j6l/8bsWQZ18Mqg6haWU40uDbidTsRdXFs7A25+3isP6o 0=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: VA64RbwiB79FIAsIVtDzdYzqRvvCgaL1sZDl1cWlBXKWtqwI3ObSHAdZDKBKArJ1qpm2W81J7V
 2tKZsQW83vu6dD+NK32l0QxmCemDm6eS75E5q/zYEz6D5IvToS6ZaRFo8le1xXgVmyWws1/XDE
 WlSrLHzPzDm95aabudQmUJOQYDQ4M1wHHlXFGEY3CPE1BDV/+GNYMroLQRVfgBPpPQy3YHjAHA
 vE+2PliyCaFcQ3SIWgVs6muMAzh88fz6mg9UiIpKQkvALPKFM0k9OkhIhyklrp/aQc4fXwhCuD
 Us0=
X-SBRS: 2.7
X-MesageID: 16297891
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="16297891"
Date: Tue, 14 Apr 2020 10:20:08 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Harsha Shamsundara Havanur <havanur@amazon.com>
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
Message-ID: <20200414081931.GF28601@Air-de-Roger>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <20200414081009.GE28601@Air-de-Roger>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200414081009.GE28601@Air-de-Roger>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Ian Jackson <ian.jackson@eu.citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 14, 2020 at 10:10:09AM +0200, Roger Pau Monné wrote:
> On Mon, Apr 13, 2020 at 09:33:42PM +0000, Harsha Shamsundara Havanur wrote:
> > It was observed that PCI MMIO and/or IO BARs were programmed with
> > BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> > register) enabled, during PCI setup phase. This resulted in
> > incorrect memory mapping as soon as the lower half of the 64 bit bar
> > is programmed, which displaced any RAM mappings under 4G. After the
> > upper half is programmed PCI memory mapping is restored to its
> > intended mapping but the RAM displaced is not restored. The OS then
> > continues to boot and function until it tries to access the displaced
> > RAM at which point it suffers a page fault and crashes.
> > 
> > This patch address the issue by deferring enablement of memory and
> > I/O decode in command register until all the resources, like interrupts
> > I/O and/or MMIO BARs for all the PCI device functions are programmed.
> > 
> > Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
> > Reviewed-by: Paul Durrant <pdurrant@amazon.com>
> > Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > ---
> >  tools/firmware/hvmloader/pci.c | 35 +++++++++++++++++++++++++++--------
> >  1 file changed, 27 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> > index 0b708bf578..f74471b255 100644
> > --- a/tools/firmware/hvmloader/pci.c
> > +++ b/tools/firmware/hvmloader/pci.c
> > @@ -84,6 +84,7 @@ void pci_setup(void)
> >      uint32_t vga_devfn = 256;
> >      uint16_t class, vendor_id, device_id;
> >      unsigned int bar, pin, link, isa_irq;
> > +    uint8_t pci_devfn_decode_type[256] = {};
> >  
> >      /* Resources assignable to PCI devices via BARs. */
> >      struct resource {
> > @@ -120,6 +121,9 @@ void pci_setup(void)
> >       */
> >      bool allow_memory_relocate = 1;
> >  
> > +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY != PCI_COMMAND_MEMORY);
> > +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_IO);
> > +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_MASTER);
> >      s = xenstore_read(HVM_XS_ALLOW_MEMORY_RELOCATE, NULL);
> >      if ( s )
> >          allow_memory_relocate = strtoll(s, NULL, 0);
> > @@ -289,9 +293,22 @@ void pci_setup(void)
> >                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
> >          }
> >  
> > -        /* Enable bus mastering. */
> > +        /*
> > +         * Disable bus mastering, memory and I/O space, which is typical device
> > +         * reset state. It is recommended that BAR programming be done whilst
> > +         * decode bits are cleared to avoid incorrect mappings being created,
> > +         * when 64-bit memory BAR is programmed first by writing the lower half
> > +         * and then the upper half, which first maps to an address under 4G
> > +         * replacing any RAM mapped in that address, which is not restored
> > +         * back after the upper half is written and PCI memory is correctly
> > +         * mapped to its intended high mem address.
> > +         *
> > +         * Capture the state of bus master to restore it back once BAR
> > +         * programming is completed.
> > +         */
> >          cmd = pci_readw(devfn, PCI_COMMAND);
> > -        cmd |= PCI_COMMAND_MASTER;
> > +        pci_devfn_decode_type[devfn] = cmd & ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
> > +        cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
> >          pci_writew(devfn, PCI_COMMAND, cmd);
> >      }
> >  
> > @@ -503,10 +520,9 @@ void pci_setup(void)
> >          if ( (bar_reg == PCI_ROM_ADDRESS) ||
> >               ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >                PCI_BASE_ADDRESS_SPACE_MEMORY) )
> > -            cmd |= PCI_COMMAND_MEMORY;
> > +            pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
> >          else
> > -            cmd |= PCI_COMMAND_IO;
> > -        pci_writew(devfn, PCI_COMMAND, cmd);
> > +            pci_devfn_decode_type[devfn] |= PCI_COMMAND_IO;
> >      }
> >  
> >      if ( pci_hi_mem_start )
> > @@ -526,10 +542,13 @@ void pci_setup(void)
> >           * has IO enabled, even if there is no I/O BAR on that
> >           * particular device.
> >           */
> > -        cmd = pci_readw(vga_devfn, PCI_COMMAND);
> > -        cmd |= PCI_COMMAND_IO;
> > -        pci_writew(vga_devfn, PCI_COMMAND, cmd);
> > +        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
> >      }
> > +
> > +    /* Enable memory and I/O space. Restore saved BUS MASTER state */
> > +    for ( devfn = 0; devfn < 256; devfn++ )
> > +        if ( pci_devfn_decode_type[devfn] )
> > +            pci_writew(devfn, PCI_COMMAND, pci_devfn_decode_type[devfn]);
> 
> Why don't you enable the decoding after done with programming all the
> BARs on the device in the loop above? Is there any reason to defer
> this until all devices have been programmed?
> 
> If so, I think you would also need to introduce a pre-loop that
> disables all of this for all devices before programming the BARs, or
> else you are still programming BARs while some devices might have the
> bus mastering or decoding bits enabled.

Oh, forget that last paragraph, I see that decoding is indeed disabled
before programming any devices BARs. I still think that it might be
feasible to enable it once all BARs on the device have been
programmed, which would allow to get rid of the extra loop and the
pci_devfn_decode_type local variable.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 08:54:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 08:54:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHL7-0005JI-C7; Tue, 14 Apr 2020 08:54:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=kDu3=56=amazon.com=prvs=3660aa63e=havanur@srs-us1.protection.inumbo.net>)
 id 1jOHL6-0005JD-2K
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 08:54:40 +0000
X-Inumbo-ID: 932b20f2-7e2d-11ea-b58d-bc764e2007e4
Received: from smtp-fw-4101.amazon.com (unknown [72.21.198.25])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 932b20f2-7e2d-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 08:54:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586854480; x=1618390480;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:content-transfer-encoding:mime-version:subject;
 bh=dLwXRUXoc2nlXy+kZ6e2eaCeWT/3bEkEeFj6PAJCKfw=;
 b=esXV1aquxHN9iVtSJUiN4GymeeWC3y0kjUc9I8OEEOAQTXgdgFkt1ahO
 R+eyde5gUgwClQ+xB5RlXlya9b5PoS3g+IjXe/QPU2ZMvAlJdhONeB7qt
 0Rj0F9YSfvJFUhMwsPMcym6jPI77pC01bSc7A7l03vouW7t5sPGKPYNd4 Q=;
IronPort-SDR: iyhDjC3UXJ04L3mZ9lyTq1ijRt7HMG2sm/Ac+mEeFh8hDk/aW2mkDGSbtPLIWOAi8KSZq4Ov6p
 Ge5xzWj6Flyg==
X-IronPort-AV: E=Sophos;i="5.72,382,1580774400"; d="scan'208";a="25457553"
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Thread-Topic: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-1d-5dd976cd.us-east-1.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP;
 14 Apr 2020 08:54:25 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166])
 by email-inbound-relay-1d-5dd976cd.us-east-1.amazon.com (Postfix) with ESMTPS
 id C1965A1AFA; Tue, 14 Apr 2020 08:54:22 +0000 (UTC)
Received: from EX13D36EUC002.ant.amazon.com (10.43.164.99) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 08:54:22 +0000
Received: from EX13D36EUC004.ant.amazon.com (10.43.164.126) by
 EX13D36EUC002.ant.amazon.com (10.43.164.99) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 08:54:20 +0000
Received: from EX13D36EUC004.ant.amazon.com ([10.43.164.126]) by
 EX13D36EUC004.ant.amazon.com ([10.43.164.126]) with mapi id 15.00.1497.006;
 Tue, 14 Apr 2020 08:54:20 +0000
From: "Shamsundara Havanur, Harsha" <havanur@amazon.com>
To: "roger.pau@citrix.com" <roger.pau@citrix.com>
Thread-Index: AQHWEdtGZKnSIpkNZ0SB6/WfFUNDKah4RIOAgAACygCAAAmOAA==
Date: Tue, 14 Apr 2020 08:54:20 +0000
Message-ID: <f8b740d9efbd0ce582193eb35e758f3bd4035e75.camel@amazon.com>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <20200414081009.GE28601@Air-de-Roger> <20200414081931.GF28601@Air-de-Roger>
In-Reply-To: <20200414081931.GF28601@Air-de-Roger>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.166.83]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0AB10B3A8550E947B977C28D7741DB10@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 "wl@xen.org" <wl@xen.org>, "jbeulich@suse.com" <jbeulich@suse.com>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

T24gVHVlLCAyMDIwLTA0LTE0IGF0IDEwOjIwICswMjAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Og0KPiBDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBv
cmdhbml6YXRpb24uIERvDQo+IG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVu
bGVzcyB5b3UgY2FuIGNvbmZpcm0gdGhlIHNlbmRlcg0KPiBhbmQga25vdyB0aGUgY29udGVudCBp
cyBzYWZlLg0KPiANCj4gDQo+IA0KPiBPbiBUdWUsIEFwciAxNCwgMjAyMCBhdCAxMDoxMDowOUFN
ICswMjAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiA+IE9uIE1vbiwgQXByIDEzLCAyMDIw
IGF0IDA5OjMzOjQyUE0gKzAwMDAsIEhhcnNoYSBTaGFtc3VuZGFyYQ0KPiA+IEhhdmFudXIgd3Jv
dGU6DQo+ID4gPiBJdCB3YXMgb2JzZXJ2ZWQgdGhhdCBQQ0kgTU1JTyBhbmQvb3IgSU8gQkFScyB3
ZXJlIHByb2dyYW1tZWQgd2l0aA0KPiA+ID4gQlVTIG1hc3RlciwgbWVtb3J5IGFuZCBJL08gZGVj
b2RlcyAoYml0cyAwLDEgYW5kIDIgb2YgUENJIENPTU1BTkQNCj4gPiA+IHJlZ2lzdGVyKSBlbmFi
bGVkLCBkdXJpbmcgUENJIHNldHVwIHBoYXNlLiBUaGlzIHJlc3VsdGVkIGluDQo+ID4gPiBpbmNv
cnJlY3QgbWVtb3J5IG1hcHBpbmcgYXMgc29vbiBhcyB0aGUgbG93ZXIgaGFsZiBvZiB0aGUgNjQg
Yml0DQo+ID4gPiBiYXINCj4gPiA+IGlzIHByb2dyYW1tZWQsIHdoaWNoIGRpc3BsYWNlZCBhbnkg
UkFNIG1hcHBpbmdzIHVuZGVyIDRHLiBBZnRlcg0KPiA+ID4gdGhlDQo+ID4gPiB1cHBlciBoYWxm
IGlzIHByb2dyYW1tZWQgUENJIG1lbW9yeSBtYXBwaW5nIGlzIHJlc3RvcmVkIHRvIGl0cw0KPiA+
ID4gaW50ZW5kZWQgbWFwcGluZyBidXQgdGhlIFJBTSBkaXNwbGFjZWQgaXMgbm90IHJlc3RvcmVk
LiBUaGUgT1MNCj4gPiA+IHRoZW4NCj4gPiA+IGNvbnRpbnVlcyB0byBib290IGFuZCBmdW5jdGlv
biB1bnRpbCBpdCB0cmllcyB0byBhY2Nlc3MgdGhlDQo+ID4gPiBkaXNwbGFjZWQNCj4gPiA+IFJB
TSBhdCB3aGljaCBwb2ludCBpdCBzdWZmZXJzIGEgcGFnZSBmYXVsdCBhbmQgY3Jhc2hlcy4NCj4g
PiA+IA0KPiA+ID4gVGhpcyBwYXRjaCBhZGRyZXNzIHRoZSBpc3N1ZSBieSBkZWZlcnJpbmcgZW5h
YmxlbWVudCBvZiBtZW1vcnkNCj4gPiA+IGFuZA0KPiA+ID4gSS9PIGRlY29kZSBpbiBjb21tYW5k
IHJlZ2lzdGVyIHVudGlsIGFsbCB0aGUgcmVzb3VyY2VzLCBsaWtlDQo+ID4gPiBpbnRlcnJ1cHRz
DQo+ID4gPiBJL08gYW5kL29yIE1NSU8gQkFScyBmb3IgYWxsIHRoZSBQQ0kgZGV2aWNlIGZ1bmN0
aW9ucyBhcmUNCj4gPiA+IHByb2dyYW1tZWQuDQo+ID4gPiANCj4gPiA+IFNpZ25lZC1vZmYtYnk6
IEhhcnNoYSBTaGFtc3VuZGFyYSBIYXZhbnVyIDxoYXZhbnVyQGFtYXpvbi5jb20+DQo+ID4gPiBS
ZXZpZXdlZC1ieTogUGF1bCBEdXJyYW50IDxwZHVycmFudEBhbWF6b24uY29tPg0KPiA+ID4gQWNr
ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQo+ID4gPiAt
LS0NCj4gPiA+ICB0b29scy9maXJtd2FyZS9odm1sb2FkZXIvcGNpLmMgfCAzNSArKysrKysrKysr
KysrKysrKysrKysrKysrKystDQo+ID4gPiAtLS0tLS0tDQo+ID4gPiAgMSBmaWxlIGNoYW5nZWQs
IDI3IGluc2VydGlvbnMoKyksIDggZGVsZXRpb25zKC0pDQo+ID4gPiANCj4gPiA+IGRpZmYgLS1n
aXQgYS90b29scy9maXJtd2FyZS9odm1sb2FkZXIvcGNpLmMNCj4gPiA+IGIvdG9vbHMvZmlybXdh
cmUvaHZtbG9hZGVyL3BjaS5jDQo+ID4gPiBpbmRleCAwYjcwOGJmNTc4Li5mNzQ0NzFiMjU1IDEw
MDY0NA0KPiA+ID4gLS0tIGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3BjaS5jDQo+ID4gPiAr
KysgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIvcGNpLmMNCj4gPiA+IEBAIC04NCw2ICs4NCw3
IEBAIHZvaWQgcGNpX3NldHVwKHZvaWQpDQo+ID4gPiAgICAgIHVpbnQzMl90IHZnYV9kZXZmbiA9
IDI1NjsNCj4gPiA+ICAgICAgdWludDE2X3QgY2xhc3MsIHZlbmRvcl9pZCwgZGV2aWNlX2lkOw0K
PiA+ID4gICAgICB1bnNpZ25lZCBpbnQgYmFyLCBwaW4sIGxpbmssIGlzYV9pcnE7DQo+ID4gPiAr
ICAgIHVpbnQ4X3QgcGNpX2RldmZuX2RlY29kZV90eXBlWzI1Nl0gPSB7fTsNCj4gPiA+IA0KPiA+
ID4gICAgICAvKiBSZXNvdXJjZXMgYXNzaWduYWJsZSB0byBQQ0kgZGV2aWNlcyB2aWEgQkFScy4g
Ki8NCj4gPiA+ICAgICAgc3RydWN0IHJlc291cmNlIHsNCj4gPiA+IEBAIC0xMjAsNiArMTIxLDkg
QEAgdm9pZCBwY2lfc2V0dXAodm9pZCkNCj4gPiA+ICAgICAgICovDQo+ID4gPiAgICAgIGJvb2wg
YWxsb3dfbWVtb3J5X3JlbG9jYXRlID0gMTsNCj4gPiA+IA0KPiA+ID4gKyAgICBCVUlMRF9CVUdf
T04oKHR5cGVvZigqcGNpX2RldmZuX2RlY29kZV90eXBlKSlQQ0lfQ09NTUFORF9NRU0NCj4gPiA+
IE9SWSAhPSBQQ0lfQ09NTUFORF9NRU1PUlkpOw0KPiA+ID4gKyAgICBCVUlMRF9CVUdfT04oKHR5
cGVvZigqcGNpX2RldmZuX2RlY29kZV90eXBlKSlQQ0lfQ09NTUFORF9JTw0KPiA+ID4gIT0gUENJ
X0NPTU1BTkRfSU8pOw0KPiA+ID4gKyAgICBCVUlMRF9CVUdfT04oKHR5cGVvZigqcGNpX2RldmZu
X2RlY29kZV90eXBlKSlQQ0lfQ09NTUFORF9JTw0KPiA+ID4gIT0gUENJX0NPTU1BTkRfTUFTVEVS
KTsNCj4gPiA+ICAgICAgcyA9IHhlbnN0b3JlX3JlYWQoSFZNX1hTX0FMTE9XX01FTU9SWV9SRUxP
Q0FURSwgTlVMTCk7DQo+ID4gPiAgICAgIGlmICggcyApDQo+ID4gPiAgICAgICAgICBhbGxvd19t
ZW1vcnlfcmVsb2NhdGUgPSBzdHJ0b2xsKHMsIE5VTEwsIDApOw0KPiA+ID4gQEAgLTI4OSw5ICsy
OTMsMjIgQEAgdm9pZCBwY2lfc2V0dXAodm9pZCkNCj4gPiA+ICAgICAgICAgICAgICAgICAgICAg
ZGV2Zm4+PjMsIGRldmZuJjcsICdBJytwaW4tMSwgaXNhX2lycSk7DQo+ID4gPiAgICAgICAgICB9
DQo+ID4gPiANCj4gPiA+IC0gICAgICAgIC8qIEVuYWJsZSBidXMgbWFzdGVyaW5nLiAqLw0KPiA+
ID4gKyAgICAgICAgLyoNCj4gPiA+ICsgICAgICAgICAqIERpc2FibGUgYnVzIG1hc3RlcmluZywg
bWVtb3J5IGFuZCBJL08gc3BhY2UsIHdoaWNoIGlzDQo+ID4gPiB0eXBpY2FsIGRldmljZQ0KPiA+
ID4gKyAgICAgICAgICogcmVzZXQgc3RhdGUuIEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgQkFSIHBy
b2dyYW1taW5nDQo+ID4gPiBiZSBkb25lIHdoaWxzdA0KPiA+ID4gKyAgICAgICAgICogZGVjb2Rl
IGJpdHMgYXJlIGNsZWFyZWQgdG8gYXZvaWQgaW5jb3JyZWN0IG1hcHBpbmdzDQo+ID4gPiBiZWlu
ZyBjcmVhdGVkLA0KPiA+ID4gKyAgICAgICAgICogd2hlbiA2NC1iaXQgbWVtb3J5IEJBUiBpcyBw
cm9ncmFtbWVkIGZpcnN0IGJ5IHdyaXRpbmcNCj4gPiA+IHRoZSBsb3dlciBoYWxmDQo+ID4gPiAr
ICAgICAgICAgKiBhbmQgdGhlbiB0aGUgdXBwZXIgaGFsZiwgd2hpY2ggZmlyc3QgbWFwcyB0byBh
bg0KPiA+ID4gYWRkcmVzcyB1bmRlciA0Rw0KPiA+ID4gKyAgICAgICAgICogcmVwbGFjaW5nIGFu
eSBSQU0gbWFwcGVkIGluIHRoYXQgYWRkcmVzcywgd2hpY2ggaXMNCj4gPiA+IG5vdCByZXN0b3Jl
ZA0KPiA+ID4gKyAgICAgICAgICogYmFjayBhZnRlciB0aGUgdXBwZXIgaGFsZiBpcyB3cml0dGVu
IGFuZCBQQ0kgbWVtb3J5DQo+ID4gPiBpcyBjb3JyZWN0bHkNCj4gPiA+ICsgICAgICAgICAqIG1h
cHBlZCB0byBpdHMgaW50ZW5kZWQgaGlnaCBtZW0gYWRkcmVzcy4NCj4gPiA+ICsgICAgICAgICAq
DQo+ID4gPiArICAgICAgICAgKiBDYXB0dXJlIHRoZSBzdGF0ZSBvZiBidXMgbWFzdGVyIHRvIHJl
c3RvcmUgaXQgYmFjaw0KPiA+ID4gb25jZSBCQVINCj4gPiA+ICsgICAgICAgICAqIHByb2dyYW1t
aW5nIGlzIGNvbXBsZXRlZC4NCj4gPiA+ICsgICAgICAgICAqLw0KPiA+ID4gICAgICAgICAgY21k
ID0gcGNpX3JlYWR3KGRldmZuLCBQQ0lfQ09NTUFORCk7DQo+ID4gPiAtICAgICAgICBjbWQgfD0g
UENJX0NPTU1BTkRfTUFTVEVSOw0KPiA+ID4gKyAgICAgICAgcGNpX2RldmZuX2RlY29kZV90eXBl
W2RldmZuXSA9IGNtZCAmDQo+ID4gPiB+KFBDSV9DT01NQU5EX01FTU9SWSB8IFBDSV9DT01NQU5E
X0lPKTsNCj4gPiA+ICsgICAgICAgIGNtZCAmPSB+KFBDSV9DT01NQU5EX01BU1RFUiB8IFBDSV9D
T01NQU5EX01FTU9SWSB8DQo+ID4gPiBQQ0lfQ09NTUFORF9JTyk7DQo+ID4gPiAgICAgICAgICBw
Y2lfd3JpdGV3KGRldmZuLCBQQ0lfQ09NTUFORCwgY21kKTsNCj4gPiA+ICAgICAgfQ0KPiA+ID4g
DQo+ID4gPiBAQCAtNTAzLDEwICs1MjAsOSBAQCB2b2lkIHBjaV9zZXR1cCh2b2lkKQ0KPiA+ID4g
ICAgICAgICAgaWYgKCAoYmFyX3JlZyA9PSBQQ0lfUk9NX0FERFJFU1MpIHx8DQo+ID4gPiAgICAg
ICAgICAgICAgICgoYmFyX2RhdGEgJiBQQ0lfQkFTRV9BRERSRVNTX1NQQUNFKSA9PQ0KPiA+ID4g
ICAgICAgICAgICAgICAgUENJX0JBU0VfQUREUkVTU19TUEFDRV9NRU1PUlkpICkNCj4gPiA+IC0g
ICAgICAgICAgICBjbWQgfD0gUENJX0NPTU1BTkRfTUVNT1JZOw0KPiA+ID4gKyAgICAgICAgICAg
IHBjaV9kZXZmbl9kZWNvZGVfdHlwZVtkZXZmbl0gfD0gUENJX0NPTU1BTkRfTUVNT1JZOw0KPiA+
ID4gICAgICAgICAgZWxzZQ0KPiA+ID4gLSAgICAgICAgICAgIGNtZCB8PSBQQ0lfQ09NTUFORF9J
TzsNCj4gPiA+IC0gICAgICAgIHBjaV93cml0ZXcoZGV2Zm4sIFBDSV9DT01NQU5ELCBjbWQpOw0K
PiA+ID4gKyAgICAgICAgICAgIHBjaV9kZXZmbl9kZWNvZGVfdHlwZVtkZXZmbl0gfD0gUENJX0NP
TU1BTkRfSU87DQo+ID4gPiAgICAgIH0NCj4gPiA+IA0KPiA+ID4gICAgICBpZiAoIHBjaV9oaV9t
ZW1fc3RhcnQgKQ0KPiA+ID4gQEAgLTUyNiwxMCArNTQyLDEzIEBAIHZvaWQgcGNpX3NldHVwKHZv
aWQpDQo+ID4gPiAgICAgICAgICAgKiBoYXMgSU8gZW5hYmxlZCwgZXZlbiBpZiB0aGVyZSBpcyBu
byBJL08gQkFSIG9uIHRoYXQNCj4gPiA+ICAgICAgICAgICAqIHBhcnRpY3VsYXIgZGV2aWNlLg0K
PiA+ID4gICAgICAgICAgICovDQo+ID4gPiAtICAgICAgICBjbWQgPSBwY2lfcmVhZHcodmdhX2Rl
dmZuLCBQQ0lfQ09NTUFORCk7DQo+ID4gPiAtICAgICAgICBjbWQgfD0gUENJX0NPTU1BTkRfSU87
DQo+ID4gPiAtICAgICAgICBwY2lfd3JpdGV3KHZnYV9kZXZmbiwgUENJX0NPTU1BTkQsIGNtZCk7
DQo+ID4gPiArICAgICAgICBwY2lfZGV2Zm5fZGVjb2RlX3R5cGVbdmdhX2RldmZuXSB8PSBQQ0lf
Q09NTUFORF9JTzsNCj4gPiA+ICAgICAgfQ0KPiA+ID4gKw0KPiA+ID4gKyAgICAvKiBFbmFibGUg
bWVtb3J5IGFuZCBJL08gc3BhY2UuIFJlc3RvcmUgc2F2ZWQgQlVTIE1BU1RFUg0KPiA+ID4gc3Rh
dGUgKi8NCj4gPiA+ICsgICAgZm9yICggZGV2Zm4gPSAwOyBkZXZmbiA8IDI1NjsgZGV2Zm4rKyAp
DQo+ID4gPiArICAgICAgICBpZiAoIHBjaV9kZXZmbl9kZWNvZGVfdHlwZVtkZXZmbl0gKQ0KPiA+
ID4gKyAgICAgICAgICAgIHBjaV93cml0ZXcoZGV2Zm4sIFBDSV9DT01NQU5ELA0KPiA+ID4gcGNp
X2RldmZuX2RlY29kZV90eXBlW2RldmZuXSk7DQo+ID4gDQo+ID4gV2h5IGRvbid0IHlvdSBlbmFi
bGUgdGhlIGRlY29kaW5nIGFmdGVyIGRvbmUgd2l0aCBwcm9ncmFtbWluZyBhbGwNCj4gPiB0aGUN
Cj4gPiBCQVJzIG9uIHRoZSBkZXZpY2UgaW4gdGhlIGxvb3AgYWJvdmU/IElzIHRoZXJlIGFueSBy
ZWFzb24gdG8gZGVmZXINCj4gPiB0aGlzIHVudGlsIGFsbCBkZXZpY2VzIGhhdmUgYmVlbiBwcm9n
cmFtbWVkPw0KPiA+IA0KPiA+IElmIHNvLCBJIHRoaW5rIHlvdSB3b3VsZCBhbHNvIG5lZWQgdG8g
aW50cm9kdWNlIGEgcHJlLWxvb3AgdGhhdA0KPiA+IGRpc2FibGVzIGFsbCBvZiB0aGlzIGZvciBh
bGwgZGV2aWNlcyBiZWZvcmUgcHJvZ3JhbW1pbmcgdGhlIEJBUnMsDQo+ID4gb3INCj4gPiBlbHNl
IHlvdSBhcmUgc3RpbGwgcHJvZ3JhbW1pbmcgQkFScyB3aGlsZSBzb21lIGRldmljZXMgbWlnaHQg
aGF2ZQ0KPiA+IHRoZQ0KPiA+IGJ1cyBtYXN0ZXJpbmcgb3IgZGVjb2RpbmcgYml0cyBlbmFibGVk
Lg0KPiANCj4gT2gsIGZvcmdldCB0aGF0IGxhc3QgcGFyYWdyYXBoLCBJIHNlZSB0aGF0IGRlY29k
aW5nIGlzIGluZGVlZA0KPiBkaXNhYmxlZA0KPiBiZWZvcmUgcHJvZ3JhbW1pbmcgYW55IGRldmlj
ZXMgQkFScy4gSSBzdGlsbCB0aGluayB0aGF0IGl0IG1pZ2h0IGJlDQo+IGZlYXNpYmxlIHRvIGVu
YWJsZSBpdCBvbmNlIGFsbCBCQVJzIG9uIHRoZSBkZXZpY2UgaGF2ZSBiZWVuDQo+IHByb2dyYW1t
ZWQsIHdoaWNoIHdvdWxkIGFsbG93IHRvIGdldCByaWQgb2YgdGhlIGV4dHJhIGxvb3AgYW5kIHRo
ZQ0KPiBwY2lfZGV2Zm5fZGVjb2RlX3R5cGUgbG9jYWwgdmFyaWFibGUuDQoNCkJBUnMgYXJlIHBy
b2dyYW1tZWQgc29ydGVkIGJ5IHRoZWlyIG1lbW9yeSByZXF1aXJlbWVudCBhbmQgdGh1cyBzYW1l
DQpwY2kgZnVuY3Rpb24gY291bGQgYmUgcHJvZ3JhbW1lZCBtdWx0aXBsZSB0aW1lcyBpbiB0aGlz
IGxvb3ANCjQyMiAgICAgLyogQXNzaWduIGlvbWVtIGFuZCBpb3BvcnQgcmVzb3VyY2VzIGluIGRl
c2NlbmRpbmcgb3JkZXIgb2YNCnNpemUuICovDQo0MjMgICAgIGZvciAoIGkgPSAwOyBpIDwgbnJf
YmFyczsgaSsrICkNCg0KSGVuY2UgSSBhbSB3YWl0aW5nIGZvciB0aGlzIGxvb3AgdG8gYmUgY29t
cGxldGVkIHRvIGVuYWJsZSBkZWNvZGUgYml0cw0KaW4gYSBzYXBhcmF0ZSBsb29wIGxhdGVyLg0K
PiANCj4gVGhhbmtzLCBSb2dlci4NCg==


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:00:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:00:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHQl-0006BB-Fl; Tue, 14 Apr 2020 09:00:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=kDu3=56=amazon.com=prvs=3660aa63e=havanur@srs-us1.protection.inumbo.net>)
 id 1jOHQj-0006B6-RN
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:00:29 +0000
X-Inumbo-ID: 6387078e-7e2e-11ea-b58d-bc764e2007e4
Received: from smtp-fw-6002.amazon.com (unknown [52.95.49.90])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6387078e-7e2e-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 09:00:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586854830; x=1618390830;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:content-transfer-encoding:mime-version:subject;
 bh=juGS2dA845dYKqsQtbYyJr/Y8af+TDtRnPgCBZcuLYg=;
 b=pSi3yE7aBk7Hpv+NJjHeuLwNqnVglNZOZvDNqR6hrj6uU1vXUkfEltiw
 76IrGX0f2ZT0B45PyXnVB0pYJHVoZ7R8rIo7qQrC/CJMX4zpEXtMiDluY
 Xc3hRVZQCyqk+YWUZHPK9RPbl9qA102LeDWQQVz/pRy8yR7CYgttyZ050 0=;
IronPort-SDR: NZ69YP2JD23iLnUNaAYgAozhCj9TAa5RUTjlybAQh/YYH3+//7pez0QUg+qMnNYjf8NCRrjmYI
 DXx8PovwuZJQ==
X-IronPort-AV: E=Sophos;i="5.72,382,1580774400"; d="scan'208";a="25370979"
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Thread-Topic: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP;
 14 Apr 2020 09:00:18 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])
 by email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com (Postfix) with ESMTPS
 id 6FA2AA259E; Tue, 14 Apr 2020 09:00:15 +0000 (UTC)
Received: from EX13D36EUC002.ant.amazon.com (10.43.164.99) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 09:00:15 +0000
Received: from EX13D36EUC004.ant.amazon.com (10.43.164.126) by
 EX13D36EUC002.ant.amazon.com (10.43.164.99) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 09:00:13 +0000
Received: from EX13D36EUC004.ant.amazon.com ([10.43.164.126]) by
 EX13D36EUC004.ant.amazon.com ([10.43.164.126]) with mapi id 15.00.1497.006;
 Tue, 14 Apr 2020 09:00:13 +0000
From: "Shamsundara Havanur, Harsha" <havanur@amazon.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Thread-Index: AQHWEdtGZKnSIpkNZ0SB6/WfFUNDKah4PMkAgAAVt4A=
Date: Tue, 14 Apr 2020 09:00:13 +0000
Message-ID: <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
In-Reply-To: <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.165.191]
Content-Type: text/plain; charset="utf-8"
Content-ID: <73F473A1284C4846B6C6222E27467FA0@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 "wl@xen.org" <wl@xen.org>, "roger.pau@citrix.com" <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

T24gVHVlLCAyMDIwLTA0LTE0IGF0IDA5OjQyICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4g
Q0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p
emF0aW9uLiBEbw0KPiBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3Mg
eW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXINCj4gYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2Fm
ZS4NCj4gDQo+IA0KPiANCj4gT24gMTMuMDQuMjAyMCAyMzozMywgSGFyc2hhIFNoYW1zdW5kYXJh
IEhhdmFudXIgd3JvdGU6DQo+ID4gSXQgd2FzIG9ic2VydmVkIHRoYXQgUENJIE1NSU8gYW5kL29y
IElPIEJBUnMgd2VyZSBwcm9ncmFtbWVkIHdpdGgNCj4gPiBCVVMgbWFzdGVyLCBtZW1vcnkgYW5k
IEkvTyBkZWNvZGVzIChiaXRzIDAsMSBhbmQgMiBvZiBQQ0kgQ09NTUFORA0KPiA+IHJlZ2lzdGVy
KSBlbmFibGVkLCBkdXJpbmcgUENJIHNldHVwIHBoYXNlLiBUaGlzIHJlc3VsdGVkIGluDQo+ID4g
aW5jb3JyZWN0IG1lbW9yeSBtYXBwaW5nIGFzIHNvb24gYXMgdGhlIGxvd2VyIGhhbGYgb2YgdGhl
IDY0IGJpdA0KPiA+IGJhcg0KPiA+IGlzIHByb2dyYW1tZWQsIHdoaWNoIGRpc3BsYWNlZCBhbnkg
UkFNIG1hcHBpbmdzIHVuZGVyIDRHLiBBZnRlciB0aGUNCj4gPiB1cHBlciBoYWxmIGlzIHByb2dy
YW1tZWQgUENJIG1lbW9yeSBtYXBwaW5nIGlzIHJlc3RvcmVkIHRvIGl0cw0KPiA+IGludGVuZGVk
IG1hcHBpbmcgYnV0IHRoZSBSQU0gZGlzcGxhY2VkIGlzIG5vdCByZXN0b3JlZC4gVGhlIE9TIHRo
ZW4NCj4gPiBjb250aW51ZXMgdG8gYm9vdCBhbmQgZnVuY3Rpb24gdW50aWwgaXQgdHJpZXMgdG8g
YWNjZXNzIHRoZQ0KPiA+IGRpc3BsYWNlZA0KPiA+IFJBTSBhdCB3aGljaCBwb2ludCBpdCBzdWZm
ZXJzIGEgcGFnZSBmYXVsdCBhbmQgY3Jhc2hlcy4NCj4gPiANCj4gPiBUaGlzIHBhdGNoIGFkZHJl
c3MgdGhlIGlzc3VlIGJ5IGRlZmVycmluZyBlbmFibGVtZW50IG9mIG1lbW9yeSBhbmQNCj4gPiBJ
L08gZGVjb2RlIGluIGNvbW1hbmQgcmVnaXN0ZXIgdW50aWwgYWxsIHRoZSByZXNvdXJjZXMsIGxp
a2UNCj4gPiBpbnRlcnJ1cHRzDQo+ID4gSS9PIGFuZC9vciBNTUlPIEJBUnMgZm9yIGFsbCB0aGUg
UENJIGRldmljZSBmdW5jdGlvbnMgYXJlDQo+ID4gcHJvZ3JhbW1lZC4NCj4gPiANCj4gPiBTaWdu
ZWQtb2ZmLWJ5OiBIYXJzaGEgU2hhbXN1bmRhcmEgSGF2YW51ciA8aGF2YW51ckBhbWF6b24uY29t
Pg0KPiA+IFJldmlld2VkLWJ5OiBQYXVsIER1cnJhbnQgPHBkdXJyYW50QGFtYXpvbi5jb20+DQo+
ID4gQWNrZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQo+
ID4gLS0tDQo+ID4gIHRvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9wY2kuYyB8IDM1ICsrKysrKysr
KysrKysrKysrKysrKysrKysrKy0tLQ0KPiA+IC0tLS0tDQo+ID4gIDEgZmlsZSBjaGFuZ2VkLCAy
NyBpbnNlcnRpb25zKCspLCA4IGRlbGV0aW9ucygtKQ0KPiANCj4gVGhlcmUgbm90IGJlaW5nIGFu
eSBkZXNjcmlwdGlvbiBvZiB3aGF0IGhhcyBjaGFuZ2VkIGluIHYyLCBJIGFsc28NCj4gY2FuJ3Qg
ZWFzaWx5IGp1ZGdlIHdoZXRoZXIga2VlcGluZyB0aGUgdHdvIHRhZ3MgYWJvdmUgd2FzDQo+IGxl
Z2l0aW1hdGUuIEluIGFueSBldmVudCB5b3UgZG9uJ3Qgc2VlbSB0byBoYXZlIHRha2VuIGNhcmUg
b2YgYWxsDQo+IHJldmlldyBmZWVkYmFjayAod2hldGhlciBieSBtYWtpbmcgY2hhbmdlcyB0byB0
aGUgcGF0Y2ggb3IgYnkNCj4gcmVwbHlpbmcgdmVyYmFsbHkpLg0KPiANCj4gPiAtLS0gYS90b29s
cy9maXJtd2FyZS9odm1sb2FkZXIvcGNpLmMNCj4gPiArKysgYi90b29scy9maXJtd2FyZS9odm1s
b2FkZXIvcGNpLmMNCj4gPiBAQCAtODQsNiArODQsNyBAQCB2b2lkIHBjaV9zZXR1cCh2b2lkKQ0K
PiA+ICAgICAgdWludDMyX3QgdmdhX2RldmZuID0gMjU2Ow0KPiA+ICAgICAgdWludDE2X3QgY2xh
c3MsIHZlbmRvcl9pZCwgZGV2aWNlX2lkOw0KPiA+ICAgICAgdW5zaWduZWQgaW50IGJhciwgcGlu
LCBsaW5rLCBpc2FfaXJxOw0KPiA+ICsgICAgdWludDhfdCBwY2lfZGV2Zm5fZGVjb2RlX3R5cGVb
MjU2XSA9IHt9Ow0KPiA+IA0KPiA+ICAgICAgLyogUmVzb3VyY2VzIGFzc2lnbmFibGUgdG8gUENJ
IGRldmljZXMgdmlhIEJBUnMuICovDQo+ID4gICAgICBzdHJ1Y3QgcmVzb3VyY2Ugew0KPiA+IEBA
IC0xMjAsNiArMTIxLDkgQEAgdm9pZCBwY2lfc2V0dXAodm9pZCkNCj4gPiAgICAgICAqLw0KPiA+
ICAgICAgYm9vbCBhbGxvd19tZW1vcnlfcmVsb2NhdGUgPSAxOw0KPiA+IA0KPiA+ICsgICAgQlVJ
TERfQlVHX09OKCh0eXBlb2YoKnBjaV9kZXZmbl9kZWNvZGVfdHlwZSkpUENJX0NPTU1BTkRfTUVN
T1INCj4gPiBZICE9IFBDSV9DT01NQU5EX01FTU9SWSk7DQo+ID4gKyAgICBCVUlMRF9CVUdfT04o
KHR5cGVvZigqcGNpX2RldmZuX2RlY29kZV90eXBlKSlQQ0lfQ09NTUFORF9JTyAhPQ0KPiA+IFBD
SV9DT01NQU5EX0lPKTsNCj4gPiArICAgIEJVSUxEX0JVR19PTigodHlwZW9mKCpwY2lfZGV2Zm5f
ZGVjb2RlX3R5cGUpKVBDSV9DT01NQU5EX0lPICE9DQo+ID4gUENJX0NPTU1BTkRfTUFTVEVSKTsN
Cj4gDQpUaGlzIGlzIGEgbWlzdGFrZSwgSW4gZmFjdCBpdCBzaG91bGQgYmUgY29tcGFyZWQgYWdh
aW5zdCB1bml0OCBhcyBJIGFtDQpzdG9yaW5nIHdob2xlIGNvbW1hbmQgdmFsdWUgbGF0ZXIgaW4g
dGhlIGxvb3AuDQoNCj4gVGhpcyBsb29rcyBsaWtlIGEgY29weS1hbmQtcGFzdGUgbWlzdGFrZSAt
IGFyZSB5b3Ugc3VyZSB5b3UndmUNCj4gYnVpbGQtdGVzdGVkIHRoaXM/IChUaGlzIGFsb25lIGxp
a2VseSBpbnZhbGlkYXRlcyB0aGUgdGFncywgYXMNCj4gcGVyIGFib3ZlLikNCj4gDQo+ID4gQEAg
LTI4OSw5ICsyOTMsMjIgQEAgdm9pZCBwY2lfc2V0dXAodm9pZCkNCj4gPiAgICAgICAgICAgICAg
ICAgICAgIGRldmZuPj4zLCBkZXZmbiY3LCAnQScrcGluLTEsIGlzYV9pcnEpOw0KPiA+ICAgICAg
ICAgIH0NCj4gPiANCj4gPiAtICAgICAgICAvKiBFbmFibGUgYnVzIG1hc3RlcmluZy4gKi8NCj4g
PiArICAgICAgICAvKg0KPiA+ICsgICAgICAgICAqIERpc2FibGUgYnVzIG1hc3RlcmluZywgbWVt
b3J5IGFuZCBJL08gc3BhY2UsIHdoaWNoIGlzDQo+ID4gdHlwaWNhbCBkZXZpY2UNCj4gPiArICAg
ICAgICAgKiByZXNldCBzdGF0ZS4gSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBCQVIgcHJvZ3JhbW1p
bmcgYmUNCj4gPiBkb25lIHdoaWxzdA0KPiA+ICsgICAgICAgICAqIGRlY29kZSBiaXRzIGFyZSBj
bGVhcmVkIHRvIGF2b2lkIGluY29ycmVjdCBtYXBwaW5ncw0KPiA+IGJlaW5nIGNyZWF0ZWQsDQo+
ID4gKyAgICAgICAgICogd2hlbiA2NC1iaXQgbWVtb3J5IEJBUiBpcyBwcm9ncmFtbWVkIGZpcnN0
IGJ5IHdyaXRpbmcNCj4gPiB0aGUgbG93ZXIgaGFsZg0KPiA+ICsgICAgICAgICAqIGFuZCB0aGVu
IHRoZSB1cHBlciBoYWxmLCB3aGljaCBmaXJzdCBtYXBzIHRvIGFuIGFkZHJlc3MNCj4gPiB1bmRl
ciA0Rw0KPiA+ICsgICAgICAgICAqIHJlcGxhY2luZyBhbnkgUkFNIG1hcHBlZCBpbiB0aGF0IGFk
ZHJlc3MsIHdoaWNoIGlzIG5vdA0KPiA+IHJlc3RvcmVkDQo+ID4gKyAgICAgICAgICogYmFjayBh
ZnRlciB0aGUgdXBwZXIgaGFsZiBpcyB3cml0dGVuIGFuZCBQQ0kgbWVtb3J5IGlzDQo+ID4gY29y
cmVjdGx5DQo+ID4gKyAgICAgICAgICogbWFwcGVkIHRvIGl0cyBpbnRlbmRlZCBoaWdoIG1lbSBh
ZGRyZXNzLg0KPiA+ICsgICAgICAgICAqDQo+ID4gKyAgICAgICAgICogQ2FwdHVyZSB0aGUgc3Rh
dGUgb2YgYnVzIG1hc3RlciB0byByZXN0b3JlIGl0IGJhY2sgb25jZQ0KPiA+IEJBUg0KPiA+ICsg
ICAgICAgICAqIHByb2dyYW1taW5nIGlzIGNvbXBsZXRlZC4NCj4gPiArICAgICAgICAgKi8NCj4g
PiAgICAgICAgICBjbWQgPSBwY2lfcmVhZHcoZGV2Zm4sIFBDSV9DT01NQU5EKTsNCj4gPiAtICAg
ICAgICBjbWQgfD0gUENJX0NPTU1BTkRfTUFTVEVSOw0KPiA+ICsgICAgICAgIHBjaV9kZXZmbl9k
ZWNvZGVfdHlwZVtkZXZmbl0gPSBjbWQgJiB+KFBDSV9DT01NQU5EX01FTU9SWQ0KPiA+IHwgUENJ
X0NPTU1BTkRfSU8pOw0KPiA+ICsgICAgICAgIGNtZCAmPSB+KFBDSV9DT01NQU5EX01BU1RFUiB8
IFBDSV9DT01NQU5EX01FTU9SWSB8DQo+ID4gUENJX0NPTU1BTkRfSU8pOw0KPiANCj4gVGhlIGRp
c2FibGluZyBvZiBNQVNURVIgd2FzIHB1dCB1bmRlciBxdWVzdGlvbiBpbiB2MSBhbHJlYWR5Lg0K
DQpEaXNhYmxpbmcgb2YgTUFTVEVSIGlzIGRvbmUgd2hpbHN0IHByb2dyYW1taW5nIEJBUnMgYW5k
IGl0IGlzIHJlc3RvcmVkDQpiYWNrIHRvIGl0cyBwcmV2aW91cyB2YWx1ZSBpbiB0aGUgbG9vcCBh
dCB0aGUgZW5kIG9mIHBjaV9zZXR1cA0KZnVuY3Rpb24uDQoNCj4gDQo+ID4gQEAgLTUyNiwxMCAr
NTQyLDEzIEBAIHZvaWQgcGNpX3NldHVwKHZvaWQpDQo+ID4gICAgICAgICAgICogaGFzIElPIGVu
YWJsZWQsIGV2ZW4gaWYgdGhlcmUgaXMgbm8gSS9PIEJBUiBvbiB0aGF0DQo+ID4gICAgICAgICAg
ICogcGFydGljdWxhciBkZXZpY2UuDQo+ID4gICAgICAgICAgICovDQo+ID4gLSAgICAgICAgY21k
ID0gcGNpX3JlYWR3KHZnYV9kZXZmbiwgUENJX0NPTU1BTkQpOw0KPiA+IC0gICAgICAgIGNtZCB8
PSBQQ0lfQ09NTUFORF9JTzsNCj4gPiAtICAgICAgICBwY2lfd3JpdGV3KHZnYV9kZXZmbiwgUENJ
X0NPTU1BTkQsIGNtZCk7DQo+ID4gKyAgICAgICAgcGNpX2RldmZuX2RlY29kZV90eXBlW3ZnYV9k
ZXZmbl0gfD0gUENJX0NPTU1BTkRfSU87DQo+ID4gICAgICB9DQo+ID4gKw0KPiA+ICsgICAgLyog
RW5hYmxlIG1lbW9yeSBhbmQgSS9PIHNwYWNlLiBSZXN0b3JlIHNhdmVkIEJVUyBNQVNURVIgc3Rh
dGUNCj4gPiAqLw0KPiA+ICsgICAgZm9yICggZGV2Zm4gPSAwOyBkZXZmbiA8IDI1NjsgZGV2Zm4r
KyApDQo+ID4gKyAgICAgICAgaWYgKCBwY2lfZGV2Zm5fZGVjb2RlX3R5cGVbZGV2Zm5dICkNCj4g
PiArICAgICAgICAgICAgcGNpX3dyaXRldyhkZXZmbiwgUENJX0NPTU1BTkQsDQo+ID4gcGNpX2Rl
dmZuX2RlY29kZV90eXBlW2RldmZuXSk7DQo+IA0KPiBZb3UgZWZmZWN0aXZlbHkgY2xlYXIgdGhl
IHVwcGVyIDggYml0cyBoZXJlLCByYXRoZXIgdGhhbiByZXRhaW5pbmcNCj4gdGhlbS4NCj4gDQpJ
biBmYWN0IGNtZCBpcyBhIDMyIGJpdCB2YWx1ZSBhbmQgSSBhbSByZXRhaW5pbmcgb25seSBsb3dl
ciA4IGJpdHMgb2YNCml0LiBUaGlzIHdpbGwgYmUgY29ycmVjdGVkIGluIHYzLg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:01:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:01:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHRR-0006Dv-Rv; Tue, 14 Apr 2020 09:01:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOHRQ-0006Dm-25
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:01:12 +0000
X-Inumbo-ID: 7c342320-7e2e-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7c342320-7e2e-11ea-9e09-bc764e2007e4;
 Tue, 14 Apr 2020 09:01:11 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 13045AA55;
 Tue, 14 Apr 2020 09:01:09 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
Date: Tue, 14 Apr 2020 11:01:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200414075245.GC28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 09:52, Roger Pau Monné wrote:
> On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
>> On 06.04.2020 12:57, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
>>>              p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
>>>                                    p2m_ram_rw, p2m_ram_logdirty);
>>>  
>>> -            flush_tlb_mask(d->dirty_cpumask);
>>> +            hap_flush_tlb_mask(d->dirty_cpumask);
>>>  
>>>              memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
>>>          }
>>> @@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
>>>           * to be read-only, or via hardware-assisted log-dirty.
>>>           */
>>>          p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
>>> -        flush_tlb_mask(d->dirty_cpumask);
>>> +        hap_flush_tlb_mask(d->dirty_cpumask);
>>>      }
>>>      return 0;
>>>  }
>>> @@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
>>>       * be read-only, or via hardware-assisted log-dirty.
>>>       */
>>>      p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
>>> -    flush_tlb_mask(d->dirty_cpumask);
>>> +    hap_flush_tlb_mask(d->dirty_cpumask);
>>>  }
>>>  
>>>  /************************************************/
>>> @@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
>>>  
>>>      safe_write_pte(p, new);
>>>      if ( old_flags & _PAGE_PRESENT )
>>> -        flush_tlb_mask(d->dirty_cpumask);
>>> +        hap_flush_tlb_mask(d->dirty_cpumask);
>>>  
>>>      paging_unlock(d);
>>>  
>>
>> Following up on my earlier mail about paging_log_dirty_range(), I'm
>> now of the opinion that all of these flushes should go away too. I
>> can only assume that they got put where they are when HAP code was
>> cloned from the shadow one. These are only p2m operations, and hence
>> p2m level TLB flushing is all that's needed here.
> 
> IIRC without those ASID flushes NPT won't work correctly, as I think
> it relies on those flushes when updating the p2m.

Hmm, yes - at least for this last one (in patch context) I definitely
agree: NPT's TLB invalidation is quite different from EPT's (and I
was too focused on the latter when writing the earlier reply).
Therefore how about keeping hap_flush_tlb_mask() (and its uses), but
teaching it to do nothing for EPT, while doing an ASID based flush
for NPT?

There may then even be the option to have a wider purpose helper,
dealing with most (all?) of the flushes needed from underneath
x86/mm/, setting the TLB and HVM_ASID_CORE flags as appropriate. In
the EPT case the function would still be a no-op (afaict).

> We could see about moving those flushes inside the NPT functions that
> modify the p2m, AFAICT p2m_pt_set_entry which calls
> p2m->write_p2m_entry relies on the later doing the ASID flushes, as it
> doesn't perform any.

I don't think we want to go this far at this point.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:09:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:09:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHZh-0006Uf-RG; Tue, 14 Apr 2020 09:09:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOHZg-0006Ua-Qb
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:09:44 +0000
X-Inumbo-ID: ad939058-7e2f-11ea-890b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ad939058-7e2f-11ea-890b-12813bfff9fa;
 Tue, 14 Apr 2020 09:09:43 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 957E5ABEF;
 Tue, 14 Apr 2020 09:09:41 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <9c7ec98b-bd2d-4fbf-530a-2164dbbee200@suse.com>
 <20200408151055.GB28601@Air-de-Roger>
 <00c10f30-5502-2b43-b394-efa8137cf264@suse.com>
 <20200414080158.GD28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <106d7363-b341-f4a8-4771-589631c4690d@suse.com>
Date: Tue, 14 Apr 2020 11:09:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200414080158.GD28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 10:01, Roger Pau Monné wrote:
> On Thu, Apr 09, 2020 at 01:16:57PM +0200, Jan Beulich wrote:
>> On 08.04.2020 17:10, Roger Pau Monné wrote:
>>> On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
>>>> On 06.04.2020 12:57, Roger Pau Monne wrote:
>>>>> --- a/xen/arch/x86/mm/paging.c
>>>>> +++ b/xen/arch/x86/mm/paging.c
>>>>> @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d,
>>>>>  
>>>>>      p2m_unlock(p2m);
>>>>>  
>>>>> -    flush_tlb_mask(d->dirty_cpumask);
>>>>> +    flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) |
>>>>> +                                 FLUSH_HVM_ASID_CORE);
>>>>
>>>> In cases where one case is assumed to be more likely than the other
>>>> putting the more likely one first can be viewed as a mild hint to
>>>> the compiler, and hence an extra ! may be warranted in an if() or
>>>> a conditional expression. Here, however, I don't think we can
>>>> really consider one case more likely than the other, and hence I'd
>>>> suggest to avoid the !, flipping the other two expressions
>>>> accordingly. I may take the liberty to adjust this while committing
>>>> (if I'm to be the one).
>>>
>>> That's fine, thanks. Somehow '!hap -> flush' was clearer in my mind.
>>
>> Thinking about it with the other HVM-related changes in v9, shouldn't
>> this then be
>>
>>     flush_mask(d->dirty_cpumask, (hap_enabled(d) ? 0 : FLUSH_TLB) |
>>                                  (is_hvm_domain(d) ? FLUSH_HVM_ASID_CORE : 0));
>>
>> Or wait - the only caller lives in hap.c. As a result the FLUSH_TLB
>> part can be dropped altogether. And I question the need of flushing
>> guest TLBs - this is purely a p2m operation. I'll go look at the
>> history of this function, but for now I think the call should be
>> dropped (albeit then maybe better in a separate patch).
> 
> The ASID flush needs to stay unless it's moved into p2m_pt_set_entry,
> as p2m_pt_set_entry itself doesn't perform any ASID flush and won't
> work correctly.

Just like for said in the other reply sent a few minutes ago - yes
for NPT, but no for EPT.

> I think it's safe to remove the TLB flush, as the code is only called
> from HAP, and hence is not used by shadow (which is what would require
> a plain TLB flush). The placement of this function seems misleading to
> me, as it looks like it's used by both shadow and HAP. It might be
> better to move it to hap.c if it's only to be used by HAP code.

Either placement has its problems, I think. The function is meant to
be a paging layer one, but is needed by HAP only right now. I'm
pondering whether to wrap it in #ifdef CONFIG_HVM (plus perhaps a
respective ASSERT_UNREACHABLE()).

In the end, just like in the other cases, this may be a valid further
user of the more generic helper that I did suggest (resulting in no
flushing on EPT and an ASID-based one on NPT).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:14:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:14:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHdy-0007I9-FS; Tue, 14 Apr 2020 09:14:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOHdx-0007I4-Im
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:14:09 +0000
X-Inumbo-ID: 4bed208e-7e30-11ea-890b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4bed208e-7e30-11ea-890b-12813bfff9fa;
 Tue, 14 Apr 2020 09:14:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1A616AF2C;
 Tue, 14 Apr 2020 09:14:07 +0000 (UTC)
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: "Shamsundara Havanur, Harsha" <havanur@amazon.com>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
 <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
Date: Tue, 14 Apr 2020 11:14:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 "wl@xen.org" <wl@xen.org>, "roger.pau@citrix.com" <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 11:00, Shamsundara Havanur, Harsha wrote:
> On Tue, 2020-04-14 at 09:42 +0200, Jan Beulich wrote:
>> On 13.04.2020 23:33, Harsha Shamsundara Havanur wrote:
>>> @@ -289,9 +293,22 @@ void pci_setup(void)
>>>                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
>>>          }
>>>
>>> -        /* Enable bus mastering. */
>>> +        /*
>>> +         * Disable bus mastering, memory and I/O space, which is
>>> typical device
>>> +         * reset state. It is recommended that BAR programming be
>>> done whilst
>>> +         * decode bits are cleared to avoid incorrect mappings
>>> being created,
>>> +         * when 64-bit memory BAR is programmed first by writing
>>> the lower half
>>> +         * and then the upper half, which first maps to an address
>>> under 4G
>>> +         * replacing any RAM mapped in that address, which is not
>>> restored
>>> +         * back after the upper half is written and PCI memory is
>>> correctly
>>> +         * mapped to its intended high mem address.
>>> +         *
>>> +         * Capture the state of bus master to restore it back once
>>> BAR
>>> +         * programming is completed.
>>> +         */
>>>          cmd = pci_readw(devfn, PCI_COMMAND);
>>> -        cmd |= PCI_COMMAND_MASTER;
>>> +        pci_devfn_decode_type[devfn] = cmd & ~(PCI_COMMAND_MEMORY
>>> | PCI_COMMAND_IO);
>>> +        cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY |
>>> PCI_COMMAND_IO);
>>
>> The disabling of MASTER was put under question in v1 already.
> 
> Disabling of MASTER is done whilst programming BARs and it is restored
> back to its previous value in the loop at the end of pci_setup
> function.

Yet didn't Andrew indicate he knows of devices which get upset if
MASTER _ever_ gets cleared?

>>> @@ -526,10 +542,13 @@ void pci_setup(void)
>>>           * has IO enabled, even if there is no I/O BAR on that
>>>           * particular device.
>>>           */
>>> -        cmd = pci_readw(vga_devfn, PCI_COMMAND);
>>> -        cmd |= PCI_COMMAND_IO;
>>> -        pci_writew(vga_devfn, PCI_COMMAND, cmd);
>>> +        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
>>>      }
>>> +
>>> +    /* Enable memory and I/O space. Restore saved BUS MASTER state
>>> */
>>> +    for ( devfn = 0; devfn < 256; devfn++ )
>>> +        if ( pci_devfn_decode_type[devfn] )
>>> +            pci_writew(devfn, PCI_COMMAND,
>>> pci_devfn_decode_type[devfn]);
>>
>> You effectively clear the upper 8 bits here, rather than retaining
>> them.
>>
> In fact cmd is a 32 bit value and I am retaining only lower 8 bits of
> it. This will be corrected in v3.

PCI_COMMAND is a 16-bit field. The adjacent 16 bits in the same 32 bit
word are PCI_STATUS.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:22:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHmP-0008A8-Fm; Tue, 14 Apr 2020 09:22:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=kDu3=56=amazon.com=prvs=3660aa63e=havanur@srs-us1.protection.inumbo.net>)
 id 1jOHmN-0008A3-EF
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:22:51 +0000
X-Inumbo-ID: 82dd12e2-7e31-11ea-83d8-bc764e2007e4
Received: from smtp-fw-33001.amazon.com (unknown [207.171.190.10])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 82dd12e2-7e31-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 09:22:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586856171; x=1618392171;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:content-transfer-encoding:mime-version:subject;
 bh=H1GOZ8xZE3NUKAUCMdpLkqZslpbo9j2EfSqjeLu3rz0=;
 b=FwJBTNVcqKp+tO25aXvl423wLGmVrMlkCRzzmAaiwZV4ITAGyIt835B0
 aEeaSgfvjXh9mpSUXNceZX2d0jM+bbEPKjRjeewXICvxVUhajpRGxaQQk
 r/q9ARNP4PSCYZ5M73kRdIr+TMuIHVAXj4F8H/tPE2mtSyamSKQ5Ra3c6 I=;
IronPort-SDR: gcIXGVMqVOalY0RTCHBMQkng+3JB3GGPfaXGE1oDKKRuCiXzn2Me85Z3sBU5Qd2kDw7hT2dXpX
 MI52EWfoGNDA==
X-IronPort-AV: E=Sophos;i="5.72,382,1580774400"; d="scan'208";a="38328242"
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Thread-Topic: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP;
 14 Apr 2020 09:22:48 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com (Postfix) with ESMTPS
 id 2FCEDA225A; Tue, 14 Apr 2020 09:22:48 +0000 (UTC)
Received: from EX13D36EUC002.ant.amazon.com (10.43.164.99) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 09:22:48 +0000
Received: from EX13D36EUC004.ant.amazon.com (10.43.164.126) by
 EX13D36EUC002.ant.amazon.com (10.43.164.99) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 09:22:46 +0000
Received: from EX13D36EUC004.ant.amazon.com ([10.43.164.126]) by
 EX13D36EUC004.ant.amazon.com ([10.43.164.126]) with mapi id 15.00.1497.006;
 Tue, 14 Apr 2020 09:22:46 +0000
From: "Shamsundara Havanur, Harsha" <havanur@amazon.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Thread-Index: AQHWEdtGZKnSIpkNZ0SB6/WfFUNDKah4PMkAgAAVt4CAAAPkAIAAAmkA
Date: Tue, 14 Apr 2020 09:22:46 +0000
Message-ID: <a102ec836a00714678fb3aa46787f597c9044f29.camel@amazon.com>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
 <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
 <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
In-Reply-To: <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.166.83]
Content-Type: text/plain; charset="utf-8"
Content-ID: <67A9608AD4CF9542A76183ADE319FC0A@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 "wl@xen.org" <wl@xen.org>, "roger.pau@citrix.com" <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

T24gVHVlLCAyMDIwLTA0LTE0IGF0IDExOjE0ICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4g
Q0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p
emF0aW9uLiBEbw0KPiBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3Mg
eW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXINCj4gYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2Fm
ZS4NCj4gDQo+IA0KPiANCj4gT24gMTQuMDQuMjAyMCAxMTowMCwgU2hhbXN1bmRhcmEgSGF2YW51
ciwgSGFyc2hhIHdyb3RlOg0KPiA+IE9uIFR1ZSwgMjAyMC0wNC0xNCBhdCAwOTo0MiArMDIwMCwg
SmFuIEJldWxpY2ggd3JvdGU6DQo+ID4gPiBPbiAxMy4wNC4yMDIwIDIzOjMzLCBIYXJzaGEgU2hh
bXN1bmRhcmEgSGF2YW51ciB3cm90ZToNCj4gPiA+ID4gQEAgLTI4OSw5ICsyOTMsMjIgQEAgdm9p
ZCBwY2lfc2V0dXAodm9pZCkNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBkZXZmbj4+Mywg
ZGV2Zm4mNywgJ0EnK3Bpbi0xLCBpc2FfaXJxKTsNCj4gPiA+ID4gICAgICAgICAgfQ0KPiA+ID4g
PiANCj4gPiA+ID4gLSAgICAgICAgLyogRW5hYmxlIGJ1cyBtYXN0ZXJpbmcuICovDQo+ID4gPiA+
ICsgICAgICAgIC8qDQo+ID4gPiA+ICsgICAgICAgICAqIERpc2FibGUgYnVzIG1hc3RlcmluZywg
bWVtb3J5IGFuZCBJL08gc3BhY2UsIHdoaWNoDQo+ID4gPiA+IGlzDQo+ID4gPiA+IHR5cGljYWwg
ZGV2aWNlDQo+ID4gPiA+ICsgICAgICAgICAqIHJlc2V0IHN0YXRlLiBJdCBpcyByZWNvbW1lbmRl
ZCB0aGF0IEJBUiBwcm9ncmFtbWluZw0KPiA+ID4gPiBiZQ0KPiA+ID4gPiBkb25lIHdoaWxzdA0K
PiA+ID4gPiArICAgICAgICAgKiBkZWNvZGUgYml0cyBhcmUgY2xlYXJlZCB0byBhdm9pZCBpbmNv
cnJlY3QgbWFwcGluZ3MNCj4gPiA+ID4gYmVpbmcgY3JlYXRlZCwNCj4gPiA+ID4gKyAgICAgICAg
ICogd2hlbiA2NC1iaXQgbWVtb3J5IEJBUiBpcyBwcm9ncmFtbWVkIGZpcnN0IGJ5DQo+ID4gPiA+
IHdyaXRpbmcNCj4gPiA+ID4gdGhlIGxvd2VyIGhhbGYNCj4gPiA+ID4gKyAgICAgICAgICogYW5k
IHRoZW4gdGhlIHVwcGVyIGhhbGYsIHdoaWNoIGZpcnN0IG1hcHMgdG8gYW4NCj4gPiA+ID4gYWRk
cmVzcw0KPiA+ID4gPiB1bmRlciA0Rw0KPiA+ID4gPiArICAgICAgICAgKiByZXBsYWNpbmcgYW55
IFJBTSBtYXBwZWQgaW4gdGhhdCBhZGRyZXNzLCB3aGljaCBpcw0KPiA+ID4gPiBub3QNCj4gPiA+
ID4gcmVzdG9yZWQNCj4gPiA+ID4gKyAgICAgICAgICogYmFjayBhZnRlciB0aGUgdXBwZXIgaGFs
ZiBpcyB3cml0dGVuIGFuZCBQQ0kgbWVtb3J5DQo+ID4gPiA+IGlzDQo+ID4gPiA+IGNvcnJlY3Rs
eQ0KPiA+ID4gPiArICAgICAgICAgKiBtYXBwZWQgdG8gaXRzIGludGVuZGVkIGhpZ2ggbWVtIGFk
ZHJlc3MuDQo+ID4gPiA+ICsgICAgICAgICAqDQo+ID4gPiA+ICsgICAgICAgICAqIENhcHR1cmUg
dGhlIHN0YXRlIG9mIGJ1cyBtYXN0ZXIgdG8gcmVzdG9yZSBpdCBiYWNrDQo+ID4gPiA+IG9uY2UN
Cj4gPiA+ID4gQkFSDQo+ID4gPiA+ICsgICAgICAgICAqIHByb2dyYW1taW5nIGlzIGNvbXBsZXRl
ZC4NCj4gPiA+ID4gKyAgICAgICAgICovDQo+ID4gPiA+ICAgICAgICAgIGNtZCA9IHBjaV9yZWFk
dyhkZXZmbiwgUENJX0NPTU1BTkQpOw0KPiA+ID4gPiAtICAgICAgICBjbWQgfD0gUENJX0NPTU1B
TkRfTUFTVEVSOw0KPiA+ID4gPiArICAgICAgICBwY2lfZGV2Zm5fZGVjb2RlX3R5cGVbZGV2Zm5d
ID0gY21kICYNCj4gPiA+ID4gfihQQ0lfQ09NTUFORF9NRU1PUlkNCj4gPiA+ID4gPiBQQ0lfQ09N
TUFORF9JTyk7DQo+ID4gPiA+IA0KPiA+ID4gPiArICAgICAgICBjbWQgJj0gfihQQ0lfQ09NTUFO
RF9NQVNURVIgfCBQQ0lfQ09NTUFORF9NRU1PUlkgfA0KPiA+ID4gPiBQQ0lfQ09NTUFORF9JTyk7
DQo+ID4gPiANCj4gPiA+IFRoZSBkaXNhYmxpbmcgb2YgTUFTVEVSIHdhcyBwdXQgdW5kZXIgcXVl
c3Rpb24gaW4gdjEgYWxyZWFkeS4NCj4gPiANCj4gPiBEaXNhYmxpbmcgb2YgTUFTVEVSIGlzIGRv
bmUgd2hpbHN0IHByb2dyYW1taW5nIEJBUnMgYW5kIGl0IGlzDQo+ID4gcmVzdG9yZWQNCj4gPiBi
YWNrIHRvIGl0cyBwcmV2aW91cyB2YWx1ZSBpbiB0aGUgbG9vcCBhdCB0aGUgZW5kIG9mIHBjaV9z
ZXR1cA0KPiA+IGZ1bmN0aW9uLg0KPiANCj4gWWV0IGRpZG4ndCBBbmRyZXcgaW5kaWNhdGUgaGUg
a25vd3Mgb2YgZGV2aWNlcyB3aGljaCBnZXQgdXBzZXQgaWYNCj4gTUFTVEVSIF9ldmVyXyBnZXRz
IGNsZWFyZWQ/DQoNClByZXZpb3VzIGNvbW1pdCBlbmFibGVkIE1BU1RFUiBmb3IgYWxsIGZ1bmN0
aW9ucy4gSSBhbSBiaXQgY29uZnVzZWQNCmhlcmUgb24gdGhlIGNvbnNlbnN1cyBvbiBlbmFibGlu
Zy9kaXNhYmxpbmcvcmV0YWluaW5nIEJNRS4NClNob3VsZCB3ZSBldmVuIGNhcmUgYWJvdXQgTUFT
VEVSPw0KDQo+IA0KPiA+ID4gPiBAQCAtNTI2LDEwICs1NDIsMTMgQEAgdm9pZCBwY2lfc2V0dXAo
dm9pZCkNCj4gPiA+ID4gICAgICAgICAgICogaGFzIElPIGVuYWJsZWQsIGV2ZW4gaWYgdGhlcmUg
aXMgbm8gSS9PIEJBUiBvbiB0aGF0DQo+ID4gPiA+ICAgICAgICAgICAqIHBhcnRpY3VsYXIgZGV2
aWNlLg0KPiA+ID4gPiAgICAgICAgICAgKi8NCj4gPiA+ID4gLSAgICAgICAgY21kID0gcGNpX3Jl
YWR3KHZnYV9kZXZmbiwgUENJX0NPTU1BTkQpOw0KPiA+ID4gPiAtICAgICAgICBjbWQgfD0gUENJ
X0NPTU1BTkRfSU87DQo+ID4gPiA+IC0gICAgICAgIHBjaV93cml0ZXcodmdhX2RldmZuLCBQQ0lf
Q09NTUFORCwgY21kKTsNCj4gPiA+ID4gKyAgICAgICAgcGNpX2RldmZuX2RlY29kZV90eXBlW3Zn
YV9kZXZmbl0gfD0gUENJX0NPTU1BTkRfSU87DQo+ID4gPiA+ICAgICAgfQ0KPiA+ID4gPiArDQo+
ID4gPiA+ICsgICAgLyogRW5hYmxlIG1lbW9yeSBhbmQgSS9PIHNwYWNlLiBSZXN0b3JlIHNhdmVk
IEJVUyBNQVNURVINCj4gPiA+ID4gc3RhdGUNCj4gPiA+ID4gKi8NCj4gPiA+ID4gKyAgICBmb3Ig
KCBkZXZmbiA9IDA7IGRldmZuIDwgMjU2OyBkZXZmbisrICkNCj4gPiA+ID4gKyAgICAgICAgaWYg
KCBwY2lfZGV2Zm5fZGVjb2RlX3R5cGVbZGV2Zm5dICkNCj4gPiA+ID4gKyAgICAgICAgICAgIHBj
aV93cml0ZXcoZGV2Zm4sIFBDSV9DT01NQU5ELA0KPiA+ID4gPiBwY2lfZGV2Zm5fZGVjb2RlX3R5
cGVbZGV2Zm5dKTsNCj4gPiA+IA0KPiA+ID4gWW91IGVmZmVjdGl2ZWx5IGNsZWFyIHRoZSB1cHBl
ciA4IGJpdHMgaGVyZSwgcmF0aGVyIHRoYW4NCj4gPiA+IHJldGFpbmluZw0KPiA+ID4gdGhlbS4N
Cj4gPiA+IA0KPiA+IA0KPiA+IEluIGZhY3QgY21kIGlzIGEgMzIgYml0IHZhbHVlIGFuZCBJIGFt
IHJldGFpbmluZyBvbmx5IGxvd2VyIDggYml0cw0KPiA+IG9mDQo+ID4gaXQuIFRoaXMgd2lsbCBi
ZSBjb3JyZWN0ZWQgaW4gdjMuDQo+IA0KPiBQQ0lfQ09NTUFORCBpcyBhIDE2LWJpdCBmaWVsZC4g
VGhlIGFkamFjZW50IDE2IGJpdHMgaW4gdGhlIHNhbWUgMzINCj4gYml0DQo+IHdvcmQgYXJlIFBD
SV9TVEFUVVMuDQo+IA0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:29:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:29:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHsU-0008Lq-F2; Tue, 14 Apr 2020 09:29:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOHsT-0008Ll-AP
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:29:09 +0000
X-Inumbo-ID: 63cbfa84-7e32-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 63cbfa84-7e32-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 09:29:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4EC51AEFD;
 Tue, 14 Apr 2020 09:29:06 +0000 (UTC)
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: "Shamsundara Havanur, Harsha" <havanur@amazon.com>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
 <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
 <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
 <a102ec836a00714678fb3aa46787f597c9044f29.camel@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <cfe18a03-854d-8b91-b333-ae2cefe3e1c8@suse.com>
Date: Tue, 14 Apr 2020 11:29:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a102ec836a00714678fb3aa46787f597c9044f29.camel@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 "wl@xen.org" <wl@xen.org>, "roger.pau@citrix.com" <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 11:22, Shamsundara Havanur, Harsha wrote:
> On Tue, 2020-04-14 at 11:14 +0200, Jan Beulich wrote:
>> CAUTION: This email originated from outside of the organization. Do
>> not click links or open attachments unless you can confirm the sender
>> and know the content is safe.
>>
>>
>>
>> On 14.04.2020 11:00, Shamsundara Havanur, Harsha wrote:
>>> On Tue, 2020-04-14 at 09:42 +0200, Jan Beulich wrote:
>>>> On 13.04.2020 23:33, Harsha Shamsundara Havanur wrote:
>>>>> @@ -289,9 +293,22 @@ void pci_setup(void)
>>>>>                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
>>>>>          }
>>>>>
>>>>> -        /* Enable bus mastering. */
>>>>> +        /*
>>>>> +         * Disable bus mastering, memory and I/O space, which
>>>>> is
>>>>> typical device
>>>>> +         * reset state. It is recommended that BAR programming
>>>>> be
>>>>> done whilst
>>>>> +         * decode bits are cleared to avoid incorrect mappings
>>>>> being created,
>>>>> +         * when 64-bit memory BAR is programmed first by
>>>>> writing
>>>>> the lower half
>>>>> +         * and then the upper half, which first maps to an
>>>>> address
>>>>> under 4G
>>>>> +         * replacing any RAM mapped in that address, which is
>>>>> not
>>>>> restored
>>>>> +         * back after the upper half is written and PCI memory
>>>>> is
>>>>> correctly
>>>>> +         * mapped to its intended high mem address.
>>>>> +         *
>>>>> +         * Capture the state of bus master to restore it back
>>>>> once
>>>>> BAR
>>>>> +         * programming is completed.
>>>>> +         */
>>>>>          cmd = pci_readw(devfn, PCI_COMMAND);
>>>>> -        cmd |= PCI_COMMAND_MASTER;
>>>>> +        pci_devfn_decode_type[devfn] = cmd &
>>>>> ~(PCI_COMMAND_MEMORY
>>>>>> PCI_COMMAND_IO);
>>>>>
>>>>> +        cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY |
>>>>> PCI_COMMAND_IO);
>>>>
>>>> The disabling of MASTER was put under question in v1 already.
>>>
>>> Disabling of MASTER is done whilst programming BARs and it is
>>> restored
>>> back to its previous value in the loop at the end of pci_setup
>>> function.
>>
>> Yet didn't Andrew indicate he knows of devices which get upset if
>> MASTER _ever_ gets cleared?
> 
> Previous commit enabled MASTER for all functions. I am bit confused
> here on the consensus on enabling/disabling/retaining BME.
> Should we even care about MASTER?

With the commit introducing its universal setting, I'm afraid to
avoid regressions we can't sensibly alter the behavior unless it
can be explained clearly why the original change must have been
outright wrong.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:29:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHsb-0008MJ-SJ; Tue, 14 Apr 2020 09:29:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1gEY=56=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOHsa-0008MD-K2
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:29:16 +0000
X-Inumbo-ID: 68de0cba-7e32-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 68de0cba-7e32-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 09:29:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=BstlzNV+1YkHfdb9VV8d+U63o01aGz0GvTcEYIMnhh8=; b=fjCFSYUlz47YmoO/fD9AF24PHj
 z+gvHFmvq2K0vnmzl0ebkU26CrYIWliDTOMRrivProkXp4YT6eL2zbLED/IHLYRWkJxcFAW3KtdWc
 zL9ka2U3thWejhD8RFkyeqUoEsqktrLin5eMNoSAJkHXWvVoLO+lm5YuTQN+ct1cmMlM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOHsS-0005qt-KF; Tue, 14 Apr 2020 09:29:08 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOHsS-0002ed-DB; Tue, 14 Apr 2020 09:29:08 +0000
Subject: Re: [PATCH v7 09/12] xen: add runtime parameter access support to
 hypfs
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-10-jgross@suse.com>
 <f08bdac6-122a-9289-3241-a0460a73c686@suse.com>
 <1a68e135-2761-0ccd-11fc-45344a84757d@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <bdd65308-e549-c2b2-0de9-fb220d03f087@xen.org>
Date: Tue, 14 Apr 2020 10:29:05 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1a68e135-2761-0ccd-11fc-45344a84757d@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 03/04/2020 16:31, Jürgen Groß wrote:
> On 03.04.20 16:51, Jan Beulich wrote:
>> On 02.04.2020 17:46, Juergen Gross wrote:
>>> V7:
>>> - fine tune some parameter initializations (Jan Beulich)
>>> - call custom_runtime_set_var() after updating the value
>>> - modify alignment in Arm linker script to 4 (Jan Beulich)
>>
>> I didn't ask for this to be unilaterally 4 - I don't think this
>> would work on Arm64, seeing that there are pointers inside the
>> struct. This wants to be pointer size, i.e. 4 for Arm32 but 8
>> for Arm64.

We don't allow unaligned access on Arm32, so if your structure happen to 
have a 64-bit value in it then you will get a crash at runtime.

For safety, it should neither be POINTER_ALIGN or 4, but 8. This is 
going to make your linker more robust.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:31:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHua-0000kU-CB; Tue, 14 Apr 2020 09:31:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOHuY-0000kO-Tq
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:31:18 +0000
X-Inumbo-ID: b1442368-7e32-11ea-890f-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b1442368-7e32-11ea-890f-12813bfff9fa;
 Tue, 14 Apr 2020 09:31:18 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id EE3D0AEFD;
 Tue, 14 Apr 2020 09:31:15 +0000 (UTC)
Subject: Re: [PATCH v7 09/12] xen: add runtime parameter access support to
 hypfs
To: Julien Grall <julien@xen.org>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-10-jgross@suse.com>
 <f08bdac6-122a-9289-3241-a0460a73c686@suse.com>
 <1a68e135-2761-0ccd-11fc-45344a84757d@suse.com>
 <bdd65308-e549-c2b2-0de9-fb220d03f087@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <82cfcac7-225f-204b-e8fc-cbd04f9652e9@suse.com>
Date: Tue, 14 Apr 2020 11:31:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <bdd65308-e549-c2b2-0de9-fb220d03f087@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Kevin Tian <kevin.tian@intel.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 11:29, Julien Grall wrote:
> On 03/04/2020 16:31, Jürgen Groß wrote:
>> On 03.04.20 16:51, Jan Beulich wrote:
>>> On 02.04.2020 17:46, Juergen Gross wrote:
>>>> V7:
>>>> - fine tune some parameter initializations (Jan Beulich)
>>>> - call custom_runtime_set_var() after updating the value
>>>> - modify alignment in Arm linker script to 4 (Jan Beulich)
>>>
>>> I didn't ask for this to be unilaterally 4 - I don't think this
>>> would work on Arm64, seeing that there are pointers inside the
>>> struct. This wants to be pointer size, i.e. 4 for Arm32 but 8
>>> for Arm64.
> 
> We don't allow unaligned access on Arm32, so if your structure happen to have a 64-bit value in it then you will get a crash at runtime.
> 
> For safety, it should neither be POINTER_ALIGN or 4, but 8.
> This is going to make your linker more robust.

Would you mind explaining to me why POINTER_ALIGN would be wrong
when the most strictly aligned field in a structure is a pointer?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:34:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOHxO-0000yX-2Y; Tue, 14 Apr 2020 09:34:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=18iO=56=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOHxN-0000yS-80
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:34:13 +0000
X-Inumbo-ID: 18068f64-7e33-11ea-890f-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 18068f64-7e33-11ea-890f-12813bfff9fa;
 Tue, 14 Apr 2020 09:34:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586856850;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=jZmQCYRAwFrineAfwjbNpRXCctp2DSDWUa0w/2fPwlc=;
 b=J6ndy9LORQylvObQV2u36Absyg2PibgzvcFQpBRLhd8UnPuqqdjWmSH1
 HtcceA84Wg1Ub0nCeuQXjDelBjgsuX/VUaoe34O4bbw2NKH80oebC0k+u
 B715X5qXpKNqaiLf02dOXcuHZYE/w1fh6vQfF4S9JJDW1nodBDTEBh/7Y k=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: FdNNSDVsA14udxnQLLKkk5NdKyx//yZcLQzy+eGt6ECxK7LX1Z7Tv0qSl2enthXAnjM/buiFyW
 9Xdvd17sZnUNHRTgBwE2p2nfPJa/X7GFZWcbp41A3FQ0Wpsbo+a56L3jtZLYLwRahZ+CEKpTT9
 F38Fzxa8SKRQywzEGIG8H4Vc6c+qXkYBspHywrar1/uFCDAbz0XrUVEwzj+ODTaVMYZU50udhg
 6YCIL1/VWfhg7WKNTJodG6QJMMT5XnRgK3QjpPjSGor458NZqS4MAZtVgaaEeozuLtzz+PeHmj
 D7k=
X-SBRS: 2.7
X-MesageID: 15614112
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="15614112"
Date: Tue, 14 Apr 2020 11:34:03 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200414093403.GG28601@Air-de-Roger>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <9c7ec98b-bd2d-4fbf-530a-2164dbbee200@suse.com>
 <20200408151055.GB28601@Air-de-Roger>
 <00c10f30-5502-2b43-b394-efa8137cf264@suse.com>
 <20200414080158.GD28601@Air-de-Roger>
 <106d7363-b341-f4a8-4771-589631c4690d@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <106d7363-b341-f4a8-4771-589631c4690d@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 14, 2020 at 11:09:43AM +0200, Jan Beulich wrote:
> On 14.04.2020 10:01, Roger Pau Monné wrote:
> > On Thu, Apr 09, 2020 at 01:16:57PM +0200, Jan Beulich wrote:
> >> On 08.04.2020 17:10, Roger Pau Monné wrote:
> >>> On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
> >>>> On 06.04.2020 12:57, Roger Pau Monne wrote:
> >>>>> --- a/xen/arch/x86/mm/paging.c
> >>>>> +++ b/xen/arch/x86/mm/paging.c
> >>>>> @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d,
> >>>>>  
> >>>>>      p2m_unlock(p2m);
> >>>>>  
> >>>>> -    flush_tlb_mask(d->dirty_cpumask);
> >>>>> +    flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) |
> >>>>> +                                 FLUSH_HVM_ASID_CORE);
> >>>>
> >>>> In cases where one case is assumed to be more likely than the other
> >>>> putting the more likely one first can be viewed as a mild hint to
> >>>> the compiler, and hence an extra ! may be warranted in an if() or
> >>>> a conditional expression. Here, however, I don't think we can
> >>>> really consider one case more likely than the other, and hence I'd
> >>>> suggest to avoid the !, flipping the other two expressions
> >>>> accordingly. I may take the liberty to adjust this while committing
> >>>> (if I'm to be the one).
> >>>
> >>> That's fine, thanks. Somehow '!hap -> flush' was clearer in my mind.
> >>
> >> Thinking about it with the other HVM-related changes in v9, shouldn't
> >> this then be
> >>
> >>     flush_mask(d->dirty_cpumask, (hap_enabled(d) ? 0 : FLUSH_TLB) |
> >>                                  (is_hvm_domain(d) ? FLUSH_HVM_ASID_CORE : 0));
> >>
> >> Or wait - the only caller lives in hap.c. As a result the FLUSH_TLB
> >> part can be dropped altogether. And I question the need of flushing
> >> guest TLBs - this is purely a p2m operation. I'll go look at the
> >> history of this function, but for now I think the call should be
> >> dropped (albeit then maybe better in a separate patch).
> > 
> > The ASID flush needs to stay unless it's moved into p2m_pt_set_entry,
> > as p2m_pt_set_entry itself doesn't perform any ASID flush and won't
> > work correctly.
> 
> Just like for said in the other reply sent a few minutes ago - yes
> for NPT, but no for EPT.

It's not strictly wrong for EPT as it won't cause EPT domains to
malfunction, it's just redundant.

> > I think it's safe to remove the TLB flush, as the code is only called
> > from HAP, and hence is not used by shadow (which is what would require
> > a plain TLB flush). The placement of this function seems misleading to
> > me, as it looks like it's used by both shadow and HAP. It might be
> > better to move it to hap.c if it's only to be used by HAP code.
> 
> Either placement has its problems, I think. The function is meant to
> be a paging layer one, but is needed by HAP only right now. I'm
> pondering whether to wrap it in #ifdef CONFIG_HVM (plus perhaps a
> respective ASSERT_UNREACHABLE()).

IMO if a TLB flush is not performed here we should add an
ASSERT_UNREACHABLE if called from a shadow mode domain, or else we
risk someone trying to use it in shadow later without realizing it's
missing a TLB flush.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:45:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOI8F-0001tH-AA; Tue, 14 Apr 2020 09:45:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=DJ5r=56=redhat.com=cohuck@srs-us1.protection.inumbo.net>)
 id 1jOI8D-0001tC-Bv
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:45:25 +0000
X-Inumbo-ID: aa32c956-7e34-11ea-b4f4-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id aa32c956-7e34-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 09:45:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1586857524;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=XqQcjBaUA4/pWS6QQM0cWlmT+P/BcxGgavR3JzzWkIM=;
 b=XsfOTM4xiC3dCT+PCk8qruJvJd1sD/CqDMtu2cPxlsJDcyKiROq81gNwcaL2ccs4uqAUbY
 hPrNvm+4SscYEcrRxWDTrU3LKMNKlZKAPZcR73a6Gh/8L1zFbmJs5aRP+gTljRzFkwqJR6
 A1Jgg1SUAao+Y0KJyMs/ZxqfgdwwmE8=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-403-ZJN9VRskMtK3FqqwWJ6GCA-1; Tue, 14 Apr 2020 05:45:22 -0400
X-MC-Unique: ZJN9VRskMtK3FqqwWJ6GCA-1
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com
 [10.5.11.13])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EE6C2107ACC4;
 Tue, 14 Apr 2020 09:45:18 +0000 (UTC)
Received: from gondolin (ovpn-113-32.ams2.redhat.com [10.36.113.32])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 52EA59F9A1;
 Tue, 14 Apr 2020 09:45:00 +0000 (UTC)
Date: Tue, 14 Apr 2020 11:44:57 +0200
From: Cornelia Huck <cohuck@redhat.com>
To: Philippe =?UTF-8?B?TWF0aGlldS1EYXVkw6k=?= <f4bug@amsat.org>
Subject: Re: [PATCH-for-5.1 2/3] various: Remove unnecessary OBJECT() cast
Message-ID: <20200414114457.06e15bcb.cohuck@redhat.com>
In-Reply-To: <20200412210954.32313-3-f4bug@amsat.org>
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-3-f4bug@amsat.org>
Organization: Red Hat GmbH
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, qemu-devel@nongnu.org,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 Philippe =?UTF-8?B?TWF0aGlldS1EYXVkw6k=?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?UTF-8?B?Q8OpZHJpYw==?= Le Goater <clg@kaod.org>,
 John Snow <jsnow@redhat.com>, Richard Henderson <rth@twiddle.net>,
 "Daniel P. =?UTF-8?B?QmVycmFuZ8Op?=" <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Laurent Vivier <laurent@vivier.eu>,
 qemu-ppc@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
 Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sun, 12 Apr 2020 23:09:53 +0200
Philippe Mathieu-Daud=C3=A9 <f4bug@amsat.org> wrote:

> The OBJECT() macro is defined as:
>=20
>   #define OBJECT(obj) ((Object *)(obj))
>=20
> Remove unnecessary OBJECT() casts.
>=20
> Patch created mechanically using spatch with this script:
>=20
>   @@
>   typedef Object;
>   Object *o;
>   @@
>   -   OBJECT(o)
>   +   o
>=20
> Signed-off-by: Philippe Mathieu-Daud=C3=A9 <f4bug@amsat.org>
> ---
>  hw/core/bus.c                       | 2 +-
>  hw/ide/ahci-allwinner.c             | 2 +-
>  hw/ipmi/smbus_ipmi.c                | 2 +-
>  hw/microblaze/petalogix_ml605_mmu.c | 8 ++++----
>  hw/s390x/sclp.c                     | 2 +-
>  monitor/misc.c                      | 3 +--
>  qom/object.c                        | 4 ++--
>  7 files changed, 11 insertions(+), 12 deletions(-)
>=20

s390x part:

Acked-by: Cornelia Huck <cohuck@redhat.com>



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:45:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOI8b-0001ux-Ln; Tue, 14 Apr 2020 09:45:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1gEY=56=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOI8a-0001uj-6o
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:45:48 +0000
X-Inumbo-ID: b7731f44-7e34-11ea-8912-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b7731f44-7e34-11ea-8912-12813bfff9fa;
 Tue, 14 Apr 2020 09:45:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=+GpQdcAzlMujF1Z4T9Zl+CYmfV4GeOBcon54F174VU8=; b=HoY3WQgDc80AD86yyAZ47i35xx
 bf3RHARJIh93WZBCNrnQzTbzUhw6+de/Z5Dpb3ZRjNVPJtN+vv6ucY6C9oS+Fy6CORCTvF88vtm3B
 GPukJ8CgOBW40j+KY17XZLFE1KPKiJzrZrcK25+R3+seY8h/jSOfsSthqR/DiALYFNhg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOI8S-0006Aj-Pi; Tue, 14 Apr 2020 09:45:40 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOI8S-0005JB-Ii; Tue, 14 Apr 2020 09:45:40 +0000
Subject: Re: [PATCH v7 09/12] xen: add runtime parameter access support to
 hypfs
To: Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-10-jgross@suse.com>
 <f08bdac6-122a-9289-3241-a0460a73c686@suse.com>
 <1a68e135-2761-0ccd-11fc-45344a84757d@suse.com>
 <bdd65308-e549-c2b2-0de9-fb220d03f087@xen.org>
 <82cfcac7-225f-204b-e8fc-cbd04f9652e9@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <06e72ae4-da0b-db3b-af43-0ba8970844dc@xen.org>
Date: Tue, 14 Apr 2020 10:45:37 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <82cfcac7-225f-204b-e8fc-cbd04f9652e9@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Kevin Tian <kevin.tian@intel.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 14/04/2020 10:31, Jan Beulich wrote:
> On 14.04.2020 11:29, Julien Grall wrote:
>> On 03/04/2020 16:31, Jürgen Groß wrote:
>>> On 03.04.20 16:51, Jan Beulich wrote:
>>>> On 02.04.2020 17:46, Juergen Gross wrote:
>>>>> V7:
>>>>> - fine tune some parameter initializations (Jan Beulich)
>>>>> - call custom_runtime_set_var() after updating the value
>>>>> - modify alignment in Arm linker script to 4 (Jan Beulich)
>>>>
>>>> I didn't ask for this to be unilaterally 4 - I don't think this
>>>> would work on Arm64, seeing that there are pointers inside the
>>>> struct. This wants to be pointer size, i.e. 4 for Arm32 but 8
>>>> for Arm64.
>>
>> We don't allow unaligned access on Arm32, so if your structure happen to have a 64-bit value in it then you will get a crash at runtime.
>>
>> For safety, it should neither be POINTER_ALIGN or 4, but 8.
>> This is going to make your linker more robust.
> 
> Would you mind explaining to me why POINTER_ALIGN would be wrong
> when the most strictly aligned field in a structure is a pointer?
Both are valid with one difference though. If tomorrow someone send a 
patch to add a 64-bit in the structure, what are the chance one won't 
notice the alignment change? It is quite high.

If you align the section to 8, then you make your code more robust at 
the expense of possibly adding an extra 4-bytes in your binary.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:50:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOIDS-0002nz-It; Tue, 14 Apr 2020 09:50:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOIDR-0002nu-Ow
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:50:49 +0000
X-Inumbo-ID: 68ba6d66-7e35-11ea-8912-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 68ba6d66-7e35-11ea-8912-12813bfff9fa;
 Tue, 14 Apr 2020 09:50:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8D3E1AD9F;
 Tue, 14 Apr 2020 09:50:42 +0000 (UTC)
Subject: Re: [PATCH v7 09/12] xen: add runtime parameter access support to
 hypfs
To: Julien Grall <julien@xen.org>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-10-jgross@suse.com>
 <f08bdac6-122a-9289-3241-a0460a73c686@suse.com>
 <1a68e135-2761-0ccd-11fc-45344a84757d@suse.com>
 <bdd65308-e549-c2b2-0de9-fb220d03f087@xen.org>
 <82cfcac7-225f-204b-e8fc-cbd04f9652e9@suse.com>
 <06e72ae4-da0b-db3b-af43-0ba8970844dc@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <b393e524-85e8-dbfd-225d-fea87646c199@suse.com>
Date: Tue, 14 Apr 2020 11:50:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <06e72ae4-da0b-db3b-af43-0ba8970844dc@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Kevin Tian <kevin.tian@intel.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 11:45, Julien Grall wrote:
> 
> 
> On 14/04/2020 10:31, Jan Beulich wrote:
>> On 14.04.2020 11:29, Julien Grall wrote:
>>> On 03/04/2020 16:31, Jürgen Groß wrote:
>>>> On 03.04.20 16:51, Jan Beulich wrote:
>>>>> On 02.04.2020 17:46, Juergen Gross wrote:
>>>>>> V7:
>>>>>> - fine tune some parameter initializations (Jan Beulich)
>>>>>> - call custom_runtime_set_var() after updating the value
>>>>>> - modify alignment in Arm linker script to 4 (Jan Beulich)
>>>>>
>>>>> I didn't ask for this to be unilaterally 4 - I don't think this
>>>>> would work on Arm64, seeing that there are pointers inside the
>>>>> struct. This wants to be pointer size, i.e. 4 for Arm32 but 8
>>>>> for Arm64.
>>>
>>> We don't allow unaligned access on Arm32, so if your structure happen to have a 64-bit value in it then you will get a crash at runtime.
>>>
>>> For safety, it should neither be POINTER_ALIGN or 4, but 8.
>>> This is going to make your linker more robust.
>>
>> Would you mind explaining to me why POINTER_ALIGN would be wrong
>> when the most strictly aligned field in a structure is a pointer?
> Both are valid with one difference though. If tomorrow someone send
> a patch to add a 64-bit in the structure, what are the chance one
> won't notice the alignment change? It is quite high.

Hmm, adjustments altering structure alignment that affect linker
script correctness should imo always be accompanied by checking
what the linker scripts has for the specific structure.

> If you align the section to 8, then you make your code more robust
> at the expense of possibly adding an extra 4-bytes in your binary.

Well, you're the maintainer for Arm, so you've got to judge. I'd
view things the other way around. Yes, it's less likely for even
larger alignment requirements to get introduced, but why not be
careful about these too and, say, align everything to PAGE_SIZE?
IOW - where do you draw the line in a non-arbitrary way?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:53:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:53:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOIFa-0002vO-3k; Tue, 14 Apr 2020 09:53:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOIFY-0002vI-UH
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:53:00 +0000
X-Inumbo-ID: b95b5960-7e35-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b95b5960-7e35-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 09:53:00 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 62149AF23;
 Tue, 14 Apr 2020 09:52:58 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <9c7ec98b-bd2d-4fbf-530a-2164dbbee200@suse.com>
 <20200408151055.GB28601@Air-de-Roger>
 <00c10f30-5502-2b43-b394-efa8137cf264@suse.com>
 <20200414080158.GD28601@Air-de-Roger>
 <106d7363-b341-f4a8-4771-589631c4690d@suse.com>
 <20200414093403.GG28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <4e87caf4-019c-8a8b-7abf-9dae44b4683b@suse.com>
Date: Tue, 14 Apr 2020 11:52:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200414093403.GG28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 11:34, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 11:09:43AM +0200, Jan Beulich wrote:
>> On 14.04.2020 10:01, Roger Pau Monné wrote:
>>> On Thu, Apr 09, 2020 at 01:16:57PM +0200, Jan Beulich wrote:
>>>> On 08.04.2020 17:10, Roger Pau Monné wrote:
>>>>> On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
>>>>>> On 06.04.2020 12:57, Roger Pau Monne wrote:
>>>>>>> --- a/xen/arch/x86/mm/paging.c
>>>>>>> +++ b/xen/arch/x86/mm/paging.c
>>>>>>> @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d,
>>>>>>>  
>>>>>>>      p2m_unlock(p2m);
>>>>>>>  
>>>>>>> -    flush_tlb_mask(d->dirty_cpumask);
>>>>>>> +    flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) |
>>>>>>> +                                 FLUSH_HVM_ASID_CORE);
>>>>>>
>>>>>> In cases where one case is assumed to be more likely than the other
>>>>>> putting the more likely one first can be viewed as a mild hint to
>>>>>> the compiler, and hence an extra ! may be warranted in an if() or
>>>>>> a conditional expression. Here, however, I don't think we can
>>>>>> really consider one case more likely than the other, and hence I'd
>>>>>> suggest to avoid the !, flipping the other two expressions
>>>>>> accordingly. I may take the liberty to adjust this while committing
>>>>>> (if I'm to be the one).
>>>>>
>>>>> That's fine, thanks. Somehow '!hap -> flush' was clearer in my mind.
>>>>
>>>> Thinking about it with the other HVM-related changes in v9, shouldn't
>>>> this then be
>>>>
>>>>     flush_mask(d->dirty_cpumask, (hap_enabled(d) ? 0 : FLUSH_TLB) |
>>>>                                  (is_hvm_domain(d) ? FLUSH_HVM_ASID_CORE : 0));
>>>>
>>>> Or wait - the only caller lives in hap.c. As a result the FLUSH_TLB
>>>> part can be dropped altogether. And I question the need of flushing
>>>> guest TLBs - this is purely a p2m operation. I'll go look at the
>>>> history of this function, but for now I think the call should be
>>>> dropped (albeit then maybe better in a separate patch).
>>>
>>> The ASID flush needs to stay unless it's moved into p2m_pt_set_entry,
>>> as p2m_pt_set_entry itself doesn't perform any ASID flush and won't
>>> work correctly.
>>
>> Just like for said in the other reply sent a few minutes ago - yes
>> for NPT, but no for EPT.
> 
> It's not strictly wrong for EPT as it won't cause EPT domains to
> malfunction, it's just redundant.

Right - it's wrong just in the sense of being pointless extra
overhead.

>>> I think it's safe to remove the TLB flush, as the code is only called
>>> from HAP, and hence is not used by shadow (which is what would require
>>> a plain TLB flush). The placement of this function seems misleading to
>>> me, as it looks like it's used by both shadow and HAP. It might be
>>> better to move it to hap.c if it's only to be used by HAP code.
>>
>> Either placement has its problems, I think. The function is meant to
>> be a paging layer one, but is needed by HAP only right now. I'm
>> pondering whether to wrap it in #ifdef CONFIG_HVM (plus perhaps a
>> respective ASSERT_UNREACHABLE()).
> 
> IMO if a TLB flush is not performed here we should add an
> ASSERT_UNREACHABLE if called from a shadow mode domain, or else we
> risk someone trying to use it in shadow later without realizing it's
> missing a TLB flush.

This would be fine with me.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 09:55:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 09:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOIHg-00032o-NN; Tue, 14 Apr 2020 09:55:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOIHf-00032j-T7
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:55:11 +0000
X-Inumbo-ID: 07af4950-7e36-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 07af4950-7e36-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 09:55:11 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B8B26AC5F;
 Tue, 14 Apr 2020 09:55:09 +0000 (UTC)
Subject: Re: [PATCH v5 1/3] x86/hypervisor: pass flags to hypervisor_flush_tlb
To: Wei Liu <wl@xen.org>
References: <20200409174104.23946-1-liuwe@microsoft.com>
 <20200409174104.23946-2-liuwe@microsoft.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f02be08b-b747-44c2-411d-8d8a41f4211c@suse.com>
Date: Tue, 14 Apr 2020 11:55:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200409174104.23946-2-liuwe@microsoft.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <liuwe@microsoft.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Michael Kelley <mikelley@microsoft.com>,
 Xen Development List <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09.04.2020 19:41, Wei Liu wrote:
> Hyper-V's L0 assisted flush has fine-grained control over what gets
> flushed. We need all the flags available to make the best decisions
> possible.
> 
> No functional change because Xen's implementation doesn't care about
> what is passed to it.
> 
> Signed-off-by: Wei Liu <liuwe@microsoft.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> Reviewed-by: Paul Durrant <pdurrant@amazon.com>

Acked-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 10:02:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 10:02:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOIOd-00041f-MT; Tue, 14 Apr 2020 10:02:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=18iO=56=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOIOc-00041Q-9O
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 10:02:22 +0000
X-Inumbo-ID: 07c3ae9e-7e37-11ea-b58d-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 07c3ae9e-7e37-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 10:02:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586858541;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=G5uNYocRpsBr1j5w6I+PIhnuAsXZ72lLaoOpIIGMmhY=;
 b=MDlh+mYa7+t/wZ7yyQloaakloNW2C1GryqoJ+Iug7kj+XwOpnXS87OO0
 RjeWd3m+1cQ2SJeSOhzVnwrm5FbMyndMl/SMkUw7XWi6cAkA9jcnLsSU5
 pmmBrPk/9TP7DF/4QYRBbAZK0Gwsh70f4Z9kTjoMVod8R55LrM5bTGbNO w=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: r1BD1DtuLZf6zdyU9wx4Guc4zHRhHnW8URk32GudgnojCixHMzRBjyH0G/LAuse1rA1/GOLu8D
 KFgira0Q5OaPHwmxqrDjfo43Mb1FoUTsyXrAq3TJBI9hXNzdDRJ9TCCLUWXz3wmDNBXgrW6FGo
 d4HHUdJjy0KY0JZ4zOlwDhUHfFKez2lMYKnzvLYp4olUMmkKHXMbhKYFW80vPgPsTnQ794lSDE
 T/P+dDkmcf4u6+fYYIHfi6SLLdZbOyTTvSuCZog6tUURdOGulxFvnFk+WMhfrZO7EPxQQiG6wT
 4W8=
X-SBRS: 2.7
X-MesageID: 16032707
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="16032707"
Date: Tue, 14 Apr 2020 12:02:13 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200414100213.GH28601@Air-de-Roger>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 14, 2020 at 11:01:06AM +0200, Jan Beulich wrote:
> On 14.04.2020 09:52, Roger Pau Monné wrote:
> > On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
> >> On 06.04.2020 12:57, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/mm/hap/hap.c
> >>> +++ b/xen/arch/x86/mm/hap/hap.c
> >>> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
> >>>              p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
> >>>                                    p2m_ram_rw, p2m_ram_logdirty);
> >>>  
> >>> -            flush_tlb_mask(d->dirty_cpumask);
> >>> +            hap_flush_tlb_mask(d->dirty_cpumask);
> >>>  
> >>>              memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
> >>>          }
> >>> @@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
> >>>           * to be read-only, or via hardware-assisted log-dirty.
> >>>           */
> >>>          p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> >>> -        flush_tlb_mask(d->dirty_cpumask);
> >>> +        hap_flush_tlb_mask(d->dirty_cpumask);
> >>>      }
> >>>      return 0;
> >>>  }
> >>> @@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
> >>>       * be read-only, or via hardware-assisted log-dirty.
> >>>       */
> >>>      p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> >>> -    flush_tlb_mask(d->dirty_cpumask);
> >>> +    hap_flush_tlb_mask(d->dirty_cpumask);
> >>>  }
> >>>  
> >>>  /************************************************/
> >>> @@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
> >>>  
> >>>      safe_write_pte(p, new);
> >>>      if ( old_flags & _PAGE_PRESENT )
> >>> -        flush_tlb_mask(d->dirty_cpumask);
> >>> +        hap_flush_tlb_mask(d->dirty_cpumask);
> >>>  
> >>>      paging_unlock(d);
> >>>  
> >>
> >> Following up on my earlier mail about paging_log_dirty_range(), I'm
> >> now of the opinion that all of these flushes should go away too. I
> >> can only assume that they got put where they are when HAP code was
> >> cloned from the shadow one. These are only p2m operations, and hence
> >> p2m level TLB flushing is all that's needed here.
> > 
> > IIRC without those ASID flushes NPT won't work correctly, as I think
> > it relies on those flushes when updating the p2m.
> 
> Hmm, yes - at least for this last one (in patch context) I definitely
> agree: NPT's TLB invalidation is quite different from EPT's (and I
> was too focused on the latter when writing the earlier reply).
> Therefore how about keeping hap_flush_tlb_mask() (and its uses), but
> teaching it to do nothing for EPT, while doing an ASID based flush
> for NPT?

I could give that a try. I'm slightly worried that EPT code might rely
on some of those ASID/VPID flushes. It seems like it's trying to do
VPID flushes when needed, but issues could be masked by the ASID/VPID
flushes done by the callers.

> There may then even be the option to have a wider purpose helper,
> dealing with most (all?) of the flushes needed from underneath
> x86/mm/, setting the TLB and HVM_ASID_CORE flags as appropriate. In
> the EPT case the function would still be a no-op (afaict).

That seems nice, we would have to be careful however as reducing the
number of ASID/VPID flushes could uncover issues in the existing code.
I guess you mean something like:

static inline void guest_flush_tlb_mask(const struct domain *d,
                                        const cpumask_t *mask)
{
    flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
                                                                : 0) |
    		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
		                                      : 0));
}

I think this should work, but I would rather do it in a separate
patch. I'm also not fully convinced guest_flush_tlb_mask is the best
name, but I couldn't think of anything else more descriptive of the
purpose of the function.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 10:13:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 10:13:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOIZ1-0004uu-Ur; Tue, 14 Apr 2020 10:13:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOIZ0-0004up-KE
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 10:13:06 +0000
X-Inumbo-ID: 87df5e88-7e38-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 87df5e88-7e38-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 10:13:05 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BD16BAD9F;
 Tue, 14 Apr 2020 10:13:03 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
Date: Tue, 14 Apr 2020 12:13:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200414100213.GH28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 12:02, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 11:01:06AM +0200, Jan Beulich wrote:
>> On 14.04.2020 09:52, Roger Pau Monné wrote:
>>> On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
>>>> On 06.04.2020 12:57, Roger Pau Monne wrote:
>>>>> --- a/xen/arch/x86/mm/hap/hap.c
>>>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>>>> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
>>>>>              p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
>>>>>                                    p2m_ram_rw, p2m_ram_logdirty);
>>>>>  
>>>>> -            flush_tlb_mask(d->dirty_cpumask);
>>>>> +            hap_flush_tlb_mask(d->dirty_cpumask);
>>>>>  
>>>>>              memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
>>>>>          }
>>>>> @@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
>>>>>           * to be read-only, or via hardware-assisted log-dirty.
>>>>>           */
>>>>>          p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
>>>>> -        flush_tlb_mask(d->dirty_cpumask);
>>>>> +        hap_flush_tlb_mask(d->dirty_cpumask);
>>>>>      }
>>>>>      return 0;
>>>>>  }
>>>>> @@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
>>>>>       * be read-only, or via hardware-assisted log-dirty.
>>>>>       */
>>>>>      p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
>>>>> -    flush_tlb_mask(d->dirty_cpumask);
>>>>> +    hap_flush_tlb_mask(d->dirty_cpumask);
>>>>>  }
>>>>>  
>>>>>  /************************************************/
>>>>> @@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
>>>>>  
>>>>>      safe_write_pte(p, new);
>>>>>      if ( old_flags & _PAGE_PRESENT )
>>>>> -        flush_tlb_mask(d->dirty_cpumask);
>>>>> +        hap_flush_tlb_mask(d->dirty_cpumask);
>>>>>  
>>>>>      paging_unlock(d);
>>>>>  
>>>>
>>>> Following up on my earlier mail about paging_log_dirty_range(), I'm
>>>> now of the opinion that all of these flushes should go away too. I
>>>> can only assume that they got put where they are when HAP code was
>>>> cloned from the shadow one. These are only p2m operations, and hence
>>>> p2m level TLB flushing is all that's needed here.
>>>
>>> IIRC without those ASID flushes NPT won't work correctly, as I think
>>> it relies on those flushes when updating the p2m.
>>
>> Hmm, yes - at least for this last one (in patch context) I definitely
>> agree: NPT's TLB invalidation is quite different from EPT's (and I
>> was too focused on the latter when writing the earlier reply).
>> Therefore how about keeping hap_flush_tlb_mask() (and its uses), but
>> teaching it to do nothing for EPT, while doing an ASID based flush
>> for NPT?
> 
> I could give that a try. I'm slightly worried that EPT code might rely
> on some of those ASID/VPID flushes. It seems like it's trying to do
> VPID flushes when needed, but issues could be masked by the ASID/VPID
> flushes done by the callers.

I can't seem to find any EPT code doing VPID flushes, and I'd also
not expect to. There's VMX code doing so, yes. EPT should be fully
agnostic to guest virtual address space.

>> There may then even be the option to have a wider purpose helper,
>> dealing with most (all?) of the flushes needed from underneath
>> x86/mm/, setting the TLB and HVM_ASID_CORE flags as appropriate. In
>> the EPT case the function would still be a no-op (afaict).
> 
> That seems nice, we would have to be careful however as reducing the
> number of ASID/VPID flushes could uncover issues in the existing code.
> I guess you mean something like:
> 
> static inline void guest_flush_tlb_mask(const struct domain *d,
>                                         const cpumask_t *mask)
> {
>     flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
>                                                                 : 0) |
>     		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> 		                                      : 0));
> }

Almost - is_hvm_domain(d) && cpu_has_svm seems to wide for me. I'd
rather use hap_enabled() && cpu_has_svm, which effectively means NPT.
Or am I overlooking a need to do ASID flushes also in shadow mode?

Also I'd suggest to calculate the flags up front, to avoid calling
flush_mask() in the first place in case (EPT) neither bit is set.

> I think this should work, but I would rather do it in a separate
> patch.

Yes, just like the originally (wrongly, as you validly say) suggested
full removal of them, putting this in a separate patch would indeed
seem better.

> I'm also not fully convinced guest_flush_tlb_mask is the best
> name, but I couldn't think of anything else more descriptive of the
> purpose of the function.

That's the name I was thinking of, too, despite also not being
entirely happy with it.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 10:38:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 10:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOIxb-0006jH-Ss; Tue, 14 Apr 2020 10:38:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=1gEY=56=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOIxa-0006jC-KG
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 10:38:30 +0000
X-Inumbo-ID: 14b175dc-7e3c-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 14b175dc-7e3c-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 10:38:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=cfI1M21/GnjXK7e4TZAloK4ojaKa+Or9W0AEaI7jEHY=; b=oeBmwK26o9ooEM69CP0N8baGM9
 oO49pd7iXvVZsOPIUGdL6MqJsaGLcw4cGXNcu0VXaT/q1WYqTE17f5n2xz8XzhIMnDEHsdjDYn4UX
 Wg6IsbqUYxoQc4WIiHQv/BYJrbYJyHmYYZty3phyPyZPQ1kGQyh1X+Y1jVP/FnTzF51o=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOIxU-0007H2-F3; Tue, 14 Apr 2020 10:38:24 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOIxU-00024h-7q; Tue, 14 Apr 2020 10:38:24 +0000
Subject: Re: [PATCH v7 09/12] xen: add runtime parameter access support to
 hypfs
To: Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-10-jgross@suse.com>
 <f08bdac6-122a-9289-3241-a0460a73c686@suse.com>
 <1a68e135-2761-0ccd-11fc-45344a84757d@suse.com>
 <bdd65308-e549-c2b2-0de9-fb220d03f087@xen.org>
 <82cfcac7-225f-204b-e8fc-cbd04f9652e9@suse.com>
 <06e72ae4-da0b-db3b-af43-0ba8970844dc@xen.org>
 <b393e524-85e8-dbfd-225d-fea87646c199@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <5ee4101f-aea0-4ead-d1eb-c20bffccd467@xen.org>
Date: Tue, 14 Apr 2020 11:38:21 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <b393e524-85e8-dbfd-225d-fea87646c199@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Kevin Tian <kevin.tian@intel.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 14/04/2020 10:50, Jan Beulich wrote:
> On 14.04.2020 11:45, Julien Grall wrote:
>>
>>
>> On 14/04/2020 10:31, Jan Beulich wrote:
>>> On 14.04.2020 11:29, Julien Grall wrote:
>>>> On 03/04/2020 16:31, Jürgen Groß wrote:
>>>>> On 03.04.20 16:51, Jan Beulich wrote:
>>>>>> On 02.04.2020 17:46, Juergen Gross wrote:
>>>>>>> V7:
>>>>>>> - fine tune some parameter initializations (Jan Beulich)
>>>>>>> - call custom_runtime_set_var() after updating the value
>>>>>>> - modify alignment in Arm linker script to 4 (Jan Beulich)
>>>>>>
>>>>>> I didn't ask for this to be unilaterally 4 - I don't think this
>>>>>> would work on Arm64, seeing that there are pointers inside the
>>>>>> struct. This wants to be pointer size, i.e. 4 for Arm32 but 8
>>>>>> for Arm64.
>>>>
>>>> We don't allow unaligned access on Arm32, so if your structure happen to have a 64-bit value in it then you will get a crash at runtime.
>>>>
>>>> For safety, it should neither be POINTER_ALIGN or 4, but 8.
>>>> This is going to make your linker more robust.
>>>
>>> Would you mind explaining to me why POINTER_ALIGN would be wrong
>>> when the most strictly aligned field in a structure is a pointer?
>> Both are valid with one difference though. If tomorrow someone send
>> a patch to add a 64-bit in the structure, what are the chance one
>> won't notice the alignment change? It is quite high.
> 
> Hmm, adjustments altering structure alignment that affect linker
> script correctness should imo always be accompanied by checking
> what the linker scripts has for the specific structure.

I agree with this, however this is theory. In practice, a contributor 
may not have noticed it and the reviewer may have overlooked it. So I 
prefer to make my life easier if the trade off is limited.

> 
>> If you align the section to 8, then you make your code more robust
>> at the expense of possibly adding an extra 4-bytes in your binary.
> 
> Well, you're the maintainer for Arm, so you've got to judge. I'd
> view things the other way around.
For me, review and maintenance are burden that needs to be decreased and 
not increased.

> Yes, it's less likely for even
> larger alignment requirements to get introduced, but why not be
> careful about these too and, say, align everything to PAGE_SIZE?
> IOW - where do you draw the line in a non-arbitrary way?

Most of decisions are arbitrary, some are more than other (e.g style).

We are down to the cost of alignment vs cost of maintenance/review 
longer term.

ldr/str on arm32 will request the address to be aligned to the size 
accessed. This will at most be 8. So by switching to 8, you remove most 
of the common unalignment fault.

You could use an higher alignment (such as PAGE_SIZE), but such 
structures are pretty limited and mostly used by the hardware. So the 
chance is the alignment will be correct from scratch.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:01:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJJs-0000j2-2x; Tue, 14 Apr 2020 11:01:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=akv/=56=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jOJJq-0000ix-3B
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:01:30 +0000
X-Inumbo-ID: 4aa0134e-7e3f-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4aa0134e-7e3f-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 11:01:29 +0000 (UTC)
Received: by mail-ed1-x544.google.com with SMTP id w4so14798921edv.13
 for <xen-devel@lists.xenproject.org>; Tue, 14 Apr 2020 04:01:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=IYQt+wstownzl3M07D6wi0vNLLoZDIkGEmMlQWfbV3Q=;
 b=ALHLJvOrB8wRB83tQVQXAO4LBlFFom5lsqC+l21Rib3Cqbe4lMSR6vhTLNz7H5psnO
 jxP0UEK4El3SCNLPnpaJiHlkRipDxJXBr+/tVTetxM87550de98bI4TwICGJFV6pwgu4
 fPfQrnUI7gfKPZ7xSEHeJ0ypwZ9yEqwhUIIqVkyHD9lBxS2hKZoifKrcFLVF8NtaTFyU
 QdLMFTqHM/VYm33q1TvbE1AgIVmTOiqbQWFz1ppZ/7ZXPUlU7mJVOzZvNLagVXN3ShXF
 dnyxKM18KFmHdSANvyNvW9zBoc0vAqlOoHx/hP985juBGFVlIGvVvElfMUPdfXuUY46Q
 S9Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=IYQt+wstownzl3M07D6wi0vNLLoZDIkGEmMlQWfbV3Q=;
 b=YGzeMGgmE9iOBPJS8YPng5/Cfb79WvLGD6Gbk80p81WL2L3KExvoH5E+odQhhUg+Zy
 Q+OrQqQM0h7i4V8WaD9IDH9KX6dGeetwlNTz2qBp6oJhHlG4xpalW/JuV+RPRX63oAAO
 CuHuDAUmstAj9PqqAJc5HNASY/tcr7j3NS7/ewoCi3lcTAwP+QZjiBRZxUPUOvVseoGz
 Z2k741zwrzTAOA8JmG9utSA0128R+oyOItf0j1D5MO5zpAv2OM2QTMiW11nQUuEX0KLK
 i52DyjLm4pojIediBvaKRAb9a1fQB04/my1w17fAqlOc+fJI6ydqneqCE87fm2uWh6NN
 JtoQ==
X-Gm-Message-State: AGi0Pua347UktrxHdU1JxwebfVfjfIFGwTnUl57QrhscXABzd95uF4i5
 Q9WIBcbI2M3Z2nkic4D1ITg=
X-Google-Smtp-Source: APiQypIvCfP5WgKgoR+zjmovT3bA56T09FvjRLUDZ5InOkRypd/R7AFLmOmykkeKIcg4Mr2UtUVIqA==
X-Received: by 2002:a50:fe05:: with SMTP id f5mr17323030edt.338.1586862088465; 
 Tue, 14 Apr 2020 04:01:28 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id y10sm1999903ejm.3.2020.04.14.04.01.25
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 14 Apr 2020 04:01:26 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>,
 "'Shamsundara Havanur, Harsha'" <havanur@amazon.com>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
 <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
 <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
 <a102ec836a00714678fb3aa46787f597c9044f29.camel@amazon.com>
 <cfe18a03-854d-8b91-b333-ae2cefe3e1c8@suse.com>
In-Reply-To: <cfe18a03-854d-8b91-b333-ae2cefe3e1c8@suse.com>
Subject: RE: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Tue, 14 Apr 2020 12:01:24 +0100
Message-ID: <000001d6124c$0aced570$206c8050$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQFuCy2uGI4jNh4hl1w2kkxxIVrUTADKkfs7Amx1u9ABXrUQQAMwPUabAgJH1CWo+j890A==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com,
 ian.jackson@eu.citrix.com, wl@xen.org, andrew.cooper3@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> >
> > Previous commit enabled MASTER for all functions. I am bit confused
> > here on the consensus on enabling/disabling/retaining BME.
> > Should we even care about MASTER?
>=20
> With the commit introducing its universal setting, I'm afraid to
> avoid regressions we can't sensibly alter the behavior unless it
> can be explained clearly why the original change must have been
> outright wrong.
>=20

Well the original code IIRC had no justification for setting BME and =
doing it unconditionally does seem dangerous. Could we at least make it =
configurable?

  Paul




From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:12:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJUK-0001dU-Bf; Tue, 14 Apr 2020 11:12:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=kDu3=56=amazon.com=prvs=3660aa63e=havanur@srs-us1.protection.inumbo.net>)
 id 1jOJUJ-0001dP-QY
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:12:19 +0000
X-Inumbo-ID: cdd9b75a-7e40-11ea-83d8-bc764e2007e4
Received: from smtp-fw-33001.amazon.com (unknown [207.171.190.10])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cdd9b75a-7e40-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 11:12:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586862739; x=1618398739;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=RJH5Ny7ZuTyqXe89uGmJwGKLv6YkS5CWRBDIFP1xT20=;
 b=Wd8Bd3ouqkPjRzDljSxTREyebWeLWrI+xAAW8LdnOdsm+/125f/GAIHT
 DjT+WzxSbnTp2sgGXZ2/JYu6MkfzL/6pKeRSD2zTwVIn2taObAKP6kkrF
 xmWZNjU6yycukYZkdi8ItQedo0A0OKmY0WvtGZFZj4aU+8cvHEEOORZ2D k=;
IronPort-SDR: CNM23QsO6ZaZY44pACSBoTzQ8rpHOu/VJfs1fAgH6YNDGuqbWnxVNGVtGT4jWKmIp0Eb80gtvd
 wube4KlSqoPA==
X-IronPort-AV: E=Sophos;i="5.72,382,1580774400"; d="scan'208";a="38344909"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-1a-67b371d8.us-east-1.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP;
 14 Apr 2020 11:12:16 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166])
 by email-inbound-relay-1a-67b371d8.us-east-1.amazon.com (Postfix) with ESMTPS
 id 4C32EA2101; Tue, 14 Apr 2020 11:12:13 +0000 (UTC)
Received: from EX13D36EUC001.ant.amazon.com (10.43.164.105) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 11:12:13 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D36EUC001.ant.amazon.com (10.43.164.105) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 11:12:12 +0000
Received: from dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com
 (172.19.122.179) by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP
 Server id 15.0.1497.2 via Frontend Transport; Tue, 14 Apr 2020 11:12:11 +0000
Received: by dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com (Postfix,
 from userid 11119479)
 id 4917E83AC8; Tue, 14 Apr 2020 11:12:11 +0000 (UTC)
From: Harsha Shamsundara Havanur <havanur@amazon.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v3] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Tue, 14 Apr 2020 11:12:01 +0000
Message-ID: <758e3427f147ed82774edcbbe80b0b29c812e6e4.1586862721.git.havanur@amazon.com>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Harsha Shamsundara Havanur <havanur@amazon.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It was observed that PCI MMIO and/or IO BARs were programmed with
memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
during PCI setup phase. This resulted in incorrect memory mapping as
soon as the lower half of the 64 bit bar is programmed.
This displaced any RAM mappings under 4G. After the
upper half is programmed PCI memory mapping is restored to its
intended high mem location, but the RAM displaced is not restored.
The OS then continues to boot and function until it tries to access
the displaced RAM at which point it suffers a page fault and crashes.

This patch address the issue by deferring enablement of memory and
I/O decode in command register until all the resources, like interrupts
I/O and/or MMIO BARs for all the PCI device functions are programmed,
in the descending order of memory requested.

Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
Reviewed-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
 tools/firmware/hvmloader/pci.c | 37 +++++++++++++++++++++++++++----------
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 0b708bf578..b8a0df3286 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -84,6 +84,7 @@ void pci_setup(void)
     uint32_t vga_devfn = 256;
     uint16_t class, vendor_id, device_id;
     unsigned int bar, pin, link, isa_irq;
+    uint8_t pci_devfn_decode_type[256] = {};
 
     /* Resources assignable to PCI devices via BARs. */
     struct resource {
@@ -120,6 +121,9 @@ void pci_setup(void)
      */
     bool allow_memory_relocate = 1;
 
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY != PCI_COMMAND_MEMORY);
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_IO);
+
     s = xenstore_read(HVM_XS_ALLOW_MEMORY_RELOCATE, NULL);
     if ( s )
         allow_memory_relocate = strtoll(s, NULL, 0);
@@ -288,10 +292,21 @@ void pci_setup(void)
             printf("pci dev %02x:%x INT%c->IRQ%u\n",
                    devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
         }
-
         /* Enable bus mastering. */
         cmd = pci_readw(devfn, PCI_COMMAND);
         cmd |= PCI_COMMAND_MASTER;
+
+        /*
+         * Disable memory and I/O decode,
+         * It is recommended that BAR programming be done whilst
+         * decode bits are cleared to avoid incorrect mappings being created,
+         * when 64-bit memory BAR is programmed first by writing the lower half
+         * and then the upper half, which first maps to an address under 4G
+         * replacing any RAM mapped in that address, which is not restored
+         * back after the upper half is written and PCI memory is correctly
+         * mapped to its intended high mem address.
+         */
+        cmd &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
         pci_writew(devfn, PCI_COMMAND, cmd);
     }
 
@@ -497,16 +512,12 @@ void pci_setup(void)
                PRIllx_arg(bar_sz),
                bar_data_upper, bar_data);
 			
-
-        /* Now enable the memory or I/O mapping. */
-        cmd = pci_readw(devfn, PCI_COMMAND);
         if ( (bar_reg == PCI_ROM_ADDRESS) ||
              ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
               PCI_BASE_ADDRESS_SPACE_MEMORY) )
-            cmd |= PCI_COMMAND_MEMORY;
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
         else
-            cmd |= PCI_COMMAND_IO;
-        pci_writew(devfn, PCI_COMMAND, cmd);
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_IO;
     }
 
     if ( pci_hi_mem_start )
@@ -526,10 +537,16 @@ void pci_setup(void)
          * has IO enabled, even if there is no I/O BAR on that
          * particular device.
          */
-        cmd = pci_readw(vga_devfn, PCI_COMMAND);
-        cmd |= PCI_COMMAND_IO;
-        pci_writew(vga_devfn, PCI_COMMAND, cmd);
+        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
     }
+
+    /* Enable memory and I/O decode. */
+    for ( devfn = 0; devfn < 256; devfn++ )
+        if ( pci_devfn_decode_type[devfn] ) {
+            cmd = pci_readw(devfn, PCI_COMMAND);
+            cmd |= pci_devfn_decode_type[devfn];
+            pci_writew(devfn, PCI_COMMAND, cmd);
+        }
 }
 
 /*
-- 
2.16.6



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:19:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJb6-0001pD-8b; Tue, 14 Apr 2020 11:19:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=18iO=56=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOJb5-0001p6-AI
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:19:19 +0000
X-Inumbo-ID: c7db885a-7e41-11ea-9e09-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c7db885a-7e41-11ea-9e09-bc764e2007e4;
 Tue, 14 Apr 2020 11:19:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586863158;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=1O7/TP4Hquw+S6YKfNy8yt/djg5QOKDWKw1HD8/6W3o=;
 b=CBctiAoeP+eqCPAL8dnKVH0Ki8nxBm6sYF+DA4wE0f9IHwj5STrc2jI+
 nmBKMwi2PsGy1yFMGi7rdEagGBu06HL/DB6PEtFKUfskbtBkCyTVAh34q
 JiZ6jBH9wN2i7iGDbzKX0V6sTV0orlUqTNpKlFegz3/mAin7xyzNsmNEb 4=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: +40fODGd5LLGlF8T3LwGC+yx5zc9gzXOR/bC5nnrk33Lw/y2Q6lpszkGvzRLwfkO4pHUtNh6u5
 /NXFevh9T5F8XbV2ZNMd7MWF4NYyEyJX9HHWiU6Vcsd+9+BrWfLHbfR/jwVSNiAcBnEJSR5fiv
 TICU7yOM6/YpmAWHdgd/HNQkcXuVKzhG+nTW4irDVPZmXX+ayKsJQp3XuuS/fMyFx7xNgB7N1N
 n6zw0RkYnQ/QQdwxA3sctJM+X3NP5VI1AkidEAJPbXZ5/5Hfy6Cl+wqm/bCAG//QlT0Ubw7pm9
 nkk=
X-SBRS: 2.7
X-MesageID: 16305962
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="16305962"
Date: Tue, 14 Apr 2020 13:19:11 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200414111911.GI28601@Air-de-Roger>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
> On 14.04.2020 12:02, Roger Pau Monné wrote:
> > On Tue, Apr 14, 2020 at 11:01:06AM +0200, Jan Beulich wrote:
> >> On 14.04.2020 09:52, Roger Pau Monné wrote:
> >>> On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
> >>>> On 06.04.2020 12:57, Roger Pau Monne wrote:
> >>>>> --- a/xen/arch/x86/mm/hap/hap.c
> >>>>> +++ b/xen/arch/x86/mm/hap/hap.c
> >>>>> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
> >>>>>              p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
> >>>>>                                    p2m_ram_rw, p2m_ram_logdirty);
> >>>>>  
> >>>>> -            flush_tlb_mask(d->dirty_cpumask);
> >>>>> +            hap_flush_tlb_mask(d->dirty_cpumask);
> >>>>>  
> >>>>>              memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
> >>>>>          }
> >>>>> @@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
> >>>>>           * to be read-only, or via hardware-assisted log-dirty.
> >>>>>           */
> >>>>>          p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> >>>>> -        flush_tlb_mask(d->dirty_cpumask);
> >>>>> +        hap_flush_tlb_mask(d->dirty_cpumask);
> >>>>>      }
> >>>>>      return 0;
> >>>>>  }
> >>>>> @@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
> >>>>>       * be read-only, or via hardware-assisted log-dirty.
> >>>>>       */
> >>>>>      p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
> >>>>> -    flush_tlb_mask(d->dirty_cpumask);
> >>>>> +    hap_flush_tlb_mask(d->dirty_cpumask);
> >>>>>  }
> >>>>>  
> >>>>>  /************************************************/
> >>>>> @@ -798,7 +798,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
> >>>>>  
> >>>>>      safe_write_pte(p, new);
> >>>>>      if ( old_flags & _PAGE_PRESENT )
> >>>>> -        flush_tlb_mask(d->dirty_cpumask);
> >>>>> +        hap_flush_tlb_mask(d->dirty_cpumask);
> >>>>>  
> >>>>>      paging_unlock(d);
> >>>>>  
> >>>>
> >>>> Following up on my earlier mail about paging_log_dirty_range(), I'm
> >>>> now of the opinion that all of these flushes should go away too. I
> >>>> can only assume that they got put where they are when HAP code was
> >>>> cloned from the shadow one. These are only p2m operations, and hence
> >>>> p2m level TLB flushing is all that's needed here.
> >>>
> >>> IIRC without those ASID flushes NPT won't work correctly, as I think
> >>> it relies on those flushes when updating the p2m.
> >>
> >> Hmm, yes - at least for this last one (in patch context) I definitely
> >> agree: NPT's TLB invalidation is quite different from EPT's (and I
> >> was too focused on the latter when writing the earlier reply).
> >> Therefore how about keeping hap_flush_tlb_mask() (and its uses), but
> >> teaching it to do nothing for EPT, while doing an ASID based flush
> >> for NPT?
> > 
> > I could give that a try. I'm slightly worried that EPT code might rely
> > on some of those ASID/VPID flushes. It seems like it's trying to do
> > VPID flushes when needed, but issues could be masked by the ASID/VPID
> > flushes done by the callers.
> 
> I can't seem to find any EPT code doing VPID flushes, and I'd also
> not expect to. There's VMX code doing so, yes. EPT should be fully
> agnostic to guest virtual address space.

I got confused.

> >> There may then even be the option to have a wider purpose helper,
> >> dealing with most (all?) of the flushes needed from underneath
> >> x86/mm/, setting the TLB and HVM_ASID_CORE flags as appropriate. In
> >> the EPT case the function would still be a no-op (afaict).
> > 
> > That seems nice, we would have to be careful however as reducing the
> > number of ASID/VPID flushes could uncover issues in the existing code.
> > I guess you mean something like:
> > 
> > static inline void guest_flush_tlb_mask(const struct domain *d,
> >                                         const cpumask_t *mask)
> > {
> >     flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
> >                                                                 : 0) |
> >     		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> > 		                                      : 0));
> > }
> 
> Almost - is_hvm_domain(d) && cpu_has_svm seems to wide for me. I'd
> rather use hap_enabled() && cpu_has_svm, which effectively means NPT.
> Or am I overlooking a need to do ASID flushes also in shadow mode?

I think so, I've used is_hvm_domain in order to cover for HVM domains
running in shadow mode on AMD hardware, I think those also need the
ASID flushes.

> Also I'd suggest to calculate the flags up front, to avoid calling
> flush_mask() in the first place in case (EPT) neither bit is set.
> 
> > I think this should work, but I would rather do it in a separate
> > patch.
> 
> Yes, just like the originally (wrongly, as you validly say) suggested
> full removal of them, putting this in a separate patch would indeed
> seem better.

Would you like me to resend with the requested fix to
paging_log_dirty_range (ie: drop the FLUSH_TLB and only call
flush_mask for HAP guests running on AMD) then?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:29:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:29:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJkv-0002iw-BU; Tue, 14 Apr 2020 11:29:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOJku-0002ir-A1
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:29:28 +0000
X-Inumbo-ID: 32d5f928-7e43-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 32d5f928-7e43-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 11:29:27 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B0936AD0F;
 Tue, 14 Apr 2020 11:29:25 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v2 0/2] x86: VM assist hypercall adjustments
Message-ID: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
Date: Tue, 14 Apr 2020 13:29:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

1: HVM: expose VM assist hypercall
2: validate VM assist value in arch_set_info_guest()

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:32:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJnb-0003VF-Tq; Tue, 14 Apr 2020 11:32:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=WDKb=56=redhat.com=armbru@srs-us1.protection.inumbo.net>)
 id 1jOJna-0003VA-Q9
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:32:14 +0000
X-Inumbo-ID: 9693f65e-7e43-11ea-83d8-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 9693f65e-7e43-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 11:32:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1586863933;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=DYr/KkW0QKxRMJqYT/HOwSxpZUuq1t2YsKc/mTSrfYk=;
 b=XAWn5qMpSMcXQnMjSRSqUL6fuB47VcoPM6wdz3wJAPwY2+Tu7DbueIcrxSWX4CdL+VrTek
 EaKYRxrPBMWqnipsjb0v7hmpEBZZL7zywdrEnJkLSwy2+06Vg41SrvQ88XBy2qmEfRX6Q0
 Olw5y4AVhVN91JP44tj+IUlD4c+YRpw=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-415-9sDNE59FPAeERBjNn-43JQ-1; Tue, 14 Apr 2020 07:32:11 -0400
X-MC-Unique: 9sDNE59FPAeERBjNn-43JQ-1
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com
 [10.5.11.14])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 08406107BA97;
 Tue, 14 Apr 2020 11:32:08 +0000 (UTC)
Received: from blackfin.pond.sub.org (ovpn-113-20.ams2.redhat.com
 [10.36.113.20])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id 3BCC15D9E2;
 Tue, 14 Apr 2020 11:32:01 +0000 (UTC)
Received: by blackfin.pond.sub.org (Postfix, from userid 1000)
 id B5AB011385C8; Tue, 14 Apr 2020 13:31:59 +0200 (CEST)
From: Markus Armbruster <armbru@redhat.com>
To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
Subject: Re: [PATCH-for-5.1 3/3] hw: Remove unnecessary DEVICE() cast
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-4-f4bug@amsat.org>
Date: Tue, 14 Apr 2020 13:31:59 +0200
In-Reply-To: <20200412210954.32313-4-f4bug@amsat.org> ("Philippe
 =?utf-8?Q?Mathieu-Daud=C3=A9=22's?= message of "Sun, 12 Apr 2020 23:09:54
 +0200")
Message-ID: <87lfmytia8.fsf@dusky.pond.sub.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, qemu-devel@nongnu.org,
 Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, Richard Henderson <rth@twiddle.net>,
 Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?utf-8?Q?C=C3=A9dric?= Le Goater <clg@kaod.org>, John Snow <jsnow@redhat.com>,
 David Gibson <david@gibson.dropbear.id.au>,
 "Daniel P. =?utf-8?Q?Berrang=C3=A9?=" <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Philippe Mathieu-Daud=C3=A9 <f4bug@amsat.org> writes:

> The DEVICE() macro is defined as:
>
>   #define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)
>
> Remove unnecessary DEVICE() casts.
>
> Patch created mechanically using spatch with this script:
>
>   @@
>   typedef DeviceState;
>   DeviceState *s;
>   @@
>   -   DEVICE(s)
>   +   s
>
> Signed-off-by: Philippe Mathieu-Daud=C3=A9 <f4bug@amsat.org>

DEVICE(obj) expands to

    OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)

and then to

    ((DeviceState *)object_dynamic_cast_assert((Object *)(obj), (name),
                                               __FILE__, __LINE__, __func__=
))

object_dynamic_cast_assert() asserts @obj can be safely converted to the
type named by @name, and returns @obj.

Your patch drops the assertion.

The assertion can only fail when @obj points to something other than its
stated type, i.e. when we're in undefined behavior country.

Preferably with this argument worked into your commit message:
Reviewed-by: Markus Armbruster <armbru@redhat.com>

There are many similar macros.  Should they get the same treatment?



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:34:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:34:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJpt-0003dN-Kn; Tue, 14 Apr 2020 11:34:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOJps-0003dI-63
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:34:36 +0000
X-Inumbo-ID: ea531a2c-7e43-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ea531a2c-7e43-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 11:34:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1C5A6AD9A;
 Tue, 14 Apr 2020 11:34:33 +0000 (UTC)
Subject: [PATCH v2 1/2] x86/HVM: expose VM assist hypercall
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
Message-ID: <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
Date: Tue, 14 Apr 2020 13:34:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In preparation for the addition of VMASST_TYPE_runstate_update_flag
commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
the hypercall for Arm. I consider it not logical that it then isn't also
exposed to x86 HVM guests (with the same single feature permitted to be
enabled as Arm has); Linux actually tries to use it afaict.

Rather than introducing yet another thin wrapper around vm_assist(),
make that function the main handler, requiring a per-arch
arch_vm_assist_valid() definition instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Re-work vm_assist() handling/layering at the same time. Also adjust
    arch_set_info_guest().

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -939,6 +939,9 @@ int arch_set_info_guest(
         v->arch.dr6 = c(debugreg[6]);
         v->arch.dr7 = c(debugreg[7]);
 
+        if ( v->vcpu_id == 0 )
+            d->vm_assist = c.nat->vm_assist;
+
         hvm_set_info_guest(v);
         goto out;
     }
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -128,6 +128,7 @@ static const hypercall_table_t hvm_hyper
 #ifdef CONFIG_GRANT_TABLE
     HVM_CALL(grant_table_op),
 #endif
+    HYPERCALL(vm_assist),
     COMPAT_CALL(vcpu_op),
     HVM_CALL(physdev_op),
     COMPAT_CALL(xen_version),
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -57,7 +57,7 @@ const hypercall_table_t pv_hypercall_tab
 #ifdef CONFIG_GRANT_TABLE
     COMPAT_CALL(grant_table_op),
 #endif
-    COMPAT_CALL(vm_assist),
+    HYPERCALL(vm_assist),
     COMPAT_CALL(update_va_mapping_otherdomain),
     COMPAT_CALL(iret),
     COMPAT_CALL(vcpu_op),
--- a/xen/common/compat/kernel.c
+++ b/xen/common/compat/kernel.c
@@ -37,11 +37,6 @@ CHECK_TYPE(capabilities_info);
 
 CHECK_TYPE(domain_handle);
 
-#ifdef COMPAT_VM_ASSIST_VALID
-#undef VM_ASSIST_VALID
-#define VM_ASSIST_VALID COMPAT_VM_ASSIST_VALID
-#endif
-
 #define DO(fn) int compat_##fn
 #define COMPAT
 
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
     return rc;
 }
 
-#ifdef VM_ASSIST_VALID
-long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
-               unsigned long valid)
+#ifdef arch_vm_assist_valid
+long do_vm_assist(unsigned int cmd, unsigned int type)
 {
+    struct domain *currd = current->domain;
+    const unsigned long valid = arch_vm_assist_valid(currd);
+
     if ( type >= BITS_PER_LONG || !test_bit(type, &valid) )
         return -EINVAL;
 
     switch ( cmd )
     {
     case VMASST_CMD_enable:
-        set_bit(type, &p->vm_assist);
+        set_bit(type, &currd->vm_assist);
         return 0;
+
     case VMASST_CMD_disable:
-        clear_bit(type, &p->vm_assist);
+        clear_bit(type, &currd->vm_assist);
         return 0;
     }
 
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -566,13 +566,6 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDL
     return -ENOSYS;
 }
 
-#ifdef VM_ASSIST_VALID
-DO(vm_assist)(unsigned int cmd, unsigned int type)
-{
-    return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
-}
-#endif
-
 /*
  * Local variables:
  * mode: C
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -195,8 +195,6 @@ extern unsigned long frametable_virt_end
 #define watchdog_disable() ((void)0)
 #define watchdog_enable()  ((void)0)
 
-#define VM_ASSIST_VALID          (1UL << VMASST_TYPE_runstate_update_flag)
-
 #endif /* __ARM_CONFIG_H__ */
 /*
  * Local variables:
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -269,6 +269,8 @@ static inline void free_vcpu_guest_conte
 
 static inline void arch_vcpu_block(struct vcpu *v) {}
 
+#define arch_vm_assist_valid(d) (1UL << VMASST_TYPE_runstate_update_flag)
+
 #endif /* __ASM_DOMAIN_H__ */
 
 /*
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -309,17 +309,6 @@ extern unsigned long xen_phys_start;
 #define ARG_XLAT_START(v)        \
     (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
 
-#define NATIVE_VM_ASSIST_VALID   ((1UL << VMASST_TYPE_4gb_segments)        | \
-                                  (1UL << VMASST_TYPE_4gb_segments_notify) | \
-                                  (1UL << VMASST_TYPE_writable_pagetables) | \
-                                  (1UL << VMASST_TYPE_pae_extended_cr3)    | \
-                                  (1UL << VMASST_TYPE_architectural_iopl)  | \
-                                  (1UL << VMASST_TYPE_runstate_update_flag)| \
-                                  (1UL << VMASST_TYPE_m2p_strict))
-#define VM_ASSIST_VALID          NATIVE_VM_ASSIST_VALID
-#define COMPAT_VM_ASSIST_VALID   (NATIVE_VM_ASSIST_VALID & \
-                                  ((1UL << COMPAT_BITS_PER_LONG) - 1))
-
 #define ELFSIZE 64
 
 #define ARCH_CRASH_SAVE_VMCOREINFO
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -700,6 +700,20 @@ static inline void pv_inject_sw_interrup
     pv_inject_event(&event);
 }
 
+#define PV_VM_ASSIST_VALID  ((1UL << VMASST_TYPE_4gb_segments)        | \
+                             (1UL << VMASST_TYPE_4gb_segments_notify) | \
+                             (1UL << VMASST_TYPE_writable_pagetables) | \
+                             (1UL << VMASST_TYPE_pae_extended_cr3)    | \
+                             (1UL << VMASST_TYPE_architectural_iopl)  | \
+                             (1UL << VMASST_TYPE_runstate_update_flag)| \
+                             (1UL << VMASST_TYPE_m2p_strict))
+#define HVM_VM_ASSIST_VALID (1UL << VMASST_TYPE_runstate_update_flag)
+
+#define arch_vm_assist_valid(d) \
+    (is_hvm_domain(d) ? HVM_VM_ASSIST_VALID \
+                      : is_pv_32bit_domain(d) ? (uint32_t)PV_VM_ASSIST_VALID \
+                                              : PV_VM_ASSIST_VALID)
+
 #endif /* __ASM_DOMAIN_H__ */
 
 /*
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -192,8 +192,6 @@ extern int compat_xsm_op(
 
 extern int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg);
 
-extern int compat_vm_assist(unsigned int cmd, unsigned int type);
-
 DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t);
 extern int compat_multicall(
     XEN_GUEST_HANDLE_PARAM(multicall_entry_compat_t) call_list,
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -122,8 +122,6 @@ extern void guest_printk(const struct do
     __attribute__ ((format (printf, 2, 3)));
 extern void noreturn panic(const char *format, ...)
     __attribute__ ((format (printf, 1, 2)));
-extern long vm_assist(struct domain *, unsigned int cmd, unsigned int type,
-                      unsigned long valid);
 extern int __printk_ratelimit(int ratelimit_ms, int ratelimit_burst);
 extern int printk_ratelimit(void);
 


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:35:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:35:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJqT-0003fi-0m; Tue, 14 Apr 2020 11:35:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOJqR-0003fX-2c
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:35:11 +0000
X-Inumbo-ID: ff2aa302-7e43-11ea-8926-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ff2aa302-7e43-11ea-8926-12813bfff9fa;
 Tue, 14 Apr 2020 11:35:10 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8EC13AD0F;
 Tue, 14 Apr 2020 11:35:08 +0000 (UTC)
Subject: [PATCH v2 2/2] x86: validate VM assist value in arch_set_info_guest()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
Message-ID: <f46967a9-f55d-63f1-1825-352a122fdd8e@suse.com>
Date: Tue, 14 Apr 2020 13:35:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While I can't spot anything that would go wrong, just like the
respective hypercall only permits applicable bits to be set, we should
also do so when loading guest context.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I'd like to note that Arm lacks a field to save/restore vm_assist.

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -932,6 +932,9 @@ int arch_set_info_guest(
         }
     }
 
+    if ( v->vcpu_id == 0 && (c(vm_assist) & ~arch_vm_assist_valid(d)) )
+        return -EINVAL;
+
     if ( is_hvm_domain(d) )
     {
         for ( i = 0; i < ARRAY_SIZE(v->arch.dr); ++i )



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:39:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJuj-0003uW-My; Tue, 14 Apr 2020 11:39:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOJui-0003uR-TA
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:39:36 +0000
X-Inumbo-ID: 9dcb16c2-7e44-11ea-8927-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9dcb16c2-7e44-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 11:39:36 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 720C5AC4A;
 Tue, 14 Apr 2020 11:39:34 +0000 (UTC)
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: paul@xen.org
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
 <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
 <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
 <a102ec836a00714678fb3aa46787f597c9044f29.camel@amazon.com>
 <cfe18a03-854d-8b91-b333-ae2cefe3e1c8@suse.com>
 <000001d6124c$0aced570$206c8050$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <90fd6e75-32b6-a140-1d20-083947bf1681@suse.com>
Date: Tue, 14 Apr 2020 13:39:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <000001d6124c$0aced570$206c8050$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: wl@xen.org, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
 "'Shamsundara Havanur, Harsha'" <havanur@amazon.com>,
 xen-devel@lists.xenproject.org, roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 13:01, Paul Durrant wrote:
>> -----Original Message-----
>>>
>>> Previous commit enabled MASTER for all functions. I am bit confused
>>> here on the consensus on enabling/disabling/retaining BME.
>>> Should we even care about MASTER?
>>
>> With the commit introducing its universal setting, I'm afraid to
>> avoid regressions we can't sensibly alter the behavior unless it
>> can be explained clearly why the original change must have been
>> outright wrong.
>>
> 
> Well the original code IIRC had no justification for setting BME
> and doing it unconditionally does seem dangerous.

I'm not viewing this as dangerous, merely as (typically) pointless.
A well behaved device won't start issuing DMA requests merely
because it had its bus mastering capability enabled. (And in the
context of some IOMMU work of yours you actually stated there are
devices where clearing of this bit won't stop them from doing so.)

> Could we at least make it configurable?
Well, the main question then would be - configurable by which
mechanism?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:40:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:40:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJv3-0003wN-2G; Tue, 14 Apr 2020 11:39:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOJv2-0003wC-8B
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:39:56 +0000
X-Inumbo-ID: a954fac6-7e44-11ea-8927-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a954fac6-7e44-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 11:39:55 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0F15BAC4A;
 Tue, 14 Apr 2020 11:39:54 +0000 (UTC)
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v6 00/10] x86emul: further work
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Message-ID: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Date: Tue, 14 Apr 2020 13:39:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

A few of the patches are still at least partly RFC, for varying
reasons (see there). I'd appreciate though if at least some of
the series could go in rather sooner than later. The two new
ones (8 and 9) could likely be moved arbitrarily ahead (as a
pair, not 9 ahead of 8), if others are to be further delayed.

 1: x86: determine HAVE_AS_* just once
 2: x86: move back clang no integrated assembler tests
 3: x86emul: support MOVDIR{I,64B} insns
 4: x86emul: support ENQCMD insn
 5: x86/HVM: scale MPERF values reported to guests (on AMD)
 6: x86emul: support RDPRU
 7: x86/HVM: don't needlessly intercept APERF/MPERF/TSC MSR reads
 8: x86emul: support SERIALIZE
 9: x86emul: support X{SUS,RES}LDTRK
10: x86emul: support MCOMMIT

See individual patches for changes from v5; as indicated in reply
to v5 I've not changed patch 1 according to feedback, as I'm not
(yet?) convinced of the underlying (new) model.

Patch 3 continues to (contextually) depend on the still pending
"x86emul: disable FPU/MMX/SIMD insn emulation when !HVM".

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:43:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:43:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJyh-0004nz-M7; Tue, 14 Apr 2020 11:43:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOJyf-0004nu-VW
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:43:41 +0000
X-Inumbo-ID: 2fa59b09-7e45-11ea-8927-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2fa59b09-7e45-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 11:43:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 33DAAAC4A;
 Tue, 14 Apr 2020 11:43:39 +0000 (UTC)
Subject: [PATCH v6 01/10] x86: determine HAVE_AS_* just once
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <8fc57413-4adb-fd31-ea43-440eda3c1e92@suse.com>
Date: Tue, 14 Apr 2020 13:43:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

With the exception of HAVE_AS_QUOTED_SYM, populate the results into a
generated header instead of (at least once per [sub]directory) into
CFLAGS. This results in proper rebuilds (via make dependencies) in case
the compiler used changes between builds. It additionally eases
inspection of which assembler features were actually found usable.

Some trickery is needed to avoid header generation itself to try to
include the to-be/not-yet-generated header.

Since the definitions in generated/config.h, previously having been
command line options, might even affect xen/config.h or its descendants,
move adding of the -include option for the latter after inclusion of the
per-arch Rules.mk. Use the occasion to also move the most general -I
option to the common Rules.mk.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v5: Re-base.
v4: New.
---
An alternative to the $(MAKECMDGOALS) trickery would be to make
generation of generated/config.h part of the asm-offsets.s rule, instead
of adding it as a dependency there. Not sure whether either is truly
better than the other.

--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -55,7 +55,7 @@ endif
 CFLAGS += -nostdinc -fno-builtin -fno-common
 CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 $(call cc-option-add,CFLAGS,CC,-Wvla)
-CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
+CFLAGS += -pipe -D__XEN__ -I$(BASEDIR)/include
 CFLAGS-$(CONFIG_DEBUG_INFO) += -g
 CFLAGS += '-D__OBJECT_FILE__="$@"'
 
@@ -95,6 +95,9 @@ SPECIAL_DATA_SECTIONS := rodata $(foreac
 
 include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
 
+# Allow the arch to use -include ahead of this one.
+CFLAGS += -include xen/config.h
+
 include Makefile
 
 define gendep
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -6,8 +6,6 @@
 # 'make clean' before rebuilding.
 #
 
-CFLAGS += -I$(BASEDIR)/include
-
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 $(call cc-option-add,CFLAGS,CC,-Wnested-externs)
 
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -225,7 +225,8 @@ endif
 efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o efi/relocs-dummy.o: $(BASEDIR)/arch/x86/efi/built_in.o
 efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o efi/relocs-dummy.o: ;
 
-asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c $(BASEDIR)/include/asm-x86/asm-macros.h
+asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c $(BASEDIR)/include/asm-x86/asm-macros.h \
+	$(BASEDIR)/include/generated/config.h
 	$(CC) $(filter-out -Wa$(comma)% -flto,$(CFLAGS)) -S -o $@ $<
 
 asm-macros.i: CFLAGS += -D__ASSEMBLY__ -P
@@ -241,6 +242,45 @@ $(BASEDIR)/include/asm-x86/asm-macros.h:
 	echo '#endif' >>$@.new
 	$(call move-if-changed,$@.new,$@)
 
+# There are multiple invocations of this Makefile, one each for asm-offset.s,
+# $(TARGET), built_in.o, and several more from the rules building $(TARGET)
+# and $(TARGET).efi. The 2nd and 3rd may race with one another, and we don't
+# want to re-generate config.h in that case anyway, so guard the logic
+# accordingly. (We do want to have the FORCE dependency on the rule, to be
+# sure we pick up changes when the compiler used has changed.)
+ifeq ($(MAKECMDGOALS),asm-offsets.s)
+
+as-ISA-list := CLWB EPT FSGSBASE INVPCID RDRAND RDSEED SSE4_2 VMX XSAVEOPT
+
+CLWB-insn	:= clwb (%rax)
+EPT-insn	:= invept (%rax),%rax
+FSGSBASE-insn	:= rdfsbase %rax
+INVPCID-insn	:= invpcid (%rax),%rax
+RDRAND-insn	:= rdrand %eax
+RDSEED-insn	:= rdseed %eax
+SSE4_2-insn	:= crc32 %eax,%eax
+VMX-insn	:= vmcall
+XSAVEOPT-insn	:= xsaveopt (%rax)
+
+# GAS's idea of true is -1.  Clang's idea is 1.
+NEGATIVE_TRUE-insn := .if ((1 > 0) > 0); .error \"\"; .endif
+
+# Check to see whether the assembler supports the .nops directive.
+NOPS_DIRECTIVE-insn := .L1: .L2: .nops (.L2 - .L1),9
+
+as-features-list := $(as-ISA-list) NEGATIVE_TRUE NOPS_DIRECTIVE
+
+$(BASEDIR)/include/generated/config.h: FORCE
+	echo '/* Generated header, do not edit. */' >$@.new
+	$(foreach f,$(as-features-list), \
+	  $(if $($(f)-insn),,$(error $(f)-insn is empty)) \
+	  echo '#$(call as-insn,$(CC) $(CFLAGS),"$($(f)-insn)", \
+	           define, \
+	           undef) HAVE_AS_$(f) /* $($(f)-insn) */' >>$@.new;)
+	$(call move-if-changed,$@.new,$@)
+
+endif
+
 efi.lds: AFLAGS += -DEFI
 xen.lds efi.lds: xen.lds.S
 	$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,7 +3,7 @@
 
 XEN_IMG_OFFSET := 0x200000
 
-CFLAGS += -I$(BASEDIR)/include
+CFLAGS += $(if $(filter asm-macros.% %/generated/config.h,$@),,-include generated/config.h)
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
 CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
@@ -38,26 +38,9 @@ endif
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 $(call cc-option-add,CFLAGS,CC,-Wnested-externs)
-$(call as-option-add,CFLAGS,CC,"vmcall",-DHAVE_AS_VMX)
-$(call as-option-add,CFLAGS,CC,"crc32 %eax$$(comma)%eax",-DHAVE_AS_SSE4_2)
-$(call as-option-add,CFLAGS,CC,"invept (%rax)$$(comma)%rax",-DHAVE_AS_EPT)
-$(call as-option-add,CFLAGS,CC,"rdrand %eax",-DHAVE_AS_RDRAND)
-$(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE)
-$(call as-option-add,CFLAGS,CC,"xsaveopt (%rax)",-DHAVE_AS_XSAVEOPT)
-$(call as-option-add,CFLAGS,CC,"rdseed %eax",-DHAVE_AS_RDSEED)
-$(call as-option-add,CFLAGS,CC,"clwb (%rax)",-DHAVE_AS_CLWB)
 $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
                      -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM \
                      '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
-$(call as-option-add,CFLAGS,CC,"invpcid (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
-
-# GAS's idea of true is -1.  Clang's idea is 1
-$(call as-option-add,CFLAGS,CC,\
-    ".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE)
-
-# Check to see whether the assmbler supports the .nop directive.
-$(call as-option-add,CFLAGS,CC,\
-    ".L1: .L2: .nops (.L2 - .L1)$$(comma)9",-DHAVE_AS_NOPS_DIRECTIVE)
 
 CFLAGS += -mno-red-zone -fpic -fno-asynchronous-unwind-tables
 
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -64,7 +64,7 @@ compat/%.h: compat/%.i Makefile $(BASEDI
 	mv -f $@.new $@
 
 compat/%.i: compat/%.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $<
+	$(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $<
 
 compat/%.c: public/%.h xlat.lst Makefile $(BASEDIR)/tools/compat-build-source.py
 	mkdir -p $(@D)
--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -10,7 +10,7 @@ DEPS_INCLUDE = $(addsuffix .d2, $(basena
 # as-insn: Check whether assembler supports an instruction.
 # Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no)
 as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
-                       | $(filter-out -M% %.d -include %/include/xen/config.h,$(1)) \
+                       | $(filter-out -M% %.d -include %/config.h,$(1)) \
                               -c -x c -o /dev/null - 2>&1),$(4),$(3))
 
 # as-option-add: Conditionally add options to flags



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:44:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJz5-0004qB-0o; Tue, 14 Apr 2020 11:44:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOJz3-0004py-93
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:44:05 +0000
X-Inumbo-ID: 3d9a9204-7e45-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3d9a9204-7e45-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 11:44:04 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CBF4BAC61;
 Tue, 14 Apr 2020 11:44:02 +0000 (UTC)
Subject: [PATCH v6 02/10] x86: move back clang no integrated assembler tests
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <8759f341-3677-84bb-a393-e1b82c0c76ff@suse.com>
Date: Tue, 14 Apr 2020 13:44:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This largely reverts f19af2f1138e ("x86: re-order clang no integrated
assembler tests"): Other CFLAGS setup would better happen first, in case
any of it affects the behavior of the integrated assembler. The comment
addition of course doesn't get undone. The only remaining as-option-add
invocation gets moved down in addition.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
v5: Re-base.
v4: New.

--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -12,35 +12,8 @@ CFLAGS += '-D__OBJECT_LABEL__=$(subst /,
 # Prevent floating-point variables from creeping into Xen.
 CFLAGS += -msoft-float
 
-ifeq ($(CONFIG_CC_IS_CLANG),y)
-# Note: Any test which adds -no-integrated-as will cause subsequent tests to
-# succeed, and not trigger further additions.
-#
-# The tests to select whether the integrated assembler is usable need to happen
-# before testing any assembler features, or else the result of the tests would
-# be stale if the integrated assembler is not used.
-
-# Older clang's built-in assembler doesn't understand .skip with labels:
-# https://bugs.llvm.org/show_bug.cgi?id=27369
-$(call as-option-add,CFLAGS,CC,".L0: .L1: .skip (.L1 - .L0)",,\
-                     -no-integrated-as)
-
-# Check whether clang asm()-s support .include.
-$(call as-option-add,CFLAGS,CC,".include \"asm-x86/indirect_thunk_asm.h\"",,\
-                     -no-integrated-as)
-
-# Check whether clang keeps .macro-s between asm()-s:
-# https://bugs.llvm.org/show_bug.cgi?id=36110
-$(call as-option-add,CFLAGS,CC,\
-                     ".macro FOO;.endm"$$(close); asm volatile $$(open)".macro FOO;.endm",\
-                     -no-integrated-as)
-endif
-
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 $(call cc-option-add,CFLAGS,CC,-Wnested-externs)
-$(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
-                     -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM \
-                     '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
 
 CFLAGS += -mno-red-zone -fpic -fno-asynchronous-unwind-tables
 
@@ -70,3 +43,30 @@ endif
 # Set up the assembler include path properly for older toolchains.
 CFLAGS += -Wa,-I$(BASEDIR)/include
 
+ifeq ($(CONFIG_CC_IS_CLANG),y)
+# Note: Any test which adds -no-integrated-as will cause subsequent tests to
+# succeed, and not trigger further additions.
+#
+# The tests to select whether the integrated assembler is usable need to happen
+# before testing any assembler features, or else the result of the tests would
+# be stale if the integrated assembler is not used.
+
+# Older clang's built-in assembler doesn't understand .skip with labels:
+# https://bugs.llvm.org/show_bug.cgi?id=27369
+$(call as-option-add,CFLAGS,CC,".L0: .L1: .skip (.L1 - .L0)",,\
+                     -no-integrated-as)
+
+# Check whether clang asm()-s support .include.
+$(call as-option-add,CFLAGS,CC,".include \"asm-x86/indirect_thunk_asm.h\"",,\
+                     -no-integrated-as)
+
+# Check whether clang keeps .macro-s between asm()-s:
+# https://bugs.llvm.org/show_bug.cgi?id=36110
+$(call as-option-add,CFLAGS,CC,\
+                     ".macro FOO;.endm"$$(close); asm volatile $$(open)".macro FOO;.endm",\
+                     -no-integrated-as)
+endif
+
+$(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
+                     -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM \
+                     '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:44:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOJzo-0004we-I5; Tue, 14 Apr 2020 11:44:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOJzn-0004wP-0A
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:44:51 +0000
X-Inumbo-ID: 587a1900-7e45-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 587a1900-7e45-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 11:44:49 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C6F9CAC61;
 Tue, 14 Apr 2020 11:44:47 +0000 (UTC)
Subject: [PATCH v6 03/10] x86emul: support MOVDIR{I,64B} insns
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <a4361808-82f9-5b59-2c89-b3b4ee8a111b@suse.com>
Date: Tue, 14 Apr 2020 13:44:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <paul@xen.org>,
 Wei Liu <wl@xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Introduce a new blk() hook, paralleling the rmw() one in a certain way,
but being intended for larger data sizes, and hence its HVM intermediate
handling function doesn't fall back to splitting the operation if the
requested virtual address can't be mapped.

Note that SDM revision 071 doesn't specify exception behavior for
ModRM.mod == 0b11; assuming #UD here.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v6: Fold MOVDIRI and MOVDIR64B changes again. Use blk() for both. All
    tags dropped.
v5: Introduce/use ->blk() hook. Correct asm() operands.
v4: Split MOVDIRI and MOVDIR64B and move this one ahead. Re-base.
v3: Update description.
---
(SDE: -tnt)

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -652,6 +652,18 @@ static int cmpxchg(
     return X86EMUL_OKAY;
 }
 
+static int blk(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    uint32_t *eflags,
+    struct x86_emulate_state *state,
+    struct x86_emulate_ctxt *ctxt)
+{
+    return x86_emul_blk((void *)offset, p_data, bytes, eflags, state, ctxt);
+}
+
 static int read_segment(
     enum x86_segment seg,
     struct segment_register *reg,
@@ -2339,6 +2351,54 @@ int main(int argc, char **argv)
         goto fail;
     printf("okay\n");
 
+    emulops.blk = blk;
+
+    printf("%-40s", "Testing movdiri %edx,(%ecx)...");
+    if ( stack_exec && cpu_has_movdiri )
+    {
+        instr[0] = 0x0f; instr[1] = 0x38; instr[2] = 0xf9; instr[3] = 0x11;
+
+        regs.eip = (unsigned long)&instr[0];
+        regs.ecx = (unsigned long)memset(res, -1, 16);
+        regs.edx = 0x44332211;
+
+        rc = x86_emulate(&ctxt, &emulops);
+        if ( (rc != X86EMUL_OKAY) ||
+             (regs.eip != (unsigned long)&instr[4]) ||
+             res[0] != 0x44332211 || ~res[1] )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing movdir64b 144(%edx),%ecx...");
+    if ( stack_exec && cpu_has_movdir64b )
+    {
+        instr[0] = 0x66; instr[1] = 0x0f; instr[2] = 0x38; instr[3] = 0xf8;
+        instr[4] = 0x8a; instr[5] = 0x90; instr[8] = instr[7] = instr[6] = 0;
+
+        regs.eip = (unsigned long)&instr[0];
+        for ( i = 0; i < 64; ++i )
+            res[i] = i - 20;
+        regs.edx = (unsigned long)res;
+        regs.ecx = (unsigned long)(res + 16);
+
+        rc = x86_emulate(&ctxt, &emulops);
+        if ( (rc != X86EMUL_OKAY) ||
+             (regs.eip != (unsigned long)&instr[9]) ||
+             res[15] != -5 || res[32] != 12 )
+            goto fail;
+        for ( i = 16; i < 32; ++i )
+            if ( res[i] != i )
+                goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    emulops.blk = NULL;
+
     printf("%-40s", "Testing movq %mm3,(%ecx)...");
     if ( stack_exec && cpu_has_mmx )
     {
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -154,6 +154,8 @@ static inline bool xcr0_mask(uint64_t ma
 #define cpu_has_avx512_vnni (cp.feat.avx512_vnni && xcr0_mask(0xe6))
 #define cpu_has_avx512_bitalg (cp.feat.avx512_bitalg && xcr0_mask(0xe6))
 #define cpu_has_avx512_vpopcntdq (cp.feat.avx512_vpopcntdq && xcr0_mask(0xe6))
+#define cpu_has_movdiri    cp.feat.movdiri
+#define cpu_has_movdir64b  cp.feat.movdir64b
 #define cpu_has_avx512_4vnniw (cp.feat.avx512_4vnniw && xcr0_mask(0xe6))
 #define cpu_has_avx512_4fmaps (cp.feat.avx512_4fmaps && xcr0_mask(0xe6))
 #define cpu_has_avx512_bf16 (cp.feat.avx512_bf16 && xcr0_mask(0xe6))
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -250,12 +250,13 @@ $(BASEDIR)/include/asm-x86/asm-macros.h:
 # sure we pick up changes when the compiler used has changed.)
 ifeq ($(MAKECMDGOALS),asm-offsets.s)
 
-as-ISA-list := CLWB EPT FSGSBASE INVPCID RDRAND RDSEED SSE4_2 VMX XSAVEOPT
+as-ISA-list := CLWB EPT FSGSBASE INVPCID MOVDIR RDRAND RDSEED SSE4_2 VMX XSAVEOPT
 
 CLWB-insn	:= clwb (%rax)
 EPT-insn	:= invept (%rax),%rax
 FSGSBASE-insn	:= rdfsbase %rax
 INVPCID-insn	:= invpcid (%rax),%rax
+MOVDIR-insn	:= movdiri %rax,(%rax)
 RDRAND-insn	:= rdrand %eax
 RDSEED-insn	:= rdseed %eax
 SSE4_2-insn	:= crc32 %eax,%eax
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1409,6 +1409,44 @@ static int hvmemul_rmw(
     return rc;
 }
 
+static int hvmemul_blk(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    uint32_t *eflags,
+    struct x86_emulate_state *state,
+    struct x86_emulate_ctxt *ctxt)
+{
+    struct hvm_emulate_ctxt *hvmemul_ctxt =
+        container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
+    unsigned long addr;
+    uint32_t pfec = PFEC_page_present | PFEC_write_access;
+    int rc;
+    void *mapping = NULL;
+
+    rc = hvmemul_virtual_to_linear(
+        seg, offset, bytes, NULL, hvm_access_write, hvmemul_ctxt, &addr);
+    if ( rc != X86EMUL_OKAY || !bytes )
+        return rc;
+
+    if ( is_x86_system_segment(seg) )
+        pfec |= PFEC_implicit;
+    else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
+        pfec |= PFEC_user_mode;
+
+    mapping = hvmemul_map_linear_addr(addr, bytes, pfec, hvmemul_ctxt);
+    if ( IS_ERR(mapping) )
+        return ~PTR_ERR(mapping);
+    if ( !mapping )
+        return X86EMUL_UNHANDLEABLE;
+
+    rc = x86_emul_blk(mapping, p_data, bytes, eflags, state, ctxt);
+    hvmemul_unmap_linear_addr(mapping, addr, bytes, hvmemul_ctxt);
+
+    return rc;
+}
+
 static int hvmemul_write_discard(
     enum x86_segment seg,
     unsigned long offset,
@@ -2475,6 +2513,7 @@ static const struct x86_emulate_ops hvm_
     .write         = hvmemul_write,
     .rmw           = hvmemul_rmw,
     .cmpxchg       = hvmemul_cmpxchg,
+    .blk           = hvmemul_blk,
     .validate      = hvmemul_validate,
     .rep_ins       = hvmemul_rep_ins,
     .rep_outs      = hvmemul_rep_outs,
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -548,6 +548,8 @@ static const struct ext0f38_table {
     [0xf1] = { .to_mem = 1, .two_op = 1 },
     [0xf2 ... 0xf3] = {},
     [0xf5 ... 0xf7] = {},
+    [0xf8] = { .simd_size = simd_other },
+    [0xf9] = { .to_mem = 1, .two_op = 1 /* Mov */ },
 };
 
 /* Shift values between src and dst sizes of pmov{s,z}x{b,w,d}{w,d,q}. */
@@ -851,6 +853,9 @@ struct x86_emulate_state {
         rmw_xchg,
         rmw_xor,
     } rmw;
+    enum {
+        blk_movdir,
+    } blk;
     uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
     uint8_t sib_index, sib_scale;
     uint8_t rex_prefix;
@@ -1914,6 +1919,8 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
 #define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
 #define vcpu_has_rdpid()       (ctxt->cpuid->feat.rdpid)
+#define vcpu_has_movdiri()     (ctxt->cpuid->feat.movdiri)
+#define vcpu_has_movdir64b()   (ctxt->cpuid->feat.movdir64b)
 #define vcpu_has_avx512_4vnniw() (ctxt->cpuid->feat.avx512_4vnniw)
 #define vcpu_has_avx512_4fmaps() (ctxt->cpuid->feat.avx512_4fmaps)
 #define vcpu_has_avx512_bf16() (ctxt->cpuid->feat.avx512_bf16)
@@ -2722,10 +2729,12 @@ x86_decode_0f38(
     {
     case 0x00 ... 0xef:
     case 0xf2 ... 0xf5:
-    case 0xf7 ... 0xff:
+    case 0xf7 ... 0xf8:
+    case 0xfa ... 0xff:
         op_bytes = 0;
         /* fall through */
     case 0xf6: /* adcx / adox */
+    case 0xf9: /* movdiri */
         ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
         break;
 
@@ -10171,6 +10180,34 @@ x86_emulate(
                             : "0" ((uint32_t)src.val), "rm" (_regs.edx) );
         break;
 
+    case X86EMUL_OPC_66(0x0f38, 0xf8): /* movdir64b r,m512 */
+        host_and_vcpu_must_have(movdir64b);
+        generate_exception_if(ea.type != OP_MEM, EXC_UD);
+        src.val = truncate_ea(*dst.reg);
+        generate_exception_if(!is_aligned(x86_seg_es, src.val, 64, ctxt, ops),
+                              EXC_GP, 0);
+        fail_if(!ops->blk);
+        state->blk = blk_movdir;
+        BUILD_BUG_ON(sizeof(*mmvalp) < 64);
+        if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp, 64,
+                             ctxt)) != X86EMUL_OKAY ||
+             (rc = ops->blk(x86_seg_es, src.val, mmvalp, 64, &_regs.eflags,
+                            state, ctxt)) != X86EMUL_OKAY )
+            goto done;
+        state->simd_size = simd_none;
+        break;
+
+    case X86EMUL_OPC(0x0f38, 0xf9): /* movdiri mem,r */
+        host_and_vcpu_must_have(movdiri);
+        generate_exception_if(dst.type != OP_MEM, EXC_UD);
+        fail_if(!ops->blk);
+        state->blk = blk_movdir;
+        if ( (rc = ops->blk(dst.mem.seg, dst.mem.off, &src.val, op_bytes,
+                            &_regs.eflags, state, ctxt)) != X86EMUL_OKAY )
+            goto done;
+        dst.type = OP_NONE;
+        break;
+
 #ifndef X86EMUL_NO_SIMD
 
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x00): /* vpermq $imm8,ymm/m256,ymm */
@@ -11429,6 +11466,77 @@ int x86_emul_rmw(
 
     return X86EMUL_OKAY;
 }
+
+int x86_emul_blk(
+    void *ptr,
+    void *data,
+    unsigned int bytes,
+    uint32_t *eflags,
+    struct x86_emulate_state *state,
+    struct x86_emulate_ctxt *ctxt)
+{
+    switch ( state->blk )
+    {
+        /*
+         * Throughout this switch(), memory clobbers are used to compensate
+         * that other operands may not properly express the (full) memory
+         * ranges covered.
+         */
+    case blk_movdir:
+        switch ( bytes )
+        {
+#ifdef __x86_64__
+        case sizeof(uint32_t):
+# ifdef HAVE_AS_MOVDIR
+            asm ( "movdiri %0, (%1)"
+                 :: "r" (*(uint32_t *)data), "r" (ptr) : "memory" );
+# else
+            /* movdiri %esi, (%rdi) */
+            asm ( ".byte 0x0f, 0x38, 0xf9, 0x37"
+                  :: "S" (*(uint32_t *)data), "D" (ptr) : "memory" );
+# endif
+            break;
+#endif
+
+        case sizeof(unsigned long):
+#ifdef HAVE_AS_MOVDIR
+            asm ( "movdiri %0, (%1)"
+                 :: "r" (*(unsigned long *)data), "r" (ptr) : "memory" );
+#else
+            /* movdiri %rsi, (%rdi) */
+            asm ( ".byte 0x48, 0x0f, 0x38, 0xf9, 0x37"
+                  :: "S" (*(unsigned long *)data), "D" (ptr) : "memory" );
+#endif
+            break;
+
+        case 64:
+            if ( ((unsigned long)ptr & 0x3f) )
+            {
+                ASSERT_UNREACHABLE();
+                return X86EMUL_UNHANDLEABLE;
+            }
+#ifdef HAVE_AS_MOVDIR
+            asm ( "movdir64b (%0), %1" :: "r" (data), "r" (ptr) : "memory" );
+#else
+            /* movdir64b (%rsi), %rdi */
+            asm ( ".byte 0x66, 0x0f, 0x38, 0xf8, 0x3e"
+                  :: "S" (data), "D" (ptr) : "memory" );
+#endif
+            break;
+
+        default:
+            ASSERT_UNREACHABLE();
+            return X86EMUL_UNHANDLEABLE;
+        }
+        break;
+
+    default:
+        ASSERT_UNREACHABLE();
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    return X86EMUL_OKAY;
+}
 
 static void __init __maybe_unused build_assertions(void)
 {
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -310,6 +310,22 @@ struct x86_emulate_ops
         struct x86_emulate_ctxt *ctxt);
 
     /*
+     * blk: Emulate a large (block) memory access.
+     * @p_data: [IN/OUT] (optional) Pointer to source/destination buffer.
+     * @eflags: [IN/OUT] Pointer to EFLAGS to be updated according to
+     *                   instruction effects.
+     * @state:  [IN/OUT] Pointer to (opaque) emulator state.
+     */
+    int (*blk)(
+        enum x86_segment seg,
+        unsigned long offset,
+        void *p_data,
+        unsigned int bytes,
+        uint32_t *eflags,
+        struct x86_emulate_state *state,
+        struct x86_emulate_ctxt *ctxt);
+
+    /*
      * validate: Post-decode, pre-emulate hook to allow caller controlled
      * filtering.
      */
@@ -793,6 +809,14 @@ x86_emul_rmw(
     unsigned int bytes,
     uint32_t *eflags,
     struct x86_emulate_state *state,
+    struct x86_emulate_ctxt *ctxt);
+int
+x86_emul_blk(
+    void *ptr,
+    void *data,
+    unsigned int bytes,
+    uint32_t *eflags,
+    struct x86_emulate_state *state,
     struct x86_emulate_ctxt *ctxt);
 
 static inline void x86_emul_hw_exception(
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -120,6 +120,8 @@
 #define cpu_has_avx512_bitalg   boot_cpu_has(X86_FEATURE_AVX512_BITALG)
 #define cpu_has_avx512_vpopcntdq boot_cpu_has(X86_FEATURE_AVX512_VPOPCNTDQ)
 #define cpu_has_rdpid           boot_cpu_has(X86_FEATURE_RDPID)
+#define cpu_has_movdiri         boot_cpu_has(X86_FEATURE_MOVDIRI)
+#define cpu_has_movdir64b       boot_cpu_has(X86_FEATURE_MOVDIR64B)
 
 /* CPUID level 0x80000007.edx */
 #define cpu_has_itsc            boot_cpu_has(X86_FEATURE_ITSC)
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -237,6 +237,8 @@ XEN_CPUFEATURE(AVX512_BITALG, 6*32+12) /
 XEN_CPUFEATURE(AVX512_VPOPCNTDQ, 6*32+14) /*A  POPCNT for vectors of DW/QW */
 XEN_CPUFEATURE(RDPID,         6*32+22) /*A  RDPID instruction */
 XEN_CPUFEATURE(CLDEMOTE,      6*32+25) /*A  CLDEMOTE instruction */
+XEN_CPUFEATURE(MOVDIRI,       6*32+27) /*A  MOVDIRI instruction */
+XEN_CPUFEATURE(MOVDIR64B,     6*32+28) /*A  MOVDIR64B instruction */
 
 /* AMD-defined CPU features, CPUID level 0x80000007.edx, word 7 */
 XEN_CPUFEATURE(ITSC,          7*32+ 8) /*   Invariant TSC */



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:46:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:46:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOK0r-00053w-Ud; Tue, 14 Apr 2020 11:45:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOK0q-00053m-HS
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:45:56 +0000
X-Inumbo-ID: 7fe57dfe-7e45-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7fe57dfe-7e45-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 11:45:55 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 10066ADFE;
 Tue, 14 Apr 2020 11:45:54 +0000 (UTC)
Subject: [PATCH v6 04/10] x86emul: support ENQCMD insn
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <d73a52d8-6835-3489-a351-8608789504fc@suse.com>
Date: Tue, 14 Apr 2020 13:45:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Note that the ISA extensions document revision 037 doesn't specify
exception behavior for ModRM.mod == 0b11; assuming #UD here.

No tests are being added to the harness - this would be quite hard,
we can't just issue the insns against RAM. Their similarity with
MOVDIR64B should have the test case there be god enough to cover any
fundamental flaws.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
TBD: This doesn't (can't) consult PASID translation tables yet, as we
     have no VMX code for this so far. I guess for this we will want to
     replace the direct ->read_msr(MSR_IA32_PASID, ...) with a new
     ->read_pasid() hook.
---
v6: Re-base.
v5: New.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -250,13 +250,14 @@ $(BASEDIR)/include/asm-x86/asm-macros.h:
 # sure we pick up changes when the compiler used has changed.)
 ifeq ($(MAKECMDGOALS),asm-offsets.s)
 
-as-ISA-list := CLWB EPT FSGSBASE INVPCID MOVDIR RDRAND RDSEED SSE4_2 VMX XSAVEOPT
+as-ISA-list := CLWB ENQCMD EPT FSGSBASE INVPCID MOVDIR RDRAND RDSEED SSE4_2 VMX XSAVEOPT
 
 CLWB-insn	:= clwb (%rax)
 EPT-insn	:= invept (%rax),%rax
 FSGSBASE-insn	:= rdfsbase %rax
 INVPCID-insn	:= invpcid (%rax),%rax
 MOVDIR-insn	:= movdiri %rax,(%rax)
+ENQCMD-insn	:= enqcmd (%rax),%rax
 RDRAND-insn	:= rdrand %eax
 RDSEED-insn	:= rdseed %eax
 SSE4_2-insn	:= crc32 %eax,%eax
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -854,6 +854,7 @@ struct x86_emulate_state {
         rmw_xor,
     } rmw;
     enum {
+        blk_enqcmd,
         blk_movdir,
     } blk;
     uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
@@ -900,6 +901,7 @@ typedef union {
     uint64_t __attribute__ ((aligned(16))) xmm[2];
     uint64_t __attribute__ ((aligned(32))) ymm[4];
     uint64_t __attribute__ ((aligned(64))) zmm[8];
+    uint32_t data32[16];
 } mmval_t;
 
 /*
@@ -1921,6 +1923,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_rdpid()       (ctxt->cpuid->feat.rdpid)
 #define vcpu_has_movdiri()     (ctxt->cpuid->feat.movdiri)
 #define vcpu_has_movdir64b()   (ctxt->cpuid->feat.movdir64b)
+#define vcpu_has_enqcmd()      (ctxt->cpuid->feat.enqcmd)
 #define vcpu_has_avx512_4vnniw() (ctxt->cpuid->feat.avx512_4vnniw)
 #define vcpu_has_avx512_4fmaps() (ctxt->cpuid->feat.avx512_4fmaps)
 #define vcpu_has_avx512_bf16() (ctxt->cpuid->feat.avx512_bf16)
@@ -10197,6 +10200,36 @@ x86_emulate(
         state->simd_size = simd_none;
         break;
 
+    case X86EMUL_OPC_F2(0x0f38, 0xf8): /* enqcmd r,m512 */
+    case X86EMUL_OPC_F3(0x0f38, 0xf8): /* enqcmds r,m512 */
+        host_and_vcpu_must_have(enqcmd);
+        generate_exception_if(ea.type != OP_MEM, EXC_UD);
+        generate_exception_if(vex.pfx != vex_f2 && !mode_ring0(), EXC_GP, 0);
+        src.val = truncate_ea(*dst.reg);
+        generate_exception_if(!is_aligned(x86_seg_es, src.val, 64, ctxt, ops),
+                              EXC_GP, 0);
+        fail_if(!ops->blk);
+        BUILD_BUG_ON(sizeof(*mmvalp) < 64);
+        if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp, 64,
+                             ctxt)) != X86EMUL_OKAY )
+            goto done;
+        if ( vex.pfx == vex_f2 ) /* enqcmd */
+        {
+            fail_if(!ops->read_msr);
+            if ( (rc = ops->read_msr(MSR_IA32_PASID,
+                                     &msr_val, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            generate_exception_if(!(msr_val & PASID_VALID), EXC_GP, 0);
+            mmvalp->data32[0] = MASK_EXTR(msr_val, PASID_PASID_MASK);
+        }
+        mmvalp->data32[0] &= ~0x7ff00000;
+        state->blk = blk_enqcmd;
+        if ( (rc = ops->blk(x86_seg_es, src.val, mmvalp, 64, &_regs.eflags,
+                            state, ctxt)) != X86EMUL_OKAY )
+            goto done;
+        state->simd_size = simd_none;
+        break;
+
     case X86EMUL_OPC(0x0f38, 0xf9): /* movdiri mem,r */
         host_and_vcpu_must_have(movdiri);
         generate_exception_if(dst.type != OP_MEM, EXC_UD);
@@ -11477,11 +11510,36 @@ int x86_emul_blk(
 {
     switch ( state->blk )
     {
+        bool zf;
+
         /*
          * Throughout this switch(), memory clobbers are used to compensate
          * that other operands may not properly express the (full) memory
          * ranges covered.
          */
+    case blk_enqcmd:
+        ASSERT(bytes == 64);
+        if ( ((unsigned long)ptr & 0x3f) )
+        {
+            ASSERT_UNREACHABLE();
+            return X86EMUL_UNHANDLEABLE;
+        }
+        *eflags &= ~EFLAGS_MASK;
+#ifdef HAVE_AS_ENQCMD
+        asm ( "enqcmds (%[src]), %[dst]" ASM_FLAG_OUT(, "; setz %0")
+              : [zf] ASM_FLAG_OUT("=@ccz", "=qm") (zf)
+              : [src] "r" (data), [dst] "r" (ptr) : "memory" );
+#else
+        /* enqcmds (%rsi), %rdi */
+        asm ( ".byte 0xf3, 0x0f, 0x38, 0xf8, 0x3e"
+              ASM_FLAG_OUT(, "; setz %[zf]")
+              : [zf] ASM_FLAG_OUT("=@ccz", "=qm") (zf)
+              : "S" (data), "D" (ptr) : "memory" );
+#endif
+        if ( zf )
+            *eflags |= X86_EFLAGS_ZF;
+        break;
+
     case blk_movdir:
         switch ( bytes )
         {
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -122,6 +122,7 @@
 #define cpu_has_rdpid           boot_cpu_has(X86_FEATURE_RDPID)
 #define cpu_has_movdiri         boot_cpu_has(X86_FEATURE_MOVDIRI)
 #define cpu_has_movdir64b       boot_cpu_has(X86_FEATURE_MOVDIR64B)
+#define cpu_has_enqcmd          boot_cpu_has(X86_FEATURE_ENQCMD)
 
 /* CPUID level 0x80000007.edx */
 #define cpu_has_itsc            boot_cpu_has(X86_FEATURE_ITSC)
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -412,6 +412,10 @@
 #define MSR_IA32_TSC_DEADLINE		0x000006E0
 #define MSR_IA32_ENERGY_PERF_BIAS	0x000001b0
 
+#define MSR_IA32_PASID			0x00000d93
+#define  PASID_PASID_MASK		0x000fffff
+#define  PASID_VALID			0x80000000
+
 /* Platform Shared Resource MSRs */
 #define MSR_IA32_CMT_EVTSEL		0x00000c8d
 #define MSR_IA32_CMT_EVTSEL_UE_MASK	0x0000ffff
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -239,6 +239,7 @@ XEN_CPUFEATURE(RDPID,         6*32+22) /
 XEN_CPUFEATURE(CLDEMOTE,      6*32+25) /*A  CLDEMOTE instruction */
 XEN_CPUFEATURE(MOVDIRI,       6*32+27) /*A  MOVDIRI instruction */
 XEN_CPUFEATURE(MOVDIR64B,     6*32+28) /*A  MOVDIR64B instruction */
+XEN_CPUFEATURE(ENQCMD,        6*32+29) /*   ENQCMD{,S} instructions */
 
 /* AMD-defined CPU features, CPUID level 0x80000007.edx, word 7 */
 XEN_CPUFEATURE(ITSC,          7*32+ 8) /*   Invariant TSC */


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:46:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOK1h-00059w-AG; Tue, 14 Apr 2020 11:46:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOK1f-00059g-Gg
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:46:47 +0000
X-Inumbo-ID: 9e86310e-7e45-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9e86310e-7e45-11ea-9e09-bc764e2007e4;
 Tue, 14 Apr 2020 11:46:47 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3812AAC44;
 Tue, 14 Apr 2020 11:46:45 +0000 (UTC)
Subject: [PATCH v6 05/10] x86/HVM: scale MPERF values reported to guests (on
 AMD)
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <d37edec9-5a87-e095-18d8-6b4d3fa8dced@suse.com>
Date: Tue, 14 Apr 2020 13:46:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

AMD's PM specifies that MPERF (and its r/o counterpart) reads are
affected by the TSC ratio. Hence when processing such reads in software
we too should scale the values. While we don't currently (yet) expose
the underlying feature flags, besides us allowing the MSRs to be read
nevertheless, RDPRU is going to expose the values even to user space.

Furthermore, due to the not exposed feature flags, this change has the
effect of making properly inaccessible (for reads) the two MSRs.

Note that writes to MPERF (and APERF) continue to be unsupported.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: New.
---
I did consider whether to put the code in guest_rdmsr() instead, but
decided that it's better to have it next to TSC handling.

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3454,6 +3454,22 @@ int hvm_msr_read_intercept(unsigned int
         *msr_content = v->arch.hvm.msr_tsc_adjust;
         break;
 
+    case MSR_MPERF_RD_ONLY:
+        if ( !d->arch.cpuid->extd.efro )
+        {
+            goto gp_fault;
+
+    case MSR_IA32_MPERF:
+            if ( !(d->arch.cpuid->basic.raw[6].c &
+                   CPUID6_ECX_APERFMPERF_CAPABILITY) )
+                goto gp_fault;
+        }
+        if ( rdmsr_safe(msr, *msr_content) )
+            goto gp_fault;
+        if ( d->arch.cpuid->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) )
+            *msr_content = hvm_get_guest_tsc_fixed(v, *msr_content);
+        break;
+
     case MSR_APIC_BASE:
         *msr_content = vcpu_vlapic(v)->hw.apic_base_msr;
         break;
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -397,6 +397,9 @@
 #define MSR_IA32_MPERF			0x000000e7
 #define MSR_IA32_APERF			0x000000e8
 
+#define MSR_MPERF_RD_ONLY		0xc00000e7
+#define MSR_APERF_RD_ONLY		0xc00000e8
+
 #define MSR_IA32_THERM_CONTROL		0x0000019a
 #define MSR_IA32_THERM_INTERRUPT	0x0000019b
 #define MSR_IA32_THERM_STATUS		0x0000019c



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:47:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOK2R-0005HM-Me; Tue, 14 Apr 2020 11:47:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qlbo=56=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOK2Q-0005HF-Uo
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:47:35 +0000
X-Inumbo-ID: ba31b342-7e45-11ea-8927-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ba31b342-7e45-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 11:47:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=34TO0mjplumC1gstw+fEa1GX6JGzZCE1txswtzfEfmk=; b=MmWC2E31PbEUkUPLnyFDeJHRP
 UaJK0VSmvR2r8qq+NYgf5Skm19Kw4cfWzFUdTq2nQNEzzdvNbCbWXDiB+UcOvuK/LORoCSNgSv3Ut
 ce3cpsmx19C12TnvtwcWk8kGTi1bRMruIUMAGDkk1P1drPk4ZZorZqtiCxB9nknTqdqMM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOK2O-0000Ex-QN; Tue, 14 Apr 2020 11:47:32 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOK2O-0004ES-II; Tue, 14 Apr 2020 11:47:32 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOK2O-0000EF-HC; Tue, 14 Apr 2020 11:47:32 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149642-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149642: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
X-Osstest-Versions-That: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 14 Apr 2020 11:47:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds   16 guest-localmigrate fail in 149634 pass in 149642
 test-amd64-amd64-examine      4 memdisk-try-append         fail pass in 149634

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149627
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149634
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149634
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149634
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149634
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149634
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149634
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149634
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149634
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149634
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3
baseline version:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3

Last test of basis   149642  2020-04-14 01:51:29 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:48:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOK2x-0005N4-8Z; Tue, 14 Apr 2020 11:48:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOK2v-0005Mn-HQ
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:48:05 +0000
X-Inumbo-ID: cc4e580a-7e45-11ea-8927-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cc4e580a-7e45-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 11:48:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3D8CDADFE;
 Tue, 14 Apr 2020 11:48:02 +0000 (UTC)
Subject: [PATCH v6 06/10] x86emul: support RDPRU
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <6b03308b-3492-de1a-6847-37ceab7d9684@suse.com>
Date: Tue, 14 Apr 2020 13:48:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While the PM doesn't say so, this assumes that the MPERF value read this
way gets scaled similarly to its reading through RDMSR.

Also introduce the SVM related constants at this occasion.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v6: Re-base.
v5: The CPUID field used is just 8 bits wide.
v4: Add GENERAL2_INTERCEPT_RDPRU and VMEXIT_RDPRU enumerators. Fold
    handling of out of bounds indexes into switch(). Avoid
    recalculate_misc() clobbering what recalculate_cpu_policy() has
    done. Re-base.
v3: New.
---
RFC: Andrew promised to take care of the CPUID side of this; re-base
     over his work once available.

--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -260,6 +260,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
 
         {"clzero",       0x80000008, NA, CPUID_REG_EBX,  0,  1},
         {"rstr-fp-err-ptrs", 0x80000008, NA, CPUID_REG_EBX, 2, 1},
+        {"rdpru",        0x80000008, NA, CPUID_REG_EBX,  4,  1},
         {"wbnoinvd",     0x80000008, NA, CPUID_REG_EBX,  9,  1},
         {"ibpb",         0x80000008, NA, CPUID_REG_EBX, 12,  1},
         {"ppin",         0x80000008, NA, CPUID_REG_EBX, 23,  1},
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -147,6 +147,8 @@ static const char *const str_e8b[32] =
     [ 0] = "clzero",
     [ 2] = "rstr-fp-err-ptrs",
 
+    [ 4] = "rdpru",
+
     /* [ 8] */            [ 9] = "wbnoinvd",
 
     [12] = "ibpb",
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -683,6 +683,13 @@ static int read_msr(
 {
     switch ( reg )
     {
+    case 0x000000e8: /* APERF */
+    case 0xc00000e8: /* APERF_RD_ONLY */
+#define APERF_LO_VALUE 0xAEAEAEAE
+#define APERF_HI_VALUE 0xEAEAEAEA
+        *val = ((uint64_t)APERF_HI_VALUE << 32) | APERF_LO_VALUE;
+        return X86EMUL_OKAY;
+
     case 0xc0000080: /* EFER */
         *val = ctxt->addr_size > 32 ? 0x500 /* LME|LMA */ : 0;
         return X86EMUL_OKAY;
@@ -2399,6 +2406,30 @@ int main(int argc, char **argv)
 
     emulops.blk = NULL;
 
+    printf("%-40s", "Testing rdpru...");
+    instr[0] = 0x0f; instr[1] = 0x01; instr[2] = 0xfd;
+    regs.eip = (unsigned long)&instr[0];
+    regs.ecx = 1;
+    regs.eflags = EFLAGS_ALWAYS_SET;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.eax != APERF_LO_VALUE) || (regs.edx != APERF_HI_VALUE) ||
+         !(regs.eflags & X86_EFLAGS_CF) ||
+         (regs.eip != (unsigned long)&instr[3]) )
+        goto fail;
+    if ( ctxt.cpuid->extd.rdpru_max < 0xffff )
+    {
+        regs.eip = (unsigned long)&instr[0];
+        regs.ecx = ctxt.cpuid->extd.rdpru_max + 1;
+        regs.eflags = EFLAGS_ALWAYS_SET | X86_EFLAGS_CF;
+        rc = x86_emulate(&ctxt, &emulops);
+        if ( (rc != X86EMUL_OKAY) || regs.eax || regs.edx ||
+             (regs.eflags & X86_EFLAGS_CF) ||
+             (regs.eip != (unsigned long)&instr[3]) )
+            goto fail;
+    }
+    printf("okay\n");
+
     printf("%-40s", "Testing movq %mm3,(%ecx)...");
     if ( stack_exec && cpu_has_mmx )
     {
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -77,6 +77,8 @@ bool emul_test_init(void)
     cp.feat.avx512pf = cp.feat.avx512f;
     cp.feat.rdpid = true;
     cp.extd.clzero = true;
+    cp.extd.rdpru = true;
+    cp.extd.rdpru_max = 1;
 
     if ( cpu_has_xsave )
     {
@@ -149,11 +151,11 @@ int emul_test_cpuid(
     }
 
     /*
-     * The emulator doesn't itself use CLZERO, so we can always run the
+     * The emulator doesn't itself use CLZERO/RDPRU, so we can always run the
      * respective test(s).
      */
     if ( leaf == 0x80000008 )
-        res->b |= 1U << 0;
+        res->b |= (1U << 0) | (1U << 4);
 
     return X86EMUL_OKAY;
 }
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -243,8 +243,6 @@ static void recalculate_misc(struct cpui
     /* Most of Power/RAS hidden from guests. */
     p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
 
-    p->extd.raw[0x8].d = 0;
-
     switch ( p->x86_vendor )
     {
     case X86_VENDOR_INTEL:
@@ -263,6 +261,7 @@ static void recalculate_misc(struct cpui
 
         p->extd.raw[0x8].a &= 0x0000ffff;
         p->extd.raw[0x8].c = 0;
+        p->extd.raw[0x8].d = 0;
         break;
 
     case X86_VENDOR_AMD:
@@ -281,6 +280,7 @@ static void recalculate_misc(struct cpui
 
         p->extd.raw[0x8].a &= 0x0000ffff; /* GuestMaxPhysAddr hidden. */
         p->extd.raw[0x8].c &= 0x0003f0ff;
+        p->extd.raw[0x8].d &= 0xffff0000;
 
         p->extd.raw[0x9] = EMPTY_LEAF;
 
@@ -643,6 +643,11 @@ void recalculate_cpuid_policy(struct dom
 
     p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
 
+    if ( p->extd.rdpru )
+        p->extd.rdpru_max = min(p->extd.rdpru_max, max->extd.rdpru_max);
+    else
+        p->extd.rdpru_max = 0;
+
     recalculate_xstate(p);
     recalculate_misc(p);
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1889,6 +1889,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_fma4()        (ctxt->cpuid->extd.fma4)
 #define vcpu_has_tbm()         (ctxt->cpuid->extd.tbm)
 #define vcpu_has_clzero()      (ctxt->cpuid->extd.clzero)
+#define vcpu_has_rdpru()       (ctxt->cpuid->extd.rdpru)
 #define vcpu_has_wbnoinvd()    (ctxt->cpuid->extd.wbnoinvd)
 
 #define vcpu_has_bmi1()        (ctxt->cpuid->feat.bmi1)
@@ -5725,6 +5726,50 @@ x86_emulate(
                 limit -= sizeof(zero);
             }
             break;
+
+        case 0xfd: /* rdpru */
+            vcpu_must_have(rdpru);
+
+            if ( !mode_ring0() )
+            {
+                fail_if(!ops->read_cr);
+                if ( (rc = ops->read_cr(4, &cr4, ctxt)) != X86EMUL_OKAY )
+                    goto done;
+                generate_exception_if(cr4 & X86_CR4_TSD, EXC_UD);
+            }
+
+            switch ( _regs.ecx | -(_regs.ecx > ctxt->cpuid->extd.rdpru_max) )
+            {
+            case 0:  n = MSR_IA32_MPERF; break;
+            case 1:  n = MSR_IA32_APERF; break;
+            default: n = 0; break;
+            }
+
+            _regs.eflags &= ~EFLAGS_MASK;
+            if ( n )
+            {
+                fail_if(!ops->read_msr);
+                switch ( rc = ops->read_msr(n, &msr_val, ctxt) )
+                {
+                case X86EMUL_OKAY:
+                    _regs.eflags |= X86_EFLAGS_CF;
+                    break;
+
+                case X86EMUL_EXCEPTION:
+                    x86_emul_reset_event(ctxt);
+                    rc = X86EMUL_OKAY;
+                    break;
+
+                default:
+                    goto done;
+                }
+            }
+
+            if ( !(_regs.eflags & X86_EFLAGS_CF) )
+                msr_val = 0;
+            _regs.r(dx) = msr_val >> 32;
+            _regs.r(ax) = (uint32_t)msr_val;
+            break;
         }
 
 #define _GRP7(mod, reg) \
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -74,7 +74,8 @@ enum GenericIntercept2bits
     GENERAL2_INTERCEPT_MONITOR = 1 << 10,
     GENERAL2_INTERCEPT_MWAIT   = 1 << 11,
     GENERAL2_INTERCEPT_MWAIT_CONDITIONAL = 1 << 12,
-    GENERAL2_INTERCEPT_XSETBV  = 1 << 13
+    GENERAL2_INTERCEPT_XSETBV  = 1 << 13,
+    GENERAL2_INTERCEPT_RDPRU   = 1 << 14,
 };
 
 
@@ -298,6 +299,7 @@ enum VMEXIT_EXITCODE
     VMEXIT_MWAIT            = 139, /* 0x8b */
     VMEXIT_MWAIT_CONDITIONAL= 140, /* 0x8c */
     VMEXIT_XSETBV           = 141, /* 0x8d */
+    VMEXIT_RDPRU            = 142, /* 0x8e */
     VMEXIT_NPF              = 1024, /* 0x400, nested paging fault */
     VMEXIT_INVALID          =  -1
 };
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -248,6 +248,7 @@ XEN_CPUFEATURE(EFRO,          7*32+10) /
 /* AMD-defined CPU features, CPUID level 0x80000008.ebx, word 8 */
 XEN_CPUFEATURE(CLZERO,        8*32+ 0) /*A  CLZERO instruction */
 XEN_CPUFEATURE(RSTR_FP_ERR_PTRS, 8*32+ 2) /*A  (F)X{SAVE,RSTOR} always saves/restores FPU Error pointers */
+XEN_CPUFEATURE(RDPRU,         8*32+ 4) /*A  RDPRU instruction */
 XEN_CPUFEATURE(WBNOINVD,      8*32+ 9) /*   WBNOINVD instruction */
 XEN_CPUFEATURE(IBPB,          8*32+12) /*A  IBPB support only (no IBRS, used by AMD) */
 XEN_CPUFEATURE(AMD_PPIN,      8*32+23) /*   Protected Processor Inventory Number */
--- a/xen/include/xen/lib/x86/cpuid.h
+++ b/xen/include/xen/lib/x86/cpuid.h
@@ -263,7 +263,7 @@ struct cpuid_policy
                 struct { DECL_BITFIELD(e8b); };
             };
             uint32_t nc:8, :4, apic_id_size:4, :16;
-            uint32_t /* d */:32;
+            uint8_t :8, :8, rdpru_max, :8;
         };
     } extd;
 



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:48:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOK3Q-0005SE-KL; Tue, 14 Apr 2020 11:48:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOK3P-0005S1-7f
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:48:35 +0000
X-Inumbo-ID: de812ad4-7e45-11ea-8927-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id de812ad4-7e45-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 11:48:34 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C1A54AD63;
 Tue, 14 Apr 2020 11:48:32 +0000 (UTC)
Subject: [PATCH v6 07/10] x86/HVM: don't needlessly intercept APERF/MPERF/TSC
 MSR reads
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <622f62e7-0dad-cca0-ed51-a84728d161c9@suse.com>
Date: Tue, 14 Apr 2020 13:48:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

If the hardware can handle accesses, we should allow it to do so. This
way we can expose EFRO to HVM guests, and "all" that's left for exposing
APERF/MPERF is to figure out how to handle writes to these MSRs. (Note
that the leaf 6 guest CPUID checks will evaluate to false for now, as
recalculate_misc() zaps the entire leaf.)

For TSC the intercepts are made mirror the RDTSC ones.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
---
v4: Make TSC intercepts mirror RDTSC ones. Re-base.
v3: New.

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -595,6 +595,7 @@ static void svm_cpuid_policy_changed(str
     struct vmcb_struct *vmcb = svm->vmcb;
     const struct cpuid_policy *cp = v->domain->arch.cpuid;
     u32 bitmap = vmcb_get_exception_intercepts(vmcb);
+    unsigned int mode;
 
     if ( opt_hvm_fep ||
          (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
@@ -607,6 +608,17 @@ static void svm_cpuid_policy_changed(str
     /* Give access to MSR_PRED_CMD if the guest has been told about it. */
     svm_intercept_msr(v, MSR_PRED_CMD,
                       cp->extd.ibpb ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW);
+
+    /* Allow direct reads from APERF/MPERF if permitted by the policy. */
+    mode = cp->basic.raw[6].c & CPUID6_ECX_APERFMPERF_CAPABILITY
+           ? MSR_INTERCEPT_WRITE : MSR_INTERCEPT_RW;
+    svm_intercept_msr(v, MSR_IA32_APERF, mode);
+    svm_intercept_msr(v, MSR_IA32_MPERF, mode);
+
+    /* Allow direct access to their r/o counterparts if permitted. */
+    mode = cp->extd.efro ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW;
+    svm_intercept_msr(v, MSR_APERF_RD_ONLY, mode);
+    svm_intercept_msr(v, MSR_MPERF_RD_ONLY, mode);
 }
 
 void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state)
@@ -860,7 +872,10 @@ static void svm_set_rdtsc_exiting(struct
     {
         general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
         general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
+        svm_enable_intercept_for_msr(v, MSR_IA32_TSC);
     }
+    else
+        svm_intercept_msr(v, MSR_IA32_TSC, MSR_INTERCEPT_WRITE);
 
     vmcb_set_general1_intercepts(vmcb, general1_intercepts);
     vmcb_set_general2_intercepts(vmcb, general2_intercepts);
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -108,6 +108,7 @@ static int construct_vmcb(struct vcpu *v
     {
         vmcb->_general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
         vmcb->_general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
+        svm_intercept_msr(v, MSR_IA32_TSC, MSR_INTERCEPT_WRITE);
     }
 
     /* Guest segment limits. */
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1141,8 +1141,13 @@ static int construct_vmcs(struct vcpu *v
         vmx_clear_msr_intercept(v, MSR_IA32_SYSENTER_CS, VMX_MSR_RW);
         vmx_clear_msr_intercept(v, MSR_IA32_SYSENTER_ESP, VMX_MSR_RW);
         vmx_clear_msr_intercept(v, MSR_IA32_SYSENTER_EIP, VMX_MSR_RW);
+
+        if ( !(v->arch.hvm.vmx.exec_control & CPU_BASED_RDTSC_EXITING) )
+            vmx_clear_msr_intercept(v, MSR_IA32_TSC, VMX_MSR_R);
+
         if ( paging_mode_hap(d) && (!is_iommu_enabled(d) || iommu_snoop) )
             vmx_clear_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW);
+
         if ( (vmexit_ctl & VM_EXIT_CLEAR_BNDCFGS) &&
              (vmentry_ctl & VM_ENTRY_LOAD_BNDCFGS) )
             vmx_clear_msr_intercept(v, MSR_IA32_BNDCFGS, VMX_MSR_RW);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -585,6 +585,18 @@ static void vmx_cpuid_policy_changed(str
         vmx_clear_msr_intercept(v, MSR_FLUSH_CMD, VMX_MSR_RW);
     else
         vmx_set_msr_intercept(v, MSR_FLUSH_CMD, VMX_MSR_RW);
+
+    /* Allow direct reads from APERF/MPERF if permitted by the policy. */
+    if ( cp->basic.raw[6].c & CPUID6_ECX_APERFMPERF_CAPABILITY )
+    {
+        vmx_clear_msr_intercept(v, MSR_IA32_APERF, VMX_MSR_R);
+        vmx_clear_msr_intercept(v, MSR_IA32_MPERF, VMX_MSR_R);
+    }
+    else
+    {
+        vmx_set_msr_intercept(v, MSR_IA32_APERF, VMX_MSR_R);
+        vmx_set_msr_intercept(v, MSR_IA32_MPERF, VMX_MSR_R);
+    }
 }
 
 int vmx_guest_x86_mode(struct vcpu *v)
@@ -1250,7 +1262,12 @@ static void vmx_set_rdtsc_exiting(struct
     vmx_vmcs_enter(v);
     v->arch.hvm.vmx.exec_control &= ~CPU_BASED_RDTSC_EXITING;
     if ( enable )
+    {
         v->arch.hvm.vmx.exec_control |= CPU_BASED_RDTSC_EXITING;
+        vmx_set_msr_intercept(v, MSR_IA32_TSC, VMX_MSR_R);
+    }
+    else
+        vmx_clear_msr_intercept(v, MSR_IA32_TSC, VMX_MSR_R);
     vmx_update_cpu_exec_control(v);
     vmx_vmcs_exit(v);
 }
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -243,7 +243,7 @@ XEN_CPUFEATURE(ENQCMD,        6*32+29) /
 
 /* AMD-defined CPU features, CPUID level 0x80000007.edx, word 7 */
 XEN_CPUFEATURE(ITSC,          7*32+ 8) /*   Invariant TSC */
-XEN_CPUFEATURE(EFRO,          7*32+10) /*   APERF/MPERF Read Only interface */
+XEN_CPUFEATURE(EFRO,          7*32+10) /*S  APERF/MPERF Read Only interface */
 
 /* AMD-defined CPU features, CPUID level 0x80000008.ebx, word 8 */
 XEN_CPUFEATURE(CLZERO,        8*32+ 0) /*A  CLZERO instruction */



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:49:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOK3s-0005Xd-Vv; Tue, 14 Apr 2020 11:49:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOK3r-0005XM-Qp
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:49:03 +0000
X-Inumbo-ID: efa80e4a-7e45-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id efa80e4a-7e45-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 11:49:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 89B44ADFE;
 Tue, 14 Apr 2020 11:49:01 +0000 (UTC)
Subject: [PATCH v6 08/10] x86emul: support SERIALIZE
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <02c670c9-48c4-fa70-47a6-1f8a7ed21fb6@suse.com>
Date: Tue, 14 Apr 2020 13:49:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

... enabling its use by all guest kinds at the same time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v6: New.

--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -213,6 +213,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
         {"avx512-4vnniw",0x00000007,  0, CPUID_REG_EDX,  2,  1},
         {"avx512-4fmaps",0x00000007,  0, CPUID_REG_EDX,  3,  1},
         {"md-clear",     0x00000007,  0, CPUID_REG_EDX, 10,  1},
+        {"serialize",    0x00000007,  0, CPUID_REG_EDX, 14,  1},
         {"ibrsb",        0x00000007,  0, CPUID_REG_EDX, 26,  1},
         {"stibp",        0x00000007,  0, CPUID_REG_EDX, 27,  1},
         {"l1d-flush",    0x00000007,  0, CPUID_REG_EDX, 28,  1},
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -163,6 +163,7 @@ static const char *const str_7d0[32] =
 
     [10] = "md-clear",
     /* 12 */                [13] = "tsx-force-abort",
+    [14] = "serialize",
 
     [18] = "pconfig",
 
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -158,6 +158,7 @@ static inline bool xcr0_mask(uint64_t ma
 #define cpu_has_movdir64b  cp.feat.movdir64b
 #define cpu_has_avx512_4vnniw (cp.feat.avx512_4vnniw && xcr0_mask(0xe6))
 #define cpu_has_avx512_4fmaps (cp.feat.avx512_4fmaps && xcr0_mask(0xe6))
+#define cpu_has_serialize  cp.feat.serialize
 #define cpu_has_avx512_bf16 (cp.feat.avx512_bf16 && xcr0_mask(0xe6))
 
 #define cpu_has_xgetbv1   (cpu_has_xsave && cp.xstate.xgetbv1)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1927,6 +1927,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_enqcmd()      (ctxt->cpuid->feat.enqcmd)
 #define vcpu_has_avx512_4vnniw() (ctxt->cpuid->feat.avx512_4vnniw)
 #define vcpu_has_avx512_4fmaps() (ctxt->cpuid->feat.avx512_4fmaps)
+#define vcpu_has_serialize()   (ctxt->cpuid->feat.serialize)
 #define vcpu_has_avx512_bf16() (ctxt->cpuid->feat.avx512_bf16)
 
 #define vcpu_must_have(feat) \
@@ -5660,6 +5661,18 @@ x86_emulate(
                 goto done;
             break;
 
+        case 0xe8:
+            switch ( vex.pfx )
+            {
+            case vex_none: /* serialize */
+                host_and_vcpu_must_have(serialize);
+                asm volatile ( ".byte 0x0f, 0x01, 0xe8" );
+                break;
+            default:
+                goto unimplemented_insn;
+            }
+            break;
+
         case 0xf8: /* swapgs */
             generate_exception_if(!mode_64bit(), EXC_UD);
             generate_exception_if(!mode_ring0(), EXC_GP, 0);
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -131,6 +131,7 @@
 #define cpu_has_avx512_4vnniw   boot_cpu_has(X86_FEATURE_AVX512_4VNNIW)
 #define cpu_has_avx512_4fmaps   boot_cpu_has(X86_FEATURE_AVX512_4FMAPS)
 #define cpu_has_tsx_force_abort boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)
+#define cpu_has_serialize       boot_cpu_has(X86_FEATURE_SERIALIZE)
 
 /* CPUID level 0x00000007:1.eax */
 #define cpu_has_avx512_bf16     boot_cpu_has(X86_FEATURE_AVX512_BF16)
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -258,6 +258,7 @@ XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /
 XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation Single Precision */
 XEN_CPUFEATURE(MD_CLEAR,      9*32+10) /*A  VERW clears microarchitectural buffers */
 XEN_CPUFEATURE(TSX_FORCE_ABORT, 9*32+13) /* MSR_TSX_FORCE_ABORT.RTM_ABORT */
+XEN_CPUFEATURE(SERIALIZE,     9*32+14) /*A  SERIALIZE insn */
 XEN_CPUFEATURE(IBRSB,         9*32+26) /*A  IBRS and IBPB support (used by Intel) */
 XEN_CPUFEATURE(STIBP,         9*32+27) /*A  STIBP */
 XEN_CPUFEATURE(L1D_FLUSH,     9*32+28) /*S  MSR_FLUSH_CMD and L1D flush. */



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:49:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOK4D-0005c8-DI; Tue, 14 Apr 2020 11:49:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOK4C-0005bk-2d
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:49:24 +0000
X-Inumbo-ID: fb9f89d0-7e45-11ea-8927-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fb9f89d0-7e45-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 11:49:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9A184AD63;
 Tue, 14 Apr 2020 11:49:21 +0000 (UTC)
Subject: [PATCH v6 09/10] x86emul: support X{SUS,RES}LDTRK
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <d34462be-84ef-9bf8-6da5-82087f826e72@suse.com>
Date: Tue, 14 Apr 2020 13:49:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

There's nothing to be done by the emulator, as we unconditionally abort
any XBEGIN.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v6: New.

--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -207,6 +207,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
         {"avx512-vnni",  0x00000007,  0, CPUID_REG_ECX, 11,  1},
         {"avx512-bitalg",0x00000007,  0, CPUID_REG_ECX, 12,  1},
         {"avx512-vpopcntdq",0x00000007,0,CPUID_REG_ECX, 14,  1},
+        {"tsxldtrk",     0x00000007,  0, CPUID_REG_ECX, 16,  1},
         {"rdpid",        0x00000007,  0, CPUID_REG_ECX, 22,  1},
         {"cldemote",     0x00000007,  0, CPUID_REG_ECX, 25,  1},
 
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -128,6 +128,7 @@ static const char *const str_7c0[32] =
     [10] = "vpclmulqdq",       [11] = "avx512_vnni",
     [12] = "avx512_bitalg",
     [14] = "avx512_vpopcntdq",
+    [16] = "tsxldtrk",
 
     [22] = "rdpid",
     /* 24 */                   [25] = "cldemote",
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1921,6 +1921,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_avx512_vnni() (ctxt->cpuid->feat.avx512_vnni)
 #define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
 #define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
+#define vcpu_has_tsxldtrk()    (ctxt->cpuid->feat.tsxldtrk)
 #define vcpu_has_rdpid()       (ctxt->cpuid->feat.rdpid)
 #define vcpu_has_movdiri()     (ctxt->cpuid->feat.movdiri)
 #define vcpu_has_movdir64b()   (ctxt->cpuid->feat.movdir64b)
@@ -5668,6 +5669,20 @@ x86_emulate(
                 host_and_vcpu_must_have(serialize);
                 asm volatile ( ".byte 0x0f, 0x01, 0xe8" );
                 break;
+            case vex_f2: /* xsusldtrk */
+                vcpu_must_have(tsxldtrk);
+                break;
+            default:
+                goto unimplemented_insn;
+            }
+            break;
+
+        case 0xe9:
+            switch ( vex.pfx )
+            {
+            case vex_f2: /* xresldtrk */
+                vcpu_must_have(tsxldtrk);
+                break;
             default:
                 goto unimplemented_insn;
             }
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -235,6 +235,7 @@ XEN_CPUFEATURE(VPCLMULQDQ,    6*32+10) /
 XEN_CPUFEATURE(AVX512_VNNI,   6*32+11) /*A  Vector Neural Network Instrs */
 XEN_CPUFEATURE(AVX512_BITALG, 6*32+12) /*A  Support for VPOPCNT[B,W] and VPSHUFBITQMB */
 XEN_CPUFEATURE(AVX512_VPOPCNTDQ, 6*32+14) /*A  POPCNT for vectors of DW/QW */
+XEN_CPUFEATURE(TSXLDTRK,      6*32+16) /*A  TSX load tracking suspend/resume insns */
 XEN_CPUFEATURE(RDPID,         6*32+22) /*A  RDPID instruction */
 XEN_CPUFEATURE(CLDEMOTE,      6*32+25) /*A  CLDEMOTE instruction */
 XEN_CPUFEATURE(MOVDIRI,       6*32+27) /*A  MOVDIRI instruction */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -284,6 +284,9 @@ def crunch_numbers(state):
         # as dependent features simplifies Xen's logic, and prevents the guest
         # from seeing implausible configurations.
         IBRSB: [STIBP, SSBD],
+
+        # In principle the TSXLDTRK insns could also be considered independent.
+        RTM: [TSXLDTRK],
     }
 
     deep_features = tuple(sorted(deps.keys()))



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:49:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOK4Z-0005iJ-Pm; Tue, 14 Apr 2020 11:49:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOK4Y-0005i0-2q
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:49:46 +0000
X-Inumbo-ID: 08ab8462-7e46-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 08ab8462-7e46-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 11:49:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8398DAF69;
 Tue, 14 Apr 2020 11:49:43 +0000 (UTC)
Subject: [PATCH v6 10/10] x86emul: support MCOMMIT
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Message-ID: <e8868040-4982-140f-5023-154c7a67e8cf@suse.com>
Date: Tue, 14 Apr 2020 13:49:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The dependency on a new EFER bit implies that we need to set that bit
ourselves in order to be able to successfully invoke the insn.

Also once again introduce the SVM related constants at this occasion.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
RFC: The exact meaning of the PM stating "any errors encountered by
     those stores have been signaled to associated error logging
     resources" is unclear. Depending on what this entails, blindly
     enabling EFER.MCOMMIT may not be a good idea. Hence the RFC.
---
v6: Re-base.
v5: Re-base.
v4: New.

--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -263,6 +263,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
         {"clzero",       0x80000008, NA, CPUID_REG_EBX,  0,  1},
         {"rstr-fp-err-ptrs", 0x80000008, NA, CPUID_REG_EBX, 2, 1},
         {"rdpru",        0x80000008, NA, CPUID_REG_EBX,  4,  1},
+        {"mcommit",      0x80000008, NA, CPUID_REG_EBX,  8,  1},
         {"wbnoinvd",     0x80000008, NA, CPUID_REG_EBX,  9,  1},
         {"ibpb",         0x80000008, NA, CPUID_REG_EBX, 12,  1},
         {"ppin",         0x80000008, NA, CPUID_REG_EBX, 23,  1},
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -150,7 +150,7 @@ static const char *const str_e8b[32] =
 
     [ 4] = "rdpru",
 
-    /* [ 8] */            [ 9] = "wbnoinvd",
+    [ 8] = "mcommit",          [ 9] = "wbnoinvd",
 
     [12] = "ibpb",
 
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -798,6 +798,9 @@ static void init_amd(struct cpuinfo_x86
 		wrmsr(MSR_K7_HWCR, l, h);
 	}
 
+	if (cpu_has(c, X86_FEATURE_MCOMMIT))
+		write_efer(read_efer() | EFER_MCOMMIT);
+
 	/* Prevent TSC drift in non single-processor, single-core platforms. */
 	if ((smp_processor_id() == 1) && !cpu_has(c, X86_FEATURE_ITSC))
 		disable_c1_ramping();
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1889,6 +1889,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_fma4()        (ctxt->cpuid->extd.fma4)
 #define vcpu_has_tbm()         (ctxt->cpuid->extd.tbm)
 #define vcpu_has_clzero()      (ctxt->cpuid->extd.clzero)
+#define vcpu_has_mcommit()     (ctxt->cpuid->extd.mcommit)
 #define vcpu_has_rdpru()       (ctxt->cpuid->extd.rdpru)
 #define vcpu_has_wbnoinvd()    (ctxt->cpuid->extd.wbnoinvd)
 
@@ -5718,6 +5719,28 @@ x86_emulate(
             _regs.r(cx) = (uint32_t)msr_val;
             goto rdtsc;
 
+        case 0xfa: /* monitorx / mcommit */
+            if ( vex.pfx == vex_f3 )
+            {
+                bool cf;
+
+                host_and_vcpu_must_have(mcommit);
+                if ( !ops->read_msr ||
+                     ops->read_msr(MSR_EFER, &msr_val, ctxt) != X86EMUL_OKAY )
+                    msr_val = 0;
+                generate_exception_if(!(msr_val & EFER_MCOMMIT), EXC_UD);
+                memcpy(get_stub(stub),
+                       ((uint8_t[]){ 0xf3, 0x0f, 0x01, 0xfa, 0xc3 }), 5);
+                _regs.eflags &= ~EFLAGS_MASK;
+                invoke_stub("", ASM_FLAG_OUT(, "setc %[cf]"),
+                            [cf] ASM_FLAG_OUT("=@ccc", "=qm") (cf) : "i" (0));
+                if ( cf )
+                    _regs.eflags |= X86_EFLAGS_CF;
+                put_stub(stub);
+                goto done;
+            }
+            goto unrecognized_insn;
+
         case 0xfc: /* clzero */
         {
             unsigned long zero = 0;
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -133,6 +133,9 @@
 #define cpu_has_tsx_force_abort boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)
 #define cpu_has_serialize       boot_cpu_has(X86_FEATURE_SERIALIZE)
 
+/* CPUID level 0x80000008.ebx */
+#define cpu_has_mcommit         boot_cpu_has(X86_FEATURE_MCOMMIT)
+
 /* CPUID level 0x00000007:1.eax */
 #define cpu_has_avx512_bf16     boot_cpu_has(X86_FEATURE_AVX512_BF16)
 
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -78,6 +78,11 @@ enum GenericIntercept2bits
     GENERAL2_INTERCEPT_RDPRU   = 1 << 14,
 };
 
+/* general 3 intercepts */
+enum GenericIntercept3bits
+{
+    GENERAL3_INTERCEPT_MCOMMIT = 1 << 3,
+};
 
 /* control register intercepts */
 enum CRInterceptBits
@@ -300,6 +305,7 @@ enum VMEXIT_EXITCODE
     VMEXIT_MWAIT_CONDITIONAL= 140, /* 0x8c */
     VMEXIT_XSETBV           = 141, /* 0x8d */
     VMEXIT_RDPRU            = 142, /* 0x8e */
+    VMEXIT_MCOMMIT          = 163, /* 0xa3 */
     VMEXIT_NPF              = 1024, /* 0x400, nested paging fault */
     VMEXIT_INVALID          =  -1
 };
@@ -414,7 +420,8 @@ struct vmcb_struct {
     u32 _exception_intercepts;  /* offset 0x08 - cleanbit 0 */
     u32 _general1_intercepts;   /* offset 0x0C - cleanbit 0 */
     u32 _general2_intercepts;   /* offset 0x10 - cleanbit 0 */
-    u32 res01[10];
+    u32 _general3_intercepts;   /* offset 0x14 - cleanbit 0 */
+    u32 res01[9];
     u16 _pause_filter_thresh;   /* offset 0x3C - cleanbit 0 */
     u16 _pause_filter_count;    /* offset 0x3E - cleanbit 0 */
     u64 _iopm_base_pa;          /* offset 0x40 - cleanbit 1 */
@@ -611,6 +618,7 @@ VMCB_ACCESSORS(dr_intercepts, intercepts
 VMCB_ACCESSORS(exception_intercepts, intercepts)
 VMCB_ACCESSORS(general1_intercepts, intercepts)
 VMCB_ACCESSORS(general2_intercepts, intercepts)
+VMCB_ACCESSORS(general3_intercepts, intercepts)
 VMCB_ACCESSORS(pause_filter_count, intercepts)
 VMCB_ACCESSORS(pause_filter_thresh, intercepts)
 VMCB_ACCESSORS(tsc_offset, intercepts)
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -88,6 +88,7 @@
 #define _EFER_NX		11 /* No execute enable */
 #define _EFER_SVME		12 /* AMD: SVM enable */
 #define _EFER_FFXSE		14 /* AMD: Fast FXSAVE/FXRSTOR enable */
+#define _EFER_MCOMMIT		17 /* AMD: MCOMMIT insn enable */
 
 #define EFER_SCE		(1<<_EFER_SCE)
 #define EFER_LME		(1<<_EFER_LME)
@@ -95,9 +96,10 @@
 #define EFER_NX			(1<<_EFER_NX)
 #define EFER_SVME		(1<<_EFER_SVME)
 #define EFER_FFXSE		(1<<_EFER_FFXSE)
+#define EFER_MCOMMIT		(1<<_EFER_MCOMMIT)
 
 #define EFER_KNOWN_MASK		(EFER_SCE | EFER_LME | EFER_LMA | EFER_NX | \
-				 EFER_SVME | EFER_FFXSE)
+				 EFER_SVME | EFER_FFXSE | EFER_MCOMMIT)
 
 /* Intel MSRs. Some also available on other CPUs */
 #define MSR_IA32_PERFCTR0		0x000000c1
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -250,6 +250,7 @@ XEN_CPUFEATURE(EFRO,          7*32+10) /
 XEN_CPUFEATURE(CLZERO,        8*32+ 0) /*A  CLZERO instruction */
 XEN_CPUFEATURE(RSTR_FP_ERR_PTRS, 8*32+ 2) /*A  (F)X{SAVE,RSTOR} always saves/restores FPU Error pointers */
 XEN_CPUFEATURE(RDPRU,         8*32+ 4) /*A  RDPRU instruction */
+XEN_CPUFEATURE(MCOMMIT,       8*32+ 8) /*A  MCOMMIT instruction */
 XEN_CPUFEATURE(WBNOINVD,      8*32+ 9) /*   WBNOINVD instruction */
 XEN_CPUFEATURE(IBPB,          8*32+12) /*A  IBPB support only (no IBRS, used by AMD) */
 XEN_CPUFEATURE(AMD_PPIN,      8*32+23) /*   Protected Processor Inventory Number */



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 11:58:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 11:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOKD0-0006j3-UY; Tue, 14 Apr 2020 11:58:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=akv/=56=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jOKCz-0006iy-R5
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 11:58:29 +0000
X-Inumbo-ID: 40f09654-7e47-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 40f09654-7e47-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 11:58:29 +0000 (UTC)
Received: by mail-ed1-x544.google.com with SMTP id v1so16709916edq.8
 for <xen-devel@lists.xenproject.org>; Tue, 14 Apr 2020 04:58:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=v1aTs8gBKrFG7WXTg/hGEoWX4C0e8azPGKqQQchQmTk=;
 b=hdE4yeHxn5chh1zcg21GItSrpVRI/xKNK1zvZgjnGcbUW8/sjJX+9Z6l8/Iomacxyv
 Mmg5Pg9lXRKzlXZkvnpGivoPNFMib0UiqvSWGU89I/B5qiXG0IjwOFN+UcpbbhyGJuFX
 p0LuzxxqbvW4kt1y5dN0YzA8KD/hpJL8tLkrEiUer3rt5FicKK9WC84s+IJ2KRDvAyA7
 Bi72yhhQf1tPQZnx6rhq6+stqJ2n6rg2DCUI0WsxaHxGV4/qd2lazS/w46f4aBcd03TQ
 72t02CAVh5E72y6VoxtHMozvzqwsDAgmjUUUjnl8zKzSp2/7gD82RzGl7IF6iUhkXlfq
 q00Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=v1aTs8gBKrFG7WXTg/hGEoWX4C0e8azPGKqQQchQmTk=;
 b=r6WYS4soFBr4ZaKTh9Bawi5ks9zVmdagkH6VmpNl7eCpMO/gI+/jKT0uGg+ok4x5hX
 GqrzdIpC2DH21kfGc8F0VWh7O/VRXO6QncLegoCHbbA3G405QO4/R5yv6uGQ/jPHMC4h
 27K0HyWmC2ezqxFqtNeqgyca+SKfiUjx7TKVAJqrWQIMvIl3cRtjn8W6kEqTGa9t8h1V
 fe1HgRlwqc8KmcuDxoMgr9gNaqGJS3g3d2m5Dhpwn+B+c6O8fI6LajbdiKsCNplf/L0R
 aXWm0U4jLad9uArvC+7RdUacaPTXVrg+hPhoWmfyzB64dZnJsh2MEIfh/OAPmLd44aR+
 hZUA==
X-Gm-Message-State: AGi0PuZlRzPkAS8lmZu3+sfbGUw4jmYwmLC2+8RT5JAEF5zqw8+3BL5N
 q5RJA/bZ3uklKVl4wiSSydw=
X-Google-Smtp-Source: APiQypIoJE7ToGYD3n9KjKEQGkn8qo7VPuB2vaiU4Gh+HzAKMbRe/eRp+KTAtKaWiiAgn+KflnXioQ==
X-Received: by 2002:a50:954b:: with SMTP id v11mr20374873eda.28.1586865508241; 
 Tue, 14 Apr 2020 04:58:28 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id i23sm1695700edr.54.2020.04.14.04.58.26
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 14 Apr 2020 04:58:27 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
 <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
 <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
 <a102ec836a00714678fb3aa46787f597c9044f29.camel@amazon.com>
 <cfe18a03-854d-8b91-b333-ae2cefe3e1c8@suse.com>
 <000001d6124c$0aced570$206c8050$@xen.org>
 <90fd6e75-32b6-a140-1d20-083947bf1681@suse.com>
In-Reply-To: <90fd6e75-32b6-a140-1d20-083947bf1681@suse.com>
Subject: RE: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Tue, 14 Apr 2020 12:58:26 +0100
Message-ID: <000001d61254$020b0dc0$06212940$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQFuCy2uGI4jNh4hl1w2kkxxIVrUTADKkfs7Amx1u9ABXrUQQAMwPUabAgJH1CUBoTRAhwIYHsW9qNyD6KA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: wl@xen.org, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
 "'Shamsundara Havanur, Harsha'" <havanur@amazon.com>,
 xen-devel@lists.xenproject.org, roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 14 April 2020 12:40
> To: paul@xen.org
> Cc: 'Shamsundara Havanur, Harsha' <havanur@amazon.com>; =
xen-devel@lists.xenproject.org;
> andrew.cooper3@citrix.com; ian.jackson@eu.citrix.com; wl@xen.org; =
roger.pau@citrix.com
> Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, =
after all resource allocation
>=20
> On 14.04.2020 13:01, Paul Durrant wrote:
> >> -----Original Message-----
> >>>
> >>> Previous commit enabled MASTER for all functions. I am bit =
confused
> >>> here on the consensus on enabling/disabling/retaining BME.
> >>> Should we even care about MASTER?
> >>
> >> With the commit introducing its universal setting, I'm afraid to
> >> avoid regressions we can't sensibly alter the behavior unless it
> >> can be explained clearly why the original change must have been
> >> outright wrong.
> >>
> >
> > Well the original code IIRC had no justification for setting BME
> > and doing it unconditionally does seem dangerous.
>=20
> I'm not viewing this as dangerous, merely as (typically) pointless.
> A well behaved device won't start issuing DMA requests merely
> because it had its bus mastering capability enabled. (And in the
> context of some IOMMU work of yours you actually stated there are
> devices where clearing of this bit won't stop them from doing so.)
>=20

It's a line of defence against some devices at least, but others may =
choke. I still think it should be cleared by default and turned on with =
quirks if that is necessary.

> > Could we at least make it configurable?
> Well, the main question then would be - configurable by which
> mechanism?
>=20

The usual for hvmloader... a xenstore platform key.

  Paul




From xen-devel-bounces@lists.xenproject.org Tue Apr 14 12:00:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 12:00:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOKFK-0007ZI-Tb; Tue, 14 Apr 2020 12:00:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=/bN9=56=xenbits.xen.org=iwj@srs-us1.protection.inumbo.net>)
 id 1jOKFK-0007ZD-2D
 for xen-devel@lists.xen.org; Tue, 14 Apr 2020 12:00:54 +0000
X-Inumbo-ID: 93684b7b-7e47-11ea-8927-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 93684b7b-7e47-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 12:00:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=eucW+RPaT0GEI8HFOjDiEnXO1niYC5IiWEbkmd5hCwo=; b=wd+55sFB06fPR6QnSYvEDjApz+
 h05YF9ODQI1QrQkCzcuuYJ4rkxB3X0ogYiS0KU8821+I6oERensZlARt66Ybe+vbq1OlNJFyRyMn8
 AblUNWcESKqLJIZyFlC2SCbys9DDdWQolc4AQ2bbBdQtSdPoDBZufHknXkFVMCFkMNDc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <iwj@xenbits.xen.org>)
 id 1jOKF8-0000YA-5T; Tue, 14 Apr 2020 12:00:42 +0000
Received: from iwj by xenbits.xenproject.org with local (Exim 4.89)
 (envelope-from <iwj@xenbits.xen.org>)
 id 1jOKF8-00072Q-3i; Tue, 14 Apr 2020 12:00:42 +0000
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.508 (Entity 5.508)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Subject: Xen Security Advisory 313 v3 (CVE-2020-11740,CVE-2020-11741) -
 multiple xenoprof issues
Message-Id: <E1jOKF8-00072Q-3i@xenbits.xenproject.org>
Date: Tue, 14 Apr 2020 12:00:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "Xen.org security team" <security-team-members@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

    Xen Security Advisory CVE-2020-11740,CVE-2020-11741 / XSA-313
                              version 3

                       multiple xenoprof issues

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

Unprivileged guests can request to map xenoprof buffers, even if
profiling has not been enabled for those guests.  These buffers were
not scrubbed.  This is CVE-2020-11740.

Furthermore, for guests for which "active" profiling was enabled by
the administrator, the xenoprof code uses the standard Xen shared ring
structure.  Unfortunately, this code did not treat the guest as a
potential adversary: it trusts the guest not to modify buffer size
information or modify head / tail pointers in unexpected ways.  This is
CVE-2020-11741.

IMPACT
======

A malicious guest may be able to access sensitive information
pertaining to other guests.  Guests with "active profiling" enabled
can crash the host (DoS).  Privilege escalation cannot be ruled out.

VULNERABLE SYSTEMS
==================

Only x86 PV guests can leverage the vulnerabilities.  Arm guests and
x86 HVM and PVH guests cannot leverage the vulnerabilities.

All Xen versions back to at least 3.2 are vulnerable.

Any x86 PV guest can leverage the information leak.  Only x86 PV guests
whose host administrator has explicitly enabled "active profiling" for an
untrusted guest can exploit the DoS / potential privilege escalation.

Only builds of Xen with the Xenoprof functionality enabled at build
time are vulnerable.  The option to disable the functionality at build
time was been introduced in Xen 4.7.

MITIGATION
==========

Never making any untrusted guests "active" will avoid all but the info
leak part of the vulnerabilities.  There's no known mitigation for the
information leak (lack of scrubbing).

CREDITS
=======

This issue was discovered by Ilja Van Sprundel of IOActive.

RESOLUTION
==========

Applying the attached set of patches resolves these issues.

The first patch fixes the information leak issue, and should be
applied to all x86 systems running untrusted PV guests.

The second patch fixes the "active profiling" issue.  Systems which do
not enable active profiling can safely skip patch 2.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa313-?.patch         xen-unstable, Xen 4.9.x - 4.13.x

$ sha256sum xsa313*
63a11c5470a6c24f19d3a8a45042306256e7422d6556e3d76badaa515deb76d6  xsa313.meta
f186ad88b492b730aeae3bd01083dd6c13813ce08bcd4ffc608d7af500633a62  xsa313-1.patch
9fbcb5f11e5029e7d371ddb3520443c2780f240edc3d24436872935e34a85c37  xsa313-2.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl6VpdkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZYZcH/0UHo2zmXGMDvZn1EF20ccKXNoZjvAE5TxSr/A/M
qkeASj4IMKlrPOrvs7aQSp97vECTz71Fxz2z7wpGwgIdiOYcRVg/t3b/+E1QSx5N
T7xYxxD9ULOLBQyPjYnXYwDC9+9yy+PZuWt3oPeXHrdtLI/5VY/gCzU+k+7bDABh
uljJ5KqxeQ5W8DOCR+XscQSZ9wiSkyh8MANjuJJ7uhtVDBo+ul94lrInJYEaBVpI
At5cU53B5nVGQ3RkNyWKjSW3VbL1TLgTdWAJNQOo+Z0OZJiKm6xQ6OYph2L4C4j4
e5A5c8UZAXLxVFWIMuiRW2GekOQEkGXtu+uJP00GuXm3+cQ=
=1C0J
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa313.meta"
Content-Disposition: attachment; filename="xsa313.meta"
Content-Transfer-Encoding: base64

ewogICJYU0EiOiAzMTMsCiAgIlN1cHBvcnRlZFZlcnNpb25zIjogWwogICAg
Im1hc3RlciIsCiAgICAiNC4xMyIsCiAgICAiNC4xMiIsCiAgICAiNC4xMSIs
CiAgICAiNC4xMCIsCiAgICAiNC45IgogIF0sCiAgIlRyZWVzIjogWwogICAg
InhlbiIKICBdLAogICJSZWNpcGVzIjogewogICAgIjQuMTAiOiB7CiAgICAg
ICJSZWNpcGVzIjogewogICAgICAgICJ4ZW4iOiB7CiAgICAgICAgICAiU3Rh
YmxlUmVmIjogIjQ5YTVkNmU5MjMxN2E3ZDlhY2JmMGJkYmQyNWIyODA5ZGZk
ODQyNjAiLAogICAgICAgICAgIlByZXJlcXMiOiBbXSwKICAgICAgICAgICJQ
YXRjaGVzIjogWwogICAgICAgICAgICAieHNhMzEzLT8ucGF0Y2giCiAgICAg
ICAgICBdCiAgICAgICAgfQogICAgICB9CiAgICB9LAogICAgIjQuMTEiOiB7
CiAgICAgICJSZWNpcGVzIjogewogICAgICAgICJ4ZW4iOiB7CiAgICAgICAg
ICAiU3RhYmxlUmVmIjogIjZiYzU0YzA2OTZjMGY2ZjYzOTU5ODM2M2QyODRj
NzE4OGE5ZTIwYWUiLAogICAgICAgICAgIlByZXJlcXMiOiBbXSwKICAgICAg
ICAgICJQYXRjaGVzIjogWwogICAgICAgICAgICAieHNhMzEzLT8ucGF0Y2gi
CiAgICAgICAgICBdCiAgICAgICAgfQogICAgICB9CiAgICB9LAogICAgIjQu
MTIiOiB7CiAgICAgICJSZWNpcGVzIjogewogICAgICAgICJ4ZW4iOiB7CiAg
ICAgICAgICAiU3RhYmxlUmVmIjogIjgyNGJkYjQzMmZjODgzMWVlNDY4NGU0
NTM2MWE3OGZhZWU0NTQ4ZWQiLAogICAgICAgICAgIlByZXJlcXMiOiBbXSwK
ICAgICAgICAgICJQYXRjaGVzIjogWwogICAgICAgICAgICAieHNhMzEzLT8u
cGF0Y2giCiAgICAgICAgICBdCiAgICAgICAgfQogICAgICB9CiAgICB9LAog
ICAgIjQuMTMiOiB7CiAgICAgICJSZWNpcGVzIjogewogICAgICAgICJ4ZW4i
OiB7CiAgICAgICAgICAiU3RhYmxlUmVmIjogImQzZjNlNDQ3Njc2NjY3ZWYz
MGI0ODcwOGQzNTljOGY4YjEzYTlhMDMiLAogICAgICAgICAgIlByZXJlcXMi
OiBbXSwKICAgICAgICAgICJQYXRjaGVzIjogWwogICAgICAgICAgICAieHNh
MzEzLT8ucGF0Y2giCiAgICAgICAgICBdCiAgICAgICAgfQogICAgICB9CiAg
ICB9LAogICAgIjQuOSI6IHsKICAgICAgIlJlY2lwZXMiOiB7CiAgICAgICAg
InhlbiI6IHsKICAgICAgICAgICJTdGFibGVSZWYiOiAiY2YyZTljYzBiYTA0
MzJmMDVjZGNhMzZkY2Q0NmJlNWZkZmQ3Y2EwYyIsCiAgICAgICAgICAiUHJl
cmVxcyI6IFtdLAogICAgICAgICAgIlBhdGNoZXMiOiBbCiAgICAgICAgICAg
ICJ4c2EzMTMtPy5wYXRjaCIKICAgICAgICAgIF0KICAgICAgICB9CiAgICAg
IH0KICAgIH0sCiAgICAibWFzdGVyIjogewogICAgICAiUmVjaXBlcyI6IHsK
ICAgICAgICAieGVuIjogewogICAgICAgICAgIlN0YWJsZVJlZiI6ICJlMTli
NGIzYjU1Zjg0ZTBjZmNjMDJmZTVkNjY5NjU5NjlhODFjOTY1IiwKICAgICAg
ICAgICJQcmVyZXFzIjogW10sCiAgICAgICAgICAiUGF0Y2hlcyI6IFsKICAg
ICAgICAgICAgInhzYTMxMy0/LnBhdGNoIgogICAgICAgICAgXQogICAgICAg
IH0KICAgICAgfQogICAgfQogIH0KfQ==

--=separator
Content-Type: application/octet-stream; name="xsa313-1.patch"
Content-Disposition: attachment; filename="xsa313-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ZW5vcHJvZjogY2xlYXIgYnVmZmVyIGludGVuZGVkIHRvIGJlIHNoYXJl
ZCB3aXRoIGd1ZXN0cwoKYWxsb2NfeGVuaGVhcF9wYWdlcygpIG1ha2luZyB1
c2Ugb2YgTUVNRl9ub19zY3J1YiBpcyBmaW5lIGZvciBYZW4KaW50ZXJuYWxs
eSB1c2VkIGFsbG9jYXRpb25zLCBidXQgYnVmZmVycyBhbGxvY2F0ZWQgdG8g
YmUgc2hhcmVkIHdpdGgKKHVucHJpdmlsaWdlZCkgZ3Vlc3RzIG5lZWQgdG8g
YmUgemFwcGVkIG9mIHRoZWlyIHByaW9yIGNvbnRlbnQuCgpUaGlzIGlzIHBh
cnQgb2YgWFNBLTMxMy4KClJlcG9ydGVkLWJ5OiBJbGphIFZhbiBTcHJ1bmRl
bCA8aXZhbnNwcnVuZGVsQGlvYWN0aXZlLmNvbT4KU2lnbmVkLW9mZi1ieTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpSZXZpZXdlZC1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFdlaSBMaXUgPHdsQHhlbi5vcmc+CgotLS0gYS94ZW4vY29t
bW9uL3hlbm9wcm9mLmMKKysrIGIveGVuL2NvbW1vbi94ZW5vcHJvZi5jCkBA
IC0yNTMsNiArMjUzLDkgQEAgc3RhdGljIGludCBhbGxvY194ZW5vcHJvZl9z
dHJ1Y3QoCiAgICAgICAgIHJldHVybiAtRU5PTUVNOwogICAgIH0KIAorICAg
IGZvciAoIGkgPSAwOyBpIDwgbnBhZ2VzOyArK2kgKQorICAgICAgICBjbGVh
cl9wYWdlKGQtPnhlbm9wcm9mLT5yYXdidWYgKyBpICogUEFHRV9TSVpFKTsK
KwogICAgIGQtPnhlbm9wcm9mLT5ucGFnZXMgPSBucGFnZXM7CiAgICAgZC0+
eGVub3Byb2YtPm5idWYgPSBudmNwdTsKICAgICBkLT54ZW5vcHJvZi0+YnVm
c2l6ZSA9IGJ1ZnNpemU7Cg==

--=separator
Content-Type: application/octet-stream; name="xsa313-2.patch"
Content-Disposition: attachment; filename="xsa313-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ZW5vcHJvZjogbGltaXQgY29uc3VtcHRpb24gb2Ygc2hhcmVkIGJ1ZmZl
ciBkYXRhCgpTaW5jZSBhIHNoYXJlZCBidWZmZXIgY2FuIGJlIHdyaXR0ZW4g
dG8gYnkgdGhlIGd1ZXN0LCB3ZSBtYXkgb25seSByZWFkCnRoZSBoZWFkIGFu
ZCB0YWlsIHBvaW50ZXJzIGZyb20gdGhlcmUgKGFsbCBvdGhlciBmaWVsZHMg
c2hvdWxkIG9ubHkgZXZlcgpiZSB3cml0dGVuIHRvKS4gRnVydGhlcm1vcmUs
IGZvciBhbnkgcGFydGljdWxhciBvcGVyYXRpb24gdGhlIHR3byB2YWx1ZXMK
bXVzdCBiZSByZWFkIGV4YWN0bHkgb25jZSwgd2l0aCBib3RoIGNoZWNrcyBh
bmQgY29uc3VtcHRpb24gaGFwcGVuaW5nCndpdGggdGhlIHRodXMgcmVhZCB2
YWx1ZXMuIChUaGUgYmFja3RyYWNlIHJlbGF0ZWQgeGVub3Byb2ZfYnVmX3Nw
YWNlKCkKdXNlIGluIHhlbm9wcm9mX2xvZ19ldmVudCgpIGlzIGFuIGV4Y2Vw
dGlvbjogVGhlIHZhbHVlcyB1c2VkIHRoZXJlIGdldApyZS1jaGVja2VkIGJ5
IGV2ZXJ5IHN1YnNlcXVlbnQgeGVub3Byb2ZfYWRkX3NhbXBsZSgpLikKClNp
bmNlIHRoYXQgY29kZSBuZWVkZWQgdG91Y2hpbmcsIGFsc28gZml4IHRoZSBk
b3VibGUgaW5jcmVtZW50IG9mIHRoZQpsb3N0IHNhbXBsZXMgY291bnQgaW4g
Y2FzZSB0aGUgYmFja3RyYWNlIHJlbGF0ZWQgeGVub3Byb2ZfYWRkX3NhbXBs
ZSgpCmludm9jYXRpb24gaW4geGVub3Byb2ZfbG9nX2V2ZW50KCkgZmFpbHMu
CgpXaGVyZSBjb2RlIGlzIGJlaW5nIHRvdWNoZWQgYW55d2F5LCBhZGQgY29u
c3QgYXMgYXBwcm9wcmlhdGUsIGJ1dCB0YWtlCnRoZSBvcHBvcnR1bml0eSB0
byBlbnRpcmVseSBkcm9wIHRoZSBub3cgdW51c2VkIGRvbWFpbiBwYXJhbWV0
ZXIgb2YKeGVub3Byb2ZfYnVmX3NwYWNlKCkuCgpUaGlzIGlzIHBhcnQgb2Yg
WFNBLTMxMy4KClJlcG9ydGVkLWJ5OiBJbGphIFZhbiBTcHJ1bmRlbCA8aXZh
bnNwcnVuZGVsQGlvYWN0aXZlLmNvbT4KU2lnbmVkLW9mZi1ieTogSmFuIEJl
dWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpSZXZpZXdlZC1ieTogR2Vvcmdl
IER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPgpSZXZpZXdlZC1i
eTogV2VpIExpdSA8d2xAeGVuLm9yZz4KCi0tLSBhL3hlbi9jb21tb24veGVu
b3Byb2YuYworKysgYi94ZW4vY29tbW9uL3hlbm9wcm9mLmMKQEAgLTQ3OSwy
NSArNDc5LDIyIEBAIHN0YXRpYyBpbnQgYWRkX3Bhc3NpdmVfbGlzdChYRU5f
R1VFU1RfSEEKIAogCiAvKiBHZXQgc3BhY2UgaW4gdGhlIGJ1ZmZlciAqLwot
c3RhdGljIGludCB4ZW5vcHJvZl9idWZfc3BhY2Uoc3RydWN0IGRvbWFpbiAq
ZCwgeGVub3Byb2ZfYnVmX3QgKiBidWYsIGludCBzaXplKQorc3RhdGljIGlu
dCB4ZW5vcHJvZl9idWZfc3BhY2UoaW50IGhlYWQsIGludCB0YWlsLCBpbnQg
c2l6ZSkKIHsKLSAgICBpbnQgaGVhZCwgdGFpbDsKLQotICAgIGhlYWQgPSB4
ZW5vcHJvZl9idWYoZCwgYnVmLCBldmVudF9oZWFkKTsKLSAgICB0YWlsID0g
eGVub3Byb2ZfYnVmKGQsIGJ1ZiwgZXZlbnRfdGFpbCk7Ci0KICAgICByZXR1
cm4gKCh0YWlsID4gaGVhZCkgPyAwIDogc2l6ZSkgKyB0YWlsIC0gaGVhZCAt
IDE7CiB9CiAKIC8qIENoZWNrIGZvciBzcGFjZSBhbmQgYWRkIGEgc2FtcGxl
LiBSZXR1cm4gMSBpZiBzdWNjZXNzZnVsLCAwIG90aGVyd2lzZS4gKi8KLXN0
YXRpYyBpbnQgeGVub3Byb2ZfYWRkX3NhbXBsZShzdHJ1Y3QgZG9tYWluICpk
LCB4ZW5vcHJvZl9idWZfdCAqYnVmLAorc3RhdGljIGludCB4ZW5vcHJvZl9h
ZGRfc2FtcGxlKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IHhlbm9wcm9mX3Zj
cHUgKnYsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDY0
X3QgZWlwLCBpbnQgbW9kZSwgaW50IGV2ZW50KQogeworICAgIHhlbm9wcm9m
X2J1Zl90ICpidWYgPSB2LT5idWZmZXI7CiAgICAgaW50IGhlYWQsIHRhaWws
IHNpemU7CiAKICAgICBoZWFkID0geGVub3Byb2ZfYnVmKGQsIGJ1ZiwgZXZl
bnRfaGVhZCk7CiAgICAgdGFpbCA9IHhlbm9wcm9mX2J1ZihkLCBidWYsIGV2
ZW50X3RhaWwpOwotICAgIHNpemUgPSB4ZW5vcHJvZl9idWYoZCwgYnVmLCBl
dmVudF9zaXplKTsKKyAgICBzaXplID0gdi0+ZXZlbnRfc2l6ZTsKICAgICAK
ICAgICAvKiBtYWtlIHN1cmUgaW5kZXhlcyBpbiBzaGFyZWQgYnVmZmVyIGFy
ZSBzYW5lICovCiAgICAgaWYgKCAoaGVhZCA8IDApIHx8IChoZWFkID49IHNp
emUpIHx8ICh0YWlsIDwgMCkgfHwgKHRhaWwgPj0gc2l6ZSkgKQpAQCAtNTA2
LDcgKzUwMyw3IEBAIHN0YXRpYyBpbnQgeGVub3Byb2ZfYWRkX3NhbXBsZShz
dHJ1Y3QgZG8KICAgICAgICAgcmV0dXJuIDA7CiAgICAgfQogCi0gICAgaWYg
KCB4ZW5vcHJvZl9idWZfc3BhY2UoZCwgYnVmLCBzaXplKSA+IDAgKQorICAg
IGlmICggeGVub3Byb2ZfYnVmX3NwYWNlKGhlYWQsIHRhaWwsIHNpemUpID4g
MCApCiAgICAgewogICAgICAgICB4ZW5vcHJvZl9idWYoZCwgYnVmLCBldmVu
dF9sb2dbaGVhZF0uZWlwKSA9IGVpcDsKICAgICAgICAgeGVub3Byb2ZfYnVm
KGQsIGJ1ZiwgZXZlbnRfbG9nW2hlYWRdLm1vZGUpID0gbW9kZTsKQEAgLTUz
MCw3ICs1MjcsNiBAQCBzdGF0aWMgaW50IHhlbm9wcm9mX2FkZF9zYW1wbGUo
c3RydWN0IGRvCiBpbnQgeGVub3Byb2ZfYWRkX3RyYWNlKHN0cnVjdCB2Y3B1
ICp2Y3B1LCB1aW50NjRfdCBwYywgaW50IG1vZGUpCiB7CiAgICAgc3RydWN0
IGRvbWFpbiAqZCA9IHZjcHUtPmRvbWFpbjsKLSAgICB4ZW5vcHJvZl9idWZf
dCAqYnVmID0gZC0+eGVub3Byb2YtPnZjcHVbdmNwdS0+dmNwdV9pZF0uYnVm
ZmVyOwogCiAgICAgLyogRG8gbm90IGFjY2lkZW50YWxseSB3cml0ZSBhbiBl
c2NhcGUgY29kZSBkdWUgdG8gYSBicm9rZW4gZnJhbWUuICovCiAgICAgaWYg
KCBwYyA9PSBYRU5PUFJPRl9FU0NBUEVfQ09ERSApCkBAIC01MzksNyArNTM1
LDggQEAgaW50IHhlbm9wcm9mX2FkZF90cmFjZShzdHJ1Y3QgdmNwdSAqdmNw
dQogICAgICAgICByZXR1cm4gMDsKICAgICB9CiAKLSAgICByZXR1cm4geGVu
b3Byb2ZfYWRkX3NhbXBsZShkLCBidWYsIHBjLCBtb2RlLCAwKTsKKyAgICBy
ZXR1cm4geGVub3Byb2ZfYWRkX3NhbXBsZShkLCAmZC0+eGVub3Byb2YtPnZj
cHVbdmNwdS0+dmNwdV9pZF0sCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgcGMsIG1vZGUsIDApOwogfQogCiB2b2lkIHhlbm9wcm9mX2xvZ19l
dmVudChzdHJ1Y3QgdmNwdSAqdmNwdSwgY29uc3Qgc3RydWN0IGNwdV91c2Vy
X3JlZ3MgKnJlZ3MsCkBAIC01NzAsMTcgKzU2NywyMiBAQCB2b2lkIHhlbm9w
cm9mX2xvZ19ldmVudChzdHJ1Y3QgdmNwdSAqdmNwCiAgICAgLyogUHJvdmlk
ZSBiYWNrdHJhY2UgaWYgcmVxdWVzdGVkLiAqLwogICAgIGlmICggYmFja3Ry
YWNlX2RlcHRoID4gMCApCiAgICAgewotICAgICAgICBpZiAoICh4ZW5vcHJv
Zl9idWZfc3BhY2UoZCwgYnVmLCB2LT5ldmVudF9zaXplKSA8IDIpIHx8Ci0g
ICAgICAgICAgICAgIXhlbm9wcm9mX2FkZF9zYW1wbGUoZCwgYnVmLCBYRU5P
UFJPRl9FU0NBUEVfQ09ERSwgbW9kZSwgCi0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgWEVOT1BST0ZfVFJBQ0VfQkVHSU4pICkKKyAgICAg
ICAgaWYgKCB4ZW5vcHJvZl9idWZfc3BhY2UoeGVub3Byb2ZfYnVmKGQsIGJ1
ZiwgZXZlbnRfaGVhZCksCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHhlbm9wcm9mX2J1ZihkLCBidWYsIGV2ZW50X3RhaWwpLAorICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB2LT5ldmVudF9zaXplKSA8IDIg
KQogICAgICAgICB7CiAgICAgICAgICAgICB4ZW5vcHJvZl9idWYoZCwgYnVm
LCBsb3N0X3NhbXBsZXMpKys7CiAgICAgICAgICAgICBsb3N0X3NhbXBsZXMr
KzsKICAgICAgICAgICAgIHJldHVybjsKICAgICAgICAgfQorCisgICAgICAg
IC8qIHhlbm9wcm9mX2FkZF9zYW1wbGUoKSB3aWxsIGluY3JlbWVudCBsb3N0
X3NhbXBsZXMgb24gZmFpbHVyZSAqLworICAgICAgICBpZiAoICF4ZW5vcHJv
Zl9hZGRfc2FtcGxlKGQsIHYsIFhFTk9QUk9GX0VTQ0FQRV9DT0RFLCBtb2Rl
LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFhFTk9QUk9G
X1RSQUNFX0JFR0lOKSApCisgICAgICAgICAgICByZXR1cm47CiAgICAgfQog
Ci0gICAgaWYgKCB4ZW5vcHJvZl9hZGRfc2FtcGxlKGQsIGJ1ZiwgcGMsIG1v
ZGUsIGV2ZW50KSApCisgICAgaWYgKCB4ZW5vcHJvZl9hZGRfc2FtcGxlKGQs
IHYsIHBjLCBtb2RlLCBldmVudCkgKQogICAgIHsKICAgICAgICAgaWYgKCBp
c19hY3RpdmUodmNwdS0+ZG9tYWluKSApCiAgICAgICAgICAgICBhY3RpdmVf
c2FtcGxlcysrOwotLS0gYS94ZW4vaW5jbHVkZS94ZW4veGVub3Byb2YuaAor
KysgYi94ZW4vaW5jbHVkZS94ZW4veGVub3Byb2YuaApAQCAtNjEsMTIgKzYx
LDEyIEBAIHN0cnVjdCB4ZW5vcHJvZiB7CiAKICNpZm5kZWYgQ09ORklHX0NP
TVBBVAogI2RlZmluZSBYRU5PUFJPRl9DT01QQVQoeCkgMAotI2RlZmluZSB4
ZW5vcHJvZl9idWYoZCwgYiwgZmllbGQpICgoYiktPmZpZWxkKQorI2RlZmlu
ZSB4ZW5vcHJvZl9idWYoZCwgYiwgZmllbGQpIEFDQ0VTU19PTkNFKChiKS0+
ZmllbGQpCiAjZWxzZQogI2RlZmluZSBYRU5PUFJPRl9DT01QQVQoeCkgKCh4
KS0+aXNfY29tcGF0KQotI2RlZmluZSB4ZW5vcHJvZl9idWYoZCwgYiwgZmll
bGQpICgqKCEoZCktPnhlbm9wcm9mLT5pc19jb21wYXQgPyBcCi0gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmKGIpLT5uYXRpdmUu
ZmllbGQgOiBcCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmKGIpLT5jb21wYXQuZmllbGQpKQorI2RlZmluZSB4ZW5vcHJvZl9i
dWYoZCwgYiwgZmllbGQpIEFDQ0VTU19PTkNFKCooIShkKS0+eGVub3Byb2Yt
PmlzX2NvbXBhdCBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA/ICYoYiktPm5hdGl2ZS5maWVsZCBcCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6
ICYoYiktPmNvbXBhdC5maWVsZCkpCiAjZW5kaWYKIAogc3RydWN0IGRvbWFp
bjsK

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 12:01:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 12:01:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOKFS-0007b8-9a; Tue, 14 Apr 2020 12:01:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=/bN9=56=xenbits.xen.org=iwj@srs-us1.protection.inumbo.net>)
 id 1jOKFR-0007ar-Hi
 for xen-devel@lists.xen.org; Tue, 14 Apr 2020 12:01:01 +0000
X-Inumbo-ID: 95863b10-7e47-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 95863b10-7e47-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 12:00:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=aP7zEw2Ja7XpkzWCUNUnIBbF7IgwD7OB+rzvUn2jWBU=; b=qsp/VEYxnTsGFRHxVlj58CHIjK
 831NIp1mUCgk53mugrrrBlPGA3AJywAcUDAfJec6GpgH17FQZFRewInEu17Viahhr9yaRnNRKMII5
 sWdlKg8SrItxIXZELcV7YxOv1nh81rpiM3MOQGHSfAG8XAH101M6x/plArRHzinLf4jg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <iwj@xenbits.xen.org>)
 id 1jOKFB-0000YM-5B; Tue, 14 Apr 2020 12:00:45 +0000
Received: from iwj by xenbits.xenproject.org with local (Exim 4.89)
 (envelope-from <iwj@xenbits.xen.org>)
 id 1jOKFB-00073X-32; Tue, 14 Apr 2020 12:00:45 +0000
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.508 (Entity 5.508)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Subject: Xen Security Advisory 314 v3 (CVE-2020-11739) - Missing memory
 barriers in read-write unlock paths
Message-Id: <E1jOKFB-00073X-32@xenbits.xenproject.org>
Date: Tue, 14 Apr 2020 12:00:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "Xen.org security team" <security-team-members@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2020-11739 / XSA-314
                               version 3

          Missing memory barriers in read-write unlock paths

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The read-write unlock paths don't contain a memory barrier.  On Arm, this
means a processor is allowed to re-order the memory access with the
preceding ones.

In other words, the unlock may be seen by another processor before all the
memory accesses within the "critical" section.

As a consequence, it may be possible to have a writer executing a critical
section at the same time as readers or another writer. In other words,
many of the assumptions (e.g a variable cannot be modified after a check)
in the critical sections are not safe anymore.

The read-write locks are used in hypercalls (such as grant-table ones), so
a malicious guest could exploit the race.  For instance, there is a small
window where Xen can leak memory if XENMAPSPACE_grant_table is used
concurrently.

IMPACT
======

A malicous guest may be able to leak memory, or cause a hypervisor crash
resulting in a Denial of Service (DoS). Information leak and privilege
escalation cannot be excluded.

VULNERABLE SYSTEMS
==================

Systems running all versions of Xen are affected.

Whether an individual Arm-based CPU is vulnerable depends on its memory
re-ordering properties.  Consult your CPU vendor.

x86 systems are not vulnerable.

MITIGATION
==========

There is no known mitigation.

CREDITS
=======

This issue was discovered by Julien Grall of Amazon.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa314.patch           xen-unstable
xsa314-4.13.patch      Xen 4.13 - Xen 4.9

$ sha256sum xsa314*
ff6e03780766d0358699ed0c5b0154be9ccbbc80796650f7568c295c5451ba0a  xsa314.meta
7c507e7b46568e94aa9595a549bd3020b16d1eca97b8bfc3bb1f5d96eb338cc1  xsa314.patch
a13e6a9cd531859882d1b0ef38245441d363d1ead1fa2a5ae5da7a0fce27e072  xsa314-4.13.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl6VpdcMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZNSoH/2TB+nP1KWB0LUkP5yD1tlSC6Q58k3ReUw7uVfLh
OOBhyOZz5jQOO9r6HDQtqxZBtihbmCDD9Ckl3V4au81TFxz8My24nMR+X1dqDcPi
0MQ2+Tu3z6S/NMw9DwLsN9b0MtHlmalOBrhbhif3/U0QDgLFhN2H8GtvFQ1imWmm
JHoTdBHDUwxCvThIHZCui/T69U/csdfyV6f/HgMVTzpNIOBkiwUuOVuMEO25KqVk
tO0z0CyK19K86VJu7k4q16RzCllUoe5bSU+7UVYOS1PxZ5XCvKTCYcZDz1HZMW/8
FOA8yNMzHV3b+0WvCnMpq9qHmmJXGx+vRSoeBF7YeU0wUkE=
=oA9H
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa314.meta"
Content-Disposition: attachment; filename="xsa314.meta"
Content-Transfer-Encoding: base64

ewogICJYU0EiOiAzMTQsCiAgIlN1cHBvcnRlZFZlcnNpb25zIjogWwogICAg
Im1hc3RlciIsCiAgICAiNC4xMyIsCiAgICAiNC4xMiIsCiAgICAiNC4xMSIs
CiAgICAiNC4xMCIsCiAgICAiNC45IgogIF0sCiAgIlRyZWVzIjogWwogICAg
InhlbiIKICBdLAogICJSZWNpcGVzIjogewogICAgIjQuMTAiOiB7CiAgICAg
ICJSZWNpcGVzIjogewogICAgICAgICJ4ZW4iOiB7CiAgICAgICAgICAiU3Rh
YmxlUmVmIjogIjQ5YTVkNmU5MjMxN2E3ZDlhY2JmMGJkYmQyNWIyODA5ZGZk
ODQyNjAiLAogICAgICAgICAgIlByZXJlcXMiOiBbXSwKICAgICAgICAgICJQ
YXRjaGVzIjogWwogICAgICAgICAgICAieHNhMzE0LTQuMTMucGF0Y2giCiAg
ICAgICAgICBdCiAgICAgICAgfQogICAgICB9CiAgICB9LAogICAgIjQuMTEi
OiB7CiAgICAgICJSZWNpcGVzIjogewogICAgICAgICJ4ZW4iOiB7CiAgICAg
ICAgICAiU3RhYmxlUmVmIjogImRkZmZjNGQ4YTA3MmYxNDYzMjBmNGNhNThj
NzY4YzRiNTYzYWI1NzEiLAogICAgICAgICAgIlByZXJlcXMiOiBbXSwKICAg
ICAgICAgICJQYXRjaGVzIjogWwogICAgICAgICAgICAieHNhMzE0LTQuMTMu
cGF0Y2giCiAgICAgICAgICBdCiAgICAgICAgfQogICAgICB9CiAgICB9LAog
ICAgIjQuMTIiOiB7CiAgICAgICJSZWNpcGVzIjogewogICAgICAgICJ4ZW4i
OiB7CiAgICAgICAgICAiU3RhYmxlUmVmIjogImE1ZmNhZmJmYmVlNTUyNjE4
NTNmYmEwNzE0OWMxYzc5NWYyYmFmNTgiLAogICAgICAgICAgIlByZXJlcXMi
OiBbXSwKICAgICAgICAgICJQYXRjaGVzIjogWwogICAgICAgICAgICAieHNh
MzE0LTQuMTMucGF0Y2giCiAgICAgICAgICBdCiAgICAgICAgfQogICAgICB9
CiAgICB9LAogICAgIjQuMTMiOiB7CiAgICAgICJSZWNpcGVzIjogewogICAg
ICAgICJ4ZW4iOiB7CiAgICAgICAgICAiU3RhYmxlUmVmIjogIjcyMWYyYzMy
M2NhNTVjNzc4NTdjOTNlNzI3NWI0YTkzYTBlMTVlMWYiLAogICAgICAgICAg
IlByZXJlcXMiOiBbXSwKICAgICAgICAgICJQYXRjaGVzIjogWwogICAgICAg
ICAgICAieHNhMzE0LTQuMTMucGF0Y2giCiAgICAgICAgICBdCiAgICAgICAg
fQogICAgICB9CiAgICB9LAogICAgIjQuOSI6IHsKICAgICAgIlJlY2lwZXMi
OiB7CiAgICAgICAgInhlbiI6IHsKICAgICAgICAgICJTdGFibGVSZWYiOiAi
Y2YyZTljYzBiYTA0MzJmMDVjZGNhMzZkY2Q0NmJlNWZkZmQ3Y2EwYyIsCiAg
ICAgICAgICAiUHJlcmVxcyI6IFtdLAogICAgICAgICAgIlBhdGNoZXMiOiBb
CiAgICAgICAgICAgICJ4c2EzMTQtNC4xMy5wYXRjaCIKICAgICAgICAgIF0K
ICAgICAgICB9CiAgICAgIH0KICAgIH0sCiAgICAibWFzdGVyIjogewogICAg
ICAiUmVjaXBlcyI6IHsKICAgICAgICAieGVuIjogewogICAgICAgICAgIlN0
YWJsZVJlZiI6ICIwZDk5YzkwOWQ3ZTFjYmU2OTMyOWEwMGY3NzcyOTQ2ZjEw
YTc4NjViIiwKICAgICAgICAgICJQcmVyZXFzIjogW10sCiAgICAgICAgICAi
UGF0Y2hlcyI6IFsKICAgICAgICAgICAgInhzYTMxNC5wYXRjaCIKICAgICAg
ICAgIF0KICAgICAgICB9CiAgICAgIH0KICAgIH0KICB9Cn0=

--=separator
Content-Type: application/octet-stream; name="xsa314.patch"
Content-Disposition: attachment; filename="xsa314.patch"
Content-Transfer-Encoding: base64

RnJvbSAyNDI5NTVhYzU2ZjE3NTMyMmFmMDQwZGYyOWFiOGNmYjU0YTNiNGY3
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWxpZW4gR3JhbGwg
PGpncmFsbEBhbWF6b24uY29tPgpEYXRlOiBUaHUsIDIwIEZlYiAyMDIwIDIw
OjU0OjQwICswMDAwClN1YmplY3Q6IFtQQVRDSF0geGVuL3J3bG9jazogQWRk
IG1pc3NpbmcgbWVtb3J5IGJhcnJpZXIgaW4gdGhlIHVubG9jayBwYXRoIG9m
CiByd2xvY2sKClRoZSByd2xvY2sgdW5sb2NrIHBhdGhzIGFyZSB1c2luZyBh
dG9taWNfc3ViKCkgdG8gcmVsZWFzZSB0aGUgbG9jay4KSG93ZXZlciB0aGUg
aW1wbGVtZW50YXRpb24gb2YgYXRvbWljX3N1YigpIHJpZ2h0ZnVsbHkgZG9l
c24ndCBjb250YWluIGEKbWVtb3J5IGJhcnJpZXIuIE9uIEFybSwgdGhpcyBt
ZWFucyBhIHByb2Nlc3NvciBpcyBhbGxvd2VkIHRvIHJlLW9yZGVyCnRoZSBt
ZW1vcnkgYWNjZXNzIHdpdGggdGhlIHByZWNlZWRpbmcgYWNjZXNzLgoKSW4g
b3RoZXIgd29yZHMsIHRoZSB1bmxvY2sgbWF5IGJlIHNlZW4gYnkgYW5vdGhl
ciBwcm9jZXNzb3IgYmVmb3JlIGFsbAp0aGUgbWVtb3J5IGFjY2Vzc2VzIHdp
dGhpbiB0aGUgImNyaXRpY2FsIiBzZWN0aW9uLgoKVGhlIHJ3bG9jayBwYXRo
cyBhbHJlYWR5IGNvbnRhaW5zIGJhcnJpZXIgaW5kaXJlY3RseSwgYnV0IHRo
ZXkgYXJlIG5vdAp2ZXJ5IHVzZWZ1bCB3aXRob3V0IHRoZSBjb3VudGVycGFy
dCBpbiB0aGUgdW5sb2NrIHBhdGhzLgoKVGhlIG1lbW9yeSBiYXJyaWVycyBh
cmUgbm90IG5lY2Vzc2FyeSBvbiB4ODYgYmVjYXVzZSBsb2Fkcy9zdG9yZXMg
YXJlCm5vdCByZS1vcmRlcmVkIHdpdGggbG9jayBpbnN0cnVjdGlvbnMuCgpT
byBhZGQgYXJjaF9sb2NrX3JlbGVhc2VfYmFycmllcigpIGluIHRoZSB1bmxv
Y2sgcGF0aHMgdGhhdCB3aWxsIG9ubHkKYWRkIG1lbW9yeSBiYXJyaWVyIG9u
IEFybS4KClRha2UgdGhlIG9wcG9ydHVuaXR5IHRvIGRvY3VtZW50IGVhY2gg
bG9jayBwYXRocyBleHBsYWluaW5nIHdoeSBhCmJhcnJpZXIgaXMgbm90IG5l
Y2Vzc2FyeS4KClRoaXMgaXMgWFNBLTMxNC4KClNpZ25lZC1vZmYtYnk6IEp1
bGllbiBHcmFsbCA8amdyYWxsQGFtYXpvbi5jb20+Ci0tLQogeGVuL2luY2x1
ZGUveGVuL3J3bG9jay5oIHwgMjkgKysrKysrKysrKysrKysrKysrKysrKysr
KysrKy0KIDEgZmlsZSBjaGFuZ2VkLCAyOCBpbnNlcnRpb25zKCspLCAxIGRl
bGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3J3bG9j
ay5oIGIveGVuL2luY2x1ZGUveGVuL3J3bG9jay5oCmluZGV4IDRkMWI0OGM3
MjIuLjQ5ZWE5YzAxMGEgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9y
d2xvY2suaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgKQEAgLTYw
LDYgKzYwLDEwIEBAIHN0YXRpYyBpbmxpbmUgaW50IF9yZWFkX3RyeWxvY2so
cndsb2NrX3QgKmxvY2spCiAgICAgaWYgKCBsaWtlbHkoX2Nhbl9yZWFkX2xv
Y2soY250cykpICkKICAgICB7CiAgICAgICAgIGNudHMgPSAodTMyKWF0b21p
Y19hZGRfcmV0dXJuKF9RUl9CSUFTLCAmbG9jay0+Y250cyk7CisgICAgICAg
IC8qCisgICAgICAgICAqIGF0b21pY19hZGRfcmV0dXJuKCkgaXMgYSBmdWxs
IGJhcnJpZXIgc28gbm8gbmVlZCBmb3IgYW4KKyAgICAgICAgICogYXJjaF9s
b2NrX2FjcXVpcmVfYmFycmllcigpLgorICAgICAgICAgKi8KICAgICAgICAg
aWYgKCBsaWtlbHkoX2Nhbl9yZWFkX2xvY2soY250cykpICkKICAgICAgICAg
ICAgIHJldHVybiAxOwogICAgICAgICBhdG9taWNfc3ViKF9RUl9CSUFTLCAm
bG9jay0+Y250cyk7CkBAIC03OCwxMSArODIsMTkgQEAgc3RhdGljIGlubGlu
ZSB2b2lkIF9yZWFkX2xvY2socndsb2NrX3QgKmxvY2spCiAKICAgICBwcmVl
bXB0X2Rpc2FibGUoKTsKICAgICBjbnRzID0gYXRvbWljX2FkZF9yZXR1cm4o
X1FSX0JJQVMsICZsb2NrLT5jbnRzKTsKKyAgICAvKgorICAgICAqIGF0b21p
Y19hZGRfcmV0dXJuKCkgaXMgYSBmdWxsIGJhcnJpZXIgc28gbm8gbmVlZCBm
b3IgYW4KKyAgICAgKiBhcmNoX2xvY2tfYWNxdWlyZV9iYXJyaWVyKCkuCisg
ICAgICovCiAgICAgaWYgKCBsaWtlbHkoX2Nhbl9yZWFkX2xvY2soY250cykp
ICkKICAgICAgICAgcmV0dXJuOwogCiAgICAgLyogVGhlIHNsb3dwYXRoIHdp
bGwgZGVjcmVtZW50IHRoZSByZWFkZXIgY291bnQsIGlmIG5lY2Vzc2FyeS4g
Ki8KICAgICBxdWV1ZV9yZWFkX2xvY2tfc2xvd3BhdGgobG9jayk7CisgICAg
LyoKKyAgICAgKiBxdWV1ZV9yZWFkX2xvY2tfc2xvd3BhdGgoKSBpcyB1c2lu
ZyBzcGlubG9jayBhbmQgdGhlcmVmb3JlIGlzIGEKKyAgICAgKiBmdWxsIGJh
cnJpZXIuIFNvIG5vIG5lZWQgZm9yIGFuIGFyY2hfbG9ja19hY3F1aXJlX2Jh
cnJpZXIoKS4KKyAgICAgKi8KIH0KIAogc3RhdGljIGlubGluZSB2b2lkIF9y
ZWFkX2xvY2tfaXJxKHJ3bG9ja190ICpsb2NrKQpAQCAtMTA2LDYgKzExOCw3
IEBAIHN0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBfcmVhZF9sb2NrX2ly
cXNhdmUocndsb2NrX3QgKmxvY2spCiAgKi8KIHN0YXRpYyBpbmxpbmUgdm9p
ZCBfcmVhZF91bmxvY2socndsb2NrX3QgKmxvY2spCiB7CisgICAgYXJjaF9s
b2NrX3JlbGVhc2VfYmFycmllcigpOwogICAgIC8qCiAgICAgICogQXRvbWlj
YWxseSBkZWNyZW1lbnQgdGhlIHJlYWRlciBjb3VudAogICAgICAqLwpAQCAt
MTQxLDEyICsxNTQsMjEgQEAgc3RhdGljIGlubGluZSB1bnNpZ25lZCBpbnQg
X3dyaXRlX2xvY2tfdmFsKHZvaWQpCiAgKi8KIHN0YXRpYyBpbmxpbmUgdm9p
ZCBfd3JpdGVfbG9jayhyd2xvY2tfdCAqbG9jaykKIHsKLSAgICAvKiBPcHRp
bWl6ZSBmb3IgdGhlIHVuZmFpciBsb2NrIGNhc2Ugd2hlcmUgdGhlIGZhaXIg
ZmxhZyBpcyAwLiAqLwogICAgIHByZWVtcHRfZGlzYWJsZSgpOworICAgIC8q
CisgICAgICogT3B0aW1pemUgZm9yIHRoZSB1bmZhaXIgbG9jayBjYXNlIHdo
ZXJlIHRoZSBmYWlyIGZsYWcgaXMgMC4KKyAgICAgKgorICAgICAqIGF0b21p
Y19jbXB4Y2hnKCkgaXMgYSBmdWxsIGJhcnJpZXIgc28gbm8gbmVlZCBmb3Ig
YW4KKyAgICAgKiBhcmNoX2xvY2tfYWNxdWlyZV9iYXJyaWVyKCkuCisgICAg
ICovCiAgICAgaWYgKCBhdG9taWNfY21weGNoZygmbG9jay0+Y250cywgMCwg
X3dyaXRlX2xvY2tfdmFsKCkpID09IDAgKQogICAgICAgICByZXR1cm47CiAK
ICAgICBxdWV1ZV93cml0ZV9sb2NrX3Nsb3dwYXRoKGxvY2spOworICAgIC8q
CisgICAgICogcXVldWVfd3JpdGVfbG9ja19zbG93cGF0aCgpIGlzIHVzaW5n
IHNwaW5sb2NrIGFuZCB0aGVyZWZvcmUgaXMgYQorICAgICAqIGZ1bGwgYmFy
cmllci4gU28gbm8gbmVlZCBmb3IgYW4gYXJjaF9sb2NrX2FjcXVpcmVfYmFy
cmllcigpLgorICAgICAqLwogfQogCiBzdGF0aWMgaW5saW5lIHZvaWQgX3dy
aXRlX2xvY2tfaXJxKHJ3bG9ja190ICpsb2NrKQpAQCAtMTgzLDEyICsyMDUs
MTcgQEAgc3RhdGljIGlubGluZSBpbnQgX3dyaXRlX3RyeWxvY2socndsb2Nr
X3QgKmxvY2spCiAgICAgICAgIHJldHVybiAwOwogICAgIH0KIAorICAgIC8q
CisgICAgICogYXRvbWljX2NtcHhjaGcoKSBpcyBhIGZ1bGwgYmFycmllciBz
byBubyBuZWVkIGZvciBhbgorICAgICAqIGFyY2hfbG9ja19hY3F1aXJlX2Jh
cnJpZXIoKS4KKyAgICAgKi8KICAgICByZXR1cm4gMTsKIH0KIAogc3RhdGlj
IGlubGluZSB2b2lkIF93cml0ZV91bmxvY2socndsb2NrX3QgKmxvY2spCiB7
CiAgICAgQVNTRVJUKF9pc193cml0ZV9sb2NrZWRfYnlfbWUoYXRvbWljX3Jl
YWQoJmxvY2stPmNudHMpKSk7CisgICAgYXJjaF9sb2NrX3JlbGVhc2VfYmFy
cmllcigpOwogICAgIGF0b21pY19hbmQofihfUVdfQ1BVTUFTSyB8IF9RV19X
TUFTSyksICZsb2NrLT5jbnRzKTsKICAgICBwcmVlbXB0X2VuYWJsZSgpOwog
fQotLSAKMi4xNy4xCgo=

--=separator
Content-Type: application/octet-stream; name="xsa314-4.13.patch"
Content-Disposition: attachment; filename="xsa314-4.13.patch"
Content-Transfer-Encoding: base64

RnJvbSBhYjQ5ZjAwNWY3ZDAxZDQwMDRkNzZmMmUyOTVkMzFhY2E3ZDRmOTNh
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWxpZW4gR3JhbGwg
PGpncmFsbEBhbWF6b24uY29tPgpEYXRlOiBUaHUsIDIwIEZlYiAyMDIwIDIw
OjU0OjQwICswMDAwClN1YmplY3Q6IFtQQVRDSF0geGVuL3J3bG9jazogQWRk
IG1pc3NpbmcgbWVtb3J5IGJhcnJpZXIgaW4gdGhlIHVubG9jayBwYXRoIG9m
CiByd2xvY2sKClRoZSByd2xvY2sgdW5sb2NrIHBhdGhzIGFyZSB1c2luZyBh
dG9taWNfc3ViKCkgdG8gcmVsZWFzZSB0aGUgbG9jay4KSG93ZXZlciB0aGUg
aW1wbGVtZW50YXRpb24gb2YgYXRvbWljX3N1YigpIHJpZ2h0ZnVsbHkgZG9l
c24ndCBjb250YWluIGEKbWVtb3J5IGJhcnJpZXIuIE9uIEFybSwgdGhpcyBt
ZWFucyBhIHByb2Nlc3NvciBpcyBhbGxvd2VkIHRvIHJlLW9yZGVyCnRoZSBt
ZW1vcnkgYWNjZXNzIHdpdGggdGhlIHByZWNlZWRpbmcgYWNjZXNzLgoKSW4g
b3RoZXIgd29yZHMsIHRoZSB1bmxvY2sgbWF5IGJlIHNlZW4gYnkgYW5vdGhl
ciBwcm9jZXNzb3IgYmVmb3JlIGFsbAp0aGUgbWVtb3J5IGFjY2Vzc2VzIHdp
dGhpbiB0aGUgImNyaXRpY2FsIiBzZWN0aW9uLgoKVGhlIHJ3bG9jayBwYXRo
cyBhbHJlYWR5IGNvbnRhaW5zIGJhcnJpZXIgaW5kaXJlY3RseSwgYnV0IHRo
ZXkgYXJlIG5vdAp2ZXJ5IHVzZWZ1bCB3aXRob3V0IHRoZSBjb3VudGVycGFy
dCBpbiB0aGUgdW5sb2NrIHBhdGhzLgoKVGhlIG1lbW9yeSBiYXJyaWVycyBh
cmUgbm90IG5lY2Vzc2FyeSBvbiB4ODYgYmVjYXVzZSBsb2Fkcy9zdG9yZXMg
YXJlCm5vdCByZS1vcmRlcmVkIHdpdGggbG9jayBpbnN0cnVjdGlvbnMuCgpT
byBhZGQgYXJjaF9sb2NrX3JlbGVhc2VfYmFycmllcigpIGluIHRoZSB1bmxv
Y2sgcGF0aHMgdGhhdCB3aWxsIG9ubHkKYWRkIG1lbW9yeSBiYXJyaWVyIG9u
IEFybS4KClRha2UgdGhlIG9wcG9ydHVuaXR5IHRvIGRvY3VtZW50IGVhY2gg
bG9jayBwYXRocyBleHBsYWluaW5nIHdoeSBhCmJhcnJpZXIgaXMgbm90IG5l
Y2Vzc2FyeS4KClRoaXMgaXMgWFNBLTMxNC4KClNpZ25lZC1vZmYtYnk6IEp1
bGllbiBHcmFsbCA8amdyYWxsQGFtYXpvbi5jb20+ClJldmlld2VkLWJ5OiBK
YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClJldmlld2VkLWJ5OiBT
dGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+Cgot
LS0KIHhlbi9pbmNsdWRlL3hlbi9yd2xvY2suaCB8IDI5ICsrKysrKysrKysr
KysrKysrKysrKysrKysrKystCiAxIGZpbGUgY2hhbmdlZCwgMjggaW5zZXJ0
aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL3hlbi9pbmNs
dWRlL3hlbi9yd2xvY2suaCBiL3hlbi9pbmNsdWRlL3hlbi9yd2xvY2suaApp
bmRleCAzZGZlYTFhYzJhLi41MTY0ODYzMDZmIDEwMDY0NAotLS0gYS94ZW4v
aW5jbHVkZS94ZW4vcndsb2NrLmgKKysrIGIveGVuL2luY2x1ZGUveGVuL3J3
bG9jay5oCkBAIC00OCw2ICs0OCwxMCBAQCBzdGF0aWMgaW5saW5lIGludCBf
cmVhZF90cnlsb2NrKHJ3bG9ja190ICpsb2NrKQogICAgIGlmICggbGlrZWx5
KCEoY250cyAmIF9RV19XTUFTSykpICkKICAgICB7CiAgICAgICAgIGNudHMg
PSAodTMyKWF0b21pY19hZGRfcmV0dXJuKF9RUl9CSUFTLCAmbG9jay0+Y250
cyk7CisgICAgICAgIC8qCisgICAgICAgICAqIGF0b21pY19hZGRfcmV0dXJu
KCkgaXMgYSBmdWxsIGJhcnJpZXIgc28gbm8gbmVlZCBmb3IgYW4KKyAgICAg
ICAgICogYXJjaF9sb2NrX2FjcXVpcmVfYmFycmllcigpLgorICAgICAgICAg
Ki8KICAgICAgICAgaWYgKCBsaWtlbHkoIShjbnRzICYgX1FXX1dNQVNLKSkg
KQogICAgICAgICAgICAgcmV0dXJuIDE7CiAgICAgICAgIGF0b21pY19zdWIo
X1FSX0JJQVMsICZsb2NrLT5jbnRzKTsKQEAgLTY0LDExICs2OCwxOSBAQCBz
dGF0aWMgaW5saW5lIHZvaWQgX3JlYWRfbG9jayhyd2xvY2tfdCAqbG9jaykK
ICAgICB1MzIgY250czsKIAogICAgIGNudHMgPSBhdG9taWNfYWRkX3JldHVy
bihfUVJfQklBUywgJmxvY2stPmNudHMpOworICAgIC8qCisgICAgICogYXRv
bWljX2FkZF9yZXR1cm4oKSBpcyBhIGZ1bGwgYmFycmllciBzbyBubyBuZWVk
IGZvciBhbgorICAgICAqIGFyY2hfbG9ja19hY3F1aXJlX2JhcnJpZXIoKS4K
KyAgICAgKi8KICAgICBpZiAoIGxpa2VseSghKGNudHMgJiBfUVdfV01BU0sp
KSApCiAgICAgICAgIHJldHVybjsKIAogICAgIC8qIFRoZSBzbG93cGF0aCB3
aWxsIGRlY3JlbWVudCB0aGUgcmVhZGVyIGNvdW50LCBpZiBuZWNlc3Nhcnku
ICovCiAgICAgcXVldWVfcmVhZF9sb2NrX3Nsb3dwYXRoKGxvY2spOworICAg
IC8qCisgICAgICogcXVldWVfcmVhZF9sb2NrX3Nsb3dwYXRoKCkgaXMgdXNp
bmcgc3BpbmxvY2sgYW5kIHRoZXJlZm9yZSBpcyBhCisgICAgICogZnVsbCBi
YXJyaWVyLiBTbyBubyBuZWVkIGZvciBhbiBhcmNoX2xvY2tfYWNxdWlyZV9i
YXJyaWVyKCkuCisgICAgICovCiB9CiAKIHN0YXRpYyBpbmxpbmUgdm9pZCBf
cmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKQEAgLTkyLDYgKzEwNCw3
IEBAIHN0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBfcmVhZF9sb2NrX2ly
cXNhdmUocndsb2NrX3QgKmxvY2spCiAgKi8KIHN0YXRpYyBpbmxpbmUgdm9p
ZCBfcmVhZF91bmxvY2socndsb2NrX3QgKmxvY2spCiB7CisgICAgYXJjaF9s
b2NrX3JlbGVhc2VfYmFycmllcigpOwogICAgIC8qCiAgICAgICogQXRvbWlj
YWxseSBkZWNyZW1lbnQgdGhlIHJlYWRlciBjb3VudAogICAgICAqLwpAQCAt
MTIxLDExICsxMzQsMjAgQEAgc3RhdGljIGlubGluZSBpbnQgX3J3X2lzX2xv
Y2tlZChyd2xvY2tfdCAqbG9jaykKICAqLwogc3RhdGljIGlubGluZSB2b2lk
IF93cml0ZV9sb2NrKHJ3bG9ja190ICpsb2NrKQogewotICAgIC8qIE9wdGlt
aXplIGZvciB0aGUgdW5mYWlyIGxvY2sgY2FzZSB3aGVyZSB0aGUgZmFpciBm
bGFnIGlzIDAuICovCisgICAgLyoKKyAgICAgKiBPcHRpbWl6ZSBmb3IgdGhl
IHVuZmFpciBsb2NrIGNhc2Ugd2hlcmUgdGhlIGZhaXIgZmxhZyBpcyAwLgor
ICAgICAqCisgICAgICogYXRvbWljX2NtcHhjaGcoKSBpcyBhIGZ1bGwgYmFy
cmllciBzbyBubyBuZWVkIGZvciBhbgorICAgICAqIGFyY2hfbG9ja19hY3F1
aXJlX2JhcnJpZXIoKS4KKyAgICAgKi8KICAgICBpZiAoIGF0b21pY19jbXB4
Y2hnKCZsb2NrLT5jbnRzLCAwLCBfUVdfTE9DS0VEKSA9PSAwICkKICAgICAg
ICAgcmV0dXJuOwogCiAgICAgcXVldWVfd3JpdGVfbG9ja19zbG93cGF0aChs
b2NrKTsKKyAgICAvKgorICAgICAqIHF1ZXVlX3dyaXRlX2xvY2tfc2xvd3Bh
dGgoKSBpcyB1c2luZyBzcGlubG9jayBhbmQgdGhlcmVmb3JlIGlzIGEKKyAg
ICAgKiBmdWxsIGJhcnJpZXIuIFNvIG5vIG5lZWQgZm9yIGFuIGFyY2hfbG9j
a19hY3F1aXJlX2JhcnJpZXIoKS4KKyAgICAgKi8KIH0KIAogc3RhdGljIGlu
bGluZSB2b2lkIF93cml0ZV9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKQEAg
LTE1NywxMSArMTc5LDE2IEBAIHN0YXRpYyBpbmxpbmUgaW50IF93cml0ZV90
cnlsb2NrKHJ3bG9ja190ICpsb2NrKQogICAgIGlmICggdW5saWtlbHkoY250
cykgKQogICAgICAgICByZXR1cm4gMDsKIAorICAgIC8qCisgICAgICogYXRv
bWljX2NtcHhjaGcoKSBpcyBhIGZ1bGwgYmFycmllciBzbyBubyBuZWVkIGZv
ciBhbgorICAgICAqIGFyY2hfbG9ja19hY3F1aXJlX2JhcnJpZXIoKS4KKyAg
ICAgKi8KICAgICByZXR1cm4gbGlrZWx5KGF0b21pY19jbXB4Y2hnKCZsb2Nr
LT5jbnRzLCAwLCBfUVdfTE9DS0VEKSA9PSAwKTsKIH0KIAogc3RhdGljIGlu
bGluZSB2b2lkIF93cml0ZV91bmxvY2socndsb2NrX3QgKmxvY2spCiB7Cisg
ICAgYXJjaF9sb2NrX3JlbGVhc2VfYmFycmllcigpOwogICAgIC8qCiAgICAg
ICogSWYgdGhlIHdyaXRlciBmaWVsZCBpcyBhdG9taWMsIGl0IGNhbiBiZSBj
bGVhcmVkIGRpcmVjdGx5LgogICAgICAqIE90aGVyd2lzZSwgYW4gYXRvbWlj
IHN1YnRyYWN0aW9uIHdpbGwgYmUgdXNlZCB0byBjbGVhciBpdC4KLS0gCjIu
MTcuMQoK

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 12:01:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 12:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOKFl-0007ka-8w; Tue, 14 Apr 2020 12:01:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=/bN9=56=xenbits.xen.org=iwj@srs-us1.protection.inumbo.net>)
 id 1jOKFj-0007jP-32
 for xen-devel@lists.xen.org; Tue, 14 Apr 2020 12:01:19 +0000
X-Inumbo-ID: 97cf226a-7e47-11ea-8927-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 97cf226a-7e47-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 12:00:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=LgG6yNBk6P6fulZ3TDuK42nX5L8NWGH0VJ9PKzbpb4w=; b=f+XLhCs5NJwWOX0af8pWUNosyf
 IHue8q37Qy5Eq8W3ml8vbj0A98N3NKuKJOh6LguhENaX2OLTDrrikXsf4FhqEVxpcB7u1Z2KBT/b4
 8mLo/5REBYj1nr99JPsUyijycpZ5c4/mUt1+m0X8CcvUT3hRh6OeImV9XI3XsDWE06o4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <iwj@xenbits.xen.org>)
 id 1jOKFE-0000Yj-9E; Tue, 14 Apr 2020 12:00:48 +0000
Received: from iwj by xenbits.xenproject.org with local (Exim 4.89)
 (envelope-from <iwj@xenbits.xen.org>)
 id 1jOKFE-00074e-81; Tue, 14 Apr 2020 12:00:48 +0000
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.508 (Entity 5.508)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Subject: Xen Security Advisory 316 v3 (CVE-2020-11743) - Bad error path in
 GNTTABOP_map_grant
Message-Id: <E1jOKFE-00074e-81@xenbits.xenproject.org>
Date: Tue, 14 Apr 2020 12:00:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "Xen.org security team" <security-team-members@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2020-11743 / XSA-316
                               version 3

                 Bad error path in GNTTABOP_map_grant

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

Grant table operations are expected to return 0 for success, and a
negative number for errors.  Some misplaced brackets cause one error
path to return 1 instead of a negative value.

The grant table code in Linux treats this condition as success, and
proceeds with incorrectly initialised state.

IMPACT
======

A buggy or malicious guest can construct its grant table in such a way
that, when a backend domain tries to map a grant, it hits the incorrect
error path.

This will crash a Linux based dom0 or backend domain.

VULNERABLE SYSTEMS
==================

Systems running any version of Xen with the XSA-295 fixes are
vulnerable.  Systems which have not yet taken the XSA-295 fixes are not
vulnerable.

Systems running a Linux based dom0 or driver domain are vulnerable.

Systems running a FreeBSD or NetBSD based dom0 or driver domain are not
impacted, as they both treat any nonzero value as a failure.

The vulnerability of other systems will depend on how they behave when
getting an unexpected positive number from the GNTTABOP_map_grant
hypercall.

MITIGATION
==========

Applying the Linux patches alone is sufficient to mitigate the issue.
This might be a preferred route for downstreams who support livepatching
Linux but not Xen.

CREDITS
=======

This issue was discovered by Ross Lagerwall of Citrix.

RESOLUTION
==========

Applying the appropriate Xen patch will resolve this issue.

Additionally, a Linux patch is provided to make Linux's behaviour more
robust to unexpected values.

We recommend taking both patches if at all possible.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa316/xsa316-xen.patch       Xen 4.9 - xen-unstable
xsa316/xsa316-linux.patch     Linux

$ sha256sum xsa316*/*
7dcd02e8cc0434046747d572bc6c77cd3a2e4041eefd2fa703f4130e998b58dd  xsa316/xsa316-linux.patch
4007578e30730861750d8808c0b63f2e03bbb05df909d71de19201084816a8b9  xsa316/xsa316-xen.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl6Vpd0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZjOgH/1xKsvqDnR04knl9OWvgL690gqxZpwliRRDwwkWh
1kOHJq2jsvm5bq38fYY9WpvmtvHW/RoM53Kacyz1Rl0y9VvK6hDU7P5np4WkMueX
iEJOcIbQau1Pg8/zD8hYkqNNGTCjb79ZhggTih1HxpeZJTa7TJv9bNsZpCQkw+P/
EBXpfsqoPqAMN1qt5PclCT5zlasyBUVjW6+lF3tF6q77knQoWNpKbIOSqL2/V2/p
vUMP/qyUikWW8JLH8N48jpRmFzjxwoDI4/3E1sbSv2VxlX1FksbZxan1cwcjoSG6
004GYSxqOjP4oPEAOrC6sXxc6DKoLLa8SVzYNhkg3XoScY0=
=qCJA
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa316/xsa316-linux.patch"
Content-Disposition: attachment; filename="xsa316/xsa316-linux.patch"
Content-Transfer-Encoding: base64

RnJvbTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPgpTdWJqZWN0
OiB4ZW4veGVuYnVzOiBlbnN1cmUgeGVuYnVzX21hcF9yaW5nX3ZhbGxvYygp
IHJldHVybnMgcHJvcGVyIGdyYW50IHN0YXR1cwoKeGVuYnVzX21hcF9yaW5n
X3ZhbGxvYygpIG1hcHMgYSByaW5nIHBhZ2UgYW5kIHJldHVybnMgdGhlIHN0
YXR1cyBvZiB0aGUKdXNlZCBncmFudCAoMCBtZWFuaW5nIHN1Y2Nlc3MpLgoK
VGhlcmUgYXJlIFhlbiBoeXBlcnZpc29ycyB3aGljaCBtaWdodCByZXR1cm4g
dGhlIHZhbHVlIDEgZm9yIHRoZSBzdGF0dXMKb2YgYSBmYWlsZWQgZ3JhbnQg
bWFwcGluZyBkdWUgdG8gYSBidWcuIFNvbWUgY2FsbGVycyBvZgp4ZW5idXNf
bWFwX3JpbmdfdmFsbG9jKCkgdGVzdCBmb3IgZXJyb3JzIGJ5IHRlc3Rpbmcg
dGhlIHJldHVybmVkIHN0YXR1cwp0byBiZSBsZXNzIHRoYW4gemVybywgcmVz
dWx0aW5nIGluIG5vIGVycm9yIGRldGVjdGVkIGFuZCBjcmFzaGluZyBsYXRl
cgpkdWUgdG8gYSBub3QgYXZhaWxhYmxlIHJpbmcgcGFnZS4KClNldCB0aGUg
cmV0dXJuIHZhbHVlIG9mIHhlbmJ1c19tYXBfcmluZ192YWxsb2MoKSB0byBH
TlRTVF9nZW5lcmFsX2Vycm9yCmluIGNhc2UgdGhlIGdyYW50IHN0YXR1cyBy
ZXBvcnRlZCBieSBYZW4gaXMgZ3JlYXRlciB0aGFuIHplcm8uCgpUaGlzIGlz
IHBhcnQgb2YgWFNBLTMxNi4KClNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jv
c3MgPGpncm9zc0BzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IFdlaSBMaXUgPHds
QHhlbi5vcmc+CgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4veGVuYnVzL3hl
bmJ1c19jbGllbnQuYyBiL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfY2xp
ZW50LmMKaW5kZXggZTE3Y2E4MTU2MTcxLi5hMzgyOTJlZjc5ZjYgMTAwNjQ0
Ci0tLSBhL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfY2xpZW50LmMKKysr
IGIvZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c19jbGllbnQuYwpAQCAtNDQ4
LDcgKzQ0OCwxNCBAQCBFWFBPUlRfU1lNQk9MX0dQTCh4ZW5idXNfZnJlZV9l
dnRjaG4pOwogaW50IHhlbmJ1c19tYXBfcmluZ192YWxsb2Moc3RydWN0IHhl
bmJ1c19kZXZpY2UgKmRldiwgZ3JhbnRfcmVmX3QgKmdudF9yZWZzLAogCQkJ
ICAgdW5zaWduZWQgaW50IG5yX2dyZWZzLCB2b2lkICoqdmFkZHIpCiB7Ci0J
cmV0dXJuIHJpbmdfb3BzLT5tYXAoZGV2LCBnbnRfcmVmcywgbnJfZ3JlZnMs
IHZhZGRyKTsKKwlpbnQgZXJyOworCisJZXJyID0gcmluZ19vcHMtPm1hcChk
ZXYsIGdudF9yZWZzLCBucl9ncmVmcywgdmFkZHIpOworCS8qIFNvbWUgaHlw
ZXJ2aXNvcnMgYXJlIGJ1Z2d5IGFuZCBjYW4gcmV0dXJuIDEuICovCisJaWYg
KGVyciA+IDApCisJCWVyciA9IEdOVFNUX2dlbmVyYWxfZXJyb3I7CisKKwly
ZXR1cm4gZXJyOwogfQogRVhQT1JUX1NZTUJPTF9HUEwoeGVuYnVzX21hcF9y
aW5nX3ZhbGxvYyk7CiAK

--=separator
Content-Type: application/octet-stream; name="xsa316/xsa316-xen.patch"
Content-Disposition: attachment; filename="xsa316/xsa316-xen.patch"
Content-Transfer-Encoding: base64

RnJvbTogUm9zcyBMYWdlcndhbGwgPHJvc3MubGFnZXJ3YWxsQGNpdHJpeC5j
b20+ClN1YmplY3Q6IHhlbi9nbnR0YWI6IEZpeCBlcnJvciBwYXRoIGluIG1h
cF9ncmFudF9yZWYoKQoKUGFydCBvZiBYU0EtMjk1IChjL3MgODYzZTc0ZWIy
Y2ZmYikgaW5hZHZlcnRlbnRseSByZS1wb3NpdGlvbmVkIHRoZSBicmFja2V0
cywKY2hhbmdpbmcgdGhlIGxvZ2ljLiAgSWYgdGhlIF9zZXRfc3RhdHVzKCkg
Y2FsbCBmYWlscywgdGhlIGdyYW50X21hcCBoeXBlcmNhbGwKd291bGQgZmFp
bCB3aXRoIGEgc3RhdHVzIG9mIDEgKHJjICE9IEdOVFNUX29rYXkpIGluc3Rl
YWQgb2YgdGhlIGV4cGVjdGVkCm5lZ2F0aXZlIEdOVFNUXyogZXJyb3IuCgpU
aGlzIGVycm9yIHBhdGggY2FuIGJlIHRha2VuIGR1ZSB0byBiYWQgZ3Vlc3Qg
c3RhdGUsIGFuZCBjYXVzZXMgbmV0L2Jsay1iYWNrCmluIExpbnV4IHRvIGNy
YXNoLgoKVGhpcyBpcyBYU0EtMzE2LgoKU2lnbmVkLW9mZi1ieTogUm9zcyBM
YWdlcndhbGwgPHJvc3MubGFnZXJ3YWxsQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t
PgpSZXZpZXdlZC1ieTogSnVsaWVuIEdyYWxsIDxqZ3JhbGxAYW1hem9uLmNv
bT4KCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL2dyYW50X3RhYmxlLmMgYi94
ZW4vY29tbW9uL2dyYW50X3RhYmxlLmMKaW5kZXggOWZkNmU2MDQxNi4uNGI1
MzQ0ZGMyMSAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9ncmFudF90YWJsZS5j
CisrKyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYwpAQCAtMTAzMSw3ICsx
MDMxLDcgQEAgbWFwX2dyYW50X3JlZigKICAgICB7CiAgICAgICAgIGlmICgg
KHJjID0gX3NldF9zdGF0dXMoc2hhaCwgc3RhdHVzLCByZCwgcmd0LT5ndF92
ZXJzaW9uLCBhY3QsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
b3AtPmZsYWdzICYgR05UTUFQX3JlYWRvbmx5LCAxLAotICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGxkLT5kb21haW5faWQpICE9IEdOVFNUX29r
YXkpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsZC0+ZG9t
YWluX2lkKSkgIT0gR05UU1Rfb2theSApCiAgICAgICAgICAgICBnb3RvIGFj
dF9yZWxlYXNlX291dDsKIAogICAgICAgICBpZiAoICFhY3QtPnBpbiApCg==

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 12:01:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 12:01:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOKFo-0007n1-Lv; Tue, 14 Apr 2020 12:01:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=/bN9=56=xenbits.xen.org=iwj@srs-us1.protection.inumbo.net>)
 id 1jOKFo-0007mZ-3H
 for xen-devel@lists.xen.org; Tue, 14 Apr 2020 12:01:24 +0000
X-Inumbo-ID: 997cd0da-7e47-11ea-8927-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 997cd0da-7e47-11ea-8927-12813bfff9fa;
 Tue, 14 Apr 2020 12:00:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=aRHmPYnG67uS0Qn4gfeD/shmRqkCxEqOSp7XObEeC28=; b=jrMr+KPRHX8NIRltmsAyItgJSK
 qWlGLhLanN1y/HTP1Hv1D90vUK653NrQxUWbQMUi0TmUw0FTfGSupqxOZaUm2TDQLvHGqqqhOBQTA
 Bw2S4LXTF6MJWhUDejaUoHpfKuPM09JhOgAYs7dc5ZWvQhuPyvr24UX5LpsdBLuwD5k4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <iwj@xenbits.xen.org>)
 id 1jOKFH-0000Zg-K7; Tue, 14 Apr 2020 12:00:51 +0000
Received: from iwj by xenbits.xenproject.org with local (Exim 4.89)
 (envelope-from <iwj@xenbits.xen.org>)
 id 1jOKFH-00075Y-Iw; Tue, 14 Apr 2020 12:00:51 +0000
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.508 (Entity 5.508)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Subject: Xen Security Advisory 318 v3 (CVE-2020-11742) - Bad continuation
 handling in GNTTABOP_copy
Message-Id: <E1jOKFH-00075Y-Iw@xenbits.xenproject.org>
Date: Tue, 14 Apr 2020 12:00:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "Xen.org security team" <security-team-members@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2020-11742 / XSA-318
                               version 3

              Bad continuation handling in GNTTABOP_copy

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

Grant table operations are expected to return 0 for success, and a
negative number for errors.  The fix for CVE-2017-12135 / XSA-226
introduced a path through grant copy handling where success may be
returned to the caller without any action taken.

In particular the status fields of individual operations are left
uninitialised, and may result in errant behaviour in the caller of
GNTTABOP_copy.

IMPACT
======

A buggy or malicious guest can construct its grant table in such a way
that, when a backend domain tries to copy a grant, it hits the incorrect
exit path.

This returns success to the caller without doing anything, which may
cause in crashes or other incorrect behaviour.

VULNERABLE SYSTEMS
==================

Systems running any version of Xen are vulnerable.

MITIGATION
==========

Only guests with access to transitive grants can exploit the
vulnerability.  In particular, this means that:

 * ARM systems which have taken the XSA-268 fix are not vulnerable, as
   Grant Table v2 was disabled for other security reasons.

 * All systems with the XSA-226 fixes, and booted with
   `gnttab=max-ver:1` or `gnttab=no-transitive` are not vulnerable.

CREDITS
=======

This issue was discovered by Pawel Wieczorkiewicz of Amazon and Jürgen
Groß of SUSE.

RESOLUTION
==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa318.patch       Xen 4.9 - xen-unstable

$ sha256sum xsa318*
4618c2609ab08178977c2b2a3d13f380ccfddd0168caca5ced708dd76a8e547c  xsa318.patch
$

NOTE CONCERNING SHORT EMBARGO
=============================

This issue was discovered in response to the XSA-316 predisclosure.

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

However, deployment of the mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because it is a guest visible change which will draw attention
to the issue.
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl6Vpd4MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZbC8IAIkpehqymi1+zrWN1OHdvIYIMv2TCzSSx3UtsoMk
J67FpgDzX8ZLfiE0x5FELs3KUdILOe5IkEmM2ssrvQRoIp+X3U4Ybm6eoIB+BzjD
bmJReqNYVY6dlJuAhO2i6L125uBITWdntlK/ZOOQAOd77hR2KueuGELV7KUoPbQa
SAiQ8jsCjqWCacYll6oq1c7jRlc1+RD/5JjkGveHlLmLOnIiS96PkDzqskM8Aniz
TLZ4WmIpfixDAHn3OYyHGoUyhNW3qlps3evDyj3Wela62LFsymDSHkcV8XFBLTGT
pueuSELzne5m85moAB2UqKVhHDV+PRCV7bLHYm/s7yeIHSg=
=hix9
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa318.patch"
Content-Disposition: attachment; filename="xsa318.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiBnbnR0YWI6IGZpeCBHTlRUQUJPUF9jb3B5IGNvbnRpbnVhdGlvbiBoYW5k
bGluZwoKVGhlIFhTQS0yMjYgZml4IHdhcyBmbGF3ZWQgLSB0aGUgYmFja3dh
cmRzIHRyYW5zZm9ybWF0aW9uIG9uIHJjIHdhcyBkb25lCnRvbyBlYXJseSwg
Y2F1c2luZyBhIGNvbnRpbnVhdGlvbiB0byBub3QgZ2V0IGludm9rZWQgd2hl
biB0aGUgbmVlZCBmb3IKcHJlZW1wdGlvbiB3YXMgZGV0ZXJtaW5lZCBhdCB0
aGUgdmVyeSBmaXJzdCBpdGVyYXRpb24gb2YgdGhlIHJlcXVlc3QuClRoaXMg
aW4gcGFydGljdWxhciBtZWFucyB0aGF0IGFsbCBvZiB0aGUgc3RhdHVzIGZp
ZWxkcyBvZiB0aGUgaW5kaXZpZHVhbApvcGVyYXRpb25zIHdvdWxkIGJlIGxl
ZnQgdW50b3VjaGVkLCBpLmUuIHNldCB0byB3aGF0ZXZlciB0aGUgY2FsbGVy
IG1heQpvciBtYXkgbm90IGhhdmUgaW5pdGlhbGl6ZWQgdGhlbSB0by4KClRo
aXMgaXMgcGFydCBvZiBYU0EtMzE4LgoKUmVwb3J0ZWQtYnk6IFBhd2VsIFdp
ZWN6b3JraWV3aWN6IDx3aXBhd2VsQGFtYXpvbi5kZT4KVGVzdGVkLWJ5OiBQ
YXdlbCBXaWVjem9ya2lld2ljeiA8d2lwYXdlbEBhbWF6b24uZGU+ClNpZ25l
ZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2
aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4KCi0t
LSBhL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYworKysgYi94ZW4vY29tbW9u
L2dyYW50X3RhYmxlLmMKQEAgLTM1NzYsOCArMzU3Niw3IEBAIGRvX2dyYW50
X3RhYmxlX29wKAogICAgICAgICByYyA9IGdudHRhYl9jb3B5KGNvcHksIGNv
dW50KTsKICAgICAgICAgaWYgKCByYyA+IDAgKQogICAgICAgICB7Ci0gICAg
ICAgICAgICByYyA9IGNvdW50IC0gcmM7Ci0gICAgICAgICAgICBndWVzdF9o
YW5kbGVfYWRkX29mZnNldChjb3B5LCByYyk7CisgICAgICAgICAgICBndWVz
dF9oYW5kbGVfYWRkX29mZnNldChjb3B5LCBjb3VudCAtIHJjKTsKICAgICAg
ICAgICAgIHVvcCA9IGd1ZXN0X2hhbmRsZV9jYXN0KGNvcHksIHZvaWQpOwog
ICAgICAgICB9CiAgICAgICAgIGJyZWFrOwpAQCAtMzY0NCw2ICszNjQzLDkg
QEAgZG9fZ3JhbnRfdGFibGVfb3AoCiAgIG91dDoKICAgICBpZiAoIHJjID4g
MCB8fCBvcGFxdWVfb3V0ICE9IDAgKQogICAgIHsKKyAgICAgICAgLyogQWRq
dXN0IHJjLCBzZWUgZ250dGFiX2NvcHkoKSBmb3Igd2h5IHRoaXMgaXMgbmVl
ZGVkLiAqLworICAgICAgICBpZiAoIGNtZCA9PSBHTlRUQUJPUF9jb3B5ICkK
KyAgICAgICAgICAgIHJjID0gY291bnQgLSByYzsKICAgICAgICAgQVNTRVJU
KHJjIDwgY291bnQpOwogICAgICAgICBBU1NFUlQoKG9wYXF1ZV9vdXQgJiBH
TlRUQUJPUF9DTURfTUFTSykgPT0gMCk7CiAgICAgICAgIHJjID0gaHlwZXJj
YWxsX2NyZWF0ZV9jb250aW51YXRpb24oX19IWVBFUlZJU09SX2dyYW50X3Rh
YmxlX29wLCAiaWhpIiwK

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 12:14:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 12:14:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOKSb-00029M-5F; Tue, 14 Apr 2020 12:14:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOKSa-00029B-3S
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 12:14:36 +0000
X-Inumbo-ID: 80d2288a-7e49-11ea-8928-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 80d2288a-7e49-11ea-8928-12813bfff9fa;
 Tue, 14 Apr 2020 12:14:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586866476;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=kgWPLuNDZlpjxPv12VjGHkKvWtekNwVRANDpyMTHKGo=;
 b=ONcagt/ZcR0MtaoHKXlpJQF9PaExFECOS8nUuDzXTPHfRHKWRCm/O0A8
 XHUnZOZJtAxPdtNvuFSYbgqAU7kpDn/Zkuuu9WCQ+BBmhOvRadMLt5LKG
 h9NBziS34xrXK63bXhyq4G6DJmEt1zgtj8PjRISvpnZyjyBnXYaUnYT38 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: JcXBX/xzh2A5GRXFwQsJvmtN95l6wgl2UkLOT6Sy55EMN4kNaRLu/hOmcqGvAE46WzB7z/A3bM
 quygnqwB3NoXUjkT0yc6R4tdCr0Jm1n5YWGtPcVWOsE3pJvJ++LIm2hjWV6fv0EimPYRmov31v
 geGB2UA0V752BJ3qaWzHjLolQjDSfJnSe6M0ukVS0wGDGEMaqCM2djVHQF/NRegUlabkTf0mhQ
 0qLbNZa8jf2PFlKV1C1H8ctSnu0m/4h7CdfHgHLMOoqNjCahCV55qs1oFok2RZGSCJX01wexn4
 OgA=
X-SBRS: 2.7
X-MesageID: 15621407
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="15621407"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/svm: Don't use vmcb->tlb_control as if it is a boolean
Date: Tue, 14 Apr 2020 13:14:29 +0100
Message-ID: <20200414121429.10196-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

svm_asid_handle_vmrun() treats tlb_control as if it were boolean, but this has
been superseded by new additions to the SVM spec.

Introduce an enum containing all legal values, and update
svm_asid_handle_vmrun() to use appropriate constants.

While adjusting this, take the opportunity to fix up two coding style issues,
and trim the include list.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>

N.B. Deliberately not updating the code to use TLB_CTRL_FLUSH_ASID.  The
safety of the current ASID logic depends on flusing everything when the ASID
wraps.
---
 xen/arch/x86/hvm/svm/asid.c        | 14 ++++++--------
 xen/include/asm-x86/hvm/svm/vmcb.h | 13 ++++++++++++-
 2 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c
index e554e25213..b7a737fdc1 100644
--- a/xen/arch/x86/hvm/svm/asid.c
+++ b/xen/arch/x86/hvm/svm/asid.c
@@ -15,12 +15,9 @@
  * this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
-#include <xen/init.h>
-#include <xen/lib.h>
-#include <xen/perfc.h>
-#include <asm/hvm/svm/asid.h>
 #include <asm/amd.h>
 #include <asm/hvm/nestedhvm.h>
+#include <asm/hvm/svm/asid.h>
 
 void svm_asid_init(const struct cpuinfo_x86 *c)
 {
@@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
     struct hvm_vcpu_asid *p_asid =
         nestedhvm_vcpu_in_guestmode(curr)
         ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
-    bool_t need_flush = hvm_asid_handle_vmenter(p_asid);
+    bool need_flush = hvm_asid_handle_vmenter(p_asid);
 
     /* ASID 0 indicates that ASIDs are disabled. */
     if ( p_asid->asid == 0 )
     {
         vmcb_set_guest_asid(vmcb, 1);
-        vmcb->tlb_control = 1;
+        vmcb->tlb_control = TLB_CTRL_FLUSH_ALL;
         return;
     }
 
-    if (vmcb_get_guest_asid(vmcb) != p_asid->asid)
+    if ( vmcb_get_guest_asid(vmcb) != p_asid->asid )
         vmcb_set_guest_asid(vmcb, p_asid->asid);
-    vmcb->tlb_control = need_flush;
+
+    vmcb->tlb_control = need_flush ? TLB_CTRL_FLUSH_ALL : TLB_CTRL_NO_FLUSH;
 }
 
 /*
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h b/xen/include/asm-x86/hvm/svm/vmcb.h
index e5ed38369e..c2e1972feb 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -302,6 +302,17 @@ enum VMEXIT_EXITCODE
     VMEXIT_INVALID          =  -1
 };
 
+enum
+{
+    /* Available on all SVM-capable hardware. */
+    TLB_CTRL_NO_FLUSH             = 0,
+    TLB_CTRL_FLUSH_ALL            = 1,
+
+    /* Available with the FlushByASID feature. */
+    TLB_CTRL_FLUSH_ASID           = 3,
+    TLB_CTRL_FLUSH_ASID_NONGLOBAL = 7,
+};
+
 typedef union
 {
     struct
@@ -419,7 +430,7 @@ struct vmcb_struct {
     u64 _msrpm_base_pa;         /* offset 0x48 - cleanbit 1 */
     u64 _tsc_offset;            /* offset 0x50 - cleanbit 0 */
     u32 _guest_asid;            /* offset 0x58 - cleanbit 2 */
-    u8  tlb_control;            /* offset 0x5C */
+    u8  tlb_control;            /* offset 0x5C - TLB_CTRL_* */
     u8  res07[3];
     vintr_t _vintr;             /* offset 0x60 - cleanbit 3 */
     intstat_t int_stat;         /* offset 0x68 */
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 12:24:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 12:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOKbr-0003CK-5z; Tue, 14 Apr 2020 12:24:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=7K6O=56=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jOKbp-0003CF-Tn
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 12:24:09 +0000
X-Inumbo-ID: d6f1ed3a-7e4a-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d6f1ed3a-7e4a-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 12:24:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586867049;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=XTSdJFI+eaJ62TaZsEa9sU+zvHGmB2SFfWnbKvCYlR8=;
 b=M8F4YW5tUIq+/NVGwSnERGaYoA+LrN2obPcPJoFuaD9xt9mTywVQ7fO3
 x+5LHbvUlrq31do7quzt1Im27YdW1wTI5wc7n6D7U7+0K2LE4kVdtOB4l
 acBbRnTSRbncPTClBCCU816mo29y0j8TjYUACjdDlQa5fLBDqY67V68m3 w=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 2hh4Yd+2awe60eudvgslxs37/C+E9diAjiCZFZXGXIelNTHczOcvc+qKLggc0q7NXwNyEcwp3/
 LLx6H9q0AQ7Bw5mv9XijkzWurUT0oGfxkVk9emmoQvmucgHYYHuD++meWe7XzDy2BFyrrY7BXw
 UYcWflUtlgSq+MR5WFLxFSYcCSZowLkGqQlXi8R/bw+R0OoIVi1f91yb4H5qinda9yvqiJtl3R
 wQqmYyl1UIUdD2kktZU8+jrTVJ4VhNpoM4AWRrxQ5zEZPS/L0TLkIQYLWPk5M+hQNRXec/7mT4
 qxw=
X-SBRS: 2.7
X-MesageID: 15652204
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="15652204"
Date: Tue, 14 Apr 2020 13:24:03 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 04/18] xen/build: include include/config/auto.conf
 in main Makefile
Message-ID: <20200414122403.GA4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-5-anthony.perard@citrix.com>
 <caf9aa56-1bc4-b24a-2a88-1c825ca8805e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <caf9aa56-1bc4-b24a-2a88-1c825ca8805e@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 01:33:50PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
> > --- a/xen/scripts/Kbuild.include
> > +++ b/xen/scripts/Kbuild.include
> > @@ -32,3 +32,8 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || e
> >  # Usage:
> >  # $(MAKE) $(clean) dir
> >  clean := -f $(BASEDIR)/scripts/Makefile.clean clean -C
> > +
> > +# Shorthand for kconfig
> > +# Usage:
> > +# $(MAKE) $(kconfig) target
> > +kconfig = -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
> 
> Is this going to be needed outside of xen/Makefile? If not, I'd
> like to ask that it be local to xen/Makefile. With the adjustment
> or with a reply clarifying to future plans
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

I'll move that to xen/Makefile.
Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 12:37:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 12:37:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOKog-0004JK-Pk; Tue, 14 Apr 2020 12:37:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9vXG=56=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jOKof-0004JF-FH
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 12:37:25 +0000
X-Inumbo-ID: b0d43e26-7e4c-11ea-892c-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b0d43e26-7e4c-11ea-892c-12813bfff9fa;
 Tue, 14 Apr 2020 12:37:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586867844;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=L+KTtZyepbJ/UWd8lcxQnDdmM63Oveq6fypoOTICUdw=;
 b=cf2H1cLY8ILwYMlZ6xSacCepUnsWkzRGjZ7rOXAZxMEbampYAh1aX4MD
 Ry3+gTWlX49/z8rds01yCuoNdwKS5GjJoeW9M9JaBMkhlI8V9HvoiaP3K
 k12Y+DHNBWbXmFYgJpWfUZ8dZNwFLYFVvA/lvoXz8rwy1EYlEOi1BBHnL 4=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 1OJHJ+h8J7+qnZsuQrKP6LLMrh8ir/Y8pd42gFxC5OMVkic4oV37hywsU7+Gb+AnlO8PbTxIUc
 DJ3La4g62ocjLknJJVKJU4XG9WAat8JDQ3XBTqwRulPza5ce21NVsbSjIouTpajnE3qQq+ZaLA
 c8bZW7nHe9XIA87lPbG4moroDl8SB7BTERwLDLuZgbnWNZ0m/4k+PejkxviTkCqhHFZUn8ggfq
 u/3/7mpOAVj9TqB3Jy3BM4LUf+OggpkNw8mnHy5sy3gI9DzTyFtP5W3Vfaf43EqQJ4AJRWtJvF
 qE0=
X-SBRS: 2.7
X-MesageID: 16040844
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="16040844"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] sched: fix scheduler_disable() with core scheduling
Thread-Topic: [PATCH] sched: fix scheduler_disable() with core scheduling
Thread-Index: AQHWDlMf+hls+gjzYE+KOswEHefQ3KhwnMkAgAfn8QA=
Date: Tue, 14 Apr 2020 12:37:21 +0000
Message-ID: <1586867831219.70127@citrix.com>
References: <20200409094137.13836-1-sergey.dyasli@citrix.com>
 <8db96ff6-53e3-8c01-0737-5181ccc348ab@suse.com>
In-Reply-To: <8db96ff6-53e3-8c01-0737-5181ccc348ab@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-imapappendstamp: AMSPEX02CL03.citrite.net (15.00.1497.006)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1D5FDD915FEC364B8E7788227A5C7436@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Igor Druzhinin <igor.druzhinin@citrix.com>,
 Sergey Dyasli <sergey.dyasli@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

(CC Igor)=0A=
=0A=
On 09/04/2020 13:50, J=FCrgen Gro=DF wrote:=0A=
> On 09.04.20 11:41, Sergey Dyasli wrote:=0A=
>> In core-scheduling mode, Xen might crash when entering ACPI S5 state.=0A=
>> This happens in sched_slave() during is_idle_unit(next) check because=0A=
>> next->vcpu_list is stale and points to an already freed memory.=0A=
>>=0A=
>> This situation happens shortly after scheduler_disable() is called if=0A=
>> some CPU is still inside sched_slave() softirq. Current logic simply=0A=
>> returns prev->next_task from sched_wait_rendezvous_in() which causes=0A=
>> the described crash because next_task->vcpu_list has become invalid.=0A=
>>=0A=
>> Fix the crash by returning NULL from sched_wait_rendezvous_in() in=0A=
>> the case when scheduler_disable() has been called.=0A=
>>=0A=
>> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>=0A=
> =0A=
> Good catch!=0A=
> =0A=
> Have you seen any further problems (e.g. with cpu on/offlining) with=0A=
> this patch applied?=0A=
=0A=
This patch shouldn't affect cpu on/offlining AFAICS. Igor was the one testi=
ng=0A=
cpu on/offlining and I think he came to a conclusion that it's broken even=
=0A=
without core-scheduling enabled.=0A=
=0A=
> Reviewed-by: Juergen Gross <jgross@suse.com>=0A=
=0A=
Thanks!=0A=
=0A=
--=0A=
Sergey=0A=


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 12:50:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 12:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOL1M-000659-K0; Tue, 14 Apr 2020 12:50:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qlbo=56=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOL1M-000651-0n
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 12:50:32 +0000
X-Inumbo-ID: 85bf1fd8-7e4e-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 85bf1fd8-7e4e-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 12:50:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=9U/DBmXCdb4JQePDuFgwVV2GrXR6TkMS8kzcWZ9Vpf4=; b=6lGIE/hFFF+16EZSAEI9gDe4r
 p7XLFIiZpSH2qFs/oQMkwjWfyAC1B5gyKHl6BEGixWxf8fW7rcMiJ/XTIW3/Gp9uG/OZwfyCfgNua
 xPpT1WD3jSwnEPZNiQaDUhvgtPrN8I/1LQLS8tQiScxD0xJryCJ3k3KzP12w2nVxyeRjc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOL1K-0001X5-9i; Tue, 14 Apr 2020 12:50:30 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOL1J-0005bo-VH; Tue, 14 Apr 2020 12:50:30 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOL1J-00009M-Uc; Tue, 14 Apr 2020 12:50:29 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149644-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149644: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=0dbc112e727f6c17f306c864950bdf83dece5cd5
X-Osstest-Versions-That: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 14 Apr 2020 12:50:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  0dbc112e727f6c17f306c864950bdf83dece5cd5
baseline version:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3

Last test of basis   149602  2020-04-10 15:01:12 Z    3 days
Testing same since   149644  2020-04-14 10:01:29 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexandru Isaila <aisaila@bitdefender.com>
  Jan Beulich <jbeulich@suse.com>
  Wei Liu <wl@xen.org>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   7372466b21..0dbc112e72  0dbc112e727f6c17f306c864950bdf83dece5cd5 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 13:07:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 13:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOLHj-0007Dn-IP; Tue, 14 Apr 2020 13:07:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOLHh-0007Di-LN
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 13:07:25 +0000
X-Inumbo-ID: e0c2d7b3-7e50-11ea-892e-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e0c2d7b3-7e50-11ea-892e-12813bfff9fa;
 Tue, 14 Apr 2020 13:07:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586869645;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=hoNkXjS6jleFTB4sL/rGguV5OQjChQ/VkNSP8PJgq/Q=;
 b=heIfEm/AnyI5tPKRsSQ3cbNgXkGYnZ+Ys+vB2ONuB1v1MQj/ttytjHA7
 5bqp1clwZfKUDNN2rjdO3kUD3Uh8mOc6QY5jIFp2KarRtkia+lXi9m1EH
 5ONKE7gQzJb7iDjy6tJznkGnleHBK90YQPIkrH/MM2R3Bl5Nrfugy0yOF s=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: b+VXqnigfZ13+AFzOc+xTHiZwBFgqHUYUPgBGQX2nKR9zIKbhG3y2L0ISFxKn30loNcGXs1+7j
 1Nr5e3ZZ2fOk9myNlNK/oPirYBDRT3oU5HH9QNHX/z2GxVzPg0e7eEcIryu3gNEXkCOVWVISO3
 iPVp19bqZipPxYqmhLuDDFVZ9loY4t47EIudqvh3BwRI9UIj2dDh7eKrQm8PMd4NhnlRHrRf+4
 J+Q27y5kOrkeTB8VzImjptWN6m3TwSI7XSOvWVRzJgMBzLNyx0dufjtU3hvLKZsMO9WGvvC3Wj
 qHQ=
X-SBRS: 2.7
X-MesageID: 15656226
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="15656226"
Subject: Re: preparations for 4.13.1 and 4.12.3
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <dbce2a2e-4cfd-9838-564d-710e5f10ab53@citrix.com>
Date: Tue, 14 Apr 2020 14:07:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Anthony Perard <anthony.perard@citrix.com>, Ian
 Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09/04/2020 08:41, Jan Beulich wrote:
> All,
>
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)

540d4d60378c "cpu: sync any remaining RCU callbacks before CPU up/down"
which fixes crashes after vcpu hotplug in shim.

It looks to depend on 53ddfc80a84a, a9b6dacf88fe, c301211a5111 and
53594c7bd197 which are other RCU bugfixes.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 13:37:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 13:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOLkN-0001gF-J2; Tue, 14 Apr 2020 13:37:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOLkM-0001g8-A4
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 13:37:02 +0000
X-Inumbo-ID: 04ea35d0-7e55-11ea-8935-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 04ea35d0-7e55-11ea-8935-12813bfff9fa;
 Tue, 14 Apr 2020 13:37:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2A2E3ADC1;
 Tue, 14 Apr 2020 13:36:59 +0000 (UTC)
Subject: Re: preparations for 4.13.1 and 4.12.3
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
 <dbce2a2e-4cfd-9838-564d-710e5f10ab53@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6b800158-9f05-1b91-e1ae-f368746852bb@suse.com>
Date: Tue, 14 Apr 2020 15:36:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <dbce2a2e-4cfd-9838-564d-710e5f10ab53@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 Anthony Perard <anthony.perard@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 15:07, Andrew Cooper wrote:
> On 09/04/2020 08:41, Jan Beulich wrote:
>> All,
>>
>> the releases are due in a week or two. Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant. (Ian, I notice there haven't been any
>> tools side backports at all so far. Julien, Stefano - same for
>> Arm.)
> 
> 540d4d60378c "cpu: sync any remaining RCU callbacks before CPU up/down"
> which fixes crashes after vcpu hotplug in shim.
> 
> It looks to depend on 53ddfc80a84a, a9b6dacf88fe, c301211a5111 and
> 53594c7bd197 which are other RCU bugfixes.

And cef21210fb133 as well as a6fe79a5979a then. Iirc we had even
talked about this on irc, and were largely in agreement that this
is a little beyond what we'd normally backport.

I have to admit that while I followed Igor's advice that there is
a dependency of his patch on Jürgen's work, I'm still not really
clear where that dependency actually lies. The patch merely moves
where rcu_barrier() gets invoked from (thus covering previously
uncovered places). If there hadn't been that named dependency, I
would have taken Igor's patch already.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 13:42:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 13:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOLpj-0002WZ-9i; Tue, 14 Apr 2020 13:42:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOLpi-0002WU-H5
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 13:42:34 +0000
X-Inumbo-ID: cb051b22-7e55-11ea-8936-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cb051b22-7e55-11ea-8936-12813bfff9fa;
 Tue, 14 Apr 2020 13:42:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C7A39AE0D;
 Tue, 14 Apr 2020 13:42:31 +0000 (UTC)
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: paul@xen.org
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
 <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
 <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
 <a102ec836a00714678fb3aa46787f597c9044f29.camel@amazon.com>
 <cfe18a03-854d-8b91-b333-ae2cefe3e1c8@suse.com>
 <000001d6124c$0aced570$206c8050$@xen.org>
 <90fd6e75-32b6-a140-1d20-083947bf1681@suse.com>
 <000001d61254$020b0dc0$06212940$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7c9ba731-bde1-96d7-6d93-9d33160f749c@suse.com>
Date: Tue, 14 Apr 2020 15:42:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <000001d61254$020b0dc0$06212940$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: wl@xen.org, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
 "'Shamsundara Havanur, Harsha'" <havanur@amazon.com>,
 xen-devel@lists.xenproject.org, roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 13:58, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 14 April 2020 12:40
>> To: paul@xen.org
>> Cc: 'Shamsundara Havanur, Harsha' <havanur@amazon.com>; xen-devel@lists.xenproject.org;
>> andrew.cooper3@citrix.com; ian.jackson@eu.citrix.com; wl@xen.org; roger.pau@citrix.com
>> Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all resource allocation
>>
>> On 14.04.2020 13:01, Paul Durrant wrote:
>>>> -----Original Message-----
>>>>>
>>>>> Previous commit enabled MASTER for all functions. I am bit confused
>>>>> here on the consensus on enabling/disabling/retaining BME.
>>>>> Should we even care about MASTER?
>>>>
>>>> With the commit introducing its universal setting, I'm afraid to
>>>> avoid regressions we can't sensibly alter the behavior unless it
>>>> can be explained clearly why the original change must have been
>>>> outright wrong.
>>>>
>>>
>>> Well the original code IIRC had no justification for setting BME
>>> and doing it unconditionally does seem dangerous.
>>
>> I'm not viewing this as dangerous, merely as (typically) pointless.
>> A well behaved device won't start issuing DMA requests merely
>> because it had its bus mastering capability enabled. (And in the
>> context of some IOMMU work of yours you actually stated there are
>> devices where clearing of this bit won't stop them from doing so.)
>>
> 
> It's a line of defence against some devices at least,

What defence? Once we're past hvmloader, the guest can do whatever it
wants anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 13:50:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 13:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOLxC-0003Ni-6y; Tue, 14 Apr 2020 13:50:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOLxA-0003Nd-Iv
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 13:50:16 +0000
X-Inumbo-ID: de993c30-7e56-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id de993c30-7e56-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 13:50:16 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 39D7DAC1D;
 Tue, 14 Apr 2020 13:50:14 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
 <20200414111911.GI28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
Date: Tue, 14 Apr 2020 15:50:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200414111911.GI28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 13:19, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
>> On 14.04.2020 12:02, Roger Pau Monné wrote:
>>> That seems nice, we would have to be careful however as reducing the
>>> number of ASID/VPID flushes could uncover issues in the existing code.
>>> I guess you mean something like:
>>>
>>> static inline void guest_flush_tlb_mask(const struct domain *d,
>>>                                         const cpumask_t *mask)
>>> {
>>>     flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
>>>                                                                 : 0) |
>>>     		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
>>> 		                                      : 0));
>>> }
>>
>> Almost - is_hvm_domain(d) && cpu_has_svm seems to wide for me. I'd
>> rather use hap_enabled() && cpu_has_svm, which effectively means NPT.
>> Or am I overlooking a need to do ASID flushes also in shadow mode?
> 
> I think so, I've used is_hvm_domain in order to cover for HVM domains
> running in shadow mode on AMD hardware, I think those also need the
> ASID flushes.

I'm unconvinced: The entire section "TLB Management" in the PM gives
the impression that "ordinary" TLB flushing covers all ASIDs anyway.
It's not stated anywhere (I could find) explicitly though.

>> Also I'd suggest to calculate the flags up front, to avoid calling
>> flush_mask() in the first place in case (EPT) neither bit is set.
>>
>>> I think this should work, but I would rather do it in a separate
>>> patch.
>>
>> Yes, just like the originally (wrongly, as you validly say) suggested
>> full removal of them, putting this in a separate patch would indeed
>> seem better.
> 
> Would you like me to resend with the requested fix to
> paging_log_dirty_range (ie: drop the FLUSH_TLB and only call
> flush_mask for HAP guests running on AMD) then?

Well, ideally I'd see that function also make use of the intended
new helper function, if at all possible (and suitable).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 13:52:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 13:52:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOLyp-0003Uz-LZ; Tue, 14 Apr 2020 13:51:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=akv/=56=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jOLyo-0003Uu-O7
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 13:51:58 +0000
X-Inumbo-ID: 1b6d6a82-7e57-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1b6d6a82-7e57-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 13:51:58 +0000 (UTC)
Received: by mail-ed1-x542.google.com with SMTP id c7so17238338edl.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Apr 2020 06:51:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=Dt4k/XK02DKznW3AtMB5fBluLBEtE4XZYUVoLyAo5OI=;
 b=Bb8OWHD1S8wERsZ8egEDK6JyXn3BFxSUvv6owRD4zsyO/WeK0OYo+d02xUHTgQzwU+
 nITDN06ziZ/Et3TOdvhjB79PXJOAVQJns8XL3tKdrk0tyxFXKKjLhSpOV/HCCW+0rvps
 BlihrX8cWdpwEAwLSwp+NbQoJzrKaldX3+IupUD8kY0hUnPI4aH42VMKJ4HQzSU7COSC
 ApWF4QWOd6XrNGqgnk3mzt4zC3+bCnhu0gMT9gY9qQMxZ/a3UDtiXVLc3W/f/nDNpKT2
 f0qkci+AQRXQdhjEnXxu7VZCtSi/OwJW9d9YCfQhj5e7isCf8lbdEMW3NWJfmH5GDud1
 AxWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=Dt4k/XK02DKznW3AtMB5fBluLBEtE4XZYUVoLyAo5OI=;
 b=s0auJi5CiVOn0UgLWzHI5MqIS1/xvTM8CNSChJPwnU0i8oMDt0x0yIs6K4ad8llkZQ
 0YVslrYkS93hIEKxL3xl+AI5e+UF5B/1hTIysUWtnMjYrRSFhKNstnKvRu2BcGGTc1hN
 sfja+p8ZA0g0ioD8s1lEWQPgArOFA24597ObwIatTFB7OAByB8njYwsySkeMa5ZGmFQj
 jJPEBo8iY8RqZS4VsjZdt/cUv16JenFHA9OIVZZuBnT4gcT8TGVHeaWCulTHIVJ107B7
 PNnK42mMsdh8N8OaupYX7A6Uotfj4KirkjvQM8UKXar38Oq/0YjLapLuKA+DMp4kAv5Q
 ANAg==
X-Gm-Message-State: AGi0PuZ2gwhJc+MD8wGA6akzfwtzT9AwWd+6wNt1euQXtb9rrlkGnl6r
 1n2pd3DwdsY8ON7qC1mk+Ag=
X-Google-Smtp-Source: APiQypJuTNJl1rR8LpqjRGggIxFj3l2PNaTP7edKekQqUOxXv9qwpnmQrgEws7+mjZaFmHP1oH5Djw==
X-Received: by 2002:a50:bb25:: with SMTP id y34mr10159597ede.237.1586872317204; 
 Tue, 14 Apr 2020 06:51:57 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.188])
 by smtp.gmail.com with ESMTPSA id sb17sm1580667ejb.75.2020.04.14.06.51.55
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 14 Apr 2020 06:51:56 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
 <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
 <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
 <a102ec836a00714678fb3aa46787f597c9044f29.camel@amazon.com>
 <cfe18a03-854d-8b91-b333-ae2cefe3e1c8@suse.com>
 <000001d6124c$0aced570$206c8050$@xen.org>
 <90fd6e75-32b6-a140-1d20-083947bf1681@suse.com>
 <000001d61254$020b0dc0$06212940$@xen.org>
 <7c9ba731-bde1-96d7-6d93-9d33160f749c@suse.com>
In-Reply-To: <7c9ba731-bde1-96d7-6d93-9d33160f749c@suse.com>
Subject: RE: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Tue, 14 Apr 2020 14:51:55 +0100
Message-ID: <001901d61263$dc9d58d0$95d80a70$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQFuCy2uGI4jNh4hl1w2kkxxIVrUTADKkfs7Amx1u9ABXrUQQAMwPUabAgJH1CUBoTRAhwIYHsW9AsXKQUsB0SSrKai37Mbw
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: wl@xen.org, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
 "'Shamsundara Havanur, Harsha'" <havanur@amazon.com>,
 xen-devel@lists.xenproject.org, roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 14 April 2020 14:43
> To: paul@xen.org
> Cc: 'Shamsundara Havanur, Harsha' <havanur@amazon.com>; =
xen-devel@lists.xenproject.org;
> andrew.cooper3@citrix.com; ian.jackson@eu.citrix.com; wl@xen.org; =
roger.pau@citrix.com
> Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, =
after all resource allocation
>=20
> On 14.04.2020 13:58, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: 14 April 2020 12:40
> >> To: paul@xen.org
> >> Cc: 'Shamsundara Havanur, Harsha' <havanur@amazon.com>; =
xen-devel@lists.xenproject.org;
> >> andrew.cooper3@citrix.com; ian.jackson@eu.citrix.com; wl@xen.org; =
roger.pau@citrix.com
> >> Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, =
after all resource allocation
> >>
> >> On 14.04.2020 13:01, Paul Durrant wrote:
> >>>> -----Original Message-----
> >>>>>
> >>>>> Previous commit enabled MASTER for all functions. I am bit =
confused
> >>>>> here on the consensus on enabling/disabling/retaining BME.
> >>>>> Should we even care about MASTER?
> >>>>
> >>>> With the commit introducing its universal setting, I'm afraid to
> >>>> avoid regressions we can't sensibly alter the behavior unless it
> >>>> can be explained clearly why the original change must have been
> >>>> outright wrong.
> >>>>
> >>>
> >>> Well the original code IIRC had no justification for setting BME
> >>> and doing it unconditionally does seem dangerous.
> >>
> >> I'm not viewing this as dangerous, merely as (typically) pointless.
> >> A well behaved device won't start issuing DMA requests merely
> >> because it had its bus mastering capability enabled. (And in the
> >> context of some IOMMU work of yours you actually stated there are
> >> devices where clearing of this bit won't stop them from doing so.)
> >>
> >
> > It's a line of defence against some devices at least,
>=20
> What defence? Once we're past hvmloader, the guest can do whatever it
> wants anyway.
>=20

My observation is that it is typically the device function driver that =
will enable BME, and that may come after a device-specific reset has =
been done. So, the chances of the VM surviving in the face of buggy h/w =
is higher if we don't blindly enable BME early on.

  Paul




From xen-devel-bounces@lists.xenproject.org Tue Apr 14 13:58:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 13:58:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOM4Y-0003h0-JG; Tue, 14 Apr 2020 13:57:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOM4X-0003gv-8h
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 13:57:53 +0000
X-Inumbo-ID: ee654d10-7e57-11ea-8938-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ee654d10-7e57-11ea-8938-12813bfff9fa;
 Tue, 14 Apr 2020 13:57:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 54112ABC2;
 Tue, 14 Apr 2020 13:57:50 +0000 (UTC)
Subject: Re: [PATCH] x86/svm: Don't use vmcb->tlb_control as if it is a boolean
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200414121429.10196-1-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <9c4e293d-1425-846f-1c52-91906f4e0d72@suse.com>
Date: Tue, 14 Apr 2020 15:57:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200414121429.10196-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 14:14, Andrew Cooper wrote:
> @@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
>      struct hvm_vcpu_asid *p_asid =
>          nestedhvm_vcpu_in_guestmode(curr)
>          ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
> -    bool_t need_flush = hvm_asid_handle_vmenter(p_asid);
> +    bool need_flush = hvm_asid_handle_vmenter(p_asid);
>  
>      /* ASID 0 indicates that ASIDs are disabled. */
>      if ( p_asid->asid == 0 )
>      {
>          vmcb_set_guest_asid(vmcb, 1);
> -        vmcb->tlb_control = 1;
> +        vmcb->tlb_control = TLB_CTRL_FLUSH_ALL;

While there ought to be no difference in behavior, use of
TLB_CTRL_FLUSH_ASID would seem more logical to me here. Other
than below we're no after flushing all ASIDs in this case
afaict.

Question of course is - did early CPUs treat this as boolean,
accepting any non-zero value to mean "flush all"?

Preferably with such an adjustment
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 14:12:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 14:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOMIE-0005Qn-Vx; Tue, 14 Apr 2020 14:12:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOMID-0005Qi-Dk
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 14:12:01 +0000
X-Inumbo-ID: e78b69c9-7e59-11ea-8941-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e78b69c9-7e59-11ea-8941-12813bfff9fa;
 Tue, 14 Apr 2020 14:12:00 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9D049AC75;
 Tue, 14 Apr 2020 14:11:58 +0000 (UTC)
Subject: Re: [XEN PATCH v3] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: Harsha Shamsundara Havanur <havanur@amazon.com>
References: <758e3427f147ed82774edcbbe80b0b29c812e6e4.1586862721.git.havanur@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3926fb02-2058-6e3a-6dcd-3ac5c4b97de5@suse.com>
Date: Tue, 14 Apr 2020 16:12:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <758e3427f147ed82774edcbbe80b0b29c812e6e4.1586862721.git.havanur@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 13:12, Harsha Shamsundara Havanur wrote:
> It was observed that PCI MMIO and/or IO BARs were programmed with
> memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
> during PCI setup phase. This resulted in incorrect memory mapping as
> soon as the lower half of the 64 bit bar is programmed.
> This displaced any RAM mappings under 4G. After the
> upper half is programmed PCI memory mapping is restored to its
> intended high mem location, but the RAM displaced is not restored.
> The OS then continues to boot and function until it tries to access
> the displaced RAM at which point it suffers a page fault and crashes.
> 
> This patch address the issue by deferring enablement of memory and
> I/O decode in command register until all the resources, like interrupts
> I/O and/or MMIO BARs for all the PCI device functions are programmed,
> in the descending order of memory requested.
> 
> Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
> Reviewed-by: Paul Durrant <pdurrant@amazon.com>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

You've fixed bugs, implying you need to drop tags covering the code
which was fixed. As said on v2, imo you should have dropped the tags
then already.

> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -84,6 +84,7 @@ void pci_setup(void)
>      uint32_t vga_devfn = 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    uint8_t pci_devfn_decode_type[256] = {};

I'm still waiting for a reply on my v1 comment on the stack
consumption of this, suggesting two 256-bit bitmaps instead.

> @@ -120,6 +121,9 @@ void pci_setup(void)
>       */
>      bool allow_memory_relocate = 1;
>  
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY != PCI_COMMAND_MEMORY);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != PCI_COMMAND_IO);

These lines are too long.

> @@ -288,10 +292,21 @@ void pci_setup(void)
>              printf("pci dev %02x:%x INT%c->IRQ%u\n",
>                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
>          }
> -
>          /* Enable bus mastering. */

Please don't drop a blank line like this.

>          cmd = pci_readw(devfn, PCI_COMMAND);
>          cmd |= PCI_COMMAND_MASTER;
> +
> +        /*
> +         * Disable memory and I/O decode,
> +         * It is recommended that BAR programming be done whilst
> +         * decode bits are cleared to avoid incorrect mappings being created,
> +         * when 64-bit memory BAR is programmed first by writing the lower half
> +         * and then the upper half, which first maps to an address under 4G
> +         * replacing any RAM mapped in that address, which is not restored
> +         * back after the upper half is written and PCI memory is correctly
> +         * mapped to its intended high mem address.
> +         */
> +        cmd &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
>          pci_writew(devfn, PCI_COMMAND, cmd);
>      }

I'd like to note that the disabling of IO and MEMORY you do here comes too
late: It should happen before any of the BARs gets written with ~0. In
particular for 64-bit BARs these writes can again cause undue effects on
the intermediately resulting effective addresses.

> @@ -526,10 +537,16 @@ void pci_setup(void)
>           * has IO enabled, even if there is no I/O BAR on that
>           * particular device.
>           */
> -        cmd = pci_readw(vga_devfn, PCI_COMMAND);
> -        cmd |= PCI_COMMAND_IO;
> -        pci_writew(vga_devfn, PCI_COMMAND, cmd);
> +        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
>      }
> +
> +    /* Enable memory and I/O decode. */
> +    for ( devfn = 0; devfn < 256; devfn++ )
> +        if ( pci_devfn_decode_type[devfn] ) {

Style: The brace belongs on its own line.

To save one set of writes to the command registers I would, btw,
be okay with you moving the MASTER enabling here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 14:13:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 14:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOMJx-0005Wh-Fc; Tue, 14 Apr 2020 14:13:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOMJw-0005Wc-RY
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 14:13:48 +0000
X-Inumbo-ID: 281d2530-7e5a-11ea-8942-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 281d2530-7e5a-11ea-8942-12813bfff9fa;
 Tue, 14 Apr 2020 14:13:47 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 095CAAC46;
 Tue, 14 Apr 2020 14:13:45 +0000 (UTC)
Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: paul@xen.org
References: <bca361efe8061c470a4a27470dd247ee8d53af59.1586813622.git.havanur@amazon.com>
 <c7882dcb-9708-414c-98fb-0a0283db0f34@suse.com>
 <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com>
 <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com>
 <a102ec836a00714678fb3aa46787f597c9044f29.camel@amazon.com>
 <cfe18a03-854d-8b91-b333-ae2cefe3e1c8@suse.com>
 <000001d6124c$0aced570$206c8050$@xen.org>
 <90fd6e75-32b6-a140-1d20-083947bf1681@suse.com>
 <000001d61254$020b0dc0$06212940$@xen.org>
 <7c9ba731-bde1-96d7-6d93-9d33160f749c@suse.com>
 <001901d61263$dc9d58d0$95d80a70$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8f7d5857-7e40-4fa4-7a62-970f0af548d4@suse.com>
Date: Tue, 14 Apr 2020 16:13:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <001901d61263$dc9d58d0$95d80a70$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: wl@xen.org, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
 "'Shamsundara Havanur, Harsha'" <havanur@amazon.com>,
 xen-devel@lists.xenproject.org, roger.pau@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 15:51, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 14 April 2020 14:43
>> To: paul@xen.org
>> Cc: 'Shamsundara Havanur, Harsha' <havanur@amazon.com>; xen-devel@lists.xenproject.org;
>> andrew.cooper3@citrix.com; ian.jackson@eu.citrix.com; wl@xen.org; roger.pau@citrix.com
>> Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all resource allocation
>>
>> On 14.04.2020 13:58, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: 14 April 2020 12:40
>>>> To: paul@xen.org
>>>> Cc: 'Shamsundara Havanur, Harsha' <havanur@amazon.com>; xen-devel@lists.xenproject.org;
>>>> andrew.cooper3@citrix.com; ian.jackson@eu.citrix.com; wl@xen.org; roger.pau@citrix.com
>>>> Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all resource allocation
>>>>
>>>> On 14.04.2020 13:01, Paul Durrant wrote:
>>>>>> -----Original Message-----
>>>>>>>
>>>>>>> Previous commit enabled MASTER for all functions. I am bit confused
>>>>>>> here on the consensus on enabling/disabling/retaining BME.
>>>>>>> Should we even care about MASTER?
>>>>>>
>>>>>> With the commit introducing its universal setting, I'm afraid to
>>>>>> avoid regressions we can't sensibly alter the behavior unless it
>>>>>> can be explained clearly why the original change must have been
>>>>>> outright wrong.
>>>>>>
>>>>>
>>>>> Well the original code IIRC had no justification for setting BME
>>>>> and doing it unconditionally does seem dangerous.
>>>>
>>>> I'm not viewing this as dangerous, merely as (typically) pointless.
>>>> A well behaved device won't start issuing DMA requests merely
>>>> because it had its bus mastering capability enabled. (And in the
>>>> context of some IOMMU work of yours you actually stated there are
>>>> devices where clearing of this bit won't stop them from doing so.)
>>>>
>>>
>>> It's a line of defence against some devices at least,
>>
>> What defence? Once we're past hvmloader, the guest can do whatever it
>> wants anyway.
>>
> 
> My observation is that it is typically the device function driver
> that will enable BME, and that may come after a device-specific
> reset has been done. So, the chances of the VM surviving in the
> face of buggy h/w is higher if we don't blindly enable BME early
> on.

Well, I'd agree if only we knew the reason for the introduction of
this, many years ago.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 14:15:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 14:15:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOMLn-0005d7-0t; Tue, 14 Apr 2020 14:15:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOMLl-0005d1-Nn
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 14:15:41 +0000
X-Inumbo-ID: 6b593e92-7e5a-11ea-b58d-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6b593e92-7e5a-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 14:15:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586873741;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=toi2ILpAKOGqdr8dfDNwG7Ozbsl+wZRMnGDjIUos9ds=;
 b=e1rj0U8XUYAYSuu6eMrSRTlOquRP7IgzWLjl6taHIfGKO6yMuT+8+FYh
 2afazxRt6nQt5aH2TvZezn/T5bG3Sa1jJpXoY7xOyAgKF+NlAumWX8Xzn
 n65GOJHwGTOEvwCT67USzAHThaJecMQQ+4BqQsP/+CQK8MG7y5JPEQvI8 Q=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: mUZpEXlKUj31QTOmD2QAxAaDmZhgtYy3hUYcda62hDMV/pPiSexULhzIQF9S/bpJ83pOgrUizn
 92IAvCpR+gsMZwK2smeKlt1Xk6uMu5EiKNe1eaXWYPNA3rr7+/GOULHpL653DCWrPpIe16iihQ
 9r4jjEilD8F4WaFM35V1Iqan1l+RCb721cki2tKkRAd1IlTIRxfoVsskVAdang4Wf5UTODVcAN
 mrzmhZDTEpQaFpjBiPg6wM7acusTf8uVNJ6HlhUxqxr+uprgyafN/iAQjGYn7NpAOu9CWMh4i1
 Cmo=
X-SBRS: 2.7
X-MesageID: 15631685
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="15631685"
Subject: Re: [PATCH] x86/svm: Don't use vmcb->tlb_control as if it is a boolean
To: Jan Beulich <jbeulich@suse.com>
References: <20200414121429.10196-1-andrew.cooper3@citrix.com>
 <9c4e293d-1425-846f-1c52-91906f4e0d72@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <223c8116-4faf-2264-bc19-0e0de8b9ec9a@citrix.com>
Date: Tue, 14 Apr 2020 15:15:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9c4e293d-1425-846f-1c52-91906f4e0d72@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14/04/2020 14:57, Jan Beulich wrote:
> On 14.04.2020 14:14, Andrew Cooper wrote:
>> @@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
>>      struct hvm_vcpu_asid *p_asid =
>>          nestedhvm_vcpu_in_guestmode(curr)
>>          ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
>> -    bool_t need_flush = hvm_asid_handle_vmenter(p_asid);
>> +    bool need_flush = hvm_asid_handle_vmenter(p_asid);
>>  
>>      /* ASID 0 indicates that ASIDs are disabled. */
>>      if ( p_asid->asid == 0 )
>>      {
>>          vmcb_set_guest_asid(vmcb, 1);
>> -        vmcb->tlb_control = 1;
>> +        vmcb->tlb_control = TLB_CTRL_FLUSH_ALL;
> While there ought to be no difference in behavior, use of
> TLB_CTRL_FLUSH_ASID would seem more logical to me here. Other
> than below we're no after flushing all ASIDs in this case
> afaict.
>
> Question of course is - did early CPUs treat this as boolean,
> accepting any non-zero value to mean "flush all"?

The spec states "When the VMM sets the TLB_CONTROL field to 1, ...",
which is fairly clear on the matter.

> Preferably with such an adjustment

I'd prefer not to.  There is a good chance that your suggestion will
suffer a vmentry failure, or not flush anything on old hardware.

A change like that should be in its own patch, ideally with finding some
old enough hardware to verify.  I do not know if I have anything that
old to hand.  (Failing real hardware, some conformation from AMD about
how the CPU behaves).

> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thanks,

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 14:21:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 14:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOMQz-0006V0-Ri; Tue, 14 Apr 2020 14:21:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOMQy-0006Uv-Nj
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 14:21:04 +0000
X-Inumbo-ID: 2c2b85e4-7e5b-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2c2b85e4-7e5b-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 14:21:04 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6601EABEC;
 Tue, 14 Apr 2020 14:21:02 +0000 (UTC)
Subject: Re: [PATCH] x86/svm: Don't use vmcb->tlb_control as if it is a boolean
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200414121429.10196-1-andrew.cooper3@citrix.com>
 <9c4e293d-1425-846f-1c52-91906f4e0d72@suse.com>
 <223c8116-4faf-2264-bc19-0e0de8b9ec9a@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <39604bee-40f1-6a7a-f089-8cecd4e914b9@suse.com>
Date: Tue, 14 Apr 2020 16:21:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <223c8116-4faf-2264-bc19-0e0de8b9ec9a@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 16:15, Andrew Cooper wrote:
> On 14/04/2020 14:57, Jan Beulich wrote:
>> On 14.04.2020 14:14, Andrew Cooper wrote:
>>> @@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
>>>      struct hvm_vcpu_asid *p_asid =
>>>          nestedhvm_vcpu_in_guestmode(curr)
>>>          ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
>>> -    bool_t need_flush = hvm_asid_handle_vmenter(p_asid);
>>> +    bool need_flush = hvm_asid_handle_vmenter(p_asid);
>>>  
>>>      /* ASID 0 indicates that ASIDs are disabled. */
>>>      if ( p_asid->asid == 0 )
>>>      {
>>>          vmcb_set_guest_asid(vmcb, 1);
>>> -        vmcb->tlb_control = 1;
>>> +        vmcb->tlb_control = TLB_CTRL_FLUSH_ALL;
>> While there ought to be no difference in behavior, use of
>> TLB_CTRL_FLUSH_ASID would seem more logical to me here. Other
>> than below we're no after flushing all ASIDs in this case
>> afaict.
>>
>> Question of course is - did early CPUs treat this as boolean,
>> accepting any non-zero value to mean "flush all"?
> 
> The spec states "When the VMM sets the TLB_CONTROL field to 1, ...",
> which is fairly clear on the matter.

Well, it is a clear statement without it being clear how close to
truth it is. Consider the spec also saying "Should only be used by
legacy hypervisors" for the value of 1.

>> Preferably with such an adjustment
> 
> I'd prefer not to.  There is a good chance that your suggestion will
> suffer a vmentry failure, or not flush anything on old hardware.

Okay then. Could I talk you into adding at least a respective
comment there? Or one indicating that we should stop using the
value of 1 altogether (which of course is a bigger change)?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 14:32:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 14:32:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOMbh-0007Rb-48; Tue, 14 Apr 2020 14:32:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOMbg-0007RW-3r
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 14:32:08 +0000
X-Inumbo-ID: b772c51c-7e5c-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b772c51c-7e5c-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 14:32:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586874727;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=TOZ8VaQtOfD6/5e8XVw+V2N89bks/gsB76xNB9tyKuI=;
 b=SNQD/HvujYayLWYzTU0460tNqRHl5JRuq9A5xuUB7fwqDgYUIaOFHoT/
 t5rWKSUDEC4PmiqqBMyEVyr183u4Zteq/D5zBROnreWaAGfjudLbbdpyq
 nqNRrFUftiTw5la3xHXi0SYuvRhPYYROUYy+wuBS+li2cd45uVf/vTti9 w=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: cxhAff+LbOIqaPSdYZ7uAEz+yu7JkmY1BnwjCDxNTAkzodjytJg+ZGjlANsE2FD1A2m6TSGSGb
 oFfy9JJgEFQwOhp3JRJ7RNA7hA+E7XPMKrOIeBlbPENlzi6hDWT//oATy+9d0XZX9pLyt1tqou
 RX03Yl6XdvZDxcK5K26GYtF3SNPyDtIPGfC1axnYFpxC6/kGrr+hUSTr3jKr6i4+RZ7Hpt0LtR
 D2vrY/23cPjTOfbCOYC/XZLac6zjKaDe5RH0gVbwYo1hOpp3KkTSCvxzubTt8zpOR1DR9Q1/i/
 NGE=
X-SBRS: 2.7
X-MesageID: 16320624
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="16320624"
Subject: Re: [PATCH] x86/svm: Don't use vmcb->tlb_control as if it is a boolean
To: Jan Beulich <jbeulich@suse.com>
References: <20200414121429.10196-1-andrew.cooper3@citrix.com>
 <9c4e293d-1425-846f-1c52-91906f4e0d72@suse.com>
 <223c8116-4faf-2264-bc19-0e0de8b9ec9a@citrix.com>
 <39604bee-40f1-6a7a-f089-8cecd4e914b9@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <51ecd0bc-5387-9126-133f-00abbb3facac@citrix.com>
Date: Tue, 14 Apr 2020 15:32:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <39604bee-40f1-6a7a-f089-8cecd4e914b9@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14/04/2020 15:21, Jan Beulich wrote:
> On 14.04.2020 16:15, Andrew Cooper wrote:
>> On 14/04/2020 14:57, Jan Beulich wrote:
>>> On 14.04.2020 14:14, Andrew Cooper wrote:
>>>> @@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
>>>>      struct hvm_vcpu_asid *p_asid =
>>>>          nestedhvm_vcpu_in_guestmode(curr)
>>>>          ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
>>>> -    bool_t need_flush = hvm_asid_handle_vmenter(p_asid);
>>>> +    bool need_flush = hvm_asid_handle_vmenter(p_asid);
>>>>  
>>>>      /* ASID 0 indicates that ASIDs are disabled. */
>>>>      if ( p_asid->asid == 0 )
>>>>      {
>>>>          vmcb_set_guest_asid(vmcb, 1);
>>>> -        vmcb->tlb_control = 1;
>>>> +        vmcb->tlb_control = TLB_CTRL_FLUSH_ALL;
>>> While there ought to be no difference in behavior, use of
>>> TLB_CTRL_FLUSH_ASID would seem more logical to me here. Other
>>> than below we're no after flushing all ASIDs in this case
>>> afaict.
>>>
>>> Question of course is - did early CPUs treat this as boolean,
>>> accepting any non-zero value to mean "flush all"?
>> The spec states "When the VMM sets the TLB_CONTROL field to 1, ...",
>> which is fairly clear on the matter.
> Well, it is a clear statement without it being clear how close to
> truth it is. Consider the spec also saying "Should only be used by
> legacy hypervisors" for the value of 1.

That particular choice of wording is odd, because it should be "legacy
hardware" instead.  I'll add this to my "pestering AMD list".

There probably is a perf hit from it, as flushing every ASID includes
flushing ASID 0 which is Xen's TLB entries.  For back-to-back vmexits,
this probably is noticeable.

>>> Preferably with such an adjustment
>> I'd prefer not to.  There is a good chance that your suggestion will
>> suffer a vmentry failure, or not flush anything on old hardware.
> Okay then. Could I talk you into adding at least a respective
> comment there? Or one indicating that we should stop using the
> value of 1 altogether (which of course is a bigger change)?

Would you accept /* TODO: investigate using TLB_CTRL_FLUSH_ASID here
instead. */ ?

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 14:49:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 14:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOMsl-0008UI-W7; Tue, 14 Apr 2020 14:49:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=0GYB=56=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jOMsk-0008UD-65
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 14:49:46 +0000
X-Inumbo-ID: 2dba0bd4-7e5f-11ea-8951-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2dba0bd4-7e5f-11ea-8951-12813bfff9fa;
 Tue, 14 Apr 2020 14:49:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586875786;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=uxLmYsNH+Xi7YobeEaF28YYubY+/DLaE1APSADXT1hs=;
 b=UtztVBxwg5gAkgHmBW3OqeQj1PW4Bpqysc7QE+DvVgQ756BguYGubEo3
 ETwPEOO238ypagwWsrSK22sSJC3zwUUP3Oe1C2oWW2vQwHPBP5B1XSWfU
 pTtjie70NzZgfXYF6WTcKtwbJ4kP2SILU9301apMKIgjMdNzAYRANMWz7 0=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: sM9RTn/E34kqzdyG0GG/cEr/6R1rWZE11TrG4PqxCU625n6DGbzq1ZNQkPD/NgVSrR2YnuYL+g
 J2eKOvOJESPN8MPFqaW0j0pY/d61wmfxhCEmzmrqWxpLToQModjSHOQsCI+p/TwtdppjK73I7s
 rwWcTM8O/aeeZu//PKNFE3m4rvzsX0LPvY7B3dexYe3F0fVqa4+3GVwzNkVT2+Noq0Mdqdnav/
 UkQesvhAtMW6U6m1+ddNC/UVA1azag1MnWP3knPUhlk8ePwuUgzyNLgz7uSmjipL1wmWikEeqD
 WoA=
X-SBRS: 2.7
X-MesageID: 15664233
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="15664233"
Subject: Re: preparations for 4.13.1 and 4.12.3
To: Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
 <dbce2a2e-4cfd-9838-564d-710e5f10ab53@citrix.com>
 <6b800158-9f05-1b91-e1ae-f368746852bb@suse.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <5e2ee422-bdbf-2493-8761-2753acacc7d4@citrix.com>
Date: Tue, 14 Apr 2020 15:49:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <6b800158-9f05-1b91-e1ae-f368746852bb@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Anthony
 Perard <anthony.perard@citrix.com>, Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14/04/2020 14:36, Jan Beulich wrote:
> On 14.04.2020 15:07, Andrew Cooper wrote:
>> On 09/04/2020 08:41, Jan Beulich wrote:
>>> All,
>>>
>>> the releases are due in a week or two. Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant. (Ian, I notice there haven't been any
>>> tools side backports at all so far. Julien, Stefano - same for
>>> Arm.)
>>
>> 540d4d60378c "cpu: sync any remaining RCU callbacks before CPU up/down"
>> which fixes crashes after vcpu hotplug in shim.
>>
>> It looks to depend on 53ddfc80a84a, a9b6dacf88fe, c301211a5111 and
>> 53594c7bd197 which are other RCU bugfixes.
> 
> And cef21210fb133 as well as a6fe79a5979a then. Iirc we had even
> talked about this on irc, and were largely in agreement that this
> is a little beyond what we'd normally backport.

Correct. Those 2 could be taken for completeness but not strictly necessary.
On the other hand, those mentioned by Andrew (maybe except for a9b6dacf88fe)
are necessary prerequisites.

> I have to admit that while I followed Igor's advice that there is
> a dependency of his patch on Jürgen's work, I'm still not really
> clear where that dependency actually lies. The patch merely moves
> where rcu_barrier() gets invoked from (thus covering previously
> uncovered places). If there hadn't been that named dependency, I
> would have taken Igor's patch already.

There is dependency in the fact after my patch is applied - rcu_barrier gets
invoked very frequently unlike before. This uncovers many issues in its
implementation that are addressed by RCU series. Without RCU series
rcu_barrier call is unstable and causes race condition induced crashes and
is incompatible with core-scheduling.

Igor


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 14:53:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 14:53:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOMwg-0000sq-JI; Tue, 14 Apr 2020 14:53:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=18iO=56=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOMwf-0000sk-Q4
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 14:53:49 +0000
X-Inumbo-ID: bf561074-7e5f-11ea-b58d-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bf561074-7e5f-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 14:53:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586876028;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=sTub6VTB/XEgX6VrGLxOBloLRI+lMtnGI+fi6SJXIrI=;
 b=MvCav3XpgvASm33vvLyQNk/+0oFa0JPb2tRMgjggTtH90lk34S1OJpVF
 cxBRSS4IEzAkWPUSnJr5nuoF/HeWqn4WMJrsmB1M/eqwEy/89vi8jkWGd
 I367S18vPLwaaU3nRB3lw8dUtLkGQws8mnUEinQBttBAJAWXW6dv0tCk6 Y=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Zu4kdScKfphFiEH8DNIt0usNvQEQRCriKbL5NKKwrQfmv/X3XgugpdJnCNe8vH9v+tY6GiuxTW
 itkPoX+R5sX/w4RnkAGSqHxrY5nOwE9koGXexzZ6xwrcvoE4irPJYbFNsMj7toKSRCVuoqwWhX
 jG/XR6FC60jJRyuTkZcQ/MQ/DOMMcgD3ePDagHkh8cywzqat3aZuBrf+Fj0RcTrg8dFwJB8HG3
 fu+sY9q1CCJKeZ49jbhKDgZiy22208gL06my7Jif96AesnR0gXgsc9qRnyKCRrjrIjJqFPOCP1
 pb4=
X-SBRS: 2.7
X-MesageID: 15971574
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,382,1580792400"; d="scan'208";a="15971574"
Date: Tue, 14 Apr 2020 16:53:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200414145337.GJ28601@Air-de-Roger>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
 <20200414111911.GI28601@Air-de-Roger>
 <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
> On 14.04.2020 13:19, Roger Pau Monné wrote:
> > On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
> >> On 14.04.2020 12:02, Roger Pau Monné wrote:
> >>> That seems nice, we would have to be careful however as reducing the
> >>> number of ASID/VPID flushes could uncover issues in the existing code.
> >>> I guess you mean something like:
> >>>
> >>> static inline void guest_flush_tlb_mask(const struct domain *d,
> >>>                                         const cpumask_t *mask)
> >>> {
> >>>     flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
> >>>                                                                 : 0) |
> >>>     		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> >>> 		                                      : 0));
> >>> }
> >>
> >> Almost - is_hvm_domain(d) && cpu_has_svm seems to wide for me. I'd
> >> rather use hap_enabled() && cpu_has_svm, which effectively means NPT.
> >> Or am I overlooking a need to do ASID flushes also in shadow mode?
> > 
> > I think so, I've used is_hvm_domain in order to cover for HVM domains
> > running in shadow mode on AMD hardware, I think those also need the
> > ASID flushes.
> 
> I'm unconvinced: The entire section "TLB Management" in the PM gives
> the impression that "ordinary" TLB flushing covers all ASIDs anyway.
> It's not stated anywhere (I could find) explicitly though.

Hm, I don't think so. XenRT found a myriad of issues with NPT when p2m
code wasn't modified to do ASID flushes instead of plain TLB flushes.
Even if it's just to stay on the safe side I would perform ASID
flushes for HVM guests with shadow running on AMD.

> >> Also I'd suggest to calculate the flags up front, to avoid calling
> >> flush_mask() in the first place in case (EPT) neither bit is set.
> >>
> >>> I think this should work, but I would rather do it in a separate
> >>> patch.
> >>
> >> Yes, just like the originally (wrongly, as you validly say) suggested
> >> full removal of them, putting this in a separate patch would indeed
> >> seem better.
> > 
> > Would you like me to resend with the requested fix to
> > paging_log_dirty_range (ie: drop the FLUSH_TLB and only call
> > flush_mask for HAP guests running on AMD) then?
> 
> Well, ideally I'd see that function also make use of the intended
> new helper function, if at all possible (and suitable).

Oh, OK. Just to make sure I understand what you are asking for, you
would like me to resend introducing the new guest_flush_tlb_mask
helper and use it in the flush_tlb_mask callers modified by this
patch?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 14:53:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 14:53:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOMwm-0000te-UW; Tue, 14 Apr 2020 14:53:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qlbo=56=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOMwm-0000tU-3S
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 14:53:56 +0000
X-Inumbo-ID: c31fed1a-7e5f-11ea-8952-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c31fed1a-7e5f-11ea-8952-12813bfff9fa;
 Tue, 14 Apr 2020 14:53:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=KFRwJ0Nb4CbSIFtxs6ZuWWwFVUNFNuf47lBjMgZi7VE=; b=n7XjAOEpi0KsbtARyiMbcpikD
 vN5Fc7FUJE0uuGQhqG+YR28hdSNEi27Rsc0rwBoBL1y0DkvAJ2mtTgy/EYI4grPkhza0WQ/5tesc0
 OeIIQ4/yj4ffeYOAsmHoCWXabjMFsL2sZGkwanmOMnLrp/eLOIs1zpr4tyDrBwy0wB8tQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOMwk-00043Y-NA; Tue, 14 Apr 2020 14:53:54 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOMwk-0000aK-D2; Tue, 14 Apr 2020 14:53:54 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOMwk-0004w0-5b; Tue, 14 Apr 2020 14:53:54 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149645-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149645: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=d6f22d5d9e8d6848ec229083ac9fb044f0adea93
X-Osstest-Versions-That: xen=0dbc112e727f6c17f306c864950bdf83dece5cd5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 14 Apr 2020 14:53:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  d6f22d5d9e8d6848ec229083ac9fb044f0adea93
baseline version:
 xen                  0dbc112e727f6c17f306c864950bdf83dece5cd5

Last test of basis   149644  2020-04-14 10:01:29 Z    0 days
Testing same since   149645  2020-04-14 13:01:02 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   0dbc112e72..d6f22d5d9e  d6f22d5d9e8d6848ec229083ac9fb044f0adea93 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 14:54:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 14:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOMxf-00011B-BS; Tue, 14 Apr 2020 14:54:51 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOMxe-000112-1v
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 14:54:50 +0000
X-Inumbo-ID: e31b5852-7e5f-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e31b5852-7e5f-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 14:54:49 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 34989ABEC;
 Tue, 14 Apr 2020 14:54:47 +0000 (UTC)
Subject: Re: [PATCH] x86/svm: Don't use vmcb->tlb_control as if it is a boolean
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200414121429.10196-1-andrew.cooper3@citrix.com>
 <9c4e293d-1425-846f-1c52-91906f4e0d72@suse.com>
 <223c8116-4faf-2264-bc19-0e0de8b9ec9a@citrix.com>
 <39604bee-40f1-6a7a-f089-8cecd4e914b9@suse.com>
 <51ecd0bc-5387-9126-133f-00abbb3facac@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e7964b35-8724-af1e-8c6b-3a182d518daa@suse.com>
Date: Tue, 14 Apr 2020 16:54:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <51ecd0bc-5387-9126-133f-00abbb3facac@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 16:32, Andrew Cooper wrote:
> On 14/04/2020 15:21, Jan Beulich wrote:
>> On 14.04.2020 16:15, Andrew Cooper wrote:
>>> On 14/04/2020 14:57, Jan Beulich wrote:
>>>> On 14.04.2020 14:14, Andrew Cooper wrote:
>>>>> @@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
>>>>>      struct hvm_vcpu_asid *p_asid =
>>>>>          nestedhvm_vcpu_in_guestmode(curr)
>>>>>          ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
>>>>> -    bool_t need_flush = hvm_asid_handle_vmenter(p_asid);
>>>>> +    bool need_flush = hvm_asid_handle_vmenter(p_asid);
>>>>>  
>>>>>      /* ASID 0 indicates that ASIDs are disabled. */
>>>>>      if ( p_asid->asid == 0 )
>>>>>      {
>>>>>          vmcb_set_guest_asid(vmcb, 1);
>>>>> -        vmcb->tlb_control = 1;
>>>>> +        vmcb->tlb_control = TLB_CTRL_FLUSH_ALL;
>>>> While there ought to be no difference in behavior, use of
>>>> TLB_CTRL_FLUSH_ASID would seem more logical to me here. Other
>>>> than below we're no after flushing all ASIDs in this case
>>>> afaict.
>>>>
>>>> Question of course is - did early CPUs treat this as boolean,
>>>> accepting any non-zero value to mean "flush all"?
>>> The spec states "When the VMM sets the TLB_CONTROL field to 1, ...",
>>> which is fairly clear on the matter.
>> Well, it is a clear statement without it being clear how close to
>> truth it is. Consider the spec also saying "Should only be used by
>> legacy hypervisors" for the value of 1.
> 
> That particular choice of wording is odd, because it should be "legacy
> hardware" instead.  I'll add this to my "pestering AMD list".
> 
> There probably is a perf hit from it, as flushing every ASID includes
> flushing ASID 0 which is Xen's TLB entries.  For back-to-back vmexits,
> this probably is noticeable.
> 
>>>> Preferably with such an adjustment
>>> I'd prefer not to.  There is a good chance that your suggestion will
>>> suffer a vmentry failure, or not flush anything on old hardware.
>> Okay then. Could I talk you into adding at least a respective
>> comment there? Or one indicating that we should stop using the
>> value of 1 altogether (which of course is a bigger change)?
> 
> Would you accept /* TODO: investigate using TLB_CTRL_FLUSH_ASID here
> instead. */ ?

Yes, thanks.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 15:06:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 15:06:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jON8x-00022d-JF; Tue, 14 Apr 2020 15:06:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=t7Uy=56=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jON8w-00022Y-79
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 15:06:30 +0000
X-Inumbo-ID: 849003da-7e61-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 849003da-7e61-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 15:06:29 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6E679ACCE;
 Tue, 14 Apr 2020 15:06:27 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Tim Deegan <tim@xen.org>
References: <20200406105703.79201-1-roger.pau@citrix.com>
 <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
 <20200414111911.GI28601@Air-de-Roger>
 <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
 <20200414145337.GJ28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <fbc0dd00-6973-4003-ad34-591561b695c9@suse.com>
Date: Tue, 14 Apr 2020 17:06:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200414145337.GJ28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 16:53, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
>> On 14.04.2020 13:19, Roger Pau Monné wrote:
>>> On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
>>>> On 14.04.2020 12:02, Roger Pau Monné wrote:
>>>>> That seems nice, we would have to be careful however as reducing the
>>>>> number of ASID/VPID flushes could uncover issues in the existing code.
>>>>> I guess you mean something like:
>>>>>
>>>>> static inline void guest_flush_tlb_mask(const struct domain *d,
>>>>>                                         const cpumask_t *mask)
>>>>> {
>>>>>     flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
>>>>>                                                                 : 0) |
>>>>>     		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
>>>>> 		                                      : 0));
>>>>> }
>>>>
>>>> Almost - is_hvm_domain(d) && cpu_has_svm seems to wide for me. I'd
>>>> rather use hap_enabled() && cpu_has_svm, which effectively means NPT.
>>>> Or am I overlooking a need to do ASID flushes also in shadow mode?
>>>
>>> I think so, I've used is_hvm_domain in order to cover for HVM domains
>>> running in shadow mode on AMD hardware, I think those also need the
>>> ASID flushes.
>>
>> I'm unconvinced: The entire section "TLB Management" in the PM gives
>> the impression that "ordinary" TLB flushing covers all ASIDs anyway.
>> It's not stated anywhere (I could find) explicitly though.
> 
> Hm, I don't think so. XenRT found a myriad of issues with NPT when p2m
> code wasn't modified to do ASID flushes instead of plain TLB flushes.

Well, that's clear from e.g. p2m_pt_set_entry() not doing any
flushing itself.

> Even if it's just to stay on the safe side I would perform ASID
> flushes for HVM guests with shadow running on AMD.

Tim, any chance you could voice your thoughts here? To me it seems
odd to do an all-ASIDs flush followed by an ASID one.

>>>> Also I'd suggest to calculate the flags up front, to avoid calling
>>>> flush_mask() in the first place in case (EPT) neither bit is set.
>>>>
>>>>> I think this should work, but I would rather do it in a separate
>>>>> patch.
>>>>
>>>> Yes, just like the originally (wrongly, as you validly say) suggested
>>>> full removal of them, putting this in a separate patch would indeed
>>>> seem better.
>>>
>>> Would you like me to resend with the requested fix to
>>> paging_log_dirty_range (ie: drop the FLUSH_TLB and only call
>>> flush_mask for HAP guests running on AMD) then?
>>
>> Well, ideally I'd see that function also make use of the intended
>> new helper function, if at all possible (and suitable).
> 
> Oh, OK. Just to make sure I understand what you are asking for, you
> would like me to resend introducing the new guest_flush_tlb_mask
> helper and use it in the flush_tlb_mask callers modified by this
> patch?

Yes (and I now realize it may not make sense to split it off into a
separate change).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 15:11:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 15:11:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jONDy-0002uP-CF; Tue, 14 Apr 2020 15:11:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=kDu3=56=amazon.com=prvs=3660aa63e=havanur@srs-us1.protection.inumbo.net>)
 id 1jONDx-0002uH-Gh
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 15:11:41 +0000
X-Inumbo-ID: 3dd9a1b6-7e62-11ea-8955-12813bfff9fa
Received: from smtp-fw-33001.amazon.com (unknown [207.171.190.10])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3dd9a1b6-7e62-11ea-8955-12813bfff9fa;
 Tue, 14 Apr 2020 15:11:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586877100; x=1618413100;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:content-transfer-encoding:mime-version:subject;
 bh=O4KQn8GhwCIq7cc2LAUDQtlEwMHMN/dpe0tMSTYfI3Y=;
 b=Musk3doSShyQQedTNP0LhB9KeQjaLRqNA1hxDLoPS+pqA1331WizZO04
 4tzaYXvNB9u2rQPeIEtCJl0wJcM2WdO7wF52G64uU+Azrcc9nDnzPH3eL
 fAbyGUU7IYzf/czqPhgwmXMA4pARwgDGDTM6imohdNVtX1B4YgQ5N/4E7 s=;
IronPort-SDR: y214ylhVr/OHMyomMlCQWgieIl7UOvnZAe4jJJg9OvgsXeTbYkOrwOUPwamqT1kfagr0PAkhzS
 xirzLit44j7g==
X-IronPort-AV: E=Sophos;i="5.72,382,1580774400"; d="scan'208";a="38395537"
Subject: Re: [XEN PATCH v3] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Thread-Topic: [XEN PATCH v3] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-1e-a70de69e.us-east-1.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP;
 14 Apr 2020 15:11:37 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])
 by email-inbound-relay-1e-a70de69e.us-east-1.amazon.com (Postfix) with ESMTPS
 id D95A8A1EC7; Tue, 14 Apr 2020 15:11:35 +0000 (UTC)
Received: from EX13D36EUC004.ant.amazon.com (10.43.164.126) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 15:11:35 +0000
Received: from EX13D36EUC004.ant.amazon.com (10.43.164.126) by
 EX13D36EUC004.ant.amazon.com (10.43.164.126) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 15:11:34 +0000
Received: from EX13D36EUC004.ant.amazon.com ([10.43.164.126]) by
 EX13D36EUC004.ant.amazon.com ([10.43.164.126]) with mapi id 15.00.1497.006;
 Tue, 14 Apr 2020 15:11:34 +0000
From: "Shamsundara Havanur, Harsha" <havanur@amazon.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Thread-Index: AQHWEk2MZgsqhznwdkqhrf4NhmkbBKh4qLgAgAAQpIA=
Date: Tue, 14 Apr 2020 15:11:34 +0000
Message-ID: <34a2bded0f4f15b2885ed8c22bf9e20fb82d5932.camel@amazon.com>
References: <758e3427f147ed82774edcbbe80b0b29c812e6e4.1586862721.git.havanur@amazon.com>
 <3926fb02-2058-6e3a-6dcd-3ac5c4b97de5@suse.com>
In-Reply-To: <3926fb02-2058-6e3a-6dcd-3ac5c4b97de5@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.166.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <15FB1521A9E3E140A8230011B6907DA0@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 "wl@xen.org" <wl@xen.org>, "roger.pau@citrix.com" <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

T24gVHVlLCAyMDIwLTA0LTE0IGF0IDE2OjEyICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4g
Q0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p
emF0aW9uLiBEbw0KPiBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3Mg
eW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXINCj4gYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2Fm
ZS4NCj4gDQo+IA0KPiANCj4gT24gMTQuMDQuMjAyMCAxMzoxMiwgSGFyc2hhIFNoYW1zdW5kYXJh
IEhhdmFudXIgd3JvdGU6DQo+ID4gSXQgd2FzIG9ic2VydmVkIHRoYXQgUENJIE1NSU8gYW5kL29y
IElPIEJBUnMgd2VyZSBwcm9ncmFtbWVkIHdpdGgNCj4gPiBtZW1vcnkgYW5kIEkvTyBkZWNvZGVz
IChiaXRzIDAgYW5kIDEgb2YgUENJIENPTU1BTkQgcmVnaXN0ZXIpDQo+ID4gZW5hYmxlZCwNCj4g
PiBkdXJpbmcgUENJIHNldHVwIHBoYXNlLiBUaGlzIHJlc3VsdGVkIGluIGluY29ycmVjdCBtZW1v
cnkgbWFwcGluZw0KPiA+IGFzDQo+ID4gc29vbiBhcyB0aGUgbG93ZXIgaGFsZiBvZiB0aGUgNjQg
Yml0IGJhciBpcyBwcm9ncmFtbWVkLg0KPiA+IFRoaXMgZGlzcGxhY2VkIGFueSBSQU0gbWFwcGlu
Z3MgdW5kZXIgNEcuIEFmdGVyIHRoZQ0KPiA+IHVwcGVyIGhhbGYgaXMgcHJvZ3JhbW1lZCBQQ0kg
bWVtb3J5IG1hcHBpbmcgaXMgcmVzdG9yZWQgdG8gaXRzDQo+ID4gaW50ZW5kZWQgaGlnaCBtZW0g
bG9jYXRpb24sIGJ1dCB0aGUgUkFNIGRpc3BsYWNlZCBpcyBub3QgcmVzdG9yZWQuDQo+ID4gVGhl
IE9TIHRoZW4gY29udGludWVzIHRvIGJvb3QgYW5kIGZ1bmN0aW9uIHVudGlsIGl0IHRyaWVzIHRv
IGFjY2Vzcw0KPiA+IHRoZSBkaXNwbGFjZWQgUkFNIGF0IHdoaWNoIHBvaW50IGl0IHN1ZmZlcnMg
YSBwYWdlIGZhdWx0IGFuZA0KPiA+IGNyYXNoZXMuDQo+ID4gDQo+ID4gVGhpcyBwYXRjaCBhZGRy
ZXNzIHRoZSBpc3N1ZSBieSBkZWZlcnJpbmcgZW5hYmxlbWVudCBvZiBtZW1vcnkgYW5kDQo+ID4g
SS9PIGRlY29kZSBpbiBjb21tYW5kIHJlZ2lzdGVyIHVudGlsIGFsbCB0aGUgcmVzb3VyY2VzLCBs
aWtlDQo+ID4gaW50ZXJydXB0cw0KPiA+IEkvTyBhbmQvb3IgTU1JTyBCQVJzIGZvciBhbGwgdGhl
IFBDSSBkZXZpY2UgZnVuY3Rpb25zIGFyZQ0KPiA+IHByb2dyYW1tZWQsDQo+ID4gaW4gdGhlIGRl
c2NlbmRpbmcgb3JkZXIgb2YgbWVtb3J5IHJlcXVlc3RlZC4NCj4gPiANCj4gPiBTaWduZWQtb2Zm
LWJ5OiBIYXJzaGEgU2hhbXN1bmRhcmEgSGF2YW51ciA8aGF2YW51ckBhbWF6b24uY29tPg0KPiA+
IFJldmlld2VkLWJ5OiBQYXVsIER1cnJhbnQgPHBkdXJyYW50QGFtYXpvbi5jb20+DQo+ID4gQWNr
ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQo+IA0KPiBZ
b3UndmUgZml4ZWQgYnVncywgaW1wbHlpbmcgeW91IG5lZWQgdG8gZHJvcCB0YWdzIGNvdmVyaW5n
IHRoZSBjb2RlDQo+IHdoaWNoIHdhcyBmaXhlZC4gQXMgc2FpZCBvbiB2MiwgaW1vIHlvdSBzaG91
bGQgaGF2ZSBkcm9wcGVkIHRoZSB0YWdzDQo+IHRoZW4gYWxyZWFkeS4NCj4gDQo+ID4gLS0tIGEv
dG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3BjaS5jDQo+ID4gKysrIGIvdG9vbHMvZmlybXdhcmUv
aHZtbG9hZGVyL3BjaS5jDQo+ID4gQEAgLTg0LDYgKzg0LDcgQEAgdm9pZCBwY2lfc2V0dXAodm9p
ZCkNCj4gPiAgICAgIHVpbnQzMl90IHZnYV9kZXZmbiA9IDI1NjsNCj4gPiAgICAgIHVpbnQxNl90
IGNsYXNzLCB2ZW5kb3JfaWQsIGRldmljZV9pZDsNCj4gPiAgICAgIHVuc2lnbmVkIGludCBiYXIs
IHBpbiwgbGluaywgaXNhX2lycTsNCj4gPiArICAgIHVpbnQ4X3QgcGNpX2RldmZuX2RlY29kZV90
eXBlWzI1Nl0gPSB7fTsNCj4gDQo+IEknbSBzdGlsbCB3YWl0aW5nIGZvciBhIHJlcGx5IG9uIG15
IHYxIGNvbW1lbnQgb24gdGhlIHN0YWNrDQo+IGNvbnN1bXB0aW9uIG9mIHRoaXMsIHN1Z2dlc3Rp
bmcgdHdvIDI1Ni1iaXQgYml0bWFwcyBpbnN0ZWFkLg0KPiANCg0KSSBjaG9zZSB1aW50OCBhcnJh
eSBvdmVyIGJpdG1hcHMgYXMgdGhpcyByZWR1Y2VzIGNvbXBsZXhpdHkgb2YgY29kZQ0KdG8gZ2V0
IGFuZCBzZXQgaW5kaXZpZHVhbCBiaXRzLiBTb3JyeSBmb3IgbWlzc2luZyB0aGlzIG91dCBpbiB0
aGUgdjENCmNvbnZlcnNhdGlvbi4NCg0KPiA+IEBAIC0xMjAsNiArMTIxLDkgQEAgdm9pZCBwY2lf
c2V0dXAodm9pZCkNCj4gPiAgICAgICAqLw0KPiA+ICAgICAgYm9vbCBhbGxvd19tZW1vcnlfcmVs
b2NhdGUgPSAxOw0KPiA+IA0KPiA+ICsgICAgQlVJTERfQlVHX09OKCh0eXBlb2YoKnBjaV9kZXZm
bl9kZWNvZGVfdHlwZSkpUENJX0NPTU1BTkRfTUVNT1INCj4gPiBZICE9IFBDSV9DT01NQU5EX01F
TU9SWSk7DQo+ID4gKyAgICBCVUlMRF9CVUdfT04oKHR5cGVvZigqcGNpX2RldmZuX2RlY29kZV90
eXBlKSlQQ0lfQ09NTUFORF9JTyAhPQ0KPiA+IFBDSV9DT01NQU5EX0lPKTsNCj4gDQo+IFRoZXNl
IGxpbmVzIGFyZSB0b28gbG9uZy4NCj4gDQo+ID4gQEAgLTI4OCwxMCArMjkyLDIxIEBAIHZvaWQg
cGNpX3NldHVwKHZvaWQpDQo+ID4gICAgICAgICAgICAgIHByaW50ZigicGNpIGRldiAlMDJ4OiV4
IElOVCVjLT5JUlEldVxuIiwNCj4gPiAgICAgICAgICAgICAgICAgICAgIGRldmZuPj4zLCBkZXZm
biY3LCAnQScrcGluLTEsIGlzYV9pcnEpOw0KPiA+ICAgICAgICAgIH0NCj4gPiAtDQo+ID4gICAg
ICAgICAgLyogRW5hYmxlIGJ1cyBtYXN0ZXJpbmcuICovDQo+IA0KPiBQbGVhc2UgZG9uJ3QgZHJv
cCBhIGJsYW5rIGxpbmUgbGlrZSB0aGlzLg0KPiANCj4gPiAgICAgICAgICBjbWQgPSBwY2lfcmVh
ZHcoZGV2Zm4sIFBDSV9DT01NQU5EKTsNCj4gPiAgICAgICAgICBjbWQgfD0gUENJX0NPTU1BTkRf
TUFTVEVSOw0KPiA+ICsNCj4gPiArICAgICAgICAvKg0KPiA+ICsgICAgICAgICAqIERpc2FibGUg
bWVtb3J5IGFuZCBJL08gZGVjb2RlLA0KPiA+ICsgICAgICAgICAqIEl0IGlzIHJlY29tbWVuZGVk
IHRoYXQgQkFSIHByb2dyYW1taW5nIGJlIGRvbmUgd2hpbHN0DQo+ID4gKyAgICAgICAgICogZGVj
b2RlIGJpdHMgYXJlIGNsZWFyZWQgdG8gYXZvaWQgaW5jb3JyZWN0IG1hcHBpbmdzDQo+ID4gYmVp
bmcgY3JlYXRlZCwNCj4gPiArICAgICAgICAgKiB3aGVuIDY0LWJpdCBtZW1vcnkgQkFSIGlzIHBy
b2dyYW1tZWQgZmlyc3QgYnkgd3JpdGluZw0KPiA+IHRoZSBsb3dlciBoYWxmDQo+ID4gKyAgICAg
ICAgICogYW5kIHRoZW4gdGhlIHVwcGVyIGhhbGYsIHdoaWNoIGZpcnN0IG1hcHMgdG8gYW4gYWRk
cmVzcw0KPiA+IHVuZGVyIDRHDQo+ID4gKyAgICAgICAgICogcmVwbGFjaW5nIGFueSBSQU0gbWFw
cGVkIGluIHRoYXQgYWRkcmVzcywgd2hpY2ggaXMgbm90DQo+ID4gcmVzdG9yZWQNCj4gPiArICAg
ICAgICAgKiBiYWNrIGFmdGVyIHRoZSB1cHBlciBoYWxmIGlzIHdyaXR0ZW4gYW5kIFBDSSBtZW1v
cnkgaXMNCj4gPiBjb3JyZWN0bHkNCj4gPiArICAgICAgICAgKiBtYXBwZWQgdG8gaXRzIGludGVu
ZGVkIGhpZ2ggbWVtIGFkZHJlc3MuDQo+ID4gKyAgICAgICAgICovDQo+ID4gKyAgICAgICAgY21k
ICY9IH4oUENJX0NPTU1BTkRfTUVNT1JZIHwgUENJX0NPTU1BTkRfSU8pOw0KPiA+ICAgICAgICAg
IHBjaV93cml0ZXcoZGV2Zm4sIFBDSV9DT01NQU5ELCBjbWQpOw0KPiA+ICAgICAgfQ0KPiANCj4g
SSdkIGxpa2UgdG8gbm90ZSB0aGF0IHRoZSBkaXNhYmxpbmcgb2YgSU8gYW5kIE1FTU9SWSB5b3Ug
ZG8gaGVyZQ0KPiBjb21lcyB0b28NCj4gbGF0ZTogSXQgc2hvdWxkIGhhcHBlbiBiZWZvcmUgYW55
IG9mIHRoZSBCQVJzIGdldHMgd3JpdHRlbiB3aXRoIH4wLg0KPiBJbg0KPiBwYXJ0aWN1bGFyIGZv
ciA2NC1iaXQgQkFScyB0aGVzZSB3cml0ZXMgY2FuIGFnYWluIGNhdXNlIHVuZHVlIGVmZmVjdHMN
Cj4gb24NCj4gdGhlIGludGVybWVkaWF0ZWx5IHJlc3VsdGluZyBlZmZlY3RpdmUgYWRkcmVzc2Vz
Lg0KPiANCkkgYWdyZWUsIHRoaXMgbmVlZHMgdG8gYmUgZG9uZSBiZWZvcmUgd3JpdGluZyBCQVJT
IHdpdGggfjANCg0KPiA+IEBAIC01MjYsMTAgKzUzNywxNiBAQCB2b2lkIHBjaV9zZXR1cCh2b2lk
KQ0KPiA+ICAgICAgICAgICAqIGhhcyBJTyBlbmFibGVkLCBldmVuIGlmIHRoZXJlIGlzIG5vIEkv
TyBCQVIgb24gdGhhdA0KPiA+ICAgICAgICAgICAqIHBhcnRpY3VsYXIgZGV2aWNlLg0KPiA+ICAg
ICAgICAgICAqLw0KPiA+IC0gICAgICAgIGNtZCA9IHBjaV9yZWFkdyh2Z2FfZGV2Zm4sIFBDSV9D
T01NQU5EKTsNCj4gPiAtICAgICAgICBjbWQgfD0gUENJX0NPTU1BTkRfSU87DQo+ID4gLSAgICAg
ICAgcGNpX3dyaXRldyh2Z2FfZGV2Zm4sIFBDSV9DT01NQU5ELCBjbWQpOw0KPiA+ICsgICAgICAg
IHBjaV9kZXZmbl9kZWNvZGVfdHlwZVt2Z2FfZGV2Zm5dIHw9IFBDSV9DT01NQU5EX0lPOw0KPiA+
ICAgICAgfQ0KPiA+ICsNCj4gPiArICAgIC8qIEVuYWJsZSBtZW1vcnkgYW5kIEkvTyBkZWNvZGUu
ICovDQo+ID4gKyAgICBmb3IgKCBkZXZmbiA9IDA7IGRldmZuIDwgMjU2OyBkZXZmbisrICkNCj4g
PiArICAgICAgICBpZiAoIHBjaV9kZXZmbl9kZWNvZGVfdHlwZVtkZXZmbl0gKSB7DQo+IA0KPiBT
dHlsZTogVGhlIGJyYWNlIGJlbG9uZ3Mgb24gaXRzIG93biBsaW5lLg0KPiANCj4gVG8gc2F2ZSBv
bmUgc2V0IG9mIHdyaXRlcyB0byB0aGUgY29tbWFuZCByZWdpc3RlcnMgSSB3b3VsZCwgYnR3LA0K
PiBiZSBva2F5IHdpdGggeW91IG1vdmluZyB0aGUgTUFTVEVSIGVuYWJsaW5nIGhlcmUuDQo+IA0K
R29vZCBwb2ludC4gSSB3aWxsIG1ha2UgdGhlc2UgY2hhbmdlcyBpbiB2NC4NCg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 16:00:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 16:00:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jONyV-0006VT-Jp; Tue, 14 Apr 2020 15:59:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Lvws=56=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jONyV-0006VO-6S
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 15:59:47 +0000
X-Inumbo-ID: f61640bc-7e68-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f61640bc-7e68-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 15:59:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 41056ABCE;
 Tue, 14 Apr 2020 15:59:44 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] docs: update xenstore migration design document
Date: Tue, 14 Apr 2020 17:59:42 +0200
Message-Id: <20200414155942.3347-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In the past there have been several attempts to make Xenstore
restartable. This requires to transfer the internal Xenstore state to
the new instance. With the Xenstore migration protocol added recently
to Xen's documentation a first base has been defined to represent the
state of Xenstore. This can be expanded a little bit in order to have
a full state representation which is needed as a first step for live
updating Xenstore.

Add some definitions to designs/xenstore-migration.md which are needed
for live update of xenstored.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 docs/designs/xenstore-migration.md | 90 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 87 insertions(+), 3 deletions(-)

diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
index 6ab351e8fe..09bb4700b4 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -9,6 +9,10 @@ records must include details of registered xenstore watches as well as
 content; information that cannot currently be recovered from `xenstored`,
 and hence some extension to the xenstore protocol[2] will also be required.
 
+As a similar set of data is needed for transferring xenstore data from
+one instance to another when live updating xenstored the same definitions
+are being used.
+
 The *libxenlight Domain Image Format* specification[3] already defines a
 record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
 transferring xenstore data pertaining to the domain directly as it is
@@ -48,7 +52,10 @@ where type is one of the following values
 |        | 0x00000001: NODE_DATA                            |
 |        | 0x00000002: WATCH_DATA                           |
 |        | 0x00000003: TRANSACTION_DATA                     |
-|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
+|        | 0x00000004: TRANSACTION_NODE_DATA                |
+|        | 0x00000005: GUEST_RING_DATA                      |
+|        | 0x00000006: DOMAIN_START (live update only)      |
+|        | 0x00000007 - 0xFFFFFFFF: reserved for future use |
 
 
 and data is one of the record data formats described in the following
@@ -79,7 +86,7 @@ as follows:
 +-------------------------------+
 | perm count (N)                |
 +-------------------------------+
-| perm0                         |
+| perm1                         |
 +-------------------------------+
 ...
 +-------------------------------+
@@ -93,7 +100,7 @@ as follows:
 +-------------------------------+
 ```
 
-where perm0..N are formatted as follows:
+where perm1..N are formatted as follows:
 
 
 ```
@@ -164,6 +171,83 @@ as follows:
 where tx_id is the non-zero identifier values of an open transaction.
 
 
+**TRANSACTION_NODE_DATA**
+
+
+Each TRANSACTION_NODE_DATA record specifies a transaction local xenstore
+node. Its is similar to the NODE_DATA record with the addition of a
+transaction id:
+
+```
+    0       1       2       3     octet
++-------+-------+-------+-------+
+| TRANSACTION_NODE_DATA         |
++-------------------------------+
+| tx_id                         |
++-------------------------------+
+| path length                   |
++-------------------------------+
+| path data                     |
+...
+| pad (0 to 3 octets)           |
++-------------------------------+
+| perm count (N)                |
++-------------------------------+
+| perm1                         |
++-------------------------------+
+...
++-------------------------------+
+| permN                         |
++-------------------------------+
+| value length                  |
++-------------------------------+
+| value data                    |
+...
+| pad (0 to 3 octets)           |
++-------------------------------+
+```
+
+where perm1..N are formatted as specified in the NODE_DATA record. A perm
+count of 0 denotes a node having been deleted in the transaction.
+
+
+**GUEST_RING_DATA**
+
+
+The GUEST_RING_DATA record is used to transfer data which is pending to be
+written to the guest's xenstore ring buffer. It si formatted as follows:
+
+
+```
++-------+-------+-------+-------+
+| GUEST_RING_DATA               |
++-------------------------------+
+| value length                  |
++-------------------------------+
+| value data                    |
+...
+| pad (0 to 3 octets)           |
++-------------------------------+
+```
+
+**DOMAIN_START**
+
+
+For live updating xenstored data of multiple domains needs to be transferred.
+For this purpose the DOMAIN_START record is being used. All records of types
+other than NODE_DATA always relate to the last DOMAIN_START record in the
+stream. A DOMAIN_START record just contains a domain-id:
+
+
+```
++-------+-------+-------+-------+
+| DOMAIN_START                  |
++-------------------------------+
+| domid         | pad           |
++-------------------------------+
+```
+
+
 ### Protocol Extension
 
 Before xenstore state is migrated it is necessary to wait for any pending
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 16:26:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 16:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOOOD-00017R-WD; Tue, 14 Apr 2020 16:26:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOOOC-00017M-Sd
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 16:26:20 +0000
X-Inumbo-ID: abddaf4a-7e6c-11ea-8966-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id abddaf4a-7e6c-11ea-8966-12813bfff9fa;
 Tue, 14 Apr 2020 16:26:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586881580;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=du4dLq7Ohce3WtFAWegYvi3R/5cSyNzhzKHfV7+9Tr4=;
 b=hdJQ56covh8yJRFbWzkN6BkK7L2DXCRUiemrB1b4/xqBF/JO9H4/4R5V
 6Hrl/duYZ8UHgYyH4q0ViM19pT07wE9yv33lljzYP+Ake6GkjMJeCcRum
 vsxW/RFi+QyJZUkGllFfOlbTJw9ag0nfzqc4mVLkX5jV2k1ZHw5ieWJ6w o=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: HpiWuVivxTMC4L8HmwfI2fD/Z+9oJVrK0SYKTNqbVMd/cFFrSICszrOXT+wwysnMAj57i/3BHs
 6teQO4IZL3hI/cziLfUneTKjLsBOeDaNNPn+mHjCbYNj3WoRKhAAGgWLjSGcuG64b4w35KTOer
 2OvZtBEO+LPB7B3WkWMbQfbAu1ydRtJ5KT/koJlHxVQhpOKJiM7q0AHHEOItm9oRt+DhXSC1KD
 oBfQ7IdYYu7BxIvqVYKerobfLxSetPQ/RD7R9EvC61R1XtvpmKHeFm2qppg7NnNLQKhQVAUmCW
 Fiw=
X-SBRS: 2.7
X-MesageID: 15898579
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,383,1580792400"; d="scan'208";a="15898579"
Subject: Re: [XEN PATCH v3] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: Jan Beulich <jbeulich@suse.com>, Harsha Shamsundara Havanur
 <havanur@amazon.com>
References: <758e3427f147ed82774edcbbe80b0b29c812e6e4.1586862721.git.havanur@amazon.com>
 <3926fb02-2058-6e3a-6dcd-3ac5c4b97de5@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <5e86b2bc-2d79-3062-856b-c9babfcc5a16@citrix.com>
Date: Tue, 14 Apr 2020 17:26:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3926fb02-2058-6e3a-6dcd-3ac5c4b97de5@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14/04/2020 15:12, Jan Beulich wrote:
> On 14.04.2020 13:12, Harsha Shamsundara Havanur wrote:
>> It was observed that PCI MMIO and/or IO BARs were programmed with
>> memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
>> during PCI setup phase. This resulted in incorrect memory mapping as
>> soon as the lower half of the 64 bit bar is programmed.
>> This displaced any RAM mappings under 4G. After the
>> upper half is programmed PCI memory mapping is restored to its
>> intended high mem location, but the RAM displaced is not restored.
>> The OS then continues to boot and function until it tries to access
>> the displaced RAM at which point it suffers a page fault and crashes.
>>
>> This patch address the issue by deferring enablement of memory and
>> I/O decode in command register until all the resources, like interrupts
>> I/O and/or MMIO BARs for all the PCI device functions are programmed,
>> in the descending order of memory requested.
>>
>> Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
>> Reviewed-by: Paul Durrant <pdurrant@amazon.com>
>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

I have not acked this patch.  My comment on v1 was correctly your
mis-spelling of "Ack-by" for Paul's tag.  I apologise if that wasn't
terribly clear.

> You've fixed bugs, implying you need to drop tags covering the code
> which was fixed. As said on v2, imo you should have dropped the tags
> then already.
>
>> --- a/tools/firmware/hvmloader/pci.c
>> +++ b/tools/firmware/hvmloader/pci.c
>> @@ -84,6 +84,7 @@ void pci_setup(void)
>>      uint32_t vga_devfn = 256;
>>      uint16_t class, vendor_id, device_id;
>>      unsigned int bar, pin, link, isa_irq;
>> +    uint8_t pci_devfn_decode_type[256] = {};
> I'm still waiting for a reply on my v1 comment on the stack
> consumption of this, suggesting two 256-bit bitmaps instead.

256 bytes of stack space isn't something to worry about.  Definitely not
for the complexity of using bitmaps instead.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 16:53:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 16:53:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOOoJ-0003fD-Cn; Tue, 14 Apr 2020 16:53:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=62lU=56=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOOoH-0003f8-FI
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 16:53:17 +0000
X-Inumbo-ID: 6f9b0574-7e70-11ea-8972-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6f9b0574-7e70-11ea-8972-12813bfff9fa;
 Tue, 14 Apr 2020 16:53:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=C2Hzg9qc6VGt4ffZRICFMUPtb0d1/k+vpZUvg8uwdZM=; b=FmixO8gE36FIdCr8QTVdyL9YKi
 ugA/3inhzbioRHg7lhuJV294d0DF/LqsVkZssPWsqMDEJaYGvS9eabgoqrsY6edD80DuPEyUF4Yig
 hhEAkt/l3foUScbCuzlCQi91RA/JP6v9LR5sysG5ckTew1Aj+McrKQnUn7caTs2+iIMs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOOoE-0006qd-NT; Tue, 14 Apr 2020 16:53:14 +0000
Received: from 54-240-197-224.amazon.com ([54.240.197.224]
 helo=freeip.amazon.com) by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOOoE-0004lW-D3; Tue, 14 Apr 2020 16:53:14 +0000
Message-ID: <aacb942aa6febd13211ca799a6456adf510cee89.camel@xen.org>
Subject: Re: [PATCH v2 1/5] x86/shim: map and unmap page tables in
 replace_va_mapping
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Date: Tue, 14 Apr 2020 17:53:12 +0100
In-Reply-To: <ddbad9f5-307e-7b1d-0cc7-cd7ed684f680@suse.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <7638095024ec3379a8d9ddadfe47e36da168e4dd.1586352238.git.hongyxia@amazon.com>
 <ddbad9f5-307e-7b1d-0cc7-cd7ed684f680@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, 2020-04-09 at 11:42 +0200, Jan Beulich wrote:
> On 08.04.2020 15:36, Hongyan Xia wrote:
> > --- a/xen/arch/x86/pv/shim.c
> > +++ b/xen/arch/x86/pv/shim.c
> > @@ -168,16 +168,17 @@ const struct platform_bad_page *__init
> > pv_shim_reserved_pages(unsigned int *size
> >  static void __init replace_va_mapping(struct domain *d,
> > l4_pgentry_t *l4start,
> >                                        unsigned long va, mfn_t mfn)
> >  {
> > -    l4_pgentry_t *pl4e = l4start + l4_table_offset(va);
> > -    l3_pgentry_t *pl3e = l4e_to_l3e(*pl4e) + l3_table_offset(va);
> > -    l2_pgentry_t *pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(va);
> > -    l1_pgentry_t *pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(va);
> > +    l4_pgentry_t l4e = l4start[l4_table_offset(va)];
> > +    l3_pgentry_t l3e = l3e_from_l4e(l4e, l3_table_offset(va));
> > +    l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(va));
> > +    l1_pgentry_t *pl1e = map_l1t_from_l2e(l2e) +
> > l1_table_offset(va);
> >      struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e));
> >  
> >      put_page_and_type(page);
> >  
> >      *pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT
> >                                                        :
> > COMPAT_L1_PROT));
> > +    UNMAP_DOMAIN_PAGE(pl1e);
> >  }
> 
> As said before, here and below I think it should be
> unmap_domain_page().
> 
> > --- a/xen/include/asm-x86/page.h
> > +++ b/xen/include/asm-x86/page.h
> > @@ -196,6 +196,19 @@ static inline l4_pgentry_t
> > l4e_from_paddr(paddr_t pa, unsigned int flags)
> >  #define map_l2t_from_l3e(x)        (l2_pgentry_t
> > *)map_domain_page(l3e_get_mfn(x))
> >  #define map_l3t_from_l4e(x)        (l3_pgentry_t
> > *)map_domain_page(l4e_get_mfn(x))
> >  
> > +/* Unlike lYe_to_lXe(), lXe_from_lYe() do not rely on the direct
> > map. */
> > +#define l2e_from_l3e(l3e, offset) ({                        \
> > +        const l2_pgentry_t *l2t = map_l2t_from_l3e(l3e);    \
> > +        l2_pgentry_t l2e = l2t[offset];                     \
> > +        UNMAP_DOMAIN_PAGE(l2t);                             \
> > +        l2e; })
> > +
> > +#define l3e_from_l4e(l4e, offset) ({                        \
> > +        const l3_pgentry_t *l3t = map_l3t_from_l4e(l4e);    \
> > +        l3_pgentry_t l3e = l3t[offset];                     \
> > +        UNMAP_DOMAIN_PAGE(l3t);                             \
> > +        l3e; })
> 
> I think l1e_from_l2e() should be introduced at the same time, even
> if for now it's unused. I also think, like we do elsewhere, that
> macro-local variables would better have _ suffixes, to avoid
> possible variable aliasing issues.

Shall I address the comments and send a new rev now, or is this small
series still being reviewed?

Hongyan



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 16:54:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 16:54:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOOpj-0003lO-Ql; Tue, 14 Apr 2020 16:54:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=5lL2=56=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOOpj-0003lH-51
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 16:54:47 +0000
X-Inumbo-ID: a511ad7a-7e70-11ea-83d8-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a511ad7a-7e70-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 16:54:46 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 236962076A;
 Tue, 14 Apr 2020 16:54:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586883285;
 bh=qzL6FDsFZCDJUSJEtA0V8eaxVB8g+SePx4SqY88TjuU=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=ylK8sQ6OYXJxDlPoY4d6SLJAm4MBMaVU32p7W3em8GDAacVNgGAwOqDlrlvFCZBKr
 Y7cti+LSL210cIaiYBnHruMuSVhug3sLoXNOXHbbvmixfGPbcE9Gyi0TH5L0MBm8WX
 nXmDSF5B8gyfMZXcBo3iIQxxbY2sNz3YclCXXPdU=
Date: Tue, 14 Apr 2020 09:54:38 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
In-Reply-To: <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
Message-ID: <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
References: <20200410164942.9747-1-sstabellini@kernel.org>
 <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, Stefano Stabellini <sstabellini@kernel.org>,
 julien@xen.org, konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
 george.dunlap@citrix.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, 14 Apr 2020, Jan Beulich wrote:
> On 10.04.2020 18:49, Stefano Stabellini wrote:
> > Create a new document under docs/process to describe our special tags.
> > For now, only add the new backport tag.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > Acked-by: Wei Liu <wl@xen.org>
> > CC: jbeulich@suse.com
> > CC: george.dunlap@citrix.com
> > CC: julien@xen.org
> > CC: lars.kurth@citrix.com
> > CC: andrew.cooper3@citrix.com
> > CC: konrad.wilk@oracle.com
> > 
> > ---
> > 
> > This is the original thread: https://marc.info/?l=xen-devel&m=157324027614941
> > 
> > The backport tag was agreed upon.
> 
> Well, sort of.
> 
> > George requested the file to be
> > renamed to something more generic, where we could add more information
> > later.
> > 
> > I kept the original content and acked-by. I renamed the file to
> > tags.pandoc.
> > ---
> >  docs/process/tags.pandoc | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> >  create mode 100644 docs/process/tags.pandoc
> > 
> > diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
> > new file mode 100644
> > index 0000000000..e570efdcc8
> > --- /dev/null
> > +++ b/docs/process/tags.pandoc
> > @@ -0,0 +1,23 @@
> > +Backport Tag
> > +------------
> > +
> > +A backport tag is an optional tag in the commit message to request a
> > +given commit to be backported to the stable trees:
> 
> Insert "fully maintained"?

Yep I'll add.


> > +    Backport: all
> > +
> > +It marks a commit for being a candidate for backports to all relevant
> > +trees.
> 
> I'm unconvinced of the utility of this form - what "all" resolves to
> changes over time. There's almost always a first version where a
> particular issue was introduced. If we want this to be generally
> useful, imo we shouldn't limit the scope of the tag to the upstream
> maintained stable trees.

The reason why I suggested also to have a "wildcard" version of this
tag, is that the person adding the tag (could be the contributor trying
to be helpful) might not know exactly to which stable trees the patch
should be backported to.

Writing this sentence, I realize that I really meant "any" rather than
"all". Would you prefer if I used "any"? Or we could even suggest to leave
it black like this:

  Backport:

But it looks a bit weird.


> > +    Backport: 4.9+
> > +
> > +It marks a commit for being a candidate for backports to all stable
> > +trees from 4.9 onward.
> > +
> > +Maintainers request the Backport tag to be added on commit.
> > +Contributors are also welcome to mark their patches with the Backport
> > +tag when they deem appropriate. Maintainers will request for it to be
> > +removed when that is not the case.
> > +
> > +Please note that the Backport tag is a **request** for backport, which
> > +will still need to be evaluated by the stable tree maintainers.
> 
> Now that we see more widespread use of the Fixes: tag, with there
> being effectively some overlap between the information conveyed I
> think there should be some mention of this. Not the least there's the
> risk of the Backport: one to become stale when a flaky commit gets
> backported - the Fixes: tag doesn't have this issue.

Yes, that's true, but "Fixes" cannot always be used. I can add a
statement like: "When possible use the Fixes tag."

Also, I can pull in the description of Fixes and add it to this file
too.


Fixes tag
---------

If your patch fixes a bug in a specific commit, e.g. you found an issue using
``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
the SHA-1 ID, and the one line summary.  Do not split the tag across multiple
lines, tags are exempt from the "wrap at 75 columns" rule in order to simplify
parsing scripts.  For example::

	Fixes: 41548c5472a "mem_sharing: VM forking"

The following ``git config`` settings can be used to add a pretty format for
outputting the above style in the ``git log`` or ``git show`` commands::

	[core]
		abbrev = 12
	[pretty]
		fixes = Fixes: %h (\"%s\")


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 17:15:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 17:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOP9X-0005Za-Ow; Tue, 14 Apr 2020 17:15:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=kDu3=56=amazon.com=prvs=3660aa63e=havanur@srs-us1.protection.inumbo.net>)
 id 1jOP9W-0005ZV-Go
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 17:15:14 +0000
X-Inumbo-ID: 807ac548-7e73-11ea-9e09-bc764e2007e4
Received: from smtp-fw-33001.amazon.com (unknown [207.171.190.10])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 807ac548-7e73-11ea-9e09-bc764e2007e4;
 Tue, 14 Apr 2020 17:15:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586884513; x=1618420513;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=Lia9k+AgDON+UwHCdetdjQRuiR3E0OJx7tIi15mMZFk=;
 b=gTzJKtv8JsCduGKG+LMMDFFrkTklwvbzRbJe78EcmzelONFbUy6ny8r7
 F5XuwSAfWPC/4AAag9UraV4R6TOFxxMpgbY2SmeOs6zXE//DJBY1SXfEX
 9/5sRwiVehpYGmPLbm+v6Ui8m/HVnDpxT5J47/+J+tZIHkyJRtCOdEUDM I=;
IronPort-SDR: 8HBJGoZ0WA1PkKJ1mBI5KZbpnVi6eT0KCXg/D3yyUiKfvG2H2Itk5mStWM+bJLjXPsVGNcqJtE
 2Aiv9EktZJTw==
X-IronPort-AV: E=Sophos;i="5.72,383,1580774400"; d="scan'208";a="38423782"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP;
 14 Apr 2020 17:15:10 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])
 by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (Postfix) with ESMTPS
 id 48C812826FB; Tue, 14 Apr 2020 17:15:07 +0000 (UTC)
Received: from EX13D36EUA003.ant.amazon.com (10.43.165.14) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 17:15:07 +0000
Received: from EX13MTAUWC001.ant.amazon.com (10.43.162.135) by
 EX13D36EUA003.ant.amazon.com (10.43.165.14) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 14 Apr 2020 17:15:06 +0000
Received: from dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com
 (172.19.122.179) by mail-relay.amazon.com (10.43.162.232) with Microsoft SMTP
 Server id 15.0.1497.2 via Frontend Transport; Tue, 14 Apr 2020 17:15:04 +0000
Received: by dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com (Postfix,
 from userid 11119479)
 id 5B32D83ECD; Tue, 14 Apr 2020 17:15:04 +0000 (UTC)
From: Harsha Shamsundara Havanur <havanur@amazon.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v4] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Tue, 14 Apr 2020 17:15:02 +0000
Message-ID: <4b6c017245698c18b063d156be645b8b633c0a99.1586884502.git.havanur@amazon.com>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Harsha Shamsundara Havanur <havanur@amazon.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It was observed that PCI MMIO and/or IO BARs were programmed with
memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
during PCI setup phase. This resulted in incorrect memory mapping as
soon as the lower half of the 64 bit bar is programmed.
This displaced any RAM mappings under 4G. After the
upper half is programmed PCI memory mapping is restored to its
intended high mem location, but the RAM displaced is not restored.
The OS then continues to boot and function until it tries to access
the displaced RAM at which point it suffers a page fault and crashes.

This patch address the issue by deferring enablement of memory and
I/O decode in command register until all the resources, like interrupts
I/O and/or MMIO BARs for all the PCI device functions are programmed,
in the descending order of memory requested.

Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>

---
Changes in v4:
  Addressed review comments from Jan Beulich <jbeulich@suse.com>
  - Disable decodes before writing ~0 to BARs
  - Enable BUS MASTER at the end along with decode bits

Changes in v3:
  - Retained enabling of BUS master for all device functions as
    was in original commit

Changes in v2:
  - BUS MASTER state was captured and restored to the same state
    while enabling decode bits.
---
---
 tools/firmware/hvmloader/pci.c | 45 ++++++++++++++++++++++++++++++------------
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 0b708bf578..69c30f0548 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -84,6 +84,7 @@ void pci_setup(void)
     uint32_t vga_devfn = 256;
     uint16_t class, vendor_id, device_id;
     unsigned int bar, pin, link, isa_irq;
+    uint8_t pci_devfn_decode_type[256] = {};
 
     /* Resources assignable to PCI devices via BARs. */
     struct resource {
@@ -120,6 +121,11 @@ void pci_setup(void)
      */
     bool allow_memory_relocate = 1;
 
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY
+            != PCI_COMMAND_MEMORY);
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO
+            != PCI_COMMAND_IO);
+
     s = xenstore_read(HVM_XS_ALLOW_MEMORY_RELOCATE, NULL);
     if ( s )
         allow_memory_relocate = strtoll(s, NULL, 0);
@@ -208,6 +214,20 @@ void pci_setup(void)
             break;
         }
 
+        /*
+         * Disable memory and I/O decode,
+         * It is recommended that BAR programming be done whilst
+         * decode bits are cleared to avoid incorrect mappings being created,
+         * when 64-bit memory BAR is programmed first by writing the lower half
+         * and then the upper half, which first maps to an address under 4G
+         * replacing any RAM mapped in that address, which is not restored
+         * back after the upper half is written and PCI memory is correctly
+         * mapped to its intended high mem address.
+         */
+        cmd = pci_readw(devfn, PCI_COMMAND);
+        cmd &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
+        pci_writew(devfn, PCI_COMMAND, cmd);
+
         /* Map the I/O memory and port resources. */
         for ( bar = 0; bar < 7; bar++ )
         {
@@ -289,10 +309,6 @@ void pci_setup(void)
                    devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
         }
 
-        /* Enable bus mastering. */
-        cmd = pci_readw(devfn, PCI_COMMAND);
-        cmd |= PCI_COMMAND_MASTER;
-        pci_writew(devfn, PCI_COMMAND, cmd);
     }
 
     if ( mmio_hole_size )
@@ -497,16 +513,12 @@ void pci_setup(void)
                PRIllx_arg(bar_sz),
                bar_data_upper, bar_data);
 			
-
-        /* Now enable the memory or I/O mapping. */
-        cmd = pci_readw(devfn, PCI_COMMAND);
         if ( (bar_reg == PCI_ROM_ADDRESS) ||
              ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
               PCI_BASE_ADDRESS_SPACE_MEMORY) )
-            cmd |= PCI_COMMAND_MEMORY;
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
         else
-            cmd |= PCI_COMMAND_IO;
-        pci_writew(devfn, PCI_COMMAND, cmd);
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_IO;
     }
 
     if ( pci_hi_mem_start )
@@ -526,10 +538,17 @@ void pci_setup(void)
          * has IO enabled, even if there is no I/O BAR on that
          * particular device.
          */
-        cmd = pci_readw(vga_devfn, PCI_COMMAND);
-        cmd |= PCI_COMMAND_IO;
-        pci_writew(vga_devfn, PCI_COMMAND, cmd);
+        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
     }
+
+    /* Enable bus master, memory and I/O decode. */
+    for ( devfn = 0; devfn < 256; devfn++ )
+        if ( pci_devfn_decode_type[devfn] )
+        {
+            cmd = pci_readw(devfn, PCI_COMMAND);
+            cmd |= (PCI_COMMAND_MASTER | pci_devfn_decode_type[devfn]);
+            pci_writew(devfn, PCI_COMMAND, cmd);
+        }
 }
 
 /*
-- 
2.16.6



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 18:16:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 18:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOQ6t-0003gk-Ap; Tue, 14 Apr 2020 18:16:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOQ6r-0003gf-UV
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 18:16:33 +0000
X-Inumbo-ID: 118f1b26-7e7c-11ea-898e-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 118f1b26-7e7c-11ea-898e-12813bfff9fa;
 Tue, 14 Apr 2020 18:16:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586888193;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=KeuI8SBj0d38u+/4Pd02DQh0/Hd0mn0uyFPFWXnUCvg=;
 b=DEyEtVQ4PiQgDZOzOIgEv2jV6y4r4KG7eGJle/1VO5IMFymVCgk/cVOj
 H7Jzi4yFH9ByIt1Er0Ld8xgsew54r0zsOuPyo2x4g3owwzeeHw0hc5lge
 i+nmhyfdnoBeCXoqOBDNHOoNbeoKdZL5i0hTkB8JjzfVOVZTl5W/c/eGt s=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: KWX9KNA65WJlTefrLwe8XGHHQ8o/69XvgeFpcOf0qXe3DpboxPTLsgjZcMFqizb5X5nXPI/aOC
 fDPL5teHMf9m5R1RW/qnj3BdzwLL+dJ4u6LGdHGtGv5mpLj5t76A7Tvb+73bO9OSUzR8HUBc4l
 MHP0AejOcK4pdSdO//qXaEiMfCvz+/RpR+5yfORIxeskYQduzAdx0t/nToXuAoN5XMHWBrQz/G
 V8PpslwxWU3p1F0g/DbDnNn5VWi5b9WIPMRJCZoJjUuwAKZAGbiQWoJVsqFoOmlNEfoa8F0Jdp
 T2Y=
X-SBRS: 2.7
X-MesageID: 15907421
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,383,1580792400"; d="scan'208";a="15907421"
Subject: Re: [PATCH v2 03/17] tools/migration: Drop IHDR_VERSION constant from
 libxc and python
To: Ian Jackson <ian.jackson@citrix.com>
References: <20200127143444.25538-1-andrew.cooper3@citrix.com>
 <20200127143444.25538-4-andrew.cooper3@citrix.com>
 <24148.1780.909250.638385@mariner.uk.xensource.com>
 <1f074dca-9798-1ed9-0163-882eb2079d53@citrix.com>
 <24161.12968.77707.404087@mariner.uk.xensource.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <b016711e-034d-cf00-1434-beb75b9c263d@citrix.com>
Date: Tue, 14 Apr 2020 19:16:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <24161.12968.77707.404087@mariner.uk.xensource.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 05/03/2020 17:11, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v2 03/17] tools/migration: Drop IHDR_VERSION constant from libxc and python"):
>> On 24/02/2020 17:25, Ian Jackson wrote:
>>> Andrew Cooper writes ("[PATCH v2 03/17] tools/migration: Drop IHDR_VERSION constant from libxc and python"):
>>>> Migration v3 is in the process of being introduced, meaning that the code has
>>>> to cope with both versions.  Use an explicit 2 for now.
>>>>
>>>> For the verify-stream-v2 and convert-legacy-stream scripts, update
>>>> text to say "v2 (or later)".  What matters is the distinction vs
>>>> legacy streams.
>>> Can I request that you use a manifest constant for `2', rather than
>>> sprinkling literal `2's everywhere ?  Something like IHDR_VERSION_2 ?
>>> This may seem pointless, but it will mean that it is possible to grep
>>> the code much more easily for things which are relevant to v2 or v3 or
>>> whatever.
>>>
>>> (I don't it's necessary to go to any great lengths to substitute the
>>> value of IHDR_VERSION_2 into error messages; a literal 2 in the string
>>> is OK I think.)
>> As I reply previously... The value comes out of a pipe, and is checked
>> exactly once.
> I think we are talking at cross purposes.
>
> I am suggesting that you replace every instance of a numeric literal
> `2' in the code with IHDR_VERSION_2 (which would be a #define or enum
> for 2).
>
> I count 4 such literals.

I presume you mean here 2x send IHDR and 2x receive IHDR, one C and one
Python in each case.

I understand what you're suggesting.  I completely disagree with it, as
it obfuscates the logic and introduces a source of bugs for zero gain.

IHDR_VERSION_* isn't grepable.  You've got to find the only instance of
it in code to figure out what to search for.

>> You can already grep for everything, using format_version which is where
>> this number is stashed for the duration of restore.
> None of the things I am talking about have "format_version" nearby.
> They tend to have variants on "version" but that is a poor thing to
> grep for.

"ctx->restore.format_version = ihdr.version;" (the only instance in the
codebase at this point in the series) is immediately after ihdr is
sanity checked, which is sole time where idhr.version has its value
checked (in the restore path.  There is also exactly one place in the
save side, and any more than this would be buggy code).

The only thing IHDR_VERSION_* usefully gets you is the ability to get
the defines accidentally wrong, and introduce bugs that way.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 18:30:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 18:30:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOQKd-0005LH-Pv; Tue, 14 Apr 2020 18:30:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qlbo=56=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOQKc-0005LC-KD
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 18:30:46 +0000
X-Inumbo-ID: 0df57f58-7e7e-11ea-8991-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0df57f58-7e7e-11ea-8991-12813bfff9fa;
 Tue, 14 Apr 2020 18:30:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mgc7llb6rxVb1gCPluYbxfbnfxfmlmmMTP4Uea/kMT4=; b=Hg6xcuqnK2uSbcsvZVMI7ZZkX
 gZoQLiJTWkLj4aYlzrFN3Vva3TU6UVcormCodx35wxaeJYJi8jWqA8X6wR1Uk07k3TdIlk84ErLqQ
 OSqSpWUVNk7LIPEXaP2Acrqi7GYFafwkjw22LRTZRv7L68R3r6UEiGxwrW5drmTP6YLyc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOQKb-0000V7-1x; Tue, 14 Apr 2020 18:30:45 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOQKa-0004zL-Oc; Tue, 14 Apr 2020 18:30:44 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOQKa-0000KS-Nz; Tue, 14 Apr 2020 18:30:44 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149654-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149654: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=fcd06227f83643194f8018f8dd37adce57763a61
X-Osstest-Versions-That: xen=d6f22d5d9e8d6848ec229083ac9fb044f0adea93
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 14 Apr 2020 18:30:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  fcd06227f83643194f8018f8dd37adce57763a61
baseline version:
 xen                  d6f22d5d9e8d6848ec229083ac9fb044f0adea93

Last test of basis   149645  2020-04-14 13:01:02 Z    0 days
Testing same since   149654  2020-04-14 16:01:51 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   d6f22d5d9e..fcd06227f8  fcd06227f83643194f8018f8dd37adce57763a61 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 18:43:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 18:43:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOQXG-0006OV-3j; Tue, 14 Apr 2020 18:43:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOQXF-0006OQ-78
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 18:43:49 +0000
X-Inumbo-ID: e016173a-7e7f-11ea-83d8-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e016173a-7e7f-11ea-83d8-bc764e2007e4;
 Tue, 14 Apr 2020 18:43:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586889829;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=EBQMiQ2jgYn+oPnB6DtmMKkWKmvsMtEMA+Ls2Y/8qEQ=;
 b=fiCay6QRhgTOtaFQEgJ7tkta64HMD1Fj6KxwRLE8XZfQdRdz0v+a0Qcb
 XobqcuoZaWp4RzcWTjV9ZS0/WlP9+Xh6XV2wlNjWiwMXy9AAoMtvpZvKB
 hQrsny+p+BPGOJDLuFrY9n3uSyXPzqTRDMsIjUF3E3Uq077rzSQDXsiIu 8=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Vs99ILpszvDFV58HEgzvm8EoKyhLoxYsYgjGc/fF6b1dzZ3cdmsuFAPoEReDmFDShCOqoqUDl9
 yQVU8mckMmSuanAcuOvbdowooT4Gv5OXceD8p5QT3b9Dy8wgzgUpSQDKQ7tJr9IbiDiTDXzjTE
 BNQctFsFKb5RmiSZGXV+sc7Rlze2DzuX+/26U7L6XNQZhzxLtkCkYwF+5p1cpKH5OzI7j69ork
 ecdVctcqNnymtGOjIFhgikX6pPeegp4l5bQ8OrJltrxUN9tPo32R79d8GlAWFk34Y+m6XgDMjy
 hJ4=
X-SBRS: 2.7
X-MesageID: 15909004
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,383,1580792400"; d="scan'208";a="15909004"
Subject: Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END inference for v2
 compatibility
To: Ian Jackson <ian.jackson@citrix.com>
References: <20200127143444.25538-1-andrew.cooper3@citrix.com>
 <20200127143444.25538-8-andrew.cooper3@citrix.com>
 <24148.2202.912512.939428@mariner.uk.xensource.com>
 <cea79256-f260-1710-a783-dadec276e32a@citrix.com>
 <24161.10156.858608.199136@mariner.uk.xensource.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <2076e9a4-c07e-9aab-1cc2-f38f7eacd8c0@citrix.com>
Date: Tue, 14 Apr 2020 19:43:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <24161.10156.858608.199136@mariner.uk.xensource.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 05/03/2020 16:24, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END inference for v2 compatibility"):
>> On 24/02/2020 17:32, Ian Jackson wrote:
>>> These 17 lines appears twice, in basically identical form.  Could it
>>> be refactored ?
>> Not really, no.
>>
>> The error handling (i.e. half of those 17 lines) is different, making it
>> somewhat awkward to fit into a static inline.
> You could handle that with a small bit of code around one of the call
> sites to adjust the error handling.  (Also, what a mess, but I guess
> we're here now...)

... which is the majority the code you're trying to abstract away.

>
>> More importantly however, by design, common code can't call
>> arch-specific code without a restore_ops hook.  Deduping these would
>> require breaking the restriction which is currently doing a decent job
>> of keeping x86-isms out of common code.
> I'm afraid you're going to have to explain that to me at a bit greater
> length.  The biggest thing that is confusing me about your statement
> here is that your patch is indeed adding x86-specific code to a common
> file.  But also I don't understand the comment about restore_ops
> hooks - do you mean something in restore_callbacks ?

No.  restore_callbacks are plumbing between libxl-save-helper and libxc.

restore_ops are internal to the restore code, and come in x86_pv and
x86_hvm flavours, with ARM existing in some theoretical future.  The
design of the common save/restore code had deliberate measures put in
place to make it hard to get arch-specific details slip into common
code, so porting to different architectures didn't have to start by
doing a bunch of cleanup.

tl;dr I could put an #ifdef x86'd static inline in the root common
header (xc_sr_common.h), but the overall complexity is greater than what
is presented here.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 20:14:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 20:14:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jORx5-0005jp-Fb; Tue, 14 Apr 2020 20:14:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=LnnE=56=gmail.com=tcminyard@srs-us1.protection.inumbo.net>)
 id 1jORx4-0005jk-Jw
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 20:14:34 +0000
X-Inumbo-ID: 8df98808-7e8c-11ea-b4f4-bc764e2007e4
Received: from mail-ot1-x341.google.com (unknown [2607:f8b0:4864:20::341])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8df98808-7e8c-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 20:14:33 +0000 (UTC)
Received: by mail-ot1-x341.google.com with SMTP id w12so982430otm.13
 for <xen-devel@lists.xenproject.org>; Tue, 14 Apr 2020 13:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:date:from:to:cc:subject:message-id:reply-to:references
 :mime-version:content-disposition:content-transfer-encoding
 :in-reply-to:user-agent;
 bh=mLX84IN8sSpaz92RYC0ANtzxCMitNAqA4sbOvVucjpo=;
 b=mJCoiUdYoRM7BsTum32ML7Agu0C4P6FMxUYLKjEPjtiYcybq6tW8iSggBcahXP7d4R
 bnGktvqFGsWgmRhQ54tR1Xq4VyiJSPT5VPPCZcTIykTgRLBauHjLUz3348id95hsjBDQ
 HD7zQGNVP8E2qTJd0b1Ulx9/eQT/0/tQdB4pfuLzNc4+OdxNW9A8GMtcM8Q0IF7RHZB1
 eK9FD5t+d7jRB/XFNKVSa0fviAZIeiSdIxfYNUILsQtPptIQbqGQxAGCyellpbPiuUpF
 D4TogO5XxC8oRyWymadXWPm7COV0+404o94OEIhtwcvoe9R5vDFHdgZqbqjQ0iwTIMdy
 vFoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
 :reply-to:references:mime-version:content-disposition
 :content-transfer-encoding:in-reply-to:user-agent;
 bh=mLX84IN8sSpaz92RYC0ANtzxCMitNAqA4sbOvVucjpo=;
 b=PI7kpZAzItiAdy7KyhQjZ+Shgy2xeTBjs3uD8s1Y2hGon3PPwNlrB075/gbpGJZzmJ
 t7c4yi/gTAAc23IFB0yvukOlU65BQV9JZbT1CVpgHw9+zpuv8GHg430kvSlxnedQA1jU
 Nx3hskWwRrNalcI7uTm3JWhMHLRYY7x7QXn+U4aKRUWE3gukEfOLAf6NGT0xaVbPTxKk
 xILOsIG3fQ2F1zD04313XgMqLa7wEsRb4TqVO8WDtXTjfwsTKlkHI4fV9I/6x3X5UAyO
 Kw/RaJFHwhcQKUVckS/V6Ga7Relb6YLEQLFa3PNFU76oEuv7XVslD+Avho3qD5DplstQ
 ePwg==
X-Gm-Message-State: AGi0PuY9kxWng0qRXZjlGEQKGgdIsyZC/GFoW5NjFdzICk7V/s/UaaVG
 47idgIlI5gw8oEAusGH0Zg==
X-Google-Smtp-Source: APiQypIGoB5Eyg4ncuNb2evXXz4/xw4fG+Pdl2xoScwF5fOGf3jkrfXAflVNWOGomQiIqihkGDqf0Q==
X-Received: by 2002:a9d:5512:: with SMTP id l18mr17601512oth.186.1586895272555; 
 Tue, 14 Apr 2020 13:14:32 -0700 (PDT)
Received: from serve.minyard.net (serve.minyard.net. [2001:470:b8f6:1b::1])
 by smtp.gmail.com with ESMTPSA id i7sm5800480otl.12.2020.04.14.13.14.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Apr 2020 13:14:31 -0700 (PDT)
Received: from minyard.net (unknown
 [IPv6:2001:470:b8f6:1b:8b39:c3f3:f502:5c4e])
 by serve.minyard.net (Postfix) with ESMTPSA id 98082181888;
 Tue, 14 Apr 2020 20:14:30 +0000 (UTC)
Date: Tue, 14 Apr 2020 15:14:29 -0500
From: Corey Minyard <minyard@acm.org>
To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
Subject: Re: [PATCH-for-5.1 2/3] various: Remove unnecessary OBJECT() cast
Message-ID: <20200414201429.GI3587@minyard.net>
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-3-f4bug@amsat.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200412210954.32313-3-f4bug@amsat.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: minyard@acm.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, qemu-devel@nongnu.org,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?utf-8?Q?C=C3=A9dric?= Le Goater <clg@kaod.org>, John Snow <jsnow@redhat.com>,
 Richard Henderson <rth@twiddle.net>,
 Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sun, Apr 12, 2020 at 11:09:53PM +0200, Philippe Mathieu-Daudé wrote:
> The OBJECT() macro is defined as:
> 
>   #define OBJECT(obj) ((Object *)(obj))
> 
> Remove unnecessary OBJECT() casts.

For ipmi change:

Acked-by: Corey Minyard <cminyard@mvista.com>

> 
> Patch created mechanically using spatch with this script:
> 
>   @@
>   typedef Object;
>   Object *o;
>   @@
>   -   OBJECT(o)
>   +   o
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/core/bus.c                       | 2 +-
>  hw/ide/ahci-allwinner.c             | 2 +-
>  hw/ipmi/smbus_ipmi.c                | 2 +-
>  hw/microblaze/petalogix_ml605_mmu.c | 8 ++++----
>  hw/s390x/sclp.c                     | 2 +-
>  monitor/misc.c                      | 3 +--
>  qom/object.c                        | 4 ++--
>  7 files changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/hw/core/bus.c b/hw/core/bus.c
> index 3dc0a825f0..4ea5870de8 100644
> --- a/hw/core/bus.c
> +++ b/hw/core/bus.c
> @@ -25,7 +25,7 @@
>  
>  void qbus_set_hotplug_handler(BusState *bus, Object *handler, Error **errp)
>  {
> -    object_property_set_link(OBJECT(bus), OBJECT(handler),
> +    object_property_set_link(OBJECT(bus), handler,
>                               QDEV_HOTPLUG_HANDLER_PROPERTY, errp);
>  }
>  
> diff --git a/hw/ide/ahci-allwinner.c b/hw/ide/ahci-allwinner.c
> index bb8393d2b6..8536b9eb5a 100644
> --- a/hw/ide/ahci-allwinner.c
> +++ b/hw/ide/ahci-allwinner.c
> @@ -90,7 +90,7 @@ static void allwinner_ahci_init(Object *obj)
>      SysbusAHCIState *s = SYSBUS_AHCI(obj);
>      AllwinnerAHCIState *a = ALLWINNER_AHCI(obj);
>  
> -    memory_region_init_io(&a->mmio, OBJECT(obj), &allwinner_ahci_mem_ops, a,
> +    memory_region_init_io(&a->mmio, obj, &allwinner_ahci_mem_ops, a,
>                            "allwinner-ahci", ALLWINNER_AHCI_MMIO_SIZE);
>      memory_region_add_subregion(&s->ahci.mem, ALLWINNER_AHCI_MMIO_OFF,
>                                  &a->mmio);
> diff --git a/hw/ipmi/smbus_ipmi.c b/hw/ipmi/smbus_ipmi.c
> index 2a9470d9df..f1a0148755 100644
> --- a/hw/ipmi/smbus_ipmi.c
> +++ b/hw/ipmi/smbus_ipmi.c
> @@ -329,7 +329,7 @@ static void smbus_ipmi_init(Object *obj)
>  {
>      SMBusIPMIDevice *sid = SMBUS_IPMI(obj);
>  
> -    ipmi_bmc_find_and_link(OBJECT(obj), (Object **) &sid->bmc);
> +    ipmi_bmc_find_and_link(obj, (Object **) &sid->bmc);
>  }
>  
>  static void smbus_ipmi_get_fwinfo(struct IPMIInterface *ii, IPMIFwInfo *info)
> diff --git a/hw/microblaze/petalogix_ml605_mmu.c b/hw/microblaze/petalogix_ml605_mmu.c
> index 0a2640c40b..52dcea9abd 100644
> --- a/hw/microblaze/petalogix_ml605_mmu.c
> +++ b/hw/microblaze/petalogix_ml605_mmu.c
> @@ -150,9 +150,9 @@ petalogix_ml605_init(MachineState *machine)
>      qdev_set_nic_properties(eth0, &nd_table[0]);
>      qdev_prop_set_uint32(eth0, "rxmem", 0x1000);
>      qdev_prop_set_uint32(eth0, "txmem", 0x1000);
> -    object_property_set_link(OBJECT(eth0), OBJECT(ds),
> +    object_property_set_link(OBJECT(eth0), ds,
>                               "axistream-connected", &error_abort);
> -    object_property_set_link(OBJECT(eth0), OBJECT(cs),
> +    object_property_set_link(OBJECT(eth0), cs,
>                               "axistream-control-connected", &error_abort);
>      qdev_init_nofail(eth0);
>      sysbus_mmio_map(SYS_BUS_DEVICE(eth0), 0, AXIENET_BASEADDR);
> @@ -163,9 +163,9 @@ petalogix_ml605_init(MachineState *machine)
>      cs = object_property_get_link(OBJECT(eth0),
>                                    "axistream-control-connected-target", NULL);
>      qdev_prop_set_uint32(dma, "freqhz", 100 * 1000000);
> -    object_property_set_link(OBJECT(dma), OBJECT(ds),
> +    object_property_set_link(OBJECT(dma), ds,
>                               "axistream-connected", &error_abort);
> -    object_property_set_link(OBJECT(dma), OBJECT(cs),
> +    object_property_set_link(OBJECT(dma), cs,
>                               "axistream-control-connected", &error_abort);
>      qdev_init_nofail(dma);
>      sysbus_mmio_map(SYS_BUS_DEVICE(dma), 0, AXIDMA_BASEADDR);
> diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
> index f0c35aa57a..bae9d2350f 100644
> --- a/hw/s390x/sclp.c
> +++ b/hw/s390x/sclp.c
> @@ -288,7 +288,7 @@ void s390_sclp_init(void)
>  
>      object_property_add_child(qdev_get_machine(), TYPE_SCLP, new,
>                                NULL);
> -    object_unref(OBJECT(new));
> +    object_unref(new);
>      qdev_init_nofail(DEVICE(new));
>  }
>  
> diff --git a/monitor/misc.c b/monitor/misc.c
> index 6c45fa490f..57af5fa5a4 100644
> --- a/monitor/misc.c
> +++ b/monitor/misc.c
> @@ -1839,8 +1839,7 @@ void object_add_completion(ReadLineState *rs, int nb_args, const char *str)
>  static int qdev_add_hotpluggable_device(Object *obj, void *opaque)
>  {
>      GSList **list = opaque;
> -    DeviceState *dev = (DeviceState *)object_dynamic_cast(OBJECT(obj),
> -                                                          TYPE_DEVICE);
> +    DeviceState *dev = (DeviceState *)object_dynamic_cast(obj, TYPE_DEVICE);
>  
>      if (dev == NULL) {
>          return 0;
> diff --git a/qom/object.c b/qom/object.c
> index 1812f79224..9893cc5459 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -762,7 +762,7 @@ Object *object_new_with_propv(const char *typename,
>          }
>      }
>  
> -    object_unref(OBJECT(obj));
> +    object_unref(obj);
>      return obj;
>  
>   error:
> @@ -1689,7 +1689,7 @@ void object_property_add_child(Object *obj, const char *name,
>          return;
>      }
>  
> -    type = g_strdup_printf("child<%s>", object_get_typename(OBJECT(child)));
> +    type = g_strdup_printf("child<%s>", object_get_typename(child));
>  
>      op = object_property_add(obj, name, type, object_get_child_property, NULL,
>                               object_finalize_child_property, child, &local_err);
> -- 
> 2.21.1
> 


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 20:23:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 20:23:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOS5h-0006fi-MK; Tue, 14 Apr 2020 20:23:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOS5g-0006fd-TC
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 20:23:28 +0000
X-Inumbo-ID: cc884a9a-7e8d-11ea-b58d-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cc884a9a-7e8d-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 20:23:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586895807;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=dDpooWvCvCdfVU+Csr7I2hSG58ilkPwM/JN7uGWPjoQ=;
 b=d2nCyzE1gfQx7bJjF93JEpbD5sONp/PGP2Ck7mQchoVLyU6NoTuarhnB
 4K3HTBlipwJSrHh6GvoRkXkYmzwgMw+D2/DPot69jSls97X0U3U48zpAY
 fxLjuYiu1MyccNgko/6W4JFs8lHXJ6MWToVx1bO8GMkVkGosmufRRiTT8 g=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: uk328W3r5ZgYEZRkXbA2nHU8HUAqJFrULWd69v7HEoqsChQ86WEflmlLIqbhPivhWBnACvuaCJ
 Nl0JZ6PPJ9Xvmy5w0aVHjFU6n4IZjHd3cCtHjaEweK0871wZji9qaQHLPTfN1wDqHgHvpLueRQ
 56KvVW/ks3Yhr7Ced9d4mUSJGA2aGLLaKwIC210T3mDadDVS5qYXD3snvIGP70NUjtf2lX8vDH
 BDDM8UTOKdowizAbEC6zijamjZicnpuBj5Ue4GNw+2xJY8AquAFt48fmW3RYzFwZnogtXJRLpn
 7X0=
X-SBRS: 2.7
X-MesageID: 15995059
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,384,1580792400"; d="scan'208";a="15995059"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH v3 10/17] tools/libxl: Plumb a restore boolean into
 libxl__domain_build_state
Date: Tue, 14 Apr 2020 21:23:21 +0100
Message-ID: <20200414202321.17580-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200127143444.25538-11-andrew.cooper3@citrix.com>
References: <20200127143444.25538-11-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

To fix CPUID handling, libxl__build_pre() is going to have to distinguish
between a brand new VM vs one which is being migrated-in/resumed.

Transcribe dcs->restore_fd into dbs->restore in initiate_domain_create()
only (specifically avoiding the stubdom state in libxl__spawn_stub_dm()).

While tweaking initiate_domain_create(), make a new dbs alias and simplify
later code, and drop the local restore_fd alias as the new dbs->restore is
more intuitive in context.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Ian Jackson <Ian.Jackson@citrix.com>
CC: Wei Liu <wl@xen.org>
CC: Anthony PERARD <anthony.perard@citrix.com>

v2:
 * New.  This is c/s aacc1430064 "tools/libxl: Plumb domain_create_state down
   into libxl__build_pre()" take-2, without any collateral damage to stubdoms.
v3:
 * Extend libxl__domain_build_state instead of adding a new parameter to
   libxl__build_pre().
---
 tools/libxl/libxl_create.c   | 14 +++++++-------
 tools/libxl/libxl_internal.h |  4 ++++
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e7cb2dbc2b..5a043df15f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1181,18 +1181,18 @@ static void initiate_domain_create(libxl__egc *egc,
 
     /* convenience aliases */
     libxl_domain_config *const d_config = dcs->guest_config;
-    const int restore_fd = dcs->restore_fd;
+    libxl__domain_build_state *dbs = &dcs->build_state;
 
     libxl__xswait_init(&dcs->console_xswait);
 
     domid = dcs->domid;
-    libxl__domain_build_state_init(&dcs->build_state);
+    libxl__domain_build_state_init(dbs);
+    dbs->restore = dcs->restore_fd >= 0;
 
     ret = libxl__domain_config_setdefault(gc,d_config,domid);
     if (ret) goto error_out;
 
-    ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
-                             dcs->soft_reset);
+    ret = libxl__domain_make(gc, d_config, dbs, &domid, dcs->soft_reset);
     if (ret) {
         LOGD(ERROR, domid, "cannot make domain: %d", ret);
         dcs->guest_domid = domid;
@@ -1236,7 +1236,7 @@ static void initiate_domain_create(libxl__egc *egc,
     if (ret)
         goto error_out;
 
-    if (restore_fd >= 0 || dcs->soft_reset) {
+    if (dbs->restore || dcs->soft_reset) {
         LOGD(DEBUG, domid, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
     } else  {
@@ -1247,8 +1247,8 @@ static void initiate_domain_create(libxl__egc *egc,
         dcs->bl.disk = bootdisk;
         dcs->bl.domid = dcs->guest_domid;
 
-        dcs->bl.kernel = &dcs->build_state.pv_kernel;
-        dcs->bl.ramdisk = &dcs->build_state.pv_ramdisk;
+        dcs->bl.kernel = &dbs->pv_kernel;
+        dcs->bl.ramdisk = &dbs->pv_ramdisk;
 
         libxl__bootloader_run(egc, &dcs->bl);
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5f39e44cb9..e5effd2ad1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1397,6 +1397,10 @@ typedef struct {
 
     /* ARM only to deal with broken firmware */
     uint32_t clock_frequency;
+
+    /* Whether this domain is being migrated/restored, or booting fresh.  Only
+     * applicable to the primary domain, not support domains (e.g. stub QEMU). */
+    bool restore;
 } libxl__domain_build_state;
 
 _hidden void libxl__domain_build_state_init(libxl__domain_build_state *s);
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 20:24:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 20:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOS76-0006lh-4r; Tue, 14 Apr 2020 20:24:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOS75-0006lb-3D
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 20:24:55 +0000
X-Inumbo-ID: 00060c86-7e8e-11ea-b58d-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 00060c86-7e8e-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 20:24:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586895894;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=y3TBEIewzoLbvOHXkrqiBad2k4udvTD2ufd/z90hUQA=;
 b=MSFySptPQ1xHTsCCJE+AyvVStnDnCoznsf4Xt9cCcDATAoQ3DzLL0xJH
 PkSWd+Ck5yQ0xjWlHj+fxSMeg0/VzmoPjWANgAbGCkbxh6mrZMbwer98J
 5M+MZaqfaeEchlG7vdzOcim7falcdk9Y8osasRrHacw6fsA3SQvrFI6+B 0=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: HpGCMY45IRaSrSS6demanULjBpYhw87sCqDBlLOLz+wlKgIOW+81RvBoBOJFU83IkAQGJHTZdn
 nQ0fs+rEaRGXP1Ql6dfTg0WaJGabc1SzT+L6m4oIqCGWSFxxOKWZbagJTLu72afCUWzQrhYOkj
 PEAhKyKUxYBw7/bFEhVzMwNqMB4BWsqUin86hYP8Y2wnP/lHfwSqeeyDHDlXX25mP3oOmNGieW
 tv+bfhnbqJzB8xNe28HDyZv2RhxE9m+jqqdjqEc0RUbKXnpRO+lrnOCkF8qFRzZJfcliX41fKF
 3Ao=
X-SBRS: 2.7
X-MesageID: 15995110
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,384,1580792400"; d="scan'208";a="15995110"
Subject: Re: Ping [PATCH v2 14/17] libxc/save: Write X86_{CPUID,MSR}_DATA
 records
To: Xen-devel <xen-devel@lists.xenproject.org>
References: <20200127143444.25538-1-andrew.cooper3@citrix.com>
 <20200127143444.25538-15-andrew.cooper3@citrix.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <5c535bf4-d1ca-488a-7b2b-dd1c023d0d83@citrix.com>
Date: Tue, 14 Apr 2020 21:24:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200127143444.25538-15-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27/01/2020 14:34, Andrew Cooper wrote:
> With all other plumbing in place, obtain the CPU Policy from Xen and
> write it into the migration stream.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Ian Jackson <Ian.Jackson@citrix.com>
> CC: Wei Liu <wl@xen.org>
> ---
>  tools/libxc/xc_sr_common_x86.c   | 50 ++++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_sr_common_x86.h   |  6 +++++
>  tools/libxc/xc_sr_save_x86_hvm.c |  2 +-
>  tools/libxc/xc_sr_save_x86_pv.c  | 12 +++++++++-
>  4 files changed, 68 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxc/xc_sr_common_x86.c b/tools/libxc/xc_sr_common_x86.c
> index 8980299e9a..6267655dab 100644
> --- a/tools/libxc/xc_sr_common_x86.c
> +++ b/tools/libxc/xc_sr_common_x86.c
> @@ -42,6 +42,56 @@ int handle_x86_tsc_info(struct xc_sr_context *ctx, struct xc_sr_record *rec)
>      return 0;
>  }
>  
> +int write_x86_cpu_policy_records(struct xc_sr_context *ctx)
> +{
> +    xc_interface *xch = ctx->xch;
> +    struct xc_sr_record cpuid = { .type = REC_TYPE_X86_CPUID_POLICY, };
> +    struct xc_sr_record msrs  = { .type = REC_TYPE_X86_MSR_POLICY, };
> +    uint32_t nr_leaves = 0, nr_msrs = 0;
> +    int rc;
> +
> +    if ( xc_get_cpu_policy_size(xch, &nr_leaves, &nr_msrs) < 0 )
> +    {
> +        PERROR("Unable to get CPU Policy size");
> +        return -1;
> +    }
> +
> +    cpuid.data = malloc(nr_leaves * sizeof(xen_cpuid_leaf_t));
> +    msrs.data  = malloc(nr_msrs   * sizeof(xen_msr_entry_t));
> +    if ( !cpuid.data || !msrs.data )
> +    {
> +        ERROR("Cannot allocate memory for CPU Policy");
> +        rc = -1;
> +        goto out;
> +    }
> +
> +    if ( xc_get_domain_cpu_policy(xch, ctx->domid, &nr_leaves, cpuid.data,
> +                                  &nr_msrs, msrs.data) )
> +    {
> +        PERROR("Unable to get d%d CPU Policy", ctx->domid);
> +        rc = -1;
> +        goto out;
> +    }
> +
> +    cpuid.length = nr_leaves * sizeof(xen_cpuid_leaf_t);
> +    if ( cpuid.length )
> +    {
> +        rc = write_record(ctx, &cpuid);
> +        if ( rc )
> +            goto out;
> +    }
> +
> +    msrs.length = nr_msrs * sizeof(xen_msr_entry_t);
> +    if ( msrs.length )
> +        rc = write_record(ctx, &msrs);
> +
> + out:
> +    free(cpuid.data);
> +    free(msrs.data);
> +
> +    return rc;
> +}
> +
>  int handle_x86_cpuid_policy(struct xc_sr_context *ctx, struct xc_sr_record *rec)
>  {
>      xc_interface *xch = ctx->xch;
> diff --git a/tools/libxc/xc_sr_common_x86.h b/tools/libxc/xc_sr_common_x86.h
> index c458c1aa37..d1050981dd 100644
> --- a/tools/libxc/xc_sr_common_x86.h
> +++ b/tools/libxc/xc_sr_common_x86.h
> @@ -15,6 +15,12 @@ int write_x86_tsc_info(struct xc_sr_context *ctx);
>  int handle_x86_tsc_info(struct xc_sr_context *ctx, struct xc_sr_record *rec);
>  
>  /*
> + * Obtains a domains CPU Policy from Xen, and writes X86_{CPUID,MSR}_POLICY
> + * records into the stream.
> + */
> +int write_x86_cpu_policy_records(struct xc_sr_context *ctx);
> +
> +/*
>   * Parses an X86_CPUID_POLICY record and stashes the content for application
>   * when a STATIC_DATA_END record is encountered.
>   */
> diff --git a/tools/libxc/xc_sr_save_x86_hvm.c b/tools/libxc/xc_sr_save_x86_hvm.c
> index 93bcc1c273..acf9264dec 100644
> --- a/tools/libxc/xc_sr_save_x86_hvm.c
> +++ b/tools/libxc/xc_sr_save_x86_hvm.c
> @@ -172,7 +172,7 @@ static int x86_hvm_setup(struct xc_sr_context *ctx)
>  
>  static int x86_hvm_static_data(struct xc_sr_context *ctx)
>  {
> -    return 0;
> +    return write_x86_cpu_policy_records(ctx);
>  }
>  
>  static int x86_hvm_start_of_stream(struct xc_sr_context *ctx)
> diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
> index 46019d962d..c7e246ef4f 100644
> --- a/tools/libxc/xc_sr_save_x86_pv.c
> +++ b/tools/libxc/xc_sr_save_x86_pv.c
> @@ -1054,7 +1054,17 @@ static int x86_pv_setup(struct xc_sr_context *ctx)
>  
>  static int x86_pv_static_data(struct xc_sr_context *ctx)
>  {
> -    return write_x86_pv_info(ctx);
> +    int rc;
> +
> +    rc = write_x86_pv_info(ctx);
> +    if ( rc )
> +        return rc;
> +
> +    rc = write_x86_cpu_policy_records(ctx);
> +    if ( rc )
> +        return rc;
> +
> +    return 0;
>  }
>  
>  static int x86_pv_start_of_stream(struct xc_sr_context *ctx)



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 20:25:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 20:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOS7K-0006nS-Hi; Tue, 14 Apr 2020 20:25:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JNOL=56=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOS7J-0006nF-DY
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 20:25:09 +0000
X-Inumbo-ID: 08099d08-7e8e-11ea-89a5-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 08099d08-7e8e-11ea-89a5-12813bfff9fa;
 Tue, 14 Apr 2020 20:25:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586895908;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=Xxsifn00S3cqfDFWDaPTDSnQvEMZeFSLvLjuf2hAnwU=;
 b=U9SntYWdthAA/3UyLccHu8EaRtshqHLvki/N3mSx461eQ2MgIHBYxpnp
 ggaRStGJKNAlACAfxCau8i5S/wQHuWgykZQ0iC4LLOtVBIq3vtXB24u3k
 hJodrFd2fGl14AL4JDvY2oRma5Q2AL9a0k4Y26lh44ewF/afQcbyJxemw 0=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 5mAoYyuaIX3cmSmAMrsjyqeNkqyEuZUOWpo7unN0Pg3D+npzFV+kecgI8nfC3qwDWm+nytAsZm
 sYW+QCKdnC0KhEJQI9XRphX3FB1Na62DP231kG9yH018f53oG0shUCS9wpgP7t4pjzfChYV4Oj
 vVx4JaB5qz72Ts9A06pIY+evoPLP52siOf/MFwC+dmlKKAUjW4koIPw2+RCYfKejnyK0r4pBCu
 xkek1BKaRKMdKAqREFGd38cr5BFxFZHvwtYC7J2Mw9a50eSjF87mfhWfeS4+teBmICyiBurypr
 8WE=
X-SBRS: 2.7
X-MesageID: 15914633
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,384,1580792400"; d="scan'208";a="15914633"
Subject: Re: Ping [PATCH v2 17/17] docs/xl.cfg: Rewrite cpuid= section
To: Xen-devel <xen-devel@lists.xenproject.org>
References: <20200127143444.25538-1-andrew.cooper3@citrix.com>
 <20200127143444.25538-18-andrew.cooper3@citrix.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <a4930733-99fa-072e-dd01-2e5b3bdcacec@citrix.com>
Date: Tue, 14 Apr 2020 21:25:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200127143444.25538-18-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <Ian.Jackson@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27/01/2020 14:34, Andrew Cooper wrote:
> This is partly to adjust the description of 'k' and 's' seeing as they have
> changed, but mostly restructuring the information for clarity.
>
> In particular, use indentation to clearly separate the areas discussing libxl
> format from xend format.  In addition, extend the xend format section to
> discuss subleaf notation.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Ian Jackson <Ian.Jackson@citrix.com>
> CC: Wei Liu <wl@xen.org>
> CC: Anthony PERARD <anthony.perard@citrix.com>
>
> v2:
>  * New
> ---
>  docs/man/xl.cfg.5.pod.in | 74 ++++++++++++++++++++++++++++++++++--------------
>  1 file changed, 53 insertions(+), 21 deletions(-)
>
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 245d3f9472..1da68c4a07 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -1964,26 +1964,42 @@ This option is disabled by default.
>  Configure the value returned when a guest executes the CPUID instruction.
>  Two versions of config syntax are recognized: libxl and xend.
>  
> -The libxl syntax is a comma separated list of key=value pairs, preceded by the
> -word "host". A few keys take a numerical value, all others take a single
> -character which describes what to do with the feature bit.
> -
> -Possible values for a single feature bit:
> +Both formats use a common notation for specifying a single feature bit.
> +Possible values are:
>    '1' -> force the corresponding bit to 1
>    '0' -> force to 0
>    'x' -> Get a safe value (pass through and mask with the default policy)
> -  'k' -> pass through the host bit value
> -  's' -> as 'k' but preserve across save/restore and migration (not implemented)
> +  'k' -> pass through the host bit value (at boot only - value preserved on migrate)
> +  's' -> legacy alias for 'k'
>  
> -Note: when specifying B<cpuid> for hypervisor leaves (0x4000xxxx major group)
> -only the lowest 8 bits of leaf's 0x4000xx00 EAX register are processed, the
> -rest are ignored (these 8 bits signify maximum number of hypervisor leaves).
> +B<Libxl format>:
> +
> +=over 4
> +
> +The libxl format is a single string, starting with the word "host", and
> +followed by a comma separated list of key=value pairs.  A few keys take a
> +numerical value, all others take a single character which describes what to do
> +with the feature bit.  e.g.:
> +
> +=over 4
> +
> +cpuid="host,tm=0,sse3=0"
> +
> +=back
>  
>  List of keys taking a value:
> +
> +=over 4
> +
>  apicidsize brandid clflush family localapicid maxleaf maxhvleaf model nc
>  proccount procpkg stepping
>  
> +=back
> +
>  List of keys taking a character:
> +
> +=over 4
> +
>  3dnow 3dnowext 3dnowprefetch abm acpi adx aes altmovcr8 apic arat avx avx2
>  avx512-4fmaps avx512-4vnniw avx512bw avx512cd avx512dq avx512er avx512f
>  avx512ifma avx512pf avx512vbmi avx512vl bmi1 bmi2 clflushopt clfsh clwb cmov
> @@ -1997,21 +2013,37 @@ ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate
>  svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc tsc-deadline tsc_adjust
>  umip vme vmx wdt x2apic xop xsave xtpr
>  
> +=back
> +
> +=back
> +
> +B<Xend format>:
>  
> -The xend syntax is a list of values in the form of
> -'leafnum:register=bitstring,register=bitstring'
> -  "leafnum" is the requested function,
> -  "register" is the response register to modify
> -  "bitstring" represents all bits in the register, its length must be 32 chars.
> -  Each successive character represent a lesser-significant bit, possible values
> -  are listed above in the libxl section.
> +=over 4
>  
> -Example to hide two features from the guest: 'tm', which is bit #29 in EDX, and
> -'pni' (SSE3), which is bit #0 in ECX:
> +Xend format consists of an array of one or more strings of the form
> +"leaf:reg=bitstring,...".  e.g. (matching the libxl example above):
>  
> -xend: [ "1:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0,edx=xx0xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ]
> +=over 4
>  
> -libxl: "host,tm=0,sse3=0"
> +cpuid=["1:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0,edx=xx0xxxxxxxxxxxxxxxxxxxxxxxxxxxxx", ...]
> +
> +=back
> +
> +"leaf" is an integer, either decimal or hex with a "0x" prefix.  e.g. to
> +specify something in the AMD feature leaves, use "0x80000001:ecx=...".
> +
> +Some leaves have subleaves which can be specified as "leaf,subleaf".  e.g. for
> +the Intel structured feature leaf, use "7,0:ebx=..."
> +
> +The bitstring represents all bits in the register, its length must be 32
> +chars.  Each successive character represent a lesser-significant bit.
> +
> +=back
> +
> +Note: when specifying B<cpuid> for hypervisor leaves (0x4000xxxx major group)
> +only the lowest 8 bits of leaf's 0x4000xx00 EAX register are processed, the
> +rest are ignored (these 8 bits signify maximum number of hypervisor leaves).
>  
>  More info about the CPUID instruction can be found in the processor manuals,
>  and on Wikipedia: L<https://en.wikipedia.org/wiki/CPUID>



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 20:41:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 20:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOSNN-00009D-5Q; Tue, 14 Apr 2020 20:41:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qlbo=56=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOSNL-000097-RN
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 20:41:43 +0000
X-Inumbo-ID: 55edc36c-7e90-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 55edc36c-7e90-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 20:41:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=I8971qnuInYWMV/jeQBGdSrM8G5TQnE8t5M8hSc+CwY=; b=FGzLtBTyMVwct7ro85S6k9r4E
 ULo1CLimrknrm73YXr8RB5soLDyffzu9RS40mnvsS+PhsaLtJKwZdYrXrcrtVWXMB58hqJRFyb0K0
 wzKAiNV787JN60tfvsVotpiiZeO+N+RUPxSr76l7BZD3GFP6aPUQZ5GzT0yLWX5eIBD70=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOSNE-00035Z-R4; Tue, 14 Apr 2020 20:41:36 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOSNE-0004wG-IQ; Tue, 14 Apr 2020 20:41:36 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOSNE-0003di-Eg; Tue, 14 Apr 2020 20:41:36 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149646-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.12-testing test] 149646: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=3536f8dc39cc7311715340b87a04a89fac468406
X-Osstest-Versions-That: xen=e8c8071f4ac2cce6f2a0ef75ea53720a7744e875
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 14 Apr 2020 20:41:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow2    17 guest-localmigrate/x10       fail  like 149607
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 xen                  3536f8dc39cc7311715340b87a04a89fac468406
baseline version:
 xen                  e8c8071f4ac2cce6f2a0ef75ea53720a7744e875

Last test of basis   149607  2020-04-10 18:18:00 Z    4 days
Testing same since   149646  2020-04-14 13:05:53 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   e8c8071f4a..3536f8dc39  3536f8dc39cc7311715340b87a04a89fac468406 -> stable-4.12


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 20:52:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 20:52:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOSXY-0001CU-NX; Tue, 14 Apr 2020 20:52:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=jlhC=56=dornerworks.com=jeff.kubascik@srs-us1.protection.inumbo.net>)
 id 1jOSXX-0001CP-PM
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 20:52:15 +0000
X-Inumbo-ID: d1ff7f8a-7e91-11ea-b58d-bc764e2007e4
Received: from webmail.dornerworks.com (unknown [12.207.209.150])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d1ff7f8a-7e91-11ea-b58d-bc764e2007e4;
 Tue, 14 Apr 2020 20:52:14 +0000 (UTC)
Subject: Re: [PATCH] sched/core: Fix bug when moving a domain between cpupools
From: Jeff Kubascik <jeff.kubascik@dornerworks.com>
To: <xen-devel@lists.xenproject.org>, George Dunlap
 <george.dunlap@citrix.com>, Dario Faggioli <dfaggioli@suse.com>
References: <20200327193023.506-1-jeff.kubascik@dornerworks.com>
Message-ID: <40389937-6f8e-dff3-8af6-30a848fcb163@dornerworks.com>
Date: Tue, 14 Apr 2020 16:52:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200327193023.506-1-jeff.kubascik@dornerworks.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.27.0.12]
X-ClientProxiedBy: Mcbain.dw.local (172.27.1.45) To Mcbain.dw.local
 (172.27.1.45)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stewart Hildebrand <Stewart.Hildebrand@dornerworks.com>,
 Nathan Studer <Nathan.Studer@dornerworks.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hello,

I wanted to follow up on this patch, as I have not seen any responses to it.

In my work on the ARINC653 scheduler, I have observed this bug write to memory
past the end of a private UNIT structure (and in my case, stomping on a TLSF
allocator header) when migrating a domain from an ARINC cpupool to a credit
cpupool. This occurs because (a) the private UNIT structure is smaller for the
ARINC cpupool and (b) the credit scheduler method csched_aff_cntl does some bit
setting/ clearing while the private UNIT pointer still points incorrectly to the
ARINC cpupool one.

On 3/27/2020 3:30 PM, Jeff Kubascik wrote:
> For each UNIT, sched_set_affinity is called before unit->priv is updated
> to the new cpupool private UNIT data structure. The issue is
> sched_set_affinity will call the adjust_affinity method of the cpupool.
> If defined, the new cpupool may use unit->priv (e.g. credit), which at
> this point still references the old cpupool private UNIT data structure.
> 
> This change fixes the bug by moving the switch of unit->priv earler in
> the function.
> 
> Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
> ---
> Hello,
> 
> I've been working on updating the arinc653 scheduler to support
> multicore for a few months now. In the process of testing, I came across
> this obscure bug in the core scheduler code that took me a few weeks to
> track down. This bug resulted in the credit scheduler writing past the
> end of the arinc653 private UNIT data structure into the TLSF allocator
> bhdr structure of the adjacent region. This required some deep diving
> into the TLSF allocator code to trace the bug back to this point.
> 
> Sincerely,
> Jeff Kubascik
> ---
>  xen/common/sched/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> index 7e8e7d2c39..ea572a345a 100644
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -686,6 +686,7 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
>          unsigned int unit_p = new_p;
>  
>          unitdata = unit->priv;
> +        unit->priv = unit_priv[unit_idx];
>  
>          for_each_sched_unit_vcpu ( unit, v )
>          {
> @@ -707,7 +708,6 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
>           */
>          spin_unlock_irq(lock);
>  
> -        unit->priv = unit_priv[unit_idx];
>          if ( !d->is_dying )
>              sched_move_irqs(unit);
>  
> 

Sincerely,
Jeff Kubascik


From xen-devel-bounces@lists.xenproject.org Tue Apr 14 21:40:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 21:40:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOTI0-0005Vg-Jo; Tue, 14 Apr 2020 21:40:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Ja/k=56=linaro.org=richard.henderson@srs-us1.protection.inumbo.net>)
 id 1jOTHz-0005Vb-4A
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 21:40:15 +0000
X-Inumbo-ID: 86112d38-7e98-11ea-b4f4-bc764e2007e4
Received: from mail-pj1-x102f.google.com (unknown [2607:f8b0:4864:20::102f])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 86112d38-7e98-11ea-b4f4-bc764e2007e4;
 Tue, 14 Apr 2020 21:40:14 +0000 (UTC)
Received: by mail-pj1-x102f.google.com with SMTP id ng8so5882685pjb.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Apr 2020 14:40:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;
 h=subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=+YdJ1eItjRB7ItTRPS1yzNOPMwATBGKtFqeGB8AgldY=;
 b=h+Eo7SnvIra0gg12SjTsJNQK7hUY+z1MG5p0nKh/xlrWsdcbkSQRExUNzO/QuF5LBq
 nK+gerPPGcDw1dky7bWHAqeQp8QM3oxsP2k5TFzYVWzZkjJvZT9B0G623T5XtGX6sISR
 AsOK2k9fq0tA6tc8Xrq91NmtabQMcdJr3WLFXjdE/qGCKZCOnri3+Ys0GnKZt3ZYg1g5
 KvE9GdB3QSSzSziY7/SdTZZfBh1MYelqsMXUNXL7f1BUMIfWIGiSP46OQMHEcZENFaZt
 OK716l6AJ5iNivPu5/aXilPD2ztEdkBYE4E+00VClFsmzjbpDFgWdZnftHI0I4QwhcQt
 l1MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:to:cc:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=+YdJ1eItjRB7ItTRPS1yzNOPMwATBGKtFqeGB8AgldY=;
 b=oN8lxHwZw+9FKuWeAFmIP2/LH+8522z9WUJzpAABjaoUpilIBLRTVW1xUO1dgedku2
 vLD9GM9MFuI+8PaLnZiP3IUE3qDA/g12RgMugU4hAhxgTyX0N7IeIn++4ByL7+t7ETdx
 /4XLzUsKT0X8/pQh0Lv6u0vdJDdRDdTfSaLvmcZCYB5mKfnmiuWhSk7uQkuugpaZN3/A
 1RVK9qTQ/2AQqvmJqVcKdrF8B0kXWh1kg8Mpa6Svke23gkjkWIU7g8nvXNHPQE0UJruq
 rcRYoj2wzsfrFGb+pZHpDP7RwonsxA338x2cC1jcXUaCuWp0s+KnbSNKSfqvHpecrJl4
 nuSw==
X-Gm-Message-State: AGi0PuZ0p7K5/HnlSt9b5LuIZo2mqsQC6CWx6aBTcS0ZNR1k0aYEGR53
 Rke0fDJyAVyIzT1gFqdKnTf13A==
X-Google-Smtp-Source: APiQypJH6XQewev6YQtlp+dBP1DIMMkffzfDkFrLt+FaPiM0Gp4zPaFkO3wCEw34bPMGeI/wlc0ovQ==
X-Received: by 2002:a17:902:8d8d:: with SMTP id
 v13mr1951273plo.260.1586900413217; 
 Tue, 14 Apr 2020 14:40:13 -0700 (PDT)
Received: from [192.168.1.11] (174-21-149-226.tukw.qwest.net. [174.21.149.226])
 by smtp.gmail.com with ESMTPSA id a136sm9012385pfa.99.2020.04.14.14.40.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Apr 2020 14:40:12 -0700 (PDT)
Subject: Re: [PATCH-for-5.1 0/3] various: Remove unnecessary casts
To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <f4bug@amsat.org>,
 qemu-devel@nongnu.org
References: <20200412210954.32313-1-f4bug@amsat.org>
From: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <a1478503-cab3-df6a-1aae-50b262e9121e@linaro.org>
Date: Tue, 14 Apr 2020 14:40:10 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200412210954.32313-1-f4bug@amsat.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
 Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, Richard Henderson <rth@twiddle.net>,
 =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?UTF-8?Q?C=c3=a9dric_Le_Goater?= <clg@kaod.org>, John Snow <jsnow@redhat.com>,
 David Gibson <david@gibson.dropbear.id.au>,
 =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/12/20 2:09 PM, Philippe Mathieu-Daudé wrote:
> Remove unnecessary casts using coccinelle scripts.
> 
> The CPU()/OBJECT() patches don't introduce logical change,
> The DEVICE() one removes various OBJECT_CHECK() calls.
> 
> Philippe Mathieu-Daudé (3):
>   target: Remove unnecessary CPU() cast
>   various: Remove unnecessary OBJECT() cast
>   hw: Remove unnecessary DEVICE() cast

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~



From xen-devel-bounces@lists.xenproject.org Tue Apr 14 23:14:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Apr 2020 23:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOUkg-0004tr-Vu; Tue, 14 Apr 2020 23:13:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=qlbo=56=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOUkf-0004tm-Si
 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 23:13:57 +0000
X-Inumbo-ID: 99fe74f6-7ea5-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 99fe74f6-7ea5-11ea-9e09-bc764e2007e4;
 Tue, 14 Apr 2020 23:13:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=znIXKZ42je8ipRXc/nYOmZrqP2sXJHDhBOdraVTHjU4=; b=1qJzANt3c4p5TsGD+YspBZRic
 iWwjWei7pk6BoBRIuMIvw9MAWlkA6AMqWTWDkXMY271iKDZYjIGiOBjuyZor3iI9trZRsJHoW1kA9
 eNinNuY1suWbqJDaqQvB7Bjeb+XoTu0kcEybl+pkc6y3FqT8w+2/B2+adyJISZcwYhwaU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOUkY-0005y0-EE; Tue, 14 Apr 2020 23:13:50 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOUkY-0007s1-2Y; Tue, 14 Apr 2020 23:13:50 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOUkY-0007Rx-1i; Tue, 14 Apr 2020 23:13:50 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149647-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.13-testing test] 149647: regressions - FAIL
X-Osstest-Failures: xen-4.13-testing:test-amd64-i386-libvirt:guest-start/debian.repeat:fail:regression
 xen-4.13-testing:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=b66ce5058ec9ce84418cedd39b2bf07b7c5a1f65
X-Osstest-Versions-That: xen=736da59cbe2752502ad863b6e71eb83352e22276
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 14 Apr 2020 23:13:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt     18 guest-start/debian.repeat fail REGR. vs. 149604

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149604
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 12 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-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass

version targeted for testing:
 xen                  b66ce5058ec9ce84418cedd39b2bf07b7c5a1f65
baseline version:
 xen                  736da59cbe2752502ad863b6e71eb83352e22276

Last test of basis   149604  2020-04-10 16:36:52 Z    4 days
Testing same since   149647  2020-04-14 13:06:03 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit b66ce5058ec9ce84418cedd39b2bf07b7c5a1f65
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 14 14:53:03 2020 +0200

    gnttab: fix GNTTABOP_copy continuation handling
    
    The XSA-226 fix was flawed - the backwards transformation on rc was done
    too early, causing a continuation to not get invoked when the need for
    preemption was determined at the very first iteration of the request.
    This in particular means that all of the status fields of the individual
    operations would be left untouched, i.e. set to whatever the caller may
    or may not have initialized them to.
    
    This is part of XSA-318.
    
    Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Tested-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    master commit: d6f22d5d9e8d6848ec229083ac9fb044f0adea93
    master date: 2020-04-14 14:42:32 +0200

commit d91d4fe88146bb4cf8e66819b6c1b762ce0ac6fc
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Tue Apr 14 14:51:45 2020 +0200

    xen/gnttab: Fix error path in map_grant_ref()
    
    Part of XSA-295 (c/s 863e74eb2cffb) inadvertently re-positioned the brackets,
    changing the logic.  If the _set_status() call fails, the grant_map hypercall
    would fail with a status of 1 (rc != GNTST_okay) instead of the expected
    negative GNTST_* error.
    
    This error path can be taken due to bad guest state, and causes net/blk-back
    in Linux to crash.
    
    This is XSA-316.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>
    master commit: da0c66c8f48042a0186799014af69db0303b1da5
    master date: 2020-04-14 14:41:02 +0200

commit b6a2c42303cb70c87de49b4a70e28f7495432f07
Author: Julien Grall <jgrall@amazon.com>
Date:   Tue Apr 14 14:50:16 2020 +0200

    xen/rwlock: Add missing memory barrier in the unlock path of rwlock
    
    The rwlock unlock paths are using atomic_sub() to release the lock.
    However the implementation of atomic_sub() rightfully doesn't contain a
    memory barrier. On Arm, this means a processor is allowed to re-order
    the memory access with the preceeding access.
    
    In other words, the unlock may be seen by another processor before all
    the memory accesses within the "critical" section.
    
    The rwlock paths already contains barrier indirectly, but they are not
    very useful without the counterpart in the unlock paths.
    
    The memory barriers are not necessary on x86 because loads/stores are
    not re-ordered with lock instructions.
    
    So add arch_lock_release_barrier() in the unlock paths that will only
    add memory barrier on Arm.
    
    Take the opportunity to document each lock paths explaining why a
    barrier is not necessary.
    
    This is XSA-314.
    
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    master commit: 6890a04072e664c25447a297fe663b45ecfd6398
    master date: 2020-04-14 14:37:11 +0200

commit ef922bda43f645749e41bd2730f6206f291be289
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 14 14:49:21 2020 +0200

    xenoprof: limit consumption of shared buffer data
    
    Since a shared buffer can be written to by the guest, we may only read
    the head and tail pointers from there (all other fields should only ever
    be written to). Furthermore, for any particular operation the two values
    must be read exactly once, with both checks and consumption happening
    with the thus read values. (The backtrace related xenoprof_buf_space()
    use in xenoprof_log_event() is an exception: The values used there get
    re-checked by every subsequent xenoprof_add_sample().)
    
    Since that code needed touching, also fix the double increment of the
    lost samples count in case the backtrace related xenoprof_add_sample()
    invocation in xenoprof_log_event() fails.
    
    Where code is being touched anyway, add const as appropriate, but take
    the opportunity to entirely drop the now unused domain parameter of
    xenoprof_buf_space().
    
    This is part of XSA-313.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: George Dunlap <george.dunlap@citrix.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    master commit: 50ef9a3cb26e2f9383f6fdfbed361d8f174bae9f
    master date: 2020-04-14 14:33:19 +0200

commit 65b16f3d217044380a80f15334ccf83b3eae6bf9
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 14 14:48:26 2020 +0200

    xenoprof: clear buffer intended to be shared with guests
    
    alloc_xenheap_pages() making use of MEMF_no_scrub is fine for Xen
    internally used allocations, but buffers allocated to be shared with
    (unpriviliged) guests need to be zapped of their prior content.
    
    This is part of XSA-313.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    master commit: 0763a7ebfcdad66cf9e5475a1301eefb29bae9ed
    master date: 2020-04-14 14:32:33 +0200
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:02:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWRX-00019B-S6; Wed, 15 Apr 2020 01:02:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWRW-000196-Rl
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:02:18 +0000
X-Inumbo-ID: c087bf1a-7eb4-11ea-b58d-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c087bf1a-7eb4-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 01:02:18 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 1DCAD2072D;
 Wed, 15 Apr 2020 01:02:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912537;
 bh=ZdE3Xo7+81xPuHaeUJizVXRE+i9VJW2i2pT0cGASjhE=;
 h=Date:From:To:cc:Subject:From;
 b=tlt0r1zGAOh0hyzkI9DICiMFiAP7AjQQ6YAwtd/yokfCYm47mJ3cB+QZ4SjwIhgym
 NxN7TWClBKCikxMaFzvcjvnGEvgW59txqu7F6pZlezEExwvw2tdTkRyZn7NX6X91V8
 MRUQ4J/s5quYD+aVpP0KuFeTjVa4QSmlXDqeoAFA=
Date: Tue, 14 Apr 2020 18:02:09 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/12] direct-map DomUs
Message-ID: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Artem_Mygaiev@epam.com, peng.fan@nxp.com, sstabellini@kernel.org,
 julien@xen.org, andrew.cooper3@citrix.com, George.Dunlap@citrix.com,
 Bertrand.Marquis@arm.com, jbeulich@suse.com, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi all,

This series adds support for 1:1 mapping (guest physical == physical)
the memory of dom0less domUs. The memory ranges assigned to a domU can be
explicitly chosen by the user at boot time.

This is desirable in cases where an IOMMU is not present in the system,
or it cannot be used. For instance, it might not be usable because it
doesn't cover a specific device, or because it doesn't have enough
bandwidth, or because it adds too much latency. In these cases, the user
should use a MPU to protect the memory in the system (e.g. the Xilinx
XMPU), configuring it with the chosen address ranges.

Cheers,

Stefano



The following changes since commit 7372466b21c3b6c96bb7a52754e432bac883a1e3:

  x86/mem_sharing: Fix build with !CONFIG_XSM (2020-04-10 15:20:10 +0100)

are available in the Git repository at:

  http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git direct-map-1

for you to fetch changes up to 43503720ab6851a28a66fdd067f592d5354ae83a:

  xen/arm: call iomem_permit_access for passthrough devices (2020-04-14 17:42:21 -0700)

----------------------------------------------------------------
Stefano Stabellini (12):
      xen: introduce xen_dom_flags
      xen/arm: introduce arch_xen_dom_flags and direct_map
      xen/arm: introduce 1:1 mapping for domUs
      xen: split alloc_heap_pages in two halves for reusability
      xen: introduce reserve_heap_pages
      xen/arm: reserve 1:1 memory for direct_map domUs
      xen/arm: new vgic: rename vgic_cpu/dist_base to c/dbase
      xen/arm: if is_domain_direct_mapped use native addresses for GICv2
      xen/arm: if is_domain_direct_mapped use native addresses for GICv3
      xen/arm: if is_domain_direct_mapped use native UART address for vPL011
      xen/arm: if xen_force don't try to setup the IOMMU
      xen/arm: call iomem_permit_access for passthrough devices

 docs/misc/arm/device-tree/booting.txt |  13 +++
 docs/misc/arm/passthrough-noiommu.txt |  35 ++++++++
 xen/arch/arm/domain.c                 |   4 +-
 xen/arch/arm/domain_build.c           | 141 ++++++++++++++++++++++++++----
 xen/arch/arm/setup.c                  |   3 +-
 xen/arch/arm/vgic-v2.c                |  12 +--
 xen/arch/arm/vgic-v3.c                |  18 +++-
 xen/arch/arm/vgic/vgic-init.c         |   4 +-
 xen/arch/arm/vgic/vgic-v2.c           |  18 ++--
 xen/arch/arm/vpl011.c                 |  12 ++-
 xen/arch/x86/domain.c                 |   3 +-
 xen/arch/x86/setup.c                  |   3 +-
 xen/common/domain.c                   |  13 +--
 xen/common/domctl.c                   |   3 +-
 xen/common/page_alloc.c               | 158 +++++++++++++++++++++++++---------
 xen/common/sched/core.c               |   3 +-
 xen/include/asm-arm/domain.h          |  10 ++-
 xen/include/asm-arm/new_vgic.h        |   4 +-
 xen/include/asm-arm/vgic.h            |   1 +
 xen/include/asm-x86/domain.h          |   2 +
 xen/include/xen/domain.h              |   8 +-
 xen/include/xen/mm.h                  |   2 +
 xen/include/xen/sched.h               |   2 +-
 23 files changed, 373 insertions(+), 99 deletions(-)
 create mode 100644 docs/misc/arm/passthrough-noiommu.txt


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSC-0001BX-7X; Wed, 15 Apr 2020 01:03:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSA-0001BP-FG
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:02:58 +0000
X-Inumbo-ID: d85ab3c2-7eb4-11ea-83d8-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d85ab3c2-7eb4-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 01:02:58 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id F091B2072D;
 Wed, 15 Apr 2020 01:02:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912577;
 bh=wF9us2YMoPDg0/9cb4wsozJ6he+zFTvLWGF9kUPj4ls=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=vbQLujcor6mYBLEyfu+PJcPRNRQfRbuzqSb6gqx/y3YBZ83w7hiDcrG01Kqxto946
 8uTCjm8hjxs+HWqTIZjAdZl0pGfkJZg+OSZtUnFe4yz9g+ZTNK5cuubIPqzgrvhuak
 2O+fQ7NMYANdRnN2k8zzdJOMYuJMG+5/4YPYfKgQ=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 01/12] xen: introduce xen_dom_flags
Date: Tue, 14 Apr 2020 18:02:44 -0700
Message-Id: <20200415010255.10081-1-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: sstabellini@kernel.org, julien@xen.org, Wei Liu <wl@xen.org>,
 George Dunlap <george.dunlap@eu.citrix.com>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, Dario Faggioli <dfaggioli@suse.com>,
 jbeulich@suse.com, Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Volodymyr_Babchuk@epam.com,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We are passing an extra special boolean flag at domain creation to
specify whether we want to the domain to be privileged (i.e. dom0) or
not. Another flag will be introduced later in this series.

Introduce a new struct xen_dom_flags and move the privileged flag to it.
Other flags will be added to struct xen_dom_flags.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
CC: andrew.cooper3@citrix.com
CC: jbeulich@suse.com
CC: George Dunlap <George.Dunlap@eu.citrix.com>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wl@xen.org>
CC: "Roger Pau Monné" <roger.pau@citrix.com>
CC: George Dunlap <george.dunlap@eu.citrix.com>
CC: Dario Faggioli <dfaggioli@suse.com>
---
 xen/arch/arm/domain.c       |  3 ++-
 xen/arch/arm/domain_build.c |  3 ++-
 xen/arch/arm/setup.c        |  3 ++-
 xen/arch/x86/domain.c       |  3 ++-
 xen/arch/x86/setup.c        |  3 ++-
 xen/common/domain.c         | 13 +++++++------
 xen/common/domctl.c         |  3 ++-
 xen/common/sched/core.c     |  3 ++-
 xen/include/xen/domain.h    |  7 ++++++-
 xen/include/xen/sched.h     |  2 +-
 10 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 6627be2922..b906a38b6b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -669,7 +669,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
 }
 
 int arch_domain_create(struct domain *d,
-                       struct xen_domctl_createdomain *config)
+                       struct xen_domctl_createdomain *config,
+                       struct xen_dom_flags *flags)
 {
     int rc, count = 0;
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4307087536..20e62a9fc4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2467,6 +2467,7 @@ void __init create_domUs(void)
             .max_grant_frames = 64,
             .max_maptrack_frames = 1024,
         };
+        struct xen_dom_flags flags = { false };
 
         if ( !dt_device_is_compatible(node, "xen,domain") )
             continue;
@@ -2491,7 +2492,7 @@ void __init create_domUs(void)
                                          GUEST_VPL011_SPI - 32 + 1);
         }
 
-        d = domain_create(++max_init_domid, &d_cfg, false);
+        d = domain_create(++max_init_domid, &d_cfg, &flags);
         if ( IS_ERR(d) )
             panic("Error creating domain %s\n", dt_node_name(node));
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7968cee47d..9ccb3f7385 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -787,6 +787,7 @@ void __init start_xen(unsigned long boot_phys_offset,
         .max_maptrack_frames = -1,
     };
     int rc;
+    struct xen_dom_flags flags = { true };
 
     dcache_line_bytes = read_dcache_line_bytes();
 
@@ -955,7 +956,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     if ( iommu_enabled )
         dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
 
-    dom0 = domain_create(0, &dom0_cfg, true);
+    dom0 = domain_create(0, &dom0_cfg, &flags);
     if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
         panic("Error creating domain 0\n");
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a008d7df1c..b92776f824 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -529,7 +529,8 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
 }
 
 int arch_domain_create(struct domain *d,
-                       struct xen_domctl_createdomain *config)
+                       struct xen_domctl_createdomain *config,
+                       struct xen_dom_flags *flags)
 {
     bool paging_initialised = false;
     uint32_t emflags;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 885919d5c3..e61114858b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -706,6 +706,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
         .max_maptrack_frames = -1,
     };
     const char *hypervisor_name;
+    struct xen_dom_flags flags = { !pv_shim };
 
     /* Critical region without IDT or TSS.  Any fault is deadly! */
 
@@ -1761,7 +1762,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
         dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
 
     /* Create initial domain 0. */
-    dom0 = domain_create(get_initial_domain_id(), &dom0_cfg, !pv_shim);
+    dom0 = domain_create(get_initial_domain_id(), &dom0_cfg, &flags);
     if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
         panic("Error creating domain 0\n");
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 3dcd73f67c..dd53475cc3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -341,7 +341,7 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
 
 struct domain *domain_create(domid_t domid,
                              struct xen_domctl_createdomain *config,
-                             bool is_priv)
+                             struct xen_dom_flags *flags)
 {
     struct domain *d, **pd, *old_hwdom = NULL;
     enum { INIT_watchdog = 1u<<1,
@@ -363,7 +363,7 @@ struct domain *domain_create(domid_t domid,
     ASSERT(is_system_domain(d) ? config == NULL : config != NULL);
 
     /* Sort out our idea of is_control_domain(). */
-    d->is_privileged = is_priv;
+    d->is_privileged =  flags ? flags->is_priv : false;
 
     /* Sort out our idea of is_hardware_domain(). */
     if ( domid == 0 || domid == hardware_domid )
@@ -443,7 +443,7 @@ struct domain *domain_create(domid_t domid,
         radix_tree_init(&d->pirq_tree);
     }
 
-    if ( (err = arch_domain_create(d, config)) != 0 )
+    if ( (err = arch_domain_create(d, config, flags)) != 0 )
         goto fail;
     init_status |= INIT_arch;
 
@@ -547,6 +547,7 @@ struct domain *domain_create(domid_t domid,
 
 void __init setup_system_domains(void)
 {
+    struct xen_dom_flags flags = { false };
     /*
      * Initialise our DOMID_XEN domain.
      * Any Xen-heap pages that we will allow to be mapped will have
@@ -554,7 +555,7 @@ void __init setup_system_domains(void)
      * Hidden PCI devices will also be associated with this domain
      * (but be [partly] controlled by Dom0 nevertheless).
      */
-    dom_xen = domain_create(DOMID_XEN, NULL, false);
+    dom_xen = domain_create(DOMID_XEN, NULL, &flags);
     if ( IS_ERR(dom_xen) )
         panic("Failed to create d[XEN]: %ld\n", PTR_ERR(dom_xen));
 
@@ -564,7 +565,7 @@ void __init setup_system_domains(void)
      * array. Mappings occur at the priv of the caller.
      * Quarantined PCI devices will be associated with this domain.
      */
-    dom_io = domain_create(DOMID_IO, NULL, false);
+    dom_io = domain_create(DOMID_IO, NULL, &flags);
     if ( IS_ERR(dom_io) )
         panic("Failed to create d[IO]: %ld\n", PTR_ERR(dom_io));
 
@@ -573,7 +574,7 @@ void __init setup_system_domains(void)
      * Initialise our COW domain.
      * This domain owns sharable pages.
      */
-    dom_cow = domain_create(DOMID_COW, NULL, false);
+    dom_cow = domain_create(DOMID_COW, NULL, &flags);
     if ( IS_ERR(dom_cow) )
         panic("Failed to create d[COW]: %ld\n", PTR_ERR(dom_cow));
 #endif
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a69b3b59a8..cb8d25500a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -364,6 +364,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     bool_t copyback = 0;
     struct xen_domctl curop, *op = &curop;
     struct domain *d;
+    struct xen_dom_flags flags ={ false };
 
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
@@ -515,7 +516,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             rover = dom;
         }
 
-        d = domain_create(dom, &op->u.createdomain, false);
+        d = domain_create(dom, &op->u.createdomain, &flags);
         if ( IS_ERR(d) )
         {
             ret = PTR_ERR(d);
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 626861a3fe..6457c71ce1 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2888,6 +2888,7 @@ void __init scheduler_init(void)
 {
     struct domain *idle_domain;
     int i;
+    struct xen_dom_flags flags = { false };
 
     scheduler_enable();
 
@@ -2957,7 +2958,7 @@ void __init scheduler_init(void)
         sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
     }
 
-    idle_domain = domain_create(DOMID_IDLE, NULL, false);
+    idle_domain = domain_create(DOMID_IDLE, NULL, &flags);
     BUG_ON(IS_ERR(idle_domain));
     BUG_ON(nr_cpu_ids > ARRAY_SIZE(idle_vcpu));
     idle_domain->vcpu = idle_vcpu;
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 7e51d361de..4423e34500 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -63,8 +63,13 @@ void arch_vcpu_destroy(struct vcpu *v);
 int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset);
 void unmap_vcpu_info(struct vcpu *v);
 
+struct xen_dom_flags {
+    bool is_priv;
+};
+
 int arch_domain_create(struct domain *d,
-                       struct xen_domctl_createdomain *config);
+                       struct xen_domctl_createdomain *config,
+                       struct xen_dom_flags *flags);
 
 void arch_domain_destroy(struct domain *d);
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 195e7ee583..4112f1ffc9 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -594,7 +594,7 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config);
  */
 struct domain *domain_create(domid_t domid,
                              struct xen_domctl_createdomain *config,
-                             bool is_priv);
+                             struct xen_dom_flags *flags);
 
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSD-0001C7-Ix; Wed, 15 Apr 2020 01:03:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSC-0001BW-7z
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:00 +0000
X-Inumbo-ID: d8674d46-7eb4-11ea-89ec-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d8674d46-7eb4-11ea-89ec-12813bfff9fa;
 Wed, 15 Apr 2020 01:02:59 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 506B120787;
 Wed, 15 Apr 2020 01:02:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912578;
 bh=YfCOD/krweRwr+m0KM00qRltE3yb4U9K6JqnMq8B/LA=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=E6vlUiEQIJ8wbywo5ASO6NY0rjUvrS4xDtaM0szQDkyAZAx1CeKpyZBSFVpufidIc
 w93SVAifJ3BXdbNHJpx+JdfNMCa9x8hvD+OHgRcKqegjg+eljNO3jJBNr7lPui8BK6
 LVVYKX7JoKEXYMwBrXVD66ZCMf6ZxlR2ECZvIeGs=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 03/12] xen/arm: introduce 1:1 mapping for domUs
Date: Tue, 14 Apr 2020 18:02:46 -0700
Message-Id: <20200415010255.10081-3-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr_Babchuk@epam.com, sstabellini@kernel.org, julien@xen.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In some cases it is desirable to map domU memory 1:1 (guest physical ==
physical.) For instance, because we want to assign a device to the domU
but the IOMMU is not present or cannot be used. In these cases, other
mechanisms should be used for DMA protection, e.g. a MPU.

This patch introduces a new device tree option for dom0less guests to
request a domain to be directly mapped. It also specifies the memory
ranges. This patch documents the new attribute and parses it at boot
time. (However, the implementation of 1:1 mapping is missing and just
BUG() out at the moment.)  Finally the patch sets the new direct_map
flag for DomU domains.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
---
 docs/misc/arm/device-tree/booting.txt | 13 +++++++
 docs/misc/arm/passthrough-noiommu.txt | 35 ++++++++++++++++++
 xen/arch/arm/domain_build.c           | 52 +++++++++++++++++++++++++--
 3 files changed, 98 insertions(+), 2 deletions(-)
 create mode 100644 docs/misc/arm/passthrough-noiommu.txt

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index 5243bc7fd3..fce5f7ed5a 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -159,6 +159,19 @@ with the following properties:
     used, or GUEST_VPL011_SPI+1 if vpl011 is enabled, whichever is
     greater.
 
+- direct-map
+
+    Optional. An array of integer pairs specifying addresses and sizes.
+    direct_map requests the memory of the domain to be 1:1 mapped with
+    the memory ranges specified as argument. Only sizes that are a
+    power of two number of pages are allowed.
+
+- #direct-map-addr-cells and #direct-map-size-cells
+
+    The number of cells to use for the addresses and for the sizes in
+    direct-map. Default and maximum are 2 cells for both addresses and
+    sizes.
+
 - #address-cells and #size-cells
 
     Both #address-cells and #size-cells need to be specified because
diff --git a/docs/misc/arm/passthrough-noiommu.txt b/docs/misc/arm/passthrough-noiommu.txt
new file mode 100644
index 0000000000..d2bfaf26c3
--- /dev/null
+++ b/docs/misc/arm/passthrough-noiommu.txt
@@ -0,0 +1,35 @@
+Request Device Assignment without IOMMU support
+===============================================
+
+Add xen,force-assign-without-iommu; to the device tree snippet
+
+    ethernet: ethernet@ff0e0000 {
+        compatible = "cdns,zynqmp-gem";
+        xen,path = "/amba/ethernet@ff0e0000";
+        xen,reg = <0x0 0xff0e0000 0x1000 0x0 0xff0e0000>;
+        xen,force-assign-without-iommu;
+
+Optionally, if none of the domains require an IOMMU, then it could be
+disabled (not recommended). For instance by adding status = "disabled";
+under the smmu node:
+
+    smmu@fd800000 {
+        compatible = "arm,mmu-500";
+        status = "disabled";
+
+
+Request 1:1 memory mapping for the dom0-less domain
+===================================================
+
+Add a direct-map property under the appropriate /chosen/domU node with
+the memory ranges you want to assign to your domain. If you are using
+imagebuilder, you can add to boot.source something like the following:
+
+    fdt set /chosen/domU0 direct-map <0x0 0x10000000 0x0 0x10000000 0x0 0x60000000 0x0 0x10000000>
+
+Which will assign the ranges:
+
+    0x10000000 - 0x20000000
+    0x60000000 - 0x70000000
+
+to the first dom0less domU.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2ec7453aa3..a2bb411568 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2435,7 +2435,51 @@ static int __init construct_domU(struct domain *d,
     /* type must be set before allocate memory */
     d->arch.type = kinfo.type;
 #endif
-    allocate_memory(d, &kinfo);
+
+    if ( !is_domain_direct_mapped(d) )
+        allocate_memory(d, &kinfo);
+    else
+    {
+        struct membank banks[NR_MEM_BANKS];
+        const struct dt_property *prop;
+        u32 direct_map_len, direct_map_addr_len = 2, direct_map_size_len = 2;
+        unsigned int i;
+        __be32 *p;
+
+        prop = dt_find_property(node, "direct-map", &direct_map_len);
+        BUG_ON(!prop);
+
+        dt_property_read_u32(node,
+                             "#direct-map-addr-cells",
+                             &direct_map_addr_len);
+        dt_property_read_u32(node,
+                             "#direct-map-size-cells",
+                             &direct_map_size_len);
+        BUG_ON(direct_map_size_len > 2 || direct_map_addr_len > 2);
+
+        for ( i = 0, p = prop->value;
+              i < direct_map_len /
+                  (4 * (direct_map_addr_len + direct_map_size_len));
+              i++)
+        {
+            int j;
+
+            banks[i].start = 0;
+            for ( j = 0; j < direct_map_addr_len; j++, p++ )
+                banks[i].start |= __be32_to_cpu(*p) << (32*j);
+
+            banks[i].size = 0;
+            for ( j = 0; j < direct_map_size_len; j++, p++ )
+                banks[i].size |= __be32_to_cpu(*p) << (32*j);
+
+            printk(XENLOG_DEBUG
+                   "direct_map start=%#"PRIpaddr" size=%#"PRIpaddr"\n",
+                   banks[i].start, banks[i].size);
+        }
+
+        /* reserve_memory_11(d, &kinfo, &banks[0], i); */
+        BUG();
+    }
 
     rc = prepare_dtb_domU(d, &kinfo);
     if ( rc < 0 )
@@ -2455,6 +2499,7 @@ void __init create_domUs(void)
 {
     struct dt_device_node *node;
     const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+    u32 direct_map = 0;
 
     BUG_ON(chosen == NULL);
     dt_for_each_child_node(chosen, node)
@@ -2476,8 +2521,11 @@ void __init create_domUs(void)
             panic("Missing property 'cpus' for domain %s\n",
                   dt_node_name(node));
 
-        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
+        dt_find_property(node, "direct-map", &direct_map);
+        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") &&
+             !direct_map )
             d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+        flags.arch.is_direct_map = direct_map != 0;
 
         if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) )
         {
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSF-0001Cy-UQ; Wed, 15 Apr 2020 01:03:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSF-0001Cn-En
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:03 +0000
X-Inumbo-ID: d8bd8db2-7eb4-11ea-83d8-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d8bd8db2-7eb4-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 01:02:58 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id BD1A320774;
 Wed, 15 Apr 2020 01:02:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912578;
 bh=o7ggJLBOOkXOXw9bb9MmuF9lECpxcldnKeYW5Qgwn6A=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=D9YZe7/B+m7worXC3EBZu5bVhXwDQiuOE6IJ326Nk1HGMg1iw7B3cIxEd3//nx9Jv
 JSQBlpy9F9ZWEcPIvsp3U64X/H5fbLJGXzdAv2n2AZmhWaw19whIXdSADoH0BgZsKB
 fe/1q/a4nO67fAmrt2kHj/86wQSLpsP01CIeWtHQ=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 02/12] xen/arm: introduce arch_xen_dom_flags and direct_map
Date: Tue, 14 Apr 2020 18:02:45 -0700
Message-Id: <20200415010255.10081-2-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: sstabellini@kernel.org, julien@xen.org, Wei Liu <wl@xen.org>,
 George Dunlap <George.Dunlap@eu.citrix.com>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, jbeulich@suse.com,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Introduce a new field in struct xen_dom_flags to store arch-specific
flags.

Add an ARM-specific flag to specify that the domain should be directly
mapped (guest physical addresses == physical addresses).

Also, add a direct_map flag under struct arch_domain and use it to
implement is_domain_direct_mapped.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
CC: andrew.cooper3@citrix.com
CC: jbeulich@suse.com
CC: George Dunlap <George.Dunlap@eu.citrix.com>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wl@xen.org>
CC: "Roger Pau Monné" <roger.pau@citrix.com>
---
 xen/arch/arm/domain.c        | 1 +
 xen/arch/arm/domain_build.c  | 1 +
 xen/arch/arm/setup.c         | 2 +-
 xen/include/asm-arm/domain.h | 9 ++++++++-
 xen/include/asm-x86/domain.h | 2 ++
 xen/include/xen/domain.h     | 1 +
 6 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index b906a38b6b..59eae36de7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -682,6 +682,7 @@ int arch_domain_create(struct domain *d,
         return 0;
 
     ASSERT(config != NULL);
+    d->arch.direct_map = flags != NULL ? flags->arch.is_direct_map : false;
 
     /* p2m_init relies on some value initialized by the IOMMU subsystem */
     if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 20e62a9fc4..2ec7453aa3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2527,6 +2527,7 @@ int __init construct_dom0(struct domain *d)
 
     iommu_hwdom_init(d);
 
+    d->arch.direct_map = true;
     d->max_pages = ~0U;
 
     kinfo.unassigned_mem = dom0_mem;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 9ccb3f7385..5434548e7b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -787,7 +787,7 @@ void __init start_xen(unsigned long boot_phys_offset,
         .max_maptrack_frames = -1,
     };
     int rc;
-    struct xen_dom_flags flags = { true };
+    struct xen_dom_flags flags = { true, .arch.is_direct_map = true };
 
     dcache_line_bytes = read_dcache_line_bytes();
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index d39477a939..7a498921bf 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -32,7 +32,7 @@ enum domain_type {
 #endif
 
 /* The hardware domain has always its memory direct mapped. */
-#define is_domain_direct_mapped(d) ((d) == hardware_domain)
+#define is_domain_direct_mapped(d) ((d)->arch.direct_map != false)
 
 struct vtimer {
     struct vcpu *v;
@@ -98,8 +98,15 @@ struct arch_domain
 #ifdef CONFIG_TEE
     void *tee;
 #endif
+
+    bool direct_map;
 }  __cacheline_aligned;
 
+struct arch_xen_dom_flags
+{
+    bool is_direct_map;
+};
+
 struct arch_vcpu
 {
     struct {
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 105adf96eb..52199ed5b9 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -418,6 +418,8 @@ struct arch_domain
     uint32_t emulation_flags;
 } __cacheline_aligned;
 
+struct arch_xen_dom_flags {};
+
 #ifdef CONFIG_HVM
 #define X86_EMU_LAPIC    XEN_X86_EMU_LAPIC
 #define X86_EMU_HPET     XEN_X86_EMU_HPET
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 4423e34500..7227e6ca98 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -65,6 +65,7 @@ void unmap_vcpu_info(struct vcpu *v);
 
 struct xen_dom_flags {
     bool is_priv;
+    struct arch_xen_dom_flags arch;
 };
 
 int arch_domain_create(struct domain *d,
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSI-0001EO-Eb; Wed, 15 Apr 2020 01:03:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSH-0001Dc-4a
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:05 +0000
X-Inumbo-ID: d991c32a-7eb4-11ea-89ec-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d991c32a-7eb4-11ea-89ec-12813bfff9fa;
 Wed, 15 Apr 2020 01:03:00 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 3258D20857;
 Wed, 15 Apr 2020 01:02:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912579;
 bh=7207g/eifnxKqKtgIrYV/hVTptHqGaliYQujFgsQjjk=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=p7wsTRFGJteqpd8bB4jmalT0FlD99CipBIjKuN9ha085Mqo28nY3jZw6t/7AzH4lw
 Cu05jMJBobNGGrKl3p2GfTcCRu9RtOgGIl30NrGalMa/VYl3xIdn412RaP/Arfr/4S
 lqRElwR96hQiL3GjuN4fG0uTnCo2agjibJsM74hg=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 05/12] xen: introduce reserve_heap_pages
Date: Tue, 14 Apr 2020 18:02:48 -0700
Message-Id: <20200415010255.10081-5-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: sstabellini@kernel.org, julien@xen.org, Wei Liu <wl@xen.org>,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, jbeulich@suse.com,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Introduce a function named reserve_heap_pages (similar to
alloc_heap_pages) that allocates a requested memory range. Call
__alloc_heap_pages for the implementation.

Change __alloc_heap_pages so that the original page doesn't get
modified, giving back unneeded memory top to bottom rather than bottom
to top.

Also introduce a function named reserve_domheap_pages, similar to
alloc_domheap_pages, that checks memflags before calling
reserve_heap_pages. It also assign_pages to the domain on success.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
CC: andrew.cooper3@citrix.com
CC: jbeulich@suse.com
CC: George Dunlap <george.dunlap@citrix.com>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wl@xen.org>
---
 xen/common/page_alloc.c | 72 ++++++++++++++++++++++++++++++++++++++---
 xen/include/xen/mm.h    |  2 ++
 2 files changed, 69 insertions(+), 5 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 79ae64d4b8..3a9c1a291b 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -911,7 +911,7 @@ static struct page_info *get_free_buddy(unsigned int zone_lo,
     }
 }
 
-static void __alloc_heap_pages(struct page_info **pgo,
+static void __alloc_heap_pages(struct page_info *pg,
                                unsigned int order,
                                unsigned int memflags,
                                struct domain *d)
@@ -922,7 +922,7 @@ static void __alloc_heap_pages(struct page_info **pgo,
     bool need_tlbflush = false;
     uint32_t tlbflush_timestamp = 0;
     unsigned int dirty_cnt = 0;
-    struct page_info *pg = *pgo;
+    struct page_info *pg_start = pg;
 
     node = phys_to_nid(page_to_maddr(pg));
     zone = page_to_zone(pg);
@@ -934,10 +934,10 @@ static void __alloc_heap_pages(struct page_info **pgo,
     while ( buddy_order != order )
     {
         buddy_order--;
+        pg = pg_start + (1U << buddy_order);
         page_list_add_scrub(pg, node, zone, buddy_order,
                             (1U << buddy_order) > first_dirty ?
                             first_dirty : INVALID_DIRTY_IDX);
-        pg += 1U << buddy_order;
 
         if ( first_dirty != INVALID_DIRTY_IDX )
         {
@@ -948,7 +948,7 @@ static void __alloc_heap_pages(struct page_info **pgo,
                 first_dirty = 0; /* We've moved past original first_dirty */
         }
     }
-    *pgo = pg;
+    pg = pg_start;
 
     ASSERT(avail[node][zone] >= request);
     avail[node][zone] -= request;
@@ -1073,7 +1073,42 @@ static struct page_info *alloc_heap_pages(
         return NULL;
     }
 
-    __alloc_heap_pages(&pg, order, memflags, d);
+    __alloc_heap_pages(pg, order, memflags, d);
+    return pg;
+}
+
+static struct page_info *reserve_heap_pages(struct domain *d,
+                                            paddr_t start,
+                                            unsigned int order,
+                                            unsigned int memflags)
+{
+    nodeid_t node;
+    unsigned int zone;
+    struct page_info *pg;
+
+    if ( unlikely(order > MAX_ORDER) )
+        return NULL;
+
+    spin_lock(&heap_lock);
+
+    /*
+     * Claimed memory is considered unavailable unless the request
+     * is made by a domain with sufficient unclaimed pages.
+     */
+    if ( (outstanding_claims + (1UL << order) > total_avail_pages) &&
+          ((memflags & MEMF_no_refcount) ||
+           !d || d->outstanding_pages < (1UL << order)) )
+    {
+        spin_unlock(&heap_lock);
+        return NULL;
+    }
+
+    pg = maddr_to_page(start);
+    node = phys_to_nid(start);
+    zone = page_to_zone(pg);
+    page_list_del(pg, &heap(node, zone, order));
+
+    __alloc_heap_pages(pg, order, memflags, d);
     return pg;
 }
 
@@ -2385,6 +2420,33 @@ struct page_info *alloc_domheap_pages(
     return pg;
 }
 
+struct page_info *reserve_domheap_pages(
+    struct domain *d, paddr_t start, unsigned int order, unsigned int memflags)
+{
+    struct page_info *pg = NULL;
+
+    ASSERT(!in_irq());
+
+    if ( memflags & MEMF_no_owner )
+        memflags |= MEMF_no_refcount;
+    else if ( (memflags & MEMF_no_refcount) && d )
+    {
+        ASSERT(!(memflags & MEMF_no_refcount));
+        return NULL;
+    }
+
+    pg = reserve_heap_pages(d, start, order, memflags);
+
+    if ( d && !(memflags & MEMF_no_owner) &&
+         assign_pages(d, pg, order, memflags) )
+    {
+        free_heap_pages(pg, order, memflags & MEMF_no_scrub);
+        return NULL;
+    }
+
+    return pg;
+}
+
 void free_domheap_pages(struct page_info *pg, unsigned int order)
 {
     struct domain *d = page_get_owner(pg);
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 9b62087be1..35407e1b68 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -199,6 +199,8 @@ void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages);
 void init_domheap_pages(paddr_t ps, paddr_t pe);
 struct page_info *alloc_domheap_pages(
     struct domain *d, unsigned int order, unsigned int memflags);
+struct page_info *reserve_domheap_pages(
+    struct domain *d, paddr_t start, unsigned int order, unsigned int memflags);
 void free_domheap_pages(struct page_info *pg, unsigned int order);
 unsigned long avail_domheap_pages_region(
     unsigned int node, unsigned int min_width, unsigned int max_width);
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSL-0001Ft-Qw; Wed, 15 Apr 2020 01:03:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSK-0001FQ-FS
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:08 +0000
X-Inumbo-ID: d93f8b0a-7eb4-11ea-b4f4-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d93f8b0a-7eb4-11ea-b4f4-bc764e2007e4;
 Wed, 15 Apr 2020 01:02:59 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id A5AD72083B;
 Wed, 15 Apr 2020 01:02:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912579;
 bh=YV7d8M1BR8baRsXNvbLsTI5FkEiel89KL9GK6xJVhRk=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=xea7/ciO1nz2/OVyRSuWlcKWtX9VHsqi0YcK0pKXrNW3WohMbZp62cZvsAySHk6lC
 lmVpXdQLoNORTEVTgpatQy3ZqT1yG4D0fHlow0JPbSIfdpBzChQhsDQEuzplpYEUMS
 eqaojGPaKVpVoUE8Nmsb9xPuEFXHcMdPUfuDpWWo=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 04/12] xen: split alloc_heap_pages in two halves for
 reusability
Date: Tue, 14 Apr 2020 18:02:47 -0700
Message-Id: <20200415010255.10081-4-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: sstabellini@kernel.org, julien@xen.org, Wei Liu <wl@xen.org>,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, jbeulich@suse.com,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This patch splits the implementation of alloc_heap_pages into two halves
so that the second half can be reused by the next patch.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
CC: andrew.cooper3@citrix.com
CC: jbeulich@suse.com
CC: George Dunlap <george.dunlap@citrix.com>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wl@xen.org>
---
Comments are welcome. I am not convinced that this is the right way to
split it. Please let me know if you have any suggestions.
---
 xen/common/page_alloc.c | 94 +++++++++++++++++++++++------------------
 1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 10b7aeca48..79ae64d4b8 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -911,54 +911,18 @@ static struct page_info *get_free_buddy(unsigned int zone_lo,
     }
 }
 
-/* Allocate 2^@order contiguous pages. */
-static struct page_info *alloc_heap_pages(
-    unsigned int zone_lo, unsigned int zone_hi,
-    unsigned int order, unsigned int memflags,
-    struct domain *d)
+static void __alloc_heap_pages(struct page_info **pgo,
+                               unsigned int order,
+                               unsigned int memflags,
+                               struct domain *d)
 {
     nodeid_t node;
     unsigned int i, buddy_order, zone, first_dirty;
     unsigned long request = 1UL << order;
-    struct page_info *pg;
     bool need_tlbflush = false;
     uint32_t tlbflush_timestamp = 0;
     unsigned int dirty_cnt = 0;
-
-    /* Make sure there are enough bits in memflags for nodeID. */
-    BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t)));
-
-    ASSERT(zone_lo <= zone_hi);
-    ASSERT(zone_hi < NR_ZONES);
-
-    if ( unlikely(order > MAX_ORDER) )
-        return NULL;
-
-    spin_lock(&heap_lock);
-
-    /*
-     * Claimed memory is considered unavailable unless the request
-     * is made by a domain with sufficient unclaimed pages.
-     */
-    if ( (outstanding_claims + request > total_avail_pages) &&
-          ((memflags & MEMF_no_refcount) ||
-           !d || d->outstanding_pages < request) )
-    {
-        spin_unlock(&heap_lock);
-        return NULL;
-    }
-
-    pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d);
-    /* Try getting a dirty buddy if we couldn't get a clean one. */
-    if ( !pg && !(memflags & MEMF_no_scrub) )
-        pg = get_free_buddy(zone_lo, zone_hi, order,
-                            memflags | MEMF_no_scrub, d);
-    if ( !pg )
-    {
-        /* No suitable memory blocks. Fail the request. */
-        spin_unlock(&heap_lock);
-        return NULL;
-    }
+    struct page_info *pg = *pgo;
 
     node = phys_to_nid(page_to_maddr(pg));
     zone = page_to_zone(pg);
@@ -984,6 +948,7 @@ static struct page_info *alloc_heap_pages(
                 first_dirty = 0; /* We've moved past original first_dirty */
         }
     }
+    *pgo = pg;
 
     ASSERT(avail[node][zone] >= request);
     avail[node][zone] -= request;
@@ -1062,6 +1027,53 @@ static struct page_info *alloc_heap_pages(
     if ( need_tlbflush )
         filtered_flush_tlb_mask(tlbflush_timestamp);
 
+}
+
+/* Allocate 2^@order contiguous pages. */
+static struct page_info *alloc_heap_pages(
+    unsigned int zone_lo, unsigned int zone_hi,
+    unsigned int order, unsigned int memflags,
+    struct domain *d)
+{
+    unsigned long request = 1UL << order;
+    struct page_info *pg;
+
+    /* Make sure there are enough bits in memflags for nodeID. */
+    BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t)));
+
+    ASSERT(zone_lo <= zone_hi);
+    ASSERT(zone_hi < NR_ZONES);
+
+    if ( unlikely(order > MAX_ORDER) )
+        return NULL;
+
+    spin_lock(&heap_lock);
+
+    /*
+     * Claimed memory is considered unavailable unless the request
+     * is made by a domain with sufficient unclaimed pages.
+     */
+    if ( (outstanding_claims + request > total_avail_pages) &&
+          ((memflags & MEMF_no_refcount) ||
+           !d || d->outstanding_pages < request) )
+    {
+        spin_unlock(&heap_lock);
+        return NULL;
+    }
+
+    pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d);
+    /* Try getting a dirty buddy if we couldn't get a clean one. */
+    if ( !pg && !(memflags & MEMF_no_scrub) )
+        pg = get_free_buddy(zone_lo, zone_hi, order,
+                            memflags | MEMF_no_scrub, d);
+    if ( !pg )
+    {
+        /* No suitable memory blocks. Fail the request. */
+        spin_unlock(&heap_lock);
+        return NULL;
+    }
+
+    __alloc_heap_pages(&pg, order, memflags, d);
     return pg;
 }
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSN-0001Gp-66; Wed, 15 Apr 2020 01:03:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSM-0001GC-4U
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:10 +0000
X-Inumbo-ID: d991c32b-7eb4-11ea-89ec-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d991c32b-7eb4-11ea-89ec-12813bfff9fa;
 Wed, 15 Apr 2020 01:03:00 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 157EB2087E;
 Wed, 15 Apr 2020 01:03:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912580;
 bh=NlKdqK0InViPQ1RlBoqs8f8gr+feCFyOn6w13VpIxiU=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=XLqpvddxuHUSAvmG2krEq5LBfd6lPKYtV9Fjg9poRf3URL45tHF+2LTpMVubFqoea
 BgTHu6IWfipWrmlF6wKpEJC5LQcpX8UWmpVD/S4/52YdNPBsoj+cGzy+5PpUXcQJVw
 D16m5BdA959RRubXCDUuesoSlP/YdayR7pl63MV0=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 07/12] xen/arm: new vgic: rename vgic_cpu/dist_base to c/dbase
Date: Tue, 14 Apr 2020 18:02:50 -0700
Message-Id: <20200415010255.10081-7-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr_Babchuk@epam.com, sstabellini@kernel.org, julien@xen.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

To be uniform with the old vgic. Name uniformity will become immediately
useful in the following patch.

In vgic_v2_map_resources, use the fields in struct vgic_dist rather than
local variables.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
---
 xen/arch/arm/vgic/vgic-init.c  |  4 ++--
 xen/arch/arm/vgic/vgic-v2.c    | 16 ++++++++--------
 xen/include/asm-arm/new_vgic.h |  4 ++--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c
index 62ae553699..ea739d081e 100644
--- a/xen/arch/arm/vgic/vgic-init.c
+++ b/xen/arch/arm/vgic/vgic-init.c
@@ -112,8 +112,8 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
         BUG();
     }
 
-    d->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
-    d->arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;
+    d->arch.vgic.dbase = VGIC_ADDR_UNDEF;
+    d->arch.vgic.cbase = VGIC_ADDR_UNDEF;
     d->arch.vgic.vgic_redist_base = VGIC_ADDR_UNDEF;
 
     return 0;
diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
index b5ba4ace87..09cb92039a 100644
--- a/xen/arch/arm/vgic/vgic-v2.c
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -258,7 +258,7 @@ void vgic_v2_enable(struct vcpu *vcpu)
 int vgic_v2_map_resources(struct domain *d)
 {
     struct vgic_dist *dist = &d->arch.vgic;
-    paddr_t cbase, csize;
+    paddr_t csize;
     paddr_t vbase;
     int ret;
 
@@ -268,7 +268,7 @@ int vgic_v2_map_resources(struct domain *d)
      */
     if ( is_hardware_domain(d) )
     {
-        d->arch.vgic.vgic_dist_base = gic_v2_hw_data.dbase;
+        d->arch.vgic.dbase = gic_v2_hw_data.dbase;
         /*
          * For the hardware domain, we always map the whole HW CPU
          * interface region in order to match the device tree (the "reg"
@@ -276,13 +276,13 @@ int vgic_v2_map_resources(struct domain *d)
          * Note that we assume the size of the CPU interface is always
          * aligned to PAGE_SIZE.
          */
-        cbase = gic_v2_hw_data.cbase;
+        d->arch.vgic.cbase = gic_v2_hw_data.cbase;
         csize = gic_v2_hw_data.csize;
         vbase = gic_v2_hw_data.vbase;
     }
     else
     {
-        d->arch.vgic.vgic_dist_base = GUEST_GICD_BASE;
+        d->arch.vgic.dbase = GUEST_GICD_BASE;
         /*
          * The CPU interface exposed to the guest is always 8kB. We may
          * need to add an offset to the virtual CPU interface base
@@ -290,13 +290,13 @@ int vgic_v2_map_resources(struct domain *d)
          * region.
          */
         BUILD_BUG_ON(GUEST_GICC_SIZE != SZ_8K);
-        cbase = GUEST_GICC_BASE;
+        d->arch.vgic.cbase = GUEST_GICC_BASE;
         csize = GUEST_GICC_SIZE;
         vbase = gic_v2_hw_data.vbase + gic_v2_hw_data.aliased_offset;
     }
 
 
-    ret = vgic_register_dist_iodev(d, gaddr_to_gfn(dist->vgic_dist_base),
+    ret = vgic_register_dist_iodev(d, gaddr_to_gfn(dist->dbase),
                                    VGIC_V2);
     if ( ret )
     {
@@ -308,8 +308,8 @@ int vgic_v2_map_resources(struct domain *d)
      * Map the gic virtual cpu interface in the gic cpu interface
      * region of the guest.
      */
-    ret = map_mmio_regions(d, gaddr_to_gfn(cbase), csize / PAGE_SIZE,
-                           maddr_to_mfn(vbase));
+    ret = map_mmio_regions(d, gaddr_to_gfn(d->arch.vgic.cbase),
+                           csize / PAGE_SIZE, maddr_to_mfn(vbase));
     if ( ret )
     {
         gdprintk(XENLOG_ERR, "Unable to remap VGIC CPU to VCPU\n");
diff --git a/xen/include/asm-arm/new_vgic.h b/xen/include/asm-arm/new_vgic.h
index 97d622bff6..e3319900ab 100644
--- a/xen/include/asm-arm/new_vgic.h
+++ b/xen/include/asm-arm/new_vgic.h
@@ -115,11 +115,11 @@ struct vgic_dist {
     unsigned int        nr_spis;
 
     /* base addresses in guest physical address space: */
-    paddr_t             vgic_dist_base;     /* distributor */
+    paddr_t             dbase;     /* distributor */
     union
     {
         /* either a GICv2 CPU interface */
-        paddr_t         vgic_cpu_base;
+        paddr_t         cbase;
         /* or a number of GICv3 redistributor regions */
         struct
         {
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSQ-0001Iz-Jo; Wed, 15 Apr 2020 01:03:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSP-0001IG-Fr
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:13 +0000
X-Inumbo-ID: d9c69c80-7eb4-11ea-b58d-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d9c69c80-7eb4-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 01:03:00 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id B0CA32076C;
 Wed, 15 Apr 2020 01:02:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912579;
 bh=FMlXcRXt/zCRQA/cD6Iv2GQCYoMd2JYd4wrOKCkm6KU=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=zly7T+H4CPDzIclXBWdJhaKJ541truZ27Mnbq0DENiut9D0fbBRJcs3piPJzKhm0f
 lhBfbBVfvIaUkKWXz8UPA0jz7641V9MPQEE3ITAyQvRV0g62rqkkwlYtHBu+NPfDc5
 wp2KmgdxUCWPRgXVf9Qbjt61XWE0cXCauoVHp4Yo=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 06/12] xen/arm: reserve 1:1 memory for direct_map domUs
Date: Tue, 14 Apr 2020 18:02:49 -0700
Message-Id: <20200415010255.10081-6-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr_Babchuk@epam.com, sstabellini@kernel.org, julien@xen.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Use reserve_domheap_pages to implement the direct-map ranges allocation
for DomUs.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
---
 xen/arch/arm/domain_build.c | 37 +++++++++++++++++++++++++++++++++++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a2bb411568..627e0c5e8e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -198,6 +198,40 @@ fail:
     return false;
 }
 
+static void __init reserve_memory_11(struct domain *d,
+                                     struct kernel_info *kinfo,
+                                     struct membank *banks,
+                                     unsigned int nr_banks)
+{
+    unsigned int i, order;
+    struct page_info *pg;
+   
+    kinfo->mem.nr_banks = 0;
+
+    for ( i = 0; i < nr_banks; i++ )
+    {
+        order = get_order_from_bytes(banks[i].size);
+        pg = reserve_domheap_pages(d, banks[i].start, order, 0);
+        if ( pg == NULL || !insert_11_bank(d, kinfo, pg, order) )
+        {
+            printk(XENLOG_ERR
+                   "%pd: cannot reserve memory start=%#"PRIpaddr" size=%#"PRIpaddr"\n",
+                    d, banks[i].start, banks[i].size);
+            BUG();
+        }
+    }
+
+    for( i = 0; i < kinfo->mem.nr_banks; i++ )
+    {
+        printk("BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+                i,
+                kinfo->mem.bank[i].start,
+                kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
+                /* Don't want format this as PRIpaddr (16 digit hex) */
+                (unsigned long)(kinfo->mem.bank[i].size >> 20));
+    }
+}
+
 /*
  * This is all pretty horrible.
  *
@@ -2477,8 +2511,7 @@ static int __init construct_domU(struct domain *d,
                    banks[i].start, banks[i].size);
         }
 
-        /* reserve_memory_11(d, &kinfo, &banks[0], i); */
-        BUG();
+        reserve_memory_11(d, &kinfo, &banks[0], i);
     }
 
     rc = prepare_dtb_domU(d, &kinfo);
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWST-0001Kp-0w; Wed, 15 Apr 2020 01:03:17 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSR-0001JV-4v
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:15 +0000
X-Inumbo-ID: da3083ca-7eb4-11ea-89ec-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id da3083ca-7eb4-11ea-89ec-12813bfff9fa;
 Wed, 15 Apr 2020 01:03:01 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 69B81208FE;
 Wed, 15 Apr 2020 01:03:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912580;
 bh=ZzU/KCsWFqwH+c4W+Sd0RSn1ZEn5hNAtQGIHQMy5tEk=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=VqWqFsZR6RwDPloWnP4LyDoX02kf0vE9iKyZaguCe9gybtsSJRC2cRPSOagrTHmNH
 5JeJsG0LKR1YfyruQjIm9ORndgRSKuInwXNxCm9xBq4B+IJxXCMZWBBVxPK8/A2kjz
 5ANwSqaclTnIZVZDTBVcIe5iphX+0/NFxdgyphCg=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 08/12] xen/arm: if is_domain_direct_mapped use native
 addresses for GICv2
Date: Tue, 14 Apr 2020 18:02:51 -0700
Message-Id: <20200415010255.10081-8-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr_Babchuk@epam.com, sstabellini@kernel.org, julien@xen.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Today we use native addresses to map the GICv2 for Dom0 and fixed
addresses for DomUs.

This patch changes the behavior so that native addresses are used for
any domain that is_domain_direct_mapped.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
---
 xen/arch/arm/domain_build.c | 10 +++++++---
 xen/arch/arm/vgic-v2.c      | 12 ++++++------
 xen/arch/arm/vgic/vgic-v2.c |  2 +-
 xen/include/asm-arm/vgic.h  |  1 +
 4 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 627e0c5e8e..303bee60f6 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1643,8 +1643,12 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
     int res = 0;
     __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
     __be32 *cells;
+    struct domain *d = kinfo->d;
+    char buf[38];
 
-    res = fdt_begin_node(fdt, "interrupt-controller@"__stringify(GUEST_GICD_BASE));
+    snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIx64,
+             d->arch.vgic.dbase);
+    res = fdt_begin_node(fdt, buf);
     if ( res )
         return res;
 
@@ -1666,9 +1670,9 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
 
     cells = &reg[0];
     dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
-                       GUEST_GICD_BASE, GUEST_GICD_SIZE);
+                       d->arch.vgic.dbase, GUEST_GICD_SIZE);
     dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
-                       GUEST_GICC_BASE, GUEST_GICC_SIZE);
+                       d->arch.vgic.cbase, GUEST_GICC_SIZE);
 
     res = fdt_property(fdt, "reg", reg, sizeof(reg));
     if (res)
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 64b141fea5..9a74e2ed38 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -650,14 +650,14 @@ static int vgic_v2_vcpu_init(struct vcpu *v)
 static int vgic_v2_domain_init(struct domain *d)
 {
     int ret;
-    paddr_t cbase, csize;
+    paddr_t csize;
     paddr_t vbase;
 
     /*
      * The hardware domain gets the hardware address.
      * Guests get the virtual platform layout.
      */
-    if ( is_hardware_domain(d) )
+    if ( is_domain_direct_mapped(d) )
     {
         d->arch.vgic.dbase = vgic_v2_hw.dbase;
         /*
@@ -667,7 +667,7 @@ static int vgic_v2_domain_init(struct domain *d)
          * Note that we assume the size of the CPU interface is always
          * aligned to PAGE_SIZE.
          */
-        cbase = vgic_v2_hw.cbase;
+        d->arch.vgic.cbase = vgic_v2_hw.cbase;
         csize = vgic_v2_hw.csize;
         vbase = vgic_v2_hw.vbase;
     }
@@ -681,7 +681,7 @@ static int vgic_v2_domain_init(struct domain *d)
          * region.
          */
         BUILD_BUG_ON(GUEST_GICC_SIZE != SZ_8K);
-        cbase = GUEST_GICC_BASE;
+        d->arch.vgic.cbase = GUEST_GICC_BASE;
         csize = GUEST_GICC_SIZE;
         vbase = vgic_v2_hw.vbase + vgic_v2_hw.aliased_offset;
     }
@@ -690,8 +690,8 @@ static int vgic_v2_domain_init(struct domain *d)
      * Map the gic virtual cpu interface in the gic cpu interface
      * region of the guest.
      */
-    ret = map_mmio_regions(d, gaddr_to_gfn(cbase), csize / PAGE_SIZE,
-                           maddr_to_mfn(vbase));
+    ret = map_mmio_regions(d, gaddr_to_gfn(d->arch.vgic.cbase),
+                           csize / PAGE_SIZE, maddr_to_mfn(vbase));
     if ( ret )
         return ret;
 
diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
index 09cb92039a..275dd8bea9 100644
--- a/xen/arch/arm/vgic/vgic-v2.c
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -266,7 +266,7 @@ int vgic_v2_map_resources(struct domain *d)
      * The hardware domain gets the hardware address.
      * Guests get the virtual platform layout.
      */
-    if ( is_hardware_domain(d) )
+    if ( is_domain_direct_mapped(d) )
     {
         d->arch.vgic.dbase = gic_v2_hw_data.dbase;
         /*
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index ce1e3c4bbd..f151d98773 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -152,6 +152,7 @@ struct vgic_dist {
     struct pending_irq *pending_irqs;
     /* Base address for guest GIC */
     paddr_t dbase; /* Distributor base address */
+    paddr_t cbase; /* CPU interface base address */
 #ifdef CONFIG_GICV3
     /* GIC V3 addressing */
     /* List of contiguous occupied by the redistributors */
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSV-0001Np-Ih; Wed, 15 Apr 2020 01:03:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSU-0001Mm-Gh
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:18 +0000
X-Inumbo-ID: da98d66e-7eb4-11ea-b4f4-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id da98d66e-7eb4-11ea-b4f4-bc764e2007e4;
 Wed, 15 Apr 2020 01:03:01 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 2166920774;
 Wed, 15 Apr 2020 01:03:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912581;
 bh=ISak1Imoj+Ly2asoLD52bHxG9S9gcN2rOOIhbYo1CLs=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=biYVLT8sFYsz1xY5aBEJJzLGhQcM1Mnhjtv1e9WY807HLywbMTeqCCZ7XfDNJI0Oh
 dRWuihqa/IpTAlnVaaMMB+YRfVJpnpwepiLH21vCPl/qLop+EsVl3ExQjbvOUlU+zT
 WNf+vYrA6H76LVIRyXX2hWuZldAJaXOeCi5PUA2E=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 10/12] xen/arm: if is_domain_direct_mapped use native UART
 address for vPL011
Date: Tue, 14 Apr 2020 18:02:53 -0700
Message-Id: <20200415010255.10081-10-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr_Babchuk@epam.com, sstabellini@kernel.org, julien@xen.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We always use a fix address to map the vPL011 to domains. The address
could be a problem for domains that are directly mapped.

Instead, for domains that are directly mapped, reuse the address of the
physical UART on the platform to avoid potential clashes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
---
 xen/arch/arm/domain_build.c  | 13 ++++++++-----
 xen/arch/arm/vpl011.c        | 12 +++++++++---
 xen/include/asm-arm/domain.h |  1 +
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index beec0a144c..9bc0b810a7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1768,8 +1768,11 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
     gic_interrupt_t intr;
     __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
     __be32 *cells;
+    struct domain *d = kinfo->d;
+    char buf[27];
 
-    res = fdt_begin_node(fdt, "sbsa-uart@"__stringify(GUEST_PL011_BASE));
+    snprintf(buf, sizeof(buf), "sbsa-uart@%"PRIx64, d->arch.vpl011_addr);
+    res = fdt_begin_node(fdt, buf);
     if ( res )
         return res;
 
@@ -1779,7 +1782,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
 
     cells = &reg[0];
     dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS,
-                       GUEST_ROOT_SIZE_CELLS, GUEST_PL011_BASE,
+                       GUEST_ROOT_SIZE_CELLS, d->arch.vpl011_addr,
                        GUEST_PL011_SIZE);
 
     res = fdt_property(fdt, "reg", reg, sizeof(reg));
@@ -2524,6 +2527,9 @@ static int __init construct_domU(struct domain *d,
         reserve_memory_11(d, &kinfo, &banks[0], i);
     }
 
+    if ( kinfo.vpl011 )
+        rc = domain_vpl011_init(d, NULL);
+
     rc = prepare_dtb_domU(d, &kinfo);
     if ( rc < 0 )
         return rc;
@@ -2532,9 +2538,6 @@ static int __init construct_domU(struct domain *d,
     if ( rc < 0 )
         return rc;
 
-    if ( kinfo.vpl011 )
-        rc = domain_vpl011_init(d, NULL);
-
     return rc;
 }
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 895f436cc4..44173a76fd 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -347,7 +347,7 @@ static int vpl011_mmio_read(struct vcpu *v,
                             void *priv)
 {
     struct hsr_dabt dabt = info->dabt;
-    uint32_t vpl011_reg = (uint32_t)(info->gpa - GUEST_PL011_BASE);
+    uint32_t vpl011_reg = (uint32_t)(info->gpa - v->domain->arch.vpl011_addr);
     struct vpl011 *vpl011 = &v->domain->arch.vpl011;
     struct domain *d = v->domain;
     unsigned long flags;
@@ -430,7 +430,7 @@ static int vpl011_mmio_write(struct vcpu *v,
                              void *priv)
 {
     struct hsr_dabt dabt = info->dabt;
-    uint32_t vpl011_reg = (uint32_t)(info->gpa - GUEST_PL011_BASE);
+    uint32_t vpl011_reg = (uint32_t)(info->gpa - v->domain->arch.vpl011_addr);
     struct vpl011 *vpl011 = &v->domain->arch.vpl011;
     struct domain *d = v->domain;
     unsigned long flags;
@@ -622,10 +622,16 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
 {
     int rc;
     struct vpl011 *vpl011 = &d->arch.vpl011;
+    const struct vuart_info *uart = serial_vuart_info(SERHND_DTUART);
 
     if ( vpl011->backend.dom.ring_buf )
         return -EINVAL;
 
+    if ( is_domain_direct_mapped(d) && uart != NULL )
+        d->arch.vpl011_addr = uart->base_addr;
+    else
+        d->arch.vpl011_addr = GUEST_PL011_BASE;
+
     /*
      * info is NULL when the backend is in Xen.
      * info is != NULL when the backend is in a domain.
@@ -673,7 +679,7 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
     spin_lock_init(&vpl011->lock);
 
     register_mmio_handler(d, &vpl011_mmio_handler,
-                          GUEST_PL011_BASE, GUEST_PL011_SIZE, NULL);
+                          d->arch.vpl011_addr, GUEST_PL011_SIZE, NULL);
 
     return 0;
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 7a498921bf..52741895c8 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -100,6 +100,7 @@ struct arch_domain
 #endif
 
     bool direct_map;
+    paddr_t vpl011_addr;
 }  __cacheline_aligned;
 
 struct arch_xen_dom_flags
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSX-0001QG-VG; Wed, 15 Apr 2020 01:03:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSW-0001OQ-5o
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:20 +0000
X-Inumbo-ID: da691cc6-7eb4-11ea-89ec-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id da691cc6-7eb4-11ea-89ec-12813bfff9fa;
 Wed, 15 Apr 2020 01:03:01 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id BC7CD2078B;
 Wed, 15 Apr 2020 01:03:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912581;
 bh=Lmbmicx/WeDeC0BE2JzU8fS5QlIfGd8kH2D1wqE2U5A=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=LJPUFIKBgND+ioK8OLEosJp2bpg2BbKzFmwLRUAwE5Uvv8T6MTQs+28V79gFgNLEN
 Mr3ixv0GaRnMnPAAdgnxsLggRUxZhT5q6IyfKzgHumUa5oeOXMlq1z+20/vRZZKXEq
 NUu03aghfahwoEshb+RapkcW9Mgi0L8Cqr4UYZPA=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 09/12] xen/arm: if is_domain_direct_mapped use native
 addresses for GICv3
Date: Tue, 14 Apr 2020 18:02:52 -0700
Message-Id: <20200415010255.10081-9-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr_Babchuk@epam.com, sstabellini@kernel.org, julien@xen.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Today we use native addresses to map the GICv3 for Dom0 and fixed
addresses for DomUs.

This patch changes the behavior so that native addresses are used for
any domain that is_domain_direct_mapped. The patch has to introduce one
#ifndef CONFIG_NEW_VGIC because the new vgic doesn't support GICv3.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
---
 xen/arch/arm/domain_build.c | 12 +++++++++---
 xen/arch/arm/vgic-v3.c      | 18 ++++++++++++++----
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 303bee60f6..beec0a144c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1697,8 +1697,12 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
     int res = 0;
     __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
     __be32 *cells;
+    struct domain *d = kinfo->d;
+    char buf[38];
 
-    res = fdt_begin_node(fdt, "interrupt-controller@"__stringify(GUEST_GICV3_GICD_BASE));
+    snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIx64,
+             d->arch.vgic.dbase);
+    res = fdt_begin_node(fdt, buf);
     if ( res )
         return res;
 
@@ -1720,9 +1724,11 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
 
     cells = &reg[0];
     dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
-                       GUEST_GICV3_GICD_BASE, GUEST_GICV3_GICD_SIZE);
+                       d->arch.vgic.dbase, GUEST_GICV3_GICD_SIZE);
+#if defined(CONFIG_GICV3) && !defined(CONFIG_NEW_VGIC)
     dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
-                       GUEST_GICV3_GICR0_BASE, GUEST_GICV3_GICR0_SIZE);
+                       d->arch.vgic.rdist_regions[0].base, GUEST_GICV3_GICR0_SIZE);
+#endif
 
     res = fdt_property(fdt, "reg", reg, sizeof(reg));
     if (res)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4e60ba15cc..4cf430f865 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1677,13 +1677,25 @@ static int vgic_v3_domain_init(struct domain *d)
      * Domain 0 gets the hardware address.
      * Guests get the virtual platform layout.
      */
-    if ( is_hardware_domain(d) )
+    if ( is_domain_direct_mapped(d) )
     {
         unsigned int first_cpu = 0;
+        unsigned int nr_rdist_regions;
 
         d->arch.vgic.dbase = vgic_v3_hw.dbase;
 
-        for ( i = 0; i < vgic_v3_hw.nr_rdist_regions; i++ )
+        if ( is_hardware_domain(d) )
+        {
+            nr_rdist_regions = vgic_v3_hw.nr_rdist_regions;
+            d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
+        }
+        else
+        {
+            nr_rdist_regions = 1;
+            d->arch.vgic.intid_bits = 10;
+        }
+
+        for ( i = 0; i < nr_rdist_regions; i++ )
         {
             paddr_t size = vgic_v3_hw.regions[i].size;
 
@@ -1706,8 +1718,6 @@ static int vgic_v3_domain_init(struct domain *d)
          * exposing unused region as they will not get emulated.
          */
         d->arch.vgic.nr_regions = i + 1;
-
-        d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
     }
     else
     {
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSa-0001Sx-Cb; Wed, 15 Apr 2020 01:03:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSZ-0001Rz-Gx
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:23 +0000
X-Inumbo-ID: db025530-7eb4-11ea-b58d-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id db025530-7eb4-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 01:03:02 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id CAF3D20787;
 Wed, 15 Apr 2020 01:03:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912582;
 bh=xC9W/4oLDuoIZtmDlnuiRW23B9RMI1gQZH5SwKKFaVk=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=0dp9DHp2jHw/sPPiaFpgucYy8LGFeesqq+1J5QFa+9mJbTH3HX1/zXFi1nFXnH1mv
 dD96TMTIU9TE94LmUXVRhDyWrAIUvn8CN8lr6Hn5ZKA2mZv6DgiWEhbQZp2q9qP7DY
 nqQ7EwTkgPUDPqFyGceQyYup5IjABiKr/SFJSF4Y=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 12/12] xen/arm: call iomem_permit_access for passthrough
 devices
Date: Tue, 14 Apr 2020 18:02:55 -0700
Message-Id: <20200415010255.10081-12-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr_Babchuk@epam.com, sstabellini@kernel.org, julien@xen.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

iomem_permit_access should be called for MMIO regions of devices
assigned to a domain. Currently it is not called for MMIO regions of
passthrough devices of Dom0less guests. This patch fixes it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
---
 xen/arch/arm/domain_build.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d0fc497d07..d3d42eef5d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1846,6 +1846,17 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
             return -EINVAL;
         }
 
+        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
+                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
+        if ( res )
+        {
+            printk(XENLOG_ERR "Unable to permit to dom%d access to"
+                   " 0x%"PRIx64" - 0x%"PRIx64"\n",
+                   kinfo->d->domain_id,
+                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
+            return res;
+        }
+
         res = map_regions_p2mt(kinfo->d,
                                gaddr_to_gfn(gstart),
                                PFN_DOWN(size),
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 01:03:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 01:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOWSc-0001Vj-PU; Wed, 15 Apr 2020 01:03:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NGac=57=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jOWSb-0001Ty-51
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 01:03:25 +0000
X-Inumbo-ID: da691cc7-7eb4-11ea-89ec-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id da691cc7-7eb4-11ea-89ec-12813bfff9fa;
 Wed, 15 Apr 2020 01:03:02 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 710A020936;
 Wed, 15 Apr 2020 01:03:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586912581;
 bh=M3mtuPpEn22GeE50cx6N0881izwzd4quzv104vMzFfg=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=Y4Bds0ycsmoxzcYjuu7OsHu5scVsagsNNWhTxdJxA3UzS4VXkzQVX1gtf16K+pT0C
 EujAoCXu6f9tdHNkM1m3eLInwHaT1nfmtJzch8OE57qrxMvXxuk6AxUuFyDVwaIA6v
 dzCI8ezkbrBcBrKW4e2RlvikiZL7jpamaOvpcidQ=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 11/12] xen/arm: if xen_force don't try to setup the IOMMU
Date: Tue, 14 Apr 2020 18:02:54 -0700
Message-Id: <20200415010255.10081-11-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr_Babchuk@epam.com, sstabellini@kernel.org, julien@xen.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

If xen_force (which means xen,force-assign-without-iommu was requested)
don't try to add the device to the IOMMU. Return early instead.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
---
 xen/arch/arm/domain_build.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9bc0b810a7..d0fc497d07 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1884,12 +1884,14 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
     if ( res < 0 )
         return res;
 
+    if ( xen_force )
+        return 0;
+
     res = iommu_add_dt_device(node);
     if ( res < 0 )
         return res;
 
-    /* If xen_force, we allow assignment of devices without IOMMU protection. */
-    if ( xen_force && !dt_device_is_protected(node) )
+    if ( !dt_device_is_protected(node) )
         return 0;
 
     return iommu_assign_dt_device(kinfo->d, node);
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 06:14:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 06:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jObJ6-0003Dt-7e; Wed, 15 Apr 2020 06:13:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jObJ4-0003Do-Hw
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 06:13:54 +0000
X-Inumbo-ID: 46fcf879-7ee0-11ea-8a06-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 46fcf879-7ee0-11ea-8a06-12813bfff9fa;
 Wed, 15 Apr 2020 06:13:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 60361AC6D;
 Wed, 15 Apr 2020 06:13:50 +0000 (UTC)
Subject: Re: [PATCH v2 1/5] x86/shim: map and unmap page tables in
 replace_va_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <7638095024ec3379a8d9ddadfe47e36da168e4dd.1586352238.git.hongyxia@amazon.com>
 <ddbad9f5-307e-7b1d-0cc7-cd7ed684f680@suse.com>
 <aacb942aa6febd13211ca799a6456adf510cee89.camel@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <28057880-89fa-0567-0fff-3ee7d8ba0550@suse.com>
Date: Wed, 15 Apr 2020 08:13:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <aacb942aa6febd13211ca799a6456adf510cee89.camel@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 18:53, Hongyan Xia wrote:
> On Thu, 2020-04-09 at 11:42 +0200, Jan Beulich wrote:
>> On 08.04.2020 15:36, Hongyan Xia wrote:
>>> --- a/xen/arch/x86/pv/shim.c
>>> +++ b/xen/arch/x86/pv/shim.c
>>> @@ -168,16 +168,17 @@ const struct platform_bad_page *__init
>>> pv_shim_reserved_pages(unsigned int *size
>>>  static void __init replace_va_mapping(struct domain *d,
>>> l4_pgentry_t *l4start,
>>>                                        unsigned long va, mfn_t mfn)
>>>  {
>>> -    l4_pgentry_t *pl4e = l4start + l4_table_offset(va);
>>> -    l3_pgentry_t *pl3e = l4e_to_l3e(*pl4e) + l3_table_offset(va);
>>> -    l2_pgentry_t *pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(va);
>>> -    l1_pgentry_t *pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(va);
>>> +    l4_pgentry_t l4e = l4start[l4_table_offset(va)];
>>> +    l3_pgentry_t l3e = l3e_from_l4e(l4e, l3_table_offset(va));
>>> +    l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(va));
>>> +    l1_pgentry_t *pl1e = map_l1t_from_l2e(l2e) +
>>> l1_table_offset(va);
>>>      struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e));
>>>  
>>>      put_page_and_type(page);
>>>  
>>>      *pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT
>>>                                                        :
>>> COMPAT_L1_PROT));
>>> +    UNMAP_DOMAIN_PAGE(pl1e);
>>>  }
>>
>> As said before, here and below I think it should be
>> unmap_domain_page().
>>
>>> --- a/xen/include/asm-x86/page.h
>>> +++ b/xen/include/asm-x86/page.h
>>> @@ -196,6 +196,19 @@ static inline l4_pgentry_t
>>> l4e_from_paddr(paddr_t pa, unsigned int flags)
>>>  #define map_l2t_from_l3e(x)        (l2_pgentry_t
>>> *)map_domain_page(l3e_get_mfn(x))
>>>  #define map_l3t_from_l4e(x)        (l3_pgentry_t
>>> *)map_domain_page(l4e_get_mfn(x))
>>>  
>>> +/* Unlike lYe_to_lXe(), lXe_from_lYe() do not rely on the direct
>>> map. */
>>> +#define l2e_from_l3e(l3e, offset) ({                        \
>>> +        const l2_pgentry_t *l2t = map_l2t_from_l3e(l3e);    \
>>> +        l2_pgentry_t l2e = l2t[offset];                     \
>>> +        UNMAP_DOMAIN_PAGE(l2t);                             \
>>> +        l2e; })
>>> +
>>> +#define l3e_from_l4e(l4e, offset) ({                        \
>>> +        const l3_pgentry_t *l3t = map_l3t_from_l4e(l4e);    \
>>> +        l3_pgentry_t l3e = l3t[offset];                     \
>>> +        UNMAP_DOMAIN_PAGE(l3t);                             \
>>> +        l3e; })
>>
>> I think l1e_from_l2e() should be introduced at the same time, even
>> if for now it's unused. I also think, like we do elsewhere, that
>> macro-local variables would better have _ suffixes, to avoid
>> possible variable aliasing issues.
> 
> Shall I address the comments and send a new rev now, or is this small
> series still being reviewed?

I didn't get to look at patches 2 thru 5 yet, if this (partly)
answers the question.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 06:23:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 06:23:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jObS7-00049C-Bj; Wed, 15 Apr 2020 06:23:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jObS5-000497-O9
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 06:23:13 +0000
X-Inumbo-ID: 935d6d1e-7ee1-11ea-8a07-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 935d6d1e-7ee1-11ea-8a07-12813bfff9fa;
 Wed, 15 Apr 2020 06:23:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id AC739AC6D;
 Wed, 15 Apr 2020 06:23:07 +0000 (UTC)
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200410164942.9747-1-sstabellini@kernel.org>
 <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
 <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <707a1448-be1d-0aa8-6b11-a33eb247304f@suse.com>
Date: Wed, 15 Apr 2020 08:23:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, julien@xen.org, konrad.wilk@oracle.com,
 andrew.cooper3@citrix.com, george.dunlap@citrix.com,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 18:54, Stefano Stabellini wrote:
> On Tue, 14 Apr 2020, Jan Beulich wrote:
>> On 10.04.2020 18:49, Stefano Stabellini wrote:
>>> Create a new document under docs/process to describe our special tags.
>>> For now, only add the new backport tag.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
>>> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>>> Acked-by: Wei Liu <wl@xen.org>
>>> CC: jbeulich@suse.com
>>> CC: george.dunlap@citrix.com
>>> CC: julien@xen.org
>>> CC: lars.kurth@citrix.com
>>> CC: andrew.cooper3@citrix.com
>>> CC: konrad.wilk@oracle.com
>>>
>>> ---
>>>
>>> This is the original thread: https://marc.info/?l=xen-devel&m=157324027614941
>>>
>>> The backport tag was agreed upon.
>>
>> Well, sort of.
>>
>>> George requested the file to be
>>> renamed to something more generic, where we could add more information
>>> later.
>>>
>>> I kept the original content and acked-by. I renamed the file to
>>> tags.pandoc.
>>> ---
>>>  docs/process/tags.pandoc | 23 +++++++++++++++++++++++
>>>  1 file changed, 23 insertions(+)
>>>  create mode 100644 docs/process/tags.pandoc
>>>
>>> diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
>>> new file mode 100644
>>> index 0000000000..e570efdcc8
>>> --- /dev/null
>>> +++ b/docs/process/tags.pandoc
>>> @@ -0,0 +1,23 @@
>>> +Backport Tag
>>> +------------
>>> +
>>> +A backport tag is an optional tag in the commit message to request a
>>> +given commit to be backported to the stable trees:
>>
>> Insert "fully maintained"?
> 
> Yep I'll add.
> 
> 
>>> +    Backport: all
>>> +
>>> +It marks a commit for being a candidate for backports to all relevant
>>> +trees.
>>
>> I'm unconvinced of the utility of this form - what "all" resolves to
>> changes over time. There's almost always a first version where a
>> particular issue was introduced. If we want this to be generally
>> useful, imo we shouldn't limit the scope of the tag to the upstream
>> maintained stable trees.
> 
> The reason why I suggested also to have a "wildcard" version of this
> tag, is that the person adding the tag (could be the contributor trying
> to be helpful) might not know exactly to which stable trees the patch
> should be backported to.
> 
> Writing this sentence, I realize that I really meant "any" rather than
> "all". Would you prefer if I used "any"? Or we could even suggest to leave
> it black like this:
> 
>   Backport:
> 
> But it looks a bit weird.

Indeed. Instead of "all" or "any", how about "yes", "unspecified", or
"unknown"? Nevertheless, I still think people asking for a backport
should be nudged towards determining the applicable range; them not
doing so effectively pushes the burden to the general maintainers or
the stable tree ones, both of which scales less well. Omitting the
tag if they don't want to invest the time would to me then seem to
be the cleanest alternative. Albeit I'm sure views here will vary.

>>> +    Backport: 4.9+
>>> +
>>> +It marks a commit for being a candidate for backports to all stable
>>> +trees from 4.9 onward.
>>> +
>>> +Maintainers request the Backport tag to be added on commit.
>>> +Contributors are also welcome to mark their patches with the Backport
>>> +tag when they deem appropriate. Maintainers will request for it to be
>>> +removed when that is not the case.
>>> +
>>> +Please note that the Backport tag is a **request** for backport, which
>>> +will still need to be evaluated by the stable tree maintainers.
>>
>> Now that we see more widespread use of the Fixes: tag, with there
>> being effectively some overlap between the information conveyed I
>> think there should be some mention of this. Not the least there's the
>> risk of the Backport: one to become stale when a flaky commit gets
>> backported - the Fixes: tag doesn't have this issue.
> 
> Yes, that's true, but "Fixes" cannot always be used. I can add a
> statement like: "When possible use the Fixes tag."

Yes please.

> Also, I can pull in the description of Fixes and add it to this file
> too.

This would be much appreciated.

> Fixes tag
> ---------
> 
> If your patch fixes a bug in a specific commit, e.g. you found an issue using
> ``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
> the SHA-1 ID, and the one line summary.  Do not split the tag across multiple
> lines, tags are exempt from the "wrap at 75 columns" rule in order to simplify
> parsing scripts.

I think this non-splitting rule, being applicable to all tags, might better
live prominently at the top of the file.

Jan

>  For example::
> 
> 	Fixes: 41548c5472a "mem_sharing: VM forking"
> 
> The following ``git config`` settings can be used to add a pretty format for
> outputting the above style in the ``git log`` or ``git show`` commands::
> 
> 	[core]
> 		abbrev = 12
> 	[pretty]
> 		fixes = Fixes: %h (\"%s\")
> 



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 06:57:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 06:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jObzE-0006iM-By; Wed, 15 Apr 2020 06:57:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jObzD-0006iH-3S
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 06:57:27 +0000
X-Inumbo-ID: 5d081eee-7ee6-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5d081eee-7ee6-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 06:57:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0402CAC6D;
 Wed, 15 Apr 2020 06:57:23 +0000 (UTC)
Subject: Re: [XEN PATCH v3] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <758e3427f147ed82774edcbbe80b0b29c812e6e4.1586862721.git.havanur@amazon.com>
 <3926fb02-2058-6e3a-6dcd-3ac5c4b97de5@suse.com>
 <5e86b2bc-2d79-3062-856b-c9babfcc5a16@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <df3f7228-adc7-38ae-7eb0-366575d3c687@suse.com>
Date: Wed, 15 Apr 2020 08:57:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5e86b2bc-2d79-3062-856b-c9babfcc5a16@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Harsha Shamsundara Havanur <havanur@amazon.com>,
 xen-devel@lists.xenproject.org, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 18:26, Andrew Cooper wrote:
> On 14/04/2020 15:12, Jan Beulich wrote:
>> On 14.04.2020 13:12, Harsha Shamsundara Havanur wrote:
>>> --- a/tools/firmware/hvmloader/pci.c
>>> +++ b/tools/firmware/hvmloader/pci.c
>>> @@ -84,6 +84,7 @@ void pci_setup(void)
>>>      uint32_t vga_devfn = 256;
>>>      uint16_t class, vendor_id, device_id;
>>>      unsigned int bar, pin, link, isa_irq;
>>> +    uint8_t pci_devfn_decode_type[256] = {};
>> I'm still waiting for a reply on my v1 comment on the stack
>> consumption of this, suggesting two 256-bit bitmaps instead.
> 
> 256 bytes of stack space isn't something to worry about.  Definitely not
> for the complexity of using bitmaps instead.

Complexity? hvmloader already has an odd partial set of bitmap
manipulation functions. Completing this doesn't seem overly
difficult. And while I agree that 256 bytes of stack space
_alone_ aren't much reason to worry, it is - as almost
always - the accumulation of local variables (over an entire
call tree, which isn't overly deep here) which counts. (Note
how the use of bitmaps would have avoided the truncation bug
that had been introduced into v2(?).)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 07:13:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 07:13:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOcEn-0008Pp-St; Wed, 15 Apr 2020 07:13:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOcEm-0008Pk-4H
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 07:13:32 +0000
X-Inumbo-ID: 9c19d1ac-7ee8-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9c19d1ac-7ee8-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 07:13:30 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 26A1AAC77;
 Wed, 15 Apr 2020 07:13:29 +0000 (UTC)
Subject: Re: [XEN PATCH v4] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: Harsha Shamsundara Havanur <havanur@amazon.com>
References: <4b6c017245698c18b063d156be645b8b633c0a99.1586884502.git.havanur@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <81c7ca01-c272-9114-a5d0-12ca94090eb2@suse.com>
Date: Wed, 15 Apr 2020 09:13:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <4b6c017245698c18b063d156be645b8b633c0a99.1586884502.git.havanur@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14.04.2020 19:15, Harsha Shamsundara Havanur wrote:
> @@ -120,6 +121,11 @@ void pci_setup(void)
>       */
>      bool allow_memory_relocate = 1;
>  
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY
> +            != PCI_COMMAND_MEMORY);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO
> +            != PCI_COMMAND_IO);

This still isn't in line with our default style, you will want eg:

    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY !=
                 PCI_COMMAND_MEMORY);
    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
                 PCI_COMMAND_IO);

> @@ -208,6 +214,20 @@ void pci_setup(void)
>              break;
>          }
>  
> +        /*
> +         * Disable memory and I/O decode,
> +         * It is recommended that BAR programming be done whilst
> +         * decode bits are cleared to avoid incorrect mappings being created,
> +         * when 64-bit memory BAR is programmed first by writing the lower half
> +         * and then the upper half, which first maps to an address under 4G
> +         * replacing any RAM mapped in that address, which is not restored
> +         * back after the upper half is written and PCI memory is correctly
> +         * mapped to its intended high mem address.
> +         */

Please can you bring this comment into shape? The comma on the first
line doesn't fit with the capital letter the second line starts with.
Plus, if you really mean what is now on the second line to start on a
new one, then please also insert a line consisting of just * at the
properly indented position between the two. Additionally there's at
least one line exceeding the 80-chars-per-line limit.

> @@ -289,10 +309,6 @@ void pci_setup(void)
>                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
>          }
>  
> -        /* Enable bus mastering. */
> -        cmd = pci_readw(devfn, PCI_COMMAND);
> -        cmd |= PCI_COMMAND_MASTER;
> -        pci_writew(devfn, PCI_COMMAND, cmd);

The movement of this wants mentioning in the description.

> @@ -526,10 +538,17 @@ void pci_setup(void)
>           * has IO enabled, even if there is no I/O BAR on that
>           * particular device.
>           */
> -        cmd = pci_readw(vga_devfn, PCI_COMMAND);
> -        cmd |= PCI_COMMAND_IO;
> -        pci_writew(vga_devfn, PCI_COMMAND, cmd);
> +        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
>      }
> +
> +    /* Enable bus master, memory and I/O decode. */
> +    for ( devfn = 0; devfn < 256; devfn++ )
> +        if ( pci_devfn_decode_type[devfn] )
> +        {
> +            cmd = pci_readw(devfn, PCI_COMMAND);
> +            cmd |= (PCI_COMMAND_MASTER | pci_devfn_decode_type[devfn]);
> +            pci_writew(devfn, PCI_COMMAND, cmd);
> +        }

This still regresses the setting of MASTER afaict: You only set
that bit now if either IO or MEMORY would also get set. But be
sure to honor the original code not doing the write when vendor/
device IDs are all ones.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 07:24:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 07:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOcPJ-0000uo-69; Wed, 15 Apr 2020 07:24:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+yDq=57=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOcPI-0000uj-Bc
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 07:24:24 +0000
X-Inumbo-ID: 20ca572c-7eea-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 20ca572c-7eea-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 07:24:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=EwCLhx+zDcKiTZwwCptEB8daqqHkD07qhVbRIomPgcY=; b=f4tz+3lhcrco19YC2q93djkOS
 nZOza1ipxo97H21ERYyAZmbPRHbJRUyNjOjBRRbeeUmBkDK9MO3/uVeUECO5x0P0Kj9T2p7EjiZMh
 /GfttaV4Cjvbrc8xr6gAc7w7FgEaRWV6RHu3GCnSYL6hbegGnvff+fqUKiJKrQL8DV7wA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOcPG-0004dd-BV; Wed, 15 Apr 2020 07:24:22 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOcPF-0004tc-VL; Wed, 15 Apr 2020 07:24:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOcPF-0006XR-TH; Wed, 15 Apr 2020 07:24:21 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149648-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149648: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=0dbc112e727f6c17f306c864950bdf83dece5cd5
X-Osstest-Versions-That: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 15 Apr 2020 07:24:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149642
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149642
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149642
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149642
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149642
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149642
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149642
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149642
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149642
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149642
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  0dbc112e727f6c17f306c864950bdf83dece5cd5
baseline version:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3

Last test of basis   149642  2020-04-14 01:51:29 Z    1 days
Testing same since   149648  2020-04-14 13:06:14 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexandru Isaila <aisaila@bitdefender.com>
  Jan Beulich <jbeulich@suse.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   7372466b21..0dbc112e72  0dbc112e727f6c17f306c864950bdf83dece5cd5 -> master


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 07:54:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 07:54:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOcsk-0003QB-VT; Wed, 15 Apr 2020 07:54:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOcsj-0003Q6-50
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 07:54:49 +0000
X-Inumbo-ID: 60c39be6-7eee-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 60c39be6-7eee-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 07:54:48 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 93570ACB0;
 Wed, 15 Apr 2020 07:54:46 +0000 (UTC)
Subject: Re: [PATCH v2 2/5] x86_64/mm: map and unmap page tables in m2p_mapped
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <e8a945defb5a4209d1f10b5f98b16a854a911c5c.1586352238.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <9a9c9d8d-be9d-c6c2-fcb1-335464dde0fd@suse.com>
Date: Wed, 15 Apr 2020 09:54:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e8a945defb5a4209d1f10b5f98b16a854a911c5c.1586352238.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.2020 15:36, Hongyan Xia wrote:
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -129,14 +129,14 @@ static mfn_t alloc_hotadd_mfn(struct mem_hotadd_info *info)
>  static int m2p_mapped(unsigned long spfn)
>  {
>      unsigned long va;
> -    l3_pgentry_t *l3_ro_mpt;
> -    l2_pgentry_t *l2_ro_mpt;
> +    l3_pgentry_t l3e_ro_mpt;
> +    l2_pgentry_t l2e_ro_mpt;

Preferably with the _ro_mpt tags here dropped
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 07:56:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 07:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOctz-0003VP-IN; Wed, 15 Apr 2020 07:56:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOcty-0003VK-5p
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 07:56:06 +0000
X-Inumbo-ID: 8bf45be8-7eee-11ea-8a12-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8bf45be8-7eee-11ea-8a12-12813bfff9fa;
 Wed, 15 Apr 2020 07:56:00 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1AE9CB168;
 Wed, 15 Apr 2020 07:55:59 +0000 (UTC)
Subject: Re: [PATCH v2 3/5] x86_64/mm: map and unmap page tables in
 share_hotadd_m2p_table
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <9bf2df7cfd65eb783afeab7d27b98b1a99233a3c.1586352238.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <aec7763c-df3d-1ee3-9313-37e4c4341aff@suse.com>
Date: Wed, 15 Apr 2020 09:55:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9bf2df7cfd65eb783afeab7d27b98b1a99233a3c.1586352238.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.2020 15:36, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Fetch lYe by mapping and unmapping lXe instead of using the direct map,
> which is now done via the lYe_from_lXe() helpers.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 07:56:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 07:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOcuN-0003YL-Tc; Wed, 15 Apr 2020 07:56:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+FHt=57=kaod.org=clg@srs-us1.protection.inumbo.net>)
 id 1jOcn2-0002ev-WF
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 07:48:57 +0000
X-Inumbo-ID: 8d6eb124-7eed-11ea-8a12-12813bfff9fa
Received: from 10.mo6.mail-out.ovh.net (unknown [87.98.157.236])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8d6eb124-7eed-11ea-8a12-12813bfff9fa;
 Wed, 15 Apr 2020 07:48:54 +0000 (UTC)
Received: from player750.ha.ovh.net (unknown [10.110.171.49])
 by mo6.mail-out.ovh.net (Postfix) with ESMTP id 6261C20B30C
 for <xen-devel@lists.xenproject.org>; Wed, 15 Apr 2020 09:48:53 +0200 (CEST)
Received: from kaod.org (82-64-250-170.subs.proxad.net [82.64.250.170])
 (Authenticated sender: clg@kaod.org)
 by player750.ha.ovh.net (Postfix) with ESMTPSA id A7A48115D0F3D;
 Wed, 15 Apr 2020 07:48:01 +0000 (UTC)
Subject: Re: [PATCH-for-5.1 3/3] hw: Remove unnecessary DEVICE() cast
To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <f4bug@amsat.org>,
 qemu-devel@nongnu.org
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-4-f4bug@amsat.org>
From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= <clg@kaod.org>
Message-ID: <353d0861-7c91-1662-7acf-5bebabaa3a4c@kaod.org>
Date: Wed, 15 Apr 2020 09:47:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200412210954.32313-4-f4bug@amsat.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 13574975176934788083
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrfedvgdduvddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepveorughrihgtpgfnvggpifhorghtvghruceotghlgheskhgrohgurdhorhhgqeenucfkpheptddrtddrtddrtddpkedvrdeigedrvdehtddrudejtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejhedtrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomheptghlgheskhgrohgurdhorhhgpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg
X-Mailman-Approved-At: Wed, 15 Apr 2020 07:56:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 John Snow <jsnow@redhat.com>, Richard Henderson <rth@twiddle.net>,
 =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/12/20 11:09 PM, Philippe Mathieu-Daudé wrote:
> The DEVICE() macro is defined as:
> 
>   #define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)
> 
> Remove unnecessary DEVICE() casts.
> 
> Patch created mechanically using spatch with this script:
> 
>   @@
>   typedef DeviceState;
>   DeviceState *s;
>   @@
>   -   DEVICE(s)
>   +   s
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

For ftgmac100,

Reviewed-by: Cédric Le Goater <clg@kaod.org>

> ---
>  hw/display/artist.c         | 2 +-
>  hw/display/cg3.c            | 2 +-
>  hw/display/sm501.c          | 2 +-
>  hw/display/tcx.c            | 4 ++--
>  hw/display/vga-isa.c        | 2 +-
>  hw/i2c/imx_i2c.c            | 2 +-
>  hw/i2c/mpc_i2c.c            | 2 +-
>  hw/ide/piix.c               | 2 +-
>  hw/misc/macio/pmu.c         | 2 +-
>  hw/net/ftgmac100.c          | 3 +--
>  hw/net/imx_fec.c            | 2 +-
>  hw/nubus/nubus-device.c     | 2 +-
>  hw/pci-host/bonito.c        | 2 +-
>  hw/ppc/spapr.c              | 2 +-
>  hw/sh4/sh_pci.c             | 2 +-
>  hw/xen/xen-legacy-backend.c | 2 +-
>  16 files changed, 17 insertions(+), 18 deletions(-)
> 
> diff --git a/hw/display/artist.c b/hw/display/artist.c
> index 753dbb9a77..7e2a4556bd 100644
> --- a/hw/display/artist.c
> +++ b/hw/display/artist.c
> @@ -1353,7 +1353,7 @@ static void artist_realizefn(DeviceState *dev, Error **errp)
>      s->cursor_height = 32;
>      s->cursor_width = 32;
>  
> -    s->con = graphic_console_init(DEVICE(dev), 0, &artist_ops, s);
> +    s->con = graphic_console_init(dev, 0, &artist_ops, s);
>      qemu_console_resize(s->con, s->width, s->height);
>  }
>  
> diff --git a/hw/display/cg3.c b/hw/display/cg3.c
> index a1ede10394..f7f1c199ce 100644
> --- a/hw/display/cg3.c
> +++ b/hw/display/cg3.c
> @@ -321,7 +321,7 @@ static void cg3_realizefn(DeviceState *dev, Error **errp)
>  
>      sysbus_init_irq(sbd, &s->irq);
>  
> -    s->con = graphic_console_init(DEVICE(dev), 0, &cg3_ops, s);
> +    s->con = graphic_console_init(dev, 0, &cg3_ops, s);
>      qemu_console_resize(s->con, s->width, s->height);
>  }
>  
> diff --git a/hw/display/sm501.c b/hw/display/sm501.c
> index de0ab9d977..2a564889bd 100644
> --- a/hw/display/sm501.c
> +++ b/hw/display/sm501.c
> @@ -1839,7 +1839,7 @@ static void sm501_init(SM501State *s, DeviceState *dev,
>                                  &s->twoD_engine_region);
>  
>      /* create qemu graphic console */
> -    s->con = graphic_console_init(DEVICE(dev), 0, &sm501_ops, s);
> +    s->con = graphic_console_init(dev, 0, &sm501_ops, s);
>  }
>  
>  static const VMStateDescription vmstate_sm501_state = {
> diff --git a/hw/display/tcx.c b/hw/display/tcx.c
> index 76de16e8ea..1fb45b1aab 100644
> --- a/hw/display/tcx.c
> +++ b/hw/display/tcx.c
> @@ -868,9 +868,9 @@ static void tcx_realizefn(DeviceState *dev, Error **errp)
>      sysbus_init_irq(sbd, &s->irq);
>  
>      if (s->depth == 8) {
> -        s->con = graphic_console_init(DEVICE(dev), 0, &tcx_ops, s);
> +        s->con = graphic_console_init(dev, 0, &tcx_ops, s);
>      } else {
> -        s->con = graphic_console_init(DEVICE(dev), 0, &tcx24_ops, s);
> +        s->con = graphic_console_init(dev, 0, &tcx24_ops, s);
>      }
>      s->thcmisc = 0;
>  
> diff --git a/hw/display/vga-isa.c b/hw/display/vga-isa.c
> index 0633ed382c..3aaeeeca1e 100644
> --- a/hw/display/vga-isa.c
> +++ b/hw/display/vga-isa.c
> @@ -74,7 +74,7 @@ static void vga_isa_realizefn(DeviceState *dev, Error **errp)
>                                          0x000a0000,
>                                          vga_io_memory, 1);
>      memory_region_set_coalescing(vga_io_memory);
> -    s->con = graphic_console_init(DEVICE(dev), 0, s->hw_ops, s);
> +    s->con = graphic_console_init(dev, 0, s->hw_ops, s);
>  
>      memory_region_add_subregion(isa_address_space(isadev),
>                                  VBE_DISPI_LFB_PHYSICAL_ADDRESS,
> diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
> index 30b9aea247..2e02e1c4fa 100644
> --- a/hw/i2c/imx_i2c.c
> +++ b/hw/i2c/imx_i2c.c
> @@ -305,7 +305,7 @@ static void imx_i2c_realize(DeviceState *dev, Error **errp)
>                            IMX_I2C_MEM_SIZE);
>      sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->iomem);
>      sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->irq);
> -    s->bus = i2c_init_bus(DEVICE(dev), NULL);
> +    s->bus = i2c_init_bus(dev, NULL);
>  }
>  
>  static void imx_i2c_class_init(ObjectClass *klass, void *data)
> diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
> index 0aa1be3ce7..9a724f3a3e 100644
> --- a/hw/i2c/mpc_i2c.c
> +++ b/hw/i2c/mpc_i2c.c
> @@ -332,7 +332,7 @@ static void mpc_i2c_realize(DeviceState *dev, Error **errp)
>      memory_region_init_io(&i2c->iomem, OBJECT(i2c), &i2c_ops, i2c,
>                            "mpc-i2c", 0x14);
>      sysbus_init_mmio(SYS_BUS_DEVICE(dev), &i2c->iomem);
> -    i2c->bus = i2c_init_bus(DEVICE(dev), "i2c");
> +    i2c->bus = i2c_init_bus(dev, "i2c");
>  }
>  
>  static void mpc_i2c_class_init(ObjectClass *klass, void *data)
> diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> index 3b2de4c312..b402a93636 100644
> --- a/hw/ide/piix.c
> +++ b/hw/ide/piix.c
> @@ -193,7 +193,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev, bool aux)
>              blk_unref(blk);
>          }
>      }
> -    qdev_reset_all(DEVICE(dev));
> +    qdev_reset_all(dev);
>      return 0;
>  }
>  
> diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
> index b8466a4a3f..4b7def9096 100644
> --- a/hw/misc/macio/pmu.c
> +++ b/hw/misc/macio/pmu.c
> @@ -758,7 +758,7 @@ static void pmu_realize(DeviceState *dev, Error **errp)
>  
>      if (s->has_adb) {
>          qbus_create_inplace(&s->adb_bus, sizeof(s->adb_bus), TYPE_ADB_BUS,
> -                            DEVICE(dev), "adb.0");
> +                            dev, "adb.0");
>          s->adb_poll_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL, pmu_adb_poll, s);
>          s->adb_poll_mask = 0xffff;
>          s->autopoll_rate_ms = 20;
> diff --git a/hw/net/ftgmac100.c b/hw/net/ftgmac100.c
> index 041ed21017..25ebee7ec2 100644
> --- a/hw/net/ftgmac100.c
> +++ b/hw/net/ftgmac100.c
> @@ -1035,8 +1035,7 @@ static void ftgmac100_realize(DeviceState *dev, Error **errp)
>      qemu_macaddr_default_if_unset(&s->conf.macaddr);
>  
>      s->nic = qemu_new_nic(&net_ftgmac100_info, &s->conf,
> -                          object_get_typename(OBJECT(dev)), DEVICE(dev)->id,
> -                          s);
> +                          object_get_typename(OBJECT(dev)), dev->id, s);
>      qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
>  }
>  
> diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
> index a35c33683e..7adcc9df65 100644
> --- a/hw/net/imx_fec.c
> +++ b/hw/net/imx_fec.c
> @@ -1323,7 +1323,7 @@ static void imx_eth_realize(DeviceState *dev, Error **errp)
>  
>      s->nic = qemu_new_nic(&imx_eth_net_info, &s->conf,
>                            object_get_typename(OBJECT(dev)),
> -                          DEVICE(dev)->id, s);
> +                          dev->id, s);
>  
>      qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
>  }
> diff --git a/hw/nubus/nubus-device.c b/hw/nubus/nubus-device.c
> index 01ccad9e8e..ffe78a8823 100644
> --- a/hw/nubus/nubus-device.c
> +++ b/hw/nubus/nubus-device.c
> @@ -156,7 +156,7 @@ void nubus_register_rom(NubusDevice *dev, const uint8_t *rom, uint32_t size,
>  
>  static void nubus_device_realize(DeviceState *dev, Error **errp)
>  {
> -    NubusBus *nubus = NUBUS_BUS(qdev_get_parent_bus(DEVICE(dev)));
> +    NubusBus *nubus = NUBUS_BUS(qdev_get_parent_bus(dev));
>      NubusDevice *nd = NUBUS_DEVICE(dev);
>      char *name;
>      hwaddr slot_offset;
> diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
> index cc6545c8a8..f212796044 100644
> --- a/hw/pci-host/bonito.c
> +++ b/hw/pci-host/bonito.c
> @@ -606,7 +606,7 @@ static void bonito_pcihost_realize(DeviceState *dev, Error **errp)
>      BonitoState *bs = BONITO_PCI_HOST_BRIDGE(dev);
>  
>      memory_region_init(&bs->pci_mem, OBJECT(dev), "pci.mem", BONITO_PCILO_SIZE);
> -    phb->bus = pci_register_root_bus(DEVICE(dev), "pci",
> +    phb->bus = pci_register_root_bus(dev, "pci",
>                                       pci_bonito_set_irq, pci_bonito_map_irq,
>                                       dev, &bs->pci_mem, get_system_io(),
>                                       0x28, 32, TYPE_PCI_BUS);
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 9a2bd501aa..3337f5e79c 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -4031,7 +4031,7 @@ static void spapr_phb_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
>      /* hotplug hooks should check it's enabled before getting this far */
>      assert(drc);
>  
> -    spapr_drc_attach(drc, DEVICE(dev), &local_err);
> +    spapr_drc_attach(drc, dev, &local_err);
>      if (local_err) {
>          error_propagate(errp, local_err);
>          return;
> diff --git a/hw/sh4/sh_pci.c b/hw/sh4/sh_pci.c
> index 08f2fc1dde..0a3e86f949 100644
> --- a/hw/sh4/sh_pci.c
> +++ b/hw/sh4/sh_pci.c
> @@ -129,7 +129,7 @@ static void sh_pci_device_realize(DeviceState *dev, Error **errp)
>      for (i = 0; i < 4; i++) {
>          sysbus_init_irq(sbd, &s->irq[i]);
>      }
> -    phb->bus = pci_register_root_bus(DEVICE(dev), "pci",
> +    phb->bus = pci_register_root_bus(dev, "pci",
>                                       sh_pci_set_irq, sh_pci_map_irq,
>                                       s->irq,
>                                       get_system_memory(),
> diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
> index 4a373b2373..f9d013811a 100644
> --- a/hw/xen/xen-legacy-backend.c
> +++ b/hw/xen/xen-legacy-backend.c
> @@ -705,7 +705,7 @@ int xen_be_init(void)
>  
>      xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
>      qdev_init_nofail(xen_sysdev);
> -    xen_sysbus = qbus_create(TYPE_XENSYSBUS, DEVICE(xen_sysdev), "xen-sysbus");
> +    xen_sysbus = qbus_create(TYPE_XENSYSBUS, xen_sysdev, "xen-sysbus");
>      qbus_set_bus_hotplug_handler(xen_sysbus, &error_abort);
>  
>      return 0;
> 



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 07:56:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 07:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOcuO-0003YS-87; Wed, 15 Apr 2020 07:56:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+FHt=57=kaod.org=clg@srs-us1.protection.inumbo.net>)
 id 1jOcn5-0002f1-CO
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 07:48:59 +0000
X-Inumbo-ID: 8ff6d532-7eed-11ea-9e09-bc764e2007e4
Received: from 19.mo7.mail-out.ovh.net (unknown [178.33.251.118])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8ff6d532-7eed-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 07:48:58 +0000 (UTC)
Received: from player794.ha.ovh.net (unknown [10.110.103.23])
 by mo7.mail-out.ovh.net (Postfix) with ESMTP id 3396415C048
 for <xen-devel@lists.xenproject.org>; Wed, 15 Apr 2020 09:48:57 +0200 (CEST)
Received: from kaod.org (82-64-250-170.subs.proxad.net [82.64.250.170])
 (Authenticated sender: clg@kaod.org)
 by player794.ha.ovh.net (Postfix) with ESMTPSA id C91BCE662EB5;
 Wed, 15 Apr 2020 07:48:00 +0000 (UTC)
Subject: Re: [PATCH-for-5.1 1/3] target: Remove unnecessary CPU() cast
To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <f4bug@amsat.org>,
 qemu-devel@nongnu.org
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-2-f4bug@amsat.org>
From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= <clg@kaod.org>
Message-ID: <1a7f2324-4264-e23f-b218-beeb50051cce@kaod.org>
Date: Wed, 15 Apr 2020 09:48:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200412210954.32313-2-f4bug@amsat.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 13576101080511187955
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrfedvgdduvddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepveorughrihgtpgfnvggpifhorghtvghruceotghlgheskhgrohgurdhorhhgqeenucfkpheptddrtddrtddrtddpkedvrdeigedrvdehtddrudejtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejleegrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomheptghlgheskhgrohgurdhorhhgpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg
X-Mailman-Approved-At: Wed, 15 Apr 2020 07:56:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 John Snow <jsnow@redhat.com>, Richard Henderson <rth@twiddle.net>,
 =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/12/20 11:09 PM, Philippe Mathieu-Daudé wrote:
> The CPU() macro is defined as:
> 
>   #define CPU(obj) ((CPUState *)(obj))
> 
> Remove an unnecessary CPU() cast.
> 
> Patch created mechanically using spatch with this script:
> 
>   @@
>   typedef CPUState;
>   CPUState *s;
>   @@
>   -   CPU(s)
>   +   s
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Reviewed-by: Cédric Le Goater <clg@kaod.org>

> ---
>  target/ppc/mmu_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
> index 86c667b094..8972714775 100644
> --- a/target/ppc/mmu_helper.c
> +++ b/target/ppc/mmu_helper.c
> @@ -1820,7 +1820,7 @@ static inline void do_invalidate_BAT(CPUPPCState *env, target_ulong BATu,
>      if (((end - base) >> TARGET_PAGE_BITS) > 1024) {
>          /* Flushing 1024 4K pages is slower than a complete flush */
>          LOG_BATS("Flush all BATs\n");
> -        tlb_flush(CPU(cs));
> +        tlb_flush(cs);
>          LOG_BATS("Flush done\n");
>          return;
>      }
> 



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:09:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOd6k-0005Cb-6A; Wed, 15 Apr 2020 08:09:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Tbih=57=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jOd6i-0005CW-U4
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:09:16 +0000
X-Inumbo-ID: 65cf88e6-7ef0-11ea-83d8-bc764e2007e4
Received: from mail-wr1-x434.google.com (unknown [2a00:1450:4864:20::434])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 65cf88e6-7ef0-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 08:09:15 +0000 (UTC)
Received: by mail-wr1-x434.google.com with SMTP id h26so6561563wrb.7
 for <xen-devel@lists.xenproject.org>; Wed, 15 Apr 2020 01:09:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=fruIXAGEQTGd94ccisu4R0cvxtI5K2GJVStu/u0gz3E=;
 b=TDlPv+AcUFIE2hi7yPchoyD3f+fZ7jRUePlTK7qWBaHcdI0Sk1GtaaVGO9u7ObRdQ0
 516didBfMwKcasiG3zl4Jk39hjeshIEioCozdwCAoX/Z3xYdmrulI4WjJFMj3SDi6ZPx
 c4M5rTWRZSIVl8nJCIzr+UzyhywREJ8EDUmeAkO8lwkZ1eBuoEffNTPN977KLJnQ+MhB
 kGgMKKaevS0nnl8LffvzjHVbs07uldIbDD1WZA0Kkv/cEi9CZSPig2xQwG8lTh10VfUY
 YmgmhOx6Cj8RQJILWw76uhVSnxqN/ghRKXm3Jgz1Ny4fjHqsf6IWRX3lXFsUcuTry+mX
 3yhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=fruIXAGEQTGd94ccisu4R0cvxtI5K2GJVStu/u0gz3E=;
 b=tT0mXk8Blli07MemU+rKUacu0D/nYnBCdbEh01g/uOXNXvl3+qs+WOBiC54pKsMevL
 /jkgOaUcVk62B/PrP2slTCGGbn9q0J5XcQu14h2NKLCc20ZyNHzUwLM496x6UmR6PjxC
 p+biwSoXWX1n/ErTYIE64tb0hXw7VFUA5ZQmddxoXlQZDyCWZVkaym0Ag2Wc6S1KAguE
 SBZiHcHpGAr+r5mW5cDuOA32OPr9mnabnYQGSyvDMqGjO951K7RzZUUZZo7nESt+LhXV
 SW7cHYmJaK9vq3O/GehSZDWait9HuqZc8aRd9Yt3cZzoNCn2SEkvx4POx6WL+CHjCUUz
 Am6w==
X-Gm-Message-State: AGi0PuaejWOCq2Z4erWca6lB6bFCq6zFmuqQiERoIRbLQwxb8NAq96Jh
 xYNSaJduL/+IYEP7kB8zCG4=
X-Google-Smtp-Source: APiQypIR6IITNMggG/0rE4iTa20Cgo468VRjdfdsU+xo+ASWHi7PIHHcBx1BOuFM5MFFTt9mR477kg==
X-Received: by 2002:adf:de8b:: with SMTP id w11mr1058459wrl.48.1586938154948; 
 Wed, 15 Apr 2020 01:09:14 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id x18sm21985707wrs.11.2020.04.15.01.09.13
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 15 Apr 2020 01:09:14 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Juergen Gross'" <jgross@suse.com>,
	<xen-devel@lists.xenproject.org>
References: <20200414155942.3347-1-jgross@suse.com>
In-Reply-To: <20200414155942.3347-1-jgross@suse.com>
Subject: RE: [PATCH] docs: update xenstore migration design document
Date: Wed, 15 Apr 2020 09:09:12 +0100
Message-ID: <002701d612fd$26f1b950$74d52bf0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQFbcicelFd+KtVwoWRd2uUiJ/nPAqlvCwVg
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Juergen Gross
> Sent: 14 April 2020 17:00
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross <jgross@suse.com>; Stefano Stabellini <sstabellini@kernel.org>; Julien Grall
> <julien@xen.org>; Wei Liu <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; Ian Jackson
> <ian.jackson@eu.citrix.com>; George Dunlap <george.dunlap@citrix.com>; Jan Beulich <jbeulich@suse.com>
> Subject: [PATCH] docs: update xenstore migration design document
> 
> In the past there have been several attempts to make Xenstore
> restartable. This requires to transfer the internal Xenstore state to
> the new instance. With the Xenstore migration protocol added recently
> to Xen's documentation a first base has been defined to represent the
> state of Xenstore. This can be expanded a little bit in order to have
> a full state representation which is needed as a first step for live
> updating Xenstore.
> 
> Add some definitions to designs/xenstore-migration.md which are needed
> for live update of xenstored.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  docs/designs/xenstore-migration.md | 90 ++++++++++++++++++++++++++++++++++++--
>  1 file changed, 87 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
> index 6ab351e8fe..09bb4700b4 100644
> --- a/docs/designs/xenstore-migration.md
> +++ b/docs/designs/xenstore-migration.md
> @@ -9,6 +9,10 @@ records must include details of registered xenstore watches as well as
>  content; information that cannot currently be recovered from `xenstored`,
>  and hence some extension to the xenstore protocol[2] will also be required.
> 
> +As a similar set of data is needed for transferring xenstore data from
> +one instance to another when live updating xenstored the same definitions
> +are being used.
> +

That makes sense, but using an external entity to extract the state makes less sense in the context of live update so, going
forward, I suggest dropping the section on extra commands.
Also, we should define a separate 'xenstore domain image format' which can be included as an opaque entity in the migration stream,
in the same way as the qemu save image.

>  The *libxenlight Domain Image Format* specification[3] already defines a
>  record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
>  transferring xenstore data pertaining to the domain directly as it is
> @@ -48,7 +52,10 @@ where type is one of the following values
>  |        | 0x00000001: NODE_DATA                            |
>  |        | 0x00000002: WATCH_DATA                           |
>  |        | 0x00000003: TRANSACTION_DATA                     |
> -|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
> +|        | 0x00000004: TRANSACTION_NODE_DATA                |
> +|        | 0x00000005: GUEST_RING_DATA                      |
> +|        | 0x00000006: DOMAIN_START (live update only)      |
> +|        | 0x00000007 - 0xFFFFFFFF: reserved for future use |
> 
> 
>  and data is one of the record data formats described in the following
> @@ -79,7 +86,7 @@ as follows:
>  +-------------------------------+
>  | perm count (N)                |
>  +-------------------------------+
> -| perm0                         |
> +| perm1                         |
>  +-------------------------------+
>  ...
>  +-------------------------------+
> @@ -93,7 +100,7 @@ as follows:
>  +-------------------------------+
>  ```
> 
> -where perm0..N are formatted as follows:
> +where perm1..N are formatted as follows:
> 
> 
>  ```
> @@ -164,6 +171,83 @@ as follows:
>  where tx_id is the non-zero identifier values of an open transaction.
> 
> 
> +**TRANSACTION_NODE_DATA**
> +
> +
> +Each TRANSACTION_NODE_DATA record specifies a transaction local xenstore
> +node. Its is similar to the NODE_DATA record with the addition of a
> +transaction id:
> +
> +```
> +    0       1       2       3     octet
> ++-------+-------+-------+-------+
> +| TRANSACTION_NODE_DATA         |
> ++-------------------------------+
> +| tx_id                         |
> ++-------------------------------+
> +| path length                   |
> ++-------------------------------+
> +| path data                     |
> +...
> +| pad (0 to 3 octets)           |
> ++-------------------------------+
> +| perm count (N)                |
> ++-------------------------------+
> +| perm1                         |
> ++-------------------------------+
> +...
> ++-------------------------------+
> +| permN                         |
> ++-------------------------------+
> +| value length                  |
> ++-------------------------------+
> +| value data                    |
> +...
> +| pad (0 to 3 octets)           |
> ++-------------------------------+
> +```
> +
> +where perm1..N are formatted as specified in the NODE_DATA record. A perm
> +count of 0 denotes a node having been deleted in the transaction.
> +

Transferring this state means we can presumably drop the TRANSACTION_DATA, since we can infer open transactions from the presence of
these records?

> +
> +**GUEST_RING_DATA**
> +
> +
> +The GUEST_RING_DATA record is used to transfer data which is pending to be
> +written to the guest's xenstore ring buffer. It si formatted as follows:
> +
> +
> +```
> ++-------+-------+-------+-------+
> +| GUEST_RING_DATA               |
> ++-------------------------------+
> +| value length                  |
> ++-------------------------------+
> +| value data                    |
> +...
> +| pad (0 to 3 octets)           |
> ++-------------------------------+
> +```
> +
> +**DOMAIN_START**
> +
> +
> +For live updating xenstored data of multiple domains needs to be transferred.
> +For this purpose the DOMAIN_START record is being used. All records of types
> +other than NODE_DATA always relate to the last DOMAIN_START record in the
> +stream. A DOMAIN_START record just contains a domain-id:

If we define a separate stream format as I suggest above, I'd expect the domain-id to be part of the header.

> +
> +
> +```
> ++-------+-------+-------+-------+
> +| DOMAIN_START                  |
> ++-------------------------------+
> +| domid         | pad           |
> ++-------------------------------+
> +```
> +
> +
>  ### Protocol Extension

As mentioned above, this section ought to be dropped for the moment. We should define the ways in which xenstored should dump state
in various scenarios: e.g. for LU it will likely be serialize to memory (possibly dev/shmem?), for migration/save-restore it will
probably be serialize to fd (socket/file). We should also define how dumping state will be triggered.

  Paul



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:21:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdIb-0006mg-LQ; Wed, 15 Apr 2020 08:21:33 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdIa-0006mb-83
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:21:32 +0000
X-Inumbo-ID: 1bb864d8-7ef2-11ea-8a15-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1bb864d8-7ef2-11ea-8a15-12813bfff9fa;
 Wed, 15 Apr 2020 08:21:30 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B7EC3AD57;
 Wed, 15 Apr 2020 08:21:28 +0000 (UTC)
Subject: [PATCH 0/2] x86: high compat r/o M2P table handling adjustments
To: xen-devel@lists.xenproject.org
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
Date: Wed, 15 Apr 2020 10:21:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Hongyan Xia <hx242@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 julien@xen.org, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While looking at "x86_64/mm: map and unmap page tables in
destroy_compat_m2p_mapping" it occurred to me that the mappings
changed there can be dropped altogether, as can the linear
address range used for this. Note that both patches have only
been lightly tested so far, I guess in particular the 2nd one
may still have issues.

1: x86: drop unnecessary page table walking in compat r/o M2P handling
2: x86: drop high compat r/o M2P table address range

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:22:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:22:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdJk-0006rX-1n; Wed, 15 Apr 2020 08:22:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=X1rp=57=huawei.com=yanaijie@srs-us1.protection.inumbo.net>)
 id 1jOdJi-0006rL-If
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:22:42 +0000
X-Inumbo-ID: 43598486-7ef2-11ea-b58d-bc764e2007e4
Received: from huawei.com (unknown [45.249.212.191])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 43598486-7ef2-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 08:22:39 +0000 (UTC)
Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58])
 by Forcepoint Email with ESMTP id 8FB6EBE898881FBAF5;
 Wed, 15 Apr 2020 16:22:35 +0800 (CST)
Received: from huawei.com (10.175.124.28) by DGGEMS408-HUB.china.huawei.com
 (10.3.19.208) with Microsoft SMTP Server id 14.3.487.0; Wed, 15 Apr 2020
 16:22:25 +0800
From: Jason Yan <yanaijie@huawei.com>
To: <sstabellini@kernel.org>, <linux@armlinux.org.uk>,
 <xen-devel@lists.xenproject.org>, <linux-arm-kernel@lists.infradead.org>,
 <linux-kernel@vger.kernel.org>
Subject: [PATCH] arm/xen: make _xen_start_info static
Date: Wed, 15 Apr 2020 16:48:53 +0800
Message-ID: <20200415084853.5808-1-yanaijie@huawei.com>
X-Mailer: git-send-email 2.21.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.175.124.28]
X-CFilter-Loop: Reflected
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Hulk Robot <hulkci@huawei.com>, Jason Yan <yanaijie@huawei.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Fix the following sparse warning:

arch/arm64/xen/../../arm/xen/enlighten.c:39:19: warning: symbol
'_xen_start_info' was not declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
---
 arch/arm/xen/enlighten.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index dd6804a64f1a..fd4e1ce1daf9 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -36,7 +36,7 @@
 
 #include <linux/mm.h>
 
-struct start_info _xen_start_info;
+static struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL(xen_start_info);
 
-- 
2.21.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:23:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:23:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdKZ-0006xA-Da; Wed, 15 Apr 2020 08:23:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdKY-0006x0-JV
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:23:34 +0000
X-Inumbo-ID: 652b466c-7ef2-11ea-8a15-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 652b466c-7ef2-11ea-8a15-12813bfff9fa;
 Wed, 15 Apr 2020 08:23:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CE157AD78;
 Wed, 15 Apr 2020 08:23:31 +0000 (UTC)
Subject: [PATCH 1/2] x86: drop unnecessary page table walking in compat r/o
 M2P handling
From: Jan Beulich <jbeulich@suse.com>
To: xen-devel@lists.xenproject.org
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
 <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
Message-ID: <61746eff-0033-ccd7-6d77-3aabb8a426c8@suse.com>
Date: Wed, 15 Apr 2020 10:23:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Hongyan Xia <hx242@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 julien@xen.org, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We have a global variable where the necessary L2 table is recorded; no
need to inspect L4 and L3 tables (and this way a few less places will
eventually need adjustment when we want to support 5-level page tables).
Also avoid setting up the L3 entry, as the address range never gets used
anyway (it'll be dropped altogether in a subsequent patch).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -219,9 +219,7 @@ static void destroy_compat_m2p_mapping(s
 {
     unsigned long i, va, rwva, pt_pfn;
     unsigned long smap = info->spfn, emap = info->spfn;
-
-    l3_pgentry_t *l3_ro_mpt;
-    l2_pgentry_t *l2_ro_mpt;
+    l2_pgentry_t *l2_ro_mpt = compat_idle_pg_table_l2;
 
     if ( smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2) )
         return;
@@ -229,12 +227,6 @@ static void destroy_compat_m2p_mapping(s
     if ( emap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2) )
         emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
 
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(HIRO_COMPAT_MPT_VIRT_START)]);
-
-    ASSERT(l3e_get_flags(l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)]) & _PAGE_PRESENT);
-
-    l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)]);
-
     for ( i = smap; i < emap; )
     {
         va = HIRO_COMPAT_MPT_VIRT_START +
@@ -323,7 +315,6 @@ static int setup_compat_m2p_table(struct
     unsigned long i, va, smap, emap, rwva, epfn = info->epfn;
     mfn_t mfn;
     unsigned int n;
-    l3_pgentry_t *l3_ro_mpt = NULL;
     l2_pgentry_t *l2_ro_mpt = NULL;
     int err = 0;
 
@@ -342,13 +333,7 @@ static int setup_compat_m2p_table(struct
     emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
                 ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
 
-    va = HIRO_COMPAT_MPT_VIRT_START +
-         smap * sizeof(*compat_machine_to_phys_mapping);
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
-
-    ASSERT(l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) & _PAGE_PRESENT);
-
-    l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
+    l2_ro_mpt = compat_idle_pg_table_l2;
 
 #define MFN(x) (((x) << L2_PAGETABLE_SHIFT) / sizeof(unsigned int))
 #define CNT ((sizeof(*frame_table) & -sizeof(*frame_table)) / \
@@ -627,16 +612,10 @@ void __init paging_init(void)
 #undef MFN
 
     /* Create user-accessible L2 directory to map the MPT for compat guests. */
-    BUILD_BUG_ON(l4_table_offset(RDWR_MPT_VIRT_START) !=
-                 l4_table_offset(HIRO_COMPAT_MPT_VIRT_START));
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(
-        HIRO_COMPAT_MPT_VIRT_START)]);
     if ( (l2_ro_mpt = alloc_xen_pagetable()) == NULL )
         goto nomem;
     compat_idle_pg_table_l2 = l2_ro_mpt;
     clear_page(l2_ro_mpt);
-    l3e_write(&l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)],
-              l3e_from_paddr(__pa(l2_ro_mpt), __PAGE_HYPERVISOR_RO));
     l2_ro_mpt += l2_table_offset(HIRO_COMPAT_MPT_VIRT_START);
     /* Allocate and map the compatibility mode machine-to-phys table. */
     mpt_size = (mpt_size >> 1) + (1UL << (L2_PAGETABLE_SHIFT - 1));



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:24:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdL0-00070w-Of; Wed, 15 Apr 2020 08:24:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdKz-00070k-Bl
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:24:01 +0000
X-Inumbo-ID: 752adb4a-7ef2-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 752adb4a-7ef2-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 08:24:00 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D606FAC12;
 Wed, 15 Apr 2020 08:23:58 +0000 (UTC)
Subject: [PATCH 2/2] x86: drop high compat r/o M2P table address range
From: Jan Beulich <jbeulich@suse.com>
To: xen-devel@lists.xenproject.org
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
 <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
Message-ID: <520c95ba-f9d0-4260-5426-b450c2310c3c@suse.com>
Date: Wed, 15 Apr 2020 10:23:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Hongyan Xia <hx242@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 julien@xen.org, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Now that we don't properly hook things up into the page tables anymore
we also don't need to set aside an address range. Drop it, using
compat_idle_pg_table_l2[] simply (explicitly) from slot 0.

While doing the re-arrangement, which is accompanied by the dropping or
replacing of some local variables, restrict the scopes of some further
ones at the same time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
TBD: With the changed usage perhaps we want to also rename
     compat_idle_pg_table_l2[] (to e.g. compat_idle_l2_entries[])?

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1454,8 +1454,7 @@ static bool pae_xen_mappings_check(const
 void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d)
 {
     memcpy(&l2t[COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(d)],
-           &compat_idle_pg_table_l2[
-               l2_table_offset(HIRO_COMPAT_MPT_VIRT_START)],
+           compat_idle_pg_table_l2,
            COMPAT_L2_PAGETABLE_XEN_SLOTS(d) * sizeof(*l2t));
 }
 
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -217,9 +217,7 @@ static int share_hotadd_m2p_table(struct
 
 static void destroy_compat_m2p_mapping(struct mem_hotadd_info *info)
 {
-    unsigned long i, va, rwva, pt_pfn;
-    unsigned long smap = info->spfn, emap = info->spfn;
-    l2_pgentry_t *l2_ro_mpt = compat_idle_pg_table_l2;
+    unsigned long i, smap = info->spfn, emap = info->spfn;
 
     if ( smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2) )
         return;
@@ -229,18 +227,19 @@ static void destroy_compat_m2p_mapping(s
 
     for ( i = smap; i < emap; )
     {
-        va = HIRO_COMPAT_MPT_VIRT_START +
-              i * sizeof(*compat_machine_to_phys_mapping);
-        rwva = RDWR_COMPAT_MPT_VIRT_START +
-             i * sizeof(*compat_machine_to_phys_mapping);
-        if ( l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT )
+        unsigned int off = i * sizeof(*compat_machine_to_phys_mapping);
+        l2_pgentry_t *pl2e = compat_idle_pg_table_l2 + l2_table_offset(off);
+
+        if ( l2e_get_flags(*pl2e) & _PAGE_PRESENT )
         {
-            pt_pfn = l2e_get_pfn(l2_ro_mpt[l2_table_offset(va)]);
+            unsigned long pt_pfn = l2e_get_pfn(*pl2e);
+
             if ( hotadd_mem_valid(pt_pfn, info) )
             {
-                destroy_xen_mappings(rwva, rwva +
-                        (1UL << L2_PAGETABLE_SHIFT));
-                l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_empty());
+                unsigned long rwva = RDWR_COMPAT_MPT_VIRT_START + off;
+
+                destroy_xen_mappings(rwva, rwva + (1UL << L2_PAGETABLE_SHIFT));
+                l2e_write(pl2e, l2e_empty());
             }
         }
 
@@ -312,10 +311,9 @@ static void destroy_m2p_mapping(struct m
  */
 static int setup_compat_m2p_table(struct mem_hotadd_info *info)
 {
-    unsigned long i, va, smap, emap, rwva, epfn = info->epfn;
+    unsigned long i, smap, emap, epfn = info->epfn;
     mfn_t mfn;
     unsigned int n;
-    l2_pgentry_t *l2_ro_mpt = NULL;
     int err = 0;
 
     smap = info->spfn & (~((1UL << (L2_PAGETABLE_SHIFT - 2)) -1));
@@ -333,8 +331,6 @@ static int setup_compat_m2p_table(struct
     emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
                 ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
 
-    l2_ro_mpt = compat_idle_pg_table_l2;
-
 #define MFN(x) (((x) << L2_PAGETABLE_SHIFT) / sizeof(unsigned int))
 #define CNT ((sizeof(*frame_table) & -sizeof(*frame_table)) / \
              sizeof(*compat_machine_to_phys_mapping))
@@ -343,13 +339,11 @@ static int setup_compat_m2p_table(struct
 
     for ( i = smap; i < emap; i += (1UL << (L2_PAGETABLE_SHIFT - 2)) )
     {
-        va = HIRO_COMPAT_MPT_VIRT_START +
-              i * sizeof(*compat_machine_to_phys_mapping);
-
-        rwva = RDWR_COMPAT_MPT_VIRT_START +
-                i * sizeof(*compat_machine_to_phys_mapping);
+        unsigned int off = i * sizeof(*compat_machine_to_phys_mapping);
+        l2_pgentry_t *pl2e = compat_idle_pg_table_l2 + l2_table_offset(off);
+        unsigned long rwva = RDWR_COMPAT_MPT_VIRT_START + off;
 
-        if (l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT)
+        if ( l2e_get_flags(*pl2e) & _PAGE_PRESENT )
             continue;
 
         for ( n = 0; n < CNT; ++n)
@@ -366,8 +360,7 @@ static int setup_compat_m2p_table(struct
         /* Fill with INVALID_M2P_ENTRY. */
         memset((void *)rwva, 0xFF, 1UL << L2_PAGETABLE_SHIFT);
         /* NB. Cannot be GLOBAL as the ptes get copied into per-VM space. */
-        l2e_write(&l2_ro_mpt[l2_table_offset(va)],
-                  l2e_from_mfn(mfn, _PAGE_PSE|_PAGE_PRESENT));
+        l2e_write(pl2e, l2e_from_mfn(mfn, _PAGE_PSE|_PAGE_PRESENT));
     }
 #undef CNT
 #undef MFN
@@ -616,7 +609,6 @@ void __init paging_init(void)
         goto nomem;
     compat_idle_pg_table_l2 = l2_ro_mpt;
     clear_page(l2_ro_mpt);
-    l2_ro_mpt += l2_table_offset(HIRO_COMPAT_MPT_VIRT_START);
     /* Allocate and map the compatibility mode machine-to-phys table. */
     mpt_size = (mpt_size >> 1) + (1UL << (L2_PAGETABLE_SHIFT - 1));
     if ( mpt_size > RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START )
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -215,11 +215,8 @@ extern unsigned char boot_edid_info[128]
 /* Slot 261: compatibility machine-to-phys conversion table (1GB). */
 #define RDWR_COMPAT_MPT_VIRT_START VMAP_VIRT_END
 #define RDWR_COMPAT_MPT_VIRT_END (RDWR_COMPAT_MPT_VIRT_START + GB(1))
-/* Slot 261: high read-only compat machine-to-phys conversion table (1GB). */
-#define HIRO_COMPAT_MPT_VIRT_START RDWR_COMPAT_MPT_VIRT_END
-#define HIRO_COMPAT_MPT_VIRT_END (HIRO_COMPAT_MPT_VIRT_START + GB(1))
 /* Slot 261: xen text, static data, bss, per-cpu stubs and executable fixmap (1GB). */
-#define XEN_VIRT_START          (HIRO_COMPAT_MPT_VIRT_END)
+#define XEN_VIRT_START          RDWR_COMPAT_MPT_VIRT_END
 #define XEN_VIRT_END            (XEN_VIRT_START + GB(1))
 
 #ifndef CONFIG_BIGMEM



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:25:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdMU-0007Al-6Q; Wed, 15 Apr 2020 08:25:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdMT-0007Ag-JA
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:25:33 +0000
X-Inumbo-ID: ac53b0b0-7ef2-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ac53b0b0-7ef2-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 08:25:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 633B8AC12;
 Wed, 15 Apr 2020 08:25:31 +0000 (UTC)
Subject: Re: [PATCH v2 4/5] x86_64/mm: map and unmap page tables in
 destroy_compat_m2p_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <881884ac-85cc-0d42-fdf7-cd655da1c5c5@suse.com>
Date: Wed, 15 Apr 2020 10:25:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.2020 15:36, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> 
> ---
> Changed in v2:
> - there is pretty much no point in keeping l3_ro_mpt mapped, just fetch
>   the l3e instead, which also cleans up the code.

Even better, there's no need to do any mapping her at all. I've
posted a pair of patches, the first of which can be seen as a
suggested replacement for the one here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:32:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdT8-00084N-0H; Wed, 15 Apr 2020 08:32:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdT6-00084H-VZ
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:32:25 +0000
X-Inumbo-ID: a1762686-7ef3-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a1762686-7ef3-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 08:32:24 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 97AB4AC12;
 Wed, 15 Apr 2020 08:32:22 +0000 (UTC)
Subject: Re: [PATCH v2 5/5] x86_64/mm: map and unmap page tables in
 destroy_m2p_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <1f6bde6f67ef214a3d4ffa81f0c55c4416c8edd4.1586352238.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <de4656ff-2fcc-2529-5ee9-2772f31e99e2@suse.com>
Date: Wed, 15 Apr 2020 10:32:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1f6bde6f67ef214a3d4ffa81f0c55c4416c8edd4.1586352238.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 08.04.2020 15:36, Hongyan Xia wrote:
> @@ -290,26 +291,30 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
>              continue;
>          }
>  
> -        l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
> -        if (!(l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT))
> +        l2_ro_mpt = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]) +
> +                    l2_table_offset(va);

Either the name of the variable should be changed or you shouldn't
add in l2_table_offset(va) here. Personally I'd go with renaming
to just pl2e.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:35:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:35:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdVt-0008Bq-Hb; Wed, 15 Apr 2020 08:35:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HD5o=57=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jOdVr-0008Bl-UU
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:35:15 +0000
X-Inumbo-ID: 072e8c48-7ef4-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 072e8c48-7ef4-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 08:35:15 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 20D3CABE7;
 Wed, 15 Apr 2020 08:35:13 +0000 (UTC)
Subject: Re: [PATCH] docs: update xenstore migration design document
To: paul@xen.org, xen-devel@lists.xenproject.org
References: <20200414155942.3347-1-jgross@suse.com>
 <002701d612fd$26f1b950$74d52bf0$@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <7c0dcc04-8c55-d59a-65fb-f26251e12c97@suse.com>
Date: Wed, 15 Apr 2020 10:35:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <002701d612fd$26f1b950$74d52bf0$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.20 10:09, Paul Durrant wrote:
>> -----Original Message-----
>> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Juergen Gross
>> Sent: 14 April 2020 17:00
>> To: xen-devel@lists.xenproject.org
>> Cc: Juergen Gross <jgross@suse.com>; Stefano Stabellini <sstabellini@kernel.org>; Julien Grall
>> <julien@xen.org>; Wei Liu <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; Ian Jackson
>> <ian.jackson@eu.citrix.com>; George Dunlap <george.dunlap@citrix.com>; Jan Beulich <jbeulich@suse.com>
>> Subject: [PATCH] docs: update xenstore migration design document
>>
>> In the past there have been several attempts to make Xenstore
>> restartable. This requires to transfer the internal Xenstore state to
>> the new instance. With the Xenstore migration protocol added recently
>> to Xen's documentation a first base has been defined to represent the
>> state of Xenstore. This can be expanded a little bit in order to have
>> a full state representation which is needed as a first step for live
>> updating Xenstore.
>>
>> Add some definitions to designs/xenstore-migration.md which are needed
>> for live update of xenstored.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   docs/designs/xenstore-migration.md | 90 ++++++++++++++++++++++++++++++++++++--
>>   1 file changed, 87 insertions(+), 3 deletions(-)
>>
>> diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
>> index 6ab351e8fe..09bb4700b4 100644
>> --- a/docs/designs/xenstore-migration.md
>> +++ b/docs/designs/xenstore-migration.md
>> @@ -9,6 +9,10 @@ records must include details of registered xenstore watches as well as
>>   content; information that cannot currently be recovered from `xenstored`,
>>   and hence some extension to the xenstore protocol[2] will also be required.
>>
>> +As a similar set of data is needed for transferring xenstore data from
>> +one instance to another when live updating xenstored the same definitions
>> +are being used.
>> +
> 
> That makes sense, but using an external entity to extract the state makes less sense in the context of live update so, going
> forward, I suggest dropping the section on extra commands.

Right, this (if still needed) should rather go to docs/misc/xenstore.txt

> Also, we should define a separate 'xenstore domain image format' which can be included as an opaque entity in the migration stream,
> in the same way as the qemu save image.

Fine with me.

> 
>>   The *libxenlight Domain Image Format* specification[3] already defines a
>>   record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
>>   transferring xenstore data pertaining to the domain directly as it is
>> @@ -48,7 +52,10 @@ where type is one of the following values
>>   |        | 0x00000001: NODE_DATA                            |
>>   |        | 0x00000002: WATCH_DATA                           |
>>   |        | 0x00000003: TRANSACTION_DATA                     |
>> -|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
>> +|        | 0x00000004: TRANSACTION_NODE_DATA                |
>> +|        | 0x00000005: GUEST_RING_DATA                      |
>> +|        | 0x00000006: DOMAIN_START (live update only)      |
>> +|        | 0x00000007 - 0xFFFFFFFF: reserved for future use |
>>
>>
>>   and data is one of the record data formats described in the following
>> @@ -79,7 +86,7 @@ as follows:
>>   +-------------------------------+
>>   | perm count (N)                |
>>   +-------------------------------+
>> -| perm0                         |
>> +| perm1                         |
>>   +-------------------------------+
>>   ...
>>   +-------------------------------+
>> @@ -93,7 +100,7 @@ as follows:
>>   +-------------------------------+
>>   ```
>>
>> -where perm0..N are formatted as follows:
>> +where perm1..N are formatted as follows:
>>
>>
>>   ```
>> @@ -164,6 +171,83 @@ as follows:
>>   where tx_id is the non-zero identifier values of an open transaction.
>>
>>
>> +**TRANSACTION_NODE_DATA**
>> +
>> +
>> +Each TRANSACTION_NODE_DATA record specifies a transaction local xenstore
>> +node. Its is similar to the NODE_DATA record with the addition of a
>> +transaction id:
>> +
>> +```
>> +    0       1       2       3     octet
>> ++-------+-------+-------+-------+
>> +| TRANSACTION_NODE_DATA         |
>> ++-------------------------------+
>> +| tx_id                         |
>> ++-------------------------------+
>> +| path length                   |
>> ++-------------------------------+
>> +| path data                     |
>> +...
>> +| pad (0 to 3 octets)           |
>> ++-------------------------------+
>> +| perm count (N)                |
>> ++-------------------------------+
>> +| perm1                         |
>> ++-------------------------------+
>> +...
>> ++-------------------------------+
>> +| permN                         |
>> ++-------------------------------+
>> +| value length                  |
>> ++-------------------------------+
>> +| value data                    |
>> +...
>> +| pad (0 to 3 octets)           |
>> ++-------------------------------+
>> +```
>> +
>> +where perm1..N are formatted as specified in the NODE_DATA record. A perm
>> +count of 0 denotes a node having been deleted in the transaction.
>> +
> 
> Transferring this state means we can presumably drop the TRANSACTION_DATA, since we can infer open transactions from the presence of
> these records?

No, I don't think so. Imagine a case where just a transaction has
been started without any further activity in this transaction having
happened yet.

> 
>> +
>> +**GUEST_RING_DATA**
>> +
>> +
>> +The GUEST_RING_DATA record is used to transfer data which is pending to be
>> +written to the guest's xenstore ring buffer. It si formatted as follows:
>> +
>> +
>> +```
>> ++-------+-------+-------+-------+
>> +| GUEST_RING_DATA               |
>> ++-------------------------------+
>> +| value length                  |
>> ++-------------------------------+
>> +| value data                    |
>> +...
>> +| pad (0 to 3 octets)           |
>> ++-------------------------------+
>> +```
>> +
>> +**DOMAIN_START**
>> +
>> +
>> +For live updating xenstored data of multiple domains needs to be transferred.
>> +For this purpose the DOMAIN_START record is being used. All records of types
>> +other than NODE_DATA always relate to the last DOMAIN_START record in the
>> +stream. A DOMAIN_START record just contains a domain-id:
> 
> If we define a separate stream format as I suggest above, I'd expect the domain-id to be part of the header.

Yes.

> 
>> +
>> +
>> +```
>> ++-------+-------+-------+-------+
>> +| DOMAIN_START                  |
>> ++-------------------------------+
>> +| domid         | pad           |
>> ++-------------------------------+
>> +```
>> +
>> +
>>   ### Protocol Extension
> 
> As mentioned above, this section ought to be dropped for the moment. We should define the ways in which xenstored should dump state
> in various scenarios: e.g. for LU it will likely be serialize to memory (possibly dev/shmem?), for migration/save-restore it will
> probably be serialize to fd (socket/file). We should also define how dumping state will be triggered.

I was planning to use XS_CONTROL for this purpose. But I'm open for
other solutions, too. And even using XS_CONTROL might want us to
have a library routine for that purpose encapsulating the way how the
extracted state is being transferred.

In the LU case the state dumping will need to be handled Xenstore
internally (especially in stubdom this will just be a memory blob inside
the stubdom, while in the daemon case it could easily be a file).


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:45:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:45:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdfX-0000kr-4s; Wed, 15 Apr 2020 08:45:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdfV-0000km-SL
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:45:13 +0000
X-Inumbo-ID: 6a5fc859-7ef5-11ea-8a18-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6a5fc859-7ef5-11ea-8a18-12813bfff9fa;
 Wed, 15 Apr 2020 08:45:11 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9A2F7AD57;
 Wed, 15 Apr 2020 08:45:09 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH 0/3] xenoprof: XSA-313 follow-up
Message-ID: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
Date: Wed, 15 Apr 2020 10:45:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Patch 1 was considered to become part of the XSA, but it was then
decided against. The other two are a little bit of cleanup, albeit
there's certainly far more room for tidying. Yet then again Paul,
in his mail from Mar 13, was asking whether we shouldn't drop
xenoprof altogether, at which point cleaning up the code would be
wasted effort.

1: adjust ordering of page sharing vs domain type setting
2: drop unused struct xenoprof fields
3: limit scope of types and #define-s

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:45:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:45:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdg1-0000nN-K6; Wed, 15 Apr 2020 08:45:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+yDq=57=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOdfz-0000n8-Ql
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:45:43 +0000
X-Inumbo-ID: 7a3d0e66-7ef5-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7a3d0e66-7ef5-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 08:45:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=bk4Iwq7L/dBevaM/0v6qaxE89bIAjt4TouON1CKfDD0=; b=OWbIBXrV/2VFPuhbl6kY8Pn8u
 XBXXvI6DCaI4IlMez2DWH8N3OR/hkvQOgmVd+UeCkwU87Mum7yzzk8igkS4dgxKko6zpGVCoWaPTR
 3AcinLI/bh9cSmhOZvxO0AfFoVIL3ShDdb2T94XTjmJ6ERYzIwWORqR8kyLR5ohNS2CG4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOdfs-0006kO-Up; Wed, 15 Apr 2020 08:45:36 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOdfs-0007kb-Mu; Wed, 15 Apr 2020 08:45:36 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOdfs-00036a-Lt; Wed, 15 Apr 2020 08:45:36 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149649-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.9-testing test] 149649: tolerable trouble: fail/pass/starved -
 PUSHED
X-Osstest-Failures: xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-localmigrate:fail:allowable
 xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-start/win.repeat:fail:nonblocking
 xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-localmigrate/x10:fail:nonblocking
 xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-localmigrate/x10:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-localmigrate/x10:fail:nonblocking
 xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.9-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.9-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.9-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: xen=45c90737d5f0c8bf479adcd8cb88450f1998e55c
X-Osstest-Versions-That: xen=cf2e9cc0ba0432f05cdca36dcd46be5fdfd7ca0c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 15 Apr 2020 08:45:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigrate fail REGR. vs. 146210

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-ws16-amd64 18 guest-start/win.repeat fail blocked in 146210
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 146097
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 146097
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat    fail  like 146139
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 146210
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 146210
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 146210
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 146210
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx  2 hosts-allocate               starved  n/a

version targeted for testing:
 xen                  45c90737d5f0c8bf479adcd8cb88450f1998e55c
baseline version:
 xen                  cf2e9cc0ba0432f05cdca36dcd46be5fdfd7ca0c

Last test of basis   146210  2020-01-18 02:13:02 Z   88 days
Testing same since   149649  2020-04-14 13:35:25 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 starved 
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   cf2e9cc0ba..45c90737d5  45c90737d5f0c8bf479adcd8cb88450f1998e55c -> stable-4.9


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:50:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdkG-0001Ym-Aq; Wed, 15 Apr 2020 08:50:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Tbih=57=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jOdkF-0001UD-Er
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:50:07 +0000
X-Inumbo-ID: 1ab1409c-7ef6-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x52a.google.com (unknown [2a00:1450:4864:20::52a])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1ab1409c-7ef6-11ea-b4f4-bc764e2007e4;
 Wed, 15 Apr 2020 08:50:06 +0000 (UTC)
Received: by mail-ed1-x52a.google.com with SMTP id w4so3592961edv.13
 for <xen-devel@lists.xenproject.org>; Wed, 15 Apr 2020 01:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=XiZHh3PsZ9aCCUeq41r8dePjo3PdgqgTlNLjjspHWUI=;
 b=PRwthg+VMECmp8hsjrIGpNHmHwiFyf+9cgFttZmtmt7vH6MIwGEWnfISCpYzdmZ5iC
 R7LYYo80ELTsDxYNrouUMSGOa7dJUu4RQbC3QGKE/tY+JUsSu7SkrvnO3t1sz5/+zBoP
 ot5+DY7qPuV85TxlzX4hS8QlgX2dOKnKDVReV4sTqbf88g/5R73j+kurDYOfSxCR0iQe
 7VUkxFp7tbyqRzTJD1H0zXq0Wk6fapqqFlmqn0mV8xu2eHr8bDRJdNTfF91oNbwQLBIE
 r0XsL0qoHqY9slP5srgOPYuEfV578lu7kB9vLnuL7dRH+HVcPNfHm9joN4X/mA3l5AQs
 ip0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=XiZHh3PsZ9aCCUeq41r8dePjo3PdgqgTlNLjjspHWUI=;
 b=nQIDC4AbQ+qlukOX0Ggc9XDflSkT7/Heh6/d1mDvKBozjet8V6QXCmHOkY2kTibVHr
 dpxeitwILJb9vjzf/HSIb/Ca+7EBO3a/BPWSkTZxZpzm4pzBJbnlPYiiALKSA7r9pdSd
 csx2iXKAJoFEx1tOvZ44DNFFp2JBepnL1CRXBjf0KieJIHkBv2JlMNEWYUxcZpU69fMB
 ASDIi715HTi3Z/FP0PPDBlfDRVoHE8yWMimehm9taDtDBLd1gWMWK92qMw4S+RMfXMle
 HjO7TMDXGf9yMIuXCukCR2cITl7Ujtk1Z7aADn76ARbYsoIpLQhc7IKrPqOGVc2tV45D
 OVFg==
X-Gm-Message-State: AGi0PuYKDYWIwD5wx8WMUmQJWsJHAO73LLj5ei2qB84oE90yOJJ2F7Kx
 /D+P14qnEPb0tqng1TA3IMRB4pUFBag=
X-Google-Smtp-Source: APiQypJCA/5uXvQTdRXaVkME/T91gxP8V6S57RyWahfsfYIYeTp6IQE90wwyglYRojgUhMxgCBkKVQ==
X-Received: by 2002:a05:6402:17ad:: with SMTP id
 j13mr23287422edy.46.1586940605927; 
 Wed, 15 Apr 2020 01:50:05 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id x22sm1831787ejb.53.2020.04.15.01.50.04
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 15 Apr 2020 01:50:05 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>,
	<xen-devel@lists.xenproject.org>
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
In-Reply-To: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
Subject: RE: [PATCH 0/3] xenoprof: XSA-313 follow-up
Date: Wed, 15 Apr 2020 09:50:03 +0100
Message-ID: <002801d61302$dbd21950$93764bf0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQKUpBz832WsrmfTrWwwQFYKS8h7/ab8vN2g
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 15 April 2020 09:45
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap =
<george.dunlap@citrix.com>; Ian Jackson
> <ian.jackson@eu.citrix.com>; Julien Grall <julien@xen.org>; Stefano =
Stabellini
> <sstabellini@kernel.org>; Wei Liu <wl@xen.org>; Paul Durrant =
<paul@xen.org>
> Subject: [PATCH 0/3] xenoprof: XSA-313 follow-up
>=20
> Patch 1 was considered to become part of the XSA, but it was then
> decided against. The other two are a little bit of cleanup, albeit
> there's certainly far more room for tidying. Yet then again Paul,
> in his mail from Mar 13, was asking whether we shouldn't drop
> xenoprof altogether, at which point cleaning up the code would be
> wasted effort.
>=20

That's still my opinion. This is a large chunk of (only passively =
maintained) code which I think is of very limited value (since it =
relates to an old tool, and it only works for PV domains).

  Paul



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:53:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:53:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdn5-0001nF-Rk; Wed, 15 Apr 2020 08:53:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdn4-0001nA-Ba
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:53:02 +0000
X-Inumbo-ID: 82f4d664-7ef6-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 82f4d664-7ef6-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 08:53:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9F231AF92;
 Wed, 15 Apr 2020 08:52:59 +0000 (UTC)
Subject: [PATCH 1/3] xenoprof: adjust ordering of page sharing vs domain type
 setting
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
Message-ID: <0a7d6a97-7093-6cec-4c8d-d1ca39e0815e@suse.com>
Date: Wed, 15 Apr 2020 10:52:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Buffer pages should be shared with "ignored" or "active" guests only
(besides, obviously, the primary profiling domain). Hence domain type
should be set to "ignored" before unsharing from the primary domain
(which implies even a previously "passive" domain may then access its
buffers, albeit that's not very useful unless it gets promoted to
"active" subsequently), i.e. such that no further writes of records to
the buffer would occur, and (at least for consistency) also before
sharing it (with the calling domain) from the XENOPROF_get_buffer path.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>

--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -372,8 +372,8 @@ static void reset_passive(struct domain
     if ( x == NULL )
         return;
 
-    unshare_xenoprof_page_with_guest(x);
     x->domain_type = XENOPROF_DOMAIN_IGNORED;
+    unshare_xenoprof_page_with_guest(x);
 }
 
 static void reset_active_list(void)
@@ -654,6 +654,13 @@ static int xenoprof_op_get_buffer(XEN_GU
         if ( ret < 0 )
             return ret;
     }
+    else
+    {
+        d->xenoprof->domain_ready = 0;
+        d->xenoprof->domain_type = XENOPROF_DOMAIN_IGNORED;
+    }
+
+    d->xenoprof->is_primary = (xenoprof_primary_profiler == d);
 
     ret = share_xenoprof_page_with_guest(
         d, virt_to_mfn(d->xenoprof->rawbuf), d->xenoprof->npages);
@@ -662,10 +669,6 @@ static int xenoprof_op_get_buffer(XEN_GU
 
     xenoprof_reset_buf(d);
 
-    d->xenoprof->domain_type  = XENOPROF_DOMAIN_IGNORED;
-    d->xenoprof->domain_ready = 0;
-    d->xenoprof->is_primary   = (xenoprof_primary_profiler == current->domain);
-        
     xenoprof_get_buffer.nbuf = d->xenoprof->nbuf;
     xenoprof_get_buffer.bufsize = d->xenoprof->bufsize;
     if ( !paging_mode_translate(d) )



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:53:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdnB-0001oy-AS; Wed, 15 Apr 2020 08:53:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOdn9-0001og-Kx
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:53:07 +0000
X-Inumbo-ID: 85a7dbea-7ef6-11ea-8a18-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 85a7dbea-7ef6-11ea-8a18-12813bfff9fa;
 Wed, 15 Apr 2020 08:53:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586940786;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=+PGgzijF6Yzl+0XlKliQKwd7r9rXyaW+LoGuU5tOlPo=;
 b=SJrPDPuZdJTUZrA4YFZLvK5+RujFsqCKLYHlKss6HefR6yDfbokOOh+s
 /0usvXFpnOrSdu6xfw9LSWqjTZ4A2Rhg11MD13/I1aizrpxaumY9AjGx1
 jLdcOzSGnieobZlwDd4d6b7q/U2I/p++xX2rsTkJwPq/68NOEYWKYqLS9 k=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 8c7e0A+J1l9bUa/W+hxa5tyRnGRS0j8uaDmS+t3aRFAQB8tCMmllbCQsLdJkUFsVR1bCJ5clpo
 1zVrQYUerCMNser+Y6WrfCK5NqAb31n7SWxHduZBNAkRIH5xZJt1ay2uT+2NG+SY9rhes0sB/T
 QPmakUJCEBAI/0+DiQRTDq09Xu2+9s9jXwWqhjX58JUOG6IzOKRr3hUQbbzLNjo6sMKt3CmqOi
 pmdpu3ZxmIbyEwyAFY36Ekoppzk8QcW4OQ84zVgMtB7XmjPs+aagorb42Z7pBmemygLeJzXokb
 0nU=
X-SBRS: 2.7
X-MesageID: 15684440
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="15684440"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag
Date: Wed, 15 Apr 2020 10:52:45 +0200
Message-ID: <20200415085246.7945-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Check if hosts have SMT based on the number of threads per core. A
value of threads per core different than 0 implies SMT support.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 sg-run-job     |  1 +
 ts-examine-cpu | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)
 create mode 100755 ts-examine-cpu

diff --git a/sg-run-job b/sg-run-job
index 97011843..aa7953ac 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -679,6 +679,7 @@ proc examine-host-examine {install} {
     if {$ok} {
 	run-ts -.  =           ts-examine-serial-post + host
 	run-ts .   =           ts-examine-iommu       + host
+	run-ts .   =           ts-examine-cpu         + host
 	run-ts .   =           ts-examine-logs-save   + host
 	run-ts .   =           ts-examine-hostprops-save
     }
diff --git a/ts-examine-cpu b/ts-examine-cpu
new file mode 100755
index 00000000..98ffab59
--- /dev/null
+++ b/ts-examine-cpu
@@ -0,0 +1,32 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2020 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# 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 Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+BEGIN { unshift @INC, qw(.); }
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+our $info = target_cmd_output_root($ho, 'xl info', 10);
+our $threads = $info =~ s/^threads_per_core\s*:.*\s//;
+
+logm("$ho->{Ident} threads per core: $threads");
+hostflag_putative_record($ho, "smt", !!$threads);
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:53:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdnQ-0001s4-OL; Wed, 15 Apr 2020 08:53:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdnQ-0001rq-0f
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:53:24 +0000
X-Inumbo-ID: 8fec7a52-7ef6-11ea-8a18-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8fec7a52-7ef6-11ea-8a18-12813bfff9fa;
 Wed, 15 Apr 2020 08:53:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 97B8EAF92;
 Wed, 15 Apr 2020 08:53:21 +0000 (UTC)
Subject: [PATCH 2/3] xenoprof: drop unused struct xenoprof fields
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
Message-ID: <0c9daea8-6778-6bf9-2bd7-fe6425efb26e@suse.com>
Date: Wed, 15 Apr 2020 10:53:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Both is_primary and domain_ready are only ever written to. Drop both
fields and restrict structure visibility to just the one involved CU.
While doing so (and just for starters) make "is_compat" properly bool.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -33,6 +33,23 @@ static DEFINE_SPINLOCK(pmu_owner_lock);
 int pmu_owner = 0;
 int pmu_hvm_refcount = 0;
 
+struct xenoprof_vcpu {
+    int event_size;
+    xenoprof_buf_t *buffer;
+};
+
+struct xenoprof {
+    char *rawbuf;
+    int npages;
+    int nbuf;
+    int bufsize;
+    int domain_type;
+#ifdef CONFIG_COMPAT
+    bool is_compat;
+#endif
+    struct xenoprof_vcpu *vcpu;
+};
+
 static struct domain *active_domains[MAX_OPROF_DOMAINS];
 static int active_ready[MAX_OPROF_DOMAINS];
 static unsigned int adomains;
@@ -259,7 +276,6 @@ static int alloc_xenoprof_struct(
     d->xenoprof->npages = npages;
     d->xenoprof->nbuf = nvcpu;
     d->xenoprof->bufsize = bufsize;
-    d->xenoprof->domain_ready = 0;
     d->xenoprof->domain_type = XENOPROF_DOMAIN_IGNORED;
 
     /* Update buffer pointers for active vcpus */
@@ -327,7 +343,6 @@ static int set_active(struct domain *d)
     if ( x == NULL )
         return -EPERM;
 
-    x->domain_ready = 1;
     x->domain_type = XENOPROF_DOMAIN_ACTIVE;
     active_ready[ind] = 1;
     activated++;
@@ -348,7 +363,6 @@ static int reset_active(struct domain *d
     if ( x == NULL )
         return -EPERM;
 
-    x->domain_ready = 0;
     x->domain_type = XENOPROF_DOMAIN_IGNORED;
     active_ready[ind] = 0;
     active_domains[ind] = NULL;
@@ -655,12 +669,7 @@ static int xenoprof_op_get_buffer(XEN_GU
             return ret;
     }
     else
-    {
-        d->xenoprof->domain_ready = 0;
         d->xenoprof->domain_type = XENOPROF_DOMAIN_IGNORED;
-    }
-
-    d->xenoprof->is_primary = (xenoprof_primary_profiler == d);
 
     ret = share_xenoprof_page_with_guest(
         d, virt_to_mfn(d->xenoprof->rawbuf), d->xenoprof->npages);
--- a/xen/include/xen/xenoprof.h
+++ b/xen/include/xen/xenoprof.h
@@ -40,25 +40,6 @@ typedef union {
 } xenoprof_buf_t;
 #endif
 
-struct xenoprof_vcpu {
-    int event_size;
-    xenoprof_buf_t *buffer;
-};
-
-struct xenoprof {
-    char *rawbuf;
-    int npages;
-    int nbuf;
-    int bufsize;
-    int domain_type;
-    int domain_ready;
-    int is_primary;
-#ifdef CONFIG_COMPAT
-    int is_compat;
-#endif
-    struct xenoprof_vcpu *vcpu;
-};
-
 #ifndef CONFIG_COMPAT
 #define XENOPROF_COMPAT(x) 0
 #define xenoprof_buf(d, b, field) ACCESS_ONCE((b)->field)



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:53:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdnW-0001to-2O; Wed, 15 Apr 2020 08:53:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOdnV-0001ta-0y
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:53:29 +0000
X-Inumbo-ID: 8f945cd3-7ef6-11ea-8a18-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8f945cd3-7ef6-11ea-8a18-12813bfff9fa;
 Wed, 15 Apr 2020 08:53:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586940803;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=PxPJblaeLlg5yGtVcndg0YsUI7TARWY6Ce7p0+AXg0M=;
 b=Xoi0EV7RnSDp64FBlRx/rUM2yAWhwzKAUQ1FGDih5DlZWmSNboNrIOoJ
 7gSwfvRPCf+yDQGUkrYpy2GPuCheBEB5wiBXwx9w/xgWZKnWC6HVWxr1W
 jG+DhbZ6fSQBWWGFNEj3XSBqsKqKz+9DumjAWMKXeVwfFWPUSsdMu9dYm o=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: E5orRe/uLBPDGpzEGM8zcXo09dKQB+6wJRlWfJDikRhOqd5KtZJRv7i/L7PeqHX1aiqohtze3z
 pgyBF5lysSW+KA9sSNFO1Q1K529NqhFLbokylPHzlzLXkKvZBskjgct3IPTCyy9573g1z9Qd4M
 O5cj64wMab1LN9PhgL3bq1VVUnrl176Lq3hxQ/8IpJGiEJxbjqhMAwKfbcNGfWw41ECegv4wwp
 H83WPXgxy0ocle6XP6qhKuHzmywJRxVLH/+fdeE6b38AZR4KPKGyKz9PdivxIj1PG0hEORT0sA
 huE=
X-SBRS: 2.7
X-MesageID: 16373616
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="16373616"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job
Date: Wed, 15 Apr 2020 10:52:46 +0200
Message-ID: <20200415085246.7945-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200415085246.7945-1-roger.pau@citrix.com>
References: <20200415085246.7945-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Run a simple core scheduling tests on a host that has SMT support.
This is only enabled for Xen >= 4.13.

The runvar difference is:

+test-amd64-coresched-amd64-xl all_host_di_version 2020-02-10
+test-amd64-coresched-i386-xl  all_host_di_version 2020-02-10
+test-amd64-coresched-amd64-xl all_host_suite      stretch
+test-amd64-coresched-i386-xl  all_host_suite      stretch
+test-amd64-coresched-amd64-xl all_hostflags       arch-amd64,arch-xen-amd64,suite-stretch,purpose-test,smt
+test-amd64-coresched-i386-xl  all_hostflags       arch-i386,arch-xen-amd64,suite-stretch,purpose-test,smt
+test-amd64-coresched-amd64-xl arch                amd64
+test-amd64-coresched-i386-xl  arch                i386
+test-amd64-coresched-amd64-xl buildjob            build-amd64
+test-amd64-coresched-i386-xl  buildjob            build-i386
+test-amd64-coresched-amd64-xl debian_arch         amd64
+test-amd64-coresched-i386-xl  debian_arch         i386
+test-amd64-coresched-amd64-xl debian_kernkind     pvops
+test-amd64-coresched-i386-xl  debian_kernkind     pvops
+test-amd64-coresched-amd64-xl debian_suite        stretch
+test-amd64-coresched-i386-xl  debian_suite        stretch
+test-amd64-coresched-amd64-xl kernbuildjob        build-amd64-pvops
+test-amd64-coresched-i386-xl  kernbuildjob        build-i386-pvops
+test-amd64-coresched-amd64-xl kernkind            pvops
+test-amd64-coresched-i386-xl  kernkind            pvops
+test-amd64-coresched-amd64-xl toolstack           xl
+test-amd64-coresched-i386-xl  toolstack           xl
+test-amd64-coresched-amd64-xl xen_boot_append     sched-gran=core
+test-amd64-coresched-i386-xl  xen_boot_append     sched-gran=core
+test-amd64-coresched-amd64-xl xenbuildjob         build-amd64
+test-amd64-coresched-i386-xl  xenbuildjob         build-amd64

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 make-flight | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/make-flight b/make-flight
index 2f445d95..e656125e 100755
--- a/make-flight
+++ b/make-flight
@@ -763,6 +763,17 @@ test_matrix_do_one () {
   *)                test_dom0pvh=n ;;
   esac
 
+  # core scheduling tests for versions >= 4.13 only
+  case "$xenbranch" in
+  xen-3.*-testing)  test_coresched=n ;;
+  xen-4.?-testing)  test_coresched=n ;;
+  xen-4.10-testing) test_coresched=n ;;
+  xen-4.11-testing) test_coresched=n ;;
+  xen-4.12-testing) test_coresched=n ;;
+  *)                test_coresched=y ;;
+  esac
+
+
   # xend PV guest test on x86 only
   if [ x$test_xend = xy -a \( $dom0arch = "i386" -o $dom0arch = "amd64" \) ]; then
     job_create_test test-$xenarch$kern-$dom0arch-pv test-debian xend \
@@ -894,6 +905,15 @@ test_matrix_do_one () {
 
   fi
 
+  # Core-scheduling tests are x86 only
+  if [ x$test_coresched = xy -a $xenarch = amd64 ]; then
+    job_create_test test-$xenarch$kern-coresched-$dom0arch-xl \
+                    test-debian xl $xenarch $dom0arch $debian_runvars \
+                    all_hostflags=$most_hostflags,smt \
+                    xen_boot_append='sched-gran=core'
+
+  fi
+
   #do_passthrough_tests
 
   do_pygrub_tests
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:53:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:53:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdnj-0001xo-Eh; Wed, 15 Apr 2020 08:53:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdni-0001xY-1F
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:53:42 +0000
X-Inumbo-ID: 9a9864fc-7ef6-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9a9864fc-7ef6-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 08:53:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 80423AF92;
 Wed, 15 Apr 2020 08:53:39 +0000 (UTC)
Subject: [PATCH 3/3] xenoprof: limit scope of types and #define-s
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
Message-ID: <61ac5f46-fd43-e173-202e-9de46755d604@suse.com>
Date: Wed, 15 Apr 2020 10:53:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Quite a few of the items are used by xenoprof.c only, so move them there
to limit their visibility as well as the amount of re-building needed in
case of changes. Also drop the inclusion of the public header there.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -19,7 +19,7 @@
 #include <xen/string.h>
 #include <xen/delay.h>
 #include <xen/xenoprof.h>
-#include <public/xen.h>
+#include <public/xenoprof.h>
 #include <asm/msr.h>
 #include <asm/apic.h>
 #include <asm/regs.h>
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -23,6 +23,32 @@
 #undef virt_to_mfn
 #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
 
+#define XENOPROF_DOMAIN_IGNORED    0
+#define XENOPROF_DOMAIN_ACTIVE     1
+#define XENOPROF_DOMAIN_PASSIVE    2
+
+#define XENOPROF_IDLE              0
+#define XENOPROF_INITIALIZED       1
+#define XENOPROF_COUNTERS_RESERVED 2
+#define XENOPROF_READY             3
+#define XENOPROF_PROFILING         4
+
+#ifndef CONFIG_COMPAT
+#define XENOPROF_COMPAT(x) false
+typedef struct xenoprof_buf xenoprof_buf_t;
+#define xenoprof_buf(d, b, field) ACCESS_ONCE((b)->field)
+#else
+#include <compat/xenoprof.h>
+#define XENOPROF_COMPAT(x) ((x)->is_compat)
+typedef union {
+    struct xenoprof_buf native;
+    struct compat_oprof_buf compat;
+} xenoprof_buf_t;
+#define xenoprof_buf(d, b, field) ACCESS_ONCE(*(!(d)->xenoprof->is_compat \
+                                                ? &(b)->native.field \
+                                                : &(b)->compat.field))
+#endif
+
 /* Limit amount of pages used for shared buffer (per domain) */
 #define MAX_OPROF_SHARED_PAGES 32
 
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -29,6 +29,7 @@
 #include <public/platform.h>
 #include <public/version.h>
 #include <public/hvm/params.h>
+#include <public/xenoprof.h>
 #include <public/xsm/flask_op.h>
 
 #include <avc.h>
--- a/xen/include/asm-x86/xenoprof.h
+++ b/xen/include/asm-x86/xenoprof.h
@@ -26,6 +26,8 @@ struct vcpu;
 
 #ifdef CONFIG_XENOPROF
 
+#include <public/xen.h>
+
 int nmi_reserve_counters(void);
 int nmi_setup_events(void);
 int nmi_enable_virq(void);
--- a/xen/include/xen/xenoprof.h
+++ b/xen/include/xen/xenoprof.h
@@ -11,7 +11,6 @@
 #define __XEN_XENOPROF_H__
 
 #include <xen/inttypes.h>
-#include <public/xenoprof.h>
 #include <asm/xenoprof.h>
 
 #define PMU_OWNER_NONE          0
@@ -20,37 +19,9 @@
 
 #ifdef CONFIG_XENOPROF
 
-#define XENOPROF_DOMAIN_IGNORED    0
-#define XENOPROF_DOMAIN_ACTIVE     1
-#define XENOPROF_DOMAIN_PASSIVE    2
-
-#define XENOPROF_IDLE              0
-#define XENOPROF_INITIALIZED       1
-#define XENOPROF_COUNTERS_RESERVED 2
-#define XENOPROF_READY             3
-#define XENOPROF_PROFILING         4
-
-#ifndef CONFIG_COMPAT
-typedef struct xenoprof_buf xenoprof_buf_t;
-#else
-#include <compat/xenoprof.h>
-typedef union {
-	struct xenoprof_buf native;
-	struct compat_oprof_buf compat;
-} xenoprof_buf_t;
-#endif
-
-#ifndef CONFIG_COMPAT
-#define XENOPROF_COMPAT(x) 0
-#define xenoprof_buf(d, b, field) ACCESS_ONCE((b)->field)
-#else
-#define XENOPROF_COMPAT(x) ((x)->is_compat)
-#define xenoprof_buf(d, b, field) ACCESS_ONCE(*(!(d)->xenoprof->is_compat \
-                                                ? &(b)->native.field \
-                                                : &(b)->compat.field))
-#endif
-
 struct domain;
+struct vcpu;
+struct cpu_user_regs;
 
 int acquire_pmu_ownership(int pmu_ownership);
 void release_pmu_ownership(int pmu_ownership);



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 08:56:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 08:56:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdq7-0002HB-UZ; Wed, 15 Apr 2020 08:56:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=c95o=57=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOdq6-0002H0-CK
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 08:56:10 +0000
X-Inumbo-ID: f2af570e-7ef6-11ea-8a1b-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f2af570e-7ef6-11ea-8a1b-12813bfff9fa;
 Wed, 15 Apr 2020 08:56:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586940970;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=aFv2mFDiaRCaSEHaajHR03BkVtQjCe9QkUEvdRhO92Y=;
 b=M06zByULz3Z9OfYgA6lnkNgm40jvA7/EQ5obyRRyJ5gtOhx3jiuL02SO
 RSb81ppwBAo0rMZUiLrOPHLsOjU0dqVDkh2BqQ36/smCAxMAbifPY4T6t
 HGr3X51l3FxuY+w3UpkpY3XKPelegXEvhmnZu2Dn2LHz5HWlpDbiZafUD c=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: +EEVJ73GOUWEfQ10qi/ynHIJ8fT79e/6wc7jLDbXjFM+0dIAmSfijPpVtIOwvk8Zx8icbKoMnJ
 4GFwG2Chz7cyggKvRD2EpFaGgmJDroYvcF9shS8RxWAFMm1eswxigPBfzqBcjotKR5R9vMN5zQ
 7eTXQGm57C/qkxGeXbwNBcc0FixwnAMfR7ZTgQomdrN+kmognsSTLhZ0yE+DNy1xhc3FmayipC
 D2QJkyO2zn1RV1KXbduyGxxXajh4NAvdlqgo1ydkG4DJ49IlQQt8ZpXlHcsjhVhrG728vUaE8u
 97A=
X-SBRS: 2.7
X-MesageID: 15714068
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="15714068"
Subject: Re: [PATCH 0/3] xenoprof: XSA-313 follow-up
To: <paul@xen.org>, 'Jan Beulich' <jbeulich@suse.com>,
 <xen-devel@lists.xenproject.org>
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
 <002801d61302$dbd21950$93764bf0$@xen.org>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <155ff149-bb9c-db71-f54e-2b91eb1474c1@citrix.com>
Date: Wed, 15 Apr 2020 09:56:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <002801d61302$dbd21950$93764bf0$@xen.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Julien Grall' <julien@xen.org>, 'Stefano
 Stabellini' <sstabellini@kernel.org>, 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Wei Liu' <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15/04/2020 09:50, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 15 April 2020 09:45
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap <george.dunlap@citrix.com>; Ian Jackson
>> <ian.jackson@eu.citrix.com>; Julien Grall <julien@xen.org>; Stefano Stabellini
>> <sstabellini@kernel.org>; Wei Liu <wl@xen.org>; Paul Durrant <paul@xen.org>
>> Subject: [PATCH 0/3] xenoprof: XSA-313 follow-up
>>
>> Patch 1 was considered to become part of the XSA, but it was then
>> decided against. The other two are a little bit of cleanup, albeit
>> there's certainly far more room for tidying. Yet then again Paul,
>> in his mail from Mar 13, was asking whether we shouldn't drop
>> xenoprof altogether, at which point cleaning up the code would be
>> wasted effort.
>>
> That's still my opinion. This is a large chunk of (only passively maintained) code which I think is of very limited value (since it relates to an old tool, and it only works for PV domains).

... and yet, noone has bothered getting any other profiler in to a
half-usable state.

You can already Kconfig it out, and yes it is a PITA to use on modern
systems where at the minimum, you need to patch the CPU model whitelist,
and in some cases extend the MSR whitelist in Xen, but at this point
where there are 0 viable alternatives for profiling, removing it would
be a deeply short-sighted move.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 09:02:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 09:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOdwK-0003Aq-Ol; Wed, 15 Apr 2020 09:02:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOdwJ-0003Al-JQ
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 09:02:35 +0000
X-Inumbo-ID: d89def8c-7ef7-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d89def8c-7ef7-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 09:02:34 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5B726AFB4;
 Wed, 15 Apr 2020 09:02:33 +0000 (UTC)
Subject: Re: xenoprof
To: paul@xen.org
References: <000001d5f95c$df50ce60$9df26b20$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <51b20e28-5176-426b-b9fc-12ad89e1deb5@suse.com>
Date: Wed, 15 Apr 2020 11:02:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <000001d5f95c$df50ce60$9df26b20$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 13.03.2020 18:28, Paul Durrant wrote:
>   I'm trying to determine the status of HYPERVISOR_xenoprof_op. The code behind it appears to be unmaintained and I cannot find any
> support statement for it. Googling around finds some mentions of Xen and oprofile but it's not clear whether it works and most
> references I find are quite old. Is it time to remove it?

Well, in the course of XSA-313 inside the security team we asked
ourselves the same, but came to the conclusion that we're better
off keeping it, probably. But clarifying its status in SUPPORT.md
would likely be a good idea. We may want to go as far as
removing security support from it, which then imo ought to be
accompanied by changing its Kconfig option to default-off. The
effect of doing such on older, in particular no longer fully
maintained releases is unclear to me though.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 09:08:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 09:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOe1o-0003MD-L5; Wed, 15 Apr 2020 09:08:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HD5o=57=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jOe1n-0003M8-1O
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 09:08:15 +0000
X-Inumbo-ID: a309db5a-7ef8-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a309db5a-7ef8-11ea-b4f4-bc764e2007e4;
 Wed, 15 Apr 2020 09:08:14 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 792D0AE39;
 Wed, 15 Apr 2020 09:08:12 +0000 (UTC)
Subject: Re: [Xen-devel] [PATCH] sched/core: Fix bug when moving a domain
 between cpupools
To: Jeff Kubascik <jeff.kubascik@dornerworks.com>,
 xen-devel@lists.xenproject.org, George Dunlap <george.dunlap@citrix.com>,
 Dario Faggioli <dfaggioli@suse.com>
References: <20200327193023.506-1-jeff.kubascik@dornerworks.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <9969e5ea-1378-3439-c9a5-19fb9b5c91ac@suse.com>
Date: Wed, 15 Apr 2020 11:08:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200327193023.506-1-jeff.kubascik@dornerworks.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stewart Hildebrand <Stewart.Hildebrand@dornerworks.com>,
 Nathan Studer <Nathan.Studer@dornerworks.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.03.20 20:30, Jeff Kubascik wrote:
> For each UNIT, sched_set_affinity is called before unit->priv is updated
> to the new cpupool private UNIT data structure. The issue is
> sched_set_affinity will call the adjust_affinity method of the cpupool.
> If defined, the new cpupool may use unit->priv (e.g. credit), which at
> this point still references the old cpupool private UNIT data structure.
> 
> This change fixes the bug by moving the switch of unit->priv earler in
> the function.
> 
> Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 09:13:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 09:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOe6R-0004As-BA; Wed, 15 Apr 2020 09:13:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOe6P-0004An-9U
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 09:13:01 +0000
X-Inumbo-ID: 4da57f60-7ef9-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4da57f60-7ef9-11ea-b4f4-bc764e2007e4;
 Wed, 15 Apr 2020 09:13:00 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B7BDAAE48;
 Wed, 15 Apr 2020 09:12:58 +0000 (UTC)
Subject: Re: [PATCH 01/12] xen: introduce xen_dom_flags
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-1-sstabellini@kernel.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <aede4742-03e1-e47b-354a-5475f63fff86@suse.com>
Date: Wed, 15 Apr 2020 11:12:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-1-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>,
 George Dunlap <George.Dunlap@eu.citrix.com>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, Dario Faggioli <dfaggioli@suse.com>,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 03:02, Stefano Stabellini wrote:
> We are passing an extra special boolean flag at domain creation to
> specify whether we want to the domain to be privileged (i.e. dom0) or
> not. Another flag will be introduced later in this series.
> 
> Introduce a new struct xen_dom_flags and move the privileged flag to it.
> Other flags will be added to struct xen_dom_flags.

I'm unsure whether introducing a 2nd structure is worth it here.
We could as well define some internal-use-only flags for
struct xen_domctl_createdomain's respective field.

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -529,7 +529,8 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>  }
>  
>  int arch_domain_create(struct domain *d,
> -                       struct xen_domctl_createdomain *config)
> +                       struct xen_domctl_createdomain *config,
> +                       struct xen_dom_flags *flags)

const (also elsewhere)?

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -706,6 +706,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>          .max_maptrack_frames = -1,
>      };
>      const char *hypervisor_name;
> +    struct xen_dom_flags flags = { !pv_shim };

Here and elsewhere please use field designators right away, even if
there's only a single field now.

> @@ -363,7 +363,7 @@ struct domain *domain_create(domid_t domid,
>      ASSERT(is_system_domain(d) ? config == NULL : config != NULL);
>  
>      /* Sort out our idea of is_control_domain(). */
> -    d->is_privileged = is_priv;
> +    d->is_privileged =  flags ? flags->is_priv : false;

Stray double blanks.

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -364,6 +364,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>      bool_t copyback = 0;
>      struct xen_domctl curop, *op = &curop;
>      struct domain *d;
> +    struct xen_dom_flags flags ={ false };

Missing blank.

> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -63,8 +63,13 @@ void arch_vcpu_destroy(struct vcpu *v);
>  int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset);
>  void unmap_vcpu_info(struct vcpu *v);
>  
> +struct xen_dom_flags {
> +    bool is_priv;

Use a single bit bitfield instead? May even want to consider passing
this struct by value then.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 09:32:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 09:32:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOePQ-0005sP-5U; Wed, 15 Apr 2020 09:32:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=lpyF=57=amazon.com=prvs=367615363=havanur@srs-us1.protection.inumbo.net>)
 id 1jOePP-0005sK-49
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 09:32:39 +0000
X-Inumbo-ID: 0b17da51-7efc-11ea-8a1e-12813bfff9fa
Received: from smtp-fw-4101.amazon.com (unknown [72.21.198.25])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0b17da51-7efc-11ea-8a1e-12813bfff9fa;
 Wed, 15 Apr 2020 09:32:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586943157; x=1618479157;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:content-transfer-encoding:mime-version:subject;
 bh=p+a9pwPcuOF2QCgGDOQQyu7qTSIDuuYYPkkAPKsD7y4=;
 b=HXUVBqsJhWWPFw+048qzJ/q4gcJaJfGen2av3qk3efmFCoUdDChH+LC+
 Yl+DiGdGppVHJGCX/T/V9seXvb3lUpzK077fkU4ZLYENKdcoHhMJrnmxW
 40R63CpMicYdhAJ8ZJZZHvCj9RG76EVI4fzLSZelQpwL2+mBfUOfR6guy M=;
IronPort-SDR: EiadF9FGcF2rHiZ0Q6pc6CVoNrw5XJwq9rU0YxMyJFYCEhJrg+1n/wf66fMnaey3drexl5YRRg
 jI6H2mPNJWLg==
X-IronPort-AV: E=Sophos;i="5.72,386,1580774400"; d="scan'208";a="25641125"
Subject: Re: [XEN PATCH v4] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Thread-Topic: [XEN PATCH v4] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-1d-f273de60.us-east-1.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP;
 15 Apr 2020 09:32:25 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])
 by email-inbound-relay-1d-f273de60.us-east-1.amazon.com (Postfix) with ESMTPS
 id 99702A23D5; Wed, 15 Apr 2020 09:32:22 +0000 (UTC)
Received: from EX13D36EUC001.ant.amazon.com (10.43.164.105) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Wed, 15 Apr 2020 09:32:22 +0000
Received: from EX13D36EUC004.ant.amazon.com (10.43.164.126) by
 EX13D36EUC001.ant.amazon.com (10.43.164.105) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Wed, 15 Apr 2020 09:32:21 +0000
Received: from EX13D36EUC004.ant.amazon.com ([10.43.164.126]) by
 EX13D36EUC004.ant.amazon.com ([10.43.164.126]) with mapi id 15.00.1497.006;
 Wed, 15 Apr 2020 09:32:21 +0000
From: "Shamsundara Havanur, Harsha" <havanur@amazon.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Thread-Index: AQHWEoA+bzxN65iSaU+AQK01+fBaZah5xbMAgAAm0QA=
Date: Wed, 15 Apr 2020 09:32:21 +0000
Message-ID: <538d839fda5fc78c7519200e990d1888e56a6e06.camel@amazon.com>
References: <4b6c017245698c18b063d156be645b8b633c0a99.1586884502.git.havanur@amazon.com>
 <81c7ca01-c272-9114-a5d0-12ca94090eb2@suse.com>
In-Reply-To: <81c7ca01-c272-9114-a5d0-12ca94090eb2@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.165.71]
Content-Type: text/plain; charset="utf-8"
Content-ID: <818FFC9DFBF3F048A9A9F9E72A160B66@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 "wl@xen.org" <wl@xen.org>, "roger.pau@citrix.com" <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

T24gV2VkLCAyMDIwLTA0LTE1IGF0IDA5OjEzICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4g
Q0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p
emF0aW9uLiBEbw0KPiBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3Mg
eW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXINCj4gYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2Fm
ZS4NCj4gDQo+IA0KPiANCj4gT24gMTQuMDQuMjAyMCAxOToxNSwgSGFyc2hhIFNoYW1zdW5kYXJh
IEhhdmFudXIgd3JvdGU6DQo+ID4gQEAgLTEyMCw2ICsxMjEsMTEgQEAgdm9pZCBwY2lfc2V0dXAo
dm9pZCkNCj4gPiAgICAgICAqLw0KPiA+ICAgICAgYm9vbCBhbGxvd19tZW1vcnlfcmVsb2NhdGUg
PSAxOw0KPiA+IA0KPiA+ICsgICAgQlVJTERfQlVHX09OKCh0eXBlb2YoKnBjaV9kZXZmbl9kZWNv
ZGVfdHlwZSkpUENJX0NPTU1BTkRfTUVNT1INCj4gPiBZDQo+ID4gKyAgICAgICAgICAgICE9IFBD
SV9DT01NQU5EX01FTU9SWSk7DQo+ID4gKyAgICBCVUlMRF9CVUdfT04oKHR5cGVvZigqcGNpX2Rl
dmZuX2RlY29kZV90eXBlKSlQQ0lfQ09NTUFORF9JTw0KPiA+ICsgICAgICAgICAgICAhPSBQQ0lf
Q09NTUFORF9JTyk7DQo+IA0KPiBUaGlzIHN0aWxsIGlzbid0IGluIGxpbmUgd2l0aCBvdXIgZGVm
YXVsdCBzdHlsZSwgeW91IHdpbGwgd2FudCBlZzoNCj4gDQo+ICAgICBCVUlMRF9CVUdfT04oKHR5
cGVvZigqcGNpX2RldmZuX2RlY29kZV90eXBlKSlQQ0lfQ09NTUFORF9NRU1PUlkNCj4gIT0NCj4g
ICAgICAgICAgICAgICAgICBQQ0lfQ09NTUFORF9NRU1PUlkpOw0KPiAgICAgQlVJTERfQlVHX09O
KCh0eXBlb2YoKnBjaV9kZXZmbl9kZWNvZGVfdHlwZSkpUENJX0NPTU1BTkRfSU8gIT0NCj4gICAg
ICAgICAgICAgICAgICBQQ0lfQ09NTUFORF9JTyk7DQo+IA0KPiA+IEBAIC0yMDgsNiArMjE0LDIw
IEBAIHZvaWQgcGNpX3NldHVwKHZvaWQpDQo+ID4gICAgICAgICAgICAgIGJyZWFrOw0KPiA+ICAg
ICAgICAgIH0NCj4gPiANCj4gPiArICAgICAgICAvKg0KPiA+ICsgICAgICAgICAqIERpc2FibGUg
bWVtb3J5IGFuZCBJL08gZGVjb2RlLA0KPiA+ICsgICAgICAgICAqIEl0IGlzIHJlY29tbWVuZGVk
IHRoYXQgQkFSIHByb2dyYW1taW5nIGJlIGRvbmUgd2hpbHN0DQo+ID4gKyAgICAgICAgICogZGVj
b2RlIGJpdHMgYXJlIGNsZWFyZWQgdG8gYXZvaWQgaW5jb3JyZWN0IG1hcHBpbmdzDQo+ID4gYmVp
bmcgY3JlYXRlZCwNCj4gPiArICAgICAgICAgKiB3aGVuIDY0LWJpdCBtZW1vcnkgQkFSIGlzIHBy
b2dyYW1tZWQgZmlyc3QgYnkgd3JpdGluZw0KPiA+IHRoZSBsb3dlciBoYWxmDQo+ID4gKyAgICAg
ICAgICogYW5kIHRoZW4gdGhlIHVwcGVyIGhhbGYsIHdoaWNoIGZpcnN0IG1hcHMgdG8gYW4gYWRk
cmVzcw0KPiA+IHVuZGVyIDRHDQo+ID4gKyAgICAgICAgICogcmVwbGFjaW5nIGFueSBSQU0gbWFw
cGVkIGluIHRoYXQgYWRkcmVzcywgd2hpY2ggaXMgbm90DQo+ID4gcmVzdG9yZWQNCj4gPiArICAg
ICAgICAgKiBiYWNrIGFmdGVyIHRoZSB1cHBlciBoYWxmIGlzIHdyaXR0ZW4gYW5kIFBDSSBtZW1v
cnkgaXMNCj4gPiBjb3JyZWN0bHkNCj4gPiArICAgICAgICAgKiBtYXBwZWQgdG8gaXRzIGludGVu
ZGVkIGhpZ2ggbWVtIGFkZHJlc3MuDQo+ID4gKyAgICAgICAgICovDQo+IA0KPiBQbGVhc2UgY2Fu
IHlvdSBicmluZyB0aGlzIGNvbW1lbnQgaW50byBzaGFwZT8gVGhlIGNvbW1hIG9uIHRoZSBmaXJz
dA0KPiBsaW5lIGRvZXNuJ3QgZml0IHdpdGggdGhlIGNhcGl0YWwgbGV0dGVyIHRoZSBzZWNvbmQg
bGluZSBzdGFydHMgd2l0aC4NCj4gUGx1cywgaWYgeW91IHJlYWxseSBtZWFuIHdoYXQgaXMgbm93
IG9uIHRoZSBzZWNvbmQgbGluZSB0byBzdGFydCBvbiBhDQo+IG5ldyBvbmUsIHRoZW4gcGxlYXNl
IGFsc28gaW5zZXJ0IGEgbGluZSBjb25zaXN0aW5nIG9mIGp1c3QgKiBhdCB0aGUNCj4gcHJvcGVy
bHkgaW5kZW50ZWQgcG9zaXRpb24gYmV0d2VlbiB0aGUgdHdvLiBBZGRpdGlvbmFsbHkgdGhlcmUn
cyBhdA0KPiBsZWFzdCBvbmUgbGluZSBleGNlZWRpbmcgdGhlIDgwLWNoYXJzLXBlci1saW5lIGxp
bWl0Lg0KPiANCj4gPiBAQCAtMjg5LDEwICszMDksNiBAQCB2b2lkIHBjaV9zZXR1cCh2b2lkKQ0K
PiA+ICAgICAgICAgICAgICAgICAgICAgZGV2Zm4+PjMsIGRldmZuJjcsICdBJytwaW4tMSwgaXNh
X2lycSk7DQo+ID4gICAgICAgICAgfQ0KPiA+IA0KPiA+IC0gICAgICAgIC8qIEVuYWJsZSBidXMg
bWFzdGVyaW5nLiAqLw0KPiA+IC0gICAgICAgIGNtZCA9IHBjaV9yZWFkdyhkZXZmbiwgUENJX0NP
TU1BTkQpOw0KPiA+IC0gICAgICAgIGNtZCB8PSBQQ0lfQ09NTUFORF9NQVNURVI7DQo+ID4gLSAg
ICAgICAgcGNpX3dyaXRldyhkZXZmbiwgUENJX0NPTU1BTkQsIGNtZCk7DQo+IA0KPiBUaGUgbW92
ZW1lbnQgb2YgdGhpcyB3YW50cyBtZW50aW9uaW5nIGluIHRoZSBkZXNjcmlwdGlvbi4NCj4gDQo+
ID4gQEAgLTUyNiwxMCArNTM4LDE3IEBAIHZvaWQgcGNpX3NldHVwKHZvaWQpDQo+ID4gICAgICAg
ICAgICogaGFzIElPIGVuYWJsZWQsIGV2ZW4gaWYgdGhlcmUgaXMgbm8gSS9PIEJBUiBvbiB0aGF0
DQo+ID4gICAgICAgICAgICogcGFydGljdWxhciBkZXZpY2UuDQo+ID4gICAgICAgICAgICovDQo+
ID4gLSAgICAgICAgY21kID0gcGNpX3JlYWR3KHZnYV9kZXZmbiwgUENJX0NPTU1BTkQpOw0KPiA+
IC0gICAgICAgIGNtZCB8PSBQQ0lfQ09NTUFORF9JTzsNCj4gPiAtICAgICAgICBwY2lfd3JpdGV3
KHZnYV9kZXZmbiwgUENJX0NPTU1BTkQsIGNtZCk7DQo+ID4gKyAgICAgICAgcGNpX2RldmZuX2Rl
Y29kZV90eXBlW3ZnYV9kZXZmbl0gfD0gUENJX0NPTU1BTkRfSU87DQo+ID4gICAgICB9DQo+ID4g
Kw0KPiA+ICsgICAgLyogRW5hYmxlIGJ1cyBtYXN0ZXIsIG1lbW9yeSBhbmQgSS9PIGRlY29kZS4g
Ki8NCj4gPiArICAgIGZvciAoIGRldmZuID0gMDsgZGV2Zm4gPCAyNTY7IGRldmZuKysgKQ0KPiA+
ICsgICAgICAgIGlmICggcGNpX2RldmZuX2RlY29kZV90eXBlW2RldmZuXSApDQo+ID4gKyAgICAg
ICAgew0KPiA+ICsgICAgICAgICAgICBjbWQgPSBwY2lfcmVhZHcoZGV2Zm4sIFBDSV9DT01NQU5E
KTsNCj4gPiArICAgICAgICAgICAgY21kIHw9IChQQ0lfQ09NTUFORF9NQVNURVIgfA0KPiA+IHBj
aV9kZXZmbl9kZWNvZGVfdHlwZVtkZXZmbl0pOw0KPiA+ICsgICAgICAgICAgICBwY2lfd3JpdGV3
KGRldmZuLCBQQ0lfQ09NTUFORCwgY21kKTsNCj4gPiArICAgICAgICB9DQo+IA0KPiBUaGlzIHN0
aWxsIHJlZ3Jlc3NlcyB0aGUgc2V0dGluZyBvZiBNQVNURVIgYWZhaWN0OiBZb3Ugb25seSBzZXQN
Cj4gdGhhdCBiaXQgbm93IGlmIGVpdGhlciBJTyBvciBNRU1PUlkgd291bGQgYWxzbyBnZXQgc2V0
LiBCdXQgYmUNCj4gc3VyZSB0byBob25vciB0aGUgb3JpZ2luYWwgY29kZSBub3QgZG9pbmcgdGhl
IHdyaXRlIHdoZW4gdmVuZG9yLw0KPiBkZXZpY2UgSURzIGFyZSBhbGwgb25lcy4NCj4gDQpJZiBj
b25kaXRpb24gZW5zdXJlcyB0aGF0IGZvciBkZXZpY2VzIHdpdGggdmVuZG9yL2RldmljZSBJRHMg
YWxsIG9uZXMNCmFyZSBza2lwcGVkIGFzIGl0IHdvdWxkIGV2YWx1YXRlIHRvIGZhbHNlLiBCdXQg
dGhpcyB3b3VsZCBhbHNvIHNraXANCmVuYWJsaW5nIEJ1cyBtYXN0ZXIgZm9yIGRldmljZXMgd2hv
c2UgdmVuZG9yL2RldmljZSBJRHMgYXJlIG5vdCBhbGwNCm9uZXMgYnV0IElPIG9yIG1lbW9yeSBC
QVJzIGFyZSBub3QgcHJvZ3JhbW1lZCBmb3IgdGhlbS4gSXMgdGhlcmUgYQ0KcG9zc2liaWxpdHkg
b2YgdGhpcyBoYXBwZW5pbmc/DQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 09:44:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 09:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOeaS-0006mo-9S; Wed, 15 Apr 2020 09:44:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3U8g=57=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jOeaQ-0006mj-Rs
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 09:44:02 +0000
X-Inumbo-ID: a27f8c52-7efd-11ea-b58d-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a27f8c52-7efd-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 09:44:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586943842;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=mbv+gpnFAZR8mNqDCIoCs8V/jdKDMCJTMEMlB1YW6yI=;
 b=dxWLk92PqR7bc/FQCberxto4vxxYjqLzf7UYrP9q6vl2H76fg0Qe2gh0
 fSNSvEZ07o+rmowlNjX0k9MwVggywmnbBbu94XaQ3qqa6TiOLDfBfV1sO
 LrACv/bJIe5uw9h7gor7RGrrL3ndWIQ7AQVgzME1Ziz/lcuZ/w/Dkoq4l 8=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: CmiavONeHizNUCydwtRzkd/g4WjHQC6isrTu2ZyfOSDY2t9rsbtzUWXZydRcMlT+LS4qvdtHT8
 vZUGx1TwaZogzFQudsrTPXIgs3mhyBoXjZ9EzlpuOKAxL56pCUqcGGH3ECXQ5NtvE/IXM5aTY4
 nLuurjtTOA6oSz1QLekM17EU8/SOajMpODkjIZgBTbjMTWEM22x+xcTuAa+0Aqq25lDpGMg7FO
 8yGb3eV0s+J45TA8Kl+wDx5hF6EY20XqKu46Dwu/Soi9PE/GTpAM3xqGSCn+B8IOB36oqLkS5F
 wdE=
X-SBRS: 2.7
X-MesageID: 15941227
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="15941227"
From: George Dunlap <George.Dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
Thread-Topic: [PATCH v2] Introduce a description of a new optional tag for
 Backports
Thread-Index: AQHWD1gOS2WGOdcsW0SaziyGliZeaKh4Iv2AgACXkACAAOHggIAAOB+A
Date: Wed, 15 Apr 2020 09:43:57 +0000
Message-ID: <04881FC6-A816-44AB-8F25-54E5A265707E@citrix.com>
References: <20200410164942.9747-1-sstabellini@kernel.org>
 <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
 <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
 <707a1448-be1d-0aa8-6b11-a33eb247304f@suse.com>
In-Reply-To: <707a1448-be1d-0aa8-6b11-a33eb247304f@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8E7CA1A66DA65A4A97EDBE444B7F8C19@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Lars Kurth <lars.kurth@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



> On Apr 15, 2020, at 7:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>=20
> On 14.04.2020 18:54, Stefano Stabellini wrote:
>> On Tue, 14 Apr 2020, Jan Beulich wrote:
>>> On 10.04.2020 18:49, Stefano Stabellini wrote:
>>=20
[snip]
>>>> +    Backport: all
>>>> +
>>>> +It marks a commit for being a candidate for backports to all relevant
>>>> +trees.
>>>=20
>>> I'm unconvinced of the utility of this form - what "all" resolves to
>>> changes over time. There's almost always a first version where a
>>> particular issue was introduced. If we want this to be generally
>>> useful, imo we shouldn't limit the scope of the tag to the upstream
>>> maintained stable trees.
>>=20
>> The reason why I suggested also to have a "wildcard" version of this
>> tag, is that the person adding the tag (could be the contributor trying
>> to be helpful) might not know exactly to which stable trees the patch
>> should be backported to.
>>=20
>> Writing this sentence, I realize that I really meant "any" rather than
>> "all". Would you prefer if I used "any"? Or we could even suggest to lea=
ve
>> it black like this:
>>=20
>>  Backport:
>>=20
>> But it looks a bit weird.
>=20
> Indeed. Instead of "all" or "any", how about "yes", "unspecified", or
> "unknown"? Nevertheless, I still think people asking for a backport
> should be nudged towards determining the applicable range; them not
> doing so effectively pushes the burden to the general maintainers or
> the stable tree ones, both of which scales less well. Omitting the
> tag if they don't want to invest the time would to me then seem to
> be the cleanest alternative. Albeit I'm sure views here will vary.

FWIW asking people adding the tag to do the work of figuring out which vers=
ions to backport to makes sense to me.

 -George



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 09:49:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 09:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOeg6-0006xU-1C; Wed, 15 Apr 2020 09:49:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOeg4-0006xP-60
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 09:49:52 +0000
X-Inumbo-ID: 739811f6-7efe-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 739811f6-7efe-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 09:49:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=u9uuE064Jb8xCh61RnjnOpdhmp/TBNWR/mKJf5x6p5Q=; b=Ft4P8P93LSORFtDNGdbVs94XSp
 D8zOtX5lmWewyw62cCnawg3KgNP1kH8NjRtPt9z0T3QQc6Z3N8iT7qT7OGFM58cQzk5Jl7ulU63b1
 apLS4MLDbeAAwVIT8A9K7FDVP5ngNA4ODsvxyiWxTa7fmL9F5CNSvYPgnmfi7rh+L/Bs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOeg1-00080X-Hu; Wed, 15 Apr 2020 09:49:49 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOeg1-0007fp-A0; Wed, 15 Apr 2020 09:49:49 +0000
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
To: George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <20200410164942.9747-1-sstabellini@kernel.org>
 <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
 <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
 <707a1448-be1d-0aa8-6b11-a33eb247304f@suse.com>
 <04881FC6-A816-44AB-8F25-54E5A265707E@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <49c732e6-d30d-0892-0bd7-65c082da0429@xen.org>
Date: Wed, 15 Apr 2020 10:49:47 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <04881FC6-A816-44AB-8F25-54E5A265707E@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Lars Kurth <lars.kurth@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 15/04/2020 10:43, George Dunlap wrote:
> 
> 
>> On Apr 15, 2020, at 7:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>> On 14.04.2020 18:54, Stefano Stabellini wrote:
>>> On Tue, 14 Apr 2020, Jan Beulich wrote:
>>>> On 10.04.2020 18:49, Stefano Stabellini wrote:
>>>
> [snip]
>>>>> +    Backport: all
>>>>> +
>>>>> +It marks a commit for being a candidate for backports to all relevant
>>>>> +trees.
>>>>
>>>> I'm unconvinced of the utility of this form - what "all" resolves to
>>>> changes over time. There's almost always a first version where a
>>>> particular issue was introduced. If we want this to be generally
>>>> useful, imo we shouldn't limit the scope of the tag to the upstream
>>>> maintained stable trees.
>>>
>>> The reason why I suggested also to have a "wildcard" version of this
>>> tag, is that the person adding the tag (could be the contributor trying
>>> to be helpful) might not know exactly to which stable trees the patch
>>> should be backported to.
>>>
>>> Writing this sentence, I realize that I really meant "any" rather than
>>> "all". Would you prefer if I used "any"? Or we could even suggest to leave
>>> it black like this:
>>>
>>>   Backport:
>>>
>>> But it looks a bit weird.
>>
>> Indeed. Instead of "all" or "any", how about "yes", "unspecified", or
>> "unknown"? Nevertheless, I still think people asking for a backport
>> should be nudged towards determining the applicable range; them not
>> doing so effectively pushes the burden to the general maintainers or
>> the stable tree ones, both of which scales less well. Omitting the
>> tag if they don't want to invest the time would to me then seem to
>> be the cleanest alternative. Albeit I'm sure views here will vary.
> 
> FWIW asking people adding the tag to do the work of figuring out which versions to backport to makes sense to me.

If you ask the contributor to do the work then you need to give guidance 
on the "older" version you can specify in Backport.

For instance, let say the bug was introduced in Xen 4.2. Are we allowing 
the user to specify Backport: 4.2+ or should it be 4.11+?

I would favor the former as this helps for downstream user which haven't 
yet moved to the supported stable tree.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 09:57:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 09:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOen2-0007q0-TR; Wed, 15 Apr 2020 09:57:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3U8g=57=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jOen2-0007pv-D0
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 09:57:04 +0000
X-Inumbo-ID: 72a86b50-7eff-11ea-8a21-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 72a86b50-7eff-11ea-8a21-12813bfff9fa;
 Wed, 15 Apr 2020 09:57:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586944620;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=GdPR/arZr8Yzve/UG6JJly3WpRtRMcwrxgJ+PQF8Sjo=;
 b=CX+dMn8+xYJSFVMZ+KeqSJxOuKtJGP8VQzEIK+A0/UxGwAkIwC8klkPu
 Y0bHBellpi2t2YjFobo3cliFDHOrGbyg1bM9ZlnJ4fyfaeSA8+Wt0T4xo
 Ex/ukwPwrt9S1+pZR6ccMYSZi2mCDqU2NoF3iypIzlv0ERXRlWBI+3/7G Y=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: JMFgYvDzPrWt+dw5QZvF9ifddYhLlPFC1ye3BpagcaFcNieJ+ZhiMvfXZiVGT3MzAlGJblfM2w
 LtwG8SFCthFoZbQ9miNx2p7pZEIrRgJWtzdIe7kOSXvGfeuhW9ZCwGb2IGOig/LRIwT/qtJOW5
 unzukODMahu6f/9QaZbh7CPa6CgINSSUn3NASMOVOQbIRpF284n/ZBUXWKTTcaCyTl8h/S6hOq
 om7/2wmS7sBLaxt+KlW2BWWt58EaRbSxbTsklncEIOjnTxjI3qLdVMEbja7udNAAIOJNlYSCbc
 ew4=
X-SBRS: 2.7
X-MesageID: 15716472
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="15716472"
From: George Dunlap <George.Dunlap@citrix.com>
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
Thread-Topic: [PATCH v2] Introduce a description of a new optional tag for
 Backports
Thread-Index: AQHWD1gOS2WGOdcsW0SaziyGliZeaKh4Iv2AgACXkACAAOHggIAAOB+AgAABooCAAAH+gA==
Date: Wed, 15 Apr 2020 09:56:55 +0000
Message-ID: <10D98CF7-E38E-44C3-AF24-C93088F6682D@citrix.com>
References: <20200410164942.9747-1-sstabellini@kernel.org>
 <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
 <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
 <707a1448-be1d-0aa8-6b11-a33eb247304f@suse.com>
 <04881FC6-A816-44AB-8F25-54E5A265707E@citrix.com>
 <49c732e6-d30d-0892-0bd7-65c082da0429@xen.org>
In-Reply-To: <49c732e6-d30d-0892-0bd7-65c082da0429@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <3409587D46A0D24D95847CE7E7001D7E@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Lars Kurth <lars.kurth@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDE1LCAyMDIwLCBhdCAxMDo0OSBBTSwgSnVsaWVuIEdyYWxsIDxqdWxpZW5A
eGVuLm9yZz4gd3JvdGU6DQo+IA0KPiANCj4gDQo+IE9uIDE1LzA0LzIwMjAgMTA6NDMsIEdlb3Jn
ZSBEdW5sYXAgd3JvdGU6DQo+Pj4gT24gQXByIDE1LCAyMDIwLCBhdCA3OjIzIEFNLCBKYW4gQmV1
bGljaCA8SkJldWxpY2hAc3VzZS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IE9uIDE0LjA0LjIwMjAg
MTg6NTQsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4+Pj4gT24gVHVlLCAxNCBBcHIgMjAy
MCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAxMC4wNC4yMDIwIDE4OjQ5LCBTdGVmYW5v
IFN0YWJlbGxpbmkgd3JvdGU6DQo+Pj4+IA0KPj4gW3NuaXBdDQo+Pj4+Pj4gKyAgICBCYWNrcG9y
dDogYWxsDQo+Pj4+Pj4gKw0KPj4+Pj4+ICtJdCBtYXJrcyBhIGNvbW1pdCBmb3IgYmVpbmcgYSBj
YW5kaWRhdGUgZm9yIGJhY2twb3J0cyB0byBhbGwgcmVsZXZhbnQNCj4+Pj4+PiArdHJlZXMuDQo+
Pj4+PiANCj4+Pj4+IEknbSB1bmNvbnZpbmNlZCBvZiB0aGUgdXRpbGl0eSBvZiB0aGlzIGZvcm0g
LSB3aGF0ICJhbGwiIHJlc29sdmVzIHRvDQo+Pj4+PiBjaGFuZ2VzIG92ZXIgdGltZS4gVGhlcmUn
cyBhbG1vc3QgYWx3YXlzIGEgZmlyc3QgdmVyc2lvbiB3aGVyZSBhDQo+Pj4+PiBwYXJ0aWN1bGFy
IGlzc3VlIHdhcyBpbnRyb2R1Y2VkLiBJZiB3ZSB3YW50IHRoaXMgdG8gYmUgZ2VuZXJhbGx5DQo+
Pj4+PiB1c2VmdWwsIGltbyB3ZSBzaG91bGRuJ3QgbGltaXQgdGhlIHNjb3BlIG9mIHRoZSB0YWcg
dG8gdGhlIHVwc3RyZWFtDQo+Pj4+PiBtYWludGFpbmVkIHN0YWJsZSB0cmVlcy4NCj4+Pj4gDQo+
Pj4+IFRoZSByZWFzb24gd2h5IEkgc3VnZ2VzdGVkIGFsc28gdG8gaGF2ZSBhICJ3aWxkY2FyZCIg
dmVyc2lvbiBvZiB0aGlzDQo+Pj4+IHRhZywgaXMgdGhhdCB0aGUgcGVyc29uIGFkZGluZyB0aGUg
dGFnIChjb3VsZCBiZSB0aGUgY29udHJpYnV0b3IgdHJ5aW5nDQo+Pj4+IHRvIGJlIGhlbHBmdWwp
IG1pZ2h0IG5vdCBrbm93IGV4YWN0bHkgdG8gd2hpY2ggc3RhYmxlIHRyZWVzIHRoZSBwYXRjaA0K
Pj4+PiBzaG91bGQgYmUgYmFja3BvcnRlZCB0by4NCj4+Pj4gDQo+Pj4+IFdyaXRpbmcgdGhpcyBz
ZW50ZW5jZSwgSSByZWFsaXplIHRoYXQgSSByZWFsbHkgbWVhbnQgImFueSIgcmF0aGVyIHRoYW4N
Cj4+Pj4gImFsbCIuIFdvdWxkIHlvdSBwcmVmZXIgaWYgSSB1c2VkICJhbnkiPyBPciB3ZSBjb3Vs
ZCBldmVuIHN1Z2dlc3QgdG8gbGVhdmUNCj4+Pj4gaXQgYmxhY2sgbGlrZSB0aGlzOg0KPj4+PiAN
Cj4+Pj4gIEJhY2twb3J0Og0KPj4+PiANCj4+Pj4gQnV0IGl0IGxvb2tzIGEgYml0IHdlaXJkLg0K
Pj4+IA0KPj4+IEluZGVlZC4gSW5zdGVhZCBvZiAiYWxsIiBvciAiYW55IiwgaG93IGFib3V0ICJ5
ZXMiLCAidW5zcGVjaWZpZWQiLCBvcg0KPj4+ICJ1bmtub3duIj8gTmV2ZXJ0aGVsZXNzLCBJIHN0
aWxsIHRoaW5rIHBlb3BsZSBhc2tpbmcgZm9yIGEgYmFja3BvcnQNCj4+PiBzaG91bGQgYmUgbnVk
Z2VkIHRvd2FyZHMgZGV0ZXJtaW5pbmcgdGhlIGFwcGxpY2FibGUgcmFuZ2U7IHRoZW0gbm90DQo+
Pj4gZG9pbmcgc28gZWZmZWN0aXZlbHkgcHVzaGVzIHRoZSBidXJkZW4gdG8gdGhlIGdlbmVyYWwg
bWFpbnRhaW5lcnMgb3INCj4+PiB0aGUgc3RhYmxlIHRyZWUgb25lcywgYm90aCBvZiB3aGljaCBz
Y2FsZXMgbGVzcyB3ZWxsLiBPbWl0dGluZyB0aGUNCj4+PiB0YWcgaWYgdGhleSBkb24ndCB3YW50
IHRvIGludmVzdCB0aGUgdGltZSB3b3VsZCB0byBtZSB0aGVuIHNlZW0gdG8NCj4+PiBiZSB0aGUg
Y2xlYW5lc3QgYWx0ZXJuYXRpdmUuIEFsYmVpdCBJJ20gc3VyZSB2aWV3cyBoZXJlIHdpbGwgdmFy
eS4NCj4+IEZXSVcgYXNraW5nIHBlb3BsZSBhZGRpbmcgdGhlIHRhZyB0byBkbyB0aGUgd29yayBv
ZiBmaWd1cmluZyBvdXQgd2hpY2ggdmVyc2lvbnMgdG8gYmFja3BvcnQgdG8gbWFrZXMgc2Vuc2Ug
dG8gbWUuDQo+IA0KPiBJZiB5b3UgYXNrIHRoZSBjb250cmlidXRvciB0byBkbyB0aGUgd29yayB0
aGVuIHlvdSBuZWVkIHRvIGdpdmUgZ3VpZGFuY2Ugb24gdGhlICJvbGRlciIgdmVyc2lvbiB5b3Ug
Y2FuIHNwZWNpZnkgaW4gQmFja3BvcnQuDQo+IA0KPiBGb3IgaW5zdGFuY2UsIGxldCBzYXkgdGhl
IGJ1ZyB3YXMgaW50cm9kdWNlZCBpbiBYZW4gNC4yLiBBcmUgd2UgYWxsb3dpbmcgdGhlIHVzZXIg
dG8gc3BlY2lmeSBCYWNrcG9ydDogNC4yKyBvciBzaG91bGQgaXQgYmUgNC4xMSs/DQo+IA0KPiBJ
IHdvdWxkIGZhdm9yIHRoZSBmb3JtZXIgYXMgdGhpcyBoZWxwcyBmb3IgZG93bnN0cmVhbSB1c2Vy
IHdoaWNoIGhhdmVuJ3QgeWV0IG1vdmVkIHRvIHRoZSBzdXBwb3J0ZWQgc3RhYmxlIHRyZWUuDQoN
CkkgYWdyZWUgdGhhdCBzcGVjaWZ5aW5nIHRoZSBvbGRlc3QgcmV2aXNpb24gcG9zc2libGUgd291
bGQgYmUgaGVscGZ1bC4NCg0KSG93ZXZlciwgSSBkb27igJl0IHRoaW5rIGZpbmRpbmcgdGhlIGFi
c29sdXRlIG9sZGVzdCByZXZpc2lvbiBzaG91bGQgYmUgKnJlcXVpcmVkKiDigJQgaW1hZ2luZSBh
IGJ1ZyB0aGF0IHdhcyBpbnRyb2R1Y2VkIGJldHdlZW4gMy4yIGFuZCAzLjMuICBJdOKAmXMgYWxz
byBwZXJmZWN0bHkgZmluZSBpZiB5b3UgZ28gYWxsIHRoZSB3YXkgYmFjayB0byA0LjIgYW5kIHN0
b3AgYmVjYXVzZSB5b3UgZ2V0IGJvcmVkLCBub3QgYmVjYXVzZSB5b3UgZm91bmQgb3V0IHRoYXQg
NC4xIGRpZG7igJl0IG5lZWQgaXQuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBjb250cmlidXRvcnMg
c2hvdWxkIGJlIGV4cGVjdGVkIHRvIGZpbmQgb3V0IGlmIGl0IG5lZWRzIHRvIGJlIGJhY2twb3J0
ZWQgKmF0IGxlYXN0KiB0byBmdWxseS1zdXBwb3J0ZWQgcmVsZWFzZXMuDQoNCkkgdGhpbmsgd2hh
dGV2ZXIgdGV4dCB3ZSBjb21lIHVwIHdpdGggc2hvdWxkIHByb2JhYmx5IHNheSB0aGF0IGNvbnRy
aWJ1dG9ycyBhcmUg4oCcZXhwZWN0ZWTigJ0gKG9yIOKAnHJlcXVpcmVk4oCdKSB0byBzcGVjaWZ5
IHdoaWNoIGN1cnJlbnRseS1zdXBwb3J0ZWQgcmVsZWFzZXMgbmVlZCB0aGUgYmFja3BvcnQ7ICBi
dXQg4oCcZW5jb3VyYWdlZOKAnSB0byBzcGVjaWZ5IGEgcmVsZWFzZSBhcyBmYXIgYmFjayBhcyBw
b3NzaWJsZS4NCg0KIC1HZW9yZ2U=


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 09:59:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 09:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOepG-0007xe-Hr; Wed, 15 Apr 2020 09:59:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOepE-0007xW-V3
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 09:59:20 +0000
X-Inumbo-ID: c60a5f06-7eff-11ea-8a21-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c60a5f06-7eff-11ea-8a21-12813bfff9fa;
 Wed, 15 Apr 2020 09:59:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ia7EMmFXKoD8KY9+fWiHsKqYonOUWQS6sBZd18xK2Ww=; b=Z8jaX7nArqqVN8PQQK/71ZQUqQ
 MvZNRE0Dq2iW4iNimuy/3GxYZZi5DnmdDafSo+D+FfTJ70KsujmmR+40eqOGWN7qM9dGmZVBDMbVK
 wMxPHw4ai6+m7uOW7XSR7RLl5QaYVnQNVybZYhogqJHlxCZysFo9CaNQA0xACmAtWAHw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOepC-0008Ba-An; Wed, 15 Apr 2020 09:59:18 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=edge-m1-r3-181.e-iad16.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOepC-0008EA-0X; Wed, 15 Apr 2020 09:59:18 +0000
Message-ID: <aba418d9b5d8832a2331c3164dc1a9fa1653f6be.camel@xen.org>
Subject: Re: [PATCH 1/2] x86: drop unnecessary page table walking in compat
 r/o M2P handling
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Date: Wed, 15 Apr 2020 10:59:16 +0100
In-Reply-To: <61746eff-0033-ccd7-6d77-3aabb8a426c8@suse.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
 <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
 <61746eff-0033-ccd7-6d77-3aabb8a426c8@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 2020-04-15 at 10:23 +0200, Jan Beulich wrote:
> We have a global variable where the necessary L2 table is recorded;
> no
> need to inspect L4 and L3 tables (and this way a few less places will
> eventually need adjustment when we want to support 5-level page
> tables).
> Also avoid setting up the L3 entry, as the address range never gets
> used
> anyway (it'll be dropped altogether in a subsequent patch).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -219,9 +219,7 @@ static void destroy_compat_m2p_mapping(s
>  {
>      unsigned long i, va, rwva, pt_pfn;
>      unsigned long smap = info->spfn, emap = info->spfn;
> -
> -    l3_pgentry_t *l3_ro_mpt;
> -    l2_pgentry_t *l2_ro_mpt;
> +    l2_pgentry_t *l2_ro_mpt = compat_idle_pg_table_l2;
>  
>      if ( smap > ((RDWR_COMPAT_MPT_VIRT_END -
> RDWR_COMPAT_MPT_VIRT_START) >> 2) )
>          return;
> @@ -229,12 +227,6 @@ static void destroy_compat_m2p_mapping(s
>      if ( emap > ((RDWR_COMPAT_MPT_VIRT_END -
> RDWR_COMPAT_MPT_VIRT_START) >> 2) )
>          emap = (RDWR_COMPAT_MPT_VIRT_END -
> RDWR_COMPAT_MPT_VIRT_START) >> 2;
>  
> -    l3_ro_mpt =
> l4e_to_l3e(idle_pg_table[l4_table_offset(HIRO_COMPAT_MPT_VIRT_START)]
> );
> -
> -    ASSERT(l3e_get_flags(l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_V
> IRT_START)]) & _PAGE_PRESENT);
> -
> -    l2_ro_mpt =
> l3e_to_l2e(l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)]);
> -
>      for ( i = smap; i < emap; )
>      {
>          va = HIRO_COMPAT_MPT_VIRT_START +
> @@ -323,7 +315,6 @@ static int setup_compat_m2p_table(struct
>      unsigned long i, va, smap, emap, rwva, epfn = info->epfn;
>      mfn_t mfn;
>      unsigned int n;
> -    l3_pgentry_t *l3_ro_mpt = NULL;
>      l2_pgentry_t *l2_ro_mpt = NULL;
>      int err = 0;
>  
> @@ -342,13 +333,7 @@ static int setup_compat_m2p_table(struct
>      emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
>                  ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
>  
> -    va = HIRO_COMPAT_MPT_VIRT_START +
> -         smap * sizeof(*compat_machine_to_phys_mapping);
> -    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
> -
> -    ASSERT(l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
> _PAGE_PRESENT);
> -
> -    l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
> +    l2_ro_mpt = compat_idle_pg_table_l2;
>  
>  #define MFN(x) (((x) << L2_PAGETABLE_SHIFT) / sizeof(unsigned int))
>  #define CNT ((sizeof(*frame_table) & -sizeof(*frame_table)) / \
> @@ -627,16 +612,10 @@ void __init paging_init(void)
>  #undef MFN
>  
>      /* Create user-accessible L2 directory to map the MPT for compat
> guests. */
> -    BUILD_BUG_ON(l4_table_offset(RDWR_MPT_VIRT_START) !=
> -                 l4_table_offset(HIRO_COMPAT_MPT_VIRT_START));
> -    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(
> -        HIRO_COMPAT_MPT_VIRT_START)]);
>      if ( (l2_ro_mpt = alloc_xen_pagetable()) == NULL )
>          goto nomem;
>      compat_idle_pg_table_l2 = l2_ro_mpt;
>      clear_page(l2_ro_mpt);
> -    l3e_write(&l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)
> ],
> -              l3e_from_paddr(__pa(l2_ro_mpt),
> __PAGE_HYPERVISOR_RO));
>      l2_ro_mpt += l2_table_offset(HIRO_COMPAT_MPT_VIRT_START);
>      /* Allocate and map the compatibility mode machine-to-phys
> table. */
>      mpt_size = (mpt_size >> 1) + (1UL << (L2_PAGETABLE_SHIFT - 1));

The code around here, I am wondering if there is a reason to put it in
this patch. If we bisect, we can end up in a commit which says the
address range of compat is still there in config.h, but actually it's
gone, so this probably belongs to the 2nd patch.

Apart from that,
Reviewed-by: Hongyan Xia <hongyxia@amazon.com>

I would like to drop relevant map/unmap patches and replace them with
the new clean-up ones (and place them at the beginning of the series),
if there is no objection with that.

Hongyan



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:15:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOf5D-0001Jx-EJ; Wed, 15 Apr 2020 10:15:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOf5C-0001Js-Ne
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:15:50 +0000
X-Inumbo-ID: 13b1b6f8-7f02-11ea-8a29-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 13b1b6f8-7f02-11ea-8a29-12813bfff9fa;
 Wed, 15 Apr 2020 10:15:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586945750;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=RqN8L0g5SnM+Z809FeY9xp0Pjnq0aBv7T4zdYHpAYdI=;
 b=XPS0n/FtKokdHrsc5EFfbu5JzL7LQ5bfNpheqr7DQOAc6ks6Q9Nst5Bh
 73vbupF3PseaaGWZndJMsh1H2Nk23jX8b7BiPyDpEbhvZTqyi9zlEAH13
 8Q267/9og8cVdPJBTGSZPIls5kfEw316Td/jm7wlAdCg+xcHLet5m5R7s 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: +7CT/fD0CjmUV+fQ2je+RVbd1B1GVGElboN0GfBDESj8Ic3YL5cT/5U8oasYibaSoQnYivOxKO
 W/QdOS8t0WcQmFrTOKBD0Ey+ZlnikX7RZCgldGoDTwot5FFAjNPU7QuFdKRiuXWBXA8KDHhNwc
 86iFwrCZp4c1Dpjs6afoWNsHnONXhvXA2gcz4WFUlMKEzzyMmseDL63M1D9TjPYtm9CtsCxy2C
 5DGWmus205099RRmxb3Zq79ecMammkC3e8y5FsV+f1qnUdq+XJJf3ZbqzGxyMpR1MoF792ZZPP
 bPk=
X-SBRS: 2.7
X-MesageID: 15687943
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="15687943"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH OSSTEST v2 1/2] exanime: test for SMT and add a host flag
Date: Wed, 15 Apr 2020 12:15:09 +0200
Message-ID: <20200415101509.8763-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200415085246.7945-1-roger.pau@citrix.com>
References: <20200415085246.7945-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Check if hosts have SMT based on the number of threads per core. A
value of threads per core greater than 1 implies SMT support.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Fix regex and set SMT if number of threads per core is > 1.
---
 sg-run-job     |  1 +
 ts-examine-cpu | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)
 create mode 100755 ts-examine-cpu

diff --git a/sg-run-job b/sg-run-job
index 97011843..aa7953ac 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -679,6 +679,7 @@ proc examine-host-examine {install} {
     if {$ok} {
 	run-ts -.  =           ts-examine-serial-post + host
 	run-ts .   =           ts-examine-iommu       + host
+	run-ts .   =           ts-examine-cpu         + host
 	run-ts .   =           ts-examine-logs-save   + host
 	run-ts .   =           ts-examine-hostprops-save
     }
diff --git a/ts-examine-cpu b/ts-examine-cpu
new file mode 100755
index 00000000..c30311ab
--- /dev/null
+++ b/ts-examine-cpu
@@ -0,0 +1,32 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2020 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# 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 Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+BEGIN { unshift @INC, qw(.); }
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+our $info = target_cmd_output_root($ho, 'xl info', 10);
+our $threads = $info =~ /^threads_per_core\s*:\s.*/m;
+
+logm("$ho->{Ident} threads per core: $threads");
+hostflag_putative_record($ho, "smt", $threads > 1);
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:16:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:16:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOf5k-0001M9-Rd; Wed, 15 Apr 2020 10:16:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Id/X=57=citrix.com=edvin.torok@srs-us1.protection.inumbo.net>)
 id 1jOf5j-0001M0-GS
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:16:23 +0000
X-Inumbo-ID: 275986c2-7f02-11ea-b58d-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 275986c2-7f02-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 10:16:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586945783;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=uxoowvEzcU0XcO4doOXu6CTfE5sQBFeU4yxc6ggHNw4=;
 b=cNmCRZYwhRS3HcT4i8K1EcGGp+v31YhIaFU292DaPjNIN24vn9eS74FW
 rAvnqlJ1y/KFVro0AlmPZ80WPSfT4eXFlRiGx5jQ6bCFaM1xS23lYSA8w
 fnTxvTmwcFBFoAQUx+o31WCEG+O0vBJRNF8mCypFTDhGeeQPidZ2CQOVa A=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=edvin.torok@citrix.com;
 spf=Pass smtp.mailfrom=edvin.torok@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 edvin.torok@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="edvin.torok@citrix.com";
 x-sender="edvin.torok@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 edvin.torok@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="edvin.torok@citrix.com";
 x-sender="edvin.torok@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="edvin.torok@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: dovn6DM/MjYd/S3FrCjJn85CKOvW3BoqwE8oh8nNm57TFf5tEtkLNG2fC/9cOf6I/fwYfWyNmm
 0cAtqNGdlVdoZb6io34Kjvl1fel+Sid+XMcSV9s7Fe6YvIRsY9wehA6UllyWTL3+9Ii63rPypu
 7sLCeJDjLovpTZE2nT9mAlpBaz8+LqDCiKdldve5nqD3a1tpjUnnUIE2Xjausp8j2SrntZjiHp
 Vxywf9Lz7nrvzGFMHFoP+TGQy+qorVKxBsFCRM+hDq90eFrYcuPsW9WK6ye03MjYblXKtdH24U
 qKQ=
X-SBRS: 2.7
X-MesageID: 15687966
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="15687966"
From: Edwin Torok <edvin.torok@citrix.com>
To: "jgross@suse.com" <jgross@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] docs: update xenstore migration design document
Thread-Topic: [PATCH] docs: update xenstore migration design document
Thread-Index: AQHWEwuHdbrYu4kO1kCcE9UH6bedb6h51i6A
Date: Wed, 15 Apr 2020 10:16:17 +0000
Message-ID: <fa75091bae05a728366498ceee225e96439948be.camel@citrix.com>
References: <20200414155942.3347-1-jgross@suse.com>
In-Reply-To: <20200414155942.3347-1-jgross@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <35466912C1B0214580E46588B71A51A5@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "julien@xen.org" <julien@xen.org>, "wl@xen.org" <wl@xen.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 "jbeulich@suse.com" <jbeulich@suse.com>, Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

T24gVHVlLCAyMDIwLTA0LTE0IGF0IDE3OjU5ICswMjAwLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0K
PiBJbiB0aGUgcGFzdCB0aGVyZSBoYXZlIGJlZW4gc2V2ZXJhbCBhdHRlbXB0cyB0byBtYWtlIFhl
bnN0b3JlDQo+IHJlc3RhcnRhYmxlLiBUaGlzIHJlcXVpcmVzIHRvIHRyYW5zZmVyIHRoZSBpbnRl
cm5hbCBYZW5zdG9yZSBzdGF0ZSB0bw0KPiB0aGUgbmV3IGluc3RhbmNlLiBXaXRoIHRoZSBYZW5z
dG9yZSBtaWdyYXRpb24gcHJvdG9jb2wgYWRkZWQgcmVjZW50bHkNCj4gdG8gWGVuJ3MgZG9jdW1l
bnRhdGlvbiBhIGZpcnN0IGJhc2UgaGFzIGJlZW4gZGVmaW5lZCB0byByZXByZXNlbnQgdGhlDQo+
IHN0YXRlIG9mIFhlbnN0b3JlLiBUaGlzIGNhbiBiZSBleHBhbmRlZCBhIGxpdHRsZSBiaXQgaW4g
b3JkZXIgdG8gaGF2ZQ0KPiBhIGZ1bGwgc3RhdGUgcmVwcmVzZW50YXRpb24gd2hpY2ggaXMgbmVl
ZGVkIGFzIGEgZmlyc3Qgc3RlcCBmb3IgbGl2ZQ0KPiB1cGRhdGluZyBYZW5zdG9yZS4NCj4gDQo+
IEFkZCBzb21lIGRlZmluaXRpb25zIHRvIGRlc2lnbnMveGVuc3RvcmUtbWlncmF0aW9uLm1kIHdo
aWNoIGFyZQ0KPiBuZWVkZWQNCj4gZm9yIGxpdmUgdXBkYXRlIG9mIHhlbnN0b3JlZC4NCj4gDQo+
IFNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCj4gLS0tDQo+
ICBkb2NzL2Rlc2lnbnMveGVuc3RvcmUtbWlncmF0aW9uLm1kIHwgOTANCj4gKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrLS0NCj4gIDEgZmlsZSBjaGFuZ2VkLCA4NyBpbnNlcnRp
b25zKCspLCAzIGRlbGV0aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL2RvY3MvZGVzaWducy94
ZW5zdG9yZS1taWdyYXRpb24ubWQNCj4gYi9kb2NzL2Rlc2lnbnMveGVuc3RvcmUtbWlncmF0aW9u
Lm1kDQo+IGluZGV4IDZhYjM1MWU4ZmUuLjA5YmI0NzAwYjQgMTAwNjQ0DQo+IC0tLSBhL2RvY3Mv
ZGVzaWducy94ZW5zdG9yZS1taWdyYXRpb24ubWQNCj4gKysrIGIvZG9jcy9kZXNpZ25zL3hlbnN0
b3JlLW1pZ3JhdGlvbi5tZA0KPiBAQCAtOSw2ICs5LDEwIEBAIHJlY29yZHMgbXVzdCBpbmNsdWRl
IGRldGFpbHMgb2YgcmVnaXN0ZXJlZCB4ZW5zdG9yZQ0KPiB3YXRjaGVzIGFzIHdlbGwgYXMNCj4g
IGNvbnRlbnQ7IGluZm9ybWF0aW9uIHRoYXQgY2Fubm90IGN1cnJlbnRseSBiZSByZWNvdmVyZWQg
ZnJvbQ0KPiBgeGVuc3RvcmVkYCwNCj4gIGFuZCBoZW5jZSBzb21lIGV4dGVuc2lvbiB0byB0aGUg
eGVuc3RvcmUgcHJvdG9jb2xbMl0gd2lsbCBhbHNvIGJlDQo+IHJlcXVpcmVkLg0KPiAgDQo+ICtB
cyBhIHNpbWlsYXIgc2V0IG9mIGRhdGEgaXMgbmVlZGVkIGZvciB0cmFuc2ZlcnJpbmcgeGVuc3Rv
cmUgZGF0YQ0KPiBmcm9tDQo+ICtvbmUgaW5zdGFuY2UgdG8gYW5vdGhlciB3aGVuIGxpdmUgdXBk
YXRpbmcgeGVuc3RvcmVkIHRoZSBzYW1lDQo+IGRlZmluaXRpb25zDQo+ICthcmUgYmVpbmcgdXNl
ZC4NCj4gKw0KPiAgVGhlICpsaWJ4ZW5saWdodCBEb21haW4gSW1hZ2UgRm9ybWF0KiBzcGVjaWZp
Y2F0aW9uWzNdIGFscmVhZHkNCj4gZGVmaW5lcyBhDQo+ICByZWNvcmQgdHlwZSBgRU1VTEFUT1Jf
WEVOU1RPUkVfREFUQWAgYnV0IHRoaXMgaXMgbm90IHN1aXRhYmxlIGZvcg0KPiAgdHJhbnNmZXJy
aW5nIHhlbnN0b3JlIGRhdGEgcGVydGFpbmluZyB0byB0aGUgZG9tYWluIGRpcmVjdGx5IGFzIGl0
DQo+IGlzDQo+IEBAIC00OCw3ICs1MiwxMCBAQCB3aGVyZSB0eXBlIGlzIG9uZSBvZiB0aGUgZm9s
bG93aW5nIHZhbHVlcw0KPiAgfCAgICAgICAgfCAweDAwMDAwMDAxOiBOT0RFX0RBVEEgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgfCAgICAgICAgfCAweDAwMDAwMDAyOiBXQVRDSF9E
QVRBICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgfCAgICAgICAgfCAweDAwMDAwMDAz
OiBUUkFOU0FDVElPTl9EQVRBICAgICAgICAgICAgICAgICAgICAgfA0KPiAtfCAgICAgICAgfCAw
eDAwMDAwMDA0IC0gMHhGRkZGRkZGRjogcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UgfA0KPiArfCAg
ICAgICAgfCAweDAwMDAwMDA0OiBUUkFOU0FDVElPTl9OT0RFX0RBVEEgICAgICAgICAgICAgICAg
fA0KPiArfCAgICAgICAgfCAweDAwMDAwMDA1OiBHVUVTVF9SSU5HX0RBVEEgICAgICAgICAgICAg
ICAgICAgICAgfA0KPiArfCAgICAgICAgfCAweDAwMDAwMDA2OiBET01BSU5fU1RBUlQgKGxpdmUg
dXBkYXRlIG9ubHkpICAgICAgfA0KPiArfCAgICAgICAgfCAweDAwMDAwMDA3IC0gMHhGRkZGRkZG
RjogcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UgfA0KPiAgDQo+ICANCj4gIGFuZCBkYXRhIGlzIG9u
ZSBvZiB0aGUgcmVjb3JkIGRhdGEgZm9ybWF0cyBkZXNjcmliZWQgaW4gdGhlDQo+IGZvbGxvd2lu
Zw0KPiBAQCAtNzksNyArODYsNyBAQCBhcyBmb2xsb3dzOg0KPiAgKy0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0rDQo+ICB8IHBlcm0gY291bnQgKE4pICAgICAgICAgICAgICAgIHwNCj4g
ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAtfCBwZXJtMCAgICAgICAgICAg
ICAgICAgICAgICAgICB8DQo+ICt8IHBlcm0xICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4g
ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAgLi4uDQo+ICArLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gQEAgLTkzLDcgKzEwMCw3IEBAIGFzIGZvbGxvd3M6
DQo+ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gIGBgYA0KPiAgDQo+IC13
aGVyZSBwZXJtMC4uTiBhcmUgZm9ybWF0dGVkIGFzIGZvbGxvd3M6DQo+ICt3aGVyZSBwZXJtMS4u
TiBhcmUgZm9ybWF0dGVkIGFzIGZvbGxvd3M6DQo+ICANCj4gIA0KPiAgYGBgDQo+IEBAIC0xNjQs
NiArMTcxLDgzIEBAIGFzIGZvbGxvd3M6DQo+ICB3aGVyZSB0eF9pZCBpcyB0aGUgbm9uLXplcm8g
aWRlbnRpZmllciB2YWx1ZXMgb2YgYW4gb3Blbg0KPiB0cmFuc2FjdGlvbi4NCj4gIA0KPiAgDQo+
ICsqKlRSQU5TQUNUSU9OX05PREVfREFUQSoqDQo+ICsNCj4gKw0KPiArRWFjaCBUUkFOU0FDVElP
Tl9OT0RFX0RBVEEgcmVjb3JkIHNwZWNpZmllcyBhIHRyYW5zYWN0aW9uIGxvY2FsDQo+IHhlbnN0
b3JlDQo+ICtub2RlLiBJdHMgaXMgc2ltaWxhciB0byB0aGUgTk9ERV9EQVRBIHJlY29yZCB3aXRo
IHRoZSBhZGRpdGlvbiBvZiBhDQo+ICt0cmFuc2FjdGlvbiBpZDoNCj4gKw0KPiArYGBgDQo+ICsg
ICAgMCAgICAgICAxICAgICAgIDIgICAgICAgMyAgICAgb2N0ZXQNCj4gKystLS0tLS0tKy0tLS0t
LS0rLS0tLS0tLSstLS0tLS0tKw0KPiArfCBUUkFOU0FDVElPTl9OT0RFX0RBVEEgICAgICAgICB8
DQo+ICsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gK3wgdHhfaWQgICAgICAg
ICAgICAgICAgICAgICAgICAgfA0KPiArKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r
DQo+ICt8IHBhdGggbGVuZ3RoICAgICAgICAgICAgICAgICAgIHwNCj4gKystLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tKw0KPiArfCBwYXRoIGRhdGEgICAgICAgICAgICAgICAgICAgICB8
DQo+ICsuLi4NCj4gK3wgcGFkICgwIHRvIDMgb2N0ZXRzKSAgICAgICAgICAgfA0KPiArKy0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICt8IHBlcm0gY291bnQgKE4pICAgICAgICAg
ICAgICAgIHwNCj4gKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiArfCBwZXJt
MSAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSsNCj4gKy4uLg0KPiArKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+
ICt8IHBlcm1OICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gKystLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tKw0KPiArfCB2YWx1ZSBsZW5ndGggICAgICAgICAgICAgICAgICB8DQo+
ICsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gK3wgdmFsdWUgZGF0YSAgICAg
ICAgICAgICAgICAgICAgfA0KPiArLi4uDQo+ICt8IHBhZCAoMCB0byAzIG9jdGV0cykgICAgICAg
ICAgIHwNCj4gKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiArYGBgDQo+ICsN
Cj4gK3doZXJlIHBlcm0xLi5OIGFyZSBmb3JtYXR0ZWQgYXMgc3BlY2lmaWVkIGluIHRoZSBOT0RF
X0RBVEEgcmVjb3JkLiBBDQo+IHBlcm0NCj4gK2NvdW50IG9mIDAgZGVub3RlcyBhIG5vZGUgaGF2
aW5nIGJlZW4gZGVsZXRlZCBpbiB0aGUgdHJhbnNhY3Rpb24uDQoNCg0Kb3hlbnN0b3JlZCBhbHNv
IHRyYWNrcyB0aGUgbnVtYmVyIG9mIG9wZXJhdGlvbnMgdGhhdCBhIHRyYW5zYWN0aW9uIGhhcw0K
cGVyZm9ybWVkLCB3aGljaCBpbmNsdWRlcyByZWFkb25seSBvcGVyYXRpb25zIEFGQUlDVCwgd2hp
Y2ggY2Fubm90IGJlDQppbmZlcnJlZCBmcm9tIGNvdW50aW5nIFRSQU5TQUNUSU9OX05PREVfREFU
QSBlbnRyaWVzLg0KSSB0aGluayB0aGUgb3BlcmF0aW9uIGNvdW50IHdvdWxkIGhhdmUgdG8gYmUg
c2VyaWFsaXplZCBhcyBwYXJ0IG9mDQpUUkFOU0FDVElPTl9EQVRBLg0KDQo+ICsNCj4gKw0KPiAr
KipHVUVTVF9SSU5HX0RBVEEqKg0KPiArDQo+ICsNCj4gK1RoZSBHVUVTVF9SSU5HX0RBVEEgcmVj
b3JkIGlzIHVzZWQgdG8gdHJhbnNmZXIgZGF0YSB3aGljaCBpcyBwZW5kaW5nDQo+IHRvIGJlDQo+
ICt3cml0dGVuIHRvIHRoZSBndWVzdCdzIHhlbnN0b3JlIHJpbmcgYnVmZmVyLiBJdCBzaSBmb3Jt
YXR0ZWQgYXMgDQoNCnR5cG86IHMvc2kvaXMvDQoNCj4gZm9sbG93czoNCj4gKw0KPiArDQo+ICtg
YGANCj4gKystLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKw0KPiArfCBHVUVTVF9SSU5H
X0RBVEEgICAgICAgICAgICAgICB8DQo+ICsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSsNCj4gK3wgdmFsdWUgbGVuZ3RoICAgICAgICAgICAgICAgICAgfA0KPiArKy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICt8IHZhbHVlIGRhdGEgICAgICAgICAgICAgICAgICAg
IHwNCj4gKy4uLg0KPiArfCBwYWQgKDAgdG8gMyBvY3RldHMpICAgICAgICAgICB8DQo+ICsrLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gK2BgYA0KPiArDQo+ICsqKkRPTUFJTl9T
VEFSVCoqDQo+ICsNCj4gKw0KPiArRm9yIGxpdmUgdXBkYXRpbmcgeGVuc3RvcmVkIGRhdGEgb2Yg
bXVsdGlwbGUgZG9tYWlucyBuZWVkcyB0byBiZQ0KPiB0cmFuc2ZlcnJlZC4NCj4gK0ZvciB0aGlz
IHB1cnBvc2UgdGhlIERPTUFJTl9TVEFSVCByZWNvcmQgaXMgYmVpbmcgdXNlZC4gQWxsIHJlY29y
ZHMNCj4gb2YgdHlwZXMNCj4gK290aGVyIHRoYW4gTk9ERV9EQVRBIGFsd2F5cyByZWxhdGUgdG8g
dGhlIGxhc3QgRE9NQUlOX1NUQVJUIHJlY29yZA0KPiBpbiB0aGUNCj4gK3N0cmVhbS4gQSBET01B
SU5fU1RBUlQgcmVjb3JkIGp1c3QgY29udGFpbnMgYSBkb21haW4taWQ6DQo+ICsNCj4gKw0KPiAr
YGBgDQo+ICsrLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSsNCj4gK3wgRE9NQUlOX1NU
QVJUICAgICAgICAgICAgICAgICAgfA0KPiArKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0rDQo+ICt8IGRvbWlkICAgICAgICAgfCBwYWQgICAgICAgICAgIHwNCj4gKystLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiArYGBgDQoNClRoZXJlIGlzIHNvbWUgbW9yZSBpbmZv
cm1hdGlvbiB0aGF0IG1pZ2h0IGJlIHVzZWZ1bCBoZXJlOiBtZm4gYW5kDQpyZW1vdGVfcG9ydC4g
KGJhc2VkIG9uIHRoZSBpbmZvcm1hdGlvbiB0aGF0IElOVFJPRFVDRSBuZWVkcykNCg0KQmVzdCBy
ZWdhcmRzLA0KLS1FZHdpbg0K


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:28:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOfGy-0002LT-2I; Wed, 15 Apr 2020 10:28:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOfGw-0002LO-9W
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:27:58 +0000
X-Inumbo-ID: c577f2b6-7f03-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c577f2b6-7f03-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 10:27:56 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BA6DBAC69;
 Wed, 15 Apr 2020 10:27:54 +0000 (UTC)
Subject: Re: [PATCH 02/12] xen/arm: introduce arch_xen_dom_flags and direct_map
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-2-sstabellini@kernel.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <4130f640-a664-a9e7-fcd7-85bbd58287e4@suse.com>
Date: Wed, 15 Apr 2020 12:27:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-2-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>,
 George Dunlap <George.Dunlap@eu.citrix.com>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 03:02, Stefano Stabellini wrote:
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -682,6 +682,7 @@ int arch_domain_create(struct domain *d,
>          return 0;
>  
>      ASSERT(config != NULL);
> +    d->arch.direct_map = flags != NULL ? flags->arch.is_direct_map : false;

Shouldn't "true" here imply ->disable_migrate also getting
set to true? Or is this already the case anyway for domains
created right at boot?

> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2527,6 +2527,7 @@ int __init construct_dom0(struct domain *d)
>  
>      iommu_hwdom_init(d);
>  
> +    d->arch.direct_map = true;

Shouldn't this get set via arch_domain_create() instead?

> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -418,6 +418,8 @@ struct arch_domain
>      uint32_t emulation_flags;
>  } __cacheline_aligned;
>  
> +struct arch_xen_dom_flags {};

This trivial x86 change
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:34:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:34:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOfN5-0003CP-Tb; Wed, 15 Apr 2020 10:34:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOfN4-0003CK-IH
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:34:18 +0000
X-Inumbo-ID: a830e04a-7f04-11ea-8a2b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a830e04a-7f04-11ea-8a2b-12813bfff9fa;
 Wed, 15 Apr 2020 10:34:17 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 55CC2AC69;
 Wed, 15 Apr 2020 10:34:15 +0000 (UTC)
Subject: Re: [PATCH 1/2] x86: drop unnecessary page table walking in compat
 r/o M2P handling
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
 <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
 <61746eff-0033-ccd7-6d77-3aabb8a426c8@suse.com>
 <aba418d9b5d8832a2331c3164dc1a9fa1653f6be.camel@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <013b0d15-6901-bb87-6b0d-9233f9bf50e6@suse.com>
Date: Wed, 15 Apr 2020 12:34:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <aba418d9b5d8832a2331c3164dc1a9fa1653f6be.camel@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 11:59, Hongyan Xia wrote:
> On Wed, 2020-04-15 at 10:23 +0200, Jan Beulich wrote:
>> @@ -627,16 +612,10 @@ void __init paging_init(void)
>>  #undef MFN
>>  
>>      /* Create user-accessible L2 directory to map the MPT for compat
>> guests. */
>> -    BUILD_BUG_ON(l4_table_offset(RDWR_MPT_VIRT_START) !=
>> -                 l4_table_offset(HIRO_COMPAT_MPT_VIRT_START));
>> -    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(
>> -        HIRO_COMPAT_MPT_VIRT_START)]);
>>      if ( (l2_ro_mpt = alloc_xen_pagetable()) == NULL )
>>          goto nomem;
>>      compat_idle_pg_table_l2 = l2_ro_mpt;
>>      clear_page(l2_ro_mpt);
>> -    l3e_write(&l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)
>> ],
>> -              l3e_from_paddr(__pa(l2_ro_mpt),
>> __PAGE_HYPERVISOR_RO));
>>      l2_ro_mpt += l2_table_offset(HIRO_COMPAT_MPT_VIRT_START);
>>      /* Allocate and map the compatibility mode machine-to-phys
>> table. */
>>      mpt_size = (mpt_size >> 1) + (1UL << (L2_PAGETABLE_SHIFT - 1));
> 
> The code around here, I am wondering if there is a reason to put it in
> this patch. If we bisect, we can end up in a commit which says the
> address range of compat is still there in config.h, but actually it's
> gone, so this probably belongs to the 2nd patch.

I could be done either way, I guess. Note though how patch 2's
description starts with "Now that we don't properly hook things
up into the page tables anymore". I.e. after this patch the
address range continues to exist solely for calculation purposes.

> Apart from that,
> Reviewed-by: Hongyan Xia <hongyxia@amazon.com>

Thanks.

> I would like to drop relevant map/unmap patches and replace them with
> the new clean-up ones (and place them at the beginning of the series),
> if there is no objection with that.

Depending on turnaround, I'd much rather see this go in before
you re-post. But if you feel like making it part of your series,
go ahead.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:35:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:35:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOfOe-0003JD-LU; Wed, 15 Apr 2020 10:35:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+yDq=57=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOfOd-0003J8-5s
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:35:55 +0000
X-Inumbo-ID: df61b148-7f04-11ea-8a2b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id df61b148-7f04-11ea-8a2b-12813bfff9fa;
 Wed, 15 Apr 2020 10:35:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=L87jQAE7GE8jHv7FAN0VirH5MQhaypPsJDf8TlGnwlg=; b=SWQipN0BIFluTbuY+Y4RnnY8V
 6igeWMQpgiqo1nz5pPLGB4KsM6kuRuqwy8zkTWSoH29XdlJpno3q3Ua2uc0zk8DEwz8Z0P3KAzCZO
 ElsKqZz3rykv9RBLstgu87R+1Ps5oUpSI+E1iCAL1JWSPnL4OqakpEKRA0/LXxs76+PBk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOfOX-0000XI-1U; Wed, 15 Apr 2020 10:35:49 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOfOW-0005FH-LX; Wed, 15 Apr 2020 10:35:48 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOfOW-0004xw-KZ; Wed, 15 Apr 2020 10:35:48 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149674-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-coverity test] 149674: all pass - PUSHED
X-Osstest-Versions-This: xen=fcd06227f83643194f8018f8dd37adce57763a61
X-Osstest-Versions-That: xen=7372466b21c3b6c96bb7a52754e432bac883a1e3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 15 Apr 2020 10:35:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen                  fcd06227f83643194f8018f8dd37adce57763a61
baseline version:
 xen                  7372466b21c3b6c96bb7a52754e432bac883a1e3

Last test of basis   149630  2020-04-12 09:19:20 Z    3 days
Testing same since   149674  2020-04-15 09:19:13 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexandru Isaila <aisaila@bitdefender.com>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>
  Wei Liu <wl@xen.org>

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
   7372466b21..fcd06227f8  fcd06227f83643194f8018f8dd37adce57763a61 -> coverity-tested/smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:36:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:36:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOfPC-0003MR-3P; Wed, 15 Apr 2020 10:36:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOfPA-0003ME-D9
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:36:28 +0000
X-Inumbo-ID: f61599b8-7f04-11ea-8a2c-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f61599b8-7f04-11ea-8a2c-12813bfff9fa;
 Wed, 15 Apr 2020 10:36:27 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C197FAC69;
 Wed, 15 Apr 2020 10:36:25 +0000 (UTC)
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
To: Julien Grall <julien@xen.org>
References: <20200410164942.9747-1-sstabellini@kernel.org>
 <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
 <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
 <707a1448-be1d-0aa8-6b11-a33eb247304f@suse.com>
 <04881FC6-A816-44AB-8F25-54E5A265707E@citrix.com>
 <49c732e6-d30d-0892-0bd7-65c082da0429@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <267d8446-39ec-3d4b-3e01-5b57e403932d@suse.com>
Date: Wed, 15 Apr 2020 12:36:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <49c732e6-d30d-0892-0bd7-65c082da0429@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Lars Kurth <lars.kurth@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 11:49, Julien Grall wrote:
> 
> 
> On 15/04/2020 10:43, George Dunlap wrote:
>>
>>
>>> On Apr 15, 2020, at 7:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>
>>> On 14.04.2020 18:54, Stefano Stabellini wrote:
>>>> On Tue, 14 Apr 2020, Jan Beulich wrote:
>>>>> On 10.04.2020 18:49, Stefano Stabellini wrote:
>>>>
>> [snip]
>>>>>> +    Backport: all
>>>>>> +
>>>>>> +It marks a commit for being a candidate for backports to all relevant
>>>>>> +trees.
>>>>>
>>>>> I'm unconvinced of the utility of this form - what "all" resolves to
>>>>> changes over time. There's almost always a first version where a
>>>>> particular issue was introduced. If we want this to be generally
>>>>> useful, imo we shouldn't limit the scope of the tag to the upstream
>>>>> maintained stable trees.
>>>>
>>>> The reason why I suggested also to have a "wildcard" version of this
>>>> tag, is that the person adding the tag (could be the contributor trying
>>>> to be helpful) might not know exactly to which stable trees the patch
>>>> should be backported to.
>>>>
>>>> Writing this sentence, I realize that I really meant "any" rather than
>>>> "all". Would you prefer if I used "any"? Or we could even suggest to leave
>>>> it black like this:
>>>>
>>>>   Backport:
>>>>
>>>> But it looks a bit weird.
>>>
>>> Indeed. Instead of "all" or "any", how about "yes", "unspecified", or
>>> "unknown"? Nevertheless, I still think people asking for a backport
>>> should be nudged towards determining the applicable range; them not
>>> doing so effectively pushes the burden to the general maintainers or
>>> the stable tree ones, both of which scales less well. Omitting the
>>> tag if they don't want to invest the time would to me then seem to
>>> be the cleanest alternative. Albeit I'm sure views here will vary.
>>
>> FWIW asking people adding the tag to do the work of figuring out which versions to backport to makes sense to me.
> 
> If you ask the contributor to do the work then you need to give guidance on the "older" version you can specify in Backport.
> 
> For instance, let say the bug was introduced in Xen 4.2. Are we allowing the user to specify Backport: 4.2+ or should it be 4.11+?
> 
> I would favor the former as this helps for downstream user which haven't yet moved to the supported stable tree.

In an earlier reply I did suggest the same, for the same reason.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:38:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOfRD-0003XK-LY; Wed, 15 Apr 2020 10:38:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOfRD-0003XF-4t
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:38:35 +0000
X-Inumbo-ID: 41ab44ae-7f05-11ea-8a2c-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 41ab44ae-7f05-11ea-8a2c-12813bfff9fa;
 Wed, 15 Apr 2020 10:38:34 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DBC5BAC8F;
 Wed, 15 Apr 2020 10:38:32 +0000 (UTC)
Subject: Re: [XEN PATCH v4] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: "Shamsundara Havanur, Harsha" <havanur@amazon.com>
References: <4b6c017245698c18b063d156be645b8b633c0a99.1586884502.git.havanur@amazon.com>
 <81c7ca01-c272-9114-a5d0-12ca94090eb2@suse.com>
 <538d839fda5fc78c7519200e990d1888e56a6e06.camel@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <c21951c0-4e2f-6268-c17e-99beecd9deb7@suse.com>
Date: Wed, 15 Apr 2020 12:38:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <538d839fda5fc78c7519200e990d1888e56a6e06.camel@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 "wl@xen.org" <wl@xen.org>, "roger.pau@citrix.com" <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 11:32, Shamsundara Havanur, Harsha wrote:
> On Wed, 2020-04-15 at 09:13 +0200, Jan Beulich wrote:
>> On 14.04.2020 19:15, Harsha Shamsundara Havanur wrote:
>>> @@ -526,10 +538,17 @@ void pci_setup(void)
>>>           * has IO enabled, even if there is no I/O BAR on that
>>>           * particular device.
>>>           */
>>> -        cmd = pci_readw(vga_devfn, PCI_COMMAND);
>>> -        cmd |= PCI_COMMAND_IO;
>>> -        pci_writew(vga_devfn, PCI_COMMAND, cmd);
>>> +        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
>>>      }
>>> +
>>> +    /* Enable bus master, memory and I/O decode. */
>>> +    for ( devfn = 0; devfn < 256; devfn++ )
>>> +        if ( pci_devfn_decode_type[devfn] )
>>> +        {
>>> +            cmd = pci_readw(devfn, PCI_COMMAND);
>>> +            cmd |= (PCI_COMMAND_MASTER |
>>> pci_devfn_decode_type[devfn]);
>>> +            pci_writew(devfn, PCI_COMMAND, cmd);
>>> +        }
>>
>> This still regresses the setting of MASTER afaict: You only set
>> that bit now if either IO or MEMORY would also get set. But be
>> sure to honor the original code not doing the write when vendor/
>> device IDs are all ones.
>>
> If condition ensures that for devices with vendor/device IDs all ones
> are skipped as it would evaluate to false. But this would also skip
> enabling Bus master for devices whose vendor/device IDs are not all
> ones but IO or memory BARs are not programmed for them. Is there a
> possibility of this happening?

I think so, yes - programming of DMA requests can in principle also
be done via custom config space fields.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:44:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:44:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOfXD-0004OK-IF; Wed, 15 Apr 2020 10:44:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOfXC-0004OF-5H
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:44:46 +0000
X-Inumbo-ID: 1e5a4b2a-7f06-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1e5a4b2a-7f06-11ea-b4f4-bc764e2007e4;
 Wed, 15 Apr 2020 10:44:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id EDA5BAC51;
 Wed, 15 Apr 2020 10:44:42 +0000 (UTC)
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
To: George Dunlap <George.Dunlap@citrix.com>
References: <20200410164942.9747-1-sstabellini@kernel.org>
 <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
 <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
 <707a1448-be1d-0aa8-6b11-a33eb247304f@suse.com>
 <04881FC6-A816-44AB-8F25-54E5A265707E@citrix.com>
 <49c732e6-d30d-0892-0bd7-65c082da0429@xen.org>
 <10D98CF7-E38E-44C3-AF24-C93088F6682D@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <454b13b1-2901-d864-6fc8-bc4f338a14d6@suse.com>
Date: Wed, 15 Apr 2020 12:44:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <10D98CF7-E38E-44C3-AF24-C93088F6682D@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Lars Kurth <lars.kurth@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 11:56, George Dunlap wrote:
> 
> 
>> On Apr 15, 2020, at 10:49 AM, Julien Grall <julien@xen.org> wrote:
>>
>>
>>
>> On 15/04/2020 10:43, George Dunlap wrote:
>>>> On Apr 15, 2020, at 7:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>
>>>> On 14.04.2020 18:54, Stefano Stabellini wrote:
>>>>> On Tue, 14 Apr 2020, Jan Beulich wrote:
>>>>>> On 10.04.2020 18:49, Stefano Stabellini wrote:
>>>>>
>>> [snip]
>>>>>>> +    Backport: all
>>>>>>> +
>>>>>>> +It marks a commit for being a candidate for backports to all relevant
>>>>>>> +trees.
>>>>>>
>>>>>> I'm unconvinced of the utility of this form - what "all" resolves to
>>>>>> changes over time. There's almost always a first version where a
>>>>>> particular issue was introduced. If we want this to be generally
>>>>>> useful, imo we shouldn't limit the scope of the tag to the upstream
>>>>>> maintained stable trees.
>>>>>
>>>>> The reason why I suggested also to have a "wildcard" version of this
>>>>> tag, is that the person adding the tag (could be the contributor trying
>>>>> to be helpful) might not know exactly to which stable trees the patch
>>>>> should be backported to.
>>>>>
>>>>> Writing this sentence, I realize that I really meant "any" rather than
>>>>> "all". Would you prefer if I used "any"? Or we could even suggest to leave
>>>>> it black like this:
>>>>>
>>>>>  Backport:
>>>>>
>>>>> But it looks a bit weird.
>>>>
>>>> Indeed. Instead of "all" or "any", how about "yes", "unspecified", or
>>>> "unknown"? Nevertheless, I still think people asking for a backport
>>>> should be nudged towards determining the applicable range; them not
>>>> doing so effectively pushes the burden to the general maintainers or
>>>> the stable tree ones, both of which scales less well. Omitting the
>>>> tag if they don't want to invest the time would to me then seem to
>>>> be the cleanest alternative. Albeit I'm sure views here will vary.
>>> FWIW asking people adding the tag to do the work of figuring out which versions to backport to makes sense to me.
>>
>> If you ask the contributor to do the work then you need to give guidance on the "older" version you can specify in Backport.
>>
>> For instance, let say the bug was introduced in Xen 4.2. Are we allowing the user to specify Backport: 4.2+ or should it be 4.11+?
>>
>> I would favor the former as this helps for downstream user which haven't yet moved to the supported stable tree.
> 
> I agree that specifying the oldest revision possible would be helpful.
> 
> However, I don’t think finding the absolute oldest revision should be *required* — imagine a bug that was introduced between 3.2 and 3.3.  It’s also perfectly fine if you go all the way back to 4.2 and stop because you get bored, not because you found out that 4.1 didn’t need it.

In which case I'd like there to be a (canonical?) way of expressing
this, like in XSAs we say "at least back to" in such a case.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:49:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOfbL-0004Xa-91; Wed, 15 Apr 2020 10:49:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HD5o=57=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jOfbJ-0004XV-Ur
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:49:01 +0000
X-Inumbo-ID: b7171ad2-7f06-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b7171ad2-7f06-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 10:49:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 35D16AEC3;
 Wed, 15 Apr 2020 10:48:59 +0000 (UTC)
Subject: Re: [PATCH] docs: update xenstore migration design document
To: Edwin Torok <edvin.torok@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <20200414155942.3347-1-jgross@suse.com>
 <fa75091bae05a728366498ceee225e96439948be.camel@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <45a1d439-fdba-5de9-51ec-d75f55746b5e@suse.com>
Date: Wed, 15 Apr 2020 12:48:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <fa75091bae05a728366498ceee225e96439948be.camel@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "julien@xen.org" <julien@xen.org>, "wl@xen.org" <wl@xen.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 "jbeulich@suse.com" <jbeulich@suse.com>, Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.20 12:16, Edwin Torok wrote:
> On Tue, 2020-04-14 at 17:59 +0200, Juergen Gross wrote:
>> In the past there have been several attempts to make Xenstore
>> restartable. This requires to transfer the internal Xenstore state to
>> the new instance. With the Xenstore migration protocol added recently
>> to Xen's documentation a first base has been defined to represent the
>> state of Xenstore. This can be expanded a little bit in order to have
>> a full state representation which is needed as a first step for live
>> updating Xenstore.
>>
>> Add some definitions to designs/xenstore-migration.md which are
>> needed
>> for live update of xenstored.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   docs/designs/xenstore-migration.md | 90
>> ++++++++++++++++++++++++++++++++++++--
>>   1 file changed, 87 insertions(+), 3 deletions(-)
>>
>> diff --git a/docs/designs/xenstore-migration.md
>> b/docs/designs/xenstore-migration.md
>> index 6ab351e8fe..09bb4700b4 100644
>> --- a/docs/designs/xenstore-migration.md
>> +++ b/docs/designs/xenstore-migration.md
>> @@ -9,6 +9,10 @@ records must include details of registered xenstore
>> watches as well as
>>   content; information that cannot currently be recovered from
>> `xenstored`,
>>   and hence some extension to the xenstore protocol[2] will also be
>> required.
>>   
>> +As a similar set of data is needed for transferring xenstore data
>> from
>> +one instance to another when live updating xenstored the same
>> definitions
>> +are being used.
>> +
>>   The *libxenlight Domain Image Format* specification[3] already
>> defines a
>>   record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
>>   transferring xenstore data pertaining to the domain directly as it
>> is
>> @@ -48,7 +52,10 @@ where type is one of the following values
>>   |        | 0x00000001: NODE_DATA                            |
>>   |        | 0x00000002: WATCH_DATA                           |
>>   |        | 0x00000003: TRANSACTION_DATA                     |
>> -|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
>> +|        | 0x00000004: TRANSACTION_NODE_DATA                |
>> +|        | 0x00000005: GUEST_RING_DATA                      |
>> +|        | 0x00000006: DOMAIN_START (live update only)      |
>> +|        | 0x00000007 - 0xFFFFFFFF: reserved for future use |
>>   
>>   
>>   and data is one of the record data formats described in the
>> following
>> @@ -79,7 +86,7 @@ as follows:
>>   +-------------------------------+
>>   | perm count (N)                |
>>   +-------------------------------+
>> -| perm0                         |
>> +| perm1                         |
>>   +-------------------------------+
>>   ...
>>   +-------------------------------+
>> @@ -93,7 +100,7 @@ as follows:
>>   +-------------------------------+
>>   ```
>>   
>> -where perm0..N are formatted as follows:
>> +where perm1..N are formatted as follows:
>>   
>>   
>>   ```
>> @@ -164,6 +171,83 @@ as follows:
>>   where tx_id is the non-zero identifier values of an open
>> transaction.
>>   
>>   
>> +**TRANSACTION_NODE_DATA**
>> +
>> +
>> +Each TRANSACTION_NODE_DATA record specifies a transaction local
>> xenstore
>> +node. Its is similar to the NODE_DATA record with the addition of a
>> +transaction id:
>> +
>> +```
>> +    0       1       2       3     octet
>> ++-------+-------+-------+-------+
>> +| TRANSACTION_NODE_DATA         |
>> ++-------------------------------+
>> +| tx_id                         |
>> ++-------------------------------+
>> +| path length                   |
>> ++-------------------------------+
>> +| path data                     |
>> +...
>> +| pad (0 to 3 octets)           |
>> ++-------------------------------+
>> +| perm count (N)                |
>> ++-------------------------------+
>> +| perm1                         |
>> ++-------------------------------+
>> +...
>> ++-------------------------------+
>> +| permN                         |
>> ++-------------------------------+
>> +| value length                  |
>> ++-------------------------------+
>> +| value data                    |
>> +...
>> +| pad (0 to 3 octets)           |
>> ++-------------------------------+
>> +```
>> +
>> +where perm1..N are formatted as specified in the NODE_DATA record. A
>> perm
>> +count of 0 denotes a node having been deleted in the transaction.
> 
> 
> oxenstored also tracks the number of operations that a transaction has
> performed, which includes readonly operations AFAICT, which cannot be
> inferred from counting TRANSACTION_NODE_DATA entries.
> I think the operation count would have to be serialized as part of
> TRANSACTION_DATA.

No, I don't think this is necessary. The read nodes can be included in
the TRANSACTION_NODE_DATA entries, too, as long as the transaction is
terminated with failure (EAGAIN). In case oxenstored is needing more,
e.g. access types, we can include that.

The TRANSACTION_NODE_DATA entries are primarily needed to ensure
returning consistent data in case of reads of nodes after having them
accessed before in the same transaction.

> 
>> +
>> +
>> +**GUEST_RING_DATA**
>> +
>> +
>> +The GUEST_RING_DATA record is used to transfer data which is pending
>> to be
>> +written to the guest's xenstore ring buffer. It si formatted as
> 
> typo: s/si/is/

Thanks.

> 
>> follows:
>> +
>> +
>> +```
>> ++-------+-------+-------+-------+
>> +| GUEST_RING_DATA               |
>> ++-------------------------------+
>> +| value length                  |
>> ++-------------------------------+
>> +| value data                    |
>> +...
>> +| pad (0 to 3 octets)           |
>> ++-------------------------------+
>> +```
>> +
>> +**DOMAIN_START**
>> +
>> +
>> +For live updating xenstored data of multiple domains needs to be
>> transferred.
>> +For this purpose the DOMAIN_START record is being used. All records
>> of types
>> +other than NODE_DATA always relate to the last DOMAIN_START record
>> in the
>> +stream. A DOMAIN_START record just contains a domain-id:
>> +
>> +
>> +```
>> ++-------+-------+-------+-------+
>> +| DOMAIN_START                  |
>> ++-------------------------------+
>> +| domid         | pad           |
>> ++-------------------------------+
>> +```
> 
> There is some more information that might be useful here: mfn and
> remote_port. (based on the information that INTRODUCE needs)

Oh yes, indeed. And additionally we need something like SOCKET_START
with the file descriptor of a socket based connection, and a global
entry with the main socket file descriptor used for connecting.


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 10:50:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 10:50:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOfd6-0005J0-Qx; Wed, 15 Apr 2020 10:50:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOfd5-0005Iu-TW
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 10:50:51 +0000
X-Inumbo-ID: f8ec7eb6-7f06-11ea-8a2e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f8ec7eb6-7f06-11ea-8a2e-12813bfff9fa;
 Wed, 15 Apr 2020 10:50:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=wxLnGTPGz04zsEyi0EroQJbAWZRX1iOLm9OqENiSLtM=; b=AtXCFLudnpeZf1zX6WreoQYyDn
 pkpim0HYQBiW0brJaUpAPmVuKX9RZvTAaLB+pgk5+frUOw1UVCAdAc3dwqXKd+4RW0UgC3tC73eJx
 F4hf2KOdGsJFjomRTYBFjQHRNPXdK3YGwq6n5R1YZW7FMpyd0Me54xCxHUARi1sBNsDw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOfd4-0000pR-CW; Wed, 15 Apr 2020 10:50:50 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=edge-m1-r3-181.e-iad16.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOfd4-0003j9-2G; Wed, 15 Apr 2020 10:50:50 +0000
Message-ID: <edb5dcfc98ae5d9de283f3abb656cef58a3c8f6d.camel@xen.org>
Subject: Re: [PATCH 1/2] x86: drop unnecessary page table walking in compat
 r/o M2P handling
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Date: Wed, 15 Apr 2020 11:50:48 +0100
In-Reply-To: <013b0d15-6901-bb87-6b0d-9233f9bf50e6@suse.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
 <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
 <61746eff-0033-ccd7-6d77-3aabb8a426c8@suse.com>
 <aba418d9b5d8832a2331c3164dc1a9fa1653f6be.camel@xen.org>
 <013b0d15-6901-bb87-6b0d-9233f9bf50e6@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 2020-04-15 at 12:34 +0200, Jan Beulich wrote:
> On 15.04.2020 11:59, Hongyan Xia wrote:
> > ...
> > I would like to drop relevant map/unmap patches and replace them
> > with
> > the new clean-up ones (and place them at the beginning of the
> > series),
> > if there is no objection with that.
> 
> Depending on turnaround, I'd much rather see this go in before
> you re-post. But if you feel like making it part of your series,
> go ahead.

I actually also very much prefer to see those clean-up patches go in
before I post the next revision, so please go ahead.

I will post the next revision minus patch 4 then to avoid conflict.

Hongyan



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:08:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOftx-0006Pj-Oj; Wed, 15 Apr 2020 11:08:17 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOftw-0006Pe-4w
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:08:16 +0000
X-Inumbo-ID: 670afda8-7f09-11ea-8a30-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 670afda8-7f09-11ea-8a30-12813bfff9fa;
 Wed, 15 Apr 2020 11:08:15 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3CC19AC69;
 Wed, 15 Apr 2020 11:08:13 +0000 (UTC)
Subject: Re: [PATCH V8] x86/altp2m: Hypercall to set altp2m view visibility
To: Alexandru Isaila <aisaila@bitdefender.com>
References: <20200413065113.27744-1-aisaila@bitdefender.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <406e5d6e-5dd1-d15a-377b-71e3da83f90b@suse.com>
Date: Wed, 15 Apr 2020 13:08:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200413065113.27744-1-aisaila@bitdefender.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jun Nakajima <jun.nakajima@intel.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 13.04.2020 08:51, Alexandru Isaila wrote:
> @@ -4786,6 +4787,19 @@ static int do_altp2m_op(
>          break;
>      }
>  
> +    case HVMOP_altp2m_set_visibility:
> +    {
> +        unsigned int idx = a.u.set_visibility.altp2m_idx;
> +
> +        if ( a.u.set_visibility.pad )
> +            rc = -EINVAL;
> +        else if ( !altp2m_active(d) )
> +            rc = -EOPNOTSUPP;
> +        else
> +            rc = p2m_set_altp2m_view_visibility(d, idx,
> +                                                a.u.set_visibility.visible);
> +    }
> +
>      default:
>          ASSERT_UNREACHABLE();
>      }

Coverity points out that there's a break statement missing here.
Which makes me wonder how you would have successfully tested this
on a debug build. Please submit a fix (Coverity ID: 1461759).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:10:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:10:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOfvy-0007Bh-89; Wed, 15 Apr 2020 11:10:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOfvx-0007Bc-N1
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:10:21 +0000
X-Inumbo-ID: b1d31636-7f09-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b1d31636-7f09-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 11:10:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586949020;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=bVsRmRMDDBof1U/c70ZBUtPRTiWlxPgX4Wung/sAkwo=;
 b=VfI87gXGVGmJRUDBisGG/oDsUIWgO+dhy5eN3tTCZPttWpWB3w3ZbSoP
 HkIUFN5PP84k+Pg//zfxhQIqNN4OD0G+2rWqTLDoItOz/2Wy4vHaKp96x
 jQo5neFlMLjlr1oASdCggWoFcnCnrYpd3SJMQIOpwxDmbkiY/gtP/QM58 o=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: vQ1Zjyzalv6YIzO8e7qZHbLJW1pUFs3APvaY+9nCMhylLOvSkbnx4IEqIZ4FJaUm36k60mUQFN
 TB8ctmU4KxaXp97/gUnXmhUBLQEfysgFxs5XOyqKI+BRTPcJfs9yyklwxJUKr7L6Fz5SphpWH0
 RS4ZnRQD0MtJR2bVQQQb6nTZ58SqJ/6DUbl7n+s2x3O8GS51hS+5AMGGp/XDswxPpeF5NPRNZj
 7p8ljeQy1u8s21gMyrk+uPMvEV+EMu8ZLIJBeDpEQWrOfEwX2FwZn/nwdxwGefQjXuUnvJt3sN
 fQ4=
X-SBRS: 2.7
X-MesageID: 16379266
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="16379266"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/altp2m: add missing break
Date: Wed, 15 Apr 2020 13:09:39 +0200
Message-ID: <20200415110939.9481-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add a missing break in the HVMOP_altp2m_set_visibility case, or else
code flow will continue into the default case and trigger the assert.

Fixes: 3fd3e9303ec4b1 ('x86/altp2m: hypercall to set altp2m view visibility')
Coverity-ID: 1461759
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/hvm/hvm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6f6f3f73a8..45959d3412 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4798,6 +4798,7 @@ static int do_altp2m_op(
         else
             rc = p2m_set_altp2m_view_visibility(d, idx,
                                                 a.u.set_visibility.visible);
+        break;
     }
 
     default:
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:16:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:16:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOg1f-0007NC-1q; Wed, 15 Apr 2020 11:16:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=j72F=57=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jOg1e-0007N7-4U
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:16:14 +0000
X-Inumbo-ID: 8462efea-7f0a-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8462efea-7f0a-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 11:16:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=WQhU2eWWD1jnfPJ21bQCTdvQycHECudYtmpUalAkOAE=; b=GFmVHRlZEGKoSaFafF38HkbwkR
 XWYWswhbWC0CUHaXKfGIPJRYd3PtnsQYSXktNd0PzZs4BQoeC4Trhd45CZ0nUeBYaBT6fqMXAiyKh
 SHubphGzzOCTPautKDfD2BxikfYff5DHjVgWl93XlbiAYLSyr9aqz78O/LOaqU30Dsbs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg1c-0001L5-Qa; Wed, 15 Apr 2020 11:16:12 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg1c-0005bk-HN; Wed, 15 Apr 2020 11:16:12 +0000
Date: Wed, 15 Apr 2020 12:16:09 +0100
From: Wei Liu <wl@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 1/2] x86: drop unnecessary page table walking in compat
 r/o M2P handling
Message-ID: <20200415111609.6xmfmlc2ygwwon4n@debian>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
 <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
 <61746eff-0033-ccd7-6d77-3aabb8a426c8@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <61746eff-0033-ccd7-6d77-3aabb8a426c8@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Hongyan Xia <hx242@xen.org>, julien@xen.org, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 15, 2020 at 10:23:31AM +0200, Jan Beulich wrote:
> We have a global variable where the necessary L2 table is recorded; no
> need to inspect L4 and L3 tables (and this way a few less places will
> eventually need adjustment when we want to support 5-level page tables).
> Also avoid setting up the L3 entry, as the address range never gets used
> anyway (it'll be dropped altogether in a subsequent patch).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:16:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOg29-0007PO-Di; Wed, 15 Apr 2020 11:16:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=j72F=57=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jOg28-0007PG-5u
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:16:44 +0000
X-Inumbo-ID: 965ad9e2-7f0a-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 965ad9e2-7f0a-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 11:16:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
 MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=BgC3RHuuwyz8SKjiEeETpqmeE62rDCI7wOFjpCWjtDc=; b=2VH5qIq61mB6KEOWfrmc4qQ6la
 r5CC4xxULrTdM2unC4POPo13AVeSxJYXN3/9oSvWKKgX7hZg3ew/1Uvu3PM3zFArYsAg/vg1+ITWG
 4U8tIUzehCYbvsbAgJ6mH/F6FWSqTL5PmD57F9uCsymAFMl2GfEJyCMkODWwJUd5gj9I=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg27-0001Lf-AN; Wed, 15 Apr 2020 11:16:43 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg27-0005dD-1X; Wed, 15 Apr 2020 11:16:43 +0000
Date: Wed, 15 Apr 2020 12:16:40 +0100
From: Wei Liu <wl@xen.org>
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] x86/altp2m: add missing break
Message-ID: <20200415111640.lbtoajlrhxyoffsz@debian>
References: <20200415110939.9481-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200415110939.9481-1-roger.pau@citrix.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 15, 2020 at 01:09:39PM +0200, Roger Pau Monne wrote:
> Add a missing break in the HVMOP_altp2m_set_visibility case, or else
> code flow will continue into the default case and trigger the assert.
> 
> Fixes: 3fd3e9303ec4b1 ('x86/altp2m: hypercall to set altp2m view visibility')
> Coverity-ID: 1461759
> Signed-off-by: Roger Pau Monn� <roger.pau@citrix.com>

Reviewed-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:17:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOg2r-0007WQ-Q5; Wed, 15 Apr 2020 11:17:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=j72F=57=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jOg2p-0007W7-Rw
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:17:27 +0000
X-Inumbo-ID: b01fd6ca-7f0a-11ea-8a34-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b01fd6ca-7f0a-11ea-8a34-12813bfff9fa;
 Wed, 15 Apr 2020 11:17:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=m474G5Mn6D4sK9sE8FKVYx9qzWKpVJO9qsIct2x6CnU=; b=uCCLtwCS+Csb6p1qmYw+A0FV0J
 smYcI+nWYY5UP5p3TYsQ8jHsu8VlwHJCVOIYa4kv58sK41ve95MX+TcZTLeDw9vqy8L3CCsvLOVtg
 dtQ6k/Dw7EaY9+39XfoGC+2zDDJsvB9iNm5ifldzFrQCUiOgdZ01wu2eH5ADLjhqEp/Q=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg2n-0001N1-Rr; Wed, 15 Apr 2020 11:17:25 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg2n-0005em-I9; Wed, 15 Apr 2020 11:17:25 +0000
Date: Wed, 15 Apr 2020 12:17:22 +0100
From: Wei Liu <wl@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 2/3] xenoprof: drop unused struct xenoprof fields
Message-ID: <20200415111722.vzgr6kwzroeo5jk7@debian>
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
 <0c9daea8-6778-6bf9-2bd7-fe6425efb26e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0c9daea8-6778-6bf9-2bd7-fe6425efb26e@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 15, 2020 at 10:53:20AM +0200, Jan Beulich wrote:
> Both is_primary and domain_ready are only ever written to. Drop both
> fields and restrict structure visibility to just the one involved CU.
> While doing so (and just for starters) make "is_compat" properly bool.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:19:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOg4x-0007hH-Am; Wed, 15 Apr 2020 11:19:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=j72F=57=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jOg4w-0007hB-Ne
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:19:38 +0000
X-Inumbo-ID: fdc1efbd-7f0a-11ea-8a34-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fdc1efbd-7f0a-11ea-8a34-12813bfff9fa;
 Wed, 15 Apr 2020 11:19:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=MngbRs4JfVL1lmnxMwnUIbMEJADMva5ac8XX6McnDJA=; b=f+MTcRUwopJ2kRzA8udo4aiD0L
 rk/DJxcE50N96SWx62FQ0eWrbjiNcacKeBA+q43FPwzJigQK1uV/9kZ5poSvcTPpVF5vfaSgVKjQv
 8uo3daSNsRqO0bLEUgERdzuGzpPTsduwklucZVYEpbUV0Y5dBHTaejc5WRkxAaa98c/U=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg4u-0001Px-MU; Wed, 15 Apr 2020 11:19:36 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg4u-0005kA-Dm; Wed, 15 Apr 2020 11:19:36 +0000
Date: Wed, 15 Apr 2020 12:19:33 +0100
From: Wei Liu <wl@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 3/3] xenoprof: limit scope of types and #define-s
Message-ID: <20200415111933.jcnz63e6yafopd2s@debian>
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
 <61ac5f46-fd43-e173-202e-9de46755d604@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <61ac5f46-fd43-e173-202e-9de46755d604@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 15, 2020 at 10:53:38AM +0200, Jan Beulich wrote:
> Quite a few of the items are used by xenoprof.c only, so move them there
> to limit their visibility as well as the amount of re-building needed in
> case of changes. Also drop the inclusion of the public header there.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I haven't read this patch carefully, but what it does is a good thing in
general and I trust our build test can catch any fallout from this sort
of change, so:

Acked-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:22:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:22:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOg7P-0008VI-SC; Wed, 15 Apr 2020 11:22:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=j72F=57=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jOg7O-0008Ul-AD
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:22:10 +0000
X-Inumbo-ID: 58b6af34-7f0b-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 58b6af34-7f0b-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 11:22:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=ge8/awGPFcL356SsWTT1df7dwyO0aIf9/UbP1gM8ze4=; b=CDh4SfHv85tjWe8KOuMcAsenPt
 VAmOMyRDuyn0rAKP4/agpEMnrGeEYOWCpWBtsh1wnJv/H2rwN6AyHpeZPthhCcdxLBRpF3IXcM501
 VTttX50z5rrJwOwRRDx+9RCxnnv+oV5LxpddTpRKBlW3UpkiKz8qaCM8gZl3f6E9p66g=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg7M-0001Tq-PP; Wed, 15 Apr 2020 11:22:08 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOg7M-00062d-G2; Wed, 15 Apr 2020 11:22:08 +0000
Date: Wed, 15 Apr 2020 12:22:05 +0100
From: Wei Liu <wl@xen.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH 04/12] xen: split alloc_heap_pages in two halves for
 reusability
Message-ID: <20200415112205.zan6w7ycgztni7aj@debian>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-4-sstabellini@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200415010255.10081-4-sstabellini@kernel.org>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, jbeulich@suse.com,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 14, 2020 at 06:02:47PM -0700, Stefano Stabellini wrote:
> This patch splits the implementation of alloc_heap_pages into two halves
> so that the second half can be reused by the next patch.

It would be good if you can put a summary on what each half does here so
that we can check you intent against the implementation.

Wei.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:28:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOgD3-0000FA-Km; Wed, 15 Apr 2020 11:28:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=c95o=57=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOgD1-0000F5-HY
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:27:59 +0000
X-Inumbo-ID: 28515b40-7f0c-11ea-9e09-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 28515b40-7f0c-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 11:27:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586950079;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=CIUTEn/Yeb9Hvgke6D2MSVCzCSUf9bwdmiJQpMGumlc=;
 b=FzlAYBz2X/f6gpHbgvgaTBwBoZBQBbEwDOPGe/C91Jt9ncaZKT0YLfiV
 5u11zE6WHpYy0mW52LfQcDrGLSX3mVFRZsynn3GwouasNDGJ/JLeEBvXv
 +hL26gxNqEhFnWOyj6paF834LUlPDm4NHHpRajWcs/hC5zK1vKglZtGH1 A=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 0SI/xKFLtmGLJ7Li0CWH4uAESkufqJmMq31Bf5mbRhrgDHyhJqbccm+GqU6Wf4t08T/7uYcca1
 nXhU7DSDb1507I03ZxWgNoRRmuoh/aapJDcyAld0fbTJ68xpnCwbxXdklj0+eaznViozbFDDRP
 t5lQaswwVGnFCfx6YirPb4wQ6xLr7kv++KqCGqTLWLN4gTisK3se8qwOtCTmZYKlJnNakelUrE
 vX4VMIL9kWLBKBdDNgqzJl1fQluw3quZE1y8VIULbDnjHTvsiQaJjOuMwITDSi6WHFV5nqzIz5
 2tM=
X-SBRS: 2.7
X-MesageID: 15720227
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="15720227"
Subject: Re: [PATCH 02/12] xen/arm: introduce arch_xen_dom_flags and direct_map
To: Jan Beulich <jbeulich@suse.com>, Stefano Stabellini
 <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-2-sstabellini@kernel.org>
 <4130f640-a664-a9e7-fcd7-85bbd58287e4@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <2c6c6600-bf58-9833-deac-111a59c16239@citrix.com>
Date: Wed, 15 Apr 2020 12:27:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <4130f640-a664-a9e7-fcd7-85bbd58287e4@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>,
 George Dunlap <George.Dunlap@eu.citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15/04/2020 11:27, Jan Beulich wrote:
> On 15.04.2020 03:02, Stefano Stabellini wrote:
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -682,6 +682,7 @@ int arch_domain_create(struct domain *d,
>>          return 0;
>>  
>>      ASSERT(config != NULL);
>> +    d->arch.direct_map = flags != NULL ? flags->arch.is_direct_map : false;
> Shouldn't "true" here imply ->disable_migrate also getting
> set to true? Or is this already the case anyway for domains
> created right at boot?

Please don't introduce any more uses for disable_migrate.  It is
fundamentally broken and won't survive to 4.14 (assuming that the 30 odd
patches of prereq fixes on xen-devel start unblocking themselves in time)

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:36:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOgKk-00018X-Ok; Wed, 15 Apr 2020 11:35:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=3n5d=57=kernel.org=sashal@srs-us1.protection.inumbo.net>)
 id 1jOgKj-00018S-Su
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:35:57 +0000
X-Inumbo-ID: 45dc65c8-7f0d-11ea-83d8-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 45dc65c8-7f0d-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 11:35:57 +0000 (UTC)
Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net
 [73.47.72.35])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 3F92920737;
 Wed, 15 Apr 2020 11:35:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586950556;
 bh=Le5r4ZEgqHViB7UDMuTUHMRwchWcpxKe6N8tGPIdKdI=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=twUXnbkxpBhf/riUONtD4bwFwRT9Vt3foYA9D0BJamIKVv6ey8auSuK0AYChUJvM+
 3fNJl0rSEnAG1ZyxE1MZAlyEMSfcEvP+WOFeHWcBCDCaTYGrqJFWdfw/Y+QsheIgF/
 InGmOQuvgz+YeRoaWaFil7ect+j/y62Ys5ZDQyK8=
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH AUTOSEL 5.6 062/129] x86/xen: Make the boot CPU idle task
 reliable
Date: Wed, 15 Apr 2020 07:33:37 -0400
Message-Id: <20200415113445.11881-62-sashal@kernel.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200415113445.11881-1-sashal@kernel.org>
References: <20200415113445.11881-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sasha Levin <sashal@kernel.org>,
 Miroslav Benes <mbenes@suse.cz>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Miroslav Benes <mbenes@suse.cz>

[ Upstream commit 2f62f36e62daec43aa7b9633ef7f18e042a80bed ]

The unwinder reports the boot CPU idle task's stack on XEN PV as
unreliable, which affects at least live patching. There are two reasons
for this. First, the task does not follow the x86 convention that its
stack starts at the offset right below saved pt_regs. It allows the
unwinder to easily detect the end of the stack and verify it. Second,
startup_xen() function does not store the return address before jumping
to xen_start_kernel() which confuses the unwinder.

Amend both issues by moving the starting point of initial stack in
startup_xen() and storing the return address before the jump, which is
exactly what call instruction does.

Signed-off-by: Miroslav Benes <mbenes@suse.cz>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/xen/xen-head.S | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 1d0cee3163e41..d63806e1ff7ae 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -35,7 +35,11 @@ SYM_CODE_START(startup_xen)
 	rep __ASM_SIZE(stos)
 
 	mov %_ASM_SI, xen_start_info
-	mov $init_thread_union+THREAD_SIZE, %_ASM_SP
+#ifdef CONFIG_X86_64
+	mov initial_stack(%rip), %rsp
+#else
+	mov pa(initial_stack), %esp
+#endif
 
 #ifdef CONFIG_X86_64
 	/* Set up %gs.
@@ -51,7 +55,7 @@ SYM_CODE_START(startup_xen)
 	wrmsr
 #endif
 
-	jmp xen_start_kernel
+	call xen_start_kernel
 SYM_CODE_END(startup_xen)
 	__FINIT
 #endif
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:43:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOgS3-00021X-Kt; Wed, 15 Apr 2020 11:43:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=3n5d=57=kernel.org=sashal@srs-us1.protection.inumbo.net>)
 id 1jOgS1-00021S-Vb
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:43:29 +0000
X-Inumbo-ID: 5354c2e4-7f0e-11ea-b58d-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5354c2e4-7f0e-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 11:43:29 +0000 (UTC)
Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net
 [73.47.72.35])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 418DF2078A;
 Wed, 15 Apr 2020 11:43:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1586951008;
 bh=Le5r4ZEgqHViB7UDMuTUHMRwchWcpxKe6N8tGPIdKdI=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=eWWAghB+N20XKezbzLQ1pEo5G4+q4R+DyHD9Ldl1O1k7/RK6NDCACdfT4Vfp5G/nT
 Tm4LBWgecFf8RxkAiie1J8eDYkiohFAdYgnW3RdmrU2Tyhu4ZP241A/O1JBUo8xoyW
 xh5O9W1n1rG34DZMhNn21xFVkiHWWUwfLO7yY7TE=
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH AUTOSEL 5.5 053/106] x86/xen: Make the boot CPU idle task
 reliable
Date: Wed, 15 Apr 2020 07:41:33 -0400
Message-Id: <20200415114226.13103-53-sashal@kernel.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200415114226.13103-1-sashal@kernel.org>
References: <20200415114226.13103-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sasha Levin <sashal@kernel.org>,
 Miroslav Benes <mbenes@suse.cz>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Miroslav Benes <mbenes@suse.cz>

[ Upstream commit 2f62f36e62daec43aa7b9633ef7f18e042a80bed ]

The unwinder reports the boot CPU idle task's stack on XEN PV as
unreliable, which affects at least live patching. There are two reasons
for this. First, the task does not follow the x86 convention that its
stack starts at the offset right below saved pt_regs. It allows the
unwinder to easily detect the end of the stack and verify it. Second,
startup_xen() function does not store the return address before jumping
to xen_start_kernel() which confuses the unwinder.

Amend both issues by moving the starting point of initial stack in
startup_xen() and storing the return address before the jump, which is
exactly what call instruction does.

Signed-off-by: Miroslav Benes <mbenes@suse.cz>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/xen/xen-head.S | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 1d0cee3163e41..d63806e1ff7ae 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -35,7 +35,11 @@ SYM_CODE_START(startup_xen)
 	rep __ASM_SIZE(stos)
 
 	mov %_ASM_SI, xen_start_info
-	mov $init_thread_union+THREAD_SIZE, %_ASM_SP
+#ifdef CONFIG_X86_64
+	mov initial_stack(%rip), %rsp
+#else
+	mov pa(initial_stack), %esp
+#endif
 
 #ifdef CONFIG_X86_64
 	/* Set up %gs.
@@ -51,7 +55,7 @@ SYM_CODE_START(startup_xen)
 	wrmsr
 #endif
 
-	jmp xen_start_kernel
+	call xen_start_kernel
 SYM_CODE_END(startup_xen)
 	__FINIT
 #endif
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:49:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOgXq-0002Aq-D6; Wed, 15 Apr 2020 11:49:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOgXp-0002Al-N0
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:49:29 +0000
X-Inumbo-ID: 2934846c-7f0f-11ea-83d8-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2934846c-7f0f-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 11:49:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586951369;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=bnnGwWvmiSqRtzZpSXaQ1DkHlTJdVm2N1krGMVkIJY8=;
 b=QiLsLT8A++INlZplXLeJaJF/YJ8qANUuASdihSD1yKkJ9WTsTvkMqbA5
 Awu9FaVA9s2Kap1vVU7hSizq/UYWF3nToUh5ubWoWZF7PMDxlcIOVRWwp
 /d8dPaU1c9VWWmA1prR0+g3Q5IFzb58+My/PtljZr40fmkQQ3wvc0gk98 o=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: /1ceEh5bI3PXMVqF4djXaKN23q1nefiRPYRZ+BM5X1tRH+XvBUXF3Rgb2kHg+JSlvQ5NtUxikP
 97cswQXeSh5klDTWzm7rKAD6lHtLSuI91DSMvE6DMMiDAxnG+BbsatCS8ccGlxcflY6S0su6U7
 Xsi9vXcUb+pwk6YhX9RhEhePsoc30CkI7oPwZMVcYAH1pfy1hVgwruDw0jPMrb2+YdQJIJsY6t
 qy2Qi6kipnuuY0RN1GLbEVHw/c5YElC/oUpVZIXBiIQRWpIgEC4k6jn3SRnhL1vMaIzZdj7kaU
 ApU=
X-SBRS: 2.7
X-MesageID: 15946342
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="15946342"
Date: Wed, 15 Apr 2020 13:49:18 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200415114918.GK28601@Air-de-Roger>
References: <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
 <20200414111911.GI28601@Air-de-Roger>
 <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
 <20200414145337.GJ28601@Air-de-Roger>
 <fbc0dd00-6973-4003-ad34-591561b695c9@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <fbc0dd00-6973-4003-ad34-591561b695c9@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 14, 2020 at 05:06:23PM +0200, Jan Beulich wrote:
> On 14.04.2020 16:53, Roger Pau Monné wrote:
> > On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
> >> On 14.04.2020 13:19, Roger Pau Monné wrote:
> >>>>> I think this should work, but I would rather do it in a separate
> >>>>> patch.
> >>>>
> >>>> Yes, just like the originally (wrongly, as you validly say) suggested
> >>>> full removal of them, putting this in a separate patch would indeed
> >>>> seem better.
> >>>
> >>> Would you like me to resend with the requested fix to
> >>> paging_log_dirty_range (ie: drop the FLUSH_TLB and only call
> >>> flush_mask for HAP guests running on AMD) then?
> >>
> >> Well, ideally I'd see that function also make use of the intended
> >> new helper function, if at all possible (and suitable).
> > 
> > Oh, OK. Just to make sure I understand what you are asking for, you
> > would like me to resend introducing the new guest_flush_tlb_mask
> > helper and use it in the flush_tlb_mask callers modified by this
> > patch?
> 
> Yes (and I now realize it may not make sense to split it off into a
> separate change).

I could do a pre-patch that introduces guest_flush_tlb_mask as a
simple wrapper around flush_tlb_mask and replace the callers that I
modify in this patch. Then this patch would only introduce
FLUSH_HVM_ASID_CORE and modify guest_flush_tlb_mask to use it when
required.

It might make it more complicated to see which callers require the
ASID flush, but if you think it's better I can arrange the patches in
that way.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:51:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOgaA-0002xP-UN; Wed, 15 Apr 2020 11:51:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOga9-0002xK-Ru
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:51:53 +0000
X-Inumbo-ID: 7f33591a-7f0f-11ea-8a3a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7f33591a-7f0f-11ea-8a3a-12813bfff9fa;
 Wed, 15 Apr 2020 11:51:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 07FB5AF01;
 Wed, 15 Apr 2020 11:51:50 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
 <20200414111911.GI28601@Air-de-Roger>
 <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
 <20200414145337.GJ28601@Air-de-Roger>
 <fbc0dd00-6973-4003-ad34-591561b695c9@suse.com>
 <20200415114918.GK28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <9af8eac3-4c0c-9440-6fe7-129bec3da774@suse.com>
Date: Wed, 15 Apr 2020 13:51:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415114918.GK28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 13:49, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 05:06:23PM +0200, Jan Beulich wrote:
>> On 14.04.2020 16:53, Roger Pau Monné wrote:
>>> On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
>>>> On 14.04.2020 13:19, Roger Pau Monné wrote:
>>>>>>> I think this should work, but I would rather do it in a separate
>>>>>>> patch.
>>>>>>
>>>>>> Yes, just like the originally (wrongly, as you validly say) suggested
>>>>>> full removal of them, putting this in a separate patch would indeed
>>>>>> seem better.
>>>>>
>>>>> Would you like me to resend with the requested fix to
>>>>> paging_log_dirty_range (ie: drop the FLUSH_TLB and only call
>>>>> flush_mask for HAP guests running on AMD) then?
>>>>
>>>> Well, ideally I'd see that function also make use of the intended
>>>> new helper function, if at all possible (and suitable).
>>>
>>> Oh, OK. Just to make sure I understand what you are asking for, you
>>> would like me to resend introducing the new guest_flush_tlb_mask
>>> helper and use it in the flush_tlb_mask callers modified by this
>>> patch?
>>
>> Yes (and I now realize it may not make sense to split it off into a
>> separate change).
> 
> I could do a pre-patch that introduces guest_flush_tlb_mask as a
> simple wrapper around flush_tlb_mask and replace the callers that I
> modify in this patch. Then this patch would only introduce
> FLUSH_HVM_ASID_CORE and modify guest_flush_tlb_mask to use it when
> required.
> 
> It might make it more complicated to see which callers require the
> ASID flush, but if you think it's better I can arrange the patches in
> that way.

No, I think it's beteer to leave as a single patch. The idea with
splitting was that you'd (fully) take care of some of the sites
needing modification ahead of what is now patch 1. I.e. this would
have been a suitable approach only if some use sites could really
have the call dropped altogether.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:55:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:55:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOgdd-00035w-Ga; Wed, 15 Apr 2020 11:55:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOgdb-00035n-U3
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:55:27 +0000
X-Inumbo-ID: fea8bc6c-7f0f-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fea8bc6c-7f0f-11ea-b4f4-bc764e2007e4;
 Wed, 15 Apr 2020 11:55:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0A8D6AF10;
 Wed, 15 Apr 2020 11:55:24 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86: retrieve and log CPU frequency information
Message-ID: <1fd091d2-30e2-0691-0485-3f5142bd457f@suse.com>
Date: Wed, 15 Apr 2020 13:55:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While from just a single Skylake system it is already clear that we
can't base any of our logic on CPUID leaf 15 [1] (leaf 16 is
documented to be used for display purposes only anyway), logging this
information may still give us some reference in case of problems as well
as for future work. Additionally on the AMD side it is unclear whether
the deviation between reported and measured frequencies is because of us
not doing well, or because of nominal and actual frequencies being quite
far apart.

The chosen variable naming in amd_log_freq() has pointed out a naming
problem in rdmsr_safe(), which is being taken care of at the same time.
Symmetrically wrmsr_safe(), being an inline function, also gets an
unnecessary underscore dropped from one of its local variables.

[1] With a core crystal clock of 24MHz and a ratio of 216/2, the
    reported frequency nevertheless is 2600MHz, rather than the to be
    expected (and calibrated by both us and Linux) 2592MHz.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
TBD: The node ID retrieval using extended leaf 1E implies it won't work
     on older hardware (pre-Fam15 I think). Besides the Node ID MSR,
     which doesn't get advertised on my Fam10 box (and it's zero on all
     processors despite there being two nodes as per the PCI device
     map), and which isn't even documented for Fam11, Fam12, and Fam14,
     I didn't find any other means to retrieve the node ID a CPU is
     associated with - the NodeId register in PCI config space depends
     on one already knowing the node ID for doing the access, as the
     device to be used is a function of the node ID.

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -532,6 +532,102 @@ static void amd_get_topology(struct cpui
                                                           : c->cpu_core_id);
 }
 
+void amd_log_freq(const struct cpuinfo_x86 *c)
+{
+	unsigned int idx = 0, h;
+	uint64_t hi, lo, val;
+
+	if (c->x86 < 0x10 || c->x86 > 0x19 ||
+	    (c != &boot_cpu_data &&
+	     (!opt_cpu_info || (c->apicid & (c->x86_num_siblings - 1)))))
+		return;
+
+	if (c->x86 < 0x17) {
+		unsigned int node = 0;
+		uint64_t nbcfg;
+
+		/*
+		 * Make an attempt at determining the node ID, but assume
+		 * symmetric setup (using node 0) if this fails.
+		 */
+		if (c->extended_cpuid_level >= 0x8000001e &&
+		    cpu_has(c, X86_FEATURE_TOPOEXT)) {
+			node = cpuid_ecx(0x8000001e) & 0xff;
+			if (node > 7)
+				node = 0;
+		} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
+			rdmsrl(0xC001100C, val);
+			node = val & 7;
+		}
+
+		/*
+		 * Enable (and use) Extended Config Space accesses, as we
+		 * can't be certain that MCFG is available here during boot.
+		 */
+		rdmsrl(MSR_AMD64_NB_CFG, nbcfg);
+		wrmsrl(MSR_AMD64_NB_CFG,
+		       nbcfg | (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT));
+#define PCI_ECS_ADDRESS(sbdf, reg) \
+    (0x80000000 | ((sbdf).bdf << 8) | ((reg) & 0xfc) | (((reg) & 0xf00) << 16))
+
+		for ( ; ; ) {
+			pci_sbdf_t sbdf = PCI_SBDF(0, 0, 0x18 | node, 4);
+
+			switch (pci_conf_read32(sbdf, PCI_VENDOR_ID)) {
+			case 0x00000000:
+			case 0xffffffff:
+				/* No device at this SBDF. */
+				if (!node)
+					break;
+				node = 0;
+				continue;
+
+			default:
+				/*
+				 * Core Performance Boost Control, family
+				 * dependent up to 3 bits starting at bit 2.
+				 */
+				switch (c->x86) {
+				case 0x10: idx = 1; break;
+				case 0x12: idx = 7; break;
+				case 0x14: idx = 7; break;
+				case 0x15: idx = 7; break;
+				case 0x16: idx = 7; break;
+				}
+				idx &= pci_conf_read(PCI_ECS_ADDRESS(sbdf,
+				                                     0x15c),
+				                     0, 4) >> 2;
+				break;
+			}
+			break;
+		}
+
+#undef PCI_ECS_ADDRESS
+		wrmsrl(MSR_AMD64_NB_CFG, nbcfg);
+	}
+
+	lo = 0; /* gcc may not recognize the loop having at least 5 iterations */
+	for (h = c->x86 == 0x10 ? 5 : 8; h--; )
+		if (!rdmsr_safe(0xC0010064 + h, lo) && (lo >> 63))
+			break;
+	if (!(lo >> 63))
+		return;
+
+#define FREQ(v) (c->x86 < 0x17 ? ((((v) & 0x3f) + 0x10) * 100) >> (((v) >> 6) & 7) \
+		                     : (((v) & 0xff) * 25 * 8) / (((v) >> 8) & 0x3f))
+	if (idx && idx < h &&
+	    !rdmsr_safe(0xC0010064 + idx, val) && (val >> 63) &&
+	    !rdmsr_safe(0xC0010064, hi) && (hi >> 63))
+		printk("CPU%u: %lu (%lu..%lu) MHz\n",
+		       smp_processor_id(), FREQ(val), FREQ(lo), FREQ(hi));
+	else if (h && !rdmsr_safe(0xC0010064, hi) && (hi >> 63))
+		printk("CPU%u: %lu..%lu MHz\n",
+		       smp_processor_id(), FREQ(lo), FREQ(hi));
+	else
+		printk("CPU%u: %lu MHz\n", smp_processor_id(), FREQ(lo));
+#undef FREQ
+}
+
 void early_init_amd(struct cpuinfo_x86 *c)
 {
 	if (c == &boot_cpu_data)
@@ -803,6 +899,8 @@ static void init_amd(struct cpuinfo_x86
 		disable_c1_ramping();
 
 	check_syscfg_dram_mod_en();
+
+	amd_log_freq(c);
 }
 
 const struct cpu_dev amd_cpu_dev = {
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -19,3 +19,4 @@ extern void detect_ht(struct cpuinfo_x86
 extern bool detect_extended_topology(struct cpuinfo_x86 *c);
 
 void early_init_amd(struct cpuinfo_x86 *c);
+void amd_log_freq(const struct cpuinfo_x86 *c);
--- a/xen/arch/x86/cpu/hygon.c
+++ b/xen/arch/x86/cpu/hygon.c
@@ -99,6 +99,8 @@ static void init_hygon(struct cpuinfo_x8
 		value |= (1 << 27); /* Enable read-only APERF/MPERF bit */
 		wrmsrl(MSR_K7_HWCR, value);
 	}
+
+	amd_log_freq(c);
 }
 
 const struct cpu_dev hygon_cpu_dev = {
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -378,6 +378,72 @@ static void init_intel(struct cpuinfo_x8
 	     ( c->cpuid_level >= 0x00000006 ) &&
 	     ( cpuid_eax(0x00000006) & (1u<<2) ) )
 		__set_bit(X86_FEATURE_ARAT, c->x86_capability);
+
+    if ( (opt_cpu_info && !(c->apicid & (c->x86_num_siblings - 1))) ||
+         c == &boot_cpu_data )
+    {
+        unsigned int eax, ebx, ecx, edx;
+        uint64_t msrval;
+
+        if ( c->cpuid_level >= 0x15 )
+        {
+            cpuid(0x15, &eax, &ebx, &ecx, &edx);
+            if ( ecx && ebx && eax )
+            {
+                unsigned long long val = ecx;
+
+                val *= ebx;
+                do_div(val, eax);
+                printk("CPU%u: TSC: %uMHz * %u / %u = %LuMHz\n",
+                       smp_processor_id(), ecx, ebx, eax, val);
+            }
+            else if ( ecx | eax | ebx )
+            {
+                printk("CPU%u: TSC:", smp_processor_id());
+                if ( ecx )
+                    printk(" core: %uMHz", ecx);
+                if ( ebx && eax )
+                    printk(" ratio: %u / %u", ebx, eax);
+                printk("\n");
+            }
+        }
+
+        if ( c->cpuid_level >= 0x16 )
+        {
+            cpuid(0x16, &eax, &ebx, &ecx, &edx);
+            if ( ecx | eax | ebx )
+            {
+                printk("CPU%u:", smp_processor_id());
+                if ( ecx )
+                    printk(" bus: %uMHz", ecx);
+                if ( eax )
+                    printk(" base: %uMHz", eax);
+                if ( ebx )
+                    printk(" max: %uMHz", ebx);
+                printk("\n");
+            }
+        }
+
+        if ( !rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msrval) &&
+             (uint8_t)(msrval >> 8) )
+        {
+            unsigned int factor = 10000;
+
+            if ( c->x86 == 6 )
+                switch ( c->x86_model )
+                {
+                case 0x1a: case 0x1e: case 0x1f: case 0x2e: /* Nehalem */
+                case 0x25: case 0x2c: case 0x2f: /* Westmere */
+                    factor = 13333;
+                    break;
+                }
+
+            printk("CPU%u: ", smp_processor_id());
+            if ( (uint8_t)(msrval >> 40) )
+                printk("%u..", (factor * (uint8_t)(msrval >> 40) + 50) / 100);
+            printk("%u MHz\n", (factor * (uint8_t)(msrval >> 8) + 50) / 100);
+        }
+    }
 }
 
 const struct cpu_dev intel_cpu_dev = {
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -40,8 +40,8 @@ static inline void wrmsrl(unsigned int m
 
 /* rdmsr with exception handling */
 #define rdmsr_safe(msr,val) ({\
-    int _rc; \
-    uint32_t lo, hi; \
+    int rc_; \
+    uint32_t lo_, hi_; \
     __asm__ __volatile__( \
         "1: rdmsr\n2:\n" \
         ".section .fixup,\"ax\"\n" \
@@ -49,15 +49,15 @@ static inline void wrmsrl(unsigned int m
         "   movl %5,%2\n; jmp 2b\n" \
         ".previous\n" \
         _ASM_EXTABLE(1b, 3b) \
-        : "=a" (lo), "=d" (hi), "=&r" (_rc) \
+        : "=a" (lo_), "=d" (hi_), "=&r" (rc_) \
         : "c" (msr), "2" (0), "i" (-EFAULT)); \
-    val = lo | ((uint64_t)hi << 32); \
-    _rc; })
+    val = lo_ | ((uint64_t)hi_ << 32); \
+    rc_; })
 
 /* wrmsr with exception handling */
 static inline int wrmsr_safe(unsigned int msr, uint64_t val)
 {
-    int _rc;
+    int rc;
     uint32_t lo, hi;
     lo = (uint32_t)val;
     hi = (uint32_t)(val >> 32);
@@ -68,9 +68,9 @@ static inline int wrmsr_safe(unsigned in
         "3: movl %5,%0\n; jmp 2b\n"
         ".previous\n"
         _ASM_EXTABLE(1b, 3b)
-        : "=&r" (_rc)
+        : "=&r" (rc)
         : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
-    return _rc;
+    return rc;
 }
 
 static inline uint64_t msr_fold(const struct cpu_user_regs *regs)


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:59:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:59:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOghi-0003EP-5Z; Wed, 15 Apr 2020 11:59:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOghg-0003EF-9m
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:59:40 +0000
X-Inumbo-ID: 956dbced-7f10-11ea-8a3a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 956dbced-7f10-11ea-8a3a-12813bfff9fa;
 Wed, 15 Apr 2020 11:59:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=jo5OaALwnkvy+PpWmv8rXB6iCH0AvFuIMsvxPmBS4Kw=; b=c5tL6n9AfBCqNjXzozd4oexmXQ
 6cKP+qsdFe/zBGeXtDkhhHEYq6nNZGgPYUbp5hzhtcM0uypTOmio56kpbWNFX+MNAKoc1PgOFFJkG
 Vy+ZLeziixHgU7cyof/DbRuRVR6FXG9TefNKRnD4Z9XpiU8OMTn+aI7PqVxzfBTVYNjA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghe-00027M-Ql; Wed, 15 Apr 2020 11:59:38 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghe-0008L0-G8; Wed, 15 Apr 2020 11:59:38 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v3 0/4] use new API for Xen page tables
Date: Wed, 15 Apr 2020 12:59:23 +0100
Message-Id: <cover.1586951696.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

This small series is basically just rewriting functions using the new
API to map and unmap PTEs. Each patch is independent.

Apart from mapping and unmapping page tables, no other functional change
intended.

---
Changed in v3:
- address all comments in v2.
- drop patch 4, since other clean-ups will make it unnecessary.

Changed in v2:
- I kept UNMAP_DOMAIN_PAGE() for now in v2, but I if people say
  in some cases it is an overkill and unmap_domain_page() should be
  used, I am okay with that and can make the change.
- code cleanup and style fixes.
- unmap as early as possible.


Wei Liu (4):
  x86/shim: map and unmap page tables in replace_va_mapping
  x86_64/mm: map and unmap page tables in m2p_mapped
  x86_64/mm: map and unmap page tables in share_hotadd_m2p_table
  x86_64/mm: map and unmap page tables in destroy_m2p_mapping

 xen/arch/x86/pv/shim.c     |  9 ++++----
 xen/arch/x86/x86_64/mm.c   | 44 +++++++++++++++++++++-----------------
 xen/include/asm-x86/page.h | 19 ++++++++++++++++
 3 files changed, 48 insertions(+), 24 deletions(-)

-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:59:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:59:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOghi-0003Ef-Lx; Wed, 15 Apr 2020 11:59:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOghh-0003EK-5Z
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:59:41 +0000
X-Inumbo-ID: 96400832-7f10-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 96400832-7f10-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 11:59:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=9mcwfS2UNApo7+gpEmAq4QsskjJ6UAD8MG/Ev2F27Uc=; b=RV3IORgR7mWX/59sDGHfPn9mNz
 p0JKr88IhtNwd8y4fBK2mP2U45nI4djiIpC63+Rv4jz4VtzY4uP/6GkpPj4MnMDLZyxRUjxDaxLya
 autw7/H49qggpvOok3nkV0gUVTFOsgn2no1BIuKc9mzV8s8ZhhRhJ1UquB7PbXF4c7KY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghg-00027R-9f; Wed, 15 Apr 2020 11:59:40 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghf-0008L0-Vd; Wed, 15 Apr 2020 11:59:40 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v3 1/4] x86/shim: map and unmap page tables in
 replace_va_mapping
Date: Wed, 15 Apr 2020 12:59:24 +0100
Message-Id: <37ad7487bc6e6f76e2082c0b42b4cf819007f513.1586951696.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586951696.git.hongyxia@amazon.com>
References: <cover.1586951696.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586951696.git.hongyxia@amazon.com>
References: <cover.1586951696.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Also, introduce lYe_from_lXe() macros which do not rely on the direct
map when walking page tables. Unfortunately, they cannot be inline
functions due to the header dependency on domain_page.h, so keep them as
macros just like map_lYt_from_lXe().

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed in v3:
- use unmap_domain_page() instead of the macro in several places.
- also introduce l1e_from_l2e().
- add _ prefix in macros to avoid aliasing.

Changed in v2:
- instead of map, map, map, read/write, unmap, unmap, unmap, do map,
  read PTE, unmap for each level instead.
- use lYe_from_lXe() macros and lift them from a later patch to this
  patch.
- const qualify pointers in new macros.
---
 xen/arch/x86/pv/shim.c     |  9 +++++----
 xen/include/asm-x86/page.h | 19 +++++++++++++++++++
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index ed2ece8a8a..31264582cc 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -168,16 +168,17 @@ const struct platform_bad_page *__init pv_shim_reserved_pages(unsigned int *size
 static void __init replace_va_mapping(struct domain *d, l4_pgentry_t *l4start,
                                       unsigned long va, mfn_t mfn)
 {
-    l4_pgentry_t *pl4e = l4start + l4_table_offset(va);
-    l3_pgentry_t *pl3e = l4e_to_l3e(*pl4e) + l3_table_offset(va);
-    l2_pgentry_t *pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(va);
-    l1_pgentry_t *pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(va);
+    l4_pgentry_t l4e = l4start[l4_table_offset(va)];
+    l3_pgentry_t l3e = l3e_from_l4e(l4e, l3_table_offset(va));
+    l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(va));
+    l1_pgentry_t *pl1e = map_l1t_from_l2e(l2e) + l1_table_offset(va);
     struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e));
 
     put_page_and_type(page);
 
     *pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT
                                                       : COMPAT_L1_PROT));
+    unmap_domain_page(pl1e);
 }
 
 static void evtchn_reserve(struct domain *d, unsigned int port)
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index eb73a0fc23..d50989a357 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -197,6 +197,25 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, unsigned int flags)
 #define map_l2t_from_l3e(x)        (l2_pgentry_t *)map_domain_page(l3e_get_mfn(x))
 #define map_l3t_from_l4e(x)        (l3_pgentry_t *)map_domain_page(l4e_get_mfn(x))
 
+/* Unlike lYe_to_lXe(), lXe_from_lYe() do not rely on the direct map. */
+#define l1e_from_l2e(_l2e, _offset) ({                      \
+        const l1_pgentry_t *_l1t = map_l1t_from_l2e(_l2e);  \
+        l1_pgentry_t _l1e = _l1t[_offset];                  \
+        unmap_domain_page(_l1t);                            \
+        _l1e; })
+
+#define l2e_from_l3e(_l3e, _offset) ({                      \
+        const l2_pgentry_t *_l2t = map_l2t_from_l3e(_l3e);  \
+        l2_pgentry_t _l2e = _l2t[_offset];                  \
+        unmap_domain_page(_l2t);                            \
+        _l2e; })
+
+#define l3e_from_l4e(_l4e, _offset) ({                      \
+        const l3_pgentry_t *_l3t = map_l3t_from_l4e(_l4e);  \
+        l3_pgentry_t _l3e = _l3t[_offset];                  \
+        unmap_domain_page(_l3t);                            \
+        _l3e; })
+
 /* Given a virtual address, get an entry offset into a page table. */
 #define l1_table_offset(a)         \
     (((a) >> L1_PAGETABLE_SHIFT) & (L1_PAGETABLE_ENTRIES - 1))
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:59:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOghn-0003Fc-0i; Wed, 15 Apr 2020 11:59:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOghl-0003FN-7L
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:59:45 +0000
X-Inumbo-ID: 983fd5e0-7f10-11ea-8a3a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 983fd5e0-7f10-11ea-8a3a-12813bfff9fa;
 Wed, 15 Apr 2020 11:59:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=NjsU0mvN8f3Kkt58hhovqMgTFjoAL4EcJkT/EkRsASw=; b=YRocKqYUdMym1/68P8V3o6gmma
 mAV7pQqwqJ9R1TFAkiQ6tJ6gWhh+ncMYSwHckl/uC3xssDklx5AXNGn/5L8LE9Il09LtghxsftmIc
 Y5MrQ3pt2oguIL/oYpLJ8pO8Fv01Ad5nggAPS+NvKOYTY7AypvphkNKZqwSy6+ZHB8Po=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghj-00027g-7M; Wed, 15 Apr 2020 11:59:43 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghi-0008L0-TS; Wed, 15 Apr 2020 11:59:43 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v3 3/4] x86_64/mm: map and unmap page tables in
 share_hotadd_m2p_table
Date: Wed, 15 Apr 2020 12:59:26 +0100
Message-Id: <584d70dfd76de21231b1f39f25a36fe58375e4f0.1586951696.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586951696.git.hongyxia@amazon.com>
References: <cover.1586951696.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586951696.git.hongyxia@amazon.com>
References: <cover.1586951696.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Fetch lYe by mapping and unmapping lXe instead of using the direct map,
which is now done via the lYe_from_lXe() helpers.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

---
Changed in v2:
- the introduction of the macros is now lifted to a previous patch.
---
 xen/arch/x86/x86_64/mm.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 41755ded26..cfaeae84e9 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -166,14 +166,14 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
           v += n << PAGE_SHIFT )
     {
         n = L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES;
-        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-            l3_table_offset(v)];
+        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+                           l3_table_offset(v));
         if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
             continue;
         if ( !(l3e_get_flags(l3e) & _PAGE_PSE) )
         {
             n = L1_PAGETABLE_ENTRIES;
-            l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+            l2e = l2e_from_l3e(l3e, l2_table_offset(v));
             if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
                 continue;
             m2p_start_mfn = l2e_get_mfn(l2e);
@@ -194,11 +194,11 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
           v != RDWR_COMPAT_MPT_VIRT_END;
           v += 1 << L2_PAGETABLE_SHIFT )
     {
-        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-            l3_table_offset(v)];
+        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+                           l3_table_offset(v));
         if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
             continue;
-        l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+        l2e = l2e_from_l3e(l3e, l2_table_offset(v));
         if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
             continue;
         m2p_start_mfn = l2e_get_mfn(l2e);
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:59:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOgho-0003GJ-Bl; Wed, 15 Apr 2020 11:59:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOghm-0003FW-5m
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:59:46 +0000
X-Inumbo-ID: 973ca8c6-7f10-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 973ca8c6-7f10-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 11:59:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=CtlOkdsHjlKFcb39XzK+uw2HvlaIF3cGj21C2XsAUj8=; b=FpVo8693YOPFA2t/1W+vffr5Ws
 3tlJRH5F3gQAuMtWynTMp+WVSXr11rzOZbjUkHl5iMEBCTrPQAtJF53/Q3NaLj2s4ZwysEC24w4rA
 yAnvGCube/J6z8s1HAaSrMBRTieI2+S5xAS6acQQ8UnYjCrzRHRxBE43dGM4NyxRxscg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghh-00027X-Oa; Wed, 15 Apr 2020 11:59:41 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghh-0008L0-Eb; Wed, 15 Apr 2020 11:59:41 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v3 2/4] x86_64/mm: map and unmap page tables in m2p_mapped
Date: Wed, 15 Apr 2020 12:59:25 +0100
Message-Id: <4e76f1b1ad2f63c460571924632fa910c33a16fd.1586951696.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586951696.git.hongyxia@amazon.com>
References: <cover.1586951696.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586951696.git.hongyxia@amazon.com>
References: <cover.1586951696.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

---
Changed in v3:
- rename l3e_ro_mpt and l2e_ro_mpt, just call them l3e and l2e.

Changed in v2:
- avoid adding goto labels, simply get the PTE and unmap quickly.
- code style fixes.
---
 xen/arch/x86/x86_64/mm.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index cee836ec37..41755ded26 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -129,14 +129,13 @@ static mfn_t alloc_hotadd_mfn(struct mem_hotadd_info *info)
 static int m2p_mapped(unsigned long spfn)
 {
     unsigned long va;
-    l3_pgentry_t *l3_ro_mpt;
-    l2_pgentry_t *l2_ro_mpt;
+    l3_pgentry_t l3e;
+    l2_pgentry_t l2e;
 
     va = RO_MPT_VIRT_START + spfn * sizeof(*machine_to_phys_mapping);
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
+    l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(va)], l3_table_offset(va));
 
-    switch ( l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
-             (_PAGE_PRESENT |_PAGE_PSE))
+    switch ( l3e_get_flags(l3e) & (_PAGE_PRESENT | _PAGE_PSE) )
     {
         case _PAGE_PSE|_PAGE_PRESENT:
             return M2P_1G_MAPPED;
@@ -146,9 +145,9 @@ static int m2p_mapped(unsigned long spfn)
         default:
             return M2P_NO_MAPPED;
     }
-    l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
+    l2e = l2e_from_l3e(l3e, l2_table_offset(va));
 
-    if (l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT)
+    if ( l2e_get_flags(l2e) & _PAGE_PRESENT )
         return M2P_2M_MAPPED;
 
     return M2P_NO_MAPPED;
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 11:59:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 11:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOghx-0003KG-O0; Wed, 15 Apr 2020 11:59:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOghw-0003JY-68
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 11:59:56 +0000
X-Inumbo-ID: 99053150-7f10-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 99053150-7f10-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 11:59:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Onk2HyVxQC7Z1tK6M5fg+SsU7UsZSdPa4/KYlIbZ/2E=; b=0BLd2aIvG8etsRxbRHXjrkXjYV
 m37WBxwdF8k193NgpVxpzByiBdRFWR7gLrFHhfvSkCiiWfQngczijQAKUzHuh6AEYFr2r8DNiS5vB
 EfXiSa4qGaQpHuVJXEA3fSfP5BYUY83fnpWVrA9oVn0EqErWL5sq9ZzFq9tZL1YfWJU8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghk-00027o-NG; Wed, 15 Apr 2020 11:59:44 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOghk-0008L0-D0; Wed, 15 Apr 2020 11:59:44 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v3 4/4] x86_64/mm: map and unmap page tables in
 destroy_m2p_mapping
Date: Wed, 15 Apr 2020 12:59:27 +0100
Message-Id: <a38bb23216b30db902114dfe194d52889643ab08.1586951696.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586951696.git.hongyxia@amazon.com>
References: <cover.1586951696.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586951696.git.hongyxia@amazon.com>
References: <cover.1586951696.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed in v3:
- rename l2_ro_mpt into pl2e to avoid confusion.

Changed in v2:
- no point in re-mapping l2t because it is exactly the same as
  l2_ro_mpt.
- point l2_ro_mpt to the entry instead of doing l2_table_offset() all
  the time.
---
 xen/arch/x86/x86_64/mm.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index cfaeae84e9..30ed4e98dd 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -263,7 +263,8 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
     unsigned long i, va, rwva;
     unsigned long smap = info->spfn, emap = info->epfn;
 
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
+    l3_ro_mpt = map_l3t_from_l4e(
+                    idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
 
     /*
      * No need to clean m2p structure existing before the hotplug
@@ -271,7 +272,7 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
     for (i = smap; i < emap;)
     {
         unsigned long pt_pfn;
-        l2_pgentry_t *l2_ro_mpt;
+        l2_pgentry_t *pl2e;
 
         va = RO_MPT_VIRT_START + i * sizeof(*machine_to_phys_mapping);
         rwva = RDWR_MPT_VIRT_START + i * sizeof(*machine_to_phys_mapping);
@@ -285,26 +286,30 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
             continue;
         }
 
-        l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
-        if (!(l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT))
+        pl2e = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]) +
+                    l2_table_offset(va);
+        if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
         {
             i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
                     (1UL << (L2_PAGETABLE_SHIFT - 3)) ;
+            UNMAP_DOMAIN_PAGE(pl2e);
             continue;
         }
 
-        pt_pfn = l2e_get_pfn(l2_ro_mpt[l2_table_offset(va)]);
+        pt_pfn = l2e_get_pfn(*pl2e);
         if ( hotadd_mem_valid(pt_pfn, info) )
         {
             destroy_xen_mappings(rwva, rwva + (1UL << L2_PAGETABLE_SHIFT));
 
-            l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
-            l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_empty());
+            l2e_write(pl2e, l2e_empty());
         }
         i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
               (1UL << (L2_PAGETABLE_SHIFT - 3));
+        UNMAP_DOMAIN_PAGE(pl2e);
     }
 
+    UNMAP_DOMAIN_PAGE(l3_ro_mpt);
+
     destroy_compat_m2p_mapping(info);
 
     /* Brute-Force flush all TLB */
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 12:27:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 12:27:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOh8s-0006G9-Bn; Wed, 15 Apr 2020 12:27:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=lpyF=57=amazon.com=prvs=367615363=havanur@srs-us1.protection.inumbo.net>)
 id 1jOh8q-0006G4-Mg
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 12:27:44 +0000
X-Inumbo-ID: 811c62d0-7f14-11ea-8a3d-12813bfff9fa
Received: from smtp-fw-9101.amazon.com (unknown [207.171.184.25])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 811c62d0-7f14-11ea-8a3d-12813bfff9fa;
 Wed, 15 Apr 2020 12:27:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586953664; x=1618489664;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=Ypr6F6X+nyZd3U8ZYJDn6DO/KXiozq3RWpedk39Yrow=;
 b=i1jlJwls/4g/Aki5kg/DXTDfH75amBCgVWrHH24oJlNAnW8UFgFTPewq
 q4n1K5VQJh3iNyCqoumbN0QvR5RO0u3+Xvot1ceIsGzG04j10XCZb3Wvp
 jmNM0Tz4i20e6dlIp7tXdvk6C3iOPrBeRslXrlbSZjikrV4J1YtKgeIXC 8=;
IronPort-SDR: 0TCG3/zWB0BpgIZNnkpNlEYtaUHuujxHTKnRGsd94kac+V5f6HaJrEP2Ln58IFNN+cYw0KEvBZ
 L134WRL5LAeA==
X-IronPort-AV: E=Sophos;i="5.72,386,1580774400"; d="scan'208";a="28847748"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP;
 15 Apr 2020 12:27:41 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])
 by email-inbound-relay-1a-807d4a99.us-east-1.amazon.com (Postfix) with ESMTPS
 id C997CA06D1; Wed, 15 Apr 2020 12:27:38 +0000 (UTC)
Received: from EX13D36EUA004.ant.amazon.com (10.43.165.106) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Wed, 15 Apr 2020 12:27:38 +0000
Received: from EX13MTAUWC001.ant.amazon.com (10.43.162.135) by
 EX13D36EUA004.ant.amazon.com (10.43.165.106) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Wed, 15 Apr 2020 12:27:36 +0000
Received: from dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com
 (172.19.122.179) by mail-relay.amazon.com (10.43.162.232) with Microsoft SMTP
 Server id 15.0.1497.2 via Frontend Transport; Wed, 15 Apr 2020 12:27:35 +0000
Received: by dev-dsk-havanur-1a-5f065856.eu-west-1.amazon.com (Postfix,
 from userid 11119479)
 id A4F3483A5F; Wed, 15 Apr 2020 12:27:34 +0000 (UTC)
From: Harsha Shamsundara Havanur <havanur@amazon.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Wed, 15 Apr 2020 12:27:31 +0000
Message-ID: <9cfd038719fee7fcb01b8967ffcb23802bb75a0b.1586953651.git.havanur@amazon.com>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Harsha Shamsundara Havanur <havanur@amazon.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It was observed that PCI MMIO and/or IO BARs were programmed with
memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
during PCI setup phase. This resulted in incorrect memory mapping as
soon as the lower half of the 64 bit bar is programmed.
This displaced any RAM mappings under 4G. After the
upper half is programmed PCI memory mapping is restored to its
intended high mem location, but the RAM displaced is not restored.
The OS then continues to boot and function until it tries to access
the displaced RAM at which point it suffers a page fault and crashes.

This patch address the issue by deferring enablement of memory and
I/O decode in command register until all the resources, like interrupts
I/O and/or MMIO BARs for all the PCI device functions are programmed,
in the descending order of memory requested.

Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>

---
Changes in v5:
  - Fix style and comment
  - Enable Bus master for all valid device functions

Changes in v4:
  Addressed review comments from Jan Beulich <jbeulich@suse.com>
  - Disable decodes before writing ~0 to BARs
  - Enable BUS MASTER at the end along with decode bits

Changes in v3:
  - Retained enabling of BUS master for all device functions as
    was in original commit

Changes in v2:
  - BUS MASTER state was captured and restored to the same state
    while enabling decode bits.
---
---
 tools/firmware/hvmloader/pci.c | 49 +++++++++++++++++++++++++++++++-----------
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 0b708bf578..47cba69ce4 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -84,6 +84,7 @@ void pci_setup(void)
     uint32_t vga_devfn = 256;
     uint16_t class, vendor_id, device_id;
     unsigned int bar, pin, link, isa_irq;
+    uint8_t pci_devfn_decode_type[256] = {};
 
     /* Resources assignable to PCI devices via BARs. */
     struct resource {
@@ -120,6 +121,13 @@ void pci_setup(void)
      */
     bool allow_memory_relocate = 1;
 
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
+            PCI_COMMAND_IO);
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY !=
+            PCI_COMMAND_MEMORY);
+    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MASTER !=
+            PCI_COMMAND_MASTER);
+
     s = xenstore_read(HVM_XS_ALLOW_MEMORY_RELOCATE, NULL);
     if ( s )
         allow_memory_relocate = strtoll(s, NULL, 0);
@@ -208,6 +216,20 @@ void pci_setup(void)
             break;
         }
 
+        /*
+         * It is recommended that BAR programming be done whilst decode
+         * bits are cleared to avoid incorrect mappings being created.
+         * When 64-bit memory BAR is programmed, first by writing the
+         * lower half and then the upper half, which maps to an address
+         * under 4G, as soon as lower half is wriiten, replacing any RAM
+         * mapped in that address, which is not restored back after the
+         * upper half is written and PCI memory is correctly mapped to
+         * its intended high mem address.
+         */
+        cmd = pci_readw(devfn, PCI_COMMAND);
+        cmd &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
+        pci_writew(devfn, PCI_COMMAND, cmd);
+
         /* Map the I/O memory and port resources. */
         for ( bar = 0; bar < 7; bar++ )
         {
@@ -289,10 +311,8 @@ void pci_setup(void)
                    devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
         }
 
-        /* Enable bus mastering. */
-        cmd = pci_readw(devfn, PCI_COMMAND);
-        cmd |= PCI_COMMAND_MASTER;
-        pci_writew(devfn, PCI_COMMAND, cmd);
+        /* Enable bus master for this function later */
+        pci_devfn_decode_type[devfn] = PCI_COMMAND_MASTER;
     }
 
     if ( mmio_hole_size )
@@ -497,16 +517,12 @@ void pci_setup(void)
                PRIllx_arg(bar_sz),
                bar_data_upper, bar_data);
 			
-
-        /* Now enable the memory or I/O mapping. */
-        cmd = pci_readw(devfn, PCI_COMMAND);
         if ( (bar_reg == PCI_ROM_ADDRESS) ||
              ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
               PCI_BASE_ADDRESS_SPACE_MEMORY) )
-            cmd |= PCI_COMMAND_MEMORY;
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
         else
-            cmd |= PCI_COMMAND_IO;
-        pci_writew(devfn, PCI_COMMAND, cmd);
+            pci_devfn_decode_type[devfn] |= PCI_COMMAND_IO;
     }
 
     if ( pci_hi_mem_start )
@@ -526,10 +542,17 @@ void pci_setup(void)
          * has IO enabled, even if there is no I/O BAR on that
          * particular device.
          */
-        cmd = pci_readw(vga_devfn, PCI_COMMAND);
-        cmd |= PCI_COMMAND_IO;
-        pci_writew(vga_devfn, PCI_COMMAND, cmd);
+        pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO;
     }
+
+    /* Enable bus master, memory and I/O decode for all valid functions. */
+    for ( devfn = 0; devfn < 256; devfn++ )
+        if ( pci_devfn_decode_type[devfn] )
+        {
+            cmd = pci_readw(devfn, PCI_COMMAND);
+            cmd |= pci_devfn_decode_type[devfn];
+            pci_writew(devfn, PCI_COMMAND, cmd);
+        }
 }
 
 /*
-- 
2.16.6



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:05:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:05:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOhid-0001EO-Gk; Wed, 15 Apr 2020 13:04:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=RJH9=57=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jOhic-0001EI-Fu
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:04:42 +0000
X-Inumbo-ID: aaf5a9c2-7f19-11ea-b4f4-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id aaf5a9c2-7f19-11ea-b4f4-bc764e2007e4;
 Wed, 15 Apr 2020 13:04:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586955881;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=79d8KqDNuAXqMFomukL7xmb6KtL6IOkDjGNslzZ/fmg=;
 b=PD8yhyJTbGPXdONhTNH9acbXmuItc8Qo5QoQzVReBcikemOYUWlfyhr5
 ulzSIWFWtXuWa5CmG4TEjXrL5VupVGMI5w2EsLlueYM50/3xlvNcLTgSy
 cXQCYO8EWfi0qYU+OztINqXDMFcoei/92qM8swbIzKgZdD2Zv7gs6jgUX k=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: saWE+cP21grtGkWqvoUsDsRNa4nZGeVL56CCv14lsWiE/aZQJzzKWXa56GfbyyyT+IhP3Xmwhe
 +o2mInfrTVqYO0Y5/564uoL4i4KDmmbvkk4luYxskBf044WshZ/3cb/BZWlKfYlZBLq7/I8rLb
 6Pq3zWenZFxbH5B9qPTY5/5B3pIu/4Xrno2VaW6gazExKM7cqwnjPeZahrWgBBiFwwN3Ks2ic1
 fUKLhrLfKZF61E7zDfnOXBxjiww+xTbP8v93jnkXHy5o9pHE/YWJyDESVL4HaEJYkWNfvk4hZM
 fe4=
X-SBRS: 2.7
X-MesageID: 16387079
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="16387079"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24215.1635.613926.945930@mariner.uk.xensource.com>
Date: Wed, 15 Apr 2020 14:04:35 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag
In-Reply-To: <20200415085246.7945-1-roger.pau@citrix.com>
References: <20200415085246.7945-1-roger.pau@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("[PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag"):
> Check if hosts have SMT based on the number of threads per core. A
> value of threads per core different than 0 implies SMT support.
...
> +logm("$ho->{Ident} threads per core: $threads");
> +hostflag_putative_record($ho, "smt", !!$threads);

This code LGTM but I wonder if it would be a good idea to start
namespacing these kind of hardware feature flags.  cpu-*, hardware-*,
feature-* maybe ?  Would you care to make a suggestion ?

Ian.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:06:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:06:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOhk8-0001Jx-VY; Wed, 15 Apr 2020 13:06:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=RJH9=57=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jOhk8-0001Jp-1K
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:06:16 +0000
X-Inumbo-ID: e30cc6a6-7f19-11ea-b58d-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e30cc6a6-7f19-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 13:06:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586955975;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=c5C3O4DQWQWnKvdfxBn1JnwkNHvHOdD5NuUuLCzLZbk=;
 b=bP2XhgbH2NcAU4cD8Y/gy58VLRxvsqxqgxz/Ulzju1+eSjUYCKIRElIM
 zWtvxd7yWdQeGtq/OSAaZ/pnRTxqu0HzBTgiOBYNrwNXFTKoJK+BK5z0G
 ivLi0uD8apPJobBDUlpT/wq6NXNejEjnsPfhJclYp2XjSeLnB0qOVFtJs g=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Doz4JmH4vMNYy482yESTydNSqcnBhFu/kBIqRiW/DTUitZal3NcDtySbiR2w3ttvskjaR8Gauc
 MmLwuwvL4mpI6s4RQ/QLwsUsXZvkLeOFXfWXD0KrxqKDexEWtLZnJfrIhRXwLYfaRih6LYVgVZ
 hS1iJPKSrN3SwQn237KLnD7M8uWBPKi67EzMr1gPmIbE2BCNlr1iPwiTZKTKv2kuCOIGW+8n2a
 C6zZxrKUBmMzmXqCJ1O3DzsTnpm5vWSZZ8JCiKpYCIpBQxcq1vy8XReuN13m0v6hXV/g9S0wmD
 VD8=
X-SBRS: 2.7
X-MesageID: 16031417
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="16031417"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24215.1729.892903.300149@mariner.uk.xensource.com>
Date: Wed, 15 Apr 2020 14:06:09 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job
In-Reply-To: <20200415085246.7945-2-roger.pau@citrix.com>
References: <20200415085246.7945-1-roger.pau@citrix.com>
 <20200415085246.7945-2-roger.pau@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("[PATCH OSSTEST 2/2] make-flight: add a core scheduling job"):
> Run a simple core scheduling tests on a host that has SMT support.
> This is only enabled for Xen >= 4.13.
...
> +  # Core-scheduling tests are x86 only
> +  if [ x$test_coresched = xy -a $xenarch = amd64 ]; then
> +    job_create_test test-$xenarch$kern-coresched-$dom0arch-xl \
> +                    test-debian xl $xenarch $dom0arch $debian_runvars \
> +                    all_hostflags=$most_hostflags,smt \
> +                    xen_boot_append='sched-gran=core'
> +
> +  fi

This seems fine as far as it goes, but all it does is check that
things still work if sched-gran=core is passed.  I'm not sure whether
anything more sophisticated is needed, and in any case this is a step
in the right direction, so:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(subject to my comment on 1/ about the flag name.)

Ian.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:07:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOhlJ-0001QS-DH; Wed, 15 Apr 2020 13:07:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=RJH9=57=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jOhlH-0001QF-Kx
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:07:27 +0000
X-Inumbo-ID: 0d70d0ae-7f1a-11ea-8a49-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0d70d0ae-7f1a-11ea-8a49-12813bfff9fa;
 Wed, 15 Apr 2020 13:07:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586956047;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=ovDGVe72F4HtehzecLzgJ6GKmjgHgrieQ/BnRYJFBYU=;
 b=AHYOlw1KZBjEGKXp4ozu1Eab0qSEcYBMT9BPP6XRKGl6H02PNgKtcZ/O
 Pt6jyFZdncX1hHHA3oFWaX72XXt6Y8Yw3xZxHb9tPPU8+65hK00Fxq+xb
 wGiEgrbUaHjOCgx3+DbkGu0/QK1tbRJ7WsFVm3ueJvhDwIgMwHJ3HUpXA c=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: dcQ+MZkJHve15iwwa9DBAFOMnaI20CM6thtaFPOrhq77Z6KB0zn/i64u66AkKUur02uznJCKET
 wYMc1jZr+vgopDp9b36+4nUMIqWNN0jnh13PvPI0qoSvtVpvtS2XCOqR9AvRY+cYdz4pXzOOL8
 Dd4vd2kcK+f7RW1Kmr/3DxxAK4yQ/EsDWFZppEToLEgdYPfTf3RFSYeQxEKOaXF5bj3eefdbp2
 iHFAT6rO++FAGwxaPe6lkjF0v1BPYg/0h/3snc1cXVbLTCg+gbXEX9l/s2kvrFh5vTNL2j4RKw
 9n0=
X-SBRS: 2.7
X-MesageID: 15697461
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,386,1580792400"; d="scan'208";a="15697461"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24215.1796.244074.907303@mariner.uk.xensource.com>
Date: Wed, 15 Apr 2020 14:07:16 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH OSSTEST v2 1/2] exanime: test for SMT and add a host flag
In-Reply-To: <20200415101509.8763-1-roger.pau@citrix.com>
References: <20200415085246.7945-1-roger.pau@citrix.com>
 <20200415101509.8763-1-roger.pau@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("[PATCH OSSTEST v2 1/2] exanime: test for SMT and add a host flag"):
> Check if hosts have SMT based on the number of threads per core. A
> value of threads per core greater than 1 implies SMT support.

I spotted the "0" in v1 but since you had clearly stated the same
thing in the commit message too I thought you knew what you were doing
:-).

Thanks,
Ian.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:24:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOi1Y-0003C8-Tj; Wed, 15 Apr 2020 13:24:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOi1X-0003C3-Ft
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:24:15 +0000
X-Inumbo-ID: 66c9ffe8-7f1c-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 66c9ffe8-7f1c-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 13:24:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=8pNF50j22WVox24Z159EB27HGmrQcEzMaNofE2TuaEA=; b=nWKrSyL/lSjBOeSmFCPDPxJB3w
 S0QxVlkr80dAwx6xVfekidJneje5edYgfS6c1CqiGtD97PyDJCnBgnT5zxqHcgUrETdPcdoQIBUp7
 EknnK5fffybbFnib9PGh5wuWfNjJR1Zv/Ubuof8jBRuYjtAYCWjDmas6oF3c0fU+BS44=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOi1R-0003jy-Vy; Wed, 15 Apr 2020 13:24:09 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOi1R-0006ZR-N5; Wed, 15 Apr 2020 13:24:09 +0000
Subject: Re: [PATCH 05/12] xen: introduce reserve_heap_pages
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-5-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <a5a3f831-c15d-7503-c7fd-876b466ca87c@xen.org>
Date: Wed, 15 Apr 2020 14:24:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-5-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, jbeulich@suse.com,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15/04/2020 02:02, Stefano Stabellini wrote:
> Introduce a function named reserve_heap_pages (similar to
> alloc_heap_pages) that allocates a requested memory range. Call
> __alloc_heap_pages for the implementation.
> 
> Change __alloc_heap_pages so that the original page doesn't get
> modified, giving back unneeded memory top to bottom rather than bottom
> to top.
> 
> Also introduce a function named reserve_domheap_pages, similar to
> alloc_domheap_pages, that checks memflags before calling
> reserve_heap_pages. It also assign_pages to the domain on success.

Xen may have already allocated the part of region for its own purpose or 
for another domain. So this will not work reliably.

We have the same issues with LiveUpdate as memory have to be preserved. 
We need to mark the page reserved before any allocation (including early 
boot allocation) so nobody can use them. See [1].

Cheers,

[1]  Live update: boot memory management, data stream handling, record 
format <a92287c03fed310e08ba40063e370038569b94ac.camel@infradead.org>

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:26:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:26:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOi41-0003Ja-Dq; Wed, 15 Apr 2020 13:26:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOi40-0003JU-4O
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:26:48 +0000
X-Inumbo-ID: c164df40-7f1c-11ea-8a4d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c164df40-7f1c-11ea-8a4d-12813bfff9fa;
 Wed, 15 Apr 2020 13:26:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=x41VIlJivgIAl7su1MrknNaAlw7LUAGcP9Z9yp7xm+g=; b=CC0u9RzuO/gvCYdJuHP9wQGQJp
 ErJHn3u5zLzJvSDFS7aF22m2sWUTw9K+gIVVtPj37wEImsmOPFnBPIMV+M/Dt7hyLOj7jMJPzldEk
 hI57KuEkwcig+HVM7QEPPG+70HxM2+QNwYSBwRGh7VyrsdF6Xh73dE6uj77tHoItA5tM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOi3w-0003mu-0b; Wed, 15 Apr 2020 13:26:44 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOi3v-0006iK-Px; Wed, 15 Apr 2020 13:26:43 +0000
Subject: Re: [PATCH 01/12] xen: introduce xen_dom_flags
To: Jan Beulich <jbeulich@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-1-sstabellini@kernel.org>
 <aede4742-03e1-e47b-354a-5475f63fff86@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <992bade3-7717-62b0-06a8-88c9dc15937e@xen.org>
Date: Wed, 15 Apr 2020 14:26:41 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <aede4742-03e1-e47b-354a-5475f63fff86@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 Dario Faggioli <dfaggioli@suse.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 15/04/2020 10:12, Jan Beulich wrote:
> On 15.04.2020 03:02, Stefano Stabellini wrote:
>> We are passing an extra special boolean flag at domain creation to
>> specify whether we want to the domain to be privileged (i.e. dom0) or
>> not. Another flag will be introduced later in this series.
>>
>> Introduce a new struct xen_dom_flags and move the privileged flag to it.
>> Other flags will be added to struct xen_dom_flags.
> 
> I'm unsure whether introducing a 2nd structure is worth it here.
> We could as well define some internal-use-only flags for
> struct xen_domctl_createdomain's respective field.

+1.

> 
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -529,7 +529,8 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>>   }
>>   
>>   int arch_domain_create(struct domain *d,
>> -                       struct xen_domctl_createdomain *config)
>> +                       struct xen_domctl_createdomain *config,
>> +                       struct xen_dom_flags *flags)
> 
> const (also elsewhere)?
> 
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -706,6 +706,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>           .max_maptrack_frames = -1,
>>       };
>>       const char *hypervisor_name;
>> +    struct xen_dom_flags flags = { !pv_shim };
> 
> Here and elsewhere please use field designators right away, even if
> there's only a single field now.
> 
>> @@ -363,7 +363,7 @@ struct domain *domain_create(domid_t domid,
>>       ASSERT(is_system_domain(d) ? config == NULL : config != NULL);
>>   
>>       /* Sort out our idea of is_control_domain(). */
>> -    d->is_privileged = is_priv;
>> +    d->is_privileged =  flags ? flags->is_priv : false;
> 
> Stray double blanks.
> 
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -364,6 +364,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>       bool_t copyback = 0;
>>       struct xen_domctl curop, *op = &curop;
>>       struct domain *d;
>> +    struct xen_dom_flags flags ={ false };
> 
> Missing blank.
> 
>> --- a/xen/include/xen/domain.h
>> +++ b/xen/include/xen/domain.h
>> @@ -63,8 +63,13 @@ void arch_vcpu_destroy(struct vcpu *v);
>>   int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset);
>>   void unmap_vcpu_info(struct vcpu *v);
>>   
>> +struct xen_dom_flags {
>> +    bool is_priv;
> 
> Use a single bit bitfield instead? May even want to consider passing
> this struct by value then.

This is an alternative if extending xen_domctl_createdomain is not a 
solution. The bitfield is easier to extend because we don't need to 
create a new field for each flag in struct domain.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:36:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOiD8-0004FG-Kk; Wed, 15 Apr 2020 13:36:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOiD7-0004FB-Hz
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:36:13 +0000
X-Inumbo-ID: 128c91e6-7f1e-11ea-8a4d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 128c91e6-7f1e-11ea-8a4d-12813bfff9fa;
 Wed, 15 Apr 2020 13:36:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=4GFoXadHKTVKLBfHvbMtoqd143ZBIehi3HQhj4NJpfw=; b=hmoSsmdAqtibBKq2EvUneZqKEm
 5jd02qNlpUd5Khyb8LwzImrWlcIrO2UakXnHTvyChlIaroDiUzQpYJ/RouNvtNZSDi3/qDgFDGl82
 FWRujRMoRjegqozZsBXtxjMVOXiOc59yDG4EnSxE+PBR0/+CNLKeqCa8IAyolsvMBVZI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiD5-0003yF-0j; Wed, 15 Apr 2020 13:36:11 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiD4-0007LF-MB; Wed, 15 Apr 2020 13:36:10 +0000
Subject: Re: [PATCH 03/12] xen/arm: introduce 1:1 mapping for domUs
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-3-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <3f26f6a0-89bd-cbec-f07f-90a08fa60e26@xen.org>
Date: Wed, 15 Apr 2020 14:36:09 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-3-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 15/04/2020 02:02, Stefano Stabellini wrote:
> In some cases it is desirable to map domU memory 1:1 (guest physical ==
> physical.) For instance, because we want to assign a device to the domU
> but the IOMMU is not present or cannot be used. In these cases, other
> mechanisms should be used for DMA protection, e.g. a MPU.

I am not against this, however the documentation should clearly explain 
that you are making your platform insecure unless you have other mean 
for DMA protection.

> 
> This patch introduces a new device tree option for dom0less guests to
> request a domain to be directly mapped. It also specifies the memory
> ranges. This patch documents the new attribute and parses it at boot
> time. (However, the implementation of 1:1 mapping is missing and just
> BUG() out at the moment.)  Finally the patch sets the new direct_map
> flag for DomU domains.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> ---
>   docs/misc/arm/device-tree/booting.txt | 13 +++++++
>   docs/misc/arm/passthrough-noiommu.txt | 35 ++++++++++++++++++
>   xen/arch/arm/domain_build.c           | 52 +++++++++++++++++++++++++--
>   3 files changed, 98 insertions(+), 2 deletions(-)
>   create mode 100644 docs/misc/arm/passthrough-noiommu.txt
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index 5243bc7fd3..fce5f7ed5a 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -159,6 +159,19 @@ with the following properties:
>       used, or GUEST_VPL011_SPI+1 if vpl011 is enabled, whichever is
>       greater.
>   
> +- direct-map
> +
> +    Optional. An array of integer pairs specifying addresses and sizes.
> +    direct_map requests the memory of the domain to be 1:1 mapped with
> +    the memory ranges specified as argument. Only sizes that are a
> +    power of two number of pages are allowed.
> +
> +- #direct-map-addr-cells and #direct-map-size-cells
> +
> +    The number of cells to use for the addresses and for the sizes in
> +    direct-map. Default and maximum are 2 cells for both addresses and
> +    sizes.
> +

As this is going to be mostly used for passthrough, can't we take 
advantage of the partial device-tree and describe the memory region 
using memory node?

>   - #address-cells and #size-cells
>   
>       Both #address-cells and #size-cells need to be specified because
> diff --git a/docs/misc/arm/passthrough-noiommu.txt b/docs/misc/arm/passthrough-noiommu.txt
> new file mode 100644
> index 0000000000..d2bfaf26c3
> --- /dev/null
> +++ b/docs/misc/arm/passthrough-noiommu.txt
> @@ -0,0 +1,35 @@
> +Request Device Assignment without IOMMU support
> +===============================================
> +
> +Add xen,force-assign-without-iommu; to the device tree snippet
> +
> +    ethernet: ethernet@ff0e0000 {
> +        compatible = "cdns,zynqmp-gem";
> +        xen,path = "/amba/ethernet@ff0e0000";
> +        xen,reg = <0x0 0xff0e0000 0x1000 0x0 0xff0e0000>;
> +        xen,force-assign-without-iommu;
> +
> +Optionally, if none of the domains require an IOMMU, then it could be
> +disabled (not recommended). For instance by adding status = "disabled";
> +under the smmu node:
> +
> +    smmu@fd800000 {
> +        compatible = "arm,mmu-500";
> +        status = "disabled";

I am not sure why this section is added in this patch. Furthermore, the 
file is named "noiommu" but here you mention the IOMMU.

> +
> +
> +Request 1:1 memory mapping for the dom0-less domain
> +===================================================
> +
> +Add a direct-map property under the appropriate /chosen/domU node with
> +the memory ranges you want to assign to your domain. If you are using
> +imagebuilder, you can add to boot.source something like the following:
> +
> +    fdt set /chosen/domU0 direct-map <0x0 0x10000000 0x0 0x10000000 0x0 0x60000000 0x0 0x10000000>
> +
> +Which will assign the ranges:
> +
> +    0x10000000 - 0x20000000
> +    0x60000000 - 0x70000000
> +
> +to the first dom0less domU.
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 2ec7453aa3..a2bb411568 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2435,7 +2435,51 @@ static int __init construct_domU(struct domain *d,
>       /* type must be set before allocate memory */
>       d->arch.type = kinfo.type;
>   #endif
> -    allocate_memory(d, &kinfo);
> +
> +    if ( !is_domain_direct_mapped(d) )
> +        allocate_memory(d, &kinfo);
> +    else
> +    {
> +        struct membank banks[NR_MEM_BANKS];
> +        const struct dt_property *prop;
> +        u32 direct_map_len, direct_map_addr_len = 2, direct_map_size_len = 2;
> +        unsigned int i;
> +        __be32 *p;
> +
> +        prop = dt_find_property(node, "direct-map", &direct_map_len);
> +        BUG_ON(!prop);
> +
> +        dt_property_read_u32(node,
> +                             "#direct-map-addr-cells",
> +                             &direct_map_addr_len);
> +        dt_property_read_u32(node,
> +                             "#direct-map-size-cells",
> +                             &direct_map_size_len);
> +        BUG_ON(direct_map_size_len > 2 || direct_map_addr_len > 2);
> +
> +        for ( i = 0, p = prop->value;
> +              i < direct_map_len /
> +                  (4 * (direct_map_addr_len + direct_map_size_len));
> +              i++)
> +        {
> +            int j;
> +
> +            banks[i].start = 0;
> +            for ( j = 0; j < direct_map_addr_len; j++, p++ )
> +                banks[i].start |= __be32_to_cpu(*p) << (32*j);

Please use dt_read_number();

> +
> +            banks[i].size = 0;
> +            for ( j = 0; j < direct_map_size_len; j++, p++ )
> +                banks[i].size |= __be32_to_cpu(*p) << (32*j);
> +

Same here.

> +            printk(XENLOG_DEBUG
> +                   "direct_map start=%#"PRIpaddr" size=%#"PRIpaddr"\n",
> +                   banks[i].start, banks[i].size);
> +        }
> +
> +        /* reserve_memory_11(d, &kinfo, &banks[0], i); */
> +        BUG();

This can be avoided by re-ordering the patches and folding #6 in this patch.

> +    }
>   
>       rc = prepare_dtb_domU(d, &kinfo);
>       if ( rc < 0 )
> @@ -2455,6 +2499,7 @@ void __init create_domUs(void)
>   {
>       struct dt_device_node *node;
>       const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
> +    u32 direct_map = 0;
>   
>       BUG_ON(chosen == NULL);
>       dt_for_each_child_node(chosen, node)
> @@ -2476,8 +2521,11 @@ void __init create_domUs(void)
>               panic("Missing property 'cpus' for domain %s\n",`
>                     dt_node_name(node));
>   
> -        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
> +        dt_find_property(node, "direct-map", &direct_map);

Please use dt_property_read_bool().

> +        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") &&
> +             !direct_map )
>               d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
> +        flags.arch.is_direct_map = direct_map != 0;
>   
>           if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) )
>           {
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:38:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:38:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOiF0-0004Kq-3F; Wed, 15 Apr 2020 13:38:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOiEy-0004Kk-3m
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:38:08 +0000
X-Inumbo-ID: 56ce3562-7f1e-11ea-8a4d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 56ce3562-7f1e-11ea-8a4d-12813bfff9fa;
 Wed, 15 Apr 2020 13:38:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=INowOVj9IdoeK+rq17IpDkaPC+/t5lBJg9NrTMbN+Sc=; b=WOM2M1c3XhcWq+XZJdnrN9wWXq
 LOpwzgUytiY4fi/vFe5qgspnAYNgcatQcb6gsSIuW6huf2rQClZrzdop3tc5RMzhiMEmg6sw3/o0q
 CVLSyjtpYpRvzZGRj5m7nggfVPnfVUzKzltg7X7uEekAWJqTYdUNVWmsG60cvoinpFKc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiEv-000407-M3; Wed, 15 Apr 2020 13:38:05 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiEv-0007Wo-DC; Wed, 15 Apr 2020 13:38:05 +0000
Subject: Re: [PATCH 06/12] xen/arm: reserve 1:1 memory for direct_map domUs
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-6-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <5647e3b8-4ade-70e8-273c-8ee54f9614ee@xen.org>
Date: Wed, 15 Apr 2020 14:38:03 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-6-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 15/04/2020 02:02, Stefano Stabellini wrote:
> Use reserve_domheap_pages to implement the direct-map ranges allocation
> for DomUs.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> ---
>   xen/arch/arm/domain_build.c | 37 +++++++++++++++++++++++++++++++++++--
>   1 file changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index a2bb411568..627e0c5e8e 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -198,6 +198,40 @@ fail:
>       return false;
>   }
>   
> +static void __init reserve_memory_11(struct domain *d,
> +                                     struct kernel_info *kinfo,
> +                                     struct membank *banks,
> +                                     unsigned int nr_banks)

Can we stop introduce more void function and properly return an error?

> +{
> +    unsigned int i, order;
> +    struct page_info *pg;
> +
> +    kinfo->mem.nr_banks = 0;
> +
> +    for ( i = 0; i < nr_banks; i++ )
> +    {
> +        order = get_order_from_bytes(banks[i].size);
> +        pg = reserve_domheap_pages(d, banks[i].start, order, 0);
> +        if ( pg == NULL || !insert_11_bank(d, kinfo, pg, order) )
> +        {
> +            printk(XENLOG_ERR
> +                   "%pd: cannot reserve memory start=%#"PRIpaddr" size=%#"PRIpaddr"\n",
> +                    d, banks[i].start, banks[i].size);
> +            BUG();
> +        }
> +    }
> +
> +    for( i = 0; i < kinfo->mem.nr_banks; i++ )
> +    {
> +        printk("BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
> +                i,
> +                kinfo->mem.bank[i].start,
> +                kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
> +                /* Don't want format this as PRIpaddr (16 digit hex) */
> +                (unsigned long)(kinfo->mem.bank[i].size >> 20));
> +    }
> +}
> +
>   /*
>    * This is all pretty horrible.
>    *
> @@ -2477,8 +2511,7 @@ static int __init construct_domU(struct domain *d,
>                      banks[i].start, banks[i].size);
>           }
>   
> -        /* reserve_memory_11(d, &kinfo, &banks[0], i); */
> -        BUG();
> +        reserve_memory_11(d, &kinfo, &banks[0], i);

If you fold this in #3 and re-order the patches then you don't need the 
the commented code + BUG().

>       }
>   
>       rc = prepare_dtb_domU(d, &kinfo);
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:41:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOiIC-0005BS-O7; Wed, 15 Apr 2020 13:41:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOiIB-0005BM-Pb
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:41:27 +0000
X-Inumbo-ID: ce07b856-7f1e-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ce07b856-7f1e-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 13:41:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=BxQrAdfzrB++GpsauX6901bkGRH5ZevSSMr6kgxcl58=; b=jVmlsR0xXuvTkLUHYQ7vPRPGZK
 9qzMdqXf4PGVmuGo7H4uWKn+RyCqYVUlkxIX2y3xFerq7yCIkYTb9uMvBuI7udylX1sISsiG9csw9
 N2VJ60qxFz11LG4PhjPgVNzsBzFMfgDydWyj59PQbQEAp3QoQDiHJ5XVudaH7VYY2eVI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiI9-00044L-AJ; Wed, 15 Apr 2020 13:41:25 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiI8-0007os-Vs; Wed, 15 Apr 2020 13:41:25 +0000
Subject: Re: [PATCH 07/12] xen/arm: new vgic: rename vgic_cpu/dist_base to
 c/dbase
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-7-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <1a553919-9844-6802-4399-e6a6a2b3536b@xen.org>
Date: Wed, 15 Apr 2020 14:41:23 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-7-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 15/04/2020 02:02, Stefano Stabellini wrote:
> To be uniform with the old vgic. Name uniformity will become immediately
> useful in the following patch.

Please no. Those fields are not meant to be exposed outside of the vGIC.

'cbase' is also much less obvious to read over vgic_cpu_base.

Instead please introduce an helper to retrieve the information you need.

> In vgic_v2_map_resources, use the fields in struct vgic_dist rather than
> local variables.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> ---
>   xen/arch/arm/vgic/vgic-init.c  |  4 ++--
>   xen/arch/arm/vgic/vgic-v2.c    | 16 ++++++++--------
>   xen/include/asm-arm/new_vgic.h |  4 ++--
>   3 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c
> index 62ae553699..ea739d081e 100644
> --- a/xen/arch/arm/vgic/vgic-init.c
> +++ b/xen/arch/arm/vgic/vgic-init.c
> @@ -112,8 +112,8 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
>           BUG();
>       }
>   
> -    d->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
> -    d->arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;
> +    d->arch.vgic.dbase = VGIC_ADDR_UNDEF;
> +    d->arch.vgic.cbase = VGIC_ADDR_UNDEF;
>       d->arch.vgic.vgic_redist_base = VGIC_ADDR_UNDEF;
>   
>       return 0;
> diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
> index b5ba4ace87..09cb92039a 100644
> --- a/xen/arch/arm/vgic/vgic-v2.c
> +++ b/xen/arch/arm/vgic/vgic-v2.c
> @@ -258,7 +258,7 @@ void vgic_v2_enable(struct vcpu *vcpu)
>   int vgic_v2_map_resources(struct domain *d)
>   {
>       struct vgic_dist *dist = &d->arch.vgic;
> -    paddr_t cbase, csize;
> +    paddr_t csize;
>       paddr_t vbase;
>       int ret;
>   
> @@ -268,7 +268,7 @@ int vgic_v2_map_resources(struct domain *d)
>        */
>       if ( is_hardware_domain(d) )
>       {
> -        d->arch.vgic.vgic_dist_base = gic_v2_hw_data.dbase;
> +        d->arch.vgic.dbase = gic_v2_hw_data.dbase;
>           /*
>            * For the hardware domain, we always map the whole HW CPU
>            * interface region in order to match the device tree (the "reg"
> @@ -276,13 +276,13 @@ int vgic_v2_map_resources(struct domain *d)
>            * Note that we assume the size of the CPU interface is always
>            * aligned to PAGE_SIZE.
>            */
> -        cbase = gic_v2_hw_data.cbase;
> +        d->arch.vgic.cbase = gic_v2_hw_data.cbase;
>           csize = gic_v2_hw_data.csize;
>           vbase = gic_v2_hw_data.vbase;
>       }
>       else
>       {
> -        d->arch.vgic.vgic_dist_base = GUEST_GICD_BASE;
> +        d->arch.vgic.dbase = GUEST_GICD_BASE;
>           /*
>            * The CPU interface exposed to the guest is always 8kB. We may
>            * need to add an offset to the virtual CPU interface base
> @@ -290,13 +290,13 @@ int vgic_v2_map_resources(struct domain *d)
>            * region.
>            */
>           BUILD_BUG_ON(GUEST_GICC_SIZE != SZ_8K);
> -        cbase = GUEST_GICC_BASE;
> +        d->arch.vgic.cbase = GUEST_GICC_BASE;
>           csize = GUEST_GICC_SIZE;
>           vbase = gic_v2_hw_data.vbase + gic_v2_hw_data.aliased_offset;
>       }
>   
>   
> -    ret = vgic_register_dist_iodev(d, gaddr_to_gfn(dist->vgic_dist_base),
> +    ret = vgic_register_dist_iodev(d, gaddr_to_gfn(dist->dbase),
>                                      VGIC_V2);
>       if ( ret )
>       {
> @@ -308,8 +308,8 @@ int vgic_v2_map_resources(struct domain *d)
>        * Map the gic virtual cpu interface in the gic cpu interface
>        * region of the guest.
>        */
> -    ret = map_mmio_regions(d, gaddr_to_gfn(cbase), csize / PAGE_SIZE,
> -                           maddr_to_mfn(vbase));
> +    ret = map_mmio_regions(d, gaddr_to_gfn(d->arch.vgic.cbase),
> +                           csize / PAGE_SIZE, maddr_to_mfn(vbase));
>       if ( ret )
>       {
>           gdprintk(XENLOG_ERR, "Unable to remap VGIC CPU to VCPU\n");
> diff --git a/xen/include/asm-arm/new_vgic.h b/xen/include/asm-arm/new_vgic.h
> index 97d622bff6..e3319900ab 100644
> --- a/xen/include/asm-arm/new_vgic.h
> +++ b/xen/include/asm-arm/new_vgic.h
> @@ -115,11 +115,11 @@ struct vgic_dist {
>       unsigned int        nr_spis;
>   
>       /* base addresses in guest physical address space: */
> -    paddr_t             vgic_dist_base;     /* distributor */
> +    paddr_t             dbase;     /* distributor */
>       union
>       {
>           /* either a GICv2 CPU interface */
> -        paddr_t         vgic_cpu_base;
> +        paddr_t         cbase;
>           /* or a number of GICv3 redistributor regions */
>           struct
>           {
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:43:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOiJo-0005GV-5h; Wed, 15 Apr 2020 13:43:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+yDq=57=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOiJn-0005GQ-BE
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:43:07 +0000
X-Inumbo-ID: 0869c0d4-7f1f-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0869c0d4-7f1f-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 13:43:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=CoEv60sRIp/WYanHll9JFwJ7C43KeqWNJeLp/SPdbXI=; b=vIzwpH92FWj87hQgKEtkaar/o
 o/MWM/59qBqZvWPLH5ip/Ib0oZBWajyF3zOSL5HJomkoioBcAKa3QzS5TR7EGjqoIWcGvuyIbOran
 y3T9z6t+sqD5Z6HaUttuCOkEHJn0KQfp/y8vBqlwCiSft/3OeyZQh09kj7hmeDJu0U72o=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOiJk-000466-PR; Wed, 15 Apr 2020 13:43:04 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOiJk-0000SW-HB; Wed, 15 Apr 2020 13:43:04 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOiJk-0001MK-GC; Wed, 15 Apr 2020 13:43:04 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149650-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.10-testing test] 149650: regressions - trouble:
 fail/pass/starved
X-Osstest-Failures: xen-4.10-testing:test-xtf-amd64-amd64-5:xtf/test-hvm64-lbr-tsx-vmentry:fail:regression
 xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: xen=24d62e126296b3f67dabdd49887d41d8ed69487f
X-Osstest-Versions-That: xen=49a5d6e92317a7d9acbf0bdbd25b2809dfd84260
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 15 Apr 2020 13:43:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5 51 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 146101

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 146076
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop             fail like 146101
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-xl-thunderx  2 hosts-allocate               starved  n/a

version targeted for testing:
 xen                  24d62e126296b3f67dabdd49887d41d8ed69487f
baseline version:
 xen                  49a5d6e92317a7d9acbf0bdbd25b2809dfd84260

Last test of basis   146101  2020-01-15 04:00:32 Z   91 days
Testing same since   149650  2020-04-14 13:35:36 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 starved 
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit 24d62e126296b3f67dabdd49887d41d8ed69487f
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 14 15:14:21 2020 +0200

    gnttab: fix GNTTABOP_copy continuation handling
    
    The XSA-226 fix was flawed - the backwards transformation on rc was done
    too early, causing a continuation to not get invoked when the need for
    preemption was determined at the very first iteration of the request.
    This in particular means that all of the status fields of the individual
    operations would be left untouched, i.e. set to whatever the caller may
    or may not have initialized them to.
    
    This is part of XSA-318.
    
    Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Tested-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    master commit: d6f22d5d9e8d6848ec229083ac9fb044f0adea93
    master date: 2020-04-14 14:42:32 +0200

commit cbedabf8276f95bb4e93a5df43257790de87daad
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Tue Apr 14 15:13:24 2020 +0200

    xen/gnttab: Fix error path in map_grant_ref()
    
    Part of XSA-295 (c/s 863e74eb2cffb) inadvertently re-positioned the brackets,
    changing the logic.  If the _set_status() call fails, the grant_map hypercall
    would fail with a status of 1 (rc != GNTST_okay) instead of the expected
    negative GNTST_* error.
    
    This error path can be taken due to bad guest state, and causes net/blk-back
    in Linux to crash.
    
    This is XSA-316.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>
    master commit: da0c66c8f48042a0186799014af69db0303b1da5
    master date: 2020-04-14 14:41:02 +0200

commit 38e589d4b0eeb917e14cc021e62669f04cabd31b
Author: Julien Grall <jgrall@amazon.com>
Date:   Tue Apr 14 15:11:38 2020 +0200

    xen/rwlock: Add missing memory barrier in the unlock path of rwlock
    
    The rwlock unlock paths are using atomic_sub() to release the lock.
    However the implementation of atomic_sub() rightfully doesn't contain a
    memory barrier. On Arm, this means a processor is allowed to re-order
    the memory access with the preceeding access.
    
    In other words, the unlock may be seen by another processor before all
    the memory accesses within the "critical" section.
    
    The rwlock paths already contains barrier indirectly, but they are not
    very useful without the counterpart in the unlock paths.
    
    The memory barriers are not necessary on x86 because loads/stores are
    not re-ordered with lock instructions.
    
    So add arch_lock_release_barrier() in the unlock paths that will only
    add memory barrier on Arm.
    
    Take the opportunity to document each lock paths explaining why a
    barrier is not necessary.
    
    This is XSA-314.
    
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    master commit: 6890a04072e664c25447a297fe663b45ecfd6398
    master date: 2020-04-14 14:37:11 +0200

commit a91b8fc39e46c7b270c63882a1033b3c4faef5bf
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 14 15:10:48 2020 +0200

    xenoprof: limit consumption of shared buffer data
    
    Since a shared buffer can be written to by the guest, we may only read
    the head and tail pointers from there (all other fields should only ever
    be written to). Furthermore, for any particular operation the two values
    must be read exactly once, with both checks and consumption happening
    with the thus read values. (The backtrace related xenoprof_buf_space()
    use in xenoprof_log_event() is an exception: The values used there get
    re-checked by every subsequent xenoprof_add_sample().)
    
    Since that code needed touching, also fix the double increment of the
    lost samples count in case the backtrace related xenoprof_add_sample()
    invocation in xenoprof_log_event() fails.
    
    Where code is being touched anyway, add const as appropriate, but take
    the opportunity to entirely drop the now unused domain parameter of
    xenoprof_buf_space().
    
    This is part of XSA-313.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: George Dunlap <george.dunlap@citrix.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    master commit: 50ef9a3cb26e2f9383f6fdfbed361d8f174bae9f
    master date: 2020-04-14 14:33:19 +0200

commit 3e0c3163a0171914afb8d1fba44afafeac4b2267
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 14 15:08:26 2020 +0200

    xenoprof: clear buffer intended to be shared with guests
    
    alloc_xenheap_pages() making use of MEMF_no_scrub is fine for Xen
    internally used allocations, but buffers allocated to be shared with
    (unpriviliged) guests need to be zapped of their prior content.
    
    This is part of XSA-313.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    master commit: 0763a7ebfcdad66cf9e5475a1301eefb29bae9ed
    master date: 2020-04-14 14:32:33 +0200
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:47:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOiO4-0005Th-Ve; Wed, 15 Apr 2020 13:47:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOiO2-0005TZ-Vn
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:47:31 +0000
X-Inumbo-ID: a615e36c-7f1f-11ea-8a50-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a615e36c-7f1f-11ea-8a50-12813bfff9fa;
 Wed, 15 Apr 2020 13:47:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586958450;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=yUBYWgBvcCBEiFtZi4KYlWiNs/ExtQYAzVUtpY5TCXI=;
 b=Q2kGFkP8Zbn3VTerPB3rqraFulyDgjEUaH4ETJGR7fFuLozyEl9kwS71
 +/ge3EksgK8+DvBhC7WQI/fmqIW+mydsKHvcFF2N4LgsSQoANQoO8W8e5
 UKVs0Tn9bFF7rJfTyo7eroP+7A0UgXB5NAU3Hzp7+iUnieF4G1pnIgd8Y 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: peEHnSpgsP5lzsl00C1ScIXEZwpEd47Ov3D29kI8RK90Ex6aHkSs0+gYSFrh8E7oYrAFpg3XDa
 LNvsiFAWizHgiIGxMD8vdDdhrZgpW8kKS17eBo/mH7JCKToXjpwWbZY+OlmgwVV81ozsa3Pf0a
 tZKcQpLKihU7QlPy5UXlp17vFLwsPKo/oZORIEcnVEOa3gFcXwwoUm+Z8gP5xiyPUXDV+KhNaG
 k7SrTK8xYl2ORD0JEKuptWxRg/b0NRLla1cce8P8wJdfGO4StX3TSar0cfTCGS8ALFClVzgDJZ
 rsU=
X-SBRS: 2.7
X-MesageID: 15700282
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="15700282"
Date: Wed, 15 Apr 2020 15:47:22 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag
Message-ID: <20200415134722.GL28601@Air-de-Roger>
References: <20200415085246.7945-1-roger.pau@citrix.com>
 <24215.1635.613926.945930@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <24215.1635.613926.945930@mariner.uk.xensource.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 15, 2020 at 02:04:35PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag"):
> > Check if hosts have SMT based on the number of threads per core. A
> > value of threads per core different than 0 implies SMT support.
> ...
> > +logm("$ho->{Ident} threads per core: $threads");
> > +hostflag_putative_record($ho, "smt", !!$threads);
> 
> This code LGTM but I wonder if it would be a good idea to start
> namespacing these kind of hardware feature flags.  cpu-*, hardware-*,
> feature-* maybe ?  Would you care to make a suggestion ?

cpu-smt seems fine if we plan to do similar namespacing with other
hardware features, I could see cpu-{smt,vmx,svm} and
devices-{iommu,sriov,ats} or some such for example.

If OTOH we don't want to be that fine grained I think
hw-{smt,iommu,vmx,...} would also be fine.

Not sure whether this has helped much. I guess my vote would be for
cpu-smt namespace.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:50:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOiQv-0006Hs-Hn; Wed, 15 Apr 2020 13:50:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=RJH9=57=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jOiQu-0006Hl-N1
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:50:28 +0000
X-Inumbo-ID: 0f62f21a-7f20-11ea-8a50-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0f62f21a-7f20-11ea-8a50-12813bfff9fa;
 Wed, 15 Apr 2020 13:50:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586958628;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=DX7seWI444dQtUzzyfy+tFF7R0mmM0fIh4xow2/mPlI=;
 b=YcF9uqHZBWGhAOcoxXOnyS3SbPjFY/PhlDO59lfWlml0XxVf1DAbfie/
 3bqHLsfpiWADpv+IT4iVYVTZm6/YVxduzbFHesc5IlbC/HPEbakzhR9oX
 trqtJPaw8HNaYhRSI7Pcx0/aMcYod6D+0GonDuswDQJ4tqDixcM32FjI8 c=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 4zzX6FdRlQojD56QbBLrfDE/Kog+0ziTVlH3YpO3QF24KensuB8voPSJikOCPWFS/0nk5Li8En
 bhh5e+ged14KDpqXII8T659ZTBSnkApyXobCF6hW5rZpIuWFhktnoJ/yoSo0oCwXAVT4I3SaBU
 PKWY00nX/P1cL8Yt+O4zgWxdvgh+9Xz3kmrWs+MSJ5UuiEtLqATZsxh/epctz06FTzpqoLrLhU
 8N4aS+pTaPJkCq+VgZxANXrYrieiYyE39zkFdeAHnN4NyyRA5OsSuuf0O9shgksKu/ZBI9sYAg
 f8w=
X-SBRS: 2.7
X-MesageID: 15955713
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="15955713"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24215.4380.895524.768102@mariner.uk.xensource.com>
Date: Wed, 15 Apr 2020 14:50:20 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag
In-Reply-To: <20200415134722.GL28601@Air-de-Roger>
References: <20200415085246.7945-1-roger.pau@citrix.com>
 <24215.1635.613926.945930@mariner.uk.xensource.com>
 <20200415134722.GL28601@Air-de-Roger>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("Re: [PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag"):
> If OTOH we don't want to be that fine grained I think
> hw-{smt,iommu,vmx,...} would also be fine.
> 
> Not sure whether this has helped much. I guess my vote would be for
> cpu-smt namespace.

Let's go with hw-*.  That will avoid chopping logic over the precise
nature of hardware features, especially ones which have elements in
multiple components.

Thanks,
Ian.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:53:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:53:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOiU9-0006Qw-4W; Wed, 15 Apr 2020 13:53:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=zknx=57=bitdefender.com=aisaila@srs-us1.protection.inumbo.net>)
 id 1jOiU7-0006Qr-7A
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:53:47 +0000
X-Inumbo-ID: 867f6f86-7f20-11ea-9e09-bc764e2007e4
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown
 [2a01:111:f400:7e1a::730])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 867f6f86-7f20-11ea-9e09-bc764e2007e4;
 Wed, 15 Apr 2020 13:53:46 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=b0XloKhgyJoYarf3pKXfViHYCKrm6pcVE0QvsgFpnAgqArVWjgnZYVVuWwkG3HJ3i3BKBQUO1qdbhT7+6rtSzLgH8O5N93IBfR7zMpOYEO+dL+/jBhKyQd3kBxmXRpjh/hAVIc05rWSP8HXfcDE4m1rwdP7FRZH0OPPC3x4LJaJaPJvjVL1Nfed/7vVTAU7fNLNT3ShX/koVubgxXfmqbwlVYo6Y3SGKLon3JgMJj+8IoqDghfhsPLDdXnromMPAHqqLwYTXkgaj5Y2WjcURQpeke7QOu4X/NvGHM+E+zZR+q9MFFlcZwUdjGywXpVkMW1+zMLN9i57BZwMZoGsv5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4180LYiPiOhhVr+svEZcXnmuH9MBiizU+Mi/jYhOP74=;
 b=KuZTbROSOCA64djSqvEs3GMAgzzoYkFsb895+IHKOQT9Ns0k8hmjyCvhR0mrZycy2jKHrqTuULnZpLikYMIvHKClkLwAJFVCkZMD5kZA7es6Fuqf/XBaNCnIb8TBk67TcVs2m4N8k9jxLImCkKtFbXdPaPJeCSlgI0VfHrrn1mzYZPpTT5LCotcjiiii/SBWnjP3lCw1zsRwvMX+q92VpMs81jP8MP8VjQiVJP6t11luQn4cmpbqpCRRmQDuaABTKq1C9c5E0P12HNuudnpo96PHGzb/4XGewwftp7UuQRuEbXufEhIDsTUvBFPUTvbsWYBZ0ifzdfzVIhGhhIle3A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=bitdefender.com; dmarc=pass action=none
 header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4180LYiPiOhhVr+svEZcXnmuH9MBiizU+Mi/jYhOP74=;
 b=H4uOaUXN30iKSOoUvGM0mMbNJsKTvv1cazs2v1k6lKGq5DawUFA+Fa9R4FHQcCJrNkNg8mmwoBMZgm1/NhE6W2SIoFTkjUChqqp0gt5y+f2D+nVM4zG26k9hhdIB0jJsRHrV3TcZGuXkP/LrMNXLygLAJ7DjOmwhe/TS3HoSAd8=
Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=aisaila@bitdefender.com; 
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com (2603:10a6:20b:86::23)
 by AM6PR02MB5496.eurprd02.prod.outlook.com (2603:10a6:20b:ee::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.26; Wed, 15 Apr
 2020 13:53:44 +0000
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208]) by AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208%4]) with mapi id 15.20.2900.028; Wed, 15 Apr 2020
 13:53:44 +0000
From: Alexandru Isaila <aisaila@bitdefender.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH V1] Fix for Coverity ID: 1461759
Date: Wed, 15 Apr 2020 16:53:13 +0300
Message-Id: <20200415135313.12886-1-aisaila@bitdefender.com>
X-Mailer: git-send-email 2.17.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: VI1PR09CA0157.eurprd09.prod.outlook.com
 (2603:10a6:800:120::11) To AM6PR02MB5223.eurprd02.prod.outlook.com
 (2603:10a6:20b:86::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from aisaila-Latitude-E5570.dsd.bitdefender.biz (82.77.232.39) by
 VI1PR09CA0157.eurprd09.prod.outlook.com (2603:10a6:800:120::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend
 Transport; Wed, 15 Apr 2020 13:53:43 +0000
X-Mailer: git-send-email 2.17.1
X-Originating-IP: [82.77.232.39]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3a70daa8-9878-419f-2ccc-08d7e144695b
X-MS-TrafficTypeDiagnostic: AM6PR02MB5496:|AM6PR02MB5496:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <AM6PR02MB549612352EB90AB1171FC6A6ABDB0@AM6PR02MB5496.eurprd02.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:102;
X-Forefront-PRVS: 0374433C81
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:AM6PR02MB5223.eurprd02.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10019020)(346002)(376002)(136003)(39860400002)(396003)(366004)(8936002)(2906002)(66556008)(66476007)(66946007)(1076003)(86362001)(478600001)(52116002)(316002)(26005)(4326008)(8676002)(186003)(16526019)(5660300002)(6666004)(4744005)(81156014)(36756003)(6486002)(2616005)(956004)(6506007)(6512007)(6916009)(54906003);
 DIR:OUT; SFP:1102; 
Received-SPF: None (protection.outlook.com: bitdefender.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: /1xtp3QEfY3uAG6MwGkbfxBCngqN2nkiR5ObGaE9EM5CNoxnkE58cGAEdwjNf+A2i5OkKIzmEFpFVHLu4FPcsyYSokWtZJUQ9N/DxSuJ1fxgi9vae0vuRm78fdYOi/A+BJNTuOQipcEdzP0UFZB38PO8VWqMTAjFJUC4FJ01BhS5pak5gMkJeudpGRxI1hM2jE4hEx1VjiaYy0oBM2pk5Je/0n9yXZyp0c1fBDv1jeFonVAfl73yCoP1O5ONpLtyiHTCiryKrLwPSSETzxifa8DzPdjTA3UbPepGRAWtSZYCDrOxDPj+X7tO7QIidtvYqe4SHlgce43siZmtm7V4yEeTliDLHZ7yEkZNVc0bXfIaNHIP2FgbayYZmiOHTiMSljXqYQuABuOn8DHUomPFAoQe5jzgVfNIy3mxVRiZdhkGl59dA4wggVCJwhEKspJE
X-MS-Exchange-AntiSpam-MessageData: 38QS8tS6cMnqb72f5YysB9IVRCjs2l6Umc65OXWXBLFSzHhQw9cL4csZj6B9y++k7cwbtWIelYKehlLZXyYxcHXz/sMIxb1tUlpM9AbtlucNSlb/8PdhidyySfnKyepZAQU82rSOWyhB+r/YA2Dhhg==
X-OriginatorOrg: bitdefender.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a70daa8-9878-419f-2ccc-08d7e144695b
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2020 13:53:44.0151 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 6+GFwz0q2nq3uQnlACAMx/8gvPOWQq2VKHtvovAAbOZJpFcHwDTybe8t1mCYgzVsqt+ifSffKIS1T0kWafr7RElSB5H88wvr0/1TUfSLEGA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR02MB5496
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Alexandru Isaila <aisaila@bitdefender.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>

---
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Wei Liu <wl@xen.org>
CC: "Roger Pau Monné" <roger.pau@citrix.com>
---
 xen/arch/x86/hvm/hvm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6f6f3f73a8..45959d3412 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4798,6 +4798,7 @@ static int do_altp2m_op(
         else
             rc = p2m_set_altp2m_view_visibility(d, idx,
                                                 a.u.set_visibility.visible);
+        break;
     }
 
     default:
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 13:59:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 13:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOiZy-0006bZ-UF; Wed, 15 Apr 2020 13:59:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=j72F=57=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jOiZw-0006bU-UK
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:59:48 +0000
X-Inumbo-ID: 5e4c628e-7f21-11ea-8a50-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5e4c628e-7f21-11ea-8a50-12813bfff9fa;
 Wed, 15 Apr 2020 13:59:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=vCaqE+Z/abmDVe5i43oLfnAU1WnM9bycARrx9VcM/vY=; b=tmmkO4/Ny3jNWojm/LEC+aV738
 MzdiwbAIpIp0TNLcDfVXFVvp9uEE0D7feHH1aSYNev5ethttLr6cXV5pZDKkC7iGQuz4vVVrgaJU+
 l6KJc3lXbPWE/mCGutQj4bNt2o0ioliErntBGpN4j9T4r73xK5jtTVsf0UggH+k5MeWU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOiZu-0004RA-EY; Wed, 15 Apr 2020 13:59:46 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jOiZu-0000iM-59; Wed, 15 Apr 2020 13:59:46 +0000
Date: Wed, 15 Apr 2020 14:59:43 +0100
From: Wei Liu <wl@xen.org>
To: Alexandru Isaila <aisaila@bitdefender.com>
Subject: Re: [PATCH V1] Fix for Coverity ID: 1461759
Message-ID: <20200415135943.rx6tqgdmyflyxuqv@debian>
References: <20200415135313.12886-1-aisaila@bitdefender.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200415135313.12886-1-aisaila@bitdefender.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 15, 2020 at 04:53:13PM +0300, Alexandru Isaila wrote:
> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>

Thanks, but Roger already posted a fix for this.

Wei.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:00:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOiam-0007Ri-CV; Wed, 15 Apr 2020 14:00:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOial-0007RZ-8b
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:00:39 +0000
X-Inumbo-ID: 7c64a52e-7f21-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7c64a52e-7f21-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 14:00:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=qiKdXtRMDFwrY08zBd+4dbytpfkDLG+Wi08CN+Mtndk=; b=cxisyBYm6M470cbd6LgR+vDRSX
 4sFzpvUoVktAs9GzKG4S9SEK5txM57zg8lfTSYGKxmHeovbdMwJP9zsw79ABUaG1Aq53DkcI5Zi78
 q7FFN1iWNXsnAO5sEWJZDRnOVIvJPIviIrUNsR78eplEYJ8tbvfNOYZwKLP9x8o81a44=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiai-0004Xh-Oz; Wed, 15 Apr 2020 14:00:36 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiai-0000xA-Io; Wed, 15 Apr 2020 14:00:36 +0000
Subject: Re: [PATCH 08/12] xen/arm: if is_domain_direct_mapped use native
 addresses for GICv2
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-8-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <05375484-43f2-9d4b-205a-b9dcf4ee5d8e@xen.org>
Date: Wed, 15 Apr 2020 15:00:34 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-8-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 15/04/2020 02:02, Stefano Stabellini wrote:
> Today we use native addresses to map the GICv2 for Dom0 and fixed
> addresses for DomUs.
> 
> This patch changes the behavior so that native addresses are used for
> any domain that is_domain_direct_mapped.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> ---
>   xen/arch/arm/domain_build.c | 10 +++++++---
>   xen/arch/arm/vgic-v2.c      | 12 ++++++------
>   xen/arch/arm/vgic/vgic-v2.c |  2 +-
>   xen/include/asm-arm/vgic.h  |  1 +
>   4 files changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 627e0c5e8e..303bee60f6 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1643,8 +1643,12 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
>       int res = 0;
>       __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
>       __be32 *cells;
> +    struct domain *d = kinfo->d;
> +    char buf[38];
>   
> -    res = fdt_begin_node(fdt, "interrupt-controller@"__stringify(GUEST_GICD_BASE));
> +    snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIx64,
> +             d->arch.vgic.dbase);
> +    res = fdt_begin_node(fdt, buf);
>       if ( res )
>           return res;
>   
> @@ -1666,9 +1670,9 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
>   
>       cells = &reg[0];
>       dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
> -                       GUEST_GICD_BASE, GUEST_GICD_SIZE);
> +                       d->arch.vgic.dbase, GUEST_GICD_SIZE);
>       dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
> -                       GUEST_GICC_BASE, GUEST_GICC_SIZE);
> +                       d->arch.vgic.cbase, GUEST_GICC_SIZE);

You can't use the native base address and not the native size. 
Particularly, this is going to screw any GIC using 8KB alias.

It would be preferable if only expose part of the CPU interface as we do 
for the guest. So d->arch.vgic.cbase would be equal to vgic_v2_hw.dbase 
+ vgic_v2.hw.aliased_offset.


Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:04:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOie5-0007cJ-0h; Wed, 15 Apr 2020 14:04:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOie4-0007cD-0D
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:04:04 +0000
X-Inumbo-ID: f57bf7f2-7f21-11ea-8a52-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f57bf7f2-7f21-11ea-8a52-12813bfff9fa;
 Wed, 15 Apr 2020 14:04:02 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6211FAA7C;
 Wed, 15 Apr 2020 14:04:00 +0000 (UTC)
Subject: Re: [PATCH v3 1/4] x86/shim: map and unmap page tables in
 replace_va_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586951696.git.hongyxia@amazon.com>
 <37ad7487bc6e6f76e2082c0b42b4cf819007f513.1586951696.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <b5ef9470-cd30-5373-8367-b19d757c48e9@suse.com>
Date: Wed, 15 Apr 2020 16:03:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <37ad7487bc6e6f76e2082c0b42b4cf819007f513.1586951696.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 13:59, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Also, introduce lYe_from_lXe() macros which do not rely on the direct
> map when walking page tables. Unfortunately, they cannot be inline
> functions due to the header dependency on domain_page.h, so keep them as
> macros just like map_lYt_from_lXe().
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> 
> ---
> Changed in v3:
> - use unmap_domain_page() instead of the macro in several places.
> - also introduce l1e_from_l2e().
> - add _ prefix in macros to avoid aliasing.

Why prefixes, violating name space rules? In my reply to v2
requesting the adjustment I specifically said "suffixes".

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:07:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOih7-0007kt-JB; Wed, 15 Apr 2020 14:07:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOih5-0007kn-Tq
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:07:11 +0000
X-Inumbo-ID: 65c9b7ea-7f22-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 65c9b7ea-7f22-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 14:07:10 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DB41DAA7C;
 Wed, 15 Apr 2020 14:07:08 +0000 (UTC)
Subject: Re: [PATCH v3 4/4] x86_64/mm: map and unmap page tables in
 destroy_m2p_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586951696.git.hongyxia@amazon.com>
 <a38bb23216b30db902114dfe194d52889643ab08.1586951696.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <94f16a38-3571-2efd-bac1-60ef082d0dc3@suse.com>
Date: Wed, 15 Apr 2020 16:07:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a38bb23216b30db902114dfe194d52889643ab08.1586951696.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 13:59, Hongyan Xia wrote:
> @@ -285,26 +286,30 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
>              continue;
>          }
>  
> -        l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
> -        if (!(l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT))
> +        pl2e = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]) +
> +                    l2_table_offset(va);
> +        if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
>          {
>              i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
>                      (1UL << (L2_PAGETABLE_SHIFT - 3)) ;
> +            UNMAP_DOMAIN_PAGE(pl2e);
>              continue;
>          }
>  
> -        pt_pfn = l2e_get_pfn(l2_ro_mpt[l2_table_offset(va)]);
> +        pt_pfn = l2e_get_pfn(*pl2e);
>          if ( hotadd_mem_valid(pt_pfn, info) )
>          {
>              destroy_xen_mappings(rwva, rwva + (1UL << L2_PAGETABLE_SHIFT));
>  
> -            l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
> -            l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_empty());
> +            l2e_write(pl2e, l2e_empty());
>          }
>          i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
>                (1UL << (L2_PAGETABLE_SHIFT - 3));
> +        UNMAP_DOMAIN_PAGE(pl2e);

Along the lines of comments given elsewhere I would have expected
this one to change to the lower case version, as it again sits
right at the and of the scope of the variable.

>      }
>  
> +    UNMAP_DOMAIN_PAGE(l3_ro_mpt);

This, otoh, is still a few lines away from its end-of-scope, and
hence I can see why the variable clearing variant is being used.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:10:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:10:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOijn-0007sx-7n; Wed, 15 Apr 2020 14:09:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOijm-0007ss-D0
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:09:58 +0000
X-Inumbo-ID: c8bb9ef4-7f22-11ea-8a56-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c8bb9ef4-7f22-11ea-8a56-12813bfff9fa;
 Wed, 15 Apr 2020 14:09:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=TMG2quokWnBbiNMGentFiAHC/QrOcLhzsZN9l7VZNX4=; b=dHoMoEJ9CfCUmgFddBn2IusPrN
 j/cWBh/pNsMsoMLrWuIQXgBn+0OtifdvI2MsITPQVMzn6uMvQJcokAh6CbdjYK5OKDC9/FarcOhd7
 pjXa3hTv6H2SmR6jqe8zRVp4A2I1BpMJCjLvfg97BtJwTZlIU2+3CsKbOJmmU1aawfMc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiji-0004jE-NF; Wed, 15 Apr 2020 14:09:54 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOiji-0001ft-EM; Wed, 15 Apr 2020 14:09:54 +0000
Subject: Re: [PATCH 09/12] xen/arm: if is_domain_direct_mapped use native
 addresses for GICv3
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-9-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <923411c5-37d4-c86e-c5a8-8acd8a6830e7@xen.org>
Date: Wed, 15 Apr 2020 15:09:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-9-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 15/04/2020 02:02, Stefano Stabellini wrote:
> Today we use native addresses to map the GICv3 for Dom0 and fixed
> addresses for DomUs.
> 
> This patch changes the behavior so that native addresses are used for
> any domain that is_domain_direct_mapped. The patch has to introduce one
> #ifndef CONFIG_NEW_VGIC because the new vgic doesn't support GICv3.

Please no #ifdef. Instead move the creation of the DT node in vgic.c and 
introduce a stub for non-GICv3 platform.

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> ---
>   xen/arch/arm/domain_build.c | 12 +++++++++---
>   xen/arch/arm/vgic-v3.c      | 18 ++++++++++++++----
>   2 files changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 303bee60f6..beec0a144c 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1697,8 +1697,12 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
>       int res = 0;
>       __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
>       __be32 *cells;
> +    struct domain *d = kinfo->d;
> +    char buf[38];
>   
> -    res = fdt_begin_node(fdt, "interrupt-controller@"__stringify(GUEST_GICV3_GICD_BASE));
> +    snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIx64,
> +             d->arch.vgic.dbase);
> +    res = fdt_begin_node(fdt, buf);
>       if ( res )
>           return res;
>   
> @@ -1720,9 +1724,11 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
>   
>       cells = &reg[0];
>       dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
> -                       GUEST_GICV3_GICD_BASE, GUEST_GICV3_GICD_SIZE);
> +                       d->arch.vgic.dbase, GUEST_GICV3_GICD_SIZE);
> +#if defined(CONFIG_GICV3) && !defined(CONFIG_NEW_VGIC)

CONFIG_GICV3 does not exist. Did you mean CONFIG_HAS_GICV3?

>       dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
> -                       GUEST_GICV3_GICR0_BASE, GUEST_GICV3_GICR0_SIZE);
> +                       d->arch.vgic.rdist_regions[0].base, GUEST_GICV3_GICR0_SIZE);
> +#endif
>   
>       res = fdt_property(fdt, "reg", reg, sizeof(reg));
>       if (res)
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 4e60ba15cc..4cf430f865 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -1677,13 +1677,25 @@ static int vgic_v3_domain_init(struct domain *d)


I think you also want to modify vgic_v3_max_rdist_count().

>        * Domain 0 gets the hardware address.
>        * Guests get the virtual platform layout.

This comment needs to be updated.

>        */
> -    if ( is_hardware_domain(d) )
> +    if ( is_domain_direct_mapped(d) )
>       {
>           unsigned int first_cpu = 0;
> +        unsigned int nr_rdist_regions;
>   
>           d->arch.vgic.dbase = vgic_v3_hw.dbase;
>   
> -        for ( i = 0; i < vgic_v3_hw.nr_rdist_regions; i++ )
> +        if ( is_hardware_domain(d) )
> +        {
> +            nr_rdist_regions = vgic_v3_hw.nr_rdist_regions;
> +            d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
> +        }
> +        else
> +        {
> +            nr_rdist_regions = 1;

What does promise your the rdist region will be big enough to cater all 
the re-distributors for your domain?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:10:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:10:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOikP-0000Ca-JX; Wed, 15 Apr 2020 14:10:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOikO-0000CP-35
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:10:36 +0000
X-Inumbo-ID: dfe00890-7f22-11ea-83d8-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id dfe00890-7f22-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 14:10:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586959835;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=MCT9iaP9hqthD1TJioFT3LOvApm5sCvM4OiVAxcsBdg=;
 b=Fpet0uH6nscgqK9CPx2wg8TrVfWi9+3qr1iOiAn9vGnRnqEy5BA7XDbs
 PzGPVU6JE0M0dRiIc7f7wBOgtZPUmu5ZENYfrqBJZvRsEhoZKb2BO9/0w
 g4neEBvYzxdt8j+PjdEv3UPZ4/c41RIcqOBkqxkl+INSzvaxiurRqn9mU Y=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 3eXi28DNUq0OnBf5u457LPO/8hOfR6TZqOniFEe6ePFsY+cj/65VYIrGatTFqMNXUd/OxNc3xJ
 IHCxIl3GjCDUtIhOhqDX8s5qjz0Rvqp6Hw1TSleIT5EWvfeKvCVijLHTgRI0HDA1WDcy9tR2TL
 AX0qIrU9GvSioaS1Vv2TztXquGKYEaGCPzbX9IqhjAk7lcN+5yfZdGBhQq7QhN9JRmVPB5J7lj
 1m8X/EAyF6gIMSQyU1Ji3BQxGv16LmlEd7LQbCHRR5Ohmr0I+UjPnJpeBabRH9FQSXiKn745yn
 TdY=
X-SBRS: 2.7
X-MesageID: 16036222
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="16036222"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH OSSTEST v3 1/2] exanime: test for SMT and add a host flag
Date: Wed, 15 Apr 2020 16:10:08 +0200
Message-ID: <20200415141009.10912-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Check if hosts have SMT based on the number of threads per core. A
value of threads per core greater than 1 implies SMT support.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v2:
 - Use hw-smt.

Changes since v1:
 - Fix regex and set SMT if number of threads per core is > 1.
---
 sg-run-job     |  1 +
 ts-examine-cpu | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)
 create mode 100755 ts-examine-cpu

diff --git a/sg-run-job b/sg-run-job
index 97011843..aa7953ac 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -679,6 +679,7 @@ proc examine-host-examine {install} {
     if {$ok} {
 	run-ts -.  =           ts-examine-serial-post + host
 	run-ts .   =           ts-examine-iommu       + host
+	run-ts .   =           ts-examine-cpu         + host
 	run-ts .   =           ts-examine-logs-save   + host
 	run-ts .   =           ts-examine-hostprops-save
     }
diff --git a/ts-examine-cpu b/ts-examine-cpu
new file mode 100755
index 00000000..81cf7544
--- /dev/null
+++ b/ts-examine-cpu
@@ -0,0 +1,32 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2020 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# 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 Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+BEGIN { unshift @INC, qw(.); }
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+our $info = target_cmd_output_root($ho, 'xl info', 10);
+our $threads = $info =~ /^threads_per_core\s*:\s.*/m;
+
+logm("$ho->{Ident} threads per core: $threads");
+hostflag_putative_record($ho, "hw-smt", $threads > 1);
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:10:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOikR-0000DL-Tv; Wed, 15 Apr 2020 14:10:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOikP-0000Ch-W5
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:10:38 +0000
X-Inumbo-ID: e0be7daa-7f22-11ea-8a58-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e0be7daa-7f22-11ea-8a58-12813bfff9fa;
 Wed, 15 Apr 2020 14:10:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586959836;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=0E+K3lFSiHcbDUF4mBJQMunGkHuYRvoLndX2Kqbkwvk=;
 b=St6qT2gp1GYjcx/LcluA+//L+XtoizGsjpV7bYW9I29KYTB96MEDMzCY
 yGf3RLiocO4Xe0H6nJ9X2S30u1T64Gyso1L25Nu9fuPjTrpsRJLsx0kxG
 5ahRaBuZ8MaW3OpEVVLQztspXQF3z+QemhTuJ4S44BOfqj0XOZNIOnzze M=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: x3ypCWGmt2rRapt6wQ4shjlF4lc2DjEAxQ/Msb1KnsxKGyysirgQ23ZQd+cYiFq4oN6NTW9Mql
 GoquxqmpfL6rqrVypOPR7onrDAU0zTU9VBa9K2//jVCvD+DaDgwCushe1bYRBmklSpfmLF6SAd
 xfGfKSlr3k8nbfCML1Ee9W64xuw1B7a/+ZZz15OiAYOuKc2y1ZTJCDtYNd5mUDzQOztTmU/Wh7
 UanDKu9PsJ1uf0iGNlOUBMIn65Anz2mgVdOMDqSPJwbKTWxsGlcXRqawnOnp/CKmQTffqlpw9u
 8ic=
X-SBRS: 2.7
X-MesageID: 16120055
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="16120055"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH OSSTEST v3 2/2] make-flight: add a core scheduling job
Date: Wed, 15 Apr 2020 16:10:09 +0200
Message-ID: <20200415141009.10912-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200415141009.10912-1-roger.pau@citrix.com>
References: <20200415141009.10912-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Run a simple core scheduling tests on a host that has SMT support.
This is only enabled for Xen >= 4.13.

The runvar difference is:

+test-amd64-coresched-amd64-xl all_host_di_version 2020-02-10
+test-amd64-coresched-i386-xl  all_host_di_version 2020-02-10
+test-amd64-coresched-amd64-xl all_host_suite      stretch
+test-amd64-coresched-i386-xl  all_host_suite      stretch
+test-amd64-coresched-amd64-xl all_hostflags       arch-amd64,arch-xen-amd64,suite-stretch,purpose-test,smt
+test-amd64-coresched-i386-xl  all_hostflags       arch-i386,arch-xen-amd64,suite-stretch,purpose-test,smt
+test-amd64-coresched-amd64-xl arch                amd64
+test-amd64-coresched-i386-xl  arch                i386
+test-amd64-coresched-amd64-xl buildjob            build-amd64
+test-amd64-coresched-i386-xl  buildjob            build-i386
+test-amd64-coresched-amd64-xl debian_arch         amd64
+test-amd64-coresched-i386-xl  debian_arch         i386
+test-amd64-coresched-amd64-xl debian_kernkind     pvops
+test-amd64-coresched-i386-xl  debian_kernkind     pvops
+test-amd64-coresched-amd64-xl debian_suite        stretch
+test-amd64-coresched-i386-xl  debian_suite        stretch
+test-amd64-coresched-amd64-xl kernbuildjob        build-amd64-pvops
+test-amd64-coresched-i386-xl  kernbuildjob        build-i386-pvops
+test-amd64-coresched-amd64-xl kernkind            pvops
+test-amd64-coresched-i386-xl  kernkind            pvops
+test-amd64-coresched-amd64-xl toolstack           xl
+test-amd64-coresched-i386-xl  toolstack           xl
+test-amd64-coresched-amd64-xl xen_boot_append     sched-gran=core
+test-amd64-coresched-i386-xl  xen_boot_append     sched-gran=core
+test-amd64-coresched-amd64-xl xenbuildjob         build-amd64
+test-amd64-coresched-i386-xl  xenbuildjob         build-amd64

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v2:
 - Use hw-smt instead of smt as hostflag.
---
 make-flight | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/make-flight b/make-flight
index 2f445d95..a361bcb1 100755
--- a/make-flight
+++ b/make-flight
@@ -763,6 +763,17 @@ test_matrix_do_one () {
   *)                test_dom0pvh=n ;;
   esac
 
+  # core scheduling tests for versions >= 4.13 only
+  case "$xenbranch" in
+  xen-3.*-testing)  test_coresched=n ;;
+  xen-4.?-testing)  test_coresched=n ;;
+  xen-4.10-testing) test_coresched=n ;;
+  xen-4.11-testing) test_coresched=n ;;
+  xen-4.12-testing) test_coresched=n ;;
+  *)                test_coresched=y ;;
+  esac
+
+
   # xend PV guest test on x86 only
   if [ x$test_xend = xy -a \( $dom0arch = "i386" -o $dom0arch = "amd64" \) ]; then
     job_create_test test-$xenarch$kern-$dom0arch-pv test-debian xend \
@@ -894,6 +905,15 @@ test_matrix_do_one () {
 
   fi
 
+  # Core-scheduling tests are x86 only
+  if [ x$test_coresched = xy -a $xenarch = amd64 ]; then
+    job_create_test test-$xenarch$kern-coresched-$dom0arch-xl \
+                    test-debian xl $xenarch $dom0arch $debian_runvars \
+                    all_hostflags=$most_hostflags,hw-smt \
+                    xen_boot_append='sched-gran=core'
+
+  fi
+
   #do_passthrough_tests
 
   do_pygrub_tests
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:10:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOikf-0000GI-9f; Wed, 15 Apr 2020 14:10:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NCA0=57=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jOike-0000G9-Qa
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:10:52 +0000
X-Inumbo-ID: e9d1e788-7f22-11ea-b58d-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e9d1e788-7f22-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 14:10:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586959852;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=U+ELunXxu2T17jTs1dYsbxn04Pb6u8YpFuruJyTrt8U=;
 b=JGaPWqvCB648CzIYtGOXSMDHr7WBGA+CrqNQvml5SXuVcYERG8MDDcHx
 x9RxhsTyUX/aq1/bjGT8t3UnsG9Nyg/DvxKrXqONKbB4SUzYQkmtIkI6j
 Ht3yMHlteYdj5TmGNCKPIkUwA6JYY3qa6R6+HUoMEO+Svm/dpLJewfos0 U=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: +gOrhGCOHPGIv4rjaKsHQgMaEN5V5joxLzSa9KUZiEzcX0qM94671z/LagFOQfEeSKhypNY3bx
 VGckw5+yAZIKCyxDcqiu5EZsxmNapT/F/+knpRkGTO6cOxUgjSl7JTRaThFOM0wuG0GbONurf9
 9qjBEo/COqI4ua545lzUR6SKYP1INGgXDtvr0xs/cMW0IqiP3DLjZ87X5mECvoOoMmE4Xa5ED2
 pdKTdiTGl1HBgrjH7QRyH/Ka3kq7D5ALJK+M9O4Wx6L1P8F6so6xqg6A65EVihYt/BEUI3fO6m
 mkI=
X-SBRS: 2.7
X-MesageID: 16120068
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="16120068"
Date: Wed, 15 Apr 2020 15:10:45 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 06/18] xen/build: have the root Makefile generates
 the CFLAGS
Message-ID: <20200415141045.GB4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-7-anthony.perard@citrix.com>
 <a2b16a74-4eed-eeae-d791-fa9fd4e63d08@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <a2b16a74-4eed-eeae-d791-fa9fd4e63d08@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 01:50:33PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
> >  # Always build obj-bin files as binary even if they come from C source. 
> > -$(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
> > +# FIXME LTO broken, but we would need a different way to filter -flto out
> > +# $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
> 
> While you mention this in the description, I'm still not overly
> happy with it getting commented out. What's wrong with making the
> construct simply act on c_flags?

It doesn't work.

I tried
    $(obj-bin-y): c_flags := $(filter-out -flto,$(c_flags))
but the $@ expansion was empty.

I guess we could do:
    $(obj-bin-y): XEN_CFLAGS := $(filter-out -flto,$(XEN_CFLAGS))
that's probably enough for now. Even if we can't test it properly.

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:11:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:11:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOil5-0000MM-Lr; Wed, 15 Apr 2020 14:11:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=zknx=57=bitdefender.com=aisaila@srs-us1.protection.inumbo.net>)
 id 1jOil4-0000M3-FE
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:11:18 +0000
X-Inumbo-ID: f8ed8358-7f22-11ea-b58d-bc764e2007e4
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (unknown
 [2a01:111:f400:fe08::726])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f8ed8358-7f22-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 14:11:17 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Zci6DVyspmqoQQFOykH09HqpiShFzkQlmWf9G59VB+Mkiv4o4EECjsanCR6bzf+3mckqpjDGZCVfXMVFFlaAFKRjalBeU+BvghRr9e5pIcWxpVST669iaZr77DaDyi5/E9ZSFSz8MaEl1eFn4OmW8D2tzYZT0Klk6SeOKlkUX/Y3mh8WTHOAJhLHjN/SaxHhmR/636nIA5hm3kInTHYMfDNZ5klf2j0WiePl7dTGkBT6HV3umqqAc8Wodm0hH1FSZI78zKzMut5VMeCflH4Y5Ubg4KDn2G7b8Ujjg77WlHDYJ2JHecipDOsMV1Plo6C/hO1wmOLHw2yHRQXAAtIAiQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Lne7SihlhgpgTF9QM1IwW3SHzsZpnjI92w/BGjtPjX0=;
 b=ZNVNO/Eyh3ZFgrv03MoAABcEDHgzW0XFBuQH9dmUIIzfai3/7jAiQD670AlGwuE7luqn+ZEVzxbUCPCBbl8mSCtOwLThMCyapaygarZVvPDj86p9ATqz3e98HX/26ym7k9vtSehz+bF7EtoDfPwXcuBHWdBUvuePQZZOF1J12rI1yoJQcziue2FbhU1ron2xnGhWesaSYnC25u6/g3F/8sErw4Xypyvq7grmeFsxhy/eO1vdq/k/XR8Uw0tG/3nfBoaEnDDzIfJpYknxcVhJgeFck93AOVMDHjeOzkN7dZJ6zJw5nucInBDEWH/F0zn71sISaRhTrGE3+FRRFFsacQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=bitdefender.com; dmarc=pass action=none
 header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Lne7SihlhgpgTF9QM1IwW3SHzsZpnjI92w/BGjtPjX0=;
 b=u8mMdqnkMxU/ggeNlhpK10Kg4qvI0O3AKC+AijSSyNjfmk7ncJhsdXerieZyZ2UhttlUF62nkbBlDKVsBu9/Wsufy+39zuZ8yYxzCZkLUTen0pxfQeLk1ZdYfpkKF71pt/WnT0NkOXlX9GKemDQ3jMQcBuEy8HpPOZIZf7bmZAg=
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com (2603:10a6:20b:86::23)
 by AM6PR02MB4930.eurprd02.prod.outlook.com (2603:10a6:20b:34::27)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Wed, 15 Apr
 2020 14:11:15 +0000
Received: from AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208]) by AM6PR02MB5223.eurprd02.prod.outlook.com
 ([fe80::b189:1c2:ea70:d208%4]) with mapi id 15.20.2900.028; Wed, 15 Apr 2020
 14:11:15 +0000
From: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
To: Wei Liu <wl@xen.org>
Subject: Re: [PATCH V1] Fix for Coverity ID: 1461759
Thread-Topic: [PATCH V1] Fix for Coverity ID: 1461759
Thread-Index: AQHWEy1HfbxtRzn/mUapOUDkpksJAqh6Nd+AgAAC1Zw=
Date: Wed, 15 Apr 2020 14:11:15 +0000
Message-ID: <AM6PR02MB52234AD1FCEF514332BA8D28ABDB0@AM6PR02MB5223.eurprd02.prod.outlook.com>
References: <20200415135313.12886-1-aisaila@bitdefender.com>,
 <20200415135943.rx6tqgdmyflyxuqv@debian>
In-Reply-To: <20200415135943.rx6tqgdmyflyxuqv@debian>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=aisaila@bitdefender.com; 
x-originating-ip: [82.77.232.39]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 859b6298-7a6b-43e0-38d6-08d7e146dc57
x-ms-traffictypediagnostic: AM6PR02MB4930:|AM6PR02MB4930:
x-microsoft-antispam-prvs: <AM6PR02MB4930C611FED709D667BCE7A0ABDB0@AM6PR02MB4930.eurprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:AM6PR02MB5223.eurprd02.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10019020)(346002)(366004)(39860400002)(376002)(136003)(396003)(478600001)(66556008)(66476007)(76116006)(91956017)(64756008)(66446008)(86362001)(66946007)(52536014)(7696005)(26005)(71200400001)(53546011)(33656002)(4326008)(8936002)(55016002)(54906003)(316002)(19627405001)(4744005)(5660300002)(6916009)(6506007)(186003)(8676002)(81156014)(9686003)(2906002);
 DIR:OUT; SFP:1102; 
received-spf: None (protection.outlook.com: bitdefender.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: t9URQFGJLGVFhT94skQGw22wwyjysQ3OLZiHaaqeN1PXJXLaskufvExcKVUBVmrquHuQBXY/0DIGe1aOINwo7xS3BCgW9GFHsWMwe1DGi9Y6kAbsu17/JX+3G/BAKIjpvIuixN88ZAG1S0cVi5J2XO3v5aoq75j6wD1MutplxJjrMAMZI6xRO1YoEHTHLPlwrqoiVC/XaI0fA5bLEaDINYC9fS8eMj+8YiLifsHDzzFur5PKHRHSHDA8JQPRjIafUtRztWgkbGJ3IeFyMGGifb8aqiEbWXkD9bGkI9VG+3t7IQRgKIblruJKKYdzH5CGPE5HhG84oSgeok2ySzDnv8FZv2JxKbPv4EAnKGpwQzFoKx/ExXjE1d5xV3xuGTYF+rzdc5Lr6Mr0VeVV9/YF4njQuluuxM+KO664vO5tU67bjMfNsHsDFmLDTMq85Jz9
x-ms-exchange-antispam-messagedata: IW4zWp+IZXWaQlsGvtnnDcS4YGNE5ggLb5TFi/satjw0ObUWQdQBP12OxU4i0PiXBiUUK8aVI8ttnpjXwjm06nJCSIKrntiJFaY4uOi+ClZs+9MQDpevmZYsTSdB8s017qk5v7F4zcqJvnIbwU83gA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
 boundary="_000_AM6PR02MB52234AD1FCEF514332BA8D28ABDB0AM6PR02MB5223eurp_"
MIME-Version: 1.0
X-OriginatorOrg: bitdefender.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 859b6298-7a6b-43e0-38d6-08d7e146dc57
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 14:11:15.5849 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 487baf29-f1da-469a-9221-243f830c36f3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jvZXxictfMVOgMgnWq/iOeANHl1RuYuXQZP7blMMiRVyveNbIjODd462H0nmzWX2pVAvDdaRP2nlUoRIFB8jLrQGbTG4mSeIG0eFYOpL7Pg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR02MB4930
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--_000_AM6PR02MB52234AD1FCEF514332BA8D28ABDB0AM6PR02MB5223eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


________________________________
From: Xen-devel <xen-devel-bounces@lists.xenproject.org> on behalf of Wei L=
iu <wl@xen.org>
Sent: Wednesday, April 15, 2020 4:59 PM
To: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
Cc: xen-devel@lists.xenproject.org <xen-devel@lists.xenproject.org>; Roger =
Pau Monn=E9 <roger.pau@citrix.com>; Wei Liu <wl@xen.org>; Jan Beulich <jbeu=
lich@suse.com>; Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH V1] Fix for Coverity ID: 1461759

On Wed, Apr 15, 2020 at 04:53:13PM +0300, Alexandru Isaila wrote:
> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>

Thanks, but Roger already posted a fix for this.

Sorry about the late reaction to this, I did no check my email.

Alex

--_000_AM6PR02MB52234AD1FCEF514332BA8D28ABDB0AM6PR02MB5223eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div id=3D"appendonsend" style=3D"font-family: Calibri, Arial, Helvetica, s=
ans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
</div>
<div style=3D"font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12p=
t; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Xen-devel &lt;xen-dev=
el-bounces@lists.xenproject.org&gt; on behalf of Wei Liu &lt;wl@xen.org&gt;=
<br>
<b>Sent:</b> Wednesday, April 15, 2020 4:59 PM<br>
<b>To:</b> Alexandru Stefan ISAILA &lt;aisaila@bitdefender.com&gt;<br>
<b>Cc:</b> xen-devel@lists.xenproject.org &lt;xen-devel@lists.xenproject.or=
g&gt;; Roger Pau Monn=E9 &lt;roger.pau@citrix.com&gt;; Wei Liu &lt;wl@xen.o=
rg&gt;; Jan Beulich &lt;jbeulich@suse.com&gt;; Andrew Cooper &lt;andrew.coo=
per3@citrix.com&gt;<br>
<b>Subject:</b> Re: [PATCH V1] Fix for Coverity ID: 1461759</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"=
>
<div class=3D"PlainText">On Wed, Apr 15, 2020 at 04:53:13PM &#43;0300, Alex=
andru Isaila wrote:<br>
&gt; Signed-off-by: Alexandru Isaila &lt;aisaila@bitdefender.com&gt;<br>
<br>
Thanks, but Roger already posted a fix for this.<br>
<br>
Sorry about the late reaction to this, I did no check my email.</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">Alex</div>
</span></font></div>
</body>
</html>

--_000_AM6PR02MB52234AD1FCEF514332BA8D28ABDB0AM6PR02MB5223eurp_--


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:11:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:11:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOilW-0000T8-6k; Wed, 15 Apr 2020 14:11:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOilU-0000Sp-M9
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:11:44 +0000
X-Inumbo-ID: 08f7c1be-7f23-11ea-8a58-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 08f7c1be-7f23-11ea-8a58-12813bfff9fa;
 Wed, 15 Apr 2020 14:11:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=msT6aM2AJ1K6oxv676k39If/2dJKOISIwujnmLA2iCE=; b=At9en+Ra03XHJWhwgHDwc0YlxC
 w/5c70mFXfsUtL4zsCpJwIdKc8a1osaDFY6qL7kv8+pwDb92FcqHiDZLYXS73+WAtfsuBhHWolHpL
 vNNmQn6AvYVEo8k2yMNmOLSi7ZUb+OIpmcX6M+Po26FfV8G3j23AVdFfFytjkdDDoYw8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOilR-0004lM-Oj; Wed, 15 Apr 2020 14:11:41 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOilR-0001wG-IJ; Wed, 15 Apr 2020 14:11:41 +0000
Subject: Re: [PATCH 10/12] xen/arm: if is_domain_direct_mapped use native UART
 address for vPL011
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-10-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <05b46414-12c3-5f79-f4b1-46cf8750d28c@xen.org>
Date: Wed, 15 Apr 2020 15:11:40 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-10-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Stefano,

On 15/04/2020 02:02, Stefano Stabellini wrote:
> We always use a fix address to map the vPL011 to domains. The address
> could be a problem for domains that are directly mapped.
> 
> Instead, for domains that are directly mapped, reuse the address of the
> physical UART on the platform to avoid potential clashes.

How do you know the physical UART MMIO region is big enough to fit the 
PL011?

What if the user want to assign the physical UART to the domain + the 
vpl011?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:12:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:12:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOimX-0000d8-Li; Wed, 15 Apr 2020 14:12:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOimW-0000cw-AK
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:12:48 +0000
X-Inumbo-ID: 2f0bd2b4-7f23-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2f0bd2b4-7f23-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 14:12:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=peyQC07JX4ABFAGVP5KwZL5UpS1XrimcPxQD1V1d9C8=; b=xRuBAIKC7nR4bQhMsZrf6RHDSF
 Pe9BL1pa0AdHMm/bbZgTJ5xqF42xv62fiIZ1TKOEEF6NaG/XQ3/QlZSMGdH8W6kb/wCGwWLtbWF9C
 h/rVbcA2s2DbTU0UCy/T6KoIPGvCBmHTcWZxeK3OYXcpB3Z4740COu6pm10J1QfaiXz0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOimU-0004nU-Gn; Wed, 15 Apr 2020 14:12:46 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOimU-0001zg-Af; Wed, 15 Apr 2020 14:12:46 +0000
Subject: Re: [PATCH 11/12] xen/arm: if xen_force don't try to setup the IOMMU
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-11-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <4b4263ba-bf6f-e578-037d-edb8add52aad@xen.org>
Date: Wed, 15 Apr 2020 15:12:44 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-11-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Stefano,

On 15/04/2020 02:02, Stefano Stabellini wrote:
> If xen_force (which means xen,force-assign-without-iommu was requested)
> don't try to add the device to the IOMMU. Return early instead.


Could you explain why this is an issue to call xen_force after 
iommu_add_dt_device()?

Cheers,
-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:14:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOio0-0000oa-2x; Wed, 15 Apr 2020 14:14:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOinz-0000oQ-BE
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:14:19 +0000
X-Inumbo-ID: 64fcb74e-7f23-11ea-8a58-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 64fcb74e-7f23-11ea-8a58-12813bfff9fa;
 Wed, 15 Apr 2020 14:14:18 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DCE3AAA7C;
 Wed, 15 Apr 2020 14:14:16 +0000 (UTC)
Subject: Re: [XEN PATCH v5] hvmloader: Enable MMIO and I/O decode, after all
 resource allocation
To: Harsha Shamsundara Havanur <havanur@amazon.com>
References: <9cfd038719fee7fcb01b8967ffcb23802bb75a0b.1586953651.git.havanur@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <cf008c26-3c06-9b1a-d022-3d0c16867c28@suse.com>
Date: Wed, 15 Apr 2020 16:14:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9cfd038719fee7fcb01b8967ffcb23802bb75a0b.1586953651.git.havanur@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 14:27, Harsha Shamsundara Havanur wrote:
> It was observed that PCI MMIO and/or IO BARs were programmed with
> memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
> during PCI setup phase. This resulted in incorrect memory mapping as
> soon as the lower half of the 64 bit bar is programmed.
> This displaced any RAM mappings under 4G. After the
> upper half is programmed PCI memory mapping is restored to its
> intended high mem location, but the RAM displaced is not restored.
> The OS then continues to boot and function until it tries to access
> the displaced RAM at which point it suffers a page fault and crashes.
> 
> This patch address the issue by deferring enablement of memory and
> I/O decode in command register until all the resources, like interrupts
> I/O and/or MMIO BARs for all the PCI device functions are programmed,
> in the descending order of memory requested.
> 
> Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
with one further adjustment:

> @@ -120,6 +121,13 @@ void pci_setup(void)
>       */
>      bool allow_memory_relocate = 1;
>  
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
> +            PCI_COMMAND_IO);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY !=
> +            PCI_COMMAND_MEMORY);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MASTER !=
> +            PCI_COMMAND_MASTER);

Indentation here still looks wrong, despite me having given you
the precise form to use in reply to v4. This can be taken care
of while committing (if no other need for a v6 arises), but it
would have been nice if you had done this as indicated.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:18:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOirv-00010G-O1; Wed, 15 Apr 2020 14:18:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=HSXo=57=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOiru-00010B-0Z
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:18:22 +0000
X-Inumbo-ID: f5d45e2a-7f23-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f5d45e2a-7f23-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 14:18:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=R9nOKVo3DKo4xWiJH5aWCXcvOmoq9BN8nzsaODFlZs0=; b=25TFLSrm/peNp/+0//h2Nd1IEi
 FRznsuN373RH72WUvWAq8JD2CsNgYoR/K+wi/XnBRRz/VBeSaUKvLD/GDjidYrR8X8SnMSPmGsvC3
 zCzxrquPFpDissdJ5HS8s6YtaUGaed/KP1/EgIYP/3+E/Fwf08UDNC1Qa/wlJfDMcujc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOirr-0004vc-EU; Wed, 15 Apr 2020 14:18:19 +0000
Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOirr-0002J5-7s; Wed, 15 Apr 2020 14:18:19 +0000
Subject: Re: [PATCH 12/12] xen/arm: call iomem_permit_access for passthrough
 devices
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-12-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <521c8e55-73e8-950f-2d94-70b0c664bd3d@xen.org>
Date: Wed, 15 Apr 2020 15:18:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-12-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 15/04/2020 02:02, Stefano Stabellini wrote:
> iomem_permit_access should be called for MMIO regions of devices
> assigned to a domain. Currently it is not called for MMIO regions of
> passthrough devices of Dom0less guests. This patch fixes it.

You can already have cases today where the MMIO regions are mapped to 
the guest but the guest doesn't have permission on them.

Can you explain why this is a problem here?

Cheers,

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> ---
>   xen/arch/arm/domain_build.c | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d0fc497d07..d3d42eef5d 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1846,6 +1846,17 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>               return -EINVAL;
>           }
>   
> +        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
> +                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
> +        if ( res )
> +        {
> +            printk(XENLOG_ERR "Unable to permit to dom%d access to"
> +                   " 0x%"PRIx64" - 0x%"PRIx64"\n",
> +                   kinfo->d->domain_id,
> +                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
> +            return res;
> +        }
> +
>           res = map_regions_p2mt(kinfo->d,
>                                  gaddr_to_gfn(gstart),
>                                  PFN_DOWN(size),
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:22:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOivm-0001qx-CE; Wed, 15 Apr 2020 14:22:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=lpyF=57=amazon.com=prvs=367615363=havanur@srs-us1.protection.inumbo.net>)
 id 1jOivk-0001qs-WA
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:22:21 +0000
X-Inumbo-ID: 83be899b-7f24-11ea-8a5c-12813bfff9fa
Received: from smtp-fw-9101.amazon.com (unknown [207.171.184.25])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id 83be899b-7f24-11ea-8a5c-12813bfff9fa;
 Wed, 15 Apr 2020 14:22:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1586960540; x=1618496540;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:content-transfer-encoding:mime-version:subject;
 bh=eeYZuoza8P0iNDel/xcZiCwNUBiCPwD7KD2PGWECSfc=;
 b=bppxzyjZ4/D9thRc1aJg0M/+LN6/+zPRrNUod2hyO/Ps3cQvIc3zqCFH
 kem6YrEy/E43L2H5ulOw+cmD1d9swZep6tHtciSlJioTssUkHE5c7S2qs
 uhbjKg2u5cyiprfSfXAKQ5Sqc1odfimxJXZOgJ1ygl6S3b0r3DtR2HSGX 8=;
IronPort-SDR: 9pF5KKiMLoheQ0kg/OBKUgGZFWqqtC9x/50i7rlxWk79zpvyzsKgI/PxZo3AukisaaD3byvWih
 N0hhzVKxkj+w==
X-IronPort-AV: E=Sophos;i="5.72,387,1580774400"; d="scan'208";a="28869729"
Subject: Re: [XEN PATCH v5] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Thread-Topic: [XEN PATCH v5] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2c-168cbb73.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP;
 15 Apr 2020 14:22:18 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2c-168cbb73.us-west-2.amazon.com (Postfix) with ESMTPS
 id 2C50AA2312; Wed, 15 Apr 2020 14:22:17 +0000 (UTC)
Received: from EX13D36EUC004.ant.amazon.com (10.43.164.126) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Wed, 15 Apr 2020 14:22:16 +0000
Received: from EX13D36EUC004.ant.amazon.com (10.43.164.126) by
 EX13D36EUC004.ant.amazon.com (10.43.164.126) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Wed, 15 Apr 2020 14:22:15 +0000
Received: from EX13D36EUC004.ant.amazon.com ([10.43.164.126]) by
 EX13D36EUC004.ant.amazon.com ([10.43.164.126]) with mapi id 15.00.1497.006;
 Wed, 15 Apr 2020 14:22:15 +0000
From: "Shamsundara Havanur, Harsha" <havanur@amazon.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Thread-Index: AQHWEyE/rXUMoux450mf7FVULomDj6h6OgUAgAACPoA=
Date: Wed, 15 Apr 2020 14:22:15 +0000
Message-ID: <7e5e3d73c8b9541aea94d884754d0fa00f86a299.camel@amazon.com>
References: <9cfd038719fee7fcb01b8967ffcb23802bb75a0b.1586953651.git.havanur@amazon.com>
 <cf008c26-3c06-9b1a-d022-3d0c16867c28@suse.com>
In-Reply-To: <cf008c26-3c06-9b1a-d022-3d0c16867c28@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.164.25]
Content-Type: text/plain; charset="utf-8"
Content-ID: <ED6E235FAD28BE49B648E46BC966BCC5@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
 "wl@xen.org" <wl@xen.org>, "roger.pau@citrix.com" <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

T24gV2VkLCAyMDIwLTA0LTE1IGF0IDE2OjE0ICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4g
Q0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p
emF0aW9uLiBEbw0KPiBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3Mg
eW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXINCj4gYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2Fm
ZS4NCj4gDQo+IA0KPiANCj4gT24gMTUuMDQuMjAyMCAxNDoyNywgSGFyc2hhIFNoYW1zdW5kYXJh
IEhhdmFudXIgd3JvdGU6DQo+ID4gSXQgd2FzIG9ic2VydmVkIHRoYXQgUENJIE1NSU8gYW5kL29y
IElPIEJBUnMgd2VyZSBwcm9ncmFtbWVkIHdpdGgNCj4gPiBtZW1vcnkgYW5kIEkvTyBkZWNvZGVz
IChiaXRzIDAgYW5kIDEgb2YgUENJIENPTU1BTkQgcmVnaXN0ZXIpDQo+ID4gZW5hYmxlZCwNCj4g
PiBkdXJpbmcgUENJIHNldHVwIHBoYXNlLiBUaGlzIHJlc3VsdGVkIGluIGluY29ycmVjdCBtZW1v
cnkgbWFwcGluZw0KPiA+IGFzDQo+ID4gc29vbiBhcyB0aGUgbG93ZXIgaGFsZiBvZiB0aGUgNjQg
Yml0IGJhciBpcyBwcm9ncmFtbWVkLg0KPiA+IFRoaXMgZGlzcGxhY2VkIGFueSBSQU0gbWFwcGlu
Z3MgdW5kZXIgNEcuIEFmdGVyIHRoZQ0KPiA+IHVwcGVyIGhhbGYgaXMgcHJvZ3JhbW1lZCBQQ0kg
bWVtb3J5IG1hcHBpbmcgaXMgcmVzdG9yZWQgdG8gaXRzDQo+ID4gaW50ZW5kZWQgaGlnaCBtZW0g
bG9jYXRpb24sIGJ1dCB0aGUgUkFNIGRpc3BsYWNlZCBpcyBub3QgcmVzdG9yZWQuDQo+ID4gVGhl
IE9TIHRoZW4gY29udGludWVzIHRvIGJvb3QgYW5kIGZ1bmN0aW9uIHVudGlsIGl0IHRyaWVzIHRv
IGFjY2Vzcw0KPiA+IHRoZSBkaXNwbGFjZWQgUkFNIGF0IHdoaWNoIHBvaW50IGl0IHN1ZmZlcnMg
YSBwYWdlIGZhdWx0IGFuZA0KPiA+IGNyYXNoZXMuDQo+ID4gDQo+ID4gVGhpcyBwYXRjaCBhZGRy
ZXNzIHRoZSBpc3N1ZSBieSBkZWZlcnJpbmcgZW5hYmxlbWVudCBvZiBtZW1vcnkgYW5kDQo+ID4g
SS9PIGRlY29kZSBpbiBjb21tYW5kIHJlZ2lzdGVyIHVudGlsIGFsbCB0aGUgcmVzb3VyY2VzLCBs
aWtlDQo+ID4gaW50ZXJydXB0cw0KPiA+IEkvTyBhbmQvb3IgTU1JTyBCQVJzIGZvciBhbGwgdGhl
IFBDSSBkZXZpY2UgZnVuY3Rpb25zIGFyZQ0KPiA+IHByb2dyYW1tZWQsDQo+ID4gaW4gdGhlIGRl
c2NlbmRpbmcgb3JkZXIgb2YgbWVtb3J5IHJlcXVlc3RlZC4NCj4gPiANCj4gPiBTaWduZWQtb2Zm
LWJ5OiBIYXJzaGEgU2hhbXN1bmRhcmEgSGF2YW51ciA8aGF2YW51ckBhbWF6b24uY29tPg0KPiAN
Cj4gUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gd2l0aCBv
bmUgZnVydGhlciBhZGp1c3RtZW50Og0KPiANCj4gPiBAQCAtMTIwLDYgKzEyMSwxMyBAQCB2b2lk
IHBjaV9zZXR1cCh2b2lkKQ0KPiA+ICAgICAgICovDQo+ID4gICAgICBib29sIGFsbG93X21lbW9y
eV9yZWxvY2F0ZSA9IDE7DQo+ID4gDQo+ID4gKyAgICBCVUlMRF9CVUdfT04oKHR5cGVvZigqcGNp
X2RldmZuX2RlY29kZV90eXBlKSlQQ0lfQ09NTUFORF9JTyAhPQ0KPiA+ICsgICAgICAgICAgICBQ
Q0lfQ09NTUFORF9JTyk7DQo+ID4gKyAgICBCVUlMRF9CVUdfT04oKHR5cGVvZigqcGNpX2RldmZu
X2RlY29kZV90eXBlKSlQQ0lfQ09NTUFORF9NRU1PUg0KPiA+IFkgIT0NCj4gPiArICAgICAgICAg
ICAgUENJX0NPTU1BTkRfTUVNT1JZKTsNCj4gPiArICAgIEJVSUxEX0JVR19PTigodHlwZW9mKCpw
Y2lfZGV2Zm5fZGVjb2RlX3R5cGUpKVBDSV9DT01NQU5EX01BU1RFDQo+ID4gUiAhPQ0KPiA+ICsg
ICAgICAgICAgICBQQ0lfQ09NTUFORF9NQVNURVIpOw0KPiANCj4gSW5kZW50YXRpb24gaGVyZSBz
dGlsbCBsb29rcyB3cm9uZywgZGVzcGl0ZSBtZSBoYXZpbmcgZ2l2ZW4geW91DQo+IHRoZSBwcmVj
aXNlIGZvcm0gdG8gdXNlIGluIHJlcGx5IHRvIHY0LiBUaGlzIGNhbiBiZSB0YWtlbiBjYXJlDQo+
IG9mIHdoaWxlIGNvbW1pdHRpbmcgKGlmIG5vIG90aGVyIG5lZWQgZm9yIGEgdjYgYXJpc2VzKSwg
YnV0IGl0DQo+IHdvdWxkIGhhdmUgYmVlbiBuaWNlIGlmIHlvdSBoYWQgZG9uZSB0aGlzIGFzIGlu
ZGljYXRlZC4NCj4gDQpUaGlzIGlzIGR1ZSB0byBteSB2aW1yYyBjb25maWd1cmF0aW9uLiBJIHdp
bGwgZml4IHRoaXMgd2hpbGUgY29taXR0aW5nDQp0byBhbGlnbiBzZWNvbmQgbGluZSB0byBiZWdp
biB3aXRoIHR5cGVvZg0KDQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:27:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOj0k-00020w-2V; Wed, 15 Apr 2020 14:27:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=tllG=57=eikelenboom.it=linux@srs-us1.protection.inumbo.net>)
 id 1jOj0i-00020r-Ci
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:27:28 +0000
X-Inumbo-ID: 39c046c0-7f25-11ea-b58d-bc764e2007e4
Received: from server.eikelenboom.it (unknown [91.121.65.215])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 39c046c0-7f25-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 14:27:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=eikelenboom.it; s=20180706; h=Content-Transfer-Encoding:Content-Type:
 In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender
 :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:
 Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:
 List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Rt4s8oCvagp1tw9q1/hSGsMdGjZ24IF156aFzu1RJ44=; b=AHKCeZ5MbXUijbcpGdM8g+mv+V
 bd/vS0hrrgyq49N9j4b8675cVhMTLmAyH5esun3wsUs17+tP9OJXY4NAUT86fEauYJuGMghnqeYr1
 RFqBRJiBugzfp/WLrBUNVG+/pOwyFJA7g3srpvgVJ/TayN4EdtA/GwUvv7P6MVIaLI5s=;
Received: from [77.168.80.73] (port=40166 helo=[172.16.1.40])
 by server.eikelenboom.it with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from <linux@eikelenboom.it>)
 id 1jOj2d-0003DS-5q; Wed, 15 Apr 2020 16:29:27 +0200
Subject: Re: preparations for 4.13.1 and 4.12.3
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
From: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <322d98a5-e8e2-d4a5-8a95-b8033cd9f3fd@eikelenboom.it>
Date: Wed, 15 Apr 2020 16:27:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <f8ecb6b1-00de-67c1-07c6-6fdb92dd63ae@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Anthony Perard <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 09/04/2020 09:41, Jan Beulich wrote:
> All,
> 
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)
> 
> Jan

I would like to suggest for 4.13.1:

4b5b431edd984b26f43b3efc7de465f3560a949e "tools/xentop: Fix calculation
of used memory"

Thanks,

--
Sander




From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:28:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOj1T-000240-Dn; Wed, 15 Apr 2020 14:28:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Tbih=57=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jOj1R-00023n-OT
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:28:13 +0000
X-Inumbo-ID: 563b39cc-7f25-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x529.google.com (unknown [2a00:1450:4864:20::529])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 563b39cc-7f25-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 14:28:13 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id v1so5075710edq.8
 for <xen-devel@lists.xenproject.org>; Wed, 15 Apr 2020 07:28:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=zRDWejqZOu4I3rDxoALy34zPC87m3axdSTkg/jWQXik=;
 b=qJSqF4Mk3gjolhB8rf7wKTo1R+gBj7JOFrPgSGB09W9s/gVR9fvewBQpZLKNCXUY9E
 CWmgOqV1rqWK8ATLfprcfH7x9vpxk1wXaTjCpI+oBrS2HgzTd8jCDmgRYgGjhm+5Fvv+
 yZnly6w3JewfxBhYL8aRgz/ZcTEKI/vF1BIwkViAQ2Mu2AqN1y8z7ieeclzX1E8EXD23
 w1YInlHE8gqiiqPrOgYczqYVLPz9b0w9sgX1l8TVHZFPDzjsS3JE8I9MUoGJcGIqYkwb
 Eru4qFPMd4rY5KC4fLVBfSN2Fs2dRXJuyuxdsucbdDD+ZLu/sTRpFFfxfRTWHFPI9P5R
 YMYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=zRDWejqZOu4I3rDxoALy34zPC87m3axdSTkg/jWQXik=;
 b=cXDLEK3u82Bh6siYBLG5nHS4e0xdz3q4nGmsq4hUm6Zp/5v05gTNX7wQS2dViYQF+N
 Pwj0MCyv2U+bdDWhtFArh+8iN//JpMEPFa8aUpYS7TTRlC/qGBT0mNhVI08hex3ndeMT
 Snhk9RyN3bJ+xPevrHlDEZ8wVmJKQtd5SPdOVaXId12SnKEWJGiVMO5nwF1qoukpSTIC
 P7uy3N7Tm1ntZ+xm7wI7WtNE0PYTtsbHffQx/KNOJDnRRzzkP9r5MHaxYZofXEFjA2di
 FV442mdFzKEFcchsvs1OGKpEDaAb1grXMLNjGW6MqkiCuKUX1xBJsRe4dgh5YJOpEe2k
 uSHA==
X-Gm-Message-State: AGi0PuZ6EXy1sn21Yb6GIaA6aqDl9kL/1ThFWUGL9evsTVp9s14dVar6
 V3rRahiZxRaRf+G2IX0jbGo=
X-Google-Smtp-Source: APiQypLjNCFpq520RRIJ3vSvyQ6C5IKem8PMjVdXlJHDqi2H5SFhWzATbTbAdk5ZzBGrCIAZY/gVyQ==
X-Received: by 2002:a50:f7ca:: with SMTP id i10mr26202693edn.274.1586960892188; 
 Wed, 15 Apr 2020 07:28:12 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id i26sm2181368edx.23.2020.04.15.07.28.10
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 15 Apr 2020 07:28:11 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Harsha Shamsundara Havanur'" <havanur@amazon.com>,
 <xen-devel@lists.xenproject.org>
References: <9cfd038719fee7fcb01b8967ffcb23802bb75a0b.1586953651.git.havanur@amazon.com>
In-Reply-To: <9cfd038719fee7fcb01b8967ffcb23802bb75a0b.1586953651.git.havanur@amazon.com>
Subject: RE: [XEN PATCH v5] hvmloader: Enable MMIO and I/O decode,
 after all resource allocation
Date: Wed, 15 Apr 2020 15:28:10 +0100
Message-ID: <000501d61332$176a3fe0$463ebfa0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQKFNRJ78JBsHK6AS4VlXgPbepkbbqcb92eQ
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>, 'Jan Beulich' <jbeulich@suse.com>,
 'Wei Liu' <wl@xen.org>,
 =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of =
Harsha Shamsundara Havanur
> Sent: 15 April 2020 13:28
> To: xen-devel@lists.xenproject.org
> Cc: Wei Liu <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; =
Ian Jackson
> <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>; Harsha =
Shamsundara Havanur
> <havanur@amazon.com>; Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Subject: [XEN PATCH v5] hvmloader: Enable MMIO and I/O decode, after =
all resource allocation
>=20
> It was observed that PCI MMIO and/or IO BARs were programmed with
> memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
> during PCI setup phase. This resulted in incorrect memory mapping as
> soon as the lower half of the 64 bit bar is programmed.
> This displaced any RAM mappings under 4G. After the
> upper half is programmed PCI memory mapping is restored to its
> intended high mem location, but the RAM displaced is not restored.
> The OS then continues to boot and function until it tries to access
> the displaced RAM at which point it suffers a page fault and crashes.
>=20
> This patch address the issue by deferring enablement of memory and
> I/O decode in command register until all the resources, like =
interrupts
> I/O and/or MMIO BARs for all the PCI device functions are programmed,
> in the descending order of memory requested.
>=20
> Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
>=20
> ---
> Changes in v5:
>   - Fix style and comment
>   - Enable Bus master for all valid device functions
>=20
> Changes in v4:
>   Addressed review comments from Jan Beulich <jbeulich@suse.com>
>   - Disable decodes before writing ~0 to BARs
>   - Enable BUS MASTER at the end along with decode bits
>=20
> Changes in v3:
>   - Retained enabling of BUS master for all device functions as
>     was in original commit
>=20
> Changes in v2:
>   - BUS MASTER state was captured and restored to the same state
>     while enabling decode bits.
> ---
> ---
>  tools/firmware/hvmloader/pci.c | 49 =
+++++++++++++++++++++++++++++++-----------
>  1 file changed, 36 insertions(+), 13 deletions(-)
>=20
> diff --git a/tools/firmware/hvmloader/pci.c =
b/tools/firmware/hvmloader/pci.c
> index 0b708bf578..47cba69ce4 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -84,6 +84,7 @@ void pci_setup(void)
>      uint32_t vga_devfn =3D 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    uint8_t pci_devfn_decode_type[256] =3D {};
>=20
>      /* Resources assignable to PCI devices via BARs. */
>      struct resource {
> @@ -120,6 +121,13 @@ void pci_setup(void)
>       */
>      bool allow_memory_relocate =3D 1;
>=20
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=3D
> +            PCI_COMMAND_IO);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY =
!=3D
> +            PCI_COMMAND_MEMORY);
> +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MASTER =
!=3D
> +            PCI_COMMAND_MASTER);
> +

These don't align. Looks like you used an indent of 8 which seems =
entirely arbitrary.

The rest LGTM.

  Paul



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:30:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOj3Q-0002sL-2c; Wed, 15 Apr 2020 14:30:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=RJH9=57=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jOj3O-0002rm-0f
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:30:14 +0000
X-Inumbo-ID: 9d550a90-7f25-11ea-8a61-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9d550a90-7f25-11ea-8a61-12813bfff9fa;
 Wed, 15 Apr 2020 14:30:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586961013;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject;
 bh=z/nd2/GRV+xdLBcIqGxYpLsusXJPiiFpLoC5sxiMHPs=;
 b=U0GSGL8xbKSFJqTJ8GGzhPWrg7Ay5b5cnvrr2hoZyguxebXZk4X1nJX2
 ojSdH4jcKSt6PgLRqiy7jVznTNtwQZQazcdQ6Z7LsqC1u7J84BFdrP9i0
 F/y4IxamlGc1EizovgBOJQUMEdCZV8WeevcOAlB946HvKDXAa7hl9szkh o=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: RRC31ipOdO51NiTNqB6RKb8AL1+IJ5wIiYhiUCLfaWOo/r6LTo5UnKtsusfVsfcdzSJdz6zVTP
 9iZdm+nAvE1j6ctC4zRtPHvKZ3zqAMy+LLlAdqO/fgxNFJEP9vrzgNU3d3VUljS7auAfDuFM1R
 zh5AowXqXVeIfmtcftIvvHw1JJqHE92R6G1oWrvLb8tQ7cSvZYqmaNoav7rUYZ6S1FOoMhEc8t
 zpXoeKZ+fhxbGx29pkbtWOvlubUlE+0ikTCLpGQKx16Sh6Yi5HveZ6bX0Qc6noa6LLsP2CbA9W
 eDw=
X-SBRS: 2.7
X-MesageID: 15732854
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="15732854"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24215.6763.241459.280994@mariner.uk.xensource.com>
Date: Wed, 15 Apr 2020 15:30:03 +0100
To: <xen-announce@lists.xenproject.org>
Subject: Xen Project {lists,mail,downloads} outage, 22 April
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Our listserver and mailserver are going to be updated to current
Debian stable on Wednesday the 22nd of April.  The outage window is
0600-0900 UTC, but we hope not to use all of it.

During this time we expect that mail will be delayed, but hopefully
not lost or rejected.

The mailing list management UI may be unavailable.  We recommend that
even if it appears to be available, you should defer your list
(un)subscriptions until after the outage window.  It is possible that
if things don't go well, changes made during the outage window might
be rolled back.

The Xen release downloads (served from downloads.xenproject.org) will
also be unavailable during the upgrade.

Mail sent via xenbits will be affected, since xenbits sends outgoing
mail via mail.xenproject.org.  But access to git repositories
(xenbits.xenproject.org), and the osstest CI
(test-lab.xenproject.org), should be unaffected.

Ian.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:38:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:38:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOjBV-00039I-3o; Wed, 15 Apr 2020 14:38:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NCA0=57=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jOjBU-00039D-G0
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:38:36 +0000
X-Inumbo-ID: c8d7f050-7f26-11ea-8a66-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c8d7f050-7f26-11ea-8a66-12813bfff9fa;
 Wed, 15 Apr 2020 14:38:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586961515;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=W/vEx8KsduErsNlL8PiwbvayjZsx229DOAm8s5Tgb2Y=;
 b=Fa5dwHvhbTBjTq1HnQxce0d5kSWnvkN6hCdteHPaGcPkhgNbcQdC0Ud5
 XiFP+3x+1zgu2tsBciunk2HF3ytUKz1N1UE+5to9zZGeTjS4pH8uzur2f
 GH/ZiCnFIYCAJVo/ikl+b+ixYiZRD70rMi78R3spM1QYoLI7Zyv9ikqIB k=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: haw2DRn+qNmt+yZNhDqHIt/lb4B8PLWH9PF3hQo3gsFZ6vssf3YfwZxXks4UfojIxGMXYQoJhh
 Mp0DaCd15JnjljiZeQGtaJf5QtfC5olTRQR7Mbpuekd2K+CjKamnhvJkXFPn/1q6MVd43RWTlG
 I1eyNvd/auZLi0O2a+5AB1MDqLuuwfiIo2ddSqA+arDhwt1XgZKDmwkc0OgSYicKv6YhYzBeYB
 DddYpFy+wEKMVZcUegtBSnQefbCp5Wg42/xh7PPPW5y3h7BS4Pl/n6V8mSs/0t6eKhQf3XWcum
 a10=
X-SBRS: 2.7
X-MesageID: 15733450
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="15733450"
Date: Wed, 15 Apr 2020 15:38:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 07/18] build: Introduce documentation for xen
 Makefiles
Message-ID: <20200415143828.GC4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-8-anthony.perard@citrix.com>
 <0a5f89d5-de77-c548-972f-231061419e51@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0a5f89d5-de77-c548-972f-231061419e51@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 02:00:43PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
> > This start explainning the variables that can be used in the many
> > Makefiles in xen/.
> > 
> > Most of the document copies and modifies text from Linux v5.4 document
> > linux.git/Documentation/kbuild/makefiles.rst. Modification are mostly
> > to avoid mentioning kbuild. Thus I've added the SPDX tag which was
> > only in index.rst in linux.git.
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> with one question:
> 
> > +Compilation flags
> > +-----------------
> > +
> > +    CFLAGS-y and AFLAGS-y
> > +	These two flags apply only to the makefile in which they
> > +	are assigned. They are used for all the normal cc, as and ld
> > +	invocations happening during a recursive build.
> > +
> > +	$(CFLAGS-y) is necessary because the top Makefile owns the
> > +	variable $(XEN_CFLAGS) and uses it for compilation flags for the
> > +	entire tree. And the variable $(CFLAGS) is modified by Config.mk
> > +	which evaluated in every subdirs.
> > +
> > +	CFLAGS-y specifies options for compiling with $(CC).
> > +	AFLAGS-y specifies assembler options.
> 
> Is it perhaps worth mentioning that c_flags and a_flags should
> not be fiddled with by individual Makefile-s?

No, I don't think that's needed. Outside of Rules.mk-s nothing modifies
c_flags, so there isn't a good reason to modify CFLAGS via c_flags
after looking for other examples.
If they do change c_flags anyway, I don't think they would have read
that new documentation.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 14:49:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 14:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOjLr-000461-9I; Wed, 15 Apr 2020 14:49:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOjLp-00045H-6E
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 14:49:17 +0000
X-Inumbo-ID: 470f657e-7f28-11ea-8a71-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 470f657e-7f28-11ea-8a71-12813bfff9fa;
 Wed, 15 Apr 2020 14:49:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586962156;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=s3ICpc1EDdmLld+0LjoYXrjTWGZGplxJRqBfFexohwI=;
 b=J5/v1d/5rzH12WxrmO1A/a74FRxryRTigeBKpASi5QVBjiHDemR0moJr
 iiWg3qUibCcV1n2/6nnyFi8OIQwSjI5P1nh6bNSfDTu8I3C0LEy5jTMoW
 G3ubrvyvBA3xe2VPdY0aj7r3tlK/0/xHbb91WO5+QISvQAB1etXKe1p77 g=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: tZKaEua7vsq1lQnBeUkT/NzXPXR5ffIeaHTOTCx4uqvGDT8hCaEzO1eFSnenmiDZdvNa0rDIVG
 HR6RUFRwpdJns4Zue2S6/IPVaSb5d3e+FOHf4Vbv4pgUSXv3FucLTlinYSSYlbVKcNVw4cxcRX
 mPrvGbUG6nmHGALwk12LJ8RVTG7I1dBEZ1t4RsEwN1X1CuQYzpMXdtca7ds0RKu4cNWwnTv+Qa
 qpyPp2rOU2HWkxryYDU2jZ+K35fqCgKYU5uUbbD9a7WbLd0kwzx24SERzMGDntiuhHFJE6p5iC
 LeE=
X-SBRS: 2.7
X-MesageID: 15704956
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="15704956"
Date: Wed, 15 Apr 2020 16:49:08 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200415144908.GM28601@Air-de-Roger>
References: <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
 <20200414111911.GI28601@Air-de-Roger>
 <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
 <20200414145337.GJ28601@Air-de-Roger>
 <fbc0dd00-6973-4003-ad34-591561b695c9@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <fbc0dd00-6973-4003-ad34-591561b695c9@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 14, 2020 at 05:06:23PM +0200, Jan Beulich wrote:
> On 14.04.2020 16:53, Roger Pau Monné wrote:
> > On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
> >> On 14.04.2020 13:19, Roger Pau Monné wrote:
> >>> On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
> >>>> On 14.04.2020 12:02, Roger Pau Monné wrote:
> >>>>> That seems nice, we would have to be careful however as reducing the
> >>>>> number of ASID/VPID flushes could uncover issues in the existing code.
> >>>>> I guess you mean something like:
> >>>>>
> >>>>> static inline void guest_flush_tlb_mask(const struct domain *d,
> >>>>>                                         const cpumask_t *mask)
> >>>>> {
> >>>>>     flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
> >>>>>                                                                 : 0) |
> >>>>>     		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> >>>>> 		                                      : 0));
> >>>>> }
> >>>>
> >>>> Almost - is_hvm_domain(d) && cpu_has_svm seems to wide for me. I'd
> >>>> rather use hap_enabled() && cpu_has_svm, which effectively means NPT.
> >>>> Or am I overlooking a need to do ASID flushes also in shadow mode?
> >>>
> >>> I think so, I've used is_hvm_domain in order to cover for HVM domains
> >>> running in shadow mode on AMD hardware, I think those also need the
> >>> ASID flushes.
> >>
> >> I'm unconvinced: The entire section "TLB Management" in the PM gives
> >> the impression that "ordinary" TLB flushing covers all ASIDs anyway.
> >> It's not stated anywhere (I could find) explicitly though.
> > 
> > Hm, I don't think so. XenRT found a myriad of issues with NPT when p2m
> > code wasn't modified to do ASID flushes instead of plain TLB flushes.
> 
> Well, that's clear from e.g. p2m_pt_set_entry() not doing any
> flushing itself.
> 
> > Even if it's just to stay on the safe side I would perform ASID
> > flushes for HVM guests with shadow running on AMD.
> 
> Tim, any chance you could voice your thoughts here? To me it seems
> odd to do an all-ASIDs flush followed by an ASID one.

I've been reading a bit more into this, and section 15.16.1 states:

"TLB flush operations must not be assumed to affect all ASIDs."

Since the VMM runs on it's own ASID it's my understanding that doing a
TLB flush from the VMM does not flush any of the guests TLBs, and
hence an ASID flush is still required.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 15:31:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 15:31:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOk0e-0008L7-LP; Wed, 15 Apr 2020 15:31:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+yDq=57=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOk0d-0008L2-Ia
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 15:31:27 +0000
X-Inumbo-ID: 280fd8d8-7f2e-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 280fd8d8-7f2e-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 15:31:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=dK4zH5AL8njcQOBgEo/gEMWmjJPxowjfTW2bIYtworg=; b=h1w7ltcfsXo8CXJIBsqeHlvxA
 VPncWsMWgWn6yPKMl+TVyM3+IACrddRog+fEmuFr7BMIf6qSYz+I3Yf77btAZfp6UixOz6iDGS+0d
 K4B/RtZPx1uBZVaUY0W5CyLsLGBsgZLXHuVNRBsaQ5R1CDu7vvP0ihHeHJzSUYHYEyFvg=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOk0W-0006JW-B3; Wed, 15 Apr 2020 15:31:20 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOk0V-0005ba-Vs; Wed, 15 Apr 2020 15:31:20 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOk0V-0000LJ-Um; Wed, 15 Apr 2020 15:31:19 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149651-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.11-testing test] 149651: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=d353f82b2edae3019b0b9405976a05f18d120ce7
X-Osstest-Versions-That: xen=affb032b9b2624b67ffc7fb246a915dd08074b3f
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 15 Apr 2020 15:31:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass

version targeted for testing:
 xen                  d353f82b2edae3019b0b9405976a05f18d120ce7
baseline version:
 xen                  affb032b9b2624b67ffc7fb246a915dd08074b3f

Last test of basis   149556  2020-04-09 08:42:59 Z    6 days
Testing same since   149651  2020-04-14 13:35:44 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   affb032b9b..d353f82b2e  d353f82b2edae3019b0b9405976a05f18d120ce7 -> stable-4.11


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 15:42:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 15:42:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOkBL-0000yj-9F; Wed, 15 Apr 2020 15:42:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOkBJ-0000ye-B9
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 15:42:29 +0000
X-Inumbo-ID: b58a73a4-7f2f-11ea-8a87-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b58a73a4-7f2f-11ea-8a87-12813bfff9fa;
 Wed, 15 Apr 2020 15:42:28 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 55E20ABCF;
 Wed, 15 Apr 2020 15:42:26 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200406105703.79201-2-roger.pau@citrix.com>
 <30062a0c-6587-a16e-2b31-de0dd6bf4c9a@suse.com>
 <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
 <20200414111911.GI28601@Air-de-Roger>
 <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
 <20200414145337.GJ28601@Air-de-Roger>
 <fbc0dd00-6973-4003-ad34-591561b695c9@suse.com>
 <20200415144908.GM28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <93d41cd3-b24c-9b51-b15e-3b1e538bba5a@suse.com>
Date: Wed, 15 Apr 2020 17:42:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415144908.GM28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 16:49, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 05:06:23PM +0200, Jan Beulich wrote:
>> On 14.04.2020 16:53, Roger Pau Monné wrote:
>>> On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
>>>> On 14.04.2020 13:19, Roger Pau Monné wrote:
>>>>> On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
>>>>>> On 14.04.2020 12:02, Roger Pau Monné wrote:
>>>>>>> That seems nice, we would have to be careful however as reducing the
>>>>>>> number of ASID/VPID flushes could uncover issues in the existing code.
>>>>>>> I guess you mean something like:
>>>>>>>
>>>>>>> static inline void guest_flush_tlb_mask(const struct domain *d,
>>>>>>>                                         const cpumask_t *mask)
>>>>>>> {
>>>>>>>     flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
>>>>>>>                                                                 : 0) |
>>>>>>>     		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
>>>>>>> 		                                      : 0));
>>>>>>> }
>>>>>>
>>>>>> Almost - is_hvm_domain(d) && cpu_has_svm seems to wide for me. I'd
>>>>>> rather use hap_enabled() && cpu_has_svm, which effectively means NPT.
>>>>>> Or am I overlooking a need to do ASID flushes also in shadow mode?
>>>>>
>>>>> I think so, I've used is_hvm_domain in order to cover for HVM domains
>>>>> running in shadow mode on AMD hardware, I think those also need the
>>>>> ASID flushes.
>>>>
>>>> I'm unconvinced: The entire section "TLB Management" in the PM gives
>>>> the impression that "ordinary" TLB flushing covers all ASIDs anyway.
>>>> It's not stated anywhere (I could find) explicitly though.
>>>
>>> Hm, I don't think so. XenRT found a myriad of issues with NPT when p2m
>>> code wasn't modified to do ASID flushes instead of plain TLB flushes.
>>
>> Well, that's clear from e.g. p2m_pt_set_entry() not doing any
>> flushing itself.
>>
>>> Even if it's just to stay on the safe side I would perform ASID
>>> flushes for HVM guests with shadow running on AMD.
>>
>> Tim, any chance you could voice your thoughts here? To me it seems
>> odd to do an all-ASIDs flush followed by an ASID one.
> 
> I've been reading a bit more into this, and section 15.16.1 states:
> 
> "TLB flush operations must not be assumed to affect all ASIDs."

That's the section talking about the tlb_control VMCB field. It is
in this context that the sentence needs to be interpreted, imo.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 15:54:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 15:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOkMx-0001wt-Gg; Wed, 15 Apr 2020 15:54:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2fIs=57=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jOkMv-0001wb-AG
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 15:54:29 +0000
X-Inumbo-ID: 62b3de0a-7f31-11ea-83d8-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 62b3de0a-7f31-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 15:54:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586966069;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=jTRiDiTZG+Xjp4Q1/LnZ0t/bRUj29uNdc4m9+KUPg6o=;
 b=VB0WN5UyuEC0MFp6taYrSAgO/mO5T4A3FBHynsPMH1wXtaYTGyjvEJJo
 PYZ2TY6XOdSmcYbUYIygm0gE5Di2cBFa5vnk4rKK4ZtSm+7tRXIY7+w/s
 mZ/lfNiICJeDGlJo0FzjMMOYniF3qYb/ovUo+jjSP37c1Ja88AVJtlEEY Q=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: RGstGHMeJaXOIaBlOkgO6k10OXUyQDBTfmZZpMMDIgnWeK5DSLnXiugAoa3l4lvPaxoSmca7Zz
 iYuEhQDi7gDQkg1JiWEha6mpQ+I3WKO7I5h+w1aPghYQYX5p8H1A++fj5rzD5e0BK16Jqw/xCN
 J96tpWj5aSDUlCj+9G9h5JzcxtTvcCAcr6FrUMt95ibKJMC+ul34uAbhDtz9oRfcDmADJQjLUc
 fE9SXEZInDo3NJxNQ+KNenKWKKD3h3BTEto8uxjDz0PBw8UsVCKPd6qaPyfhB86ZKOTjk5Vkq/
 8kA=
X-SBRS: 2.7
X-MesageID: 15739722
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="15739722"
Date: Wed, 15 Apr 2020 17:54:20 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200415155420.GN28601@Air-de-Roger>
References: <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
 <20200414111911.GI28601@Air-de-Roger>
 <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
 <20200414145337.GJ28601@Air-de-Roger>
 <fbc0dd00-6973-4003-ad34-591561b695c9@suse.com>
 <20200415144908.GM28601@Air-de-Roger>
 <93d41cd3-b24c-9b51-b15e-3b1e538bba5a@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <93d41cd3-b24c-9b51-b15e-3b1e538bba5a@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 15, 2020 at 05:42:20PM +0200, Jan Beulich wrote:
> On 15.04.2020 16:49, Roger Pau Monné wrote:
> > On Tue, Apr 14, 2020 at 05:06:23PM +0200, Jan Beulich wrote:
> >> On 14.04.2020 16:53, Roger Pau Monné wrote:
> >>> On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
> >>>> On 14.04.2020 13:19, Roger Pau Monné wrote:
> >>>>> On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
> >>>>>> On 14.04.2020 12:02, Roger Pau Monné wrote:
> >>>>>>> That seems nice, we would have to be careful however as reducing the
> >>>>>>> number of ASID/VPID flushes could uncover issues in the existing code.
> >>>>>>> I guess you mean something like:
> >>>>>>>
> >>>>>>> static inline void guest_flush_tlb_mask(const struct domain *d,
> >>>>>>>                                         const cpumask_t *mask)
> >>>>>>> {
> >>>>>>>     flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
> >>>>>>>                                                                 : 0) |
> >>>>>>>     		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> >>>>>>> 		                                      : 0));
> >>>>>>> }
> >>>>>>
> >>>>>> Almost - is_hvm_domain(d) && cpu_has_svm seems to wide for me. I'd
> >>>>>> rather use hap_enabled() && cpu_has_svm, which effectively means NPT.
> >>>>>> Or am I overlooking a need to do ASID flushes also in shadow mode?
> >>>>>
> >>>>> I think so, I've used is_hvm_domain in order to cover for HVM domains
> >>>>> running in shadow mode on AMD hardware, I think those also need the
> >>>>> ASID flushes.
> >>>>
> >>>> I'm unconvinced: The entire section "TLB Management" in the PM gives
> >>>> the impression that "ordinary" TLB flushing covers all ASIDs anyway.
> >>>> It's not stated anywhere (I could find) explicitly though.
> >>>
> >>> Hm, I don't think so. XenRT found a myriad of issues with NPT when p2m
> >>> code wasn't modified to do ASID flushes instead of plain TLB flushes.
> >>
> >> Well, that's clear from e.g. p2m_pt_set_entry() not doing any
> >> flushing itself.
> >>
> >>> Even if it's just to stay on the safe side I would perform ASID
> >>> flushes for HVM guests with shadow running on AMD.
> >>
> >> Tim, any chance you could voice your thoughts here? To me it seems
> >> odd to do an all-ASIDs flush followed by an ASID one.
> > 
> > I've been reading a bit more into this, and section 15.16.1 states:
> > 
> > "TLB flush operations must not be assumed to affect all ASIDs."
> 
> That's the section talking about the tlb_control VMCB field. It is
> in this context that the sentence needs to be interpreted, imo.

It explicitly mentions move-to-cr3 and move-to-cr4 before that phrase:

"TLB flush operations function identically whether or not SVM is
enabled (e.g., MOV-TO-CR3 flushes non-global mappings, whereas
MOV-TO-CR4 flushes global and non-global mappings). TLB flush
operations must not be assumed to affect all ASIDs."

So my reading is that normal flush operations not involving
tlb_control VMCB field should not assume to flush all ASIDs. Again
this is of course my interpretation of the text in the PM. I will go
with my suggested approach, which is safer and should cause no
functional issues AFAICT. The only downside is the maybe redundant
flush, but that's safe.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 15:55:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 15:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOkNr-00020g-TN; Wed, 15 Apr 2020 15:55:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOkNq-00020Y-HN
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 15:55:26 +0000
X-Inumbo-ID: 85209668-7f31-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 85209668-7f31-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 15:55:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 794D3ACCE;
 Wed, 15 Apr 2020 15:55:23 +0000 (UTC)
Subject: Re: [XEN PATCH v4 06/18] xen/build: have the root Makefile generates
 the CFLAGS
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-7-anthony.perard@citrix.com>
 <a2b16a74-4eed-eeae-d791-fa9fd4e63d08@suse.com>
 <20200415141045.GB4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <adf71966-541b-d9b5-39f1-d30eb10c84f2@suse.com>
Date: Wed, 15 Apr 2020 17:55:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415141045.GB4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 16:10, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 01:50:33PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>>  # Always build obj-bin files as binary even if they come from C source. 
>>> -$(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
>>> +# FIXME LTO broken, but we would need a different way to filter -flto out
>>> +# $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
>>
>> While you mention this in the description, I'm still not overly
>> happy with it getting commented out. What's wrong with making the
>> construct simply act on c_flags?
> 
> It doesn't work.
> 
> I tried
>     $(obj-bin-y): c_flags := $(filter-out -flto,$(c_flags))
> but the $@ expansion was empty.

Hmm, yes, presumably because of having to use :=. But the old
code gives the appearance of having worked despite this fact.

> I guess we could do:
>     $(obj-bin-y): XEN_CFLAGS := $(filter-out -flto,$(XEN_CFLAGS))
> that's probably enough for now. Even if we can't test it properly.

If -flto gets added to XEN_CFLAGS (not c_flags) - why not?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 15:59:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 15:59:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOkRg-0002BX-GV; Wed, 15 Apr 2020 15:59:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=UoJL=57=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOkRe-0002BS-R8
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 15:59:22 +0000
X-Inumbo-ID: 1218202c-7f32-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1218202c-7f32-11ea-b4f4-bc764e2007e4;
 Wed, 15 Apr 2020 15:59:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 477A0AC94;
 Wed, 15 Apr 2020 15:59:20 +0000 (UTC)
Subject: Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200414075245.GC28601@Air-de-Roger>
 <92a4ff05-9dcf-1d50-b9b2-bde39c4e3e8d@suse.com>
 <20200414100213.GH28601@Air-de-Roger>
 <389afe02-1747-1583-e642-6e4025b402aa@suse.com>
 <20200414111911.GI28601@Air-de-Roger>
 <073512c9-6500-054c-c72c-1f468da6464c@suse.com>
 <20200414145337.GJ28601@Air-de-Roger>
 <fbc0dd00-6973-4003-ad34-591561b695c9@suse.com>
 <20200415144908.GM28601@Air-de-Roger>
 <93d41cd3-b24c-9b51-b15e-3b1e538bba5a@suse.com>
 <20200415155420.GN28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <63ba566b-3da9-c670-4496-9af2f9a6334c@suse.com>
Date: Wed, 15 Apr 2020 17:59:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415155420.GN28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 17:54, Roger Pau Monné wrote:
> On Wed, Apr 15, 2020 at 05:42:20PM +0200, Jan Beulich wrote:
>> On 15.04.2020 16:49, Roger Pau Monné wrote:
>>> On Tue, Apr 14, 2020 at 05:06:23PM +0200, Jan Beulich wrote:
>>>> On 14.04.2020 16:53, Roger Pau Monné wrote:
>>>>> On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
>>>>>> On 14.04.2020 13:19, Roger Pau Monné wrote:
>>>>>>> On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
>>>>>>>> On 14.04.2020 12:02, Roger Pau Monné wrote:
>>>>>>>>> That seems nice, we would have to be careful however as reducing the
>>>>>>>>> number of ASID/VPID flushes could uncover issues in the existing code.
>>>>>>>>> I guess you mean something like:
>>>>>>>>>
>>>>>>>>> static inline void guest_flush_tlb_mask(const struct domain *d,
>>>>>>>>>                                         const cpumask_t *mask)
>>>>>>>>> {
>>>>>>>>>     flush_mask(mask, (is_pv_domain(d) || shadow_mode_enabled(d) ? FLUSH_TLB
>>>>>>>>>                                                                 : 0) |
>>>>>>>>>     		     (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
>>>>>>>>> 		                                      : 0));
>>>>>>>>> }
>>>>>>>>
>>>>>>>> Almost - is_hvm_domain(d) && cpu_has_svm seems to wide for me. I'd
>>>>>>>> rather use hap_enabled() && cpu_has_svm, which effectively means NPT.
>>>>>>>> Or am I overlooking a need to do ASID flushes also in shadow mode?
>>>>>>>
>>>>>>> I think so, I've used is_hvm_domain in order to cover for HVM domains
>>>>>>> running in shadow mode on AMD hardware, I think those also need the
>>>>>>> ASID flushes.
>>>>>>
>>>>>> I'm unconvinced: The entire section "TLB Management" in the PM gives
>>>>>> the impression that "ordinary" TLB flushing covers all ASIDs anyway.
>>>>>> It's not stated anywhere (I could find) explicitly though.
>>>>>
>>>>> Hm, I don't think so. XenRT found a myriad of issues with NPT when p2m
>>>>> code wasn't modified to do ASID flushes instead of plain TLB flushes.
>>>>
>>>> Well, that's clear from e.g. p2m_pt_set_entry() not doing any
>>>> flushing itself.
>>>>
>>>>> Even if it's just to stay on the safe side I would perform ASID
>>>>> flushes for HVM guests with shadow running on AMD.
>>>>
>>>> Tim, any chance you could voice your thoughts here? To me it seems
>>>> odd to do an all-ASIDs flush followed by an ASID one.
>>>
>>> I've been reading a bit more into this, and section 15.16.1 states:
>>>
>>> "TLB flush operations must not be assumed to affect all ASIDs."
>>
>> That's the section talking about the tlb_control VMCB field. It is
>> in this context that the sentence needs to be interpreted, imo.
> 
> It explicitly mentions move-to-cr3 and move-to-cr4 before that phrase:
> 
> "TLB flush operations function identically whether or not SVM is
> enabled (e.g., MOV-TO-CR3 flushes non-global mappings, whereas
> MOV-TO-CR4 flushes global and non-global mappings). TLB flush
> operations must not be assumed to affect all ASIDs."

Hmm, indeed. How did I not spot this already when reading this the
other day?

> So my reading is that normal flush operations not involving
> tlb_control VMCB field should not assume to flush all ASIDs. Again
> this is of course my interpretation of the text in the PM. I will go
> with my suggested approach, which is safer and should cause no
> functional issues AFAICT. The only downside is the maybe redundant
> flush, but that's safe.

Okay. And I'm sorry for having attempted to mislead you.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 16:06:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 16:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOkYT-0003bx-BL; Wed, 15 Apr 2020 16:06:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NCA0=57=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jOkYS-0003bs-7Z
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 16:06:24 +0000
X-Inumbo-ID: 0b70c143-7f33-11ea-8a8b-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0b70c143-7f33-11ea-8a8b-12813bfff9fa;
 Wed, 15 Apr 2020 16:06:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586966782;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=3RF1qwsYl1fvOhYvwlgKda5DNYFTm0l7l3nQGW+RA+k=;
 b=XLEO7fY53gjxJoQoiQDSbRUEBGpItNk9J0HgdMlWqVr+OycUHtSr0jh3
 zqMoLaKiIC0Ta98tYq7cVwS3a+Fb/Qv95dAnfegW2s1aushypNhAH99qI
 Loitja7lYXQuj5houpxWXHitx5lAp8tFjxFpCs3CtP93CrJ6fdeflpK14 U=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: ml+gMtIUlb+7yti7C2VsiGKIzJH8RWmiDnVgfMdffdHsT61j7dQRo6TmDPLMrf4iaqEFaHjNHh
 +zWgIsbZWk+2dsK62bv6zVCD93IgT52RfH/ssNtWjqkU8EACJW/lnqXIliU9zcqwWOI86FuM6z
 lxEqvd4mOGmwpX3D8ksvP5AmU3+gb7v67GdoZaPraTax94zh3NMtgHKtUce8FLwQBkzaPxPuZf
 vvPNJZSFH00iYK+FJCs7BB9ZbQHpuExhyV4G22EgZQxaQAl+pHGete9zIvhPDn/4U8r3rIyvHH
 zUs=
X-SBRS: 2.7
X-MesageID: 15966399
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="15966399"
Date: Wed, 15 Apr 2020 17:06:15 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 10/18] xen/build: use if_changed on built_in.o
Message-ID: <20200415160615.GD4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-11-anthony.perard@citrix.com>
 <072ffe9d-88c0-144f-a9ab-c83869ad34e2@suse.com>
 <71ee52de-af4a-2b1b-4080-d42af6ac6399@citrix.com>
 <03b74c20-54bb-06dd-8020-16da4b3bf521@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <03b74c20-54bb-06dd-8020-16da4b3bf521@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 03:35:17PM +0200, Jan Beulich wrote:
> On 08.04.2020 15:13, Andrew Cooper wrote:
> > On 08/04/2020 13:40, Jan Beulich wrote:
> >> On 31.03.2020 12:30, Anthony PERARD wrote:
> >>> --- a/xen/Rules.mk
> >>> +++ b/xen/Rules.mk
> >>> @@ -130,15 +130,24 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
> >>>  c_flags += $(CFLAGS-y)
> >>>  a_flags += $(CFLAGS-y) $(AFLAGS-y)
> >>>  
> >>> -built_in.o: $(obj-y) $(extra-y)
> >>> -ifeq ($(obj-y),)
> >>> -	$(CC) $(c_flags) -c -x c /dev/null -o $@
> >>> -else
> >>> +quiet_cmd_ld_builtin = LD      $@
> >>>  ifeq ($(CONFIG_LTO),y)
> >>> -	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
> >>> +cmd_ld_builtin = \
> >>> +    $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
> >>>  else
> >>> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
> >>> +cmd_ld_builtin = \
> >>> +    $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
> >>>  endif
> >> How about going yet one step further and doing away with the
> >> ifeq here altogether:
> >>
> >> cmd_ld_builtin-y = \
> >>     $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
> >> cmd_ld_builtin-$(CONFIG_LTO) = \
> >>     $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
> > 
> > Please don't.
> > 
> > Logic like this is substantially harder to follow than a plain if/else
> > construct, and clarity is of far higher importance than optimising the
> > line count in the build system.
> 
> I could maybe see the argument if the two definitions were far apart.
> This suggestion isn't about line count at all, but about clarity. In
> particular because of the need to use ifeq(,) rather than simple "if"
> constructs, I view this list model as the better alternative in all
> cases where it can be made use of.

We could use "ifdef CONFIG_LTO" to avoid ifeq ;-). But I think you
disliked that because CONFIG_LTO could be present in the environment
with a value different than "y" and mess up the build system, just to
annoy us.

> > This trick only works for trivial cases, and interferes with diff's when
> > the logic inevitably becomes less trivial.
> 
> It may, but whether it actually will can't be known until such time
> as it would get touched. The suggested model may very well also be
> suitable then.
> 
> Anyway, Anthony, I'm not going to insist. This is just another aspect
> where we would better generally settle on the preferred style to use.

I think if/else is better for alternatives. And we can keep "var-y" for
lists with optional items.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 16:58:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 16:58:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOlN3-0007yd-H7; Wed, 15 Apr 2020 16:58:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=NCA0=57=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jOlN2-0007yY-Jy
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 16:58:40 +0000
X-Inumbo-ID: 5a4cab30-7f3a-11ea-8a9d-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5a4cab30-7f3a-11ea-8a9d-12813bfff9fa;
 Wed, 15 Apr 2020 16:58:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586969919;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=bIM8+88g3CgLKm9tfNDdFOCKIodTYi4iWimyZSBpDhA=;
 b=YUsC8aqj2VaLNFWEKTh6go/Aia2pflzP/q00sWMmuWHsqqrn2dsIMqHj
 ejOmeBT50RAXLeUiDcSiR5jTTBNxjQj92TNZ/B2nl9v4YJ3Eq328/ZTOb
 duQHClgIp243I2AaBalkr2KsYRVCmt4zl9tVY4f33glAlxDrRju5jcpyk k=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: CReFrOIJbnZcAfZ7gZHVWLv8BbeOUYmfinUJb+Q3FhN0u2kcX0m0hgn/4mGdERWQpP6GTHeX9j
 CcB3XMEodEPd+BC40SdRj09wvpYuMGQlSIeoHq2BkKJ87Z9aMqfOUZVVVGSCod/2Y0/ST/s/9F
 aSN5uhHRWTpRC37YWKFWvnIjOZosU+Emr6ZM5e5lPApxGcw0xNzwRj/bpcDO3vyy1fjKv9/XTE
 Athyc/f9IXTW5hVnOznQ3FB5fwRmCht/ISxvq7nzvfVTT0fCVZYsDNNcVia3XfHrtGtcgbgIoN
 Hi8=
X-SBRS: 2.7
X-MesageID: 15969785
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="15969785"
Date: Wed, 15 Apr 2020 17:58:32 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 12/18] xen/build: factorise generation of the
 linker scripts
Message-ID: <20200415165832.GE4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-13-anthony.perard@citrix.com>
 <af0121cc-c282-ceb0-b5e8-44ac0ba6ebfb@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <af0121cc-c282-ceb0-b5e8-44ac0ba6ebfb@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 02:46:42PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
> >     - avoid using "define" for cmd_cc_lds_S, as adding '; \' on each line is
> >       still mandatory for if_changed (or cmd) macro to work.
> 
> I still don't believe in there being a need for "; \" there. This
> actually breaks things, after all:
> 
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -236,6 +236,12 @@ cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
> >  %.s: %.S FORCE
> >  	$(call if_changed,cpp_s_S)
> >  
> > +# Linker scripts, .lds.S -> .lds
> > +quiet_cmd_cc_lds_S = LDS     $@
> > +cmd_cc_lds_S = $(CPP) -P $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<; \
> > +    sed -e 's/.*\.lds\.o:/$(@F):/g' <$(dot-target).d >$(dot-target).d.new; \
> > +    mv -f $(dot-target).d.new $(dot-target).d
> 
> if $(CPP) or sed fail, previously the whole rule would have failed,
> which no longer is the case with your use of semicolons. There
> ought to be a solution to this, ideally one better than adding
> "set -e" as the first command ("define" would at least deal with
> the multi-line make issue, but without it being clear to me why the
> semicolons would be needed I don't think I can suggest anything
> there at the moment).

The only macro that will consumes cmd_cc_lds_S (and other cmd_*) is
"cmd", it is defined as:
    cmd = @set -e; $(echo-cmd) $(cmd_$(1))
So, "set -e" is already there, and using semicolons in commands is
equivalent to using "&&".

With "cmd" alone, multi-line command would work as expected (unless
$(echo-cmd) is is trying to print the command line).

It's "if_changed" macro that doesn't work with multi-line commands.
It does:
    $(cmd); printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd
With a multiple line command, $(make-cmd) get's expanded to multiple
line, so the second argument of "printf" is going to be spread over
multiple line in make, and thus multiple shell. We run into this error:
    /bin/sh: -c: line 0: unexpected EOF while looking for matching `''
    /bin/sh: -c: line 1: syntax error: unexpected end of file

This is why we need to have commands on a single line.

I hope the explanation is clear enough.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 17:39:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 17:39:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOm0O-0003F1-3c; Wed, 15 Apr 2020 17:39:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=c95o=57=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOm0N-0003Ew-2Q
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 17:39:19 +0000
X-Inumbo-ID: 07cf02ee-7f40-11ea-83d8-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 07cf02ee-7f40-11ea-83d8-bc764e2007e4;
 Wed, 15 Apr 2020 17:39:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1586972358;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=KT25FAHq2BmfGlcvKEr4mXsRrbSMMRPlnJpg+2+Quf0=;
 b=YaLsDyX1Y72KHdGtHWFRlfDtn0O7wrupwC8emrTkgk0mAumrNl//CLcU
 omDNYmNqMyi5QSuMuWzaHbk8DodEOxPja82D7ZcZRqXfNNimomKNfW/25
 6gLJcPBCVbGTnDTW9Upm39viL048HgCbYmMNTkNLRcc9BbWWSz89+ONdP 8=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: gUaA31CQCxiClz/lI3IeMQFARiETpsiNaP4x3659Q/wcJVtVNl8Jo+TQrMgYKJMnfVcxqZDTPE
 sj8yK0oUC6C79TbQ5ESmuACSMKxXh0YGhHaqikK8rU9P3jaGwGtPkWAEF/LkXTqLB3kdnZpQXK
 +nC++WXm/Dekmg1u2wBlaVMxdM69nJTsGmOz0fIIAj4Z80cfKzsJ8niJpEh8ZUsvTM5jOuRnjN
 cg7l6KJFzFttZmjhesjbrFdO8gvTacKDkdIufSIp3QWII3HFvuUu1gA6G8f+Vr2TXLWkqAoV3t
 FuY=
X-SBRS: 2.7
X-MesageID: 15746409
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,387,1580792400"; d="scan'208";a="15746409"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/boot: Fix early exception handling with
 CONFIG_PERF_COUNTERS
Date: Wed, 15 Apr 2020 18:39:11 +0100
Message-ID: <20200415173911.13286-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Wei Liu <wl@xen.org>, Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The PERFC_INCR() macro uses current->processor, but current is not valid
during early boot.  This causes the following crash to occur if
e.g. rdmsr_safe() has to recover from a #GP fault.

  (XEN) Early fatal page fault at e008:ffff82d0803b1a39 (cr2=0000000000000004, ec=0000)
  (XEN) ----[ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]----
  (XEN) CPU:    0
  (XEN) RIP:    e008:[<ffff82d0803b1a39>] x86_64/entry.S#handle_exception_saved+0x64/0xb8
  ...
  (XEN) Xen call trace:
  (XEN)    [<ffff82d0803b1a39>] R x86_64/entry.S#handle_exception_saved+0x64/0xb8
  (XEN)    [<ffff82d0806394fe>] F __start_xen+0x2cd/0x2980
  (XEN)    [<ffff82d0802000ec>] F __high_start+0x4c/0x4e

Furthermore, the PERFC_INCR() macro is wildly inefficient.  There has been a
single caller for many releases now, so inline it and delete the macro
completely.

For the assembly, move entry_vector from %eax into %ecx.  There is no encoding
benefit for movzbl, and it frees up %eax to be used inside the
CONFIG_PERF_COUNTERS block where there is an encoding benefit.

There is no need to reference current at all.  What is actually needed is the
per_cpu_offset which can be obtained directly from the top-of-stack block.
This simplifies the counter handling to 3 instructions and no spilling to the
stack at all.

The same breakage from above is now handled properly:

  (XEN) traps.c:1591: GPF (0000): ffff82d0806394fe [__start_xen+0x2cd/0x2980] -> ffff82d0803b3bfb

Reported-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Julien Grall <jgrall@amazon.com>
---
 xen/arch/x86/x86_64/asm-offsets.c |  1 +
 xen/arch/x86/x86_64/entry.S       | 10 +++++++---
 xen/include/asm-x86/asm_defns.h   | 16 ----------------
 3 files changed, 8 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index b8e8510439..500df7a3e7 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -112,6 +112,7 @@ void __dummy__(void)
     OFFSET(CPUINFO_guest_cpu_user_regs, struct cpu_info, guest_cpu_user_regs);
     OFFSET(CPUINFO_verw_sel, struct cpu_info, verw_sel);
     OFFSET(CPUINFO_current_vcpu, struct cpu_info, current_vcpu);
+    OFFSET(CPUINFO_per_cpu_offset, struct cpu_info, per_cpu_offset);
     OFFSET(CPUINFO_cr4, struct cpu_info, cr4);
     OFFSET(CPUINFO_xen_cr3, struct cpu_info, xen_cr3);
     OFFSET(CPUINFO_pv_cr3, struct cpu_info, pv_cr3);
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 997c481ecb..52bd41d9f6 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -677,10 +677,14 @@ handle_exception_saved:
 #endif /* CONFIG_PV */
         sti
 1:      movq  %rsp,%rdi
-        movzbl UREGS_entry_vector(%rsp),%eax
+        movzbl UREGS_entry_vector(%rsp), %ecx
         leaq  exception_table(%rip),%rdx
-        PERFC_INCR(exceptions, %rax, %rbx)
-        mov   (%rdx, %rax, 8), %rdx
+#ifdef CONFIG_PERF_COUNTERS
+        lea   per_cpu__perfcounters(%rip), %rax
+        add   STACK_CPUINFO_FIELD(per_cpu_offset)(%r14), %rax
+        incl  ASM_PERFC_exceptions * 4(%rax, %rcx, 4)
+#endif
+        mov   (%rdx, %rcx, 8), %rdx
         INDIRECT_CALL %rdx
         mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
         mov   %r13b, STACK_CPUINFO_FIELD(use_pv_cr3)(%r14)
diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h
index bc9d9fcdb2..b42a19b654 100644
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -346,22 +346,6 @@ static always_inline void stac(void)
 
 #endif
 
-#ifdef CONFIG_PERF_COUNTERS
-#define PERFC_INCR(_name,_idx,_cur)             \
-        pushq _cur;                             \
-        movslq VCPU_processor(_cur),_cur;       \
-        pushq %rdx;                             \
-        leaq __per_cpu_offset(%rip),%rdx;       \
-        movq (%rdx,_cur,8),_cur;                \
-        leaq per_cpu__perfcounters(%rip),%rdx;  \
-        addq %rdx,_cur;                         \
-        popq %rdx;                              \
-        incl ASM_PERFC_##_name*4(_cur,_idx,4);  \
-        popq _cur
-#else
-#define PERFC_INCR(_name,_idx,_cur)
-#endif
-
 /* Work around AMD erratum #88 */
 #define safe_swapgs                             \
         "mfence; swapgs;"
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 18:38:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 18:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOmvF-0000F7-1W; Wed, 15 Apr 2020 18:38:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOmvE-0000F2-3o
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 18:38:04 +0000
X-Inumbo-ID: 3d46427c-7f48-11ea-8abf-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3d46427c-7f48-11ea-8abf-12813bfff9fa;
 Wed, 15 Apr 2020 18:38:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=w0De8RWsimvi343iFj1mIkaonWnYYRQGzcjR5lnEr8U=; b=676GNLxCC4w4dAJ1sz8YHb3rEr
 p4MZuXT/tzfTWyi+QwsJxcHA1SHTJa7E7s3RYBzom1WjI75uywIPkogA/rp5RSlgMJNYCxbh+0OWq
 pKhozrI6Pgb08hY1YyXjVBaigSmLVhmYpazQQzxF7ePJklabIEbdKl9oOZEhXAPhSEB8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvC-00020U-LN; Wed, 15 Apr 2020 18:38:02 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvC-0005Md-AW; Wed, 15 Apr 2020 18:38:02 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v4 0/4] use new API for Xen page tables
Date: Wed, 15 Apr 2020 19:37:48 +0100
Message-Id: <cover.1586975587.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

This small series is basically just rewriting functions using the new
API to map and unmap PTEs. Each patch is independent.

Apart from mapping and unmapping page tables, no other functional change
intended.

---
Changed in v4:
- use _ suffix instead of prefix in macros.
- use normal unmap_domain_page() for variable right before end-of-scope.

Changed in v3:
- address all comments in v2.
- drop patch 4, since other clean-ups will make it unnecessary.

Changed in v2:
- I kept UNMAP_DOMAIN_PAGE() for now in v2, but I if people say
  in some cases it is an overkill and unmap_domain_page() should be
  used, I am okay with that and can make the change.
- code cleanup and style fixes.
- unmap as early as possible.

Wei Liu (4):
  x86/shim: map and unmap page tables in replace_va_mapping
  x86_64/mm: map and unmap page tables in m2p_mapped
  x86_64/mm: map and unmap page tables in share_hotadd_m2p_table
  x86_64/mm: map and unmap page tables in destroy_m2p_mapping

 xen/arch/x86/pv/shim.c     |  9 ++++----
 xen/arch/x86/x86_64/mm.c   | 44 +++++++++++++++++++++-----------------
 xen/include/asm-x86/page.h | 19 ++++++++++++++++
 3 files changed, 48 insertions(+), 24 deletions(-)

-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 18:38:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 18:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOmvQ-0000GT-E0; Wed, 15 Apr 2020 18:38:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOmvP-0000GC-DS
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 18:38:15 +0000
X-Inumbo-ID: 4099e352-7f48-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4099e352-7f48-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 18:38:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=wtSQHHmgrwnbMvPmliwMYHdNPJs99gEJt0RbRPvDJgc=; b=vduiSzcAUdceT/n7jp+T1bniId
 ZPNFexGiSZu0nll3HunbP2GHiz8v8ANbQ9h0d924b/+mEYpum/bbbZT/xKLduFcUHmv/V2Sp7BSrh
 Z0Bdsadnz0SrGhTLQxqM6K4yj4srTWyHXKtIDA54aYjg0L0IJbzhz3BvzKldlp713yWY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvI-00020s-A7; Wed, 15 Apr 2020 18:38:08 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvI-0005Md-0h; Wed, 15 Apr 2020 18:38:08 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v4 4/4] x86_64/mm: map and unmap page tables in
 destroy_m2p_mapping
Date: Wed, 15 Apr 2020 19:37:52 +0100
Message-Id: <cd077c5592df0ee1c3568bab1c5e5001946981a9.1586975587.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586975587.git.hongyxia@amazon.com>
References: <cover.1586975587.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586975587.git.hongyxia@amazon.com>
References: <cover.1586975587.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed in v4:
- switch to normal unmap_domain_page() for variable right before
  end-of-scope.

Changed in v3:
- rename l2_ro_mpt into pl2e to avoid confusion.

Changed in v2:
- no point in re-mapping l2t because it is exactly the same as
  l2_ro_mpt.
- point l2_ro_mpt to the entry instead of doing l2_table_offset() all
  the time.
---
 xen/arch/x86/x86_64/mm.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index cfaeae84e9..e85ef449f3 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -263,7 +263,8 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
     unsigned long i, va, rwva;
     unsigned long smap = info->spfn, emap = info->epfn;
 
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
+    l3_ro_mpt = map_l3t_from_l4e(
+                    idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
 
     /*
      * No need to clean m2p structure existing before the hotplug
@@ -271,7 +272,7 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
     for (i = smap; i < emap;)
     {
         unsigned long pt_pfn;
-        l2_pgentry_t *l2_ro_mpt;
+        l2_pgentry_t *pl2e;
 
         va = RO_MPT_VIRT_START + i * sizeof(*machine_to_phys_mapping);
         rwva = RDWR_MPT_VIRT_START + i * sizeof(*machine_to_phys_mapping);
@@ -285,26 +286,30 @@ static void destroy_m2p_mapping(struct mem_hotadd_info *info)
             continue;
         }
 
-        l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
-        if (!(l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT))
+        pl2e = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]) +
+                    l2_table_offset(va);
+        if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
         {
             i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
                     (1UL << (L2_PAGETABLE_SHIFT - 3)) ;
+            UNMAP_DOMAIN_PAGE(pl2e);
             continue;
         }
 
-        pt_pfn = l2e_get_pfn(l2_ro_mpt[l2_table_offset(va)]);
+        pt_pfn = l2e_get_pfn(*pl2e);
         if ( hotadd_mem_valid(pt_pfn, info) )
         {
             destroy_xen_mappings(rwva, rwva + (1UL << L2_PAGETABLE_SHIFT));
 
-            l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
-            l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_empty());
+            l2e_write(pl2e, l2e_empty());
         }
         i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
               (1UL << (L2_PAGETABLE_SHIFT - 3));
+        unmap_domain_page(pl2e);
     }
 
+    UNMAP_DOMAIN_PAGE(l3_ro_mpt);
+
     destroy_compat_m2p_mapping(info);
 
     /* Brute-Force flush all TLB */
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 18:38:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 18:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOmvK-0000Fk-Mw; Wed, 15 Apr 2020 18:38:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOmvI-0000FT-W5
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 18:38:09 +0000
X-Inumbo-ID: 3f236a20-7f48-11ea-8abf-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3f236a20-7f48-11ea-8abf-12813bfff9fa;
 Wed, 15 Apr 2020 18:38:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=CtlOkdsHjlKFcb39XzK+uw2HvlaIF3cGj21C2XsAUj8=; b=glId3sBLWVFPgGXaUMZcet07lb
 hxuPNoosoivlji4cO+7gfQHaeE6JlHzl9j10fjJjSbYTH4eIyEjBfnLCzSj0zFDMnfOQndYvKHz4k
 d0fLo8CVxxoQq2jLWGiUC1AsVHXsQnjw7W7Ib5oI6HRpYdFmewesFF2T7XUrQWXwq+UA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvF-00020g-Fa; Wed, 15 Apr 2020 18:38:05 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvF-0005Md-5r; Wed, 15 Apr 2020 18:38:05 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v4 2/4] x86_64/mm: map and unmap page tables in m2p_mapped
Date: Wed, 15 Apr 2020 19:37:50 +0100
Message-Id: <5e880ea0aea869fe31438b61540227c6f4f1bfcb.1586975587.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586975587.git.hongyxia@amazon.com>
References: <cover.1586975587.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586975587.git.hongyxia@amazon.com>
References: <cover.1586975587.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

---
Changed in v3:
- rename l3e_ro_mpt and l2e_ro_mpt, just call them l3e and l2e.

Changed in v2:
- avoid adding goto labels, simply get the PTE and unmap quickly.
- code style fixes.
---
 xen/arch/x86/x86_64/mm.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index cee836ec37..41755ded26 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -129,14 +129,13 @@ static mfn_t alloc_hotadd_mfn(struct mem_hotadd_info *info)
 static int m2p_mapped(unsigned long spfn)
 {
     unsigned long va;
-    l3_pgentry_t *l3_ro_mpt;
-    l2_pgentry_t *l2_ro_mpt;
+    l3_pgentry_t l3e;
+    l2_pgentry_t l2e;
 
     va = RO_MPT_VIRT_START + spfn * sizeof(*machine_to_phys_mapping);
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
+    l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(va)], l3_table_offset(va));
 
-    switch ( l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
-             (_PAGE_PRESENT |_PAGE_PSE))
+    switch ( l3e_get_flags(l3e) & (_PAGE_PRESENT | _PAGE_PSE) )
     {
         case _PAGE_PSE|_PAGE_PRESENT:
             return M2P_1G_MAPPED;
@@ -146,9 +145,9 @@ static int m2p_mapped(unsigned long spfn)
         default:
             return M2P_NO_MAPPED;
     }
-    l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
+    l2e = l2e_from_l3e(l3e, l2_table_offset(va));
 
-    if (l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT)
+    if ( l2e_get_flags(l2e) & _PAGE_PRESENT )
         return M2P_2M_MAPPED;
 
     return M2P_NO_MAPPED;
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 18:38:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 18:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOmvM-0000Fw-1T; Wed, 15 Apr 2020 18:38:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOmvK-0000Ff-Cm
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 18:38:10 +0000
X-Inumbo-ID: 3fbf2870-7f48-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3fbf2870-7f48-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 18:38:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=NjsU0mvN8f3Kkt58hhovqMgTFjoAL4EcJkT/EkRsASw=; b=c7BI++wLiuzUBdO51vXkFZaF1N
 GtK7GzkoHTVf1NNy4tip3XFLBWm8xW1eedEDpZzh0oZxjQKQTB6PF2iZ0GVysGvceERfJGj3zxaMc
 PF5JO63vX/WxoZ972Vo/epj51DNq00Jrh6HF/CiluJlFqboVYeWQ/83f25K8K2mY2YnY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvG-00020l-TD; Wed, 15 Apr 2020 18:38:06 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvG-0005Md-JN; Wed, 15 Apr 2020 18:38:06 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v4 3/4] x86_64/mm: map and unmap page tables in
 share_hotadd_m2p_table
Date: Wed, 15 Apr 2020 19:37:51 +0100
Message-Id: <3e716bbf183f8ecd162c04e1c3f4c44fd292d082.1586975587.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586975587.git.hongyxia@amazon.com>
References: <cover.1586975587.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586975587.git.hongyxia@amazon.com>
References: <cover.1586975587.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Fetch lYe by mapping and unmapping lXe instead of using the direct map,
which is now done via the lYe_from_lXe() helpers.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

---
Changed in v2:
- the introduction of the macros is now lifted to a previous patch.
---
 xen/arch/x86/x86_64/mm.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 41755ded26..cfaeae84e9 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -166,14 +166,14 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
           v += n << PAGE_SHIFT )
     {
         n = L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES;
-        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-            l3_table_offset(v)];
+        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+                           l3_table_offset(v));
         if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
             continue;
         if ( !(l3e_get_flags(l3e) & _PAGE_PSE) )
         {
             n = L1_PAGETABLE_ENTRIES;
-            l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+            l2e = l2e_from_l3e(l3e, l2_table_offset(v));
             if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
                 continue;
             m2p_start_mfn = l2e_get_mfn(l2e);
@@ -194,11 +194,11 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
           v != RDWR_COMPAT_MPT_VIRT_END;
           v += 1 << L2_PAGETABLE_SHIFT )
     {
-        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-            l3_table_offset(v)];
+        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+                           l3_table_offset(v));
         if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
             continue;
-        l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+        l2e = l2e_from_l3e(l3e, l2_table_offset(v));
         if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
             continue;
         m2p_start_mfn = l2e_get_mfn(l2e);
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 18:38:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 18:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOmvG-0000FI-CS; Wed, 15 Apr 2020 18:38:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lFP+=57=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jOmvF-0000FB-GL
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 18:38:05 +0000
X-Inumbo-ID: 3e0d54f2-7f48-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3e0d54f2-7f48-11ea-b58d-bc764e2007e4;
 Wed, 15 Apr 2020 18:38:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=OGUpue1cqSI1HPssYadS8eAIPmRW9EWPZGCXCE9dcVM=; b=jSgcbfR6F4U6UthIr2iYcEdQU0
 xT73P2rrPBS96AckwpUD4P63Y69k/Xn7NanJtNaINdz2Yd2bkSfjiUGfznFHOkFRN+lk/QkEwFgrC
 GA261dK3vkPNcQaiecneXyq+y9eqGVlrkNsY6mnqKffjPYAniOVp+FoVZra2DNtqMlQE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvE-00020Z-22; Wed, 15 Apr 2020 18:38:04 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jOmvD-0005Md-O3; Wed, 15 Apr 2020 18:38:03 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v4 1/4] x86/shim: map and unmap page tables in
 replace_va_mapping
Date: Wed, 15 Apr 2020 19:37:49 +0100
Message-Id: <2401b53f39ae0aeb7fac6c207f5f89ff8687338b.1586975587.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1586975587.git.hongyxia@amazon.com>
References: <cover.1586975587.git.hongyxia@amazon.com>
In-Reply-To: <cover.1586975587.git.hongyxia@amazon.com>
References: <cover.1586975587.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Also, introduce lYe_from_lXe() macros which do not rely on the direct
map when walking page tables. Unfortunately, they cannot be inline
functions due to the header dependency on domain_page.h, so keep them as
macros just like map_lYt_from_lXe().

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed in v4:
- use _ suffixes instead of prefixes.

Changed in v3:
- use unmap_domain_page() instead of the macro in several places.
- also introduce l1e_from_l2e().
- add _ prefix in macros to avoid aliasing.

Changed in v2:
- instead of map, map, map, read/write, unmap, unmap, unmap, do map,
  read PTE, unmap for each level instead.
- use lYe_from_lXe() macros and lift them from a later patch to this
  patch.
- const qualify pointers in new macros.
---
 xen/arch/x86/pv/shim.c     |  9 +++++----
 xen/include/asm-x86/page.h | 19 +++++++++++++++++++
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index ed2ece8a8a..31264582cc 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -168,16 +168,17 @@ const struct platform_bad_page *__init pv_shim_reserved_pages(unsigned int *size
 static void __init replace_va_mapping(struct domain *d, l4_pgentry_t *l4start,
                                       unsigned long va, mfn_t mfn)
 {
-    l4_pgentry_t *pl4e = l4start + l4_table_offset(va);
-    l3_pgentry_t *pl3e = l4e_to_l3e(*pl4e) + l3_table_offset(va);
-    l2_pgentry_t *pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(va);
-    l1_pgentry_t *pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(va);
+    l4_pgentry_t l4e = l4start[l4_table_offset(va)];
+    l3_pgentry_t l3e = l3e_from_l4e(l4e, l3_table_offset(va));
+    l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(va));
+    l1_pgentry_t *pl1e = map_l1t_from_l2e(l2e) + l1_table_offset(va);
     struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e));
 
     put_page_and_type(page);
 
     *pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT
                                                       : COMPAT_L1_PROT));
+    unmap_domain_page(pl1e);
 }
 
 static void evtchn_reserve(struct domain *d, unsigned int port)
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index eb73a0fc23..5acf3d3d5a 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -197,6 +197,25 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, unsigned int flags)
 #define map_l2t_from_l3e(x)        (l2_pgentry_t *)map_domain_page(l3e_get_mfn(x))
 #define map_l3t_from_l4e(x)        (l3_pgentry_t *)map_domain_page(l4e_get_mfn(x))
 
+/* Unlike lYe_to_lXe(), lXe_from_lYe() do not rely on the direct map. */
+#define l1e_from_l2e(l2e_, offset_) ({                      \
+        const l1_pgentry_t *l1t_ = map_l1t_from_l2e(l2e_);  \
+        l1_pgentry_t l1e_ = l1t_[offset_];                  \
+        unmap_domain_page(l1t_);                            \
+        l1e_; })
+
+#define l2e_from_l3e(l3e_, offset_) ({                      \
+        const l2_pgentry_t *l2t_ = map_l2t_from_l3e(l3e_);  \
+        l2_pgentry_t l2e_ = l2t_[offset_];                  \
+        unmap_domain_page(l2t_);                            \
+        l2e_; })
+
+#define l3e_from_l4e(l4e_, offset_) ({                      \
+        const l3_pgentry_t *l3t_ = map_l3t_from_l4e(l4e_);  \
+        l3_pgentry_t l3e_ = l3t_[offset_];                  \
+        unmap_domain_page(l3t_);                            \
+        l3e_; })
+
 /* Given a virtual address, get an entry offset into a page table. */
 #define l1_table_offset(a)         \
     (((a) >> L1_PAGETABLE_SHIFT) & (L1_PAGETABLE_ENTRIES - 1))
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 15 19:01:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 19:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOnI9-0003Mj-Ib; Wed, 15 Apr 2020 19:01:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+yDq=57=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOnI7-0003MV-TI
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 19:01:43 +0000
X-Inumbo-ID: 87658cad-7f4b-11ea-8ac3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 87658cad-7f4b-11ea-8ac3-12813bfff9fa;
 Wed, 15 Apr 2020 19:01:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=H007eG7zLZ4obUNGIsBcZ4Ey5MWiYvGGM7z1HnLXD8w=; b=k6cLPmpMui3PX0jN2z6jHAukh
 uW+X/pFdssrTTyEKlreb1pyEcciHB9qijyjfx10LWJbE+Ky9SOalwA9hmMSoymneMvnDXqtXL+XQd
 SX8YMSXC5nwKEDK7WroUgGf4knh5DTdbolLZFSS/OXyzDDaC//JmrGnQbs6nsGXk7/yC0=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOnHz-0002Wm-SK; Wed, 15 Apr 2020 19:01:35 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOnHz-0007zR-Gv; Wed, 15 Apr 2020 19:01:35 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOnHz-00057a-CA; Wed, 15 Apr 2020 19:01:35 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149658-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-upstream-4.13-testing test] 149658: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-upstream-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-upstream-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: qemuu=730e2b1927e7d911bbd5350714054ddd5912f4ed
X-Osstest-Versions-That: qemuu=933ebad2470a169504799a1d95b8e410bd9847ef
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 15 Apr 2020 19:01:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail   never pass
 test-amd64-amd64-libvirt-vhd 12 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 qemuu                730e2b1927e7d911bbd5350714054ddd5912f4ed
baseline version:
 qemuu                933ebad2470a169504799a1d95b8e410bd9847ef

Last test of basis   144391  2019-11-29 15:07:52 Z  138 days
Testing same since   149658  2020-04-14 18:08:38 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Adrian Moreno <amorenoz@redhat.com>
  Alberto Garcia <berto@igalia.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christophe Lyon <christophe.lyon@linaro.org>
  Cornelia Huck <cohuck@redhat.com>
  Daniel P. Berrangé <berrange@redhat.com>
  David Hildenbrand <david@redhat.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fan Yang <Fan_Yang@sjtu.edu.cn>
  Gerd Hoffmann <kraxel@redhat.com>
  Guoyi Tu <tu.guoyi@h3c.com>
  Hikaru Nishida <hikarupsp@gmail.com>
  Igor Mammedov <imammedo@redhat.com>
  Jason Wang <jasowang@redhat.com>
  Johannes Berg <johannes.berg@intel.com>
  John Snow <jsnow@redhat.com>
  Kevin Wolf <kwolf@redhat.com>
  Markus Armbruster <armbru@redhat.com>
  Matthew Rosato <mjrosato@linux.ibm.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Maxim Levitsky <mlevitsk@redhat.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Weiser <michael.weiser@gmx.de>
  Mikhail Sennikovsky <mikhail.sennikovskii@cloud.ionos.com>
  Nir Soffer <nirsof@gmail.com>
  Nir Soffer <nsoffer@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Durrant <paul.durrant@citrix.com>
  Paul Durrant <pdurrant@amazon.com>
  Peter Krempa <pkrempa@redhat.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  Prasad J Pandit <pjp@fedoraproject.org>
  Richard Henderson <richard.henderson@linaro.org>
  Sergio Lopez <slp@redhat.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Garzarella <sgarzare@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Tuguoyi <tu.guoyi@h3c.com>
  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  Wei Yang <richardw.yang@linux.intel.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   933ebad247..730e2b1927  730e2b1927e7d911bbd5350714054ddd5912f4ed -> stable-4.13


From xen-devel-bounces@lists.xenproject.org Wed Apr 15 22:42:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Apr 2020 22:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOqjy-0005Pb-56; Wed, 15 Apr 2020 22:42:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=+yDq=57=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOqjx-0005PW-E2
 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 22:42:41 +0000
X-Inumbo-ID: 65b56c8e-7f6a-11ea-8afa-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 65b56c8e-7f6a-11ea-8afa-12813bfff9fa;
 Wed, 15 Apr 2020 22:42:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=8kMngsv/XyJbs2fGZsYxtdzWIypMfCcz4DEbEzvPHD8=; b=MS3VAmZa8n2GyfH2ntPIrVPSR
 R+Gt2fWFXFRmnrsMmjcvl2+xF1B+8SfvyWep3X0FOT63pMg3UX1vgDRTCil/KmN/vU2lnS0AOt8Fi
 4K+LxvZrTvdiaKO/dskig/nBuLT2C9DE0cPv7MniNzGHMH+GyslLS6Zrdrs8CMH/rXZyc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOqjp-0006vI-Hq; Wed, 15 Apr 2020 22:42:33 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOqjp-0003L1-8n; Wed, 15 Apr 2020 22:42:33 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOqjp-00036Z-7k; Wed, 15 Apr 2020 22:42:33 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149659-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149659: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:regression
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=8632e9b5645bbc2331d21d892b0d6961c1a08429
X-Osstest-Versions-That: linux=8f3d9f354286745c751374f5f1fcafee6b3f3136
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 15 Apr 2020 22:42:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine      4 memdisk-try-append       fail REGR. vs. 149632

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149632
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149632
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149632
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149632
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149632
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149632
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149632
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149632
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                8632e9b5645bbc2331d21d892b0d6961c1a08429
baseline version:
 linux                8f3d9f354286745c751374f5f1fcafee6b3f3136

Last test of basis   149632  2020-04-13 01:08:56 Z    2 days
Testing same since   149659  2020-04-14 19:09:17 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  David Howells <dhowells@redhat.com>
  David Sterba <dsterba@suse.com>
  Eugene Syromiatnikov <esyr@redhat.com>
  Filipe Manana <fdmanana@suse.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Gustavo A. R. Silva <gustavo@embeddedor.com>
  Johannes Hirte <johannes.hirte@datenkhaos.de>
  Josef Bacik <josef@toxicpanda.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Olaf Hering <olaf@aepfle.de>
  Tianyu Lan <Tianyu.Lan@microsoft.com>
  Wei Liu <wei.liu@kernel.org>
  YueHaibing <yuehaibing@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 02:07:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 02:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOtwA-0008Ml-RN; Thu, 16 Apr 2020 02:07:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOtw9-0008Mg-GG
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 02:07:29 +0000
X-Inumbo-ID: 0296ba1e-7f87-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0296ba1e-7f87-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 02:07:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=N5VT8TLlFBoCcKIR/LuEwBi6Z6ffFgFfzHn6ABucvDw=; b=OGALSIVzB+wFg0NQE5TSVkiUF
 E1MuPLrTL6SdnBQuR5oSyev9J76evg1KjxK8aQZ5ylp09sWTf4O/QvbSOF+eOSwlhE9/EqbpebHim
 lGEjGdmHqMSBB63R52/qr93Yvkovg+WhfJFqMtM7S4I4mGSj0PmQ7RW54uSmA0fOcn3iI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOtw2-0007k5-L8; Thu, 16 Apr 2020 02:07:22 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOtw2-0004y1-D7; Thu, 16 Apr 2020 02:07:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOtw2-0005IT-CA; Thu, 16 Apr 2020 02:07:22 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149660-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149660: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-saverestore:fail:allowable
 qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=a457215ed2aaa9598bd4ebbc6745d2a494ba9990
X-Osstest-Versions-That: qemuu=14e5526b51910efd62cd31cd95b49baca975c83f
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 02:07:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     15 guest-saverestore        fail REGR. vs. 149641
 test-armhf-armhf-xl-rtds    16 guest-start/debian.repeat fail REGR. vs. 149641

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

version targeted for testing:
 qemuu                a457215ed2aaa9598bd4ebbc6745d2a494ba9990
baseline version:
 qemuu                14e5526b51910efd62cd31cd95b49baca975c83f

Last test of basis   149641  2020-04-14 00:36:57 Z    2 days
Testing same since   149660  2020-04-14 19:36:24 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Peter Maydell <peter.maydell@linaro.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   14e5526b51..a457215ed2  a457215ed2aaa9598bd4ebbc6745d2a494ba9990 -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 04:57:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 04:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOwZx-0005Bg-P8; Thu, 16 Apr 2020 04:56:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOwZw-0005Bb-Bb
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 04:56:44 +0000
X-Inumbo-ID: a6c13c10-7f9e-11ea-8b4d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a6c13c10-7f9e-11ea-8b4d-12813bfff9fa;
 Thu, 16 Apr 2020 04:56:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=VSzrvrMdHjBLk84NFT26Gz4bxmFIFDr9VL0K8DI1WJg=; b=Mh5Te9h9Hgh2JI/6z7gp82awX
 +Lj4QVATtCeReOrdMkNwSI+DdPibZJkdMeexxNrNloVmc9JxjUTj+J3ppxPbiuDnk0ewKVxjUrznH
 OtVSId1jbQxen1XRKsIXCGhN6OmQVZWgcIwARUuG+JLgcfOHE12ZNSc+XZ5uWYamjOj6A=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOwZo-0002en-Gi; Thu, 16 Apr 2020 04:56:36 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOwZo-0006A8-4F; Thu, 16 Apr 2020 04:56:36 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOwZo-0000Mq-3S; Thu, 16 Apr 2020 04:56:36 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149666-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149666: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=a7db0b757d210071d39e6d116e6a4bc761e2ed66
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 04:56:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              a7db0b757d210071d39e6d116e6a4bc761e2ed66
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   89 days
Failing since        146211  2020-01-18 04:18:52 Z   89 days   85 attempts
Testing same since   149666  2020-04-15 04:18:44 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 14730 lines long.)


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 05:05:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 05:05:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOwi1-0006LW-OT; Thu, 16 Apr 2020 05:05:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOwi1-0006LR-AC
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 05:05:05 +0000
X-Inumbo-ID: d1a0d2be-7f9f-11ea-8b4d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d1a0d2be-7f9f-11ea-8b4d-12813bfff9fa;
 Thu, 16 Apr 2020 05:04:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=wdxd0h/Ei5omiMPnQAEQNtpURSzgYBVWFCtFBxQurIc=; b=PpEohbXSxL7vUMLdi9QH1Offy
 V+t7o+iwSmB7ACsAzo3vLbOqrqU57wK2hiyH1iZ6G+cRgZFUmvDIMpsr+lmpyJDZJIOay2/zbCaE9
 EqCyfz78DjFrvwBTm61dCbbfEAymzsQAgTX/OMpBu7qjB1YOnrGxXzMC27gcBI2YK7gJE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOwht-00037x-Ux; Thu, 16 Apr 2020 05:04:58 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOwht-0006fM-Ip; Thu, 16 Apr 2020 05:04:57 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOwht-0004Cr-Ho; Thu, 16 Apr 2020 05:04:57 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149664-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.13-testing test] 149664: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.13-testing:test-amd64-i386-libvirt:guest-start/debian.repeat:fail:heisenbug
 xen-4.13-testing:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 xen-4.13-testing:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=b66ce5058ec9ce84418cedd39b2bf07b7c5a1f65
X-Osstest-Versions-That: xen=736da59cbe2752502ad863b6e71eb83352e22276
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 05:04:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt 18 guest-start/debian.repeat fail in 149647 pass in 149664
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149647

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149604
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 12 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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass

version targeted for testing:
 xen                  b66ce5058ec9ce84418cedd39b2bf07b7c5a1f65
baseline version:
 xen                  736da59cbe2752502ad863b6e71eb83352e22276

Last test of basis   149604  2020-04-10 16:36:52 Z    5 days
Testing same since   149647  2020-04-14 13:06:03 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   736da59cbe..b66ce5058e  b66ce5058ec9ce84418cedd39b2bf07b7c5a1f65 -> stable-4.13


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 05:34:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 05:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOxAN-0000Rq-EG; Thu, 16 Apr 2020 05:34:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jOxAL-0000Rj-Qr
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 05:34:21 +0000
X-Inumbo-ID: ec17cc84-7fa3-11ea-8b4d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ec17cc84-7fa3-11ea-8b4d-12813bfff9fa;
 Thu, 16 Apr 2020 05:34:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=YdR5OD6kf4pD4jE4kSneKDTKRzO/mpKH9hXKiXE9+AQ=; b=SoCLFDmBD5Uw66PEvX1csChD5
 mMlVh/hEkzrNGUSSbaJBCheEEb1BvcIRPtrp0dZyegeueTOLtHW8nz0g5lnagkw4ANHO4JjbEOKSR
 CNP/8e6QwSYq4ddgxg/y5spJYpMeo0fQLQFIQZoOyo6DEvTvri9jBwApANXe8CjgXoSus=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOxAK-0003g3-C5; Thu, 16 Apr 2020 05:34:20 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jOxAK-000818-2M; Thu, 16 Apr 2020 05:34:20 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jOxAK-0005QZ-1a; Thu, 16 Apr 2020 05:34:20 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149665-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149665: all pass - PUSHED
X-Osstest-Versions-This: ovmf=8c654bb3ec0b5232dec2b2b07234c5479eb14d62
X-Osstest-Versions-That: ovmf=bd6aa93296de36c5afabd34e4fa4083bccb8488d
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 05:34:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 8c654bb3ec0b5232dec2b2b07234c5479eb14d62
baseline version:
 ovmf                 bd6aa93296de36c5afabd34e4fa4083bccb8488d

Last test of basis   149638  2020-04-13 10:09:17 Z    2 days
Testing same since   149665  2020-04-15 01:40:25 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Christopher J Zurcher <christopher.j.zurcher@intel.com>
  Zurcher, Christopher J <christopher.j.zurcher@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   bd6aa93296..8c654bb3ec  8c654bb3ec0b5232dec2b2b07234c5479eb14d62 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 07:08:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 07:08:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOydZ-0007rV-Rz; Thu, 16 Apr 2020 07:08:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOydY-0007rQ-Gg
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 07:08:36 +0000
X-Inumbo-ID: 15552954-7fb1-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 15552954-7fb1-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 07:08:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D6455AC85;
 Thu, 16 Apr 2020 07:08:31 +0000 (UTC)
Subject: Re: [PATCH v4 1/4] x86/shim: map and unmap page tables in
 replace_va_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586975587.git.hongyxia@amazon.com>
 <2401b53f39ae0aeb7fac6c207f5f89ff8687338b.1586975587.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <024cc4bc-6b10-dca6-7b85-62446b724fd7@suse.com>
Date: Thu, 16 Apr 2020 09:08:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <2401b53f39ae0aeb7fac6c207f5f89ff8687338b.1586975587.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 20:37, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Also, introduce lYe_from_lXe() macros which do not rely on the direct
> map when walking page tables. Unfortunately, they cannot be inline
> functions due to the header dependency on domain_page.h, so keep them as
> macros just like map_lYt_from_lXe().
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 07:09:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 07:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOye9-0007td-7m; Thu, 16 Apr 2020 07:09:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOye8-0007tV-BZ
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 07:09:12 +0000
X-Inumbo-ID: 2c272060-7fb1-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2c272060-7fb1-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 07:09:12 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6E8AAAC85;
 Thu, 16 Apr 2020 07:09:10 +0000 (UTC)
Subject: Re: [PATCH v4 4/4] x86_64/mm: map and unmap page tables in
 destroy_m2p_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1586975587.git.hongyxia@amazon.com>
 <cd077c5592df0ee1c3568bab1c5e5001946981a9.1586975587.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <46a11c70-5eef-dbaa-cb59-74cd35f22cca@suse.com>
Date: Thu, 16 Apr 2020 09:09:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <cd077c5592df0ee1c3568bab1c5e5001946981a9.1586975587.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 20:37, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 07:19:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 07:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOyoM-0000Oi-9o; Thu, 16 Apr 2020 07:19:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOyoL-0000OZ-8i
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 07:19:45 +0000
X-Inumbo-ID: a472003e-7fb2-11ea-8b5c-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a472003e-7fb2-11ea-8b5c-12813bfff9fa;
 Thu, 16 Apr 2020 07:19:43 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BD113AD4B;
 Thu, 16 Apr 2020 07:19:41 +0000 (UTC)
Subject: Re: [PATCH] x86/boot: Fix early exception handling with
 CONFIG_PERF_COUNTERS
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200415173911.13286-1-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <72b35bfa-e795-72c0-d925-924ca18711df@suse.com>
Date: Thu, 16 Apr 2020 09:19:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415173911.13286-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 Julien Grall <jgrall@amazon.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 19:39, Andrew Cooper wrote:
> The PERFC_INCR() macro uses current->processor, but current is not valid
> during early boot.  This causes the following crash to occur if
> e.g. rdmsr_safe() has to recover from a #GP fault.
> 
>   (XEN) Early fatal page fault at e008:ffff82d0803b1a39 (cr2=0000000000000004, ec=0000)
>   (XEN) ----[ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]----
>   (XEN) CPU:    0
>   (XEN) RIP:    e008:[<ffff82d0803b1a39>] x86_64/entry.S#handle_exception_saved+0x64/0xb8
>   ...
>   (XEN) Xen call trace:
>   (XEN)    [<ffff82d0803b1a39>] R x86_64/entry.S#handle_exception_saved+0x64/0xb8
>   (XEN)    [<ffff82d0806394fe>] F __start_xen+0x2cd/0x2980
>   (XEN)    [<ffff82d0802000ec>] F __high_start+0x4c/0x4e
> 
> Furthermore, the PERFC_INCR() macro is wildly inefficient.  There has been a
> single caller for many releases now, so inline it and delete the macro
> completely.
> 
> For the assembly, move entry_vector from %eax into %ecx.  There is no encoding
> benefit for movzbl, and it frees up %eax to be used inside the
> CONFIG_PERF_COUNTERS block where there is an encoding benefit.

I don't mind the change in register use, but I'd certainly like to
understand the supposed "encoding benefit". Afaics ...

> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -677,10 +677,14 @@ handle_exception_saved:
>  #endif /* CONFIG_PV */
>          sti
>  1:      movq  %rsp,%rdi
> -        movzbl UREGS_entry_vector(%rsp),%eax
> +        movzbl UREGS_entry_vector(%rsp), %ecx
>          leaq  exception_table(%rip),%rdx
> -        PERFC_INCR(exceptions, %rax, %rbx)
> -        mov   (%rdx, %rax, 8), %rdx
> +#ifdef CONFIG_PERF_COUNTERS
> +        lea   per_cpu__perfcounters(%rip), %rax
> +        add   STACK_CPUINFO_FIELD(per_cpu_offset)(%r14), %rax
> +        incl  ASM_PERFC_exceptions * 4(%rax, %rcx, 4)
> +#endif

... all insns inside the block use a ModR/M byte, and there's also
no special SIB encoding form used (i.e. one where the disp size
would increase because of register choice).

With this clarified, i.e. possibly the commit message updated
accordingly, and possibly even code churn reduced by undoing the
change of register used,
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 07:36:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 07:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOz4Q-00020V-QN; Thu, 16 Apr 2020 07:36:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOz4P-00020P-BX
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 07:36:21 +0000
X-Inumbo-ID: f663a076-7fb4-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f663a076-7fb4-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 07:36:19 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D4549AD1E;
 Thu, 16 Apr 2020 07:36:17 +0000 (UTC)
Subject: Re: [XEN PATCH v4 12/18] xen/build: factorise generation of the
 linker scripts
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-13-anthony.perard@citrix.com>
 <af0121cc-c282-ceb0-b5e8-44ac0ba6ebfb@suse.com>
 <20200415165832.GE4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6001a8a3-aed6-0e74-f82d-823853e44483@suse.com>
Date: Thu, 16 Apr 2020 09:36:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415165832.GE4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 18:58, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 02:46:42PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>>     - avoid using "define" for cmd_cc_lds_S, as adding '; \' on each line is
>>>       still mandatory for if_changed (or cmd) macro to work.
>>
>> I still don't believe in there being a need for "; \" there. This
>> actually breaks things, after all:
>>
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -236,6 +236,12 @@ cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
>>>  %.s: %.S FORCE
>>>  	$(call if_changed,cpp_s_S)
>>>  
>>> +# Linker scripts, .lds.S -> .lds
>>> +quiet_cmd_cc_lds_S = LDS     $@
>>> +cmd_cc_lds_S = $(CPP) -P $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<; \
>>> +    sed -e 's/.*\.lds\.o:/$(@F):/g' <$(dot-target).d >$(dot-target).d.new; \
>>> +    mv -f $(dot-target).d.new $(dot-target).d
>>
>> if $(CPP) or sed fail, previously the whole rule would have failed,
>> which no longer is the case with your use of semicolons. There
>> ought to be a solution to this, ideally one better than adding
>> "set -e" as the first command ("define" would at least deal with
>> the multi-line make issue, but without it being clear to me why the
>> semicolons would be needed I don't think I can suggest anything
>> there at the moment).
> 
> The only macro that will consumes cmd_cc_lds_S (and other cmd_*) is
> "cmd", it is defined as:
>     cmd = @set -e; $(echo-cmd) $(cmd_$(1))
> So, "set -e" is already there, and using semicolons in commands is
> equivalent to using "&&".
> 
> With "cmd" alone, multi-line command would work as expected (unless
> $(echo-cmd) is is trying to print the command line).
> 
> It's "if_changed" macro that doesn't work with multi-line commands.
> It does:
>     $(cmd); printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd
> With a multiple line command, $(make-cmd) get's expanded to multiple
> line, so the second argument of "printf" is going to be spread over
> multiple line in make, and thus multiple shell. We run into this error:
>     /bin/sh: -c: line 0: unexpected EOF while looking for matching `''
>     /bin/sh: -c: line 1: syntax error: unexpected end of file
> 
> This is why we need to have commands on a single line.
> 
> I hope the explanation is clear enough.

Yes, thanks. One question remains though: Why do we need multiple
commands here in the first place, when Linux gets away with one?

Two other remarks: For one the command's name, aiui, ought to be
cmd_cpp_lds_S (see Linux). And there ought to be cpp_flags, which
would then also be used by e.g. cmd_s_S (instead of both having
$(filter-out -Wa$(comma)%,$(a_flags)) open-coded).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 08:19:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 08:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOzkM-0005qM-W6; Thu, 16 Apr 2020 08:19:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HCIP=6A=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jOzkL-0005qH-UO
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 08:19:42 +0000
X-Inumbo-ID: 048bcee8-7fbb-11ea-b4f4-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 048bcee8-7fbb-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 08:19:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587025180;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=0ixsc0CzeYa9zcT53ZlBUs1gmBMK2SR725xlwyoE4ZM=;
 b=eVYBkwBev+9fNMKU2Tid7Fzc4QLU3r1PDsdHJ8NFm1s8ZWeKUg1DFgJT
 1uXYl+9VJJTgH8/oHi2qF0LHuNdBGcaQM8+34eOx7/yc02EVNpaELz9Ni
 Lft7H3mQZCZW+7dYNHhOAxiE48ZTq0I1yHFOXRWS+2LM73fkbficXAIUD k=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: /bAA3odhOw10A5EzH+a+1ebWjyrYZhaSwwTURssJnoQp+Bh1rM9tld+zkkliewSayEVB+Vb7k2
 4bAKPynN0BfD22egjxFhxXmt3B1G6jWIj5DqA6q9IiYkUr0y9VekVebFUqhX40uqetL5zo5/6l
 3YD8CAtOM4+XbvTAk2uy5nHsRnr7MDIluQfx1cT0LacvQKINJ3WQwak+YCzh7t4uPXJTRgb3zF
 ZApKluZahbesdr3I/jqk42rFD4MwLs+kuHs3jdBjf0SwbHg0ifn86mSBH7jbBFre7cNEYuFn4q
 IaI=
X-SBRS: 2.7
X-MesageID: 16165154
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,390,1580792400"; d="scan'208";a="16165154"
Subject: Re: [PATCH] x86/boot: Fix early exception handling with
 CONFIG_PERF_COUNTERS
To: Jan Beulich <jbeulich@suse.com>
References: <20200415173911.13286-1-andrew.cooper3@citrix.com>
 <72b35bfa-e795-72c0-d925-924ca18711df@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <4c418f62-14b5-1f77-9bf3-979b5d1f56d9@citrix.com>
Date: Thu, 16 Apr 2020 09:19:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <72b35bfa-e795-72c0-d925-924ca18711df@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 Julien Grall <jgrall@amazon.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 08:19, Jan Beulich wrote:
> On 15.04.2020 19:39, Andrew Cooper wrote:
>> The PERFC_INCR() macro uses current->processor, but current is not valid
>> during early boot.  This causes the following crash to occur if
>> e.g. rdmsr_safe() has to recover from a #GP fault.
>>
>>   (XEN) Early fatal page fault at e008:ffff82d0803b1a39 (cr2=0000000000000004, ec=0000)
>>   (XEN) ----[ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]----
>>   (XEN) CPU:    0
>>   (XEN) RIP:    e008:[<ffff82d0803b1a39>] x86_64/entry.S#handle_exception_saved+0x64/0xb8
>>   ...
>>   (XEN) Xen call trace:
>>   (XEN)    [<ffff82d0803b1a39>] R x86_64/entry.S#handle_exception_saved+0x64/0xb8
>>   (XEN)    [<ffff82d0806394fe>] F __start_xen+0x2cd/0x2980
>>   (XEN)    [<ffff82d0802000ec>] F __high_start+0x4c/0x4e
>>
>> Furthermore, the PERFC_INCR() macro is wildly inefficient.  There has been a
>> single caller for many releases now, so inline it and delete the macro
>> completely.
>>
>> For the assembly, move entry_vector from %eax into %ecx.  There is no encoding
>> benefit for movzbl, and it frees up %eax to be used inside the
>> CONFIG_PERF_COUNTERS block where there is an encoding benefit.
> I don't mind the change in register use, but I'd certainly like to
> understand the supposed "encoding benefit". Afaics ...
>
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -677,10 +677,14 @@ handle_exception_saved:
>>  #endif /* CONFIG_PV */
>>          sti
>>  1:      movq  %rsp,%rdi
>> -        movzbl UREGS_entry_vector(%rsp),%eax
>> +        movzbl UREGS_entry_vector(%rsp), %ecx
>>          leaq  exception_table(%rip),%rdx
>> -        PERFC_INCR(exceptions, %rax, %rbx)
>> -        mov   (%rdx, %rax, 8), %rdx
>> +#ifdef CONFIG_PERF_COUNTERS
>> +        lea   per_cpu__perfcounters(%rip), %rax
>> +        add   STACK_CPUINFO_FIELD(per_cpu_offset)(%r14), %rax
>> +        incl  ASM_PERFC_exceptions * 4(%rax, %rcx, 4)
>> +#endif
> ... all insns inside the block use a ModR/M byte, and there's also
> no special SIB encoding form used (i.e. one where the disp size
> would increase because of register choice).

Hmm - I suppose it is stale, written for an older version of the logic
before I spotted a further optimisation.

> With this clarified, i.e. possibly the commit message updated
> accordingly, and possibly even code churn reduced by undoing the
> change of register used,

Leaving %eax as was, and using %rdi for the single temporary looks like:

diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 997c481ecb..1984bb7948 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -679,7 +679,11 @@ handle_exception_saved:
 1:      movq  %rsp,%rdi
         movzbl UREGS_entry_vector(%rsp),%eax
         leaq  exception_table(%rip),%rdx
-        PERFC_INCR(exceptions, %rax, %rbx)
+#ifdef CONFIG_PERF_COUNTERS
+        lea   per_cpu__perfcounters(%rip), %rdi
+        add   STACK_CPUINFO_FIELD(per_cpu_offset)(%r14), %rdi
+        incl  ASM_PERFC_exceptions * 4(%rdi, %rax, 4)
+#endif
         mov   (%rdx, %rax, 8), %rdx
         INDIRECT_CALL %rdx
         mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)


If you're happy with that?

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 08:34:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 08:34:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOzyF-0007Ru-Me; Thu, 16 Apr 2020 08:34:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=FuWY=6A=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jOzyE-0007Rm-Qc
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 08:34:02 +0000
X-Inumbo-ID: 05f25732-7fbd-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 05f25732-7fbd-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 08:34:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=5rwClm+Zgtmmy4ztGRUQ5EJ3hSqUkJhruPU33x8OK9U=; b=zB/xDfUVKw75+nC3KYbUWUXn7u
 FC/L4uVg8CHqoYa7cmGVfqcLdC9Di1oNEby7Ks4dhmMsKE7ayxO7eRnQplV5yQVhkClbHQi/5lmXP
 zfLEYBtK4YxbB/oEUJ73oEq9V5mMYO+A1xh72ybD+bYZR0D8AFLJ5ULF/b9WQH1azk8M=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOzyA-0007g2-UV; Thu, 16 Apr 2020 08:33:58 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jOzyA-0006FQ-NK; Thu, 16 Apr 2020 08:33:58 +0000
Subject: Re: [PATCH] x86/boot: Fix early exception handling with
 CONFIG_PERF_COUNTERS
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20200415173911.13286-1-andrew.cooper3@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <1123ff61-4e82-26dc-6727-d6a877f3723d@xen.org>
Date: Thu, 16 Apr 2020 09:33:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415173911.13286-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <jgrall@amazon.com>, Jan Beulich <JBeulich@suse.com>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Andrew,

On 15/04/2020 18:39, Andrew Cooper wrote:
> The PERFC_INCR() macro uses current->processor, but current is not valid
> during early boot.  This causes the following crash to occur if
> e.g. rdmsr_safe() has to recover from a #GP fault.
> 
>    (XEN) Early fatal page fault at e008:ffff82d0803b1a39 (cr2=0000000000000004, ec=0000)
>    (XEN) ----[ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]----
>    (XEN) CPU:    0
>    (XEN) RIP:    e008:[<ffff82d0803b1a39>] x86_64/entry.S#handle_exception_saved+0x64/0xb8
>    ...
>    (XEN) Xen call trace:
>    (XEN)    [<ffff82d0803b1a39>] R x86_64/entry.S#handle_exception_saved+0x64/0xb8
>    (XEN)    [<ffff82d0806394fe>] F __start_xen+0x2cd/0x2980
>    (XEN)    [<ffff82d0802000ec>] F __high_start+0x4c/0x4e
> 
> Furthermore, the PERFC_INCR() macro is wildly inefficient.  There has been a
> single caller for many releases now, so inline it and delete the macro
> completely.
> 
> For the assembly, move entry_vector from %eax into %ecx.  There is no encoding
> benefit for movzbl, and it frees up %eax to be used inside the
> CONFIG_PERF_COUNTERS block where there is an encoding benefit.
> 
> There is no need to reference current at all.  What is actually needed is the
> per_cpu_offset which can be obtained directly from the top-of-stack block.
> This simplifies the counter handling to 3 instructions and no spilling to the
> stack at all.
> 
> The same breakage from above is now handled properly:
> 
>    (XEN) traps.c:1591: GPF (0000): ffff82d0806394fe [__start_xen+0x2cd/0x2980] -> ffff82d0803b3bfb
> 
> Reported-by: Julien Grall <jgrall@amazon.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

I can confirm the crash I have seen has now disappeared.

Tested-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 08:34:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 08:34:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOzyC-0007RL-7v; Thu, 16 Apr 2020 08:34:00 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Wvvh=6A=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jOzyA-0007RG-EN
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 08:33:58 +0000
X-Inumbo-ID: 029ead9c-7fbd-11ea-8b65-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 029ead9c-7fbd-11ea-8b65-12813bfff9fa;
 Thu, 16 Apr 2020 08:33:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587026037;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=NgXOvquez9U/cttLx9tqkxe4NTlWEYntfETsT8qIthM=;
 b=YroKZK1GiHIPkdz9zNq6WdqKdZzvKWCGXg9zMBAKSVbw1rffsmG1atEs
 96nzUmoBLjCaw0sQnngC0XgoUIp3Pn65Db8wyxjOjjxA3N9VMIDqeyWf2
 9WB8T6CfqBS7TIrMRh9DzbNTyWxW5klkWrGcR35kXPB42mR36p1qckvSc o=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: u2M5NzuNL1QYGylOCtwnH8eWYCiSA4I8BdR2hGXE8UawawyirMNLVcgCwgCYEij9X4ENyh/7mT
 YQVo0aq4bUOpV+nfZ9Zb6MZS4wmvurkzF0hw9TYoueR6C9enRLaBQVwybobd9jE6ockvyve5PU
 T3tMcTW7iZ/tcgj4kCgR8+EdwgJOZL58eDP55EbKZpUw+4upqDhfy4Q4Y8cfpYVvqzbGH4UYez
 cikYAnCSvtcHpRYq39BvQwjwjbbXePPjm/IZ+UdqZ4t7fw3Xp48E3IzwX3Jv6Wpes5DNynLwtE
 Kc8=
X-SBRS: 2.7
X-MesageID: 15778273
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,390,1580792400"; d="scan'208";a="15778273"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH] sched: print information about scheduler granularity
Date: Thu, 16 Apr 2020 09:33:41 +0100
Message-ID: <20200416083341.21122-1-sergey.dyasli@citrix.com>
X-Mailer: git-send-email 2.17.1
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sergey Dyasli <sergey.dyasli@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Currently it might be not obvious which scheduling mode is being used
by the scheduler. Alleviate this by printing additional information
about the selected granularity. Messages now look like these:

1. boot
(XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler (credit) in core-scheduling mode

2. xl debug-keys r
(XEN) [   45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-way core-scheduling mode

Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
---
CC: Juergen Gross <jgross@suse.com>
CC: Dario Faggioli <dfaggioli@suse.com>
CC: George Dunlap <george.dunlap@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
---
 xen/common/sched/core.c    | 10 ++++++++--
 xen/common/sched/cpupool.c | 30 +++++++++++++++++++++++++++++-
 xen/common/sched/private.h |  2 ++
 3 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d4a6489929..b1b09a159b 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2883,6 +2883,7 @@ void scheduler_enable(void)
 void __init scheduler_init(void)
 {
     struct domain *idle_domain;
+    char sched_gran[20];
     int i;
 
     scheduler_enable();
@@ -2937,7 +2938,9 @@ void __init scheduler_init(void)
         BUG();
     register_cpu_notifier(&cpu_schedule_nfb);
 
-    printk("Using scheduler: %s (%s)\n", ops.name, ops.opt_name);
+    printk("Using scheduler: %s (%s) in %s-scheduling mode\n",
+           ops.name, ops.opt_name,
+           sched_gran_str(sched_gran, sizeof(sched_gran)));
     if ( sched_init(&ops) )
         panic("scheduler returned error on init\n");
 
@@ -3267,6 +3270,7 @@ void schedule_dump(struct cpupool *c)
     unsigned int      i, j;
     struct scheduler *sched;
     cpumask_t        *cpus;
+    char              sched_gran[20];
 
     /* Locking, if necessary, must be handled withing each scheduler */
 
@@ -3276,7 +3280,9 @@ void schedule_dump(struct cpupool *c)
     {
         sched = c->sched;
         cpus = c->res_valid;
-        printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
+        printk("Scheduler: %s (%s) in %s-scheduling mode\n",
+               sched->name, sched->opt_name,
+               sched_gran_str(sched_gran, sizeof(sched_gran)));
         sched_dump_settings(sched);
     }
     else
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index d40345b585..a37b97f4c2 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -38,7 +38,35 @@ static cpumask_t cpupool_locked_cpus;
 static DEFINE_SPINLOCK(cpupool_lock);
 
 static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
-static unsigned int __read_mostly sched_granularity = 1;
+static unsigned int __read_mostly sched_granularity;
+
+char *sched_gran_str(char *str, size_t size)
+{
+    char *mode = "";
+
+    switch ( opt_sched_granularity )
+    {
+    case SCHED_GRAN_cpu:
+        mode = "cpu";
+        break;
+    case SCHED_GRAN_core:
+        mode = "core";
+        break;
+    case SCHED_GRAN_socket:
+        mode = "socket";
+        break;
+    default:
+        ASSERT_UNREACHABLE();
+        break;
+    }
+
+    if ( sched_granularity )
+        snprintf(str, size, "%u-way %s", sched_granularity, mode);
+    else
+        snprintf(str, size, "%s", mode);
+
+    return str;
+}
 
 #ifdef CONFIG_HAS_SCHED_GRANULARITY
 static int __init sched_select_granularity(const char *str)
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index 367811a12f..fd49f545cb 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -30,6 +30,8 @@ enum sched_gran {
     SCHED_GRAN_socket
 };
 
+char *sched_gran_str(char *str, size_t size);
+
 /*
  * In order to allow a scheduler to remap the lock->cpu mapping,
  * we have a per-cpu pointer, along with a pre-allocated set of
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 08:35:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 08:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jOzzv-0007cu-43; Thu, 16 Apr 2020 08:35:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jOzzu-0007co-94
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 08:35:46 +0000
X-Inumbo-ID: 43b92f28-7fbd-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 43b92f28-7fbd-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 08:35:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A635CAC4D;
 Thu, 16 Apr 2020 08:35:43 +0000 (UTC)
Subject: Re: [PATCH] x86/boot: Fix early exception handling with
 CONFIG_PERF_COUNTERS
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200415173911.13286-1-andrew.cooper3@citrix.com>
 <72b35bfa-e795-72c0-d925-924ca18711df@suse.com>
 <4c418f62-14b5-1f77-9bf3-979b5d1f56d9@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <88658e82-e38a-6230-e6ab-7cfd00e4f19f@suse.com>
Date: Thu, 16 Apr 2020 10:35:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <4c418f62-14b5-1f77-9bf3-979b5d1f56d9@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 Julien Grall <jgrall@amazon.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.2020 10:19, Andrew Cooper wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -679,7 +679,11 @@ handle_exception_saved:
>  1:      movq  %rsp,%rdi
>          movzbl UREGS_entry_vector(%rsp),%eax
>          leaq  exception_table(%rip),%rdx
> -        PERFC_INCR(exceptions, %rax, %rbx)
> +#ifdef CONFIG_PERF_COUNTERS
> +        lea   per_cpu__perfcounters(%rip), %rdi
> +        add   STACK_CPUINFO_FIELD(per_cpu_offset)(%r14), %rdi
> +        incl  ASM_PERFC_exceptions * 4(%rdi, %rax, 4)
> +#endif
>          mov   (%rdx, %rax, 8), %rdx
>          INDIRECT_CALL %rdx
>          mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
> 
> 
> If you're happy with that?

I'm afraid I'm not - you can't use %rdi here, it already holds the
called function's argument. I'd be fine with %rcx used instead.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 08:48:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 08:48:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP0Bj-00008c-Bd; Thu, 16 Apr 2020 08:47:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HCIP=6A=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jP0Bh-00008X-O8
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 08:47:57 +0000
X-Inumbo-ID: f76fe4e9-7fbe-11ea-8b67-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f76fe4e9-7fbe-11ea-8b67-12813bfff9fa;
 Thu, 16 Apr 2020 08:47:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587026877;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=7v9/wyFbbQVkew1cNcrXu3u97mvWC0o4T7Is622nKEQ=;
 b=JmuCRwsltPAkGu+FghcvBbMvhbth3PdHpcrlCzffqimMh/AMIn2KQWwz
 MrAvUAuOVh8e2BIK1Ydyaya5N1yeTebl73ErMf948mxikrOCgVjwEacsv
 roKMPuRZWNwIKyg6UDi7tmpSVZ1mb3KgpYf37lfHaWn/FTeWF1WEBzxI/ o=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: H/pYgj6NmDPIOA1l6Jl6wOnlNcJBkEqnZdQ4EZcAOydIgk32WMCiPSNbk1+VRhDQeiXqnn2v9h
 u7x1sSd7WjKyNvzxF2PskcVBizIGqiuT7MV7OZVykWupU/N1LjA6uW0k7kP2U1jQa+3EOE6jj3
 NuwTNN2MrybPoEpL+adQulJ/K0WPs8P2p5BSHINKH44Wr9sfA0H6h6/XymdXXI7No0rvdBBbBx
 YiB8JGttoH9r7kMFIZbciHiFjyMVIN5dBCK6OqndKIEkO4qPjOLeihLPfOdHjShJVo9OMJxyQx
 A4Y=
X-SBRS: 2.7
X-MesageID: 16440388
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,390,1580792400"; d="scan'208";a="16440388"
Subject: Re: [PATCH] x86/boot: Fix early exception handling with
 CONFIG_PERF_COUNTERS
To: Jan Beulich <jbeulich@suse.com>
References: <20200415173911.13286-1-andrew.cooper3@citrix.com>
 <72b35bfa-e795-72c0-d925-924ca18711df@suse.com>
 <4c418f62-14b5-1f77-9bf3-979b5d1f56d9@citrix.com>
 <88658e82-e38a-6230-e6ab-7cfd00e4f19f@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <17d1e29a-ea6e-93f1-1fa8-393e0cd8da23@citrix.com>
Date: Thu, 16 Apr 2020 09:47:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <88658e82-e38a-6230-e6ab-7cfd00e4f19f@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 Julien Grall <jgrall@amazon.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 09:35, Jan Beulich wrote:
> On 16.04.2020 10:19, Andrew Cooper wrote:
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -679,7 +679,11 @@ handle_exception_saved:
>>  1:      movq  %rsp,%rdi
>>          movzbl UREGS_entry_vector(%rsp),%eax
>>          leaq  exception_table(%rip),%rdx
>> -        PERFC_INCR(exceptions, %rax, %rbx)
>> +#ifdef CONFIG_PERF_COUNTERS
>> +        lea   per_cpu__perfcounters(%rip), %rdi
>> +        add   STACK_CPUINFO_FIELD(per_cpu_offset)(%r14), %rdi
>> +        incl  ASM_PERFC_exceptions * 4(%rdi, %rax, 4)
>> +#endif
>>          mov   (%rdx, %rax, 8), %rdx
>>          INDIRECT_CALL %rdx
>>          mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
>>
>>
>> If you're happy with that?
> I'm afraid I'm not - you can't use %rdi here, it already holds the
> called function's argument. I'd be fine with %rcx used instead.

Bah - serves me right for being lazy and not retesting.

%rcx it is.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 08:58:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 08:58:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP0LM-00011q-G6; Thu, 16 Apr 2020 08:57:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fNsn=6A=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jP0LL-00011l-CR
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 08:57:55 +0000
X-Inumbo-ID: 5ba42716-7fc0-11ea-8b69-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5ba42716-7fc0-11ea-8b69-12813bfff9fa;
 Thu, 16 Apr 2020 08:57:54 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6ED2AAD60;
 Thu, 16 Apr 2020 08:57:52 +0000 (UTC)
Subject: Re: [PATCH] sched: print information about scheduler granularity
To: Sergey Dyasli <sergey.dyasli@citrix.com>, xen-devel@lists.xenproject.org
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <996ed66e-3782-5187-a804-9291741a2241@suse.com>
Date: Thu, 16 Apr 2020 10:57:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200416083341.21122-1-sergey.dyasli@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.20 10:33, Sergey Dyasli wrote:
> Currently it might be not obvious which scheduling mode is being used
> by the scheduler. Alleviate this by printing additional information
> about the selected granularity. Messages now look like these:
> 
> 1. boot
> (XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler (credit) in core-scheduling mode
> 
> 2. xl debug-keys r
> (XEN) [   45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-way core-scheduling mode
> 
> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>

Hmm, do we need that?

The xen commandline ins part of the boot messages and is contained
in the "xl info" output.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 08:59:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 08:59:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP0N1-00018P-UI; Thu, 16 Apr 2020 08:59:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=FuWY=6A=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jP0N0-00018G-Iv
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 08:59:38 +0000
X-Inumbo-ID: 999ab0a8-7fc0-11ea-8b69-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 999ab0a8-7fc0-11ea-8b69-12813bfff9fa;
 Thu, 16 Apr 2020 08:59:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/TqZOft4RGfERk+H5s4rfyuDHaBPVm0OwmJ0sXepDpA=; b=ooXQYAgs8csaj+aTRKxynXvhwj
 xGF91o5po60r3VN4H4DVa1KuM1mUGN4Y4p2hgKxxsnaznZd7oRSzOhzEwAjW5Pc5IHRXKZ3Rnm8UG
 ENy8vRVRjZzIe9/4NPDJ7hs9Fl9LjIbO4WJxCdkwuhZzKrXb3+aaMofFDjgxM4qle6GI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jP0Ms-0008Ad-Bi; Thu, 16 Apr 2020 08:59:30 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jP0Ms-0000MV-2r; Thu, 16 Apr 2020 08:59:30 +0000
Subject: Re: [PATCH 0/12] direct-map DomUs
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <4a62c7c1-710f-21a9-a6cc-03aa290e18b1@xen.org>
Date: Thu, 16 Apr 2020 09:59:27 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Artem_Mygaiev@epam.com, peng.fan@nxp.com, andrew.cooper3@citrix.com,
 George.Dunlap@citrix.com, Bertrand.Marquis@arm.com, jbeulich@suse.com,
 Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 15/04/2020 02:02, Stefano Stabellini wrote:
> Hi all,
> 
> This series adds support for 1:1 mapping (guest physical == physical)
> the memory of dom0less domUs. The memory ranges assigned to a domU can be
> explicitly chosen by the user at boot time.
> 
> This is desirable in cases where an IOMMU is not present in the system,
> or it cannot be used. For instance, it might not be usable because it
> doesn't cover a specific device, or because it doesn't have enough
> bandwidth, or because it adds too much latency. In these cases, the user
> should use a MPU to protect the memory in the system (e.g. the Xilinx
> XMPU), configuring it with the chosen address ranges.
> 
> Cheers,
> 
> Stefano
> 
> 
> 
> The following changes since commit 7372466b21c3b6c96bb7a52754e432bac883a1e3:
> 
>    x86/mem_sharing: Fix build with !CONFIG_XSM (2020-04-10 15:20:10 +0100)
> 
> are available in the Git repository at:
> 
>    http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git direct-map-1
> 
> for you to fetch changes up to 43503720ab6851a28a66fdd067f592d5354ae83a:
> 
>    xen/arm: call iomem_permit_access for passthrough devices (2020-04-14 17:42:21 -0700)
> 
> ----------------------------------------------------------------
> Stefano Stabellini (12):
>        xen: introduce xen_dom_flags
>        xen/arm: introduce arch_xen_dom_flags and direct_map
>        xen/arm: introduce 1:1 mapping for domUs
>        xen: split alloc_heap_pages in two halves for reusability
>        xen: introduce reserve_heap_pages
>        xen/arm: reserve 1:1 memory for direct_map domUs
>        xen/arm: new vgic: rename vgic_cpu/dist_base to c/dbase
>        xen/arm: if is_domain_direct_mapped use native addresses for GICv2
>        xen/arm: if is_domain_direct_mapped use native addresses for GICv3
>        xen/arm: if is_domain_direct_mapped use native UART address for vPL011

The 3 patches above cover addresses but not interrupts. Why?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 09:21:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 09:21:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP0hZ-0003bZ-7k; Thu, 16 Apr 2020 09:20:53 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Wvvh=6A=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jP0hX-0003b2-4o
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 09:20:51 +0000
X-Inumbo-ID: 8f533523-7fc3-11ea-8b6a-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8f533523-7fc3-11ea-8b6a-12813bfff9fa;
 Thu, 16 Apr 2020 09:20:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587028850;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=MZ/72IIf4ZOogYqkPGju9A5rEBvyFOlbgvjO5ryjWfg=;
 b=P6Sx+PvCeSA0JT+uMM4te0Th/mF0tavV8cnSENJmgokIoU94lEYwdeCp
 U11OYmyMU6aXHgZXAnwtyGq64RW9XYDTW4dn7uvEiF4iN0c+Rx5NxxiLn
 ao62Xw98wWchJOweHe1rCqa94YE2qvBrhUYv3ChOaMJxWyHX18jCZJBum Y=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 1b7aK2QxUkoXgCS3e9fw3AfcRnXNB2p6iUum9NTnGdPwnTFtNpoNZyfn/doYkjN5fWpzlta7sI
 J0y+ioLQEDR1NrH0+PTQXwTZOp7hLeRC9SS55d5q61UYnCAo158tyb/ZXpbr4uxUIxM/aV9OQo
 sZZjwC9b4/4EX9+IqX/Q7IPfbxeidcgiXISvbABYp3c4bgXrr4bLkXMbxVd/dYte0mpkUHHFqP
 Bfr8dfRVVcn1CtNVv4iNeWrROQRXi7jZRbNzMVtO24r6qj3DXkhdwkELkLNGP37/OzdIZBiGY6
 2Ys=
X-SBRS: 2.7
X-MesageID: 15780082
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,390,1580792400"; d="scan'208";a="15780082"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] sched: print information about scheduler granularity
Thread-Topic: [PATCH] sched: print information about scheduler granularity
Thread-Index: AQHWE8nCYlq/J4KoL0iU4gkSoIElX6h7UR4AgAAWygA=
Date: Thu, 16 Apr 2020 09:20:45 +0000
Message-ID: <1587028832608.72974@citrix.com>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <996ed66e-3782-5187-a804-9291741a2241@suse.com>
In-Reply-To: <996ed66e-3782-5187-a804-9291741a2241@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-imapappendstamp: AMSPEX02CL03.citrite.net (15.00.1497.006)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <87E26F5B6704684C9B6C1280419A4926@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Sergey Dyasli <sergey.dyasli@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 09:57, J=FCrgen Gro=DF wrote:=0A=
> On 16.04.20 10:33, Sergey Dyasli wrote:=0A=
>> Currently it might be not obvious which scheduling mode is being used=0A=
>> by the scheduler. Alleviate this by printing additional information=0A=
>> about the selected granularity. Messages now look like these:=0A=
>>=0A=
>> 1. boot=0A=
>> (XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler (credit) =
in core-scheduling mode=0A=
>>=0A=
>> 2. xl debug-keys r=0A=
>> (XEN) [=A0=A0 45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-w=
ay core-scheduling mode=0A=
>>=0A=
>> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>=0A=
> =0A=
> Hmm, do we need that?=0A=
> =0A=
> The xen commandline ins part of the boot messages and is contained=0A=
> in the "xl info" output.=0A=
=0A=
It's true that you can see "sched-gran=3Dcore" in "xl info" output. But tha=
t's=0A=
just the switch - not the end result. A user might want to verify that he d=
id=0A=
everything correctly and core-scheduling mode has indeed been enabled.=0A=
=0A=
--=0A=
Thanks,=0A=
Sergey=0A=
=0A=


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 09:25:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 09:25:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP0mL-0003kz-T1; Thu, 16 Apr 2020 09:25:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fNsn=6A=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jP0mK-0003ku-KQ
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 09:25:48 +0000
X-Inumbo-ID: 4149e7bc-7fc4-11ea-8b6b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4149e7bc-7fc4-11ea-8b6b-12813bfff9fa;
 Thu, 16 Apr 2020 09:25:47 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 59767AEB9;
 Thu, 16 Apr 2020 09:25:46 +0000 (UTC)
Subject: Re: [PATCH] sched: print information about scheduler granularity
To: Sergey Dyasli <sergey.dyasli@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <996ed66e-3782-5187-a804-9291741a2241@suse.com>
 <1587028832608.72974@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <bd38c4da-b982-0d13-bdbd-ab363dae68e0@suse.com>
Date: Thu, 16 Apr 2020 11:25:46 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <1587028832608.72974@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.20 11:20, Sergey Dyasli wrote:
> On 16/04/2020 09:57, Jürgen Groß wrote:
>> On 16.04.20 10:33, Sergey Dyasli wrote:
>>> Currently it might be not obvious which scheduling mode is being used
>>> by the scheduler. Alleviate this by printing additional information
>>> about the selected granularity. Messages now look like these:
>>>
>>> 1. boot
>>> (XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler (credit) in core-scheduling mode
>>>
>>> 2. xl debug-keys r
>>> (XEN) [   45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-way core-scheduling mode
>>>
>>> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
>>
>> Hmm, do we need that?
>>
>> The xen commandline ins part of the boot messages and is contained
>> in the "xl info" output.
> 
> It's true that you can see "sched-gran=core" in "xl info" output. But that's
> just the switch - not the end result. A user might want to verify that he did
> everything correctly and core-scheduling mode has indeed been enabled.

I'm planning to add this information in the pending hypfs (per cpupool).

I'm not opposed to your patch, but as soon as we have per-cpupool
granularity it should be reverted again.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 09:38:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 09:38:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP0yf-0004hk-8N; Thu, 16 Apr 2020 09:38:33 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Wvvh=6A=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jP0ye-0004he-6t
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 09:38:32 +0000
X-Inumbo-ID: 0852acee-7fc6-11ea-8b6d-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0852acee-7fc6-11ea-8b6d-12813bfff9fa;
 Thu, 16 Apr 2020 09:38:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587029911;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=um4CYpM/aGGIm54gur/4JoCcsorEfvmkqorHGGSv+J8=;
 b=H90mztX7rD570/yiOhFNhjfSPoz/LGEUsmHIRo1xXagOfySlYCMQUXvc
 t28pUNr5lJf/PWU/Naq3WKMllJ5quIvs+xUVtfK+aa3pLT406b3GJhWXN
 jumwtrB9xNb0a2zO6kqlrNvC6HHisONTc62XkqOCUCtYK8fmDEXbMKTQV I=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 7rhV4FwIG4X8WnGhEXBXNLrLSg8V4FMaFfaw5MmSB0UBMd+cg0mjluospN15akAqQz+vz3kZQ7
 FrL2yEhdtfP6zmBBLQch73DrFzryy/QVfn00TMlPnqOxz7ksyLXDqLlWB0SRTP12FCACrL3rgR
 fsdBkT1eeuqvNIfmA5nzvQAC4hzJ5eF3htKZ3RPfaU4BIDx3ttigVyeHM02glWBEnAkgR0QNPn
 LiUzGxrAvXanN8Sklp+WizGT/O38nxZl5s09YpjN81NKLfe+uaGzpHCdVOn9y8bHZbrBxjz/hY
 pqM=
X-SBRS: 2.7
X-MesageID: 16168094
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,390,1580792400"; d="scan'208";a="16168094"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] sched: print information about scheduler granularity
Thread-Topic: [PATCH] sched: print information about scheduler granularity
Thread-Index: AQHWE8nCYlq/J4KoL0iU4gkSoIElX6h7UR4AgAAWygD///EBAIAAEwaA
Date: Thu, 16 Apr 2020 09:38:27 +0000
Message-ID: <1587029894464.80479@citrix.com>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <996ed66e-3782-5187-a804-9291741a2241@suse.com>
 <1587028832608.72974@citrix.com>
 <bd38c4da-b982-0d13-bdbd-ab363dae68e0@suse.com>
In-Reply-To: <bd38c4da-b982-0d13-bdbd-ab363dae68e0@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-imapappendstamp: AMSPEX02CL03.citrite.net (15.00.1497.006)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <38FD14541B61304BAFABA8E3DBB18EC4@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Sergey Dyasli <sergey.dyasli@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 10:25, J=FCrgen Gro=DF wrote:=0A=
> On 16.04.20 11:20, Sergey Dyasli wrote:=0A=
>> On 16/04/2020 09:57, J=FCrgen Gro=DF wrote:=0A=
>>> On 16.04.20 10:33, Sergey Dyasli wrote:=0A=
>>>> Currently it might be not obvious which scheduling mode is being used=
=0A=
>>>> by the scheduler. Alleviate this by printing additional information=0A=
>>>> about the selected granularity. Messages now look like these:=0A=
>>>>=0A=
>>>> 1. boot=0A=
>>>> (XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler (credit=
) in core-scheduling mode=0A=
>>>>=0A=
>>>> 2. xl debug-keys r=0A=
>>>> (XEN) [=A0=A0 45.914314] Scheduler: SMP Credit Scheduler (credit) in 2=
-way core-scheduling mode=0A=
>>>>=0A=
>>>> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>=0A=
>>>=0A=
>>> Hmm, do we need that?=0A=
>>>=0A=
>>> The xen commandline ins part of the boot messages and is contained=0A=
>>> in the "xl info" output.=0A=
>>=0A=
>> It's true that you can see "sched-gran=3Dcore" in "xl info" output. But =
that's=0A=
>> just the switch - not the end result. A user might want to verify that h=
e did=0A=
>> everything correctly and core-scheduling mode has indeed been enabled.=
=0A=
> =0A=
> I'm planning to add this information in the pending hypfs (per cpupool).=
=0A=
=0A=
hypfs is certainly nice, but I doubt it'll be available for Xen 4.13.=0A=
=0A=
> I'm not opposed to your patch, but as soon as we have per-cpupool=0A=
> granularity it should be reverted again.=0A=
=0A=
"xl debug-keys r" already prints the granularity information per cpupool.=
=0A=
It's just opt_sched_granularity is currently a single global variable. Once=
=0A=
per-cpupool granularity is implemented, sched_gran_str() should simply gain=
=0A=
granularity as a parameter.=0A=
=0A=
--=0A=
Thanks,=0A=
Sergey=0A=
=0A=


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 09:42:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 09:42:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP122-0005Tt-Pd; Thu, 16 Apr 2020 09:42:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Xq2g=6A=amazon.de=prvs=368a07d89=wipawel@srs-us1.protection.inumbo.net>)
 id 1jP121-0005To-3l
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 09:42:01 +0000
X-Inumbo-ID: 845095eb-7fc6-11ea-8b6d-12813bfff9fa
Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 845095eb-7fc6-11ea-8b6d-12813bfff9fa;
 Thu, 16 Apr 2020 09:41:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587030120; x=1618566120;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=UEPw6O3BljFwct47izeBxnxQHVPFN3vhQxafqb4+2o0=;
 b=FdJNGvyiZtCeHWoHX1X013xozj8fgiAkmZWhfXDp5xpL9V3l7hHdBCL7
 7iogntAJcNqeQwtuE/Vhx2fviuoZIpxsINYrX0F9fnW4CLOFZjnFXsOR5
 HPinekU4dKxJw6Mroi84kcNWnZGZzHQCmcjQwsynVak5xe1Ej7QLd9vcO I=;
IronPort-SDR: awgMYQycTtlz5joRHfcsa6TCbyYnbC4FGLuXeI+yN/YVQg4UmtZOk46pq8uR8pMjgVjQmMzR+p
 r5roaCCx9irw==
X-IronPort-AV: E=Sophos;i="5.72,390,1580774400"; d="scan'208";a="37396512"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2a-69849ee2.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP;
 16 Apr 2020 09:41:58 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2a-69849ee2.us-west-2.amazon.com (Postfix) with ESMTPS
 id F102BA2264; Thu, 16 Apr 2020 09:41:56 +0000 (UTC)
Received: from EX13D05EUC003.ant.amazon.com (10.43.164.207) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:41:56 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D05EUC003.ant.amazon.com (10.43.164.207) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:41:55 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 16 Apr 2020 09:41:54 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 1/4] lib: Add XEN_MAJOR() and XEN_MINOR() macros
Date: Thu, 16 Apr 2020 09:41:38 +0000
Message-ID: <20200416094141.65120-2-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200416094141.65120-1-wipawel@amazon.de>
References: <20200416094141.65120-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, Pawel Wieczorkiewicz <wipawel@amazon.de>,
 nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

These are just a simple macros obtaining major, minor values as
returned by xen_version hypercall.

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 include/xtf/lib.h    | 3 +++
 tests/xsa-213/main.c | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/xtf/lib.h b/include/xtf/lib.h
index 3348464..40e5731 100644
--- a/include/xtf/lib.h
+++ b/include/xtf/lib.h
@@ -20,6 +20,9 @@
 
 #define ACCESS_ONCE(x)   (*(volatile typeof(x) *)&(x))
 
+#define XEN_MAJOR(v) (((v) >> 16) & 0xFFFF)
+#define XEN_MINOR(v) ((v) & 0xFFFF)
+
 void __noreturn panic(const char *fmt, ...) __printf(1, 2);
 
 #define ASSERT(cond)                                    \
diff --git a/tests/xsa-213/main.c b/tests/xsa-213/main.c
index 64e7065..0353168 100644
--- a/tests/xsa-213/main.c
+++ b/tests/xsa-213/main.c
@@ -121,8 +121,8 @@ void test_main(void)
 {
     long rc, xen_version = hypercall_xen_version(XENVER_version, NULL);
 
-    printk("Found Xen %ld.%ld\n",
-           (xen_version >> 16) & 0xffff, xen_version & 0xffff);
+    printk("Found Xen %ld.%ld\n", XEN_MAJOR(xen_version),
+           XEN_MINOR(xen_version));
 
     xtf_set_idte(X86_VEC_AVAIL, &idte);
 
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 16 09:42:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 09:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP125-0005UP-37; Thu, 16 Apr 2020 09:42:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Xq2g=6A=amazon.de=prvs=368a07d89=wipawel@srs-us1.protection.inumbo.net>)
 id 1jP124-0005UF-Jb
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 09:42:04 +0000
X-Inumbo-ID: 86c7512e-7fc6-11ea-9e09-bc764e2007e4
Received: from smtp-fw-33001.amazon.com (unknown [207.171.190.10])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 86c7512e-7fc6-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 09:42:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587030124; x=1618566124;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=79p/4CDiEGJ18qhAhEUHKqQ88FWOgjBQJAWLoAZCclQ=;
 b=IVzJqfanxImuCiJars7ebN0+vxcrTvuVeyAwRcmheUSg/0PbrF5PcMVC
 3w0i3P+HlLHrfKiZVsuwGyo+dBsfvLONl25RVKcHKlJxWW3bOeizM4aL0
 93bBzwhDvv+mAcSl9EG1RcgV/WaVrQsUcg91K1W6PaTePQXfMxCzNICCy k=;
IronPort-SDR: Fy6DzixMvXQkmTCjVVJW3EyoVB9tCVaYJjwpWq+ZmtQkdWygvOGzzv1WJse+ZIwXC66gZpIcoL
 hxKteE0w2Fkg==
X-IronPort-AV: E=Sophos;i="5.72,390,1580774400"; d="scan'208";a="38805096"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP;
 16 Apr 2020 09:42:02 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com (Postfix) with ESMTPS
 id F0AF1A1F4D; Thu, 16 Apr 2020 09:42:00 +0000 (UTC)
Received: from EX13D05EUB004.ant.amazon.com (10.43.166.115) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:42:00 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D05EUB004.ant.amazon.com (10.43.166.115) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:41:59 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 16 Apr 2020 09:41:57 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 3/4] Enabled serial writing for hvm guests
Date: Thu, 16 Apr 2020 09:41:40 +0000
Message-ID: <20200416094141.65120-4-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200416094141.65120-1-wipawel@amazon.de>
References: <20200416094141.65120-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Semel <phentex@amazon.de>, julien@xen.org, paul@xen.org,
 semelpaul@gmail.com, andrew.cooper3@citrix.com,
 Pawel Wieczorkiewicz <wipawel@amazon.de>, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Semel <phentex@amazon.de>

setup.c: PV console writing is not working in Xen 4.2 for hvm
guests, so we make xtf write to COM1 serial port to get its output

Signed-off-by: Paul Semel <phentex@amazon.de>
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 arch/x86/setup.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 3c84e96..f6fa4df 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -238,6 +238,13 @@ static void qemu_console_write(const char *buf, size_t len)
                  : "d" (0x12));
 }
 
+static void com1_write(const char *buf, size_t len)
+{
+    asm volatile("rep; outsb"
+                 : "+S" (buf), "+c" (len)
+                 : "d" (0x3f8));
+}
+
 static void xen_console_write(const char *buf, size_t len)
 {
     hypercall_console_write(buf, len);
@@ -246,7 +253,14 @@ static void xen_console_write(const char *buf, size_t len)
 void arch_setup(void)
 {
     if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
+    {
         register_console_callback(qemu_console_write);
+    }
+
+    if ( IS_DEFINED(CONFIG_HVM) )
+    {
+        register_console_callback(com1_write);
+    }
 
     register_console_callback(xen_console_write);
 
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 16 09:42:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 09:42:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP127-0005VF-DR; Thu, 16 Apr 2020 09:42:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Xq2g=6A=amazon.de=prvs=368a07d89=wipawel@srs-us1.protection.inumbo.net>)
 id 1jP126-0005Uw-3n
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 09:42:06 +0000
X-Inumbo-ID: 85a1bfb4-7fc6-11ea-8b6d-12813bfff9fa
Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 85a1bfb4-7fc6-11ea-8b6d-12813bfff9fa;
 Thu, 16 Apr 2020 09:42:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587030122; x=1618566122;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=uIb4xj2tgH7IFsq9Zy2xIFcyIZN50bCT56Bc23fuUE0=;
 b=cujHMR7Y93oSRRxeSRWg+ByVzMEafY8GKa/lhBs35exzG1c/HQJP6WH1
 Z/ffLINbNA/U40Kbcn7vCn1vxBOsJuxjc7QhH0/qomiHL8ahR3OUKR8/C
 qYvNEzyN5gjPlYcLudJpZtsILwowC9Jde4hF05BxW/keM4DgRGR7Rhsnn Q=;
IronPort-SDR: M67prEiEzjjQKWR1atCMO4W6H/f51di5RQ5Hs/4aHqemofZyX4FLhlXDWavxFVIqCyLtZaGssN
 SYmgjSgA2etQ==
X-IronPort-AV: E=Sophos;i="5.72,390,1580774400"; d="scan'208";a="37396515"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP;
 16 Apr 2020 09:42:00 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com (Postfix) with ESMTPS
 id DF99DA1F58; Thu, 16 Apr 2020 09:41:58 +0000 (UTC)
Received: from EX13D05EUB001.ant.amazon.com (10.43.166.87) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:41:58 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D05EUB001.ant.amazon.com (10.43.166.87) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:41:57 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 16 Apr 2020 09:41:55 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 2/4] lib: always append CR after LF in vsnprintf()
Date: Thu, 16 Apr 2020 09:41:39 +0000
Message-ID: <20200416094141.65120-3-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200416094141.65120-1-wipawel@amazon.de>
References: <20200416094141.65120-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, Pawel Wieczorkiewicz <wipawel@amazon.de>,
 nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The explicit LFCR sequence guarantees proper line by line formatting
in the output.
The '\n' character alone on some terminals is not automatically
converted to LFCR.

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 common/libc/vsnprintf.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
index a49fd30..3202137 100644
--- a/common/libc/vsnprintf.c
+++ b/common/libc/vsnprintf.c
@@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
         if ( *fmt != '%' )
         {
             PUT(*fmt);
+
+            /*
+             * The '\n' character alone on some terminals is not automatically
+             * converted to LFCR.
+             * The explicit LFCR sequence guarantees proper line by line
+             * formatting in the output.
+             */
+            if ( *fmt == '\n' && str < end )
+                PUT('\r');
+
             continue;
         }
 
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 16 09:42:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 09:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP12A-0005WZ-MQ; Thu, 16 Apr 2020 09:42:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Xq2g=6A=amazon.de=prvs=368a07d89=wipawel@srs-us1.protection.inumbo.net>)
 id 1jP129-0005WF-By
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 09:42:09 +0000
X-Inumbo-ID: 8a4fa7d8-7fc6-11ea-9e09-bc764e2007e4
Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8a4fa7d8-7fc6-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 09:42:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587030130; x=1618566130;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=N1PTILdmBfZn0k0Ab+em8z55iCcBPHLG1MBSARH7dyg=;
 b=sEft3WfAQREuuD+g9jBzjrYb/4rysG/zSJOhqQfvuaXkaeJO49yRnX32
 NBnbbgMWGR6vPJCM3wlsvoQCXgp1fiYhhY5zUmhVQp34J8EF0rVEaeuv3
 7oTH1SnQ3gpGWot8wQEzhNVQBEjPHPVucU0WqFqfXDMwmsU1/D36TUgEb 4=;
IronPort-SDR: C//d8M9DnvYSECCCxrZ9Up9jtF1y54t7U8++eWZJ9svcIKT+TotKIfB1wKTibmdkvwkB35BF+R
 JOsW0slzsbSw==
X-IronPort-AV: E=Sophos;i="5.72,390,1580774400"; d="scan'208";a="26069913"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO
 email-inbound-relay-2b-4e24fd92.us-west-2.amazon.com) ([10.43.8.2])
 by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP;
 16 Apr 2020 09:41:56 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2b-4e24fd92.us-west-2.amazon.com (Postfix) with ESMTPS
 id 28D05A23D6; Thu, 16 Apr 2020 09:41:55 +0000 (UTC)
Received: from EX13D05EUB001.ant.amazon.com (10.43.166.87) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:41:54 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D05EUB001.ant.amazon.com (10.43.166.87) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:41:53 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 16 Apr 2020 09:41:52 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 0/4] Small fixes and improvements
Date: Thu, 16 Apr 2020 09:41:37 +0000
Message-ID: <20200416094141.65120-1-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, Pawel Wieczorkiewicz <wipawel@amazon.de>,
 nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is the first series of XTF patches I intend to send.
It covers some relatively small fixes to handling of PV console
by HVM guests, as well as adding serial consol support.

Paul Semel (2):
  Enabled serial writing for hvm guests
  setup: Setup PV console for HVM guests on xen >4.2

Pawel Wieczorkiewicz (2):
  lib: Add XEN_MAJOR() and XEN_MINOR() macros
  lib: always append CR after LF in vsnprintf()

 arch/x86/setup.c        | 34 ++++++++++++++++++++++++++++++++--
 common/libc/vsnprintf.c | 10 ++++++++++
 common/setup.c          |  6 +++++-
 include/xtf/framework.h |  2 +-
 include/xtf/lib.h       |  3 +++
 tests/xsa-213/main.c    |  4 ++--
 6 files changed, 53 insertions(+), 6 deletions(-)

-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 16 09:42:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 09:42:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP12P-0005bV-1K; Thu, 16 Apr 2020 09:42:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Xq2g=6A=amazon.de=prvs=368a07d89=wipawel@srs-us1.protection.inumbo.net>)
 id 1jP12N-0005b4-Nc
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 09:42:23 +0000
X-Inumbo-ID: 92e334f0-7fc6-11ea-b4f4-bc764e2007e4
Received: from smtp-fw-6001.amazon.com (unknown [52.95.48.154])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 92e334f0-7fc6-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 09:42:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587030143; x=1618566143;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=nBLsA1bQLNUw4cSYjqTUKz4JCf9EJCqVCkOxhJf9Dao=;
 b=P8rwHFgI9voH3xn9bkvFzTgoq3N7neS5PrOa578RUxO8bwQYjULs5mEB
 BC6+cc0QCqqKcc0M207mDxY+865owtaJv8thOZC7SJWjg5T6hK3taHTpb
 Jd04KeLaRGI5bmJlQZkY9kdNeB2iAeA664Pc9DKskoJ8N6PGPgdzHjTEN Y=;
IronPort-SDR: 4zeGHXNkwwvCfr19HUt8zMUCSA+sE035/1CEAJo8lWjqG6csKOEBfXySD8LDoRI47c78qCl2XV
 GJ6xWD94TUFA==
X-IronPort-AV: E=Sophos;i="5.72,390,1580774400"; d="scan'208";a="27162069"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2c-397e131e.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP;
 16 Apr 2020 09:42:22 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2c-397e131e.us-west-2.amazon.com (Postfix) with ESMTPS
 id 9F2B2A2E2B; Thu, 16 Apr 2020 09:42:21 +0000 (UTC)
Received: from EX13D02EUB003.ant.amazon.com (10.43.166.172) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:42:02 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D02EUB003.ant.amazon.com (10.43.166.172) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 09:42:01 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 16 Apr 2020 09:41:59 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2
Date: Thu, 16 Apr 2020 09:41:41 +0000
Message-ID: <20200416094141.65120-5-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200416094141.65120-1-wipawel@amazon.de>
References: <20200416094141.65120-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Semel <phentex@amazon.de>, julien@xen.org, paul@xen.org,
 semelpaul@gmail.com, andrew.cooper3@citrix.com,
 Pawel Wieczorkiewicz <wipawel@amazon.de>, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Semel <phentex@amazon.de>

Xen 4.2 requires a workaround that does not setup PV console
for HVM guests. However, newer Xen versions do not have that
limitation and should always have the PV console setup.

In arch_setup() detects Xen version by issuing xen_version hypercall
and optionally passes the version to main_xtf().

Signed-off-by: Paul Semel <phentex@amazon.de>
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 arch/x86/setup.c        | 20 ++++++++++++++++++--
 common/setup.c          |  6 +++++-
 include/xtf/framework.h |  2 +-
 3 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index f6fa4df..e3f74e6 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -250,8 +250,10 @@ static void xen_console_write(const char *buf, size_t len)
     hypercall_console_write(buf, len);
 }
 
-void arch_setup(void)
+void arch_setup(int *version)
 {
+    int xen_version;
+
     if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
     {
         register_console_callback(qemu_console_write);
@@ -272,9 +274,23 @@ void arch_setup(void)
 
     init_hypercalls();
 
-    if ( !is_initdomain() )
+    xen_version = hypercall_xen_version(XENVER_version, NULL);
+    if ( version )
+        *version = xen_version;
+
+    /*
+     * The setup_pv_console function registers a writing function
+     * that makes hvm guests crash on Xen 4.2
+     */
+    if ( (!IS_DEFINED(CONFIG_HVM) ||
+         (XEN_MAJOR(xen_version) >= 4 && XEN_MINOR(xen_version) > 2)) &&
+         !is_initdomain() )
     {
         setup_pv_console();
+    }
+
+    if ( !is_initdomain() )
+    {
         setup_xenbus();
     }
 
diff --git a/common/setup.c b/common/setup.c
index 932fc09..1d3da15 100644
--- a/common/setup.c
+++ b/common/setup.c
@@ -19,9 +19,13 @@
  */
 void __noreturn xtf_main(void)
 {
-    arch_setup();
+    int xen_version;
+
+    arch_setup(&xen_version);
 
     printk("--- Xen Test Framework ---\n");
+    printk("Found Xen: %d.%d\n", XEN_MAJOR(xen_version),
+           XEN_MINOR(xen_version));
     printk("Environment: %s\n", environment_description);
     printk("%s\n", test_title);
 
diff --git a/include/xtf/framework.h b/include/xtf/framework.h
index a71bf39..6664733 100644
--- a/include/xtf/framework.h
+++ b/include/xtf/framework.h
@@ -2,7 +2,7 @@
 #define XTF_FRAMEWORK_H
 
 /* To be implemented by each arch */
-void arch_setup(void);
+void arch_setup(int *);
 void test_setup(void);
 
 /* Single line summary of execution environment. */
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 16 09:58:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 09:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP1HO-0006op-MY; Thu, 16 Apr 2020 09:57:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=IxKm=6A=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jP1HN-0006ok-TZ
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 09:57:53 +0000
X-Inumbo-ID: bcb57a20-7fc8-11ea-8b6f-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bcb57a20-7fc8-11ea-8b6f-12813bfff9fa;
 Thu, 16 Apr 2020 09:57:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587031072;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=Lc///ge52iw6+SY+Ikb3wdVYUDR30932DvTdJF2/5RI=;
 b=aqyUnyZ4yfixQu1nSKxO6lzfBKIDOjKTvX5pZZgaHNcDJ7d+B0NfgLyR
 lEJkQeYMLD6Wi6CRlZD1Rf5EajESOFOUq46L5+dxPLacLZlD/tI4wNBmS
 w+MNm71yMolSQxVa+/dFic9EpSgWUmyP6d5wwLOwgKRm5TF2KCxOY+70l U=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: NBCwOs6L7lM5ap3HreIV8567cRrZGOYjTTB3j4cvb+j0upve7c3RFcsP+COBqS2AeYhbkn8Cb0
 gn4QOnbNl6xHV0rl/y3Ewh4HW7UnvXaXEo8NUXlUCq1OzX7Dsimlar2Z+tjtLyZWkFzi0JfNRp
 t+914568NNWaGlOIhll6aiaGfPHXb9OuCllJ6KTLhUboSWfeXqv8Q50U8mm6iSvDers0ZK/Vi2
 f2L3MJ/CaVh+djtdwLMz7OLpFqBq8v4TSpLYUM1+nDyUd84kC0BqQ+nTmt9A58gvwWl3vRP6mU
 I7Q=
X-SBRS: 2.7
X-MesageID: 16168719
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,390,1580792400"; d="scan'208";a="16168719"
Date: Thu, 16 Apr 2020 10:57:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 12/18] xen/build: factorise generation of the
 linker scripts
Message-ID: <20200416095747.GF4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-13-anthony.perard@citrix.com>
 <af0121cc-c282-ceb0-b5e8-44ac0ba6ebfb@suse.com>
 <20200415165832.GE4088@perard.uk.xensource.com>
 <6001a8a3-aed6-0e74-f82d-823853e44483@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6001a8a3-aed6-0e74-f82d-823853e44483@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 16, 2020 at 09:36:15AM +0200, Jan Beulich wrote:
> On 15.04.2020 18:58, Anthony PERARD wrote:
> > On Wed, Apr 08, 2020 at 02:46:42PM +0200, Jan Beulich wrote:
> >> On 31.03.2020 12:30, Anthony PERARD wrote:
> >>>     - avoid using "define" for cmd_cc_lds_S, as adding '; \' on each line is
> >>>       still mandatory for if_changed (or cmd) macro to work.
> >>
> >> I still don't believe in there being a need for "; \" there. This
> >> actually breaks things, after all:
> >>
> >>> --- a/xen/Rules.mk
> >>> +++ b/xen/Rules.mk
> >>> @@ -236,6 +236,12 @@ cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
> >>>  %.s: %.S FORCE
> >>>  	$(call if_changed,cpp_s_S)
> >>>  
> >>> +# Linker scripts, .lds.S -> .lds
> >>> +quiet_cmd_cc_lds_S = LDS     $@
> >>> +cmd_cc_lds_S = $(CPP) -P $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<; \
> >>> +    sed -e 's/.*\.lds\.o:/$(@F):/g' <$(dot-target).d >$(dot-target).d.new; \
> >>> +    mv -f $(dot-target).d.new $(dot-target).d
> >>
> >> if $(CPP) or sed fail, previously the whole rule would have failed,
> >> which no longer is the case with your use of semicolons. There
> >> ought to be a solution to this, ideally one better than adding
> >> "set -e" as the first command ("define" would at least deal with
> >> the multi-line make issue, but without it being clear to me why the
> >> semicolons would be needed I don't think I can suggest anything
> >> there at the moment).
> > 
> > The only macro that will consumes cmd_cc_lds_S (and other cmd_*) is
> > "cmd", it is defined as:
> >     cmd = @set -e; $(echo-cmd) $(cmd_$(1))
> > So, "set -e" is already there, and using semicolons in commands is
> > equivalent to using "&&".
> > 
> > With "cmd" alone, multi-line command would work as expected (unless
> > $(echo-cmd) is is trying to print the command line).
> > 
> > It's "if_changed" macro that doesn't work with multi-line commands.
> > It does:
> >     $(cmd); printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd
> > With a multiple line command, $(make-cmd) get's expanded to multiple
> > line, so the second argument of "printf" is going to be spread over
> > multiple line in make, and thus multiple shell. We run into this error:
> >     /bin/sh: -c: line 0: unexpected EOF while looking for matching `''
> >     /bin/sh: -c: line 1: syntax error: unexpected end of file
> > 
> > This is why we need to have commands on a single line.
> > 
> > I hope the explanation is clear enough.
> 
> Yes, thanks. One question remains though: Why do we need multiple
> commands here in the first place, when Linux gets away with one?

Actually, Linux also has multiple commands as well. After running CPP,
it runs ./fixdep (via if_change_dep) which does at least the same thing
as our sed command. We can't use fixdep yet, but I'm working toward it.

> Two other remarks: For one the command's name, aiui, ought to be
> cmd_cpp_lds_S (see Linux). And there ought to be cpp_flags, which
> would then also be used by e.g. cmd_s_S (instead of both having
> $(filter-out -Wa$(comma)%,$(a_flags)) open-coded).

When switching to use CPP instead of CC, I forgot to rename the command,
so I'll fix that.

I'll look at introducing cpp_flags.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 10:19:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 10:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP1bp-0000Eb-Pz; Thu, 16 Apr 2020 10:19:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HCIP=6A=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jP1bo-0000EV-I4
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 10:19:00 +0000
X-Inumbo-ID: adb1460b-7fcb-11ea-8b6f-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id adb1460b-7fcb-11ea-8b6f-12813bfff9fa;
 Thu, 16 Apr 2020 10:18:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587032337;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=7yXG1cGvOJHfGQ2haqawbrQ/ZIdPpc5FOue7dtqIElM=;
 b=e3XIX0zJG7muBvvuO6oibgyuiF5zkeyz9YwPozCiW2ljOuY4ySueTXvQ
 EBtCWYuxbxe7/nojg+YFZ6sNVdnWa4WOqEim7pMeiKEorhC5R90noayl+
 exHDwxPB9n578HL3Dk8QQ05yT6HNTkIxGS4mpuwg1H1Y7lFzjQwckzYxq g=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: lGfQjk1y2psOXoykCMThRYcOT1HSzGLD2WsBrfz1q/9RXTK3zk+LXZxgi1L3CSARCEpPEMl2hS
 m4+oZ08ddGBjqwCyXOZxELlUkMoyg51Pzccb4A7bWElAiZFg6qT7A9htMK0LfMgFQcmHXxFSNA
 Jhs2bnlSETPiuzWYWzbNEnZ9GIg5T1lT6aWFxSRpakx8mH/NC4ozzO0AaS6CgOE5K0j9fNOfml
 gX4jk/U8fXbvyJPzdW+J2+NZdy9WvF98hbX6awIBe6p3xDeySNTzWTbGWCIF6gvBfDJek2Q4Oo
 2CA=
X-SBRS: 2.7
X-MesageID: 16009628
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,390,1580792400"; d="scan'208";a="16009628"
Subject: Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
To: Pawel Wieczorkiewicz <wipawel@amazon.de>, <xen-devel@lists.xen.org>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-3-wipawel@amazon.de>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <00549997-7633-a8c2-899a-fbc0b5a45541@citrix.com>
Date: Thu, 16 Apr 2020 11:18:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416094141.65120-3-wipawel@amazon.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: semelpaul@gmail.com, julien@xen.org, nmanthey@amazon.de, paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
> The explicit LFCR sequence guarantees proper line by line formatting
> in the output.
> The '\n' character alone on some terminals is not automatically
> converted to LFCR.
>
> Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>

Up until now, all console destinations have expected POSIX text semantics.

I presume this is due to the COM1 use presented in the next patch?

Unfortunately, this comes with collateral damage.

# ./xtf-runner hvm64 example
Executing 'xl create -p tests/example/test-hvm64-example.cfg'
Executing 'xl console test-hvm64-example'
Executing 'xl unpause test-hvm64-example'
--- Xen Test Framework ---

Found Xen: 4.14

Environment: HVM 64bit (Long mode 4 levels)

Hello World

Test result: SUCCESS


Combined test results:
test-hvm64-example                       CRASH

which I believe is due to xenconsoled (or the intervening pty) also
expanding \n to \r\n (and "Test result:" no longer being on the final
line from xtf-runner's point of view).  Xen also expands \n to \r\n for
the console, so ends up emitting \r\r\n.

Would it be better to have the com1 console handler do the expansion
locally, to avoid interfering with the semantics of every other
destination?  That said...

> ---
>  common/libc/vsnprintf.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
> index a49fd30..3202137 100644
> --- a/common/libc/vsnprintf.c
> +++ b/common/libc/vsnprintf.c
> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
>          if ( *fmt != '%' )
>          {
>              PUT(*fmt);
> +
> +            /*
> +             * The '\n' character alone on some terminals is not automatically
> +             * converted to LFCR.
> +             * The explicit LFCR sequence guarantees proper line by line
> +             * formatting in the output.
> +             */
> +            if ( *fmt == '\n' && str < end )
> +                PUT('\r');

... doesn't this end up putting out \n\r ?

~Andrew

> +
>              continue;
>          }
>  



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 10:32:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 10:32:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP1ox-0001n8-V7; Thu, 16 Apr 2020 10:32:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HCIP=6A=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jP1ox-0001n3-AB
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 10:32:35 +0000
X-Inumbo-ID: 9538e31a-7fcd-11ea-b4f4-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9538e31a-7fcd-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 10:32:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587033153;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=eEs36gk2NiP2i+W0bBr9CkC/FtyZfs0r3OSlO+gq+1s=;
 b=iLdP7rr9ZETdrydntDp2mTtgr+LjnvxYG2JIFUXbJ4ziUfy1xUxVEfZR
 QgRlKtOTV0mooiAP7OzQK3CNsew11/N+V9vBf9ZpAV2CkxfvSx/ZRVAnh
 I8ZOpB8DEe38H5mnHL7wc6xhbmzH9S9A1MRD/vnBDIHoTdywA83cPXMj3 I=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 5sfaLj9JjifoftMNaIgSBeJt0a0MBZFkbAI+gA6X8ZYSWmfiMiudHVGLMAL/VNU6EBSkNRt2pc
 QFqSER7WJ/8+AfbLPsfnf8ZObxStNVoLkVJOHKx28hoPMMa4Mj/tVwEOLKOMcXzlpFPbTUAtey
 6MhVgz9Mzh1MM8V+7Xb1tZ+fti2lOyt0yFHV7WVUusClG5JeZuu6jj4OFeuLaVRekIB3bII264
 C5Qf8n+7z/+PDE/TBkiZDNLujnvFI5D8TjE7jiqvcCbs0jcNE7tzopfGT+3yIBdEa2o8PYq2aJ
 als=
X-SBRS: 2.7
X-MesageID: 16087307
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,390,1580792400"; d="scan'208";a="16087307"
Subject: Re: [XTF 3/4] Enabled serial writing for hvm guests
To: Pawel Wieczorkiewicz <wipawel@amazon.de>, <xen-devel@lists.xen.org>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-4-wipawel@amazon.de>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <501cc157-b260-bca0-2920-f4e3a8a07c1b@citrix.com>
Date: Thu, 16 Apr 2020 11:32:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416094141.65120-4-wipawel@amazon.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: semelpaul@gmail.com, Paul Semel <phentex@amazon.de>, julien@xen.org,
 nmanthey@amazon.de, paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
> From: Paul Semel <phentex@amazon.de>
>
> setup.c: PV console writing is not working in Xen 4.2 for hvm
> guests,

What is not working about it?

>  so we make xtf write to COM1 serial port to get its output
>
> Signed-off-by: Paul Semel <phentex@amazon.de>
> Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
> ---
>  arch/x86/setup.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/x86/setup.c b/arch/x86/setup.c
> index 3c84e96..f6fa4df 100644
> --- a/arch/x86/setup.c
> +++ b/arch/x86/setup.c
> @@ -238,6 +238,13 @@ static void qemu_console_write(const char *buf, size_t len)
>                   : "d" (0x12));
>  }
>  
> +static void com1_write(const char *buf, size_t len)
> +{
> +    asm volatile("rep; outsb"
> +                 : "+S" (buf), "+c" (len)
> +                 : "d" (0x3f8));

Despite being 0x3f8, this really isn't uart-compatible COM1.  I presume
it only works because Qemu doesn't have any real THR delays in its
emulation.

> +}
> +
>  static void xen_console_write(const char *buf, size_t len)
>  {
>      hypercall_console_write(buf, len);
> @@ -246,7 +253,14 @@ static void xen_console_write(const char *buf, size_t len)
>  void arch_setup(void)
>  {
>      if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
> +    {
>          register_console_callback(qemu_console_write);
> +    }
> +
> +    if ( IS_DEFINED(CONFIG_HVM) )
> +    {
> +        register_console_callback(com1_write);

This wires up 0x3f8 even for PVH guests, which I'm guessing isn't
intentional?  This should be part of the previous if(), but does beg the
question what is wrong with the existing qemu console?

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 10:36:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 10:36:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP1t1-0001wR-I7; Thu, 16 Apr 2020 10:36:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HCIP=6A=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jP1t0-0001wM-Kq
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 10:36:46 +0000
X-Inumbo-ID: 2b16453a-7fce-11ea-8b73-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2b16453a-7fce-11ea-8b73-12813bfff9fa;
 Thu, 16 Apr 2020 10:36:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587033406;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=B3F9vmUKCZWW8pKxejUrfxO+dZqnQtTncGLehYdGxzc=;
 b=eOkpOmwWbr3UQoZHovoRy6Rw1Z8SHpeBOM5NNsQwsdC6mFouf55A3pa4
 zv2sOsYlDfBh1Qrg7+JJLmT7o3oaFw54MPRy6Mm/eBMmfRs5Kt//D2bwL
 bbN1AckfZEVN+3yuV2kzuw5ka6hkDNCPMZSCcVHDFYCOyCTRjK1sKLkqu M=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: GZ1+DEOi9kEEdEQ6ewAZITP9zQ10gRfnfEpqTye1jakNMNmizl1LM8+8DgopAp0G4+Xg0hX9Qj
 x7m5SBGgwVsApyUhm3K0oBS8VCjfho4AEKgwSfmWE8V89FPptAj0jWthPXurchbGKGrNT29fcb
 8Biu23djIsEN4Wvomn56eiUGqOjbFXKcv5HpJU7K1nAqX5mEElnkDAKG54bwq4A7QCeUJGawc/
 gUDuZrvys//5mIOWAV889zqkqkcREfdRdvea0p8g/GIhGbme5oXltwU4KnkwCbrXO8MMP80h7U
 lw8=
X-SBRS: 2.7
X-MesageID: 15783033
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,390,1580792400"; d="scan'208";a="15783033"
Subject: Re: [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2
To: Pawel Wieczorkiewicz <wipawel@amazon.de>, <xen-devel@lists.xen.org>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-5-wipawel@amazon.de>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <e1e910a7-ed94-46e9-6987-fecdd704e104@citrix.com>
Date: Thu, 16 Apr 2020 11:36:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416094141.65120-5-wipawel@amazon.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: semelpaul@gmail.com, Paul Semel <phentex@amazon.de>, julien@xen.org,
 nmanthey@amazon.de, paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
> @@ -272,9 +274,23 @@ void arch_setup(void)
>  
>      init_hypercalls();
>  
> -    if ( !is_initdomain() )
> +    xen_version = hypercall_xen_version(XENVER_version, NULL);
> +    if ( version )
> +        *version = xen_version;
> +
> +    /*
> +     * The setup_pv_console function registers a writing function
> +     * that makes hvm guests crash on Xen 4.2

This comment in particular is rather concerning.  Even if there is a
configuration issue in 4.2 stopping the PV console from being wired up
properly, nothing involved in transmitting on the console should crash
the guest.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 11:24:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 11:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP2dC-00064f-9g; Thu, 16 Apr 2020 11:24:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=FuWY=6A=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jP2dA-00064Y-BY
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 11:24:28 +0000
X-Inumbo-ID: d48b55a1-7fd4-11ea-8b78-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d48b55a1-7fd4-11ea-8b78-12813bfff9fa;
 Thu, 16 Apr 2020 11:24:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=lztuz1kka89WKgJaeck9DZdVbr9zC3Dt9d5CkACQMII=; b=YaVw0aGGW+I0Y+B+FButI8n2HR
 ZF84y6il0u1pmEqWe2Rg2JCGLNChla8bL75776ckVvrot9nJc4iFgZptJ+heFqk0BuvizKtbctdcm
 rez84p5I+TCGuQoN8nnyoutDL58K84OdJNDK6rknfZRCpIqpksi53eOQcc/Tmrn3qKY8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jP2d8-0002fA-BG; Thu, 16 Apr 2020 11:24:26 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jP2d8-00036o-1Z; Thu, 16 Apr 2020 11:24:26 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [[PATCH v3]] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
Date: Thu, 16 Apr 2020 12:24:23 +0100
Message-Id: <20200416112423.25755-1-julien@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <jgrall@amazon.com>, julien@xen.org,
 Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
data to guest handle marked const.

Thankfully, no users of the helper will do that. Rather than hoping this
can be caught during review, harden copy_to_guest_offset() so the build
will fail if such users are introduced.

There is no easy way to check whether a const is NULL in C99. The
approach used is to introduce an unused variable that is non-const and
assign the handle. If the handle were const, this would fail at build
because without an explicit cast, it is not possible to assign a const
variable to a non-const variable.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>

---
    Changes in v3:
        - Reduce the length of the comments and move it within the
        macro.

    Changes in v2:
        - Use a void * variable to check the handle is not const.
---
 xen/include/asm-arm/guest_access.h | 4 ++++
 xen/include/asm-x86/guest_access.h | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
index 8997a1cbfe..97cf3384f1 100644
--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -78,6 +78,8 @@ int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
 #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    /* Check if the handle is not const */              \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
 })
@@ -127,6 +129,8 @@ int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
 #define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    /* Check if the handle is not const */              \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
 })
diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index ca700c959a..6f5107951c 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -87,6 +87,8 @@
 #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    /* Check if the handle is not const */              \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
 })
@@ -137,6 +139,8 @@
 #define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
     const typeof(*(ptr)) *_s = (ptr);                   \
     char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    /* Check if the handle is not const */              \
+    void *__maybe_unused _t = (hnd).p;                  \
     ((void)((hnd).p == (ptr)));                         \
     __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
 })
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 11:25:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 11:25:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP2eK-00069X-PL; Thu, 16 Apr 2020 11:25:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=FuWY=6A=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jP2eJ-00069N-Vc
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 11:25:40 +0000
X-Inumbo-ID: fffcf81a-7fd4-11ea-8b78-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fffcf81a-7fd4-11ea-8b78-12813bfff9fa;
 Thu, 16 Apr 2020 11:25:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Tux4Pn7DtfiIM2J0xf+G6osHvsBjKxGAxQwcCieWLj4=; b=6tAAO8HznTTTyUOUdBmPmz1j+B
 TXe4DcqHQSdA/XWaUiGKePtwHhGaLYNkgZlq9oRjpqu3Gt2/k7t9mtx7lzn9l4PG8+0Whzb/wM0NH
 u9Hx6/eFZevs0ze7zLewVYUF8cmajK5MAHeq9yd8gd4Pry20BPcOutNyWnqyC8y5vTQY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jP2eC-0002gP-0m; Thu, 16 Apr 2020 11:25:32 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jP2eB-0003A2-P4; Thu, 16 Apr 2020 11:25:31 +0000
Subject: Re: [PATCH 0/8] Fix build with using OCaml 4.06.1 and -safe-string
To: xen-devel@lists.xenproject.org,
 Christian Lindig <christian.lindig@citrix.com>, David Scott <dave@recoil.org>
References: <20200330192157.1335-1-julien@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <67d3370c-779a-7007-e5fa-98d957a85ce9@xen.org>
Date: Thu, 16 Apr 2020 12:25:28 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200330192157.1335-1-julien@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, dfaggioli@suse.com,
 Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

Gentle ping. I am missing reviews for the OCaml part.

Cheers,

On 30/03/2020 20:21, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Hi all,
> 
> This series is meant to solve the build issue reported by Dario when
> using recent version of OCaml and -safe-string.
> 
> I took the opportunity to harden a bit more the code by using const more
> often.
> 
> This series was only build tested.
> 
> Cheers,
> 
> Julien Grall (8):
>    xen/guest_access: Harden copy_to_guest_offset to prevent const dest
>      operand
>    xen/public: sysctl: set_parameter.params and debug.keys should be
>      const
>    tools/libxc: misc: Mark const the parameter 'keys' of
>      xc_send_debug_keys()
>    tools/libxc: misc: Mark const the parameter 'params' of
>      xc_set_parameters()
>    tools/ocaml: libxc: Check error return in stub_xc_vcpu_context_get()
>    tools/ocaml: libxb: Harden stub_header_of_string()
>    tools/ocaml: libxb: Avoid to use String_val() when value is bytes
>    tools/ocaml: Fix stubs build when OCaml has been compiled with
>      -safe-string
> 
>   tools/libxc/include/xenctrl.h       |  4 ++--
>   tools/libxc/xc_misc.c               |  8 ++++----
>   tools/libxc/xc_private.h            |  8 ++++++++
>   tools/ocaml/libs/xb/xenbus_stubs.c  |  6 +++---
>   tools/ocaml/libs/xb/xs_ring_stubs.c | 12 ++++++++++--
>   tools/ocaml/libs/xc/xenctrl_stubs.c |  6 ++++--
>   xen/include/asm-arm/guest_access.h  |  2 +-
>   xen/include/asm-x86/guest_access.h  |  2 +-
>   xen/include/public/sysctl.h         |  4 ++--
>   9 files changed, 35 insertions(+), 17 deletions(-)
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 11:34:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 11:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP2mP-00073O-Mx; Thu, 16 Apr 2020 11:34:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jP2mO-00073J-ER
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 11:34:00 +0000
X-Inumbo-ID: 29c631b0-7fd6-11ea-8b78-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 29c631b0-7fd6-11ea-8b78-12813bfff9fa;
 Thu, 16 Apr 2020 11:33:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=QCdCJQniNLOUu5FUzLbEKqAY0XqNLyR5tH9DX7Jj/QQ=; b=n4GfmKHv2nrXQUpTAnOBGfVCy
 9OXiKW+xgo1OoCzZLshRPVESmw+YJdNTOkb5aKEog4CjH4XM5o9fuj3rFCVtZ56roHw8Ziko+4yzb
 j9yVEn6okM3tmMOMc+vaaeYDubG0wSPMmpP4ReNwGXSSqygjz0zOCoN8at0mEMIWbpNG4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jP2mM-0002qS-ML; Thu, 16 Apr 2020 11:33:58 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jP2mM-0002Ly-En; Thu, 16 Apr 2020 11:33:58 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jP2mM-0004CA-ED; Thu, 16 Apr 2020 11:33:58 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149686-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149686: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=615bfe42c6d183a0e54a0525ef82b58580d01619
X-Osstest-Versions-That: xen=fcd06227f83643194f8018f8dd37adce57763a61
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 11:33:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  615bfe42c6d183a0e54a0525ef82b58580d01619
baseline version:
 xen                  fcd06227f83643194f8018f8dd37adce57763a61

Last test of basis   149654  2020-04-14 16:01:51 Z    1 days
Testing same since   149686  2020-04-16 09:01:03 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Julien Grall <jgrall@amazon.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   fcd06227f8..615bfe42c6  615bfe42c6d183a0e54a0525ef82b58580d01619 -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 11:36:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 11:36:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP2op-0007AS-6Q; Thu, 16 Apr 2020 11:36:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Xq2g=6A=amazon.de=prvs=368a07d89=wipawel@srs-us1.protection.inumbo.net>)
 id 1jP2on-0007AN-Tu
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 11:36:30 +0000
X-Inumbo-ID: 836e2038-7fd6-11ea-9e09-bc764e2007e4
Received: from smtp-fw-4101.amazon.com (unknown [72.21.198.25])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 836e2038-7fd6-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 11:36:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587036989; x=1618572989;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:mime-version:content-transfer-encoding:subject;
 bh=dPngK29NaQQoll/lqE2nCMTHqbTXqmYPy6JDuOY58JY=;
 b=JtGA35tfjSyVcxU5IuxtyLziQuZXSoLJ5ayaSi41mknXzsx2SYUClJHv
 3lWITy9UxFfFFCeCGoSwK7771d+iIrzoxhB3eBD25+7nw8Ocu2VpMgdUu
 me3qxxDs6ffNQd34s2Wbefwo+JN9lZlsLgWJKCWu4tE86UxC3H5VY79c6 k=;
IronPort-SDR: 93YY/2ZoeiPT42XaGaI2NNeR6NJkZTtvzgY/4iXX/qMwjrAA6kIXb+FdFfHZENgV8UwZixYcOw
 l5yuTQloafHw==
X-IronPort-AV: E=Sophos;i="5.72,390,1580774400"; d="scan'208";a="25822943"
Subject: Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
Thread-Topic: [XTF 2/4] lib: always append CR after LF in vsnprintf()
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP;
 16 Apr 2020 11:36:17 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166])
 by email-inbound-relay-1e-27fb8269.us-east-1.amazon.com (Postfix) with ESMTPS
 id D77EEA1CF0; Thu, 16 Apr 2020 11:36:15 +0000 (UTC)
Received: from EX13D05EUB002.ant.amazon.com (10.43.166.45) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 11:36:15 +0000
Received: from EX13D05EUB004.ant.amazon.com (10.43.166.115) by
 EX13D05EUB002.ant.amazon.com (10.43.166.45) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 11:36:14 +0000
Received: from EX13D05EUB004.ant.amazon.com ([10.43.166.115]) by
 EX13D05EUB004.ant.amazon.com ([10.43.166.115]) with mapi id 15.00.1497.006;
 Thu, 16 Apr 2020 11:36:14 +0000
From: "Wieczorkiewicz, Pawel" <wipawel@amazon.de>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Thread-Index: AQHWE9NFbSxUmGmFhkmqadsHpX8TWKh7iTMAgAAVnYA=
Date: Thu, 16 Apr 2020 11:36:14 +0000
Message-ID: <A2E046DD-9F85-4C54-9FED-BE240AA71E09@amazon.com>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-3-wipawel@amazon.de>
 <00549997-7633-a8c2-899a-fbc0b5a45541@citrix.com>
In-Reply-To: <00549997-7633-a8c2-899a-fbc0b5a45541@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.166.198]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19DBE9CA9BC8494AB39BDFE7569D8353@amazon.com>
MIME-Version: 1.0
Precedence: Bulk
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <julien@xen.org>, "paul@xen.org" <paul@xen.org>,
 "semelpaul@gmail.com" <semelpaul@gmail.com>,
 "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Wieczorkiewicz,
 Pawel" <wipawel@amazon.de>, "Manthey, Norbert" <nmanthey@amazon.de>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



> On 16. Apr 2020, at 12:18, Andrew Cooper <andrew.cooper3@citrix.com> wrot=
e:
> =

> CAUTION: This email originated from outside of the organization. Do not c=
lick links or open attachments unless you can confirm the sender and know t=
he content is safe.
> =

> =

> =

> On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
>> The explicit LFCR sequence guarantees proper line by line formatting
>> in the output.
>> The '\n' character alone on some terminals is not automatically
>> converted to LFCR.
>> =

>> Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
> =

> Up until now, all console destinations have expected POSIX text semantics.
> =

> I presume this is due to the COM1 use presented in the next patch?
> =


No, this is not about that.

> Unfortunately, this comes with collateral damage.
> =

> # ./xtf-runner hvm64 example
> Executing 'xl create -p tests/example/test-hvm64-example.cfg'
> Executing 'xl console test-hvm64-example'
> Executing 'xl unpause test-hvm64-example'
> --- Xen Test Framework ---
> =

> Found Xen: 4.14
> =

> Environment: HVM 64bit (Long mode 4 levels)
> =

> Hello World
> =

> Test result: SUCCESS
> =

> =

> Combined test results:
> test-hvm64-example                       CRASH
> =


I never use xtf-runner script to execute tests. I do it the old fashion way:

# xl create -c test-hvm64-example.cfg
Parsing config from test-hvm64-example.cfg
Guest cpuid information
                       Native cpuid:
                                      00000000:ffffffff -> 0000000d:756e654=
7:6c65746e:49656e69
                                                                           =
                     00000001:ffffffff -> 000306e4:00400800:f7ba2203:1fcbfb=
ff
                                                                           =
                                                                           =
    00000002:ffffffff -> 76036301:00f0b2ff:00000000:00ca0000
00000003:ffffffff -> 00000000:00000000:00000000:00000000
                                                          00000004:00000000=
 -> 7c000121:01c0003f:0000003f:00000000
                                                                           =
                                         00000004:00000001 -> 7c000122:01c0=
003f:0000003f:00000000
                                                                           =
                                                                           =
                        00000004:00000002 -> 7c000143:01c0003f:000001ff:000=
00000
                                                                           =
                                                                           =
                                                                           =
       00000004:00000003 -> 7c000163:04c0003f:00004fff:00000006
 00000004:00000004 -> 00000000:00000000:00000000:00000000
                                                           00000005:fffffff=
f -> 00000040:00000040:00000003:00001120
                                                                           =
                                          00000006:ffffffff -> 00000077:000=
00002:00000009:00000000
                                                                           =
                                                                           =
                         00000007:00000000 -> 00000000:00000281:00000000:9c=
000400
                                                                           =
                                                                           =
                                                                           =
        00000008:ffffffff -> 00000000:00000000:00000000:00000000
  00000009:ffffffff -> 00000000:00000000:00000000:00000000
                                                            0000000a:ffffff=
ff -> 07300403:00000000:00000000:00000603
                                                                           =
                                           0000000b:ffffffff -> 00000000:00=
000000:00000000:00000000
                                                                           =
                                                                           =
                          0000000c:ffffffff -> 00000000:00000000:00000000:0=
0000000
                                                                           =
                                                                           =
                                                                           =
         0000000d:00000000 -> 00000007:00000240:00000340:00000000
   0000000d:00000001 -> 00000001:00000000:00000000:00000000
                                                             0000000d:00000=
002 -> 00000100:00000240:00000000:00000000
                                                                           =
                                            40000000:ffffffff -> 40000005:5=
66e6558:65584d4d:4d4d566e
                                                                           =
                                                                           =
                           40000001:ffffffff -> 0004000b:00000000:00000000:=
00000000
                                                                           =
                                                                           =
                                                                           =
          40000002:ffffffff -> 00000001:40000000:00000000:00000000
    40000003:00000000 -> 00000006:00000000:002625a2:00000001
                                                              40000003:0000=
0001 -> 57b3c4d2:00030755:ccccc210:ffffffff
                                                                           =
                                             40000003:00000002 -> 002625a2:=
00000000:00000000:00000000
                                                                           =
                                                                           =
                            40000004:00000000 -> 0000001c:00000000:00000ac9=
:00000000
                                                                           =
                                                                           =
                                                                           =
           40000005:ffffffff -> 00000000:00000000:00000000:00000000
     40000100:ffffffff -> 00000000:00000000:00000000:00000000
                                                               80000000:fff=
fffff -> 80000008:00000000:00000000:00000000
                                                                           =
                                              80000001:ffffffff -> 00000000=
:00000000:00000001:2c100800
                                                                           =
                                                                           =
                             80000002:ffffffff -> 20202020:6e492020:286c657=
4:58202952
                                                                           =
                                                                           =
                                                                           =
            80000003:ffffffff -> 286e6f65:43202952:45205550:36322d35
      80000004:ffffffff -> 76203037:20402032:30352e32:007a4847
                                                                80000005:ff=
ffffff -> 00000000:00000000:00000000:00000000
                                                                           =
                                               80000006:ffffffff -> 0000000=
0:00000000:01006040:00000000
                                                                           =
                                                                           =
                              80000007:ffffffff -> 00000000:00000000:000000=
00:00000000
                                                                           =
                                                                           =
                                                                           =
             80000008:ffffffff -> 0000302e:00001000:00000000:00000000
     Test result: SUCCESS


There is no \r added to the console. I am not using serial console for this=
 example.

Also, qemu seems to do the right thing and appends \r when it is not there.

> which I believe is due to xenconsoled (or the intervening pty) also
> expanding \n to \r\n (and "Test result:" no longer being on the final
> line from xtf-runner's point of view).  Xen also expands \n to \r\n for
> the console, so ends up emitting \r\r\n.
> =

> Would it be better to have the com1 console handler do the expansion
> locally, to avoid interfering with the semantics of every other
> destination?  That said...

com1 handler works fine even without this patch

> =

>> ---
>> common/libc/vsnprintf.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>> =

>> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
>> index a49fd30..3202137 100644
>> --- a/common/libc/vsnprintf.c
>> +++ b/common/libc/vsnprintf.c
>> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *f=
mt, va_list args)
>>         if ( *fmt !=3D '%' )
>>         {
>>             PUT(*fmt);
>> +
>> +            /*
>> +             * The '\n' character alone on some terminals is not automa=
tically
>> +             * converted to LFCR.
>> +             * The explicit LFCR sequence guarantees proper line by line
>> +             * formatting in the output.
>> +             */
>> +            if ( *fmt =3D=3D '\n' && str < end )
>> +                PUT('\r');
> =

> ... doesn't this end up putting out \n\r ?

yes, it does

> =

> ~Andrew
> =

>> +
>>             continue;
>>         }
>> =

> =



Best Regards,
Pawel Wieczorkiewicz
wipawel@amazon.com



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 16 11:45:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 11:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP2x5-00083m-4j; Thu, 16 Apr 2020 11:45:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Xq2g=6A=amazon.de=prvs=368a07d89=wipawel@srs-us1.protection.inumbo.net>)
 id 1jP2x3-00083h-SC
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 11:45:01 +0000
X-Inumbo-ID: b45ce5b6-7fd7-11ea-b4f4-bc764e2007e4
Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b45ce5b6-7fd7-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 11:45:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587037502; x=1618573502;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:mime-version:content-transfer-encoding:subject;
 bh=MsCDHqnsOetk3Dzm8XZOfBpxwNjbELnvC6olGu/VtZ8=;
 b=CvbvGHuyXJg+RvqQgC38LTL29Rxg1lAlVZT6seJl3q6MZXFqFyw1oPMA
 0ZVN/QDnne2vHeOoVew1eW+a+yZhVBYs9sA6llp8ZleuxK4hwa3rLMwBJ
 dO9I+AdlSoIlLeCYChuWHgvj0lMWUtwRFM1LdgysElqdzoFeFx8v8FXFP Y=;
IronPort-SDR: V2pBEwcyKocyPXA+BIVc668LO1sKPDzf7UQl+plxQh1IKSFBM5efyVPCNwi9mh+3mD6v8YUHOf
 hTCjkJw4zCuA==
X-IronPort-AV: E=Sophos;i="5.72,390,1580774400"; d="scan'208";a="37412680"
Subject: Re: [XTF 3/4] Enabled serial writing for hvm guests
Thread-Topic: [XTF 3/4] Enabled serial writing for hvm guests
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-1e-c7c08562.us-east-1.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP;
 16 Apr 2020 11:44:59 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])
 by email-inbound-relay-1e-c7c08562.us-east-1.amazon.com (Postfix) with ESMTPS
 id 4A43A241B3F; Thu, 16 Apr 2020 11:44:57 +0000 (UTC)
Received: from EX13D05EUB001.ant.amazon.com (10.43.166.87) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 11:44:56 +0000
Received: from EX13D05EUB004.ant.amazon.com (10.43.166.115) by
 EX13D05EUB001.ant.amazon.com (10.43.166.87) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 11:44:55 +0000
Received: from EX13D05EUB004.ant.amazon.com ([10.43.166.115]) by
 EX13D05EUB004.ant.amazon.com ([10.43.166.115]) with mapi id 15.00.1497.006;
 Thu, 16 Apr 2020 11:44:55 +0000
From: "Wieczorkiewicz, Pawel" <wipawel@amazon.de>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Thread-Index: AQHWE9NGGLvUKlPnBky0fF8RmnZleKh7jQGAgAAUPYA=
Date: Thu, 16 Apr 2020 11:44:55 +0000
Message-ID: <987F9723-8B54-4908-8AED-F265C0F7E1AC@amazon.com>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-4-wipawel@amazon.de>
 <501cc157-b260-bca0-2920-f4e3a8a07c1b@citrix.com>
In-Reply-To: <501cc157-b260-bca0-2920-f4e3a8a07c1b@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.165.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9E9FD017AB6D9844ACAF970D8DAF4A62@amazon.com>
MIME-Version: 1.0
Precedence: Bulk
Content-Transfer-Encoding: base64
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Semel <phentex@amazon.de>, Julien Grall <julien@xen.org>,
 "paul@xen.org" <paul@xen.org>, "semelpaul@gmail.com" <semelpaul@gmail.com>,
 "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Wieczorkiewicz,
 Pawel" <wipawel@amazon.de>, "Manthey, Norbert" <nmanthey@amazon.de>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQo+IE9uIDE2LiBBcHIgMjAyMCwgYXQgMTI6MzIsIEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29w
ZXIzQGNpdHJpeC5jb20+IHdyb3RlOg0KPiANCj4gQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5h
dGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mg
b3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXIgYW5k
IGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IA0KPiANCj4gT24gMTYvMDQvMjAyMCAx
MDo0MSwgUGF3ZWwgV2llY3pvcmtpZXdpY3ogd3JvdGU6DQo+PiBGcm9tOiBQYXVsIFNlbWVsIDxw
aGVudGV4QGFtYXpvbi5kZT4NCj4+IA0KPj4gc2V0dXAuYzogUFYgY29uc29sZSB3cml0aW5nIGlz
IG5vdCB3b3JraW5nIGluIFhlbiA0LjIgZm9yIGh2bQ0KPj4gZ3Vlc3RzLA0KPiANCj4gV2hhdCBp
cyBub3Qgd29ya2luZyBhYm91dCBpdD8NCj4gDQoNCkhvbmVzdGx5IEkgYW0gbGl0dGxlIHNob3J0
IG9uIGRldGFpbHMgaGVyZSwgSSB3b3VsZCBoYXZlIHRvIGFzayBQYXVsIG9yIHJlZnJlc2ggbXkg
bWVtb3J5Lg0KDQo+PiBzbyB3ZSBtYWtlIHh0ZiB3cml0ZSB0byBDT00xIHNlcmlhbCBwb3J0IHRv
IGdldCBpdHMgb3V0cHV0DQo+PiANCj4+IFNpZ25lZC1vZmYtYnk6IFBhdWwgU2VtZWwgPHBoZW50
ZXhAYW1hem9uLmRlPg0KPj4gU2lnbmVkLW9mZi1ieTogUGF3ZWwgV2llY3pvcmtpZXdpY3ogPHdp
cGF3ZWxAYW1hem9uLmRlPg0KPj4gLS0tDQo+PiBhcmNoL3g4Ni9zZXR1cC5jIHwgMTQgKysrKysr
KysrKysrKysNCj4+IDEgZmlsZSBjaGFuZ2VkLCAxNCBpbnNlcnRpb25zKCspDQo+PiANCj4+IGRp
ZmYgLS1naXQgYS9hcmNoL3g4Ni9zZXR1cC5jIGIvYXJjaC94ODYvc2V0dXAuYw0KPj4gaW5kZXgg
M2M4NGU5Ni4uZjZmYTRkZiAxMDA2NDQNCj4+IC0tLSBhL2FyY2gveDg2L3NldHVwLmMNCj4+ICsr
KyBiL2FyY2gveDg2L3NldHVwLmMNCj4+IEBAIC0yMzgsNiArMjM4LDEzIEBAIHN0YXRpYyB2b2lk
IHFlbXVfY29uc29sZV93cml0ZShjb25zdCBjaGFyICpidWYsIHNpemVfdCBsZW4pDQo+PiAgICAg
ICAgICAgICAgICAgIDogImQiICgweDEyKSk7DQo+PiB9DQo+PiANCj4+ICtzdGF0aWMgdm9pZCBj
b20xX3dyaXRlKGNvbnN0IGNoYXIgKmJ1Ziwgc2l6ZV90IGxlbikNCj4+ICt7DQo+PiArICAgIGFz
bSB2b2xhdGlsZSgicmVwOyBvdXRzYiINCj4+ICsgICAgICAgICAgICAgICAgIDogIitTIiAoYnVm
KSwgIitjIiAobGVuKQ0KPj4gKyAgICAgICAgICAgICAgICAgOiAiZCIgKDB4M2Y4KSk7DQo+IA0K
PiBEZXNwaXRlIGJlaW5nIDB4M2Y4LCB0aGlzIHJlYWxseSBpc24ndCB1YXJ0LWNvbXBhdGlibGUg
Q09NMS4gIEkgcHJlc3VtZQ0KPiBpdCBvbmx5IHdvcmtzIGJlY2F1c2UgUWVtdSBkb2Vzbid0IGhh
dmUgYW55IHJlYWwgVEhSIGRlbGF5cyBpbiBpdHMNCj4gZW11bGF0aW9uLg0KPiANCg0KVGhhdCBj
YW4gYmUuIE5ldmVydGhlbGVzcywgaXQgd29ya3MgZm9yIG1lW3RtXS4NCg0KPj4gK30NCj4+ICsN
Cj4+IHN0YXRpYyB2b2lkIHhlbl9jb25zb2xlX3dyaXRlKGNvbnN0IGNoYXIgKmJ1Ziwgc2l6ZV90
IGxlbikNCj4+IHsNCj4+ICAgICBoeXBlcmNhbGxfY29uc29sZV93cml0ZShidWYsIGxlbik7DQo+
PiBAQCAtMjQ2LDcgKzI1MywxNCBAQCBzdGF0aWMgdm9pZCB4ZW5fY29uc29sZV93cml0ZShjb25z
dCBjaGFyICpidWYsIHNpemVfdCBsZW4pDQo+PiB2b2lkIGFyY2hfc2V0dXAodm9pZCkNCj4+IHsN
Cj4+ICAgICBpZiAoIElTX0RFRklORUQoQ09ORklHX0hWTSkgJiYgIXB2aF9zdGFydF9pbmZvICkN
Cj4+ICsgICAgew0KPj4gICAgICAgICByZWdpc3Rlcl9jb25zb2xlX2NhbGxiYWNrKHFlbXVfY29u
c29sZV93cml0ZSk7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCBJU19ERUZJTkVEKENP
TkZJR19IVk0pICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcmVnaXN0ZXJfY29uc29sZV9jYWxs
YmFjayhjb20xX3dyaXRlKTsNCj4gDQo+IFRoaXMgd2lyZXMgdXAgMHgzZjggZXZlbiBmb3IgUFZI
IGd1ZXN0cywgd2hpY2ggSSdtIGd1ZXNzaW5nIGlzbid0DQo+IGludGVudGlvbmFsPyAgVGhpcyBz
aG91bGQgYmUgcGFydCBvZiB0aGUgcHJldmlvdXMgaWYoKSwgYnV0IGRvZXMgYmVnIHRoZQ0KPiBx
dWVzdGlvbiB3aGF0IGlzIHdyb25nIHdpdGggdGhlIGV4aXN0aW5nIHFlbXUgY29uc29sZT8NCj4g
DQoNCkl0IHR1cm5zIG91dCB0aGF0IGJvdGggUFZIIGFuZCBIVk0gZ3Vlc3RzIGFyZSBQVkggQUJJ
IGNvbXBhdGlibGUsDQpidXQgUFZIIGRvZXMgbm90IG5lZWQgcWVtdSBjb25zb2xlLiBBcyBwZXI6
DQoNCjAxZTE2Y2ViIGFyY2gveDg2L2h2bS9oZWFkLlMgICAgICAoQW5kcmV3IENvb3BlciAgICAg
ICAgMjAxOC0wMS0yNiAxNjozOToxNSArMDAwMCAzNikgLyogQWxsIEhWTSBYVEYgZ3Vlc3RzIGFy
ZSBjb21wYXRpYmxlIHdpdGggdGhlIFBWSCBBQkkuICovDQoNCkluIG9yZGVyIHRvIGdldCBzZXJp
YWwgY29uc29sZSB2aWEgcWVtdSB3b3JraW5nLCBJIGFsd2F5cyByZWdpc3RlciBjb20xDQpoYW5k
bGVyIGZvciBib3RoIEhWTSBhbmQgUFZILiBSZWdpc3RlciBxZW11IGNvbnNvbGUgb25seSBmb3Ig
SFZNIGd1ZXN0cy4NCg0KPiB+QW5kcmV3DQoNCkkgdXNlIHRoZSBjb20xIHRvIG1ha2UgcWVtdSB3
cml0ZSBjb25zb2xlIG91dHB1dCB0byBhIGZpbGUgdmlhOiBzZXJpYWw94oCcZmlsZTovdG1wL+KA
puKAnQ0KDQpCZXN0IFJlZ2FyZHMsDQpQYXdlbCBXaWVjem9ya2lld2ljeg0Kd2lwYXdlbEBhbWF6
b24uY29tDQoKCgpBbWF6b24gRGV2ZWxvcG1lbnQgQ2VudGVyIEdlcm1hbnkgR21iSApLcmF1c2Vu
c3RyLiAzOAoxMDExNyBCZXJsaW4KR2VzY2hhZWZ0c2Z1ZWhydW5nOiBDaHJpc3RpYW4gU2NobGFl
Z2VyLCBKb25hdGhhbiBXZWlzcwpFaW5nZXRyYWdlbiBhbSBBbXRzZ2VyaWNodCBDaGFybG90dGVu
YnVyZyB1bnRlciBIUkIgMTQ5MTczIEIKU2l0ejogQmVybGluClVzdC1JRDogREUgMjg5IDIzNyA4
NzkKCgo=



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 11:50:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 11:50:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP31z-0000Nm-UJ; Thu, 16 Apr 2020 11:50:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=FuWY=6A=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jP31z-0000G0-0q
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 11:50:07 +0000
X-Inumbo-ID: 6a732658-7fd8-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6a732658-7fd8-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 11:50:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=rnZu8jPWUQl/Vf5EjZVZqzR8pVvKBUltUctAIRVe6Aw=; b=KdXk8SFEX3bZgarjgMedOWnTum
 kaEu+YquL+Xaps8eY3JxK6CB2oJ2zuB4vro6Z7KZzRHy/WP75FJCa5fwqPMh55gS3iBvTwn9QNGCm
 4H12AfgPqwpYH3ibGr5yZi743ezNlqskifc740fO7VYfO84PdTrxNvE4KwbKtPglqpW0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jP31w-0003AC-MV; Thu, 16 Apr 2020 11:50:04 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jP31w-0004ky-Fr; Thu, 16 Apr 2020 11:50:04 +0000
Subject: Re: [PATCH 01/17] xen/x86: Introduce helpers to generate/convert the
 CR3 from/to a MFN/GFN
To: Jan Beulich <jbeulich@suse.com>
References: <20200322161418.31606-1-julien@xen.org>
 <20200322161418.31606-2-julien@xen.org>
 <4896eacc-10ce-5db9-3990-d74fb05e2ef0@suse.com>
 <6d544a04-72a2-0407-64da-789f9a82b0e0@xen.org>
 <dfa94f76-8e6e-4e17-9173-bb210e60eadd@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <9bcfb1f0-a7d6-7187-9161-b17cd7e17bf6@xen.org>
Date: Thu, 16 Apr 2020 12:50:02 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <dfa94f76-8e6e-4e17-9173-bb210e60eadd@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 30/03/2020 08:38, Jan Beulich wrote:
> Maybe some variation thereof:
> 
>   - hvm_cr3_to_gfn()/hvm_gfn_to_cr3(): Handle the CR3 for HVM guest
>   - {pv,compat}_mfn_to_cr3()/{pv,compat}_cr3_to_mfn(): Handle the CR3 for PV guest
>   - cr3_to_mfn()/mfn_to_cr3(): To handle the host cr3
> 
> ? This is because I'd prefer to avoid host_ prefixes (albeit I'm
> not entirely opposed to such), and I'd also prefer to use xen_
> prefixes as they're generally ambiguous as to what aspect of "Xen"
> they actually mean.

I am happy with your suggested naming. I will have a look to see how 
they fit in the tree and respin the series.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 11:51:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 11:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP33Z-0000ZL-Ab; Thu, 16 Apr 2020 11:51:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Xq2g=6A=amazon.de=prvs=368a07d89=wipawel@srs-us1.protection.inumbo.net>)
 id 1jP33Y-0000ZF-9P
 for xen-devel@lists.xen.org; Thu, 16 Apr 2020 11:51:44 +0000
X-Inumbo-ID: a48843d2-7fd8-11ea-9e09-bc764e2007e4
Received: from smtp-fw-6001.amazon.com (unknown [52.95.48.154])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a48843d2-7fd8-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 11:51:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587037904; x=1618573904;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:mime-version:content-transfer-encoding:subject;
 bh=bACNbQMGENTkXIxTumUp47YWOAp6aIX03GFXjMekIbA=;
 b=bbg7rhvBRznWgCoAW8eekgYmFCHKwCvfNcbCn0wCBcs/rUylsIjibNg9
 GVBqMBZWJ002T1TA1Iwa5uAr/cBo8YoYNrXfysFh2XePnVpyMchrst8T4
 sCOWKY3B5uB9Rh8R1J1MUSpUxj6uybX0klxkx8G0AZF4ufdsWQt8BT+IJ c=;
IronPort-SDR: CNJL5/AFrLs5MJ4zmIq6+n+nX8ujjn7E/3RrjS5S/AX34BQucokVI7I6lI5575p02uCL7uu94F
 AYMnnRAGDxNA==
X-IronPort-AV: E=Sophos;i="5.72,390,1580774400"; d="scan'208";a="27174727"
Subject: Re: [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2
Thread-Topic: [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2b-55156cd4.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP;
 16 Apr 2020 11:51:31 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2b-55156cd4.us-west-2.amazon.com (Postfix) with ESMTPS
 id 7071EA1E31; Thu, 16 Apr 2020 11:51:30 +0000 (UTC)
Received: from EX13D05EUB004.ant.amazon.com (10.43.166.115) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 11:51:30 +0000
Received: from EX13D05EUB004.ant.amazon.com (10.43.166.115) by
 EX13D05EUB004.ant.amazon.com (10.43.166.115) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 16 Apr 2020 11:51:29 +0000
Received: from EX13D05EUB004.ant.amazon.com ([10.43.166.115]) by
 EX13D05EUB004.ant.amazon.com ([10.43.166.115]) with mapi id 15.00.1497.006;
 Thu, 16 Apr 2020 11:51:29 +0000
From: "Wieczorkiewicz, Pawel" <wipawel@amazon.de>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Thread-Index: AQHWE9NHjcoqxUtZ/EiL7nmmqxalz6h7ji0AgAAU5gA=
Date: Thu, 16 Apr 2020 11:51:28 +0000
Message-ID: <82FE157A-310D-4D4E-9D87-F04DE2E6B26E@amazon.com>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-5-wipawel@amazon.de>
 <e1e910a7-ed94-46e9-6987-fecdd704e104@citrix.com>
In-Reply-To: <e1e910a7-ed94-46e9-6987-fecdd704e104@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.164.70]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6C9E6F85DC83994F9D27CE4DE1E781AD@amazon.com>
MIME-Version: 1.0
Precedence: Bulk
Content-Transfer-Encoding: base64
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Semel <phentex@amazon.de>, "julien@xen.org" <julien@xen.org>,
 "paul@xen.org" <paul@xen.org>, "semelpaul@gmail.com" <semelpaul@gmail.com>,
 "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Wieczorkiewicz,
 Pawel" <wipawel@amazon.de>, "Manthey, Norbert" <nmanthey@amazon.de>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQo+IE9uIDE2LiBBcHIgMjAyMCwgYXQgMTI6MzYsIEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29w
ZXIzQGNpdHJpeC5jb20+IHdyb3RlOg0KPiANCj4gQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5h
dGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mg
b3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXIgYW5k
IGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IA0KPiANCj4gT24gMTYvMDQvMjAyMCAx
MDo0MSwgUGF3ZWwgV2llY3pvcmtpZXdpY3ogd3JvdGU6DQo+PiBAQCAtMjcyLDkgKzI3NCwyMyBA
QCB2b2lkIGFyY2hfc2V0dXAodm9pZCkNCj4+IA0KPj4gICAgIGluaXRfaHlwZXJjYWxscygpOw0K
Pj4gDQo+PiAtICAgIGlmICggIWlzX2luaXRkb21haW4oKSApDQo+PiArICAgIHhlbl92ZXJzaW9u
ID0gaHlwZXJjYWxsX3hlbl92ZXJzaW9uKFhFTlZFUl92ZXJzaW9uLCBOVUxMKTsNCj4+ICsgICAg
aWYgKCB2ZXJzaW9uICkNCj4+ICsgICAgICAgICp2ZXJzaW9uID0geGVuX3ZlcnNpb247DQo+PiAr
DQo+PiArICAgIC8qDQo+PiArICAgICAqIFRoZSBzZXR1cF9wdl9jb25zb2xlIGZ1bmN0aW9uIHJl
Z2lzdGVycyBhIHdyaXRpbmcgZnVuY3Rpb24NCj4+ICsgICAgICogdGhhdCBtYWtlcyBodm0gZ3Vl
c3RzIGNyYXNoIG9uIFhlbiA0LjINCj4gDQo+IFRoaXMgY29tbWVudCBpbiBwYXJ0aWN1bGFyIGlz
IHJhdGhlciBjb25jZXJuaW5nLiAgRXZlbiBpZiB0aGVyZSBpcyBhDQo+IGNvbmZpZ3VyYXRpb24g
aXNzdWUgaW4gNC4yIHN0b3BwaW5nIHRoZSBQViBjb25zb2xlIGZyb20gYmVpbmcgd2lyZWQgdXAN
Cj4gcHJvcGVybHksIG5vdGhpbmcgaW52b2x2ZWQgaW4gdHJhbnNtaXR0aW5nIG9uIHRoZSBjb25z
b2xlIHNob3VsZCBjcmFzaA0KPiB0aGUgZ3Vlc3QuDQo+IA0KDQpJIGFtIGFnYWluIGEgbGl0dGxl
IHNob3J0IG9uIGRldGFpbHMgaGVyZS4gTWF5YmUgUGF1bCBjb3VsZCBjaGltZSBpbi4NCkJ1dCwg
SSB2YWd1YWx5IHJlbWVtYmVyIGl0IHdhcyBzb21ldGhpbmcgYWJvdXQgdGhlIGluaXRfcHZfY29u
c29sZSgp4oCZczoNCg0KICAgIGlmICggcG9ydCA+PSAoc2l6ZW9mKHNoYXJlZF9pbmZvLmV2dGNo
bl9wZW5kaW5nKSAqIENIQVJfQklUKSApDQogICAgICAgIHBhbmljKCJldnRjaG4gJXUgb3V0IG9m
IGV2dGNobl9wZW5kaW5nW10gcmFuZ2VcbiIsIHBvcnQpOw0KDQo+IH5BbmRyZXcNCg0KDQpCZXN0
IFJlZ2FyZHMsDQpQYXdlbCBXaWVjem9ya2lld2ljeg0Kd2lwYXdlbEBhbWF6b24uY29tDQoKCgpB
bWF6b24gRGV2ZWxvcG1lbnQgQ2VudGVyIEdlcm1hbnkgR21iSApLcmF1c2Vuc3RyLiAzOAoxMDEx
NyBCZXJsaW4KR2VzY2hhZWZ0c2Z1ZWhydW5nOiBDaHJpc3RpYW4gU2NobGFlZ2VyLCBKb25hdGhh
biBXZWlzcwpFaW5nZXRyYWdlbiBhbSBBbXRzZ2VyaWNodCBDaGFybG90dGVuYnVyZyB1bnRlciBI
UkIgMTQ5MTczIEIKU2l0ejogQmVybGluClVzdC1JRDogREUgMjg5IDIzNyA4NzkKCgo=



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:14:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:14:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3Pe-0002NO-FV; Thu, 16 Apr 2020 12:14:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP3Pd-0002NJ-7O
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:14:33 +0000
X-Inumbo-ID: d324d632-7fdb-11ea-8b7c-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d324d632-7fdb-11ea-8b7c-12813bfff9fa;
 Thu, 16 Apr 2020 12:14:32 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CF5BDAC6D;
 Thu, 16 Apr 2020 12:14:30 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86emul: SYSRET must change CPL
Message-ID: <d193babc-9afa-7cff-13f4-532e62d5e3e6@suse.com>
Date: Thu, 16 Apr 2020 14:14:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The special AMD behavior of leaving SS mostly alone wasn't really
complete: We need to adjust CPL aka SS.DPL.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6022,6 +6022,8 @@ x86_emulate(
 
             /* There's explicitly no RPL adjustment here. */
             sreg.sel = (msr_val >> 48) + 8;
+            /* But DPL needs adjustment, for the new CPL to be correct. */
+            sreg.dpl = 3;
         }
 
 #ifdef __x86_64__


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:19:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:19:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3U5-0002Xe-3E; Thu, 16 Apr 2020 12:19:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP3U3-0002XZ-JN
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:19:07 +0000
X-Inumbo-ID: 77a79684-7fdc-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 77a79684-7fdc-11ea-83d8-bc764e2007e4;
 Thu, 16 Apr 2020 12:19:07 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6DBD1AC6D;
 Thu, 16 Apr 2020 12:19:05 +0000 (UTC)
Subject: Re: [[PATCH v3]] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
To: Julien Grall <julien@xen.org>
References: <20200416112423.25755-1-julien@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <495b74dc-3ee3-ff23-99ce-2fa4a17d57a4@suse.com>
Date: Thu, 16 Apr 2020 14:19:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416112423.25755-1-julien@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.2020 13:24, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
> data to guest handle marked const.
> 
> Thankfully, no users of the helper will do that. Rather than hoping this
> can be caught during review, harden copy_to_guest_offset() so the build
> will fail if such users are introduced.
> 
> There is no easy way to check whether a const is NULL in C99. The
> approach used is to introduce an unused variable that is non-const and
> assign the handle. If the handle were const, this would fail at build
> because without an explicit cast, it is not possible to assign a const
> variable to a non-const variable.
> 
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Julien Grall <jgrall@amazon.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
with one further remark:

> --- a/xen/include/asm-x86/guest_access.h
> +++ b/xen/include/asm-x86/guest_access.h
> @@ -87,6 +87,8 @@
>  #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
>      const typeof(*(ptr)) *_s = (ptr);                   \
>      char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
> +    /* Check if the handle is not const */              \
> +    void *__maybe_unused _t = (hnd).p;                  \

Not being a native speaker, to me "if" doesn't look appropriate
here. I'd use "that" instead, but you may want to confirm this.
Overall then maybe "Check that the handle is not for a const type"?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:26:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3ad-0003NM-TY; Thu, 16 Apr 2020 12:25:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=ZWjb=6A=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jP3ac-0003NH-96
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:25:54 +0000
X-Inumbo-ID: 69771412-7fdd-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x529.google.com (unknown [2a00:1450:4864:20::529])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 69771412-7fdd-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 12:25:52 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id s10so8374801edy.9
 for <xen-devel@lists.xenproject.org>; Thu, 16 Apr 2020 05:25:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=Z9eLh4KNhywGN0NPizPWZ1qOndO9/IFnmP6hHS/DlDQ=;
 b=M95mbC0o1pKWyI3wiy5NVmHOEvBXEoOWKr0tP5azTXfj6Ja6Jmbt/GqtowfefS734K
 GqZdNgCG3dluYlM5TAU6NyTk6ykOjkh7vwRo/tbprlRNleIM4d0AWhyK0fw2+9zPCnhh
 RnQJ1Xm3+QbYgsOrBwBiitiXfcJYBG4uh1wzs6ignFl5ZbcvL62IpfluQ5tDUl7reiDf
 vkcN/rqEmLNFFTvj9OjNRXlPjR4G69onGjt0TJusQ4bmK9r6BJ9QXf10u7synn8V6F3x
 IPA7PnvhJ6sZ0zt+O6/6H9b5jXLB8cgzw+XfybrBsY32atDQL5SyWj5iCH/Vy347Fffg
 UfCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=Z9eLh4KNhywGN0NPizPWZ1qOndO9/IFnmP6hHS/DlDQ=;
 b=FAbRWGRQWTnS6H8x6KHsTWopfb3SpXYRXtgrgr7MwK3duMFTeAa/l00zgQJslxwqcm
 Hgkx+y2wnoEbpmgLyTB8UvQkW0zzJ6rf5ZS/gyXpRxpG+NkcROwDkgx0c4aw9800meCx
 F8N3Lc1HHKP7AtvfGdpMEgJ3X54TNJAcV/xuV8TKUJeZoqqE//8ixfg1xKSiy/gTjgxB
 tY5fqQ1GqoSzlP9edHCFeXInhwOjMlO+JvAfKZRsiguFhcxyx5xyfDHTZu8ykQVK7PB9
 WjdDEjZFFVRhQBAduF2ZXROkxj5k09gUT4Eoz9hIkV5hL12tUj9M7HTC2gIdO8Scjl0W
 L66Q==
X-Gm-Message-State: AGi0Pub7C1u0+I83YsvMCetUibzr9KBGMHI37puNX2rQcdf3xGEgyxPl
 Vnogqo0rGZB08/Lf1Qct45A=
X-Google-Smtp-Source: APiQypIKiKntxb+N4LDk596sshvc10VTLmIuJ9CfimgMGhnwCQORoe0m3noyI3LAWzOFU0iZNVfhcg==
X-Received: by 2002:a50:d71e:: with SMTP id t30mr12139687edi.246.1587039951839; 
 Thu, 16 Apr 2020 05:25:51 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id q1sm2962274ejf.42.2020.04.16.05.25.50
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 16 Apr 2020 05:25:51 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>,
	<xen-devel@lists.xenproject.org>
References: <d9a53b50-472d-477a-6275-ada0cb6e87e6@suse.com>
 <a4361808-82f9-5b59-2c89-b3b4ee8a111b@suse.com>
In-Reply-To: <a4361808-82f9-5b59-2c89-b3b4ee8a111b@suse.com>
Subject: RE: [PATCH v6 03/10] x86emul: support MOVDIR{I,64B} insns
Date: Thu, 16 Apr 2020 13:25:50 +0100
Message-ID: <000801d613ea$2aa093d0$7fe1bb70$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJ9+FkQ6sJgtx/RrR3D4m8VxfWo0AHYmyKkpx0dMwA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>, 'Wei Liu' <wl@xen.org>,
 'Roger Pau Monne' <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 14 April 2020 12:45
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; Wei Liu <wl@xen.org>; Roger Pau Monne
> <roger.pau@citrix.com>; Paul Durrant <paul@xen.org>
> Subject: [PATCH v6 03/10] x86emul: support MOVDIR{I,64B} insns
> 
> Introduce a new blk() hook, paralleling the rmw() one in a certain way,
> but being intended for larger data sizes, and hence its HVM intermediate
> handling function doesn't fall back to splitting the operation if the
> requested virtual address can't be mapped.
> 
> Note that SDM revision 071 doesn't specify exception behavior for
> ModRM.mod == 0b11; assuming #UD here.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

hvm/emulate part...

Reviewed-by: Paul Durrant <paul@xen.org>

> ---
> v6: Fold MOVDIRI and MOVDIR64B changes again. Use blk() for both. All
>     tags dropped.
> v5: Introduce/use ->blk() hook. Correct asm() operands.
> v4: Split MOVDIRI and MOVDIR64B and move this one ahead. Re-base.
> v3: Update description.
> ---
> (SDE: -tnt)
> 
> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -652,6 +652,18 @@ static int cmpxchg(
>      return X86EMUL_OKAY;
>  }
> 
> +static int blk(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    uint32_t *eflags,
> +    struct x86_emulate_state *state,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    return x86_emul_blk((void *)offset, p_data, bytes, eflags, state, ctxt);
> +}
> +
>  static int read_segment(
>      enum x86_segment seg,
>      struct segment_register *reg,
> @@ -2339,6 +2351,54 @@ int main(int argc, char **argv)
>          goto fail;
>      printf("okay\n");
> 
> +    emulops.blk = blk;
> +
> +    printf("%-40s", "Testing movdiri %edx,(%ecx)...");
> +    if ( stack_exec && cpu_has_movdiri )
> +    {
> +        instr[0] = 0x0f; instr[1] = 0x38; instr[2] = 0xf9; instr[3] = 0x11;
> +
> +        regs.eip = (unsigned long)&instr[0];
> +        regs.ecx = (unsigned long)memset(res, -1, 16);
> +        regs.edx = 0x44332211;
> +
> +        rc = x86_emulate(&ctxt, &emulops);
> +        if ( (rc != X86EMUL_OKAY) ||
> +             (regs.eip != (unsigned long)&instr[4]) ||
> +             res[0] != 0x44332211 || ~res[1] )
> +            goto fail;
> +        printf("okay\n");
> +    }
> +    else
> +        printf("skipped\n");
> +
> +    printf("%-40s", "Testing movdir64b 144(%edx),%ecx...");
> +    if ( stack_exec && cpu_has_movdir64b )
> +    {
> +        instr[0] = 0x66; instr[1] = 0x0f; instr[2] = 0x38; instr[3] = 0xf8;
> +        instr[4] = 0x8a; instr[5] = 0x90; instr[8] = instr[7] = instr[6] = 0;
> +
> +        regs.eip = (unsigned long)&instr[0];
> +        for ( i = 0; i < 64; ++i )
> +            res[i] = i - 20;
> +        regs.edx = (unsigned long)res;
> +        regs.ecx = (unsigned long)(res + 16);
> +
> +        rc = x86_emulate(&ctxt, &emulops);
> +        if ( (rc != X86EMUL_OKAY) ||
> +             (regs.eip != (unsigned long)&instr[9]) ||
> +             res[15] != -5 || res[32] != 12 )
> +            goto fail;
> +        for ( i = 16; i < 32; ++i )
> +            if ( res[i] != i )
> +                goto fail;
> +        printf("okay\n");
> +    }
> +    else
> +        printf("skipped\n");
> +
> +    emulops.blk = NULL;
> +
>      printf("%-40s", "Testing movq %mm3,(%ecx)...");
>      if ( stack_exec && cpu_has_mmx )
>      {
> --- a/tools/tests/x86_emulator/x86-emulate.h
> +++ b/tools/tests/x86_emulator/x86-emulate.h
> @@ -154,6 +154,8 @@ static inline bool xcr0_mask(uint64_t ma
>  #define cpu_has_avx512_vnni (cp.feat.avx512_vnni && xcr0_mask(0xe6))
>  #define cpu_has_avx512_bitalg (cp.feat.avx512_bitalg && xcr0_mask(0xe6))
>  #define cpu_has_avx512_vpopcntdq (cp.feat.avx512_vpopcntdq && xcr0_mask(0xe6))
> +#define cpu_has_movdiri    cp.feat.movdiri
> +#define cpu_has_movdir64b  cp.feat.movdir64b
>  #define cpu_has_avx512_4vnniw (cp.feat.avx512_4vnniw && xcr0_mask(0xe6))
>  #define cpu_has_avx512_4fmaps (cp.feat.avx512_4fmaps && xcr0_mask(0xe6))
>  #define cpu_has_avx512_bf16 (cp.feat.avx512_bf16 && xcr0_mask(0xe6))
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -250,12 +250,13 @@ $(BASEDIR)/include/asm-x86/asm-macros.h:
>  # sure we pick up changes when the compiler used has changed.)
>  ifeq ($(MAKECMDGOALS),asm-offsets.s)
> 
> -as-ISA-list := CLWB EPT FSGSBASE INVPCID RDRAND RDSEED SSE4_2 VMX XSAVEOPT
> +as-ISA-list := CLWB EPT FSGSBASE INVPCID MOVDIR RDRAND RDSEED SSE4_2 VMX XSAVEOPT
> 
>  CLWB-insn	:= clwb (%rax)
>  EPT-insn	:= invept (%rax),%rax
>  FSGSBASE-insn	:= rdfsbase %rax
>  INVPCID-insn	:= invpcid (%rax),%rax
> +MOVDIR-insn	:= movdiri %rax,(%rax)
>  RDRAND-insn	:= rdrand %eax
>  RDSEED-insn	:= rdseed %eax
>  SSE4_2-insn	:= crc32 %eax,%eax
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1409,6 +1409,44 @@ static int hvmemul_rmw(
>      return rc;
>  }
> 
> +static int hvmemul_blk(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    uint32_t *eflags,
> +    struct x86_emulate_state *state,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    struct hvm_emulate_ctxt *hvmemul_ctxt =
> +        container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
> +    unsigned long addr;
> +    uint32_t pfec = PFEC_page_present | PFEC_write_access;
> +    int rc;
> +    void *mapping = NULL;
> +
> +    rc = hvmemul_virtual_to_linear(
> +        seg, offset, bytes, NULL, hvm_access_write, hvmemul_ctxt, &addr);
> +    if ( rc != X86EMUL_OKAY || !bytes )
> +        return rc;
> +
> +    if ( is_x86_system_segment(seg) )
> +        pfec |= PFEC_implicit;
> +    else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
> +        pfec |= PFEC_user_mode;
> +
> +    mapping = hvmemul_map_linear_addr(addr, bytes, pfec, hvmemul_ctxt);
> +    if ( IS_ERR(mapping) )
> +        return ~PTR_ERR(mapping);
> +    if ( !mapping )
> +        return X86EMUL_UNHANDLEABLE;
> +
> +    rc = x86_emul_blk(mapping, p_data, bytes, eflags, state, ctxt);
> +    hvmemul_unmap_linear_addr(mapping, addr, bytes, hvmemul_ctxt);
> +
> +    return rc;
> +}
> +
>  static int hvmemul_write_discard(
>      enum x86_segment seg,
>      unsigned long offset,
> @@ -2475,6 +2513,7 @@ static const struct x86_emulate_ops hvm_
>      .write         = hvmemul_write,
>      .rmw           = hvmemul_rmw,
>      .cmpxchg       = hvmemul_cmpxchg,
> +    .blk           = hvmemul_blk,
>      .validate      = hvmemul_validate,
>      .rep_ins       = hvmemul_rep_ins,
>      .rep_outs      = hvmemul_rep_outs,
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -548,6 +548,8 @@ static const struct ext0f38_table {
>      [0xf1] = { .to_mem = 1, .two_op = 1 },
>      [0xf2 ... 0xf3] = {},
>      [0xf5 ... 0xf7] = {},
> +    [0xf8] = { .simd_size = simd_other },
> +    [0xf9] = { .to_mem = 1, .two_op = 1 /* Mov */ },
>  };
> 
>  /* Shift values between src and dst sizes of pmov{s,z}x{b,w,d}{w,d,q}. */
> @@ -851,6 +853,9 @@ struct x86_emulate_state {
>          rmw_xchg,
>          rmw_xor,
>      } rmw;
> +    enum {
> +        blk_movdir,
> +    } blk;
>      uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
>      uint8_t sib_index, sib_scale;
>      uint8_t rex_prefix;
> @@ -1914,6 +1919,8 @@ amd_like(const struct x86_emulate_ctxt *
>  #define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
>  #define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
>  #define vcpu_has_rdpid()       (ctxt->cpuid->feat.rdpid)
> +#define vcpu_has_movdiri()     (ctxt->cpuid->feat.movdiri)
> +#define vcpu_has_movdir64b()   (ctxt->cpuid->feat.movdir64b)
>  #define vcpu_has_avx512_4vnniw() (ctxt->cpuid->feat.avx512_4vnniw)
>  #define vcpu_has_avx512_4fmaps() (ctxt->cpuid->feat.avx512_4fmaps)
>  #define vcpu_has_avx512_bf16() (ctxt->cpuid->feat.avx512_bf16)
> @@ -2722,10 +2729,12 @@ x86_decode_0f38(
>      {
>      case 0x00 ... 0xef:
>      case 0xf2 ... 0xf5:
> -    case 0xf7 ... 0xff:
> +    case 0xf7 ... 0xf8:
> +    case 0xfa ... 0xff:
>          op_bytes = 0;
>          /* fall through */
>      case 0xf6: /* adcx / adox */
> +    case 0xf9: /* movdiri */
>          ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
>          break;
> 
> @@ -10171,6 +10180,34 @@ x86_emulate(
>                              : "0" ((uint32_t)src.val), "rm" (_regs.edx) );
>          break;
> 
> +    case X86EMUL_OPC_66(0x0f38, 0xf8): /* movdir64b r,m512 */
> +        host_and_vcpu_must_have(movdir64b);
> +        generate_exception_if(ea.type != OP_MEM, EXC_UD);
> +        src.val = truncate_ea(*dst.reg);
> +        generate_exception_if(!is_aligned(x86_seg_es, src.val, 64, ctxt, ops),
> +                              EXC_GP, 0);
> +        fail_if(!ops->blk);
> +        state->blk = blk_movdir;
> +        BUILD_BUG_ON(sizeof(*mmvalp) < 64);
> +        if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp, 64,
> +                             ctxt)) != X86EMUL_OKAY ||
> +             (rc = ops->blk(x86_seg_es, src.val, mmvalp, 64, &_regs.eflags,
> +                            state, ctxt)) != X86EMUL_OKAY )
> +            goto done;
> +        state->simd_size = simd_none;
> +        break;
> +
> +    case X86EMUL_OPC(0x0f38, 0xf9): /* movdiri mem,r */
> +        host_and_vcpu_must_have(movdiri);
> +        generate_exception_if(dst.type != OP_MEM, EXC_UD);
> +        fail_if(!ops->blk);
> +        state->blk = blk_movdir;
> +        if ( (rc = ops->blk(dst.mem.seg, dst.mem.off, &src.val, op_bytes,
> +                            &_regs.eflags, state, ctxt)) != X86EMUL_OKAY )
> +            goto done;
> +        dst.type = OP_NONE;
> +        break;
> +
>  #ifndef X86EMUL_NO_SIMD
> 
>      case X86EMUL_OPC_VEX_66(0x0f3a, 0x00): /* vpermq $imm8,ymm/m256,ymm */
> @@ -11429,6 +11466,77 @@ int x86_emul_rmw(
> 
>      return X86EMUL_OKAY;
>  }
> +
> +int x86_emul_blk(
> +    void *ptr,
> +    void *data,
> +    unsigned int bytes,
> +    uint32_t *eflags,
> +    struct x86_emulate_state *state,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    switch ( state->blk )
> +    {
> +        /*
> +         * Throughout this switch(), memory clobbers are used to compensate
> +         * that other operands may not properly express the (full) memory
> +         * ranges covered.
> +         */
> +    case blk_movdir:
> +        switch ( bytes )
> +        {
> +#ifdef __x86_64__
> +        case sizeof(uint32_t):
> +# ifdef HAVE_AS_MOVDIR
> +            asm ( "movdiri %0, (%1)"
> +                 :: "r" (*(uint32_t *)data), "r" (ptr) : "memory" );
> +# else
> +            /* movdiri %esi, (%rdi) */
> +            asm ( ".byte 0x0f, 0x38, 0xf9, 0x37"
> +                  :: "S" (*(uint32_t *)data), "D" (ptr) : "memory" );
> +# endif
> +            break;
> +#endif
> +
> +        case sizeof(unsigned long):
> +#ifdef HAVE_AS_MOVDIR
> +            asm ( "movdiri %0, (%1)"
> +                 :: "r" (*(unsigned long *)data), "r" (ptr) : "memory" );
> +#else
> +            /* movdiri %rsi, (%rdi) */
> +            asm ( ".byte 0x48, 0x0f, 0x38, 0xf9, 0x37"
> +                  :: "S" (*(unsigned long *)data), "D" (ptr) : "memory" );
> +#endif
> +            break;
> +
> +        case 64:
> +            if ( ((unsigned long)ptr & 0x3f) )
> +            {
> +                ASSERT_UNREACHABLE();
> +                return X86EMUL_UNHANDLEABLE;
> +            }
> +#ifdef HAVE_AS_MOVDIR
> +            asm ( "movdir64b (%0), %1" :: "r" (data), "r" (ptr) : "memory" );
> +#else
> +            /* movdir64b (%rsi), %rdi */
> +            asm ( ".byte 0x66, 0x0f, 0x38, 0xf8, 0x3e"
> +                  :: "S" (data), "D" (ptr) : "memory" );
> +#endif
> +            break;
> +
> +        default:
> +            ASSERT_UNREACHABLE();
> +            return X86EMUL_UNHANDLEABLE;
> +        }
> +        break;
> +
> +    default:
> +        ASSERT_UNREACHABLE();
> +        return X86EMUL_UNHANDLEABLE;
> +    }
> +
> +    return X86EMUL_OKAY;
> +}
> 
>  static void __init __maybe_unused build_assertions(void)
>  {
> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -310,6 +310,22 @@ struct x86_emulate_ops
>          struct x86_emulate_ctxt *ctxt);
> 
>      /*
> +     * blk: Emulate a large (block) memory access.
> +     * @p_data: [IN/OUT] (optional) Pointer to source/destination buffer.
> +     * @eflags: [IN/OUT] Pointer to EFLAGS to be updated according to
> +     *                   instruction effects.
> +     * @state:  [IN/OUT] Pointer to (opaque) emulator state.
> +     */
> +    int (*blk)(
> +        enum x86_segment seg,
> +        unsigned long offset,
> +        void *p_data,
> +        unsigned int bytes,
> +        uint32_t *eflags,
> +        struct x86_emulate_state *state,
> +        struct x86_emulate_ctxt *ctxt);
> +
> +    /*
>       * validate: Post-decode, pre-emulate hook to allow caller controlled
>       * filtering.
>       */
> @@ -793,6 +809,14 @@ x86_emul_rmw(
>      unsigned int bytes,
>      uint32_t *eflags,
>      struct x86_emulate_state *state,
> +    struct x86_emulate_ctxt *ctxt);
> +int
> +x86_emul_blk(
> +    void *ptr,
> +    void *data,
> +    unsigned int bytes,
> +    uint32_t *eflags,
> +    struct x86_emulate_state *state,
>      struct x86_emulate_ctxt *ctxt);
> 
>  static inline void x86_emul_hw_exception(
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -120,6 +120,8 @@
>  #define cpu_has_avx512_bitalg   boot_cpu_has(X86_FEATURE_AVX512_BITALG)
>  #define cpu_has_avx512_vpopcntdq boot_cpu_has(X86_FEATURE_AVX512_VPOPCNTDQ)
>  #define cpu_has_rdpid           boot_cpu_has(X86_FEATURE_RDPID)
> +#define cpu_has_movdiri         boot_cpu_has(X86_FEATURE_MOVDIRI)
> +#define cpu_has_movdir64b       boot_cpu_has(X86_FEATURE_MOVDIR64B)
> 
>  /* CPUID level 0x80000007.edx */
>  #define cpu_has_itsc            boot_cpu_has(X86_FEATURE_ITSC)
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -237,6 +237,8 @@ XEN_CPUFEATURE(AVX512_BITALG, 6*32+12) /
>  XEN_CPUFEATURE(AVX512_VPOPCNTDQ, 6*32+14) /*A  POPCNT for vectors of DW/QW */
>  XEN_CPUFEATURE(RDPID,         6*32+22) /*A  RDPID instruction */
>  XEN_CPUFEATURE(CLDEMOTE,      6*32+25) /*A  CLDEMOTE instruction */
> +XEN_CPUFEATURE(MOVDIRI,       6*32+27) /*A  MOVDIRI instruction */
> +XEN_CPUFEATURE(MOVDIR64B,     6*32+28) /*A  MOVDIR64B instruction */
> 
>  /* AMD-defined CPU features, CPUID level 0x80000007.edx, word 7 */
>  XEN_CPUFEATURE(ITSC,          7*32+ 8) /*   Invariant TSC */




From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:27:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:27:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3bq-0003TU-BA; Thu, 16 Apr 2020 12:27:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fNsn=6A=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jP3bp-0003TJ-5P
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:27:09 +0000
X-Inumbo-ID: 93aa684c-7fdd-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 93aa684c-7fdd-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 12:27:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0D00BAC6D;
 Thu, 16 Apr 2020 12:27:01 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH] mini-os: allow 4096 event channels for 64-bit mini-os
Date: Thu, 16 Apr 2020 14:27:00 +0200
Message-Id: <20200416122700.22620-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, samuel.thibault@ens-lyon.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Limiting the number of event channels to 1024 is fine for 32-bit
builds, but not for 64-bit ones. This might be a problem when using
Xenstore-stubdom as the number of domains which can be supported is
then limited to a little bit more than 1000.

So raise the number of event channels to 4096 in 64-bit builds.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 events.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/events.c b/events.c
index 342aead..cdae90f 100644
--- a/events.c
+++ b/events.c
@@ -23,7 +23,7 @@
 #include <mini-os/lib.h>
 #include <xen/xsm/flask_op.h>
 
-#define NR_EVS 1024
+#define NR_EVS EVTCHN_2L_NR_CHANNELS
 
 /* this represents a event handler. Chaining or sharing is not allowed */
 typedef struct _ev_action_t {
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:27:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3cF-0003Wm-MM; Thu, 16 Apr 2020 12:27:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fNsn=6A=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jP3cE-0003WU-Gy
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:27:34 +0000
X-Inumbo-ID: a51e214b-7fdd-11ea-8b81-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a51e214b-7fdd-11ea-8b81-12813bfff9fa;
 Thu, 16 Apr 2020 12:27:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2D0CBAC6D;
 Thu, 16 Apr 2020 12:27:32 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH] mini-os: use -m elf_i386 for final linking
Date: Thu, 16 Apr 2020 14:27:31 +0200
Message-Id: <20200416122731.22713-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, samuel.thibault@ens-lyon.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Using the standard -m elf_x86_64 for 64-bit mini-os results in the
first section (.text) to start only at offset 2MB in the binary file.

Using -m elf_i386 avoids that problem without any visible disadvantage.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/arch.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/arch.mk b/arch/x86/arch.mk
index c87885f..00028a0 100644
--- a/arch/x86/arch.mk
+++ b/arch/x86/arch.mk
@@ -26,3 +26,5 @@ ifeq ($(CONFIG_PARAVIRT),n)
 ARCH_LDFLAGS_FINAL := --oformat=elf32-i386
 ARCH_AS_DEPS += x86_hvm.S
 endif
+
+ARCH_LDFLAGS_FINAL += -m elf_i386
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:28:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3cc-0003ds-3v; Thu, 16 Apr 2020 12:27:58 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fNsn=6A=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jP3cb-0003c0-0W
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:27:57 +0000
X-Inumbo-ID: b036c136-7fdd-11ea-8b81-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b036c136-7fdd-11ea-8b81-12813bfff9fa;
 Thu, 16 Apr 2020 12:27:51 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 003A4AC7B;
 Thu, 16 Apr 2020 12:27:49 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH] mini-os: provide binary without debug information
Date: Thu, 16 Apr 2020 14:27:48 +0200
Message-Id: <20200416122748.22798-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, samuel.thibault@ens-lyon.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Provide a mini-os binary stripped from debug information in order to
have a smaller resulting kernel file. The binary with debug
information is kept with the suffix "-debug".

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 6a05de6..be640cd 100644
--- a/Makefile
+++ b/Makefile
@@ -167,7 +167,9 @@ $(OBJ_DIR)/arch/x86/minios-x86%.lds:  arch/x86/minios-x86.lds.S
 $(OBJ_DIR)/$(TARGET): $(OBJS) $(APP_O) arch_lib $(OBJ_DIR)/$(TARGET_ARCH_DIR)/minios-$(MINIOS_TARGET_ARCH).lds
 	$(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(APP_O) $(OBJS) $(LDARCHLIB) $(LDLIBS) -o $@.o
 	$(OBJCOPY) -w -G $(GLOBAL_PREFIX)* -G _start $@.o $@.o
-	$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@
+	$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@-debug
+	strip -s $@-debug -o $@
+	gzip -n -f -9 -c $@-debug >$@-debug.gz
 	gzip -n -f -9 -c $@ >$@.gz
 
 .PHONY: config
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:29:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:29:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3e5-0003qN-MS; Thu, 16 Apr 2020 12:29:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3QVr=6A=ens-lyon.org=samuel.thibault@srs-us1.protection.inumbo.net>)
 id 1jP3e4-0003qG-Gb
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:29:28 +0000
X-Inumbo-ID: e64e230e-7fdd-11ea-83d8-bc764e2007e4
Received: from hera.aquilenet.fr (unknown [185.233.100.1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e64e230e-7fdd-11ea-83d8-bc764e2007e4;
 Thu, 16 Apr 2020 12:29:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 2ED09AD8B;
 Thu, 16 Apr 2020 14:29:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id R7saMafNshcE; Thu, 16 Apr 2020 14:29:19 +0200 (CEST)
Received: from function (lfbn-bor-1-797-11.w86-234.abo.wanadoo.fr
 [86.234.239.11])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 96418A85A;
 Thu, 16 Apr 2020 14:29:19 +0200 (CEST)
Received: from samy by function with local (Exim 4.93)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1jP3du-004UPj-E0; Thu, 16 Apr 2020 14:29:18 +0200
Date: Thu, 16 Apr 2020 14:29:18 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH] mini-os: allow 4096 event channels for 64-bit mini-os
Message-ID: <20200416122918.p757arqwyvjamwv5@function>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org
References: <20200416122700.22620-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200416122700.22620-1-jgross@suse.com>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Juergen Gross, le jeu. 16 avril 2020 14:27:00 +0200, a ecrit:
> Limiting the number of event channels to 1024 is fine for 32-bit
> builds, but not for 64-bit ones. This might be a problem when using
> Xenstore-stubdom as the number of domains which can be supported is
> then limited to a little bit more than 1000.
> 
> So raise the number of event channels to 4096 in 64-bit builds.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  events.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/events.c b/events.c
> index 342aead..cdae90f 100644
> --- a/events.c
> +++ b/events.c
> @@ -23,7 +23,7 @@
>  #include <mini-os/lib.h>
>  #include <xen/xsm/flask_op.h>
>  
> -#define NR_EVS 1024
> +#define NR_EVS EVTCHN_2L_NR_CHANNELS
>  
>  /* this represents a event handler. Chaining or sharing is not allowed */
>  typedef struct _ev_action_t {
> -- 
> 2.16.4
> 


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:30:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3eh-0004Se-1R; Thu, 16 Apr 2020 12:30:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3QVr=6A=ens-lyon.org=samuel.thibault@srs-us1.protection.inumbo.net>)
 id 1jP3eg-0004N1-Ct
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:30:06 +0000
X-Inumbo-ID: ffd47fd0-7fdd-11ea-9e09-bc764e2007e4
Received: from hera.aquilenet.fr (unknown [2a0c:e300::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ffd47fd0-7fdd-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 12:30:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 498E8AD8C;
 Thu, 16 Apr 2020 14:30:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fLJn6-P7OT8N; Thu, 16 Apr 2020 14:30:02 +0200 (CEST)
Received: from function (lfbn-bor-1-797-11.w86-234.abo.wanadoo.fr
 [86.234.239.11])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id D8D9FAD8B;
 Thu, 16 Apr 2020 14:30:02 +0200 (CEST)
Received: from samy by function with local (Exim 4.93)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1jP3ec-004UQ3-8b; Thu, 16 Apr 2020 14:30:02 +0200
Date: Thu, 16 Apr 2020 14:30:02 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH] mini-os: provide binary without debug information
Message-ID: <20200416123002.hmituo73bydg43kr@function>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org
References: <20200416122748.22798-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200416122748.22798-1-jgross@suse.com>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Juergen Gross, le jeu. 16 avril 2020 14:27:48 +0200, a ecrit:
> Provide a mini-os binary stripped from debug information in order to
> have a smaller resulting kernel file. The binary with debug
> information is kept with the suffix "-debug".
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 6a05de6..be640cd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -167,7 +167,9 @@ $(OBJ_DIR)/arch/x86/minios-x86%.lds:  arch/x86/minios-x86.lds.S
>  $(OBJ_DIR)/$(TARGET): $(OBJS) $(APP_O) arch_lib $(OBJ_DIR)/$(TARGET_ARCH_DIR)/minios-$(MINIOS_TARGET_ARCH).lds
>  	$(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(APP_O) $(OBJS) $(LDARCHLIB) $(LDLIBS) -o $@.o
>  	$(OBJCOPY) -w -G $(GLOBAL_PREFIX)* -G _start $@.o $@.o
> -	$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@
> +	$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@-debug
> +	strip -s $@-debug -o $@
> +	gzip -n -f -9 -c $@-debug >$@-debug.gz
>  	gzip -n -f -9 -c $@ >$@.gz
>  
>  .PHONY: config
> -- 
> 2.16.4
> 


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:44:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3sG-0005bj-FP; Thu, 16 Apr 2020 12:44:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=IxKm=6A=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jP3sF-0005bd-42
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:44:07 +0000
X-Inumbo-ID: f5245c52-7fdf-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f5245c52-7fdf-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 12:44:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587041046;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=ikHcH4cEh6j+kdYwyEUkdhRSJ5cLmyLlvVOpIBQon6c=;
 b=MhVWPsFz56x+L6hHEN/DkN05OwQdVykUTwJzIK97I+cCmplmhJXlOkah
 sYWj3JUp/bSOYvbsFggRMWafcbAFjDPv/EJ8+jGa/WxLXWipxGqdA4C+2
 IuZM9o/DxUiAMrunS0T5gUOeyRLHfoSdvPyuUzNFwn8wPV6IkadsxC3kX E=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: gDc6IXGlsKq6bjl1iT+5J2MWpFL+dDsX8X+cwOLF5FDcY3kir0FF3kUMhedXemcIu0y/I3XCQg
 zrE+T0nnyrKiQ/N3YWGIty/Jzpv7TEDMTm3u8+Q1PpTYqNphUJSjywU25q1vm7MZ6ufaK5YH4W
 LURm+B8jFbEMEFoGAKvAiHZClOew3K/ELGUatHw9KT4/pfxLltxHm6yXrkh2QAAmaAUvlYr9Lj
 D6tBIiEk0zmhwzWHYm/BiXFVLPR1V5xgOS3n7NamIjy1j2hdX9rsMY31IQM4cst+0QAIcp+GET
 hJY=
X-SBRS: 2.7
X-MesageID: 16451258
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="16451258"
Date: Thu, 16 Apr 2020 13:44:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
Message-ID: <20200416124400.GG4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-15-anthony.perard@citrix.com>
 <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
> > We want to use the same rune to build mm/*/guest_*.o as the one use to
> > build every other *.o object. The consequence it that file symbols that
> > the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
> > 
> > (1) Currently we have those two file symbols:
> >     guest_walk.c
> >     guest_walk_2.o
> > (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have:
> >     arch/x86/mm/guest_walk.c
> >     guest_walk_2.o
> > 
> > The order in which those symbols are present may be different.
> > 
> > Currently, in case (1) ./symbols chooses the *.o symbol (object file
> > name). But in case (2), may choose the *.c symbol (source file name with
> > path component) if it is first
> > 
> > We want to have ./symbols choose the object file name symbol in both
> > cases.
> 
> I guess the reason for wanting this is somehow connected to the
> statement at the beginning of the description, but I can't seem
> to be able to make the connection.

I'm not sure I can explain it better.

The "object file name" file symbol is used to distinguish between symbols
from all mm/*/guest_* objects. The other file symbol present in those
object is a "source file name without any path component symbol".

But building those objects with the same rune as any other objects, and
having CONFIG_ENFORCE_UNIQUE_SYMBOLS=y, changes the file symbols present
in the resulting object. We still have the "object file name" symbol,
but now we also have "source file name with path components" symbol.
Unfortunately, all mm/*/guest_*.o in one directory are built from the
same source file, and thus have the same "source file name" symbol, but
have different "object file name" symbol. We still want to be able to
distinguish between guest_*.o in one dir, and the only way for that is
to use the "object file name" symbol.

> > So this patch changes that ./symbols prefer the "object file
> > name" symbol over the "source file name with path component" symbols.
> > 
> > The new intended order of preference is:
> >     - first object file name symbol
> >     - first source file name with path components symbol
> >     - last source file name without any path component symbol
> 
> Isn't this going to lead to ambiguities again when
> CONFIG_ENFORCE_UNIQUE_SYMBOLS? Several object files (in different
> dirs) are named the same, after all. Static symbols with the same
> name in such objects would hence resolve to the same kallsyms
> name.

"object file name" symbol are only present in mm/*/guest_*.o objects,
they all have different basenames. There is no ambiguity here.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:46:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:46:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP3ul-0005iE-UF; Thu, 16 Apr 2020 12:46:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3QVr=6A=ens-lyon.org=samuel.thibault@srs-us1.protection.inumbo.net>)
 id 1jP3uk-0005i9-Bf
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:46:42 +0000
X-Inumbo-ID: 515fa5a8-7fe0-11ea-b58d-bc764e2007e4
Received: from hera.aquilenet.fr (unknown [185.233.100.1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 515fa5a8-7fe0-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 12:46:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id E129E3384;
 Thu, 16 Apr 2020 14:46:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DnbOd6ykFoxr; Thu, 16 Apr 2020 14:46:39 +0200 (CEST)
Received: from function (lfbn-bor-1-797-11.w86-234.abo.wanadoo.fr
 [86.234.239.11])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id E80473251;
 Thu, 16 Apr 2020 14:46:38 +0200 (CEST)
Received: from samy by function with local (Exim 4.93)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1jP3ue-004VIx-W9; Thu, 16 Apr 2020 14:46:37 +0200
Date: Thu, 16 Apr 2020 14:46:36 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH] mini-os: use -m elf_i386 for final linking
Message-ID: <20200416124636.35zgnf5bhq3d3bpw@function>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org
References: <20200416122731.22713-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200416122731.22713-1-jgross@suse.com>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


Juergen Gross, le jeu. 16 avril 2020 14:27:31 +0200, a ecrit:
> Using the standard -m elf_x86_64 for 64-bit mini-os results in the
> first section (.text) to start only at offset 2MB in the binary file.

? I'm not seeing this on my system:

  0 .text         0001933a  0000000000000000  0000000000000000  00001000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

so only 4K offset in the file, the file ends up being 135K big after
stripping.

> Using -m elf_i386 avoids that problem without any visible disadvantage.

Using a 32bit emulation for a 64bit binary? This looks very odd to me?
(and probably fragile)

I'd like to know more where this 2MB binary file offset is coming from,
since AIUI it'd basically impact all binaries built by the toolchain of
your system, not just mini-os, and I don't think the maintainers of your
system want that :)

Samuel


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:57:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP44z-0006dH-3d; Thu, 16 Apr 2020 12:57:17 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=IxKm=6A=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jP44x-0006dC-Ox
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:57:15 +0000
X-Inumbo-ID: cb411716-7fe1-11ea-8b89-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cb411716-7fe1-11ea-8b89-12813bfff9fa;
 Thu, 16 Apr 2020 12:57:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587041834;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=KjAHFwFGo3xfJkkoWvq/QGOD0tYBgW5BJ5r6B2qu7GI=;
 b=gxerxzcNPJbwZqnoWCFs1YAQW8TG/kOZ+QtvDF3XdL9ErKHaLrkvo6cL
 /HpN16m1edbsAPkJ9D+fhqnCLFFBSgC5AK3+RPv9JMdKEPj3WIySWMC3X
 Y9pRW/09xhALirnf7tJyX3b8YlJy6Rvxea/SUut38xrUMFfXrMBonGv5t o=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: xq/EouRQn3r2pn52OH+eeEWFrtYNFerqQ5R1/qiSotgRfTdDY7UDmONykEDiB6YUdBKMMgHvq9
 TuzIatMM4Vns4i6qDjUYlGQUANDmQI2vDXMlYdIm65+MeAISs2uJwCpeQX+OR0szAJLBx59kvd
 ms0wI3VThwj68Ulx2QoBDepZKCnma+XFyEOfKu8wg3Fujp3OCLrQgEGL5XWjYXiAA2RTGPT/yk
 Uj5hEG93CeZO7P/kTnjTYH1Huub+akg8HTdLJ0ayheq+m8CeP/SWLdYkMjRnhUDckoo/ORa4i7
 LNE=
X-SBRS: 2.7
X-MesageID: 16017330
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="16017330"
Date: Thu, 16 Apr 2020 13:57:08 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 15/18] xen/build: use if_changed to build guest_%.o
Message-ID: <20200416125708.GH4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-16-anthony.perard@citrix.com>
 <9bf47db9-e3cf-fffd-cfb2-18dec2317c91@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9bf47db9-e3cf-fffd-cfb2-18dec2317c91@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 03:02:21PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
> > Use if_changed for building all guest_%.o objects, and make use of
> > command that already exist.
> > 
> > This patch make a change to the way guest_%.o files are built, and now
> > run the same commands that enforce unique symbols. But with patch
> > "xen,symbols: rework file symbols selection", ./symbols should still
> > select the file symbols directive intended to be used for guest_%.o
> > objects.
> 
> I'm having trouble making the connection between the change to the
> symbols tool and the adjustments made here:

The change to symbol tool is to allow this change.

> > --- a/xen/arch/x86/mm/Makefile
> > +++ b/xen/arch/x86/mm/Makefile
> > @@ -11,11 +11,13 @@ obj-y += p2m.o p2m-pt.o
> >  obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
> >  obj-y += paging.o
> >  
> > -guest_walk_%.o: guest_walk.c Makefile
> > -	$(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
> 
> The original rules didn't do anything special to arrange for the
> resulting kallsyms names; these arrangements instead live at the
> top of the respective source files, in the form of asm()-s.

They still are. I try to consolidate the number of location which have
command that build a target. Those guest_%.o object aren't special
enough to deserve to be built in a different way than every other
object. They do need a different make rule, but they can use the same
command.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 12:58:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 12:58:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP46O-0006k4-Hc; Thu, 16 Apr 2020 12:58:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fNsn=6A=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jP46N-0006jw-Gf
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 12:58:43 +0000
X-Inumbo-ID: fb03a9ab-7fe1-11ea-8b89-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fb03a9ab-7fe1-11ea-8b89-12813bfff9fa;
 Thu, 16 Apr 2020 12:58:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5208BAC5B;
 Thu, 16 Apr 2020 12:58:34 +0000 (UTC)
Subject: Re: [PATCH] mini-os: use -m elf_i386 for final linking
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
References: <20200416122731.22713-1-jgross@suse.com>
 <20200416124636.35zgnf5bhq3d3bpw@function>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <71871753-d4e5-9afc-9637-479f5ecb2776@suse.com>
Date: Thu, 16 Apr 2020 14:58:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200416124636.35zgnf5bhq3d3bpw@function>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.20 14:46, Samuel Thibault wrote:
> 
> Juergen Gross, le jeu. 16 avril 2020 14:27:31 +0200, a ecrit:
>> Using the standard -m elf_x86_64 for 64-bit mini-os results in the
>> first section (.text) to start only at offset 2MB in the binary file.
> 
> ? I'm not seeing this on my system:
> 
>    0 .text         0001933a  0000000000000000  0000000000000000  00001000  2**12
>                    CONTENTS, ALLOC, LOAD, READONLY, CODE

# readelf -S mini-os
There are 19 section headers, starting at offset 0x245e88:

Section Headers:
   [Nr] Name              Type             Address           Offset
        Size              EntSize          Flags  Link  Info  Align
   [ 0]                   NULL             0000000000000000  00000000
        0000000000000000  0000000000000000           0     0     0
   [ 1] .text             PROGBITS         0000000000000000  00200000
        0000000000017d07  0000000000000000  AX       0     0     4096
   [ 2] .rodata           PROGBITS         0000000000017d20  00217d20

> 
> so only 4K offset in the file, the file ends up being 135K big after
> stripping.

Lucky you. :-)

Might be specific to the linker used.

> 
>> Using -m elf_i386 avoids that problem without any visible disadvantage.
> 
> Using a 32bit emulation for a 64bit binary? This looks very odd to me?
> (and probably fragile)

That is only the final linking process, the option must not be used
earlier (I had linking errors in that case).

> I'd like to know more where this 2MB binary file offset is coming from,
> since AIUI it'd basically impact all binaries built by the toolchain of
> your system, not just mini-os, and I don't think the maintainers of your
> system want that :)

Andrew Cooper gave me the hint how to solve the problem. He has seen it
as well and told me (via IRC):

"I actually figured that out while hacking up a KVM-friendly version of
  XTF for Andy Luto. The linking -m elf_i386/elf_x86_64 option sets the
  "target emulation" which is more than just "what this is compiled for".
  I haven't yet cleaned up the patch for XTF (which also suffers the same
  problem), but linking an ELF64 using -m elf_i386 will DTRT with no
  other ill effects.
  Sadly, LD's documentation about details like this (and the linker
  script for that matter) are poor at best. Specifically, 64bit emulation
  appears to include "align primary sections to 2M so your OS can make
  better use of superpages even when mmap()ing", with no way I can spot
  to override this in the linker file."


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 13:03:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 13:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP4AS-0007aC-3x; Thu, 16 Apr 2020 13:02:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=IxKm=6A=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jP4AQ-0007a7-QC
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 13:02:54 +0000
X-Inumbo-ID: 957c1580-7fe2-11ea-b4f4-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 957c1580-7fe2-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 13:02:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587042174;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=78aAS1DK5EK3sN71rJ8l+oNrB/KTy52SFf9RuDGv1D4=;
 b=ck17y7RFg2RDbRwlbrSuMy7uanu8N7oHyhZ3V++TRmlqOjxSBsyf4nVI
 G+iv6vMEobE2wmCr0coN3NpzC5cNVxYNQQj/Dg6lcqA7pd8k4Vemchm7E
 WpG0zq5QoI5WRMQivdTIO8ewZyUW+K+nT7LFJslbpaPdjmX4e1wzNGoaQ g=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: BzDhvdJnMfoe/lrzX0RnpY4nQ2XmaDAFz9YGibL2yuHsjM8AGb9dyzRa95VR/vuBlkrs0zrwmr
 7kBhTSCw50Vs60AHc2Z0GtjTayXPOEF88HKap/jpvfo6uuifdGd5eD42/1D3hnwg9ZotTAyOWu
 zIiw/fFaHPXRuvG2GB3UxiA04jzHdrvcZJzW0M6sYUNe/CeVuA45o/JwXLmGtTaR4O3OqNvWUe
 0uqABbkXh5KX2StTwGF+4prktFVqyWKMD5mqgUKc1uiHqDscCU9dFfgNeXkxc8lSgrqLLjMlZr
 ycM=
X-SBRS: 2.7
X-MesageID: 16178422
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="16178422"
Date: Thu, 16 Apr 2020 14:02:50 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 16/18] build,xsm: Fix multiple call
Message-ID: <20200416130250.GI4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-17-anthony.perard@citrix.com>
 <809cba94-cebf-29c6-39d5-31ec41bdbdc4@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <809cba94-cebf-29c6-39d5-31ec41bdbdc4@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 03:28:06PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:31, Anthony PERARD wrote:
> > Both script mkflask.sh and mkaccess_vector.sh generates multiple
> > files. Exploits the 'multi-target pattern rule' trick to call each
> > scripts only once.
> 
> Isn't this a general fix, which may even want backporting? If so,
> this would better be at or near the beginning of the series.

It is mostly a performance improvement, avoiding doing the same thing
several time. I don't think anything bad happens from concurrent calls,
or we would already have bug report I think. But I can try to move the
patch up.

> > --- a/xen/xsm/flask/Makefile
> > +++ b/xen/xsm/flask/Makefile
> > @@ -26,14 +26,14 @@ mkflask := policy/mkflask.sh
> >  quiet_cmd_mkflask = MKFLASK $@
> >  cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND)
> >  
> > -$(FLASK_H_FILES): $(FLASK_H_DEPEND) $(mkflask) FORCE
> > +$(patsubst include/%,\%/%,$(FLASK_H_FILES)): $(FLASK_H_DEPEND) $(mkflask) FORCE
> 
> Since what $(FLASK_H_FILES) contains is well under our control,
> how about the simpler
> 
> $(subst include/,%/,$(FLASK_H_FILES)): ...
> 
> ? Preferably with this and preferably with it moved ahead
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

I'll do that, thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 13:08:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 13:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP4FX-0007nz-Un; Thu, 16 Apr 2020 13:08:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=IxKm=6A=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jP4FW-0007nt-S3
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 13:08:10 +0000
X-Inumbo-ID: 51a6ee6a-7fe3-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 51a6ee6a-7fe3-11ea-83d8-bc764e2007e4;
 Thu, 16 Apr 2020 13:08:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587042490;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=2iMs7/0FW6j7l0gvgLW8KPNy22seGZpviEn+sFj8034=;
 b=FcHKc8lcGel4mjLY/JnAuzE2DsLRSHDmoDaWhYa7umgxeyO+dbj6zdcF
 Z9Rk5BpEoi3fp/y3Gpu5URbm71lW+k+tvI/6EmmMhKyt0vweAMy3ELRqS
 1qpgT1vQWzv2H2lPoWBZ4GnJWWx25E/HYBx7ruv9zCBkMK/+QX1D7/kNK A=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: VW022pDUzO1NHq++iN3SaZz2f6Ha7JAhJ7l0kPemwRdjL2jwd0rCbmathVSafIW9mxW7QGGcSI
 XkmTnmFdvnRlObf+3iFUvKpnqdu8rHICgdh8GSmysVSOAWcYMr6WEgmrw/SaPe4znP7ZSGcjXV
 rz/Y9KpBGFFP3XmiQ0YnZ57k+GZwDvMHdU0MJiYbltSqEMyDJwZm1ohw3DzyUm8BV1u4XUz9GU
 n+e+zN0lyIPzECpCaQtIgof1MKgKINnSmJbOOm8I7/qAm4+VMrd8thUAOIBpRvTXtDAZ+Ia02U
 suk=
X-SBRS: 2.7
X-MesageID: 16180504
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="16180504"
Date: Thu, 16 Apr 2020 14:07:48 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 17/18] build, include: rework compat-build-source.py
Message-ID: <20200416130748.GJ4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-18-anthony.perard@citrix.com>
 <57d9630d-d70e-bb20-1d8b-307d2bbc740f@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <57d9630d-d70e-bb20-1d8b-307d2bbc740f@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 03:53:01PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:31, Anthony PERARD wrote:
> > Improvement are:
> > - give the path to xlat.lst as argument
> > - include `grep -v` in compat-build-source.py script, we don't need to
> >   write this in several scripted language.
> > - have 'xlat.lst' path as a variable.
> 
> The change looks okay, but I'm unsure whether it's really worthwhile.
> I specifically dislike the last point above, as it makes things less
> easy to read. I might be willing to ack a patch with this part taken
> out again; faod I'm not meaning to nak the patch in its current form,
> but I guess I'm also not going to ack it.

I'll remove the last point from this patch.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 13:11:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 13:11:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP4IK-00007p-E3; Thu, 16 Apr 2020 13:11:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3QVr=6A=ens-lyon.org=samuel.thibault@srs-us1.protection.inumbo.net>)
 id 1jP4II-00007i-Qs
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 13:11:02 +0000
X-Inumbo-ID: b7e65698-7fe3-11ea-8b90-12813bfff9fa
Received: from hera.aquilenet.fr (unknown [185.233.100.1])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b7e65698-7fe3-11ea-8b90-12813bfff9fa;
 Thu, 16 Apr 2020 13:11:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 7E81CAE65;
 Thu, 16 Apr 2020 15:11:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id MTR01cjk79An; Thu, 16 Apr 2020 15:10:59 +0200 (CEST)
Received: from function (lfbn-bor-1-797-11.w86-234.abo.wanadoo.fr
 [86.234.239.11])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 5E2BFADE6;
 Thu, 16 Apr 2020 15:10:59 +0200 (CEST)
Received: from samy by function with local (Exim 4.93)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1jP4ID-004Vno-Tr; Thu, 16 Apr 2020 15:10:57 +0200
Date: Thu, 16 Apr 2020 15:10:57 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Subject: Re: [PATCH] mini-os: use -m elf_i386 for final linking
Message-ID: <20200416131057.yvrsijib7aqjzc4s@function>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
References: <20200416122731.22713-1-jgross@suse.com>
 <20200416124636.35zgnf5bhq3d3bpw@function>
 <71871753-d4e5-9afc-9637-479f5ecb2776@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <71871753-d4e5-9afc-9637-479f5ecb2776@suse.com>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Jürgen Groß, le jeu. 16 avril 2020 14:58:34 +0200, a ecrit:
>  Specifically, 64bit emulation appears to include "align primary
>  sections to 2M so your OS can make better use of superpages even when
>  mmap()ing", with no way I can spot to override this in the linker
>  file."

Ok, I see, I had indeed guessed that the 2M rounding probably had
something to do with 2M pages.

I'm afraid it may bite us back some day, but I'd say it is fine enough
for now to include it, so 

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

with the information quoted above put in the changelog, please :)

Samuel


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 13:14:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 13:14:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP4Lw-0000Ii-1m; Thu, 16 Apr 2020 13:14:48 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jP4Lu-0000Id-QR
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 13:14:46 +0000
X-Inumbo-ID: 3d96bea4-7fe4-11ea-8b90-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3d96bea4-7fe4-11ea-8b90-12813bfff9fa;
 Thu, 16 Apr 2020 13:14:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2q6VG0ZgTEsBAmNbG8L+8bCKUE0ecd7DdTCASpw0z5o=; b=yRrkO7LtCVq2RP7x5qj5XaT4K
 JRVNjpIpMSO+iHKbX0qoZERJzQAYKiMZs8f6nfd4k4sth2BJX9QtVEVJQ/7vdZiLOr0Cbf8DYlhPF
 V7CIpDu2tl1OjFLFuqxv1IrP2gysciVMe51LNvRwI2k/rtQvONd9Y+rAOrKp1SO8YuKgc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jP4Ls-0004rW-SL; Thu, 16 Apr 2020 13:14:44 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jP4Ls-0007XU-HG; Thu, 16 Apr 2020 13:14:44 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jP4Ls-0007Nj-GU; Thu, 16 Apr 2020 13:14:44 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149667-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149667: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=fcd06227f83643194f8018f8dd37adce57763a61
X-Osstest-Versions-That: xen=0dbc112e727f6c17f306c864950bdf83dece5cd5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 13:14:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149648

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149648
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149648
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149648
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149648
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149648
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149648
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149648
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149648
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149648
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  fcd06227f83643194f8018f8dd37adce57763a61
baseline version:
 xen                  0dbc112e727f6c17f306c864950bdf83dece5cd5

Last test of basis   149648  2020-04-14 13:06:14 Z    2 days
Testing same since   149667  2020-04-15 07:26:21 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   0dbc112e72..fcd06227f8  fcd06227f83643194f8018f8dd37adce57763a61 -> master


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 13:17:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 13:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP4OO-0000QR-I9; Thu, 16 Apr 2020 13:17:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fNsn=6A=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jP4ON-0000QM-Pi
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 13:17:19 +0000
X-Inumbo-ID: 98912a10-7fe4-11ea-8b92-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 98912a10-7fe4-11ea-8b92-12813bfff9fa;
 Thu, 16 Apr 2020 13:17:18 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B58E7AC6D;
 Thu, 16 Apr 2020 13:17:16 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2] mini-os: use -m elf_i386 for final linking
Date: Thu, 16 Apr 2020 15:17:15 +0200
Message-Id: <20200416131715.24498-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, samuel.thibault@ens-lyon.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Using the standard -m elf_x86_64 for 64-bit mini-os results in the
first section (.text) to start only at offset 2MB in the binary file.

Quoting Andrew Cooper on that topic:

  Specifically, 64bit emulation appears to include "align primary
  sections to 2M so your OS can make better use of superpages even when
  mmap()ing", with no way I can spot to override this in the linker
  file.

Using -m elf_i386 avoids that problem without any visible disadvantage.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/arch.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/arch.mk b/arch/x86/arch.mk
index c87885f..00028a0 100644
--- a/arch/x86/arch.mk
+++ b/arch/x86/arch.mk
@@ -26,3 +26,5 @@ ifeq ($(CONFIG_PARAVIRT),n)
 ARCH_LDFLAGS_FINAL := --oformat=elf32-i386
 ARCH_AS_DEPS += x86_hvm.S
 endif
+
+ARCH_LDFLAGS_FINAL += -m elf_i386
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 13:25:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 13:25:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP4WR-0001SP-2n; Thu, 16 Apr 2020 13:25:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=gkLV=6A=citrix.com=christian.lindig@srs-us1.protection.inumbo.net>)
 id 1jP4WP-0001SK-1e
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 13:25:37 +0000
X-Inumbo-ID: c16d0ad4-7fe5-11ea-8b92-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c16d0ad4-7fe5-11ea-8b92-12813bfff9fa;
 Thu, 16 Apr 2020 13:25:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587043537;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-transfer-encoding:mime-version;
 bh=4YW9jmThK2p92tdAQyY4DWoKdL+iWXf8XE2lQN6cwP8=;
 b=YoKhRcGWt2zCIiytfHah03O8SW4A0XPEL0r2gG0mjiVrxnjTKqXPTi95
 qqpu7wIuTcYKqp3VogQrigmwmIGQ6kTxEphw2HD4bltl+3uRu1pwQpS4a
 C4JmrMlE0d/X12HIxg1Rg1SZmjjJpsoISc+4Y8NIZP6Ehm9Ba7RZ0xDqa M=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=christian.lindig@citrix.com;
 spf=Pass smtp.mailfrom=christian.lindig@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 christian.lindig@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="christian.lindig@citrix.com";
 x-sender="christian.lindig@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 christian.lindig@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="christian.lindig@citrix.com";
 x-sender="christian.lindig@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="christian.lindig@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: erBkGnVQCCT95l3wxpzgHk/xSSH2wlnQc5zxebzqmEj2RFTdin+b+ujL2JqSMsDDTCqAFZnNPs
 zhy8ZzfSB1T5zPbKebEbSByDM5QFHm5yR6rBnTihJH++6F0IQuRo11/5bI6RuQr1kbtYqCx87s
 K0kkKDmhAUjldWqr2zlfRdSuLOpOCzSdmhB0MtYWREDct1/NE1zrJRzfmitGhhTk0uQB/CDPS9
 KwhMn3Fa6CbG/pTJREqtWQI9exs9CIIMYKNLVvnBw8Z8p1LOHCEByqz629RlIb+j/1LbEi/zqd
 EJc=
X-SBRS: 2.7
X-MesageID: 15764106
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="15764106"
From: Christian Lindig <christian.lindig@citrix.com>
To: Julien Grall <julien@xen.org>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>, David Scott <dave@recoil.org>
Subject: Re: [PATCH 0/8] Fix build with using OCaml 4.06.1 and -safe-string
Thread-Topic: [PATCH 0/8] Fix build with using OCaml 4.06.1 and -safe-string
Thread-Index: AQHWBsiEF3guLbrjg0q8hVYSHUQ086h7lF0AgABCC8w=
Date: Thu, 16 Apr 2020 13:25:32 +0000
Message-ID: <1587043532025.36720@citrix.com>
References: <20200330192157.1335-1-julien@xen.org>,
 <67d3370c-779a-7007-e5fa-98d957a85ce9@xen.org>
In-Reply-To: <67d3370c-779a-7007-e5fa-98d957a85ce9@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 "dfaggioli@suse.com" <dfaggioli@suse.com>, Jan Beulich <jbeulich@suse.com>,
 Ian Jackson <Ian.Jackson@citrix.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, Roger Pau
 Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

=0A=
The changes in the OCaml C stubs look good to me. They don't really touch t=
he interface but are mostly concerned with types on the C side by adding ca=
sts, const, and so on. The extended error handling is an improvement.=0A=
=0A=
-- Christian=0A=
=0A=
-- =0A=
Acked-by: Christian Lindig <christian.lindig@citrix.com>=0A=
=0A=
________________________________________=0A=
From: Julien Grall <julien@xen.org>=0A=
Sent: 16 April 2020 12:25=0A=
To: xen-devel@lists.xenproject.org; Christian Lindig; David Scott=0A=
Cc: dfaggioli@suse.com; Julien Grall; Stefano Stabellini; Volodymyr Babchuk=
; Jan Beulich; Andrew Cooper; Wei Liu; Roger Pau Monne; George Dunlap; Ian =
Jackson=0A=
Subject: Re: [PATCH 0/8] Fix build with using OCaml 4.06.1 and -safe-string=
=0A=
=0A=
Hi,=0A=
=0A=
Gentle ping. I am missing reviews for the OCaml part.=0A=
=0A=
Cheers,=0A=
=0A=
On 30/03/2020 20:21, Julien Grall wrote:=0A=
> From: Julien Grall <jgrall@amazon.com>=0A=
>=0A=
> Hi all,=0A=
>=0A=
> This series is meant to solve the build issue reported by Dario when=0A=
> using recent version of OCaml and -safe-string.=0A=
>=0A=
> I took the opportunity to harden a bit more the code by using const more=
=0A=
> often.=0A=
>=0A=
> This series was only build tested.=0A=
>=0A=
> Cheers,=0A=
>=0A=
> Julien Grall (8):=0A=
>    xen/guest_access: Harden copy_to_guest_offset to prevent const dest=0A=
>      operand=0A=
>    xen/public: sysctl: set_parameter.params and debug.keys should be=0A=
>      const=0A=
>    tools/libxc: misc: Mark const the parameter 'keys' of=0A=
>      xc_send_debug_keys()=0A=
>    tools/libxc: misc: Mark const the parameter 'params' of=0A=
>      xc_set_parameters()=0A=
>    tools/ocaml: libxc: Check error return in stub_xc_vcpu_context_get()=
=0A=
>    tools/ocaml: libxb: Harden stub_header_of_string()=0A=
>    tools/ocaml: libxb: Avoid to use String_val() when value is bytes=0A=
>    tools/ocaml: Fix stubs build when OCaml has been compiled with=0A=
>      -safe-string=0A=
>=0A=
>   tools/libxc/include/xenctrl.h       |  4 ++--=0A=
>   tools/libxc/xc_misc.c               |  8 ++++----=0A=
>   tools/libxc/xc_private.h            |  8 ++++++++=0A=
>   tools/ocaml/libs/xb/xenbus_stubs.c  |  6 +++---=0A=
>   tools/ocaml/libs/xb/xs_ring_stubs.c | 12 ++++++++++--=0A=
>   tools/ocaml/libs/xc/xenctrl_stubs.c |  6 ++++--=0A=
>   xen/include/asm-arm/guest_access.h  |  2 +-=0A=
>   xen/include/asm-x86/guest_access.h  |  2 +-=0A=
>   xen/include/public/sysctl.h         |  4 ++--=0A=
>   9 files changed, 35 insertions(+), 17 deletions(-)=0A=
>=0A=
=0A=
--=0A=
Julien Grall=


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 13:30:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 13:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP4bL-0002Hh-PD; Thu, 16 Apr 2020 13:30:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=tGEC=6A=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jP4bL-0002Hc-7d
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 13:30:43 +0000
X-Inumbo-ID: 7850c9a2-7fe6-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7850c9a2-7fe6-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 13:30:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=jVDr4ghE8GHOij+dttnIDL2OkTWCoRsjL55B/g2+vh4=; b=uiZyr1tdM6nFtBYe3KgedjvjEe
 aS0HZ8KxTYUE7zKE53sbCrdkkOLrxYxOSYTzkybLgB5APPin9l8FAxZraiW7qTwZeexbGyqwWcUc5
 9y56RuIGTNxIgwLGvVI08h8bh4SV2FZjWRHrwPoL8sGtL+6+md4ZjOAC2ga/kYjznNcc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jP4bH-0005BM-Ok; Thu, 16 Apr 2020 13:30:39 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jP4bH-00034X-FR; Thu, 16 Apr 2020 13:30:39 +0000
Date: Thu, 16 Apr 2020 14:30:36 +0100
From: Wei Liu <wl@xen.org>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org
Subject: Re: [PATCH] mini-os: provide binary without debug information
Message-ID: <20200416133036.6igduiwssnvjatfe@debian>
References: <20200416122748.22798-1-jgross@suse.com>
 <20200416123002.hmituo73bydg43kr@function>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200416123002.hmituo73bydg43kr@function>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 16, 2020 at 02:30:02PM +0200, Samuel Thibault wrote:
> Juergen Gross, le jeu. 16 avril 2020 14:27:48 +0200, a ecrit:
> > Provide a mini-os binary stripped from debug information in order to
> > have a smaller resulting kernel file. The binary with debug
> > information is kept with the suffix "-debug".
> > 
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> 

Applied.


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 13:31:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 13:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP4bi-0002Kn-4s; Thu, 16 Apr 2020 13:31:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=tGEC=6A=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jP4bh-0002Ke-85
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 13:31:05 +0000
X-Inumbo-ID: 8498d6d2-7fe6-11ea-8b92-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8498d6d2-7fe6-11ea-8b92-12813bfff9fa;
 Thu, 16 Apr 2020 13:31:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=BONflVOk44YPtXzQwXdBYDSr4YhDryB8SuquSdSqYKk=; b=zzhsfCc/HCuI4brmnFGRKdVarp
 QIQDTZuekxuVeecwSWnuBhyEk4z88VJTDm2qVg7p0quvNlNVj04ZJLNQuNcbSKQQsR1Jvx8ARu/K0
 tNnGSYgl1V0DTxI47Hq/+KUr8o71x4xwXaVVt2Xt5iwvVFvYh+pfRNiuQuSsXibPtn6o=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jP4be-0005Bn-FE; Thu, 16 Apr 2020 13:31:02 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jP4be-00034v-6h; Thu, 16 Apr 2020 13:31:02 +0000
Date: Thu, 16 Apr 2020 14:30:59 +0100
From: Wei Liu <wl@xen.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH v2] mini-os: use -m elf_i386 for final linking
Message-ID: <20200416133059.eetlpshw3gzxks6z@debian>
References: <20200416131715.24498-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200416131715.24498-1-jgross@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 Wei Liu <wl@xen.org>, samuel.thibault@ens-lyon.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 16, 2020 at 03:17:15PM +0200, Juergen Gross wrote:
> Using the standard -m elf_x86_64 for 64-bit mini-os results in the
> first section (.text) to start only at offset 2MB in the binary file.
> 
> Quoting Andrew Cooper on that topic:
> 
>   Specifically, 64bit emulation appears to include "align primary
>   sections to 2M so your OS can make better use of superpages even when
>   mmap()ing", with no way I can spot to override this in the linker
>   file.
> 
> Using -m elf_i386 avoids that problem without any visible disadvantage.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Applied with Samuel's Rb from v1.

Wei.


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 13:32:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 13:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP4cm-0002To-Ih; Thu, 16 Apr 2020 13:32:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=tGEC=6A=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jP4cl-0002Td-2Z
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 13:32:11 +0000
X-Inumbo-ID: acb0ca8a-7fe6-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id acb0ca8a-7fe6-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 13:32:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=w2sVyh/xsnx9fzZdKP+3VDX/aWeSKnjEekHGi2q7hck=; b=kYLuJBaPiKyTLjm1Wr/fbMXnt8
 uTEyyipj+ci+/lPgrrpXbKnkAwveDsatcpqigB3cGYUmA03IK/UTcqIfCGdb9o3vqveXB9CgyZrBh
 XEVFv5SCYOmoOSNSRSO6GdNPYm8a42oX58pEOXOJzNDQzpTHQ8Laqk54tlHizBy2vs48=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jP4ci-0005Dg-Up; Thu, 16 Apr 2020 13:32:08 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jP4ci-00038R-MO; Thu, 16 Apr 2020 13:32:08 +0000
Date: Thu, 16 Apr 2020 14:32:06 +0100
From: Wei Liu <wl@xen.org>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org
Subject: Re: [PATCH] mini-os: allow 4096 event channels for 64-bit mini-os
Message-ID: <20200416133206.hezesgzrzkvm6hcd@debian>
References: <20200416122700.22620-1-jgross@suse.com>
 <20200416122918.p757arqwyvjamwv5@function>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200416122918.p757arqwyvjamwv5@function>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 16, 2020 at 02:29:18PM +0200, Samuel Thibault wrote:
> Juergen Gross, le jeu. 16 avril 2020 14:27:00 +0200, a ecrit:
> > Limiting the number of event channels to 1024 is fine for 32-bit
> > builds, but not for 64-bit ones. This might be a problem when using
> > Xenstore-stubdom as the number of domains which can be supported is
> > then limited to a little bit more than 1000.
> > 
> > So raise the number of event channels to 4096 in 64-bit builds.
> > 
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Applied.


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 14:00:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 14:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP54A-0005AV-49; Thu, 16 Apr 2020 14:00:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8YfG=6A=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jP548-0005AC-7I
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:00:28 +0000
X-Inumbo-ID: 9e2f1b16-7fea-11ea-8b99-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9e2f1b16-7fea-11ea-8b99-12813bfff9fa;
 Thu, 16 Apr 2020 14:00:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587045625;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=9fcaOhytlvsoCQdOFtbwDrty6x8vBezRR7Mhmxygeew=;
 b=S9J2UKpZf9sABINeYrs8VmK/RwTORzVMyc5M2iP3PtrxriKKK4p2xpqC
 ORM9xc5LmZ/0MW/GACOsHAcKUp0cyHWPNdgmj9cMNrJ9rYXAMZsQPV1o4
 bQl05izC2r6rzKv7jvStYom9XQEGFte2RGNB8J2vTXykKcJVg56tMhJHF Q=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: erGlxoMUDHD0u/d94h3GqsgyDHpES9jP0yYfjhBYob3iqAQHtVggwRBTV1Ow6YwtBwcCMRqvyW
 yUE47HPH+GHkwl6d2lWzVSMW+TDxNopJJALJV/GKGghv8eR29wPrXqpYyZwLqUM8BPax/THBz/
 pPgbG35NOvd+JxlybFBFQ7LbrjOYgclbfuGrCnqoWh+IdOMqgy9WU6HF/nGyUGnRBAPL4TtniY
 Vb33Wa8TeLHW9AEYU6+d/UW3J2+WvyzU+XvkchXW0zulvJOSK81NA/BSoL1baRZoAD64qKzY5z
 paQ=
X-SBRS: 2.7
X-MesageID: 15766298
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="15766298"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v10 2/3] x86/tlb: allow disabling the TLB clock
Date: Thu, 16 Apr 2020 15:59:08 +0200
Message-ID: <20200416135909.16155-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200416135909.16155-1-roger.pau@citrix.com>
References: <20200416135909.16155-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.

This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes: Xen itself for example offers a HVMOP_flush_tlbs hypercall in
order to perform a TLB flush without having to IPI each CPU. When
using such mechanisms it's no longer possible to keep a timestamp of
the flushes on each CPU, as they are performed by the underlying
hypervisor.

Offer a boolean in order to signal Xen that the timestamped TLB
shouldn't be used. This avoids keeping the timestamps of the flushes,
and also forces NEED_FLUSH to always return true.

No functional change intended, as this change doesn't introduce any
user that disables the timestamped TLB.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/flushtlb.c        | 19 +++++++++++++------
 xen/include/asm-x86/flushtlb.h | 17 ++++++++++++++++-
 2 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 7d261aef32..e1b1e98c23 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -33,6 +33,9 @@
 u32 tlbflush_clock = 1U;
 DEFINE_PER_CPU(u32, tlbflush_time);
 
+/* Signals whether the TLB flush clock is in use. */
+bool __read_mostly tlb_clk_enabled = true;
+
 /*
  * pre_flush(): Increment the virtual TLB-flush clock. Returns new clock value.
  * 
@@ -83,12 +86,13 @@ static void post_flush(u32 t)
 static void do_tlb_flush(void)
 {
     unsigned long flags, cr4;
-    u32 t;
+    u32 t = 0;
 
     /* This non-reentrant function is sometimes called in interrupt context. */
     local_irq_save(flags);
 
-    t = pre_flush();
+    if ( tlb_clk_enabled )
+        t = pre_flush();
 
     if ( use_invpcid )
         invpcid_flush_all();
@@ -100,7 +104,8 @@ static void do_tlb_flush(void)
     else
         write_cr3(read_cr3());
 
-    post_flush(t);
+    if ( tlb_clk_enabled )
+        post_flush(t);
 
     local_irq_restore(flags);
 }
@@ -108,7 +113,7 @@ static void do_tlb_flush(void)
 void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
 {
     unsigned long flags, old_cr4;
-    u32 t;
+    u32 t = 0;
 
     /* Throughout this function we make this assumption: */
     ASSERT(!(cr4 & X86_CR4_PCIDE) || !(cr4 & X86_CR4_PGE));
@@ -116,7 +121,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
     /* This non-reentrant function is sometimes called in interrupt context. */
     local_irq_save(flags);
 
-    t = pre_flush();
+    if ( tlb_clk_enabled )
+        t = pre_flush();
     hvm_flush_guest_tlbs();
 
     old_cr4 = read_cr4();
@@ -169,7 +175,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
     if ( cr4 & X86_CR4_PCIDE )
         invpcid_flush_all_nonglobals();
 
-    post_flush(t);
+    if ( tlb_clk_enabled )
+        post_flush(t);
 
     local_irq_restore(flags);
 }
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 50df468c16..d5ca4bad57 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -21,10 +21,21 @@ extern u32 tlbflush_clock;
 /* Time at which each CPU's TLB was last flushed. */
 DECLARE_PER_CPU(u32, tlbflush_time);
 
-#define tlbflush_current_time() tlbflush_clock
+/* TLB clock is in use. */
+extern bool tlb_clk_enabled;
+
+static inline uint32_t tlbflush_current_time(void)
+{
+    /* Returning 0 from tlbflush_current_time will always force a flush. */
+    return tlb_clk_enabled ? tlbflush_clock : 0;
+}
 
 static inline void page_set_tlbflush_timestamp(struct page_info *page)
 {
+    /* Avoid the write if the TLB clock is disabled. */
+    if ( !tlb_clk_enabled )
+        return;
+
     /*
      * Prevent storing a stale time stamp, which could happen if an update
      * to tlbflush_clock plus a subsequent flush IPI happen between the
@@ -67,6 +78,10 @@ static inline void tlbflush_filter(cpumask_t *mask, uint32_t page_timestamp)
 {
     unsigned int cpu;
 
+    /* Short-circuit: there's no need to iterate if the clock is disabled. */
+    if ( !tlb_clk_enabled )
+        return;
+
     for_each_cpu ( cpu, mask )
         if ( !NEED_FLUSH(per_cpu(tlbflush_time, cpu), page_timestamp) )
             __cpumask_clear_cpu(cpu, mask);
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 14:00:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 14:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP544-00059X-Bh; Thu, 16 Apr 2020 14:00:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8YfG=6A=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jP543-00059P-Cw
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:00:23 +0000
X-Inumbo-ID: 9c73f7c4-7fea-11ea-8b99-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9c73f7c4-7fea-11ea-8b99-12813bfff9fa;
 Thu, 16 Apr 2020 14:00:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587045621;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=DB5AJyccZDlAh+2LWwWKF7DT4f6pew9ftCx0h5I2CK8=;
 b=Xs8tFdpPHJ0WUxysjg1geYzTekUfprRYLfSkH3x/OGQY/fDc2KiHBYbI
 VWP5VuL6F5aM1LGXRN88kYwaKk3PX8A5g3NWPwuagN63a8MNRVpxeECZs
 32l1F4qtrSxO3jmgfIzzjGU2ADqox8E683pz6Ws4tSHxsRodu4NZEMk5G E=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Hzylxg3N6Xk+QwNFfoLsMUKoV2ARTOgd9/mINNWWdgZ9WxsFaEBIH8eVSphwW7B2YqFrg38BO0
 cW4jcLD9Yxs9mDTzJuAGSeqdL0Iu6v3iPhbK26mWcNI7gocRCshPVFemBYPUtKjqemEVU8eXW2
 yXeRuMfoh9cVgOVf5K2PvfGXOjgCT1RyrR01JouGRnrv055Z3R/yarn7QUGTxMihdIEHVb9Ygd
 kAdb4k2QBwc9Os9esRCDthV94LX5DPer1aGnyexJlDBASeK9njEeUo/R2W+StHalqVsDtENybc
 9hQ=
X-SBRS: 2.7
X-MesageID: 15796806
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="15796806"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Date: Thu, 16 Apr 2020 15:59:07 +0200
Message-ID: <20200416135909.16155-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200416135909.16155-1-roger.pau@citrix.com>
References: <20200416135909.16155-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George
 Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Introduce a specific flag to request a HVM guest linear TLB flush,
which is an ASID/VPID tickle that forces a guest linear to guest
physical TLB flush for all HVM guests.

This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't require linear
TLB flushes as Xen doesn't modify the guest page tables in that case
(ie: when using HAP). Note that shadow paging code already takes care
of issuing the necessary flushes when the shadow page tables are
modified.

In order to keep the previous behavior modify all shadow code TLB
flushes to also flush the guest linear to physical TLB if the guest is
HVM. I haven't looked at each specific shadow code TLB flush in order
to figure out whether it actually requires a guest TLB flush or not,
so there might be room for improvement in that regard.

Also perform ASID/VPID flushes when modifying the p2m tables as it's a
requirement for AMD hardware. Finally keep the flush in
switch_cr3_cr4, as it's not clear whether code could rely on
switch_cr3_cr4 also performing a guest linear TLB flush. A following
patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to
not be necessary.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v9:
 - Introduce and use guest_flush_tlb_mask and sh_flush_local.
 - Add a local domain variable to p2m_pt_change_entry_type_global.

Changes since v8:
 - Don't flush host TLB on HAP changes.
 - Introduce a helper for shadow changes that only flushes ASIDs/VPIDs
   when the guest is HVM.
 - Introduce a helper for HAP that only flushes ASIDs/VPIDs.

Changes since v7:
 - Do not perform an ASID flush in filtered_flush_tlb_mask: the
   requested flush is related to the page need_tlbflush field and not
   to p2m changes (applies to both callers).

Changes since v6:
 - Add ASID/VPID flushes when modifying the p2m.
 - Keep the ASID/VPID flush in switch_cr3_cr4.

Changes since v5:
 - Rename FLUSH_GUESTS_TLB to FLUSH_HVM_ASID_CORE.
 - Clarify commit message.
 - Define FLUSH_HVM_ASID_CORE to 0 when !CONFIG_HVM.
---
 xen/arch/x86/flushtlb.c          | 18 ++++++++++++++++--
 xen/arch/x86/mm/hap/hap.c        |  8 ++++----
 xen/arch/x86/mm/hap/nested_hap.c |  2 +-
 xen/arch/x86/mm/p2m-pt.c         |  5 +++--
 xen/arch/x86/mm/paging.c         |  2 +-
 xen/arch/x86/mm/shadow/common.c  | 18 +++++++++---------
 xen/arch/x86/mm/shadow/hvm.c     |  2 +-
 xen/arch/x86/mm/shadow/multi.c   | 16 ++++++++--------
 xen/arch/x86/mm/shadow/private.h |  6 ++++++
 xen/include/asm-x86/flushtlb.h   |  8 ++++++++
 10 files changed, 57 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 03f92c23dc..7d261aef32 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -7,6 +7,7 @@
  * Copyright (c) 2003-2006, K A Fraser
  */
 
+#include <xen/paging.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/softirq.h>
@@ -59,8 +60,6 @@ static u32 pre_flush(void)
         raise_softirq(NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ);
 
  skip_clocktick:
-    hvm_flush_guest_tlbs();
-
     return t2;
 }
 
@@ -118,6 +117,7 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
     local_irq_save(flags);
 
     t = pre_flush();
+    hvm_flush_guest_tlbs();
 
     old_cr4 = read_cr4();
     ASSERT(!(old_cr4 & X86_CR4_PCIDE) || !(old_cr4 & X86_CR4_PGE));
@@ -221,6 +221,9 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
             do_tlb_flush();
     }
 
+    if ( flags & FLUSH_HVM_ASID_CORE )
+        hvm_flush_guest_tlbs();
+
     if ( flags & FLUSH_CACHE )
     {
         const struct cpuinfo_x86 *c = &current_cpu_data;
@@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
 
     return flags;
 }
+
+void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
+{
+    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
+                                                                   : 0) |
+                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
+                                                          : 0);
+
+    if ( flags )
+        flush_mask(mask, flags);
+}
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 052ae35c6f..f7218a86d6 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
             p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
                                   p2m_ram_rw, p2m_ram_logdirty);
 
-            flush_tlb_mask(d->dirty_cpumask);
+            guest_flush_tlb_mask(d, d->dirty_cpumask);
 
             memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
         }
@@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
          * to be read-only, or via hardware-assisted log-dirty.
          */
         p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     }
     return 0;
 }
@@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
      * be read-only, or via hardware-assisted log-dirty.
      */
     p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
-    flush_tlb_mask(d->dirty_cpumask);
+    guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 /************************************************/
@@ -812,7 +812,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
 
     safe_write_pte(p, new);
     if ( old_flags & _PAGE_PRESENT )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     paging_unlock(d);
 
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index abe5958a52..f92ddc5206 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -84,7 +84,7 @@ nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
     safe_write_pte(p, new);
 
     if (old_flags & _PAGE_PRESENT)
-        flush_tlb_mask(p2m->dirty_cpumask);
+        guest_flush_tlb_mask(d, p2m->dirty_cpumask);
 
     paging_unlock(d);
 
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index eb66077496..5c0501794e 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -866,11 +866,12 @@ static void p2m_pt_change_entry_type_global(struct p2m_domain *p2m,
     l1_pgentry_t *tab;
     unsigned long gfn = 0;
     unsigned int i, changed;
+    const struct domain *d = p2m->domain;
 
     if ( pagetable_get_pfn(p2m_get_pagetable(p2m)) == 0 )
         return;
 
-    ASSERT(hap_enabled(p2m->domain));
+    ASSERT(hap_enabled(d));
 
     tab = map_domain_page(pagetable_get_mfn(p2m_get_pagetable(p2m)));
     for ( changed = i = 0; i < (1 << PAGETABLE_ORDER); ++i )
@@ -896,7 +897,7 @@ static void p2m_pt_change_entry_type_global(struct p2m_domain *p2m,
     unmap_domain_page(tab);
 
     if ( changed )
-         flush_tlb_mask(p2m->domain->dirty_cpumask);
+         guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 static int p2m_pt_change_entry_type_range(struct p2m_domain *p2m,
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index 469bb76429..fd3175bd3e 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -613,7 +613,7 @@ void paging_log_dirty_range(struct domain *d,
 
     p2m_unlock(p2m);
 
-    flush_tlb_mask(d->dirty_cpumask);
+    guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 /*
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 75dd414a6e..f8168b210a 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -363,7 +363,7 @@ static int oos_remove_write_access(struct vcpu *v, mfn_t gmfn,
     }
 
     if ( ftlb )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     return 0;
 }
@@ -939,7 +939,7 @@ static void _shadow_prealloc(struct domain *d, unsigned int pages)
                 /* See if that freed up enough space */
                 if ( d->arch.paging.shadow.free_pages >= pages )
                 {
-                    flush_tlb_mask(d->dirty_cpumask);
+                    guest_flush_tlb_mask(d, d->dirty_cpumask);
                     return;
                 }
             }
@@ -993,7 +993,7 @@ static void shadow_blow_tables(struct domain *d)
                                pagetable_get_mfn(v->arch.shadow_table[i]), 0);
 
     /* Make sure everyone sees the unshadowings */
-    flush_tlb_mask(d->dirty_cpumask);
+    guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 void shadow_blow_tables_per_domain(struct domain *d)
@@ -1102,7 +1102,7 @@ mfn_t shadow_alloc(struct domain *d,
         if ( unlikely(!cpumask_empty(&mask)) )
         {
             perfc_incr(shadow_alloc_tlbflush);
-            flush_tlb_mask(&mask);
+            guest_flush_tlb_mask(d, &mask);
         }
         /* Now safe to clear the page for reuse */
         clear_domain_page(page_to_mfn(sp));
@@ -2293,7 +2293,7 @@ void sh_remove_shadows(struct domain *d, mfn_t gmfn, int fast, int all)
 
     /* Need to flush TLBs now, so that linear maps are safe next time we
      * take a fault. */
-    flush_tlb_mask(d->dirty_cpumask);
+    guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     paging_unlock(d);
 }
@@ -3008,7 +3008,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d, unsigned long gfn,
         {
             sh_remove_all_shadows_and_parents(d, mfn);
             if ( sh_remove_all_mappings(d, mfn, _gfn(gfn)) )
-                flush_tlb_mask(d->dirty_cpumask);
+                guest_flush_tlb_mask(d, d->dirty_cpumask);
         }
     }
 
@@ -3048,7 +3048,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d, unsigned long gfn,
                 }
                 omfn = mfn_add(omfn, 1);
             }
-            flush_tlb_mask(&flushmask);
+            guest_flush_tlb_mask(d, &flushmask);
 
             if ( npte )
                 unmap_domain_page(npte);
@@ -3335,7 +3335,7 @@ int shadow_track_dirty_vram(struct domain *d,
         }
     }
     if ( flush_tlb )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     goto out;
 
 out_sl1ma:
@@ -3405,7 +3405,7 @@ bool shadow_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
     }
 
     /* Flush TLBs on all CPUs with dirty vcpu state. */
-    flush_tlb_mask(mask);
+    guest_flush_tlb_mask(d, mask);
 
     /* Done. */
     for_each_vcpu ( d, v )
diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c
index 1e6024c71f..608360daec 100644
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -591,7 +591,7 @@ static void validate_guest_pt_write(struct vcpu *v, mfn_t gmfn,
 
     if ( rc & SHADOW_SET_FLUSH )
         /* Need to flush TLBs to pick up shadow PT changes */
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     if ( rc & SHADOW_SET_ERROR )
     {
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index f6b1628742..d3f6a9216f 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3067,7 +3067,7 @@ static int sh_page_fault(struct vcpu *v,
         perfc_incr(shadow_rm_write_flush_tlb);
         smp_wmb();
         atomic_inc(&d->arch.paging.shadow.gtable_dirty_version);
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     }
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
@@ -3576,7 +3576,7 @@ static bool sh_invlpg(struct vcpu *v, unsigned long linear)
     if ( mfn_to_page(sl1mfn)->u.sh.type
          == SH_type_fl1_shadow )
     {
-        flush_tlb_local();
+        sh_flush_local(v->domain);
         return false;
     }
 
@@ -3811,7 +3811,7 @@ sh_update_linear_entries(struct vcpu *v)
          * table entry. But, without this change, it would fetch the wrong
          * value due to a stale TLB.
          */
-        flush_tlb_local();
+        sh_flush_local(d);
     }
 }
 
@@ -4012,7 +4012,7 @@ sh_update_cr3(struct vcpu *v, int do_locking, bool noflush)
      * (old) shadow linear maps in the writeable mapping heuristics. */
 #if GUEST_PAGING_LEVELS == 2
     if ( sh_remove_write_access(d, gmfn, 2, 0) != 0 )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     sh_set_toplevel_shadow(v, 0, gmfn, SH_type_l2_shadow);
 #elif GUEST_PAGING_LEVELS == 3
     /* PAE guests have four shadow_table entries, based on the
@@ -4036,7 +4036,7 @@ sh_update_cr3(struct vcpu *v, int do_locking, bool noflush)
             }
         }
         if ( flush )
-            flush_tlb_mask(d->dirty_cpumask);
+            guest_flush_tlb_mask(d, d->dirty_cpumask);
         /* Now install the new shadows. */
         for ( i = 0; i < 4; i++ )
         {
@@ -4057,7 +4057,7 @@ sh_update_cr3(struct vcpu *v, int do_locking, bool noflush)
     }
 #elif GUEST_PAGING_LEVELS == 4
     if ( sh_remove_write_access(d, gmfn, 4, 0) != 0 )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     sh_set_toplevel_shadow(v, 0, gmfn, SH_type_l4_shadow);
     if ( !shadow_mode_external(d) && !is_pv_32bit_domain(d) )
     {
@@ -4503,7 +4503,7 @@ static void sh_pagetable_dying(paddr_t gpa)
         }
     }
     if ( flush )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     /* Remember that we've seen the guest use this interface, so we
      * can rely on it using it in future, instead of guessing at
@@ -4540,7 +4540,7 @@ static void sh_pagetable_dying(paddr_t gpa)
         mfn_to_page(gmfn)->pagetable_dying = true;
         shadow_unhook_mappings(d, smfn, 1/* user pages only */);
         /* Now flush the TLB: we removed toplevel mappings. */
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     }
 
     /* Remember that we've seen the guest use this interface, so we
diff --git a/xen/arch/x86/mm/shadow/private.h b/xen/arch/x86/mm/shadow/private.h
index e8b028a365..82735e35ef 100644
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -818,6 +818,12 @@ static inline int sh_check_page_has_no_refs(struct page_info *page)
 bool shadow_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
                       void *ctxt);
 
+static inline void sh_flush_local(const struct domain *d)
+{
+    flush_local(FLUSH_TLB |
+                (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE : 0));
+}
+
 #endif /* _XEN_SHADOW_PRIVATE_H */
 
 /*
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 2cfe4e6e97..50df468c16 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -105,6 +105,12 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4);
 #define FLUSH_VCPU_STATE 0x1000
  /* Flush the per-cpu root page table */
 #define FLUSH_ROOT_PGTBL 0x2000
+#if CONFIG_HVM
+ /* Flush all HVM guests linear TLB (using ASID/VPID) */
+#define FLUSH_HVM_ASID_CORE 0x4000
+#else
+#define FLUSH_HVM_ASID_CORE 0
+#endif
 
 /* Flush local TLBs/caches. */
 unsigned int flush_area_local(const void *va, unsigned int flags);
@@ -159,4 +165,6 @@ static inline int clean_dcache_va_range(const void *p, unsigned long size)
     return clean_and_invalidate_dcache_va_range(p, size);
 }
 
+void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask);
+
 #endif /* __FLUSHTLB_H__ */
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 14:00:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 14:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP548-0005AH-Qf; Thu, 16 Apr 2020 14:00:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8YfG=6A=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jP547-0005A5-4c
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:00:27 +0000
X-Inumbo-ID: 9f19b1bc-7fea-11ea-b4f4-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9f19b1bc-7fea-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 14:00:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587045626;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=6xDyV2T4eBxzsTghP88Qw+tODGijc2LN55Bf5M9CvYA=;
 b=c1wTWdpd/vQx1e1tAHOMSN/tD7wxvs4/1BkJH5IUFZRopu/T+APlGlG4
 8Sfp6z1JUi5m4r4D17x3reIXMuheUL1BzZzJ4jRTNvcVcPMAmdNfA7FpJ
 ng0AczH1V2Gtol1SpdRzGH2Yxy/KqmPeTXSVhSAVzxmF5o/WtKTSahk1G k=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: MKHEBmf4ue0VjpPmTbPNTKxCtdeiif7GQ5dWGKBB38Y/74KaBON2lQb9jlqL+0GsLJgRqAhDu1
 EPou1uevZVE5XymxWIDwqc/tpkMm3NT24wzKrOiPv1Ig8i0rk3CMPRbEeMsZbYpUIHZIPhaeIj
 ScXbgnjnNhDOCQXm6bUvafnAEosolny5lR0plb1vvulpPG6f8w5s800XuOSVkgyNQeRHEgxa08
 UMzLtJA05nWmbhuJF/d6qJTfYVIeMJlMMmGqKh3MjL9h1V9IYWe5bHcWpYBX6jk/YVJ5DRWdVL
 qNA=
X-SBRS: 2.7
X-MesageID: 16023369
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="16023369"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v10 3/3] x86/tlb: use Xen L0 assisted TLB flush when available
Date: Thu, 16 Apr 2020 15:59:09 +0200
Message-ID: <20200416135909.16155-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200416135909.16155-1-roger.pau@citrix.com>
References: <20200416135909.16155-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.

The following figures are from a PV guest running `make -j32 xen` in
shim mode with 32 vCPUs and HAP.

Using x2APIC and ALLBUT shorthand:
real	4m35.973s
user	4m35.110s
sys	36m24.117s

Using L0 assisted flush:
real    1m2.596s
user    4m34.818s
sys     5m16.374s

The implementation adds a new hook to hypervisor_ops so other
enlightenments can also implement such assisted flush just by filling
the hook.

Note that the Xen implementation completely ignores the dirty CPU mask
and the linear address passed in, and always performs a global TLB
flush on all vCPUs. This is a limitation of the hypercall provided by
Xen. Also note that local TLB flushes are not performed using the
assisted TLB flush, only remote ones.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Changes since v5:
 - Clarify commit message.
 - Test for assisted flush at setup, do this for all hypervisors.
 - Return EOPNOTSUPP if assisted flush is not available.

Changes since v4:
 - Adjust order calculation.

Changes since v3:
 - Use an alternative call for the flush hook.

Changes since v1:
 - Add a L0 assisted hook to hypervisor ops.
---
 xen/arch/x86/guest/hypervisor.c        | 14 ++++++++++++++
 xen/arch/x86/guest/xen/xen.c           |  6 ++++++
 xen/arch/x86/smp.c                     |  7 +++++++
 xen/include/asm-x86/guest/hypervisor.h | 17 +++++++++++++++++
 4 files changed, 44 insertions(+)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 647cdb1367..e46de42ded 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -18,6 +18,7 @@
  *
  * Copyright (c) 2019 Microsoft.
  */
+#include <xen/cpumask.h>
 #include <xen/init.h>
 #include <xen/types.h>
 
@@ -51,6 +52,10 @@ void __init hypervisor_setup(void)
 {
     if ( ops.setup )
         ops.setup();
+
+    /* Check if assisted flush is available and disable the TLB clock if so. */
+    if ( !hypervisor_flush_tlb(cpumask_of(smp_processor_id()), NULL, 0) )
+        tlb_clk_enabled = false;
 }
 
 int hypervisor_ap_setup(void)
@@ -73,6 +78,15 @@ void __init hypervisor_e820_fixup(struct e820map *e820)
         ops.e820_fixup(e820);
 }
 
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+                         unsigned int order)
+{
+    if ( ops.flush_tlb )
+        return alternative_call(ops.flush_tlb, mask, va, order);
+
+    return -EOPNOTSUPP;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index e74fd1e995..3bc01c8723 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -324,12 +324,18 @@ static void __init e820_fixup(struct e820map *e820)
         pv_shim_fixup_e820(e820);
 }
 
+static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int order)
+{
+    return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
+}
+
 static const struct hypervisor_ops __initconstrel ops = {
     .name = "Xen",
     .setup = setup,
     .ap_setup = ap_setup,
     .resume = resume,
     .e820_fixup = e820_fixup,
+    .flush_tlb = flush_tlb,
 };
 
 const struct hypervisor_ops *__init xg_probe(void)
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index bcead5d01b..1d9fec65de 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -15,6 +15,7 @@
 #include <xen/perfc.h>
 #include <xen/spinlock.h>
 #include <asm/current.h>
+#include <asm/guest.h>
 #include <asm/smp.h>
 #include <asm/mc146818rtc.h>
 #include <asm/flushtlb.h>
@@ -268,6 +269,12 @@ void flush_area_mask(const cpumask_t *mask, const void *va, unsigned int flags)
     if ( (flags & ~FLUSH_ORDER_MASK) &&
          !cpumask_subset(mask, cpumask_of(cpu)) )
     {
+        if ( cpu_has_hypervisor &&
+             !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID |
+                         FLUSH_ORDER_MASK)) &&
+             !hypervisor_flush_tlb(mask, va, (flags - 1) & FLUSH_ORDER_MASK) )
+            return;
+
         spin_lock(&flush_lock);
         cpumask_and(&flush_cpumask, mask, &cpu_online_map);
         cpumask_clear_cpu(cpu, &flush_cpumask);
diff --git a/xen/include/asm-x86/guest/hypervisor.h b/xen/include/asm-x86/guest/hypervisor.h
index ade10e74ea..77a1d21824 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -19,6 +19,8 @@
 #ifndef __X86_HYPERVISOR_H__
 #define __X86_HYPERVISOR_H__
 
+#include <xen/cpumask.h>
+
 #include <asm/e820.h>
 
 struct hypervisor_ops {
@@ -32,6 +34,8 @@ struct hypervisor_ops {
     void (*resume)(void);
     /* Fix up e820 map */
     void (*e820_fixup)(struct e820map *e820);
+    /* L0 assisted TLB flush */
+    int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int order);
 };
 
 #ifdef CONFIG_GUEST
@@ -41,6 +45,14 @@ void hypervisor_setup(void);
 int hypervisor_ap_setup(void);
 void hypervisor_resume(void);
 void hypervisor_e820_fixup(struct e820map *e820);
+/*
+ * L0 assisted TLB flush.
+ * mask: cpumask of the dirty vCPUs that should be flushed.
+ * va: linear address to flush, or NULL for global flushes.
+ * order: order of the linear address pointed by va.
+ */
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+                         unsigned int order);
 
 #else
 
@@ -52,6 +64,11 @@ static inline void hypervisor_setup(void) { ASSERT_UNREACHABLE(); }
 static inline int hypervisor_ap_setup(void) { return 0; }
 static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
 static inline void hypervisor_e820_fixup(struct e820map *e820) {}
+static inline int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+                                       unsigned int order)
+{
+    return -EOPNOTSUPP;
+}
 
 #endif  /* CONFIG_GUEST */
 
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 14:00:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 14:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP542-00059I-2F; Thu, 16 Apr 2020 14:00:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8YfG=6A=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jP541-00059B-3f
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:00:21 +0000
X-Inumbo-ID: 9baf24da-7fea-11ea-9e09-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9baf24da-7fea-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 14:00:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587045620;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=OVEGa+BBaSJHb0mtRikxXra1nYF8Nodlx6a7ie+oOaw=;
 b=FKhVdNl0s/lCdJcPBr+D4hPfaCfnnLAqn0yX4HoXvYtqkYs1/wTVcI/w
 P4fgF0TNzd8TlTA2qh77OZQkd9aYV4OKj30ZqKQcCkv7Sm9GfQfas4qU6
 K9Hngh+Ti0FdsGRLShRba6DHKL77ZnfnBB3LNPTEaKK/Z1mb1y3YvQc9s g=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: AhAbhK9I6BM6LOJPACLRR6pOah5wrRusMiBK7p1r0iLfgDUPWQfydBKVxOF9smQg4niD0q9gQY
 D60W3tk2tLwTw8Xeilvs9w2cnWLhEpJM4Uk2dl3vmLlAyjevsR/J8a956W5XxQIX77RKBEAHRC
 cGD1W3xfajEVr0bcHac9V1s4xcCv4tLnAaHi7Uan8YXbBVlkvSWfGy9XQDVt/LTtskmNd91ONM
 wYAZDQbcwiUQ/2gb0QbkhcRRHonA5hu0Wm9LByQ6sVWzcgl7603SAOrnYzxwUhwwdWaT/r/3L9
 Hhw=
X-SBRS: 2.7
X-MesageID: 16183925
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="16183925"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v10 0/3] x86/guest: use assisted TLB flush in guest mode
Date: Thu, 16 Apr 2020 15:59:06 +0200
Message-ID: <20200416135909.16155-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George
 Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hello,

This is the remaining of the assisted TLB flush series. This last set of
patches enable the usage of the Xen assisted flush when running nested
on Xen.

Thanks, Roger.

Roger Pau Monne (3):
  x86/tlb: introduce a flush HVM ASIDs flag
  x86/tlb: allow disabling the TLB clock
  x86/tlb: use Xen L0 assisted TLB flush when available

 xen/arch/x86/flushtlb.c                | 37 ++++++++++++++++++++------
 xen/arch/x86/guest/hypervisor.c        | 14 ++++++++++
 xen/arch/x86/guest/xen/xen.c           |  6 +++++
 xen/arch/x86/mm/hap/hap.c              |  8 +++---
 xen/arch/x86/mm/hap/nested_hap.c       |  2 +-
 xen/arch/x86/mm/p2m-pt.c               |  5 ++--
 xen/arch/x86/mm/paging.c               |  2 +-
 xen/arch/x86/mm/shadow/common.c        | 18 ++++++-------
 xen/arch/x86/mm/shadow/hvm.c           |  2 +-
 xen/arch/x86/mm/shadow/multi.c         | 16 +++++------
 xen/arch/x86/mm/shadow/private.h       |  6 +++++
 xen/arch/x86/smp.c                     |  7 +++++
 xen/include/asm-x86/flushtlb.h         | 25 ++++++++++++++++-
 xen/include/asm-x86/guest/hypervisor.h | 17 ++++++++++++
 14 files changed, 130 insertions(+), 35 deletions(-)

-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 14:18:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 14:18:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP5LH-0006SG-Hb; Thu, 16 Apr 2020 14:18:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=IxKm=6A=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jP5LG-0006SB-MF
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:18:10 +0000
X-Inumbo-ID: 18d10a76-7fed-11ea-b4f4-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 18d10a76-7fed-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 14:18:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587046690;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=Kh3BmGMTXO9P5LsWmgax8Nkxw/HZZ74qwzH8KOZvnEM=;
 b=LbdF3kOI2VwG1mhyutV0gG4jpTAWFt80PP0W4/N8nYoK7Y6nKWNWITXX
 gg7vup+4FxGPhp8EBzMY+FlH59NO9JcSb/OVGeFP1oPX0Y1UAi5u5SA4T
 Bgkumzwu0w+38c5X8DVJaXY+KCx/cwF3XNWNA5mOQ5E52nxbncuxj4gds k=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: igkCrR43vR+I/WSxy3qHtrkK8+NajL66CnFaQAXwphlv+exSsRge3ssGaJJ2CotAZ96DATBjsV
 mxDeGLo06KmCst1NyKZoeTaYlaw9eBwqZysJJ36WidO5+v1MOnDRsueiPleOIG/R6g3BmhiuDl
 7IcMccig8Mgp8gnCzjqvAW7BG0uWt9JFBg8RYQjbh+fEAKQUvFwEb0qt6pKKYOKB3eMSxtMZon
 qjb39SE77g/3nZROsAYE4JpJcrYfHwAfe/OzxZKjofmA4ayfJRl4mELTOZ+S0aQUxgJIDHNJyG
 MBE=
X-SBRS: 2.7
X-MesageID: 15767899
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="15767899"
Date: Thu, 16 Apr 2020 15:17:52 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 18/18] build, include: rework compat-build-header.py
Message-ID: <20200416141752.GK4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-19-anthony.perard@citrix.com>
 <7bd39b51-5dee-40f5-1524-f36aad6b7d06@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7bd39b51-5dee-40f5-1524-f36aad6b7d06@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 08, 2020 at 03:56:02PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:31, Anthony PERARD wrote:
> > Replace a mix of shell script and python script by all python script.
> > 
> > Remove the unnecessary "grep -v '^# [0-9]'". It is to hide the
> > linemarkers generated by the preprocessor. But adding -P inhibit there
> > generation, thus the grep isn't needed anymore.
> > 
> > gcc -E -P and clang -E -P have different behavior. While both don't
> > generates linemarkers, gcc also removes all empty lines while clang
> > keep them all. We don't need those empty lines, so we don't generates
> > them in the final compat/%.h headers. (This replace `uniq` which was
> > only de-duplicating empty line.)
> > 
> > The only changes in the final generated headers it that they don't
> > have empty lines anymore.
> 
> Making them harder to read? While typically no-one needs to look at
> their contents, in case of problems it helps if generated files are
> half way accessible to a human as well.

I do think they are still readable. Those empty lines don't add much.
There are so many of them that a `uniq` is needed...

For example, with dm_op.h, we have this:

<<<<<<< before
#pragma pack(4)
typedef uint16_t ioservid_compat_t;
struct compat_dm_op_create_ioreq_server {

    uint8_t handle_bufioreq;
    uint8_t pad[3];

    ioservid_compat_t id;
};
struct compat_dm_op_get_ioreq_server_info {

    ioservid_compat_t id;

    uint16_t flags;

    evtchn_port_compat_t bufioreq_port;

    uint64_t ioreq_gfn;

    uint64_t bufioreq_gfn;
};
struct compat_dm_op_ioreq_server_range {

    ioservid_compat_t id;
    uint16_t pad;

    uint32_t type;

    uint64_t start, end;
};
=======
#pragma pack(4)
typedef uint16_t ioservid_compat_t;
struct compat_dm_op_create_ioreq_server {
    uint8_t handle_bufioreq;
    uint8_t pad[3];
    ioservid_compat_t id;
};
struct compat_dm_op_get_ioreq_server_info {
    ioservid_compat_t id;
    uint16_t flags;
    evtchn_port_compat_t bufioreq_port;
    uint64_t ioreq_gfn;
    uint64_t bufioreq_gfn;
};
struct compat_dm_op_ioreq_server_range {
    ioservid_compat_t id;
    uint16_t pad;
    uint32_t type;
    uint64_t start, end;
};
>>>>>>> after

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 14:22:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 14:22:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP5PC-0007EJ-4k; Thu, 16 Apr 2020 14:22:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP5PB-0007EE-EP
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:22:13 +0000
X-Inumbo-ID: a9e2b7bc-7fed-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a9e2b7bc-7fed-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 14:22:12 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E5750AC37;
 Thu, 16 Apr 2020 14:22:10 +0000 (UTC)
Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-15-anthony.perard@citrix.com>
 <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
 <20200416124400.GG4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <312e719f-2bae-cb29-a6dd-29ae0d976d95@suse.com>
Date: Thu, 16 Apr 2020 16:22:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416124400.GG4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.2020 14:44, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>> We want to use the same rune to build mm/*/guest_*.o as the one use to
>>> build every other *.o object. The consequence it that file symbols that
>>> the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
>>>
>>> (1) Currently we have those two file symbols:
>>>     guest_walk.c
>>>     guest_walk_2.o
>>> (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have:
>>>     arch/x86/mm/guest_walk.c
>>>     guest_walk_2.o
>>>
>>> The order in which those symbols are present may be different.
>>>
>>> Currently, in case (1) ./symbols chooses the *.o symbol (object file
>>> name). But in case (2), may choose the *.c symbol (source file name with
>>> path component) if it is first
>>>
>>> We want to have ./symbols choose the object file name symbol in both
>>> cases.
>>
>> I guess the reason for wanting this is somehow connected to the
>> statement at the beginning of the description, but I can't seem
>> to be able to make the connection.
> 
> I'm not sure I can explain it better.
> 
> The "object file name" file symbol is used to distinguish between symbols
> from all mm/*/guest_* objects. The other file symbol present in those
> object is a "source file name without any path component symbol".
> 
> But building those objects with the same rune as any other objects, and
> having CONFIG_ENFORCE_UNIQUE_SYMBOLS=y, changes the file symbols present
> in the resulting object. We still have the "object file name" symbol,
> but now we also have "source file name with path components" symbol.
> Unfortunately, all mm/*/guest_*.o in one directory are built from the
> same source file, and thus have the same "source file name" symbol, but
> have different "object file name" symbol. We still want to be able to
> distinguish between guest_*.o in one dir, and the only way for that is
> to use the "object file name" symbol.

So where's the difference from how things work right now? The "same rune"
aspect doesn't really change - right now we also build with effectively
the same logic, just that -DGUEST_PAGING_LEVELS=... gets added. I guess
it might help if you showed (for one particular example) how the set of
file symbols changes from what we have now (with and without
CONFIG_ENFORCE_UNIQUE_SYMBOLS=y) to what there would be with your changes
to the symbols utility to what there will be with those changes.

>>> So this patch changes that ./symbols prefer the "object file
>>> name" symbol over the "source file name with path component" symbols.
>>>
>>> The new intended order of preference is:
>>>     - first object file name symbol
>>>     - first source file name with path components symbol
>>>     - last source file name without any path component symbol
>>
>> Isn't this going to lead to ambiguities again when
>> CONFIG_ENFORCE_UNIQUE_SYMBOLS? Several object files (in different
>> dirs) are named the same, after all. Static symbols with the same
>> name in such objects would hence resolve to the same kallsyms
>> name.
> 
> "object file name" symbol are only present in mm/*/guest_*.o objects,
> they all have different basenames. There is no ambiguity here.

At least not right now, I see. Could you make this aspect more explicit
by adding something like "(present only in object files produced from
multiply compiled sources)" to the first bullet point?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 14:28:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 14:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP5V7-0007Rj-0s; Thu, 16 Apr 2020 14:28:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP5V5-0007Re-5Y
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:28:19 +0000
X-Inumbo-ID: 83d853be-7fee-11ea-8ba3-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 83d853be-7fee-11ea-8ba3-12813bfff9fa;
 Thu, 16 Apr 2020 14:28:18 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A75B5AC37;
 Thu, 16 Apr 2020 14:28:16 +0000 (UTC)
Subject: Re: [XEN PATCH v4 15/18] xen/build: use if_changed to build guest_%.o
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-16-anthony.perard@citrix.com>
 <9bf47db9-e3cf-fffd-cfb2-18dec2317c91@suse.com>
 <20200416125708.GH4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <9c8ca283-329a-2f75-815c-f867e6c6beb0@suse.com>
Date: Thu, 16 Apr 2020 16:28:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416125708.GH4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.2020 14:57, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 03:02:21PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>> Use if_changed for building all guest_%.o objects, and make use of
>>> command that already exist.
>>>
>>> This patch make a change to the way guest_%.o files are built, and now
>>> run the same commands that enforce unique symbols. But with patch
>>> "xen,symbols: rework file symbols selection", ./symbols should still
>>> select the file symbols directive intended to be used for guest_%.o
>>> objects.
>>
>> I'm having trouble making the connection between the change to the
>> symbols tool and the adjustments made here:
> 
> The change to symbol tool is to allow this change.

I've been understanding the fact, but I still don't understand why
the adjustment to that tool is necessary for the change here to be
made.

>>> --- a/xen/arch/x86/mm/Makefile
>>> +++ b/xen/arch/x86/mm/Makefile
>>> @@ -11,11 +11,13 @@ obj-y += p2m.o p2m-pt.o
>>>  obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
>>>  obj-y += paging.o
>>>  
>>> -guest_walk_%.o: guest_walk.c Makefile
>>> -	$(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
>>
>> The original rules didn't do anything special to arrange for the
>> resulting kallsyms names; these arrangements instead live at the
>> top of the respective source files, in the form of asm()-s.
> 
> They still are. I try to consolidate the number of location which have
> command that build a target. Those guest_%.o object aren't special
> enough to deserve to be built in a different way than every other
> object. They do need a different make rule, but they can use the same
> command.

Again, I understand what the goal is, but not what it is that
changes (and why) in the produced file symbols, making the utility
adjustment necessary. I guess it's obvious to you, but it looks as
if I was dense, sorry.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 14:30:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 14:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP5XH-0008CA-Eu; Thu, 16 Apr 2020 14:30:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP5XG-0008C5-3i
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:30:34 +0000
X-Inumbo-ID: d464c54c-7fee-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d464c54c-7fee-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 14:30:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2BCB2AC37;
 Thu, 16 Apr 2020 14:30:32 +0000 (UTC)
Subject: Re: [XEN PATCH v4 16/18] build,xsm: Fix multiple call
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-17-anthony.perard@citrix.com>
 <809cba94-cebf-29c6-39d5-31ec41bdbdc4@suse.com>
 <20200416130250.GI4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3c6caf8e-43cd-9635-1ff3-db8bdb0e2851@suse.com>
Date: Thu, 16 Apr 2020 16:30:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416130250.GI4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.2020 15:02, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 03:28:06PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:31, Anthony PERARD wrote:
>>> Both script mkflask.sh and mkaccess_vector.sh generates multiple
>>> files. Exploits the 'multi-target pattern rule' trick to call each
>>> scripts only once.
>>
>> Isn't this a general fix, which may even want backporting? If so,
>> this would better be at or near the beginning of the series.
> 
> It is mostly a performance improvement, avoiding doing the same thing
> several time. I don't think anything bad happens from concurrent calls,
> or we would already have bug report I think. But I can try to move the
> patch up.

Up to three processes in parallel writing to the same file(s) is
almost certainly a recipe for eventual / random breakage.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 14:34:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 14:34:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP5aw-0008M7-0a; Thu, 16 Apr 2020 14:34:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP5au-0008M2-Pd
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:34:20 +0000
X-Inumbo-ID: 5b52c8a6-7fef-11ea-8ba5-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5b52c8a6-7fef-11ea-8ba5-12813bfff9fa;
 Thu, 16 Apr 2020 14:34:20 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 264B4ACB1;
 Thu, 16 Apr 2020 14:34:18 +0000 (UTC)
Subject: Re: [XEN PATCH v4 18/18] build, include: rework compat-build-header.py
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-19-anthony.perard@citrix.com>
 <7bd39b51-5dee-40f5-1524-f36aad6b7d06@suse.com>
 <20200416141752.GK4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <b53178f6-ab3d-e784-4f22-914279989915@suse.com>
Date: Thu, 16 Apr 2020 16:34:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416141752.GK4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.2020 16:17, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 03:56:02PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:31, Anthony PERARD wrote:
>>> Replace a mix of shell script and python script by all python script.
>>>
>>> Remove the unnecessary "grep -v '^# [0-9]'". It is to hide the
>>> linemarkers generated by the preprocessor. But adding -P inhibit there
>>> generation, thus the grep isn't needed anymore.
>>>
>>> gcc -E -P and clang -E -P have different behavior. While both don't
>>> generates linemarkers, gcc also removes all empty lines while clang
>>> keep them all. We don't need those empty lines, so we don't generates
>>> them in the final compat/%.h headers. (This replace `uniq` which was
>>> only de-duplicating empty line.)
>>>
>>> The only changes in the final generated headers it that they don't
>>> have empty lines anymore.
>>
>> Making them harder to read? While typically no-one needs to look at
>> their contents, in case of problems it helps if generated files are
>> half way accessible to a human as well.
> 
> I do think they are still readable. Those empty lines don't add much.
> There are so many of them that a `uniq` is needed...
> 
> For example, with dm_op.h, we have this:

Let me take a different example, grant_table.h: Not all of the
blank lines it has are useful, but I think the file would suffer
if all of them got removed.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:07:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP674-0002Qk-Rt; Thu, 16 Apr 2020 15:07:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jP673-0002Qe-Fx
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:07:33 +0000
X-Inumbo-ID: fb09668c-7ff3-11ea-8bb2-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fb09668c-7ff3-11ea-8bb2-12813bfff9fa;
 Thu, 16 Apr 2020 15:07:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=t67nOYaMeF6H30Lg13i+CSUy3GdwKh1cc0/QNY6wOMc=; b=ZuIBJ/Xw6CT2jhpYlPZYWohnb
 eXdqsaEI6jEwGEt8MsaHo8isMUmRUAdpZNWUQpVnG5lyt6HCWdvwPG3S6sNsLjJUwHDLa+oNaQnDC
 NK6+EWH5HCdY9jY+yG7W/knFFhQtGYoMSZBCIt2oxGQmee0d8UJmuwK+zaQP2I6jVz0Mo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jP66w-00079R-CR; Thu, 16 Apr 2020 15:07:26 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jP66w-0006H7-3Y; Thu, 16 Apr 2020 15:07:26 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jP66w-0001cY-2w; Thu, 16 Apr 2020 15:07:26 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149676-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.10-testing test] 149676: tolerable trouble: fail/pass/starved
 - PUSHED
X-Osstest-Failures: xen-4.10-testing:test-xtf-amd64-amd64-5:xtf/test-hvm64-lbr-tsx-vmentry:fail:heisenbug
 xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-saverestore.2:fail:heisenbug
 xen-4.10-testing:test-armhf-armhf-xl-credit2:guest-start/debian.repeat:fail:heisenbug
 xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: xen=24d62e126296b3f67dabdd49887d41d8ed69487f
X-Osstest-Versions-That: xen=49a5d6e92317a7d9acbf0bdbd25b2809dfd84260
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 15:07:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-5 51 xtf/test-hvm64-lbr-tsx-vmentry fail in 149650 pass in 149676
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-saverestore.2 fail pass in 149650
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 149650

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop   fail in 149650 never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 146076
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop             fail like 146101
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-xl-thunderx  2 hosts-allocate               starved  n/a

version targeted for testing:
 xen                  24d62e126296b3f67dabdd49887d41d8ed69487f
baseline version:
 xen                  49a5d6e92317a7d9acbf0bdbd25b2809dfd84260

Last test of basis   146101  2020-01-15 04:00:32 Z   92 days
Testing same since   149650  2020-04-14 13:35:36 Z    2 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Pawel Wieczorkiewicz <wipawel@amazon.de>
  Ross Lagerwall <ross.lagerwall@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 starved 
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   49a5d6e923..24d62e1262  24d62e126296b3f67dabdd49887d41d8ed69487f -> stable-4.10


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:09:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:09:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP695-0002Xn-DJ; Thu, 16 Apr 2020 15:09:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=IxKm=6A=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jP693-0002Xg-Ki
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:09:37 +0000
X-Inumbo-ID: 48c8e3f0-7ff4-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 48c8e3f0-7ff4-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 15:09:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587049776;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=ChKu0i0nSi6EMnag20ygWtX4kVH+ovYT9LFgD+AjFxo=;
 b=N3V6x/67TzjanvyEXB8JlN44UOsD48CFxi2+FXyEGhcpuba8sxnhXaVD
 /WBWSqkaxbgBR+ZLxLom+HHvex/eyzN5GU0/zKBWbgmi2F9TjZXI2qrwo
 t/eErcqK3/9uCSHyJaaH/muY/JLuAaIUG+7PaXpzsjfztTHQbmPSDbum/ U=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: AmhUQPUlUSjl9wmL1u5t85OXeRiaLuz6AYMwgR2PHw9NgsQveLSgw9kfUmLHzNAzD7Km7ibzPu
 eJs1nRW74xOkYHaixzZABCxSIXSwXHvLXpPn+juDvdjctB+sZn1cC02SWcC1wTE2oQAsc3IJ6s
 4oAA7j8Rxw9e9WuKa/p4+xEWz5DGuu7VtQufHp7VORfa0N/L/lDNuzl1gINrnWvEA+92IDlDAY
 jmN7lO6m0I3NAXlZwHY3sQj+vxqI5LRZBVMf7sP1VBXBsBXC9Ty1Em4OHv+MYImLXGMTsXiR2d
 axs=
X-SBRS: 2.7
X-MesageID: 15802529
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="15802529"
Date: Thu, 16 Apr 2020 16:09:29 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
Message-ID: <20200416150929.GL4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-15-anthony.perard@citrix.com>
 <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
 <20200416124400.GG4088@perard.uk.xensource.com>
 <312e719f-2bae-cb29-a6dd-29ae0d976d95@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <312e719f-2bae-cb29-a6dd-29ae0d976d95@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 16, 2020 at 04:22:05PM +0200, Jan Beulich wrote:
> On 16.04.2020 14:44, Anthony PERARD wrote:
> > On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
> >> On 31.03.2020 12:30, Anthony PERARD wrote:
> >>> We want to use the same rune to build mm/*/guest_*.o as the one use to
> >>> build every other *.o object. The consequence it that file symbols that
> >>> the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
> >>>
> >>> (1) Currently we have those two file symbols:
> >>>     guest_walk.c
> >>>     guest_walk_2.o
> >>> (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have:
> >>>     arch/x86/mm/guest_walk.c
> >>>     guest_walk_2.o
> >>>
> >>> The order in which those symbols are present may be different.
> >>>
> >>> Currently, in case (1) ./symbols chooses the *.o symbol (object file
> >>> name). But in case (2), may choose the *.c symbol (source file name with
> >>> path component) if it is first
> >>>
> >>> We want to have ./symbols choose the object file name symbol in both
> >>> cases.
> >>
> >> I guess the reason for wanting this is somehow connected to the
> >> statement at the beginning of the description, but I can't seem
> >> to be able to make the connection.
> > 
> > I'm not sure I can explain it better.
> > 
> > The "object file name" file symbol is used to distinguish between symbols
> > from all mm/*/guest_* objects. The other file symbol present in those
> > object is a "source file name without any path component symbol".
> > 
> > But building those objects with the same rune as any other objects, and
> > having CONFIG_ENFORCE_UNIQUE_SYMBOLS=y, changes the file symbols present
> > in the resulting object. We still have the "object file name" symbol,
> > but now we also have "source file name with path components" symbol.
> > Unfortunately, all mm/*/guest_*.o in one directory are built from the
> > same source file, and thus have the same "source file name" symbol, but
> > have different "object file name" symbol. We still want to be able to
> > distinguish between guest_*.o in one dir, and the only way for that is
> > to use the "object file name" symbol.
> 
> So where's the difference from how things work right now? The "same rune"
> aspect doesn't really change - right now we also build with effectively
> the same logic, just that -DGUEST_PAGING_LEVELS=... gets added. I guess
> it might help if you showed (for one particular example) how the set of
> file symbols changes from what we have now (with and without
> CONFIG_ENFORCE_UNIQUE_SYMBOLS=y) to what there would be with your changes
> to the symbols utility to what there will be with those changes.

The logic to build objects from C files changed in 81ecb38b83b0 ("build:
provide option to disambiguate symbol names"), with objects build with
__OBJECT_FILE__ explicitly left alone. So the logic is different now (at
least when CONFIG_ENFORCE_UNIQUE_SYMBOLS=y).

I did add the example of building arch/x86/mm/guest_walk_2.o to the
commit message, reworded below:

For example, when building arch/x86/mm/guest_walk_2.o from guest_walk.c,
this would be the difference of file symbol present in the object when
building with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y:

(1) Currently we have those two file symbols:
    guest_walk.c
    guest_walk_2.o
(2) When building with the same rune, we will have:
    arch/x86/mm/guest_walk.c
    guest_walk_2.o

The order in which those symbols are present may be different. Building
without CONFIG_ENFORCE_UNIQUE_SYMBOLS will result in (1).


> >>> So this patch changes that ./symbols prefer the "object file
> >>> name" symbol over the "source file name with path component" symbols.
> >>>
> >>> The new intended order of preference is:
> >>>     - first object file name symbol
> >>>     - first source file name with path components symbol
> >>>     - last source file name without any path component symbol
> >>
> >> Isn't this going to lead to ambiguities again when
> >> CONFIG_ENFORCE_UNIQUE_SYMBOLS? Several object files (in different
> >> dirs) are named the same, after all. Static symbols with the same
> >> name in such objects would hence resolve to the same kallsyms
> >> name.
> > 
> > "object file name" symbol are only present in mm/*/guest_*.o objects,
> > they all have different basenames. There is no ambiguity here.
> 
> At least not right now, I see. Could you make this aspect more explicit
> by adding something like "(present only in object files produced from
> multiply compiled sources)" to the first bullet point?

Will do.

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:16:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP6FE-0003T7-Gr; Thu, 16 Apr 2020 15:16:00 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jP6FD-0003T2-LE
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:15:59 +0000
X-Inumbo-ID: 29fd881c-7ff5-11ea-8bb5-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 29fd881c-7ff5-11ea-8bb5-12813bfff9fa;
 Thu, 16 Apr 2020 15:15:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=OJxzv3b3I9OCWxF4mc0kKX5TwR7Pke/UxOMxuCT5JEI=; b=Ng8W7B5ZZk1MTyB2t70iacG7k
 l6uw0rtOMmqrr06UHgfzzIKr0TSDGVnmLtJ4zjGPJSAVjA2aV31WkxnbHD8Mmcxx5vfxX5dArDCOj
 e9rFMa0aPQ6k20mURJf5RomJ3xPjREcQ8s6FUCtcfbSRD/jp+9OJfX5QjndiZ+/Lt91yU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jP6F7-0007Jm-Fo; Thu, 16 Apr 2020 15:15:53 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jP6F7-0006dg-1M; Thu, 16 Apr 2020 15:15:53 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jP6F7-0007jv-0l; Thu, 16 Apr 2020 15:15:53 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149688-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149688: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=a48e1323f9aa29f1ffb95594671b73de6bd7c1d4
X-Osstest-Versions-That: xen=615bfe42c6d183a0e54a0525ef82b58580d01619
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 15:15:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  a48e1323f9aa29f1ffb95594671b73de6bd7c1d4
baseline version:
 xen                  615bfe42c6d183a0e54a0525ef82b58580d01619

Last test of basis   149686  2020-04-16 09:01:03 Z    0 days
Testing same since   149688  2020-04-16 12:01:12 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Harsha Shamsundara Havanur <havanur@amazon.com>
  Hongyan Xia <hongyxia@amazon.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Wei Liu <wei.liu2@citrix.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   615bfe42c6..a48e1323f9  a48e1323f9aa29f1ffb95594671b73de6bd7c1d4 -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:43:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:43:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP6fI-0005ru-QA; Thu, 16 Apr 2020 15:42:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP6fH-0005rp-65
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:42:55 +0000
X-Inumbo-ID: efdc777a-7ff8-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id efdc777a-7ff8-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 15:42:54 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 11271AC79;
 Thu, 16 Apr 2020 15:42:53 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH 0/6] x86/mem-paging: misc cleanup
Message-ID: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Date: Thu, 16 Apr 2020 17:42:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Repeatedly looking at varying parts of this code has lead to
me accumulating a few adjustments.

1: fold p2m_mem_paging_prep()'s main if()-s
2: correct p2m_mem_paging_prep()'s error handling
3: use guest handle for XENMEM_paging_op_prep
4: add minimal lock order enforcement to p2m_mem_paging_prep()
5: move code to its dedicated source file
6: consistently use gfn_t

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:44:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP6hH-0005ys-8x; Thu, 16 Apr 2020 15:44:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP6hG-0005yk-4Y
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:44:58 +0000
X-Inumbo-ID: 393736e4-7ff9-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 393736e4-7ff9-11ea-83d8-bc764e2007e4;
 Thu, 16 Apr 2020 15:44:57 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 30189AB5C;
 Thu, 16 Apr 2020 15:44:56 +0000 (UTC)
Subject: [PATCH 1/6] x86/mem-paging: fold p2m_mem_paging_prep()'s main if()-s
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Message-ID: <44a7d9ce-6c38-89a7-f558-4db220dcb21d@suse.com>
Date: Thu, 16 Apr 2020 17:44:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The condition of the second can be true only if the condition of the
first was met; the second half of the condition of the second then also
is redundant with an earlier check. Combine them, drop a pointless
local variable, and re-flow the affected gdprintk().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1808,6 +1808,8 @@ int p2m_mem_paging_prep(struct domain *d
     /* Allocate a page if the gfn does not have one yet */
     if ( !mfn_valid(mfn) )
     {
+        void *guest_map;
+
         /* If the user did not provide a buffer, we disallow */
         ret = -EINVAL;
         if ( unlikely(user_ptr == NULL) )
@@ -1819,22 +1821,16 @@ int p2m_mem_paging_prep(struct domain *d
             goto out;
         mfn = page_to_mfn(page);
         page_extant = 0;
-    }
-
-    /* If we were given a buffer, now is the time to use it */
-    if ( !page_extant && user_ptr )
-    {
-        void *guest_map;
-        int rc;
 
         ASSERT( mfn_valid(mfn) );
         guest_map = map_domain_page(mfn);
-        rc = copy_from_user(guest_map, user_ptr, PAGE_SIZE);
+        ret = copy_from_user(guest_map, user_ptr, PAGE_SIZE);
         unmap_domain_page(guest_map);
-        if ( rc )
+        if ( ret )
         {
-            gdprintk(XENLOG_ERR, "Failed to load paging-in gfn %lx domain %u "
-                                 "bytes left %d\n", gfn_l, d->domain_id, rc);
+            gdprintk(XENLOG_ERR,
+                     "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
+                     gfn_l, d->domain_id, ret);
             ret = -EFAULT;
             put_page(page); /* Don't leak pages */
             goto out;            



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:45:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:45:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP6hm-00062O-Jg; Thu, 16 Apr 2020 15:45:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP6hl-00062G-8s
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:45:29 +0000
X-Inumbo-ID: 4bc17702-7ff9-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4bc17702-7ff9-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 15:45:28 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4A5A6AB5C;
 Thu, 16 Apr 2020 15:45:27 +0000 (UTC)
Subject: [PATCH 2/6] x86/mem-paging: correct p2m_mem_paging_prep()'s error
 handling
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Message-ID: <853d915a-4748-00c2-e065-9cd8ef63f279@suse.com>
Date: Thu, 16 Apr 2020 17:45:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Communicating errors from p2m_set_entry() to the caller is not enough:
Neither the M2P nor the stats updates should occur in such a case.
Instead the allocated page needs to be freed again; for cleanliness
reasons also properly take into account _PGC_allocated there.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1781,7 +1781,7 @@ void p2m_mem_paging_populate(struct doma
  */
 int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l, uint64_t buffer)
 {
-    struct page_info *page;
+    struct page_info *page = NULL;
     p2m_type_t p2mt;
     p2m_access_t a;
     gfn_t gfn = _gfn(gfn_l);
@@ -1816,9 +1816,19 @@ int p2m_mem_paging_prep(struct domain *d
             goto out;
         /* Get a free page */
         ret = -ENOMEM;
-        page = alloc_domheap_page(p2m->domain, 0);
+        page = alloc_domheap_page(d, 0);
         if ( unlikely(page == NULL) )
             goto out;
+        if ( unlikely(!get_page(page, d)) )
+        {
+            /*
+             * The domain can't possibly know about this page yet, so failure
+             * here is a clear indication of something fishy going on.
+             */
+            domain_crash(d);
+            page = NULL;
+            goto out;
+        }
         mfn = page_to_mfn(page);
         page_extant = 0;
 
@@ -1832,7 +1842,6 @@ int p2m_mem_paging_prep(struct domain *d
                      "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
                      gfn_l, d->domain_id, ret);
             ret = -EFAULT;
-            put_page(page); /* Don't leak pages */
             goto out;            
         }
     }
@@ -1843,13 +1852,24 @@ int p2m_mem_paging_prep(struct domain *d
     ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
                         paging_mode_log_dirty(d) ? p2m_ram_logdirty
                                                  : p2m_ram_rw, a);
-    set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
+    if ( !ret )
+    {
+        set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
 
-    if ( !page_extant )
-        atomic_dec(&d->paged_pages);
+        if ( !page_extant )
+            atomic_dec(&d->paged_pages);
+    }
 
  out:
     gfn_unlock(p2m, gfn, 0);
+
+    if ( page )
+    {
+        if ( ret )
+            put_page_alloc_ref(page);
+        put_page(page);
+    }
+
     return ret;
 }
 



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:46:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP6iY-00068m-Uo; Thu, 16 Apr 2020 15:46:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP6iX-00068W-HE
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:46:17 +0000
X-Inumbo-ID: 685b5374-7ff9-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 685b5374-7ff9-11ea-9e09-bc764e2007e4;
 Thu, 16 Apr 2020 15:46:16 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 146EEAC50;
 Thu, 16 Apr 2020 15:46:15 +0000 (UTC)
Subject: [PATCH 3/6] x86/mem-paging: use guest handle for XENMEM_paging_op_prep
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Message-ID: <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
Date: Thu, 16 Apr 2020 17:46:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While it should have been this way from the beginning, not doing so will
become an actual problem with PVH Dom0. The interface change is binary
compatible, but requires tools side producers to be re-built.

Drop the bogus/unnecessary page alignment restriction on the input
buffer at the same time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Is there really no way to avoid the buffer copying in libxc?

--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -26,15 +26,33 @@ static int xc_mem_paging_memop(xc_interf
                                unsigned int op, uint64_t gfn, void *buffer)
 {
     xen_mem_paging_op_t mpo;
+    DECLARE_HYPERCALL_BOUNCE(buffer, XC_PAGE_SIZE,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    int rc;
 
     memset(&mpo, 0, sizeof(mpo));
 
     mpo.op      = op;
     mpo.domain  = domain_id;
     mpo.gfn     = gfn;
-    mpo.buffer  = (unsigned long) buffer;
 
-    return do_memory_op(xch, XENMEM_paging_op, &mpo, sizeof(mpo));
+    if ( buffer )
+    {
+        if ( xc_hypercall_bounce_pre(xch, buffer) )
+        {
+            PERROR("Could not bounce memory for XENMEM_paging_op %u", op);
+            return -1;
+        }
+
+        set_xen_guest_handle(mpo.buffer, buffer);
+    }
+
+    rc = do_memory_op(xch, XENMEM_paging_op, &mpo, sizeof(mpo));
+
+    if ( buffer )
+        xc_hypercall_bounce_post(xch, buffer);
+
+    return rc;
 }
 
 int xc_mem_paging_enable(xc_interface *xch, uint32_t domain_id,
@@ -92,28 +110,13 @@ int xc_mem_paging_prep(xc_interface *xch
 int xc_mem_paging_load(xc_interface *xch, uint32_t domain_id,
                        uint64_t gfn, void *buffer)
 {
-    int rc, old_errno;
-
     errno = EINVAL;
 
     if ( !buffer )
         return -1;
 
-    if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
-        return -1;
-
-    if ( mlock(buffer, XC_PAGE_SIZE) )
-        return -1;
-
-    rc = xc_mem_paging_memop(xch, domain_id,
-                             XENMEM_paging_op_prep,
-                             gfn, buffer);
-
-    old_errno = errno;
-    munlock(buffer, XC_PAGE_SIZE);
-    errno = old_errno;
-
-    return rc;
+    return xc_mem_paging_memop(xch, domain_id, XENMEM_paging_op_prep,
+                               gfn, buffer);
 }
 
 
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1779,7 +1779,8 @@ void p2m_mem_paging_populate(struct doma
  * mfn if populate was called for  gfn which was nominated but not evicted. In
  * this case only the p2mt needs to be forwarded.
  */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l, uint64_t buffer)
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l,
+                        XEN_GUEST_HANDLE_PARAM(const_uint8) buffer)
 {
     struct page_info *page = NULL;
     p2m_type_t p2mt;
@@ -1788,13 +1789,9 @@ int p2m_mem_paging_prep(struct domain *d
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret, page_extant = 1;
-    const void *user_ptr = (const void *) buffer;
 
-    if ( user_ptr )
-        /* Sanity check the buffer and bail out early if trouble */
-        if ( (buffer & (PAGE_SIZE - 1)) || 
-             (!access_ok(user_ptr, PAGE_SIZE)) )
-            return -EINVAL;
+    if ( !guest_handle_okay(buffer, PAGE_SIZE) )
+        return -EINVAL;
 
     gfn_lock(p2m, gfn, 0);
 
@@ -1812,7 +1809,7 @@ int p2m_mem_paging_prep(struct domain *d
 
         /* If the user did not provide a buffer, we disallow */
         ret = -EINVAL;
-        if ( unlikely(user_ptr == NULL) )
+        if ( unlikely(guest_handle_is_null(buffer)) )
             goto out;
         /* Get a free page */
         ret = -ENOMEM;
@@ -1834,7 +1831,7 @@ int p2m_mem_paging_prep(struct domain *d
 
         ASSERT( mfn_valid(mfn) );
         guest_map = map_domain_page(mfn);
-        ret = copy_from_user(guest_map, user_ptr, PAGE_SIZE);
+        ret = copy_from_guest(guest_map, buffer, PAGE_SIZE);
         unmap_domain_page(guest_map);
         if ( ret )
         {
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -741,7 +741,8 @@ void p2m_mem_paging_drop_page(struct dom
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer);
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn,
+                        XEN_GUEST_HANDLE_PARAM(const_uint8) buffer);
 /* Resume normal operation (in case a domain was paused) */
 struct vm_event_st;
 void p2m_mem_paging_resume(struct domain *d, struct vm_event_st *rsp);
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -396,10 +396,10 @@ struct xen_mem_paging_op {
     uint8_t     op;         /* XENMEM_paging_op_* */
     domid_t     domain;
 
-    /* PAGING_PREP IN: buffer to immediately fill page in */
-    uint64_aligned_t    buffer;
-    /* Other OPs */
-    uint64_aligned_t    gfn;           /* IN:  gfn of page being operated on */
+    /* IN: (XENMEM_paging_op_prep) buffer to immediately fill page from */
+    XEN_GUEST_HANDLE_64(const_uint8) buffer;
+    /* IN:  gfn of page being operated on */
+    uint64_aligned_t    gfn;
 };
 typedef struct xen_mem_paging_op xen_mem_paging_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_mem_paging_op_t);



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:46:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP6j9-0006E3-DH; Thu, 16 Apr 2020 15:46:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP6j7-0006Dk-L7
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:46:53 +0000
X-Inumbo-ID: 7e1ba772-7ff9-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7e1ba772-7ff9-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 15:46:53 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 82129AC79;
 Thu, 16 Apr 2020 15:46:51 +0000 (UTC)
Subject: [PATCH 4/6] x86/mem-paging: add minimal lock order enforcement to
 p2m_mem_paging_prep()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Message-ID: <e0609729-0a07-6f67-f278-3809ec92dd83@suse.com>
Date: Thu, 16 Apr 2020 17:46:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While full checking is impossible (as the lock is being acquired/
released down the call tree), perform at least a lock level check.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1813,6 +1813,7 @@ int p2m_mem_paging_prep(struct domain *d
             goto out;
         /* Get a free page */
         ret = -ENOMEM;
+        page_alloc_mm_pre_lock(d);
         page = alloc_domheap_page(d, 0);
         if ( unlikely(page == NULL) )
             goto out;



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:47:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP6k2-0006Kq-PZ; Thu, 16 Apr 2020 15:47:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP6k2-0006Ki-7g
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:47:50 +0000
X-Inumbo-ID: 9eace8df-7ff9-11ea-8bb9-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9eace8df-7ff9-11ea-8bb9-12813bfff9fa;
 Thu, 16 Apr 2020 15:47:48 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9613DAC50;
 Thu, 16 Apr 2020 15:47:46 +0000 (UTC)
Subject: [PATCH 5/6] x86/mem-paging: move code to its dedicated source file
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Message-ID: <8a4378ee-c086-b847-ba0f-a84d257f5c54@suse.com>
Date: Thu, 16 Apr 2020 17:47:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Do a little bit of style adjustment along the way, and drop the
"p2m_mem_paging_" prefixes from the now static functions.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,6 +25,421 @@
 #include <xen/vm_event.h>
 #include <xsm/xsm.h>
 
+#include "mm-locks.h"
+
+/*
+ * p2m_mem_paging_drop_page - Tell pager to drop its reference to a paged page
+ * @d: guest domain
+ * @gfn: guest page to drop
+ *
+ * p2m_mem_paging_drop_page() will notify the pager that a paged-out gfn was
+ * released by the guest. The pager is supposed to drop its reference of the
+ * gfn.
+ */
+void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
+                              p2m_type_t p2mt)
+{
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_PAGING,
+        .u.mem_paging.gfn = gfn
+    };
+
+    /*
+     * We allow no ring in this unique case, because it won't affect
+     * correctness of the guest execution at this point.  If this is the only
+     * page that happens to be paged-out, we'll be okay..  but it's likely the
+     * guest will crash shortly anyways.
+     */
+    int rc = vm_event_claim_slot(d, d->vm_event_paging);
+
+    if ( rc < 0 )
+        return;
+
+    /* Send release notification to pager */
+    req.u.mem_paging.flags = MEM_PAGING_DROP_PAGE;
+
+    /* Update stats unless the page hasn't yet been evicted */
+    if ( p2mt != p2m_ram_paging_out )
+        atomic_dec(&d->paged_pages);
+    else
+        /* Evict will fail now, tag this request for pager */
+        req.u.mem_paging.flags |= MEM_PAGING_EVICT_FAIL;
+
+    vm_event_put_request(d, d->vm_event_paging, &req);
+}
+
+/*
+ * p2m_mem_paging_populate - Tell pager to populate a paged page
+ * @d: guest domain
+ * @gfn: guest page in paging state
+ *
+ * p2m_mem_paging_populate() will notify the pager that a page in any of the
+ * paging states needs to be written back into the guest.
+ * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
+ * paging types because the gfn may not be backed by a mfn.
+ *
+ * The gfn can be in any of the paging states, but the pager needs only be
+ * notified when the gfn is in the paging-out path (paging_out or paged).  This
+ * function may be called more than once from several vcpus. If the vcpu belongs
+ * to the guest, the vcpu must be stopped and the pager notified that the vcpu
+ * was stopped. The pager needs to handle several requests for the same gfn.
+ *
+ * If the gfn is not in the paging-out path and the vcpu does not belong to the
+ * guest, nothing needs to be done and the function assumes that a request was
+ * already sent to the pager. In this case the caller has to try again until the
+ * gfn is fully paged in again.
+ */
+void p2m_mem_paging_populate(struct domain *d, unsigned long gfn_l)
+{
+    struct vcpu *v = current;
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_PAGING,
+        .u.mem_paging.gfn = gfn_l
+    };
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    gfn_t gfn = _gfn(gfn_l);
+    mfn_t mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int rc = vm_event_claim_slot(d, d->vm_event_paging);
+
+    /* We're paging. There should be a ring. */
+    if ( rc == -EOPNOTSUPP )
+    {
+        gdprintk(XENLOG_ERR, "Dom%d paging gfn %lx yet no ring in place\n",
+                 d->domain_id, gfn_l);
+        /* Prevent the vcpu from faulting repeatedly on the same gfn */
+        if ( v->domain == d )
+            vcpu_pause_nosync(v);
+        domain_crash(d);
+        return;
+    }
+    else if ( rc < 0 )
+        return;
+
+    /* Fix p2m mapping */
+    gfn_lock(p2m, gfn, 0);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+    /* Allow only nominated or evicted pages to enter page-in path */
+    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
+    {
+        /* Evict will fail now, tag this request for pager */
+        if ( p2mt == p2m_ram_paging_out )
+            req.u.mem_paging.flags |= MEM_PAGING_EVICT_FAIL;
+
+        rc = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+    }
+    gfn_unlock(p2m, gfn, 0);
+    if ( rc < 0 )
+        goto out_cancel;
+
+    /* Pause domain if request came from guest and gfn has paging type */
+    if ( p2m_is_paging(p2mt) && v->domain == d )
+    {
+        vm_event_vcpu_pause(v);
+        req.flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+    }
+    /* No need to inform pager if the gfn is not in the page-out path */
+    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
+    {
+        /* gfn is already on its way back and vcpu is not paused */
+    out_cancel:
+        vm_event_cancel_slot(d, d->vm_event_paging);
+        return;
+    }
+
+    /* Send request to pager */
+    req.u.mem_paging.p2mt = p2mt;
+    req.vcpu_id = v->vcpu_id;
+
+    vm_event_put_request(d, d->vm_event_paging, &req);
+}
+
+/*
+ * p2m_mem_paging_resume - Resume guest gfn
+ * @d: guest domain
+ * @rsp: vm_event response received
+ *
+ * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw. It is
+ * called by the pager.
+ *
+ * The gfn was previously either evicted and populated, or nominated and
+ * populated. If the page was evicted the p2mt will be p2m_ram_paging_in. If
+ * the page was just nominated the p2mt will be p2m_ram_paging_in_start because
+ * the pager did not call prepare().
+ *
+ * If the gfn was dropped the vcpu needs to be unpaused.
+ */
+void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    mfn_t mfn;
+
+    /* Fix p2m entry if the page was not dropped */
+    if ( !(rsp->u.mem_paging.flags & MEM_PAGING_DROP_PAGE) )
+    {
+        gfn_t gfn = _gfn(rsp->u.mem_access.gfn);
+
+        gfn_lock(p2m, gfn, 0);
+        mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+        /*
+         * Allow only pages which were prepared properly, or pages which
+         * were nominated but not evicted.
+         */
+        if ( mfn_valid(mfn) && (p2mt == p2m_ram_paging_in) )
+        {
+            int rc = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                                   paging_mode_log_dirty(d) ? p2m_ram_logdirty
+                                                            : p2m_ram_rw, a);
+
+            if ( !rc )
+                set_gpfn_from_mfn(mfn_x(mfn), gfn_x(gfn));
+        }
+        gfn_unlock(p2m, gfn, 0);
+    }
+}
+
+/*
+ * nominate - Mark a guest page as to-be-paged-out
+ * @d: guest domain
+ * @gfn: guest page to nominate
+ *
+ * Returns 0 for success or negative errno values if gfn is not pageable.
+ *
+ * nominate() is called by the pager and checks if a guest page can be paged
+ * out. If the following conditions are met the p2mt will be changed:
+ * - the gfn is backed by a mfn
+ * - the p2mt of the gfn is pageable
+ * - the mfn is not used for IO
+ * - the mfn has exactly one user and has no special meaning
+ *
+ * Once the p2mt is changed the page is readonly for the guest.  On success the
+ * pager can write the page contents to disk and later evict the page.
+ */
+static int nominate(struct domain *d, unsigned long gfn_l)
+{
+    struct page_info *page;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    gfn_t gfn = _gfn(gfn_l);
+    mfn_t mfn;
+    int ret = -EBUSY;
+
+    gfn_lock(p2m, gfn, 0);
+
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+
+    /* Check if mfn is valid */
+    if ( !mfn_valid(mfn) )
+        goto out;
+
+    /* Check p2m type */
+    if ( !p2m_is_pageable(p2mt) )
+        goto out;
+
+    /* Check for io memory page */
+    if ( is_iomem_page(mfn) )
+        goto out;
+
+    /* Check page count and type */
+    page = mfn_to_page(mfn);
+    if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
+         (1 | PGC_allocated) )
+        goto out;
+
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
+        goto out;
+
+    /* Fix p2m entry */
+    ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
+
+ out:
+    gfn_unlock(p2m, gfn, 0);
+    return ret;
+}
+
+/*
+ * evict - Mark a guest page as paged-out
+ * @d: guest domain
+ * @gfn: guest page to evict
+ *
+ * Returns 0 for success or negative errno values if eviction is not possible.
+ *
+ * evict() is called by the pager and will free a guest page and release it
+ * back to Xen. If the following conditions are met the page can be freed:
+ * - the gfn is backed by a mfn
+ * - the gfn was nominated
+ * - the mfn has still exactly one user and has no special meaning
+ *
+ * After successful nomination some other process could have mapped the page. In
+ * this case eviction can not be done. If the gfn was populated before the pager
+ * could evict it, eviction can not be done either. In this case the gfn is
+ * still backed by a mfn.
+ */
+static int evict(struct domain *d, unsigned long gfn_l)
+{
+    struct page_info *page;
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    gfn_t gfn = _gfn(gfn_l);
+    mfn_t mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int ret = -EBUSY;
+
+    gfn_lock(p2m, gfn, 0);
+
+    /* Get mfn */
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+    if ( unlikely(!mfn_valid(mfn)) )
+        goto out;
+
+    /* Allow only nominated pages */
+    if ( p2mt != p2m_ram_paging_out )
+        goto out;
+
+    /* Get the page so it doesn't get modified under Xen's feet */
+    page = mfn_to_page(mfn);
+    if ( unlikely(!get_page(page, d)) )
+        goto out;
+
+    /* Check page count and type once more */
+    if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
+         (2 | PGC_allocated) )
+        goto out_put;
+
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
+        goto out_put;
+
+    /* Decrement guest domain's ref count of the page */
+    put_page_alloc_ref(page);
+
+    /* Remove mapping from p2m table */
+    ret = p2m_set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
+                        p2m_ram_paged, a);
+
+    /* Clear content before returning the page to Xen */
+    scrub_one_page(page);
+
+    /* Track number of paged gfns */
+    atomic_inc(&d->paged_pages);
+
+ out_put:
+    /* Put the page back so it gets freed */
+    put_page(page);
+
+ out:
+    gfn_unlock(p2m, gfn, 0);
+    return ret;
+}
+
+/*
+ * prepare - Allocate a new page for the guest
+ * @d: guest domain
+ * @gfn: guest page in paging state
+ *
+ * prepare() will allocate a new page for the guest if the gfn is not backed
+ * by a mfn. It is called by the pager.
+ * It is required that the gfn was already populated. The gfn may already have a
+ * mfn if populate was called for  gfn which was nominated but not evicted. In
+ * this case only the p2mt needs to be forwarded.
+ */
+static int prepare(struct domain *d, unsigned long gfn_l,
+                   XEN_GUEST_HANDLE_PARAM(const_uint8) buffer)
+{
+    struct page_info *page = NULL;
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    gfn_t gfn = _gfn(gfn_l);
+    mfn_t mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int ret, page_extant = 1;
+
+    if ( !guest_handle_okay(buffer, PAGE_SIZE) )
+        return -EINVAL;
+
+    gfn_lock(p2m, gfn, 0);
+
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+
+    ret = -ENOENT;
+    /* Allow missing pages */
+    if ( (p2mt != p2m_ram_paging_in) && (p2mt != p2m_ram_paged) )
+        goto out;
+
+    /* Allocate a page if the gfn does not have one yet */
+    if ( !mfn_valid(mfn) )
+    {
+        void *guest_map;
+
+        /* If the user did not provide a buffer, we disallow */
+        ret = -EINVAL;
+        if ( unlikely(guest_handle_is_null(buffer)) )
+            goto out;
+        /* Get a free page */
+        ret = -ENOMEM;
+        page_alloc_mm_pre_lock(d);
+        page = alloc_domheap_page(d, 0);
+        if ( unlikely(page == NULL) )
+            goto out;
+        if ( unlikely(!get_page(page, d)) )
+        {
+            /*
+             * The domain can't possibly know about this page yet, so failure
+             * here is a clear indication of something fishy going on.
+             */
+            domain_crash(d);
+            page = NULL;
+            goto out;
+        }
+        mfn = page_to_mfn(page);
+        page_extant = 0;
+
+        ASSERT( mfn_valid(mfn) );
+        guest_map = map_domain_page(mfn);
+        ret = copy_from_guest(guest_map, buffer, PAGE_SIZE);
+        unmap_domain_page(guest_map);
+        if ( ret )
+        {
+            gdprintk(XENLOG_ERR,
+                     "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
+                     gfn_l, d->domain_id, ret);
+            ret = -EFAULT;
+            goto out;
+        }
+    }
+
+    /*
+     * Make the page already guest-accessible. If the pager still has a
+     * pending resume operation, it will be idempotent p2m entry-wise, but
+     * will unpause the vcpu.
+     */
+    ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                        paging_mode_log_dirty(d) ? p2m_ram_logdirty
+                                                 : p2m_ram_rw, a);
+    if ( !ret )
+    {
+        set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
+
+        if ( !page_extant )
+            atomic_dec(&d->paged_pages);
+    }
+
+ out:
+    gfn_unlock(p2m, gfn, 0);
+
+    if ( page )
+    {
+        if ( ret )
+            put_page_alloc_ref(page);
+        put_page(page);
+    }
+
+    return ret;
+}
+
 int mem_paging_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
 {
     int rc;
@@ -50,15 +465,15 @@ int mem_paging_memop(XEN_GUEST_HANDLE_PA
     switch( mpo.op )
     {
     case XENMEM_paging_op_nominate:
-        rc = p2m_mem_paging_nominate(d, mpo.gfn);
+        rc = nominate(d, mpo.gfn);
         break;
 
     case XENMEM_paging_op_evict:
-        rc = p2m_mem_paging_evict(d, mpo.gfn);
+        rc = evict(d, mpo.gfn);
         break;
 
     case XENMEM_paging_op_prep:
-        rc = p2m_mem_paging_prep(d, mpo.gfn, mpo.buffer);
+        rc = prepare(d, mpo.gfn, mpo.buffer);
         if ( !rc )
             copyback = 1;
         break;
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -23,7 +23,6 @@
  * along with this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
-#include <xen/guest_access.h> /* copy_from_guest() */
 #include <xen/iommu.h>
 #include <xen/mem_access.h>
 #include <xen/vm_event.h>
@@ -1506,418 +1505,6 @@ int set_shared_p2m_entry(struct domain *
     return rc;
 }
 
-/**
- * p2m_mem_paging_nominate - Mark a guest page as to-be-paged-out
- * @d: guest domain
- * @gfn: guest page to nominate
- *
- * Returns 0 for success or negative errno values if gfn is not pageable.
- *
- * p2m_mem_paging_nominate() is called by the pager and checks if a guest page
- * can be paged out. If the following conditions are met the p2mt will be
- * changed:
- * - the gfn is backed by a mfn
- * - the p2mt of the gfn is pageable
- * - the mfn is not used for IO
- * - the mfn has exactly one user and has no special meaning
- *
- * Once the p2mt is changed the page is readonly for the guest.  On success the
- * pager can write the page contents to disk and later evict the page.
- */
-int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn_l)
-{
-    struct page_info *page;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
-    mfn_t mfn;
-    int ret = -EBUSY;
-
-    gfn_lock(p2m, gfn, 0);
-
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-
-    /* Check if mfn is valid */
-    if ( !mfn_valid(mfn) )
-        goto out;
-
-    /* Check p2m type */
-    if ( !p2m_is_pageable(p2mt) )
-        goto out;
-
-    /* Check for io memory page */
-    if ( is_iomem_page(mfn) )
-        goto out;
-
-    /* Check page count and type */
-    page = mfn_to_page(mfn);
-    if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
-         (1 | PGC_allocated) )
-        goto out;
-
-    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
-        goto out;
-
-    /* Fix p2m entry */
-    ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
-
- out:
-    gfn_unlock(p2m, gfn, 0);
-    return ret;
-}
-
-/**
- * p2m_mem_paging_evict - Mark a guest page as paged-out
- * @d: guest domain
- * @gfn: guest page to evict
- *
- * Returns 0 for success or negative errno values if eviction is not possible.
- *
- * p2m_mem_paging_evict() is called by the pager and will free a guest page and
- * release it back to Xen. If the following conditions are met the page can be
- * freed:
- * - the gfn is backed by a mfn
- * - the gfn was nominated
- * - the mfn has still exactly one user and has no special meaning
- *
- * After successful nomination some other process could have mapped the page. In
- * this case eviction can not be done. If the gfn was populated before the pager
- * could evict it, eviction can not be done either. In this case the gfn is
- * still backed by a mfn.
- */
-int p2m_mem_paging_evict(struct domain *d, unsigned long gfn_l)
-{
-    struct page_info *page;
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
-    mfn_t mfn;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret = -EBUSY;
-
-    gfn_lock(p2m, gfn, 0);
-
-    /* Get mfn */
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-    if ( unlikely(!mfn_valid(mfn)) )
-        goto out;
-
-    /* Allow only nominated pages */
-    if ( p2mt != p2m_ram_paging_out )
-        goto out;
-
-    /* Get the page so it doesn't get modified under Xen's feet */
-    page = mfn_to_page(mfn);
-    if ( unlikely(!get_page(page, d)) )
-        goto out;
-
-    /* Check page count and type once more */
-    if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
-         (2 | PGC_allocated) )
-        goto out_put;
-
-    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
-        goto out_put;
-
-    /* Decrement guest domain's ref count of the page */
-    put_page_alloc_ref(page);
-
-    /* Remove mapping from p2m table */
-    ret = p2m_set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
-                        p2m_ram_paged, a);
-
-    /* Clear content before returning the page to Xen */
-    scrub_one_page(page);
-
-    /* Track number of paged gfns */
-    atomic_inc(&d->paged_pages);
-
- out_put:
-    /* Put the page back so it gets freed */
-    put_page(page);
-
- out:
-    gfn_unlock(p2m, gfn, 0);
-    return ret;
-}
-
-/**
- * p2m_mem_paging_drop_page - Tell pager to drop its reference to a paged page
- * @d: guest domain
- * @gfn: guest page to drop
- *
- * p2m_mem_paging_drop_page() will notify the pager that a paged-out gfn was
- * released by the guest. The pager is supposed to drop its reference of the
- * gfn.
- */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
-                                p2m_type_t p2mt)
-{
-    vm_event_request_t req = {
-        .reason = VM_EVENT_REASON_MEM_PAGING,
-        .u.mem_paging.gfn = gfn
-    };
-
-    /* We allow no ring in this unique case, because it won't affect
-     * correctness of the guest execution at this point.  If this is the only
-     * page that happens to be paged-out, we'll be okay..  but it's likely the
-     * guest will crash shortly anyways. */
-    int rc = vm_event_claim_slot(d, d->vm_event_paging);
-    if ( rc < 0 )
-        return;
-
-    /* Send release notification to pager */
-    req.u.mem_paging.flags = MEM_PAGING_DROP_PAGE;
-
-    /* Update stats unless the page hasn't yet been evicted */
-    if ( p2mt != p2m_ram_paging_out )
-        atomic_dec(&d->paged_pages);
-    else
-        /* Evict will fail now, tag this request for pager */
-        req.u.mem_paging.flags |= MEM_PAGING_EVICT_FAIL;
-
-    vm_event_put_request(d, d->vm_event_paging, &req);
-}
-
-/**
- * p2m_mem_paging_populate - Tell pager to populate a paged page
- * @d: guest domain
- * @gfn: guest page in paging state
- *
- * p2m_mem_paging_populate() will notify the pager that a page in any of the
- * paging states needs to be written back into the guest.
- * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
- * paging types because the gfn may not be backed by a mfn.
- *
- * The gfn can be in any of the paging states, but the pager needs only be
- * notified when the gfn is in the paging-out path (paging_out or paged).  This
- * function may be called more than once from several vcpus. If the vcpu belongs
- * to the guest, the vcpu must be stopped and the pager notified that the vcpu
- * was stopped. The pager needs to handle several requests for the same gfn.
- *
- * If the gfn is not in the paging-out path and the vcpu does not belong to the
- * guest, nothing needs to be done and the function assumes that a request was
- * already sent to the pager. In this case the caller has to try again until the
- * gfn is fully paged in again.
- */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn_l)
-{
-    struct vcpu *v = current;
-    vm_event_request_t req = {
-        .reason = VM_EVENT_REASON_MEM_PAGING,
-        .u.mem_paging.gfn = gfn_l
-    };
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
-    mfn_t mfn;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-
-    /* We're paging. There should be a ring */
-    int rc = vm_event_claim_slot(d, d->vm_event_paging);
-
-    if ( rc == -EOPNOTSUPP )
-    {
-        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
-                             "in place\n", d->domain_id, gfn_l);
-        /* Prevent the vcpu from faulting repeatedly on the same gfn */
-        if ( v->domain == d )
-            vcpu_pause_nosync(v);
-        domain_crash(d);
-        return;
-    }
-    else if ( rc < 0 )
-        return;
-
-    /* Fix p2m mapping */
-    gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-    /* Allow only nominated or evicted pages to enter page-in path */
-    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
-    {
-        /* Evict will fail now, tag this request for pager */
-        if ( p2mt == p2m_ram_paging_out )
-            req.u.mem_paging.flags |= MEM_PAGING_EVICT_FAIL;
-
-        rc = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
-    }
-    gfn_unlock(p2m, gfn, 0);
-    if ( rc < 0 )
-        goto out_cancel;
-
-    /* Pause domain if request came from guest and gfn has paging type */
-    if ( p2m_is_paging(p2mt) && v->domain == d )
-    {
-        vm_event_vcpu_pause(v);
-        req.flags |= VM_EVENT_FLAG_VCPU_PAUSED;
-    }
-    /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
-    {
-        /* gfn is already on its way back and vcpu is not paused */
-    out_cancel:
-        vm_event_cancel_slot(d, d->vm_event_paging);
-        return;
-    }
-
-    /* Send request to pager */
-    req.u.mem_paging.p2mt = p2mt;
-    req.vcpu_id = v->vcpu_id;
-
-    vm_event_put_request(d, d->vm_event_paging, &req);
-}
-
-/**
- * p2m_mem_paging_prep - Allocate a new page for the guest
- * @d: guest domain
- * @gfn: guest page in paging state
- *
- * p2m_mem_paging_prep() will allocate a new page for the guest if the gfn is
- * not backed by a mfn. It is called by the pager.
- * It is required that the gfn was already populated. The gfn may already have a
- * mfn if populate was called for  gfn which was nominated but not evicted. In
- * this case only the p2mt needs to be forwarded.
- */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l,
-                        XEN_GUEST_HANDLE_PARAM(const_uint8) buffer)
-{
-    struct page_info *page = NULL;
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
-    mfn_t mfn;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret, page_extant = 1;
-
-    if ( !guest_handle_okay(buffer, PAGE_SIZE) )
-        return -EINVAL;
-
-    gfn_lock(p2m, gfn, 0);
-
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-
-    ret = -ENOENT;
-    /* Allow missing pages */
-    if ( (p2mt != p2m_ram_paging_in) && (p2mt != p2m_ram_paged) )
-        goto out;
-
-    /* Allocate a page if the gfn does not have one yet */
-    if ( !mfn_valid(mfn) )
-    {
-        void *guest_map;
-
-        /* If the user did not provide a buffer, we disallow */
-        ret = -EINVAL;
-        if ( unlikely(guest_handle_is_null(buffer)) )
-            goto out;
-        /* Get a free page */
-        ret = -ENOMEM;
-        page_alloc_mm_pre_lock(d);
-        page = alloc_domheap_page(d, 0);
-        if ( unlikely(page == NULL) )
-            goto out;
-        if ( unlikely(!get_page(page, d)) )
-        {
-            /*
-             * The domain can't possibly know about this page yet, so failure
-             * here is a clear indication of something fishy going on.
-             */
-            domain_crash(d);
-            page = NULL;
-            goto out;
-        }
-        mfn = page_to_mfn(page);
-        page_extant = 0;
-
-        ASSERT( mfn_valid(mfn) );
-        guest_map = map_domain_page(mfn);
-        ret = copy_from_guest(guest_map, buffer, PAGE_SIZE);
-        unmap_domain_page(guest_map);
-        if ( ret )
-        {
-            gdprintk(XENLOG_ERR,
-                     "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
-                     gfn_l, d->domain_id, ret);
-            ret = -EFAULT;
-            goto out;            
-        }
-    }
-
-    /* Make the page already guest-accessible. If the pager still has a
-     * pending resume operation, it will be idempotent p2m entry-wise,
-     * but will unpause the vcpu */
-    ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
-                        paging_mode_log_dirty(d) ? p2m_ram_logdirty
-                                                 : p2m_ram_rw, a);
-    if ( !ret )
-    {
-        set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
-
-        if ( !page_extant )
-            atomic_dec(&d->paged_pages);
-    }
-
- out:
-    gfn_unlock(p2m, gfn, 0);
-
-    if ( page )
-    {
-        if ( ret )
-            put_page_alloc_ref(page);
-        put_page(page);
-    }
-
-    return ret;
-}
-
-/**
- * p2m_mem_paging_resume - Resume guest gfn
- * @d: guest domain
- * @rsp: vm_event response received
- *
- * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw. It is
- * called by the pager.
- *
- * The gfn was previously either evicted and populated, or nominated and
- * populated. If the page was evicted the p2mt will be p2m_ram_paging_in. If
- * the page was just nominated the p2mt will be p2m_ram_paging_in_start because
- * the pager did not call p2m_mem_paging_prep().
- *
- * If the gfn was dropped the vcpu needs to be unpaused.
- */
-
-void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
-{
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    mfn_t mfn;
-
-    /* Fix p2m entry if the page was not dropped */
-    if ( !(rsp->u.mem_paging.flags & MEM_PAGING_DROP_PAGE) )
-    {
-        gfn_t gfn = _gfn(rsp->u.mem_access.gfn);
-
-        gfn_lock(p2m, gfn, 0);
-        mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-        /*
-         * Allow only pages which were prepared properly, or pages which
-         * were nominated but not evicted.
-         */
-        if ( mfn_valid(mfn) && (p2mt == p2m_ram_paging_in) )
-        {
-            int rc = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
-                                   paging_mode_log_dirty(d) ? p2m_ram_logdirty :
-                                   p2m_ram_rw, a);
-
-            if ( !rc )
-                set_gpfn_from_mfn(mfn_x(mfn), gfn_x(gfn));
-        }
-        gfn_unlock(p2m, gfn, 0);
-    }
-}
-
 #ifdef CONFIG_HVM
 static struct p2m_domain *
 p2m_getlru_nestedp2m(struct domain *d, struct p2m_domain *p2m)
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -731,18 +731,11 @@ static inline void p2m_pod_init(struct p
 /* Modify p2m table for shared gfn */
 int set_shared_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 
-/* Check if a nominated gfn is valid to be paged out */
-int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn);
-/* Evict a frame */
-int p2m_mem_paging_evict(struct domain *d, unsigned long gfn);
 /* Tell xenpaging to drop a paged out frame */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn, 
                                 p2m_type_t p2mt);
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
-/* Prepare the p2m for paging a frame in */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn,
-                        XEN_GUEST_HANDLE_PARAM(const_uint8) buffer);
 /* Resume normal operation (in case a domain was paused) */
 struct vm_event_st;
 void p2m_mem_paging_resume(struct domain *d, struct vm_event_st *rsp);



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 15:48:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 15:48:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP6kb-0006RP-89; Thu, 16 Apr 2020 15:48:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=CeM5=6A=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jP6kZ-0006RH-Rv
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 15:48:23 +0000
X-Inumbo-ID: b38d291c-7ff9-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b38d291c-7ff9-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 15:48:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2E78FAC79;
 Thu, 16 Apr 2020 15:48:21 +0000 (UTC)
Subject: [PATCH 6/6] x86/mem-paging: consistently use gfn_t
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Message-ID: <224337b8-98b4-b0f6-a57a-6f508ffa6838@suse.com>
Date: Thu, 16 Apr 2020 17:48:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -278,7 +278,7 @@ static int set_mem_type(struct domain *d
         if ( p2m_is_paging(t) )
         {
             put_gfn(d, pfn);
-            p2m_mem_paging_populate(d, pfn);
+            p2m_mem_paging_populate(d, _gfn(pfn));
             return -EAGAIN;
         }
 
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1968,7 +1968,7 @@ int hvm_hap_nested_page_fault(paddr_t gp
      * locks in such circumstance.
      */
     if ( paged )
-        p2m_mem_paging_populate(currd, gfn);
+        p2m_mem_paging_populate(currd, _gfn(gfn));
 
     if ( sharing_enomem )
     {
@@ -3199,7 +3199,7 @@ enum hvm_translation_result hvm_translat
     if ( p2m_is_paging(p2mt) )
     {
         put_page(page);
-        p2m_mem_paging_populate(v->domain, gfn_x(gfn));
+        p2m_mem_paging_populate(v->domain, gfn);
         return HVMTRANS_gfn_paged_out;
     }
     if ( p2m_is_shared(p2mt) )
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2151,16 +2151,17 @@ static int mod_l1_entry(l1_pgentry_t *pl
              paging_mode_translate(pg_dom) )
         {
             p2m_type_t p2mt;
+            unsigned long gfn = l1e_get_pfn(nl1e);
             p2m_query_t q = l1e_get_flags(nl1e) & _PAGE_RW ?
                             P2M_ALLOC | P2M_UNSHARE : P2M_ALLOC;
 
-            page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), &p2mt, q);
+            page = get_page_from_gfn(pg_dom, gfn, &p2mt, q);
 
             if ( p2m_is_paged(p2mt) )
             {
                 if ( page )
                     put_page(page);
-                p2m_mem_paging_populate(pg_dom, l1e_get_pfn(nl1e));
+                p2m_mem_paging_populate(pg_dom, _gfn(gfn));
                 return -ENOENT;
             }
 
@@ -3982,7 +3983,7 @@ long do_mmu_update(
                     put_page(page);
                 if ( p2m_is_paged(p2mt) )
                 {
-                    p2m_mem_paging_populate(pt_owner, gmfn);
+                    p2m_mem_paging_populate(pt_owner, _gfn(gmfn));
                     rc = -ENOENT;
                 }
                 else
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -68,7 +68,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         *pfec = PFEC_page_paged;
         if ( top_page )
             put_page(top_page);
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
+        p2m_mem_paging_populate(p2m->domain, _gfn(PFN_DOWN(cr3)));
         return gfn_x(INVALID_GFN);
     }
     if ( p2m_is_shared(p2mt) )
@@ -109,7 +109,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         {
             ASSERT(p2m_is_hostp2m(p2m));
             *pfec = PFEC_page_paged;
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+            p2m_mem_paging_populate(p2m->domain, gfn);
             return gfn_x(INVALID_GFN);
         }
         if ( p2m_is_shared(p2mt) )
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -36,12 +36,11 @@
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
-                              p2m_type_t p2mt)
+void p2m_mem_paging_drop_page(struct domain *d, gfn_t gfn, p2m_type_t p2mt)
 {
     vm_event_request_t req = {
         .reason = VM_EVENT_REASON_MEM_PAGING,
-        .u.mem_paging.gfn = gfn
+        .u.mem_paging.gfn = gfn_x(gfn)
     };
 
     /*
@@ -89,16 +88,15 @@ void p2m_mem_paging_drop_page(struct dom
  * already sent to the pager. In this case the caller has to try again until the
  * gfn is fully paged in again.
  */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn_l)
+void p2m_mem_paging_populate(struct domain *d, gfn_t gfn)
 {
     struct vcpu *v = current;
     vm_event_request_t req = {
         .reason = VM_EVENT_REASON_MEM_PAGING,
-        .u.mem_paging.gfn = gfn_l
+        .u.mem_paging.gfn = gfn_x(gfn)
     };
     p2m_type_t p2mt;
     p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int rc = vm_event_claim_slot(d, d->vm_event_paging);
@@ -107,7 +105,7 @@ void p2m_mem_paging_populate(struct doma
     if ( rc == -EOPNOTSUPP )
     {
         gdprintk(XENLOG_ERR, "Dom%d paging gfn %lx yet no ring in place\n",
-                 d->domain_id, gfn_l);
+                 d->domain_id, gfn_x(gfn));
         /* Prevent the vcpu from faulting repeatedly on the same gfn */
         if ( v->domain == d )
             vcpu_pause_nosync(v);
@@ -218,13 +216,12 @@ void p2m_mem_paging_resume(struct domain
  * Once the p2mt is changed the page is readonly for the guest.  On success the
  * pager can write the page contents to disk and later evict the page.
  */
-static int nominate(struct domain *d, unsigned long gfn_l)
+static int nominate(struct domain *d, gfn_t gfn)
 {
     struct page_info *page;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     p2m_type_t p2mt;
     p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
     mfn_t mfn;
     int ret = -EBUSY;
 
@@ -279,12 +276,11 @@ static int nominate(struct domain *d, un
  * could evict it, eviction can not be done either. In this case the gfn is
  * still backed by a mfn.
  */
-static int evict(struct domain *d, unsigned long gfn_l)
+static int evict(struct domain *d, gfn_t gfn)
 {
     struct page_info *page;
     p2m_type_t p2mt;
     p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret = -EBUSY;
@@ -346,13 +342,12 @@ static int evict(struct domain *d, unsig
  * mfn if populate was called for  gfn which was nominated but not evicted. In
  * this case only the p2mt needs to be forwarded.
  */
-static int prepare(struct domain *d, unsigned long gfn_l,
+static int prepare(struct domain *d, gfn_t gfn,
                    XEN_GUEST_HANDLE_PARAM(const_uint8) buffer)
 {
     struct page_info *page = NULL;
     p2m_type_t p2mt;
     p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret, page_extant = 1;
@@ -405,7 +400,7 @@ static int prepare(struct domain *d, uns
         {
             gdprintk(XENLOG_ERR,
                      "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
-                     gfn_l, d->domain_id, ret);
+                     gfn_x(gfn), d->domain_id, ret);
             ret = -EFAULT;
             goto out;
         }
@@ -421,7 +416,7 @@ static int prepare(struct domain *d, uns
                                                  : p2m_ram_rw, a);
     if ( !ret )
     {
-        set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
+        set_gpfn_from_mfn(mfn_x(mfn), gfn_x(gfn));
 
         if ( !page_extant )
             atomic_dec(&d->paged_pages);
@@ -465,15 +460,15 @@ int mem_paging_memop(XEN_GUEST_HANDLE_PA
     switch( mpo.op )
     {
     case XENMEM_paging_op_nominate:
-        rc = nominate(d, mpo.gfn);
+        rc = nominate(d, _gfn(mpo.gfn));
         break;
 
     case XENMEM_paging_op_evict:
-        rc = evict(d, mpo.gfn);
+        rc = evict(d, _gfn(mpo.gfn));
         break;
 
     case XENMEM_paging_op_prep:
-        rc = prepare(d, mpo.gfn, mpo.buffer);
+        rc = prepare(d, _gfn(mpo.gfn), mpo.buffer);
         if ( !rc )
             copyback = 1;
         break;
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1835,7 +1835,7 @@ void *map_domain_gfn(struct p2m_domain *
         ASSERT(p2m_is_hostp2m(p2m));
         if ( page )
             put_page(page);
-        p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+        p2m_mem_paging_populate(p2m->domain, gfn);
         *pfec = PFEC_page_paged;
         return NULL;
     }
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -848,7 +848,7 @@ int guest_wrmsr_xen(struct vcpu *v, uint
 
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, gmfn);
+                p2m_mem_paging_populate(d, _gfn(gmfn));
                 return X86EMUL_RETRY;
             }
 
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -322,7 +322,7 @@ int guest_remove_page(struct domain *d,
 
         put_gfn(d, gmfn);
 
-        p2m_mem_paging_drop_page(d, gmfn, p2mt);
+        p2m_mem_paging_drop_page(d, _gfn(gmfn), p2mt);
 
         return 0;
     }
@@ -1667,7 +1667,7 @@ int check_get_page_from_gfn(struct domai
         if ( page )
             put_page(page);
 
-        p2m_mem_paging_populate(d, gfn_x(gfn));
+        p2m_mem_paging_populate(d, gfn);
         return -EAGAIN;
     }
 #endif
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -732,10 +732,9 @@ static inline void p2m_pod_init(struct p
 int set_shared_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 
 /* Tell xenpaging to drop a paged out frame */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn, 
-                                p2m_type_t p2mt);
+void p2m_mem_paging_drop_page(struct domain *d, gfn_t gfn, p2m_type_t p2mt);
 /* Start populating a paged out frame */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
+void p2m_mem_paging_populate(struct domain *d, gfn_t gfn);
 /* Resume normal operation (in case a domain was paused) */
 struct vm_event_st;
 void p2m_mem_paging_resume(struct domain *d, struct vm_event_st *rsp);



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 16:09:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 16:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP74l-0000IU-46; Thu, 16 Apr 2020 16:09:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=04wr=6A=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jP74j-0000IP-A2
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 16:09:13 +0000
X-Inumbo-ID: 9c0fc71a-7ffc-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9c0fc71a-7ffc-11ea-b4f4-bc764e2007e4;
 Thu, 16 Apr 2020 16:09:12 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3ED57AC50;
 Thu, 16 Apr 2020 16:09:10 +0000 (UTC)
Message-ID: <f3e7c6bfc2203119b2dfc36bd1fb9167b4fbfb2c.camel@suse.com>
Subject: Re: [Xen-devel] [PATCH] sched/core: Fix bug when moving a domain
 between cpupools
From: Dario Faggioli <dfaggioli@suse.com>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, Jeff Kubascik
 <jeff.kubascik@dornerworks.com>, xen-devel@lists.xenproject.org, George
 Dunlap <george.dunlap@citrix.com>
Date: Thu, 16 Apr 2020 18:09:07 +0200
In-Reply-To: <9969e5ea-1378-3439-c9a5-19fb9b5c91ac@suse.com>
References: <20200327193023.506-1-jeff.kubascik@dornerworks.com>
 <9969e5ea-1378-3439-c9a5-19fb9b5c91ac@suse.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-KqD7d3f6zIwiA7UyClwN"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stewart Hildebrand <Stewart.Hildebrand@dornerworks.com>,
 Nathan Studer <Nathan.Studer@dornerworks.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-KqD7d3f6zIwiA7UyClwN
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2020-04-15 at 11:08 +0200, J=C3=BCrgen Gro=C3=9F wrote:
> On 27.03.20 20:30, Jeff Kubascik wrote:
> > For each UNIT, sched_set_affinity is called before unit->priv is
> > updated
> > to the new cpupool private UNIT data structure. The issue is
> > sched_set_affinity will call the adjust_affinity method of the
> > cpupool.
> > If defined, the new cpupool may use unit->priv (e.g. credit), which
> > at
> > this point still references the old cpupool private UNIT data
> > structure.
> >=20
> > This change fixes the bug by moving the switch of unit->priv earler
> > in
> > the function.
> >=20
> > Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
>=20
> Reviewed-by: Juergen Gross <jgross@suse.com>
>
Acked-by: Dario Faggioli <dfaggioli@suse.com>

Sorry it took a while. And thanks Juergen for also having a look.

Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-KqD7d3f6zIwiA7UyClwN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6YgyQACgkQFkJ4iaW4
c+6QkBAA3MtTipEeb+IAbi+rUcCc25N6+aPXu2vxCfuMEP7hWH8NZgA1CfIxGlvc
XHC+wXpgrnPBaowE9x9V3QQ+b9I79T5YgcbZR1KJL06ZzREvtEHfV0yTvYAmULlH
TsnYrtihmh7VwB0Gh57U2VONc+OwKA9D5ghaqbbXrhO1skilHhNqLcAaubFNrevA
oGWNCYqIF5fARxEB61aAltYatLgq7XFEDEqfKvopPibv6bUBTN2ArJ7bdfmmJbOg
J55IFJM8LI/1LtO9/CSbg8WIT/qahPcnPMnvl9LsDDOYU9wdX8o1azP9NAxI3koQ
IvQBJDSx1+zcxl29LSHXFNl20X08uT31EPJ4PYTSItzLi62MhU8afsTOQgeztYt+
1zvOXL4tO71wXMDgXnyUQuT4UbrUUm+0oqTbTz8Xkgqc8G3brAlsSc/9g7UMrGBG
HKZGf7NcqM4KOn9a6j8AYeLNDMf8eylf6C+MtHeMY8axsRMZSD2PjzElyidcuPFn
GvIlm9z8mChBpRyol/iGgJUbtPx9RlXzUwP9XSB8JGrZwd2D0fYwGo1QRbo+S7FN
dnp/rIsbKL3hZOnADHU40xdsomIT7qQB/SsLIHnQLLIML210xaMO6PCrgDHQoIk7
MfK/MY4xbJ7v0VLXC08pGN6JSeM0M7PnaBUJOOd1jtVW+CduI48=
=skAQ
-----END PGP SIGNATURE-----

--=-KqD7d3f6zIwiA7UyClwN--



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 16:11:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 16:11:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP76T-00011V-HD; Thu, 16 Apr 2020 16:11:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=04wr=6A=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jP76S-00011P-OJ
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 16:11:00 +0000
X-Inumbo-ID: dc4e1eda-7ffc-11ea-8bc4-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id dc4e1eda-7ffc-11ea-8bc4-12813bfff9fa;
 Thu, 16 Apr 2020 16:10:59 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 462E9AB3D;
 Thu, 16 Apr 2020 16:10:58 +0000 (UTC)
Message-ID: <559fe5e03caa954f6985e074940b5eb076b0af3f.camel@suse.com>
Subject: Re: [PATCH] sched: fix scheduler_disable() with core scheduling
From: Dario Faggioli <dfaggioli@suse.com>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, Sergey Dyasli
 <sergey.dyasli@citrix.com>, xen-devel@lists.xenproject.org
Date: Thu, 16 Apr 2020 18:10:57 +0200
In-Reply-To: <8db96ff6-53e3-8c01-0737-5181ccc348ab@suse.com>
References: <20200409094137.13836-1-sergey.dyasli@citrix.com>
 <8db96ff6-53e3-8c01-0737-5181ccc348ab@suse.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-YN2g2caKjbfUCaXH3L5Q"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-YN2g2caKjbfUCaXH3L5Q
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2020-04-09 at 14:50 +0200, J=C3=BCrgen Gro=C3=9F wrote:
> On 09.04.20 11:41, Sergey Dyasli wrote:
> > In core-scheduling mode, Xen might crash when entering ACPI S5
> > state.
> > This happens in sched_slave() during is_idle_unit(next) check
> > because
> > next->vcpu_list is stale and points to an already freed memory.
> >=20
> > This situation happens shortly after scheduler_disable() is called
> > if
> > some CPU is still inside sched_slave() softirq. Current logic
> > simply
> > returns prev->next_task from sched_wait_rendezvous_in() which
> > causes
> > the described crash because next_task->vcpu_list has become
> > invalid.
> >=20
> > Fix the crash by returning NULL from sched_wait_rendezvous_in() in
> > the case when scheduler_disable() has been called.
> >=20
> > Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
>=20
> Reviewed-by: Juergen Gross <jgross@suse.com>
>=20
Reviewed-by: Dario Faggioli <dfaggioli@suse.com>

Thanks and Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-YN2g2caKjbfUCaXH3L5Q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6Yg5EACgkQFkJ4iaW4
c+5qmw/+JPlnlHvg0c5jxt4Y7BsJo8P1HLhfIFT6lviclMaIQR7rCuo2S/thnnN1
bsmoxB0nyI+REPq8ZEe+zOqhqO6dzg53+/Ue1Ybdy1592Z5ETzAOaDGUZU5395ty
rgFMdTVG0ePL3kyJcoHBxoG2IHVyRBQE9nIERQ1VUhwMPt8P4mlJ4He+P2mJNBDV
u6vVZcnO85qxaXuctvyUXTJlmd8vvixr0I93FcLjtnvH9GTxDba3597EZkTk/qug
FRiCIceaAdSZzzrG+dTyQMOqVLtHbRPoYeEc+5sdazNmItd5G4sdpQv7nfYjotF7
+OGSHX9k1prglZ11WFhhTur2pthnWMc7GNFPdyE8um2X3fMcIIPPBbsgSuxGlD82
ib6qt8aRnt6zaZkUrleGmJ7mjcEHywsTWV7cPORsJkUQpYCzMEGfJgwxxAJNMwY2
nBYAb5PhMNraK1r2yDFCOP0zAM0tuFMoJtnGLjFYnfXC200qDfOh5cFp0sQQT3kl
r7EPmFvsNaj0xaGyM3VCt+go93ig5iBzElUcw/vf/b/irctNE9adQ4Uc+2B0hfPR
AlCLSRjfysdZ9sE7BPj+pbH7wX689ybCbiDJoR04HRHtXDaHNsX8yJZ4xwXyCXlU
cy7fjrvKBIelpCSEExzajnBtIkhaDPM01uQsMcWWrEnYuqWQ1+Y=
=vc/P
-----END PGP SIGNATURE-----

--=-YN2g2caKjbfUCaXH3L5Q--



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 16:28:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 16:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP7NW-00023I-54; Thu, 16 Apr 2020 16:28:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=04wr=6A=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jP7NU-00023D-Se
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 16:28:36 +0000
X-Inumbo-ID: 51e768e8-7fff-11ea-8bc7-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 51e768e8-7fff-11ea-8bc7-12813bfff9fa;
 Thu, 16 Apr 2020 16:28:36 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A09CDABCF;
 Thu, 16 Apr 2020 16:28:34 +0000 (UTC)
Message-ID: <ca19a888e95d00ce664b9d777510e366547327cc.camel@suse.com>
Subject: Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job
From: Dario Faggioli <dfaggioli@suse.com>
To: Ian Jackson <ian.jackson@citrix.com>, Roger Pau Monne
 <roger.pau@citrix.com>
Date: Thu, 16 Apr 2020 18:28:33 +0200
In-Reply-To: <24215.1729.892903.300149@mariner.uk.xensource.com>
References: <20200415085246.7945-1-roger.pau@citrix.com>
 <20200415085246.7945-2-roger.pau@citrix.com>
 <24215.1729.892903.300149@mariner.uk.xensource.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-P8akR4LN9whvqAkNCJY3"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-P8akR4LN9whvqAkNCJY3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2020-04-15 at 14:06 +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH OSSTEST 2/2] make-flight: add a core
> scheduling job"):
> > Run a simple core scheduling tests on a host that has SMT support.
> > This is only enabled for Xen >=3D 4.13.
> ...
> > +  # Core-scheduling tests are x86 only
> > +  if [ x$test_coresched =3D xy -a $xenarch =3D amd64 ]; then
> > +    job_create_test test-$xenarch$kern-coresched-$dom0arch-xl \
> > +                    test-debian xl $xenarch $dom0arch
> > $debian_runvars \
> > +                    all_hostflags=3D$most_hostflags,smt \
> > +                    xen_boot_append=3D'sched-gran=3Dcore'
> > +
> > +  fi
>=20
> This seems fine as far as it goes, but all it does is check that
> things still work if sched-gran=3Dcore is passed.=20
>
Yep, and that's enough for enabling and starting using ore-scheduling.
So, doing like this, core-scheduling should get the same amount and
kind of testing that scheduling in general gets.

>  I'm not sure whether
> anything more sophisticated is needed, and in any case this is a step
> in the right direction, so:
>=20
Indeed.

One question, as my OSSTest-fu is a bit rusty... does this create
"sched-gran=3Dcore" tests for all the schedulers? Or just one of them for
th default scheduler?

Thanks and Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-P8akR4LN9whvqAkNCJY3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6Yh7EACgkQFkJ4iaW4
c+6ZVhAAlmHtoJuiTRf7r77pF/CPJ5qO8wCpgXGqa/k2K+utONe0Vy3Ow12yqKK6
ijUP1QagNoqiqh2plo3w/qf1TpiRfK/8gp19ZnfxdlLtQMfR4pl6IrkRxlrl7SHz
HdiaM8fSpvAieHMwAsYZELyTvXCs/xaLOBXGwrhYWnGSMH45QooasqS9BGno+C4R
iLtI0xYfhka+6UxmrSTtt6q3XtvGml34zp+t/HXH+ZobvFWpLwKamXljMTEx4HMB
3rG8VZVD8pYS4wBTzCCuNJMfGENjaNJTrSiw4U1dAEP1E6rpWuyTMXP3NhXPIDF8
3lIt9iuojw6rC2ZVu0Y4/kpme/bIxGu/PriFp1793ZqWRMaQ6+NiqcHle0EcZfND
+9XiKtBvrW6byVmvhkfjmmStgf7xTkEqB/NMHdD+XqntMOrIb/cQhoHE5xOoXL7D
z0VdGXVQYDK8X4S3i7O4SP5pM5U2SY57zFbvy3YFm11oqzUxfQHhyuu0kxxRwyVp
1/E3pRtcYn1b9emewk6qAb0R8P7N/6XsCLiFj6EUA2VZEVo3ee3beJMpU54NXDan
ndgaBaLtEkhMkwwoRPcmFTmueF2Jquu89IxDH6cuKnJpzTVh+ic9+nyKjO5lgVKc
3d0Ovjy9FImVMSSSNTZfdR/5kttaYDXVArrCcZqj+zavQ1gZsBs=
=ykJc
-----END PGP SIGNATURE-----

--=-P8akR4LN9whvqAkNCJY3--



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 16:36:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 16:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP7Uv-0002t3-1m; Thu, 16 Apr 2020 16:36:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8YfG=6A=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jP7Ut-0002sy-Il
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 16:36:15 +0000
X-Inumbo-ID: 630dac30-8000-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 630dac30-8000-11ea-83d8-bc764e2007e4;
 Thu, 16 Apr 2020 16:36:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587054974;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=IW4X/8elxpsv9rYspMp4ZxClWi5lZ3p/vTWGpAsRf4A=;
 b=b4zZhr2vKtCFOr3S6RBHjvO64tL1bADAiNUadRDMu4WVXMYfYlOg2myp
 JXnsVfhZrZpnmfukoRBZ4w3fAwwtGT/PVR1Ky4Np8nlpdkXm4fLpbsG8M
 AZw23k8ZNFrtd8oGxUtO3+0WLOknYNsXk8XSwwmgLqNsQ0AwncCaDq2YL Y=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: YRBBME4ZSTJ/s//42/YcNnsOYEFjv9MgE4xtapPebpTdsq6GyAwc/xVx3RHO7pG4+KG0C42gXL
 wZ6tYQj8CzwiKTqmSwX1aa18xhMDtyfqp2uYoTH+6YOlmFEW0f1Ol+imb3z7ecez2HkeVZLqJ2
 D/dfK2WDSqNP/YLple+UOtDY/KRZ47WVIi7dS4yzHubK+NF5oQe4WK/z41/NucFx1KJiHrGf2s
 /kGZiWiiqx3BsOhAsQtWan9h+CC+FLz2srhQKOGFbKvFxi39ztQm5V9Vjenb2m0OL70YT2koi5
 Vb0=
X-SBRS: 2.7
X-MesageID: 16196245
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="16196245"
Date: Thu, 16 Apr 2020 18:36:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Dario Faggioli <dfaggioli@suse.com>
Subject: Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job
Message-ID: <20200416163607.GO28601@Air-de-Roger>
References: <20200415085246.7945-1-roger.pau@citrix.com>
 <20200415085246.7945-2-roger.pau@citrix.com>
 <24215.1729.892903.300149@mariner.uk.xensource.com>
 <ca19a888e95d00ce664b9d777510e366547327cc.camel@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <ca19a888e95d00ce664b9d777510e366547327cc.camel@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 16, 2020 at 06:28:33PM +0200, Dario Faggioli wrote:
> On Wed, 2020-04-15 at 14:06 +0100, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH OSSTEST 2/2] make-flight: add a core
> > scheduling job"):
> > > Run a simple core scheduling tests on a host that has SMT support.
> > > This is only enabled for Xen >= 4.13.
> > ...
> > > +  # Core-scheduling tests are x86 only
> > > +  if [ x$test_coresched = xy -a $xenarch = amd64 ]; then
> > > +    job_create_test test-$xenarch$kern-coresched-$dom0arch-xl \
> > > +                    test-debian xl $xenarch $dom0arch
> > > $debian_runvars \
> > > +                    all_hostflags=$most_hostflags,smt \
> > > +                    xen_boot_append='sched-gran=core'
> > > +
> > > +  fi
> > 
> > This seems fine as far as it goes, but all it does is check that
> > things still work if sched-gran=core is passed. 
> >
> Yep, and that's enough for enabling and starting using ore-scheduling.
> So, doing like this, core-scheduling should get the same amount and
> kind of testing that scheduling in general gets.

Well, we run a lot more tests without 'sched-gran=core', but I don't
think it's feasible to duplicate the matrix to run all tests with and
without core-scheduling.

> >  I'm not sure whether
> > anything more sophisticated is needed, and in any case this is a step
> > in the right direction, so:
> > 
> Indeed.
> 
> One question, as my OSSTest-fu is a bit rusty... does this create
> "sched-gran=core" tests for all the schedulers? Or just one of them for
> th default scheduler?

Just for the default scheduler ATM, we can expand this if required.
The test also is very simple, as it just creates a Debian PV guest
and does some basic life cycle operations, it's exactly like the job
below but with 'sched-gran=core':

http://logs.test-lab.xenproject.org/osstest/logs/149667/test-amd64-amd64-xl/info.html

Roger.


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 16:44:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 16:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP7cL-0003jq-1d; Thu, 16 Apr 2020 16:43:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=04wr=6A=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jP7cK-0003jk-5p
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 16:43:56 +0000
X-Inumbo-ID: 74e059d5-8001-11ea-8bcd-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 74e059d5-8001-11ea-8bcd-12813bfff9fa;
 Thu, 16 Apr 2020 16:43:55 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7172FACA1;
 Thu, 16 Apr 2020 16:43:53 +0000 (UTC)
Message-ID: <d2577c4b4ff040c8f256d203e647619d9d4d6ebb.camel@suse.com>
Subject: Re: [PATCH] sched: print information about scheduler granularity
From: Dario Faggioli <dfaggioli@suse.com>
To: Sergey Dyasli <sergey.dyasli@citrix.com>, xen-devel@lists.xenproject.org
Date: Thu, 16 Apr 2020 18:43:52 +0200
In-Reply-To: <20200416083341.21122-1-sergey.dyasli@citrix.com>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-SnfX3jvJDGmwQRqGTV5c"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-SnfX3jvJDGmwQRqGTV5c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
> Currently it might be not obvious which scheduling mode is being used
> by the scheduler. Alleviate this by printing additional information
> about the selected granularity.
>
I like the idea. However, I don't like how verbose and long that line
becomes.

>  Messages now look like these:
>=20
> 1. boot
> (XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler
> (credit) in core-scheduling mode
>=20
> 2. xl debug-keys r
> (XEN) [   45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-
> way core-scheduling mode
>=20
What about adding an entry, just below these ones. Something looking
like, for instance (both at boot and in the debug-key dump):

"Scheduling granularity: cpu"

(or "core", or "socket")

Also

> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -38,7 +38,35 @@ static cpumask_t cpupool_locked_cpus;
>  static DEFINE_SPINLOCK(cpupool_lock);
> =20
>  static enum sched_gran __read_mostly opt_sched_granularity =3D
> SCHED_GRAN_cpu;
> -static unsigned int __read_mostly sched_granularity =3D 1;
> +static unsigned int __read_mostly sched_granularity;
> +
> +char *sched_gran_str(char *str, size_t size)
> +{
> +    char *mode =3D "";
> +
> +    switch ( opt_sched_granularity )
> +    {
> +    case SCHED_GRAN_cpu:
> +        mode =3D "cpu";
> +        break;
> +    case SCHED_GRAN_core:
> +        mode =3D "core";
> +        break;
> +    case SCHED_GRAN_socket:
> +        mode =3D "socket";
> +        break;
> +    default:
> +        ASSERT_UNREACHABLE();
> +        break;
> +    }
> +
> +    if ( sched_granularity )
> +        snprintf(str, size, "%u-way %s", sched_granularity, mode);
>
I'm not sure about using the value of the enum like this.

E.g., in a system with 4 threads per core, enabling core scheduling
granularity would mean having 4 vCPUs in the scheduling units. But this
will still print "2-way core-scheduling", which I think would sound
confusing.

So I'd just go with "cpu", "core" and "socket" strings.

Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-SnfX3jvJDGmwQRqGTV5c
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6Yi0gACgkQFkJ4iaW4
c+7+Sg//UY/Widq8Kp3d0N6+YzrY8WXHDC6d5F/0VeLpArqweCv7Xfg7C4/zE0Rg
JZF75OOpOs6Lna6/5xICDJcM9kjjpFnIlToJlJ53jKSJ0Ghhqlo2LsygFkcPNWn9
F6rzpOM+1vAApCrdGqPv0mrx4ZGzXphgBIWtsdgVeRCjQCrtBojfp6/rKIodQCwa
0mzLUlUjmqJvIYKS8qUxaAe6dCPMKqCxz999waT+cM44FeAdIYgA7Fnsk2bZOQb0
twfoKCzW+ETTXUcMHWlvJX4m3PWAjDy+pffG5aazLCz+PPZnDpqSr8z8bsrqZdIy
3Tk6bqNd4/ka9522U9ke+uO8ZPbefo0YzDu76bg8RW4jIvJ1mucAJfza8FVq/63l
O1YKxmIMut9MjMzZ3rfJXLWVzG6TYnoBV+xDX0hxG/Y6vD0Xs5fxgpeK/UEm4gvX
ZTPKbhOih8Wp0xebKEvoCo7tyyHAqkZwdGjJ4NdSX5cTn16/Fd5KgP+LBFPViiuJ
aVZxH4h/VzIjI/449pwLR8tGCW+SJft6R6lX4Iyn6yf19r142B3VOTpQSy5glH8B
aIjESCaCP68I6lPjk88MQmBOZyKebXT5+q2iq6o/KQQf0svg3Saug8rZKqN6zlmt
3MSNA+bZlJCpbDHW3sGetMhtrwwPgFbcH7GBSDX7oxvORAI2h+Y=
=iycN
-----END PGP SIGNATURE-----

--=-SnfX3jvJDGmwQRqGTV5c--



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 16:47:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 16:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP7fR-0003sC-IG; Thu, 16 Apr 2020 16:47:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=04wr=6A=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jP7fQ-0003s7-PB
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 16:47:08 +0000
X-Inumbo-ID: e8aaec26-8001-11ea-8bce-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e8aaec26-8001-11ea-8bce-12813bfff9fa;
 Thu, 16 Apr 2020 16:47:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7EC97AAC7;
 Thu, 16 Apr 2020 16:47:06 +0000 (UTC)
Message-ID: <4716e235b5a5723c7cf55c3ef2d6295bcb27d8e0.camel@suse.com>
Subject: Re: [PATCH] sched: print information about scheduler granularity
From: Dario Faggioli <dfaggioli@suse.com>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, Sergey Dyasli
 <sergey.dyasli@citrix.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
Date: Thu, 16 Apr 2020 18:47:05 +0200
In-Reply-To: <bd38c4da-b982-0d13-bdbd-ab363dae68e0@suse.com>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <996ed66e-3782-5187-a804-9291741a2241@suse.com>
 <1587028832608.72974@citrix.com>
 <bd38c4da-b982-0d13-bdbd-ab363dae68e0@suse.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-CKOCHYlTqc2Ci+0DTwlt"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-CKOCHYlTqc2Ci+0DTwlt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2020-04-16 at 11:25 +0200, J=C3=BCrgen Gro=C3=9F wrote:
> On 16.04.20 11:20, Sergey Dyasli wrote:
> > On 16/04/2020 09:57, J=C3=BCrgen Gro=C3=9F wrote:
> > >=20
> > > The xen commandline ins part of the boot messages and is
> > > contained
> > > in the "xl info" output.
> >=20
> > It's true that you can see "sched-gran=3Dcore" in "xl info" output.
> > But that's
> > just the switch - not the end result. A user might want to verify
> > that he did
> > everything correctly and core-scheduling mode has indeed been
> > enabled.
>=20
> I'm not opposed to your patch, but as soon as we have per-cpupool
> granularity it should be reverted again.
>=20
Why reverted? Each cpupool dumps its own scheduling information. With
per-pool granularity, we'll see something like

cpupool: Pool-A
Scheduler: SMP Credit Scheduler (credit)
Scheduling granularity: cpu
...
cpupool: Pool-B
Scheduler: SMP Credit Scheduler (credit)
Scheduling granularity: core

etc.

Or am I missing something?

Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-CKOCHYlTqc2Ci+0DTwlt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6YjAoACgkQFkJ4iaW4
c+6R2Q/+LwMlSNIdE1d5dFF1Jy2y+5hLE0Owh/RXFj3EISxS04r3nyUwwFrrHDel
RONmQ8z0FnPQHpV+SOPoE0+yM5An0lKcA7bo5IDgKcycZuWWuczwuMZpKW4eBZYl
clKphTqYDRzr4nYCY1L8z4YlpmJE9DUosOTl/+aKgYospuYqqaPnbL23wCNMk9W6
UM/NzIrJkpzUyTzTczd2QOqT+Rgm354KkFdgZGf+2gKW+jbfdjkbnzi+74vK5AX/
q1fEKQTy7cKS1e4AWECLFfWwd7TnD05zAIsPooxU81cQBq0WZx1alDkO4TsPm/3L
XDq5mGmW6s+J4d4fb50wqHZi/0D9bAURyRd/HKgLJORDCjX+4bYUw3pQYwZNTGIU
X77DO+m5Q+sEy/ULFpOmEMxV/5NlMRXHcbSCve0jKEFPz60OJ7ACWUmUZYTFyII3
aeEgC8yvEJWsh3N4xAyJFOosa2Mt2Ys4Z3LQhKmGcOrUsKBjFsESXPvOWnzQ29Kk
TX/GRaQoN1OKm7+N3rBbtap3OQqqZb0KzTlgTiEBPQLEED2yK6EK6xILnU+WQwYe
6z18Dm1t3BnRRAuYgowIzYsV/UzmnbFz61tKj+IAN421X5eA85DRbBsk13CEJ8tT
0tnLUZykz1b4SuRz3ep5oskjUM5kv4BEa8FfXVshmOTe2d9d5do=
=LwrW
-----END PGP SIGNATURE-----

--=-CKOCHYlTqc2Ci+0DTwlt--



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 16:56:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 16:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP7nw-0004j7-GI; Thu, 16 Apr 2020 16:55:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=04wr=6A=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jP7nu-0004j2-Ov
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 16:55:54 +0000
X-Inumbo-ID: 220f0776-8003-11ea-8bd1-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 220f0776-8003-11ea-8bd1-12813bfff9fa;
 Thu, 16 Apr 2020 16:55:53 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4AAE5ACA1;
 Thu, 16 Apr 2020 16:55:52 +0000 (UTC)
Message-ID: <96263bbd41717d68bb35f14163973267a29ef0e4.camel@suse.com>
Subject: Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job
From: Dario Faggioli <dfaggioli@suse.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Date: Thu, 16 Apr 2020 18:55:51 +0200
In-Reply-To: <20200416163607.GO28601@Air-de-Roger>
References: <20200415085246.7945-1-roger.pau@citrix.com>
 <20200415085246.7945-2-roger.pau@citrix.com>
 <24215.1729.892903.300149@mariner.uk.xensource.com>
 <ca19a888e95d00ce664b9d777510e366547327cc.camel@suse.com>
 <20200416163607.GO28601@Air-de-Roger>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-2Aw/QhzsplwSlf9tzdzL"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-2Aw/QhzsplwSlf9tzdzL
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2020-04-16 at 18:36 +0200, Roger Pau Monn=C3=A9 wrote:
> On Thu, Apr 16, 2020 at 06:28:33PM +0200, Dario Faggioli wrote:
> > On Wed, 2020-04-15 at 14:06 +0100, Ian Jackson wrote:
> > >=20
> > > This seems fine as far as it goes, but all it does is check that
> > > things still work if sched-gran=3Dcore is passed.=20
> > >=20
> > Yep, and that's enough for enabling and starting using ore-
> > scheduling.
> > So, doing like this, core-scheduling should get the same amount and
> > kind of testing that scheduling in general gets.
>=20
> Well, we run a lot more tests without 'sched-gran=3Dcore', but I don't
> think it's feasible to duplicate the matrix to run all tests with and
> without core-scheduling.
>=20
Sure, but again, that's the kind of scheduling testing that we do.
E.g., right now that Credit2 is the default scheduler, we still test
the other schedulers, exactly with "just" a job like this (AFAICR, at
least).

It indeed would be good to have something more specific, not only for
core-scheduling, but for scheduling in general. But it's not there
right now... That was the point. :-)

Of course the default setup (which, currently, has "sched-gran=3Dcpu") is
stressed much more, because all the other jobs also use it, but indeed
it does not appear sensible to replicate the matrix for each job that
we have with a non-default configuration.

> > One question, as my OSSTest-fu is a bit rusty... does this create
> > "sched-gran=3Dcore" tests for all the schedulers? Or just one of them
> > for
> > th default scheduler?
>=20
> Just for the default scheduler ATM, we can expand this if required.
>
Ok, sure. Maybe it would make sense to add just another one for Credit,
sooner rather than later, as I guess there may be people wanting to
continue use Credit, but they may want to try it with core-scheduling.

Of course, this can be done on top of this patch... I was just thinking
out loud here. :-)

Thanks and Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-2Aw/QhzsplwSlf9tzdzL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6YjhcACgkQFkJ4iaW4
c+7V1w/+PfHN8AlcJCzAjIecPV1EQCW+m2HuVinIwvWq3/LRlHWfHpteQln2zj/b
C2lASOg0+kzr1KFKwyt89VDsqz8P/hTxPTGVpicW10N74s5ZAUrSsXKpEGnm6I4s
JTJE2tbNseTZZetJMgGANgjjXMK4P6NCf6lYK5zTb6n28bEFQI/nFAtTT5kKJv9y
IdWCvTmHbdiiHjXrXJsf1KaA6Sfa/Pt4AVMdeVTs+vrJ8sg9sB5tupzr3bNfZgci
dsAURzV8LShwKWOzI5LuYnAQ3gSts4V9yGjbha69Px/XZ7P1Q12pT48VxB6gPAnB
oDj6VBLbxWUKDfbF4bH4cL+HRrx+L3ac8nHbBPc8XKlh17rQonTDtEZYmE0jdPbq
ODjK5j3JAYTVWN2Osg7LrwtsXivGbeQcaOhOm7BOZs3eOTD9Q6L7pvoClku/7Hzr
Te4boaXQBGDNbkc46yNoYcRkWuAn0GLWlOW95dj5p3GirMZ5SMNEjzPad5miShXy
Zlv4H5i9sOzyKU+61RLbdTtMkx3DVeW/PTq8DtHYSYd2y5RoZ1jK9knGi4rslwn9
Z0mnrDdB5I7TOJ9LUIh53t23kVWWot5eB8L1dPXrZewScj6H2btPo9wjGzf+qcFw
6ucRASJeXMYohKmQdvPzLAZOiylYOQNf+U0yOKuwIwvFKGCctFo=
=OAbZ
-----END PGP SIGNATURE-----

--=-2Aw/QhzsplwSlf9tzdzL--



From xen-devel-bounces@lists.xenproject.org Thu Apr 16 16:58:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 16:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP7qY-0004rj-V4; Thu, 16 Apr 2020 16:58:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=7gJ3=6A=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jP7qX-0004rd-D2
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 16:58:37 +0000
X-Inumbo-ID: 81e98fc2-8003-11ea-8bd1-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 81e98fc2-8003-11ea-8bd1-12813bfff9fa;
 Thu, 16 Apr 2020 16:58:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587056314;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=+A7o7zIGoVU/FcjMkxo6qjyBi0s/hnC1sRn3hc0hJNk=;
 b=XfU6Um+aABPDD4m47CK3f2uzm3sb3l43FPWdR4N2gjrnNku/NUX2WWuK
 wwGjYsQlmL/VQjYp+R7uz4S0oirR8vNhT2HUrb4WrastaBmAEdECKguXi
 mHrUA+2h7zvZrG+JE/L5Eprwjdhu3vzyBGIsl3H45vne+orPTVnvLKuC4 0=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: shuKxPwSXk6ubQUn927O1TLTBkZC0MGHX9m4jAArEGQG7C2+DYGn4QmMJK3qQpgszcgCQ9rYz1
 y9jBdboYm2J/XoOvpmaxpSfGpD0t91i3GhiWHMnnKYMS2wMnNP36cRF+cUZvBqIhwnPI6WRpZg
 6ls99KBVDB0ZgETaT5QlV/xZ5soeDKyNonFBSDEF5T3nEqSR7pydWN5l5tdU0M8PBqruY2ZLx4
 /4y2L8o3n8d+IvloqWo95KuTnFJ0XYK6tQ0ajsLQEtOEhmiMe1bMLJruYgbbmCphUCGEX9XO6y
 UTs=
X-SBRS: 2.7
X-MesageID: 15810236
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="15810236"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24216.36520.20579.92616@mariner.uk.xensource.com>
Date: Thu, 16 Apr 2020 17:58:16 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job
In-Reply-To: <20200416163607.GO28601@Air-de-Roger>
References: <20200415085246.7945-1-roger.pau@citrix.com>
 <20200415085246.7945-2-roger.pau@citrix.com>
 <24215.1729.892903.300149@mariner.uk.xensource.com>
 <ca19a888e95d00ce664b9d777510e366547327cc.camel@suse.com>
 <20200416163607.GO28601@Air-de-Roger>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job"):
> On Thu, Apr 16, 2020 at 06:28:33PM +0200, Dario Faggioli wrote:
> > Yep, and that's enough for enabling and starting using ore-scheduling.
> > So, doing like this, core-scheduling should get the same amount and
> > kind of testing that scheduling in general gets.
> 
> Well, we run a lot more tests without 'sched-gran=core', but I don't
> think it's feasible to duplicate the matrix to run all tests with and
> without core-scheduling.

Yes, I agree with Roger.

> > One question, as my OSSTest-fu is a bit rusty... does this create
> > "sched-gran=core" tests for all the schedulers? Or just one of them for
> > th default scheduler?
> 
> Just for the default scheduler ATM, we can expand this if required.
> The test also is very simple, as it just creates a Debian PV guest
> and does some basic life cycle operations, it's exactly like the job
> below but with 'sched-gran=core':
> 
> http://logs.test-lab.xenproject.org/osstest/logs/149667/test-amd64-amd64-xl/info.html

Right.

Thanks,
Ian.


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 17:10:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 17:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jP82C-0006Qa-56; Thu, 16 Apr 2020 17:10:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=7gJ3=6A=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jP82B-0006QV-9m
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 17:10:39 +0000
X-Inumbo-ID: 315c653c-8005-11ea-83d8-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 315c653c-8005-11ea-83d8-bc764e2007e4;
 Thu, 16 Apr 2020 17:10:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587057038;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=qfkSq7URKpvXjF7lnJTFYslcRpwMyj8W2lwX2JJDTYQ=;
 b=gPFevS3bLIoEU5EHfyYXnEtcpCDk9pxbSru9O2GSFwNfp0KwUAojosKZ
 vKpbqDEoAmysJpo8qqcTSDP/dfIxx9whw8B4DGR+ct5clnLUzmNrA1Wvw
 7olgE5g0Eq/HSvUXsV7qWDp0VVVf+Q6j+v6TIKlB2yOErSPcI0JO7myG/ Y=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: NpvzHCUBFzCkdF2r9vzy0co5kUkHtjY9NtEeobzKYtXkfKVg+HU46L2uDkCHqvl/kCXHEc4ORS
 uPA4eQfCXmLEIGrNTR8XWAZzcP9WyQbroK0CsApgO/vVVOb9oA/qK/zmTpasllvwJ0bQ+etQp3
 0VIdrHSJGPLXoYGNrWJ+Ye+GK0MZF0DrSNsXUde4bL6wIpcQsAd80pfeT9qvL8CI5vCtTUDIGd
 WGS8cWSnnxj58C4LE0SPdkn5MTKa/ayUw/e8vLyodj3bdJLGQd98vK2feNfZJ4+0vo7z/9CZA/
 2hQ=
X-SBRS: 2.7
X-MesageID: 16472943
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,391,1580792400"; d="scan'208";a="16472943"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24216.37252.294936.717519@mariner.uk.xensource.com>
Date: Thu, 16 Apr 2020 18:10:28 +0100
To: Dario Faggioli <dfaggioli@suse.com>
Subject: Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job
In-Reply-To: <96263bbd41717d68bb35f14163973267a29ef0e4.camel@suse.com>
References: <20200415085246.7945-1-roger.pau@citrix.com>
 <20200415085246.7945-2-roger.pau@citrix.com>
 <24215.1729.892903.300149@mariner.uk.xensource.com>
 <ca19a888e95d00ce664b9d777510e366547327cc.camel@suse.com>
 <20200416163607.GO28601@Air-de-Roger>
 <96263bbd41717d68bb35f14163973267a29ef0e4.camel@suse.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Dario Faggioli writes ("Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job"):
> Ok, sure. Maybe it would make sense to add just another one for Credit,
> sooner rather than later, as I guess there may be people wanting to
> continue use Credit, but they may want to try it with core-scheduling.

Maybe in return we could delete the rtds test which has been marked
nonblocking forever and which no-one seems to be fixing ? :-)

Patches welcome...

Ian.


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 19:57:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 19:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPAdN-0002Ue-OV; Thu, 16 Apr 2020 19:57:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPAdM-0002UZ-DO
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 19:57:12 +0000
X-Inumbo-ID: 7562bf62-801c-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7562bf62-801c-11ea-83d8-bc764e2007e4;
 Thu, 16 Apr 2020 19:57:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=qBUWFVQB+W/Dmv+mxapUcSQDM/tKi3QLCcF6F9mbjE8=; b=D3Obh84wU2HMM5zpR03XsruwV
 mrLbnN03UjB8NCTNZZ5GRHcM3nB4oSuNfhawlO6KTWDtPXPThNcgVSRtl91DbQGhJpw93+Vowj66V
 bArUD+FH6rhKREtI3weMaExDClcmwAUnG/SUG5WfQoaXbySlRqLn43IEUibKOM9/JfsCQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPAdK-0005Pa-AE; Thu, 16 Apr 2020 19:57:10 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPAdK-0003u9-01; Thu, 16 Apr 2020 19:57:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPAdJ-0002oA-Vc; Thu, 16 Apr 2020 19:57:09 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149678-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149678: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 linux-linus:test-arm64-arm64-xl-seattle:xen-boot:fail:heisenbug
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=8632e9b5645bbc2331d21d892b0d6961c1a08429
X-Osstest-Versions-That: linux=8f3d9f354286745c751374f5f1fcafee6b3f3136
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 19:57:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds   16 guest-localmigrate fail in 149659 pass in 149678
 test-amd64-amd64-examine    4 memdisk-try-append fail in 149659 pass in 149678
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 149659 pass in 149678
 test-arm64-arm64-xl-seattle   7 xen-boot                   fail pass in 149659

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

version targeted for testing:
 linux                8632e9b5645bbc2331d21d892b0d6961c1a08429
baseline version:
 linux                8f3d9f354286745c751374f5f1fcafee6b3f3136

Last test of basis   149632  2020-04-13 01:08:56 Z    3 days
Testing same since   149659  2020-04-14 19:09:17 Z    2 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  David Howells <dhowells@redhat.com>
  David Sterba <dsterba@suse.com>
  Eugene Syromiatnikov <esyr@redhat.com>
  Filipe Manana <fdmanana@suse.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Gustavo A. R. Silva <gustavo@embeddedor.com>
  Johannes Hirte <johannes.hirte@datenkhaos.de>
  Josef Bacik <josef@toxicpanda.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Olaf Hering <olaf@aepfle.de>
  Tianyu Lan <Tianyu.Lan@microsoft.com>
  Wei Liu <wei.liu@kernel.org>
  YueHaibing <yuehaibing@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   8f3d9f354286..8632e9b5645b  8632e9b5645bbc2331d21d892b0d6961c1a08429 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 20:05:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 20:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPAl6-0003Ud-1C; Thu, 16 Apr 2020 20:05:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPAl4-0003U6-Hp
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 20:05:10 +0000
X-Inumbo-ID: 92b45d86-801d-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 92b45d86-801d-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 20:05:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=JTIXb1bP4DyZ4SPd/0qyy+r3YXosVMkR1L4Fh2XrZug=; b=danGmBVv4ZI3YZnvu/h3qIDV2
 aGNkXWT6X3HxC+X2Y2tsO68wF0wzMmhehIRqZr8DUpjFZsRSfETWf5zy57T2BheMTp1SKM8uKVXkk
 sk75eBXGUiqIJPBUymLH/dIETGjRSCrlM5oQOnetEJnpov6a7pt6oxtYRRgd1dgAN9jmc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPAl3-0005e3-0h; Thu, 16 Apr 2020 20:05:09 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPAl2-00045m-Kc; Thu, 16 Apr 2020 20:05:08 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPAl2-0005Ej-K5; Thu, 16 Apr 2020 20:05:08 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149684-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149684: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=a158eb5c8e18336d1dd39148a5d5c6b0bd3f26c1
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 20:05:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

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

version targeted for testing:
 libvirt              a158eb5c8e18336d1dd39148a5d5c6b0bd3f26c1
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   90 days
Failing since        146211  2020-01-18 04:18:52 Z   89 days   86 attempts
Testing same since   149684  2020-04-16 05:00:04 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 14835 lines long.)


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 21:14:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 21:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPBqA-0000fy-FY; Thu, 16 Apr 2020 21:14:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DlbZ=6A=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jPBq9-0000ft-4h
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 21:14:29 +0000
X-Inumbo-ID: 418bdeca-8027-11ea-83d8-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 418bdeca-8027-11ea-83d8-bc764e2007e4;
 Thu, 16 Apr 2020 21:14:28 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 4C094221F4;
 Thu, 16 Apr 2020 21:14:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587071667;
 bh=55ywWyXgqRR8JtB9q8XT/HTHFJsxaFbLSUz46VW/a6w=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=k5zUD1LenWWSk5G1VKmWbn2m7ZeKFj4CvOfpg/4L+sWgJpFZncOCDlOrlGOoXz5ZK
 +wdl6GTTwdh0BqtVk2nbMVSAjptK6DDDFyfo1YRMv+PTq+gjLaxfrOmU658EXdwhOO
 qq9pKBQxX8HnZXfYjLgoHjUJ31u1AjNQ7xVe6Lqk=
Date: Thu, 16 Apr 2020 14:14:20 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
In-Reply-To: <454b13b1-2901-d864-6fc8-bc4f338a14d6@suse.com>
Message-ID: <alpine.DEB.2.21.2004161252180.8316@sstabellini-ThinkPad-T480s>
References: <20200410164942.9747-1-sstabellini@kernel.org>
 <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
 <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
 <707a1448-be1d-0aa8-6b11-a33eb247304f@suse.com>
 <04881FC6-A816-44AB-8F25-54E5A265707E@citrix.com>
 <49c732e6-d30d-0892-0bd7-65c082da0429@xen.org>
 <10D98CF7-E38E-44C3-AF24-C93088F6682D@citrix.com>
 <454b13b1-2901-d864-6fc8-bc4f338a14d6@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-957468000-1587067177=:8316"
Content-ID: <alpine.DEB.2.21.2004161259490.8316@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Lars Kurth <lars.kurth@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-957468000-1587067177=:8316
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.21.2004161259491.8316@sstabellini-ThinkPad-T480s>

On Wed, 15 Apr 2020, Jan Beulich wrote:
> On 15.04.2020 11:56, George Dunlap wrote:
> > 
> > 
> >> On Apr 15, 2020, at 10:49 AM, Julien Grall <julien@xen.org> wrote:
> >>
> >>
> >>
> >> On 15/04/2020 10:43, George Dunlap wrote:
> >>>> On Apr 15, 2020, at 7:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>
> >>>> On 14.04.2020 18:54, Stefano Stabellini wrote:
> >>>>> On Tue, 14 Apr 2020, Jan Beulich wrote:
> >>>>>> On 10.04.2020 18:49, Stefano Stabellini wrote:
> >>>>>
> >>> [snip]
> >>>>>>> +    Backport: all
> >>>>>>> +
> >>>>>>> +It marks a commit for being a candidate for backports to all relevant
> >>>>>>> +trees.
> >>>>>>
> >>>>>> I'm unconvinced of the utility of this form - what "all" resolves to
> >>>>>> changes over time. There's almost always a first version where a
> >>>>>> particular issue was introduced. If we want this to be generally
> >>>>>> useful, imo we shouldn't limit the scope of the tag to the upstream
> >>>>>> maintained stable trees.
> >>>>>
> >>>>> The reason why I suggested also to have a "wildcard" version of this
> >>>>> tag, is that the person adding the tag (could be the contributor trying
> >>>>> to be helpful) might not know exactly to which stable trees the patch
> >>>>> should be backported to.
> >>>>>
> >>>>> Writing this sentence, I realize that I really meant "any" rather than
> >>>>> "all". Would you prefer if I used "any"? Or we could even suggest to leave
> >>>>> it black like this:
> >>>>>
> >>>>>  Backport:
> >>>>>
> >>>>> But it looks a bit weird.
> >>>>
> >>>> Indeed. Instead of "all" or "any", how about "yes", "unspecified", or
> >>>> "unknown"? Nevertheless, I still think people asking for a backport
> >>>> should be nudged towards determining the applicable range; them not
> >>>> doing so effectively pushes the burden to the general maintainers or
> >>>> the stable tree ones, both of which scales less well. Omitting the
> >>>> tag if they don't want to invest the time would to me then seem to
> >>>> be the cleanest alternative. Albeit I'm sure views here will vary.
> >>> FWIW asking people adding the tag to do the work of figuring out which versions to backport to makes sense to me.
> >>
> >> If you ask the contributor to do the work then you need to give guidance on the "older" version you can specify in Backport.
> >>
> >> For instance, let say the bug was introduced in Xen 4.2. Are we allowing the user to specify Backport: 4.2+ or should it be 4.11+?
> >>
> >> I would favor the former as this helps for downstream user which haven't yet moved to the supported stable tree.
> > 
> > I agree that specifying the oldest revision possible would be helpful.
> > 
> > However, I don’t think finding the absolute oldest revision should be *required* — imagine a bug that was introduced between 3.2 and 3.3.  It’s also perfectly fine if you go all the way back to 4.2 and stop because you get bored, not because you found out that 4.1 didn’t need it.

I dropped the definition of "Backport: all", and adopted George's
suggested wording:

  The backport requester is expected to specify which currently supported
  releases need the backport; but encouraged to specify a release as far
  back as possible which applies.


> In which case I'd like there to be a (canonical?) way of expressing
> this, like in XSAs we say "at least back to" in such a case.

I couldn't think of anything better than:

  Backport: 4.9+ # maybe older

We probably don't need to codify something like that in this document.


As an alternative we could perhaps reuse the "Backport: all" idea in a
different light for this new purpose.

I expect that in these cases where we don't know the oldest affected
tree, all the currently maintained stable trees will have to get the
backport. So maybe we could use one of the following:

  Backport: all
  Backport: oldest
  Backport: oldest-unknown

To express that the fix needs to be backported to *all* the currently
maintained stable trees, but there might be also other older
unmaintained trees that could be affected; we don't know for sure how
far back it should go.
--8323329-957468000-1587067177=:8316--


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 21:24:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 21:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPC01-0001Xz-Hp; Thu, 16 Apr 2020 21:24:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=DlbZ=6A=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jPC00-0001Xu-Kv
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 21:24:40 +0000
X-Inumbo-ID: accce481-8028-11ea-8c11-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id accce481-8028-11ea-8c11-12813bfff9fa;
 Thu, 16 Apr 2020 21:24:39 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 5977322201;
 Thu, 16 Apr 2020 21:24:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587072278;
 bh=RRSObpGdrqNjfvIEEsG9Z/f7yPIRU00BfWL00R3oQI4=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=jI3mqniXkjRzCj5RdMnIQkietwemkVIBM4mQtulV72/U7JOWC8lpxOr4B+KyrKssC
 upzZmCbx89P2OYVS8pe6EyeWIgs9QcbA55HfYWaLbt86LykbuIQOQ7oQnzpPpWxQIa
 rDe0O27DWQeHq+pIexYRjp1VA2dURAAspGXaOq1Q=
Date: Thu, 16 Apr 2020 14:24:37 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jason Yan <yanaijie@huawei.com>
Subject: Re: [PATCH] arm/xen: make _xen_start_info static
In-Reply-To: <20200415084853.5808-1-yanaijie@huawei.com>
Message-ID: <alpine.DEB.2.21.2004161424090.8316@sstabellini-ThinkPad-T480s>
References: <20200415084853.5808-1-yanaijie@huawei.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, sstabellini@kernel.org, linux@armlinux.org.uk,
 linux-kernel@vger.kernel.org, Hulk Robot <hulkci@huawei.com>,
 xen-devel@lists.xenproject.org, linux-arm-kernel@lists.infradead.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 15 Apr 2020, Jason Yan wrote:
> Fix the following sparse warning:
> 
> arch/arm64/xen/../../arm/xen/enlighten.c:39:19: warning: symbol
> '_xen_start_info' was not declared. Should it be static?
> 
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

> ---
>  arch/arm/xen/enlighten.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index dd6804a64f1a..fd4e1ce1daf9 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -36,7 +36,7 @@
>  
>  #include <linux/mm.h>
>  
> -struct start_info _xen_start_info;
> +static struct start_info _xen_start_info;
>  struct start_info *xen_start_info = &_xen_start_info;
>  EXPORT_SYMBOL(xen_start_info);
>  
> -- 
> 2.21.1
> 


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 21:35:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 21:35:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPCA9-0002RW-Lv; Thu, 16 Apr 2020 21:35:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPCA8-0002RR-9i
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 21:35:08 +0000
X-Inumbo-ID: 23893e10-802a-11ea-8c16-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 23893e10-802a-11ea-8c16-12813bfff9fa;
 Thu, 16 Apr 2020 21:35:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=vsBlpnAMRnjWExLzZ+4H1EFgLlW+oUYoU7+aEs6UwbA=; b=ha0Qt8N2zVNf3CGmZByyy4eIb
 cL3w2AkOcvpm/U0ndEUnSQ9lkApAMfWtWY57GofZntJayJO43FEQd3VC0CrvXdUDfNgNQvVgQON17
 YOLLw+p/DMnH6PUKCAMj56YpXkGmYLaVtT4nmHQ+RkwSZgFsA0BFA3ofhNeMPk6/zaIXQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPCA5-0007Oi-Sm; Thu, 16 Apr 2020 21:35:05 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPCA5-0007w0-8L; Thu, 16 Apr 2020 21:35:05 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPCA5-0000tB-7Y; Thu, 16 Apr 2020 21:35:05 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149685-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149685: all pass - PUSHED
X-Osstest-Versions-This: ovmf=06033f5abad3815e8d80de22c97ba38a05017262
X-Osstest-Versions-That: ovmf=8c654bb3ec0b5232dec2b2b07234c5479eb14d62
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 21:35:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 06033f5abad3815e8d80de22c97ba38a05017262
baseline version:
 ovmf                 8c654bb3ec0b5232dec2b2b07234c5479eb14d62

Last test of basis   149665  2020-04-15 01:40:25 Z    1 days
Testing same since   149685  2020-04-16 05:35:47 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Shenglei Zhang <shenglei.zhang@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   8c654bb3ec..06033f5aba  06033f5abad3815e8d80de22c97ba38a05017262 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 16 21:57:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Apr 2020 21:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPCW1-00048t-IC; Thu, 16 Apr 2020 21:57:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=amLm=6A=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPCW0-00048o-Jk
 for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 21:57:44 +0000
X-Inumbo-ID: 4c2641d0-802d-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4c2641d0-802d-11ea-b58d-bc764e2007e4;
 Thu, 16 Apr 2020 21:57:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Iu0In11GBJv0dvjUwlYZp1EfdOHaIQoxqAQMzLZKy14=; b=gfFbejFEn1p1oXqLgV4btr1kt
 t7xF1+hk9ktF96ZUoxYN/wpYJHoiVORYE9OvZ77qPTzmnSbpbipV+f9iq3uzshza5Kf+qXLwZm6EK
 QMQVwDTvx/mUnP8tsdvf145IkCm3C2jXpuUFhDuLnR+IjzM4nlZTtSRB65pOaWOs0obEM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPCVy-0007ol-Gm; Thu, 16 Apr 2020 21:57:42 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPCVy-0000Kg-4l; Thu, 16 Apr 2020 21:57:42 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPCVy-0000FF-46; Thu, 16 Apr 2020 21:57:42 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149681-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149681: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=20038cd7a8412feeb49c01f6ede89e36c8995472
X-Osstest-Versions-That: qemuu=a457215ed2aaa9598bd4ebbc6745d2a494ba9990
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 16 Apr 2020 21:57:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu                20038cd7a8412feeb49c01f6ede89e36c8995472
baseline version:
 qemuu                a457215ed2aaa9598bd4ebbc6745d2a494ba9990

Last test of basis   149660  2020-04-14 19:36:24 Z    2 days
Testing same since   149681  2020-04-16 02:09:07 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alex Bennée <alex.bennee@linaro.org>
  Howard Spoelstra <hsp.cat7@gmail.com>
  Igor Mammedov <imammedo@redhat.com>
  James Le Cuirot <chewi@aura-online.co.uk>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Xu <peterx@redhat.com>
  Philippe Mathieu-Daudé <philmd@redhat.com>
  Stefano Garzarella <sgarzare@redhat.com>
  Volker Rümelin <vr_qemu@t-online.de>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   a457215ed2..20038cd7a8  20038cd7a8412feeb49c01f6ede89e36c8995472 -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 04:15:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 04:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPIPL-0004Hj-00; Fri, 17 Apr 2020 04:15:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPIPJ-0004Hc-34
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 04:15:13 +0000
X-Inumbo-ID: 0426e350-8062-11ea-8c5f-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0426e350-8062-11ea-8c5f-12813bfff9fa;
 Fri, 17 Apr 2020 04:15:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=iDgKe/Er5nSEzKh21USR8KwHmapZWPmdvCJMxo9jkIE=; b=1R38gcLHRiDltopS6+b0SEpVO
 0VFrnMQKn5ECOMngVLnRPt6rY+5Fn5FdH3ttBjsOA0/zKn9a3eG9pMEWJNaDD+8B9nE/QVjssFz1L
 vO/gaqm5FRl/cmZXbkIgN8pYjakP7IeOO41CQEZ6abl9EE5fsgkEQbnsb5iGcTiFOvQ4Q=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPIPB-0003h3-14; Fri, 17 Apr 2020 04:15:05 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPIPA-0004ZZ-Mi; Fri, 17 Apr 2020 04:15:04 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPIPA-00088I-LX; Fri, 17 Apr 2020 04:15:04 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149689-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149689: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=615bfe42c6d183a0e54a0525ef82b58580d01619
X-Osstest-Versions-That: xen=fcd06227f83643194f8018f8dd37adce57763a61
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 04:15:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     16 guest-localmigrate           fail  like 149667
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149667
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149667
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149667
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149667
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149667
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149667
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149667
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149667
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149667
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  615bfe42c6d183a0e54a0525ef82b58580d01619
baseline version:
 xen                  fcd06227f83643194f8018f8dd37adce57763a61

Last test of basis   149667  2020-04-15 07:26:21 Z    1 days
Testing same since   149689  2020-04-16 13:17:05 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Julien Grall <jgrall@amazon.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   fcd06227f8..615bfe42c6  615bfe42c6d183a0e54a0525ef82b58580d01619 -> master


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 06:52:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 06:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPKrC-0000YK-Ry; Fri, 17 Apr 2020 06:52:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPKrB-0000YB-DD
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 06:52:09 +0000
X-Inumbo-ID: f3944602-8077-11ea-8c7d-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f3944602-8077-11ea-8c7d-12813bfff9fa;
 Fri, 17 Apr 2020 06:52:07 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 27229AAC7;
 Fri, 17 Apr 2020 06:52:05 +0000 (UTC)
Subject: Re: [PATCH v2] Introduce a description of a new optional tag for
 Backports
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200410164942.9747-1-sstabellini@kernel.org>
 <50c8b3be-eadf-dd39-3ce0-05658faa3a4a@suse.com>
 <alpine.DEB.2.21.2004140953450.4953@sstabellini-ThinkPad-T480s>
 <707a1448-be1d-0aa8-6b11-a33eb247304f@suse.com>
 <04881FC6-A816-44AB-8F25-54E5A265707E@citrix.com>
 <49c732e6-d30d-0892-0bd7-65c082da0429@xen.org>
 <10D98CF7-E38E-44C3-AF24-C93088F6682D@citrix.com>
 <454b13b1-2901-d864-6fc8-bc4f338a14d6@suse.com>
 <alpine.DEB.2.21.2004161252180.8316@sstabellini-ThinkPad-T480s>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <695f394c-4708-19e3-531c-91e983ac6010@suse.com>
Date: Fri, 17 Apr 2020 08:51:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004161252180.8316@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Lars Kurth <lars.kurth@citrix.com>, Julien Grall <julien@xen.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.2020 23:14, Stefano Stabellini wrote:
> On Wed, 15 Apr 2020, Jan Beulich wrote:
>> On 15.04.2020 11:56, George Dunlap wrote:
>>>
>>>
>>>> On Apr 15, 2020, at 10:49 AM, Julien Grall <julien@xen.org> wrote:
>>>>
>>>>
>>>>
>>>> On 15/04/2020 10:43, George Dunlap wrote:
>>>>>> On Apr 15, 2020, at 7:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>
>>>>>> On 14.04.2020 18:54, Stefano Stabellini wrote:
>>>>>>> On Tue, 14 Apr 2020, Jan Beulich wrote:
>>>>>>>> On 10.04.2020 18:49, Stefano Stabellini wrote:
>>>>>>>
>>>>> [snip]
>>>>>>>>> +    Backport: all
>>>>>>>>> +
>>>>>>>>> +It marks a commit for being a candidate for backports to all relevant
>>>>>>>>> +trees.
>>>>>>>>
>>>>>>>> I'm unconvinced of the utility of this form - what "all" resolves to
>>>>>>>> changes over time. There's almost always a first version where a
>>>>>>>> particular issue was introduced. If we want this to be generally
>>>>>>>> useful, imo we shouldn't limit the scope of the tag to the upstream
>>>>>>>> maintained stable trees.
>>>>>>>
>>>>>>> The reason why I suggested also to have a "wildcard" version of this
>>>>>>> tag, is that the person adding the tag (could be the contributor trying
>>>>>>> to be helpful) might not know exactly to which stable trees the patch
>>>>>>> should be backported to.
>>>>>>>
>>>>>>> Writing this sentence, I realize that I really meant "any" rather than
>>>>>>> "all". Would you prefer if I used "any"? Or we could even suggest to leave
>>>>>>> it black like this:
>>>>>>>
>>>>>>>  Backport:
>>>>>>>
>>>>>>> But it looks a bit weird.
>>>>>>
>>>>>> Indeed. Instead of "all" or "any", how about "yes", "unspecified", or
>>>>>> "unknown"? Nevertheless, I still think people asking for a backport
>>>>>> should be nudged towards determining the applicable range; them not
>>>>>> doing so effectively pushes the burden to the general maintainers or
>>>>>> the stable tree ones, both of which scales less well. Omitting the
>>>>>> tag if they don't want to invest the time would to me then seem to
>>>>>> be the cleanest alternative. Albeit I'm sure views here will vary.
>>>>> FWIW asking people adding the tag to do the work of figuring out which versions to backport to makes sense to me.
>>>>
>>>> If you ask the contributor to do the work then you need to give guidance on the "older" version you can specify in Backport.
>>>>
>>>> For instance, let say the bug was introduced in Xen 4.2. Are we allowing the user to specify Backport: 4.2+ or should it be 4.11+?
>>>>
>>>> I would favor the former as this helps for downstream user which haven't yet moved to the supported stable tree.
>>>
>>> I agree that specifying the oldest revision possible would be helpful.
>>>
>>> However, I don’t think finding the absolute oldest revision should be *required* — imagine a bug that was introduced between 3.2 and 3.3.  It’s also perfectly fine if you go all the way back to 4.2 and stop because you get bored, not because you found out that 4.1 didn’t need it.
> 
> I dropped the definition of "Backport: all", and adopted George's
> suggested wording:
> 
>   The backport requester is expected to specify which currently supported
>   releases need the backport; but encouraged to specify a release as far
>   back as possible which applies.
> 
> 
>> In which case I'd like there to be a (canonical?) way of expressing
>> this, like in XSAs we say "at least back to" in such a case.
> 
> I couldn't think of anything better than:
> 
>   Backport: 4.9+ # maybe older
> 
> We probably don't need to codify something like that in this document.

The suggestion looks fine to me, and people using slightly varying
wording wouldn't be a problem either.

> As an alternative we could perhaps reuse the "Backport: all" idea in a
> different light for this new purpose.
> 
> I expect that in these cases where we don't know the oldest affected
> tree, all the currently maintained stable trees will have to get the
> backport. So maybe we could use one of the following:
> 
>   Backport: all
>   Backport: oldest
>   Backport: oldest-unknown
> 
> To express that the fix needs to be backported to *all* the currently
> maintained stable trees, but there might be also other older
> unmaintained trees that could be affected; we don't know for sure how
> far back it should go.

My prior objection to "all" remains - it changes over time what
"currently means", rendering the tag stale quite quickly. I think
that without even providing a suggested means to create such a tag
without an explicit version specified we underline the need to
figure out a baseline from where to apply the backport.

One more thing comes to mind that may want mentioning here: If
people request a backport, I think this should take as an
implication their willingness to actually be involved in doing
the actual backporting work. Typically it's pretty simple, but
every now and then quite a bit of effort is needed. It would be
nice if the stable tree maintainers could push over some of this
burden without the requester being caught by surprise.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:03:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPL1y-0001XM-Gk; Fri, 17 Apr 2020 07:03:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPL1x-0001XH-8p
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 07:03:17 +0000
X-Inumbo-ID: 81bdd2bc-8079-11ea-8c80-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 81bdd2bc-8079-11ea-8c80-12813bfff9fa;
 Fri, 17 Apr 2020 07:03:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=RqSEwesonuIDtMcXJkXxg/yfVfZ+8iasmrVS/c6JjPs=; b=yBMq365x5ReItSLtYvDyPND6a
 HAUpF1jX72I1ilFUuYjrtx9bFD1UIVZCmrQTj39pICBWJt8pTi7U8O67p0t7RTFmRfS94wWFSJbSa
 Q/DJVDegSy3yRstJgtn8enSpChqQOs0nnwHriLv+gpuZ7FNVmC5D9TjXjwGyQrXSVOmqQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPL1u-0007Kj-6O; Fri, 17 Apr 2020 07:03:14 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPL1t-0003fa-E7; Fri, 17 Apr 2020 07:03:13 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPL1t-0006bT-D7; Fri, 17 Apr 2020 07:03:13 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149696-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149696: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=52b51b55a2e93546185dbe61ddf1d97987421a5b
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 07:03:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      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-pair  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-armhf-armhf-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-i386-libvirt       1 build-check(1)               blocked  n/a
 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-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              52b51b55a2e93546185dbe61ddf1d97987421a5b
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   91 days
Failing since        146211  2020-01-18 04:18:52 Z   90 days   87 attempts
Testing same since   149696  2020-04-17 04:18:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 15052 lines long.)


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:05:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:05:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPL4X-0001fT-5c; Fri, 17 Apr 2020 07:05:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3sm3=6B=amazon.de=prvs=369b905e4=wipawel@srs-us1.protection.inumbo.net>)
 id 1jPL4W-0001fN-EO
 for xen-devel@lists.xen.org; Fri, 17 Apr 2020 07:05:56 +0000
X-Inumbo-ID: e1ff53da-8079-11ea-9e09-bc764e2007e4
Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e1ff53da-8079-11ea-9e09-bc764e2007e4;
 Fri, 17 Apr 2020 07:05:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587107156; x=1618643156;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=AkgOU1+wOVzG+27TQuBhKQNE6uoniU+ew1o8ehk32hA=;
 b=a0XgZ+sVOHLGUzcjFLCelGmC2EIDt7sv7VvRaMyEKJAXMgomSltgc5RI
 GCmDC1qGNum+Qq3dTN2/GosEyDH61O1nMFLkjTPY3BjrPcnDITDwfiQfZ
 4Ro893VPE4f7NMfeWDVN66dLZGFccAR3v//dCIavSx3aHm3ltk1OrMPN/ 8=;
IronPort-SDR: pfvgCizM2AECzeaFULj2lu7txdzERBMb1floi+jXOnnAkISKso9xmZqRJv6SGT7bW7qDb+eYdv
 tQGJUJKhmbzg==
X-IronPort-AV: E=Sophos;i="5.72,394,1580774400"; d="scan'208";a="26253741"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO
 email-inbound-relay-2b-c7131dcf.us-west-2.amazon.com) ([10.43.8.2])
 by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP;
 17 Apr 2020 07:05:39 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2b-c7131dcf.us-west-2.amazon.com (Postfix) with ESMTPS
 id A24CCA218A; Fri, 17 Apr 2020 07:05:38 +0000 (UTC)
Received: from EX13D02EUC004.ant.amazon.com (10.43.164.117) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:37 +0000
Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by
 EX13D02EUC004.ant.amazon.com (10.43.164.117) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:36 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Fri, 17 Apr 2020 07:05:35 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 0/6] Add time management functionality
Date: Fri, 17 Apr 2020 07:05:22 +0000
Message-ID: <20200417070528.48329-1-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: semelpaul@gmail.com, andrew.cooper3@citrix.com, julien@xen.org,
 nmanthey@amazon.de, paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is a 2nd attempt to contribute time management functionality
to XTF. It is also a 2nd batch of the changes I want to sent upstream.

The patches add common/time.c core with scaling and system time
calculating functions.
Other patches add helper functions based on the core functionality.

Finally, there is also a little change adding EVTCHNOP_bind_vcpu
defininitions.

Paul Semel (4):
  time: introduce time managment in xtf
  time: add current_time() function to time management
  time: add gettimeofday() function to time managment
  time: Add helper functions and macros to time management

Pawel Wieczorkiewicz (2):
  time: Add cycles2{n,u,m}sec functions
  event_channels: Add EVTCHNOP_bind_vcpu hypercall support

 build/files.mk              |   1 +
 common/time.c               | 190 ++++++++++++++++++++++++++++++++++++++++++++
 include/xen/event_channel.h |   7 ++
 include/xtf/lib.h           |  18 +++++
 include/xtf/time.h          |  63 +++++++++++++++
 5 files changed, 279 insertions(+)
 create mode 100644 common/time.c
 create mode 100644 include/xtf/time.h

-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:06:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:06:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPL4c-0001gF-EY; Fri, 17 Apr 2020 07:06:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3sm3=6B=amazon.de=prvs=369b905e4=wipawel@srs-us1.protection.inumbo.net>)
 id 1jPL4b-0001g5-9W
 for xen-devel@lists.xen.org; Fri, 17 Apr 2020 07:06:01 +0000
X-Inumbo-ID: e2279250-8079-11ea-9e09-bc764e2007e4
Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e2279250-8079-11ea-9e09-bc764e2007e4;
 Fri, 17 Apr 2020 07:05:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587107156; x=1618643156;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=FGq21dZDqlyAQXJxV2xTF6vsjs2rXeIGTVUXZZqRLdA=;
 b=ptbhjimgkFbgqPndDPQ8IHF1jFoLh7ooko+wBKsclEHQr+yHTPPJ50rN
 2L/csHrXyzFBcE16TaKDOb31eBXmmKS2QkhJni3UnlqNli044tuP4dDSZ
 HbX+ir3UBBf1VGyblaqdU5gzrtwhAcwNLSMtw0R0fdLBTlD9nxBXrGDOC U=;
IronPort-SDR: rjJzvLVqtRl3y398/t9DcG0j2Zl+/QEbvLLjmG61nbiR07845Oq27V1MnQL0HXGPPxmBq1ysn2
 LVWhC2MEWvZw==
X-IronPort-AV: E=Sophos;i="5.72,394,1580774400"; d="scan'208";a="26253747"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO
 email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com) ([10.43.8.2])
 by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP;
 17 Apr 2020 07:05:43 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com (Postfix) with ESMTPS
 id BD700A225C; Fri, 17 Apr 2020 07:05:42 +0000 (UTC)
Received: from EX13D02EUC002.ant.amazon.com (10.43.164.14) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:42 +0000
Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by
 EX13D02EUC002.ant.amazon.com (10.43.164.14) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:41 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Fri, 17 Apr 2020 07:05:39 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 1/6] time: introduce time managment in xtf
Date: Fri, 17 Apr 2020 07:05:23 +0000
Message-ID: <20200417070528.48329-2-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200417070528.48329-1-wipawel@amazon.de>
References: <20200417070528.48329-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, Pawel Wieczorkiewicz <wipawel@amazon.de>,
 nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Semel <phentex@amazon.de>

This commit introduces basic time management functionality.
For synchronization purpose, we do really want to be able to
"control" time.

Add since_boot_time() that gets the time in nanoseconds from the
moment the VM has booted.

Signed-off-by: Paul Semel <phentex@amazon.de>
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 build/files.mk     |  1 +
 common/time.c      | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/xtf/lib.h  | 18 ++++++++++++
 include/xtf/time.h | 28 ++++++++++++++++++
 4 files changed, 132 insertions(+)
 create mode 100644 common/time.c
 create mode 100644 include/xtf/time.h

diff --git a/build/files.mk b/build/files.mk
index dfa27e4..6286317 100644
--- a/build/files.mk
+++ b/build/files.mk
@@ -16,6 +16,7 @@ obj-perarch += $(ROOT)/common/libc/vsnprintf.o
 obj-perarch += $(ROOT)/common/report.o
 obj-perarch += $(ROOT)/common/setup.o
 obj-perarch += $(ROOT)/common/xenbus.o
+obj-perarch += $(ROOT)/common/time.o
 
 obj-perenv += $(ROOT)/arch/x86/decode.o
 obj-perenv += $(ROOT)/arch/x86/desc.o
diff --git a/common/time.c b/common/time.c
new file mode 100644
index 0000000..b9a6531
--- /dev/null
+++ b/common/time.c
@@ -0,0 +1,85 @@
+#include <xtf/types.h>
+#include <xtf/traps.h>
+#include <xtf/time.h>
+#include <xtf/atomic.h>
+
+/* This function was taken from mini-os source code */
+/* It returns ((delta << shift) * mul_frac) >> 32 */
+static inline uint64_t scale_delta(uint64_t delta, uint32_t mul_frac, int shift)
+{
+    uint64_t product;
+#ifdef __i386__
+    uint32_t tmp1, tmp2;
+#endif
+
+    if ( shift < 0 )
+        delta >>= -shift;
+    else
+        delta <<= shift;
+
+#ifdef __i386__
+    __asm__ (
+            "mul  %5       ; "
+            "mov  %4,%%eax ; "
+            "mov  %%edx,%4 ; "
+            "mul  %5       ; "
+            "add  %4,%%eax ; "
+            "xor  %5,%5    ; "
+            "adc  %5,%%edx ; "
+            : "=A" (product), "=r" (tmp1), "=r" (tmp2)
+            : "a" ((uint32_t)delta), "1" ((uint32_t)(delta >> 32)), "2" (mul_frac) );
+#else
+    __asm__ (
+            "mul %%rdx ; shrd $32,%%rdx,%%rax"
+            : "=a" (product) : "0" (delta), "d" ((uint64_t)mul_frac) );
+#endif
+
+    return product;
+}
+
+
+#if defined(__i386__)
+uint32_t since_boot_time(void)
+#else
+uint64_t since_boot_time(void)
+#endif
+{
+    unsigned long old_tsc, tsc;
+#if defined(__i386__)
+    uint32_t system_time;
+#else
+    uint64_t system_time;
+#endif
+    uint32_t ver1, ver2;
+
+    do {
+        do {
+            ver1 = shared_info.vcpu_info[0].time.version;
+            smp_rmb();
+        } while ( (ver1 & 1) == 1 );
+
+        system_time = shared_info.vcpu_info[0].time.system_time;
+        old_tsc = shared_info.vcpu_info[0].time.tsc_timestamp;
+
+        smp_rmb();
+        tsc = rdtscp();
+        ver2 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
+        smp_rmb();
+    } while ( ver1 != ver2 );
+
+    system_time += scale_delta(tsc - old_tsc,
+                               shared_info.vcpu_info[0].time.tsc_to_system_mul,
+                               shared_info.vcpu_info[0].time.tsc_shift);
+
+    return system_time;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xtf/lib.h b/include/xtf/lib.h
index 3348464..c3eb10c 100644
--- a/include/xtf/lib.h
+++ b/include/xtf/lib.h
@@ -54,6 +54,24 @@ void __noreturn panic(const char *fmt, ...) __printf(1, 2);
 
 #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
 
+#ifdef __GCC_ASM_FLAG_OUTPUTS__
+# define ASM_FLAG_OUT(yes, no) yes
+#else
+# define ASM_FLAG_OUT(yes, no) no
+#endif
+
+static inline uint64_t rdtsc (void) {
+  unsigned int low, high;
+  asm volatile ("rdtsc" : "=a" (low), "=d" (high));
+  return ((uint64_t) high << 32) | low;
+}
+
+static inline uint64_t rdtscp (void) {
+  unsigned int low, high;
+  asm volatile ("rdtscp" : "=a" (low), "=d" (high) :: "ecx");
+  return ((uint64_t) high << 32) | low;
+}
+
 void heapsort(void *base, size_t nmemb, size_t size,
               int (*compar)(const void *, const void *),
               void (*swap)(void *, void *));
diff --git a/include/xtf/time.h b/include/xtf/time.h
new file mode 100644
index 0000000..e30d109
--- /dev/null
+++ b/include/xtf/time.h
@@ -0,0 +1,28 @@
+/**
+ * @file include/xtf/time.h
+ *
+ * Time management
+ */
+#ifndef XTF_TIME_H
+# define XTF_TIME_H
+
+#include <xtf/types.h>
+
+#if defined(__i386__)
+/* Time from boot in nanoseconds */
+uint32_t since_boot_time(void);
+#else
+uint64_t since_boot_time(void);
+#endif
+
+#endif /* XTF_TIME_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:06:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:06:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPL4f-0001hG-Nq; Fri, 17 Apr 2020 07:06:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3sm3=6B=amazon.de=prvs=369b905e4=wipawel@srs-us1.protection.inumbo.net>)
 id 1jPL4d-0001gm-LW
 for xen-devel@lists.xen.org; Fri, 17 Apr 2020 07:06:03 +0000
X-Inumbo-ID: e5f79132-8079-11ea-8c80-12813bfff9fa
Received: from smtp-fw-6001.amazon.com (unknown [52.95.48.154])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e5f79132-8079-11ea-8c80-12813bfff9fa;
 Fri, 17 Apr 2020 07:06:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587107163; x=1618643163;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=UuhJUamVQd+VEFaxWjDQUrzLutylPKzCdCKci7sTFY8=;
 b=RVeUGLlLP/pEJaD+6PIWi9VAiqzAIz51ndh15kpZWTZhAx4WPy4OgyUd
 pIdzHyjqqIksfm6Fq/VNl6o87ppQwPX95c7Nc+tCSIoncgYmL0WdLG+lM
 69oBytPRP6BbDccQCZsFOz4gtXBc2DfWL7cWT0A8HXBBEyrKoGcJEFgLB o=;
IronPort-SDR: HZXgY8bJmz2svV7iz58h+viVh4a+y8Y07WG7YaoCHAnuPRqDVveBIiijfZOwfer/Kr6DcblnPV
 uVcoYzSMTUfQ==
X-IronPort-AV: E=Sophos;i="5.72,394,1580774400"; d="scan'208";a="27348876"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2c-87a10be6.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP;
 17 Apr 2020 07:05:45 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2c-87a10be6.us-west-2.amazon.com (Postfix) with ESMTPS
 id 6C582A24B7; Fri, 17 Apr 2020 07:05:44 +0000 (UTC)
Received: from EX13D02EUB002.ant.amazon.com (10.43.166.170) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:44 +0000
Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by
 EX13D02EUB002.ant.amazon.com (10.43.166.170) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:43 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Fri, 17 Apr 2020 07:05:41 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 2/6] time: add current_time() function to time management
Date: Fri, 17 Apr 2020 07:05:24 +0000
Message-ID: <20200417070528.48329-3-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200417070528.48329-1-wipawel@amazon.de>
References: <20200417070528.48329-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: semelpaul@gmail.com, andrew.cooper3@citrix.com, julien@xen.org,
 nmanthey@amazon.de, paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Semel <phentex@amazon.de>

This function returns the "epoch" time.

Signed-off-by: Paul Semel <phentex@amazon.de>
---
 common/time.c      | 16 ++++++++++++++++
 include/xtf/time.h |  4 ++++
 2 files changed, 20 insertions(+)

diff --git a/common/time.c b/common/time.c
index b9a6531..7decd07 100644
--- a/common/time.c
+++ b/common/time.c
@@ -74,6 +74,22 @@ uint64_t since_boot_time(void)
     return system_time;
 }
 
+/* This function return the epoch time (number of seconds elapsed
+ * since Juanary 1, 1970) */
+#if defined(__i386__)
+uint32_t current_time(void)
+#else
+uint64_t current_time(void)
+#endif
+{
+#if defined(__i386__)
+    uint32_t seconds = shared_info.wc_sec;
+#else
+    uint64_t seconds = ((uint64_t)shared_info.wc_sec_hi << 32) | shared_info.wc_sec;
+#endif
+    return seconds + (since_boot_time() / 1000000000);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index e30d109..52da27a 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -11,8 +11,12 @@
 #if defined(__i386__)
 /* Time from boot in nanoseconds */
 uint32_t since_boot_time(void);
+
+uint32_t current_time(void);
 #else
 uint64_t since_boot_time(void);
+
+uint64_t current_time(void);
 #endif
 
 #endif /* XTF_TIME_H */
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:06:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:06:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPL4j-0001iU-1G; Fri, 17 Apr 2020 07:06:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3sm3=6B=amazon.de=prvs=369b905e4=wipawel@srs-us1.protection.inumbo.net>)
 id 1jPL4i-0001iJ-LZ
 for xen-devel@lists.xen.org; Fri, 17 Apr 2020 07:06:08 +0000
X-Inumbo-ID: e6d588fd-8079-11ea-8c80-12813bfff9fa
Received: from smtp-fw-4101.amazon.com (unknown [72.21.198.25])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e6d588fd-8079-11ea-8c80-12813bfff9fa;
 Fri, 17 Apr 2020 07:06:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587107165; x=1618643165;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=493GNuIf5KbW+Y/729Kw1IKQ8Uqsew/NWiY7HpkG1hg=;
 b=IHlDk+s/fHSacLfqJM1ZyUhysyyzv1zhiljbsKiX5C+T2+uj7ZiuIcX5
 yxeXjz8iSBpDQ8fSLqfmzhOB4LA/ZsYxkVFbhKY6VAu3DDi2GTIgQ+yEH
 DPt7St+azVfn42SSIKa+jI8awMzMSBhoQf+cJgd6uxycHhsb6Jv/gGGp3 c=;
IronPort-SDR: bB/uFZXPLRh/pPukLbf1/QJKMR4TloS6qG2sZfxHgYCMOuZ1ys2ILsDEwcKqcvWmqOjiZ+9jNp
 Mmn+b03wsatw==
X-IronPort-AV: E=Sophos;i="5.72,394,1580774400"; d="scan'208";a="26002075"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP;
 17 Apr 2020 07:05:47 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com (Postfix) with ESMTPS
 id 32E3AA24C6; Fri, 17 Apr 2020 07:05:46 +0000 (UTC)
Received: from EX13D02EUB001.ant.amazon.com (10.43.166.150) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:45 +0000
Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by
 EX13D02EUB001.ant.amazon.com (10.43.166.150) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:44 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Fri, 17 Apr 2020 07:05:43 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 3/6] time: add gettimeofday() function to time managment
Date: Fri, 17 Apr 2020 07:05:25 +0000
Message-ID: <20200417070528.48329-4-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200417070528.48329-1-wipawel@amazon.de>
References: <20200417070528.48329-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: semelpaul@gmail.com, andrew.cooper3@citrix.com, julien@xen.org,
 nmanthey@amazon.de, paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Semel <phentex@amazon.de>

Signed-off-by: Paul Semel <phentex@amazon.de>
---
 common/time.c      | 14 ++++++++++++++
 include/xtf/time.h | 12 ++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/common/time.c b/common/time.c
index 7decd07..fffae1c 100644
--- a/common/time.c
+++ b/common/time.c
@@ -90,6 +90,20 @@ uint64_t current_time(void)
     return seconds + (since_boot_time() / 1000000000);
 }
 
+/* The POSIX gettimeofday syscall normally takes a second argument, which is
+ * the timezone (struct timezone). However, it sould be NULL because linux
+ * doesn't use it anymore. So we need for us to add it in this function
+ */
+int gettimeofday(struct timeval *tp)
+{
+    if (!tp)
+        return -1;
+
+    tp->sec = current_time();
+    tp->nsec = shared_info.wc_nsec + (since_boot_time() % 1000000000);
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index 52da27a..e312465 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -8,6 +8,16 @@
 
 #include <xtf/types.h>
 
+struct timeval {
+#if !defined(__i386__)
+    uint64_t sec;
+    uint64_t nsec;
+#else
+    uint32_t sec;
+    uint32_t nsec;
+#endif
+};
+
 #if defined(__i386__)
 /* Time from boot in nanoseconds */
 uint32_t since_boot_time(void);
@@ -19,6 +29,8 @@ uint64_t since_boot_time(void);
 uint64_t current_time(void);
 #endif
 
+int gettimeofday(struct timeval *tp);
+
 #endif /* XTF_TIME_H */
 
 /*
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:06:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPL4o-0001kI-AL; Fri, 17 Apr 2020 07:06:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3sm3=6B=amazon.de=prvs=369b905e4=wipawel@srs-us1.protection.inumbo.net>)
 id 1jPL4n-0001k1-Lv
 for xen-devel@lists.xen.org; Fri, 17 Apr 2020 07:06:13 +0000
X-Inumbo-ID: ec349702-8079-11ea-8c80-12813bfff9fa
Received: from smtp-fw-6001.amazon.com (unknown [52.95.48.154])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ec349702-8079-11ea-8c80-12813bfff9fa;
 Fri, 17 Apr 2020 07:06:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587107173; x=1618643173;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=7z65Bh4Xe0Ehypmwl+K1UUIrCedT+0ZwsHnvKnpUKuo=;
 b=jdNkq8/P4tIwHc5HqNoq+VfI1uWhFxRffAs6Ba7AhvzPK1ytQe+yBWgi
 ICbexPFXPs9z3GE8NnLehUerGuXb+G4el+d8/sPIkexqyJPm+VnAZBUAZ
 +pXl2V2wcaEZ63EgbJEgrKhNvZjPo71nPyFvDEGDaCP432F6wsw5IQ22X I=;
IronPort-SDR: ipOWzI3Pz3DD/dajzMiIsbaMbBaQAyA9/mhsuH+7SPxo01uOIPjsRIZkiZbCQteofQXlvabn86
 jdhLw+mSKaPw==
X-IronPort-AV: E=Sophos;i="5.72,394,1580774400"; d="scan'208";a="27348926"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2b-baacba05.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP;
 17 Apr 2020 07:06:13 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2b-baacba05.us-west-2.amazon.com (Postfix) with ESMTPS
 id B58B1A056D; Fri, 17 Apr 2020 07:06:11 +0000 (UTC)
Received: from EX13D02EUC004.ant.amazon.com (10.43.164.117) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:47 +0000
Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by
 EX13D02EUC004.ant.amazon.com (10.43.164.117) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:46 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Fri, 17 Apr 2020 07:05:45 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 4/6] time: Add helper functions and macros to time management
Date: Fri, 17 Apr 2020 07:05:26 +0000
Message-ID: <20200417070528.48329-5-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200417070528.48329-1-wipawel@amazon.de>
References: <20200417070528.48329-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: semelpaul@gmail.com, andrew.cooper3@citrix.com, julien@xen.org,
 nmanthey@amazon.de, paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Semel <phentex@amazon.de>

Add the following helper functions:
  - nspin_sleep()
  - spin_sleep()
  - mspin_sleep()

Add the following helper macros:
  - sleep()
  - msleep()
  - NOW()

Signed-off-by: Paul Semel <phentex@amazon.de>
---
 common/time.c      | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/xtf/time.h | 16 +++++++++++++++
 2 files changed, 74 insertions(+)

diff --git a/common/time.c b/common/time.c
index fffae1c..3db1f8f 100644
--- a/common/time.c
+++ b/common/time.c
@@ -104,6 +104,64 @@ int gettimeofday(struct timeval *tp)
     return 0;
 }
 
+#if defined(__i386__)
+static inline void nspin_sleep(uint32_t t)
+#else
+static inline void nspin_sleep(uint64_t t)
+#endif
+{
+    unsigned long end = since_boot_time() + t;
+
+    while ( since_boot_time() < end )
+        asm volatile ( "pause" );
+}
+
+#if defined(__i386__)
+static inline void spin_sleep(uint32_t t)
+#else
+static inline void spin_sleep(uint64_t t)
+#endif
+{
+#if defined(__i386__)
+    uint32_t nsec = t * 1000000000;
+#else
+    uint64_t nsec = t * 1000000000ul;
+#endif
+    nspin_sleep(nsec);
+}
+
+#if defined(__i386__)
+static inline void mspin_sleep(uint32_t t)
+#else
+static inline void mspin_sleep(uint64_t t)
+#endif
+{
+#if defined(__i386__)
+    uint32_t nsec = t * 1000000;
+#else
+    uint64_t nsec = t * 1000000ul;
+#endif
+    nspin_sleep(nsec);
+}
+
+#if defined(__i386__)
+void sleep(uint32_t t)
+#else
+void sleep(uint64_t t)
+#endif
+{
+    spin_sleep(t);
+}
+
+#if defined(__i386__)
+void msleep(uint32_t t)
+#else
+void msleep(uint64_t t)
+#endif
+{
+    mspin_sleep(t);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index e312465..07fcae5 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -23,14 +23,30 @@ struct timeval {
 uint32_t since_boot_time(void);
 
 uint32_t current_time(void);
+
+/* This function takes seconds in parameter */
+void sleep(uint32_t f);
+
+/* Be careful, this function takes milliseconds in parameter,
+ * not microseconds !
+ */
+void msleep(uint32_t f);
 #else
 uint64_t since_boot_time(void);
 
 uint64_t current_time(void);
+
+void sleep(uint64_t f);
+
+void msleep(uint64_t f);
 #endif
 
 int gettimeofday(struct timeval *tp);
 
+
+/* This returns the current epoch time */
+#define NOW() current_time()
+
 #endif /* XTF_TIME_H */
 
 /*
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:06:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:06:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPL4p-0001lL-K5; Fri, 17 Apr 2020 07:06:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3sm3=6B=amazon.de=prvs=369b905e4=wipawel@srs-us1.protection.inumbo.net>)
 id 1jPL4o-0001kF-8L
 for xen-devel@lists.xen.org; Fri, 17 Apr 2020 07:06:14 +0000
X-Inumbo-ID: ec55d89a-8079-11ea-b4f4-bc764e2007e4
Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ec55d89a-8079-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 07:06:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587107173; x=1618643173;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=l/TJTTqBsW2Qk+W7CflHlPQqQTeMk2Ziy87aPeKhtR8=;
 b=duQ3EvjROmJPZs0ebKxZAr14SUrLCqvIYnKFyPlv5h2q5XtksLi4d7w9
 /J/mXl2gnTU/096pjxwQsz7bnPsWVNr54W6nM8R/HdHz8tMEPyCwhTbC/
 nsKyRbVuRdIhIux965NZDgcCT94WccLj//B+bY0HhCbpBrA7NBak/VoS+ Q=;
IronPort-SDR: QKpZsaYWvK5JQHIwh1KDXnpUuIWKPnO0byJA6yZrOwJCTUeKWStqi424LVyNyHDyZMMrwqMnk0
 IiQqFmkj40gg==
X-IronPort-AV: E=Sophos;i="5.72,394,1580774400"; d="scan'208";a="37631727"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2a-f14f4a47.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP;
 17 Apr 2020 07:06:11 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2a-f14f4a47.us-west-2.amazon.com (Postfix) with ESMTPS
 id 6EC1BA22CA; Fri, 17 Apr 2020 07:06:11 +0000 (UTC)
Received: from EX13D05EUB002.ant.amazon.com (10.43.166.45) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:49 +0000
Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by
 EX13D05EUB002.ant.amazon.com (10.43.166.45) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:48 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Fri, 17 Apr 2020 07:05:46 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 5/6] time: Add cycles2{n,u,m}sec functions
Date: Fri, 17 Apr 2020 07:05:27 +0000
Message-ID: <20200417070528.48329-6-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200417070528.48329-1-wipawel@amazon.de>
References: <20200417070528.48329-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, Pawel Wieczorkiewicz <wipawel@amazon.de>,
 nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In order to easily translate CPU cycles to time values add the
following helpers:
- cycles2nsec()
- cycles2usec()
- cycles2msec()

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 common/time.c      | 17 +++++++++++++++++
 include/xtf/time.h |  5 ++++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/common/time.c b/common/time.c
index 3db1f8f..8f73243 100644
--- a/common/time.c
+++ b/common/time.c
@@ -162,6 +162,23 @@ void msleep(uint64_t t)
     mspin_sleep(t);
 }
 
+unsigned long cycles2nsec(uint64_t cycles)
+{
+    return scale_delta(cycles,
+            shared_info.vcpu_info[0].time.tsc_to_system_mul,
+            shared_info.vcpu_info[0].time.tsc_shift);
+}
+
+unsigned long cycles2usec(uint64_t cycles)
+{
+    return cycles2nsec(cycles) / 1000;
+}
+
+unsigned long cycles2msec(uint64_t cycles)
+{
+    return cycles2nsec(cycles) / 1000000;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index 07fcae5..6aa1efc 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -43,10 +43,13 @@ void msleep(uint64_t f);
 
 int gettimeofday(struct timeval *tp);
 
-
 /* This returns the current epoch time */
 #define NOW() current_time()
 
+unsigned long cycles2nsec(uint64_t cycles);
+unsigned long cycles2usec(uint64_t cycles);
+unsigned long cycles2msec(uint64_t cycles);
+
 #endif /* XTF_TIME_H */
 
 /*
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:06:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:06:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPL51-0001s1-4f; Fri, 17 Apr 2020 07:06:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=3sm3=6B=amazon.de=prvs=369b905e4=wipawel@srs-us1.protection.inumbo.net>)
 id 1jPL4z-0001rQ-Vh
 for xen-devel@lists.xen.org; Fri, 17 Apr 2020 07:06:25 +0000
X-Inumbo-ID: f3b57adc-8079-11ea-b4f4-bc764e2007e4
Received: from smtp-fw-6002.amazon.com (unknown [52.95.49.90])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f3b57adc-8079-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 07:06:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587107186; x=1618643186;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=ohM0/A02cQtDxZuWCKtvIr8AsH7i7i/rmvBHra8TnjM=;
 b=Iq05JnjD0Ksap+A2CMLoa+a+aCdMiyQJ+jkfyeB/osDnSD/mhRK2v8F7
 lj1DVW6W239jFO/I1i+8YuBLqeuDoH5kTqn3qWR0aSL2YiPXJbgGvSSBz
 KtRx/0LMcJ0dGICKMoXZ0vlnHUHSgzcLuDhEbOgbLk5labBs50RpMQhnW Q=;
IronPort-SDR: /gCX9Bs9KaV8s7+165BhnxqcrciZ2hP71u0dos2O8eUjPUQxjrJmVL3fhlouF8tIIOa5de3rZq
 8Ltkwv+SMVhg==
X-IronPort-AV: E=Sophos;i="5.72,394,1580774400"; d="scan'208";a="25912318"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2b-4ff6265a.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP;
 17 Apr 2020 07:06:14 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2b-4ff6265a.us-west-2.amazon.com (Postfix) with ESMTPS
 id D57D3A2747; Fri, 17 Apr 2020 07:06:11 +0000 (UTC)
Received: from EX13D05EUB003.ant.amazon.com (10.43.166.253) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:51 +0000
Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by
 EX13D05EUB003.ant.amazon.com (10.43.166.253) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 17 Apr 2020 07:05:50 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Fri, 17 Apr 2020 07:05:48 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 6/6] event_channels: Add EVTCHNOP_bind_vcpu hypercall support
Date: Fri, 17 Apr 2020 07:05:28 +0000
Message-ID: <20200417070528.48329-7-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200417070528.48329-1-wipawel@amazon.de>
References: <20200417070528.48329-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, Pawel Wieczorkiewicz <wipawel@amazon.de>,
 nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 include/xen/event_channel.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/xen/event_channel.h b/include/xen/event_channel.h
index 62ee95a..6253b89 100644
--- a/include/xen/event_channel.h
+++ b/include/xen/event_channel.h
@@ -2,6 +2,7 @@
 #define XEN_PUBLIC_EVENT_CHANNEL_H
 
 #define EVTCHNOP_send             4
+#define EVTCHNOP_bind_vcpu        8
 #define EVTCHNOP_init_control    11
 #define EVTCHNOP_expand_array    12
 
@@ -22,6 +23,12 @@ struct evtchn_expand_array {
     uint64_t array_gfn;
 };
 
+struct evtchn_bind_vcpu {
+    /* IN parameters. */
+    evtchn_port_t port;
+    uint32_t vcpu;
+};
+
 #endif /* XEN_PUBLIC_EVENT_CHANNEL_H */
 
 /*
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:09:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPL8A-0002Ms-Mp; Fri, 17 Apr 2020 07:09:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=VQOO=6B=huawei.com=yanaijie@srs-us1.protection.inumbo.net>)
 id 1jPL89-0002Mn-NU
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 07:09:41 +0000
X-Inumbo-ID: 653c4366-807a-11ea-b4f4-bc764e2007e4
Received: from huawei.com (unknown [45.249.212.32])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 653c4366-807a-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 07:09:37 +0000 (UTC)
Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58])
 by Forcepoint Email with ESMTP id 28D6622F2F9E658195FE;
 Fri, 17 Apr 2020 15:09:35 +0800 (CST)
Received: from huawei.com (10.175.124.28) by DGGEMS404-HUB.china.huawei.com
 (10.3.19.204) with Microsoft SMTP Server id 14.3.487.0; Fri, 17 Apr 2020
 15:09:27 +0800
From: Jason Yan <yanaijie@huawei.com>
To: <konrad.wilk@oracle.com>, <bhelgaas@google.com>, <tglx@linutronix.de>,
 <mingo@redhat.com>, <bp@alien8.de>, <x86@kernel.org>, <hpa@zytor.com>,
 <xen-devel@lists.xenproject.org>, <linux-pci@vger.kernel.org>,
 <linux-kernel@vger.kernel.org>
Subject: [PATCH] xen/pci: make xen_msi_init() static
Date: Fri, 17 Apr 2020 15:35:53 +0800
Message-ID: <20200417073553.42873-1-yanaijie@huawei.com>
X-Mailer: git-send-email 2.21.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.175.124.28]
X-CFilter-Loop: Reflected
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Hulk Robot <hulkci@huawei.com>, Jason Yan <yanaijie@huawei.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Fix the following sparse warning:

arch/x86/pci/xen.c:426:13: warning: symbol 'xen_msi_init' was not
declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
---
 arch/x86/pci/xen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 91220cc25854..0d06f12ccd74 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -423,7 +423,7 @@ int __init pci_xen_init(void)
 }
 
 #ifdef CONFIG_PCI_MSI
-void __init xen_msi_init(void)
+static void __init xen_msi_init(void)
 {
 	if (!disable_apic) {
 		/*
-- 
2.21.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:12:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPLAg-00037N-4Y; Fri, 17 Apr 2020 07:12:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPLAe-00037H-Cv
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 07:12:16 +0000
X-Inumbo-ID: c3da72a8-807a-11ea-8c82-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c3da72a8-807a-11ea-8c82-12813bfff9fa;
 Fri, 17 Apr 2020 07:12:15 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4A133AE41;
 Fri, 17 Apr 2020 07:12:13 +0000 (UTC)
Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-15-anthony.perard@citrix.com>
 <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
 <20200416124400.GG4088@perard.uk.xensource.com>
 <312e719f-2bae-cb29-a6dd-29ae0d976d95@suse.com>
 <20200416150929.GL4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <586cff44-d46e-3a5b-9e47-0c7ff4de8801@suse.com>
Date: Fri, 17 Apr 2020 09:12:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416150929.GL4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.2020 17:09, Anthony PERARD wrote:
> On Thu, Apr 16, 2020 at 04:22:05PM +0200, Jan Beulich wrote:
>> On 16.04.2020 14:44, Anthony PERARD wrote:
>>> On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
>>>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>>>> We want to use the same rune to build mm/*/guest_*.o as the one use to
>>>>> build every other *.o object. The consequence it that file symbols that
>>>>> the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
>>>>>
>>>>> (1) Currently we have those two file symbols:
>>>>>     guest_walk.c
>>>>>     guest_walk_2.o
>>>>> (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have:
>>>>>     arch/x86/mm/guest_walk.c
>>>>>     guest_walk_2.o
>>>>>
>>>>> The order in which those symbols are present may be different.
>>>>>
>>>>> Currently, in case (1) ./symbols chooses the *.o symbol (object file
>>>>> name). But in case (2), may choose the *.c symbol (source file name with
>>>>> path component) if it is first
>>>>>
>>>>> We want to have ./symbols choose the object file name symbol in both
>>>>> cases.
>>>>
>>>> I guess the reason for wanting this is somehow connected to the
>>>> statement at the beginning of the description, but I can't seem
>>>> to be able to make the connection.
>>>
>>> I'm not sure I can explain it better.
>>>
>>> The "object file name" file symbol is used to distinguish between symbols
>>> from all mm/*/guest_* objects. The other file symbol present in those
>>> object is a "source file name without any path component symbol".
>>>
>>> But building those objects with the same rune as any other objects, and
>>> having CONFIG_ENFORCE_UNIQUE_SYMBOLS=y, changes the file symbols present
>>> in the resulting object. We still have the "object file name" symbol,
>>> but now we also have "source file name with path components" symbol.
>>> Unfortunately, all mm/*/guest_*.o in one directory are built from the
>>> same source file, and thus have the same "source file name" symbol, but
>>> have different "object file name" symbol. We still want to be able to
>>> distinguish between guest_*.o in one dir, and the only way for that is
>>> to use the "object file name" symbol.
>>
>> So where's the difference from how things work right now? The "same rune"
>> aspect doesn't really change - right now we also build with effectively
>> the same logic, just that -DGUEST_PAGING_LEVELS=... gets added. I guess
>> it might help if you showed (for one particular example) how the set of
>> file symbols changes from what we have now (with and without
>> CONFIG_ENFORCE_UNIQUE_SYMBOLS=y) to what there would be with your changes
>> to the symbols utility to what there will be with those changes.
> 
> The logic to build objects from C files changed in 81ecb38b83b0 ("build:
> provide option to disambiguate symbol names"), with objects build with
> __OBJECT_FILE__ explicitly left alone. So the logic is different now (at
> least when CONFIG_ENFORCE_UNIQUE_SYMBOLS=y).
> 
> I did add the example of building arch/x86/mm/guest_walk_2.o to the
> commit message, reworded below:
> 
> For example, when building arch/x86/mm/guest_walk_2.o from guest_walk.c,
> this would be the difference of file symbol present in the object when
> building with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y:
> 
> (1) Currently we have those two file symbols:
>     guest_walk.c
>     guest_walk_2.o
> (2) When building with the same rune, we will have:
>     arch/x86/mm/guest_walk.c
>     guest_walk_2.o

Ah, yes, the changed introductory paragraph makes clear (to me)
what presence and what future (1) and (2) are talking about. Yet
what I then still don't understand - what is it that makes the
path appear when switching to the common rune? Oh - I finally
figured it: It's the objcopy step that will apply to all targets
uniformly then. Perhaps it's indeed obvious, but it clearly
wasn't to me when merely looking at the patch.

With this I'd then wonder whether it wouldn't be a far smaller
adjustment to simply skip that --redefine-sym step in case the
object file already has a file symbol naming the object file,
thus simply retaining the status quo.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:28:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:28:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPLQC-00046d-Mw; Fri, 17 Apr 2020 07:28:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPLQA-00046Y-Pc
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 07:28:18 +0000
X-Inumbo-ID: fe653c9e-807c-11ea-8c83-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fe653c9e-807c-11ea-8c83-12813bfff9fa;
 Fri, 17 Apr 2020 07:28:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=rU9uB9G8hWVM7mQHoQpmdZiFkM+uBXYeTDQpG5zLvyo=; b=j+m5ZzUk0xtQ2vJ00CSZQv/8A
 TR3AXD55JXyfDrKnGfzbB5vRqWT6/mEzoVuTmZnCwnxagsF6f3l9tFW2bQxSj4VmaUGEGXld92/jE
 TpHYHh806hX7u1wzWODp+EZAtF/6xs1BeNeZbCNmHXQmEyu8D9+LvE490Mi4L4HbaIfkY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPLQ3-0007pv-RR; Fri, 17 Apr 2020 07:28:11 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPLQ3-0005Qe-Fw; Fri, 17 Apr 2020 07:28:11 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPLQ3-0007FF-Ek; Fri, 17 Apr 2020 07:28:11 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149693-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149693: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=9786cab674574239b04df638f825ee0e7d76a48c
X-Osstest-Versions-That: linux=8632e9b5645bbc2331d21d892b0d6961c1a08429
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 07:28:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                9786cab674574239b04df638f825ee0e7d76a48c
baseline version:
 linux                8632e9b5645bbc2331d21d892b0d6961c1a08429

Last test of basis   149678  2020-04-15 22:45:22 Z    1 days
Testing same since   149693  2020-04-16 19:59:31 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ardb@kernel.org>
  Arnd Bergmann <arnd@arndb.de>
  Arvind Sankar <nivedita@alum.mit.edu>
  Colin Ian King <colin.king@canonical.com>
  David Howells <dhowells@redhat.com>
  Gary Lin <glin@suse.com>
  Ilya Dryomov <idryomov@gmail.com>
  Ingo Molnar <mingo@kernel.org>
  Jeff Layton <jlayton@kernel.org>
  Jiri Slaby <jslaby@suse.cz>
  Linus Torvalds <torvalds@linux-foundation.org>
  Ondrej Mosnacek <omosnace@redhat.com>
  Paul Moore <paul@paul-moore.com>
  Steven Rostedt (VMware) <rostedt@goodmis.org>
  Takashi Iwai <tiwai@suse.de>
  Theodore Ts'o <tytso@mit.edu>
  Vasily Averin <vvs@virtuozzo.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   8632e9b5645b..9786cab67457  9786cab674574239b04df638f825ee0e7d76a48c -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:50:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:50:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPLlM-0006TN-Tv; Fri, 17 Apr 2020 07:50:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPLlL-0006TI-Tg
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 07:50:11 +0000
X-Inumbo-ID: 0c43783d-8080-11ea-8c85-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0c43783d-8080-11ea-8c85-12813bfff9fa;
 Fri, 17 Apr 2020 07:50:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=sARSnXEOJu+nYg4xBwR5C4LwnsmdLizd2/X+L79U++w=; b=m8p/DV9GA2NAvsRx+aRwOFzOb
 PLBW3bck+9/AD0p4alMw5O2fHSU7r6P/mCkP8OBFKi7JSelBSuHljBjcaIgl7RB1Cpz/vJEw7XeFK
 AD979I4YVrAwfHdTAEQotXJa+Hr5drd8g3+SrPIEwJ5fMCltnwgXO9cFFOQFthzjehW7E=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPLlD-0008Eq-OZ; Fri, 17 Apr 2020 07:50:03 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPLlD-0006WO-GW; Fri, 17 Apr 2020 07:50:03 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPLlD-0005fE-Ep; Fri, 17 Apr 2020 07:50:03 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149694-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149694: all pass - PUSHED
X-Osstest-Versions-This: ovmf=a7947b6366a660d4d655371fe6bc96315097c06d
X-Osstest-Versions-That: ovmf=06033f5abad3815e8d80de22c97ba38a05017262
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 07:50:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 a7947b6366a660d4d655371fe6bc96315097c06d
baseline version:
 ovmf                 06033f5abad3815e8d80de22c97ba38a05017262

Last test of basis   149685  2020-04-16 05:35:47 Z    1 days
Testing same since   149694  2020-04-16 21:41:26 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laszlo Ersek <lersek@redhat.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   06033f5aba..a7947b6366  a7947b6366a660d4d655371fe6bc96315097c06d -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:54:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPLpZ-0006dR-Gg; Fri, 17 Apr 2020 07:54:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ygd1=6B=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jPLpY-0006dM-8o
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 07:54:32 +0000
X-Inumbo-ID: ab0dd8fe-8080-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ab0dd8fe-8080-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 07:54:30 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1FA6CACC3;
 Fri, 17 Apr 2020 07:54:29 +0000 (UTC)
Subject: Re: [PATCH] sched: print information about scheduler granularity
To: Dario Faggioli <dfaggioli@suse.com>,
 Sergey Dyasli <sergey.dyasli@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <996ed66e-3782-5187-a804-9291741a2241@suse.com>
 <1587028832608.72974@citrix.com>
 <bd38c4da-b982-0d13-bdbd-ab363dae68e0@suse.com>
 <4716e235b5a5723c7cf55c3ef2d6295bcb27d8e0.camel@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <0a46eff8-454a-4bd8-6d7d-e90b8bb148a2@suse.com>
Date: Fri, 17 Apr 2020 09:54:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <4716e235b5a5723c7cf55c3ef2d6295bcb27d8e0.camel@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.20 18:47, Dario Faggioli wrote:
> On Thu, 2020-04-16 at 11:25 +0200, Jürgen Groß wrote:
>> On 16.04.20 11:20, Sergey Dyasli wrote:
>>> On 16/04/2020 09:57, Jürgen Groß wrote:
>>>>
>>>> The xen commandline ins part of the boot messages and is
>>>> contained
>>>> in the "xl info" output.
>>>
>>> It's true that you can see "sched-gran=core" in "xl info" output.
>>> But that's
>>> just the switch - not the end result. A user might want to verify
>>> that he did
>>> everything correctly and core-scheduling mode has indeed been
>>> enabled.
>>
>> I'm not opposed to your patch, but as soon as we have per-cpupool
>> granularity it should be reverted again.
>>
> Why reverted? Each cpupool dumps its own scheduling information. With
> per-pool granularity, we'll see something like
> 
> cpupool: Pool-A
> Scheduler: SMP Credit Scheduler (credit)
> Scheduling granularity: cpu
> ...
> cpupool: Pool-B
> Scheduler: SMP Credit Scheduler (credit)
> Scheduling granularity: core
> 
> etc.
> 
> Or am I missing something?

"Reworking" might have been a better wording.

The patch is looking only at the global variable opt_sched_granularity
for deciding which granularity to print out.


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 07:57:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 07:57:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPLsl-0006ks-1V; Fri, 17 Apr 2020 07:57:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ygd1=6B=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jPLsk-0006km-1o
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 07:57:50 +0000
X-Inumbo-ID: 212c7b26-8081-11ea-8c87-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 212c7b26-8081-11ea-8c87-12813bfff9fa;
 Fri, 17 Apr 2020 07:57:49 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5F201AEEF;
 Fri, 17 Apr 2020 07:57:47 +0000 (UTC)
Subject: Re: [PATCH] sched: print information about scheduler granularity
To: Dario Faggioli <dfaggioli@suse.com>,
 Sergey Dyasli <sergey.dyasli@citrix.com>, xen-devel@lists.xenproject.org
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <d2577c4b4ff040c8f256d203e647619d9d4d6ebb.camel@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <3dacf98c-c4b7-a263-01d3-f8562619ff53@suse.com>
Date: Fri, 17 Apr 2020 09:57:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <d2577c4b4ff040c8f256d203e647619d9d4d6ebb.camel@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.20 18:43, Dario Faggioli wrote:
> On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
>> Currently it might be not obvious which scheduling mode is being used
>> by the scheduler. Alleviate this by printing additional information
>> about the selected granularity.
>>
> I like the idea. However, I don't like how verbose and long that line
> becomes.
> 
>>   Messages now look like these:
>>
>> 1. boot
>> (XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler
>> (credit) in core-scheduling mode
>>
>> 2. xl debug-keys r
>> (XEN) [   45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-
>> way core-scheduling mode
>>
> What about adding an entry, just below these ones. Something looking
> like, for instance (both at boot and in the debug-key dump):
> 
> "Scheduling granularity: cpu"
> 
> (or "core", or "socket")
> 
> Also
> 
>> --- a/xen/common/sched/cpupool.c
>> +++ b/xen/common/sched/cpupool.c
>> @@ -38,7 +38,35 @@ static cpumask_t cpupool_locked_cpus;
>>   static DEFINE_SPINLOCK(cpupool_lock);
>>   
>>   static enum sched_gran __read_mostly opt_sched_granularity =
>> SCHED_GRAN_cpu;
>> -static unsigned int __read_mostly sched_granularity = 1;
>> +static unsigned int __read_mostly sched_granularity;
>> +
>> +char *sched_gran_str(char *str, size_t size)
>> +{
>> +    char *mode = "";
>> +
>> +    switch ( opt_sched_granularity )
>> +    {
>> +    case SCHED_GRAN_cpu:
>> +        mode = "cpu";
>> +        break;
>> +    case SCHED_GRAN_core:
>> +        mode = "core";
>> +        break;
>> +    case SCHED_GRAN_socket:
>> +        mode = "socket";
>> +        break;
>> +    default:
>> +        ASSERT_UNREACHABLE();
>> +        break;
>> +    }
>> +
>> +    if ( sched_granularity )
>> +        snprintf(str, size, "%u-way %s", sched_granularity, mode);
>>
> I'm not sure about using the value of the enum like this.

enum? sched_granularity holds the number of cpus per scheduling
resource. opt_sched_granularity is the enum.

> 
> E.g., in a system with 4 threads per core, enabling core scheduling
> granularity would mean having 4 vCPUs in the scheduling units. But this
> will still print "2-way core-scheduling", which I think would sound
> confusing.

It would print "4-way", of course.

> 
> So I'd just go with "cpu", "core" and "socket" strings.

No, this is not a good idea. With e.g. smt=0 you'll be able to have
"1-way core" which is much more informative than "core".


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 08:37:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 08:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPMVJ-000276-Rv; Fri, 17 Apr 2020 08:37:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ygtx=6B=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPMVI-000271-2P
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 08:37:40 +0000
X-Inumbo-ID: b1285d62-8086-11ea-8c8a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b1285d62-8086-11ea-8c8a-12813bfff9fa;
 Fri, 17 Apr 2020 08:37:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/8xz/0zKPNa/QJnDkWQwq8lAPPqH0LAPkGvdw/+MObg=; b=ZHr9u0A659KFm//qnVaUQgpDtK
 s+ogHCwbaIhcMj/Ws8DqNFz4wRBZ7Yk+w5v8RQHGdpyPJpio9EfnerMi1JnnDJjLFfKT8SbHZL1ab
 2SuiGHSab3NeGIJ6s6utCplY7altvF3jxrCdIjORKVGQCSUQmDZkW1alzfHpjNzh7paE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPMVD-0001Ev-D3; Fri, 17 Apr 2020 08:37:35 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPMVD-0006na-62; Fri, 17 Apr 2020 08:37:35 +0000
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
Date: Fri, 17 Apr 2020 09:37:32 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 16/04/2020 16:46, Jan Beulich wrote:
> While it should have been this way from the beginning, not doing so will
> become an actual problem with PVH Dom0.

I think the current code is also buggy on PV dom0 because the buffer is 
not locked in memory. So you have no promise the buffer will be present 
when calling the hypercall.

> The interface change is binary
> compatible, but requires tools side producers to be re-built.
> 
> Drop the bogus/unnecessary page alignment restriction on the input
> buffer at the same time.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Is there really no way to avoid the buffer copying in libxc?
> 
> --- a/tools/libxc/xc_mem_paging.c
> +++ b/tools/libxc/xc_mem_paging.c
> @@ -26,15 +26,33 @@ static int xc_mem_paging_memop(xc_interf
>                                  unsigned int op, uint64_t gfn, void *buffer)

NIT: As you switch the handle to use const, would it make to also make 
the buffer const?

>   {
>       xen_mem_paging_op_t mpo;
> +    DECLARE_HYPERCALL_BOUNCE(buffer, XC_PAGE_SIZE,
> +                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +    int rc;
>   
>       memset(&mpo, 0, sizeof(mpo));
>   
>       mpo.op      = op;
>       mpo.domain  = domain_id;
>       mpo.gfn     = gfn;
> -    mpo.buffer  = (unsigned long) buffer;
>   
> -    return do_memory_op(xch, XENMEM_paging_op, &mpo, sizeof(mpo));
> +    if ( buffer )
> +    {
> +        if ( xc_hypercall_bounce_pre(xch, buffer) )
> +        {
> +            PERROR("Could not bounce memory for XENMEM_paging_op %u", op);
> +            return -1;
> +        }
> +
> +        set_xen_guest_handle(mpo.buffer, buffer);
> +    }
> +
> +    rc = do_memory_op(xch, XENMEM_paging_op, &mpo, sizeof(mpo));
> +
> +    if ( buffer )
> +        xc_hypercall_bounce_post(xch, buffer);
> +
> +    return rc;
>   }
>   
>   int xc_mem_paging_enable(xc_interface *xch, uint32_t domain_id,
> @@ -92,28 +110,13 @@ int xc_mem_paging_prep(xc_interface *xch
>   int xc_mem_paging_load(xc_interface *xch, uint32_t domain_id,
>                          uint64_t gfn, void *buffer)
>   {
> -    int rc, old_errno;
> -
>       errno = EINVAL;
>   
>       if ( !buffer )
>           return -1;
>   
> -    if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
> -        return -1;
> -
> -    if ( mlock(buffer, XC_PAGE_SIZE) )
> -        return -1;
> -
> -    rc = xc_mem_paging_memop(xch, domain_id,
> -                             XENMEM_paging_op_prep,
> -                             gfn, buffer);
> -
> -    old_errno = errno;
> -    munlock(buffer, XC_PAGE_SIZE);
> -    errno = old_errno;
> -
> -    return rc;
> +    return xc_mem_paging_memop(xch, domain_id, XENMEM_paging_op_prep,
> +                               gfn, buffer);
>   }
>   
>   
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1779,7 +1779,8 @@ void p2m_mem_paging_populate(struct doma
>    * mfn if populate was called for  gfn which was nominated but not evicted. In
>    * this case only the p2mt needs to be forwarded.
>    */
> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l, uint64_t buffer)
> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l,
> +                        XEN_GUEST_HANDLE_PARAM(const_uint8) buffer)

Shouldn't this technically be XEN_GUEST_HANDLE_64() to match the field?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:11:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:11:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPN1b-0005Gk-OZ; Fri, 17 Apr 2020 09:11:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=faa+=6B=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jPN1a-0005Gf-DT
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:11:02 +0000
X-Inumbo-ID: 5b433232-808b-11ea-8c96-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5b433232-808b-11ea-8c96-12813bfff9fa;
 Fri, 17 Apr 2020 09:11:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Reply-To:
 MIME-Version:Message-Id:Date:Subject:Cc:To:From:Sender:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=xoq74kanlDpSEGeT4aaaEaqJDjN1PmYSdwJPnXAjuvM=; b=Fql8UHiYjn7JGLgTSRvnGT9rV7
 tGAsz5U7grgG77kQ5DwLaTsEB6j1/V1IwJf016pomRAjd1ueQwlV7bfdPoSmxYy2BRIgaDs9/KpKb
 LlV4y6SEAqWRhdHDWXM3ffqU7V/pQhFRTf7lJmf58+ISlIwbykKjmaC/KAS6OPW4z7KM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jPN1Y-0001sy-B8; Fri, 17 Apr 2020 09:11:00 +0000
Received: from [54.239.6.186] (helo=CBG-R90WXYV0.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jPN1Y-0000X0-06; Fri, 17 Apr 2020 09:11:00 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [ANNOUNCE] Xen 4.14 Development Update
Date: Fri, 17 Apr 2020 10:10:57 +0100
Message-Id: <20200417091057.136-1-paul@xen.org>
X-Mailer: git-send-email 2.17.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: xen-devel@lists.xenproject.org, pdurrant@amazon.com
Cc: jgross@suse.com, andrew.cooper3@citrix.com, pdurrant@amazon.com,
 marmarek@invisiblethingslab.com, hongyxia@amazon.com, jbeulich@suse.com,
 tamas.k.lengyel@gmail.com, roger.pau@citrix.com, dwmw@amazon.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

*** TWO WEEKS UNTIL LAST POSTING ***

This email only tracks big items for xen.git tree. Please reply for items
you would like to see in 4.14 so that people have an idea what
is going on and prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release about every 8
 months.
The critical dates for Xen 4.14 are as follows:

---> We are here
* Last posting date: May 1st, 2020
* Hard code freeze: May 22nd, 2020
* Release: June 26th, 2020

Note that we don't have a freeze exception scheme anymore. All patches
that wish to go into 4.14 must be posted initially no later than the
last posting date and finally no later than the hard code freeze.
All patches posted after that date will be automatically queued into next
release.

RCs will be arranged immediately after freeze.

There is also a jira instance to track all the tasks (not only big)
for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.

Some of the tasks tracked by this e-mail also have a corresponding jira task
referred by XEN-N.

There is a version number for patch series associated to each feature.
Can each owner send an update giving the latest version number if the
series has been re-posted? Also, can the owners of any completed items
please respond so that the item can be moved into the 'Completed' section.

= Projects =

== Hypervisor == 

*  Live-Updating Xen (RFC v2)
  -  David Woodhouse
  -  The latest code is available at https://xenbits.xen.org/gitweb/?p=people/dwmw2/xen.git;a=shortlog;h=refs/heads/lu-master
  -  Project wiki page at https://wiki.xenproject.org/wiki/Live-Updating_Xen

*  Non-Cooperative Live Migration
  -  Paul Durrant

*  Secret Hiding
  -  Hongyan Xia

*  Hypervisor file system (v7)
  -  Juergen Gross

=== x86 === 

*  Linux stub domains (v4)
  -  Marek Marczykowski-Górecki

*  Virtualise MSR_ARCH_CAPS for guests
  -  Andrew Cooper

*  AMD hardware mitigations (Rome)
  -  Andrew Cooper

*  Xen ioreq server (v3)
  -  Roger Pau Monne

*  Memory read caching in emulation (v5)
  -  Jan Beulich

*  Instruction emulator improvements
  -  Jan Beulich

*  VM forking (v11)
  -  Tamas K Lengyel

=== ARM === 

== Completed == 


Paul Durrant


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:31:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:31:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNLg-0006vi-K9; Fri, 17 Apr 2020 09:31:48 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPNLg-0006vd-1x
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:31:48 +0000
X-Inumbo-ID: 40d70c9a-808e-11ea-8c98-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 40d70c9a-808e-11ea-8c98-12813bfff9fa;
 Fri, 17 Apr 2020 09:31:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id EA740AED8;
 Fri, 17 Apr 2020 09:31:43 +0000 (UTC)
Subject: Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several
 people have reproduced
To: Jason Andryuk <jandryuk@gmail.com>
References: <cfbb5553-b9dc-ee86-145f-3cab92289c4d@suse.com>
 <20200317152310.114567-1-jandryuk@gmail.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7aca5da4-2ae5-8d3d-e7df-69eb7ffb743c@suse.com>
Date: Fri, 17 Apr 2020 11:31:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200317152310.114567-1-jandryuk@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: andrew.cooper3@citrix.com, aaron@ajanse.me, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.03.2020 16:23, Jason Andryuk wrote:
> Below is the diff.  It was messier and I tidied it up some.

I've looked into this some more. I can see how what we currently
do is not in line with firmware handing off with LegacyReplacement
mode enabled. However, this case doesn't look to apply here:

> It's mainly the change to hpet_resume() to mimic Linux's legacy HPET
> setup on T0.  It turns on HPET_CFG_LEGACY to ensure the timer interrupt
> is running.  And it also includes the printing of the initial HPET
> config:
> HPET_CFG 00000001

While HPET_CFG_ENABLE is set, HPET_CFG_LEGACY is clear.

> HPET_T0_CFG 00008030
> HPET_T0_ROUTE 0000016c

And while firmware must have setup FSB routing for T0, its enable
bits (both HPET_TN_ENABLE and HPET_TN_FSB) are also clear.
Therefore we have, afaics, no indication whatsoever that we ought
to enable LegacyReplacement mode. Of course the spec also says
"Assuming platform does not have 8254/RTC hardware or does not
want to support this legacy timer hardware, for this case, System
BIOS should set the LegacyReplacement Route bit and report IRQ0 &
IRQ8 as being consumed by the HPET block in system name space:"
(followed by a table). What is referred to as "system name space"
is, I assume, ACPI DSDT/SSDTs, which we have no access to this
early (and Linux doesn't either, aiui), so also can't be used as
indicator.

Otoh I also don't think it is correct to blindly enable
LegacyReplacement mode, like - afaics - Linux does, the more with
our split brain model as far as affected devices go (Xen "owns"
the PIT [and of course also the HPET], while Linux "owns" the
RTC). This is because of the effect of this setting on what
actually drives IRQ8. In theory we might be able do so when
ACPI_FADT_NO_CMOS_RTC is set, but Linux may use the CMOS RTC
even when that flag is set.

So right now the only possible approach I see to address your
problem is to add yet another fallback mode to check_timer(),
forcing LegacyReplacement mode to be enabled. But between /
after which step(s) to put this there isn't at all obvious to me.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:38:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNSA-00077S-Dl; Fri, 17 Apr 2020 09:38:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPNS9-00077N-P5
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:38:29 +0000
X-Inumbo-ID: 31374ccc-808f-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 31374ccc-808f-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 09:38:28 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 47E5FAD03;
 Fri, 17 Apr 2020 09:38:27 +0000 (UTC)
Subject: Re: [ANNOUNCE] Xen 4.14 Development Update
To: pdurrant@amazon.com, andrew.cooper3@citrix.com
References: <20200417091057.136-1-paul@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <15ddf257-adb3-9384-0b38-d5ecd568746b@suse.com>
Date: Fri, 17 Apr 2020 11:38:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417091057.136-1-paul@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 11:10, Paul Durrant wrote:
> *  Memory read caching in emulation (v5)
>   -  Jan Beulich

I'd like to take this as an opportunity to ask on the disposition
of this series: Under the new rules in principle I could have put
this in with Paul's R-b, but given the prior discussions I didn't
want to do so without at least an informal okay from you, Andrew.
Now that the sending of v5 as well as Paul's reviewing of it is 6
weeks back, I guess unless I hear otherwise pretty soon I'm going
to commit the remaining 3 patches some time next week.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:45:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNYS-0007xF-AC; Fri, 17 Apr 2020 09:45:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPNYQ-0007xA-QQ
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:44:58 +0000
X-Inumbo-ID: 1954cc96-8090-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1954cc96-8090-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 09:44:58 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2A21BAD45;
 Fri, 17 Apr 2020 09:44:56 +0000 (UTC)
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
To: Julien Grall <julien@xen.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
 <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
Date: Fri, 17 Apr 2020 11:44:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 10:37, Julien Grall wrote:
> On 16/04/2020 16:46, Jan Beulich wrote:
>> While it should have been this way from the beginning, not doing so will
>> become an actual problem with PVH Dom0.
> 
> I think the current code is also buggy on PV dom0 because the buffer
> is not locked in memory. So you have no promise the buffer will be
> present when calling the hypercall.

Quite possibly; I didn't looks at that aspect at all.

>> --- a/tools/libxc/xc_mem_paging.c
>> +++ b/tools/libxc/xc_mem_paging.c
>> @@ -26,15 +26,33 @@ static int xc_mem_paging_memop(xc_interf
>>                                  unsigned int op, uint64_t gfn, void *buffer)
> 
> NIT: As you switch the handle to use const, would it make to also
> make the buffer const?

A separate change, I would say, but if the tool stack maintainers
agree with doing so at the same time, I certainly can.

>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1779,7 +1779,8 @@ void p2m_mem_paging_populate(struct doma
>>    * mfn if populate was called for  gfn which was nominated but not evicted. In
>>    * this case only the p2mt needs to be forwarded.
>>    */
>> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l, uint64_t buffer)
>> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l,
>> +                        XEN_GUEST_HANDLE_PARAM(const_uint8) buffer)
> 
> Shouldn't this technically be XEN_GUEST_HANDLE_64() to match the field?

I think an argument can be made for going either way - as a function
parameter it should have the type chosen. Do you see any (possibly
just latent) breakage from using _PARAM() rather than _64()?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:52:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:52:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNfc-0000LT-Dh; Fri, 17 Apr 2020 09:52:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lM+k=6B=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jPNfb-0000LM-40
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:52:23 +0000
X-Inumbo-ID: 226fb0b0-8091-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 226fb0b0-8091-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 09:52:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=7I49opomVxvB6V8PzhNVtuuo+Ifnpql27GLDjPB32Kw=; b=U/vQRxFirIgOsjhpUeE1YKAn/1
 ioly0B4M83S0EK0PELN1eGIbRSPaod2Z1wJwZzJvz4kK+YGbQGqQ/dmAUfaydE8dBlSU3HiS2UW7S
 nBlomGh2Ejn/9aVTANwypSQcq2bKlplr6hG/Vl6S8f1o7Wo/wazxJ0ri8nM7jf2wDYz4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfa-0002fp-2R; Fri, 17 Apr 2020 09:52:22 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfZ-000304-Os; Fri, 17 Apr 2020 09:52:22 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 3/6] x86_64/mm: map and unmap page tables in subarch_memory_op
Date: Fri, 17 Apr 2020 10:52:05 +0100
Message-Id: <1c88c785eb9537983a1692cc379604233ff13025.1587116799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/x86_64/mm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 5714e5ba62..6d52183559 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -932,13 +932,13 @@ long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
               (v < (unsigned long)(machine_to_phys_mapping + max_page));
               i++, v += 1UL << L2_PAGETABLE_SHIFT )
         {
-            l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-                l3_table_offset(v)];
+            l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+                               l3_table_offset(v));
             if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
                 mfn = last_mfn;
             else if ( !(l3e_get_flags(l3e) & _PAGE_PSE) )
             {
-                l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+                l2e = l2e_from_l3e(l3e, l2_table_offset(v));
                 if ( l2e_get_flags(l2e) & _PAGE_PRESENT )
                     mfn = l2e_get_pfn(l2e);
                 else
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:52:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:52:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNfa-0000LG-43; Fri, 17 Apr 2020 09:52:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lM+k=6B=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jPNfY-0000LB-4z
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:52:20 +0000
X-Inumbo-ID: 1fe8cef8-8091-11ea-8c9b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1fe8cef8-8091-11ea-8c9b-12813bfff9fa;
 Fri, 17 Apr 2020 09:52:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=gV81cHJB3NZq+lqurKfDaoiAVy854Zr2arns+wuToNI=; b=mhZSOZ4IwsHnwFLpOcCVHtmPrr
 aHY6Op4ptWnC/wlWbnydJa0nYfDC6VJElOIKbkXRHTmVWriF0f3akPKWfOrSgd3F3S+hh0eRk36qc
 oB29a46rh8ZF783cNUP1vnkkRN/7fwk3IE0WaiMezwB9vcmOrzPFvH3+7J22H9uZt36E=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfV-0002fY-QD; Fri, 17 Apr 2020 09:52:17 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfV-000304-FW; Fri, 17 Apr 2020 09:52:17 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/6] convert more Xen page table code to the new API
Date: Fri, 17 Apr 2020 10:52:02 +0100
Message-Id: <cover.1587116799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

Basically just rewriting functions using the new API to map and unmap
PTEs. Each patch is independent.

Apart from mapping and unmapping page tables, no other functional change
intended.

Wei Liu (6):
  x86_64/mm: map and unmap page tables in cleanup_frame_table
  x86_64/mm: map and unmap page tables in subarch_init_memory
  x86_64/mm: map and unmap page tables in subarch_memory_op
  x86/smpboot: map and unmap page tables in cleanup_cpu_root_pgt
  x86/pv: map and unmap page tables in mark_pv_pt_pages_rdonly
  x86/pv: map and unmap page table in dom0_construct_pv

 xen/arch/x86/pv/dom0_build.c | 38 ++++++++++++++++++++++++------------
 xen/arch/x86/smpboot.c       | 25 ++++++++++++++++--------
 xen/arch/x86/x86_64/mm.c     | 32 +++++++++++++++---------------
 3 files changed, 58 insertions(+), 37 deletions(-)

-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:52:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:52:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNfe-0000M6-Nm; Fri, 17 Apr 2020 09:52:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lM+k=6B=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jPNfd-0000Lc-0p
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:52:25 +0000
X-Inumbo-ID: 2030b313-8091-11ea-8c9b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2030b313-8091-11ea-8c9b-12813bfff9fa;
 Fri, 17 Apr 2020 09:52:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=fgPHa6/lewyPUGLpvLuUr7Qnl8FXYus9SeBUggwCmRY=; b=fsoDzbLe09VaPA4VGTGG/T2hUA
 ng16FFZwNw0bU5Df2LGAgfBie/sIqtw/GHzip1fzwercdIajGh2lUi7UvIwZvPcWUSzbZpRQ+4sr2
 JC12EYZYIOBOWUlpfl1yhEqZxMD+E54kgExpa6CVvZy3QCRiEiQ/dvIiOVgsZM4x9HFo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfX-0002fd-9o; Fri, 17 Apr 2020 09:52:19 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfW-000304-TS; Fri, 17 Apr 2020 09:52:19 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 1/6] x86_64/mm: map and unmap page tables in
 cleanup_frame_table
Date: Fri, 17 Apr 2020 10:52:03 +0100
Message-Id: <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Also fix a weird indentation.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/x86_64/mm.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index e85ef449f3..18210405f4 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -737,8 +737,8 @@ static void cleanup_frame_table(struct mem_hotadd_info *info)
 
     while (sva < eva)
     {
-        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(sva)])[
-          l3_table_offset(sva)];
+        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(sva)],
+                           l3_table_offset(sva));
         if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) ||
              (l3e_get_flags(l3e) & _PAGE_PSE) )
         {
@@ -747,7 +747,7 @@ static void cleanup_frame_table(struct mem_hotadd_info *info)
             continue;
         }
 
-        l2e = l3e_to_l2e(l3e)[l2_table_offset(sva)];
+        l2e = l2e_from_l3e(l3e, l2_table_offset(sva));
         ASSERT(l2e_get_flags(l2e) & _PAGE_PRESENT);
 
         if ( (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) ==
@@ -763,10 +763,10 @@ static void cleanup_frame_table(struct mem_hotadd_info *info)
             continue;
         }
 
-        ASSERT(l1e_get_flags(l2e_to_l1e(l2e)[l1_table_offset(sva)]) &
-                _PAGE_PRESENT);
-         sva = (sva & ~((1UL << PAGE_SHIFT) - 1)) +
-                    (1UL << PAGE_SHIFT);
+        ASSERT(l1e_get_flags(l1e_from_l2e(l2e, l1_table_offset(sva))) &
+               _PAGE_PRESENT);
+
+        sva = (sva & ~((1UL << PAGE_SHIFT) - 1)) + (1UL << PAGE_SHIFT);
     }
 
     /* Brute-Force flush all TLB */
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:52:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNfh-0000Mq-18; Fri, 17 Apr 2020 09:52:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lM+k=6B=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jPNfg-0000Me-1B
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:52:28 +0000
X-Inumbo-ID: 241c2132-8091-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 241c2132-8091-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 09:52:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=3PKlc7n3xS/jV0u6XuY6+PkL5866S2noi39EkmZJHLk=; b=6Wg/PSgPxch2MIXxZCIZTcAGU2
 e+xUte2YS7ssUZFYv3wFEa/duhWo1Ggen13MRH11jSCORyfcUeRbyKWsDQDL6mNvXVJ1/HexFz1DW
 fygtm8y+pMpFDHAveHIAoqHwbPYOc4iAYVihpCinG71neeIk6++Dvyj3pRxvpxhj1a3U=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfc-0002g2-TE; Fri, 17 Apr 2020 09:52:24 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfc-000304-Ju; Fri, 17 Apr 2020 09:52:24 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
Date: Fri, 17 Apr 2020 10:52:07 +0100
Message-Id: <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/pv/dom0_build.c | 32 ++++++++++++++++++++------------
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 5678da782d..28a939b68a 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -50,17 +50,17 @@ static __init void mark_pv_pt_pages_rdonly(struct domain *d,
     unsigned long count;
     struct page_info *page;
     l4_pgentry_t *pl4e;
-    l3_pgentry_t *pl3e;
-    l2_pgentry_t *pl2e;
-    l1_pgentry_t *pl1e;
+    l3_pgentry_t *pl3e, *l3t;
+    l2_pgentry_t *pl2e, *l2t;
+    l1_pgentry_t *pl1e, *l1t;
 
     pl4e = l4start + l4_table_offset(vpt_start);
-    pl3e = l4e_to_l3e(*pl4e);
-    pl3e += l3_table_offset(vpt_start);
-    pl2e = l3e_to_l2e(*pl3e);
-    pl2e += l2_table_offset(vpt_start);
-    pl1e = l2e_to_l1e(*pl2e);
-    pl1e += l1_table_offset(vpt_start);
+    l3t = map_l3t_from_l4e(*pl4e);
+    pl3e = l3t + l3_table_offset(vpt_start);
+    l2t = map_l2t_from_l3e(*pl3e);
+    pl2e = l2t + l2_table_offset(vpt_start);
+    l1t = map_l1t_from_l2e(*pl2e);
+    pl1e = l1t + l1_table_offset(vpt_start);
     for ( count = 0; count < nr_pt_pages; count++ )
     {
         l1e_remove_flags(*pl1e, _PAGE_RW);
@@ -85,12 +85,20 @@ static __init void mark_pv_pt_pages_rdonly(struct domain *d,
             if ( !((unsigned long)++pl2e & (PAGE_SIZE - 1)) )
             {
                 if ( !((unsigned long)++pl3e & (PAGE_SIZE - 1)) )
-                    pl3e = l4e_to_l3e(*++pl4e);
-                pl2e = l3e_to_l2e(*pl3e);
+                {
+                    unmap_domain_page(l3t);
+                    pl3e = l3t = map_l3t_from_l4e(*++pl4e);
+                }
+                unmap_domain_page(l2t);
+                pl2e = l2t = map_l2t_from_l3e(*pl3e);
             }
-            pl1e = l2e_to_l1e(*pl2e);
+            unmap_domain_page(l1t);
+            pl1e = l1t = map_l1t_from_l2e(*pl2e);
         }
     }
+    unmap_domain_page(l1t);
+    unmap_domain_page(l2t);
+    unmap_domain_page(l3t);
 }
 
 static __init void setup_pv_physmap(struct domain *d, unsigned long pgtbl_pfn,
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:52:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNfj-0000Nv-An; Fri, 17 Apr 2020 09:52:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lM+k=6B=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jPNfi-0000NQ-0x
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:52:30 +0000
X-Inumbo-ID: 21d23984-8091-11ea-8c9b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 21d23984-8091-11ea-8c9b-12813bfff9fa;
 Fri, 17 Apr 2020 09:52:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tEeVOsGMSDjBCM+osSPHmTi/618O72vOFb/JLOuqfjw=; b=FPk6Z1cKcufcm78XCUmuoAsxxg
 NB3bUWLYiTVSS/9IGOxLLksT8xkRnHri/hH9X25+ldy7DqY3dAxpaUOvJy/7srSgxcNkRUC8X6CIT
 qf0PaoDxzvVgRwDGesPf3H/FRcBDOLUa/0Pm4j8vLlNFK0NeMdi+zzvlyjh2PVzilojw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfY-0002fk-Lb; Fri, 17 Apr 2020 09:52:20 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfY-000304-B3; Fri, 17 Apr 2020 09:52:20 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 2/6] x86_64/mm: map and unmap page tables in
 subarch_init_memory
Date: Fri, 17 Apr 2020 10:52:04 +0100
Message-Id: <0e14533f516ee5ce410e2cd8050f085aec4b4961.1587116799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/x86_64/mm.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 18210405f4..5714e5ba62 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -852,14 +852,14 @@ void __init subarch_init_memory(void)
           v += n << PAGE_SHIFT )
     {
         n = L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES;
-        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-            l3_table_offset(v)];
+        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+                           l3_table_offset(v));
         if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
             continue;
         if ( !(l3e_get_flags(l3e) & _PAGE_PSE) )
         {
             n = L1_PAGETABLE_ENTRIES;
-            l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+            l2e = l2e_from_l3e(l3e, l2_table_offset(v));
             if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
                 continue;
             m2p_start_mfn = l2e_get_pfn(l2e);
@@ -878,11 +878,11 @@ void __init subarch_init_memory(void)
           v != RDWR_COMPAT_MPT_VIRT_END;
           v += 1 << L2_PAGETABLE_SHIFT )
     {
-        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-            l3_table_offset(v)];
+        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+                           l3_table_offset(v));
         if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
             continue;
-        l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+        l2e = l2e_from_l3e(l3e, l2_table_offset(v));
         if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
             continue;
         m2p_start_mfn = l2e_get_pfn(l2e);
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:52:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:52:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNfn-0000Qx-KK; Fri, 17 Apr 2020 09:52:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lM+k=6B=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jPNfn-0000Qc-18
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:52:35 +0000
X-Inumbo-ID: 232cfa12-8091-11ea-8c9b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 232cfa12-8091-11ea-8c9b-12813bfff9fa;
 Fri, 17 Apr 2020 09:52:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=TtfDNJhA8tjoCGd8nfl59DQgpyHwzck4uvav7srJyZM=; b=g3HnPNSWrF201Ln96S0X0V/JcW
 wroUnjXehYGLMAV4J6FGf/LZz+Cb5M0eHPm7Uit2Ahbyyp080Cd7ak33v8QUeCSxka8THYJSgwbB7
 hXKpv/5fMSRJbedRVuycqIxJJdh5+Ckl6+oU+foZDHO9fLzjdIRZ6B0GGPM0rRpGRNSk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfb-0002fw-Fo; Fri, 17 Apr 2020 09:52:23 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfb-000304-6P; Fri, 17 Apr 2020 09:52:23 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 4/6] x86/smpboot: map and unmap page tables in
 cleanup_cpu_root_pgt
Date: Fri, 17 Apr 2020 10:52:06 +0100
Message-Id: <bc0ad02ad73ac3f02e063457d69634b1f6b57ddc.1587116799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/smpboot.c | 25 +++++++++++++++++--------
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 09264b02d1..275ce7661d 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -858,23 +858,27 @@ static void cleanup_cpu_root_pgt(unsigned int cpu)
           r < root_table_offset(HYPERVISOR_VIRT_END); ++r )
     {
         l3_pgentry_t *l3t;
+        mfn_t l3mfn;
         unsigned int i3;
 
         if ( !(root_get_flags(rpt[r]) & _PAGE_PRESENT) )
             continue;
 
-        l3t = l4e_to_l3e(rpt[r]);
+        l3mfn = l4e_get_mfn(rpt[r]);
+        l3t = map_domain_page(l3mfn);
 
         for ( i3 = 0; i3 < L3_PAGETABLE_ENTRIES; ++i3 )
         {
             l2_pgentry_t *l2t;
+            mfn_t l2mfn;
             unsigned int i2;
 
             if ( !(l3e_get_flags(l3t[i3]) & _PAGE_PRESENT) )
                 continue;
 
             ASSERT(!(l3e_get_flags(l3t[i3]) & _PAGE_PSE));
-            l2t = l3e_to_l2e(l3t[i3]);
+            l2mfn = l3e_get_mfn(l3t[i3]);
+            l2t = map_domain_page(l2mfn);
 
             for ( i2 = 0; i2 < L2_PAGETABLE_ENTRIES; ++i2 )
             {
@@ -882,13 +886,15 @@ static void cleanup_cpu_root_pgt(unsigned int cpu)
                     continue;
 
                 ASSERT(!(l2e_get_flags(l2t[i2]) & _PAGE_PSE));
-                free_xen_pagetable(l2e_to_l1e(l2t[i2]));
+                free_xen_pagetable_new(l2e_get_mfn(l2t[i2]));
             }
 
-            free_xen_pagetable(l2t);
+            unmap_domain_page(l2t);
+            free_xen_pagetable_new(l2mfn);
         }
 
-        free_xen_pagetable(l3t);
+        unmap_domain_page(l3t);
+        free_xen_pagetable_new(l3mfn);
     }
 
     free_xen_pagetable(rpt);
@@ -896,11 +902,14 @@ static void cleanup_cpu_root_pgt(unsigned int cpu)
     /* Also zap the stub mapping for this CPU. */
     if ( stub_linear )
     {
-        l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
-        l2_pgentry_t *l2t = l3e_to_l2e(l3t[l3_table_offset(stub_linear)]);
-        l1_pgentry_t *l1t = l2e_to_l1e(l2t[l2_table_offset(stub_linear)]);
+        l3_pgentry_t l3e = l3e_from_l4e(common_pgt,
+                                        l3_table_offset(stub_linear));
+        l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(stub_linear));
+        l1_pgentry_t *l1t = map_l1t_from_l2e(l2e);
 
         l1t[l1_table_offset(stub_linear)] = l1e_empty();
+
+        unmap_domain_page(l1t);
     }
 }
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 09:52:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 09:52:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNft-0000UJ-3c; Fri, 17 Apr 2020 09:52:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=lM+k=6B=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jPNfs-0000Tf-1F
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 09:52:40 +0000
X-Inumbo-ID: 24f1209e-8091-11ea-8c9b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 24f1209e-8091-11ea-8c9b-12813bfff9fa;
 Fri, 17 Apr 2020 09:52:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Dfu+OgKnJzFWoXe/gPFe0obtWomHwJiB46S0uhovLc0=; b=D3+GJWuLGIwR19dKVk0QfvNpEP
 cq5z41eQ+J/4T7c2UgY0l1mUsBfDgyPYxRoCHvFEVty/RdmTdnBAeHoDv2QLHpo989tqmXDP8/zq8
 aqAaX/Nm3UKdNTMnSmr4X/cLjNmWJY6ox7HCtSFN9clvlm85ITsPGB8cccDyzXW+xf+w=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfe-0002g8-Aj; Fri, 17 Apr 2020 09:52:26 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jPNfe-000304-15; Fri, 17 Apr 2020 09:52:26 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 6/6] x86/pv: map and unmap page table in dom0_construct_pv
Date: Fri, 17 Apr 2020 10:52:08 +0100
Message-Id: <18fda6bdeb4f20bf2272503e45c7c420e51673ac.1587116799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/pv/dom0_build.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 28a939b68a..a03f0501ab 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -677,6 +677,8 @@ int __init dom0_construct_pv(struct domain *d,
 
     if ( is_pv_32bit_domain(d) )
     {
+        l2_pgentry_t *l2t;
+
         /* Ensure the first four L3 entries are all populated. */
         for ( i = 0, l3tab = l3start; i < 4; ++i, ++l3tab )
         {
@@ -691,7 +693,9 @@ int __init dom0_construct_pv(struct domain *d,
                 l3e_get_page(*l3tab)->u.inuse.type_info |= PGT_pae_xen_l2;
         }
 
-        init_xen_pae_l2_slots(l3e_to_l2e(l3start[3]), d);
+        l2t = map_l2t_from_l3e(l3start[3]);
+        init_xen_pae_l2_slots(l2t, d);
+        unmap_domain_page(l2t);
     }
 
     /* Pages that are part of page tables must be read only. */
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 10:02:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 10:02:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNpE-0001rs-4M; Fri, 17 Apr 2020 10:02:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPNpC-0001rn-BK
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 10:02:18 +0000
X-Inumbo-ID: 84ed83e2-8092-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 84ed83e2-8092-11ea-83d8-bc764e2007e4;
 Fri, 17 Apr 2020 10:02:17 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CFB98ADBB;
 Fri, 17 Apr 2020 10:02:15 +0000 (UTC)
Subject: Re: [PATCH 04/12] xen: split alloc_heap_pages in two halves for
 reusability
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-4-sstabellini@kernel.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <348994e9-7b32-33fc-0e40-f7e1a6543b92@suse.com>
Date: Fri, 17 Apr 2020 12:02:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-4-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 03:02, Stefano Stabellini wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -911,54 +911,18 @@ static struct page_info *get_free_buddy(unsigned int zone_lo,
>      }
>  }
>  
> -/* Allocate 2^@order contiguous pages. */
> -static struct page_info *alloc_heap_pages(
> -    unsigned int zone_lo, unsigned int zone_hi,
> -    unsigned int order, unsigned int memflags,
> -    struct domain *d)
> +static void __alloc_heap_pages(struct page_info **pgo,
> +                               unsigned int order,
> +                               unsigned int memflags,
> +                               struct domain *d)

Along the line of Wei's reply, I'd suggest the name to better reflect
the difference to alloc_heap_pages() itself. Maybe
alloc_pages_from_buddy() or alloc_buddy_pages()?

In addition
- no double leading underscores please
- instead of the function returning void and taking
  struct page_info **pgo, why not have it take and return
  struct page_info *?
- add a comment about the non-standard locking behavior

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 10:11:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 10:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPNy0-0002jZ-40; Fri, 17 Apr 2020 10:11:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPNxy-0002jU-K2
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 10:11:22 +0000
X-Inumbo-ID: c955db0a-8093-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c955db0a-8093-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 10:11:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id EABB6B031;
 Fri, 17 Apr 2020 10:11:19 +0000 (UTC)
Subject: Re: [PATCH 05/12] xen: introduce reserve_heap_pages
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-5-sstabellini@kernel.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3129ab49-5898-9d2e-8fbb-d1fcaf6cdec7@suse.com>
Date: Fri, 17 Apr 2020 12:11:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415010255.10081-5-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 03:02, Stefano Stabellini wrote:
> Introduce a function named reserve_heap_pages (similar to
> alloc_heap_pages) that allocates a requested memory range. Call
> __alloc_heap_pages for the implementation.
> 
> Change __alloc_heap_pages so that the original page doesn't get
> modified, giving back unneeded memory top to bottom rather than bottom
> to top.

While it may be less of a problem within a zone, doing so is
against our general "return high pages first" policy.

> @@ -1073,7 +1073,42 @@ static struct page_info *alloc_heap_pages(
>          return NULL;
>      }
>  
> -    __alloc_heap_pages(&pg, order, memflags, d);
> +    __alloc_heap_pages(pg, order, memflags, d);
> +    return pg;
> +}
> +
> +static struct page_info *reserve_heap_pages(struct domain *d,
> +                                            paddr_t start,
> +                                            unsigned int order,
> +                                            unsigned int memflags)
> +{
> +    nodeid_t node;
> +    unsigned int zone;
> +    struct page_info *pg;
> +
> +    if ( unlikely(order > MAX_ORDER) )
> +        return NULL;
> +
> +    spin_lock(&heap_lock);
> +
> +    /*
> +     * Claimed memory is considered unavailable unless the request
> +     * is made by a domain with sufficient unclaimed pages.
> +     */
> +    if ( (outstanding_claims + (1UL << order) > total_avail_pages) &&
> +          ((memflags & MEMF_no_refcount) ||
> +           !d || d->outstanding_pages < (1UL << order)) )
> +    {
> +        spin_unlock(&heap_lock);
> +        return NULL;
> +    }

Where would such a claim come from? Given the purpose I'd assume
the function (as well as reserve_domheap_pages()) can actually be
__init. With that I'd then also be okay with them getting built
unconditionally, i.e. even on x86.

> +    pg = maddr_to_page(start);
> +    node = phys_to_nid(start);
> +    zone = page_to_zone(pg);
> +    page_list_del(pg, &heap(node, zone, order));
> +
> +    __alloc_heap_pages(pg, order, memflags, d);

I agree with Julien in not seeing how this can be safe / correct.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 10:27:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 10:27:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPODR-0003hM-JF; Fri, 17 Apr 2020 10:27:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=u48u=6B=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jPODQ-0003hH-7x
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 10:27:20 +0000
X-Inumbo-ID: 03fddcb0-8096-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 03fddcb0-8096-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 10:27:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587119240;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=sVPQ2SfLGHhnQ75gorUBD/BFheC45NpGFyA7/hVH80g=;
 b=QUD4sVjrKrmGw/a/8j8DcI51JlKHjQPhjFfx9/2bFb7m3Vh1gM/ZoKiN
 mymtcQgyKEi8+PUD80IJ+oO4V/0lszxI4mUZW376Fubb7kCjelzWRlCB0
 Tbq3amPUH61ypM2Kr2ndbhGJsjDyypwTqIX1wZBrV0Tyv/1g+2N7ST3DM M=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: cePuOYDmdm5/Pgnbv1jlPgu1sHgz9zd4iFc7HIXBmqej2663EsG6NJFNcqsLtDA1ygN9qIOKSE
 p6E19Y9mN7o5NGoiO6W2Z67TmdVyQxThmlWgmjvb4HzNkqGoLOwrRHk2QPBOCSgmoOWVaXd9Pl
 Uc+u31tvspFa4qPzvOdcayCkDi9uGoDNGUx70y4bAaJHKe9QPjChtiIYdAdpxRsNWyFKK3l3Up
 TNOdgsHDWRKrFFW6gNwEIlZ3oVLdUO+URLzIM5i+N981zwElqdMfwABeDz7MGzp5mVbkTeXG/K
 HHA=
X-SBRS: 2.7
X-MesageID: 15848747
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,394,1580792400"; d="scan'208";a="15848747"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/vtd: fix EPT page table sharing check
Date: Fri, 17 Apr 2020 12:26:50 +0200
Message-ID: <20200417102650.20083-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The EPT page tables can be shared with the IOMMU as long as the page
sizes supported by EPT are also supported by the IOMMU.

Current code checks that both the IOMMU and EPT support the same page
sizes, but this is not strictly required, the IOMMU supporting more
page sizes than EPT is fine and shouldn't block page sharing.

This is likely not a common case (IOMMU supporting more page sizes
than EPT), but should still be fixed for correctness.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/drivers/passthrough/vtd/iommu.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 07d40b37fe..63298d3a99 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1914,8 +1914,10 @@ static int __init vtd_ept_page_compatible(struct vtd_iommu *iommu)
     if ( rdmsr_safe(MSR_IA32_VMX_EPT_VPID_CAP, ept_cap) != 0 ) 
         return 0;
 
-    return (ept_has_2mb(ept_cap) && opt_hap_2mb) == cap_sps_2mb(vtd_cap) &&
-           (ept_has_1gb(ept_cap) && opt_hap_1gb) == cap_sps_1gb(vtd_cap);
+    return ((ept_has_2mb(ept_cap) && opt_hap_2mb) ? cap_sps_2mb(vtd_cap)
+                                                  : true) &&
+           ((ept_has_1gb(ept_cap) && opt_hap_1gb) ? cap_sps_1gb(vtd_cap)
+                                                  : true);
 }
 
 /*
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 10:57:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 10:57:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPOgX-000683-0a; Fri, 17 Apr 2020 10:57:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPOgV-00067y-F8
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 10:57:23 +0000
X-Inumbo-ID: 36cb8d50-809a-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 36cb8d50-809a-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 10:57:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 19B07AD33;
 Fri, 17 Apr 2020 10:57:21 +0000 (UTC)
Subject: Re: [PATCH] x86/vtd: fix EPT page table sharing check
To: Roger Pau Monne <roger.pau@citrix.com>
References: <20200417102650.20083-1-roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <c3589851-7084-e3a4-f776-6157bc4de762@suse.com>
Date: Fri, 17 Apr 2020 12:57:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417102650.20083-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Kevin Tian <kevin.tian@intel.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 12:26, Roger Pau Monne wrote:
> The EPT page tables can be shared with the IOMMU as long as the page
> sizes supported by EPT are also supported by the IOMMU.
> 
> Current code checks that both the IOMMU and EPT support the same page
> sizes, but this is not strictly required, the IOMMU supporting more
> page sizes than EPT is fine and shouldn't block page sharing.

Meaning the check isn't wrong, just too strict. Hence maybe
"relax" instead of "fix" in the subject?

Also "... page table sharing."

> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1914,8 +1914,10 @@ static int __init vtd_ept_page_compatible(struct vtd_iommu *iommu)
>      if ( rdmsr_safe(MSR_IA32_VMX_EPT_VPID_CAP, ept_cap) != 0 ) 
>          return 0;
>  
> -    return (ept_has_2mb(ept_cap) && opt_hap_2mb) == cap_sps_2mb(vtd_cap) &&
> -           (ept_has_1gb(ept_cap) && opt_hap_1gb) == cap_sps_1gb(vtd_cap);
> +    return ((ept_has_2mb(ept_cap) && opt_hap_2mb) ? cap_sps_2mb(vtd_cap)
> +                                                  : true) &&
> +           ((ept_has_1gb(ept_cap) && opt_hap_1gb) ? cap_sps_1gb(vtd_cap)
> +                                                  : true);

I have to admit that I always find it odd to have "true" or "false"
as the 2nd or 3rd operand of a ternary. How about simply changing
== to <= in the original expression?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 11:17:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 11:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPOzJ-0007o7-KL; Fri, 17 Apr 2020 11:16:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=u48u=6B=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jPOzH-0007o2-U8
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 11:16:47 +0000
X-Inumbo-ID: ece88bfe-809c-11ea-b4f4-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ece88bfe-809c-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 11:16:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587122207;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=djCXv7uCk7fv9Jjx0UeSVQ2MPe/pxjEJjsO5csnrEiA=;
 b=Lfdj7RvSDVh//3fwKCwRPjaJGj71q6WjA0itqkKgbyOB6w3n4WVFOQWh
 T1wbc5Mx/MbifqkaljblrsJoe3/ZaaT4dagnoCVP5MfGO5ntFjZBmJ3cZ
 kgckTParPqwcja3osP6MXfMK9FKBQ+KOSh6BDNGAKYhHzQAVp4tGfU2L6 U=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Cem/JgwjjFgPDmr4oDeCMYlVydC6h3Zfd4VaHW6bjc99xKtOEWO0W3niN3xtgn1O5HI+BMAEWU
 yHQjOFS7bFCS1IaWH97+JBRKeq+sX9weafjFVOlbDWRrQMHMaCFvayBv/ltNG505bW6y0B1nkI
 L/NOFL46LjXjcJfjsoF0DlFqANJFEKMH3vbwUgeKGFmcQr1NNNmc6r359BBh1hro+3QVb7PINB
 UKiYaVOZ35VsEjUkKRqIL9i5TtQqMiCGjCJtCwkCrR3YcyyJoWmjkAcYpwpU0pNq8zQzLpYqMb
 xdc=
X-SBRS: 2.7
X-MesageID: 16238159
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,394,1580792400"; d="scan'208";a="16238159"
Date: Fri, 17 Apr 2020 13:16:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86/vtd: fix EPT page table sharing check
Message-ID: <20200417111637.GP28601@Air-de-Roger>
References: <20200417102650.20083-1-roger.pau@citrix.com>
 <c3589851-7084-e3a4-f776-6157bc4de762@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <c3589851-7084-e3a4-f776-6157bc4de762@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Kevin Tian <kevin.tian@intel.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 12:57:16PM +0200, Jan Beulich wrote:
> On 17.04.2020 12:26, Roger Pau Monne wrote:
> > The EPT page tables can be shared with the IOMMU as long as the page
> > sizes supported by EPT are also supported by the IOMMU.
> > 
> > Current code checks that both the IOMMU and EPT support the same page
> > sizes, but this is not strictly required, the IOMMU supporting more
> > page sizes than EPT is fine and shouldn't block page sharing.
> 
> Meaning the check isn't wrong, just too strict. Hence maybe
> "relax" instead of "fix" in the subject?
> 
> Also "... page table sharing."

Sure.

> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -1914,8 +1914,10 @@ static int __init vtd_ept_page_compatible(struct vtd_iommu *iommu)
> >      if ( rdmsr_safe(MSR_IA32_VMX_EPT_VPID_CAP, ept_cap) != 0 ) 
> >          return 0;
> >  
> > -    return (ept_has_2mb(ept_cap) && opt_hap_2mb) == cap_sps_2mb(vtd_cap) &&
> > -           (ept_has_1gb(ept_cap) && opt_hap_1gb) == cap_sps_1gb(vtd_cap);
> > +    return ((ept_has_2mb(ept_cap) && opt_hap_2mb) ? cap_sps_2mb(vtd_cap)
> > +                                                  : true) &&
> > +           ((ept_has_1gb(ept_cap) && opt_hap_1gb) ? cap_sps_1gb(vtd_cap)
> > +                                                  : true);
> 
> I have to admit that I always find it odd to have "true" or "false"
> as the 2nd or 3rd operand of a ternary. How about simply changing
> == to <= in the original expression?

I find it weird to use <= to compare booleans, but I can change it.
Let me post a new version with the adjustments to the commit message
and this requested change.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 11:22:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 11:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPP4j-0000A4-A3; Fri, 17 Apr 2020 11:22:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPP4i-00009z-9B
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 11:22:24 +0000
X-Inumbo-ID: b554c77e-809d-11ea-8cb9-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b554c77e-809d-11ea-8cb9-12813bfff9fa;
 Fri, 17 Apr 2020 11:22:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2wvFEs/cXe2NZ9sAEGDYQy42aC5FCH3HhuX61osEIeo=; b=03PCWeGnbFIk7r/zPlEf6hMw/
 A2G2xVEd8wLRX+ifrnRlODrbOaPenA7gkapQQDfd6Oh3y8fF7A3ysaPRXM0GEYVaLkC1rMJyM8zj9
 51lWJ+PbCvXyFSvEt5gZMTOFBwUYOQKrBrstVVrdofVyr1cpr2XmR1rU2eB93rmk8zeMw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPP4g-0004UG-Lk; Fri, 17 Apr 2020 11:22:22 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPP4g-00016o-Cw; Fri, 17 Apr 2020 11:22:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPP4g-0007YC-As; Fri, 17 Apr 2020 11:22:22 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149699-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149699: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
X-Osstest-Versions-That: xen=a48e1323f9aa29f1ffb95594671b73de6bd7c1d4
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 11:22:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
baseline version:
 xen                  a48e1323f9aa29f1ffb95594671b73de6bd7c1d4

Last test of basis   149688  2020-04-16 12:01:12 Z    0 days
Testing same since   149699  2020-04-17 08:00:46 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dfaggioli@suse.com>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Sergey Dyasli <sergey.dyasli@citrix.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   a48e1323f9..82dd1a956d  82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638 -> smoke


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 11:30:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 11:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPPCN-000123-Am; Fri, 17 Apr 2020 11:30:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=u48u=6B=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jPPCL-00011y-J2
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 11:30:17 +0000
X-Inumbo-ID: ced242de-809e-11ea-8cbb-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ced242de-809e-11ea-8cbb-12813bfff9fa;
 Fri, 17 Apr 2020 11:30:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587123016;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=AvVKH8/nmaAKkcfNP9IppKatqInv4zImFWpcshcgltQ=;
 b=NXJyWdMEVwWlW4Msgd3CI81CMXpUgOThN6lp6mhgAMqfG61CyJrGTAYy
 88SKs5yMACkZbzg3xDaAdyI5F+Jk3x+XyrDSsLIhRzIrnniaZCM8bHfS2
 YXTMkdDMNDn/csqRziUtedilGxp4Ln0y406Yy/gcBB3cZFv5XHSIPogsq M=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: PIw3IpUuYKYIREodqPJr4JplEjMBLctkfo0zVxZGL5y2d2BfbDS/EhAIS8QYLq0pIpxYqnMSwz
 SAAFDuxvgI6OpH4+OEYnD0qDQOHDqc3cUjC7++sGGCtl4gNghfqFB/vI4eM7qB18Npz5IWO8pI
 wrGhJwIVo3/W6yZMGWE/JbllCPyFy9YCcq3AT21rXXpu0xumWTL2cn1i5NFjNMPu71qkIq6/O3
 6HOQKSaPtIorXiHFdmKecKAlS8iiYpRB3FxCqKWvPJWvXM1dp1BmHJ4qpE/GniajK80zyD4rBm
 XRE=
X-SBRS: 2.7
X-MesageID: 16078695
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,394,1580792400"; d="scan'208";a="16078695"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/vtd: relax EPT page table sharing check
Date: Fri, 17 Apr 2020 13:29:54 +0200
Message-ID: <20200417112954.21250-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The EPT page tables can be shared with the IOMMU as long as the page
sizes supported by EPT are also supported by the IOMMU.

Current code checks that both the IOMMU and EPT support the same page
sizes, but this is not strictly required, the IOMMU supporting more
page sizes than EPT is fine and shouldn't block page table sharing.

This is likely not a common case (IOMMU supporting more page sizes
than EPT), but should still be fixed for correctness.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
---
Changes since v1:
 - Use <= to compare caps.
 - Reword subject/commit message.
---
 xen/drivers/passthrough/vtd/iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 07d40b37fe..208b33c0e4 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1914,8 +1914,8 @@ static int __init vtd_ept_page_compatible(struct vtd_iommu *iommu)
     if ( rdmsr_safe(MSR_IA32_VMX_EPT_VPID_CAP, ept_cap) != 0 ) 
         return 0;
 
-    return (ept_has_2mb(ept_cap) && opt_hap_2mb) == cap_sps_2mb(vtd_cap) &&
-           (ept_has_1gb(ept_cap) && opt_hap_1gb) == cap_sps_1gb(vtd_cap);
+    return (ept_has_2mb(ept_cap) && opt_hap_2mb) <= cap_sps_2mb(vtd_cap) &&
+           (ept_has_1gb(ept_cap) && opt_hap_1gb) <= cap_sps_1gb(vtd_cap);
 }
 
 /*
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 11:34:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 11:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPPGS-0001BW-VS; Fri, 17 Apr 2020 11:34:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9Py=6B=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jPPGR-0001BR-F0
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 11:34:31 +0000
X-Inumbo-ID: 6651cde6-809f-11ea-8cbb-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6651cde6-809f-11ea-8cbb-12813bfff9fa;
 Fri, 17 Apr 2020 11:34:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587123270;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=CJQ4tzDi8UqH0BYulrbZ/8izM1++NozR47DTHe8h3R8=;
 b=UPwGCNBWKiz0CKGRUrX6rsId3LPfUOLbr9Lbro3EYQCoI9WYqgn92ZpE
 9Z+Ee8pMBSRpD7RB4jbnjPZToDmsARqSgfcfNhH3+lJPpPsBjXLgoPzkE
 +2JDm+A3/3ccOwKCFh3FFGGpxsJ84f/QXseCztYoMWFzyxarf7lb+Yq+Y w=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: jcB7hJmVDX7TvsIWbVMbGsHlJY3aoaZkCunwTnfWTRqvardxXYhOvvE0GosgBcsVIAjXTdWY4G
 13cNUTUAPM9v+POt4Sqp+zaP/tgifpwCP3yEEkf6vVa1Y/qp92au+yV68Z4/yaru8Rt77KCeF/
 IyId2t+sBoJM1Ohqd8ZKQQVxN2dJx5TvgUa4WbwTwp16H4wHb68S2SJT5msei2jPhZwUfaTeBz
 5Hc+4HL8BFdfs3/0LAuyuzpVqQ65NP2YC0M0zXUZfSwRlYYIj7lCX9VQ7+ZIFJy++jqLe2yUw/
 tDk=
X-SBRS: 2.7
X-MesageID: 15820357
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,394,1580792400"; d="scan'208";a="15820357"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/pv: Delete CONFIG_PV_LDT_PAGING
Date: Fri, 17 Apr 2020 12:34:23 +0100
Message-ID: <20200417113423.19057-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

... in accordance with the timeline layed out in the Kconfig message.  There
has been no comment since it was disabled by default.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/Kconfig                | 23 -----------------------
 xen/arch/x86/mm.c                   | 31 -------------------------------
 xen/arch/x86/pv/descriptor-tables.c | 15 ---------------
 xen/arch/x86/pv/domain.c            |  4 ----
 xen/arch/x86/pv/mm.c                |  9 ---------
 xen/include/asm-x86/domain.h        |  6 ------
 6 files changed, 88 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 8149362bde..a69be983d6 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -225,26 +225,3 @@ endmenu
 source "common/Kconfig"
 
 source "drivers/Kconfig"
-
-menu "Deprecated Functionality"
-
-config PV_LDT_PAGING
-	bool "PV LDT Paging-out support"
-	depends on PV
-	---help---
-	  For a very long time, the PV ABI has included the ability to page
-	  out the LDT by transitioning its mapping to not-present.  This
-	  functionality is believed to only exist for the PV Windows XP port
-	  which never came to anything.
-
-	  The implementation contains a vCPU scalability limitation in a
-	  position which is prohibitively complicated to resolve.  As the
-	  feature is believed to be unused in practice, removing the feature
-	  is the easiest remediation.
-
-	  If you discover a usecase which is broken by this option being off,
-	  please contact xen-devel@lists.xenproject.org urgently.  Baring
-	  something unexpected, the code and this option will be deleted 2
-	  releases after Xen 4.12.
-
-endmenu
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index fb53d62abc..ee56e053e1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1251,40 +1251,9 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain *l1e_owner)
      */
     if ( (l1e_get_flags(l1e) & _PAGE_RW) &&
          ((l1e_owner == pg_owner) || !paging_mode_external(pg_owner)) )
-    {
         put_page_and_type(page);
-    }
     else
-    {
-#ifdef CONFIG_PV_LDT_PAGING
-        /* We expect this is rare so we blow the entire shadow LDT. */
-        if ( unlikely(((page->u.inuse.type_info & PGT_type_mask) ==
-                       PGT_seg_desc_page)) &&
-             unlikely(((page->u.inuse.type_info & PGT_count_mask) != 0)) &&
-             (l1e_owner == pg_owner) )
-        {
-            struct vcpu *v;
-            cpumask_t *mask = this_cpu(scratch_cpumask);
-
-            cpumask_clear(mask);
-
-            for_each_vcpu ( pg_owner, v )
-            {
-                unsigned int cpu;
-
-                if ( !pv_destroy_ldt(v) )
-                    continue;
-                cpu = read_atomic(&v->dirty_cpu);
-                if ( is_vcpu_dirty_cpu(cpu) )
-                    __cpumask_set_cpu(cpu, mask);
-            }
-
-            if ( !cpumask_empty(mask) )
-                flush_tlb_mask(mask);
-        }
-#endif /* CONFIG_PV_LDT_PAGING */
         put_page(page);
-    }
 }
 
 #ifdef CONFIG_PV
diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c
index 940804b18a..090f901b5b 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -37,14 +37,7 @@ bool pv_destroy_ldt(struct vcpu *v)
 
     ASSERT(!in_irq());
 
-#ifdef CONFIG_PV_LDT_PAGING
-    spin_lock(&v->arch.pv.shadow_ldt_lock);
-
-    if ( v->arch.pv.shadow_ldt_mapcnt == 0 )
-        goto out;
-#else
     ASSERT(v == current || !vcpu_cpu_dirty(v));
-#endif
 
     pl1e = pv_ldt_ptes(v);
 
@@ -62,14 +55,6 @@ bool pv_destroy_ldt(struct vcpu *v)
         put_page_and_type(page);
     }
 
-#ifdef CONFIG_PV_LDT_PAGING
-    ASSERT(v->arch.pv.shadow_ldt_mapcnt == mappings_dropped);
-    v->arch.pv.shadow_ldt_mapcnt = 0;
-
- out:
-    spin_unlock(&v->arch.pv.shadow_ldt_lock);
-#endif
-
     return mappings_dropped;
 }
 
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 70fae43965..43da5c179f 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -243,10 +243,6 @@ int pv_vcpu_initialise(struct vcpu *v)
 
     ASSERT(!is_idle_domain(d));
 
-#ifdef CONFIG_PV_LDT_PAGING
-    spin_lock_init(&v->arch.pv.shadow_ldt_lock);
-#endif
-
     rc = pv_create_gdt_ldt_l1tab(v);
     if ( rc )
         return rc;
diff --git a/xen/arch/x86/pv/mm.c b/xen/arch/x86/pv/mm.c
index 2b0dadc8da..5d4cd00941 100644
--- a/xen/arch/x86/pv/mm.c
+++ b/xen/arch/x86/pv/mm.c
@@ -123,17 +123,8 @@ bool pv_map_ldt_shadow_page(unsigned int offset)
     pl1e = &pv_ldt_ptes(curr)[offset >> PAGE_SHIFT];
     l1e_add_flags(gl1e, _PAGE_RW);
 
-#ifdef CONFIG_PV_LDT_PAGING
-    spin_lock(&curr->arch.pv.shadow_ldt_lock);
-#endif
-
     l1e_write(pl1e, gl1e);
 
-#ifdef CONFIG_PV_LDT_PAGING
-    curr->arch.pv.shadow_ldt_mapcnt++;
-    spin_unlock(&curr->arch.pv.shadow_ldt_lock);
-#endif
-
     return true;
 }
 
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 4192c636b1..554b8dddcc 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -520,12 +520,6 @@ struct pv_vcpu
     unsigned int iopl;        /* Current IOPL for this VCPU, shifted left by
                                * 12 to match the eflags register. */
 
-#ifdef CONFIG_PV_LDT_PAGING
-    /* Current LDT details. */
-    unsigned long shadow_ldt_mapcnt;
-    spinlock_t shadow_ldt_lock;
-#endif
-
     /*
      * %dr7 bits the guest has set, but aren't loaded into hardware, and are
      * completely emulated.
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 11:45:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 11:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPPRN-000266-3c; Fri, 17 Apr 2020 11:45:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+QBT=6B=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jPPRL-000261-QW
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 11:45:47 +0000
X-Inumbo-ID: fa5fa034-80a0-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fa5fa034-80a0-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 11:45:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=nhJoQhBdS+eHcmpfuySjaJ1ecM/XbFb2B9gH6k6ftF8=; b=BhJU5kpev6cGZB9Hr3lnQlbUiU
 QdgcKKsSDdVTFBONqDPcfmpIV57sNDsiOIQbINPXs9UX00Hd0zNtTIEqVwwSOQWlCBoRFcvqdPBCt
 PjhoYBkM1R3FEl1nFdvTqXSkwehnBCprFruHG5dg+tiVtewV+3BKJHDGvBiABoVrgQjI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jPPRK-0004up-L5; Fri, 17 Apr 2020 11:45:46 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jPPRK-0002g6-Bu; Fri, 17 Apr 2020 11:45:46 +0000
Date: Fri, 17 Apr 2020 12:45:43 +0100
From: Wei Liu <wl@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/pv: Delete CONFIG_PV_LDT_PAGING
Message-ID: <20200417114543.rofpi53qdg3gcsm2@debian>
References: <20200417113423.19057-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200417113423.19057-1-andrew.cooper3@citrix.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 12:34:23PM +0100, Andrew Cooper wrote:
> ... in accordance with the timeline layed out in the Kconfig message.  There
> has been no comment since it was disabled by default.

layed -> laid

Code looks good to me:

Reviewed-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 12:04:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 12:04:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPPjn-0003n3-4b; Fri, 17 Apr 2020 12:04:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPPjl-0003my-TP
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 12:04:49 +0000
X-Inumbo-ID: a235c016-80a3-11ea-8cc2-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a235c016-80a3-11ea-8cc2-12813bfff9fa;
 Fri, 17 Apr 2020 12:04:48 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9BC93AD83;
 Fri, 17 Apr 2020 12:04:46 +0000 (UTC)
Subject: Re: [PATCH] x86/vtd: fix EPT page table sharing check
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200417102650.20083-1-roger.pau@citrix.com>
 <c3589851-7084-e3a4-f776-6157bc4de762@suse.com>
 <20200417111637.GP28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <224070b7-d396-52cb-5eed-d0295528a865@suse.com>
Date: Fri, 17 Apr 2020 14:04:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417111637.GP28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Kevin Tian <kevin.tian@intel.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 13:16, Roger Pau Monné wrote:
> On Fri, Apr 17, 2020 at 12:57:16PM +0200, Jan Beulich wrote:
>> On 17.04.2020 12:26, Roger Pau Monne wrote:
>>> --- a/xen/drivers/passthrough/vtd/iommu.c
>>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>>> @@ -1914,8 +1914,10 @@ static int __init vtd_ept_page_compatible(struct vtd_iommu *iommu)
>>>      if ( rdmsr_safe(MSR_IA32_VMX_EPT_VPID_CAP, ept_cap) != 0 ) 
>>>          return 0;
>>>  
>>> -    return (ept_has_2mb(ept_cap) && opt_hap_2mb) == cap_sps_2mb(vtd_cap) &&
>>> -           (ept_has_1gb(ept_cap) && opt_hap_1gb) == cap_sps_1gb(vtd_cap);
>>> +    return ((ept_has_2mb(ept_cap) && opt_hap_2mb) ? cap_sps_2mb(vtd_cap)
>>> +                                                  : true) &&
>>> +           ((ept_has_1gb(ept_cap) && opt_hap_1gb) ? cap_sps_1gb(vtd_cap)
>>> +                                                  : true);
>>
>> I have to admit that I always find it odd to have "true" or "false"
>> as the 2nd or 3rd operand of a ternary. How about simply changing
>> == to <= in the original expression?
> 
> I find it weird to use <= to compare booleans, but I can change it.

In the end Kevin will have to judge what variant to use.

> Let me post a new version with the adjustments to the commit message
> and this requested change.

Thanks.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 12:06:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 12:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPPlY-0003ss-JM; Fri, 17 Apr 2020 12:06:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPPlY-0003sn-3N
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 12:06:40 +0000
X-Inumbo-ID: e47ec60c-80a3-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e47ec60c-80a3-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 12:06:39 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 18D4DABEF;
 Fri, 17 Apr 2020 12:06:38 +0000 (UTC)
Subject: Re: [PATCH] x86/vtd: relax EPT page table sharing check
To: Roger Pau Monne <roger.pau@citrix.com>
References: <20200417112954.21250-1-roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <00d0abbb-5925-4866-8614-7ea10bc80cf4@suse.com>
Date: Fri, 17 Apr 2020 14:06:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417112954.21250-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Kevin Tian <kevin.tian@intel.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 13:29, Roger Pau Monne wrote:
> The EPT page tables can be shared with the IOMMU as long as the page
> sizes supported by EPT are also supported by the IOMMU.
> 
> Current code checks that both the IOMMU and EPT support the same page
> sizes, but this is not strictly required, the IOMMU supporting more
> page sizes than EPT is fine and shouldn't block page table sharing.
> 
> This is likely not a common case (IOMMU supporting more page sizes
> than EPT), but should still be fixed for correctness.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 13:20:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 13:20:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPQuD-00017T-2m; Fri, 17 Apr 2020 13:19:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=iNba=6B=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jPQuB-00016v-WF
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 13:19:40 +0000
X-Inumbo-ID: 162a4f82-80ae-11ea-83d8-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 162a4f82-80ae-11ea-83d8-bc764e2007e4;
 Fri, 17 Apr 2020 13:19:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587129577;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=Z3WtNWDaRIC8wLfSnN432v4D7LHYtucb0aC+fVHX9Vg=;
 b=M7R3Tg3DltuTJQloXZkCTLz7k4d+i+qJDlTED+kSmU7RzD4WV0TA5rSc
 ClC7rSjnVFML76853rbUn7mXgkPi54bVa7YfipSK87hBGhKWsbD/D39RE
 J2Hd5B73krXf+/sl1UfaKoFyLPcEuMQYwLkgbG3Xc8KstfYwBTGzuSChi A=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: wsRw+yfmvKUvI9XLHy3KfJD0s5nsAbwcsHNu8AyKMgo369T4sd2Ne5JxoooSuqCQ4CmwlKnsTg
 pPwU08NgY8SWHBGL8MSG6ng86ABTFvtcNGwLMyBEusm4Ff71vf83dmBFShLMG0rzrZKZneQ4Nd
 3msDQy5jgQoVMKshpWG9RqfK54fX3Gm+M0UJx8iuJlzG262uUpKudzGB048ZQpe+fY3ETc5ih4
 rfenKhC3YjKSNn/4fkvzm3Zrqk0oPwJ/4khEw1iXXVzQygP1FeGYew7dW8/to6HIRKLFZp/md+
 Nho=
X-SBRS: 2.7
X-MesageID: 16159541
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="16159541"
Date: Fri, 17 Apr 2020 14:19:31 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
Message-ID: <20200417131931.GM4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-15-anthony.perard@citrix.com>
 <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
 <20200416124400.GG4088@perard.uk.xensource.com>
 <312e719f-2bae-cb29-a6dd-29ae0d976d95@suse.com>
 <20200416150929.GL4088@perard.uk.xensource.com>
 <586cff44-d46e-3a5b-9e47-0c7ff4de8801@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <586cff44-d46e-3a5b-9e47-0c7ff4de8801@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 09:12:11AM +0200, Jan Beulich wrote:
> On 16.04.2020 17:09, Anthony PERARD wrote:
> > On Thu, Apr 16, 2020 at 04:22:05PM +0200, Jan Beulich wrote:
> >> On 16.04.2020 14:44, Anthony PERARD wrote:
> >>> On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
> >>>> On 31.03.2020 12:30, Anthony PERARD wrote:
> >>>>> We want to use the same rune to build mm/*/guest_*.o as the one use to
> >>>>> build every other *.o object. The consequence it that file symbols that
> >>>>> the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
> >>>>>
> >>>>> (1) Currently we have those two file symbols:
> >>>>>     guest_walk.c
> >>>>>     guest_walk_2.o
> >>>>> (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have:
> >>>>>     arch/x86/mm/guest_walk.c
> >>>>>     guest_walk_2.o
> >>>>>
> >>>>> The order in which those symbols are present may be different.
> >>>>>
> >>>>> Currently, in case (1) ./symbols chooses the *.o symbol (object file
> >>>>> name). But in case (2), may choose the *.c symbol (source file name with
> >>>>> path component) if it is first
> >>>>>
> >>>>> We want to have ./symbols choose the object file name symbol in both
> >>>>> cases.
> >>>>
> >>>> I guess the reason for wanting this is somehow connected to the
> >>>> statement at the beginning of the description, but I can't seem
> >>>> to be able to make the connection.
> >>>
> >>> I'm not sure I can explain it better.
> >>>
> >>> The "object file name" file symbol is used to distinguish between symbols
> >>> from all mm/*/guest_* objects. The other file symbol present in those
> >>> object is a "source file name without any path component symbol".
> >>>
> >>> But building those objects with the same rune as any other objects, and
> >>> having CONFIG_ENFORCE_UNIQUE_SYMBOLS=y, changes the file symbols present
> >>> in the resulting object. We still have the "object file name" symbol,
> >>> but now we also have "source file name with path components" symbol.
> >>> Unfortunately, all mm/*/guest_*.o in one directory are built from the
> >>> same source file, and thus have the same "source file name" symbol, but
> >>> have different "object file name" symbol. We still want to be able to
> >>> distinguish between guest_*.o in one dir, and the only way for that is
> >>> to use the "object file name" symbol.
> >>
> >> So where's the difference from how things work right now? The "same rune"
> >> aspect doesn't really change - right now we also build with effectively
> >> the same logic, just that -DGUEST_PAGING_LEVELS=... gets added. I guess
> >> it might help if you showed (for one particular example) how the set of
> >> file symbols changes from what we have now (with and without
> >> CONFIG_ENFORCE_UNIQUE_SYMBOLS=y) to what there would be with your changes
> >> to the symbols utility to what there will be with those changes.
> > 
> > The logic to build objects from C files changed in 81ecb38b83b0 ("build:
> > provide option to disambiguate symbol names"), with objects build with
> > __OBJECT_FILE__ explicitly left alone. So the logic is different now (at
> > least when CONFIG_ENFORCE_UNIQUE_SYMBOLS=y).
> > 
> > I did add the example of building arch/x86/mm/guest_walk_2.o to the
> > commit message, reworded below:
> > 
> > For example, when building arch/x86/mm/guest_walk_2.o from guest_walk.c,
> > this would be the difference of file symbol present in the object when
> > building with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y:
> > 
> > (1) Currently we have those two file symbols:
> >     guest_walk.c
> >     guest_walk_2.o
> > (2) When building with the same rune, we will have:
> >     arch/x86/mm/guest_walk.c
> >     guest_walk_2.o
> 
> Ah, yes, the changed introductory paragraph makes clear (to me)
> what presence and what future (1) and (2) are talking about. Yet
> what I then still don't understand - what is it that makes the
> path appear when switching to the common rune? Oh - I finally
> figured it: It's the objcopy step that will apply to all targets
> uniformly then. Perhaps it's indeed obvious, but it clearly
> wasn't to me when merely looking at the patch.
>
> With this I'd then wonder whether it wouldn't be a far smaller
> adjustment to simply skip that --redefine-sym step in case the
> object file already has a file symbol naming the object file,
> thus simply retaining the status quo.

So, we should call `nm' thousands of time, to find out if calling
`objcopy' is needed, for the 9 objects that doesn't need the extra step?

Or do you mean keeping exception to the rule? And hope that when someone
changes the rule, it doesn't forget to check if the exception needs
changing as well?

Also, I'm going to have to use this patch later anyway as sometime CC
use a full path to the source as file symbol. So this is going to be
important when we will run for example
`clang -o arch/x86/mm/guest_walk_2.o arch/x86/mm/guest_walk.c`.
(There isn't a patch for that yet.)

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 13:30:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 13:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPR4h-0002dj-1d; Fri, 17 Apr 2020 13:30:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPR4f-0002de-Pb
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 13:30:29 +0000
X-Inumbo-ID: 9719da4e-80af-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9719da4e-80af-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 13:30:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=BDQOr9eANLTAO7vi+lhZ4AT+Jyxic2lUGRA49LBVPtE=; b=Urv5BnSVCtbNupMYefML64kfe
 EjQq/EiChXTtRrpzT544mbSw5Bka5vnDZT8eB6HPkV7ExzUA40SV6oLymBOirJmrnKyOX+acPufgA
 c4bhl5pthXiZtUDmwHm5Xr29j/3H5pbQvoa8sGRNm5W+Q7wJxQ3kdAqAUdEwH2MMgzLuo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPR4Y-0006xh-QI; Fri, 17 Apr 2020 13:30:22 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPR4Y-0001UY-HX; Fri, 17 Apr 2020 13:30:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPR4Y-00024N-Ge; Fri, 17 Apr 2020 13:30:22 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149695-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149695: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=a48e1323f9aa29f1ffb95594671b73de6bd7c1d4
X-Osstest-Versions-That: xen=615bfe42c6d183a0e54a0525ef82b58580d01619
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 13:30:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149689
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149689
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149689
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149689
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149689
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149689
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149689
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149689
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149689
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149689
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  a48e1323f9aa29f1ffb95594671b73de6bd7c1d4
baseline version:
 xen                  615bfe42c6d183a0e54a0525ef82b58580d01619

Last test of basis   149689  2020-04-16 13:17:05 Z    1 days
Testing same since   149695  2020-04-17 04:16:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Harsha Shamsundara Havanur <havanur@amazon.com>
  Hongyan Xia <hongyxia@amazon.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Wei Liu <wei.liu2@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   615bfe42c6..a48e1323f9  a48e1323f9aa29f1ffb95594671b73de6bd7c1d4 -> master


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 13:40:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 13:40:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRDo-0002zo-Ko; Fri, 17 Apr 2020 13:39:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRDn-0002zj-Ub
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 13:39:55 +0000
X-Inumbo-ID: eb91cc7a-80b0-11ea-8ce5-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id eb91cc7a-80b0-11ea-8ce5-12813bfff9fa;
 Fri, 17 Apr 2020 13:39:54 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DACC5ACC4;
 Fri, 17 Apr 2020 13:39:52 +0000 (UTC)
Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-15-anthony.perard@citrix.com>
 <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
 <20200416124400.GG4088@perard.uk.xensource.com>
 <312e719f-2bae-cb29-a6dd-29ae0d976d95@suse.com>
 <20200416150929.GL4088@perard.uk.xensource.com>
 <586cff44-d46e-3a5b-9e47-0c7ff4de8801@suse.com>
 <20200417131931.GM4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <83de83ee-848f-a048-7293-d1e5b01dd217@suse.com>
Date: Fri, 17 Apr 2020 15:39:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417131931.GM4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 15:19, Anthony PERARD wrote:
> On Fri, Apr 17, 2020 at 09:12:11AM +0200, Jan Beulich wrote:
>> On 16.04.2020 17:09, Anthony PERARD wrote:
>>> On Thu, Apr 16, 2020 at 04:22:05PM +0200, Jan Beulich wrote:
>>>> On 16.04.2020 14:44, Anthony PERARD wrote:
>>>>> On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
>>>>>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>>>>>> We want to use the same rune to build mm/*/guest_*.o as the one use to
>>>>>>> build every other *.o object. The consequence it that file symbols that
>>>>>>> the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
>>>>>>>
>>>>>>> (1) Currently we have those two file symbols:
>>>>>>>     guest_walk.c
>>>>>>>     guest_walk_2.o
>>>>>>> (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have:
>>>>>>>     arch/x86/mm/guest_walk.c
>>>>>>>     guest_walk_2.o
>>>>>>>
>>>>>>> The order in which those symbols are present may be different.
>>>>>>>
>>>>>>> Currently, in case (1) ./symbols chooses the *.o symbol (object file
>>>>>>> name). But in case (2), may choose the *.c symbol (source file name with
>>>>>>> path component) if it is first
>>>>>>>
>>>>>>> We want to have ./symbols choose the object file name symbol in both
>>>>>>> cases.
>>>>>>
>>>>>> I guess the reason for wanting this is somehow connected to the
>>>>>> statement at the beginning of the description, but I can't seem
>>>>>> to be able to make the connection.
>>>>>
>>>>> I'm not sure I can explain it better.
>>>>>
>>>>> The "object file name" file symbol is used to distinguish between symbols
>>>>> from all mm/*/guest_* objects. The other file symbol present in those
>>>>> object is a "source file name without any path component symbol".
>>>>>
>>>>> But building those objects with the same rune as any other objects, and
>>>>> having CONFIG_ENFORCE_UNIQUE_SYMBOLS=y, changes the file symbols present
>>>>> in the resulting object. We still have the "object file name" symbol,
>>>>> but now we also have "source file name with path components" symbol.
>>>>> Unfortunately, all mm/*/guest_*.o in one directory are built from the
>>>>> same source file, and thus have the same "source file name" symbol, but
>>>>> have different "object file name" symbol. We still want to be able to
>>>>> distinguish between guest_*.o in one dir, and the only way for that is
>>>>> to use the "object file name" symbol.
>>>>
>>>> So where's the difference from how things work right now? The "same rune"
>>>> aspect doesn't really change - right now we also build with effectively
>>>> the same logic, just that -DGUEST_PAGING_LEVELS=... gets added. I guess
>>>> it might help if you showed (for one particular example) how the set of
>>>> file symbols changes from what we have now (with and without
>>>> CONFIG_ENFORCE_UNIQUE_SYMBOLS=y) to what there would be with your changes
>>>> to the symbols utility to what there will be with those changes.
>>>
>>> The logic to build objects from C files changed in 81ecb38b83b0 ("build:
>>> provide option to disambiguate symbol names"), with objects build with
>>> __OBJECT_FILE__ explicitly left alone. So the logic is different now (at
>>> least when CONFIG_ENFORCE_UNIQUE_SYMBOLS=y).
>>>
>>> I did add the example of building arch/x86/mm/guest_walk_2.o to the
>>> commit message, reworded below:
>>>
>>> For example, when building arch/x86/mm/guest_walk_2.o from guest_walk.c,
>>> this would be the difference of file symbol present in the object when
>>> building with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y:
>>>
>>> (1) Currently we have those two file symbols:
>>>     guest_walk.c
>>>     guest_walk_2.o
>>> (2) When building with the same rune, we will have:
>>>     arch/x86/mm/guest_walk.c
>>>     guest_walk_2.o
>>
>> Ah, yes, the changed introductory paragraph makes clear (to me)
>> what presence and what future (1) and (2) are talking about. Yet
>> what I then still don't understand - what is it that makes the
>> path appear when switching to the common rune? Oh - I finally
>> figured it: It's the objcopy step that will apply to all targets
>> uniformly then. Perhaps it's indeed obvious, but it clearly
>> wasn't to me when merely looking at the patch.
>>
>> With this I'd then wonder whether it wouldn't be a far smaller
>> adjustment to simply skip that --redefine-sym step in case the
>> object file already has a file symbol naming the object file,
>> thus simply retaining the status quo.
> 
> So, we should call `nm' thousands of time, to find out if calling
> `objcopy' is needed, for the 9 objects that doesn't need the extra step?

Well that (or rather objdump) was what I was thinking while writing
the earlier reply, but you have a point - I can see how treating
the bigger change for less build time might be worth it. Yet ...

> Or do you mean keeping exception to the rule? And hope that when someone
> changes the rule, it doesn't forget to check if the exception needs
> changing as well?

... "exception" like you put it (requiring special care to keep
multiple instances in sync) is not the only way this can be done
(and indeed I'd not want something like this). Since you have
(in patch 15) e.g.

guest_walk_%.o: guest_walk.c FORCE
	$(call if_changed_rule,cc_o_c)

anyway, the desire to skip the objcopy step could be communicated
to the command from here, without needing to clone the command.
One way might be a special (phony) dependency, another might be to
set some variable along the lines of

guest_walk_%.o: SPECIAL := y

> Also, I'm going to have to use this patch later anyway as sometime CC
> use a full path to the source as file symbol. So this is going to be
> important when we will run for example
> `clang -o arch/x86/mm/guest_walk_2.o arch/x86/mm/guest_walk.c`.
> (There isn't a patch for that yet.)

That's interesting - what will be the goal of that future adjustment?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 13:41:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 13:41:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRFZ-0003jD-1j; Fri, 17 Apr 2020 13:41:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8vtN=6B=gmail.com=brendank310@srs-us1.protection.inumbo.net>)
 id 1jPRAp-0002w8-4t
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 13:36:51 +0000
X-Inumbo-ID: 7e06d128-80b0-11ea-9e09-bc764e2007e4
Received: from mail-qk1-x72b.google.com (unknown [2607:f8b0:4864:20::72b])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7e06d128-80b0-11ea-9e09-bc764e2007e4;
 Fri, 17 Apr 2020 13:36:50 +0000 (UTC)
Received: by mail-qk1-x72b.google.com with SMTP id x66so2316302qkd.9
 for <xen-devel@lists.xenproject.org>; Fri, 17 Apr 2020 06:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id;
 bh=wWFO4OrewFzHWBIK4A/5sZz/WdC0rHyctT9V9v5Avow=;
 b=XVU2YuWvv6CVx4OW+5x1js3oxi+SdhXTkvGtYWdNF5P/smVNFXhtBAYu0mZFMdNALt
 OvbhJ+bGKgHNGBs7dc7c430XRPYAT9eNY6RpEWpVSvfGyPCnYeuNRPXGhFaCkW6SGzgI
 fgKIhRn2LQTwhZHKoEGYYGCgM1dQTKypY7bsQTuHvGowAQfPFRLgrWY1u2DYID8sIsmK
 61q2tV1SFaotxfT51cLgg2Twn7q7QLKN8eOHqAQn4Luf4N5vPeNOrQdJO6ML7d3ft+U0
 TAE76vKvxrSacO0nkPB4TTdtxJyO0th8x6WC0sRsa/FE9JZ944HOF6AcUVggb0wgAQ2r
 6LUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id;
 bh=wWFO4OrewFzHWBIK4A/5sZz/WdC0rHyctT9V9v5Avow=;
 b=DZEogf07KH4l8BHJkyVNOWpMbnAlvUSomvaew0+lhS5kPrOFIxCBzpqLvSxcKjijG7
 iSMhgqJDDOlAWy+hHzOUAOkltDsdgRbQXoVEuKKTqOdMN4UlQDVWEiHrJL3oB3wbP82/
 PVC0CqGnEsjGC/bzwBO4uYGMszssM4gjhIDShOO42PLUMqkg+yl5kDpAF+SZMnhFsgAE
 UqYqbRJ1au9Nobiw1mFwKzPxJRFTbMD118b8e8yT0sEAJMa4hyj40pZyxRqihrFkAgvo
 mpxVz2FPl6C8+0sX2zuEE7Ht0vMIbYlZsIFJp7ErsuPSiqJYj98AY8lpUT7dLdvLRsm4
 mdGA==
X-Gm-Message-State: AGi0PuZs0pzQZ/at2FsurHnZGCbnPsQJVpLNhZHQSo1E87M3489xooJh
 VGwFPH57hoIksXtNTg4ppPDPF+nq9eRHUw==
X-Google-Smtp-Source: APiQypKphbZJN0BAcXe4dNOcmQFWeiUUKpO3dI07Rb7VA/9iyM8q/ThAHDSxQOG3Rb80cnGl1p9yIg==
X-Received: by 2002:a37:b1c6:: with SMTP id a189mr3288480qkf.26.1587130609992; 
 Fri, 17 Apr 2020 06:36:49 -0700 (PDT)
Received: from ubuntu.localdomain
 (pool-96-249-236-140.nrflva.fios.verizon.net. [96.249.236.140])
 by smtp.gmail.com with ESMTPSA id s15sm18140737qtc.31.2020.04.17.06.36.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Apr 2020 06:36:49 -0700 (PDT)
From: Brendan Kerrigan <brendank310@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/1] Mask VT-d DMAR faults for IGD devices
Date: Fri, 17 Apr 2020 09:36:25 -0400
Message-Id: <20200417133626.72302-1-brendank310@gmail.com>
X-Mailer: git-send-email 2.17.1
X-Mailman-Approved-At: Fri, 17 Apr 2020 13:41:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: kevin.tian@intel.com, Brendan Kerrigan <kerriganb@ainfosec.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Brendan Kerrigan <kerriganb@ainfosec.com>

The Intel IOMMU for at least 8th and 9th generation Core processors has a bug
where the Fault Processing Disable bit is not respected for the Intel Graphics
Device (IGD). The resulting behavior was reported previously[1]. The underlying
cause is described by Intel as Errata ID 049 in the Core spec update
document[2], along with a suggested workaround, which is implemented in the
patch.

[1] https://lists.xen.org/archives/html/xen-devel/2015-08/msg01955.html
[2] https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/8th-gen-core-spec-update.pdf


Brendan Kerrigan (1):
  x86/vtd: Mask DMAR faults for IGD devices

 xen/drivers/passthrough/vtd/iommu.c | 9 +++++++++
 1 file changed, 9 insertions(+)

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 13:41:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 13:41:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRFZ-0003jK-B6; Fri, 17 Apr 2020 13:41:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=8vtN=6B=gmail.com=brendank310@srs-us1.protection.inumbo.net>)
 id 1jPRAw-0002wX-2P
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 13:36:58 +0000
X-Inumbo-ID: 82311876-80b0-11ea-b58d-bc764e2007e4
Received: from mail-qv1-xf44.google.com (unknown [2607:f8b0:4864:20::f44])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 82311876-80b0-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 13:36:57 +0000 (UTC)
Received: by mail-qv1-xf44.google.com with SMTP id p13so845385qvt.12
 for <xen-devel@lists.xenproject.org>; Fri, 17 Apr 2020 06:36:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references;
 bh=HRPWWtofqA3WxdWb6Pe4buRoU0c+5z8FPddggNV3kGg=;
 b=Ez+/LioiTpBc2aMj08gzjWR1kkaHMuAwKEfggRF0eTANv28Gwf/3GMz/f3wtRvYGda
 GDLIPdlp/fpivgsB+lVj9k6a9TKmu/beQtukKKZfhfbuYR1qzhh4Jk3sYCLkq8SYfIER
 BQ81qnCPKDEFijPmkSqlHDDUn/KXaBzxNc7K1XQSWju+ZuQxYmS6AEGXJLGliFJrsm75
 jDWkXSXP2FUhVZjL/F0S5ongusEvg8WZK9vCLllTd2T/bqoSFNLbrKICmtlBFeRZ1Aft
 PcDG4WmPnja4yoLeKaOAWGNM1E6rAoXUEfPF2KoyyJPUh+JPZ+KaZiZDcb4EyIUEfPef
 tJqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references;
 bh=HRPWWtofqA3WxdWb6Pe4buRoU0c+5z8FPddggNV3kGg=;
 b=RPDLaiT0Pq7L/M6ZC6aLiQ1fSFUd9OGtJ9aznblSqRxHITJ69ZZ5rh8uxO6f62g/mn
 FEGHSOVlO8/PAXXXbQLnMIIvJ3Simo11a3RcfX0ttdiIB8cWqswO5n+4GIRxegkvk3P5
 YdihHZ2CeUSQOSGSrTl6FCF1aLIpBE/WYttEedfttpQehQUmeEsxyLs8DeVflF1Cavi6
 LjYwkQkA3Gbdmr/IqbD46E930Uy+gE9GRz8293TjipUexCYj72YQEdk8J0pU2SPcW8u5
 ahhC1E8ODeSSdI88aSNzqzauObjNppxyldKH16gAJ7v0isIyyA8igNBkPMWjmlmNUlXM
 5aAA==
X-Gm-Message-State: AGi0PuZwt9uwnHjn/XHo+IHg8Tl1C81BczkTSVgwkiS4x0KF3QQf0aFA
 iLGQ0XDNfQwBVPNQUVF3A2yTqGMF1QrbNg==
X-Google-Smtp-Source: APiQypJvxlV1pk2XCy0Fb3ndgKfkRrg3cavj5ggAli2VEjBjAnaK65Ii8wvKWFtSFosYmV2b4Qc3qw==
X-Received: by 2002:ad4:57b0:: with SMTP id g16mr2716362qvx.161.1587130616978; 
 Fri, 17 Apr 2020 06:36:56 -0700 (PDT)
Received: from ubuntu.localdomain
 (pool-96-249-236-140.nrflva.fios.verizon.net. [96.249.236.140])
 by smtp.gmail.com with ESMTPSA id s15sm18140737qtc.31.2020.04.17.06.36.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Apr 2020 06:36:56 -0700 (PDT)
From: Brendan Kerrigan <brendank310@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 1/1] x86/vtd: Mask DMAR faults for IGD devices
Date: Fri, 17 Apr 2020 09:36:26 -0400
Message-Id: <20200417133626.72302-2-brendank310@gmail.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200417133626.72302-1-brendank310@gmail.com>
References: <20200417133626.72302-1-brendank310@gmail.com>
X-Mailman-Approved-At: Fri, 17 Apr 2020 13:41:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: kevin.tian@intel.com, Brendan Kerrigan <kerriganb@ainfosec.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Brendan Kerrigan <kerriganb@ainfosec.com>

The Intel graphics device records DMAR faults regardless
of the Fault Process Disable bit being set. When this fault
occurs, enable the Interrupt Mask (IM) bit in the Fault
Event Control (FECTL) register to prevent the continued
recording of the fault.

Signed-off-by: Brendan Kerrigan <kerriganb@ainfosec.com>
---
 xen/drivers/passthrough/vtd/iommu.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 07d40b37fe..288399d816 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -41,6 +41,8 @@
 #include "vtd.h"
 #include "../ats.h"
 
+#define IS_IGD(seg, id) (0 == seg && 0 == PCI_BUS(id) && 2 == PCI_SLOT(id) && 0 == PCI_FUNC(id))
+
 struct mapped_rmrr {
     struct list_head list;
     u64 base, end;
@@ -872,6 +874,13 @@ static int iommu_page_fault_do_one(struct vtd_iommu *iommu, int type,
     printk(XENLOG_G_WARNING VTDPREFIX "%s: reason %02x - %s\n",
            kind, fault_reason, reason);
 
+    if ( DMA_REMAP == fault_type && type && IS_IGD(seg, source_id) ) {
+        u32 fectl = dmar_readl(iommu->reg, DMAR_FECTL_REG);
+        fectl |= DMA_FECTL_IM;
+        dmar_writel(iommu->reg, DMAR_FECTL_REG, fectl);
+        printk(XENLOG_G_WARNING VTDPREFIX "Disabling DMAR faults for IGD\n");
+    }
+
     if ( iommu_verbose && fault_type == DMA_REMAP )
         print_vtd_entries(iommu, PCI_BUS(source_id), PCI_DEVFN2(source_id),
                           addr >> PAGE_SHIFT);
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 13:43:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 13:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRHZ-0003wQ-PE; Fri, 17 Apr 2020 13:43:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=f44r=6B=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jPRHX-0003wK-Om
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 13:43:47 +0000
X-Inumbo-ID: 74f87c35-80b1-11ea-8ce6-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 74f87c35-80b1-11ea-8ce6-12813bfff9fa;
 Fri, 17 Apr 2020 13:43:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587131025;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=+5W5SMf3LfxShpfVPxwa76djMVbv6G1uq8Zf3be7nqA=;
 b=Bncg1tWPiM/AUM+3fBJqTcb2zKnQOrnO/LxMZ7XOmIVmk05wWH1j4Pbl
 w0jVdJYR4CcBjldWUKKn1vYVKosHqx9BThwglvhBbFgUA7FQtwSYtYBn/
 hs+pbT+SMw43uA9Vx+5Sg0DT7l9CdC+PtPLPMN6jqX9If1PfzJ3Ndd7O/ 4=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: LdzRVlFhzQ3FsvQL97yGXmJnVEPAE6C0WztRsxKXgBeeri5iZMqbizVtaXSJazcaSOTGTnLBNe
 BW1OBWlLSRKaGJ+20zY5lVz/YvlXkQc2I952BBTqH1ZSYgPvt6/n58p93FkgCSwsNY+a5QojJx
 noThwM/6Ufm9bxYfN9C+lRNStXwsPH+8oZWTs+Pr7Hn7K3kr7YJWwUsBdacHRC2x7iRJqCYnSo
 4krihPlL8CTfqy1qWT/gsErrBIBR5oqBtw772hCrIBQHnaabHRGLMIaLAojh2ZVppniy9wLf72
 Da0=
X-SBRS: 2.7
X-MesageID: 16520376
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="16520376"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, Dario Faggioli
 <dfaggioli@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] sched: print information about scheduler granularity
Thread-Topic: [PATCH] sched: print information about scheduler granularity
Thread-Index: AQHWE8nCYlq/J4KoL0iU4gkSoIElX6h701EAgAD/WICAAHCoAA==
Date: Fri, 17 Apr 2020 13:43:42 +0000
Message-ID: <1587131006806.63738@citrix.com>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <d2577c4b4ff040c8f256d203e647619d9d4d6ebb.camel@suse.com>
 <3dacf98c-c4b7-a263-01d3-f8562619ff53@suse.com>
In-Reply-To: <3dacf98c-c4b7-a263-01d3-f8562619ff53@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-imapappendstamp: AMSPEX02CL03.citrite.net (15.00.1497.006)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <734F0004E7610C44BE63323EB5575303@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17/04/2020 08:57, J=FCrgen Gro=DF wrote:=0A=
> On 16.04.20 18:43, Dario Faggioli wrote:=0A=
>> On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:=0A=
>>> Currently it might be not obvious which scheduling mode is being used=
=0A=
>>> by the scheduler. Alleviate this by printing additional information=0A=
>>> about the selected granularity.=0A=
>>>=0A=
>> I like the idea. However, I don't like how verbose and long that line=0A=
>> becomes.=0A=
>>=0A=
>>> =A0 Messages now look like these:=0A=
>>>=0A=
>>> 1. boot=0A=
>>> (XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler=0A=
>>> (credit) in core-scheduling mode=0A=
>>>=0A=
>>> 2. xl debug-keys r=0A=
>>> (XEN) [=A0=A0 45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-=
=0A=
>>> way core-scheduling mode=0A=
>>>=0A=
>> What about adding an entry, just below these ones. Something looking=0A=
>> like, for instance (both at boot and in the debug-key dump):=0A=
>>=0A=
>> "Scheduling granularity: cpu"=0A=
>>=0A=
>> (or "core", or "socket")=0A=
=0A=
I agree that the line becomes too long. I'll print the new information=0A=
on a separate line as you suggest in v2.=0A=
=0A=
>>=0A=
>> Also=0A=
>>=0A=
>>> --- a/xen/common/sched/cpupool.c=0A=
>>> +++ b/xen/common/sched/cpupool.c=0A=
>>> @@ -38,7 +38,35 @@ static cpumask_t cpupool_locked_cpus;=0A=
>>> =A0 static DEFINE_SPINLOCK(cpupool_lock);=0A=
>>> =A0 static enum sched_gran __read_mostly opt_sched_granularity =3D=0A=
>>> SCHED_GRAN_cpu;=0A=
>>> -static unsigned int __read_mostly sched_granularity =3D 1;=0A=
>>> +static unsigned int __read_mostly sched_granularity;=0A=
>>> +=0A=
>>> +char *sched_gran_str(char *str, size_t size)=0A=
>>> +{=0A=
>>> +=A0=A0=A0 char *mode =3D "";=0A=
>>> +=0A=
>>> +=A0=A0=A0 switch ( opt_sched_granularity )=0A=
>>> +=A0=A0=A0 {=0A=
>>> +=A0=A0=A0 case SCHED_GRAN_cpu:=0A=
>>> +=A0=A0=A0=A0=A0=A0=A0 mode =3D "cpu";=0A=
>>> +=A0=A0=A0=A0=A0=A0=A0 break;=0A=
>>> +=A0=A0=A0 case SCHED_GRAN_core:=0A=
>>> +=A0=A0=A0=A0=A0=A0=A0 mode =3D "core";=0A=
>>> +=A0=A0=A0=A0=A0=A0=A0 break;=0A=
>>> +=A0=A0=A0 case SCHED_GRAN_socket:=0A=
>>> +=A0=A0=A0=A0=A0=A0=A0 mode =3D "socket";=0A=
>>> +=A0=A0=A0=A0=A0=A0=A0 break;=0A=
>>> +=A0=A0=A0 default:=0A=
>>> +=A0=A0=A0=A0=A0=A0=A0 ASSERT_UNREACHABLE();=0A=
>>> +=A0=A0=A0=A0=A0=A0=A0 break;=0A=
>>> +=A0=A0=A0 }=0A=
>>> +=0A=
>>> +=A0=A0=A0 if ( sched_granularity )=0A=
>>> +=A0=A0=A0=A0=A0=A0=A0 snprintf(str, size, "%u-way %s", sched_granulari=
ty, mode);=0A=
>>>=0A=
>> I'm not sure about using the value of the enum like this.=0A=
> =0A=
> enum? sched_granularity holds the number of cpus per scheduling=0A=
> resource. opt_sched_granularity is the enum.=0A=
> =0A=
>>=0A=
>> E.g., in a system with 4 threads per core, enabling core scheduling=0A=
>> granularity would mean having 4 vCPUs in the scheduling units. But this=
=0A=
>> will still print "2-way core-scheduling", which I think would sound=0A=
>> confusing.=0A=
> =0A=
> It would print "4-way", of course.=0A=
> =0A=
>>=0A=
>> So I'd just go with "cpu", "core" and "socket" strings.=0A=
> =0A=
> No, this is not a good idea. With e.g. smt=3D0 you'll be able to have=0A=
> "1-way core" which is much more informative than "core".=0A=
=0A=
Can confirm the above. "sched-gran=3Dcore" on a Knights Mill produces:=0A=
(XEN) [  232.018648] Scheduler: SMP Credit Scheduler (credit) in 4-way core=
-scheduling mode=0A=
=0A=
While "sched-gran=3Dcore smt=3D0" gives:=0A=
(XEN) [  259.337588] Scheduler: SMP Credit Scheduler (credit) in 1-way core=
-scheduling mode=0A=
=0A=
--=0A=
Thanks,=0A=
Sergey=0A=
=0A=


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 13:52:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 13:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRPk-0004nc-Oo; Fri, 17 Apr 2020 13:52:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ygd1=6B=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jPRPj-0004nX-K8
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 13:52:15 +0000
X-Inumbo-ID: a4ab7106-80b2-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a4ab7106-80b2-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 13:52:14 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 38E8AAE09;
 Fri, 17 Apr 2020 13:52:13 +0000 (UTC)
Subject: Re: [PATCH] sched: print information about scheduler granularity
To: Sergey Dyasli <sergey.dyasli@citrix.com>,
 Dario Faggioli <dfaggioli@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <d2577c4b4ff040c8f256d203e647619d9d4d6ebb.camel@suse.com>
 <3dacf98c-c4b7-a263-01d3-f8562619ff53@suse.com>
 <1587131006806.63738@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <2d2fb0af-2ec3-4b2f-4427-eb13e9623111@suse.com>
Date: Fri, 17 Apr 2020 15:52:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <1587131006806.63738@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.20 15:43, Sergey Dyasli wrote:
> On 17/04/2020 08:57, Jürgen Groß wrote:
>> On 16.04.20 18:43, Dario Faggioli wrote:
>>> On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
>>>> Currently it might be not obvious which scheduling mode is being used
>>>> by the scheduler. Alleviate this by printing additional information
>>>> about the selected granularity.
>>>>
>>> I like the idea. However, I don't like how verbose and long that line
>>> becomes.
>>>
>>>>    Messages now look like these:
>>>>
>>>> 1. boot
>>>> (XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler
>>>> (credit) in core-scheduling mode
>>>>
>>>> 2. xl debug-keys r
>>>> (XEN) [   45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-
>>>> way core-scheduling mode
>>>>
>>> What about adding an entry, just below these ones. Something looking
>>> like, for instance (both at boot and in the debug-key dump):
>>>
>>> "Scheduling granularity: cpu"
>>>
>>> (or "core", or "socket")
> 
> I agree that the line becomes too long. I'll print the new information
> on a separate line as you suggest in v2.
> 
>>>
>>> Also
>>>
>>>> --- a/xen/common/sched/cpupool.c
>>>> +++ b/xen/common/sched/cpupool.c
>>>> @@ -38,7 +38,35 @@ static cpumask_t cpupool_locked_cpus;
>>>>    static DEFINE_SPINLOCK(cpupool_lock);
>>>>    static enum sched_gran __read_mostly opt_sched_granularity =
>>>> SCHED_GRAN_cpu;
>>>> -static unsigned int __read_mostly sched_granularity = 1;
>>>> +static unsigned int __read_mostly sched_granularity;
>>>> +
>>>> +char *sched_gran_str(char *str, size_t size)
>>>> +{
>>>> +    char *mode = "";
>>>> +
>>>> +    switch ( opt_sched_granularity )
>>>> +    {
>>>> +    case SCHED_GRAN_cpu:
>>>> +        mode = "cpu";
>>>> +        break;
>>>> +    case SCHED_GRAN_core:
>>>> +        mode = "core";
>>>> +        break;
>>>> +    case SCHED_GRAN_socket:
>>>> +        mode = "socket";
>>>> +        break;
>>>> +    default:
>>>> +        ASSERT_UNREACHABLE();
>>>> +        break;
>>>> +    }
>>>> +
>>>> +    if ( sched_granularity )
>>>> +        snprintf(str, size, "%u-way %s", sched_granularity, mode);
>>>>
>>> I'm not sure about using the value of the enum like this.
>>
>> enum? sched_granularity holds the number of cpus per scheduling
>> resource. opt_sched_granularity is the enum.
>>
>>>
>>> E.g., in a system with 4 threads per core, enabling core scheduling
>>> granularity would mean having 4 vCPUs in the scheduling units. But this
>>> will still print "2-way core-scheduling", which I think would sound
>>> confusing.
>>
>> It would print "4-way", of course.
>>
>>>
>>> So I'd just go with "cpu", "core" and "socket" strings.
>>
>> No, this is not a good idea. With e.g. smt=0 you'll be able to have
>> "1-way core" which is much more informative than "core".
> 
> Can confirm the above. "sched-gran=core" on a Knights Mill produces:
> (XEN) [  232.018648] Scheduler: SMP Credit Scheduler (credit) in 4-way core-scheduling mode
> 
> While "sched-gran=core smt=0" gives:
> (XEN) [  259.337588] Scheduler: SMP Credit Scheduler (credit) in 1-way core-scheduling mode

You might want to consider not using the global variables
[opt_]sched_granularity, but the per-cpupool ones. Right now they have
the same value, but this might change in future...


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 13:54:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 13:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRS2-0004vx-Ab; Fri, 17 Apr 2020 13:54:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPRS1-0004vr-2g
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 13:54:37 +0000
X-Inumbo-ID: f9176e5c-80b2-11ea-8cf0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f9176e5c-80b2-11ea-8cf0-12813bfff9fa;
 Fri, 17 Apr 2020 13:54:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=sNaHNLPNKm2Bg04wtzDKHJW229rDt+VafWM8WVkmqPs=; b=bin8oM+6RTQD+6FEXGPr02CL0
 8p/dCsV+5RgzWQU3Rzu/ybDBlTVEJRd6w4IxvsJ9WBY3TePfIBEZTdWGhwsIYystQGgfk9SBHhIyn
 XnTjy927ljc5yNHAhZ+38WY2ligFmgIjFoVWJWccQSUaI+Jv/iz7eN6YBxumQdpBRTx7U=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPRRz-0007RV-Qi; Fri, 17 Apr 2020 13:54:35 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPRRz-0002kA-Ik; Fri, 17 Apr 2020 13:54:35 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPRRz-0003In-I2; Fri, 17 Apr 2020 13:54:35 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149698-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149698: all pass - PUSHED
X-Osstest-Versions-This: ovmf=c884b23ac40a1b1f56e21ebbb1f602fa2e0f05c9
X-Osstest-Versions-That: ovmf=a7947b6366a660d4d655371fe6bc96315097c06d
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 13:54:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

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

Last test of basis   149694  2020-04-16 21:41:26 Z    0 days
Testing same since   149698  2020-04-17 07:50:32 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Pierre Gondois <pierre.gondois@arm.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   a7947b6366..c884b23ac4  c884b23ac40a1b1f56e21ebbb1f602fa2e0f05c9 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:23:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRth-0007S6-LB; Fri, 17 Apr 2020 14:23:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRtg-0007S1-GO
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:23:12 +0000
X-Inumbo-ID: f6666f1a-80b6-11ea-8d02-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f6666f1a-80b6-11ea-8d02-12813bfff9fa;
 Fri, 17 Apr 2020 14:23:10 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 37530AB5F;
 Fri, 17 Apr 2020 14:23:08 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH 00/10] x86: mm (mainly shadow) adjustments
Message-ID: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Date: Fri, 17 Apr 2020 16:23:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Large parts of this series are to further isolate pieces which
are needed for HVM only, and hence would better not be built
with HVM=n. But there are also a few other items which I've
noticed along the road.

01: mm: no-one passes a NULL domain to init_xen_l4_slots()
02: shadow: drop a stray forward structure declaration
03: shadow: monitor table is HVM-only
04: shadow: sh_update_linear_entries() is a no-op for PV
05: mm: monitor table is HVM-only
06: shadow: sh_remove_write_access_from_sl1p() can be static
07: shadow: the guess_wrmap() hook is needed for HVM only
08: mm: pagetable_dying() is HVM-only
09: shadow: the trace_emul_write_val() hook is HVM-only
10: shadow: don't open-code shadow_blow_tables_per_domain()

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:25:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRvf-0007Xr-43; Fri, 17 Apr 2020 14:25:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRve-0007Xl-8x
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:25:14 +0000
X-Inumbo-ID: 4025c09c-80b7-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4025c09c-80b7-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 14:25:13 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 20A21AB5F;
 Fri, 17 Apr 2020 14:25:12 +0000 (UTC)
Subject: [PATCH 01/10] x86/mm: no-one passes a NULL domain to
 init_xen_l4_slots()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <19d7ad4f-c653-b7b6-59a8-90c9700c9200@suse.com>
Date: Fri, 17 Apr 2020 16:25:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Drop the NULL checks - they've been introduced by commit 8d7b633ada
("x86/mm: Consolidate all Xen L4 slot writing into
init_xen_l4_slots()") for no apparent reason.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1696,7 +1696,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t
      * PV vcpus need a shortened directmap.  HVM and Idle vcpus get the full
      * directmap.
      */
-    bool short_directmap = d && !paging_mode_external(d);
+    bool short_directmap = !paging_mode_external(d);
 
     /* Slot 256: RO M2P (if applicable). */
     l4t[l4_table_offset(RO_MPT_VIRT_START)] =
@@ -1717,10 +1717,9 @@ void init_xen_l4_slots(l4_pgentry_t *l4t
         mfn_eq(sl4mfn, INVALID_MFN) ? l4e_empty() :
         l4e_from_mfn(sl4mfn, __PAGE_HYPERVISOR_RW);
 
-    /* Slot 260: Per-domain mappings (if applicable). */
+    /* Slot 260: Per-domain mappings. */
     l4t[l4_table_offset(PERDOMAIN_VIRT_START)] =
-        d ? l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW)
-          : l4e_empty();
+        l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
 
     /* Slot 261-: text/data/bss, RW M2P, vmap, frametable, directmap. */
 #ifndef NDEBUG



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:25:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:25:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRwH-0007cG-FO; Fri, 17 Apr 2020 14:25:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRwF-0007c3-Os
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:25:51 +0000
X-Inumbo-ID: 569d068c-80b7-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 569d068c-80b7-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 14:25:51 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C3AD1AB5F;
 Fri, 17 Apr 2020 14:25:49 +0000 (UTC)
Subject: [PATCH 02/10] x86/shadow: drop a stray forward structure declaration
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <deb5a6e0-36bf-0efa-f161-8901468cc700@suse.com>
Date: Fri, 17 Apr 2020 16:25:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

struct sh_emulate_ctxt is private to shadow code, and hence a
declaration for it is not needed here.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -92,7 +92,6 @@
  * These shouldn't be used directly by callers; rather use the functions
  * below which will indirect through this table as appropriate. */
 
-struct sh_emulate_ctxt;
 struct shadow_paging_mode {
 #ifdef CONFIG_SHADOW_PAGING
     void          (*detach_old_tables     )(struct vcpu *v);



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:26:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRwm-0007gZ-R1; Fri, 17 Apr 2020 14:26:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRwk-0007gH-Qc
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:26:22 +0000
X-Inumbo-ID: 68fc7740-80b7-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 68fc7740-80b7-11ea-9e09-bc764e2007e4;
 Fri, 17 Apr 2020 14:26:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 73F58AC6C;
 Fri, 17 Apr 2020 14:26:20 +0000 (UTC)
Subject: [PATCH 03/10] x86/shadow: monitor table is HVM-only
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <7aa11566-289c-41c2-ec90-c15e0a6490cb@suse.com>
Date: Fri, 17 Apr 2020 16:26:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2376,7 +2376,6 @@ void sh_reset_l3_up_pointers(struct vcpu
 static void sh_update_paging_modes(struct vcpu *v)
 {
     struct domain *d = v->domain;
-    const struct paging_mode *old_mode = v->arch.paging.mode;
 
     ASSERT(paging_locked_by_me(d));
 
@@ -2421,11 +2420,14 @@ static void sh_update_paging_modes(struc
     if ( v->arch.paging.mode )
         v->arch.paging.mode->shadow.detach_old_tables(v);
 
+#ifdef CONFIG_HVM
     if ( !is_pv_domain(d) )
     {
         ///
         /// HVM guest
         ///
+        const struct paging_mode *old_mode = v->arch.paging.mode;
+
         ASSERT(shadow_mode_translate(d));
         ASSERT(shadow_mode_external(d));
 
@@ -2523,6 +2525,7 @@ static void sh_update_paging_modes(struc
         //        different values for CR4.PSE and CR4.PGE at the same time.
         //        This *does* happen, at least for CR4.PGE...
     }
+#endif /* CONFIG_HVM */
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
     /* We need to check that all the vcpus have paging enabled to
@@ -2703,7 +2706,6 @@ void shadow_teardown(struct domain *d, b
  * Should only be called for dying domains. */
 {
     struct vcpu *v;
-    mfn_t mfn;
     struct page_info *unpaged_pagetable = NULL;
 
     ASSERT(d->is_dying);
@@ -2719,13 +2721,16 @@ void shadow_teardown(struct domain *d, b
             if ( v->arch.paging.mode )
             {
                 v->arch.paging.mode->shadow.detach_old_tables(v);
+#ifdef CONFIG_HVM
                 if ( shadow_mode_external(d) )
                 {
-                    mfn = pagetable_get_mfn(v->arch.monitor_table);
+                    mfn_t mfn = pagetable_get_mfn(v->arch.monitor_table);
+
                     if ( mfn_valid(mfn) && (mfn_x(mfn) != 0) )
                         v->arch.paging.mode->shadow.destroy_monitor_table(v, mfn);
                     v->arch.monitor_table = pagetable_null();
                 }
+#endif /* CONFIG_HVM */
             }
         }
     }
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1515,7 +1515,7 @@ make_fl1_shadow(struct domain *d, gfn_t
 }
 
 
-#if SHADOW_PAGING_LEVELS == GUEST_PAGING_LEVELS
+#if SHADOW_PAGING_LEVELS == GUEST_PAGING_LEVELS && defined(CONFIG_HVM)
 mfn_t
 sh_make_monitor_table(struct vcpu *v)
 {
@@ -1965,7 +1965,7 @@ void sh_destroy_l1_shadow(struct domain
     shadow_free(d, smfn);
 }
 
-#if SHADOW_PAGING_LEVELS == GUEST_PAGING_LEVELS
+#if SHADOW_PAGING_LEVELS == GUEST_PAGING_LEVELS && defined(CONFIG_HVM)
 void sh_destroy_monitor_table(struct vcpu *v, mfn_t mmfn)
 {
     struct domain *d = v->domain;
@@ -4881,8 +4881,10 @@ const struct paging_mode sh_paging_mode
     .shadow.write_guest_entry      = sh_write_guest_entry,
     .shadow.cmpxchg_guest_entry    = sh_cmpxchg_guest_entry,
 #endif
+#ifdef CONFIG_HVM
     .shadow.make_monitor_table     = sh_make_monitor_table,
     .shadow.destroy_monitor_table  = sh_destroy_monitor_table,
+#endif
 #if SHADOW_OPTIMIZATIONS & SHOPT_WRITABLE_HEURISTIC
     .shadow.guess_wrmap            = sh_guess_wrmap,
 #endif
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -102,8 +102,10 @@ struct shadow_paging_mode {
                                             intpte_t *old, intpte_t new,
                                             mfn_t gmfn);
 #endif
+#ifdef CONFIG_HVM
     mfn_t         (*make_monitor_table    )(struct vcpu *v);
     void          (*destroy_monitor_table )(struct vcpu *v, mfn_t mmfn);
+#endif
     int           (*guess_wrmap           )(struct vcpu *v, 
                                             unsigned long vaddr, mfn_t gmfn);
     void          (*pagetable_dying       )(paddr_t gpa);



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:27:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:27:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRxN-0007mh-7P; Fri, 17 Apr 2020 14:27:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRxM-0007mY-D6
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:27:00 +0000
X-Inumbo-ID: 7f0237f1-80b7-11ea-8d02-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7f0237f1-80b7-11ea-8d02-12813bfff9fa;
 Fri, 17 Apr 2020 14:26:59 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 11B42ACC2;
 Fri, 17 Apr 2020 14:26:58 +0000 (UTC)
Subject: [PATCH 04/10] x86/shadow: sh_update_linear_entries() is a no-op for PV
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <e5457534-6491-b9be-e61d-d669a8e7656e@suse.com>
Date: Fri, 17 Apr 2020 16:26:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Consolidate the shadow_mode_external() in here: Check this once at the
start of the function.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3707,34 +3707,30 @@ sh_update_linear_entries(struct vcpu *v)
      */
 
     /* Don't try to update the monitor table if it doesn't exist */
-    if ( shadow_mode_external(d)
-         && pagetable_get_pfn(v->arch.monitor_table) == 0 )
+    if ( !shadow_mode_external(d) ||
+         pagetable_get_pfn(v->arch.monitor_table) == 0 )
         return;
 
 #if SHADOW_PAGING_LEVELS == 4
 
-    /* For PV, one l4e points at the guest l4, one points at the shadow
-     * l4.  No maintenance required.
-     * For HVM, just need to update the l4e that points to the shadow l4. */
+    /* For HVM, just need to update the l4e that points to the shadow l4. */
 
-    if ( shadow_mode_external(d) )
+    /* Use the linear map if we can; otherwise make a new mapping */
+    if ( v == current )
     {
-        /* Use the linear map if we can; otherwise make a new mapping */
-        if ( v == current )
-        {
-            __linear_l4_table[l4_linear_offset(SH_LINEAR_PT_VIRT_START)] =
-                l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
-                             __PAGE_HYPERVISOR_RW);
-        }
-        else
-        {
-            l4_pgentry_t *ml4e;
-            ml4e = map_domain_page(pagetable_get_mfn(v->arch.monitor_table));
-            ml4e[l4_table_offset(SH_LINEAR_PT_VIRT_START)] =
-                l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
-                             __PAGE_HYPERVISOR_RW);
-            unmap_domain_page(ml4e);
-        }
+        __linear_l4_table[l4_linear_offset(SH_LINEAR_PT_VIRT_START)] =
+            l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
+                         __PAGE_HYPERVISOR_RW);
+    }
+    else
+    {
+        l4_pgentry_t *ml4e;
+
+        ml4e = map_domain_page(pagetable_get_mfn(v->arch.monitor_table));
+        ml4e[l4_table_offset(SH_LINEAR_PT_VIRT_START)] =
+            l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
+                         __PAGE_HYPERVISOR_RW);
+        unmap_domain_page(ml4e);
     }
 
 #elif SHADOW_PAGING_LEVELS == 3
@@ -3748,7 +3744,6 @@ sh_update_linear_entries(struct vcpu *v)
      * the shadows.
      */
 
-    ASSERT(shadow_mode_external(d));
     {
         /* Install copies of the shadow l3es into the monitor l2 table
          * that maps SH_LINEAR_PT_VIRT_START. */
@@ -3799,20 +3794,16 @@ sh_update_linear_entries(struct vcpu *v)
 #error this should not happen
 #endif
 
-    if ( shadow_mode_external(d) )
-    {
-        /*
-         * Having modified the linear pagetable mapping, flush local host TLBs.
-         * This was not needed when vmenter/vmexit always had the side effect
-         * of flushing host TLBs but, with ASIDs, it is possible to finish
-         * this CR3 update, vmenter the guest, vmexit due to a page fault,
-         * without an intervening host TLB flush. Then the page fault code
-         * could use the linear pagetable to read a top-level shadow page
-         * table entry. But, without this change, it would fetch the wrong
-         * value due to a stale TLB.
-         */
-        flush_tlb_local();
-    }
+    /*
+     * Having modified the linear pagetable mapping, flush local host TLBs.
+     * This was not needed when vmenter/vmexit always had the side effect of
+     * flushing host TLBs but, with ASIDs, it is possible to finish this CR3
+     * update, vmenter the guest, vmexit due to a page fault, without an
+     * intervening host TLB flush. Then the page fault code could use the
+     * linear pagetable to read a top-level shadow page table entry. But,
+     * without this change, it would fetch the wrong value due to a stale TLB.
+     */
+    flush_tlb_local();
 }
 
 



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:27:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRxs-0007sE-KH; Fri, 17 Apr 2020 14:27:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRxr-0007s0-8s
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:27:31 +0000
X-Inumbo-ID: 91a4a7ee-80b7-11ea-8d02-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 91a4a7ee-80b7-11ea-8d02-12813bfff9fa;
 Fri, 17 Apr 2020 14:27:30 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B00A3AB5F;
 Fri, 17 Apr 2020 14:27:28 +0000 (UTC)
Subject: [PATCH 05/10] x86/mm: monitor table is HVM-only
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <e175a985-bdb9-d8e6-2f84-76abdcc24188@suse.com>
Date: Fri, 17 Apr 2020 16:27:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Move the per-vCPU field to the HVM sub-structure.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -545,7 +545,7 @@ void write_ptbase(struct vcpu *v)
  * Should be called after CR3 is updated.
  *
  * Uses values found in vcpu->arch.(guest_table and guest_table_user), and
- * for HVM guests, arch.monitor_table and hvm's guest CR3.
+ * for HVM guests, arch.hvm.monitor_table and hvm's guest CR3.
  *
  * Update ref counts to shadow tables appropriately.
  */
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -393,7 +393,7 @@ static mfn_t hap_make_monitor_table(stru
     l4_pgentry_t *l4e;
     mfn_t m4mfn;
 
-    ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0);
+    ASSERT(pagetable_get_pfn(v->arch.hvm.monitor_table) == 0);
 
     if ( (pg = hap_alloc(d)) == NULL )
         goto oom;
@@ -579,10 +579,10 @@ void hap_teardown(struct domain *d, bool
         {
             if ( paging_get_hostmode(v) && paging_mode_external(d) )
             {
-                mfn = pagetable_get_mfn(v->arch.monitor_table);
+                mfn = pagetable_get_mfn(v->arch.hvm.monitor_table);
                 if ( mfn_valid(mfn) && (mfn_x(mfn) != 0) )
                     hap_destroy_monitor_table(v, mfn);
-                v->arch.monitor_table = pagetable_null();
+                v->arch.hvm.monitor_table = pagetable_null();
             }
         }
     }
@@ -758,10 +758,10 @@ static void hap_update_paging_modes(stru
 
     v->arch.paging.mode = hap_paging_get_mode(v);
 
-    if ( pagetable_is_null(v->arch.monitor_table) )
+    if ( pagetable_is_null(v->arch.hvm.monitor_table) )
     {
         mfn_t mmfn = hap_make_monitor_table(v);
-        v->arch.monitor_table = pagetable_from_mfn(mmfn);
+        v->arch.hvm.monitor_table = pagetable_from_mfn(mmfn);
         make_cr3(v, mmfn);
         hvm_update_host_cr3(v);
     }
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2465,10 +2465,10 @@ static void sh_update_paging_modes(struc
                 &SHADOW_INTERNAL_NAME(sh_paging_mode, 2);
         }
 
-        if ( pagetable_is_null(v->arch.monitor_table) )
+        if ( pagetable_is_null(v->arch.hvm.monitor_table) )
         {
             mfn_t mmfn = v->arch.paging.mode->shadow.make_monitor_table(v);
-            v->arch.monitor_table = pagetable_from_mfn(mmfn);
+            v->arch.hvm.monitor_table = pagetable_from_mfn(mmfn);
             make_cr3(v, mmfn);
             hvm_update_host_cr3(v);
         }
@@ -2502,10 +2502,10 @@ static void sh_update_paging_modes(struc
                     return;
                 }
 
-                old_mfn = pagetable_get_mfn(v->arch.monitor_table);
-                v->arch.monitor_table = pagetable_null();
+                old_mfn = pagetable_get_mfn(v->arch.hvm.monitor_table);
+                v->arch.hvm.monitor_table = pagetable_null();
                 new_mfn = v->arch.paging.mode->shadow.make_monitor_table(v);
-                v->arch.monitor_table = pagetable_from_mfn(new_mfn);
+                v->arch.hvm.monitor_table = pagetable_from_mfn(new_mfn);
                 SHADOW_PRINTK("new monitor table %"PRI_mfn "\n",
                                mfn_x(new_mfn));
 
@@ -2724,11 +2724,11 @@ void shadow_teardown(struct domain *d, b
 #ifdef CONFIG_HVM
                 if ( shadow_mode_external(d) )
                 {
-                    mfn_t mfn = pagetable_get_mfn(v->arch.monitor_table);
+                    mfn_t mfn = pagetable_get_mfn(v->arch.hvm.monitor_table);
 
                     if ( mfn_valid(mfn) && (mfn_x(mfn) != 0) )
                         v->arch.paging.mode->shadow.destroy_monitor_table(v, mfn);
-                    v->arch.monitor_table = pagetable_null();
+                    v->arch.hvm.monitor_table = pagetable_null();
                 }
 #endif /* CONFIG_HVM */
             }
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1521,7 +1521,7 @@ sh_make_monitor_table(struct vcpu *v)
 {
     struct domain *d = v->domain;
 
-    ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0);
+    ASSERT(pagetable_get_pfn(v->arch.hvm.monitor_table) == 0);
 
     /* Guarantee we can get the memory we need */
     shadow_prealloc(d, SH_type_monitor_table, CONFIG_PAGING_LEVELS);
@@ -3708,7 +3708,7 @@ sh_update_linear_entries(struct vcpu *v)
 
     /* Don't try to update the monitor table if it doesn't exist */
     if ( !shadow_mode_external(d) ||
-         pagetable_get_pfn(v->arch.monitor_table) == 0 )
+         pagetable_get_pfn(v->arch.hvm.monitor_table) == 0 )
         return;
 
 #if SHADOW_PAGING_LEVELS == 4
@@ -3726,7 +3726,7 @@ sh_update_linear_entries(struct vcpu *v)
     {
         l4_pgentry_t *ml4e;
 
-        ml4e = map_domain_page(pagetable_get_mfn(v->arch.monitor_table));
+        ml4e = map_domain_page(pagetable_get_mfn(v->arch.hvm.monitor_table));
         ml4e[l4_table_offset(SH_LINEAR_PT_VIRT_START)] =
             l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
                          __PAGE_HYPERVISOR_RW);
@@ -3761,7 +3761,7 @@ sh_update_linear_entries(struct vcpu *v)
             l4_pgentry_t *ml4e;
             l3_pgentry_t *ml3e;
             int linear_slot = shadow_l4_table_offset(SH_LINEAR_PT_VIRT_START);
-            ml4e = map_domain_page(pagetable_get_mfn(v->arch.monitor_table));
+            ml4e = map_domain_page(pagetable_get_mfn(v->arch.hvm.monitor_table));
 
             ASSERT(l4e_get_flags(ml4e[linear_slot]) & _PAGE_PRESENT);
             l3mfn = l4e_get_mfn(ml4e[linear_slot]);
@@ -4096,7 +4096,7 @@ sh_update_cr3(struct vcpu *v, int do_loc
     ///
     if ( shadow_mode_external(d) )
     {
-        make_cr3(v, pagetable_get_mfn(v->arch.monitor_table));
+        make_cr3(v, pagetable_get_mfn(v->arch.hvm.monitor_table));
     }
 #if SHADOW_PAGING_LEVELS == 4
     else // not shadow_mode_external...
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -581,7 +581,6 @@ struct arch_vcpu
     /* guest_table holds a ref to the page, and also a type-count unless
      * shadow refcounts are in use */
     pagetable_t shadow_table[4];        /* (MFN) shadow(s) of guest */
-    pagetable_t monitor_table;          /* (MFN) hypervisor PT (for HVM) */
     unsigned long cr3;                  /* (MA) value to install in HW CR3 */
 
     /*
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -176,6 +176,9 @@ struct hvm_vcpu {
         uint16_t p2midx;
     } fast_single_step;
 
+    /* (MFN) hypervisor page table */
+    pagetable_t         monitor_table;
+
     struct hvm_vcpu_asid n1asid;
 
     u64                 msr_tsc_adjust;



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:27:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRyJ-0007y9-4p; Fri, 17 Apr 2020 14:27:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRyH-0007xJ-0x
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:27:57 +0000
X-Inumbo-ID: a13dc2f8-80b7-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a13dc2f8-80b7-11ea-9e09-bc764e2007e4;
 Fri, 17 Apr 2020 14:27:56 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CD821AB5F;
 Fri, 17 Apr 2020 14:27:54 +0000 (UTC)
Subject: [PATCH 06/10] x86/shadow: sh_remove_write_access_from_sl1p() can be
 static
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <56e38dfd-2733-b669-180a-5876a339c60a@suse.com>
Date: Fri, 17 Apr 2020 16:27:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It's only used by common.c.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -38,6 +38,9 @@
 #include <xen/numa.h>
 #include "private.h"
 
+static int sh_remove_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
+                                            mfn_t smfn, unsigned long offset);
+
 DEFINE_PER_CPU(uint32_t,trace_shadow_path_flags);
 
 static int sh_enable_log_dirty(struct domain *, bool log_global);
@@ -1999,8 +2002,8 @@ int sh_remove_write_access(struct domain
 }
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
-int sh_remove_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
-                                     mfn_t smfn, unsigned long off)
+static int sh_remove_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
+                                            mfn_t smfn, unsigned long off)
 {
     struct page_info *sp = mfn_to_page(smfn);
 
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -396,9 +396,6 @@ void sh_resync(struct domain *d, mfn_t g
 
 void oos_fixup_add(struct domain *d, mfn_t gmfn, mfn_t smfn, unsigned long off);
 
-int sh_remove_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
-                                     mfn_t smfn, unsigned long offset);
-
 /* Pull all out-of-sync shadows back into sync.  If skip != 0, we try
  * to avoid resyncing where we think we can get away with it. */
 



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:28:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:28:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRyf-00082e-IX; Fri, 17 Apr 2020 14:28:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRye-00082I-46
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:28:20 +0000
X-Inumbo-ID: aed63b20-80b7-11ea-8d02-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id aed63b20-80b7-11ea-8d02-12813bfff9fa;
 Fri, 17 Apr 2020 14:28:19 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B159EAB5F;
 Fri, 17 Apr 2020 14:28:17 +0000 (UTC)
Subject: [PATCH 07/10] x86/shadow: the guess_wrmap() hook is needed for HVM
 only
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <1e221192-7899-b60d-0280-b77ab5877772@suse.com>
Date: Fri, 17 Apr 2020 16:28:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

sh_remove_write_access() bails early for !external guests, and hence its
building and thus the need for the hook can be suppressed altogether in
!HVM configs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1769,6 +1769,7 @@ static inline void trace_shadow_wrmap_bf
     }
 }
 
+#ifdef CONFIG_HVM
 /**************************************************************************/
 /* Remove all writeable mappings of a guest frame from the shadow tables
  * Returns non-zero if we need to flush TLBs.
@@ -2000,6 +2001,7 @@ int sh_remove_write_access(struct domain
     /* We killed at least one writeable mapping, so must flush TLBs. */
     return 1;
 }
+#endif /* CONFIG_HVM */
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
 static int sh_remove_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4203,7 +4203,7 @@ int sh_rm_write_access_from_sl1p(struct
 }
 #endif /* OOS */
 
-#if SHADOW_OPTIMIZATIONS & SHOPT_WRITABLE_HEURISTIC
+#if defined(CONFIG_HVM) && (SHADOW_OPTIMIZATIONS & SHOPT_WRITABLE_HEURISTIC)
 static int sh_guess_wrmap(struct vcpu *v, unsigned long vaddr, mfn_t gmfn)
 /* Look up this vaddr in the current shadow and see if it's a writeable
  * mapping of this gmfn.  If so, remove it.  Returns 1 if it worked. */
@@ -4875,10 +4875,10 @@ const struct paging_mode sh_paging_mode
 #ifdef CONFIG_HVM
     .shadow.make_monitor_table     = sh_make_monitor_table,
     .shadow.destroy_monitor_table  = sh_destroy_monitor_table,
-#endif
 #if SHADOW_OPTIMIZATIONS & SHOPT_WRITABLE_HEURISTIC
     .shadow.guess_wrmap            = sh_guess_wrmap,
 #endif
+#endif /* CONFIG_HVM */
     .shadow.pagetable_dying        = sh_pagetable_dying,
     .shadow.trace_emul_write_val   = trace_emulate_write_val,
     .shadow.shadow_levels          = SHADOW_PAGING_LEVELS,
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -359,6 +359,7 @@ void sh_install_xen_entries_in_l4(struct
 /* Update the shadows in response to a pagetable write from Xen */
 int sh_validate_guest_entry(struct vcpu *v, mfn_t gmfn, void *entry, u32 size);
 
+#ifdef CONFIG_HVM
 /* Remove all writeable mappings of a guest frame from the shadows.
  * Returns non-zero if we need to flush TLBs.
  * level and fault_addr desribe how we found this to be a pagetable;
@@ -366,6 +367,14 @@ int sh_validate_guest_entry(struct vcpu
 extern int sh_remove_write_access(struct domain *d, mfn_t readonly_mfn,
                                   unsigned int level,
                                   unsigned long fault_addr);
+#else
+static inline int sh_remove_write_access(struct domain *d, mfn_t readonly_mfn,
+                                         unsigned int level,
+                                         unsigned long fault_addr)
+{
+    return 0;
+}
+#endif
 
 /* Functions that atomically write PT/P2M entries and update state */
 int shadow_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -105,9 +105,9 @@ struct shadow_paging_mode {
 #ifdef CONFIG_HVM
     mfn_t         (*make_monitor_table    )(struct vcpu *v);
     void          (*destroy_monitor_table )(struct vcpu *v, mfn_t mmfn);
-#endif
     int           (*guess_wrmap           )(struct vcpu *v, 
                                             unsigned long vaddr, mfn_t gmfn);
+#endif
     void          (*pagetable_dying       )(paddr_t gpa);
     void          (*trace_emul_write_val  )(const void *ptr, unsigned long vaddr,
                                             const void *src, unsigned int bytes);



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:28:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRzA-0008As-V9; Fri, 17 Apr 2020 14:28:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRz9-0008Ah-Qj
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:28:51 +0000
X-Inumbo-ID: c18f7024-80b7-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c18f7024-80b7-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 14:28:50 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 38320AB5F;
 Fri, 17 Apr 2020 14:28:49 +0000 (UTC)
Subject: [PATCH 08/10] x86/mm: pagetable_dying() is HVM-only
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <c8ca6185-3242-b259-a16a-3d14e896e9f2@suse.com>
Date: Fri, 17 Apr 2020 16:28:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Its only caller lives in HVM-only code.

This involves wider changes, in order to limit #ifdef-ary: Shadow's
SHOPT_FAST_EMULATION and the fields used by it get constrained to HVM
builds as well. Additionally the shadow_{init,continue}_emulation()
stubs for the !HVM case aren't needed anymore and hence get dropped.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -851,6 +851,7 @@ int paging_enable(struct domain *d, u32
         return shadow_enable(d, mode);
 }
 
+#ifdef CONFIG_HVM
 /* Called from the guest to indicate that a process is being torn down
  * and therefore its pagetables will soon be discarded */
 void pagetable_dying(paddr_t gpa)
@@ -865,6 +866,7 @@ void pagetable_dying(paddr_t gpa)
     BUG();
 #endif
 }
+#endif /* CONFIG_HVM */
 
 /* Print paging-assistance info to the console */
 void paging_dump_domain_info(struct domain *d)
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -66,7 +66,9 @@ int shadow_domain_init(struct domain *d)
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
     d->arch.paging.shadow.oos_active = 0;
 #endif
+#ifdef CONFIG_HVM
     d->arch.paging.shadow.pagetable_dying_op = 0;
+#endif
 
     return 0;
 }
@@ -690,8 +692,10 @@ void shadow_promote(struct domain *d, mf
     if ( !test_and_set_bit(_PGC_page_table, &page->count_info) )
     {
         page->shadow_flags = 0;
+#ifdef CONFIG_HVM
         if ( is_hvm_domain(d) )
             page->pagetable_dying = false;
+#endif
     }
 
     ASSERT(!(page->shadow_flags & (1u << type)));
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2764,8 +2764,10 @@ static int sh_page_fault(struct vcpu *v,
     mfn_t gmfn, sl1mfn = _mfn(0);
     shadow_l1e_t sl1e, *ptr_sl1e;
     paddr_t gpa;
+#ifdef CONFIG_HVM
     struct sh_emulate_ctxt emul_ctxt;
     const struct x86_emulate_ops *emul_ops;
+#endif
     int r;
     p2m_type_t p2mt;
     uint32_t rc, error_code;
@@ -3253,7 +3255,13 @@ static int sh_page_fault(struct vcpu *v,
      * caught by user-mode page-table check above.
      */
  emulate_readonly:
+    if ( !is_hvm_domain(d) )
+    {
+        ASSERT_UNREACHABLE();
+        goto not_a_shadow_fault;
+    }
 
+#ifdef CONFIG_HVM
     /* Unshadow if we are writing to a toplevel pagetable that is
      * flagged as a dying process, and that is not currently used. */
     if ( sh_mfn_is_a_page_table(gmfn) && is_hvm_domain(d) &&
@@ -3302,31 +3310,28 @@ static int sh_page_fault(struct vcpu *v,
 #if SHADOW_OPTIMIZATIONS & SHOPT_FAST_EMULATION
  early_emulation:
 #endif
-    if ( is_hvm_domain(d) )
+    /*
+     * If we are in the middle of injecting an exception or interrupt then
+     * we should not emulate: the fault is a side effect of the processor
+     * trying to deliver the exception (e.g. IDT/GDT accesses, pushing the
+     * exception frame onto the stack).  Furthermore it is almost
+     * certainly the case the handler stack is currently considered to be
+     * a page table, so we should unshadow the faulting page before
+     * exiting.
+     */
+    if ( unlikely(hvm_event_pending(v)) )
     {
-        /*
-         * If we are in the middle of injecting an exception or interrupt then
-         * we should not emulate: the fault is a side effect of the processor
-         * trying to deliver the exception (e.g. IDT/GDT accesses, pushing the
-         * exception frame onto the stack).  Furthermore it is almost
-         * certainly the case the handler stack is currently considered to be
-         * a page table, so we should unshadow the faulting page before
-         * exiting.
-         */
-        if ( unlikely(hvm_event_pending(v)) )
-        {
 #if SHADOW_OPTIMIZATIONS & SHOPT_FAST_EMULATION
-            if ( fast_emul )
-            {
-                perfc_incr(shadow_fault_fast_emulate_fail);
-                v->arch.paging.last_write_emul_ok = 0;
-            }
-#endif
-            sh_remove_shadows(d, gmfn, 0 /* thorough */, 1 /* must succeed */);
-            trace_shadow_emulate_other(TRC_SHADOW_EMULATE_UNSHADOW_EVTINJ,
-                                       va, gfn);
-            return EXCRET_fault_fixed;
+        if ( fast_emul )
+        {
+            perfc_incr(shadow_fault_fast_emulate_fail);
+            v->arch.paging.last_write_emul_ok = 0;
         }
+#endif
+        sh_remove_shadows(d, gmfn, 0 /* thorough */, 1 /* must succeed */);
+        trace_shadow_emulate_other(TRC_SHADOW_EMULATE_UNSHADOW_EVTINJ,
+                                   va, gfn);
+        return EXCRET_fault_fixed;
     }
 
     SHADOW_PRINTK("emulate: eip=%#lx esp=%#lx\n", regs->rip, regs->rsp);
@@ -3334,11 +3339,8 @@ static int sh_page_fault(struct vcpu *v,
     emul_ops = shadow_init_emulation(&emul_ctxt, regs, GUEST_PTE_SIZE);
 
     r = x86_emulate(&emul_ctxt.ctxt, emul_ops);
-
-#ifdef CONFIG_HVM
     if ( r == X86EMUL_EXCEPTION )
     {
-        ASSERT(is_hvm_domain(d));
         /*
          * This emulation covers writes to shadow pagetables.  We tolerate #PF
          * (from accesses spanning pages, concurrent paging updated from
@@ -3360,7 +3362,6 @@ static int sh_page_fault(struct vcpu *v,
             r = X86EMUL_UNHANDLEABLE;
         }
     }
-#endif
 
     /*
      * NB. We do not unshadow on X86EMUL_EXCEPTION. It's not clear that it
@@ -3466,6 +3467,7 @@ static int sh_page_fault(struct vcpu *v,
  emulate_done:
     SHADOW_PRINTK("emulated\n");
     return EXCRET_fault_fixed;
+#endif /* CONFIG_HVM */
 
  mmio:
     if ( !guest_mode(regs) )
@@ -4157,7 +4159,9 @@ sh_update_cr3(struct vcpu *v, int do_loc
 int sh_rm_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
                                  mfn_t smfn, unsigned long off)
 {
+#ifdef CONFIG_HVM
     struct vcpu *curr = current;
+#endif
     int r;
     shadow_l1e_t *sl1p, sl1e;
     struct page_info *sp;
@@ -4165,10 +4169,12 @@ int sh_rm_write_access_from_sl1p(struct
     ASSERT(mfn_valid(gmfn));
     ASSERT(mfn_valid(smfn));
 
+#ifdef CONFIG_HVM
     /* Remember if we've been told that this process is being torn down */
     if ( curr->domain == d && is_hvm_domain(d) )
         curr->arch.paging.shadow.pagetable_dying
             = mfn_to_page(gmfn)->pagetable_dying;
+#endif
 
     sp = mfn_to_page(smfn);
 
@@ -4424,6 +4430,7 @@ int sh_remove_l3_shadow(struct domain *d
 }
 #endif /* 64bit guest */
 
+#ifdef CONFIG_HVM
 /**************************************************************************/
 /* Function for the guest to inform us that a process is being torn
  * down.  We remember that as a hint to unshadow its pagetables soon,
@@ -4545,6 +4552,7 @@ static void sh_pagetable_dying(paddr_t g
     put_gfn(d, gpa >> PAGE_SHIFT);
 }
 #endif
+#endif /* CONFIG_HVM */
 
 /**************************************************************************/
 /* Audit tools */
@@ -4878,8 +4886,8 @@ const struct paging_mode sh_paging_mode
 #if SHADOW_OPTIMIZATIONS & SHOPT_WRITABLE_HEURISTIC
     .shadow.guess_wrmap            = sh_guess_wrmap,
 #endif
-#endif /* CONFIG_HVM */
     .shadow.pagetable_dying        = sh_pagetable_dying,
+#endif /* CONFIG_HVM */
     .shadow.trace_emul_write_val   = trace_emulate_write_val,
     .shadow.shadow_levels          = SHADOW_PAGING_LEVELS,
 };
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -66,7 +66,11 @@ extern int shadow_audit_enable;
 #define SHOPT_FAST_EMULATION      0x80  /* Fast write emulation */
 #define SHOPT_OUT_OF_SYNC        0x100  /* Allow guest writes to L1 PTs */
 
+#ifdef CONFIG_HVM
 #define SHADOW_OPTIMIZATIONS     0x1ff
+#else
+#define SHADOW_OPTIMIZATIONS     (0x1ff & ~SHOPT_FAST_EMULATION)
+#endif
 
 
 /******************************************************************************
@@ -715,26 +719,11 @@ struct sh_emulate_ctxt {
 #endif
 };
 
-#ifdef CONFIG_HVM
 const struct x86_emulate_ops *shadow_init_emulation(
     struct sh_emulate_ctxt *sh_ctxt, struct cpu_user_regs *regs,
     unsigned int pte_size);
 void shadow_continue_emulation(
     struct sh_emulate_ctxt *sh_ctxt, struct cpu_user_regs *regs);
-#else
-static inline const struct x86_emulate_ops *shadow_init_emulation(
-    struct sh_emulate_ctxt *sh_ctxt, struct cpu_user_regs *regs,
-    unsigned int pte_size)
-{
-    BUG();
-    return NULL;
-}
-static inline void shadow_continue_emulation(
-    struct sh_emulate_ctxt *sh_ctxt, struct cpu_user_regs *regs)
-{
-    BUG();
-}
-#endif
 
 /* Stop counting towards early unshadows, as we've seen a real page fault */
 static inline void sh_reset_early_unshadow(struct vcpu *v)
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -117,8 +117,10 @@ struct shadow_domain {
     /* OOS */
     bool_t oos_active;
 
+#ifdef CONFIG_HVM
     /* Has this domain ever used HVMOP_pagetable_dying? */
     bool_t pagetable_dying_op;
+#endif
 
 #ifdef CONFIG_PV
     /* PV L1 Terminal Fault mitigation. */
@@ -137,10 +139,12 @@ struct shadow_vcpu {
     unsigned long last_emulated_mfn_for_unshadow;
     /* MFN of the last shadow that we shot a writeable mapping in */
     unsigned long last_writeable_pte_smfn;
+#ifdef CONFIG_HVM
     /* Last frame number that we emulated a write to. */
     unsigned long last_emulated_frame;
     /* Last MFN that we emulated a write successfully */
     unsigned long last_emulated_mfn;
+#endif
 
     /* Shadow out-of-sync: pages that this vcpu has let go out of sync */
     mfn_t oos[SHADOW_OOS_PAGES];
@@ -151,8 +155,10 @@ struct shadow_vcpu {
         unsigned long off[SHADOW_OOS_FIXUPS];
     } oos_fixup[SHADOW_OOS_PAGES];
 
+#ifdef CONFIG_HVM
     bool_t pagetable_dying;
 #endif
+#endif
 };
 
 /************************************************/
@@ -225,10 +231,12 @@ struct paging_vcpu {
     const struct paging_mode *mode;
     /* Nested Virtualization: paging mode of nested guest */
     const struct paging_mode *nestedmode;
+#ifdef CONFIG_HVM
     /* HVM guest: last emulate was to a pagetable */
     unsigned int last_write_was_pt:1;
     /* HVM guest: last write emulation succeeds */
     unsigned int last_write_emul_ok:1;
+#endif
     /* Translated guest: virtual TLB */
     struct shadow_vtlb *vtlb;
     spinlock_t          vtlb_lock;
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -287,7 +287,9 @@ struct page_info
          */
         struct {
             uint16_t shadow_flags;
+#ifdef CONFIG_HVM
             bool pagetable_dying;
+#endif
         };
 
         /* When in use as a shadow, next shadow in this hash chain. */
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -107,8 +107,8 @@ struct shadow_paging_mode {
     void          (*destroy_monitor_table )(struct vcpu *v, mfn_t mmfn);
     int           (*guess_wrmap           )(struct vcpu *v, 
                                             unsigned long vaddr, mfn_t gmfn);
-#endif
     void          (*pagetable_dying       )(paddr_t gpa);
+#endif
     void          (*trace_emul_write_val  )(const void *ptr, unsigned long vaddr,
                                             const void *src, unsigned int bytes);
 #endif



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:29:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPRza-0008Fb-AC; Fri, 17 Apr 2020 14:29:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPRzZ-0008FP-4H
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:29:17 +0000
X-Inumbo-ID: d1004c5e-80b7-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d1004c5e-80b7-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 14:29:16 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 21949AB64;
 Fri, 17 Apr 2020 14:29:14 +0000 (UTC)
Subject: [PATCH 09/10] x86/shadow: the trace_emul_write_val() hook is HVM-only
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <8d02bf12-1380-725b-7aca-a494c8258e54@suse.com>
Date: Fri, 17 Apr 2020 16:29:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Its only caller lives in HVM-only code, and the only caller of
trace_shadow_emulate() also already site in a HVM-only code section.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2694,6 +2694,7 @@ static inline void trace_shadow_emulate_
     }
 }
 
+#ifdef CONFIG_HVM
 #if GUEST_PAGING_LEVELS == 3
 static DEFINE_PER_CPU(guest_va_t,trace_emulate_initial_va);
 static DEFINE_PER_CPU(int,trace_extra_emulation_count);
@@ -2745,6 +2746,7 @@ static inline void trace_shadow_emulate(
         __trace_var(event, 0/*!tsc*/, sizeof(d), &d);
     }
 }
+#endif /* CONFIG_HVM */
 
 /**************************************************************************/
 /* Entry points into the shadow code */
@@ -4887,8 +4889,8 @@ const struct paging_mode sh_paging_mode
     .shadow.guess_wrmap            = sh_guess_wrmap,
 #endif
     .shadow.pagetable_dying        = sh_pagetable_dying,
-#endif /* CONFIG_HVM */
     .shadow.trace_emul_write_val   = trace_emulate_write_val,
+#endif /* CONFIG_HVM */
     .shadow.shadow_levels          = SHADOW_PAGING_LEVELS,
 };
 
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -108,10 +108,10 @@ struct shadow_paging_mode {
     int           (*guess_wrmap           )(struct vcpu *v, 
                                             unsigned long vaddr, mfn_t gmfn);
     void          (*pagetable_dying       )(paddr_t gpa);
-#endif
     void          (*trace_emul_write_val  )(const void *ptr, unsigned long vaddr,
                                             const void *src, unsigned int bytes);
 #endif
+#endif
     /* For outsiders to tell what mode we're in */
     unsigned int shadow_levels;
 };



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:29:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPS03-0008LO-Mf; Fri, 17 Apr 2020 14:29:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=x8HM=6B=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jPS02-0008LG-RE
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:29:46 +0000
X-Inumbo-ID: e2bccefe-80b7-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e2bccefe-80b7-11ea-9e09-bc764e2007e4;
 Fri, 17 Apr 2020 14:29:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B3842AC69;
 Fri, 17 Apr 2020 14:29:44 +0000 (UTC)
Subject: [PATCH 10/10] x86/shadow: don't open-code
 shadow_blow_tables_per_domain()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Message-ID: <6ca8bbff-1dcb-f57e-3d16-4cf3fef6555f@suse.com>
Date: Fri, 17 Apr 2020 16:29:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Make shadow_blow_all_tables() call the designated function, and this
occasion make the function itself use domain_vcpu().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1005,7 +1005,8 @@ static void shadow_blow_tables(struct do
 
 void shadow_blow_tables_per_domain(struct domain *d)
 {
-    if ( shadow_mode_enabled(d) && d->vcpu != NULL && d->vcpu[0] != NULL ) {
+    if ( shadow_mode_enabled(d) && domain_vcpu(d, 0) )
+    {
         paging_lock(d);
         shadow_blow_tables(d);
         paging_unlock(d);
@@ -1022,14 +1023,7 @@ static void shadow_blow_all_tables(unsig
     printk("'%c' pressed -> blowing all shadow tables\n", c);
     rcu_read_lock(&domlist_read_lock);
     for_each_domain(d)
-    {
-        if ( shadow_mode_enabled(d) && d->vcpu != NULL && d->vcpu[0] != NULL )
-        {
-            paging_lock(d);
-            shadow_blow_tables(d);
-            paging_unlock(d);
-        }
-    }
+        shadow_blow_tables_per_domain(d);
     rcu_read_unlock(&domlist_read_lock);
 }
 



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:36:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPS6f-0000q4-G8; Fri, 17 Apr 2020 14:36:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=H8UU=6B=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jPS6e-0000pz-Hh
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:36:36 +0000
X-Inumbo-ID: d681210c-80b8-11ea-8d07-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d681210c-80b8-11ea-8d07-12813bfff9fa;
 Fri, 17 Apr 2020 14:36:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C352BAC6C;
 Fri, 17 Apr 2020 14:36:33 +0000 (UTC)
Message-ID: <71fec2ed355f62bedff97d54a4d5ad9166a5a9c9.camel@suse.com>
Subject: Re: [PATCH] sched: print information about scheduler granularity
From: Dario Faggioli <dfaggioli@suse.com>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, Sergey Dyasli
 <sergey.dyasli@citrix.com>, xen-devel@lists.xenproject.org
Date: Fri, 17 Apr 2020 16:36:32 +0200
In-Reply-To: <3dacf98c-c4b7-a263-01d3-f8562619ff53@suse.com>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <d2577c4b4ff040c8f256d203e647619d9d4d6ebb.camel@suse.com>
 <3dacf98c-c4b7-a263-01d3-f8562619ff53@suse.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-NSFr/7Jsh560HfIcFVSf"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-NSFr/7Jsh560HfIcFVSf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2020-04-17 at 09:57 +0200, J=C3=BCrgen Gro=C3=9F wrote:
> On 16.04.20 18:43, Dario Faggioli wrote:
> > On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
> > >=20
> > > +char *sched_gran_str(char *str, size_t size)
> > > +{
> > > +    char *mode =3D "";
> > > +
> > > +    switch ( opt_sched_granularity )
> > > +    {
> > > +    case SCHED_GRAN_cpu:
> > > +        mode =3D "cpu";
> > > +        break;
> > > +    case SCHED_GRAN_core:
> > > +        mode =3D "core";
> > > +        break;
> > > +    case SCHED_GRAN_socket:
> > > +        mode =3D "socket";
> > > +        break;
> > > +    default:
> > > +        ASSERT_UNREACHABLE();
> > > +        break;
> > > +    }
> > > +
> > > +    if ( sched_granularity )
> > > +        snprintf(str, size, "%u-way %s", sched_granularity,
> > > mode);
> > >=20
> > I'm not sure about using the value of the enum like this.
>=20
> enum? sched_granularity holds the number of cpus per scheduling
> resource. opt_sched_granularity is the enum.
>=20
Ah, indeed! I failed to see that the if and the snprintf above use
that, and not opt_sched_granularity! Sorry for the confusion.

> > So I'd just go with "cpu", "core" and "socket" strings.
>=20
> No, this is not a good idea. With e.g. smt=3D0 you'll be able to have
> "1-way core" which is much more informative than "core".
>=20
True. And thinking to this cases, I agree that it makes sense to
provide an information that takes that into account too.

I'm now not sure whether something like "1-way core-scheduling (or "1-
way core-scheduling more") is really the best way to tell the user
we're using using core-scheduling, but we have disabled SMT... Perhaps
something like:

Scheduling granularity: core, 1CPU(s) per sched-resource

Or something like that?

Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-NSFr/7Jsh560HfIcFVSf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6ZvvAACgkQFkJ4iaW4
c+7ZFBAAs5Q7OHht7ajtsaC1asDDRswP7bb8PbaZTxoLTVLu1Cgbj1sOKdHbCjSh
N97/HmP18U9mhqRPFPdS1+cDFCwqpkufcqsKxjQv9gvzyz8DyjnKwzxwpa8FmaHa
zci/ApSC3eX4lLrkeLKDFPWGxfKGwhbnWyqx6ZUjOsTgbSsFZ7y4IJeIwU0V1WA3
U6oRIZgIy7Y+7j6nKH6ovK/gR1+SYt8hD/dVPSaabS+PvxF28EJ0IbfQP7s96eFb
BAdLT8mqOjh2CfhRWmIOq9B0+PGQt5OpQrH+LvyZW7DOTPjZA88CqZSaq/GRx/Lk
pTfgux3YKljnkEyECeM/4wDlUA3CWapqaes3K04lNX4+FS8VymSIvZuB85GipiaP
CtwGYvnMDsVoAqos9ZG9OOI9cfEq6YA00pKgASRe3aUehRFMs6XvJvLLrUxw2vqg
Rvf+BR39jr0A/+rTA4uJUDIj1mc+eRqnNgmLR0gU1TZUXy0aZurTY6zXKlS9/4G8
ZgAUbZqSPlgxKFBLCqt5DuEQ8kKdZ5uF2I1qF0BH0uJBhxBGSk2Yo8LBmtBRrilJ
rSOSan94hB/OXck+L/ABBEtyoM0uYdeMn+BhExxt9yJQDA6M75FGbViz0F8jzr+e
mw4pQo2wcsLWRhIF5DhjimszD09Eb6Cs8g5bWfweXilfKygW/FI=
=v8Ak
-----END PGP SIGNATURE-----

--=-NSFr/7Jsh560HfIcFVSf--



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:37:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPS7z-0000xx-35; Fri, 17 Apr 2020 14:37:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=H8UU=6B=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jPS7x-0000xe-LM
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:37:57 +0000
X-Inumbo-ID: 0733e1fe-80b9-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0733e1fe-80b9-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 14:37:57 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9A58FAC6C;
 Fri, 17 Apr 2020 14:37:55 +0000 (UTC)
Message-ID: <5c2f85e4817889fe5ac4a21774468ff9b1ddd569.camel@suse.com>
Subject: Re: [PATCH] sched: print information about scheduler granularity
From: Dario Faggioli <dfaggioli@suse.com>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, Sergey Dyasli
 <sergey.dyasli@citrix.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
Date: Fri, 17 Apr 2020 16:37:54 +0200
In-Reply-To: <2d2fb0af-2ec3-4b2f-4427-eb13e9623111@suse.com>
References: <20200416083341.21122-1-sergey.dyasli@citrix.com>
 <d2577c4b4ff040c8f256d203e647619d9d4d6ebb.camel@suse.com>
 <3dacf98c-c4b7-a263-01d3-f8562619ff53@suse.com>
 <1587131006806.63738@citrix.com>
 <2d2fb0af-2ec3-4b2f-4427-eb13e9623111@suse.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-cupDj4zpwc4lTzuuZY3V"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-cupDj4zpwc4lTzuuZY3V
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2020-04-17 at 15:52 +0200, J=C3=BCrgen Gro=C3=9F wrote:
> On 17.04.20 15:43, Sergey Dyasli wrote:
> > While "sched-gran=3Dcore smt=3D0" gives:
> > (XEN) [  259.337588] Scheduler: SMP Credit Scheduler (credit) in 1-
> > way core-scheduling mode
>=20
> You might want to consider not using the global variables
> [opt_]sched_granularity, but the per-cpupool ones. Right now they
> have
> the same value, but this might change in future...
>=20
Yes, agreed.

Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-cupDj4zpwc4lTzuuZY3V
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6Zv0MACgkQFkJ4iaW4
c+6TPw//VT/xB4VwOI2eap2ndai88df+Ty3eJ1l6KdgGvjShZwvsNueNhxt3WC1Q
oh5EGrtlN9yajJvjM3CavyyrdQHIZ4+VkqsIkBHp9bPVnQlD/UC27c+K28XpU9jF
1bdXkWKuBD6WAf7kP6hR2f+BNL86Tv58LRErmQYC84S+vTT0MT94mxCnzfQFB5M+
hl0+CdDOHsImaBjqihjOlsTUsu5y3f1E2CiQuw6iQwDip0Snhomy1st1P8dYEjw2
vdyJB+uEjmrkTGVJEt2sfUzDV2YP4j+K4mDept6mwjpt+t1seeCUVBnykbJ/d2R8
w56D7Asi646s606du3Kv0boI9UdGPSq8KDI/B8GAo2wdsMCT0mNt4N1qjozcoqS+
Jsne7/ihD/0Fly4xdz5F0IkQ4HKhwKuJ2uKEepssUzwuNw9t5bybKI9NgUqAvTjW
1+rAvorPahAtXACdPpxhXpffI19TqdzCjhdHLJWKCvuv+iJnR+A2oxPdoMFvbcg2
7oHB6g9W74rB1xUZ6nXY5ytZ+7LnrvSQTe/jE04gHfpkZ4QmSs+N2nd6E6VLg8KZ
l1/OpKlgfpMJVhOiR8OtXSwwNe2pOKBuc56L1bBIvKjJ3mB61IeuipJS75citVOM
By6iBIFxUo7WezRx1ShRN08T/j1Hn3lIN6+C55V1yg5I47atSE4=
=3KaA
-----END PGP SIGNATURE-----

--=-cupDj4zpwc4lTzuuZY3V--



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 14:42:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 14:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPSCI-0001lg-Nj; Fri, 17 Apr 2020 14:42:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=iNba=6B=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jPSCH-0001lb-FM
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 14:42:25 +0000
X-Inumbo-ID: a6850760-80b9-11ea-83d8-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a6850760-80b9-11ea-83d8-bc764e2007e4;
 Fri, 17 Apr 2020 14:42:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587134544;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=ldFwJ8f/H27/uGBJtOv7qMBB0cnH3N9x8Av4ARicKfA=;
 b=PDHanGuQKTQru7iyqh6ixzq7llVk/mAoeWVWFRNOcZaJtxeDc8T87d0b
 4NTbR7u6HQDiw7jEt4i7PlGUJV/Jhzowbqx3qKfeWxVjgYwRupJwLjLV2
 hk5o3S8VHBc4sRYKJ6DpjBYd1tF45si5ue8zUaCB0S+FSyNf0g543IEnk M=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: /pEXAGlykJ4dqop1vj8FVgfw0qwPoGgU0S27Ju89JPLhKYNexP7Q/3DDx0KtPE+kSHrL0dJcl3
 E5VnIJk2WUGhNiTHupbWnzdbHdBh/NsRbF4z9pT4rCYIS1UI8l4WTmrEC0JYTtmy/pUZibvJjq
 /g45nAgrwwYUn/GzG5KVjRgUk78a1YflANFcZ5Zwwd5IyraREKgUHbZs57aqmTMz/9Cmq4WWY9
 +Nav/Zk54S1MmoxSwSne8R1DV59JYAa2Ho0A2Q27o5BbbhnMWrn4MhLITs2kq9U3IzWjmSxjqB
 MWg=
X-SBRS: 2.7
X-MesageID: 16164727
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="16164727"
Date: Fri, 17 Apr 2020 15:42:18 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
Message-ID: <20200417144218.GN4088@perard.uk.xensource.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-15-anthony.perard@citrix.com>
 <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
 <20200416124400.GG4088@perard.uk.xensource.com>
 <312e719f-2bae-cb29-a6dd-29ae0d976d95@suse.com>
 <20200416150929.GL4088@perard.uk.xensource.com>
 <586cff44-d46e-3a5b-9e47-0c7ff4de8801@suse.com>
 <20200417131931.GM4088@perard.uk.xensource.com>
 <83de83ee-848f-a048-7293-d1e5b01dd217@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <83de83ee-848f-a048-7293-d1e5b01dd217@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 03:39:48PM +0200, Jan Beulich wrote:
> On 17.04.2020 15:19, Anthony PERARD wrote:
> > Or do you mean keeping exception to the rule? And hope that when someone
> > changes the rule, it doesn't forget to check if the exception needs
> > changing as well?
> 
> ... "exception" like you put it (requiring special care to keep
> multiple instances in sync) is not the only way this can be done
> (and indeed I'd not want something like this). Since you have
> (in patch 15) e.g.
> 
> guest_walk_%.o: guest_walk.c FORCE
> 	$(call if_changed_rule,cc_o_c)
> 
> anyway, the desire to skip the objcopy step could be communicated
> to the command from here, without needing to clone the command.
> One way might be a special (phony) dependency, another might be to
> set some variable along the lines of
> 
> guest_walk_%.o: SPECIAL := y

I guess something like that could be done. But if possible, I'd like to
avoid that.

> > Also, I'm going to have to use this patch later anyway as sometime CC
> > use a full path to the source as file symbol. So this is going to be
> > important when we will run for example
> > `clang -o arch/x86/mm/guest_walk_2.o arch/x86/mm/guest_walk.c`.
> > (There isn't a patch for that yet.)
> 
> That's interesting - what will be the goal of that future adjustment?

It's a step toward my goal of been able to have out-of-tree build for
xen, as stated in my cover letter. In order to do that, I try to adapt
Kbuild to build Xen.

Kbuild is building the linux kernel without changing directory, so I'd
like to do the same, as it probably makes it easier to do out-of-tree
build.

Another tool I'd like to use from Kbuild is ./fixdep, it's a small
program that run after running CC and fix the dependency file that CC
generates. The main thing it does is to add a dependency on
Kconfig options that a source file uses instead of having a dependency
on whether any unrelated Kconfig has change at all. But ./fixdep from
Linux only works if we build without changing directory. ([1] for more
on fixdep)

I guess one advantage of never changing directory is that we can always
use relative path in global *FLAGS. There isn't a need to use absolute
path, which is an issue when the source tree is moved to a different
location. That can easily happen when for example you try to build in a
container (mapping the source tree inside it) then try to rebuild from
outside. (After using automation/scripts/containerize for example.)
And we don't need tricks like the .*.d2 files (which isn't needed in the
hypervisor anyway, so far at least).


[1], copied from Linux's scripts/basic/fixdep.c introduction:
    If the user re-runs make *config, autoconf.h will be
    regenerated.  make notices that and will rebuild every file which
    includes autoconf.h, i.e. basically all files. This is extremely
    annoying if the user just changed CONFIG_HIS_DRIVER from n to m.

    So we play the same trick that "mkdep" played before. We replace
    the dependency on autoconf.h by a dependency on every config
    option which is mentioned in any of the listed prerequisites.

    kconfig populates a tree in include/config/ with an empty file
    for each config symbol and when the configuration is updated
    the files representing changed config options are touched
    which then let make pick up the changes and the files that use
    the config symbols are rebuilt.

    So if the user changes his CONFIG_HIS_DRIVER option, only the objects
    which depend on "include/config/his/driver.h" will be rebuilt,
    so most likely only his driver ;-)

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 15:16:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 15:16:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPSj6-0004IH-H3; Fri, 17 Apr 2020 15:16:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=u2Wk=6B=arm.com=bertrand.marquis@srs-us1.protection.inumbo.net>)
 id 1jPSj5-0004IC-H6
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 15:16:19 +0000
X-Inumbo-ID: 619a888c-80be-11ea-8d1d-12813bfff9fa
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (unknown
 [40.107.1.67]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 619a888c-80be-11ea-8d1d-12813bfff9fa;
 Fri, 17 Apr 2020 15:16:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; 
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=66xSmOfYG4jHlFll/fjUK4czw+WNQK/s8+9fRgbGNwk=;
 b=ibZETFQEX+QPT0UkmwtrVOwnT0pxLZaPvLrhcZFpe0dxmz8nS+3gDAWFT9rzflEjz89hkH8b0N0I9J9ZvpFpS7vuKGw5oWjPcvvvAS/JFUrKg60yvcdXpC7lAHOGyvzuNdIYV2R/cmgXsndZ8cLLbzPS92f8TAnlIfb3ucTyzLc=
Received: from AM5PR0402CA0012.eurprd04.prod.outlook.com
 (2603:10a6:203:90::22) by VI1PR08MB2847.eurprd08.prod.outlook.com
 (2603:10a6:802:19::31) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.26; Fri, 17 Apr
 2020 15:16:13 +0000
Received: from AM5EUR03FT030.eop-EUR03.prod.protection.outlook.com
 (2603:10a6:203:90:cafe::de) by AM5PR0402CA0012.outlook.office365.com
 (2603:10a6:203:90::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.26 via Frontend
 Transport; Fri, 17 Apr 2020 15:16:13 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was
 verified) header.d=armh.onmicrosoft.com;lists.xenproject.org;
 dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AM5EUR03FT030.mail.protection.outlook.com (10.152.16.117) with
 Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2900.18 via Frontend Transport; Fri, 17 Apr 2020 15:16:11 +0000
Received: ("Tessian outbound cbb03e3a1db0:v53");
 Fri, 17 Apr 2020 15:16:10 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: ca04699a134b115c
X-CR-MTA-TID: 64aa7808
Received: from a566ce57193a.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 3867CA21-086C-4BAF-833F-4F179A37F667.1; 
 Fri, 17 Apr 2020 15:16:05 +0000
Received: from EUR04-VI1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a566ce57193a.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Fri, 17 Apr 2020 15:16:05 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=QT186vvrkYEVQw0qPRTRh/tk2WIQFnK+8rtYCZci/nOEJGc90xiLuhvWkaN9nXMGiaycaneldhUB++3VnW385neba5tSeOWbjEZkx7B/T0M2YooDJzH8dnpK2H10vu7gg2BNyH0seAUYKa1JQIhOqmO+SKgBA6vWRI2VQLT4mWUpe4vB8bNsWwzpN1UPUgXmlGv7PMVCD5nxJs4EPiiJWxXMBWjL8Vz1rcijBvKPcImomygSKlOocn5+p3BmAJsal7lu7idLcAArMxotJu5dS4fbwS3ZJFwHXAruivHpBiTMxZb1wopIzzYgcoZPoWpIFZCS13GpyPbVN4oCk9iA2w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=66xSmOfYG4jHlFll/fjUK4czw+WNQK/s8+9fRgbGNwk=;
 b=CFmHQRHJ/RQm8IDTSmKGvFpDRJ30vn4Tcq3c/HmjpP3EJnRL/VjWQyd/yUU8pY3iHHXjhpPJtSNMI2aKyAeHbFC5tHVbZ87PWBVjDQAYvFQNHzlpRE86lEXZg+DPy0COwlSPlUPd9VWiJtaL9z3O5RSsnoezogXn67dgBie3RtV+kqYxoAjToZ3WqCzwlsoPWlluJZuzmqXprGTmOKTO0g00njYme/ZAA3I6HBjZmLmS9wtbf0ujeqKbcfBIabweBMxpsLJdXz510Xu7PiEBN4Wqk+jvMZ4j1qfln2wD2Qh9wapGOKsxx9GUdZGIaB2ngj/fY/jDKWbl+kjvQwnHkg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; 
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=66xSmOfYG4jHlFll/fjUK4czw+WNQK/s8+9fRgbGNwk=;
 b=ibZETFQEX+QPT0UkmwtrVOwnT0pxLZaPvLrhcZFpe0dxmz8nS+3gDAWFT9rzflEjz89hkH8b0N0I9J9ZvpFpS7vuKGw5oWjPcvvvAS/JFUrKg60yvcdXpC7lAHOGyvzuNdIYV2R/cmgXsndZ8cLLbzPS92f8TAnlIfb3ucTyzLc=
Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16)
 by DB7PR08MB3308.eurprd08.prod.outlook.com (2603:10a6:5:20::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Fri, 17 Apr
 2020 15:16:02 +0000
Received: from DB7PR08MB3689.eurprd08.prod.outlook.com
 ([fe80::94d7:a242:40b4:cfb5]) by DB7PR08MB3689.eurprd08.prod.outlook.com
 ([fe80::94d7:a242:40b4:cfb5%6]) with mapi id 15.20.2921.027; Fri, 17 Apr 2020
 15:16:02 +0000
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Julien Grall <julien@xen.org>, Stefano Stabellini
 <stefano.stabellini@xilinx.com>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Topic: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Thread-Index: AQHWB8CUPtV45V7pfkaBDuUahGESj6hj8BaAgAImRYCAABntAIABn/cAgAAM24CABI1SgIAADaYAgAFoMACAAAmAAIAAGAiAgAAcqICAAe3jAIAAwKMAgAABOACADLiFAA==
Date: Fri, 17 Apr 2020 15:16:02 +0000
Message-ID: <C39B873E-F40C-4549-9D5E-953E88F94E43@arm.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <38f56c3e-8f7d-7aee-8216-73398f4543bb@xen.org>
 <alpine.DEB.2.21.2003300932430.4572@sstabellini-ThinkPad-T480s>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
 <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
 <057f48b7-84be-0bc5-773d-d01a79181b20@xen.org>
 <alpine.DEB.2.21.2004081642070.28673@sstabellini-ThinkPad-T480s>
 <914c421a-02cf-375b-a3fa-1c5e934cdeb3@xen.org>
 <3b002deb-5a80-3dc4-9462-649135cfbd29@xen.org>
In-Reply-To: <3b002deb-5a80-3dc4-9462-649135cfbd29@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Authentication-Results-Original: spf=none (sender IP is )
 smtp.mailfrom=Bertrand.Marquis@arm.com; 
x-originating-ip: [82.24.250.194]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: f444f73b-27d4-4b62-8c14-08d7e2e2432c
x-ms-traffictypediagnostic: DB7PR08MB3308:|VI1PR08MB2847:
X-Microsoft-Antispam-PRVS: <VI1PR08MB284777D7AD5012585307E3279DD90@VI1PR08MB2847.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0376ECF4DD
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en;
 SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com;
 PTR:; CAT:NONE; SFTY:;
 SFS:(10009020)(4636009)(39860400002)(346002)(396003)(376002)(136003)(366004)(6512007)(71200400001)(5660300002)(2906002)(8936002)(8676002)(81156014)(6486002)(33656002)(86362001)(4326008)(36756003)(26005)(91956017)(186003)(2616005)(478600001)(316002)(66476007)(76116006)(66446008)(64756008)(66556008)(66946007)(54906003)(110136005)(6506007)(53546011);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: yp9JsU4vmJgrhrNdEQmdL1l31+TF29CNVBb93gc93jkMF+Qjb360dPH1CeAUf7cCmccBvKsW+zqgLAeZa//ujEDD3LYprebsa+3x9VktEZdkTOC7EGPPW7hfWI3GPchTjX0TRTB8/1Q/+jMag6CqK4RwKmwnApVMiGYKuEyipubxkPtB75CiqLJquxXlTs0pPt8yS9k8cnPUZ3vTKGcLecf/8pWVOGuXJGG+Qdluhoe2PdHqxuTFyYKmDrDWSTON07cg3z/vUhaDPYEevoFn0Q2Xo5ZCSeHE6li9QmAM/4k6ZDyzmlgcwud0LwRjdaU1+34Uz1tanvo8HkDuLVARLKRcudw4VWoyvLTBz/Ipb7f/D7JYwiuQ/3+7HpLBRhZVr/VUovA/p7q3eNNPu9rFSmNOud+eP+LwrPsvmaXysn70Ot4UuJOPM3JO5ZAYpuN/
x-ms-exchange-antispam-messagedata: 00s+waVq6rGfNYo4BGN5z47rb4o53grJcQIg82RPm4JyzI+KWS0P3QrX/dXIOUTzsG6x1jklUwvXcn3JpuvZ2Dc4bJK5vwxQ9vFN7GeOgOp0BnS9AHmwSC3mbxIHpSTAkjGii2+29OxnCS75YV9okw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
 boundary="_000_C39B873EF40C45499D5E953E88F94E43armcom_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3308
Original-Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=Bertrand.Marquis@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT030.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;
 IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;
 PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:;
 SFS:(10009020)(4636009)(346002)(136003)(39860400002)(376002)(396003)(46966005)(70586007)(186003)(336012)(54906003)(86362001)(81166007)(316002)(8936002)(110136005)(26005)(4326008)(6486002)(70206006)(36756003)(8676002)(45080400002)(33964004)(82740400003)(81156014)(2616005)(356005)(33656002)(47076004)(6506007)(53546011)(478600001)(5660300002)(6512007)(2906002);
 DIR:OUT; SFP:1101; 
X-MS-Office365-Filtering-Correlation-Id-Prvs: 67acc335-1877-4945-d0ee-08d7e2e23dfe
X-Forefront-PRVS: 0376ECF4DD
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: lKtDTP4P8k6LZ5k1SW0FkzfTvrDChwcnk3xmy2zPiq9vSpDp/i3o4RL+2Pw7R9cXHY4iEvC26SNUekeoFG1KBl2Zl/wV2OZj2U9jE29w/b77vLLcPzQECiPe2QoVzgL3fWII2b78bapDD/DsYY4xZjo4XaY56fM+pQVT9tFM8418lMJkhxMHhnFKIK9ADu0AzwIxkd9QtO0FE6qd6t4YkMzuEaScYIhiwiwEmOKtzIpxg7CHvkiZB52o+b3QeyQNN5sN4anwiaN3O6xIl/JVkQPbGCVApAk7K7bWGsiWlxUZJg7FnLsjDiiGWXQsj3fKCleCAG1ZNzRcZaFSCqG6h5n7sdBtq5/LXk9TiI4W4GYK5EJ/YG9nyy6RnbdmE2tbj+43EXgQmXcHbzHzKSRocMWMAtLH8rZexEZonjl3zgZJaKAb7T12CyFRTSVlDIbJDtoiz6SfnKQTO9PhWPtyi9auaAKEhgcFgmBosIgMWfY4XPEp1jaxg6kB8TqqgXgUL76p5Joi0i1vOiauFxDx+Q==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2020 15:16:11.2943 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f444f73b-27d4-4b62-8c14-08d7e2e2432c
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];
 Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2847
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, George Dunlap <George.Dunlap@citrix.com>,
 Wei Xu <xuwei5@hisilicon.com>, xen-devel <xen-devel@lists.xenproject.org>,
 nd <nd@arm.com>, Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--_000_C39B873EF40C45499D5E953E88F94E43armcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpPbiA5IEFwciAyMDIwLCBhdCAxNDowMCwgSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZzxt
YWlsdG86anVsaWVuQHhlbi5vcmc+PiB3cm90ZToNCg0KDQoNCk9uIDA5LzA0LzIwMjAgMTM6NTYs
IEp1bGllbiBHcmFsbCB3cm90ZToNCk9uIDA5LzA0LzIwMjAgMDI6MjYsIFN0ZWZhbm8gU3RhYmVs
bGluaSB3cm90ZToNCk9uIFR1ZSwgNyBBcHIgMjAyMCwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KSSBk
b27igJl0IGtub3cgd2hhdCBtYWludGVuYW5jZSBJUlFzIGFyZSwgYnV0IGlmIHRoZXkgb25seSBo
YXBwZW4NCmludGVybWl0dGVudGx5LCBpdOKAmXMgcG9zc2libGUgdGhhdCB5b3XigJlkIG5ldmVy
IGdldCBtb3JlIHRoYW4gYSBzaW5nbGUNCm9uZSBpbiBhIGxhdGVuY3ktY3JpdGljYWwgSVJRIHJv
dXRpbmU7IGFuZCBhcyBzdWNoLCB0aGUgdmFyaWF0aWJpbGl0eSBpbg0KZXhlY3V0aW9uIHRpbWUg
KGppdHRlcikgd291bGRu4oCZdCBiZSBhbiBpc3N1ZSBpbiBwcmFjdGljZS4gIEJ1dCBldmVyeQ0K
dGltZSB5b3UgYWRkIGEgbmV3IHVuYmxvY2thYmxlIElQSSwgeW91IGluY3JlYXNlIHRoaXMgaml0
dGVyOw0KcGFydGljdWxhcmx5IGlmIHRoaXMgdW5ibG9ja2FibGUgSVBJIG1pZ2h0IGJlIHJlcGVh
dGVkIGFuIGFyYml0cmFyeQ0KbnVtYmVyIG9mIHRpbWVzLg0KKFN0ZWZhbm8sIGxldCBtZSBrbm93
IGlmIEnigJl2ZSBtaXN1bmRlcnN0b29kIHNvbWV0aGluZy4pDQpTbyBzdGVwcGluZyBiYWNrIGEg
bW9tZW50LCBoZXJl4oCZcyBhbGwgdGhlIHBvc3NpYmxlIGlkZWFzIHRoYXQgSSB0aGluaw0KaGF2
ZSBiZWVuIGRpc2N1c3NlZCAob3IgYXJlIHRoZXJlIGltcGxpY2l0bHkpIHNvIGZhci4NCjEuIFtE
ZWZhdWx0XSBEbyBub3RoaW5nOyBndWVzdHMgdXNpbmcgdGhpcyByZWdpc3RlciBjb250aW51ZSBj
cmFzaGluZw0KMi4gTWFrZSB0aGUgST9BQ1RJVkVSIHJlZ2lzdGVycyBSWldJLg0KMy4gTWFrZSBJ
P0FDVElWRVIgcmV0dXJuIHRoZSBtb3N0IHJlY2VudCBrbm93biB2YWx1ZTsgaS5lLiBLVk3igJlz
IGN1cnJlbnQNCmJlaGF2aW9yIChhcyBmYXIgYXMgd2UgdW5kZXJzdGFuZCBpdCkNCjQuIFVzZSBh
IHNpbXBsZSBJUEkgd2l0aCBkb19ub29wIHRvIHVwZGF0ZSBJP0FDVElWRVINCjRhLiAgVXNlIGFu
IElQSSwgYnV0IGNvbWUgdXAgd2l0aCBjbGV2ZXIgdHJpY2tzIHRvIGF2b2lkIGludGVycnVwdGlu
Zw0KZ3Vlc3RzIGhhbmRsaW5nIElSUXMuDQo1LiBUcmFwIHRvIFhlbiBvbiBndWVzdCBFT0ksIHNv
IHRoYXQgd2Uga25vdyB3aGVuIHRoZQ0KNi4gU29tZSBjbGV2ZXIgcGFyYXZpcnR1YWxpemVkIG9w
dGlvbg0KDQo3LiBVc2UgYW4gSVBJIGlmIHdlIGFyZSBjb25maWRlbnQgdGhlIGludGVycnVwdHMg
bWF5IGJlIGFjdGl2ZS4NCg0KSSBkb27igJl0IHVuZGVyc3RhbmQgdGhpcyBvbmUuICBIb3cgaXMg
aXQgZGlmZmVyZW50IHRoYW4gNCBvciA0YT8gIEFuZCBpbg0KcGFydGljdWxhciwgaG93IGRvZXMg
aXQgZXZhbHVhdGUgb24gdGhlIOKAnGhvdyBtdWNoIGFkZGl0aW9uYWwgZGVzaWduIHdvcmsNCndv
dWxkIGl0IHRha2XigJ0gY3JpdGVyaWE/DQoNCkxldCBtZSBzdGFydCB3aXRoLCBpZiB3ZSB3YW50
IHRvIGhhdmUgYSB2R0lDIHRvIHJ1bGUgdGhlbSBhbGwsIHRoZW4gSSBhbQ0KYWZyYWlkIHlvdSBh
cmUgZ29pbmcgdG8gaGF2ZSB0byBjb21wcm9taXNlLiBXZSBjYW4gZGlzY3VzcyBhYm91dCB0YWls
b3JpbmcgdGhlDQp2R0lDIGJ1dCBJIHRoaW5rIGJlZm9yZSB0aGF0IHdlIG5lZWQgYSB2R0lDIHRo
YXQgaXMgZmFpdGhmdWxsIHdpdGggdGhlIHNwZWMNCihlLmcgZGlmZmVyZW50aWF0aW5nIGxldmVs
IHZzIGVkZ2UgaW50ZXJydXB0cywgaGFuZGxpbmcgYWN0aXZlci4uLikuIE5vdGUgdGhhdA0KQXJt
IHNwZW50IHNvbWUgZWZmb3J0IHRvIGdldCBhIG5ldyB2R0lDIG1lcmdlZCBidXQgdGhpcyB3YXMg
bmV2ZXIgbWFkZSBhIGZpcnN0DQpjbGFzcyBjaXRpemVuLg0KDQpIb3dldmVyLCBldmVuIGlmIHlv
dSB0YWlsb3IgdGhlIHZHSUMsIHlvdSBhcmUgbm90IGdvaW5nIHRvIGJlIGFibGUgdG8gYXZvaWQN
CklQSSBpbiBzb21lIG9jY2FzaW9ucy4gVGhpcyB3b3VsZCBoYXBwZW4gd2hlbiB1c2luZyBldmVu
dCBjaGFubmVscywgaW4tZ3Vlc3QNCklQSS4uLiBBbm90aGVyIGV4YW1wbGUgaXMgd2hlbiBlbmFi
bGluZyBhbiBpbnRlcnJ1cHQsIGFsdGhvdWdoIEkgcmVhbGl6ZSB0aGF0DQpvdXIgdkdJQyBkb2Vz
IG5vdCBkbyBpdCB0b2RheSBtZWFuaW5nIHRoYXQgYSBwZW5kaW5nIGludGVycnVwdCB3aGlsZSBk
aXNhYmxlZA0Kd2lsbCBub3QgYmUgZm9yd2FyZGVkIHVudGlsIHRoZSB2Q1BVIGV4aXQuDQoNCkZ1
cnRoZXJtb3JlLCBpbXBsZW1lbnRpbmcgYSB3cml0ZSB0byBJe0MsU31BQ1RJVkVSICh0byBhY3Rp
dmF0ZS9kZS1hY3RpdmF0ZSkNCmlzIGdvaW5nIHRvIGJlIHZlcnkgZGlmZmljdWx0ICh0byBub3Qg
c2F5IGltcG9zc2libGUpIHRvIGRvIHdpdGhvdXQgSVBJLg0KDQpJZiB5b3UgYXJlIHdvcnJ5IGFi
b3V0IGEgdkNQVSBiZWVuIGludGVycnVwdGVkIGluIGNyaXRpY2FsIHNlY3Rpb24sIHRoZW4gSQ0K
dGhpbmsgeW91IHNob3VsZCB0YWlsb3IgeW91ciBndWVzdCB0byBhdm9pZCB1c2luZyB0aG9zZSBy
ZWdpc3RlcnMuDQoNCkxldCdzIGNhbGwgaXQgb3B0aW9uIDggInRlbGwgdGhlIHVzZXIgdGhhdCBz
aGUgbmVlZHMgdG8gbW9kaWZ5IGhlcg0Ka2VybmVsLiINCg0KDQpBbiBhbHRlcm5hdGl2ZSB3b3Vs
ZCBiZSB0byB1c2Ugc3BpbmxvY2svbXV0ZXggd2l0aGluIHRoZSBjb2RlIHRvIHByZXZlbnQgYQ0K
VkNQVSB0byBhY2Nlc3MgdGhlIHZHSUMgcmVnaXN0ZXJzIHdoaWxlIGFub3RoZXIgdkNQVSBkb24n
dCB3YW50IHRvIGJlDQppbnRlcnJ1cHRlZC4NCg0KUmVnYXJkaW5nLCA0YS4gVGhlIG9ubHkgd2F5
IEkgY291bGQgdGhpbmsgb2Ygd291bGQgYmUgdG8gdHJhcCB0aGUgaW5zdHJ1Y3Rpb25zDQp0aGF0
IG1hc2svdW5tYXNrIGludGVycnVwdHMuIElmIEkgcmVhZCBjb3JyZWN0bHkgdGhlIEFybXY4IHNw
ZWMsIGl0IGlzIG5vdA0KcG9zc2libGUgdG8gZG8gaXQuDQoNCjcuIGlzIGJhc2ljYWxseSA0LmEg
dGhlIGdvYWwgd291bGQgYmUgdG8gYXZvaWQgaW50ZXJydXB0cyB0aGUgdkNQVSBoYXMgbXVjaCBh
cw0KcG9zc2libGUgYnV0IHlvdSBtYXkgYmUgd3Jvbmcgc29tZXRpbWVzLiBPYnZpb3VzbHkgd2Ug
d2FudCB0byBiZSBjb3JyZWN0IG1vc3QNCm9mIHRoZSB0aW1lcy4NCg0KSSB1bmRlcnN0YW5kIHRo
aXMgbWF5IG5vdCBiZSB0aGUgaWRlYWwgc29sdXRpb24sIGJ1dCB0aGlzIGlzIHByb2JhYmx5IHRo
ZSBiZXN0DQp3ZSBjb3VsZCBjb21lIHdpdGggYW5kIGRvZXMgbm90IGludm9sdmUgYSBsb3Qgb2Yg
d29yayBiZWNhdXNlIHdlIGhhdmUgYWxyZWFkeQ0KYWxsIHRoZSBpbmZvcm1hdGlvbiBpbiBwbGFj
ZSAod2Uga25vdyB3aGVuIGFuIGludGVycnVwdCB3YXMgaW5qZWN0ZWQgdG8gYQ0KdkNQVSkuDQoN
ClRoZSBuZXh0IGJlc3Qgc29sdXRpb24gaXMgdG8gcHJldmVudCBpbiB5b3VyIGd1ZXN0IHRvIG1v
ZGlmeSBzb21lIHJlZ2lzdGVycyBvZg0KdGhlIHZHSUMgYXQgdGhlIHNhbWUgdGltZSBhcyBhbm90
aGVyIHZDUFUgaXMgaW4gYSBjcml0aWNhbCBzZWN0aW9uLg0KDQpMZXQncyBjYWxsIHRoaXMgb3B0
aW9uIDkuDQoNCg0KSSBhbSBqdXN0IHRoaW5raW5nIG91dCBsb3VkIGhlcmUgOikNClRoYW5rIHlv
dSBmb3IgdGhpbmtpbmcgb3V0IGxvdWQuIFNhZGx5LCBhcyBJIHBvaW50ZWQgb3V0IGJlZm9yZSwg
dGhlcmUgYXJlIG90aGVyIHBhcnQgb2YgdGhlIHZHSUMgZmFjaW5nIHRoZSBzYW1lIHByb2JsZW1z
IChlLmcgSXtTLEN9RU5BQkxFUiwgc2VuZGluZyBTR0lzLCBzZW5kaW5nIGV2ZW50IGNoYW5uZWxz
KS4NClNvIGNhbiB5b3UgZW5saWdodGVuIG1lIHdoeSBJe1MsQ31FTkFCTEVSIGlzIHRoYXQgbXVj
aCBhIGNvbmNlcm4gb3ZlciB0aGUgb3RoZXI/DQoNClRvIGJlIGNsZWFyLCBJIGFtIG5vdCBzYXlp
bmcgSXtTLEN9RU5BQkxFUiBzaG91bGQgbm90IGJlIGEgY29uY2Vybi4gQnV0IEkgd291bGQgcHJl
ZmVyIGlmIHdlIGZvY3VzIG9uIGEgZ2VuZXJpYyBzb2x1dGlvbiBpZiB0aGUgcHJvYmxlbSBpcyB3
aWRlci4NCg0KSXQgc2VlbXMgdGhhdCB0aGUgcHJvYmxlbSBpcyBhIGJpdCBiaWdnZXIgdGhlbiBl
eHBlY3RlZCBhbmQgd2lsbCBuZWVkIG1vcmUgZGlzY3Vzc2lvbiBhbmQgdGhpbmtpbmcuDQpJIGRp
ZCBzb21lIHJlc2VhcmNoIG9uIG15IHNpZGUgYW5kIHRoZXJlIGFyZSBzZXZlcmFsIGRlc2lnbiBw
b3NzaWJsZSBkZXBlbmRpbmcgb24gd2hhdCBzaG91bGQgYmUgdGhlIGdvYWwgcGVyZm9ybWFuY2Ug
b3IgcmVhbC10aW1lIGJlaGF2aW91ciAoZ29pbmcgZnJvbSBqdXN0IGdpdmUgdGhlIHN0YXR1cyB3
ZSBoYXZlIHRvIGZpcmUgYSBzZXJ2aWNlIGludGVycnVwdHMgd2hlbiBhbnkgaW50ZXJydXB0cyBp
cyBhY2tlZCBieSBhIGd1ZXN0IHRvIHJlZnJlc2ggb3VyIGludGVybmFsIHN0YXR1cykuDQoNCklu
IHRoZSBzaG9ydCB0ZXJtLCBjb3VsZCB3ZSBub3QgYWdyZWUgdG8gZml4IHRoZSB0eXBvIGJ5IHJl
dHVybmluZyBhbHdheXMgMCBhbmQgc3RhcnQgYSBkaXNjdXNzaW9uIG9uIHRoZSB2Z2ljIGltcGxl
bWVudGF0aW9uID8NCg0KQ2hlZXJzDQoNCkJlcnRyYW5kDQoNCg==

--_000_C39B873EF40C45499D5E953E88F94E43armcom_
Content-Type: text/html; charset="utf-8"
Content-ID: <5DFAE353903159499B04463546E2B5C5@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gOSBBcHIgMjAyMCwg
YXQgMTQ6MDAsIEp1bGllbiBHcmFsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1bGllbkB4ZW4ub3Jn
IiBjbGFzcz0iIj5qdWxpZW5AeGVuLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz
PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PGJyIHN0eWxlPSJj
YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp
emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg
Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog
c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj
ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog
MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQt
Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx
MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt
d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg
dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29s
b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4
dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh
bnQ7IiBjbGFzcz0iIj5Pbg0KIDA5LzA0LzIwMjAgMTM6NTYsIEp1bGllbiBHcmFsbCB3cm90ZTo8
L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v
cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt
OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm
b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v
cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu
czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJv
a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQpPbiAwOS8w
NC8yMDIwIDAyOjI2LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gVHVlLCA3IEFwciAyMDIwLCBKdWxpZW4g
R3JhbGwgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9
IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SSBkb27i
gJl0IGtub3cgd2hhdCBtYWludGVuYW5jZSBJUlFzIGFyZSwgYnV0IGlmIHRoZXkgb25seSBoYXBw
ZW48YnIgY2xhc3M9IiI+DQppbnRlcm1pdHRlbnRseSwgaXTigJlzIHBvc3NpYmxlIHRoYXQgeW91
4oCZZCBuZXZlciBnZXQgbW9yZSB0aGFuIGEgc2luZ2xlPGJyIGNsYXNzPSIiPg0Kb25lIGluIGEg
bGF0ZW5jeS1jcml0aWNhbCBJUlEgcm91dGluZTsgYW5kIGFzIHN1Y2gsIHRoZSB2YXJpYXRpYmls
aXR5IGluPGJyIGNsYXNzPSIiPg0KZXhlY3V0aW9uIHRpbWUgKGppdHRlcikgd291bGRu4oCZdCBi
ZSBhbiBpc3N1ZSBpbiBwcmFjdGljZS4mbmJzcDsgQnV0IGV2ZXJ5PGJyIGNsYXNzPSIiPg0KdGlt
ZSB5b3UgYWRkIGEgbmV3IHVuYmxvY2thYmxlIElQSSwgeW91IGluY3JlYXNlIHRoaXMgaml0dGVy
OzxiciBjbGFzcz0iIj4NCnBhcnRpY3VsYXJseSBpZiB0aGlzIHVuYmxvY2thYmxlIElQSSBtaWdo
dCBiZSByZXBlYXRlZCBhbiBhcmJpdHJhcnk8YnIgY2xhc3M9IiI+DQpudW1iZXIgb2YgdGltZXMu
PGJyIGNsYXNzPSIiPg0KKFN0ZWZhbm8sIGxldCBtZSBrbm93IGlmIEnigJl2ZSBtaXN1bmRlcnN0
b29kIHNvbWV0aGluZy4pPGJyIGNsYXNzPSIiPg0KU28gc3RlcHBpbmcgYmFjayBhIG1vbWVudCwg
aGVyZeKAmXMgYWxsIHRoZSBwb3NzaWJsZSBpZGVhcyB0aGF0IEkgdGhpbms8YnIgY2xhc3M9IiI+
DQpoYXZlIGJlZW4gZGlzY3Vzc2VkIChvciBhcmUgdGhlcmUgaW1wbGljaXRseSkgc28gZmFyLjxi
ciBjbGFzcz0iIj4NCjEuIFtEZWZhdWx0XSBEbyBub3RoaW5nOyBndWVzdHMgdXNpbmcgdGhpcyBy
ZWdpc3RlciBjb250aW51ZSBjcmFzaGluZzxiciBjbGFzcz0iIj4NCjIuIE1ha2UgdGhlIEk/QUNU
SVZFUiByZWdpc3RlcnMgUlpXSS48YnIgY2xhc3M9IiI+DQozLiBNYWtlIEk/QUNUSVZFUiByZXR1
cm4gdGhlIG1vc3QgcmVjZW50IGtub3duIHZhbHVlOyBpLmUuIEtWTeKAmXMgY3VycmVudDxiciBj
bGFzcz0iIj4NCmJlaGF2aW9yIChhcyBmYXIgYXMgd2UgdW5kZXJzdGFuZCBpdCk8YnIgY2xhc3M9
IiI+DQo0LiBVc2UgYSBzaW1wbGUgSVBJIHdpdGggZG9fbm9vcCB0byB1cGRhdGUgST9BQ1RJVkVS
PGJyIGNsYXNzPSIiPg0KNGEuJm5ic3A7IFVzZSBhbiBJUEksIGJ1dCBjb21lIHVwIHdpdGggY2xl
dmVyIHRyaWNrcyB0byBhdm9pZCBpbnRlcnJ1cHRpbmc8YnIgY2xhc3M9IiI+DQpndWVzdHMgaGFu
ZGxpbmcgSVJRcy48YnIgY2xhc3M9IiI+DQo1LiBUcmFwIHRvIFhlbiBvbiBndWVzdCBFT0ksIHNv
IHRoYXQgd2Uga25vdyB3aGVuIHRoZTxiciBjbGFzcz0iIj4NCjYuIFNvbWUgY2xldmVyIHBhcmF2
aXJ0dWFsaXplZCBvcHRpb248YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9
IiI+DQo3LiBVc2UgYW4gSVBJIGlmIHdlIGFyZSBjb25maWRlbnQgdGhlIGludGVycnVwdHMgbWF5
IGJlIGFjdGl2ZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJ
IGRvbuKAmXQgdW5kZXJzdGFuZCB0aGlzIG9uZS4mbmJzcDsgSG93IGlzIGl0IGRpZmZlcmVudCB0
aGFuIDQgb3IgNGE/Jm5ic3A7IEFuZCBpbjxiciBjbGFzcz0iIj4NCnBhcnRpY3VsYXIsIGhvdyBk
b2VzIGl0IGV2YWx1YXRlIG9uIHRoZSDigJxob3cgbXVjaCBhZGRpdGlvbmFsIGRlc2lnbiB3b3Jr
PGJyIGNsYXNzPSIiPg0Kd291bGQgaXQgdGFrZeKAnSBjcml0ZXJpYT88YnIgY2xhc3M9IiI+DQo8
L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpMZXQgbWUgc3RhcnQgd2l0aCwgaWYgd2Ugd2Fu
dCB0byBoYXZlIGEgdkdJQyB0byBydWxlIHRoZW0gYWxsLCB0aGVuIEkgYW08YnIgY2xhc3M9IiI+
DQphZnJhaWQgeW91IGFyZSBnb2luZyB0byBoYXZlIHRvIGNvbXByb21pc2UuIFdlIGNhbiBkaXNj
dXNzIGFib3V0IHRhaWxvcmluZyB0aGU8YnIgY2xhc3M9IiI+DQp2R0lDIGJ1dCBJIHRoaW5rIGJl
Zm9yZSB0aGF0IHdlIG5lZWQgYSB2R0lDIHRoYXQgaXMgZmFpdGhmdWxsIHdpdGggdGhlIHNwZWM8
YnIgY2xhc3M9IiI+DQooZS5nIGRpZmZlcmVudGlhdGluZyBsZXZlbCB2cyBlZGdlIGludGVycnVw
dHMsIGhhbmRsaW5nIGFjdGl2ZXIuLi4pLiBOb3RlIHRoYXQ8YnIgY2xhc3M9IiI+DQpBcm0gc3Bl
bnQgc29tZSBlZmZvcnQgdG8gZ2V0IGEgbmV3IHZHSUMgbWVyZ2VkIGJ1dCB0aGlzIHdhcyBuZXZl
ciBtYWRlIGEgZmlyc3Q8YnIgY2xhc3M9IiI+DQpjbGFzcyBjaXRpemVuLjxiciBjbGFzcz0iIj4N
CjxiciBjbGFzcz0iIj4NCkhvd2V2ZXIsIGV2ZW4gaWYgeW91IHRhaWxvciB0aGUgdkdJQywgeW91
IGFyZSBub3QgZ29pbmcgdG8gYmUgYWJsZSB0byBhdm9pZDxiciBjbGFzcz0iIj4NCklQSSBpbiBz
b21lIG9jY2FzaW9ucy4gVGhpcyB3b3VsZCBoYXBwZW4gd2hlbiB1c2luZyBldmVudCBjaGFubmVs
cywgaW4tZ3Vlc3Q8YnIgY2xhc3M9IiI+DQpJUEkuLi4gQW5vdGhlciBleGFtcGxlIGlzIHdoZW4g
ZW5hYmxpbmcgYW4gaW50ZXJydXB0LCBhbHRob3VnaCBJIHJlYWxpemUgdGhhdDxiciBjbGFzcz0i
Ij4NCm91ciB2R0lDIGRvZXMgbm90IGRvIGl0IHRvZGF5IG1lYW5pbmcgdGhhdCBhIHBlbmRpbmcg
aW50ZXJydXB0IHdoaWxlIGRpc2FibGVkPGJyIGNsYXNzPSIiPg0Kd2lsbCBub3QgYmUgZm9yd2Fy
ZGVkIHVudGlsIHRoZSB2Q1BVIGV4aXQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRnVy
dGhlcm1vcmUsIGltcGxlbWVudGluZyBhIHdyaXRlIHRvIEl7QyxTfUFDVElWRVIgKHRvIGFjdGl2
YXRlL2RlLWFjdGl2YXRlKTxiciBjbGFzcz0iIj4NCmlzIGdvaW5nIHRvIGJlIHZlcnkgZGlmZmlj
dWx0ICh0byBub3Qgc2F5IGltcG9zc2libGUpIHRvIGRvIHdpdGhvdXQgSVBJLjxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCklmIHlvdSBhcmUgd29ycnkgYWJvdXQgYSB2Q1BVIGJlZW4gaW50
ZXJydXB0ZWQgaW4gY3JpdGljYWwgc2VjdGlvbiwgdGhlbiBJPGJyIGNsYXNzPSIiPg0KdGhpbmsg
eW91IHNob3VsZCB0YWlsb3IgeW91ciBndWVzdCB0byBhdm9pZCB1c2luZyB0aG9zZSByZWdpc3Rl
cnMuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KTGV0J3MgY2Fs
bCBpdCBvcHRpb24gOCAmcXVvdDt0ZWxsIHRoZSB1c2VyIHRoYXQgc2hlIG5lZWRzIHRvIG1vZGlm
eSBoZXI8YnIgY2xhc3M9IiI+DQprZXJuZWwuJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz
PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+QW4g
YWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gdXNlIHNwaW5sb2NrL211dGV4IHdpdGhpbiB0aGUgY29k
ZSB0byBwcmV2ZW50IGE8YnIgY2xhc3M9IiI+DQpWQ1BVIHRvIGFjY2VzcyB0aGUgdkdJQyByZWdp
c3RlcnMgd2hpbGUgYW5vdGhlciB2Q1BVIGRvbid0IHdhbnQgdG8gYmU8YnIgY2xhc3M9IiI+DQpp
bnRlcnJ1cHRlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSZWdhcmRpbmcsIDRhLiBU
aGUgb25seSB3YXkgSSBjb3VsZCB0aGluayBvZiB3b3VsZCBiZSB0byB0cmFwIHRoZSBpbnN0cnVj
dGlvbnM8YnIgY2xhc3M9IiI+DQp0aGF0IG1hc2svdW5tYXNrIGludGVycnVwdHMuIElmIEkgcmVh
ZCBjb3JyZWN0bHkgdGhlIEFybXY4IHNwZWMsIGl0IGlzIG5vdDxiciBjbGFzcz0iIj4NCnBvc3Np
YmxlIHRvIGRvIGl0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjcuIGlzIGJhc2ljYWxs
eSA0LmEgdGhlIGdvYWwgd291bGQgYmUgdG8gYXZvaWQgaW50ZXJydXB0cyB0aGUgdkNQVSBoYXMg
bXVjaCBhczxiciBjbGFzcz0iIj4NCnBvc3NpYmxlIGJ1dCB5b3UgbWF5IGJlIHdyb25nIHNvbWV0
aW1lcy4gT2J2aW91c2x5IHdlIHdhbnQgdG8gYmUgY29ycmVjdCBtb3N0PGJyIGNsYXNzPSIiPg0K
b2YgdGhlIHRpbWVzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgdW5kZXJzdGFuZCB0
aGlzIG1heSBub3QgYmUgdGhlIGlkZWFsIHNvbHV0aW9uLCBidXQgdGhpcyBpcyBwcm9iYWJseSB0
aGUgYmVzdDxiciBjbGFzcz0iIj4NCndlIGNvdWxkIGNvbWUgd2l0aCBhbmQgZG9lcyBub3QgaW52
b2x2ZSBhIGxvdCBvZiB3b3JrIGJlY2F1c2Ugd2UgaGF2ZSBhbHJlYWR5PGJyIGNsYXNzPSIiPg0K
YWxsIHRoZSBpbmZvcm1hdGlvbiBpbiBwbGFjZSAod2Uga25vdyB3aGVuIGFuIGludGVycnVwdCB3
YXMgaW5qZWN0ZWQgdG8gYTxiciBjbGFzcz0iIj4NCnZDUFUpLjxiciBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NClRoZSBuZXh0IGJlc3Qgc29sdXRpb24gaXMgdG8gcHJldmVudCBpbiB5b3VyIGd1
ZXN0IHRvIG1vZGlmeSBzb21lIHJlZ2lzdGVycyBvZjxiciBjbGFzcz0iIj4NCnRoZSB2R0lDIGF0
IHRoZSBzYW1lIHRpbWUgYXMgYW5vdGhlciB2Q1BVIGlzIGluIGEgY3JpdGljYWwgc2VjdGlvbi48
YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpMZXQncyBjYWxsIHRo
aXMgb3B0aW9uIDkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
SSBhbSBqdXN0IHRoaW5raW5nIG91dCBsb3VkIGhlcmUgOik8YnIgY2xhc3M9IiI+DQo8L2Jsb2Nr
cXVvdGU+DQpUaGFuayB5b3UgZm9yIHRoaW5raW5nIG91dCBsb3VkLiBTYWRseSwgYXMgSSBwb2lu
dGVkIG91dCBiZWZvcmUsIHRoZXJlIGFyZSBvdGhlciBwYXJ0IG9mIHRoZSB2R0lDIGZhY2luZyB0
aGUgc2FtZSBwcm9ibGVtcyAoZS5nIEl7UyxDfUVOQUJMRVIsIHNlbmRpbmcgU0dJcywgc2VuZGlu
ZyBldmVudCBjaGFubmVscykuPGJyIGNsYXNzPSIiPg0KU28gY2FuIHlvdSBlbmxpZ2h0ZW4gbWUg
d2h5IEl7UyxDfUVOQUJMRVIgaXMgdGhhdCBtdWNoIGEgY29uY2VybiBvdmVyIHRoZSBvdGhlcj88
YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io
MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z
dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y
bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh
dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg
MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs
OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh
Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv
bjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9
IiI+VG8NCiBiZSBjbGVhciwgSSBhbSBub3Qgc2F5aW5nIEl7UyxDfUVOQUJMRVIgc2hvdWxkIG5v
dCBiZSBhIGNvbmNlcm4uIEJ1dCBJIHdvdWxkIHByZWZlciBpZiB3ZSBmb2N1cyBvbiBhIGdlbmVy
aWMgc29sdXRpb24gaWYgdGhlIHByb2JsZW0gaXMgd2lkZXIuPC9zcGFuPjxiciBzdHlsZT0iY2Fy
ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl
OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0
YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6
IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pkl0IHNlZW1zIHRoYXQgdGhlIHBy
b2JsZW0gaXMgYSBiaXQgYmlnZ2VyIHRoZW4gZXhwZWN0ZWQgYW5kIHdpbGwgbmVlZCBtb3JlIGRp
c2N1c3Npb24gYW5kIHRoaW5raW5nLjwvZGl2Pg0KPGRpdj5JIGRpZCBzb21lIHJlc2VhcmNoIG9u
IG15IHNpZGUgYW5kIHRoZXJlIGFyZSBzZXZlcmFsIGRlc2lnbiBwb3NzaWJsZSBkZXBlbmRpbmcg
b24gd2hhdCBzaG91bGQgYmUgdGhlIGdvYWwgcGVyZm9ybWFuY2Ugb3IgcmVhbC10aW1lIGJlaGF2
aW91ciAoZ29pbmcgZnJvbSBqdXN0IGdpdmUgdGhlIHN0YXR1cyB3ZSBoYXZlIHRvIGZpcmUgYSBz
ZXJ2aWNlIGludGVycnVwdHMgd2hlbiBhbnkgaW50ZXJydXB0cyBpcyBhY2tlZCBieSBhIGd1ZXN0
IHRvDQogcmVmcmVzaCBvdXIgaW50ZXJuYWwgc3RhdHVzKS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNz
PSIiPg0KPC9kaXY+DQo8ZGl2PkluIHRoZSBzaG9ydCB0ZXJtLCBjb3VsZCB3ZSBub3QgYWdyZWUg
dG8gZml4IHRoZSB0eXBvIGJ5IHJldHVybmluZyBhbHdheXMgMCBhbmQgc3RhcnQgYSBkaXNjdXNz
aW9uIG9uIHRoZSB2Z2ljIGltcGxlbWVudGF0aW9uID88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2PkNoZWVyczwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxkaXY+QmVydHJhbmQ8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_C39B873EF40C45499D5E953E88F94E43armcom_--


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 15:17:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 15:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPSkO-0004N4-1u; Fri, 17 Apr 2020 15:17:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ygd1=6B=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jPSkM-0004Mx-PT
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 15:17:38 +0000
X-Inumbo-ID: 925c32b8-80be-11ea-8d1d-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 925c32b8-80be-11ea-8d1d-12813bfff9fa;
 Fri, 17 Apr 2020 15:17:38 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 68C39AD2A;
 Fri, 17 Apr 2020 15:17:36 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: torvalds@linux-foundation.org
Subject: [GIT PULL] xen: branch for v5.7-rc2
Date: Fri, 17 Apr 2020 17:17:35 +0200
Message-Id: <20200417151735.30600-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
 linux-kernel@vger.kernel.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.7-rc2-tag

xen: branch for v5.7-rc2

It contains:
- a small cleanup patch
- a security fix for a bug in the Xen hypervisor to avoid enabling Xen
  guests to crash dom0 on an unfixed hypervisor.

Thanks.

Juergen

 arch/arm/xen/enlighten.c           | 2 +-
 drivers/xen/xenbus/xenbus_client.c | 9 ++++++++-
 2 files changed, 9 insertions(+), 2 deletions(-)

Jason Yan (1):
      arm/xen: make _xen_start_info static

Juergen Gross (1):
      xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 15:50:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 15:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPTFy-0007WE-6x; Fri, 17 Apr 2020 15:50:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9Py=6B=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jPTFw-0007W9-W9
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 15:50:17 +0000
X-Inumbo-ID: 1e35ab82-80c3-11ea-8d2d-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1e35ab82-80c3-11ea-8d2d-12813bfff9fa;
 Fri, 17 Apr 2020 15:50:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587138611;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=n+kJcIVbiUyfNa/vyQETwoQaqxnGj4WaK08bU0mpih8=;
 b=hRtN2I0OIE8y+Zi/dpQjUqLCsSAU9I3WoxwYgvRFatSvSMPtdD+0K+Bg
 N2cuCa65YRccGg5LHrXop7ylPBa9p06jsYP3IYeEM6WA85qFJNI1JlhYS
 0obBJgsPf2iGiIosKz/FH2LH/y49jZcbm/4MePNTk2nmJf0ymNcjK0fnm I=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 8Vcdiq6a3gEzu1kd9D3SXRhu8odtLdwfaNLMVV4pcfP+CBcV0GsgdPkLh86Q4M6llxFbBZSO8i
 lBGg6e9Rc2fwNZLdoFh7bY9V2GnlMyuixjajzPIZ5rHqb/Upld0OdrEezDv+HMUatSCfCnj3Hf
 iMDN6RY/uWDJ7ezfGmRAXh9BPOAMqmoM79JyJSkAeGJJSk3epCxXb7G2a1Pwv5/pTNf+8Bkwez
 Dku+pWBL//AfyNwjr7IN86o6UbvTK1+8Te73vE2rAcj1cUQ8mlMYuQTziAIcKTei9o2Z8HCWpP
 dPI=
X-SBRS: 2.7
X-MesageID: 16253793
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="16253793"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit PV
 support
Date: Fri, 17 Apr 2020 16:50:02 +0100
Message-ID: <20200417155004.16806-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200417155004.16806-1-andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is the start of some performance and security-hardening improvements,
based on the fact that 32bit PV guests are few and far between these days.

Ring1 is full or architectural corner cases, such as counting as supervisor
from a paging point of view.  This accounts for a substantial performance hit
on processors from the last 8 years (adjusting SMEP/SMAP on every privilege
transition), and the gap is only going to get bigger with new hardware
features.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>

There is a series I can't quite post yet which wants to conditionally turn
opt_pv32 off, which is why I've put it straight in in an int8_t form rather
than a straight boolean form.
---
 docs/misc/xen-command-line.pandoc | 12 +++++++++++-
 xen/arch/x86/Kconfig              | 16 ++++++++++++++++
 xen/arch/x86/pv/domain.c          | 35 +++++++++++++++++++++++++++++++++++
 xen/arch/x86/setup.c              |  9 +++++++--
 xen/include/asm-x86/pv/domain.h   |  6 ++++++
 5 files changed, 75 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index acd0b3d994..ee12b0f53f 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1694,7 +1694,17 @@ The following resources are available:
     CDP, one COS will corespond two CBMs other than one with CAT, due to the
     sum of CBMs is fixed, that means actual `cos_max` in use will automatically
     reduce to half when CDP is enabled.
-	
+
+### pv
+    = List of [ 32=<bool> ]
+
+    Applicability: x86
+
+Controls for aspects of PV guest support.
+
+*   The `32` boolean controls whether 32bit PV guests can be created.  It
+    defaults to `true`, and is ignored when `CONFIG_PV32` is compiled out.
+
 ### pv-linear-pt (x86)
 > `= <boolean>`
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 8149362bde..4c52197de3 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -49,6 +49,22 @@ config PV
 
 	  If unsure, say Y.
 
+config PV32
+	bool "Support for 32bit PV guests"
+	depends on PV
+	default y
+	---help---
+	  The 32bit PV ABI uses Ring1, an area of the x86 architecture which
+	  was deprecated and mostly removed in the AMD64 spec.  As a result,
+	  it occasionally conflicts with newer x86 hardware features, causing
+	  overheads for Xen to maintain backwards compatibility.
+
+	  People may wish to disable 32bit PV guests for attack surface
+	  reduction, or performance reasons.  Backwards compatibility can be
+	  provided via the PV Shim mechanism.
+
+	  If unsure, say Y.
+
 config PV_LINEAR_PT
        bool "Support for PV linear pagetables"
        depends on PV
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 70fae43965..47a0db082f 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -16,6 +16,39 @@
 #include <asm/pv/domain.h>
 #include <asm/shadow.h>
 
+#ifdef CONFIG_PV32
+int8_t __read_mostly opt_pv32 = -1;
+#endif
+
+static int parse_pv(const char *s)
+{
+    const char *ss;
+    int val, rc = 0;
+
+    do {
+        ss = strchr(s, ',');
+        if ( !ss )
+            ss = strchr(s, '\0');
+
+        if ( (val = parse_boolean("32", s, ss)) >= 0 )
+        {
+#ifdef CONFIG_PV32
+            opt_pv32 = val;
+#else
+            printk(XENLOG_INFO
+                   "CONFIG_PV32 disabled - ignoring 'pv=32' setting\n");
+#endif
+        }
+        else
+            rc = -EINVAL;
+
+        s = ss + 1;
+    } while ( *ss );
+
+    return rc;
+}
+custom_param("pv", parse_pv);
+
 static __read_mostly enum {
     PCID_OFF,
     PCID_ALL,
@@ -174,6 +207,8 @@ int switch_compat(struct domain *d)
 
     BUILD_BUG_ON(offsetof(struct shared_info, vcpu_info) != 0);
 
+    if ( !opt_pv32 )
+        return -EOPNOTSUPP;
     if ( is_hvm_domain(d) || domain_tot_pages(d) != 0 )
         return -EACCES;
     if ( is_pv_32bit_domain(d) )
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 885919d5c3..c50aefb2de 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -53,6 +53,7 @@
 #include <asm/spec_ctrl.h>
 #include <asm/guest.h>
 #include <asm/microcode.h>
+#include <asm/pv/domain.h>
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool __initdata opt_nosmp;
@@ -1875,8 +1876,12 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
     {
         snprintf(s, sizeof(s), "xen-%d.%d-x86_64 ", major, minor);
         safe_strcat(*info, s);
-        snprintf(s, sizeof(s), "xen-%d.%d-x86_32p ", major, minor);
-        safe_strcat(*info, s);
+
+        if ( opt_pv32 )
+        {
+            snprintf(s, sizeof(s), "xen-%d.%d-x86_32p ", major, minor);
+            safe_strcat(*info, s);
+        }
     }
     if ( hvm_enabled )
     {
diff --git a/xen/include/asm-x86/pv/domain.h b/xen/include/asm-x86/pv/domain.h
index 7a69bfb303..df9716ff26 100644
--- a/xen/include/asm-x86/pv/domain.h
+++ b/xen/include/asm-x86/pv/domain.h
@@ -23,6 +23,12 @@
 
 #include <xen/sched.h>
 
+#ifdef CONFIG_PV32
+extern int8_t opt_pv32;
+#else
+# define opt_pv32 false
+#endif
+
 /*
  * PCID values for the address spaces of 64-bit pv domains:
  *
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 15:50:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 15:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPTG8-0007XQ-VK; Fri, 17 Apr 2020 15:50:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9Py=6B=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jPTG7-0007X6-07
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 15:50:27 +0000
X-Inumbo-ID: 1f61c946-80c3-11ea-8d2d-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1f61c946-80c3-11ea-8d2d-12813bfff9fa;
 Fri, 17 Apr 2020 15:50:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587138613;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=I+Bzh3V08iUOv/zMH5/E2yogQfOh3a7ZmPE910Vqxec=;
 b=b6K8WYIT+yJsqi9Eb2Edl+tupQ8guogVzlVKRG4M/eAcnMCBmCVlo3kX
 vUlKY7W3ImYRftVfbgnHOnDwFmjEzm2CY0Ri/eeAGP8GQnpwgeI27+Aex
 gAK1p8aprKrYmAJsZPpZkETvmEXUegiXQpLusuRJt6enm/LJq72dFsvtM 4=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: ZZHdT/SVFo4ioFH9zsgNLB31zP9EFSLqKfJ1WrK6nWJd9gTlf5lGp94n5yIVrvpF+MJ6J6Z5xA
 quFbwGvXi+DAJP2wViJRg163Sf9NhLgrl02pS8kqn1Z4s8ixFd1VQxipQ80JL3rZyhr9FnHgFx
 RG2iB+SiTSaulJ8iyyT/KL/KlHIdN3fW+iyEmmrwhoPMa2pM+DDubLbuZmuFN1i3FF/9YE0li5
 Mye8StftOunlmrc6BQr6EmnZKN53rV39LgrhQj3uIY/0aR+MeBj1NjRVTPyfHT17ZphWVikUnl
 NPw=
X-SBRS: 2.7
X-MesageID: 16168815
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="16168815"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 3/3] x86/pv: Compile out compat_gdt in !CONFIG_PV builds
Date: Fri, 17 Apr 2020 16:50:04 +0100
Message-ID: <20200417155004.16806-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200417155004.16806-1-andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

There is no need for the Compat GDT if there are no 32bit PV guests.  This
saves 4k per online CPU

Bloat-o-meter reports the following savings in Xen itself:

  add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605)
  Function                                     old     new   delta
  cpu_smpboot_free                            1249    1256      +7
  per_cpu__compat_gdt_l1e                        8       -      -8
  per_cpu__compat_gdt                            8       -      -8
  init_idt_traps                               442     420     -22
  load_system_tables                           414     364     -50
  trap_init                                    444     280    -164
  cpu_smpboot_callback                        1255     991    -264
  boot_compat_gdt                             4096       -   -4096
  Total: Before=3062726, After=3058121, chg -0.15%

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>

The increase in cpu_smpboot_free() appears to be a consequence of a totally
different layout of basic blocks.
---
 xen/arch/x86/cpu/common.c |  5 +++--
 xen/arch/x86/desc.c       |  2 ++
 xen/arch/x86/smpboot.c    |  5 ++++-
 xen/arch/x86/traps.c      | 10 +++++++---
 4 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 1b33f1ed71..7b093cb421 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -752,8 +752,9 @@ void load_system_tables(void)
 
 	_set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss,
 			 sizeof(*tss) - 1, SYS_DESC_tss_avail);
-	_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
-			 sizeof(*tss) - 1, SYS_DESC_tss_busy);
+	if ( IS_ENABLED(CONFIG_PV32) )
+		_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
+				 sizeof(*tss) - 1, SYS_DESC_tss_busy);
 
 	per_cpu(full_gdt_loaded, cpu) = false;
 	lgdt(&gdtr);
diff --git a/xen/arch/x86/desc.c b/xen/arch/x86/desc.c
index dfeb1beaa8..39080ca672 100644
--- a/xen/arch/x86/desc.c
+++ b/xen/arch/x86/desc.c
@@ -55,6 +55,7 @@ seg_desc_t boot_gdt[PAGE_SIZE / sizeof(seg_desc_t)] =
     [SEL2GDT(PER_CPU_SELECTOR)] =     { 0x0000910000000000 },
 };
 
+#ifdef CONFIG_PV32
 __section(".data.page_aligned") __aligned(PAGE_SIZE)
 seg_desc_t boot_compat_gdt[PAGE_SIZE / sizeof(seg_desc_t)] =
 {
@@ -83,6 +84,7 @@ seg_desc_t boot_compat_gdt[PAGE_SIZE / sizeof(seg_desc_t)] =
     /* 0xe060 - per-CPU entry (limit == cpu) */
     [SEL2GDT(PER_CPU_SELECTOR)] =     { 0x0000910000000000 },
 };
+#endif
 
 /*
  * Used by each CPU as it starts up, to enter C with a suitable %cs.
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 09264b02d1..f9f63e496f 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -959,7 +959,8 @@ static void cpu_smpboot_free(unsigned int cpu, bool remove)
             free_domheap_page(mfn_to_page(mfn));
     }
 
-    FREE_XENHEAP_PAGE(per_cpu(compat_gdt, cpu));
+    if ( IS_ENABLED(CONFIG_PV32) )
+        FREE_XENHEAP_PAGE(per_cpu(compat_gdt, cpu));
 
     if ( remove )
     {
@@ -1001,6 +1002,7 @@ static int cpu_smpboot_alloc(unsigned int cpu)
     BUILD_BUG_ON(NR_CPUS > 0x10000);
     gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a = cpu;
 
+#ifdef CONFIG_PV32
     per_cpu(compat_gdt, cpu) = gdt = alloc_xenheap_pages(0, memflags);
     if ( gdt == NULL )
         goto out;
@@ -1008,6 +1010,7 @@ static int cpu_smpboot_alloc(unsigned int cpu)
         l1e_from_pfn(virt_to_mfn(gdt), __PAGE_HYPERVISOR_RW);
     memcpy(gdt, boot_compat_gdt, NR_RESERVED_GDT_PAGES * PAGE_SIZE);
     gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a = cpu;
+#endif
 
     if ( idt_tables[cpu] == NULL )
         idt_tables[cpu] = alloc_xenheap_pages(0, memflags);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index e838846c6b..0bcf554e93 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -100,8 +100,10 @@ static DEFINE_PER_CPU(unsigned long, last_extable_addr);
 
 DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, gdt);
 DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, gdt_l1e);
+#ifdef CONFIG_PV32
 DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, compat_gdt);
 DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, compat_gdt_l1e);
+#endif
 
 /* Master table, used by CPU0. */
 idt_entry_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
@@ -1999,7 +2001,8 @@ void __init init_idt_traps(void)
     idt_tables[0] = idt_table;
 
     this_cpu(gdt) = boot_gdt;
-    this_cpu(compat_gdt) = boot_compat_gdt;
+    if ( IS_ENABLED(CONFIG_PV32) )
+        this_cpu(compat_gdt) = boot_compat_gdt;
 }
 
 extern void (*const autogen_entrypoints[X86_NR_VECTORS])(void);
@@ -2030,8 +2033,9 @@ void __init trap_init(void)
     /* Cache {,compat_}gdt_l1e now that physically relocation is done. */
     this_cpu(gdt_l1e) =
         l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
-    this_cpu(compat_gdt_l1e) =
-        l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_RW);
+    if ( IS_ENABLED(CONFIG_PV32) )
+        this_cpu(compat_gdt_l1e) =
+            l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_RW);
 
     percpu_traps_init();
 
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 15:50:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 15:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPTG3-0007Wi-JL; Fri, 17 Apr 2020 15:50:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9Py=6B=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jPTG1-0007WZ-WD
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 15:50:22 +0000
X-Inumbo-ID: 1f61c945-80c3-11ea-8d2d-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1f61c945-80c3-11ea-8d2d-12813bfff9fa;
 Fri, 17 Apr 2020 15:50:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587138612;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=ZhK0+BzJnp1VoPrHaLr5cGNVpfHqgyvx1ITJ+8zW0CY=;
 b=OCq2KqcwQhkfBU0cDmGVB0GA+B51j0jHk2AAGtCru15GqK6R6V3ET5cI
 kpoSzCd7pMlZHvu+XV6mEMeDXmzUcRdvNdD7ZYMCisHAfwz2/vUiIcEuW
 v5QZqGuDMqUGr1hTRISJV2DNWTejoDNJwCrmCCEn+oqyuPEBUyIJ7M75t g=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: W60PJzhwI65JY1GYUh57Ly621HUTbcLiEz5oy0VTNXg7PnHPDHnYNirQiboUboOIulASbJDdr1
 poaZgku4gp0ROTF6jflE5I2WFFCLUwM0Ya2F4PWcxEXzKi4y+zYd1smgUspOHsm8J95tdeSzlp
 +OKmDFAywofaNFoW08QuQFuap1MD0xHI8w7Ovt3Nyi32fFbRBZOBNswxmR3iVUdI/bbXFjPUQW
 uU+YPouzi5QerAjeF09mIejvZPFIUMO+zrzu6EmUG3W+qmJBDCJqDEy+RGjkDI+W0TUnAwD2oY
 0pQ=
X-SBRS: 2.7
X-MesageID: 16168814
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="16168814"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 2/3] x86/pv: Short-circuit is_pv_{32,
 64}bit_domain() in !CONFIG_PV32 builds
Date: Fri, 17 Apr 2020 16:50:03 +0100
Message-ID: <20200417155004.16806-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200417155004.16806-1-andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

... and move arch.is_32bit_pv into the pv union while at it.

Bloat-o-meter reports the following net savings with some notable differences
highlighted:

  add/remove: 4/6 grow/shrink: 5/76 up/down: 1955/-18792 (-16837)
  Function                                     old     new   delta
  ...
  pv_vcpu_initialise                           411     158    -253
  guest_cpuid                                 1837    1584    -253
  pv_hypercall                                 579     297    -282
  check_descriptor                             427     130    -297
  _get_page_type                              5915    5202    -713
  arch_get_info_guest                         2225    1195   -1030
  context_switch                              3831    2635   -1196
  dom0_construct_pv                          10284    8939   -1345
  arch_set_info_guest                         5564    3267   -2297
  Total: Before=3079563, After=3062726, chg -0.55%

In principle, DOMAIN_is_32bit_pv should be based on CONFIG_PV32, but the
assembly code is going to need further untangling before that becomes easy to
do.  For now, use CONFIG_PV as missed accidentally by c/s ec651bd2460 "x86:
make entry point code build when !CONFIG_PV".

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/domctl.c             |  4 ++--
 xen/arch/x86/pv/domain.c          |  6 +++---
 xen/arch/x86/pv/hypercall.c       |  2 ++
 xen/arch/x86/x86_64/asm-offsets.c |  4 +++-
 xen/include/asm-x86/domain.h      |  4 ++--
 xen/include/xen/sched.h           | 15 +++++++++++++--
 6 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index add70126b9..3822dd7fd1 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -576,8 +576,8 @@ long arch_do_domctl(
             ret = -EOPNOTSUPP;
         else if ( is_pv_domain(d) )
         {
-            if ( ((domctl->u.address_size.size == 64) && !d->arch.is_32bit_pv) ||
-                 ((domctl->u.address_size.size == 32) && d->arch.is_32bit_pv) )
+            if ( ((domctl->u.address_size.size == 64) && !d->arch.pv.is_32bit) ||
+                 ((domctl->u.address_size.size == 32) && d->arch.pv.is_32bit) )
                 ret = 0;
             else if ( domctl->u.address_size.size == 32 )
                 ret = switch_compat(d);
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 47a0db082f..e0977bfbd7 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -215,7 +215,7 @@ int switch_compat(struct domain *d)
         return 0;
 
     d->arch.has_32bit_shinfo = 1;
-    d->arch.is_32bit_pv = 1;
+    d->arch.pv.is_32bit = 1;
 
     for_each_vcpu( d, v )
     {
@@ -235,7 +235,7 @@ int switch_compat(struct domain *d)
     return 0;
 
  undo_and_fail:
-    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
+    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
     for_each_vcpu( d, v )
     {
         free_compat_arg_xlat(v);
@@ -358,7 +358,7 @@ int pv_domain_initialise(struct domain *d)
     d->arch.ctxt_switch = &pv_csw;
 
     /* 64-bit PV guest by default. */
-    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
+    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
 
     d->arch.pv.xpti = is_hardware_domain(d) ? opt_xpti_hwdom : opt_xpti_domu;
 
diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index 17ddf9ea1f..32d90a543f 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -302,6 +302,7 @@ void pv_ring3_init_hypercall_page(void *p)
     }
 }
 
+#ifdef CONFIG_PV32
 void pv_ring1_init_hypercall_page(void *p)
 {
     unsigned int i;
@@ -329,6 +330,7 @@ void pv_ring1_init_hypercall_page(void *p)
         *(u8  *)(p+ 7) = 0xc3;    /* ret */
     }
 }
+#endif
 
 /*
  * Local variables:
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index 500df7a3e7..9f66a69be7 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -98,8 +98,10 @@ void __dummy__(void)
     OFFSET(VCPU_nsvm_hap_enabled, struct vcpu, arch.hvm.nvcpu.u.nsvm.ns_hap_enabled);
     BLANK();
 
-    OFFSET(DOMAIN_is_32bit_pv, struct domain, arch.is_32bit_pv);
+#ifdef CONFIG_PV
+    OFFSET(DOMAIN_is_32bit_pv, struct domain, arch.pv.is_32bit);
     BLANK();
+#endif
 
     OFFSET(VCPUINFO_upcall_pending, struct vcpu_info, evtchn_upcall_pending);
     OFFSET(VCPUINFO_upcall_mask, struct vcpu_info, evtchn_upcall_mask);
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 4192c636b1..ae155d6522 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -254,6 +254,8 @@ struct pv_domain
 
     atomic_t nr_l4_pages;
 
+    /* Is a 32-bit PV guest? */
+    bool is_32bit;
     /* XPTI active? */
     bool xpti;
     /* Use PCID feature? */
@@ -333,8 +335,6 @@ struct arch_domain
     /* NB. protected by d->event_lock and by irq_desc[irq].lock */
     struct radix_tree_root irq_pirq;
 
-    /* Is a 32-bit PV (non-HVM) guest? */
-    bool_t is_32bit_pv;
     /* Is shared-info page in 32-bit format? */
     bool_t has_32bit_shinfo;
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 195e7ee583..6101761d25 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -985,7 +985,11 @@ static always_inline bool is_pv_vcpu(const struct vcpu *v)
 #ifdef CONFIG_COMPAT
 static always_inline bool is_pv_32bit_domain(const struct domain *d)
 {
-    return is_pv_domain(d) && d->arch.is_32bit_pv;
+#ifdef CONFIG_PV32
+    return is_pv_domain(d) && d->arch.pv.is_32bit;
+#else
+    return false;
+#endif
 }
 
 static always_inline bool is_pv_32bit_vcpu(const struct vcpu *v)
@@ -995,7 +999,14 @@ static always_inline bool is_pv_32bit_vcpu(const struct vcpu *v)
 
 static always_inline bool is_pv_64bit_domain(const struct domain *d)
 {
-    return is_pv_domain(d) && !d->arch.is_32bit_pv;
+    if ( !is_pv_domain(d) )
+        return false;
+
+#ifdef CONFIG_PV32
+    return !d->arch.pv.is_32bit;
+#else
+    return true;
+#endif
 }
 
 static always_inline bool is_pv_64bit_vcpu(const struct vcpu *v)
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 15:50:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 15:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPTFt-0007W3-Pq; Fri, 17 Apr 2020 15:50:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9Py=6B=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jPTFs-0007Vw-2c
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 15:50:12 +0000
X-Inumbo-ID: 1e35ab81-80c3-11ea-8d2d-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1e35ab81-80c3-11ea-8d2d-12813bfff9fa;
 Fri, 17 Apr 2020 15:50:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587138610;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=Ty9LCOSIDFwYRg9etCmwYzIgyzp5o29Ynp1qGNaPCMc=;
 b=gUILGGtjZDtyknJf5IP2mYV36oW/oLiJbBF2reVTeMU+66A9qKjD+PJZ
 7ibE8tySVB2AfBn8uATjiRPaRR6U2MuDCL0BDlMhLcL7WjTp+DNP8Ug4Q
 AEZ4EddwcMC2D+h/zevxS3uCt8awPtPa2b2SeI5MgJWS3EEhJFkA03eiY k=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: HNegbfuZ/DbU50cCy0gHrJ7kaVRk98n/zdGAAYajyTOWKrRD/iqU2e3o7UEpdrNYUtNX6+Zf3Q
 U7sd3xwM5EdHJJWgal+5pC8fltKPm4FL+RjweRUShk6UrMGCkbmZLSFrB+25ffzLNypC1p8T1l
 G5RPu5JPQTpldmMRmi4kquZ9ILV1sAQNeDjaQITKlcaVXbs7l/HDAxvJt4v4+DGIQD+ruVAzYY
 4WE+quqCl9ENMMb8fG/nAcZgH6X3evM+ey/7CCU8XJ987Sbh9A33HyCuPMljRWMTRSc/VXUWi1
 LEA=
X-SBRS: 2.7
X-MesageID: 16528319
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="16528319"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 0/3] x86/pv: Start to trim 32bit support
Date: Fri, 17 Apr 2020 16:50:01 +0100
Message-ID: <20200417155004.16806-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Wei Liu <wl@xen.org>, Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Downstreams may want this for either security or performance reasons.  Offer
some options, and take advantage of some of the very low hanging fruit it
offers.

There is plenty more incremental cleanup which can be done at a later point.

Andrew Cooper (3):
  x86/pv: Options to disable and/or compile out 32bit PV support
  x86/pv: Short-circuit is_pv_{32,64}bit_domain() in !CONFIG_PV32 builds
  x86/pv: Compile out compat_gdt in !CONFIG_PV builds

 docs/misc/xen-command-line.pandoc | 12 +++++++++++-
 xen/arch/x86/Kconfig              | 16 +++++++++++++++
 xen/arch/x86/cpu/common.c         |  5 +++--
 xen/arch/x86/desc.c               |  2 ++
 xen/arch/x86/domctl.c             |  4 ++--
 xen/arch/x86/pv/domain.c          | 41 ++++++++++++++++++++++++++++++++++++---
 xen/arch/x86/pv/hypercall.c       |  2 ++
 xen/arch/x86/setup.c              |  9 +++++++--
 xen/arch/x86/smpboot.c            |  5 ++++-
 xen/arch/x86/traps.c              | 10 +++++++---
 xen/arch/x86/x86_64/asm-offsets.c |  4 +++-
 xen/include/asm-x86/domain.h      |  4 ++--
 xen/include/asm-x86/pv/domain.h   |  6 ++++++
 xen/include/xen/sched.h           | 15 ++++++++++++--
 14 files changed, 116 insertions(+), 19 deletions(-)

-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 16:07:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 16:07:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPTWK-0000rH-QP; Fri, 17 Apr 2020 16:07:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ygtx=6B=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPTWJ-0000rC-06
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 16:07:11 +0000
X-Inumbo-ID: 7dd06e71-80c5-11ea-8d34-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7dd06e71-80c5-11ea-8d34-12813bfff9fa;
 Fri, 17 Apr 2020 16:07:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=6+dABX/BVEpImn2q9apkI5btMGodHnh717dR+CmwPbo=; b=XJPguxHV6CvF1jVOruWkeP/c8O
 VhU7X6A1r92tqitZ6e5B/5TAdBFws8pxtrLOzkmbHdjInCZq29aNgHv8Mis+jpyF7EndRDOMwbs/+
 K9t7v9jfjHB1YBJO7Rdx5HKraugKf2H8Pz/GbYY7vdFgOeW7CO3EFOFcmuUXHadW1lHk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPTWD-0002Cx-40; Fri, 17 Apr 2020 16:07:05 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPTWC-0002v2-Ry; Fri, 17 Apr 2020 16:07:05 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Bertrand Marquis <Bertrand.Marquis@arm.com>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <5deb3992-3cf5-2b00-8cef-af75ed83a1fd@xen.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
 <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
 <057f48b7-84be-0bc5-773d-d01a79181b20@xen.org>
 <alpine.DEB.2.21.2004081642070.28673@sstabellini-ThinkPad-T480s>
 <914c421a-02cf-375b-a3fa-1c5e934cdeb3@xen.org>
 <3b002deb-5a80-3dc4-9462-649135cfbd29@xen.org>
 <C39B873E-F40C-4549-9D5E-953E88F94E43@arm.com>
From: Julien Grall <julien@xen.org>
Message-ID: <1b91aeb3-589b-ac68-8f92-a1e06fa9640d@xen.org>
Date: Fri, 17 Apr 2020 17:07:02 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <C39B873E-F40C-4549-9D5E-953E88F94E43@arm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, George Dunlap <George.Dunlap@citrix.com>,
 Wei Xu <xuwei5@hisilicon.com>, xen-devel <xen-devel@lists.xenproject.org>,
 nd <nd@arm.com>, Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Bertrand,

On 17/04/2020 16:16, Bertrand Marquis wrote:
> It seems that the problem is a bit bigger then expected and will need 
> more discussion and thinking.
> I did some research on my side and there are several design possible 
> depending on what should be the goal performance or real-time behaviour 
> (going from just give the status we have to fire a service interrupts 
> when any interrupts is acked by a guest to refresh our internal status).
> 
> In the short term, could we not agree to fix the typo by returning 
> always 0 and start a discussion on the vgic implementation ?

I have already pointed out multiple time now ([1], [2]) that I would not 
oppose the temporary solution. I think this is a matter of someone 
(Stefano?) to submit it :).

Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg01642.html
[2] 
https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg00459.html

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 16:29:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 16:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPTs1-0002Yw-TH; Fri, 17 Apr 2020 16:29:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPTrz-0002Yr-Tp
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 16:29:35 +0000
X-Inumbo-ID: 9b136426-80c8-11ea-8d48-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9b136426-80c8-11ea-8d48-12813bfff9fa;
 Fri, 17 Apr 2020 16:29:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=FMKeicTiD2QiPkpOMNLpoPUbVaE9lUYlI6MpPpw62/4=; b=f1XYFLU5KgaolgkH4vcuYkQQ6
 fHV/HiRyF0Y7Euk7cdPviCi96yTb1cjU7xeMcmxT5fbxfrWztPjS4ceBJgUf5RzDTRSe8mJil671X
 U3XwpL3sWIkhiJi6NZCrfLsMP3tssuuGHNtdCoz4pUkHqrvQMbf/cPsdcXclNkMr1wRZ8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPTrq-0002cz-VC; Fri, 17 Apr 2020 16:29:27 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPTrq-0004Yf-Mi; Fri, 17 Apr 2020 16:29:26 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPTrq-0007m5-M6; Fri, 17 Apr 2020 16:29:26 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149697-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149697: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:regression
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=7a56db0299f9d43b4fe076838150c5cc293df131
X-Osstest-Versions-That: linux=9786cab674574239b04df638f825ee0e7d76a48c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 16:29:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine      4 memdisk-try-append       fail REGR. vs. 149693

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149693

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149693
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149693
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149693
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149693
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149693
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149693
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149693
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149693
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                7a56db0299f9d43b4fe076838150c5cc293df131
baseline version:
 linux                9786cab674574239b04df638f825ee0e7d76a48c

Last test of basis   149693  2020-04-16 19:59:31 Z    0 days
Testing same since   149697  2020-04-17 07:30:41 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexei Starovoitov <ast@kernel.org>
  Amol Grover <frextrite@gmail.com>
  Andrew Lunn <andrew@lunn.ch>
  Andrey Ignatov <rdna@fb.com>
  Andrii Nakryiko <andriin@fb.com>
  Arnd Bergmann <arnd@arndb.de>
  Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
  Björn Töpel <bjorn.topel@gmail.com>
  Björn Töpel <bjorn.topel@intel.com>
  Cambda Zhu <cambda@linux.alibaba.com>
  Chen-Yu Tsai <wens@csie.org>
  Christophe JAILLET <christophe.jaillet@wanadoo.fr>
  Clemens Gruber <clemens.gruber@pqgruber.com>
  Colin Ian King <colin.king@canonical.com>
  Dan Carpenter <dan.carpenter@oracle.com>
  Daniel Borkmann <daniel@iogearbox.net>
  Daniel T. Lee <danieltimlee@gmail.com>
  David Ahern <dsahern@gmail.com>
  David Howells <dhowells@redhat.com>
  David S. Miller <davem@davemloft.net>
  DENG Qingfang <dqfext@gmail.com>
  Dmytro Linkin <dmitrolin@mellanox.com>
  Eli Cohen <eli@mellanox.com>
  Enric Balletbo i Serra <enric.balletbo@collabora.com>
  Eran Ben Elisha <eranbe@mellanox.com>
  Eric Dumazet <edumazet@google.com>
  Florian Fainelli <f.fainelli@gmail.com>
  Florian Westphal <fw@strlen.de>
  Frank Wunderlich <frank-w@public-files.de>
  Fugang Duan <fugang.duan@nxp.com>
  Gilberto Bertin <me@jibi.io>
  Jakub Kicinski <kuba@kernel.org>
  Jakub Sitnicki <jakub@cloudflare.com>
  Jason Gunthorpe <jgg@mellanox.com>
  Jason Yan <yanaijie@huawei.com>
  Jeremy Cline <jcline@redhat.com>
  Joe Stringer <joe@wand.net.nz>
  Johan Jonker <jbx6244@gmail.com>
  Johannes Berg <johannes.berg@intel.com>
  Jon Maloy <jmaloy@redhat.com>
  Jonathan Lemon <jonathan.lemon@gmail.com>
  Ka-Cheong Poon <ka-cheong.poon@oracle.com>
  Kalle Valo <kvalo@codeaurora.org>
  Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
  KP Singh <kpsingh@google.com>
  Li RongQing <lirongqing@baidu.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lothar Rubusch <l.rubusch@gmail.com>
  Luke Nelson <luke.r.nels@gmail.com>
  Luke Nelson <lukenels@cs.washington.edu>
  Maciej Żenczykowski <maze@google.com>
  Magnus Karlsson <magnus.karlsson@intel.com>
  Martin Fuzzey <martin.fuzzey@flowbird.group>
  Martin KaFai Lau <kafai@fb.com>
  Matteo Croce <mcroce@redhat.com>
  Michael Weiß <michael.weiss@aisec.fraunhofer.de>
  Moshe Shemesh <moshe@mellanox.com>
  Pablo Neira Ayuso <pablo@netfilter.org>
  Parav Pandit <parav@mellanox.com>
  Paul Blakey <paulb@mellanox.com>
  Qiujun Huang <hqjagain@gmail.com>
  Rafał Miłecki <rafal@milecki.pl>
  Randy Dunlap <rdunlap@infradead.org>
  René van Dorst <opensource@vdorst.com>
  Rob Herring <robh@kernel.org>
  Roi Dayan <roid@mellanox.com>
  Roman Mashak <mrv@mojatatu.com>
  Russell King <rmk+kernel@armlinux.org.uk>
  Saeed Mahameed <saeedm@mellanox.com>
  Santosh Shilimkar <santosh.shilimkar@oracle.com>
  Sean Wang <sean.wang@mediatek.com>
  Sebastian Andrzej Siewior <bigeasy@linutronix.de>
  Shannon Nelson <snelson@pensando.io>
  Slava Bacherikov <slava@bacher09.org>
  Song Liu <songliubraving@fb.com>
  Stefano Brivio <sbrivio@redhat.com>
  Sumit Garg <sumit.garg@linaro.org>
  Taehee Yoo <ap420073@gmail.com>
  Tamizh chelvam <tamizhr@codeaurora.org>
  Taras Chornyi <taras.chornyi@plvision.eu>
  Tim Stallard <code@timstallard.me.uk>
  Toke Høiland-Jørgensen <toke@redhat.com>
  Tom Lendacky <thomas.lendacky@amd.com>
  Trond Myklebust <trond.myklebust@hammerspace.com>
  Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
  Tuong Lien <tuong.t.lien@dektech.com.au>
  Vadym Kochan <vadym.kochan@plvision.eu>
  Vladimir Oltean <vladimir.oltean@nxp.com>
  Wang Wenhu <wenhu.wang@vivo.com>
  Xi Wang <xi.wang@gmail.com>
  YueHaibing <yuehaibing@huawei.com>
  Zou Wei <zou_wei@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 16:32:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 16:32:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPTuW-0003JC-El; Fri, 17 Apr 2020 16:32:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=4I3R=6B=xilinx.com=stefanos@srs-us1.protection.inumbo.net>)
 id 1jPTuV-0003J7-NT
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 16:32:11 +0000
X-Inumbo-ID: fc7f3ece-80c8-11ea-8d49-12813bfff9fa
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (unknown
 [40.107.93.62]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fc7f3ece-80c8-11ea-8d49-12813bfff9fa;
 Fri, 17 Apr 2020 16:32:11 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Jc69E2zzooSJ5NNUFHfKRga0w26jQSod0NMW7MEehq2c4NSwg6RTrMxS/ITpafRw9pTHdpPORMdhqWUEUjLs506TlJKJmLSbYB/F/0+QWJK+TIekciiHQJowXSTZW2QiwzNjhOGrEAyGj4cCMF34fMqgUj7zXtW1L+CtO6YoQwpaGZViBpJ1XW7Qbnucr13Nddbf7AIqJwC5OMiKJJdD2WcjOT8g5Lu7KTRI2lsEpM/f+WzNLnOG1Az5ncICubIJn9BexWeBCaSHJ5i0igluJGg1lDSY8ZotbVsu6kuFTG78d8dNu+hDc/3Rg0pPYMZxF3SZ9zpdSKybaE/IOu+OLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=PdIcjiLhfWOL6ylvSHUwMphztwroU6PYI+7VkROH3aU=;
 b=cp1ouxUNMPmeRYcOaZxDVSfJNhCICIiSjNvCEXh7WZ4u+EVGOO6mk72wxWa/fOSUDXKrp4zyeo+t7yB5QSTm65l5cF9B4lhV8536gk4PhxNd+4nIukeOUoYDv6VE4fewkmxSRl92f/DCVXUtZmLAevt2MzNU6kDiAfgNheBiIsfS+hUYS/5V04A/edpeuhdF8b9iFq60FrgTycq8yx1mEhrZGm1WhzVCbzvN2JPqFXyspp6nIE6h6HnXnUbgRhSDSgth/j1b6AlZHhc9fsQyeRbwRVeobgOcE1hYdokfJDGUwTym9Aeu7shlH5qmMA+PAu5AWYxHdUAP77MIRNe7iA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 149.199.60.83) smtp.rcpttodomain=xen.org smtp.mailfrom=xilinx.com;
 dmarc=bestguesspass action=none header.from=xilinx.com; dkim=none (message
 not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=PdIcjiLhfWOL6ylvSHUwMphztwroU6PYI+7VkROH3aU=;
 b=GFO4D2GKABsAto317wOC9UkyE9Mvhh+BRjEPQfISGFlnkUYYz7Tc1Z8HNfRbslQhTGviULprYQ2oaBXpJP37kwuj/a8C1KZwffpclBRB2Njc9tvyKWi5IwPVXmXHn6SBc3MP84H2ZTewNSjezYbUbh2yhP/TeMVi8XhA+4KhU/Q=
Received: from DM3PR03CA0016.namprd03.prod.outlook.com (2603:10b6:0:50::26) by
 MWHPR02MB2720.namprd02.prod.outlook.com (2603:10b6:300:10a::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Fri, 17 Apr
 2020 16:32:08 +0000
Received: from CY1NAM02FT021.eop-nam02.prod.protection.outlook.com
 (2603:10b6:0:50:cafe::87) by DM3PR03CA0016.outlook.office365.com
 (2603:10b6:0:50::26) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend
 Transport; Fri, 17 Apr 2020 16:32:08 +0000
Authentication-Results: spf=pass (sender IP is 149.199.60.83)
 smtp.mailfrom=xilinx.com; xen.org; dkim=none (message not signed)
 header.d=none;xen.org; dmarc=bestguesspass action=none
 header.from=xilinx.com;
Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
 149.199.60.83 as permitted sender) receiver=protection.outlook.com;
 client-ip=149.199.60.83; helo=xsj-pvapsmtpgw01;
Received: from xsj-pvapsmtpgw01 (149.199.60.83) by
 CY1NAM02FT021.mail.protection.outlook.com (10.152.75.187) with Microsoft SMTP
 Server id 15.20.2921.25 via Frontend Transport; Fri, 17 Apr 2020 16:32:07
 +0000
Received: from [149.199.38.66] (port=50018 helo=xsj-pvapsmtp01)
 by xsj-pvapsmtpgw01 with esmtp (Exim 4.90)
 (envelope-from <stefano.stabellini@xilinx.com>)
 id 1jPTtd-0003jW-E0; Fri, 17 Apr 2020 09:31:17 -0700
Received: from [127.0.0.1] (helo=localhost)
 by xsj-pvapsmtp01 with smtp (Exim 4.63)
 (envelope-from <stefano.stabellini@xilinx.com>)
 id 1jPTuQ-0003fD-VD; Fri, 17 Apr 2020 09:32:07 -0700
Received: from [172.19.2.220] (helo=localhost)
 by xsj-pvapsmtp01 with esmtp (Exim 4.63)
 (envelope-from <stefanos@xilinx.com>)
 id 1jPTuI-0003cy-08; Fri, 17 Apr 2020 09:31:58 -0700
Date: Fri, 17 Apr 2020 09:31:57 -0700 (PDT)
From: Stefano Stabellini <stefano.stabellini@xilinx.com>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
In-Reply-To: <1b91aeb3-589b-ac68-8f92-a1e06fa9640d@xen.org>
Message-ID: <alpine.DEB.2.21.2004170930420.13631@sstabellini-ThinkPad-T480s>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <alpine.DEB.2.21.2003311121120.4572@sstabellini-ThinkPad-T480s>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
 <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
 <057f48b7-84be-0bc5-773d-d01a79181b20@xen.org>
 <alpine.DEB.2.21.2004081642070.28673@sstabellini-ThinkPad-T480s>
 <914c421a-02cf-375b-a3fa-1c5e934cdeb3@xen.org>
 <3b002deb-5a80-3dc4-9462-649135cfbd29@xen.org>
 <C39B873E-F40C-4549-9D5E-953E88F94E43@arm.com>
 <1b91aeb3-589b-ac68-8f92-a1e06fa9640d@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.2.0.1013-23620.005
X-TM-AS-User-Approved-Sender: Yes;Yes
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:149.199.60.83; CTRY:US; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:xsj-pvapsmtpgw01; PTR:unknown-60-83.xilinx.com; CAT:NONE;
 SFTY:;
 SFS:(10009020)(4636009)(7916004)(136003)(376002)(396003)(346002)(39860400002)(46966005)(426003)(44832011)(5660300002)(478600001)(966005)(336012)(186003)(9686003)(4326008)(47076004)(356005)(82740400003)(33716001)(6916009)(81166007)(54906003)(316002)(2906002)(8676002)(81156014)(8936002)(9786002)(7416002)(26005)(53546011)(70206006)(70586007);
 DIR:OUT; SFP:1101; 
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b7934679-6b0f-485a-adf1-08d7e2ecded3
X-MS-TrafficTypeDiagnostic: MWHPR02MB2720:
X-Microsoft-Antispam-PRVS: <MWHPR02MB2720710C3FAC57115548913EA0D90@MWHPR02MB2720.namprd02.prod.outlook.com>
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0376ECF4DD
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 8C0xUwAu0wU/YtLujPbV15IjnAFO74EH8rK+6utwfYW/aZj3D/WegwF4Ymeb5KIBRMgEUoIRldKwMuRZfVSQUrs/XapUJWiZ3gZo6HfuowGQXzR0np8PW/Z0RrIjtqz+c/CHI86jnA55rWv8lLA58gntiyoDr11IXTH8g/IXDWUz8c/W+J2OW0PmcpjxXjTW5/qomWZBHZdAFVV0pVBZVK3JRrj3fCiUiWRox7oJcuDPXoHTZnUfAdtiZqA8eF6VFJXR7GSItyhhj2u/gjXK0UG+fBdFWDvTl7PUBjznDYuMQsqRHczz6JZB+ux6SgAnadovXFY2p9P3CZtqxJphV7ATuwsp3LVl2O3T5XiNThnXnWqg7qO4GEuDxuosMgBPZD0H4FKO+XgsXc8Eg4lfRQXBG5ZvqGOUfal6CtfFxijzPS8VOfK7YzVAWATUE+U1gtj5ILUbfu3HcVmcmvq4WiYsn4EBSz5BsCNRm8sdYpAjI10Oi6pLOgahiGlzcb5bIbT4nlWZgSCVdoV+3F9WBNCKjK+/qC/GdTO0Kg3l8pBvO7WpnrAlwstLHObyci8Sq8knr9NAoANnQkiAr8uCaU3ey7KRFHg1rClNlGsuq6A=
X-OriginatorOrg: xilinx.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2020 16:32:07.4488 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b7934679-6b0f-485a-adf1-08d7e2ecded3
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.60.83];
 Helo=[xsj-pvapsmtpgw01]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2720
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, George Dunlap <George.Dunlap@citrix.com>,
 Wei Xu <xuwei5@hisilicon.com>, Bertrand Marquis <Bertrand.Marquis@arm.com>,
 nd <nd@arm.com>, xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 17 Apr 2020, Julien Grall wrote:
> Hi Bertrand,
> 
> On 17/04/2020 16:16, Bertrand Marquis wrote:
> > It seems that the problem is a bit bigger then expected and will need more
> > discussion and thinking.
> > I did some research on my side and there are several design possible
> > depending on what should be the goal performance or real-time behaviour
> > (going from just give the status we have to fire a service interrupts when
> > any interrupts is acked by a guest to refresh our internal status).
> > 
> > In the short term, could we not agree to fix the typo by returning always 0
> > and start a discussion on the vgic implementation ?
> 
> I have already pointed out multiple time now ([1], [2]) that I would not
> oppose the temporary solution. I think this is a matter of someone (Stefano?)
> to submit it :).
> 
> Cheers,
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg01642.html
> [2] https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg00459.html

I can submit it. Julien, would you prefer the plain always return 0
patch, or would you prefer if I tried to get the latest ISACTIVER
information (like this patch does) but only for the local processor?


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 16:48:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 16:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPU9p-0004Iz-4d; Fri, 17 Apr 2020 16:48:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ygtx=6B=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPU9n-0004Iu-Q0
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 16:47:59 +0000
X-Inumbo-ID: 31d05412-80cb-11ea-8d4f-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 31d05412-80cb-11ea-8d4f-12813bfff9fa;
 Fri, 17 Apr 2020 16:47:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=d7+plLdv5A+PdXs7CYiNYco9gxcmJgef7cePUxupGFI=; b=hGN4iR+RLRZOKn8b9eP5An5TAV
 iTU50MGkqdOiuwbXrzgRJorBGW/SjvcUmKbbxQJxXybc6jK2UMyoXr1IaaBeNKqCdnMfF6mRR5Zuo
 tsv6u7+L3yveY974EHOdHM7OP0qWAk0gWFqKD33pfHb8N1b/6StsSuCToCCvqshzQreo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPU9i-0002zL-Vf; Fri, 17 Apr 2020 16:47:54 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPU9i-0005R4-Ny; Fri, 17 Apr 2020 16:47:54 +0000
Subject: Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
To: Stefano Stabellini <stefano.stabellini@xilinx.com>
References: <20200327023451.20271-1-sstabellini@kernel.org>
 <2bb21703-8078-cd92-0463-bea049413f32@xen.org>
 <alpine.DEB.2.21.2004010747530.10657@sstabellini-ThinkPad-T480s>
 <d457455f-a1ad-1964-ff15-45d794f1822a@xen.org>
 <alpine.DEB.2.21.2004031234010.23034@sstabellini-ThinkPad-T480s>
 <CAJ=z9a2LdC-nSMUEjLhGp_4PAkcRkp4wJKXiAy0ftt34T8LAVg@mail.gmail.com>
 <D048CA76-8C9F-4F44-B05C-D834A6D0D37D@citrix.com>
 <9de763c9-19f2-2163-d5db-95176dbce3cc@xen.org>
 <082584BF-3837-48A7-A0C2-9582BA3379C0@citrix.com>
 <a29cb044-7e78-a47b-f842-327373e0ec9f@xen.org>
 <4FBF62BA-5844-4506-8C01-FE1A6F4A7ED2@citrix.com>
 <057f48b7-84be-0bc5-773d-d01a79181b20@xen.org>
 <alpine.DEB.2.21.2004081642070.28673@sstabellini-ThinkPad-T480s>
 <914c421a-02cf-375b-a3fa-1c5e934cdeb3@xen.org>
 <3b002deb-5a80-3dc4-9462-649135cfbd29@xen.org>
 <C39B873E-F40C-4549-9D5E-953E88F94E43@arm.com>
 <1b91aeb3-589b-ac68-8f92-a1e06fa9640d@xen.org>
 <alpine.DEB.2.21.2004170930420.13631@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <651d7cd7-6a42-8898-72db-263bf6f7ea98@xen.org>
Date: Fri, 17 Apr 2020 17:47:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004170930420.13631@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "maz@kernel.org" <maz@kernel.org>, George Dunlap <George.Dunlap@citrix.com>,
 Wei Xu <xuwei5@hisilicon.com>, Bertrand Marquis <Bertrand.Marquis@arm.com>,
 xen-devel <xen-devel@lists.xenproject.org>, nd <nd@arm.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 17/04/2020 17:31, Stefano Stabellini wrote:
> On Fri, 17 Apr 2020, Julien Grall wrote:
>> Hi Bertrand,
>>
>> On 17/04/2020 16:16, Bertrand Marquis wrote:
>>> It seems that the problem is a bit bigger then expected and will need more
>>> discussion and thinking.
>>> I did some research on my side and there are several design possible
>>> depending on what should be the goal performance or real-time behaviour
>>> (going from just give the status we have to fire a service interrupts when
>>> any interrupts is acked by a guest to refresh our internal status).
>>>
>>> In the short term, could we not agree to fix the typo by returning always 0
>>> and start a discussion on the vgic implementation ?
>>
>> I have already pointed out multiple time now ([1], [2]) that I would not
>> oppose the temporary solution. I think this is a matter of someone (Stefano?)
>> to submit it :).
>>
>> Cheers,
>>
>> [1] https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg01642.html
>> [2] https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg00459.html
> 
> I can submit it. Julien, would you prefer the plain always return 0
> patch, or would you prefer if I tried to get the latest ISACTIVER
> information (like this patch does) but only for the local processor?

Always returning 0.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 17:07:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 17:07:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPUSA-0005y5-6L; Fri, 17 Apr 2020 17:06:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=lvC5=6B=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jPUS9-0005xz-MC
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 17:06:57 +0000
X-Inumbo-ID: d64de930-80cd-11ea-b58d-bc764e2007e4
Received: from mga17.intel.com (unknown [192.55.52.151])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d64de930-80cd-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 17:06:54 +0000 (UTC)
IronPort-SDR: QwXs3ZOvtr03zWg1LI4gt/cKOJyflZAtI72zUhIxQPc60szSp2/s5Wc9Wgktw92uFKWp3nULt1
 T7CYUDw3ohcQ==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga005.jf.intel.com ([10.7.209.41])
 by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Apr 2020 10:06:46 -0700
IronPort-SDR: 0pnPoF6TZ5mkNJeHiaWByldBGy4lChjaaP5R8cQhK3wb0xYPXUkEI5jcVw8xZK63msW54Bwu8u
 H9zcZVd9aYjA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,395,1580803200"; d="scan'208";a="428288186"
Received: from keclark-mobl.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.135.32.180])
 by orsmga005.jf.intel.com with ESMTP; 17 Apr 2020 10:06:44 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v15 2/3] mem_sharing: allow forking domain with IOMMU enabled
Date: Fri, 17 Apr 2020 10:06:32 -0700
Message-Id: <0be7501ace42d856b344828755ece18659dabd33.1587142844.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <cover.1587142844.git.tamas.lengyel@intel.com>
References: <cover.1587142844.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The memory sharing subsystem by default doesn't allow a domain to share memory
if it has an IOMMU active for obvious security reasons. However, when fuzzing a
VM fork, the same security restrictions don't necessarily apply. While it makes
no sense to try to create a full fork of a VM that has an IOMMU attached as only
one domain can own the pass-through device at a time, creating a shallow fork
without a device model is still very useful for fuzzing kernel-mode drivers.

By allowing the parent VM to initialize the kernel-mode driver with a real
device that's pass-through, the driver can enter into a state more suitable for
fuzzing. Some of these initialization steps are quite complex and are easier to
perform when a real device is present. After the initialization, shallow forks
can be utilized for fuzzing code-segments in the device driver that don't
directly interact with the device.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
 xen/arch/x86/mm/mem_sharing.c | 18 ++++++++++++------
 xen/include/public/memory.h   |  4 +++-
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 4b31a8b8f6..a5063d5992 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1430,7 +1430,8 @@ static int range_share(struct domain *d, struct domain *cd,
     return rc;
 }
 
-static inline int mem_sharing_control(struct domain *d, bool enable)
+static inline int mem_sharing_control(struct domain *d, bool enable,
+                                      bool allow_iommu)
 {
     if ( enable )
     {
@@ -1440,7 +1441,7 @@ static inline int mem_sharing_control(struct domain *d, bool enable)
         if ( unlikely(!hap_enabled(d)) )
             return -ENODEV;
 
-        if ( unlikely(is_iommu_enabled(d)) )
+        if (unlikely(!allow_iommu && is_iommu_enabled(d)) )
             return -EXDEV;
     }
 
@@ -1827,7 +1828,8 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
     if ( rc )
         goto out;
 
-    if ( !mem_sharing_enabled(d) && (rc = mem_sharing_control(d, true)) )
+    if ( !mem_sharing_enabled(d) &&
+         (rc = mem_sharing_control(d, true, false)) )
         return rc;
 
     switch ( mso.op )
@@ -2063,9 +2065,10 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
     case XENMEM_sharing_op_fork:
     {
         struct domain *pd;
+        bool allow_iommu;
 
         rc = -EINVAL;
-        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[2] )
+        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] )
             goto out;
 
         rc = rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_domain,
@@ -2080,7 +2083,10 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
             goto out;
         }
 
-        if ( !mem_sharing_enabled(pd) && (rc = mem_sharing_control(pd, true)) )
+        allow_iommu = mso.u.fork.flags & XENMEM_FORK_WITH_IOMMU_ALLOWED;
+
+        if ( !mem_sharing_enabled(pd) &&
+             (rc = mem_sharing_control(pd, true, allow_iommu)) )
         {
             rcu_unlock_domain(pd);
             goto out;
@@ -2138,7 +2144,7 @@ int mem_sharing_domctl(struct domain *d, struct xen_domctl_mem_sharing_op *mec)
     switch ( mec->op )
     {
     case XEN_DOMCTL_MEM_SHARING_CONTROL:
-        rc = mem_sharing_control(d, mec->u.enable);
+        rc = mem_sharing_control(d, mec->u.enable, false);
         break;
 
     default:
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index d36d64b8dc..1d2149def3 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -536,7 +536,9 @@ struct xen_mem_sharing_op {
         } debug;
         struct mem_sharing_op_fork {      /* OP_FORK */
             domid_t parent_domain;        /* IN: parent's domain id */
-            uint16_t pad[3];              /* Must be set to 0 */
+#define XENMEM_FORK_WITH_IOMMU_ALLOWED 1  /* Allow forking domain with IOMMU */
+            uint16_t flags;               /* IN: optional settings */
+            uint16_t pad[2];              /* Must be set to 0 */
         } fork;
     } u;
 };
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 17:07:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 17:07:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPUSH-0005yt-Pw; Fri, 17 Apr 2020 17:07:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=lvC5=6B=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jPUSG-0005yg-1Z
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 17:07:04 +0000
X-Inumbo-ID: d73290f8-80cd-11ea-8d58-12813bfff9fa
Received: from mga17.intel.com (unknown [192.55.52.151])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d73290f8-80cd-11ea-8d58-12813bfff9fa;
 Fri, 17 Apr 2020 17:06:55 +0000 (UTC)
IronPort-SDR: 5wKoKo0zsi21mK+IFH/YqNrBPSbYf/mjQ2qMNRxq4Lc+wMYRVkkQREPmYTraWDP7tvC/gxHLTq
 x5lvbIUrZ93w==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga005.jf.intel.com ([10.7.209.41])
 by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Apr 2020 10:06:46 -0700
IronPort-SDR: gNCsQVxUsh84c1MR7F0ukbC2h4fyODrZxCM28KtnaYBeAPSjyfY4hiwJ/XhY2ptHvlD/20pC8s
 S3Z2hVB3k0Tw==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,395,1580803200"; d="scan'208";a="428288194"
Received: from keclark-mobl.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.135.32.180])
 by orsmga005.jf.intel.com with ESMTP; 17 Apr 2020 10:06:46 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v15 3/3] xen/tools: VM forking toolstack side
Date: Fri, 17 Apr 2020 10:06:33 -0700
Message-Id: <7053228ba34b3e7a6ac62a527222f9cd04fbca67.1587142844.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <cover.1587142844.git.tamas.lengyel@intel.com>
References: <cover.1587142844.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
 docs/man/xl.1.pod.in          |  48 +++++
 tools/libxc/include/xenctrl.h |  14 ++
 tools/libxc/xc_memshr.c       |  26 +++
 tools/libxl/libxl.h           |  12 ++
 tools/libxl/libxl_create.c    | 361 +++++++++++++++++++---------------
 tools/libxl/libxl_dm.c        |   2 +-
 tools/libxl/libxl_dom.c       |  43 +++-
 tools/libxl/libxl_internal.h  |   7 +
 tools/libxl/libxl_types.idl   |   1 +
 tools/libxl/libxl_x86.c       |  42 ++++
 tools/xl/Makefile             |   2 +-
 tools/xl/xl.h                 |   5 +
 tools/xl/xl_cmdtable.c        |  16 ++
 tools/xl/xl_forkvm.c          | 157 +++++++++++++++
 tools/xl/xl_vmcontrol.c       |  14 ++
 15 files changed, 584 insertions(+), 166 deletions(-)
 create mode 100644 tools/xl/xl_forkvm.c

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 09339282e6..010d07b07b 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -708,6 +708,54 @@ above).
 
 =back
 
+=item B<fork-vm> [I<OPTIONS>] I<domain-id>
+
+Create a fork of a running VM.  The domain will be paused after the operation
+and remains paused while forks of it exist.  Experimental and x86 only.
+Forks can only be made of domains with HAP enabled and on Intel hardware.  The
+parent domain must be created with the xl toolstack and its configuration must
+not manually define max_grant_frames, max_maptrack_frames or max_event_channels.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-p>
+
+Leave the fork paused after creating it.
+
+=item B<--launch-dm>
+
+Specify whether the device model (QEMU) should be launched for the fork. Late
+launch allows to start the device model for an already running fork.
+
+=item B<-C>
+
+The config file to use when launching the device model.  Currently required when
+launching the device model.  Most config settings MUST match the parent domain
+exactly, only change VM name, disk path and network configurations.
+
+=item B<-Q>
+
+The path to the qemu save file to use when launching the device model.  Currently
+required when launching the device model.
+
+=item B<--fork-reset>
+
+Perform a reset operation of an already running fork.  Note that resetting may
+be less performant then creating a new fork depending on how much memory the
+fork has deduplicated during its runtime.
+
+=item B<--max-vcpus>
+
+Specify the max-vcpus matching the parent domain when not launching the dm.
+
+=item B<--allow-iommu>
+
+Allow working a domain with IOMMU attached. Only for forks created with --launch-dm no.
+
+=back
+
 =item B<sharing> [I<domain-id>]
 
 Display the number of shared pages for a specified domain. If no domain is
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 5f25c5a6d4..0a6ff93229 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2232,6 +2232,20 @@ int xc_memshr_range_share(xc_interface *xch,
                           uint64_t first_gfn,
                           uint64_t last_gfn);
 
+int xc_memshr_fork(xc_interface *xch,
+                   uint32_t source_domain,
+                   uint32_t client_domain,
+                   bool allow_with_iommu);
+
+/*
+ * Note: this function is only intended to be used on short-lived forks that
+ * haven't yet aquired a lot of memory. In case the fork has a lot of memory
+ * it is likely more performant to create a new fork with xc_memshr_fork.
+ *
+ * With VMs that have a lot of memory this call may block for a long time.
+ */
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain);
+
 /* Debug calls: return the number of pages referencing the shared frame backing
  * the input argument. Should be one or greater.
  *
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index 97e2e6a8d9..2300cc7075 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -239,6 +239,32 @@ int xc_memshr_debug_gref(xc_interface *xch,
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid,
+                   bool allow_with_iommu)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_fork;
+    mso.u.fork.parent_domain = pdomid;
+
+    if ( allow_with_iommu )
+        mso.u.fork.flags |= XENMEM_FORK_WITH_IOMMU_ALLOWED;
+
+    return xc_memshr_memop(xch, domid, &mso);
+}
+
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+    mso.op = XENMEM_sharing_op_fork_reset;
+
+    return xc_memshr_memop(xch, domid, &mso);
+}
+
 int xc_memshr_audit(xc_interface *xch)
 {
     xen_mem_sharing_op_t mso;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 71709dc585..d8da347d4e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2666,6 +2666,18 @@ int libxl_psr_get_hw_info(libxl_ctx *ctx, libxl_psr_feat_type type,
                           unsigned int lvl, unsigned int *nr,
                           libxl_psr_hw_info **info);
 void libxl_psr_hw_info_list_free(libxl_psr_hw_info *list, unsigned int nr);
+
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid,
+                         bool allow_with_iommu)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                uint32_t domid,
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 #endif
 
 /* misc */
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e7cb2dbc2b..5705b6e3a5 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -538,12 +538,12 @@ out:
     return ret;
 }
 
-int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
-                       libxl__domain_build_state *state,
-                       uint32_t *domid, bool soft_reset)
+static int libxl__domain_make_xs_entries(libxl__gc *gc, libxl_domain_config *d_config,
+                                         libxl__domain_build_state *state,
+                                         uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, rc, nb_vm;
+    int rc, nb_vm;
     const char *dom_type;
     char *uuid_string;
     char *dom_path, *vm_path, *libxl_path;
@@ -555,9 +555,6 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     /* convenience aliases */
     libxl_domain_create_info *info = &d_config->c_info;
-    libxl_domain_build_info *b_info = &d_config->b_info;
-
-    assert(soft_reset || *domid == INVALID_DOMID);
 
     uuid_string = libxl__uuid2string(gc, info->uuid);
     if (!uuid_string) {
@@ -565,137 +562,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         goto out;
     }
 
-    if (!soft_reset) {
-        struct xen_domctl_createdomain create = {
-            .ssidref = info->ssidref,
-            .max_vcpus = b_info->max_vcpus,
-            .max_evtchn_port = b_info->event_channels,
-            .max_grant_frames = b_info->max_grant_frames,
-            .max_maptrack_frames = b_info->max_maptrack_frames,
-        };
-
-        if (info->type != LIBXL_DOMAIN_TYPE_PV) {
-            create.flags |= XEN_DOMCTL_CDF_hvm;
-            create.flags |=
-                libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
-            create.flags |=
-                libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
-        }
-
-        assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
-        LOG(DETAIL, "passthrough: %s",
-            libxl_passthrough_to_string(info->passthrough));
-
-        if (info->passthrough != LIBXL_PASSTHROUGH_DISABLED)
-            create.flags |= XEN_DOMCTL_CDF_iommu;
-
-        if (info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT)
-            create.iommu_opts |= XEN_DOMCTL_IOMMU_no_sharept;
-
-        /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
-        libxl_uuid_copy(ctx, (libxl_uuid *)&create.handle, &info->uuid);
-
-        ret = libxl__arch_domain_prepare_config(gc, d_config, &create);
-        if (ret < 0) {
-            LOGED(ERROR, *domid, "fail to get domain config");
-            rc = ERROR_FAIL;
-            goto out;
-        }
-
-        for (;;) {
-            uint32_t local_domid;
-            bool recent;
-
-            if (info->domid == RANDOM_DOMID) {
-                uint16_t v;
-
-                ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
-                if (ret < 0)
-                    break;
-
-                v &= DOMID_MASK;
-                if (!libxl_domid_valid_guest(v))
-                    continue;
-
-                local_domid = v;
-            } else {
-                local_domid = info->domid; /* May not be valid */
-            }
-
-            ret = xc_domain_create(ctx->xch, &local_domid, &create);
-            if (ret < 0) {
-                /*
-                 * If we generated a random domid and creation failed
-                 * because that domid already exists then simply try
-                 * again.
-                 */
-                if (errno == EEXIST && info->domid == RANDOM_DOMID)
-                    continue;
-
-                LOGED(ERROR, local_domid, "domain creation fail");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /* A new domain now exists */
-            *domid = local_domid;
-
-            rc = libxl__is_domid_recent(gc, local_domid, &recent);
-            if (rc)
-                goto out;
-
-            /* The domid is not recent, so we're done */
-            if (!recent)
-                break;
-
-            /*
-             * If the domid was specified then there's no point in
-             * trying again.
-             */
-            if (libxl_domid_valid_guest(info->domid)) {
-                LOGED(ERROR, local_domid, "domain id recently used");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /*
-             * The domain is recent and so cannot be used. Clear domid
-             * here since, if xc_domain_destroy() fails below there is
-             * little point calling it again in the error path.
-             */
-            *domid = INVALID_DOMID;
-
-            ret = xc_domain_destroy(ctx->xch, local_domid);
-            if (ret < 0) {
-                LOGED(ERROR, local_domid, "domain destroy fail");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /* The domain was successfully destroyed, so we can try again */
-        }
-
-        rc = libxl__arch_domain_save_config(gc, d_config, state, &create);
-        if (rc < 0)
-            goto out;
-    }
-
-    /*
-     * If soft_reset is set the the domid will have been valid on entry.
-     * If it was not set then xc_domain_create() should have assigned a
-     * valid value. Either way, if we reach this point, domid should be
-     * valid.
-     */
-    assert(libxl_domid_valid_guest(*domid));
-
-    ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
-    if (ret < 0) {
-        LOGED(ERROR, *domid, "domain move fail");
-        rc = ERROR_FAIL;
-        goto out;
-    }
-
-    dom_path = libxl__xs_get_dompath(gc, *domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         rc = ERROR_FAIL;
         goto out;
@@ -703,12 +570,12 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     vm_path = GCSPRINTF("/vm/%s", uuid_string);
     if (!vm_path) {
-        LOGD(ERROR, *domid, "cannot allocate create paths");
+        LOGD(ERROR, domid, "cannot allocate create paths");
         rc = ERROR_FAIL;
         goto out;
     }
 
-    libxl_path = libxl__xs_libxl_path(gc, *domid);
+    libxl_path = libxl__xs_libxl_path(gc, domid);
     if (!libxl_path) {
         rc = ERROR_FAIL;
         goto out;
@@ -719,10 +586,10 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     roperm[0].id = 0;
     roperm[0].perms = XS_PERM_NONE;
-    roperm[1].id = *domid;
+    roperm[1].id = domid;
     roperm[1].perms = XS_PERM_READ;
 
-    rwperm[0].id = *domid;
+    rwperm[0].id = domid;
     rwperm[0].perms = XS_PERM_NONE;
 
 retry_transaction:
@@ -740,7 +607,7 @@ retry_transaction:
                     noperm, ARRAY_SIZE(noperm));
 
     xs_write(ctx->xsh, t, GCSPRINTF("%s/vm", dom_path), vm_path, strlen(vm_path));
-    rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
+    rc = libxl__domain_rename(gc, domid, 0, info->name, t);
     if (rc)
         goto out;
 
@@ -830,7 +697,7 @@ retry_transaction:
 
     vm_list = libxl_list_vm(ctx, &nb_vm);
     if (!vm_list) {
-        LOGD(ERROR, *domid, "cannot get number of running guests");
+        LOGD(ERROR, domid, "cannot get number of running guests");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -854,7 +721,7 @@ retry_transaction:
             t = 0;
             goto retry_transaction;
         }
-        LOGED(ERROR, *domid, "domain creation ""xenstore transaction commit failed");
+        LOGED(ERROR, domid, "domain creation ""xenstore transaction commit failed");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -866,6 +733,155 @@ retry_transaction:
     return rc;
 }
 
+int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
+                       libxl__domain_build_state *state,
+                       uint32_t *domid, bool soft_reset)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret, rc;
+
+    /* convenience aliases */
+    libxl_domain_create_info *info = &d_config->c_info;
+    libxl_domain_build_info *b_info = &d_config->b_info;
+
+    assert(soft_reset || *domid == INVALID_DOMID);
+
+    if (!soft_reset) {
+        struct xen_domctl_createdomain create = {
+            .ssidref = info->ssidref,
+            .max_vcpus = b_info->max_vcpus,
+            .max_evtchn_port = b_info->event_channels,
+            .max_grant_frames = b_info->max_grant_frames,
+            .max_maptrack_frames = b_info->max_maptrack_frames,
+        };
+
+        if (info->type != LIBXL_DOMAIN_TYPE_PV) {
+            create.flags |= XEN_DOMCTL_CDF_hvm;
+            create.flags |=
+                libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+            create.flags |=
+                libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
+        }
+
+        assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
+        LOG(DETAIL, "passthrough: %s",
+            libxl_passthrough_to_string(info->passthrough));
+
+        if (info->passthrough != LIBXL_PASSTHROUGH_DISABLED)
+            create.flags |= XEN_DOMCTL_CDF_iommu;
+
+        if (info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT)
+            create.iommu_opts |= XEN_DOMCTL_IOMMU_no_sharept;
+
+        /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
+        libxl_uuid_copy(ctx, (libxl_uuid *)&create.handle, &info->uuid);
+
+        ret = libxl__arch_domain_prepare_config(gc, d_config, &create);
+        if (ret < 0) {
+            LOGED(ERROR, *domid, "fail to get domain config");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        for (;;) {
+            uint32_t local_domid;
+            bool recent;
+
+            if (info->domid == RANDOM_DOMID) {
+                uint16_t v;
+
+                ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
+                if (ret < 0)
+                    break;
+
+                v &= DOMID_MASK;
+                if (!libxl_domid_valid_guest(v))
+                    continue;
+
+                local_domid = v;
+            } else {
+                local_domid = info->domid; /* May not be valid */
+            }
+
+            ret = xc_domain_create(ctx->xch, &local_domid, &create);
+            if (ret < 0) {
+                /*
+                 * If we generated a random domid and creation failed
+                 * because that domid already exists then simply try
+                 * again.
+                 */
+                if (errno == EEXIST && info->domid == RANDOM_DOMID)
+                    continue;
+
+                LOGED(ERROR, local_domid, "domain creation fail");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* A new domain now exists */
+            *domid = local_domid;
+
+            rc = libxl__is_domid_recent(gc, local_domid, &recent);
+            if (rc)
+                goto out;
+
+            /* The domid is not recent, so we're done */
+            if (!recent)
+                break;
+
+            /*
+             * If the domid was specified then there's no point in
+             * trying again.
+             */
+            if (libxl_domid_valid_guest(info->domid)) {
+                LOGED(ERROR, local_domid, "domain id recently used");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /*
+             * The domain is recent and so cannot be used. Clear domid
+             * here since, if xc_domain_destroy() fails below there is
+             * little point calling it again in the error path.
+             */
+            *domid = INVALID_DOMID;
+
+            ret = xc_domain_destroy(ctx->xch, local_domid);
+            if (ret < 0) {
+                LOGED(ERROR, local_domid, "domain destroy fail");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* The domain was successfully destroyed, so we can try again */
+        }
+
+        rc = libxl__arch_domain_save_config(gc, d_config, state, &create);
+        if (rc < 0)
+            goto out;
+    }
+
+    /*
+     * If soft_reset is set the the domid will have been valid on entry.
+     * If it was not set then xc_domain_create() should have assigned a
+     * valid value. Either way, if we reach this point, domid should be
+     * valid.
+     */
+    assert(libxl_domid_valid_guest(*domid));
+
+    ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
+    if (ret < 0) {
+        LOGED(ERROR, *domid, "domain move fail");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl__domain_make_xs_entries(gc, d_config, state, *domid);
+
+out:
+    return rc;
+}
+
 static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
                              libxl_domain_build_info *b_info)
 {
@@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
     ret = libxl__domain_config_setdefault(gc,d_config,domid);
     if (ret) goto error_out;
 
-    ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
-                             dcs->soft_reset);
-    if (ret) {
-        LOGD(ERROR, domid, "cannot make domain: %d", ret);
+    if ( !d_config->dm_restore_file )
+    {
+        ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
+                                 dcs->soft_reset);
         dcs->guest_domid = domid;
+
+        if (ret) {
+            LOGD(ERROR, domid, "cannot make domain: %d", ret);
+            ret = ERROR_FAIL;
+            goto error_out;
+        }
+    } else if ( dcs->guest_domid != INVALID_DOMID ) {
+        domid = dcs->guest_domid;
+
+        ret = libxl__domain_make_xs_entries(gc, d_config, &dcs->build_state, domid);
+        if (ret) {
+            LOGD(ERROR, domid, "cannot make domain: %d", ret);
+            ret = ERROR_FAIL;
+            goto error_out;
+        }
+    } else {
+        LOGD(ERROR, domid, "cannot make domain");
         ret = ERROR_FAIL;
         goto error_out;
     }
 
-    dcs->guest_domid = domid;
     dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
 
     /* post-4.13 todo: move these next bits of defaulting to
@@ -1236,7 +1268,7 @@ static void initiate_domain_create(libxl__egc *egc,
     if (ret)
         goto error_out;
 
-    if (restore_fd >= 0 || dcs->soft_reset) {
+    if (restore_fd >= 0 || dcs->soft_reset || d_config->dm_restore_file) {
         LOGD(DEBUG, domid, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
     } else  {
@@ -1312,7 +1344,16 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->sdss.dm.callback = domcreate_devmodel_started;
     dcs->sdss.callback = domcreate_devmodel_started;
 
-    if (restore_fd < 0 && !dcs->soft_reset) {
+    if (restore_fd < 0 && !dcs->soft_reset && !d_config->dm_restore_file) {
+        rc = libxl__domain_build(gc, d_config, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    if ( d_config->dm_restore_file ) {
+        dcs->srs.dcs = dcs;
+        dcs->srs.ao = ao;
+        state->forked_vm = true;
         rc = libxl__domain_build(gc, d_config, domid, state);
         domcreate_rebuild_done(egc, dcs, rc);
         return;
@@ -1510,6 +1551,7 @@ static void domcreate_rebuild_done(libxl__egc *egc,
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
 
     if (ret) {
         LOGD(ERROR, domid, "cannot (re-)build domain: %d", ret);
@@ -1517,6 +1559,9 @@ static void domcreate_rebuild_done(libxl__egc *egc,
         goto error_out;
     }
 
+    if ( d_config->dm_restore_file )
+        state->saved_state = GCSPRINTF("%s", d_config->dm_restore_file);
+
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     libxl__multidev_begin(ao, &dcs->multidev);
@@ -1947,7 +1992,7 @@ static void domain_create_cb(libxl__egc *egc,
                              libxl__domain_create_state *dcs,
                              int rc, uint32_t domid);
 
-static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+int libxl__do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid, int restore_fd, int send_back_fd,
                             const libxl_domain_restore_params *params,
                             const libxl_asyncop_how *ao_how,
@@ -1960,6 +2005,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     GCNEW(cdcs);
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.guest_domid = *domid;
+
     libxl_domain_config_init(&cdcs->dcs.guest_config_saved);
     libxl_domain_config_copy(ctx, &cdcs->dcs.guest_config_saved, d_config);
     cdcs->dcs.restore_fd = cdcs->dcs.libxc_fd = restore_fd;
@@ -2204,8 +2251,8 @@ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             const libxl_asyncprogress_how *aop_console_how)
 {
     unset_disk_colo_restore(d_config);
-    return do_domain_create(ctx, d_config, domid, -1, -1, NULL,
-                            ao_how, aop_console_how);
+    return libxl__do_domain_create(ctx, d_config, domid, -1, -1, NULL,
+                                  ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
@@ -2221,8 +2268,8 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
         unset_disk_colo_restore(d_config);
     }
 
-    return do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
-                            params, ao_how, aop_console_how);
+    return libxl__do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
+                                   params, ao_how, aop_console_how);
 }
 
 int libxl_domain_soft_reset(libxl_ctx *ctx,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index f4007bbe50..b615f1fc88 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2803,7 +2803,7 @@ static void device_model_spawn_outcome(libxl__egc *egc,
 
     libxl__domain_build_state *state = dmss->build_state;
 
-    if (state->saved_state) {
+    if (state->saved_state && !state->forked_vm) {
         ret2 = unlink(state->saved_state);
         if (ret2) {
             LOGED(ERROR, dmss->guest_domid, "%s: failed to remove device-model state %s",
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 71cb578923..3bc7117b99 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -249,9 +249,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *xs_domid, *con_domid;
-    int rc;
+    int rc = 0;
     uint64_t size;
 
+    if ( state->forked_vm )
+        goto skip_fork;
+
     if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) {
         LOG(ERROR, "Couldn't set max vcpu count");
         return ERROR_FAIL;
@@ -362,7 +365,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         }
     }
 
-
     rc = libxl__arch_extra_memory(gc, info, &size);
     if (rc < 0) {
         LOGE(ERROR, "Couldn't get arch extra constant memory size");
@@ -374,6 +376,11 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         return ERROR_FAIL;
     }
 
+    rc = libxl__arch_domain_create(gc, d_config, domid);
+    if ( rc )
+        goto out;
+
+skip_fork:
     xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
     state->store_domid = xs_domid ? atoi(xs_domid) : 0;
     free(xs_domid);
@@ -385,8 +392,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
 
-    rc = libxl__arch_domain_create(gc, d_config, domid);
-
+out:
     return rc;
 }
 
@@ -444,6 +450,9 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char **ents;
     int i, rc;
 
+    if ( state->forked_vm )
+        goto skip_fork;
+
     if (info->num_vnuma_nodes && !info->num_vcpu_soft_affinity) {
         rc = set_vnuma_affinity(gc, domid, info);
         if (rc)
@@ -466,6 +475,7 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
         }
     }
 
+skip_fork:
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
@@ -728,14 +738,16 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
                                 int console_evtchn, unsigned long *console_mfn,
-                                domid_t store_domid, domid_t console_domid)
+                                domid_t store_domid, domid_t console_domid,
+                                bool forked_vm)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
     uint64_t str_mfn, cons_mfn;
     int i;
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if ( info->type == LIBXL_DOMAIN_TYPE_HVM && !forked_vm )
+    {
         va_map = xc_map_foreign_range(handle, domid,
                                       XC_PAGE_SIZE, PROT_READ | PROT_WRITE,
                                       HVM_INFO_PFN);
@@ -1051,6 +1063,23 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
     struct xc_dom_image *dom = NULL;
     bool device_model = info->type == LIBXL_DOMAIN_TYPE_HVM ? true : false;
 
+    if ( state->forked_vm )
+    {
+        rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
+                                  &state->store_mfn, state->console_port,
+                                  &state->console_mfn, state->store_domid,
+                                  state->console_domid, state->forked_vm);
+
+        if ( rc )
+            return rc;
+
+        return xc_dom_gnttab_seed(ctx->xch, domid, true,
+                                  state->console_mfn,
+                                  state->store_mfn,
+                                  state->console_domid,
+                                  state->store_domid);
+    }
+
     xc_dom_loginit(ctx->xch);
 
     /*
@@ -1175,7 +1204,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
     rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
                                &state->store_mfn, state->console_port,
                                &state->console_mfn, state->store_domid,
-                               state->console_domid);
+                               state->console_domid, false);
     if (rc != 0) {
         LOG(ERROR, "hvm build set params failed");
         goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5f39e44cb9..d05ff31e83 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1374,6 +1374,7 @@ typedef struct {
 
     char *saved_state;
     int dm_monitor_fd;
+    bool forked_vm;
 
     libxl__file_reference pv_kernel;
     libxl__file_reference pv_ramdisk;
@@ -4818,6 +4819,12 @@ _hidden int libxl__domain_pvcontrol(libxl__egc *egc,
 /* Check whether a domid is recent */
 int libxl__is_domid_recent(libxl__gc *gc, uint32_t domid, bool *recent);
 
+_hidden int libxl__do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                    uint32_t *domid, int restore_fd, int send_back_fd,
+                                    const libxl_domain_restore_params *params,
+                                    const libxl_asyncop_how *ao_how,
+                                    const libxl_asyncprogress_how *aop_console_how);
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7c473be74..2bb5e6319e 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -958,6 +958,7 @@ libxl_domain_config = Struct("domain_config", [
     ("on_watchdog", libxl_action_on_shutdown),
     ("on_crash", libxl_action_on_shutdown),
     ("on_soft_reset", libxl_action_on_shutdown),
+    ("dm_restore_file", string, {'const': True}),
     ], dir=DIR_IN)
 
 libxl_diskinfo = Struct("diskinfo", [
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index f8bc828e62..7a0bd62fa7 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -2,6 +2,7 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
+#include <xen-xsm/flask/flask.h>
 
 int libxl__arch_domain_prepare_config(libxl__gc *gc,
                                       libxl_domain_config *d_config,
@@ -842,6 +843,47 @@ int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
     return rc;
 }
 
+/*
+ * The parent domain is expected to be created with default settings for
+ * - max_evtch_port
+ * - max_grant_frames
+ * - max_maptrack_frames
+ */
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid,
+                         bool allow_with_iommu)
+{
+    int rc;
+    struct xen_domctl_createdomain create = {0};
+    create.flags |= XEN_DOMCTL_CDF_hvm;
+    create.flags |= XEN_DOMCTL_CDF_hap;
+    create.flags |= XEN_DOMCTL_CDF_oos_off;
+    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
+    create.ssidref = SECINITSID_DOMU;
+    create.max_vcpus = max_vcpus;
+    create.max_evtchn_port = 1023;
+    create.max_grant_frames = LIBXL_MAX_GRANT_FRAMES_DEFAULT;
+    create.max_maptrack_frames = LIBXL_MAX_MAPTRACK_FRAMES_DEFAULT;
+
+    if ( (rc = xc_domain_create(ctx->xch, domid, &create)) )
+        return rc;
+
+    if ( (rc = xc_memshr_fork(ctx->xch, pdomid, *domid, allow_with_iommu)) )
+        xc_domain_destroy(ctx->xch, *domid);
+
+    return rc;
+}
+
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                uint32_t domid,
+                                const libxl_asyncprogress_how *aop_console_how)
+{
+    return libxl__do_domain_create(ctx, d_config, &domid, -1, -1, 0, 0, aop_console_how);
+}
+
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid)
+{
+    return xc_memshr_fork_reset(ctx->xch, domid);
+}
 
 /*
  * Local variables:
diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index af4912e67a..073222233b 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -15,7 +15,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
 CFLAGS_XL += $(CFLAGS_libxenlight)
 CFLAGS_XL += -Wshadow
 
-XL_OBJS-$(CONFIG_X86) = xl_psr.o
+XL_OBJS-$(CONFIG_X86) = xl_psr.o xl_forkvm.o
 XL_OBJS = xl.o xl_cmdtable.o xl_sxp.o xl_utils.o $(XL_OBJS-y)
 XL_OBJS += xl_parse.o xl_cpupool.o xl_flask.o
 XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 06569c6c4a..1105c34b15 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -31,6 +31,7 @@ struct cmd_spec {
 };
 
 struct domain_create {
+    uint32_t ddomid; /* fork launch dm for this domid */
     int debug;
     int daemonize;
     int monitor; /* handle guest reboots etc */
@@ -45,6 +46,7 @@ struct domain_create {
     const char *config_file;
     char *extra_config; /* extra config string */
     const char *restore_file;
+    const char *dm_restore_file;
     char *colo_proxy_script;
     bool userspace_colo_proxy;
     int migrate_fd; /* -1 means none */
@@ -128,6 +130,8 @@ int main_pciassignable_remove(int argc, char **argv);
 int main_pciassignable_list(int argc, char **argv);
 #ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
 int main_restore(int argc, char **argv);
+int main_fork_launch_dm(int argc, char **argv);
+int main_fork_reset(int argc, char **argv);
 int main_migrate_receive(int argc, char **argv);
 int main_save(int argc, char **argv);
 int main_migrate(int argc, char **argv);
@@ -212,6 +216,7 @@ int main_psr_cat_cbm_set(int argc, char **argv);
 int main_psr_cat_show(int argc, char **argv);
 int main_psr_mba_set(int argc, char **argv);
 int main_psr_mba_show(int argc, char **argv);
+int main_fork_vm(int argc, char **argv);
 #endif
 int main_qemu_monitor_command(int argc, char **argv);
 
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 08335394e5..e5d2097c2b 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -187,6 +187,22 @@ struct cmd_spec cmd_table[] = {
       "Restore a domain from a saved state",
       "- for internal use only",
     },
+#if defined(__i386__) || defined(__x86_64__)
+    { "fork-vm",
+      &main_fork_vm, 0, 1,
+      "Fork a domain from the running parent domid. Experimental. Most config settings must match parent.",
+      "[options] <Domid>",
+      "-h                           Print this help.\n"
+      "-C <config>                  Use config file for VM fork.\n"
+      "-Q <qemu-save-file>          Use qemu save file for VM fork.\n"
+      "--launch-dm <yes|no|late>    Launch device model (QEMU) for VM fork.\n"
+      "--fork-reset                 Reset VM fork.\n"
+      "--max-vcpus                  Specify max-vcpus matching the parent domain when not launching dm\n"
+      "--allow-iommu                Allow forking a domain with IOMMU attached (only with --launch-dm no)\n"
+      "-p                           Do not unpause fork VM after operation.\n"
+      "-d                           Enable debug messages.\n"
+    },
+#endif
 #endif
     { "dump-core",
       &main_dump_core, 0, 1,
diff --git a/tools/xl/xl_forkvm.c b/tools/xl/xl_forkvm.c
new file mode 100644
index 0000000000..8ff1a59d3f
--- /dev/null
+++ b/tools/xl/xl_forkvm.c
@@ -0,0 +1,157 @@
+/*
+ * Copyright 2020 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <sys/utsname.h>
+#include <time.h>
+#include <unistd.h>
+
+#include <libxl.h>
+#include <libxl_utils.h>
+#include <libxlutil.h>
+
+#include "xl.h"
+#include "xl_utils.h"
+#include "xl_parse.h"
+
+int main_fork_vm(int argc, char **argv)
+{
+    int rc, debug = 0;
+    uint32_t domid_in = INVALID_DOMID, domid_out = INVALID_DOMID;
+    int launch_dm = 1;
+    bool reset = 0;
+    bool pause = 0;
+    bool allow_iommu = 0;
+    const char *config_file = NULL;
+    const char *dm_restore_file = NULL;
+    uint32_t max_vcpus = 0;
+
+    int opt;
+    static struct option opts[] = {
+        {"launch-dm", 1, 0, 'l'},
+        {"fork-reset", 0, 0, 'r'},
+        {"max-vcpus", 1, 0, 'm'},
+        {"allow-iommu", 1, 0, 'i'},
+        COMMON_LONG_OPTS
+    };
+
+    SWITCH_FOREACH_OPT(opt, "phdC:Q:l:rm:i", opts, "fork-vm", 1) {
+    case 'd':
+        debug = 1;
+        break;
+    case 'p':
+        pause = 1;
+        break;
+    case 'm':
+        max_vcpus = atoi(optarg);
+        break;
+    case 'C':
+        config_file = optarg;
+        break;
+    case 'Q':
+        dm_restore_file = optarg;
+        break;
+    case 'l':
+        if ( !strcmp(optarg, "no") )
+            launch_dm = 0;
+        if ( !strcmp(optarg, "yes") )
+            launch_dm = 1;
+        if ( !strcmp(optarg, "late") )
+            launch_dm = 2;
+        break;
+    case 'r':
+        reset = 1;
+        break;
+    case 'i':
+        allow_iommu = 1;
+        break;
+    default:
+        fprintf(stderr, "Unimplemented option(s)\n");
+        return EXIT_FAILURE;
+    }
+
+    if (argc-optind == 1) {
+        domid_in = atoi(argv[optind]);
+    } else {
+        help("fork-vm");
+        return EXIT_FAILURE;
+    }
+
+    if (launch_dm)
+    {
+        if (!config_file || !dm_restore_file) {
+            fprintf(stderr, "Currently you must provide both -C and -Q options\n");
+            return EXIT_FAILURE;
+        }
+
+        if (allow_iommu) {
+            fprintf(stderr, "Forking a domain with an IOMMU is only possible with --launch-dm no\n");
+            return EXIT_FAILURE;
+        }
+    }
+
+    if (reset) {
+        domid_out = domid_in;
+        if (libxl_domain_fork_reset(ctx, domid_in) == EXIT_FAILURE)
+            return EXIT_FAILURE;
+    }
+
+    if (launch_dm == 2 || reset) {
+        domid_out = domid_in;
+        rc = EXIT_SUCCESS;
+    } else {
+        if ( !max_vcpus )
+        {
+            fprintf(stderr, "Currently you must parent's max_vcpu for this option\n");
+            return EXIT_FAILURE;
+        }
+
+        rc = libxl_domain_fork_vm(ctx, domid_in, max_vcpus, &domid_out, allow_iommu);
+    }
+
+    if (rc == EXIT_SUCCESS) {
+        if ( launch_dm ) {
+            struct domain_create dom_info;
+            memset(&dom_info, 0, sizeof(dom_info));
+            dom_info.ddomid = domid_out;
+            dom_info.dm_restore_file = dm_restore_file;
+            dom_info.debug = debug;
+            dom_info.paused = pause;
+            dom_info.config_file = config_file;
+            dom_info.migrate_fd = -1;
+            dom_info.send_back_fd = -1;
+            rc = create_domain(&dom_info) < 0 ? EXIT_FAILURE : EXIT_SUCCESS;
+        } else if ( !pause )
+            rc = libxl_domain_unpause(ctx, domid_out, NULL);
+    }
+
+    if (rc == EXIT_SUCCESS)
+        fprintf(stderr, "fork-vm command successfully returned domid: %u\n", domid_out);
+    else if ( domid_out != INVALID_DOMID )
+        libxl_domain_destroy(ctx, domid_out, 0);
+
+    return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 17b4514c94..c64123d0a1 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -676,6 +676,12 @@ int create_domain(struct domain_create *dom_info)
 
     int restoring = (restore_file || (migrate_fd >= 0));
 
+#if defined(__i386__) || defined(__x86_64__)
+    /* VM forking */
+    uint32_t ddomid = dom_info->ddomid; // launch dm for this domain iff set
+    const char *dm_restore_file = dom_info->dm_restore_file;
+#endif
+
     libxl_domain_config_init(&d_config);
 
     if (restoring) {
@@ -928,6 +934,14 @@ start:
          * restore/migrate-receive it again.
          */
         restoring = 0;
+#if defined(__i386__) || defined(__x86_64__)
+    } else if ( ddomid ) {
+        d_config.dm_restore_file = dm_restore_file;
+        ret = libxl_domain_fork_launch_dm(ctx, &d_config, ddomid,
+                                          autoconnect_console_how);
+        domid = ddomid;
+        ddomid = INVALID_DOMID;
+#endif
     } else if (domid_soft_reset != INVALID_DOMID) {
         /* Do soft reset. */
         ret = libxl_domain_soft_reset(ctx, &d_config, domid_soft_reset,
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 17:07:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 17:07:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPUS7-0005xn-TJ; Fri, 17 Apr 2020 17:06:55 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=lvC5=6B=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jPUS6-0005xi-3k
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 17:06:54 +0000
X-Inumbo-ID: d47239ea-80cd-11ea-8d58-12813bfff9fa
Received: from mga17.intel.com (unknown [192.55.52.151])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d47239ea-80cd-11ea-8d58-12813bfff9fa;
 Fri, 17 Apr 2020 17:06:51 +0000 (UTC)
IronPort-SDR: uAqTuY2qtf3n3mYcmOcg+siN8cEI9Pma4TpXewMywKgH+ZgCwvOAPt0Xb16Kv7TTzvJbBAruJD
 bxPLhqSC49Iw==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga005.jf.intel.com ([10.7.209.41])
 by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Apr 2020 10:06:44 -0700
IronPort-SDR: Hxljqv/S0DfA+K2ftb5Z32yh7sP3CD+PD7XvcRzVija6oON3r7toBlBuRSwlQfH5ZCW9VbW8Ot
 JC0UIYCBE6KQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,395,1580803200"; d="scan'208";a="428288160"
Received: from keclark-mobl.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.135.32.180])
 by orsmga005.jf.intel.com with ESMTP; 17 Apr 2020 10:06:41 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v15 0/3] VM forking
Date: Fri, 17 Apr 2020 10:06:30 -0700
Message-Id: <cover.1587141409.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The following patches are part of the series that implement VM forking for
Intel HVM guests to allow for the fast creation of identical VMs without the
assosciated high startup costs of booting or restoring the VM from a savefile.

JIRA issue: https://xenproject.atlassian.net/browse/XEN-89

The fork operation is implemented as part of the "xl fork-vm" command:
    xl fork-vm -C <config> -Q <qemu-save-file> -m <max-vcpus> <parent_domid>
    
By default a fully functional fork is created. The user is in charge however to
create the appropriate config file for the fork and to generate the QEMU save
file before the fork-vm call is made. The config file needs to give the
fork a new name at minimum but other settings may also require changes. Certain
settings in the config file of both the parent and the fork have to be set to
default. Details are documented.

The interface also allows to split the forking into two steps:
    xl fork-vm --launch-dm no \
               -m <max-vcpus> \
               -p <parent_domid>
    xl fork-vm --launch-dm late \
               -C <config_file_for_fork> \
               -Q <qemu_save_file> \
               <fork_domid>

The split creation model is useful when the VM needs to be created as fast as
possible. The forked VM can be unpaused without the device model being launched
to be monitored and accessed via VMI. Note however that without its device
model running (depending on what is executing in the VM) it is bound to
misbehave or even crash when its trying to access devices that would be
emulated by QEMU. We anticipate that for certain use-cases this would be an
acceptable situation, in case for example when fuzzing is performed of code
segments that don't access such devices.

Launching the device model requires the QEMU Xen savefile to be generated
manually from the parent VM. This can be accomplished simply by connecting to
its QMP socket and issuing the "xen-save-devices-state" command. For example
using the standard tool socat these commands can be used to generate the file:
    socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-<parent_domid>
    { "execute": "qmp_capabilities" }
    { "execute": "xen-save-devices-state", \
        "arguments": { "filename": "/path/to/save/qemu_state", \
                        "live": false} }

At runtime the forked VM starts running with an empty p2m which gets lazily
populated when the VM generates EPT faults, similar to how altp2m views are
populated. If the memory access is a read-only access, the p2m entry is
populated with a memory shared entry with its parent. For write memory accesses
or in case memory sharing wasn't possible (for example in case a reference is
held by a third party), a new page is allocated and the page contents are
copied over from the parent VM. Forks can be further forked if needed, thus
allowing for further memory savings.

A VM fork reset hypercall is also added that allows the fork to be reset to the
state it was just after a fork, also accessible via xl:
    xl fork-vm --fork-reset -p <fork_domid>

This is an optimization for cases where the forks are very short-lived and run
without a device model, so resetting saves some time compared to creating a
brand new fork provided the fork has not aquired a lot of memory. If the fork
has a lot of memory deduplicated it is likely going to be faster to create a
new fork from scratch and asynchronously destroying the old one.

The series has been tested with Windows VMs and functions as expected. Linux
VMs when forked from a running VM will have a frozen VNC screen. Linux VMs at
this time can only be forked with a working device model when the parent VM was
restored from a snapshot using "xl restore -p". This is a known limitation.
Also note that PVHVM/PVH Linux guests have not been tested. Forking most likely
works but PV devices and drivers would require additional wiring to set things
up properly since the guests are unaware of the forking taking place, unlike
the save/restore routine where the guest is made aware of the procedure.

Forking time has been measured to be 0.0007s, device model launch to be around
1s depending largely on the number of devices being emulated. Fork resets have
been measured to be 0.0001s under the optimal circumstances.

New in v15:
    Bugfix for fork reset with vm_events active
    Allowing forking a domain with IOMMU active

Patch 1 fix for VM fork reset dropping vm_events
Patch 2 adds option to fork a domain with IOMMU active
Patch 3 adds the toolstack-side code implementing VM forking and reset

Tamas K Lengyel (3):
  mem_sharing: don't reset vCPU info page during fork reset
  mem_sharing: allow forking domain with IOMMU enabled
  xen/tools: VM forking toolstack side

 docs/man/xl.1.pod.in          |  44 +++++
 tools/libxc/include/xenctrl.h |  14 ++
 tools/libxc/xc_memshr.c       |  26 +++
 tools/libxl/libxl.h           |  12 ++
 tools/libxl/libxl_create.c    | 361 +++++++++++++++++++---------------
 tools/libxl/libxl_dm.c        |   2 +-
 tools/libxl/libxl_dom.c       |  43 +++-
 tools/libxl/libxl_internal.h  |   7 +
 tools/libxl/libxl_types.idl   |   1 +
 tools/libxl/libxl_x86.c       |  42 ++++
 tools/xl/Makefile             |   2 +-
 tools/xl/xl.h                 |   5 +
 tools/xl/xl_cmdtable.c        |  15 ++
 tools/xl/xl_forkvm.c          | 149 ++++++++++++++
 tools/xl/xl_vmcontrol.c       |  14 ++
 xen/arch/x86/mm/mem_sharing.c |  68 ++++---
 xen/include/public/memory.h   |   4 +-
 17 files changed, 611 insertions(+), 198 deletions(-)
 create mode 100644 tools/xl/xl_forkvm.c

-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 17:07:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 17:07:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPUSC-0005yM-GG; Fri, 17 Apr 2020 17:07:00 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=lvC5=6B=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jPUSB-0005yB-14
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 17:06:59 +0000
X-Inumbo-ID: d5e6bc9d-80cd-11ea-8d58-12813bfff9fa
Received: from mga17.intel.com (unknown [192.55.52.151])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d5e6bc9d-80cd-11ea-8d58-12813bfff9fa;
 Fri, 17 Apr 2020 17:06:54 +0000 (UTC)
IronPort-SDR: UMpcsIwibaTSXgcNQgExkE8c7VJKrwZKPlmW0yzIAbo/i7tfHgiD0EHiGL5LdaWiISKFclx1N+
 x0FuSHOMlnyg==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga005.jf.intel.com ([10.7.209.41])
 by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Apr 2020 10:06:44 -0700
IronPort-SDR: yD0rH/H3MEyzfzqevgp6lFsmboi4nihchuwQrtdF08TfAwXXWc/XvKNZ1EMZp0hjD+KiL0Hj9x
 4AvQNsAoAa8g==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,395,1580803200"; d="scan'208";a="428288173"
Received: from keclark-mobl.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.135.32.180])
 by orsmga005.jf.intel.com with ESMTP; 17 Apr 2020 10:06:43 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v15 1/3] mem_sharing: don't reset vCPU info page during fork
 reset
Date: Fri, 17 Apr 2020 10:06:31 -0700
Message-Id: <ef0f91fd4c49c623dda09a1774392d2f2a99ae35.1587142844.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <cover.1587142844.git.tamas.lengyel@intel.com>
References: <cover.1587142844.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

When a forked VM is being reset while having vm_events active, re-copying the
vCPU info page can lead to events being lost. This seems to only affect a
subset of events (interrupts), while not others (cpuid, MTF, EPT) thus it was
not discovered beforehand. Only copying vCPU info page contents during initial
fork fixes the problem.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
 xen/arch/x86/mm/mem_sharing.c | 50 +++++++++++++++++------------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index e572e9e39d..4b31a8b8f6 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1534,28 +1534,6 @@ int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
                           p2m->default_access, -1);
 }
 
-static int bring_up_vcpus(struct domain *cd, struct domain *d)
-{
-    unsigned int i;
-    int ret = -EINVAL;
-
-    if ( d->max_vcpus != cd->max_vcpus ||
-        (ret = cpupool_move_domain(cd, d->cpupool)) )
-        return ret;
-
-    for ( i = 0; i < cd->max_vcpus; i++ )
-    {
-        if ( !d->vcpu[i] || cd->vcpu[i] )
-            continue;
-
-        if ( !vcpu_create(cd, i) )
-            return -EINVAL;
-    }
-
-    domain_update_node_affinity(cd);
-    return 0;
-}
-
 static int copy_vcpu_settings(struct domain *cd, const struct domain *d)
 {
     unsigned int i;
@@ -1614,6 +1592,31 @@ static int copy_vcpu_settings(struct domain *cd, const struct domain *d)
     return 0;
 }
 
+static int bring_up_vcpus(struct domain *cd, struct domain *d)
+{
+    unsigned int i;
+    int ret = -EINVAL;
+
+    if ( d->max_vcpus != cd->max_vcpus ||
+        (ret = cpupool_move_domain(cd, d->cpupool)) )
+        return ret;
+
+    for ( i = 0; i < cd->max_vcpus; i++ )
+    {
+        if ( !d->vcpu[i] || cd->vcpu[i] )
+            continue;
+
+        if ( !vcpu_create(cd, i) )
+            return -EINVAL;
+    }
+
+    if ( (ret = copy_vcpu_settings(cd, d)) )
+        return ret;
+
+    domain_update_node_affinity(cd);
+    return 0;
+}
+
 static int fork_hap_allocation(struct domain *cd, struct domain *d)
 {
     int rc;
@@ -1697,9 +1700,6 @@ static int copy_settings(struct domain *cd, struct domain *d)
 {
     int rc;
 
-    if ( (rc = copy_vcpu_settings(cd, d)) )
-        return rc;
-
     if ( (rc = hvm_copy_context_and_params(cd, d)) )
         return rc;
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 17:13:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 17:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPUYg-00074f-PI; Fri, 17 Apr 2020 17:13:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ygtx=6B=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPUYf-00074a-VH
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 17:13:42 +0000
X-Inumbo-ID: c8ebe78c-80ce-11ea-8d59-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c8ebe78c-80ce-11ea-8d59-12813bfff9fa;
 Fri, 17 Apr 2020 17:13:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=D8VN3PW81jkZ4glUrbi6ljPgP5CasHxtokngXuueBhs=; b=y9AGmDgJl4w/qtdvWxdSyatUtG
 6QO5w4PsNYyCXyBexTt0QoPYspFrP1GxjERggjrZ7aYxgsNJUz3iMzqOA33VMrVovR1dpGhy7qux3
 AeP96Y5LGmVEpoU8ztlPh6GA+HKU4gC4a1eJgFAY9iqVHG5mK4QXw8ckcvXsd2Tt/r+I=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPUYe-0003W3-2G; Fri, 17 Apr 2020 17:13:40 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPUYd-00079Q-Qs; Fri, 17 Apr 2020 17:13:39 +0000
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
To: Jan Beulich <jbeulich@suse.com>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
 <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
 <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <80621ca8-6c08-2868-ada6-bf0ef41fc699@xen.org>
Date: Fri, 17 Apr 2020 18:13:37 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 17/04/2020 10:44, Jan Beulich wrote:
> On 17.04.2020 10:37, Julien Grall wrote:
>> On 16/04/2020 16:46, Jan Beulich wrote:
>>> While it should have been this way from the beginning, not doing so will
>>> become an actual problem with PVH Dom0.
>>
>> I think the current code is also buggy on PV dom0 because the buffer
>> is not locked in memory. So you have no promise the buffer will be
>> present when calling the hypercall.
> 
> Quite possibly; I didn't looks at that aspect at all.
> 
>>> --- a/tools/libxc/xc_mem_paging.c
>>> +++ b/tools/libxc/xc_mem_paging.c
>>> @@ -26,15 +26,33 @@ static int xc_mem_paging_memop(xc_interf
>>>                                   unsigned int op, uint64_t gfn, void *buffer)
>>
>> NIT: As you switch the handle to use const, would it make to also
>> make the buffer const?
> 
> A separate change, I would say, but if the tool stack maintainers
> agree with doing so at the same time, I certainly can.

Ok.

> 
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -1779,7 +1779,8 @@ void p2m_mem_paging_populate(struct doma
>>>     * mfn if populate was called for  gfn which was nominated but not evicted. In
>>>     * this case only the p2mt needs to be forwarded.
>>>     */
>>> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l, uint64_t buffer)
>>> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l,
>>> +                        XEN_GUEST_HANDLE_PARAM(const_uint8) buffer)
>>
>> Shouldn't this technically be XEN_GUEST_HANDLE_64() to match the field?
> 
> I think an argument can be made for going either way - as a function
> parameter it should have the type chosen. Do you see any (possibly
> just latent) breakage from using _PARAM() rather than _64()?
I know they are the same on x86, but from an abstract PoV they are 
fundamentally different.

XEN_GUEST_HANDLE_PARAM() represents a guest pointer, when pased as an 
hypercall argument.

XEN_GUEST_HANDLE() represents a guest pointer, when passed as a field in 
a struct in memory.

In this case, the guest pointer was part of a structure. So I think you 
want to use XEN_GUEST_HANDLE().

FWIW, the different matters on Arm. Although, it looks like the compiler 
will not warn you if you are using the wrong handler :(.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 17:16:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 17:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPUbG-0007CE-8M; Fri, 17 Apr 2020 17:16:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=Ygtx=6B=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPUbF-0007C9-Hk
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 17:16:21 +0000
X-Inumbo-ID: 27b4eeee-80cf-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 27b4eeee-80cf-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 17:16:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=pzs92fzZfLsc6pyDF41fqVp18XT3eOxwzr7jwS16cUY=; b=qY1ZxNcUDCpKeQ6fiNnk5dyaWZ
 1upbu6Wo6pqYwjbdqu65peru9mOG5rslJa1/jcKxOhz/daoEt+/lm4HVEYgm491NVzXkgGaW4+B8t
 4AByquvscEGIvoo4E/BoeQy1P6dV5Xpsc6OE8OzgPVdrTs625kRWFFDxQYYCjbVUpizA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPUbD-0003ZD-Q5; Fri, 17 Apr 2020 17:16:19 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPUbD-0007Gn-JU; Fri, 17 Apr 2020 17:16:19 +0000
Subject: Re: [[PATCH v3]] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
To: Jan Beulich <jbeulich@suse.com>
References: <20200416112423.25755-1-julien@xen.org>
 <495b74dc-3ee3-ff23-99ce-2fa4a17d57a4@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <6ce4afd3-7f03-1083-1057-ed90876f90e0@xen.org>
Date: Fri, 17 Apr 2020 18:16:18 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <495b74dc-3ee3-ff23-99ce-2fa4a17d57a4@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 16/04/2020 13:19, Jan Beulich wrote:
> On 16.04.2020 13:24, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
>> data to guest handle marked const.
>>
>> Thankfully, no users of the helper will do that. Rather than hoping this
>> can be caught during review, harden copy_to_guest_offset() so the build
>> will fail if such users are introduced.
>>
>> There is no easy way to check whether a const is NULL in C99. The
>> approach used is to introduce an unused variable that is non-const and
>> assign the handle. If the handle were const, this would fail at build
>> because without an explicit cast, it is not possible to assign a const
>> variable to a non-const variable.
>>
>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Julien Grall <jgrall@amazon.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> with one further remark:
> 
>> --- a/xen/include/asm-x86/guest_access.h
>> +++ b/xen/include/asm-x86/guest_access.h
>> @@ -87,6 +87,8 @@
>>   #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
>>       const typeof(*(ptr)) *_s = (ptr);                   \
>>       char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>> +    /* Check if the handle is not const */              \
>> +    void *__maybe_unused _t = (hnd).p;                  \
> 
> Not being a native speaker, to me "if" doesn't look appropriate
> here. I'd use "that" instead, but you may want to confirm this.
> Overall then maybe "Check that the handle is not for a const type"?

I am happy with the new suggestion. I will fixup while comitting it.


I would also need a review from Stefano here also.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 17:45:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 17:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPV3P-0001Ck-Mq; Fri, 17 Apr 2020 17:45:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=fjPP=6B=kernel.org=pr-tracker-bot@srs-us1.protection.inumbo.net>)
 id 1jPV3O-0001Cf-IT
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 17:45:26 +0000
X-Inumbo-ID: 38371996-80d3-11ea-b4f4-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 38371996-80d3-11ea-b4f4-bc764e2007e4;
 Fri, 17 Apr 2020 17:45:26 +0000 (UTC)
Subject: Re: [GIT PULL] xen: branch for v5.7-rc2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587145525;
 bh=olLvWaB4ydIcFWkrvOI7Encucm4ZHe6kcAaiQlphu3M=;
 h=From:In-Reply-To:References:Date:To:Cc:From;
 b=jMYEzC0zUHELGIqLnf+KzQbReRKX7YDFJxwq0qDXzDszdDKlMEnawj1St9XntdvW6
 I4xZ9laJtGDl94PYdAdnR+RdwBBVcQNbohiDWNtTy9KgppnkWCjSqQnxGErsE1atS1
 xAEmhghYYOZPmrc8sAihs60svt2cyNif6LZ3HLVs=
From: pr-tracker-bot@kernel.org
In-Reply-To: <20200417151735.30600-1-jgross@suse.com>
References: <20200417151735.30600-1-jgross@suse.com>
X-PR-Tracked-List-Id: <linux-kernel.vger.kernel.org>
X-PR-Tracked-Message-Id: <20200417151735.30600-1-jgross@suse.com>
X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
 for-linus-5.7-rc2-tag
X-PR-Tracked-Commit-Id: 74f4c438f22ca3fff157fb45e694805931487c55
X-PR-Merge-Tree: torvalds/linux.git
X-PR-Merge-Refname: refs/heads/master
X-PR-Merge-Commit-Id: d0a4ebe7d1c5970f00cca09cbdfcb8ae1658349d
Message-Id: <158714552532.1625.5085942411616750345.pr-tracker-bot@kernel.org>
Date: Fri, 17 Apr 2020 17:45:25 +0000
To: Juergen Gross <jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
 torvalds@linux-foundation.org, linux-kernel@vger.kernel.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The pull request you sent on Fri, 17 Apr 2020 17:17:35 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.7-rc2-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d0a4ebe7d1c5970f00cca09cbdfcb8ae1658349d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 17:45:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 17:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPV3S-0001Cy-VM; Fri, 17 Apr 2020 17:45:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPV3Q-0001Cq-VV
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 17:45:29 +0000
X-Inumbo-ID: 349175c0-80d3-11ea-8d67-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 349175c0-80d3-11ea-8d67-12813bfff9fa;
 Fri, 17 Apr 2020 17:45:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2N8BLgZKxd/iUXSKCuOxSAQnBFOXc6R6Q6wATt+ISms=; b=BIM/eDLxNUjXnY2BYB1U9GqAJ
 FF47vRj2nWZI2TpARdZWbsbM/uwCGNmFweQtg5idjo+22uLyh/CPXByl7ilKT6JFdM3+vsZLzUvFQ
 WiHgNj57JagHv2s2ewbqV/HgGfVxx+HSgTwA4qPjl3cql0fcvC/8J8cwAiykR2JjxykMQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPV3H-000463-Ba; Fri, 17 Apr 2020 17:45:19 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPV3H-000830-1g; Fri, 17 Apr 2020 17:45:19 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPV3H-0007GV-0q; Fri, 17 Apr 2020 17:45:19 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149700-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149700: regressions - FAIL
X-Osstest-Failures: linux-5.4:test-amd64-amd64-examine:memdisk-try-append:fail:regression
 linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=dc4059d21d87e87054714d51a5325984f91c04b3
X-Osstest-Versions-That: linux=bc844d58f697dff3ded4b410094ee89f5cedc04c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 17:45:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine      4 memdisk-try-append       fail REGR. vs. 149637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149637
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                dc4059d21d87e87054714d51a5325984f91c04b3
baseline version:
 linux                bc844d58f697dff3ded4b410094ee89f5cedc04c

Last test of basis   149637  2020-04-13 09:10:52 Z    4 days
Testing same since   149700  2020-04-17 09:09:37 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Eric W. Biederman" <ebiederm@xmission.com>
  Aaron Liu <aaron.liu@amd.com>
  Adrian Hunter <adrian.hunter@intel.com>
  Ahmed S. Darwish <a.darwish@linutronix.de>
  Ajay Singh <ajay.kathat@microchip.com>
  Alain Volmat <avolmat@me.com>
  Alan Maguire <alan.maguire@oracle.com>
  Alex Deucher <alexander.deucher@amd.com>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Sverdlin <alexander.sverdlin@nokia.com>
  Alexei Starovoitov <ast@kernel.org>
  Alexey Dobriyan (SK hynix) <adobriyan@gmail.com>
  Alexey Dobriyan <adobriyan@gmail.com>
  Andre Przywara <andre.przywara@arm.com>
  Andrei Botila <andrei.botila@nxp.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andrzej Pietrasiewicz <andrzej.p@collabora.com>
  Andy Lutomirski <luto@kernel.org>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
  Anssi Hannula <anssi.hannula@bitwise.fi>
  Ard Biesheuvel <ardb@kernel.org>
  Arnaldo Carvalho de Melo <acme@redhat.com>
  Arvind Sankar <nivedita@alum.mit.edu>
  Bart Van Assche <bvanassche@acm.org>
  Benoit Parrot <bparrot@ti.com>
  Bjorn Andersson <bjorn.andersson@linaro.org>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Liu <bob.liu@oracle.com>
  Bob Peterson <rpeterso@redhat.com>
  Boqun Feng <boqun.feng@gmail.com>
  Borislav Petkov <bp@suse.de>
  Catalin Marinas <catalin.marinas@arm.com>
  Changwei Ge <chge@linux.alibaba.com>
  Chen-Yu Tsai <wens@csie.org>
  chenqiwu <chenqiwu@xiaomi.com>
  Chris Down <chris@chrisdown.name>
  Chris Packham <chris.packham@alliedtelesis.co.nz>
  Chris Wilson <chris@chris-wilson.co.uk>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Gmeiner <christian.gmeiner@gmail.com>
  Christoph Hellwig <hch@lst.de>
  Christoph Niedermaier <cniedermaier@dh-electronics.com>
  Christophe Leroy <christophe.leroy@c-s.fr>
  Chuck Lever <chuck.lever@oracle.com>
  cki-project@redhat.com
  Clement Courbet <courbet@google.com>
  Corey Minyard <cminyard@mvista.com>
  Cédric Le Goater <clg@kaod.org>
  Dan Carpenter <dan.carpenter@oracle.com>
  Daniel Axtens <dja@axtens.net>
  Daniel Borkmann <daniel@iogearbox.net>
  Daniel Lezcano <daniel.lezcano@linaro.org>
  Dave Gerlach <d-gerlach@ti.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <david@redhat.com>
  David Howells <dhowells@redhat.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.com>
  Dick Kennedy <dick.kennedy@broadcom.com>
  Dietmar Eggemann <dietmar.eggemann@arm.com>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Dongchun Zhu <dongchun.zhu@mediatek.com>
  Eric Auger <eric.auger@redhat.com>
  Eric Biggers <ebiggers@google.com>
  Eric W. Biederman <ebiederm@xmission.com>
  Ezequiel Garcia <ezequiel@collabora.com>
  Faiz Abbas <faiz_abbas@ti.com>
  Feilong Lin <linfeilong@huawei.com>
  Felipe Balbi <balbi@kernel.org>
  Filipe Manana <fdmanana@suse.com>
  Fredrik Strupe <fredrik@strupe.net>
  Frieder Schrempf <frieder.schrempf@kontron.de>
  Gao Xiang <gaoxiang25@huawei.com>
  Gary Lin <glin@suse.com>
  Geert Uytterhoeven <geert+renesas@glider.be>
  Gilad Ben-Yossef <gilad@benyossef.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Grigore Popescu <grigore.popescu@nxp.com>
  Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
  Gustavo A. R. Silva <gustavo@embeddedor.com>
  Gyeongtaek Lee <gt82.lee@samsung.com>
  Hans de Goede <hdegoede@redhat.com>
  Hans Verkuil <hverkuil-cisco@xs4all.nl>
  Harshini Shetty <harshini.x.shetty@sony.com>
  He Zhe <zhe.he@windriver.com>
  Herbert Xu <herbert@gondor.apana.org.au>
  Horia Geantă <horia.geanta@nxp.com>
  Huacai Chen <chenhc@lemote.com>
  Huang Rui <ray.huang@amd.com>
  Hui Wang <hui.wang@canonical.com>
  Ilan Peer <ilan.peer@intel.com>
  Imre Deak <imre.deak@intel.com>
  Ingo Molnar <mingo@kernel.org>
  J. Bruce Fields <bfields@redhat.com>
  Jakub Kicinski <kuba@kernel.org>
  James Morse <james.morse@arm.com>
  James Smart <jsmart2021@gmail.com>
  Jan Engelhardt <jengelh@inai.de>
  Jann Horn <jannh@google.com>
  Janosch Frank <frankja@linux.ibm.com>
  Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
  Jeff Mahoney <jeffm@suse.com>
  Jens Axboe <axboe@kernel.dk>
  Jiri Olsa <jolsa@redhat.com>
  Johannes Berg <johannes.berg@intel.com>
  John Garry <john.garry@huawei.com>
  Josef Bacik <josef@toxicpanda.com>
  Juergen Gross <jgross@suse.com>
  Julia Lawall <Julia.Lawall@inria.fr>
  Junyong Sun <sunjunyong@xiaomi.com>
  Junyong Sun <sunjy516@gmail.com>
  Kai-Heng Feng <kai.heng.feng@canonical.com>
  Kalle Valo <kvalo@codeaurora.org>
  Kar Hin Ong <kar.hin.ong@ni.com>
  Kees Cook <keescook@chromium.org>
  Keith Busch <kbusch@kernel.org>
  Kishon Vijay Abraham I <kishon@ti.com>
  Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
  Kristian Klausen <kristian@klausen.dk>
  Krzysztof Kozlowski <krzk@kernel.org>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Laurentiu Tudor <laurentiu.tudor@nxp.com>
  Lee Jones <lee.jones@linaro.org>
  Li Yang <leoyang.li@nxp.com>
  Libor Pechacek <lpechacek@suse.cz>
  Linus Torvalds <torvalds@linux-foundation.org>
  Linus Walleij <linus.walleij@linaro.org>
  Logan Gunthorpe <logang@deltatee.com>
  Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  Luca Coelho <luciano.coelho@intel.com>
  Lucas Stach <l.stach@pengutronix.de>
  Luis Chamberlain <mcgrof@kernel.org>
  Lukas Wunner <lukas@wunner.de>
  Luo bin <luobin9@huawei.com>
  Lyude Paul <lyude@redhat.com>
  Marc Zyngier <maz@kernel.org>
  Marek Szyprowski <m.szyprowski@samsung.com>
  Mark Brown <broonie@kernel.org>
  Markus Fuchs <mklntf@gmail.com>
  Martin Blumenstingl <martin.blumenstingl@googlemail.com>
  Martin K. Petersen <martin.petersen@oracle.com>
  Masami Hiramatsu <mhiramat@kernel.org>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Matt Ranostay <matt.ranostay@konsulko.com>
  Matthew Garrett <matthewgarrett@google.com>
  Matthew Wilcox (Oracle) <willy@infradead.org>
  Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
  Maxime Ripard <maxime@cerno.tech>
  Mengbing Wang <Mengbing.Wang@amd.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Mueller <mimu@linux.ibm.com>
  Michael Tretter <m.tretter@pengutronix.de>
  Michael Walle <michael@walle.cc>
  Michael Wang <yun.wang@linux.alibaba.com>
  Michal Hocko <mhocko@suse.com>
  Michal Suchanek <msuchanek@suse.de>
  Mike Snitzer <snitzer@redhat.com>
  Mikulas Patocka <mpatocka@redhat.com>
  Miquel Raynal <miquel.raynal@bootlin.com>
  Mohammad Rasim <mohammad.rasim96@gmail.com>
  Nathan Chancellor <natechancellor@gmail.com>
  Neeraj Upadhyay <neeraju@codeaurora.org>
  Neil Armstrong <narmstrong@baylibre.com>
  Neil Horman <nhorman@tuxdriver.com>
  Nick Reitemeyer <nick.reitemeyer@web.de>
  Nikita Shubin <NShubin@topcon.com>
  Nikos Tsironis <ntsironis@arrikto.com>
  Oliver O'Halloran <oohall@gmail.com>
  Olivier Moysan <olivier.moysan@st.com>
  Ondrej Jirman <megous@megous.com>
  Ondřej Caletka <ondrej@caletka.cz>
  Paolo Bonzini <pbonzini@redhat.com>
  Paolo Valente <paolo.valente@linaro.org>
  Paul Cercueil <paul@crapouillou.net>
  Pei Huang <huangpei@loongson.cn>
  Peng Fan <peng.fan@nxp.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Pradeep P V K <ppvk@codeaurora.org>
  Prike Liang <Prike.Liang@amd.com>
  Qian Cai <cai@lca.pw>
  Qu Wenruo <wqu@suse.com>
  Rafael Aquini <aquini@redhat.com>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Raju Rangoju <rajur@chelsio.com>
  Remi Pommarel <repk@triplefau.lt>
  Robbie Ko <robbieko@synology.com>
  Rodrigo Vivi <rodrigo.vivi@intel.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Roger Quadros <rogerq@ti.com>
  Ronnie Sahlberg <lsahlber@redhat.com>
  Rosioru Dragos <dragos.rosioru@nxp.com>
  Sagi Grimberg <sagi@grimberg.me>
  Sahitya Tummala <stummala@codeaurora.org>
  Sakari Ailus <sakari.ailus@linux.intel.com>
  Sam Lunt <samuel.j.lunt@gmail.com>
  Sam Lunt <samueljlunt@gmail.com>
  Sasha Levin <sashal@kernel.org>
  Scott Wood <oss@buserror.net>
  Scott Wood <swood@redhat.com>
  Sean Christopherson <sean.j.christopherson@intel.com>
  Sean Tranchetti <stranche@codeaurora.org>
  Sean V Kelley <sean.v.kelley@linux.intel.com>
  Sean Young <sean@mess.org>
  Shetty, Harshini X (EXT-Sony Mobile) <Harshini.X.Shetty@sony.com>
  Sibi Sankar <sibis@codeaurora.org>
  Simon Gander <simon@tuxera.com>
  Song Liu <songliubraving@fb.com>
  Sreekanth Reddy <sreekanth.reddy@broadcom.com>
  Sriharsha Allenki <sallenki@codeaurora.org>
  Stanimir Varbanov <stanimir.varbanov@linaro.org>
  Stanimir Varbanov <svarbanov@mm-sol.com>
  Stanley Chu <stanley.chu@mediatek.com>
  Steffen Maier <maier@linux.ibm.com>
  Stephan Gerhold <stephan@gerhold.net>
  Stephen Boyd <sboyd@kernel.org>
  Steve French <stfrench@microsoft.com>
  Steven Rostedt (VMware) <rostedt@goodmis.org>
  Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
  Sungbo Eo <mans0n@gorani.run>
  Sven Schnelle <svens@linux.ibm.com>
  Taehee Yoo <ap420073@gmail.com>
  Takashi Iwai <tiwai@suse.de>
  Tero Kristo <t-kristo@ti.com>
  Theodore Ts'o <tytso@mit.edu>
  Thinh Nguyen <Thinh.Nguyen@synopsys.com>
  Thinh Nguyen <thinhn@synopsys.com>
  Thomas Bogendoerfer <tsbogend@alpha.franken.de>
  Thomas Gleixner <tglx@linutronix.de>
  Thomas Hebb <tommyhebb@gmail.com>
  Thomas Hellstrom <thellstrom@vmware.com>
  Thomas Zimmermann <tzimmermann@suse.de>
  Tom Lendacky <thomas.lendacky@amd.com>
  Tomasz Figa <tfiga@chromium.org>
  Tony Lindgren <tony@atomide.com>
  Trond Myklebust <trond.myklebust@hammerspace.com>
  Ulf Hansson <ulf.hansson@linaro.org>
  Valentin Ciocoi Radulescu <valentin.ciocoi@nxp.com>
  Vasily Averin <vvs@virtuozzo.com>
  Vasily Gorbik <gor@linux.ibm.com>
  Vincent Guittot <vincent.guittot@linaro.org>
  Viresh Kumar <viresh.kumar@linaro.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Vladimir Oltean <vladimir.oltean@nxp.com>
  Wen Yang <wenyang@linux.alibaba.com>
  Wolfram Sang <wsa@the-dreams.de>
  Xu Wang <vulab@iscas.ac.cn>
  Yang Xu <xuyang2018.jy@cn.fujitsu.com>
  Yangbo Lu <yangbo.lu@nxp.com>
  Yicong Yang <yangyicong@hisilicon.com>
  Yilu Lin <linyilu@huawei.com>
  Yintian Tao <yttao@amd.com>
  Yonghong Song <yhs@fb.com>
  YueHaibing <yuehaibing@huawei.com>
  Yuxian Dai <Yuxian.Dai@amd.com>
  Zheng Wei <wei.zheng@vivo.com>
  Zhiqiang Liu <liuzhiqiang26@huawei.com>
  이경택 <gt82.lee@samsung.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 19:45:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 19:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPWvf-0002Zt-Gk; Fri, 17 Apr 2020 19:45:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fMRh=6B=redhat.com=jsnow@srs-us1.protection.inumbo.net>)
 id 1jPWve-0002Zo-FB
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 19:45:34 +0000
X-Inumbo-ID: 001b8afe-80e4-11ea-8d8c-12813bfff9fa
Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id 001b8afe-80e4-11ea-8d8c-12813bfff9fa;
 Fri, 17 Apr 2020 19:45:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1587152732;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=7SGmO4CMWTruMjIwOTsUxxI3ib9EdM5DOMAXSKcbj5A=;
 b=Tagonb9bIC9zYJEgCLhmdYjStuMpPpJds5DB6VexS3hCGYg1ntawEB6ZwetCtnJuTqlhY1
 S8DAax9LoML2B7iRU0TAjd1feiojdU+YIYrY06o0eQnINfgXCSMI1fBM2OBjDeUsmsafqU
 NqcN2whQZfrnWGDEID/GpQt3f7mZzb0=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-179-HBjqHuMQPKyk9jQwPny2NA-1; Fri, 17 Apr 2020 15:45:30 -0400
X-MC-Unique: HBjqHuMQPKyk9jQwPny2NA-1
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com
 [10.5.11.16])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8D06D192D785;
 Fri, 17 Apr 2020 19:45:26 +0000 (UTC)
Received: from [10.10.119.33] (ovpn-119-33.rdu2.redhat.com [10.10.119.33])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 5F9AA5C28E;
 Fri, 17 Apr 2020 19:45:09 +0000 (UTC)
Subject: Re: [PATCH-for-5.1 2/3] various: Remove unnecessary OBJECT() cast
To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <f4bug@amsat.org>,
 qemu-devel@nongnu.org
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-3-f4bug@amsat.org>
From: John Snow <jsnow@redhat.com>
Autocrypt: addr=jsnow@redhat.com; prefer-encrypt=mutual; keydata=
 mQINBFTKefwBEAChvwqYC6saTzawbih87LqBYq0d5A8jXYXaiFMV/EvMSDqqY4EY6whXliNO
 IYzhgrPEe7ZmPxbCSe4iMykjhwMh5byIHDoPGDU+FsQty2KXuoxto+ZdrP9gymAgmyqdk3aV
 vzzmCa3cOppcqKvA0Kqr10UeX/z4OMVV390V+DVWUvzXpda45/Sxup57pk+hyY52wxxjIqef
 rj8u5BN93s5uCVTus0oiVA6W+iXYzTvVDStMFVqnTxSxlpZoH5RGKvmoWV3uutByQyBPHW2U
 1Y6n6iEZ9MlP3hcDqlo0S8jeP03HaD4gOqCuqLceWF5+2WyHzNfylpNMFVi+Hp0H/nSDtCvQ
 ua7j+6Pt7q5rvqgHvRipkDDVsjqwasuNc3wyoHexrBeLU/iJBuDld5iLy+dHXoYMB3HmjMxj
 3K5/8XhGrDx6BDFeO3HIpi3u2z1jniB7RtyVEtdupED6lqsDj0oSz9NxaOFZrS3Jf6z/kHIf
 h42mM9Sx7+s4c07N2LieUxcfqhFTaa/voRibF4cmkBVUhOD1AKXNfhEsTvmcz9NbUchCkcvA
 T9119CrsxfVsE7bXiGvdXnzyGLXdsoosjzwacKdOrVaDmN3Uy+SHiQXo6TlkSdV0XH2PUxTM
 LsBFIO9qXO43Ai6J6iPAP/01l8fuZfpJE0/L/c25yyaND7xA3wARAQABtCpKb2huIFNub3cg
 KEpvaG4gSHVzdG9uKSA8anNub3dAcmVkaGF0LmNvbT6JAlQEEwECAD4CGwMCHgECF4AFCwkI
 BwMFFQoJCAsFFgIDAQAWIQT665cRoSz0dYEvGPKIqQZNGDVh6wUCXF392gUJC1Xq3gAKCRCI
 qQZNGDVh6558D/9pM4pu4njX5aT6uUW3vAmbWLF1jfPxiTQgSHAnm9EBMZED/fsvkzj97clo
 LN7JKmbYZNgJmR01A7flG45V4iOR/249qAfaVuD+ZzZi1R4jFzr13WS+IEdn0hYp9ITndb7R
 ezW+HGu6/rP2PnfmDnNowgJu6Dp6IUEabq8SXXwGHXZPuMIrsXJxUdKJdGnh1o2u7271yNO7
 J9PEMuMDsgjsdnaGtv7aQ9CECtXvBleAc06pLW2HU10r5wQyBMZGITemJdBhhdzGmbHAL0M6
 vKi/bafHRWqfMqOAdDkv3Jg4arl2NCG/uNateR1z5e529+UlB4XVAQT+f5T/YyI65DFTY940
 il3aZhA8u788jZEPMXmt94u7uPZbEYp7V0jt68SrTaOgO7NaXsboXFjwEa42Ug5lB5d5/Qdp
 1AITUv0NJ51kKwhHL1dEagGeloIsGVQILmpS0MLdtitBHqZLsnJkRvtMaxo47giyBlv2ewmq
 tIGTlVLxHx9xkc9aVepOuiGlZaZB72c9AvZs9rKaAjgU2UfJHlB/Hr4uSk/1EY0IgMv4vnsG
 1sA5gvS7A4T4euu0PqHtn2sZEWDrk5RDbw0yIb53JYdXboLFmFXKzVASfKh2ZVeXRBlQQSJi
 3PBR1GzzqORlfryby7mkY857xzCI2NkIkD2eq+HhzFTfFOTdGrkCDQRUynn8ARAAwbhP45BE
 d/zAMBPV2dk2WwIwKRSKULElP3kXpcuiDWYQob3UODUUqClO+3aXVRndaNmZX9WbzGYexVo3
 5j+CVBCGr3DlU8AL9pp3KQ3SJihWcDed1LSmUf8tS+10d6mdGxDqgnd/OWU214isvhgWZtZG
 MM/Xj7cx5pERIiP+jqu7PT1cibcfcEKhPjYdyV1QnLtKNGrTg/UMKaL+qkWBUI/8uBoa0HLs
 NH63bXsRtNAG8w6qG7iiueYZUIXKc4IHINUguqYQJVdSe+u8b2N5XNhDSEUhdlqFYraJvX6d
 TjxMTW5lzVG2KjztfErRNSUmu2gezbw1/CV0ztniOKDA7mkQi6UIUDRh4LxRm5mflfKiCyDQ
 L6P/jxHBxFv+sIgjuLrfNhIC1p3z9rvCh+idAVJgtHtYl8p6GAVrF+4xQV2zZH45tgmHo2+S
 JsLPjXZtWVsWANpepXnesyabWtNAV4qQB7/SfC77zZwsVX0OOY2Qc+iohmXo8U7DgXVDgl/R
 /5Qgfnlv0/3rOdMt6ZPy5LJr8D9LJmcP0RvX98jyoBOf06Q9QtEwJsNLCOCo2LKNL71DNjZr
 nXEwjUH66CXiRXDbDKprt71BiSTitkFhGGU88XCtrp8R9yArXPf4MN+wNYBjfT7K29gWTzxt
 9DYQIvEf69oZD5Z5qHYGp031E90AEQEAAYkCPAQYAQIAJgIbDBYhBPrrlxGhLPR1gS8Y8oip
 Bk0YNWHrBQJcXf3JBQkLVerNAAoJEIipBk0YNWHrU1AP/1FOK2SBGbyhHa5vDHuf47fgLipC
 e0/h1E0vdSonzlhPxuZoQ47FjzG9uOhqqQG6/PqtWs/FJIyz8aGG4aV+pSA/9Ko3/2ND8MSY
 ZflWs7Y8Peg08Ro01GTHFITjEUgHpTpHiT6TNcZB5aZNJ8jqCtW5UlqvXXbVeSTmO70ZiVtc
 vUJbpvSxYmzhFfZWaXIPcNcKWL1rnmnzs67lDhMLdkYVf91aml/XtyMUlfB8Iaejzud9Ht3r
 C0pA9MG57pLblX7okEshxAC0+tUdY2vANWFeX0mgqRt1GSuG9XM9H/cKP1czfUV/FgaWo/Ya
 fM4eMhUAlL/y+/AJxxumPhBXftM4yuiktp2JMezoIMJI9fmhjfWDw7+2jVrx9ze1joLakFD1
 rVAoHxVJ7ORfQ4Ni/qWbQm3T6qQkSMt4N/scNsMczibdTPxU7qtwQwIeFOOc3wEwmJ9Qe3ox
 TODQ0agXiWVj0OXYCHJ6MxTDswtyTGQW+nUHpKBgHGwUaR6d1kr/LK9+5LpOfRlK9VRfEu7D
 PGNiRkr8Abp8jHsrBqQWfUS1bAf62bq6XUel0kUCtb7qCq024aOczXYWPFpJFX+nhp4d7NeH
 Edq+wlC13sBSiSHC7T5yssJ+7JPa2ATLlSKhEvBsLe2TsSTTtFlA0nBclqhfJXzimiuge9qU
 E40lvMWBuQINBFTKimUBEADDbJ+pQ5M4QBMWkaWImRj7c598xIZ37oKM6rGaSnuB1SVb7YCr
 Ci2MTwQcrQscA2jm80O8VFqWk+/XsEp62dty47GVwSfdGje/3zv3VTH2KhOCKOq3oPP5ZXWY
 rz2d2WnTvx++o6lU7HLHDEC3NGLYNLkL1lyVxLhnhvcMxkf1EGA1DboEcMgnJrNB1pGP27ww
 cSfvdyPGseV+qZZa8kuViDga1oxmnYDxFKMGLxrClqHrRt8geQL1Wj5KFM5hFtGTK4da5lPn
 wGNd6/CINMeCT2AWZY5ySz7/tSZe5F22vPvVZGoPgQicYWdNc3ap7+7IKP86JNjmec/9RJcz
 jvrYjJdiqBVldXou72CtDydKVLVSKv8c2wBDJghYZitfYIaL8cTvQfUHRYTfo0n5KKSec8Vo
 vjDuxmdbOUBA+SkRxqmneP5OxGoZ92VusrwWCjry8HRsNdR+2T+ClDCO6Wpihu4V3CPkQwTy
 eCuMHPAT0ka5paTwLrnZIxsdfnjUa96T10vzmQgAxpbbiaLvgKJ8+76OPdDnhddyxd2ldYfw
 RkF5PEGg3mqZnYKNNBtwjvX49SAvgETQvLzQ8IKVgZS0m4z9qHHvtc1BsQnFfe+LJOFjzZr7
 CrDNJMqk1JTHYsSi2JcN3vY32WMezXSQ0TzeMK4kdnclSQyp/h23GWod5QARAQABiQRbBBgB
 AgAmAhsCFiEE+uuXEaEs9HWBLxjyiKkGTRg1YesFAlxd/coFCQtV2mQCKcFdIAQZAQIABgUC
 VMqKZQAKCRB974EGqvw5DiJoEACLmuiRq9ifvOh5DyBFwRS7gvA14DsGQngmC57EzV0EFcfM
 XVi1jX5OtwUyUe0Az5r6lHyyHDsDsIpLKBlWrYCeLpUhRR3oy181T7UNxvujGFeTkzvLAOo6
 Hs3b8Wv9ARg+7acRYkQRNY7k0GIJ6YZz149tRyRKAy/vSjsaB9Lt0NOd1wf2EQMKwRVELwJD
 y0AazGn+0PRP7Bua2YbtxaBmhBBDb2tPpwn8U9xdckB4Vlft9lcWNsC/18Gi9bpjd9FSbdH/
 sOUI+3ToWYENeoT4IP09wn6EkgWaJS3nAUN/MOycNej2i4Yhy2wDDSKyTAnVkSSSoXk+tK91
 HfqtokbDanB8daP+K5LgoiWHzjfWzsxA2jKisI4YCGjrYQzTyGOT6P6u6SEeoEx10865B/zc
 8/vN50kncdjYz2naacIDEKQNZlnGLsGkpCbfmfdi3Zg4vuWKNdWr0wGUzDUcpqW0y/lUXna+
 6uyQShX5e4JD2UPuf9WAQ9HtgSAkaDd4O1I2J41sleePzZOVB3DmYgy+ECRJJ5nw3ihdxpgc
 y/v3lfcJaqiyCv0PF+K/gSOvwhH7CbVqARmptT7yhhxqFdaYWo2Z2ksuKyoKSRMFCXQY5oac
 uTmyPIT4STFyUQFeqSCWDum/NFNoSKhmItw2Td+4VSJHShRVbg39KNFPZ7mXYAkQiKkGTRg1
 YesWJA/+PV3qDUtPNEGwjVvjQqHSbrBy94tu6gJvPHgGPtRDYvxnCaJsmgiC0pGB2KFRsnfl
 2zBNBEWF/XwsI081jQE5UO60GKmHTputChLXpVobyuc+lroG2YhknXRBAV969SLnZR4BS/1s
 Gi046gOXfaKYatve8BiZr5it5Foq3FMPDNgZMit1H9Dk8rkKFfDMRf8EGS/Z+TmyEsIf99H7
 TH3n7lco8qO81fSFwkh4pvo2kWRFYTC5vsIVQ+GqVUp+W1DZJHxX8LwWuF1AzUt4MUTtNAvy
 TXl5EgsmoY9mpNNL7ZnW65oG63nEP5KNiybvuQJzXVxR8eqzOh2Mod4nHg3PE7UCd3DvLNsn
 GXFRo44WyT/G2lArBtjpkut7bDm0i1nENABy2UgS+1QvdmgNu6aEZxdNthwRjUhuuvCCDMA4
 rCDQYyakH2tJNQgkXkeLodBKF4bHiBbuwj0E39S9wmGgg+q4OTnAO/yhQGknle7a7G5xHBwE
 i0HjnLoJP5jDcoMTabZTIazXmJz3pKM11HYJ5/ZsTIf3ZRJJKIvXJpbmcAPVwTZII6XxiJdh
 RSSX4Mvd5pL/+5WI6NTdW6DMfigTtdd85fe6PwBNVJL2ZvBfsBJZ5rxg1TOH3KLsYBqBTgW2
 glQofxhkJhDEcvjLhe3Y2BlbCWKOmvM8XS9TRt0OwUs=
Message-ID: <f3b9362e-b55e-c9e1-81b0-fa770f96bd13@redhat.com>
Date: Fri, 17 Apr 2020 15:45:08 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200412210954.32313-3-f4bug@amsat.org>
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?UTF-8?Q?C=c3=a9dric_Le_Goater?= <clg@kaod.org>,
 Richard Henderson <rth@twiddle.net>,
 =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 4/12/20 5:09 PM, Philippe Mathieu-Daud=C3=A9 wrote:
> -    memory_region_init_io(&a->mmio, OBJECT(obj), &allwinner_ahci_mem_ops=
, a,
> +    memory_region_init_io(&a->mmio, obj, &allwinner_ahci_mem_ops, a,

Acked-by: John Snow <jsnow@redhat.com>



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 19:46:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 19:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPWwH-0002cS-S9; Fri, 17 Apr 2020 19:46:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=fMRh=6B=redhat.com=jsnow@srs-us1.protection.inumbo.net>)
 id 1jPWwG-0002cI-OM
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 19:46:12 +0000
X-Inumbo-ID: 17788c24-80e4-11ea-9e09-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 17788c24-80e4-11ea-9e09-bc764e2007e4;
 Fri, 17 Apr 2020 19:46:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1587152772;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=PLcbl+bmeMrJ87QQsOvOjSaI65Nvn1hnJ1HGq+00ox4=;
 b=PntUoJEJRKhcBkQ+YtSaDmGd7gSE9Nn8MxZhX63qbEWQKAT0/7LwsQaUKUewJqwjg5D7BS
 MfKiS12ng8Sa1/VuA1HdYAV5yTWmW0Rp3HOKgujRKoRwL1vQjTPwmEmGrebgq7rsU6Fzs7
 SA4xdILEkn+GL2m0eJ+X/aT3VaJfxW4=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-510-pcV3h1kAOY-R5aFO7L_9Nw-1; Fri, 17 Apr 2020 15:46:10 -0400
X-MC-Unique: pcV3h1kAOY-R5aFO7L_9Nw-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D1CAB107ACC9;
 Fri, 17 Apr 2020 19:46:05 +0000 (UTC)
Received: from [10.10.119.33] (ovpn-119-33.rdu2.redhat.com [10.10.119.33])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 6CF1F8D57F;
 Fri, 17 Apr 2020 19:45:53 +0000 (UTC)
Subject: Re: [PATCH-for-5.1 3/3] hw: Remove unnecessary DEVICE() cast
To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <f4bug@amsat.org>,
 qemu-devel@nongnu.org
References: <20200412210954.32313-1-f4bug@amsat.org>
 <20200412210954.32313-4-f4bug@amsat.org>
From: John Snow <jsnow@redhat.com>
Autocrypt: addr=jsnow@redhat.com; prefer-encrypt=mutual; keydata=
 mQINBFTKefwBEAChvwqYC6saTzawbih87LqBYq0d5A8jXYXaiFMV/EvMSDqqY4EY6whXliNO
 IYzhgrPEe7ZmPxbCSe4iMykjhwMh5byIHDoPGDU+FsQty2KXuoxto+ZdrP9gymAgmyqdk3aV
 vzzmCa3cOppcqKvA0Kqr10UeX/z4OMVV390V+DVWUvzXpda45/Sxup57pk+hyY52wxxjIqef
 rj8u5BN93s5uCVTus0oiVA6W+iXYzTvVDStMFVqnTxSxlpZoH5RGKvmoWV3uutByQyBPHW2U
 1Y6n6iEZ9MlP3hcDqlo0S8jeP03HaD4gOqCuqLceWF5+2WyHzNfylpNMFVi+Hp0H/nSDtCvQ
 ua7j+6Pt7q5rvqgHvRipkDDVsjqwasuNc3wyoHexrBeLU/iJBuDld5iLy+dHXoYMB3HmjMxj
 3K5/8XhGrDx6BDFeO3HIpi3u2z1jniB7RtyVEtdupED6lqsDj0oSz9NxaOFZrS3Jf6z/kHIf
 h42mM9Sx7+s4c07N2LieUxcfqhFTaa/voRibF4cmkBVUhOD1AKXNfhEsTvmcz9NbUchCkcvA
 T9119CrsxfVsE7bXiGvdXnzyGLXdsoosjzwacKdOrVaDmN3Uy+SHiQXo6TlkSdV0XH2PUxTM
 LsBFIO9qXO43Ai6J6iPAP/01l8fuZfpJE0/L/c25yyaND7xA3wARAQABtCpKb2huIFNub3cg
 KEpvaG4gSHVzdG9uKSA8anNub3dAcmVkaGF0LmNvbT6JAlQEEwECAD4CGwMCHgECF4AFCwkI
 BwMFFQoJCAsFFgIDAQAWIQT665cRoSz0dYEvGPKIqQZNGDVh6wUCXF392gUJC1Xq3gAKCRCI
 qQZNGDVh6558D/9pM4pu4njX5aT6uUW3vAmbWLF1jfPxiTQgSHAnm9EBMZED/fsvkzj97clo
 LN7JKmbYZNgJmR01A7flG45V4iOR/249qAfaVuD+ZzZi1R4jFzr13WS+IEdn0hYp9ITndb7R
 ezW+HGu6/rP2PnfmDnNowgJu6Dp6IUEabq8SXXwGHXZPuMIrsXJxUdKJdGnh1o2u7271yNO7
 J9PEMuMDsgjsdnaGtv7aQ9CECtXvBleAc06pLW2HU10r5wQyBMZGITemJdBhhdzGmbHAL0M6
 vKi/bafHRWqfMqOAdDkv3Jg4arl2NCG/uNateR1z5e529+UlB4XVAQT+f5T/YyI65DFTY940
 il3aZhA8u788jZEPMXmt94u7uPZbEYp7V0jt68SrTaOgO7NaXsboXFjwEa42Ug5lB5d5/Qdp
 1AITUv0NJ51kKwhHL1dEagGeloIsGVQILmpS0MLdtitBHqZLsnJkRvtMaxo47giyBlv2ewmq
 tIGTlVLxHx9xkc9aVepOuiGlZaZB72c9AvZs9rKaAjgU2UfJHlB/Hr4uSk/1EY0IgMv4vnsG
 1sA5gvS7A4T4euu0PqHtn2sZEWDrk5RDbw0yIb53JYdXboLFmFXKzVASfKh2ZVeXRBlQQSJi
 3PBR1GzzqORlfryby7mkY857xzCI2NkIkD2eq+HhzFTfFOTdGrkCDQRUynn8ARAAwbhP45BE
 d/zAMBPV2dk2WwIwKRSKULElP3kXpcuiDWYQob3UODUUqClO+3aXVRndaNmZX9WbzGYexVo3
 5j+CVBCGr3DlU8AL9pp3KQ3SJihWcDed1LSmUf8tS+10d6mdGxDqgnd/OWU214isvhgWZtZG
 MM/Xj7cx5pERIiP+jqu7PT1cibcfcEKhPjYdyV1QnLtKNGrTg/UMKaL+qkWBUI/8uBoa0HLs
 NH63bXsRtNAG8w6qG7iiueYZUIXKc4IHINUguqYQJVdSe+u8b2N5XNhDSEUhdlqFYraJvX6d
 TjxMTW5lzVG2KjztfErRNSUmu2gezbw1/CV0ztniOKDA7mkQi6UIUDRh4LxRm5mflfKiCyDQ
 L6P/jxHBxFv+sIgjuLrfNhIC1p3z9rvCh+idAVJgtHtYl8p6GAVrF+4xQV2zZH45tgmHo2+S
 JsLPjXZtWVsWANpepXnesyabWtNAV4qQB7/SfC77zZwsVX0OOY2Qc+iohmXo8U7DgXVDgl/R
 /5Qgfnlv0/3rOdMt6ZPy5LJr8D9LJmcP0RvX98jyoBOf06Q9QtEwJsNLCOCo2LKNL71DNjZr
 nXEwjUH66CXiRXDbDKprt71BiSTitkFhGGU88XCtrp8R9yArXPf4MN+wNYBjfT7K29gWTzxt
 9DYQIvEf69oZD5Z5qHYGp031E90AEQEAAYkCPAQYAQIAJgIbDBYhBPrrlxGhLPR1gS8Y8oip
 Bk0YNWHrBQJcXf3JBQkLVerNAAoJEIipBk0YNWHrU1AP/1FOK2SBGbyhHa5vDHuf47fgLipC
 e0/h1E0vdSonzlhPxuZoQ47FjzG9uOhqqQG6/PqtWs/FJIyz8aGG4aV+pSA/9Ko3/2ND8MSY
 ZflWs7Y8Peg08Ro01GTHFITjEUgHpTpHiT6TNcZB5aZNJ8jqCtW5UlqvXXbVeSTmO70ZiVtc
 vUJbpvSxYmzhFfZWaXIPcNcKWL1rnmnzs67lDhMLdkYVf91aml/XtyMUlfB8Iaejzud9Ht3r
 C0pA9MG57pLblX7okEshxAC0+tUdY2vANWFeX0mgqRt1GSuG9XM9H/cKP1czfUV/FgaWo/Ya
 fM4eMhUAlL/y+/AJxxumPhBXftM4yuiktp2JMezoIMJI9fmhjfWDw7+2jVrx9ze1joLakFD1
 rVAoHxVJ7ORfQ4Ni/qWbQm3T6qQkSMt4N/scNsMczibdTPxU7qtwQwIeFOOc3wEwmJ9Qe3ox
 TODQ0agXiWVj0OXYCHJ6MxTDswtyTGQW+nUHpKBgHGwUaR6d1kr/LK9+5LpOfRlK9VRfEu7D
 PGNiRkr8Abp8jHsrBqQWfUS1bAf62bq6XUel0kUCtb7qCq024aOczXYWPFpJFX+nhp4d7NeH
 Edq+wlC13sBSiSHC7T5yssJ+7JPa2ATLlSKhEvBsLe2TsSTTtFlA0nBclqhfJXzimiuge9qU
 E40lvMWBuQINBFTKimUBEADDbJ+pQ5M4QBMWkaWImRj7c598xIZ37oKM6rGaSnuB1SVb7YCr
 Ci2MTwQcrQscA2jm80O8VFqWk+/XsEp62dty47GVwSfdGje/3zv3VTH2KhOCKOq3oPP5ZXWY
 rz2d2WnTvx++o6lU7HLHDEC3NGLYNLkL1lyVxLhnhvcMxkf1EGA1DboEcMgnJrNB1pGP27ww
 cSfvdyPGseV+qZZa8kuViDga1oxmnYDxFKMGLxrClqHrRt8geQL1Wj5KFM5hFtGTK4da5lPn
 wGNd6/CINMeCT2AWZY5ySz7/tSZe5F22vPvVZGoPgQicYWdNc3ap7+7IKP86JNjmec/9RJcz
 jvrYjJdiqBVldXou72CtDydKVLVSKv8c2wBDJghYZitfYIaL8cTvQfUHRYTfo0n5KKSec8Vo
 vjDuxmdbOUBA+SkRxqmneP5OxGoZ92VusrwWCjry8HRsNdR+2T+ClDCO6Wpihu4V3CPkQwTy
 eCuMHPAT0ka5paTwLrnZIxsdfnjUa96T10vzmQgAxpbbiaLvgKJ8+76OPdDnhddyxd2ldYfw
 RkF5PEGg3mqZnYKNNBtwjvX49SAvgETQvLzQ8IKVgZS0m4z9qHHvtc1BsQnFfe+LJOFjzZr7
 CrDNJMqk1JTHYsSi2JcN3vY32WMezXSQ0TzeMK4kdnclSQyp/h23GWod5QARAQABiQRbBBgB
 AgAmAhsCFiEE+uuXEaEs9HWBLxjyiKkGTRg1YesFAlxd/coFCQtV2mQCKcFdIAQZAQIABgUC
 VMqKZQAKCRB974EGqvw5DiJoEACLmuiRq9ifvOh5DyBFwRS7gvA14DsGQngmC57EzV0EFcfM
 XVi1jX5OtwUyUe0Az5r6lHyyHDsDsIpLKBlWrYCeLpUhRR3oy181T7UNxvujGFeTkzvLAOo6
 Hs3b8Wv9ARg+7acRYkQRNY7k0GIJ6YZz149tRyRKAy/vSjsaB9Lt0NOd1wf2EQMKwRVELwJD
 y0AazGn+0PRP7Bua2YbtxaBmhBBDb2tPpwn8U9xdckB4Vlft9lcWNsC/18Gi9bpjd9FSbdH/
 sOUI+3ToWYENeoT4IP09wn6EkgWaJS3nAUN/MOycNej2i4Yhy2wDDSKyTAnVkSSSoXk+tK91
 HfqtokbDanB8daP+K5LgoiWHzjfWzsxA2jKisI4YCGjrYQzTyGOT6P6u6SEeoEx10865B/zc
 8/vN50kncdjYz2naacIDEKQNZlnGLsGkpCbfmfdi3Zg4vuWKNdWr0wGUzDUcpqW0y/lUXna+
 6uyQShX5e4JD2UPuf9WAQ9HtgSAkaDd4O1I2J41sleePzZOVB3DmYgy+ECRJJ5nw3ihdxpgc
 y/v3lfcJaqiyCv0PF+K/gSOvwhH7CbVqARmptT7yhhxqFdaYWo2Z2ksuKyoKSRMFCXQY5oac
 uTmyPIT4STFyUQFeqSCWDum/NFNoSKhmItw2Td+4VSJHShRVbg39KNFPZ7mXYAkQiKkGTRg1
 YesWJA/+PV3qDUtPNEGwjVvjQqHSbrBy94tu6gJvPHgGPtRDYvxnCaJsmgiC0pGB2KFRsnfl
 2zBNBEWF/XwsI081jQE5UO60GKmHTputChLXpVobyuc+lroG2YhknXRBAV969SLnZR4BS/1s
 Gi046gOXfaKYatve8BiZr5it5Foq3FMPDNgZMit1H9Dk8rkKFfDMRf8EGS/Z+TmyEsIf99H7
 TH3n7lco8qO81fSFwkh4pvo2kWRFYTC5vsIVQ+GqVUp+W1DZJHxX8LwWuF1AzUt4MUTtNAvy
 TXl5EgsmoY9mpNNL7ZnW65oG63nEP5KNiybvuQJzXVxR8eqzOh2Mod4nHg3PE7UCd3DvLNsn
 GXFRo44WyT/G2lArBtjpkut7bDm0i1nENABy2UgS+1QvdmgNu6aEZxdNthwRjUhuuvCCDMA4
 rCDQYyakH2tJNQgkXkeLodBKF4bHiBbuwj0E39S9wmGgg+q4OTnAO/yhQGknle7a7G5xHBwE
 i0HjnLoJP5jDcoMTabZTIazXmJz3pKM11HYJ5/ZsTIf3ZRJJKIvXJpbmcAPVwTZII6XxiJdh
 RSSX4Mvd5pL/+5WI6NTdW6DMfigTtdd85fe6PwBNVJL2ZvBfsBJZ5rxg1TOH3KLsYBqBTgW2
 glQofxhkJhDEcvjLhe3Y2BlbCWKOmvM8XS9TRt0OwUs=
Message-ID: <a4eda645-9e09-b384-0b17-c38a4025ef3c@redhat.com>
Date: Fri, 17 Apr 2020 15:45:52 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200412210954.32313-4-f4bug@amsat.org>
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peter Maydell <peter.maydell@linaro.org>,
 David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>,
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
 BALATON Zoltan <balaton@eik.bme.hu>, Gerd Hoffmann <kraxel@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>, qemu-block@nongnu.org,
 Paul Durrant <paul@xen.org>, Markus Armbruster <armbru@redhat.com>,
 Halil Pasic <pasic@linux.ibm.com>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
 Joel Stanley <joel@jms.id.au>, Anthony Perard <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, David Gibson <david@gibson.dropbear.id.au>,
 =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <philmd@redhat.com>,
 Eduardo Habkost <ehabkost@redhat.com>, Corey Minyard <minyard@acm.org>,
 "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-s390x@nongnu.org,
 qemu-arm@nongnu.org, Peter Chubb <peter.chubb@nicta.com.au>,
 =?UTF-8?Q?C=c3=a9dric_Le_Goater?= <clg@kaod.org>,
 Richard Henderson <rth@twiddle.net>,
 =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= <berrange@redhat.com>,
 Andrew Jeffery <andrew@aj.id.au>, Cornelia Huck <cohuck@redhat.com>,
 Laurent Vivier <laurent@vivier.eu>, qemu-ppc@nongnu.org,
 Paolo Bonzini <pbonzini@redhat.com>, Aurelien Jarno <aurelien@aurel32.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 4/12/20 5:09 PM, Philippe Mathieu-Daud=C3=A9 wrote:
> diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> index 3b2de4c312..b402a93636 100644
> --- a/hw/ide/piix.c
> +++ b/hw/ide/piix.c
> @@ -193,7 +193,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev, bool a=
ux)
>              blk_unref(blk);
>          }
>      }
> -    qdev_reset_all(DEVICE(dev));
> +    qdev_reset_all(dev);
>      return 0;
>  }
> =20

Acked-by: John Snow <jsnow@redhat.com>



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 19:46:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 19:46:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPWwg-0002fr-68; Fri, 17 Apr 2020 19:46:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9Py=6B=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jPWwe-0002fd-CC
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 19:46:36 +0000
X-Inumbo-ID: 251785ce-80e4-11ea-8d8c-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 251785ce-80e4-11ea-8d8c-12813bfff9fa;
 Fri, 17 Apr 2020 19:46:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587152795;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=i0czuu+bpPt/GLhHiDU/+0/mjatb0g27pfgD9Jof7ks=;
 b=HIm5I9mTtxUoDt3xUi2/5hxhPe6d9f4rboj/90jDE4DTY3Whl3DRVCzA
 bOqumZyFbMSGh9z5xlOsFnN9iUUwmYxv6xbpysrHZtlN8WWTzdVNcsCj8
 inW1J2OnHN7QO6N5UxpKW3AFceAIKO736ozDsUYf6gT+S0XAO3jJzO8bz M=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 7cya/+90k0nYnj1OsS0J/jXXn2rL19IlElmrqaJGoI0BwG0a/lhCIiZiuB+4OroC85IsYoltjq
 UCBRYJJTNC7X6r+jbeBqyjR3fhRttr71fEVXnfG771laU3YLcaxMb3DvIr7PvMoBXL4BnD+K56
 79jYLyS9UmaSWw885KYkBuOcmKK7/WRgAEUYvJezsCmgffNWgb5wsZRXPFKY39cRQqhPo64zrO
 fLycCuUVlRmZiLPUtou0h3GFw1ZwYC5ZtMEDmQxaGJYwSOZWDX8W9NX+jTmxvrWzcVkxHBIZ0t
 AKc=
X-SBRS: 2.7
X-MesageID: 16180506
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="16180506"
Subject: Re: [PATCH 01/10] x86/mm: no-one passes a NULL domain to
 init_xen_l4_slots()
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
 <19d7ad4f-c653-b7b6-59a8-90c9700c9200@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <68542638-b5d5-3261-8088-d0cd6e2dcd74@citrix.com>
Date: Fri, 17 Apr 2020 20:46:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <19d7ad4f-c653-b7b6-59a8-90c9700c9200@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>, Wei
 Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17/04/2020 15:25, Jan Beulich wrote:
> Drop the NULL checks - they've been introduced by commit 8d7b633ada
> ("x86/mm: Consolidate all Xen L4 slot writing into
> init_xen_l4_slots()") for no apparent reason.

:) I'll take this as conformation that all my sudden pagetable work in
Xen manage ended up being rather more subtle than Linux's equivalent
work for KPTI.

https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00281.html

Specifically, this was part of trying to arrange for fully per-pcpu
private mappings, and was used to construct the pagetables for the idle
vcpu which specifically don't have a perdomain mapping.

Seeing as this is still an outstanding task in the secret-free-Xen
plans, any dropping of it now will have to be undone at some point in
the future.  Is there a specific reason for the cleanup?

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1696,7 +1696,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t

If we continue with this patch, this comment, just out of context, needs
adjusting.

~Andrew

>       * PV vcpus need a shortened directmap.  HVM and Idle vcpus get the full
>       * directmap.
>       */
> -    bool short_directmap = d && !paging_mode_external(d);
> +    bool short_directmap = !paging_mode_external(d);
>  
>      /* Slot 256: RO M2P (if applicable). */
>      l4t[l4_table_offset(RO_MPT_VIRT_START)] =
>



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 19:51:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 19:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPX19-0003YW-RR; Fri, 17 Apr 2020 19:51:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9Py=6B=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jPX19-0003YR-Fv
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 19:51:15 +0000
X-Inumbo-ID: cad0c6ec-80e4-11ea-8d8e-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cad0c6ec-80e4-11ea-8d8e-12813bfff9fa;
 Fri, 17 Apr 2020 19:51:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587153074;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=RgRmr230wnYjNNSUHIhVD8yX7hpvc9Y4Jh7dc4PYD9g=;
 b=PcpCkFisTvGzlnnvRMgTWp9BeS5MUTYvhgbtDWrdnySStFqSZcYfoDXv
 INRrxHdqisV8y4s6ajgJ17zCfbWz4zq4D/Unf2va955xJ361OGBwuvEpi
 76kNXfmgXewbIb59eoZuzYOkCKEFsLZ5LrQWWE531L/el2MP9iMORp9fM M=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: QVx8Y3eMc885KLcfwZPK1w8jzVY68NmjzHuRnzdjzFDDq+n6r9IWGk/c7r2YbzKJQ/+pwlb6zR
 U0So8Rp0C4DVe9tBEJBjORj8OBwThOjbaN5evMqW7ounUpSKhqsfR7MxuqA4MVXGqvDPw8Q4sW
 DoXo+nHltGF4EcQ1JIjonkfkMnia8TTXb0Rv1TdmiIWsoOxwfywdxvT+h/UE18qqoCmTaDMuaF
 4DLjtqabNIcuthpvBj1DDR3piw5Gt/ggFtISi3/powTUDRCXplTl0zIPlhSnS1g3pkEAGUyIcu
 uvo=
X-SBRS: 2.7
X-MesageID: 16107768
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="16107768"
Subject: Re: [PATCH 03/10] x86/shadow: monitor table is HVM-only
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
 <7aa11566-289c-41c2-ec90-c15e0a6490cb@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <a198dd8e-cced-53d8-ed33-393f9a878c67@citrix.com>
Date: Fri, 17 Apr 2020 20:51:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <7aa11566-289c-41c2-ec90-c15e0a6490cb@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>, Wei
 Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17/04/2020 15:26, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2376,7 +2376,6 @@ void sh_reset_l3_up_pointers(struct vcpu
>  static void sh_update_paging_modes(struct vcpu *v)
>  {
>      struct domain *d = v->domain;
> -    const struct paging_mode *old_mode = v->arch.paging.mode;
>  
>      ASSERT(paging_locked_by_me(d));
>  
> @@ -2421,11 +2420,14 @@ static void sh_update_paging_modes(struc
>      if ( v->arch.paging.mode )
>          v->arch.paging.mode->shadow.detach_old_tables(v);
>  
> +#ifdef CONFIG_HVM
>      if ( !is_pv_domain(d) )
>      {
>          ///
>          /// HVM guest
>          ///

Can we drop this comment while we're here?  The ifdef and
!is_pv_domain() are crystal clear.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 20:12:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 20:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPXLL-0005KJ-Qs; Fri, 17 Apr 2020 20:12:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=z9Py=6B=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jPXLK-0005KE-4H
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 20:12:06 +0000
X-Inumbo-ID: b48fae36-80e7-11ea-8d8e-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b48fae36-80e7-11ea-8d8e-12813bfff9fa;
 Fri, 17 Apr 2020 20:12:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587154325;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=gqFwEViAJgrKMTHTCOqBhD2phSQkPExre/t7MwiNmsU=;
 b=EZTuNK5qx/V4bvAtRAC5J5FdTWF9URTx0QHqeQ+8lX2HEwvZRoCiQJrD
 vyKLLZgfBVEa+Psvk/61XES7Sk5pKqrxLzxdl5cWWw2NEHn5fd2IOSQSK
 DiXUUYopuNB3ZEPXdqW21CaddCLDz5Xx5vSqYxf2SNjWyQxf0XAWKJj+t k=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: iU42E3VCpO6/vJVLQOQJpzcsgv/XOdSaJn+rqnOa5JUnpih7ZpTuhNlhIJtYjVGmLwkLnVakcH
 o2S0kvctXTJ10TrVIcwX0AkvzC9yR1U4dt8mJsAa+pD86jMxTBZvXBXpiHCCDpBIqrPC4iFGWA
 AKTXYInR/ksw6bCtOAN98Q2mTBwsoCYX01lGfcTTFzzNT0VdWuTuAQZaeSbUZJJdFFVrwHaqZD
 1nysmVzQvlYLiOLL6kqKcdPJfrXqAH/9LXh4d9eUn8W6eO+qwgOdlpJW7sa68ffgJVY/V8m/AL
 fmQ=
X-SBRS: 2.7
X-MesageID: 15849234
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,395,1580792400"; d="scan'208";a="15849234"
Subject: Re: [PATCH 00/10] x86: mm (mainly shadow) adjustments
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <ab717c57-2533-51fb-b14a-7bd19e2fe700@citrix.com>
Date: Fri, 17 Apr 2020 21:12:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17/04/2020 15:23, Jan Beulich wrote:
> Large parts of this series are to further isolate pieces which
> are needed for HVM only, and hence would better not be built
> with HVM=n. But there are also a few other items which I've
> noticed along the road.
>
> 01: mm: no-one passes a NULL domain to init_xen_l4_slots()
> 02: shadow: drop a stray forward structure declaration
> 03: shadow: monitor table is HVM-only
> 04: shadow: sh_update_linear_entries() is a no-op for PV
> 05: mm: monitor table is HVM-only
> 06: shadow: sh_remove_write_access_from_sl1p() can be static
> 07: shadow: the guess_wrmap() hook is needed for HVM only
> 08: mm: pagetable_dying() is HVM-only
> 09: shadow: the trace_emul_write_val() hook is HVM-only
> 10: shadow: don't open-code shadow_blow_tables_per_domain()

Patch 1 I think ought to be dropped.  Everything else Acked-by: Andrew
Cooper <andrew.cooper3@citrix.com>, ideally with the suggested tweak in
patch 3.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 22:16:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPZHR-0006fb-Mt; Fri, 17 Apr 2020 22:16:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcYo=6B=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jPZHQ-0006fW-E3
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 22:16:12 +0000
X-Inumbo-ID: 0b924700-80f9-11ea-b58d-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0b924700-80f9-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 22:16:12 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 1F32220656;
 Fri, 17 Apr 2020 22:16:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587161771;
 bh=gb3Z9a2VrqqwohrS52ctiZQwXXCEVwx1D9sYthQAaBA=;
 h=From:To:Cc:Subject:Date:From;
 b=rCo8cU3hxVvD+j2afiY73LvWzbGWr81CAXYZXvJloPVc2WLXNBApK7OE1L8avdFAu
 DM8KWKwmgCfsD2KZ3vYgRsfIt/CrbWkqXsG45TJeqZEOnVFGmiMHcLDVdX6VQRY3xc
 s6OMUUMjpT/MvOXkqSuevESQd9B7FDK1UYj2wDVQ=
From: Stefano Stabellini <sstabellini@kernel.org>
To: julien@xen.org
Subject: [PATCH][RESEND] xen/arm: vgic-v3: fix GICD_ISACTIVER range
Date: Fri, 17 Apr 2020 15:16:09 -0700
Message-Id: <20200417221609.19928-1-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Peng Fan <peng.fan@nxp.com>,
 sstabellini@kernel.org, Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Peng Fan <peng.fan@nxp.com>

The end should be GICD_ISACTIVERN not GICD_ISACTIVER.

(See https://marc.info/?l=xen-devel&m=158527653730795 for a discussion on
what it would take to implement GICD_ISACTIVER/GICD_ICACTIVER properly.)

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

---
 xen/arch/arm/vgic-v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4e60ba15cc..fd8cfc156d 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -713,7 +713,7 @@ static int __vgic_v3_distr_common_mmio_read(const char *name, struct vcpu *v,
         goto read_as_zero;
 
     /* Read the active status of an IRQ via GICD/GICR is not supported */
-    case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVER):
+    case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
     case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
         goto read_as_zero;
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 22:24:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 22:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPZPX-0007WZ-Jw; Fri, 17 Apr 2020 22:24:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcYo=6B=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jPZPW-0007WU-Is
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 22:24:34 +0000
X-Inumbo-ID: 3607e930-80fa-11ea-8da7-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3607e930-80fa-11ea-8da7-12813bfff9fa;
 Fri, 17 Apr 2020 22:24:32 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id ADE7620776;
 Fri, 17 Apr 2020 22:24:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587162272;
 bh=cN63QuJZ8sbvvVXA8yUyWE0xtwrSWuim3k/SqZ0/+6s=;
 h=From:To:Cc:Subject:Date:From;
 b=1nsPArcMvOrzXecHYcu/RaV5/lggz+hPIY5Lox0FWfn3kyDwzeiXIesyIADqYyaKQ
 9nl1oDEONHt6jCqyjB+p9JSoZhqn0n5luoIYD7TIprldDWL4sp8uwQOv3r5sMQapaY
 m9CA0pb0RhC42igYiWTBIVGCGpqty/ygXFPLVZD4=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v3] Introduce a description of the Backport and Fixes tags
Date: Fri, 17 Apr 2020 15:24:30 -0700
Message-Id: <20200417222430.20480-1-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, sstabellini@kernel.org, julien@xen.org,
 Wei Liu <wl@xen.org>, konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, george.dunlap@citrix.com,
 jbeulich@suse.com, Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Create a new document under docs/process to describe our special tags.
Add a description of the Fixes tag and the new Backport tag. Also
clarify that lines with tags should not be split.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wl@xen.org>
CC: jbeulich@suse.com
CC: george.dunlap@citrix.com
CC: julien@xen.org
CC: lars.kurth@citrix.com
CC: andrew.cooper3@citrix.com
CC: konrad.wilk@oracle.com
---
Removing Acks as I added the description of "Fixes"
---
 docs/process/tags.pandoc | 55 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 docs/process/tags.pandoc

diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
new file mode 100644
index 0000000000..06b06dda01
--- /dev/null
+++ b/docs/process/tags.pandoc
@@ -0,0 +1,55 @@
+Tags: No line splitting
+-----------------------
+Do not split a tag across multiple lines, tags are exempt from the
+"wrap at 75 columns" rule in order to simplify parsing scripts.  For
+example:
+
+        Fixes: 67d01cdb5 ("x86: infrastructure to allow converting certain indirect calls to direct ones")
+
+
+Fixes Tag
+---------
+
+If your patch fixes a bug in a specific commit, e.g. you found an issue using
+``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
+the SHA-1 ID, and the one line summary.
+
+The following ``git config`` settings can be used to add a pretty format for
+outputting the above style in the ``git log`` or ``git show`` commands:
+
+        [core]
+                abbrev = 12
+        [pretty]
+                fixes = Fixes: %h (\"%s\")
+
+
+Backport Tag
+------------
+
+A backport tag is an optional tag in the commit message to request a
+given commit to be backported to the stable trees:
+
+    Backport: 4.9+
+
+It marks a commit for being a candidate for backports to all stable
+trees from 4.9 onward.
+
+The backport requester is expected to specify which currently supported
+releases need the backport; but encouraged to specify a release as far
+back as possible which applies. If the requester doesn't know the oldest
+affected tree, they are encouraged to append a comment like the
+following:
+
+    Backport: 4.9+ # maybe older
+
+Maintainers request the Backport tag to be added on commit. Contributors
+are welcome to mark their patches with the Backport tag when they deem
+appropriate. Maintainers will request for it to be removed when that is
+not the case.
+
+Please note that the Backport tag is a **request** for backport, which
+will still need to be evaluated by the stable tree maintainers.
+Maintainers might ask the requester to help with the backporting work if
+it is not trivial.
+
+When possible, please use the Fixes tag instead.
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 17 22:47:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 22:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPZl7-0000nY-Lw; Fri, 17 Apr 2020 22:46:53 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=piBF=6B=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPZl6-0000nT-FP
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 22:46:52 +0000
X-Inumbo-ID: 5018c418-80fd-11ea-8dae-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5018c418-80fd-11ea-8dae-12813bfff9fa;
 Fri, 17 Apr 2020 22:46:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=7B0JaLSnuVR+YBO5eh9cqWYvTIRBL//OpTLnADWx+xA=; b=0zSY2mMJaQ30Ug0mCluxTF8uh
 OPFjenIrm61R/xP7Ma9ykb4afZ0krbl60urtrhDrIlXRyrlommV2cS+Vxto0KYqP5Nrlu4GuoMgrE
 dq7z6jr4F6h3Xbr+/dmNL6R7YQ5XSPIxB2Ll2xpqLIzIqMzT+rJziK7BMdQfLD8QghaLU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPZky-0006gC-Gh; Fri, 17 Apr 2020 22:46:44 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPZky-0006sP-83; Fri, 17 Apr 2020 22:46:44 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPZky-0003Rq-7N; Fri, 17 Apr 2020 22:46:44 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149701-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.11-testing test] 149701: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=96a8b5bc48be2ae9691369849036453f8850135b
X-Osstest-Versions-That: xen=d353f82b2edae3019b0b9405976a05f18d120ce7
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 17 Apr 2020 22:46:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass

version targeted for testing:
 xen                  96a8b5bc48be2ae9691369849036453f8850135b
baseline version:
 xen                  d353f82b2edae3019b0b9405976a05f18d120ce7

Last test of basis   149651  2020-04-14 13:35:44 Z    3 days
Testing same since   149701  2020-04-17 12:06:32 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   d353f82b2e..96a8b5bc48  96a8b5bc48be2ae9691369849036453f8850135b -> stable-4.11


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 22:51:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 22:51:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPZpR-0001cg-CZ; Fri, 17 Apr 2020 22:51:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=r7J8=6B=gmail.com=julien.grall.oss@srs-us1.protection.inumbo.net>)
 id 1jPZpQ-0001cb-9x
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 22:51:20 +0000
X-Inumbo-ID: f37b5cec-80fd-11ea-b58d-bc764e2007e4
Received: from mail-wr1-x42c.google.com (unknown [2a00:1450:4864:20::42c])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f37b5cec-80fd-11ea-b58d-bc764e2007e4;
 Fri, 17 Apr 2020 22:51:19 +0000 (UTC)
Received: by mail-wr1-x42c.google.com with SMTP id t14so4781765wrw.12
 for <xen-devel@lists.xenproject.org>; Fri, 17 Apr 2020 15:51:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=r3PsbtqPjNhGMvcmhOuB1O8bVlsofWGA32h2HvSAUH4=;
 b=Zuosua/2vhlvLM5TS9x3eJrKKRPnMxMqcBO2E0vRelvhNy68Z29I1CCnVa/3PHJ72b
 sY35vWoP6vZR2OStJsVfAhwowLVvjrVADy/Le2cyChwAb8h5wVx7dYgyMtwappk97lVl
 s68o61X9VxoFa9T5wydFO8kh88DUVewUY7eDA5+k3JXIi/YJzUu/RdUp3XtdqWB+7rkL
 8h/gOf5xnkJ5JzpsG5P3XfMn11DMKQuPfNMVBINm6CN7miL7m5yuVxyaqVfUAPGOCSaj
 73RYBE+zxkA9QIn6k20ZyVXbZ4+Wzt1jZikz6IJbbb0n+Xt9Rj825A8n5nSUWvnshf5n
 kIuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=r3PsbtqPjNhGMvcmhOuB1O8bVlsofWGA32h2HvSAUH4=;
 b=XuJ7zS7NE1eXcrMsagCtYfOa5OpS1J8K/6goosN9MN52lb8Tn2s1hwTXVyeVDZ/IKA
 lJgyB91laTn/9sBWtl1GknW6elj+EsDj6TyN1fdcDPSpN4Wz/WI3s8S4DFWYTHPm8kxX
 XyAdTytGCQhIK8+58msZjB6rgi1TQq01p0nUlsOokqHR/kRSE013NO4V/58Z83IKjeX0
 QQccKwtj1zAFICDntBHH/UrCo3ZCzkeKMcu+oc5l3XNsrYOoAA0su4rpTf8Tx4yFRJ0z
 uA3uPkfbBonMsV1dQ3cQ4xm+ZKPN6FxCEO6ksTxO/D45xDmDCNGaRVRjDCxw2wng3Wd1
 6jfg==
X-Gm-Message-State: AGi0PubLOXvUjhvvcO6WMX5Urlfye+MIxwpUtTsdC5YyXsTFb73C2eCv
 SaRgLYTHIzP6ywet6VHR9prZ+u9HH7JG0UnpcUA=
X-Google-Smtp-Source: APiQypJC1Jpy8ygtBYdhcm+mTVyw5//BpBUPhLshm4Zk5fFpy1SlEAWGZnaM4QpvXWYG8Q9oIM/FWcJeFLE+c2Zoqx8=
X-Received: by 2002:adf:f30c:: with SMTP id i12mr6525380wro.426.1587163878490; 
 Fri, 17 Apr 2020 15:51:18 -0700 (PDT)
MIME-Version: 1.0
References: <20200417221609.19928-1-sstabellini@kernel.org>
In-Reply-To: <20200417221609.19928-1-sstabellini@kernel.org>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Fri, 17 Apr 2020 23:51:07 +0100
Message-ID: <CAJ=z9a2yCLfOGChD8YL3K7H50spGyifcpeLq_dz_T7aFV8VGQQ@mail.gmail.com>
Subject: Re: [PATCH][RESEND] xen/arm: vgic-v3: fix GICD_ISACTIVER range
To: Stefano Stabellini <sstabellini@kernel.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Peng Fan <peng.fan@nxp.com>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

The title claim this is a resend, but this is actually not the latest
version of this patch. Can you explain why you decided to use v1
rather than v2?

On Fri, 17 Apr 2020 at 23:16, Stefano Stabellini <sstabellini@kernel.org> wrote:
>
> From: Peng Fan <peng.fan@nxp.com>
>
> The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
>
> (See https://marc.info/?l=xen-devel&m=158527653730795 for a discussion on
> what it would take to implement GICD_ISACTIVER/GICD_ICACTIVER properly.)
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

I don't think you can be at the same time an author of the patch and a
reviewer. Otherwise, I could review my own patch ;).

Cheers,


From xen-devel-bounces@lists.xenproject.org Fri Apr 17 23:12:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Apr 2020 23:12:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPaA2-0003JN-5q; Fri, 17 Apr 2020 23:12:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JcYo=6B=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jPaA1-0003JI-1V
 for xen-devel@lists.xenproject.org; Fri, 17 Apr 2020 23:12:37 +0000
X-Inumbo-ID: ece74bae-8100-11ea-9e09-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ece74bae-8100-11ea-9e09-bc764e2007e4;
 Fri, 17 Apr 2020 23:12:36 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id C526C214D8;
 Fri, 17 Apr 2020 23:12:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587165156;
 bh=hJjcLQ+PXT3NI0+b9gpDpkrXj4Fq+8d8vEQZHQE57uA=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=qtt/Z6E4r+El/eAJJvSQ/lkUiXU/NcNFqKTDpaE61QE5VbYyPfWYmVaSuu25T5mJp
 4ZgildUnB4f63bWElsxuzCOgKZoG2Ts1GIwtkQxew9No4lNHC/o/ulkWT7wxSqpOD7
 Mlom/nkjjWD760X86LbyRpUmFk0h434ofUHb+Xug=
Date: Fri, 17 Apr 2020 16:12:30 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien.grall.oss@gmail.com>
Subject: Re: [PATCH][RESEND] xen/arm: vgic-v3: fix GICD_ISACTIVER range
In-Reply-To: <CAJ=z9a2yCLfOGChD8YL3K7H50spGyifcpeLq_dz_T7aFV8VGQQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2004171600580.32540@sstabellini-ThinkPad-T480s>
References: <20200417221609.19928-1-sstabellini@kernel.org>
 <CAJ=z9a2yCLfOGChD8YL3K7H50spGyifcpeLq_dz_T7aFV8VGQQ@mail.gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Peng Fan <peng.fan@nxp.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 17 Apr 2020, Julien Grall wrote:
> Hi,
> 
> The title claim this is a resend, but this is actually not the latest
> version of this patch. Can you explain why you decided to use v1
> rather than v2?

Because v2 added a printk for every read, and I thought you only wanted
the range fix. Also, the printk is not a "warn once" so after the
discussion where it became apparent that the register can be read many
times, it sounded undesirable.

Nonetheless I don't have a strong preference between the two. If you
prefer v2 it is here:

https://marc.info/?l=xen-devel&m=157440872522065

Do you need me to resent it? If it is OK for you as-is, you can give
your ack here, and I'll go ahead and commit it.


> On Fri, 17 Apr 2020 at 23:16, Stefano Stabellini <sstabellini@kernel.org> wrote:
> >
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
> >
> > (See https://marc.info/?l=xen-devel&m=158527653730795 for a discussion on
> > what it would take to implement GICD_ISACTIVER/GICD_ICACTIVER properly.)
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> I don't think you can be at the same time an author of the patch and a
> reviewer. Otherwise, I could review my own patch ;).

Yeah ... that was not the intention. I changed the commit message so I
had to add my signed-off-by for copyright reasons. At the same time I
reviewed it even before changing the commit message so I added the
reviewed-by. I agree it looks kind of weird. 


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 04:15:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 04:15:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPetL-0005Y0-0E; Sat, 18 Apr 2020 04:15:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=msmW=6C=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPetJ-0005Xv-NP
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 04:15:41 +0000
X-Inumbo-ID: 3cb6c1bc-812b-11ea-8df1-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3cb6c1bc-812b-11ea-8df1-12813bfff9fa;
 Sat, 18 Apr 2020 04:15:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=1V0xlbgADfZEfJmortD7OzNxPRA847kz1Dsjcewzy5U=; b=PHua7A0HU7UPjqENb3tQ00AK3
 t9/YNWn3xNLJCJuaSVDts1guuMPw6QEFsWy3bjIi/YnR4enGrLa2d8OO0Mj2gofHtqKO9TeUWwwqc
 b5EBC7/cf9tSMErPuVJ9cFQlFqlWtS7kN7Kaj3vWeECCbR4Og/sLaKv7IrKlGVHjcAHaA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPet6-0007Bn-QR; Sat, 18 Apr 2020 04:15:28 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPet6-0000Go-HO; Sat, 18 Apr 2020 04:15:28 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPet6-0006Q1-EN; Sat, 18 Apr 2020 04:15:28 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149702-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149702: trouble: broken/fail/pass
X-Osstest-Failures: xen-unstable:test-amd64-i386-libvirt:<job
 status>:broken:regression
 xen-unstable:test-amd64-i386-libvirt:host-install(4):broken:regression
 xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
X-Osstest-Versions-That: xen=a48e1323f9aa29f1ffb95594671b73de6bd7c1d4
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 18 Apr 2020 04:15:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt         <job status>                 broken
 test-amd64-i386-libvirt       4 host-install(4)        broken REGR. vs. 149695

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

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

version targeted for testing:
 xen                  82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
baseline version:
 xen                  a48e1323f9aa29f1ffb95594671b73de6bd7c1d4

Last test of basis   149695  2020-04-17 04:16:59 Z    0 days
Testing same since   149702  2020-04-17 13:36:57 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dfaggioli@suse.com>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Sergey Dyasli <sergey.dyasli@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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

broken-job test-amd64-i386-libvirt broken
broken-step test-amd64-i386-libvirt host-install(4)

Not pushing.

------------------------------------------------------------
commit 82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
Author: Sergey Dyasli <sergey.dyasli@citrix.com>
Date:   Fri Apr 17 09:28:16 2020 +0200

    sched: fix scheduler_disable() with core scheduling
    
    In core-scheduling mode, Xen might crash when entering ACPI S5 state.
    This happens in sched_slave() during is_idle_unit(next) check because
    next->vcpu_list is stale and points to an already freed memory.
    
    This situation happens shortly after scheduler_disable() is called if
    some CPU is still inside sched_slave() softirq. Current logic simply
    returns prev->next_task from sched_wait_rendezvous_in() which causes
    the described crash because next_task->vcpu_list has become invalid.
    
    Fix the crash by returning NULL from sched_wait_rendezvous_in() in
    the case when scheduler_disable() has been called.
    
    Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Dario Faggioli <dfaggioli@suse.com>

commit ee97008433f15e60478058c8ace514b939b6f862
Author: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Date:   Fri Apr 17 09:27:21 2020 +0200

    sched/core: fix bug when moving a domain between cpupools
    
    For each UNIT, sched_set_affinity is called before unit->priv is updated
    to the new cpupool private UNIT data structure. The issue is
    sched_set_affinity will call the adjust_affinity method of the cpupool.
    If defined, the new cpupool may use unit->priv (e.g. credit), which at
    this point still references the old cpupool private UNIT data structure.
    
    This change fixes the bug by moving the switch of unit->priv earler in
    the function.
    
    Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Acked-by: Dario Faggioli <dfaggioli@suse.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 07:55:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 07:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPiJt-0006dN-JV; Sat, 18 Apr 2020 07:55:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=msmW=6C=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jPiJr-0006dI-WD
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 07:55:20 +0000
X-Inumbo-ID: edd41cec-8149-11ea-8e1d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id edd41cec-8149-11ea-8e1d-12813bfff9fa;
 Sat, 18 Apr 2020 07:55:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ljU8mZ2CmV+qBMdtfBGnamAmoWcTov2AKMT9tweyP+Q=; b=1QLBUfYs101hdaW+yPE/p8QNR
 +o0g6cRu5eNfqzUfGdI4klIyqmH3QCS5aMmevSF/88MSbeSZkudk5Ce5+jDges+UFIewyaEsxzMFb
 50ndc5atPM1f3AXv0pgEPDjs2UJ5QX43bqS0J+lq5Emp4J111I2zzA2w7uYrwKSxlZPNw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPiJi-0003IR-RX; Sat, 18 Apr 2020 07:55:10 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jPiJi-0000PD-J0; Sat, 18 Apr 2020 07:55:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jPiJi-0004qz-I3; Sat, 18 Apr 2020 07:55:10 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149703-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149703: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:heisenbug
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=7a56db0299f9d43b4fe076838150c5cc293df131
X-Osstest-Versions-That: linux=9786cab674574239b04df638f825ee0e7d76a48c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 18 Apr 2020 07:55:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-examine    4 memdisk-try-append fail in 149697 pass in 149703
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail pass in 149697

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149693

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 149697 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149693
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149693
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149693
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149693
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149693
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149693
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149693
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149693
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                7a56db0299f9d43b4fe076838150c5cc293df131
baseline version:
 linux                9786cab674574239b04df638f825ee0e7d76a48c

Last test of basis   149693  2020-04-16 19:59:31 Z    1 days
Testing same since   149697  2020-04-17 07:30:41 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexei Starovoitov <ast@kernel.org>
  Amol Grover <frextrite@gmail.com>
  Andrew Lunn <andrew@lunn.ch>
  Andrey Ignatov <rdna@fb.com>
  Andrii Nakryiko <andriin@fb.com>
  Arnd Bergmann <arnd@arndb.de>
  Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
  Björn Töpel <bjorn.topel@gmail.com>
  Björn Töpel <bjorn.topel@intel.com>
  Cambda Zhu <cambda@linux.alibaba.com>
  Chen-Yu Tsai <wens@csie.org>
  Christophe JAILLET <christophe.jaillet@wanadoo.fr>
  Clemens Gruber <clemens.gruber@pqgruber.com>
  Colin Ian King <colin.king@canonical.com>
  Dan Carpenter <dan.carpenter@oracle.com>
  Daniel Borkmann <daniel@iogearbox.net>
  Daniel T. Lee <danieltimlee@gmail.com>
  David Ahern <dsahern@gmail.com>
  David Howells <dhowells@redhat.com>
  David S. Miller <davem@davemloft.net>
  DENG Qingfang <dqfext@gmail.com>
  Dmytro Linkin <dmitrolin@mellanox.com>
  Eli Cohen <eli@mellanox.com>
  Enric Balletbo i Serra <enric.balletbo@collabora.com>
  Eran Ben Elisha <eranbe@mellanox.com>
  Eric Dumazet <edumazet@google.com>
  Florian Fainelli <f.fainelli@gmail.com>
  Florian Westphal <fw@strlen.de>
  Frank Wunderlich <frank-w@public-files.de>
  Fugang Duan <fugang.duan@nxp.com>
  Gilberto Bertin <me@jibi.io>
  Jakub Kicinski <kuba@kernel.org>
  Jakub Sitnicki <jakub@cloudflare.com>
  Jason Gunthorpe <jgg@mellanox.com>
  Jason Yan <yanaijie@huawei.com>
  Jeremy Cline <jcline@redhat.com>
  Joe Stringer <joe@wand.net.nz>
  Johan Jonker <jbx6244@gmail.com>
  Johannes Berg <johannes.berg@intel.com>
  Jon Maloy <jmaloy@redhat.com>
  Jonathan Lemon <jonathan.lemon@gmail.com>
  Ka-Cheong Poon <ka-cheong.poon@oracle.com>
  Kalle Valo <kvalo@codeaurora.org>
  Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
  KP Singh <kpsingh@google.com>
  Li RongQing <lirongqing@baidu.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lothar Rubusch <l.rubusch@gmail.com>
  Luke Nelson <luke.r.nels@gmail.com>
  Luke Nelson <lukenels@cs.washington.edu>
  Maciej Żenczykowski <maze@google.com>
  Magnus Karlsson <magnus.karlsson@intel.com>
  Martin Fuzzey <martin.fuzzey@flowbird.group>
  Martin KaFai Lau <kafai@fb.com>
  Matteo Croce <mcroce@redhat.com>
  Michael Weiß <michael.weiss@aisec.fraunhofer.de>
  Moshe Shemesh <moshe@mellanox.com>
  Pablo Neira Ayuso <pablo@netfilter.org>
  Parav Pandit <parav@mellanox.com>
  Paul Blakey <paulb@mellanox.com>
  Qiujun Huang <hqjagain@gmail.com>
  Rafał Miłecki <rafal@milecki.pl>
  Randy Dunlap <rdunlap@infradead.org>
  René van Dorst <opensource@vdorst.com>
  Rob Herring <robh@kernel.org>
  Roi Dayan <roid@mellanox.com>
  Roman Mashak <mrv@mojatatu.com>
  Russell King <rmk+kernel@armlinux.org.uk>
  Saeed Mahameed <saeedm@mellanox.com>
  Santosh Shilimkar <santosh.shilimkar@oracle.com>
  Sean Wang <sean.wang@mediatek.com>
  Sebastian Andrzej Siewior <bigeasy@linutronix.de>
  Shannon Nelson <snelson@pensando.io>
  Slava Bacherikov <slava@bacher09.org>
  Song Liu <songliubraving@fb.com>
  Stefano Brivio <sbrivio@redhat.com>
  Sumit Garg <sumit.garg@linaro.org>
  Taehee Yoo <ap420073@gmail.com>
  Tamizh chelvam <tamizhr@codeaurora.org>
  Taras Chornyi <taras.chornyi@plvision.eu>
  Tim Stallard <code@timstallard.me.uk>
  Toke Høiland-Jørgensen <toke@redhat.com>
  Tom Lendacky <thomas.lendacky@amd.com>
  Trond Myklebust <trond.myklebust@hammerspace.com>
  Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
  Tuong Lien <tuong.t.lien@dektech.com.au>
  Vadym Kochan <vadym.kochan@plvision.eu>
  Vladimir Oltean <vladimir.oltean@nxp.com>
  Wang Wenhu <wenhu.wang@vivo.com>
  Xi Wang <xi.wang@gmail.com>
  YueHaibing <yuehaibing@huawei.com>
  Zou Wei <zou_wei@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            fail    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   9786cab67457..7a56db0299f9  7a56db0299f9d43b4fe076838150c5cc293df131 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 08:57:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 08:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPjHR-0003Xi-VB; Sat, 18 Apr 2020 08:56:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=kcTk=6C=xen.org=tim@srs-us1.protection.inumbo.net>)
 id 1jPjHQ-0003Xd-1o
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 08:56:52 +0000
X-Inumbo-ID: 8ad19d5a-8152-11ea-83d8-bc764e2007e4
Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8ad19d5a-8152-11ea-83d8-bc764e2007e4;
 Sat, 18 Apr 2020 08:56:51 +0000 (UTC)
Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD))
 (envelope-from <tim@xen.org>)
 id 1jPjHL-000O86-QX; Sat, 18 Apr 2020 08:56:47 +0000
Date: Sat, 18 Apr 2020 09:56:47 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 04/10] x86/shadow: sh_update_linear_entries() is a no-op
 for PV
Message-ID: <20200418085647.GC92478@deinos.phlegethon.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
 <e5457534-6491-b9be-e61d-d669a8e7656e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <e5457534-6491-b9be-e61d-d669a8e7656e@suse.com>
User-Agent: Mutt/1.11.1 (2018-12-01)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
 SAEximRunCond expanded to false
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

At 16:26 +0200 on 17 Apr (1587140817), Jan Beulich wrote:
> Consolidate the shadow_mode_external() in here: Check this once at the
> start of the function.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -3707,34 +3707,30 @@ sh_update_linear_entries(struct vcpu *v)
>       */

This looks good.  Can you please also delete the out-of-date comment
just above that talks about about PAE linear pagetables in PV guests,
to make it clear that PV guests don't need any maintenance here?

Cheers,

Tim.


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 09:03:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 09:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPjNh-0004PI-Mj; Sat, 18 Apr 2020 09:03:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=kcTk=6C=xen.org=tim@srs-us1.protection.inumbo.net>)
 id 1jPjNf-0004PD-HA
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 09:03:19 +0000
X-Inumbo-ID: 720ae38e-8153-11ea-b58d-bc764e2007e4
Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 720ae38e-8153-11ea-b58d-bc764e2007e4;
 Sat, 18 Apr 2020 09:03:18 +0000 (UTC)
Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD))
 (envelope-from <tim@xen.org>)
 id 1jPjNd-000O9E-9K; Sat, 18 Apr 2020 09:03:17 +0000
Date: Sat, 18 Apr 2020 10:03:17 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 07/10] x86/shadow: the guess_wrmap() hook is needed for
 HVM only
Message-ID: <20200418090317.GD92478@deinos.phlegethon.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
 <1e221192-7899-b60d-0280-b77ab5877772@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <1e221192-7899-b60d-0280-b77ab5877772@suse.com>
User-Agent: Mutt/1.11.1 (2018-12-01)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
 SAEximRunCond expanded to false
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

At 16:28 +0200 on 17 Apr (1587140897), Jan Beulich wrote:
> sh_remove_write_access() bails early for !external guests, and hence its
> building and thus the need for the hook can be suppressed altogether in
> !HVM configs.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

> @@ -366,6 +367,14 @@ int sh_validate_guest_entry(struct vcpu
>  extern int sh_remove_write_access(struct domain *d, mfn_t readonly_mfn,
>                                    unsigned int level,
>                                    unsigned long fault_addr);
> +#else
> +static inline int sh_remove_write_access(struct domain *d, mfn_t readonly_mfn,
> +                                         unsigned int level,
> +                                         unsigned long fault_addr)
> +{

Can we have an ASSERT(!shadow_mode_refcounts(d)) here, please,
matching the check that would have made it a noop before?

Cheers,

Tim.



From xen-devel-bounces@lists.xenproject.org Sat Apr 18 09:04:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 09:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPjOk-0004TO-1N; Sat, 18 Apr 2020 09:04:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=kcTk=6C=xen.org=tim@srs-us1.protection.inumbo.net>)
 id 1jPjOi-0004TI-RE
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 09:04:24 +0000
X-Inumbo-ID: 98fcdf4c-8153-11ea-b58d-bc764e2007e4
Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 98fcdf4c-8153-11ea-b58d-bc764e2007e4;
 Sat, 18 Apr 2020 09:04:24 +0000 (UTC)
Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD))
 (envelope-from <tim@xen.org>)
 id 1jPjOh-000O9o-BV; Sat, 18 Apr 2020 09:04:23 +0000
Date: Sat, 18 Apr 2020 10:04:23 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 00/10] x86: mm (mainly shadow) adjustments
Message-ID: <20200418090423.GE92478@deinos.phlegethon.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
User-Agent: Mutt/1.11.1 (2018-12-01)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
 SAEximRunCond expanded to false
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

At 16:23 +0200 on 17 Apr (1587140581), Jan Beulich wrote:
> Large parts of this series are to further isolate pieces which
> are needed for HVM only, and hence would better not be built
> with HVM=n. But there are also a few other items which I've
> noticed along the road.

Acked-by: Tim Deegan <tim@xen.org>
with two suggestions that I've sent separately.

Cheers,

Tim.


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 09:49:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 09:49:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPk6R-0007oA-Nq; Sat, 18 Apr 2020 09:49:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8kJB=6C=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPk6Q-0007o5-B2
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 09:49:34 +0000
X-Inumbo-ID: e82de844-8159-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e82de844-8159-11ea-b58d-bc764e2007e4;
 Sat, 18 Apr 2020 09:49:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=7fymu2QlK+KyWYQjKNKQ+iYld+MrrAymt1eIIKU97D4=; b=NFqRTJaO2EzRlKtoqWPJd6D4fT
 X84Qic93SleF0b62T1i/GfwOLE7OEvaCVASz9Cepq79qfrWQhQ3pT9hLLRYkWGURirimiA/dLm0/W
 OaA3dxtaitmvsbhxL0PtH0EGMGwWgpQ43aP3ngxFCsyXblT9mebTfdmfBjzWGVdoI70c=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPk6N-0005xw-UK; Sat, 18 Apr 2020 09:49:31 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPk6N-0001ZI-Mi; Sat, 18 Apr 2020 09:49:31 +0000
Subject: Re: [PATCH][RESEND] xen/arm: vgic-v3: fix GICD_ISACTIVER range
To: Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien.grall.oss@gmail.com>
References: <20200417221609.19928-1-sstabellini@kernel.org>
 <CAJ=z9a2yCLfOGChD8YL3K7H50spGyifcpeLq_dz_T7aFV8VGQQ@mail.gmail.com>
 <alpine.DEB.2.21.2004171600580.32540@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <aa8013f5-2209-ed0d-6ef4-e6a195bff75a@xen.org>
Date: Sat, 18 Apr 2020 10:49:29 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004171600580.32540@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Peng Fan <peng.fan@nxp.com>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 18/04/2020 00:12, Stefano Stabellini wrote:
> On Fri, 17 Apr 2020, Julien Grall wrote:
>> Hi,
>>
>> The title claim this is a resend, but this is actually not the latest
>> version of this patch. Can you explain why you decided to use v1
>> rather than v2?
> 
> Because v2 added a printk for every read, and I thought you only wanted
> the range fix. Also, the printk is not a "warn once" so after the
> discussion where it became apparent that the register can be read many
> times, it sounded undesirable.

You previously mentionned that you will use Peng's patch. From my 
perspective, this meant you are using the latest version of a patch not 
a previous one.

So this was a bit of a surprised to me.

> 
> Nonetheless I don't have a strong preference between the two. If you
> prefer v2 it is here:
> 
> https://marc.info/?l=xen-devel&m=157440872522065
I understand the "warn" issue but we did agree with it back then. I am 
ok to drop it. However, may I request to be more forthcoming in your 
patch in the future?

For instance in this case, this a link to the original patch and an 
explanation why you selected v1 would have been really useful.

> 
> Do you need me to resent it? If it is OK for you as-is, you can give
> your ack here, and I'll go ahead and commit it.
> 
> 
>> On Fri, 17 Apr 2020 at 23:16, Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>
>>> From: Peng Fan <peng.fan@nxp.com>
>>>
>>> The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
>>>
>>> (See https://marc.info/?l=xen-devel&m=158527653730795 for a discussion on
>>> what it would take to implement GICD_ISACTIVER/GICD_ICACTIVER properly.)
>>>
>>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>>
>> I don't think you can be at the same time an author of the patch and a
>> reviewer. Otherwise, I could review my own patch ;).
> 
> Yeah ... that was not the intention. I changed the commit message so I
> had to add my signed-off-by for copyright reasons.
> At the same time I
> reviewed it even before changing the commit message so I added the
> reviewed-by. I agree it looks kind of weird.

I don't feel this should go as-is. It is not clear in the commit message 
the changes you did and could lead confusion once merged. One may think 
you reviewed your own patch.

In general when I tweak a commit message, I will not add my 
signed-off-by but just add [julieng: Tweak commit message] above my 
reviewed-by/acked-by tag.

Alternatively, you can remove your reviewed-by and let another 
maintainer reviewing it.

I will let you decide your preference and resend the patch appropriately.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 10:24:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 10:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPkdv-0002aY-Jy; Sat, 18 Apr 2020 10:24:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8kJB=6C=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPkdu-0002aT-EB
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 10:24:10 +0000
X-Inumbo-ID: bc86a10f-815e-11ea-8e36-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bc86a10f-815e-11ea-8e36-12813bfff9fa;
 Sat, 18 Apr 2020 10:24:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=1vkxPKNWjP8nHZwNeJ+YXdvMNzuF34ibw8pEJZyuvls=; b=PplC0/ZREJy1c1h16zuZVUQ55p
 Bg1nnJV+asHdFAlWphq771jFTcICkjTNrG8be5zD0iqPQg1Bs0GFyntBXY5gRsm71RgbQyGQxpmXq
 qJZ8M0Vc0dFj2GoEG85dqDdriIVd1IO7bMhjiQn+LRKBjnu3Ir7srKtMFiAze8MIXjSE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPkdk-0006hb-J7; Sat, 18 Apr 2020 10:24:00 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPkdk-0003Rg-7G; Sat, 18 Apr 2020 10:24:00 +0000
Subject: Re: [PATCH 05/17] xen/x86: Remove the non-typesafe version of
 pagetable_* helpers
To: Jan Beulich <jbeulich@suse.com>
References: <20200322161418.31606-1-julien@xen.org>
 <20200322161418.31606-6-julien@xen.org>
 <b0d29ded-f0e8-013b-de43-22788cd8f599@suse.com>
 <2be87441-05a6-6b58-23e3-da467230ffe7@xen.org>
 <cf983d3e-125a-621a-f81d-2f9955ec86eb@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <f72f5c31-c437-549a-9d8b-8b836caf699b@xen.org>
Date: Sat, 18 Apr 2020 11:23:57 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <cf983d3e-125a-621a-f81d-2f9955ec86eb@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 30/03/2020 08:52, Jan Beulich wrote:
> On 28.03.2020 11:52, Julien Grall wrote:
>> On 26/03/2020 15:39, Jan Beulich wrote:
>>> On 22.03.2020 17:14, julien@xen.org wrote:
>>>> @@ -3116,24 +3116,24 @@ int vcpu_destroy_pagetables(struct vcpu *v)
>>>>          /* Free that page if non-zero */
>>>>        do {
>>>> -        if ( mfn )
>>>> +        if ( !mfn_eq(mfn, _mfn(0)) )
>>>
>>> I admit I'm not fully certain either, but at the first glance
>>>
>>>           if ( mfn_x(mfn) )
>>>
>>> would seem more in line with the original code to me (and then
>>> also elsewhere).
>>
>> It is doing *exactly* the same things. The whole point of typesafe
>> is to use typesafe helper not open-coding test everywhere.
>>
>> It is also easier to spot any use of MFN 0 within the code as you
>> know could grep "_mfn(0)".
>>
>> Therefore I will insist to the code as-is.
> 
> What I insit on is that readability of the result of such changes be
> also kept in mind. The mfn_eq() construct is (I think) clearly less
> easy to read and recognize than the simpler alternative suggested.

If mfn_eq() is less clear, then where do you draw the line when the 
macro should or not be used?

> If you want to avoid mfn_x(), how about introducing (if possible
> limited to x86, assuming that MFN 0 has no special meaning on Arm)
> mfn_zero()?

Zero has not special meaning on Arm, so we could limit to x86.

> 
>>>> @@ -3560,19 +3561,18 @@ long do_mmuext_op(
>>>>                if ( unlikely(rc) )
>>>>                    break;
>>>>    -            old_mfn = pagetable_get_pfn(curr->arch.guest_table_user);
>>>> +            old_mfn = pagetable_get_mfn(curr->arch.guest_table_user);
>>>>                /*
>>>>                 * This is particularly important when getting restarted after the
>>>>                 * previous attempt got preempted in the put-old-MFN phase.
>>>>                 */
>>>> -            if ( old_mfn == op.arg1.mfn )
>>>> +            if ( mfn_eq(old_mfn, new_mfn) )
>>>>                    break;
>>>>    -            if ( op.arg1.mfn != 0 )
>>>> +            if ( !mfn_eq(new_mfn, _mfn(0)) )
>>>
>>> At least here I would clearly prefer the old code to be kept.
>>
>> See above.
> 
> I don't agree - here you're evaluating an aspect of the public
> interface. MFN 0 internally having a special meaning is, while
> connected to this aspect, still an implementation detail.

Fair enough.

> 
>>>> @@ -3580,19 +3580,19 @@ long do_mmuext_op(
>>>>                        else if ( rc != -ERESTART )
>>>>                            gdprintk(XENLOG_WARNING,
>>>>                                     "Error %d installing new mfn %" PRI_mfn "\n",
>>>> -                                 rc, op.arg1.mfn);
>>>> +                                 rc, mfn_x(new_mfn));
>>>
>>> Here I'm also not sure I see the point of the conversion.
>>
>> op.arg1.mfn and mfn are technically not the same type. The
>> former is a xen_pfn_t, whilst the latter is mfn_t.
>>
>> In practice they are both unsigned long on x86, so it should
>> be fine to use PRI_mfn. However, I think this is an abuse
>> and we should aim to use the proper PRI_* for a type.
> 
> I'd be fine with switching to PRI_xen_pfn here, yes. But
> especially with the "not the same type" argument what should
> be logged is imo what was specified, not what we converted it
> to.

Fair point. I will switch back to op.arg1.mfn.

> 
>>>> @@ -213,17 +214,17 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, unsigned int flags)
>>>>    #ifndef __ASSEMBLY__
>>>>      /* Page-table type. */
>>>> -typedef struct { u64 pfn; } pagetable_t;
>>>> -#define pagetable_get_paddr(x)  ((paddr_t)(x).pfn << PAGE_SHIFT)
>>>> +typedef struct { mfn_t mfn; } pagetable_t;
>>>> +#define PAGETABLE_NULL_MFN      _mfn(0)
>>>
>>> I'd prefer to get away without this constant.
>> I would rather keep the constant as it makes easier to
>> understand what _mfn(0) means in the context of the pagetable.
> 
> If this was used outside of the accessor definitions, I'd
> probably agree. But the accessor definitions exist specifically
> to abstract away such things from use sites. Hence, bike-
> shedding or not, if Andrew was clearly agreeing with your view,
> I'd accept it. If he's indifferent, I'd prefer the #define to
> be dropped.

Andrew, do you have any opinion?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 10:54:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 10:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPl7N-00053p-5g; Sat, 18 Apr 2020 10:54:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8kJB=6C=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPl7L-00053k-VW
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 10:54:36 +0000
X-Inumbo-ID: fd8c1b8a-8162-11ea-8e3b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fd8c1b8a-8162-11ea-8e3b-12813bfff9fa;
 Sat, 18 Apr 2020 10:54:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=HSDBAEvJ7RUlXDXP2H48sMA6xVahTxTlM0FI7E2eZyE=; b=paZ1Fyuh8aotQMdB3iF+9wnzkg
 cR2Q+yNseUUff9F/3ucYG21KugeFSxEvafCXEeKdXW/qTqdM7WZHJOU2kyyHcACbJOYLbcg0ebs/f
 rlltHPwWc+GoQqCEWgq+nYMlQt/TvsxdS2VY8KCx8ENGuunNeMnpQcbgoFlh+Afxo81E=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPl7I-0007GG-N9; Sat, 18 Apr 2020 10:54:32 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPl7I-0005Mp-Fq; Sat, 18 Apr 2020 10:54:32 +0000
Subject: Re: [PATCH 06/17] xen/x86: mm: Fix the comment on top
 put_page_from_l2e() to use 'mfn'
To: Jan Beulich <jbeulich@suse.com>
References: <20200322161418.31606-1-julien@xen.org>
 <20200322161418.31606-7-julien@xen.org>
 <4f6d47dd-997d-977e-690d-7f21be2617a0@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <09bf5a4a-e60f-3f98-1a3d-00e4777665fa@xen.org>
Date: Sat, 18 Apr 2020 11:54:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <4f6d47dd-997d-977e-690d-7f21be2617a0@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 26/03/2020 15:51, Jan Beulich wrote:
> On 22.03.2020 17:14, julien@xen.org wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> We are using the 'mfn' to refer to machine frame. As this function deal
>> with 'mfn', replace 'pfn' with 'mfn'.
>>
>> Signed-off-by: Julien Grall <jgrall@amazon.com>
>>
>> ---
>>
>> I am not entirely sure to understand the comment on top of the
>> function, so this change may be wrong.
> 
> Looking at the history of the function, ...
> 
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -1321,7 +1321,7 @@ static int put_data_pages(struct page_info *page, bool writeable, int pt_shift)
>>   }
>>   
>>   /*
>> - * NB. Virtual address 'l2e' maps to a machine address within frame 'pfn'.
>> + * NB. Virtual address 'l2e' maps to a machine address within frame 'mfn'.
>>    * Note also that this automatically deals correctly with linear p.t.'s.
>>    */
>>   static int put_page_from_l2e(l2_pgentry_t l2e, mfn_t l2mfn, unsigned int flags)
> 
> ... it used to be
> 
> static int put_page_from_l2e(l2_pgentry_t l2e, unsigned long pfn)
> 
> When the rename occurred (in the context of or as a follow-up to an
> XSA iirc), the comment adjustment was apparently missed. With the
> referenced name matching that of the function argument (l2mfn)
> Acked-by: Jan Beulich <jbeulich@suse.com>

I will update the reference to use 'l2mfn' and also add a word that the 
comment was adjusted in ea51977a7aa5e645680a7194550fbceb59004ccf.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 11:01:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 11:01:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPlE8-0005uU-V9; Sat, 18 Apr 2020 11:01:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8kJB=6C=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPlE7-0005uK-KN
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 11:01:35 +0000
X-Inumbo-ID: f7b846c4-8163-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f7b846c4-8163-11ea-b4f4-bc764e2007e4;
 Sat, 18 Apr 2020 11:01:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=T0pf81C8tsobYNsvH2Fh3loQ0nS6jxdDTYbmC9/2MJw=; b=FQ5cl9zTgqZxGeNYb1dshsBeVR
 XfZewbmv5UmUlJMb/wMMbOrBCMeO36rw5Cbk5KuZnk1SIVwDiIvIa6qIVYn/LK/PKFW6vjxO92QlM
 F4qUbKm7bxIPQZbRPfjiUgpSbzm9V06s7qmlwFhjmKri+DKaCp5/u+z3P+l1OfAA0z3k=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPlE5-0007RU-8S; Sat, 18 Apr 2020 11:01:33 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPlE5-0006JO-13; Sat, 18 Apr 2020 11:01:33 +0000
Subject: Re: [PATCH 07/17] xen/x86: traps: Convert __page_fault_type() to use
 typesafe MFN
To: Jan Beulich <jbeulich@suse.com>
References: <20200322161418.31606-1-julien@xen.org>
 <20200322161418.31606-8-julien@xen.org>
 <12a955a3-d326-f5f9-f20b-69f3dafac238@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <527ec42b-1fcf-7e35-0ed7-b9da91a8c583@xen.org>
Date: Sat, 18 Apr 2020 12:01:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <12a955a3-d326-f5f9-f20b-69f3dafac238@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 26/03/2020 15:54, Jan Beulich wrote:
> On 22.03.2020 17:14, julien@xen.org wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> Note that the code is now using cr3_to_mfn() to get the MFN. This is
>> slightly different as the top 12-bits will now be masked.
> 
> And here I agree with the change. Hence it is even more so important
> that the patch introducing the new helper(s) first gets sorted.
> Should there be further patches in this series with this same
> interaction issue, I won't point it out again and may not respond at
> all if I see no other issues.

I will update the commit message explaining the reason of using 
cr3_to_mfn() and look at the other user.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 11:15:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 11:15:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPlR7-0006pp-61; Sat, 18 Apr 2020 11:15:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8kJB=6C=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPlR5-0006pk-Dn
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 11:14:59 +0000
X-Inumbo-ID: d716517a-8165-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d716517a-8165-11ea-b58d-bc764e2007e4;
 Sat, 18 Apr 2020 11:14:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=4sF/li1s1aznx4euBWkYr5XliRGisWmMxDp2HKyFP4U=; b=Q85lgQ67J6tQ2H08OuG5YpfmaX
 hnVNvNkAVLOZ98+v0t61kdGIXqYt+9CcCLs5FjoKiifz0QqjxU20Vfvh9JKof5fmA5C1NhkdWZ3Vg
 gCuxRQ4hMtitcuRRInEVO/pTqdt0fXDr+7jtMjis2wwQAgK8driwXxLzEwt93XrYq7q8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPlR3-0007g6-Ak; Sat, 18 Apr 2020 11:14:57 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPlR3-00070T-3O; Sat, 18 Apr 2020 11:14:57 +0000
Subject: Re: [PATCH 6/6] x86/mem-paging: consistently use gfn_t
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <224337b8-98b4-b0f6-a57a-6f508ffa6838@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <66d56fc4-11a3-6c43-5fbd-ef7039fd06f8@xen.org>
Date: Sat, 18 Apr 2020 12:14:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <224337b8-98b4-b0f6-a57a-6f508ffa6838@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 16/04/2020 16:48, Jan Beulich wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2151,16 +2151,17 @@ static int mod_l1_entry(l1_pgentry_t *pl
>                paging_mode_translate(pg_dom) )
>           {
>               p2m_type_t p2mt;
> +            unsigned long gfn = l1e_get_pfn(nl1e);

How about making gfn a gfn_t directly? This would avoid code churn when...

>               p2m_query_t q = l1e_get_flags(nl1e) & _PAGE_RW ?
>                               P2M_ALLOC | P2M_UNSHARE : P2M_ALLOC;
>   
> -            page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), &p2mt, q);
> +            page = get_page_from_gfn(pg_dom, gfn, &p2mt, q);

... I am going to convert get_page_from_gfn() to use typesafe gfn. See [1].

> @@ -89,16 +88,15 @@ void p2m_mem_paging_drop_page(struct dom
>    * already sent to the pager. In this case the caller has to try again until the
>    * gfn is fully paged in again.
>    */
> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn_l)
> +void p2m_mem_paging_populate(struct domain *d, gfn_t gfn)
>   {
>       struct vcpu *v = current;
>       vm_event_request_t req = {
>           .reason = VM_EVENT_REASON_MEM_PAGING,
> -        .u.mem_paging.gfn = gfn_l
> +        .u.mem_paging.gfn = gfn_x(gfn)
>       };
>       p2m_type_t p2mt;
>       p2m_access_t a;
> -    gfn_t gfn = _gfn(gfn_l);
>       mfn_t mfn;
>       struct p2m_domain *p2m = p2m_get_hostp2m(d);
>       int rc = vm_event_claim_slot(d, d->vm_event_paging);
> @@ -107,7 +105,7 @@ void p2m_mem_paging_populate(struct doma
>       if ( rc == -EOPNOTSUPP )
>       {
>           gdprintk(XENLOG_ERR, "Dom%d paging gfn %lx yet no ring in place\n",
> -                 d->domain_id, gfn_l);
> +                 d->domain_id, gfn_x(gfn));

Please use PRI_gfn in the format string to match the argument change.

Cheers,

[1] 
https://lore.kernel.org/xen-devel/20200322161418.31606-18-julien@xen.org/

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 11:44:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 11:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPlsy-0000pe-Gi; Sat, 18 Apr 2020 11:43:48 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=8kJB=6C=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jPlsx-0000pZ-Jy
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 11:43:47 +0000
X-Inumbo-ID: dc8fdfdc-8169-11ea-8e48-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id dc8fdfdc-8169-11ea-8e48-12813bfff9fa;
 Sat, 18 Apr 2020 11:43:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=0qgST8erGD8iAqhvKJgKSRe1X9VlBdr6bmS36yWatUc=; b=FGFzbN18TgXWbQpJt/SP9/54SG
 kvKaTmxza+zoZaFW7ffN71I9HSDgRHXDFvjFaQo8lEf105C+B7f3VaiGGAmTA3Xz/evElu6GeWBMm
 Qh9LHbP4VfnPXHQDK1VdiRoYB6IHoucXx5mDqERlUDbxPpeOt5m8un0OtPV3vHLygb7k=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPlsu-0008CO-8z; Sat, 18 Apr 2020 11:43:44 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jPlsu-0008OE-2J; Sat, 18 Apr 2020 11:43:44 +0000
Subject: Re: [PATCH 07/17] xen/x86: traps: Convert __page_fault_type() to use
 typesafe MFN
To: Jan Beulich <jbeulich@suse.com>
References: <20200322161418.31606-1-julien@xen.org>
 <20200322161418.31606-8-julien@xen.org>
 <12a955a3-d326-f5f9-f20b-69f3dafac238@suse.com>
 <527ec42b-1fcf-7e35-0ed7-b9da91a8c583@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <cb09a267-32b6-9ea3-1289-a1e20ec99746@xen.org>
Date: Sat, 18 Apr 2020 12:43:42 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <527ec42b-1fcf-7e35-0ed7-b9da91a8c583@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 18/04/2020 12:01, Julien Grall wrote:
> On 26/03/2020 15:54, Jan Beulich wrote:
>> On 22.03.2020 17:14, julien@xen.org wrote:
>>> From: Julien Grall <jgrall@amazon.com>
>>>
>>> Note that the code is now using cr3_to_mfn() to get the MFN. This is
>>> slightly different as the top 12-bits will now be masked.
>>
>> And here I agree with the change. Hence it is even more so important
>> that the patch introducing the new helper(s) first gets sorted.
>> Should there be further patches in this series with this same
>> interaction issue, I won't point it out again and may not respond at
>> all if I see no other issues.
> 
> I will update the commit message explaining the reason of using 
> cr3_to_mfn() and look at the other user.

Looking at the code again, there are a few users that don't mask the top 
12-bits. I am trying to understand why this has never been an issue so far.

Wouldn't it break when bit 63 (no flush) is set? If so, maybe I should 
split the work from typesafe.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 12:49:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 12:49:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPmtx-0005km-RV; Sat, 18 Apr 2020 12:48:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=bbfk=6C=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jPmtw-0005kd-0i
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 12:48:52 +0000
X-Inumbo-ID: f42d8dfc-8172-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f42d8dfc-8172-11ea-b58d-bc764e2007e4;
 Sat, 18 Apr 2020 12:48:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=tktXeVI11Y10hQs1qrLMwCmFVrk1+4IMVs9my8vm8D0=; b=rmZTVjXf73SjxVUXkgYHowkzBu
 WGgqoITsdX4A7TZT4N/bR8AHRuY7K0xF+Zhe8BZAMMKL/BW2q8l5zkBjSS7wO0a3V/jbka+PXEdbA
 XHqjVVdDrAAK70ZUIAroVA+9V1h7Wzea+PGrhiWbxBWZHSRpSC1We4QH1RknEXa4rK/I=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jPmtt-0000yV-O7; Sat, 18 Apr 2020 12:48:49 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jPmtt-0003Yw-DZ; Sat, 18 Apr 2020 12:48:49 +0000
Date: Sat, 18 Apr 2020 13:48:46 +0100
From: Wei Liu <wl@xen.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v3] Introduce a description of the Backport and Fixes tags
Message-ID: <20200418124846.kinsiggbw2e5v76t@debian>
References: <20200417222430.20480-1-sstabellini@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200417222430.20480-1-sstabellini@kernel.org>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, julien@xen.org, Wei Liu <wl@xen.org>,
 konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, george.dunlap@citrix.com,
 jbeulich@suse.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 03:24:30PM -0700, Stefano Stabellini wrote:
> Create a new document under docs/process to describe our special tags.
> Add a description of the Fixes tag and the new Backport tag. Also
> clarify that lines with tags should not be split.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> CC: Ian Jackson <ian.jackson@eu.citrix.com>
> CC: Wei Liu <wl@xen.org>
> CC: jbeulich@suse.com
> CC: george.dunlap@citrix.com
> CC: julien@xen.org
> CC: lars.kurth@citrix.com
> CC: andrew.cooper3@citrix.com
> CC: konrad.wilk@oracle.com

Acked-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Sat Apr 18 13:46:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Apr 2020 13:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jPnnV-00024r-Co; Sat, 18 Apr 2020 13:46:17 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=bbfk=6C=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jPnnU-00024m-05
 for xen-devel@lists.xenproject.org; Sat, 18 Apr 2020 13:46:16 +0000
X-Inumbo-ID: f88bb024-817a-11ea-8e72-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f88bb024-817a-11ea-8e72-12813bfff9fa;
 Sat, 18 Apr 2020 13:46:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=spdwGc0KgnbRB5gjjv05TunodJTNA0vnhyFB/SZ8hrM=; b=Daj1JSwmsZqnIW0W0iraqLtt1V
 VmRwPPtaAbZ0cQOKtADA6Q/EpooifLRgY1hFyRHbSPZyfv+UvTsw1z8/XloSkdLTzWlwf9tCdUPAe
 xYI+C9batrRQvfpKIl/Ud+vQYus0Koz1fwgbZNLZtLpAcMlAwRG9BfxgFET/zsYZ4P38=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jPnnS-00022e-0U; Sat, 18 Apr 2020 13:46:14 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jPnnR-0006i4-NO; Sat, 18 Apr 2020 13:46:13 +0000
Date: Sat, 18 Apr 2020 14:46:10 +0100
From: Wei Liu <wl@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 0/3] x86/pv: Start to trim 32bit support
Message-ID: <20200418134610.hlqcj7v3zoobjrvv@debian>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200417155004.16806-1-andrew.cooper3@citrix.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Xen-devel <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Jan Beulich <JBeulich@suse.com>,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 04:50:01PM +0100, Andrew Cooper wrote:
> Downstreams may want this for either security or performance reasons.  Offer
> some options, and take advantage of some of the very low hanging fruit it
> offers.
> 
> There is plenty more incremental cleanup which can be done at a later point.
> 
> Andrew Cooper (3):
>   x86/pv: Options to disable and/or compile out 32bit PV support
>   x86/pv: Short-circuit is_pv_{32,64}bit_domain() in !CONFIG_PV32 builds
>   x86/pv: Compile out compat_gdt in !CONFIG_PV builds

Reviewed-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Sun Apr 19 09:51:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Apr 2020 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQ6b0-0001sR-LB; Sun, 19 Apr 2020 09:50:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+3Jy=6D=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQ6az-0001sM-JB
 for xen-devel@lists.xenproject.org; Sun, 19 Apr 2020 09:50:37 +0000
X-Inumbo-ID: 36c3e1f6-8223-11ea-8f63-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 36c3e1f6-8223-11ea-8f63-12813bfff9fa;
 Sun, 19 Apr 2020 09:50:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=RH2hdVxOyk3fFCZM1TxXyP1c7ntIm63sYd3dwBS69VI=; b=LacVcxUyMPjVd2SrdDa7YJFKhK
 2JmWy+Qe5tWBKdRlhFG1e5s6V+2QjrHwLeMU3RCOahYVpKIOURuxrfTVRNTB/GjwRLk8TXMjzz3gR
 CEH6TCSFPboyh2hIE4q1PHcdACDZFGnYVDqKP5d+CjhDikCBCpjS1dQoVcUUgJY08i1I=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQ6av-00079V-My; Sun, 19 Apr 2020 09:50:33 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQ6av-0000QZ-A8; Sun, 19 Apr 2020 09:50:33 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] xen/arm: Avoid to open-code the relinquish state machine
Date: Sun, 19 Apr 2020 10:50:30 +0100
Message-Id: <20200419095030.2081-1-julien@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Julien Grall <jgrall@amazon.com>, Stefano Stabellini <sstabellini@kernel.org>,
 julien@xen.org, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In commit 0dfffe01d5 "x86: Improve the efficiency of
domain_relinquish_resources()", the x86 version of the function has been
reworked to avoid open-coding the state machine and also add more
documentation.

Bring the Arm version on part with x86 by introducing a documented
PROGRESS() macro to avoid latent bugs and make the new PROG_* states
private to domain_relinquish_resources().

Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/arch/arm/domain.c        | 60 ++++++++++++++++++++++--------------
 xen/include/asm-arm/domain.h |  9 +-----
 2 files changed, 38 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 6627be2922..31169326b2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -674,7 +674,6 @@ int arch_domain_create(struct domain *d,
     int rc, count = 0;
 
     BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
-    d->arch.relmem = RELMEM_not_started;
 
     /* Idle domains do not need this setup */
     if ( is_idle_domain(d) )
@@ -950,13 +949,41 @@ static int relinquish_memory(struct domain *d, struct page_list_head *list)
     return ret;
 }
 
+/*
+ * Record the current progress. Subsequent hypercall continuations will
+ * logically restart work from this point.
+ *
+ * PROGRESS() markers must not be in the middle of loops. The loop
+ * variable isn't preserved accross a continuation.
+ *
+ * To avoid redundant work, there should be a marker before each
+ * function which may return -ERESTART.
+ */
+enum {
+    PROG_tee = 1,
+    PROG_xen,
+    PROG_page,
+    PROG_mapping,
+    PROG_done,
+};
+
+#define PROGRESS(x)                         \
+    d->arch.rel_priv = PROG_ ## x;          \
+    /* Fallthrough */                       \
+    case PROG_ ## x
+
 int domain_relinquish_resources(struct domain *d)
 {
     int ret = 0;
 
-    switch ( d->arch.relmem )
+    /*
+     * This hypercall can take minutes of wallclock time to complete.  This
+     * logic implements a co-routine, stashing state in struct domain across
+     * hypercall continuation boundaries.
+     */
+    switch ( d->arch.rel_priv )
     {
-    case RELMEM_not_started:
+    case 0:
         ret = iommu_release_dt_devices(d);
         if ( ret )
             return ret;
@@ -967,42 +994,27 @@ int domain_relinquish_resources(struct domain *d)
          */
         domain_vpl011_deinit(d);
 
-        d->arch.relmem = RELMEM_tee;
-        /* Fallthrough */
-
-    case RELMEM_tee:
+    PROGRESS(tee):
         ret = tee_relinquish_resources(d);
         if (ret )
             return ret;
 
-        d->arch.relmem = RELMEM_xen;
-        /* Fallthrough */
-
-    case RELMEM_xen:
+    PROGRESS(xen):
         ret = relinquish_memory(d, &d->xenpage_list);
         if ( ret )
             return ret;
 
-        d->arch.relmem = RELMEM_page;
-        /* Fallthrough */
-
-    case RELMEM_page:
+    PROGRESS(page):
         ret = relinquish_memory(d, &d->page_list);
         if ( ret )
             return ret;
 
-        d->arch.relmem = RELMEM_mapping;
-        /* Fallthrough */
-
-    case RELMEM_mapping:
+    PROGRESS(mapping):
         ret = relinquish_p2m_mapping(d);
         if ( ret )
             return ret;
 
-        d->arch.relmem = RELMEM_done;
-        /* Fallthrough */
-
-    case RELMEM_done:
+    PROGRESS(done):
         break;
 
     default:
@@ -1012,6 +1024,8 @@ int domain_relinquish_resources(struct domain *d)
     return 0;
 }
 
+#undef PROGRESS
+
 void arch_dump_domain_info(struct domain *d)
 {
     p2m_dump_info(d);
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index d39477a939..d2142c6707 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -56,14 +56,7 @@ struct arch_domain
     struct vmmio vmmio;
 
     /* Continuable domain_relinquish_resources(). */
-    enum {
-        RELMEM_not_started,
-        RELMEM_tee,
-        RELMEM_xen,
-        RELMEM_page,
-        RELMEM_mapping,
-        RELMEM_done,
-    } relmem;
+    unsigned int rel_priv;
 
     struct {
         uint64_t offset;
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 19 10:50:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Apr 2020 10:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQ7WQ-00066z-CE; Sun, 19 Apr 2020 10:49:58 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=+3Jy=6D=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQ7WP-00066u-B6
 for xen-devel@lists.xenproject.org; Sun, 19 Apr 2020 10:49:57 +0000
X-Inumbo-ID: 81d4dc88-822b-11ea-8f6c-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 81d4dc88-822b-11ea-8f6c-12813bfff9fa;
 Sun, 19 Apr 2020 10:49:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=pyaiyR6L4SEuSUNV7H6kqDTjrLyJNv4ZxXTLj1xNjpU=; b=2QabZeEm/464+rrcVqpRbWq6H6
 WP3VEudpYNLbuKlMtjP3JI5ZslAwqOGHUO6kyp1BmvmlDpfWtS3LgvaZebfj8UO6b7dy7dIdNR4GK
 Rqo7vN2IIaXn+aVgnF60TSfbYIrcehp+yM3E9C8muWCBr40tQpm9RvIdFakuBMm+GBj8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQ7WN-0008Nz-LR; Sun, 19 Apr 2020 10:49:55 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQ7WN-0003bY-8v; Sun, 19 Apr 2020 10:49:55 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] pvcalls: Document explicitly the padding for all arches
Date: Sun, 19 Apr 2020 11:49:48 +0100
Message-Id: <20200419104948.31200-1-julien@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

The documentation of pvcalls only describes the padding for i386. This
is a bit odd as there are some implicit padding for 64-bit (e.g in
xen_pvcalls_release) and this doesn't cater other 32-bit arch.

Remove the #ifdef in the documentation to show the padding is present on
all arches and take the opportunity to describe the padding in the
public header as well.

Signed-off-by: Julien Grall <jgrall@amazon.com>

---

AFAICT, we cannot mandate the padding to be 0 as they are already
present.
---
 docs/misc/pvcalls.pandoc        | 8 --------
 xen/include/public/io/pvcalls.h | 4 ++++
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc
index 665dad556c..971cd8f4b1 100644
--- a/docs/misc/pvcalls.pandoc
+++ b/docs/misc/pvcalls.pandoc
@@ -246,9 +246,7 @@ The format is defined as follows:
     			uint32_t domain;
     			uint32_t type;
     			uint32_t protocol;
-    			#ifdef CONFIG_X86_32
     			uint8_t pad[4];
-    			#endif
     		} socket;
     		struct xen_pvcalls_connect {
     			uint64_t id;
@@ -257,16 +255,12 @@ The format is defined as follows:
     			uint32_t flags;
     			grant_ref_t ref;
     			uint32_t evtchn;
-    			#ifdef CONFIG_X86_32
     			uint8_t pad[4];
-    			#endif
     		} connect;
     		struct xen_pvcalls_release {
     			uint64_t id;
     			uint8_t reuse;
-    			#ifdef CONFIG_X86_32
     			uint8_t pad[7];
-    			#endif
     		} release;
     		struct xen_pvcalls_bind {
     			uint64_t id;
@@ -276,9 +270,7 @@ The format is defined as follows:
     		struct xen_pvcalls_listen {
     			uint64_t id;
     			uint32_t backlog;
-    			#ifdef CONFIG_X86_32
     			uint8_t pad[4];
-    			#endif
     		} listen;
     		struct xen_pvcalls_accept {
     			uint64_t id;
diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h
index cb8171275c..f6048ddc63 100644
--- a/xen/include/public/io/pvcalls.h
+++ b/xen/include/public/io/pvcalls.h
@@ -65,6 +65,7 @@ struct xen_pvcalls_request {
             uint32_t domain;
             uint32_t type;
             uint32_t protocol;
+            uint8_t pad[4];
         } socket;
         struct xen_pvcalls_connect {
             uint64_t id;
@@ -73,10 +74,12 @@ struct xen_pvcalls_request {
             uint32_t flags;
             grant_ref_t ref;
             uint32_t evtchn;
+            uint8_t pad[4];
         } connect;
         struct xen_pvcalls_release {
             uint64_t id;
             uint8_t reuse;
+            uint8_t pad[7];
         } release;
         struct xen_pvcalls_bind {
             uint64_t id;
@@ -86,6 +89,7 @@ struct xen_pvcalls_request {
         struct xen_pvcalls_listen {
             uint64_t id;
             uint32_t backlog;
+            uint8_t pad[4];
         } listen;
         struct xen_pvcalls_accept {
             uint64_t id;
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Sun Apr 19 11:26:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Apr 2020 11:26:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQ85e-0000uR-3N; Sun, 19 Apr 2020 11:26:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=giSJ=6D=mail.ru=santucco@srs-us1.protection.inumbo.net>)
 id 1jQ85c-0000uM-DU
 for xen-devel@lists.xenproject.org; Sun, 19 Apr 2020 11:26:20 +0000
X-Inumbo-ID: 94d3b598-8230-11ea-9e09-bc764e2007e4
Received: from f508.i.mail.ru (unknown [217.69.138.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 94d3b598-8230-11ea-9e09-bc764e2007e4;
 Sun, 19 Apr 2020 11:26:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru;
 s=mail2; 
 h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From;
 bh=CaFyn1nmOxXe+7cFZ3n7PQ9JD05+Y0FhK4h5nmEw45g=; 
 b=QbZ/eczIQvQ5vbYodZPFi9yoDpSMnAvY7PfqBLZYFiKthttCbh+JZUGzaFWiqARNMxBHdUCDhzfjrkldZ9xAeMTZtSmHUpPbTSidAHftnmCb5Ddp+ESTFNoKjQFfJxK/+V9jqOBygXHMXzBYJFfUWmaZaEZa6ckAbOP68w3Uuhs=;
Received: by f508.i.mail.ru with local (envelope-from <santucco@mail.ru>)
 id 1jQ85W-0007wG-Ec; Sun, 19 Apr 2020 14:26:14 +0300
Received: by e.mail.ru with HTTP;
	Sun, 19 Apr 2020 14:26:14 +0300
From: =?UTF-8?B?U2FudHVjY28=?= <santucco@mail.ru>
To: =?UTF-8?B?T2xla3NhbmRyIEFuZHJ1c2hjaGVua28=?=
 <oleksandr_andrushchenko@epam.com>
Subject: =?UTF-8?B?UmVbMl06IFtYZW4tZGV2ZWxdIFBWIERSTSBkb2Vzbid0IHdvcmsgd2l0aG91?=
 =?UTF-8?B?dCBhdXRvX3RyYW5zbGF0ZWRfcGh5c21hcCBmZWF0dXJlIGluIERvbTA=?=
MIME-Version: 1.0
X-Mailer: Mail.Ru Mailer 1.0
Date: Sun, 19 Apr 2020 14:26:14 +0300
X-Priority: 3 (Normal)
Message-ID: <1587295574.703588442@f508.i.mail.ru>
Content-Type: multipart/mixed;
 boundary="----f6F3cBc2eD6085103965FcFaC2fC1e5B-cwxOE3xDPrhw03v2-1587295574"
In-Reply-To: <994358c4-2430-74ad-3c3a-923a01c33e51@epam.com>
References: <1580804903.724638150@f311.i.mail.ru>
 <1580929196.631103701@f331.i.mail.ru>
 <994358c4-2430-74ad-3c3a-923a01c33e51@epam.com>
Authentication-Results: f508.i.mail.ru; auth=pass smtp.auth=santucco@mail.ru
 smtp.mailfrom=santucco@mail.ru
X-7564579A: 646B95376F6C166E
X-77F55803: 0A44E481635329DB4E7FAE048FD183FFD32E5E48865217364D5B7DD649282911D70A458D32E90B64FBDBF69DD7E3F538042BB3FB9AD55D3DF27955DEA0705EF5C2B382FFC9F674EE4A8F2C87B2D57BF0
X-7FA49CB5: 70AAF3C13DB7016878DA827A17800CE716A764422F1F4B1CD82A6BABE6F325AC9EB98D58427B1C2ABCF491FFA38154B613377AFFFEAFD269176DF2183F8FC7C09A02CFBD12041B85C2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE779AAD18609327F83EA1F7E6F0F101C674E70A05D1297E1BBC6CDE5D1141D2B1C026794D1B687D4C259389F046B3E9BA98E1B3915D191C0B49FA2833FD35BB23D9E625A9149C048EE9ECD01F8117BC8BEA471835C12D1D9774AD6D5ED66289B524E70A05D1297E1BBF6B57BC7E64490611E7FA7ABCAF51C92A417C69337E82CC2CC7F00164DA146DA6F5DAA56C3B73B23E7DDDDC251EA7DABAAAE862A0553A39223F8577A6DFFEA7CE31A2885C41F97C443847C11F186F3C5E7DDDDC251EA7DABCC89B49CDF41148FDCD13837A2BCF0203C9F3DD0FB1AF5EB4E70A05D1297E1BBCB5012B2E24CD356
X-D57D3AED: Y8kq8+OzVozcFQziTi/Zi098oNK9gy3Irm5KFwLuDg60je4lC+GbTj0M8KbzpOmgsB7wYP6nnel8wfEHQiZAetlEg7qy07ISeqrIhHPnkjxpRyBbnPB6aA==
X-Mailru-MI: 800
X-Mailru-Sender: F9A8308B51EED93E48F30226B6D448D04CC7A3406CCD017E59869FD4A6E86D5AEF500594ABB6299A9BE4FF0D1D4200097903AA853BEC14D60E09D1A5DFDDD82F8BC0F606C687C5A13A50EA9FAFF5C6D05CDCB0CA073FD32967EA787935ED9F1B
X-Mras: Ok
X-Spam: undefined
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: =?UTF-8?B?U2FudHVjY28=?= <santucco@mail.ru>
Cc: =?UTF-8?B?eGVuLWRldmVs?= <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


------f6F3cBc2eD6085103965FcFaC2fC1e5B-cwxOE3xDPrhw03v2-1587295574
Content-Type: multipart/alternative;
	boundary="--ALT--f6F3cBc2eD6085103965FcFaC2fC1e5B1587295574"


----ALT--f6F3cBc2eD6085103965FcFaC2fC1e5B1587295574
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

CkhlbGxvLArCoApJIGhhdmUgZm91bmQgYSBzb3VyY2Ugb2YgdGhlIHByb2JsZW0uCkluIGRpc3Bs
X2JlLMKgIEJhc2VEdW1wIGNvcGllcyB0byB0aGUgZHJtIGJ1ZmZlciB3aXRoIGHCoHNpemUgZnJv
bSBpOTE1wqBkcm0gZHJpdmVyLCBidXQgdGhpcyBzaXplIGEgYml0IG1vcmUgdGhhbiBhwqBzaXpl
IG9mwqBteSBmcm9udGVuZCBkaXNwbGF5IGJ1ZmZlci4gSSBoYXZlIG1hZGUgYSBxdWljayBhbmQg
ZGlydHnCoGZpeCzCoGEgY29wecKgYSBsaW5lIG9mIG15IGRpc3BsYXkgYnVmZmVyIHRvIGEgbWlk
ZGxlIG9mIGHCoGxpbmUgb2bCoHRoZcKgZHJtIGRpc3BsYXkgYnVmZmVyLiBQYXRjaCBpcyBhdHRh
Y2hlZC4KwqAKQmVzdCByZWdhcmRzLApBbGV4YW5kZXIgCj7Qp9C10YLQstC10YDQsywgNiDRhNC1
0LLRgNCw0LvRjyAyMDIwLCAxMToyMCArMDM6MDAg0L7RgiBPbGVrc2FuZHIgQW5kcnVzaGNoZW5r
byA8b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20+Ogo+wqAKPk9uIDIvNS8yMCA4OjU5
IFBNLCBTYW50dWNjbyB3cm90ZToKPj4gSGVsbG8sCj4+IE9rLCBJwqAgY29tbWVudGVkIG91dCB0
aGUgbWVtY3B5IGNhbGwgYW5kIHJ1bsKgdGhlIHRlc3QuCj4+IGRpc3BsX2JlIGhhc27igJl0IGNy
YWNoZWQsIEkgaGF2ZcKgc2VlbiBGTElQIGV2ZW50cyBpbiB0aGUgbG9nLgo+PiBCdXQgdGhlcmUg
aGFzbuKAmXQgYmVlbsKgdGhlwqBibGFjayBzY3JlZW4sIGp1c3QgYcKgYmxpbmsgZWZmZWN0IGV2
ZXJ5Cj4+IGNvdXBsZSBvZiBzZWNvbmRzLgo+PiBMb2dzIGFyZSBhdHRhY2hlZC4KPk9rLCBzbyBJ
IGJlbGlldmUgdGhhdCBmcm9udGVuZCAtIGJhY2tlbmQgKGRpc3BsX2JlKSBjb21tdW5pY2F0aW9u
IGlzIG9rCj5hbmQgdGhlcmUgaXMgbm90aGluZyB0byBkbyB0aGVyZS4KPgo+TmV4dCwgSSB3b3Vs
ZCBzdGFydCBkZWJ1Z2dpbmcgdGhlIGZvbGxvd2luZyBpbiBYZW46Cj4oWEVOKSBtbS5jOjIyMjM6
ZDJ2MCBCYWQgTDEgZmxhZ3MgODAKPmFuZCBoYXZlIGEgbG9vayBhdCBbMV0uIFByb2JhYmx5LCBz
b21lb25lIG9uIFhlbiB4ODYgc2lkZSBjYW4gdGVsbAo+aWYgdGhpcyBjb3VsZCBiZSByZWxhdGVk
IHRvIHRoZSBmbGFncyBhdCBbMl0uCj4KPj4gQmVzdCByZWdhcmRzLAo+PiBBbGV4YW5kZXIKPj4K
Pj4g0KHRgNC10LTQsCwgNSDRhNC10LLRgNCw0LvRjyAyMDIwLCA5OjMxICswMzowMCDQvtGCIE9s
ZWtzYW5kciBBbmRydXNoY2hlbmtvCj4+IDwgb2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5j
b20gPjoKPj4gT24gMi80LzIwIDEwOjI4IEFNLCBTYW50dWNjbyB3cm90ZToKPj4gPiBIZWxsbywK
Pj4gPiBkaXNwbF9iZSB3YXMgY29tcGlsZWTCoHdpdGhvdXQgemVyby1jb3B5IHN1cHBvcnQgZWFy
bHkuCj4+ID4gSSBoYXZlIHRyaWVkIHdpdGggdGhlwqByZWNvbXBpbGVkIGRvbTAga2VybmVsLCBh
IHJlc3VsdCBpc8KgdGhlIHNhbWUuCj4+ID4gTG9ncyBhbmQgY29uZmlncyAoK2Rpc3BsX2Jl4oCZ
c8KgQ01ha2VDYWNoZS50eHTCoCkgYXJlIGF0dGFjaGVkLgo+PiBPaywgeWV0IGFub3RoZXIgdGVz
dCB0byBsb2NhbGl6ZSB0aGUgcHJvYmxlbS4KPj4gQ291bGQgeW91IHBsZWFzZSByZW1vdmUgbWVt
Y3B5IGZyb20KPj4gIzHCoCAweDAwMDA1NWU1YTFmMjhiZWMgaW4gRHJtOjpEdW1iRHJtOjpjb3B5
ICh0aGlzPTB4N2Y5MzM4MDAwZTAwKSBhdAo+PiAvaG9tZS9zYW50dWNjby90bXAveGVuLXRyb29w
cy9kaXNwbF9iZS9zcmMvZGlzcGxheUJhY2tlbmQvZHJtL0R1bWIuY3BwOjE0OQo+PiBhbmQganVz
dCBtZW1zZXQgdGhlIGRlc3RpbmF0aW9uIHdpdGggMCBvciB3aGF0ZXZlci4KPj4KPj4gSSBleHBl
Y3QgdGhhdCBzeXN0ZW0gd29uJ3QgY3Jhc2gsIG5vdGhpbmcgd2lsbCBiZSBzaG93biAoYmxhY2sK
Pj4gc2NyZWVuKSwgYnV0Cj4+IGRpc3BsX2JlIHdpbGwgc2hvdyBwYWdlIGZsaXAgZXZlbnRzIGlu
IGl0cyBsb2dzLgo+PiA+IEJlc3QgcmVnYXJkcywKPj4gPiBBbGV4YW5kZXIKPj4gPgo+PiA+INCf
0L7QvdC10LTQtdC70YzQvdC40LosIDMg0YTQtdCy0YDQsNC70Y8gMjAyMCwgMTA6MzYgKzAzOjAw
INC+0YIgT2xla3NhbmRyCj4+ID4gQW5kcnVzaGNoZW5rbyA8IG9sZWtzYW5kcl9hbmRydXNoY2hl
bmtvQGVwYW0uY29tCj4+IDwvY29tcG9zZT9Ubz1vbGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFt
LmNvbT4+Ogo+PiA+Cj4+ID4KPj4gPiBPbiAyLzEvMjAgNDozOSBQTSwgU2FudHVjY28gd3JvdGU6
Cj4+ID4gPiBIZWxsbyBhZ2FpbiwKPj4gPiA+IEkgaGF2ZSBub3QgeWV0IG1hZGUgdG8gd29yayBt
eSBkcm0gY2xpZW50LCBzbyBJIGhhdmUgdHJpZWQgdG8gcnVuCj4+ID4gPiBsaW51eCBsaWtlIGEg
ZG9tVcKgKHRvIHNlZSBob3cgaXQgc2hvdWxkIHdvcmspLCBpdCBkb2VzbuKAmXQgd29yayB0b28K
Pj4gPiA+IOKAlMKgZGlzcGxfYmUgY2F0Y2hlcyBTSUdTRUdWOgo+PiA+ID4KPj4gPiA+ICMwIMKg
MHgwMDAwN2Y0YWZlZDFjMTYxIGluID8/ICgpIGZyb20gL2xpYjY0L2xpYmMuc28uNgo+PiA+ID4g
IzEgwqAweDAwMDA1NTcyM2I5YzViZWMgaW4gRHJtOjpEdW1iRHJtOjpjb3B5Cj4+ID4gKHRoaXM9
MHg3ZjRhZGMwMDBlMDApIGF0Cj4+ID4gPgo+PiA+Cj4+IC9ob21lL3NhbnR1Y2NvL3RtcC94ZW4t
dHJvb3BzL2Rpc3BsX2JlL3NyYy9kaXNwbGF5QmFja2VuZC9kcm0vRHVtYi5jcHA6MTQ5Cj4+ID4g
PiAjMiDCoDB4MDAwMDU1NzIzYjlhOGY1MSBpbiBCdWZmZXJzU3RvcmFnZTo6Z2V0RnJhbWVCdWZm
ZXJBbmRDb3B5Cj4+ID4gPiAodGhpcz0weDdmNGFlMDAwMTBlMCwgZmJDb29raWU9MTg0NDY2MTI2
ODIyOTUwODMyNjQpIGF0Cj4+ID4gPgo+PiA+Cj4+IC9ob21lL3NhbnR1Y2NvL3RtcC94ZW4tdHJv
b3BzL2Rpc3BsX2JlL3NyYy9kaXNwbGF5QmFja2VuZC9CdWZmZXJzU3RvcmFnZS5jcHA6MTY1Cj4+
ID4gPiBJdCB0cmllcyB0byBjb3B5IHRvIG1CdWZmZXIgd2l0aCBub24tYWNjZXNzaWJsZSBhZGRy
ZXNzLgo+PiA+ID4gRm9yIHRoZSBtb21lbnQgSSBzZWUgYcKgc3RyYW5nZSBvZmZzZXQgZm9yIG1t
YXAgY2FsbCBvZgo+PiA+IC9kZXYvZHJtL2NhcmQwCj4+ID4gPiBpbiB0aGUgc3RyYWNlIGxvZyDi
gJTCoDB4MTAwMDAwMDAwLiBJcyB0aGF0IG5vcm1hbD8KPj4gPiA+IEFueSBkaXJlY3Rpb24gb2Yg
d2hpY2jCoHRvIGRpZyB3aWxsIGJlIHZlcnkgaGVscGZ1bC4KPj4gPiA+IENvbmZpZ3VyYXRpb24g
ZGV0YWlsczoKPj4gPiA+IFhlbiA0LjEyLjEgRG9tMDogTGludXggNC4yMC4xNy1nZW50b28gIzEz
IFNNUCBTYXQgRGVjIDI4Cj4+ID4gMTE6MTI6MjQgTVNLCj4+ID4gPiAyMDE5IHg4Nl82NCBJbnRl
bChSKSBDZWxlcm9uKFIpIENQVSBOMzA1MCBAIDEuNjBHSHogR2VudWluZUludGVsCj4+ID4gR05V
L0xpbnV4Cj4+ID4gPiBEb21VOiBMaW51eCA0LjIwLjE3LWdlbnRvbwo+PiA+ID4gbGFzdCB4ZW4t
dHJvb3BzL2xpYnhlbmJlIGFuZCB4ZW4tdHJvb3BzL2Rpc3BsX2JlCj4+ID4gPiBMb2dzIChkbWVz
ZywgeGwgZG1lc2csIGRpc3BsX2JlLCBzdHJhY2UgbG9nIG9mIGRpc3BsX2JlKSwgYQo+PiA+IGJh
Y2t0cmFjZQo+PiA+ID4gb2YgZ2RiIGFuZCBrZXJuZWwgY29uZmlncyBhcmUgYXR0YWNoZWQuCj4+
ID4gPiBUaGFua3MgaW4gYWR2YW5jZS4KPj4gPiBDb3VsZCB5b3UgcGxlYXNlIHRyeSBEb20wIGtl
cm5lbCBXSVRIT1VUIHRoZSBvcHRpb25zIGJlbG93Ogo+PiA+IENPTkZJR19YRU5fR05UREVWX0RN
QUJVRj15Cj4+ID4gQ09ORklHX1hFTl9HUkFOVF9ETUFfQUxMT0M9eQo+PiA+Cj4+ID4gVGhlbiwg
anVzdCB0byBtYWtlIHN1cmUsIGRpZCB5b3UgYnVpbGQgZGlzcGxfYmUgd2l0aG91dCB6ZXJvLWNv
cHkKPj4gPiBzdXBwb3J0Pwo+PiA+Cj4+ID4gPiBPbiAxLzgvMjAgNTozOCBQTSwgU2FudHVjY28g
d3JvdGU6Cj4+ID4gPiA+IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIGFsbCB5b3VyIGFuc3dlcnMu
Cj4+ID4gPiA+Cj4+ID4gPiA+INCh0YDQtdC00LAsIDgg0Y/QvdCy0LDRgNGPIDIwMjAsIDEwOjU0
ICswMzowMCDQvtGCIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvCj4+ID4gPiA+IDwgb2xla3NhbmRy
X2FuZHJ1c2hjaGVua29AZXBhbS5jb20KPj4gPC9jb21wb3NlP1RvPW9sZWtzYW5kcl9hbmRydXNo
Y2hlbmtvQGVwYW0uY29tPgo+PiA+ID4gPiA8L2NvbXBvc2U/VG89b2xla3NhbmRyX2FuZHJ1c2hj
aGVua29AZXBhbS5jb20+PjoKPj4gPiA+ID4gT24gMS82LzIwIDEwOjM4IEFNLCBKw7xyZ2VuIEdy
b8OfIHdyb3RlOgo+PiA+ID4gPiA+IE9uIDA2LjAxLjIwIDA4OjU2LCBTYW50dWNjbyB3cm90ZToK
Pj4gPiA+ID4gPj4gSGVsbG8sCj4+ID4gPiA+ID4+Cj4+ID4gPiA+ID4+IEnigJltIHRyeWluZyB0
byB1c2UgdmRpc3BsIGludGVyZmFjZSBmcm9tIFBWIE9TLCBpdCBkb2VzbuKAmXQKPj4gd29yay4K
Pj4gPiA+ID4gPj4gQ29uZmlndXJhdGlvbiBkZXRhaWxzOgo+PiA+ID4gPiA+PiDCoMKgwqDCoCBY
ZW4gNC4xMi4xCj4+ID4gPiA+ID4+IMKgwqDCoMKgIERvbTA6IExpbnV4IDQuMjAuMTctZ2VudG9v
ICMxMyBTTVAgU2F0IERlYyAyOAo+PiAxMToxMjoyNCBNU0sKPj4gPiA+ID4gMjAxOQo+PiA+ID4g
PiA+PiB4ODZfNjQgSW50ZWwoUikgQ2VsZXJvbihSKSBDUFUgTjMwNTAgQCAxLjYwR0h6IEdlbnVp
bmVJbnRlbAo+PiA+ID4gPiBHTlUvTGludXgKPj4gPiA+ID4gPj4gwqDCoMKgwqAgRG9tVTogeDg2
wqBQbGFuOSwgUFYKPj4gPiA+ID4gPj4gZGlzcGxfYmUgYXMgYSBiYWNrZW5kIGZvciB2ZGlzcGwg
YW5kIHZrYgo+PiA+ID4gPiA+Pgo+PiA+ID4gPiA+PiB3aGVuIFZNIHN0YXJ0cywgZGlzcGxfYmUg
cmVwb3J0cyBhYm91dCBhbiBlcnJvcjoKPj4gPiA+ID4gPj4gZ250dGFiOiBlcnJvcjogaW9jdGwg
RE1BQlVGX0VYUF9GUk9NX1JFRlMgZmFpbGVkOiBJbnZhbGlkCj4+ID4gYXJndW1lbnQKPj4gPiA+
ID4gPj4gKGRpc3BsX2JlLmxvZzoyMjEpCj4+ID4gPiA+ID4+Cj4+ID4gPiA+ID4+IHJlbGF0ZWTC
oERvbTAgb3V0cHV0IGlzOgo+PiA+ID4gPiA+PiBbIDE5MS41NzkyNzhdIENhbm5vdCBwcm92aWRl
IGRtYS1idWY6IHVzZV9wdGVtb2RlIDEKPj4gPiA+ID4gPj4gKGRtZXNnLmNyZWF0ZS5sb2c6MTIz
KQo+PiA+ID4gPiA+Cj4+ID4gPiA+ID4gVGhpcyBzZWVtcyB0byBiZSBhIGxpbWl0YXRpb24gb2Yg
dGhlIHhlbiBkbWEtYnVmIGRyaXZlci4KPj4gSXQgd2FzCj4+ID4gPiA+IHdyaXR0ZW4KPj4gPiA+
ID4gPiBmb3IgYmVpbmcgdXNlZCBvbiBBUk0gaW5pdGlhbGx5IHdoZXJlIFBWIGlzIG5vdCBhdmFp
bGFibGUuCj4+ID4gPiA+IFRoaXMgaXMgdHJ1ZSBhbmQgd2UgbmV2ZXIgdHJpZWQvdGFyZ2V0ZWQg
UFYgZG9tYWlucyB3aXRoIHRoaXMKPj4gPiA+ID4gaW1wbGVtZW50YXRpb24sCj4+ID4gPiA+IHNv
IGlmIHRoZXJlIGlzIGEgbmVlZCBmb3IgdGhhdCBzb21lb25lIGhhcyB0byB0YWtlIGEgbG9vayBv
biB0aGUKPj4gPiA+ID4gcHJvcGVyCj4+ID4gPiA+IGltcGxlbWVudGF0aW9uIGZvciBQVuKApgo+
PiA+ID4gPgo+PiA+ID4gPiBIYXZlIEkgZ290IHlvdXIgcmlnaHQgYW5kIHRoZXJlIGlzIG5vwqB0
aGUgcHJvcGVyCj4+ID4gaW1wbGVtZW50YXRpb24gOi0pPwo+PiA+ID4gVGhlcmUgaXMgbm8KPj4g
PiA+ID4KPj4gPiA+ID4gPgo+PiA+ID4gPiA+IENDLWluZyBPbGVrc2FuZHIgQW5kcnVzaGNoZW5r
byB3aG8gaXMgdGhlIGF1dGhvciBvZiB0aGF0Cj4+ID4gZHJpdmVyLiBIZQo+PiA+ID4gPiA+IHNo
b3VsZCBiZSBhYmxlIHRvIHRlbGwgdXMgd2hhdCB3b3VsZCBiZSBuZWVkZWQgdG8gZW5hYmxlIFBW
Cj4+ID4gZG9tMC4KPj4gPiA+ID4gPgo+PiA+ID4gPiA+IERlcGVuZGluZyBvbiB5b3VyIHVzZSBj
YXNlIGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIHVzZSBQVkgKPj4gPiBkb20wLCBidXQKPj4gPiA+
ID4gPiBzdXBwb3J0IGZvciB0aGlzIG1vZGUgaXMgImV4cGVyaW1lbnRhbCIgb25seSBhbmQgc29t
ZSBmZWF0dXJlcwo+PiA+ID4gPiBhcmUgbm90Cj4+ID4gPiA+ID4geWV0IHdvcmtpbmcuCj4+ID4g
PiA+ID4KPj4gPiA+ID4gV2VsbCwgb25lIG9mIHRoZSB3b3JrYXJvdW5kcyBwb3NzaWJsZSBpcyB0
byBkcm9wIHplcm8tY29weWluZwo+PiA+IHVzZS1jYXNlCj4+ID4gPiA+ICh0aGlzIGlzIHdoeSBk
aXNwbGF5IGJhY2tlbmQgdHJpZXMgdG8gY3JlYXRlIGRtdS1idWZzIGZyb20KPj4gZ3JhbnRzCj4+
ID4gPiA+IHBhc3NlZAo+PiA+ID4gPiBieSB0aGUgZ3Vlc3QgZG9tYWluIGFuZCBmYWlscyBiZWNh
dXNlIG9mICJDYW5ub3QgcHJvdmlkZQo+PiBkbWEtYnVmOgo+PiA+ID4gPiB1c2VfcHRlbW9kZSAx
IikKPj4gPiA+ID4gU28sIGluIHRoaXMgY2FzZSBkaXNwbGF5IGJhY2tlbmQgd2lsbCBkbyBtZW1v
cnkgY29weWluZyBmb3IgdGhlCj4+ID4gPiA+IGluY29taW5nCj4+ID4gPiA+IGZyYW1lcwo+PiA+
ID4gPiBhbmQgd29uJ3QgdG91Y2ggRE1BQlVGX0VYUF9GUk9NX1JFRlMgaW9jdGwuCj4+ID4gPiA+
IFRvIGRvIHNvIGp1c3QgZGlzYWJsZSB6ZXJvLWNvcHlpbmcgd2hpbGUgYnVpbGRpbmcgdGhlCj4+
IGJhY2tlbmQgWzFdCj4+ID4gPiA+Cj4+ID4gPiA+IFRoYW5rcywgSSBoYXZlIGp1c3TCoHRyaWVk
wqB0aGUgd29ya2Fyb3VuZC4gVGhlIGJhY2tlbmQgaGFzwqBmYWlsZWQKPj4gPiA+ID4gaW7CoGFu
IG90aGVyIHBsYWNlwqBub3QgY29ycmVzcG9uZGluZyB3aXRoIGRtYV9idWYuCj4+ID4gPiA+IEFu
eXdhecKgaXQgaXMgZW5vdWdoIHRvIGNvbnRpbnVlwqBkZWJ1Z2dpbmfCoMKgbXkKPj4gPiBmcm9u
dGVuZMKgaW1wbGVtZW50YXRpb24uCj4+ID4gPiA+IERvIHlvdcKga25vdyBob3cgYmlnIGlzIHBl
cmZvcm1hbmNlIHBlbmFsdHkgaW4gY29tcGFyaXNvbiB3aXRoCj4+ID4gPiA+IHRoZcKgemVyby1j
b3B5IHZhcmlhbnQ/Cj4+ID4gPiBXZWxsLCBpdCBzb2xlbHkgZGVwZW5kcyBvbiB5b3VyIHNldHVw
LCBzbyBJIGNhbm5vdCB0ZWxsIHdoYXQKPj4gPiA+IHdvdWxkIHRoZSBudW1iZXJzIGJlIGluIHlv
dXIgY2FzZS4gQ29tcGFyaW5nIHRvIHdoYXQgSSBoYXZlCj4+IGRvZXNuJ3QKPj4gPiA+IG1ha2Ug
YW55IHNlbnNlIHRvIG1lOiBvbmUgc2hvdWxkIGNvbXBhcmUgYXBwbGVzIHRvIGFwcGxlcwo+PiA+
ID4gPiBEb2VzIGl0IG1ha2UgYcKgc2Vuc2UgaWYgSSBtYWtlIGHCoGRlZGljYXRlZCBIVk0gZG9t
YWluIHdpdGgKPj4gPiBsaW51eCBvbmx5Cj4+ID4gPiA+IGZvciB0aGUgcHVycG9zZSBvZsKgdmRp
c3BsIGFuZCB2a2JkIGJhY2tlbmRzP8KgSXMgdGhlcmUgYQo+PiBob3BlwqB0aGlzCj4+ID4gPiA+
IGFwcHJvYWNoIHdpbGwgd29yaz8KPj4gPiA+IFlvdSBjYW4gdHJ5IGlmIHRoaXMgYXBwcm9hY2gg
Zml0cyB5b3VyIGRlc2lnbiBhbmQgcmVxdWlyZW1lbnRzCj4+ID4gPiA+Cj4+ID4gPiA+ID4KPj4g
PiA+ID4gPiBKdWVyZ2VuCj4+ID4gPiA+ID4KPj4gPiA+ID4gWzFdCj4+ID4gPiA+Cj4+ID4gPgo+
PiA+Cj4+ICBodHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9iZS9ibG9iL21hc3Rl
ci9DTWFrZUxpc3RzLnR4dCNMMTIKPj4gPCBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0
cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0
cy50eHQqTDEyX187SXchIUdGXzI5ZGJjUUlVQlBBIWtaMUpRRlJTMnBYal9JdVhCaHZZaG1QOVFf
c3ZjTHlqQ1hLOTQ2NVVMR0I0TWVpWVBSejJjRjdsZXBIZ2dyOVV4UFU5ek9CRVV3JCA+Cj4+ID4K
Pj4gPCBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hlbi10
cm9vcHMvZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdGXzI5
ZGJjUUlVQlBBIWt2RGd5M1gwSXVTUWs3RDJEZHNHdHNqdHlHcm9ZYk5LT3JQRzk1T3B5b0FrdUJW
YkZTbXpvendmb3IwNWprUmwwaXRhMEZ1bUJ3JCA+Cj4+ID4gPgo+PiA+Cj4+IDwgaHR0cHM6Ly91
cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJvb3BzL2Rpc3BsX2Jl
L2Jsb2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0KkwxMl9fO0l3ISFHRl8yOWRiY1FJVUJQQSFnaTgx
b1paTnZXYUZXVVZuYVpsdUFfbU5CQUl0TE1kNFJabW5jLU1fRm1scERvanFlUVFuUzdhWFNObGJv
ODByZTl1T2wyd3FGQSQgPgo+PiA+ID4gPgo+PiA+ID4KPj4gPgo+PiA8IGh0dHBzOi8vdXJsZGVm
ZW5zZS5jb20vdjMvX19odHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9iZS9ibG9i
L21hc3Rlci9DTWFrZUxpc3RzLnR4dCpMMTJfXztJdyEhR0ZfMjlkYmNRSVVCUEEhbXozZ24xd1FN
WDJEWGVOdUFWLTFfZEk3bnhGWVlaT2dkUGlKTlNGTWVzQ3o5bEF6T0tsd1ZQbGRkYnhiY0xtVU80
NE5PeTBURkEkID4KPj4gPiA+ID4KPj4gPiA+ID4gQmVzdCByZWdhcmRzLAo+PiA+ID4gPiDCoCBB
bGV4YW5kZXIgU3ljaGV2Cj4+ID4gPgo+PiA+Cj4+ID4KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+Cj5b
MV0gIGh0dHBzOi8vZWxpeGlyLmJvb3RsaW4uY29tL2xpbnV4L3Y1LjUvc291cmNlL2RyaXZlcnMv
eGVuL2dudGRldi5jI0wzMDAKPlsyXSAgaHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20vbGludXgv
djUuNS9zb3VyY2UvZHJpdmVycy94ZW4vZ250ZGV2LmMjTDMxOQrCoA==

----ALT--f6F3cBc2eD6085103965FcFaC2fC1e5B1587295574
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

CjxIVE1MPjxCT0RZPjxkaXY+SGVsbG8sPC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48ZGl2PkkgaGF2
ZSBmb3VuZCBhIHNvdXJjZSBvZiB0aGUgcHJvYmxlbS48L2Rpdj48ZGl2PkluIGRpc3BsX2JlLCZu
YnNwOyBCYXNlRHVtcCBjb3BpZXMgdG8gdGhlIGRybSBidWZmZXIgd2l0aCBhJm5ic3A7c2l6ZSBm
cm9tIGk5MTUmbmJzcDtkcm0gZHJpdmVyLCBidXQgdGhpcyBzaXplIGEgYml0IG1vcmUgdGhhbiBh
Jm5ic3A7c2l6ZSBvZiZuYnNwO215IGZyb250ZW5kIGRpc3BsYXkgYnVmZmVyLiBJIGhhdmUgbWFk
ZSBhIHF1aWNrIGFuZCBkaXJ0eSZuYnNwO2ZpeCwmbmJzcDthIGNvcHkmbmJzcDthIGxpbmUgb2Yg
bXkgZGlzcGxheSBidWZmZXIgdG8gYSBtaWRkbGUgb2YgYSZuYnNwO2xpbmUgb2YmbmJzcDt0aGUm
bmJzcDtkcm0gZGlzcGxheSBidWZmZXIuIFBhdGNoIGlzIGF0dGFjaGVkLjwvZGl2PjxkaXY+Jm5i
c3A7PC9kaXY+PGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+PGRpdj5BbGV4YW5kZXI8L2Rpdj48Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6MXB4IHNvbGlkICMwODU3QTY7IG1hcmdpbjoxMHB4
OyBwYWRkaW5nOjAgMCAwIDEwcHg7Ij7Qp9C10YLQstC10YDQsywgNiDRhNC10LLRgNCw0LvRjyAy
MDIwLCAxMToyMCArMDM6MDAg0L7RgiBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbyAmbHQ7b2xla3Nh
bmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20mZ3Q7Ojxicj4mbmJzcDs8ZGl2IGlkPSIiPjxkaXYg
Y2xhc3M9ImpzLWhlbHBlciBqcy1yZWFkbXNnLW1zZyI+PHN0eWxlIHR5cGU9InRleHQvY3NzIj48
L3N0eWxlPjxkaXY+PGRpdiBpZD0ic3R5bGVfMTU4MDk3NzI1OTA3NzIwODM2MjFfQk9EWSI+T24g
Mi81LzIwIDg6NTkgUE0sIFNhbnR1Y2NvIHdyb3RlOjxicj4mZ3Q7IEhlbGxvLDxicj4mZ3Q7IE9r
LCBJJm5ic3A7IGNvbW1lbnRlZCBvdXQgdGhlIG1lbWNweSBjYWxsIGFuZCBydW4mbmJzcDt0aGUg
dGVzdC48YnI+Jmd0OyBkaXNwbF9iZSBoYXNu4oCZdCBjcmFjaGVkLCBJIGhhdmUmbmJzcDtzZWVu
IEZMSVAgZXZlbnRzIGluIHRoZSBsb2cuPGJyPiZndDsgQnV0IHRoZXJlIGhhc27igJl0IGJlZW4m
bmJzcDt0aGUmbmJzcDtibGFjayBzY3JlZW4sIGp1c3QgYSZuYnNwO2JsaW5rIGVmZmVjdCBldmVy
eTxicj4mZ3Q7IGNvdXBsZSBvZiBzZWNvbmRzLjxicj4mZ3Q7IExvZ3MgYXJlIGF0dGFjaGVkLjxi
cj5Paywgc28gSSBiZWxpZXZlIHRoYXQgZnJvbnRlbmQgLSBiYWNrZW5kIChkaXNwbF9iZSkgY29t
bXVuaWNhdGlvbiBpcyBvazxicj5hbmQgdGhlcmUgaXMgbm90aGluZyB0byBkbyB0aGVyZS48YnI+
PGJyPk5leHQsIEkgd291bGQgc3RhcnQgZGVidWdnaW5nIHRoZSBmb2xsb3dpbmcgaW4gWGVuOjxi
cj4oWEVOKSBtbS5jOjIyMjM6ZDJ2MCBCYWQgTDEgZmxhZ3MgODA8YnI+YW5kIGhhdmUgYSBsb29r
IGF0IFsxXS4gUHJvYmFibHksIHNvbWVvbmUgb24gWGVuIHg4NiBzaWRlIGNhbiB0ZWxsPGJyPmlm
IHRoaXMgY291bGQgYmUgcmVsYXRlZCB0byB0aGUgZmxhZ3MgYXQgWzJdLjxicj48YnI+Jmd0OyBC
ZXN0IHJlZ2FyZHMsPGJyPiZndDsgQWxleGFuZGVyPGJyPiZndDs8YnI+Jmd0OyDQodGA0LXQtNCw
LCA1INGE0LXQstGA0LDQu9GPIDIwMjAsIDk6MzEgKzAzOjAwINC+0YIgT2xla3NhbmRyIEFuZHJ1
c2hjaGVua288YnI+Jmd0OyAmbHQ7PGEgaHJlZj0iL2NvbXBvc2U/VG89b2xla3NhbmRyX2FuZHJ1
c2hjaGVua29AZXBhbS5jb20iPm9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPC9hPiZn
dDs6PGJyPiZndDsgT24gMi80LzIwIDEwOjI4IEFNLCBTYW50dWNjbyB3cm90ZTo8YnI+Jmd0OyAm
Z3Q7IEhlbGxvLDxicj4mZ3Q7ICZndDsgZGlzcGxfYmUgd2FzIGNvbXBpbGVkJm5ic3A7d2l0aG91
dCB6ZXJvLWNvcHkgc3VwcG9ydCBlYXJseS48YnI+Jmd0OyAmZ3Q7IEkgaGF2ZSB0cmllZCB3aXRo
IHRoZSZuYnNwO3JlY29tcGlsZWQgZG9tMCBrZXJuZWwsIGEgcmVzdWx0IGlzJm5ic3A7dGhlIHNh
bWUuPGJyPiZndDsgJmd0OyBMb2dzIGFuZCBjb25maWdzICgrZGlzcGxfYmXigJlzJm5ic3A7Q01h
a2VDYWNoZS50eHQmbmJzcDspIGFyZSBhdHRhY2hlZC48YnI+Jmd0OyBPaywgeWV0IGFub3RoZXIg
dGVzdCB0byBsb2NhbGl6ZSB0aGUgcHJvYmxlbS48YnI+Jmd0OyBDb3VsZCB5b3UgcGxlYXNlIHJl
bW92ZSBtZW1jcHkgZnJvbTxicj4mZ3Q7ICMxJm5ic3A7IDB4MDAwMDU1ZTVhMWYyOGJlYyBpbiBE
cm06OkR1bWJEcm06OmNvcHkgKHRoaXM9MHg3ZjkzMzgwMDBlMDApIGF0PGJyPiZndDsgL2hvbWUv
c2FudHVjY28vdG1wL3hlbi10cm9vcHMvZGlzcGxfYmUvc3JjL2Rpc3BsYXlCYWNrZW5kL2RybS9E
dW1iLmNwcDoxNDk8YnI+Jmd0OyBhbmQganVzdCBtZW1zZXQgdGhlIGRlc3RpbmF0aW9uIHdpdGgg
MCBvciB3aGF0ZXZlci48YnI+Jmd0Ozxicj4mZ3Q7IEkgZXhwZWN0IHRoYXQgc3lzdGVtIHdvbid0
IGNyYXNoLCBub3RoaW5nIHdpbGwgYmUgc2hvd24gKGJsYWNrPGJyPiZndDsgc2NyZWVuKSwgYnV0
PGJyPiZndDsgZGlzcGxfYmUgd2lsbCBzaG93IHBhZ2UgZmxpcCBldmVudHMgaW4gaXRzIGxvZ3Mu
PGJyPiZndDsgJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPiZndDsgJmd0OyBBbGV4YW5kZXI8YnI+Jmd0
OyAmZ3Q7PGJyPiZndDsgJmd0OyDQn9C+0L3QtdC00LXQu9GM0L3QuNC6LCAzINGE0LXQstGA0LDQ
u9GPIDIwMjAsIDEwOjM2ICswMzowMCDQvtGCIE9sZWtzYW5kcjxicj4mZ3Q7ICZndDsgQW5kcnVz
aGNoZW5rbyAmbHQ7PGEgaHJlZj0iL2NvbXBvc2U/VG89b2xla3NhbmRyX2FuZHJ1c2hjaGVua29A
ZXBhbS5jb20iPm9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPC9hPjxicj4mZ3Q7ICZs
dDsvY29tcG9zZT9Ubz1vbGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbSZndDsmZ3Q7Ojxi
cj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBPbiAyLzEvMjAgNDozOSBQTSwg
U2FudHVjY28gd3JvdGU6PGJyPiZndDsgJmd0OyAmZ3Q7IEhlbGxvIGFnYWluLDxicj4mZ3Q7ICZn
dDsgJmd0OyBJIGhhdmUgbm90IHlldCBtYWRlIHRvIHdvcmsgbXkgZHJtIGNsaWVudCwgc28gSSBo
YXZlIHRyaWVkIHRvIHJ1bjxicj4mZ3Q7ICZndDsgJmd0OyBsaW51eCBsaWtlIGEgZG9tVSZuYnNw
Oyh0byBzZWUgaG93IGl0IHNob3VsZCB3b3JrKSwgaXQgZG9lc27igJl0IHdvcmsgdG9vPGJyPiZn
dDsgJmd0OyAmZ3Q7IOKAlCZuYnNwO2Rpc3BsX2JlIGNhdGNoZXMgU0lHU0VHVjo8YnI+Jmd0OyAm
Z3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgIzAgJm5ic3A7MHgwMDAwN2Y0YWZlZDFjMTYxIGlu
ID8/ICgpIGZyb20gL2xpYjY0L2xpYmMuc28uNjxicj4mZ3Q7ICZndDsgJmd0OyAjMSAmbmJzcDsw
eDAwMDA1NTcyM2I5YzViZWMgaW4gRHJtOjpEdW1iRHJtOjpjb3B5PGJyPiZndDsgJmd0OyAodGhp
cz0weDdmNGFkYzAwMGUwMCkgYXQ8YnI+Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZn
dDsgL2hvbWUvc2FudHVjY28vdG1wL3hlbi10cm9vcHMvZGlzcGxfYmUvc3JjL2Rpc3BsYXlCYWNr
ZW5kL2RybS9EdW1iLmNwcDoxNDk8YnI+Jmd0OyAmZ3Q7ICZndDsgIzIgJm5ic3A7MHgwMDAwNTU3
MjNiOWE4ZjUxIGluIEJ1ZmZlcnNTdG9yYWdlOjpnZXRGcmFtZUJ1ZmZlckFuZENvcHk8YnI+Jmd0
OyAmZ3Q7ICZndDsgKHRoaXM9MHg3ZjRhZTAwMDEwZTAsIGZiQ29va2llPTE4NDQ2NjEyNjgyMjk1
MDgzMjY0KSBhdDxicj4mZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAvaG9tZS9z
YW50dWNjby90bXAveGVuLXRyb29wcy9kaXNwbF9iZS9zcmMvZGlzcGxheUJhY2tlbmQvQnVmZmVy
c1N0b3JhZ2UuY3BwOjE2NTxicj4mZ3Q7ICZndDsgJmd0OyBJdCB0cmllcyB0byBjb3B5IHRvIG1C
dWZmZXIgd2l0aCBub24tYWNjZXNzaWJsZSBhZGRyZXNzLjxicj4mZ3Q7ICZndDsgJmd0OyBGb3Ig
dGhlIG1vbWVudCBJIHNlZSBhJm5ic3A7c3RyYW5nZSBvZmZzZXQgZm9yIG1tYXAgY2FsbCBvZjxi
cj4mZ3Q7ICZndDsgL2Rldi9kcm0vY2FyZDA8YnI+Jmd0OyAmZ3Q7ICZndDsgaW4gdGhlIHN0cmFj
ZSBsb2cg4oCUJm5ic3A7MHgxMDAwMDAwMDAuIElzIHRoYXQgbm9ybWFsPzxicj4mZ3Q7ICZndDsg
Jmd0OyBBbnkgZGlyZWN0aW9uIG9mIHdoaWNoJm5ic3A7dG8gZGlnIHdpbGwgYmUgdmVyeSBoZWxw
ZnVsLjxicj4mZ3Q7ICZndDsgJmd0OyBDb25maWd1cmF0aW9uIGRldGFpbHM6PGJyPiZndDsgJmd0
OyAmZ3Q7IFhlbiA0LjEyLjEgRG9tMDogTGludXggNC4yMC4xNy1nZW50b28gIzEzIFNNUCBTYXQg
RGVjIDI4PGJyPiZndDsgJmd0OyAxMToxMjoyNCBNU0s8YnI+Jmd0OyAmZ3Q7ICZndDsgMjAxOSB4
ODZfNjQgSW50ZWwoUikgQ2VsZXJvbihSKSBDUFUgTjMwNTAgQCAxLjYwR0h6IEdlbnVpbmVJbnRl
bDxicj4mZ3Q7ICZndDsgR05VL0xpbnV4PGJyPiZndDsgJmd0OyAmZ3Q7IERvbVU6IExpbnV4IDQu
MjAuMTctZ2VudG9vPGJyPiZndDsgJmd0OyAmZ3Q7IGxhc3QgeGVuLXRyb29wcy9saWJ4ZW5iZSBh
bmQgeGVuLXRyb29wcy9kaXNwbF9iZTxicj4mZ3Q7ICZndDsgJmd0OyBMb2dzIChkbWVzZywgeGwg
ZG1lc2csIGRpc3BsX2JlLCBzdHJhY2UgbG9nIG9mIGRpc3BsX2JlKSwgYTxicj4mZ3Q7ICZndDsg
YmFja3RyYWNlPGJyPiZndDsgJmd0OyAmZ3Q7IG9mIGdkYiBhbmQga2VybmVsIGNvbmZpZ3MgYXJl
IGF0dGFjaGVkLjxicj4mZ3Q7ICZndDsgJmd0OyBUaGFua3MgaW4gYWR2YW5jZS48YnI+Jmd0OyAm
Z3Q7IENvdWxkIHlvdSBwbGVhc2UgdHJ5IERvbTAga2VybmVsIFdJVEhPVVQgdGhlIG9wdGlvbnMg
YmVsb3c6PGJyPiZndDsgJmd0OyBDT05GSUdfWEVOX0dOVERFVl9ETUFCVUY9eTxicj4mZ3Q7ICZn
dDsgQ09ORklHX1hFTl9HUkFOVF9ETUFfQUxMT0M9eTxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7
IFRoZW4sIGp1c3QgdG8gbWFrZSBzdXJlLCBkaWQgeW91IGJ1aWxkIGRpc3BsX2JlIHdpdGhvdXQg
emVyby1jb3B5PGJyPiZndDsgJmd0OyBzdXBwb3J0Pzxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7
ICZndDsgT24gMS84LzIwIDU6MzggUE0sIFNhbnR1Y2NvIHdyb3RlOjxicj4mZ3Q7ICZndDsgJmd0
OyAmZ3Q7IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIGFsbCB5b3VyIGFuc3dlcnMuPGJyPiZndDsg
Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyDQodGA0LXQtNCwLCA4INGP0L3Q
stCw0YDRjyAyMDIwLCAxMDo1NCArMDM6MDAg0L7RgiBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbzxi
cj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSIvY29tcG9zZT9Ubz1vbGVrc2FuZHJf
YW5kcnVzaGNoZW5rb0BlcGFtLmNvbSI+b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb208
L2E+PGJyPiZndDsgJmx0Oy9jb21wb3NlP1RvPW9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0u
Y29tJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDsvY29tcG9zZT9Ubz1vbGVrc2FuZHJf
YW5kcnVzaGNoZW5rb0BlcGFtLmNvbSZndDsmZ3Q7Ojxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9u
IDEvNi8yMCAxMDozOCBBTSwgSsO8cmdlbiBHcm/DnyB3cm90ZTo8YnI+Jmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IE9uIDA2LjAxLjIwIDA4OjU2LCBTYW50dWNjbyB3cm90ZTo8YnI+Jmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7Jmd0OyBIZWxsbyw8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0
Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IEnigJltIHRyeWluZyB0byB1c2UgdmRp
c3BsIGludGVyZmFjZSBmcm9tIFBWIE9TLCBpdCBkb2VzbuKAmXQ8YnI+Jmd0OyB3b3JrLjxicj4m
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IENvbmZpZ3VyYXRpb24gZGV0YWlsczo8YnI+Jmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWGVuIDQu
MTIuMTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBEb20wOiBMaW51eCA0LjIwLjE3LWdlbnRvbyAjMTMgU01QIFNhdCBEZWMgMjg8YnI+Jmd0
OyAxMToxMjoyNCBNU0s8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAyMDE5PGJyPiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyZndDsgeDg2XzY0IEludGVsKFIpIENlbGVyb24oUikgQ1BVIE4zMDUwIEAg
MS42MEdIeiBHZW51aW5lSW50ZWw8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBHTlUvTGludXg8YnI+
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRG9t
VTogeDg2Jm5ic3A7UGxhbjksIFBWPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgZGlz
cGxfYmUgYXMgYSBiYWNrZW5kIGZvciB2ZGlzcGwgYW5kIHZrYjxicj4mZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgd2hlbiBWTSBzdGFy
dHMsIGRpc3BsX2JlIHJlcG9ydHMgYWJvdXQgYW4gZXJyb3I6PGJyPiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyZndDsgZ250dGFiOiBlcnJvcjogaW9jdGwgRE1BQlVGX0VYUF9GUk9NX1JFRlMgZmFp
bGVkOiBJbnZhbGlkPGJyPiZndDsgJmd0OyBhcmd1bWVudDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZndDsmZ3Q7IChkaXNwbF9iZS5sb2c6MjIxKTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsm
Z3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgcmVsYXRlZCZuYnNwO0RvbTAgb3V0
cHV0IGlzOjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFsgMTkxLjU3OTI3OF0gQ2Fu
bm90IHByb3ZpZGUgZG1hLWJ1ZjogdXNlX3B0ZW1vZGUgMTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZndDsmZ3Q7IChkbWVzZy5jcmVhdGUubG9nOjEyMyk8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGlzIHNlZW1zIHRvIGJlIGEgbGltaXRh
dGlvbiBvZiB0aGUgeGVuIGRtYS1idWYgZHJpdmVyLjxicj4mZ3Q7IEl0IHdhczxicj4mZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IHdyaXR0ZW48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZvciBiZWlu
ZyB1c2VkIG9uIEFSTSBpbml0aWFsbHkgd2hlcmUgUFYgaXMgbm90IGF2YWlsYWJsZS48YnI+Jmd0
OyAmZ3Q7ICZndDsgJmd0OyBUaGlzIGlzIHRydWUgYW5kIHdlIG5ldmVyIHRyaWVkL3RhcmdldGVk
IFBWIGRvbWFpbnMgd2l0aCB0aGlzPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW1wbGVtZW50YXRp
b24sPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgc28gaWYgdGhlcmUgaXMgYSBuZWVkIGZvciB0aGF0
IHNvbWVvbmUgaGFzIHRvIHRha2UgYSBsb29rIG9uIHRoZTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7
IHByb3Blcjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGltcGxlbWVudGF0aW9uIGZvciBQVuKApjxi
cj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgSGF2ZSBJIGdvdCB5
b3VyIHJpZ2h0IGFuZCB0aGVyZSBpcyBubyZuYnNwO3RoZSBwcm9wZXI8YnI+Jmd0OyAmZ3Q7IGlt
cGxlbWVudGF0aW9uIDotKT88YnI+Jmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm88YnI+Jmd0OyAm
Z3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IENDLWluZyBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbyB3aG8gaXMgdGhlIGF1
dGhvciBvZiB0aGF0PGJyPiZndDsgJmd0OyBkcml2ZXIuIEhlPGJyPiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyBzaG91bGQgYmUgYWJsZSB0byB0ZWxsIHVzIHdoYXQgd291bGQgYmUgbmVlZGVkIHRv
IGVuYWJsZSBQVjxicj4mZ3Q7ICZndDsgZG9tMC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBEZXBlbmRpbmcgb24geW91ciB1c2UgY2FzZSBp
dCBtaWdodCBiZSBwb3NzaWJsZSB0byB1c2UgUFZIPGJyPiZndDsgJmd0OyBkb20wLCBidXQ8YnI+
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHN1cHBvcnQgZm9yIHRoaXMgbW9kZSBpcyAiZXhwZXJp
bWVudGFsIiBvbmx5IGFuZCBzb21lIGZlYXR1cmVzPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgYXJl
IG5vdDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgeWV0IHdvcmtpbmcuPGJyPiZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFdlbGwsIG9uZSBvZiB0aGUg
d29ya2Fyb3VuZHMgcG9zc2libGUgaXMgdG8gZHJvcCB6ZXJvLWNvcHlpbmc8YnI+Jmd0OyAmZ3Q7
IHVzZS1jYXNlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgKHRoaXMgaXMgd2h5IGRpc3BsYXkgYmFj
a2VuZCB0cmllcyB0byBjcmVhdGUgZG11LWJ1ZnMgZnJvbTxicj4mZ3Q7IGdyYW50czxicj4mZ3Q7
ICZndDsgJmd0OyAmZ3Q7IHBhc3NlZDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJ5IHRoZSBndWVz
dCBkb21haW4gYW5kIGZhaWxzIGJlY2F1c2Ugb2YgIkNhbm5vdCBwcm92aWRlPGJyPiZndDsgZG1h
LWJ1Zjo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB1c2VfcHRlbW9kZSAxIik8YnI+Jmd0OyAmZ3Q7
ICZndDsgJmd0OyBTbywgaW4gdGhpcyBjYXNlIGRpc3BsYXkgYmFja2VuZCB3aWxsIGRvIG1lbW9y
eSBjb3B5aW5nIGZvciB0aGU8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpbmNvbWluZzxicj4mZ3Q7
ICZndDsgJmd0OyAmZ3Q7IGZyYW1lczxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFuZCB3b24ndCB0
b3VjaCBETUFCVUZfRVhQX0ZST01fUkVGUyBpb2N0bC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBU
byBkbyBzbyBqdXN0IGRpc2FibGUgemVyby1jb3B5aW5nIHdoaWxlIGJ1aWxkaW5nIHRoZTxicj4m
Z3Q7IGJhY2tlbmQgWzFdPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsg
Jmd0OyBUaGFua3MsIEkgaGF2ZSBqdXN0Jm5ic3A7dHJpZWQmbmJzcDt0aGUgd29ya2Fyb3VuZC4g
VGhlIGJhY2tlbmQgaGFzJm5ic3A7ZmFpbGVkPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW4mbmJz
cDthbiBvdGhlciBwbGFjZSZuYnNwO25vdCBjb3JyZXNwb25kaW5nIHdpdGggZG1hX2J1Zi48YnI+
Jmd0OyAmZ3Q7ICZndDsgJmd0OyBBbnl3YXkmbmJzcDtpdCBpcyBlbm91Z2ggdG8gY29udGludWUm
bmJzcDtkZWJ1Z2dpbmcmbmJzcDsmbmJzcDtteTxicj4mZ3Q7ICZndDsgZnJvbnRlbmQmbmJzcDtp
bXBsZW1lbnRhdGlvbi48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBEbyB5b3UmbmJzcDtrbm93IGhv
dyBiaWcgaXMgcGVyZm9ybWFuY2UgcGVuYWx0eSBpbiBjb21wYXJpc29uIHdpdGg8YnI+Jmd0OyAm
Z3Q7ICZndDsgJmd0OyB0aGUmbmJzcDt6ZXJvLWNvcHkgdmFyaWFudD88YnI+Jmd0OyAmZ3Q7ICZn
dDsgV2VsbCwgaXQgc29sZWx5IGRlcGVuZHMgb24geW91ciBzZXR1cCwgc28gSSBjYW5ub3QgdGVs
bCB3aGF0PGJyPiZndDsgJmd0OyAmZ3Q7IHdvdWxkIHRoZSBudW1iZXJzIGJlIGluIHlvdXIgY2Fz
ZS4gQ29tcGFyaW5nIHRvIHdoYXQgSSBoYXZlPGJyPiZndDsgZG9lc24ndDxicj4mZ3Q7ICZndDsg
Jmd0OyBtYWtlIGFueSBzZW5zZSB0byBtZTogb25lIHNob3VsZCBjb21wYXJlIGFwcGxlcyB0byBh
cHBsZXM8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBEb2VzIGl0IG1ha2UgYSZuYnNwO3NlbnNlIGlm
IEkgbWFrZSBhJm5ic3A7ZGVkaWNhdGVkIEhWTSBkb21haW4gd2l0aDxicj4mZ3Q7ICZndDsgbGlu
dXggb25seTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZvciB0aGUgcHVycG9zZSBvZiZuYnNwO3Zk
aXNwbCBhbmQgdmtiZCBiYWNrZW5kcz8mbmJzcDtJcyB0aGVyZSBhPGJyPiZndDsgaG9wZSZuYnNw
O3RoaXM8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBhcHByb2FjaCB3aWxsIHdvcms/PGJyPiZndDsg
Jmd0OyAmZ3Q7IFlvdSBjYW4gdHJ5IGlmIHRoaXMgYXBwcm9hY2ggZml0cyB5b3VyIGRlc2lnbiBh
bmQgcmVxdWlyZW1lbnRzPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBKdWVyZ2VuPGJyPiZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFsxXTxicj4mZ3Q7ICZndDsg
Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7IDxhIGhyZWY9
Imh0dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJvb3BzL2Rpc3BsX2JlL2Jsb2IvbWFzdGVyL0NNYWtl
TGlzdHMudHh0I0wxMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJv
b3BzL2Rpc3BsX2JlL2Jsb2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0I0wxMjwvYT48YnI+Jmd0OyAm
bHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZ2l0aHViLmNv
bS94ZW4tdHJvb3BzL2Rpc3BsX2JlL2Jsb2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0KkwxMl9fO0l3
ISFHRl8yOWRiY1FJVUJQQSFrWjFKUUZSUzJwWGpfSXVYQmh2WWhtUDlRX3N2Y0x5akNYSzk0NjVV
TEdCNE1laVlQUnoyY0Y3bGVwSGdncjlVeFBVOXpPQkVVdyQiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlz
cGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdGXzI5ZGJjUUlVQlBB
IWtaMUpRRlJTMnBYal9JdVhCaHZZaG1QOVFfc3ZjTHlqQ1hLOTQ2NVVMR0I0TWVpWVBSejJjRjds
ZXBIZ2dyOVV4UFU5ek9CRVV3JDwvYT4mZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZsdDs8YSBo
cmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hlbi10
cm9vcHMvZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdGXzI5
ZGJjUUlVQlBBIWt2RGd5M1gwSXVTUWs3RDJEZHNHdHNqdHlHcm9ZYk5LT3JQRzk1T3B5b0FrdUJW
YkZTbXpvendmb3IwNWprUmwwaXRhMEZ1bUJ3JCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJs
ZGVmZW5zZS5jb20vdjMvX19odHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9iZS9i
bG9iL21hc3Rlci9DTWFrZUxpc3RzLnR4dCpMMTJfXztJdyEhR0ZfMjlkYmNRSVVCUEEha3ZEZ3kz
WDBJdVNRazdEMkRkc0d0c2p0eUdyb1liTktPclBHOTVPcHlvQWt1QlZiRlNtem96d2ZvcjA1amtS
bDBpdGEwRnVtQnckPC9hPiZndDs8YnI+Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZn
dDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2dpdGh1
Yi5jb20veGVuLXRyb29wcy9kaXNwbF9iZS9ibG9iL21hc3Rlci9DTWFrZUxpc3RzLnR4dCpMMTJf
XztJdyEhR0ZfMjlkYmNRSVVCUEEhZ2k4MW9aWk52V2FGV1VWbmFabHVBX21OQkFJdExNZDRSWm1u
Yy1NX0ZtbHBEb2pxZVFRblM3YVhTTmxibzgwcmU5dU9sMndxRkEkIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJvb3Bz
L2Rpc3BsX2JlL2Jsb2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0KkwxMl9fO0l3ISFHRl8yOWRiY1FJ
VUJQQSFnaTgxb1paTnZXYUZXVVZuYVpsdUFfbU5CQUl0TE1kNFJabW5jLU1fRm1scERvanFlUVFu
UzdhWFNObGJvODByZTl1T2wyd3FGQSQ8L2E+Jmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy
PiZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZsdDs8YSBocmVmPSJodHRwczov
L3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlzcGxf
YmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdGXzI5ZGJjUUlVQlBBIW16
M2duMXdRTVgyRFhlTnVBVi0xX2RJN254RllZWk9nZFBpSk5TRk1lc0N6OWxBek9LbHdWUGxkZGJ4
YmNMbVVPNDROT3kwVEZBJCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5jb20v
djMvX19odHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9iZS9ibG9iL21hc3Rlci9D
TWFrZUxpc3RzLnR4dCpMMTJfXztJdyEhR0ZfMjlkYmNRSVVCUEEhbXozZ24xd1FNWDJEWGVOdUFW
LTFfZEk3bnhGWVlaT2dkUGlKTlNGTWVzQ3o5bEF6T0tsd1ZQbGRkYnhiY0xtVU80NE5PeTBURkEk
PC9hPiZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJl
c3QgcmVnYXJkcyw8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgQWxleGFuZGVyIFN5Y2hl
djxicj4mZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPGJyPiZndDs8YnI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vZWxpeGlyLmJvb3Rs
aW4uY29tL2xpbnV4L3Y1LjUvc291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jI0wzMDAiIHRhcmdl
dD0iX2JsYW5rIj5odHRwczovL2VsaXhpci5ib290bGluLmNvbS9saW51eC92NS41L3NvdXJjZS9k
cml2ZXJzL3hlbi9nbnRkZXYuYyNMMzAwPC9hPjxicj5bMl0gPGEgaHJlZj0iaHR0cHM6Ly9lbGl4
aXIuYm9vdGxpbi5jb20vbGludXgvdjUuNS9zb3VyY2UvZHJpdmVycy94ZW4vZ250ZGV2LmMjTDMx
OSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZWxpeGlyLmJvb3RsaW4uY29tL2xpbnV4L3Y1LjUv
c291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jI0wzMTk8L2E+PC9kaXY+PC9kaXY+PC9kaXY+PC9k
aXY+PC9ibG9ja3F1b3RlPjxkaXY+Jm5ic3A7PC9kaXY+PC9CT0RZPjwvSFRNTD4K

----ALT--f6F3cBc2eD6085103965FcFaC2fC1e5B1587295574--

------f6F3cBc2eD6085103965FcFaC2fC1e5B-cwxOE3xDPrhw03v2-1587295574
Content-Type: application/octet-stream; name="=?UTF-8?B?cGF0Y2g=?="
Content-Disposition: attachment; filename="=?UTF-8?B?cGF0Y2g=?="
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3NyYy9kaXNwbGF5QmFja2VuZC9kcm0vRHVtYi5jcHAgYi9zcmMvZGlzcGxh
eUJhY2tlbmQvZHJtL0R1bWIuY3BwCmluZGV4IGY0MTI2YWEuLmJiMWYxZDIgMTAwNjQ0Ci0tLSBh
L3NyYy9kaXNwbGF5QmFja2VuZC9kcm0vRHVtYi5jcHAKKysrIGIvc3JjL2Rpc3BsYXlCYWNrZW5k
L2RybS9EdW1iLmNwcApAQCAtNTEsNiArNTEsNyBAQCBEdW1iQmFzZTo6RHVtYkJhc2UoaW50IGRy
bUZkLCB1aW50MzJfdCB3aWR0aCwgdWludDMyX3QgaGVpZ2h0KSA6CiAJbURybUZkKGRybUZkKSwK
IAltQnVmRHJtSGFuZGxlKDApLAogCW1TdHJpZGUoMCksCisJbUZyb250U3RyaWRlKDApLAogCW1X
aWR0aCh3aWR0aCksCiAJbUhlaWdodChoZWlnaHQpLAogCW1OYW1lKDApLApAQCAtOTMsNiArOTQs
OCBAQCB2b2lkIER1bWJCYXNlOjpjcmVhdGVEdW1iKHVpbnQzMl90IGJwcCkKIHsKIAlkcm1fbW9k
ZV9jcmVhdGVfZHVtYiBjcmVxIHswfTsKIAorCW1Gcm9udFN0cmlkZSA9IDQgKiAoKG1XaWR0aCAq
IGJwcCArIDMxKSAvIDMyKTsKKwogCWNyZXEud2lkdGggPSBtV2lkdGg7CiAJY3JlcS5oZWlnaHQg
PSBtSGVpZ2h0OwogCWNyZXEuYnBwID0gYnBwOwpAQCAtMTQ1LDggKzE0OCwxOCBAQCB2b2lkIER1
bWJEcm06OmNvcHkoKQogCX0KIAogCURMT0cobUxvZywgREVCVUcpIDw8ICJDb3B5IGR1bWIsIGhh
bmRsZTogIiA8PCBtQnVmRHJtSGFuZGxlOwotCi0JbWVtY3B5KG1CdWZmZXIsIG1HbnR0YWJCdWZm
ZXItPmdldCgpLCBtU2l6ZSk7CisJaWYobVN0cmlkZSA9PSBtRnJvbnRTdHJpZGUpCisJeworCQlt
ZW1jcHkobUJ1ZmZlciwgbUdudHRhYkJ1ZmZlci0+Z2V0KCksIG1TaXplKTsKKwkJcmV0dXJuOwor
CX0KKwlhdXRvIGRpZmYgPSAobVN0cmlkZSAtIG1Gcm9udFN0cmlkZSArIDEpIC8gMjsKKwlhdXRv
IHNyYyA9IHJlaW50ZXJwcmV0X2Nhc3Q8dW5zaWduZWQgY2hhcio+KG1HbnR0YWJCdWZmZXItPmdl
dCgpKTsKKwlhdXRvIGRzdCA9IHJlaW50ZXJwcmV0X2Nhc3Q8dW5zaWduZWQgY2hhcio+KG1CdWZm
ZXIpOworCWZvcih1bnNpZ25lZCBpbnQgaSA9IDA7IGkgPCBtSGVpZ2h0OyBpKyspCisJeworCQlt
ZW1jcHkoZHN0ICsgZGlmZiArIGkgKiBtU3RyaWRlLCBzcmMgKyBpICogbUZyb250U3RyaWRlLCBt
RnJvbnRTdHJpZGUpOworCX0KIH0KIAogLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKZGlmZiAtLWdp
dCBhL3NyYy9kaXNwbGF5QmFja2VuZC9kcm0vRHVtYi5ocHAgYi9zcmMvZGlzcGxheUJhY2tlbmQv
ZHJtL0R1bWIuaHBwCmluZGV4IDJhMTFiNWQuLjA0YTEzN2QgMTAwNjQ0Ci0tLSBhL3NyYy9kaXNw
bGF5QmFja2VuZC9kcm0vRHVtYi5ocHAKKysrIGIvc3JjL2Rpc3BsYXlCYWNrZW5kL2RybS9EdW1i
LmhwcApAQCAtODEsNiArODEsNyBAQCBwcm90ZWN0ZWQ6CiAJaW50IG1Ecm1GZDsKIAl1aW50MzJf
dCBtQnVmRHJtSGFuZGxlOwogCXVpbnQzMl90IG1TdHJpZGU7CisJdWludDMyX3QgbUZyb250U3Ry
aWRlOwogCXVpbnQzMl90IG1XaWR0aDsKIAl1aW50MzJfdCBtSGVpZ2h0OwogCXVpbnQzMl90IG1O
YW1lOwo=

------f6F3cBc2eD6085103965FcFaC2fC1e5B-cwxOE3xDPrhw03v2-1587295574--


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 02:41:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 02:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQMNG-0002HW-Kv; Mon, 20 Apr 2020 02:41:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JSG1=6E=intel.com=kevin.tian@srs-us1.protection.inumbo.net>)
 id 1jQMNF-0002HR-7a
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 02:41:29 +0000
X-Inumbo-ID: 6d89d956-82b0-11ea-9016-12813bfff9fa
Received: from mga09.intel.com (unknown [134.134.136.24])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6d89d956-82b0-11ea-9016-12813bfff9fa;
 Mon, 20 Apr 2020 02:41:25 +0000 (UTC)
IronPort-SDR: c+7WvAwjCRhlst9c5+Ne13W0w10FswryWkrR5TyLO+xt26voDYYSE3dQcroKPatOq2WhtxGBzs
 3lpQp4BfrvAw==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
 by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 19 Apr 2020 19:41:24 -0700
IronPort-SDR: T9VNeDHfCIh1jTN5Qen7Qbaz8Mojh7O7X3v+2MB5ZtIm7cZuQw/fCO/R9U+C1c7lHmOVJ859Ky
 er9o7WCbEmOA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,405,1580803200"; d="scan'208";a="456235582"
Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201])
 by fmsmga006.fm.intel.com with ESMTP; 19 Apr 2020 19:41:23 -0700
Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by
 FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Sun, 19 Apr 2020 19:41:19 -0700
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
 FMSMSX119.amr.corp.intel.com (10.18.124.207) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Sun, 19 Apr 2020 19:41:19 -0700
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.225]) by
 SHSMSX103.ccr.corp.intel.com ([169.254.4.146]) with mapi id 14.03.0439.000;
 Mon, 20 Apr 2020 10:41:17 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Roger Pau Monne <roger.pau@citrix.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
Subject: RE: [PATCH] x86/vtd: relax EPT page table sharing check
Thread-Topic: [PATCH] x86/vtd: relax EPT page table sharing check
Thread-Index: AQHWFKuYa2F4ckLYBUip3x2dtyt9faiBUOCw
Date: Mon, 20 Apr 2020 02:41:16 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D84B492@SHSMSX104.ccr.corp.intel.com>
References: <20200417112954.21250-1-roger.pau@citrix.com>
In-Reply-To: <20200417112954.21250-1-roger.pau@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

PiBGcm9tOiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPiBTZW50OiBG
cmlkYXksIEFwcmlsIDE3LCAyMDIwIDc6MzAgUE0NCj4gDQo+IFRoZSBFUFQgcGFnZSB0YWJsZXMg
Y2FuIGJlIHNoYXJlZCB3aXRoIHRoZSBJT01NVSBhcyBsb25nIGFzIHRoZSBwYWdlDQo+IHNpemVz
IHN1cHBvcnRlZCBieSBFUFQgYXJlIGFsc28gc3VwcG9ydGVkIGJ5IHRoZSBJT01NVS4NCj4gDQo+
IEN1cnJlbnQgY29kZSBjaGVja3MgdGhhdCBib3RoIHRoZSBJT01NVSBhbmQgRVBUIHN1cHBvcnQg
dGhlIHNhbWUgcGFnZQ0KPiBzaXplcywgYnV0IHRoaXMgaXMgbm90IHN0cmljdGx5IHJlcXVpcmVk
LCB0aGUgSU9NTVUgc3VwcG9ydGluZyBtb3JlDQo+IHBhZ2Ugc2l6ZXMgdGhhbiBFUFQgaXMgZmlu
ZSBhbmQgc2hvdWxkbid0IGJsb2NrIHBhZ2UgdGFibGUgc2hhcmluZy4NCj4gDQo+IFRoaXMgaXMg
bGlrZWx5IG5vdCBhIGNvbW1vbiBjYXNlIChJT01NVSBzdXBwb3J0aW5nIG1vcmUgcGFnZSBzaXpl
cw0KPiB0aGFuIEVQVCksIGJ1dCBzaG91bGQgc3RpbGwgYmUgZml4ZWQgZm9yIGNvcnJlY3RuZXNz
Lg0KPiANCj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJp
eC5jb20+DQoNClJldmlld2VkLWJ5OiBLZXZpbiBUaWFuIDxrZXZpbi50aWFuQGludGVsLmNvbT4N
Cg==


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 03:28:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 03:28:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQN6g-00066g-FB; Mon, 20 Apr 2020 03:28:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=JSG1=6E=intel.com=kevin.tian@srs-us1.protection.inumbo.net>)
 id 1jQN6f-00066Z-I7
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 03:28:25 +0000
X-Inumbo-ID: fc29dfe8-82b6-11ea-901c-12813bfff9fa
Received: from mga01.intel.com (unknown [192.55.52.88])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fc29dfe8-82b6-11ea-901c-12813bfff9fa;
 Mon, 20 Apr 2020 03:28:22 +0000 (UTC)
IronPort-SDR: zt5TGFxK9GnJbilXOEaAUpbu6EMAmzBJVEK1BEVdvvFDuVinpjj/WEJoDf/GXG51c+n0iTsdR1
 RPz+YOrGzkhg==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
 by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 19 Apr 2020 20:28:20 -0700
IronPort-SDR: nxhYMr9cNGfvlA95hWQwrf4g4yVzsjvb1AIUKMWwKQOq2Ec2hAnXz1UwGfnucXsZp+FKZxt11P
 R5Dj35xqIZBw==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,405,1580803200"; d="scan'208";a="456242835"
Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203])
 by fmsmga006.fm.intel.com with ESMTP; 19 Apr 2020 20:28:20 -0700
Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by
 FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Sun, 19 Apr 2020 20:28:20 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
 fmsmsx120.amr.corp.intel.com (10.18.124.208) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Sun, 19 Apr 2020 20:28:20 -0700
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.225]) by
 shsmsx102.ccr.corp.intel.com ([169.254.2.138]) with mapi id 14.03.0439.000;
 Mon, 20 Apr 2020 11:28:18 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Brendan Kerrigan <brendank310@gmail.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
Subject: RE: [PATCH 1/1] x86/vtd: Mask DMAR faults for IGD devices
Thread-Topic: [PATCH 1/1] x86/vtd: Mask DMAR faults for IGD devices
Thread-Index: AQHWFL1LsFJ5VBUZwEqsY3bDkrxGQKiBW4ZQ
Date: Mon, 20 Apr 2020 03:28:17 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D84C3FA@SHSMSX104.ccr.corp.intel.com>
References: <20200417133626.72302-1-brendank310@gmail.com>
 <20200417133626.72302-2-brendank310@gmail.com>
In-Reply-To: <20200417133626.72302-2-brendank310@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Brendan Kerrigan <kerriganb@ainfosec.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> From: Brendan Kerrigan <brendank310@gmail.com>
> Sent: Friday, April 17, 2020 9:36 PM
>=20
> From: Brendan Kerrigan <kerriganb@ainfosec.com>
>=20
> The Intel graphics device records DMAR faults regardless
> of the Fault Process Disable bit being set. When this fault

Since this is an errata for specific generations, let's describe
this way instead of stating it as a generic problem.

> occurs, enable the Interrupt Mask (IM) bit in the Fault
> Event Control (FECTL) register to prevent the continued
> recording of the fault.
>=20
> Signed-off-by: Brendan Kerrigan <kerriganb@ainfosec.com>
> ---
>  xen/drivers/passthrough/vtd/iommu.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>=20
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index 07d40b37fe..288399d816 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -41,6 +41,8 @@
>  #include "vtd.h"
>  #include "../ats.h"
>=20
> +#define IS_IGD(seg, id) (0 =3D=3D seg && 0 =3D=3D PCI_BUS(id) && 2 =3D=
=3D PCI_SLOT(id)
> && 0 =3D=3D PCI_FUNC(id))
> +
>  struct mapped_rmrr {
>      struct list_head list;
>      u64 base, end;
> @@ -872,6 +874,13 @@ static int iommu_page_fault_do_one(struct
> vtd_iommu *iommu, int type,
>      printk(XENLOG_G_WARNING VTDPREFIX "%s: reason %02x - %s\n",
>             kind, fault_reason, reason);
>=20
> +    if ( DMA_REMAP =3D=3D fault_type && type && IS_IGD(seg, source_id) )=
 {
> +        u32 fectl =3D dmar_readl(iommu->reg, DMAR_FECTL_REG);
> +        fectl |=3D DMA_FECTL_IM;
> +        dmar_writel(iommu->reg, DMAR_FECTL_REG, fectl);
> +        printk(XENLOG_G_WARNING VTDPREFIX "Disabling DMAR faults for
> IGD\n");
> +    }
> +

Several questions. First, I just note that FPD is not touched by any code
today. then how is this errata being caught? Second, we already have
pci_check_disable_device in place which stops DMAs from the problematic
device if it triggers excessive fault reports. why doesn't it work for your
case? Last, dma_msi_end just forces clearing the mask bit at end of handlin=
g
the fault interrupt, making above fix meaningless. Those questions just
make me wonder how you actually test this patch and whether it's necessary.=
..

Thanks
Kevin

>      if ( iommu_verbose && fault_type =3D=3D DMA_REMAP )
>          print_vtd_entries(iommu, PCI_BUS(source_id), PCI_DEVFN2(source_i=
d),
>                            addr >> PAGE_SHIFT);
> --
> 2.17.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 05:49:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 05:49:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQPIc-0000rM-03; Mon, 20 Apr 2020 05:48:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQPIa-0000rD-Et
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 05:48:52 +0000
X-Inumbo-ID: 9c7d1e48-82ca-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9c7d1e48-82ca-11ea-83d8-bc764e2007e4;
 Mon, 20 Apr 2020 05:48:51 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5EB13AE79;
 Mon, 20 Apr 2020 05:48:49 +0000 (UTC)
Subject: Re: [PATCH 01/10] x86/mm: no-one passes a NULL domain to
 init_xen_l4_slots()
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
 <19d7ad4f-c653-b7b6-59a8-90c9700c9200@suse.com>
 <68542638-b5d5-3261-8088-d0cd6e2dcd74@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <757e4a8b-f60d-1c5c-fe11-b1d22980f09e@suse.com>
Date: Mon, 20 Apr 2020 07:48:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <68542638-b5d5-3261-8088-d0cd6e2dcd74@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 21:46, Andrew Cooper wrote:
> On 17/04/2020 15:25, Jan Beulich wrote:
>> Drop the NULL checks - they've been introduced by commit 8d7b633ada
>> ("x86/mm: Consolidate all Xen L4 slot writing into
>> init_xen_l4_slots()") for no apparent reason.
> 
> :) I'll take this as conformation that all my sudden pagetable work in
> Xen manage ended up being rather more subtle than Linux's equivalent
> work for KPTI.
> 
> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00281.html
> 
> Specifically, this was part of trying to arrange for fully per-pcpu
> private mappings, and was used to construct the pagetables for the idle
> vcpu which specifically don't have a perdomain mapping.
> 
> Seeing as this is still an outstanding task in the secret-free-Xen
> plans, any dropping of it now will have to be undone at some point in
> the future.

s/will/may/ I suppose - we don't know for sure how this will look
like at this point.

>  Is there a specific reason for the cleanup?

Elimination of effectively dead code. We avoid arbitrary NULL checks
elsewhere as well; iirc I've seen you (amongst others) comment on
people trying to introduce such in their patches.

>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -1696,7 +1696,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t
> 
> If we continue with this patch, this comment, just out of context, needs
> adjusting.

Will do.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 05:59:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 05:59:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQPSZ-0001jR-18; Mon, 20 Apr 2020 05:59:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2WxG=6E=epam.com=oleksandr_andrushchenko@srs-us1.protection.inumbo.net>)
 id 1jQPSW-0001jM-PX
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 05:59:08 +0000
X-Inumbo-ID: 0b7d4556-82cc-11ea-9031-12813bfff9fa
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (unknown
 [40.107.15.77]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0b7d4556-82cc-11ea-9031-12813bfff9fa;
 Mon, 20 Apr 2020 05:59:07 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Zh0OFeWnqnjCJovAj0wPArdyMasg5u6LJ9HDsn3PkhAJeWRuHdZzKCJ4By+DS8rY//OqJRkIRrrgxJSvJ9H5NrmTsKrtRCHPU0pkWOVkm1oNrTsPIooQ9uyLwq0ZbRVOhBarJncJiPz/7Rp8m/kVky8k2jYiliqhn0HwjzZ5+SvtlZUsPf70TWR28wg+R9DfvZyUChMsLpz2+GuPl5PNH0wyMt1D1FpZKkf1BdWb/Lr9BVT0wzwL8di0FxrK2bZaoA2tJYYSAsWCMp7Z7vIzBZilFgaRG5zrj7PcpMjVuV6/5LC++9AEGf0I96xqC4wGAL37X11omy8uf05nN8fLJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fFLmBHJtYuxt5lRVe3PCXlbiNe6KNYeeUzbAAj6al0M=;
 b=KPrgjcQDpQSAAc+uwhBtc+AXw0kGEGzQYFvV6Gl/kLOlPwvvzYwWeeg0BiBciNrzXbNc6OwnvLN2ppWllw2PjYdVMe7XcA4oHIRX8DOGnSW8Qi6atbr0v4Nmg0N89pBCQQNA1/wEAmuP0phwO4TM3y/VpdDxXCtTwG+cKQTd1rxwF5/mjR8hgTtuztK/czJCHMf1cZs5JHGpiTeK6jIaX2WtCIPWP7cRwtR5uG8mcsfHJBZbOnIXeNJuLM0EC2sw5xwLFF6eHCS4YOTwEg+n7MV2ptIqG1e10OkKrNQPJrMz2Jzzt/16cf/58RMf4QpoMWho6IsnK/bzSYzjm+I85w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fFLmBHJtYuxt5lRVe3PCXlbiNe6KNYeeUzbAAj6al0M=;
 b=gEAL3HNle9tUTxhvaJbDf24TZJG7ZO4TELWmFVAEw7NCW5E3nCTmXVc0TtvPcr1NOvOgEwTB19wmTcy3Fxmn6BDfFJfAhVxv7/C6vDdZRJP6T1tT+h5Vj3sozt1hAOor8cmoNpBKqj5i8fuZKK9p8DMxhe3SPqZrNU08C6/q/uw=
Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14)
 by VI1PR03MB6173.eurprd03.prod.outlook.com (2603:10a6:800:142::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Mon, 20 Apr
 2020 05:59:03 +0000
Received: from VI1PR03MB3998.eurprd03.prod.outlook.com
 ([fe80::4144:ba6b:18cd:af5c]) by VI1PR03MB3998.eurprd03.prod.outlook.com
 ([fe80::4144:ba6b:18cd:af5c%7]) with mapi id 15.20.2921.027; Mon, 20 Apr 2020
 05:59:03 +0000
From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
To: Santucco <santucco@mail.ru>
Subject: Re: [Xen-devel] PV DRM doesn't work without auto_translated_physmap
 feature in Dom0
Thread-Topic: [Xen-devel] PV DRM doesn't work without auto_translated_physmap
 feature in Dom0
Thread-Index: AQHWFtjLJbeyGGW61EqaqZ4hjk3lQQ==
Date: Mon, 20 Apr 2020 05:59:02 +0000
Message-ID: <da633357-6c40-217f-e59d-d770da573240@epam.com>
References: <1580804903.724638150@f311.i.mail.ru>
 <1580929196.631103701@f331.i.mail.ru>
 <994358c4-2430-74ad-3c3a-923a01c33e51@epam.com>
 <1587295574.703588442@f508.i.mail.ru>
In-Reply-To: <1587295574.703588442@f508.i.mail.ru>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=Oleksandr_Andrushchenko@epam.com; 
x-originating-ip: [185.199.97.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fcf38858-d0be-4541-ce7f-08d7e4efedae
x-ms-traffictypediagnostic: VI1PR03MB6173:|VI1PR03MB6173:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <VI1PR03MB6173D3C5B2C689221BD5F3CCE7D40@VI1PR03MB6173.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03793408BA
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10009020)(4636009)(376002)(136003)(366004)(346002)(39860400002)(396003)(86362001)(71200400001)(26005)(6486002)(6506007)(36756003)(2616005)(186003)(2906002)(53546011)(5660300002)(31696002)(64756008)(66556008)(478600001)(6916009)(6512007)(8936002)(54906003)(107886003)(31686004)(4326008)(81156014)(966005)(66574012)(8676002)(66946007)(76116006)(316002)(66446008)(66476007);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: epam.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8bN1WkMQQJufcp2Cy/gujlMFz+bjQCVsDvfEr8zFIh8QIpeU3Nvi+oY4MQkUwaOfZoxBqTxllLexCuTpwKFKyHpe+IBU1CVWXxSb9Ti0KzyOZKKLPyBIW8GXONdjHHPdVffSF+SbHP9bZc94ctDUYbcXHfDDnU9VbTDcEShxUlaZ97B8ViFJstYPOByrwCmAj5wV+yf6kEdBTFanGYUBNrevOkF0tJhCR3cwvA7y2mzwTS0lobZUbB7KmvMHVscVE4oExx6MQ4ezwxLsjNINBFROYGhAHDn0mTP9IM8J0NVv5O7WuwHZRghCRu1lDm/qlxA2dWSoRaY9GIwynoXBgksdtyjVE6gv8XEErZ6ZoIPJFyQgydgzOdkfHewLKh4U5wwd44uiyja/AyTQhL+H8EcLYFmvrw0mFQHNfx3kUTROftol8/hhcz/JJ4XjRERZ1RCTB/zTDjGo+hyiqjqgLJ+gOF2U6KiRF/8VTeRR5upQEc4C/9KlSq+sgWQecZDyIVCJP4E2Ij6o2r7dCUu1XQ==
x-ms-exchange-antispam-messagedata: Ue88uvLOpCZS548SL0wZv6yDShfs5bOtkuH3wACQ1kLijF73WOVQ6948oFn5UJhqdsy2ayP9awSxBMPKMtslB4C4aiL/2RId8nal9vhvi7BLOMWya5Pe+nSvA3ohV8ZL7Sns6jZ2decvAjnpykIHDQR4y/VIro9ZcgSbc05uzRRj+80l8MCgqpny9QkO9R7Go2SDOCRJE5M1XIH7RbuO22rkmd58uGWnLG8M54PvgfHq5nhd5NaSfqqIjuPlBWomMmCZXozhdMVRL4KurYTljBxqNCiz6AWAl3Pquu7c0dNupzfxwArBDZfSthrukSSSSp8LH5dVUYYNxKpyTnRkD3Uquit3o81jRi9fRx/BUt0e2dRal64V5WEzreUKKHj+DWFX/l9OnETgyGQ5Gstod8emv3eRBBT3dbpcwAXkJmXbqka3AeSvvRGyJhuPx+c3cdqah+84M7eDJ2k8FEFXZtNHu08Ak/Xcadj18nA2lCiMn7XsTVddnYDEAFcy0eAZ4HJY0smt/QXwTgb63Orf2+eNuO6fNNMf67b813oP6yeM0JEl7kdYMB4wo+c+QGQgqdf3MSxznMj9poi2C5dNKL1TVS1UnJffTaN5ILz38AibL1PfHSbfWs+KyLS/GTkhEMseAgIu3Ari4BPF5ZfEwzVlcelBtZbjh/BnqK+Kk7cEhEOIAISCCp7L6iIcAB8KPjxfjPZ0nTJqX1Qm+rmNVa7oTGZRoqxeCfArirzRUTqYk1QwYjmmbnjUa48V9PWo8xUctqbMRov8t0qcP9LSplkNBm0Rk2toqFLyVwbrB64=
Content-Type: text/plain; charset="utf-8"
Content-ID: <B705F37FAF089E418AFBD96B4A0C5A26@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fcf38858-d0be-4541-ce7f-08d7e4efedae
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2020 05:59:03.0738 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4Z0jJet4V+NzbLziSQZEHp5EyVs/3IPwSEtVv0YEPTzAZ63tPRhrNj6TRBQ+GS/RwcUNSlMwU8IV4UWNk8NLq/lJ4rOi/Nlnzw3hBxZquYPDXC5U8fuqbhSE6ei7E7Fs
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6173
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Oleksandr Grytsov <Oleksandr_Grytsov@epam.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

SGksDQoNCk9uIDQvMTkvMjAgMTQ6MjYsIFNhbnR1Y2NvIHdyb3RlOg0KPiBIZWxsbywNCj4gSSBo
YXZlIGZvdW5kIGEgc291cmNlIG9mIHRoZSBwcm9ibGVtLg0KPiBJbiBkaXNwbF9iZSzCoCBCYXNl
RHVtcCBjb3BpZXMgdG8gdGhlIGRybSBidWZmZXIgd2l0aCBhwqBzaXplIGZyb20gDQo+IGk5MTXC
oGRybSBkcml2ZXIsIGJ1dCB0aGlzIHNpemUgYSBiaXQgbW9yZSB0aGFuIGHCoHNpemUgb2bCoG15
IGZyb250ZW5kIA0KPiBkaXNwbGF5IGJ1ZmZlci4gSSBoYXZlIG1hZGUgYSBxdWljayBhbmQgZGly
dHnCoGZpeCzCoGEgY29wecKgYSBsaW5lIG9mIG15IA0KPiBkaXNwbGF5IGJ1ZmZlciB0byBhIG1p
ZGRsZSBvZiBhwqBsaW5lIG9mwqB0aGXCoGRybSBkaXNwbGF5IGJ1ZmZlci4gUGF0Y2ggDQo+IGlz
IGF0dGFjaGVkLg0KDQpUaGFuayB5b3UgZm9yIHRoZSBwYXRjaCBhbmQgeW91ciBlZmZvcnRzIHRv
IGZpeCB0aGUgaXNzdWUuDQoNCkNvdWxkIHlvdSBwbGVhc2UgbWFrZSBhIHB1bGwgcmVxdWVzdCB0
byBbMV0sIHNvIHdlIGNhbiBjb250aW51ZSB0aGVyZT8NCg0KVGhhbmsgeW91IGluIGFkdmFuY2Us
DQoNCk9sZWtzYW5kcg0KDQo+IEJlc3QgcmVnYXJkcywNCj4gQWxleGFuZGVyDQo+DQo+ICAgICDQ
p9C10YLQstC10YDQsywgNiDRhNC10LLRgNCw0LvRjyAyMDIwLCAxMToyMCArMDM6MDAg0L7RgiBP
bGVrc2FuZHIgQW5kcnVzaGNoZW5rbw0KPiAgICAgPG9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVw
YW0uY29tPjoNCj4gICAgIE9uIDIvNS8yMCA4OjU5IFBNLCBTYW50dWNjbyB3cm90ZToNCj4gICAg
ID4gSGVsbG8sDQo+ICAgICA+IE9rLCBJwqAgY29tbWVudGVkIG91dCB0aGUgbWVtY3B5IGNhbGwg
YW5kIHJ1bsKgdGhlIHRlc3QuDQo+ICAgICA+IGRpc3BsX2JlIGhhc27igJl0IGNyYWNoZWQsIEkg
aGF2ZcKgc2VlbiBGTElQIGV2ZW50cyBpbiB0aGUgbG9nLg0KPiAgICAgPiBCdXQgdGhlcmUgaGFz
buKAmXQgYmVlbsKgdGhlwqBibGFjayBzY3JlZW4sIGp1c3QgYcKgYmxpbmsgZWZmZWN0IGV2ZXJ5
DQo+ICAgICA+IGNvdXBsZSBvZiBzZWNvbmRzLg0KPiAgICAgPiBMb2dzIGFyZSBhdHRhY2hlZC4N
Cj4gICAgIE9rLCBzbyBJIGJlbGlldmUgdGhhdCBmcm9udGVuZCAtIGJhY2tlbmQgKGRpc3BsX2Jl
KSBjb21tdW5pY2F0aW9uDQo+ICAgICBpcyBvaw0KPiAgICAgYW5kIHRoZXJlIGlzIG5vdGhpbmcg
dG8gZG8gdGhlcmUuDQo+DQo+ICAgICBOZXh0LCBJIHdvdWxkIHN0YXJ0IGRlYnVnZ2luZyB0aGUg
Zm9sbG93aW5nIGluIFhlbjoNCj4gICAgIChYRU4pIG1tLmM6MjIyMzpkMnYwIEJhZCBMMSBmbGFn
cyA4MA0KPiAgICAgYW5kIGhhdmUgYSBsb29rIGF0IFsxXS4gUHJvYmFibHksIHNvbWVvbmUgb24g
WGVuIHg4NiBzaWRlIGNhbiB0ZWxsDQo+ICAgICBpZiB0aGlzIGNvdWxkIGJlIHJlbGF0ZWQgdG8g
dGhlIGZsYWdzIGF0IFsyXS4NCj4NCj4gICAgID4gQmVzdCByZWdhcmRzLA0KPiAgICAgPiBBbGV4
YW5kZXINCj4gICAgID4NCj4gICAgID4g0KHRgNC10LTQsCwgNSDRhNC10LLRgNCw0LvRjyAyMDIw
LCA5OjMxICswMzowMCDQvtGCIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvDQo+ICAgICA+IDxvbGVr
c2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbQ0KPiAgICAgPC9jb21wb3NlP1RvPW9sZWtzYW5k
cl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPj46DQo+ICAgICA+IE9uIDIvNC8yMCAxMDoyOCBBTSwg
U2FudHVjY28gd3JvdGU6DQo+ICAgICA+ID4gSGVsbG8sDQo+ICAgICA+ID4gZGlzcGxfYmUgd2Fz
IGNvbXBpbGVkwqB3aXRob3V0IHplcm8tY29weSBzdXBwb3J0IGVhcmx5Lg0KPiAgICAgPiA+IEkg
aGF2ZSB0cmllZCB3aXRoIHRoZcKgcmVjb21waWxlZCBkb20wIGtlcm5lbCwgYSByZXN1bHQgaXPC
oHRoZQ0KPiAgICAgc2FtZS4NCj4gICAgID4gPiBMb2dzIGFuZCBjb25maWdzICgrZGlzcGxfYmXi
gJlzwqBDTWFrZUNhY2hlLnR4dMKgKSBhcmUgYXR0YWNoZWQuDQo+ICAgICA+IE9rLCB5ZXQgYW5v
dGhlciB0ZXN0IHRvIGxvY2FsaXplIHRoZSBwcm9ibGVtLg0KPiAgICAgPiBDb3VsZCB5b3UgcGxl
YXNlIHJlbW92ZSBtZW1jcHkgZnJvbQ0KPiAgICAgPiAjMcKgIDB4MDAwMDU1ZTVhMWYyOGJlYyBp
biBEcm06OkR1bWJEcm06OmNvcHkNCj4gICAgICh0aGlzPTB4N2Y5MzM4MDAwZTAwKSBhdA0KPiAg
ICAgPg0KPiAgICAgL2hvbWUvc2FudHVjY28vdG1wL3hlbi10cm9vcHMvZGlzcGxfYmUvc3JjL2Rp
c3BsYXlCYWNrZW5kL2RybS9EdW1iLmNwcDoxNDkNCj4gICAgID4gYW5kIGp1c3QgbWVtc2V0IHRo
ZSBkZXN0aW5hdGlvbiB3aXRoIDAgb3Igd2hhdGV2ZXIuDQo+ICAgICA+DQo+ICAgICA+IEkgZXhw
ZWN0IHRoYXQgc3lzdGVtIHdvbid0IGNyYXNoLCBub3RoaW5nIHdpbGwgYmUgc2hvd24gKGJsYWNr
DQo+ICAgICA+IHNjcmVlbiksIGJ1dA0KPiAgICAgPiBkaXNwbF9iZSB3aWxsIHNob3cgcGFnZSBm
bGlwIGV2ZW50cyBpbiBpdHMgbG9ncy4NCj4gICAgID4gPiBCZXN0IHJlZ2FyZHMsDQo+ICAgICA+
ID4gQWxleGFuZGVyDQo+ICAgICA+ID4NCj4gICAgID4gPiDQn9C+0L3QtdC00LXQu9GM0L3QuNC6
LCAzINGE0LXQstGA0LDQu9GPIDIwMjAsIDEwOjM2ICswMzowMCDQvtGCIE9sZWtzYW5kcg0KPiAg
ICAgPiA+IEFuZHJ1c2hjaGVua28gPG9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tDQo+
ICAgICA8L2NvbXBvc2U/VG89b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20+DQo+ICAg
ICA+IDwvY29tcG9zZT9Ubz1vbGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbT4+Og0KPiAg
ICAgPiA+DQo+ICAgICA+ID4NCj4gICAgID4gPiBPbiAyLzEvMjAgNDozOSBQTSwgU2FudHVjY28g
d3JvdGU6DQo+ICAgICA+ID4gPiBIZWxsbyBhZ2FpbiwNCj4gICAgID4gPiA+IEkgaGF2ZSBub3Qg
eWV0IG1hZGUgdG8gd29yayBteSBkcm0gY2xpZW50LCBzbyBJIGhhdmUgdHJpZWQNCj4gICAgIHRv
IHJ1bg0KPiAgICAgPiA+ID4gbGludXggbGlrZSBhIGRvbVXCoCh0byBzZWUgaG93IGl0IHNob3Vs
ZCB3b3JrKSwgaXQgZG9lc27igJl0DQo+ICAgICB3b3JrIHRvbw0KPiAgICAgPiA+ID4g4oCUwqBk
aXNwbF9iZSBjYXRjaGVzIFNJR1NFR1Y6DQo+ICAgICA+ID4gPg0KPiAgICAgPiA+ID4gIzAgwqAw
eDAwMDA3ZjRhZmVkMWMxNjEgaW4gPz8gKCkgZnJvbSAvbGliNjQvbGliYy5zby42DQo+ICAgICA+
ID4gPiAjMSDCoDB4MDAwMDU1NzIzYjljNWJlYyBpbiBEcm06OkR1bWJEcm06OmNvcHkNCj4gICAg
ID4gPiAodGhpcz0weDdmNGFkYzAwMGUwMCkgYXQNCj4gICAgID4gPiA+DQo+ICAgICA+ID4NCj4g
ICAgID4NCj4gICAgIC9ob21lL3NhbnR1Y2NvL3RtcC94ZW4tdHJvb3BzL2Rpc3BsX2JlL3NyYy9k
aXNwbGF5QmFja2VuZC9kcm0vRHVtYi5jcHA6MTQ5DQo+ICAgICA+ID4gPiAjMiDCoDB4MDAwMDU1
NzIzYjlhOGY1MSBpbiBCdWZmZXJzU3RvcmFnZTo6Z2V0RnJhbWVCdWZmZXJBbmRDb3B5DQo+ICAg
ICA+ID4gPiAodGhpcz0weDdmNGFlMDAwMTBlMCwgZmJDb29raWU9MTg0NDY2MTI2ODIyOTUwODMy
NjQpIGF0DQo+ICAgICA+ID4gPg0KPiAgICAgPiA+DQo+ICAgICA+DQo+ICAgICAvaG9tZS9zYW50
dWNjby90bXAveGVuLXRyb29wcy9kaXNwbF9iZS9zcmMvZGlzcGxheUJhY2tlbmQvQnVmZmVyc1N0
b3JhZ2UuY3BwOjE2NQ0KPiAgICAgPiA+ID4gSXQgdHJpZXMgdG8gY29weSB0byBtQnVmZmVyIHdp
dGggbm9uLWFjY2Vzc2libGUgYWRkcmVzcy4NCj4gICAgID4gPiA+IEZvciB0aGUgbW9tZW50IEkg
c2VlIGHCoHN0cmFuZ2Ugb2Zmc2V0IGZvciBtbWFwIGNhbGwgb2YNCj4gICAgID4gPiAvZGV2L2Ry
bS9jYXJkMA0KPiAgICAgPiA+ID4gaW4gdGhlIHN0cmFjZSBsb2cg4oCUwqAweDEwMDAwMDAwMC4g
SXMgdGhhdCBub3JtYWw/DQo+ICAgICA+ID4gPiBBbnkgZGlyZWN0aW9uIG9mIHdoaWNowqB0byBk
aWcgd2lsbCBiZSB2ZXJ5IGhlbHBmdWwuDQo+ICAgICA+ID4gPiBDb25maWd1cmF0aW9uIGRldGFp
bHM6DQo+ICAgICA+ID4gPiBYZW4gNC4xMi4xIERvbTA6IExpbnV4IDQuMjAuMTctZ2VudG9vICMx
MyBTTVAgU2F0IERlYyAyOA0KPiAgICAgPiA+IDExOjEyOjI0IE1TSw0KPiAgICAgPiA+ID4gMjAx
OSB4ODZfNjQgSW50ZWwoUikgQ2VsZXJvbihSKSBDUFUgTjMwNTAgQCAxLjYwR0h6IEdlbnVpbmVJ
bnRlbA0KPiAgICAgPiA+IEdOVS9MaW51eA0KPiAgICAgPiA+ID4gRG9tVTogTGludXggNC4yMC4x
Ny1nZW50b28NCj4gICAgID4gPiA+IGxhc3QgeGVuLXRyb29wcy9saWJ4ZW5iZSBhbmQgeGVuLXRy
b29wcy9kaXNwbF9iZQ0KPiAgICAgPiA+ID4gTG9ncyAoZG1lc2csIHhsIGRtZXNnLCBkaXNwbF9i
ZSwgc3RyYWNlIGxvZyBvZiBkaXNwbF9iZSksIGENCj4gICAgID4gPiBiYWNrdHJhY2UNCj4gICAg
ID4gPiA+IG9mIGdkYiBhbmQga2VybmVsIGNvbmZpZ3MgYXJlIGF0dGFjaGVkLg0KPiAgICAgPiA+
ID4gVGhhbmtzIGluIGFkdmFuY2UuDQo+ICAgICA+ID4gQ291bGQgeW91IHBsZWFzZSB0cnkgRG9t
MCBrZXJuZWwgV0lUSE9VVCB0aGUgb3B0aW9ucyBiZWxvdzoNCj4gICAgID4gPiBDT05GSUdfWEVO
X0dOVERFVl9ETUFCVUY9eQ0KPiAgICAgPiA+IENPTkZJR19YRU5fR1JBTlRfRE1BX0FMTE9DPXkN
Cj4gICAgID4gPg0KPiAgICAgPiA+IFRoZW4sIGp1c3QgdG8gbWFrZSBzdXJlLCBkaWQgeW91IGJ1
aWxkIGRpc3BsX2JlIHdpdGhvdXQgemVyby1jb3B5DQo+ICAgICA+ID4gc3VwcG9ydD8NCj4gICAg
ID4gPg0KPiAgICAgPiA+ID4gT24gMS84LzIwIDU6MzggUE0sIFNhbnR1Y2NvIHdyb3RlOg0KPiAg
ICAgPiA+ID4gPiBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciBhbGwgeW91ciBhbnN3ZXJzLg0KPiAg
ICAgPiA+ID4gPg0KPiAgICAgPiA+ID4gPiDQodGA0LXQtNCwLCA4INGP0L3QstCw0YDRjyAyMDIw
LCAxMDo1NCArMDM6MDAg0L7RgiBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbw0KPiAgICAgPiA+ID4g
PiA8b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20NCj4gICAgIDwvY29tcG9zZT9Ubz1v
bGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbT4NCj4gICAgID4gPC9jb21wb3NlP1RvPW9s
ZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPg0KPiAgICAgPiA+ID4gPiA8L2NvbXBvc2U/
VG89b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20+PjoNCj4gICAgID4gPiA+ID4gT24g
MS82LzIwIDEwOjM4IEFNLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPiAgICAgPiA+ID4gPiA+IE9u
IDA2LjAxLjIwIDA4OjU2LCBTYW50dWNjbyB3cm90ZToNCj4gICAgID4gPiA+ID4gPj4gSGVsbG8s
DQo+ICAgICA+ID4gPiA+ID4+DQo+ICAgICA+ID4gPiA+ID4+IEnigJltIHRyeWluZyB0byB1c2Ug
dmRpc3BsIGludGVyZmFjZSBmcm9tIFBWIE9TLCBpdCBkb2VzbuKAmXQNCj4gICAgID4gd29yay4N
Cj4gICAgID4gPiA+ID4gPj4gQ29uZmlndXJhdGlvbiBkZXRhaWxzOg0KPiAgICAgPiA+ID4gPiA+
PiDCoMKgwqDCoCBYZW4gNC4xMi4xDQo+ICAgICA+ID4gPiA+ID4+IMKgwqDCoMKgIERvbTA6IExp
bnV4IDQuMjAuMTctZ2VudG9vICMxMyBTTVAgU2F0IERlYyAyOA0KPiAgICAgPiAxMToxMjoyNCBN
U0sNCj4gICAgID4gPiA+ID4gMjAxOQ0KPiAgICAgPiA+ID4gPiA+PiB4ODZfNjQgSW50ZWwoUikg
Q2VsZXJvbihSKSBDUFUgTjMwNTAgQCAxLjYwR0h6IEdlbnVpbmVJbnRlbA0KPiAgICAgPiA+ID4g
PiBHTlUvTGludXgNCj4gICAgID4gPiA+ID4gPj4gwqDCoMKgwqAgRG9tVTogeDg2wqBQbGFuOSwg
UFYNCj4gICAgID4gPiA+ID4gPj4gZGlzcGxfYmUgYXMgYSBiYWNrZW5kIGZvciB2ZGlzcGwgYW5k
IHZrYg0KPiAgICAgPiA+ID4gPiA+Pg0KPiAgICAgPiA+ID4gPiA+PiB3aGVuIFZNIHN0YXJ0cywg
ZGlzcGxfYmUgcmVwb3J0cyBhYm91dCBhbiBlcnJvcjoNCj4gICAgID4gPiA+ID4gPj4gZ250dGFi
OiBlcnJvcjogaW9jdGwgRE1BQlVGX0VYUF9GUk9NX1JFRlMgZmFpbGVkOiBJbnZhbGlkDQo+ICAg
ICA+ID4gYXJndW1lbnQNCj4gICAgID4gPiA+ID4gPj4gKGRpc3BsX2JlLmxvZzoyMjEpDQo+ICAg
ICA+ID4gPiA+ID4+DQo+ICAgICA+ID4gPiA+ID4+IHJlbGF0ZWTCoERvbTAgb3V0cHV0IGlzOg0K
PiAgICAgPiA+ID4gPiA+PiBbIDE5MS41NzkyNzhdIENhbm5vdCBwcm92aWRlIGRtYS1idWY6IHVz
ZV9wdGVtb2RlIDENCj4gICAgID4gPiA+ID4gPj4gKGRtZXNnLmNyZWF0ZS5sb2c6MTIzKQ0KPiAg
ICAgPiA+ID4gPiA+DQo+ICAgICA+ID4gPiA+ID4gVGhpcyBzZWVtcyB0byBiZSBhIGxpbWl0YXRp
b24gb2YgdGhlIHhlbiBkbWEtYnVmIGRyaXZlci4NCj4gICAgID4gSXQgd2FzDQo+ICAgICA+ID4g
PiA+IHdyaXR0ZW4NCj4gICAgID4gPiA+ID4gPiBmb3IgYmVpbmcgdXNlZCBvbiBBUk0gaW5pdGlh
bGx5IHdoZXJlIFBWIGlzIG5vdCBhdmFpbGFibGUuDQo+ICAgICA+ID4gPiA+IFRoaXMgaXMgdHJ1
ZSBhbmQgd2UgbmV2ZXIgdHJpZWQvdGFyZ2V0ZWQgUFYgZG9tYWlucyB3aXRoIHRoaXMNCj4gICAg
ID4gPiA+ID4gaW1wbGVtZW50YXRpb24sDQo+ICAgICA+ID4gPiA+IHNvIGlmIHRoZXJlIGlzIGEg
bmVlZCBmb3IgdGhhdCBzb21lb25lIGhhcyB0byB0YWtlIGEgbG9vaw0KPiAgICAgb24gdGhlDQo+
ICAgICA+ID4gPiA+IHByb3Blcg0KPiAgICAgPiA+ID4gPiBpbXBsZW1lbnRhdGlvbiBmb3IgUFbi
gKYNCj4gICAgID4gPiA+ID4NCj4gICAgID4gPiA+ID4gSGF2ZSBJIGdvdCB5b3VyIHJpZ2h0IGFu
ZCB0aGVyZSBpcyBub8KgdGhlIHByb3Blcg0KPiAgICAgPiA+IGltcGxlbWVudGF0aW9uIDotKT8N
Cj4gICAgID4gPiA+IFRoZXJlIGlzIG5vDQo+ICAgICA+ID4gPiA+DQo+ICAgICA+ID4gPiA+ID4N
Cj4gICAgID4gPiA+ID4gPiBDQy1pbmcgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gd2hvIGlzIHRo
ZSBhdXRob3Igb2YgdGhhdA0KPiAgICAgPiA+IGRyaXZlci4gSGUNCj4gICAgID4gPiA+ID4gPiBz
aG91bGQgYmUgYWJsZSB0byB0ZWxsIHVzIHdoYXQgd291bGQgYmUgbmVlZGVkIHRvIGVuYWJsZSBQ
Vg0KPiAgICAgPiA+IGRvbTAuDQo+ICAgICA+ID4gPiA+ID4NCj4gICAgID4gPiA+ID4gPiBEZXBl
bmRpbmcgb24geW91ciB1c2UgY2FzZSBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byB1c2UgUFZIDQo+
ICAgICA+ID4gZG9tMCwgYnV0DQo+ICAgICA+ID4gPiA+ID4gc3VwcG9ydCBmb3IgdGhpcyBtb2Rl
IGlzICJleHBlcmltZW50YWwiIG9ubHkgYW5kIHNvbWUNCj4gICAgIGZlYXR1cmVzDQo+ICAgICA+
ID4gPiA+IGFyZSBub3QNCj4gICAgID4gPiA+ID4gPiB5ZXQgd29ya2luZy4NCj4gICAgID4gPiA+
ID4gPg0KPiAgICAgPiA+ID4gPiBXZWxsLCBvbmUgb2YgdGhlIHdvcmthcm91bmRzIHBvc3NpYmxl
IGlzIHRvIGRyb3AgemVyby1jb3B5aW5nDQo+ICAgICA+ID4gdXNlLWNhc2UNCj4gICAgID4gPiA+
ID4gKHRoaXMgaXMgd2h5IGRpc3BsYXkgYmFja2VuZCB0cmllcyB0byBjcmVhdGUgZG11LWJ1ZnMg
ZnJvbQ0KPiAgICAgPiBncmFudHMNCj4gICAgID4gPiA+ID4gcGFzc2VkDQo+ICAgICA+ID4gPiA+
IGJ5IHRoZSBndWVzdCBkb21haW4gYW5kIGZhaWxzIGJlY2F1c2Ugb2YgIkNhbm5vdCBwcm92aWRl
DQo+ICAgICA+IGRtYS1idWY6DQo+ICAgICA+ID4gPiA+IHVzZV9wdGVtb2RlIDEiKQ0KPiAgICAg
PiA+ID4gPiBTbywgaW4gdGhpcyBjYXNlIGRpc3BsYXkgYmFja2VuZCB3aWxsIGRvIG1lbW9yeSBj
b3B5aW5nDQo+ICAgICBmb3IgdGhlDQo+ICAgICA+ID4gPiA+IGluY29taW5nDQo+ICAgICA+ID4g
PiA+IGZyYW1lcw0KPiAgICAgPiA+ID4gPiBhbmQgd29uJ3QgdG91Y2ggRE1BQlVGX0VYUF9GUk9N
X1JFRlMgaW9jdGwuDQo+ICAgICA+ID4gPiA+IFRvIGRvIHNvIGp1c3QgZGlzYWJsZSB6ZXJvLWNv
cHlpbmcgd2hpbGUgYnVpbGRpbmcgdGhlDQo+ICAgICA+IGJhY2tlbmQgWzFdDQo+ICAgICA+ID4g
PiA+DQo+ICAgICA+ID4gPiA+IFRoYW5rcywgSSBoYXZlIGp1c3TCoHRyaWVkwqB0aGUgd29ya2Fy
b3VuZC4gVGhlIGJhY2tlbmQNCj4gICAgIGhhc8KgZmFpbGVkDQo+ICAgICA+ID4gPiA+IGluwqBh
biBvdGhlciBwbGFjZcKgbm90IGNvcnJlc3BvbmRpbmcgd2l0aCBkbWFfYnVmLg0KPiAgICAgPiA+
ID4gPiBBbnl3YXnCoGl0IGlzIGVub3VnaCB0byBjb250aW51ZcKgZGVidWdnaW5nwqDCoG15DQo+
ICAgICA+ID4gZnJvbnRlbmTCoGltcGxlbWVudGF0aW9uLg0KPiAgICAgPiA+ID4gPiBEbyB5b3XC
oGtub3cgaG93IGJpZyBpcyBwZXJmb3JtYW5jZSBwZW5hbHR5IGluIGNvbXBhcmlzb24gd2l0aA0K
PiAgICAgPiA+ID4gPiB0aGXCoHplcm8tY29weSB2YXJpYW50Pw0KPiAgICAgPiA+ID4gV2VsbCwg
aXQgc29sZWx5IGRlcGVuZHMgb24geW91ciBzZXR1cCwgc28gSSBjYW5ub3QgdGVsbCB3aGF0DQo+
ICAgICA+ID4gPiB3b3VsZCB0aGUgbnVtYmVycyBiZSBpbiB5b3VyIGNhc2UuIENvbXBhcmluZyB0
byB3aGF0IEkgaGF2ZQ0KPiAgICAgPiBkb2Vzbid0DQo+ICAgICA+ID4gPiBtYWtlIGFueSBzZW5z
ZSB0byBtZTogb25lIHNob3VsZCBjb21wYXJlIGFwcGxlcyB0byBhcHBsZXMNCj4gICAgID4gPiA+
ID4gRG9lcyBpdCBtYWtlIGHCoHNlbnNlIGlmIEkgbWFrZSBhwqBkZWRpY2F0ZWQgSFZNIGRvbWFp
biB3aXRoDQo+ICAgICA+ID4gbGludXggb25seQ0KPiAgICAgPiA+ID4gPiBmb3IgdGhlIHB1cnBv
c2Ugb2bCoHZkaXNwbCBhbmQgdmtiZCBiYWNrZW5kcz/CoElzIHRoZXJlIGENCj4gICAgID4gaG9w
ZcKgdGhpcw0KPiAgICAgPiA+ID4gPiBhcHByb2FjaCB3aWxsIHdvcms/DQo+ICAgICA+ID4gPiBZ
b3UgY2FuIHRyeSBpZiB0aGlzIGFwcHJvYWNoIGZpdHMgeW91ciBkZXNpZ24gYW5kIHJlcXVpcmVt
ZW50cw0KPiAgICAgPiA+ID4gPg0KPiAgICAgPiA+ID4gPiA+DQo+ICAgICA+ID4gPiA+ID4gSnVl
cmdlbg0KPiAgICAgPiA+ID4gPiA+DQo+ICAgICA+ID4gPiA+IFsxXQ0KPiAgICAgPiA+ID4gPg0K
PiAgICAgPiA+ID4NCj4gICAgID4gPg0KPiAgICAgPg0KPiAgICAgaHR0cHM6Ly9naXRodWIuY29t
L3hlbi10cm9vcHMvZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQjTDEyDQo+ICAg
ICA8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJv
b3BzL2Rpc3BsX2JlL2Jsb2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0KkwxMl9fO0l3ISFHRl8yOWRi
Y1FJVUJQQSFtaGxRQVBTX096eTU3eGFfME9SNjZxYzFtamxTRXo3bGozTWtXQ3lEREY5MUJHYTdK
Ny1CT1lXWWNka3NwbG9jWnZ4SVpNaXJXZyQ+DQo+ICAgICA+DQo+ICAgICA8aHR0cHM6Ly91cmxk
ZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJvb3BzL2Rpc3BsX2JlL2Js
b2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0KkwxMl9fO0l3ISFHRl8yOWRiY1FJVUJQQSFrWjFKUUZS
UzJwWGpfSXVYQmh2WWhtUDlRX3N2Y0x5akNYSzk0NjVVTEdCNE1laVlQUnoyY0Y3bGVwSGdncjlV
eFBVOXpPQkVVdyQ+DQo+ICAgICA+ID4NCj4gICAgID4NCj4gICAgIDxodHRwczovL3VybGRlZmVu
c2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlzcGxfYmUvYmxvYi9t
YXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdGXzI5ZGJjUUlVQlBBIWt2RGd5M1gwSXVT
UWs3RDJEZHNHdHNqdHlHcm9ZYk5LT3JQRzk1T3B5b0FrdUJWYkZTbXpvendmb3IwNWprUmwwaXRh
MEZ1bUJ3JD4NCj4gICAgID4gPiA+DQo+ICAgICA+ID4NCj4gICAgID4NCj4gICAgIDxodHRwczov
L3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlzcGxf
YmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdGXzI5ZGJjUUlVQlBBIWdp
ODFvWlpOdldhRldVVm5hWmx1QV9tTkJBSXRMTWQ0UlptbmMtTV9GbWxwRG9qcWVRUW5TN2FYU05s
Ym84MHJlOXVPbDJ3cUZBJD4NCj4gICAgID4gPiA+ID4NCj4gICAgID4gPiA+DQo+ICAgICA+ID4N
Cj4gICAgID4NCj4gICAgIDxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRo
dWIuY29tL3hlbi10cm9vcHMvZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEy
X187SXchIUdGXzI5ZGJjUUlVQlBBIW16M2duMXdRTVgyRFhlTnVBVi0xX2RJN254RllZWk9nZFBp
Sk5TRk1lc0N6OWxBek9LbHdWUGxkZGJ4YmNMbVVPNDROT3kwVEZBJD4NCj4gICAgID4gPiA+ID4N
Cj4gICAgID4gPiA+ID4gQmVzdCByZWdhcmRzLA0KPiAgICAgPiA+ID4gPiDCoCBBbGV4YW5kZXIg
U3ljaGV2DQo+ICAgICA+ID4gPg0KPiAgICAgPiA+DQo+ICAgICA+ID4NCj4gICAgID4NCj4gICAg
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgPg0KPiAgICAgWzFdDQo+ICAgICBodHRwczovL2VsaXhp
ci5ib290bGluLmNvbS9saW51eC92NS41L3NvdXJjZS9kcml2ZXJzL3hlbi9nbnRkZXYuYyNMMzAw
DQo+ICAgICA8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZWxpeGlyLmJvb3Rs
aW4uY29tL2xpbnV4L3Y1LjUvc291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jKkwzMDBfXztJdyEh
R0ZfMjlkYmNRSVVCUEEhbWhsUUFQU19Penk1N3hhXzBPUjY2cWMxbWpsU0V6N2xqM01rV0N5RERG
OTFCR2E3SjctQk9ZV1ljZGtzcGxvY1p2em42ZmxrNlEkPg0KPiAgICAgWzJdDQo+ICAgICBodHRw
czovL2VsaXhpci5ib290bGluLmNvbS9saW51eC92NS41L3NvdXJjZS9kcml2ZXJzL3hlbi9nbnRk
ZXYuYyNMMzE5DQo+ICAgICA8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZWxp
eGlyLmJvb3RsaW4uY29tL2xpbnV4L3Y1LjUvc291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jKkwz
MTlfXztJdyEhR0ZfMjlkYmNRSVVCUEEhbWhsUUFQU19Penk1N3hhXzBPUjY2cWMxbWpsU0V6N2xq
M01rV0N5RERGOTFCR2E3SjctQk9ZV1ljZGtzcGxvY1p2d2pPZllKeGckPg0KPg0KDQpbMV0gaHR0
cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlzcGxfYmUNCg==


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 06:03:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 06:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQPWQ-0002bd-Ng; Mon, 20 Apr 2020 06:03:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQPWP-0002bY-QT
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 06:03:09 +0000
X-Inumbo-ID: 9b9488e8-82cc-11ea-9032-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9b9488e8-82cc-11ea-9032-12813bfff9fa;
 Mon, 20 Apr 2020 06:03:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0067CAF43;
 Mon, 20 Apr 2020 06:03:06 +0000 (UTC)
Subject: Re: [PATCH 6/6] x86/mem-paging: consistently use gfn_t
To: Julien Grall <julien@xen.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <224337b8-98b4-b0f6-a57a-6f508ffa6838@suse.com>
 <66d56fc4-11a3-6c43-5fbd-ef7039fd06f8@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <cc56ee19-4bec-80f9-e200-39c716122ed8@suse.com>
Date: Mon, 20 Apr 2020 08:03:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <66d56fc4-11a3-6c43-5fbd-ef7039fd06f8@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 18.04.2020 13:14, Julien Grall wrote:
> On 16/04/2020 16:48, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -2151,16 +2151,17 @@ static int mod_l1_entry(l1_pgentry_t *pl
>>                paging_mode_translate(pg_dom) )
>>           {
>>               p2m_type_t p2mt;
>> +            unsigned long gfn = l1e_get_pfn(nl1e);
> 
> How about making gfn a gfn_t directly? This would avoid code churn when...
> 
>>               p2m_query_t q = l1e_get_flags(nl1e) & _PAGE_RW ?
>>                               P2M_ALLOC | P2M_UNSHARE : P2M_ALLOC;
>>   -            page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), &p2mt, q);
>> +            page = get_page_from_gfn(pg_dom, gfn, &p2mt, q);
> 
> ... I am going to convert get_page_from_gfn() to use typesafe gfn. See [1].

Ah, yes, I can certainly do so.

>> @@ -89,16 +88,15 @@ void p2m_mem_paging_drop_page(struct dom
>>    * already sent to the pager. In this case the caller has to try again until the
>>    * gfn is fully paged in again.
>>    */
>> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn_l)
>> +void p2m_mem_paging_populate(struct domain *d, gfn_t gfn)
>>   {
>>       struct vcpu *v = current;
>>       vm_event_request_t req = {
>>           .reason = VM_EVENT_REASON_MEM_PAGING,
>> -        .u.mem_paging.gfn = gfn_l
>> +        .u.mem_paging.gfn = gfn_x(gfn)
>>       };
>>       p2m_type_t p2mt;
>>       p2m_access_t a;
>> -    gfn_t gfn = _gfn(gfn_l);
>>       mfn_t mfn;
>>       struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>       int rc = vm_event_claim_slot(d, d->vm_event_paging);
>> @@ -107,7 +105,7 @@ void p2m_mem_paging_populate(struct doma
>>       if ( rc == -EOPNOTSUPP )
>>       {
>>           gdprintk(XENLOG_ERR, "Dom%d paging gfn %lx yet no ring in place\n",
>> -                 d->domain_id, gfn_l);
>> +                 d->domain_id, gfn_x(gfn));
> 
> Please use PRI_gfn in the format string to match the argument change.

I can do this, but iirc in one of my replies to one of your changes
I've indicated I'm not fully convinced of such changes.

> [1] https://lore.kernel.org/xen-devel/20200322161418.31606-18-julien@xen.org/

Looking over this I notice (only now) that this patch is not
consistent with its dropping of # in PRI_[gm]fn uses: You
don't drop them in e.g. Viridian's enable_hypercall_page(),
but you do in e.g. guest_wrmsr_xen(). Dropping is The Right
Thing To Do (tm), so please do so uniformly.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 07:26:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 07:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQQoq-0000iX-GP; Mon, 20 Apr 2020 07:26:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQQop-0000iS-Dt
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 07:26:15 +0000
X-Inumbo-ID: 34a9cb28-82d8-11ea-9038-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 34a9cb28-82d8-11ea-9038-12813bfff9fa;
 Mon, 20 Apr 2020 07:26:10 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4295FAEF9;
 Mon, 20 Apr 2020 07:26:08 +0000 (UTC)
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
To: Julien Grall <julien@xen.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
 <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
 <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
 <80621ca8-6c08-2868-ada6-bf0ef41fc699@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <802bfbad-a0d7-8d7a-716d-76f0b83c5707@suse.com>
Date: Mon, 20 Apr 2020 09:26:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <80621ca8-6c08-2868-ada6-bf0ef41fc699@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 19:13, Julien Grall wrote:
> On 17/04/2020 10:44, Jan Beulich wrote:
>> On 17.04.2020 10:37, Julien Grall wrote:
>>> On 16/04/2020 16:46, Jan Beulich wrote:
>>>> --- a/xen/arch/x86/mm/p2m.c
>>>> +++ b/xen/arch/x86/mm/p2m.c
>>>> @@ -1779,7 +1779,8 @@ void p2m_mem_paging_populate(struct doma
>>>>     * mfn if populate was called for  gfn which was nominated but not evicted. In
>>>>     * this case only the p2mt needs to be forwarded.
>>>>     */
>>>> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l, uint64_t buffer)
>>>> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l,
>>>> +                        XEN_GUEST_HANDLE_PARAM(const_uint8) buffer)
>>>
>>> Shouldn't this technically be XEN_GUEST_HANDLE_64() to match the field?
>>
>> I think an argument can be made for going either way - as a function
>> parameter it should have the type chosen. Do you see any (possibly
>> just latent) breakage from using _PARAM() rather than _64()?
> I know they are the same on x86, but from an abstract PoV they are fundamentally different.
> 
> XEN_GUEST_HANDLE_PARAM() represents a guest pointer, when pased as an
> hypercall argument.
> 
> XEN_GUEST_HANDLE() represents a guest pointer, when passed as a field
> in a struct in memory.
> 
> In this case, the guest pointer was part of a structure. So I think
> you want to use XEN_GUEST_HANDLE().

Hmm, looks like I was confused about what the two mean. So far I was
under the impression that _PARAM() was to be used for function
parameters in general, not just hypercall ones. While the text near
the macro definitions is quite clear in this regard, I'm afraid
Stefano's original series (first and foremost commit abf06ea91d12's
playing with e.g. handle_iomem_range()) was rather confusing than
helpful - it looks to me as if quite a bit of the "casting" could
actually be dropped (I'll see about doing some cleanup there). Plus
I'm afraid other mixing of plain vs param has been introduced on
x86, at least for dm.c:track_dirty_vram()'s calls to
{hap,shadow}_track_dirty_vram(); this is just the first instance
I've found - there may be more.

> FWIW, the different matters on Arm. Although, it looks like the
> compiler will not warn you if you are using the wrong handler :(.

I find this highly suspicious, but can't check myself until back
in the office - these are distinct compound types after all, so
this shouldn't just be a warning, but an error. Or did you merely
mean there's no warning on x86?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 07:45:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 07:45:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQR7S-0002NH-7J; Mon, 20 Apr 2020 07:45:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2FAk=6E=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jQR7R-0002NB-1c
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 07:45:29 +0000
X-Inumbo-ID: e6aba1c8-82da-11ea-b4f4-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e6aba1c8-82da-11ea-b4f4-bc764e2007e4;
 Mon, 20 Apr 2020 07:45:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587368727;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=BRYZeONaMRXa/u7Cz/2ild+p3hGKgptGPtrN/V9uopo=;
 b=Qc5BVfgzP/Ag+D/lmctevZhPc3meHv08gu8cavpLGT02s18szGAAqG7K
 LU85WiFT7Nwd/YgaSUX6Flqa+Zbo5KZsqX5H/q8Jch9MdGu+TBfNJhMrX
 mks+ktkd0WZkNFnqnNy54ag6jZ7OMbEF4ESm/S/+InkqyzaNQb3XdGaka s=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 0DNPrjBKtvkqMlm6iJXIDkQdq9w2Q1vjnQKl/DaIUzLht6PIrj9xFNBGCwi2lnFdgvFoWiNJaA
 BWf7vSxIAWd3wvJgiLlS2cq5P4wtsBAUVDUFzZQ0G0nGE2Xztvdf+fMvSAlb7NCz81Zxmwd/zo
 9gJUDd2mObvQLJNmmw5h/mPl1Fpw9t6FHL0hpSBc+p/H/hZlLrfAW+4RF6GT8NQGlcwReVbkwR
 YDDqDYjprFG4tfywTq6YB1VWrawHiM2LcZ/Yff9fX1fLNqXCN9Qxkhs8OLPz2orJvyrtAd1c9R
 IRY=
X-SBRS: 2.7
X-MesageID: 16596890
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="16596890"
Date: Mon, 20 Apr 2020 09:45:16 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Subject: Re: [PATCH v15 1/3] mem_sharing: don't reset vCPU info page during
 fork reset
Message-ID: <20200420074516.GQ28601@Air-de-Roger>
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <ef0f91fd4c49c623dda09a1774392d2f2a99ae35.1587142844.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <ef0f91fd4c49c623dda09a1774392d2f2a99ae35.1587142844.git.tamas.lengyel@intel.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
> When a forked VM is being reset while having vm_events active, re-copying the
> vCPU info page can lead to events being lost. This seems to only affect a
> subset of events (interrupts), while not others (cpuid, MTF, EPT) thus it was

I'm slightly lost by the sentence, is the guest or the hypervisor
the one losing events?

Ie: interrupts are events from a guest PoV, but cpuid or EPT is not
something that triggers events that are injected to the guest. I think
the commit message needs clarification.

> not discovered beforehand. Only copying vCPU info page contents during initial
> fork fixes the problem.

Hm, I'm not sure I understand why this is causing issues. When you
reset a fork you should reset the vcpu info page, or else event masks would
be in a wrong state?

> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> ---
>  xen/arch/x86/mm/mem_sharing.c | 50 +++++++++++++++++------------------
>  1 file changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index e572e9e39d..4b31a8b8f6 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1534,28 +1534,6 @@ int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
>                            p2m->default_access, -1);
>  }
>  
> -static int bring_up_vcpus(struct domain *cd, struct domain *d)
> -{
> -    unsigned int i;
> -    int ret = -EINVAL;
> -
> -    if ( d->max_vcpus != cd->max_vcpus ||
> -        (ret = cpupool_move_domain(cd, d->cpupool)) )
> -        return ret;
> -
> -    for ( i = 0; i < cd->max_vcpus; i++ )
> -    {
> -        if ( !d->vcpu[i] || cd->vcpu[i] )
> -            continue;
> -
> -        if ( !vcpu_create(cd, i) )
> -            return -EINVAL;
> -    }
> -
> -    domain_update_node_affinity(cd);
> -    return 0;
> -}
> -
>  static int copy_vcpu_settings(struct domain *cd, const struct domain *d)
>  {
>      unsigned int i;
> @@ -1614,6 +1592,31 @@ static int copy_vcpu_settings(struct domain *cd, const struct domain *d)
>      return 0;
>  }
>  
> +static int bring_up_vcpus(struct domain *cd, struct domain *d)
> +{
> +    unsigned int i;
> +    int ret = -EINVAL;
> +
> +    if ( d->max_vcpus != cd->max_vcpus ||
> +        (ret = cpupool_move_domain(cd, d->cpupool)) )
> +        return ret;
> +
> +    for ( i = 0; i < cd->max_vcpus; i++ )
> +    {
> +        if ( !d->vcpu[i] || cd->vcpu[i] )
> +            continue;
> +
> +        if ( !vcpu_create(cd, i) )
> +            return -EINVAL;
> +    }
> +
> +    if ( (ret = copy_vcpu_settings(cd, d)) )
> +        return ret;
> +
> +    domain_update_node_affinity(cd);
> +    return 0;
> +}

I would prefer the code movement to be in a different patch: it makes
it more difficult to spot non-functional changes being made while
moving the function around.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 07:57:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 07:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQRIg-0003Gn-CG; Mon, 20 Apr 2020 07:57:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2FAk=6E=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jQRIe-0003Gi-Lk
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 07:57:04 +0000
X-Inumbo-ID: 853aadc4-82dc-11ea-83d8-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 853aadc4-82dc-11ea-83d8-bc764e2007e4;
 Mon, 20 Apr 2020 07:57:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587369423;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=Z4oFYSLmLzGpfaUyWAYlBZkAsjCQNOvHHSOxWRX6LIc=;
 b=VfGb6S8rMTRyMqhGnmqFFI1P7drrzLGoNy+rByqZke70lRHFRHSNM2GY
 nvojSjXpqsGYBcrgkd7h/tf8t3aRox57LLxn+4W9XpAHmhFeIWuA4shVv
 LTcxkyXKxeiYO/tHhMg3KNk17PgduuBFNvNz+Ua6vRJLjukcqw0KGfl+Y w=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: OR08X66S/ezZrfrZorqmcTtz63ZcB2fnG+hMugYldHT+ANeyYyVNjEU+IqEY9Dok+4jZC0A8gu
 nfzpGiznroV/B/z117MWjTy07bdusUgOX/qht4JcGe0wJvo1frbHCanQXHeRkLcZrHzAfUdpGd
 lvpaQ9cJqedOXwwl3jCYrL3kYAkulu8c1vmYOeQm5DxUOQ/CsdUSGuQKanXZ3pYthvSNsU6ItO
 yt+0UihufUhVWuF6IYAbWRvTz1Pi+eA4OeAOZfWr48GNOe4mZ+FitD4PEQZvA4KJH+1SOu+jqX
 9lQ=
X-SBRS: 2.7
X-MesageID: 16166357
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="16166357"
Date: Mon, 20 Apr 2020 09:56:55 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Subject: Re: [PATCH v15 2/3] mem_sharing: allow forking domain with IOMMU
 enabled
Message-ID: <20200420075655.GR28601@Air-de-Roger>
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <0be7501ace42d856b344828755ece18659dabd33.1587142844.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <0be7501ace42d856b344828755ece18659dabd33.1587142844.git.tamas.lengyel@intel.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Stefano
 Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 10:06:32AM -0700, Tamas K Lengyel wrote:
> The memory sharing subsystem by default doesn't allow a domain to share memory
> if it has an IOMMU active for obvious security reasons. However, when fuzzing a
> VM fork, the same security restrictions don't necessarily apply. While it makes
> no sense to try to create a full fork of a VM that has an IOMMU attached as only
> one domain can own the pass-through device at a time, creating a shallow fork
> without a device model is still very useful for fuzzing kernel-mode drivers.
> 
> By allowing the parent VM to initialize the kernel-mode driver with a real
> device that's pass-through, the driver can enter into a state more suitable for
                ^ passed
> fuzzing. Some of these initialization steps are quite complex and are easier to
> perform when a real device is present. After the initialization, shallow forks
> can be utilized for fuzzing code-segments in the device driver that don't
> directly interact with the device.

If I understand this correctly, the forked VM won't have an IOMMU
setup, and the only domain allowed to interact with the device would
be the parent?

> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> ---
>  xen/arch/x86/mm/mem_sharing.c | 18 ++++++++++++------
>  xen/include/public/memory.h   |  4 +++-
>  2 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 4b31a8b8f6..a5063d5992 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1430,7 +1430,8 @@ static int range_share(struct domain *d, struct domain *cd,
>      return rc;
>  }
>  
> -static inline int mem_sharing_control(struct domain *d, bool enable)
> +static inline int mem_sharing_control(struct domain *d, bool enable,
> +                                      bool allow_iommu)
>  {
>      if ( enable )
>      {
> @@ -1440,7 +1441,7 @@ static inline int mem_sharing_control(struct domain *d, bool enable)
>          if ( unlikely(!hap_enabled(d)) )
>              return -ENODEV;
>  
> -        if ( unlikely(is_iommu_enabled(d)) )
> +        if (unlikely(!allow_iommu && is_iommu_enabled(d)) )

Coding style (missing space)

>              return -EXDEV;
>      }
>  
> @@ -1827,7 +1828,8 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>      if ( rc )
>          goto out;
>  
> -    if ( !mem_sharing_enabled(d) && (rc = mem_sharing_control(d, true)) )
> +    if ( !mem_sharing_enabled(d) &&
> +         (rc = mem_sharing_control(d, true, false)) )
>          return rc;
>  
>      switch ( mso.op )
> @@ -2063,9 +2065,10 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>      case XENMEM_sharing_op_fork:
>      {
>          struct domain *pd;
> +        bool allow_iommu;
>  
>          rc = -EINVAL;
> -        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[2] )
> +        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] )
>              goto out;
>  
>          rc = rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_domain,
> @@ -2080,7 +2083,10 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>              goto out;
>          }
>  
> -        if ( !mem_sharing_enabled(pd) && (rc = mem_sharing_control(pd, true)) )
> +        allow_iommu = mso.u.fork.flags & XENMEM_FORK_WITH_IOMMU_ALLOWED;

I'm not sure whether it is worth to extract the flags into booleans at
this level. As you add more flags it might make sense to just pass the
whole flags field to mem_sharing_control?

mem_sharing_memop itself doesn't need to know which flags are
specified.

> +
> +        if ( !mem_sharing_enabled(pd) &&
> +             (rc = mem_sharing_control(pd, true, allow_iommu)) )
>          {
>              rcu_unlock_domain(pd);
>              goto out;
> @@ -2138,7 +2144,7 @@ int mem_sharing_domctl(struct domain *d, struct xen_domctl_mem_sharing_op *mec)
>      switch ( mec->op )
>      {
>      case XEN_DOMCTL_MEM_SHARING_CONTROL:
> -        rc = mem_sharing_control(d, mec->u.enable);
> +        rc = mem_sharing_control(d, mec->u.enable, false);
>          break;
>  
>      default:
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index d36d64b8dc..1d2149def3 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -536,7 +536,9 @@ struct xen_mem_sharing_op {
>          } debug;
>          struct mem_sharing_op_fork {      /* OP_FORK */
>              domid_t parent_domain;        /* IN: parent's domain id */
> -            uint16_t pad[3];              /* Must be set to 0 */
> +#define XENMEM_FORK_WITH_IOMMU_ALLOWED 1  /* Allow forking domain with IOMMU */

Since this is a flags field, can you express this is as: (1u << 0).

> +            uint16_t flags;               /* IN: optional settings */
> +            uint16_t pad[2];              /* Must be set to 0 */

Nit: padding can be made a uint32_t now instead of an array of two
uint16_t.

Or add an uint16_t between parent_domain and flags and make flags an
uint32_t.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 08:04:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 08:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQRQ4-0004fP-QR; Mon, 20 Apr 2020 08:04:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQRQ3-0004fG-Dh
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 08:04:43 +0000
X-Inumbo-ID: 96e65fcc-82dd-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 96e65fcc-82dd-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 08:04:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 82B1AAFB4;
 Mon, 20 Apr 2020 08:04:40 +0000 (UTC)
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Julien Grall <julien@xen.org>
References: <20200419104948.31200-1-julien@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
Date: Mon, 20 Apr 2020 10:04:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200419104948.31200-1-julien@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 19.04.2020 12:49, Julien Grall wrote:
> --- a/docs/misc/pvcalls.pandoc
> +++ b/docs/misc/pvcalls.pandoc
> @@ -246,9 +246,7 @@ The format is defined as follows:
>      			uint32_t domain;
>      			uint32_t type;
>      			uint32_t protocol;
> -    			#ifdef CONFIG_X86_32
>      			uint8_t pad[4];
> -    			#endif
>      		} socket;
>      		struct xen_pvcalls_connect {
>      			uint64_t id;
> @@ -257,16 +255,12 @@ The format is defined as follows:
>      			uint32_t flags;
>      			grant_ref_t ref;
>      			uint32_t evtchn;
> -    			#ifdef CONFIG_X86_32
>      			uint8_t pad[4];
> -    			#endif
>      		} connect;
>      		struct xen_pvcalls_release {
>      			uint64_t id;
>      			uint8_t reuse;
> -    			#ifdef CONFIG_X86_32
>      			uint8_t pad[7];
> -    			#endif
>      		} release;
>      		struct xen_pvcalls_bind {
>      			uint64_t id;
> @@ -276,9 +270,7 @@ The format is defined as follows:
>      		struct xen_pvcalls_listen {
>      			uint64_t id;
>      			uint32_t backlog;
> -    			#ifdef CONFIG_X86_32
>      			uint8_t pad[4];
> -    			#endif
>      		} listen;
>      		struct xen_pvcalls_accept {
>      			uint64_t id;

I wonder on what grounds these #ifdef-s had been there - they're
plain wrong with the types used in the public header.

> --- a/xen/include/public/io/pvcalls.h
> +++ b/xen/include/public/io/pvcalls.h
> @@ -65,6 +65,7 @@ struct xen_pvcalls_request {
>              uint32_t domain;
>              uint32_t type;
>              uint32_t protocol;
> +            uint8_t pad[4];
>          } socket;
>          struct xen_pvcalls_connect {
>              uint64_t id;
> @@ -73,10 +74,12 @@ struct xen_pvcalls_request {
>              uint32_t flags;
>              grant_ref_t ref;
>              uint32_t evtchn;
> +            uint8_t pad[4];
>          } connect;
>          struct xen_pvcalls_release {
>              uint64_t id;
>              uint8_t reuse;
> +            uint8_t pad[7];
>          } release;
>          struct xen_pvcalls_bind {
>              uint64_t id;
> @@ -86,6 +89,7 @@ struct xen_pvcalls_request {
>          struct xen_pvcalls_listen {
>              uint64_t id;
>              uint32_t backlog;
> +            uint8_t pad[4];
>          } listen;

I'm afraid we can't change these in such a way - your additions
change sizeof() for the respective sub-structures on 32-bit x86,
and hence this is not a backwards compatible adjustment. The
best I can think of right now that we could do is make the
difference explicit, by putting the padding fields inside
#ifndef __i386__. But of course this is awkward at least when
thinking about a 32-bit / 64-bit pair of communication ends on
an x86-64 host.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 08:33:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 08:33:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQRrG-00076P-Ak; Mon, 20 Apr 2020 08:32:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=7yY/=6E=redhat.com=armbru@srs-us1.protection.inumbo.net>)
 id 1jQRrE-00076K-UC
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 08:32:48 +0000
X-Inumbo-ID: 82c47a3f-82e1-11ea-903c-12813bfff9fa
Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id 82c47a3f-82e1-11ea-903c-12813bfff9fa;
 Mon, 20 Apr 2020 08:32:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1587371566;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=H67yUlCy/y0Sl74oiSkcXseZ2y18ZG7uO1JqanC1+vk=;
 b=G6b2u27ztP2MUdqPaTkLbc5pVKOU/Equ0z3FyA2U6ttGnvFfOZ1KxLD45AykMlhJVzLNnl
 Q+rJSf7kmmM0RLj8oBDpniFzWfS8pE5lSzut7fNCeoZvQP2aEc/Wit40vUIsEOHNZdacRm
 zVBzmV2Fl4i4iyPQKS0anFSKUCO8WHU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-65-KlhUBDb3NCekAEnO42wDZw-1; Mon, 20 Apr 2020 04:32:41 -0400
X-MC-Unique: KlhUBDb3NCekAEnO42wDZw-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 26D918017F3;
 Mon, 20 Apr 2020 08:32:40 +0000 (UTC)
Received: from blackfin.pond.sub.org (ovpn-113-6.ams2.redhat.com [10.36.113.6])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id C89412B479;
 Mon, 20 Apr 2020 08:32:39 +0000 (UTC)
Received: by blackfin.pond.sub.org (Postfix, from userid 1000)
 id BB20811358C5; Mon, 20 Apr 2020 10:32:36 +0200 (CEST)
From: Markus Armbruster <armbru@redhat.com>
To: qemu-devel@nongnu.org
Subject: [PATCH 09/11] xen/pt: Fix flawed conversion to realize()
Date: Mon, 20 Apr 2020 10:32:34 +0200
Message-Id: <20200420083236.19309-10-armbru@redhat.com>
In-Reply-To: <20200420083236.19309-1-armbru@redhat.com>
References: <20200420083236.19309-1-armbru@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <sstabellini@kernel.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The conversion of xen_pt_initfn() to xen_pt_realize() blindly replaced
XEN_PT_ERR() by error_setg().  Several error conditions that did not
fail xen_pt_initfn() now fail xen_pt_realize().  Unsurprisingly, the
cleanup on these errors looks highly suspicious.

Revert the inappropriate replacements.

Fixes: 5a11d0f7549e24a10e178a9dc8ff5e698031d9a6
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Paul Durrant <paul@xen.org>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 hw/xen/xen_pt.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index b91082cb8b..81d5ad8da7 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -858,8 +858,8 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
=20
     rc =3D xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
     if (rc < 0) {
-        error_setg_errno(errp, errno, "Mapping machine irq %u to"
-                         " pirq %i failed", machine_irq, pirq);
+        XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (err: %d)=
\n",
+                   machine_irq, pirq, errno);
=20
         /* Disable PCI intx assertion (turn on bit10 of devctl) */
         cmd |=3D PCI_COMMAND_INTX_DISABLE;
@@ -880,8 +880,8 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
                                        PCI_SLOT(d->devfn),
                                        e_intx);
         if (rc < 0) {
-            error_setg_errno(errp, errno, "Binding of interrupt %u failed"=
,
-                             e_intx);
+            XEN_PT_ERR(d, "Binding of interrupt %i failed! (err: %d)\n",
+                       e_intx, errno);
=20
             /* Disable PCI intx assertion (turn on bit10 of devctl) */
             cmd |=3D PCI_COMMAND_INTX_DISABLE;
@@ -889,8 +889,8 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
=20
             if (xen_pt_mapped_machine_irq[machine_irq] =3D=3D 0) {
                 if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq))=
 {
-                    error_setg_errno(errp, errno, "Unmapping of machine"
-                            " interrupt %u failed", machine_irq);
+                    XEN_PT_ERR(d, "Unmapping of machine interrupt %i faile=
d!"
+                               " (err: %d)\n", machine_irq, errno);
                 }
             }
             s->machine_irq =3D 0;
--=20
2.21.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 08:58:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 08:58:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQSGG-0000SI-IO; Mon, 20 Apr 2020 08:58:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=UDoD=6E=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jQSGF-0000SD-EK
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 08:58:39 +0000
X-Inumbo-ID: 1fc90c5c-82e5-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x533.google.com (unknown [2a00:1450:4864:20::533])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1fc90c5c-82e5-11ea-b4f4-bc764e2007e4;
 Mon, 20 Apr 2020 08:58:38 +0000 (UTC)
Received: by mail-ed1-x533.google.com with SMTP id w2so6739798edx.4
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 01:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=l12LqyTH4YgL3udx+mMMxH3mer6k55ySqu3cyDYdhec=;
 b=Qjx8Z0Ed/kKdXep5rDdvFhr5KVGQog4BiWtrplRP6hSSskyzCXPWh0sTr+5Pl3MOKW
 ot1j5t9vUjdC0xTr8FtSt3a6gMHp2ZK/lgqqQrWc3Tl8GaQ5jnu4b2zKzyGNLQ+zo+Si
 gELZtGQTjhMNVtGgM8fHjEtyd2YvM7QfwVBVm9JFk4aenWBS5GwmmoSHSAzXnGwnYk9V
 e+7sWwg19gPqG43omTfeUJG0GSTPj1tkb/ATOvzk3I40JxqseDUZ8F8I5WZpP07IYKAw
 8ujUjxBCyM9jH1e08GsCk6PBoTzW/YI9MNngOH7sOudKp5IhcLccjUg3RvQAu/dj0jLf
 mYKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=l12LqyTH4YgL3udx+mMMxH3mer6k55ySqu3cyDYdhec=;
 b=XeZvYIbe3gE6E5YpUwTJUILEaqu1An/uOR3z4FInJmFSl0ad7stfrAmHMudc1PALD5
 aJCEo0Otkle6EG2lB/ISr7lWy4F7aTW8eesOvNcHJIen/bgTqwrI2SMrZjc1F9QvrQNM
 ntvC6hS7sGoi5Val9Dv2OKchXiNOdepCPxRTmp6cef+ORengWHHRZI7Set/di1gfxTeZ
 nEaJT0/fJLfD0MZ9RdG++RgnWGWmbhsR52AXm/K+iJK4nLWSf0FlWRYjm+dbk4c9XoSl
 bYvAWlw+XPLB9JM9PhfpiY8jjXqn5RuFQRe6jr25j5VFi2NE/Bf/obGMNTUzLIkwbtft
 Un2A==
X-Gm-Message-State: AGi0PubFpsVHi680wGUUCVHzUQ2G3hdPAL9LzbYmKGpx2SgQ1zKFSfMV
 WplED/jq0smf6U4BFEr9p44=
X-Google-Smtp-Source: APiQypIKPCo2plSHpjjzSAMNGT9aA4e3L7shMprjSVglVHH/8jSrvmcyN8rO+29d1JFDuoXpyr19cQ==
X-Received: by 2002:a05:6402:310b:: with SMTP id
 dc11mr12798473edb.143.1587373117743; 
 Mon, 20 Apr 2020 01:58:37 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id dm15sm21184edb.84.2020.04.20.01.58.36
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 20 Apr 2020 01:58:37 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Markus Armbruster'" <armbru@redhat.com>,
	<qemu-devel@nongnu.org>
References: <20200420083236.19309-1-armbru@redhat.com>
 <20200420083236.19309-10-armbru@redhat.com>
In-Reply-To: <20200420083236.19309-10-armbru@redhat.com>
Subject: RE: [PATCH 09/11] xen/pt: Fix flawed conversion to realize()
Date: Mon, 20 Apr 2020 09:58:35 +0100
Message-ID: <002201d616f1$e1057910$a3106b30$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQIW6PbL/TFzdKd45gQwHtYhr73cEQJR6tGlp+2CVEA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Anthony Perard' <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, 'Stefano Stabellini' <sstabellini@kernel.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Markus Armbruster <armbru@redhat.com>
> Sent: 20 April 2020 09:33
> To: qemu-devel@nongnu.org
> Cc: Stefano Stabellini <sstabellini@kernel.org>; Anthony Perard <anthony.perard@citrix.com>; Paul
> Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Subject: [PATCH 09/11] xen/pt: Fix flawed conversion to realize()
> 
> The conversion of xen_pt_initfn() to xen_pt_realize() blindly replaced
> XEN_PT_ERR() by error_setg().  Several error conditions that did not
> fail xen_pt_initfn() now fail xen_pt_realize().  Unsurprisingly, the
> cleanup on these errors looks highly suspicious.
> 
> Revert the inappropriate replacements.
> 
> Fixes: 5a11d0f7549e24a10e178a9dc8ff5e698031d9a6
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Paul Durrant <paul@xen.org>
> Cc: xen-devel@lists.xenproject.org
> Signed-off-by: Markus Armbruster <armbru@redhat.com>

Reviewed-by: Paul Durrant <paul@xen.org>



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 09:17:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 09:17:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQSXs-00028x-AZ; Mon, 20 Apr 2020 09:16:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQSXq-00028s-Ok
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 09:16:50 +0000
X-Inumbo-ID: a992cc3c-82e7-11ea-903e-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a992cc3c-82e7-11ea-903e-12813bfff9fa;
 Mon, 20 Apr 2020 09:16:48 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C449EAD2A;
 Mon, 20 Apr 2020 09:16:46 +0000 (UTC)
Subject: Re: [PATCH 05/17] xen/x86: Remove the non-typesafe version of
 pagetable_* helpers
To: Julien Grall <julien@xen.org>
References: <20200322161418.31606-1-julien@xen.org>
 <20200322161418.31606-6-julien@xen.org>
 <b0d29ded-f0e8-013b-de43-22788cd8f599@suse.com>
 <2be87441-05a6-6b58-23e3-da467230ffe7@xen.org>
 <cf983d3e-125a-621a-f81d-2f9955ec86eb@suse.com>
 <f72f5c31-c437-549a-9d8b-8b836caf699b@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6af445d8-636f-a19e-ac53-9c66ae9f61c5@suse.com>
Date: Mon, 20 Apr 2020 11:16:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <f72f5c31-c437-549a-9d8b-8b836caf699b@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 18.04.2020 12:23, Julien Grall wrote:
> On 30/03/2020 08:52, Jan Beulich wrote:
>> On 28.03.2020 11:52, Julien Grall wrote:
>>> On 26/03/2020 15:39, Jan Beulich wrote:
>>>> On 22.03.2020 17:14, julien@xen.org wrote:
>>>>> @@ -3116,24 +3116,24 @@ int vcpu_destroy_pagetables(struct vcpu *v)
>>>>>          /* Free that page if non-zero */
>>>>>        do {
>>>>> -        if ( mfn )
>>>>> +        if ( !mfn_eq(mfn, _mfn(0)) )
>>>>
>>>> I admit I'm not fully certain either, but at the first glance
>>>>
>>>>           if ( mfn_x(mfn) )
>>>>
>>>> would seem more in line with the original code to me (and then
>>>> also elsewhere).
>>>
>>> It is doing *exactly* the same things. The whole point of typesafe
>>> is to use typesafe helper not open-coding test everywhere.
>>>
>>> It is also easier to spot any use of MFN 0 within the code as you
>>> know could grep "_mfn(0)".
>>>
>>> Therefore I will insist to the code as-is.
>>
>> What I insit on is that readability of the result of such changes be
>> also kept in mind. The mfn_eq() construct is (I think) clearly less
>> easy to read and recognize than the simpler alternative suggested.
> 
> If mfn_eq() is less clear, then where do you draw the line when the
> macro should or not be used?

I'm afraid there may not be a clear line to draw until everything
got converted. I do seem to recall though that, perhaps in a
different context, Andrew recently agreed with my view here (Andrew,
please correct me if I'm wrong). It being a fuzzy thing, I guess
maintainers get to judge ...

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 09:20:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 09:20:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQSax-0002UI-RF; Mon, 20 Apr 2020 09:20:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQSaw-0002Li-8F
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 09:20:02 +0000
X-Inumbo-ID: 1c7c2b08-82e8-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1c7c2b08-82e8-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 09:20:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B01F5B1CD;
 Mon, 20 Apr 2020 09:19:59 +0000 (UTC)
Subject: Re: [PATCH 07/17] xen/x86: traps: Convert __page_fault_type() to use
 typesafe MFN
To: Julien Grall <julien@xen.org>
References: <20200322161418.31606-1-julien@xen.org>
 <20200322161418.31606-8-julien@xen.org>
 <12a955a3-d326-f5f9-f20b-69f3dafac238@suse.com>
 <527ec42b-1fcf-7e35-0ed7-b9da91a8c583@xen.org>
 <cb09a267-32b6-9ea3-1289-a1e20ec99746@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <97d8cf44-678b-29ed-995e-e0737f83566f@suse.com>
Date: Mon, 20 Apr 2020 11:19:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <cb09a267-32b6-9ea3-1289-a1e20ec99746@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 18.04.2020 13:43, Julien Grall wrote:
> On 18/04/2020 12:01, Julien Grall wrote:
>> On 26/03/2020 15:54, Jan Beulich wrote:
>>> On 22.03.2020 17:14, julien@xen.org wrote:
>>>> From: Julien Grall <jgrall@amazon.com>
>>>>
>>>> Note that the code is now using cr3_to_mfn() to get the MFN. This is
>>>> slightly different as the top 12-bits will now be masked.
>>>
>>> And here I agree with the change. Hence it is even more so important
>>> that the patch introducing the new helper(s) first gets sorted.
>>> Should there be further patches in this series with this same
>>> interaction issue, I won't point it out again and may not respond at
>>> all if I see no other issues.
>>
>> I will update the commit message explaining the reason of using cr3_to_mfn() and look at the other user.
> 
> Looking at the code again, there are a few users that don't mask the top 12-bits. I am trying to understand why this has never been an issue so far.
> 
> Wouldn't it break when bit 63 (no flush) is set?

Yes; I guess those uses are case where bit 63 can't / won't be set.
Just like the register, which doesn't store the bit, I think we
avoid storing the bit set as well. But correctness of the non-
masking variants can only be established by looking at every
individual site.

> If so, maybe I should split the work from typesafe.

Maybe better indeed.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 09:31:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 09:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQSmA-0003pf-SD; Mon, 20 Apr 2020 09:31:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQSm9-0003p8-71
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 09:31:37 +0000
X-Inumbo-ID: ba8857ee-82e9-11ea-903e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ba8857ee-82e9-11ea-903e-12813bfff9fa;
 Mon, 20 Apr 2020 09:31:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=NYUQwQcNaVU7FSpt2cneenw126eCi3OdfcC0R9kcoTk=; b=61h/SUFosgBa8fVSFD+stmSnWX
 AAHzyM/4Vy+RxoUHNb6Hzv41zuA6MkaNMlghEdWulK8mMtmW7tmI8pkwl2C+e1fuwO64BF+gMOC4d
 xRz0a2EExhEx4kUeR4w7zcHz01VOyucjCotX6wDlrQMxg0yq94RHfCN8xBLmNmxvlOSE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQSm3-0000N8-KW; Mon, 20 Apr 2020 09:31:31 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQSm3-00088B-CN; Mon, 20 Apr 2020 09:31:31 +0000
Subject: Re: [PATCH v3] Introduce a description of the Backport and Fixes tags
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20200417222430.20480-1-sstabellini@kernel.org>
From: Julien Grall <julien@xen.org>
Message-ID: <35b34e2f-e6cd-6afc-19fd-c7880ec0eace@xen.org>
Date: Mon, 20 Apr 2020 10:31:28 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417222430.20480-1-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, Wei Liu <wl@xen.org>, konrad.wilk@oracle.com,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 george.dunlap@citrix.com, jbeulich@suse.com,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Stefano,

On 17/04/2020 23:24, Stefano Stabellini wrote:
> Create a new document under docs/process to describe our special tags.
> Add a description of the Fixes tag and the new Backport tag. Also
> clarify that lines with tags should not be split.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> CC: Ian Jackson <ian.jackson@eu.citrix.com>
> CC: Wei Liu <wl@xen.org>
> CC: jbeulich@suse.com
> CC: george.dunlap@citrix.com
> CC: julien@xen.org
> CC: lars.kurth@citrix.com
> CC: andrew.cooper3@citrix.com
> CC: konrad.wilk@oracle.com
> ---
> Removing Acks as I added the description of "Fixes"
> ---
>   docs/process/tags.pandoc | 55 ++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 55 insertions(+)
>   create mode 100644 docs/process/tags.pandoc
> 
> diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
> new file mode 100644
> index 0000000000..06b06dda01
> --- /dev/null
> +++ b/docs/process/tags.pandoc
> @@ -0,0 +1,55 @@
> +Tags: No line splitting
> +-----------------------
> +Do not split a tag across multiple lines, tags are exempt from the
> +"wrap at 75 columns" rule in order to simplify parsing scripts.  For
> +example:
> +
> +        Fixes: 67d01cdb5 ("x86: infrastructure to allow converting certain indirect calls to direct ones")

The SHA-1 ID is 9 characters but...

> +
> +
> +Fixes Tag
> +---------
> +
> +If your patch fixes a bug in a specific commit, e.g. you found an issue using
> +``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
> +the SHA-1 ID, and the one line summary.

... you request 12 characters here. Can you make sure the two match please?

However, I am not entirely sure why we should mandate 12 characters. 
With the title, you should always be able to find back the commit if 
there is a clash.

> +
> +The following ``git config`` settings can be used to add a pretty format for
> +outputting the above style in the ``git log`` or ``git show`` commands:
> +
> +        [core]
> +                abbrev = 12
> +        [pretty]
> +                fixes = Fixes: %h (\"%s\")
> +
> +
> +Backport Tag
> +------------
> +
> +A backport tag is an optional tag in the commit message to request a
> +given commit to be backported to the stable trees:
> +
> +    Backport: 4.9+
> +
> +It marks a commit for being a candidate for backports to all stable
> +trees from 4.9 onward.
> +
> +The backport requester is expected to specify which currently supported
> +releases need the backport; but encouraged to specify a release as far
> +back as possible which applies. If the requester doesn't know the oldest
> +affected tree, they are encouraged to append a comment like the
> +following:
> +
> +    Backport: 4.9+ # maybe older
> +
> +Maintainers request the Backport tag to be added on commit. Contributors
> +are welcome to mark their patches with the Backport tag when they deem
> +appropriate. Maintainers will request for it to be removed when that is
> +not the case.
> +
> +Please note that the Backport tag is a **request** for backport, which
> +will still need to be evaluated by the stable tree maintainers.
> +Maintainers might ask the requester to help with the backporting work if
> +it is not trivial.
> +
> +When possible, please use the Fixes tag instead.
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 09:57:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 09:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQTAr-0005iw-J5; Mon, 20 Apr 2020 09:57:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQTAp-0005ip-Qo
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 09:57:07 +0000
X-Inumbo-ID: 4b5e4294-82ed-11ea-9042-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4b5e4294-82ed-11ea-9042-12813bfff9fa;
 Mon, 20 Apr 2020 09:57:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=nObpbmf80etLb5MlD1R+jvWn83wNDWDnU20N1scz+Yk=; b=TUTgAfpBdEzA+qDSIux6qTjYhX
 ehtHRvJeygTWUNhnOIov7amNYfW5pcL57q5B3TEC/E3cD7Tr9xlC68FnaKMWYhnoYryu+Gr5jUaQx
 ijv+ct908IzQF7SDsGmHuvQ+P5OWDd1RlA3cg9jmwGzWUHFBvAQ4y+nOBXpL+iQ0UG/Q=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQTAn-0000tX-Tq; Mon, 20 Apr 2020 09:57:05 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQTAn-0001IL-LV; Mon, 20 Apr 2020 09:57:05 +0000
Subject: Re: [PATCH 6/6] x86/mem-paging: consistently use gfn_t
To: Jan Beulich <jbeulich@suse.com>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <224337b8-98b4-b0f6-a57a-6f508ffa6838@suse.com>
 <66d56fc4-11a3-6c43-5fbd-ef7039fd06f8@xen.org>
 <cc56ee19-4bec-80f9-e200-39c716122ed8@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <8a58a2d1-e72b-1f88-e5a5-cf168f42c783@xen.org>
Date: Mon, 20 Apr 2020 10:57:03 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <cc56ee19-4bec-80f9-e200-39c716122ed8@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 20/04/2020 07:03, Jan Beulich wrote:
> On 18.04.2020 13:14, Julien Grall wrote:
>> On 16/04/2020 16:48, Jan Beulich wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -2151,16 +2151,17 @@ static int mod_l1_entry(l1_pgentry_t *pl
>>>                 paging_mode_translate(pg_dom) )
>>>            {
>>>                p2m_type_t p2mt;
>>> +            unsigned long gfn = l1e_get_pfn(nl1e);
>>
>> How about making gfn a gfn_t directly? This would avoid code churn when...
>>
>>>                p2m_query_t q = l1e_get_flags(nl1e) & _PAGE_RW ?
>>>                                P2M_ALLOC | P2M_UNSHARE : P2M_ALLOC;
>>>    -            page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), &p2mt, q);
>>> +            page = get_page_from_gfn(pg_dom, gfn, &p2mt, q);
>>
>> ... I am going to convert get_page_from_gfn() to use typesafe gfn. See [1].
> 
> Ah, yes, I can certainly do so.
> 
>>> @@ -89,16 +88,15 @@ void p2m_mem_paging_drop_page(struct dom
>>>     * already sent to the pager. In this case the caller has to try again until the
>>>     * gfn is fully paged in again.
>>>     */
>>> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn_l)
>>> +void p2m_mem_paging_populate(struct domain *d, gfn_t gfn)
>>>    {
>>>        struct vcpu *v = current;
>>>        vm_event_request_t req = {
>>>            .reason = VM_EVENT_REASON_MEM_PAGING,
>>> -        .u.mem_paging.gfn = gfn_l
>>> +        .u.mem_paging.gfn = gfn_x(gfn)
>>>        };
>>>        p2m_type_t p2mt;
>>>        p2m_access_t a;
>>> -    gfn_t gfn = _gfn(gfn_l);
>>>        mfn_t mfn;
>>>        struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>>        int rc = vm_event_claim_slot(d, d->vm_event_paging);
>>> @@ -107,7 +105,7 @@ void p2m_mem_paging_populate(struct doma
>>>        if ( rc == -EOPNOTSUPP )
>>>        {
>>>            gdprintk(XENLOG_ERR, "Dom%d paging gfn %lx yet no ring in place\n",
>>> -                 d->domain_id, gfn_l);
>>> +                 d->domain_id, gfn_x(gfn));
>>
>> Please use PRI_gfn in the format string to match the argument change.
> 
> I can do this, but iirc in one of my replies to one of your changes
> I've indicated I'm not fully convinced of such changes.

I guess you are referring to [2]. The discussion was quite different, we 
were arguing whether PRI_mfn could be used for other value than 
mfn_x(mfn). But then you said you were happy with PRI_xen_pfn.

Aside the return type of gfn_x(gfn) argument, if we use %PRI_gfn then we 
can finally have a consistent way to print a GFN and easily change it.

> 
>> [1] https://lore.kernel.org/xen-devel/20200322161418.31606-18-julien@xen.org/
> 
> Looking over this I notice (only now) that this patch is not
> consistent with its dropping of # in PRI_[gm]fn uses: You
> don't drop them in e.g. Viridian's enable_hypercall_page(),
> but you do in e.g. guest_wrmsr_xen(). Dropping is The Right
> Thing To Do (tm), so please do so uniformly.

Ok.

Cheers,

[2] <2be87441-05a6-6b58-23e3-da467230ffe7@xen.org>

> 
> Jan
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 10:11:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 10:11:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQTON-0007b3-CD; Mon, 20 Apr 2020 10:11:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQTOM-0007ay-Ja
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 10:11:06 +0000
X-Inumbo-ID: 3f4c28c0-82ef-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3f4c28c0-82ef-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 10:11:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tLF5TzU2ciFZupaKQnhPRe4udKvUSPWMek1boWueADw=; b=INM2Rfjbc0vRULDE4JeARd3YBv
 5mcBN/MN43X6I7BtYaE0dvOAg9SYpHWyIgueHxnfH/A0kIM5DqEn9bi1yUxSbELCPmNUf4q6otntx
 Cv/ywDDkWMRDnzR6zV0gS3leAvOkFFh1KyYHlfu7qzcmywm2Mq+QE3T0s4fcR/gQ1sFI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQTOA-0001EO-ED; Mon, 20 Apr 2020 10:10:54 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQTOA-0002Ja-6N; Mon, 20 Apr 2020 10:10:54 +0000
Subject: Re: [PATCH 05/17] xen/x86: Remove the non-typesafe version of
 pagetable_* helpers
To: Jan Beulich <jbeulich@suse.com>
References: <20200322161418.31606-1-julien@xen.org>
 <20200322161418.31606-6-julien@xen.org>
 <b0d29ded-f0e8-013b-de43-22788cd8f599@suse.com>
 <2be87441-05a6-6b58-23e3-da467230ffe7@xen.org>
 <cf983d3e-125a-621a-f81d-2f9955ec86eb@suse.com>
 <f72f5c31-c437-549a-9d8b-8b836caf699b@xen.org>
 <6af445d8-636f-a19e-ac53-9c66ae9f61c5@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <0bb49716-6b1c-0beb-01c5-4c0d220ca011@xen.org>
Date: Mon, 20 Apr 2020 11:10:51 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <6af445d8-636f-a19e-ac53-9c66ae9f61c5@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 20/04/2020 10:16, Jan Beulich wrote:
> On 18.04.2020 12:23, Julien Grall wrote:
>> On 30/03/2020 08:52, Jan Beulich wrote:
>>> On 28.03.2020 11:52, Julien Grall wrote:
>>>> On 26/03/2020 15:39, Jan Beulich wrote:
>>>>> On 22.03.2020 17:14, julien@xen.org wrote:
>>>>>> @@ -3116,24 +3116,24 @@ int vcpu_destroy_pagetables(struct vcpu *v)
>>>>>>           /* Free that page if non-zero */
>>>>>>         do {
>>>>>> -        if ( mfn )
>>>>>> +        if ( !mfn_eq(mfn, _mfn(0)) )
>>>>>
>>>>> I admit I'm not fully certain either, but at the first glance
>>>>>
>>>>>            if ( mfn_x(mfn) )
>>>>>
>>>>> would seem more in line with the original code to me (and then
>>>>> also elsewhere).
>>>>
>>>> It is doing *exactly* the same things. The whole point of typesafe
>>>> is to use typesafe helper not open-coding test everywhere.
>>>>
>>>> It is also easier to spot any use of MFN 0 within the code as you
>>>> know could grep "_mfn(0)".
>>>>
>>>> Therefore I will insist to the code as-is.
>>>
>>> What I insit on is that readability of the result of such changes be
>>> also kept in mind. The mfn_eq() construct is (I think) clearly less
>>> easy to read and recognize than the simpler alternative suggested.
>>
>> If mfn_eq() is less clear, then where do you draw the line when the
>> macro should or not be used?
> 
> I'm afraid there may not be a clear line to draw until everything
> got converted.

I am sorry but this doesn't add up. Here you say that we can't have a 
clear line to draw until everything is converted but...

> I do seem to recall though that, perhaps in a
> different context, Andrew recently agreed with my view here (Andrew,
> please correct me if I'm wrong). It being a fuzzy thing, I guess
> maintainers get to judge ...

... here you say the maintainers get to decide when to use mfn_eq() (or 
other typesafe construction). So basically, we would never be able to 
fully convert the code and therefore never draw a line.

As I am trying to convert x86 to use typesafe, I would like a bit more 
guidelines on your expectation for typesafe. Can you clarify it?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 10:27:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 10:27:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQTe3-00009R-00; Mon, 20 Apr 2020 10:27:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VyLZ=6E=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jQTe0-00009G-Vp
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 10:27:17 +0000
X-Inumbo-ID: 80f11d1a-82f1-11ea-9047-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 80f11d1a-82f1-11ea-9047-12813bfff9fa;
 Mon, 20 Apr 2020 10:27:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=HaDXFlQmidgbWj3zhL4GhucQd3bBxb6VifXw9Bq2UvE=; b=IbvbNLZ29weOQQ1I3Cqf1jPOOm
 0phH//EToN0VmbCNHwymylpfK3AJl2wI4pzF/WLp9co9km/4nkmPwhfGwcpp+9vFQVkxwdD+QaMuj
 5gJfFM2XM4c9e8Sxm73ockdryzIFOIOn1Zlyd7fJIfacPB2RNCDUIxwGceBvjtcNVuWI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jQTdx-0001ZX-TV; Mon, 20 Apr 2020 10:27:13 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jQTdx-0003Kk-JB; Mon, 20 Apr 2020 10:27:13 +0000
Date: Mon, 20 Apr 2020 11:27:10 +0100
From: Wei Liu <wl@xen.org>
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v3] Introduce a description of the Backport and Fixes tags
Message-ID: <20200420102710.cg3bmjlntgpxqj77@debian>
References: <20200417222430.20480-1-sstabellini@kernel.org>
 <35b34e2f-e6cd-6afc-19fd-c7880ec0eace@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <35b34e2f-e6cd-6afc-19fd-c7880ec0eace@xen.org>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, Stefano Stabellini <sstabellini@kernel.org>,
 Wei Liu <wl@xen.org>, konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, george.dunlap@citrix.com,
 jbeulich@suse.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 20, 2020 at 10:31:28AM +0100, Julien Grall wrote:
> Hi Stefano,
> 
> On 17/04/2020 23:24, Stefano Stabellini wrote:
> > Create a new document under docs/process to describe our special tags.
> > Add a description of the Fixes tag and the new Backport tag. Also
> > clarify that lines with tags should not be split.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > CC: Ian Jackson <ian.jackson@eu.citrix.com>
> > CC: Wei Liu <wl@xen.org>
> > CC: jbeulich@suse.com
> > CC: george.dunlap@citrix.com
> > CC: julien@xen.org
> > CC: lars.kurth@citrix.com
> > CC: andrew.cooper3@citrix.com
> > CC: konrad.wilk@oracle.com
> > ---
> > Removing Acks as I added the description of "Fixes"
> > ---
> >   docs/process/tags.pandoc | 55 ++++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 55 insertions(+)
> >   create mode 100644 docs/process/tags.pandoc
> > 
> > diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
> > new file mode 100644
> > index 0000000000..06b06dda01
> > --- /dev/null
> > +++ b/docs/process/tags.pandoc
> > @@ -0,0 +1,55 @@
> > +Tags: No line splitting
> > +-----------------------
> > +Do not split a tag across multiple lines, tags are exempt from the
> > +"wrap at 75 columns" rule in order to simplify parsing scripts.  For
> > +example:
> > +
> > +        Fixes: 67d01cdb5 ("x86: infrastructure to allow converting certain indirect calls to direct ones")
> 
> The SHA-1 ID is 9 characters but...
> 
> > +
> > +
> > +Fixes Tag
> > +---------
> > +
> > +If your patch fixes a bug in a specific commit, e.g. you found an issue using
> > +``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
> > +the SHA-1 ID, and the one line summary.
> 
> ... you request 12 characters here. Can you make sure the two match please?
> 
> However, I am not entirely sure why we should mandate 12 characters. With
> the title, you should always be able to find back the commit if there is a
> clash.

This is copied from Linux's document.

I normally use 8-9 characters, but I don't mind using 12 either.

Wei.


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:09:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVEO-0008WR-Iy; Mon, 20 Apr 2020 12:08:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQVEM-0008WM-Vs
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:08:55 +0000
X-Inumbo-ID: b4215f98-82ff-11ea-9053-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b4215f98-82ff-11ea-9053-12813bfff9fa;
 Mon, 20 Apr 2020 12:08:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=3uJrIP1KzKW+tm4uKI8YsSCB6DZyKMvlrY4HiQcrG3Q=; b=P05JlT1xupwI1L9Jus1usXaSri
 mb8VV6gHAm0drj82kl6/c/UR/HS+0g7wI3p9AM/n/gkQXSxQYW9A/d0bMyrBRoQzEcTeKOXkVb59Q
 ym6l1a4e3wJTCYqNA7dWL5MlLAGHP1g1qFtUJtdBBbxQl1L+V3Qsocsk05PIKO0cVG1Y=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQVEK-0003aE-7R; Mon, 20 Apr 2020 12:08:52 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQVEJ-0000Zp-W0; Mon, 20 Apr 2020 12:08:52 +0000
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
To: Jan Beulich <jbeulich@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
 <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
 <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
 <80621ca8-6c08-2868-ada6-bf0ef41fc699@xen.org>
 <802bfbad-a0d7-8d7a-716d-76f0b83c5707@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <136f8a16-3160-04f7-55f3-667f578e505e@xen.org>
Date: Mon, 20 Apr 2020 13:08:49 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <802bfbad-a0d7-8d7a-716d-76f0b83c5707@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 20/04/2020 08:26, Jan Beulich wrote:
> On 17.04.2020 19:13, Julien Grall wrote:
>> On 17/04/2020 10:44, Jan Beulich wrote:
>>> On 17.04.2020 10:37, Julien Grall wrote:
>>>> On 16/04/2020 16:46, Jan Beulich wrote:
>>>>> --- a/xen/arch/x86/mm/p2m.c
>>>>> +++ b/xen/arch/x86/mm/p2m.c
>>>>> @@ -1779,7 +1779,8 @@ void p2m_mem_paging_populate(struct doma
>>>>>      * mfn if populate was called for  gfn which was nominated but not evicted. In
>>>>>      * this case only the p2mt needs to be forwarded.
>>>>>      */
>>>>> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l, uint64_t buffer)
>>>>> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l,
>>>>> +                        XEN_GUEST_HANDLE_PARAM(const_uint8) buffer)
>>>>
>>>> Shouldn't this technically be XEN_GUEST_HANDLE_64() to match the field?
>>>
>>> I think an argument can be made for going either way - as a function
>>> parameter it should have the type chosen. Do you see any (possibly
>>> just latent) breakage from using _PARAM() rather than _64()?
>> I know they are the same on x86, but from an abstract PoV they are fundamentally different.
>>
>> XEN_GUEST_HANDLE_PARAM() represents a guest pointer, when pased as an
>> hypercall argument.
>>
>> XEN_GUEST_HANDLE() represents a guest pointer, when passed as a field
>> in a struct in memory.
>>
>> In this case, the guest pointer was part of a structure. So I think
>> you want to use XEN_GUEST_HANDLE().
> 
> Hmm, looks like I was confused about what the two mean. So far I was
> under the impression that _PARAM() was to be used for function
> parameters in general, not just hypercall ones. While the text near
> the macro definitions is quite clear in this regard, I'm afraid
> Stefano's original series (first and foremost commit abf06ea91d12's
> playing with e.g. handle_iomem_range()) was rather confusing than
> helpful - it looks to me as if quite a bit of the "casting" could
> actually be dropped (I'll see about doing some cleanup there). Plus
> I'm afraid other mixing of plain vs param has been introduced on
> x86, at least for dm.c:track_dirty_vram()'s calls to
> {hap,shadow}_track_dirty_vram(); this is just the first instance
> I've found - there may be more.

I agree the commit you mention above is confusing. If we follow the 
definition, then the conversion between the two internally should never 
have been done.

Maybe Stefano can clarify the intention?

>> FWIW, the different matters on Arm. Although, it looks like the
>> compiler will not warn you if you are using the wrong handler :(.
> 
> I find this highly suspicious, but can't check myself until back
> in the office - these are distinct compound types after all, so
> this shouldn't just be a warning, but an error. Or did you merely
> mean there's no warning on x86?

I mean on Arm 32-bit. I have changed one of the function to use 
XEN_GUEST_HANDLE_PARAM() rather than XEN_GUEST_HANDLE() but not changing 
the caller.

It is probably because they are both defined using an union. Interestly, 
the type will also not be checked, so the code a function will happily 
accept a XEN_GUEST_HANDLE_PARAM(uint8) even if the prototype requested 
XEN_GUEST_HANDLE_PARAM(uint64).

This looks rather messy, maybe we should use a structure (and some 
alignment) to add more safety.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:12:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:12:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVHY-0000rg-4T; Mon, 20 Apr 2020 12:12:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQVHX-0000rb-OW
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:12:11 +0000
X-Inumbo-ID: 293d4328-8300-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 293d4328-8300-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 12:12:10 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 11BBFABAD;
 Mon, 20 Apr 2020 12:12:09 +0000 (UTC)
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
To: Julien Grall <julien@xen.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
 <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
 <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
 <80621ca8-6c08-2868-ada6-bf0ef41fc699@xen.org>
 <802bfbad-a0d7-8d7a-716d-76f0b83c5707@suse.com>
 <136f8a16-3160-04f7-55f3-667f578e505e@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f281c763-42ea-ae6f-7c1c-2a5523a64db9@suse.com>
Date: Mon, 20 Apr 2020 14:12:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <136f8a16-3160-04f7-55f3-667f578e505e@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 14:08, Julien Grall wrote:
> On 20/04/2020 08:26, Jan Beulich wrote:
>> On 17.04.2020 19:13, Julien Grall wrote:
>>> FWIW, the different matters on Arm. Although, it looks like the
>>> compiler will not warn you if you are using the wrong handler :(.
>>
>> I find this highly suspicious, but can't check myself until back
>> in the office - these are distinct compound types after all, so
>> this shouldn't just be a warning, but an error. Or did you merely
>> mean there's no warning on x86?
> 
> I mean on Arm 32-bit. I have changed one of the function to use XEN_GUEST_HANDLE_PARAM() rather than XEN_GUEST_HANDLE() but not changing the caller.
> 
> It is probably because they are both defined using an union. Interestly, the type will also not be checked, so the code a function will happily accept a XEN_GUEST_HANDLE_PARAM(uint8) even if the prototype requested XEN_GUEST_HANDLE_PARAM(uint64).
> 
> This looks rather messy, maybe we should use a structure (and some alignment) to add more safety.

Are the unions plain ones? I could see room for behavior like
the one you describe with transparent unions, albeit still
not quite like you describe it. Getting handle types to be
properly type-checked by the compiler is pretty imperative imo.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:13:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:13:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVIr-0000yX-Gb; Mon, 20 Apr 2020 12:13:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQVIq-0000yP-5g
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:13:32 +0000
X-Inumbo-ID: 59bd5dda-8300-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 59bd5dda-8300-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 12:13:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=L9TqMVZQYqMWHi2FhTfEDDZifUufm8YPzvfzEYDISAg=; b=D/SKxKYy1pAYXMH0qsUbgF7zcq
 piQZ8o2FbcB1cJr4Cq3WcJRRtMKgMW4B/lMqW5Ps/E7AiZyroUeYMcroR8hNEYG7m6EcbkDKpF4fI
 6RXNs9oAw6gDuWIvWb2yghLXXbGDYFGyxn753B7UUl8QS7BAZwYCvvOSPyBILzxaoKhU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQVIj-0003gw-RP; Mon, 20 Apr 2020 12:13:25 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQVIj-0000yk-KO; Mon, 20 Apr 2020 12:13:25 +0000
Subject: Re: [PATCH 0/8] Fix build with using OCaml 4.06.1 and -safe-string
To: Christian Lindig <christian.lindig@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 David Scott <dave@recoil.org>
References: <20200330192157.1335-1-julien@xen.org>
 <67d3370c-779a-7007-e5fa-98d957a85ce9@xen.org>
 <1587043532025.36720@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <b585e4c0-5770-4b56-3a1c-96b5c749fa78@xen.org>
Date: Mon, 20 Apr 2020 13:13:22 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1587043532025.36720@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 "dfaggioli@suse.com" <dfaggioli@suse.com>, Jan Beulich <jbeulich@suse.com>,
 Ian Jackson <Ian.Jackson@citrix.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Christian,

On 16/04/2020 14:25, Christian Lindig wrote:
> 
> The changes in the OCaml C stubs look good to me. They don't really touch the interface but are mostly concerned with types on the C side by adding casts, const, and so on. The extended error handling is an improvement.

Thank you for the review! I will commit the rest of the series.

As an aside, the acked-by was adding as part of the signature.

Not sure whether this is intentional but some e-mail clients are hiding 
the signature so the acked-by can be easily missed.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:15:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:15:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVKD-00014X-TZ; Mon, 20 Apr 2020 12:14:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQVKC-00014Q-HY
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:14:56 +0000
X-Inumbo-ID: 8b91a62c-8300-11ea-9055-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8b91a62c-8300-11ea-9055-12813bfff9fa;
 Mon, 20 Apr 2020 12:14:55 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BBA0CABAD;
 Mon, 20 Apr 2020 12:14:53 +0000 (UTC)
Subject: Re: [PATCH 05/17] xen/x86: Remove the non-typesafe version of
 pagetable_* helpers
To: Julien Grall <julien@xen.org>
References: <20200322161418.31606-1-julien@xen.org>
 <20200322161418.31606-6-julien@xen.org>
 <b0d29ded-f0e8-013b-de43-22788cd8f599@suse.com>
 <2be87441-05a6-6b58-23e3-da467230ffe7@xen.org>
 <cf983d3e-125a-621a-f81d-2f9955ec86eb@suse.com>
 <f72f5c31-c437-549a-9d8b-8b836caf699b@xen.org>
 <6af445d8-636f-a19e-ac53-9c66ae9f61c5@suse.com>
 <0bb49716-6b1c-0beb-01c5-4c0d220ca011@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e9b5d086-3d95-68cc-a8d3-7c3309dae464@suse.com>
Date: Mon, 20 Apr 2020 14:14:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <0bb49716-6b1c-0beb-01c5-4c0d220ca011@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 12:10, Julien Grall wrote:
> Hi,
> 
> On 20/04/2020 10:16, Jan Beulich wrote:
>> On 18.04.2020 12:23, Julien Grall wrote:
>>> On 30/03/2020 08:52, Jan Beulich wrote:
>>>> On 28.03.2020 11:52, Julien Grall wrote:
>>>>> On 26/03/2020 15:39, Jan Beulich wrote:
>>>>>> On 22.03.2020 17:14, julien@xen.org wrote:
>>>>>>> @@ -3116,24 +3116,24 @@ int vcpu_destroy_pagetables(struct vcpu *v)
>>>>>>>           /* Free that page if non-zero */
>>>>>>>         do {
>>>>>>> -        if ( mfn )
>>>>>>> +        if ( !mfn_eq(mfn, _mfn(0)) )
>>>>>>
>>>>>> I admit I'm not fully certain either, but at the first glance
>>>>>>
>>>>>>            if ( mfn_x(mfn) )
>>>>>>
>>>>>> would seem more in line with the original code to me (and then
>>>>>> also elsewhere).
>>>>>
>>>>> It is doing *exactly* the same things. The whole point of typesafe
>>>>> is to use typesafe helper not open-coding test everywhere.
>>>>>
>>>>> It is also easier to spot any use of MFN 0 within the code as you
>>>>> know could grep "_mfn(0)".
>>>>>
>>>>> Therefore I will insist to the code as-is.
>>>>
>>>> What I insit on is that readability of the result of such changes be
>>>> also kept in mind. The mfn_eq() construct is (I think) clearly less
>>>> easy to read and recognize than the simpler alternative suggested.
>>>
>>> If mfn_eq() is less clear, then where do you draw the line when the
>>> macro should or not be used?
>>
>> I'm afraid there may not be a clear line to draw until everything
>> got converted.
> 
> I am sorry but this doesn't add up. Here you say that we can't have
> a clear line to draw until everything is converted but...
> 
>> I do seem to recall though that, perhaps in a
>> different context, Andrew recently agreed with my view here (Andrew,
>> please correct me if I'm wrong). It being a fuzzy thing, I guess
>> maintainers get to judge ...
> 
> ... here you say the maintainers get to decide when to use mfn_eq()
> (or other typesafe construction). So basically, we would never be
> able to fully convert the code and therefore never draw a line.

Why? Eventually both sides of an mfn_eq() will be of type mfn_t. And
in the specific case hand even with my alternative suggestion no
further change would  be needed down the road. Type safety is for
things like function argument passing and assignments and alike. A
leaf expression like "if ( mfn_x() )" is not type-unsafe in any way.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:20:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVPN-0001vY-J8; Mon, 20 Apr 2020 12:20:17 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQVPL-0001vT-LF
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:20:15 +0000
X-Inumbo-ID: 49e185ac-8301-11ea-9055-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 49e185ac-8301-11ea-9055-12813bfff9fa;
 Mon, 20 Apr 2020 12:20:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mGRCjKmvDhbwpEpcE8+rBn9Bxzl3KHCygMwMaf+uDE4=; b=5rzNsVv2EKrJ6bvrNoROZ6boW6
 rCmRxZHegomnzolQwBABAkcN2RifpJcDKuVwxaIIVQmjSnQ0XPvsrNaZmCoiWMWJWS50Le5pJ3FvV
 luG4vcRVPVp2frYuxSjmuLiSqNJGJqMg/VfkCYdVK9sxjvKQG0TAp5DAVrK2OfDtnhWk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQVPH-0003po-KX; Mon, 20 Apr 2020 12:20:11 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQVPH-0001DV-D5; Mon, 20 Apr 2020 12:20:11 +0000
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
To: Jan Beulich <jbeulich@suse.com>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
 <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
 <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
 <80621ca8-6c08-2868-ada6-bf0ef41fc699@xen.org>
 <802bfbad-a0d7-8d7a-716d-76f0b83c5707@suse.com>
 <136f8a16-3160-04f7-55f3-667f578e505e@xen.org>
 <f281c763-42ea-ae6f-7c1c-2a5523a64db9@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <5f1298c1-3931-2bf2-381e-51cc8afcdca9@xen.org>
Date: Mon, 20 Apr 2020 13:20:09 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <f281c763-42ea-ae6f-7c1c-2a5523a64db9@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 20/04/2020 13:12, Jan Beulich wrote:
> On 20.04.2020 14:08, Julien Grall wrote:
>> On 20/04/2020 08:26, Jan Beulich wrote:
>>> On 17.04.2020 19:13, Julien Grall wrote:
>>>> FWIW, the different matters on Arm. Although, it looks like the
>>>> compiler will not warn you if you are using the wrong handler :(.
>>>
>>> I find this highly suspicious, but can't check myself until back
>>> in the office - these are distinct compound types after all, so
>>> this shouldn't just be a warning, but an error. Or did you merely
>>> mean there's no warning on x86?
>>
>> I mean on Arm 32-bit. I have changed one of the function to use XEN_GUEST_HANDLE_PARAM() rather than XEN_GUEST_HANDLE() but not changing the caller.
>>
>> It is probably because they are both defined using an union. Interestly, the type will also not be checked, so the code a function will happily accept a XEN_GUEST_HANDLE_PARAM(uint8) even if the prototype requested XEN_GUEST_HANDLE_PARAM(uint64).
>>
>> This looks rather messy, maybe we should use a structure (and some alignment) to add more safety.
> 
> Are the unions plain ones? I could see room for behavior like
> the one you describe with transparent unions, albeit still
> not quite like you describe it. Getting handle types to be
> properly type-checked by the compiler is pretty imperative imo.

It looks like x86 is using structure, but arm is using plain union:

#define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
     typedef union { type *p; unsigned long q; }                 \
         __guest_handle_ ## name;                                \
     typedef union { type *p; uint64_aligned_t q; }              \
         __guest_handle_64_ ## name

I will look at introducing a union on Arm.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:31:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVaR-0002qF-Oh; Mon, 20 Apr 2020 12:31:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQVaR-0002qA-Bm
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:31:43 +0000
X-Inumbo-ID: e323cca6-8302-11ea-9057-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e323cca6-8302-11ea-9057-12813bfff9fa;
 Mon, 20 Apr 2020 12:31:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id ADB5DABCE;
 Mon, 20 Apr 2020 12:31:39 +0000 (UTC)
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
To: Julien Grall <julien@xen.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
 <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
 <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
 <80621ca8-6c08-2868-ada6-bf0ef41fc699@xen.org>
 <802bfbad-a0d7-8d7a-716d-76f0b83c5707@suse.com>
 <136f8a16-3160-04f7-55f3-667f578e505e@xen.org>
 <f281c763-42ea-ae6f-7c1c-2a5523a64db9@suse.com>
 <5f1298c1-3931-2bf2-381e-51cc8afcdca9@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <d4b276dd-6ebc-6c43-bda5-37a1cd19d384@suse.com>
Date: Mon, 20 Apr 2020 14:31:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5f1298c1-3931-2bf2-381e-51cc8afcdca9@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 14:20, Julien Grall wrote:
> Hi,
> 
> On 20/04/2020 13:12, Jan Beulich wrote:
>> On 20.04.2020 14:08, Julien Grall wrote:
>>> On 20/04/2020 08:26, Jan Beulich wrote:
>>>> On 17.04.2020 19:13, Julien Grall wrote:
>>>>> FWIW, the different matters on Arm. Although, it looks like the
>>>>> compiler will not warn you if you are using the wrong handler :(.
>>>>
>>>> I find this highly suspicious, but can't check myself until back
>>>> in the office - these are distinct compound types after all, so
>>>> this shouldn't just be a warning, but an error. Or did you merely
>>>> mean there's no warning on x86?
>>>
>>> I mean on Arm 32-bit. I have changed one of the function to use XEN_GUEST_HANDLE_PARAM() rather than XEN_GUEST_HANDLE() but not changing the caller.
>>>
>>> It is probably because they are both defined using an union. Interestly, the type will also not be checked, so the code a function will happily accept a XEN_GUEST_HANDLE_PARAM(uint8) even if the prototype requested XEN_GUEST_HANDLE_PARAM(uint64).
>>>
>>> This looks rather messy, maybe we should use a structure (and some alignment) to add more safety.
>>
>> Are the unions plain ones? I could see room for behavior like
>> the one you describe with transparent unions, albeit still
>> not quite like you describe it. Getting handle types to be
>> properly type-checked by the compiler is pretty imperative imo.
> 
> It looks like x86 is using structure, but arm is using plain union:
> 
> #define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
>     typedef union { type *p; unsigned long q; }                 \
>         __guest_handle_ ## name;                                \
>     typedef union { type *p; uint64_aligned_t q; }              \
>         __guest_handle_64_ ## name

I don't see how this would make a difference, and hence ...

> I will look at introducing a union on Arm.

... how this would help. I must be missing something, or there
must be a very curious bug in only the Arm gcc.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:35:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVe3-00031A-Ca; Mon, 20 Apr 2020 12:35:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQVe2-000315-Kk
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:35:26 +0000
X-Inumbo-ID: 681fb7e5-8303-11ea-9058-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 681fb7e5-8303-11ea-9058-12813bfff9fa;
 Mon, 20 Apr 2020 12:35:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 64BB5ABCE;
 Mon, 20 Apr 2020 12:35:24 +0000 (UTC)
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
 <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
 <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
 <80621ca8-6c08-2868-ada6-bf0ef41fc699@xen.org>
 <802bfbad-a0d7-8d7a-716d-76f0b83c5707@suse.com>
 <136f8a16-3160-04f7-55f3-667f578e505e@xen.org>
 <f281c763-42ea-ae6f-7c1c-2a5523a64db9@suse.com>
 <5f1298c1-3931-2bf2-381e-51cc8afcdca9@xen.org>
 <d4b276dd-6ebc-6c43-bda5-37a1cd19d384@suse.com>
Message-ID: <9deece3d-fd3c-8d94-f4ed-7bfe77d3a47e@suse.com>
Date: Mon, 20 Apr 2020 14:35:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d4b276dd-6ebc-6c43-bda5-37a1cd19d384@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 14:31, Jan Beulich wrote:
> On 20.04.2020 14:20, Julien Grall wrote:
>> On 20/04/2020 13:12, Jan Beulich wrote:
>>> On 20.04.2020 14:08, Julien Grall wrote:
>>> Are the unions plain ones? I could see room for behavior like
>>> the one you describe with transparent unions, albeit still
>>> not quite like you describe it. Getting handle types to be
>>> properly type-checked by the compiler is pretty imperative imo.
>>
>> It looks like x86 is using structure, but arm is using plain union:
>>
>> #define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
>>     typedef union { type *p; unsigned long q; }                 \
>>         __guest_handle_ ## name;                                \
>>     typedef union { type *p; uint64_aligned_t q; }              \
>>         __guest_handle_64_ ## name
> 
> I don't see how this would make a difference, and hence ...
> 
>> I will look at introducing a union on Arm.
> 
> ... how this would help. I must be missing something, or there
> must be a very curious bug in only the Arm gcc.

Compiling this (for x86) properly raises two errors:

union u1 { void *p; unsigned long v; };
union u2 { void *p; unsigned long v; };

void test(union u1 u1, union u2 u2) {
	test(u1, u1);
	test(u2, u2);
}

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:36:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVfT-00039B-1v; Mon, 20 Apr 2020 12:36:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQVfR-00038p-7S
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:36:53 +0000
X-Inumbo-ID: 9c896818-8303-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9c896818-8303-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 12:36:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C6866ABCE;
 Mon, 20 Apr 2020 12:36:50 +0000 (UTC)
Subject: Re: [PATCH v3] Introduce a description of the Backport and Fixes tags
To: Wei Liu <wl@xen.org>
References: <20200417222430.20480-1-sstabellini@kernel.org>
 <35b34e2f-e6cd-6afc-19fd-c7880ec0eace@xen.org>
 <20200420102710.cg3bmjlntgpxqj77@debian>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <a4cfb801-f0c5-f08d-02fc-c35820bccd87@suse.com>
Date: Mon, 20 Apr 2020 14:36:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200420102710.cg3bmjlntgpxqj77@debian>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, konrad.wilk@oracle.com,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 george.dunlap@citrix.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 12:27, Wei Liu wrote:
> On Mon, Apr 20, 2020 at 10:31:28AM +0100, Julien Grall wrote:
>> On 17/04/2020 23:24, Stefano Stabellini wrote:
>>> Create a new document under docs/process to describe our special tags.
>>> Add a description of the Fixes tag and the new Backport tag. Also
>>> clarify that lines with tags should not be split.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
>>> CC: Ian Jackson <ian.jackson@eu.citrix.com>
>>> CC: Wei Liu <wl@xen.org>
>>> CC: jbeulich@suse.com
>>> CC: george.dunlap@citrix.com
>>> CC: julien@xen.org
>>> CC: lars.kurth@citrix.com
>>> CC: andrew.cooper3@citrix.com
>>> CC: konrad.wilk@oracle.com
>>> ---
>>> Removing Acks as I added the description of "Fixes"
>>> ---
>>>   docs/process/tags.pandoc | 55 ++++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 55 insertions(+)
>>>   create mode 100644 docs/process/tags.pandoc
>>>
>>> diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
>>> new file mode 100644
>>> index 0000000000..06b06dda01
>>> --- /dev/null
>>> +++ b/docs/process/tags.pandoc
>>> @@ -0,0 +1,55 @@
>>> +Tags: No line splitting
>>> +-----------------------
>>> +Do not split a tag across multiple lines, tags are exempt from the
>>> +"wrap at 75 columns" rule in order to simplify parsing scripts.  For
>>> +example:
>>> +
>>> +        Fixes: 67d01cdb5 ("x86: infrastructure to allow converting certain indirect calls to direct ones")
>>
>> The SHA-1 ID is 9 characters but...
>>
>>> +
>>> +
>>> +Fixes Tag
>>> +---------
>>> +
>>> +If your patch fixes a bug in a specific commit, e.g. you found an issue using
>>> +``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
>>> +the SHA-1 ID, and the one line summary.
>>
>> ... you request 12 characters here. Can you make sure the two match please?
>>
>> However, I am not entirely sure why we should mandate 12 characters. With
>> the title, you should always be able to find back the commit if there is a
>> clash.
> 
> This is copied from Linux's document.
> 
> I normally use 8-9 characters, but I don't mind using 12 either.

Are they still saying 9? I've been asked to switch to 12 several
weeks back ...

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:51:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:51:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVtL-0004p4-Ho; Mon, 20 Apr 2020 12:51:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQVtK-0004oz-8o
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:51:14 +0000
X-Inumbo-ID: 9df0a5f2-8305-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9df0a5f2-8305-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 12:51:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tK8XpUBJH/bCZBQEfI5zHBmTZGkN3X/Q4OvyGS2xYq8=; b=kD+EwccCUb2qqCAE3/rPO53r0B
 9Fy7Xdg/CQkqLHY/Gu8O3F59lY4UOdikQHvTZB2h9jrG5bGpBCyAR3+AxoTlIrVCB7c8jqRyYfWDR
 C8PDjCmrtpJ2ecQvL1sT9D9b5VN1PlEQJGsSRKEeYC597iMQZFzbq0ViJ8KWJVC9LyTE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQVtJ-0004Rx-4F; Mon, 20 Apr 2020 12:51:13 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQVtI-0002xx-Sm; Mon, 20 Apr 2020 12:51:13 +0000
Subject: Re: [PATCH 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
To: Jan Beulich <jbeulich@suse.com>
References: <3b7cc69d-709c-570a-716a-c45f6fda181f@suse.com>
 <f3c57792-d372-a70f-691b-87681b83e898@suse.com>
 <d340e170-1c08-e20a-b170-c176eb00b4dd@xen.org>
 <5e1dc7fd-f780-31bc-670d-4736061f46af@suse.com>
 <80621ca8-6c08-2868-ada6-bf0ef41fc699@xen.org>
 <802bfbad-a0d7-8d7a-716d-76f0b83c5707@suse.com>
 <136f8a16-3160-04f7-55f3-667f578e505e@xen.org>
 <f281c763-42ea-ae6f-7c1c-2a5523a64db9@suse.com>
 <5f1298c1-3931-2bf2-381e-51cc8afcdca9@xen.org>
 <d4b276dd-6ebc-6c43-bda5-37a1cd19d384@suse.com>
 <9deece3d-fd3c-8d94-f4ed-7bfe77d3a47e@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <6c693204-21a4-100a-d2c0-32dffb804551@xen.org>
Date: Mon, 20 Apr 2020 13:51:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9deece3d-fd3c-8d94-f4ed-7bfe77d3a47e@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 20/04/2020 13:35, Jan Beulich wrote:
> On 20.04.2020 14:31, Jan Beulich wrote:
>> On 20.04.2020 14:20, Julien Grall wrote:
>>> On 20/04/2020 13:12, Jan Beulich wrote:
>>>> On 20.04.2020 14:08, Julien Grall wrote:
>>>> Are the unions plain ones? I could see room for behavior like
>>>> the one you describe with transparent unions, albeit still
>>>> not quite like you describe it. Getting handle types to be
>>>> properly type-checked by the compiler is pretty imperative imo.
>>>
>>> It looks like x86 is using structure, but arm is using plain union:
>>>
>>> #define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
>>>      typedef union { type *p; unsigned long q; }                 \
>>>          __guest_handle_ ## name;                                \
>>>      typedef union { type *p; uint64_aligned_t q; }              \
>>>          __guest_handle_64_ ## name
>>
>> I don't see how this would make a difference, and hence ...
>>
>>> I will look at introducing a union on Arm.
>>
>> ... how this would help. I must be missing something, or there
>> must be a very curious bug in only the Arm gcc.
> 
> Compiling this (for x86) properly raises two errors:
> 
> union u1 { void *p; unsigned long v; };
> union u2 { void *p; unsigned long v; };
> 
> void test(union u1 u1, union u2 u2) {
> 	test(u1, u1);
> 	test(u2, u2);
> }

You are right. It is just me not compiling properly. Sorry for the noise :(

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 12:55:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 12:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQVxn-0004yz-5h; Mon, 20 Apr 2020 12:55:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=/aJH=6E=mail.ru=santucco@srs-us1.protection.inumbo.net>)
 id 1jQVxl-0004yu-15
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 12:55:49 +0000
X-Inumbo-ID: 3feba4f6-8306-11ea-905f-12813bfff9fa
Received: from f147.i.mail.ru (unknown [128.140.171.241])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3feba4f6-8306-11ea-905f-12813bfff9fa;
 Mon, 20 Apr 2020 12:55:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru;
 s=mail2; 
 h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From;
 bh=T8fjMe5JtuImrQM2eFc5bdH0WDmYi09sX/OXK0UPnro=; 
 b=UitNIhb1ep425C7GbSkrwt9zeHxOge0rUyHY5Pk4mrWehhUb85i4yJsaEZOgpY5ww+7/ec5+4g6YAEQWXusXBNBmqNz/ivO7N9fiGYAtg+IJdUYWTncYrrly4x5hbEMk8mj4S8PH9PbvfzUBmlRjYspePJbz6eec0sSzye6BKPI=;
Received: by f147.i.mail.ru with local (envelope-from <santucco@mail.ru>)
 id 1jQVxg-0003eP-7i; Mon, 20 Apr 2020 15:55:44 +0300
Received: by e.mail.ru with HTTP;
	Mon, 20 Apr 2020 15:55:44 +0300
From: =?UTF-8?B?U2FudHVjY28=?= <santucco@mail.ru>
To: =?UTF-8?B?T2xla3NhbmRyIEFuZHJ1c2hjaGVua28=?=
 <oleksandr_andrushchenko@epam.com>
Subject: =?UTF-8?B?UmVbMl06IFtYZW4tZGV2ZWxdIFBWIERSTSBkb2Vzbid0IHdvcmsgd2l0aG91?=
 =?UTF-8?B?dCBhdXRvX3RyYW5zbGF0ZWRfcGh5c21hcCBmZWF0dXJlIGluIERvbTA=?=
MIME-Version: 1.0
X-Mailer: Mail.Ru Mailer 1.0
Date: Mon, 20 Apr 2020 15:55:44 +0300
X-Priority: 3 (Normal)
Message-ID: <1587387344.546879054@f147.i.mail.ru>
Content-Type: multipart/alternative;
 boundary="--ALT--2cAeB49257DbbC9313Db7a25C7c5C5eE1587387344"
In-Reply-To: <da633357-6c40-217f-e59d-d770da573240@epam.com>
References: <1580804903.724638150@f311.i.mail.ru>
 <1587295574.703588442@f508.i.mail.ru>
 <da633357-6c40-217f-e59d-d770da573240@epam.com>
Authentication-Results: f147.i.mail.ru; auth=pass smtp.auth=santucco@mail.ru
 smtp.mailfrom=santucco@mail.ru
X-7564579A: 646B95376F6C166E
X-77F55803: 0A44E481635329DB4E7FAE048FD183FFD32E5E48865217364D5B7DD649282911C2102407321185A3FBDBF69DD7E3F538A78D8A3DE626E6153A4EFC669FFC40A85F1F19FEC15D7B800499F951132FAAA9
X-7FA49CB5: 70AAF3C13DB7016878DA827A17800CE791A5C024950FE862D82A6BABE6F325AC9EB98D58427B1C2ABCF491FFA38154B613377AFFFEAFD269176DF2183F8FC7C0E338B9D28515FD48C2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE7BA0D57D3459E5640EA1F7E6F0F101C674E70A05D1297E1BBC6CDE5D1141D2B1CE42E74F51656BF27DAC8A3D88DE792F29314C08A77E655319FA2833FD35BB23D9E625A9149C048EE9ECD01F8117BC8BEA471835C12D1D9774AD6D5ED66289B524E70A05D1297E1BBF6B57BC7E64490611E7FA7ABCAF51C92A417C69337E82CC2CC7F00164DA146DA6F5DAA56C3B73B23E7DDDDC251EA7DABAAAE862A0553A39223F8577A6DFFEA7CFA80D66F452D417A43847C11F186F3C5E7DDDDC251EA7DABCC89B49CDF41148FDCD13837A2BCF0203C9F3DD0FB1AF5EB4E70A05D1297E1BBCB5012B2E24CD356
X-D57D3AED: Y8kq8+OzVozcFQziTi/Zi098oNK9gy3Irm5KFwLuDg60je4lC+GbTj0M8KbzpOmgsB7wYP6nnel8wfEHQiZAetlEg7qy07ISeqrIhHPnkjzDMJz2FR7vUA==
X-Mailru-Internal-Actual: A:0.82303108184282
X-Mailru-MI: 900
X-Mailru-Sender: 8C9CBEE23AAD72FDED4E53C4A048AFBFB9391841CD250D838194700B7A614BA34A4BF3E678A38CAF96DF9BFA4323C77F7903AA853BEC14D60E09D1A5DFDDD82F8BC0F606C687C5A13A50EA9FAFF5C6D05CDCB0CA073FD32967EA787935ED9F1B
X-Mras: Ok
X-Spam: undefined
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: =?UTF-8?B?U2FudHVjY28=?= <santucco@mail.ru>
Cc: =?UTF-8?B?eGVuLWRldmVs?= <xen-devel@lists.xenproject.org>,
 =?UTF-8?B?T2xla3NhbmRyIEdyeXRzb3Y=?= <Oleksandr_Grytsov@epam.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


----ALT--2cAeB49257DbbC9313Db7a25C7c5C5eE1587387344
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

ClN1cmUuCsKgCkkgd2lsbCBtYWtlIGl0IGEgYml0IGxhdGVyLCB3aGVuIEkgaGF2ZSB0aGXCoG1v
cmUgc3RhYmxlIHJlc3VsdC4KwqAKQmVzdCByZWdhcmRzLApBbGV4YW5kZXIKwqAKwqAgCj7Qn9C+
0L3QtdC00LXQu9GM0L3QuNC6LCAyMCDQsNC/0YDQtdC70Y8gMjAyMCwgODo1OSArMDM6MDAg0L7R
giBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbyA8b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5j
b20+Ogo+wqAKPkhpLAo+Cj5PbiA0LzE5LzIwIDE0OjI2LCBTYW50dWNjbyB3cm90ZToKPj4gSGVs
bG8sCj4+IEkgaGF2ZSBmb3VuZCBhIHNvdXJjZSBvZiB0aGUgcHJvYmxlbS4KPj4gSW4gZGlzcGxf
YmUswqAgQmFzZUR1bXAgY29waWVzIHRvIHRoZSBkcm0gYnVmZmVyIHdpdGggYcKgc2l6ZSBmcm9t
Cj4+IGk5MTXCoGRybSBkcml2ZXIsIGJ1dCB0aGlzIHNpemUgYSBiaXQgbW9yZSB0aGFuIGHCoHNp
emUgb2bCoG15IGZyb250ZW5kCj4+IGRpc3BsYXkgYnVmZmVyLiBJIGhhdmUgbWFkZSBhIHF1aWNr
IGFuZCBkaXJ0ecKgZml4LMKgYSBjb3B5wqBhIGxpbmUgb2YgbXkKPj4gZGlzcGxheSBidWZmZXIg
dG8gYSBtaWRkbGUgb2YgYcKgbGluZSBvZsKgdGhlwqBkcm0gZGlzcGxheSBidWZmZXIuIFBhdGNo
Cj4+IGlzIGF0dGFjaGVkLgo+Cj5UaGFuayB5b3UgZm9yIHRoZSBwYXRjaCBhbmQgeW91ciBlZmZv
cnRzIHRvIGZpeCB0aGUgaXNzdWUuCj4KPkNvdWxkIHlvdSBwbGVhc2UgbWFrZSBhIHB1bGwgcmVx
dWVzdCB0byBbMV0sIHNvIHdlIGNhbiBjb250aW51ZSB0aGVyZT8KPgo+VGhhbmsgeW91IGluIGFk
dmFuY2UsCj4KPk9sZWtzYW5kcgo+Cj4+IEJlc3QgcmVnYXJkcywKPj4gQWxleGFuZGVyCj4+Cj4+
INCn0LXRgtCy0LXRgNCzLCA2INGE0LXQstGA0LDQu9GPIDIwMjAsIDExOjIwICswMzowMCDQvtGC
IE9sZWtzYW5kciBBbmRydXNoY2hlbmtvCj4+IDwgb2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBh
bS5jb20gPjoKPj4gT24gMi81LzIwIDg6NTkgUE0sIFNhbnR1Y2NvIHdyb3RlOgo+PiA+IEhlbGxv
LAo+PiA+IE9rLCBJwqAgY29tbWVudGVkIG91dCB0aGUgbWVtY3B5IGNhbGwgYW5kIHJ1bsKgdGhl
IHRlc3QuCj4+ID4gZGlzcGxfYmUgaGFzbuKAmXQgY3JhY2hlZCwgSSBoYXZlwqBzZWVuIEZMSVAg
ZXZlbnRzIGluIHRoZSBsb2cuCj4+ID4gQnV0IHRoZXJlIGhhc27igJl0IGJlZW7CoHRoZcKgYmxh
Y2sgc2NyZWVuLCBqdXN0IGHCoGJsaW5rIGVmZmVjdCBldmVyeQo+PiA+IGNvdXBsZSBvZiBzZWNv
bmRzLgo+PiA+IExvZ3MgYXJlIGF0dGFjaGVkLgo+PiBPaywgc28gSSBiZWxpZXZlIHRoYXQgZnJv
bnRlbmQgLSBiYWNrZW5kIChkaXNwbF9iZSkgY29tbXVuaWNhdGlvbgo+PiBpcyBvawo+PiBhbmQg
dGhlcmUgaXMgbm90aGluZyB0byBkbyB0aGVyZS4KPj4KPj4gTmV4dCwgSSB3b3VsZCBzdGFydCBk
ZWJ1Z2dpbmcgdGhlIGZvbGxvd2luZyBpbiBYZW46Cj4+IChYRU4pIG1tLmM6MjIyMzpkMnYwIEJh
ZCBMMSBmbGFncyA4MAo+PiBhbmQgaGF2ZSBhIGxvb2sgYXQgWzFdLiBQcm9iYWJseSwgc29tZW9u
ZSBvbiBYZW4geDg2IHNpZGUgY2FuIHRlbGwKPj4gaWYgdGhpcyBjb3VsZCBiZSByZWxhdGVkIHRv
IHRoZSBmbGFncyBhdCBbMl0uCj4+Cj4+ID4gQmVzdCByZWdhcmRzLAo+PiA+IEFsZXhhbmRlcgo+
PiA+Cj4+ID4g0KHRgNC10LTQsCwgNSDRhNC10LLRgNCw0LvRjyAyMDIwLCA5OjMxICswMzowMCDQ
vtGCIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvCj4+ID4gPCBvbGVrc2FuZHJfYW5kcnVzaGNoZW5r
b0BlcGFtLmNvbQo+PiA8L2NvbXBvc2U/VG89b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5j
b20+PjoKPj4gPiBPbiAyLzQvMjAgMTA6MjggQU0sIFNhbnR1Y2NvIHdyb3RlOgo+PiA+ID4gSGVs
bG8sCj4+ID4gPiBkaXNwbF9iZSB3YXMgY29tcGlsZWTCoHdpdGhvdXQgemVyby1jb3B5IHN1cHBv
cnQgZWFybHkuCj4+ID4gPiBJIGhhdmUgdHJpZWQgd2l0aCB0aGXCoHJlY29tcGlsZWQgZG9tMCBr
ZXJuZWwsIGEgcmVzdWx0IGlzwqB0aGUKPj4gc2FtZS4KPj4gPiA+IExvZ3MgYW5kIGNvbmZpZ3Mg
KCtkaXNwbF9iZeKAmXPCoENNYWtlQ2FjaGUudHh0wqApIGFyZSBhdHRhY2hlZC4KPj4gPiBPaywg
eWV0IGFub3RoZXIgdGVzdCB0byBsb2NhbGl6ZSB0aGUgcHJvYmxlbS4KPj4gPiBDb3VsZCB5b3Ug
cGxlYXNlIHJlbW92ZSBtZW1jcHkgZnJvbQo+PiA+ICMxwqAgMHgwMDAwNTVlNWExZjI4YmVjIGlu
IERybTo6RHVtYkRybTo6Y29weQo+PiAodGhpcz0weDdmOTMzODAwMGUwMCkgYXQKPj4gPgo+PiAv
aG9tZS9zYW50dWNjby90bXAveGVuLXRyb29wcy9kaXNwbF9iZS9zcmMvZGlzcGxheUJhY2tlbmQv
ZHJtL0R1bWIuY3BwOjE0OQo+PiA+IGFuZCBqdXN0IG1lbXNldCB0aGUgZGVzdGluYXRpb24gd2l0
aCAwIG9yIHdoYXRldmVyLgo+PiA+Cj4+ID4gSSBleHBlY3QgdGhhdCBzeXN0ZW0gd29uJ3QgY3Jh
c2gsIG5vdGhpbmcgd2lsbCBiZSBzaG93biAoYmxhY2sKPj4gPiBzY3JlZW4pLCBidXQKPj4gPiBk
aXNwbF9iZSB3aWxsIHNob3cgcGFnZSBmbGlwIGV2ZW50cyBpbiBpdHMgbG9ncy4KPj4gPiA+IEJl
c3QgcmVnYXJkcywKPj4gPiA+IEFsZXhhbmRlcgo+PiA+ID4KPj4gPiA+INCf0L7QvdC10LTQtdC7
0YzQvdC40LosIDMg0YTQtdCy0YDQsNC70Y8gMjAyMCwgMTA6MzYgKzAzOjAwINC+0YIgT2xla3Nh
bmRyCj4+ID4gPiBBbmRydXNoY2hlbmtvIDwgb2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5j
b20KPj4gPC9jb21wb3NlP1RvPW9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPgo+PiA+
IDwvY29tcG9zZT9Ubz1vbGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbT4+Ogo+PiA+ID4K
Pj4gPiA+Cj4+ID4gPiBPbiAyLzEvMjAgNDozOSBQTSwgU2FudHVjY28gd3JvdGU6Cj4+ID4gPiA+
IEhlbGxvIGFnYWluLAo+PiA+ID4gPiBJIGhhdmUgbm90IHlldCBtYWRlIHRvIHdvcmsgbXkgZHJt
IGNsaWVudCwgc28gSSBoYXZlIHRyaWVkCj4+IHRvIHJ1bgo+PiA+ID4gPiBsaW51eCBsaWtlIGEg
ZG9tVcKgKHRvIHNlZSBob3cgaXQgc2hvdWxkIHdvcmspLCBpdCBkb2VzbuKAmXQKPj4gd29yayB0
b28KPj4gPiA+ID4g4oCUwqBkaXNwbF9iZSBjYXRjaGVzIFNJR1NFR1Y6Cj4+ID4gPiA+Cj4+ID4g
PiA+ICMwIMKgMHgwMDAwN2Y0YWZlZDFjMTYxIGluID8/ICgpIGZyb20gL2xpYjY0L2xpYmMuc28u
Ngo+PiA+ID4gPiAjMSDCoDB4MDAwMDU1NzIzYjljNWJlYyBpbiBEcm06OkR1bWJEcm06OmNvcHkK
Pj4gPiA+ICh0aGlzPTB4N2Y0YWRjMDAwZTAwKSBhdAo+PiA+ID4gPgo+PiA+ID4KPj4gPgo+PiAv
aG9tZS9zYW50dWNjby90bXAveGVuLXRyb29wcy9kaXNwbF9iZS9zcmMvZGlzcGxheUJhY2tlbmQv
ZHJtL0R1bWIuY3BwOjE0OQo+PiA+ID4gPiAjMiDCoDB4MDAwMDU1NzIzYjlhOGY1MSBpbiBCdWZm
ZXJzU3RvcmFnZTo6Z2V0RnJhbWVCdWZmZXJBbmRDb3B5Cj4+ID4gPiA+ICh0aGlzPTB4N2Y0YWUw
MDAxMGUwLCBmYkNvb2tpZT0xODQ0NjYxMjY4MjI5NTA4MzI2NCkgYXQKPj4gPiA+ID4KPj4gPiA+
Cj4+ID4KPj4gL2hvbWUvc2FudHVjY28vdG1wL3hlbi10cm9vcHMvZGlzcGxfYmUvc3JjL2Rpc3Bs
YXlCYWNrZW5kL0J1ZmZlcnNTdG9yYWdlLmNwcDoxNjUKPj4gPiA+ID4gSXQgdHJpZXMgdG8gY29w
eSB0byBtQnVmZmVyIHdpdGggbm9uLWFjY2Vzc2libGUgYWRkcmVzcy4KPj4gPiA+ID4gRm9yIHRo
ZSBtb21lbnQgSSBzZWUgYcKgc3RyYW5nZSBvZmZzZXQgZm9yIG1tYXAgY2FsbCBvZgo+PiA+ID4g
L2Rldi9kcm0vY2FyZDAKPj4gPiA+ID4gaW4gdGhlIHN0cmFjZSBsb2cg4oCUwqAweDEwMDAwMDAw
MC4gSXMgdGhhdCBub3JtYWw/Cj4+ID4gPiA+IEFueSBkaXJlY3Rpb24gb2Ygd2hpY2jCoHRvIGRp
ZyB3aWxsIGJlIHZlcnkgaGVscGZ1bC4KPj4gPiA+ID4gQ29uZmlndXJhdGlvbiBkZXRhaWxzOgo+
PiA+ID4gPiBYZW4gNC4xMi4xIERvbTA6IExpbnV4IDQuMjAuMTctZ2VudG9vICMxMyBTTVAgU2F0
IERlYyAyOAo+PiA+ID4gMTE6MTI6MjQgTVNLCj4+ID4gPiA+IDIwMTkgeDg2XzY0IEludGVsKFIp
IENlbGVyb24oUikgQ1BVIE4zMDUwIEAgMS42MEdIeiBHZW51aW5lSW50ZWwKPj4gPiA+IEdOVS9M
aW51eAo+PiA+ID4gPiBEb21VOiBMaW51eCA0LjIwLjE3LWdlbnRvbwo+PiA+ID4gPiBsYXN0IHhl
bi10cm9vcHMvbGlieGVuYmUgYW5kIHhlbi10cm9vcHMvZGlzcGxfYmUKPj4gPiA+ID4gTG9ncyAo
ZG1lc2csIHhsIGRtZXNnLCBkaXNwbF9iZSwgc3RyYWNlIGxvZyBvZiBkaXNwbF9iZSksIGEKPj4g
PiA+IGJhY2t0cmFjZQo+PiA+ID4gPiBvZiBnZGIgYW5kIGtlcm5lbCBjb25maWdzIGFyZSBhdHRh
Y2hlZC4KPj4gPiA+ID4gVGhhbmtzIGluIGFkdmFuY2UuCj4+ID4gPiBDb3VsZCB5b3UgcGxlYXNl
IHRyeSBEb20wIGtlcm5lbCBXSVRIT1VUIHRoZSBvcHRpb25zIGJlbG93Ogo+PiA+ID4gQ09ORklH
X1hFTl9HTlRERVZfRE1BQlVGPXkKPj4gPiA+IENPTkZJR19YRU5fR1JBTlRfRE1BX0FMTE9DPXkK
Pj4gPiA+Cj4+ID4gPiBUaGVuLCBqdXN0IHRvIG1ha2Ugc3VyZSwgZGlkIHlvdSBidWlsZCBkaXNw
bF9iZSB3aXRob3V0IHplcm8tY29weQo+PiA+ID4gc3VwcG9ydD8KPj4gPiA+Cj4+ID4gPiA+IE9u
IDEvOC8yMCA1OjM4IFBNLCBTYW50dWNjbyB3cm90ZToKPj4gPiA+ID4gPiBUaGFuayB5b3UgdmVy
eSBtdWNoIGZvciBhbGwgeW91ciBhbnN3ZXJzLgo+PiA+ID4gPiA+Cj4+ID4gPiA+ID4g0KHRgNC1
0LTQsCwgOCDRj9C90LLQsNGA0Y8gMjAyMCwgMTA6NTQgKzAzOjAwINC+0YIgT2xla3NhbmRyIEFu
ZHJ1c2hjaGVua28KPj4gPiA+ID4gPiA8IG9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29t
Cj4+IDwvY29tcG9zZT9Ubz1vbGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbT4KPj4gPiA8
L2NvbXBvc2U/VG89b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20+Cj4+ID4gPiA+ID4g
PC9jb21wb3NlP1RvPW9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPj46Cj4+ID4gPiA+
ID4gT24gMS82LzIwIDEwOjM4IEFNLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOgo+PiA+ID4gPiA+ID4g
T24gMDYuMDEuMjAgMDg6NTYsIFNhbnR1Y2NvIHdyb3RlOgo+PiA+ID4gPiA+ID4+IEhlbGxvLAo+
PiA+ID4gPiA+ID4+Cj4+ID4gPiA+ID4gPj4gSeKAmW0gdHJ5aW5nIHRvIHVzZSB2ZGlzcGwgaW50
ZXJmYWNlIGZyb20gUFYgT1MsIGl0IGRvZXNu4oCZdAo+PiA+IHdvcmsuCj4+ID4gPiA+ID4gPj4g
Q29uZmlndXJhdGlvbiBkZXRhaWxzOgo+PiA+ID4gPiA+ID4+IMKgwqDCoMKgIFhlbiA0LjEyLjEK
Pj4gPiA+ID4gPiA+PiDCoMKgwqDCoCBEb20wOiBMaW51eCA0LjIwLjE3LWdlbnRvbyAjMTMgU01Q
IFNhdCBEZWMgMjgKPj4gPiAxMToxMjoyNCBNU0sKPj4gPiA+ID4gPiAyMDE5Cj4+ID4gPiA+ID4g
Pj4geDg2XzY0IEludGVsKFIpIENlbGVyb24oUikgQ1BVIE4zMDUwIEAgMS42MEdIeiBHZW51aW5l
SW50ZWwKPj4gPiA+ID4gPiBHTlUvTGludXgKPj4gPiA+ID4gPiA+PiDCoMKgwqDCoCBEb21VOiB4
ODbCoFBsYW45LCBQVgo+PiA+ID4gPiA+ID4+IGRpc3BsX2JlIGFzIGEgYmFja2VuZCBmb3IgdmRp
c3BsIGFuZCB2a2IKPj4gPiA+ID4gPiA+Pgo+PiA+ID4gPiA+ID4+IHdoZW4gVk0gc3RhcnRzLCBk
aXNwbF9iZSByZXBvcnRzIGFib3V0IGFuIGVycm9yOgo+PiA+ID4gPiA+ID4+IGdudHRhYjogZXJy
b3I6IGlvY3RsIERNQUJVRl9FWFBfRlJPTV9SRUZTIGZhaWxlZDogSW52YWxpZAo+PiA+ID4gYXJn
dW1lbnQKPj4gPiA+ID4gPiA+PiAoZGlzcGxfYmUubG9nOjIyMSkKPj4gPiA+ID4gPiA+Pgo+PiA+
ID4gPiA+ID4+IHJlbGF0ZWTCoERvbTAgb3V0cHV0IGlzOgo+PiA+ID4gPiA+ID4+IFsgMTkxLjU3
OTI3OF0gQ2Fubm90IHByb3ZpZGUgZG1hLWJ1ZjogdXNlX3B0ZW1vZGUgMQo+PiA+ID4gPiA+ID4+
IChkbWVzZy5jcmVhdGUubG9nOjEyMykKPj4gPiA+ID4gPiA+Cj4+ID4gPiA+ID4gPiBUaGlzIHNl
ZW1zIHRvIGJlIGEgbGltaXRhdGlvbiBvZiB0aGUgeGVuIGRtYS1idWYgZHJpdmVyLgo+PiA+IEl0
IHdhcwo+PiA+ID4gPiA+IHdyaXR0ZW4KPj4gPiA+ID4gPiA+IGZvciBiZWluZyB1c2VkIG9uIEFS
TSBpbml0aWFsbHkgd2hlcmUgUFYgaXMgbm90IGF2YWlsYWJsZS4KPj4gPiA+ID4gPiBUaGlzIGlz
IHRydWUgYW5kIHdlIG5ldmVyIHRyaWVkL3RhcmdldGVkIFBWIGRvbWFpbnMgd2l0aCB0aGlzCj4+
ID4gPiA+ID4gaW1wbGVtZW50YXRpb24sCj4+ID4gPiA+ID4gc28gaWYgdGhlcmUgaXMgYSBuZWVk
IGZvciB0aGF0IHNvbWVvbmUgaGFzIHRvIHRha2UgYSBsb29rCj4+IG9uIHRoZQo+PiA+ID4gPiA+
IHByb3Blcgo+PiA+ID4gPiA+IGltcGxlbWVudGF0aW9uIGZvciBQVuKApgo+PiA+ID4gPiA+Cj4+
ID4gPiA+ID4gSGF2ZSBJIGdvdCB5b3VyIHJpZ2h0IGFuZCB0aGVyZSBpcyBub8KgdGhlIHByb3Bl
cgo+PiA+ID4gaW1wbGVtZW50YXRpb24gOi0pPwo+PiA+ID4gPiBUaGVyZSBpcyBubwo+PiA+ID4g
PiA+Cj4+ID4gPiA+ID4gPgo+PiA+ID4gPiA+ID4gQ0MtaW5nIE9sZWtzYW5kciBBbmRydXNoY2hl
bmtvIHdobyBpcyB0aGUgYXV0aG9yIG9mIHRoYXQKPj4gPiA+IGRyaXZlci4gSGUKPj4gPiA+ID4g
PiA+IHNob3VsZCBiZSBhYmxlIHRvIHRlbGwgdXMgd2hhdCB3b3VsZCBiZSBuZWVkZWQgdG8gZW5h
YmxlIFBWCj4+ID4gPiBkb20wLgo+PiA+ID4gPiA+ID4KPj4gPiA+ID4gPiA+IERlcGVuZGluZyBv
biB5b3VyIHVzZSBjYXNlIGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIHVzZSBQVkgKPj4gPiA+IGRv
bTAsIGJ1dAo+PiA+ID4gPiA+ID4gc3VwcG9ydCBmb3IgdGhpcyBtb2RlIGlzICJleHBlcmltZW50
YWwiIG9ubHkgYW5kIHNvbWUKPj4gZmVhdHVyZXMKPj4gPiA+ID4gPiBhcmUgbm90Cj4+ID4gPiA+
ID4gPiB5ZXQgd29ya2luZy4KPj4gPiA+ID4gPiA+Cj4+ID4gPiA+ID4gV2VsbCwgb25lIG9mIHRo
ZSB3b3JrYXJvdW5kcyBwb3NzaWJsZSBpcyB0byBkcm9wIHplcm8tY29weWluZwo+PiA+ID4gdXNl
LWNhc2UKPj4gPiA+ID4gPiAodGhpcyBpcyB3aHkgZGlzcGxheSBiYWNrZW5kIHRyaWVzIHRvIGNy
ZWF0ZSBkbXUtYnVmcyBmcm9tCj4+ID4gZ3JhbnRzCj4+ID4gPiA+ID4gcGFzc2VkCj4+ID4gPiA+
ID4gYnkgdGhlIGd1ZXN0IGRvbWFpbiBhbmQgZmFpbHMgYmVjYXVzZSBvZiAiQ2Fubm90IHByb3Zp
ZGUKPj4gPiBkbWEtYnVmOgo+PiA+ID4gPiA+IHVzZV9wdGVtb2RlIDEiKQo+PiA+ID4gPiA+IFNv
LCBpbiB0aGlzIGNhc2UgZGlzcGxheSBiYWNrZW5kIHdpbGwgZG8gbWVtb3J5IGNvcHlpbmcKPj4g
Zm9yIHRoZQo+PiA+ID4gPiA+IGluY29taW5nCj4+ID4gPiA+ID4gZnJhbWVzCj4+ID4gPiA+ID4g
YW5kIHdvbid0IHRvdWNoIERNQUJVRl9FWFBfRlJPTV9SRUZTIGlvY3RsLgo+PiA+ID4gPiA+IFRv
IGRvIHNvIGp1c3QgZGlzYWJsZSB6ZXJvLWNvcHlpbmcgd2hpbGUgYnVpbGRpbmcgdGhlCj4+ID4g
YmFja2VuZCBbMV0KPj4gPiA+ID4gPgo+PiA+ID4gPiA+IFRoYW5rcywgSSBoYXZlIGp1c3TCoHRy
aWVkwqB0aGUgd29ya2Fyb3VuZC4gVGhlIGJhY2tlbmQKPj4gaGFzwqBmYWlsZWQKPj4gPiA+ID4g
PiBpbsKgYW4gb3RoZXIgcGxhY2XCoG5vdCBjb3JyZXNwb25kaW5nIHdpdGggZG1hX2J1Zi4KPj4g
PiA+ID4gPiBBbnl3YXnCoGl0IGlzIGVub3VnaCB0byBjb250aW51ZcKgZGVidWdnaW5nwqDCoG15
Cj4+ID4gPiBmcm9udGVuZMKgaW1wbGVtZW50YXRpb24uCj4+ID4gPiA+ID4gRG8geW91wqBrbm93
IGhvdyBiaWcgaXMgcGVyZm9ybWFuY2UgcGVuYWx0eSBpbiBjb21wYXJpc29uIHdpdGgKPj4gPiA+
ID4gPiB0aGXCoHplcm8tY29weSB2YXJpYW50Pwo+PiA+ID4gPiBXZWxsLCBpdCBzb2xlbHkgZGVw
ZW5kcyBvbiB5b3VyIHNldHVwLCBzbyBJIGNhbm5vdCB0ZWxsIHdoYXQKPj4gPiA+ID4gd291bGQg
dGhlIG51bWJlcnMgYmUgaW4geW91ciBjYXNlLiBDb21wYXJpbmcgdG8gd2hhdCBJIGhhdmUKPj4g
PiBkb2Vzbid0Cj4+ID4gPiA+IG1ha2UgYW55IHNlbnNlIHRvIG1lOiBvbmUgc2hvdWxkIGNvbXBh
cmUgYXBwbGVzIHRvIGFwcGxlcwo+PiA+ID4gPiA+IERvZXMgaXQgbWFrZSBhwqBzZW5zZSBpZiBJ
IG1ha2UgYcKgZGVkaWNhdGVkIEhWTSBkb21haW4gd2l0aAo+PiA+ID4gbGludXggb25seQo+PiA+
ID4gPiA+IGZvciB0aGUgcHVycG9zZSBvZsKgdmRpc3BsIGFuZCB2a2JkIGJhY2tlbmRzP8KgSXMg
dGhlcmUgYQo+PiA+IGhvcGXCoHRoaXMKPj4gPiA+ID4gPiBhcHByb2FjaCB3aWxsIHdvcms/Cj4+
ID4gPiA+IFlvdSBjYW4gdHJ5IGlmIHRoaXMgYXBwcm9hY2ggZml0cyB5b3VyIGRlc2lnbiBhbmQg
cmVxdWlyZW1lbnRzCj4+ID4gPiA+ID4KPj4gPiA+ID4gPiA+Cj4+ID4gPiA+ID4gPiBKdWVyZ2Vu
Cj4+ID4gPiA+ID4gPgo+PiA+ID4gPiA+IFsxXQo+PiA+ID4gPiA+Cj4+ID4gPiA+Cj4+ID4gPgo+
PiA+Cj4+ICBodHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9iZS9ibG9iL21hc3Rl
ci9DTWFrZUxpc3RzLnR4dCNMMTIKPj4gPCBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0
cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0
cy50eHQqTDEyX187SXchIUdGXzI5ZGJjUUlVQlBBIW1obFFBUFNfT3p5NTd4YV8wT1I2NnFjMW1q
bFNFejdsajNNa1dDeURERjkxQkdhN0o3LUJPWVdZY2Rrc3Bsb2NadnhJWk1pcldnJCA+Cj4+ID4K
Pj4gPCBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hlbi10
cm9vcHMvZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdGXzI5
ZGJjUUlVQlBBIWtaMUpRRlJTMnBYal9JdVhCaHZZaG1QOVFfc3ZjTHlqQ1hLOTQ2NVVMR0I0TWVp
WVBSejJjRjdsZXBIZ2dyOVV4UFU5ek9CRVV3JCA+Cj4+ID4gPgo+PiA+Cj4+IDwgaHR0cHM6Ly91
cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJvb3BzL2Rpc3BsX2Jl
L2Jsb2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0KkwxMl9fO0l3ISFHRl8yOWRiY1FJVUJQQSFrdkRn
eTNYMEl1U1FrN0QyRGRzR3RzanR5R3JvWWJOS09yUEc5NU9weW9Ba3VCVmJGU216b3p3Zm9yMDVq
a1JsMGl0YTBGdW1CdyQgPgo+PiA+ID4gPgo+PiA+ID4KPj4gPgo+PiA8IGh0dHBzOi8vdXJsZGVm
ZW5zZS5jb20vdjMvX19odHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9iZS9ibG9i
L21hc3Rlci9DTWFrZUxpc3RzLnR4dCpMMTJfXztJdyEhR0ZfMjlkYmNRSVVCUEEhZ2k4MW9aWk52
V2FGV1VWbmFabHVBX21OQkFJdExNZDRSWm1uYy1NX0ZtbHBEb2pxZVFRblM3YVhTTmxibzgwcmU5
dU9sMndxRkEkID4KPj4gPiA+ID4gPgo+PiA+ID4gPgo+PiA+ID4KPj4gPgo+PiA8IGh0dHBzOi8v
dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9i
ZS9ibG9iL21hc3Rlci9DTWFrZUxpc3RzLnR4dCpMMTJfXztJdyEhR0ZfMjlkYmNRSVVCUEEhbXoz
Z24xd1FNWDJEWGVOdUFWLTFfZEk3bnhGWVlaT2dkUGlKTlNGTWVzQ3o5bEF6T0tsd1ZQbGRkYnhi
Y0xtVU80NE5PeTBURkEkID4KPj4gPiA+ID4gPgo+PiA+ID4gPiA+IEJlc3QgcmVnYXJkcywKPj4g
PiA+ID4gPiDCoCBBbGV4YW5kZXIgU3ljaGV2Cj4+ID4gPiA+Cj4+ID4gPgo+PiA+ID4KPj4gPgo+
PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KPj4gPgo+PiBbMV0KPj4gIGh0dHBzOi8vZWxpeGlyLmJvb3RsaW4u
Y29tL2xpbnV4L3Y1LjUvc291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jI0wzMDAKPj4gPCBodHRw
czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20vbGludXgv
djUuNS9zb3VyY2UvZHJpdmVycy94ZW4vZ250ZGV2LmMqTDMwMF9fO0l3ISFHRl8yOWRiY1FJVUJQ
QSFtaGxRQVBTX096eTU3eGFfME9SNjZxYzFtamxTRXo3bGozTWtXQ3lEREY5MUJHYTdKNy1CT1lX
WWNka3NwbG9jWnZ6bjZmbGs2USQgPgo+PiBbMl0KPj4gIGh0dHBzOi8vZWxpeGlyLmJvb3RsaW4u
Y29tL2xpbnV4L3Y1LjUvc291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jI0wzMTkKPj4gPCBodHRw
czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20vbGludXgv
djUuNS9zb3VyY2UvZHJpdmVycy94ZW4vZ250ZGV2LmMqTDMxOV9fO0l3ISFHRl8yOWRiY1FJVUJQ
QSFtaGxRQVBTX096eTU3eGFfME9SNjZxYzFtamxTRXo3bGozTWtXQ3lEREY5MUJHYTdKNy1CT1lX
WWNka3NwbG9jWnZ3ak9mWUp4ZyQgPgo+Pgo+Cj5bMV0gIGh0dHBzOi8vZ2l0aHViLmNvbS94ZW4t
dHJvb3BzL2Rpc3BsX2JlCsKg

----ALT--2cAeB49257DbbC9313Db7a25C7c5C5eE1587387344
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

CjxIVE1MPjxCT0RZPjxkaXY+U3VyZS48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxkaXY+SSB3aWxs
IG1ha2UgaXQgYSBiaXQgbGF0ZXIsIHdoZW4gSSBoYXZlIHRoZSZuYnNwO21vcmUgc3RhYmxlIHJl
c3VsdC48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2PjxkaXY+
QWxleGFuZGVyPC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXItbGVmdDoxcHggc29saWQgIzA4NTdBNjsgbWFyZ2luOjEwcHg7IHBh
ZGRpbmc6MCAwIDAgMTBweDsiPtCf0L7QvdC10LTQtdC70YzQvdC40LosIDIwINCw0L/RgNC10LvR
jyAyMDIwLCA4OjU5ICswMzowMCDQvtGCIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvICZsdDtvbGVr
c2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbSZndDs6PGJyPiZuYnNwOzxkaXYgaWQ9IiI+PGRp
diBjbGFzcz0ianMtaGVscGVyIGpzLXJlYWRtc2ctbXNnIj48c3R5bGUgdHlwZT0idGV4dC9jc3Mi
Pjwvc3R5bGU+PGRpdj48ZGl2IGlkPSJzdHlsZV8xNTg3MzYyMzQ4MTM0MzEwMjU2Nl9CT0RZIj5I
aSw8YnI+PGJyPk9uIDQvMTkvMjAgMTQ6MjYsIFNhbnR1Y2NvIHdyb3RlOjxicj4mZ3Q7IEhlbGxv
LDxicj4mZ3Q7IEkgaGF2ZSBmb3VuZCBhIHNvdXJjZSBvZiB0aGUgcHJvYmxlbS48YnI+Jmd0OyBJ
biBkaXNwbF9iZSwmbmJzcDsgQmFzZUR1bXAgY29waWVzIHRvIHRoZSBkcm0gYnVmZmVyIHdpdGgg
YSZuYnNwO3NpemUgZnJvbTxicj4mZ3Q7IGk5MTUmbmJzcDtkcm0gZHJpdmVyLCBidXQgdGhpcyBz
aXplIGEgYml0IG1vcmUgdGhhbiBhJm5ic3A7c2l6ZSBvZiZuYnNwO215IGZyb250ZW5kPGJyPiZn
dDsgZGlzcGxheSBidWZmZXIuIEkgaGF2ZSBtYWRlIGEgcXVpY2sgYW5kIGRpcnR5Jm5ic3A7Zml4
LCZuYnNwO2EgY29weSZuYnNwO2EgbGluZSBvZiBteTxicj4mZ3Q7IGRpc3BsYXkgYnVmZmVyIHRv
IGEgbWlkZGxlIG9mIGEmbmJzcDtsaW5lIG9mJm5ic3A7dGhlJm5ic3A7ZHJtIGRpc3BsYXkgYnVm
ZmVyLiBQYXRjaDxicj4mZ3Q7IGlzIGF0dGFjaGVkLjxicj48YnI+VGhhbmsgeW91IGZvciB0aGUg
cGF0Y2ggYW5kIHlvdXIgZWZmb3J0cyB0byBmaXggdGhlIGlzc3VlLjxicj48YnI+Q291bGQgeW91
IHBsZWFzZSBtYWtlIGEgcHVsbCByZXF1ZXN0IHRvIFsxXSwgc28gd2UgY2FuIGNvbnRpbnVlIHRo
ZXJlPzxicj48YnI+VGhhbmsgeW91IGluIGFkdmFuY2UsPGJyPjxicj5PbGVrc2FuZHI8YnI+PGJy
PiZndDsgQmVzdCByZWdhcmRzLDxicj4mZ3Q7IEFsZXhhbmRlcjxicj4mZ3Q7PGJyPiZndDsg0KfQ
tdGC0LLQtdGA0LMsIDYg0YTQtdCy0YDQsNC70Y8gMjAyMCwgMTE6MjAgKzAzOjAwINC+0YIgT2xl
a3NhbmRyIEFuZHJ1c2hjaGVua288YnI+Jmd0OyAmbHQ7PGEgaHJlZj0iL2NvbXBvc2U/VG89b2xl
a3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20iPm9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVw
YW0uY29tPC9hPiZndDs6PGJyPiZndDsgT24gMi81LzIwIDg6NTkgUE0sIFNhbnR1Y2NvIHdyb3Rl
Ojxicj4mZ3Q7ICZndDsgSGVsbG8sPGJyPiZndDsgJmd0OyBPaywgSSZuYnNwOyBjb21tZW50ZWQg
b3V0IHRoZSBtZW1jcHkgY2FsbCBhbmQgcnVuJm5ic3A7dGhlIHRlc3QuPGJyPiZndDsgJmd0OyBk
aXNwbF9iZSBoYXNu4oCZdCBjcmFjaGVkLCBJIGhhdmUmbmJzcDtzZWVuIEZMSVAgZXZlbnRzIGlu
IHRoZSBsb2cuPGJyPiZndDsgJmd0OyBCdXQgdGhlcmUgaGFzbuKAmXQgYmVlbiZuYnNwO3RoZSZu
YnNwO2JsYWNrIHNjcmVlbiwganVzdCBhJm5ic3A7YmxpbmsgZWZmZWN0IGV2ZXJ5PGJyPiZndDsg
Jmd0OyBjb3VwbGUgb2Ygc2Vjb25kcy48YnI+Jmd0OyAmZ3Q7IExvZ3MgYXJlIGF0dGFjaGVkLjxi
cj4mZ3Q7IE9rLCBzbyBJIGJlbGlldmUgdGhhdCBmcm9udGVuZCAtIGJhY2tlbmQgKGRpc3BsX2Jl
KSBjb21tdW5pY2F0aW9uPGJyPiZndDsgaXMgb2s8YnI+Jmd0OyBhbmQgdGhlcmUgaXMgbm90aGlu
ZyB0byBkbyB0aGVyZS48YnI+Jmd0Ozxicj4mZ3Q7IE5leHQsIEkgd291bGQgc3RhcnQgZGVidWdn
aW5nIHRoZSBmb2xsb3dpbmcgaW4gWGVuOjxicj4mZ3Q7IChYRU4pIG1tLmM6MjIyMzpkMnYwIEJh
ZCBMMSBmbGFncyA4MDxicj4mZ3Q7IGFuZCBoYXZlIGEgbG9vayBhdCBbMV0uIFByb2JhYmx5LCBz
b21lb25lIG9uIFhlbiB4ODYgc2lkZSBjYW4gdGVsbDxicj4mZ3Q7IGlmIHRoaXMgY291bGQgYmUg
cmVsYXRlZCB0byB0aGUgZmxhZ3MgYXQgWzJdLjxicj4mZ3Q7PGJyPiZndDsgJmd0OyBCZXN0IHJl
Z2FyZHMsPGJyPiZndDsgJmd0OyBBbGV4YW5kZXI8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyDQ
odGA0LXQtNCwLCA1INGE0LXQstGA0LDQu9GPIDIwMjAsIDk6MzEgKzAzOjAwINC+0YIgT2xla3Nh
bmRyIEFuZHJ1c2hjaGVua288YnI+Jmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSIvY29tcG9zZT9Ubz1v
bGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbSI+b2xla3NhbmRyX2FuZHJ1c2hjaGVua29A
ZXBhbS5jb208L2E+PGJyPiZndDsgJmx0Oy9jb21wb3NlP1RvPW9sZWtzYW5kcl9hbmRydXNoY2hl
bmtvQGVwYW0uY29tJmd0OyZndDs6PGJyPiZndDsgJmd0OyBPbiAyLzQvMjAgMTA6MjggQU0sIFNh
bnR1Y2NvIHdyb3RlOjxicj4mZ3Q7ICZndDsgJmd0OyBIZWxsbyw8YnI+Jmd0OyAmZ3Q7ICZndDsg
ZGlzcGxfYmUgd2FzIGNvbXBpbGVkJm5ic3A7d2l0aG91dCB6ZXJvLWNvcHkgc3VwcG9ydCBlYXJs
eS48YnI+Jmd0OyAmZ3Q7ICZndDsgSSBoYXZlIHRyaWVkIHdpdGggdGhlJm5ic3A7cmVjb21waWxl
ZCBkb20wIGtlcm5lbCwgYSByZXN1bHQgaXMmbmJzcDt0aGU8YnI+Jmd0OyBzYW1lLjxicj4mZ3Q7
ICZndDsgJmd0OyBMb2dzIGFuZCBjb25maWdzICgrZGlzcGxfYmXigJlzJm5ic3A7Q01ha2VDYWNo
ZS50eHQmbmJzcDspIGFyZSBhdHRhY2hlZC48YnI+Jmd0OyAmZ3Q7IE9rLCB5ZXQgYW5vdGhlciB0
ZXN0IHRvIGxvY2FsaXplIHRoZSBwcm9ibGVtLjxicj4mZ3Q7ICZndDsgQ291bGQgeW91IHBsZWFz
ZSByZW1vdmUgbWVtY3B5IGZyb208YnI+Jmd0OyAmZ3Q7ICMxJm5ic3A7IDB4MDAwMDU1ZTVhMWYy
OGJlYyBpbiBEcm06OkR1bWJEcm06OmNvcHk8YnI+Jmd0OyAodGhpcz0weDdmOTMzODAwMGUwMCkg
YXQ8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgL2hvbWUvc2FudHVjY28vdG1wL3hlbi10cm9vcHMvZGlz
cGxfYmUvc3JjL2Rpc3BsYXlCYWNrZW5kL2RybS9EdW1iLmNwcDoxNDk8YnI+Jmd0OyAmZ3Q7IGFu
ZCBqdXN0IG1lbXNldCB0aGUgZGVzdGluYXRpb24gd2l0aCAwIG9yIHdoYXRldmVyLjxicj4mZ3Q7
ICZndDs8YnI+Jmd0OyAmZ3Q7IEkgZXhwZWN0IHRoYXQgc3lzdGVtIHdvbid0IGNyYXNoLCBub3Ro
aW5nIHdpbGwgYmUgc2hvd24gKGJsYWNrPGJyPiZndDsgJmd0OyBzY3JlZW4pLCBidXQ8YnI+Jmd0
OyAmZ3Q7IGRpc3BsX2JlIHdpbGwgc2hvdyBwYWdlIGZsaXAgZXZlbnRzIGluIGl0cyBsb2dzLjxi
cj4mZ3Q7ICZndDsgJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPiZndDsgJmd0OyAmZ3Q7IEFsZXhhbmRl
cjxicj4mZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyDQn9C+0L3QtdC00LXQu9GM0L3Q
uNC6LCAzINGE0LXQstGA0LDQu9GPIDIwMjAsIDEwOjM2ICswMzowMCDQvtGCIE9sZWtzYW5kcjxi
cj4mZ3Q7ICZndDsgJmd0OyBBbmRydXNoY2hlbmtvICZsdDs8YSBocmVmPSIvY29tcG9zZT9Ubz1v
bGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbSI+b2xla3NhbmRyX2FuZHJ1c2hjaGVua29A
ZXBhbS5jb208L2E+PGJyPiZndDsgJmx0Oy9jb21wb3NlP1RvPW9sZWtzYW5kcl9hbmRydXNoY2hl
bmtvQGVwYW0uY29tJmd0Ozxicj4mZ3Q7ICZndDsgJmx0Oy9jb21wb3NlP1RvPW9sZWtzYW5kcl9h
bmRydXNoY2hlbmtvQGVwYW0uY29tJmd0OyZndDs6PGJyPiZndDsgJmd0OyAmZ3Q7PGJyPiZndDsg
Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7IE9uIDIvMS8yMCA0OjM5IFBNLCBTYW50dWNjbyB3
cm90ZTo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBIZWxsbyBhZ2Fpbiw8YnI+Jmd0OyAmZ3Q7ICZn
dDsgJmd0OyBJIGhhdmUgbm90IHlldCBtYWRlIHRvIHdvcmsgbXkgZHJtIGNsaWVudCwgc28gSSBo
YXZlIHRyaWVkPGJyPiZndDsgdG8gcnVuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgbGludXggbGlr
ZSBhIGRvbVUmbmJzcDsodG8gc2VlIGhvdyBpdCBzaG91bGQgd29yayksIGl0IGRvZXNu4oCZdDxi
cj4mZ3Q7IHdvcmsgdG9vPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg4oCUJm5ic3A7ZGlzcGxfYmUg
Y2F0Y2hlcyBTSUdTRUdWOjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7
ICZndDsgIzAgJm5ic3A7MHgwMDAwN2Y0YWZlZDFjMTYxIGluID8/ICgpIGZyb20gL2xpYjY0L2xp
YmMuc28uNjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICMxICZuYnNwOzB4MDAwMDU1NzIzYjljNWJl
YyBpbiBEcm06OkR1bWJEcm06OmNvcHk8YnI+Jmd0OyAmZ3Q7ICZndDsgKHRoaXM9MHg3ZjRhZGMw
MDBlMDApIGF0PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0
OyAmZ3Q7PGJyPiZndDsgL2hvbWUvc2FudHVjY28vdG1wL3hlbi10cm9vcHMvZGlzcGxfYmUvc3Jj
L2Rpc3BsYXlCYWNrZW5kL2RybS9EdW1iLmNwcDoxNDk8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAj
MiAmbmJzcDsweDAwMDA1NTcyM2I5YThmNTEgaW4gQnVmZmVyc1N0b3JhZ2U6OmdldEZyYW1lQnVm
ZmVyQW5kQ29weTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICh0aGlzPTB4N2Y0YWUwMDAxMGUwLCBm
YkNvb2tpZT0xODQ0NjYxMjY4MjI5NTA4MzI2NCkgYXQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0Ozxi
cj4mZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAvaG9tZS9zYW50dWNjby90bXAv
eGVuLXRyb29wcy9kaXNwbF9iZS9zcmMvZGlzcGxheUJhY2tlbmQvQnVmZmVyc1N0b3JhZ2UuY3Bw
OjE2NTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEl0IHRyaWVzIHRvIGNvcHkgdG8gbUJ1ZmZlciB3
aXRoIG5vbi1hY2Nlc3NpYmxlIGFkZHJlc3MuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgRm9yIHRo
ZSBtb21lbnQgSSBzZWUgYSZuYnNwO3N0cmFuZ2Ugb2Zmc2V0IGZvciBtbWFwIGNhbGwgb2Y8YnI+
Jmd0OyAmZ3Q7ICZndDsgL2Rldi9kcm0vY2FyZDA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpbiB0
aGUgc3RyYWNlIGxvZyDigJQmbmJzcDsweDEwMDAwMDAwMC4gSXMgdGhhdCBub3JtYWw/PGJyPiZn
dDsgJmd0OyAmZ3Q7ICZndDsgQW55IGRpcmVjdGlvbiBvZiB3aGljaCZuYnNwO3RvIGRpZyB3aWxs
IGJlIHZlcnkgaGVscGZ1bC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBDb25maWd1cmF0aW9uIGRl
dGFpbHM6PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgWGVuIDQuMTIuMSBEb20wOiBMaW51eCA0LjIw
LjE3LWdlbnRvbyAjMTMgU01QIFNhdCBEZWMgMjg8YnI+Jmd0OyAmZ3Q7ICZndDsgMTE6MTI6MjQg
TVNLPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgMjAxOSB4ODZfNjQgSW50ZWwoUikgQ2VsZXJvbihS
KSBDUFUgTjMwNTAgQCAxLjYwR0h6IEdlbnVpbmVJbnRlbDxicj4mZ3Q7ICZndDsgJmd0OyBHTlUv
TGludXg8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBEb21VOiBMaW51eCA0LjIwLjE3LWdlbnRvbzxi
cj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxhc3QgeGVuLXRyb29wcy9saWJ4ZW5iZSBhbmQgeGVuLXRy
b29wcy9kaXNwbF9iZTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IExvZ3MgKGRtZXNnLCB4bCBkbWVz
ZywgZGlzcGxfYmUsIHN0cmFjZSBsb2cgb2YgZGlzcGxfYmUpLCBhPGJyPiZndDsgJmd0OyAmZ3Q7
IGJhY2t0cmFjZTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9mIGdkYiBhbmQga2VybmVsIGNvbmZp
Z3MgYXJlIGF0dGFjaGVkLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoYW5rcyBpbiBhZHZhbmNl
Ljxicj4mZ3Q7ICZndDsgJmd0OyBDb3VsZCB5b3UgcGxlYXNlIHRyeSBEb20wIGtlcm5lbCBXSVRI
T1VUIHRoZSBvcHRpb25zIGJlbG93Ojxicj4mZ3Q7ICZndDsgJmd0OyBDT05GSUdfWEVOX0dOVERF
Vl9ETUFCVUY9eTxicj4mZ3Q7ICZndDsgJmd0OyBDT05GSUdfWEVOX0dSQU5UX0RNQV9BTExPQz15
PGJyPiZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7IFRoZW4sIGp1c3QgdG8gbWFrZSBz
dXJlLCBkaWQgeW91IGJ1aWxkIGRpc3BsX2JlIHdpdGhvdXQgemVyby1jb3B5PGJyPiZndDsgJmd0
OyAmZ3Q7IHN1cHBvcnQ/PGJyPiZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg
T24gMS84LzIwIDU6MzggUE0sIFNhbnR1Y2NvIHdyb3RlOjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZndDsgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgYWxsIHlvdXIgYW5zd2Vycy48YnI+Jmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyDQodGA0LXQtNCw
LCA4INGP0L3QstCw0YDRjyAyMDIwLCAxMDo1NCArMDM6MDAg0L7RgiBPbGVrc2FuZHIgQW5kcnVz
aGNoZW5rbzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Ii9jb21wb3Nl
P1RvPW9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tIj5vbGVrc2FuZHJfYW5kcnVzaGNo
ZW5rb0BlcGFtLmNvbTwvYT48YnI+Jmd0OyAmbHQ7L2NvbXBvc2U/VG89b2xla3NhbmRyX2FuZHJ1
c2hjaGVua29AZXBhbS5jb20mZ3Q7PGJyPiZndDsgJmd0OyAmbHQ7L2NvbXBvc2U/VG89b2xla3Nh
bmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20mZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmbHQ7L2NvbXBvc2U/VG89b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20mZ3Q7Jmd0
Ozo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9uIDEvNi8yMCAxMDozOCBBTSwgSsO8cmdl
biBHcm/DnyB3cm90ZTo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT24gMDYuMDEu
MjAgMDg6NTYsIFNhbnR1Y2NvIHdyb3RlOjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyZndDsgSGVsbG8sPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgSeKAmW0gdHJ5aW5nIHRvIHVzZSB2ZGlzcGwg
aW50ZXJmYWNlIGZyb20gUFYgT1MsIGl0IGRvZXNu4oCZdDxicj4mZ3Q7ICZndDsgd29yay48YnI+
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IENvbmZpZ3VyYXRpb24gZGV0YWlsczo8
YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBYZW4gNC4xMi4xPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgRG9tMDogTGludXggNC4yMC4xNy1nZW50b28gIzEzIFNNUCBT
YXQgRGVjIDI4PGJyPiZndDsgJmd0OyAxMToxMjoyNCBNU0s8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7IDIwMTk8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IHg4Nl82NCBJ
bnRlbChSKSBDZWxlcm9uKFIpIENQVSBOMzA1MCBAIDEuNjBHSHogR2VudWluZUludGVsPGJyPiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBHTlUvTGludXg8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEb21VOiB4ODYmbmJzcDtQbGFu
OSwgUFY8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IGRpc3BsX2JlIGFzIGEg
YmFja2VuZCBmb3IgdmRpc3BsIGFuZCB2a2I8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyB3aGVuIFZNIHN0YXJ0
cywgZGlzcGxfYmUgcmVwb3J0cyBhYm91dCBhbiBlcnJvcjo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsmZ3Q7IGdudHRhYjogZXJyb3I6IGlvY3RsIERNQUJVRl9FWFBfRlJPTV9SRUZT
IGZhaWxlZDogSW52YWxpZDxicj4mZ3Q7ICZndDsgJmd0OyBhcmd1bWVudDxicj4mZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgKGRpc3BsX2JlLmxvZzoyMjEpPGJyPiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZn
dDsgcmVsYXRlZCZuYnNwO0RvbTAgb3V0cHV0IGlzOjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyZndDsgWyAxOTEuNTc5Mjc4XSBDYW5ub3QgcHJvdmlkZSBkbWEtYnVmOiB1c2VfcHRl
bW9kZSAxPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAoZG1lc2cuY3JlYXRl
LmxvZzoxMjMpPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7IFRoaXMgc2VlbXMgdG8gYmUgYSBsaW1pdGF0aW9uIG9mIHRoZSB4
ZW4gZG1hLWJ1ZiBkcml2ZXIuPGJyPiZndDsgJmd0OyBJdCB3YXM8YnI+Jmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IHdyaXR0ZW48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZm9yIGJl
aW5nIHVzZWQgb24gQVJNIGluaXRpYWxseSB3aGVyZSBQViBpcyBub3QgYXZhaWxhYmxlLjxicj4m
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhpcyBpcyB0cnVlIGFuZCB3ZSBuZXZlciB0cmllZC90
YXJnZXRlZCBQViBkb21haW5zIHdpdGggdGhpczxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
aW1wbGVtZW50YXRpb24sPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBzbyBpZiB0aGVyZSBp
cyBhIG5lZWQgZm9yIHRoYXQgc29tZW9uZSBoYXMgdG8gdGFrZSBhIGxvb2s8YnI+Jmd0OyBvbiB0
aGU8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHByb3Blcjxicj4mZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgaW1wbGVtZW50YXRpb24gZm9yIFBW4oCmPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSGF2ZSBJIGdvdCB5b3VyIHJpZ2h0IGFu
ZCB0aGVyZSBpcyBubyZuYnNwO3RoZSBwcm9wZXI8YnI+Jmd0OyAmZ3Q7ICZndDsgaW1wbGVtZW50
YXRpb24gOi0pPzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIG5vPGJyPiZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBDQy1pbmcgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28g
d2hvIGlzIHRoZSBhdXRob3Igb2YgdGhhdDxicj4mZ3Q7ICZndDsgJmd0OyBkcml2ZXIuIEhlPGJy
PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNob3VsZCBiZSBhYmxlIHRvIHRlbGwgdXMg
d2hhdCB3b3VsZCBiZSBuZWVkZWQgdG8gZW5hYmxlIFBWPGJyPiZndDsgJmd0OyAmZ3Q7IGRvbTAu
PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IERlcGVuZGluZyBvbiB5b3VyIHVzZSBjYXNlIGl0IG1pZ2h0IGJlIHBvc3NpYmxl
IHRvIHVzZSBQVkg8YnI+Jmd0OyAmZ3Q7ICZndDsgZG9tMCwgYnV0PGJyPiZndDsgJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7IHN1cHBvcnQgZm9yIHRoaXMgbW9kZSBpcyAiZXhwZXJpbWVudGFsIiBv
bmx5IGFuZCBzb21lPGJyPiZndDsgZmVhdHVyZXM8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
IGFyZSBub3Q8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgeWV0IHdvcmtpbmcuPGJy
PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyBXZWxsLCBvbmUgb2YgdGhlIHdvcmthcm91bmRzIHBvc3NpYmxlIGlzIHRvIGRyb3AgemVyby1j
b3B5aW5nPGJyPiZndDsgJmd0OyAmZ3Q7IHVzZS1jYXNlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAodGhpcyBpcyB3aHkgZGlzcGxheSBiYWNrZW5kIHRyaWVzIHRvIGNyZWF0ZSBkbXUtYnVm
cyBmcm9tPGJyPiZndDsgJmd0OyBncmFudHM8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBh
c3NlZDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYnkgdGhlIGd1ZXN0IGRvbWFpbiBhbmQg
ZmFpbHMgYmVjYXVzZSBvZiAiQ2Fubm90IHByb3ZpZGU8YnI+Jmd0OyAmZ3Q7IGRtYS1idWY6PGJy
PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB1c2VfcHRlbW9kZSAxIik8YnI+Jmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IFNvLCBpbiB0aGlzIGNhc2UgZGlzcGxheSBiYWNrZW5kIHdpbGwgZG8gbWVt
b3J5IGNvcHlpbmc8YnI+Jmd0OyBmb3IgdGhlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBp
bmNvbWluZzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZnJhbWVzPGJyPiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyBhbmQgd29uJ3QgdG91Y2ggRE1BQlVGX0VYUF9GUk9NX1JFRlMgaW9jdGwu
PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUbyBkbyBzbyBqdXN0IGRpc2FibGUgemVyby1j
b3B5aW5nIHdoaWxlIGJ1aWxkaW5nIHRoZTxicj4mZ3Q7ICZndDsgYmFja2VuZCBbMV08YnI+Jmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGFua3Ms
IEkgaGF2ZSBqdXN0Jm5ic3A7dHJpZWQmbmJzcDt0aGUgd29ya2Fyb3VuZC4gVGhlIGJhY2tlbmQ8
YnI+Jmd0OyBoYXMmbmJzcDtmYWlsZWQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluJm5i
c3A7YW4gb3RoZXIgcGxhY2UmbmJzcDtub3QgY29ycmVzcG9uZGluZyB3aXRoIGRtYV9idWYuPGJy
PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBBbnl3YXkmbmJzcDtpdCBpcyBlbm91Z2ggdG8gY29u
dGludWUmbmJzcDtkZWJ1Z2dpbmcmbmJzcDsmbmJzcDtteTxicj4mZ3Q7ICZndDsgJmd0OyBmcm9u
dGVuZCZuYnNwO2ltcGxlbWVudGF0aW9uLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgRG8g
eW91Jm5ic3A7a25vdyBob3cgYmlnIGlzIHBlcmZvcm1hbmNlIHBlbmFsdHkgaW4gY29tcGFyaXNv
biB3aXRoPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUmbmJzcDt6ZXJvLWNvcHkgdmFy
aWFudD88YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBXZWxsLCBpdCBzb2xlbHkgZGVwZW5kcyBvbiB5
b3VyIHNldHVwLCBzbyBJIGNhbm5vdCB0ZWxsIHdoYXQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB3
b3VsZCB0aGUgbnVtYmVycyBiZSBpbiB5b3VyIGNhc2UuIENvbXBhcmluZyB0byB3aGF0IEkgaGF2
ZTxicj4mZ3Q7ICZndDsgZG9lc24ndDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1ha2UgYW55IHNl
bnNlIHRvIG1lOiBvbmUgc2hvdWxkIGNvbXBhcmUgYXBwbGVzIHRvIGFwcGxlczxicj4mZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZndDsgRG9lcyBpdCBtYWtlIGEmbmJzcDtzZW5zZSBpZiBJIG1ha2UgYSZu
YnNwO2RlZGljYXRlZCBIVk0gZG9tYWluIHdpdGg8YnI+Jmd0OyAmZ3Q7ICZndDsgbGludXggb25s
eTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZm9yIHRoZSBwdXJwb3NlIG9mJm5ic3A7dmRp
c3BsIGFuZCB2a2JkIGJhY2tlbmRzPyZuYnNwO0lzIHRoZXJlIGE8YnI+Jmd0OyAmZ3Q7IGhvcGUm
bmJzcDt0aGlzPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBhcHByb2FjaCB3aWxsIHdvcms/
PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgWW91IGNhbiB0cnkgaWYgdGhpcyBhcHByb2FjaCBmaXRz
IHlvdXIgZGVzaWduIGFuZCByZXF1aXJlbWVudHM8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IEp1ZXJnZW48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+Jmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFsxXTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+
Jmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0
OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9iZS9ibG9iL21h
c3Rlci9DTWFrZUxpc3RzLnR4dCNMMTIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5j
b20veGVuLXRyb29wcy9kaXNwbF9iZS9ibG9iL21hc3Rlci9DTWFrZUxpc3RzLnR4dCNMMTI8L2E+
PGJyPiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov
L2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9iZS9ibG9iL21hc3Rlci9DTWFrZUxpc3RzLnR4
dCpMMTJfXztJdyEhR0ZfMjlkYmNRSVVCUEEhbWhsUUFQU19Penk1N3hhXzBPUjY2cWMxbWpsU0V6
N2xqM01rV0N5RERGOTFCR2E3SjctQk9ZV1ljZGtzcGxvY1p2eElaTWlyV2ckIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZ2l0aHViLmNvbS94ZW4t
dHJvb3BzL2Rpc3BsX2JlL2Jsb2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0KkwxMl9fO0l3ISFHRl8y
OWRiY1FJVUJQQSFtaGxRQVBTX096eTU3eGFfME9SNjZxYzFtamxTRXo3bGozTWtXQ3lEREY5MUJH
YTdKNy1CT1lXWWNka3NwbG9jWnZ4SVpNaXJXZyQ8L2E+Jmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0
OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZ2l0aHVi
LmNvbS94ZW4tdHJvb3BzL2Rpc3BsX2JlL2Jsb2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0KkwxMl9f
O0l3ISFHRl8yOWRiY1FJVUJQQSFrWjFKUUZSUzJwWGpfSXVYQmh2WWhtUDlRX3N2Y0x5akNYSzk0
NjVVTEdCNE1laVlQUnoyY0Y3bGVwSGdncjlVeFBVOXpPQkVVdyQiIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMv
ZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdGXzI5ZGJjUUlV
QlBBIWtaMUpRRlJTMnBYal9JdVhCaHZZaG1QOVFfc3ZjTHlqQ1hLOTQ2NVVMR0I0TWVpWVBSejJj
RjdsZXBIZ2dyOVV4UFU5ek9CRVV3JDwvYT4mZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7PGJyPiZndDsg
Jmd0Ozxicj4mZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0
cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0
cy50eHQqTDEyX187SXchIUdGXzI5ZGJjUUlVQlBBIWt2RGd5M1gwSXVTUWs3RDJEZHNHdHNqdHlH
cm9ZYk5LT3JQRzk1T3B5b0FrdUJWYkZTbXpvendmb3IwNWprUmwwaXRhMEZ1bUJ3JCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2dpdGh1Yi5jb20v
eGVuLXRyb29wcy9kaXNwbF9iZS9ibG9iL21hc3Rlci9DTWFrZUxpc3RzLnR4dCpMMTJfXztJdyEh
R0ZfMjlkYmNRSVVCUEEha3ZEZ3kzWDBJdVNRazdEMkRkc0d0c2p0eUdyb1liTktPclBHOTVPcHlv
QWt1QlZiRlNtem96d2ZvcjA1amtSbDBpdGEwRnVtQnckPC9hPiZndDs8YnI+Jmd0OyAmZ3Q7ICZn
dDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmbHQ7PGEgaHJl
Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJv
b3BzL2Rpc3BsX2JlL2Jsb2IvbWFzdGVyL0NNYWtlTGlzdHMudHh0KkwxMl9fO0l3ISFHRl8yOWRi
Y1FJVUJQQSFnaTgxb1paTnZXYUZXVVZuYVpsdUFfbU5CQUl0TE1kNFJabW5jLU1fRm1scERvanFl
UVFuUzdhWFNObGJvODByZTl1T2wyd3FGQSQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRl
ZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlzcGxfYmUvYmxv
Yi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdGXzI5ZGJjUUlVQlBBIWdpODFvWlpO
dldhRldVVm5hWmx1QV9tTkJBSXRMTWQ0UlptbmMtTV9GbWxwRG9qcWVRUW5TN2FYU05sYm84MHJl
OXVPbDJ3cUZBJDwvYT4mZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZn
dDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZsdDs8
YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9naXRodWIuY29tL3hl
bi10cm9vcHMvZGlzcGxfYmUvYmxvYi9tYXN0ZXIvQ01ha2VMaXN0cy50eHQqTDEyX187SXchIUdG
XzI5ZGJjUUlVQlBBIW16M2duMXdRTVgyRFhlTnVBVi0xX2RJN254RllZWk9nZFBpSk5TRk1lc0N6
OWxBek9LbHdWUGxkZGJ4YmNMbVVPNDROT3kwVEZBJCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9kaXNwbF9i
ZS9ibG9iL21hc3Rlci9DTWFrZUxpc3RzLnR4dCpMMTJfXztJdyEhR0ZfMjlkYmNRSVVCUEEhbXoz
Z24xd1FNWDJEWGVOdUFWLTFfZEk3bnhGWVlaT2dkUGlKTlNGTWVzQ3o5bEF6T0tsd1ZQbGRkYnhi
Y0xtVU80NE5PeTBURkEkPC9hPiZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmbmJzcDsgQWxleGFuZGVyIFN5Y2hldjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy
PiZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLTxicj4mZ3Q7ICZndDs8YnI+Jmd0OyBbMV08YnI+Jmd0OyA8YSBocmVmPSJo
dHRwczovL2VsaXhpci5ib290bGluLmNvbS9saW51eC92NS41L3NvdXJjZS9kcml2ZXJzL3hlbi9n
bnRkZXYuYyNMMzAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20v
bGludXgvdjUuNS9zb3VyY2UvZHJpdmVycy94ZW4vZ250ZGV2LmMjTDMwMDwvYT48YnI+Jmd0OyAm
bHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZWxpeGlyLmJv
b3RsaW4uY29tL2xpbnV4L3Y1LjUvc291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jKkwzMDBfXztJ
dyEhR0ZfMjlkYmNRSVVCUEEhbWhsUUFQU19Penk1N3hhXzBPUjY2cWMxbWpsU0V6N2xqM01rV0N5
RERGOTFCR2E3SjctQk9ZV1ljZGtzcGxvY1p2em42ZmxrNlEkIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZWxpeGlyLmJvb3RsaW4uY29tL2xpbnV4
L3Y1LjUvc291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jKkwzMDBfXztJdyEhR0ZfMjlkYmNRSVVC
UEEhbWhsUUFQU19Penk1N3hhXzBPUjY2cWMxbWpsU0V6N2xqM01rV0N5RERGOTFCR2E3SjctQk9Z
V1ljZGtzcGxvY1p2em42ZmxrNlEkPC9hPiZndDs8YnI+Jmd0OyBbMl08YnI+Jmd0OyA8YSBocmVm
PSJodHRwczovL2VsaXhpci5ib290bGluLmNvbS9saW51eC92NS41L3NvdXJjZS9kcml2ZXJzL3hl
bi9nbnRkZXYuYyNMMzE5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5j
b20vbGludXgvdjUuNS9zb3VyY2UvZHJpdmVycy94ZW4vZ250ZGV2LmMjTDMxOTwvYT48YnI+Jmd0
OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZWxpeGly
LmJvb3RsaW4uY29tL2xpbnV4L3Y1LjUvc291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jKkwzMTlf
XztJdyEhR0ZfMjlkYmNRSVVCUEEhbWhsUUFQU19Penk1N3hhXzBPUjY2cWMxbWpsU0V6N2xqM01r
V0N5RERGOTFCR2E3SjctQk9ZV1ljZGtzcGxvY1p2d2pPZllKeGckIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZWxpeGlyLmJvb3RsaW4uY29tL2xp
bnV4L3Y1LjUvc291cmNlL2RyaXZlcnMveGVuL2dudGRldi5jKkwzMTlfXztJdyEhR0ZfMjlkYmNR
SVVCUEEhbWhsUUFQU19Penk1N3hhXzBPUjY2cWMxbWpsU0V6N2xqM01rV0N5RERGOTFCR2E3Sjct
Qk9ZV1ljZGtzcGxvY1p2d2pPZllKeGckPC9hPiZndDs8YnI+Jmd0Ozxicj48YnI+WzFdIDxhIGhy
ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJvb3BzL2Rpc3BsX2JlIiB0YXJnZXQ9Il9ibGFu
ayI+aHR0cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvZGlzcGxfYmU8L2E+PC9kaXY+PC9kaXY+
PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+Jm5ic3A7PC9kaXY+PC9CT0RZPjwvSFRNTD4K

----ALT--2cAeB49257DbbC9313Db7a25C7c5C5eE1587387344--


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:03:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:03:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQW4j-0005tl-3v; Mon, 20 Apr 2020 13:03:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=VyLZ=6E=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jQW4h-0005tg-Tf
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:02:59 +0000
X-Inumbo-ID: 428a1304-8307-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 428a1304-8307-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 13:02:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=W09ujvn6zHL+FVq+uHtKF1npnXqYeIi9IbSgfmvfBWY=; b=CeR48/NOEPi4RpjQw2iSDQcS4v
 65xLdBQM0XmIJFbFA8+XilT7ueqfUYseGW/2Uz39w1HHy/FjEDzCiuEoOyvFFVGmivi6/LjopUUn5
 Qe7kSUnS90FrzAki5NiaAAjsUWpFznu+fQ8Ppr7v+HtLkexMPDrewJ6k4a5S5cv01FZQ=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jQW4f-0004iA-L6; Mon, 20 Apr 2020 13:02:57 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jQW4f-0003jR-Ac; Mon, 20 Apr 2020 13:02:57 +0000
Date: Mon, 20 Apr 2020 14:02:54 +0100
From: Wei Liu <wl@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v3] Introduce a description of the Backport and Fixes tags
Message-ID: <20200420130254.unwgbelql75lnprw@debian>
References: <20200417222430.20480-1-sstabellini@kernel.org>
 <35b34e2f-e6cd-6afc-19fd-c7880ec0eace@xen.org>
 <20200420102710.cg3bmjlntgpxqj77@debian>
 <a4cfb801-f0c5-f08d-02fc-c35820bccd87@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a4cfb801-f0c5-f08d-02fc-c35820bccd87@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, konrad.wilk@oracle.com,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 george.dunlap@citrix.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 20, 2020 at 02:36:49PM +0200, Jan Beulich wrote:
> On 20.04.2020 12:27, Wei Liu wrote:
> > On Mon, Apr 20, 2020 at 10:31:28AM +0100, Julien Grall wrote:
> >> On 17/04/2020 23:24, Stefano Stabellini wrote:
> >>> Create a new document under docs/process to describe our special tags.
> >>> Add a description of the Fixes tag and the new Backport tag. Also
> >>> clarify that lines with tags should not be split.
> >>>
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> >>> CC: Ian Jackson <ian.jackson@eu.citrix.com>
> >>> CC: Wei Liu <wl@xen.org>
> >>> CC: jbeulich@suse.com
> >>> CC: george.dunlap@citrix.com
> >>> CC: julien@xen.org
> >>> CC: lars.kurth@citrix.com
> >>> CC: andrew.cooper3@citrix.com
> >>> CC: konrad.wilk@oracle.com
> >>> ---
> >>> Removing Acks as I added the description of "Fixes"
> >>> ---
> >>>   docs/process/tags.pandoc | 55 ++++++++++++++++++++++++++++++++++++++++
> >>>   1 file changed, 55 insertions(+)
> >>>   create mode 100644 docs/process/tags.pandoc
> >>>
> >>> diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
> >>> new file mode 100644
> >>> index 0000000000..06b06dda01
> >>> --- /dev/null
> >>> +++ b/docs/process/tags.pandoc
> >>> @@ -0,0 +1,55 @@
> >>> +Tags: No line splitting
> >>> +-----------------------
> >>> +Do not split a tag across multiple lines, tags are exempt from the
> >>> +"wrap at 75 columns" rule in order to simplify parsing scripts.  For
> >>> +example:
> >>> +
> >>> +        Fixes: 67d01cdb5 ("x86: infrastructure to allow converting certain indirect calls to direct ones")
> >>
> >> The SHA-1 ID is 9 characters but...
> >>
> >>> +
> >>> +
> >>> +Fixes Tag
> >>> +---------
> >>> +
> >>> +If your patch fixes a bug in a specific commit, e.g. you found an issue using
> >>> +``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
> >>> +the SHA-1 ID, and the one line summary.
> >>
> >> ... you request 12 characters here. Can you make sure the two match please?
> >>
> >> However, I am not entirely sure why we should mandate 12 characters. With
> >> the title, you should always be able to find back the commit if there is a
> >> clash.
> > 
> > This is copied from Linux's document.
> > 
> > I normally use 8-9 characters, but I don't mind using 12 either.
> 
> Are they still saying 9? I've been asked to switch to 12 several
> weeks back ...

I mean when I work on Xen I normally use 8 or 9. Not sure about Linux.

Wei.

> 
> Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:06:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQW8U-000622-MT; Mon, 20 Apr 2020 13:06:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQW8T-00061w-In
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:06:53 +0000
X-Inumbo-ID: cd850afe-8307-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cd850afe-8307-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 13:06:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 38272ADEE;
 Mon, 20 Apr 2020 13:06:51 +0000 (UTC)
Subject: Re: [PATCH 07/10] x86/shadow: the guess_wrmap() hook is needed for
 HVM only
To: Tim Deegan <tim@xen.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
 <1e221192-7899-b60d-0280-b77ab5877772@suse.com>
 <20200418090317.GD92478@deinos.phlegethon.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <43a8e15c-e739-0cb3-4ad9-23def4e24709@suse.com>
Date: Mon, 20 Apr 2020 15:06:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200418090317.GD92478@deinos.phlegethon.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 18.04.2020 11:03, Tim Deegan wrote:
> At 16:28 +0200 on 17 Apr (1587140897), Jan Beulich wrote:
>> sh_remove_write_access() bails early for !external guests, and hence its
>> building and thus the need for the hook can be suppressed altogether in
>> !HVM configs.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
>> @@ -366,6 +367,14 @@ int sh_validate_guest_entry(struct vcpu
>>  extern int sh_remove_write_access(struct domain *d, mfn_t readonly_mfn,
>>                                    unsigned int level,
>>                                    unsigned long fault_addr);
>> +#else
>> +static inline int sh_remove_write_access(struct domain *d, mfn_t readonly_mfn,
>> +                                         unsigned int level,
>> +                                         unsigned long fault_addr)
>> +{
> 
> Can we have an ASSERT(!shadow_mode_refcounts(d)) here, please,
> matching the check that would have made it a noop before?

I've added one, but I find this quite odd in a !HVM build, where

#define PG_refcounts   0

and

#define paging_mode_refcounts(_d) (!!((_d)->arch.paging.mode & PG_refcounts))

Perhaps you're wanting this mainly for documentation purposes?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:07:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQW8l-00063p-W1; Mon, 20 Apr 2020 13:07:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FXEW=6E=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jQW8l-00063e-1y
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:07:11 +0000
X-Inumbo-ID: d7888e87-8307-11ea-905f-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d7888e87-8307-11ea-905f-12813bfff9fa;
 Mon, 20 Apr 2020 13:07:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587388029;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=L3PQ48H6KQFQdpQ41RB3Eoax7eA/K+aSt4iO3iwbA0Q=;
 b=KxmgF63CwqTHsy/XsRt1HI5Sn+sCCSs0hAmAsBqC5mEER9A5LzuPgqjR
 421EZP9Uf/ckIFaZ0AY7RB9dyC/OzInXJKyA3TN0PIeBiQv8c3kLl5oEF
 drVdtb7VWLK5eYEdB55qi/4wVrVauvCly3AEh9OyWo5nwi5ZWCCWtNC0H g=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: KPcc98wCAz7VmNkfybLHtCKZadOKWATAuQcK8CQIuHZOeFd02qSJp87ki60Q1JlmZjaF4DXIbe
 EXCB2QgPNCP8sqMP2oj6gVH32W3ETDunncqS1ZuFF5k2BaqeaGjJkWPw+as9wdCBdBej5D/B4Q
 e8LvkTLd3LZ7UkEl9BA03Umsu35ZA9VnRLSDXPbeFJxjjxitttlsbnj9rssj0fiF8nk//3fRg2
 tx/jz6IS5qaB5+6B+HuubCsZ05XxEyThe6RkR5Y0mtZYXO2ZP7zJoOqTSeat+2PzqFZRD3dsvs
 CQM=
X-SBRS: 2.7
X-MesageID: 16611592
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="16611592"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v2] sched: print information about scheduling granularity
Date: Mon, 20 Apr 2020 14:06:50 +0100
Message-ID: <20200420130650.14341-1-sergey.dyasli@citrix.com>
X-Mailer: git-send-email 2.17.1
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sergey Dyasli <sergey.dyasli@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Currently it might be not obvious which scheduling mode (e.g. core-
scheduling) is being used by the scheduler. Alleviate this by printing
additional information about the selected granularity per-cpupool.

Note: per-cpupool granularity selection is not implemented yet.
      The single global value is being used for each cpupool.

Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
---
v2:
- print information on a separate line
- use per-cpupool granularity
- updated commit message

CC: Juergen Gross <jgross@suse.com>
CC: Dario Faggioli <dfaggioli@suse.com>
CC: George Dunlap <george.dunlap@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
---
 xen/common/sched/cpupool.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index d40345b585..68106f6c15 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -40,6 +40,30 @@ static DEFINE_SPINLOCK(cpupool_lock);
 static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
 static unsigned int __read_mostly sched_granularity = 1;
 
+static void sched_gran_print(enum sched_gran mode, unsigned int gran)
+{
+    char *str = "";
+
+    switch ( mode )
+    {
+    case SCHED_GRAN_cpu:
+        str = "cpu";
+        break;
+    case SCHED_GRAN_core:
+        str = "core";
+        break;
+    case SCHED_GRAN_socket:
+        str = "socket";
+        break;
+    default:
+        ASSERT_UNREACHABLE();
+        break;
+    }
+
+    printk("Scheduling granularity: %s, %u CPU%s per sched-resource\n",
+           str, gran, gran == 1 ? "" : "s");
+}
+
 #ifdef CONFIG_HAS_SCHED_GRANULARITY
 static int __init sched_select_granularity(const char *str)
 {
@@ -115,6 +139,7 @@ static void __init cpupool_gran_init(void)
         warning_add(fallback);
 
     sched_granularity = gran;
+    sched_gran_print(opt_sched_granularity, sched_granularity);
 }
 
 unsigned int cpupool_get_granularity(const struct cpupool *c)
@@ -911,6 +936,7 @@ void dump_runq(unsigned char key)
     {
         printk("Cpupool %d:\n", (*c)->cpupool_id);
         printk("Cpus: %*pbl\n", CPUMASK_PR((*c)->cpu_valid));
+        sched_gran_print((*c)->gran, cpupool_get_granularity(*c));
         schedule_dump(*c);
     }
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:14:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:14:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWFI-0006zz-Nl; Mon, 20 Apr 2020 13:13:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQWFH-0006zt-ES
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:13:55 +0000
X-Inumbo-ID: c906f144-8308-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c906f144-8308-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 13:13:54 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4FE38AC92;
 Mon, 20 Apr 2020 13:13:52 +0000 (UTC)
Subject: Re: [PATCH v2] sched: print information about scheduling granularity
To: Sergey Dyasli <sergey.dyasli@citrix.com>
References: <20200420130650.14341-1-sergey.dyasli@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8543ad06-2b98-a211-8360-c57ee9ddafa2@suse.com>
Date: Mon, 20 Apr 2020 15:13:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200420130650.14341-1-sergey.dyasli@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
 George Dunlap <george.dunlap@citrix.com>, Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 15:06, Sergey Dyasli wrote:
> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -40,6 +40,30 @@ static DEFINE_SPINLOCK(cpupool_lock);
>  static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
>  static unsigned int __read_mostly sched_granularity = 1;
>  
> +static void sched_gran_print(enum sched_gran mode, unsigned int gran)
> +{
> +    char *str = "";

const please (could easily be added while committing of course)

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:21:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:21:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWMB-0007vY-R9; Mon, 20 Apr 2020 13:21:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=c3QN=6E=gmail.com=brendank310@srs-us1.protection.inumbo.net>)
 id 1jQWMA-0007vS-WE
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:21:03 +0000
X-Inumbo-ID: c5adc6e8-8309-11ea-b4f4-bc764e2007e4
Received: from mail-ua1-x944.google.com (unknown [2607:f8b0:4864:20::944])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c5adc6e8-8309-11ea-b4f4-bc764e2007e4;
 Mon, 20 Apr 2020 13:20:58 +0000 (UTC)
Received: by mail-ua1-x944.google.com with SMTP id i22so3581748uak.6
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 06:20:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=VpcsqAlQlp7qXVfTlVL/05yjiCd41tZkoCGHDj0/oIg=;
 b=SDBMgZMBMQiUhjqjoRYdHTSfW35pmmUTaN3+a+Kq/dpf9w1HQINbDts+dCFue2++v9
 mFquXPXHcnNQX/YfKjKXT95U1918HP3SI679T3kBy4wzZuOZmoTC7v9/D1kQ0F3I9GK3
 7D5mQfr7aestjxLHUUxYQW20rcITTOh8HqZ8gNHmrxZZcGCAgeH1ziyOQsg1iAx0SFhY
 FKAH2ssxhV6XEsTrD5hbGMNPiPL+TlO9JJ7jmUKFm9kxlDvUu+n27aGvjuNxXMi0tixc
 hDW0YosOI+oCJjx6bAjo2jVSJk52snubwTozoe/cd7UYhgHcQfQKr0OUimr05tVXHask
 uvsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=VpcsqAlQlp7qXVfTlVL/05yjiCd41tZkoCGHDj0/oIg=;
 b=Jg+DUA3GT06lmZJi++81uRt2AbHDDy1faIo66fPHK6W0/lHD5VCjnHT/kVt0QtBy+d
 oNu9bmQO0I7ztSDpL/6+WdkvvoEQll1fX4Ra3me2X+u9d/HWsPnX4eK7InRP+9o69Phz
 0MZwwy8QsPMISIPGAAr6fslKV0QYpTTNm2Damsr/pkdjtnNmkGTFS+0Y2SH4P1wxNXyz
 VXgwxRQYNSTFwjptkoMdPIp6BOJV2AKcvchT6k7JPzln+LbdT3DxT4yDHZ1eACmcZCNn
 vEB6VnuzTqnJo150HF7+PTU4CqcimdEThu1e0/2eUoqfgVV9lxvKFttAGzVyXjXEpsyi
 w8+A==
X-Gm-Message-State: AGi0PuaIyBOGi5EEyfvPEI9Z2pU9WOK3+OpOEOlBycjhDT5RVIv64Tru
 qkjDdNV1fHQLTnP9gu91770jlxQhy0Uz1XstspA=
X-Google-Smtp-Source: APiQypIacDoPrZtqodsBs9S8OPRC8LOLQEWyIt9K+7I5gWva8YiFgsYuOv3zEWP9LgyTQMq7Wr5dfDyjMypyGhCiD/s=
X-Received: by 2002:ab0:705:: with SMTP id h5mr7844656uah.74.1587388857926;
 Mon, 20 Apr 2020 06:20:57 -0700 (PDT)
MIME-Version: 1.0
References: <20200417133626.72302-1-brendank310@gmail.com>
 <20200417133626.72302-2-brendank310@gmail.com>
 <AADFC41AFE54684AB9EE6CBC0274A5D19D84C3FA@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D19D84C3FA@SHSMSX104.ccr.corp.intel.com>
From: Brendan Kerrigan <brendank310@gmail.com>
Date: Mon, 20 Apr 2020 09:20:46 -0400
Message-ID: <CAKPa3c1fsGctG9+P2VNYQez8TWndc=qpa6-O+=LC4dB5qHRLig@mail.gmail.com>
Subject: Re: [PATCH 1/1] x86/vtd: Mask DMAR faults for IGD devices
To: "Tian, Kevin" <kevin.tian@intel.com>
Content-Type: multipart/alternative; boundary="000000000000ff4c2205a3b8c467"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Brendan Kerrigan <kerriganb@ainfosec.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--000000000000ff4c2205a3b8c467
Content-Type: text/plain; charset="UTF-8"

While it's described as errata for gen8/9, the previous reporting was from
2015 which predates those generations. I tested it on a gen 7 box (which
was causing me the grief of consuming my Xen console buffer). It could be
the case that the FPD code isn't implemented (which wouldn't matter for
gen8/9 because it is broken), and the original problem of faulty firmware
reporting bad ranges is the ultimate culprit. As far as the last two
questions, I was testing on an older version of Xen (4.9.x) and ported it
to master. Happy to hear a better approach to solving the original problem.

-Brendan

On Sun, Apr 19, 2020 at 11:28 PM Tian, Kevin <kevin.tian@intel.com> wrote:

> > From: Brendan Kerrigan <brendank310@gmail.com>
> > Sent: Friday, April 17, 2020 9:36 PM
> >
> > From: Brendan Kerrigan <kerriganb@ainfosec.com>
> >
> > The Intel graphics device records DMAR faults regardless
> > of the Fault Process Disable bit being set. When this fault
>
> Since this is an errata for specific generations, let's describe
> this way instead of stating it as a generic problem.
>
> > occurs, enable the Interrupt Mask (IM) bit in the Fault
> > Event Control (FECTL) register to prevent the continued
> > recording of the fault.
> >
> > Signed-off-by: Brendan Kerrigan <kerriganb@ainfosec.com>
> > ---
> >  xen/drivers/passthrough/vtd/iommu.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/xen/drivers/passthrough/vtd/iommu.c
> > b/xen/drivers/passthrough/vtd/iommu.c
> > index 07d40b37fe..288399d816 100644
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -41,6 +41,8 @@
> >  #include "vtd.h"
> >  #include "../ats.h"
> >
> > +#define IS_IGD(seg, id) (0 == seg && 0 == PCI_BUS(id) && 2 ==
> PCI_SLOT(id)
> > && 0 == PCI_FUNC(id))
> > +
> >  struct mapped_rmrr {
> >      struct list_head list;
> >      u64 base, end;
> > @@ -872,6 +874,13 @@ static int iommu_page_fault_do_one(struct
> > vtd_iommu *iommu, int type,
> >      printk(XENLOG_G_WARNING VTDPREFIX "%s: reason %02x - %s\n",
> >             kind, fault_reason, reason);
> >
> > +    if ( DMA_REMAP == fault_type && type && IS_IGD(seg, source_id) ) {
> > +        u32 fectl = dmar_readl(iommu->reg, DMAR_FECTL_REG);
> > +        fectl |= DMA_FECTL_IM;
> > +        dmar_writel(iommu->reg, DMAR_FECTL_REG, fectl);
> > +        printk(XENLOG_G_WARNING VTDPREFIX "Disabling DMAR faults for
> > IGD\n");
> > +    }
> > +
>
> Several questions. First, I just note that FPD is not touched by any code
> today. then how is this errata being caught? Second, we already have
> pci_check_disable_device in place which stops DMAs from the problematic
> device if it triggers excessive fault reports. why doesn't it work for your
> case? Last, dma_msi_end just forces clearing the mask bit at end of
> handling
> the fault interrupt, making above fix meaningless. Those questions just
> make me wonder how you actually test this patch and whether it's
> necessary...
>
> Thanks
> Kevin
>
> >      if ( iommu_verbose && fault_type == DMA_REMAP )
> >          print_vtd_entries(iommu, PCI_BUS(source_id),
> PCI_DEVFN2(source_id),
> >                            addr >> PAGE_SHIFT);
> > --
> > 2.17.1
>
>

--000000000000ff4c2205a3b8c467
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>While it&#39;s described as errata for gen8/9, the pr=
evious reporting was from 2015 which predates those generations. I tested i=
t on a gen 7 box (which was causing me the grief of consuming my Xen consol=
e buffer). It could be the case that the FPD code isn&#39;t implemented (wh=
ich wouldn&#39;t matter for gen8/9 because it is broken), and the original =
problem of faulty firmware reporting bad ranges is the ultimate culprit. As=
 far as the last two questions, I was testing on an older version of Xen (4=
.9.x) and ported it to master. Happy to hear a better approach to solving t=
he original problem.</div><div><br></div><div>-Brendan<br></div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr=
 19, 2020 at 11:28 PM Tian, Kevin &lt;<a href=3D"mailto:kevin.tian@intel.co=
m">kevin.tian@intel.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">&gt; From: Brendan Kerrigan &lt;<a href=3D"mailto:br=
endank310@gmail.com" target=3D"_blank">brendank310@gmail.com</a>&gt;<br>
&gt; Sent: Friday, April 17, 2020 9:36 PM<br>
&gt; <br>
&gt; From: Brendan Kerrigan &lt;<a href=3D"mailto:kerriganb@ainfosec.com" t=
arget=3D"_blank">kerriganb@ainfosec.com</a>&gt;<br>
&gt; <br>
&gt; The Intel graphics device records DMAR faults regardless<br>
&gt; of the Fault Process Disable bit being set. When this fault<br>
<br>
Since this is an errata for specific generations, let&#39;s describe<br>
this way instead of stating it as a generic problem.<br>
<br>
&gt; occurs, enable the Interrupt Mask (IM) bit in the Fault<br>
&gt; Event Control (FECTL) register to prevent the continued<br>
&gt; recording of the fault.<br>
&gt; <br>
&gt; Signed-off-by: Brendan Kerrigan &lt;<a href=3D"mailto:kerriganb@ainfos=
ec.com" target=3D"_blank">kerriganb@ainfosec.com</a>&gt;<br>
&gt; ---<br>
&gt;=C2=A0 xen/drivers/passthrough/vtd/iommu.c | 9 +++++++++<br>
&gt;=C2=A0 1 file changed, 9 insertions(+)<br>
&gt; <br>
&gt; diff --git a/xen/drivers/passthrough/vtd/iommu.c<br>
&gt; b/xen/drivers/passthrough/vtd/iommu.c<br>
&gt; index 07d40b37fe..288399d816 100644<br>
&gt; --- a/xen/drivers/passthrough/vtd/iommu.c<br>
&gt; +++ b/xen/drivers/passthrough/vtd/iommu.c<br>
&gt; @@ -41,6 +41,8 @@<br>
&gt;=C2=A0 #include &quot;vtd.h&quot;<br>
&gt;=C2=A0 #include &quot;../ats.h&quot;<br>
&gt; <br>
&gt; +#define IS_IGD(seg, id) (0 =3D=3D seg &amp;&amp; 0 =3D=3D PCI_BUS(id)=
 &amp;&amp; 2 =3D=3D PCI_SLOT(id)<br>
&gt; &amp;&amp; 0 =3D=3D PCI_FUNC(id))<br>
&gt; +<br>
&gt;=C2=A0 struct mapped_rmrr {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 struct list_head list;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 u64 base, end;<br>
&gt; @@ -872,6 +874,13 @@ static int iommu_page_fault_do_one(struct<br>
&gt; vtd_iommu *iommu, int type,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 printk(XENLOG_G_WARNING VTDPREFIX &quot;%s: reason=
 %02x - %s\n&quot;,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kind, fault_reason, rea=
son);<br>
&gt; <br>
&gt; +=C2=A0 =C2=A0 if ( DMA_REMAP =3D=3D fault_type &amp;&amp; type &amp;&=
amp; IS_IGD(seg, source_id) ) {<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 u32 fectl =3D dmar_readl(iommu-&gt;reg, D=
MAR_FECTL_REG);<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 fectl |=3D DMA_FECTL_IM;<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 dmar_writel(iommu-&gt;reg, DMAR_FECTL_REG=
, fectl);<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 printk(XENLOG_G_WARNING VTDPREFIX &quot;D=
isabling DMAR faults for<br>
&gt; IGD\n&quot;);<br>
&gt; +=C2=A0 =C2=A0 }<br>
&gt; +<br>
<br>
Several questions. First, I just note that FPD is not touched by any code<b=
r>
today. then how is this errata being caught? Second, we already have<br>
pci_check_disable_device in place which stops DMAs from the problematic<br>
device if it triggers excessive fault reports. why doesn&#39;t it work for =
your<br>
case? Last, dma_msi_end just forces clearing the mask bit at end of handlin=
g<br>
the fault interrupt, making above fix meaningless. Those questions just<br>
make me wonder how you actually test this patch and whether it&#39;s necess=
ary...<br>
<br>
Thanks<br>
Kevin<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0 if ( iommu_verbose &amp;&amp; fault_type =3D=3D DM=
A_REMAP )<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 print_vtd_entries(iommu, PCI_BUS(sou=
rce_id), PCI_DEVFN2(source_id),<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 addr &gt;&gt; PAGE_SHIFT);<br>
&gt; --<br>
&gt; 2.17.1<br>
<br>
</blockquote></div>

--000000000000ff4c2205a3b8c467--


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:35:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:35:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWZc-0000Uc-02; Mon, 20 Apr 2020 13:34:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQWZb-0000UX-EF
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:34:55 +0000
X-Inumbo-ID: b8011106-830b-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b8011106-830b-11ea-b4f4-bc764e2007e4;
 Mon, 20 Apr 2020 13:34:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=KHZs/z/LrfqhfDQ4gmLLzmAK5E3xFeKoPnMo1lVPRtA=; b=duhHwTD69XjxKOBN2aJBRP0fAC
 RfjxcFLoKppfdiuc/OtL0sSJifMmARn7G3dsocyiKFxsPfNIvvUpdtGxZfkiOf+AAMkuMgXvQEaLM
 M9dNaclBdjNBMvsp6pe1Ac6nDUAOX2t7kR3x2eg7j47A9aZvRcOLEArhnKiDLXhiJk0w=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQWZY-0005Ky-0s; Mon, 20 Apr 2020 13:34:52 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQWZX-0005RH-PI; Mon, 20 Apr 2020 13:34:51 +0000
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Jan Beulich <jbeulich@suse.com>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
Date: Mon, 20 Apr 2020 14:34:49 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 20/04/2020 09:04, Jan Beulich wrote:
> On 19.04.2020 12:49, Julien Grall wrote:
>> --- a/docs/misc/pvcalls.pandoc
>> +++ b/docs/misc/pvcalls.pandoc
>> @@ -246,9 +246,7 @@ The format is defined as follows:
>>       			uint32_t domain;
>>       			uint32_t type;
>>       			uint32_t protocol;
>> -    			#ifdef CONFIG_X86_32
>>       			uint8_t pad[4];
>> -    			#endif
>>       		} socket;
>>       		struct xen_pvcalls_connect {
>>       			uint64_t id;
>> @@ -257,16 +255,12 @@ The format is defined as follows:
>>       			uint32_t flags;
>>       			grant_ref_t ref;
>>       			uint32_t evtchn;
>> -    			#ifdef CONFIG_X86_32
>>       			uint8_t pad[4];
>> -    			#endif
>>       		} connect;
>>       		struct xen_pvcalls_release {
>>       			uint64_t id;
>>       			uint8_t reuse;
>> -    			#ifdef CONFIG_X86_32
>>       			uint8_t pad[7];
>> -    			#endif
>>       		} release;
>>       		struct xen_pvcalls_bind {
>>       			uint64_t id;
>> @@ -276,9 +270,7 @@ The format is defined as follows:
>>       		struct xen_pvcalls_listen {
>>       			uint64_t id;
>>       			uint32_t backlog;
>> -    			#ifdef CONFIG_X86_32
>>       			uint8_t pad[4];
>> -    			#endif
>>       		} listen;
>>       		struct xen_pvcalls_accept {
>>       			uint64_t id;
> 
> I wonder on what grounds these #ifdef-s had been there - they're
> plain wrong with the types used in the public header.
> 
>> --- a/xen/include/public/io/pvcalls.h
>> +++ b/xen/include/public/io/pvcalls.h
>> @@ -65,6 +65,7 @@ struct xen_pvcalls_request {
>>               uint32_t domain;
>>               uint32_t type;
>>               uint32_t protocol;
>> +            uint8_t pad[4];
>>           } socket;
>>           struct xen_pvcalls_connect {
>>               uint64_t id;
>> @@ -73,10 +74,12 @@ struct xen_pvcalls_request {
>>               uint32_t flags;
>>               grant_ref_t ref;
>>               uint32_t evtchn;
>> +            uint8_t pad[4];
>>           } connect;
>>           struct xen_pvcalls_release {
>>               uint64_t id;
>>               uint8_t reuse;
>> +            uint8_t pad[7];
>>           } release;
>>           struct xen_pvcalls_bind {
>>               uint64_t id;
>> @@ -86,6 +89,7 @@ struct xen_pvcalls_request {
>>           struct xen_pvcalls_listen {
>>               uint64_t id;
>>               uint32_t backlog;
>> +            uint8_t pad[4];
>>           } listen;
> 
> I'm afraid we can't change these in such a way - your additions
> change sizeof() for the respective sub-structures on 32-bit x86,
> and hence this is not a backwards compatible adjustment. 

This is a bit confusing, each structure contain a 64-bit field so I 
would have thought it the structure would be 8-byte aligned (as on 
32-bit Arm). But looking at the spec, a uint64_t will only aligned to 
4-byte.

However, I am not sure why sizeof() matters here. I understand the value 
would be different, but AFAICT, this is not used as part of the protocol.

IIUC the request should always be 56-bytes, so at worse you will read 
unknown bytes. Those bytes are at the end of the structure, so it should 
not matter.

> The
> best I can think of right now that we could do is make the
> difference explicit, by putting the padding fields inside
> #ifndef __i386__. But of course this is awkward at least when
> thinking about a 32-bit / 64-bit pair of communication ends on
> an x86-64 host.

I don't think this is necessary because of the way a request has been 
defined.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:39:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWdz-0000ev-OY; Mon, 20 Apr 2020 13:39:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQWdy-0000ep-AJ
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:39:26 +0000
X-Inumbo-ID: 5905a707-830c-11ea-9062-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5905a707-830c-11ea-9062-12813bfff9fa;
 Mon, 20 Apr 2020 13:39:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 533E8ADD3;
 Mon, 20 Apr 2020 13:39:23 +0000 (UTC)
Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200331103102.1105674-1-anthony.perard@citrix.com>
 <20200331103102.1105674-15-anthony.perard@citrix.com>
 <e28fa2b6-89c9-8e87-eaf0-91a3d6f6a62f@suse.com>
 <20200416124400.GG4088@perard.uk.xensource.com>
 <312e719f-2bae-cb29-a6dd-29ae0d976d95@suse.com>
 <20200416150929.GL4088@perard.uk.xensource.com>
 <586cff44-d46e-3a5b-9e47-0c7ff4de8801@suse.com>
 <20200417131931.GM4088@perard.uk.xensource.com>
 <83de83ee-848f-a048-7293-d1e5b01dd217@suse.com>
 <20200417144218.GN4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <fa559a21-5c86-fe00-0bbf-23270e5f6951@suse.com>
Date: Mon, 20 Apr 2020 15:39:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417144218.GN4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 16:42, Anthony PERARD wrote:
> On Fri, Apr 17, 2020 at 03:39:48PM +0200, Jan Beulich wrote:
>> On 17.04.2020 15:19, Anthony PERARD wrote:
>>> Or do you mean keeping exception to the rule? And hope that when someone
>>> changes the rule, it doesn't forget to check if the exception needs
>>> changing as well?
>>
>> ... "exception" like you put it (requiring special care to keep
>> multiple instances in sync) is not the only way this can be done
>> (and indeed I'd not want something like this). Since you have
>> (in patch 15) e.g.
>>
>> guest_walk_%.o: guest_walk.c FORCE
>> 	$(call if_changed_rule,cc_o_c)
>>
>> anyway, the desire to skip the objcopy step could be communicated
>> to the command from here, without needing to clone the command.
>> One way might be a special (phony) dependency, another might be to
>> set some variable along the lines of
>>
>> guest_walk_%.o: SPECIAL := y
> 
> I guess something like that could be done. But if possible, I'd like to
> avoid that.
> 
>>> Also, I'm going to have to use this patch later anyway as sometime CC
>>> use a full path to the source as file symbol. So this is going to be
>>> important when we will run for example
>>> `clang -o arch/x86/mm/guest_walk_2.o arch/x86/mm/guest_walk.c`.
>>> (There isn't a patch for that yet.)
>>
>> That's interesting - what will be the goal of that future adjustment?
> 
> It's a step toward my goal of been able to have out-of-tree build for
> xen, as stated in my cover letter. In order to do that, I try to adapt
> Kbuild to build Xen.
> 
> Kbuild is building the linux kernel without changing directory, so I'd
> like to do the same, as it probably makes it easier to do out-of-tree
> build.
> 
> Another tool I'd like to use from Kbuild is ./fixdep, it's a small
> program that run after running CC and fix the dependency file that CC
> generates. The main thing it does is to add a dependency on
> Kconfig options that a source file uses instead of having a dependency
> on whether any unrelated Kconfig has change at all. But ./fixdep from
> Linux only works if we build without changing directory. ([1] for more
> on fixdep)
> 
> I guess one advantage of never changing directory is that we can always
> use relative path in global *FLAGS. There isn't a need to use absolute
> path, which is an issue when the source tree is moved to a different
> location. That can easily happen when for example you try to build in a
> container (mapping the source tree inside it) then try to rebuild from
> outside. (After using automation/scripts/containerize for example.)
> And we don't need tricks like the .*.d2 files (which isn't needed in the
> hypervisor anyway, so far at least).

Ah, I see. Out-of-tree builds don't necessarily imply source trees
that can also be moved, so you want to actually go a step further.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:40:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:40:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWeh-0001OF-3I; Mon, 20 Apr 2020 13:40:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQWef-0001O8-Rn
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:40:09 +0000
X-Inumbo-ID: 735baa10-830c-11ea-83d8-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 735baa10-830c-11ea-83d8-bc764e2007e4;
 Mon, 20 Apr 2020 13:40:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587390008;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=dkX0LhNkF7QXB5i7ncQgZIg5lPgcDEw3d4hNAnw1U2A=;
 b=gNBe3oJ8DWyWa6TlnHr2m0xtGaUh63A/hxhTtsniIfUBHSBoP4+2VQ76
 S0/auIGpehujDwQWLp6jpBm2N8YJqXPD81I5oR6kE613RRNtAHF5vjI2G
 tvEf2fF95MyGEcgp2XUhvaRy4QGO5oGwi2CwW1y3FZnFya7G77amRk58u E=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: y1HcT2tUx2uuBM38CT6ha1INOCW9zW3Nu58s+MT2Lj1kMr+PbnnFaFbyn0vBY6nHQ6lJRfwHeB
 e8NqKeX6nIVP11Rz7EldKGqP7IahnkHAuQtM3moIhxTXhqltdngHcFcE3nmtaWslgRKCwRtq0a
 8CEePjA63mYGx31oqA/EN2ISY6MMe9JtSgbdwfVDkfv9xwTQshGMNWOPC3Mflzq1D9oPcWAp9a
 ms+jiP8rp2+83j87ec3mI3KDWwaIHy5PzcXnWv7YLZOoYYVhD+8pczPsYxxyCKqwcmPU1ApInk
 LwA=
X-SBRS: 2.7
X-MesageID: 16253199
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="16253199"
Subject: Re: [PATCH] x86emul: SYSRET must change CPL
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <d193babc-9afa-7cff-13f4-532e62d5e3e6@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <4f605ad9-ebf0-522e-6d84-ec717ab6171e@citrix.com>
Date: Mon, 20 Apr 2020 14:40:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d193babc-9afa-7cff-13f4-532e62d5e3e6@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 13:14, Jan Beulich wrote:
> The special AMD behavior of leaving SS mostly alone wasn't really
> complete: We need to adjust CPL aka SS.DPL.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Oops.

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -6022,6 +6022,8 @@ x86_emulate(
>  
>              /* There's explicitly no RPL adjustment here. */
>              sreg.sel = (msr_val >> 48) + 8;
> +            /* But DPL needs adjustment, for the new CPL to be correct. */
> +            sreg.dpl = 3;
>          }
>  
>  #ifdef __x86_64__



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:40:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWfQ-0001U5-Dh; Mon, 20 Apr 2020 13:40:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=pMKz=6E=dornerworks.com=jeff.kubascik@srs-us1.protection.inumbo.net>)
 id 1jQWfP-0001Tw-9Z
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:40:55 +0000
X-Inumbo-ID: 8ea3e878-830c-11ea-9e09-bc764e2007e4
Received: from webmail.dornerworks.com (unknown [12.207.209.150])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8ea3e878-830c-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 13:40:54 +0000 (UTC)
Subject: Re: Re: [Xen-devel] [PATCH] sched/core: Fix bug when moving a domain
 between cpupools
To: Dario Faggioli <dfaggioli@suse.com>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>, <xen-devel@lists.xenproject.org>, George Dunlap
 <george.dunlap@citrix.com>
References: <20200327193023.506-1-jeff.kubascik@dornerworks.com>
 <9969e5ea-1378-3439-c9a5-19fb9b5c91ac@suse.com>
 <f3e7c6bfc2203119b2dfc36bd1fb9167b4fbfb2c.camel@suse.com>
From: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Message-ID: <a72b2571-65b0-bd6a-2bd5-2ce7a0667648@dornerworks.com>
Date: Mon, 20 Apr 2020 09:42:01 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <f3e7c6bfc2203119b2dfc36bd1fb9167b4fbfb2c.camel@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [172.27.0.12]
X-ClientProxiedBy: Mcbain.dw.local (172.27.1.45) To Mcbain.dw.local
 (172.27.1.45)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stewart Hildebrand <Stewart.Hildebrand@dornerworks.com>,
 Nathan Studer <Nathan.Studer@dornerworks.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Thank you Juergen and Dario!

On 4/16/2020 12:09 PM, Dario Faggioli wrote:
> On Wed, 2020-04-15 at 11:08 +0200, Jürgen Groß wrote:
>> On 27.03.20 20:30, Jeff Kubascik wrote:
>>> For each UNIT, sched_set_affinity is called before unit->priv is
>>> updated
>>> to the new cpupool private UNIT data structure. The issue is
>>> sched_set_affinity will call the adjust_affinity method of the
>>> cpupool.
>>> If defined, the new cpupool may use unit->priv (e.g. credit), which
>>> at
>>> this point still references the old cpupool private UNIT data
>>> structure.
>>>
>>> This change fixes the bug by moving the switch of unit->priv earler
>>> in
>>> the function.
>>>
>>> Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
>>
>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>
> Acked-by: Dario Faggioli <dfaggioli@suse.com>
> 
> Sorry it took a while. And thanks Juergen for also having a look.
> 
> Regards
> 

Sincerely,
Jeff Kubascik


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:43:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWhj-0001ez-SK; Mon, 20 Apr 2020 13:43:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQWhi-0001eu-US
 for xen-devel@lists.xen.org; Mon, 20 Apr 2020 13:43:18 +0000
X-Inumbo-ID: e3eef7a0-830c-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e3eef7a0-830c-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 13:43:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587390199;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=XuJI7MJ4eLlPZd78Ewl8OXRKmbXDAyZFQxiQFbAVD2E=;
 b=RDeMqUYE/KjWx6b+USzEneZ9dh/eGDI4PWWisfTK/qGTk4BfT0P/yT69
 o/xAjm760Oyqwj3j3yCZ0jfg1aZxr1SHZ6ugPQwbnCtIYIn6YpqtZDhmJ
 mIY7w5JJoEgfPgE7d1GNLRlEetYttrggA7R5iko4FBNlbxxFyGtQ9TZLz U=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: SDxmUL4Ds1blFeR6GmLnRQYPchznhXdtAXvYtHUglLxmvz1yXI3USVUO3Z81NSnG1GNJWn0Vb4
 K6U5PtGGXSNPNkbYyJrqZluMAsJfRU1415zhs7gi6CmBXZXR8pQaA/h6RwkBIpelf3BbuStxPx
 OJF9xQ3pJljaAFjfaYe0P4/3xjxnqGmxUMTeWP7NLCE0dlWvsQiqcFjxDF4J/4HUNe4fOV5nMn
 sDcn64NEckI/nDyOy04fWz4ZPWGo6mNisjBwgvSiyH2RYfw9MViAQYnS3d8CbII3rjyMPzXEaM
 G+g=
X-SBRS: 2.7
X-MesageID: 15952752
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="15952752"
Subject: Re: [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2
To: "Wieczorkiewicz, Pawel" <wipawel@amazon.de>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-5-wipawel@amazon.de>
 <e1e910a7-ed94-46e9-6987-fecdd704e104@citrix.com>
 <82FE157A-310D-4D4E-9D87-F04DE2E6B26E@amazon.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <26028dfa-d475-486d-83ae-08b27389d536@citrix.com>
Date: Mon, 20 Apr 2020 14:43:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <82FE157A-310D-4D4E-9D87-F04DE2E6B26E@amazon.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "semelpaul@gmail.com" <semelpaul@gmail.com>, "paul@xen.org" <paul@xen.org>,
 "julien@xen.org" <julien@xen.org>, "Manthey, Norbert" <nmanthey@amazon.de>,
 "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 12:51, Wieczorkiewicz, Pawel wrote:
>> On 16. Apr 2020, at 12:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>
>>
>>
>> On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
>>> @@ -272,9 +274,23 @@ void arch_setup(void)
>>>
>>>     init_hypercalls();
>>>
>>> -    if ( !is_initdomain() )
>>> +    xen_version = hypercall_xen_version(XENVER_version, NULL);
>>> +    if ( version )
>>> +        *version = xen_version;
>>> +
>>> +    /*
>>> +     * The setup_pv_console function registers a writing function
>>> +     * that makes hvm guests crash on Xen 4.2
>> This comment in particular is rather concerning.  Even if there is a
>> configuration issue in 4.2 stopping the PV console from being wired up
>> properly, nothing involved in transmitting on the console should crash
>> the guest.
>>
> I am again a little short on details here. Maybe Paul could chime in.
> But, I vagualy remember it was something about the init_pv_console()’s:
>
>     if ( port >= (sizeof(shared_info.evtchn_pending) * CHAR_BIT) )
>         panic("evtchn %u out of evtchn_pending[] range\n", port);

This is a sanity check about not overrunning the evtchn_pending array. 
However, the check is still correct AFAICT.

port will either be 0 (if not configured by the toolstack), or strictly
less than 8 if configured properly.

What value are you seeing here?

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:45:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:45:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWjV-0001lZ-9e; Mon, 20 Apr 2020 13:45:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=FSNm=6E=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jQWjT-0001lS-V3
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:45:07 +0000
X-Inumbo-ID: 25101994-830d-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 25101994-830d-11ea-b4f4-bc764e2007e4;
 Mon, 20 Apr 2020 13:45:07 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 81AFDADD3;
 Mon, 20 Apr 2020 13:45:05 +0000 (UTC)
Subject: Re: [PATCH v2] sched: print information about scheduling granularity
To: Sergey Dyasli <sergey.dyasli@citrix.com>, xen-devel@lists.xenproject.org
References: <20200420130650.14341-1-sergey.dyasli@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <fd6eb92b-0708-186e-7d17-3527a2673dc8@suse.com>
Date: Mon, 20 Apr 2020 15:45:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200420130650.14341-1-sergey.dyasli@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.20 15:06, Sergey Dyasli wrote:
> Currently it might be not obvious which scheduling mode (e.g. core-
> scheduling) is being used by the scheduler. Alleviate this by printing
> additional information about the selected granularity per-cpupool.
> 
> Note: per-cpupool granularity selection is not implemented yet.
>        The single global value is being used for each cpupool.

This is misleading. You are using the per-cpupool values, but they
are all the same right now.

> 
> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
> ---
> v2:
> - print information on a separate line
> - use per-cpupool granularity
> - updated commit message
> 
> CC: Juergen Gross <jgross@suse.com>
> CC: Dario Faggioli <dfaggioli@suse.com>
> CC: George Dunlap <george.dunlap@citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> ---
>   xen/common/sched/cpupool.c | 26 ++++++++++++++++++++++++++
>   1 file changed, 26 insertions(+)
> 
> diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
> index d40345b585..68106f6c15 100644
> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -40,6 +40,30 @@ static DEFINE_SPINLOCK(cpupool_lock);
>   static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
>   static unsigned int __read_mostly sched_granularity = 1;
>   
> +static void sched_gran_print(enum sched_gran mode, unsigned int gran)
> +{
> +    char *str = "";
> +
> +    switch ( mode )
> +    {
> +    case SCHED_GRAN_cpu:
> +        str = "cpu";
> +        break;
> +    case SCHED_GRAN_core:
> +        str = "core";
> +        break;
> +    case SCHED_GRAN_socket:
> +        str = "socket";
> +        break;
> +    default:
> +        ASSERT_UNREACHABLE();
> +        break;
> +    }

With this addition it might make sense to have an array indexed by
mode to get the string. This array could then be used in
sched_select_granularity(), too.

> +
> +    printk("Scheduling granularity: %s, %u CPU%s per sched-resource\n",
> +           str, gran, gran == 1 ? "" : "s");
> +}
> +
>   #ifdef CONFIG_HAS_SCHED_GRANULARITY
>   static int __init sched_select_granularity(const char *str)
>   {
> @@ -115,6 +139,7 @@ static void __init cpupool_gran_init(void)
>           warning_add(fallback);
>   
>       sched_granularity = gran;
> +    sched_gran_print(opt_sched_granularity, sched_granularity);
>   }
>   
>   unsigned int cpupool_get_granularity(const struct cpupool *c)
> @@ -911,6 +936,7 @@ void dump_runq(unsigned char key)
>       {
>           printk("Cpupool %d:\n", (*c)->cpupool_id);
>           printk("Cpus: %*pbl\n", CPUMASK_PR((*c)->cpu_valid));
> +        sched_gran_print((*c)->gran, cpupool_get_granularity(*c));
>           schedule_dump(*c);
>       }


Juergen



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:45:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWk6-0001pL-KY; Mon, 20 Apr 2020 13:45:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQWk5-0001p7-1I
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:45:45 +0000
X-Inumbo-ID: 3b17da24-830d-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3b17da24-830d-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 13:45:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6D501AAB2;
 Mon, 20 Apr 2020 13:45:42 +0000 (UTC)
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Julien Grall <julien@xen.org>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
Date: Mon, 20 Apr 2020 15:45:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 15:34, Julien Grall wrote:
> Hi Jan,
> 
> On 20/04/2020 09:04, Jan Beulich wrote:
>> On 19.04.2020 12:49, Julien Grall wrote:
>>> --- a/docs/misc/pvcalls.pandoc
>>> +++ b/docs/misc/pvcalls.pandoc
>>> @@ -246,9 +246,7 @@ The format is defined as follows:
>>>                   uint32_t domain;
>>>                   uint32_t type;
>>>                   uint32_t protocol;
>>> -                #ifdef CONFIG_X86_32
>>>                   uint8_t pad[4];
>>> -                #endif
>>>               } socket;
>>>               struct xen_pvcalls_connect {
>>>                   uint64_t id;
>>> @@ -257,16 +255,12 @@ The format is defined as follows:
>>>                   uint32_t flags;
>>>                   grant_ref_t ref;
>>>                   uint32_t evtchn;
>>> -                #ifdef CONFIG_X86_32
>>>                   uint8_t pad[4];
>>> -                #endif
>>>               } connect;
>>>               struct xen_pvcalls_release {
>>>                   uint64_t id;
>>>                   uint8_t reuse;
>>> -                #ifdef CONFIG_X86_32
>>>                   uint8_t pad[7];
>>> -                #endif
>>>               } release;
>>>               struct xen_pvcalls_bind {
>>>                   uint64_t id;
>>> @@ -276,9 +270,7 @@ The format is defined as follows:
>>>               struct xen_pvcalls_listen {
>>>                   uint64_t id;
>>>                   uint32_t backlog;
>>> -                #ifdef CONFIG_X86_32
>>>                   uint8_t pad[4];
>>> -                #endif
>>>               } listen;
>>>               struct xen_pvcalls_accept {
>>>                   uint64_t id;
>>
>> I wonder on what grounds these #ifdef-s had been there - they're
>> plain wrong with the types used in the public header.
>>
>>> --- a/xen/include/public/io/pvcalls.h
>>> +++ b/xen/include/public/io/pvcalls.h
>>> @@ -65,6 +65,7 @@ struct xen_pvcalls_request {
>>>               uint32_t domain;
>>>               uint32_t type;
>>>               uint32_t protocol;
>>> +            uint8_t pad[4];
>>>           } socket;
>>>           struct xen_pvcalls_connect {
>>>               uint64_t id;
>>> @@ -73,10 +74,12 @@ struct xen_pvcalls_request {
>>>               uint32_t flags;
>>>               grant_ref_t ref;
>>>               uint32_t evtchn;
>>> +            uint8_t pad[4];
>>>           } connect;
>>>           struct xen_pvcalls_release {
>>>               uint64_t id;
>>>               uint8_t reuse;
>>> +            uint8_t pad[7];
>>>           } release;
>>>           struct xen_pvcalls_bind {
>>>               uint64_t id;
>>> @@ -86,6 +89,7 @@ struct xen_pvcalls_request {
>>>           struct xen_pvcalls_listen {
>>>               uint64_t id;
>>>               uint32_t backlog;
>>> +            uint8_t pad[4];
>>>           } listen;
>>
>> I'm afraid we can't change these in such a way - your additions
>> change sizeof() for the respective sub-structures on 32-bit x86,
>> and hence this is not a backwards compatible adjustment. 
> 
> This is a bit confusing, each structure contain a 64-bit field so
> I would have thought it the structure would be 8-byte aligned (as
> on 32-bit Arm). But looking at the spec, a uint64_t will only
> aligned to 4-byte.
> 
> However, I am not sure why sizeof() matters here. I understand
> the value would be different, but AFAICT, this is not used as part
> of the protocol.

Two independent components of a consumer of our interface could
have a function taking (pointer to) struct xen_pvcalls_connect.
If one component gets re-built with the new definition and the
other doesn't, they'll disagree on what range of memory needs
to be accessible. The instantiating side (using the old header)
may have ended up placing the struct immediately ahead of a
page boundary. The consuming side (using the changed header)
would then encounter a fault if it wanted to access the struct
as a whole (assignment, memcpy()).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:48:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWmN-00020m-67; Mon, 20 Apr 2020 13:48:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=2FAk=6E=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jQWmL-00020h-TX
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:48:05 +0000
X-Inumbo-ID: 8ef9d962-830d-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8ef9d962-830d-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 13:48:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587390486;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=2NElD+U/1cEa4jqn3EeFINWbuMVySiRvo1hS95d1zH4=;
 b=V+RflgJnyZ/TY/Kj5KMpDgT6hR16Pag34LQeRlWsCYRqwzy3ACVfIu2v
 wCyKd3a+MAzGATgGXmA/IolO87/cdwXgXCyzSa5aQR4JY3lKh4FdbRQlA
 kjoMQLxSvyB8iHy243qg3M0830fZhmhAVo9nkMbwGB3dxcvzqjDOxFe+N k=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: wtr3FQppgT4kf7DOPZIrmcD6ZcKl/z5owwStwrFadIVBw9nqLVfHzS+5gGSNe181hV4ha6sHQK
 bl7Ee+HFXbAWvSI/HoZXbrkIrhs9zQD4WEOkqDwgHKLIyOzoDoMoZYtdufbdydphX+g4q5Yo+c
 8DrbnIhjFzyNF04omdehH5K75hXC4TShcj/sGTMNL44bHML8bOv7nX4X3A3OkaUf3wURoxtF3c
 Bv0GjsOfeURpS/5i5nObHHRq3q+0AKNPijDXAaYhrCd0Nd+E0qZ/APJUnjriBy42k+BpSbE2Wx
 cBc=
X-SBRS: 2.7
X-MesageID: 15953093
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="15953093"
Date: Mon, 20 Apr 2020 15:47:57 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
Message-ID: <20200420134757.GS28601@Air-de-Roger>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200417155004.16806-2-andrew.cooper3@citrix.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 04:50:02PM +0100, Andrew Cooper wrote:
> This is the start of some performance and security-hardening improvements,
> based on the fact that 32bit PV guests are few and far between these days.
> 
> Ring1 is full or architectural corner cases, such as counting as supervisor
                ^ of
> from a paging point of view.  This accounts for a substantial performance hit
> on processors from the last 8 years (adjusting SMEP/SMAP on every privilege
> transition), and the gap is only going to get bigger with new hardware
> features.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Wei Liu <wl@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> 
> There is a series I can't quite post yet which wants to conditionally turn
> opt_pv32 off, which is why I've put it straight in in an int8_t form rather

s/in in/in/

> than a straight boolean form.
> ---
>  docs/misc/xen-command-line.pandoc | 12 +++++++++++-
>  xen/arch/x86/Kconfig              | 16 ++++++++++++++++
>  xen/arch/x86/pv/domain.c          | 35 +++++++++++++++++++++++++++++++++++
>  xen/arch/x86/setup.c              |  9 +++++++--
>  xen/include/asm-x86/pv/domain.h   |  6 ++++++
>  5 files changed, 75 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index acd0b3d994..ee12b0f53f 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1694,7 +1694,17 @@ The following resources are available:
>      CDP, one COS will corespond two CBMs other than one with CAT, due to the
>      sum of CBMs is fixed, that means actual `cos_max` in use will automatically
>      reduce to half when CDP is enabled.
> -	
> +
> +### pv
> +    = List of [ 32=<bool> ]
> +
> +    Applicability: x86
> +
> +Controls for aspects of PV guest support.
> +
> +*   The `32` boolean controls whether 32bit PV guests can be created.  It
> +    defaults to `true`, and is ignored when `CONFIG_PV32` is compiled out.
> +
>  ### pv-linear-pt (x86)
>  > `= <boolean>`
>  
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 8149362bde..4c52197de3 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -49,6 +49,22 @@ config PV
>  
>  	  If unsure, say Y.
>  
> +config PV32
> +	bool "Support for 32bit PV guests"
> +	depends on PV
> +	default y
> +	---help---
> +	  The 32bit PV ABI uses Ring1, an area of the x86 architecture which
> +	  was deprecated and mostly removed in the AMD64 spec.  As a result,
> +	  it occasionally conflicts with newer x86 hardware features, causing
> +	  overheads for Xen to maintain backwards compatibility.
> +
> +	  People may wish to disable 32bit PV guests for attack surface
> +	  reduction, or performance reasons.  Backwards compatibility can be
> +	  provided via the PV Shim mechanism.
> +
> +	  If unsure, say Y.
> +
>  config PV_LINEAR_PT
>         bool "Support for PV linear pagetables"
>         depends on PV
> diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> index 70fae43965..47a0db082f 100644
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -16,6 +16,39 @@
>  #include <asm/pv/domain.h>
>  #include <asm/shadow.h>
>  
> +#ifdef CONFIG_PV32
> +int8_t __read_mostly opt_pv32 = -1;
> +#endif
> +
> +static int parse_pv(const char *s)

__init

With that:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 13:56:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 13:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQWuO-0002uo-3p; Mon, 20 Apr 2020 13:56:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQWuN-0002uj-1t
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 13:56:23 +0000
X-Inumbo-ID: b76aed36-830e-11ea-9067-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b76aed36-830e-11ea-9067-12813bfff9fa;
 Mon, 20 Apr 2020 13:56:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 47825AAB2;
 Mon, 20 Apr 2020 13:56:20 +0000 (UTC)
Subject: Re: [PATCH v3] Introduce a description of the Backport and Fixes tags
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200417222430.20480-1-sstabellini@kernel.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <5d33d469-9aba-5285-766a-193d7109712d@suse.com>
Date: Mon, 20 Apr 2020 15:56:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417222430.20480-1-sstabellini@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, julien@xen.org, Wei Liu <wl@xen.org>,
 konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, george.dunlap@citrix.com,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 18.04.2020 00:24, Stefano Stabellini wrote:
> +Backport Tag
> +------------
> +
> +A backport tag is an optional tag in the commit message to request a
> +given commit to be backported to the stable trees:
> +
> +    Backport: 4.9+
> +
> +It marks a commit for being a candidate for backports to all stable
> +trees from 4.9 onward.

Using the wording "stable trees" may, to some, imply ones still
under maintenance. How about omitting "stable", or replacing it
by "released"?

> +The backport requester is expected to specify which currently supported
> +releases need the backport; but encouraged to specify a release as far
> +back as possible which applies. If the requester doesn't know the oldest
> +affected tree, they are encouraged to append a comment like the
> +following:
> +
> +    Backport: 4.9+ # maybe older
> +
> +Maintainers request the Backport tag to be added on commit. Contributors
> +are welcome to mark their patches with the Backport tag when they deem
> +appropriate. Maintainers will request for it to be removed when that is
> +not the case.
> +
> +Please note that the Backport tag is a **request** for backport, which
> +will still need to be evaluated by the stable tree maintainers.
> +Maintainers might ask the requester to help with the backporting work if
> +it is not trivial.
> +
> +When possible, please use the Fixes tag instead.

Maybe amend with "(or in addition)"? I'm thinking in particular
about a case where a buggy change was already backported, but
didn't show up yet in a release from the respective branch(es).

Previously I did suggest to add an indication that people requesting
backports should also be prepare to actually help with backporting.
I don't recall a verbal reply, and I also don't see any respective
update here. (I'm not fully trusting our mail system, i.e. it may
very well be that I did miss a reply.)

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:05:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:05:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQX3L-0003tl-3A; Mon, 20 Apr 2020 14:05:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQX3J-0003tg-2h
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:05:37 +0000
X-Inumbo-ID: 01724392-8310-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 01724392-8310-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 14:05:36 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 638B9AEA2;
 Mon, 20 Apr 2020 14:05:34 +0000 (UTC)
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <5dc9dbd9-fbeb-46ef-4d4e-7916c3219bb3@suse.com>
Date: Mon, 20 Apr 2020 16:05:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417155004.16806-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 17:50, Andrew Cooper wrote:
> This is the start of some performance and security-hardening improvements,
> based on the fact that 32bit PV guests are few and far between these days.
> 
> Ring1 is full or architectural corner cases, such as counting as supervisor

... full of ...

> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1694,7 +1694,17 @@ The following resources are available:
>      CDP, one COS will corespond two CBMs other than one with CAT, due to the
>      sum of CBMs is fixed, that means actual `cos_max` in use will automatically
>      reduce to half when CDP is enabled.
> -	
> +
> +### pv
> +    = List of [ 32=<bool> ]
> +
> +    Applicability: x86
> +
> +Controls for aspects of PV guest support.
> +
> +*   The `32` boolean controls whether 32bit PV guests can be created.  It
> +    defaults to `true`, and is ignored when `CONFIG_PV32` is compiled out.

Rather than ignoring in the way you do, how about ...

> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -16,6 +16,39 @@
>  #include <asm/pv/domain.h>
>  #include <asm/shadow.h>
>  
> +#ifdef CONFIG_PV32
> +int8_t __read_mostly opt_pv32 = -1;
> +#endif
> +
> +static int parse_pv(const char *s)
> +{
> +    const char *ss;
> +    int val, rc = 0;
> +
> +    do {
> +        ss = strchr(s, ',');
> +        if ( !ss )
> +            ss = strchr(s, '\0');
> +
> +        if ( (val = parse_boolean("32", s, ss)) >= 0 )
> +        {
> +#ifdef CONFIG_PV32
> +            opt_pv32 = val;
> +#else
> +            printk(XENLOG_INFO
> +                   "CONFIG_PV32 disabled - ignoring 'pv=32' setting\n");
> +#endif
> +        }

... moving the #ifdef ahead of the if(), and the #endif here (may
want converting to "else if" with a placeholder if(0) for this
purpose), with the separate printk() dropped? I'm in particular
concerned that we may gain a large number of such printk()s over
time, if we added them in such cases. See parse_iommu_param() for
how I'd prefer things to look like in the long run.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:09:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQX7T-00043S-MT; Mon, 20 Apr 2020 14:09:55 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQX7S-00043N-IQ
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:09:54 +0000
X-Inumbo-ID: 9b39e0c0-8310-11ea-9068-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9b39e0c0-8310-11ea-9068-12813bfff9fa;
 Mon, 20 Apr 2020 14:09:54 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7BB53ABD7;
 Mon, 20 Apr 2020 14:09:52 +0000 (UTC)
Subject: Re: [PATCH 2/3] x86/pv: Short-circuit is_pv_{32,64}bit_domain() in
 !CONFIG_PV32 builds
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-3-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <9b721f94-92de-8d23-b9a4-fdaae13aec38@suse.com>
Date: Mon, 20 Apr 2020 16:09:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417155004.16806-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 17:50, Andrew Cooper wrote:
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -215,7 +215,7 @@ int switch_compat(struct domain *d)
>          return 0;
>  
>      d->arch.has_32bit_shinfo = 1;
> -    d->arch.is_32bit_pv = 1;
> +    d->arch.pv.is_32bit = 1;
>  
>      for_each_vcpu( d, v )
>      {
> @@ -235,7 +235,7 @@ int switch_compat(struct domain *d)
>      return 0;
>  
>   undo_and_fail:
> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
>      for_each_vcpu( d, v )
>      {
>          free_compat_arg_xlat(v);
> @@ -358,7 +358,7 @@ int pv_domain_initialise(struct domain *d)
>      d->arch.ctxt_switch = &pv_csw;
>  
>      /* 64-bit PV guest by default. */
> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;

Switch to true/false while you're touching these?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:12:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:12:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXAM-0004v9-Bw; Mon, 20 Apr 2020 14:12:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQXAK-0004v4-QH
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:12:52 +0000
X-Inumbo-ID: 05883850-8311-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 05883850-8311-11ea-83d8-bc764e2007e4;
 Mon, 20 Apr 2020 14:12:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BC2B2AC44;
 Mon, 20 Apr 2020 14:12:50 +0000 (UTC)
Subject: Re: [PATCH 3/3] x86/pv: Compile out compat_gdt in !CONFIG_PV builds
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-4-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3c8eee8d-c2ce-d262-4056-a5d2c9f843cb@suse.com>
Date: Mon, 20 Apr 2020 16:12:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417155004.16806-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 17:50, Andrew Cooper wrote:
> There is no need for the Compat GDT if there are no 32bit PV guests.  This
> saves 4k per online CPU
> 
> Bloat-o-meter reports the following savings in Xen itself:
> 
>   add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605)
>   Function                                     old     new   delta
>   cpu_smpboot_free                            1249    1256      +7
>   per_cpu__compat_gdt_l1e                        8       -      -8
>   per_cpu__compat_gdt                            8       -      -8
>   init_idt_traps                               442     420     -22
>   load_system_tables                           414     364     -50
>   trap_init                                    444     280    -164
>   cpu_smpboot_callback                        1255     991    -264
>   boot_compat_gdt                             4096       -   -4096
>   Total: Before=3062726, After=3058121, chg -0.15%
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Wei Liu <wl@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> 
> The increase in cpu_smpboot_free() appears to be a consequence of a totally
> different layout of basic blocks.
> ---
>  xen/arch/x86/cpu/common.c |  5 +++--
>  xen/arch/x86/desc.c       |  2 ++
>  xen/arch/x86/smpboot.c    |  5 ++++-
>  xen/arch/x86/traps.c      | 10 +++++++---
>  4 files changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 1b33f1ed71..7b093cb421 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -752,8 +752,9 @@ void load_system_tables(void)
>  
>  	_set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss,
>  			 sizeof(*tss) - 1, SYS_DESC_tss_avail);
> -	_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
> -			 sizeof(*tss) - 1, SYS_DESC_tss_busy);
> +	if ( IS_ENABLED(CONFIG_PV32) )
> +		_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
> +				 sizeof(*tss) - 1, SYS_DESC_tss_busy);

Wouldn't this better be "if ( opt_pv32 )"? Also elsewhere then.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:15:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXCU-00052i-QM; Mon, 20 Apr 2020 14:15:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQXCT-00052Y-KF
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:15:05 +0000
X-Inumbo-ID: 534249c9-8311-11ea-906a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 534249c9-8311-11ea-906a-12813bfff9fa;
 Mon, 20 Apr 2020 14:15:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Y9sVFCkw9Wu8l6WSbqyH/0aVtir6qS95iEHpEFKks80=; b=hbsS/MuthYW8Vh+D9Zbnecg7/S
 wVDcymMSymRQYX+6sx3A395EYR7BhwgYe28W2TdwVrWCOavwvGou6Rc4/Jd4UIyRA312YwX5/hhVj
 HpfgNtfaizGIqPDc3ROrJhcCraKsTGTW62FDIYJzXSBPtuIf42LIZTVfRy7udqSQOPpQ=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQXCQ-0006GS-46; Mon, 20 Apr 2020 14:15:02 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQXCP-00080c-T8; Mon, 20 Apr 2020 14:15:02 +0000
Subject: Re: [PATCH 0/3] xenoprof: XSA-313 follow-up
To: paul@xen.org, 'Jan Beulich' <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
 <002801d61302$dbd21950$93764bf0$@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <410df70e-6e21-2d0a-8148-62ccf2a24366@xen.org>
Date: Mon, 20 Apr 2020 15:14:59 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <002801d61302$dbd21950$93764bf0$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Wei Liu' <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 15/04/2020 09:50, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 15 April 2020 09:45
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap <george.dunlap@citrix.com>; Ian Jackson
>> <ian.jackson@eu.citrix.com>; Julien Grall <julien@xen.org>; Stefano Stabellini
>> <sstabellini@kernel.org>; Wei Liu <wl@xen.org>; Paul Durrant <paul@xen.org>
>> Subject: [PATCH 0/3] xenoprof: XSA-313 follow-up
>>
>> Patch 1 was considered to become part of the XSA, but it was then
>> decided against. The other two are a little bit of cleanup, albeit
>> there's certainly far more room for tidying. Yet then again Paul,
>> in his mail from Mar 13, was asking whether we shouldn't drop
>> xenoprof altogether, at which point cleaning up the code would be
>> wasted effort.
>>
> 
> That's still my opinion. This is a large chunk of (only passively maintained) code which I think is of very limited value (since it relates to an old tool, and it only works for PV domains).

While there are no active user we are aware of, this is an example on 
how to implement a profiler backend with Xen. So I would agree with 
Andrew here.

IIRC, the reason behind your request is it makes difficult for your 
xenheap work. Am I correct? If so, do you have a thread explaining the 
issues?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:15:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:15:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXCn-000546-4y; Mon, 20 Apr 2020 14:15:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQXCm-00053z-QH
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:15:24 +0000
X-Inumbo-ID: 6019afe2-8311-11ea-906a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6019afe2-8311-11ea-906a-12813bfff9fa;
 Mon, 20 Apr 2020 14:15:24 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C5DA4ABD7;
 Mon, 20 Apr 2020 14:15:22 +0000 (UTC)
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3aa6e2bf-b0a3-5540-ec9a-0abc048a85ab@suse.com>
Date: Mon, 20 Apr 2020 16:15:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417155004.16806-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 17:50, Andrew Cooper wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -49,6 +49,22 @@ config PV
>  
>  	  If unsure, say Y.
>  
> +config PV32
> +	bool "Support for 32bit PV guests"
> +	depends on PV
> +	default y

I guess I can see why you don't want an EXPERT dependency here, but
I guess we really need to settle on our (as a community) position
on the growth of varying configs people can build and expect to be
supported.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:15:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXDC-00058n-Kx; Mon, 20 Apr 2020 14:15:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=AIDV=6E=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jQXDB-00058d-Hs
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:15:49 +0000
X-Inumbo-ID: 6eb12fd0-8311-11ea-9e09-bc764e2007e4
Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6eb12fd0-8311-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 14:15:48 +0000 (UTC)
Received: by mail-ej1-x644.google.com with SMTP id x1so8034386ejd.8
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 07:15:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=js3/PcnLC9eiEFfZ7ktFRlh5Aytzt6B6NIEngxcMNzM=;
 b=ig7YigTdtLIleaXJLOe+ai2QazINZl0eiLexI0bcIRFQ/FAWiSGb0XmeAZh1yFGDWT
 rL1kfkXGFIg6IhZ5Q+/QVY/2pcWXx67WKj4AfWKI6CGX86oRLFm/TWJp9aD4xOz6dZgM
 qY9fNjjLjOY89wMWXpoaEQiw8InIEbPIr5z4k7FJAumhjj3aBq56a6fZPyl3bRvFqyoQ
 BibnOjYBAd8XWapbT8J9VOC2xTxsh0drgDvI5ej1nAYAQRXb5w8+nlCMy2XuXTIHRA7/
 hbzhRWM5xOpFcFTI74MznTuiWT+pKXCP3dc0xixRUgU6+ZErNR1r6+eEzVo9gICNgyHy
 qXKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=js3/PcnLC9eiEFfZ7ktFRlh5Aytzt6B6NIEngxcMNzM=;
 b=Le2pq2usSFD60rGRxHIryGuQ0EZLbYfOuAfWTsubBmTLjj1StgSpYf/wBLQ5ln4yFu
 2BpaLbo2eL5ueKsWAziRQat9YnvEp2X551y40xITaQQiYxvVcVIR6TNap+sC98KjHqy6
 WoskcfaLy0T7mW8HmqtpObV6vuajBB3IGbhYteKuhHhyo6g8T2ZxKJfdjx0Mg16Dg4Ro
 Bv70hWvF3rRdQ2MndgIlw2ZytZbAXvfnFyvSuJxZpX53Q23meBfjt0z5NTlBctpANqpI
 eiGXPU6QpPe262UsQu3KOA3kC29F8PAz5D8RCtsIjrMSdIgKmWr6n/KFYfnb3UH9cw6V
 dxBA==
X-Gm-Message-State: AGi0PuapGJCFwEJ350C5vLdjJfeulCCz5JGHpl2JFFAUIXqOXK4JtnDY
 Iz0nTIOt56khTJ7IECMz1RgcLBEd13A=
X-Google-Smtp-Source: APiQypLqwQolzKDjGXL0nmgajG5HzKZphaZpNPLBDVnREQ7MNj+KFjWnUzXxUI6Ej62NnOoIjPtJJA==
X-Received: by 2002:a17:906:11c7:: with SMTP id
 o7mr2571936eja.108.1587392146874; 
 Mon, 20 Apr 2020 07:15:46 -0700 (PDT)
Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com.
 [209.85.221.45])
 by smtp.gmail.com with ESMTPSA id l2sm161631ejz.29.2020.04.20.07.15.45
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Apr 2020 07:15:45 -0700 (PDT)
Received: by mail-wr1-f45.google.com with SMTP id u13so12389341wrp.3
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 07:15:45 -0700 (PDT)
X-Received: by 2002:a05:6000:4:: with SMTP id
 h4mr19658737wrx.386.1587392145242; 
 Mon, 20 Apr 2020 07:15:45 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <ef0f91fd4c49c623dda09a1774392d2f2a99ae35.1587142844.git.tamas.lengyel@intel.com>
 <20200420074516.GQ28601@Air-de-Roger>
In-Reply-To: <20200420074516.GQ28601@Air-de-Roger>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Mon, 20 Apr 2020 08:15:10 -0600
X-Gmail-Original-Message-ID: <CABfawh=Fd+Te7ECcgdxU3GUnBYygDXjFDyRHKAWf75MLZu7KAQ@mail.gmail.com>
Message-ID: <CABfawh=Fd+Te7ECcgdxU3GUnBYygDXjFDyRHKAWf75MLZu7KAQ@mail.gmail.com>
Subject: Re: [PATCH v15 1/3] mem_sharing: don't reset vCPU info page during
 fork reset
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.com>=
 wrote:
>
> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
> > When a forked VM is being reset while having vm_events active, re-copyi=
ng the
> > vCPU info page can lead to events being lost. This seems to only affect=
 a
> > subset of events (interrupts), while not others (cpuid, MTF, EPT) thus =
it was
>
> I'm slightly lost by the sentence, is the guest or the hypervisor
> the one losing events?
>
> Ie: interrupts are events from a guest PoV, but cpuid or EPT is not
> something that triggers events that are injected to the guest. I think
> the commit message needs clarification.

Sorry, what I meant was software interrupts are not triggered anymore,
ie. int3 and it's associated event is not sent to the monitor
application (VM_EVENT_REASON_SOFTWARE_BREAKPOINT).

>
> > not discovered beforehand. Only copying vCPU info page contents during =
initial
> > fork fixes the problem.
>
> Hm, I'm not sure I understand why this is causing issues. When you
> reset a fork you should reset the vcpu info page, or else event masks wou=
ld
> be in a wrong state?

When we reset a fork we only want to 1) discard any memory allocated
for it 2) reset the vCPU registers. We don't want to reset event
channels or anything else. We have active vm_events on the domain and
the whole point of doing a fork reset is to avoid having to
reinitialize all that as it's quite slow.

> >
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> > ---
> >  xen/arch/x86/mm/mem_sharing.c | 50 +++++++++++++++++------------------
> >  1 file changed, 25 insertions(+), 25 deletions(-)
> >
> > diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharin=
g.c
> > index e572e9e39d..4b31a8b8f6 100644
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -1534,28 +1534,6 @@ int mem_sharing_fork_page(struct domain *d, gfn_=
t gfn, bool unsharing)
> >                            p2m->default_access, -1);
> >  }
> >
> > -static int bring_up_vcpus(struct domain *cd, struct domain *d)
> > -{
> > -    unsigned int i;
> > -    int ret =3D -EINVAL;
> > -
> > -    if ( d->max_vcpus !=3D cd->max_vcpus ||
> > -        (ret =3D cpupool_move_domain(cd, d->cpupool)) )
> > -        return ret;
> > -
> > -    for ( i =3D 0; i < cd->max_vcpus; i++ )
> > -    {
> > -        if ( !d->vcpu[i] || cd->vcpu[i] )
> > -            continue;
> > -
> > -        if ( !vcpu_create(cd, i) )
> > -            return -EINVAL;
> > -    }
> > -
> > -    domain_update_node_affinity(cd);
> > -    return 0;
> > -}
> > -
> >  static int copy_vcpu_settings(struct domain *cd, const struct domain *=
d)
> >  {
> >      unsigned int i;
> > @@ -1614,6 +1592,31 @@ static int copy_vcpu_settings(struct domain *cd,=
 const struct domain *d)
> >      return 0;
> >  }
> >
> > +static int bring_up_vcpus(struct domain *cd, struct domain *d)
> > +{
> > +    unsigned int i;
> > +    int ret =3D -EINVAL;
> > +
> > +    if ( d->max_vcpus !=3D cd->max_vcpus ||
> > +        (ret =3D cpupool_move_domain(cd, d->cpupool)) )
> > +        return ret;
> > +
> > +    for ( i =3D 0; i < cd->max_vcpus; i++ )
> > +    {
> > +        if ( !d->vcpu[i] || cd->vcpu[i] )
> > +            continue;
> > +
> > +        if ( !vcpu_create(cd, i) )
> > +            return -EINVAL;
> > +    }
> > +
> > +    if ( (ret =3D copy_vcpu_settings(cd, d)) )
> > +        return ret;
> > +
> > +    domain_update_node_affinity(cd);
> > +    return 0;
> > +}
>
> I would prefer the code movement to be in a different patch: it makes
> it more difficult to spot non-functional changes being made while
> moving the function around.

I don't think it's worth splitting this patch because of that. The
patch is quite small an the move is trivial to allow the function
bring_up_vcpus be able to call copy_vcpu_settings without having to
pre-declare that function.

Tamas


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:19:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXH6-0005P1-77; Mon, 20 Apr 2020 14:19:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=AIDV=6E=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jQXH4-0005Ow-Lw
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:19:50 +0000
X-Inumbo-ID: fe343332-8311-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fe343332-8311-11ea-b4f4-bc764e2007e4;
 Mon, 20 Apr 2020 14:19:49 +0000 (UTC)
Received: by mail-ed1-x542.google.com with SMTP id p16so2852575edm.10
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 07:19:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=t/kri24haV5L/p/bSs6cCMuZWIexiokG6gR1wAuRqYc=;
 b=iv2jwUO7qFn3rx7A2CX6BtzqiH9FNBs5WpVuXYESSlw+WGPjPLpJFB1hbwkMBUisag
 5zdkFdWzB+nEkBA9il+2AAlhgSvxelnkAVhrNuwnYC+uUaONDBK3sx0MEyU9fwDccrEq
 K794oUIlYbsgrntEuGkKfDnS/DEbflRinax04/1mmPA4w6Nf5cf3MRtylkbXgTp5Imrr
 c4ZFPF86EslxP7fqI6mGGstMH4JYxhPajhlT+sdgmzuLine0rD0rNuQi71QGE+n2SGT/
 0jeK89J9AuX2O5LWx+/EZL9gT96plRXC5guMWtC9y2Alr6g3Rv88Y0xccI+3aUl3I08i
 J7Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=t/kri24haV5L/p/bSs6cCMuZWIexiokG6gR1wAuRqYc=;
 b=YWfQzgk/RKHsJZE8tU6z7ZgU8OsoIToSZCtO84GxlLyjaIHyAN24W4IuXaDqsbLptV
 UUhFgz4CiyuIiuQ54qm63deCqRCwf3CqpO8fSWWKIZ9VJemj5TS7sWJE5DJmAfsX+rWb
 KTGdUzv11HX0BvaHUQuri6CdzicnRHLqopRaSDz2PIsDTt0HdSuYDyCWsTlLih9T05BM
 6v00xVUpWwJUsmSSjftaRlHzsaw86p4RUZ+teypE4UNVarJ/H4d15rm6T/YgD6SKCuGm
 JvDm+cvgUFX+JGbJDctbYlo6VAfG2oKSqJxgYgD034fhmJDqOfheYTL8NVlT4Ay6NJV5
 hkHw==
X-Gm-Message-State: AGi0Puay0cpudMH9tsfS6505k/2ey0XqAJ1FNUhkqa0cGMgvn5MUlnKf
 QkshGB5UHBM+Ud3jpGmNzbi+BJq8oyU=
X-Google-Smtp-Source: APiQypIzUYfD0SLF+Ne1E+BT5Y4h9OJamjq+oOFaEM150/1PNC1YbDxOMmouEoofJ74hoOvAvvFWwg==
X-Received: by 2002:a05:6402:3041:: with SMTP id
 bu1mr13920357edb.145.1587392388166; 
 Mon, 20 Apr 2020 07:19:48 -0700 (PDT)
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com.
 [209.85.221.41])
 by smtp.gmail.com with ESMTPSA id o13sm163353ejn.19.2020.04.20.07.19.47
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Apr 2020 07:19:47 -0700 (PDT)
Received: by mail-wr1-f41.google.com with SMTP id j2so12373379wrs.9
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 07:19:47 -0700 (PDT)
X-Received: by 2002:a5d:4ac9:: with SMTP id y9mr8992366wrs.182.1587392387111; 
 Mon, 20 Apr 2020 07:19:47 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <0be7501ace42d856b344828755ece18659dabd33.1587142844.git.tamas.lengyel@intel.com>
 <20200420075655.GR28601@Air-de-Roger>
In-Reply-To: <20200420075655.GR28601@Air-de-Roger>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Mon, 20 Apr 2020 08:19:12 -0600
X-Gmail-Original-Message-ID: <CABfawhmWm_KasEPG=4e1V4qF5uh-ErtazsK=O8gS2n80KrqOyA@mail.gmail.com>
Message-ID: <CABfawhmWm_KasEPG=4e1V4qF5uh-ErtazsK=O8gS2n80KrqOyA@mail.gmail.com>
Subject: Re: [PATCH v15 2/3] mem_sharing: allow forking domain with IOMMU
 enabled
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 20, 2020 at 1:57 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.com>=
 wrote:
>
> On Fri, Apr 17, 2020 at 10:06:32AM -0700, Tamas K Lengyel wrote:
> > The memory sharing subsystem by default doesn't allow a domain to share=
 memory
> > if it has an IOMMU active for obvious security reasons. However, when f=
uzzing a
> > VM fork, the same security restrictions don't necessarily apply. While =
it makes
> > no sense to try to create a full fork of a VM that has an IOMMU attache=
d as only
> > one domain can own the pass-through device at a time, creating a shallo=
w fork
> > without a device model is still very useful for fuzzing kernel-mode dri=
vers.
> >
> > By allowing the parent VM to initialize the kernel-mode driver with a r=
eal
> > device that's pass-through, the driver can enter into a state more suit=
able for
>                 ^ passed
> > fuzzing. Some of these initialization steps are quite complex and are e=
asier to
> > perform when a real device is present. After the initialization, shallo=
w forks
> > can be utilized for fuzzing code-segments in the device driver that don=
't
> > directly interact with the device.
>
> If I understand this correctly, the forked VM won't have an IOMMU
> setup, and the only domain allowed to interact with the device would
> be the parent?

Correct, this mode would only be for forks that have no access to
devices at all (--launch-dm no).

>
> >
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> > ---
> >  xen/arch/x86/mm/mem_sharing.c | 18 ++++++++++++------
> >  xen/include/public/memory.h   |  4 +++-
> >  2 files changed, 15 insertions(+), 7 deletions(-)
> >
> > diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharin=
g.c
> > index 4b31a8b8f6..a5063d5992 100644
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -1430,7 +1430,8 @@ static int range_share(struct domain *d, struct d=
omain *cd,
> >      return rc;
> >  }
> >
> > -static inline int mem_sharing_control(struct domain *d, bool enable)
> > +static inline int mem_sharing_control(struct domain *d, bool enable,
> > +                                      bool allow_iommu)
> >  {
> >      if ( enable )
> >      {
> > @@ -1440,7 +1441,7 @@ static inline int mem_sharing_control(struct doma=
in *d, bool enable)
> >          if ( unlikely(!hap_enabled(d)) )
> >              return -ENODEV;
> >
> > -        if ( unlikely(is_iommu_enabled(d)) )
> > +        if (unlikely(!allow_iommu && is_iommu_enabled(d)) )
>
> Coding style (missing space)

Ack

>
> >              return -EXDEV;
> >      }
> >
> > @@ -1827,7 +1828,8 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_=
mem_sharing_op_t) arg)
> >      if ( rc )
> >          goto out;
> >
> > -    if ( !mem_sharing_enabled(d) && (rc =3D mem_sharing_control(d, tru=
e)) )
> > +    if ( !mem_sharing_enabled(d) &&
> > +         (rc =3D mem_sharing_control(d, true, false)) )
> >          return rc;
> >
> >      switch ( mso.op )
> > @@ -2063,9 +2065,10 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen=
_mem_sharing_op_t) arg)
> >      case XENMEM_sharing_op_fork:
> >      {
> >          struct domain *pd;
> > +        bool allow_iommu;
> >
> >          rc =3D -EINVAL;
> > -        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[=
2] )
> > +        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] )
> >              goto out;
> >
> >          rc =3D rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_dom=
ain,
> > @@ -2080,7 +2083,10 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen=
_mem_sharing_op_t) arg)
> >              goto out;
> >          }
> >
> > -        if ( !mem_sharing_enabled(pd) && (rc =3D mem_sharing_control(p=
d, true)) )
> > +        allow_iommu =3D mso.u.fork.flags & XENMEM_FORK_WITH_IOMMU_ALLO=
WED;
>
> I'm not sure whether it is worth to extract the flags into booleans at
> this level. As you add more flags it might make sense to just pass the
> whole flags field to mem_sharing_control?

Sure.

>
> mem_sharing_memop itself doesn't need to know which flags are
> specified.
>
> > +
> > +        if ( !mem_sharing_enabled(pd) &&
> > +             (rc =3D mem_sharing_control(pd, true, allow_iommu)) )
> >          {
> >              rcu_unlock_domain(pd);
> >              goto out;
> > @@ -2138,7 +2144,7 @@ int mem_sharing_domctl(struct domain *d, struct x=
en_domctl_mem_sharing_op *mec)
> >      switch ( mec->op )
> >      {
> >      case XEN_DOMCTL_MEM_SHARING_CONTROL:
> > -        rc =3D mem_sharing_control(d, mec->u.enable);
> > +        rc =3D mem_sharing_control(d, mec->u.enable, false);
> >          break;
> >
> >      default:
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index d36d64b8dc..1d2149def3 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -536,7 +536,9 @@ struct xen_mem_sharing_op {
> >          } debug;
> >          struct mem_sharing_op_fork {      /* OP_FORK */
> >              domid_t parent_domain;        /* IN: parent's domain id */
> > -            uint16_t pad[3];              /* Must be set to 0 */
> > +#define XENMEM_FORK_WITH_IOMMU_ALLOWED 1  /* Allow forking domain with=
 IOMMU */
>
> Since this is a flags field, can you express this is as: (1u << 0).

I was thinking of doing that then it won't fit into a single line. For
this particular flag it would also make no difference.

>
> > +            uint16_t flags;               /* IN: optional settings */
> > +            uint16_t pad[2];              /* Must be set to 0 */
>
> Nit: padding can be made a uint32_t now instead of an array of two
> uint16_t.
>
> Or add an uint16_t between parent_domain and flags and make flags an
> uint32_t.

True.

Thanks,
Tamas


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:19:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXHB-0005Pf-Fz; Mon, 20 Apr 2020 14:19:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQXH9-0005PD-KD
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:19:55 +0000
X-Inumbo-ID: 0030ca42-8312-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0030ca42-8312-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 14:19:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0BDA8ABD7;
 Mon, 20 Apr 2020 14:19:50 +0000 (UTC)
Subject: Re: [PATCH v15 1/3] mem_sharing: don't reset vCPU info page during
 fork reset
To: Tamas K Lengyel <tamas@tklengyel.com>
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <ef0f91fd4c49c623dda09a1774392d2f2a99ae35.1587142844.git.tamas.lengyel@intel.com>
 <20200420074516.GQ28601@Air-de-Roger>
 <CABfawh=Fd+Te7ECcgdxU3GUnBYygDXjFDyRHKAWf75MLZu7KAQ@mail.gmail.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <686dafe9-54f6-3224-d2ff-8cfb99734b2c@suse.com>
Date: Mon, 20 Apr 2020 16:19:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CABfawh=Fd+Te7ECcgdxU3GUnBYygDXjFDyRHKAWf75MLZu7KAQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 16:15, Tamas K Lengyel wrote:
> On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
>>
>> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
>>> When a forked VM is being reset while having vm_events active, re-copying the
>>> vCPU info page can lead to events being lost. This seems to only affect a
>>> subset of events (interrupts), while not others (cpuid, MTF, EPT) thus it was
>>
>> I'm slightly lost by the sentence, is the guest or the hypervisor
>> the one losing events?
>>
>> Ie: interrupts are events from a guest PoV, but cpuid or EPT is not
>> something that triggers events that are injected to the guest. I think
>> the commit message needs clarification.
> 
> Sorry, what I meant was software interrupts are not triggered anymore,
> ie. int3 and it's associated event is not sent to the monitor
> application (VM_EVENT_REASON_SOFTWARE_BREAKPOINT).
> 
>>
>>> not discovered beforehand. Only copying vCPU info page contents during initial
>>> fork fixes the problem.
>>
>> Hm, I'm not sure I understand why this is causing issues. When you
>> reset a fork you should reset the vcpu info page, or else event masks would
>> be in a wrong state?
> 
> When we reset a fork we only want to 1) discard any memory allocated
> for it 2) reset the vCPU registers. We don't want to reset event
> channels or anything else. We have active vm_events on the domain and
> the whole point of doing a fork reset is to avoid having to
> reinitialize all that as it's quite slow.

So for an arbitrary piece of state, what are the criteria to establish
whether to copy or re-init them during a fork? Is it really now and
forever only memory that wants resetting? I have to admit I'm confused
by you also mentioning CPU registers - aren't they to be copied rather
than reset?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:27:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXOh-0006NG-BJ; Mon, 20 Apr 2020 14:27:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=AIDV=6E=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jQXOg-0006NB-Lb
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:27:42 +0000
X-Inumbo-ID: 17c571f2-8313-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 17c571f2-8313-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 14:27:41 +0000 (UTC)
Received: by mail-ed1-x542.google.com with SMTP id j20so7503403edj.0
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 07:27:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=fHHaShK22Kc3ujSnwRS+DsjSEXQ91HZrUzjUtP445/Q=;
 b=AdX8d6ksm28L7TnElgaXLMaLkYZBpVJbaez8GcQT8octHJFfohR3O2ZBokSop8p0AB
 xu7vta75pk2/NQmgI1JdSj3r6aqZ898EzN8tYCWNysswzMsCJ7Rr/eSAdF0T+nKGOSIN
 86Sf8XH6SPW+sRjLtP9bMAVvx0Za6iNOM+oq5Su/5yRN39DY8Y7Qwj39FLNWTLMt1xEC
 FdEWSLAbblIp0rLN9LWp/bmIXlIVQMcF+DpPZz5IauDFiunEOx9to+VPiWhslEx2Tj09
 +auGWOgQHHWfbLg8q4dUV9l54paiDk29Mxkt0rlVeLJVvyGhnNlaEJ5PiS8fVCSsrejh
 aldQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=fHHaShK22Kc3ujSnwRS+DsjSEXQ91HZrUzjUtP445/Q=;
 b=r42AxyETagMJl0C0pFzKaHGetIqtDsVlPjIickm68XmtHEEseKuBKVw+LMrBp/goCC
 Cbr4B9a5ULQT735eZQh3UsP7DrM+xX6ceHTx9gVShUpKaAtlGkvGey2pNtgzt2YhJ2d6
 myUcXvK7Nxyi2X6r3mdZn7lC0g/2+BFb1SixY1/cY+5XSeGuB3pBUIJ3Hw3GEtNVc69b
 VvI0mfIn+f0/WKgylgw7Opf6gOYu9QxxFVM8/TWMBL4jWyOihm+F9GisKF+93JkRiJDx
 h+IfoLdhyTd7KRTLzqKhbje/g1z7xtrrXbWNdW17FZvyk7EdM7M9dB7Fmxt9hgbTm7hl
 3NJg==
X-Gm-Message-State: AGi0PuaZF4ADnorwkTFDok58RWNI3j7SulycTF5qLHizMRsBUPbvIQ3U
 tdBK4d2AcHZQTdGtFW2xeefAyq3jMik=
X-Google-Smtp-Source: APiQypKmShzy15y9E/Q02551hsoYlqlCN3DzAWUpEBt5irxfzEXGTqMupN6c7TUO1lkUK4AHXueVHA==
X-Received: by 2002:a05:6402:120a:: with SMTP id
 c10mr13575460edw.15.1587392860553; 
 Mon, 20 Apr 2020 07:27:40 -0700 (PDT)
Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com.
 [209.85.128.51])
 by smtp.gmail.com with ESMTPSA id g1sm164102ejs.51.2020.04.20.07.27.39
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Apr 2020 07:27:39 -0700 (PDT)
Received: by mail-wm1-f51.google.com with SMTP id h2so11280299wmb.4
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 07:27:39 -0700 (PDT)
X-Received: by 2002:a05:600c:441a:: with SMTP id
 u26mr19128706wmn.154.1587392859434; 
 Mon, 20 Apr 2020 07:27:39 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <ef0f91fd4c49c623dda09a1774392d2f2a99ae35.1587142844.git.tamas.lengyel@intel.com>
 <20200420074516.GQ28601@Air-de-Roger>
 <CABfawh=Fd+Te7ECcgdxU3GUnBYygDXjFDyRHKAWf75MLZu7KAQ@mail.gmail.com>
 <686dafe9-54f6-3224-d2ff-8cfb99734b2c@suse.com>
In-Reply-To: <686dafe9-54f6-3224-d2ff-8cfb99734b2c@suse.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Mon, 20 Apr 2020 08:27:04 -0600
X-Gmail-Original-Message-ID: <CABfawh=TdgdaQnwDoAvGyMMY-HyRyqg9T5oyrfadie9_7GZLeg@mail.gmail.com>
Message-ID: <CABfawh=TdgdaQnwDoAvGyMMY-HyRyqg9T5oyrfadie9_7GZLeg@mail.gmail.com>
Subject: Re: [PATCH v15 1/3] mem_sharing: don't reset vCPU info page during
 fork reset
To: Jan Beulich <jbeulich@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 20, 2020 at 8:19 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 20.04.2020 16:15, Tamas K Lengyel wrote:
> > On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.=
com> wrote:
> >>
> >> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
> >>> When a forked VM is being reset while having vm_events active, re-cop=
ying the
> >>> vCPU info page can lead to events being lost. This seems to only affe=
ct a
> >>> subset of events (interrupts), while not others (cpuid, MTF, EPT) thu=
s it was
> >>
> >> I'm slightly lost by the sentence, is the guest or the hypervisor
> >> the one losing events?
> >>
> >> Ie: interrupts are events from a guest PoV, but cpuid or EPT is not
> >> something that triggers events that are injected to the guest. I think
> >> the commit message needs clarification.
> >
> > Sorry, what I meant was software interrupts are not triggered anymore,
> > ie. int3 and it's associated event is not sent to the monitor
> > application (VM_EVENT_REASON_SOFTWARE_BREAKPOINT).
> >
> >>
> >>> not discovered beforehand. Only copying vCPU info page contents durin=
g initial
> >>> fork fixes the problem.
> >>
> >> Hm, I'm not sure I understand why this is causing issues. When you
> >> reset a fork you should reset the vcpu info page, or else event masks =
would
> >> be in a wrong state?
> >
> > When we reset a fork we only want to 1) discard any memory allocated
> > for it 2) reset the vCPU registers. We don't want to reset event
> > channels or anything else. We have active vm_events on the domain and
> > the whole point of doing a fork reset is to avoid having to
> > reinitialize all that as it's quite slow.
>
> So for an arbitrary piece of state, what are the criteria to establish
> whether to copy or re-init them during a fork? Is it really now and
> forever only memory that wants resetting? I have to admit I'm confused
> by you also mentioning CPU registers - aren't they to be copied rather
> than reset?

Registers are being reset by copying them from the parent. Allocated
memory is discarded as the memory that's needed for the new execution
will get copied when EPT faults happen as it's executing. The goal is
to put the domain back to its initial execution state without having
to reinitialize vm_events. In our experiments when the forks are
executed only for a very short period (fuzzing), having to
reinitialize the vm_event interfaces mean going from ~100 execution/s
to ~2 executions/s. Unfortunately in the current state the fork
doesn't generate the required vm_events after the first execution and
for some reason it only happens for int3 generated events.

Tamas


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:39:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXZr-0007M6-JT; Mon, 20 Apr 2020 14:39:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQXZq-0007M1-IL
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:39:14 +0000
X-Inumbo-ID: b42767de-8314-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b42767de-8314-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 14:39:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587393554;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=S486ude860vDA8QaHxqW7zJSFV8McnAWmJdpiHJaYTI=;
 b=FZYBg2PidIJdLuc/VAPDPYe+7NujJ84xeevZjw+C46DeKhVqOhwy9s6S
 o3Lu0dr/LzZVQVR5izdTI0AWxTiZyagvPljGbbT9c4DsAnI52j6R/dp6/
 8jCMP7wruHGn18j3zUQTJVf9GJBmLl6otmzwR+Px+/b8947dLf+5VQNtT 4=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: GCvJ214p2L2UKCmiUyX3IHFMciauSDgcEU2OJooAW5i+7MFPHm1onAT9uza/eDigefxG4/kAWS
 VS/f7hZVysZOtLBBWFJtwiiFt6jFbbhUqs+3m7PSj1uD0vD+kstyHx/l0/KFmsrfPenYPqMnrQ
 Lma9TYykOgD6VBx59vi3PY3xmnqRYtd4Xdle3Qp//+gF64zoLTvh2fbGGKF/l4ptmM/qweGrnV
 MfSGrLNAqHePpo7z5ESUkEBlv+TsGghhvVK+QxZTWLTLg+knlGAB/aFsfvc1hjTp2jk0Qpnhwn
 VKA=
X-SBRS: 2.7
X-MesageID: 15958555
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="15958555"
Subject: Re: [PATCH 3/3] x86/pv: Compile out compat_gdt in !CONFIG_PV builds
To: Jan Beulich <jbeulich@suse.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-4-andrew.cooper3@citrix.com>
 <3c8eee8d-c2ce-d262-4056-a5d2c9f843cb@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <acffe7f9-3265-e999-34ce-30891535897b@citrix.com>
Date: Mon, 20 Apr 2020 15:39:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3c8eee8d-c2ce-d262-4056-a5d2c9f843cb@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/04/2020 15:12, Jan Beulich wrote:
> On 17.04.2020 17:50, Andrew Cooper wrote:
>> There is no need for the Compat GDT if there are no 32bit PV guests.  This
>> saves 4k per online CPU
>>
>> Bloat-o-meter reports the following savings in Xen itself:
>>
>>   add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605)
>>   Function                                     old     new   delta
>>   cpu_smpboot_free                            1249    1256      +7
>>   per_cpu__compat_gdt_l1e                        8       -      -8
>>   per_cpu__compat_gdt                            8       -      -8
>>   init_idt_traps                               442     420     -22
>>   load_system_tables                           414     364     -50
>>   trap_init                                    444     280    -164
>>   cpu_smpboot_callback                        1255     991    -264
>>   boot_compat_gdt                             4096       -   -4096
>>   Total: Before=3062726, After=3058121, chg -0.15%
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Wei Liu <wl@xen.org>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>
>> The increase in cpu_smpboot_free() appears to be a consequence of a totally
>> different layout of basic blocks.
>> ---
>>  xen/arch/x86/cpu/common.c |  5 +++--
>>  xen/arch/x86/desc.c       |  2 ++
>>  xen/arch/x86/smpboot.c    |  5 ++++-
>>  xen/arch/x86/traps.c      | 10 +++++++---
>>  4 files changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>> index 1b33f1ed71..7b093cb421 100644
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -752,8 +752,9 @@ void load_system_tables(void)
>>  
>>  	_set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss,
>>  			 sizeof(*tss) - 1, SYS_DESC_tss_avail);
>> -	_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>> -			 sizeof(*tss) - 1, SYS_DESC_tss_busy);
>> +	if ( IS_ENABLED(CONFIG_PV32) )
>> +		_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>> +				 sizeof(*tss) - 1, SYS_DESC_tss_busy);
> Wouldn't this better be "if ( opt_pv32 )"? Also elsewhere then.

Doing it like this specifically ensures that there is never a case where
things are half configured.

I don't think it is wise to suggest that making opt_pv32 runtime
configurable might work.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:59:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:59:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXtM-0000jH-V7; Mon, 20 Apr 2020 14:59:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQXtL-0000jA-Dy
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:59:23 +0000
X-Inumbo-ID: 826fb37e-8317-11ea-9e09-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 826fb37e-8317-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 14:59:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587394758;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=0FMwLpqDC0VR7A4uGgKObYvkj59mRHa1JOdxdGTYGzg=;
 b=Aout0F85o8qaOSclzinxrlzka8Tjl96tYOCOdCfc/L1zh6twF0zY3gmc
 D/3TTlR3KSUmLh9IZvYlVh79JhjEPq8FKRMvNzjq9AP8JTM35Ui4/Ddfm
 SDHgpOe9kdOF2mdUkQiEpXcZLevEIsanj1VQR+I5R9iIxjejbOZ8nsV6G s=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 1mGYZCKyXlgwt18fLqgX04XEr+xWh5d5Y1kv8/xwox7zyJlXLBninIdrft4fV0zXKXMxc+Og+9
 DZFWLcRnHh2peXEkJ+6LF5mgc7BUXzLmO/DdVwdRSmJ3RBYux+u4j8AUn7snkuOYbHKIIf/B9t
 KHXATJ78feEYdBIWFmVQaAx2aaYEmozn5NV6H3pzqJfcN8ZQNduu0+z1gWHpzZkRtlQb7FkqIH
 xWRKaqjZ29FTtQL1UgJ8+VwbQ/hjdZaSww/+2FdvfzoIOK1ZPewLGj8RUa2ezFbpr0hC19NCQF
 hQA=
X-SBRS: 2.7
X-MesageID: 15959933
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="15959933"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 2/3] x86/boot: Don't enable EFER.SCE for !CONFIG_PV builds
Date: Mon, 20 Apr 2020 15:59:10 +0100
Message-ID: <20200420145911.5708-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200420145911.5708-1-andrew.cooper3@citrix.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Kevin Tian <kevin.tian@intel.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This will cause all SYSCALL/SYSRET instructions to suffer #UD rather than
following the MSR_{L,C}STAR pointers, allowing us to drop the star_enter()
panic helper, allowing us to clean up the IST stacks in a subsequent patch.

Drop the now-dead conditional SYSENTER logic in the middle of
subarch_percpu_traps_init().

In addition, vmx_restore_host_msrs() need not restore any host
state.  (Regarding the asymmetric changes, VT-x automatically restores
SYSENTER state on vmexit, and SVM restores both SYSCALL/SYSENTER state with
the VMSAVE/VMLOAD instructions.)

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Kevin Tian <kevin.tian@intel.com>
---
 xen/arch/x86/boot/trampoline.S |  4 ++--
 xen/arch/x86/efi/efi-boot.h    |  3 ++-
 xen/arch/x86/hvm/vmx/vmx.c     |  4 ++++
 xen/arch/x86/x86_64/traps.c    | 19 ++++++-------------
 4 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index 18c6638924..928b4ad4ce 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -140,9 +140,9 @@ gdt_48:
 GLOBAL(trampoline_misc_enable_off)
         .quad   0
 
-/* EFER OR-mask for boot paths.  This gets adjusted with NX when available. */
+/* EFER OR-mask for boot paths.  SCE conditional on PV support, NX added when available. */
 GLOBAL(trampoline_efer)
-        .long   EFER_LME | EFER_SCE
+        .long   EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV))
 
 GLOBAL(trampoline_xen_phys_start)
         .long   0
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index a13304201f..bf0fae4f89 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -238,7 +238,8 @@ static void __init noreturn efi_arch_post_exit_boot(void)
     /* Set system registers and transfer control. */
     asm volatile("pushq $0\n\tpopfq");
     rdmsrl(MSR_EFER, efer);
-    efer |= EFER_SCE;
+    if ( IS_ENABLED(CONFIG_PV) )
+        efer |= EFER_SCE;
     if ( cpu_has_nx )
         efer |= EFER_NX;
     wrmsrl(MSR_EFER, efer);
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 869339062b..3e4b2e9a58 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -496,6 +496,10 @@ static void vmx_vcpu_destroy(struct vcpu *v)
  */
 static void vmx_restore_host_msrs(void)
 {
+    /* No PV guests?  No need to set restore host SYSCALL infrastructure. */
+    if ( !IS_ENABLED(CONFIG_PV) )
+        return;
+
     /* Relies on the SYSCALL trampoline being at the start of the stubs. */
     wrmsrl(MSR_STAR,         XEN_MSR_STAR);
     wrmsrl(MSR_LSTAR,        this_cpu(stubs.addr));
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index c3d4faea6b..93af0c5e87 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -299,17 +299,8 @@ static unsigned int write_stub_trampoline(
 
 DEFINE_PER_CPU(struct stubs, stubs);
 
-#ifdef CONFIG_PV
 void lstar_enter(void);
 void cstar_enter(void);
-#else
-static void __cold star_enter(void)
-{
-    panic("lstar/cstar\n");
-}
-#define lstar_enter star_enter
-#define cstar_enter star_enter
-#endif /* CONFIG_PV */
 
 void subarch_percpu_traps_init(void)
 {
@@ -321,6 +312,10 @@ void subarch_percpu_traps_init(void)
     /* IST_MAX IST pages + at least 1 guard page + primary stack. */
     BUILD_BUG_ON((IST_MAX + 1) * PAGE_SIZE + PRIMARY_STACK_SIZE > STACK_SIZE);
 
+    /* No PV guests?  No need to set up SYSCALL/SYSENTER infrastructure. */
+    if ( !IS_ENABLED(CONFIG_PV) )
+        return;
+
     stub_page = map_domain_page(_mfn(this_cpu(stubs.mfn)));
 
     /*
@@ -338,10 +333,8 @@ void subarch_percpu_traps_init(void)
     {
         /* SYSENTER entry. */
         wrmsrl(MSR_IA32_SYSENTER_ESP, stack_bottom);
-        wrmsrl(MSR_IA32_SYSENTER_EIP,
-               IS_ENABLED(CONFIG_PV) ? (unsigned long)sysenter_entry : 0);
-        wrmsr(MSR_IA32_SYSENTER_CS,
-              IS_ENABLED(CONFIG_PV) ? __HYPERVISOR_CS : 0, 0);
+        wrmsrl(MSR_IA32_SYSENTER_EIP, (unsigned long)sysenter_entry);
+        wrmsr(MSR_IA32_SYSENTER_CS, __HYPERVISOR_CS, 0);
     }
 
     /* Trampoline for SYSCALL entry from compatibility mode. */
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:59:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:59:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXtH-0000iy-LM; Mon, 20 Apr 2020 14:59:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQXtG-0000it-Ds
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:59:18 +0000
X-Inumbo-ID: 81b123fa-8317-11ea-9e09-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 81b123fa-8317-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 14:59:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587394757;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=7k2KgyXK5WCQysFCR3M6CGIKNQrfmIps/JCUPxhQK84=;
 b=fuPrV/8gcQcGvGSKsP1nfQSAaP3Qz2zirdRU5L5h1/+ROLiK5+tMDL+u
 qqtaBTvpn5dPOqa9am8dTfP6iGPCHwlSI6J1K3hY4uEgScH6+lAgYjJCK
 cOxDwWGCXAoybMy7KSFMumzqXyklmow/K2gA8FxD++pVBS3ZV9jKjxiwu c=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: vwgPRJFnJJ5HqRLjWI1kNt/Q3Duw63WpHzn+qiHtkUT6j++6JPoEI0IarP9Lwtfke8lXvLX57x
 HZN62iud0ZAumQDQWfc5qdZuJhq/+Rx7vbhfwTG6D3vB4UXx8RCx2GhGqlmXykfIE3yAM5BmRy
 nRnZ8KGR/KMlRjRAlKJB5YsxiIC0fRfW2SxKhrXkMSrRFt7MmwW4iY9N1c+qYir45bb+Dcd6FG
 kE2afj2hZrrAArxk6xvJn4hSjhDpAxsKaDRIVm6NGiiAGUINqahCk8ugKJVOgvDKNu5xkTS9cg
 QGg=
X-SBRS: 2.7
X-MesageID: 15959931
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="15959931"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 1/3] x86/S3: Use percpu_traps_init() rather than opencoding
 SYSCALL/SYSENTER restoration
Date: Mon, 20 Apr 2020 15:59:09 +0100
Message-ID: <20200420145911.5708-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200420145911.5708-1-andrew.cooper3@citrix.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This make the S3 BSP path consistent with AP paths, and reduces the amount of
state needing stashing specially.  Also, it takes care of re-setting up Xen's
LBR configuration if requested, which was missing previously.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/acpi/suspend.c | 25 ++-----------------------
 1 file changed, 2 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/acpi/suspend.c b/xen/arch/x86/acpi/suspend.c
index 32d0f71ffd..1c2f1c470e 100644
--- a/xen/arch/x86/acpi/suspend.c
+++ b/xen/arch/x86/acpi/suspend.c
@@ -15,8 +15,6 @@
 #include <asm/xstate.h>
 #include <xen/hypercall.h>
 
-static unsigned long saved_lstar, saved_cstar;
-static unsigned long saved_sysenter_esp, saved_sysenter_eip;
 static unsigned long saved_fs_base, saved_gs_base, saved_kernel_gs_base;
 static uint64_t saved_xcr0;
 
@@ -25,14 +23,6 @@ void save_rest_processor_state(void)
     saved_fs_base = rdfsbase();
     saved_gs_base = rdgsbase();
     rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
-    rdmsrl(MSR_CSTAR, saved_cstar);
-    rdmsrl(MSR_LSTAR, saved_lstar);
-
-    if ( cpu_has_sep )
-    {
-        rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
-        rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
-    }
 
     if ( cpu_has_xsave )
         saved_xcr0 = get_xcr0();
@@ -46,24 +36,13 @@ void restore_rest_processor_state(void)
     /* Restore full CR4 (inc MCE) now that the IDT is in place. */
     write_cr4(mmu_cr4_features);
 
-    /* Recover syscall MSRs */
-    wrmsrl(MSR_LSTAR, saved_lstar);
-    wrmsrl(MSR_CSTAR, saved_cstar);
-    wrmsrl(MSR_STAR, XEN_MSR_STAR);
-    wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
+    /* (re)initialise SYSCALL/SYSENTER state, amongst other things. */
+    percpu_traps_init();
 
     wrfsbase(saved_fs_base);
     wrgsbase(saved_gs_base);
     wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
 
-    if ( cpu_has_sep )
-    {
-        /* Recover sysenter MSRs */
-        wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
-        wrmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
-        wrmsr(MSR_IA32_SYSENTER_CS, __HYPERVISOR_CS, 0);
-    }
-
     if ( cpu_has_xsave && !set_xcr0(saved_xcr0) )
         BUG();
 
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:59:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:59:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXtS-0000kB-9A; Mon, 20 Apr 2020 14:59:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQXtQ-0000jn-Da
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:59:28 +0000
X-Inumbo-ID: 830acb48-8317-11ea-83d8-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 830acb48-8317-11ea-83d8-bc764e2007e4;
 Mon, 20 Apr 2020 14:59:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587394760;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=iey7aibL2jSId8nqzu63DXwhMLLiDYRA4/Czvj4kpsU=;
 b=Tz2eeTLmy+8ziwN7Ijk6Gs9G5+fpGFOmK8aHg4VeKvlbQJ7PRD1iLlV3
 BW3IugEA6WBQus7IoyEX80Cn+n8zDromj15dV6WGv2hxBUsFYY654yyN4
 0LY0KkwKUyszXzbQmVF8N7oA7HIEFp32+yoPPJTYeFIZ1C2sJbGz/owl4 k=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: jXdlcSAfrcGp+tNv0XgzI+aOKK8aoY9xYgjNRJQHnFyinUhTe6OPol6afEd5ZXugydxkKShrUk
 Q+Ky74EnxbZt1muA2edI2lzxIGBrWzSJS2vSkIjHz50xYultnsXQ9r0XZP3wjNQIIZkqOEb/yz
 u4FYiBm4RZSO5P/Zvbul0qYUGBdHW53WLbgYffkqfc93uEmJRyHSKOihQfA8hDc3ngAS7jBSeR
 9HI5XPd4UiDBkx94FcmoIQwFbpVr/56hnQXGWvSZ0FRU9rweygq9gNlk+5cOM5VcHkhCKzClHb
 Tjc=
X-SBRS: 2.7
X-MesageID: 15928930
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="15928930"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 3/3] x86/pv: Don't use IST for NMI/#MC/#DB in !CONFIG_PV builds
Date: Mon, 20 Apr 2020 15:59:11 +0100
Message-ID: <20200420145911.5708-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200420145911.5708-1-andrew.cooper3@citrix.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

ISTs are used to force a stack switch on CPL0=>0 interrupts/exceptions.  They
however come with a nasty corner case in the case of reentrancy where the
outer exception frame gets clobbered.

When the SYSCALL/SYSRET instructions aren't used, there is no need to use IST
for anything other than #DF, which reduces the number of corner cases.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/common.c       |  8 +++++---
 xen/include/asm-x86/processor.h | 12 +++++++++++-
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 7b093cb421..d45495c701 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -732,15 +732,17 @@ void load_system_tables(void)
 		.rsp2 = 0x8600111111111111ul,
 
 		/*
-		 * MCE, NMI and Double Fault handlers get their own stacks.
+		 * #DF always uses a separate stack. NMI/#MC/#DB only need a
+		 * separate stacks when PV guests are used.
 		 * All others poisoned.
 		 */
 		.ist = {
-			[IST_MCE - 1] = stack_top + IST_MCE * PAGE_SIZE,
 			[IST_DF  - 1] = stack_top + IST_DF  * PAGE_SIZE,
+#ifdef CONFIG_PV
 			[IST_NMI - 1] = stack_top + IST_NMI * PAGE_SIZE,
+			[IST_MCE - 1] = stack_top + IST_MCE * PAGE_SIZE,
 			[IST_DB  - 1] = stack_top + IST_DB  * PAGE_SIZE,
-
+#endif
 			[IST_MAX ... ARRAY_SIZE(tss->ist) - 1] =
 				0x8600111111111111ul,
 		},
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index ea6e5497f4..33f2052c8e 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -441,12 +441,18 @@ struct tss_page {
 };
 DECLARE_PER_CPU(struct tss_page, tss_page);
 
+/*
+ * Interrupt Stack Tables.  Used to force a stack switch on a CPL0=>0
+ * interrupt/exception.  #DF uses IST all the time to detect stack overflows
+ * cleanly.  NMI/#MC/#DB only need IST to cover the SYSCALL gap, and therefore
+ * only necessary with PV guests.
+ */
 #define IST_NONE 0UL
 #define IST_DF   1UL
 #define IST_NMI  2UL
 #define IST_MCE  3UL
 #define IST_DB   4UL
-#define IST_MAX  4UL
+#define IST_MAX  (IS_ENABLED(CONFIG_PV) ? 4ul : 1ul)
 
 /* Set the Interrupt Stack Table used by a particular IDT entry. */
 static inline void set_ist(idt_entry_t *idt, unsigned int ist)
@@ -461,6 +467,8 @@ static inline void set_ist(idt_entry_t *idt, unsigned int ist)
 static inline void enable_each_ist(idt_entry_t *idt)
 {
     set_ist(&idt[TRAP_double_fault],  IST_DF);
+    if ( !IS_ENABLED(CONFIG_PV) )
+        return;
     set_ist(&idt[TRAP_nmi],           IST_NMI);
     set_ist(&idt[TRAP_machine_check], IST_MCE);
     set_ist(&idt[TRAP_debug],         IST_DB);
@@ -469,6 +477,8 @@ static inline void enable_each_ist(idt_entry_t *idt)
 static inline void disable_each_ist(idt_entry_t *idt)
 {
     set_ist(&idt[TRAP_double_fault],  IST_NONE);
+    if ( !IS_ENABLED(CONFIG_PV) )
+        return;
     set_ist(&idt[TRAP_nmi],           IST_NONE);
     set_ist(&idt[TRAP_machine_check], IST_NONE);
     set_ist(&idt[TRAP_debug],         IST_NONE);
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 14:59:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 14:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXtX-0000lt-IX; Mon, 20 Apr 2020 14:59:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQXtV-0000l9-DK
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:59:33 +0000
X-Inumbo-ID: 844a295e-8317-11ea-9e09-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 844a295e-8317-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 14:59:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587394762;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=edN7GW+FnWgdsna6bvvtPwReexh/+W7WgLmlAa4mlw8=;
 b=Ue1dlznVoAYdzgbKWaF0he6kpwx7SkC3z21jZPSGdnbAOaBRF4T5jVqz
 koUn9ejgXrYkSpRFdTh1ReSOHu2HbetQjx0KnxyELIxb1eYchTdkV/EH5
 zmOfv7ZcHaK5wUeWHMyhryz1673/oYFLXi+DmKDT/do1IGfcXUN29tRkL I=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: h3SeV2TztS/EzUEhUx5OovT21RrHn+t17pyPaUkw0kN5AS/64lkQOghl6rXnGNwiEdZPhZjAmp
 g5OPIYZ4SIQrgpL0ikYgp/3aENhB6fi9gKiSrfGZC+WDBcuTqrF/NEuoj1eEEYVQPnlLUox8C8
 OqFZRUQtX/8dpotfHbtncvgLUZYaIWevg8Q5pud68Ba2iGrD28Xs7ZiWUsUIgW1nNCA0tCxoxV
 Qvex6RkThDdcWbZNqPidFIqWv62Hvzu5uOBNAd1oM0jp3ugKn+O7wdRQgQUsWuTsBZRNcgmSMZ
 N/I=
X-SBRS: 2.7
X-MesageID: 16191905
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="16191905"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH 0/3] x86: IST cleanup
Date: Mon, 20 Apr 2020 15:59:08 +0100
Message-ID: <20200420145911.5708-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Kevin Tian <kevin.tian@intel.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Various bits of cleanup for !CONFIG_PV builds.

Andrew Cooper (3):
  x86/S3: Use percpu_traps_init() rather than opencoding SYSCALL/SYSENTER restoration
  x86/boot: Don't enable EFER.SCE for !CONFIG_PV builds
  x86/pv: Don't use IST for NMI/#MC/#DB in !CONFIG_PV builds

 xen/arch/x86/acpi/suspend.c     | 25 ++-----------------------
 xen/arch/x86/boot/trampoline.S  |  4 ++--
 xen/arch/x86/cpu/common.c       |  8 +++++---
 xen/arch/x86/efi/efi-boot.h     |  3 ++-
 xen/arch/x86/hvm/vmx/vmx.c      |  4 ++++
 xen/arch/x86/x86_64/traps.c     | 19 ++++++-------------
 xen/include/asm-x86/processor.h | 12 +++++++++++-
 7 files changed, 32 insertions(+), 43 deletions(-)

-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 15:01:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 15:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQXve-0001mD-1U; Mon, 20 Apr 2020 15:01:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=UDoD=6E=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jQXvd-0001m8-4q
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 15:01:45 +0000
X-Inumbo-ID: d936394e-8317-11ea-b58d-bc764e2007e4
Received: from mail-wm1-x335.google.com (unknown [2a00:1450:4864:20::335])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d936394e-8317-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 15:01:44 +0000 (UTC)
Received: by mail-wm1-x335.google.com with SMTP id u16so3174540wmc.5
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 08:01:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=ffQMkShY/21xVg5iLV5KNIlCzyK/hZzdotYmiBh3NVw=;
 b=WgOT1IYhWk8wUPg3n4DLM+Drl2yavFIjiygv/z096X4bMe9I1fZsLuGVZUR7u8+K2t
 S/1PpjzknJYjf0PGluwZqpkzjbqtlmlaO1XVc8l7R8iVpCHcbTJzmQYbHqTVqzYfOtU1
 31keHCn52yCmW2SPX5cQLriFByeL8GdvwdQUoudDMx7Dily0jt2LqR5hBV/j4dhLKMEY
 JFB9T5tTW+O5yBCk7rIFHAssLzvfR1aS7Q8Gu/0lVkhE71dBZqKFbH+R0IjcE216nhMU
 ILJ1r8z7ijdO4XEK12bw6SlpeBFRjr6Ph9wNmAtN1qNGukhfk/6erCMqHXyUXUaKCvCl
 Ke9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=ffQMkShY/21xVg5iLV5KNIlCzyK/hZzdotYmiBh3NVw=;
 b=FnudXhMo35/oZDqi5nus+CXcCcK/U/bcwQUn12AOhW87woOspP6cCHtB3fMisKmrgt
 nYPui4njRcKIs85k1N1NTCKnWr27MPrBUqE00EybjFuqA06VPTpovCi6aLRIULOUw/JT
 CUpGI/19C+8QDgirqd6CYfZypOGBRv09VasRa6woLgAVb8LahVpHE7N3Dry3pSgs80DN
 8QzxGsZB9Vu81dDy6I5ya0WyPPuzTR+ypsPWbQ0j0kvCDIBUbX41WD0oObxBcAlx7+Gn
 7Aoni4YEqZhiShSSXZeeyCxlkVl3eyA1xuMFmLqVBbiH1n8P9th81NDg8xPMSCS3Az65
 qiIA==
X-Gm-Message-State: AGi0Pubm83nsJpKb+avDccAbGu0dH36BGQswaU174inHmtk/s5TpPD0Y
 J0ws+4ynpnQSmLcVmBlIfVg=
X-Google-Smtp-Source: APiQypKGAp4L4yQFbQxgbStiIUzd/FFARkLJ2QemlYDpaNupVnL/0+O7bdBtbX/UF3qL6x7/b6ytng==
X-Received: by 2002:a1c:e1c1:: with SMTP id
 y184mr18618597wmg.143.1587394903662; 
 Mon, 20 Apr 2020 08:01:43 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id s14sm1698966wme.33.2020.04.20.08.01.41
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 20 Apr 2020 08:01:43 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>, "'Jan Beulich'" <jbeulich@suse.com>,
 <xen-devel@lists.xenproject.org>
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
 <002801d61302$dbd21950$93764bf0$@xen.org>
 <410df70e-6e21-2d0a-8148-62ccf2a24366@xen.org>
In-Reply-To: <410df70e-6e21-2d0a-8148-62ccf2a24366@xen.org>
Subject: RE: [PATCH 0/3] xenoprof: XSA-313 follow-up
Date: Mon, 20 Apr 2020 16:01:41 +0100
Message-ID: <004301d61724$9a5c9ab0$cf15d010$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQKUpBz832WsrmfTrWwwQFYKS8h7/QHBHudWATlYg7ym7SqU4A==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Wei Liu' <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 20 April 2020 15:15
> To: paul@xen.org; 'Jan Beulich' <jbeulich@suse.com>; =
xen-devel@lists.xenproject.org
> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' =
<george.dunlap@citrix.com>; 'Ian
> Jackson' <ian.jackson@eu.citrix.com>; 'Stefano Stabellini' =
<sstabellini@kernel.org>; 'Wei Liu'
> <wl@xen.org>
> Subject: Re: [PATCH 0/3] xenoprof: XSA-313 follow-up
>=20
> Hi Paul,
>=20
> On 15/04/2020 09:50, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: 15 April 2020 09:45
> >> To: xen-devel@lists.xenproject.org
> >> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap =
<george.dunlap@citrix.com>; Ian
> Jackson
> >> <ian.jackson@eu.citrix.com>; Julien Grall <julien@xen.org>; Stefano =
Stabellini
> >> <sstabellini@kernel.org>; Wei Liu <wl@xen.org>; Paul Durrant =
<paul@xen.org>
> >> Subject: [PATCH 0/3] xenoprof: XSA-313 follow-up
> >>
> >> Patch 1 was considered to become part of the XSA, but it was then
> >> decided against. The other two are a little bit of cleanup, albeit
> >> there's certainly far more room for tidying. Yet then again Paul,
> >> in his mail from Mar 13, was asking whether we shouldn't drop
> >> xenoprof altogether, at which point cleaning up the code would be
> >> wasted effort.
> >>
> >
> > That's still my opinion. This is a large chunk of (only passively =
maintained) code which I think is
> of very limited value (since it relates to an old tool, and it only =
works for PV domains).
>=20
> While there are no active user we are aware of, this is an example on
> how to implement a profiler backend with Xen. So I would agree with
> Andrew here.
>=20
> IIRC, the reason behind your request is it makes difficult for your
> xenheap work. Am I correct? If so, do you have a thread explaining the
> issues?

After shared info and grant table, it is the only other occurrence of a =
xenheap page shared with a non-system domain. Also, it cannot be =
trivially replaced with an 'extra' domheap page because its assignment =
changes. Thus a whole bunch of cleanup work that I was hoping to do =
(largely in domain_relinquish_resources and free_domheap_pages) is =
either ruled out, or would have to special-case this type of page.
Also, I am unconvinced that PV guests are sufficiently common these days =
(apart from dom0) that profiling them is of any real use.

  Paul



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 15:47:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 15:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQYdj-0005Nm-RH; Mon, 20 Apr 2020 15:47:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQYdh-0005Nh-T4
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 15:47:17 +0000
X-Inumbo-ID: 35caad7e-831e-11ea-9073-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 35caad7e-831e-11ea-9073-12813bfff9fa;
 Mon, 20 Apr 2020 15:47:16 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 401E9ADA3;
 Mon, 20 Apr 2020 15:47:15 +0000 (UTC)
Subject: Re: [PATCH 3/3] x86/pv: Compile out compat_gdt in !CONFIG_PV builds
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-4-andrew.cooper3@citrix.com>
 <3c8eee8d-c2ce-d262-4056-a5d2c9f843cb@suse.com>
 <acffe7f9-3265-e999-34ce-30891535897b@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <cb6fcbd0-1b0a-d105-30ce-e0a6215f4904@suse.com>
Date: Mon, 20 Apr 2020 17:47:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <acffe7f9-3265-e999-34ce-30891535897b@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 16:39, Andrew Cooper wrote:
> On 20/04/2020 15:12, Jan Beulich wrote:
>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>> There is no need for the Compat GDT if there are no 32bit PV guests.  This
>>> saves 4k per online CPU
>>>
>>> Bloat-o-meter reports the following savings in Xen itself:
>>>
>>>   add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605)
>>>   Function                                     old     new   delta
>>>   cpu_smpboot_free                            1249    1256      +7
>>>   per_cpu__compat_gdt_l1e                        8       -      -8
>>>   per_cpu__compat_gdt                            8       -      -8
>>>   init_idt_traps                               442     420     -22
>>>   load_system_tables                           414     364     -50
>>>   trap_init                                    444     280    -164
>>>   cpu_smpboot_callback                        1255     991    -264
>>>   boot_compat_gdt                             4096       -   -4096
>>>   Total: Before=3062726, After=3058121, chg -0.15%
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> ---
>>> CC: Jan Beulich <JBeulich@suse.com>
>>> CC: Wei Liu <wl@xen.org>
>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>>
>>> The increase in cpu_smpboot_free() appears to be a consequence of a totally
>>> different layout of basic blocks.
>>> ---
>>>  xen/arch/x86/cpu/common.c |  5 +++--
>>>  xen/arch/x86/desc.c       |  2 ++
>>>  xen/arch/x86/smpboot.c    |  5 ++++-
>>>  xen/arch/x86/traps.c      | 10 +++++++---
>>>  4 files changed, 16 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>> index 1b33f1ed71..7b093cb421 100644
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -752,8 +752,9 @@ void load_system_tables(void)
>>>  
>>>  	_set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss,
>>>  			 sizeof(*tss) - 1, SYS_DESC_tss_avail);
>>> -	_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>>> -			 sizeof(*tss) - 1, SYS_DESC_tss_busy);
>>> +	if ( IS_ENABLED(CONFIG_PV32) )
>>> +		_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>>> +				 sizeof(*tss) - 1, SYS_DESC_tss_busy);
>> Wouldn't this better be "if ( opt_pv32 )"? Also elsewhere then.
> 
> Doing it like this specifically ensures that there is never a case where
> things are half configured.

But this way you set up something in the GDT that's never going
to be used when "pv=no-32". Why leave a TSS accessible that we
don't need?

> I don't think it is wise to suggest that making opt_pv32 runtime
> configurable might work.

I didn't suggest (nor even consider) runtime changing of this
setting. If we wanted, _that_ would be what might require using
code as you have it right now (if we wanted to avoid setting
this up at the time the setting gets flipped from false to true).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 15:51:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 15:51:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQYhv-0006E9-Ea; Mon, 20 Apr 2020 15:51:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=z/8R=6E=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQYhu-0006E4-DV
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 15:51:38 +0000
X-Inumbo-ID: d140ef0c-831e-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d140ef0c-831e-11ea-b4f4-bc764e2007e4;
 Mon, 20 Apr 2020 15:51:37 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BA58EAD49;
 Mon, 20 Apr 2020 15:51:35 +0000 (UTC)
Subject: Re: [PATCH v15 1/3] mem_sharing: don't reset vCPU info page during
 fork reset
To: Tamas K Lengyel <tamas@tklengyel.com>
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <ef0f91fd4c49c623dda09a1774392d2f2a99ae35.1587142844.git.tamas.lengyel@intel.com>
 <20200420074516.GQ28601@Air-de-Roger>
 <CABfawh=Fd+Te7ECcgdxU3GUnBYygDXjFDyRHKAWf75MLZu7KAQ@mail.gmail.com>
 <686dafe9-54f6-3224-d2ff-8cfb99734b2c@suse.com>
 <CABfawh=TdgdaQnwDoAvGyMMY-HyRyqg9T5oyrfadie9_7GZLeg@mail.gmail.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <d7e53215-9fba-a648-1988-88333a53596f@suse.com>
Date: Mon, 20 Apr 2020 17:51:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CABfawh=TdgdaQnwDoAvGyMMY-HyRyqg9T5oyrfadie9_7GZLeg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 16:27, Tamas K Lengyel wrote:
> On Mon, Apr 20, 2020 at 8:19 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 20.04.2020 16:15, Tamas K Lengyel wrote:
>>> On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
>>>>
>>>> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
>>>>> When a forked VM is being reset while having vm_events active, re-copying the
>>>>> vCPU info page can lead to events being lost. This seems to only affect a
>>>>> subset of events (interrupts), while not others (cpuid, MTF, EPT) thus it was
>>>>
>>>> I'm slightly lost by the sentence, is the guest or the hypervisor
>>>> the one losing events?
>>>>
>>>> Ie: interrupts are events from a guest PoV, but cpuid or EPT is not
>>>> something that triggers events that are injected to the guest. I think
>>>> the commit message needs clarification.
>>>
>>> Sorry, what I meant was software interrupts are not triggered anymore,
>>> ie. int3 and it's associated event is not sent to the monitor
>>> application (VM_EVENT_REASON_SOFTWARE_BREAKPOINT).
>>>
>>>>
>>>>> not discovered beforehand. Only copying vCPU info page contents during initial
>>>>> fork fixes the problem.
>>>>
>>>> Hm, I'm not sure I understand why this is causing issues. When you
>>>> reset a fork you should reset the vcpu info page, or else event masks would
>>>> be in a wrong state?
>>>
>>> When we reset a fork we only want to 1) discard any memory allocated
>>> for it 2) reset the vCPU registers. We don't want to reset event
>>> channels or anything else. We have active vm_events on the domain and
>>> the whole point of doing a fork reset is to avoid having to
>>> reinitialize all that as it's quite slow.
>>
>> So for an arbitrary piece of state, what are the criteria to establish
>> whether to copy or re-init them during a fork? Is it really now and
>> forever only memory that wants resetting? I have to admit I'm confused
>> by you also mentioning CPU registers - aren't they to be copied rather
>> than reset?
> 
> Registers are being reset by copying them from the parent. Allocated
> memory is discarded as the memory that's needed for the new execution
> will get copied when EPT faults happen as it's executing. The goal is
> to put the domain back to its initial execution state without having
> to reinitialize vm_events. In our experiments when the forks are
> executed only for a very short period (fuzzing), having to
> reinitialize the vm_event interfaces mean going from ~100 execution/s
> to ~2 executions/s. Unfortunately in the current state the fork
> doesn't generate the required vm_events after the first execution and
> for some reason it only happens for int3 generated events.

Thanks, but I'm afraid this doesn't answer my question regarding the
criteria for what should be put back to the fork's initial state vs
what should be left as is. In fact _anything_ not getting reset to
initial state would seem to need special justification (beyond
performance considerations).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 16:09:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 16:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQYzW-0007pj-47; Mon, 20 Apr 2020 16:09:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=AIDV=6E=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jQYzV-0007pe-3R
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 16:09:49 +0000
X-Inumbo-ID: 5b63b654-8321-11ea-9e09-bc764e2007e4
Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5b63b654-8321-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 16:09:48 +0000 (UTC)
Received: by mail-ed1-x542.google.com with SMTP id k22so3458692eds.6
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 09:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=qEe9v+ERjXK1jlYcwsDG5QMcN4eKzmGnHW9zUzAGG7Q=;
 b=V769VLAuFzKV7+YqoeIQVyaZXpNWXCM6mh8phRUovWFcC5taatOoe/KpvSJmf32Uma
 iRkpt8ogL5NX7WOlWu7u7fp0chkDCXwhajgvMvdAsd+HtIbol7Pt1W9PVhY6/Gcxirdt
 fuTToqELI5YXOQs3Qp/U60DCAxxL0bEChPWK2zVYWCqnau11aug5m7u+rflqFXCXZ9zA
 2iusg/Ctod5w3N/icVboF/gyy7HFn6evylrEElLxemgVhfp2O7IyhNNpsQMLa9URSGHi
 z8jitAjBFbgAqdd1ks+GWPPLEyrCxGuGW4YgRP+cOUMlz6M1PMiUFKXWf0hG636dJLt0
 h0HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=qEe9v+ERjXK1jlYcwsDG5QMcN4eKzmGnHW9zUzAGG7Q=;
 b=slSRF6DpfVxqWqBPRZe349CXsaelK5x4s//aKvH7zw8o/GBlotdAJEIBmNf2pLYRGD
 Y3TH9yHD2SbiZWC96dXEGnnT9tjvYHUkXzUThgh35RdYOgnuPIQJ0fCAAlKy8AGGF36q
 4Y/xwdXOHdSTycPy4GbjG0yZRdqADRSPBnzZXW0aLWimTv2mMY66Uu1pUssC4fRtn2GB
 Zil+5IEH0lLMhauhrHqh4NyQ2nDyc3sYEoa2MOonyZ9ULQcN62g7Xz71zcTFeTVA+g6K
 Te76sGXRAWZ0zYmlwbJ7kyTebIkHoVffexVJgwWKV9JVnOMjVN2PhksF1z7OAQTpy7jv
 C/kg==
X-Gm-Message-State: AGi0PuagVlw+CEGBIFSYW9QAlmiUVPpBDXZTDCQ0gR0qE/DehdU4K7Di
 dsm05WRz7vr+bCtbL1eTD3AciPRrc5E=
X-Google-Smtp-Source: APiQypKldem4IQ0iMW6iSIs3C4uRmhaZvDzHY6WLwsnfpFBjFN9sBJJAA/p/00n1LUkfwk9TieeexA==
X-Received: by 2002:a50:e841:: with SMTP id k1mr14267708edn.245.1587398986846; 
 Mon, 20 Apr 2020 09:09:46 -0700 (PDT)
Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com.
 [209.85.221.49])
 by smtp.gmail.com with ESMTPSA id l7sm189947ejx.82.2020.04.20.09.09.45
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Apr 2020 09:09:45 -0700 (PDT)
Received: by mail-wr1-f49.google.com with SMTP id i10so12856148wrv.10
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 09:09:45 -0700 (PDT)
X-Received: by 2002:adf:f0d2:: with SMTP id x18mr19269206wro.259.1587398985454; 
 Mon, 20 Apr 2020 09:09:45 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <ef0f91fd4c49c623dda09a1774392d2f2a99ae35.1587142844.git.tamas.lengyel@intel.com>
 <20200420074516.GQ28601@Air-de-Roger>
 <CABfawh=Fd+Te7ECcgdxU3GUnBYygDXjFDyRHKAWf75MLZu7KAQ@mail.gmail.com>
 <686dafe9-54f6-3224-d2ff-8cfb99734b2c@suse.com>
 <CABfawh=TdgdaQnwDoAvGyMMY-HyRyqg9T5oyrfadie9_7GZLeg@mail.gmail.com>
 <d7e53215-9fba-a648-1988-88333a53596f@suse.com>
In-Reply-To: <d7e53215-9fba-a648-1988-88333a53596f@suse.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Mon, 20 Apr 2020 10:09:08 -0600
X-Gmail-Original-Message-ID: <CABfawhkKybZJHMxgK0YTbL75WQryijJjBKs=urncqW4cNd62NQ@mail.gmail.com>
Message-ID: <CABfawhkKybZJHMxgK0YTbL75WQryijJjBKs=urncqW4cNd62NQ@mail.gmail.com>
Subject: Re: [PATCH v15 1/3] mem_sharing: don't reset vCPU info page during
 fork reset
To: Jan Beulich <jbeulich@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 20, 2020 at 9:51 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 20.04.2020 16:27, Tamas K Lengyel wrote:
> > On Mon, Apr 20, 2020 at 8:19 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 20.04.2020 16:15, Tamas K Lengyel wrote:
> >>> On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monn=C3=A9 <roger.pau@citri=
x.com> wrote:
> >>>>
> >>>> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
> >>>>> When a forked VM is being reset while having vm_events active, re-c=
opying the
> >>>>> vCPU info page can lead to events being lost. This seems to only af=
fect a
> >>>>> subset of events (interrupts), while not others (cpuid, MTF, EPT) t=
hus it was
> >>>>
> >>>> I'm slightly lost by the sentence, is the guest or the hypervisor
> >>>> the one losing events?
> >>>>
> >>>> Ie: interrupts are events from a guest PoV, but cpuid or EPT is not
> >>>> something that triggers events that are injected to the guest. I thi=
nk
> >>>> the commit message needs clarification.
> >>>
> >>> Sorry, what I meant was software interrupts are not triggered anymore=
,
> >>> ie. int3 and it's associated event is not sent to the monitor
> >>> application (VM_EVENT_REASON_SOFTWARE_BREAKPOINT).
> >>>
> >>>>
> >>>>> not discovered beforehand. Only copying vCPU info page contents dur=
ing initial
> >>>>> fork fixes the problem.
> >>>>
> >>>> Hm, I'm not sure I understand why this is causing issues. When you
> >>>> reset a fork you should reset the vcpu info page, or else event mask=
s would
> >>>> be in a wrong state?
> >>>
> >>> When we reset a fork we only want to 1) discard any memory allocated
> >>> for it 2) reset the vCPU registers. We don't want to reset event
> >>> channels or anything else. We have active vm_events on the domain and
> >>> the whole point of doing a fork reset is to avoid having to
> >>> reinitialize all that as it's quite slow.
> >>
> >> So for an arbitrary piece of state, what are the criteria to establish
> >> whether to copy or re-init them during a fork? Is it really now and
> >> forever only memory that wants resetting? I have to admit I'm confused
> >> by you also mentioning CPU registers - aren't they to be copied rather
> >> than reset?
> >
> > Registers are being reset by copying them from the parent. Allocated
> > memory is discarded as the memory that's needed for the new execution
> > will get copied when EPT faults happen as it's executing. The goal is
> > to put the domain back to its initial execution state without having
> > to reinitialize vm_events. In our experiments when the forks are
> > executed only for a very short period (fuzzing), having to
> > reinitialize the vm_event interfaces mean going from ~100 execution/s
> > to ~2 executions/s. Unfortunately in the current state the fork
> > doesn't generate the required vm_events after the first execution and
> > for some reason it only happens for int3 generated events.
>
> Thanks, but I'm afraid this doesn't answer my question regarding the
> criteria for what should be put back to the fork's initial state vs
> what should be left as is. In fact _anything_ not getting reset to
> initial state would seem to need special justification (beyond
> performance considerations).

>From my PoV everything should be reset as long as it doesn't interfere
with already registered vm_events. The only part that seems to
interfere with the regular flow of events right now is the
vcpu_info_mfn.

I've ran some further tests and seems that when the code that is being
fuzzed is in ring3, int3 events are delivered as expected after a fork
reset. But if the code in question is ring0, then the expected int3 is
not delivered. It could entirely be that in the kernel-mode case the
code takes a detour and the reason we don't see the expected int3 is
not an interference with vm_events directly, rather a crash in the
guest due to the vcpu_info_mfn being reset. In either case, it needs
to be avoided.

Tamas

Tamas


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 17:09:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 17:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQZua-0004Sw-M0; Mon, 20 Apr 2020 17:08:48 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQZuZ-0004Sr-9w
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 17:08:47 +0000
X-Inumbo-ID: 9805e07a-8329-11ea-9081-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9805e07a-8329-11ea-9081-12813bfff9fa;
 Mon, 20 Apr 2020 17:08:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587402526;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=GNY2F0NFC6sGM7lIxG+sAWuDe6O9jnHgOvJP/u9aHAI=;
 b=O6+BPkjzvbAXssvnrM1SkjZJNzJIgf80DH6FB1TGHEtfoAqyM5B+MHdz
 eZ5PlS6N3QyUOw555Ov6rK5dIr9i5cpRZZNTiZFzGVE3y9W3hCyoizy1j
 0kDbRzqqgg+shruLX0ZLPFpWDUciKCm4acdSgigHqbOd+WbwdviHAqnz3 o=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: xsVnqzQmV5FI2h8OaFQVY2KG5TX0yoT9zqvfaGsdjfz3y6b06pUKSXmHK2VRU+jF8YaBphzUhW
 Vs5wTp3srl0B+wz/shhIJejLrMyJF25zDcNsPq0Mkna7gjSOqwKh+UgXm3ayN1+/Khdtbt0N4s
 W9uAOQ6wGA21vASDZCcexUIGsytO5bA/YQOBSzB3OZmK2DWo9dewTkBv0jxTrYYJrPSgcuMd/H
 wKXZELNQzrOV0V5VLH0P6r04HhB0OHglL4xLMSkdCb8InJbQwmUqttWXDBnke0Xw/wv9atEB9P
 Ad4=
X-SBRS: 2.7
X-MesageID: 16269190
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="16269190"
Subject: Re: [PATCH 3/3] x86/pv: Compile out compat_gdt in !CONFIG_PV builds
To: Jan Beulich <jbeulich@suse.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-4-andrew.cooper3@citrix.com>
 <3c8eee8d-c2ce-d262-4056-a5d2c9f843cb@suse.com>
 <acffe7f9-3265-e999-34ce-30891535897b@citrix.com>
 <cb6fcbd0-1b0a-d105-30ce-e0a6215f4904@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <e5a208df-94f0-56e7-e801-06fb0933f02e@citrix.com>
Date: Mon, 20 Apr 2020 18:08:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <cb6fcbd0-1b0a-d105-30ce-e0a6215f4904@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/04/2020 16:47, Jan Beulich wrote:
> On 20.04.2020 16:39, Andrew Cooper wrote:
>> On 20/04/2020 15:12, Jan Beulich wrote:
>>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>>> There is no need for the Compat GDT if there are no 32bit PV guests.  This
>>>> saves 4k per online CPU
>>>>
>>>> Bloat-o-meter reports the following savings in Xen itself:
>>>>
>>>>   add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605)
>>>>   Function                                     old     new   delta
>>>>   cpu_smpboot_free                            1249    1256      +7
>>>>   per_cpu__compat_gdt_l1e                        8       -      -8
>>>>   per_cpu__compat_gdt                            8       -      -8
>>>>   init_idt_traps                               442     420     -22
>>>>   load_system_tables                           414     364     -50
>>>>   trap_init                                    444     280    -164
>>>>   cpu_smpboot_callback                        1255     991    -264
>>>>   boot_compat_gdt                             4096       -   -4096
>>>>   Total: Before=3062726, After=3058121, chg -0.15%
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> ---
>>>> CC: Jan Beulich <JBeulich@suse.com>
>>>> CC: Wei Liu <wl@xen.org>
>>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>>>
>>>> The increase in cpu_smpboot_free() appears to be a consequence of a totally
>>>> different layout of basic blocks.
>>>> ---
>>>>  xen/arch/x86/cpu/common.c |  5 +++--
>>>>  xen/arch/x86/desc.c       |  2 ++
>>>>  xen/arch/x86/smpboot.c    |  5 ++++-
>>>>  xen/arch/x86/traps.c      | 10 +++++++---
>>>>  4 files changed, 16 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>>> index 1b33f1ed71..7b093cb421 100644
>>>> --- a/xen/arch/x86/cpu/common.c
>>>> +++ b/xen/arch/x86/cpu/common.c
>>>> @@ -752,8 +752,9 @@ void load_system_tables(void)
>>>>  
>>>>  	_set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss,
>>>>  			 sizeof(*tss) - 1, SYS_DESC_tss_avail);
>>>> -	_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>>>> -			 sizeof(*tss) - 1, SYS_DESC_tss_busy);
>>>> +	if ( IS_ENABLED(CONFIG_PV32) )
>>>> +		_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>>>> +				 sizeof(*tss) - 1, SYS_DESC_tss_busy);
>>> Wouldn't this better be "if ( opt_pv32 )"? Also elsewhere then.
>> Doing it like this specifically ensures that there is never a case where
>> things are half configured.
> But this way you set up something in the GDT that's never going
> to be used when "pv=no-32". Why leave a TSS accessible that we
> don't need?

Defence in depth.

Having it only partially set up is more likely to fail in a security
relevant way, than having it fully set up.

This particular example is poor.  There is no need to have the TSS in
either GDT after the `ltr` instruction at boot for 64bit, because we
don't task switch, but ISTR you requesting that this stayed as-was for
consistency.  (For 32bit Xen, it was strictly necessary for the #DF task
switch to work.)

However, the other logic, particularly the cached l1e pointing at the
percpu compat_gdt is more liable to go wrong in interesting ways.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 17:21:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 17:21:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQa6J-00064D-Rz; Mon, 20 Apr 2020 17:20:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQa6J-000648-3x
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 17:20:55 +0000
X-Inumbo-ID: 4a21a6b2-832b-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4a21a6b2-832b-11ea-b4f4-bc764e2007e4;
 Mon, 20 Apr 2020 17:20:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Wtln8GHRDrFjI9qICeSHTb5m0mY3Bd2zyxLBp1qD7nY=; b=u1AzQxl08Qt8ZZMu/QjU9VBc+t
 p/SNU3OtLptbLbg7csIXt5BgprTd7ohzpM6m6lQrQp4FJzdOP/hr5ltKvutkZXAHxcfP3rZf2FO4X
 NXfHy+NiK05deVI3+DPdOj9wS4pOB5jgYxchL+vrpAhqgIwfdMAA3F/LiQ6jAElBJ0tE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQa6A-00027d-Uf; Mon, 20 Apr 2020 17:20:46 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQa6A-0003PY-Di; Mon, 20 Apr 2020 17:20:46 +0000
Subject: Re: [PATCH v2 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-2-paul@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <2f69484c-d043-bded-0a88-2587241aaa94@xen.org>
Date: Mon, 20 Apr 2020 18:20:43 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200407173847.1595-2-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 07/04/2020 18:38, Paul Durrant wrote:
> To allow enlightened HVM guests (i.e. those that have PV drivers) to be
> migrated without their co-operation it will be necessary to transfer 'PV'
> state such as event channel state, grant entry state, etc.
> 
> Currently there is a framework (entered via the hvm_save/load() functions)
> that allows a domain's 'HVM' (architectural) state to be transferred but
> 'PV' state is also common with pure PV guests and so this framework is not
> really suitable.
> 
> This patch adds the new public header and low level implementation of a new
> common framework, entered via the domain_save/load() functions. Subsequent
> patches will introduce other parts of the framework, and code that will
> make use of it within the current version of the libxc migration stream.
> 
> This patch also marks the HVM-only framework as deprecated in favour of the
> new framework.
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> ---
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Wei Liu <wl@xen.org>
> Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> Cc: "Roger Pau Monné" <roger.pau@citrix.com>
> 
> v2:
>   - Allow multi-stage save/load to avoid the need to double-buffer
>   - Get rid of the masks and add an 'ignore' flag instead
>   - Create copy function union to preserve const save buffer
>   - Deprecate HVM-only framework
> ---
>   xen/common/Makefile                    |   1 +
>   xen/common/save.c                      | 329 +++++++++++++++++++++++++
>   xen/include/public/arch-arm/hvm/save.h |   5 +
>   xen/include/public/arch-x86/hvm/save.h |   5 +
>   xen/include/public/save.h              |  84 +++++++
>   xen/include/xen/save.h                 | 152 ++++++++++++
>   6 files changed, 576 insertions(+)
>   create mode 100644 xen/common/save.c
>   create mode 100644 xen/include/public/save.h
>   create mode 100644 xen/include/xen/save.h
> 
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index e8cde65370..90553ba5d7 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -37,6 +37,7 @@ obj-y += radix-tree.o
>   obj-y += rbtree.o
>   obj-y += rcupdate.o
>   obj-y += rwlock.o
> +obj-y += save.o
>   obj-y += shutdown.o
>   obj-y += softirq.o
>   obj-y += sort.o
> diff --git a/xen/common/save.c b/xen/common/save.c
> new file mode 100644
> index 0000000000..6cdac3785b
> --- /dev/null
> +++ b/xen/common/save.c
> @@ -0,0 +1,329 @@
> +/*
> + * save.c: Save and restore PV guest state common to all domain types.
> + *
> + * Copyright Amazon.com Inc. or its affiliates.
> + *
> + * 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 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 <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <xen/save.h>
> +
> +union domain_copy_entry {
> +    domain_write_entry write;
> +    domain_read_entry read;
> +};
> +
> +struct domain_context {
> +    bool log;
> +    struct domain_save_descriptor desc;
> +    size_t data_len;

What is data_len?

> +    union domain_copy_entry copy;
> +    void *priv;
> +};
> +
> +static struct {
> +    const char *name;
> +    bool per_vcpu;
> +    domain_save_handler save;
> +    domain_load_handler load;
> +} handlers[DOMAIN_SAVE_CODE_MAX + 1];
> +
> +void __init domain_register_save_type(unsigned int tc, const char *name,
> +                                      bool per_vcpu,
> +                                      domain_save_handler save,
> +                                      domain_load_handler load)
> +{
> +    BUG_ON(tc > ARRAY_SIZE(handlers));
> +
> +    ASSERT(!handlers[tc].save);
> +    ASSERT(!handlers[tc].load);
> +
> +    handlers[tc].name = name;
> +    handlers[tc].per_vcpu = per_vcpu;
> +    handlers[tc].save = save;
> +    handlers[tc].load = load;
> +}
> +
> +int domain_save_begin(struct domain_context *c, unsigned int tc,
> +                      const char *name, const struct vcpu *v, size_t len)
> +{
> +    int rc;
> +
> +    if ( c->log )
> +        gdprintk(XENLOG_INFO, "%pv save: %s (%lu)\n", v, name,
> +                 (unsigned long)len);

How about using %zu rather than a cast here?

> +
> +    BUG_ON(tc != c->desc.typecode);
> +    BUG_ON(v->vcpu_id != c->desc.vcpu_id);

I can't find any answer on my question about this part. I understand the 
code would be buggy if this happen, but is it warrant to crash the host? 
Couldn't you just return an error and continue to run?

> +
> +    ASSERT(!c->data_len);
> +    c->data_len = c->desc.length = len;
> +
> +    rc = c->copy.write(c->priv, &c->desc, sizeof(c->desc));
> +    if ( rc )
> +        return rc;
> +
> +    c->desc.length = 0;

This is confusing, why would you need to reset c->desc.length but not 
the rest of the fields?

> +
> +    return 0;
> +}
> +
> +int domain_save_data(struct domain_context *c, const void *src, size_t len)
> +{
> +    if ( c->desc.length + len > c->data_len )
> +        return -ENOSPC;
> +
> +    c->desc.length += len;
> +
> +    return c->copy.write(c->priv, src, len);
> +}
> +
> +int domain_save_end(struct domain_context *c)
> +{
> +    /*
> +     * If desc.length does not match the length specified in
> +     * domain_save_begin(), there should have been more data.
> +     */
> +    if ( c->desc.length != c->data_len )

This suggests you know in advance the size of the record. I have seen 
some cases where we don't know the size in advance. A good example if 
when saving grants. You know the maximum of grant used by the guest but 
you don't know yet the number of grants used. You might need to walk the 
"list" twice or allocate a temporary buffer. None of them are ideal.

Another example is when saving memory, we may want to compact page 
informations to save space.

This problem is going to be more relevant for LiveUpdate where we need 
to be able to create the stream in a very short amount of time. 
Allocating any temporary buffer and/or walking the list twice is going 
to kill the performance.

I would suggest to consider a different approach where you update the 
record length at the end.

FWIW, this below the current approach for the LU stream (IIRC David sent 
a prototype recently). A record is opened using lu_stream_open_record(), 
you then have two way to add data:
     - lu_stream_append() -> This takes a buffer and write to the stream.
     - lu_stream_reserve() -> Pre-allocate space in the stream and 
return a pointer to the beginning of the reserved region.
     - lu_stream_end_reservation() -> Takes the actual size in parameter 
and update the stream size.
     - lu_stream_close_record() -> Update the header with the total 
length and update the position in the stream.

> +        return -EIO;

I noticed that all the pasding check have been dropped. I still think we 
need implicit padding to harden the code.

> +
> +    c->data_len = 0;
> +
> +    return 0;
> +}
> +
> +int domain_save(struct domain *d, domain_write_entry write, void *priv,
> +                bool dry_run)
> +{
> +    struct domain_context c = {
> +        .copy.write = write,
> +        .priv = priv,
> +        .log = !dry_run,
> +    };
> +    struct domain_save_header h = {
> +        .magic = DOMAIN_SAVE_MAGIC,
> +        .version = DOMAIN_SAVE_VERSION,
> +    };
> +    struct domain_save_header e;
> +    unsigned int i;
> +    int rc;
> +
> +    ASSERT(d != current->domain);
> +
> +    if ( d->is_dying )

I can't find an answer to my question about d->is_dying. What if the 
guest die afterwards? What does protect us against domain_kill()?

[...]

> +int domain_load(struct domain *d, domain_read_entry read, void *priv)
> +{
> +    struct domain_context c = {
> +        .copy.read = read,
> +        .priv = priv,
> +        .log = true,
> +    };
> +    struct domain_save_header h;
> +    int rc;
> +
> +    ASSERT(d != current->domain);
> +
> +    if ( d->is_dying )
> +        return -EINVAL;

Same here.


> diff --git a/xen/include/public/save.h b/xen/include/public/save.h
> new file mode 100644
> index 0000000000..7e5f8752bd
> --- /dev/null
> +++ b/xen/include/public/save.h
> @@ -0,0 +1,84 @@
> +/*
> + * save.h
> + *
> + * Structure definitions for common PV/HVM domain state that is held by
> + * Xen and must be saved along with the domain's memory.
> + *
> + * Copyright Amazon.com Inc. or its affiliates.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __XEN_PUBLIC_SAVE_H__
> +#define __XEN_PUBLIC_SAVE_H__

Does this header need to be exposed outside of Xen and the tools?

> +
> +#include "xen.h"
> +
> +/* Each entry is preceded by a descriptor */
> +struct domain_save_descriptor {
> +    uint16_t typecode;
> +    /*
> +     * Each entry will contain either to global or per-vcpu domain state.
> +     * Entries relating to global state should have zero in this field.
> +     */
> +    uint16_t vcpu_id;
> +    uint32_t flags;
> +    /*
> +     * When restoring state this flag can be set in a descriptor to cause
> +     * its content to be ignored.

Could you give examples where you would want to ignore a descriptor?

> +     *
> +     * NOTE: It is invalid to set this flag for HEADER or END records (see
> +     *       below).
> +     */
> +#define _DOMAIN_SAVE_FLAG_IGNORE 0
> +#define DOMAIN_SAVE_FLAG_IGNORE (1u << _DOMAIN_SAVE_FLAG_IGNORE)
> +
> +    /* Entry length not including this descriptor */
> +    uint64_t length;
> +};
> +
> +/*
> + * Each entry has a type associated with it. DECLARE_DOMAIN_SAVE_TYPE
> + * binds these things together.
> + */
> +#define DECLARE_DOMAIN_SAVE_TYPE(_x, _code, _type) \
> +    struct __DOMAIN_SAVE_TYPE_##_x { char c[_code]; _type t; };
> +
> +#define DOMAIN_SAVE_CODE(_x) \
> +    (sizeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->c))
> +#define DOMAIN_SAVE_TYPE(_x) \
> +    typeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->t)
> +
> +/* Terminating entry */
> +struct domain_save_end {};
> +DECLARE_DOMAIN_SAVE_TYPE(END, 0, struct domain_save_end);
> +
> +#define DOMAIN_SAVE_MAGIC   0x53415645
> +#define DOMAIN_SAVE_VERSION 0x00000001
> +
> +/* Initial entry */
> +struct domain_save_header {
> +    uint32_t magic;             /* Must be DOMAIN_SAVE_MAGIC */
> +    uint32_t version;           /* Save format version */


I haven't seen any answer about xen version here. For the record:

"Let's imagine in 4.14 we introduced a bug in the saving part. This is
solved in 4.15 but somehow the version is not bumped. How would you
differentiate the streams saved by Xen 4.14 so you can still migrate?

If you record the version of Xen in the record automatically, then you
at least have a way to differentiate the two versions."

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 17:26:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 17:26:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQaBX-0006F1-Nf; Mon, 20 Apr 2020 17:26:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQaBW-0006Ew-JZ
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 17:26:18 +0000
X-Inumbo-ID: 0b025aa2-832c-11ea-9086-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0b025aa2-832c-11ea-9086-12813bfff9fa;
 Mon, 20 Apr 2020 17:26:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=SF892JNXVZng8dYTDOBMQ2wLtlLLlDuMWiz/y4bkUH8=; b=UBhOHLilJYznRKNudtY3VYgwBu
 a/oJepqHG7naCLTojnC02V+qlOYbHDRhemnrUBxq4FlzZTak/3ucww6CP7LoddwB5i5bmEA6JYa3L
 42bxX1lPmBBM9auYBvlcngbEM2bJB5RSMs30VhM7Wr9U/j9C5iOH2W6KFLGxY+B2L4VE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQaBP-0002EH-Nn; Mon, 20 Apr 2020 17:26:11 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQaBP-0003ob-GX; Mon, 20 Apr 2020 17:26:11 +0000
Subject: Re: [PATCH v2 2/5] xen/common/domctl: introduce
 XEN_DOMCTL_get/setdomaincontext
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-3-paul@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <f4aa5e9f-4a1c-c02a-1cee-a43591492556@xen.org>
Date: Mon, 20 Apr 2020 18:26:09 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200407173847.1595-3-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 07/04/2020 18:38, Paul Durrant wrote:
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 1ad34c35eb..8ab39acf0c 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -38,7 +38,7 @@
>   #include "hvm/save.h"
>   #include "memory.h"
>   
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000012
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000013
>   
>   /*
>    * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> @@ -1129,6 +1129,44 @@ struct xen_domctl_vuart_op {
>                                    */
>   };
>   
> +/*
> + * Get/Set domain PV context. The same struct xen_domctl_domaincontext

I think you want to update the comments to match the split.

> + * is used for both commands but with slightly different field semantics
> + * as follows:

Reviewed-by: Julien Grall <jgrall@amazon.com>


Cheers,


-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 17:31:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 17:31:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQaGL-00074V-DP; Mon, 20 Apr 2020 17:31:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQaGJ-00074Q-Or
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 17:31:15 +0000
X-Inumbo-ID: bb60ae94-832c-11ea-b4f4-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bb60ae94-832c-11ea-b4f4-bc764e2007e4;
 Mon, 20 Apr 2020 17:31:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587403874;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=F05uyVxwp1JoOAOpYLy8FCYYOpsSUjvQDelW8C5ZJV0=;
 b=NDEQiIQmJjIt9W60KZRUgTLwgMu84/n9Ja8sJsKf7x4phHx50HjInwcD
 ULpuaueckblHzXey/E1/XtKn/ymy10VdkQmT1X8PUTLaZtfHc0sAhsV5+
 ahNRLZD+iLfgG+b7YniwHuh8XN90OjfuWAk7+WXIR5uQRPbbWlSgZu8ya 4=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: oR7G4JNTMS4paASmxqOKN3Z+jn+ViELXowzJJjdiXAYukZRbjZU0mKlEynaE1eSyo34/alwK4I
 592OgIzUi35Nk8nN+PP4SZM71P9wf3XWlBVUTEe9Gu4kAVDElUiZqttccPRvziv8fxYHATBDY1
 Jn4vXVnPVeu3/m4jTTwqQ/q7TiMZFFO43VhAMqz1LUJCbuITLkpI1qMgqNXd4gHy0PANMoYckE
 BjX9M382mQUNfad33HHZeGwFt2tD5zaaWyaXnL8z0/TxtbqkJRYMQtPP/jFrhP4JMPPC3CbnAs
 dKk=
X-SBRS: 2.7
X-MesageID: 15970648
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="15970648"
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
 <20200420134757.GS28601@Air-de-Roger>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <71867ff0-6b4b-0355-d547-8ba7685a89e2@citrix.com>
Date: Mon, 20 Apr 2020 18:31:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200420134757.GS28601@Air-de-Roger>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/04/2020 14:47, Roger Pau Monné wrote:
> On Fri, Apr 17, 2020 at 04:50:02PM +0100, Andrew Cooper wrote:
>> This is the start of some performance and security-hardening improvements,
>> based on the fact that 32bit PV guests are few and far between these days.
>>
>> Ring1 is full or architectural corner cases, such as counting as supervisor
>                 ^ of

Already fixed (I spotted it 30s after posting).

>> from a paging point of view.  This accounts for a substantial performance hit
>> on processors from the last 8 years (adjusting SMEP/SMAP on every privilege
>> transition), and the gap is only going to get bigger with new hardware
>> features.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Wei Liu <wl@xen.org>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>
>> There is a series I can't quite post yet which wants to conditionally turn
>> opt_pv32 off, which is why I've put it straight in in an int8_t form rather
> s/in in/in/

"in in" is legitimate in some cases, despite it looking awkard.   In
this case, the structure is "straight in", separate from "in an int8_t
form".

If this sentence were for inclusion in the commit message, I'd have
probably spent more effort trying to phrase it differently.

>
>> than a straight boolean form.
>> ---
>>  docs/misc/xen-command-line.pandoc | 12 +++++++++++-
>>  xen/arch/x86/Kconfig              | 16 ++++++++++++++++
>>  xen/arch/x86/pv/domain.c          | 35 +++++++++++++++++++++++++++++++++++
>>  xen/arch/x86/setup.c              |  9 +++++++--
>>  xen/include/asm-x86/pv/domain.h   |  6 ++++++
>>  5 files changed, 75 insertions(+), 3 deletions(-)
>>
>> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
>> index acd0b3d994..ee12b0f53f 100644
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -1694,7 +1694,17 @@ The following resources are available:
>>      CDP, one COS will corespond two CBMs other than one with CAT, due to the
>>      sum of CBMs is fixed, that means actual `cos_max` in use will automatically
>>      reduce to half when CDP is enabled.
>> -	
>> +
>> +### pv
>> +    = List of [ 32=<bool> ]
>> +
>> +    Applicability: x86
>> +
>> +Controls for aspects of PV guest support.
>> +
>> +*   The `32` boolean controls whether 32bit PV guests can be created.  It
>> +    defaults to `true`, and is ignored when `CONFIG_PV32` is compiled out.
>> +
>>  ### pv-linear-pt (x86)
>>  > `= <boolean>`
>>  
>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>> index 8149362bde..4c52197de3 100644
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -49,6 +49,22 @@ config PV
>>  
>>  	  If unsure, say Y.
>>  
>> +config PV32
>> +	bool "Support for 32bit PV guests"
>> +	depends on PV
>> +	default y
>> +	---help---
>> +	  The 32bit PV ABI uses Ring1, an area of the x86 architecture which
>> +	  was deprecated and mostly removed in the AMD64 spec.  As a result,
>> +	  it occasionally conflicts with newer x86 hardware features, causing
>> +	  overheads for Xen to maintain backwards compatibility.
>> +
>> +	  People may wish to disable 32bit PV guests for attack surface
>> +	  reduction, or performance reasons.  Backwards compatibility can be
>> +	  provided via the PV Shim mechanism.
>> +
>> +	  If unsure, say Y.
>> +
>>  config PV_LINEAR_PT
>>         bool "Support for PV linear pagetables"
>>         depends on PV
>> diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
>> index 70fae43965..47a0db082f 100644
>> --- a/xen/arch/x86/pv/domain.c
>> +++ b/xen/arch/x86/pv/domain.c
>> @@ -16,6 +16,39 @@
>>  #include <asm/pv/domain.h>
>>  #include <asm/shadow.h>
>>  
>> +#ifdef CONFIG_PV32
>> +int8_t __read_mostly opt_pv32 = -1;
>> +#endif
>> +
>> +static int parse_pv(const char *s)
> __init
>
> With that:
>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks,

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 17:35:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 17:35:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQaJy-0007EH-0S; Mon, 20 Apr 2020 17:35:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQaJw-0007EC-UZ
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 17:35:00 +0000
X-Inumbo-ID: 42467d8a-832d-11ea-9088-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 42467d8a-832d-11ea-9088-12813bfff9fa;
 Mon, 20 Apr 2020 17:34:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tXAQEPqWo7QJj3gcv7v80gUq7a1pBTl1KlwSa5TIyQs=; b=uDkLISDFWu7jkzBiXD7GFK5nTT
 svW5+OUI7i12ida5e2lPNrArX0nUBVef12mwrhIqL75IbBMIytYsIThEiksSSmJBLTcauA8PXhImc
 tcCT2EQ945aNH30T5PPd0QlJj/k/dzQHIIspRZJE69qCkEBNpiW36M4ksdODu30d2DDo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQaJr-0002Ph-GY; Mon, 20 Apr 2020 17:34:55 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQaJr-0004JQ-4Z; Mon, 20 Apr 2020 17:34:55 +0000
Subject: Re: [PATCH v2 4/5] common/domain: add a domain context record for
 shared_info...
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-5-paul@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <7f0821ed-34e8-2a63-aaab-bf781fdfb9e7@xen.org>
Date: Mon, 20 Apr 2020 18:34:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200407173847.1595-5-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 07/04/2020 18:38, Paul Durrant wrote:
> ... and update xen-domctx to dump some information describing the record.
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> ---
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Wei Liu <wl@xen.org>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> 
> v2:
>   - Drop the header change to define a 'Xen' page size and instead use a
>     variable length struct now that the framework makes this is feasible
>   - Guard use of 'has_32bit_shinfo' in common code with CONFIG_COMPAT
> ---
>   tools/misc/xen-domctx.c   | 11 ++++++
>   xen/common/domain.c       | 81 +++++++++++++++++++++++++++++++++++++++
>   xen/include/public/save.h | 10 ++++-
>   3 files changed, 101 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/misc/xen-domctx.c b/tools/misc/xen-domctx.c
> index d663522a8b..a8d3922321 100644
> --- a/tools/misc/xen-domctx.c
> +++ b/tools/misc/xen-domctx.c
> @@ -59,6 +59,16 @@ static void dump_header(struct domain_save_descriptor *desc)
>       off += desc->length;
>   }
>   
> +static void dump_shared_info(struct domain_save_descriptor *desc)
> +{
> +    DOMAIN_SAVE_TYPE(SHARED_INFO) s;
> +    READ(s);
> +    printf("    SHARED_INFO: field_width %u buffer size: %lu\n",
> +           s.field_width, desc->length - sizeof(s));
> +
> +    off += desc->length;
> +}
> +
>   static void dump_end(struct domain_save_descriptor *desc)
>   {
>       DOMAIN_SAVE_TYPE(END) e;
> @@ -125,6 +135,7 @@ int main(int argc, char **argv)
>           switch (desc.typecode)
>           {
>           case DOMAIN_SAVE_CODE(HEADER): dump_header(&desc); break;
> +        case DOMAIN_SAVE_CODE(SHARED_INFO): dump_shared_info(&desc); break;
>           case DOMAIN_SAVE_CODE(END): dump_end(&desc); return 0;
>           default:
>               printf("Unknown type %u: skipping\n", desc.typecode);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 3dcd73f67c..8b72462e07 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -33,6 +33,7 @@
>   #include <xen/xenoprof.h>
>   #include <xen/irq.h>
>   #include <xen/argo.h>
> +#include <xen/save.h>
>   #include <asm/debugger.h>
>   #include <asm/p2m.h>
>   #include <asm/processor.h>
> @@ -1646,6 +1647,86 @@ int continue_hypercall_on_cpu(
>       return 0;
>   }
>   
> +static int save_shared_info(const struct vcpu *v, struct domain_context *c,
> +                            bool dry_run)
> +{
> +    struct domain *d = v->domain;
> +    struct domain_shared_info_context ctxt = {};
> +    size_t hdr_size = offsetof(typeof(ctxt), buffer);
> +    size_t size = hdr_size + PAGE_SIZE;
> +    int rc;
> +
> +    rc = DOMAIN_SAVE_BEGIN(SHARED_INFO, c, v, size);
> +    if ( rc )
> +        return rc;
> +
> +    if ( !dry_run )

NIT: I think the if is not necessary here as you don't skip that much code.

> +        ctxt.field_width =
> +#ifdef CONFIG_COMPAT
> +            has_32bit_shinfo(d) ? 4 :
> +#endif
> +            8;
> +
> +    rc = domain_save_data(c, &ctxt, hdr_size);
> +    if ( rc )
> +        return rc;
> +
> +    rc = domain_save_data(c, d->shared_info, PAGE_SIZE);
> +    if ( rc )
> +        return rc;
> +
> +    return domain_save_end(c);
> +}
> +
> +static int load_shared_info(struct vcpu *v, struct domain_context *c)
> +{
> +    struct domain *d = v->domain;
> +    struct domain_shared_info_context ctxt = {};
> +    size_t hdr_size = offsetof(typeof(ctxt), buffer);
> +    size_t size = hdr_size + PAGE_SIZE;
> +    unsigned int i;
> +    int rc;
> +
> +    rc = DOMAIN_LOAD_BEGIN(SHARED_INFO, c, v, size, true);
> +    if ( rc )
> +        return rc;
> +
> +    rc = domain_load_data(c, &ctxt, hdr_size);
> +    if ( rc )
> +        return rc;
> +
> +    for ( i = 0; i < ARRAY_SIZE(ctxt.pad); i++ )
> +        if ( ctxt.pad[i] )
> +            return -EINVAL;
> +
> +    switch ( ctxt.field_width )
> +    {
> +#ifdef CONFIG_COMPAT
> +    case 4:
> +        d->arch.has_32bit_shinfo = 1;
> +        break;
> +#endif
> +    case 8:
> +#ifdef CONFIG_COMPAT
> +        d->arch.has_32bit_shinfo = 0;
> +#endif
> +        break;
> +
> +    default:
> +        rc = -EINVAL;
> +        break;
> +    }
> +
> +    rc = domain_load_data(c, d->shared_info, PAGE_SIZE);
> +    if ( rc )
> +        return rc;
> +
> +    return domain_load_end(c);
> +}
> +
> +DOMAIN_REGISTER_SAVE_RESTORE(SHARED_INFO, false, save_shared_info,
> +                             load_shared_info);
> +
>   /*
>    * Local variables:
>    * mode: C
> diff --git a/xen/include/public/save.h b/xen/include/public/save.h
> index 7e5f8752bd..ed994a8765 100644
> --- a/xen/include/public/save.h
> +++ b/xen/include/public/save.h
> @@ -79,6 +79,14 @@ struct domain_save_header {
>   };
>   DECLARE_DOMAIN_SAVE_TYPE(HEADER, 1, struct domain_save_header);
>   
> -#define DOMAIN_SAVE_CODE_MAX 1
> +struct domain_shared_info_context {
> +    uint8_t field_width;
> +    uint8_t pad[7];
> +    uint8_t buffer[]; /* Implementation specific size */

I would recommend to use buffer[XEN_FLEX_ARRAY_DIM].

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 17:53:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 17:53:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQabr-0000Wy-MG; Mon, 20 Apr 2020 17:53:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=JPG3=6E=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQabq-0000Wt-Pd
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 17:53:30 +0000
X-Inumbo-ID: d781bed0-832f-11ea-908d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d781bed0-832f-11ea-908d-12813bfff9fa;
 Mon, 20 Apr 2020 17:53:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=zpHY0fpG0EiCbk2zSLSeuKu89TT/u8Imh9O2Yagyy/U=; b=kFfHigYpBYkDfymI6lA93cP7Vo
 hMvG7xKNJo5pMbJ5LfCnCS8Tsi/Qoicj74lRrGaBIi9n7BpWne6ldBzEV6qJGqONVS6TbmypMzXlo
 O0tgvVEuaw8RZFmr+vAtUG20cWwbo0YV6Xg53/u/RXV/2Z5ndqHA4yHYkmEk3zuvrYdo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQabn-0002mN-0b; Mon, 20 Apr 2020 17:53:27 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQabm-0005FW-K8; Mon, 20 Apr 2020 17:53:26 +0000
Subject: Re: [PATCH v2 1/2] x86/HVM: expose VM assist hypercall
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
 <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <1f463b9e-9629-4ba0-3b7f-373b4bcb5b64@xen.org>
Date: Mon, 20 Apr 2020 18:53:24 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 14/04/2020 12:34, Jan Beulich wrote:
> In preparation for the addition of VMASST_TYPE_runstate_update_flag
> commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
> the hypercall for Arm. I consider it not logical that it then isn't also
> exposed to x86 HVM guests (with the same single feature permitted to be
> enabled as Arm has); Linux actually tries to use it afaict.
> 
> Rather than introducing yet another thin wrapper around vm_assist(),
> make that function the main handler, requiring a per-arch
> arch_vm_assist_valid() definition instead.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: Re-work vm_assist() handling/layering at the same time. Also adjust
>      arch_set_info_guest().
> 
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -939,6 +939,9 @@ int arch_set_info_guest(
>           v->arch.dr6 = c(debugreg[6]);
>           v->arch.dr7 = c(debugreg[7]);
>   
> +        if ( v->vcpu_id == 0 )
> +            d->vm_assist = c.nat->vm_assist;
> +
>           hvm_set_info_guest(v);
>           goto out;
>       }
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -128,6 +128,7 @@ static const hypercall_table_t hvm_hyper
>   #ifdef CONFIG_GRANT_TABLE
>       HVM_CALL(grant_table_op),
>   #endif
> +    HYPERCALL(vm_assist),
>       COMPAT_CALL(vcpu_op),
>       HVM_CALL(physdev_op),
>       COMPAT_CALL(xen_version),
> --- a/xen/arch/x86/pv/hypercall.c
> +++ b/xen/arch/x86/pv/hypercall.c
> @@ -57,7 +57,7 @@ const hypercall_table_t pv_hypercall_tab
>   #ifdef CONFIG_GRANT_TABLE
>       COMPAT_CALL(grant_table_op),
>   #endif
> -    COMPAT_CALL(vm_assist),
> +    HYPERCALL(vm_assist),
>       COMPAT_CALL(update_va_mapping_otherdomain),
>       COMPAT_CALL(iret),
>       COMPAT_CALL(vcpu_op),
> --- a/xen/common/compat/kernel.c
> +++ b/xen/common/compat/kernel.c
> @@ -37,11 +37,6 @@ CHECK_TYPE(capabilities_info);
>   
>   CHECK_TYPE(domain_handle);
>   
> -#ifdef COMPAT_VM_ASSIST_VALID
> -#undef VM_ASSIST_VALID
> -#define VM_ASSIST_VALID COMPAT_VM_ASSIST_VALID
> -#endif
> -
>   #define DO(fn) int compat_##fn
>   #define COMPAT
>   
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
>       return rc;
>   }
>   
> -#ifdef VM_ASSIST_VALID
> -long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
> -               unsigned long valid)
> +#ifdef arch_vm_assist_valid

How about naming the function arch_vm_assist_valid_mask?

> +long do_vm_assist(unsigned int cmd, unsigned int type)
>   {
> +    struct domain *currd = current->domain;
> +    const unsigned long valid = arch_vm_assist_valid(currd);
> +
>       if ( type >= BITS_PER_LONG || !test_bit(type, &valid) )
>           return -EINVAL;
>   
>       switch ( cmd )
>       {
>       case VMASST_CMD_enable:
> -        set_bit(type, &p->vm_assist);
> +        set_bit(type, &currd->vm_assist);
>           return 0;
> +
>       case VMASST_CMD_disable:
> -        clear_bit(type, &p->vm_assist);
> +        clear_bit(type, &currd->vm_assist);
>           return 0;
>       }
>   
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -566,13 +566,6 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDL
>       return -ENOSYS;
>   }
>   
> -#ifdef VM_ASSIST_VALID
> -DO(vm_assist)(unsigned int cmd, unsigned int type)
> -{
> -    return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
> -}
> -#endif
> -
>   /*
>    * Local variables:
>    * mode: C
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -195,8 +195,6 @@ extern unsigned long frametable_virt_end
>   #define watchdog_disable() ((void)0)
>   #define watchdog_enable()  ((void)0)
>   
> -#define VM_ASSIST_VALID          (1UL << VMASST_TYPE_runstate_update_flag)
> -
>   #endif /* __ARM_CONFIG_H__ */
>   /*
>    * Local variables:
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -269,6 +269,8 @@ static inline void free_vcpu_guest_conte
>   
>   static inline void arch_vcpu_block(struct vcpu *v) {}
>   
> +#define arch_vm_assist_valid(d) (1UL << VMASST_TYPE_runstate_update_flag)
> +
>   #endif /* __ASM_DOMAIN_H__ */
>   
>   /*
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -309,17 +309,6 @@ extern unsigned long xen_phys_start;
>   #define ARG_XLAT_START(v)        \
>       (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
>   
> -#define NATIVE_VM_ASSIST_VALID   ((1UL << VMASST_TYPE_4gb_segments)        | \
> -                                  (1UL << VMASST_TYPE_4gb_segments_notify) | \
> -                                  (1UL << VMASST_TYPE_writable_pagetables) | \
> -                                  (1UL << VMASST_TYPE_pae_extended_cr3)    | \
> -                                  (1UL << VMASST_TYPE_architectural_iopl)  | \
> -                                  (1UL << VMASST_TYPE_runstate_update_flag)| \
> -                                  (1UL << VMASST_TYPE_m2p_strict))
> -#define VM_ASSIST_VALID          NATIVE_VM_ASSIST_VALID
> -#define COMPAT_VM_ASSIST_VALID   (NATIVE_VM_ASSIST_VALID & \
> -                                  ((1UL << COMPAT_BITS_PER_LONG) - 1))
> -
>   #define ELFSIZE 64
>   
>   #define ARCH_CRASH_SAVE_VMCOREINFO
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -700,6 +700,20 @@ static inline void pv_inject_sw_interrup
>       pv_inject_event(&event);
>   }
>   
> +#define PV_VM_ASSIST_VALID  ((1UL << VMASST_TYPE_4gb_segments)        | \
> +                             (1UL << VMASST_TYPE_4gb_segments_notify) | \
> +                             (1UL << VMASST_TYPE_writable_pagetables) | \
> +                             (1UL << VMASST_TYPE_pae_extended_cr3)    | \
> +                             (1UL << VMASST_TYPE_architectural_iopl)  | \
> +                             (1UL << VMASST_TYPE_runstate_update_flag)| \
> +                             (1UL << VMASST_TYPE_m2p_strict))
> +#define HVM_VM_ASSIST_VALID (1UL << VMASST_TYPE_runstate_update_flag)
> +
> +#define arch_vm_assist_valid(d) \
> +    (is_hvm_domain(d) ? HVM_VM_ASSIST_VALID \
> +                      : is_pv_32bit_domain(d) ? (uint32_t)PV_VM_ASSIST_VALID \

I understand this is matching the current code, however without looking 
at the rest of patch this is not clear why the cast. May I suggest to 
add a comment explaining the rationale?

> +                                              : PV_VM_ASSIST_VALID)
> +
>   #endif /* __ASM_DOMAIN_H__ */
>   
>   /*
> --- a/xen/include/xen/hypercall.h
> +++ b/xen/include/xen/hypercall.h
> @@ -192,8 +192,6 @@ extern int compat_xsm_op(
>   
>   extern int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg);
>   
> -extern int compat_vm_assist(unsigned int cmd, unsigned int type);
> -
>   DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t);
>   extern int compat_multicall(
>       XEN_GUEST_HANDLE_PARAM(multicall_entry_compat_t) call_list,
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -122,8 +122,6 @@ extern void guest_printk(const struct do
>       __attribute__ ((format (printf, 2, 3)));
>   extern void noreturn panic(const char *format, ...)
>       __attribute__ ((format (printf, 1, 2)));
> -extern long vm_assist(struct domain *, unsigned int cmd, unsigned int type,
> -                      unsigned long valid);
>   extern int __printk_ratelimit(int ratelimit_ms, int ratelimit_burst);
>   extern int printk_ratelimit(void);
>   
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 18:06:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 18:06:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQanw-0001Yw-1u; Mon, 20 Apr 2020 18:06:00 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQanu-0001Yr-Fy
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 18:05:58 +0000
X-Inumbo-ID: 9527bc72-8331-11ea-9090-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9527bc72-8331-11ea-9090-12813bfff9fa;
 Mon, 20 Apr 2020 18:05:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587405957;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=s/IklyaZa/hQRtFMHdxIo4fYDsXN+b7ayxeBXoKUNw4=;
 b=YMxDhcSZkSNRCCQi1S/3HMlJyINvqMskhaxn+zTaqvIGtbWgcc+Ulu61
 5fgXRTFuIvhW9pRAZGAC/N1F7nJvRu5r0YotP7Qf4OHlq/Mt8Bc0MJA9O
 os4ATivd3AvD4ecABbSdbLTK/I/KqY/vQ8TfRf5jVFhyHRWxkjCEuUOhE 4=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: GhSzeoTZdqh/6giK/iWNmtZqUJVaWMZzWo1G8b89bhCDv0xfzb9TPzcQYN+7aylDly4Wj5q/vP
 TRkyb9XDu52apeira8P7e3Sz+SOwuAVJfEQMOIVtZ+qmxpr1/4N6zpkocWF9dQIQTzr6QsOUF4
 uuWuzmk1gd0tfI+cDVeGmTOSnYExBZGReUo6FuuL6+GCJy9RQL4HkvxkuGY3tmmYOOldFGMR5+
 IoCcpdSuhXLj77chl1GdLCnsqL9k3VtqPa0hNhy1Rcun7AMcvIBEmG0SYTdlMSgWxLLwbaapLP
 oyU=
X-SBRS: 2.7
X-MesageID: 16272721
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="16272721"
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
To: Jan Beulich <jbeulich@suse.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
 <5dc9dbd9-fbeb-46ef-4d4e-7916c3219bb3@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <4e732f90-1d5f-7ae5-0f02-6b313a381df7@citrix.com>
Date: Mon, 20 Apr 2020 19:05:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5dc9dbd9-fbeb-46ef-4d4e-7916c3219bb3@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/04/2020 15:05, Jan Beulich wrote:
> On 17.04.2020 17:50, Andrew Cooper wrote:
>> This is the start of some performance and security-hardening improvements,
>> based on the fact that 32bit PV guests are few and far between these days.
>>
>> Ring1 is full or architectural corner cases, such as counting as supervisor
> ... full of ...
>
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -1694,7 +1694,17 @@ The following resources are available:
>>      CDP, one COS will corespond two CBMs other than one with CAT, due to the
>>      sum of CBMs is fixed, that means actual `cos_max` in use will automatically
>>      reduce to half when CDP is enabled.
>> -	
>> +
>> +### pv
>> +    = List of [ 32=<bool> ]
>> +
>> +    Applicability: x86
>> +
>> +Controls for aspects of PV guest support.
>> +
>> +*   The `32` boolean controls whether 32bit PV guests can be created.  It
>> +    defaults to `true`, and is ignored when `CONFIG_PV32` is compiled out.
> Rather than ignoring in the way you do, how about ...
>
>> --- a/xen/arch/x86/pv/domain.c
>> +++ b/xen/arch/x86/pv/domain.c
>> @@ -16,6 +16,39 @@
>>  #include <asm/pv/domain.h>
>>  #include <asm/shadow.h>
>>  
>> +#ifdef CONFIG_PV32
>> +int8_t __read_mostly opt_pv32 = -1;
>> +#endif
>> +
>> +static int parse_pv(const char *s)
>> +{
>> +    const char *ss;
>> +    int val, rc = 0;
>> +
>> +    do {
>> +        ss = strchr(s, ',');
>> +        if ( !ss )
>> +            ss = strchr(s, '\0');
>> +
>> +        if ( (val = parse_boolean("32", s, ss)) >= 0 )
>> +        {
>> +#ifdef CONFIG_PV32
>> +            opt_pv32 = val;
>> +#else
>> +            printk(XENLOG_INFO
>> +                   "CONFIG_PV32 disabled - ignoring 'pv=32' setting\n");
>> +#endif
>> +        }
> ... moving the #ifdef ahead of the if(), and the #endif here (may
> want converting to "else if" with a placeholder if(0) for this
> purpose), with the separate printk() dropped?

In this specific case, it would be even more awkward as there is no use
of val outside of the ifdef.

> I'm in particular
> concerned that we may gain a large number of such printk()s over
> time, if we added them in such cases.

The printk() was a bit of an afterthought, but deliberately avoiding the
-EINVAL path was specifically not.

In the case that the user tries to use `pv=no-32` without CONFIG_PV32,
they should see something other than

(XEN) parameter "pv=no-32" unknown!

I don't think overloading the return value is a clever move, because
then every parse function has to take care of ensuring that -EOPNOTSUPP
(or ENODEV?) never clobbers -EINVAL.

We could have a generic helper which looks like:

static inline void ignored_param(const char *cfg, const char *name,
const char *s, const char *ss)
{
    printk(XENLOG_INFO "%s disabled - ignoring '%s=%*.s' setting\n",
cfg, name, s, (int)(ss - s));
}

which at least would keep all the users consistent.

> See parse_iommu_param() for
> how I'd prefer things to look like in the long run.

I'm aware of that, just as you are aware of my specific dislike for the
ifndefs, which make the logic opaque and hard to follow.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 19:09:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 19:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQbmu-0006f7-3h; Mon, 20 Apr 2020 19:09:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQbms-0006ey-18
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 19:08:58 +0000
X-Inumbo-ID: 61d66fea-833a-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 61d66fea-833a-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 19:08:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587409737;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=J1UdN+Z09vl4PeSBpKdcHD5rJLhydkwGDGHiLZBiFto=;
 b=e5T5KY/uSCa/cUqlgRzpuqKh73kIzlpba8LQjEaBNfyO5V02YzPGQYp5
 Az42CCKoSmO0f/6YXrZPHGl91SeHD4YIuIuD9TpMxbG102/8dGnQ1Pcaw
 7ACJsJrNI8BuD1wJ+XX5aGWry0Mz1WFf30laZi86hcACGqJ8n78fR4YMY I=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: dIhjNs5TOxqhISzkCO6/P3I8cozFiAXEwDKOoTTuDVYbg8OcSHw7lQ64I73R3pY20uTR7c98kx
 bLw0FlxsT5RKsMMuHCFD+8YZdEhFL6rhAeXC377MotZqEQK4mXPdjEoUcVw4GvCjzKnk9JjIt7
 pTLemi0p/XseFKKdArwvXNH7DGHt1vk81a1hiROyXaxK400KBAhl29+yvxN5pu9LBjH4MnB36Y
 ZOBV3byptgLouM0TqkVprq7n7uFeK4GCdMSNDgX7VMdErWhhWmmpxGxGW7PKiRiUcf3n8uQMy0
 /1Y=
X-SBRS: 2.7
X-MesageID: 15976207
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="15976207"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86: Enumeration for Control-flow Enforcement Technology
Date: Mon, 20 Apr 2020 20:08:29 +0100
Message-ID: <20200420190829.17874-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The CET spec has been published and guest kernels are starting to get support.
Introduce the CPUID and MSRs, and fully block the MSRs from guest use.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 tools/libxl/libxl_cpuid.c                   | 2 ++
 tools/misc/xen-cpuid.c                      | 3 ++-
 xen/arch/x86/msr.c                          | 6 ++++++
 xen/include/asm-x86/msr-index.h             | 8 ++++++++
 xen/include/public/arch-x86/cpufeatureset.h | 2 ++
 5 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index b4f6fd590d..00262a3f8f 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -201,6 +201,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str)
         {"pku",          0x00000007,  0, CPUID_REG_ECX,  3,  1},
         {"ospke",        0x00000007,  0, CPUID_REG_ECX,  4,  1},
         {"avx512-vbmi2", 0x00000007,  0, CPUID_REG_ECX,  6,  1},
+        {"cet-ss",       0x00000007,  0, CPUID_REG_ECX,  7,  1},
         {"gfni",         0x00000007,  0, CPUID_REG_ECX,  8,  1},
         {"vaes",         0x00000007,  0, CPUID_REG_ECX,  9,  1},
         {"vpclmulqdq",   0x00000007,  0, CPUID_REG_ECX, 10,  1},
@@ -213,6 +214,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str)
         {"avx512-4vnniw",0x00000007,  0, CPUID_REG_EDX,  2,  1},
         {"avx512-4fmaps",0x00000007,  0, CPUID_REG_EDX,  3,  1},
         {"md-clear",     0x00000007,  0, CPUID_REG_EDX, 10,  1},
+        {"cet-ibt",      0x00000007,  0, CPUID_REG_EDX, 20,  1},
         {"ibrsb",        0x00000007,  0, CPUID_REG_EDX, 26,  1},
         {"stibp",        0x00000007,  0, CPUID_REG_EDX, 27,  1},
         {"l1d-flush",    0x00000007,  0, CPUID_REG_EDX, 28,  1},
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 585b530b21..ff36d8cee1 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -123,7 +123,7 @@ static const char *const str_7c0[32] =
     [ 0] = "prefetchwt1",      [ 1] = "avx512_vbmi",
     [ 2] = "umip",             [ 3] = "pku",
     [ 4] = "ospke",            [ 5] = "waitpkg",
-    [ 6] = "avx512_vbmi2",
+    [ 6] = "avx512_vbmi2",     [ 7] = "cet-ss",
     [ 8] = "gfni",             [ 9] = "vaes",
     [10] = "vpclmulqdq",       [11] = "avx512_vnni",
     [12] = "avx512_bitalg",
@@ -163,6 +163,7 @@ static const char *const str_7d0[32] =
     /* 12 */                [13] = "tsx-force-abort",
 
     [18] = "pconfig",
+    [20] = "cet-ibt",
 
     [26] = "ibrsb",         [27] = "stibp",
     [28] = "l1d_flush",     [29] = "arch_caps",
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index b4a1ab0fa6..dcacae58de 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -167,6 +167,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
     case MSR_CORE_CAPABILITIES:
     case MSR_TSX_FORCE_ABORT:
     case MSR_TSX_CTRL:
+    case MSR_U_CET:
+    case MSR_S_CET:
+    case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE:
     case MSR_AMD64_LWP_CFG:
     case MSR_AMD64_LWP_CBADDR:
     case MSR_PPIN_CTL:
@@ -324,6 +327,9 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
     case MSR_TEST_CTRL:
     case MSR_TSX_FORCE_ABORT:
     case MSR_TSX_CTRL:
+    case MSR_U_CET:
+    case MSR_S_CET:
+    case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE:
     case MSR_AMD64_LWP_CFG:
     case MSR_AMD64_LWP_CBADDR:
     case MSR_PPIN_CTL:
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index bb4e601445..85c5f20b76 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -66,6 +66,14 @@
 #define  TSX_CTRL_RTM_DISABLE               (_AC(1, ULL) <<  0)
 #define  TSX_CTRL_CPUID_CLEAR               (_AC(1, ULL) <<  1)
 
+#define MSR_U_CET                           0x000006a0
+#define MSR_S_CET                           0x000006a2
+#define MSR_PL0_SSP                         0x000006a4
+#define MSR_PL1_SSP                         0x000006a5
+#define MSR_PL2_SSP                         0x000006a6
+#define MSR_PL3_SSP                         0x000006a7
+#define MSR_INTERRUPT_SSP_TABLE             0x000006a8
+
 /*
  * Legacy MSR constants in need of cleanup.  No new MSRs below this comment.
  */
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index 295b2b7aa8..c061133282 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -229,6 +229,7 @@ XEN_CPUFEATURE(UMIP,          6*32+ 2) /*S  User Mode Instruction Prevention */
 XEN_CPUFEATURE(PKU,           6*32+ 3) /*H  Protection Keys for Userspace */
 XEN_CPUFEATURE(OSPKE,         6*32+ 4) /*!  OS Protection Keys Enable */
 XEN_CPUFEATURE(AVX512_VBMI2,  6*32+ 6) /*A  Additional AVX-512 Vector Byte Manipulation Instrs */
+XEN_CPUFEATURE(CET_SS,        6*32+ 7) /*   CET - Shadow Stacks */
 XEN_CPUFEATURE(GFNI,          6*32+ 8) /*A  Galois Field Instrs */
 XEN_CPUFEATURE(VAES,          6*32+ 9) /*A  Vector AES Instrs */
 XEN_CPUFEATURE(VPCLMULQDQ,    6*32+10) /*A  Vector Carry-less Multiplication Instrs */
@@ -255,6 +256,7 @@ XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation Single
 XEN_CPUFEATURE(MD_CLEAR,      9*32+10) /*A  VERW clears microarchitectural buffers */
 XEN_CPUFEATURE(TSX_FORCE_ABORT, 9*32+13) /* MSR_TSX_FORCE_ABORT.RTM_ABORT */
 XEN_CPUFEATURE(IBRSB,         9*32+26) /*A  IBRS and IBPB support (used by Intel) */
+XEN_CPUFEATURE(CET_IBT,       6*32+20) /*   CET - Indirect Branch Tracking */
 XEN_CPUFEATURE(STIBP,         9*32+27) /*A  STIBP */
 XEN_CPUFEATURE(L1D_FLUSH,     9*32+28) /*S  MSR_FLUSH_CMD and L1D flush. */
 XEN_CPUFEATURE(ARCH_CAPS,     9*32+29) /*   IA32_ARCH_CAPABILITIES MSR */
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 20 19:26:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 19:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQc3T-0008Mz-Rx; Mon, 20 Apr 2020 19:26:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQc3S-0008Mu-CB
 for xen-devel@lists.xen.org; Mon, 20 Apr 2020 19:26:06 +0000
X-Inumbo-ID: c7008584-833c-11ea-83d8-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c7008584-833c-11ea-83d8-bc764e2007e4;
 Mon, 20 Apr 2020 19:26:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587410766;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=EDcqMXALMDZFs73JCUMqOfAEFSoF6ZFBFx9LXx7DcQ4=;
 b=PG1PjNVfZw/mGF3cBFv2NePs+mfIP3yZgMrQV3zh9MWo2D7+TeXT6pxR
 X2ec59jP7sQF+GRJeip0i5VU8Rg287wUDv8vOdv7m/QDYibKVhgv31xrv
 8JlEb9REiMLamKG+xu4REKDbGnAIxq4Rt2eXojM9xxzOUD8ps5h35bPBH 0=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: reWQRjM2UxYwApXmal+vYP/g+hEi5Q3jury8H5z7azhUbZC//XXDeN3RfuYY/qQhFAEtv+HU2C
 54EauKVtl/jF41dzJNLCDevoE5QJPvtr4w/D+CtFsis7Ccy08vudfn281CfakXFIdypHI7N1kh
 HtIr19tO7NjSNtLCPvndswceRz/23btyNRW+pjqZpwH/FSpuEH9DxhdIv5XIXnnueMlyBKzKT+
 MMo8HKUenClgXfUxWZ9mn1cFHpXA9PsXmKFoaG00LYpB2fTc/HMWN/MD8l2F8vDqAFg5Yjs+oF
 IFQ=
X-SBRS: 2.7
X-MesageID: 16209848
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="16209848"
Subject: Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
To: "Wieczorkiewicz, Pawel" <wipawel@amazon.de>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-3-wipawel@amazon.de>
 <00549997-7633-a8c2-899a-fbc0b5a45541@citrix.com>
 <A2E046DD-9F85-4C54-9FED-BE240AA71E09@amazon.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <5d319ae1-e244-23bb-d3fa-cbabb739c33c@citrix.com>
Date: Mon, 20 Apr 2020 20:26:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <A2E046DD-9F85-4C54-9FED-BE240AA71E09@amazon.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "semelpaul@gmail.com" <semelpaul@gmail.com>, "paul@xen.org" <paul@xen.org>,
 Julien Grall <julien@xen.org>, "Manthey, Norbert" <nmanthey@amazon.de>,
 "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 12:36, Wieczorkiewicz, Pawel wrote:
>> Unfortunately, this comes with collateral damage.
>>
>> # ./xtf-runner hvm64 example
>> Executing 'xl create -p tests/example/test-hvm64-example.cfg'
>> Executing 'xl console test-hvm64-example'
>> Executing 'xl unpause test-hvm64-example'
>> --- Xen Test Framework ---
>>
>> Found Xen: 4.14
>>
>> Environment: HVM 64bit (Long mode 4 levels)
>>
>> Hello World
>>
>> Test result: SUCCESS
>>
>>
>> Combined test results:
>> test-hvm64-example                       CRASH
>>
> I never use xtf-runner script to execute tests. I do it the old fashion way:
>
> # xl create -c test-hvm64-example.cfg
> Parsing config from test-hvm64-example.cfg

I presume you mean hvm64-cpuid here, but...

> Guest cpuid information
>                        Native cpuid:
>                                       00000000:ffffffff -> 0000000d:756e6547:6c65746e:49656e69
>                                                                                                 00000001:ffffffff -> 000306e4:00400800:f7ba2203:1fcbfbff
>                                                                                                                                                           00000002:ffffffff -> 76036301:00f0b2ff:00000000:00ca0000
> 00000003:ffffffff -> 00000000:00000000:00000000:00000000
>                                                           00000004:00000000 -> 7c000121:01c0003f:0000003f:00000000
>                                                                                                                     00000004:00000001 -> 7c000122:01c0003f:0000003f:00000000
>                                                                                                                                                                               00000004:00000002 -> 7c000143:01c0003f:000001ff:00000000
>                                                                                                                                                                                                                                         00000004:00000003 -> 7c000163:04c0003f:00004fff:00000006
>  00000004:00000004 -> 00000000:00000000:00000000:00000000
>                                                            00000005:ffffffff -> 00000040:00000040:00000003:00001120
>                                                                                                                      00000006:ffffffff -> 00000077:00000002:00000009:00000000
>                                                                                                                                                                                00000007:00000000 -> 00000000:00000281:00000000:9c000400
>                                                                                                                                                                                                                                          00000008:ffffffff -> 00000000:00000000:00000000:00000000
>   00000009:ffffffff -> 00000000:00000000:00000000:00000000
>                                                             0000000a:ffffffff -> 07300403:00000000:00000000:00000603
>                                                                                                                       0000000b:ffffffff -> 00000000:00000000:00000000:00000000
>                                                                                                                                                                                 0000000c:ffffffff -> 00000000:00000000:00000000:00000000
>                                                                                                                                                                                                                                           0000000d:00000000 -> 00000007:00000240:00000340:00000000
>    0000000d:00000001 -> 00000001:00000000:00000000:00000000
>                                                              0000000d:00000002 -> 00000100:00000240:00000000:00000000
>                                                                                                                        40000000:ffffffff -> 40000005:566e6558:65584d4d:4d4d566e
>                                                                                                                                                                                  40000001:ffffffff -> 0004000b:00000000:00000000:00000000
>                                                                                                                                                                                                                                            40000002:ffffffff -> 00000001:40000000:00000000:00000000
>     40000003:00000000 -> 00000006:00000000:002625a2:00000001
>                                                               40000003:00000001 -> 57b3c4d2:00030755:ccccc210:ffffffff
>                                                                                                                         40000003:00000002 -> 002625a2:00000000:00000000:00000000
>                                                                                                                                                                                   40000004:00000000 -> 0000001c:00000000:00000ac9:00000000
>                                                                                                                                                                                                                                             40000005:ffffffff -> 00000000:00000000:00000000:00000000
>      40000100:ffffffff -> 00000000:00000000:00000000:00000000
>                                                                80000000:ffffffff -> 80000008:00000000:00000000:00000000
>                                                                                                                          80000001:ffffffff -> 00000000:00000000:00000001:2c100800
>                                                                                                                                                                                    80000002:ffffffff -> 20202020:6e492020:286c6574:58202952
>                                                                                                                                                                                                                                              80000003:ffffffff -> 286e6f65:43202952:45205550:36322d35
>       80000004:ffffffff -> 76203037:20402032:30352e32:007a4847
>                                                                 80000005:ffffffff -> 00000000:00000000:00000000:00000000
>                                                                                                                           80000006:ffffffff -> 00000000:00000000:01006040:00000000
>                                                                                                                                                                                     80000007:ffffffff -> 00000000:00000000:00000000:00000000
>                                                                                                                                                                                                                                               80000008:ffffffff -> 0000302e:00001000:00000000:00000000
>      Test result: SUCCESS

... I have reproduced this locally.

However, I'd argue that this it is a bug in xenconsoled rather than
XTF.  In particular, modifying XTF would result in xenconsoled writing
out the logfile with windows line endings, which surely isn't intended.

>>> ---
>>> common/libc/vsnprintf.c | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
>>> index a49fd30..3202137 100644
>>> --- a/common/libc/vsnprintf.c
>>> +++ b/common/libc/vsnprintf.c
>>> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
>>>         if ( *fmt != '%' )
>>>         {
>>>             PUT(*fmt);
>>> +
>>> +            /*
>>> +             * The '\n' character alone on some terminals is not automatically
>>> +             * converted to LFCR.
>>> +             * The explicit LFCR sequence guarantees proper line by line
>>> +             * formatting in the output.
>>> +             */
>>> +            if ( *fmt == '\n' && str < end )
>>> +                PUT('\r');
>> ... doesn't this end up putting out \n\r ?
> yes, it does

So the one type of line ending which isn't in common use?

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 19:43:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 19:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQcJl-0001el-8Z; Mon, 20 Apr 2020 19:42:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQcJj-0001dr-PW
 for xen-devel@lists.xen.org; Mon, 20 Apr 2020 19:42:55 +0000
X-Inumbo-ID: 207ea634-833f-11ea-90a0-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 207ea634-833f-11ea-90a0-12813bfff9fa;
 Mon, 20 Apr 2020 19:42:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587411774;
 h=subject:from:to:cc:references:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=EcoVDdX2n7iLRgt2kHD8oLc9jomtpflRQLMWHNvAzUA=;
 b=PpfANSy9vGec6RVRW0DS6BrI2UpCeKlAcB0iQBoyVZe5SgiAF9PuJLx1
 PzaITQL555eqyOXRGts78/VUT9hdG9dPoSvPRD1TP6AKS/zi8oEOPth6b
 /MLyZxaF5SYoHrQix35fUDPz+hjBnPmeNEPXxnT4vV4duVijgY3tg/0GU 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: FUBaUWY2mGK5sgaUUeMWdVAUjCgGDdJ6QM6PAmqWSZsHO183G83oVgs3IfQ8ipmJKe2Yqee+tf
 6F0yVfxIWa8qBHO+qh0w9PciqBPRhmmUC66qtMQWUeOfBBH+LuyULHG9taU0qyKDXLZ/rESUcV
 tYTTk0kci8NoPK7lhhHSptCCaelLjg67AXk0tluTMPgZdeeEsxuu2Ix8EERCCQehjVGHKb8WGk
 JKVe6yVOLbGyJumgebNE6Nz5FhiO4Ebt/9QH5tSA2ssO1Ifltwm32HMxsi9pRH5Huvui4aq2mV
 hxo=
X-SBRS: 2.7
X-MesageID: 15947036
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="15947036"
Subject: Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Wieczorkiewicz, Pawel" <wipawel@amazon.de>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-3-wipawel@amazon.de>
 <00549997-7633-a8c2-899a-fbc0b5a45541@citrix.com>
 <A2E046DD-9F85-4C54-9FED-BE240AA71E09@amazon.com>
 <5d319ae1-e244-23bb-d3fa-cbabb739c33c@citrix.com>
Message-ID: <088234e8-16a6-872c-70a3-6b4bd1c3767b@citrix.com>
Date: Mon, 20 Apr 2020 20:42:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5d319ae1-e244-23bb-d3fa-cbabb739c33c@citrix.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "semelpaul@gmail.com" <semelpaul@gmail.com>,
 "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
 Julien Grall <julien@xen.org>, "Manthey, Norbert" <nmanthey@amazon.de>,
 "paul@xen.org" <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/04/2020 20:26, Andrew Cooper wrote:
>>>> ---
>>>> common/libc/vsnprintf.c | 10 ++++++++++
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
>>>> index a49fd30..3202137 100644
>>>> --- a/common/libc/vsnprintf.c
>>>> +++ b/common/libc/vsnprintf.c
>>>> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
>>>>         if ( *fmt != '%' )
>>>>         {
>>>>             PUT(*fmt);
>>>> +
>>>> +            /*
>>>> +             * The '\n' character alone on some terminals is not automatically
>>>> +             * converted to LFCR.
>>>> +             * The explicit LFCR sequence guarantees proper line by line
>>>> +             * formatting in the output.
>>>> +             */
>>>> +            if ( *fmt == '\n' && str < end )
>>>> +                PUT('\r');
>>> ... doesn't this end up putting out \n\r ?
>> yes, it does
> So the one type of line ending which isn't in common use?

Switching this to do \r\n does seem to fix the raw `xl create` problem
you were seeing before, doesn't cause the double newlines as far as
`./xtf-runner` is concerned, and doesn't appear to cause xenconsoled to
write windows file endings.

I'm still a little hesitant to do this unilaterally.  Do we know what
Linux usually emits via the console, because that will get us closer to
whatever people actually test.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 19:55:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 19:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQcVR-0002aq-EH; Mon, 20 Apr 2020 19:55:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQcVP-0002al-WC
 for xen-devel@lists.xen.org; Mon, 20 Apr 2020 19:55:00 +0000
X-Inumbo-ID: d0705316-8340-11ea-9e09-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d0705316-8340-11ea-9e09-bc764e2007e4;
 Mon, 20 Apr 2020 19:54:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587412500;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=5RsXPncjBxSabyQjNXqkTykmnUFEE9yX4j6KmjU0SYo=;
 b=LanEZ2uNA+jPARe3r3oD/cuyGEHN3FAsyHwaGf/5CDbLejv+t/O96ahu
 acSlIcRz8OE9W+vbGnooCxh5xCuH9upGsClkbOFcaXVBssiE9XT32yj3p
 YufwfZ1U7Ybk45o97Zfb4FUz1kngH7YoZGLmrf0SRXWOG4FVJU71zIEn6 s=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: RLNUbVNHPy++YUByN0UYYaZCSODwvajSN/gJC1HMl8lBgxmxVwOISTk+tOrOhwvf6OWA6f6F4D
 zcLWkGSJiNBa9bGjDz82zZ1tO/w29gvHGqyhzSB0c2FVY26iTY+2az1KROE1FkN2vBR2W1lNMC
 TVWN0J9v+oTyuRvDqvISpkG8ivLyE7YcjFwKFfYNdbggCGfZCMrWyDvs9rbnYYMzpldTH2sjgK
 J6wlGdgVm360mMtPhzt8jcXV73a4uX+zvCpjFX7/xoibHnplHi/eRl+XD468NKcMyUYg3xpKy2
 mTU=
X-SBRS: 2.7
X-MesageID: 16211296
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="16211296"
Subject: Re: [XTF 3/4] Enabled serial writing for hvm guests
To: "Wieczorkiewicz, Pawel" <wipawel@amazon.de>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-4-wipawel@amazon.de>
 <501cc157-b260-bca0-2920-f4e3a8a07c1b@citrix.com>
 <987F9723-8B54-4908-8AED-F265C0F7E1AC@amazon.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <1b8db49e-4313-7460-7f88-7e0c6c2ab306@citrix.com>
Date: Mon, 20 Apr 2020 20:54:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <987F9723-8B54-4908-8AED-F265C0F7E1AC@amazon.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "semelpaul@gmail.com" <semelpaul@gmail.com>, "paul@xen.org" <paul@xen.org>,
 Julien Grall <julien@xen.org>, "Manthey, Norbert" <nmanthey@amazon.de>,
 "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16/04/2020 12:44, Wieczorkiewicz, Pawel wrote:
>>> +}
>>> +
>>> static void xen_console_write(const char *buf, size_t len)
>>> {
>>>     hypercall_console_write(buf, len);
>>> @@ -246,7 +253,14 @@ static void xen_console_write(const char *buf, size_t len)
>>> void arch_setup(void)
>>> {
>>>     if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
>>> +    {
>>>         register_console_callback(qemu_console_write);
>>> +    }
>>> +
>>> +    if ( IS_DEFINED(CONFIG_HVM) )
>>> +    {
>>> +        register_console_callback(com1_write);
>> This wires up 0x3f8 even for PVH guests, which I'm guessing isn't
>> intentional?  This should be part of the previous if(), but does beg the
>> question what is wrong with the existing qemu console?
>>
> It turns out that both PVH and HVM guests are PVH ABI compatible,

Correct

> but PVH does not need qemu console.

Its not that.  PVH guests are intended to run without qemu so there is
nothing listening on port 0x12.

> In order to get serial console via qemu working, I always register com1
> handler for both HVM and PVH. Register qemu console only for HVM guests.

> I use the com1 to make qemu write console output to a file via: serial=“file:/tmp/…”


Right, but this is a local configuration issue.

I'm happy to make console selection more flexible, but there is
absolutely no need to two separate IO ports throwing the same text
string at Qemu.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 20:16:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 20:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQcqD-0004Ph-CC; Mon, 20 Apr 2020 20:16:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQcqB-0004Pc-PW
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 20:16:27 +0000
X-Inumbo-ID: cf9b0366-8343-11ea-83d8-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cf9b0366-8343-11ea-83d8-bc764e2007e4;
 Mon, 20 Apr 2020 20:16:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587413786;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=rJtPC9jEQ7HMhkdwEUNWy89ojiD+bLtbYIASQqupK0k=;
 b=Y91Zxz52guWIhUzzPwklz3aym1iMW7hSA9FPIr3bx5yM6u0qHsVVG2v8
 YHzYqauFoyNkVZnLCyedsBFP83l0v9uYema7E9DIWJHMsPEFCzbw/z0Gk
 DEY6ih4oao3Vh2OO1l+hTw7M1MjJM2gF5AuLTan1FFkgiRzMWZFMEtohp s=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: /dOe95GmuvgxQQ4GhwR5PsLp95YmUUW9vYZ/EyeR438RJe+7wjQX2Axj8x41b+wmJNNBTPfR6n
 95mjKbV49J+IxTZUUh1xiODfVxWztr7jZZr090wDIi3rKNeCaTr7KlQ64N2q6Z389+rSfpC0DG
 w+mD0aFVQ19LgyX4HP1SN4FfmG8i8CufUEpvIWFEtq7Ajttzn1uX8jzqZpFhZfL+nYYMgR+ID+
 oRwbJok5fW5yImjg1c/WFXs7meQYKCusM4EGYiTYDVHT8qCySj2va4rUwc9o2UjBc5GeEV6VLa
 Ttw=
X-SBRS: 2.7
X-MesageID: 16212393
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="16212393"
Subject: Re: [PATCH v2 1/2] x86/HVM: expose VM assist hypercall
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
 <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <92aedd0d-fcb0-2c6b-6586-5d859333575d@citrix.com>
Date: Mon, 20 Apr 2020 21:16:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14/04/2020 12:34, Jan Beulich wrote:
> In preparation for the addition of VMASST_TYPE_runstate_update_flag
> commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
> the hypercall for Arm. I consider it not logical that it then isn't also
> exposed to x86 HVM guests (with the same single feature permitted to be
> enabled as Arm has); Linux actually tries to use it afaict.
>
> Rather than introducing yet another thin wrapper around vm_assist(),
> make that function the main handler, requiring a per-arch
> arch_vm_assist_valid() definition instead.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: Re-work vm_assist() handling/layering at the same time. Also adjust
>     arch_set_info_guest().

Much nicer.  Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

However, ...

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
>      return rc;
>  }
>  
> -#ifdef VM_ASSIST_VALID
> -long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
> -               unsigned long valid)
> +#ifdef arch_vm_assist_valid
> +long do_vm_assist(unsigned int cmd, unsigned int type)
>  {
> +    struct domain *currd = current->domain;
> +    const unsigned long valid = arch_vm_assist_valid(currd);
> +
>      if ( type >= BITS_PER_LONG || !test_bit(type, &valid) )
>          return -EINVAL;

As a thought, would it be better to have a guest_bits_per_long()
helper?  This type >= BITS_PER_LONG isn't terribly correct for 32bit
guests, and it would avoid needing the truncation in the arch helper,
which is asymmetric on the ARM side.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 20:16:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 20:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQcqa-0004Qx-Mz; Mon, 20 Apr 2020 20:16:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQcqZ-0004Ql-Be
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 20:16:51 +0000
X-Inumbo-ID: ddfcc4da-8343-11ea-90a5-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ddfcc4da-8343-11ea-90a5-12813bfff9fa;
 Mon, 20 Apr 2020 20:16:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587413810;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=9XsHSpVgplvVQrJBKTgSYyVxLH1WryzAKV3bjpi9r9A=;
 b=em0ysZHoibH8np+JRDi/Lo1yvZPjUI3vbV+y38hy7G7Ogu5TZycgcrdc
 Ykif4kGvjHS0nCht3nOLdu+KrC9/JqmzxkHqpfLY0nOqGbH1H1GbwRq8T
 GwTRzIoK0VxSPb8RqQgILQ86ibwDvt4haB1kxXrjCHHcYvj5m5K11uWiN I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 5KlfpzTaGjUzWPOT65dlL7Y6WTJEUFvOea1IHb3rOvn2o0FsGfEzRDT3iFD0ONEJ1t+7nMbHbi
 663pp4va7LGdFQ16w8xylAXjEwYHFvmKnegfdIEmX9yZqYtNiOkV74YITzScfhPeMDPcZyZIZP
 DkIkXYdm51gw+NpFlNZCz09NU8VaVxu37NgeHV70P2pslWwHe/RhpSL6vVP81LFg7SJxAI/I/3
 RNSLAr6HOhPWCPzMLG4jzyE/ZMIlzZYuNsPsvT+Mpie8d0uvYau1dAoiP82Fy/Q39oAlbSNHch
 b5E=
X-SBRS: 2.7
X-MesageID: 16642379
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="16642379"
Subject: Re: [PATCH v2 2/2] x86: validate VM assist value in
 arch_set_info_guest()
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
 <f46967a9-f55d-63f1-1825-352a122fdd8e@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <eb5a529b-4adb-7307-38a6-f146cbc80c9a@citrix.com>
Date: Mon, 20 Apr 2020 21:16:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <f46967a9-f55d-63f1-1825-352a122fdd8e@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 14/04/2020 12:35, Jan Beulich wrote:
> While I can't spot anything that would go wrong, just like the
> respective hypercall only permits applicable bits to be set, we should
> also do so when loading guest context.
>
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 20:39:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 20:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQdBy-0006I7-Ms; Mon, 20 Apr 2020 20:38:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=WKP3=6E=gmail.com=jaromir.dolecek@srs-us1.protection.inumbo.net>)
 id 1jQdBx-0006I2-9o
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 20:38:57 +0000
X-Inumbo-ID: f4cc390e-8346-11ea-b58d-bc764e2007e4
Received: from mail-vs1-xe33.google.com (unknown [2607:f8b0:4864:20::e33])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f4cc390e-8346-11ea-b58d-bc764e2007e4;
 Mon, 20 Apr 2020 20:38:56 +0000 (UTC)
Received: by mail-vs1-xe33.google.com with SMTP id h30so6547828vsr.5
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 13:38:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=bQALrf3WcH8i6SO2fmMGShb4DZzX8afESIzHnyOClcA=;
 b=Vy1sGPMtxUT2w0bicMiM2oc16xPxx/dg68oqkE08sWMfgk8sNw3aL6Y9cidFwdh6/E
 JQvG9nFyF5WrU+jZaxoIbvFYFFiGHd6OPTR+1DCC8CzPcdBZdd3C2qN7HsJJo1SdmGut
 G/srvqP4rL9Dzb92vT62eqxNTnMuGduK4fhQhqiUH2bozamuST1ccdL8ufktcQ78sAC9
 O6Kzd2ZSZ98RgWLBZSOOucdtrv50+lNppVqAnDVsZYeEcxkhMWxlrvAZn3mar8hC/YNI
 51kz0wzPtKiLmYSYSP+QeFzTNsBcg/DUMcCagX5iHFeNC7qxnyrPPh7r3+K36hHcsk2/
 GMYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=bQALrf3WcH8i6SO2fmMGShb4DZzX8afESIzHnyOClcA=;
 b=q8jFfKWTLBT4oncEQvuNgcBEhXPfd/VNV9CR1OJV5ytpY0bneWNml4/8IyILgmPKKT
 svGTww6z0EHsozRWItLErxsikzITfD2yXri9bi1TVpU0Rv9jB3cJcpKXMLm+cP9fr4Fp
 m+q6i1/DA7qBxF5sVuhxL+46U5kXAETGhdB3cUy6GPQWuoU83OGbiBu2MaUrp3LpAi8p
 HXw2jKWIr5lKJQ+5Lm2HFaiKEQ839SJlCAiPA+RxSGdtW+2Ks6JWx4P/cXm9DNR/TSBk
 L5AHOGSwPUEVaBP9FUR/IdRRxwfp+ZPsG2OciJeRy1nBdU03ahHsnxtWchVYdpezH+Yh
 fb2A==
X-Gm-Message-State: AGi0PuYXoMqfrAmCpRFnE5ATDApIl7shIhYD5wBLCSjMWfT5mft7B988
 31wyy+MwAB4ZTUZNsftOjZa677sglhazfphVdtJsz+7/
X-Google-Smtp-Source: APiQypLgZ6P1Tc5MY6wmwxSX+XvdxtiEZVp38a3PkdijPAJ0wDPEEGmzINyxGpbllRAXVaA3H3YlC1kiVYIdd7KszZs=
X-Received: by 2002:a05:6102:104b:: with SMTP id
 h11mr13286523vsq.182.1587415136054; 
 Mon, 20 Apr 2020 13:38:56 -0700 (PDT)
MIME-Version: 1.0
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
Date: Mon, 20 Apr 2020 22:38:45 +0200
Message-ID: <CAMnsW57Kn05TyDiVmZLaiYBdVZwy_7LazvLvR_AG0KHEYJ-z0Q@mail.gmail.com>
Subject: grant_table_op v2 support for HVM?
To: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hello,

I'm working on NetBSD Xen support.

Recently, we've switched to grant version 2 mainly for the improved
status handling, and eventually for copy-only subpage grant support,
which I'd like to experiment with in our netback driver. Currently we
don't need the 64-bit frame, which I found was reason to Linux was
switched over to v2 a while ago.

However, later found out that HVM doesn't actually seem to support the
GNTTABOP_get_status_frames hypercall, so had to fall back to v1 for
HVM. Code in xen/arch/x86/hvm/hypercall.c, which doesn't have any
handling in GNTTABOP_get_status_frames neither in Xen 4.11/4.12/4.13.

Can you advise which version should be used by Dom0/DomU kernels?

Is there some way to still use v2 with HVM? Possibly instead of using
the status frames, still use the old cmpxchg16 method on hdr.flags,
but as I understand hdr.flags is not used for GTF_reading and
GTF_writing in v2. I also see the set_version and get_version calls
are still supported even for HVM.

Understandably, we'd prefer to use same version for PV and HVM kernels.

Thanks.

Jaromir


From xen-devel-bounces@lists.xenproject.org Mon Apr 20 20:56:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Apr 2020 20:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQdSt-0007zU-9e; Mon, 20 Apr 2020 20:56:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=61/n=6E=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQdSr-0007zP-Eb
 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 20:56:25 +0000
X-Inumbo-ID: 6436127c-8349-11ea-90a7-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6436127c-8349-11ea-90a7-12813bfff9fa;
 Mon, 20 Apr 2020 20:56:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587416184;
 h=subject:to:references:from:message-id:date:mime-version:
 in-reply-to:content-transfer-encoding;
 bh=S79DiUrKjSp1OJp5zwKtvZ9/QIdrrycRZwpzUvspEZQ=;
 b=ac9ybHvnMw7XQk0imqcC5euQHCfn3hYUEkJqDO403GnpoNgWSsACMA0s
 aSjMHDQU8ciopbe0U+3IGBp8arP4bUjOhg0IJxo7lp+fgrqqpnu3F+X5l
 wlKleMjNkUAJYjLbEWzkFcvYmIkdfoFyKyq2OgLn3Vplg9Q4vxq6LDIML Y=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: HqOEGo02meEOmgaCm+X4kUt7Cg/diRW0NQQP4R8ASdqiSyQOYiJbOpG2+AN3b7+O7FkZwl6lvg
 +Av8g210jiJmCYr01qz0sLRNJEE4pds6kZP/NUzh8fQ3zMV8SZja+8yItS5Qyq4WG98xVfg031
 MnmlhUHifdMS3qlEV3BCo/gyYPtu/2hEt7r7pIMtJk5qN23th0tOkPnaI/6JbrFePPLxapmbq7
 Nysh5/xbPlaVv7uk7fVeJ7HXHs8NTOMrUO6YqxmjLytghf6OpW/rNbEkqI+lwswNTanGUkMJ9Y
 oEQ=
X-SBRS: 2.7
X-MesageID: 15981285
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,407,1580792400"; d="scan'208";a="15981285"
Subject: Re: grant_table_op v2 support for HVM?
To: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>,
 <xen-devel@lists.xenproject.org>
References: <CAMnsW57Kn05TyDiVmZLaiYBdVZwy_7LazvLvR_AG0KHEYJ-z0Q@mail.gmail.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <a8245dcc-cb91-f3d2-f0a2-135efd137370@citrix.com>
Date: Mon, 20 Apr 2020 21:56:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAMnsW57Kn05TyDiVmZLaiYBdVZwy_7LazvLvR_AG0KHEYJ-z0Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/04/2020 21:38, Jaromír Doleček wrote:
> Hello,
>
> I'm working on NetBSD Xen support.
>
> Recently, we've switched to grant version 2 mainly for the improved
> status handling,

Really?  The status handling is certainly different, but v2 is much
harder to use correctly.

>  and eventually for copy-only subpage grant support,
> which I'd like to experiment with in our netback driver. Currently we
> don't need the 64-bit frame, which I found was reason to Linux was
> switched over to v2 a while ago.
>
> However, later found out that HVM doesn't actually seem to support the
> GNTTABOP_get_status_frames hypercall, so had to fall back to v1 for
> HVM. Code in xen/arch/x86/hvm/hypercall.c, which doesn't have any
> handling in GNTTABOP_get_status_frames neither in Xen 4.11/4.12/4.13.
>
> Can you advise which version should be used by Dom0/DomU kernels?
>
> Is there some way to still use v2 with HVM? Possibly instead of using
> the status frames, still use the old cmpxchg16 method on hdr.flags,
> but as I understand hdr.flags is not used for GTF_reading and
> GTF_writing in v2. I also see the set_version and get_version calls
> are still supported even for HVM.
>
> Understandably, we'd prefer to use same version for PV and HVM kernels.

Like many things, PV and HVM are different.

For PV, the guest creates the mapping.  You've got to ask Xen for the
list of MFNs, so you can create a PTE pointing at them.

For HVM, you've got to decide were you'd like the frames in your guest
physical space, and ask Xen to make the adjustment.

You want add_to_physmap(), requesting XENMAPSPACE_grant_table and or-ing
XENMAPIDX_grant_table_status into the index.  (Because a new
XENMAPSPACE_grant_status apparently wasn't the most logical way to
extend the existing interface.)

i.e. duplicate the existing grant frame logic, picking a second set of
gfns, and tweaking the index input.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 05:11:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 05:11:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQlB9-0003Hg-CM; Tue, 21 Apr 2020 05:10:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=N3RI=6F=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jQlB7-0003Ha-Rx
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 05:10:37 +0000
X-Inumbo-ID: 6f47dd22-838e-11ea-83d8-bc764e2007e4
Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6f47dd22-838e-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 05:10:36 +0000 (UTC)
Received: by mail-ej1-x642.google.com with SMTP id gr25so9967418ejb.10
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 22:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=Ahl719VdLrqEkLxbHehMoqTOI51NEmagjMQ89jY7A6w=;
 b=ODYjVXyvzD+D2Un8S07Ed/yk1M6L5FhBDMInxcU53h10wlEVrkVotnfOCe4Ug6hGh8
 qeUKmh6b1GJDpcXBpEfZkkGnCAUn+jajfG8xPu5P71ebgw8yWlFnarScifJkBZKwU2Fz
 oVEj82dua/HkzWTs+xiIEztddtTM5it4MaLw9KqrJnIpnsy/KwQqXp/bC7agogfDKuJ3
 6uudW9vEzjubWRhepCSGiWhMZuGgzVwdcSEfeyeLJYMluaXT4qz/Grdl3SOTaQnHfQ9l
 1xZ4oqnioBoBdsSm1kHw46DdYiXYOkKfUsS78rfkE5ukSSSzJaYj4L7JBwGqjq12ImsI
 h0NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=Ahl719VdLrqEkLxbHehMoqTOI51NEmagjMQ89jY7A6w=;
 b=i8xlRVf185k/9F8Y0jCN6g7RZ05MSL4hZQpCJHmmgiHn64sQ+tHQjBH5UinmvXSlA4
 7WFVdKmBtEjjh6zJKAldzaZs4H6l5zIR5V1GeOOb3xeDXuUthhndTWsJjlLCKjafe4tf
 Gt406ToHwZ6B5Q0dzRZ1Rmk0SCEmuuAxakYZqFD2BLjEju3lZ+412Lb2kXd5BjXAQJr5
 umQQ801q6pCBG8k7QvEOWDR3IVDRpeOFii+Qr+QU2CHYk7gBlmAaf9M54+eEuKojEswR
 OwemLeWVLcGInuk6H8qvnw1ydaT/inW7hIHmYZ0YJ8KOG+hIrjZvxBMuwpnKBVtmGA3x
 jpDw==
X-Gm-Message-State: AGi0PuaklNhlw3xcyrPmOFwSijxKGicBFc7HQG1E4gL1y+FvaEenDiia
 kqngsGudZqE5iQOGt6ZJ1F92iX4c5x8=
X-Google-Smtp-Source: APiQypKUX/bQQL0MiQgNqYnxCHF9JYwSwzM3cyfOfrcLz9CQTYpJUdnVsx4EmvcZiYvJ7oVZfzgdiQ==
X-Received: by 2002:a17:906:46da:: with SMTP id
 k26mr19946096ejs.106.1587445835643; 
 Mon, 20 Apr 2020 22:10:35 -0700 (PDT)
Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com.
 [209.85.128.50])
 by smtp.gmail.com with ESMTPSA id w9sm358723ejn.54.2020.04.20.22.10.34
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Apr 2020 22:10:34 -0700 (PDT)
Received: by mail-wm1-f50.google.com with SMTP id x25so2074480wmc.0
 for <xen-devel@lists.xenproject.org>; Mon, 20 Apr 2020 22:10:34 -0700 (PDT)
X-Received: by 2002:a05:600c:220c:: with SMTP id
 z12mr2857152wml.84.1587445834173; 
 Mon, 20 Apr 2020 22:10:34 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <ef0f91fd4c49c623dda09a1774392d2f2a99ae35.1587142844.git.tamas.lengyel@intel.com>
 <20200420074516.GQ28601@Air-de-Roger>
 <CABfawh=Fd+Te7ECcgdxU3GUnBYygDXjFDyRHKAWf75MLZu7KAQ@mail.gmail.com>
 <686dafe9-54f6-3224-d2ff-8cfb99734b2c@suse.com>
 <CABfawh=TdgdaQnwDoAvGyMMY-HyRyqg9T5oyrfadie9_7GZLeg@mail.gmail.com>
 <d7e53215-9fba-a648-1988-88333a53596f@suse.com>
 <CABfawhkKybZJHMxgK0YTbL75WQryijJjBKs=urncqW4cNd62NQ@mail.gmail.com>
In-Reply-To: <CABfawhkKybZJHMxgK0YTbL75WQryijJjBKs=urncqW4cNd62NQ@mail.gmail.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Mon, 20 Apr 2020 23:09:57 -0600
X-Gmail-Original-Message-ID: <CABfawhk_TTEXhWAT3iMDiARSh=UT3bKh=DZj4LEsdci-3cDuzw@mail.gmail.com>
Message-ID: <CABfawhk_TTEXhWAT3iMDiARSh=UT3bKh=DZj4LEsdci-3cDuzw@mail.gmail.com>
Subject: Re: [PATCH v15 1/3] mem_sharing: don't reset vCPU info page during
 fork reset
To: Jan Beulich <jbeulich@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 20, 2020 at 10:09 AM Tamas K Lengyel <tamas@tklengyel.com> wrot=
e:
>
> On Mon, Apr 20, 2020 at 9:51 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 20.04.2020 16:27, Tamas K Lengyel wrote:
> > > On Mon, Apr 20, 2020 at 8:19 AM Jan Beulich <jbeulich@suse.com> wrote=
:
> > >>
> > >> On 20.04.2020 16:15, Tamas K Lengyel wrote:
> > >>> On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monn=C3=A9 <roger.pau@cit=
rix.com> wrote:
> > >>>>
> > >>>> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
> > >>>>> When a forked VM is being reset while having vm_events active, re=
-copying the
> > >>>>> vCPU info page can lead to events being lost. This seems to only =
affect a
> > >>>>> subset of events (interrupts), while not others (cpuid, MTF, EPT)=
 thus it was
> > >>>>
> > >>>> I'm slightly lost by the sentence, is the guest or the hypervisor
> > >>>> the one losing events?
> > >>>>
> > >>>> Ie: interrupts are events from a guest PoV, but cpuid or EPT is no=
t
> > >>>> something that triggers events that are injected to the guest. I t=
hink
> > >>>> the commit message needs clarification.
> > >>>
> > >>> Sorry, what I meant was software interrupts are not triggered anymo=
re,
> > >>> ie. int3 and it's associated event is not sent to the monitor
> > >>> application (VM_EVENT_REASON_SOFTWARE_BREAKPOINT).
> > >>>
> > >>>>
> > >>>>> not discovered beforehand. Only copying vCPU info page contents d=
uring initial
> > >>>>> fork fixes the problem.
> > >>>>
> > >>>> Hm, I'm not sure I understand why this is causing issues. When you
> > >>>> reset a fork you should reset the vcpu info page, or else event ma=
sks would
> > >>>> be in a wrong state?
> > >>>
> > >>> When we reset a fork we only want to 1) discard any memory allocate=
d
> > >>> for it 2) reset the vCPU registers. We don't want to reset event
> > >>> channels or anything else. We have active vm_events on the domain a=
nd
> > >>> the whole point of doing a fork reset is to avoid having to
> > >>> reinitialize all that as it's quite slow.
> > >>
> > >> So for an arbitrary piece of state, what are the criteria to establi=
sh
> > >> whether to copy or re-init them during a fork? Is it really now and
> > >> forever only memory that wants resetting? I have to admit I'm confus=
ed
> > >> by you also mentioning CPU registers - aren't they to be copied rath=
er
> > >> than reset?
> > >
> > > Registers are being reset by copying them from the parent. Allocated
> > > memory is discarded as the memory that's needed for the new execution
> > > will get copied when EPT faults happen as it's executing. The goal is
> > > to put the domain back to its initial execution state without having
> > > to reinitialize vm_events. In our experiments when the forks are
> > > executed only for a very short period (fuzzing), having to
> > > reinitialize the vm_event interfaces mean going from ~100 execution/s
> > > to ~2 executions/s. Unfortunately in the current state the fork
> > > doesn't generate the required vm_events after the first execution and
> > > for some reason it only happens for int3 generated events.
> >
> > Thanks, but I'm afraid this doesn't answer my question regarding the
> > criteria for what should be put back to the fork's initial state vs
> > what should be left as is. In fact _anything_ not getting reset to
> > initial state would seem to need special justification (beyond
> > performance considerations).
>
> From my PoV everything should be reset as long as it doesn't interfere
> with already registered vm_events. The only part that seems to
> interfere with the regular flow of events right now is the
> vcpu_info_mfn.

Alright, I figured out what's really happening here. During fork reset
we iterate over all pages belonging to the fork, releasing all pages
that pass p2m_is_sharable(p2mt) check. Unfortunately the vcpu info
pages also pass this check. Because of that the pages are removed from
the p2m but remain mapped to the vcpu structs. No wonder this was
causing all sorts of weirdness, if the guest tries to access the vcpu
info pages it would cause endless pagefaults, which would manifest as
events no longer appearing as expected (in this case the int3 event).
Re-copying the vcpu info page's content from the parent is perfectly
fine during reset, that causes no issues if the pages remain in the
p2m. I'll be sending a different patch that fixes this bug and with a
better commit message.

Tamas


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 05:31:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 05:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQlVh-00051y-8F; Tue, 21 Apr 2020 05:31:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=twDm=6F=xen.org=tim@srs-us1.protection.inumbo.net>)
 id 1jQlVg-00051t-Ef
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 05:31:52 +0000
X-Inumbo-ID: 66f1941c-8391-11ea-b4f4-bc764e2007e4
Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 66f1941c-8391-11ea-b4f4-bc764e2007e4;
 Tue, 21 Apr 2020 05:31:51 +0000 (UTC)
Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD))
 (envelope-from <tim@xen.org>)
 id 1jQlVb-0007iE-JA; Tue, 21 Apr 2020 05:31:47 +0000
Date: Tue, 21 Apr 2020 06:31:47 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 07/10] x86/shadow: the guess_wrmap() hook is needed for
 HVM only
Message-ID: <20200421053147.GA29592@deinos.phlegethon.org>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
 <1e221192-7899-b60d-0280-b77ab5877772@suse.com>
 <20200418090317.GD92478@deinos.phlegethon.org>
 <43a8e15c-e739-0cb3-4ad9-23def4e24709@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <43a8e15c-e739-0cb3-4ad9-23def4e24709@suse.com>
User-Agent: Mutt/1.11.1 (2018-12-01)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
 SAEximRunCond expanded to false
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

At 15:06 +0200 on 20 Apr (1587395210), Jan Beulich wrote:
> On 18.04.2020 11:03, Tim Deegan wrote:
> > At 16:28 +0200 on 17 Apr (1587140897), Jan Beulich wrote:
> >> sh_remove_write_access() bails early for !external guests, and hence its
> >> building and thus the need for the hook can be suppressed altogether in
> >> !HVM configs.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> >> @@ -366,6 +367,14 @@ int sh_validate_guest_entry(struct vcpu
> >>  extern int sh_remove_write_access(struct domain *d, mfn_t readonly_mfn,
> >>                                    unsigned int level,
> >>                                    unsigned long fault_addr);
> >> +#else
> >> +static inline int sh_remove_write_access(struct domain *d, mfn_t readonly_mfn,
> >> +                                         unsigned int level,
> >> +                                         unsigned long fault_addr)
> >> +{
> > 
> > Can we have an ASSERT(!shadow_mode_refcounts(d)) here, please,
> > matching the check that would have made it a noop before?
> 
> I've added one, but I find this quite odd in a !HVM build, where
> 
> #define PG_refcounts   0
> 
> and
> 
> #define paging_mode_refcounts(_d) (!!((_d)->arch.paging.mode & PG_refcounts))
> 
> Perhaps you're wanting this mainly for documentation purposes?


Yeah, that and future-proofing.  If !HVM builds ever start using
paging_mode_refcounts then this assertion will forcibly remind us that
we need changes here.  I'm glad that it compiles away to nothing in
the meantime.

Cheers,

Tim.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 05:43:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 05:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQlgi-0005yp-BY; Tue, 21 Apr 2020 05:43:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQlgg-0005yk-SX
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 05:43:14 +0000
X-Inumbo-ID: fd431552-8392-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fd431552-8392-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 05:43:13 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1A5EFAAC7;
 Tue, 21 Apr 2020 05:43:10 +0000 (UTC)
Subject: Re: [PATCH v2 1/2] x86/HVM: expose VM assist hypercall
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
 <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
 <92aedd0d-fcb0-2c6b-6586-5d859333575d@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <c449baf8-d3e0-53d4-4f9e-5552527b0701@suse.com>
Date: Tue, 21 Apr 2020 07:43:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <92aedd0d-fcb0-2c6b-6586-5d859333575d@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 22:16, Andrew Cooper wrote:
> On 14/04/2020 12:34, Jan Beulich wrote:
>> In preparation for the addition of VMASST_TYPE_runstate_update_flag
>> commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
>> the hypercall for Arm. I consider it not logical that it then isn't also
>> exposed to x86 HVM guests (with the same single feature permitted to be
>> enabled as Arm has); Linux actually tries to use it afaict.
>>
>> Rather than introducing yet another thin wrapper around vm_assist(),
>> make that function the main handler, requiring a per-arch
>> arch_vm_assist_valid() definition instead.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> v2: Re-work vm_assist() handling/layering at the same time. Also adjust
>>     arch_set_info_guest().
> 
> Much nicer.  Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

> However, ...
> 
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
>>      return rc;
>>  }
>>  
>> -#ifdef VM_ASSIST_VALID
>> -long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
>> -               unsigned long valid)
>> +#ifdef arch_vm_assist_valid
>> +long do_vm_assist(unsigned int cmd, unsigned int type)
>>  {
>> +    struct domain *currd = current->domain;
>> +    const unsigned long valid = arch_vm_assist_valid(currd);
>> +
>>      if ( type >= BITS_PER_LONG || !test_bit(type, &valid) )
>>          return -EINVAL;
> 
> As a thought, would it be better to have a guest_bits_per_long()
> helper?  This type >= BITS_PER_LONG isn't terribly correct for 32bit
> guests, and it would avoid needing the truncation in the arch helper,
> which is asymmetric on the ARM side.

I'd rather not - the concept of guest bitness is already fuzzy
enough for HVM (see our 32-bit shared info latching), and
introducing a generic predicate like you suggest would invite
for use of it in places where people may forget how fuzzy the
concept is.

I also don't view the BITS_PER_LONG check here as pertaining
to a guest property - all we want is to bound the test_bit().
There's nothing wrong to, in the future, define bits beyond
possible guest bitness. It's merely a "helps for now" that on
x86 we've decided to put the 1st 64-bit only assist bit in
the high 32 bits (it may well be that this was added back
when we still had 32-bit support for Xen itself).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 05:54:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 05:54:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQlrv-0006uQ-G7; Tue, 21 Apr 2020 05:54:51 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQlru-0006uK-3U
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 05:54:50 +0000
X-Inumbo-ID: 9c5903b2-8394-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9c5903b2-8394-11ea-b4f4-bc764e2007e4;
 Tue, 21 Apr 2020 05:54:49 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 30384AA55;
 Tue, 21 Apr 2020 05:54:47 +0000 (UTC)
Subject: Re: [PATCH v2 1/2] x86/HVM: expose VM assist hypercall
To: Julien Grall <julien@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
 <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
 <1f463b9e-9629-4ba0-3b7f-373b4bcb5b64@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <5863d6d0-22cf-7237-a88b-a3a2c4809635@suse.com>
Date: Tue, 21 Apr 2020 07:54:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1f463b9e-9629-4ba0-3b7f-373b4bcb5b64@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 19:53, Julien Grall wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
>>       return rc;
>>   }
>>   -#ifdef VM_ASSIST_VALID
>> -long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
>> -               unsigned long valid)
>> +#ifdef arch_vm_assist_valid
> 
> How about naming the function arch_vm_assist_valid_mask?

Certainly a possibility, albeit to me the gain would be marginal
and possibly not outweigh the growth in length. Andrew, any
preference?

>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -700,6 +700,20 @@ static inline void pv_inject_sw_interrup
>>     pv_inject_event(&event);
>> }
>> +#define PV_VM_ASSIST_VALID  ((1UL << VMASST_TYPE_4gb_segments)        | \
>> +                             (1UL << VMASST_TYPE_4gb_segments_notify) | \
>> +                             (1UL << VMASST_TYPE_writable_pagetables) | \
>> +                             (1UL << VMASST_TYPE_pae_extended_cr3)    | \
>> +                             (1UL << VMASST_TYPE_architectural_iopl)  | \
>> +                             (1UL << VMASST_TYPE_runstate_update_flag)| \
>> +                             (1UL << VMASST_TYPE_m2p_strict))
>> +#define HVM_VM_ASSIST_VALID (1UL << VMASST_TYPE_runstate_update_flag)
>> +
>> +#define arch_vm_assist_valid(d) \
>> +    (is_hvm_domain(d) ? HVM_VM_ASSIST_VALID \
>> +                      : is_pv_32bit_domain(d) ? (uint32_t)PV_VM_ASSIST_VALID \
> 
> I understand this is matching the current code, however without
> looking at the rest of patch this is not clear why the cast. May
> I suggest to add a comment explaining the rationale?

Hmm, I can state that the rationale is history. Many of the assists in
the low 32 bits are for 32-bit guests only. But we can't start refusing
a 64-bit kernel requesting them. The ones in the high 32 bits are, for
now, applicable to 64-bit guests only, and have always been refused for
32-bit ones.

Imo if anything an explanation on where new bits should be put should
go next to the VMASST_TYPE_* definitions in the public header, yet then
again the public headers aren't (imo) a good place to put
implementation detail comments.

Again, Andrew - since you've ack-ed the patch already, any thoughts
here either way?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 06:02:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 06:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQlza-0007s5-Bl; Tue, 21 Apr 2020 06:02:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQlzZ-0007s0-3y
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 06:02:45 +0000
X-Inumbo-ID: b52ead3c-8395-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b52ead3c-8395-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 06:02:40 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B733CAC53;
 Tue, 21 Apr 2020 06:02:38 +0000 (UTC)
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
 <5dc9dbd9-fbeb-46ef-4d4e-7916c3219bb3@suse.com>
 <4e732f90-1d5f-7ae5-0f02-6b313a381df7@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6b4e5b50-51f7-566f-2a18-4bb5f4f43d59@suse.com>
Date: Tue, 21 Apr 2020 08:02:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <4e732f90-1d5f-7ae5-0f02-6b313a381df7@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 20:05, Andrew Cooper wrote:
> On 20/04/2020 15:05, Jan Beulich wrote:
>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>> This is the start of some performance and security-hardening improvements,
>>> based on the fact that 32bit PV guests are few and far between these days.
>>>
>>> Ring1 is full or architectural corner cases, such as counting as supervisor
>> ... full of ...
>>
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -1694,7 +1694,17 @@ The following resources are available:
>>>      CDP, one COS will corespond two CBMs other than one with CAT, due to the
>>>      sum of CBMs is fixed, that means actual `cos_max` in use will automatically
>>>      reduce to half when CDP is enabled.
>>> -	
>>> +
>>> +### pv
>>> +    = List of [ 32=<bool> ]
>>> +
>>> +    Applicability: x86
>>> +
>>> +Controls for aspects of PV guest support.
>>> +
>>> +*   The `32` boolean controls whether 32bit PV guests can be created.  It
>>> +    defaults to `true`, and is ignored when `CONFIG_PV32` is compiled out.
>> Rather than ignoring in the way you do, how about ...
>>
>>> --- a/xen/arch/x86/pv/domain.c
>>> +++ b/xen/arch/x86/pv/domain.c
>>> @@ -16,6 +16,39 @@
>>>  #include <asm/pv/domain.h>
>>>  #include <asm/shadow.h>
>>>  
>>> +#ifdef CONFIG_PV32
>>> +int8_t __read_mostly opt_pv32 = -1;
>>> +#endif
>>> +
>>> +static int parse_pv(const char *s)
>>> +{
>>> +    const char *ss;
>>> +    int val, rc = 0;
>>> +
>>> +    do {
>>> +        ss = strchr(s, ',');
>>> +        if ( !ss )
>>> +            ss = strchr(s, '\0');
>>> +
>>> +        if ( (val = parse_boolean("32", s, ss)) >= 0 )
>>> +        {
>>> +#ifdef CONFIG_PV32
>>> +            opt_pv32 = val;
>>> +#else
>>> +            printk(XENLOG_INFO
>>> +                   "CONFIG_PV32 disabled - ignoring 'pv=32' setting\n");
>>> +#endif
>>> +        }
>> ... moving the #ifdef ahead of the if(), and the #endif here (may
>> want converting to "else if" with a placeholder if(0) for this
>> purpose), with the separate printk() dropped?
> 
> In this specific case, it would be even more awkward as there is no use
> of val outside of the ifdef.

True, but can be dealt with in the body of the suggested placeholder
if(0).

>> I'm in particular
>> concerned that we may gain a large number of such printk()s over
>> time, if we added them in such cases.
> 
> The printk() was a bit of an afterthought, but deliberately avoiding the
> -EINVAL path was specifically not.
> 
> In the case that the user tries to use `pv=no-32` without CONFIG_PV32,
> they should see something other than
> 
> (XEN) parameter "pv=no-32" unknown!

Why - to this specific build of Xen the parameter is unknown.

> I don't think overloading the return value is a clever move, because
> then every parse function has to take care of ensuring that -EOPNOTSUPP
> (or ENODEV?) never clobbers -EINVAL.

I didn't suggest overloading the return value. Instead I
specifically want this to go the -EINVAL path.

> We could have a generic helper which looks like:
> 
> static inline void ignored_param(const char *cfg, const char *name,
> const char *s, const char *ss)
> {
>     printk(XENLOG_INFO "%s disabled - ignoring '%s=%*.s' setting\n",
> cfg, name, s, (int)(ss - s));
> }
> 
> which at least would keep all the users consistent.

Further bloating the binary with (almost) useless string literals.
I'd specifically like to avoid this.

>> See parse_iommu_param() for
>> how I'd prefer things to look like in the long run.
> 
> I'm aware of that, just as you are aware of my specific dislike for the
> ifndefs, which make the logic opaque and hard to follow.

A matter of taste and/or perception, I guess, but yes, I'm aware.
I don't recall a suggestion (from you or anyone else) as to a good
alternative, though. What I'd like to achieve is that command line
options valid only in certain configurations get similar treatment
no matter by whom they were added. It doesn't need to be my way of
handling, but I'm pretty convinced that consistency especially in
such "user interface" aspects is very desirable goal.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 06:09:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 06:09:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQm6Q-00084l-5l; Tue, 21 Apr 2020 06:09:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQm6O-00084g-GB
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 06:09:48 +0000
X-Inumbo-ID: b34537ec-8396-11ea-9100-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b34537ec-8396-11ea-9100-12813bfff9fa;
 Tue, 21 Apr 2020 06:09:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 357C6AAC7;
 Tue, 21 Apr 2020 06:09:45 +0000 (UTC)
Subject: Re: [PATCH 3/3] x86/pv: Compile out compat_gdt in !CONFIG_PV builds
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-4-andrew.cooper3@citrix.com>
 <3c8eee8d-c2ce-d262-4056-a5d2c9f843cb@suse.com>
 <acffe7f9-3265-e999-34ce-30891535897b@citrix.com>
 <cb6fcbd0-1b0a-d105-30ce-e0a6215f4904@suse.com>
 <e5a208df-94f0-56e7-e801-06fb0933f02e@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8c4a05ba-825f-f9c7-5ef2-0d97f1a59870@suse.com>
Date: Tue, 21 Apr 2020 08:09:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e5a208df-94f0-56e7-e801-06fb0933f02e@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 19:08, Andrew Cooper wrote:
> On 20/04/2020 16:47, Jan Beulich wrote:
>> On 20.04.2020 16:39, Andrew Cooper wrote:
>>> On 20/04/2020 15:12, Jan Beulich wrote:
>>>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>>>> There is no need for the Compat GDT if there are no 32bit PV guests.  This
>>>>> saves 4k per online CPU
>>>>>
>>>>> Bloat-o-meter reports the following savings in Xen itself:
>>>>>
>>>>>   add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605)
>>>>>   Function                                     old     new   delta
>>>>>   cpu_smpboot_free                            1249    1256      +7
>>>>>   per_cpu__compat_gdt_l1e                        8       -      -8
>>>>>   per_cpu__compat_gdt                            8       -      -8
>>>>>   init_idt_traps                               442     420     -22
>>>>>   load_system_tables                           414     364     -50
>>>>>   trap_init                                    444     280    -164
>>>>>   cpu_smpboot_callback                        1255     991    -264
>>>>>   boot_compat_gdt                             4096       -   -4096
>>>>>   Total: Before=3062726, After=3058121, chg -0.15%
>>>>>
>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> ---
>>>>> CC: Jan Beulich <JBeulich@suse.com>
>>>>> CC: Wei Liu <wl@xen.org>
>>>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>>>>
>>>>> The increase in cpu_smpboot_free() appears to be a consequence of a totally
>>>>> different layout of basic blocks.
>>>>> ---
>>>>>  xen/arch/x86/cpu/common.c |  5 +++--
>>>>>  xen/arch/x86/desc.c       |  2 ++
>>>>>  xen/arch/x86/smpboot.c    |  5 ++++-
>>>>>  xen/arch/x86/traps.c      | 10 +++++++---
>>>>>  4 files changed, 16 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>>>> index 1b33f1ed71..7b093cb421 100644
>>>>> --- a/xen/arch/x86/cpu/common.c
>>>>> +++ b/xen/arch/x86/cpu/common.c
>>>>> @@ -752,8 +752,9 @@ void load_system_tables(void)
>>>>>  
>>>>>  	_set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss,
>>>>>  			 sizeof(*tss) - 1, SYS_DESC_tss_avail);
>>>>> -	_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>>>>> -			 sizeof(*tss) - 1, SYS_DESC_tss_busy);
>>>>> +	if ( IS_ENABLED(CONFIG_PV32) )
>>>>> +		_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>>>>> +				 sizeof(*tss) - 1, SYS_DESC_tss_busy);
>>>> Wouldn't this better be "if ( opt_pv32 )"? Also elsewhere then.
>>> Doing it like this specifically ensures that there is never a case where
>>> things are half configured.
>> But this way you set up something in the GDT that's never going
>> to be used when "pv=no-32". Why leave a TSS accessible that we
>> don't need?
> 
> Defence in depth.
> 
> Having it only partially set up is more likely to fail in a security
> relevant way, than having it fully set up.

Well, I'm not convinced, but anyway
Acked-by: Jan Beulich <jbeulich@suse.com>

> This particular example is poor.  There is no need to have the TSS in
> either GDT after the `ltr` instruction at boot for 64bit, because we
> don't task switch, but ISTR you requesting that this stayed as-was for
> consistency.  (For 32bit Xen, it was strictly necessary for the #DF task
> switch to work.)

Well, I'm simply of the opinion that what the TR holds should point
to something valid in the currently active GDT. (As an alternative
we could decide to zap TSS descriptors from _both_ GDTs once we're
past the LTR. This wouldn't even conflict with resume from S3, as
we re-write the TSS descriptors immediately ahead of the LTR.)

> However, the other logic, particularly the cached l1e pointing at the
> percpu compat_gdt is more liable to go wrong in interesting ways.

Possibly, yes.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 06:29:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 06:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQmPR-0001Q6-16; Tue, 21 Apr 2020 06:29:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=j1p9=6F=amazon.de=prvs=373406edd=wipawel@srs-us1.protection.inumbo.net>)
 id 1jQmPO-0001Q1-Ub
 for xen-devel@lists.xen.org; Tue, 21 Apr 2020 06:29:27 +0000
X-Inumbo-ID: 72521946-8399-11ea-9e09-bc764e2007e4
Received: from smtp-fw-6002.amazon.com (unknown [52.95.49.90])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 72521946-8399-11ea-9e09-bc764e2007e4;
 Tue, 21 Apr 2020 06:29:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587450566; x=1618986566;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-id:mime-version:content-transfer-encoding:subject;
 bh=EtpmZq12ld7XHAeAJgEHYYuGwoWtybHTmEm6jnq8bSs=;
 b=W86dk2ElDCYafFELdXDTn+NnckTxzTJph/YMKpfb+MB8difeDLAjCFiz
 5dEyC6PEGsz7GCTtn7FkRuKciQyrpXS6CQ8wqilgawgcGPKe6sRLLCwxH
 qyRNrDeMHR2CFGR0CDCmQSI6mvLDARyq4fJGNRX5bZnKCjbMBbpr33e2h 8=;
IronPort-SDR: xcH3cT9zYRLNEHWzKvu7/8KZ/1A3qDr9cwaBgq/MqIu2IZU8rObSrEe0hgXQJ+nYMKmYvZsHjH
 DIVltw6tNIZA==
X-IronPort-AV: E=Sophos;i="5.72,409,1580774400"; d="scan'208";a="26498420"
Subject: Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
Thread-Topic: [XTF 2/4] lib: always append CR after LF in vsnprintf()
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP;
 21 Apr 2020 06:29:13 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com (Postfix) with ESMTPS
 id 9659AA2374; Tue, 21 Apr 2020 06:29:12 +0000 (UTC)
Received: from EX13D05EUB002.ant.amazon.com (10.43.166.45) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 21 Apr 2020 06:29:09 +0000
Received: from EX13D05EUB004.ant.amazon.com (10.43.166.115) by
 EX13D05EUB002.ant.amazon.com (10.43.166.45) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 21 Apr 2020 06:29:08 +0000
Received: from EX13D05EUB004.ant.amazon.com ([10.43.166.115]) by
 EX13D05EUB004.ant.amazon.com ([10.43.166.115]) with mapi id 15.00.1497.006;
 Tue, 21 Apr 2020 06:29:08 +0000
From: "Wieczorkiewicz, Pawel" <wipawel@amazon.de>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Thread-Index: AQHWE9NFbSxUmGmFhkmqadsHpX8TWKh7iTMAgAAVnYCABsyVAIAAuUcA
Date: Tue, 21 Apr 2020 06:29:08 +0000
Message-ID: <D93B12C8-C4CA-4303-84A7-B4B30729BFA4@amazon.com>
References: <20200416094141.65120-1-wipawel@amazon.de>
 <20200416094141.65120-3-wipawel@amazon.de>
 <00549997-7633-a8c2-899a-fbc0b5a45541@citrix.com>
 <A2E046DD-9F85-4C54-9FED-BE240AA71E09@amazon.com>
 <5d319ae1-e244-23bb-d3fa-cbabb739c33c@citrix.com>
In-Reply-To: <5d319ae1-e244-23bb-d3fa-cbabb739c33c@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.165.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <479299534BAFFC459963AED0ED9626D7@amazon.com>
MIME-Version: 1.0
Precedence: Bulk
Content-Transfer-Encoding: base64
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <julien@xen.org>, "paul@xen.org" <paul@xen.org>,
 "semelpaul@gmail.com" <semelpaul@gmail.com>,
 "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Wieczorkiewicz,
 Pawel" <wipawel@amazon.de>, "Manthey, Norbert" <nmanthey@amazon.de>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQo+IE9uIDIwLiBBcHIgMjAyMCwgYXQgMjE6MjYsIEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29w
ZXIzQGNpdHJpeC5jb20+IHdyb3RlOg0KPiANCj4gQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5h
dGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mg
b3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXIgYW5k
IGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IA0KPiANCj4gT24gMTYvMDQvMjAyMCAx
MjozNiwgV2llY3pvcmtpZXdpY3osIFBhd2VsIHdyb3RlOg0KPj4+IFVuZm9ydHVuYXRlbHksIHRo
aXMgY29tZXMgd2l0aCBjb2xsYXRlcmFsIGRhbWFnZS4NCj4+PiANCj4+PiAjIC4veHRmLXJ1bm5l
ciBodm02NCBleGFtcGxlDQo+Pj4gRXhlY3V0aW5nICd4bCBjcmVhdGUgLXAgdGVzdHMvZXhhbXBs
ZS90ZXN0LWh2bTY0LWV4YW1wbGUuY2ZnJw0KPj4+IEV4ZWN1dGluZyAneGwgY29uc29sZSB0ZXN0
LWh2bTY0LWV4YW1wbGUnDQo+Pj4gRXhlY3V0aW5nICd4bCB1bnBhdXNlIHRlc3QtaHZtNjQtZXhh
bXBsZScNCj4+PiAtLS0gWGVuIFRlc3QgRnJhbWV3b3JrIC0tLQ0KPj4+IA0KPj4+IEZvdW5kIFhl
bjogNC4xNA0KPj4+IA0KPj4+IEVudmlyb25tZW50OiBIVk0gNjRiaXQgKExvbmcgbW9kZSA0IGxl
dmVscykNCj4+PiANCj4+PiBIZWxsbyBXb3JsZA0KPj4+IA0KPj4+IFRlc3QgcmVzdWx0OiBTVUND
RVNTDQo+Pj4gDQo+Pj4gDQo+Pj4gQ29tYmluZWQgdGVzdCByZXN1bHRzOg0KPj4+IHRlc3QtaHZt
NjQtZXhhbXBsZSAgICAgICAgICAgICAgICAgICAgICAgQ1JBU0gNCj4+PiANCj4+IEkgbmV2ZXIg
dXNlIHh0Zi1ydW5uZXIgc2NyaXB0IHRvIGV4ZWN1dGUgdGVzdHMuIEkgZG8gaXQgdGhlIG9sZCBm
YXNoaW9uIHdheToNCj4+IA0KPj4gIyB4bCBjcmVhdGUgLWMgdGVzdC1odm02NC1leGFtcGxlLmNm
Zw0KPj4gUGFyc2luZyBjb25maWcgZnJvbSB0ZXN0LWh2bTY0LWV4YW1wbGUuY2ZnDQo+IA0KPiBJ
IHByZXN1bWUgeW91IG1lYW4gaHZtNjQtY3B1aWQgaGVyZSwgYnV0Li4uDQo+IA0KPj4gR3Vlc3Qg
Y3B1aWQgaW5mb3JtYXRpb24NCj4+ICAgICAgICAgICAgICAgICAgICAgICBOYXRpdmUgY3B1aWQ6
DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMDA6ZmZmZmZm
ZmYgLT4gMDAwMDAwMGQ6NzU2ZTY1NDc6NmM2NTc0NmU6NDk2NTZlNjkNCj4+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMDE6ZmZmZmZmZmYgLT4gMDAwMzA2ZTQ6
MDA0MDA4MDA6ZjdiYTIyMDM6MWZjYmZiZmYNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDAwMDAwMDAyOmZmZmZmZmZmIC0+IDc2MDM2MzAxOjAwZjBiMmZmOjAwMDAw
MDAwOjAwY2EwMDAwDQo+PiAwMDAwMDAwMzpmZmZmZmZmZiAtPiAwMDAwMDAwMDowMDAwMDAwMDow
MDAwMDAwMDowMDAwMDAwMA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMDQ6MDAwMDAwMDAgLT4gN2MwMDAxMjE6MDFjMDAw
M2Y6MDAwMDAwM2Y6MDAwMDAwMDANCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwNDowMDAwMDAwMSAtPiA3YzAwMDEyMjow
MWMwMDAzZjowMDAwMDAzZjowMDAwMDAwMA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwNDowMDAwMDAwMiAtPiA3YzAw
MDE0MzowMWMwMDAzZjowMDAwMDFmZjowMDAwMDAwMA0KPj4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMDQ6MDAwMDAwMDMg
LT4gN2MwMDAxNjM6MDRjMDAwM2Y6MDAwMDRmZmY6MDAwMDAwMDYNCj4+IDAwMDAwMDA0OjAwMDAw
MDA0IC0+IDAwMDAwMDAwOjAwMDAwMDAwOjAwMDAwMDAwOjAwMDAwMDAwDQo+PiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMDU6
ZmZmZmZmZmYgLT4gMDAwMDAwNDA6MDAwMDAwNDA6MDAwMDAwMDM6MDAwMDExMjANCj4+ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAw
MDAwMDY6ZmZmZmZmZmYgLT4gMDAwMDAwNzc6MDAwMDAwMDI6MDAwMDAwMDk6MDAwMDAwMDANCj4+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDAwMDAwMDA3OjAwMDAwMDAwIC0+IDAwMDAwMDAwOjAwMDAwMjgxOjAwMDAwMDAwOjljMDAw
NDAwDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgMDAwMDAwMDg6ZmZmZmZmZmYgLT4gMDAwMDAwMDA6MDAwMDAwMDA6MDAwMDAw
MDA6MDAwMDAwMDANCj4+ICAwMDAwMDAwOTpmZmZmZmZmZiAtPiAwMDAwMDAwMDowMDAwMDAwMDow
MDAwMDAwMDowMDAwMDAwMA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwYTpmZmZmZmZmZiAtPiAwNzMwMDQwMzowMDAw
MDAwMDowMDAwMDAwMDowMDAwMDYwMw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMGI6ZmZmZmZmZmYgLT4gMDAwMDAw
MDA6MDAwMDAwMDA6MDAwMDAwMDA6MDAwMDAwMDANCj4+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwYzpmZmZmZmZmZiAt
PiAwMDAwMDAwMDowMDAwMDAwMDowMDAwMDAwMDowMDAwMDAwMA0KPj4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwZDow
MDAwMDAwMCAtPiAwMDAwMDAwNzowMDAwMDI0MDowMDAwMDM0MDowMDAwMDAwMA0KPj4gICAwMDAw
MDAwZDowMDAwMDAwMSAtPiAwMDAwMDAwMTowMDAwMDAwMDowMDAwMDAwMDowMDAwMDAwMA0KPj4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMDAwMDAwMGQ6MDAwMDAwMDIgLT4gMDAwMDAxMDA6MDAwMDAyNDA6MDAwMDAwMDA6MDAwMDAw
MDANCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA0MDAwMDAwMDpmZmZmZmZmZiAtPiA0MDAwMDAwNTo1NjZlNjU1ODo2NTU4NGQ0
ZDo0ZDRkNTY2ZQ0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA0MDAwMDAwMTpmZmZmZmZmZiAtPiAwMDA0MDAwYjowMDAwMDAw
MDowMDAwMDAwMDowMDAwMDAwMA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNDAwMDAwMDI6ZmZmZmZmZmYgLT4gMDAwMDAw
MDE6NDAwMDAwMDA6MDAwMDAwMDA6MDAwMDAwMDANCj4+ICAgIDQwMDAwMDAzOjAwMDAwMDAwIC0+
IDAwMDAwMDA2OjAwMDAwMDAwOjAwMjYyNWEyOjAwMDAwMDAxDQo+PiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNDAwMDAwMDM6MDAw
MDAwMDEgLT4gNTdiM2M0ZDI6MDAwMzA3NTU6Y2NjY2MyMTA6ZmZmZmZmZmYNCj4+ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNDAw
MDAwMDM6MDAwMDAwMDIgLT4gMDAyNjI1YTI6MDAwMDAwMDA6MDAwMDAwMDA6MDAwMDAwMDANCj4+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDQwMDAwMDA0OjAwMDAwMDAwIC0+IDAwMDAwMDFjOjAwMDAwMDAwOjAwMDAwYWM5OjAw
MDAwMDAwDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgNDAwMDAwMDU6ZmZmZmZmZmYgLT4gMDAwMDAwMDA6MDAwMDAwMDA6
MDAwMDAwMDA6MDAwMDAwMDANCj4+ICAgICA0MDAwMDEwMDpmZmZmZmZmZiAtPiAwMDAwMDAwMDow
MDAwMDAwMDowMDAwMDAwMDowMDAwMDAwMA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA4MDAwMDAwMDpmZmZmZmZmZiAtPiA4
MDAwMDAwODowMDAwMDAwMDowMDAwMDAwMDowMDAwMDAwMA0KPj4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgODAwMDAwMDE6ZmZm
ZmZmZmYgLT4gMDAwMDAwMDA6MDAwMDAwMDA6MDAwMDAwMDE6MmMxMDA4MDANCj4+ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA4
MDAwMDAwMjpmZmZmZmZmZiAtPiAyMDIwMjAyMDo2ZTQ5MjAyMDoyODZjNjU3NDo1ODIwMjk1Mg0K
Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA4MDAwMDAwMzpmZmZmZmZmZiAtPiAyODZlNmY2NTo0MzIwMjk1Mjo0NTIwNTU1
MDozNjMyMmQzNQ0KPj4gICAgICA4MDAwMDAwNDpmZmZmZmZmZiAtPiA3NjIwMzAzNzoyMDQwMjAz
MjozMDM1MmUzMjowMDdhNDg0Nw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgODAwMDAwMDU6ZmZmZmZmZmYgLT4gMDAwMDAw
MDA6MDAwMDAwMDA6MDAwMDAwMDA6MDAwMDAwMDANCj4+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA4MDAwMDAwNjpmZmZmZmZm
ZiAtPiAwMDAwMDAwMDowMDAwMDAwMDowMTAwNjA0MDowMDAwMDAwMA0KPj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA4MDAw
MDAwNzpmZmZmZmZmZiAtPiAwMDAwMDAwMDowMDAwMDAwMDowMDAwMDAwMDowMDAwMDAwMA0KPj4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgODAwMDAwMDg6ZmZmZmZmZmYgLT4gMDAwMDMwMmU6MDAwMDEwMDA6MDAwMDAwMDA6
MDAwMDAwMDANCj4+ICAgICBUZXN0IHJlc3VsdDogU1VDQ0VTUw0KPiANCj4gLi4uIEkgaGF2ZSBy
ZXByb2R1Y2VkIHRoaXMgbG9jYWxseS4NCj4gDQoNCkNvb2whDQoNCj4gSG93ZXZlciwgSSdkIGFy
Z3VlIHRoYXQgdGhpcyBpdCBpcyBhIGJ1ZyBpbiB4ZW5jb25zb2xlZCByYXRoZXIgdGhhbg0KPiBY
VEYuICBJbiBwYXJ0aWN1bGFyLCBtb2RpZnlpbmcgWFRGIHdvdWxkIHJlc3VsdCBpbiB4ZW5jb25z
b2xlZCB3cml0aW5nDQo+IG91dCB0aGUgbG9nZmlsZSB3aXRoIHdpbmRvd3MgbGluZSBlbmRpbmdz
LCB3aGljaCBzdXJlbHkgaXNuJ3QgaW50ZW5kZWQuDQo+IA0KDQpXZSBjYW7igJl0IGZpeCB4ZW5j
b25zb2xlZCByZXRyb3NwZWN0aXZlbHksIHNvIEnigJlkIGFyZ3VlIHRoYXQgd2UgaGF2ZSB0byBo
YXZlDQphIHdvcmthcm91bmQgaW4gWFRGIChvciBzb21ld2hlcmUgZWxzZSwgSSBkbyBub3QgY2Fy
ZSBtdWNoIHdoZXJlKS4gSSBwbGFuIHRvDQprZWVwIHVzaW5nIFhURiB3aXRoIHZhcmlvdXMgWGVu
IHZlcnNpb25zLg0KDQo+Pj4+IC0tLQ0KPj4+PiBjb21tb24vbGliYy92c25wcmludGYuYyB8IDEw
ICsrKysrKysrKysNCj4+Pj4gMSBmaWxlIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKykNCj4+Pj4g
DQo+Pj4+IGRpZmYgLS1naXQgYS9jb21tb24vbGliYy92c25wcmludGYuYyBiL2NvbW1vbi9saWJj
L3ZzbnByaW50Zi5jDQo+Pj4+IGluZGV4IGE0OWZkMzAuLjMyMDIxMzcgMTAwNjQ0DQo+Pj4+IC0t
LSBhL2NvbW1vbi9saWJjL3ZzbnByaW50Zi5jDQo+Pj4+ICsrKyBiL2NvbW1vbi9saWJjL3ZzbnBy
aW50Zi5jDQo+Pj4+IEBAIC0yODUsNiArMjg1LDE2IEBAIGludCB2c25wcmludGYoY2hhciAqYnVm
LCBzaXplX3Qgc2l6ZSwgY29uc3QgY2hhciAqZm10LCB2YV9saXN0IGFyZ3MpDQo+Pj4+ICAgICAg
ICBpZiAoICpmbXQgIT0gJyUnICkNCj4+Pj4gICAgICAgIHsNCj4+Pj4gICAgICAgICAgICBQVVQo
KmZtdCk7DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgICAgIC8qDQo+Pj4+ICsgICAgICAgICAgICAg
KiBUaGUgJ1xuJyBjaGFyYWN0ZXIgYWxvbmUgb24gc29tZSB0ZXJtaW5hbHMgaXMgbm90IGF1dG9t
YXRpY2FsbHkNCj4+Pj4gKyAgICAgICAgICAgICAqIGNvbnZlcnRlZCB0byBMRkNSLg0KPj4+PiAr
ICAgICAgICAgICAgICogVGhlIGV4cGxpY2l0IExGQ1Igc2VxdWVuY2UgZ3VhcmFudGVlcyBwcm9w
ZXIgbGluZSBieSBsaW5lDQo+Pj4+ICsgICAgICAgICAgICAgKiBmb3JtYXR0aW5nIGluIHRoZSBv
dXRwdXQuDQo+Pj4+ICsgICAgICAgICAgICAgKi8NCj4+Pj4gKyAgICAgICAgICAgIGlmICggKmZt
dCA9PSAnXG4nICYmIHN0ciA8IGVuZCApDQo+Pj4+ICsgICAgICAgICAgICAgICAgUFVUKCdccicp
Ow0KPj4+IC4uLiBkb2Vzbid0IHRoaXMgZW5kIHVwIHB1dHRpbmcgb3V0IFxuXHIgPw0KPj4geWVz
LCBpdCBkb2VzDQo+IA0KPiBTbyB0aGUgb25lIHR5cGUgb2YgbGluZSBlbmRpbmcgd2hpY2ggaXNu
J3QgaW4gY29tbW9uIHVzZT8NCj4gDQoNCkFzIGxvbmcgYXMgaXQgd29ya3PigKYgYWRkaXRpb25h
bCBiZW5lZml0IGlzIHNpbXBsaWNpdHkuDQpJIGRpZCBub3Qgd2FudCB0byBtZXNzIHdpdGggdGhl
IHN0cmVhbSBhbmQgcG90ZW50aWFsbHkgY2F1c2UgbW9yZSBoYXJtLg0KDQo+IH5BbmRyZXcNCg0K
DQpCZXN0IFJlZ2FyZHMsDQpQYXdlbCBXaWVjem9ya2lld2ljeg0Kd2lwYXdlbEBhbWF6b24uY29t
DQoNCgoKCkFtYXpvbiBEZXZlbG9wbWVudCBDZW50ZXIgR2VybWFueSBHbWJICktyYXVzZW5zdHIu
IDM4CjEwMTE3IEJlcmxpbgpHZXNjaGFlZnRzZnVlaHJ1bmc6IENocmlzdGlhbiBTY2hsYWVnZXIs
IEpvbmF0aGFuIFdlaXNzCkVpbmdldHJhZ2VuIGFtIEFtdHNnZXJpY2h0IENoYXJsb3R0ZW5idXJn
IHVudGVyIEhSQiAxNDkxNzMgQgpTaXR6OiBCZXJsaW4KVXN0LUlEOiBERSAyODkgMjM3IDg3OQoK
Cg==



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 07:08:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 07:08:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQn1S-0004t8-Bl; Tue, 21 Apr 2020 07:08:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=dLRr=6F=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jQn1Q-0004t3-C9
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 07:08:44 +0000
X-Inumbo-ID: eeae8538-839e-11ea-910b-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id eeae8538-839e-11ea-910b-12813bfff9fa;
 Tue, 21 Apr 2020 07:08:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587452923;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=qeD5LJPhG08+uyODt3+zNlqT7vUrOUWeuBGqitvC/AQ=;
 b=JIBsMMDWbOWpT0cdNla101mFByD60FifAPaGwHwhM2jqSRRt8XJlv/J1
 ShSp7HdPXWJyOXS4tWOBZ3nfpe0Tbo6de7Tsy1Hu4JvpoDhXB+sXF5r+7
 Z6wrZF7EcUDdnl17+JSwB/S/94yF27282Qf/2bCDS2PilwP113ndR5HnT 8=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: uiWh71NJu13r3dyLexoYQLqp7h/XoklX77h5gEsZ+lgWADzGbIbAmzvYJKlTfbkidtUdXGynxf
 zQgAFt3as2XoIhE+oa00U08oaqtNcObhhIO+PCZEFUJwGIxG72Yqdrd7yEm4FSgGrsBdUVpUw6
 ABmFRCr2Pio3pp3g7N2181lCxYh8JrrmsQ2dmOQQb5iD3UGa0RsDX0GOELw1rozZ3uOWz1JTpo
 TC8SyHvkq8mIeGZauNoOXTfjDmHn/M921Cf1MEMzWg+BYUvNhs0a/2uH+E72fprFQVYrWCsrs7
 kUE=
X-SBRS: 2.7
X-MesageID: 15968401
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,409,1580792400"; d="scan'208";a="15968401"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2] sched: print information about scheduling granularity
Thread-Topic: [PATCH v2] sched: print information about scheduling granularity
Thread-Index: AQHWFxSXjjMvJMzYJESueOXaD39h5aiB5BuAgAE0AwA=
Date: Tue, 21 Apr 2020 07:08:38 +0000
Message-ID: <1587452901632.99554@citrix.com>
References: <20200420130650.14341-1-sergey.dyasli@citrix.com>
 <fd6eb92b-0708-186e-7d17-3527a2673dc8@suse.com>
In-Reply-To: <fd6eb92b-0708-186e-7d17-3527a2673dc8@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-imapappendstamp: AMSPEX02CL03.citrite.net (15.00.1497.006)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <22C434D97EF9164F98A7171B9AF1EB1E@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Sergey Dyasli <sergey.dyasli@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/04/2020 14:45, J=FCrgen Gro=DF wrote:=0A=
> On 20.04.20 15:06, Sergey Dyasli wrote:=0A=
>> Currently it might be not obvious which scheduling mode (e.g. core-=0A=
>> scheduling) is being used by the scheduler. Alleviate this by printing=
=0A=
>> additional information about the selected granularity per-cpupool.=0A=
>>=0A=
>> Note: per-cpupool granularity selection is not implemented yet.=0A=
>> =A0=A0=A0=A0=A0=A0 The single global value is being used for each cpupoo=
l.=0A=
> =0A=
> This is misleading. You are using the per-cpupool values, but they=0A=
> are all the same right now.=0A=
=0A=
This is what I meant by my note, but I might need to improve the wording=0A=
since the current one looks ambiguous to you.=0A=
=0A=
> =0A=
>>=0A=
>> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>=0A=
>> ---=0A=
>> v2:=0A=
>> - print information on a separate line=0A=
>> - use per-cpupool granularity=0A=
>> - updated commit message=0A=
>>=0A=
>> CC: Juergen Gross <jgross@suse.com>=0A=
>> CC: Dario Faggioli <dfaggioli@suse.com>=0A=
>> CC: George Dunlap <george.dunlap@citrix.com>=0A=
>> CC: Jan Beulich <jbeulich@suse.com>=0A=
>> ---=0A=
>> =A0 xen/common/sched/cpupool.c | 26 ++++++++++++++++++++++++++=0A=
>> =A0 1 file changed, 26 insertions(+)=0A=
>>=0A=
>> diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c=0A=
>> index d40345b585..68106f6c15 100644=0A=
>> --- a/xen/common/sched/cpupool.c=0A=
>> +++ b/xen/common/sched/cpupool.c=0A=
>> @@ -40,6 +40,30 @@ static DEFINE_SPINLOCK(cpupool_lock);=0A=
>> =A0 static enum sched_gran __read_mostly opt_sched_granularity =3D SCHED=
_GRAN_cpu;=0A=
>> =A0 static unsigned int __read_mostly sched_granularity =3D 1;=0A=
>> +static void sched_gran_print(enum sched_gran mode, unsigned int gran)=
=0A=
>> +{=0A=
>> +=A0=A0=A0 char *str =3D "";=0A=
>> +=0A=
>> +=A0=A0=A0 switch ( mode )=0A=
>> +=A0=A0=A0 {=0A=
>> +=A0=A0=A0 case SCHED_GRAN_cpu:=0A=
>> +=A0=A0=A0=A0=A0=A0=A0 str =3D "cpu";=0A=
>> +=A0=A0=A0=A0=A0=A0=A0 break;=0A=
>> +=A0=A0=A0 case SCHED_GRAN_core:=0A=
>> +=A0=A0=A0=A0=A0=A0=A0 str =3D "core";=0A=
>> +=A0=A0=A0=A0=A0=A0=A0 break;=0A=
>> +=A0=A0=A0 case SCHED_GRAN_socket:=0A=
>> +=A0=A0=A0=A0=A0=A0=A0 str =3D "socket";=0A=
>> +=A0=A0=A0=A0=A0=A0=A0 break;=0A=
>> +=A0=A0=A0 default:=0A=
>> +=A0=A0=A0=A0=A0=A0=A0 ASSERT_UNREACHABLE();=0A=
>> +=A0=A0=A0=A0=A0=A0=A0 break;=0A=
>> +=A0=A0=A0 }=0A=
> =0A=
> With this addition it might make sense to have an array indexed by=0A=
> mode to get the string. This array could then be used in=0A=
> sched_select_granularity(), too.=0A=
=0A=
I had thoughts about that, and with your suggestion looks like I need=0A=
to go and do it.=0A=
=0A=
> =0A=
>> +=0A=
>> +=A0=A0=A0 printk("Scheduling granularity: %s, %u CPU%s per sched-resour=
ce\n",=0A=
>> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 str, gran, gran =3D=3D 1 ? "" : "s");=0A=
>> +}=0A=
>> +=0A=
>> =A0 #ifdef CONFIG_HAS_SCHED_GRANULARITY=0A=
>> =A0 static int __init sched_select_granularity(const char *str)=0A=
>> =A0 {=0A=
>> @@ -115,6 +139,7 @@ static void __init cpupool_gran_init(void)=0A=
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 warning_add(fallback);=0A=
>> =A0=A0=A0=A0=A0 sched_granularity =3D gran;=0A=
>> +=A0=A0=A0 sched_gran_print(opt_sched_granularity, sched_granularity);=
=0A=
>> =A0 }=0A=
>> =A0 unsigned int cpupool_get_granularity(const struct cpupool *c)=0A=
>> @@ -911,6 +936,7 @@ void dump_runq(unsigned char key)=0A=
>> =A0=A0=A0=A0=A0 {=0A=
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 printk("Cpupool %d:\n", (*c)->cpupool_id);=
=0A=
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 printk("Cpus: %*pbl\n", CPUMASK_PR((*c)->cpu=
_valid));=0A=
>> +=A0=A0=A0=A0=A0=A0=A0 sched_gran_print((*c)->gran, cpupool_get_granular=
ity(*c));=0A=
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 schedule_dump(*c);=0A=
>> =A0=A0=A0=A0=A0 }=0A=
> =0A=
=0A=
--=0A=
Thanks,=0A=
Sergey=0A=
=0A=


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 07:09:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 07:09:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQn26-0004wg-Mn; Tue, 21 Apr 2020 07:09:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Zbep=6F=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jQn25-0004wZ-97
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 07:09:25 +0000
X-Inumbo-ID: 07728d08-839f-11ea-910b-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 07728d08-839f-11ea-910b-12813bfff9fa;
 Tue, 21 Apr 2020 07:09:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587452965;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=hnuYWUrcISGhyqgbBWbE93SDbcbhAnI50QvY7gz3WXY=;
 b=Z3MuwFqyFt2zi31ZAwDdFZLZRu78NOIT/5J/umBqk+Bk1kPlaTF9Et9Q
 crPEF2Yhql0cTBKAJeKNxgzWFcWjk0wtuE7UhZ/N8HbC/osbH9QvIsFZp
 M0JKCYtYXb9lGE1489PZL/SrmpICccHCm/nP2XsBXCVEvn5BVP3HZrLIC 0=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 0fzLVnxxwZbV0SMiETKcq8c8BxoPnoeChdpNpHJbtja0yLqfE5ZTUIXPwZJPRGKu5TTAiHoOZY
 tRDhc4QW9EQO65bSm8J4XjiYQUqp51+1Kh+c4GVPtMeGTBBMq9LR1NUCjBW8OKgn0lV/GiMnZM
 jByhMvPeLt76pt5VNwxciTiqFLCwsmDixhZlU0Sg1wwRVwKUNMI7FMSzP89xD1ltUPHB2Iew/i
 EFpuU8TPEijK5JlnxxGnFfA0CqU5GqEpbuCNAu7p3JdD0MTaLZrc/DJTZnLS6Ty2StJoS86XSR
 /+k=
X-SBRS: 2.7
X-MesageID: 15968412
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,409,1580792400"; d="scan'208";a="15968412"
Date: Tue, 21 Apr 2020 09:09:13 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Subject: Re: [PATCH v15 2/3] mem_sharing: allow forking domain with IOMMU
 enabled
Message-ID: <20200421070913.GT28601@Air-de-Roger>
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <0be7501ace42d856b344828755ece18659dabd33.1587142844.git.tamas.lengyel@intel.com>
 <20200420075655.GR28601@Air-de-Roger>
 <CABfawhmWm_KasEPG=4e1V4qF5uh-ErtazsK=O8gS2n80KrqOyA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABfawhmWm_KasEPG=4e1V4qF5uh-ErtazsK=O8gS2n80KrqOyA@mail.gmail.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 20, 2020 at 08:19:12AM -0600, Tamas K Lengyel wrote:
> On Mon, Apr 20, 2020 at 1:57 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
> >
> > On Fri, Apr 17, 2020 at 10:06:32AM -0700, Tamas K Lengyel wrote:
> > > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > > index d36d64b8dc..1d2149def3 100644
> > > --- a/xen/include/public/memory.h
> > > +++ b/xen/include/public/memory.h
> > > @@ -536,7 +536,9 @@ struct xen_mem_sharing_op {
> > >          } debug;
> > >          struct mem_sharing_op_fork {      /* OP_FORK */
> > >              domid_t parent_domain;        /* IN: parent's domain id */
> > > -            uint16_t pad[3];              /* Must be set to 0 */
> > > +#define XENMEM_FORK_WITH_IOMMU_ALLOWED 1  /* Allow forking domain with IOMMU */
> >
> > Since this is a flags field, can you express this is as: (1u << 0).
> 
> I was thinking of doing that then it won't fit into a single line. For
> this particular flag it would also make no difference.

Right, but when new flags are added it looks weird IMO to have:

#define XENMEM_FORK_WITH_IOMMU_ALLOWED 1
#define XENMEM_FOO_BAR_WITH_FOO        (1u << 1)

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 07:11:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 07:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQn4T-0005nR-AU; Tue, 21 Apr 2020 07:11:53 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQn4S-0005nM-DE
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 07:11:52 +0000
X-Inumbo-ID: 5eeeeaa4-839f-11ea-910d-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5eeeeaa4-839f-11ea-910d-12813bfff9fa;
 Tue, 21 Apr 2020 07:11:50 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 48291AC53;
 Tue, 21 Apr 2020 07:11:49 +0000 (UTC)
Subject: Re: [PATCH] x86: Enumeration for Control-flow Enforcement Technology
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200420190829.17874-1-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3c085f0c-134d-ae56-c529-60ea8e61b1be@suse.com>
Date: Tue, 21 Apr 2020 09:11:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200420190829.17874-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 21:08, Andrew Cooper wrote:
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -229,6 +229,7 @@ XEN_CPUFEATURE(UMIP,          6*32+ 2) /*S  User Mode Instruction Prevention */
>  XEN_CPUFEATURE(PKU,           6*32+ 3) /*H  Protection Keys for Userspace */
>  XEN_CPUFEATURE(OSPKE,         6*32+ 4) /*!  OS Protection Keys Enable */
>  XEN_CPUFEATURE(AVX512_VBMI2,  6*32+ 6) /*A  Additional AVX-512 Vector Byte Manipulation Instrs */
> +XEN_CPUFEATURE(CET_SS,        6*32+ 7) /*   CET - Shadow Stacks */
>  XEN_CPUFEATURE(GFNI,          6*32+ 8) /*A  Galois Field Instrs */
>  XEN_CPUFEATURE(VAES,          6*32+ 9) /*A  Vector AES Instrs */
>  XEN_CPUFEATURE(VPCLMULQDQ,    6*32+10) /*A  Vector Carry-less Multiplication Instrs */
> @@ -255,6 +256,7 @@ XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation Single
>  XEN_CPUFEATURE(MD_CLEAR,      9*32+10) /*A  VERW clears microarchitectural buffers */
>  XEN_CPUFEATURE(TSX_FORCE_ABORT, 9*32+13) /* MSR_TSX_FORCE_ABORT.RTM_ABORT */
>  XEN_CPUFEATURE(IBRSB,         9*32+26) /*A  IBRS and IBPB support (used by Intel) */
> +XEN_CPUFEATURE(CET_IBT,       6*32+20) /*   CET - Indirect Branch Tracking */

s/6/9/, moved up a line, and then
Reviewed-by: Jan Beulich <jbeulich@suse.com>

I take it you intentionally don't mean to add #CP related bits yet,
first and foremost TRAP_control_flow or some such, as well as its
error code bits? Nor definitions for the bits within the MSRs you
add, nor XSAVE pieces?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 07:24:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 07:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQnGs-0006lq-JC; Tue, 21 Apr 2020 07:24:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQnGr-0006ll-IY
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 07:24:41 +0000
X-Inumbo-ID: 29afbcfe-83a1-11ea-9112-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 29afbcfe-83a1-11ea-9112-12813bfff9fa;
 Tue, 21 Apr 2020 07:24:40 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BD5C8AEE6;
 Tue, 21 Apr 2020 07:24:38 +0000 (UTC)
Subject: Re: [PATCH 1/3] x86/S3: Use percpu_traps_init() rather than
 opencoding SYSCALL/SYSENTER restoration
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
 <20200420145911.5708-2-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <db70738a-4750-2780-2f44-b0bcd3a5f93b@suse.com>
Date: Tue, 21 Apr 2020 09:24:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200420145911.5708-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 16:59, Andrew Cooper wrote:
> @@ -46,24 +36,13 @@ void restore_rest_processor_state(void)
>      /* Restore full CR4 (inc MCE) now that the IDT is in place. */
>      write_cr4(mmu_cr4_features);
>  
> -    /* Recover syscall MSRs */
> -    wrmsrl(MSR_LSTAR, saved_lstar);
> -    wrmsrl(MSR_CSTAR, saved_cstar);
> -    wrmsrl(MSR_STAR, XEN_MSR_STAR);
> -    wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
> +    /* (re)initialise SYSCALL/SYSENTER state, amongst other things. */
> +    percpu_traps_init();

Without tweaks to subarch_percpu_traps_init() this assumes that,
now and going forward, map_domain_page() will work reliably at
this early point of resume. I'm not opposed, i.e.
Acked-by: Jan Beulich <jbeulich@suse.com>
but it would feel less fragile if the redundant re-writing of
the stubs would be skipped in the BSP resume case (I didn't
check whether it's also redundant for APs, but I suspect it's
not, as the stub pages may get allocated anew).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 07:35:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 07:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQnRB-0007jj-Q6; Tue, 21 Apr 2020 07:35:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQnRA-0007je-7W
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 07:35:20 +0000
X-Inumbo-ID: a6429bf0-83a2-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a6429bf0-83a2-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 07:35:19 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 47F39AF77;
 Tue, 21 Apr 2020 07:35:17 +0000 (UTC)
Subject: Re: [PATCH 2/3] x86/boot: Don't enable EFER.SCE for !CONFIG_PV builds
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
 <20200420145911.5708-3-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <4ded0aab-dcab-bc46-92f3-d76ac8606889@suse.com>
Date: Tue, 21 Apr 2020 09:35:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200420145911.5708-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 Kevin Tian <kevin.tian@intel.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 16:59, Andrew Cooper wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -238,7 +238,8 @@ static void __init noreturn efi_arch_post_exit_boot(void)
>      /* Set system registers and transfer control. */
>      asm volatile("pushq $0\n\tpopfq");
>      rdmsrl(MSR_EFER, efer);
> -    efer |= EFER_SCE;
> +    if ( IS_ENABLED(CONFIG_PV) )
> +        efer |= EFER_SCE;
>      if ( cpu_has_nx )
>          efer |= EFER_NX;
>      wrmsrl(MSR_EFER, efer);

Switch to simply ORing in trampoline_efer here?

With or without the adjustment
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 07:48:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 07:48:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQne6-0000Gp-6c; Tue, 21 Apr 2020 07:48:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQne4-0000Gk-Ti
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 07:48:40 +0000
X-Inumbo-ID: 83cb8328-83a4-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 83cb8328-83a4-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 07:48:40 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6A2A2AC2C;
 Tue, 21 Apr 2020 07:48:38 +0000 (UTC)
Subject: Re: [PATCH 3/3] x86/pv: Don't use IST for NMI/#MC/#DB in !CONFIG_PV
 builds
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
 <20200420145911.5708-4-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <08a798db-3126-7ccd-17f3-476607cc9e45@suse.com>
Date: Tue, 21 Apr 2020 09:48:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200420145911.5708-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20.04.2020 16:59, Andrew Cooper wrote:
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -441,12 +441,18 @@ struct tss_page {
>  };
>  DECLARE_PER_CPU(struct tss_page, tss_page);
>  
> +/*
> + * Interrupt Stack Tables.  Used to force a stack switch on a CPL0=>0
> + * interrupt/exception.  #DF uses IST all the time to detect stack overflows
> + * cleanly.  NMI/#MC/#DB only need IST to cover the SYSCALL gap, and therefore
> + * only necessary with PV guests.
> + */

Is it really only the SYSCALL gap that we mean to cover? In particular
for #MC I'd suspect it is a good idea to switch stacks as well, to get
onto a distinct memory page in case the #MC was stack related. With
NMI it might as well be better to switch; I agree we don't need any
switching for #DB.

I also think that the comment at the top of current.h would want
updating with these adjustments (which I notice lacks the #DB part
anyway).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 08:54:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 08:54:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQofJ-0006fM-7G; Tue, 21 Apr 2020 08:54:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=400w=6F=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jQofH-0006fH-Nt
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 08:53:59 +0000
X-Inumbo-ID: a34639b0-83ad-11ea-9118-12813bfff9fa
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id a34639b0-83ad-11ea-9118-12813bfff9fa;
 Tue, 21 Apr 2020 08:53:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1587459237;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=1rQk9nLhjoKU4Y84lvzoPJz3nfGTEDpCxX8N/2k68SI=;
 b=K+0wwCFdseKsjQ8s3LhNJxNmrRu0BzB/y9U7Drzaqzv7HQb2NpVbueoZqrh0mjWgNdqqH9
 OmSfo750i7EORuPjd6e+Ev9F/GoMgjZ/tg1zk5gMCeUCqNhGB2xxN3z2wWcH8Vx0QzZzRJ
 rBfSdruvGJ6TyN7jzS9ChfE7cdx2CE8=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-263-jqpXaHuMO16QPOc7WagJGg-1; Tue, 21 Apr 2020 04:53:56 -0400
X-MC-Unique: jqpXaHuMO16QPOc7WagJGg-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com
 [10.5.11.22])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ADD5E107ACC7;
 Tue, 21 Apr 2020 08:53:54 +0000 (UTC)
Received: from t480s.redhat.com (ovpn-113-245.ams2.redhat.com [10.36.113.245])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 3FBB510027A9;
 Tue, 21 Apr 2020 08:53:46 +0000 (UTC)
From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Subject: [PATCH v4 03/13] numa: Teach ram block notifiers about resizeable ram
 blocks
Date: Tue, 21 Apr 2020 10:52:50 +0200
Message-Id: <20200421085300.7734-4-david@redhat.com>
In-Reply-To: <20200421085300.7734-1-david@redhat.com>
References: <20200421085300.7734-1-david@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Eduardo Habkost <ehabkost@redhat.com>, Juan Quintela <quintela@redhat.com>,
 "Michael S . Tsirkin" <mst@redhat.com>, David Hildenbrand <david@redhat.com>,
 "Dr . David Alan Gilbert" <dgilbert@redhat.com>, Peter Xu <peterx@redhat.com>,
 Paul Durrant <paul@xen.org>, Igor Mammedov <imammedo@redhat.com>,
 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, xen-devel@lists.xenproject.org,
 Anthony Perard <anthony.perard@citrix.com>,
 Paolo Bonzini <pbonzini@redhat.com>,
 =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@redhat.com>,
 Richard Henderson <rth@twiddle.net>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Ram block notifiers are currently not aware of resizes. Especially to
handle resizes during migration, but also to implement actually resizeable
ram blocks (make everything between used_length and max_length
inaccessible), we want to teach ram block notifiers about resizeable
ram.

Introduce the basic infrastructure but keep using max_size in the
existing notifiers. Supply the max_size when adding and removing ram
blocks. Also, notify on resizes.

Acked-by: Paul Durrant <paul@xen.org>
Reviewed-by: Peter Xu <peterx@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Paul Durrant <paul@xen.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: xen-devel@lists.xenproject.org
Cc: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 exec.c                     | 11 +++++++++--
 hw/core/numa.c             | 22 +++++++++++++++++-----
 hw/i386/xen/xen-mapcache.c |  7 ++++---
 include/exec/ramlist.h     | 13 +++++++++----
 target/i386/hax-mem.c      |  5 +++--
 target/i386/sev.c          | 18 ++++++++++--------
 util/vfio-helpers.c        | 16 ++++++++--------
 7 files changed, 60 insertions(+), 32 deletions(-)

diff --git a/exec.c b/exec.c
index 4f804347a6..83304e51c6 100644
--- a/exec.c
+++ b/exec.c
@@ -2115,6 +2115,11 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t news=
ize, Error **errp)
         return -EINVAL;
     }
=20
+    /* Notify before modifying the ram block and touching the bitmaps. */
+    if (block->host) {
+        ram_block_notify_resize(block->host, block->used_length, newsize);
+    }
+
     cpu_physical_memory_clear_dirty_range(block->offset, block->used_lengt=
h);
     block->used_length =3D newsize;
     cpu_physical_memory_set_dirty_range(block->offset, block->used_length,
@@ -2281,7 +2286,8 @@ static void ram_block_add(RAMBlock *new_block, Error =
**errp, bool shared)
             qemu_madvise(new_block->host, new_block->max_length,
                          QEMU_MADV_DONTFORK);
         }
-        ram_block_notify_add(new_block->host, new_block->max_length);
+        ram_block_notify_add(new_block->host, new_block->used_length,
+                             new_block->max_length);
     }
 }
=20
@@ -2461,7 +2467,8 @@ void qemu_ram_free(RAMBlock *block)
     }
=20
     if (block->host) {
-        ram_block_notify_remove(block->host, block->max_length);
+        ram_block_notify_remove(block->host, block->used_length,
+                                block->max_length);
     }
=20
     qemu_mutex_lock_ramlist();
diff --git a/hw/core/numa.c b/hw/core/numa.c
index dc5e5b4046..fe6ca5c50d 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -857,11 +857,12 @@ void query_numa_node_mem(NumaNodeMem node_mem[], Mach=
ineState *ms)
 static int ram_block_notify_add_single(RAMBlock *rb, void *opaque)
 {
     const ram_addr_t max_size =3D qemu_ram_get_max_length(rb);
+    const ram_addr_t size =3D qemu_ram_get_used_length(rb);
     void *host =3D qemu_ram_get_host_addr(rb);
     RAMBlockNotifier *notifier =3D opaque;
=20
     if (host) {
-        notifier->ram_block_added(notifier, host, max_size);
+        notifier->ram_block_added(notifier, host, size, max_size);
     }
     return 0;
 }
@@ -878,20 +879,31 @@ void ram_block_notifier_remove(RAMBlockNotifier *n)
     QLIST_REMOVE(n, next);
 }
=20
-void ram_block_notify_add(void *host, size_t size)
+void ram_block_notify_add(void *host, size_t size, size_t max_size)
 {
     RAMBlockNotifier *notifier;
=20
     QLIST_FOREACH(notifier, &ram_list.ramblock_notifiers, next) {
-        notifier->ram_block_added(notifier, host, size);
+        notifier->ram_block_added(notifier, host, size, max_size);
     }
 }
=20
-void ram_block_notify_remove(void *host, size_t size)
+void ram_block_notify_remove(void *host, size_t size, size_t max_size)
 {
     RAMBlockNotifier *notifier;
=20
     QLIST_FOREACH(notifier, &ram_list.ramblock_notifiers, next) {
-        notifier->ram_block_removed(notifier, host, size);
+        notifier->ram_block_removed(notifier, host, size, max_size);
+    }
+}
+
+void ram_block_notify_resize(void *host, size_t old_size, size_t new_size)
+{
+    RAMBlockNotifier *notifier;
+
+    QLIST_FOREACH(notifier, &ram_list.ramblock_notifiers, next) {
+        if (notifier->ram_block_resized) {
+            notifier->ram_block_resized(notifier, host, old_size, new_size=
);
+        }
     }
 }
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index 5b120ed44b..d6dcea65d1 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -169,7 +169,8 @@ static void xen_remap_bucket(MapCacheEntry *entry,
=20
     if (entry->vaddr_base !=3D NULL) {
         if (!(entry->flags & XEN_MAPCACHE_ENTRY_DUMMY)) {
-            ram_block_notify_remove(entry->vaddr_base, entry->size);
+            ram_block_notify_remove(entry->vaddr_base, entry->size,
+                                    entry->size);
         }
         if (munmap(entry->vaddr_base, entry->size) !=3D 0) {
             perror("unmap fails");
@@ -211,7 +212,7 @@ static void xen_remap_bucket(MapCacheEntry *entry,
     }
=20
     if (!(entry->flags & XEN_MAPCACHE_ENTRY_DUMMY)) {
-        ram_block_notify_add(vaddr_base, size);
+        ram_block_notify_add(vaddr_base, size, size);
     }
=20
     entry->vaddr_base =3D vaddr_base;
@@ -452,7 +453,7 @@ static void xen_invalidate_map_cache_entry_unlocked(uin=
t8_t *buffer)
     }
=20
     pentry->next =3D entry->next;
-    ram_block_notify_remove(entry->vaddr_base, entry->size);
+    ram_block_notify_remove(entry->vaddr_base, entry->size, entry->size);
     if (munmap(entry->vaddr_base, entry->size) !=3D 0) {
         perror("unmap fails");
         exit(-1);
diff --git a/include/exec/ramlist.h b/include/exec/ramlist.h
index bc4faa1b00..293c0ddabe 100644
--- a/include/exec/ramlist.h
+++ b/include/exec/ramlist.h
@@ -65,15 +65,20 @@ void qemu_mutex_lock_ramlist(void);
 void qemu_mutex_unlock_ramlist(void);
=20
 struct RAMBlockNotifier {
-    void (*ram_block_added)(RAMBlockNotifier *n, void *host, size_t size);
-    void (*ram_block_removed)(RAMBlockNotifier *n, void *host, size_t size=
);
+    void (*ram_block_added)(RAMBlockNotifier *n, void *host, size_t size,
+                            size_t max_size);
+    void (*ram_block_removed)(RAMBlockNotifier *n, void *host, size_t size=
,
+                              size_t max_size);
+    void (*ram_block_resized)(RAMBlockNotifier *n, void *host, size_t old_=
size,
+                              size_t new_size);
     QLIST_ENTRY(RAMBlockNotifier) next;
 };
=20
 void ram_block_notifier_add(RAMBlockNotifier *n);
 void ram_block_notifier_remove(RAMBlockNotifier *n);
-void ram_block_notify_add(void *host, size_t size);
-void ram_block_notify_remove(void *host, size_t size);
+void ram_block_notify_add(void *host, size_t size, size_t max_size);
+void ram_block_notify_remove(void *host, size_t size, size_t max_size);
+void ram_block_notify_resize(void *host, size_t old_size, size_t new_size)=
;
=20
 void ram_block_dump(Monitor *mon);
=20
diff --git a/target/i386/hax-mem.c b/target/i386/hax-mem.c
index 6bb5a24917..454d7fb212 100644
--- a/target/i386/hax-mem.c
+++ b/target/i386/hax-mem.c
@@ -293,7 +293,8 @@ static MemoryListener hax_memory_listener =3D {
     .priority =3D 10,
 };
=20
-static void hax_ram_block_added(RAMBlockNotifier *n, void *host, size_t si=
ze)
+static void hax_ram_block_added(RAMBlockNotifier *n, void *host, size_t si=
ze,
+                                size_t max_size)
 {
     /*
      * We must register each RAM block with the HAXM kernel module, or
@@ -304,7 +305,7 @@ static void hax_ram_block_added(RAMBlockNotifier *n, vo=
id *host, size_t size)
      * host physical pages for the RAM block as part of this registration
      * process, hence the name hax_populate_ram().
      */
-    if (hax_populate_ram((uint64_t)(uintptr_t)host, size) < 0) {
+    if (hax_populate_ram((uint64_t)(uintptr_t)host, max_size) < 0) {
         fprintf(stderr, "HAX failed to populate RAM\n");
         abort();
     }
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 846018a12d..65d852adf8 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -129,7 +129,8 @@ sev_set_guest_state(SevState new_state)
 }
=20
 static void
-sev_ram_block_added(RAMBlockNotifier *n, void *host, size_t size)
+sev_ram_block_added(RAMBlockNotifier *n, void *host, size_t size,
+                    size_t max_size)
 {
     int r;
     struct kvm_enc_region range;
@@ -146,19 +147,20 @@ sev_ram_block_added(RAMBlockNotifier *n, void *host, =
size_t size)
     }
=20
     range.addr =3D (__u64)(unsigned long)host;
-    range.size =3D size;
+    range.size =3D max_size;
=20
-    trace_kvm_memcrypt_register_region(host, size);
+    trace_kvm_memcrypt_register_region(host, max_size);
     r =3D kvm_vm_ioctl(kvm_state, KVM_MEMORY_ENCRYPT_REG_REGION, &range);
     if (r) {
         error_report("%s: failed to register region (%p+%#zx) error '%s'",
-                     __func__, host, size, strerror(errno));
+                     __func__, host, max_size, strerror(errno));
         exit(1);
     }
 }
=20
 static void
-sev_ram_block_removed(RAMBlockNotifier *n, void *host, size_t size)
+sev_ram_block_removed(RAMBlockNotifier *n, void *host, size_t size,
+                      size_t max_size)
 {
     int r;
     struct kvm_enc_region range;
@@ -175,13 +177,13 @@ sev_ram_block_removed(RAMBlockNotifier *n, void *host=
, size_t size)
     }
=20
     range.addr =3D (__u64)(unsigned long)host;
-    range.size =3D size;
+    range.size =3D max_size;
=20
-    trace_kvm_memcrypt_unregister_region(host, size);
+    trace_kvm_memcrypt_unregister_region(host, max_size);
     r =3D kvm_vm_ioctl(kvm_state, KVM_MEMORY_ENCRYPT_UNREG_REGION, &range)=
;
     if (r) {
         error_report("%s: failed to unregister region (%p+%#zx)",
-                     __func__, host, size);
+                     __func__, host, max_size);
     }
 }
=20
diff --git a/util/vfio-helpers.c b/util/vfio-helpers.c
index 260570ae19..9ec01bfe26 100644
--- a/util/vfio-helpers.c
+++ b/util/vfio-helpers.c
@@ -372,26 +372,26 @@ fail_container:
     return ret;
 }
=20
-static void qemu_vfio_ram_block_added(RAMBlockNotifier *n,
-                                      void *host, size_t size)
+static void qemu_vfio_ram_block_added(RAMBlockNotifier *n, void *host,
+                                      size_t size, size_t max_size)
 {
     QEMUVFIOState *s =3D container_of(n, QEMUVFIOState, ram_notifier);
     int ret;
=20
-    trace_qemu_vfio_ram_block_added(s, host, size);
-    ret =3D qemu_vfio_dma_map(s, host, size, false, NULL);
+    trace_qemu_vfio_ram_block_added(s, host, max_size);
+    ret =3D qemu_vfio_dma_map(s, host, max_size, false, NULL);
     if (ret) {
-        error_report("qemu_vfio_dma_map(%p, %zu) failed: %s", host, size,
+        error_report("qemu_vfio_dma_map(%p, %zu) failed: %s", host, max_si=
ze,
                      strerror(-ret));
     }
 }
=20
-static void qemu_vfio_ram_block_removed(RAMBlockNotifier *n,
-                                        void *host, size_t size)
+static void qemu_vfio_ram_block_removed(RAMBlockNotifier *n, void *host,
+                                        size_t size, size_t max_size)
 {
     QEMUVFIOState *s =3D container_of(n, QEMUVFIOState, ram_notifier);
     if (host) {
-        trace_qemu_vfio_ram_block_removed(s, host, size);
+        trace_qemu_vfio_ram_block_removed(s, host, max_size);
         qemu_vfio_dma_unmap(s, host);
     }
 }
--=20
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 09:08:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 09:08:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQotQ-0007h0-KD; Tue, 21 Apr 2020 09:08:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQotP-0007gv-AQ
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 09:08:35 +0000
X-Inumbo-ID: ace167ae-83af-11ea-911a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ace167ae-83af-11ea-911a-12813bfff9fa;
 Tue, 21 Apr 2020 09:08:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C5F8FAD23;
 Tue, 21 Apr 2020 09:08:31 +0000 (UTC)
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v2 0/4] x86: mm (mainly shadow) adjustments
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Message-ID: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
Date: Tue, 21 Apr 2020 11:08:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

(Not so) large (anymore) parts of this series are to further
isolate pieces which are needed for HVM only, and hence would
better not be built with HVM=n. But there are also a few other
items which I've noticed along the road, including the new in
v2 4th patch.

1: mm: no-one passes a NULL domain to init_xen_l4_slots()
2: shadow: sh_update_linear_entries() is a no-op for PV
3: mm: monitor table is HVM-only
4: adjustments to guest handle treatment

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 09:11:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 09:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQovr-0008Uv-8S; Tue, 21 Apr 2020 09:11:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQovq-0008Ul-FM
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 09:11:06 +0000
X-Inumbo-ID: 073a9a18-83b0-11ea-911a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 073a9a18-83b0-11ea-911a-12813bfff9fa;
 Tue, 21 Apr 2020 09:11:05 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 873A4AC19;
 Tue, 21 Apr 2020 09:11:03 +0000 (UTC)
Subject: [PATCH v2 1/4] x86/mm: no-one passes a NULL domain to
 init_xen_l4_slots()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
Message-ID: <8787b72e-c71e-b75d-2ca0-0c6fe7c8259f@suse.com>
Date: Tue, 21 Apr 2020 11:11:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Drop the NULL checks - they've been introduced by commit 8d7b633ada
("x86/mm: Consolidate all Xen L4 slot writing into
init_xen_l4_slots()") for no apparent reason.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Adjust comment ahead of the function.

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1653,7 +1653,7 @@ static int promote_l3_table(struct page_
  * This function must write all ROOT_PAGETABLE_PV_XEN_SLOTS, to clobber any
  * values a guest may have left there from promote_l4_table().
  *
- * l4t and l4mfn are mandatory, but l4mfn doesn't need to be the mfn under
+ * l4t, l4mfn, and d are mandatory, but l4mfn doesn't need to be the mfn under
  * *l4t.  All other parameters are optional and will either fill or zero the
  * appropriate slots.  Pagetables not shared with guests will gain the
  * extended directmap.
@@ -1665,7 +1665,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t
      * PV vcpus need a shortened directmap.  HVM and Idle vcpus get the full
      * directmap.
      */
-    bool short_directmap = d && !paging_mode_external(d);
+    bool short_directmap = !paging_mode_external(d);
 
     /* Slot 256: RO M2P (if applicable). */
     l4t[l4_table_offset(RO_MPT_VIRT_START)] =
@@ -1686,10 +1686,9 @@ void init_xen_l4_slots(l4_pgentry_t *l4t
         mfn_eq(sl4mfn, INVALID_MFN) ? l4e_empty() :
         l4e_from_mfn(sl4mfn, __PAGE_HYPERVISOR_RW);
 
-    /* Slot 260: Per-domain mappings (if applicable). */
+    /* Slot 260: Per-domain mappings. */
     l4t[l4_table_offset(PERDOMAIN_VIRT_START)] =
-        d ? l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW)
-          : l4e_empty();
+        l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
 
     /* Slot 261-: text/data/bss, RW M2P, vmap, frametable, directmap. */
 #ifndef NDEBUG



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 09:11:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 09:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQowP-0000B2-Q7; Tue, 21 Apr 2020 09:11:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQowO-0000Ai-4E
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 09:11:40 +0000
X-Inumbo-ID: 1b9eefae-83b0-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1b9eefae-83b0-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 09:11:39 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C10C7ACAE;
 Tue, 21 Apr 2020 09:11:37 +0000 (UTC)
Subject: [PATCH v2 2/4] x86/shadow: sh_update_linear_entries() is a no-op for
 PV
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
Message-ID: <c90b72a8-9145-f0fb-8490-4d62a674eed7@suse.com>
Date: Tue, 21 Apr 2020 11:11:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Consolidate the shadow_mode_external() in here: Check this once at the
start of the function.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Delete stale part of comment.
---
Tim - I'm re-posting as I wasn't entirely sure whether you meant to drop
the entire PV part of the comment, or only the last two sentences.

--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3680,20 +3680,7 @@ sh_update_linear_entries(struct vcpu *v)
 {
     struct domain *d = v->domain;
 
-    /* Linear pagetables in PV guests
-     * ------------------------------
-     *
-     * Guest linear pagetables, which map the guest pages, are at
-     * LINEAR_PT_VIRT_START.  Shadow linear pagetables, which map the
-     * shadows, are at SH_LINEAR_PT_VIRT_START.  Most of the time these
-     * are set up at shadow creation time, but (of course!) the PAE case
-     * is subtler.  Normal linear mappings are made by having an entry
-     * in the top-level table that points to itself (shadow linear) or
-     * to the guest top-level table (guest linear).  For PAE, to set up
-     * a linear map requires us to copy the four top-level entries into
-     * level-2 entries.  That means that every time we change a PAE l3e,
-     * we need to reflect the change into the copy.
-     *
+    /*
      * Linear pagetables in HVM guests
      * -------------------------------
      *
@@ -3711,34 +3698,30 @@ sh_update_linear_entries(struct vcpu *v)
      */
 
     /* Don't try to update the monitor table if it doesn't exist */
-    if ( shadow_mode_external(d)
-         && pagetable_get_pfn(v->arch.monitor_table) == 0 )
+    if ( !shadow_mode_external(d) ||
+         pagetable_get_pfn(v->arch.monitor_table) == 0 )
         return;
 
 #if SHADOW_PAGING_LEVELS == 4
 
-    /* For PV, one l4e points at the guest l4, one points at the shadow
-     * l4.  No maintenance required.
-     * For HVM, just need to update the l4e that points to the shadow l4. */
+    /* For HVM, just need to update the l4e that points to the shadow l4. */
 
-    if ( shadow_mode_external(d) )
+    /* Use the linear map if we can; otherwise make a new mapping */
+    if ( v == current )
     {
-        /* Use the linear map if we can; otherwise make a new mapping */
-        if ( v == current )
-        {
-            __linear_l4_table[l4_linear_offset(SH_LINEAR_PT_VIRT_START)] =
-                l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
-                             __PAGE_HYPERVISOR_RW);
-        }
-        else
-        {
-            l4_pgentry_t *ml4e;
-            ml4e = map_domain_page(pagetable_get_mfn(v->arch.monitor_table));
-            ml4e[l4_table_offset(SH_LINEAR_PT_VIRT_START)] =
-                l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
-                             __PAGE_HYPERVISOR_RW);
-            unmap_domain_page(ml4e);
-        }
+        __linear_l4_table[l4_linear_offset(SH_LINEAR_PT_VIRT_START)] =
+            l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
+                         __PAGE_HYPERVISOR_RW);
+    }
+    else
+    {
+        l4_pgentry_t *ml4e;
+
+        ml4e = map_domain_page(pagetable_get_mfn(v->arch.monitor_table));
+        ml4e[l4_table_offset(SH_LINEAR_PT_VIRT_START)] =
+            l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
+                         __PAGE_HYPERVISOR_RW);
+        unmap_domain_page(ml4e);
     }
 
 #elif SHADOW_PAGING_LEVELS == 3
@@ -3752,7 +3735,6 @@ sh_update_linear_entries(struct vcpu *v)
      * the shadows.
      */
 
-    ASSERT(shadow_mode_external(d));
     {
         /* Install copies of the shadow l3es into the monitor l2 table
          * that maps SH_LINEAR_PT_VIRT_START. */
@@ -3803,20 +3785,16 @@ sh_update_linear_entries(struct vcpu *v)
 #error this should not happen
 #endif
 
-    if ( shadow_mode_external(d) )
-    {
-        /*
-         * Having modified the linear pagetable mapping, flush local host TLBs.
-         * This was not needed when vmenter/vmexit always had the side effect
-         * of flushing host TLBs but, with ASIDs, it is possible to finish
-         * this CR3 update, vmenter the guest, vmexit due to a page fault,
-         * without an intervening host TLB flush. Then the page fault code
-         * could use the linear pagetable to read a top-level shadow page
-         * table entry. But, without this change, it would fetch the wrong
-         * value due to a stale TLB.
-         */
-        flush_tlb_local();
-    }
+    /*
+     * Having modified the linear pagetable mapping, flush local host TLBs.
+     * This was not needed when vmenter/vmexit always had the side effect of
+     * flushing host TLBs but, with ASIDs, it is possible to finish this CR3
+     * update, vmenter the guest, vmexit due to a page fault, without an
+     * intervening host TLB flush. Then the page fault code could use the
+     * linear pagetable to read a top-level shadow page table entry. But,
+     * without this change, it would fetch the wrong value due to a stale TLB.
+     */
+    flush_tlb_local();
 }
 
 



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 09:12:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 09:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQox7-0000Lr-D0; Tue, 21 Apr 2020 09:12:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQox6-0000Le-Ez
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 09:12:24 +0000
X-Inumbo-ID: 3602b524-83b0-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3602b524-83b0-11ea-b4f4-bc764e2007e4;
 Tue, 21 Apr 2020 09:12:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 04591AC19;
 Tue, 21 Apr 2020 09:12:21 +0000 (UTC)
Subject: [PATCH v2 3/4] x86/mm: monitor table is HVM-only
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
Message-ID: <c1c385f1-8e9f-af9f-d079-729fa448bb1b@suse.com>
Date: Tue, 21 Apr 2020 11:12:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Move the per-vCPU field to the HVM sub-structure.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -545,7 +545,7 @@ void write_ptbase(struct vcpu *v)
  * Should be called after CR3 is updated.
  *
  * Uses values found in vcpu->arch.(guest_table and guest_table_user), and
- * for HVM guests, arch.monitor_table and hvm's guest CR3.
+ * for HVM guests, arch.hvm.monitor_table and hvm's guest CR3.
  *
  * Update ref counts to shadow tables appropriately.
  */
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -393,7 +393,7 @@ static mfn_t hap_make_monitor_table(stru
     l4_pgentry_t *l4e;
     mfn_t m4mfn;
 
-    ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0);
+    ASSERT(pagetable_get_pfn(v->arch.hvm.monitor_table) == 0);
 
     if ( (pg = hap_alloc(d)) == NULL )
         goto oom;
@@ -579,10 +579,10 @@ void hap_teardown(struct domain *d, bool
         {
             if ( paging_get_hostmode(v) && paging_mode_external(d) )
             {
-                mfn = pagetable_get_mfn(v->arch.monitor_table);
+                mfn = pagetable_get_mfn(v->arch.hvm.monitor_table);
                 if ( mfn_valid(mfn) && (mfn_x(mfn) != 0) )
                     hap_destroy_monitor_table(v, mfn);
-                v->arch.monitor_table = pagetable_null();
+                v->arch.hvm.monitor_table = pagetable_null();
             }
         }
     }
@@ -758,10 +758,10 @@ static void hap_update_paging_modes(stru
 
     v->arch.paging.mode = hap_paging_get_mode(v);
 
-    if ( pagetable_is_null(v->arch.monitor_table) )
+    if ( pagetable_is_null(v->arch.hvm.monitor_table) )
     {
         mfn_t mmfn = hap_make_monitor_table(v);
-        v->arch.monitor_table = pagetable_from_mfn(mmfn);
+        v->arch.hvm.monitor_table = pagetable_from_mfn(mmfn);
         make_cr3(v, mmfn);
         hvm_update_host_cr3(v);
     }
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2465,10 +2465,10 @@ static void sh_update_paging_modes(struc
                 &SHADOW_INTERNAL_NAME(sh_paging_mode, 2);
         }
 
-        if ( pagetable_is_null(v->arch.monitor_table) )
+        if ( pagetable_is_null(v->arch.hvm.monitor_table) )
         {
             mfn_t mmfn = v->arch.paging.mode->shadow.make_monitor_table(v);
-            v->arch.monitor_table = pagetable_from_mfn(mmfn);
+            v->arch.hvm.monitor_table = pagetable_from_mfn(mmfn);
             make_cr3(v, mmfn);
             hvm_update_host_cr3(v);
         }
@@ -2502,10 +2502,10 @@ static void sh_update_paging_modes(struc
                     return;
                 }
 
-                old_mfn = pagetable_get_mfn(v->arch.monitor_table);
-                v->arch.monitor_table = pagetable_null();
+                old_mfn = pagetable_get_mfn(v->arch.hvm.monitor_table);
+                v->arch.hvm.monitor_table = pagetable_null();
                 new_mfn = v->arch.paging.mode->shadow.make_monitor_table(v);
-                v->arch.monitor_table = pagetable_from_mfn(new_mfn);
+                v->arch.hvm.monitor_table = pagetable_from_mfn(new_mfn);
                 SHADOW_PRINTK("new monitor table %"PRI_mfn "\n",
                                mfn_x(new_mfn));
 
@@ -2724,11 +2724,11 @@ void shadow_teardown(struct domain *d, b
 #ifdef CONFIG_HVM
                 if ( shadow_mode_external(d) )
                 {
-                    mfn_t mfn = pagetable_get_mfn(v->arch.monitor_table);
+                    mfn_t mfn = pagetable_get_mfn(v->arch.hvm.monitor_table);
 
                     if ( mfn_valid(mfn) && (mfn_x(mfn) != 0) )
                         v->arch.paging.mode->shadow.destroy_monitor_table(v, mfn);
-                    v->arch.monitor_table = pagetable_null();
+                    v->arch.hvm.monitor_table = pagetable_null();
                 }
 #endif /* CONFIG_HVM */
             }
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1521,7 +1521,7 @@ sh_make_monitor_table(struct vcpu *v)
 {
     struct domain *d = v->domain;
 
-    ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0);
+    ASSERT(pagetable_get_pfn(v->arch.hvm.monitor_table) == 0);
 
     /* Guarantee we can get the memory we need */
     shadow_prealloc(d, SH_type_monitor_table, CONFIG_PAGING_LEVELS);
@@ -3699,7 +3699,7 @@ sh_update_linear_entries(struct vcpu *v)
 
     /* Don't try to update the monitor table if it doesn't exist */
     if ( !shadow_mode_external(d) ||
-         pagetable_get_pfn(v->arch.monitor_table) == 0 )
+         pagetable_get_pfn(v->arch.hvm.monitor_table) == 0 )
         return;
 
 #if SHADOW_PAGING_LEVELS == 4
@@ -3717,7 +3717,7 @@ sh_update_linear_entries(struct vcpu *v)
     {
         l4_pgentry_t *ml4e;
 
-        ml4e = map_domain_page(pagetable_get_mfn(v->arch.monitor_table));
+        ml4e = map_domain_page(pagetable_get_mfn(v->arch.hvm.monitor_table));
         ml4e[l4_table_offset(SH_LINEAR_PT_VIRT_START)] =
             l4e_from_pfn(pagetable_get_pfn(v->arch.shadow_table[0]),
                          __PAGE_HYPERVISOR_RW);
@@ -3752,7 +3752,7 @@ sh_update_linear_entries(struct vcpu *v)
             l4_pgentry_t *ml4e;
             l3_pgentry_t *ml3e;
             int linear_slot = shadow_l4_table_offset(SH_LINEAR_PT_VIRT_START);
-            ml4e = map_domain_page(pagetable_get_mfn(v->arch.monitor_table));
+            ml4e = map_domain_page(pagetable_get_mfn(v->arch.hvm.monitor_table));
 
             ASSERT(l4e_get_flags(ml4e[linear_slot]) & _PAGE_PRESENT);
             l3mfn = l4e_get_mfn(ml4e[linear_slot]);
@@ -4087,7 +4087,7 @@ sh_update_cr3(struct vcpu *v, int do_loc
     ///
     if ( shadow_mode_external(d) )
     {
-        make_cr3(v, pagetable_get_mfn(v->arch.monitor_table));
+        make_cr3(v, pagetable_get_mfn(v->arch.hvm.monitor_table));
     }
 #if SHADOW_PAGING_LEVELS == 4
     else // not shadow_mode_external...
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -583,7 +583,6 @@ struct arch_vcpu
     /* guest_table holds a ref to the page, and also a type-count unless
      * shadow refcounts are in use */
     pagetable_t shadow_table[4];        /* (MFN) shadow(s) of guest */
-    pagetable_t monitor_table;          /* (MFN) hypervisor PT (for HVM) */
     unsigned long cr3;                  /* (MA) value to install in HW CR3 */
 
     /*
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -176,6 +176,9 @@ struct hvm_vcpu {
         uint16_t p2midx;
     } fast_single_step;
 
+    /* (MFN) hypervisor page table */
+    pagetable_t         monitor_table;
+
     struct hvm_vcpu_asid n1asid;
 
     u64                 msr_tsc_adjust;



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 09:13:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 09:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQoy7-0000VU-R5; Tue, 21 Apr 2020 09:13:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQoy6-0000VK-Rk
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 09:13:26 +0000
X-Inumbo-ID: 5ad83180-83b0-11ea-911a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5ad83180-83b0-11ea-911a-12813bfff9fa;
 Tue, 21 Apr 2020 09:13:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B1559AD23;
 Tue, 21 Apr 2020 09:13:23 +0000 (UTC)
Subject: [PATCH v2 4/4] x86: adjustments to guest handle treatment
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
Message-ID: <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
Date: Tue, 21 Apr 2020 11:13:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

First of all avoid excessive conversions. copy_{from,to}_guest(), for
example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().

Further
- do_physdev_op_compat() didn't use the param form for its parameter,
- {hap,shadow}_track_dirty_vram() wrongly used the param form,
- compat processor Px logic failed to check compatibility of native and
  compat structures not further converted.

As this eliminates all users of guest_handle_from_param() and as there's
no real need to allow for conversions in both directions, drop the
macros as well.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.

--- a/xen/arch/x86/compat.c
+++ b/xen/arch/x86/compat.c
@@ -15,7 +15,7 @@ typedef long ret_t;
 #endif
 
 /* Legacy hypercall (as of 0x00030202). */
-ret_t do_physdev_op_compat(XEN_GUEST_HANDLE(physdev_op_t) uop)
+ret_t do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
 {
     typeof(do_physdev_op) *fn =
         (void *)pv_hypercall_table[__HYPERVISOR_physdev_op].native;
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -678,7 +678,7 @@ static long microcode_update_helper(void
     return ret;
 }
 
-int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
+int microcode_update(XEN_GUEST_HANDLE(const_void) buf, unsigned long len)
 {
     int ret;
     struct ucode_buf *buffer;
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4441,20 +4441,16 @@ static int _handle_iomem_range(unsigned
 {
     if ( s > ctxt->s && !(s >> (paddr_bits - PAGE_SHIFT)) )
     {
-        e820entry_t ent;
-        XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;
-        XEN_GUEST_HANDLE(e820entry_t) buffer;
-
         if ( !guest_handle_is_null(ctxt->map.buffer) )
         {
+            e820entry_t ent;
+
             if ( ctxt->n + 1 >= ctxt->map.nr_entries )
                 return -EINVAL;
             ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT;
             ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT;
             ent.type = E820_RESERVED;
-            buffer_param = guest_handle_cast(ctxt->map.buffer, e820entry_t);
-            buffer = guest_handle_from_param(buffer_param, e820entry_t);
-            if ( __copy_to_guest_offset(buffer, ctxt->n, &ent, 1) )
+            if ( __copy_to_guest_offset(ctxt->map.buffer, ctxt->n, &ent, 1) )
                 return -EFAULT;
         }
         ctxt->n++;
@@ -4715,8 +4711,7 @@ long arch_memory_op(unsigned long cmd, X
     case XENMEM_machine_memory_map:
     {
         struct memory_map_context ctxt;
-        XEN_GUEST_HANDLE(e820entry_t) buffer;
-        XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;
+        XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer;
         unsigned int i;
         bool store;
 
@@ -4732,8 +4727,7 @@ long arch_memory_op(unsigned long cmd, X
         if ( store && ctxt.map.nr_entries < e820.nr_map + 1 )
             return -EINVAL;
 
-        buffer_param = guest_handle_cast(ctxt.map.buffer, e820entry_t);
-        buffer = guest_handle_from_param(buffer_param, e820entry_t);
+        buffer = guest_handle_cast(ctxt.map.buffer, e820entry_t);
         if ( store && !guest_handle_okay(buffer, ctxt.map.nr_entries) )
             return -EFAULT;
 
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -59,7 +59,7 @@
 int hap_track_dirty_vram(struct domain *d,
                          unsigned long begin_pfn,
                          unsigned long nr,
-                         XEN_GUEST_HANDLE_PARAM(void) guest_dirty_bitmap)
+                         XEN_GUEST_HANDLE(void) guest_dirty_bitmap)
 {
     long rc = 0;
     struct sh_dirty_vram *dirty_vram;
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3171,7 +3171,7 @@ static void sh_clean_dirty_bitmap(struct
 int shadow_track_dirty_vram(struct domain *d,
                             unsigned long begin_pfn,
                             unsigned long nr,
-                            XEN_GUEST_HANDLE_PARAM(void) guest_dirty_bitmap)
+                            XEN_GUEST_HANDLE(void) guest_dirty_bitmap)
 {
     int rc = 0;
     unsigned long end_pfn = begin_pfn + nr;
--- a/xen/arch/x86/oprofile/backtrace.c
+++ b/xen/arch/x86/oprofile/backtrace.c
@@ -74,11 +74,8 @@ dump_guest_backtrace(struct vcpu *vcpu,
     }
     else
     {
-        XEN_GUEST_HANDLE(const_frame_head_t) guest_head;
-        XEN_GUEST_HANDLE_PARAM(const_frame_head_t) guest_head_param =
+        XEN_GUEST_HANDLE_PARAM(const_frame_head_t) guest_head =
             const_guest_handle_from_ptr(head, frame_head_t);
-        guest_head = guest_handle_from_param(guest_head_param,
-					     const_frame_head_t);
 
         /* Also check accessibility of one struct frame_head beyond */
         if (!guest_handle_okay(guest_head, 2))
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -285,9 +285,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PA
 
         guest_from_compat_handle(data, op->u.microcode.data);
 
-        ret = microcode_update(
-                guest_handle_to_param(data, const_void),
-                op->u.microcode.length);
+        ret = microcode_update(data, op->u.microcode.length);
     }
     break;
 
@@ -531,9 +529,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PA
             XEN_GUEST_HANDLE(uint32) pdc;
 
             guest_from_compat_handle(pdc, op->u.set_pminfo.u.pdc);
-            ret = acpi_set_pdc_bits(
-                    op->u.set_pminfo.id,
-                    guest_handle_to_param(pdc, uint32));
+            ret = acpi_set_pdc_bits(op->u.set_pminfo.id, pdc);
         }
         break;
 
--- a/xen/arch/x86/x86_64/compat.c
+++ b/xen/arch/x86/x86_64/compat.c
@@ -15,6 +15,7 @@ EMIT_FILE;
 
 #define COMPAT
 #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t)
+#define _XEN_GUEST_HANDLE_PARAM(t) XEN_GUEST_HANDLE_PARAM(t)
 typedef int ret_t;
 
 #include "../compat.c"
--- a/xen/arch/x86/x86_64/cpu_idle.c
+++ b/xen/arch/x86/x86_64/cpu_idle.c
@@ -52,13 +52,9 @@ static int copy_from_compat_state(xen_pr
                                   compat_processor_cx_t *state)
 {
 #define XLAT_processor_cx_HNDL_dp(_d_, _s_) do { \
-    XEN_GUEST_HANDLE(compat_processor_csd_t) dps; \
-    XEN_GUEST_HANDLE_PARAM(xen_processor_csd_t) dps_param; \
     if ( unlikely(!compat_handle_okay((_s_)->dp, (_s_)->dpcnt)) ) \
-            return -EFAULT; \
-    guest_from_compat_handle(dps, (_s_)->dp); \
-    dps_param = guest_handle_cast(dps, xen_processor_csd_t); \
-    (_d_)->dp = guest_handle_from_param(dps_param, xen_processor_csd_t); \
+        return -EFAULT; \
+    guest_from_compat_handle((_d_)->dp, (_s_)->dp); \
 } while (0)
     XLAT_processor_cx(xen_state, state);
 #undef XLAT_processor_cx_HNDL_dp
--- a/xen/arch/x86/x86_64/cpufreq.c
+++ b/xen/arch/x86/x86_64/cpufreq.c
@@ -26,6 +26,8 @@
 #include <xen/pmstat.h>
 #include <compat/platform.h>
 
+CHECK_processor_px;
+
 DEFINE_XEN_GUEST_HANDLE(compat_processor_px_t);
 
 int 
@@ -42,13 +44,9 @@ compat_set_px_pminfo(uint32_t cpu, struc
 	return -EFAULT;
 
 #define XLAT_processor_performance_HNDL_states(_d_, _s_) do { \
-    XEN_GUEST_HANDLE(compat_processor_px_t) states; \
-    XEN_GUEST_HANDLE_PARAM(xen_processor_px_t) states_t; \
     if ( unlikely(!compat_handle_okay((_s_)->states, (_s_)->state_count)) ) \
         return -EFAULT; \
-    guest_from_compat_handle(states, (_s_)->states); \
-    states_t = guest_handle_cast(states, xen_processor_px_t); \
-    (_d_)->states = guest_handle_from_param(states_t, xen_processor_px_t); \
+    guest_from_compat_handle((_d_)->states, (_s_)->states); \
 } while (0)
 
     XLAT_processor_performance(xen_perf, perf);
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -492,7 +492,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op
     return ret;
 }
 
-int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
+int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32) pdc)
 {
     u32 bits[3];
     int ret;
--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -40,7 +40,7 @@ int access_guest_memory_by_ipa(struct do
     (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
 })
 
-/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
+/* Convert a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
 #define guest_handle_to_param(hnd, type) ({                  \
     typeof((hnd).p) _x = (hnd).p;                            \
     XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
@@ -51,18 +51,6 @@ int access_guest_memory_by_ipa(struct do
     _y;                                                      \
 })
 
-
-/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
-#define guest_handle_from_param(hnd, type) ({               \
-    typeof((hnd).p) _x = (hnd).p;                           \
-    XEN_GUEST_HANDLE(type) _y = { _x };                     \
-    /* type checking: make sure that the pointers inside    \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
-     * the same type, then return hnd */                    \
-    (void)(&_x == &_y.p);                                   \
-    _y;                                                     \
-})
-
 #define guest_handle_for_field(hnd, type, fld)          \
     ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
 
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -52,21 +52,11 @@
     (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
 })
 
-/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
+/* Convert a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
 #define guest_handle_to_param(hnd, type) ({                  \
     /* type checking: make sure that the pointers inside     \
      * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
      * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
-})
-
-/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
-#define guest_handle_from_param(hnd, type) ({                \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
     (void)((typeof(&(hnd).p)) 0 ==                           \
         (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
     (hnd);                                                   \
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -41,7 +41,7 @@ void  hap_vcpu_init(struct vcpu *v);
 int   hap_track_dirty_vram(struct domain *d,
                            unsigned long begin_pfn,
                            unsigned long nr,
-                           XEN_GUEST_HANDLE_PARAM(void) dirty_bitmap);
+                           XEN_GUEST_HANDLE(void) dirty_bitmap);
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
 int hap_set_allocation(struct domain *d, unsigned int pages, bool *preempted);
--- a/xen/include/asm-x86/microcode.h
+++ b/xen/include/asm-x86/microcode.h
@@ -20,7 +20,7 @@ struct cpu_signature {
 DECLARE_PER_CPU(struct cpu_signature, cpu_sig);
 
 void microcode_set_module(unsigned int idx);
-int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len);
+int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);
 int early_microcode_init(void);
 int microcode_update_one(bool start_update);
 
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -64,7 +64,7 @@ int shadow_enable(struct domain *d, u32
 int shadow_track_dirty_vram(struct domain *d,
                             unsigned long first_pfn,
                             unsigned long nr,
-                            XEN_GUEST_HANDLE_PARAM(void) dirty_bitmap);
+                            XEN_GUEST_HANDLE(void) dirty_bitmap);
 
 /* Handler for shadow control ops: operations from user-space to enable
  * and disable ephemeral shadow modes (test mode and log-dirty mode) and
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -184,8 +184,8 @@ static inline unsigned int acpi_get_csub
 static inline void acpi_set_csubstate_limit(unsigned int new_limit) { return; }
 #endif
 
-#ifdef XEN_GUEST_HANDLE_PARAM
-int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32));
+#ifdef XEN_GUEST_HANDLE
+int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32));
 #endif
 int arch_acpi_set_pdc_bits(u32 acpi_id, u32 *, u32 mask);
 



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 09:21:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 09:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQp6E-0001OT-Sd; Tue, 21 Apr 2020 09:21:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQp6E-0001OO-1v
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 09:21:50 +0000
X-Inumbo-ID: 87426744-83b1-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 87426744-83b1-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 09:21:49 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 82D34AD8E;
 Tue, 21 Apr 2020 09:21:47 +0000 (UTC)
Subject: Re: [PATCH v15 2/3] mem_sharing: allow forking domain with IOMMU
 enabled
To: Tamas K Lengyel <tamas.lengyel@intel.com>
References: <cover.1587142844.git.tamas.lengyel@intel.com>
 <0be7501ace42d856b344828755ece18659dabd33.1587142844.git.tamas.lengyel@intel.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8d9a7e20-3f8b-2a32-fe65-1a14630489db@suse.com>
Date: Tue, 21 Apr 2020 11:21:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <0be7501ace42d856b344828755ece18659dabd33.1587142844.git.tamas.lengyel@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 19:06, Tamas K Lengyel wrote:
> @@ -2063,9 +2065,10 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>      case XENMEM_sharing_op_fork:
>      {
>          struct domain *pd;
> +        bool allow_iommu;
>  
>          rc = -EINVAL;
> -        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[2] )
> +        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] )
>              goto out;

Rather than outright dropping this, you now want to bail on
any bits set in flags except the one that's currently defined.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 10:02:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 10:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQpj8-0004xD-6H; Tue, 21 Apr 2020 10:02:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQpj6-0004x8-UZ
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 10:02:00 +0000
X-Inumbo-ID: 23b89896-83b7-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 23b89896-83b7-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 10:01:59 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B11D7ABF4;
 Tue, 21 Apr 2020 10:01:57 +0000 (UTC)
Subject: Re: [PATCH 1/1] x86/vtd: Mask DMAR faults for IGD devices
To: Brendan Kerrigan <brendank310@gmail.com>
References: <20200417133626.72302-1-brendank310@gmail.com>
 <20200417133626.72302-2-brendank310@gmail.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <2738a150-89b4-0ffa-aa25-4e6a99bd3be8@suse.com>
Date: Tue, 21 Apr 2020 12:01:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200417133626.72302-2-brendank310@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, kevin.tian@intel.com,
 Brendan Kerrigan <kerriganb@ainfosec.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 15:36, Brendan Kerrigan wrote:
> The Intel graphics device records DMAR faults regardless
> of the Fault Process Disable bit being set.

I can't seem to be able to find a place where we would set FPD.
Why do we need the workaround then, or what am I missing?

> When this fault
> occurs, enable the Interrupt Mask (IM) bit in the Fault
> Event Control (FECTL) register to prevent the continued
> recording of the fault.

This should mention the underlying erratum in one way or another.

> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -41,6 +41,8 @@
>  #include "vtd.h"
>  #include "../ats.h"
>  
> +#define IS_IGD(seg, id) (0 == seg && 0 == PCI_BUS(id) && 2 == PCI_SLOT(id) && 0 == PCI_FUNC(id))
> +
>  struct mapped_rmrr {
>      struct list_head list;
>      u64 base, end;
> @@ -872,6 +874,13 @@ static int iommu_page_fault_do_one(struct vtd_iommu *iommu, int type,
>      printk(XENLOG_G_WARNING VTDPREFIX "%s: reason %02x - %s\n",
>             kind, fault_reason, reason);
>  
> +    if ( DMA_REMAP == fault_type && type && IS_IGD(seg, source_id) ) {

Using existing infrastructure would be at least some improvement, in
particular to avoid this workaround triggering on unaffected
hardware (including such where there's something else at 0000:00:02.0).
See e.g. is_igd_drhd(), and note that most uses of it are currently
further qualified to limit what hardware quirk workarounds get applied
to. In any event you'll want to clarify in the description that this
won't ever be done on hardware not having this issue, at least as long
as this isn't obvious from the code.

Also - why the "type" part of the conditional? The erratum text
doesn't talk about only DMA reads being affected.

Finally, style-wise the brace belongs on its own line.

> +        u32 fectl = dmar_readl(iommu->reg, DMAR_FECTL_REG);
> +        fectl |= DMA_FECTL_IM;

While this is the recommended workaround, I don't see you undoing
the masking anywhere later, and I'm also unconvinced this should be
done upon seeing the first fault. One option might be to do so on the
the first fault when FPD is set for the offending device. Or else,
following the title, it might want/need doing unconditionally at
initialization time.

> +        dmar_writel(iommu->reg, DMAR_FECTL_REG, fectl);
> +        printk(XENLOG_G_WARNING VTDPREFIX "Disabling DMAR faults for IGD\n");

If, as suggested above, IM will get cleared again at some point,
this printk() should imo not be issued more than once.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 10:02:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 10:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQpju-0004zY-KT; Tue, 21 Apr 2020 10:02:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=YDxJ=6F=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jQpjt-0004zR-Di
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 10:02:49 +0000
X-Inumbo-ID: 4188ae74-83b7-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4188ae74-83b7-11ea-9e09-bc764e2007e4;
 Tue, 21 Apr 2020 10:02:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=qYEMQ5cVkkzjo74NoNs/EBSLtEjotkHHvf/NsOcC6C0=; b=l/5k8GG/IcBBLc1XF28ahoR++N
 Ke09MqEngVFZBJ4lfMIzrpZtg6j/pcCa6017nsbX/qTHr0ljmLGvBxlERPwlOwh+N09IJZSH6ftPw
 85ewGplON/jgHiK532mJ8iUyAxpeOUgRWJ05ttEVxePI4YENTujhWWX3c7T6cHFkl1sc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jQpjs-00043g-MZ; Tue, 21 Apr 2020 10:02:48 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jQpjs-0008Ig-DV; Tue, 21 Apr 2020 10:02:48 +0000
Date: Tue, 21 Apr 2020 11:02:45 +0100
From: Wei Liu <wl@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86: Enumeration for Control-flow Enforcement Technology
Message-ID: <20200421100245.sdd7cy2i55xwaxu6@debian>
References: <20200420190829.17874-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200420190829.17874-1-andrew.cooper3@citrix.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 20, 2020 at 08:08:29PM +0100, Andrew Cooper wrote:
> The CET spec has been published and guest kernels are starting to get support.
> Introduce the CPUID and MSRs, and fully block the MSRs from guest use.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 10:21:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 10:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQq1l-0006mH-9w; Tue, 21 Apr 2020 10:21:17 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQq1j-0006mC-UR
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 10:21:15 +0000
X-Inumbo-ID: d463a788-83b9-11ea-9123-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d463a788-83b9-11ea-9123-12813bfff9fa;
 Tue, 21 Apr 2020 10:21:14 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 36466ABAD;
 Tue, 21 Apr 2020 10:21:12 +0000 (UTC)
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: Roger Pau Monne <roger.pau@citrix.com>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <80288e76-aff6-61d5-71aa-ae7c8e9d9a65@suse.com>
Date: Tue, 21 Apr 2020 12:21:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416135909.16155-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 16.04.2020 15:59, Roger Pau Monne wrote:
> Introduce a specific flag to request a HVM guest linear TLB flush,
> which is an ASID/VPID tickle that forces a guest linear to guest
> physical TLB flush for all HVM guests.
> 
> This was previously unconditionally done in each pre_flush call, but
> that's not required: HVM guests not using shadow don't require linear
> TLB flushes as Xen doesn't modify the guest page tables in that case
> (ie: when using HAP).

I'm afraid I'm being confused by this: Even in shadow mode Xen
doesn't modify guest page tables, does it?

> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
>  
>      return flags;
>  }
> +
> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
> +{
> +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
> +                                                                   : 0) |
> +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> +                                                          : 0);

Why the is_pv_domain() part of the condition? Afaict for PV
domains you can get here only if they have shadow mode enabled.

> --- a/xen/arch/x86/mm/shadow/private.h
> +++ b/xen/arch/x86/mm/shadow/private.h
> @@ -818,6 +818,12 @@ static inline int sh_check_page_has_no_refs(struct page_info *page)
>  bool shadow_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
>                        void *ctxt);
>  
> +static inline void sh_flush_local(const struct domain *d)
> +{
> +    flush_local(FLUSH_TLB |
> +                (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE : 0));
> +}

I think the right side of | wants folding with its counterpart in
guest_flush_tlb_mask(). Doing so would avoid guest_flush_tlb_mask()
getting updated but this one forgotten. Perhaps split out
guest_flush_tlb_flags() from guest_flush_tlb_mask()?

I also think this function should move into multi.c as long as it's
needed only there.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 10:33:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 10:33:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQqDs-0007ki-G0; Tue, 21 Apr 2020 10:33:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=5BlT=6F=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQqDr-0007kd-9s
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 10:33:47 +0000
X-Inumbo-ID: 944b9352-83bb-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 944b9352-83bb-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 10:33:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587465226;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=9wLs3cwz/7QnXCIqkz1OOmDUM/zdSH/1b9Yue3Cg6cU=;
 b=AjUaYf+Ld+JC2Bwk0Amxf9fjDpI07/WviHjz3wLKje6ZowHDdKa3a569
 LnXyRmkcVpADkZKLSrPK2szlwE766QaE9ecK0PMuL0aokUgh3Y4zYHR6o
 dcuS58c3kvb/jl9pQ+5LX96pMEH2lc4IqxCh05sY3YyaNmruZrWLm0z01 c=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: CTj4r/FoTU0XdijLSqw9ics0an6TeNYyw1SIKjvHGynHI4DRm8BOEaObiHQ8VOlkeE969JEl+t
 jVb8vTZ8UlWElfbCUj4r09D7w7YTzFGK7z35HIQY5U/EIEXU5/m8WBOf7Bav05xmoCdnYBOmol
 B2eHDZcjaj/cx8mAP748+p53fykvbPN2RULRt8FTnZ/PEp5PRk0+F+bJeCxH3NlzY40aIm0Ur8
 Pz6gq/rJQAyp1FV2Kpn/HpH41HWMfYhrt0zb/JXrwT/I2WsoZSTfSuNqWZ1jWmmuLptdPix1z0
 QLY=
X-SBRS: 2.7
X-MesageID: 16669326
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16669326"
Subject: Re: [PATCH] x86: Enumeration for Control-flow Enforcement Technology
To: Jan Beulich <jbeulich@suse.com>
References: <20200420190829.17874-1-andrew.cooper3@citrix.com>
 <3c085f0c-134d-ae56-c529-60ea8e61b1be@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <44e6f6e8-3e79-11ac-58a5-59ed27fbe1bf@citrix.com>
Date: Tue, 21 Apr 2020 11:33:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3c085f0c-134d-ae56-c529-60ea8e61b1be@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21/04/2020 08:11, Jan Beulich wrote:
> On 20.04.2020 21:08, Andrew Cooper wrote:
>> --- a/xen/include/public/arch-x86/cpufeatureset.h
>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
>> @@ -229,6 +229,7 @@ XEN_CPUFEATURE(UMIP,          6*32+ 2) /*S  User Mode Instruction Prevention */
>>  XEN_CPUFEATURE(PKU,           6*32+ 3) /*H  Protection Keys for Userspace */
>>  XEN_CPUFEATURE(OSPKE,         6*32+ 4) /*!  OS Protection Keys Enable */
>>  XEN_CPUFEATURE(AVX512_VBMI2,  6*32+ 6) /*A  Additional AVX-512 Vector Byte Manipulation Instrs */
>> +XEN_CPUFEATURE(CET_SS,        6*32+ 7) /*   CET - Shadow Stacks */
>>  XEN_CPUFEATURE(GFNI,          6*32+ 8) /*A  Galois Field Instrs */
>>  XEN_CPUFEATURE(VAES,          6*32+ 9) /*A  Vector AES Instrs */
>>  XEN_CPUFEATURE(VPCLMULQDQ,    6*32+10) /*A  Vector Carry-less Multiplication Instrs */
>> @@ -255,6 +256,7 @@ XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation Single
>>  XEN_CPUFEATURE(MD_CLEAR,      9*32+10) /*A  VERW clears microarchitectural buffers */
>>  XEN_CPUFEATURE(TSX_FORCE_ABORT, 9*32+13) /* MSR_TSX_FORCE_ABORT.RTM_ABORT */
>>  XEN_CPUFEATURE(IBRSB,         9*32+26) /*A  IBRS and IBPB support (used by Intel) */
>> +XEN_CPUFEATURE(CET_IBT,       6*32+20) /*   CET - Indirect Branch Tracking */
> s/6/9/, moved up a line, and then

Oops.  I only spotted during final review that CET-SS and CET-IBT are in
different feature leaves, then failed at adjusting the CET-IBT adequately.

> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thanks,

>
> I take it you intentionally don't mean to add #CP related bits yet,
> first and foremost TRAP_control_flow or some such, as well as its
> error code bits? Nor definitions for the bits within the MSRs you
> add, nor XSAVE pieces?

Those pieces aren't necessary to hide the MSRs, whereas this patch wants
backporting in due course.  Every "make the MSRs have correct
architectural properties" will until MSR handling is fixed properly (and
by this, I mean no default cases which leak state/availability, or
discard writes).

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 10:43:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 10:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQqNV-0000Eh-HG; Tue, 21 Apr 2020 10:43:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Zbep=6F=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jQqNU-0000Ec-IJ
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 10:43:44 +0000
X-Inumbo-ID: f80f3406-83bc-11ea-9123-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f80f3406-83bc-11ea-9123-12813bfff9fa;
 Tue, 21 Apr 2020 10:43:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587465822;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=hInLTlMqqYT4W2C4qBKheXcnwqmrBCfPj09AVeWtvO8=;
 b=U2oFoFfGRgA+vzig4QnIvDun+WiPdTtuhQWrF6x6udHq7gnx/0gywI16
 nabtt/XjZiaJ1+1NLqVV4u8Q0inOb2kwCvRmgM21eqheff5f5Ki0oPmgN
 +/40RgQhOyYyCwUJCjCyxr5URIcrYKX65mweT9P/EKP07cbwHQjxgrHJk 8=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: zL0XnSXuyOUbPlOkfG+xKKetCQ/USDct8YzlERuXbteFWJ0MiNVEJ3/i+ynJLq7ggLjrPKB4g6
 sW/ryoxJBQCmoH8Qhw6CQKjZK4cTj99whYe2aiD/iehVaJLw19f/Giu5Lza2LH/CzWlC2saZMh
 EByDe9yxRL4IFJGqEmwx4NXtjkmge1ws5itl8rMzi1rNT+gFvNhdL8NCilDZxcs8gjySkwn2Lo
 07p0xj69uDneJpw5S+FQtpxoLS7PxTcxr3+2MWUgu0kakoIj8xW5eSNP40q078hFDszqqREW6K
 vV0=
X-SBRS: 2.7
X-MesageID: 16669647
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16669647"
Date: Tue, 21 Apr 2020 12:43:35 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200421104335.GU28601@Air-de-Roger>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <80288e76-aff6-61d5-71aa-ae7c8e9d9a65@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <80288e76-aff6-61d5-71aa-ae7c8e9d9a65@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 12:21:12PM +0200, Jan Beulich wrote:
> On 16.04.2020 15:59, Roger Pau Monne wrote:
> > Introduce a specific flag to request a HVM guest linear TLB flush,
> > which is an ASID/VPID tickle that forces a guest linear to guest
> > physical TLB flush for all HVM guests.
> > 
> > This was previously unconditionally done in each pre_flush call, but
> > that's not required: HVM guests not using shadow don't require linear
> > TLB flushes as Xen doesn't modify the guest page tables in that case
> > (ie: when using HAP).
> 
> I'm afraid I'm being confused by this: Even in shadow mode Xen
> doesn't modify guest page tables, does it?

I'm also confused now. It's my understand that when running in shadow
mode guest page tables are not actually used, and the guest uses Xen's
crafted shadow tables instead, which are based on the original guest
page tables suitably adjusted by Xen in order to do the p2m
translation in the HVM case, or the needed PTE adjustments in the PV
case.

So guest page tables are not modified, but are also not used as they
are never loaded into cr3.

> > @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
> >  
> >      return flags;
> >  }
> > +
> > +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
> > +{
> > +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
> > +                                                                   : 0) |
> > +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> > +                                                          : 0);
> 
> Why the is_pv_domain() part of the condition? Afaict for PV
> domains you can get here only if they have shadow mode enabled.

Right now yes, the only way to get here for PV domains is when using
shadow, but if this helper gets used in other non-shadow PV paths then
Xen's needs to do a TLB flush.

> > --- a/xen/arch/x86/mm/shadow/private.h
> > +++ b/xen/arch/x86/mm/shadow/private.h
> > @@ -818,6 +818,12 @@ static inline int sh_check_page_has_no_refs(struct page_info *page)
> >  bool shadow_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
> >                        void *ctxt);
> >  
> > +static inline void sh_flush_local(const struct domain *d)
> > +{
> > +    flush_local(FLUSH_TLB |
> > +                (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE : 0));
> > +}
> 
> I think the right side of | wants folding with its counterpart in
> guest_flush_tlb_mask(). Doing so would avoid guest_flush_tlb_mask()
> getting updated but this one forgotten. Perhaps split out
> guest_flush_tlb_flags() from guest_flush_tlb_mask()?

Can do.

> I also think this function should move into multi.c as long as it's
> needed only there.

Ack.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 10:45:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 10:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQqPH-0000LO-Uh; Tue, 21 Apr 2020 10:45:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Vwqf=6F=oracle.com=dan.carpenter@srs-us1.protection.inumbo.net>)
 id 1jQqPG-0000LI-M1
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 10:45:34 +0000
X-Inumbo-ID: 3a098b86-83bd-11ea-83d8-bc764e2007e4
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3a098b86-83bd-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 10:45:34 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03LAgWTe122997;
 Tue, 21 Apr 2020 10:45:30 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=date : from : to : cc
 : subject : message-id : mime-version : content-type; s=corp-2020-01-29;
 bh=xjrB8UBkgtQfAZWQWCOIt+Y6oS0Ty5B3R37uMdP+3g8=;
 b=AajEf3fFShsegcoNEW+JOBjqQQJjA0tp/GCYa9eNPSmLaOXf/yM9jOKej/AOhNfme7++
 hLWsdPXhd016jrxVW5SRRY0lkEpt4oDQujFoRYk9rfp5UxJuI7RPAu1YHRUhF6J+5XBe
 rX0FrJBM7p1+aTz0OHCLmjPUOTWcQn++nnuWmix9Md5qq2Vmox2Oi2+EJ6gUcy59T43I
 ONs7z6ViDXSPsts0+kyNj76430QCCB4gzHzAuYBgttFr4/5Uoa9+jsvyOVlB1NZB+LQ1
 UBaUgLjLmxZ3Gp/HJF/6j1p0zVDwkc6tWBIb2xaFC57M459G6blcKHrsP4UtlYF0B19X Dw== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by userp2120.oracle.com with ESMTP id 30ft6n47kv-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 21 Apr 2020 10:45:29 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03LAgTjq031125;
 Tue, 21 Apr 2020 10:45:29 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by aserp3020.oracle.com with ESMTP id 30gbbdenj8-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 21 Apr 2020 10:45:29 +0000
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03LAjSdo016137;
 Tue, 21 Apr 2020 10:45:28 GMT
Received: from mwanda (/41.57.98.10) by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 21 Apr 2020 03:45:28 -0700
Date: Tue, 21 Apr 2020 13:45:22 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: oleksandr_andrushchenko@epam.com
Subject: [bug report] drm/xen-front: Add support for Xen PV display frontend
Message-ID: <20200421104522.GA86681@mwanda>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9597
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 suspectscore=3 mlxlogscore=999 adultscore=0 mlxscore=0 phishscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004210085
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9597
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3
 bulkscore=0
 priorityscore=1501 impostorscore=0 adultscore=0 phishscore=0
 lowpriorityscore=0 malwarescore=0 clxscore=1011 mlxlogscore=999 mlxscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004210085
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, kernel-janitors@vger.kernel.org,
 dri-devel@lists.freedesktop.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Kernel Janitors,

Here is another idea that someone could work on, fixing the
IS_ERR_OR_NULL() checks in the xen driver.

The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:

	drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
	warn: passing zero to 'ERR_CAST'

drivers/gpu/drm/xen/xen_drm_front_gem.c
   133  struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
   134                                                  size_t size)
   135  {
   136          struct xen_gem_object *xen_obj;
   137  
   138          xen_obj = gem_create(dev, size);
   139          if (IS_ERR_OR_NULL(xen_obj))
   140                  return ERR_CAST(xen_obj);

This warning is old and it's actually the result of a bug I had in my
devel version of Smatch yesterday.  xen_obj can't really be NULL, but
if it were then the caller would return success which would probably
create some issues.

When a function returns both error pointers and NULL then NULL is a
special case of success.  Like say you have:  "p = start_feature();".
If there is an allocation failure, then the code should return -ENOMEM
and the whole thing should fail.  But if the feature is optional and
the user has disabled it in the config then we return NULL and the
caller has to be able to accept that.  There are a lot of these
IS_ERR_OR_NULL() checks in the xen driver...

The one here is clearly buggy because returning NULL would lead to a
run time failure.  All these IS_ERR_OR_NULL() should be checked and
probably changed to just IS_ERR().

This sort of change is probably change is probably easiest if you build
the Smatch DB and you can check if Smatch thinks the functions return
NULL.

~/smatch/smatch_data/db/smdb.py return_states gem_create | grep INTERNAL
drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 58 |  (-4095)-(-1) |      INTERNAL |  -1 |                      | struct xen_gem_object*(*)(struct drm_device*, ulong) |
drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 62 | 4065035897849303040 |      INTERNAL |  -1 |                      | struct xen_gem_object*(*)(struct drm_device*, ulong) |
drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 66 | 4065035897849303040 |      INTERNAL |  -1 |                      | struct xen_gem_object*(*)(struct drm_device*, ulong) |
drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 68 | 0,(-4095)-(-1) |      INTERNAL |  -1 |                      | struct xen_gem_object*(*)(struct drm_device*, ulong) |

Smatch thinks that gem_create() sometimes returns NULL or error pointers
but that's because of a bug in the unreleased version of Smatch and
because gem_create() uses IS_ERR_OR_NULL().

   141  
   142          return &xen_obj->base;
   143  }

regards,
dan carpenter


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 11:35:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 11:35:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQrB5-0004fm-8w; Tue, 21 Apr 2020 11:34:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9pWK=6F=epam.com=oleksandr_andrushchenko@srs-us1.protection.inumbo.net>)
 id 1jQrB3-0004ff-TS
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 11:34:58 +0000
X-Inumbo-ID: 1f2bbe90-83c4-11ea-83d8-bc764e2007e4
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (unknown
 [40.107.5.41]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1f2bbe90-83c4-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 11:34:56 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=HT8rlgSniTOLPbn6PLuOc5HBNs4tPLo2opmh3ypPqT96N3vDwxfzOFBeuzYC3sQJ5LFvtdFSoWk6B+/+v3YKRga7UTmJZGX2aGr9SDuvV2YqmUvkAjT9YKWeaqj0Y5FzeveRywsKx4iITeXLrQNWDkDOk+67nIFv4eYdaGHW3OHzIeG+G5JGoSccL2aOy6ZyzyuZ8nQv0EFODnWHzI+5KrvT7+rg427ihSnawyiUWuxIrj9LJZX69vSPRwle5VMqBmTZPvRZHVov4JkDeWT32C0nWTrsmVHP629yFqfwNcz6JhUx6XDvd0J+OY/ucwi4HaughIjCDZJcS9RkpH5svA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ErhIsr6nFzZAhpsCBTew5GcZqhDzEM9a0zUDFOef73c=;
 b=UTgyvoZnG3UxsPfu1vzMXzfvvxLfUOkFSWxS+iU829724sitvfNjTU2N9cTNVCFuqJZJRJvimS3LjAj6P/sdBbTzaGJldpVweomxBsK7yD5Gj58tI1s44cfUvUAXn2dBR710b4Z88JDHtHn+lX3lKO2IQ794Q4reJJif8UCP5cGKNjhhSoWkXO4EKSexpwj7cHHZQNvPgi8MxZy8gCbNF/7Gq4JXpPPFZfPG1n0z9jUgfqi8FWhv1NBxnbfPzSIuT+fAUrJj2iXCFam0H9CUVZcswS3OU4gJnd2qJIER3HA+yNht0OgHfzh8Q8K9Y9P/K2IGGyPBOJyKk25MKvQFoA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ErhIsr6nFzZAhpsCBTew5GcZqhDzEM9a0zUDFOef73c=;
 b=Ls0yTPY/Q4dhlgwQiq6BAF0fOPPLZZ5+uNbjXpM1sWm+kbdmNE5gKDEMidhHMW3xWag1wISKjm5ABUli5P9fXTDoRTxofrzk5EUbRhvPZgSnhVL8eP6jjE+IhK3Xmh+X9QPk0qzJms0pzlAboE33aSxWpJxlERwdNmq6DtfwaI0=
Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14)
 by VI1PR03MB4672.eurprd03.prod.outlook.com (2603:10a6:803:5e::30)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Tue, 21 Apr
 2020 11:34:53 +0000
Received: from VI1PR03MB3998.eurprd03.prod.outlook.com
 ([fe80::4144:ba6b:18cd:af5c]) by VI1PR03MB3998.eurprd03.prod.outlook.com
 ([fe80::4144:ba6b:18cd:af5c%7]) with mapi id 15.20.2921.030; Tue, 21 Apr 2020
 11:34:53 +0000
From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [bug report] drm/xen-front: Add support for Xen PV display
 frontend
Thread-Topic: [bug report] drm/xen-front: Add support for Xen PV display
 frontend
Thread-Index: AQHWF8n8HYXBbl5N3kSvZpSjxllEBqiDciuA
Date: Tue, 21 Apr 2020 11:34:53 +0000
Message-ID: <28cc7f7c-fe0a-fd06-d330-73531b818a79@epam.com>
References: <20200421104522.GA86681@mwanda>
In-Reply-To: <20200421104522.GA86681@mwanda>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=Oleksandr_Andrushchenko@epam.com; 
x-originating-ip: [185.199.97.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7510d33f-d8a7-4207-7ead-08d7e5e802c0
x-ms-traffictypediagnostic: VI1PR03MB4672:
x-microsoft-antispam-prvs: <VI1PR03MB467219CFA5E165EB519A94F9E7D50@VI1PR03MB4672.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 038002787A
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10009020)(4636009)(376002)(396003)(346002)(39860400002)(136003)(366004)(36756003)(186003)(2906002)(76116006)(31696002)(478600001)(6512007)(6916009)(31686004)(6486002)(5660300002)(86362001)(54906003)(4326008)(53546011)(6506007)(66946007)(64756008)(66556008)(2616005)(66476007)(66446008)(81156014)(8936002)(26005)(316002)(8676002)(71200400001);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: epam.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Q/t49k4dydozIpZmJDDMSMx+09QzOYMeb1HIJ5ztefBVFB3AhkFKN9xtvX3cws7hC2E9ggWJGZD683KNHD6Q+0e2dBeDpMz1fsUSfW46RrYCUwvrG9V9p0vNkTTQOz9Js2enxz9WH8pKAg4N1coNQS9oZJD1mvy/T1C1kZnkby0OIMjwyyPpMuu5LkMfwT17hOMV1ctokI0eF31BUFSUm7YDFIsMj6mwfnA17hg70yq6M121XBhvOLlYbQ3lFydeRKkOWPO1zEbCi56P3Jm0eP9dpU+Er4HHwbY69ERHqbsyT5n/BUEOLxyIRvySzg1nKVdby+NroNoL63xvCiSmVvu1+h8itOWpLgjtgAaWT5yva5coD2+58nU/WB7ZK+lxRGgWbZeU5hov3FJHl+4eIFzT/LbslPhkZEVHVsRjoOUSi0dtDaclW2qqofpJs4G3
x-ms-exchange-antispam-messagedata: 6jSJmebMBwMRvLIkc69lHGdGqElXKPrTZQgL59k3o8DLVBX9k5w3Di5OVpVZXJY+5oSdrLpO2ZLKPZ2laEaEJ7K9hfh7o9aVK2DwCnJz3gXQ2GutoDm5UMVQ1tBQMPa7gTLmJ761eeudOes+W+zXSeYdCZfPcgrvNhCpD/LP91RhnbDKUAFd6c4xtTbN9ByOV8WQn7isjshauDsu3fjz6+PFiJlwzZ+lhWTZfe7U5rW9tUjE5rtZmaTzz+0qI+UDgbRkVx4XksYt22zrz64ZAGgvKW+1ni0g9k3IeLiP1Thfj6LPXHuDjtQxJvhtRc+qJbF06cqJ30ORDZWb8awaQ4fbuEe2si3wXEKviSP178jg4IbgNY6Vr8FRTYD4bVrpLjqBC0rES1J0FazchFANk61FEy4Whfxx1kvvitNpelknx2eE5EAjMDlwh01HajQ1za2xdyN7ng5saYta8vgEDQ6TXIDAXhiwSro6Grgz+5SBlz+24fCmtXdMzme0EMYrWyQl/9md+G1DmvqciuQ2n+WE1aZutJPp/QZnvEarDsqUKQPLCmjJxthdKIUr+jighWLQ2NmpyOD8+QzNPuiaX1O9PgkyWbHd5jlu1Sa4AE9yta/kgYnJ3wnOu+J9MmVo+GcZe1EQ7jBIIFLVnCnS1pM5VJefK/1QLYlFAmw/S9WUmOfRJMdnhzJGNlXEHeYSiXY4cFFQgl5v14s4nZebEWigJbbYGNMYmUAZ5lj6xGi8GW2FvVlxtFfwYv5GEgRlOs2d018Lifnq0qZZh4/RRFKfUioWORmRrcl9Pl0U9ls=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <6F53AA9BC003B44BAFE1919709B1AB56@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7510d33f-d8a7-4207-7ead-08d7e5e802c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 11:34:53.6328 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FiiQ2z03w/fkjEBeEHmh6+i8ShxTJdKoNHDKTGksb6qavfzZrLcjpWkgIKqlERAQhznBnqSxBBUO9ABYG6o1G3aGqXVZ9YzakxDFzHzFexjHTh0YAXf0ynLpZCXWcipe
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4672
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "kernel-janitors@vger.kernel.org" <kernel-janitors@vger.kernel.org>,
 "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

T24gNC8yMS8yMCAxMzo0NSwgRGFuIENhcnBlbnRlciB3cm90ZToNCj4gSGkgS2VybmVsIEphbml0
b3JzLA0KSGkNCj4NCj4gSGVyZSBpcyBhbm90aGVyIGlkZWEgdGhhdCBzb21lb25lIGNvdWxkIHdv
cmsgb24sIGZpeGluZyB0aGUNCj4gSVNfRVJSX09SX05VTEwoKSBjaGVja3MgaW4gdGhlIHhlbiBk
cml2ZXIuDQo+DQo+IFRoZSBwYXRjaCBjNTc1YjdlZWI4OWY6ICJkcm0veGVuLWZyb250OiBBZGQg
c3VwcG9ydCBmb3IgWGVuIFBWDQo+IGRpc3BsYXkgZnJvbnRlbmQiIGZyb20gQXByIDMsIDIwMTgs
IGxlYWRzIHRvIHRoZSBmb2xsb3dpbmcgc3RhdGljDQo+IGNoZWNrZXIgd2FybmluZzoNCj4NCj4g
CWRyaXZlcnMvZ3B1L2RybS94ZW4veGVuX2RybV9mcm9udF9nZW0uYzoxNDAgeGVuX2RybV9mcm9u
dF9nZW1fY3JlYXRlKCkNCj4gCXdhcm46IHBhc3NpbmcgemVybyB0byAnRVJSX0NBU1QnDQo+DQo+
IGRyaXZlcnMvZ3B1L2RybS94ZW4veGVuX2RybV9mcm9udF9nZW0uYw0KPiAgICAgMTMzICBzdHJ1
Y3QgZHJtX2dlbV9vYmplY3QgKnhlbl9kcm1fZnJvbnRfZ2VtX2NyZWF0ZShzdHJ1Y3QgZHJtX2Rl
dmljZSAqZGV2LA0KPiAgICAgMTM0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBzaXplX3Qgc2l6ZSkNCj4gICAgIDEzNSAgew0KPiAgICAgMTM2ICAgICAg
ICAgIHN0cnVjdCB4ZW5fZ2VtX29iamVjdCAqeGVuX29iajsNCj4gICAgIDEzNw0KPiAgICAgMTM4
ICAgICAgICAgIHhlbl9vYmogPSBnZW1fY3JlYXRlKGRldiwgc2l6ZSk7DQo+ICAgICAxMzkgICAg
ICAgICAgaWYgKElTX0VSUl9PUl9OVUxMKHhlbl9vYmopKQ0KPiAgICAgMTQwICAgICAgICAgICAg
ICAgICAgcmV0dXJuIEVSUl9DQVNUKHhlbl9vYmopOw0KPg0KPiBUaGlzIHdhcm5pbmcgaXMgb2xk
IGFuZCBpdCdzIGFjdHVhbGx5IHRoZSByZXN1bHQgb2YgYSBidWcgSSBoYWQgaW4gbXkNCj4gZGV2
ZWwgdmVyc2lvbiBvZiBTbWF0Y2ggeWVzdGVyZGF5LiAgeGVuX29iaiBjYW4ndCByZWFsbHkgYmUg
TlVMTCwgYnV0DQo+IGlmIGl0IHdlcmUgdGhlbiB0aGUgY2FsbGVyIHdvdWxkIHJldHVybiBzdWNj
ZXNzIHdoaWNoIHdvdWxkIHByb2JhYmx5DQo+IGNyZWF0ZSBzb21lIGlzc3Vlcy4NCj4NCj4gV2hl
biBhIGZ1bmN0aW9uIHJldHVybnMgYm90aCBlcnJvciBwb2ludGVycyBhbmQgTlVMTCB0aGVuIE5V
TEwgaXMgYQ0KPiBzcGVjaWFsIGNhc2Ugb2Ygc3VjY2Vzcy4gIExpa2Ugc2F5IHlvdSBoYXZlOiAg
InAgPSBzdGFydF9mZWF0dXJlKCk7Ii4NCj4gSWYgdGhlcmUgaXMgYW4gYWxsb2NhdGlvbiBmYWls
dXJlLCB0aGVuIHRoZSBjb2RlIHNob3VsZCByZXR1cm4gLUVOT01FTQ0KPiBhbmQgdGhlIHdob2xl
IHRoaW5nIHNob3VsZCBmYWlsLiAgQnV0IGlmIHRoZSBmZWF0dXJlIGlzIG9wdGlvbmFsIGFuZA0K
PiB0aGUgdXNlciBoYXMgZGlzYWJsZWQgaXQgaW4gdGhlIGNvbmZpZyB0aGVuIHdlIHJldHVybiBO
VUxMIGFuZCB0aGUNCj4gY2FsbGVyIGhhcyB0byBiZSBhYmxlIHRvIGFjY2VwdCB0aGF0LiAgVGhl
cmUgYXJlIGEgbG90IG9mIHRoZXNlDQo+IElTX0VSUl9PUl9OVUxMKCkgY2hlY2tzIGluIHRoZSB4
ZW4gZHJpdmVyLi4uDQo+DQo+IFRoZSBvbmUgaGVyZSBpcyBjbGVhcmx5IGJ1Z2d5IGJlY2F1c2Ug
cmV0dXJuaW5nIE5VTEwgd291bGQgbGVhZCB0byBhDQo+IHJ1biB0aW1lIGZhaWx1cmUuICBBbGwg
dGhlc2UgSVNfRVJSX09SX05VTEwoKSBzaG91bGQgYmUgY2hlY2tlZCBhbmQNCj4gcHJvYmFibHkg
Y2hhbmdlZCB0byBqdXN0IElTX0VSUigpLg0KPg0KPiBUaGlzIHNvcnQgb2YgY2hhbmdlIGlzIHBy
b2JhYmx5IGNoYW5nZSBpcyBwcm9iYWJseSBlYXNpZXN0IGlmIHlvdSBidWlsZA0KPiB0aGUgU21h
dGNoIERCIGFuZCB5b3UgY2FuIGNoZWNrIGlmIFNtYXRjaCB0aGlua3MgdGhlIGZ1bmN0aW9ucyBy
ZXR1cm4NCj4gTlVMTC4NCj4NCj4gfi9zbWF0Y2gvc21hdGNoX2RhdGEvZGIvc21kYi5weSByZXR1
cm5fc3RhdGVzIGdlbV9jcmVhdGUgfCBncmVwIElOVEVSTkFMDQo+IGRyaXZlcnMvZ3B1L2RybS94
ZW4veGVuX2RybV9mcm9udF9nZW0uYyB8IGdlbV9jcmVhdGUgfCA1OCB8ICAoLTQwOTUpLSgtMSkg
fCAgICAgIElOVEVSTkFMIHwgIC0xIHwgICAgICAgICAgICAgICAgICAgICAgfCBzdHJ1Y3QgeGVu
X2dlbV9vYmplY3QqKCopKHN0cnVjdCBkcm1fZGV2aWNlKiwgdWxvbmcpIHwNCj4gZHJpdmVycy9n
cHUvZHJtL3hlbi94ZW5fZHJtX2Zyb250X2dlbS5jIHwgZ2VtX2NyZWF0ZSB8IDYyIHwgNDA2NTAz
NTg5Nzg0OTMwMzA0MCB8ICAgICAgSU5URVJOQUwgfCAgLTEgfCAgICAgICAgICAgICAgICAgICAg
ICB8IHN0cnVjdCB4ZW5fZ2VtX29iamVjdCooKikoc3RydWN0IGRybV9kZXZpY2UqLCB1bG9uZykg
fA0KPiBkcml2ZXJzL2dwdS9kcm0veGVuL3hlbl9kcm1fZnJvbnRfZ2VtLmMgfCBnZW1fY3JlYXRl
IHwgNjYgfCA0MDY1MDM1ODk3ODQ5MzAzMDQwIHwgICAgICBJTlRFUk5BTCB8ICAtMSB8ICAgICAg
ICAgICAgICAgICAgICAgIHwgc3RydWN0IHhlbl9nZW1fb2JqZWN0KigqKShzdHJ1Y3QgZHJtX2Rl
dmljZSosIHVsb25nKSB8DQo+IGRyaXZlcnMvZ3B1L2RybS94ZW4veGVuX2RybV9mcm9udF9nZW0u
YyB8IGdlbV9jcmVhdGUgfCA2OCB8IDAsKC00MDk1KS0oLTEpIHwgICAgICBJTlRFUk5BTCB8ICAt
MSB8ICAgICAgICAgICAgICAgICAgICAgIHwgc3RydWN0IHhlbl9nZW1fb2JqZWN0KigqKShzdHJ1
Y3QgZHJtX2RldmljZSosIHVsb25nKSB8DQo+DQo+IFNtYXRjaCB0aGlua3MgdGhhdCBnZW1fY3Jl
YXRlKCkgc29tZXRpbWVzIHJldHVybnMgTlVMTCBvciBlcnJvciBwb2ludGVycw0KPiBidXQgdGhh
dCdzIGJlY2F1c2Ugb2YgYSBidWcgaW4gdGhlIHVucmVsZWFzZWQgdmVyc2lvbiBvZiBTbWF0Y2gg
YW5kDQo+IGJlY2F1c2UgZ2VtX2NyZWF0ZSgpIHVzZXMgSVNfRVJSX09SX05VTEwoKS4NCj4NCj4g
ICAgIDE0MQ0KPiAgICAgMTQyICAgICAgICAgIHJldHVybiAmeGVuX29iai0+YmFzZTsNCj4gICAg
IDE0MyAgfQ0KPg0KPiByZWdhcmRzLA0KPiBkYW4gY2FycGVudGVyDQoNClRoYW5rIHlvdSBmb3Ig
dGhlIHJlcG9ydCwgSSB3aWxsIHRyeSB0byBmaW5kIHNvbWUgdGltZSB0byBsb29rIGludG8gdGhp
cyANCmFuZCBjb21lIHVwIHdpdGggZml4ZXMuDQoNCkNvdWxkIHlvdSBwbGVhc2UgKHByb2JhYmx5
IG9mZi1saXN0KSBpbnN0cnVjdCBtZSBvciBnaXZlIGFueSBwb2ludGVycyB0byANCmhvdyB0byBy
ZXByb2R1Y2UNCg0KdGhlIHJlc3VsdHMgb2YgdGhlIGFuYWx5emVyIHNob3duIGFib3ZlPw0KDQpU
aGFuayB5b3UsDQoNCk9sZWtzYW5kcg0K


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 11:51:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 11:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQrR5-0006Pd-Rz; Tue, 21 Apr 2020 11:51:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Vwqf=6F=oracle.com=dan.carpenter@srs-us1.protection.inumbo.net>)
 id 1jQrR4-0006PY-Hb
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 11:51:30 +0000
X-Inumbo-ID: 70105b70-83c6-11ea-b58d-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 70105b70-83c6-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 11:51:29 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03LBmYDu045551;
 Tue, 21 Apr 2020 11:51:27 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=date : from : to : cc
 : subject : message-id : references : mime-version : content-type :
 in-reply-to; s=corp-2020-01-29;
 bh=4bRJ6HpveUYBF386I3U2/DJBFNbrJMpTxF/6PvkbQyY=;
 b=qL8jUlPcFKY0QYfc9jOK4O9NjJE4lHZ9bTqJAbG4cNbhIjeoccTV34xeMbe9+zeaH3Xi
 izBlyXs3x6FRVWxUlHqvHyC1DHA+QX7RjiAmBSUTdTaQtvIsoNDJeQnGHPU+71DfcLJw
 ljBQYZWWgEWuUePFxddjT5zDt5/avrrTjgPZQkmtJWOR4hbP1fNQTCwnjwlJPdmZexW1
 WMcWMukaeTRXyjXTji9aSW4n1rCwvxERs7CGnX53oxPoA+KnVclY3f8ckU+I2JK5ME7C
 rsdgF7KndudPUDXJ2XIT2K0kMFbIm9T72M/oH2cqcTY/dGiilA64IzZ5oGA7twE/rFW/ Pw== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by aserp2120.oracle.com with ESMTP id 30fsgkvha9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 21 Apr 2020 11:51:27 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03LBgRMa006184;
 Tue, 21 Apr 2020 11:51:26 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by aserp3020.oracle.com with ESMTP id 30gbbdjwbm-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 21 Apr 2020 11:51:26 +0000
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03LBpP3D005889;
 Tue, 21 Apr 2020 11:51:25 GMT
Received: from kadam (/41.57.98.10) by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 21 Apr 2020 04:51:24 -0700
Date: Tue, 21 Apr 2020 14:51:12 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
Subject: Re: [bug report] drm/xen-front: Add support for Xen PV display
 frontend
Message-ID: <20200421115112.GB2682@kadam>
References: <20200421104522.GA86681@mwanda>
 <28cc7f7c-fe0a-fd06-d330-73531b818a79@epam.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <28cc7f7c-fe0a-fd06-d330-73531b818a79@epam.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9597
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 malwarescore=0
 suspectscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 phishscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004210094
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9597
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 priorityscore=1501
 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 clxscore=1015
 spamscore=0 bulkscore=0 phishscore=0 suspectscore=0 impostorscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004210094
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "kernel-janitors@vger.kernel.org" <kernel-janitors@vger.kernel.org>,
 "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It turns out there aren't that many of these in xen.

$ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
drivers/gpu/drm/xen/xen_drm_front_kms.c:63:     if (IS_ERR_OR_NULL(fb))
drivers/gpu/drm/xen/xen_drm_front_gem.c:86:     if (IS_ERR_OR_NULL(xen_obj))
drivers/gpu/drm/xen/xen_drm_front_gem.c:120:    if (IS_ERR_OR_NULL(xen_obj->pages)) {
drivers/gpu/drm/xen/xen_drm_front_gem.c:139:    if (IS_ERR_OR_NULL(xen_obj))
drivers/gpu/drm/xen/xen_drm_front_gem.c:197:    if (IS_ERR_OR_NULL(xen_obj))
drivers/gpu/drm/xen/xen_drm_front.c:403:        if (IS_ERR_OR_NULL(obj)) {

They're all wrong, because if the pointer was really NULL then it's
not handled correctly and would eventually lead to a runtime failure.

Normally Smatch is smart enough to know that the pointer isn't NULL so
it doesn't generate a warning but yesterday I introduced a bug in Smatch
by mistake.  It's fixed now.

regards,
dan carpenter



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 12:06:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 12:06:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQrfB-0007Sr-KE; Tue, 21 Apr 2020 12:06:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQrf9-0007Sm-LY
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 12:06:03 +0000
X-Inumbo-ID: 784b4a0a-83c8-11ea-912a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 784b4a0a-83c8-11ea-912a-12813bfff9fa;
 Tue, 21 Apr 2020 12:06:02 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D8C89ABC7;
 Tue, 21 Apr 2020 12:06:00 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86/shadow: make sh_remove_write_access() helper HVM only
Message-ID: <2a339346-ed09-22b6-88fb-6f9d997b10b4@suse.com>
Date: Tue, 21 Apr 2020 14:05:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Despite the inline attribute at least some clang versions warn about
trace_shadow_wrmap_bf() being unused in !HVM builds. Include the helper
in the #ifdef region.

Fixes: 8b8d011ad868 ("x86/shadow: the guess_wrmap() hook is needed for HVM only")
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1756,6 +1756,7 @@ void sh_destroy_shadow(struct domain *d,
     }
 }
 
+#ifdef CONFIG_HVM
 static inline void trace_shadow_wrmap_bf(mfn_t gmfn)
 {
     if ( tb_init_done )
@@ -1767,7 +1768,6 @@ static inline void trace_shadow_wrmap_bf
     }
 }
 
-#ifdef CONFIG_HVM
 /**************************************************************************/
 /* Remove all writeable mappings of a guest frame from the shadow tables
  * Returns non-zero if we need to flush TLBs.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 12:06:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 12:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQrfo-0007WA-Vm; Tue, 21 Apr 2020 12:06:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=5BlT=6F=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQrfn-0007W4-R4
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 12:06:43 +0000
X-Inumbo-ID: 9038c62e-83c8-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9038c62e-83c8-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 12:06:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587470802;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=m7bdbXp9cMzUM/xm0bUXvtCsqniWLj+1XboG0CODW/0=;
 b=W7DCUPXb9sVDxjEMHa0gf2PA11bLWNib0ocd2+AzgsJbIgunnE6pA3DN
 RsrOIXnJ5KUZD8yAJAUhS+pkKqJ4gH7hLW8upsJCAlMr0vI4q6yqvxQP1
 kJC3ptFI0jdppM/DZGuut9qbmVguZBhU05ikcvm+3RVTnIa6LC7C9YFHw E=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 0P02j3QqbONlKvcutAPWqJZdrE/2CPFs12A/Ddem9i9YTJRyD605q2losRnp4ilFF582bIc0XT
 aAMKVXLNJsCxM9dduL/RJVylE5uUQP+7KuA6+AkPiO6p9n+a6c5uIPB3sZ/Neb3ii9TSLCsFQh
 Zaarp1QURL16EzQ/nQB5Hs/09qGBfi1ZySW4Sm8mrR04KnouXd0j5Q5/ImdLeUKOHEP00rXw2O
 JLfKGgoVK2DHrMXCT/Ffc2cEEQagXhPgLJRsfZhR26lwceEYrmagokjWRfZLccwcjujgPz91Sj
 iP0=
X-SBRS: 2.7
X-MesageID: 16395615
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16395615"
Subject: Re: [PATCH] x86/shadow: make sh_remove_write_access() helper HVM only
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <2a339346-ed09-22b6-88fb-6f9d997b10b4@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <9ac15077-7888-603e-410e-c7d0bc0a9f9d@citrix.com>
Date: Tue, 21 Apr 2020 13:06:37 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <2a339346-ed09-22b6-88fb-6f9d997b10b4@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21/04/2020 13:05, Jan Beulich wrote:
> Despite the inline attribute at least some clang versions warn about
> trace_shadow_wrmap_bf() being unused in !HVM builds. Include the helper
> in the #ifdef region.
>
> Fixes: 8b8d011ad868 ("x86/shadow: the guess_wrmap() hook is needed for HVM only")
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 12:35:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 12:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQs7R-0001kG-Ik; Tue, 21 Apr 2020 12:35:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=wEXD=6F=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQs7Q-0001kB-Au
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 12:35:16 +0000
X-Inumbo-ID: 8d442c20-83cc-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8d442c20-83cc-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 12:35:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=3VZPPZt9qJm6OA2YKyrSvNJ6N8g0ZBmXvs7ZqLlBjKk=; b=1beMDBXnQdznL2PhaePEbNuZLT
 LOv+Vhkq2LmGWLRbvQCNgM7KWqdX9LqiACnfEaOR7aYf15PqMh72SC0pcFOtAxWI/bRy1nTY2Olz0
 gluf2oEH+PuQWsOKuxR1BH/4Rv0fR/plhAxQL5gBLCUN13XvmJTRK+gnX/02QvHaHGss=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQs7O-00076d-96; Tue, 21 Apr 2020 12:35:14 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQs7O-0004Db-1i; Tue, 21 Apr 2020 12:35:14 +0000
Subject: Re: [PATCH v2 1/2] x86/HVM: expose VM assist hypercall
To: Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
 <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
 <1f463b9e-9629-4ba0-3b7f-373b4bcb5b64@xen.org>
 <5863d6d0-22cf-7237-a88b-a3a2c4809635@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <a6474b12-05a2-925f-0d7f-eacc8b1406bd@xen.org>
Date: Tue, 21 Apr 2020 13:35:11 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5863d6d0-22cf-7237-a88b-a3a2c4809635@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 21/04/2020 06:54, Jan Beulich wrote:
> On 20.04.2020 19:53, Julien Grall wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
>>>        return rc;
>>>    }
>>>    -#ifdef VM_ASSIST_VALID
>>> -long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
>>> -               unsigned long valid)
>>> +#ifdef arch_vm_assist_valid
>>
>> How about naming the function arch_vm_assist_valid_mask?
> 
> Certainly a possibility, albeit to me the gain would be marginal
> and possibly not outweigh the growth in length. Andrew, any
> preference?

You have a point regarding the length of the function.

> 
>>> --- a/xen/include/asm-x86/domain.h
>>> +++ b/xen/include/asm-x86/domain.h
>>> @@ -700,6 +700,20 @@ static inline void pv_inject_sw_interrup
>>>       pv_inject_event(&event);
>>> }
>>> +#define PV_VM_ASSIST_VALID  ((1UL << VMASST_TYPE_4gb_segments)        | \
>>> +                             (1UL << VMASST_TYPE_4gb_segments_notify) | \
>>> +                             (1UL << VMASST_TYPE_writable_pagetables) | \
>>> +                             (1UL << VMASST_TYPE_pae_extended_cr3)    | \
>>> +                             (1UL << VMASST_TYPE_architectural_iopl)  | \
>>> +                             (1UL << VMASST_TYPE_runstate_update_flag)| \
>>> +                             (1UL << VMASST_TYPE_m2p_strict))
>>> +#define HVM_VM_ASSIST_VALID (1UL << VMASST_TYPE_runstate_update_flag)
>>> +
>>> +#define arch_vm_assist_valid(d) \
>>> +    (is_hvm_domain(d) ? HVM_VM_ASSIST_VALID \
>>> +                      : is_pv_32bit_domain(d) ? (uint32_t)PV_VM_ASSIST_VALID \
>>
>> I understand this is matching the current code, however without
>> looking at the rest of patch this is not clear why the cast. May
>> I suggest to add a comment explaining the rationale?
> 
> Hmm, I can state that the rationale is history. Many of the assists in
> the low 32 bits are for 32-bit guests only. But we can't start refusing
> a 64-bit kernel requesting them. The ones in the high 32 bits are, for
> now, applicable to 64-bit guests only, and have always been refused for
> 32-bit ones.
 >
> Imo if anything an explanation on where new bits should be put should
> go next to the VMASST_TYPE_* definitions in the public header, yet then
> again the public headers aren't (imo) a good place to put
> implementation detail comments.

How about splitting PV_VM_ASSIST_VALID in two? One would contain 64-bit 
PV specific flags and the other common PV flags?

This should make the code more obvious and easier to read for someone 
less familiar with the area.

It also means we could have a BUILD_BUG_ON() to check at build time that 
no flags are added above 32-bit.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 12:38:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 12:38:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQsAJ-0001sS-2T; Tue, 21 Apr 2020 12:38:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=5BlT=6F=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQsAH-0001sN-Jp
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 12:38:13 +0000
X-Inumbo-ID: f5a8bb33-83cc-11ea-912f-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f5a8bb33-83cc-11ea-912f-12813bfff9fa;
 Tue, 21 Apr 2020 12:38:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587472693;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=ez7b51wbdbgSx0b91oiYrAWAE9050LVS4gcmvETfNAA=;
 b=DMb5kysf5Y21eAeNV29c5xll0pk8Lt2ugTO2MUG+giHf7tAF9I6yB025
 9X3CPYKgAMCt7XFdGC//qsBCKx6qRtcIAFBQBeOrBdoVUqWVhIUrRU3sG
 YXZKqZEok2t2fGIzWdOVSycXwNHWRlDBS0kSfb6B/SuK7GBAJm8fjqdFP Q=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: wG6Q/7OwvPV7dD3CbWROX0rRD8MynACnSpNQO15rcogPyyXlTcNcg/y/1cwPza891Bh5UaddyQ
 9a3a6WpA8PI/wrsG+KCkUnG0GG82NJwIMNorHtbrMRGZDr/0ah6jJILi0iWUdWJHq1JikjTrwW
 VAMLWuAXa7V9ZDM6rUE1l997EvNp17qU1AOj0Cf67zenR5hJ1L6Dnx6IFhHU/b7PuSv0sY1I2t
 c5qyLr9wUbi5X0AjGBwpkBgTH3ktDn6xuFE2I5Qjk4yrB2fzXohKIlcGG2FnmzFdIxMVAqAhpl
 9nA=
X-SBRS: 2.7
X-MesageID: 16012010
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16012010"
Subject: Re: [PATCH v2 1/2] x86/HVM: expose VM assist hypercall
To: Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
 <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
 <1f463b9e-9629-4ba0-3b7f-373b4bcb5b64@xen.org>
 <5863d6d0-22cf-7237-a88b-a3a2c4809635@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <c67330b3-5766-28f1-c2d1-5adb3c302208@citrix.com>
Date: Tue, 21 Apr 2020 13:38:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5863d6d0-22cf-7237-a88b-a3a2c4809635@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, George
 Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21/04/2020 06:54, Jan Beulich wrote:
> On 20.04.2020 19:53, Julien Grall wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
>>>       return rc;
>>>   }
>>>   -#ifdef VM_ASSIST_VALID
>>> -long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
>>> -               unsigned long valid)
>>> +#ifdef arch_vm_assist_valid
>> How about naming the function arch_vm_assist_valid_mask?
> Certainly a possibility, albeit to me the gain would be marginal
> and possibly not outweigh the growth in length. Andrew, any
> preference?

I prefer Julien's suggestion overall.  It is obviously not a predicate,
whereas the shorter name could easily be one.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 12:41:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 12:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQsCt-0002gu-HD; Tue, 21 Apr 2020 12:40:55 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=5BlT=6F=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jQsCs-0002gp-4P
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 12:40:54 +0000
X-Inumbo-ID: 5641f63e-83cd-11ea-9133-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5641f63e-83cd-11ea-9133-12813bfff9fa;
 Tue, 21 Apr 2020 12:40:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587472854;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=jlxUicnZ98dspp8RLOm5cBjgiezSey5iTAiuQxl5Y5Y=;
 b=LMlsDkmZ5PMQa8neXQGOcSIIMNt5QWaYKG0p700k6IxyNGZUQ/9QX+hj
 svntFpE1lOOxjpCsrCZ7E2gD5ZYt8MXuQkkV6yqNiHH1EKzMSq4+hC1PO
 BCvy5a9eoBelvJcjOJeVy0uXNDdQ9FyG4fZM2zEfabGYW9fx3+62fbTKo g=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: LAsIpZE00xuyfI6/oIFfGuzfW1yXJr9Sp5TIJx3Stk9LipEzGCyNxfaC5HuMZOHGEK3ijUY/oi
 eeOU7+9B0AkSda4O66PVyEFguB/AKro2Qp5wjias6Vfu1cGVrgJZ4j6ZgRj7ljOL4LkEnc86f0
 eArjtP5yKBygl42UpZSw6Sw7nk1WJJpZWWWiW9G3asnsqIgd7EIMDAa5jyq0k7ajMvr1+7FJZy
 trOSy6dnCpzedcIWtz84C/U2vSEma5xLXfff139oNBcaWWqAWgfs4+kIpCSCUsqxkNFl7T4Xe3
 KK0=
X-SBRS: 2.7
X-MesageID: 16245712
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16245712"
Subject: Re: [PATCH v2 1/2] x86/HVM: expose VM assist hypercall
To: Julien Grall <julien@xen.org>, Jan Beulich <jbeulich@suse.com>
References: <51dfb592-2653-738f-6933-9521ffa4fecd@suse.com>
 <e5eb3508-141e-dd9d-5177-c08d51ebaaa0@suse.com>
 <1f463b9e-9629-4ba0-3b7f-373b4bcb5b64@xen.org>
 <5863d6d0-22cf-7237-a88b-a3a2c4809635@suse.com>
 <a6474b12-05a2-925f-0d7f-eacc8b1406bd@xen.org>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <98b3786a-99b2-708a-d9e5-010a115d5ea3@citrix.com>
Date: Tue, 21 Apr 2020 13:40:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a6474b12-05a2-925f-0d7f-eacc8b1406bd@xen.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, George
 Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21/04/2020 13:35, Julien Grall wrote:
>>>> --- a/xen/include/asm-x86/domain.h
>>>> +++ b/xen/include/asm-x86/domain.h
>>>> @@ -700,6 +700,20 @@ static inline void pv_inject_sw_interrup
>>>>       pv_inject_event(&event);
>>>> }
>>>> +#define PV_VM_ASSIST_VALID  ((1UL <<
>>>> VMASST_TYPE_4gb_segments)        | \
>>>> +                             (1UL <<
>>>> VMASST_TYPE_4gb_segments_notify) | \
>>>> +                             (1UL <<
>>>> VMASST_TYPE_writable_pagetables) | \
>>>> +                             (1UL <<
>>>> VMASST_TYPE_pae_extended_cr3)    | \
>>>> +                             (1UL <<
>>>> VMASST_TYPE_architectural_iopl)  | \
>>>> +                             (1UL <<
>>>> VMASST_TYPE_runstate_update_flag)| \
>>>> +                             (1UL << VMASST_TYPE_m2p_strict))
>>>> +#define HVM_VM_ASSIST_VALID (1UL << VMASST_TYPE_runstate_update_flag)
>>>> +
>>>> +#define arch_vm_assist_valid(d) \
>>>> +    (is_hvm_domain(d) ? HVM_VM_ASSIST_VALID \
>>>> +                      : is_pv_32bit_domain(d) ?
>>>> (uint32_t)PV_VM_ASSIST_VALID \
>>>
>>> I understand this is matching the current code, however without
>>> looking at the rest of patch this is not clear why the cast. May
>>> I suggest to add a comment explaining the rationale?
>>
>> Hmm, I can state that the rationale is history. Many of the assists in
>> the low 32 bits are for 32-bit guests only. But we can't start refusing
>> a 64-bit kernel requesting them. The ones in the high 32 bits are, for
>> now, applicable to 64-bit guests only, and have always been refused for
>> 32-bit ones.
> >
>> Imo if anything an explanation on where new bits should be put should
>> go next to the VMASST_TYPE_* definitions in the public header, yet then
>> again the public headers aren't (imo) a good place to put
>> implementation detail comments.
>
> How about splitting PV_VM_ASSIST_VALID in two? One would contain
> 64-bit PV specific flags and the other common PV flags?
>
> This should make the code more obvious and easier to read for someone
> less familiar with the area.
>
> It also means we could have a BUILD_BUG_ON() to check at build time
> that no flags are added above 32-bit.

I like this suggestion, but would suggest a 64/32 split, rather than
64/common.  These are a total mixed bag and every new one should be
considered for all ABIs rather than falling automatically into some.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 12:54:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 12:54:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQsQ2-0003gx-11; Tue, 21 Apr 2020 12:54:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=9pWK=6F=epam.com=oleksandr_andrushchenko@srs-us1.protection.inumbo.net>)
 id 1jQsQ1-0003gr-0r
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 12:54:29 +0000
X-Inumbo-ID: 3b8c5fc6-83cf-11ea-9133-12813bfff9fa
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (unknown
 [40.107.0.83]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3b8c5fc6-83cf-11ea-9133-12813bfff9fa;
 Tue, 21 Apr 2020 12:54:27 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=FfpFCwh6dzF1GIRAHtgAxrYms+56O2LpPxoqnDNwbtH41xhxkOE++E+J99KFZDyW11T5DIlpC/Bs7TqinKM+7cb1RHSK8EL+BbnC4TkWN5LM96Y5NjkGSDA1M7Xta1O+XU1JPxOmnNTGykHWewgWxCuNYSz3SoeJmhXFNDBFoUikNW+2Mnkm66RaqsneZXSjpuMevwgZ/wGkt7Qnrt1QUhguweb4BbPVq2Sax6v8O7pqDc0er+PYpVQfFa2lnkhupKar2B46DYM2EXt/03xLPlVkltpoiG6Y3ExXCyzN36AHKBI/OQYCdL4uIWwPD7T2+/JbEvVCG56dD7K4KgvE2Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kUhg6+PXb/gGujyhRwvnR9ociJ+Z2CmlNEGwIq3yeOw=;
 b=UHUITyKSMjaUhXjOYXzMlfoPW6o/mbraMS7poFXpvh5NUAzL4LryYpsaKSVPuh5akA1NLQGj52lnXFpvoYmrNTOUOqhqwBfmd+UPc302wakFgMy1R3dPOYJ+3PwG0nzpY8xNSrpP/0WFCAYw6WFQ7OvGHkkgepRAWuONFv8riI5LisZg+AN89OclOa2VM7FrFxZ9epbFZJu3U1Z/XdxC5JDePCDJ3mpCktMjg+2u4gcMlel0A0Rfi7zzuDhqEkvYYgG+zt5z4Tf8r2Cm/y4FQwqiMpue+FOTGXv1k0qC24EIK5H9gRlSsmdkOkoF8ye1qofbdyPVsrdP+xeIIVAcWA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kUhg6+PXb/gGujyhRwvnR9ociJ+Z2CmlNEGwIq3yeOw=;
 b=aOynohSb8lsBTth6zphGhsjl01We1Aktb+8wnuf9YHP2WiLIoUNthwzEbjVxN0FuCPD9o4y1FITxxRXHwIVNmfCFnqjre27TAa6cugAoNUic22OhxNaafVKmvPTTME3cPXdAxB+WAeDhXABzYCl/gpua/9ldmZkYhHQwTfZkv7Y=
Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14)
 by VI1PR03MB4638.eurprd03.prod.outlook.com (2603:10a6:803:56::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Tue, 21 Apr
 2020 12:54:25 +0000
Received: from VI1PR03MB3998.eurprd03.prod.outlook.com
 ([fe80::4144:ba6b:18cd:af5c]) by VI1PR03MB3998.eurprd03.prod.outlook.com
 ([fe80::4144:ba6b:18cd:af5c%7]) with mapi id 15.20.2921.030; Tue, 21 Apr 2020
 12:54:25 +0000
From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [bug report] drm/xen-front: Add support for Xen PV display
 frontend
Thread-Topic: [bug report] drm/xen-front: Add support for Xen PV display
 frontend
Thread-Index: AQHWF8n8HYXBbl5N3kSvZpSjxllEBqiDciuAgAAEjwCAABGqgA==
Date: Tue, 21 Apr 2020 12:54:25 +0000
Message-ID: <ea900230-25fb-2b2c-c29c-535bc44c16c7@epam.com>
References: <20200421104522.GA86681@mwanda>
 <28cc7f7c-fe0a-fd06-d330-73531b818a79@epam.com> <20200421115112.GB2682@kadam>
In-Reply-To: <20200421115112.GB2682@kadam>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=Oleksandr_Andrushchenko@epam.com; 
x-originating-ip: [185.199.97.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3ff24d75-22a8-4608-dc2b-08d7e5f31f25
x-ms-traffictypediagnostic: VI1PR03MB4638:
x-microsoft-antispam-prvs: <VI1PR03MB46387F4F64934B85BA19B1E5E7D50@VI1PR03MB4638.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 038002787A
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(10009020)(4636009)(366004)(53546011)(6506007)(81156014)(26005)(71200400001)(31696002)(2616005)(6916009)(36756003)(8676002)(8936002)(4326008)(6512007)(76116006)(6486002)(66446008)(64756008)(66556008)(66476007)(66946007)(31686004)(5660300002)(4744005)(498600001)(2906002)(86362001)(54906003)(186003);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: epam.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jPDIJMa/O3aW3FbM7CJtSKA44MS1sCI3knoZ/ZAu65lUseH9CgW7/POnSaJ9kqsx06mUG9yMrFUE6iJglt4VfI3Ssp5yKtJ64g++DSqk9VXNqVYPzQAW4Fn2Ld19hxL94MyStbwK/0cZquyrNLszI/2k4ojyskHbiqRea0U8evB+h8gAncbOzM1MJEoaSH9ND8BFoz71jqag5smcisuSkWpI/09CPHYL5VXQ3nj+5OXzE6kEr3eSAbKxuQFVHBKJPHaevvR/2qj8PkrehY+42g15Sd2folWDYMBfT4x2KvsiSqVVMy2FVqned3mIcZbW7lCfAAHmqNOFK3/Qe+KRQXIasyjKXdZya6W40Ev+Sc0/VaBSw6Wk9108UsGuDARzCwE7WaHGx26gL0wv6MXkQzNk8Egp0Hbf15QW5fJcPsxLBTUujqbB2FlgdjUIy/vM
x-ms-exchange-antispam-messagedata: lvdipXn0Pnvdy7cPNQiavWOWht++FlJx6qCFRwZ+/i7XG2SVxojT5DROy6kg3JhK87dVfMZUDZRtl5bM0kQnayK4vH43S8sy72TUGiM9kUgVB/DjhVJjakFBhFVpLRL+SYfy5jTVGI56T3tqwQxRweHlz92SXgwyisr5uWdAfcM5i7PovdtYnx85QWaJnCopvQiBHk4KuFg3/kgikkoxeffKsCbkrj28FHIxVbw0EendVE7stfwQ3QBlIF2O+aQmYUPE2o339x70M289UuKp5JALe6Mxf06r1Hcb97JdO8GR3eJ+Ejhxn+bDTtSOVZWCHpwYqnNBhQxkLbu6GySHkk5xJRnB9IC93R0O9kpzDZLwyQxj4NQgeCV/1M2buIMr0x0HKqzBlJZ843/ieojTE78Rv7dY3rASUSQHh9x8p9jEXpv0PODaDKYVM7wNdI/1XFgc8wZVw0SbiVjHKUqBzuOmBtEzVbhIo6GTzTTbInVOvmvL1nPQZBoeM4NoelL3GifmWvWApMTEiy7BsZ6wkE30mfhk4rrK2Laym3Q1U06nQQLPIvuuDF46znLpONSoRbSprnQpsVD9usQX1kIbkL5MqEung5UG0REVsExZgvdXlSQ82wKw+bcPRpp9KPwRBDTZhFh0cYDlkw2D2kvbMhogjpsl67N4IbYhXVV7Uta4BPnsA2+qCm0wYodbL1h40d8mjDdZgKCpRsw+byIXsDs31nPOrF6bi8WY8L8TzFaqzP5dkrS20P/L9DYR2JN5+RDBoi7xeLrGTvBJcb2t0tT94GcpZDOKDPQVmXnKssw=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <77FB5B472DD20940A15971BEA76ADB7D@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ff24d75-22a8-4608-dc2b-08d7e5f31f25
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 12:54:25.7183 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9xm/TJ3X1CQ7fy/lFfyB/TNKmyGPWc32Ue3no4BT1WGpTia1mICueKp2pv4JbpYbFUxTifjj65Yt2NjwkG/b5+sHv8yZNRXZxjKyQrl20mzI/84kRJzsTLxlBLUg96Je
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4638
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "kernel-janitors@vger.kernel.org" <kernel-janitors@vger.kernel.org>,
 "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

T24gNC8yMS8yMCAxNDo1MSwgRGFuIENhcnBlbnRlciB3cm90ZToNCj4gSXQgdHVybnMgb3V0IHRo
ZXJlIGFyZW4ndCB0aGF0IG1hbnkgb2YgdGhlc2UgaW4geGVuLg0KPg0KPiAkIGdyZXAgSVNfRVJS
X09SX05VTEwgZHJpdmVycy9ncHUvZHJtL3hlbi8gLVJuDQo+IGRyaXZlcnMvZ3B1L2RybS94ZW4v
eGVuX2RybV9mcm9udF9rbXMuYzo2MzogICAgIGlmIChJU19FUlJfT1JfTlVMTChmYikpDQo+IGRy
aXZlcnMvZ3B1L2RybS94ZW4veGVuX2RybV9mcm9udF9nZW0uYzo4NjogICAgIGlmIChJU19FUlJf
T1JfTlVMTCh4ZW5fb2JqKSkNCj4gZHJpdmVycy9ncHUvZHJtL3hlbi94ZW5fZHJtX2Zyb250X2dl
bS5jOjEyMDogICAgaWYgKElTX0VSUl9PUl9OVUxMKHhlbl9vYmotPnBhZ2VzKSkgew0KPiBkcml2
ZXJzL2dwdS9kcm0veGVuL3hlbl9kcm1fZnJvbnRfZ2VtLmM6MTM5OiAgICBpZiAoSVNfRVJSX09S
X05VTEwoeGVuX29iaikpDQo+IGRyaXZlcnMvZ3B1L2RybS94ZW4veGVuX2RybV9mcm9udF9nZW0u
YzoxOTc6ICAgIGlmIChJU19FUlJfT1JfTlVMTCh4ZW5fb2JqKSkNCj4gZHJpdmVycy9ncHUvZHJt
L3hlbi94ZW5fZHJtX2Zyb250LmM6NDAzOiAgICAgICAgaWYgKElTX0VSUl9PUl9OVUxMKG9iaikp
IHsNCj4NCj4gVGhleSdyZSBhbGwgd3JvbmcsIGJlY2F1c2UgaWYgdGhlIHBvaW50ZXIgd2FzIHJl
YWxseSBOVUxMIHRoZW4gaXQncw0KPiBub3QgaGFuZGxlZCBjb3JyZWN0bHkgYW5kIHdvdWxkIGV2
ZW50dWFsbHkgbGVhZCB0byBhIHJ1bnRpbWUgZmFpbHVyZS4NCj4NCj4gTm9ybWFsbHkgU21hdGNo
IGlzIHNtYXJ0IGVub3VnaCB0byBrbm93IHRoYXQgdGhlIHBvaW50ZXIgaXNuJ3QgTlVMTCBzbw0K
PiBpdCBkb2Vzbid0IGdlbmVyYXRlIGEgd2FybmluZyBidXQgeWVzdGVyZGF5IEkgaW50cm9kdWNl
ZCBhIGJ1ZyBpbiBTbWF0Y2gNCj4gYnkgbWlzdGFrZS4gIEl0J3MgZml4ZWQgbm93Lg0KPg0KPiBy
ZWdhcmRzLA0KPiBkYW4gY2FycGVudGVyDQo+DQpUaGFuayB5b3UsDQoNCkknbGwgaGF2ZSBhIGxv
b2sgYXQgdGhvc2UNCg==


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 12:59:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 12:59:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQsUc-0003ri-Q7; Tue, 21 Apr 2020 12:59:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQsUb-0003rd-Q5
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 12:59:13 +0000
X-Inumbo-ID: e5e73a18-83cf-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e5e73a18-83cf-11ea-b4f4-bc764e2007e4;
 Tue, 21 Apr 2020 12:59:13 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6DA30ABE7;
 Tue, 21 Apr 2020 12:59:11 +0000 (UTC)
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <80288e76-aff6-61d5-71aa-ae7c8e9d9a65@suse.com>
 <20200421104335.GU28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <21abc8e6-5665-9d6f-395f-6e4eb8bf2e58@suse.com>
Date: Tue, 21 Apr 2020 14:59:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421104335.GU28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 12:43, Roger Pau Monné wrote:
> On Tue, Apr 21, 2020 at 12:21:12PM +0200, Jan Beulich wrote:
>> On 16.04.2020 15:59, Roger Pau Monne wrote:
>>> Introduce a specific flag to request a HVM guest linear TLB flush,
>>> which is an ASID/VPID tickle that forces a guest linear to guest
>>> physical TLB flush for all HVM guests.
>>>
>>> This was previously unconditionally done in each pre_flush call, but
>>> that's not required: HVM guests not using shadow don't require linear
>>> TLB flushes as Xen doesn't modify the guest page tables in that case
>>> (ie: when using HAP).
>>
>> I'm afraid I'm being confused by this: Even in shadow mode Xen
>> doesn't modify guest page tables, does it?
> 
> I'm also confused now. It's my understand that when running in shadow
> mode guest page tables are not actually used, and the guest uses Xen's
> crafted shadow tables instead, which are based on the original guest
> page tables suitably adjusted by Xen in order to do the p2m
> translation in the HVM case, or the needed PTE adjustments in the PV
> case.
> 
> So guest page tables are not modified, but are also not used as they
> are never loaded into cr3.

This matches my understanding.

>>> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
>>>  
>>>      return flags;
>>>  }
>>> +
>>> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
>>> +{
>>> +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
>>> +                                                                   : 0) |
>>> +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
>>> +                                                          : 0);
>>
>> Why the is_pv_domain() part of the condition? Afaict for PV
>> domains you can get here only if they have shadow mode enabled.
> 
> Right now yes, the only way to get here for PV domains is when using
> shadow, but if this helper gets used in other non-shadow PV paths then
> Xen's needs to do a TLB flush.

Why would a non-shdow PV path find a need to call this function?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 13:52:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 13:52:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQtJc-0000Zw-1m; Tue, 21 Apr 2020 13:51:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Zbep=6F=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jQtJa-0000Zr-7J
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 13:51:54 +0000
X-Inumbo-ID: 40e95976-83d7-11ea-9146-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 40e95976-83d7-11ea-9146-12813bfff9fa;
 Tue, 21 Apr 2020 13:51:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587477113;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=Sh7/fshD/STrrXYzJ6J4SzYayDsi9ZusIGDEMiMQapo=;
 b=ejRJT/y2uRLxER4dzU5x068ROfkgmJwQBfvWmdNjYP7KpLyRjIOow+40
 PHYjaZ5XkZpsQHyANp78LbyGgfo12sqwpz+OW2tbXL0176huLoC687VPG
 /nbEIWu7B35+soU1wkLiI/EMzHTe+mIrjiB/XNiOKVD2DrOhVCw1YiUxZ 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: n+jV2mVCOHIfT5fIQ4JqxYewBtVaZ4UF4JdCnEy0u++GsLbSbEFKOcqZSb/EPYjPahm+OGJIRj
 vwnKKEIgkBkzj6o6UfOnB26lmHHy+uwSryfH1iip6XCXj5MF9F84qeSfpkZdyfK2FxF1ggLmnE
 dyf318e2Ikx4mAvOjC7QlikBU+JEhWwuVmgiKyrVJQioLUsIFeCSMpubv35h+ebMyjgTrNSZil
 bqW9x0vtJGcKlwol80DnTHtaLzMToigCT8PqTqxgPZ2esYYpon9eg5PZSo0/qMxl8JbxBvbcUq
 pLY=
X-SBRS: 2.7
X-MesageID: 15987758
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="15987758"
Date: Tue, 21 Apr 2020 15:51:44 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200421135144.GV28601@Air-de-Roger>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <80288e76-aff6-61d5-71aa-ae7c8e9d9a65@suse.com>
 <20200421104335.GU28601@Air-de-Roger>
 <21abc8e6-5665-9d6f-395f-6e4eb8bf2e58@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <21abc8e6-5665-9d6f-395f-6e4eb8bf2e58@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 02:59:10PM +0200, Jan Beulich wrote:
> On 21.04.2020 12:43, Roger Pau Monné wrote:
> > On Tue, Apr 21, 2020 at 12:21:12PM +0200, Jan Beulich wrote:
> >> On 16.04.2020 15:59, Roger Pau Monne wrote:
> >>> Introduce a specific flag to request a HVM guest linear TLB flush,
> >>> which is an ASID/VPID tickle that forces a guest linear to guest
> >>> physical TLB flush for all HVM guests.
> >>>
> >>> This was previously unconditionally done in each pre_flush call, but
> >>> that's not required: HVM guests not using shadow don't require linear
> >>> TLB flushes as Xen doesn't modify the guest page tables in that case
> >>> (ie: when using HAP).
> >>
> >> I'm afraid I'm being confused by this: Even in shadow mode Xen
> >> doesn't modify guest page tables, does it?
> > 
> > I'm also confused now. It's my understand that when running in shadow
> > mode guest page tables are not actually used, and the guest uses Xen's
> > crafted shadow tables instead, which are based on the original guest
> > page tables suitably adjusted by Xen in order to do the p2m
> > translation in the HVM case, or the needed PTE adjustments in the PV
> > case.
> > 
> > So guest page tables are not modified, but are also not used as they
> > are never loaded into cr3.
> 
> This matches my understanding.

Please bear with me, as I'm not sure if your question was because you
think the paragraph is not clear and/or should be expanded.

The point of the paragraph you mention was to have a difference
between guests running in shadow mode vs guests running in HAP mode.
Maybe I should use guest loaded page pages, to differentiate between
guest created page tables and the page tables actually loaded in cr3
in guest mode?

> >>> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
> >>>  
> >>>      return flags;
> >>>  }
> >>> +
> >>> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
> >>> +{
> >>> +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
> >>> +                                                                   : 0) |
> >>> +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> >>> +                                                          : 0);
> >>
> >> Why the is_pv_domain() part of the condition? Afaict for PV
> >> domains you can get here only if they have shadow mode enabled.
> > 
> > Right now yes, the only way to get here for PV domains is when using
> > shadow, but if this helper gets used in other non-shadow PV paths then
> > Xen's needs to do a TLB flush.
> 
> Why would a non-shdow PV path find a need to call this function?

The memory management code in PV guests also needs to perform TLB
flushes, so I wasn't sure whether the aim was to also switch it to use
guest_flush_tlb_mask.

I guess this doesn't make a lot of sense since PV guests just need a
plain TLB flush, and there's not a lot of benefit from having a helper
around that. Maybe for PV guests running in XPTI mode, where the flush
can be avoided as the return to guest path already flushes the page
tables? Anyway, will remove the is_pv_domain check.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 14:09:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 14:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQtao-0001iS-LU; Tue, 21 Apr 2020 14:09:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQtao-0001iN-59
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 14:09:42 +0000
X-Inumbo-ID: be4548a6-83d9-11ea-9147-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id be4548a6-83d9-11ea-9147-12813bfff9fa;
 Tue, 21 Apr 2020 14:09:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E07F4AC46;
 Tue, 21 Apr 2020 14:09:39 +0000 (UTC)
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <80288e76-aff6-61d5-71aa-ae7c8e9d9a65@suse.com>
 <20200421104335.GU28601@Air-de-Roger>
 <21abc8e6-5665-9d6f-395f-6e4eb8bf2e58@suse.com>
 <20200421135144.GV28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <38804079-7363-4098-88dd-b37e039498b5@suse.com>
Date: Tue, 21 Apr 2020 16:09:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421135144.GV28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 15:51, Roger Pau Monné wrote:
> On Tue, Apr 21, 2020 at 02:59:10PM +0200, Jan Beulich wrote:
>> On 21.04.2020 12:43, Roger Pau Monné wrote:
>>> On Tue, Apr 21, 2020 at 12:21:12PM +0200, Jan Beulich wrote:
>>>> On 16.04.2020 15:59, Roger Pau Monne wrote:
>>>>> Introduce a specific flag to request a HVM guest linear TLB flush,
>>>>> which is an ASID/VPID tickle that forces a guest linear to guest
>>>>> physical TLB flush for all HVM guests.
>>>>>
>>>>> This was previously unconditionally done in each pre_flush call, but
>>>>> that's not required: HVM guests not using shadow don't require linear
>>>>> TLB flushes as Xen doesn't modify the guest page tables in that case
>>>>> (ie: when using HAP).
>>>>
>>>> I'm afraid I'm being confused by this: Even in shadow mode Xen
>>>> doesn't modify guest page tables, does it?
>>>
>>> I'm also confused now. It's my understand that when running in shadow
>>> mode guest page tables are not actually used, and the guest uses Xen's
>>> crafted shadow tables instead, which are based on the original guest
>>> page tables suitably adjusted by Xen in order to do the p2m
>>> translation in the HVM case, or the needed PTE adjustments in the PV
>>> case.
>>>
>>> So guest page tables are not modified, but are also not used as they
>>> are never loaded into cr3.
>>
>> This matches my understanding.
> 
> Please bear with me, as I'm not sure if your question was because you
> think the paragraph is not clear and/or should be expanded.
> 
> The point of the paragraph you mention was to have a difference
> between guests running in shadow mode vs guests running in HAP mode.
> Maybe I should use guest loaded page pages, to differentiate between
> guest created page tables and the page tables actually loaded in cr3
> in guest mode?

How about using "the pages tables the guest runs on"?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 14:36:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 14:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQu0a-0004HH-U6; Tue, 21 Apr 2020 14:36:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQu0Z-0004HC-HY
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 14:36:19 +0000
X-Inumbo-ID: 764a5b14-83dd-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 764a5b14-83dd-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 14:36:18 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 11691AEF6;
 Tue, 21 Apr 2020 14:36:17 +0000 (UTC)
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v3 0/2] x86: VM assist hypercall adjustments
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Message-ID: <cb2dd3ad-2f38-1576-7743-7525e77704b5@suse.com>
Date: Tue, 21 Apr 2020 16:36:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

1: HVM: expose VM assist hypercall
2: validate VM assist value in arch_set_info_guest()

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 14:39:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 14:39:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQu3Q-0004PW-Dz; Tue, 21 Apr 2020 14:39:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQu3O-0004PR-I5
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 14:39:14 +0000
X-Inumbo-ID: de836d06-83dd-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id de836d06-83dd-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 14:39:13 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id ECC0AAEE6;
 Tue, 21 Apr 2020 14:39:11 +0000 (UTC)
Subject: [PATCH v3 1/2] x86/HVM: expose VM assist hypercall
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <cb2dd3ad-2f38-1576-7743-7525e77704b5@suse.com>
Message-ID: <5ed6b8a1-1f05-c24b-b3a8-d170a315d92a@suse.com>
Date: Tue, 21 Apr 2020 16:39:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <cb2dd3ad-2f38-1576-7743-7525e77704b5@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In preparation for the addition of VMASST_TYPE_runstate_update_flag
commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
the hypercall for Arm. I consider it not logical that it then isn't also
exposed to x86 HVM guests (with the same single feature permitted to be
enabled as Arm has); Linux actually tries to use it afaict.

Rather than introducing yet another thin wrapper around vm_assist(),
make that function the main handler, requiring a per-arch
arch_vm_assist_valid_mask() definition instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
v3: Rename to arch_vm_assist_valid_mask(). Have separate 32- and 64-bit
    PV #define-s.
v2: Re-work vm_assist() handling/layering at the same time. Also adjust
    arch_set_info_guest().

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -939,6 +939,9 @@ int arch_set_info_guest(
         v->arch.dr6 = c(debugreg[6]);
         v->arch.dr7 = c(debugreg[7]);
 
+        if ( v->vcpu_id == 0 )
+            d->vm_assist = c.nat->vm_assist;
+
         hvm_set_info_guest(v);
         goto out;
     }
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -128,6 +128,7 @@ static const hypercall_table_t hvm_hyper
 #ifdef CONFIG_GRANT_TABLE
     HVM_CALL(grant_table_op),
 #endif
+    HYPERCALL(vm_assist),
     COMPAT_CALL(vcpu_op),
     HVM_CALL(physdev_op),
     COMPAT_CALL(xen_version),
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -57,7 +57,7 @@ const hypercall_table_t pv_hypercall_tab
 #ifdef CONFIG_GRANT_TABLE
     COMPAT_CALL(grant_table_op),
 #endif
-    COMPAT_CALL(vm_assist),
+    HYPERCALL(vm_assist),
     COMPAT_CALL(update_va_mapping_otherdomain),
     COMPAT_CALL(iret),
     COMPAT_CALL(vcpu_op),
--- a/xen/common/compat/kernel.c
+++ b/xen/common/compat/kernel.c
@@ -37,11 +37,6 @@ CHECK_TYPE(capabilities_info);
 
 CHECK_TYPE(domain_handle);
 
-#ifdef COMPAT_VM_ASSIST_VALID
-#undef VM_ASSIST_VALID
-#define VM_ASSIST_VALID COMPAT_VM_ASSIST_VALID
-#endif
-
 #define DO(fn) int compat_##fn
 #define COMPAT
 
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
     return rc;
 }
 
-#ifdef VM_ASSIST_VALID
-long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
-               unsigned long valid)
+#ifdef arch_vm_assist_valid_mask
+long do_vm_assist(unsigned int cmd, unsigned int type)
 {
+    struct domain *currd = current->domain;
+    const unsigned long valid = arch_vm_assist_valid_mask(currd);
+
     if ( type >= BITS_PER_LONG || !test_bit(type, &valid) )
         return -EINVAL;
 
     switch ( cmd )
     {
     case VMASST_CMD_enable:
-        set_bit(type, &p->vm_assist);
+        set_bit(type, &currd->vm_assist);
         return 0;
+
     case VMASST_CMD_disable:
-        clear_bit(type, &p->vm_assist);
+        clear_bit(type, &currd->vm_assist);
         return 0;
     }
 
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -566,13 +566,6 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDL
     return -ENOSYS;
 }
 
-#ifdef VM_ASSIST_VALID
-DO(vm_assist)(unsigned int cmd, unsigned int type)
-{
-    return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
-}
-#endif
-
 /*
  * Local variables:
  * mode: C
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -195,8 +195,6 @@ extern unsigned long frametable_virt_end
 #define watchdog_disable() ((void)0)
 #define watchdog_enable()  ((void)0)
 
-#define VM_ASSIST_VALID          (1UL << VMASST_TYPE_runstate_update_flag)
-
 #endif /* __ARM_CONFIG_H__ */
 /*
  * Local variables:
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -269,6 +269,8 @@ static inline void free_vcpu_guest_conte
 
 static inline void arch_vcpu_block(struct vcpu *v) {}
 
+#define arch_vm_assist_valid_mask(d) (1UL << VMASST_TYPE_runstate_update_flag)
+
 #endif /* __ASM_DOMAIN_H__ */
 
 /*
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -309,17 +309,6 @@ extern unsigned long xen_phys_start;
 #define ARG_XLAT_START(v)        \
     (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
 
-#define NATIVE_VM_ASSIST_VALID   ((1UL << VMASST_TYPE_4gb_segments)        | \
-                                  (1UL << VMASST_TYPE_4gb_segments_notify) | \
-                                  (1UL << VMASST_TYPE_writable_pagetables) | \
-                                  (1UL << VMASST_TYPE_pae_extended_cr3)    | \
-                                  (1UL << VMASST_TYPE_architectural_iopl)  | \
-                                  (1UL << VMASST_TYPE_runstate_update_flag)| \
-                                  (1UL << VMASST_TYPE_m2p_strict))
-#define VM_ASSIST_VALID          NATIVE_VM_ASSIST_VALID
-#define COMPAT_VM_ASSIST_VALID   (NATIVE_VM_ASSIST_VALID & \
-                                  ((1UL << COMPAT_BITS_PER_LONG) - 1))
-
 #define ELFSIZE 64
 
 #define ARCH_CRASH_SAVE_VMCOREINFO
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -694,6 +694,25 @@ static inline void pv_inject_sw_interrup
     pv_inject_event(&event);
 }
 
+#define PV32_VM_ASSIST_MASK ((1UL << VMASST_TYPE_4gb_segments)        | \
+                             (1UL << VMASST_TYPE_4gb_segments_notify) | \
+                             (1UL << VMASST_TYPE_writable_pagetables) | \
+                             (1UL << VMASST_TYPE_pae_extended_cr3)    | \
+                             (1UL << VMASST_TYPE_architectural_iopl)  | \
+                             (1UL << VMASST_TYPE_runstate_update_flag))
+/*
+ * Various of what PV32_VM_ASSIST_MASK has isn't really applicable to 64-bit,
+ * but we can't make such requests fail all of the sudden.
+ */
+#define PV64_VM_ASSIST_MASK (PV32_VM_ASSIST_MASK                      | \
+                             (1UL << VMASST_TYPE_m2p_strict))
+#define HVM_VM_ASSIST_MASK  (1UL << VMASST_TYPE_runstate_update_flag)
+
+#define arch_vm_assist_valid_mask(d) \
+    (is_hvm_domain(d) ? HVM_VM_ASSIST_MASK \
+                      : is_pv_32bit_domain(d) ? PV32_VM_ASSIST_MASK \
+                                              : PV64_VM_ASSIST_MASK)
+
 #endif /* __ASM_DOMAIN_H__ */
 
 /*
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -192,8 +192,6 @@ extern int compat_xsm_op(
 
 extern int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg);
 
-extern int compat_vm_assist(unsigned int cmd, unsigned int type);
-
 DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t);
 extern int compat_multicall(
     XEN_GUEST_HANDLE_PARAM(multicall_entry_compat_t) call_list,
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -122,8 +122,6 @@ extern void guest_printk(const struct do
     __attribute__ ((format (printf, 2, 3)));
 extern void noreturn panic(const char *format, ...)
     __attribute__ ((format (printf, 1, 2)));
-extern long vm_assist(struct domain *, unsigned int cmd, unsigned int type,
-                      unsigned long valid);
 extern int __printk_ratelimit(int ratelimit_ms, int ratelimit_burst);
 extern int printk_ratelimit(void);
 



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 14:39:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 14:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQu3X-0004QV-Oc; Tue, 21 Apr 2020 14:39:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=mjY1=6F=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jQu3V-0004Q9-JL
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 14:39:21 +0000
X-Inumbo-ID: e2ff30a4-83dd-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e2ff30a4-83dd-11ea-9e09-bc764e2007e4;
 Tue, 21 Apr 2020 14:39:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=BLUVMe9WpBDKTMdFF5kh2+6UvRoh84tfQiIkterFJ3E=; b=2S3KloCSUvokdsNb1KaEjv4aq
 VTpTMQk2xhXS0x1mdJLAE4vBeLR9sONngBskd+R0ataj4Os4+g6eS0rpw/gJey4//TyW9nkLqY9ky
 M7o7LH5L6c6W4Za1KimuD7LVinn/hNCj2WpGyN28MTqMuOHMPgtOQRrYIfEOCJxaqX3u4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jQu3U-0001FJ-IF; Tue, 21 Apr 2020 14:39:20 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jQu3U-0002Yn-8q; Tue, 21 Apr 2020 14:39:20 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jQu3U-0008WL-5c; Tue, 21 Apr 2020 14:39:20 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149713-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149713: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=7aacf6ac49829d8dd6242f67460f4d52d0d36503
X-Osstest-Versions-That: xen=82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 21 Apr 2020 14:39:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  7aacf6ac49829d8dd6242f67460f4d52d0d36503
baseline version:
 xen                  82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638

Last test of basis   149699  2020-04-17 08:00:46 Z    4 days
Testing same since   149713  2020-04-21 11:00:34 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christian Lindig <christian.lindig@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Tim Deegan <tim@xen.org>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   82dd1a956d..7aacf6ac49  7aacf6ac49829d8dd6242f67460f4d52d0d36503 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 14:39:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 14:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQu3r-0004V3-82; Tue, 21 Apr 2020 14:39:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=OiHr=6F=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jQu3q-0004Us-Dk
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 14:39:42 +0000
X-Inumbo-ID: ef5c5caa-83dd-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ef5c5caa-83dd-11ea-b4f4-bc764e2007e4;
 Tue, 21 Apr 2020 14:39:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7522DAEF6;
 Tue, 21 Apr 2020 14:39:40 +0000 (UTC)
Subject: [PATCH v3 2/2] x86: validate VM assist value in arch_set_info_guest()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <cb2dd3ad-2f38-1576-7743-7525e77704b5@suse.com>
Message-ID: <60f51e40-ada5-b206-cfd3-d1cc1d24c382@suse.com>
Date: Tue, 21 Apr 2020 16:39:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <cb2dd3ad-2f38-1576-7743-7525e77704b5@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While I can't spot anything that would go wrong, just like the
respective hypercall only permits applicable bits to be set, we should
also do so when loading guest context.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
I'd like to note that Arm lacks a field to save/restore vm_assist.

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -932,6 +932,9 @@ int arch_set_info_guest(
         }
     }
 
+    if ( v->vcpu_id == 0 && (c(vm_assist) & ~arch_vm_assist_valid_mask(d)) )
+        return -EINVAL;
+
     if ( is_hvm_domain(d) )
     {
         for ( i = 0; i < ARRAY_SIZE(v->arch.dr); ++i )



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 15:48:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 15:48:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQv7f-0002Hh-Um; Tue, 21 Apr 2020 15:47:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=vOT2=6F=inria.fr=julia.lawall@srs-us1.protection.inumbo.net>)
 id 1jQupw-0000ZQ-MV
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 15:29:24 +0000
X-Inumbo-ID: e050e184-83e4-11ea-9e09-bc764e2007e4
Received: from mail2-relais-roc.national.inria.fr (unknown [192.134.164.83])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e050e184-83e4-11ea-9e09-bc764e2007e4;
 Tue, 21 Apr 2020 15:29:23 +0000 (UTC)
X-IronPort-AV: E=Sophos;i="5.72,410,1580770800"; d="scan'208";a="446201452"
Received: from abo-173-121-68.mrs.modulonet.fr (HELO hadrien) ([85.68.121.173])
 by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 21 Apr 2020 17:29:02 +0200
Date: Tue, 21 Apr 2020 17:29:02 +0200 (CEST)
From: Julia Lawall <julia.lawall@inria.fr>
X-X-Sender: jll@hadrien
To: Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [bug report] drm/xen-front: Add support for Xen PV display
 frontend
In-Reply-To: <20200421104522.GA86681@mwanda>
Message-ID: <alpine.DEB.2.21.2004211728360.3118@hadrien>
References: <20200421104522.GA86681@mwanda>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Mailman-Approved-At: Tue, 21 Apr 2020 15:47:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, kernel-janitors@vger.kernel.org,
 dri-devel@lists.freedesktop.org, oleksandr_andrushchenko@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On Tue, 21 Apr 2020, Dan Carpenter wrote:

> Hi Kernel Janitors,
>
> Here is another idea that someone could work on, fixing the
> IS_ERR_OR_NULL() checks in the xen driver.
>
> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> display frontend" from Apr 3, 2018, leads to the following static
> checker warning:
>
> 	drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
> 	warn: passing zero to 'ERR_CAST'
>
> drivers/gpu/drm/xen/xen_drm_front_gem.c
>    133  struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
>    134                                                  size_t size)
>    135  {
>    136          struct xen_gem_object *xen_obj;
>    137
>    138          xen_obj = gem_create(dev, size);
>    139          if (IS_ERR_OR_NULL(xen_obj))
>    140                  return ERR_CAST(xen_obj);

Are the other occurrences of this also a possible problem?  There are a
few others outside of xen.

julia

>
> This warning is old and it's actually the result of a bug I had in my
> devel version of Smatch yesterday.  xen_obj can't really be NULL, but
> if it were then the caller would return success which would probably
> create some issues.
>
> When a function returns both error pointers and NULL then NULL is a
> special case of success.  Like say you have:  "p = start_feature();".
> If there is an allocation failure, then the code should return -ENOMEM
> and the whole thing should fail.  But if the feature is optional and
> the user has disabled it in the config then we return NULL and the
> caller has to be able to accept that.  There are a lot of these
> IS_ERR_OR_NULL() checks in the xen driver...
>
> The one here is clearly buggy because returning NULL would lead to a
> run time failure.  All these IS_ERR_OR_NULL() should be checked and
> probably changed to just IS_ERR().
>
> This sort of change is probably change is probably easiest if you build
> the Smatch DB and you can check if Smatch thinks the functions return
> NULL.
>
> ~/smatch/smatch_data/db/smdb.py return_states gem_create | grep INTERNAL
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 58 |  (-4095)-(-1) |      INTERNAL |  -1 |                      | struct xen_gem_object*(*)(struct drm_device*, ulong) |
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 62 | 4065035897849303040 |      INTERNAL |  -1 |                      | struct xen_gem_object*(*)(struct drm_device*, ulong) |
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 66 | 4065035897849303040 |      INTERNAL |  -1 |                      | struct xen_gem_object*(*)(struct drm_device*, ulong) |
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 68 | 0,(-4095)-(-1) |      INTERNAL |  -1 |                      | struct xen_gem_object*(*)(struct drm_device*, ulong) |
>
> Smatch thinks that gem_create() sometimes returns NULL or error pointers
> but that's because of a bug in the unreleased version of Smatch and
> because gem_create() uses IS_ERR_OR_NULL().
>
>    141
>    142          return &xen_obj->base;
>    143  }
>
> regards,
> dan carpenter
>


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVe-0005Q5-G6; Tue, 21 Apr 2020 16:12:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVd-0005Pr-GB
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:29 +0000
X-Inumbo-ID: e3959744-83ea-11ea-9160-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e3959744-83ea-11ea-9160-12813bfff9fa;
 Tue, 21 Apr 2020 16:12:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485545;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=8SweUxOrsIVVWZNbjHYtMG1kL0UrANIJUt364vs9N/M=;
 b=hksGa1KX7E0+HMHmosPokprDpxw+gSiTHk7oWcBrB8mqct0/duZAQMQF
 t4hQyEXDprGF0hrSaUvlP9D+stErSvqKItCShHRYb9m07HQ7HCI3n+cmC
 N7WL7t/WqIFdY5QOpNbC4LJ2ilWoBO7IVpt7HyzIxZe6ACXsrbR2WX4Wz Q=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: bWyQ/LK6H5KZ+jo5oBnN3C/uKUGO3b8/lj6XwHPT9XyO+cRH5z0v1ErmJ7n9e8ZirgCNMPxOnC
 /mngHYO4494Rl95wWOzIX6YcHCfPgbrzi3MM/GsadORJ6Ef5m90RKyEwi8Rn/Dh4duuXLCMiOU
 2U9Rq13wzw+AGrZhem67uzb2fvaU4tfew+078ULYmxLV5NT5xd3MjKuCGO6bU+eYIQRxAM6uU6
 pXA+ANICkm6Y8OXmpTceU0RKhP1bnYJi/J4pkjnich+vfJA2ByR+6yt+4SrjADqnxkG4x7ipsz
 t0Y=
X-SBRS: 2.7
X-MesageID: 16028576
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16028576"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 01/16] build,xsm: Fix multiple call
Date: Tue, 21 Apr 2020 17:11:53 +0100
Message-ID: <20200421161208.2429539-2-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Both script mkflask.sh and mkaccess_vector.sh generates multiple
files. Exploits the 'multi-target pattern rule' trick to call each
scripts only once.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---

Notes:
    v5:
    - Use simpler $(subst ) instead of $(patsubst )
    - moved the patch ahead in the series
    
    v4:
    - new patch

 xen/xsm/flask/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index b1fd45421993..f001bb18d4ed 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -21,10 +21,10 @@ ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
 
 $(obj-y) ss/built_in.o: $(ALL_H_FILES)
 
-$(FLASK_H_FILES): $(FLASK_H_DEPEND)
+$(subst include/,%/,$(FLASK_H_FILES)): $(FLASK_H_DEPEND)
 	$(CONFIG_SHELL) policy/mkflask.sh $(AWK) include $(FLASK_H_DEPEND)
 
-$(AV_H_FILES): $(AV_H_DEPEND)
+$(subst include/,%/,$(AV_H_FILES)): $(AV_H_DEPEND)
 	$(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
 
 obj-bin-$(CONFIG_XSM_FLASK_POLICY) += flask-policy.o
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVf-0005Qi-Q3; Tue, 21 Apr 2020 16:12:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVd-0005Px-Rj
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:29 +0000
X-Inumbo-ID: e4cea4b6-83ea-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e4cea4b6-83ea-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 16:12:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485548;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=TqRiWlksd5/Lp1nWEjOyVynJCuKHF40ozmWf1/OBleM=;
 b=MaMWGnTtOjL7tYetqEPrtS0XCUp/Nsviz6KDqNd/jI3ACBpTtA7OHgmO
 T0XEoM/7eohprDuNQ3tU2RV3pOAxhKRbJrn/DLwCkZ88vWHWAdiqRFMHq
 bHJenSNCUR0tTBWX2AZ7IZ44XwbqnvbAimarIp9MLShDTt3Ay9RhBiMNi o=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: dTnp1eCa59ZbhtFeom1ZCXVAsTAGLPk2LMvx41CkLgFvN/TlmNWjj7ERbOofQX3r8BraIxQU+J
 ZxM7tbgTQXc2E+fXTXBa8Z0z2XewVYCyO347aLG3/emFWTJAYUN1ylHe8nZ32nFh21b8VChSsD
 zNWU0C2ughrF5vmHfA0fECySG3WcjI1kXytYRKKYEzngbkwr7h+fkg1y7+OoHSkZeqKYTS4tMN
 aW4uPz6IapUHuOn6A+7ZCQdXYashvynVtJ+CRHO43YhWNlBX6XddA7sZg36qZiwh3yA4gfgeS8
 ios=
X-SBRS: 2.7
X-MesageID: 16414403
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16414403"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 03/16] xen/build: use new $(c_flags) and $(a_flags)
 instead of $(CFLAGS)
Date: Tue, 21 Apr 2020 17:11:55 +0100
Message-ID: <20200421161208.2429539-4-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Tim Deegan <tim@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In a later patch ("xen/build: have the root Makefile generates the
CFLAGS), we want to generate the CFLAGS in xen/Makefile, then export
it and have Rules.mk use a CFLAGS from the environment variables. That
changes the flavor of the CFLAGS and flags intended for one target
(like -D__OBJECT_FILE__ and -M%) gets propagated and duplicated. So we
start by moving such flags out of $(CFLAGS) and into $(c_flags) which
is to be modified by only Rules.mk.

__OBJECT_FILE__ is only used by arch/x86/mm/*.c files, so having it in
$(c_flags) is enough, we don't need it in $(a_flags).

For include/Makefile and as-insn we can keep using CFLAGS, but since
it doesn't have -M* flags anymore there is no need to filter them out.

The XEN_BUILD_EFI tests in arch/x86/Makefile was filtering out
CFLAGS-y, but according to dd40177c1bc8 ("x86-64/EFI: add CFLAGS to
check compile"), it was done to filter out -MF. CFLAGS doesn't
have those flags anymore, so no filtering is needed.

This is inspired by the way Kbuild generates CFLAGS for each targets.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---

Notes:
    v4:
    - drop change in as-insn macro, and keep filtering-out -M% %.d
    
    v3:
    - include/Makefile: Keep using CFLAGS, but since it doesn't have -M*
      flags anymore, no need to filter it.
    - Write c_flags and a_flags on a single line.
    - arch/x86/Makefile: remove the filter-out of dependency flags
      they are remove from CFLAGS anyway.
      (was intended to be done in xen/build: have the root Makefile
      generates the CFLAGS originally, move the change to this patch).
    - also modify as-insn as it is now xen/ only.

 xen/Rules.mk                    | 23 +++++++++++------------
 xen/arch/arm/Makefile           |  4 ++--
 xen/arch/x86/Makefile           |  6 +++---
 xen/arch/x86/mm/Makefile        |  6 +++---
 xen/arch/x86/mm/hap/Makefile    |  6 +++---
 xen/arch/x86/mm/shadow/Makefile |  6 +++---
 xen/include/Makefile            |  2 +-
 7 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 9079df7978a7..3408a35dbf53 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -57,7 +57,6 @@ CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 $(call cc-option-add,CFLAGS,CC,-Wvla)
 CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS-$(CONFIG_DEBUG_INFO) += -g
-CFLAGS += '-D__OBJECT_FILE__="$@"'
 
 ifneq ($(CONFIG_CC_IS_CLANG),y)
 # Clang doesn't understand this command line argument, and doesn't appear to
@@ -70,9 +69,6 @@ AFLAGS += -D__ASSEMBLY__
 
 ALL_OBJS := $(ALL_OBJS-y)
 
-# Get gcc to generate the dependencies for us.
-CFLAGS-y += -MMD -MP -MF $(@D)/.$(@F).d
-
 CFLAGS += $(CFLAGS-y)
 # allow extra CFLAGS externally via EXTRA_CFLAGS_XEN_CORE
 CFLAGS += $(EXTRA_CFLAGS_XEN_CORE)
@@ -146,9 +142,12 @@ endif
 # Always build obj-bin files as binary even if they come from C source. 
 $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
 
+c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(CFLAGS) '-D__OBJECT_FILE__="$@"'
+a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(AFLAGS)
+
 built_in.o: $(obj-y) $(extra-y)
 ifeq ($(obj-y),)
-	$(CC) $(CFLAGS) -c -x c /dev/null -o $@
+	$(CC) $(c_flags) -c -x c /dev/null -o $@
 else
 ifeq ($(CONFIG_LTO),y)
 	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
@@ -159,7 +158,7 @@ endif
 
 built_in_bin.o: $(obj-bin-y) $(extra-y)
 ifeq ($(obj-bin-y),)
-	$(CC) $(AFLAGS) -c -x assembler /dev/null -o $@
+	$(CC) $(a_flags) -c -x assembler /dev/null -o $@
 else
 	$(LD) $(LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
 endif
@@ -178,7 +177,7 @@ SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR))
 
 %.o: %.c Makefile
 ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y)
-	$(CC) $(CFLAGS) -c $< -o $(@D)/.$(@F).tmp -MQ $@
+	$(CC) $(c_flags) -c $< -o $(@D)/.$(@F).tmp -MQ $@
 ifeq ($(CONFIG_CC_IS_CLANG),y)
 	$(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< $(@D)/.$(@F).tmp $@
 else
@@ -186,11 +185,11 @@ else
 endif
 	rm -f $(@D)/.$(@F).tmp
 else
-	$(CC) $(CFLAGS) -c $< -o $@
+	$(CC) $(c_flags) -c $< -o $@
 endif
 
 %.o: %.S Makefile
-	$(CC) $(AFLAGS) -c $< -o $@
+	$(CC) $(a_flags) -c $< -o $@
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
 	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name sz rest; do \
@@ -205,12 +204,12 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
 	$(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
 
 %.i: %.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) $< -o $@
+	$(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
 
 %.s: %.c Makefile
-	$(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -S $< -o $@
+	$(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
 
 %.s: %.S Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(AFLAGS)) $< -o $@
+	$(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
 
 -include $(DEPS_INCLUDE)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7273f356f190..913f6cdeed3f 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -120,10 +120,10 @@ $(TARGET)-syms: prelink.o xen.lds
 	rm -f $(@D)/.$(@F).[0-9]*
 
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
-	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
+	$(CC) $(filter-out -flto,$(c_flags)) -S -o $@ $<
 
 xen.lds: xen.lds.S
-	$(CC) -P -E -Ui386 $(AFLAGS) -o $@ $<
+	$(CC) -P -E -Ui386 $(a_flags) -o $@ $<
 	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
 	mv -f .xen.lds.d.new .xen.lds.d
 
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index e954edbc2e0a..1405525105d9 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -168,7 +168,7 @@ EFI_LDFLAGS += --major-os-version=2 --minor-os-version=0
 EFI_LDFLAGS += --major-subsystem-version=2 --minor-subsystem-version=0
 
 # Check if the compiler supports the MS ABI.
-export XEN_BUILD_EFI := $(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c efi/check.c -o efi/check.o 2>/dev/null && echo y)
+export XEN_BUILD_EFI := $(shell $(CC) $(CFLAGS) -c efi/check.c -o efi/check.o 2>/dev/null && echo y)
 # Check if the linker supports PE.
 XEN_BUILD_PE := $(if $(XEN_BUILD_EFI),$(shell $(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o 2>/dev/null && echo y))
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
@@ -223,7 +223,7 @@ efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o efi/relocs-dummy.o: $(B
 efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o efi/relocs-dummy.o: ;
 
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c $(BASEDIR)/include/asm-x86/asm-macros.h
-	$(CC) $(filter-out -Wa$(comma)% -flto,$(CFLAGS)) -S -o $@ $<
+	$(CC) $(filter-out -Wa$(comma)% -flto,$(c_flags)) -S -o $@ $<
 
 asm-macros.i: CFLAGS += -D__ASSEMBLY__ -P
 
@@ -240,7 +240,7 @@ $(BASEDIR)/include/asm-x86/asm-macros.h: asm-macros.i Makefile
 
 efi.lds: AFLAGS += -DEFI
 xen.lds efi.lds: xen.lds.S
-	$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
+	$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<
 	sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new
 	mv -f .$(@F).d.new .$(@F).d
 
diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index d87dc0aa6eeb..a2431fde6bb4 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -12,10 +12,10 @@ obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
 obj-y += paging.o
 
 guest_walk_%.o: guest_walk.c Makefile
-	$(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+	$(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
 
 guest_walk_%.i: guest_walk.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+	$(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
 
 guest_walk_%.s: guest_walk.c Makefile
-	$(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
+	$(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
diff --git a/xen/arch/x86/mm/hap/Makefile b/xen/arch/x86/mm/hap/Makefile
index b14a9aff93d2..22e7ad54bd33 100644
--- a/xen/arch/x86/mm/hap/Makefile
+++ b/xen/arch/x86/mm/hap/Makefile
@@ -6,10 +6,10 @@ obj-y += nested_hap.o
 obj-y += nested_ept.o
 
 guest_walk_%level.o: guest_walk.c Makefile
-	$(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+	$(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
 
 guest_walk_%level.i: guest_walk.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+	$(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
 
 guest_walk_%level.s: guest_walk.c Makefile
-	$(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
+	$(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
diff --git a/xen/arch/x86/mm/shadow/Makefile b/xen/arch/x86/mm/shadow/Makefile
index ff03a9937f9b..23d3ff10802c 100644
--- a/xen/arch/x86/mm/shadow/Makefile
+++ b/xen/arch/x86/mm/shadow/Makefile
@@ -7,10 +7,10 @@ obj-y += none.o
 endif
 
 guest_%.o: multi.c Makefile
-	$(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+	$(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
 
 guest_%.i: multi.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+	$(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
 
 guest_%.s: multi.c Makefile
-	$(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
+	$(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 433bad9055b2..a488a98d8bb7 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -64,7 +64,7 @@ compat/%.h: compat/%.i Makefile $(BASEDIR)/tools/compat-build-header.py
 	mv -f $@.new $@
 
 compat/%.i: compat/%.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $<
+	$(CPP) $(filter-out -Wa$(comma)% -include %/include/xen/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $<
 
 compat/%.c: public/%.h xlat.lst Makefile $(BASEDIR)/tools/compat-build-source.py
 	mkdir -p $(@D)
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVa-0005Ph-6R; Tue, 21 Apr 2020 16:12:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVY-0005Pc-L5
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:24 +0000
X-Inumbo-ID: e1ed0329-83ea-11ea-9160-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e1ed0329-83ea-11ea-9160-12813bfff9fa;
 Tue, 21 Apr 2020 16:12:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485543;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=jPOuSn9Ufevxvq1zCWh1f+c0TEZ2OwuaVLSgw7emdXc=;
 b=NmbqwTumiISP1mx4ONvdp0V40EsB7EK1sAMSGBjefaaAa5qybVp7Gyhc
 kK2fVauUHiRBr5u736Q/c59dph/3rHQcWcYXOVNWknAITjFTqTqoTqIo4
 jM1tf4W7//ILHfk5e5PvMoTT+dRok18iWyEfXtyQ3uyrMob94K7sEjUKa A=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: TrZj9YlMdTDuYDUspGI9xkAsdT55vuX430lEeRu5OxUvg0wzUvukPFY3A76MknI5DdwIne9per
 4/XeZztL9zxLftqN5g4Ae8ur43SctjqaEtLzBi7WtfP2LXWnk/reu+c0GzKLVtbOnhITe51+kt
 6DDKBObc6FPt4MiePseMV4yL2phlqdG8UGNo6YiXp1exj911CYMBgrqU92rht7NFJU7WiookdE
 ozFKHXv/EgtJUSGVoSLy0a8w6SZjn187T3KxnmLneHhZ2HtwTIULvdELiPtEy9Ot0WO3E3IOxf
 8AA=
X-SBRS: 2.7
X-MesageID: 16028573
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16028573"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 00/16] xen: Build system improvements
Date: Tue, 21 Apr 2020 17:11:52 +0100
Message-ID: <20200421161208.2429539-1-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Wei
 Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Tim
 Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.build-system-xen-v5

v5:
- few changes detailed in patch notes.
- 1 new patch

v4:
- some patch already applied.
- Have added patches from "xen/arm: Configure early printk via Kconfig" series.
- Some new patch to add documentation or fix issues, and patch to improve
  compat header generation.
Other changes are detailed in patches.

v3:
- new patches that do some cleanup or fix issues
- have rework most patches, to have better commit message or change the coding
  style, or fix issues that I've seen. There were some cases where CFLAGS were
  missing.
  See patch notes for details
- introduce if_changed*. That plenty of new patches on top of what we had in v2.
  (those changes ignore CONFIG_LTO=y, I'll see about fixing that later)

(There is more to come in order to use fixdep from Linux, but that's not ready)

Hi,

I have work toward building Xen (the hypervisor) with Linux's build system,
Kbuild.

The main reason for that is to be able to have out-of-tree build. It's annoying
when a build fail because of the pvshim. Other benefit is a much faster
rebuild, and `make clean` doesn't take ages, and better dependencies to figure
out what needs to be rebuild.

So, we are not there yet, but the series already contain quite a few
improvement and cleanup. More patches are going to be added to the series.

Cheers,

Anthony PERARD (16):
  build,xsm: Fix multiple call
  xen/build: include include/config/auto.conf in main Makefile
  xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)
  xen/build: have the root Makefile generates the CFLAGS
  build: Introduce documentation for xen Makefiles
  xen/build: introduce if_changed and if_changed_rule
  xen/build: Start using if_changed
  build: Introduce $(cpp_flags)
  xen/build: use if_changed on built_in.o
  xen/build: Use if_changed_rules with %.o:%.c targets
  xen/build: factorise generation of the linker scripts
  xen/build: Use if_changed for prelink*.o
  xen,symbols: rework file symbols selection
  build: use if_changed to build mm/*/guest_%.o
  build,include: rework compat-build-source.py
  build,include: rework compat-build-header.py

 .gitignore                            |   1 +
 docs/misc/xen-makefiles/makefiles.rst | 185 ++++++++++++++++++++
 xen/Makefile                          | 212 ++++++++++++++++++++---
 xen/Rules.mk                          | 235 ++++++++++++++++----------
 xen/arch/arm/Makefile                 |  22 +--
 xen/arch/arm/Rules.mk                 |  23 ---
 xen/arch/arm/{Rules.mk => arch.mk}    |   5 -
 xen/arch/arm/efi/Makefile             |   2 +-
 xen/arch/x86/Makefile                 |  41 ++---
 xen/arch/x86/Rules.mk                 |  91 +---------
 xen/arch/x86/{Rules.mk => arch.mk}    |  17 +-
 xen/arch/x86/efi/Makefile             |   9 +-
 xen/arch/x86/mm/Makefile              |  14 +-
 xen/arch/x86/mm/hap/Makefile          |  15 +-
 xen/arch/x86/mm/shadow/Makefile       |  14 +-
 xen/common/libelf/Makefile            |  14 +-
 xen/common/libfdt/Makefile            |  13 +-
 xen/include/Makefile                  |  16 +-
 xen/scripts/Kbuild.include            | 107 ++++++++++++
 xen/tools/compat-build-header.py      |  52 +++++-
 xen/tools/compat-build-source.py      |   8 +-
 xen/tools/symbols.c                   |  20 ++-
 xen/xsm/flask/Makefile                |  19 ++-
 xen/xsm/flask/ss/Makefile             |   2 +-
 24 files changed, 809 insertions(+), 328 deletions(-)
 create mode 100644 docs/misc/xen-makefiles/makefiles.rst
 copy xen/arch/arm/{Rules.mk => arch.mk} (85%)
 copy xen/arch/x86/{Rules.mk => arch.mk} (87%)

-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVj-0005Rs-7t; Tue, 21 Apr 2020 16:12:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVi-0005RF-H0
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:34 +0000
X-Inumbo-ID: e38a2fe5-83ea-11ea-9160-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e38a2fe5-83ea-11ea-9160-12813bfff9fa;
 Tue, 21 Apr 2020 16:12:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485546;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=2Y4zAqD3SPAwwyAAX03cx8+4KttgfO65JfsgLeokrM8=;
 b=g5Sv/JRviSNRAH//I/7pku8dK5A4ONMLtOrLJp/JURxYqF47RoEetwx8
 cP/8kUoBzr5rEmhO7wFDNTv65BqRyUUKozhTch+UAiYwwCUMymhUqXOq+
 cYUa6uOb2VOHlxPyGGxGHclkK46pnz2lE8ajJhPckoGr9/uYwn1NUU6hJ Y=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: iEqW7XRTwssf4VmdNrQ65MSpHXxYQaHYKFHsqXKUx5+YtZsAG2cSP1Ee+X+rh9L3qBBsMaU/Vu
 N73biyyNmvUGqmt7GG+Y2XybyxA36aIJmsO8Wm5Tq59ACIp12EAtvIsj3gFtWY0QSuqiMaTBY/
 2lG89pOIb/siMj4v6nerr9QSAgT7fcK9oVtYZYX8e93uIoAXK5dRXHBVzRTqJyQHMuQun68bJA
 Lo2LKTdXz03NzFZsghXfypfgAqUW9B9NiTg2UNitRhTdcECXyx0LTOaWqNCRzxcOTocgbt7yPk
 a1c=
X-SBRS: 2.7
X-MesageID: 16330438
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16330438"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 02/16] xen/build: include include/config/auto.conf in
 main Makefile
Date: Tue, 21 Apr 2020 17:11:54 +0100
Message-ID: <20200421161208.2429539-3-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We are going to generate the CFLAGS early from "xen/Makefile" instead
of in "Rules.mk", but we need to include "config/auto.conf", so
include it in "Makefile".

Before including "config/auto.conf" we check which make target a user
is calling, as some targets don't need "auto.conf". For targets that
needs auto.conf, make will generate it (and a default .config if
missing).

root-make-done is to avoid doing the calculation again once Rules.mk
takes over and is been executed with the root Makefile. When Rules.mk
is including xen/Makefile, `config-build' and `need-config' are
undefined so auto.conf will not be included again (it is already
included by Rules.mk) and kconfig target are out of reach of Rules.mk.

We are introducing a target %config to catch all targets for kconfig.
So we need an extra target %/.config to prevent make from trying to
regenerate $(XEN_ROOT)/.config that is included in Config.mk.

The way targets are filtered is inspired by Kbuild, with some code
imported from Linux. That's why there is PHONY variable that isn't
used yet, for example.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---

Notes:
    v5:
    - move kconfig shorthand to the only file that uses it.
    
    v4:
    - check that root-make-done hasn't been set to an expected value
      instead of checking if it has been set at all.
    - Add a shorthand $(kconfig) to run kconfig targets.
    
    v3:
    - filter only for %config instead of both config %config
    - keep the multi-target pattern rule trick for include/config/auto.conf
      instead of using Linux's newer pattern (we dont have tristate.conf so
      don't need to change it)
    - use y/n for root-make-done, config-build, need-config instead of
      relying on ifdef and ifndef and on assigning an empty value meaning
      undef
    - use space for indentation
    - explain why %/.config is suddenly needed.

 xen/Makefile | 101 +++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 78 insertions(+), 23 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index e5f7b1ae13bc..643c689658f3 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -49,7 +49,76 @@ default: build
 .PHONY: dist
 dist: install
 
-build install:: include/config/auto.conf
+
+ifneq ($(root-make-done),y)
+# section to run before calling Rules.mk, but only once.
+#
+# To make sure we do not include .config for any of the *config targets
+# catch them early, and hand them over to tools/kconfig/Makefile
+
+clean-targets := %clean
+no-dot-config-targets := $(clean-targets) \
+                         uninstall debug cloc \
+                         cscope TAGS tags MAP gtags \
+                         xenversion
+
+config-build    := n
+need-config     := y
+
+ifneq ($(filter $(no-dot-config-targets), $(MAKECMDGOALS)),)
+    ifeq ($(filter-out $(no-dot-config-targets), $(MAKECMDGOALS)),)
+        need-config := n
+    endif
+endif
+
+ifneq ($(filter %config,$(MAKECMDGOALS)),)
+    config-build := y
+endif
+
+export root-make-done := y
+endif # root-make-done
+
+include scripts/Kbuild.include
+
+# Shorthand for kconfig
+kconfig = -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
+
+ifeq ($(config-build),y)
+# ===========================================================================
+# *config targets only - make sure prerequisites are updated, and descend
+# in tools/kconfig to make the *config target
+
+config: FORCE
+	$(MAKE) $(kconfig) $@
+
+# Config.mk tries to include .config file, don't try to remake it
+%/.config: ;
+
+%config: FORCE
+	$(MAKE) $(kconfig) $@
+
+else # !config-build
+
+ifeq ($(need-config),y)
+include include/config/auto.conf
+# Read in dependencies to all Kconfig* files, make sure to run syncconfig if
+# changes are detected.
+include include/config/auto.conf.cmd
+
+# Allow people to just run `make` as before and not force them to configure
+$(KCONFIG_CONFIG):
+	$(MAKE) $(kconfig) defconfig
+
+# The actual configuration files used during the build are stored in
+# include/generated/ and include/config/. Update them if .config is newer than
+# include/config/auto.conf (which mirrors .config).
+#
+# This exploits the 'multi-target pattern rule' trick.
+# The syncconfig should be executed only once to make all the targets.
+include/config/%.conf include/config/%.conf.cmd: $(KCONFIG_CONFIG)
+	$(MAKE) $(kconfig) syncconfig
+
+endif # need-config
 
 .PHONY: build install uninstall clean distclean MAP
 build install uninstall debug clean distclean MAP::
@@ -254,9 +323,6 @@ cscope:
 _MAP:
 	$(NM) -n $(TARGET)-syms | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' > System.map
 
-.PHONY: FORCE
-FORCE:
-
 %.o %.i %.s: %.c FORCE
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(*D) $(@F)
 
@@ -277,25 +343,6 @@ $(foreach base,arch/x86/mm/guest_walk_% \
                arch/x86/mm/shadow/guest_%, \
     $(foreach ext,o i s,$(call build-intermediate,$(base).$(ext))))
 
-kconfig := oldconfig config menuconfig defconfig allyesconfig allnoconfig \
-	nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig \
-	randconfig $(notdir $(wildcard arch/$(SRCARCH)/configs/*_defconfig))
-.PHONY: $(kconfig)
-$(kconfig):
-	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
-
-include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
-	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" syncconfig
-
-# Allow people to just run `make` as before and not force them to configure
-$(KCONFIG_CONFIG):
-	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" defconfig
-
-# Break the dependency chain for the first run
-include/config/auto.conf.cmd: ;
-
--include $(BASEDIR)/include/config/auto.conf.cmd
-
 .PHONY: cloc
 cloc:
 	$(eval tmpfile := $(shell mktemp))
@@ -307,3 +354,11 @@ cloc:
 	cloc --list-file=$(tmpfile)
 	rm $(tmpfile)
 
+endif #config-build
+
+PHONY += FORCE
+FORCE:
+
+# Declare the contents of the PHONY variable as phony.  We keep that
+# information in a variable so we can use it in if_changed and friends.
+.PHONY: $(PHONY)
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVj-0005SD-HL; Tue, 21 Apr 2020 16:12:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVi-0005Rn-Pk
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:34 +0000
X-Inumbo-ID: e78d7ae2-83ea-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e78d7ae2-83ea-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 16:12:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485552;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=zEDVWtRNnmIv3S8+CaBN4lgkVkyoY1pGarxEeF5jdjg=;
 b=atS3jXv/m5cYKEdPsWKLWAxrbi3n/fvLtsukXCwBTd4hVAQQaLz2Ksmx
 7u/vMJciryE239Ei6RVZVhHXAv2kU2hegysI4T+92aPjeU2zI8N28477p
 aonxaA1hj2LBQFirlGtEicdbis5ESwm4d8Vhb8s69PFkIEpw4aNE6on6h 4=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 31oQgUFgunBghWDk/ml68DoAX8eNl8VnT+ClLsXPzU3D7PwG2lUfA2dOFsRrnGUBUtnRW0TNYK
 VX25DrgWtCljd06XhAH4imcqbJHmt3eyk3SF73rgpxyuQBdERRdc9KWlaQiScKxlOr4/TDM1xE
 Gm0QJDHZt++Zpu6qSWnVkeCZ8u1kcRhNxRLguw+/4XIYjQS4Wrti89lpjyNABqOkJ1f7gacQ19
 qFB0b7K0Nq8l2tnM7ypUlNMbzsoe5iWB5Lo8rz8T0ncw1e4+aek29kvAMWarLuBA/MkfJbyxkL
 cS8=
X-SBRS: 2.7
X-MesageID: 16414410
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16414410"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 05/16] build: Introduce documentation for xen Makefiles
Date: Tue, 21 Apr 2020 17:11:57 +0100
Message-ID: <20200421161208.2429539-6-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This start explainning the variables that can be used in the many
Makefiles in xen/.

Most of the document copies and modifies text from Linux v5.4 document
linux.git/Documentation/kbuild/makefiles.rst. Modification are mostly
to avoid mentioning kbuild. Thus I've added the SPDX tag which was
only in index.rst in linux.git.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---

Notes:
    v4:
    - new patch

 docs/misc/xen-makefiles/makefiles.rst | 87 +++++++++++++++++++++++++++
 xen/Rules.mk                          |  4 ++
 2 files changed, 91 insertions(+)
 create mode 100644 docs/misc/xen-makefiles/makefiles.rst

diff --git a/docs/misc/xen-makefiles/makefiles.rst b/docs/misc/xen-makefiles/makefiles.rst
new file mode 100644
index 000000000000..a86e3a612d61
--- /dev/null
+++ b/docs/misc/xen-makefiles/makefiles.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+Xen Makefiles
+=============
+
+Documentation for the build system of Xen, found in xen.git/xen/.
+
+Makefile files
+==============
+
+Description of the syntax that can be used in most Makefiles named
+'Makefile'. ('xen/Makefile' isn't part of the description.)
+
+'Makefile's are consumed by 'Rules.mk' when building.
+
+Goal definitions
+----------------
+
+	Goal definitions are the main part (heart) of the Makefile.
+	These lines define the files to be built, any special compilation
+	options, and any subdirectories to be entered recursively.
+
+	The most simple makefile contains one line:
+
+	Example::
+
+		obj-y += foo.o
+
+	This tells the build system that there is one object in that
+	directory, named foo.o. foo.o will be built from foo.c or foo.S.
+
+	The following pattern is often used to have object selected
+	depending on the configuration:
+
+	Example::
+
+		obj-$(CONFIG_FOO) += foo.o
+
+	$(CONFIG_FOO) can evaluates to y.
+	If CONFIG_FOO is not y, then the file will not be compiled nor linked.
+
+Descending down in directories
+------------------------------
+
+	A Makefile is only responsible for building objects in its own
+	directory. Files in subdirectories should be taken care of by
+	Makefiles in these subdirs. The build system will automatically
+	invoke make recursively in subdirectories, provided you let it know of
+	them.
+
+	To do so, obj-y is used.
+	acpi lives in a separate directory, and the Makefile present in
+	drivers/ tells the build system to descend down using the following
+	assignment.
+
+	Example::
+
+		#drivers/Makefile
+		obj-$(CONFIG_ACPI) += acpi/
+
+	If CONFIG_ACPI is set to 'y'
+	the corresponding obj- variable will be set, and the build system
+	will descend down in the apci directory.
+	The build system only uses this information to decide that it needs
+	to visit the directory, it is the Makefile in the subdirectory that
+	specifies what is modular and what is built-in.
+
+	It is good practice to use a `CONFIG_` variable when assigning directory
+	names. This allows the build system to totally skip the directory if the
+	corresponding `CONFIG_` option is 'y'.
+
+Compilation flags
+-----------------
+
+    CFLAGS-y and AFLAGS-y
+	These two flags apply only to the makefile in which they
+	are assigned. They are used for all the normal cc, as and ld
+	invocations happening during a recursive build.
+
+	$(CFLAGS-y) is necessary because the top Makefile owns the
+	variable $(XEN_CFLAGS) and uses it for compilation flags for the
+	entire tree. And the variable $(CFLAGS) is modified by Config.mk
+	which evaluated in every subdirs.
+
+	CFLAGS-y specifies options for compiling with $(CC).
+	AFLAGS-y specifies assembler options.
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 8e4b9e3a4a82..9d1e1ebf5e44 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -1,3 +1,7 @@
+#
+# See docs/misc/xen-makefiles/makefiles.rst on variables that can be used in
+# Makefile and are consumed by Rules.mk
+#
 
 -include $(BASEDIR)/include/config/auto.conf
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVo-0005Ur-S7; Tue, 21 Apr 2020 16:12:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVn-0005Tv-Gp
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:39 +0000
X-Inumbo-ID: e83f201d-83ea-11ea-9160-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e83f201d-83ea-11ea-9160-12813bfff9fa;
 Tue, 21 Apr 2020 16:12:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485553;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=F8hItL4OkCEv1+RcIrGO9a1Vw+sXS9Wwz/XS0OqQdLQ=;
 b=VP+WMdxMjJNQW1gEWwz2OE8lQFYmo7wwj1XXtxJKDaFwAxkqsy9aS+qu
 yeH4rV3TMrYtQTZiKhekl0hNRGRyl0M5kbp3OgiYUuchvCi0XZW1l0gG7
 3JzCY/yVmcOxnlKFz6q4vr/YyucRrJw/jxbQuLmOCkenmvEqQrjoctJuI E=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: +nqSIIVBZSSpkEP6Qd7q9x7x/7EgFhKIoText7+Xd0qpHQmqoSg0OMdsQCxHCWfb0jeUBPfrQv
 26zjn5qnYVkC2y0LdjM8x7CR9WloPfFgrln3c9ke6fivbAy5jAbqOeVUebADam6zrm0KVs74mX
 eiMt5Xbj06NBDy/JAge0lzkdP6LcIJu40W4/VRNcpkHH0EZ90XzBUZp5m7JhqYncmTXxi1nT3M
 MmxFjCgpxIrIMEzUIrfS4a4hSiVSmNJSVGb94WOPf+HbpF9cXPLhkMsFsw9T+Npuz9xC332+eo
 Qog=
X-SBRS: 2.7
X-MesageID: 16414414
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16414414"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 06/16] xen/build: introduce if_changed and
 if_changed_rule
Date: Tue, 21 Apr 2020 17:11:58 +0100
Message-ID: <20200421161208.2429539-7-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The if_changed macro from Linux, in addition to check if any files
needs an update, check if the command line has changed since the last
invocation. The latter will force a rebuild if any options to the
executable have changed.

if_changed_rule checks dependencies like if_changed, but execute
rule_$(1) instead of cmd_$(1) when a target needs to be rebuilt. A rule_
macro can call more than one cmd_ macro. One of the cmd_ macro in a
rule need to be call using a macro that record the command line, so
cmd_and_record is introduced. It is similar to cmd_and_fixup from
Linux but without a call to fixdep which we don't have yet. (We will
later replace cmd_and_record by cmd_and_fixup.)

Example of a rule_ macro:
define rule_cc_o_c
    $(call cmd_and_record,cc_o_o)
    $(call cmd,objcopy)
endef

This needs one of the call to use cmd_and_record, otherwise no .*.cmd
file will be created, and the target will keep been rebuilt.

In order for if_changed to works correctly, we need to load the .%.cmd
files that the macro generates, this is done by adding targets in to
the $(targets) variable. We use intermediate_targets to add %.init.o
dependency %.o to target since there aren't in obj-y.

We also add $(MAKECMDGOALS) to targets so that when running for
example `make common/memory.i`, make will load the associated .%.cmd
dependency file.

Beside the if_changed*, we import the machinery used for a "beautify
output". The important one is when running make with V=2 which help to
debug the makefiles by printing why a target is been rebuilt, via the
$(echo-why) macro.

if_changed and if_changed_rule aren't used yet.

Most of this code is copied from Linux v5.4, including the
documentation.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---

Notes:
    v5:
    - In documentation, fix some mix tab/space used for indentation,
      convert to all tab.
    - and fix a "note" in "if_changed" where the paragraph was cut in two.
    
    v4:
    - Use := in make whenever possible (instead of =)
    - insert new string in .gitignore somewhere more plausible.
    - import documentation from Linux

 .gitignore                            |   1 +
 docs/misc/xen-makefiles/makefiles.rst |  98 +++++++++++++++++++++++
 xen/Makefile                          |  53 ++++++++++++-
 xen/Rules.mk                          |  33 +++++++-
 xen/scripts/Kbuild.include            | 107 ++++++++++++++++++++++++++
 5 files changed, 290 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4ca679ddbc9a..bfa53723b38b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,5 @@
 .hg
+.*.cmd
 .*.tmp
 *.orig
 *~
diff --git a/docs/misc/xen-makefiles/makefiles.rst b/docs/misc/xen-makefiles/makefiles.rst
index a86e3a612d61..04bc72601c31 100644
--- a/docs/misc/xen-makefiles/makefiles.rst
+++ b/docs/misc/xen-makefiles/makefiles.rst
@@ -85,3 +85,101 @@ Compilation flags
 
 	CFLAGS-y specifies options for compiling with $(CC).
 	AFLAGS-y specifies assembler options.
+
+
+Build system infrastructure
+===========================
+
+This chapter describe some of the macro used when building Xen.
+
+Macros
+------
+
+
+    if_changed
+	if_changed is the infrastructure used for the following commands.
+
+	Usage::
+
+		target: source(s) FORCE
+			$(call if_changed,ld/objcopy/...)
+
+	When the rule is evaluated, it is checked to see if any files
+	need an update, or the command line has changed since the last
+	invocation. The latter will force a rebuild if any options
+	to the executable have changed.
+	Any target that utilises if_changed must be listed in $(targets),
+	otherwise the command line check will fail, and the target will
+	always be built.
+	if_changed may be used in conjunction with custom commands as
+	defined in "Custom commands".
+
+	Note: It is a typical mistake to forget the FORCE prerequisite.
+	Another common pitfall is that whitespace is sometimes
+	significant; for instance, the below will fail (note the extra space
+	after the comma)::
+
+		target: source(s) FORCE
+
+	**WRONG!**	$(call if_changed, ld/objcopy/...)
+
+	Note:
+		if_changed should not be used more than once per target.
+		It stores the executed command in a corresponding .cmd file
+		and multiple calls would result in overwrites and unwanted
+		results when the target is up to date and only the tests on
+		changed commands trigger execution of commands.
+
+    ld
+	Link target.
+
+	Example::
+
+		targets += setup setup.o bootsect bootsect.o
+		$(obj)/setup $(obj)/bootsect: %: %.o FORCE
+			$(call if_changed,ld)
+
+	$(targets) are assigned all potential targets, by which the build
+	system knows the targets and will:
+
+		1) check for commandline changes
+
+	The ": %: %.o" part of the prerequisite is a shorthand that
+	frees us from listing the setup.o and bootsect.o files.
+
+	Note:
+		It is a common mistake to forget the "targets :=" assignment,
+		resulting in the target file being recompiled for no
+		obvious reason.
+
+    objcopy
+	Copy binary. Uses OBJCOPYFLAGS usually specified in
+	arch/$(ARCH)/Makefile.
+
+Custom commands
+---------------
+
+	When the build system is executing with V=0, then only
+	a shorthand of a command is normally displayed.
+	To enable this behaviour for custom commands, two variables are
+	required to be set::
+
+		quiet_cmd_<command>	- what shall be echoed
+		      cmd_<command>	- the command to execute
+
+	Example::
+
+		# xsm/flask/Makefile
+		mkflask := policy/mkflask.sh
+		quiet_cmd_mkflask = MKFLASK $@
+		cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include \
+			$(FLASK_H_DEPEND)
+
+		include/flask.h: $(FLASK_H_DEPEND) $(mkflask) FORCE
+			$(call if_changed,mkflask)
+
+	When updating the include/flask.h target, the line:
+
+		MKFLASK include/flask.h
+
+	will be displayed with "make V=0". (V=0 is the default)
diff --git a/xen/Makefile b/xen/Makefile
index 2a689b26a2ba..07f8ef808743 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -52,7 +52,57 @@ dist: install
 
 ifneq ($(root-make-done),y)
 # section to run before calling Rules.mk, but only once.
+
+# Beautify output
+# ---------------------------------------------------------------------------
+#
+# Normally, we echo the whole command before executing it. By making
+# that echo $($(quiet)$(cmd)), we now have the possibility to set
+# $(quiet) to choose other forms of output instead, e.g.
+#
+#         quiet_cmd_cc_o_c = Compiling $(RELDIR)/$@
+#         cmd_cc_o_c       = $(CC) $(c_flags) -c -o $@ $<
+#
+# If $(quiet) is empty, the whole command will be printed.
+# If it is set to "quiet_", only the short version will be printed.
+# If it is set to "silent_", nothing will be printed at all, since
+# the variable $(silent_cmd_cc_o_c) doesn't exist.
+#
+# A simple variant is to prefix commands with $(Q) - that's useful
+# for commands that shall be hidden in non-verbose mode.
 #
+#	$(Q)ln $@ :<
+#
+# If KBUILD_VERBOSE equals 0 then the above command will be hidden.
+# If KBUILD_VERBOSE equals 1 then the above command is displayed.
+#
+# To put more focus on warnings, be less verbose as default
+# Use 'make V=1' to see the full commands
+
+ifeq ("$(origin V)", "command line")
+    KBUILD_VERBOSE := $(V)
+endif
+ifndef KBUILD_VERBOSE
+    KBUILD_VERBOSE := 0
+endif
+
+ifeq ($(KBUILD_VERBOSE),1)
+    quiet :=
+    Q :=
+else
+    quiet := quiet_
+    Q := @
+endif
+
+# If the user is running make -s (silent mode), suppress echoing of
+# commands
+
+ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),)
+    quiet := silent_
+endif
+
+export quiet Q KBUILD_VERBOSE
+
 # To make sure we do not include .config for any of the *config targets
 # catch them early, and hand them over to tools/kconfig/Makefile
 
@@ -261,7 +311,8 @@ _clean: delete-unfresh-files
 	$(MAKE) $(clean) arch/x86
 	$(MAKE) $(clean) test
 	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) clean
-	find . \( -name "*.o" -o -name ".*.d" -o -name ".*.d2" -o -name "*.gcno" \) -exec rm -f {} \;
+	find . \( -name "*.o" -o -name ".*.d" -o -name ".*.d2" \
+		-o -name "*.gcno" -o -name ".*.cmd" \) -exec rm -f {} \;
 	rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi $(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map *~ core
 	rm -f include/asm-*/asm-offsets.h
 	rm -f .banner
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 9d1e1ebf5e44..21cac7f5f51a 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -42,6 +42,7 @@ ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(CONFIG_CRYPTO)   += $(BASEDIR)/crypto/built_in.o
 
 # Initialise some variables
+targets :=
 CFLAGS-y :=
 AFLAGS-y :=
 
@@ -69,6 +70,10 @@ $(foreach o,$(filter-out %/,$(obj-y) $(obj-bin-y) $(extra-y)),$(eval $(call gend
 subdir-y := $(subdir-y) $(filter %/, $(obj-y))
 obj-y    := $(patsubst %/, %/built_in.o, $(obj-y))
 
+# $(subdir-obj-y) is the list of objects in $(obj-y) which uses dir/ to
+# tell kbuild to descend
+subdir-obj-y := $(filter %/built_in.o, $(obj-y))
+
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY
 
 ifeq ($(CONFIG_COVERAGE),y)
@@ -123,6 +128,10 @@ else
 endif
 endif
 
+targets += built_in.o
+targets += $(filter-out $(subdir-obj-y), $(obj-y)) $(extra-y)
+targets += $(MAKECMDGOALS)
+
 built_in_bin.o: $(obj-bin-y) $(extra-y)
 ifeq ($(obj-bin-y),)
 	$(CC) $(a_flags) -c -x assembler /dev/null -o $@
@@ -131,7 +140,7 @@ else
 endif
 
 # Force execution of pattern rules (for which PHONY cannot be directly used).
-.PHONY: FORCE
+PHONY += FORCE
 FORCE:
 
 %/built_in.o: FORCE
@@ -179,4 +188,26 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
 %.s: %.S Makefile
 	$(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
 
+# Add intermediate targets:
+# When building objects with specific suffix patterns, add intermediate
+# targets that the final targets are derived from.
+intermediate_targets = $(foreach sfx, $(2), \
+				$(patsubst %$(strip $(1)),%$(sfx), \
+					$(filter %$(strip $(1)), $(targets))))
+# %.init.o <- %.o
+targets += $(call intermediate_targets, .init.o, .o)
+
 -include $(DEPS_INCLUDE)
+
+# Read all saved command lines and dependencies for the $(targets) we
+# may be building above, using $(if_changed{,_dep}). As an
+# optimization, we don't need to read them if the target does not
+# exist, we will rebuild anyway in that case.
+
+existing-targets := $(wildcard $(sort $(targets)))
+
+-include $(foreach f,$(existing-targets),$(dir $(f)).$(notdir $(f)).cmd)
+
+# Declare the contents of the PHONY variable as phony.  We keep that
+# information in a variable so we can use it in if_changed and friends.
+.PHONY: $(PHONY)
diff --git a/xen/scripts/Kbuild.include b/xen/scripts/Kbuild.include
index 806c68824ed5..e62eddc3654c 100644
--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -2,11 +2,30 @@
 ####
 # kbuild: Generic definitions
 
+# Convenient variables
+squote  := '
+empty   :=
+space   := $(empty) $(empty)
+space_escape := _-_SPACE_-_
+pound   := \#
+
+###
+# Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o
+dot-target = $(@D)/.$(@F)
+
 ###
 # dependencies
 DEPS = .*.d
 DEPS_INCLUDE = $(addsuffix .d2, $(basename $(wildcard $(DEPS))))
 
+###
+# real prerequisites without phony targets
+real-prereqs = $(filter-out $(PHONY), $^)
+
+###
+# Escape single quote for use in echo statements
+escsq = $(subst $(squote),'\$(squote)',$1)
+
 # as-insn: Check whether assembler supports an instruction.
 # Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no)
 as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
@@ -32,3 +51,91 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || e
 # Usage:
 # $(MAKE) $(clean) dir
 clean := -f $(BASEDIR)/scripts/Makefile.clean clean -C
+
+# echo command.
+# Short version is used, if $(quiet) equals `quiet_', otherwise full one.
+echo-cmd = $(if $($(quiet)cmd_$(1)),\
+        echo '  $(call escsq,$($(quiet)cmd_$(1)))$(echo-why)';)
+
+# printing commands
+cmd = @set -e; $(echo-cmd) $(cmd_$(1))
+
+###
+# if_changed      - execute command if any prerequisite is newer than
+#                   target, or command line has changed
+# if_changed_rule - as if_changed but execute rule instead
+
+ifneq ($(KBUILD_NOCMDDEP),1)
+# Check if both commands are the same including their order. Result is empty
+# string if equal. User may override this check using make KBUILD_NOCMDDEP=1
+cmd-check = $(filter-out $(subst $(space),$(space_escape),$(strip $(cmd_$@))), \
+                         $(subst $(space),$(space_escape),$(strip $(cmd_$1))))
+else
+cmd-check = $(if $(strip $(cmd_$@)),,1)
+endif
+
+# Replace >$< with >$$< to preserve $ when reloading the .cmd file
+# (needed for make)
+# Replace >#< with >$(pound)< to avoid starting a comment in the .cmd file
+# (needed for make)
+# Replace >'< with >'\''< to be able to enclose the whole string in '...'
+# (needed for the shell)
+make-cmd = $(call escsq,$(subst $(pound),$$(pound),$(subst $$,$$$$,$(cmd_$(1)))))
+
+# Find any prerequisites that is newer than target or that does not exist.
+# PHONY targets skipped in both cases.
+any-prereq = $(filter-out $(PHONY),$?)$(filter-out $(PHONY) $(wildcard $^),$^)
+
+# Execute command if command has changed or prerequisite(s) are updated.
+if_changed = $(if $(any-prereq)$(cmd-check),                                 \
+        $(cmd);                                                              \
+        printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)
+
+# Usage: $(call if_changed_rule,foo)
+# Will check if $(cmd_foo) or any of the prerequisites changed,
+# and if so will execute $(rule_foo).
+if_changed_rule = $(if $(any-prereq)$(cmd-check),$(rule_$(1)),@:)
+
+cmd_and_record =                                                             \
+        $(cmd);                                                              \
+        printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd
+
+###
+# why - tell why a target got built
+#       enabled by make V=2
+#       Output (listed in the order they are checked):
+#          (1) - due to target is PHONY
+#          (2) - due to target missing
+#          (3) - due to: file1.h file2.h
+#          (4) - due to command line change
+#          (5) - due to missing .cmd file
+#          (6) - due to target not in $(targets)
+# (1) PHONY targets are always build
+# (2) No target, so we better build it
+# (3) Prerequisite is newer than target
+# (4) The command line stored in the file named dir/.target.cmd
+#     differed from actual command line. This happens when compiler
+#     options changes
+# (5) No dir/.target.cmd file (used to store command line)
+# (6) No dir/.target.cmd file and target not listed in $(targets)
+#     This is a good hint that there is a bug in the kbuild file
+ifeq ($(KBUILD_VERBOSE),2)
+why =                                                                        \
+    $(if $(filter $@, $(PHONY)),- due to target is PHONY,                    \
+        $(if $(wildcard $@),                                                 \
+            $(if $(any-prereq),- due to: $(any-prereq),                      \
+                $(if $(cmd-check),                                           \
+                    $(if $(cmd_$@),- due to command line change,             \
+                        $(if $(filter $@, $(targets)),                       \
+                            - due to missing .cmd file,                      \
+                            - due to $(notdir $@) not in $$(targets)         \
+                         )                                                   \
+                     )                                                       \
+                 )                                                           \
+             ),                                                              \
+             - due to target missing                                         \
+         )                                                                   \
+     )
+
+echo-why = $(call escsq, $(strip $(why)))
+endif
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVp-0005V7-6n; Tue, 21 Apr 2020 16:12:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVn-0005U4-QK
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:39 +0000
X-Inumbo-ID: e7f25782-83ea-11ea-b58d-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e7f25782-83ea-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 16:12:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485553;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=0hrNnTkGU1cVUEGCg9RIavqwWfviH43vEK4pXIptfW4=;
 b=PYV0Vnab5++zaB4t9ojPMEsGjKC4pW4M3cfEh4H+IV5p7IMG6rPxTEI/
 gFsPkioAtgPlRpJR0PklTfdKLTCTLS5kGL951BO4fwpNtwIj2fUmsc0Uz
 yRDv76taEQcnmL93oqG3HlbkbyYMyEQWqWXn4gOxlBmOhow9uP9OkvJm3 I=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: kHE+1wNsgjA+7laOt810J2tJ1Z5QpvodkY9ftGvjTzxu+oZkxYuAy1XdLXq4yigz+AJJoFWbjL
 5rT/JtQ8Sg3K5hqlqEeebWZcQXkWJliHkkEdgOX5eLbqSP7XJnX9RA5bpynIkFDX+6DQG+Lcmo
 kMnJ+iy5ynNboynI6DKo8sPJENgojaJqp2Xpc4zlGyxOM2m4v59x6GlXsoQSZGzNFfbe5cvi5Z
 ZFvdRnVGHJ7nQMXR3xPWf/A0AuBuwxTQizVl5yW/k9HLbKOEav9/pNK/xbcVqx53/3GKCkFtYL
 y3c=
X-SBRS: 2.7
X-MesageID: 16262940
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16262940"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 04/16] xen/build: have the root Makefile generates the
 CFLAGS
Date: Tue, 21 Apr 2020 17:11:56 +0100
Message-ID: <20200421161208.2429539-5-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Instead of generating the CFLAGS in Rules.mk everytime we enter a new
subdirectory, we are going to generate most of them a single time, and
export the result in the environment so that Rules.mk can use it.  The
only flags left to be generated are the ones that depend on the
targets, but the variable $(c_flags) takes care of that.

Arch specific CFLAGS are generated by a new file "arch/*/arch.mk"
which is included by the root Makefile.

We export the *FLAGS via the environment variables XEN_*FLAGS because
Rules.mk still includes Config.mk and would add duplicated flags to
CFLAGS.

When running Rules.mk in the root directory (xen/), the variable
`root-make-done' is set, so `need-config' will remain undef and so the
root Makefile will not generate the cflags again.

We can't use CFLAGS in subdirectories to add flags to particular
targets, instead start to use CFLAGS-y. Idem for AFLAGS.
So there are two different CFLAGS-y, the one in xen/Makefile (and
arch.mk), and the one in subdirs that Rules.mk is going to use.
We can't add to XEN_CFLAGS because it is exported, so making change to
it might be propagated to subdirectory which isn't intended.

Some style change are introduced in this patch:
    when LDFLAGS_DIRECT is included in LDFLAGS
    use of CFLAGS-$(CONFIG_INDIRECT_THUNK) instead of ifeq().

The LTO change hasn't been tested properly, as LTO is marked as
broken.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

Notes:
    v5:
    - typos
    - remove -flto from XEN_CFLAGS instead of calling lto broken and
      commenting out lto stuff.
    
    v4:
    - typos
    - Adding $(AFLAGS-y) to $(AFLAGS)
    
    v3:
    - squash "xen/build: introduce ccflags-y and CFLAGS_$@" here, with
      those changes:
        - rename ccflags-y to simply CFLAGS-y and start using AFLAGS-y in
          subdirs.
        - remove CFLAGS_$@, we don't need it yet.
        - fix build of xen.lds and efi.lds which needed -D to be a_flags
    - remove arch_ccflags, and modify c_flags directly
      with that change, reorder c_flags, so that target specific flags are last.
    - remove HAVE_AS_QUOTED_SYM from envvar and check XEN_CFLAGS to find if
      it's there when adding -D__OBJECT_LABEL__.
    - fix missing some flags in AFLAGS
      (like -fshort-wchar in xen/arch/x86/efi/Makefile,
       and -D__OBJECT_LABEL__ and CFLAGS-stack-boundary)
    - keep COV_FLAGS generation in Rules.mk since it doesn't invovle to
      call CC
    - fix clang test for "asm()-s support .include." (in a new patch done
      ahead)
    - include Kconfig.include in xen/Makefile because as-option-add is
      defined there now.

 xen/Makefile                       | 58 +++++++++++++++++++
 xen/Rules.mk                       | 73 ++++++------------------
 xen/arch/arm/Makefile              | 10 ++--
 xen/arch/arm/Rules.mk              | 23 --------
 xen/arch/arm/{Rules.mk => arch.mk} |  5 --
 xen/arch/arm/efi/Makefile          |  2 +-
 xen/arch/x86/Makefile              | 24 ++++----
 xen/arch/x86/Rules.mk              | 91 ++----------------------------
 xen/arch/x86/{Rules.mk => arch.mk} | 17 ++----
 xen/arch/x86/efi/Makefile          |  2 +-
 xen/common/libelf/Makefile         |  4 +-
 xen/common/libfdt/Makefile         |  4 +-
 xen/include/Makefile               |  2 +-
 xen/xsm/flask/Makefile             |  2 +-
 xen/xsm/flask/ss/Makefile          |  2 +-
 15 files changed, 114 insertions(+), 205 deletions(-)
 copy xen/arch/arm/{Rules.mk => arch.mk} (85%)
 copy xen/arch/x86/{Rules.mk => arch.mk} (87%)

diff --git a/xen/Makefile b/xen/Makefile
index 643c689658f3..2a689b26a2ba 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -118,6 +118,64 @@ $(KCONFIG_CONFIG):
 include/config/%.conf include/config/%.conf.cmd: $(KCONFIG_CONFIG)
 	$(MAKE) $(kconfig) syncconfig
 
+ifeq ($(CONFIG_DEBUG),y)
+CFLAGS += -O1
+else
+CFLAGS += -O2
+endif
+
+ifeq ($(CONFIG_FRAME_POINTER),y)
+CFLAGS += -fno-omit-frame-pointer
+else
+CFLAGS += -fomit-frame-pointer
+endif
+
+CFLAGS += -nostdinc -fno-builtin -fno-common
+CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
+$(call cc-option-add,CFLAGS,CC,-Wvla)
+CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
+CFLAGS-$(CONFIG_DEBUG_INFO) += -g
+
+ifneq ($(CONFIG_CC_IS_CLANG),y)
+# Clang doesn't understand this command line argument, and doesn't appear to
+# have a suitable alternative.  The resulting compiled binary does function,
+# but has an excessively large symbol table.
+CFLAGS += -Wa,--strip-local-absolute
+endif
+
+AFLAGS += -D__ASSEMBLY__
+
+CFLAGS += $(CFLAGS-y)
+# allow extra CFLAGS externally via EXTRA_CFLAGS_XEN_CORE
+CFLAGS += $(EXTRA_CFLAGS_XEN_CORE)
+
+# Most CFLAGS are safe for assembly files:
+#  -std=gnu{89,99} gets confused by #-prefixed end-of-line comments
+#  -flto makes no sense and annoys clang
+AFLAGS += $(filter-out -std=gnu% -flto,$(CFLAGS)) $(AFLAGS-y)
+
+# LDFLAGS are only passed directly to $(LD)
+LDFLAGS += $(LDFLAGS_DIRECT) $(LDFLAGS-y)
+
+ifeq ($(CONFIG_UBSAN),y)
+CFLAGS_UBSAN := -fsanitize=undefined
+else
+CFLAGS_UBSAN :=
+endif
+
+ifeq ($(CONFIG_LTO),y)
+CFLAGS += -flto
+LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
+endif
+
+include $(BASEDIR)/arch/$(TARGET_ARCH)/arch.mk
+
+# define new variables to avoid the ones defined in Config.mk
+export XEN_CFLAGS := $(CFLAGS)
+export XEN_AFLAGS := $(AFLAGS)
+export XEN_LDFLAGS := $(LDFLAGS)
+export CFLAGS_UBSAN
+
 endif # need-config
 
 .PHONY: build install uninstall clean distclean MAP
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3408a35dbf53..8e4b9e3a4a82 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -38,59 +38,17 @@ ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(CONFIG_CRYPTO)   += $(BASEDIR)/crypto/built_in.o
 
 # Initialise some variables
-CFLAGS_UBSAN :=
-
-ifeq ($(CONFIG_DEBUG),y)
-CFLAGS += -O1
-else
-CFLAGS += -O2
-endif
-
-ifeq ($(CONFIG_FRAME_POINTER),y)
-CFLAGS += -fno-omit-frame-pointer
-else
-CFLAGS += -fomit-frame-pointer
-endif
-
-CFLAGS += -nostdinc -fno-builtin -fno-common
-CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
-$(call cc-option-add,CFLAGS,CC,-Wvla)
-CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
-CFLAGS-$(CONFIG_DEBUG_INFO) += -g
-
-ifneq ($(CONFIG_CC_IS_CLANG),y)
-# Clang doesn't understand this command line argument, and doesn't appear to
-# have an suitable alternative.  The resulting compiled binary does function,
-# but has an excessively large symbol table.
-CFLAGS += -Wa,--strip-local-absolute
-endif
-
-AFLAGS += -D__ASSEMBLY__
+CFLAGS-y :=
+AFLAGS-y :=
 
 ALL_OBJS := $(ALL_OBJS-y)
 
-CFLAGS += $(CFLAGS-y)
-# allow extra CFLAGS externally via EXTRA_CFLAGS_XEN_CORE
-CFLAGS += $(EXTRA_CFLAGS_XEN_CORE)
-
-# Most CFLAGS are safe for assembly files:
-#  -std=gnu{89,99} gets confused by #-prefixed end-of-line comments
-#  -flto makes no sense and annoys clang
-AFLAGS += $(filter-out -std=gnu% -flto,$(CFLAGS))
-
-# LDFLAGS are only passed directly to $(LD)
-LDFLAGS += $(LDFLAGS_DIRECT)
-
-LDFLAGS += $(LDFLAGS-y)
-
 SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
                                             $(foreach w,1 2 4, \
                                                         rodata.str$(w).$(a)) \
                                             rodata.cst$(a)) \
                          $(foreach r,rel rel.ro,data.$(r).local)
 
-include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
-
 include Makefile
 
 define gendep
@@ -107,7 +65,7 @@ $(foreach o,$(filter-out %/,$(obj-y) $(obj-bin-y) $(extra-y)),$(eval $(call gend
 subdir-y := $(subdir-y) $(filter %/, $(obj-y))
 obj-y    := $(patsubst %/, %/built_in.o, $(obj-y))
 
-$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += -DINIT_SECTIONS_ONLY
+$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY
 
 ifeq ($(CONFIG_COVERAGE),y)
 ifeq ($(CONFIG_CC_IS_CLANG),y)
@@ -115,19 +73,16 @@ ifeq ($(CONFIG_CC_IS_CLANG),y)
 else
     COV_FLAGS := -fprofile-arcs -ftest-coverage
 endif
-$(filter-out %.init.o $(nocov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += $(COV_FLAGS)
+$(filter-out %.init.o $(nocov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += $(COV_FLAGS)
 endif
 
 ifeq ($(CONFIG_UBSAN),y)
-CFLAGS_UBSAN += -fsanitize=undefined
 # Any -fno-sanitize= options need to come after any -fsanitize= options
 $(filter-out %.init.o $(noubsan-y),$(obj-y) $(obj-bin-y) $(extra-y)): \
-CFLAGS += $(filter-out -fno-%,$(CFLAGS_UBSAN)) $(filter -fno-%,$(CFLAGS_UBSAN))
+CFLAGS-y += $(filter-out -fno-%,$(CFLAGS_UBSAN)) $(filter -fno-%,$(CFLAGS_UBSAN))
 endif
 
 ifeq ($(CONFIG_LTO),y)
-CFLAGS += -flto
-LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
 # Mirror the directory tree, collecting them as built_in_bin.o.
@@ -140,10 +95,18 @@ obj-bin-y :=
 endif
 
 # Always build obj-bin files as binary even if they come from C source. 
-$(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
+$(obj-bin-y): XEN_CFLAGS := $(filter-out -flto,$(XEN_CFLAGS))
+
+# Calculation of flags, first the generic flags, then the arch specific flags,
+# and last the flags modified for a target or a directory.
+
+c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_CFLAGS) '-D__OBJECT_FILE__="$@"'
+a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_AFLAGS)
+
+include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
 
-c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(CFLAGS) '-D__OBJECT_FILE__="$@"'
-a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(AFLAGS)
+c_flags += $(CFLAGS-y)
+a_flags += $(CFLAGS-y) $(AFLAGS-y)
 
 built_in.o: $(obj-y) $(extra-y)
 ifeq ($(obj-y),)
@@ -152,7 +115,7 @@ else
 ifeq ($(CONFIG_LTO),y)
 	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
 else
-	$(LD) $(LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
 endif
 endif
 
@@ -160,7 +123,7 @@ built_in_bin.o: $(obj-bin-y) $(extra-y)
 ifeq ($(obj-bin-y),)
 	$(CC) $(a_flags) -c -x assembler /dev/null -o $@
 else
-	$(LD) $(LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
 endif
 
 # Force execution of pattern rules (for which PHONY cannot be directly used).
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 913f6cdeed3f..9f1ab2335756 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -95,24 +95,24 @@ prelink_lto.o: $(ALL_OBJS)
 
 # Link it with all the binary objects
 prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
-	$(LD) $(LDFLAGS) -r -o $@ $^
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
 else
 prelink.o: $(ALL_OBJS)
-	$(LD) $(LDFLAGS) -r -o $@ $^
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
 endif
 
 $(TARGET)-syms: prelink.o xen.lds
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	$(LD) $(XEN_LDFLAGS) -T xen.lds -N prelink.o \
 	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
 	$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
 		| $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort >$(@D)/.$(@F).0.S
 	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	$(LD) $(XEN_LDFLAGS) -T xen.lds -N prelink.o \
 	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
 	$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
 		| $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort >$(@D)/.$(@F).1.S
 	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
+	$(LD) $(XEN_LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
 	    $(@D)/.$(@F).1.o -o $@
 	$(NM) -pa --format=sysv $(@D)/$(@F) \
 		| $(BASEDIR)/tools/symbols --xensyms --sysv --sort \
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 3ad284aa71a4..e69de29bb2d1 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -1,23 +0,0 @@
-########################################
-# arm-specific definitions
-
-#
-# If you change any of these configuration options then you must
-# 'make clean' before rebuilding.
-#
-
-CFLAGS += -I$(BASEDIR)/include
-
-$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
-$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
-
-# Prevent floating-point variables from creeping into Xen.
-CFLAGS-$(CONFIG_ARM_32) += -msoft-float
-CFLAGS-$(CONFIG_ARM_32) += -mcpu=cortex-a15
-
-CFLAGS-$(CONFIG_ARM_64) += -mcpu=generic
-CFLAGS-$(CONFIG_ARM_64) += -mgeneral-regs-only # No fp registers etc
-
-ifneq ($(filter command line environment,$(origin CONFIG_EARLY_PRINTK)),)
-    $(error You must use 'make menuconfig' to enable/disable early printk now)
-endif
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/arch.mk
similarity index 85%
copy from xen/arch/arm/Rules.mk
copy to xen/arch/arm/arch.mk
index 3ad284aa71a4..c8186f58288d 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/arch.mk
@@ -1,11 +1,6 @@
 ########################################
 # arm-specific definitions
 
-#
-# If you change any of these configuration options then you must
-# 'make clean' before rebuilding.
-#
-
 CFLAGS += -I$(BASEDIR)/include
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
diff --git a/xen/arch/arm/efi/Makefile b/xen/arch/arm/efi/Makefile
index d34c9168914a..e3ff2c3f283c 100644
--- a/xen/arch/arm/efi/Makefile
+++ b/xen/arch/arm/efi/Makefile
@@ -1,4 +1,4 @@
-CFLAGS += -fshort-wchar
+CFLAGS-y += -fshort-wchar
 
 obj-y +=  boot.init.o runtime.o
 obj-$(CONFIG_ACPI) +=  efi-dom0.init.o
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 1405525105d9..a805e9982e85 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -121,32 +121,32 @@ prelink-efi_lto.o: $(ALL_OBJS) efi/runtime.o efi/compat.o
 
 # Link it with all the binary objects
 prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
-	$(LD) $(LDFLAGS) -r -o $@ $^
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
 
 prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink-efi_lto.o efi/boot.init.o
-	$(LD) $(LDFLAGS) -r -o $@ $^
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
 else
 prelink.o: $(ALL_OBJS)
-	$(LD) $(LDFLAGS) -r -o $@ $^
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
 
 prelink-efi.o: $(ALL_OBJS) efi/boot.init.o efi/runtime.o efi/compat.o
-	$(LD) $(LDFLAGS) -r -o $@ $(filter-out %/efi/built_in.o,$^)
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out %/efi/built_in.o,$^)
 endif
 
 $(TARGET)-syms: prelink.o xen.lds
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
+	$(LD) $(XEN_LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
 	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
 	$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
 		| $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort \
 		>$(@D)/.$(@F).0.S
 	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
+	$(LD) $(XEN_LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
 	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
 	$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
 		| $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort $(syms-warn-dup-y) \
 		>$(@D)/.$(@F).1.S
 	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
+	$(LD) $(XEN_LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
 	    $(@D)/.$(@F).1.o -o $@
 	$(NM) -pa --format=sysv $(@D)/$(@F) \
 		| $(BASEDIR)/tools/symbols --xensyms --sysv --sort \
@@ -159,7 +159,7 @@ note.o: $(TARGET)-syms
 		--rename-section=.data=.note.gnu.build-id -S $@.bin $@
 	rm -f $@.bin
 
-EFI_LDFLAGS = $(patsubst -m%,-mi386pep,$(LDFLAGS)) --subsystem=10
+EFI_LDFLAGS = $(patsubst -m%,-mi386pep,$(XEN_LDFLAGS)) --subsystem=10
 EFI_LDFLAGS += --image-base=$(1) --stack=0,0 --heap=0,0 --strip-debug
 EFI_LDFLAGS += --section-alignment=0x200000 --file-alignment=0x20
 EFI_LDFLAGS += --major-image-version=$(XEN_VERSION)
@@ -168,7 +168,7 @@ EFI_LDFLAGS += --major-os-version=2 --minor-os-version=0
 EFI_LDFLAGS += --major-subsystem-version=2 --minor-subsystem-version=0
 
 # Check if the compiler supports the MS ABI.
-export XEN_BUILD_EFI := $(shell $(CC) $(CFLAGS) -c efi/check.c -o efi/check.o 2>/dev/null && echo y)
+export XEN_BUILD_EFI := $(shell $(CC) $(XEN_CFLAGS) -c efi/check.c -o efi/check.o 2>/dev/null && echo y)
 # Check if the linker supports PE.
 XEN_BUILD_PE := $(if $(XEN_BUILD_EFI),$(shell $(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o 2>/dev/null && echo y))
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
@@ -178,7 +178,7 @@ $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A ALT_
 
 ifneq ($(build_id_linker),)
 ifeq ($(call ld-ver-build-id,$(LD) $(filter -m%,$(EFI_LDFLAGS))),y)
-CFLAGS += -DBUILD_ID_EFI
+CFLAGS-y += -DBUILD_ID_EFI
 EFI_LDFLAGS += $(build_id_linker)
 note_file := efi/buildid.o
 # NB: this must be the last input in the linker call, because inputs following
@@ -225,7 +225,7 @@ efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o efi/relocs-dummy.o: ;
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c $(BASEDIR)/include/asm-x86/asm-macros.h
 	$(CC) $(filter-out -Wa$(comma)% -flto,$(c_flags)) -S -o $@ $<
 
-asm-macros.i: CFLAGS += -D__ASSEMBLY__ -P
+asm-macros.i: CFLAGS-y += -D__ASSEMBLY__ -P
 
 $(BASEDIR)/include/asm-x86/asm-macros.h: asm-macros.i Makefile
 	echo '#if 0' >$@.new
@@ -238,7 +238,7 @@ $(BASEDIR)/include/asm-x86/asm-macros.h: asm-macros.i Makefile
 	echo '#endif' >>$@.new
 	$(call move-if-changed,$@.new,$@)
 
-efi.lds: AFLAGS += -DEFI
+efi.lds: AFLAGS-y += -DEFI
 xen.lds efi.lds: xen.lds.S
 	$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<
 	sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 4b7ab784670c..56fe22c979ea 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,89 +1,10 @@
 ########################################
 # x86-specific definitions
 
-XEN_IMG_OFFSET := 0x200000
-
-CFLAGS += -I$(BASEDIR)/include
-CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
-CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
-CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
-CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst $(BASEDIR)/,,$(CURDIR))/$@))'
-
-# Prevent floating-point variables from creeping into Xen.
-CFLAGS += -msoft-float
-
-ifeq ($(CONFIG_CC_IS_CLANG),y)
-# Note: Any test which adds -no-integrated-as will cause subsequent tests to
-# succeed, and not trigger further additions.
-#
-# The tests to select whether the integrated assembler is usable need to happen
-# before testing any assembler features, or else the result of the tests would
-# be stale if the integrated assembler is not used.
-
-# Older clang's built-in assembler doesn't understand .skip with labels:
-# https://bugs.llvm.org/show_bug.cgi?id=27369
-$(call as-option-add,CFLAGS,CC,".L0: .L1: .skip (.L1 - .L0)",,\
-                     -no-integrated-as)
-
-# Check whether clang asm()-s support .include.
-$(call as-option-add,CFLAGS,CC,".include \"asm-x86/indirect_thunk_asm.h\"",,\
-                     -no-integrated-as)
-
-# Check whether clang keeps .macro-s between asm()-s:
-# https://bugs.llvm.org/show_bug.cgi?id=36110
-$(call as-option-add,CFLAGS,CC,\
-                     ".macro FOO;.endm"$$(close); asm volatile $$(open)".macro FOO;.endm",\
-                     -no-integrated-as)
-endif
-
-$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
-$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
-$(call as-option-add,CFLAGS,CC,"vmcall",-DHAVE_AS_VMX)
-$(call as-option-add,CFLAGS,CC,"crc32 %eax$$(comma)%eax",-DHAVE_AS_SSE4_2)
-$(call as-option-add,CFLAGS,CC,"invept (%rax)$$(comma)%rax",-DHAVE_AS_EPT)
-$(call as-option-add,CFLAGS,CC,"rdrand %eax",-DHAVE_AS_RDRAND)
-$(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE)
-$(call as-option-add,CFLAGS,CC,"xsaveopt (%rax)",-DHAVE_AS_XSAVEOPT)
-$(call as-option-add,CFLAGS,CC,"rdseed %eax",-DHAVE_AS_RDSEED)
-$(call as-option-add,CFLAGS,CC,"clwb (%rax)",-DHAVE_AS_CLWB)
-$(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
-                     -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM \
-                     '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
-$(call as-option-add,CFLAGS,CC,"invpcid (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
-
-# GAS's idea of true is -1.  Clang's idea is 1
-$(call as-option-add,CFLAGS,CC,\
-    ".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE)
-
-# Check to see whether the assmbler supports the .nop directive.
-$(call as-option-add,CFLAGS,CC,\
-    ".L1: .L2: .nops (.L2 - .L1)$$(comma)9",-DHAVE_AS_NOPS_DIRECTIVE)
-
-CFLAGS += -mno-red-zone -fpic -fno-asynchronous-unwind-tables
-
-# Xen doesn't use SSE interally.  If the compiler supports it, also skip the
-# SSE setup for variadic function calls.
-CFLAGS += -mno-sse $(call cc-option,$(CC),-mskip-rax-setup)
-
-# Compile with thunk-extern, indirect-branch-register if avaiable.
-ifeq ($(CONFIG_INDIRECT_THUNK),y)
-CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register
-CFLAGS += -fno-jump-tables
+ifneq ($(filter -DHAVE_AS_QUOTED_SYM,$(XEN_CFLAGS)),)
+object_label_flags = '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$@'
+else
+object_label_flags = '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst $(BASEDIR)/,,$(CURDIR))/$@))'
 endif
-
-# If supported by the compiler, reduce stack alignment to 8 bytes. But allow
-# this to be overridden elsewhere.
-$(call cc-option-add,CFLAGS-stack-boundary,CC,-mpreferred-stack-boundary=3)
-CFLAGS += $(CFLAGS-stack-boundary)
-
-ifeq ($(CONFIG_UBSAN),y)
-# Don't enable alignment sanitisation.  x86 has efficient unaligned accesses,
-# and various things (ACPI tables, hypercall pages, stubs, etc) are wont-fix.
-# It also causes an as-yet-unidentified crash on native boot before the
-# console starts.
-$(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
-endif
-
-# Set up the assembler include path properly for older toolchains.
-CFLAGS += -Wa,-I$(BASEDIR)/include
-
+c_flags += $(object_label_flags) $(CFLAGS-stack-boundary)
+a_flags += $(object_label_flags) $(CFLAGS-stack-boundary)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/arch.mk
similarity index 87%
copy from xen/arch/x86/Rules.mk
copy to xen/arch/x86/arch.mk
index 4b7ab784670c..2a51553edb3c 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/arch.mk
@@ -1,13 +1,12 @@
 ########################################
 # x86-specific definitions
 
-XEN_IMG_OFFSET := 0x200000
+export XEN_IMG_OFFSET := 0x200000
 
 CFLAGS += -I$(BASEDIR)/include
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
 CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
-CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst $(BASEDIR)/,,$(CURDIR))/$@))'
 
 # Prevent floating-point variables from creeping into Xen.
 CFLAGS += -msoft-float
@@ -46,9 +45,7 @@ $(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE)
 $(call as-option-add,CFLAGS,CC,"xsaveopt (%rax)",-DHAVE_AS_XSAVEOPT)
 $(call as-option-add,CFLAGS,CC,"rdseed %eax",-DHAVE_AS_RDSEED)
 $(call as-option-add,CFLAGS,CC,"clwb (%rax)",-DHAVE_AS_CLWB)
-$(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
-                     -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM \
-                     '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
+$(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1",-DHAVE_AS_QUOTED_SYM)
 $(call as-option-add,CFLAGS,CC,"invpcid (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
 
 # GAS's idea of true is -1.  Clang's idea is 1
@@ -66,15 +63,14 @@ CFLAGS += -mno-red-zone -fpic -fno-asynchronous-unwind-tables
 CFLAGS += -mno-sse $(call cc-option,$(CC),-mskip-rax-setup)
 
 # Compile with thunk-extern, indirect-branch-register if avaiable.
-ifeq ($(CONFIG_INDIRECT_THUNK),y)
-CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register
-CFLAGS += -fno-jump-tables
-endif
+CFLAGS-$(CONFIG_INDIRECT_THUNK) += -mindirect-branch=thunk-extern
+CFLAGS-$(CONFIG_INDIRECT_THUNK) += -mindirect-branch-register
+CFLAGS-$(CONFIG_INDIRECT_THUNK) += -fno-jump-tables
 
 # If supported by the compiler, reduce stack alignment to 8 bytes. But allow
 # this to be overridden elsewhere.
 $(call cc-option-add,CFLAGS-stack-boundary,CC,-mpreferred-stack-boundary=3)
-CFLAGS += $(CFLAGS-stack-boundary)
+export CFLAGS-stack-boundary
 
 ifeq ($(CONFIG_UBSAN),y)
 # Don't enable alignment sanitisation.  x86 has efficient unaligned accesses,
@@ -86,4 +82,3 @@ endif
 
 # Set up the assembler include path properly for older toolchains.
 CFLAGS += -Wa,-I$(BASEDIR)/include
-
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 4bc0a196e9ca..490d791aae2d 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,4 +1,4 @@
-CFLAGS += -fshort-wchar
+CFLAGS-y += -fshort-wchar
 
 %.o: %.ihex
 	$(OBJCOPY) -I ihex -O binary $< $@
diff --git a/xen/common/libelf/Makefile b/xen/common/libelf/Makefile
index 3d9e38f27e65..464c448d9d37 100644
--- a/xen/common/libelf/Makefile
+++ b/xen/common/libelf/Makefile
@@ -3,10 +3,10 @@ nocov-y += libelf.o
 
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
 
-CFLAGS += -Wno-pointer-sign
+CFLAGS-y += -Wno-pointer-sign
 
 libelf.o: libelf-temp.o Makefile
 	$(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
 
 libelf-temp.o: libelf-tools.o libelf-loader.o libelf-dominfo.o #libelf-relocate.o
-	$(LD) $(LDFLAGS) -r -o $@ $^
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index c075bbf5462a..e2a5e59380a0 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -5,10 +5,10 @@ SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
 obj-y += libfdt.o
 nocov-y += libfdt.o
 
-CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
+CFLAGS-y += -I$(BASEDIR)/include/xen/libfdt/
 
 libfdt.o: libfdt-temp.o Makefile
 	$(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
 
 libfdt-temp.o: $(LIBFDT_OBJS)
-	$(LD) $(LDFLAGS) -r -o $@ $^
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
diff --git a/xen/include/Makefile b/xen/include/Makefile
index a488a98d8bb7..2a10725d689b 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -64,7 +64,7 @@ compat/%.h: compat/%.i Makefile $(BASEDIR)/tools/compat-build-header.py
 	mv -f $@.new $@
 
 compat/%.i: compat/%.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)% -include %/include/xen/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $<
+	$(CPP) $(filter-out -Wa$(comma)% -include %/include/xen/config.h,$(XEN_CFLAGS)) $(cppflags-y) -o $@ $<
 
 compat/%.c: public/%.h xlat.lst Makefile $(BASEDIR)/tools/compat-build-source.py
 	mkdir -p $(@D)
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index f001bb18d4ed..6db396347b1f 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -4,7 +4,7 @@ obj-y += flask_op.o
 
 obj-y += ss/
 
-CFLAGS += -I./include
+CFLAGS-y += -I./include
 
 AWK = awk
 
diff --git a/xen/xsm/flask/ss/Makefile b/xen/xsm/flask/ss/Makefile
index 046ce8f53326..d32b9e07138e 100644
--- a/xen/xsm/flask/ss/Makefile
+++ b/xen/xsm/flask/ss/Makefile
@@ -8,4 +8,4 @@ obj-y += services.o
 obj-y += conditional.o
 obj-y += mls.o
 
-CFLAGS += -I../include
+CFLAGS-y += -I../include
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVt-0005Zf-TR; Tue, 21 Apr 2020 16:12:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVs-0005YK-Gl
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:44 +0000
X-Inumbo-ID: ea4d0d60-83ea-11ea-9160-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ea4d0d60-83ea-11ea-9160-12813bfff9fa;
 Tue, 21 Apr 2020 16:12:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485556;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=IcWJ0C78z4awOosEvnLnoGUS16QfXFVHleO3sXQ7AYw=;
 b=BFs+G6LjlNlkHb0KgtWDVbIDiu0TzqpwGK5X/0EWodQx9a/2aLe8rS1r
 /gv1nYMPn9droDlNxYg6dH0pzImHOL6RbOGtNbGeKzxtXTmNyKaOWPK4r
 cO4nl7kGxc40M8usRqimyCdtAJVhPAnhDZnVSZcmkd5m3m+xEzjGqnx4P I=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: f/O9gcAXfrvfhD1I2LQQwBHJh+GjMWaJbVdq1ODda8g/jQty3UaSbP+N1tD7dvwzR4gg240XoU
 em8EtILsb1wpph+7wRBlY6SganCnbIATvhpwWHexQPmkjSP7+NwuoIFs3t4YIjk9sV3s3N+XFb
 caf88OoM4EzDtY+vsCA4HCD7PAetUSS8dqNI4/GGK1TcJHFHFFu9jCKlpv9SLmOPf97g4Rfnjf
 XknrTO89IH9Hp54hLNSdzrwYPWBo2iwQEh8KFmd56lkOvZ6lQTxkY34B8rgwwhnZ9V0b/YazXL
 K2Y=
X-SBRS: 2.7
X-MesageID: 16414428
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16414428"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 07/16] xen/build: Start using if_changed
Date: Tue, 21 Apr 2020 17:11:59 +0100
Message-ID: <20200421161208.2429539-8-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This patch start to use if_changed introduced in a previous commit.

Whenever if_changed is called, the target must have FORCE as
dependency so that if_changed can check if the command line to be
run has changed, so the macro $(real-prereqs) must be used to
discover the dependencies without "FORCE".

Whenever a target isn't in obj-y, it should be added to extra-y so the
.*.cmd dependency file associated with the target can be loaded. This
is done for xsm/flask/ and both common/lib{elf,fdt}/ and
arch/x86/Makefile.

For the targets that generate .*.d dependency files, there's going to
be two dependency files (.*.d and .*.cmd) until we can merge them
together in a later patch via fixdep from Linux.

One cleanup, libelf-relocate.o doesn't exist anymore.

We import cmd_ld and cmd_objcopy from Linux v5.4.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---

Notes:
    v4:
    - typos
    - fix missing FORCE in libfdt/Makefile
    - typo flask vs flash in xsm
    - in xsm, use *_H_DEPEND in command lines of mkaccess and mkflask
      instead of $(real-prereq) to avoid including the script as argument of
      itself.

 xen/Rules.mk               | 68 +++++++++++++++++++++++++++-----------
 xen/arch/arm/Makefile      |  4 +--
 xen/arch/x86/Makefile      |  1 +
 xen/arch/x86/efi/Makefile  |  7 ++--
 xen/common/libelf/Makefile | 12 ++++---
 xen/common/libfdt/Makefile | 11 +++---
 xen/xsm/flask/Makefile     | 17 +++++++---
 7 files changed, 85 insertions(+), 35 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 21cac7f5f51a..2e28c572305a 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,18 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
 
 include Makefile
 
+# Linking
+# ---------------------------------------------------------------------------
+
+quiet_cmd_ld = LD      $@
+cmd_ld = $(LD) $(XEN_LDFLAGS) -r -o $@ $(real-prereqs)
+
+# Objcopy
+# ---------------------------------------------------------------------------
+
+quiet_cmd_objcopy = OBJCOPY $@
+cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $< $@
+
 define gendep
     ifneq ($(1),$(subst /,:,$(1)))
         DEPS += $(dir $(1)).$(notdir $(1)).d
@@ -164,29 +176,47 @@ else
 	$(CC) $(c_flags) -c $< -o $@
 endif
 
-%.o: %.S Makefile
-	$(CC) $(a_flags) -c $< -o $@
+quiet_cmd_cc_o_S = CC      $@
+cmd_cc_o_S = $(CC) $(a_flags) -c $< -o $@
+
+%.o: %.S FORCE
+	$(call if_changed,cc_o_S)
+
+
+quiet_cmd_obj_init_o = INIT_O  $@
+define cmd_obj_init_o
+    $(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name sz rest; do \
+        case "$$name" in \
+        .*.local) ;; \
+        .text|.text.*|.data|.data.*|.bss) \
+            test $$sz != 0 || continue; \
+            echo "Error: size of $<:$$name is 0x$$sz" >&2; \
+            exit $$(expr $$idx + 1);; \
+        esac; \
+    done; \
+    $(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
+endef
+
+$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o FORCE
+	$(call if_changed,obj_init_o)
+
+quiet_cmd_cpp_i_c = CPP     $@
+cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
+
+quiet_cmd_cc_s_c = CC      $@
+cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
 
-$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
-	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name sz rest; do \
-		case "$$name" in \
-		.*.local) ;; \
-		.text|.text.*|.data|.data.*|.bss) \
-			test $$sz != 0 || continue; \
-			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
-			exit $$(expr $$idx + 1);; \
-		esac; \
-	done
-	$(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
+quiet_cmd_s_S = CPP     $@
+cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
 
-%.i: %.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
+%.i: %.c FORCE
+	$(call if_changed,cpp_i_c)
 
-%.s: %.c Makefile
-	$(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
+%.s: %.c FORCE
+	$(call if_changed,cc_s_c)
 
-%.s: %.S Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
+%.s: %.S FORCE
+	$(call if_changed,cpp_s_S)
 
 # Add intermediate targets:
 # When building objects with specific suffix patterns, add intermediate
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9f1ab2335756..b79ad55646bd 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -97,8 +97,8 @@ prelink_lto.o: $(ALL_OBJS)
 prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
 	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
 else
-prelink.o: $(ALL_OBJS)
-	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
+prelink.o: $(ALL_OBJS) FORCE
+	$(call if_changed,ld)
 endif
 
 $(TARGET)-syms: prelink.o xen.lds
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index a805e9982e85..44137d919b66 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_TBOOT) += tboot.o
 obj-y += hpet.o
 obj-y += vm_event.o
 obj-y += xstate.o
+extra-y += asm-macros.i
 
 x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
 
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 490d791aae2d..3e4c395b7535 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,7 +1,10 @@
 CFLAGS-y += -fshort-wchar
 
-%.o: %.ihex
-	$(OBJCOPY) -I ihex -O binary $< $@
+quiet_cmd_objcopy_o_ihex = OBJCOPY $@
+cmd_objcopy_o_ihex = $(OBJCOPY) -I ihex -O binary $< $@
+
+%.o: %.ihex FORCE
+	$(call if_changed,objcopy_o_ihex)
 
 boot.init.o: buildid.o
 
diff --git a/xen/common/libelf/Makefile b/xen/common/libelf/Makefile
index 464c448d9d37..a92326c982e9 100644
--- a/xen/common/libelf/Makefile
+++ b/xen/common/libelf/Makefile
@@ -1,12 +1,16 @@
 obj-bin-y := libelf.o
 nocov-y += libelf.o
+libelf-objs := libelf-tools.o libelf-loader.o libelf-dominfo.o
 
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
+OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
 
 CFLAGS-y += -Wno-pointer-sign
 
-libelf.o: libelf-temp.o Makefile
-	$(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
+libelf.o: libelf-temp.o FORCE
+	$(call if_changed,objcopy)
 
-libelf-temp.o: libelf-tools.o libelf-loader.o libelf-dominfo.o #libelf-relocate.o
-	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
+libelf-temp.o: $(libelf-objs) FORCE
+	$(call if_changed,ld)
+
+extra-y += libelf-temp.o $(libelf-objs)
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index e2a5e59380a0..6bd207cf8ffa 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -1,14 +1,17 @@
 include Makefile.libfdt
 
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
+OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
 
 obj-y += libfdt.o
 nocov-y += libfdt.o
 
 CFLAGS-y += -I$(BASEDIR)/include/xen/libfdt/
 
-libfdt.o: libfdt-temp.o Makefile
-	$(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
+libfdt.o: libfdt-temp.o FORCE
+	$(call if_changed,objcopy)
 
-libfdt-temp.o: $(LIBFDT_OBJS)
-	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
+libfdt-temp.o: $(LIBFDT_OBJS) FORCE
+	$(call if_changed,ld)
+
+extra-y += libfdt-temp.o $(LIBFDT_OBJS)
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index 6db396347b1f..eebfceecc5fb 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -20,12 +20,21 @@ AV_H_FILES = include/av_perm_to_string.h include/av_permissions.h
 ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
 
 $(obj-y) ss/built_in.o: $(ALL_H_FILES)
+extra-y += $(ALL_H_FILES)
 
-$(subst include/,%/,$(FLASK_H_FILES)): $(FLASK_H_DEPEND)
-	$(CONFIG_SHELL) policy/mkflask.sh $(AWK) include $(FLASK_H_DEPEND)
+mkflask := policy/mkflask.sh
+quiet_cmd_mkflask = MKFLASK $@
+cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND)
 
-$(subst include/,%/,$(AV_H_FILES)): $(AV_H_DEPEND)
-	$(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
+$(subst include/,%/,$(FLASK_H_FILES)): $(FLASK_H_DEPEND) $(mkflask) FORCE
+	$(call if_changed,mkflask)
+
+mkaccess := policy/mkaccess_vector.sh
+quiet_cmd_mkaccess = MKACCESS VECTOR $@
+cmd_mkaccess = $(CONFIG_SHELL) $(mkaccess) $(AWK) $(AV_H_DEPEND)
+
+$(subst include/,%/,$(AV_H_FILES)): $(AV_H_DEPEND) $(mkaccess) FORCE
+	$(call if_changed,mkaccess)
 
 obj-bin-$(CONFIG_XSM_FLASK_POLICY) += flask-policy.o
 flask-policy.o: policy.bin
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVu-0005a8-8O; Tue, 21 Apr 2020 16:12:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVs-0005Yk-QF
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:44 +0000
X-Inumbo-ID: eb4cf23e-83ea-11ea-b4f4-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id eb4cf23e-83ea-11ea-b4f4-bc764e2007e4;
 Tue, 21 Apr 2020 16:12:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485558;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=s+d3Av6oel5qMTSwNLaojwyj9CuUdXJgvmHiictMXoI=;
 b=YWByUit3bQOKzVXz3HSTt5Nxkmlk3vHxEGVuuoXO9rz2E1UgEN6p6RK0
 tVhDD9WEvG0aTDPicmPiqJR0HqXJr1L+F1dq/RF+G2o+lRIspBpvANvWy
 PtMQTsh9mUpo63ol9U98rX4rfbEsbMg2RY7BDDf3I+Ssk7xfNbJgD5GP4 M=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: q9maglSWzj19QYn3MKDXTkwLOC3tZHBAOphDPsyhBvZzMFAEiKTeKUfAIjQ5yE/KBLrAmsEsqS
 HFgjxL1hthFHWSTmySTWArecW2UaiuDBL5ouWTZh5suWaAQUVCqqS2i9PpFSpj+3Q2kQSJY8RO
 kXPMUIAXxNknd9J9+C4hPBHRAZNuishUiyq4cFFPwCxyVsXau8l7s+NkA9S9ZRJAZoJdB56uxN
 L4/G3S2TUSE1zaGbzCZDNG4gaouELAsh4tfja3tEvYBT1meGNegYnGTQUNG/O1rRPB8vd1rKUE
 glw=
X-SBRS: 2.7
X-MesageID: 16330448
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16330448"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 08/16] build: Introduce $(cpp_flags)
Date: Tue, 21 Apr 2020 17:12:00 +0100
Message-ID: <20200421161208.2429539-9-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

Notes:
    v5:
    - new patch

 xen/Rules.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 2e28c572305a..25bcf45612bd 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -123,6 +123,7 @@ $(obj-bin-y): XEN_CFLAGS := $(filter-out -flto,$(XEN_CFLAGS))
 
 c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_CFLAGS) '-D__OBJECT_FILE__="$@"'
 a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_AFLAGS)
+cpp_flags = $(filter-out -Wa$(comma)%,$(a_flags))
 
 include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
 
@@ -207,7 +208,7 @@ quiet_cmd_cc_s_c = CC      $@
 cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
 
 quiet_cmd_s_S = CPP     $@
-cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
+cmd_s_S = $(CPP) $(cpp_flags) $< -o $@
 
 %.i: %.c FORCE
 	$(call if_changed,cpp_i_c)
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVy-0005eK-Jl; Tue, 21 Apr 2020 16:12:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVx-0005dA-Gm
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:49 +0000
X-Inumbo-ID: edb62586-83ea-11ea-9160-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id edb62586-83ea-11ea-9160-12813bfff9fa;
 Tue, 21 Apr 2020 16:12:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485562;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=0izhnBZO5D9wuACF3/cIE86tFOeUto318+1OADqyCoo=;
 b=BGACX90UYtvdeQSJReSQ1jC/QaiIrKVDJKOWLR6Ry1nCTSiTMfMkIe58
 8if9AsqTNdOBMmXC2g5bEyeq8j7rKb7lCPUQixCjYq924g8hOMV1x4iYJ
 G4H6sjTOaDIygZmJ725Nb3bZMhf8mqY2zH0oT2yxfGgiuzoLCAWohlu3Q 4=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: ujEdstzz5iP8bpZsR/3NBoE1tb6gIVT7YwtcNbq9VfKnStCgLpX6k5L627K1LwFbmN+kuFiiDZ
 FhJKu0F87UC/m0hLWErGTkp8kFg/yejZa7jcFrElnvNNQz18wsTq7zY/anJQELC+nF68R6xqH3
 WfHAmb6afBqD96j85hj+u/ixJED7VeZ9yqQM/enH6/er78WAaMy0LtxpRcu/IaD9RLIvd4zXp+
 SO9U+16kUnGXkikqoFAvdoL7G+0IDKSy4OEklkoS9z41wR2/TtH6Eo5rhYIyGXK/HEWJl0L8Oi
 aeE=
X-SBRS: 2.7
X-MesageID: 16414439
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16414439"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 10/16] xen/build: Use if_changed_rules with %.o:%.c
 targets
Date: Tue, 21 Apr 2020 17:12:02 +0100
Message-ID: <20200421161208.2429539-11-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Use $(dot-target) to have the target name prefix with a dot.

Now, when the CC command has run, it is recorded in .*.cmd
file, then if_changed_rules will compare it on subsequent runs.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
 xen/Rules.mk | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 5e08e14455d7..9150911296de 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -173,19 +173,27 @@ FORCE:
 
 SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR))
 
-%.o: %.c Makefile
+quiet_cmd_cc_o_c = CC      $@
 ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y)
-	$(CC) $(c_flags) -c $< -o $(@D)/.$(@F).tmp -MQ $@
-ifeq ($(CONFIG_CC_IS_CLANG),y)
-	$(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< $(@D)/.$(@F).tmp $@
-else
-	$(OBJCOPY) --redefine-sym $(<F)=$(SRCPATH)/$< $(@D)/.$(@F).tmp $@
-endif
-	rm -f $(@D)/.$(@F).tmp
+    cmd_cc_o_c = $(CC) $(c_flags) -c $< -o $(dot-target).tmp -MQ $@
+    ifeq ($(CONFIG_CC_IS_CLANG),y)
+        cmd_objcopy_fix_sym = $(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< $(dot-target).tmp $@
+    else
+        cmd_objcopy_fix_sym = $(OBJCOPY) --redefine-sym $(<F)=$(SRCPATH)/$< $(dot-target).tmp $@
+    endif
+    cmd_objcopy_fix_sym += && rm -f $(dot-target).tmp
 else
-	$(CC) $(c_flags) -c $< -o $@
+    cmd_cc_o_c = $(CC) $(c_flags) -c $< -o $@
 endif
 
+define rule_cc_o_c
+    $(call cmd_and_record,cc_o_c)
+    $(call cmd,objcopy_fix_sym)
+endef
+
+%.o: %.c FORCE
+	$(call if_changed_rule,cc_o_c)
+
 quiet_cmd_cc_o_S = CC      $@
 cmd_cc_o_S = $(CC) $(a_flags) -c $< -o $@
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvVy-0005ej-VC; Tue, 21 Apr 2020 16:12:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvVx-0005dZ-QZ
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:49 +0000
X-Inumbo-ID: ec636cfc-83ea-11ea-9e09-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ec636cfc-83ea-11ea-9e09-bc764e2007e4;
 Tue, 21 Apr 2020 16:12:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485560;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=SOrawvnXI2EUHIZElTe68KnUYiUQdGo4YNmYWBa9KoA=;
 b=fmB4O+9RoEv4ar6rJqUyLTeMN158KLfmW+iryxjoJawu7SLixTUVlExF
 T/UuSHcbC2K0V1rZc+DS03Nc9lFUlMDX4pPXvnQT0tagoQwYldXYKsyiU
 E2uVTMvxcXpJnDKAZ7qDrA0l7h2ywVwlcL477sGElCzl4KIAoib2tC4Ba k=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Gk7xBkDrgkEf1i9W3J69/g+xQZ72ufhT5RhktDe0S/j93oin1DJRXPTvKTLC+lD+6vInav5hKc
 rus9WLFzapszJd04+vIEb6d9FnI9B/LyoYi2/axsi7sBqbEY2m8VAP5+f289OGEDGmDidJgSvt
 E79+aFIlQ2Z4JhlGaf56H6yawtpTeCIhDzii1VVNtqqpPQKQ6ILiJIzIkxcEEw3eFuHrPCWkFg
 ufhMdGtYltYOHwmG7EbfPrNZh40+zxKoAAZ8psUjryLyM0L2H0Mh0kkqdk9CxdBk3hn4b2F6/k
 IpY=
X-SBRS: 2.7
X-MesageID: 16692953
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16692953"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 09/16] xen/build: use if_changed on built_in.o
Date: Tue, 21 Apr 2020 17:12:01 +0100
Message-ID: <20200421161208.2429539-10-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In the case where $(obj-y) is empty, we also replace $(c_flags) by
$(XEN_CFLAGS) to avoid generating an .%.d dependency file. This avoid
make trying to include %.h file in the ld command if $(obj-y) isn't
empty anymore on a second run.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

Notes:
    v4:
    - Have cmd_ld_builtin depends on CONFIG_LTO, which simplify built_in.o
      rule.

 xen/Rules.mk | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 25bcf45612bd..5e08e14455d7 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -130,15 +130,24 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
 c_flags += $(CFLAGS-y)
 a_flags += $(CFLAGS-y) $(AFLAGS-y)
 
-built_in.o: $(obj-y) $(extra-y)
-ifeq ($(obj-y),)
-	$(CC) $(c_flags) -c -x c /dev/null -o $@
-else
+quiet_cmd_ld_builtin = LD      $@
 ifeq ($(CONFIG_LTO),y)
-	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
+cmd_ld_builtin = \
+    $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
 else
-	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
+cmd_ld_builtin = \
+    $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
 endif
+
+quiet_cmd_cc_builtin = LD      $@
+cmd_cc_builtin = \
+    $(CC) $(XEN_CFLAGS) -c -x c /dev/null -o $@
+
+built_in.o: $(obj-y) $(extra-y) FORCE
+ifeq ($(obj-y),)
+	$(call if_changed,cc_builtin)
+else
+	$(call if_changed,ld_builtin)
 endif
 
 targets += built_in.o
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvW4-0005jq-D7; Tue, 21 Apr 2020 16:12:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvW2-0005iI-HN
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:54 +0000
X-Inumbo-ID: efada4b8-83ea-11ea-9160-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id efada4b8-83ea-11ea-9160-12813bfff9fa;
 Tue, 21 Apr 2020 16:12:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485566;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=AQRaVk/v7QW+wcXm5kKKaYVv1dsIzBGEE54VZC5qCQM=;
 b=QFHvQuH5mqQtpreZ1hVn5b2uqsM8V7PIuFDabFGhTUYolK7qdQxVJJSH
 SdBTzdGa3RePi7d2UVPRValm6juA90WjlpuBobAvplnkEF2emrruJRn2z
 X6sSG26lxL50QQb9Zvl05L8ygGszxmWzetc94FCxevhn3ARGdM0+fj+J/ 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: RuL8iKNRLtVvNJJ7CxqCEc+OTd+Y44oac2zE58IMbR6GruoGJWHV0RInsFDQ4hqI7mWfLJwTNA
 ux3FkUbeWLwCYIZ45FDlqsB/PUKYenCcQEYILmZJ8u38tb8dOIRt98jE2nkX0rIbcsoUzou9u5
 brt0Ewe0hJp4tUYhfyeE7Rkv0UmjXRw14nA2Jl8GMlHQlgzyfeSk3ULBLxzYqye8qNB8NBYsHs
 ZN1sm5cPVjk3CWXf22VqJkQ0W2O8JO/h0bGIXzTAjpyc/s7JkAmpSfejS3ufPEP9pUR0898zDo
 60Q=
X-SBRS: 2.7
X-MesageID: 15998896
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="15998896"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 11/16] xen/build: factorise generation of the linker
 scripts
Date: Tue, 21 Apr 2020 17:12:03 +0100
Message-ID: <20200421161208.2429539-12-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In Arm and X86 makefile, generating the linker script is the same, so
we can simply have both call the same macro.

We need to add *.lds files into extra-y so that Rules.mk can find the
.*.cmd dependency file and load it.

Change made to the command line:
- Use of $(CPP) instead of $(CC) -E
- Remove -Ui386.
  We don't compile Xen for i386 anymore, so that macro is never
  defined. Also it doesn't make sense on Arm.
- Use $(cpp_flags) which simply filter -Wa,% options from $(a_flags).

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

Notes:
    v5:
    - rename cc_lds_S to cpp_lds_S as the binary runned is now CPP
    - Use new cpp_flags instead of the open-coded filter of a_flags.
    
    v4:
    - fix rebuild by adding FORCE as dependency
    - Use $(CPP)
    - remove -Ui386
    - avoid using "define" for cmd_cc_lds_S, as adding '; \' on each line is
      still mandatory for if_changed (or cmd) macro to work.

 xen/Rules.mk          | 6 ++++++
 xen/arch/arm/Makefile | 8 ++++----
 xen/arch/x86/Makefile | 8 ++++----
 3 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 9150911296de..877f52d871fa 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -236,6 +236,12 @@ cmd_s_S = $(CPP) $(cpp_flags) $< -o $@
 %.s: %.S FORCE
 	$(call if_changed,cpp_s_S)
 
+# Linker scripts, .lds.S -> .lds
+quiet_cmd_cpp_lds_S = LDS     $@
+cmd_cpp_lds_S = $(CPP) -P $(cpp_flags) -o $@ $<; \
+    sed -e 's/.*\.lds\.o:/$(@F):/g' <$(dot-target).d >$(dot-target).d.new; \
+    mv -f $(dot-target).d.new $(dot-target).d
+
 # Add intermediate targets:
 # When building objects with specific suffix patterns, add intermediate
 # targets that the final targets are derived from.
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b79ad55646bd..68cb258870eb 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -64,6 +64,8 @@ obj-y += vpsci.o
 obj-y += vuart.o
 extra-y += $(TARGET_SUBARCH)/head.o
 
+extra-y += xen.lds
+
 #obj-bin-y += ....o
 
 ifdef CONFIG_DTB_FILE
@@ -122,10 +124,8 @@ $(TARGET)-syms: prelink.o xen.lds
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
 	$(CC) $(filter-out -flto,$(c_flags)) -S -o $@ $<
 
-xen.lds: xen.lds.S
-	$(CC) -P -E -Ui386 $(a_flags) -o $@ $<
-	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
-	mv -f .xen.lds.d.new .xen.lds.d
+xen.lds: xen.lds.S FORCE
+	$(call if_changed,cpp_lds_S)
 
 dtb.o: $(CONFIG_DTB_FILE)
 
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 44137d919b66..92430192a74e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -72,6 +72,7 @@ obj-y += hpet.o
 obj-y += vm_event.o
 obj-y += xstate.o
 extra-y += asm-macros.i
+extra-y += xen.lds
 
 x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
 
@@ -173,6 +174,7 @@ export XEN_BUILD_EFI := $(shell $(CC) $(XEN_CFLAGS) -c efi/check.c -o efi/check.
 # Check if the linker supports PE.
 XEN_BUILD_PE := $(if $(XEN_BUILD_EFI),$(shell $(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o 2>/dev/null && echo y))
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
+extra-$(XEN_BUILD_PE) += efi.lds
 
 $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A VIRT_START$$,,p')
 $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A ALT_START$$,,p')
@@ -240,10 +242,8 @@ $(BASEDIR)/include/asm-x86/asm-macros.h: asm-macros.i Makefile
 	$(call move-if-changed,$@.new,$@)
 
 efi.lds: AFLAGS-y += -DEFI
-xen.lds efi.lds: xen.lds.S
-	$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<
-	sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new
-	mv -f .$(@F).d.new .$(@F).d
+xen.lds efi.lds: xen.lds.S FORCE
+	$(call if_changed,cpp_lds_S)
 
 boot/mkelf32: boot/mkelf32.c
 	$(HOSTCC) $(HOSTCFLAGS) -o $@ $<
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:12:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvW4-0005kC-O6; Tue, 21 Apr 2020 16:12:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvW2-0005iZ-Qs
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:54 +0000
X-Inumbo-ID: f14645c8-83ea-11ea-b4f4-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f14645c8-83ea-11ea-b4f4-bc764e2007e4;
 Tue, 21 Apr 2020 16:12:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485568;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=QA9Ytw4tgdGXTJdplw1k3QfIYlPUtGeX6093EfEeAnY=;
 b=BjPRijYPNPVYcSo8KKdZR8V98qmow1dJ+62qsFy9giq2jlbMCM4FVTJ7
 pijDNXmXSqfY+L7jRpk/jKR1jN39AlEjAxXi5NaaGGTmRASFP5q2mze9h
 DSLjRAsagtAUxPrIgovsY+Z0i/pXPF+NiUx2ArV4WpR71NW527qjVxglv 8=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 0Jel8dWhOjiailf28vFm17hFhGbAdy1mt+9Lh2fXij2TwM3hMRtUOyyhBPttrc7O7UCGqnUWll
 INMFWBBpaBSprs1hSvgI2G1/TlFo0pO9C5nUMNsygQP3gCtuuwE54PmP6mKb12JE3i81NwFuvD
 HE/hmtfyDuvBUjR+rVGfvIy6DQ0sulIOe1vMIAl07+nDCWm+N2q12GV+gzhymYtbxrKekN+Sa6
 cZeFa13ktezfhdZBBkIIYibmn4XKVhAU1CkPuIVUc5g5gEj3hIR5g0LLjdm8HVJpbMCJifwokk
 90c=
X-SBRS: 2.7
X-MesageID: 16692967
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16692967"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 13/16] xen,symbols: rework file symbols selection
Date: Tue, 21 Apr 2020 17:12:05 +0100
Message-ID: <20200421161208.2429539-14-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We want to use the same rune to build mm/*/guest_*.o as the one use to
build every other *.o object. The consequence it that file symbols that
the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.

For example, when building arch/x86/mm/guest_walk_2.o from guest_walk.c,
this would be the difference of file symbol present in the object when
building with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y:

(1) Currently we have those two file symbols:
    guest_walk.c
    guest_walk_2.o
(2) When building with the same rune, we will have:
    arch/x86/mm/guest_walk.c
    guest_walk_2.o

The order in which those symbols are present may be different. Building
without CONFIG_ENFORCE_UNIQUE_SYMBOLS will result in (1).

Currently, in case (1) ./symbols chooses the *.o symbol (object file
name). But in case (2), may choose the *.c symbol (source file name with
path component) if it is first

We want to have ./symbols choose the object file name symbol in both
cases. So this patch changes that ./symbols prefer the "object file
name" symbol over the "source file name with path component" symbols.

The new intended order of preference is:
    - first object file name symbol (present only in object files
      produced from multiply-compiled sources)
    - first source file name with path components symbol
    - last source file name without any path component symbol

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

Notes:
    v5:
    - reword part of the commit message
    
    v4:
    - rescope enum symbol_type
    - remove setting values to enums, as it's not needed.
    - rename the enumeration symbols

 xen/tools/symbols.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/tools/symbols.c b/xen/tools/symbols.c
index 9f9e2c990061..b3a9465b32d3 100644
--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -84,7 +84,12 @@ static int read_symbol(FILE *in, struct sym_entry *s)
 {
 	char str[500], type[20] = "";
 	char *sym, stype;
-	static enum { symbol, single_source, multi_source } last;
+	static enum symbol_type {
+		symbol,
+		file_source,
+		path_source,
+		obj_file,
+	} last;
 	static char *filename;
 	int rc = -1;
 
@@ -125,13 +130,20 @@ static int read_symbol(FILE *in, struct sym_entry *s)
 		 * prefer the first one if that names an object file or has a
 		 * directory component (to cover multiply compiled files).
 		 */
-		bool multi = strchr(str, '/') || (sym && sym[1] == 'o');
+		enum symbol_type current;
 
-		if (multi || last != multi_source) {
+		if (sym && sym[1] == 'o')
+		    current = obj_file;
+		else if (strchr(str, '/'))
+		    current = path_source;
+		else
+		    current = file_source;
+
+		if (current > last || last == file_source) {
 			free(filename);
 			filename = *str ? strdup(str) : NULL;
+			last = current;
 		}
-		last = multi ? multi_source : single_source;
 		goto skip_tail;
 	}
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:13:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvW9-0005qL-9V; Tue, 21 Apr 2020 16:13:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvW7-0005oV-Hd
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:59 +0000
X-Inumbo-ID: f1d545e9-83ea-11ea-9160-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f1d545e9-83ea-11ea-9160-12813bfff9fa;
 Tue, 21 Apr 2020 16:12:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485570;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=CYI3fXntoKuTBeVkyy91OK1emIZvOATrp8gvGepHy7M=;
 b=PD7zjurtAAs+MC42N1bqh/fC5Th2gxBbA2KzKD/woz588YbCbUOj2ORM
 iB4VibyGe8FSpwk5HV9wpt7Kf9Xk2XJD6UdpmEhdhzVf62ADO34/w+4tv
 mSUFSALFbxaqWs4Jq4al9ZX/q40sbpDjnITKELi9fxpnadn4Cy/V37wgA g=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: vqf/pjQitzpEos5dEuzl3VApKVPOredEl9GVRmphC3CN+HN+RqMhN2quBTVhZpeHoA9sVkXlKP
 AQ0EP+69wNmpk55q9nNxngpJFt6RsaV6dtcBLX8tS1fxZHe5K1oAWC0+z7Q9RoW/4aGQwn2xZA
 zcEh4XaqeQLzeUn6+doLT+n9ju7UQsrBtdOEMGIL2TQwfMRzY9+jcISypAJbqvCF8eYOeQSlKv
 RDGm6lSQsvYdWINdYdI8vPt+2NaC+tvUxR26L8VG5u1U857J4f7d2Uf7d9GYtN2dYoh3M1780n
 XqE=
X-SBRS: 2.7
X-MesageID: 15998908
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="15998908"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 14/16] build: use if_changed to build mm/*/guest_%.o
Date: Tue, 21 Apr 2020 17:12:06 +0100
Message-ID: <20200421161208.2429539-15-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Use if_changed for building all guest_%.o objects, and make use of
command that already exist.

The current command only runs `CC`, but the runes to build every other
object in Xen also runs `objcopy` (when CONFIG_ENFORCE_UNIQUE_SYMBOLS=y)
which modify the file symbol. But with patch
"xen,symbols: rework file symbols selection", ./symbols should still
select the file symbols directive intended to be used for guest_%.o
objects.

The goal here is to reduce the number of commands written in
makefiles.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

Notes:
    v5:
    - reword commit message
    
    v4:
    - remove the introduction of Kbuild's CFLAGS_$@
      and simply use make's per-target variable customization.
      Mostly to avoid using $(eval ) which might not work as expected on
      make 3.80.

 xen/arch/x86/mm/Makefile        | 14 ++++++++------
 xen/arch/x86/mm/hap/Makefile    | 15 +++++++++------
 xen/arch/x86/mm/shadow/Makefile | 14 ++++++++------
 3 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index a2431fde6bb4..a66a57314489 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -11,11 +11,13 @@ obj-y += p2m.o p2m-pt.o
 obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
 obj-y += paging.o
 
-guest_walk_%.o: guest_walk.c Makefile
-	$(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+guest_walk_%.o guest_walk_%.i guest_walk_%.s: CFLAGS-y += -DGUEST_PAGING_LEVELS=$*
 
-guest_walk_%.i: guest_walk.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+guest_walk_%.o: guest_walk.c FORCE
+	$(call if_changed_rule,cc_o_c)
 
-guest_walk_%.s: guest_walk.c Makefile
-	$(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
+guest_walk_%.i: guest_walk.c FORCE
+	$(call if_changed,cpp_i_c)
+
+guest_walk_%.s: guest_walk.c FORCE
+	$(call if_changed,cc_s_c)
diff --git a/xen/arch/x86/mm/hap/Makefile b/xen/arch/x86/mm/hap/Makefile
index 22e7ad54bd33..34720b2fbe2e 100644
--- a/xen/arch/x86/mm/hap/Makefile
+++ b/xen/arch/x86/mm/hap/Makefile
@@ -5,11 +5,14 @@ obj-y += guest_walk_4level.o
 obj-y += nested_hap.o
 obj-y += nested_ept.o
 
-guest_walk_%level.o: guest_walk.c Makefile
-	$(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+guest_walk_%level.o guest_walk_%level.i guest_walk_%level.s: \
+    CFLAGS-y += -DGUEST_PAGING_LEVELS=$*
 
-guest_walk_%level.i: guest_walk.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+guest_walk_%level.o: guest_walk.c FORCE
+	$(call if_changed_rule,cc_o_c)
 
-guest_walk_%level.s: guest_walk.c Makefile
-	$(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
+guest_walk_%level.i: guest_walk.c FORCE
+	$(call if_changed,cpp_i_c)
+
+guest_walk_%level.s: guest_walk.c FORCE
+	$(call if_changed,cc_s_c)
diff --git a/xen/arch/x86/mm/shadow/Makefile b/xen/arch/x86/mm/shadow/Makefile
index 23d3ff10802c..e00f9cb1aaba 100644
--- a/xen/arch/x86/mm/shadow/Makefile
+++ b/xen/arch/x86/mm/shadow/Makefile
@@ -6,11 +6,13 @@ else
 obj-y += none.o
 endif
 
-guest_%.o: multi.c Makefile
-	$(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+guest_%.o guest_%.i guest_%.s: CFLAGS-y += -DGUEST_PAGING_LEVELS=$*
 
-guest_%.i: multi.c Makefile
-	$(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+guest_%.o: multi.c FORCE
+	$(call if_changed_rule,cc_o_c)
 
-guest_%.s: multi.c Makefile
-	$(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
+guest_%.i: multi.c FORCE
+	$(call if_changed,cpp_i_c)
+
+guest_%.s: multi.c FORCE
+	$(call if_changed,cc_s_c)
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:13:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvW9-0005qq-L9; Tue, 21 Apr 2020 16:13:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvW7-0005oq-Qd
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:12:59 +0000
X-Inumbo-ID: f406669e-83ea-11ea-83d8-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f406669e-83ea-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 16:12:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485573;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=b2jcJWvHVOOCDCdVXs6JVD54TeD6Qf6UZQ9BDc6Gxpw=;
 b=hyl8OwRvVyWcVxV7T5/xCWcbCc85oBXauj0r4jlMJ1I8IdE9IJZiIor3
 Uto4fGgd81roREWVO5zELU50Jw//hgsaE0BQqQRySTK0tp2lee6cxCpjl
 vQngD4Ot1/+9L1px0F7GdwPW9UlZJMN1mhFdtFTY+/fFXeLoCQOTw2she A=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 8FTpPkx2AdH6Lr+kJmSFCeHSjZIJlgp2SQCaEsA5zUYTx6BRjQNzJKePsUmaLU0RW/TUwvZIwx
 QbNyk7BZc3GxuxvT6UlCtAj7IDIY7cnuYwqMKpfU/ds3WmT6u5YZpNtZGNyzN/VFFc3bwW1uTu
 sssO9MkWUlXSDGUAiWOIqu2wBaFogq4uaDyQUigzZ8MFfGFILoS67U4vyS/56SdY44HcwJw9ra
 rftnofxm4HrrUhK7wD+vEjGIuJtaExTyYaThM6Hrx+FPLGWxGP2mXaIyGdLBt/Ys2eBKRxwhcS
 QDk=
X-SBRS: 2.7
X-MesageID: 16330476
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16330476"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 15/16] build,include: rework compat-build-source.py
Date: Tue, 21 Apr 2020 17:12:07 +0100
Message-ID: <20200421161208.2429539-16-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Improvement are:
- give the path to xlat.lst as argument
- include `grep -v` in compat-build-source.py script, we don't need to
  write this in several scripted language.

No changes in final compat/%.h headers.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

Notes:
    v5:
    - removed "have 'xlat.lst' path as a variable" from the patch.
    
    v4:
    - new patch

 xen/include/Makefile             | 3 +--
 xen/tools/compat-build-source.py | 8 +++++++-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 2a10725d689b..537085b82793 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -68,8 +68,7 @@ compat/%.i: compat/%.c Makefile
 
 compat/%.c: public/%.h xlat.lst Makefile $(BASEDIR)/tools/compat-build-source.py
 	mkdir -p $(@D)
-	grep -v 'DEFINE_XEN_GUEST_HANDLE(long)' $< | \
-	$(PYTHON) $(BASEDIR)/tools/compat-build-source.py >$@.new
+	$(PYTHON) $(BASEDIR)/tools/compat-build-source.py xlat.lst <$< >$@.new
 	mv -f $@.new $@
 
 compat/.xlat/%.h: compat/%.h compat/.xlat/%.lst $(BASEDIR)/tools/get-fields.sh Makefile
diff --git a/xen/tools/compat-build-source.py b/xen/tools/compat-build-source.py
index c664eb85e633..c7fc2c53db61 100755
--- a/xen/tools/compat-build-source.py
+++ b/xen/tools/compat-build-source.py
@@ -12,7 +12,11 @@ pats = [
  [ r"XEN_GUEST_HANDLE(_[0-9A-Fa-f]+)?", r"COMPAT_HANDLE" ],
 ];
 
-xlatf = open('xlat.lst', 'r')
+try:
+    xlatf = open(sys.argv[1], 'r')
+except IndexError:
+    print('missing path to xlat.lst argument')
+    sys.exit(1)
 for line in xlatf.readlines():
     match = re.subn(r"^\s*\?\s+(\w*)\s.*", r"\1", line.rstrip())
     if match[1]:
@@ -24,6 +28,8 @@ for pat in pats:
     pat[0] = re.compile(pat[0])
 
 for line in sys.stdin.readlines():
+    if 'DEFINE_XEN_GUEST_HANDLE(long)' in line:
+        continue
     for pat in pats:
         line = re.sub(pat[0], pat[1], line)
     print(line.rstrip())
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:13:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:13:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvWE-0005vm-0T; Tue, 21 Apr 2020 16:13:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvWC-0005uQ-RP
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:13:04 +0000
X-Inumbo-ID: f661cd52-83ea-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f661cd52-83ea-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 16:12:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485577;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=K8Lniz6UiDyu3Tb2CuVmdy2kcNZ7QfJlssODBIQJTks=;
 b=ZYfIZ6ztBpnaDNBkBXD+y/CyDJFuzc5wOXv4sdxHn5GzvRY6UMN0yvA6
 4LbFOsae0AbW2Hmwkc8tds0PFWESqOW7+bxCB+ynalO+ysCk4CA94MBR1
 DXIwS52ThFnEwu0u1laPGr6eeusMgJJnSPxXL+F4Pf1g0sRHCgg9lmeGo c=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: QJCQGW3Yhu9OQfaPCzcw5RV6uFa+quI1o+tDsWt9gY494v0hluljYK7Ir3bIl3vIWAa6VBnjqp
 s1VxnAescwFA6Nu8xLymWseN2yOt1eQQld7KAAoGdcSxXq179LoLYo5EFgEZSznKuumfpL5rvN
 gLB/Dh9FlgO29TfJz2PbEsqsussiUBC2WB2YqX8MyboireG4y5JUwF8qpyldV5FAloPgcVwe7K
 4MNOIrKSmcLU9MTmKPqdBDknDzFQBpOvImK8d66nP+l9S/X8iElvDAqAzqziHgx6C66t6Bvyiz
 dFE=
X-SBRS: 2.7
X-MesageID: 16692977
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16692977"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 16/16] build,include: rework compat-build-header.py
Date: Tue, 21 Apr 2020 17:12:08 +0100
Message-ID: <20200421161208.2429539-17-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Replace a mix of shell script and python script by all python script.

No change to the final generated headers.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

Notes:
    v5:
    - Removed -P from CPP when generating compat/%.i
      -> keep removing linemarkers and keep de-duplicating empty lines.
      So that all the blank line that currently exist in the generated
      headers stays in place.
    
    v4:
    - new patch

 xen/include/Makefile             | 11 +------
 xen/tools/compat-build-header.py | 52 ++++++++++++++++++++++++++++++--
 2 files changed, 51 insertions(+), 12 deletions(-)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 537085b82793..12660625119e 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -51,16 +51,7 @@ public-$(CONFIG_ARM) := $(wildcard public/arch-arm/*.h public/arch-arm/*/*.h)
 all: $(headers-y)
 
 compat/%.h: compat/%.i Makefile $(BASEDIR)/tools/compat-build-header.py
-	set -e; id=_$$(echo $@ | tr '[:lower:]-/.' '[:upper:]___'); \
-	echo "#ifndef $$id" >$@.new; \
-	echo "#define $$id" >>$@.new; \
-	echo "#include <xen/compat.h>" >>$@.new; \
-	$(if $(filter-out compat/arch-%.h,$@),echo "#include <$(patsubst compat/%,public/%,$@)>" >>$@.new;) \
-	$(if $(prefix-y),echo "$(prefix-y)" >>$@.new;) \
-	grep -v '^# [0-9]' $< | \
-	$(PYTHON) $(BASEDIR)/tools/compat-build-header.py | uniq >>$@.new; \
-	$(if $(suffix-y),echo "$(suffix-y)" >>$@.new;) \
-	echo "#endif /* $$id */" >>$@.new
+	$(PYTHON) $(BASEDIR)/tools/compat-build-header.py <$< $@ "$(prefix-y)" "$(suffix-y)" >>$@.new; \
 	mv -f $@.new $@
 
 compat/%.i: compat/%.c Makefile
diff --git a/xen/tools/compat-build-header.py b/xen/tools/compat-build-header.py
index b85c43f13faf..34d5343c3dd9 100755
--- a/xen/tools/compat-build-header.py
+++ b/xen/tools/compat-build-header.py
@@ -2,6 +2,12 @@
 
 import re,sys
 
+try:
+    maketrans = str.maketrans
+except AttributeError:
+    # For python2
+    from string import maketrans
+
 pats = [
  [ r"__InClUdE__(.*)", r"#include\1\n#pragma pack(4)" ],
  [ r"__IfDeF__ (XEN_HAVE.*)", r"#ifdef \1" ],
@@ -20,7 +26,49 @@ pats = [
  [ r"(^|[^\w])long([^\w]|$$)", r"\1int\2" ]
 ];
 
+output_filename = sys.argv[1]
+
+# tr '[:lower:]-/.' '[:upper:]___'
+header_id = '_' + \
+    output_filename.upper().translate(maketrans('-/.','___'))
+
+header = """#ifndef {0}
+#define {0}
+#include <xen/compat.h>""".format(header_id)
+
+print(header)
+
+if not re.match("compat/arch-.*.h$", output_filename):
+    x = output_filename.replace("compat/","public/")
+    print('#include <%s>' % x)
+
+def print_if_nonempty(s):
+    if len(s):
+        print(s)
+
+print_if_nonempty(sys.argv[2])
+
+last_line_empty = False
 for line in sys.stdin.readlines():
+    line = line.rstrip()
+
+    # Remove linemarkers generated by the preprocessor.
+    if re.match(r"^# \d", line):
+        continue
+
+    # De-duplicate empty lines.
+    if len(line) == 0:
+        if not last_line_empty:
+            print(line)
+            last_line_empty = True
+        continue
+    else:
+        last_line_empty = False
+
     for pat in pats:
-        line = re.subn(pat[0], pat[1], line)[0]
-    print(line.rstrip())
+        line = re.sub(pat[0], pat[1], line)
+    print(line)
+
+print_if_nonempty(sys.argv[3])
+
+print("#endif /* %s */" % header_id)
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:13:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:13:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvWJ-00060u-Bc; Tue, 21 Apr 2020 16:13:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=FwqV=6F=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jQvWI-0005zp-Dt
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:13:10 +0000
X-Inumbo-ID: fde20fc4-83ea-11ea-9160-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fde20fc4-83ea-11ea-9160-12813bfff9fa;
 Tue, 21 Apr 2020 16:13:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587485590;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=3g/kc8pNBw/sbdvX8irTw/wR8q6h/mFF8tP1CnqtF6w=;
 b=WHguN2UvweZDs0NMi87RA7Y58eVPBso4TfhaSvRUjMAK/1kSdpLlAtpn
 +hLtG8Wszj7KnL4ifCWBH8k4sjED+yMtxWiASAEAVRvoB8HDHBlAuyX8F
 IOi0JOM+pHG6IwsA5JaOXQMqb+PofLKq8CinUnswwY79Qo4IF6JDTHlzW 4=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: CAhOQPrrOcKx0DyUd3f5+wGXVaKwUjLgvnEY/nn4lojwnga0TLEzSbdbZjNGXMUDcD08sp4TBx
 ooZ3vTPQ2WHvXNzR797ib/ED7z7iMgIcr8bqYiv+yuKRDHSDnGBSZK7XWQnxW7n2dAnwysiIfK
 4ig9dPMhgtXvQRhaLVSMir6T2wTORHh9zKKDJ1U0vdNsIGU1SATTddXKfaEBZWzyDjg8rh0occ
 I4RbplsjAbg9w1rYg0rvoHu4J0b90eWh15O/n/DbL0ucqoavBTQ/7qEfi0KWCIK9o1ED3rIcR4
 BM8=
X-SBRS: 2.7
X-MesageID: 16262963
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16262963"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH v5 12/16] xen/build: Use if_changed for prelink*.o
Date: Tue, 21 Apr 2020 17:12:04 +0100
Message-ID: <20200421161208.2429539-13-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200421161208.2429539-1-anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We change the dependencies of prelink-efi.o so that we can use the
same command line. The dependency on efi/built_in.o isn't needed
because, we already have:
    efi/*.o: efi/built_in.o
to build efi/*.o files that prelink-efi.o needs.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---

Notes:
    v4:
    - fix rebuild, prelink.o and prelink-efi.o needs to be in targets

 xen/arch/x86/Makefile | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 92430192a74e..33e9ebf25074 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -128,11 +128,13 @@ prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
 prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink-efi_lto.o efi/boot.init.o
 	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
 else
-prelink.o: $(ALL_OBJS)
-	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
+prelink.o: $(ALL_OBJS) FORCE
+	$(call if_changed,ld)
+
+prelink-efi.o: $(filter-out %/efi/built_in.o,$(ALL_OBJS)) efi/boot.init.o efi/runtime.o efi/compat.o FORCE
+	$(call if_changed,ld)
 
-prelink-efi.o: $(ALL_OBJS) efi/boot.init.o efi/runtime.o efi/compat.o
-	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out %/efi/built_in.o,$^)
+targets += prelink.o prelink-efi.o
 endif
 
 $(TARGET)-syms: prelink.o xen.lds
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:35:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:35:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvrY-0000Lp-FV; Tue, 21 Apr 2020 16:35:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Zh6d=6F=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jQvrX-0000Lj-Ff
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:35:07 +0000
X-Inumbo-ID: 0e75d610-83ee-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0e75d610-83ee-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 16:35:06 +0000 (UTC)
Received: by mail-ed1-x544.google.com with SMTP id k22so6364026eds.6
 for <xen-devel@lists.xenproject.org>; Tue, 21 Apr 2020 09:35:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=jBH6wLTw5xYtoFHc9CAmsGToP+zT76M0LFJjcJ4nRYg=;
 b=Sp384YhaBHDUJHFoh+hYzGPOpMVjLo/BD4jyk5IVJDQocdAwQBAoQBuQp9yniVn4N4
 s2AiYDiz60zpkrO/RNQvR03Wyf9vGy5fqZYO6vvT0bGYbuSk5DggDpRlWZfmhrnc74gl
 oTGiIRzbdOTpRtFqHndO66znHBVNygnWK1kUgR8NsJRTd5OImYPb6j2mjOpVl2qiKTOs
 bgx2RUS4NgSxzDQA+FUrHaMFQqm5neJNX7srdMaDj3LQZzGXuAjaQPGtvDlwXtM2PN0x
 xgsh2sN+MfehD7L3O8ySldCugH+s74u+TJOSb+AmQSqmLRD/kcFhJWr1IGlEM3ZKozfi
 AGrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=jBH6wLTw5xYtoFHc9CAmsGToP+zT76M0LFJjcJ4nRYg=;
 b=hD6d4RNnH5HJ3IfNVDmyJD4nRWuy6+9Rw9eLGzvCeJmFai7hINI+/ceilMhwsDYcHE
 WzxNvkP09pLU92ip9dxNIQRjeluKmGnaHDQihYUzQVvUBJX6n2g5QxHz5LaHr1+XH8FA
 khSBVJdm0oGMMNnf2RXe+WLk2HHYiwahDye7HGXjZSpkD8gP4U0QYibHQ3KPFIy8B3TG
 9XBw3meoJ6Iz+Se+lWOfDMuE5ntaPsCxSQVXByzmk2d05+SwarF2FQzY0OO8hzY8XAVl
 UrcBVZwXtYImoSCTCeBfECtWpNYB4M3KRHhF1pbMCNlsp7nR6iXdcksheaiNNVeWb6u0
 HH9Q==
X-Gm-Message-State: AGi0PuYv5rvPdFDFgmliCI/KuZJhwtXdulHAp1iac9d40fWCb6w3VSTf
 B5OYXSvl3HDxWSgj0u8jm4I=
X-Google-Smtp-Source: APiQypLPfczPzOtaPhKUfdgH1b3A3rAhZ7yd9Hk10EcwATviNuevw/qjdwinAM0Gy6WJoBhgy86fhQ==
X-Received: by 2002:a05:6402:2203:: with SMTP id
 cq3mr7735609edb.154.1587486905247; 
 Tue, 21 Apr 2020 09:35:05 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.177])
 by smtp.gmail.com with ESMTPSA id r26sm361132edw.34.2020.04.21.09.35.04
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 21 Apr 2020 09:35:04 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Maximilian Heyne'" <mheyne@amazon.de>, <xen-devel@lists.xenproject.org>
References: <20200313123316.122003-1-mheyne@amazon.de>
 <6f476505-5e85-8a8a-d6d7-db56ea921637@amazon.de>
In-Reply-To: <6f476505-5e85-8a8a-d6d7-db56ea921637@amazon.de>
Subject: RE: [PATCH 0/3] Cleanup IOREQ server on exit
Date: Tue, 21 Apr 2020 17:35:03 +0100
Message-ID: <005f01d617fa$cf921ad0$6eb65070$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQGvBAjA7hxOW9V3ZNauiodGQFqJFQEiCWftqMjdIaA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Ian Jackson' <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Ping v2?

> -----Original Message-----
> From: Maximilian Heyne <mheyne@amazon.de>
> Sent: 07 April 2020 10:16
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson <ian.jackson@citrix.com>; Paul Durrant <paul@xen.org>
> Subject: Re: [PATCH 0/3] Cleanup IOREQ server on exit
> 
> Could someone please have a look at this patch? It solves an actual issue:
> Try soft-reset with qemu-xen-traditional and it will fail.
> 
> On 3/13/20 1:33 PM, Maximilian Heyne wrote:
> > Following up on commit 9c0eed61 ("qemu-trad: stop using the default IOREQ
> > server"), clean up the IOREQ server on exit. This fixes a bug with soft-reset
> > that shows up as "bind interdomain ioctl error 22" because the event channels
> > were not closed at the soft-reset and can't be bound again.
> >
> > For this I used the exit notifiers from QEMU that I backported together with the
> > required generic notifier lists.
> >
> > Anthony Liguori (1):
> >    Add support for generic notifier lists
> >
> > Gerd Hoffmann (1):
> >    Add exit notifiers.
> >
> > Maximilian Heyne (1):
> >    xen: cleanup IOREQ server on exit
> >
> >   Makefile            |  1 +
> >   hw/xen_machine_fv.c | 11 +++++++++++
> >   notify.c            | 39 +++++++++++++++++++++++++++++++++++++++
> >   notify.h            | 43 +++++++++++++++++++++++++++++++++++++++++++
> >   sys-queue.h         |  5 +++++
> >   sysemu.h            |  5 +++++
> >   vl.c                | 20 ++++++++++++++++++++
> >   7 files changed, 124 insertions(+)
> >   create mode 100644 notify.c
> >   create mode 100644 notify.h
> >
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 




From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:40:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvwJ-0000cX-3o; Tue, 21 Apr 2020 16:40:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=CVv8=6F=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jQvwH-0000Vx-QQ
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:40:01 +0000
X-Inumbo-ID: be51a622-83ee-11ea-b58d-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id be51a622-83ee-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 16:40:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587487201;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=4sTOet8CXQFB68zZkvtqHMQlWkrfatsJwLewDzbWoiE=;
 b=ScJ6/gNVIwqJlQ4hgFcMppPhY2vdmtth3ftVZmTsvqGSR+uZA+zKW/pI
 2xwfkS/HXy3GDHipGnmdg5FcbseexPMWjQfI8jQpqMhJ4gdqTpEEMyRsD
 9+HE6hOQdDNPxJbOZ3wo1dM96eysDt9IGtXja9aH2YshwU9PPv9K0Hu8E U=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 2QcckzMJ06ZX/4Mnh4YFbuKk5Fjt+GNP+RD2eoFzAzzcxZl40vztVqLdNggTdiGEsdgu9B4W5F
 z5W/CHA6P/IMCZdzd1oxtTwudQoKzyeKjqv3SCFBLu3/2FbIrr4LDXQ/EcTptxpSu6nh6TFCqb
 Nk7dCaWmLHRNpXVm+DKlQsrHbaBWlTUKRtJqhiCNaPIe8p7mR8IXAc11VBzl1WW1am7IDTfd/H
 Y1br0jvRRZSHwFtr556+H3ivJUBiNlDUxYC3TCSpJPbpn8ZpBn7LkAwRpjgbenpkmb4abgC3+Z
 AJo=
X-SBRS: 2.7
X-MesageID: 16000719
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16000719"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24223.8666.764943.818163@mariner.uk.xensource.com>
Date: Tue, 21 Apr 2020 17:39:54 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH OSSTEST v3 2/2] make-flight: add a core scheduling job
In-Reply-To: <20200415141009.10912-2-roger.pau@citrix.com>
References: <20200415141009.10912-1-roger.pau@citrix.com>
 <20200415141009.10912-2-roger.pau@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("[PATCH OSSTEST v3 2/2] make-flight: add a core scheduling job"):
> Run a simple core scheduling tests on a host that has SMT support.
> This is only enabled for Xen >= 4.13.

Thanks, pushed to pretest.

Once it makes it through staging the test will appear, but it will
start failing (nonblockingly) until the SMT hostflag has been scanned.
It would be sensible for me to run a special examine job for that.

Ian.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:41:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:41:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvxJ-0001Iq-G2; Tue, 21 Apr 2020 16:41:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Zbep=6F=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jQvxI-0001Ij-6a
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:41:04 +0000
X-Inumbo-ID: e374c060-83ee-11ea-83d8-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e374c060-83ee-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 16:41:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587487264;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=BduFHRx/PNBYm3VtA+0kr91CleodHqExL3YyPNPv24g=;
 b=Wl6qVuKAy+RyXtYOfBDbj6k/4j/cbGap2oCkm4+VDWG6zhX6bZtLe6jd
 N4o0vg4+7qfAEXor4rR5EOvC91zZCVphfWchie6/7PhBWQ2Bf1b1d+7MA
 YRXvyvkuS95ZhgK0E7XBTIVibRMeA34T9Ku5kPk46Ngi5ZZP5J/idiZmy o=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: BVWvAKyI7lfjSuM/C/feMxbL+9bS6hZUdSxrbjTFM+TO9WaUzEofhA1NOjnRb6HeYTOMNfv44z
 frt1UqnNXhdvUOVOEyhC45iZyTzZsB3xbWX2BgB4CbinJils/RLiBYZjQMKeIeedHWmRdrk3tK
 kOjDzeCbPEdgk8XLit7PV9XFk3O3B/C4YObE+nhNYVbHpUB8v86YWQ8U81msUbHo4Ry4bn4z97
 qKwhuELRkCEu06MfCTqDob4I/E9BqGyDT7McmWzjIHVY5a3z8Mrs43aW4eMOjEXPFFLMR97+ZF
 1J8=
X-SBRS: 2.7
X-MesageID: 16265048
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16265048"
Date: Tue, 21 Apr 2020 18:40:55 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2 1/4] x86/mm: no-one passes a NULL domain to
 init_xen_l4_slots()
Message-ID: <20200421164055.GW28601@Air-de-Roger>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <8787b72e-c71e-b75d-2ca0-0c6fe7c8259f@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8787b72e-c71e-b75d-2ca0-0c6fe7c8259f@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 11:11:03AM +0200, Jan Beulich wrote:
> Drop the NULL checks - they've been introduced by commit 8d7b633ada
> ("x86/mm: Consolidate all Xen L4 slot writing into
> init_xen_l4_slots()") for no apparent reason.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 16:42:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 16:42:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQvym-0001Qs-Us; Tue, 21 Apr 2020 16:42:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Zbep=6F=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jQvyl-0001Qm-SJ
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 16:42:35 +0000
X-Inumbo-ID: 1a32aac2-83ef-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1a32aac2-83ef-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 16:42:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587487355;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=6WpbqOfaHNRMZy+BKWAm9DYG28/LEC8N2Z7Q30RqXhI=;
 b=ZzSZ4TS1cnFCUBzYZFR8WPwBe0JauuiIT9DWy4HUOJMLvI2X/9bhLbIq
 s8xlwOXFJ3Vwel+bSYKCZCfXIsoXdfGwUgHCcUGCFTMydIO74DlFyAhxs
 u4ROaYBWiNEjyMNaeZu5FbD9wzWcYmcfGj1YIOIrgN0XKOjqfT5KPU0Gb 8=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: cja57WEcbFOEYparK8ju57BtnXLfIikixueAnbn7MDigsNkxM3L9XF6XluqH2rAiLUDrVRY6hh
 U7pupfDbdlzr/fPal/4yi6DkFMSR48uNazqy3nibOFE0bEtNMEcYdXId5ivWT5YgFGdjLCAgBl
 JNn6Fm6BiN4tbYc2oGi4Mn+wzIFhwVyXcwIN13W62mA0xBpVMkAnc2Utg9i5q+k3X2MBgm/9En
 IqX4kbCZP5JzOAHnRvfQNel92thTHJjOdPxMGH9OwU+K4VDKO96XR5nw43jd36ByTwhzZt/k40
 snY=
X-SBRS: 2.7
X-MesageID: 16416379
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,410,1580792400"; d="scan'208";a="16416379"
Date: Tue, 21 Apr 2020 18:42:27 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH OSSTEST v3 2/2] make-flight: add a core scheduling job
Message-ID: <20200421164227.GX28601@Air-de-Roger>
References: <20200415141009.10912-1-roger.pau@citrix.com>
 <20200415141009.10912-2-roger.pau@citrix.com>
 <24223.8666.764943.818163@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <24223.8666.764943.818163@mariner.uk.xensource.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 05:39:54PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH OSSTEST v3 2/2] make-flight: add a core scheduling job"):
> > Run a simple core scheduling tests on a host that has SMT support.
> > This is only enabled for Xen >= 4.13.
> 
> Thanks, pushed to pretest.
> 
> Once it makes it through staging the test will appear, but it will
> start failing (nonblockingly) until the SMT hostflag has been scanned.
> It would be sensible for me to run a special examine job for that.

Yes, I think so. Will try to keep an eye and ping you when it passes
osstest self push gate.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 17:30:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 17:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQwj5-0005rU-Nx; Tue, 21 Apr 2020 17:30:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Zbep=6F=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jQwj5-0005rP-55
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 17:30:27 +0000
X-Inumbo-ID: c8fe2833-83f5-11ea-9175-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c8fe2833-83f5-11ea-9175-12813bfff9fa;
 Tue, 21 Apr 2020 17:30:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587490225;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=rTyg5GkSCEnmbYmkqxtD0tdi7bqwJ71vNPKBP0QsvuU=;
 b=To55zwlN2IL4hRMtuFInAXNt8DaRvDvkhDxixVzY0jEBbDEAzIqvU7wJ
 ZneYpSrEqMcDqQA7rRY0u0hyzJDfBIJGUk5RFFkVkXWfNBSm3GlwI1iLT
 yhQkDXSqEMelbPNuhKFZeImEKGdn8C5VjL0c6XbrQ0uco/k9oAbpmWMEZ I=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 8+wPFDfQSk/Nl84ZXfpS+QeVyRlOobvkreTY7CtgKDs9nFYoFzojVmfRbi8htLxThPATd/gqTz
 e1ubtSBNiiqtOEByK9Qfpss7DfTjZHESjaFnHAVBl+p0zmaEX712KQ09AKR+rgAH1NDKDMLwmY
 bWnP4hcbgPcZ5Xd1R8QdJiSgWs8F4ItMyd129lIfiqqVs+PWGPXBtDVmhioFvA2WpLDk+aYiDg
 10YIGf7JFTP37rfAiaafgL7sFLcQQ5chwYB0uyyMAxt1+FuAJGqLKw85HGB51whdELvDGZftPb
 LGE=
X-SBRS: 2.7
X-MesageID: 16335694
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,411,1580792400"; d="scan'208";a="16335694"
Date: Tue, 21 Apr 2020 19:30:10 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
Message-ID: <20200421173010.GY28601@Air-de-Roger>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
> First of all avoid excessive conversions. copy_{from,to}_guest(), for
> example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().

I'm not sure I understand the difference between those two, as they
are both placeholders for linear guest addresses?

AFAICT XEN_GUEST_HANDLE should be used for guest pointers inside of an
hypercall struct, while XEN_GUEST_HANDLE_PARAM is for guest pointers
as hypercall arguments. But those are both just guest pointers,
whether they are a parameter to the hypercall or a field in a
struct, and hence could use the same type?

I assume there's some reason for not doing so, and I see the comment
about other arches, but again a linear guest address is just that in
all arches, regardless of it's placement.

Sorry, this is likely tangential to your patch.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 17:47:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 17:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQwzp-0006vd-Am; Tue, 21 Apr 2020 17:47:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=90sK=6F=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jQwzn-0006vT-Qz
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 17:47:43 +0000
X-Inumbo-ID: 31087b56-83f8-11ea-83d8-bc764e2007e4
Received: from mga05.intel.com (unknown [192.55.52.43])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 31087b56-83f8-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 17:47:40 +0000 (UTC)
IronPort-SDR: JE9TpcU4QlJWKqwxr3OFG/YzqwowviewmsH2SbADTjAZr9GfmOh29EKEvNX6DkctmvSHHrwjbk
 1qASJl1YjMGA==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 21 Apr 2020 10:47:36 -0700
IronPort-SDR: wBVR3z0/sLsC3KSTsMXGmFRUIaGWcXVxAM9deXXi52CWdyeipYad+yI1YjlN/yyoemnBubAEqu
 cC+rF4Uig2GA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,411,1580803200"; d="scan'208";a="300680740"
Received: from tlengyel-mobl2.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.17.85])
 by FMSMGA003.fm.intel.com with ESMTP; 21 Apr 2020 10:47:35 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v16 1/3] mem_sharing: fix sharability check during fork reset
Date: Tue, 21 Apr 2020 10:47:23 -0700
Message-Id: <8eb756357cb6d9222ed7ec4c0af58473160361a1.1587490511.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <cover.1587490511.git.tamas.lengyel@intel.com>
References: <cover.1587490511.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

When resetting a VM fork we ought to only remove pages that were allocated for
the fork during it's execution and the contents copied over from the parent.
This can be determined if the page is sharable as special pages used by the
fork for other purposes will not pass this test. Unfortunately during the fork
reset loop we only partially check whether that's the case. A page's type may
indicate it is sharable (pass p2m_is_sharable) but that's not a sufficient
check by itself. All checks that are normally performed before a page is
converted to the sharable type need to be performed to avoid removing pages
from the p2m that may be used for other purposes. For example, currently the
reset loop also removes the vcpu info pages from the p2m, potentially putting
the guest into infinite page-fault loops.

For this we extend the existing nominate_page and page_make_sharable functions
to perform a validation-only run without actually converting the page.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
 xen/arch/x86/mm/mem_sharing.c | 79 ++++++++++++++++++++++-------------
 1 file changed, 50 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index e572e9e39d..d8ed660abb 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -633,31 +633,35 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
 /* Functions that change a page's type and ownership */
 static int page_make_sharable(struct domain *d,
                               struct page_info *page,
-                              int expected_refcnt)
+                              int expected_refcnt,
+                              bool validate_only)
 {
-    bool_t drop_dom_ref;
+    int rc;
+    bool drop_dom_ref = false;
 
-    spin_lock(&d->page_alloc_lock);
+    /* caller already has the lock when validating only */
+    if ( !validate_only )
+        spin_lock(&d->page_alloc_lock);
 
     if ( d->is_dying )
     {
-        spin_unlock(&d->page_alloc_lock);
-        return -EBUSY;
+        rc = -EBUSY;
+        goto out;
     }
 
     /* Change page type and count atomically */
     if ( !get_page_and_type(page, d, PGT_shared_page) )
     {
-        spin_unlock(&d->page_alloc_lock);
-        return -EINVAL;
+        rc = -EINVAL;
+        goto out;
     }
 
     /* Check it wasn't already sharable and undo if it was */
     if ( (page->u.inuse.type_info & PGT_count_mask) != 1 )
     {
-        spin_unlock(&d->page_alloc_lock);
         put_page_and_type(page);
-        return -EEXIST;
+        rc = -EEXIST;
+        goto out;
     }
 
     /*
@@ -666,20 +670,31 @@ static int page_make_sharable(struct domain *d,
      */
     if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
     {
-        spin_unlock(&d->page_alloc_lock);
         /* Return type count back to zero */
         put_page_and_type(page);
-        return -E2BIG;
+        rc = -E2BIG;
+        goto out;
+    }
+
+    rc = 0;
+
+    if ( validate_only )
+    {
+        put_page_and_type(page);
+        goto out;
     }
 
     page_set_owner(page, dom_cow);
     drop_dom_ref = !domain_adjust_tot_pages(d, -1);
     page_list_del(page, &d->page_list);
-    spin_unlock(&d->page_alloc_lock);
 
+out:
+    if ( !validate_only )
+        spin_unlock(&d->page_alloc_lock);
     if ( drop_dom_ref )
         put_domain(d);
-    return 0;
+
+    return rc;
 }
 
 static int page_make_private(struct domain *d, struct page_info *page)
@@ -809,8 +824,8 @@ static int debug_gref(struct domain *d, grant_ref_t ref)
     return debug_gfn(d, gfn);
 }
 
-static int nominate_page(struct domain *d, gfn_t gfn,
-                         int expected_refcnt, shr_handle_t *phandle)
+static int nominate_page(struct domain *d, gfn_t gfn, int expected_refcnt,
+                         bool validate_only, shr_handle_t *phandle)
 {
     struct p2m_domain *hp2m = p2m_get_hostp2m(d);
     p2m_type_t p2mt;
@@ -879,8 +894,8 @@ static int nominate_page(struct domain *d, gfn_t gfn,
     }
 
     /* Try to convert the mfn to the sharable type */
-    ret = page_make_sharable(d, page, expected_refcnt);
-    if ( ret )
+    ret = page_make_sharable(d, page, expected_refcnt, validate_only);
+    if ( ret || validate_only )
         goto out;
 
     /*
@@ -1392,13 +1407,13 @@ static int range_share(struct domain *d, struct domain *cd,
          * We only break out if we run out of memory as individual pages may
          * legitimately be unsharable and we just want to skip over those.
          */
-        rc = nominate_page(d, _gfn(start), 0, &sh);
+        rc = nominate_page(d, _gfn(start), 0, false, &sh);
         if ( rc == -ENOMEM )
             break;
 
         if ( !rc )
         {
-            rc = nominate_page(cd, _gfn(start), 0, &ch);
+            rc = nominate_page(cd, _gfn(start), 0, false, &ch);
             if ( rc == -ENOMEM )
                 break;
 
@@ -1476,7 +1491,7 @@ int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
         /* For read-only accesses we just add a shared entry to the physmap */
         while ( parent )
         {
-            if ( !(rc = nominate_page(parent, gfn, 0, &handle)) )
+            if ( !(rc = nominate_page(parent, gfn, 0, false, &handle)) )
                 break;
 
             parent = parent->parent;
@@ -1773,16 +1788,22 @@ static int mem_sharing_fork_reset(struct domain *d, struct domain *pd)
     spin_lock_recursive(&d->page_alloc_lock);
     page_list_for_each_safe(page, tmp, &d->page_list)
     {
-        p2m_type_t p2mt;
-        p2m_access_t p2ma;
+        shr_handle_t sh;
         mfn_t mfn = page_to_mfn(page);
         gfn_t gfn = mfn_to_gfn(d, mfn);
 
-        mfn = __get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
-                                    0, NULL, false);
-
-        /* only reset pages that are sharable */
-        if ( !p2m_is_sharable(p2mt) )
+        /*
+         * We only want to remove pages from the fork here that were copied
+         * from the parent but could be potentially re-populated using memory
+         * sharing after the reset. These pages all must be regular pages with
+         * no extra reference held to them, thus should be possible to make
+         * them sharable. Unfortunately p2m_is_sharable check is not sufficient
+         * to test this as it doesn't check the page's reference count. We thus
+         * check whether the page is convertable to the shared type using
+         * nominate_page. In case the page is already shared (ie. a share
+         * handle is returned) then we don't remove it.
+         */
+        if ( (rc = nominate_page(d, gfn, 0, true, &sh)) || sh )
             continue;
 
         /* take an extra reference or just skip if can't for whatever reason */
@@ -1836,7 +1857,7 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
     {
         shr_handle_t handle;
 
-        rc = nominate_page(d, _gfn(mso.u.nominate.u.gfn), 0, &handle);
+        rc = nominate_page(d, _gfn(mso.u.nominate.u.gfn), 0, false, &handle);
         mso.u.nominate.handle = handle;
     }
     break;
@@ -1851,7 +1872,7 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
         if ( rc < 0 )
             goto out;
 
-        rc = nominate_page(d, gfn, 3, &handle);
+        rc = nominate_page(d, gfn, 3, false, &handle);
         mso.u.nominate.handle = handle;
     }
     break;
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 17:47:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 17:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQwzp-0006vj-KH; Tue, 21 Apr 2020 17:47:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=90sK=6F=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jQwzo-0006vY-Ac
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 17:47:44 +0000
X-Inumbo-ID: 2fc05a3e-83f8-11ea-9177-12813bfff9fa
Received: from mga05.intel.com (unknown [192.55.52.43])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2fc05a3e-83f8-11ea-9177-12813bfff9fa;
 Tue, 21 Apr 2020 17:47:39 +0000 (UTC)
IronPort-SDR: 1X6RjqN38W3xfluhUPJFVo+slI69vGDR5mpbseiMndfvSlixYr14sijk0GthrlUaYTmEwKregV
 PLtac/Pf6tzw==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 21 Apr 2020 10:47:35 -0700
IronPort-SDR: 3YJc4GWZuxL0qpKOjiZXrT/0eFBNlH7Tj7rsDOXA5kav9/5APtMhvFaseCnbQo2lEZ6s/n2zLH
 r9SElV567KUg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,411,1580803200"; d="scan'208";a="300680735"
Received: from tlengyel-mobl2.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.17.85])
 by FMSMGA003.fm.intel.com with ESMTP; 21 Apr 2020 10:47:34 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v16 0/3] VM forking
Date: Tue, 21 Apr 2020 10:47:22 -0700
Message-Id: <cover.1587490511.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>,
 Anthony PERARD <anthony.perard@citrix.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The following patches are part of the series that implement VM forking for
Intel HVM guests to allow for the fast creation of identical VMs without the
assosciated high startup costs of booting or restoring the VM from a savefile.

JIRA issue: https://xenproject.atlassian.net/browse/XEN-89

The fork operation is implemented as part of the "xl fork-vm" command:
    xl fork-vm -C <config> -Q <qemu-save-file> -m <max-vcpus> <parent_domid>
    
By default a fully functional fork is created. The user is in charge however to
create the appropriate config file for the fork and to generate the QEMU save
file before the fork-vm call is made. The config file needs to give the
fork a new name at minimum but other settings may also require changes. Certain
settings in the config file of both the parent and the fork have to be set to
default. Details are documented.

The interface also allows to split the forking into two steps:
    xl fork-vm --launch-dm no \
               -m <max-vcpus> \
               -p <parent_domid>
    xl fork-vm --launch-dm late \
               -C <config_file_for_fork> \
               -Q <qemu_save_file> \
               <fork_domid>

The split creation model is useful when the VM needs to be created as fast as
possible. The forked VM can be unpaused without the device model being launched
to be monitored and accessed via VMI. Note however that without its device
model running (depending on what is executing in the VM) it is bound to
misbehave or even crash when its trying to access devices that would be
emulated by QEMU. We anticipate that for certain use-cases this would be an
acceptable situation, in case for example when fuzzing is performed of code
segments that don't access such devices.

Launching the device model requires the QEMU Xen savefile to be generated
manually from the parent VM. This can be accomplished simply by connecting to
its QMP socket and issuing the "xen-save-devices-state" command. For example
using the standard tool socat these commands can be used to generate the file:
    socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-<parent_domid>
    { "execute": "qmp_capabilities" }
    { "execute": "xen-save-devices-state", \
        "arguments": { "filename": "/path/to/save/qemu_state", \
                        "live": false} }

At runtime the forked VM starts running with an empty p2m which gets lazily
populated when the VM generates EPT faults, similar to how altp2m views are
populated. If the memory access is a read-only access, the p2m entry is
populated with a memory shared entry with its parent. For write memory accesses
or in case memory sharing wasn't possible (for example in case a reference is
held by a third party), a new page is allocated and the page contents are
copied over from the parent VM. Forks can be further forked if needed, thus
allowing for further memory savings.

A VM fork reset hypercall is also added that allows the fork to be reset to the
state it was just after a fork, also accessible via xl:
    xl fork-vm --fork-reset -p <fork_domid>

This is an optimization for cases where the forks are very short-lived and run
without a device model, so resetting saves some time compared to creating a
brand new fork provided the fork has not aquired a lot of memory. If the fork
has a lot of memory deduplicated it is likely going to be faster to create a
new fork from scratch and asynchronously destroying the old one.

The series has been tested with Windows VMs and functions as expected. Linux
VMs when forked from a running VM will have a frozen VNC screen. Linux VMs at
this time can only be forked with a working device model when the parent VM was
restored from a snapshot using "xl restore -p". This is a known limitation.
Also note that PVHVM/PVH Linux guests have not been tested. Forking most likely
works but PV devices and drivers would require additional wiring to set things
up properly since the guests are unaware of the forking taking place, unlike
the save/restore routine where the guest is made aware of the procedure.

Forking time has been measured to be 0.0007s, device model launch to be around
1s depending largely on the number of devices being emulated. Fork resets have
been measured to be 0.0001s under the optimal circumstances.

New in v16:
    A better bugfix for fork reset issue
    Minor fixes for the IOMMU allow patch based on feedback

Patch 1 fix for VM fork reset removing pages from the p2m that it shouldn't
Patch 2 adds option to fork a domain with IOMMU active
Patch 3 adds the toolstack-side code implementing VM forking and reset

Tamas K Lengyel (3):
  mem_sharing: fix sharability check during fork reset
  mem_sharing: allow forking domain with IOMMU enabled
  xen/tools: VM forking toolstack side

 docs/man/xl.1.pod.in          |  44 +++++
 tools/libxc/include/xenctrl.h |  14 ++
 tools/libxc/xc_memshr.c       |  26 +++
 tools/libxl/libxl.h           |  12 ++
 tools/libxl/libxl_create.c    | 361 +++++++++++++++++++---------------
 tools/libxl/libxl_dm.c        |   2 +-
 tools/libxl/libxl_dom.c       |  43 +++-
 tools/libxl/libxl_internal.h  |   7 +
 tools/libxl/libxl_types.idl   |   1 +
 tools/libxl/libxl_x86.c       |  42 ++++
 tools/xl/Makefile             |   2 +-
 tools/xl/xl.h                 |   5 +
 tools/xl/xl_cmdtable.c        |  15 ++
 tools/xl/xl_forkvm.c          | 149 ++++++++++++++
 tools/xl/xl_vmcontrol.c       |  14 ++
 xen/arch/x86/mm/mem_sharing.c |  99 ++++++----
 xen/include/public/memory.h   |   4 +-
 17 files changed, 637 insertions(+), 203 deletions(-)
 create mode 100644 tools/xl/xl_forkvm.c

-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 17:47:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 17:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQwzu-0006wT-24; Tue, 21 Apr 2020 17:47:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=90sK=6F=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jQwzs-0006wF-F4
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 17:47:48 +0000
X-Inumbo-ID: 33f23b36-83f8-11ea-83d8-bc764e2007e4
Received: from mga05.intel.com (unknown [192.55.52.43])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 33f23b36-83f8-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 17:47:43 +0000 (UTC)
IronPort-SDR: wof1HeqO93luk6GBbvgWUUrJjVgMNtdj56lQCpmaPrOlvbmpdkBUcSsqDPpwhVB2A3enGDJHW5
 vdhh3Lla36WA==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 21 Apr 2020 10:47:38 -0700
IronPort-SDR: v+zuVKiGGBtEq1BGefKamc33QP6S5dAcn7QFqCJfNqBUp0a5boH4nGoMSt6m8EeAUuDGo2fwV5
 Y1+fO29dHnPQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,411,1580803200"; d="scan'208";a="300680743"
Received: from tlengyel-mobl2.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.17.85])
 by FMSMGA003.fm.intel.com with ESMTP; 21 Apr 2020 10:47:36 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v16 2/3] mem_sharing: allow forking domain with IOMMU enabled
Date: Tue, 21 Apr 2020 10:47:24 -0700
Message-Id: <c958f3776e602143efb2fb7c146a0c18a3fcd262.1587490511.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <cover.1587490511.git.tamas.lengyel@intel.com>
References: <cover.1587490511.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The memory sharing subsystem by default doesn't allow a domain to share memory
if it has an IOMMU active for obvious security reasons. However, when fuzzing a
VM fork, the same security restrictions don't necessarily apply. While it makes
no sense to try to create a full fork of a VM that has an IOMMU attached as only
one domain can own the pass-through device at a time, creating a shallow fork
without a device model is still very useful for fuzzing kernel-mode drivers.

By allowing the parent VM to initialize the kernel-mode driver with a real
device that's pass-through, the driver can enter into a state more suitable for
fuzzing. Some of these initialization steps are quite complex and are easier to
perform when a real device is present. After the initialization, shallow forks
can be utilized for fuzzing code-segments in the device driver that don't
directly interact with the device.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
v16: Minor fixes based on feedback
---
 xen/arch/x86/mm/mem_sharing.c | 20 +++++++++++++-------
 xen/include/public/memory.h   |  4 +++-
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index d8ed660abb..e690d2fa13 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1445,7 +1445,8 @@ static int range_share(struct domain *d, struct domain *cd,
     return rc;
 }
 
-static inline int mem_sharing_control(struct domain *d, bool enable)
+static inline int mem_sharing_control(struct domain *d, bool enable,
+                                      uint16_t flags)
 {
     if ( enable )
     {
@@ -1455,7 +1456,8 @@ static inline int mem_sharing_control(struct domain *d, bool enable)
         if ( unlikely(!hap_enabled(d)) )
             return -ENODEV;
 
-        if ( unlikely(is_iommu_enabled(d)) )
+        if ( unlikely(is_iommu_enabled(d) &&
+                      !(flags & XENMEM_FORK_WITH_IOMMU_ALLOWED)) )
             return -EXDEV;
     }
 
@@ -1848,7 +1850,8 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
     if ( rc )
         goto out;
 
-    if ( !mem_sharing_enabled(d) && (rc = mem_sharing_control(d, true)) )
+    if ( !mem_sharing_enabled(d) &&
+         (rc = mem_sharing_control(d, true, 0)) )
         return rc;
 
     switch ( mso.op )
@@ -2086,7 +2089,9 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
         struct domain *pd;
 
         rc = -EINVAL;
-        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[2] )
+        if ( mso.u.fork.pad )
+            goto out;
+        if ( mso.u.fork.flags & ~XENMEM_FORK_WITH_IOMMU_ALLOWED )
             goto out;
 
         rc = rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_domain,
@@ -2101,7 +2106,8 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
             goto out;
         }
 
-        if ( !mem_sharing_enabled(pd) && (rc = mem_sharing_control(pd, true)) )
+        if ( !mem_sharing_enabled(pd) &&
+             (rc = mem_sharing_control(pd, true, mso.u.fork.flags)) )
         {
             rcu_unlock_domain(pd);
             goto out;
@@ -2122,7 +2128,7 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
         struct domain *pd;
 
         rc = -EINVAL;
-        if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[2] )
+        if ( mso.u.fork.pad || mso.u.fork.flags )
             goto out;
 
         rc = -ENOSYS;
@@ -2159,7 +2165,7 @@ int mem_sharing_domctl(struct domain *d, struct xen_domctl_mem_sharing_op *mec)
     switch ( mec->op )
     {
     case XEN_DOMCTL_MEM_SHARING_CONTROL:
-        rc = mem_sharing_control(d, mec->u.enable);
+        rc = mem_sharing_control(d, mec->u.enable, 0);
         break;
 
     default:
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index d36d64b8dc..e56800357d 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -536,7 +536,9 @@ struct xen_mem_sharing_op {
         } debug;
         struct mem_sharing_op_fork {      /* OP_FORK */
             domid_t parent_domain;        /* IN: parent's domain id */
-            uint16_t pad[3];              /* Must be set to 0 */
+#define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0)
+            uint16_t flags;               /* IN: optional settings */
+            uint32_t pad;                 /* Must be set to 0 */
         } fork;
     } u;
 };
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 17:47:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 17:47:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQwzx-0006xZ-BC; Tue, 21 Apr 2020 17:47:53 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=90sK=6F=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jQwzv-0006xE-KQ
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 17:47:51 +0000
X-Inumbo-ID: 345c093a-83f8-11ea-9177-12813bfff9fa
Received: from mga05.intel.com (unknown [192.55.52.43])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 345c093a-83f8-11ea-9177-12813bfff9fa;
 Tue, 21 Apr 2020 17:47:44 +0000 (UTC)
IronPort-SDR: uFFlZ9pIZc+rqPB7o5QKcO2RNerZPWnsJcB1wAVJd264ACqLsWYCNlz4XYYftJknUO30nZmxu+
 F65QWKMNdWxg==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 21 Apr 2020 10:47:39 -0700
IronPort-SDR: FAIX96XgdaGaxmq/k6y2vZmz6LK7MbjbG8nVw3iGlCXnIyXN3z30IN48eDI/5t10Hx1nAtnIYW
 iPhHAwCg64cQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,411,1580803200"; d="scan'208";a="300680748"
Received: from tlengyel-mobl2.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.17.85])
 by FMSMGA003.fm.intel.com with ESMTP; 21 Apr 2020 10:47:38 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v16 3/3] xen/tools: VM forking toolstack side
Date: Tue, 21 Apr 2020 10:47:25 -0700
Message-Id: <1f411b499c98393786a91baf3b8ac0e0d5c6b109.1587490511.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <cover.1587490511.git.tamas.lengyel@intel.com>
References: <cover.1587490511.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
 docs/man/xl.1.pod.in          |  44 +++++
 tools/libxc/include/xenctrl.h |  14 ++
 tools/libxc/xc_memshr.c       |  26 +++
 tools/libxl/libxl.h           |  12 ++
 tools/libxl/libxl_create.c    | 361 +++++++++++++++++++---------------
 tools/libxl/libxl_dm.c        |   2 +-
 tools/libxl/libxl_dom.c       |  43 +++-
 tools/libxl/libxl_internal.h  |   7 +
 tools/libxl/libxl_types.idl   |   1 +
 tools/libxl/libxl_x86.c       |  42 ++++
 tools/xl/Makefile             |   2 +-
 tools/xl/xl.h                 |   5 +
 tools/xl/xl_cmdtable.c        |  15 ++
 tools/xl/xl_forkvm.c          | 149 ++++++++++++++
 tools/xl/xl_vmcontrol.c       |  14 ++
 15 files changed, 571 insertions(+), 166 deletions(-)
 create mode 100644 tools/xl/xl_forkvm.c

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 09339282e6..59c03c6427 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -708,6 +708,50 @@ above).
 
 =back
 
+=item B<fork-vm> [I<OPTIONS>] I<domain-id>
+
+Create a fork of a running VM.  The domain will be paused after the operation
+and remains paused while forks of it exist.  Experimental and x86 only.
+Forks can only be made of domains with HAP enabled and on Intel hardware.  The
+parent domain must be created with the xl toolstack and its configuration must
+not manually define max_grant_frames, max_maptrack_frames or max_event_channels.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-p>
+
+Leave the fork paused after creating it.
+
+=item B<--launch-dm>
+
+Specify whether the device model (QEMU) should be launched for the fork. Late
+launch allows to start the device model for an already running fork.
+
+=item B<-C>
+
+The config file to use when launching the device model.  Currently required when
+launching the device model.  Most config settings MUST match the parent domain
+exactly, only change VM name, disk path and network configurations.
+
+=item B<-Q>
+
+The path to the qemu save file to use when launching the device model.  Currently
+required when launching the device model.
+
+=item B<--fork-reset>
+
+Perform a reset operation of an already running fork.  Note that resetting may
+be less performant then creating a new fork depending on how much memory the
+fork has deduplicated during its runtime.
+
+=item B<--max-vcpus>
+
+Specify the max-vcpus matching the parent domain when not launching the dm.
+
+=back
+
 =item B<sharing> [I<domain-id>]
 
 Display the number of shared pages for a specified domain. If no domain is
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 5f25c5a6d4..0a6ff93229 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2232,6 +2232,20 @@ int xc_memshr_range_share(xc_interface *xch,
                           uint64_t first_gfn,
                           uint64_t last_gfn);
 
+int xc_memshr_fork(xc_interface *xch,
+                   uint32_t source_domain,
+                   uint32_t client_domain,
+                   bool allow_with_iommu);
+
+/*
+ * Note: this function is only intended to be used on short-lived forks that
+ * haven't yet aquired a lot of memory. In case the fork has a lot of memory
+ * it is likely more performant to create a new fork with xc_memshr_fork.
+ *
+ * With VMs that have a lot of memory this call may block for a long time.
+ */
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain);
+
 /* Debug calls: return the number of pages referencing the shared frame backing
  * the input argument. Should be one or greater.
  *
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index 97e2e6a8d9..2300cc7075 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -239,6 +239,32 @@ int xc_memshr_debug_gref(xc_interface *xch,
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid,
+                   bool allow_with_iommu)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_fork;
+    mso.u.fork.parent_domain = pdomid;
+
+    if ( allow_with_iommu )
+        mso.u.fork.flags |= XENMEM_FORK_WITH_IOMMU_ALLOWED;
+
+    return xc_memshr_memop(xch, domid, &mso);
+}
+
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+    mso.op = XENMEM_sharing_op_fork_reset;
+
+    return xc_memshr_memop(xch, domid, &mso);
+}
+
 int xc_memshr_audit(xc_interface *xch)
 {
     xen_mem_sharing_op_t mso;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 71709dc585..d8da347d4e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2666,6 +2666,18 @@ int libxl_psr_get_hw_info(libxl_ctx *ctx, libxl_psr_feat_type type,
                           unsigned int lvl, unsigned int *nr,
                           libxl_psr_hw_info **info);
 void libxl_psr_hw_info_list_free(libxl_psr_hw_info *list, unsigned int nr);
+
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid,
+                         bool allow_with_iommu)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                uint32_t domid,
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 #endif
 
 /* misc */
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e7cb2dbc2b..5705b6e3a5 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -538,12 +538,12 @@ out:
     return ret;
 }
 
-int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
-                       libxl__domain_build_state *state,
-                       uint32_t *domid, bool soft_reset)
+static int libxl__domain_make_xs_entries(libxl__gc *gc, libxl_domain_config *d_config,
+                                         libxl__domain_build_state *state,
+                                         uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, rc, nb_vm;
+    int rc, nb_vm;
     const char *dom_type;
     char *uuid_string;
     char *dom_path, *vm_path, *libxl_path;
@@ -555,9 +555,6 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     /* convenience aliases */
     libxl_domain_create_info *info = &d_config->c_info;
-    libxl_domain_build_info *b_info = &d_config->b_info;
-
-    assert(soft_reset || *domid == INVALID_DOMID);
 
     uuid_string = libxl__uuid2string(gc, info->uuid);
     if (!uuid_string) {
@@ -565,137 +562,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         goto out;
     }
 
-    if (!soft_reset) {
-        struct xen_domctl_createdomain create = {
-            .ssidref = info->ssidref,
-            .max_vcpus = b_info->max_vcpus,
-            .max_evtchn_port = b_info->event_channels,
-            .max_grant_frames = b_info->max_grant_frames,
-            .max_maptrack_frames = b_info->max_maptrack_frames,
-        };
-
-        if (info->type != LIBXL_DOMAIN_TYPE_PV) {
-            create.flags |= XEN_DOMCTL_CDF_hvm;
-            create.flags |=
-                libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
-            create.flags |=
-                libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
-        }
-
-        assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
-        LOG(DETAIL, "passthrough: %s",
-            libxl_passthrough_to_string(info->passthrough));
-
-        if (info->passthrough != LIBXL_PASSTHROUGH_DISABLED)
-            create.flags |= XEN_DOMCTL_CDF_iommu;
-
-        if (info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT)
-            create.iommu_opts |= XEN_DOMCTL_IOMMU_no_sharept;
-
-        /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
-        libxl_uuid_copy(ctx, (libxl_uuid *)&create.handle, &info->uuid);
-
-        ret = libxl__arch_domain_prepare_config(gc, d_config, &create);
-        if (ret < 0) {
-            LOGED(ERROR, *domid, "fail to get domain config");
-            rc = ERROR_FAIL;
-            goto out;
-        }
-
-        for (;;) {
-            uint32_t local_domid;
-            bool recent;
-
-            if (info->domid == RANDOM_DOMID) {
-                uint16_t v;
-
-                ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
-                if (ret < 0)
-                    break;
-
-                v &= DOMID_MASK;
-                if (!libxl_domid_valid_guest(v))
-                    continue;
-
-                local_domid = v;
-            } else {
-                local_domid = info->domid; /* May not be valid */
-            }
-
-            ret = xc_domain_create(ctx->xch, &local_domid, &create);
-            if (ret < 0) {
-                /*
-                 * If we generated a random domid and creation failed
-                 * because that domid already exists then simply try
-                 * again.
-                 */
-                if (errno == EEXIST && info->domid == RANDOM_DOMID)
-                    continue;
-
-                LOGED(ERROR, local_domid, "domain creation fail");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /* A new domain now exists */
-            *domid = local_domid;
-
-            rc = libxl__is_domid_recent(gc, local_domid, &recent);
-            if (rc)
-                goto out;
-
-            /* The domid is not recent, so we're done */
-            if (!recent)
-                break;
-
-            /*
-             * If the domid was specified then there's no point in
-             * trying again.
-             */
-            if (libxl_domid_valid_guest(info->domid)) {
-                LOGED(ERROR, local_domid, "domain id recently used");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /*
-             * The domain is recent and so cannot be used. Clear domid
-             * here since, if xc_domain_destroy() fails below there is
-             * little point calling it again in the error path.
-             */
-            *domid = INVALID_DOMID;
-
-            ret = xc_domain_destroy(ctx->xch, local_domid);
-            if (ret < 0) {
-                LOGED(ERROR, local_domid, "domain destroy fail");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /* The domain was successfully destroyed, so we can try again */
-        }
-
-        rc = libxl__arch_domain_save_config(gc, d_config, state, &create);
-        if (rc < 0)
-            goto out;
-    }
-
-    /*
-     * If soft_reset is set the the domid will have been valid on entry.
-     * If it was not set then xc_domain_create() should have assigned a
-     * valid value. Either way, if we reach this point, domid should be
-     * valid.
-     */
-    assert(libxl_domid_valid_guest(*domid));
-
-    ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
-    if (ret < 0) {
-        LOGED(ERROR, *domid, "domain move fail");
-        rc = ERROR_FAIL;
-        goto out;
-    }
-
-    dom_path = libxl__xs_get_dompath(gc, *domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         rc = ERROR_FAIL;
         goto out;
@@ -703,12 +570,12 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     vm_path = GCSPRINTF("/vm/%s", uuid_string);
     if (!vm_path) {
-        LOGD(ERROR, *domid, "cannot allocate create paths");
+        LOGD(ERROR, domid, "cannot allocate create paths");
         rc = ERROR_FAIL;
         goto out;
     }
 
-    libxl_path = libxl__xs_libxl_path(gc, *domid);
+    libxl_path = libxl__xs_libxl_path(gc, domid);
     if (!libxl_path) {
         rc = ERROR_FAIL;
         goto out;
@@ -719,10 +586,10 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     roperm[0].id = 0;
     roperm[0].perms = XS_PERM_NONE;
-    roperm[1].id = *domid;
+    roperm[1].id = domid;
     roperm[1].perms = XS_PERM_READ;
 
-    rwperm[0].id = *domid;
+    rwperm[0].id = domid;
     rwperm[0].perms = XS_PERM_NONE;
 
 retry_transaction:
@@ -740,7 +607,7 @@ retry_transaction:
                     noperm, ARRAY_SIZE(noperm));
 
     xs_write(ctx->xsh, t, GCSPRINTF("%s/vm", dom_path), vm_path, strlen(vm_path));
-    rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
+    rc = libxl__domain_rename(gc, domid, 0, info->name, t);
     if (rc)
         goto out;
 
@@ -830,7 +697,7 @@ retry_transaction:
 
     vm_list = libxl_list_vm(ctx, &nb_vm);
     if (!vm_list) {
-        LOGD(ERROR, *domid, "cannot get number of running guests");
+        LOGD(ERROR, domid, "cannot get number of running guests");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -854,7 +721,7 @@ retry_transaction:
             t = 0;
             goto retry_transaction;
         }
-        LOGED(ERROR, *domid, "domain creation ""xenstore transaction commit failed");
+        LOGED(ERROR, domid, "domain creation ""xenstore transaction commit failed");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -866,6 +733,155 @@ retry_transaction:
     return rc;
 }
 
+int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
+                       libxl__domain_build_state *state,
+                       uint32_t *domid, bool soft_reset)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret, rc;
+
+    /* convenience aliases */
+    libxl_domain_create_info *info = &d_config->c_info;
+    libxl_domain_build_info *b_info = &d_config->b_info;
+
+    assert(soft_reset || *domid == INVALID_DOMID);
+
+    if (!soft_reset) {
+        struct xen_domctl_createdomain create = {
+            .ssidref = info->ssidref,
+            .max_vcpus = b_info->max_vcpus,
+            .max_evtchn_port = b_info->event_channels,
+            .max_grant_frames = b_info->max_grant_frames,
+            .max_maptrack_frames = b_info->max_maptrack_frames,
+        };
+
+        if (info->type != LIBXL_DOMAIN_TYPE_PV) {
+            create.flags |= XEN_DOMCTL_CDF_hvm;
+            create.flags |=
+                libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+            create.flags |=
+                libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
+        }
+
+        assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
+        LOG(DETAIL, "passthrough: %s",
+            libxl_passthrough_to_string(info->passthrough));
+
+        if (info->passthrough != LIBXL_PASSTHROUGH_DISABLED)
+            create.flags |= XEN_DOMCTL_CDF_iommu;
+
+        if (info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT)
+            create.iommu_opts |= XEN_DOMCTL_IOMMU_no_sharept;
+
+        /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
+        libxl_uuid_copy(ctx, (libxl_uuid *)&create.handle, &info->uuid);
+
+        ret = libxl__arch_domain_prepare_config(gc, d_config, &create);
+        if (ret < 0) {
+            LOGED(ERROR, *domid, "fail to get domain config");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        for (;;) {
+            uint32_t local_domid;
+            bool recent;
+
+            if (info->domid == RANDOM_DOMID) {
+                uint16_t v;
+
+                ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
+                if (ret < 0)
+                    break;
+
+                v &= DOMID_MASK;
+                if (!libxl_domid_valid_guest(v))
+                    continue;
+
+                local_domid = v;
+            } else {
+                local_domid = info->domid; /* May not be valid */
+            }
+
+            ret = xc_domain_create(ctx->xch, &local_domid, &create);
+            if (ret < 0) {
+                /*
+                 * If we generated a random domid and creation failed
+                 * because that domid already exists then simply try
+                 * again.
+                 */
+                if (errno == EEXIST && info->domid == RANDOM_DOMID)
+                    continue;
+
+                LOGED(ERROR, local_domid, "domain creation fail");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* A new domain now exists */
+            *domid = local_domid;
+
+            rc = libxl__is_domid_recent(gc, local_domid, &recent);
+            if (rc)
+                goto out;
+
+            /* The domid is not recent, so we're done */
+            if (!recent)
+                break;
+
+            /*
+             * If the domid was specified then there's no point in
+             * trying again.
+             */
+            if (libxl_domid_valid_guest(info->domid)) {
+                LOGED(ERROR, local_domid, "domain id recently used");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /*
+             * The domain is recent and so cannot be used. Clear domid
+             * here since, if xc_domain_destroy() fails below there is
+             * little point calling it again in the error path.
+             */
+            *domid = INVALID_DOMID;
+
+            ret = xc_domain_destroy(ctx->xch, local_domid);
+            if (ret < 0) {
+                LOGED(ERROR, local_domid, "domain destroy fail");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* The domain was successfully destroyed, so we can try again */
+        }
+
+        rc = libxl__arch_domain_save_config(gc, d_config, state, &create);
+        if (rc < 0)
+            goto out;
+    }
+
+    /*
+     * If soft_reset is set the the domid will have been valid on entry.
+     * If it was not set then xc_domain_create() should have assigned a
+     * valid value. Either way, if we reach this point, domid should be
+     * valid.
+     */
+    assert(libxl_domid_valid_guest(*domid));
+
+    ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
+    if (ret < 0) {
+        LOGED(ERROR, *domid, "domain move fail");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl__domain_make_xs_entries(gc, d_config, state, *domid);
+
+out:
+    return rc;
+}
+
 static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
                              libxl_domain_build_info *b_info)
 {
@@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
     ret = libxl__domain_config_setdefault(gc,d_config,domid);
     if (ret) goto error_out;
 
-    ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
-                             dcs->soft_reset);
-    if (ret) {
-        LOGD(ERROR, domid, "cannot make domain: %d", ret);
+    if ( !d_config->dm_restore_file )
+    {
+        ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
+                                 dcs->soft_reset);
         dcs->guest_domid = domid;
+
+        if (ret) {
+            LOGD(ERROR, domid, "cannot make domain: %d", ret);
+            ret = ERROR_FAIL;
+            goto error_out;
+        }
+    } else if ( dcs->guest_domid != INVALID_DOMID ) {
+        domid = dcs->guest_domid;
+
+        ret = libxl__domain_make_xs_entries(gc, d_config, &dcs->build_state, domid);
+        if (ret) {
+            LOGD(ERROR, domid, "cannot make domain: %d", ret);
+            ret = ERROR_FAIL;
+            goto error_out;
+        }
+    } else {
+        LOGD(ERROR, domid, "cannot make domain");
         ret = ERROR_FAIL;
         goto error_out;
     }
 
-    dcs->guest_domid = domid;
     dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
 
     /* post-4.13 todo: move these next bits of defaulting to
@@ -1236,7 +1268,7 @@ static void initiate_domain_create(libxl__egc *egc,
     if (ret)
         goto error_out;
 
-    if (restore_fd >= 0 || dcs->soft_reset) {
+    if (restore_fd >= 0 || dcs->soft_reset || d_config->dm_restore_file) {
         LOGD(DEBUG, domid, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
     } else  {
@@ -1312,7 +1344,16 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->sdss.dm.callback = domcreate_devmodel_started;
     dcs->sdss.callback = domcreate_devmodel_started;
 
-    if (restore_fd < 0 && !dcs->soft_reset) {
+    if (restore_fd < 0 && !dcs->soft_reset && !d_config->dm_restore_file) {
+        rc = libxl__domain_build(gc, d_config, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    if ( d_config->dm_restore_file ) {
+        dcs->srs.dcs = dcs;
+        dcs->srs.ao = ao;
+        state->forked_vm = true;
         rc = libxl__domain_build(gc, d_config, domid, state);
         domcreate_rebuild_done(egc, dcs, rc);
         return;
@@ -1510,6 +1551,7 @@ static void domcreate_rebuild_done(libxl__egc *egc,
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
 
     if (ret) {
         LOGD(ERROR, domid, "cannot (re-)build domain: %d", ret);
@@ -1517,6 +1559,9 @@ static void domcreate_rebuild_done(libxl__egc *egc,
         goto error_out;
     }
 
+    if ( d_config->dm_restore_file )
+        state->saved_state = GCSPRINTF("%s", d_config->dm_restore_file);
+
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     libxl__multidev_begin(ao, &dcs->multidev);
@@ -1947,7 +1992,7 @@ static void domain_create_cb(libxl__egc *egc,
                              libxl__domain_create_state *dcs,
                              int rc, uint32_t domid);
 
-static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+int libxl__do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid, int restore_fd, int send_back_fd,
                             const libxl_domain_restore_params *params,
                             const libxl_asyncop_how *ao_how,
@@ -1960,6 +2005,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     GCNEW(cdcs);
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.guest_domid = *domid;
+
     libxl_domain_config_init(&cdcs->dcs.guest_config_saved);
     libxl_domain_config_copy(ctx, &cdcs->dcs.guest_config_saved, d_config);
     cdcs->dcs.restore_fd = cdcs->dcs.libxc_fd = restore_fd;
@@ -2204,8 +2251,8 @@ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             const libxl_asyncprogress_how *aop_console_how)
 {
     unset_disk_colo_restore(d_config);
-    return do_domain_create(ctx, d_config, domid, -1, -1, NULL,
-                            ao_how, aop_console_how);
+    return libxl__do_domain_create(ctx, d_config, domid, -1, -1, NULL,
+                                  ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
@@ -2221,8 +2268,8 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
         unset_disk_colo_restore(d_config);
     }
 
-    return do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
-                            params, ao_how, aop_console_how);
+    return libxl__do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
+                                   params, ao_how, aop_console_how);
 }
 
 int libxl_domain_soft_reset(libxl_ctx *ctx,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index f4007bbe50..b615f1fc88 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2803,7 +2803,7 @@ static void device_model_spawn_outcome(libxl__egc *egc,
 
     libxl__domain_build_state *state = dmss->build_state;
 
-    if (state->saved_state) {
+    if (state->saved_state && !state->forked_vm) {
         ret2 = unlink(state->saved_state);
         if (ret2) {
             LOGED(ERROR, dmss->guest_domid, "%s: failed to remove device-model state %s",
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 71cb578923..3bc7117b99 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -249,9 +249,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *xs_domid, *con_domid;
-    int rc;
+    int rc = 0;
     uint64_t size;
 
+    if ( state->forked_vm )
+        goto skip_fork;
+
     if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) {
         LOG(ERROR, "Couldn't set max vcpu count");
         return ERROR_FAIL;
@@ -362,7 +365,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         }
     }
 
-
     rc = libxl__arch_extra_memory(gc, info, &size);
     if (rc < 0) {
         LOGE(ERROR, "Couldn't get arch extra constant memory size");
@@ -374,6 +376,11 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         return ERROR_FAIL;
     }
 
+    rc = libxl__arch_domain_create(gc, d_config, domid);
+    if ( rc )
+        goto out;
+
+skip_fork:
     xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
     state->store_domid = xs_domid ? atoi(xs_domid) : 0;
     free(xs_domid);
@@ -385,8 +392,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
 
-    rc = libxl__arch_domain_create(gc, d_config, domid);
-
+out:
     return rc;
 }
 
@@ -444,6 +450,9 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char **ents;
     int i, rc;
 
+    if ( state->forked_vm )
+        goto skip_fork;
+
     if (info->num_vnuma_nodes && !info->num_vcpu_soft_affinity) {
         rc = set_vnuma_affinity(gc, domid, info);
         if (rc)
@@ -466,6 +475,7 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
         }
     }
 
+skip_fork:
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
@@ -728,14 +738,16 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
                                 int console_evtchn, unsigned long *console_mfn,
-                                domid_t store_domid, domid_t console_domid)
+                                domid_t store_domid, domid_t console_domid,
+                                bool forked_vm)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
     uint64_t str_mfn, cons_mfn;
     int i;
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if ( info->type == LIBXL_DOMAIN_TYPE_HVM && !forked_vm )
+    {
         va_map = xc_map_foreign_range(handle, domid,
                                       XC_PAGE_SIZE, PROT_READ | PROT_WRITE,
                                       HVM_INFO_PFN);
@@ -1051,6 +1063,23 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
     struct xc_dom_image *dom = NULL;
     bool device_model = info->type == LIBXL_DOMAIN_TYPE_HVM ? true : false;
 
+    if ( state->forked_vm )
+    {
+        rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
+                                  &state->store_mfn, state->console_port,
+                                  &state->console_mfn, state->store_domid,
+                                  state->console_domid, state->forked_vm);
+
+        if ( rc )
+            return rc;
+
+        return xc_dom_gnttab_seed(ctx->xch, domid, true,
+                                  state->console_mfn,
+                                  state->store_mfn,
+                                  state->console_domid,
+                                  state->store_domid);
+    }
+
     xc_dom_loginit(ctx->xch);
 
     /*
@@ -1175,7 +1204,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
     rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
                                &state->store_mfn, state->console_port,
                                &state->console_mfn, state->store_domid,
-                               state->console_domid);
+                               state->console_domid, false);
     if (rc != 0) {
         LOG(ERROR, "hvm build set params failed");
         goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5f39e44cb9..d05ff31e83 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1374,6 +1374,7 @@ typedef struct {
 
     char *saved_state;
     int dm_monitor_fd;
+    bool forked_vm;
 
     libxl__file_reference pv_kernel;
     libxl__file_reference pv_ramdisk;
@@ -4818,6 +4819,12 @@ _hidden int libxl__domain_pvcontrol(libxl__egc *egc,
 /* Check whether a domid is recent */
 int libxl__is_domid_recent(libxl__gc *gc, uint32_t domid, bool *recent);
 
+_hidden int libxl__do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                    uint32_t *domid, int restore_fd, int send_back_fd,
+                                    const libxl_domain_restore_params *params,
+                                    const libxl_asyncop_how *ao_how,
+                                    const libxl_asyncprogress_how *aop_console_how);
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7c473be74..2bb5e6319e 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -958,6 +958,7 @@ libxl_domain_config = Struct("domain_config", [
     ("on_watchdog", libxl_action_on_shutdown),
     ("on_crash", libxl_action_on_shutdown),
     ("on_soft_reset", libxl_action_on_shutdown),
+    ("dm_restore_file", string, {'const': True}),
     ], dir=DIR_IN)
 
 libxl_diskinfo = Struct("diskinfo", [
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index f8bc828e62..7a0bd62fa7 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -2,6 +2,7 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
+#include <xen-xsm/flask/flask.h>
 
 int libxl__arch_domain_prepare_config(libxl__gc *gc,
                                       libxl_domain_config *d_config,
@@ -842,6 +843,47 @@ int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
     return rc;
 }
 
+/*
+ * The parent domain is expected to be created with default settings for
+ * - max_evtch_port
+ * - max_grant_frames
+ * - max_maptrack_frames
+ */
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid,
+                         bool allow_with_iommu)
+{
+    int rc;
+    struct xen_domctl_createdomain create = {0};
+    create.flags |= XEN_DOMCTL_CDF_hvm;
+    create.flags |= XEN_DOMCTL_CDF_hap;
+    create.flags |= XEN_DOMCTL_CDF_oos_off;
+    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
+    create.ssidref = SECINITSID_DOMU;
+    create.max_vcpus = max_vcpus;
+    create.max_evtchn_port = 1023;
+    create.max_grant_frames = LIBXL_MAX_GRANT_FRAMES_DEFAULT;
+    create.max_maptrack_frames = LIBXL_MAX_MAPTRACK_FRAMES_DEFAULT;
+
+    if ( (rc = xc_domain_create(ctx->xch, domid, &create)) )
+        return rc;
+
+    if ( (rc = xc_memshr_fork(ctx->xch, pdomid, *domid, allow_with_iommu)) )
+        xc_domain_destroy(ctx->xch, *domid);
+
+    return rc;
+}
+
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                uint32_t domid,
+                                const libxl_asyncprogress_how *aop_console_how)
+{
+    return libxl__do_domain_create(ctx, d_config, &domid, -1, -1, 0, 0, aop_console_how);
+}
+
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid)
+{
+    return xc_memshr_fork_reset(ctx->xch, domid);
+}
 
 /*
  * Local variables:
diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index af4912e67a..073222233b 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -15,7 +15,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
 CFLAGS_XL += $(CFLAGS_libxenlight)
 CFLAGS_XL += -Wshadow
 
-XL_OBJS-$(CONFIG_X86) = xl_psr.o
+XL_OBJS-$(CONFIG_X86) = xl_psr.o xl_forkvm.o
 XL_OBJS = xl.o xl_cmdtable.o xl_sxp.o xl_utils.o $(XL_OBJS-y)
 XL_OBJS += xl_parse.o xl_cpupool.o xl_flask.o
 XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 06569c6c4a..1105c34b15 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -31,6 +31,7 @@ struct cmd_spec {
 };
 
 struct domain_create {
+    uint32_t ddomid; /* fork launch dm for this domid */
     int debug;
     int daemonize;
     int monitor; /* handle guest reboots etc */
@@ -45,6 +46,7 @@ struct domain_create {
     const char *config_file;
     char *extra_config; /* extra config string */
     const char *restore_file;
+    const char *dm_restore_file;
     char *colo_proxy_script;
     bool userspace_colo_proxy;
     int migrate_fd; /* -1 means none */
@@ -128,6 +130,8 @@ int main_pciassignable_remove(int argc, char **argv);
 int main_pciassignable_list(int argc, char **argv);
 #ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
 int main_restore(int argc, char **argv);
+int main_fork_launch_dm(int argc, char **argv);
+int main_fork_reset(int argc, char **argv);
 int main_migrate_receive(int argc, char **argv);
 int main_save(int argc, char **argv);
 int main_migrate(int argc, char **argv);
@@ -212,6 +216,7 @@ int main_psr_cat_cbm_set(int argc, char **argv);
 int main_psr_cat_show(int argc, char **argv);
 int main_psr_mba_set(int argc, char **argv);
 int main_psr_mba_show(int argc, char **argv);
+int main_fork_vm(int argc, char **argv);
 #endif
 int main_qemu_monitor_command(int argc, char **argv);
 
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 08335394e5..ef634abf32 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -187,6 +187,21 @@ struct cmd_spec cmd_table[] = {
       "Restore a domain from a saved state",
       "- for internal use only",
     },
+#if defined(__i386__) || defined(__x86_64__)
+    { "fork-vm",
+      &main_fork_vm, 0, 1,
+      "Fork a domain from the running parent domid. Experimental. Most config settings must match parent.",
+      "[options] <Domid>",
+      "-h                           Print this help.\n"
+      "-C <config>                  Use config file for VM fork.\n"
+      "-Q <qemu-save-file>          Use qemu save file for VM fork.\n"
+      "--launch-dm <yes|no|late>    Launch device model (QEMU) for VM fork.\n"
+      "--fork-reset                 Reset VM fork.\n"
+      "--max-vcpus                  Specify max-vcpus matching the parent domain when not launching dm\n"
+      "-p                           Do not unpause fork VM after operation.\n"
+      "-d                           Enable debug messages.\n"
+    },
+#endif
 #endif
     { "dump-core",
       &main_dump_core, 0, 1,
diff --git a/tools/xl/xl_forkvm.c b/tools/xl/xl_forkvm.c
new file mode 100644
index 0000000000..d40518fc59
--- /dev/null
+++ b/tools/xl/xl_forkvm.c
@@ -0,0 +1,149 @@
+/*
+ * Copyright 2020 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <sys/utsname.h>
+#include <time.h>
+#include <unistd.h>
+
+#include <libxl.h>
+#include <libxl_utils.h>
+#include <libxlutil.h>
+
+#include "xl.h"
+#include "xl_utils.h"
+#include "xl_parse.h"
+
+int main_fork_vm(int argc, char **argv)
+{
+    int rc, debug = 0;
+    uint32_t domid_in = INVALID_DOMID, domid_out = INVALID_DOMID;
+    int launch_dm = 1;
+    bool reset = 0;
+    bool pause = 0;
+    bool allow_iommu = 0;
+    const char *config_file = NULL;
+    const char *dm_restore_file = NULL;
+    uint32_t max_vcpus = 0;
+
+    int opt;
+    static struct option opts[] = {
+        {"launch-dm", 1, 0, 'l'},
+        {"fork-reset", 0, 0, 'r'},
+        {"max-vcpus", 1, 0, 'm'},
+        {"allow-iommu", 1, 0, 'i'},
+        COMMON_LONG_OPTS
+    };
+
+    SWITCH_FOREACH_OPT(opt, "phdC:Q:l:rm:i", opts, "fork-vm", 1) {
+    case 'd':
+        debug = 1;
+        break;
+    case 'p':
+        pause = 1;
+        break;
+    case 'm':
+        max_vcpus = atoi(optarg);
+        break;
+    case 'C':
+        config_file = optarg;
+        break;
+    case 'Q':
+        dm_restore_file = optarg;
+        break;
+    case 'l':
+        if ( !strcmp(optarg, "no") )
+            launch_dm = 0;
+        if ( !strcmp(optarg, "yes") )
+            launch_dm = 1;
+        if ( !strcmp(optarg, "late") )
+            launch_dm = 2;
+        break;
+    case 'r':
+        reset = 1;
+        break;
+    case 'i':
+        allow_iommu = 1;
+        break;
+    default:
+        fprintf(stderr, "Unimplemented option(s)\n");
+        return EXIT_FAILURE;
+    }
+
+    if (argc-optind == 1) {
+        domid_in = atoi(argv[optind]);
+    } else {
+        help("fork-vm");
+        return EXIT_FAILURE;
+    }
+
+    if (launch_dm && (!config_file || !dm_restore_file)) {
+        fprintf(stderr, "Currently you must provide both -C and -Q options\n");
+        return EXIT_FAILURE;
+    }
+
+    if (reset) {
+        domid_out = domid_in;
+        if (libxl_domain_fork_reset(ctx, domid_in) == EXIT_FAILURE)
+            return EXIT_FAILURE;
+    }
+
+    if (launch_dm == 2 || reset) {
+        domid_out = domid_in;
+        rc = EXIT_SUCCESS;
+    } else {
+        if ( !max_vcpus )
+        {
+            fprintf(stderr, "Currently you must parent's max_vcpu for this option\n");
+            return EXIT_FAILURE;
+        }
+
+        rc = libxl_domain_fork_vm(ctx, domid_in, max_vcpus, &domid_out, allow_iommu);
+    }
+
+    if (rc == EXIT_SUCCESS) {
+        if ( launch_dm ) {
+            struct domain_create dom_info;
+            memset(&dom_info, 0, sizeof(dom_info));
+            dom_info.ddomid = domid_out;
+            dom_info.dm_restore_file = dm_restore_file;
+            dom_info.debug = debug;
+            dom_info.paused = pause;
+            dom_info.config_file = config_file;
+            dom_info.migrate_fd = -1;
+            dom_info.send_back_fd = -1;
+            rc = create_domain(&dom_info) < 0 ? EXIT_FAILURE : EXIT_SUCCESS;
+        } else if ( !pause )
+            rc = libxl_domain_unpause(ctx, domid_out, NULL);
+    }
+
+    if (rc == EXIT_SUCCESS)
+        fprintf(stderr, "fork-vm command successfully returned domid: %u\n", domid_out);
+    else if ( domid_out != INVALID_DOMID )
+        libxl_domain_destroy(ctx, domid_out, 0);
+
+    return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 17b4514c94..c64123d0a1 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -676,6 +676,12 @@ int create_domain(struct domain_create *dom_info)
 
     int restoring = (restore_file || (migrate_fd >= 0));
 
+#if defined(__i386__) || defined(__x86_64__)
+    /* VM forking */
+    uint32_t ddomid = dom_info->ddomid; // launch dm for this domain iff set
+    const char *dm_restore_file = dom_info->dm_restore_file;
+#endif
+
     libxl_domain_config_init(&d_config);
 
     if (restoring) {
@@ -928,6 +934,14 @@ start:
          * restore/migrate-receive it again.
          */
         restoring = 0;
+#if defined(__i386__) || defined(__x86_64__)
+    } else if ( ddomid ) {
+        d_config.dm_restore_file = dm_restore_file;
+        ret = libxl_domain_fork_launch_dm(ctx, &d_config, ddomid,
+                                          autoconnect_console_how);
+        domid = ddomid;
+        ddomid = INVALID_DOMID;
+#endif
     } else if (domid_soft_reset != INVALID_DOMID) {
         /* Do soft reset. */
         ret = libxl_domain_soft_reset(ctx, &d_config, domid_soft_reset,
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 17:52:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 17:52:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQx4Z-00086O-8A; Tue, 21 Apr 2020 17:52:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Vwqf=6F=oracle.com=dan.carpenter@srs-us1.protection.inumbo.net>)
 id 1jQx4Y-00086J-8V
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 17:52:38 +0000
X-Inumbo-ID: e22df816-83f8-11ea-83d8-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e22df816-83f8-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 17:52:36 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03LHmYJX096737;
 Tue, 21 Apr 2020 17:52:29 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=date : from : to : cc
 : subject : message-id : references : mime-version : content-type :
 in-reply-to; s=corp-2020-01-29;
 bh=Gb8/bLuXjV1Ljp3couvoG3LVw9WMnRQZdKtizYgqvV0=;
 b=s0T1NKhXBkHfhF4J/h9RNAJlV2m/vMNEQAuA5pQdN+egk4GtuDJA6qZhBtfVkSlCyezV
 bAHSv7qngCX470G0LaK9ZT+JsV9ndJUMfIRfe8Ul7FhCjfDMS6qYFq+xSHIkj9zUCNOk
 y+948CrOTthzKc3sALfJhvAzabjT7TOuHP+x2iRw3jKs8O/zp5+/DSGQSa+drkyPpcUF
 /4Q8h4cMqfCzmIamZ/7paLiWutTm4SPNw0kZWuB1/rQLLeBFArhoyCFdDLhJUftyvSkA
 3NY9gSo3CZOkN4cP0j9r6UlZBdEe48LMFRC74/DcvOoLxtmm0uZlx7ygOfRd+Oa909WP Jg== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by aserp2120.oracle.com with ESMTP id 30fsgkxg3u-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 21 Apr 2020 17:52:28 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03LHlZIq138730;
 Tue, 21 Apr 2020 17:52:28 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by aserp3030.oracle.com with ESMTP id 30gb3skhse-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 21 Apr 2020 17:52:28 +0000
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03LHqR90031728;
 Tue, 21 Apr 2020 17:52:27 GMT
Received: from kadam (/41.57.98.10) by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 21 Apr 2020 10:52:26 -0700
Date: Tue, 21 Apr 2020 20:52:20 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Julia Lawall <julia.lawall@inria.fr>
Subject: Re: [bug report] drm/xen-front: Add support for Xen PV display
 frontend
Message-ID: <20200421175220.GE2659@kadam>
References: <20200421104522.GA86681@mwanda>
 <alpine.DEB.2.21.2004211728360.3118@hadrien>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.2004211728360.3118@hadrien>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9598
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 spamscore=0 adultscore=0
 mlxlogscore=999 phishscore=0 suspectscore=2 bulkscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004210137
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9598
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 priorityscore=1501
 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 clxscore=1015
 spamscore=0 bulkscore=0 phishscore=0 suspectscore=2 impostorscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004210137
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, kernel-janitors@vger.kernel.org,
 dri-devel@lists.freedesktop.org, oleksandr_andrushchenko@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 05:29:02PM +0200, Julia Lawall wrote:
> 
> 
> On Tue, 21 Apr 2020, Dan Carpenter wrote:
> 
> > Hi Kernel Janitors,
> >
> > Here is another idea that someone could work on, fixing the
> > IS_ERR_OR_NULL() checks in the xen driver.
> >
> > The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> > display frontend" from Apr 3, 2018, leads to the following static
> > checker warning:
> >
> > 	drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
> > 	warn: passing zero to 'ERR_CAST'
> >
> > drivers/gpu/drm/xen/xen_drm_front_gem.c
> >    133  struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
> >    134                                                  size_t size)
> >    135  {
> >    136          struct xen_gem_object *xen_obj;
> >    137
> >    138          xen_obj = gem_create(dev, size);
> >    139          if (IS_ERR_OR_NULL(xen_obj))
> >    140                  return ERR_CAST(xen_obj);
> 
> Are the other occurrences of this also a possible problem?  There are a
> few others outside of xen.

We sometimes check a parameter for IS_ERR_OR_NULL().

void free_function(struct something *p)
{
	if (IS_ERR_OR_NULL(p))
		return;
}

That's fine, absolutely harmless and not a bug.  But if we are checking
a return value like this then probably most of the time it's invalid
code.  Normally it's again like this code where we're dealing with an
impossible thing because the return is never NULL.  The common bugs are
that it returns NULL to a caller which only expects error pointers or it
returns success instead of failure.  But sometimes returning success can
be valid:

	obj = get_feature(dev);
	if (IS_ERR_OR_NULL(obj))
		return PTR_ERR(obj);

It deliberately returns success because the rest of the function is
useless when we don't have the feature.

regards,
dan carpenter



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 18:15:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 18:15:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQxQ4-0001bl-6X; Tue, 21 Apr 2020 18:14:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=mjY1=6F=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jQxQ2-0001bg-V7
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 18:14:51 +0000
X-Inumbo-ID: fd63d0d0-83fb-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fd63d0d0-83fb-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 18:14:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=BUQSDGsY7X+FbkqKnY8PnjumTMoguYbokFXCNyuivUk=; b=BvMUMuujAkZSRuDBRbAAUs+wS
 /S447ogYHyKRwHlSeuGJ8fCot5tyQuKNYfX5sXueZu+ercIE/pRkH/dZm+rBAZ2lnDHqGIIrrRAo9
 x81Zmxvf09A5V75xqeAIgRZHzxmkXUdcqdt1o4l9BAP6gIDUetBsp24ssQ5OnvGgfzO7E=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jQxQ1-0006Dn-Nf; Tue, 21 Apr 2020 18:14:49 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jQxQ1-0007VO-DD; Tue, 21 Apr 2020 18:14:49 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jQxQ1-0005qq-BE; Tue, 21 Apr 2020 18:14:49 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149720-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149720: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=4803a67114279a656a54a23cebed646da32efeb6
X-Osstest-Versions-That: xen=7aacf6ac49829d8dd6242f67460f4d52d0d36503
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 21 Apr 2020 18:14:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  4803a67114279a656a54a23cebed646da32efeb6
baseline version:
 xen                  7aacf6ac49829d8dd6242f67460f4d52d0d36503

Last test of basis   149713  2020-04-21 11:00:34 Z    0 days
Testing same since   149720  2020-04-21 16:02:16 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Wei Liu <wl@xen.org>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   7aacf6ac49..4803a67114  4803a67114279a656a54a23cebed646da32efeb6 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 18:21:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 18:21:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQxW7-0002Uq-Vd; Tue, 21 Apr 2020 18:21:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HO9m=6F=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jQxW6-0002Ul-1f
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 18:21:06 +0000
X-Inumbo-ID: dd077fc0-83fc-11ea-b58d-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id dd077fc0-83fc-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 18:21:05 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 6B16720679;
 Tue, 21 Apr 2020 18:21:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587493264;
 bh=4ftyYLUQ5gLpIK5wPScHNo813E3g44obj0E6BDW9s9o=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=bg14cRhRTyKeBPn70VZ4qmRGHfkjUGQDU1gjbCescZZlGgygDiCy6jr1fUyq77abo
 rJD0spRoHW5E9S+ZsiiJdYZX3KGvZp4GXjhApZCHtqU3lv4Ch7polpPTH8AcpKn6B7
 5NMPricgLOuaCpk8d5fo8rREMeTmPIAV5EB8Tz14=
Date: Tue, 21 Apr 2020 11:21:03 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v3] Introduce a description of the Backport and Fixes tags
In-Reply-To: <a4cfb801-f0c5-f08d-02fc-c35820bccd87@suse.com>
Message-ID: <alpine.DEB.2.21.2004211117160.24585@sstabellini-ThinkPad-T480s>
References: <20200417222430.20480-1-sstabellini@kernel.org>
 <35b34e2f-e6cd-6afc-19fd-c7880ec0eace@xen.org>
 <20200420102710.cg3bmjlntgpxqj77@debian>
 <a4cfb801-f0c5-f08d-02fc-c35820bccd87@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, konrad.wilk@oracle.com,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 george.dunlap@citrix.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, 20 Apr 2020, Jan Beulich wrote:
> On 20.04.2020 12:27, Wei Liu wrote:
> > On Mon, Apr 20, 2020 at 10:31:28AM +0100, Julien Grall wrote:
> >> On 17/04/2020 23:24, Stefano Stabellini wrote:
> >>> Create a new document under docs/process to describe our special tags.
> >>> Add a description of the Fixes tag and the new Backport tag. Also
> >>> clarify that lines with tags should not be split.
> >>>
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> >>> CC: Ian Jackson <ian.jackson@eu.citrix.com>
> >>> CC: Wei Liu <wl@xen.org>
> >>> CC: jbeulich@suse.com
> >>> CC: george.dunlap@citrix.com
> >>> CC: julien@xen.org
> >>> CC: lars.kurth@citrix.com
> >>> CC: andrew.cooper3@citrix.com
> >>> CC: konrad.wilk@oracle.com
> >>> ---
> >>> Removing Acks as I added the description of "Fixes"
> >>> ---
> >>>   docs/process/tags.pandoc | 55 ++++++++++++++++++++++++++++++++++++++++
> >>>   1 file changed, 55 insertions(+)
> >>>   create mode 100644 docs/process/tags.pandoc
> >>>
> >>> diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
> >>> new file mode 100644
> >>> index 0000000000..06b06dda01
> >>> --- /dev/null
> >>> +++ b/docs/process/tags.pandoc
> >>> @@ -0,0 +1,55 @@
> >>> +Tags: No line splitting
> >>> +-----------------------
> >>> +Do not split a tag across multiple lines, tags are exempt from the
> >>> +"wrap at 75 columns" rule in order to simplify parsing scripts.  For
> >>> +example:
> >>> +
> >>> +        Fixes: 67d01cdb5 ("x86: infrastructure to allow converting certain indirect calls to direct ones")
> >>
> >> The SHA-1 ID is 9 characters but...
> >>
> >>> +
> >>> +
> >>> +Fixes Tag
> >>> +---------
> >>> +
> >>> +If your patch fixes a bug in a specific commit, e.g. you found an issue using
> >>> +``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
> >>> +the SHA-1 ID, and the one line summary.
> >>
> >> ... you request 12 characters here. Can you make sure the two match please?
> >>
> >> However, I am not entirely sure why we should mandate 12 characters. With
> >> the title, you should always be able to find back the commit if there is a
> >> clash.
> > 
> > This is copied from Linux's document.
> > 
> > I normally use 8-9 characters, but I don't mind using 12 either.
> 
> Are they still saying 9? I've been asked to switch to 12 several
> weeks back ...

Yes, I just took it from Linux. I don't care 9 or 12. Given the
preference for 12, I'll keep 12 in the text and update the example to
match.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 18:22:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 18:22:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQxXo-0002bJ-DM; Tue, 21 Apr 2020 18:22:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HO9m=6F=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jQxXn-0002bE-GS
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 18:22:51 +0000
X-Inumbo-ID: 1bf97206-83fd-11ea-9180-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1bf97206-83fd-11ea-9180-12813bfff9fa;
 Tue, 21 Apr 2020 18:22:51 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 2162F20724;
 Tue, 21 Apr 2020 18:22:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587493370;
 bh=gFnveSCvSzdifyHd5GqGr2RENVOime36TyKZ9gRmTJM=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=jsYO6bUt27HdFXkvew/c74MjxnGnGwXH7noy+6LHtpcLUesv8ohCM09sO73/n3yVz
 75wZyz+m/x1V/t/gaS6H60fcXHkxQ74x04zLSTnk3Ovb2d47Gwih9YeLBBiv4dtvz+
 MWayd0Ju1uFGJz4S51affS4iPVbX4oNHXiYYZQx4=
Date: Tue, 21 Apr 2020 11:22:49 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v3] Introduce a description of the Backport and Fixes tags
In-Reply-To: <5d33d469-9aba-5285-766a-193d7109712d@suse.com>
Message-ID: <alpine.DEB.2.21.2004211117460.24585@sstabellini-ThinkPad-T480s>
References: <20200417222430.20480-1-sstabellini@kernel.org>
 <5d33d469-9aba-5285-766a-193d7109712d@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, Stefano Stabellini <sstabellini@kernel.org>,
 julien@xen.org, Wei Liu <wl@xen.org>, konrad.wilk@oracle.com,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 george.dunlap@citrix.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, 20 Apr 2020, Jan Beulich wrote:
> On 18.04.2020 00:24, Stefano Stabellini wrote:
> > +Backport Tag
> > +------------
> > +
> > +A backport tag is an optional tag in the commit message to request a
> > +given commit to be backported to the stable trees:
> > +
> > +    Backport: 4.9+
> > +
> > +It marks a commit for being a candidate for backports to all stable
> > +trees from 4.9 onward.
> 
> Using the wording "stable trees" may, to some, imply ones still
> under maintenance. How about omitting "stable", or replacing it
> by "released"?

OK


> > +The backport requester is expected to specify which currently supported
> > +releases need the backport; but encouraged to specify a release as far
> > +back as possible which applies. If the requester doesn't know the oldest
> > +affected tree, they are encouraged to append a comment like the
> > +following:
> > +
> > +    Backport: 4.9+ # maybe older
> > +
> > +Maintainers request the Backport tag to be added on commit. Contributors
> > +are welcome to mark their patches with the Backport tag when they deem
> > +appropriate. Maintainers will request for it to be removed when that is
> > +not the case.
> > +
> > +Please note that the Backport tag is a **request** for backport, which
> > +will still need to be evaluated by the stable tree maintainers.
> > +Maintainers might ask the requester to help with the backporting work if
> > +it is not trivial.
> > +
> > +When possible, please use the Fixes tag instead.
> 
> Maybe amend with "(or in addition)"? I'm thinking in particular
> about a case where a buggy change was already backported, but
> didn't show up yet in a release from the respective branch(es).

Sure


> Previously I did suggest to add an indication that people requesting
> backports should also be prepare to actually help with backporting.
> I don't recall a verbal reply, and I also don't see any respective
> update here. (I'm not fully trusting our mail system, i.e. it may
> very well be that I did miss a reply.)


I didn't reply, but I added two lines in that regards, see also above:

> > +Maintainers might ask the requester to help with the backporting work if
> > +it is not trivial.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 18:29:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 18:29:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQxeX-0002p3-6e; Tue, 21 Apr 2020 18:29:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HO9m=6F=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jQxeW-0002oy-Hx
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 18:29:48 +0000
X-Inumbo-ID: 148b818e-83fe-11ea-b4f4-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 148b818e-83fe-11ea-b4f4-bc764e2007e4;
 Tue, 21 Apr 2020 18:29:48 +0000 (UTC)
Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net
 (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 21FCB206B9;
 Tue, 21 Apr 2020 18:29:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587493787;
 bh=gPYLioEdR97tixnLWErX6tDm6h4U0yFb+6/sLVniAGs=;
 h=From:To:Cc:Subject:Date:From;
 b=DTYWyTaz5529QGg3jN5POOeo6GndaQxhZaHvyO7V3/GcmJCFum2RkLs3Ede5xnO+S
 8ioVKufkZPDJSnRVCMu+InCLVYu8q49JrRwu49W8eiFrklD4ZkWfcbEq3Sm9j2W4r8
 peH9OsIFgG0sM6PfG8AX9FZHsUQlny2llcdz3P40=
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] Introduce a description of the Backport and Fixes tags
Date: Tue, 21 Apr 2020 11:29:46 -0700
Message-Id: <20200421182946.27337-1-sstabellini@kernel.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, sstabellini@kernel.org, julien@xen.org,
 konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, george.dunlap@citrix.com,
 jbeulich@suse.com, Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Create a new document under docs/process to describe our special tags.
Add a description of the Fixes tag and the new Backport tag. Also
clarify that lines with tags should not be split.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Acked-by: Wei Liu <wl@xen.org>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: jbeulich@suse.com
CC: george.dunlap@citrix.com
CC: julien@xen.org
CC: lars.kurth@citrix.com
CC: andrew.cooper3@citrix.com
CC: konrad.wilk@oracle.com

---

Changes in v4:
- fix example
- use released trees instead of stable trees
- add (or in addition)

---
 docs/process/tags.pandoc | 55 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 docs/process/tags.pandoc

diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
new file mode 100644
index 0000000000..1841cb87a8
--- /dev/null
+++ b/docs/process/tags.pandoc
@@ -0,0 +1,55 @@
+Tags: No line splitting
+-----------------------
+Do not split a tag across multiple lines, tags are exempt from the
+"wrap at 75 columns" rule in order to simplify parsing scripts.  For
+example:
+
+        Fixes: 67d01cdb5518 ("x86: infrastructure to allow converting certain indirect calls to direct ones")
+
+
+Fixes Tag
+---------
+
+If your patch fixes a bug in a specific commit, e.g. you found an issue using
+``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
+the SHA-1 ID, and the one line summary.
+
+The following ``git config`` settings can be used to add a pretty format for
+outputting the above style in the ``git log`` or ``git show`` commands:
+
+        [core]
+                abbrev = 12
+        [pretty]
+                fixes = Fixes: %h (\"%s\")
+
+
+Backport Tag
+------------
+
+A backport tag is an optional tag in the commit message to request a
+given commit to be backported to the released trees:
+
+    Backport: 4.9+
+
+It marks a commit for being a candidate for backports to all released
+trees from 4.9 onward.
+
+The backport requester is expected to specify which currently supported
+releases need the backport; but encouraged to specify a release as far
+back as possible which applies. If the requester doesn't know the oldest
+affected tree, they are encouraged to append a comment like the
+following:
+
+    Backport: 4.9+ # maybe older
+
+Maintainers request the Backport tag to be added on commit. Contributors
+are welcome to mark their patches with the Backport tag when they deem
+appropriate. Maintainers will request for it to be removed when that is
+not the case.
+
+Please note that the Backport tag is a **request** for backport, which
+will still need to be evaluated by the maintainers. Maintainers might
+ask the requester to help with the backporting work if it is not
+trivial.
+
+When possible, please use the Fixes tag instead (or in addition).
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 18:45:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 18:45:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQxtF-0004Z4-K7; Tue, 21 Apr 2020 18:45:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=wEXD=6F=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQxtE-0004Yz-8F
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 18:45:00 +0000
X-Inumbo-ID: 33f6a560-8400-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 33f6a560-8400-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 18:44:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=3LRpHjK56BbXSmp/E5Wp5stHCUvVNHhkgn/mMIlOrhM=; b=LoMkH8FFHvgYsF++CozfveQZeI
 t4Op3K1otGTctTHTuU3zl74R8X/TI42NDaGJFKWBijnPsJ3bjC0tVl1+plJ7sNZ8SRNt7J8vGhfWg
 emAFgx4MSrmfb5cboJ2uM5R0LdaEUnaJDH906q+4rA15sTbSVy/+fOYSxSSnfWXXO8Rg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQxtB-0006q3-SR; Tue, 21 Apr 2020 18:44:57 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQxtB-0001cU-Lp; Tue, 21 Apr 2020 18:44:57 +0000
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Jan Beulich <jbeulich@suse.com>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
 <20200421173010.GY28601@Air-de-Roger>
From: Julien Grall <julien@xen.org>
Message-ID: <524885c7-5189-7215-41e6-1652a8bd08a2@xen.org>
Date: Tue, 21 Apr 2020 19:44:55 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421173010.GY28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 21/04/2020 18:30, Roger Pau Monné wrote:
> On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
>> First of all avoid excessive conversions. copy_{from,to}_guest(), for
>> example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
> 
> I'm not sure I understand the difference between those two, as they
> are both placeholders for linear guest addresses?
> 
> AFAICT XEN_GUEST_HANDLE should be used for guest pointers inside of an
> hypercall struct, while XEN_GUEST_HANDLE_PARAM is for guest pointers
> as hypercall arguments. But those are both just guest pointers,
> whether they are a parameter to the hypercall or a field in a
> struct, and hence could use the same type?
> 
> I assume there's some reason for not doing so, and I see the comment
> about other arches, but again a linear guest address is just that in
> all arches, regardless of it's placement.

On Arm:
  * XEN_GUEST_HANDLE() will always be 64-bit on both 32-bit and 64-bit 
hypervisor.
  * XEN_GUEST_HANDLE_PARAM() will be 32-bit for 32-bit hypervisor. For 
64-bit hypervisor, it will be 64-bit.

Per the ABI, each argument only fit a register. So you could not use 
XEN_GUEST_HANDLE() as now an argument will be held in 2 registers on 32-bit.

We also want the structure layout to be the same for 32-bit and 64-bit. 
So using XEN_GUEST_HANDLE_PARAM() everywhere is not the solution as the 
virtual address is not the same.

We could possibly convert internally XEN_GUEST_HANDLE_PARAM() to 
XEN_GUEST_HANDLE(), but I am not sure how this would be beneficial. We 
would have to use 2 registers for arm 32-bit everytime.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 18:49:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 18:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQxxm-0004kc-D9; Tue, 21 Apr 2020 18:49:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=CVv8=6F=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jQxxl-0004kP-Ir
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 18:49:41 +0000
X-Inumbo-ID: db0e9dda-8400-11ea-9189-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id db0e9dda-8400-11ea-9189-12813bfff9fa;
 Tue, 21 Apr 2020 18:49:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587494981;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=uZLNAWSjOVHW6mvQrnSk6c0Ya0uaKOvcN4JfeXRphEo=;
 b=hVtVK0dHJJsw12jHHoqZtTHdkiAR22IGlWl3VfMpVPp1X862VP1FFF5V
 4/9LwaVmfxJ/e8MHEdcR38ZAgAx8JqxXbieC9G2svqRmH3DYSQ5zlOOiu
 ebJzUxYSZqVMtAMNbpnNbh2xH61k90knelMX7nVC3k3H7bPdQ+oBRyrvH w=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 93rJBk9yjg7Hx9ygMFH3JGj0lYDJT4exs57KgwxvEDf7nX/9hLNrIh8D7EL2ONXvF4LRX9hpNm
 NDOtDQxAQNdZNmTmRaA+tey4t+7xLzUEFczGw9BjHpCYBy8Uqnlm0zF1Cq4RbciVoRMTKQz59X
 tK9JjJ5cAX5LbnZgFHHv5A+e1FQaHX2bmrxLjYP7CgImiolDJR9Sko+iB8C0n1S6tFA0V7P3D2
 EOJkl1y6yNcyGNwuuFobnL3P4N689R5hACbNtaxl/JoSBo4SwZ1yUGuoibujXixhX75q6oYFhn
 Whg=
X-SBRS: 2.7
X-MesageID: 16273838
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,411,1580792400"; d="scan'208";a="16273838"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24223.16427.427446.817623@mariner.uk.xensource.com>
Date: Tue, 21 Apr 2020 19:49:15 +0100
To: Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH] Introduce a description of the Backport and Fixes tags
In-Reply-To: <20200421182946.27337-1-sstabellini@kernel.org>
References: <20200421182946.27337-1-sstabellini@kernel.org>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "lars.kurth@citrix.com" <lars.kurth@citrix.com>,
 "julien@xen.org" <julien@xen.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 "jbeulich@suse.com" <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Stefano Stabellini writes ("[PATCH] Introduce a description of the Backport and Fixes tags"):
> Create a new document under docs/process to describe our special tags.
> Add a description of the Fixes tag and the new Backport tag. Also
> clarify that lines with tags should not be split.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> Acked-by: Wei Liu <wl@xen.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> +When possible, please use the Fixes tag instead (or in addition).

Do we have any code to turn Fixes: into a list of commits to
backport to a particular stable branch ?

If not it might be easier to ask people to add both Backport: and
Fixes:.

Ian.


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 18:49:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 18:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQxxr-0004m7-Ml; Tue, 21 Apr 2020 18:49:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HO9m=6F=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jQxxr-0004m1-1S
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 18:49:47 +0000
X-Inumbo-ID: dee76964-8400-11ea-9e09-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id dee76964-8400-11ea-9e09-bc764e2007e4;
 Tue, 21 Apr 2020 18:49:46 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id A11BF2068F;
 Tue, 21 Apr 2020 18:49:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587494986;
 bh=JtRBE1c3gRzFwsCZSKoRG25qASupDZE4AfU18+lXo9Y=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=EuR8U44iZ3mqIjBWnwIulciQ+u4ZoFYsta7o3Zdu6i9bIL7qKGsbhv5I5ToaAS1+Z
 xTfVYGw6tcOvO58eyXTCU53AEPwyQWk8PQK4+MnpD5ZwblpdQHCtOCtfKLxRsmZA4v
 TmTiuROeMrOrdjI8lqkDxUNlQyO/Yud6FpP0ef60=
Date: Tue, 21 Apr 2020 11:49:45 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH][RESEND] xen/arm: vgic-v3: fix GICD_ISACTIVER range
In-Reply-To: <aa8013f5-2209-ed0d-6ef4-e6a195bff75a@xen.org>
Message-ID: <alpine.DEB.2.21.2004211131461.24585@sstabellini-ThinkPad-T480s>
References: <20200417221609.19928-1-sstabellini@kernel.org>
 <CAJ=z9a2yCLfOGChD8YL3K7H50spGyifcpeLq_dz_T7aFV8VGQQ@mail.gmail.com>
 <alpine.DEB.2.21.2004171600580.32540@sstabellini-ThinkPad-T480s>
 <aa8013f5-2209-ed0d-6ef4-e6a195bff75a@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>,
 George.Dunlap@citrix.com, xen-devel <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

+ George

On Sat, 18 Apr 2020, Julien Grall wrote:
> Hi,
> 
> On 18/04/2020 00:12, Stefano Stabellini wrote:
> > On Fri, 17 Apr 2020, Julien Grall wrote:
> > > Hi,
> > > 
> > > The title claim this is a resend, but this is actually not the latest
> > > version of this patch. Can you explain why you decided to use v1
> > > rather than v2?
> > 
> > Because v2 added a printk for every read, and I thought you only wanted
> > the range fix. Also, the printk is not a "warn once" so after the
> > discussion where it became apparent that the register can be read many
> > times, it sounded undesirable.
> 
> You previously mentionned that you will use Peng's patch. From my perspective,
> this meant you are using the latest version of a patch not a previous one.
> 
> So this was a bit of a surprised to me.
> 
> > 
> > Nonetheless I don't have a strong preference between the two. If you
> > prefer v2 it is here:
> > 
> > https://marc.info/?l=xen-devel&m=157440872522065
> I understand the "warn" issue but we did agree with it back then. I am ok to
> drop it. However, may I request to be more forthcoming in your patch in the
> future?
> 
> For instance in this case, this a link to the original patch and an
> explanation why you selected v1 would have been really useful.

That's a good point, I can add it. So, for clarity, I'll keep v1 but
expand on the commit message to say that we kept v1 to avoid spamming
the console.


> > Do you need me to resent it? If it is OK for you as-is, you can give
> > your ack here, and I'll go ahead and commit it.
> > 
> > 
> > > On Fri, 17 Apr 2020 at 23:16, Stefano Stabellini <sstabellini@kernel.org>
> > > wrote:
> > > > 
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > > 
> > > > The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
> > > > 
> > > > (See https://marc.info/?l=xen-devel&m=158527653730795 for a discussion
> > > > on
> > > > what it would take to implement GICD_ISACTIVER/GICD_ICACTIVER properly.)
> > > > 
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > > > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> > > 
> > > I don't think you can be at the same time an author of the patch and a
> > > reviewer. Otherwise, I could review my own patch ;).
> > 
> > Yeah ... that was not the intention. I changed the commit message so I
> > had to add my signed-off-by for copyright reasons.
> > At the same time I
> > reviewed it even before changing the commit message so I added the
> > reviewed-by. I agree it looks kind of weird.
> 
> I don't feel this should go as-is. It is not clear in the commit message the
> changes you did and could lead confusion once merged. One may think you
> reviewed your own patch.
> 
> In general when I tweak a commit message, I will not add my signed-off-by but
> just add [julieng: Tweak commit message] above my reviewed-by/acked-by tag.
> 
> Alternatively, you can remove your reviewed-by and let another maintainer
> reviewing it.
> 
> I will let you decide your preference and resend the patch appropriately.
 
The Linux policy on Signed-off-by is really strict: basically any time a
person touches a patch, even just to commit the patch (no changes to
it), they add a Signed-off-by. So it is common there and other projects
to have both Signed-off-by and Reviewed-by from the same individual. For
instance on Linux:


commit b2a84de2a2deb76a6a51609845341f508c518c03

    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit 33e45234987ea3ed4b05fc512f4441696478f12d

    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Vincenzo Frascino <Vincenzo.Frascino@arm.com>
    Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
    [Amit: Modified secondary cores key structure, comments]
    Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


On QEMU:


commit 22cd0945b8429f818a2d90f06f02bb526bfb319d

    Signed-off-by: Francisco Iglesias <frasse.iglesias@gmail.com>
    Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
    Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
    Message-id: 20180503214201.29082-2-frasse.iglesias@gmail.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 133d23b3ad1be53105b9950fb18858cf059f2da6

    Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
    Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
    Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>


Your suggestion of adding something between brackets like:

  [stefano: update commit message] 

is good because it clarifies things and I'd like to do that. But still,
I think it would require the addition of my Signed-off-by. At the same
time it doesn't look like we want to avoiding adding a Reviewed-by
because a reviewer made a change to the commit message too?


Of course, for this patch, I am happy to drop my Reviewed-by and resend
and I'll do that. But I think it would be worth clarifying this point at
the project level. George, do we or the LinuxFoundation have a policy on
whether we can or cannot have reviewed-by and signed-off-by from the same
individual?


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 18:59:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 18:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQy6z-0005pK-OS; Tue, 21 Apr 2020 18:59:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=vOT2=6F=inria.fr=julia.lawall@srs-us1.protection.inumbo.net>)
 id 1jQy6y-0005pF-JS
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 18:59:12 +0000
X-Inumbo-ID: 2f8fca0e-8402-11ea-918e-12813bfff9fa
Received: from mail3-relais-sop.national.inria.fr (unknown [192.134.164.104])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2f8fca0e-8402-11ea-918e-12813bfff9fa;
 Tue, 21 Apr 2020 18:59:11 +0000 (UTC)
X-IronPort-AV: E=Sophos;i="5.72,411,1580770800"; d="scan'208";a="346583965"
Received: from abo-173-121-68.mrs.modulonet.fr (HELO hadrien) ([85.68.121.173])
 by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 21 Apr 2020 20:59:10 +0200
Date: Tue, 21 Apr 2020 20:59:09 +0200 (CEST)
From: Julia Lawall <julia.lawall@inria.fr>
X-X-Sender: jll@hadrien
To: Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [bug report] drm/xen-front: Add support for Xen PV display
 frontend
In-Reply-To: <20200421175220.GE2659@kadam>
Message-ID: <alpine.DEB.2.21.2004212057070.3118@hadrien>
References: <20200421104522.GA86681@mwanda>
 <alpine.DEB.2.21.2004211728360.3118@hadrien> <20200421175220.GE2659@kadam>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, kernel-janitors@vger.kernel.org,
 dri-devel@lists.freedesktop.org, oleksandr_andrushchenko@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On Tue, 21 Apr 2020, Dan Carpenter wrote:

> On Tue, Apr 21, 2020 at 05:29:02PM +0200, Julia Lawall wrote:
> >
> >
> > On Tue, 21 Apr 2020, Dan Carpenter wrote:
> >
> > > Hi Kernel Janitors,
> > >
> > > Here is another idea that someone could work on, fixing the
> > > IS_ERR_OR_NULL() checks in the xen driver.
> > >
> > > The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> > > display frontend" from Apr 3, 2018, leads to the following static
> > > checker warning:
> > >
> > > 	drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
> > > 	warn: passing zero to 'ERR_CAST'
> > >
> > > drivers/gpu/drm/xen/xen_drm_front_gem.c
> > >    133  struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
> > >    134                                                  size_t size)
> > >    135  {
> > >    136          struct xen_gem_object *xen_obj;
> > >    137
> > >    138          xen_obj = gem_create(dev, size);
> > >    139          if (IS_ERR_OR_NULL(xen_obj))
> > >    140                  return ERR_CAST(xen_obj);
> >
> > Are the other occurrences of this also a possible problem?  There are a
> > few others outside of xen.
>
> We sometimes check a parameter for IS_ERR_OR_NULL().
>
> void free_function(struct something *p)
> {
> 	if (IS_ERR_OR_NULL(p))
> 		return;
> }
>
> That's fine, absolutely harmless and not a bug.  But if we are checking
> a return value like this then probably most of the time it's invalid
> code.  Normally it's again like this code where we're dealing with an
> impossible thing because the return is never NULL.  The common bugs are
> that it returns NULL to a caller which only expects error pointers or it
> returns success instead of failure.  But sometimes returning success can
> be valid:
>
> 	obj = get_feature(dev);
> 	if (IS_ERR_OR_NULL(obj))
> 		return PTR_ERR(obj);
>
> It deliberately returns success because the rest of the function is
> useless when we don't have the feature.

The other cases are also with ERR_CAST:

drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c in create_udp_flow
fs/overlayfs/namei.c in ovl_index_upper
sound/soc/qcom/qdsp6/q6adm.c in q6adm_open
drivers/clk/clk.c in clk_hw_create_clk

julia


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 19:04:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 19:04:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQyCC-0006kB-Di; Tue, 21 Apr 2020 19:04:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=wEXD=6F=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jQyCA-0006je-Ne
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 19:04:34 +0000
X-Inumbo-ID: efea3e4c-8402-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id efea3e4c-8402-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 19:04:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=61JhVvefd6IQbuaphx3kk8843mhSQvEv4uW1B7wrSL0=; b=464WjS5zWb+EP0G0MWg1tnCXUs
 pbzZd+CZ/IIzBdynh2cGVWWswkauoJ96MwQdGoIRaKx8AbqmB8JMKIYgv+3t6SL5QUEZLrtB5DSXE
 n3x07KxCeDa7ETH0Yr3bJRwZI2Rrq/vMkSlcvS/fAfqcVhJ8syg4exsCH93gDuXPJeTY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQyC6-0007GP-Lf; Tue, 21 Apr 2020 19:04:30 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jQyC6-0002kG-7q; Tue, 21 Apr 2020 19:04:30 +0000
Subject: Re: [PATCH][RESEND] xen/arm: vgic-v3: fix GICD_ISACTIVER range
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200417221609.19928-1-sstabellini@kernel.org>
 <CAJ=z9a2yCLfOGChD8YL3K7H50spGyifcpeLq_dz_T7aFV8VGQQ@mail.gmail.com>
 <alpine.DEB.2.21.2004171600580.32540@sstabellini-ThinkPad-T480s>
 <aa8013f5-2209-ed0d-6ef4-e6a195bff75a@xen.org>
 <alpine.DEB.2.21.2004211131461.24585@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <125309d6-0a81-b6b5-2cf7-4cb3912b7144@xen.org>
Date: Tue, 21 Apr 2020 20:04:28 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004211131461.24585@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Peng Fan <peng.fan@nxp.com>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, George.Dunlap@citrix.com,
 Julien Grall <julien.grall.oss@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 21/04/2020 19:49, Stefano Stabellini wrote:
> + George
> 
> On Sat, 18 Apr 2020, Julien Grall wrote:
>> Hi,
>>
>> On 18/04/2020 00:12, Stefano Stabellini wrote:
>>> On Fri, 17 Apr 2020, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> The title claim this is a resend, but this is actually not the latest
>>>> version of this patch. Can you explain why you decided to use v1
>>>> rather than v2?
>>>
>>> Because v2 added a printk for every read, and I thought you only wanted
>>> the range fix. Also, the printk is not a "warn once" so after the
>>> discussion where it became apparent that the register can be read many
>>> times, it sounded undesirable.
>>
>> You previously mentionned that you will use Peng's patch. From my perspective,
>> this meant you are using the latest version of a patch not a previous one.
>>
>> So this was a bit of a surprised to me.
>>
>>>
>>> Nonetheless I don't have a strong preference between the two. If you
>>> prefer v2 it is here:
>>>
>>> https://marc.info/?l=xen-devel&m=157440872522065
>> I understand the "warn" issue but we did agree with it back then. I am ok to
>> drop it. However, may I request to be more forthcoming in your patch in the
>> future?
>>
>> For instance in this case, this a link to the original patch and an
>> explanation why you selected v1 would have been really useful.
> 
> That's a good point, I can add it. So, for clarity, I'll keep v1 but
> expand on the commit message to say that we kept v1 to avoid spamming
> the console.

I am fine with that:

Acked-by: Julien Grall <jgrall@amazon.com>

> 
> 
>>> Do you need me to resent it? If it is OK for you as-is, you can give
>>> your ack here, and I'll go ahead and commit it.
>>>
>>>
>>>> On Fri, 17 Apr 2020 at 23:16, Stefano Stabellini <sstabellini@kernel.org>
>>>> wrote:
>>>>>
>>>>> From: Peng Fan <peng.fan@nxp.com>
>>>>>
>>>>> The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
>>>>>
>>>>> (See https://marc.info/?l=xen-devel&m=158527653730795 for a discussion
>>>>> on
>>>>> what it would take to implement GICD_ISACTIVER/GICD_ICACTIVER properly.)
>>>>>
>>>>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
>>>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>>>>
>>>> I don't think you can be at the same time an author of the patch and a
>>>> reviewer. Otherwise, I could review my own patch ;).
>>>
>>> Yeah ... that was not the intention. I changed the commit message so I
>>> had to add my signed-off-by for copyright reasons.
>>> At the same time I
>>> reviewed it even before changing the commit message so I added the
>>> reviewed-by. I agree it looks kind of weird.
>>
>> I don't feel this should go as-is. It is not clear in the commit message the
>> changes you did and could lead confusion once merged. One may think you
>> reviewed your own patch.
>>
>> In general when I tweak a commit message, I will not add my signed-off-by but
>> just add [julieng: Tweak commit message] above my reviewed-by/acked-by tag.
>>
>> Alternatively, you can remove your reviewed-by and let another maintainer
>> reviewing it.
>>
>> I will let you decide your preference and resend the patch appropriately.
>   
> The Linux policy on Signed-off-by is really strict: basically any time a
> person touches a patch, even just to commit the patch (no changes to
> it), they add a Signed-off-by. So it is common there and other projects
> to have both Signed-off-by and Reviewed-by from the same individual. For
> instance on Linux:

I don't think we used this policy so far for Xen Project. Before 
pointing out the Signed-off-by vs Reviewed-by, I actually looked online 
but I wasn't able to find why Signed-off-by and Reviewed-by was added 
together.

> 
> 
> commit b2a84de2a2deb76a6a51609845341f508c518c03
> 
>      Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
>      Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
>      Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>      Signed-off-by: Will Deacon <will@kernel.org>
>      Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> 
> commit 33e45234987ea3ed4b05fc512f4441696478f12d
> 
>      Reviewed-by: Kees Cook <keescook@chromium.org>
>      Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>      Reviewed-by: Vincenzo Frascino <Vincenzo.Frascino@arm.com>
>      Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
>      [Amit: Modified secondary cores key structure, comments]
>      Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
>      Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> 
> 
> On QEMU:
> 
> 
> commit 22cd0945b8429f818a2d90f06f02bb526bfb319d
> 
>      Signed-off-by: Francisco Iglesias <frasse.iglesias@gmail.com>
>      Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
>      Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
>      Message-id: 20180503214201.29082-2-frasse.iglesias@gmail.com
>      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> 
> commit 133d23b3ad1be53105b9950fb18858cf059f2da6
> 
>      Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>      Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
>      Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
> 
> 
> Your suggestion of adding something between brackets like:
> 
>    [stefano: update commit message]
> 
> is good because it clarifies things and I'd like to do that. But still,
> I think it would require the addition of my Signed-off-by. At the same
> time it doesn't look like we want to avoiding adding a Reviewed-by
> because a reviewer made a change to the commit message too?

Agree, I also think we need to clarify in this case as it is more 
difficult to understand if the signed-off-by was by a contributor or 
someone who merged it.

> 
> 
> Of course, for this patch, I am happy to drop my Reviewed-by and resend
> and I'll do that. But I think it would be worth clarifying this point at
> the project level. George, do we or the LinuxFoundation have a policy on
> whether we can or cannot have reviewed-by and signed-off-by from the same
> individual?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 19:07:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 19:07:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQyF6-0006rg-0O; Tue, 21 Apr 2020 19:07:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=mjY1=6F=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jQyF5-0006ra-3t
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 19:07:35 +0000
X-Inumbo-ID: 5632dd81-8403-11ea-9191-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5632dd81-8403-11ea-9191-12813bfff9fa;
 Tue, 21 Apr 2020 19:07:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=uiIMugXv12UuGnA3+wib3QV49FgeAd2Hi5DMOHuHHbY=; b=w3aMRQMGoPasSEPUWH0I8iTg/
 v2ljuODgGHeKwY2O3wSiBE316j2ZJ6VE9rVDShSIcrSJ6PLOhvRJZpjAQjYVCcK10DhBe5p7MD9ty
 7pC8NDXtGki13db5u/1+9I0yY6DflNgzsPGk78FtxEn+JVBLl18IBDEwWQs3nTdVDdxw4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jQyEv-0007KP-Us; Tue, 21 Apr 2020 19:07:26 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jQyEv-00023S-Ij; Tue, 21 Apr 2020 19:07:25 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jQyEv-0007aj-Hw; Tue, 21 Apr 2020 19:07:25 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149706-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149706: regressions - FAIL
X-Osstest-Failures: qemu-mainline:test-armhf-armhf-libvirt-raw:xen-boot:fail:regression
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=3119154db04890fdf57022a43cf2ee594fd4da5a
X-Osstest-Versions-That: qemuu=20038cd7a8412feeb49c01f6ede89e36c8995472
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 21 Apr 2020 19:07:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  7 xen-boot                 fail REGR. vs. 149681

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149681

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149681
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149681
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149681
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149681
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 qemuu                3119154db04890fdf57022a43cf2ee594fd4da5a
baseline version:
 qemuu                20038cd7a8412feeb49c01f6ede89e36c8995472

Last test of basis   149681  2020-04-16 02:09:07 Z    5 days
Testing same since   149706  2020-04-21 10:39:06 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Chen Qun <kuhn.chenqun@huawei.com>
  Cédric Le Goater <clg@kaod.org>
  David Gibson <david@gibson.dropbear.id.au>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Laurent Vivier <laurent@vivier.eu>
  Nathan Chancellor <natechancellor@gmail.com>
  Nicholas Piggin <npiggin@gmail.com>
  Peter Maydell <peter.maydell@linaro.org>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Richard Henderson <richard.henderson@linaro.org>
  Sergei Trofimovich <slyfox@gentoo.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

------------------------------------------------------------
commit 3119154db04890fdf57022a43cf2ee594fd4da5a
Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
Date:   Fri Apr 17 11:07:49 2020 +0200

    target/ppc: Fix TCG temporary leaks in gen_slbia()
    
    This fixes:
    
      $ qemu-system-ppc64 \$
      -machine pseries-4.1 -cpu power9 \$
      -smp 4 -m 12G -accel tcg ...
      ...
      Quiescing Open Firmware ...
      Booting Linux via __start() @ 0x0000000002000000 ...
      Opcode 1f 12 0f 00 (7ce003e4) leaked temporaries
      Opcode 1f 12 0f 00 (7ce003e4) leaked temporaries
      Opcode 1f 12 0f 00 (7ce003e4) leaked temporaries
    
    [*] https://www.mail-archive.com/qemu-discuss@nongnu.org/msg05400.html
    
    Fixes: 0418bf78fe8 ("Fix ISA v3.0 (POWER9) slbia implementation")
    Reported-by: Dennis Clarke <dclarke@blastwave.org>
    Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: Cédric Le Goater <clg@kaod.org>
    Message-id: 20200417090749.14310-1-f4bug@amsat.org
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 5b4273e462515ae2f14cb57954d99416ae1778d9
Merge: d5232d8b06 5ed195065c
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Mon Apr 20 19:57:18 2020 +0100

    Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200417' into staging
    
    ppc patch queue for 2020-04-17
    
    Here are a few late bugfixes for qemu-5.0 in the ppc target code.
    Unless some really nasty last minute bug shows up, I expect this to be
    the last ppc pull request for qemu-5.0.
    
    # gpg: Signature made Fri 17 Apr 2020 06:02:13 BST
    # gpg:                using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
    # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
    # gpg:                 aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
    # gpg:                 aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full]
    # gpg:                 aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown]
    # Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392
    
    * remotes/dgibson/tags/ppc-for-5.0-20200417:
      target/ppc: Fix mtmsr(d) L=1 variant that loses interrupts
      target/ppc: Fix wrong interpretation of the disposition flag.
      linux-user/ppc: Fix padding in mcontext_t for ppc64
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit d5232d8b06003246b00b2001160beae4d8036dd2
Merge: ff0507c239 386d386568
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Mon Apr 20 14:43:10 2020 +0100

    Merge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-5.0-pull-request' into staging
    
    Fix epoll_create1() for qemu-alpha
    
    # gpg: Signature made Thu 16 Apr 2020 16:28:15 BST
    # gpg:                using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C
    # gpg:                issuer "laurent@vivier.eu"
    # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full]
    # gpg:                 aka "Laurent Vivier <laurent@vivier.eu>" [full]
    # gpg:                 aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full]
    # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F  5173 F30C 38BD 3F2F BE3C
    
    * remotes/vivier2/tags/linux-user-for-5.0-pull-request:
      linux-user/syscall.c: add target-to-host mapping for epoll_create1()
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit ff0507c239a246fd7215b31c5658fc6a3ee1e4c5
Author: Chen Qun <kuhn.chenqun@huawei.com>
Date:   Sat Apr 18 14:26:02 2020 +0800

    block/iscsi:fix heap-buffer-overflow in iscsi_aio_ioctl_cb
    
    There is an overflow, the source 'datain.data[2]' is 100 bytes,
     but the 'ss' is 252 bytes.This may cause a security issue because
     we can access a lot of unrelated memory data.
    
    The len for sbp copy data should take the minimum of mx_sb_len and
     sb_len_wr, not the maximum.
    
    If we use iscsi device for VM backend storage, ASAN show stack:
    
    READ of size 252 at 0xfffd149dcfc4 thread T0
        #0 0xaaad433d0d34 in __asan_memcpy (aarch64-softmmu/qemu-system-aarch64+0x2cb0d34)
        #1 0xaaad45f9d6d0 in iscsi_aio_ioctl_cb /qemu/block/iscsi.c:996:9
        #2 0xfffd1af0e2dc  (/usr/lib64/iscsi/libiscsi.so.8+0xe2dc)
        #3 0xfffd1af0d174  (/usr/lib64/iscsi/libiscsi.so.8+0xd174)
        #4 0xfffd1af19fac  (/usr/lib64/iscsi/libiscsi.so.8+0x19fac)
        #5 0xaaad45f9acc8 in iscsi_process_read /qemu/block/iscsi.c:403:5
        #6 0xaaad4623733c in aio_dispatch_handler /qemu/util/aio-posix.c:467:9
        #7 0xaaad4622f350 in aio_dispatch_handlers /qemu/util/aio-posix.c:510:20
        #8 0xaaad4622f350 in aio_dispatch /qemu/util/aio-posix.c:520
        #9 0xaaad46215944 in aio_ctx_dispatch /qemu/util/async.c:298:5
        #10 0xfffd1bed12f4 in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x512f4)
        #11 0xaaad46227de0 in glib_pollfds_poll /qemu/util/main-loop.c:219:9
        #12 0xaaad46227de0 in os_host_main_loop_wait /qemu/util/main-loop.c:242
        #13 0xaaad46227de0 in main_loop_wait /qemu/util/main-loop.c:518
        #14 0xaaad43d9d60c in qemu_main_loop /qemu/softmmu/vl.c:1662:9
        #15 0xaaad4607a5b0 in main /qemu/softmmu/main.c:49:5
        #16 0xfffd1a460b9c in __libc_start_main (/lib64/libc.so.6+0x20b9c)
        #17 0xaaad43320740 in _start (aarch64-softmmu/qemu-system-aarch64+0x2c00740)
    
    0xfffd149dcfc4 is located 0 bytes to the right of 100-byte region [0xfffd149dcf60,0xfffd149dcfc4)
    allocated by thread T0 here:
        #0 0xaaad433d1e70 in __interceptor_malloc (aarch64-softmmu/qemu-system-aarch64+0x2cb1e70)
        #1 0xfffd1af0e254  (/usr/lib64/iscsi/libiscsi.so.8+0xe254)
        #2 0xfffd1af0d174  (/usr/lib64/iscsi/libiscsi.so.8+0xd174)
        #3 0xfffd1af19fac  (/usr/lib64/iscsi/libiscsi.so.8+0x19fac)
        #4 0xaaad45f9acc8 in iscsi_process_read /qemu/block/iscsi.c:403:5
        #5 0xaaad4623733c in aio_dispatch_handler /qemu/util/aio-posix.c:467:9
        #6 0xaaad4622f350 in aio_dispatch_handlers /qemu/util/aio-posix.c:510:20
        #7 0xaaad4622f350 in aio_dispatch /qemu/util/aio-posix.c:520
        #8 0xaaad46215944 in aio_ctx_dispatch /qemu/util/async.c:298:5
        #9 0xfffd1bed12f4 in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x512f4)
        #10 0xaaad46227de0 in glib_pollfds_poll /qemu/util/main-loop.c:219:9
        #11 0xaaad46227de0 in os_host_main_loop_wait /qemu/util/main-loop.c:242
        #12 0xaaad46227de0 in main_loop_wait /qemu/util/main-loop.c:518
        #13 0xaaad43d9d60c in qemu_main_loop /qemu/softmmu/vl.c:1662:9
        #14 0xaaad4607a5b0 in main /qemu/softmmu/main.c:49:5
        #15 0xfffd1a460b9c in __libc_start_main (/lib64/libc.so.6+0x20b9c)
        #16 0xaaad43320740 in _start (aarch64-softmmu/qemu-system-aarch64+0x2c00740)
    
    Reported-by: Euler Robot <euler.robot@huawei.com>
    Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-id: 20200418062602.10776-1-kuhn.chenqun@huawei.com
    Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 5ed195065cc6895f61b9d59bfa0a0536ed5ed51e
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue Apr 14 21:11:31 2020 +1000

    target/ppc: Fix mtmsr(d) L=1 variant that loses interrupts
    
    If mtmsr L=1 sets MSR[EE] while there is a maskable exception pending,
    it does not cause an interrupt. This causes the test case to hang:
    
    https://lists.gnu.org/archive/html/qemu-ppc/2019-10/msg00826.html
    
    More recently, Linux reduced the occurance of operations (e.g., rfi)
    which stop translation and allow pending interrupts to be processed.
    This started causing hangs in Linux boot in long-running kernel tests,
    running with '-d int' shows the decrementer stops firing despite DEC
    wrapping and MSR[EE]=1.
    
    https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208301.html
    
    The cause is the broken mtmsr L=1 behaviour, which is contrary to the
    architecture. From Power ISA v3.0B, p.977, Move To Machine State Register,
    Programming Note states:
    
        If MSR[EE]=0 and an External, Decrementer, or Performance Monitor
        exception is pending, executing an mtmsrd instruction that sets
        MSR[EE] to 1 will cause the interrupt to occur before the next
        instruction is executed, if no higher priority exception exists
    
    Fix this by handling L=1 exactly the same way as L=0, modulo the MSR
    bits altered.
    
    The confusion arises from L=0 being "context synchronizing" whereas L=1
    is "execution synchronizing", which is a weaker semantic. However this
    is not a relaxation of the requirement that these exceptions cause
    interrupts when MSR[EE]=1 (e.g., when mtmsr executes to completion as
    TCG is doing here), rather it specifies how a pipelined processor can
    have multiple instructions in flight where one may influence how another
    behaves.
    
    Cc: qemu-stable@nongnu.org
    Reported-by: Anton Blanchard <anton@ozlabs.org>
    Reported-by: Nathan Chancellor <natechancellor@gmail.com>
    Tested-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Message-Id: <20200414111131.465560-1-npiggin@gmail.com>
    Reviewed-by: Cédric Le Goater <clg@kaod.org>
    Tested-by: Cédric Le Goater <clg@kaod.org>
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

commit 211a7784b9a80e42841223d8ea5252567ebe0e9e
Author: Ganesh Goudar <ganeshgr@linux.ibm.com>
Date:   Wed Apr 8 22:39:44 2020 +0530

    target/ppc: Fix wrong interpretation of the disposition flag.
    
    Bitwise AND with kvm_run->flags to evaluate if we recovered from
    MCE or not is not correct, As disposition in kvm_run->flags is a
    two-bit integer value and not a bit map, So check for equality
    instead of bitwise AND.
    
    Without the fix qemu treats any unrecoverable mce error as recoverable
    and ends up in a mce loop inside the guest, Below are the MCE logs before
    and after the fix.
    
    Before fix:
    
    [   66.775757] MCE: CPU0: Initiator CPU
    [   66.775891] MCE: CPU0: Unknown
    [   66.776587] MCE: CPU0: machine check (Harmless) Host UE Indeterminate [Recovered]
    [   66.776857] MCE: CPU0: NIP: [c0080000000e00b8] mcetest_tlbie+0xb0/0x128 [mcetest_tlbie]
    
    After fix:
    
    [ 20.650577] CPU: 0 PID: 1415 Comm: insmod Tainted: G M O 5.6.0-fwnmi-arv+ #11
    [ 20.650618] NIP: c0080000023a00e8 LR: c0080000023a00d8 CTR: c000000000021fe0
    [ 20.650660] REGS: c0000001fffd3d70 TRAP: 0200 Tainted: G M O (5.6.0-fwnmi-arv+)
    [ 20.650708] MSR: 8000000002a0b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 42000222 XER: 20040000
    [ 20.650758] CFAR: c00000000000b940 DAR: c0080000025e00e0 DSISR: 00000200 IRQMASK: 0
    [ 20.650758] GPR00: c0080000023a00d8 c0000001fddd79a0 c0080000023a8500 0000000000000039
    [ 20.650758] GPR04: 0000000000000001 0000000000000000 0000000000000000 0000000000000007
    [ 20.650758] GPR08: 0000000000000007 c0080000025e00e0 0000000000000000 00000000000000f7
    [ 20.650758] GPR12: 0000000000000000 c000000001900000 c00000000101f398 c0080000025c052f
    [ 20.650758] GPR16: 00000000000003a8 c0080000025c0000 c0000001fddd7d70 c0000000015b7940
    [ 20.650758] GPR20: 000000000000fff1 c000000000f72c28 c0080000025a0988 0000000000000000
    [ 20.650758] GPR24: 0000000000000100 c0080000023a05d0 c0000000001f1d70 0000000000000000
    [ 20.650758] GPR28: c0000001fde20000 c0000001fd02b2e0 c0080000023a0000 c0080000025e0000
    [ 20.651178] NIP [c0080000023a00e8] mcetest_tlbie+0xe8/0xf0 [mcetest_tlbie]
    [ 20.651220] LR [c0080000023a00d8] mcetest_tlbie+0xd8/0xf0 [mcetest_tlbie]
    [ 20.651262] Call Trace:
    [ 20.651280] [c0000001fddd79a0] [c0080000023a00d8] mcetest_tlbie+0xd8/0xf0 [mcetest_tlbie] (unreliable)
    [ 20.651340] [c0000001fddd7a10] [c00000000001091c] do_one_initcall+0x6c/0x2c0
    [ 20.651390] [c0000001fddd7af0] [c0000000001f7998] do_init_module+0x90/0x298
    [ 20.651433] [c0000001fddd7b80] [c0000000001f61a8] load_module+0x1f58/0x27a0
    [ 20.651476] [c0000001fddd7d40] [c0000000001f6c70] __do_sys_finit_module+0xe0/0x100
    [ 20.651526] [c0000001fddd7e20] [c00000000000b9d0] system_call+0x5c/0x68
    [ 20.651567] Instruction dump:
    [ 20.651594] e8410018 3c620000 e8638020 480000cd e8410018 3c620000 e8638028 480000bd
    [ 20.651646] e8410018 7be904e4 39400000 612900e0 <7d434a64> 4bffff74 3c4c0001 38428410
    [ 20.651699] ---[ end trace 4c40897f016b4340 ]---
    [ 20.653310]
    Bus error
    [ 20.655575] MCE: CPU0: machine check (Harmless) Host UE Indeterminate [Not recovered]
    [ 20.655575] MCE: CPU0: NIP: [c0080000023a00e8] mcetest_tlbie+0xe8/0xf0 [mcetest_tlbie]
    [ 20.655576] MCE: CPU0: Initiator CPU
    [ 20.655576] MCE: CPU0: Unknown
    
    Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
    Message-Id: <20200408170944.16003-1-ganeshgr@linux.ibm.com>
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

commit 5da5f47e6c65eda83e5433bd905c4df03be98596
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Mon Apr 6 20:21:05 2020 -0700

    linux-user/ppc: Fix padding in mcontext_t for ppc64
    
    The padding that was added in 95cda4c44ee was added to a union,
    and so it had no effect.  This fixes misalignment errors detected
    by clang sanitizers for ppc64 and ppc64le.
    
    In addition, only ppc64 allocates space for VSX registers, so do
    not save them for ppc32.  The kernel only has references to
    CONFIG_SPE in signal_32.c, so do not attempt to save them for ppc64.
    
    Fixes: 95cda4c44ee
    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
    Message-Id: <20200407032105.26711-1-richard.henderson@linaro.org>
    Acked-by: Laurent Vivier <laurent@vivier.eu>
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

commit 386d38656889a40d29b514ee6f34997ca18f741e
Author: Sergei Trofimovich <slyfox@gentoo.org>
Date:   Wed Apr 15 23:05:08 2020 +0100

    linux-user/syscall.c: add target-to-host mapping for epoll_create1()
    
    Noticed by Barnabás Virágh as a python-3.7 failue on qemu-alpha.
    
    The bug shows up on alpha as it's one of the targets where
    EPOLL_CLOEXEC differs from other targets:
        sysdeps/unix/sysv/linux/alpha/bits/epoll.h: EPOLL_CLOEXEC  = 01000000
        sysdeps/unix/sysv/linux/bits/epoll.h:        EPOLL_CLOEXEC = 02000000
    
    Bug: https://bugs.gentoo.org/717548
    Reported-by: Barnabás Virágh
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
    CC: Riku Voipio <riku.voipio@iki.fi>
    CC: Laurent Vivier <laurent@vivier.eu>
    Reviewed-by: Laurent Vivier <laurent@vivier.eu>
    Message-Id: <20200415220508.5044-1-slyfox@gentoo.org>
    Signed-off-by: Laurent Vivier <laurent@vivier.eu>


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 19:33:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 19:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQyeA-000183-Dx; Tue, 21 Apr 2020 19:33:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=Vwqf=6F=oracle.com=dan.carpenter@srs-us1.protection.inumbo.net>)
 id 1jQye8-00017t-RO
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 19:33:28 +0000
X-Inumbo-ID: f93a9704-8406-11ea-b4f4-bc764e2007e4
Received: from userp2120.oracle.com (unknown [156.151.31.85])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f93a9704-8406-11ea-b4f4-bc764e2007e4;
 Tue, 21 Apr 2020 19:33:28 +0000 (UTC)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03LJWbR7057307;
 Tue, 21 Apr 2020 19:33:21 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=date : from : to : cc
 : subject : message-id : references : mime-version : content-type :
 in-reply-to; s=corp-2020-01-29;
 bh=TfPCGAFcUDdGL+XJcTh5/DTnMS3ZeObUNYGdVKYo47E=;
 b=f86QhzGK9gsry8DK6RXoI/tkWT0W4WGhAW3WCHkgZsUJbIaZPbW0Z6nfOfKLdlzEmN2R
 N8yAnL+SS/PG0upm6nceWCppUox7EVb/TEv9x8cF87bJVqQuKAHWYWDEIkLfogDCQUW4
 E0T/ny8tS8388vMS0AQNZ9GUz4AZSUMEsYMKTHurtoN1k+YAb6oWJPkpo2OW19RWQojR
 TbwcOMTi3tTybJUFZEah2/iOPa4WoVxTuluBCG3Uiv+WTSDKf/WEtqQOFQNxK8qPpMFb
 tvFT0FR+CUtdowe1/4ZLGZ8HVXic5JljvLgav4ei+B4boBZVBBtwiclCd22QoB1IzUpw 5A== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2120.oracle.com with ESMTP id 30ft6n6wbq-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 21 Apr 2020 19:33:21 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03LJWElK040860;
 Tue, 21 Apr 2020 19:33:21 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
 by userp3030.oracle.com with ESMTP id 30gb1gry0w-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 21 Apr 2020 19:33:21 +0000
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
 by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03LJXKAA004999;
 Tue, 21 Apr 2020 19:33:20 GMT
Received: from kadam (/41.57.98.10) by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 21 Apr 2020 12:33:19 -0700
Date: Tue, 21 Apr 2020 22:33:12 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Julia Lawall <julia.lawall@inria.fr>
Subject: Re: [bug report] drm/xen-front: Add support for Xen PV display
 frontend
Message-ID: <20200421193312.GG2659@kadam>
References: <20200421104522.GA86681@mwanda>
 <alpine.DEB.2.21.2004211728360.3118@hadrien>
 <20200421175220.GE2659@kadam>
 <alpine.DEB.2.21.2004212057070.3118@hadrien>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.2004212057070.3118@hadrien>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9598
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 suspectscore=2 spamscore=0
 mlxlogscore=999 mlxscore=0 malwarescore=0 bulkscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004210146
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9598
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2
 bulkscore=0
 priorityscore=1501 impostorscore=0 adultscore=0 phishscore=0
 lowpriorityscore=0 malwarescore=0 clxscore=1015 mlxlogscore=999 mlxscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004210146
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, kernel-janitors@vger.kernel.org,
 dri-devel@lists.freedesktop.org, oleksandr_andrushchenko@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 08:59:09PM +0200, Julia Lawall wrote:
> 
> 
> On Tue, 21 Apr 2020, Dan Carpenter wrote:
> 
> > On Tue, Apr 21, 2020 at 05:29:02PM +0200, Julia Lawall wrote:
> > >
> > >
> > > On Tue, 21 Apr 2020, Dan Carpenter wrote:
> > >
> > > > Hi Kernel Janitors,
> > > >
> > > > Here is another idea that someone could work on, fixing the
> > > > IS_ERR_OR_NULL() checks in the xen driver.
> > > >
> > > > The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> > > > display frontend" from Apr 3, 2018, leads to the following static
> > > > checker warning:
> > > >
> > > > 	drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
> > > > 	warn: passing zero to 'ERR_CAST'
> > > >
> > > > drivers/gpu/drm/xen/xen_drm_front_gem.c
> > > >    133  struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
> > > >    134                                                  size_t size)
> > > >    135  {
> > > >    136          struct xen_gem_object *xen_obj;
> > > >    137
> > > >    138          xen_obj = gem_create(dev, size);
> > > >    139          if (IS_ERR_OR_NULL(xen_obj))
> > > >    140                  return ERR_CAST(xen_obj);
> > >
> > > Are the other occurrences of this also a possible problem?  There are a
> > > few others outside of xen.
> >
> > We sometimes check a parameter for IS_ERR_OR_NULL().
> >
> > void free_function(struct something *p)
> > {
> > 	if (IS_ERR_OR_NULL(p))
> > 		return;
> > }
> >
> > That's fine, absolutely harmless and not a bug.  But if we are checking
> > a return value like this then probably most of the time it's invalid
> > code.  Normally it's again like this code where we're dealing with an
> > impossible thing because the return is never NULL.  The common bugs are
> > that it returns NULL to a caller which only expects error pointers or it
> > returns success instead of failure.  But sometimes returning success can
> > be valid:
> >
> > 	obj = get_feature(dev);
> > 	if (IS_ERR_OR_NULL(obj))
> > 		return PTR_ERR(obj);
> >
> > It deliberately returns success because the rest of the function is
> > useless when we don't have the feature.
> 
> The other cases are also with ERR_CAST:

I bet these are less likely to be correct because probably the optional
feature doesn't translate to a different optional feature.

> 
> drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c in create_udp_flow

This can never be NULL, but look at this code:

drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
   427                          if (trans_spec) {
   428                                  qp_flow = create_and_add_flow(qp_grp,
   429                                                                  trans_spec);
   430                                  if (IS_ERR_OR_NULL(qp_flow)) {
   431                                          status = qp_flow ? PTR_ERR(qp_flow) : -EFAULT;
   432                                          break;
   433                                  }
   434                          } else {

If the create_and_add_flow() returns NULL, that's a bug because it's not
an optional feature which can be disabled in the config etc.  But this
code has been future proofed in case future users decide to write buggy
code the NULL gets changed to an error code.

Is -EFAULT the correct way to handle bugs that future programmers are
going to introduce?  You have to very psychic to know the answer to
that.

> fs/overlayfs/namei.c in ovl_index_upper

This code is correct.  There are actually a bunch of functions in VFS
which only return NULL and error pointers, never valid pointers.  VFS
is weird like that.

> sound/soc/qcom/qdsp6/q6adm.c in q6adm_open

Never NULL.  It should be IS_ERR().

> drivers/clk/clk.c in clk_hw_create_clk

This is checking a parameter so it's fine.

regards,
dan carpenter



From xen-devel-bounces@lists.xenproject.org Tue Apr 21 19:52:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 19:52:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jQywT-0002vh-40; Tue, 21 Apr 2020 19:52:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=mjY1=6F=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jQywR-0002vc-K1
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 19:52:23 +0000
X-Inumbo-ID: 9ae051d2-8409-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9ae051d2-8409-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 19:52:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=CWl64kH1K7aVNAktVVjNJgeS+LhtSUj9ObGplGDPBb8=; b=wIXeR/c0xn1j5RUFSGJub5KXH
 IbMTLBouW6s5o4WH2J9aXQukcThvDmI8BeA7MXTJqnu/HKo/Z0c/bZY8Cma9vXLPa0rHR1ub6xB+d
 DWynhgUbWmlSh+0TI1M7CIy1quaK3QtAjGaiibRp3cxXviFZr5c6VfqPfY6ySi16DVnOM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jQywL-0008Bb-Du; Tue, 21 Apr 2020 19:52:17 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jQywL-0004Gi-5C; Tue, 21 Apr 2020 19:52:17 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jQywL-00032k-4U; Tue, 21 Apr 2020 19:52:17 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149708-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149708: all pass - PUSHED
X-Osstest-Versions-This: ovmf=6e3c834ae47d1201c4ddcc6a6adc5e44718c7617
X-Osstest-Versions-That: ovmf=c884b23ac40a1b1f56e21ebbb1f602fa2e0f05c9
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 21 Apr 2020 19:52:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 6e3c834ae47d1201c4ddcc6a6adc5e44718c7617
baseline version:
 ovmf                 c884b23ac40a1b1f56e21ebbb1f602fa2e0f05c9

Last test of basis   149698  2020-04-17 07:50:32 Z    4 days
Testing same since   149708  2020-04-21 10:39:57 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Keysound Chang <Keysound_Chang@phoenix.com>
  Maciej Rabeda <maciej.rabeda@linux.intel.com>
  Michael Kubacki <michael.kubacki@microsoft.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   c884b23ac4..6e3c834ae4  6e3c834ae47d1201c4ddcc6a6adc5e44718c7617 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 21:43:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 21:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR0g0-0004Fn-Nk; Tue, 21 Apr 2020 21:43:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=mjY1=6F=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jR0fz-0004Fi-7D
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 21:43:31 +0000
X-Inumbo-ID: 23a28882-8419-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 23a28882-8419-11ea-b58d-bc764e2007e4;
 Tue, 21 Apr 2020 21:43:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ur1uXKGNe/h845/X65Db7stS7c7jmeN2ZKlA/NVsFus=; b=jpQzySZjmX8OrwP8LIeeIw8ng
 lywikLs9JayKG7XjPIrd4bh6p3bSXwn9Ft843QIChVolQOTSRdOkeIfoeIurwbtCgRW895GR8O5Xr
 02JOAb1lAE5yoah55fqTGMwkizA4fgYMI+QUPNSUlFH1gRwt3GGHHjphn9MDkBUoJvJO4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR0fx-00021z-9O; Tue, 21 Apr 2020 21:43:29 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR0fx-0002s4-0Q; Tue, 21 Apr 2020 21:43:29 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jR0fw-0003Cu-Vv; Tue, 21 Apr 2020 21:43:28 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149705-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149705: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
X-Osstest-Versions-That: xen=a48e1323f9aa29f1ffb95594671b73de6bd7c1d4
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 21 Apr 2020 21:43:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149695
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149695
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149695
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149695
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149695
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149695
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149695
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149695
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149695
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149695
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 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-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
baseline version:
 xen                  a48e1323f9aa29f1ffb95594671b73de6bd7c1d4

Last test of basis   149695  2020-04-17 04:16:59 Z    4 days
Testing same since   149702  2020-04-17 13:36:57 Z    4 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dfaggioli@suse.com>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Sergey Dyasli <sergey.dyasli@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   a48e1323f9..82dd1a956d  82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638 -> master


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 23:27:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 23:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR2IQ-0004jp-7n; Tue, 21 Apr 2020 23:27:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HO9m=6F=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jR2IP-0004jk-D8
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 23:27:17 +0000
X-Inumbo-ID: a32d9304-8427-11ea-91e3-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a32d9304-8427-11ea-91e3-12813bfff9fa;
 Tue, 21 Apr 2020 23:27:16 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id A6A87206D5;
 Tue, 21 Apr 2020 23:27:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587511636;
 bh=sfnZf1beH10HqpyFM6AUXnmvNTnUV7wg6qSQSlrtjrY=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=b2LQdJgurLstaApReLHIjx5mlrgrkQtsU7trXwaXqF8/VNBSou+vMYPvCqbXOAp2M
 576f7eMK5jb+ukKCwZ4lBKXrVNYHAaSxGSCkgsSH3bkPkCSVvaJg0yvUNwQGTmeZ7v
 RDvtP9OHfQHzuWFO1f1ll/rNFevQzBWqKZXInixQ=
Date: Tue, 21 Apr 2020 16:27:15 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all
 arches
In-Reply-To: <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
Message-ID: <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1109758986-1587511151=:24585"
Content-ID: <alpine.DEB.2.21.2004211619370.24585@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1109758986-1587511151=:24585
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.21.2004211619371.24585@sstabellini-ThinkPad-T480s>

On Mon, 20 Apr 2020, Jan Beulich wrote:
> On 20.04.2020 15:34, Julien Grall wrote:
> > Hi Jan,
> > 
> > On 20/04/2020 09:04, Jan Beulich wrote:
> >> On 19.04.2020 12:49, Julien Grall wrote:
> >>> --- a/docs/misc/pvcalls.pandoc
> >>> +++ b/docs/misc/pvcalls.pandoc
> >>> @@ -246,9 +246,7 @@ The format is defined as follows:
> >>>                   uint32_t domain;
> >>>                   uint32_t type;
> >>>                   uint32_t protocol;
> >>> -                #ifdef CONFIG_X86_32
> >>>                   uint8_t pad[4];
> >>> -                #endif
> >>>               } socket;
> >>>               struct xen_pvcalls_connect {
> >>>                   uint64_t id;
> >>> @@ -257,16 +255,12 @@ The format is defined as follows:
> >>>                   uint32_t flags;
> >>>                   grant_ref_t ref;
> >>>                   uint32_t evtchn;
> >>> -                #ifdef CONFIG_X86_32
> >>>                   uint8_t pad[4];
> >>> -                #endif
> >>>               } connect;
> >>>               struct xen_pvcalls_release {
> >>>                   uint64_t id;
> >>>                   uint8_t reuse;
> >>> -                #ifdef CONFIG_X86_32
> >>>                   uint8_t pad[7];
> >>> -                #endif
> >>>               } release;
> >>>               struct xen_pvcalls_bind {
> >>>                   uint64_t id;
> >>> @@ -276,9 +270,7 @@ The format is defined as follows:
> >>>               struct xen_pvcalls_listen {
> >>>                   uint64_t id;
> >>>                   uint32_t backlog;
> >>> -                #ifdef CONFIG_X86_32
> >>>                   uint8_t pad[4];
> >>> -                #endif
> >>>               } listen;
> >>>               struct xen_pvcalls_accept {
> >>>                   uint64_t id;
> >>
> >> I wonder on what grounds these #ifdef-s had been there - they're
> >> plain wrong with the types used in the public header.
> >>
> >>> --- a/xen/include/public/io/pvcalls.h
> >>> +++ b/xen/include/public/io/pvcalls.h
> >>> @@ -65,6 +65,7 @@ struct xen_pvcalls_request {
> >>>               uint32_t domain;
> >>>               uint32_t type;
> >>>               uint32_t protocol;
> >>> +            uint8_t pad[4];
> >>>           } socket;
> >>>           struct xen_pvcalls_connect {
> >>>               uint64_t id;
> >>> @@ -73,10 +74,12 @@ struct xen_pvcalls_request {
> >>>               uint32_t flags;
> >>>               grant_ref_t ref;
> >>>               uint32_t evtchn;
> >>> +            uint8_t pad[4];
> >>>           } connect;
> >>>           struct xen_pvcalls_release {
> >>>               uint64_t id;
> >>>               uint8_t reuse;
> >>> +            uint8_t pad[7];
> >>>           } release;
> >>>           struct xen_pvcalls_bind {
> >>>               uint64_t id;
> >>> @@ -86,6 +89,7 @@ struct xen_pvcalls_request {
> >>>           struct xen_pvcalls_listen {
> >>>               uint64_t id;
> >>>               uint32_t backlog;
> >>> +            uint8_t pad[4];
> >>>           } listen;
> >>
> >> I'm afraid we can't change these in such a way - your additions
> >> change sizeof() for the respective sub-structures on 32-bit x86,
> >> and hence this is not a backwards compatible adjustment. 
> > 
> > This is a bit confusing, each structure contain a 64-bit field so
> > I would have thought it the structure would be 8-byte aligned (as
> > on 32-bit Arm). But looking at the spec, a uint64_t will only
> > aligned to 4-byte.
> > 
> > However, I am not sure why sizeof() matters here. I understand
> > the value would be different, but AFAICT, this is not used as part
> > of the protocol.
> 
> Two independent components of a consumer of our interface could
> have a function taking (pointer to) struct xen_pvcalls_connect.
> If one component gets re-built with the new definition and the
> other doesn't, they'll disagree on what range of memory needs
> to be accessible. The instantiating side (using the old header)
> may have ended up placing the struct immediately ahead of a
> page boundary. The consuming side (using the changed header)
> would then encounter a fault if it wanted to access the struct
> as a whole (assignment, memcpy()).

Even if it was possible to use the sub-structs defined in the header
that way, keep in mind that we also wrote:

        /* dummy member to force sizeof(struct xen_pvcalls_request)
         * to match across archs */
        struct xen_pvcalls_dummy {
            uint8_t dummy[56];
        } dummy;

And the spec also clarifies that the size of each specific request is
always 56 bytes. So I think that if we wanted, we could make the changes
Julien is suggesting without worrying about breaking anything.

Speaking of the patch, I think it would be good to have to make things
clearer.
--8323329-1109758986-1587511151=:24585--


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 23:31:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 23:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR2Mj-0005YX-Rh; Tue, 21 Apr 2020 23:31:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=mjY1=6F=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jR2Mi-0005YS-Sq
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 23:31:44 +0000
X-Inumbo-ID: 4299072a-8428-11ea-91e5-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4299072a-8428-11ea-91e5-12813bfff9fa;
 Tue, 21 Apr 2020 23:31:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=5UATkTJlo3ZIna4iatVR3a6Hv/oXsOd+v8MKFD7z33Y=; b=pgsws8b7jKdNXgihrabRdvFTA
 ruRzYe0lAshZpqUDmr8Dk05yLNVGOryeprUQH5e8J+cvkJFFAnQDlhgW26Z7BU1vxB2hNqdxVpjbu
 SpOIR9oG3fqil4iez57kFBPa3lzmgGOVa9NfuRGZ22yX1u+ywdpMlP4Q0HHYcTHOvaVYI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR2Mh-00049R-NP; Tue, 21 Apr 2020 23:31:43 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR2Mh-0002NA-Dz; Tue, 21 Apr 2020 23:31:43 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jR2Mh-0006Fa-DO; Tue, 21 Apr 2020 23:31:43 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149724-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149724: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=0796cb907f2c31046427510a6da6f4941f678b76
X-Osstest-Versions-That: xen=4803a67114279a656a54a23cebed646da32efeb6
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 21 Apr 2020 23:31:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  0796cb907f2c31046427510a6da6f4941f678b76
baseline version:
 xen                  4803a67114279a656a54a23cebed646da32efeb6

Last test of basis   149720  2020-04-21 16:02:16 Z    0 days
Testing same since   149724  2020-04-21 20:01:12 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Julien Grall <jgrall@amazon.com>
  Peng Fan <peng.fan@nxp.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4803a67114..0796cb907f  0796cb907f2c31046427510a6da6f4941f678b76 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 23:47:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 23:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR2cI-0006gr-53; Tue, 21 Apr 2020 23:47:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=HO9m=6F=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jR2cG-0006gm-K3
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 23:47:48 +0000
X-Inumbo-ID: 80ccce8b-842a-11ea-91e7-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 80ccce8b-842a-11ea-91e7-12813bfff9fa;
 Tue, 21 Apr 2020 23:47:48 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 3DCFC2068F;
 Tue, 21 Apr 2020 23:47:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587512867;
 bh=ozv1hgN/Sf+MmTuer++0IDoXPh3jGO16JZYGMTkRSGw=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=MJxELsGnGWw2NXrmnuybCTEBs+RAgjJSB4oYdGdEESBhI3Mxr/zjBc5/mBc3eAK+T
 5sBNp745QfOAExOOZ5HbMFUCatERpHpCaCL02MTysOKRbSCBDjbQ8Wf9xKTzI5k3/r
 tMtw19UOKko3jVpmZe3XJfCBzaaWOl2wL/QunlzE=
Date: Tue, 21 Apr 2020 16:47:46 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH] xen/arm: Avoid to open-code the relinquish state machine
In-Reply-To: <20200419095030.2081-1-julien@xen.org>
Message-ID: <alpine.DEB.2.21.2004211640450.24585@sstabellini-ThinkPad-T480s>
References: <20200419095030.2081-1-julien@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sun, 19 Apr 2020, Julien Grall wrote:
> In commit 0dfffe01d5 "x86: Improve the efficiency of
> domain_relinquish_resources()", the x86 version of the function has been
> reworked to avoid open-coding the state machine and also add more
> documentation.
> 
> Bring the Arm version on part with x86 by introducing a documented
> PROGRESS() macro to avoid latent bugs and make the new PROG_* states
> private to domain_relinquish_resources().
> 
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Julien Grall <jgrall@amazon.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/arch/arm/domain.c        | 60 ++++++++++++++++++++++--------------
>  xen/include/asm-arm/domain.h |  9 +-----
>  2 files changed, 38 insertions(+), 31 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 6627be2922..31169326b2 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -674,7 +674,6 @@ int arch_domain_create(struct domain *d,
>      int rc, count = 0;
>  
>      BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
> -    d->arch.relmem = RELMEM_not_started;
>  
>      /* Idle domains do not need this setup */
>      if ( is_idle_domain(d) )
> @@ -950,13 +949,41 @@ static int relinquish_memory(struct domain *d, struct page_list_head *list)
>      return ret;
>  }
>  
> +/*
> + * Record the current progress. Subsequent hypercall continuations will
> + * logically restart work from this point.
> + *
> + * PROGRESS() markers must not be in the middle of loops. The loop
> + * variable isn't preserved accross a continuation.
> + *
> + * To avoid redundant work, there should be a marker before each
> + * function which may return -ERESTART.
> + */
> +enum {
> +    PROG_tee = 1,
> +    PROG_xen,
> +    PROG_page,
> +    PROG_mapping,
> +    PROG_done,
> +};
> +
> +#define PROGRESS(x)                         \
> +    d->arch.rel_priv = PROG_ ## x;          \
> +    /* Fallthrough */                       \
> +    case PROG_ ## x
> +
>  int domain_relinquish_resources(struct domain *d)
>  {
>      int ret = 0;
>  
> -    switch ( d->arch.relmem )
> +    /*
> +     * This hypercall can take minutes of wallclock time to complete.  This
> +     * logic implements a co-routine, stashing state in struct domain across
> +     * hypercall continuation boundaries.
> +     */
> +    switch ( d->arch.rel_priv )
>      {
> -    case RELMEM_not_started:
> +    case 0:
>          ret = iommu_release_dt_devices(d);
>          if ( ret )
>              return ret;
> @@ -967,42 +994,27 @@ int domain_relinquish_resources(struct domain *d)
>           */
>          domain_vpl011_deinit(d);
>  
> -        d->arch.relmem = RELMEM_tee;
> -        /* Fallthrough */
> -
> -    case RELMEM_tee:
> +    PROGRESS(tee):
>          ret = tee_relinquish_resources(d);
>          if (ret )
>              return ret;
>  
> -        d->arch.relmem = RELMEM_xen;
> -        /* Fallthrough */
> -
> -    case RELMEM_xen:
> +    PROGRESS(xen):
>          ret = relinquish_memory(d, &d->xenpage_list);
>          if ( ret )
>              return ret;
>  
> -        d->arch.relmem = RELMEM_page;
> -        /* Fallthrough */
> -
> -    case RELMEM_page:
> +    PROGRESS(page):
>          ret = relinquish_memory(d, &d->page_list);
>          if ( ret )
>              return ret;
>  
> -        d->arch.relmem = RELMEM_mapping;
> -        /* Fallthrough */
> -
> -    case RELMEM_mapping:
> +    PROGRESS(mapping):
>          ret = relinquish_p2m_mapping(d);
>          if ( ret )
>              return ret;
>  
> -        d->arch.relmem = RELMEM_done;
> -        /* Fallthrough */
> -
> -    case RELMEM_done:
> +    PROGRESS(done):
>          break;
>  
>      default:
> @@ -1012,6 +1024,8 @@ int domain_relinquish_resources(struct domain *d)
>      return 0;
>  }
>  
> +#undef PROGRESS
> +
>  void arch_dump_domain_info(struct domain *d)
>  {
>      p2m_dump_info(d);
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index d39477a939..d2142c6707 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -56,14 +56,7 @@ struct arch_domain
>      struct vmmio vmmio;
>  
>      /* Continuable domain_relinquish_resources(). */
> -    enum {
> -        RELMEM_not_started,
> -        RELMEM_tee,
> -        RELMEM_xen,
> -        RELMEM_page,
> -        RELMEM_mapping,
> -        RELMEM_done,
> -    } relmem;
> +    unsigned int rel_priv;
>  
>      struct {
>          uint64_t offset;
> -- 
> 2.17.1
> 


From xen-devel-bounces@lists.xenproject.org Tue Apr 21 23:58:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Apr 2020 23:58:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR2m7-0007gT-7e; Tue, 21 Apr 2020 23:57:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=mjY1=6F=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jR2m5-0007g9-6C
 for xen-devel@lists.xenproject.org; Tue, 21 Apr 2020 23:57:57 +0000
X-Inumbo-ID: e863ffae-842b-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e863ffae-842b-11ea-83d8-bc764e2007e4;
 Tue, 21 Apr 2020 23:57:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=54bxYuGuInvykX/iCsRN/qF4t55ZTUvjNNgS6RkQ4jc=; b=5XUSMCoaAUOW2SK16T9abCxlO
 v5d/oAUKnX0gUz0CwgvebV+lqanA0GcM4CoamHGrTWqVRhc91cgx5U2Q+Pg9h7JvdPo1dnlvAl9z4
 YiLSiRoEOJH5VpAJsJGdCwDsDFdca7sSe0LPfqTvyRLNwE6xIo43TFk/BvLRERzTDW2fs=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR2ly-0004fX-B2; Tue, 21 Apr 2020 23:57:50 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR2lx-00045S-S8; Tue, 21 Apr 2020 23:57:49 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jR2lx-0006CQ-RV; Tue, 21 Apr 2020 23:57:49 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149709-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149709: regressions - FAIL
X-Osstest-Failures: linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression
 linux-5.4:test-amd64-amd64-xl-rtds:guest-saverestore:fail:allowable
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: linux=6ccc74c083c0d472ac64f3733f5b7bf3f99f261e
X-Osstest-Versions-That: linux=bc844d58f697dff3ded4b410094ee89f5cedc04c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 21 Apr 2020 23:57:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 149637

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     15 guest-saverestore        fail REGR. vs. 149637

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                6ccc74c083c0d472ac64f3733f5b7bf3f99f261e
baseline version:
 linux                bc844d58f697dff3ded4b410094ee89f5cedc04c

Last test of basis   149637  2020-04-13 09:10:52 Z    8 days
Failing since        149700  2020-04-17 09:09:37 Z    4 days    2 attempts
Testing same since   149709  2020-04-21 10:41:23 Z    0 days    1 attempts

------------------------------------------------------------
317 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 02:25:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 02:25:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR54T-0007eK-8P; Wed, 22 Apr 2020 02:25:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jR54R-0007eF-6B
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 02:25:03 +0000
X-Inumbo-ID: 7840e330-8440-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7840e330-8440-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 02:25:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=wBIy5oUa18sf4H4q8RDzq8VCZrcSIG+AJg8fvX3NeL4=; b=cLdm7kwu3hiXQ9en2+PByxRJR
 FA0OOL6VZyJoWHcMwy2njbPhjZDp8f2h5hvJZ0CWbFsgZTJID3kbtqn8V+JLvbj35B7NodSbiKe4h
 Pf0vWzrawcR0ZqgejrDES/T//S6Ci/LGFtasnk9pWaWtawy3pg4+aCZoUtUT2bRMU5P4I=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR54P-0004cJ-H9; Wed, 22 Apr 2020 02:25:01 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR54P-0004tg-A2; Wed, 22 Apr 2020 02:25:01 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jR54P-0007Pr-9R; Wed, 22 Apr 2020 02:25:01 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149727-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149727: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=5730ac3c8346f56fe8ee90249cdcbdab2a4d5791
X-Osstest-Versions-That: xen=0796cb907f2c31046427510a6da6f4941f678b76
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 02:25:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  5730ac3c8346f56fe8ee90249cdcbdab2a4d5791
baseline version:
 xen                  0796cb907f2c31046427510a6da6f4941f678b76

Last test of basis   149724  2020-04-21 20:01:12 Z    0 days
Testing same since   149727  2020-04-22 00:01:31 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Julien Grall <jgrall@amazon.com>
  Julien Grall <julien@xen.org>

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


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   0796cb907f..5730ac3c83  5730ac3c8346f56fe8ee90249cdcbdab2a4d5791 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 03:58:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 03:58:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR6Wf-0007ED-HX; Wed, 22 Apr 2020 03:58:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jR6Wd-0007E8-Dp
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 03:58:15 +0000
X-Inumbo-ID: 79e467cc-844d-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 79e467cc-844d-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 03:58:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=AibztkYXZqtuiy6qxIya3iVB/OGKY+iIvqLdbcZtZng=; b=ZeT0IkmjRA1Nghrb4N4IfsLcq
 fX8mNFU17RitNSEQDtqnT2c4IeWwwwBPo6RLqoZ+Cwl/LN+HgWOFge8W/x/LX3KUXdMXBvsGoTjxa
 gsylUgFX+VFQOCMNcxveEZevOOXrR68pJOuW8hzPKnbyOcWROiUh6tUkFZKiAm752NqtY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR6WV-0006VE-RF; Wed, 22 Apr 2020 03:58:07 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR6WV-0001mZ-Id; Wed, 22 Apr 2020 03:58:07 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jR6WV-0003oD-I6; Wed, 22 Apr 2020 03:58:07 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149711-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149711: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=ae83d0b416db002fe95601e7f97f64b59514d936
X-Osstest-Versions-That: linux=7a56db0299f9d43b4fe076838150c5cc293df131
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 03:58:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                ae83d0b416db002fe95601e7f97f64b59514d936
baseline version:
 linux                7a56db0299f9d43b4fe076838150c5cc293df131

Last test of basis   149703  2020-04-17 16:39:47 Z    4 days
Testing same since   149711  2020-04-21 10:41:40 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Eric W. Biederman" <ebiederm@xmission.com>
  Adam Barber <barberadam995@gmail.com>
  afzal mohammed <afzal.mohd.ma@gmail.com>
  Alex Deucher <alexander.deucher@amd.com>
  Alex Deucher <alexdeucher@gmail.com>
  Alexandru Tachici <alexandru.tachici@analog.com>
  Andrei Vagin <avagin@gmail.com>
  Ann T Ropea <bedhanger@gmx.de>
  Arnaldo Carvalho de Melo <acme@redhat.com>
  Arnd Bergmann <arnd@arndb.de>
  Ashutosh Dixit <ashutosh.dixit@intel.com>
  Atish Patra <atish.patra@wdc.com>
  Ben Skeggs <bskeggs@redhat.com>
  Ben Skeggs <skeggsb@gmail.com>
  Bodo Stroesser <bstroesser@ts.fujitsu.com>
  Borislav Petkov <bp@suse.de>
  Brian Foster <bfoster@redhat.com>
  Brian Geffon <bgeffon@google.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Chris Packham <chris.packham@alliedtelesis.co.nz>
  Chris Wilson <chris@chris-wilson.co.uk>
  Christian Brauner <christian.brauner@ubuntu.com>
  Chunyan Zhang <chunyan.zhang@unisoc.com>
  Darrick J. Wong <darrick.wong@oracle.com>
  Dave Airlie <airlied@redhat.com>
  David Sterba <dsterba@suse.com>
  Dmitry Osipenko <digetx@gmail.com>
  Douglas Gilbert <dgilbert@interlog.com>
  Eric Biggers <ebiggers@google.com>
  Eric W. Biederman <ebiederm@xmission.com>
  Eugene Syromiatnikov <esyr@redhat.com>
  Evan Quan <evan.quan@amd.com>
  Fabio Estevam <festevam@gmail.com>
  Fangrui Song <maskray@google.com>
  Frank Rowand <frank.rowand@sony.com>
  Geert Uytterhoeven <geert+renesas@glider.be>
  Grygorii Strashko <grygorii.strashko@ti.com>
  Guenter Roeck <linux@roeck-us.net>
  Gustavo A. R. Silva <gustavo@embeddedor.com>
  Hans de Goede <hdegoede@redhat.com>
  Hui Wang <hui.wang@canonical.com>
  Ingo Molnar <mingo@kernel.org>
  James Morse <james.morse@arm.com>
  Jan Kara <jack@suse.cz>
  Jarkko Nikula <jarkko.nikula@linux.intel.com>
  Jason Yan <yanaijie@huawei.com>
  Jens Axboe <axboe@kernel.dk>
  Jin Yao <yao.jin@linux.intel.com>
  Jiri Olsa <jolsa@kernel.org>
  Joel Stanley <joel@jms.id.au>
  John Allen <john.allen@amd.com>
  John Garry <john.garry@huawei.com>
  Jonathan Corbet <corbet@lwn.net>
  Jones Syue <jonessyue@qnap.com>
  Josef Bacik <josef@toxicpanda.com>
  Josh Poimboeuf <jpoimboe@redhat.com>
  Josh Triplett <josh@joshtriplett.org>
  Juergen Gross <jgross@suse.com>
  Kai-Heng Feng <kai.heng.feng@canonical.com>
  Li Bin <huawei.libin@huawei.com>
  Likun Gao <Likun.Gao@amd.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Linus Walleij <linus.walleij@linaro.org>
  Marc Zyngier <maz@kernel.org>
  Mark Rutland <mark.rutland@arm.com>
  Martin K. Petersen <martin.petersen@oracle.com>
  Masahiro Yamada <masahiroy@kernel.org>
  Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
  Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
  Mengbing Wang <Mengbing.Wang@amd.com>
  Michael Kerrisk <mtk.manpages@gmail.com>
  Michael Walle <michael@walle.cc>
  Mike Christie <mchristi@redhat.com>
  Nathan Chancellor <natechancellor@gmail.com>
  Nilesh Javali <njavali@marvell.com>
  Nuno Sá <nuno.sa@analog.com>
  Oleg Nesterov <oleg@redhat.com>
  Paul E. McKenney <paulmck@kernel.org>
  Paul Menzel <pmenzel@molgen.mpg.de>
  Pavel Begunkov <asml.silence@gmail.com>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Xu <peterx@redhat.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Peter Zijlstra <peterz@infradead.org>
  Prike Liang <Prike.Liang@amd.com>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Rajendra Nayak <rnayak@codeaurora.org>
  Reinette Chatre <reinette.chatre@intel.com>
  Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
  Richard Weinberger <richard@nod.at>
  Rob Herring <robh@kernel.org>
  Rodrigo Vivi <rodrigo.vivi@intel.com>
  Roman Gushchin <guro@fb.com>
  Ronnie Sahlberg <lsahlber@redhat.com>
  Roy Spliet <nouveau@spliet.org>
  Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
  Sascha Hauer <s.hauer@pengutronix.de>
  Sergei Lopatin <magist3r@gmail.com>
  Stefan Haberland <sth@linux.ibm.com>
  Stephen Boyd <sboyd@kernel.org>
  Steve French <stfrench@microsoft.com>
  Takashi Iwai <tiwai@suse.de>
  Theodore Ts'o <tytso@mit.edu>
  Thomas Gleixner <tglx@linutronix.de>
  Tiezhu Yang <yangtiezhu@loongson.cn>
  Tommi Rantala <tommi.t.rantala@nokia.com>
  Tony Luck <tony.luck@intel.com>
  Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
  Viresh Kumar <viresh.kumar@linaro.org>
  Will Deacon <will@kernel.org>
  Wim Van Sebroeck <wim@linux-watchdog.org>
  Wolfram Sang <wsa+renesas@sang-engineering.com>
  Wolfram Sang <wsa@the-dreams.de>
  Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
  Xu Wang <vulab@iscas.ac.cn>
  Yan Zhao <yan.y.zhao@intel.com>
  yangerkun <yangerkun@huawei.com>
  YueHaibing <yuehaibing@huawei.com>
  Zenghui Yu <yuzenghui@huawei.com>
  Zhenyu Wang <zhenyuw@linux.intel.com>
  Zhenyu Wang<zhenyuw@linux.intel.com>
  Zhiqiang Liu <liuzhiqiang26@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   7a56db0299f9..ae83d0b416db  ae83d0b416db002fe95601e7f97f64b59514d936 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 04:07:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 04:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR6fU-0008Ff-H5; Wed, 22 Apr 2020 04:07:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jR6fT-0008Fa-Ih
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 04:07:23 +0000
X-Inumbo-ID: c17bf734-844e-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c17bf734-844e-11ea-b4f4-bc764e2007e4;
 Wed, 22 Apr 2020 04:07:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=q8mX2eH9rU5rtVGBrckLfA8MpaDTOodZiOpBsQRXbJU=; b=kby01qVlXvPwXNyjVopGMcA4X
 CYmJAJ8el35fho08b+7hpNPs/Df9L97fI4Xy2/AOwrqOESqyR+khgJLYAUgUmwNbEXBoj804hXO8R
 sH6dpTzG37PqrAn9f40/lMg3xYzxkmf17SKJEgTp2ufUauyX2VZ+ouyhgycB4zTjPk6PQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR6fN-0006mo-BN; Wed, 22 Apr 2020 04:07:17 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jR6fM-0002Qi-O7; Wed, 22 Apr 2020 04:07:16 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jR6fM-0002Zm-NF; Wed, 22 Apr 2020 04:07:16 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149712-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [seabios test] 149712: tolerable FAIL - PUSHED
X-Osstest-Failures: seabios:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 seabios:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 seabios:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 seabios:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 seabios:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 seabios:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 seabios:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
X-Osstest-Versions-This: seabios=eaaf726038cb9b2d01312d6430b4e93842aa96eb
X-Osstest-Versions-That: seabios=6a3b59ab9c7dc00331c21346052dfa6a0df45aa3
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 04:07:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149712 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149712/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149211
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149211
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149211
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149211
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 seabios              eaaf726038cb9b2d01312d6430b4e93842aa96eb
baseline version:
 seabios              6a3b59ab9c7dc00331c21346052dfa6a0df45aa3

Last test of basis   149211  2020-03-30 13:24:09 Z   22 days
Testing same since   149712  2020-04-21 10:44:40 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/seabios.git
   6a3b59a..eaaf726  eaaf726038cb9b2d01312d6430b4e93842aa96eb -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 06:48:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 06:48:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR9Ao-0006rS-Ry; Wed, 22 Apr 2020 06:47:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=AaA6=6G=xen.org=tim@srs-us1.protection.inumbo.net>)
 id 1jR9An-0006rL-S9
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 06:47:53 +0000
X-Inumbo-ID: 301208bc-8465-11ea-b58d-bc764e2007e4
Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 301208bc-8465-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 06:47:52 +0000 (UTC)
Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD))
 (envelope-from <tim@xen.org>)
 id 1jR9Aj-000BFu-Ve; Wed, 22 Apr 2020 06:47:49 +0000
Date: Wed, 22 Apr 2020 07:47:49 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2 2/4] x86/shadow: sh_update_linear_entries() is a no-op
 for PV
Message-ID: <20200422064749.GA43182@deinos.phlegethon.org>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <c90b72a8-9145-f0fb-8490-4d62a674eed7@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <c90b72a8-9145-f0fb-8490-4d62a674eed7@suse.com>
User-Agent: Mutt/1.11.1 (2018-12-01)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
 SAEximRunCond expanded to false
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

At 11:11 +0200 on 21 Apr (1587467497), Jan Beulich wrote:
> Consolidate the shadow_mode_external() in here: Check this once at the
> start of the function.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Tim Deegan <tim@xen.org>
> ---
> v2: Delete stale part of comment.
> ---
> Tim - I'm re-posting as I wasn't entirely sure whether you meant to drop
> the entire PV part of the comment, or only the last two sentences.

Looks good, thanks!

Acked-by: Tim Deegan <tim@xen.org>


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 06:48:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 06:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.89)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jR9B6-0006u7-5z; Wed, 22 Apr 2020 06:48:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <SRS0=AaA6=6G=xen.org=tim@srs-us1.protection.inumbo.net>)
 id 1jR9B4-0006tl-My
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 06:48:10 +0000
X-Inumbo-ID: 3a90050a-8465-11ea-9e09-bc764e2007e4
Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3a90050a-8465-11ea-9e09-bc764e2007e4;
 Wed, 22 Apr 2020 06:48:10 +0000 (UTC)
Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD))
 (envelope-from <tim@xen.org>)
 id 1jR9B3-000BGG-GD; Wed, 22 Apr 2020 06:48:09 +0000
Date: Wed, 22 Apr 2020 07:48:09 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86/shadow: make sh_remove_write_access() helper HVM only
Message-ID: <20200422064809.GB43182@deinos.phlegethon.org>
References: <2a339346-ed09-22b6-88fb-6f9d997b10b4@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <2a339346-ed09-22b6-88fb-6f9d997b10b4@suse.com>
User-Agent: Mutt/1.11.1 (2018-12-01)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
 SAEximRunCond expanded to false
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

At 14:05 +0200 on 21 Apr (1587477956), Jan Beulich wrote:
> Despite the inline attribute at least some clang versions warn about
> trace_shadow_wrmap_bf() being unused in !HVM builds. Include the helper
> in the #ifdef region.
> 
> Fixes: 8b8d011ad868 ("x86/shadow: the guess_wrmap() hook is needed for HVM only")
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Tim Deegan <tim@xen.org>


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 07:57:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 07:57:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRAFA-0007VO-GT; Wed, 22 Apr 2020 07:56:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1SgQ=6G=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRAF8-0007VI-AS
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 07:56:26 +0000
X-Inumbo-ID: c329b5f6-846e-11ea-9e09-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c329b5f6-846e-11ea-9e09-bc764e2007e4;
 Wed, 22 Apr 2020 07:56:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587542186;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=DfDeNp+iCCsiAIDZvvALimFgTCBS7+oN9x/w2MadkKk=;
 b=fSOuLHr6khbgCEWHtDoS1S/d2mHj5SPZl41ri91nL2oaloPlGQuGyCpK
 zhSzYhGjRGKRTZTx4nieW5tnDrNHRwgFGjlKcK491Tpcj5x/U4+1StQWU
 bTXuMp3Zg1pDanN4+FTzyUz02BzjFcWQhmD2DI4WRr7EydgCA99KX3QjC g=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: SkDqbVlerrzvnEVk/b/6m3nBvc6sIAQPzp0mEnGKPtFZvl3Jsi3UAG7F+i2osJTpEMfFfz5b1M
 WLye/oICbSrDcI3lomoUJUc9FUlgYg/4zRJJisgos7G/geNTUJdewsPp6T1idubM7ecjSWfBPn
 QuYqTmo1Nu7YzyBWfQBaCi+0f67Noga03kOSnp67b3CwjjcdaPzmIy2cESwOyPk0j+d43Qfh1Q
 iNQMQ1cckJTNlOb94pOHggkPO1XatvCfCDJLSM9WIwuton1gt07n3IX1SN6eHWIfFnfWF+wYKf
 PFY=
X-SBRS: 2.7
X-MesageID: 16065250
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,412,1580792400"; d="scan'208";a="16065250"
Date: Wed, 22 Apr 2020 09:56:14 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
Message-ID: <20200422075614.GZ28601@Air-de-Roger>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
 <20200421173010.GY28601@Air-de-Roger>
 <524885c7-5189-7215-41e6-1652a8bd08a2@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <524885c7-5189-7215-41e6-1652a8bd08a2@xen.org>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 07:44:55PM +0100, Julien Grall wrote:
> Hi,
> 
> On 21/04/2020 18:30, Roger Pau Monné wrote:
> > On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
> > > First of all avoid excessive conversions. copy_{from,to}_guest(), for
> > > example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
> > 
> > I'm not sure I understand the difference between those two, as they
> > are both placeholders for linear guest addresses?
> > 
> > AFAICT XEN_GUEST_HANDLE should be used for guest pointers inside of an
> > hypercall struct, while XEN_GUEST_HANDLE_PARAM is for guest pointers
> > as hypercall arguments. But those are both just guest pointers,
> > whether they are a parameter to the hypercall or a field in a
> > struct, and hence could use the same type?
> > 
> > I assume there's some reason for not doing so, and I see the comment
> > about other arches, but again a linear guest address is just that in
> > all arches, regardless of it's placement.
> 
> On Arm:
>  * XEN_GUEST_HANDLE() will always be 64-bit on both 32-bit and 64-bit
> hypervisor.
>  * XEN_GUEST_HANDLE_PARAM() will be 32-bit for 32-bit hypervisor. For 64-bit
> hypervisor, it will be 64-bit.
> 
> Per the ABI, each argument only fit a register. So you could not use
> XEN_GUEST_HANDLE() as now an argument will be held in 2 registers on 32-bit.
> 
> We also want the structure layout to be the same for 32-bit and 64-bit. So
> using XEN_GUEST_HANDLE_PARAM() everywhere is not the solution as the virtual
> address is not the same.

Right, you hide the 'padding' inside XEN_GUEST_HANDLE by making it
have a fixed size on all bitnesses, I can see how that's not
desirable for hypercall params though.

Iff we ever switch to an ABI that uses physical addresses instead of
linear ones we would have to switch everything to be a 64bit integer,
or else 32bit PAE won't work correctly. Or come up with a completely
different ABI (ie: use a pre-allocated set of buffer pages, IIRC as
suggested by Juergen).

> 
> We could possibly convert internally XEN_GUEST_HANDLE_PARAM() to
> XEN_GUEST_HANDLE(), but I am not sure how this would be beneficial. We would
> have to use 2 registers for arm 32-bit everytime.

Hm, we could maybe expand hypercall parameters to 64bit using some
kind of translation layer between the entry point and the actual
handler, but anyway, I get now there's a need to keep this difference.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 08:03:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 08:03:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRALd-0000Sd-RQ; Wed, 22 Apr 2020 08:03:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EBpN=6G=intel.com=kevin.tian@srs-us1.protection.inumbo.net>)
 id 1jRALc-0000SY-8U
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 08:03:08 +0000
X-Inumbo-ID: b194679c-846f-11ea-9238-12813bfff9fa
Received: from mga09.intel.com (unknown [134.134.136.24])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b194679c-846f-11ea-9238-12813bfff9fa;
 Wed, 22 Apr 2020 08:03:06 +0000 (UTC)
IronPort-SDR: k7XY5TUkW3kqkIKwMwJDU7gJeCtH1MkGbGbVVjRxIdfWo/3qyiO2+hSddPPqyBzdSD6V6c5+jE
 tUVOWhvE7kRQ==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga006.jf.intel.com ([10.7.209.51])
 by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 22 Apr 2020 01:03:05 -0700
IronPort-SDR: B8D5zln76yC8y2E9XKweAVTJ6kzxVfDz6mbmU9HIrU2cCBvRGIxQVvoSelc9Zs2Tl3Y1RecW2a
 7NwORHQYWPKg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,412,1580803200"; d="scan'208";a="258990228"
Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201])
 by orsmga006.jf.intel.com with ESMTP; 22 Apr 2020 01:03:05 -0700
Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by
 FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Wed, 22 Apr 2020 01:02:36 -0700
Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by
 fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.1713.5; Wed, 22 Apr 2020 01:02:36 -0700
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
 fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5
 via Frontend Transport; Wed, 22 Apr 2020 01:02:35 -0700
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.225]) by
 SHSMSX152.ccr.corp.intel.com ([169.254.6.209]) with mapi id 14.03.0439.000;
 Wed, 22 Apr 2020 16:02:34 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel
 <xen-devel@lists.xenproject.org>
Subject: RE: [PATCH 2/3] x86/boot: Don't enable EFER.SCE for !CONFIG_PV builds
Thread-Topic: [PATCH 2/3] x86/boot: Don't enable EFER.SCE for !CONFIG_PV builds
Thread-Index: AQHWFyRLs5sm5DaTOEa1b2TGziQ7AqiEylaw
Date: Wed, 22 Apr 2020 08:02:33 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D86F81E@SHSMSX104.ccr.corp.intel.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
 <20200420145911.5708-3-andrew.cooper3@citrix.com>
In-Reply-To: <20200420145911.5708-3-andrew.cooper3@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Jan Beulich <JBeulich@suse.com>,
 =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

PiBGcm9tOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPg0KPiBTZW50
OiBNb25kYXksIEFwcmlsIDIwLCAyMDIwIDEwOjU5IFBNDQo+IA0KPiBUaGlzIHdpbGwgY2F1c2Ug
YWxsIFNZU0NBTEwvU1lTUkVUIGluc3RydWN0aW9ucyB0byBzdWZmZXIgI1VEIHJhdGhlciB0aGFu
DQo+IGZvbGxvd2luZyB0aGUgTVNSX3tMLEN9U1RBUiBwb2ludGVycywgYWxsb3dpbmcgdXMgdG8g
ZHJvcCB0aGUgc3Rhcl9lbnRlcigpDQo+IHBhbmljIGhlbHBlciwgYWxsb3dpbmcgdXMgdG8gY2xl
YW4gdXAgdGhlIElTVCBzdGFja3MgaW4gYSBzdWJzZXF1ZW50IHBhdGNoLg0KPiANCj4gRHJvcCB0
aGUgbm93LWRlYWQgY29uZGl0aW9uYWwgU1lTRU5URVIgbG9naWMgaW4gdGhlIG1pZGRsZSBvZg0K
PiBzdWJhcmNoX3BlcmNwdV90cmFwc19pbml0KCkuDQo+IA0KPiBJbiBhZGRpdGlvbiwgdm14X3Jl
c3RvcmVfaG9zdF9tc3JzKCkgbmVlZCBub3QgcmVzdG9yZSBhbnkgaG9zdA0KPiBzdGF0ZS4gIChS
ZWdhcmRpbmcgdGhlIGFzeW1tZXRyaWMgY2hhbmdlcywgVlQteCBhdXRvbWF0aWNhbGx5IHJlc3Rv
cmVzDQo+IFNZU0VOVEVSIHN0YXRlIG9uIHZtZXhpdCwgYW5kIFNWTSByZXN0b3JlcyBib3RoIFNZ
U0NBTEwvU1lTRU5URVIgc3RhdGUNCj4gd2l0aA0KPiB0aGUgVk1TQVZFL1ZNTE9BRCBpbnN0cnVj
dGlvbnMuKQ0KPiANCj4gU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3Bl
cjNAY2l0cml4LmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEtldmluIFRpYW4gPGtldmluLnRpYW5AaW50
ZWwuY29tPg0K


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 08:07:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 08:07:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRAPK-0000id-D0; Wed, 22 Apr 2020 08:06:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=l+vI=6G=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRAPJ-0000iY-VJ
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 08:06:57 +0000
X-Inumbo-ID: 3c6b4dac-8470-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3c6b4dac-8470-11ea-9e09-bc764e2007e4;
 Wed, 22 Apr 2020 08:06:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=exj9V+erqRuRhmyNX+YAr66nhM+cm67YdLn2LyxfvWc=; b=Ho7Mz8EKiPjHxy/QWl/zLfLNKo
 mrqXhGFQljc+C/OgauViN0mdQcneFSt31mIs36kXXTAs7RrHgUtXpBOXlqdJ+5smN0AgS3hTOiPRm
 Qub2xtFIKIB1dNKEEMQCA5VlhKovqdQxPQQTT2ChLw5X7/oRjfTdN76EyObkCekTMbk0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRAPH-0005wR-QM; Wed, 22 Apr 2020 08:06:55 +0000
Received: from 54-240-197-228.amazon.com ([54.240.197.228]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRAPH-0002Il-JN; Wed, 22 Apr 2020 08:06:55 +0000
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
 <20200421173010.GY28601@Air-de-Roger>
 <524885c7-5189-7215-41e6-1652a8bd08a2@xen.org>
 <20200422075614.GZ28601@Air-de-Roger>
From: Julien Grall <julien@xen.org>
Message-ID: <541acfc7-0032-c58f-f8b5-5ed1e9ea034c@xen.org>
Date: Wed, 22 Apr 2020 09:06:53 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200422075614.GZ28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 22/04/2020 08:56, Roger Pau Monné wrote:
> On Tue, Apr 21, 2020 at 07:44:55PM +0100, Julien Grall wrote:
>> Hi,
>>
>> On 21/04/2020 18:30, Roger Pau Monné wrote:
>>> On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
>>>> First of all avoid excessive conversions. copy_{from,to}_guest(), for
>>>> example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
>>>
>>> I'm not sure I understand the difference between those two, as they
>>> are both placeholders for linear guest addresses?
>>>
>>> AFAICT XEN_GUEST_HANDLE should be used for guest pointers inside of an
>>> hypercall struct, while XEN_GUEST_HANDLE_PARAM is for guest pointers
>>> as hypercall arguments. But those are both just guest pointers,
>>> whether they are a parameter to the hypercall or a field in a
>>> struct, and hence could use the same type?
>>>
>>> I assume there's some reason for not doing so, and I see the comment
>>> about other arches, but again a linear guest address is just that in
>>> all arches, regardless of it's placement.
>>
>> On Arm:
>>   * XEN_GUEST_HANDLE() will always be 64-bit on both 32-bit and 64-bit
>> hypervisor.
>>   * XEN_GUEST_HANDLE_PARAM() will be 32-bit for 32-bit hypervisor. For 64-bit
>> hypervisor, it will be 64-bit.
>>
>> Per the ABI, each argument only fit a register. So you could not use
>> XEN_GUEST_HANDLE() as now an argument will be held in 2 registers on 32-bit.
>>
>> We also want the structure layout to be the same for 32-bit and 64-bit. So
>> using XEN_GUEST_HANDLE_PARAM() everywhere is not the solution as the virtual
>> address is not the same.
> 
> Right, you hide the 'padding' inside XEN_GUEST_HANDLE by making it
> have a fixed size on all bitnesses, I can see how that's not
> desirable for hypercall params though.
> 
> Iff we ever switch to an ABI that uses physical addresses instead of
> linear ones we would have to switch everything to be a 64bit integer,
> or else 32bit PAE won't work correctly. Or come up with a completely
> different ABI (ie: use a pre-allocated set of buffer pages, IIRC as
> suggested by Juergen).

I would go further here and request the arguments to always be the same 
size regardless the bitness.

> 
>>
>> We could possibly convert internally XEN_GUEST_HANDLE_PARAM() to
>> XEN_GUEST_HANDLE(), but I am not sure how this would be beneficial. We would
>> have to use 2 registers for arm 32-bit everytime.
> 
> Hm, we could maybe expand hypercall parameters to 64bit using some
> kind of translation layer between the entry point and the actual
> handler, but anyway, I get now there's a need to keep this difference.

This can be done today using guest_handle_from_param manually.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 08:17:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 08:17:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRAZL-00019t-GM; Wed, 22 Apr 2020 08:17:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=l+vI=6G=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRAZJ-00019o-OU
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 08:17:17 +0000
X-Inumbo-ID: adf0604c-8471-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id adf0604c-8471-11ea-b4f4-bc764e2007e4;
 Wed, 22 Apr 2020 08:17:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=bs4RCcJj1vtgZkHUIrOjbXNxo36I+mFDfybWCo5xYdM=; b=jV0/ja0MxRJwa3gVg1V9y/s3ru
 kelRXBWER6MUiTJsuAWC+JHCt+C+0Y03FDbsY7MhKkhSa+Csrod1KGLgX6x2jXFxd19OjDFLGRBXX
 LFH/emlaKmHYlmH5rXCWT2VZ6FkH6Xsnw4HAjeBESaAyVFeUzgfKs1hbKYtOlRX/6jGk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRAZF-0000S4-SE; Wed, 22 Apr 2020 08:17:13 +0000
Received: from 54-240-197-228.amazon.com ([54.240.197.228]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRAZF-0002tS-LR; Wed, 22 Apr 2020 08:17:13 +0000
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <9108f918-ee44-0740-48e0-7e0b0c761e1b@xen.org>
Date: Wed, 22 Apr 2020 09:17:11 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 21/04/2020 10:13, Jan Beulich wrote:
> First of all avoid excessive conversions. copy_{from,to}_guest(), for
> example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
> 
> Further
> - do_physdev_op_compat() didn't use the param form for its parameter,
> - {hap,shadow}_track_dirty_vram() wrongly used the param form,
> - compat processor Px logic failed to check compatibility of native and
>    compat structures not further converted.
> 
> As this eliminates all users of guest_handle_from_param() and as there's
> no real need to allow for conversions in both directions, drop the
> macros as well.

I was kind of expecting both guest_handle_from_param() and 
guest_handle_to_param() to be dropped together. May I ask why you still 
need guest_handle_to_param()?

[...]

>   /* Handler for shadow control ops: operations from user-space to enable
>    * and disable ephemeral shadow modes (test mode and log-dirty mode) and
> --- a/xen/include/xen/acpi.h
> +++ b/xen/include/xen/acpi.h
> @@ -184,8 +184,8 @@ static inline unsigned int acpi_get_csub
>   static inline void acpi_set_csubstate_limit(unsigned int new_limit) { return; }
>   #endif
>   
> -#ifdef XEN_GUEST_HANDLE_PARAM
> -int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32));
> +#ifdef XEN_GUEST_HANDLE
> +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32));
>   #endif

Do we really need to keep the #ifdef here?

>   int arch_acpi_set_pdc_bits(u32 acpi_id, u32 *, u32 mask);
>   
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 08:26:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 08:26:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRAi5-0002Di-Db; Wed, 22 Apr 2020 08:26:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1SgQ=6G=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRAi4-0002Dd-Gk
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 08:26:20 +0000
X-Inumbo-ID: f0393586-8472-11ea-9238-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f0393586-8472-11ea-9238-12813bfff9fa;
 Wed, 22 Apr 2020 08:26:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587543979;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=Y7amq8xTpcuto+AQMGhQqS4CzWMbMKrxCXwkwHmR2r8=;
 b=hMPJYR11ocR777uDreKmzjW9k1ke9AibE9lRu1b1LiPbHU0xpKojOa04
 h/abCdafzTEODLyj+AdDZ6QRzUc2ALVqkLkcQjDRD1KeFNFJhIM5CIVzk
 dIOutm6J7kQragrtrr/qOXRGwbroEcQrKB4V+QlNu3T/NiwnUgIWCPFZh U=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: xpqxiZcoef+9nCFki3DxDWdEbWTd4fpPy2cRsxIPb3iGxqYvE282B60LNx1l1+llOOpuvNHova
 1tZanj7Q6yvGFsqrtRLwcLLk/D6Zzuv3EwoijrW4VGrO1GtKDVjrcXFi533xwjVeNFwCQNPtqh
 UUVY7snCvZmgoyYa1aV8Uo4wL42GcZC3p3eeqsVTfjuojqNkKeo0uvijF21dSLqSUUes9smmGa
 0nxMevHXMVj8OyZJa5CHPRgwcc50mUqxo4RICgnbp1+UfYTWXIpQ0pLPrU9KMLRB15cvCPpdmG
 xxg=
X-SBRS: 2.7
X-MesageID: 16066424
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,413,1580792400"; d="scan'208";a="16066424"
Date: Wed, 22 Apr 2020 10:26:10 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
Message-ID: <20200422082610.GA28601@Air-de-Roger>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
> First of all avoid excessive conversions. copy_{from,to}_guest(), for
> example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
> 
> Further
> - do_physdev_op_compat() didn't use the param form for its parameter,
> - {hap,shadow}_track_dirty_vram() wrongly used the param form,
> - compat processor Px logic failed to check compatibility of native and
>   compat structures not further converted.
> 
> As this eliminates all users of guest_handle_from_param() and as there's
> no real need to allow for conversions in both directions, drop the
> macros as well.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -492,7 +492,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op
>      return ret;
>  }
>  
> -int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
> +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32) pdc)

Nit: switch to uint32_t while there?

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 08:57:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 08:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBC5-0002OB-KL; Wed, 22 Apr 2020 08:57:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=l+vI=6G=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRBC5-0002O6-0x
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 08:57:21 +0000
X-Inumbo-ID: 4647d67c-8477-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4647d67c-8477-11ea-9e09-bc764e2007e4;
 Wed, 22 Apr 2020 08:57:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=GT+ThNe2hh14lYny6gP0dey3DMvQfvU4coP96SK6oFo=; b=EK61mQF9+D/cFrMq1ZMKh0nPEj
 M3s2Y0RpFbY2AZXvQMFz+Xy30y4CV9ZGbmdkBuZOuX1y83Guswpn2X3xTNXB/1g0re+vv7z6tJ/o2
 w0s8R/Ppu04yoVKOjyK1kOiUb/f3oAsRY2IYQRcJx/FStryP/xahZ7Zruj2vEml/q1xs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRBC2-0000u8-Aj; Wed, 22 Apr 2020 08:57:18 +0000
Received: from 54-240-197-228.amazon.com ([54.240.197.228]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRBC1-0005nX-PV; Wed, 22 Apr 2020 08:57:17 +0000
Subject: Re: [PATCH v3 1/2] x86/HVM: expose VM assist hypercall
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <cb2dd3ad-2f38-1576-7743-7525e77704b5@suse.com>
 <5ed6b8a1-1f05-c24b-b3a8-d170a315d92a@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <2c5a677e-0327-8924-7ac3-2ae7d673be94@xen.org>
Date: Wed, 22 Apr 2020 09:57:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5ed6b8a1-1f05-c24b-b3a8-d170a315d92a@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 21/04/2020 15:39, Jan Beulich wrote:
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -269,6 +269,8 @@ static inline void free_vcpu_guest_conte
>   
>   static inline void arch_vcpu_block(struct vcpu *v) {}
>   
> +#define arch_vm_assist_valid_mask(d) (1UL << VMASST_TYPE_runstate_update_flag)

NIT: Do we want to evaluate d?

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:00:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBEi-0002mc-2k; Wed, 22 Apr 2020 09:00:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1SgQ=6G=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRBEg-0002gO-QI
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:00:02 +0000
X-Inumbo-ID: a609da9c-8477-11ea-b4f4-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a609da9c-8477-11ea-b4f4-bc764e2007e4;
 Wed, 22 Apr 2020 09:00:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587546001;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=1GQREWhDygLwdQroq/fpBH1lWkr/Pvaet3OjXeuuFnk=;
 b=idFuI91GJN9kO9sTEsgwb8BYsGI1Wpd2wuPuA+mLfAdYXir3TT3ioPfz
 cf4TB7lAqMX3jR9U1UMmCwcQ4AS6ncJnRiP/2ZsaDkRVhLfaJ7c/jnll2
 Dmr0tUlVtwDk3xldD6tnx3Prh90mzsphW9coJONsZXnOjB6GuaPzh3fAt o=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: K9ua9W/E+CRc044F6sqDf0U/VhPegaPyXX1zi8MzcBuojpVcBboMCSFYwyaaW0c+H9lAzn4iwZ
 sTw5syM29OUMd3FZ7kb41Bd8Nl4S08ndg/7WKU/9uRSJkKi+588Xg2diCcYGx15n0qj/9rErVe
 +chjKZ/CJrcDMhxvWqEuNMs1F5Q+OvidnPlZ0oBiR2qAD6Dbuhf2CW8reraLG/sfJIEGoWuX2n
 jwoMF5KovRL/73WNQyVe2GMXTSjVqbbZTmB1T+2Y20nPEq82mC3ykJrceTIw76F5fsxGywmaoe
 iTo=
X-SBRS: 2.7
X-MesageID: 16453007
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,413,1580792400"; d="scan'208";a="16453007"
Date: Wed, 22 Apr 2020 10:59:53 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Subject: Re: [PATCH v16 1/3] mem_sharing: fix sharability check during fork
 reset
Message-ID: <20200422085953.GB28601@Air-de-Roger>
References: <cover.1587490511.git.tamas.lengyel@intel.com>
 <8eb756357cb6d9222ed7ec4c0af58473160361a1.1587490511.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <8eb756357cb6d9222ed7ec4c0af58473160361a1.1587490511.git.tamas.lengyel@intel.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 10:47:23AM -0700, Tamas K Lengyel wrote:
> When resetting a VM fork we ought to only remove pages that were allocated for
> the fork during it's execution and the contents copied over from the parent.
> This can be determined if the page is sharable as special pages used by the
> fork for other purposes will not pass this test.

Would it be easier to just check if the page refcount is > 1? (as I
expect Xen is also holding a reference to this page)

> Unfortunately during the fork
> reset loop we only partially check whether that's the case. A page's type may
> indicate it is sharable (pass p2m_is_sharable) but that's not a sufficient
> check by itself. All checks that are normally performed before a page is
> converted to the sharable type need to be performed to avoid removing pages
> from the p2m that may be used for other purposes. For example, currently the
> reset loop also removes the vcpu info pages from the p2m, potentially putting
> the guest into infinite page-fault loops.
> 
> For this we extend the existing nominate_page and page_make_sharable functions
> to perform a validation-only run without actually converting the page.

Maybe you could split that chunk into a separate helper that just
performs the checks?

> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> ---
>  xen/arch/x86/mm/mem_sharing.c | 79 ++++++++++++++++++++++-------------
>  1 file changed, 50 insertions(+), 29 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index e572e9e39d..d8ed660abb 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -633,31 +633,35 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
>  /* Functions that change a page's type and ownership */
>  static int page_make_sharable(struct domain *d,
>                                struct page_info *page,
> -                              int expected_refcnt)
> +                              int expected_refcnt,
> +                              bool validate_only)
>  {
> -    bool_t drop_dom_ref;
> +    int rc;
> +    bool drop_dom_ref = false;
>  
> -    spin_lock(&d->page_alloc_lock);
> +    /* caller already has the lock when validating only */
> +    if ( !validate_only )
> +        spin_lock(&d->page_alloc_lock);

page_alloc_lock seems to be used as a recursive lock by some callers,
could you do the same here?

>  
>      if ( d->is_dying )
>      {
> -        spin_unlock(&d->page_alloc_lock);
> -        return -EBUSY;
> +        rc = -EBUSY;
> +        goto out;
>      }
>  
>      /* Change page type and count atomically */
>      if ( !get_page_and_type(page, d, PGT_shared_page) )
>      {
> -        spin_unlock(&d->page_alloc_lock);
> -        return -EINVAL;
> +        rc = -EINVAL;
> +        goto out;
>      }
>  
>      /* Check it wasn't already sharable and undo if it was */
>      if ( (page->u.inuse.type_info & PGT_count_mask) != 1 )
>      {
> -        spin_unlock(&d->page_alloc_lock);
>          put_page_and_type(page);
> -        return -EEXIST;
> +        rc = -EEXIST;
> +        goto out;
>      }
>  
>      /*
> @@ -666,20 +670,31 @@ static int page_make_sharable(struct domain *d,
>       */
>      if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
>      {
> -        spin_unlock(&d->page_alloc_lock);
>          /* Return type count back to zero */
>          put_page_and_type(page);
> -        return -E2BIG;
> +        rc = -E2BIG;
> +        goto out;
> +    }
> +
> +    rc = 0;
> +
> +    if ( validate_only )
> +    {
> +        put_page_and_type(page);

You seem to check some page attributes but then put the page again,
which looks racy to me. Since you put the page, couldn't the checks
that you have performed be stale by the point the data is consumed by
the caller?

> +        goto out;
>      }
>  
>      page_set_owner(page, dom_cow);
>      drop_dom_ref = !domain_adjust_tot_pages(d, -1);
>      page_list_del(page, &d->page_list);
> -    spin_unlock(&d->page_alloc_lock);
>  
> +out:
> +    if ( !validate_only )
> +        spin_unlock(&d->page_alloc_lock);
>      if ( drop_dom_ref )
>          put_domain(d);
> -    return 0;
> +
> +    return rc;
>  }
>  
>  static int page_make_private(struct domain *d, struct page_info *page)
> @@ -809,8 +824,8 @@ static int debug_gref(struct domain *d, grant_ref_t ref)
>      return debug_gfn(d, gfn);
>  }
>  
> -static int nominate_page(struct domain *d, gfn_t gfn,
> -                         int expected_refcnt, shr_handle_t *phandle)
> +static int nominate_page(struct domain *d, gfn_t gfn, int expected_refcnt,

Is there any reason for expected_refcnt to be signed? All callers use
unsigned values.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:04:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBIh-0003Tw-Pp; Wed, 22 Apr 2020 09:04:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9j4T=6G=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRBIf-0003Tr-Nr
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:04:09 +0000
X-Inumbo-ID: 3974c1c0-8478-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3974c1c0-8478-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 09:04:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BCCDBAB8F;
 Wed, 22 Apr 2020 09:04:06 +0000 (UTC)
Subject: Re: [PATCH v3 1/2] x86/HVM: expose VM assist hypercall
To: Julien Grall <julien@xen.org>
References: <cb2dd3ad-2f38-1576-7743-7525e77704b5@suse.com>
 <5ed6b8a1-1f05-c24b-b3a8-d170a315d92a@suse.com>
 <2c5a677e-0327-8924-7ac3-2ae7d673be94@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e5a28434-d6c9-f920-d8a8-070cb23c62a4@suse.com>
Date: Wed, 22 Apr 2020 11:04:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <2c5a677e-0327-8924-7ac3-2ae7d673be94@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 22.04.2020 10:57, Julien Grall wrote:
> On 21/04/2020 15:39, Jan Beulich wrote:
>> --- a/xen/include/asm-arm/domain.h
>> +++ b/xen/include/asm-arm/domain.h
>> @@ -269,6 +269,8 @@ static inline void free_vcpu_guest_conte
>>     static inline void arch_vcpu_block(struct vcpu *v) {}
>>   +#define arch_vm_assist_valid_mask(d) (1UL << VMASST_TYPE_runstate_update_flag)
> 
> NIT: Do we want to evaluate d?

I didn't think we need to, given the very limited use of the
macro.

> Reviewed-by: Julien Grall <jgrall@amazon.com>

Thanks.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:05:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:05:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBJV-0003Wy-36; Wed, 22 Apr 2020 09:05:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=l+vI=6G=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRBJT-0003Wn-Sn
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:04:59 +0000
X-Inumbo-ID: 57dc4d86-8478-11ea-9243-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 57dc4d86-8478-11ea-9243-12813bfff9fa;
 Wed, 22 Apr 2020 09:04:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=zs3Pw5DcilVBapi9zJ1ao2CuIyx+5LpXrstCOQiZJTQ=; b=2KB6NCl4LyjA8YwfBJsBq4BUjO
 +mQNUrm30/CalGOvtZxscH9ZFC5pmWIn+gWLmz0PViAFnyvSgfZyC+dvJZawTJztBOu5bPkRPpLcn
 6GjHbwPzaGhftgSgKxpIjQsCvcjuDfBn1Dr5drBrh4WYmXgJGTpmgz5BBymCXoGBdLmM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRBJR-00015r-L3; Wed, 22 Apr 2020 09:04:57 +0000
Received: from 54-240-197-228.amazon.com ([54.240.197.228]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRBJR-0006dj-4l; Wed, 22 Apr 2020 09:04:57 +0000
Subject: Re: [PATCH v3 1/2] x86/HVM: expose VM assist hypercall
To: Jan Beulich <jbeulich@suse.com>
References: <cb2dd3ad-2f38-1576-7743-7525e77704b5@suse.com>
 <5ed6b8a1-1f05-c24b-b3a8-d170a315d92a@suse.com>
 <2c5a677e-0327-8924-7ac3-2ae7d673be94@xen.org>
 <e5a28434-d6c9-f920-d8a8-070cb23c62a4@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <d3a5ce02-58c1-85e6-9470-eccdfdd8a3ae@xen.org>
Date: Wed, 22 Apr 2020 10:04:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e5a28434-d6c9-f920-d8a8-070cb23c62a4@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 22/04/2020 10:04, Jan Beulich wrote:
> On 22.04.2020 10:57, Julien Grall wrote:
>> On 21/04/2020 15:39, Jan Beulich wrote:
>>> --- a/xen/include/asm-arm/domain.h
>>> +++ b/xen/include/asm-arm/domain.h
>>> @@ -269,6 +269,8 @@ static inline void free_vcpu_guest_conte
>>>      static inline void arch_vcpu_block(struct vcpu *v) {}
>>>    +#define arch_vm_assist_valid_mask(d) (1UL << VMASST_TYPE_runstate_update_flag)
>>
>> NIT: Do we want to evaluate d?
> 
> I didn't think we need to, given the very limited use of the
> macro.

Fair point. I thought I would ask just in case.

> 
>> Reviewed-by: Julien Grall <jgrall@amazon.com>
> 
> Thanks.
> 
> Jan
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:09:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:09:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBNm-0003k8-KR; Wed, 22 Apr 2020 09:09:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1SgQ=6G=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRBNl-0003k3-AR
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:09:25 +0000
X-Inumbo-ID: f5a84984-8478-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f5a84984-8478-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 09:09:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587546564;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=cSW/KbbCI2axUz4DTYkDiScIu1rTDjrq9O3+zsPfUs0=;
 b=bikCVD9taPNexJ/+CCfl2So7YwMLZBR6WOOMWVfit0pWqVSu7gWFIlUL
 IZAHx01eBBcEQJ36LPyvAb2w/IhdiVwZAtKQm6GT3EMvXlsWHsFQj+/r1
 uN8BeTOut62xNduchwlbOpuA3EOcM6G1U2pTF1PKXunHyxsKe3UPlYvUh k=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 2SdP0RQUfpGRAIGxEy+PujQSXpVTtmwbY85KSLJ4Q/c67Y5eURsp8GNRYZ3dZvHrJU+WFg2vPJ
 q1PNiBdGRrJQ4cl34Fmw451My/BQFdUGs4+dy/5Uv36KghVx3jy1MShHaeANTCv4rPA2qAyx6U
 D4WdBegs+q5Fqe11+wigfRhSCscjinW8XLXIITOItkWVxm/lbyBpa9dxaFak6MK0Ti3wZUvRcq
 suwGplWGwDgwlDbKNyvj+vHG7msrFJD8P9+3UrgxuuhdPDzA/Dm3Xa8R1LFva+bmVqPgcsaSfS
 BVs=
X-SBRS: 2.7
X-MesageID: 16732824
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,413,1580792400"; d="scan'208";a="16732824"
Date: Wed, 22 Apr 2020 11:09:11 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Subject: Re: [PATCH v16 2/3] mem_sharing: allow forking domain with IOMMU
 enabled
Message-ID: <20200422090911.GC28601@Air-de-Roger>
References: <cover.1587490511.git.tamas.lengyel@intel.com>
 <c958f3776e602143efb2fb7c146a0c18a3fcd262.1587490511.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c958f3776e602143efb2fb7c146a0c18a3fcd262.1587490511.git.tamas.lengyel@intel.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Stefano
 Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 10:47:24AM -0700, Tamas K Lengyel wrote:
> The memory sharing subsystem by default doesn't allow a domain to share memory
> if it has an IOMMU active for obvious security reasons. However, when fuzzing a
> VM fork, the same security restrictions don't necessarily apply. While it makes
> no sense to try to create a full fork of a VM that has an IOMMU attached as only
> one domain can own the pass-through device at a time, creating a shallow fork
> without a device model is still very useful for fuzzing kernel-mode drivers.
> 
> By allowing the parent VM to initialize the kernel-mode driver with a real
> device that's pass-through, the driver can enter into a state more suitable for
> fuzzing. Some of these initialization steps are quite complex and are easier to
> perform when a real device is present. After the initialization, shallow forks
> can be utilized for fuzzing code-segments in the device driver that don't
> directly interact with the device.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:11:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBPf-0004b4-0O; Wed, 22 Apr 2020 09:11:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9j4T=6G=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRBPd-0004az-Tx
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:11:21 +0000
X-Inumbo-ID: 3a9271f1-8479-11ea-9243-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3a9271f1-8479-11ea-9243-12813bfff9fa;
 Wed, 22 Apr 2020 09:11:20 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id F1BDDAE39;
 Wed, 22 Apr 2020 09:11:18 +0000 (UTC)
Subject: Re: [PATCH v3] Introduce a description of the Backport and Fixes tags
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200417222430.20480-1-sstabellini@kernel.org>
 <5d33d469-9aba-5285-766a-193d7109712d@suse.com>
 <alpine.DEB.2.21.2004211117460.24585@sstabellini-ThinkPad-T480s>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7b2d1e94-ccac-756a-d80e-397cef4b53a2@suse.com>
Date: Wed, 22 Apr 2020 11:11:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004211117460.24585@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: lars.kurth@citrix.com, julien@xen.org, Wei Liu <wl@xen.org>,
 konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>, george.dunlap@citrix.com,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 20:22, Stefano Stabellini wrote:
> On Mon, 20 Apr 2020, Jan Beulich wrote:
>> On 18.04.2020 00:24, Stefano Stabellini wrote:
>> Previously I did suggest to add an indication that people requesting
>> backports should also be prepare to actually help with backporting.
>> I don't recall a verbal reply, and I also don't see any respective
>> update here. (I'm not fully trusting our mail system, i.e. it may
>> very well be that I did miss a reply.)
> 
> 
> I didn't reply, but I added two lines in that regards, see also above:
> 
>>> +Maintainers might ask the requester to help with the backporting work if
>>> +it is not trivial.

Oh, sorry, I simply didn't notice it in the place you put it.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:20:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:20:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBYI-0005S0-UN; Wed, 22 Apr 2020 09:20:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9j4T=6G=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRBYH-0005Rv-0K
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:20:17 +0000
X-Inumbo-ID: 79df70a1-847a-11ea-9248-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 79df70a1-847a-11ea-9248-12813bfff9fa;
 Wed, 22 Apr 2020 09:20:16 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A2528AC52;
 Wed, 22 Apr 2020 09:20:13 +0000 (UTC)
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
 <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
Date: Wed, 22 Apr 2020 11:20:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 22.04.2020 01:27, Stefano Stabellini wrote:
> On Mon, 20 Apr 2020, Jan Beulich wrote:
>> On 20.04.2020 15:34, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 20/04/2020 09:04, Jan Beulich wrote:
>>>> On 19.04.2020 12:49, Julien Grall wrote:
>>>>> --- a/docs/misc/pvcalls.pandoc
>>>>> +++ b/docs/misc/pvcalls.pandoc
>>>>> @@ -246,9 +246,7 @@ The format is defined as follows:
>>>>>                   uint32_t domain;
>>>>>                   uint32_t type;
>>>>>                   uint32_t protocol;
>>>>> -                #ifdef CONFIG_X86_32
>>>>>                   uint8_t pad[4];
>>>>> -                #endif
>>>>>               } socket;
>>>>>               struct xen_pvcalls_connect {
>>>>>                   uint64_t id;
>>>>> @@ -257,16 +255,12 @@ The format is defined as follows:
>>>>>                   uint32_t flags;
>>>>>                   grant_ref_t ref;
>>>>>                   uint32_t evtchn;
>>>>> -                #ifdef CONFIG_X86_32
>>>>>                   uint8_t pad[4];
>>>>> -                #endif
>>>>>               } connect;
>>>>>               struct xen_pvcalls_release {
>>>>>                   uint64_t id;
>>>>>                   uint8_t reuse;
>>>>> -                #ifdef CONFIG_X86_32
>>>>>                   uint8_t pad[7];
>>>>> -                #endif
>>>>>               } release;
>>>>>               struct xen_pvcalls_bind {
>>>>>                   uint64_t id;
>>>>> @@ -276,9 +270,7 @@ The format is defined as follows:
>>>>>               struct xen_pvcalls_listen {
>>>>>                   uint64_t id;
>>>>>                   uint32_t backlog;
>>>>> -                #ifdef CONFIG_X86_32
>>>>>                   uint8_t pad[4];
>>>>> -                #endif
>>>>>               } listen;
>>>>>               struct xen_pvcalls_accept {
>>>>>                   uint64_t id;
>>>>
>>>> I wonder on what grounds these #ifdef-s had been there - they're
>>>> plain wrong with the types used in the public header.
>>>>
>>>>> --- a/xen/include/public/io/pvcalls.h
>>>>> +++ b/xen/include/public/io/pvcalls.h
>>>>> @@ -65,6 +65,7 @@ struct xen_pvcalls_request {
>>>>>               uint32_t domain;
>>>>>               uint32_t type;
>>>>>               uint32_t protocol;
>>>>> +            uint8_t pad[4];
>>>>>           } socket;
>>>>>           struct xen_pvcalls_connect {
>>>>>               uint64_t id;
>>>>> @@ -73,10 +74,12 @@ struct xen_pvcalls_request {
>>>>>               uint32_t flags;
>>>>>               grant_ref_t ref;
>>>>>               uint32_t evtchn;
>>>>> +            uint8_t pad[4];
>>>>>           } connect;
>>>>>           struct xen_pvcalls_release {
>>>>>               uint64_t id;
>>>>>               uint8_t reuse;
>>>>> +            uint8_t pad[7];
>>>>>           } release;
>>>>>           struct xen_pvcalls_bind {
>>>>>               uint64_t id;
>>>>> @@ -86,6 +89,7 @@ struct xen_pvcalls_request {
>>>>>           struct xen_pvcalls_listen {
>>>>>               uint64_t id;
>>>>>               uint32_t backlog;
>>>>> +            uint8_t pad[4];
>>>>>           } listen;
>>>>
>>>> I'm afraid we can't change these in such a way - your additions
>>>> change sizeof() for the respective sub-structures on 32-bit x86,
>>>> and hence this is not a backwards compatible adjustment. 
>>>
>>> This is a bit confusing, each structure contain a 64-bit field so
>>> I would have thought it the structure would be 8-byte aligned (as
>>> on 32-bit Arm). But looking at the spec, a uint64_t will only
>>> aligned to 4-byte.
>>>
>>> However, I am not sure why sizeof() matters here. I understand
>>> the value would be different, but AFAICT, this is not used as part
>>> of the protocol.
>>
>> Two independent components of a consumer of our interface could
>> have a function taking (pointer to) struct xen_pvcalls_connect.
>> If one component gets re-built with the new definition and the
>> other doesn't, they'll disagree on what range of memory needs
>> to be accessible. The instantiating side (using the old header)
>> may have ended up placing the struct immediately ahead of a
>> page boundary. The consuming side (using the changed header)
>> would then encounter a fault if it wanted to access the struct
>> as a whole (assignment, memcpy()).
> 
> Even if it was possible to use the sub-structs defined in the header
> that way, keep in mind that we also wrote:
> 
>         /* dummy member to force sizeof(struct xen_pvcalls_request)
>          * to match across archs */
>         struct xen_pvcalls_dummy {
>             uint8_t dummy[56];
>         } dummy;

This has nothing to do with how a consumer may use the structs.

> And the spec also clarifies that the size of each specific request is
> always 56 bytes.

Sure, and I didn't mean to imply that a consumer would be allowed
to break this requirement. Still something like this

int pvcall_new_socket(struct xen_pvcalls_socket *s) {
    struct xen_pvcalls_request req = {
        .req_id = REQ_ID,
        .cmd = PVCALLS_SOCKET,
        .u.socket = *s,
    };

    return pvcall(&req);
}

may break.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:28:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:28:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBfn-0005mj-R6; Wed, 22 Apr 2020 09:28:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9j4T=6G=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRBfm-0005me-Qi
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:28:02 +0000
X-Inumbo-ID: 8f8e1324-847b-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8f8e1324-847b-11ea-9e09-bc764e2007e4;
 Wed, 22 Apr 2020 09:28:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A645CAEB8;
 Wed, 22 Apr 2020 09:27:59 +0000 (UTC)
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
 <20200422082610.GA28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f7df284f-ba06-b7ce-b843-690c81521a75@suse.com>
Date: Wed, 22 Apr 2020 11:27:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200422082610.GA28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 22.04.2020 10:26, Roger Pau Monné wrote:
> On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
>> --- a/xen/drivers/acpi/pmstat.c
>> +++ b/xen/drivers/acpi/pmstat.c
>> @@ -492,7 +492,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op
>>      return ret;
>>  }
>>  
>> -int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
>> +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32) pdc)
> 
> Nit: switch to uint32_t while there?

Ah, yes.

> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:30:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBi6-0006X0-7g; Wed, 22 Apr 2020 09:30:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=cUjI=6G=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jRBi4-0006Wu-NG
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:30:24 +0000
X-Inumbo-ID: e44e818c-847b-11ea-b4f4-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e44e818c-847b-11ea-b4f4-bc764e2007e4;
 Wed, 22 Apr 2020 09:30:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587547823;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=H1tzBodFfLZl2PzsVtHMvT84Jmeky0w/e8zXs1bdyBQ=;
 b=ZVnCvN7unU5aC7/dxaxoQwHEMvAP3pigyeOj4Lio0Zsn62F8EU26o3t4
 jA5vW728D5z1uC0Lg9jvnRCWtfSzDks+sm/DEKsYE9HfV5EIincHGwcp9
 Fdk+rZwdG1vV9zSWbl+RsLkXbw0PCVvwEZ+MPyNbB1B+gZGtWHPqeCZ+b 0=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: vcc7NVwL3g0jnfCKRteDH5h5+L8cJyhUS5T0e7Wf+c8b0CI3CzKvYt7JbWDFX3jTKe33y89q70
 0yUIJgVCkPo+xj1bBj1D6uG3RRyG5v9NdqY2E/DHncuqS6y9fu8sTTYqjVTBaYW5gcZUfFQbKN
 k67JkvhlyzioqmctBRopaFFxtyx5ipfrD0sZ5bXVPEyeK3c5YyqN6Ss9bBNXbjW5jM1hnYXqI/
 N6RucdKo5fjhrogunF35QQIshgSH6YyPEeTAeRw1O96d7NPe5oXvKLvKhEZDHUpIiMoXpiFSJm
 O5I=
X-SBRS: 2.7
X-MesageID: 16733751
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,413,1580792400"; d="scan'208";a="16733751"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v3] sched: print information about scheduling granularity
Date: Wed, 22 Apr 2020 10:30:10 +0100
Message-ID: <20200422093010.12940-1-sergey.dyasli@citrix.com>
X-Mailer: git-send-email 2.17.1
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sergey Dyasli <sergey.dyasli@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Currently it might be not obvious which scheduling mode (e.g. core-
scheduling) is being used by the scheduler. Alleviate this by printing
additional information about the selected granularity per-cpupool.

Note: per-cpupool granularity selection is not implemented yet. Every
      cpupool gets its granularity from the single global value.

Take this opportunity to introduce struct sched_gran_name array and
refactor sched_select_granularity().

Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
---
v3:
- use const char*
- use sched_gran_name array instead of switch
- updated commit message

v2:
- print information on a separate line
- use per-cpupool granularity
- updated commit message

CC: Juergen Gross <jgross@suse.com>
CC: Dario Faggioli <dfaggioli@suse.com>
CC: George Dunlap <george.dunlap@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
---
 xen/common/sched/cpupool.c | 51 +++++++++++++++++++++++++++++++-------
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index d40345b585..b60799a558 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -40,19 +40,50 @@ static DEFINE_SPINLOCK(cpupool_lock);
 static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
 static unsigned int __read_mostly sched_granularity = 1;
 
+struct sched_gran_name {
+    enum sched_gran mode;
+    const char *name;
+};
+
+static const struct sched_gran_name sg_name[] = {
+    {SCHED_GRAN_cpu, "cpu"},
+    {SCHED_GRAN_core, "core"},
+    {SCHED_GRAN_socket, "socket"},
+};
+
+static void sched_gran_print(enum sched_gran mode, unsigned int gran)
+{
+    const char *name = "";
+    unsigned int i;
+
+    for ( i = 0; i < ARRAY_SIZE(sg_name); i++ )
+    {
+        if ( mode == sg_name[i].mode )
+        {
+            name = sg_name[i].name;
+            break;
+        }
+    }
+
+    printk("Scheduling granularity: %s, %u CPU%s per sched-resource\n",
+           name, gran, gran == 1 ? "" : "s");
+}
+
 #ifdef CONFIG_HAS_SCHED_GRANULARITY
 static int __init sched_select_granularity(const char *str)
 {
-    if ( strcmp("cpu", str) == 0 )
-        opt_sched_granularity = SCHED_GRAN_cpu;
-    else if ( strcmp("core", str) == 0 )
-        opt_sched_granularity = SCHED_GRAN_core;
-    else if ( strcmp("socket", str) == 0 )
-        opt_sched_granularity = SCHED_GRAN_socket;
-    else
-        return -EINVAL;
+    unsigned int i;
 
-    return 0;
+    for ( i = 0; i < ARRAY_SIZE(sg_name); i++ )
+    {
+        if ( strcmp(sg_name[i].name, str) == 0 )
+        {
+            opt_sched_granularity = sg_name[i].mode;
+            return 0;
+        }
+    }
+
+    return -EINVAL;
 }
 custom_param("sched-gran", sched_select_granularity);
 #endif
@@ -115,6 +146,7 @@ static void __init cpupool_gran_init(void)
         warning_add(fallback);
 
     sched_granularity = gran;
+    sched_gran_print(opt_sched_granularity, sched_granularity);
 }
 
 unsigned int cpupool_get_granularity(const struct cpupool *c)
@@ -911,6 +943,7 @@ void dump_runq(unsigned char key)
     {
         printk("Cpupool %d:\n", (*c)->cpupool_id);
         printk("Cpus: %*pbl\n", CPUMASK_PR((*c)->cpu_valid));
+        sched_gran_print((*c)->gran, cpupool_get_granularity(*c));
         schedule_dump(*c);
     }
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:32:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRBjn-0006lQ-JG; Wed, 22 Apr 2020 09:32:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9j4T=6G=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRBjm-0006lL-4E
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:32:10 +0000
X-Inumbo-ID: 234e687a-847c-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 234e687a-847c-11ea-b4f4-bc764e2007e4;
 Wed, 22 Apr 2020 09:32:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A1DB9AE52;
 Wed, 22 Apr 2020 09:32:07 +0000 (UTC)
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
To: Julien Grall <julien@xen.org>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
 <9108f918-ee44-0740-48e0-7e0b0c761e1b@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <2025316a-de36-91d9-521c-547af668f919@suse.com>
Date: Wed, 22 Apr 2020 11:32:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9108f918-ee44-0740-48e0-7e0b0c761e1b@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 22.04.2020 10:17, Julien Grall wrote:
> On 21/04/2020 10:13, Jan Beulich wrote:
>> First of all avoid excessive conversions. copy_{from,to}_guest(), for
>> example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
>>
>> Further
>> - do_physdev_op_compat() didn't use the param form for its parameter,
>> - {hap,shadow}_track_dirty_vram() wrongly used the param form,
>> - compat processor Px logic failed to check compatibility of native and
>>    compat structures not further converted.
>>
>> As this eliminates all users of guest_handle_from_param() and as there's
>> no real need to allow for conversions in both directions, drop the
>> macros as well.
> 
> I was kind of expecting both guest_handle_from_param() and
> guest_handle_to_param() to be dropped together. May I ask why
> you still need guest_handle_to_param()?

There are three (iirc) uses left which I don't really see how
to sensibly replace. Take a look at the different callers of
x86's vcpumask_to_pcpumask(), for example.

>> --- a/xen/include/xen/acpi.h
>> +++ b/xen/include/xen/acpi.h
>> @@ -184,8 +184,8 @@ static inline unsigned int acpi_get_csub
>>   static inline void acpi_set_csubstate_limit(unsigned int new_limit) { return; }
>>   #endif
>>   -#ifdef XEN_GUEST_HANDLE_PARAM
>> -int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32));
>> +#ifdef XEN_GUEST_HANDLE
>> +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32));
>>   #endif
> 
> Do we really need to keep the #ifdef here?

I think so, yes, or else the original one wouldn't have been
needed either. (Consider the header getting included without
any of the public headers having got included first.) Dropping
(if it was possible) this would be an orthogonal change imo.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 09:58:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 09:58:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRC9L-0000Lz-MD; Wed, 22 Apr 2020 09:58:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRC9K-0000Lu-75
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 09:58:34 +0000
X-Inumbo-ID: cee8856e-847f-11ea-924e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cee8856e-847f-11ea-924e-12813bfff9fa;
 Wed, 22 Apr 2020 09:58:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=MQBmOnL/bai8WT6lXnGaBxTwKILIHtVuc5OOFpNR+4Q=; b=maNOwoDMF0ngxQkS3VOMW3Mss
 4L+vjsRVufWIUDGiQvMXjvldSwQkB9R1sSZkkw9kUIN3ijHtHzap99fSVCEDGwVmqjk5mR12MJAQ9
 6v8chEtKHvDK0w46Mug60cvvsBz0bTuguhyVNEnHW34LDkBjzDOk5LWdA8NZjC1js40D8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRC9B-0002ID-EG; Wed, 22 Apr 2020 09:58:25 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRC9A-0003h2-VS; Wed, 22 Apr 2020 09:58:25 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRC9A-0002BW-Up; Wed, 22 Apr 2020 09:58:24 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149734-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-coverity test] 149734: all pass - PUSHED
X-Osstest-Versions-This: xen=5730ac3c8346f56fe8ee90249cdcbdab2a4d5791
X-Osstest-Versions-That: xen=fcd06227f83643194f8018f8dd37adce57763a61
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 09:58:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen                  5730ac3c8346f56fe8ee90249cdcbdab2a4d5791
baseline version:
 xen                  fcd06227f83643194f8018f8dd37adce57763a61

Last test of basis   149674  2020-04-15 09:19:13 Z    7 days
Testing same since   149734  2020-04-22 09:18:32 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christian Lindig <christian.lindig@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  Harsha Shamsundara Havanur <havanur@amazon.com>
  Hongyan Xia <hongyxia@amazon.com>
  Jan Beulich <jbeulich@suse.com>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Julien Grall <jgrall@amazon.com>
  Julien Grall <julien@xen.org>
  Peng Fan <peng.fan@nxp.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Sergey Dyasli <sergey.dyasli@citrix.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@citrix.com>
  Wei Liu <wl@xen.org>

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
   fcd06227f8..5730ac3c83  5730ac3c8346f56fe8ee90249cdcbdab2a4d5791 -> coverity-tested/smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 10:50:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 10:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRCxM-0005jD-IV; Wed, 22 Apr 2020 10:50:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9j4T=6G=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRCxL-0005j8-LX
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 10:50:15 +0000
X-Inumbo-ID: 0bdf5acc-8487-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0bdf5acc-8487-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 10:50:14 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id F1F18AC22;
 Wed, 22 Apr 2020 10:50:12 +0000 (UTC)
Subject: Re: [PATCH v3] sched: print information about scheduling granularity
To: Sergey Dyasli <sergey.dyasli@citrix.com>
References: <20200422093010.12940-1-sergey.dyasli@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <b8f74570-fc9f-61c5-7e52-c2a50e8350dc@suse.com>
Date: Wed, 22 Apr 2020 12:50:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200422093010.12940-1-sergey.dyasli@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
 George Dunlap <george.dunlap@citrix.com>, Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 22.04.2020 11:30, Sergey Dyasli wrote:
> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -40,19 +40,50 @@ static DEFINE_SPINLOCK(cpupool_lock);
>  static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
>  static unsigned int __read_mostly sched_granularity = 1;
>  
> +struct sched_gran_name {
> +    enum sched_gran mode;
> +    const char *name;
> +};
> +
> +static const struct sched_gran_name sg_name[] = {
> +    {SCHED_GRAN_cpu, "cpu"},
> +    {SCHED_GRAN_core, "core"},
> +    {SCHED_GRAN_socket, "socket"},
> +};

Personally I think that in cases like this one it is more
(space) efficient to use char[8] or so for the second
struct member.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 11:20:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 11:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRDQ0-0007xG-18; Wed, 22 Apr 2020 11:19:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRDPy-0007xB-GQ
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 11:19:50 +0000
X-Inumbo-ID: 2b0dc236-848b-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2b0dc236-848b-11ea-9e09-bc764e2007e4;
 Wed, 22 Apr 2020 11:19:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=AqOxmstzLKpNFy3WEwwajuEeQ7vUM5/UPPJOFcxe2bw=; b=XQJGfqRuEGuLMcrDp+umcD3t6
 M9dNnjAArYZrU3QyRqpHaDCcO+5bgg5dkYHutZBf99TjnvGzboyu7IPYfCZ+5mNcjnNFTzp2xrwFk
 hoHSHG0NHOFZkdrBxjWpZGyvvasXfR8p0rcUZANjL0LHJ4MBXDNthbTtTb8jS0hm8JbKo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRDPs-00049q-Eb; Wed, 22 Apr 2020 11:19:44 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRDPs-0008SA-1i; Wed, 22 Apr 2020 11:19:44 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRDPs-0004vH-14; Wed, 22 Apr 2020 11:19:44 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149725-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149725: all pass - PUSHED
X-Osstest-Versions-This: ovmf=b447a20bdfb2ff24ba048bb3026c902c4768a7e9
X-Osstest-Versions-That: ovmf=6e3c834ae47d1201c4ddcc6a6adc5e44718c7617
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 11:19:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 b447a20bdfb2ff24ba048bb3026c902c4768a7e9
baseline version:
 ovmf                 6e3c834ae47d1201c4ddcc6a6adc5e44718c7617

Last test of basis   149708  2020-04-21 10:39:57 Z    1 days
Testing same since   149725  2020-04-21 20:09:37 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@arm.com>
  Hao A Wu <hao.a.wu@intel.com>
  Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   6e3c834ae4..b447a20bdf  b447a20bdfb2ff24ba048bb3026c902c4768a7e9 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 11:45:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 11:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRDoJ-0002Fu-4j; Wed, 22 Apr 2020 11:44:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRDoH-0002Fp-6g
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 11:44:57 +0000
X-Inumbo-ID: acbc77d4-848e-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id acbc77d4-848e-11ea-9e09-bc764e2007e4;
 Wed, 22 Apr 2020 11:44:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=27Bb+ApY9d5w1PB9ZsXVwTVXtAFYVqT43G558emIHx8=; b=ALhGoPNb42qO9EnynGwVHxSuS
 Av8vXIptBivmb+yJJdByrGDeetfAn+pDOq8DWrW+yrOdxRhtkewOUP71z9QxpnvGCL0eAWcbm8342
 YSikuMl6C2CMVpXEAuniKtAUP6CHrOFIl/ZgoRgHJYeJl8qEHRSwoZn/71rnn88MCK1gA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRDoA-0004eg-CK; Wed, 22 Apr 2020 11:44:50 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRDoA-0001i5-4b; Wed, 22 Apr 2020 11:44:50 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRDoA-0007jP-40; Wed, 22 Apr 2020 11:44:50 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149723-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149723: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=3119154db04890fdf57022a43cf2ee594fd4da5a
X-Osstest-Versions-That: qemuu=20038cd7a8412feeb49c01f6ede89e36c8995472
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 11:44:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149723 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149723/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149681

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149681
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149681
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149681
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149681
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149681
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass

version targeted for testing:
 qemuu                3119154db04890fdf57022a43cf2ee594fd4da5a
baseline version:
 qemuu                20038cd7a8412feeb49c01f6ede89e36c8995472

Last test of basis   149681  2020-04-16 02:09:07 Z    6 days
Testing same since   149706  2020-04-21 10:39:06 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Chen Qun <kuhn.chenqun@huawei.com>
  Cédric Le Goater <clg@kaod.org>
  David Gibson <david@gibson.dropbear.id.au>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Laurent Vivier <laurent@vivier.eu>
  Nathan Chancellor <natechancellor@gmail.com>
  Nicholas Piggin <npiggin@gmail.com>
  Peter Maydell <peter.maydell@linaro.org>
  Philippe Mathieu-Daudé <f4bug@amsat.org>
  Richard Henderson <richard.henderson@linaro.org>
  Sergei Trofimovich <slyfox@gentoo.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   20038cd7a8..3119154db0  3119154db04890fdf57022a43cf2ee594fd4da5a -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 12:19:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 12:19:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jREL9-0005AO-UY; Wed, 22 Apr 2020 12:18:55 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jREL8-0005AJ-N5
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 12:18:54 +0000
X-Inumbo-ID: 69ce797e-8493-11ea-926b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 69ce797e-8493-11ea-926b-12813bfff9fa;
 Wed, 22 Apr 2020 12:18:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=cMOPaOLK42hQvOgzGUzV5yI//1yskD+hq/9Wvsrzi40=; b=OGw/VPSiU9Elcp6b+i/VMKLfN
 Gp8eipnsoJO7x33nd/Q7bK4hmkqahrrswUbqIe8y+cBewRIy0xmVlHN5eB4jD7X1oEjbGVyKl2c9K
 ceu5w5lC/YYZpTwXUb2ZrfjUekurvG9NMqmv/wumLK6r2j47lQ+gGHMOEA9b8zbckbPes=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jREL0-0005NA-6Z; Wed, 22 Apr 2020 12:18:46 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jREKz-0003Yu-U4; Wed, 22 Apr 2020 12:18:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jREKz-0004Dx-TT; Wed, 22 Apr 2020 12:18:45 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149733-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149733: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=17b094b97c823c956c57e31c5cd7175d56b3efe4
X-Osstest-Versions-That: xen=5730ac3c8346f56fe8ee90249cdcbdab2a4d5791
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 12:18:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149733 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149733/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  17b094b97c823c956c57e31c5cd7175d56b3efe4
baseline version:
 xen                  5730ac3c8346f56fe8ee90249cdcbdab2a4d5791

Last test of basis   149727  2020-04-22 00:01:31 Z    0 days
Testing same since   149733  2020-04-22 09:02:41 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   5730ac3c83..17b094b97c  17b094b97c823c956c57e31c5cd7175d56b3efe4 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 12:20:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 12:20:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jREMV-0005tq-AA; Wed, 22 Apr 2020 12:20:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=yehR=6G=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jREMT-0005tg-UZ
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 12:20:18 +0000
X-Inumbo-ID: 9f34712a-8493-11ea-926b-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9f34712a-8493-11ea-926b-12813bfff9fa;
 Wed, 22 Apr 2020 12:20:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587558015;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=uybLuVdkqaTFdLBCFX6aVDoWpAdWDrb62FwYzc00iR8=;
 b=dpj0Jpjrk9unop8RUl90n48HQc8sCvBMjxL4EXHEEqrqDZfhclD7rRSi
 DkZLymXyBhdtnCS5MMVfvk8Hn46yf65Xjhqxj/ns9EeULn2fgWSXTso6x
 b5gTxGfxM0iX+3mdiKbn+Y8W7Af+/JMfuKkHK3/P1qg94PYuZkaUyKSYh 0=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: IHRhp7IM1jZirlKm2mYv1r6iQd0LFBKt7B5KpGdpNWZtPb8z0hH5jYsAwEnEuZ1UuSK0e6YzPc
 V6HkO57CahywqKTXqxpBGGhY41KXvLJy5sSC4BRymasx8j+DksX5xG/MiBWVPtrNfJXZfJrEXv
 Se9NJGb5f5rh18kWGae/58aP2FCin0GO1KQnvS8xrMtFYQyRnpvyjJErWHUykeS0EJWaKcP/Q+
 6Cxf7WBI7CjEG1UKA4KX6lLnszkC8Fmgp9jcb2MCZwBa3aJCh6F492xL6lUlQpvnO2vanOSlQ/
 b7U=
X-SBRS: 2.7
X-MesageID: 16461383
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,414,1580792400"; d="scan'208";a="16461383"
Subject: Re: [PATCH 01/10] x86/mm: no-one passes a NULL domain to
 init_xen_l4_slots()
To: Jan Beulich <jbeulich@suse.com>
References: <65bfcd6a-2bb0-da6f-9e85-39f224bd81fb@suse.com>
 <19d7ad4f-c653-b7b6-59a8-90c9700c9200@suse.com>
 <68542638-b5d5-3261-8088-d0cd6e2dcd74@citrix.com>
 <757e4a8b-f60d-1c5c-fe11-b1d22980f09e@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <9432cd11-3d40-76b7-b033-08aab274172a@citrix.com>
Date: Wed, 22 Apr 2020 13:20:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <757e4a8b-f60d-1c5c-fe11-b1d22980f09e@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Tim
 Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/04/2020 06:48, Jan Beulich wrote:
> On 17.04.2020 21:46, Andrew Cooper wrote:
>> On 17/04/2020 15:25, Jan Beulich wrote:
>>> Drop the NULL checks - they've been introduced by commit 8d7b633ada
>>> ("x86/mm: Consolidate all Xen L4 slot writing into
>>> init_xen_l4_slots()") for no apparent reason.
>> :) I'll take this as conformation that all my sudden pagetable work in
>> Xen manage ended up being rather more subtle than Linux's equivalent
>> work for KPTI.
>>
>> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00281.html
>>
>> Specifically, this was part of trying to arrange for fully per-pcpu
>> private mappings, and was used to construct the pagetables for the idle
>> vcpu which specifically don't have a perdomain mapping.
>>
>> Seeing as this is still an outstanding task in the secret-free-Xen
>> plans, any dropping of it now will have to be undone at some point in
>> the future.
> s/will/may/ I suppose - we don't know for sure how this will look
> like at this point.

Will.

The only reason we don't need it right now is because idle_pg_table[]
gets constructed at boot time.  As soon as we're creating one (or more)
per pcpu, we need a way of writing an L4 without a perdomain mapping.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 12:32:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 12:32:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jREYO-00074d-HP; Wed, 22 Apr 2020 12:32:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mXoo=6G=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jREYN-00074Y-4d
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 12:32:35 +0000
X-Inumbo-ID: 577bd894-8495-11ea-83d8-bc764e2007e4
Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 577bd894-8495-11ea-83d8-bc764e2007e4;
 Wed, 22 Apr 2020 12:32:34 +0000 (UTC)
Received: by mail-ed1-x541.google.com with SMTP id t12so1348305edw.3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 05:32:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=mBPOSEUY1oXRJqJRPsCtY53O3+dkrXrAH33/WuR+SJ4=;
 b=WUaCAyWhoC8B3P15XdCYUIp3BSoXcMhe1KLfAm658VjRI/l9Nkll5UK7Q9dfnauRsD
 CJRIMAhVcYvuUYGY/jXFX6XqLAFiqaQDGjCnWduxfr2zQXvefMIkyV1ZEd7jBTZ9KWcN
 txKXMUjCR7SKYJwnPfct+0HUeAE4fHLUQrM8MFPGKF3N26nMWH89ZHuhKwf0/FVrUnSs
 2RDgXDllmTrAAUTiwj6wMjWPKbJx4IYz+wEgMzA0P/Wy1lnbNt6+qbD77v7OySNqbXWz
 bL/cJdGsqwi0HPXUFYZe0ZNIpdzCwK/BvLMQxeQ76w1UBcRG6ccBixLaeHeYtHCAovJt
 LJAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=mBPOSEUY1oXRJqJRPsCtY53O3+dkrXrAH33/WuR+SJ4=;
 b=K8aH95OOplWImZ4oFgYlBJESHFJn8ejHIOZ08MJZgGp8SbGhEUQPTHbezVxP7CVaTP
 lFghk2cdT+44GKonqKOghZCdSzyiPEbjGKpjos/6Rf0ZSsMBlJcDXQB0sAFEOIAu9cWX
 9PoYvGPUe87CLPPSlTrLDVD1JXIv85U/tuXkVoy0HUJr3qluR84stVSvLCiGvDaZ9k5a
 tyJ8BwWWbqoCXErIImBENVgQQJvAmbrA1t283C8zTL32c0RCm3nDB4LIjNFK45s5O/pf
 eFdmGf1kDG5/7yXiQKCUYqTMoFHSI6V1t5D1KpcX86kSWidk+Idf7leURUaVkVqa55Fz
 bk+Q==
X-Gm-Message-State: AGi0PuaUpILaDEP/op48jU1+d3zz3ojM8B4DnOryON0YlAVJ0mTDFgFK
 NAK7N/kdHp0G8QwVQdUHQ630WcqhUAg=
X-Google-Smtp-Source: APiQypKMoNk8wby8t5D2DGWdWvB4gh3KhMZgAftfJttwN+y0FYahYK5tl+LElutF0DvVuYhIfX6BXg==
X-Received: by 2002:a50:f058:: with SMTP id u24mr21845199edl.171.1587558753287; 
 Wed, 22 Apr 2020 05:32:33 -0700 (PDT)
Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com.
 [209.85.128.41])
 by smtp.gmail.com with ESMTPSA id hh1sm929567ejb.46.2020.04.22.05.32.31
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 22 Apr 2020 05:32:32 -0700 (PDT)
Received: by mail-wm1-f41.google.com with SMTP id v4so4837307wme.1
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 05:32:31 -0700 (PDT)
X-Received: by 2002:a1c:4c10:: with SMTP id z16mr10496624wmf.77.1587558751325; 
 Wed, 22 Apr 2020 05:32:31 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587490511.git.tamas.lengyel@intel.com>
 <c958f3776e602143efb2fb7c146a0c18a3fcd262.1587490511.git.tamas.lengyel@intel.com>
 <20200422090911.GC28601@Air-de-Roger>
In-Reply-To: <20200422090911.GC28601@Air-de-Roger>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Wed, 22 Apr 2020 06:31:54 -0600
X-Gmail-Original-Message-ID: <CABfawhnxTBcV4oZpWubYYfPaYG8-3bG-GbgC11mxFrSmRfAuEA@mail.gmail.com>
Message-ID: <CABfawhnxTBcV4oZpWubYYfPaYG8-3bG-GbgC11mxFrSmRfAuEA@mail.gmail.com>
Subject: Re: [PATCH v16 2/3] mem_sharing: allow forking domain with IOMMU
 enabled
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 22, 2020 at 3:09 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.com>=
 wrote:
>
> On Tue, Apr 21, 2020 at 10:47:24AM -0700, Tamas K Lengyel wrote:
> > The memory sharing subsystem by default doesn't allow a domain to share=
 memory
> > if it has an IOMMU active for obvious security reasons. However, when f=
uzzing a
> > VM fork, the same security restrictions don't necessarily apply. While =
it makes
> > no sense to try to create a full fork of a VM that has an IOMMU attache=
d as only
> > one domain can own the pass-through device at a time, creating a shallo=
w fork
> > without a device model is still very useful for fuzzing kernel-mode dri=
vers.
> >
> > By allowing the parent VM to initialize the kernel-mode driver with a r=
eal
> > device that's pass-through, the driver can enter into a state more suit=
able for
> > fuzzing. Some of these initialization steps are quite complex and are e=
asier to
> > perform when a real device is present. After the initialization, shallo=
w forks
> > can be utilized for fuzzing code-segments in the device driver that don=
't
> > directly interact with the device.
> >
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
>
> Reviewed-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>

Thanks! This can be merged independent of the other patches in the series.

Tamas


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 12:43:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 12:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jREip-00085K-Jn; Wed, 22 Apr 2020 12:43:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mXoo=6G=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jREio-00085F-N4
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 12:43:22 +0000
X-Inumbo-ID: d927fe76-8496-11ea-b4f4-bc764e2007e4
Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d927fe76-8496-11ea-b4f4-bc764e2007e4;
 Wed, 22 Apr 2020 12:43:21 +0000 (UTC)
Received: by mail-ej1-x642.google.com with SMTP id x1so1731032ejd.8
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 05:43:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=IuQCr5WXRmfAZXY/oAwjRLg3LntkbJRVPIjlT0Xz4ZE=;
 b=DCC6+C8mcc7b5sAHRV4xj4X/RWVzN2xcMdShrMXQHscIoXwD7RTLiXFn1RsoCmokt4
 99NeYdUoC6f7aD1rRv4ejj21QkxhOE7IgHWrphaCo+ryV1ZrLULTFtiIhqDYYIOZjUAw
 qh/8ZAiM31pVcx6o08GsSt20vGRcu39qyFJlB0vBQZD7lq6nepgmvEDe7OrPFkN6my9u
 fJwg+jJtABfszfY7GxkOZTPx1mKJzPCVxSwtjJM2RpoTfiV3J2hc8AuKUTYvFeasATtn
 w0Xhi0NL3yGv9vcuLTtfEWoKyJgBgm+oCTX+yjpB7/8pNNOs01eIcZjXKK1kDojLQNpQ
 PqyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=IuQCr5WXRmfAZXY/oAwjRLg3LntkbJRVPIjlT0Xz4ZE=;
 b=WYkG3fAWoJnoIdRW5M81Y9aPb1IDmO1uxTnPZdJW7fmu3D6Z+liiSMg7+x/qEZEkkI
 FEKBb67QgXXBUX9X90Bm5u2soBVabaSfAaChJUYjuulyyRip6RYz4SzpN7UspjX9Lrf5
 r3yOflEDxz17x+YVdGaNO1p4kpHmzVEtJitzjxUd69JNFqIjlVn0O17bS6EqAUfoi8kk
 T6tRqgPeu7+rzgYCEI6mK6U19lhRWzm5ZlZeQT3641Nmmw0iINx7m3MNmKdZOmsLpy0g
 x5QFh+MuK7GwtIsOyw2MbiZF6uJ2TNdsQy9xZuldmFE8ENzr9GQufvI8bC5Hdvsdcqhv
 ytWA==
X-Gm-Message-State: AGi0PuagUmjSJOzzJ/94kPVZxHQbv47i7vcgNCumKn1yMfM//tXAiRni
 FOPcNxbO8RRr53Y5/Q+6vEWmnnpQPtM=
X-Google-Smtp-Source: APiQypKrYpklhsS2DGHtMAwfR9XTJr2ZoEWTaX2XlZl/E2ToBh6Zur7Cq9dlN1EL0UoBQ0Nl4X+xHQ==
X-Received: by 2002:a17:906:4e46:: with SMTP id
 g6mr25313432ejw.36.1587559400278; 
 Wed, 22 Apr 2020 05:43:20 -0700 (PDT)
Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com.
 [209.85.128.47])
 by smtp.gmail.com with ESMTPSA id t12sm921928ejx.30.2020.04.22.05.43.18
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 22 Apr 2020 05:43:19 -0700 (PDT)
Received: by mail-wm1-f47.google.com with SMTP id y24so2189554wma.4
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 05:43:18 -0700 (PDT)
X-Received: by 2002:a05:600c:220c:: with SMTP id
 z12mr10191128wml.84.1587559398437; 
 Wed, 22 Apr 2020 05:43:18 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587490511.git.tamas.lengyel@intel.com>
 <8eb756357cb6d9222ed7ec4c0af58473160361a1.1587490511.git.tamas.lengyel@intel.com>
 <20200422085953.GB28601@Air-de-Roger>
In-Reply-To: <20200422085953.GB28601@Air-de-Roger>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Wed, 22 Apr 2020 06:42:42 -0600
X-Gmail-Original-Message-ID: <CABfawhmBW4kiv_mCUrH_JTdCDZWdbb7Qf65_i350apx-q7NXbg@mail.gmail.com>
Message-ID: <CABfawhmBW4kiv_mCUrH_JTdCDZWdbb7Qf65_i350apx-q7NXbg@mail.gmail.com>
Subject: Re: [PATCH v16 1/3] mem_sharing: fix sharability check during fork
 reset
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 22, 2020 at 3:00 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.com>=
 wrote:
>
> On Tue, Apr 21, 2020 at 10:47:23AM -0700, Tamas K Lengyel wrote:
> > When resetting a VM fork we ought to only remove pages that were alloca=
ted for
> > the fork during it's execution and the contents copied over from the pa=
rent.
> > This can be determined if the page is sharable as special pages used by=
 the
> > fork for other purposes will not pass this test.
>
> Would it be easier to just check if the page refcount is > 1? (as I
> expect Xen is also holding a reference to this page)

That by itself is not necessarily enough.

>
> > Unfortunately during the fork
> > reset loop we only partially check whether that's the case. A page's ty=
pe may
> > indicate it is sharable (pass p2m_is_sharable) but that's not a suffici=
ent
> > check by itself. All checks that are normally performed before a page i=
s
> > converted to the sharable type need to be performed to avoid removing p=
ages
> > from the p2m that may be used for other purposes. For example, currentl=
y the
> > reset loop also removes the vcpu info pages from the p2m, potentially p=
utting
> > the guest into infinite page-fault loops.
> >
> > For this we extend the existing nominate_page and page_make_sharable fu=
nctions
> > to perform a validation-only run without actually converting the page.
>
> Maybe you could split that chunk into a separate helper that just
> performs the checks?

I think it's fine this way that we just bail half-way through the
process of making the page shared. Splitting this out to a helper
would require a lot more code-shuffling.

>
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> > ---
> >  xen/arch/x86/mm/mem_sharing.c | 79 ++++++++++++++++++++++-------------
> >  1 file changed, 50 insertions(+), 29 deletions(-)
> >
> > diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharin=
g.c
> > index e572e9e39d..d8ed660abb 100644
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -633,31 +633,35 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
> >  /* Functions that change a page's type and ownership */
> >  static int page_make_sharable(struct domain *d,
> >                                struct page_info *page,
> > -                              int expected_refcnt)
> > +                              int expected_refcnt,
> > +                              bool validate_only)
> >  {
> > -    bool_t drop_dom_ref;
> > +    int rc;
> > +    bool drop_dom_ref =3D false;
> >
> > -    spin_lock(&d->page_alloc_lock);
> > +    /* caller already has the lock when validating only */
> > +    if ( !validate_only )
> > +        spin_lock(&d->page_alloc_lock);
>
> page_alloc_lock seems to be used as a recursive lock by some callers,
> could you do the same here?

We can do that, yes.

>
> >
> >      if ( d->is_dying )
> >      {
> > -        spin_unlock(&d->page_alloc_lock);
> > -        return -EBUSY;
> > +        rc =3D -EBUSY;
> > +        goto out;
> >      }
> >
> >      /* Change page type and count atomically */
> >      if ( !get_page_and_type(page, d, PGT_shared_page) )
> >      {
> > -        spin_unlock(&d->page_alloc_lock);
> > -        return -EINVAL;
> > +        rc =3D -EINVAL;
> > +        goto out;
> >      }
> >
> >      /* Check it wasn't already sharable and undo if it was */
> >      if ( (page->u.inuse.type_info & PGT_count_mask) !=3D 1 )
> >      {
> > -        spin_unlock(&d->page_alloc_lock);
> >          put_page_and_type(page);
> > -        return -EEXIST;
> > +        rc =3D -EEXIST;
> > +        goto out;
> >      }
> >
> >      /*
> > @@ -666,20 +670,31 @@ static int page_make_sharable(struct domain *d,
> >       */
> >      if ( page->count_info !=3D (PGC_allocated | (2 + expected_refcnt))=
 )
> >      {
> > -        spin_unlock(&d->page_alloc_lock);
> >          /* Return type count back to zero */
> >          put_page_and_type(page);
> > -        return -E2BIG;
> > +        rc =3D -E2BIG;
> > +        goto out;
> > +    }
> > +
> > +    rc =3D 0;
> > +
> > +    if ( validate_only )
> > +    {
> > +        put_page_and_type(page);
>
> You seem to check some page attributes but then put the page again,
> which looks racy to me. Since you put the page, couldn't the checks
> that you have performed be stale by the point the data is consumed by
> the caller?

During fork reset when this is called with validate_only =3D true the
domain is paused. Furthermore, fork reset is only for forks that have
no device model running, so nothing is interacting with its memory
that could acquire extra references. So no, this isn't racy since
there is nothing to race against that I'm aware of. Also, this check
is really to check for special pages, all of which are setup during
the initial fork process, not during runtime of the fork.

>
> > +        goto out;
> >      }
> >
> >      page_set_owner(page, dom_cow);
> >      drop_dom_ref =3D !domain_adjust_tot_pages(d, -1);
> >      page_list_del(page, &d->page_list);
> > -    spin_unlock(&d->page_alloc_lock);
> >
> > +out:
> > +    if ( !validate_only )
> > +        spin_unlock(&d->page_alloc_lock);
> >      if ( drop_dom_ref )
> >          put_domain(d);
> > -    return 0;
> > +
> > +    return rc;
> >  }
> >
> >  static int page_make_private(struct domain *d, struct page_info *page)
> > @@ -809,8 +824,8 @@ static int debug_gref(struct domain *d, grant_ref_t=
 ref)
> >      return debug_gfn(d, gfn);
> >  }
> >
> > -static int nominate_page(struct domain *d, gfn_t gfn,
> > -                         int expected_refcnt, shr_handle_t *phandle)
> > +static int nominate_page(struct domain *d, gfn_t gfn, int expected_ref=
cnt,
>
> Is there any reason for expected_refcnt to be signed? All callers use
> unsigned values.

No reason. It's just how the code was written by the original author
and we never changed it.

Tamas


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 13:07:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 13:07:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRF68-0001fl-La; Wed, 22 Apr 2020 13:07:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/xVI=6G=redhat.com=armbru@srs-us1.protection.inumbo.net>)
 id 1jRF67-0001fg-G8
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 13:07:27 +0000
X-Inumbo-ID: 36d9eb3a-849a-11ea-b58d-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 36d9eb3a-849a-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 13:07:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1587560846;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=4HJTMDpzbAUUU2nrkN9nZ+ekSAeo3tJy8O/pNLEoIcU=;
 b=enBEuahPp8P+QpX0ayMOyg3S/o6FP7TRvbi9+t/gqZwQxlqD4zwLxe5w9cAFoeAaluPlzP
 db9/BZQ5UIiNS93ckDo0sCf7anPzi1rOBKKgaZ9ZFhv5qGEqZ2uSetuCg6gto7t9pNK/ys
 5c8HiPqVSEEOSCOUAMNl0xjjsEO2SAc=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-459-qrfxHadDMEiHhCJ7_Dd9lA-1; Wed, 22 Apr 2020 09:07:24 -0400
X-MC-Unique: qrfxHadDMEiHhCJ7_Dd9lA-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
 [10.5.11.12])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7303A8EB022;
 Wed, 22 Apr 2020 13:07:23 +0000 (UTC)
Received: from blackfin.pond.sub.org (ovpn-113-6.ams2.redhat.com [10.36.113.6])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id 2395960C99;
 Wed, 22 Apr 2020 13:07:23 +0000 (UTC)
Received: by blackfin.pond.sub.org (Postfix, from userid 1000)
 id 1D92311358C5; Wed, 22 Apr 2020 15:07:20 +0200 (CEST)
From: Markus Armbruster <armbru@redhat.com>
To: qemu-devel@nongnu.org
Subject: [PATCH v2 09/14] xen/pt: Fix flawed conversion to realize()
Date: Wed, 22 Apr 2020 15:07:14 +0200
Message-Id: <20200422130719.28225-10-armbru@redhat.com>
In-Reply-To: <20200422130719.28225-1-armbru@redhat.com>
References: <20200422130719.28225-1-armbru@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <sstabellini@kernel.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The conversion of xen_pt_initfn() to xen_pt_realize() blindly replaced
XEN_PT_ERR() by error_setg().  Several error conditions that did not
fail xen_pt_initfn() now fail xen_pt_realize().  Unsurprisingly, the
cleanup on these errors looks highly suspicious.

Revert the inappropriate replacements.

Fixes: 5a11d0f7549e24a10e178a9dc8ff5e698031d9a6
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Paul Durrant <paul@xen.org>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Paul Durrant <paul@xen.org>
---
 hw/xen/xen_pt.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index b91082cb8b..81d5ad8da7 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -858,8 +858,8 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
=20
     rc =3D xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
     if (rc < 0) {
-        error_setg_errno(errp, errno, "Mapping machine irq %u to"
-                         " pirq %i failed", machine_irq, pirq);
+        XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (err: %d)=
\n",
+                   machine_irq, pirq, errno);
=20
         /* Disable PCI intx assertion (turn on bit10 of devctl) */
         cmd |=3D PCI_COMMAND_INTX_DISABLE;
@@ -880,8 +880,8 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
                                        PCI_SLOT(d->devfn),
                                        e_intx);
         if (rc < 0) {
-            error_setg_errno(errp, errno, "Binding of interrupt %u failed"=
,
-                             e_intx);
+            XEN_PT_ERR(d, "Binding of interrupt %i failed! (err: %d)\n",
+                       e_intx, errno);
=20
             /* Disable PCI intx assertion (turn on bit10 of devctl) */
             cmd |=3D PCI_COMMAND_INTX_DISABLE;
@@ -889,8 +889,8 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
=20
             if (xen_pt_mapped_machine_irq[machine_irq] =3D=3D 0) {
                 if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq))=
 {
-                    error_setg_errno(errp, errno, "Unmapping of machine"
-                            " interrupt %u failed", machine_irq);
+                    XEN_PT_ERR(d, "Unmapping of machine interrupt %i faile=
d!"
+                               " (err: %d)\n", machine_irq, errno);
                 }
             }
             s->machine_irq =3D 0;
--=20
2.21.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 22 13:08:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 13:08:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRF6f-0001i9-1z; Wed, 22 Apr 2020 13:08:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9hqk=6G=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jRF6d-0001hx-1b
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 13:07:59 +0000
X-Inumbo-ID: 4968f0de-849a-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4968f0de-849a-11ea-83d8-bc764e2007e4;
 Wed, 22 Apr 2020 13:07:58 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7FB5DABEC;
 Wed, 22 Apr 2020 13:07:56 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] xen/grants: fix hypercall continuation for
 GNTTABOP_cache_flush
Date: Wed, 22 Apr 2020 15:07:53 +0200
Message-Id: <20200422130753.14713-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The GNTTABOP_cache_flush hypercall has a wrong test for hypercall
continuation, the test today is:

    if ( rc > 0 || opaque_out != 0 )

Unfortunately this will be true even in case of an error (rc < 0),
possibly leading to very long lasting hypercalls (times of more
than an hour have been observed in a test case).

Correct the test condition to result in false with rc < 0 and set
opaque_out only if no error occurred, to be on the safe side.

Partially-suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/grant_table.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 96080b3dec..5ef7ff940d 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3626,12 +3626,12 @@ do_grant_table_op(
         if ( unlikely(!guest_handle_okay(cflush, count)) )
             goto out;
         rc = gnttab_cache_flush(cflush, &opaque_in, count);
-        if ( rc > 0 )
+        if ( rc >= 0 )
         {
             guest_handle_add_offset(cflush, rc);
             uop = guest_handle_cast(cflush, void);
+            opaque_out = opaque_in;
         }
-        opaque_out = opaque_in;
         break;
     }
 
@@ -3641,7 +3641,7 @@ do_grant_table_op(
     }
 
   out:
-    if ( rc > 0 || opaque_out != 0 )
+    if ( rc > 0 || (opaque_out != 0 && rc == 0) )
     {
         /* Adjust rc, see gnttab_copy() for why this is needed. */
         if ( cmd == GNTTABOP_copy )
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Wed Apr 22 13:17:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 13:17:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRFG9-0002oQ-0U; Wed, 22 Apr 2020 13:17:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1SgQ=6G=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRFG8-0002oL-FK
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 13:17:48 +0000
X-Inumbo-ID: a86c96f2-849b-11ea-927e-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a86c96f2-849b-11ea-927e-12813bfff9fa;
 Wed, 22 Apr 2020 13:17:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587561468;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=PGuUnY4JbJkTyuU6N67wb5IjbfVS7qgCj1NE4/JpsXY=;
 b=O/34rtX23qoEtxRP9zjq0PFqdB28I1VUehUBBzh1ojIM8jS/uGtQJRga
 kIiaHjm+CW/d31TBnAZPJ6NfXweXkUufM6ddun3RBQXQiSos2sO4Fr2mp
 LsZb7fIFYVmg3e7T15PMKjGPGKTrbsjEAf7DFu9m5dsMXSp8l04w7TwO0 g=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: XbmrQOrqPQdcPw2ZgxT0hgJ4QIMSz0TW1yGmvkcpTGs3BxQ6rFYiSJ8RqwKEksm19P/5jv4+r8
 Syr4cWnpNlt0zuODUbIPwErZRACkCWEAnJmgKo6EXNrjS48O6cCIzBZ5vCDJe3rmt9eDxNzuX9
 2m8WaojNiR7+cBsk5hN5U+ea6WOIVYUPsRwboNREtXiLysOdjU+YPCswtEnslrR91/gHQw5CUW
 sf8i9vxwbsLAAukvE411sYlntPj9RPnACqe/sOjUEQpye+3UKSuzxC6htz7dpeyV4PARghECW1
 tD4=
X-SBRS: 2.7
X-MesageID: 16314181
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,414,1580792400"; d="scan'208";a="16314181"
Date: Wed, 22 Apr 2020 15:17:36 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH] Introduce a description of the Backport and Fixes tags
Message-ID: <20200422131736.GD28601@Air-de-Roger>
References: <20200421182946.27337-1-sstabellini@kernel.org>
 <24223.16427.427446.817623@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <24223.16427.427446.817623@mariner.uk.xensource.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "lars.kurth@citrix.com" <lars.kurth@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, "julien@xen.org" <julien@xen.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 "jbeulich@suse.com" <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 21, 2020 at 07:49:15PM +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[PATCH] Introduce a description of the Backport and Fixes tags"):
> > Create a new document under docs/process to describe our special tags.
> > Add a description of the Fixes tag and the new Backport tag. Also
> > clarify that lines with tags should not be split.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > Acked-by: Wei Liu <wl@xen.org>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> > +When possible, please use the Fixes tag instead (or in addition).
> 
> Do we have any code to turn Fixes: into a list of commits to
> backport to a particular stable branch ?

I think we should have one of those, I've attempted something like:

#!/bin/sh -e

branch=$1
remote=$2

for fix in `git log ${remote}/master --grep='^Fixes:\s.*' --format="%H"`; do
    # Check if the fix is already part of the branch, in which case we have
    # gone backwards enough
    if git branch --contains $fix -r | \
       grep -q ${remote}/staging-${branch}; then
        break;
    fi
    bug=`git show $fix | grep -E '^\s*Fixes:\s.*' | awk '{ print $2 }'`
    # Append possible backports of the bug
    bugs="$bug `git log --grep="^master commit: $bug" --format="%H" --all` \
               `git log --grep="^(cherry picked from commit $bug" --format="%H" --all`"
    for bug in $bugs; do
        if ! git branch --contains $bug -r | \
             grep -q ${remote}/staging-${branch}; then
            continue
        fi
        # Check if fix has been backported
        fixes="`git log --grep="^master commit: $fix" --format="%H" --all` \
               `git log --grep="^(cherry picked from commit $fix" --format="%H" --all`"
        fixed=0
        for f in $fixes; do
            if git branch --contains $f -r | \
               grep -q ${remote}/staging-${branch}; then
                fixed=1
                break
            fi
        done
        if [ $fixed == 0 ]; then
            echo "$fix"
            break
        fi
    done
done

But it's hard to actually test whether it's correct. Seems to produce
some output, but I'm not sure whether it's missing commits, use as:

# ./check-branch.sh 4.12 origin

The script could also likely be cleaned up and improved, it's quite
ugly...

> If not it might be easier to ask people to add both Backport: and
> Fixes:.

I would like to avoid that, a Fixes tag should be enough for us to
figure out where the patch should be applied.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 13:44:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 13:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRFfD-0005ll-53; Wed, 22 Apr 2020 13:43:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=l+vI=6G=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRFfB-0005lf-Jh
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 13:43:41 +0000
X-Inumbo-ID: 4659c788-849f-11ea-9285-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4659c788-849f-11ea-9285-12813bfff9fa;
 Wed, 22 Apr 2020 13:43:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=JqRFwaQIjIR+ZrZsM+AUU9yy9fZziYRfNHECZiMPR6E=; b=k89ZoeMUNHdMX0S42JEFASMi6p
 aElH8CQcOMDcAnyI20BCrkamvS+q/ME4RvHXox1KifR+azkOFoRRvI3iWZ/aa0enPkfIkVbyMGJVX
 /WMR6iGIdiZgJja665hv3SNxvVsRZFe3zruC0bRVmlFffvzro99alrFWgNp0u6kt4oc4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRFf8-0007AQ-TO; Wed, 22 Apr 2020 13:43:38 +0000
Received: from 54-240-197-228.amazon.com ([54.240.197.228]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRFf8-0007ea-LP; Wed, 22 Apr 2020 13:43:38 +0000
Subject: Re: [PATCH] xen/grants: fix hypercall continuation for
 GNTTABOP_cache_flush
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
References: <20200422130753.14713-1-jgross@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <6ae77443-2703-614a-adfc-65bfacf27185@xen.org>
Date: Wed, 22 Apr 2020 14:43:36 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200422130753.14713-1-jgross@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Juergen,

On 22/04/2020 14:07, Juergen Gross wrote:
> The GNTTABOP_cache_flush hypercall has a wrong test for hypercall
> continuation, the test today is:
> 
>      if ( rc > 0 || opaque_out != 0 )
> 
> Unfortunately this will be true even in case of an error (rc < 0),
> possibly leading to very long lasting hypercalls (times of more
> than an hour have been observed in a test case).
> 
> Correct the test condition to result in false with rc < 0 and set
> opaque_out only if no error occurred, to be on the safe side.
> 
> Partially-suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>   xen/common/grant_table.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 96080b3dec..5ef7ff940d 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3626,12 +3626,12 @@ do_grant_table_op(
>           if ( unlikely(!guest_handle_okay(cflush, count)) )
>               goto out;
>           rc = gnttab_cache_flush(cflush, &opaque_in, count);
> -        if ( rc > 0 )
> +        if ( rc >= 0 )
>           {
>               guest_handle_add_offset(cflush, rc);
>               uop = guest_handle_cast(cflush, void);
> +            opaque_out = opaque_in;
>           }
> -        opaque_out = opaque_in;
>           break;
>       }
>   
> @@ -3641,7 +3641,7 @@ do_grant_table_op(
>       }
>   
>     out:
> -    if ( rc > 0 || opaque_out != 0 )
> +    if ( rc > 0 || (opaque_out != 0 && rc == 0) )

I don't understand this change. If you look at the implementation of 
gnttab_flush() it is not possible to have opaque_out non-zero with rc = 0.

So what's the point of the second condition?

>       {
>           /* Adjust rc, see gnttab_copy() for why this is needed. */
>           if ( cmd == GNTTABOP_copy )
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 13:47:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 13:47:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRFiO-0005uN-KR; Wed, 22 Apr 2020 13:47:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hTjb=6G=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jRFiN-0005uH-86
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 13:46:59 +0000
X-Inumbo-ID: bbf57686-849f-11ea-b4f4-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bbf57686-849f-11ea-b4f4-bc764e2007e4;
 Wed, 22 Apr 2020 13:46:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587563219;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=Atqgb43qTn9s9DbagQG9mt1kaowUF5UzkDPgDS2NtcI=;
 b=A8NpDsqMLrteOoHnFSoyNGW0OOwrXeNe8ofDWGCQoPVm4cDTpiRcmYlV
 fj+uOa/DWKO/iIEsjlW0fMnhBuPHpNgPcmrFmpkbsYIgcA1XbIAnLt+BD
 zD/wXIzJsJilXxLZOnmLHCLUz8oGpOwwn61SRpd79NYqB6q7ogpXbb5jh I=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: QxiQWHokpSaaCiqOctnrTtRyjd76nCKl3Nvk5RiRQV5du1ZuNpjikMFtRF9gPkAZwq72DGF7CI
 Q54+5/5UWHy/2cEG4uNCMdZTpHbeGARW2BTEUG65v3PnRF1Tt9R7sy6+6uP8hgjll1H1QDHV2U
 Wzd0hEktwYY0gaqd5eygbWmdfQz7Lubann4/3WcsGpky9bPuw7y4uQvVWHGJkCydSu5j3vXb4w
 J0E6lvIWod1W84B/age4dedE4jj5ddbAchUKIrXJjDk6Tm9w1IU7g8qJMqAZAY9I958BUe6HXV
 JIY=
X-SBRS: 2.7
X-MesageID: 16316202
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.72,414,1580792400"; d="scan'208";a="16316202"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24224.19143.658445.359032@mariner.uk.xensource.com>
Date: Wed, 22 Apr 2020 14:46:47 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] Introduce a description of the Backport and Fixes tags
In-Reply-To: <20200422131736.GD28601@Air-de-Roger>
References: <20200421182946.27337-1-sstabellini@kernel.org>
 <24223.16427.427446.817623@mariner.uk.xensource.com>
 <20200422131736.GD28601@Air-de-Roger>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "lars.kurth@citrix.com" <lars.kurth@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, "julien@xen.org" <julien@xen.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>,
 "jbeulich@suse.com" <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("Re: [PATCH] Introduce a description of the Backport and Fixes tags"):
> On Tue, Apr 21, 2020 at 07:49:15PM +0100, Ian Jackson wrote:
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> > > +When possible, please use the Fixes tag instead (or in addition).
> > 
> > Do we have any code to turn Fixes: into a list of commits to
> > backport to a particular stable branch ?
> 
> I think we should have one of those, I've attempted something like:

Cool :-).

> > If not it might be easier to ask people to add both Backport: and
> > Fixes:.
> 
> I would like to avoid that, a Fixes tag should be enough for us to
> figure out where the patch should be applied.

OK.  Let us start using these tags as defined in Stefano's patch and
we can debug the script when we have some test data :-).

> #!/bin/sh -e

I tried to avoid reading your script but I couldn't help glancing at
the first line and

  #!/bin/sh
  set -e

is better because then

  bash -x script

isn't a bomb.

> The script could also likely be cleaned up and improved, it's quite
> ugly...

We can put it in-tree and then people can send patches...

Ian.


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 13:50:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 13:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRFlH-00063t-2R; Wed, 22 Apr 2020 13:49:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9hqk=6G=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jRFlF-00063k-Jx
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 13:49:57 +0000
X-Inumbo-ID: 26763c84-84a0-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 26763c84-84a0-11ea-83d8-bc764e2007e4;
 Wed, 22 Apr 2020 13:49:56 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D295EAEE8;
 Wed, 22 Apr 2020 13:49:54 +0000 (UTC)
Subject: Re: [PATCH] xen/grants: fix hypercall continuation for
 GNTTABOP_cache_flush
To: Julien Grall <julien@xen.org>, xen-devel@lists.xenproject.org
References: <20200422130753.14713-1-jgross@suse.com>
 <6ae77443-2703-614a-adfc-65bfacf27185@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <c1e12fda-6740-d301-977e-265307158e50@suse.com>
Date: Wed, 22 Apr 2020 15:49:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <6ae77443-2703-614a-adfc-65bfacf27185@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 22.04.20 15:43, Julien Grall wrote:
> Hi Juergen,
> 
> On 22/04/2020 14:07, Juergen Gross wrote:
>> The GNTTABOP_cache_flush hypercall has a wrong test for hypercall
>> continuation, the test today is:
>>
>>      if ( rc > 0 || opaque_out != 0 )
>>
>> Unfortunately this will be true even in case of an error (rc < 0),
>> possibly leading to very long lasting hypercalls (times of more
>> than an hour have been observed in a test case).
>>
>> Correct the test condition to result in false with rc < 0 and set
>> opaque_out only if no error occurred, to be on the safe side.
>>
>> Partially-suggested-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   xen/common/grant_table.c | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>> index 96080b3dec..5ef7ff940d 100644
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -3626,12 +3626,12 @@ do_grant_table_op(
>>           if ( unlikely(!guest_handle_okay(cflush, count)) )
>>               goto out;
>>           rc = gnttab_cache_flush(cflush, &opaque_in, count);
>> -        if ( rc > 0 )
>> +        if ( rc >= 0 )
>>           {
>>               guest_handle_add_offset(cflush, rc);
>>               uop = guest_handle_cast(cflush, void);
>> +            opaque_out = opaque_in;
>>           }
>> -        opaque_out = opaque_in;
>>           break;
>>       }
>> @@ -3641,7 +3641,7 @@ do_grant_table_op(
>>       }
>>     out:
>> -    if ( rc > 0 || opaque_out != 0 )
>> +    if ( rc > 0 || (opaque_out != 0 && rc == 0) )
> 
> I don't understand this change. If you look at the implementation of 
> gnttab_flush() it is not possible to have opaque_out non-zero with rc = 0.

Why not?

In gnttab_cache_flush() we have:

   if ( hypercall_preempt_check() )
       return i;

i will be 0 in the first loop iteration.


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 13:50:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 13:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRFlR-0006hv-Ak; Wed, 22 Apr 2020 13:50:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=l+vI=6G=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRFlQ-0006fV-Ml
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 13:50:08 +0000
X-Inumbo-ID: 2ceda2e6-84a0-11ea-9287-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2ceda2e6-84a0-11ea-9287-12813bfff9fa;
 Wed, 22 Apr 2020 13:50:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=hOCpRi14MuW2iXfxBgDx5xM0YVwCVVg6dimgyyOfD2A=; b=tccILTkrrP0pLIsIirF1ZkXn7b
 4oGnvbRzIbjaTKpX1hfQ6Z4zfuySkqPrjAU59MIjknJ7NPo2bBNqtYWyTyNhoWkR9kZ0xP/05sT6m
 WEl1LWPHUTaszP6l6QELrCSNRhiuS+GGBZEYIfEvsxibrC9luFVYnCG0WUCjrYLkPKb8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRFlN-0007Il-6k; Wed, 22 Apr 2020 13:50:05 +0000
Received: from 54-240-197-228.amazon.com ([54.240.197.228]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRFlM-0008Bn-UJ; Wed, 22 Apr 2020 13:50:05 +0000
Subject: Re: [PATCH] xen/grants: fix hypercall continuation for
 GNTTABOP_cache_flush
From: Julien Grall <julien@xen.org>
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
References: <20200422130753.14713-1-jgross@suse.com>
 <6ae77443-2703-614a-adfc-65bfacf27185@xen.org>
Message-ID: <9f23844c-4ca0-8eb6-406f-a4c85274c42f@xen.org>
Date: Wed, 22 Apr 2020 14:50:02 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <6ae77443-2703-614a-adfc-65bfacf27185@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 22/04/2020 14:43, Julien Grall wrote:
> Hi Juergen,
> 
> On 22/04/2020 14:07, Juergen Gross wrote:
>> The GNTTABOP_cache_flush hypercall has a wrong test for hypercall
>> continuation, the test today is:
>>
>>      if ( rc > 0 || opaque_out != 0 )
>>
>> Unfortunately this will be true even in case of an error (rc < 0),
>> possibly leading to very long lasting hypercalls (times of more
>> than an hour have been observed in a test case).
>>
>> Correct the test condition to result in false with rc < 0 and set
>> opaque_out only if no error occurred, to be on the safe side.
>>
>> Partially-suggested-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   xen/common/grant_table.c | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>> index 96080b3dec..5ef7ff940d 100644
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -3626,12 +3626,12 @@ do_grant_table_op(
>>           if ( unlikely(!guest_handle_okay(cflush, count)) )
>>               goto out;
>>           rc = gnttab_cache_flush(cflush, &opaque_in, count);
>> -        if ( rc > 0 )
>> +        if ( rc >= 0 )
>>           {
>>               guest_handle_add_offset(cflush, rc);
>>               uop = guest_handle_cast(cflush, void);
>> +            opaque_out = opaque_in;
>>           }
>> -        opaque_out = opaque_in;
>>           break;
>>       }
>> @@ -3641,7 +3641,7 @@ do_grant_table_op(
>>       }
>>     out:
>> -    if ( rc > 0 || opaque_out != 0 )
>> +    if ( rc > 0 || (opaque_out != 0 && rc == 0) )
> 
> I don't understand this change. If you look at the implementation of 
> gnttab_flush() it is not possible to have opaque_out non-zero with rc = 0.

Hmmm... I misread the code and missed the:

if ( hypercall_preempt_check() )
   return i;

Sorry for the noise.

I am also assuming this want a Fixes tag on 
18e8d22fe750c8c7b2830fa37961352693425cf1 "introduce GNTTABOP_cache_flush".

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 14:01:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 14:01:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRFw1-0007sH-GJ; Wed, 22 Apr 2020 14:01:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9j4T=6G=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRFvz-0007sC-Ud
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 14:01:03 +0000
X-Inumbo-ID: b3663de7-84a1-11ea-9289-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b3663de7-84a1-11ea-9289-12813bfff9fa;
 Wed, 22 Apr 2020 14:01:02 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DF032ABCF;
 Wed, 22 Apr 2020 14:01:00 +0000 (UTC)
Subject: Re: [PATCH] xen/grants: fix hypercall continuation for
 GNTTABOP_cache_flush
To: Juergen Gross <jgross@suse.com>
References: <20200422130753.14713-1-jgross@suse.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6b050b8e-72d2-2d4f-3e23-101596d31d40@suse.com>
Date: Wed, 22 Apr 2020 16:00:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200422130753.14713-1-jgross@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 22.04.2020 15:07, Juergen Gross wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3626,12 +3626,12 @@ do_grant_table_op(
>          if ( unlikely(!guest_handle_okay(cflush, count)) )
>              goto out;
>          rc = gnttab_cache_flush(cflush, &opaque_in, count);
> -        if ( rc > 0 )
> +        if ( rc >= 0 )
>          {
>              guest_handle_add_offset(cflush, rc);
>              uop = guest_handle_cast(cflush, void);
> +            opaque_out = opaque_in;
>          }
> -        opaque_out = opaque_in;
>          break;
>      }
>  
> @@ -3641,7 +3641,7 @@ do_grant_table_op(
>      }
>  
>    out:
> -    if ( rc > 0 || opaque_out != 0 )
> +    if ( rc > 0 || (opaque_out != 0 && rc == 0) )

I disagree with this part - opaque_out shouldn't end up non-zero
when rc < 0, and it won't anymore with the change in the earlier
hunk.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 15:50:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 15:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRHdW-0000vE-UI; Wed, 22 Apr 2020 15:50:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1SgQ=6G=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRHdV-0000gt-87
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 15:50:05 +0000
X-Inumbo-ID: ee2ea666-84b0-11ea-b58d-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ee2ea666-84b0-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 15:50:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587570604;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=rlpauxDm9qoGYqy2SW+9vPdrfTG1GPO/Be0nzwvZITc=;
 b=PdDh9Gm57qzMj9BfbR0O0UyP0xJ46G8+duEcNfBhBjHFOQpJh/bcrlkp
 pJR2bsPpQ8Y/aivOJFgIh62tJ3qWEW0sPocG0G4f1QTGxMNnbWtrfIy8p
 lyVbJgOFtUQA5Zi3l0KCjGsFoO7w/fPLG+HHf9tgx7H420aP/klMAf6ls o=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: G16WzRWnYbXJERv/lI+rCbf12v3M7TUdB9z1D83A8vwm9JXCLM+XkeSQkJN7W/c3GfxJxPRiNU
 6Kkg2mQe1skCKaY4B6JokvVpctghmrSW6B9BLXw+b7riNww8L6k71qFC697hJ4Q8pheOdkdtK6
 ZTCylv30GGhr+9ZbzSE24kKaFYVxAVa3Vwy9J96OpmYzMTizlR4gPhWKh3h8TH0XSHnwGcsK3t
 3C+4c+owuEQdAPfXpVfuzO9JMS03XIrC2o00syahbYCE5VrvoGz+TWHqcpvnd1wq3DzgYvYZhw
 pSU=
X-SBRS: 2.7
X-MesageID: 16062577
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,303,1583211600"; d="scan'208";a="16062577"
Date: Wed, 22 Apr 2020 17:49:56 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Subject: Re: [PATCH v16 1/3] mem_sharing: fix sharability check during fork
 reset
Message-ID: <20200422154956.GE28601@Air-de-Roger>
References: <cover.1587490511.git.tamas.lengyel@intel.com>
 <8eb756357cb6d9222ed7ec4c0af58473160361a1.1587490511.git.tamas.lengyel@intel.com>
 <20200422085953.GB28601@Air-de-Roger>
 <CABfawhmBW4kiv_mCUrH_JTdCDZWdbb7Qf65_i350apx-q7NXbg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABfawhmBW4kiv_mCUrH_JTdCDZWdbb7Qf65_i350apx-q7NXbg@mail.gmail.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 22, 2020 at 06:42:42AM -0600, Tamas K Lengyel wrote:
> On Wed, Apr 22, 2020 at 3:00 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
> >
> > On Tue, Apr 21, 2020 at 10:47:23AM -0700, Tamas K Lengyel wrote:
> > > @@ -666,20 +670,31 @@ static int page_make_sharable(struct domain *d,
> > >       */
> > >      if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
> > >      {
> > > -        spin_unlock(&d->page_alloc_lock);
> > >          /* Return type count back to zero */
> > >          put_page_and_type(page);
> > > -        return -E2BIG;
> > > +        rc = -E2BIG;
> > > +        goto out;
> > > +    }
> > > +
> > > +    rc = 0;
> > > +
> > > +    if ( validate_only )
> > > +    {
> > > +        put_page_and_type(page);
> >
> > You seem to check some page attributes but then put the page again,
> > which looks racy to me. Since you put the page, couldn't the checks
> > that you have performed be stale by the point the data is consumed by
> > the caller?
> 
> During fork reset when this is called with validate_only = true the
> domain is paused. Furthermore, fork reset is only for forks that have
> no device model running, so nothing is interacting with its memory
> that could acquire extra references. So no, this isn't racy since
> there is nothing to race against that I'm aware of. Also, this check
> is really to check for special pages, all of which are setup during
> the initial fork process, not during runtime of the fork.

Right, it would feel safer to me however if you just return from
page_make_sharable while having a page reference, and drop it in
mem_sharing_fork_reset if the page shouldn't be removed from the fork.

This way you could also avoid having to take an extra reference just
after returning from nominate_page in mem_sharing_fork_reset.
page_make_sharable already returns while having taken an extra
reference to the page in the non validate only case anyway.

> >
> > > +        goto out;
> > >      }
> > >
> > >      page_set_owner(page, dom_cow);
> > >      drop_dom_ref = !domain_adjust_tot_pages(d, -1);
> > >      page_list_del(page, &d->page_list);
> > > -    spin_unlock(&d->page_alloc_lock);
> > >
> > > +out:
> > > +    if ( !validate_only )
> > > +        spin_unlock(&d->page_alloc_lock);
> > >      if ( drop_dom_ref )
> > >          put_domain(d);
> > > -    return 0;
> > > +
> > > +    return rc;
> > >  }
> > >
> > >  static int page_make_private(struct domain *d, struct page_info *page)
> > > @@ -809,8 +824,8 @@ static int debug_gref(struct domain *d, grant_ref_t ref)
> > >      return debug_gfn(d, gfn);
> > >  }
> > >
> > > -static int nominate_page(struct domain *d, gfn_t gfn,
> > > -                         int expected_refcnt, shr_handle_t *phandle)
> > > +static int nominate_page(struct domain *d, gfn_t gfn, int expected_refcnt,
> >
> > Is there any reason for expected_refcnt to be signed? All callers use
> > unsigned values.
> 
> No reason. It's just how the code was written by the original author
> and we never changed it.

Since you are already changing those lines, can I ask you to also
change it to unsigned in the places that you touch?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 15:50:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 15:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRHdo-000135-74; Wed, 22 Apr 2020 15:50:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FcMM=6G=gmail.com=jaromir.dolecek@srs-us1.protection.inumbo.net>)
 id 1jRHdn-00012s-5U
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 15:50:23 +0000
X-Inumbo-ID: f9a13860-84b0-11ea-83d8-bc764e2007e4
Received: from mail-ua1-x942.google.com (unknown [2607:f8b0:4864:20::942])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f9a13860-84b0-11ea-83d8-bc764e2007e4;
 Wed, 22 Apr 2020 15:50:22 +0000 (UTC)
Received: by mail-ua1-x942.google.com with SMTP id t8so2148248uap.3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 08:50:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=QFk2ifqjLHyPsKZvVEBsxNJMQtRHXXI1/TtMaXlRdEk=;
 b=igUk2GatzQjNtX9WrSaxy6Efi0j7gTyUAaV0zPpDpXfSjtWmk1lmfsgbNd6/L5AhFl
 JGjtTXGluFc9Jb8vR6jWT0Mo4LX0CL0MSv1WB/IS7CANi74GGNqLBD4zytVC/ybmXIiK
 9a8sJGSOU/1Q8cOipysM3OJIVMGrthMymKsCkRb7VxjQ/4pmwgfhB03OKH3gb0t+vOEe
 67JGtfthTqR3djkYAXWleXJ9JX51LLGIfztsVhAc2LU+tJomll3R6Bopi7MVfhh7biGr
 0yGF5ZjTkhKIT7/vC+sA9Gtg1ulfO3lF4PHEzR9hzDq7mYwyxgt9nasFRf/clI6FmnbY
 zQ7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=QFk2ifqjLHyPsKZvVEBsxNJMQtRHXXI1/TtMaXlRdEk=;
 b=CCBEfkAhih/yeUaJ4wJnpkdt7nnujoG0CYWnwMNChy76vVJ5Y8MmXStGhSPdToYlww
 VpOkzf1t+FPnZLJCoeUPlGuqWejbiObpsfLLRJ2FxcI+kx5I+lUazDT53RnWi5ylk3bg
 XXBRJE73lC3p1BOCWyu5K1BwKcpYsc2AYFAt6cebtsznVicBpan8jxx2vilrclmY07kZ
 w1EcRdIi55dIdmr3s1xAbiEmXrUWS4lpcf4tnTyFe6rrrDkT+La9FVC6YIF0XRJ6fhOu
 ecUWGRBVWH2OBVtmdioCSeXKwmB64kUoGLMk36Sa5o0W6uX9rKZZk3L9HNjHMP42SvJ6
 f/nQ==
X-Gm-Message-State: AGi0PuYKvDThmdPj6B6uFsnWawht3AzWqAA/O353Ql3pzB6etPxWWs2g
 Wm/wljqkBtdBt/qtZZHRQXXytkfq3UJtArk8Jg0=
X-Google-Smtp-Source: APiQypIDHngdHx4llhSmDfU0ASqIe6gGP3hn4zaxN8GHQOaexMpuvavfn30wc+pGUDjiNBVz4EF0siZeQ9Yw8LmWW50=
X-Received: by 2002:a67:3343:: with SMTP id z64mr20120128vsz.108.1587570622254; 
 Wed, 22 Apr 2020 08:50:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAMnsW57Kn05TyDiVmZLaiYBdVZwy_7LazvLvR_AG0KHEYJ-z0Q@mail.gmail.com>
 <a8245dcc-cb91-f3d2-f0a2-135efd137370@citrix.com>
In-Reply-To: <a8245dcc-cb91-f3d2-f0a2-135efd137370@citrix.com>
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
Date: Wed, 22 Apr 2020 17:50:11 +0200
Message-ID: <CAMnsW57SVfdLQSZaLWwdgYikQZuaSUSX2-YJZtv31bDJpemETA@mail.gmail.com>
Subject: Re: grant_table_op v2 support for HVM?
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Le lun. 20 avr. 2020 =C3=A0 22:56, Andrew Cooper
<andrew.cooper3@citrix.com> a =C3=A9crit :
> Really?  The status handling is certainly different, but v2 is much
> harder to use correctly.

In which sense?

>From granter standpoint it seems to be just checking the status on
different place. Of course you can't atomically check the flags and
status any more, but with cooperating grantees that shouldn't be
problem - once grantee indicates it's done with the grant and unmaps
the pages, it doesn't map it again. Even e.g. Linux xbdback with
feature-persistent just keeps it mapped until it decides to g/c it.

Actually connected to this - am I correct to assume that for small
requests (say under 1500 bytes), it's faster to do just a memory copy
using the grant than it is to map+unmap the granted page into grantee
memory space, due to cost of TLB flushes on the grantee side?

> You want add_to_physmap(), requesting XENMAPSPACE_grant_table and or-ing
> XENMAPIDX_grant_table_status into the index.  (Because a new
> XENMAPSPACE_grant_status apparently wasn't the most logical way to
> extend the existing interface.)

This works indeed, so NetBSD can use v2 for both PV and HVM, thank you!

Interestingly, Linux kernel doesn't seem to use
XENMAPIDX_grant_table_status anywhere, I found only the standard setup
using the get_status_frames hypercall. How is HVM case handled in
Linux, is it just using v1?

I have another unrelated question, for MSI/MSI-X support in Dom0.

Is it necessary to do anything special to use properly the pirq/gsi
returned by physdev_op PHYSDEVOP_map_pirq?
After the map call for MSI interrupts (which succeeds), I execute only
the regular PHYSDEVOP_alloc_irq_vector for it, but interrupts don't
seem to be delivered right now under Dom0 (works native).

Of course this is likely to be a bugs in my code somewhere, I'd just
like to rule out that nothing else is necessary on Xen side.

Jaromir


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 16:04:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 16:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRHrf-0002pk-HV; Wed, 22 Apr 2020 16:04:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=nI87=6G=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRHre-0002pf-Fd
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 16:04:42 +0000
X-Inumbo-ID: f914b7e4-84b2-11ea-92a6-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f914b7e4-84b2-11ea-92a6-12813bfff9fa;
 Wed, 22 Apr 2020 16:04:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587571481;
 h=from:to:cc:subject:date:message-id:content-id:
 content-transfer-encoding:mime-version;
 bh=uo6cG7FvJcmGQBp58Ixw9BOK89YlsvpEaT1zEvp+qE8=;
 b=CDNT5tKFAvF10g4N7NZhdDjeEmWdjLOmNMAllGe3KFcHxyGIw+FbRVQg
 5zO8IuPFYZimQzXj+mNdSxXxzGUiymB2UCk3LFBfU7GYH02GvHI5G485W
 KB02RbPYw/VP75kVQjjLKErV7/lY9c2tObhOflh76BiGGYcA+XyKP6va/ U=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: UNylRPrAYfP3GfQSrhbLHR7RfLs8sVNQca8ZWW74vZSHRaQunXFZ9KQD06h2FWe2feNXNl9Qn3
 bNenCEKN216GJzlswJowevaxbHQlqCNYiQAUUkOQeX/C+okB149M7tYbIbmBvOjTuPvTXyhCrS
 iZ5pmG3pH3LfeaPQrIu4cXWBI5UVtjBjFWzWk4t2Akda6Kl49YDqQuY5mTWRaj+jzDJ1LraKn2
 JOvof84gqSQLwRrwHOK7vMqn0nUd0EwCvB9e1psBcx7Jq5uSNKwhf+EJDu3RuNc0faAi5WJ2v/
 d70=
X-SBRS: 2.7
X-MesageID: 16393313
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,303,1583211600"; d="scan'208,217";a="16393313"
From: George Dunlap <George.Dunlap@citrix.com>
To: xen-devel <xen-devel@lists.xenproject.org>
Subject: Golang Xen packages and the golang packaging  system
Thread-Topic: Golang Xen packages and the golang packaging  system
Thread-Index: AQHWGL+4RaHBeS8dkEGvpDIRZjts4w==
Date: Wed, 22 Apr 2020 16:04:37 +0000
Message-ID: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <E64C3C6AA610FD48AC63071689994CE9@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Nick Rosbrook <rosbrookn@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

U28gY3VycmVudGx5LCBvdXIgYnVpbGQgc3lzdGVtIHdpbGwgaW5zdGFsbCB0aGUgeGVubGlnaHQg
cGFja2FnZSBpbnRvICRQUkVGSVgvc2hhcmUvZ29jb2RlL3NyYy9nb2xhbmcueGVucHJvamVjdC5v
cmcveGVubGlnaHQuICBIb3dldmVyLCBpdCBhY3R1YWxseSB0YWtlcyBhIGJpdCBvZiB3cmVzdGxp
bmcgdG8gZ2V0IGdvbGFuZyB0byB1c2UgdGhpcyBsb2NhdGlvbiwgYW5kIG1ha2VzIGl0IGRpZmZp
Y3VsdCB0byB1c2Ugc2hhcmVkIGNvZGUuICBJdCB3b3VsZCBiZSBuaWNlIGlmIHBlb3BsZSBjb3Vs
ZCBzaW1wbHkgYWRkIGBnb2xhbmcueGVucHJvamVjdC5vcmcveGVubGlnaHRgIHRvIHRoZWlyIGRl
cGVuZGVuY2llcywgYW5kIGhhdmUgYGdvIGdldGAganVzdCBEVFJULg0KDQpUaGlzIGJhc2ljYWxs
eSBpbnZvbHZlcyB0d28gdGhpbmdzOg0KDQoxLiBDcmVhdGluZyBhIHB1YmxpY2x5LWFjY2Vzc2li
bGUgc3VpdGFibGUgZ2l0IHJlcG8gY29udGFpbmluZyB0aGUgZ29sYW5nIHBhY2thZ2UocykNCg0K
Mi4gQ2F1c2luZyBgY3VybCBnb2xhbmcueGVucHJvamVjdC5vcmcvJFBLR05BTUVgIHRvIHJldHVy
biBzb21lIEhUTUwgd2l0aCB0aGUgZm9sbG93aW5nIHJ1bmU6DQoNCjxtZXRhIG5hbWU9ImdvLWlt
cG9ydCIgY29udGVudD3igJxnb2xhbmcueGVucHJvamVjdC5vcmcgZ2l0ICRVUkzigJ0+DQoNCldo
ZXJlICRVUkwgcG9pbnRzIHRvIHRoZSB0cmVlIGZyb20gIzEuDQoNCldlIHNob3VsZCBwcm9iYWJs
eSBhbHNvIGhhdmUgc29tZSBtb3JlIGh1bWFuLWZyaWVuZGx5IGNvbnRlbnQgaW4gY2FzZSBzb21l
b25lIHdhbmRlcnMgdGhlcmUgd2l0aCBhIHdlYiBicm93c2VyLg0KDQrigJxTdWl0YWJsZSBnaXQg
dHJlZeKAnSBtZWFuczoNCi0gVGhhdCBpdCBjb250YWlucyBqdXN0IHRoZSBiaW5kaW5ncy4gIA0K
LSBBbnkg4oCYcmVsZWFzZWTigJkgWGVuIHZlcnNpb24gaGFzIGEgdGFnIG9mIHRoZSB2QS5CLkMg
Zm9ybWF0DQoNCkkgdGhpbmsgaWRlYWxseSB3ZeKAmWQgbGlrZSB0aGUg4oCYbWFzdGVy4oCZIGJy
YW5jaCBvZiB0aGlzIGdpdCB0cmVlIHRvIGNvbnRhaW4gdGhlIGJpbmRpbmdzIGZyb20gdGhlIHhl
bmJpdHMueGVucHJvamVjdC5vcmcveGVuLmdpdCBtYXN0ZXIgYnJhbmNoLCBidXQgdGhhdOKAmXMg
c29tZXdoYXQgbmVnb3RpYWJsZS4NCg0KU28gd2hhdCB3ZeKAmWQgbmVlZCB0byBkbyBpcyBoYXZl
IGEgcHJvY2VzcyAvIGhvb2sgc29tZXdoZXJlIHdoaWNoIHdvdWxkLCBvbiBwdXNoIHRvIHhlbmJp
dHMueGVucHJvamVjdC5vcmcveGVuLmdpdCDigJlzIG1hc3RlciBicmFuY2g6DQogLSBHZW5lcmF0
ZSB0aGUgYmluZGluZ3MgZnJvbSB0aGUgc291cmNlIGNvZGUNCiAtIENvcHkgdGhlc2UgYmluZGlu
Z3MgaW50byB0aGUgZ2l0IHJlcG8sIHJlcGxhY2luZyB0aGUgb2xkIGJpbmRpbmdzIGVudGlyZWx5
IChpLmUuLCBkZWxldGluZyBmaWxlcyB3aGljaCBkb27igJl0IGV4aXN0IGFueSBtb3JlLCBhZGRp
bmcgbmV3IGZpbGVzKQ0KIC0gUnVubmluZyDigJhnaXQgY29tbWl04oCZLCBwcm9iYWJseSB3aXRo
IGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21taXQgZnJvbSB3aGljaCB0aGlzIGNvZGUgaGFzIGJl
ZW4gZ2VuZXJhdGVkDQogLSBDaGVjayB0byBzZWUgaWYgdGhlcmUgaXMgYSBuZXcgUkVMRUFTRS1Y
LlkuWiB0YWcgYW5kIGdlbmVyYXRlIGFuIGFwcHJvcHJpYXRlIHRhZw0KIC0gUHVzaCB0byB0aGUg
Z2l0IHJlcG8gaW4gc3RlcCAjMSBhYm92ZQ0KDQpUaGlzIHNjcmlwdCBzaG91bGQgbGl2ZSBpbiB4
ZW4uZ2l0IEkgZ3Vlc3MuDQoNCkkgZ3Vlc3MgbWF5YmUgaXQgd291bGQgbWFrZSBzZW5zZSB0byBo
YXZlIG9uZSBnaXQgdHJlZSBwZXIgcGFja2FnZSwgYW5kIHB1dCB0aGVtIGF0IHhlbmJpdHMueGVu
cHJvamVjdC5vcmcvZ29sYW5nLyRQS0dOQU1FPyAoZS5nLiwgeGVuYml0cy54ZW5wcm9qZWN0Lm9y
Zy9nb2xhbmcveGVubGlnaHQuZ2l0PykgIEF0IGFueSByYXRlLCBzb21ldGhpbmcgdGhhdCB3b3Vs
ZCBhbGxvdyB1cyB0byBsZXZlcmFnZSBvdXIgY3VycmVudCBnaXRodHRwIGluc3RhbmNlIG9uIHhl
bmJpdHMuDQoNCk9uZSBxdWVzdGlvbiBJIGhhdmUgZnJvbSB0aGUgYWJvdmUgaXMgaG93IHRoZSB4
ZW4uZ2l0IFJFTEVBU0UtWC5ZLlogc2hvdWxkIGNvcnJlc3BvbmQgdG8gdGhlIHZBLkIuQyBpbiB0
aGUgZ29sYW5nIHBhY2thZ2UgcmVwby4NCg0KVGhlIG9idmlvdXMgYW5zd2VyLCBvZiBjb3Vyc2Us
IGlzIChBLCBCLCBDKSA9IChYLCBZLCBaKTsgdGhhdCBpcywgeGVuLmdpdCB0YWcgUkVMRUFTRS00
LjE0LjAgc2hvdWxkIGNyZWF0ZSBhIGdvbGFuZyBwYWNrYWdlIHRhZyBvZiB2NC4xNC4wLg0KDQpU
aGUgaXNzdWUgd2l0aCB0aGlzIGlzIHRoYXQgZ29sYW5nIGFzc3VtZXMgeW914oCZcmUgdXNpbmcg
c2VtYW50aWMgdmVyc2lvbmluZzsgc28gYSBgZ28gZ2V0IC11YCB3b3VsZCBub3JtYWxseSBmZWVs
IGp1c3RpZmllZCBpbiB1cGdyYWRpbmcgZnJvbSB2NC4xNC54IHRvIHY0LjE1LnguDQoNCkEgY291
cGxlIG9mIHBvc3NpYmxlIHJlc3BvbnNlczoNCg0KMS4gRGVjbGFyZSB0aGF0IE9LLiAgVGhhdCB3
b3VsZCBtZWFuIG5vdCBvbmx5IHRoYXQgd2UgaGF2ZSB0byBoYXZlIHY0LjE1LnggYmUgY29tcGF0
aWJsZSB3aXRoIGdvbGFuZyBzb3VyY2UgY29kZSB3cml0dGVuIGFnYWluc3QgdjQuMTQ7IGl0IHdv
dWxkIGFsc28gbWVhbiB0aGF0IHY0LjE1LnggbmVlZHMgdG8gYmUgYWJsZSB0byAqY29tcGlsZSog
YWdhaW5zdCBsaWJ4bCB2ZXJzaW9uIDQuMTQuICBXaGljaCBtaWdodCBiZSBhIGdvb2QgaWRlYSwg
YnV0IHdl4oCZZCB3YW50IHRvIHRoaW5rIGNhcmVmdWxseSBiZWZvcmUgbWFraW5nIHRoYXQga2lu
ZCBvZiBjb21taXRtZW50Lg0KDQoyLiBEZWNsYXJlIHRoYXQgcGVvcGxlIG5lZWQgdG8gdXNlIGBn
byBnZXQgLXU9cGF0Y2hgIHdoZW4gdXBkYXRpbmcsIGFuZC9vciB1c2UgZ28ubW9kICZjIHRvIG1h
bnVhbGx5IHJlc3RyaWN0IHRoZSB2ZXJzaW9uIG9mIGdvIHRvIHVzZSB0byB0aGUgY3VycmVudGx5
LWluc3RhbGxlZCBYZW4gdmVyc2lvbg0KDQozLiBNYXAgKEEsIEIsIEMpID0gKFksIFosIDApLiAg
KGkuZS4sIFJFTEVBU0UtNC4xNC41IHdvdWxkIG1ha2UgdGFnIHYxNC41LjAgLikgIGBnbyBnZXRg
IHdvdWxkbuKAmXQgdXBkYXRlIGF1dG9tYXRpY2FsbHksIGJ1dCBpdCBtaWdodCBiZSBjb25mdXNp
bmcgd2hpY2ggdmVyc2lvbiAqc2hvdWxkKiBiZSB1c2VkOyBwYXJ0aWN1bGFybHkgaWYgd2UgZXZl
ciByb2xsIG92ZXIgYSBtYWpvciB2ZXJzaW9uIGZvciBYZW4uDQoNCkFueSBvdGhlciBwb3NzaWJp
bGl0aWVzPw0KDQpJIHRoaW5rIEnigJlkIHN0YXJ0IG91dCB3aXRoICMyLCBhbmQgdGhlbiBjb25z
aWRlciBtb3ZpbmcgdG8gIzEgYXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlLg0KDQpUaG91Z2h0
cz8NCg0KIC1HZW9yZ2UNCg0K


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 16:10:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 16:10:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRHxa-0003eF-7g; Wed, 22 Apr 2020 16:10:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRHxZ-0003eA-D1
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 16:10:49 +0000
X-Inumbo-ID: d4240092-84b3-11ea-92a9-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d4240092-84b3-11ea-92a9-12813bfff9fa;
 Wed, 22 Apr 2020 16:10:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=K84IagFoT7i1DbDCJbuMixDCd/6yRY00KkBg9fgc5uE=; b=pJjBwC0TnrOg+owuwd7jal4IK
 ba3RuNv2dr0GOtnXu6NLukN9FAmz4HZu4zSpGfT/45rc2q4Wa9x9VduaFi+ExE45Fv824YjATEVTN
 mkg3NPHjVqsOQiw0SaWAOIx039uxIMt2vXPEeWkqoUyjAJXvmuZbyb9jubPDktcV3uY/k=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRHxY-0002cU-0M; Wed, 22 Apr 2020 16:10:48 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRHxX-0007zq-Id; Wed, 22 Apr 2020 16:10:47 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRHxX-0005Tk-Hy; Wed, 22 Apr 2020 16:10:47 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149736-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149736: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
X-Osstest-Versions-That: xen=17b094b97c823c956c57e31c5cd7175d56b3efe4
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 16:10:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149736 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149736/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
baseline version:
 xen                  17b094b97c823c956c57e31c5cd7175d56b3efe4

Last test of basis   149733  2020-04-22 09:02:41 Z    0 days
Testing same since   149736  2020-04-22 13:01:28 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   17b094b97c..a62c6fe05c  a62c6fe05c4ae905b7d4cb0ca946508b7f96d522 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 16:32:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 16:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRII9-0005tN-Al; Wed, 22 Apr 2020 16:32:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MSan=6G=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jRII7-0005tI-Fh
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 16:32:03 +0000
X-Inumbo-ID: cbac7c3e-84b6-11ea-92b0-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cbac7c3e-84b6-11ea-92b0-12813bfff9fa;
 Wed, 22 Apr 2020 16:32:02 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id B95DF20767;
 Wed, 22 Apr 2020 16:32:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587573122;
 bh=IBNfVtGrbV89GNQJg6jOWn+LKlgGLO1lj2u1kryxwiw=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=Prhch0N39vs3d9lnGpw5r2fiDCP/3wnFO+5pZQqKTPVKSIVsdNEkO3NN6KphwOkKb
 DK3h7gneD6xbIf4OubusnlsEke5AOmSoUW8aCm2LZh8n+Kp9s8py/azPzlPpl6EEcW
 7Wmsh4cyJ3/DOfqSab0ySv9jIL1XP0caxr7ljMrQ=
Date: Wed, 22 Apr 2020 09:31:54 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] xen/grants: fix hypercall continuation for
 GNTTABOP_cache_flush
In-Reply-To: <6b050b8e-72d2-2d4f-3e23-101596d31d40@suse.com>
Message-ID: <alpine.DEB.2.21.2004220911040.25377@sstabellini-ThinkPad-T480s>
References: <20200422130753.14713-1-jgross@suse.com>
 <6b050b8e-72d2-2d4f-3e23-101596d31d40@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 22 Apr 2020, Jan Beulich wrote:
> On 22.04.2020 15:07, Juergen Gross wrote:
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -3626,12 +3626,12 @@ do_grant_table_op(
> >          if ( unlikely(!guest_handle_okay(cflush, count)) )
> >              goto out;
> >          rc = gnttab_cache_flush(cflush, &opaque_in, count);
> > -        if ( rc > 0 )
> > +        if ( rc >= 0 )
> >          {
> >              guest_handle_add_offset(cflush, rc);
> >              uop = guest_handle_cast(cflush, void);
> > +            opaque_out = opaque_in;
> >          }
> > -        opaque_out = opaque_in;
> >          break;
> >      }
> >  
> > @@ -3641,7 +3641,7 @@ do_grant_table_op(
> >      }
> >  
> >    out:
> > -    if ( rc > 0 || opaque_out != 0 )
> > +    if ( rc > 0 || (opaque_out != 0 && rc == 0) )
> 
> I disagree with this part - opaque_out shouldn't end up non-zero
> when rc < 0, and it won't anymore with the change in the earlier
> hunk.

But opaque_out could end up being non-zero when rc == 0. I think it is a
good improvement that we explicitly prevent rc < 0 from entering this
if condition. This is why this new version of the patch is my favorite:
it is the one that leads to the code most robust. 

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


That said, as I mentioned before, I would be OK even without the last
part because it would still be enough to fix the bug.


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 16:33:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 16:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRIJn-0005zy-MT; Wed, 22 Apr 2020 16:33:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1SgQ=6G=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRIJn-0005zt-2D
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 16:33:47 +0000
X-Inumbo-ID: 09547280-84b7-11ea-b58d-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 09547280-84b7-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 16:33:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587573226;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=G3mkT4oFR4kXoNWmMSQAwM0sbSjW+8RCU+61QXmBpTQ=;
 b=SdG5KLDOr3bFLKQFIN/TZK6ONvjU/LkB3y1a0j0tgPMmRDFtQQALoxVQ
 veZG9lT/Je6Av6PHRR0KkVCFUmcFUiCE9JAJkrU5RWF7g8mxDtmnrr7np
 w/mwJxGWsjQgoyzM8Aqoa0Jhya/9z0rwTtAGc8PpWpTAcn+YqpHaGr1Qw k=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: yErkoYtC1pkuSH/KMiklMSFy8elHhAlwjvW9jzltzN4Plt0GRGKPZp7Agkj0WE7l0jpKv08KMX
 cQT/Dk1CJy0aASgtNlgyeHIEc5Y41Eu3Sq7fnBHDm8vqTXl66CY80HmVsqjqxahhG10zlSeH8R
 X0nrml/R/OWjPe3B0gtkSiEjWOnZvEkB5gEtqh2QZ+19HxsaxLJNYr/2tYI3kLGw0PDiOuLGzG
 i07DzjQ+SISFZmqIb7zWB+NPx/JEGTHDeKKcwkiLu28B0m+QR9MHfAZJfoeFpC4r0zMKxgXjID
 beA=
X-SBRS: 2.7
X-MesageID: 16395186
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,304,1583211600"; d="scan'208";a="16395186"
Date: Wed, 22 Apr 2020 18:33:38 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200422163338.GF28601@Air-de-Roger>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20200416135909.16155-2-roger.pau@citrix.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 George Dunlap <george.dunlap@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
>  
>      return flags;
>  }
> +
> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
> +{
> +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
> +                                                                   : 0) |
> +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> +                                                          : 0);

Maybe I'm getting confused, but I think the above is wrong and ASID
should _always_ be flushed when running a HVM domain in shadow mode
regardless of whether the underlying hw is Intel or AMD, ie:

bool shadow = paging_mode_shadow(d);
unsigned int flags = (shadow ? FLUSH_TLB : 0) |
                     (is_hvm_domain(d) &&
                      (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE : 0);

Is the correct version.

Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 16:34:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 16:34:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRIKR-00064E-W3; Wed, 22 Apr 2020 16:34:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mXoo=6G=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jRIKQ-000645-Cb
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 16:34:26 +0000
X-Inumbo-ID: 20c5d18e-84b7-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 20c5d18e-84b7-11ea-b4f4-bc764e2007e4;
 Wed, 22 Apr 2020 16:34:25 +0000 (UTC)
Received: by mail-ed1-x541.google.com with SMTP id f12so1961743edn.12
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 09:34:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=gwL52jhgsPisokJqqP2AaJci4wTaX2YHQDDtdSUNJHY=;
 b=aYwVQ53Ca3QNtnUqsJokxb0Vmp20nBKVeS0wo4H0ifBGhDZlnaU82gkpQpZegJowr2
 sVWyDw0ApJFgVhc/YqvU6HcFbhziKsKVEGjCl0nN4rWjBq0FUsNC+BrwtvXVVObmcyvM
 gsKenSylaSb2NT67jZHY23u+tQvVE1r4auAjdQK0//4te6qZc7qzb90jq149TSKw6kJt
 t4fVtkMFNanbKu8DKmp1lCCwDo2yylRF2Gk6X/68Xj0NQLAWFDBVr0075qfuTHI8rBR/
 Bbto67cjDOoGF9JeiBxhgnp7OBhEqZfQJUpMqJ3MpmWrwAzgwXy/9l6zBNDUNJ/z6oKB
 OmmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=gwL52jhgsPisokJqqP2AaJci4wTaX2YHQDDtdSUNJHY=;
 b=UwLCBnSG4dXRBS1lk2ycIiqhzWbsAXr3XSAnSukhO+WQd8r6GYZlNZPrWLPSbI4wOf
 gyAkaB2kP+0R0701LGxdLYJryM99WuURWk5DaN9OdzZmZfxdkX5ZxxUgDBLx+tJWl4yq
 I7qo3+pqOR+i9Kefgv0PJZ0YEJ1UUx4gkzVuaZ/VOjX2HSXD7tgHvRq4dhVhexbO1mZT
 D6ZEXfJXQclKDAo21byAHAoafA+zzdQICCtvJCGTZoXtpc4cui7NcHMKkhteUJj9hrcJ
 m68VEf9jg3MFh9QQvBuQeovie9q3cn/ZKjLx56VW1crvQGu5q4aEjqma+Ai6g7DZoPBq
 iDJg==
X-Gm-Message-State: AGi0PuYX1pru2QSdeXnkJ6erKp3vXacTNt+zNmFw/zkw8SQBZdZhq2eW
 EZCaHttHv/Wdqb+4UmvbTcgUeBAZVNs=
X-Google-Smtp-Source: APiQypKjovmCYBTvIi1rjLD22D0kuAPnQOWa1v+VxWzwOMiWeRZeFnx4a3RA9nKmLbDGydYUT3xgPA==
X-Received: by 2002:aa7:d481:: with SMTP id b1mr2080111edr.226.1587573264439; 
 Wed, 22 Apr 2020 09:34:24 -0700 (PDT)
Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com.
 [209.85.128.45])
 by smtp.gmail.com with ESMTPSA id r26sm670398edw.34.2020.04.22.09.34.22
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 22 Apr 2020 09:34:23 -0700 (PDT)
Received: by mail-wm1-f45.google.com with SMTP id h2so3117854wmb.4
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 09:34:22 -0700 (PDT)
X-Received: by 2002:a7b:c858:: with SMTP id c24mr12056096wml.51.1587573262084; 
 Wed, 22 Apr 2020 09:34:22 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587490511.git.tamas.lengyel@intel.com>
 <8eb756357cb6d9222ed7ec4c0af58473160361a1.1587490511.git.tamas.lengyel@intel.com>
 <20200422085953.GB28601@Air-de-Roger>
 <CABfawhmBW4kiv_mCUrH_JTdCDZWdbb7Qf65_i350apx-q7NXbg@mail.gmail.com>
 <20200422154956.GE28601@Air-de-Roger>
In-Reply-To: <20200422154956.GE28601@Air-de-Roger>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Wed, 22 Apr 2020 10:33:45 -0600
X-Gmail-Original-Message-ID: <CABfawhnfgd8AMuovdcdYcraSk5GOszum71RYBAOZq46uSscs4g@mail.gmail.com>
Message-ID: <CABfawhnfgd8AMuovdcdYcraSk5GOszum71RYBAOZq46uSscs4g@mail.gmail.com>
Subject: Re: [PATCH v16 1/3] mem_sharing: fix sharability check during fork
 reset
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 22, 2020 at 9:50 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.com>=
 wrote:
>
> On Wed, Apr 22, 2020 at 06:42:42AM -0600, Tamas K Lengyel wrote:
> > On Wed, Apr 22, 2020 at 3:00 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.=
com> wrote:
> > >
> > > On Tue, Apr 21, 2020 at 10:47:23AM -0700, Tamas K Lengyel wrote:
> > > > @@ -666,20 +670,31 @@ static int page_make_sharable(struct domain *=
d,
> > > >       */
> > > >      if ( page->count_info !=3D (PGC_allocated | (2 + expected_refc=
nt)) )
> > > >      {
> > > > -        spin_unlock(&d->page_alloc_lock);
> > > >          /* Return type count back to zero */
> > > >          put_page_and_type(page);
> > > > -        return -E2BIG;
> > > > +        rc =3D -E2BIG;
> > > > +        goto out;
> > > > +    }
> > > > +
> > > > +    rc =3D 0;
> > > > +
> > > > +    if ( validate_only )
> > > > +    {
> > > > +        put_page_and_type(page);
> > >
> > > You seem to check some page attributes but then put the page again,
> > > which looks racy to me. Since you put the page, couldn't the checks
> > > that you have performed be stale by the point the data is consumed by
> > > the caller?
> >
> > During fork reset when this is called with validate_only =3D true the
> > domain is paused. Furthermore, fork reset is only for forks that have
> > no device model running, so nothing is interacting with its memory
> > that could acquire extra references. So no, this isn't racy since
> > there is nothing to race against that I'm aware of. Also, this check
> > is really to check for special pages, all of which are setup during
> > the initial fork process, not during runtime of the fork.
>
> Right, it would feel safer to me however if you just return from
> page_make_sharable while having a page reference, and drop it in
> mem_sharing_fork_reset if the page shouldn't be removed from the fork.
>
> This way you could also avoid having to take an extra reference just
> after returning from nominate_page in mem_sharing_fork_reset.
> page_make_sharable already returns while having taken an extra
> reference to the page in the non validate only case anyway.

Ah yea, that would make sense. Good idea!

> > >
> > > > +        goto out;
> > > >      }
> > > >
> > > >      page_set_owner(page, dom_cow);
> > > >      drop_dom_ref =3D !domain_adjust_tot_pages(d, -1);
> > > >      page_list_del(page, &d->page_list);
> > > > -    spin_unlock(&d->page_alloc_lock);
> > > >
> > > > +out:
> > > > +    if ( !validate_only )
> > > > +        spin_unlock(&d->page_alloc_lock);
> > > >      if ( drop_dom_ref )
> > > >          put_domain(d);
> > > > -    return 0;
> > > > +
> > > > +    return rc;
> > > >  }
> > > >
> > > >  static int page_make_private(struct domain *d, struct page_info *p=
age)
> > > > @@ -809,8 +824,8 @@ static int debug_gref(struct domain *d, grant_r=
ef_t ref)
> > > >      return debug_gfn(d, gfn);
> > > >  }
> > > >
> > > > -static int nominate_page(struct domain *d, gfn_t gfn,
> > > > -                         int expected_refcnt, shr_handle_t *phandl=
e)
> > > > +static int nominate_page(struct domain *d, gfn_t gfn, int expected=
_refcnt,
> > >
> > > Is there any reason for expected_refcnt to be signed? All callers use
> > > unsigned values.
> >
> > No reason. It's just how the code was written by the original author
> > and we never changed it.
>
> Since you are already changing those lines, can I ask you to also
> change it to unsigned in the places that you touch?

Sure thing.

Thanks,
Tamas


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 16:54:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 16:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRIdv-000829-Ny; Wed, 22 Apr 2020 16:54:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRIdu-000824-1E
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 16:54:34 +0000
X-Inumbo-ID: ec78e4cc-84b9-11ea-92b3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ec78e4cc-84b9-11ea-92b3-12813bfff9fa;
 Wed, 22 Apr 2020 16:54:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Vd6xwCvnAXhZwTflpdqa+AEVWuNFChrum4ai7fk3Ob8=; b=odEoDIxj8Afwe7evkQWjgcp5l
 HCOhgkXoq4p19owzPgoP0BeqHdPxC0R5/Y5K6S8a0KTZ2r1/IVzDrvwukWqmc2Ox+bDF/p2/mNOfx
 /zpyBKCr2fa9ieF4bRmFlBy9FwmkTZVHsGYzKO1fEdJEkrFfa41/DtNShxkBbce02FvQo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRIdl-0003ga-PK; Wed, 22 Apr 2020 16:54:25 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRIdl-0001wH-Bc; Wed, 22 Apr 2020 16:54:25 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRIdl-0004N7-AI; Wed, 22 Apr 2020 16:54:25 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149726-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149726: regressions - FAIL
X-Osstest-Failures: xen-unstable:test-amd64-i386-qemuu-rhel6hvm-amd:guest-start/redhat.repeat:fail:regression
 xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=4803a67114279a656a54a23cebed646da32efeb6
X-Osstest-Versions-That: xen=82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 16:54:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149726 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149726/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 149705

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat    fail  like 149702
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149705
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149705
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149705
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149705
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149705
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149705
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149705
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149705
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149705
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149705
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  4803a67114279a656a54a23cebed646da32efeb6
baseline version:
 xen                  82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638

Last test of basis   149705  2020-04-21 10:39:06 Z    1 days
Testing same since   149726  2020-04-21 22:07:46 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christian Lindig <christian.lindig@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 4803a67114279a656a54a23cebed646da32efeb6
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Feb 21 17:56:57 2020 +0000

    x86: Enumeration for Control-flow Enforcement Technology
    
    The CET spec has been published and guest kernels are starting to get support.
    Introduce the CPUID and MSRs, and fully block the MSRs from guest use.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Wei Liu <wl@xen.org>

commit 7aacf6ac49829d8dd6242f67460f4d52d0d36503
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 21 11:03:46 2020 +0200

    x86/shadow: don't open-code shadow_blow_tables_per_domain()
    
    Make shadow_blow_all_tables() call the designated function, and on this
    occasion make the function itself use domain_vcpu().
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>

commit e55c9b25349c133a333b7b827d3b4645a84b5846
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 21 11:02:36 2020 +0200

    x86/shadow: the trace_emul_write_val() hook is HVM-only
    
    Its only caller lives in HVM-only code, and the only caller of
    trace_shadow_emulate() also already site in a HVM-only code section.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>

commit 2fb2dee1ac6288349a8a8320cde739df4f0e379f
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 21 10:59:43 2020 +0200

    x86/mm: pagetable_dying() is HVM-only
    
    Its only caller lives in HVM-only code.
    
    This involves wider changes, in order to limit #ifdef-ary: Shadow's
    SHOPT_FAST_EMULATION and the fields used by it get constrained to HVM
    builds as well. Additionally the shadow_{init,continue}_emulation()
    stubs for the !HVM case aren't needed anymore and hence get dropped.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>

commit 8b8d011ad868df38afae6282103087556beaa1f9
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 21 10:58:45 2020 +0200

    x86/shadow: the guess_wrmap() hook is needed for HVM only
    
    sh_remove_write_access() bails early for !external guests, and hence its
    building and thus the need for the hook can be suppressed altogether in
    !HVM configs.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>

commit df9238eaa4ad870bab835de5be3242f8f2a632ce
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 21 10:58:05 2020 +0200

    x86/shadow: sh_remove_write_access_from_sl1p() can be static
    
    It's only used by common.c.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>

commit 452219e246486d35fffb0b418f97db1beb9bc37c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 21 10:57:04 2020 +0200

    x86/shadow: monitor table is HVM-only
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>

commit ac7addbeff73bc8b06d8234a0e1658bba9368164
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 21 10:55:58 2020 +0200

    x86/shadow: drop a stray forward structure declaration
    
    struct sh_emulate_ctxt is private to shadow code, and hence a
    declaration for it is not needed here.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>

commit 3957e12c02670b97855ef0933b373f99993fa598
Author: Roger Pau Monné <roger.pau@citrix.com>
Date:   Tue Apr 21 10:54:56 2020 +0200

    x86/vtd: relax EPT page table sharing check
    
    The EPT page tables can be shared with the IOMMU as long as the page
    sizes supported by EPT are also supported by the IOMMU.
    
    Current code checks that both the IOMMU and EPT support the same page
    sizes, but this is not strictly required, the IOMMU supporting more
    page sizes than EPT is fine and shouldn't block page table sharing.
    
    This is likely not a common case (IOMMU supporting more page sizes
    than EPT), but should still be fixed for correctness.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>

commit a94b55a2986145ab5b357feb340f782d9d199d10
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 21 10:51:42 2020 +0200

    x86emul: SYSRET must change CPL
    
    The special AMD behavior of leaving SS mostly alone wasn't really
    complete: We need to adjust CPL aka SS.DPL.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>

commit 59b087e3954402c487e0abb4ad9bd05f43669436
Author: Julien Grall <jgrall@amazon.com>
Date:   Mon Mar 30 15:14:23 2020 +0100

    tools/ocaml: Fix stubs build when OCaml has been compiled with -safe-string
    
    The OCaml code has been fixed to handle properly -safe-string in Xen
    4.11, however the stubs part were missed.
    
    On OCaml newer than 4.06.1, String_Val() will return a const char *
    when using -safe-string leading to build failure when this is used
    in place where char * is expected.
    
    The main use in Xen code base is when a new string is allocated. The
    suggested approach by the OCaml community [1] is to use the helper
    caml_alloc_initialized_string() but it was introduced by OCaml 4.06.1.
    
    The next best approach is to cast String_val() to (char *) as the helper
    would have done. So use it when we need to update the new string using
    memcpy().
    
    Take the opportunity to remove the unnecessary cast of the source as
    mempcy() is expecting a void *.
    
    [1] https://github.com/ocaml/ocaml/pull/1274
    
    Reported-by: Dario Faggioli <dfaggioli@suse.com>
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Acked-by: Christian Lindig <christian.lindig@citrix.com>

commit 78686437e949a85a207ae1a0d637efe2d3778bbe
Author: Julien Grall <jgrall@amazon.com>
Date:   Mon Mar 30 18:50:08 2020 +0100

    tools/ocaml: libxb: Avoid to use String_val() when value is bytes
    
    Commit ec7d54dd1a "ocaml/libs/xb: Use bytes in place of strings for
    mutable buffers" switch mutable buffers from string to bytes. However
    the C code were still using String_Val() to access them.
    
    While the underlying structure is the same between string and bytes, a
    string is meant to be immutable. OCaml 4.06.1 and later will enforce it.
    Therefore, it will not be possible to build the OCaml libs when using
    -safe-string. This is because String_val() will return a const value.
    
    To avoid plain cast in the code, the code is now switched to use
    Bytes_val(). As the macro is not defined in older OCaml version, we need
    to provide a stub.
    
    Take the opportunity to switch to const the buffer in
    ml_interface_write() as it should not be modified.
    
    Reported-by: Dario Faggioli <dfaggioli@suse.com>
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Acked-by: Christian Lindig <christian.lindig@citrix.com>

commit d92ba1aa7cf877a77abdcbd94a6a19fc55886a75
Author: Julien Grall <jgrall@amazon.com>
Date:   Mon Mar 30 14:29:10 2020 +0100

    tools/ocaml: libxb: Harden stub_header_of_string()
    
    stub_header_of_string() should not modify the header. So mark the
    variable 'hdr' as const.
    
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Acked-by: Christian Lindig <christian.lindig@citrix.com>

commit 3bf69699cacad3efb4fe6109044365f79379ed20
Author: Julien Grall <jgrall@amazon.com>
Date:   Sun Mar 29 20:12:34 2020 +0100

    tools/ocaml: libxc: Check error return in stub_xc_vcpu_context_get()
    
    xc_vcpu_getcontext() may fail to retrieve the vcpu context. Rather than
    ignoring the return value, check it and throw an error if needed.
    
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Acked-by: Christian Lindig <christian.lindig@citrix.com>

commit ca58e7b0800aaef85739508674abca2db9c6637d
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Apr 17 12:31:13 2020 +0100

    x86/pv: Delete CONFIG_PV_LDT_PAGING
    
    ... in accordance with the timeline laid out in the Kconfig message.  There
    has been no comment since it was disabled by default.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Wei Liu <wl@xen.org>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 18:08:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 18:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRJmu-0006Hl-0V; Wed, 22 Apr 2020 18:07:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=nI87=6G=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRJms-0006Hg-7R
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 18:07:54 +0000
X-Inumbo-ID: 2f08dedc-84c4-11ea-b58d-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2f08dedc-84c4-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 18:07:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587578873;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=hyo69tV4hYTkA6dzha8AK6bfIxwqnG4eZA8WfglpDqU=;
 b=Je/5zi7PpHExe++tY0MdSbMIcuewKofaCTfFhumSIx34YrHNOWLy3JP2
 wt9NAKtl92Oez13V4YyQ4awyzqfFZUa2CG3PK27PrSM8AHMzCekHTBnki
 6oWHIcxDS5dG5c2M7WM8DyG5GzTr7Wxi8zyAdyX90YvM1EUXrAU7QIQUy U=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: dO+AnPLyPDt/m73wRthnYAm16wShCidU4VC56Zua1cub1PHccwiEFdSeqNFUatDDXX33NyURZ4
 dz7YWFvv3t6jQcKowk4huhG7J1lTGpMGOyisYTwqz0aPNo1ZMQDeQs6JGKJVYYRykstAgEgDN3
 Z49IZ018xraXC2vD9JBpOcJtp7GIs5Od3kQVZ+sNdYMQLeSg86NdkY6ejulSpSR0bjNJCx5tPN
 Y9pafKiXc2jwYBiQ2WudrAbb36jGmpbYkuHr4DKpgAsPl90O2PgC29/1yICtUW485hcGpHT0uC
 47E=
X-SBRS: 2.7
X-MesageID: 16487488
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,304,1583211600"; d="scan'208";a="16487488"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 1/4] golang/xenlight: add NameToDomid and DomidToName util
 functions
Thread-Topic: [PATCH 1/4] golang/xenlight: add NameToDomid and DomidToName
 util functions
Thread-Index: AQHWERYbx3dgi/1zV0KyTdtBFGxU1KiFXiqA
Date: Wed, 22 Apr 2020 18:07:49 +0000
Message-ID: <65721F76-319A-47E4-8184-116F02B2BCE3@citrix.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
 <e2d8d6c1293c8251be881cd471265aa8188ae2ae.1586727061.git.rosbrookn@ainfosec.com>
In-Reply-To: <e2d8d6c1293c8251be881cd471265aa8188ae2ae.1586727061.git.rosbrookn@ainfosec.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <12FB20DF6C3CFD46AD2270A747BF8236@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDEyLCAyMDIwLCBhdCAxMTowMiBQTSwgTmljayBSb3Nicm9vayA8cm9zYnJv
b2tuQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBNYW55IGV4cG9ydGVkIGZ1bmN0aW9ucyBpbiB4
ZW5saWdodCByZXF1aXJlIGEgZG9taWQgYXMgYW4gYXJndW1lbnQuIE1ha2UNCj4gaXQgZWFzaWVy
IGZvciBwYWNrYWdlIHVzZXJzIHRvIHVzZSB0aGVzZSBmdW5jdGlvbnMgYnkgYWRkaW5nIHdyYXBw
ZXJzDQo+IGZvciB0aGUgbGlieGwgdXRpbGl0eSBmdW5jdGlvbnMgbGlieGxfbmFtZV90b19kb21p
ZCBhbmQNCj4gbGlieGxfZG9taWRfdG9fbmFtZS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IE5pY2sg
Um9zYnJvb2sgPHJvc2Jyb29rbkBhaW5mb3NlYy5jb20+DQo+IC0tLQ0KPiB0b29scy9nb2xhbmcv
eGVubGlnaHQveGVubGlnaHQuZ28gfCAyMyArKysrKysrKysrKysrKysrKysrKysrKw0KPiAxIGZp
bGUgY2hhbmdlZCwgMjMgaW5zZXJ0aW9ucygrKQ0KPiANCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2dv
bGFuZy94ZW5saWdodC94ZW5saWdodC5nbyBiL3Rvb2xzL2dvbGFuZy94ZW5saWdodC94ZW5saWdo
dC5nbw0KPiBpbmRleCAzZjFiMGJhYTBjLi44NDkyYmNlYzRlIDEwMDY0NA0KPiAtLS0gYS90b29s
cy9nb2xhbmcveGVubGlnaHQveGVubGlnaHQuZ28NCj4gKysrIGIvdG9vbHMvZ29sYW5nL3hlbmxp
Z2h0L3hlbmxpZ2h0LmdvDQo+IEBAIC0yMCw2ICsyMCw3IEBAIHBhY2thZ2UgeGVubGlnaHQNCj4g
I2NnbyBMREZMQUdTOiAtbHhlbmxpZ2h0IC1seWFqbCAtbHhlbnRvb2xsb2cNCj4gI2luY2x1ZGUg
PHN0ZGxpYi5oPg0KPiAjaW5jbHVkZSA8bGlieGwuaD4NCj4gKyNpbmNsdWRlIDxsaWJ4bF91dGls
cy5oPg0KPiAqLw0KPiBpbXBvcnQgIkMiDQo+IA0KPiBAQCAtMTI0LDYgKzEyNSwyOCBAQCBmdW5j
IChjdHggKkNvbnRleHQpIENsb3NlKCkgZXJyb3Igew0KPiANCj4gdHlwZSBEb21pZCB1aW50MzIN
Cj4gDQo+ICsvLyBOYW1lVG9Eb21pZCByZXR1cm5zIHRoZSBEb21pZCBmb3IgYSBkb21haW4sIGdp
dmVuIGl0cyBuYW1lLCBpZiBpdCBleGlzdHMuDQo+ICtmdW5jIChDdHggKkNvbnRleHQpIE5hbWVU
b0RvbWlkKG5hbWUgc3RyaW5nKSAoRG9taWQsIGVycm9yKSB7DQo+ICsJdmFyIGRvbWlkIEMudWlu
dDMyX3QNCj4gKw0KPiArCWNuYW1lIDo9IEMuQ1N0cmluZyhuYW1lKQ0KPiArCWRlZmVyIEMuZnJl
ZSh1bnNhZmUuUG9pbnRlcihjbmFtZSkpDQo+ICsNCj4gKwlpZiByZXQgOj0gQy5saWJ4bF9uYW1l
X3RvX2RvbWlkKEN0eC5jdHgsIGNuYW1lLCAmZG9taWQpOyByZXQgIT0gMCB7DQo+ICsJCXJldHVy
biBeRG9taWQoMCksIEVycm9yKHJldCkNCg0KbGlieGwuaCBkZWZpbmVzIElOVkFMSURfRE9NSUQg
4oCUIGRvIHdlIHdhbnQgdG8gZGVmaW5lIGFuIGV4cG9ydGVkIGNvbnN0YW50IHdpdGggdGhlIHNh
bWUgbmFtZSBhbmQgdXNlIHRoYXQgaGVyZT8gIChBbHRob3VnaCBwYXJ0IG9mIG1lIHdvbmRlcnMg
aWYgRE9NSURfSU5WQUxJRCB3b3VsZCBiZSBhIGJldHRlciBvcHRpb24uKQ0KDQo+ICsJfQ0KPiAr
DQo+ICsJcmV0dXJuIERvbWlkKGRvbWlkKSwgbmlsDQo+ICt9DQo+ICsNCj4gKy8vIERvbWlkVG9O
YW1lIHJldHVybnMgdGhlIG5hbWUgZm9yIGEgZG9tYWluLCBnaXZlbiBpdHMgZG9taWQuDQo+ICtm
dW5jIChDdHggKkNvbnRleHQpIERvbWlkVG9OYW1lKGRvbWlkIERvbWlkKSBzdHJpbmcgew0KPiAr
CWNuYW1lIDo9IEMubGlieGxfZG9taWRfdG9fbmFtZShDdHguY3R4LCBDLnVpbnQzMl90KGRvbWlk
KSkNCj4gKwlkZWZlciBDLmZyZWUodW5zYWZlLlBvaW50ZXIoY25hbWUpKQ0KPiArDQo+ICsJcmV0
dXJuIEMuR29TdHJpbmcoY25hbWUpDQo+ICt9DQoNCkl0IGxvb2tzIHRvIG1lIGxpa2UgaWYgdGhl
IGRvbWlkIGRvZXNu4oCZdCBleGlzdCwgbGlieGxfZG9taWRfdG9fbmFtZSgpIHdpbGwgcmV0dXJu
IE5VTEw7IGFuZCB0aGVuIERvbWlkVG9OYW1lIHdpbGwgcmV0dXJuIOKAnOKAnS4gIElzIHRoYXQg
d2hhdCB3ZSB3YW50Pw0KDQpJZiBzbywgaXQgc2hvdWxkIHByb2JhYmx5IGJlIGRvY3VtZW50ZWQu
DQoNCk9uZSB0aGluZyB0aGF0IG1pZ2h0IGJlIHdvcnRoIHBvaW50aW5nIG91dCBpcyB0aGF0IGJv
dGggb2YgdGhlc2UgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSByYWN5OiBUaGVyZeKAmXMgbm8gZ3Vh
cmFudGVlIHRoYXQgYnkgdGhlIHRpbWUgbGlieGxfZG9taWRfdG9fbmFtZSgpIHJldHVybnMgdGhh
dCB0aGUgZG9tYWluIHdpdGggdGhhdCBuYW1lIGhhcyBkaWVkLCBhbmQgYW5vdGhlciBkb21haW4g
d2l0aCBhIGRpZmZlcmVudCBuYW1lIGhhcyByZS11c2VkIHRoZSBzYW1lIGRvbWlkLiAgVGhhdOKA
mXMgcGFydGx5IHdoeSBYZW4gaGFzIHRoZSB3aG9sZSDigJxkb21haW4gcmVhcGVy4oCdIHN5c3Rl
bSwgbGlrZSBmb3IgVW5peCBwcm9jZXNzZXMgKHdoaWNoIHNvIGZhciBpc27igJl0IGltcGxlbWVu
dGFibGUgeWV0IHdpdGggdGhlIGdvbGFuZyB3cmFwcGVycykuICBJIHRoaW5rIHdoZW4gd2UgbWFr
ZSBvdXIg4oCcdm3igJ0gbGlicmFyeSwgd2XigJlyZSBnb2luZyB0byB3YW50IHRvIHRyeSB0byBj
b21lIHVwIHdpdGggc29tZXRoaW5nIGxpa2UgYW4gb2JqZWN0IHRoYXQgbWFrZXMgaXQgZWFzeSB0
byBhdm9pZCB0aGlzIHNvcnQgb2YgcmFjZS4NCg0KQnV0IHRoYXTigJlzIGEgZGlzY3Vzc2lvbiBm
b3IgYW5vdGhlciBkYXkuIDotKSAgRXZlcnl0aGluZyBlbHNlIGxvb2tzIGdvb2QsIHRoYW5rcy4N
Cg0KIC1HZW9yZ2U=


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 18:19:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 18:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRJxZ-0007JW-1C; Wed, 22 Apr 2020 18:18:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=nI87=6G=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRJxX-0007JR-Rt
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 18:18:55 +0000
X-Inumbo-ID: b932068d-84c5-11ea-92c3-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b932068d-84c5-11ea-92c3-12813bfff9fa;
 Wed, 22 Apr 2020 18:18:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587579534;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=cpDDr/FE9EF9GRbwzefTicYxITzzrMu8MMn8tsGt7RI=;
 b=hqlUbikW4uXAfKBj1DtWhEB27kxHny0uaO3CkWOFOQ8qXiplk+dUUdpD
 zRKiyhb8dyVRLxeJ9++jedW9wCS4m0cqyNMK8ASwgGdPw6EpdQUoU7KNe
 fOsSxLsYAvUlzXw9sI65uI7DjPhQ0EVldGF/CD+Dk/nkfCqQdj6BjDQDC s=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: fIVwoBWs+roMvmT/HyCk6mTpUgVvs7AZoKZWWpidOqVlIGWaB/L9uvHu2XRJi28NfzeKkZ3U0P
 TFa3hzZ3PFoG73ehyFlb14NmPSUCGFFn32QwGtmY0doyDsI74RWNEDJ0TwxttsSB+zV+KYuGah
 mIPCoLdJgOqN8t+0nRkVZUEopnrKwRi/Agtei7vVnzRnmfxPEqh2uxAp18Hgw7bO2TiymBKPpg
 z8/ekc2xSxF82/+VAbT4r4I685GnnVrI0xWufVKvgqZfvFOiwzj9f19oieUq09jUQGjD7HNCYU
 QAk=
X-SBRS: 2.7
X-MesageID: 16488111
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,304,1583211600"; d="scan'208";a="16488111"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 2/4] golang/xenlight: add DeviceNicAdd/Remove wrappers
Thread-Topic: [PATCH 2/4] golang/xenlight: add DeviceNicAdd/Remove wrappers
Thread-Index: AQHWERYbVTK8PO5Z/kOuRmMVsD4Gv6iFYT+A
Date: Wed, 22 Apr 2020 18:18:51 +0000
Message-ID: <0A603CD8-2054-413C-9096-F03CEE7B2D5E@citrix.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
 <87323a6eb60fd908ea2f792c9754cb88b283c5a6.1586727061.git.rosbrookn@ainfosec.com>
In-Reply-To: <87323a6eb60fd908ea2f792c9754cb88b283c5a6.1586727061.git.rosbrookn@ainfosec.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <A9BBFED4986DC94B9C429BA623F63B38@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDEyLCAyMDIwLCBhdCAxMTowMiBQTSwgTmljayBSb3Nicm9vayA8cm9zYnJv
b2tuQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBBZGQgRGV2aWNlTmljQWRkIGFuZCBEZXZpY2VO
aWNSZW1vdmUgYXMgd3JhcHBlcnMgZm9yDQo+IGxpYnhsX2RldmljZV9uaWNfYWRkIGFuZCBsaWJ4
bF9kZXZpY2VfbmljX3JlbW92ZS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IE5pY2sgUm9zYnJvb2sg
PHJvc2Jyb29rbkBhaW5mb3NlYy5jb20+DQo+IC0tLQ0KPiB0b29scy9nb2xhbmcveGVubGlnaHQv
eGVubGlnaHQuZ28gfCAzNCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+IDEgZmls
ZSBjaGFuZ2VkLCAzNCBpbnNlcnRpb25zKCspDQo+IA0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvZ29s
YW5nL3hlbmxpZ2h0L3hlbmxpZ2h0LmdvIGIvdG9vbHMvZ29sYW5nL3hlbmxpZ2h0L3hlbmxpZ2h0
LmdvDQo+IGluZGV4IDg0OTJiY2VjNGUuLmE1NmY5MTNiODEgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xz
L2dvbGFuZy94ZW5saWdodC94ZW5saWdodC5nbw0KPiArKysgYi90b29scy9nb2xhbmcveGVubGln
aHQveGVubGlnaHQuZ28NCj4gQEAgLTEwNjgsMyArMTA2OCwzNyBAQCBmdW5jIChDdHggKkNvbnRl
eHQpIFByaW1hcnlDb25zb2xlR2V0VHR5KGRvbWlkIHVpbnQzMikgKHBhdGggc3RyaW5nLCBlcnIg
ZXJyb3IpDQo+IAlwYXRoID0gQy5Hb1N0cmluZyhjcGF0aCkNCj4gCXJldHVybg0KPiB9DQo+ICsN
Cj4gKy8vIERldmljZU5pY0FkZCBhZGRzIGEgbmljIHRvIGEgZG9tYWluLg0KPiArZnVuYyAoQ3R4
ICpDb250ZXh0KSBEZXZpY2VOaWNBZGQoZG9taWQgRG9taWQsIG5pYyAqRGV2aWNlTmljKSBlcnJv
ciB7DQo+ICsJdmFyIGNuaWMgQy5saWJ4bF9kZXZpY2VfbmljDQo+ICsNCj4gKwlpZiBlcnIgOj0g
bmljLnRvQygmY25pYyk7IGVyciAhPSBuaWwgew0KPiArCQlyZXR1cm4gZXJyDQo+ICsJfQ0KPiAr
CWRlZmVyIEMubGlieGxfZGV2aWNlX25pY19kaXNwb3NlKCZjbmljKQ0KPiArDQo+ICsJcmV0IDo9
IEMubGlieGxfZGV2aWNlX25pY19hZGQoQ3R4LmN0eCwgQy51aW50MzJfdChkb21pZCksICZjbmlj
LCBuaWwpDQo+ICsJaWYgcmV0ICE9IDAgew0KPiArCQlyZXR1cm4gRXJyb3IocmV0KQ0KPiArCX0N
Cj4gKw0KPiArCXJldHVybiBuaWwNCj4gK30NCj4gKw0KPiArLy8gRGV2aWNlTmljUmVtb3ZlIHJl
bW92ZXMgYSBuaWMgZnJvbSBhIGRvbWFpbi4NCg0KSSBmZWVsIGxpa2UgSSB3YW50IHRvIHNheSBo
ZXJlIHdoYXQgaXQgaXMgeW91IGFjdHVhbGx5IGhhdmUgdG8gZmlsbCBpbiB0byByZW1vdmUgdGhl
IG5pYzsgYnV0IGFmdGVyIDEwIG1pbnV0ZXMgb2YgcG9raW5nIGFyb3VuZCB0aGUgY29kZSwgSeKA
mW0gbm90IGFjdHVhbGx5IHN1cmUgbXlzZWxmLiA6LSkgIChJIHRoaW5rIGl0ICptaWdodCogYmUg
anVzdCBEZXZpZCBhbmQgQmFja2VuZERvbWlkLikNCg0KU28gSeKAmWxsIGdpdmUgdGhpcyBmb3Ig
bm93Og0KDQpSZXZpZXdlZC1ieTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXgu
Y29tPg0KDQpBbmQgaWYgSSBmaW5kIGl0IGJlZm9yZSBJIGZpbmlzaCByZXZpZXdpbmcgdGhlIGVu
ZCBvZiB0aGUgc2VyaWVzLCB3ZSBjYW4gY2hlY2sgaXQgaW4gYW5kIGxvb2sgYXQgaW1wcm92aW5n
IHRoZSBkb2N1bWVudGF0aW9uIGxhdGVyLg0KDQogLUdlb3JnZQ==


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 18:56:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 18:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRKXR-0002Yj-Tw; Wed, 22 Apr 2020 18:56:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ldCW=6G=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRKXQ-0002Ye-5q
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 18:56:00 +0000
X-Inumbo-ID: e73757b2-84ca-11ea-b4f4-bc764e2007e4
Received: from mail-lf1-x132.google.com (unknown [2a00:1450:4864:20::132])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e73757b2-84ca-11ea-b4f4-bc764e2007e4;
 Wed, 22 Apr 2020 18:55:59 +0000 (UTC)
Received: by mail-lf1-x132.google.com with SMTP id g10so2580799lfj.13
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 11:55:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=gddG5PZDCbgewde5LFsrnaQZpH7b9VEvC8Um1KlBE4Y=;
 b=mYha5onfeMct02gBKfTECQcjXnR9cz+EgqVe/LdAWwX2NaZ77Y1IXF0z1Eakx57XIW
 WOSXJ6odvESCp/Ye94zaCXmzB19eVKXLFjXx+dzESV4F/zAtdCcYrbFnQ25QPdFm1MM/
 1oO3MokEguCiRsVUxw0N81rwTPFFecjwNENSUewDAE2gKKWtjob67SH2y8zGm3Hq3bFY
 qgzHSPC1CK0bT8/MsMwNjLgIVI2nMk9BDx5gciINeOsBbj9I/t4sdeh6Gmh8IlBUr3Q8
 TJPrrsbD9ZkWpr/ScksMqRtydFQS9oMzdlkSiDYWWYMwHBHiWbpXQlWr6fKh3e6sNv29
 II8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=gddG5PZDCbgewde5LFsrnaQZpH7b9VEvC8Um1KlBE4Y=;
 b=ac3WUxMtHy0a3qZOe2a8vIbK0G8R4714yeKUv9LwliclW2uEanOphLOCCiS6P815qF
 IyFQ4bM9f6SdsqWX6kID6rqloWPM9IZ+6D+ktjV6SoNY6zwuj40k1pE4obcZWaBdU/Tc
 P/TdhBO3qnGdLO2h774gXgJbiPNzOgjFxi18D0stQAsM6Out2BygVFnJE0jtxLpQ8U1z
 D6t267g0er6UKnjzBw7lwct/WOn4kKWeLJBDOT+Jx1CCeezoMvl27YlZqAFW+LN+3g5T
 wQmRiY6F8CeHN4UijaOj+MKDVexBR2ZQBzYvpJElQ+w0pr3mtt8aat6v+0eZsGara3da
 GVHA==
X-Gm-Message-State: AGi0PuaYnGXySMgWfBnONlkAetGgqHn1keD5ASvXeCC0Zr7sqb3oVI1U
 vmACAcBUIf12ruu60dWecGCE7oG4CYYYJhTQLsS/TxLk
X-Google-Smtp-Source: APiQypJzaeYlYzHGR2Z41U+t6aDQKbWRs6Av9fAAJKSgW8XTx5rSsobCmNW/QlAHAVWp+sl34kdpih26EQPbCjGG/tM=
X-Received: by 2002:a19:1c3:: with SMTP id 186mr17922436lfb.191.1587581758004; 
 Wed, 22 Apr 2020 11:55:58 -0700 (PDT)
MIME-Version: 1.0
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
In-Reply-To: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Wed, 22 Apr 2020 14:55:46 -0400
Message-ID: <CAEBZRSe=yB6Y1TQSQqAphDw8gVKm8VhpqEYsKXgVnZjvPNPUnQ@mail.gmail.com>
Subject: Re: Golang Xen packages and the golang packaging system
To: George Dunlap <George.Dunlap@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> One question I have from the above is how the xen.git RELEASE-X.Y.Z shoul=
d correspond to the vA.B.C in the golang package repo.
>
> The obvious answer, of course, is (A, B, C) =3D (X, Y, Z); that is, xen.g=
it tag RELEASE-4.14.0 should create a golang package tag of v4.14.0.
>
> The issue with this is that golang assumes you=E2=80=99re using semantic =
versioning; so a `go get -u` would normally feel justified in upgrading fro=
m v4.14.x to v4.15.x.
>
> A couple of possible responses:
>
> 1. Declare that OK.  That would mean not only that we have to have v4.15.=
x be compatible with golang source code written against v4.14; it would als=
o mean that v4.15.x needs to be able to *compile* against libxl version 4.1=
4.  Which might be a good idea, but we=E2=80=99d want to think carefully be=
fore making that kind of commitment.
>
> 2. Declare that people need to use `go get -u=3Dpatch` when updating, and=
/or use go.mod &c to manually restrict the version of go to use to the curr=
ently-installed Xen version
>
> 3. Map (A, B, C) =3D (Y, Z, 0).  (i.e., RELEASE-4.14.5 would make tag v14=
.5.0 .)  `go get` wouldn=E2=80=99t update automatically, but it might be co=
nfusing which version *should* be used; particularly if we ever roll over a=
 major version for Xen.
>
> Any other possibilities?
>
> I think I=E2=80=99d start out with #2, and then consider moving to #1 at =
some point in the future.
>
> Thoughts?

We should also consider aligning with Go module versioning
conventions. For example, right now the package is unstable, so
according to convention we should be in v0.1.x. A "v0" indicates to
the Go ecosystem that, at this stage, we will likely make breaking
changes to the package API. So, tagging v4.14.0 is a bit confusing
since this indicates that we are on the 4th major version of the
package, and that it's stable. See [1] and [2] for more on these
conventions.

However, things are obviously complicated by the fact that the
xenlight package depends on libxl, and following convention might make
that relationship less clear and difficult to track. But, if we stray
from convention we at least need to be clear about it and have a good
explanation why.

That said, unless we can come up with a good way to follow convention
*and* keep the libxl version sorted, I think #2 makes the most sense
right now.

-NR

[1] https://blog.golang.org/publishing-go-modules
[2] https://blog.golang.org/v2-go-modules


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 19:47:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 19:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRLKq-0007DR-QC; Wed, 22 Apr 2020 19:47:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ldCW=6G=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRLKp-0007DM-S0
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 19:47:03 +0000
X-Inumbo-ID: 094a1414-84d2-11ea-9e09-bc764e2007e4
Received: from mail-lf1-x142.google.com (unknown [2a00:1450:4864:20::142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 094a1414-84d2-11ea-9e09-bc764e2007e4;
 Wed, 22 Apr 2020 19:47:03 +0000 (UTC)
Received: by mail-lf1-x142.google.com with SMTP id l11so2747541lfc.5
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 12:47:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=fH5ovlMQHSD35J+5fA7W367GKpKz222U1ZfjV1xIg7E=;
 b=obB0vOxKEhc05/wG2Cw6EK0B2bGPmU0rWBnrYmTQMAuNVBQdCtfSpr1laclLY4KBvZ
 1rC5C0rKhiLackNxPA08vUd4uSvpXVSnXLfGSATGQHChB9SaYc5f4zHj/YO1i1FBnXi8
 +Ur3tL5qCcduVoxgVDRKBGD8osheNux7KtdYjmD1yemS50g1w/CrfRFE/Af1JbIUITGQ
 Ncrhi0j64zibkSgjaxA9Uhsn8m7AHkEAZwdpemoamVe1nixqVxUHdC/arUwLeHK6HwRx
 E7NtWA8It4yQDLtrLn/CBm62JGoSRXy/SRpW+GfxWb13PViv6JWGZdFnydduENJeuR95
 7NRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=fH5ovlMQHSD35J+5fA7W367GKpKz222U1ZfjV1xIg7E=;
 b=Fg9fqmXsfmAaFOuPwlqfl4hcFKgZlEbAXU5HSTS/4j83X1mXHFANC1sfYVIAv8MNTS
 DZ5zNo7MEnoTRDM9fEcncy21GKUqukG3GEG+oHrVG2c76ewd+otVn+KRmn/4kz7GhtDC
 EXLno5nqOlIaih2A0foiKw/wjCGB5oq9FOphX/shUTUSpT00+kn9zIViml3UUNFhnqyT
 kRjFdTRpR641MCYK5knxgxD+iYuJaMon5rgvxL3pCr0yMjQ4UVy0KIA13QiQtQH8uIih
 YkvV+0cFYezpvFy6sZN6n3k51+ZckSMFgteHWA2zzqs0ZK5g/8uL7JDi70udtPs3XpJz
 Kt+w==
X-Gm-Message-State: AGi0PuZRK7gld9Z9dfodofaRNErqNwBHiJxatH5xL2ZzuM57Rq8t1Dnv
 utR5zz6EIFrCIi0FJrCWAYxL0T+q8hlkaem4Sgk=
X-Google-Smtp-Source: APiQypKJcp00pj5t78apj5qE1RxvSfKr92SkVWprDNXkhvU0tl8gF1Pk6rj9OQy/uhVme/lwWFe7+iwYFBOujhCoDio=
X-Received: by 2002:a19:6007:: with SMTP id u7mr114957lfb.9.1587584821755;
 Wed, 22 Apr 2020 12:47:01 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
 <e2d8d6c1293c8251be881cd471265aa8188ae2ae.1586727061.git.rosbrookn@ainfosec.com>
 <65721F76-319A-47E4-8184-116F02B2BCE3@citrix.com>
In-Reply-To: <65721F76-319A-47E4-8184-116F02B2BCE3@citrix.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Wed, 22 Apr 2020 15:46:50 -0400
Message-ID: <CAEBZRSckvUqCikFhtHECzmybwC_d8ojCfvBznvF90A7pS1A_1Q@mail.gmail.com>
Subject: Re: [PATCH 1/4] golang/xenlight: add NameToDomid and DomidToName util
 functions
To: George Dunlap <George.Dunlap@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> libxl.h defines INVALID_DOMID =E2=80=94 do we want to define an exported =
constant with the same name and use that here?  (Although part of me wonder=
s if DOMID_INVALID would be a better option.)

Yeah, that makes sense. I'll add that.

> > +     }
> > +
> > +     return Domid(domid), nil
> > +}
> > +
> > +// DomidToName returns the name for a domain, given its domid.
> > +func (Ctx *Context) DomidToName(domid Domid) string {
> > +     cname :=3D C.libxl_domid_to_name(Ctx.ctx, C.uint32_t(domid))
> > +     defer C.free(unsafe.Pointer(cname))
> > +
> > +     return C.GoString(cname)
> > +}
>
> It looks to me like if the domid doesn=E2=80=99t exist, libxl_domid_to_na=
me() will return NULL; and then DomidToName will return =E2=80=9C=E2=80=9D.=
  Is that what we want?
>
> If so, it should probably be documented.

I considered returning an error if C.GoString(cname) =3D=3D "". But, with
these functions (as well as the others in these series), I opted to
keep the signatures aligned with their libxl counterparts since we're
keeping the package API mostly one-to-one with libxl. I can add a
second return value if you prefer, otherwise I'll just add a note in
the comment.

> One thing that might be worth pointing out is that both of these function=
s are actually racy: There=E2=80=99s no guarantee that by the time libxl_do=
mid_to_name() returns that the domain with that name has died, and another =
domain with a different name has re-used the same domid.  That=E2=80=99s pa=
rtly why Xen has the whole =E2=80=9Cdomain reaper=E2=80=9D system, like for=
 Unix processes (which so far isn=E2=80=99t implementable yet with the gola=
ng wrappers).  I think when we make our =E2=80=9Cvm=E2=80=9D library, we=E2=
=80=99re going to want to try to come up with something like an object that=
 makes it easy to avoid this sort of race.

That's good to know, thanks. I'll add that to the comments as well.

> But that=E2=80=99s a discussion for another day. :-)  Everything else loo=
ks good, thanks.

Thanks!

-NR


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 19:58:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 19:58:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRLVi-0008Fb-U6; Wed, 22 Apr 2020 19:58:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ldCW=6G=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRLVg-0008FV-UP
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 19:58:17 +0000
X-Inumbo-ID: 9aa0d8f2-84d3-11ea-b58d-bc764e2007e4
Received: from mail-lf1-x144.google.com (unknown [2a00:1450:4864:20::144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9aa0d8f2-84d3-11ea-b58d-bc764e2007e4;
 Wed, 22 Apr 2020 19:58:16 +0000 (UTC)
Received: by mail-lf1-x144.google.com with SMTP id k28so2759268lfe.10
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 12:58:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=XcQb4M+NPUPy07eOdpHWYjbaoG6q04jfoDv78njdn1A=;
 b=i/YXNFiZeiPZluI9S/6tdQtbKRQE7bQBdnQEEbYI157v+bgrlwvpPCvSIgO78tUVkv
 jLFNjLoFCEY6EE3fUrEW2BklBfFQUE32XqeTTiS7RxVA/625ShnTYwtzXg5T6OkgtiSe
 ji6JlJaPmoDEM5j6upU1mNJKDN7ugcZzNgDClxnPT9aL9m0rkOP43QhXai4FHviYOZox
 +DESN/l4rj7H5PI+YY7F6yfBw5CBNR5WlYa6rJyF2g6JIPLcnn5Z3zt0gXO65EW5gt8o
 TfqY5wB5JwuvmAiL8e2E/NmnGs62RObBgvEMWFbyxlwHdeKN4iszyWJcuSrigiubOQcz
 LKdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=XcQb4M+NPUPy07eOdpHWYjbaoG6q04jfoDv78njdn1A=;
 b=CSuVUnNZH6T4BieppqpmJsLITFfH75rqEte99g95/m7fPmArZH4tikNoHHLyY3J49L
 jubQ8XCpySqbW498LDwc0+6vA0aWqH0sWV7KaYvcYFOib0PmtvyRmlRtkyvEiWJZhhFW
 UlGl70QAznIXM4CGX95sIDOUZh0Cx5bD6IVvFkaFD7WpK1MQwZT6rHkqBFYxhTSyRp1S
 LfarD+qXgBt10qxvzn9UCNruFZD7anl+jvxXduPtaFuytb11fJKnk6t7E1EEn99Vu5ev
 OtWXW3J9gk20QEnIWu8EqrnKOyzQkTMg4KiBlWsiwADsFqqlPBZcIeb8RaY8CeQr5wWv
 Sd+w==
X-Gm-Message-State: AGi0PuZquMgN6eGWCzSJBGZy2UBynlgZ61mf0SzBHVxz9Sqo3khCLIE+
 610JRr/6e/MEC4PdJos4zhG8fzZLGKNFZJNWx8c=
X-Google-Smtp-Source: APiQypJv3u3FZ2BCh+cqU86y5GNTOYOkIb8ZOi28a1gszK3+Ju7HbIkBzlCkjrgH5oBwzvVBD/qF3uBby/uomnQJRPk=
X-Received: by 2002:a05:6512:406:: with SMTP id
 u6mr148439lfk.150.1587585495058; 
 Wed, 22 Apr 2020 12:58:15 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
 <87323a6eb60fd908ea2f792c9754cb88b283c5a6.1586727061.git.rosbrookn@ainfosec.com>
 <0A603CD8-2054-413C-9096-F03CEE7B2D5E@citrix.com>
In-Reply-To: <0A603CD8-2054-413C-9096-F03CEE7B2D5E@citrix.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Wed, 22 Apr 2020 15:58:03 -0400
Message-ID: <CAEBZRSctbCjPANDcXG=8-1gxE1PQe6tiSBBq7_a1E6omd8dmKg@mail.gmail.com>
Subject: Re: [PATCH 2/4] golang/xenlight: add DeviceNicAdd/Remove wrappers
To: George Dunlap <George.Dunlap@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> I feel like I want to say here what it is you actually have to fill in to=
 remove the nic; but after 10 minutes of poking around the code, I=E2=80=99=
m not actually sure myself. :-)  (I think it *might* be just Devid and Back=
endDomid.)

IIRC, you can use just the MAC or devid. I was using just the MAC when
I tested it out.

> So I=E2=80=99ll give this for now:
>
> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
>
> And if I find it before I finish reviewing the end of the series, we can =
check it in and look at improving the documentation later.

Sounds good, thanks!

-NR


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 19:58:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 19:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRLVr-0008HO-Al; Wed, 22 Apr 2020 19:58:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRLVq-0008H4-5l
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 19:58:26 +0000
X-Inumbo-ID: 9c4eaa3a-84d3-11ea-92d1-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9c4eaa3a-84d3-11ea-92d1-12813bfff9fa;
 Wed, 22 Apr 2020 19:58:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=cKMbLdP1JsBa5gZcvbEmEdQIQyIeQnbumdVq+dlN/hg=; b=wQEM2lVC2VKRltZbBi/qtJTD8
 y6EHOFOOsMEj0N0+PUSLQsm0jBqzDjHMLDvb7pmUzaD4ygwb3+4o/s9LV4hAcj/DhiGFM742VXCAL
 /py5uUvNw+PHNrVkUqrj8rqMP0eykTWelv41CIt9EOb02+1PHuZm2vMdredDeRJGiM4oE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRLVi-0007b9-53; Wed, 22 Apr 2020 19:58:18 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRLVh-00047Y-T1; Wed, 22 Apr 2020 19:58:17 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRLVh-00046a-Qd; Wed, 22 Apr 2020 19:58:17 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149728-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149728: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-5.4:test-amd64-amd64-xl-rtds:guest-saverestore:fail:heisenbug
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:heisenbug
 linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=6ccc74c083c0d472ac64f3733f5b7bf3f99f261e
X-Osstest-Versions-That: linux=bc844d58f697dff3ded4b410094ee89f5cedc04c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 19:58:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149728 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149728/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds    15 guest-saverestore fail in 149709 pass in 149728
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail in 149709 pass in 149728
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149709

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149637
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                6ccc74c083c0d472ac64f3733f5b7bf3f99f261e
baseline version:
 linux                bc844d58f697dff3ded4b410094ee89f5cedc04c

Last test of basis   149637  2020-04-13 09:10:52 Z    9 days
Failing since        149700  2020-04-17 09:09:37 Z    5 days    3 attempts
Testing same since   149709  2020-04-21 10:41:23 Z    1 days    2 attempts

------------------------------------------------------------
317 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   bc844d58f697..6ccc74c083c0  6ccc74c083c0d472ac64f3733f5b7bf3f99f261e -> tested/linux-5.4


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 20:13:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 20:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRLkQ-0001rg-NZ; Wed, 22 Apr 2020 20:13:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRLkP-0001rb-AH
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 20:13:29 +0000
X-Inumbo-ID: b69fc502-84d5-11ea-92d5-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b69fc502-84d5-11ea-92d5-12813bfff9fa;
 Wed, 22 Apr 2020 20:13:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=b02J02A/5tTzRxltwf4EpRM6loXPb5jA72q7a88R8u0=; b=jYRjAYMHDy3kw/mjg7yT4QOHy
 /ymqA5MskKPp/L6bUHLmC2L2oCNLp5CMrrW2qMq1tNwUSkd0N2uDhLQdKG4F4WBwWlKTgxDYqTkkL
 Figb5r/MSgkMzzaU+EpNyOn+iQx5cHL0aSDqAUIBKgkUPVuywErQRQQT+rmCFHo+cgLxI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRLkH-00081G-Ao; Wed, 22 Apr 2020 20:13:21 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRLkH-0004yo-2S; Wed, 22 Apr 2020 20:13:21 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRLkH-00005Z-1o; Wed, 22 Apr 2020 20:13:21 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149732-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149732: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=9ced95a49c7491d9e16650f68146f85e5878d499
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 20:13:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149732 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149732/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
 build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   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
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-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-i386-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-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              9ced95a49c7491d9e16650f68146f85e5878d499
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   96 days
Failing since        146211  2020-01-18 04:18:52 Z   95 days   88 attempts
Testing same since   149732  2020-04-22 04:18:51 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mark Asselstine <mark.asselstine@windriver.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Philipp Hahn <hahn@univention.de>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 15617 lines long.)


From xen-devel-bounces@lists.xenproject.org Wed Apr 22 22:41:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Apr 2020 22:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRO3H-0007A5-Gt; Wed, 22 Apr 2020 22:41:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GuZW=6G=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRO3G-00075N-5H
 for xen-devel@lists.xenproject.org; Wed, 22 Apr 2020 22:41:06 +0000
X-Inumbo-ID: 56749922-84ea-11ea-92ee-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 56749922-84ea-11ea-92ee-12813bfff9fa;
 Wed, 22 Apr 2020 22:40:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=BzOmB4a9A1YSjtd5Qf6HSFwRo/WZWpIJ+55T1dbwd7A=; b=L48uPhF2fCfvU+xtDIVyZcaXw
 dhFU6w8mr5f5154xbb9TKEV9iS+hL/H/aw4l0mJs9/KHlK5XJuksiw8LQX5ktK+VjJJwBv7wTw/X0
 /hoxH5vTfAmbQCu4TMzbJvW5e5/oaXtPWjcD3x6tJq6UAYhRVdicvlnBvUjEJHXYuzgUw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRO39-0002lC-DI; Wed, 22 Apr 2020 22:40:59 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRO39-00058W-4d; Wed, 22 Apr 2020 22:40:59 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRO39-0003Sr-3y; Wed, 22 Apr 2020 22:40:59 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149735-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149735: all pass - PUSHED
X-Osstest-Versions-This: ovmf=c6a60cf4b99069f55325675c7c7e98b510f4b224
X-Osstest-Versions-That: ovmf=b447a20bdfb2ff24ba048bb3026c902c4768a7e9
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 22 Apr 2020 22:40:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149735 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149735/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 c6a60cf4b99069f55325675c7c7e98b510f4b224
baseline version:
 ovmf                 b447a20bdfb2ff24ba048bb3026c902c4768a7e9

Last test of basis   149725  2020-04-21 20:09:37 Z    1 days
Testing same since   149735  2020-04-22 11:21:30 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Guomin Jiang <guomin.jiang@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   b447a20bdf..c6a60cf4b9  c6a60cf4b99069f55325675c7c7e98b510f4b224 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 00:25:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 00:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRPgJ-0000ET-Ml; Thu, 23 Apr 2020 00:25:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XA1d=6H=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRPgJ-0000EO-1C
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 00:25:31 +0000
X-Inumbo-ID: efea2e74-84f8-11ea-b4f4-bc764e2007e4
Received: from mail-qt1-x842.google.com (unknown [2607:f8b0:4864:20::842])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id efea2e74-84f8-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 00:25:30 +0000 (UTC)
Received: by mail-qt1-x842.google.com with SMTP id 71so3432414qtc.12
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 17:25:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id;
 bh=h+pwNdLOWjUpWrGteZatUyi5IhkS2B1ScCjGXT55ZGY=;
 b=UFK3Ras4EkjzXFGBE+kS/Xnk8G3Dxk4K1tE1HQglJcyQ42MI4c8gEMKrvcusC+FYDT
 J+7n7CKrm0lbT6xXauMLygdECmTwAGdi63lB+HiDBNOAC7WQpeNbyfNrucCtGJ5feYTy
 1xUmb9SoqoFdLMuEdmavjJyjCWxmgTKal2b5bkasetfTHo8G6fjm2LQLUZwJWDPDSs4d
 s1/rZ3DQ/M80Qp+5tWeXi2l5IzqF/IhXD94NudcmYYi3M0fiJZE4lVN76tgwc4vUf7qN
 6fLaAwTyvNXkb+mJhtMCKUdv38M8OVNjyppUJArEQKZFGlctO+qjRk8KDCPzaBvjq4Ox
 Xr+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id;
 bh=h+pwNdLOWjUpWrGteZatUyi5IhkS2B1ScCjGXT55ZGY=;
 b=cCsBoRGoODnfJ+YvkFq0zT9uv4FHjrysulL8DSzG2JgO2xwioxEivyU/04Jo+edzbo
 6EpfZ3WKipQWp/JbZlsYv/9bxu/sUICk3bMz7Rxk7pxDNrxqtm0ap6+NWa1AL+KgltWX
 YlUusLetrYJQ7MdSNUQRK41EUOkK3iwSVLRKEuruWWasw7C2Xmu7nT3rc1LahRGyye0g
 uAbg0VNHp7IY1ycoyQKcQPXtgtgGZ3k5P12P7bKsHNNtFAZz8DZTVguN83jfAEYMSTL9
 gU1a2MaFNigGG3Je/jzcXSrr1EX3tRNGPGvuTmIrxPtQNs6lj6Qk6u/PWOQfOrHdOI/F
 sOmA==
X-Gm-Message-State: AGi0PuY1kQl0VxBdjhEoGDXGK3M6tteUsFG4Y1H+mUm/Z059ajzdg9GI
 LVzeUGLy0IRSrlahfTBIx0hwq3F47iY=
X-Google-Smtp-Source: APiQypIxEsoR1buy6TZrD0ZugfhRB1M0OjMgETCp2UE8/5ffGfdXwwL9zcbptyHlLpNNoxnvznw1wA==
X-Received: by 2002:aed:2765:: with SMTP id n92mr1405454qtd.73.1587601529313; 
 Wed, 22 Apr 2020 17:25:29 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id j90sm669088qte.20.2020.04.22.17.25.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Apr 2020 17:25:28 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/2] build golang tools
Date: Wed, 22 Apr 2020 20:25:24 -0400
Message-Id: <cover.1587599094.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Nick Rosbrook <rosbrookn@ainfosec.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

These patches add support for the golang tools in the build system.

The behavior of configure with respect to the new variable,
CONFIG_GOLANG_TOOLS is copied from other components, such as the Ocaml
tools. Namely, build the tools by default if the go compiler is found.

Nick Rosbrook (2):
  tools: build golang tools if go compiler is present
  golang/xenlight: stop tracking generated files

 .gitignore                           |    3 +
 .hgignore                            |    2 +
 config/Tools.mk.in                   |    1 +
 m4/golang.m4                         |    4 +
 tools/Makefile                       |    2 +-
 tools/Rules.mk                       |    2 -
 tools/configure                      |  138 +
 tools/configure.ac                   |   12 +
 tools/golang/xenlight/Makefile       |    1 +
 tools/golang/xenlight/helpers.gen.go | 4658 --------------------------
 tools/golang/xenlight/types.gen.go   | 1225 -------
 11 files changed, 162 insertions(+), 5886 deletions(-)
 create mode 100644 m4/golang.m4
 delete mode 100644 tools/golang/xenlight/helpers.gen.go
 delete mode 100644 tools/golang/xenlight/types.gen.go

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 00:25:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 00:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRPgO-0000Ee-US; Thu, 23 Apr 2020 00:25:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XA1d=6H=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRPgN-0000EZ-Sb
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 00:25:35 +0000
X-Inumbo-ID: f0de2a24-84f8-11ea-9e09-bc764e2007e4
Received: from mail-qt1-x843.google.com (unknown [2607:f8b0:4864:20::843])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f0de2a24-84f8-11ea-9e09-bc764e2007e4;
 Thu, 23 Apr 2020 00:25:31 +0000 (UTC)
Received: by mail-qt1-x843.google.com with SMTP id z90so3440009qtd.10
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 17:25:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=54Yo/CmXj3GfX8VmGqgKQ7FZ0LlX1+GiaRBwFewzMro=;
 b=k8dYunRPbEKFeUySCyZdtbr+5AlKRM2DZYY4Zp/WgEHRWWNA2YoRjzsdP/QmzTgkzW
 ogKdXpECN6zJjLeZ9U0IO0hTJsu42ThdHXtTBqBjWj0/Xt7vh5PF4yQod9C5oPCAAZOY
 93Yfg5dpMc91GcEx9NaR7O2gv4PZw9kgBddQoYxq7e/yZlD8ROwSVGM/cWMYyheDOIm5
 sZAxp2iMgC0t88CWq751COXrBtny++SVCkRoZ21fxsea/vcfR1/14VLW0GDYGyYRq+2c
 AB/l2DzvaB97ydgMIP0C9QtzBQTwxJVx4C+Bk1V0dT1/eTID58bA8k7t5bIzDbhj2eDD
 LEJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=54Yo/CmXj3GfX8VmGqgKQ7FZ0LlX1+GiaRBwFewzMro=;
 b=Ro1RLfv0OIdoRS9t4oarHTQ14Keae7V/a9gI1Bd4g5/cWfgJdD2SjPY67gZ9AnVkyB
 htv8pCHqRK2/LP+qapSyOOna6SafvXeMJHoodbX4/yThkzJwBGzRGzxgAUdLZH1GvuU1
 7GPWmDMI4yuExhQjdWJ1fRqFRg28aKerLAaFDVHxMXCqe3kyYDz0psBAo7A/k0rYfK65
 JLJ0sp/gweF61Su6TUjzDssYUJdIULEpfmpqKjhSk8j7UsCkJRLsV6Kgf7ckGCOJAF4f
 qOF3WkWaKkQYANWDc1PTw2ABqyjp2zxbAC03BYYAYSMGVfKSDKYS3Caz0FeFucfKvQW/
 9HuA==
X-Gm-Message-State: AGi0PuaPu9L5qnuwUdBeWIrgtuV2JBJaqSkBnDnKC2yTeTQjjFyGxSaV
 IjE/QO2HWp7MbAmt4PDKPycmCh1KHxI=
X-Google-Smtp-Source: APiQypJGlFyjvZADY5o1y3jHWmP7RN+PLDvHbokx1/YoFm4Bdr9KWDQo0KMmfPFdMZ7DGzzaFeRATw==
X-Received: by 2002:ac8:7cba:: with SMTP id z26mr1447090qtv.143.1587601530753; 
 Wed, 22 Apr 2020 17:25:30 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id j90sm669088qte.20.2020.04.22.17.25.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Apr 2020 17:25:30 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 1/2] tools: build golang tools if go compiler is present
Date: Wed, 22 Apr 2020 20:25:25 -0400
Message-Id: <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587599094.git.rosbrookn@ainfosec.com>
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1587599094.git.rosbrookn@ainfosec.com>
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

By default, if the go compiler is found by the configure script, build
the golang tools. If the compiler is not found, and
--enable-golang_tools was not explicitly set, do not build to the golang
tools.

The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove
CONFIG_GOLANG from tools/Rules.mk since the new variable is set by
configure.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 config/Tools.mk.in |   1 +
 m4/golang.m4       |   4 ++
 tools/Makefile     |   2 +-
 tools/Rules.mk     |   2 -
 tools/configure    | 138 +++++++++++++++++++++++++++++++++++++++++++++
 tools/configure.ac |  12 ++++
 6 files changed, 156 insertions(+), 3 deletions(-)
 create mode 100644 m4/golang.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 189fda1596..2c219f5477 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -55,6 +55,7 @@ CONFIG_QEMU_TRAD    := @qemu_traditional@
 CONFIG_QEMU_XEN     := @qemu_xen@
 CONFIG_QEMUU_EXTRA_ARGS:= @EXTRA_QEMUU_CONFIGURE_ARGS@
 CONFIG_LIBNL        := @libnl@
+CONFIG_GOLANG_TOOLS := @golang_tools@
 
 CONFIG_SYSTEMD      := @systemd@
 SYSTEMD_CFLAGS      := @SYSTEMD_CFLAGS@
diff --git a/m4/golang.m4 b/m4/golang.m4
new file mode 100644
index 0000000000..0b4bd54ce0
--- /dev/null
+++ b/m4/golang.m4
@@ -0,0 +1,4 @@
+AC_DEFUN([AC_PROG_GO], [
+    dnl Check for the go compiler
+    AC_CHECK_TOOL([GO],[go],[no])
+])
diff --git a/tools/Makefile b/tools/Makefile
index c10946e3b1..81be8db757 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -31,7 +31,7 @@ endif
 
 SUBDIRS-y += xenpmd
 SUBDIRS-y += libxl
-SUBDIRS-$(CONFIG_GOLANG) += golang
+SUBDIRS-$(CONFIG_GOLANG_TOOLS) += golang
 SUBDIRS-y += xl
 SUBDIRS-y += helpers
 SUBDIRS-$(CONFIG_X86) += xenpaging
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 9bac15c8d1..5b8cf748ad 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -35,8 +35,6 @@ XENSTORE_XENSTORED ?= y
 debug ?= y
 debug_symbols ?= $(debug)
 
-# Set CONFIG_GOLANG=y in .config (or in make) to build golang
-CONFIG_GOLANG ?= n
 XEN_GOPATH        = $(XEN_ROOT)/tools/golang
 XEN_GOCODE_URL    = golang.xenproject.org
 
diff --git a/tools/configure b/tools/configure
index 4fa5f7b937..a4199573fd 100755
--- a/tools/configure
+++ b/tools/configure
@@ -664,6 +664,7 @@ pyconfig
 PYTHONPATH
 CHECKPOLICY
 XENSTORED
+GO
 OCAMLFIND
 OCAMLBUILD
 OCAMLDOC
@@ -705,6 +706,7 @@ LD86
 AS86
 qemu_traditional
 LINUX_BACKEND_MODULES
+golang_tools
 seabios
 ovmf
 xsmpolicy
@@ -807,6 +809,7 @@ enable_ocamltools
 enable_xsmpolicy
 enable_ovmf
 enable_seabios
+enable_golang_tools
 with_linux_backend_modules
 enable_qemu_traditional
 enable_rombios
@@ -1493,6 +1496,7 @@ Optional Features:
   --disable-xsmpolicy     Disable XSM policy compilation (default is ENABLED)
   --enable-ovmf           Enable OVMF (default is DISABLED)
   --disable-seabios       Disable SeaBIOS (default is ENABLED)
+  --disable-golang_tools  Disable Go tools (default is ENABLED)
   --enable-qemu-traditional
                           Enable qemu traditional device model, (DEFAULT is on
                           for Linux or NetBSD x86, otherwise off)
@@ -3870,6 +3874,8 @@ esac
 
 
 
+
+
 
 
 
@@ -4200,6 +4206,29 @@ seabios=$ax_cv_seabios
 
 
 
+# Check whether --enable-golang_tools was given.
+if test "${enable_golang_tools+set}" = set; then :
+  enableval=$enable_golang_tools;
+fi
+
+
+if test "x$enable_golang_tools" = "xno"; then :
+
+    ax_cv_golang_tools="n"
+
+elif test "x$enable_golang_tools" = "xyes"; then :
+
+    ax_cv_golang_tools="y"
+
+elif test -z $ax_cv_golang_tools; then :
+
+    ax_cv_golang_tools="y"
+
+fi
+golang_tools=$ax_cv_golang_tools
+
+
+
 
 # Check whether --with-linux-backend-modules was given.
 if test "${with_linux_backend_modules+set}" = set; then :
@@ -6694,6 +6723,115 @@ fi
 
 fi
 
+if test "x$golang_tools" = "xy"; then :
+
+
+        if test -n "$ac_tool_prefix"; then
+  # Extract the first word of "${ac_tool_prefix}go", so it can be a program name with args.
+set dummy ${ac_tool_prefix}go; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_GO+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if test -n "$GO"; then
+  ac_cv_prog_GO="$GO" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+    for ac_exec_ext in '' $ac_executable_extensions; do
+  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_GO="${ac_tool_prefix}go"
+    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+fi
+fi
+GO=$ac_cv_prog_GO
+if test -n "$GO"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $GO" >&5
+$as_echo "$GO" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+fi
+if test -z "$ac_cv_prog_GO"; then
+  ac_ct_GO=$GO
+  # Extract the first word of "go", so it can be a program name with args.
+set dummy go; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_ac_ct_GO+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if test -n "$ac_ct_GO"; then
+  ac_cv_prog_ac_ct_GO="$ac_ct_GO" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+    for ac_exec_ext in '' $ac_executable_extensions; do
+  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_ac_ct_GO="go"
+    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+fi
+fi
+ac_ct_GO=$ac_cv_prog_ac_ct_GO
+if test -n "$ac_ct_GO"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_GO" >&5
+$as_echo "$ac_ct_GO" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+  if test "x$ac_ct_GO" = x; then
+    GO="no"
+  else
+    case $cross_compiling:$ac_tool_warned in
+yes:)
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
+$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
+ac_tool_warned=yes ;;
+esac
+    GO=$ac_ct_GO
+  fi
+else
+  GO="$ac_cv_prog_GO"
+fi
+
+
+    if test "x$GO" = "xno"; then :
+
+        if test "x$enable_golang_tools" =  "xyes"; then :
+
+            as_fn_error $? "Go tools enabled, but missing go compiler" "$LINENO" 5
+
+fi
+        golang_tools="n"
+
+fi
+
+fi
+
 
 
 
diff --git a/tools/configure.ac b/tools/configure.ac
index ea0272766f..69e0894638 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -73,6 +73,7 @@ m4_include([../m4/fetcher.m4])
 m4_include([../m4/ax_compare_version.m4])
 m4_include([../m4/paths.m4])
 m4_include([../m4/systemd.m4])
+m4_include([../m4/golang.m4])
 
 AX_XEN_EXPAND_CONFIG()
 
@@ -84,6 +85,7 @@ AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools])
 AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
 AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
 AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
+AX_ARG_DEFAULT_ENABLE([golang_tools], [Disable Go tools])
 
 AC_ARG_WITH([linux-backend-modules],
     AS_HELP_STRING([--with-linux-backend-modules="mod1 mod2"],
@@ -320,6 +322,16 @@ AS_IF([test "x$ocamltools" = "xy"], [
     ])
 ])
 
+AS_IF([test "x$golang_tools" = "xy"], [
+    AC_PROG_GO
+    AS_IF([test "x$GO" = "xno"], [
+        AS_IF([test "x$enable_golang_tools" =  "xyes"], [
+            AC_MSG_ERROR([Go tools enabled, but missing go compiler])
+        ])
+        golang_tools="n"
+    ])
+])
+
 m4_include([../m4/xenstored.m4])
 AX_XENSTORE_OPTIONS
 AX_XENSTORE_SET
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 00:25:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 00:25:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRPgg-0000Fx-6u; Thu, 23 Apr 2020 00:25:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XA1d=6H=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRPgf-0000Fp-3I
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 00:25:53 +0000
X-Inumbo-ID: f411f4b4-84f8-11ea-83d8-bc764e2007e4
Received: from mail-qt1-x82e.google.com (unknown [2607:f8b0:4864:20::82e])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f411f4b4-84f8-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 00:25:37 +0000 (UTC)
Received: by mail-qt1-x82e.google.com with SMTP id 92so3479559qtg.0
 for <xen-devel@lists.xenproject.org>; Wed, 22 Apr 2020 17:25:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=5EJb+QA+QlNkg6psQhVkZFgAjPM8l4HdiO80d945so0=;
 b=cWuZIXoV1c9Fk/yETOiaUio3/2I8D7xTozkAsDii9Xxi7TO8p0KTg8wfb2YxssE8Yt
 m604E+oFjpoTRJwAVdGfiNupA0q+ucuh/oafrcnzE2qM+Uir9mbSK00CviyaiNEroxpr
 20rSMCfhj16p8MN54UxxqputI/Jh9wTnCvYiB9QycOMGGin7OWilVIey7MrdzQIatWY0
 r2EYnMLdhOSAB3byy/Ng0F9JMPWAYaiH5VKO8OeykrVRGxEFlRBblT51VA1T3qwmdQ/3
 gmRSVUyj+aJODFL9u531uhsLq6gROf+OOiT2B15lFaWpnglKOlef0jFst35CezhDazsU
 ULNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=5EJb+QA+QlNkg6psQhVkZFgAjPM8l4HdiO80d945so0=;
 b=VfeX82qZdZs1BNVftGpng7ZL7iUywM2/mE2VkKlAOZSPK/Z+Kqd4U/X56HzpzKHZkP
 1GyJt3mJnKTtAhBZpiINH5kJebaC+82KXHmfRAUwNO5IGyqkOZkbdBaZadbF6KKiiZ2+
 xNQj9pSG6lAGESAWw1pRa6KRRaYyzc3CJSt9QyN2wJ0PquXmXafZaQkv12G4Ov5rGR50
 5lgZ7X4g8Kk37uPTH68mipTuIm7MCuc4Le5RQ0IMAW95np9PTbhDvzUutqoDjM281uP4
 e0CbSds/pT2g1tHU9Fg4Xih6EyErfWNOKRd3DK/TuT1tZt82F7FiMbilHXMsPJc+gNh9
 mJIg==
X-Gm-Message-State: AGi0PuYEqQBjcjyfX8qqW5ra037sRP7rOahqa3Fi+NKh521ZfdO88nd8
 IjjdeRQTL/Kmx/6YWsz2sDM+NuFZwh0=
X-Google-Smtp-Source: APiQypI8QmNdF6XF2/jYXnMOvZiof285yEIJIZMYxN+FoP8W6rDwbeXoM88ALsGFkccleebJJR6UDQ==
X-Received: by 2002:aed:3fab:: with SMTP id s40mr1510566qth.140.1587601533065; 
 Wed, 22 Apr 2020 17:25:33 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id j90sm669088qte.20.2020.04.22.17.25.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Apr 2020 17:25:32 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 2/2] golang/xenlight: stop tracking generated files
Date: Wed, 22 Apr 2020 20:25:26 -0400
Message-Id: <f4fd2508a9cbceec2d1b8b480d4e4a15422d67d2.1587599095.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587599094.git.rosbrookn@ainfosec.com>
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1587599094.git.rosbrookn@ainfosec.com>
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Nick Rosbrook <rosbrookn@ainfosec.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The generated go files were tracked temporarily while the initial
implementation of gengotypes.py was in progress. They can now be removed
and ignored by git and hg.

While here, make sure generated files are removed by make clean.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 .gitignore                           |    3 +
 .hgignore                            |    2 +
 tools/golang/xenlight/Makefile       |    1 +
 tools/golang/xenlight/helpers.gen.go | 4658 --------------------------
 tools/golang/xenlight/types.gen.go   | 1225 -------
 5 files changed, 6 insertions(+), 5883 deletions(-)
 delete mode 100644 tools/golang/xenlight/helpers.gen.go
 delete mode 100644 tools/golang/xenlight/types.gen.go

diff --git a/.gitignore b/.gitignore
index 4ca679ddbc..93c11019a2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -405,6 +405,9 @@ tools/xenstore/xenstore-watch
 tools/xl/_paths.h
 tools/xl/xl
 
+tools/golang/src
+tools/golang/*/*.gen.go
+
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
 docs/figs/*.png
diff --git a/.hgignore b/.hgignore
index 2d41670632..2ec52982e1 100644
--- a/.hgignore
+++ b/.hgignore
@@ -282,6 +282,8 @@
 ^tools/ocaml/test/xtl$
 ^tools/ocaml/test/send_debug_keys$
 ^tools/ocaml/test/list_domains$
+^tools/golang/src$
+^tools/golang/.*/.*\.gen\.go$
 ^tools/autom4te\.cache$
 ^tools/config\.h$
 ^tools/config\.log$
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
index 753132306a..144c133ced 100644
--- a/tools/golang/xenlight/Makefile
+++ b/tools/golang/xenlight/Makefile
@@ -49,6 +49,7 @@ install: build
 clean:
 	$(RM) -r $(XEN_GOPATH)$(GOXL_PKG_DIR)
 	$(RM) $(XEN_GOPATH)/pkg/*/$(XEN_GOCODE_URL)/xenlight.a
+	$(RM) *.gen.go
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
deleted file mode 100644
index 344ce9a461..0000000000
--- a/tools/golang/xenlight/helpers.gen.go
+++ /dev/null
@@ -1,4658 +0,0 @@
-// DO NOT EDIT.
-//
-// This file is generated by:
-// gengotypes.py ../../libxl/libxl_types.idl
-//
-package xenlight
-
-import (
-	"errors"
-	"fmt"
-	"unsafe"
-)
-
-/*
-#cgo LDFLAGS: -lxenlight
-#include <stdlib.h>
-#include <libxl.h>
-
-typedef typeof(((struct libxl_channelinfo *)NULL)->u.pty)libxl_channelinfo_connection_union_pty;
-typedef typeof(((struct libxl_domain_build_info *)NULL)->u.hvm)libxl_domain_build_info_type_union_hvm;
-typedef typeof(((struct libxl_domain_build_info *)NULL)->u.pv)libxl_domain_build_info_type_union_pv;
-typedef typeof(((struct libxl_domain_build_info *)NULL)->u.pvh)libxl_domain_build_info_type_union_pvh;
-typedef typeof(((struct libxl_device_usbdev *)NULL)->u.hostdev)libxl_device_usbdev_type_union_hostdev;
-typedef typeof(((struct libxl_device_channel *)NULL)->u.socket)libxl_device_channel_connection_union_socket;
-typedef typeof(((struct libxl_event *)NULL)->u.domain_shutdown)libxl_event_type_union_domain_shutdown;
-typedef typeof(((struct libxl_event *)NULL)->u.disk_eject)libxl_event_type_union_disk_eject;
-typedef typeof(((struct libxl_event *)NULL)->u.operation_complete)libxl_event_type_union_operation_complete;
-typedef typeof(((struct libxl_psr_hw_info *)NULL)->u.cat)libxl_psr_hw_info_type_union_cat;
-typedef typeof(((struct libxl_psr_hw_info *)NULL)->u.mba)libxl_psr_hw_info_type_union_mba;
-*/
-import "C"
-
-// NewIoportRange returns an instance of IoportRange initialized with defaults.
-func NewIoportRange() (*IoportRange, error) {
-	var (
-		x  IoportRange
-		xc C.libxl_ioport_range
-	)
-
-	C.libxl_ioport_range_init(&xc)
-	defer C.libxl_ioport_range_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *IoportRange) fromC(xc *C.libxl_ioport_range) error {
-	x.First = uint32(xc.first)
-	x.Number = uint32(xc.number)
-
-	return nil
-}
-
-func (x *IoportRange) toC(xc *C.libxl_ioport_range) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_ioport_range_dispose(xc)
-		}
-	}()
-
-	xc.first = C.uint32_t(x.First)
-	xc.number = C.uint32_t(x.Number)
-
-	return nil
-}
-
-// NewIomemRange returns an instance of IomemRange initialized with defaults.
-func NewIomemRange() (*IomemRange, error) {
-	var (
-		x  IomemRange
-		xc C.libxl_iomem_range
-	)
-
-	C.libxl_iomem_range_init(&xc)
-	defer C.libxl_iomem_range_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *IomemRange) fromC(xc *C.libxl_iomem_range) error {
-	x.Start = uint64(xc.start)
-	x.Number = uint64(xc.number)
-	x.Gfn = uint64(xc.gfn)
-
-	return nil
-}
-
-func (x *IomemRange) toC(xc *C.libxl_iomem_range) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_iomem_range_dispose(xc)
-		}
-	}()
-
-	xc.start = C.uint64_t(x.Start)
-	xc.number = C.uint64_t(x.Number)
-	xc.gfn = C.uint64_t(x.Gfn)
-
-	return nil
-}
-
-// NewVgaInterfaceInfo returns an instance of VgaInterfaceInfo initialized with defaults.
-func NewVgaInterfaceInfo() (*VgaInterfaceInfo, error) {
-	var (
-		x  VgaInterfaceInfo
-		xc C.libxl_vga_interface_info
-	)
-
-	C.libxl_vga_interface_info_init(&xc)
-	defer C.libxl_vga_interface_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VgaInterfaceInfo) fromC(xc *C.libxl_vga_interface_info) error {
-	x.Kind = VgaInterfaceType(xc.kind)
-
-	return nil
-}
-
-func (x *VgaInterfaceInfo) toC(xc *C.libxl_vga_interface_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vga_interface_info_dispose(xc)
-		}
-	}()
-
-	xc.kind = C.libxl_vga_interface_type(x.Kind)
-
-	return nil
-}
-
-// NewVncInfo returns an instance of VncInfo initialized with defaults.
-func NewVncInfo() (*VncInfo, error) {
-	var (
-		x  VncInfo
-		xc C.libxl_vnc_info
-	)
-
-	C.libxl_vnc_info_init(&xc)
-	defer C.libxl_vnc_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VncInfo) fromC(xc *C.libxl_vnc_info) error {
-	if err := x.Enable.fromC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	x.Listen = C.GoString(xc.listen)
-	x.Passwd = C.GoString(xc.passwd)
-	x.Display = int(xc.display)
-	if err := x.Findunused.fromC(&xc.findunused); err != nil {
-		return fmt.Errorf("converting field Findunused: %v", err)
-	}
-
-	return nil
-}
-
-func (x *VncInfo) toC(xc *C.libxl_vnc_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vnc_info_dispose(xc)
-		}
-	}()
-
-	if err := x.Enable.toC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	if x.Listen != "" {
-		xc.listen = C.CString(x.Listen)
-	}
-	if x.Passwd != "" {
-		xc.passwd = C.CString(x.Passwd)
-	}
-	xc.display = C.int(x.Display)
-	if err := x.Findunused.toC(&xc.findunused); err != nil {
-		return fmt.Errorf("converting field Findunused: %v", err)
-	}
-
-	return nil
-}
-
-// NewSpiceInfo returns an instance of SpiceInfo initialized with defaults.
-func NewSpiceInfo() (*SpiceInfo, error) {
-	var (
-		x  SpiceInfo
-		xc C.libxl_spice_info
-	)
-
-	C.libxl_spice_info_init(&xc)
-	defer C.libxl_spice_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SpiceInfo) fromC(xc *C.libxl_spice_info) error {
-	if err := x.Enable.fromC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	x.Port = int(xc.port)
-	x.TlsPort = int(xc.tls_port)
-	x.Host = C.GoString(xc.host)
-	if err := x.DisableTicketing.fromC(&xc.disable_ticketing); err != nil {
-		return fmt.Errorf("converting field DisableTicketing: %v", err)
-	}
-	x.Passwd = C.GoString(xc.passwd)
-	if err := x.AgentMouse.fromC(&xc.agent_mouse); err != nil {
-		return fmt.Errorf("converting field AgentMouse: %v", err)
-	}
-	if err := x.Vdagent.fromC(&xc.vdagent); err != nil {
-		return fmt.Errorf("converting field Vdagent: %v", err)
-	}
-	if err := x.ClipboardSharing.fromC(&xc.clipboard_sharing); err != nil {
-		return fmt.Errorf("converting field ClipboardSharing: %v", err)
-	}
-	x.Usbredirection = int(xc.usbredirection)
-	x.ImageCompression = C.GoString(xc.image_compression)
-	x.StreamingVideo = C.GoString(xc.streaming_video)
-
-	return nil
-}
-
-func (x *SpiceInfo) toC(xc *C.libxl_spice_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_spice_info_dispose(xc)
-		}
-	}()
-
-	if err := x.Enable.toC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	xc.port = C.int(x.Port)
-	xc.tls_port = C.int(x.TlsPort)
-	if x.Host != "" {
-		xc.host = C.CString(x.Host)
-	}
-	if err := x.DisableTicketing.toC(&xc.disable_ticketing); err != nil {
-		return fmt.Errorf("converting field DisableTicketing: %v", err)
-	}
-	if x.Passwd != "" {
-		xc.passwd = C.CString(x.Passwd)
-	}
-	if err := x.AgentMouse.toC(&xc.agent_mouse); err != nil {
-		return fmt.Errorf("converting field AgentMouse: %v", err)
-	}
-	if err := x.Vdagent.toC(&xc.vdagent); err != nil {
-		return fmt.Errorf("converting field Vdagent: %v", err)
-	}
-	if err := x.ClipboardSharing.toC(&xc.clipboard_sharing); err != nil {
-		return fmt.Errorf("converting field ClipboardSharing: %v", err)
-	}
-	xc.usbredirection = C.int(x.Usbredirection)
-	if x.ImageCompression != "" {
-		xc.image_compression = C.CString(x.ImageCompression)
-	}
-	if x.StreamingVideo != "" {
-		xc.streaming_video = C.CString(x.StreamingVideo)
-	}
-
-	return nil
-}
-
-// NewSdlInfo returns an instance of SdlInfo initialized with defaults.
-func NewSdlInfo() (*SdlInfo, error) {
-	var (
-		x  SdlInfo
-		xc C.libxl_sdl_info
-	)
-
-	C.libxl_sdl_info_init(&xc)
-	defer C.libxl_sdl_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SdlInfo) fromC(xc *C.libxl_sdl_info) error {
-	if err := x.Enable.fromC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	if err := x.Opengl.fromC(&xc.opengl); err != nil {
-		return fmt.Errorf("converting field Opengl: %v", err)
-	}
-	x.Display = C.GoString(xc.display)
-	x.Xauthority = C.GoString(xc.xauthority)
-
-	return nil
-}
-
-func (x *SdlInfo) toC(xc *C.libxl_sdl_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_sdl_info_dispose(xc)
-		}
-	}()
-
-	if err := x.Enable.toC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	if err := x.Opengl.toC(&xc.opengl); err != nil {
-		return fmt.Errorf("converting field Opengl: %v", err)
-	}
-	if x.Display != "" {
-		xc.display = C.CString(x.Display)
-	}
-	if x.Xauthority != "" {
-		xc.xauthority = C.CString(x.Xauthority)
-	}
-
-	return nil
-}
-
-// NewDominfo returns an instance of Dominfo initialized with defaults.
-func NewDominfo() (*Dominfo, error) {
-	var (
-		x  Dominfo
-		xc C.libxl_dominfo
-	)
-
-	C.libxl_dominfo_init(&xc)
-	defer C.libxl_dominfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Dominfo) fromC(xc *C.libxl_dominfo) error {
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	x.Domid = Domid(xc.domid)
-	x.Ssidref = uint32(xc.ssidref)
-	x.SsidLabel = C.GoString(xc.ssid_label)
-	x.Running = bool(xc.running)
-	x.Blocked = bool(xc.blocked)
-	x.Paused = bool(xc.paused)
-	x.Shutdown = bool(xc.shutdown)
-	x.Dying = bool(xc.dying)
-	x.NeverStop = bool(xc.never_stop)
-	x.ShutdownReason = ShutdownReason(xc.shutdown_reason)
-	x.OutstandingMemkb = uint64(xc.outstanding_memkb)
-	x.CurrentMemkb = uint64(xc.current_memkb)
-	x.SharedMemkb = uint64(xc.shared_memkb)
-	x.PagedMemkb = uint64(xc.paged_memkb)
-	x.MaxMemkb = uint64(xc.max_memkb)
-	x.CpuTime = uint64(xc.cpu_time)
-	x.VcpuMaxId = uint32(xc.vcpu_max_id)
-	x.VcpuOnline = uint32(xc.vcpu_online)
-	x.Cpupool = uint32(xc.cpupool)
-	x.DomainType = DomainType(xc.domain_type)
-
-	return nil
-}
-
-func (x *Dominfo) toC(xc *C.libxl_dominfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_dominfo_dispose(xc)
-		}
-	}()
-
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	xc.domid = C.libxl_domid(x.Domid)
-	xc.ssidref = C.uint32_t(x.Ssidref)
-	if x.SsidLabel != "" {
-		xc.ssid_label = C.CString(x.SsidLabel)
-	}
-	xc.running = C.bool(x.Running)
-	xc.blocked = C.bool(x.Blocked)
-	xc.paused = C.bool(x.Paused)
-	xc.shutdown = C.bool(x.Shutdown)
-	xc.dying = C.bool(x.Dying)
-	xc.never_stop = C.bool(x.NeverStop)
-	xc.shutdown_reason = C.libxl_shutdown_reason(x.ShutdownReason)
-	xc.outstanding_memkb = C.uint64_t(x.OutstandingMemkb)
-	xc.current_memkb = C.uint64_t(x.CurrentMemkb)
-	xc.shared_memkb = C.uint64_t(x.SharedMemkb)
-	xc.paged_memkb = C.uint64_t(x.PagedMemkb)
-	xc.max_memkb = C.uint64_t(x.MaxMemkb)
-	xc.cpu_time = C.uint64_t(x.CpuTime)
-	xc.vcpu_max_id = C.uint32_t(x.VcpuMaxId)
-	xc.vcpu_online = C.uint32_t(x.VcpuOnline)
-	xc.cpupool = C.uint32_t(x.Cpupool)
-	xc.domain_type = C.libxl_domain_type(x.DomainType)
-
-	return nil
-}
-
-// NewCpupoolinfo returns an instance of Cpupoolinfo initialized with defaults.
-func NewCpupoolinfo() (*Cpupoolinfo, error) {
-	var (
-		x  Cpupoolinfo
-		xc C.libxl_cpupoolinfo
-	)
-
-	C.libxl_cpupoolinfo_init(&xc)
-	defer C.libxl_cpupoolinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Cpupoolinfo) fromC(xc *C.libxl_cpupoolinfo) error {
-	x.Poolid = uint32(xc.poolid)
-	x.PoolName = C.GoString(xc.pool_name)
-	x.Sched = Scheduler(xc.sched)
-	x.NDom = uint32(xc.n_dom)
-	if err := x.Cpumap.fromC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-
-	return nil
-}
-
-func (x *Cpupoolinfo) toC(xc *C.libxl_cpupoolinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_cpupoolinfo_dispose(xc)
-		}
-	}()
-
-	xc.poolid = C.uint32_t(x.Poolid)
-	if x.PoolName != "" {
-		xc.pool_name = C.CString(x.PoolName)
-	}
-	xc.sched = C.libxl_scheduler(x.Sched)
-	xc.n_dom = C.uint32_t(x.NDom)
-	if err := x.Cpumap.toC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-
-	return nil
-}
-
-// NewChannelinfo returns an instance of Channelinfo initialized with defaults.
-func NewChannelinfo(connection ChannelConnection) (*Channelinfo, error) {
-	var (
-		x  Channelinfo
-		xc C.libxl_channelinfo
-	)
-
-	C.libxl_channelinfo_init(&xc)
-	C.libxl_channelinfo_init_connection(&xc, C.libxl_channel_connection(connection))
-	defer C.libxl_channelinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Channelinfo) fromC(xc *C.libxl_channelinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.Rref = int(xc.rref)
-	x.Connection = ChannelConnection(xc.connection)
-	switch x.Connection {
-	case ChannelConnectionUnknown:
-		x.ConnectionUnion = nil
-	case ChannelConnectionPty:
-		var connectionPty ChannelinfoConnectionUnionPty
-		if err := connectionPty.fromC(xc); err != nil {
-			return fmt.Errorf("converting field connectionPty: %v", err)
-		}
-		x.ConnectionUnion = connectionPty
-	case ChannelConnectionSocket:
-		x.ConnectionUnion = nil
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Connection)
-	}
-
-	return nil
-}
-
-func (x *ChannelinfoConnectionUnionPty) fromC(xc *C.libxl_channelinfo) error {
-	if ChannelConnection(xc.connection) != ChannelConnectionPty {
-		return errors.New("expected union key ChannelConnectionPty")
-	}
-
-	tmp := (*C.libxl_channelinfo_connection_union_pty)(unsafe.Pointer(&xc.u[0]))
-	x.Path = C.GoString(tmp.path)
-	return nil
-}
-
-func (x *Channelinfo) toC(xc *C.libxl_channelinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_channelinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref = C.int(x.Rref)
-	xc.connection = C.libxl_channel_connection(x.Connection)
-	switch x.Connection {
-	case ChannelConnectionUnknown:
-		break
-	case ChannelConnectionPty:
-		tmp, ok := x.ConnectionUnion.(ChannelinfoConnectionUnionPty)
-		if !ok {
-			return errors.New("wrong type for union key connection")
-		}
-		var pty C.libxl_channelinfo_connection_union_pty
-		if tmp.Path != "" {
-			pty.path = C.CString(tmp.Path)
-		}
-		ptyBytes := C.GoBytes(unsafe.Pointer(&pty), C.sizeof_libxl_channelinfo_connection_union_pty)
-		copy(xc.u[:], ptyBytes)
-	case ChannelConnectionSocket:
-		break
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Connection)
-	}
-
-	return nil
-}
-
-// NewVminfo returns an instance of Vminfo initialized with defaults.
-func NewVminfo() (*Vminfo, error) {
-	var (
-		x  Vminfo
-		xc C.libxl_vminfo
-	)
-
-	C.libxl_vminfo_init(&xc)
-	defer C.libxl_vminfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vminfo) fromC(xc *C.libxl_vminfo) error {
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	x.Domid = Domid(xc.domid)
-
-	return nil
-}
-
-func (x *Vminfo) toC(xc *C.libxl_vminfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vminfo_dispose(xc)
-		}
-	}()
-
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	xc.domid = C.libxl_domid(x.Domid)
-
-	return nil
-}
-
-// NewVersionInfo returns an instance of VersionInfo initialized with defaults.
-func NewVersionInfo() (*VersionInfo, error) {
-	var (
-		x  VersionInfo
-		xc C.libxl_version_info
-	)
-
-	C.libxl_version_info_init(&xc)
-	defer C.libxl_version_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VersionInfo) fromC(xc *C.libxl_version_info) error {
-	x.XenVersionMajor = int(xc.xen_version_major)
-	x.XenVersionMinor = int(xc.xen_version_minor)
-	x.XenVersionExtra = C.GoString(xc.xen_version_extra)
-	x.Compiler = C.GoString(xc.compiler)
-	x.CompileBy = C.GoString(xc.compile_by)
-	x.CompileDomain = C.GoString(xc.compile_domain)
-	x.CompileDate = C.GoString(xc.compile_date)
-	x.Capabilities = C.GoString(xc.capabilities)
-	x.Changeset = C.GoString(xc.changeset)
-	x.VirtStart = uint64(xc.virt_start)
-	x.Pagesize = int(xc.pagesize)
-	x.Commandline = C.GoString(xc.commandline)
-	x.BuildId = C.GoString(xc.build_id)
-
-	return nil
-}
-
-func (x *VersionInfo) toC(xc *C.libxl_version_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_version_info_dispose(xc)
-		}
-	}()
-
-	xc.xen_version_major = C.int(x.XenVersionMajor)
-	xc.xen_version_minor = C.int(x.XenVersionMinor)
-	if x.XenVersionExtra != "" {
-		xc.xen_version_extra = C.CString(x.XenVersionExtra)
-	}
-	if x.Compiler != "" {
-		xc.compiler = C.CString(x.Compiler)
-	}
-	if x.CompileBy != "" {
-		xc.compile_by = C.CString(x.CompileBy)
-	}
-	if x.CompileDomain != "" {
-		xc.compile_domain = C.CString(x.CompileDomain)
-	}
-	if x.CompileDate != "" {
-		xc.compile_date = C.CString(x.CompileDate)
-	}
-	if x.Capabilities != "" {
-		xc.capabilities = C.CString(x.Capabilities)
-	}
-	if x.Changeset != "" {
-		xc.changeset = C.CString(x.Changeset)
-	}
-	xc.virt_start = C.uint64_t(x.VirtStart)
-	xc.pagesize = C.int(x.Pagesize)
-	if x.Commandline != "" {
-		xc.commandline = C.CString(x.Commandline)
-	}
-	if x.BuildId != "" {
-		xc.build_id = C.CString(x.BuildId)
-	}
-
-	return nil
-}
-
-// NewDomainCreateInfo returns an instance of DomainCreateInfo initialized with defaults.
-func NewDomainCreateInfo() (*DomainCreateInfo, error) {
-	var (
-		x  DomainCreateInfo
-		xc C.libxl_domain_create_info
-	)
-
-	C.libxl_domain_create_info_init(&xc)
-	defer C.libxl_domain_create_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainCreateInfo) fromC(xc *C.libxl_domain_create_info) error {
-	x.Type = DomainType(xc._type)
-	if err := x.Hap.fromC(&xc.hap); err != nil {
-		return fmt.Errorf("converting field Hap: %v", err)
-	}
-	if err := x.Oos.fromC(&xc.oos); err != nil {
-		return fmt.Errorf("converting field Oos: %v", err)
-	}
-	x.Ssidref = uint32(xc.ssidref)
-	x.SsidLabel = C.GoString(xc.ssid_label)
-	x.Name = C.GoString(xc.name)
-	x.Domid = Domid(xc.domid)
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	if err := x.Xsdata.fromC(&xc.xsdata); err != nil {
-		return fmt.Errorf("converting field Xsdata: %v", err)
-	}
-	if err := x.Platformdata.fromC(&xc.platformdata); err != nil {
-		return fmt.Errorf("converting field Platformdata: %v", err)
-	}
-	x.Poolid = uint32(xc.poolid)
-	x.PoolName = C.GoString(xc.pool_name)
-	if err := x.RunHotplugScripts.fromC(&xc.run_hotplug_scripts); err != nil {
-		return fmt.Errorf("converting field RunHotplugScripts: %v", err)
-	}
-	if err := x.DriverDomain.fromC(&xc.driver_domain); err != nil {
-		return fmt.Errorf("converting field DriverDomain: %v", err)
-	}
-	x.Passthrough = Passthrough(xc.passthrough)
-
-	return nil
-}
-
-func (x *DomainCreateInfo) toC(xc *C.libxl_domain_create_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_create_info_dispose(xc)
-		}
-	}()
-
-	xc._type = C.libxl_domain_type(x.Type)
-	if err := x.Hap.toC(&xc.hap); err != nil {
-		return fmt.Errorf("converting field Hap: %v", err)
-	}
-	if err := x.Oos.toC(&xc.oos); err != nil {
-		return fmt.Errorf("converting field Oos: %v", err)
-	}
-	xc.ssidref = C.uint32_t(x.Ssidref)
-	if x.SsidLabel != "" {
-		xc.ssid_label = C.CString(x.SsidLabel)
-	}
-	if x.Name != "" {
-		xc.name = C.CString(x.Name)
-	}
-	xc.domid = C.libxl_domid(x.Domid)
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	if err := x.Xsdata.toC(&xc.xsdata); err != nil {
-		return fmt.Errorf("converting field Xsdata: %v", err)
-	}
-	if err := x.Platformdata.toC(&xc.platformdata); err != nil {
-		return fmt.Errorf("converting field Platformdata: %v", err)
-	}
-	xc.poolid = C.uint32_t(x.Poolid)
-	if x.PoolName != "" {
-		xc.pool_name = C.CString(x.PoolName)
-	}
-	if err := x.RunHotplugScripts.toC(&xc.run_hotplug_scripts); err != nil {
-		return fmt.Errorf("converting field RunHotplugScripts: %v", err)
-	}
-	if err := x.DriverDomain.toC(&xc.driver_domain); err != nil {
-		return fmt.Errorf("converting field DriverDomain: %v", err)
-	}
-	xc.passthrough = C.libxl_passthrough(x.Passthrough)
-
-	return nil
-}
-
-// NewDomainRestoreParams returns an instance of DomainRestoreParams initialized with defaults.
-func NewDomainRestoreParams() (*DomainRestoreParams, error) {
-	var (
-		x  DomainRestoreParams
-		xc C.libxl_domain_restore_params
-	)
-
-	C.libxl_domain_restore_params_init(&xc)
-	defer C.libxl_domain_restore_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainRestoreParams) fromC(xc *C.libxl_domain_restore_params) error {
-	x.CheckpointedStream = int(xc.checkpointed_stream)
-	x.StreamVersion = uint32(xc.stream_version)
-	x.ColoProxyScript = C.GoString(xc.colo_proxy_script)
-	if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy); err != nil {
-		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
-	}
-
-	return nil
-}
-
-func (x *DomainRestoreParams) toC(xc *C.libxl_domain_restore_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_restore_params_dispose(xc)
-		}
-	}()
-
-	xc.checkpointed_stream = C.int(x.CheckpointedStream)
-	xc.stream_version = C.uint32_t(x.StreamVersion)
-	if x.ColoProxyScript != "" {
-		xc.colo_proxy_script = C.CString(x.ColoProxyScript)
-	}
-	if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil {
-		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
-	}
-
-	return nil
-}
-
-// NewSchedParams returns an instance of SchedParams initialized with defaults.
-func NewSchedParams() (*SchedParams, error) {
-	var (
-		x  SchedParams
-		xc C.libxl_sched_params
-	)
-
-	C.libxl_sched_params_init(&xc)
-	defer C.libxl_sched_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SchedParams) fromC(xc *C.libxl_sched_params) error {
-	x.Vcpuid = int(xc.vcpuid)
-	x.Weight = int(xc.weight)
-	x.Cap = int(xc.cap)
-	x.Period = int(xc.period)
-	x.Extratime = int(xc.extratime)
-	x.Budget = int(xc.budget)
-
-	return nil
-}
-
-func (x *SchedParams) toC(xc *C.libxl_sched_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_sched_params_dispose(xc)
-		}
-	}()
-
-	xc.vcpuid = C.int(x.Vcpuid)
-	xc.weight = C.int(x.Weight)
-	xc.cap = C.int(x.Cap)
-	xc.period = C.int(x.Period)
-	xc.extratime = C.int(x.Extratime)
-	xc.budget = C.int(x.Budget)
-
-	return nil
-}
-
-// NewVcpuSchedParams returns an instance of VcpuSchedParams initialized with defaults.
-func NewVcpuSchedParams() (*VcpuSchedParams, error) {
-	var (
-		x  VcpuSchedParams
-		xc C.libxl_vcpu_sched_params
-	)
-
-	C.libxl_vcpu_sched_params_init(&xc)
-	defer C.libxl_vcpu_sched_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VcpuSchedParams) fromC(xc *C.libxl_vcpu_sched_params) error {
-	x.Sched = Scheduler(xc.sched)
-	numVcpus := int(xc.num_vcpus)
-	cVcpus := (*[1 << 28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:numVcpus:numVcpus]
-	x.Vcpus = make([]SchedParams, numVcpus)
-	for i, v := range cVcpus {
-		if err := x.Vcpus[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Vcpus: %v", err)
-		}
-	}
-
-	return nil
-}
-
-func (x *VcpuSchedParams) toC(xc *C.libxl_vcpu_sched_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vcpu_sched_params_dispose(xc)
-		}
-	}()
-
-	xc.sched = C.libxl_scheduler(x.Sched)
-	if numVcpus := len(x.Vcpus); numVcpus > 0 {
-		xc.vcpus = (*C.libxl_sched_params)(C.malloc(C.ulong(numVcpus) * C.sizeof_libxl_sched_params))
-		xc.num_vcpus = C.int(numVcpus)
-		cVcpus := (*[1 << 28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:numVcpus:numVcpus]
-		for i, v := range x.Vcpus {
-			if err := v.toC(&cVcpus[i]); err != nil {
-				return fmt.Errorf("converting field Vcpus: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewDomainSchedParams returns an instance of DomainSchedParams initialized with defaults.
-func NewDomainSchedParams() (*DomainSchedParams, error) {
-	var (
-		x  DomainSchedParams
-		xc C.libxl_domain_sched_params
-	)
-
-	C.libxl_domain_sched_params_init(&xc)
-	defer C.libxl_domain_sched_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainSchedParams) fromC(xc *C.libxl_domain_sched_params) error {
-	x.Sched = Scheduler(xc.sched)
-	x.Weight = int(xc.weight)
-	x.Cap = int(xc.cap)
-	x.Period = int(xc.period)
-	x.Budget = int(xc.budget)
-	x.Extratime = int(xc.extratime)
-	x.Slice = int(xc.slice)
-	x.Latency = int(xc.latency)
-
-	return nil
-}
-
-func (x *DomainSchedParams) toC(xc *C.libxl_domain_sched_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_sched_params_dispose(xc)
-		}
-	}()
-
-	xc.sched = C.libxl_scheduler(x.Sched)
-	xc.weight = C.int(x.Weight)
-	xc.cap = C.int(x.Cap)
-	xc.period = C.int(x.Period)
-	xc.budget = C.int(x.Budget)
-	xc.extratime = C.int(x.Extratime)
-	xc.slice = C.int(x.Slice)
-	xc.latency = C.int(x.Latency)
-
-	return nil
-}
-
-// NewVnodeInfo returns an instance of VnodeInfo initialized with defaults.
-func NewVnodeInfo() (*VnodeInfo, error) {
-	var (
-		x  VnodeInfo
-		xc C.libxl_vnode_info
-	)
-
-	C.libxl_vnode_info_init(&xc)
-	defer C.libxl_vnode_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VnodeInfo) fromC(xc *C.libxl_vnode_info) error {
-	x.Memkb = uint64(xc.memkb)
-	numDistances := int(xc.num_distances)
-	cDistances := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.distances))[:numDistances:numDistances]
-	x.Distances = make([]uint32, numDistances)
-	for i, v := range cDistances {
-		x.Distances[i] = uint32(v)
-	}
-	x.Pnode = uint32(xc.pnode)
-	if err := x.Vcpus.fromC(&xc.vcpus); err != nil {
-		return fmt.Errorf("converting field Vcpus: %v", err)
-	}
-
-	return nil
-}
-
-func (x *VnodeInfo) toC(xc *C.libxl_vnode_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vnode_info_dispose(xc)
-		}
-	}()
-
-	xc.memkb = C.uint64_t(x.Memkb)
-	if numDistances := len(x.Distances); numDistances > 0 {
-		xc.distances = (*C.uint32_t)(C.malloc(C.size_t(numDistances * numDistances)))
-		xc.num_distances = C.int(numDistances)
-		cDistances := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.distances))[:numDistances:numDistances]
-		for i, v := range x.Distances {
-			cDistances[i] = C.uint32_t(v)
-		}
-	}
-	xc.pnode = C.uint32_t(x.Pnode)
-	if err := x.Vcpus.toC(&xc.vcpus); err != nil {
-		return fmt.Errorf("converting field Vcpus: %v", err)
-	}
-
-	return nil
-}
-
-// NewRdmReserve returns an instance of RdmReserve initialized with defaults.
-func NewRdmReserve() (*RdmReserve, error) {
-	var (
-		x  RdmReserve
-		xc C.libxl_rdm_reserve
-	)
-
-	C.libxl_rdm_reserve_init(&xc)
-	defer C.libxl_rdm_reserve_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *RdmReserve) fromC(xc *C.libxl_rdm_reserve) error {
-	x.Strategy = RdmReserveStrategy(xc.strategy)
-	x.Policy = RdmReservePolicy(xc.policy)
-
-	return nil
-}
-
-func (x *RdmReserve) toC(xc *C.libxl_rdm_reserve) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_rdm_reserve_dispose(xc)
-		}
-	}()
-
-	xc.strategy = C.libxl_rdm_reserve_strategy(x.Strategy)
-	xc.policy = C.libxl_rdm_reserve_policy(x.Policy)
-
-	return nil
-}
-
-// NewDomainBuildInfo returns an instance of DomainBuildInfo initialized with defaults.
-func NewDomainBuildInfo(dtype DomainType) (*DomainBuildInfo, error) {
-	var (
-		x  DomainBuildInfo
-		xc C.libxl_domain_build_info
-	)
-
-	C.libxl_domain_build_info_init(&xc)
-	C.libxl_domain_build_info_init_type(&xc, C.libxl_domain_type(dtype))
-	defer C.libxl_domain_build_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainBuildInfo) fromC(xc *C.libxl_domain_build_info) error {
-	x.MaxVcpus = int(xc.max_vcpus)
-	if err := x.AvailVcpus.fromC(&xc.avail_vcpus); err != nil {
-		return fmt.Errorf("converting field AvailVcpus: %v", err)
-	}
-	if err := x.Cpumap.fromC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-	if err := x.Nodemap.fromC(&xc.nodemap); err != nil {
-		return fmt.Errorf("converting field Nodemap: %v", err)
-	}
-	numVcpuHardAffinity := int(xc.num_vcpu_hard_affinity)
-	cVcpuHardAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:numVcpuHardAffinity:numVcpuHardAffinity]
-	x.VcpuHardAffinity = make([]Bitmap, numVcpuHardAffinity)
-	for i, v := range cVcpuHardAffinity {
-		if err := x.VcpuHardAffinity[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field VcpuHardAffinity: %v", err)
-		}
-	}
-	numVcpuSoftAffinity := int(xc.num_vcpu_soft_affinity)
-	cVcpuSoftAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:numVcpuSoftAffinity:numVcpuSoftAffinity]
-	x.VcpuSoftAffinity = make([]Bitmap, numVcpuSoftAffinity)
-	for i, v := range cVcpuSoftAffinity {
-		if err := x.VcpuSoftAffinity[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field VcpuSoftAffinity: %v", err)
-		}
-	}
-	if err := x.NumaPlacement.fromC(&xc.numa_placement); err != nil {
-		return fmt.Errorf("converting field NumaPlacement: %v", err)
-	}
-	x.TscMode = TscMode(xc.tsc_mode)
-	x.MaxMemkb = uint64(xc.max_memkb)
-	x.TargetMemkb = uint64(xc.target_memkb)
-	x.VideoMemkb = uint64(xc.video_memkb)
-	x.ShadowMemkb = uint64(xc.shadow_memkb)
-	x.IommuMemkb = uint64(xc.iommu_memkb)
-	x.RtcTimeoffset = uint32(xc.rtc_timeoffset)
-	x.ExecSsidref = uint32(xc.exec_ssidref)
-	x.ExecSsidLabel = C.GoString(xc.exec_ssid_label)
-	if err := x.Localtime.fromC(&xc.localtime); err != nil {
-		return fmt.Errorf("converting field Localtime: %v", err)
-	}
-	if err := x.DisableMigrate.fromC(&xc.disable_migrate); err != nil {
-		return fmt.Errorf("converting field DisableMigrate: %v", err)
-	}
-	if err := x.Cpuid.fromC(&xc.cpuid); err != nil {
-		return fmt.Errorf("converting field Cpuid: %v", err)
-	}
-	x.BlkdevStart = C.GoString(xc.blkdev_start)
-	numVnumaNodes := int(xc.num_vnuma_nodes)
-	cVnumaNodes := (*[1 << 28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:numVnumaNodes:numVnumaNodes]
-	x.VnumaNodes = make([]VnodeInfo, numVnumaNodes)
-	for i, v := range cVnumaNodes {
-		if err := x.VnumaNodes[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field VnumaNodes: %v", err)
-		}
-	}
-	x.MaxGrantFrames = uint32(xc.max_grant_frames)
-	x.MaxMaptrackFrames = uint32(xc.max_maptrack_frames)
-	x.DeviceModelVersion = DeviceModelVersion(xc.device_model_version)
-	if err := x.DeviceModelStubdomain.fromC(&xc.device_model_stubdomain); err != nil {
-		return fmt.Errorf("converting field DeviceModelStubdomain: %v", err)
-	}
-	x.DeviceModel = C.GoString(xc.device_model)
-	x.DeviceModelSsidref = uint32(xc.device_model_ssidref)
-	x.DeviceModelSsidLabel = C.GoString(xc.device_model_ssid_label)
-	x.DeviceModelUser = C.GoString(xc.device_model_user)
-	if err := x.Extra.fromC(&xc.extra); err != nil {
-		return fmt.Errorf("converting field Extra: %v", err)
-	}
-	if err := x.ExtraPv.fromC(&xc.extra_pv); err != nil {
-		return fmt.Errorf("converting field ExtraPv: %v", err)
-	}
-	if err := x.ExtraHvm.fromC(&xc.extra_hvm); err != nil {
-		return fmt.Errorf("converting field ExtraHvm: %v", err)
-	}
-	if err := x.SchedParams.fromC(&xc.sched_params); err != nil {
-		return fmt.Errorf("converting field SchedParams: %v", err)
-	}
-	numIoports := int(xc.num_ioports)
-	cIoports := (*[1 << 28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:numIoports:numIoports]
-	x.Ioports = make([]IoportRange, numIoports)
-	for i, v := range cIoports {
-		if err := x.Ioports[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Ioports: %v", err)
-		}
-	}
-	numIrqs := int(xc.num_irqs)
-	cIrqs := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:numIrqs:numIrqs]
-	x.Irqs = make([]uint32, numIrqs)
-	for i, v := range cIrqs {
-		x.Irqs[i] = uint32(v)
-	}
-	numIomem := int(xc.num_iomem)
-	cIomem := (*[1 << 28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:numIomem:numIomem]
-	x.Iomem = make([]IomemRange, numIomem)
-	for i, v := range cIomem {
-		if err := x.Iomem[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Iomem: %v", err)
-		}
-	}
-	if err := x.ClaimMode.fromC(&xc.claim_mode); err != nil {
-		return fmt.Errorf("converting field ClaimMode: %v", err)
-	}
-	x.EventChannels = uint32(xc.event_channels)
-	x.Kernel = C.GoString(xc.kernel)
-	x.Cmdline = C.GoString(xc.cmdline)
-	x.Ramdisk = C.GoString(xc.ramdisk)
-	x.DeviceTree = C.GoString(xc.device_tree)
-	if err := x.Acpi.fromC(&xc.acpi); err != nil {
-		return fmt.Errorf("converting field Acpi: %v", err)
-	}
-	x.Bootloader = C.GoString(xc.bootloader)
-	if err := x.BootloaderArgs.fromC(&xc.bootloader_args); err != nil {
-		return fmt.Errorf("converting field BootloaderArgs: %v", err)
-	}
-	x.TimerMode = TimerMode(xc.timer_mode)
-	if err := x.NestedHvm.fromC(&xc.nested_hvm); err != nil {
-		return fmt.Errorf("converting field NestedHvm: %v", err)
-	}
-	if err := x.Apic.fromC(&xc.apic); err != nil {
-		return fmt.Errorf("converting field Apic: %v", err)
-	}
-	if err := x.DmRestrict.fromC(&xc.dm_restrict); err != nil {
-		return fmt.Errorf("converting field DmRestrict: %v", err)
-	}
-	x.Tee = TeeType(xc.tee)
-	x.Type = DomainType(xc._type)
-	switch x.Type {
-	case DomainTypeHvm:
-		var typeHvm DomainBuildInfoTypeUnionHvm
-		if err := typeHvm.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeHvm: %v", err)
-		}
-		x.TypeUnion = typeHvm
-	case DomainTypePv:
-		var typePv DomainBuildInfoTypeUnionPv
-		if err := typePv.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typePv: %v", err)
-		}
-		x.TypeUnion = typePv
-	case DomainTypePvh:
-		var typePvh DomainBuildInfoTypeUnionPvh
-		if err := typePvh.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typePvh: %v", err)
-		}
-		x.TypeUnion = typePvh
-	case DomainTypeInvalid:
-		x.TypeUnion = nil
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-	x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version)
-	x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart)
-	x.Altp2M = Altp2MMode(xc.altp2m)
-
-	return nil
-}
-
-func (x *DomainBuildInfoTypeUnionHvm) fromC(xc *C.libxl_domain_build_info) error {
-	if DomainType(xc._type) != DomainTypeHvm {
-		return errors.New("expected union key DomainTypeHvm")
-	}
-
-	tmp := (*C.libxl_domain_build_info_type_union_hvm)(unsafe.Pointer(&xc.u[0]))
-	x.Firmware = C.GoString(tmp.firmware)
-	x.Bios = BiosType(tmp.bios)
-	if err := x.Pae.fromC(&tmp.pae); err != nil {
-		return fmt.Errorf("converting field Pae: %v", err)
-	}
-	if err := x.Apic.fromC(&tmp.apic); err != nil {
-		return fmt.Errorf("converting field Apic: %v", err)
-	}
-	if err := x.Acpi.fromC(&tmp.acpi); err != nil {
-		return fmt.Errorf("converting field Acpi: %v", err)
-	}
-	if err := x.AcpiS3.fromC(&tmp.acpi_s3); err != nil {
-		return fmt.Errorf("converting field AcpiS3: %v", err)
-	}
-	if err := x.AcpiS4.fromC(&tmp.acpi_s4); err != nil {
-		return fmt.Errorf("converting field AcpiS4: %v", err)
-	}
-	if err := x.AcpiLaptopSlate.fromC(&tmp.acpi_laptop_slate); err != nil {
-		return fmt.Errorf("converting field AcpiLaptopSlate: %v", err)
-	}
-	if err := x.Nx.fromC(&tmp.nx); err != nil {
-		return fmt.Errorf("converting field Nx: %v", err)
-	}
-	if err := x.Viridian.fromC(&tmp.viridian); err != nil {
-		return fmt.Errorf("converting field Viridian: %v", err)
-	}
-	if err := x.ViridianEnable.fromC(&tmp.viridian_enable); err != nil {
-		return fmt.Errorf("converting field ViridianEnable: %v", err)
-	}
-	if err := x.ViridianDisable.fromC(&tmp.viridian_disable); err != nil {
-		return fmt.Errorf("converting field ViridianDisable: %v", err)
-	}
-	x.Timeoffset = C.GoString(tmp.timeoffset)
-	if err := x.Hpet.fromC(&tmp.hpet); err != nil {
-		return fmt.Errorf("converting field Hpet: %v", err)
-	}
-	if err := x.VptAlign.fromC(&tmp.vpt_align); err != nil {
-		return fmt.Errorf("converting field VptAlign: %v", err)
-	}
-	x.MmioHoleMemkb = uint64(tmp.mmio_hole_memkb)
-	x.TimerMode = TimerMode(tmp.timer_mode)
-	if err := x.NestedHvm.fromC(&tmp.nested_hvm); err != nil {
-		return fmt.Errorf("converting field NestedHvm: %v", err)
-	}
-	if err := x.Altp2M.fromC(&tmp.altp2m); err != nil {
-		return fmt.Errorf("converting field Altp2M: %v", err)
-	}
-	x.SystemFirmware = C.GoString(tmp.system_firmware)
-	x.SmbiosFirmware = C.GoString(tmp.smbios_firmware)
-	x.AcpiFirmware = C.GoString(tmp.acpi_firmware)
-	x.Hdtype = Hdtype(tmp.hdtype)
-	if err := x.Nographic.fromC(&tmp.nographic); err != nil {
-		return fmt.Errorf("converting field Nographic: %v", err)
-	}
-	if err := x.Vga.fromC(&tmp.vga); err != nil {
-		return fmt.Errorf("converting field Vga: %v", err)
-	}
-	if err := x.Vnc.fromC(&tmp.vnc); err != nil {
-		return fmt.Errorf("converting field Vnc: %v", err)
-	}
-	x.Keymap = C.GoString(tmp.keymap)
-	if err := x.Sdl.fromC(&tmp.sdl); err != nil {
-		return fmt.Errorf("converting field Sdl: %v", err)
-	}
-	if err := x.Spice.fromC(&tmp.spice); err != nil {
-		return fmt.Errorf("converting field Spice: %v", err)
-	}
-	if err := x.GfxPassthru.fromC(&tmp.gfx_passthru); err != nil {
-		return fmt.Errorf("converting field GfxPassthru: %v", err)
-	}
-	x.GfxPassthruKind = GfxPassthruKind(tmp.gfx_passthru_kind)
-	x.Serial = C.GoString(tmp.serial)
-	x.Boot = C.GoString(tmp.boot)
-	if err := x.Usb.fromC(&tmp.usb); err != nil {
-		return fmt.Errorf("converting field Usb: %v", err)
-	}
-	x.Usbversion = int(tmp.usbversion)
-	x.Usbdevice = C.GoString(tmp.usbdevice)
-	if err := x.VkbDevice.fromC(&tmp.vkb_device); err != nil {
-		return fmt.Errorf("converting field VkbDevice: %v", err)
-	}
-	x.Soundhw = C.GoString(tmp.soundhw)
-	if err := x.XenPlatformPci.fromC(&tmp.xen_platform_pci); err != nil {
-		return fmt.Errorf("converting field XenPlatformPci: %v", err)
-	}
-	if err := x.UsbdeviceList.fromC(&tmp.usbdevice_list); err != nil {
-		return fmt.Errorf("converting field UsbdeviceList: %v", err)
-	}
-	x.VendorDevice = VendorDevice(tmp.vendor_device)
-	if err := x.MsVmGenid.fromC(&tmp.ms_vm_genid); err != nil {
-		return fmt.Errorf("converting field MsVmGenid: %v", err)
-	}
-	if err := x.SerialList.fromC(&tmp.serial_list); err != nil {
-		return fmt.Errorf("converting field SerialList: %v", err)
-	}
-	if err := x.Rdm.fromC(&tmp.rdm); err != nil {
-		return fmt.Errorf("converting field Rdm: %v", err)
-	}
-	x.RdmMemBoundaryMemkb = uint64(tmp.rdm_mem_boundary_memkb)
-	x.McaCaps = uint64(tmp.mca_caps)
-	return nil
-}
-
-func (x *DomainBuildInfoTypeUnionPv) fromC(xc *C.libxl_domain_build_info) error {
-	if DomainType(xc._type) != DomainTypePv {
-		return errors.New("expected union key DomainTypePv")
-	}
-
-	tmp := (*C.libxl_domain_build_info_type_union_pv)(unsafe.Pointer(&xc.u[0]))
-	x.Kernel = C.GoString(tmp.kernel)
-	x.SlackMemkb = uint64(tmp.slack_memkb)
-	x.Bootloader = C.GoString(tmp.bootloader)
-	if err := x.BootloaderArgs.fromC(&tmp.bootloader_args); err != nil {
-		return fmt.Errorf("converting field BootloaderArgs: %v", err)
-	}
-	x.Cmdline = C.GoString(tmp.cmdline)
-	x.Ramdisk = C.GoString(tmp.ramdisk)
-	x.Features = C.GoString(tmp.features)
-	if err := x.E820Host.fromC(&tmp.e820_host); err != nil {
-		return fmt.Errorf("converting field E820Host: %v", err)
-	}
-	return nil
-}
-
-func (x *DomainBuildInfoTypeUnionPvh) fromC(xc *C.libxl_domain_build_info) error {
-	if DomainType(xc._type) != DomainTypePvh {
-		return errors.New("expected union key DomainTypePvh")
-	}
-
-	tmp := (*C.libxl_domain_build_info_type_union_pvh)(unsafe.Pointer(&xc.u[0]))
-	if err := x.Pvshim.fromC(&tmp.pvshim); err != nil {
-		return fmt.Errorf("converting field Pvshim: %v", err)
-	}
-	x.PvshimPath = C.GoString(tmp.pvshim_path)
-	x.PvshimCmdline = C.GoString(tmp.pvshim_cmdline)
-	x.PvshimExtra = C.GoString(tmp.pvshim_extra)
-	return nil
-}
-
-func (x *DomainBuildInfo) toC(xc *C.libxl_domain_build_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_build_info_dispose(xc)
-		}
-	}()
-
-	xc.max_vcpus = C.int(x.MaxVcpus)
-	if err := x.AvailVcpus.toC(&xc.avail_vcpus); err != nil {
-		return fmt.Errorf("converting field AvailVcpus: %v", err)
-	}
-	if err := x.Cpumap.toC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-	if err := x.Nodemap.toC(&xc.nodemap); err != nil {
-		return fmt.Errorf("converting field Nodemap: %v", err)
-	}
-	if numVcpuHardAffinity := len(x.VcpuHardAffinity); numVcpuHardAffinity > 0 {
-		xc.vcpu_hard_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuHardAffinity) * C.sizeof_libxl_bitmap))
-		xc.num_vcpu_hard_affinity = C.int(numVcpuHardAffinity)
-		cVcpuHardAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:numVcpuHardAffinity:numVcpuHardAffinity]
-		for i, v := range x.VcpuHardAffinity {
-			if err := v.toC(&cVcpuHardAffinity[i]); err != nil {
-				return fmt.Errorf("converting field VcpuHardAffinity: %v", err)
-			}
-		}
-	}
-	if numVcpuSoftAffinity := len(x.VcpuSoftAffinity); numVcpuSoftAffinity > 0 {
-		xc.vcpu_soft_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuSoftAffinity) * C.sizeof_libxl_bitmap))
-		xc.num_vcpu_soft_affinity = C.int(numVcpuSoftAffinity)
-		cVcpuSoftAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:numVcpuSoftAffinity:numVcpuSoftAffinity]
-		for i, v := range x.VcpuSoftAffinity {
-			if err := v.toC(&cVcpuSoftAffinity[i]); err != nil {
-				return fmt.Errorf("converting field VcpuSoftAffinity: %v", err)
-			}
-		}
-	}
-	if err := x.NumaPlacement.toC(&xc.numa_placement); err != nil {
-		return fmt.Errorf("converting field NumaPlacement: %v", err)
-	}
-	xc.tsc_mode = C.libxl_tsc_mode(x.TscMode)
-	xc.max_memkb = C.uint64_t(x.MaxMemkb)
-	xc.target_memkb = C.uint64_t(x.TargetMemkb)
-	xc.video_memkb = C.uint64_t(x.VideoMemkb)
-	xc.shadow_memkb = C.uint64_t(x.ShadowMemkb)
-	xc.iommu_memkb = C.uint64_t(x.IommuMemkb)
-	xc.rtc_timeoffset = C.uint32_t(x.RtcTimeoffset)
-	xc.exec_ssidref = C.uint32_t(x.ExecSsidref)
-	if x.ExecSsidLabel != "" {
-		xc.exec_ssid_label = C.CString(x.ExecSsidLabel)
-	}
-	if err := x.Localtime.toC(&xc.localtime); err != nil {
-		return fmt.Errorf("converting field Localtime: %v", err)
-	}
-	if err := x.DisableMigrate.toC(&xc.disable_migrate); err != nil {
-		return fmt.Errorf("converting field DisableMigrate: %v", err)
-	}
-	if err := x.Cpuid.toC(&xc.cpuid); err != nil {
-		return fmt.Errorf("converting field Cpuid: %v", err)
-	}
-	if x.BlkdevStart != "" {
-		xc.blkdev_start = C.CString(x.BlkdevStart)
-	}
-	if numVnumaNodes := len(x.VnumaNodes); numVnumaNodes > 0 {
-		xc.vnuma_nodes = (*C.libxl_vnode_info)(C.malloc(C.ulong(numVnumaNodes) * C.sizeof_libxl_vnode_info))
-		xc.num_vnuma_nodes = C.int(numVnumaNodes)
-		cVnumaNodes := (*[1 << 28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:numVnumaNodes:numVnumaNodes]
-		for i, v := range x.VnumaNodes {
-			if err := v.toC(&cVnumaNodes[i]); err != nil {
-				return fmt.Errorf("converting field VnumaNodes: %v", err)
-			}
-		}
-	}
-	xc.max_grant_frames = C.uint32_t(x.MaxGrantFrames)
-	xc.max_maptrack_frames = C.uint32_t(x.MaxMaptrackFrames)
-	xc.device_model_version = C.libxl_device_model_version(x.DeviceModelVersion)
-	if err := x.DeviceModelStubdomain.toC(&xc.device_model_stubdomain); err != nil {
-		return fmt.Errorf("converting field DeviceModelStubdomain: %v", err)
-	}
-	if x.DeviceModel != "" {
-		xc.device_model = C.CString(x.DeviceModel)
-	}
-	xc.device_model_ssidref = C.uint32_t(x.DeviceModelSsidref)
-	if x.DeviceModelSsidLabel != "" {
-		xc.device_model_ssid_label = C.CString(x.DeviceModelSsidLabel)
-	}
-	if x.DeviceModelUser != "" {
-		xc.device_model_user = C.CString(x.DeviceModelUser)
-	}
-	if err := x.Extra.toC(&xc.extra); err != nil {
-		return fmt.Errorf("converting field Extra: %v", err)
-	}
-	if err := x.ExtraPv.toC(&xc.extra_pv); err != nil {
-		return fmt.Errorf("converting field ExtraPv: %v", err)
-	}
-	if err := x.ExtraHvm.toC(&xc.extra_hvm); err != nil {
-		return fmt.Errorf("converting field ExtraHvm: %v", err)
-	}
-	if err := x.SchedParams.toC(&xc.sched_params); err != nil {
-		return fmt.Errorf("converting field SchedParams: %v", err)
-	}
-	if numIoports := len(x.Ioports); numIoports > 0 {
-		xc.ioports = (*C.libxl_ioport_range)(C.malloc(C.ulong(numIoports) * C.sizeof_libxl_ioport_range))
-		xc.num_ioports = C.int(numIoports)
-		cIoports := (*[1 << 28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:numIoports:numIoports]
-		for i, v := range x.Ioports {
-			if err := v.toC(&cIoports[i]); err != nil {
-				return fmt.Errorf("converting field Ioports: %v", err)
-			}
-		}
-	}
-	if numIrqs := len(x.Irqs); numIrqs > 0 {
-		xc.irqs = (*C.uint32_t)(C.malloc(C.size_t(numIrqs * numIrqs)))
-		xc.num_irqs = C.int(numIrqs)
-		cIrqs := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:numIrqs:numIrqs]
-		for i, v := range x.Irqs {
-			cIrqs[i] = C.uint32_t(v)
-		}
-	}
-	if numIomem := len(x.Iomem); numIomem > 0 {
-		xc.iomem = (*C.libxl_iomem_range)(C.malloc(C.ulong(numIomem) * C.sizeof_libxl_iomem_range))
-		xc.num_iomem = C.int(numIomem)
-		cIomem := (*[1 << 28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:numIomem:numIomem]
-		for i, v := range x.Iomem {
-			if err := v.toC(&cIomem[i]); err != nil {
-				return fmt.Errorf("converting field Iomem: %v", err)
-			}
-		}
-	}
-	if err := x.ClaimMode.toC(&xc.claim_mode); err != nil {
-		return fmt.Errorf("converting field ClaimMode: %v", err)
-	}
-	xc.event_channels = C.uint32_t(x.EventChannels)
-	if x.Kernel != "" {
-		xc.kernel = C.CString(x.Kernel)
-	}
-	if x.Cmdline != "" {
-		xc.cmdline = C.CString(x.Cmdline)
-	}
-	if x.Ramdisk != "" {
-		xc.ramdisk = C.CString(x.Ramdisk)
-	}
-	if x.DeviceTree != "" {
-		xc.device_tree = C.CString(x.DeviceTree)
-	}
-	if err := x.Acpi.toC(&xc.acpi); err != nil {
-		return fmt.Errorf("converting field Acpi: %v", err)
-	}
-	if x.Bootloader != "" {
-		xc.bootloader = C.CString(x.Bootloader)
-	}
-	if err := x.BootloaderArgs.toC(&xc.bootloader_args); err != nil {
-		return fmt.Errorf("converting field BootloaderArgs: %v", err)
-	}
-	xc.timer_mode = C.libxl_timer_mode(x.TimerMode)
-	if err := x.NestedHvm.toC(&xc.nested_hvm); err != nil {
-		return fmt.Errorf("converting field NestedHvm: %v", err)
-	}
-	if err := x.Apic.toC(&xc.apic); err != nil {
-		return fmt.Errorf("converting field Apic: %v", err)
-	}
-	if err := x.DmRestrict.toC(&xc.dm_restrict); err != nil {
-		return fmt.Errorf("converting field DmRestrict: %v", err)
-	}
-	xc.tee = C.libxl_tee_type(x.Tee)
-	xc._type = C.libxl_domain_type(x.Type)
-	switch x.Type {
-	case DomainTypeHvm:
-		tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionHvm)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var hvm C.libxl_domain_build_info_type_union_hvm
-		if tmp.Firmware != "" {
-			hvm.firmware = C.CString(tmp.Firmware)
-		}
-		hvm.bios = C.libxl_bios_type(tmp.Bios)
-		if err := tmp.Pae.toC(&hvm.pae); err != nil {
-			return fmt.Errorf("converting field Pae: %v", err)
-		}
-		if err := tmp.Apic.toC(&hvm.apic); err != nil {
-			return fmt.Errorf("converting field Apic: %v", err)
-		}
-		if err := tmp.Acpi.toC(&hvm.acpi); err != nil {
-			return fmt.Errorf("converting field Acpi: %v", err)
-		}
-		if err := tmp.AcpiS3.toC(&hvm.acpi_s3); err != nil {
-			return fmt.Errorf("converting field AcpiS3: %v", err)
-		}
-		if err := tmp.AcpiS4.toC(&hvm.acpi_s4); err != nil {
-			return fmt.Errorf("converting field AcpiS4: %v", err)
-		}
-		if err := tmp.AcpiLaptopSlate.toC(&hvm.acpi_laptop_slate); err != nil {
-			return fmt.Errorf("converting field AcpiLaptopSlate: %v", err)
-		}
-		if err := tmp.Nx.toC(&hvm.nx); err != nil {
-			return fmt.Errorf("converting field Nx: %v", err)
-		}
-		if err := tmp.Viridian.toC(&hvm.viridian); err != nil {
-			return fmt.Errorf("converting field Viridian: %v", err)
-		}
-		if err := tmp.ViridianEnable.toC(&hvm.viridian_enable); err != nil {
-			return fmt.Errorf("converting field ViridianEnable: %v", err)
-		}
-		if err := tmp.ViridianDisable.toC(&hvm.viridian_disable); err != nil {
-			return fmt.Errorf("converting field ViridianDisable: %v", err)
-		}
-		if tmp.Timeoffset != "" {
-			hvm.timeoffset = C.CString(tmp.Timeoffset)
-		}
-		if err := tmp.Hpet.toC(&hvm.hpet); err != nil {
-			return fmt.Errorf("converting field Hpet: %v", err)
-		}
-		if err := tmp.VptAlign.toC(&hvm.vpt_align); err != nil {
-			return fmt.Errorf("converting field VptAlign: %v", err)
-		}
-		hvm.mmio_hole_memkb = C.uint64_t(tmp.MmioHoleMemkb)
-		hvm.timer_mode = C.libxl_timer_mode(tmp.TimerMode)
-		if err := tmp.NestedHvm.toC(&hvm.nested_hvm); err != nil {
-			return fmt.Errorf("converting field NestedHvm: %v", err)
-		}
-		if err := tmp.Altp2M.toC(&hvm.altp2m); err != nil {
-			return fmt.Errorf("converting field Altp2M: %v", err)
-		}
-		if tmp.SystemFirmware != "" {
-			hvm.system_firmware = C.CString(tmp.SystemFirmware)
-		}
-		if tmp.SmbiosFirmware != "" {
-			hvm.smbios_firmware = C.CString(tmp.SmbiosFirmware)
-		}
-		if tmp.AcpiFirmware != "" {
-			hvm.acpi_firmware = C.CString(tmp.AcpiFirmware)
-		}
-		hvm.hdtype = C.libxl_hdtype(tmp.Hdtype)
-		if err := tmp.Nographic.toC(&hvm.nographic); err != nil {
-			return fmt.Errorf("converting field Nographic: %v", err)
-		}
-		if err := tmp.Vga.toC(&hvm.vga); err != nil {
-			return fmt.Errorf("converting field Vga: %v", err)
-		}
-		if err := tmp.Vnc.toC(&hvm.vnc); err != nil {
-			return fmt.Errorf("converting field Vnc: %v", err)
-		}
-		if tmp.Keymap != "" {
-			hvm.keymap = C.CString(tmp.Keymap)
-		}
-		if err := tmp.Sdl.toC(&hvm.sdl); err != nil {
-			return fmt.Errorf("converting field Sdl: %v", err)
-		}
-		if err := tmp.Spice.toC(&hvm.spice); err != nil {
-			return fmt.Errorf("converting field Spice: %v", err)
-		}
-		if err := tmp.GfxPassthru.toC(&hvm.gfx_passthru); err != nil {
-			return fmt.Errorf("converting field GfxPassthru: %v", err)
-		}
-		hvm.gfx_passthru_kind = C.libxl_gfx_passthru_kind(tmp.GfxPassthruKind)
-		if tmp.Serial != "" {
-			hvm.serial = C.CString(tmp.Serial)
-		}
-		if tmp.Boot != "" {
-			hvm.boot = C.CString(tmp.Boot)
-		}
-		if err := tmp.Usb.toC(&hvm.usb); err != nil {
-			return fmt.Errorf("converting field Usb: %v", err)
-		}
-		hvm.usbversion = C.int(tmp.Usbversion)
-		if tmp.Usbdevice != "" {
-			hvm.usbdevice = C.CString(tmp.Usbdevice)
-		}
-		if err := tmp.VkbDevice.toC(&hvm.vkb_device); err != nil {
-			return fmt.Errorf("converting field VkbDevice: %v", err)
-		}
-		if tmp.Soundhw != "" {
-			hvm.soundhw = C.CString(tmp.Soundhw)
-		}
-		if err := tmp.XenPlatformPci.toC(&hvm.xen_platform_pci); err != nil {
-			return fmt.Errorf("converting field XenPlatformPci: %v", err)
-		}
-		if err := tmp.UsbdeviceList.toC(&hvm.usbdevice_list); err != nil {
-			return fmt.Errorf("converting field UsbdeviceList: %v", err)
-		}
-		hvm.vendor_device = C.libxl_vendor_device(tmp.VendorDevice)
-		if err := tmp.MsVmGenid.toC(&hvm.ms_vm_genid); err != nil {
-			return fmt.Errorf("converting field MsVmGenid: %v", err)
-		}
-		if err := tmp.SerialList.toC(&hvm.serial_list); err != nil {
-			return fmt.Errorf("converting field SerialList: %v", err)
-		}
-		if err := tmp.Rdm.toC(&hvm.rdm); err != nil {
-			return fmt.Errorf("converting field Rdm: %v", err)
-		}
-		hvm.rdm_mem_boundary_memkb = C.uint64_t(tmp.RdmMemBoundaryMemkb)
-		hvm.mca_caps = C.uint64_t(tmp.McaCaps)
-		hvmBytes := C.GoBytes(unsafe.Pointer(&hvm), C.sizeof_libxl_domain_build_info_type_union_hvm)
-		copy(xc.u[:], hvmBytes)
-	case DomainTypePv:
-		tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPv)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var pv C.libxl_domain_build_info_type_union_pv
-		if tmp.Kernel != "" {
-			pv.kernel = C.CString(tmp.Kernel)
-		}
-		pv.slack_memkb = C.uint64_t(tmp.SlackMemkb)
-		if tmp.Bootloader != "" {
-			pv.bootloader = C.CString(tmp.Bootloader)
-		}
-		if err := tmp.BootloaderArgs.toC(&pv.bootloader_args); err != nil {
-			return fmt.Errorf("converting field BootloaderArgs: %v", err)
-		}
-		if tmp.Cmdline != "" {
-			pv.cmdline = C.CString(tmp.Cmdline)
-		}
-		if tmp.Ramdisk != "" {
-			pv.ramdisk = C.CString(tmp.Ramdisk)
-		}
-		if tmp.Features != "" {
-			pv.features = C.CString(tmp.Features)
-		}
-		if err := tmp.E820Host.toC(&pv.e820_host); err != nil {
-			return fmt.Errorf("converting field E820Host: %v", err)
-		}
-		pvBytes := C.GoBytes(unsafe.Pointer(&pv), C.sizeof_libxl_domain_build_info_type_union_pv)
-		copy(xc.u[:], pvBytes)
-	case DomainTypePvh:
-		tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPvh)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var pvh C.libxl_domain_build_info_type_union_pvh
-		if err := tmp.Pvshim.toC(&pvh.pvshim); err != nil {
-			return fmt.Errorf("converting field Pvshim: %v", err)
-		}
-		if tmp.PvshimPath != "" {
-			pvh.pvshim_path = C.CString(tmp.PvshimPath)
-		}
-		if tmp.PvshimCmdline != "" {
-			pvh.pvshim_cmdline = C.CString(tmp.PvshimCmdline)
-		}
-		if tmp.PvshimExtra != "" {
-			pvh.pvshim_extra = C.CString(tmp.PvshimExtra)
-		}
-		pvhBytes := C.GoBytes(unsafe.Pointer(&pvh), C.sizeof_libxl_domain_build_info_type_union_pvh)
-		copy(xc.u[:], pvhBytes)
-	case DomainTypeInvalid:
-		break
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-	xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion)
-	xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart)
-	xc.altp2m = C.libxl_altp2m_mode(x.Altp2M)
-
-	return nil
-}
-
-// NewDeviceVfb returns an instance of DeviceVfb initialized with defaults.
-func NewDeviceVfb() (*DeviceVfb, error) {
-	var (
-		x  DeviceVfb
-		xc C.libxl_device_vfb
-	)
-
-	C.libxl_device_vfb_init(&xc)
-	defer C.libxl_device_vfb_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVfb) fromC(xc *C.libxl_device_vfb) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	if err := x.Vnc.fromC(&xc.vnc); err != nil {
-		return fmt.Errorf("converting field Vnc: %v", err)
-	}
-	if err := x.Sdl.fromC(&xc.sdl); err != nil {
-		return fmt.Errorf("converting field Sdl: %v", err)
-	}
-	x.Keymap = C.GoString(xc.keymap)
-
-	return nil
-}
-
-func (x *DeviceVfb) toC(xc *C.libxl_device_vfb) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vfb_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	if err := x.Vnc.toC(&xc.vnc); err != nil {
-		return fmt.Errorf("converting field Vnc: %v", err)
-	}
-	if err := x.Sdl.toC(&xc.sdl); err != nil {
-		return fmt.Errorf("converting field Sdl: %v", err)
-	}
-	if x.Keymap != "" {
-		xc.keymap = C.CString(x.Keymap)
-	}
-
-	return nil
-}
-
-// NewDeviceVkb returns an instance of DeviceVkb initialized with defaults.
-func NewDeviceVkb() (*DeviceVkb, error) {
-	var (
-		x  DeviceVkb
-		xc C.libxl_device_vkb
-	)
-
-	C.libxl_device_vkb_init(&xc)
-	defer C.libxl_device_vkb_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVkb) fromC(xc *C.libxl_device_vkb) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.BackendType = VkbBackend(xc.backend_type)
-	x.UniqueId = C.GoString(xc.unique_id)
-	x.FeatureDisableKeyboard = bool(xc.feature_disable_keyboard)
-	x.FeatureDisablePointer = bool(xc.feature_disable_pointer)
-	x.FeatureAbsPointer = bool(xc.feature_abs_pointer)
-	x.FeatureRawPointer = bool(xc.feature_raw_pointer)
-	x.FeatureMultiTouch = bool(xc.feature_multi_touch)
-	x.Width = uint32(xc.width)
-	x.Height = uint32(xc.height)
-	x.MultiTouchWidth = uint32(xc.multi_touch_width)
-	x.MultiTouchHeight = uint32(xc.multi_touch_height)
-	x.MultiTouchNumContacts = uint32(xc.multi_touch_num_contacts)
-
-	return nil
-}
-
-func (x *DeviceVkb) toC(xc *C.libxl_device_vkb) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vkb_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.backend_type = C.libxl_vkb_backend(x.BackendType)
-	if x.UniqueId != "" {
-		xc.unique_id = C.CString(x.UniqueId)
-	}
-	xc.feature_disable_keyboard = C.bool(x.FeatureDisableKeyboard)
-	xc.feature_disable_pointer = C.bool(x.FeatureDisablePointer)
-	xc.feature_abs_pointer = C.bool(x.FeatureAbsPointer)
-	xc.feature_raw_pointer = C.bool(x.FeatureRawPointer)
-	xc.feature_multi_touch = C.bool(x.FeatureMultiTouch)
-	xc.width = C.uint32_t(x.Width)
-	xc.height = C.uint32_t(x.Height)
-	xc.multi_touch_width = C.uint32_t(x.MultiTouchWidth)
-	xc.multi_touch_height = C.uint32_t(x.MultiTouchHeight)
-	xc.multi_touch_num_contacts = C.uint32_t(x.MultiTouchNumContacts)
-
-	return nil
-}
-
-// NewDeviceDisk returns an instance of DeviceDisk initialized with defaults.
-func NewDeviceDisk() (*DeviceDisk, error) {
-	var (
-		x  DeviceDisk
-		xc C.libxl_device_disk
-	)
-
-	C.libxl_device_disk_init(&xc)
-	defer C.libxl_device_disk_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceDisk) fromC(xc *C.libxl_device_disk) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.PdevPath = C.GoString(xc.pdev_path)
-	x.Vdev = C.GoString(xc.vdev)
-	x.Backend = DiskBackend(xc.backend)
-	x.Format = DiskFormat(xc.format)
-	x.Script = C.GoString(xc.script)
-	x.Removable = int(xc.removable)
-	x.Readwrite = int(xc.readwrite)
-	x.IsCdrom = int(xc.is_cdrom)
-	x.DirectIoSafe = bool(xc.direct_io_safe)
-	if err := x.DiscardEnable.fromC(&xc.discard_enable); err != nil {
-		return fmt.Errorf("converting field DiscardEnable: %v", err)
-	}
-	if err := x.ColoEnable.fromC(&xc.colo_enable); err != nil {
-		return fmt.Errorf("converting field ColoEnable: %v", err)
-	}
-	if err := x.ColoRestoreEnable.fromC(&xc.colo_restore_enable); err != nil {
-		return fmt.Errorf("converting field ColoRestoreEnable: %v", err)
-	}
-	x.ColoHost = C.GoString(xc.colo_host)
-	x.ColoPort = int(xc.colo_port)
-	x.ColoExport = C.GoString(xc.colo_export)
-	x.ActiveDisk = C.GoString(xc.active_disk)
-	x.HiddenDisk = C.GoString(xc.hidden_disk)
-
-	return nil
-}
-
-func (x *DeviceDisk) toC(xc *C.libxl_device_disk) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_disk_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	if x.PdevPath != "" {
-		xc.pdev_path = C.CString(x.PdevPath)
-	}
-	if x.Vdev != "" {
-		xc.vdev = C.CString(x.Vdev)
-	}
-	xc.backend = C.libxl_disk_backend(x.Backend)
-	xc.format = C.libxl_disk_format(x.Format)
-	if x.Script != "" {
-		xc.script = C.CString(x.Script)
-	}
-	xc.removable = C.int(x.Removable)
-	xc.readwrite = C.int(x.Readwrite)
-	xc.is_cdrom = C.int(x.IsCdrom)
-	xc.direct_io_safe = C.bool(x.DirectIoSafe)
-	if err := x.DiscardEnable.toC(&xc.discard_enable); err != nil {
-		return fmt.Errorf("converting field DiscardEnable: %v", err)
-	}
-	if err := x.ColoEnable.toC(&xc.colo_enable); err != nil {
-		return fmt.Errorf("converting field ColoEnable: %v", err)
-	}
-	if err := x.ColoRestoreEnable.toC(&xc.colo_restore_enable); err != nil {
-		return fmt.Errorf("converting field ColoRestoreEnable: %v", err)
-	}
-	if x.ColoHost != "" {
-		xc.colo_host = C.CString(x.ColoHost)
-	}
-	xc.colo_port = C.int(x.ColoPort)
-	if x.ColoExport != "" {
-		xc.colo_export = C.CString(x.ColoExport)
-	}
-	if x.ActiveDisk != "" {
-		xc.active_disk = C.CString(x.ActiveDisk)
-	}
-	if x.HiddenDisk != "" {
-		xc.hidden_disk = C.CString(x.HiddenDisk)
-	}
-
-	return nil
-}
-
-// NewDeviceNic returns an instance of DeviceNic initialized with defaults.
-func NewDeviceNic() (*DeviceNic, error) {
-	var (
-		x  DeviceNic
-		xc C.libxl_device_nic
-	)
-
-	C.libxl_device_nic_init(&xc)
-	defer C.libxl_device_nic_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceNic) fromC(xc *C.libxl_device_nic) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.Mtu = int(xc.mtu)
-	x.Model = C.GoString(xc.model)
-	if err := x.Mac.fromC(&xc.mac); err != nil {
-		return fmt.Errorf("converting field Mac: %v", err)
-	}
-	x.Ip = C.GoString(xc.ip)
-	x.Bridge = C.GoString(xc.bridge)
-	x.Ifname = C.GoString(xc.ifname)
-	x.Script = C.GoString(xc.script)
-	x.Nictype = NicType(xc.nictype)
-	x.RateBytesPerInterval = uint64(xc.rate_bytes_per_interval)
-	x.RateIntervalUsecs = uint32(xc.rate_interval_usecs)
-	x.Gatewaydev = C.GoString(xc.gatewaydev)
-	x.ColoftForwarddev = C.GoString(xc.coloft_forwarddev)
-	x.ColoSockMirrorId = C.GoString(xc.colo_sock_mirror_id)
-	x.ColoSockMirrorIp = C.GoString(xc.colo_sock_mirror_ip)
-	x.ColoSockMirrorPort = C.GoString(xc.colo_sock_mirror_port)
-	x.ColoSockComparePriInId = C.GoString(xc.colo_sock_compare_pri_in_id)
-	x.ColoSockComparePriInIp = C.GoString(xc.colo_sock_compare_pri_in_ip)
-	x.ColoSockComparePriInPort = C.GoString(xc.colo_sock_compare_pri_in_port)
-	x.ColoSockCompareSecInId = C.GoString(xc.colo_sock_compare_sec_in_id)
-	x.ColoSockCompareSecInIp = C.GoString(xc.colo_sock_compare_sec_in_ip)
-	x.ColoSockCompareSecInPort = C.GoString(xc.colo_sock_compare_sec_in_port)
-	x.ColoSockCompareNotifyId = C.GoString(xc.colo_sock_compare_notify_id)
-	x.ColoSockCompareNotifyIp = C.GoString(xc.colo_sock_compare_notify_ip)
-	x.ColoSockCompareNotifyPort = C.GoString(xc.colo_sock_compare_notify_port)
-	x.ColoSockRedirector0Id = C.GoString(xc.colo_sock_redirector0_id)
-	x.ColoSockRedirector0Ip = C.GoString(xc.colo_sock_redirector0_ip)
-	x.ColoSockRedirector0Port = C.GoString(xc.colo_sock_redirector0_port)
-	x.ColoSockRedirector1Id = C.GoString(xc.colo_sock_redirector1_id)
-	x.ColoSockRedirector1Ip = C.GoString(xc.colo_sock_redirector1_ip)
-	x.ColoSockRedirector1Port = C.GoString(xc.colo_sock_redirector1_port)
-	x.ColoSockRedirector2Id = C.GoString(xc.colo_sock_redirector2_id)
-	x.ColoSockRedirector2Ip = C.GoString(xc.colo_sock_redirector2_ip)
-	x.ColoSockRedirector2Port = C.GoString(xc.colo_sock_redirector2_port)
-	x.ColoFilterMirrorQueue = C.GoString(xc.colo_filter_mirror_queue)
-	x.ColoFilterMirrorOutdev = C.GoString(xc.colo_filter_mirror_outdev)
-	x.ColoFilterRedirector0Queue = C.GoString(xc.colo_filter_redirector0_queue)
-	x.ColoFilterRedirector0Indev = C.GoString(xc.colo_filter_redirector0_indev)
-	x.ColoFilterRedirector0Outdev = C.GoString(xc.colo_filter_redirector0_outdev)
-	x.ColoFilterRedirector1Queue = C.GoString(xc.colo_filter_redirector1_queue)
-	x.ColoFilterRedirector1Indev = C.GoString(xc.colo_filter_redirector1_indev)
-	x.ColoFilterRedirector1Outdev = C.GoString(xc.colo_filter_redirector1_outdev)
-	x.ColoComparePriIn = C.GoString(xc.colo_compare_pri_in)
-	x.ColoCompareSecIn = C.GoString(xc.colo_compare_sec_in)
-	x.ColoCompareOut = C.GoString(xc.colo_compare_out)
-	x.ColoCompareNotifyDev = C.GoString(xc.colo_compare_notify_dev)
-	x.ColoSockSecRedirector0Id = C.GoString(xc.colo_sock_sec_redirector0_id)
-	x.ColoSockSecRedirector0Ip = C.GoString(xc.colo_sock_sec_redirector0_ip)
-	x.ColoSockSecRedirector0Port = C.GoString(xc.colo_sock_sec_redirector0_port)
-	x.ColoSockSecRedirector1Id = C.GoString(xc.colo_sock_sec_redirector1_id)
-	x.ColoSockSecRedirector1Ip = C.GoString(xc.colo_sock_sec_redirector1_ip)
-	x.ColoSockSecRedirector1Port = C.GoString(xc.colo_sock_sec_redirector1_port)
-	x.ColoFilterSecRedirector0Queue = C.GoString(xc.colo_filter_sec_redirector0_queue)
-	x.ColoFilterSecRedirector0Indev = C.GoString(xc.colo_filter_sec_redirector0_indev)
-	x.ColoFilterSecRedirector0Outdev = C.GoString(xc.colo_filter_sec_redirector0_outdev)
-	x.ColoFilterSecRedirector1Queue = C.GoString(xc.colo_filter_sec_redirector1_queue)
-	x.ColoFilterSecRedirector1Indev = C.GoString(xc.colo_filter_sec_redirector1_indev)
-	x.ColoFilterSecRedirector1Outdev = C.GoString(xc.colo_filter_sec_redirector1_outdev)
-	x.ColoFilterSecRewriter0Queue = C.GoString(xc.colo_filter_sec_rewriter0_queue)
-	x.ColoCheckpointHost = C.GoString(xc.colo_checkpoint_host)
-	x.ColoCheckpointPort = C.GoString(xc.colo_checkpoint_port)
-
-	return nil
-}
-
-func (x *DeviceNic) toC(xc *C.libxl_device_nic) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_nic_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.mtu = C.int(x.Mtu)
-	if x.Model != "" {
-		xc.model = C.CString(x.Model)
-	}
-	if err := x.Mac.toC(&xc.mac); err != nil {
-		return fmt.Errorf("converting field Mac: %v", err)
-	}
-	if x.Ip != "" {
-		xc.ip = C.CString(x.Ip)
-	}
-	if x.Bridge != "" {
-		xc.bridge = C.CString(x.Bridge)
-	}
-	if x.Ifname != "" {
-		xc.ifname = C.CString(x.Ifname)
-	}
-	if x.Script != "" {
-		xc.script = C.CString(x.Script)
-	}
-	xc.nictype = C.libxl_nic_type(x.Nictype)
-	xc.rate_bytes_per_interval = C.uint64_t(x.RateBytesPerInterval)
-	xc.rate_interval_usecs = C.uint32_t(x.RateIntervalUsecs)
-	if x.Gatewaydev != "" {
-		xc.gatewaydev = C.CString(x.Gatewaydev)
-	}
-	if x.ColoftForwarddev != "" {
-		xc.coloft_forwarddev = C.CString(x.ColoftForwarddev)
-	}
-	if x.ColoSockMirrorId != "" {
-		xc.colo_sock_mirror_id = C.CString(x.ColoSockMirrorId)
-	}
-	if x.ColoSockMirrorIp != "" {
-		xc.colo_sock_mirror_ip = C.CString(x.ColoSockMirrorIp)
-	}
-	if x.ColoSockMirrorPort != "" {
-		xc.colo_sock_mirror_port = C.CString(x.ColoSockMirrorPort)
-	}
-	if x.ColoSockComparePriInId != "" {
-		xc.colo_sock_compare_pri_in_id = C.CString(x.ColoSockComparePriInId)
-	}
-	if x.ColoSockComparePriInIp != "" {
-		xc.colo_sock_compare_pri_in_ip = C.CString(x.ColoSockComparePriInIp)
-	}
-	if x.ColoSockComparePriInPort != "" {
-		xc.colo_sock_compare_pri_in_port = C.CString(x.ColoSockComparePriInPort)
-	}
-	if x.ColoSockCompareSecInId != "" {
-		xc.colo_sock_compare_sec_in_id = C.CString(x.ColoSockCompareSecInId)
-	}
-	if x.ColoSockCompareSecInIp != "" {
-		xc.colo_sock_compare_sec_in_ip = C.CString(x.ColoSockCompareSecInIp)
-	}
-	if x.ColoSockCompareSecInPort != "" {
-		xc.colo_sock_compare_sec_in_port = C.CString(x.ColoSockCompareSecInPort)
-	}
-	if x.ColoSockCompareNotifyId != "" {
-		xc.colo_sock_compare_notify_id = C.CString(x.ColoSockCompareNotifyId)
-	}
-	if x.ColoSockCompareNotifyIp != "" {
-		xc.colo_sock_compare_notify_ip = C.CString(x.ColoSockCompareNotifyIp)
-	}
-	if x.ColoSockCompareNotifyPort != "" {
-		xc.colo_sock_compare_notify_port = C.CString(x.ColoSockCompareNotifyPort)
-	}
-	if x.ColoSockRedirector0Id != "" {
-		xc.colo_sock_redirector0_id = C.CString(x.ColoSockRedirector0Id)
-	}
-	if x.ColoSockRedirector0Ip != "" {
-		xc.colo_sock_redirector0_ip = C.CString(x.ColoSockRedirector0Ip)
-	}
-	if x.ColoSockRedirector0Port != "" {
-		xc.colo_sock_redirector0_port = C.CString(x.ColoSockRedirector0Port)
-	}
-	if x.ColoSockRedirector1Id != "" {
-		xc.colo_sock_redirector1_id = C.CString(x.ColoSockRedirector1Id)
-	}
-	if x.ColoSockRedirector1Ip != "" {
-		xc.colo_sock_redirector1_ip = C.CString(x.ColoSockRedirector1Ip)
-	}
-	if x.ColoSockRedirector1Port != "" {
-		xc.colo_sock_redirector1_port = C.CString(x.ColoSockRedirector1Port)
-	}
-	if x.ColoSockRedirector2Id != "" {
-		xc.colo_sock_redirector2_id = C.CString(x.ColoSockRedirector2Id)
-	}
-	if x.ColoSockRedirector2Ip != "" {
-		xc.colo_sock_redirector2_ip = C.CString(x.ColoSockRedirector2Ip)
-	}
-	if x.ColoSockRedirector2Port != "" {
-		xc.colo_sock_redirector2_port = C.CString(x.ColoSockRedirector2Port)
-	}
-	if x.ColoFilterMirrorQueue != "" {
-		xc.colo_filter_mirror_queue = C.CString(x.ColoFilterMirrorQueue)
-	}
-	if x.ColoFilterMirrorOutdev != "" {
-		xc.colo_filter_mirror_outdev = C.CString(x.ColoFilterMirrorOutdev)
-	}
-	if x.ColoFilterRedirector0Queue != "" {
-		xc.colo_filter_redirector0_queue = C.CString(x.ColoFilterRedirector0Queue)
-	}
-	if x.ColoFilterRedirector0Indev != "" {
-		xc.colo_filter_redirector0_indev = C.CString(x.ColoFilterRedirector0Indev)
-	}
-	if x.ColoFilterRedirector0Outdev != "" {
-		xc.colo_filter_redirector0_outdev = C.CString(x.ColoFilterRedirector0Outdev)
-	}
-	if x.ColoFilterRedirector1Queue != "" {
-		xc.colo_filter_redirector1_queue = C.CString(x.ColoFilterRedirector1Queue)
-	}
-	if x.ColoFilterRedirector1Indev != "" {
-		xc.colo_filter_redirector1_indev = C.CString(x.ColoFilterRedirector1Indev)
-	}
-	if x.ColoFilterRedirector1Outdev != "" {
-		xc.colo_filter_redirector1_outdev = C.CString(x.ColoFilterRedirector1Outdev)
-	}
-	if x.ColoComparePriIn != "" {
-		xc.colo_compare_pri_in = C.CString(x.ColoComparePriIn)
-	}
-	if x.ColoCompareSecIn != "" {
-		xc.colo_compare_sec_in = C.CString(x.ColoCompareSecIn)
-	}
-	if x.ColoCompareOut != "" {
-		xc.colo_compare_out = C.CString(x.ColoCompareOut)
-	}
-	if x.ColoCompareNotifyDev != "" {
-		xc.colo_compare_notify_dev = C.CString(x.ColoCompareNotifyDev)
-	}
-	if x.ColoSockSecRedirector0Id != "" {
-		xc.colo_sock_sec_redirector0_id = C.CString(x.ColoSockSecRedirector0Id)
-	}
-	if x.ColoSockSecRedirector0Ip != "" {
-		xc.colo_sock_sec_redirector0_ip = C.CString(x.ColoSockSecRedirector0Ip)
-	}
-	if x.ColoSockSecRedirector0Port != "" {
-		xc.colo_sock_sec_redirector0_port = C.CString(x.ColoSockSecRedirector0Port)
-	}
-	if x.ColoSockSecRedirector1Id != "" {
-		xc.colo_sock_sec_redirector1_id = C.CString(x.ColoSockSecRedirector1Id)
-	}
-	if x.ColoSockSecRedirector1Ip != "" {
-		xc.colo_sock_sec_redirector1_ip = C.CString(x.ColoSockSecRedirector1Ip)
-	}
-	if x.ColoSockSecRedirector1Port != "" {
-		xc.colo_sock_sec_redirector1_port = C.CString(x.ColoSockSecRedirector1Port)
-	}
-	if x.ColoFilterSecRedirector0Queue != "" {
-		xc.colo_filter_sec_redirector0_queue = C.CString(x.ColoFilterSecRedirector0Queue)
-	}
-	if x.ColoFilterSecRedirector0Indev != "" {
-		xc.colo_filter_sec_redirector0_indev = C.CString(x.ColoFilterSecRedirector0Indev)
-	}
-	if x.ColoFilterSecRedirector0Outdev != "" {
-		xc.colo_filter_sec_redirector0_outdev = C.CString(x.ColoFilterSecRedirector0Outdev)
-	}
-	if x.ColoFilterSecRedirector1Queue != "" {
-		xc.colo_filter_sec_redirector1_queue = C.CString(x.ColoFilterSecRedirector1Queue)
-	}
-	if x.ColoFilterSecRedirector1Indev != "" {
-		xc.colo_filter_sec_redirector1_indev = C.CString(x.ColoFilterSecRedirector1Indev)
-	}
-	if x.ColoFilterSecRedirector1Outdev != "" {
-		xc.colo_filter_sec_redirector1_outdev = C.CString(x.ColoFilterSecRedirector1Outdev)
-	}
-	if x.ColoFilterSecRewriter0Queue != "" {
-		xc.colo_filter_sec_rewriter0_queue = C.CString(x.ColoFilterSecRewriter0Queue)
-	}
-	if x.ColoCheckpointHost != "" {
-		xc.colo_checkpoint_host = C.CString(x.ColoCheckpointHost)
-	}
-	if x.ColoCheckpointPort != "" {
-		xc.colo_checkpoint_port = C.CString(x.ColoCheckpointPort)
-	}
-
-	return nil
-}
-
-// NewDevicePci returns an instance of DevicePci initialized with defaults.
-func NewDevicePci() (*DevicePci, error) {
-	var (
-		x  DevicePci
-		xc C.libxl_device_pci
-	)
-
-	C.libxl_device_pci_init(&xc)
-	defer C.libxl_device_pci_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DevicePci) fromC(xc *C.libxl_device_pci) error {
-	x.Func = byte(xc._func)
-	x.Dev = byte(xc.dev)
-	x.Bus = byte(xc.bus)
-	x.Domain = int(xc.domain)
-	x.Vdevfn = uint32(xc.vdevfn)
-	x.VfuncMask = uint32(xc.vfunc_mask)
-	x.Msitranslate = bool(xc.msitranslate)
-	x.PowerMgmt = bool(xc.power_mgmt)
-	x.Permissive = bool(xc.permissive)
-	x.Seize = bool(xc.seize)
-	x.RdmPolicy = RdmReservePolicy(xc.rdm_policy)
-
-	return nil
-}
-
-func (x *DevicePci) toC(xc *C.libxl_device_pci) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_pci_dispose(xc)
-		}
-	}()
-
-	xc._func = C.uint8_t(x.Func)
-	xc.dev = C.uint8_t(x.Dev)
-	xc.bus = C.uint8_t(x.Bus)
-	xc.domain = C.int(x.Domain)
-	xc.vdevfn = C.uint32_t(x.Vdevfn)
-	xc.vfunc_mask = C.uint32_t(x.VfuncMask)
-	xc.msitranslate = C.bool(x.Msitranslate)
-	xc.power_mgmt = C.bool(x.PowerMgmt)
-	xc.permissive = C.bool(x.Permissive)
-	xc.seize = C.bool(x.Seize)
-	xc.rdm_policy = C.libxl_rdm_reserve_policy(x.RdmPolicy)
-
-	return nil
-}
-
-// NewDeviceRdm returns an instance of DeviceRdm initialized with defaults.
-func NewDeviceRdm() (*DeviceRdm, error) {
-	var (
-		x  DeviceRdm
-		xc C.libxl_device_rdm
-	)
-
-	C.libxl_device_rdm_init(&xc)
-	defer C.libxl_device_rdm_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceRdm) fromC(xc *C.libxl_device_rdm) error {
-	x.Start = uint64(xc.start)
-	x.Size = uint64(xc.size)
-	x.Policy = RdmReservePolicy(xc.policy)
-
-	return nil
-}
-
-func (x *DeviceRdm) toC(xc *C.libxl_device_rdm) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_rdm_dispose(xc)
-		}
-	}()
-
-	xc.start = C.uint64_t(x.Start)
-	xc.size = C.uint64_t(x.Size)
-	xc.policy = C.libxl_rdm_reserve_policy(x.Policy)
-
-	return nil
-}
-
-// NewDeviceUsbctrl returns an instance of DeviceUsbctrl initialized with defaults.
-func NewDeviceUsbctrl() (*DeviceUsbctrl, error) {
-	var (
-		x  DeviceUsbctrl
-		xc C.libxl_device_usbctrl
-	)
-
-	C.libxl_device_usbctrl_init(&xc)
-	defer C.libxl_device_usbctrl_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceUsbctrl) fromC(xc *C.libxl_device_usbctrl) error {
-	x.Type = UsbctrlType(xc._type)
-	x.Devid = Devid(xc.devid)
-	x.Version = int(xc.version)
-	x.Ports = int(xc.ports)
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-
-	return nil
-}
-
-func (x *DeviceUsbctrl) toC(xc *C.libxl_device_usbctrl) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_usbctrl_dispose(xc)
-		}
-	}()
-
-	xc._type = C.libxl_usbctrl_type(x.Type)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.version = C.int(x.Version)
-	xc.ports = C.int(x.Ports)
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-
-	return nil
-}
-
-// NewDeviceUsbdev returns an instance of DeviceUsbdev initialized with defaults.
-func NewDeviceUsbdev(utype UsbdevType) (*DeviceUsbdev, error) {
-	var (
-		x  DeviceUsbdev
-		xc C.libxl_device_usbdev
-	)
-
-	C.libxl_device_usbdev_init(&xc)
-	C.libxl_device_usbdev_init_type(&xc, C.libxl_usbdev_type(utype))
-	defer C.libxl_device_usbdev_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceUsbdev) fromC(xc *C.libxl_device_usbdev) error {
-	x.Ctrl = Devid(xc.ctrl)
-	x.Port = int(xc.port)
-	x.Type = UsbdevType(xc._type)
-	switch x.Type {
-	case UsbdevTypeHostdev:
-		var typeHostdev DeviceUsbdevTypeUnionHostdev
-		if err := typeHostdev.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeHostdev: %v", err)
-		}
-		x.TypeUnion = typeHostdev
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-func (x *DeviceUsbdevTypeUnionHostdev) fromC(xc *C.libxl_device_usbdev) error {
-	if UsbdevType(xc._type) != UsbdevTypeHostdev {
-		return errors.New("expected union key UsbdevTypeHostdev")
-	}
-
-	tmp := (*C.libxl_device_usbdev_type_union_hostdev)(unsafe.Pointer(&xc.u[0]))
-	x.Hostbus = byte(tmp.hostbus)
-	x.Hostaddr = byte(tmp.hostaddr)
-	return nil
-}
-
-func (x *DeviceUsbdev) toC(xc *C.libxl_device_usbdev) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_usbdev_dispose(xc)
-		}
-	}()
-
-	xc.ctrl = C.libxl_devid(x.Ctrl)
-	xc.port = C.int(x.Port)
-	xc._type = C.libxl_usbdev_type(x.Type)
-	switch x.Type {
-	case UsbdevTypeHostdev:
-		tmp, ok := x.TypeUnion.(DeviceUsbdevTypeUnionHostdev)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var hostdev C.libxl_device_usbdev_type_union_hostdev
-		hostdev.hostbus = C.uint8_t(tmp.Hostbus)
-		hostdev.hostaddr = C.uint8_t(tmp.Hostaddr)
-		hostdevBytes := C.GoBytes(unsafe.Pointer(&hostdev), C.sizeof_libxl_device_usbdev_type_union_hostdev)
-		copy(xc.u[:], hostdevBytes)
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-// NewDeviceDtdev returns an instance of DeviceDtdev initialized with defaults.
-func NewDeviceDtdev() (*DeviceDtdev, error) {
-	var (
-		x  DeviceDtdev
-		xc C.libxl_device_dtdev
-	)
-
-	C.libxl_device_dtdev_init(&xc)
-	defer C.libxl_device_dtdev_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceDtdev) fromC(xc *C.libxl_device_dtdev) error {
-	x.Path = C.GoString(xc.path)
-
-	return nil
-}
-
-func (x *DeviceDtdev) toC(xc *C.libxl_device_dtdev) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_dtdev_dispose(xc)
-		}
-	}()
-
-	if x.Path != "" {
-		xc.path = C.CString(x.Path)
-	}
-
-	return nil
-}
-
-// NewDeviceVtpm returns an instance of DeviceVtpm initialized with defaults.
-func NewDeviceVtpm() (*DeviceVtpm, error) {
-	var (
-		x  DeviceVtpm
-		xc C.libxl_device_vtpm
-	)
-
-	C.libxl_device_vtpm_init(&xc)
-	defer C.libxl_device_vtpm_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVtpm) fromC(xc *C.libxl_device_vtpm) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-
-	return nil
-}
-
-func (x *DeviceVtpm) toC(xc *C.libxl_device_vtpm) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vtpm_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-
-	return nil
-}
-
-// NewDeviceP9 returns an instance of DeviceP9 initialized with defaults.
-func NewDeviceP9() (*DeviceP9, error) {
-	var (
-		x  DeviceP9
-		xc C.libxl_device_p9
-	)
-
-	C.libxl_device_p9_init(&xc)
-	defer C.libxl_device_p9_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceP9) fromC(xc *C.libxl_device_p9) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Tag = C.GoString(xc.tag)
-	x.Path = C.GoString(xc.path)
-	x.SecurityModel = C.GoString(xc.security_model)
-	x.Devid = Devid(xc.devid)
-
-	return nil
-}
-
-func (x *DeviceP9) toC(xc *C.libxl_device_p9) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_p9_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	if x.Tag != "" {
-		xc.tag = C.CString(x.Tag)
-	}
-	if x.Path != "" {
-		xc.path = C.CString(x.Path)
-	}
-	if x.SecurityModel != "" {
-		xc.security_model = C.CString(x.SecurityModel)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-
-	return nil
-}
-
-// NewDevicePvcallsif returns an instance of DevicePvcallsif initialized with defaults.
-func NewDevicePvcallsif() (*DevicePvcallsif, error) {
-	var (
-		x  DevicePvcallsif
-		xc C.libxl_device_pvcallsif
-	)
-
-	C.libxl_device_pvcallsif_init(&xc)
-	defer C.libxl_device_pvcallsif_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DevicePvcallsif) fromC(xc *C.libxl_device_pvcallsif) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-
-	return nil
-}
-
-func (x *DevicePvcallsif) toC(xc *C.libxl_device_pvcallsif) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_pvcallsif_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-
-	return nil
-}
-
-// NewDeviceChannel returns an instance of DeviceChannel initialized with defaults.
-func NewDeviceChannel(connection ChannelConnection) (*DeviceChannel, error) {
-	var (
-		x  DeviceChannel
-		xc C.libxl_device_channel
-	)
-
-	C.libxl_device_channel_init(&xc)
-	C.libxl_device_channel_init_connection(&xc, C.libxl_channel_connection(connection))
-	defer C.libxl_device_channel_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceChannel) fromC(xc *C.libxl_device_channel) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.Name = C.GoString(xc.name)
-	x.Connection = ChannelConnection(xc.connection)
-	switch x.Connection {
-	case ChannelConnectionUnknown:
-		x.ConnectionUnion = nil
-	case ChannelConnectionPty:
-		x.ConnectionUnion = nil
-	case ChannelConnectionSocket:
-		var connectionSocket DeviceChannelConnectionUnionSocket
-		if err := connectionSocket.fromC(xc); err != nil {
-			return fmt.Errorf("converting field connectionSocket: %v", err)
-		}
-		x.ConnectionUnion = connectionSocket
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Connection)
-	}
-
-	return nil
-}
-
-func (x *DeviceChannelConnectionUnionSocket) fromC(xc *C.libxl_device_channel) error {
-	if ChannelConnection(xc.connection) != ChannelConnectionSocket {
-		return errors.New("expected union key ChannelConnectionSocket")
-	}
-
-	tmp := (*C.libxl_device_channel_connection_union_socket)(unsafe.Pointer(&xc.u[0]))
-	x.Path = C.GoString(tmp.path)
-	return nil
-}
-
-func (x *DeviceChannel) toC(xc *C.libxl_device_channel) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_channel_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	if x.Name != "" {
-		xc.name = C.CString(x.Name)
-	}
-	xc.connection = C.libxl_channel_connection(x.Connection)
-	switch x.Connection {
-	case ChannelConnectionUnknown:
-		break
-	case ChannelConnectionPty:
-		break
-	case ChannelConnectionSocket:
-		tmp, ok := x.ConnectionUnion.(DeviceChannelConnectionUnionSocket)
-		if !ok {
-			return errors.New("wrong type for union key connection")
-		}
-		var socket C.libxl_device_channel_connection_union_socket
-		if tmp.Path != "" {
-			socket.path = C.CString(tmp.Path)
-		}
-		socketBytes := C.GoBytes(unsafe.Pointer(&socket), C.sizeof_libxl_device_channel_connection_union_socket)
-		copy(xc.u[:], socketBytes)
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Connection)
-	}
-
-	return nil
-}
-
-// NewConnectorParam returns an instance of ConnectorParam initialized with defaults.
-func NewConnectorParam() (*ConnectorParam, error) {
-	var (
-		x  ConnectorParam
-		xc C.libxl_connector_param
-	)
-
-	C.libxl_connector_param_init(&xc)
-	defer C.libxl_connector_param_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *ConnectorParam) fromC(xc *C.libxl_connector_param) error {
-	x.UniqueId = C.GoString(xc.unique_id)
-	x.Width = uint32(xc.width)
-	x.Height = uint32(xc.height)
-
-	return nil
-}
-
-func (x *ConnectorParam) toC(xc *C.libxl_connector_param) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_connector_param_dispose(xc)
-		}
-	}()
-
-	if x.UniqueId != "" {
-		xc.unique_id = C.CString(x.UniqueId)
-	}
-	xc.width = C.uint32_t(x.Width)
-	xc.height = C.uint32_t(x.Height)
-
-	return nil
-}
-
-// NewDeviceVdispl returns an instance of DeviceVdispl initialized with defaults.
-func NewDeviceVdispl() (*DeviceVdispl, error) {
-	var (
-		x  DeviceVdispl
-		xc C.libxl_device_vdispl
-	)
-
-	C.libxl_device_vdispl_init(&xc)
-	defer C.libxl_device_vdispl_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVdispl) fromC(xc *C.libxl_device_vdispl) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.BeAlloc = bool(xc.be_alloc)
-	numConnectors := int(xc.num_connectors)
-	cConnectors := (*[1 << 28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors]
-	x.Connectors = make([]ConnectorParam, numConnectors)
-	for i, v := range cConnectors {
-		if err := x.Connectors[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Connectors: %v", err)
-		}
-	}
-
-	return nil
-}
-
-func (x *DeviceVdispl) toC(xc *C.libxl_device_vdispl) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vdispl_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.be_alloc = C.bool(x.BeAlloc)
-	if numConnectors := len(x.Connectors); numConnectors > 0 {
-		xc.connectors = (*C.libxl_connector_param)(C.malloc(C.ulong(numConnectors) * C.sizeof_libxl_connector_param))
-		xc.num_connectors = C.int(numConnectors)
-		cConnectors := (*[1 << 28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors]
-		for i, v := range x.Connectors {
-			if err := v.toC(&cConnectors[i]); err != nil {
-				return fmt.Errorf("converting field Connectors: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewVsndParams returns an instance of VsndParams initialized with defaults.
-func NewVsndParams() (*VsndParams, error) {
-	var (
-		x  VsndParams
-		xc C.libxl_vsnd_params
-	)
-
-	C.libxl_vsnd_params_init(&xc)
-	defer C.libxl_vsnd_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VsndParams) fromC(xc *C.libxl_vsnd_params) error {
-	numSampleRates := int(xc.num_sample_rates)
-	cSampleRates := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:numSampleRates:numSampleRates]
-	x.SampleRates = make([]uint32, numSampleRates)
-	for i, v := range cSampleRates {
-		x.SampleRates[i] = uint32(v)
-	}
-	numSampleFormats := int(xc.num_sample_formats)
-	cSampleFormats := (*[1 << 28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:numSampleFormats:numSampleFormats]
-	x.SampleFormats = make([]VsndPcmFormat, numSampleFormats)
-	for i, v := range cSampleFormats {
-		x.SampleFormats[i] = VsndPcmFormat(v)
-	}
-	x.ChannelsMin = uint32(xc.channels_min)
-	x.ChannelsMax = uint32(xc.channels_max)
-	x.BufferSize = uint32(xc.buffer_size)
-
-	return nil
-}
-
-func (x *VsndParams) toC(xc *C.libxl_vsnd_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vsnd_params_dispose(xc)
-		}
-	}()
-
-	if numSampleRates := len(x.SampleRates); numSampleRates > 0 {
-		xc.sample_rates = (*C.uint32_t)(C.malloc(C.size_t(numSampleRates * numSampleRates)))
-		xc.num_sample_rates = C.int(numSampleRates)
-		cSampleRates := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:numSampleRates:numSampleRates]
-		for i, v := range x.SampleRates {
-			cSampleRates[i] = C.uint32_t(v)
-		}
-	}
-	if numSampleFormats := len(x.SampleFormats); numSampleFormats > 0 {
-		xc.sample_formats = (*C.libxl_vsnd_pcm_format)(C.malloc(C.size_t(numSampleFormats * numSampleFormats)))
-		xc.num_sample_formats = C.int(numSampleFormats)
-		cSampleFormats := (*[1 << 28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:numSampleFormats:numSampleFormats]
-		for i, v := range x.SampleFormats {
-			cSampleFormats[i] = C.libxl_vsnd_pcm_format(v)
-		}
-	}
-	xc.channels_min = C.uint32_t(x.ChannelsMin)
-	xc.channels_max = C.uint32_t(x.ChannelsMax)
-	xc.buffer_size = C.uint32_t(x.BufferSize)
-
-	return nil
-}
-
-// NewVsndStream returns an instance of VsndStream initialized with defaults.
-func NewVsndStream() (*VsndStream, error) {
-	var (
-		x  VsndStream
-		xc C.libxl_vsnd_stream
-	)
-
-	C.libxl_vsnd_stream_init(&xc)
-	defer C.libxl_vsnd_stream_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VsndStream) fromC(xc *C.libxl_vsnd_stream) error {
-	x.UniqueId = C.GoString(xc.unique_id)
-	x.Type = VsndStreamType(xc._type)
-	if err := x.Params.fromC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-
-	return nil
-}
-
-func (x *VsndStream) toC(xc *C.libxl_vsnd_stream) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vsnd_stream_dispose(xc)
-		}
-	}()
-
-	if x.UniqueId != "" {
-		xc.unique_id = C.CString(x.UniqueId)
-	}
-	xc._type = C.libxl_vsnd_stream_type(x.Type)
-	if err := x.Params.toC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-
-	return nil
-}
-
-// NewVsndPcm returns an instance of VsndPcm initialized with defaults.
-func NewVsndPcm() (*VsndPcm, error) {
-	var (
-		x  VsndPcm
-		xc C.libxl_vsnd_pcm
-	)
-
-	C.libxl_vsnd_pcm_init(&xc)
-	defer C.libxl_vsnd_pcm_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VsndPcm) fromC(xc *C.libxl_vsnd_pcm) error {
-	x.Name = C.GoString(xc.name)
-	if err := x.Params.fromC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-	numVsndStreams := int(xc.num_vsnd_streams)
-	cStreams := (*[1 << 28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams]
-	x.Streams = make([]VsndStream, numVsndStreams)
-	for i, v := range cStreams {
-		if err := x.Streams[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Streams: %v", err)
-		}
-	}
-
-	return nil
-}
-
-func (x *VsndPcm) toC(xc *C.libxl_vsnd_pcm) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vsnd_pcm_dispose(xc)
-		}
-	}()
-
-	if x.Name != "" {
-		xc.name = C.CString(x.Name)
-	}
-	if err := x.Params.toC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-	if numVsndStreams := len(x.Streams); numVsndStreams > 0 {
-		xc.streams = (*C.libxl_vsnd_stream)(C.malloc(C.ulong(numVsndStreams) * C.sizeof_libxl_vsnd_stream))
-		xc.num_vsnd_streams = C.int(numVsndStreams)
-		cStreams := (*[1 << 28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams]
-		for i, v := range x.Streams {
-			if err := v.toC(&cStreams[i]); err != nil {
-				return fmt.Errorf("converting field Streams: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewDeviceVsnd returns an instance of DeviceVsnd initialized with defaults.
-func NewDeviceVsnd() (*DeviceVsnd, error) {
-	var (
-		x  DeviceVsnd
-		xc C.libxl_device_vsnd
-	)
-
-	C.libxl_device_vsnd_init(&xc)
-	defer C.libxl_device_vsnd_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVsnd) fromC(xc *C.libxl_device_vsnd) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.ShortName = C.GoString(xc.short_name)
-	x.LongName = C.GoString(xc.long_name)
-	if err := x.Params.fromC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-	numVsndPcms := int(xc.num_vsnd_pcms)
-	cPcms := (*[1 << 28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms]
-	x.Pcms = make([]VsndPcm, numVsndPcms)
-	for i, v := range cPcms {
-		if err := x.Pcms[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Pcms: %v", err)
-		}
-	}
-
-	return nil
-}
-
-func (x *DeviceVsnd) toC(xc *C.libxl_device_vsnd) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vsnd_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	if x.ShortName != "" {
-		xc.short_name = C.CString(x.ShortName)
-	}
-	if x.LongName != "" {
-		xc.long_name = C.CString(x.LongName)
-	}
-	if err := x.Params.toC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-	if numVsndPcms := len(x.Pcms); numVsndPcms > 0 {
-		xc.pcms = (*C.libxl_vsnd_pcm)(C.malloc(C.ulong(numVsndPcms) * C.sizeof_libxl_vsnd_pcm))
-		xc.num_vsnd_pcms = C.int(numVsndPcms)
-		cPcms := (*[1 << 28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms]
-		for i, v := range x.Pcms {
-			if err := v.toC(&cPcms[i]); err != nil {
-				return fmt.Errorf("converting field Pcms: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewDomainConfig returns an instance of DomainConfig initialized with defaults.
-func NewDomainConfig() (*DomainConfig, error) {
-	var (
-		x  DomainConfig
-		xc C.libxl_domain_config
-	)
-
-	C.libxl_domain_config_init(&xc)
-	defer C.libxl_domain_config_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainConfig) fromC(xc *C.libxl_domain_config) error {
-	if err := x.CInfo.fromC(&xc.c_info); err != nil {
-		return fmt.Errorf("converting field CInfo: %v", err)
-	}
-	if err := x.BInfo.fromC(&xc.b_info); err != nil {
-		return fmt.Errorf("converting field BInfo: %v", err)
-	}
-	numDisks := int(xc.num_disks)
-	cDisks := (*[1 << 28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:numDisks:numDisks]
-	x.Disks = make([]DeviceDisk, numDisks)
-	for i, v := range cDisks {
-		if err := x.Disks[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Disks: %v", err)
-		}
-	}
-	numNics := int(xc.num_nics)
-	cNics := (*[1 << 28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:numNics:numNics]
-	x.Nics = make([]DeviceNic, numNics)
-	for i, v := range cNics {
-		if err := x.Nics[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Nics: %v", err)
-		}
-	}
-	numPcidevs := int(xc.num_pcidevs)
-	cPcidevs := (*[1 << 28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:numPcidevs:numPcidevs]
-	x.Pcidevs = make([]DevicePci, numPcidevs)
-	for i, v := range cPcidevs {
-		if err := x.Pcidevs[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Pcidevs: %v", err)
-		}
-	}
-	numRdms := int(xc.num_rdms)
-	cRdms := (*[1 << 28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:numRdms:numRdms]
-	x.Rdms = make([]DeviceRdm, numRdms)
-	for i, v := range cRdms {
-		if err := x.Rdms[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Rdms: %v", err)
-		}
-	}
-	numDtdevs := int(xc.num_dtdevs)
-	cDtdevs := (*[1 << 28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:numDtdevs:numDtdevs]
-	x.Dtdevs = make([]DeviceDtdev, numDtdevs)
-	for i, v := range cDtdevs {
-		if err := x.Dtdevs[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Dtdevs: %v", err)
-		}
-	}
-	numVfbs := int(xc.num_vfbs)
-	cVfbs := (*[1 << 28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:numVfbs:numVfbs]
-	x.Vfbs = make([]DeviceVfb, numVfbs)
-	for i, v := range cVfbs {
-		if err := x.Vfbs[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Vfbs: %v", err)
-		}
-	}
-	numVkbs := int(xc.num_vkbs)
-	cVkbs := (*[1 << 28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:numVkbs:numVkbs]
-	x.Vkbs = make([]DeviceVkb, numVkbs)
-	for i, v := range cVkbs {
-		if err := x.Vkbs[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Vkbs: %v", err)
-		}
-	}
-	numVtpms := int(xc.num_vtpms)
-	cVtpms := (*[1 << 28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:numVtpms:numVtpms]
-	x.Vtpms = make([]DeviceVtpm, numVtpms)
-	for i, v := range cVtpms {
-		if err := x.Vtpms[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Vtpms: %v", err)
-		}
-	}
-	numP9S := int(xc.num_p9s)
-	cP9S := (*[1 << 28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:numP9S:numP9S]
-	x.P9S = make([]DeviceP9, numP9S)
-	for i, v := range cP9S {
-		if err := x.P9S[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field P9S: %v", err)
-		}
-	}
-	numPvcallsifs := int(xc.num_pvcallsifs)
-	cPvcallsifs := (*[1 << 28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:numPvcallsifs:numPvcallsifs]
-	x.Pvcallsifs = make([]DevicePvcallsif, numPvcallsifs)
-	for i, v := range cPvcallsifs {
-		if err := x.Pvcallsifs[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Pvcallsifs: %v", err)
-		}
-	}
-	numVdispls := int(xc.num_vdispls)
-	cVdispls := (*[1 << 28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:numVdispls:numVdispls]
-	x.Vdispls = make([]DeviceVdispl, numVdispls)
-	for i, v := range cVdispls {
-		if err := x.Vdispls[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Vdispls: %v", err)
-		}
-	}
-	numVsnds := int(xc.num_vsnds)
-	cVsnds := (*[1 << 28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:numVsnds:numVsnds]
-	x.Vsnds = make([]DeviceVsnd, numVsnds)
-	for i, v := range cVsnds {
-		if err := x.Vsnds[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Vsnds: %v", err)
-		}
-	}
-	numChannels := int(xc.num_channels)
-	cChannels := (*[1 << 28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:numChannels:numChannels]
-	x.Channels = make([]DeviceChannel, numChannels)
-	for i, v := range cChannels {
-		if err := x.Channels[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Channels: %v", err)
-		}
-	}
-	numUsbctrls := int(xc.num_usbctrls)
-	cUsbctrls := (*[1 << 28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:numUsbctrls:numUsbctrls]
-	x.Usbctrls = make([]DeviceUsbctrl, numUsbctrls)
-	for i, v := range cUsbctrls {
-		if err := x.Usbctrls[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Usbctrls: %v", err)
-		}
-	}
-	numUsbdevs := int(xc.num_usbdevs)
-	cUsbdevs := (*[1 << 28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:numUsbdevs:numUsbdevs]
-	x.Usbdevs = make([]DeviceUsbdev, numUsbdevs)
-	for i, v := range cUsbdevs {
-		if err := x.Usbdevs[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Usbdevs: %v", err)
-		}
-	}
-	x.OnPoweroff = ActionOnShutdown(xc.on_poweroff)
-	x.OnReboot = ActionOnShutdown(xc.on_reboot)
-	x.OnWatchdog = ActionOnShutdown(xc.on_watchdog)
-	x.OnCrash = ActionOnShutdown(xc.on_crash)
-	x.OnSoftReset = ActionOnShutdown(xc.on_soft_reset)
-
-	return nil
-}
-
-func (x *DomainConfig) toC(xc *C.libxl_domain_config) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_config_dispose(xc)
-		}
-	}()
-
-	if err := x.CInfo.toC(&xc.c_info); err != nil {
-		return fmt.Errorf("converting field CInfo: %v", err)
-	}
-	if err := x.BInfo.toC(&xc.b_info); err != nil {
-		return fmt.Errorf("converting field BInfo: %v", err)
-	}
-	if numDisks := len(x.Disks); numDisks > 0 {
-		xc.disks = (*C.libxl_device_disk)(C.malloc(C.ulong(numDisks) * C.sizeof_libxl_device_disk))
-		xc.num_disks = C.int(numDisks)
-		cDisks := (*[1 << 28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:numDisks:numDisks]
-		for i, v := range x.Disks {
-			if err := v.toC(&cDisks[i]); err != nil {
-				return fmt.Errorf("converting field Disks: %v", err)
-			}
-		}
-	}
-	if numNics := len(x.Nics); numNics > 0 {
-		xc.nics = (*C.libxl_device_nic)(C.malloc(C.ulong(numNics) * C.sizeof_libxl_device_nic))
-		xc.num_nics = C.int(numNics)
-		cNics := (*[1 << 28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:numNics:numNics]
-		for i, v := range x.Nics {
-			if err := v.toC(&cNics[i]); err != nil {
-				return fmt.Errorf("converting field Nics: %v", err)
-			}
-		}
-	}
-	if numPcidevs := len(x.Pcidevs); numPcidevs > 0 {
-		xc.pcidevs = (*C.libxl_device_pci)(C.malloc(C.ulong(numPcidevs) * C.sizeof_libxl_device_pci))
-		xc.num_pcidevs = C.int(numPcidevs)
-		cPcidevs := (*[1 << 28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:numPcidevs:numPcidevs]
-		for i, v := range x.Pcidevs {
-			if err := v.toC(&cPcidevs[i]); err != nil {
-				return fmt.Errorf("converting field Pcidevs: %v", err)
-			}
-		}
-	}
-	if numRdms := len(x.Rdms); numRdms > 0 {
-		xc.rdms = (*C.libxl_device_rdm)(C.malloc(C.ulong(numRdms) * C.sizeof_libxl_device_rdm))
-		xc.num_rdms = C.int(numRdms)
-		cRdms := (*[1 << 28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:numRdms:numRdms]
-		for i, v := range x.Rdms {
-			if err := v.toC(&cRdms[i]); err != nil {
-				return fmt.Errorf("converting field Rdms: %v", err)
-			}
-		}
-	}
-	if numDtdevs := len(x.Dtdevs); numDtdevs > 0 {
-		xc.dtdevs = (*C.libxl_device_dtdev)(C.malloc(C.ulong(numDtdevs) * C.sizeof_libxl_device_dtdev))
-		xc.num_dtdevs = C.int(numDtdevs)
-		cDtdevs := (*[1 << 28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:numDtdevs:numDtdevs]
-		for i, v := range x.Dtdevs {
-			if err := v.toC(&cDtdevs[i]); err != nil {
-				return fmt.Errorf("converting field Dtdevs: %v", err)
-			}
-		}
-	}
-	if numVfbs := len(x.Vfbs); numVfbs > 0 {
-		xc.vfbs = (*C.libxl_device_vfb)(C.malloc(C.ulong(numVfbs) * C.sizeof_libxl_device_vfb))
-		xc.num_vfbs = C.int(numVfbs)
-		cVfbs := (*[1 << 28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:numVfbs:numVfbs]
-		for i, v := range x.Vfbs {
-			if err := v.toC(&cVfbs[i]); err != nil {
-				return fmt.Errorf("converting field Vfbs: %v", err)
-			}
-		}
-	}
-	if numVkbs := len(x.Vkbs); numVkbs > 0 {
-		xc.vkbs = (*C.libxl_device_vkb)(C.malloc(C.ulong(numVkbs) * C.sizeof_libxl_device_vkb))
-		xc.num_vkbs = C.int(numVkbs)
-		cVkbs := (*[1 << 28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:numVkbs:numVkbs]
-		for i, v := range x.Vkbs {
-			if err := v.toC(&cVkbs[i]); err != nil {
-				return fmt.Errorf("converting field Vkbs: %v", err)
-			}
-		}
-	}
-	if numVtpms := len(x.Vtpms); numVtpms > 0 {
-		xc.vtpms = (*C.libxl_device_vtpm)(C.malloc(C.ulong(numVtpms) * C.sizeof_libxl_device_vtpm))
-		xc.num_vtpms = C.int(numVtpms)
-		cVtpms := (*[1 << 28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:numVtpms:numVtpms]
-		for i, v := range x.Vtpms {
-			if err := v.toC(&cVtpms[i]); err != nil {
-				return fmt.Errorf("converting field Vtpms: %v", err)
-			}
-		}
-	}
-	if numP9S := len(x.P9S); numP9S > 0 {
-		xc.p9s = (*C.libxl_device_p9)(C.malloc(C.ulong(numP9S) * C.sizeof_libxl_device_p9))
-		xc.num_p9s = C.int(numP9S)
-		cP9S := (*[1 << 28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:numP9S:numP9S]
-		for i, v := range x.P9S {
-			if err := v.toC(&cP9S[i]); err != nil {
-				return fmt.Errorf("converting field P9S: %v", err)
-			}
-		}
-	}
-	if numPvcallsifs := len(x.Pvcallsifs); numPvcallsifs > 0 {
-		xc.pvcallsifs = (*C.libxl_device_pvcallsif)(C.malloc(C.ulong(numPvcallsifs) * C.sizeof_libxl_device_pvcallsif))
-		xc.num_pvcallsifs = C.int(numPvcallsifs)
-		cPvcallsifs := (*[1 << 28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:numPvcallsifs:numPvcallsifs]
-		for i, v := range x.Pvcallsifs {
-			if err := v.toC(&cPvcallsifs[i]); err != nil {
-				return fmt.Errorf("converting field Pvcallsifs: %v", err)
-			}
-		}
-	}
-	if numVdispls := len(x.Vdispls); numVdispls > 0 {
-		xc.vdispls = (*C.libxl_device_vdispl)(C.malloc(C.ulong(numVdispls) * C.sizeof_libxl_device_vdispl))
-		xc.num_vdispls = C.int(numVdispls)
-		cVdispls := (*[1 << 28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:numVdispls:numVdispls]
-		for i, v := range x.Vdispls {
-			if err := v.toC(&cVdispls[i]); err != nil {
-				return fmt.Errorf("converting field Vdispls: %v", err)
-			}
-		}
-	}
-	if numVsnds := len(x.Vsnds); numVsnds > 0 {
-		xc.vsnds = (*C.libxl_device_vsnd)(C.malloc(C.ulong(numVsnds) * C.sizeof_libxl_device_vsnd))
-		xc.num_vsnds = C.int(numVsnds)
-		cVsnds := (*[1 << 28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:numVsnds:numVsnds]
-		for i, v := range x.Vsnds {
-			if err := v.toC(&cVsnds[i]); err != nil {
-				return fmt.Errorf("converting field Vsnds: %v", err)
-			}
-		}
-	}
-	if numChannels := len(x.Channels); numChannels > 0 {
-		xc.channels = (*C.libxl_device_channel)(C.malloc(C.ulong(numChannels) * C.sizeof_libxl_device_channel))
-		xc.num_channels = C.int(numChannels)
-		cChannels := (*[1 << 28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:numChannels:numChannels]
-		for i, v := range x.Channels {
-			if err := v.toC(&cChannels[i]); err != nil {
-				return fmt.Errorf("converting field Channels: %v", err)
-			}
-		}
-	}
-	if numUsbctrls := len(x.Usbctrls); numUsbctrls > 0 {
-		xc.usbctrls = (*C.libxl_device_usbctrl)(C.malloc(C.ulong(numUsbctrls) * C.sizeof_libxl_device_usbctrl))
-		xc.num_usbctrls = C.int(numUsbctrls)
-		cUsbctrls := (*[1 << 28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:numUsbctrls:numUsbctrls]
-		for i, v := range x.Usbctrls {
-			if err := v.toC(&cUsbctrls[i]); err != nil {
-				return fmt.Errorf("converting field Usbctrls: %v", err)
-			}
-		}
-	}
-	if numUsbdevs := len(x.Usbdevs); numUsbdevs > 0 {
-		xc.usbdevs = (*C.libxl_device_usbdev)(C.malloc(C.ulong(numUsbdevs) * C.sizeof_libxl_device_usbdev))
-		xc.num_usbdevs = C.int(numUsbdevs)
-		cUsbdevs := (*[1 << 28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:numUsbdevs:numUsbdevs]
-		for i, v := range x.Usbdevs {
-			if err := v.toC(&cUsbdevs[i]); err != nil {
-				return fmt.Errorf("converting field Usbdevs: %v", err)
-			}
-		}
-	}
-	xc.on_poweroff = C.libxl_action_on_shutdown(x.OnPoweroff)
-	xc.on_reboot = C.libxl_action_on_shutdown(x.OnReboot)
-	xc.on_watchdog = C.libxl_action_on_shutdown(x.OnWatchdog)
-	xc.on_crash = C.libxl_action_on_shutdown(x.OnCrash)
-	xc.on_soft_reset = C.libxl_action_on_shutdown(x.OnSoftReset)
-
-	return nil
-}
-
-// NewDiskinfo returns an instance of Diskinfo initialized with defaults.
-func NewDiskinfo() (*Diskinfo, error) {
-	var (
-		x  Diskinfo
-		xc C.libxl_diskinfo
-	)
-
-	C.libxl_diskinfo_init(&xc)
-	defer C.libxl_diskinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Diskinfo) fromC(xc *C.libxl_diskinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.Rref = int(xc.rref)
-
-	return nil
-}
-
-func (x *Diskinfo) toC(xc *C.libxl_diskinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_diskinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref = C.int(x.Rref)
-
-	return nil
-}
-
-// NewNicinfo returns an instance of Nicinfo initialized with defaults.
-func NewNicinfo() (*Nicinfo, error) {
-	var (
-		x  Nicinfo
-		xc C.libxl_nicinfo
-	)
-
-	C.libxl_nicinfo_init(&xc)
-	defer C.libxl_nicinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Nicinfo) fromC(xc *C.libxl_nicinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.RrefTx = int(xc.rref_tx)
-	x.RrefRx = int(xc.rref_rx)
-
-	return nil
-}
-
-func (x *Nicinfo) toC(xc *C.libxl_nicinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_nicinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref_tx = C.int(x.RrefTx)
-	xc.rref_rx = C.int(x.RrefRx)
-
-	return nil
-}
-
-// NewVtpminfo returns an instance of Vtpminfo initialized with defaults.
-func NewVtpminfo() (*Vtpminfo, error) {
-	var (
-		x  Vtpminfo
-		xc C.libxl_vtpminfo
-	)
-
-	C.libxl_vtpminfo_init(&xc)
-	defer C.libxl_vtpminfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vtpminfo) fromC(xc *C.libxl_vtpminfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.Rref = int(xc.rref)
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-
-	return nil
-}
-
-func (x *Vtpminfo) toC(xc *C.libxl_vtpminfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vtpminfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref = C.int(x.Rref)
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-
-	return nil
-}
-
-// NewUsbctrlinfo returns an instance of Usbctrlinfo initialized with defaults.
-func NewUsbctrlinfo() (*Usbctrlinfo, error) {
-	var (
-		x  Usbctrlinfo
-		xc C.libxl_usbctrlinfo
-	)
-
-	C.libxl_usbctrlinfo_init(&xc)
-	defer C.libxl_usbctrlinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Usbctrlinfo) fromC(xc *C.libxl_usbctrlinfo) error {
-	x.Type = UsbctrlType(xc._type)
-	x.Devid = Devid(xc.devid)
-	x.Version = int(xc.version)
-	x.Ports = int(xc.ports)
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.RefUrb = int(xc.ref_urb)
-	x.RefConn = int(xc.ref_conn)
-
-	return nil
-}
-
-func (x *Usbctrlinfo) toC(xc *C.libxl_usbctrlinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_usbctrlinfo_dispose(xc)
-		}
-	}()
-
-	xc._type = C.libxl_usbctrl_type(x.Type)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.version = C.int(x.Version)
-	xc.ports = C.int(x.Ports)
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.ref_urb = C.int(x.RefUrb)
-	xc.ref_conn = C.int(x.RefConn)
-
-	return nil
-}
-
-// NewVcpuinfo returns an instance of Vcpuinfo initialized with defaults.
-func NewVcpuinfo() (*Vcpuinfo, error) {
-	var (
-		x  Vcpuinfo
-		xc C.libxl_vcpuinfo
-	)
-
-	C.libxl_vcpuinfo_init(&xc)
-	defer C.libxl_vcpuinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vcpuinfo) fromC(xc *C.libxl_vcpuinfo) error {
-	x.Vcpuid = uint32(xc.vcpuid)
-	x.Cpu = uint32(xc.cpu)
-	x.Online = bool(xc.online)
-	x.Blocked = bool(xc.blocked)
-	x.Running = bool(xc.running)
-	x.VcpuTime = uint64(xc.vcpu_time)
-	if err := x.Cpumap.fromC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-	if err := x.CpumapSoft.fromC(&xc.cpumap_soft); err != nil {
-		return fmt.Errorf("converting field CpumapSoft: %v", err)
-	}
-
-	return nil
-}
-
-func (x *Vcpuinfo) toC(xc *C.libxl_vcpuinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vcpuinfo_dispose(xc)
-		}
-	}()
-
-	xc.vcpuid = C.uint32_t(x.Vcpuid)
-	xc.cpu = C.uint32_t(x.Cpu)
-	xc.online = C.bool(x.Online)
-	xc.blocked = C.bool(x.Blocked)
-	xc.running = C.bool(x.Running)
-	xc.vcpu_time = C.uint64_t(x.VcpuTime)
-	if err := x.Cpumap.toC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-	if err := x.CpumapSoft.toC(&xc.cpumap_soft); err != nil {
-		return fmt.Errorf("converting field CpumapSoft: %v", err)
-	}
-
-	return nil
-}
-
-// NewPhysinfo returns an instance of Physinfo initialized with defaults.
-func NewPhysinfo() (*Physinfo, error) {
-	var (
-		x  Physinfo
-		xc C.libxl_physinfo
-	)
-
-	C.libxl_physinfo_init(&xc)
-	defer C.libxl_physinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Physinfo) fromC(xc *C.libxl_physinfo) error {
-	x.ThreadsPerCore = uint32(xc.threads_per_core)
-	x.CoresPerSocket = uint32(xc.cores_per_socket)
-	x.MaxCpuId = uint32(xc.max_cpu_id)
-	x.NrCpus = uint32(xc.nr_cpus)
-	x.CpuKhz = uint32(xc.cpu_khz)
-	x.TotalPages = uint64(xc.total_pages)
-	x.FreePages = uint64(xc.free_pages)
-	x.ScrubPages = uint64(xc.scrub_pages)
-	x.OutstandingPages = uint64(xc.outstanding_pages)
-	x.SharingFreedPages = uint64(xc.sharing_freed_pages)
-	x.SharingUsedFrames = uint64(xc.sharing_used_frames)
-	x.MaxPossibleMfn = uint64(xc.max_possible_mfn)
-	x.NrNodes = uint32(xc.nr_nodes)
-	if err := x.HwCap.fromC(&xc.hw_cap); err != nil {
-		return fmt.Errorf("converting field HwCap: %v", err)
-	}
-	x.CapHvm = bool(xc.cap_hvm)
-	x.CapPv = bool(xc.cap_pv)
-	x.CapHvmDirectio = bool(xc.cap_hvm_directio)
-	x.CapHap = bool(xc.cap_hap)
-	x.CapShadow = bool(xc.cap_shadow)
-	x.CapIommuHapPtShare = bool(xc.cap_iommu_hap_pt_share)
-
-	return nil
-}
-
-func (x *Physinfo) toC(xc *C.libxl_physinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_physinfo_dispose(xc)
-		}
-	}()
-
-	xc.threads_per_core = C.uint32_t(x.ThreadsPerCore)
-	xc.cores_per_socket = C.uint32_t(x.CoresPerSocket)
-	xc.max_cpu_id = C.uint32_t(x.MaxCpuId)
-	xc.nr_cpus = C.uint32_t(x.NrCpus)
-	xc.cpu_khz = C.uint32_t(x.CpuKhz)
-	xc.total_pages = C.uint64_t(x.TotalPages)
-	xc.free_pages = C.uint64_t(x.FreePages)
-	xc.scrub_pages = C.uint64_t(x.ScrubPages)
-	xc.outstanding_pages = C.uint64_t(x.OutstandingPages)
-	xc.sharing_freed_pages = C.uint64_t(x.SharingFreedPages)
-	xc.sharing_used_frames = C.uint64_t(x.SharingUsedFrames)
-	xc.max_possible_mfn = C.uint64_t(x.MaxPossibleMfn)
-	xc.nr_nodes = C.uint32_t(x.NrNodes)
-	if err := x.HwCap.toC(&xc.hw_cap); err != nil {
-		return fmt.Errorf("converting field HwCap: %v", err)
-	}
-	xc.cap_hvm = C.bool(x.CapHvm)
-	xc.cap_pv = C.bool(x.CapPv)
-	xc.cap_hvm_directio = C.bool(x.CapHvmDirectio)
-	xc.cap_hap = C.bool(x.CapHap)
-	xc.cap_shadow = C.bool(x.CapShadow)
-	xc.cap_iommu_hap_pt_share = C.bool(x.CapIommuHapPtShare)
-
-	return nil
-}
-
-// NewConnectorinfo returns an instance of Connectorinfo initialized with defaults.
-func NewConnectorinfo() (*Connectorinfo, error) {
-	var (
-		x  Connectorinfo
-		xc C.libxl_connectorinfo
-	)
-
-	C.libxl_connectorinfo_init(&xc)
-	defer C.libxl_connectorinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Connectorinfo) fromC(xc *C.libxl_connectorinfo) error {
-	x.UniqueId = C.GoString(xc.unique_id)
-	x.Width = uint32(xc.width)
-	x.Height = uint32(xc.height)
-	x.ReqEvtch = int(xc.req_evtch)
-	x.ReqRref = int(xc.req_rref)
-	x.EvtEvtch = int(xc.evt_evtch)
-	x.EvtRref = int(xc.evt_rref)
-
-	return nil
-}
-
-func (x *Connectorinfo) toC(xc *C.libxl_connectorinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_connectorinfo_dispose(xc)
-		}
-	}()
-
-	if x.UniqueId != "" {
-		xc.unique_id = C.CString(x.UniqueId)
-	}
-	xc.width = C.uint32_t(x.Width)
-	xc.height = C.uint32_t(x.Height)
-	xc.req_evtch = C.int(x.ReqEvtch)
-	xc.req_rref = C.int(x.ReqRref)
-	xc.evt_evtch = C.int(x.EvtEvtch)
-	xc.evt_rref = C.int(x.EvtRref)
-
-	return nil
-}
-
-// NewVdisplinfo returns an instance of Vdisplinfo initialized with defaults.
-func NewVdisplinfo() (*Vdisplinfo, error) {
-	var (
-		x  Vdisplinfo
-		xc C.libxl_vdisplinfo
-	)
-
-	C.libxl_vdisplinfo_init(&xc)
-	defer C.libxl_vdisplinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vdisplinfo) fromC(xc *C.libxl_vdisplinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.BeAlloc = bool(xc.be_alloc)
-	numConnectors := int(xc.num_connectors)
-	cConnectors := (*[1 << 28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors]
-	x.Connectors = make([]Connectorinfo, numConnectors)
-	for i, v := range cConnectors {
-		if err := x.Connectors[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Connectors: %v", err)
-		}
-	}
-
-	return nil
-}
-
-func (x *Vdisplinfo) toC(xc *C.libxl_vdisplinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vdisplinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.be_alloc = C.bool(x.BeAlloc)
-	if numConnectors := len(x.Connectors); numConnectors > 0 {
-		xc.connectors = (*C.libxl_connectorinfo)(C.malloc(C.ulong(numConnectors) * C.sizeof_libxl_connectorinfo))
-		xc.num_connectors = C.int(numConnectors)
-		cConnectors := (*[1 << 28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors]
-		for i, v := range x.Connectors {
-			if err := v.toC(&cConnectors[i]); err != nil {
-				return fmt.Errorf("converting field Connectors: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewStreaminfo returns an instance of Streaminfo initialized with defaults.
-func NewStreaminfo() (*Streaminfo, error) {
-	var (
-		x  Streaminfo
-		xc C.libxl_streaminfo
-	)
-
-	C.libxl_streaminfo_init(&xc)
-	defer C.libxl_streaminfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Streaminfo) fromC(xc *C.libxl_streaminfo) error {
-	x.ReqEvtch = int(xc.req_evtch)
-	x.ReqRref = int(xc.req_rref)
-
-	return nil
-}
-
-func (x *Streaminfo) toC(xc *C.libxl_streaminfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_streaminfo_dispose(xc)
-		}
-	}()
-
-	xc.req_evtch = C.int(x.ReqEvtch)
-	xc.req_rref = C.int(x.ReqRref)
-
-	return nil
-}
-
-// NewPcminfo returns an instance of Pcminfo initialized with defaults.
-func NewPcminfo() (*Pcminfo, error) {
-	var (
-		x  Pcminfo
-		xc C.libxl_pcminfo
-	)
-
-	C.libxl_pcminfo_init(&xc)
-	defer C.libxl_pcminfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Pcminfo) fromC(xc *C.libxl_pcminfo) error {
-	numVsndStreams := int(xc.num_vsnd_streams)
-	cStreams := (*[1 << 28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams]
-	x.Streams = make([]Streaminfo, numVsndStreams)
-	for i, v := range cStreams {
-		if err := x.Streams[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Streams: %v", err)
-		}
-	}
-
-	return nil
-}
-
-func (x *Pcminfo) toC(xc *C.libxl_pcminfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_pcminfo_dispose(xc)
-		}
-	}()
-
-	if numVsndStreams := len(x.Streams); numVsndStreams > 0 {
-		xc.streams = (*C.libxl_streaminfo)(C.malloc(C.ulong(numVsndStreams) * C.sizeof_libxl_streaminfo))
-		xc.num_vsnd_streams = C.int(numVsndStreams)
-		cStreams := (*[1 << 28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams]
-		for i, v := range x.Streams {
-			if err := v.toC(&cStreams[i]); err != nil {
-				return fmt.Errorf("converting field Streams: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewVsndinfo returns an instance of Vsndinfo initialized with defaults.
-func NewVsndinfo() (*Vsndinfo, error) {
-	var (
-		x  Vsndinfo
-		xc C.libxl_vsndinfo
-	)
-
-	C.libxl_vsndinfo_init(&xc)
-	defer C.libxl_vsndinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vsndinfo) fromC(xc *C.libxl_vsndinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	numVsndPcms := int(xc.num_vsnd_pcms)
-	cPcms := (*[1 << 28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms]
-	x.Pcms = make([]Pcminfo, numVsndPcms)
-	for i, v := range cPcms {
-		if err := x.Pcms[i].fromC(&v); err != nil {
-			return fmt.Errorf("converting field Pcms: %v", err)
-		}
-	}
-
-	return nil
-}
-
-func (x *Vsndinfo) toC(xc *C.libxl_vsndinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vsndinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	if numVsndPcms := len(x.Pcms); numVsndPcms > 0 {
-		xc.pcms = (*C.libxl_pcminfo)(C.malloc(C.ulong(numVsndPcms) * C.sizeof_libxl_pcminfo))
-		xc.num_vsnd_pcms = C.int(numVsndPcms)
-		cPcms := (*[1 << 28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms]
-		for i, v := range x.Pcms {
-			if err := v.toC(&cPcms[i]); err != nil {
-				return fmt.Errorf("converting field Pcms: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewVkbinfo returns an instance of Vkbinfo initialized with defaults.
-func NewVkbinfo() (*Vkbinfo, error) {
-	var (
-		x  Vkbinfo
-		xc C.libxl_vkbinfo
-	)
-
-	C.libxl_vkbinfo_init(&xc)
-	defer C.libxl_vkbinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vkbinfo) fromC(xc *C.libxl_vkbinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.Rref = int(xc.rref)
-
-	return nil
-}
-
-func (x *Vkbinfo) toC(xc *C.libxl_vkbinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vkbinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref = C.int(x.Rref)
-
-	return nil
-}
-
-// NewNumainfo returns an instance of Numainfo initialized with defaults.
-func NewNumainfo() (*Numainfo, error) {
-	var (
-		x  Numainfo
-		xc C.libxl_numainfo
-	)
-
-	C.libxl_numainfo_init(&xc)
-	defer C.libxl_numainfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Numainfo) fromC(xc *C.libxl_numainfo) error {
-	x.Size = uint64(xc.size)
-	x.Free = uint64(xc.free)
-	numDists := int(xc.num_dists)
-	cDists := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.dists))[:numDists:numDists]
-	x.Dists = make([]uint32, numDists)
-	for i, v := range cDists {
-		x.Dists[i] = uint32(v)
-	}
-
-	return nil
-}
-
-func (x *Numainfo) toC(xc *C.libxl_numainfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_numainfo_dispose(xc)
-		}
-	}()
-
-	xc.size = C.uint64_t(x.Size)
-	xc.free = C.uint64_t(x.Free)
-	if numDists := len(x.Dists); numDists > 0 {
-		xc.dists = (*C.uint32_t)(C.malloc(C.size_t(numDists * numDists)))
-		xc.num_dists = C.int(numDists)
-		cDists := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.dists))[:numDists:numDists]
-		for i, v := range x.Dists {
-			cDists[i] = C.uint32_t(v)
-		}
-	}
-
-	return nil
-}
-
-// NewCputopology returns an instance of Cputopology initialized with defaults.
-func NewCputopology() (*Cputopology, error) {
-	var (
-		x  Cputopology
-		xc C.libxl_cputopology
-	)
-
-	C.libxl_cputopology_init(&xc)
-	defer C.libxl_cputopology_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Cputopology) fromC(xc *C.libxl_cputopology) error {
-	x.Core = uint32(xc.core)
-	x.Socket = uint32(xc.socket)
-	x.Node = uint32(xc.node)
-
-	return nil
-}
-
-func (x *Cputopology) toC(xc *C.libxl_cputopology) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_cputopology_dispose(xc)
-		}
-	}()
-
-	xc.core = C.uint32_t(x.Core)
-	xc.socket = C.uint32_t(x.Socket)
-	xc.node = C.uint32_t(x.Node)
-
-	return nil
-}
-
-// NewPcitopology returns an instance of Pcitopology initialized with defaults.
-func NewPcitopology() (*Pcitopology, error) {
-	var (
-		x  Pcitopology
-		xc C.libxl_pcitopology
-	)
-
-	C.libxl_pcitopology_init(&xc)
-	defer C.libxl_pcitopology_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Pcitopology) fromC(xc *C.libxl_pcitopology) error {
-	x.Seg = uint16(xc.seg)
-	x.Bus = byte(xc.bus)
-	x.Devfn = byte(xc.devfn)
-	x.Node = uint32(xc.node)
-
-	return nil
-}
-
-func (x *Pcitopology) toC(xc *C.libxl_pcitopology) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_pcitopology_dispose(xc)
-		}
-	}()
-
-	xc.seg = C.uint16_t(x.Seg)
-	xc.bus = C.uint8_t(x.Bus)
-	xc.devfn = C.uint8_t(x.Devfn)
-	xc.node = C.uint32_t(x.Node)
-
-	return nil
-}
-
-// NewSchedCreditParams returns an instance of SchedCreditParams initialized with defaults.
-func NewSchedCreditParams() (*SchedCreditParams, error) {
-	var (
-		x  SchedCreditParams
-		xc C.libxl_sched_credit_params
-	)
-
-	C.libxl_sched_credit_params_init(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SchedCreditParams) fromC(xc *C.libxl_sched_credit_params) error {
-	x.TsliceMs = int(xc.tslice_ms)
-	x.RatelimitUs = int(xc.ratelimit_us)
-	x.VcpuMigrDelayUs = int(xc.vcpu_migr_delay_us)
-
-	return nil
-}
-
-func (x *SchedCreditParams) toC(xc *C.libxl_sched_credit_params) (err error) {
-	xc.tslice_ms = C.int(x.TsliceMs)
-	xc.ratelimit_us = C.int(x.RatelimitUs)
-	xc.vcpu_migr_delay_us = C.int(x.VcpuMigrDelayUs)
-
-	return nil
-}
-
-// NewSchedCredit2Params returns an instance of SchedCredit2Params initialized with defaults.
-func NewSchedCredit2Params() (*SchedCredit2Params, error) {
-	var (
-		x  SchedCredit2Params
-		xc C.libxl_sched_credit2_params
-	)
-
-	C.libxl_sched_credit2_params_init(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SchedCredit2Params) fromC(xc *C.libxl_sched_credit2_params) error {
-	x.RatelimitUs = int(xc.ratelimit_us)
-
-	return nil
-}
-
-func (x *SchedCredit2Params) toC(xc *C.libxl_sched_credit2_params) (err error) {
-	xc.ratelimit_us = C.int(x.RatelimitUs)
-
-	return nil
-}
-
-// NewDomainRemusInfo returns an instance of DomainRemusInfo initialized with defaults.
-func NewDomainRemusInfo() (*DomainRemusInfo, error) {
-	var (
-		x  DomainRemusInfo
-		xc C.libxl_domain_remus_info
-	)
-
-	C.libxl_domain_remus_info_init(&xc)
-	defer C.libxl_domain_remus_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainRemusInfo) fromC(xc *C.libxl_domain_remus_info) error {
-	x.Interval = int(xc.interval)
-	if err := x.AllowUnsafe.fromC(&xc.allow_unsafe); err != nil {
-		return fmt.Errorf("converting field AllowUnsafe: %v", err)
-	}
-	if err := x.Blackhole.fromC(&xc.blackhole); err != nil {
-		return fmt.Errorf("converting field Blackhole: %v", err)
-	}
-	if err := x.Compression.fromC(&xc.compression); err != nil {
-		return fmt.Errorf("converting field Compression: %v", err)
-	}
-	if err := x.Netbuf.fromC(&xc.netbuf); err != nil {
-		return fmt.Errorf("converting field Netbuf: %v", err)
-	}
-	x.Netbufscript = C.GoString(xc.netbufscript)
-	if err := x.Diskbuf.fromC(&xc.diskbuf); err != nil {
-		return fmt.Errorf("converting field Diskbuf: %v", err)
-	}
-	if err := x.Colo.fromC(&xc.colo); err != nil {
-		return fmt.Errorf("converting field Colo: %v", err)
-	}
-	if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy); err != nil {
-		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
-	}
-
-	return nil
-}
-
-func (x *DomainRemusInfo) toC(xc *C.libxl_domain_remus_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_remus_info_dispose(xc)
-		}
-	}()
-
-	xc.interval = C.int(x.Interval)
-	if err := x.AllowUnsafe.toC(&xc.allow_unsafe); err != nil {
-		return fmt.Errorf("converting field AllowUnsafe: %v", err)
-	}
-	if err := x.Blackhole.toC(&xc.blackhole); err != nil {
-		return fmt.Errorf("converting field Blackhole: %v", err)
-	}
-	if err := x.Compression.toC(&xc.compression); err != nil {
-		return fmt.Errorf("converting field Compression: %v", err)
-	}
-	if err := x.Netbuf.toC(&xc.netbuf); err != nil {
-		return fmt.Errorf("converting field Netbuf: %v", err)
-	}
-	if x.Netbufscript != "" {
-		xc.netbufscript = C.CString(x.Netbufscript)
-	}
-	if err := x.Diskbuf.toC(&xc.diskbuf); err != nil {
-		return fmt.Errorf("converting field Diskbuf: %v", err)
-	}
-	if err := x.Colo.toC(&xc.colo); err != nil {
-		return fmt.Errorf("converting field Colo: %v", err)
-	}
-	if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil {
-		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
-	}
-
-	return nil
-}
-
-// NewEvent returns an instance of Event initialized with defaults.
-func NewEvent(etype EventType) (*Event, error) {
-	var (
-		x  Event
-		xc C.libxl_event
-	)
-
-	C.libxl_event_init(&xc)
-	C.libxl_event_init_type(&xc, C.libxl_event_type(etype))
-	defer C.libxl_event_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Event) fromC(xc *C.libxl_event) error {
-	if err := x.Link.fromC(&xc.link); err != nil {
-		return fmt.Errorf("converting field Link: %v", err)
-	}
-	x.Domid = Domid(xc.domid)
-	if err := x.Domuuid.fromC(&xc.domuuid); err != nil {
-		return fmt.Errorf("converting field Domuuid: %v", err)
-	}
-	x.ForUser = uint64(xc.for_user)
-	x.Type = EventType(xc._type)
-	switch x.Type {
-	case EventTypeDomainShutdown:
-		var typeDomainShutdown EventTypeUnionDomainShutdown
-		if err := typeDomainShutdown.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeDomainShutdown: %v", err)
-		}
-		x.TypeUnion = typeDomainShutdown
-	case EventTypeDomainDeath:
-		x.TypeUnion = nil
-	case EventTypeDiskEject:
-		var typeDiskEject EventTypeUnionDiskEject
-		if err := typeDiskEject.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeDiskEject: %v", err)
-		}
-		x.TypeUnion = typeDiskEject
-	case EventTypeOperationComplete:
-		var typeOperationComplete EventTypeUnionOperationComplete
-		if err := typeOperationComplete.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeOperationComplete: %v", err)
-		}
-		x.TypeUnion = typeOperationComplete
-	case EventTypeDomainCreateConsoleAvailable:
-		x.TypeUnion = nil
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-func (x *EventTypeUnionDomainShutdown) fromC(xc *C.libxl_event) error {
-	if EventType(xc._type) != EventTypeDomainShutdown {
-		return errors.New("expected union key EventTypeDomainShutdown")
-	}
-
-	tmp := (*C.libxl_event_type_union_domain_shutdown)(unsafe.Pointer(&xc.u[0]))
-	x.ShutdownReason = byte(tmp.shutdown_reason)
-	return nil
-}
-
-func (x *EventTypeUnionDiskEject) fromC(xc *C.libxl_event) error {
-	if EventType(xc._type) != EventTypeDiskEject {
-		return errors.New("expected union key EventTypeDiskEject")
-	}
-
-	tmp := (*C.libxl_event_type_union_disk_eject)(unsafe.Pointer(&xc.u[0]))
-	x.Vdev = C.GoString(tmp.vdev)
-	if err := x.Disk.fromC(&tmp.disk); err != nil {
-		return fmt.Errorf("converting field Disk: %v", err)
-	}
-	return nil
-}
-
-func (x *EventTypeUnionOperationComplete) fromC(xc *C.libxl_event) error {
-	if EventType(xc._type) != EventTypeOperationComplete {
-		return errors.New("expected union key EventTypeOperationComplete")
-	}
-
-	tmp := (*C.libxl_event_type_union_operation_complete)(unsafe.Pointer(&xc.u[0]))
-	x.Rc = int(tmp.rc)
-	return nil
-}
-
-func (x *Event) toC(xc *C.libxl_event) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_event_dispose(xc)
-		}
-	}()
-
-	if err := x.Link.toC(&xc.link); err != nil {
-		return fmt.Errorf("converting field Link: %v", err)
-	}
-	xc.domid = C.libxl_domid(x.Domid)
-	if err := x.Domuuid.toC(&xc.domuuid); err != nil {
-		return fmt.Errorf("converting field Domuuid: %v", err)
-	}
-	xc.for_user = C.uint64_t(x.ForUser)
-	xc._type = C.libxl_event_type(x.Type)
-	switch x.Type {
-	case EventTypeDomainShutdown:
-		tmp, ok := x.TypeUnion.(EventTypeUnionDomainShutdown)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var domain_shutdown C.libxl_event_type_union_domain_shutdown
-		domain_shutdown.shutdown_reason = C.uint8_t(tmp.ShutdownReason)
-		domain_shutdownBytes := C.GoBytes(unsafe.Pointer(&domain_shutdown), C.sizeof_libxl_event_type_union_domain_shutdown)
-		copy(xc.u[:], domain_shutdownBytes)
-	case EventTypeDomainDeath:
-		break
-	case EventTypeDiskEject:
-		tmp, ok := x.TypeUnion.(EventTypeUnionDiskEject)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var disk_eject C.libxl_event_type_union_disk_eject
-		if tmp.Vdev != "" {
-			disk_eject.vdev = C.CString(tmp.Vdev)
-		}
-		if err := tmp.Disk.toC(&disk_eject.disk); err != nil {
-			return fmt.Errorf("converting field Disk: %v", err)
-		}
-		disk_ejectBytes := C.GoBytes(unsafe.Pointer(&disk_eject), C.sizeof_libxl_event_type_union_disk_eject)
-		copy(xc.u[:], disk_ejectBytes)
-	case EventTypeOperationComplete:
-		tmp, ok := x.TypeUnion.(EventTypeUnionOperationComplete)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var operation_complete C.libxl_event_type_union_operation_complete
-		operation_complete.rc = C.int(tmp.Rc)
-		operation_completeBytes := C.GoBytes(unsafe.Pointer(&operation_complete), C.sizeof_libxl_event_type_union_operation_complete)
-		copy(xc.u[:], operation_completeBytes)
-	case EventTypeDomainCreateConsoleAvailable:
-		break
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-// NewPsrCatInfo returns an instance of PsrCatInfo initialized with defaults.
-func NewPsrCatInfo() (*PsrCatInfo, error) {
-	var (
-		x  PsrCatInfo
-		xc C.libxl_psr_cat_info
-	)
-
-	C.libxl_psr_cat_info_init(&xc)
-	defer C.libxl_psr_cat_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *PsrCatInfo) fromC(xc *C.libxl_psr_cat_info) error {
-	x.Id = uint32(xc.id)
-	x.CosMax = uint32(xc.cos_max)
-	x.CbmLen = uint32(xc.cbm_len)
-	x.CdpEnabled = bool(xc.cdp_enabled)
-
-	return nil
-}
-
-func (x *PsrCatInfo) toC(xc *C.libxl_psr_cat_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_psr_cat_info_dispose(xc)
-		}
-	}()
-
-	xc.id = C.uint32_t(x.Id)
-	xc.cos_max = C.uint32_t(x.CosMax)
-	xc.cbm_len = C.uint32_t(x.CbmLen)
-	xc.cdp_enabled = C.bool(x.CdpEnabled)
-
-	return nil
-}
-
-// NewPsrHwInfo returns an instance of PsrHwInfo initialized with defaults.
-func NewPsrHwInfo(ptype PsrFeatType) (*PsrHwInfo, error) {
-	var (
-		x  PsrHwInfo
-		xc C.libxl_psr_hw_info
-	)
-
-	C.libxl_psr_hw_info_init(&xc)
-	C.libxl_psr_hw_info_init_type(&xc, C.libxl_psr_feat_type(ptype))
-	defer C.libxl_psr_hw_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *PsrHwInfo) fromC(xc *C.libxl_psr_hw_info) error {
-	x.Id = uint32(xc.id)
-	x.Type = PsrFeatType(xc._type)
-	switch x.Type {
-	case PsrFeatTypeCat:
-		var typeCat PsrHwInfoTypeUnionCat
-		if err := typeCat.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeCat: %v", err)
-		}
-		x.TypeUnion = typeCat
-	case PsrFeatTypeMba:
-		var typeMba PsrHwInfoTypeUnionMba
-		if err := typeMba.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeMba: %v", err)
-		}
-		x.TypeUnion = typeMba
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-func (x *PsrHwInfoTypeUnionCat) fromC(xc *C.libxl_psr_hw_info) error {
-	if PsrFeatType(xc._type) != PsrFeatTypeCat {
-		return errors.New("expected union key PsrFeatTypeCat")
-	}
-
-	tmp := (*C.libxl_psr_hw_info_type_union_cat)(unsafe.Pointer(&xc.u[0]))
-	x.CosMax = uint32(tmp.cos_max)
-	x.CbmLen = uint32(tmp.cbm_len)
-	x.CdpEnabled = bool(tmp.cdp_enabled)
-	return nil
-}
-
-func (x *PsrHwInfoTypeUnionMba) fromC(xc *C.libxl_psr_hw_info) error {
-	if PsrFeatType(xc._type) != PsrFeatTypeMba {
-		return errors.New("expected union key PsrFeatTypeMba")
-	}
-
-	tmp := (*C.libxl_psr_hw_info_type_union_mba)(unsafe.Pointer(&xc.u[0]))
-	x.CosMax = uint32(tmp.cos_max)
-	x.ThrtlMax = uint32(tmp.thrtl_max)
-	x.Linear = bool(tmp.linear)
-	return nil
-}
-
-func (x *PsrHwInfo) toC(xc *C.libxl_psr_hw_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_psr_hw_info_dispose(xc)
-		}
-	}()
-
-	xc.id = C.uint32_t(x.Id)
-	xc._type = C.libxl_psr_feat_type(x.Type)
-	switch x.Type {
-	case PsrFeatTypeCat:
-		tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionCat)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var cat C.libxl_psr_hw_info_type_union_cat
-		cat.cos_max = C.uint32_t(tmp.CosMax)
-		cat.cbm_len = C.uint32_t(tmp.CbmLen)
-		cat.cdp_enabled = C.bool(tmp.CdpEnabled)
-		catBytes := C.GoBytes(unsafe.Pointer(&cat), C.sizeof_libxl_psr_hw_info_type_union_cat)
-		copy(xc.u[:], catBytes)
-	case PsrFeatTypeMba:
-		tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionMba)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var mba C.libxl_psr_hw_info_type_union_mba
-		mba.cos_max = C.uint32_t(tmp.CosMax)
-		mba.thrtl_max = C.uint32_t(tmp.ThrtlMax)
-		mba.linear = C.bool(tmp.Linear)
-		mbaBytes := C.GoBytes(unsafe.Pointer(&mba), C.sizeof_libxl_psr_hw_info_type_union_mba)
-		copy(xc.u[:], mbaBytes)
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
deleted file mode 100644
index 4aaee20b95..0000000000
--- a/tools/golang/xenlight/types.gen.go
+++ /dev/null
@@ -1,1225 +0,0 @@
-// DO NOT EDIT.
-//
-// This file is generated by:
-// gengotypes.py ../../libxl/libxl_types.idl
-//
-package xenlight
-
-type Error int
-
-const (
-	ErrorNonspecific                  Error = -1
-	ErrorVersion                      Error = -2
-	ErrorFail                         Error = -3
-	ErrorNi                           Error = -4
-	ErrorNomem                        Error = -5
-	ErrorInval                        Error = -6
-	ErrorBadfail                      Error = -7
-	ErrorGuestTimedout                Error = -8
-	ErrorTimedout                     Error = -9
-	ErrorNoparavirt                   Error = -10
-	ErrorNotReady                     Error = -11
-	ErrorOseventRegFail               Error = -12
-	ErrorBufferfull                   Error = -13
-	ErrorUnknownChild                 Error = -14
-	ErrorLockFail                     Error = -15
-	ErrorJsonConfigEmpty              Error = -16
-	ErrorDeviceExists                 Error = -17
-	ErrorCheckpointDevopsDoesNotMatch Error = -18
-	ErrorCheckpointDeviceNotSupported Error = -19
-	ErrorVnumaConfigInvalid           Error = -20
-	ErrorDomainNotfound               Error = -21
-	ErrorAborted                      Error = -22
-	ErrorNotfound                     Error = -23
-	ErrorDomainDestroyed              Error = -24
-	ErrorFeatureRemoved               Error = -25
-	ErrorProtocolErrorQmp             Error = -26
-	ErrorUnknownQmpError              Error = -27
-	ErrorQmpGenericError              Error = -28
-	ErrorQmpCommandNotFound           Error = -29
-	ErrorQmpDeviceNotActive           Error = -30
-	ErrorQmpDeviceNotFound            Error = -31
-	ErrorQemuApi                      Error = -32
-)
-
-type DomainType int
-
-const (
-	DomainTypeInvalid DomainType = -1
-	DomainTypeHvm     DomainType = 1
-	DomainTypePv      DomainType = 2
-	DomainTypePvh     DomainType = 3
-)
-
-type RdmReserveStrategy int
-
-const (
-	RdmReserveStrategyIgnore RdmReserveStrategy = 0
-	RdmReserveStrategyHost   RdmReserveStrategy = 1
-)
-
-type RdmReservePolicy int
-
-const (
-	RdmReservePolicyInvalid RdmReservePolicy = -1
-	RdmReservePolicyStrict  RdmReservePolicy = 0
-	RdmReservePolicyRelaxed RdmReservePolicy = 1
-)
-
-type ChannelConnection int
-
-const (
-	ChannelConnectionUnknown ChannelConnection = 0
-	ChannelConnectionPty     ChannelConnection = 1
-	ChannelConnectionSocket  ChannelConnection = 2
-)
-
-type DeviceModelVersion int
-
-const (
-	DeviceModelVersionUnknown            DeviceModelVersion = 0
-	DeviceModelVersionQemuXenTraditional DeviceModelVersion = 1
-	DeviceModelVersionQemuXen            DeviceModelVersion = 2
-)
-
-type ConsoleType int
-
-const (
-	ConsoleTypeUnknown ConsoleType = 0
-	ConsoleTypeSerial  ConsoleType = 1
-	ConsoleTypePv      ConsoleType = 2
-	ConsoleTypeVuart   ConsoleType = 3
-)
-
-type DiskFormat int
-
-const (
-	DiskFormatUnknown DiskFormat = 0
-	DiskFormatQcow    DiskFormat = 1
-	DiskFormatQcow2   DiskFormat = 2
-	DiskFormatVhd     DiskFormat = 3
-	DiskFormatRaw     DiskFormat = 4
-	DiskFormatEmpty   DiskFormat = 5
-	DiskFormatQed     DiskFormat = 6
-)
-
-type DiskBackend int
-
-const (
-	DiskBackendUnknown DiskBackend = 0
-	DiskBackendPhy     DiskBackend = 1
-	DiskBackendTap     DiskBackend = 2
-	DiskBackendQdisk   DiskBackend = 3
-)
-
-type NicType int
-
-const (
-	NicTypeUnknown  NicType = 0
-	NicTypeVifIoemu NicType = 1
-	NicTypeVif      NicType = 2
-)
-
-type ActionOnShutdown int
-
-const (
-	ActionOnShutdownDestroy         ActionOnShutdown = 1
-	ActionOnShutdownRestart         ActionOnShutdown = 2
-	ActionOnShutdownRestartRename   ActionOnShutdown = 3
-	ActionOnShutdownPreserve        ActionOnShutdown = 4
-	ActionOnShutdownCoredumpDestroy ActionOnShutdown = 5
-	ActionOnShutdownCoredumpRestart ActionOnShutdown = 6
-	ActionOnShutdownSoftReset       ActionOnShutdown = 7
-)
-
-type Trigger int
-
-const (
-	TriggerUnknown  Trigger = 0
-	TriggerPower    Trigger = 1
-	TriggerSleep    Trigger = 2
-	TriggerNmi      Trigger = 3
-	TriggerInit     Trigger = 4
-	TriggerReset    Trigger = 5
-	TriggerS3Resume Trigger = 6
-)
-
-type TscMode int
-
-const (
-	TscModeDefault        TscMode = 0
-	TscModeAlwaysEmulate  TscMode = 1
-	TscModeNative         TscMode = 2
-	TscModeNativeParavirt TscMode = 3
-)
-
-type GfxPassthruKind int
-
-const (
-	GfxPassthruKindDefault GfxPassthruKind = 0
-	GfxPassthruKindIgd     GfxPassthruKind = 1
-)
-
-type TimerMode int
-
-const (
-	TimerModeUnknown               TimerMode = -1
-	TimerModeDelayForMissedTicks   TimerMode = 0
-	TimerModeNoDelayForMissedTicks TimerMode = 1
-	TimerModeNoMissedTicksPending  TimerMode = 2
-	TimerModeOneMissedTickPending  TimerMode = 3
-)
-
-type BiosType int
-
-const (
-	BiosTypeUnknown BiosType = 0
-	BiosTypeRombios BiosType = 1
-	BiosTypeSeabios BiosType = 2
-	BiosTypeOvmf    BiosType = 3
-)
-
-type Scheduler int
-
-const (
-	SchedulerUnknown  Scheduler = 0
-	SchedulerSedf     Scheduler = 4
-	SchedulerCredit   Scheduler = 5
-	SchedulerCredit2  Scheduler = 6
-	SchedulerArinc653 Scheduler = 7
-	SchedulerRtds     Scheduler = 8
-	SchedulerNull     Scheduler = 9
-)
-
-type ShutdownReason int
-
-const (
-	ShutdownReasonUnknown   ShutdownReason = -1
-	ShutdownReasonPoweroff  ShutdownReason = 0
-	ShutdownReasonReboot    ShutdownReason = 1
-	ShutdownReasonSuspend   ShutdownReason = 2
-	ShutdownReasonCrash     ShutdownReason = 3
-	ShutdownReasonWatchdog  ShutdownReason = 4
-	ShutdownReasonSoftReset ShutdownReason = 5
-)
-
-type VgaInterfaceType int
-
-const (
-	VgaInterfaceTypeUnknown VgaInterfaceType = 0
-	VgaInterfaceTypeCirrus  VgaInterfaceType = 1
-	VgaInterfaceTypeStd     VgaInterfaceType = 2
-	VgaInterfaceTypeNone    VgaInterfaceType = 3
-	VgaInterfaceTypeQxl     VgaInterfaceType = 4
-)
-
-type VendorDevice int
-
-const (
-	VendorDeviceNone      VendorDevice = 0
-	VendorDeviceXenserver VendorDevice = 1
-)
-
-type ViridianEnlightenment int
-
-const (
-	ViridianEnlightenmentBase                ViridianEnlightenment = 0
-	ViridianEnlightenmentFreq                ViridianEnlightenment = 1
-	ViridianEnlightenmentTimeRefCount        ViridianEnlightenment = 2
-	ViridianEnlightenmentReferenceTsc        ViridianEnlightenment = 3
-	ViridianEnlightenmentHcallRemoteTlbFlush ViridianEnlightenment = 4
-	ViridianEnlightenmentApicAssist          ViridianEnlightenment = 5
-	ViridianEnlightenmentCrashCtl            ViridianEnlightenment = 6
-	ViridianEnlightenmentSynic               ViridianEnlightenment = 7
-	ViridianEnlightenmentStimer              ViridianEnlightenment = 8
-	ViridianEnlightenmentHcallIpi            ViridianEnlightenment = 9
-)
-
-type Hdtype int
-
-const (
-	HdtypeIde  Hdtype = 1
-	HdtypeAhci Hdtype = 2
-)
-
-type CheckpointedStream int
-
-const (
-	CheckpointedStreamNone  CheckpointedStream = 0
-	CheckpointedStreamRemus CheckpointedStream = 1
-	CheckpointedStreamColo  CheckpointedStream = 2
-)
-
-type VuartType int
-
-const (
-	VuartTypeUnknown  VuartType = 0
-	VuartTypeSbsaUart VuartType = 1
-)
-
-type VkbBackend int
-
-const (
-	VkbBackendUnknown VkbBackend = 0
-	VkbBackendQemu    VkbBackend = 1
-	VkbBackendLinux   VkbBackend = 2
-)
-
-type Passthrough int
-
-const (
-	PassthroughDefault  Passthrough = 0
-	PassthroughDisabled Passthrough = 1
-	PassthroughEnabled  Passthrough = 2
-	PassthroughSyncPt   Passthrough = 3
-	PassthroughSharePt  Passthrough = 4
-)
-
-type IoportRange struct {
-	First  uint32
-	Number uint32
-}
-
-type IomemRange struct {
-	Start  uint64
-	Number uint64
-	Gfn    uint64
-}
-
-type VgaInterfaceInfo struct {
-	Kind VgaInterfaceType
-}
-
-type VncInfo struct {
-	Enable     Defbool
-	Listen     string
-	Passwd     string
-	Display    int
-	Findunused Defbool
-}
-
-type SpiceInfo struct {
-	Enable           Defbool
-	Port             int
-	TlsPort          int
-	Host             string
-	DisableTicketing Defbool
-	Passwd           string
-	AgentMouse       Defbool
-	Vdagent          Defbool
-	ClipboardSharing Defbool
-	Usbredirection   int
-	ImageCompression string
-	StreamingVideo   string
-}
-
-type SdlInfo struct {
-	Enable     Defbool
-	Opengl     Defbool
-	Display    string
-	Xauthority string
-}
-
-type Dominfo struct {
-	Uuid             Uuid
-	Domid            Domid
-	Ssidref          uint32
-	SsidLabel        string
-	Running          bool
-	Blocked          bool
-	Paused           bool
-	Shutdown         bool
-	Dying            bool
-	NeverStop        bool
-	ShutdownReason   ShutdownReason
-	OutstandingMemkb uint64
-	CurrentMemkb     uint64
-	SharedMemkb      uint64
-	PagedMemkb       uint64
-	MaxMemkb         uint64
-	CpuTime          uint64
-	VcpuMaxId        uint32
-	VcpuOnline       uint32
-	Cpupool          uint32
-	DomainType       DomainType
-}
-
-type Cpupoolinfo struct {
-	Poolid   uint32
-	PoolName string
-	Sched    Scheduler
-	NDom     uint32
-	Cpumap   Bitmap
-}
-
-type Channelinfo struct {
-	Backend         string
-	BackendId       uint32
-	Frontend        string
-	FrontendId      uint32
-	Devid           Devid
-	State           int
-	Evtch           int
-	Rref            int
-	Connection      ChannelConnection
-	ConnectionUnion channelinfoConnectionUnion
-}
-
-type channelinfoConnectionUnion interface {
-	ischannelinfoConnectionUnion()
-}
-
-type ChannelinfoConnectionUnionPty struct {
-	Path string
-}
-
-func (x ChannelinfoConnectionUnionPty) ischannelinfoConnectionUnion() {}
-
-type Vminfo struct {
-	Uuid  Uuid
-	Domid Domid
-}
-
-type VersionInfo struct {
-	XenVersionMajor int
-	XenVersionMinor int
-	XenVersionExtra string
-	Compiler        string
-	CompileBy       string
-	CompileDomain   string
-	CompileDate     string
-	Capabilities    string
-	Changeset       string
-	VirtStart       uint64
-	Pagesize        int
-	Commandline     string
-	BuildId         string
-}
-
-type DomainCreateInfo struct {
-	Type              DomainType
-	Hap               Defbool
-	Oos               Defbool
-	Ssidref           uint32
-	SsidLabel         string
-	Name              string
-	Domid             Domid
-	Uuid              Uuid
-	Xsdata            KeyValueList
-	Platformdata      KeyValueList
-	Poolid            uint32
-	PoolName          string
-	RunHotplugScripts Defbool
-	DriverDomain      Defbool
-	Passthrough       Passthrough
-}
-
-type DomainRestoreParams struct {
-	CheckpointedStream int
-	StreamVersion      uint32
-	ColoProxyScript    string
-	UserspaceColoProxy Defbool
-}
-
-type SchedParams struct {
-	Vcpuid    int
-	Weight    int
-	Cap       int
-	Period    int
-	Extratime int
-	Budget    int
-}
-
-type VcpuSchedParams struct {
-	Sched Scheduler
-	Vcpus []SchedParams
-}
-
-type DomainSchedParams struct {
-	Sched     Scheduler
-	Weight    int
-	Cap       int
-	Period    int
-	Budget    int
-	Extratime int
-	Slice     int
-	Latency   int
-}
-
-type VnodeInfo struct {
-	Memkb     uint64
-	Distances []uint32
-	Pnode     uint32
-	Vcpus     Bitmap
-}
-
-type GicVersion int
-
-const (
-	GicVersionDefault GicVersion = 0
-	GicVersionV2      GicVersion = 32
-	GicVersionV3      GicVersion = 48
-)
-
-type TeeType int
-
-const (
-	TeeTypeNone  TeeType = 0
-	TeeTypeOptee TeeType = 1
-)
-
-type RdmReserve struct {
-	Strategy RdmReserveStrategy
-	Policy   RdmReservePolicy
-}
-
-type Altp2MMode int
-
-const (
-	Altp2MModeDisabled Altp2MMode = 0
-	Altp2MModeMixed    Altp2MMode = 1
-	Altp2MModeExternal Altp2MMode = 2
-	Altp2MModeLimited  Altp2MMode = 3
-)
-
-type DomainBuildInfo struct {
-	MaxVcpus              int
-	AvailVcpus            Bitmap
-	Cpumap                Bitmap
-	Nodemap               Bitmap
-	VcpuHardAffinity      []Bitmap
-	VcpuSoftAffinity      []Bitmap
-	NumaPlacement         Defbool
-	TscMode               TscMode
-	MaxMemkb              uint64
-	TargetMemkb           uint64
-	VideoMemkb            uint64
-	ShadowMemkb           uint64
-	IommuMemkb            uint64
-	RtcTimeoffset         uint32
-	ExecSsidref           uint32
-	ExecSsidLabel         string
-	Localtime             Defbool
-	DisableMigrate        Defbool
-	Cpuid                 CpuidPolicyList
-	BlkdevStart           string
-	VnumaNodes            []VnodeInfo
-	MaxGrantFrames        uint32
-	MaxMaptrackFrames     uint32
-	DeviceModelVersion    DeviceModelVersion
-	DeviceModelStubdomain Defbool
-	DeviceModel           string
-	DeviceModelSsidref    uint32
-	DeviceModelSsidLabel  string
-	DeviceModelUser       string
-	Extra                 StringList
-	ExtraPv               StringList
-	ExtraHvm              StringList
-	SchedParams           DomainSchedParams
-	Ioports               []IoportRange
-	Irqs                  []uint32
-	Iomem                 []IomemRange
-	ClaimMode             Defbool
-	EventChannels         uint32
-	Kernel                string
-	Cmdline               string
-	Ramdisk               string
-	DeviceTree            string
-	Acpi                  Defbool
-	Bootloader            string
-	BootloaderArgs        StringList
-	TimerMode             TimerMode
-	NestedHvm             Defbool
-	Apic                  Defbool
-	DmRestrict            Defbool
-	Tee                   TeeType
-	Type                  DomainType
-	TypeUnion             domainBuildInfoTypeUnion
-	ArchArm               struct {
-		GicVersion GicVersion
-		Vuart      VuartType
-	}
-	Altp2M Altp2MMode
-}
-
-type domainBuildInfoTypeUnion interface {
-	isdomainBuildInfoTypeUnion()
-}
-
-type DomainBuildInfoTypeUnionHvm struct {
-	Firmware            string
-	Bios                BiosType
-	Pae                 Defbool
-	Apic                Defbool
-	Acpi                Defbool
-	AcpiS3              Defbool
-	AcpiS4              Defbool
-	AcpiLaptopSlate     Defbool
-	Nx                  Defbool
-	Viridian            Defbool
-	ViridianEnable      Bitmap
-	ViridianDisable     Bitmap
-	Timeoffset          string
-	Hpet                Defbool
-	VptAlign            Defbool
-	MmioHoleMemkb       uint64
-	TimerMode           TimerMode
-	NestedHvm           Defbool
-	Altp2M              Defbool
-	SystemFirmware      string
-	SmbiosFirmware      string
-	AcpiFirmware        string
-	Hdtype              Hdtype
-	Nographic           Defbool
-	Vga                 VgaInterfaceInfo
-	Vnc                 VncInfo
-	Keymap              string
-	Sdl                 SdlInfo
-	Spice               SpiceInfo
-	GfxPassthru         Defbool
-	GfxPassthruKind     GfxPassthruKind
-	Serial              string
-	Boot                string
-	Usb                 Defbool
-	Usbversion          int
-	Usbdevice           string
-	VkbDevice           Defbool
-	Soundhw             string
-	XenPlatformPci      Defbool
-	UsbdeviceList       StringList
-	VendorDevice        VendorDevice
-	MsVmGenid           MsVmGenid
-	SerialList          StringList
-	Rdm                 RdmReserve
-	RdmMemBoundaryMemkb uint64
-	McaCaps             uint64
-}
-
-func (x DomainBuildInfoTypeUnionHvm) isdomainBuildInfoTypeUnion() {}
-
-type DomainBuildInfoTypeUnionPv struct {
-	Kernel         string
-	SlackMemkb     uint64
-	Bootloader     string
-	BootloaderArgs StringList
-	Cmdline        string
-	Ramdisk        string
-	Features       string
-	E820Host       Defbool
-}
-
-func (x DomainBuildInfoTypeUnionPv) isdomainBuildInfoTypeUnion() {}
-
-type DomainBuildInfoTypeUnionPvh struct {
-	Pvshim        Defbool
-	PvshimPath    string
-	PvshimCmdline string
-	PvshimExtra   string
-}
-
-func (x DomainBuildInfoTypeUnionPvh) isdomainBuildInfoTypeUnion() {}
-
-type DeviceVfb struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-	Vnc            VncInfo
-	Sdl            SdlInfo
-	Keymap         string
-}
-
-type DeviceVkb struct {
-	BackendDomid           Domid
-	BackendDomname         string
-	Devid                  Devid
-	BackendType            VkbBackend
-	UniqueId               string
-	FeatureDisableKeyboard bool
-	FeatureDisablePointer  bool
-	FeatureAbsPointer      bool
-	FeatureRawPointer      bool
-	FeatureMultiTouch      bool
-	Width                  uint32
-	Height                 uint32
-	MultiTouchWidth        uint32
-	MultiTouchHeight       uint32
-	MultiTouchNumContacts  uint32
-}
-
-type DeviceDisk struct {
-	BackendDomid      Domid
-	BackendDomname    string
-	PdevPath          string
-	Vdev              string
-	Backend           DiskBackend
-	Format            DiskFormat
-	Script            string
-	Removable         int
-	Readwrite         int
-	IsCdrom           int
-	DirectIoSafe      bool
-	DiscardEnable     Defbool
-	ColoEnable        Defbool
-	ColoRestoreEnable Defbool
-	ColoHost          string
-	ColoPort          int
-	ColoExport        string
-	ActiveDisk        string
-	HiddenDisk        string
-}
-
-type DeviceNic struct {
-	BackendDomid                   Domid
-	BackendDomname                 string
-	Devid                          Devid
-	Mtu                            int
-	Model                          string
-	Mac                            Mac
-	Ip                             string
-	Bridge                         string
-	Ifname                         string
-	Script                         string
-	Nictype                        NicType
-	RateBytesPerInterval           uint64
-	RateIntervalUsecs              uint32
-	Gatewaydev                     string
-	ColoftForwarddev               string
-	ColoSockMirrorId               string
-	ColoSockMirrorIp               string
-	ColoSockMirrorPort             string
-	ColoSockComparePriInId         string
-	ColoSockComparePriInIp         string
-	ColoSockComparePriInPort       string
-	ColoSockCompareSecInId         string
-	ColoSockCompareSecInIp         string
-	ColoSockCompareSecInPort       string
-	ColoSockCompareNotifyId        string
-	ColoSockCompareNotifyIp        string
-	ColoSockCompareNotifyPort      string
-	ColoSockRedirector0Id          string
-	ColoSockRedirector0Ip          string
-	ColoSockRedirector0Port        string
-	ColoSockRedirector1Id          string
-	ColoSockRedirector1Ip          string
-	ColoSockRedirector1Port        string
-	ColoSockRedirector2Id          string
-	ColoSockRedirector2Ip          string
-	ColoSockRedirector2Port        string
-	ColoFilterMirrorQueue          string
-	ColoFilterMirrorOutdev         string
-	ColoFilterRedirector0Queue     string
-	ColoFilterRedirector0Indev     string
-	ColoFilterRedirector0Outdev    string
-	ColoFilterRedirector1Queue     string
-	ColoFilterRedirector1Indev     string
-	ColoFilterRedirector1Outdev    string
-	ColoComparePriIn               string
-	ColoCompareSecIn               string
-	ColoCompareOut                 string
-	ColoCompareNotifyDev           string
-	ColoSockSecRedirector0Id       string
-	ColoSockSecRedirector0Ip       string
-	ColoSockSecRedirector0Port     string
-	ColoSockSecRedirector1Id       string
-	ColoSockSecRedirector1Ip       string
-	ColoSockSecRedirector1Port     string
-	ColoFilterSecRedirector0Queue  string
-	ColoFilterSecRedirector0Indev  string
-	ColoFilterSecRedirector0Outdev string
-	ColoFilterSecRedirector1Queue  string
-	ColoFilterSecRedirector1Indev  string
-	ColoFilterSecRedirector1Outdev string
-	ColoFilterSecRewriter0Queue    string
-	ColoCheckpointHost             string
-	ColoCheckpointPort             string
-}
-
-type DevicePci struct {
-	Func         byte
-	Dev          byte
-	Bus          byte
-	Domain       int
-	Vdevfn       uint32
-	VfuncMask    uint32
-	Msitranslate bool
-	PowerMgmt    bool
-	Permissive   bool
-	Seize        bool
-	RdmPolicy    RdmReservePolicy
-}
-
-type DeviceRdm struct {
-	Start  uint64
-	Size   uint64
-	Policy RdmReservePolicy
-}
-
-type UsbctrlType int
-
-const (
-	UsbctrlTypeAuto        UsbctrlType = 0
-	UsbctrlTypePv          UsbctrlType = 1
-	UsbctrlTypeDevicemodel UsbctrlType = 2
-	UsbctrlTypeQusb        UsbctrlType = 3
-)
-
-type UsbdevType int
-
-const (
-	UsbdevTypeHostdev UsbdevType = 1
-)
-
-type DeviceUsbctrl struct {
-	Type           UsbctrlType
-	Devid          Devid
-	Version        int
-	Ports          int
-	BackendDomid   Domid
-	BackendDomname string
-}
-
-type DeviceUsbdev struct {
-	Ctrl      Devid
-	Port      int
-	Type      UsbdevType
-	TypeUnion deviceUsbdevTypeUnion
-}
-
-type deviceUsbdevTypeUnion interface {
-	isdeviceUsbdevTypeUnion()
-}
-
-type DeviceUsbdevTypeUnionHostdev struct {
-	Hostbus  byte
-	Hostaddr byte
-}
-
-func (x DeviceUsbdevTypeUnionHostdev) isdeviceUsbdevTypeUnion() {}
-
-type DeviceDtdev struct {
-	Path string
-}
-
-type DeviceVtpm struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-	Uuid           Uuid
-}
-
-type DeviceP9 struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Tag            string
-	Path           string
-	SecurityModel  string
-	Devid          Devid
-}
-
-type DevicePvcallsif struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-}
-
-type DeviceChannel struct {
-	BackendDomid    Domid
-	BackendDomname  string
-	Devid           Devid
-	Name            string
-	Connection      ChannelConnection
-	ConnectionUnion deviceChannelConnectionUnion
-}
-
-type deviceChannelConnectionUnion interface {
-	isdeviceChannelConnectionUnion()
-}
-
-type DeviceChannelConnectionUnionSocket struct {
-	Path string
-}
-
-func (x DeviceChannelConnectionUnionSocket) isdeviceChannelConnectionUnion() {}
-
-type ConnectorParam struct {
-	UniqueId string
-	Width    uint32
-	Height   uint32
-}
-
-type DeviceVdispl struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-	BeAlloc        bool
-	Connectors     []ConnectorParam
-}
-
-type VsndPcmFormat int
-
-const (
-	VsndPcmFormatS8               VsndPcmFormat = 1
-	VsndPcmFormatU8               VsndPcmFormat = 2
-	VsndPcmFormatS16Le            VsndPcmFormat = 3
-	VsndPcmFormatS16Be            VsndPcmFormat = 4
-	VsndPcmFormatU16Le            VsndPcmFormat = 5
-	VsndPcmFormatU16Be            VsndPcmFormat = 6
-	VsndPcmFormatS24Le            VsndPcmFormat = 7
-	VsndPcmFormatS24Be            VsndPcmFormat = 8
-	VsndPcmFormatU24Le            VsndPcmFormat = 9
-	VsndPcmFormatU24Be            VsndPcmFormat = 10
-	VsndPcmFormatS32Le            VsndPcmFormat = 11
-	VsndPcmFormatS32Be            VsndPcmFormat = 12
-	VsndPcmFormatU32Le            VsndPcmFormat = 13
-	VsndPcmFormatU32Be            VsndPcmFormat = 14
-	VsndPcmFormatF32Le            VsndPcmFormat = 15
-	VsndPcmFormatF32Be            VsndPcmFormat = 16
-	VsndPcmFormatF64Le            VsndPcmFormat = 17
-	VsndPcmFormatF64Be            VsndPcmFormat = 18
-	VsndPcmFormatIec958SubframeLe VsndPcmFormat = 19
-	VsndPcmFormatIec958SubframeBe VsndPcmFormat = 20
-	VsndPcmFormatMuLaw            VsndPcmFormat = 21
-	VsndPcmFormatALaw             VsndPcmFormat = 22
-	VsndPcmFormatImaAdpcm         VsndPcmFormat = 23
-	VsndPcmFormatMpeg             VsndPcmFormat = 24
-	VsndPcmFormatGsm              VsndPcmFormat = 25
-)
-
-type VsndParams struct {
-	SampleRates   []uint32
-	SampleFormats []VsndPcmFormat
-	ChannelsMin   uint32
-	ChannelsMax   uint32
-	BufferSize    uint32
-}
-
-type VsndStreamType int
-
-const (
-	VsndStreamTypeP VsndStreamType = 1
-	VsndStreamTypeC VsndStreamType = 2
-)
-
-type VsndStream struct {
-	UniqueId string
-	Type     VsndStreamType
-	Params   VsndParams
-}
-
-type VsndPcm struct {
-	Name    string
-	Params  VsndParams
-	Streams []VsndStream
-}
-
-type DeviceVsnd struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-	ShortName      string
-	LongName       string
-	Params         VsndParams
-	Pcms           []VsndPcm
-}
-
-type DomainConfig struct {
-	CInfo       DomainCreateInfo
-	BInfo       DomainBuildInfo
-	Disks       []DeviceDisk
-	Nics        []DeviceNic
-	Pcidevs     []DevicePci
-	Rdms        []DeviceRdm
-	Dtdevs      []DeviceDtdev
-	Vfbs        []DeviceVfb
-	Vkbs        []DeviceVkb
-	Vtpms       []DeviceVtpm
-	P9S         []DeviceP9
-	Pvcallsifs  []DevicePvcallsif
-	Vdispls     []DeviceVdispl
-	Vsnds       []DeviceVsnd
-	Channels    []DeviceChannel
-	Usbctrls    []DeviceUsbctrl
-	Usbdevs     []DeviceUsbdev
-	OnPoweroff  ActionOnShutdown
-	OnReboot    ActionOnShutdown
-	OnWatchdog  ActionOnShutdown
-	OnCrash     ActionOnShutdown
-	OnSoftReset ActionOnShutdown
-}
-
-type Diskinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Evtch      int
-	Rref       int
-}
-
-type Nicinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Evtch      int
-	RrefTx     int
-	RrefRx     int
-}
-
-type Vtpminfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Evtch      int
-	Rref       int
-	Uuid       Uuid
-}
-
-type Usbctrlinfo struct {
-	Type       UsbctrlType
-	Devid      Devid
-	Version    int
-	Ports      int
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	State      int
-	Evtch      int
-	RefUrb     int
-	RefConn    int
-}
-
-type Vcpuinfo struct {
-	Vcpuid     uint32
-	Cpu        uint32
-	Online     bool
-	Blocked    bool
-	Running    bool
-	VcpuTime   uint64
-	Cpumap     Bitmap
-	CpumapSoft Bitmap
-}
-
-type Physinfo struct {
-	ThreadsPerCore     uint32
-	CoresPerSocket     uint32
-	MaxCpuId           uint32
-	NrCpus             uint32
-	CpuKhz             uint32
-	TotalPages         uint64
-	FreePages          uint64
-	ScrubPages         uint64
-	OutstandingPages   uint64
-	SharingFreedPages  uint64
-	SharingUsedFrames  uint64
-	MaxPossibleMfn     uint64
-	NrNodes            uint32
-	HwCap              Hwcap
-	CapHvm             bool
-	CapPv              bool
-	CapHvmDirectio     bool
-	CapHap             bool
-	CapShadow          bool
-	CapIommuHapPtShare bool
-}
-
-type Connectorinfo struct {
-	UniqueId string
-	Width    uint32
-	Height   uint32
-	ReqEvtch int
-	ReqRref  int
-	EvtEvtch int
-	EvtRref  int
-}
-
-type Vdisplinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	BeAlloc    bool
-	Connectors []Connectorinfo
-}
-
-type Streaminfo struct {
-	ReqEvtch int
-	ReqRref  int
-}
-
-type Pcminfo struct {
-	Streams []Streaminfo
-}
-
-type Vsndinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Pcms       []Pcminfo
-}
-
-type Vkbinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Evtch      int
-	Rref       int
-}
-
-type Numainfo struct {
-	Size  uint64
-	Free  uint64
-	Dists []uint32
-}
-
-type Cputopology struct {
-	Core   uint32
-	Socket uint32
-	Node   uint32
-}
-
-type Pcitopology struct {
-	Seg   uint16
-	Bus   byte
-	Devfn byte
-	Node  uint32
-}
-
-type SchedCreditParams struct {
-	TsliceMs        int
-	RatelimitUs     int
-	VcpuMigrDelayUs int
-}
-
-type SchedCredit2Params struct {
-	RatelimitUs int
-}
-
-type DomainRemusInfo struct {
-	Interval           int
-	AllowUnsafe        Defbool
-	Blackhole          Defbool
-	Compression        Defbool
-	Netbuf             Defbool
-	Netbufscript       string
-	Diskbuf            Defbool
-	Colo               Defbool
-	UserspaceColoProxy Defbool
-}
-
-type EventType int
-
-const (
-	EventTypeDomainShutdown               EventType = 1
-	EventTypeDomainDeath                  EventType = 2
-	EventTypeDiskEject                    EventType = 3
-	EventTypeOperationComplete            EventType = 4
-	EventTypeDomainCreateConsoleAvailable EventType = 5
-)
-
-type Event struct {
-	Link      EvLink
-	Domid     Domid
-	Domuuid   Uuid
-	ForUser   uint64
-	Type      EventType
-	TypeUnion eventTypeUnion
-}
-
-type eventTypeUnion interface {
-	iseventTypeUnion()
-}
-
-type EventTypeUnionDomainShutdown struct {
-	ShutdownReason byte
-}
-
-func (x EventTypeUnionDomainShutdown) iseventTypeUnion() {}
-
-type EventTypeUnionDiskEject struct {
-	Vdev string
-	Disk DeviceDisk
-}
-
-func (x EventTypeUnionDiskEject) iseventTypeUnion() {}
-
-type EventTypeUnionOperationComplete struct {
-	Rc int
-}
-
-func (x EventTypeUnionOperationComplete) iseventTypeUnion() {}
-
-type PsrCmtType int
-
-const (
-	PsrCmtTypeCacheOccupancy PsrCmtType = 1
-	PsrCmtTypeTotalMemCount  PsrCmtType = 2
-	PsrCmtTypeLocalMemCount  PsrCmtType = 3
-)
-
-type PsrCbmType int
-
-const (
-	PsrCbmTypeUnknown   PsrCbmType = 0
-	PsrCbmTypeL3Cbm     PsrCbmType = 1
-	PsrCbmTypeL3CbmCode PsrCbmType = 2
-	PsrCbmTypeL3CbmData PsrCbmType = 3
-	PsrCbmTypeL2Cbm     PsrCbmType = 4
-	PsrCbmTypeMbaThrtl  PsrCbmType = 5
-)
-
-type PsrCatInfo struct {
-	Id         uint32
-	CosMax     uint32
-	CbmLen     uint32
-	CdpEnabled bool
-}
-
-type PsrFeatType int
-
-const (
-	PsrFeatTypeCat PsrFeatType = 1
-	PsrFeatTypeMba PsrFeatType = 2
-)
-
-type PsrHwInfo struct {
-	Id        uint32
-	Type      PsrFeatType
-	TypeUnion psrHwInfoTypeUnion
-}
-
-type psrHwInfoTypeUnion interface {
-	ispsrHwInfoTypeUnion()
-}
-
-type PsrHwInfoTypeUnionCat struct {
-	CosMax     uint32
-	CbmLen     uint32
-	CdpEnabled bool
-}
-
-func (x PsrHwInfoTypeUnionCat) ispsrHwInfoTypeUnion() {}
-
-type PsrHwInfoTypeUnionMba struct {
-	CosMax   uint32
-	ThrtlMax uint32
-	Linear   bool
-}
-
-func (x PsrHwInfoTypeUnionMba) ispsrHwInfoTypeUnion() {}
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 03:13:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 03:13:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRSI8-0004iy-5u; Thu, 23 Apr 2020 03:12:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRSI6-0004it-He
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 03:12:42 +0000
X-Inumbo-ID: 4990b1a2-8510-11ea-9319-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4990b1a2-8510-11ea-9319-12813bfff9fa;
 Thu, 23 Apr 2020 03:12:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mR/eYLGM6LQf85PQDULWrRH5ahAepLc/Bw1wyWGbLWM=; b=2JnTq89q8p4220Is91E7FFBcb
 88UbMxzocF15VPiGvA/9Eo6j04c37pSb5XNu6E8demPInQdqHmXpRyXwuMKUTLRQwUuIHi062p2th
 zx4Q8TzzLfcorlqQTyv7VkGiqCdU2qB/yDejQ/yNpvFItSkYrNYSQCPsLq4qqJ/Gr8KvU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRSI2-0006yC-Kr; Thu, 23 Apr 2020 03:12:38 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRSI2-0002IF-C7; Thu, 23 Apr 2020 03:12:38 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRSI2-0000MN-B1; Thu, 23 Apr 2020 03:12:38 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149731-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149731: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=18bf34080c4c3beb6699181986cc97dd712498fe
X-Osstest-Versions-That: linux=ae83d0b416db002fe95601e7f97f64b59514d936
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 03:12:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149731 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149731/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149711
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149711
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149711
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149711
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149711
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149711
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149711
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149711
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149711
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                18bf34080c4c3beb6699181986cc97dd712498fe
baseline version:
 linux                ae83d0b416db002fe95601e7f97f64b59514d936

Last test of basis   149711  2020-04-21 10:41:40 Z    1 days
Testing same since   149731  2020-04-22 04:00:57 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexander Duyck <alexander.h.duyck@linux.intel.com>
  Andrew Morton <akpm@linux-foundation.org>
  Bartosz Golaszewski <bgolaszewski@baylibre.com>
  Bjorn Andersson <bjorn.andersson@linaro.org>
  Borislav Petkov <bp@suse.de>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christophe JAILLET <christophe.jaillet@wanadoo.fr>
  Claudio Imbrenda <imbrenda@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  David Gibson <david@gibson.dropbear.id.au>
  Eric Farman <farman@linux.ibm.com>
  Eugenio Pérez <eperezma@redhat.com>
  George Burgess IV <gbiv@google.com>
  George Wilson <gcwilson@linux.ibm.com>
  Gustavo A. R. Silva <gustavo@embeddedor.com>
  Hugh Dickins <hughd@google.com>
  Ian Rogers <irogers@google.com>
  Jann Horn <jannh@google.com>
  Janosch Frank <frankja@linux.ibm.com>
  Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
  Jason Wang <jasowang@redhat.com>
  Jason Yan <yanaijie@huawei.com>
  Joe Perches <joe@perches.com>
  Jon Cargille <jcargill@google.com>
  Josh Poimboeuf <jpoimboe@redhat.com>
  Kees Cook <keescook@chromium.org>
  Linh Pham <phaml@us.ibm.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Longpeng <longpeng2@huawei.com>
  Lucas Stach <l.stach@pengutronix.de>
  Marco Elver <elver@google.com>
  Masahiro Yamada <masahiroy@kernel.org>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Hocko <mhocko@suse.com>
  Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
  Muchun Song <songmuchun@bytedance.com>
  Naresh Kamboju <naresh.kamboju@linaro.org>
  Oliver Upton <oupton@google.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Mackerras <paulus@ozlabs.org>
  Peter Xu <peterx@redhat.com>
  Randy Dunlap <rdunlap@infradead.org>
  Randy Dunlap <rdunlap@infradead.org> # build-tested
  Sachin Sant <sachinp@linux.vnet.ibm.com>
  Sean Christopherson <sean.j.christopherson@intel.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefani Seibold <stefani@seibold.net>
  Stephen Rothwell <sfr@canb.auug.org.au>
  Steve Rutherford <srutherford@google.com>
  Sudip Mukherjee <sudipm.mukherjee@gmail.com>
  syzbot+e27980339d305f2dbfd9@syzkaller.appspotmail.com
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Uros Bizjak <ubizjak@gmail.com>
  Venkatesh Srinivas <venkateshs@google.com>
  Yang Shi <yang.shi@linux.alibaba.com>
  YueHaibing <yuehaibing@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   ae83d0b416db..18bf34080c4c  18bf34080c4c3beb6699181986cc97dd712498fe -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 03:45:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 03:45:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRSnE-0007HQ-QZ; Thu, 23 Apr 2020 03:44:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRSnD-0007HL-Tt
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 03:44:52 +0000
X-Inumbo-ID: c8118bd8-8514-11ea-931e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c8118bd8-8514-11ea-931e-12813bfff9fa;
 Thu, 23 Apr 2020 03:44:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Yzvmp0hyam7hVAPVGj5hAiclZwtJOZK5FziWhTXQKvM=; b=Fvbd4of/BRc20wsXd4wna78l+
 pCbTHFGvPR2zv478LU8y8tkaPYBQ6fu8sXjRRIK/KLiH12JpI1ZtAuDIXOAOMmFAsBUtyJejDZFkX
 01pz6/zJCmip70apcqd0oItLqA0sq28QlltUntoKmxKKKRAKr0AIYxRcjQ7qbFib/7KJU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRSnA-0007aw-TH; Thu, 23 Apr 2020 03:44:48 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRSnA-0003vW-IK; Thu, 23 Apr 2020 03:44:48 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRSnA-0003XT-HV; Thu, 23 Apr 2020 03:44:48 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149737-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149737: tolerable trouble: fail/pass/starved -
 PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 qemu-mainline:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: qemuu=7769c23774d1278f60b9e40d2c0b98784de6425f
X-Osstest-Versions-That: qemuu=3119154db04890fdf57022a43cf2ee594fd4da5a
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 03:44:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149737 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149737/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149723
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149723
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149723
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149723
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149723
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149723
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate               starved  n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate               starved  n/a

version targeted for testing:
 qemuu                7769c23774d1278f60b9e40d2c0b98784de6425f
baseline version:
 qemuu                3119154db04890fdf57022a43cf2ee594fd4da5a

Last test of basis   149723  2020-04-21 19:36:52 Z    1 days
Testing same since   149737  2020-04-22 13:06:30 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                starved 
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 starved 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   3119154db0..7769c23774  7769c23774d1278f60b9e40d2c0b98784de6425f -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 06:55:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 06:55:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRVkx-0006LL-7Y; Thu, 23 Apr 2020 06:54:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRVkv-0006LG-UE
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 06:54:41 +0000
X-Inumbo-ID: 4d84130c-852f-11ea-9328-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4d84130c-852f-11ea-9328-12813bfff9fa;
 Thu, 23 Apr 2020 06:54:40 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 445E8ADD3;
 Thu, 23 Apr 2020 06:54:38 +0000 (UTC)
Subject: Re: [PATCH] xen/grants: fix hypercall continuation for
 GNTTABOP_cache_flush
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200422130753.14713-1-jgross@suse.com>
 <6b050b8e-72d2-2d4f-3e23-101596d31d40@suse.com>
 <alpine.DEB.2.21.2004220911040.25377@sstabellini-ThinkPad-T480s>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <c157a585-790d-8feb-1527-9eb3f0b3a729@suse.com>
Date: Thu, 23 Apr 2020 08:54:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004220911040.25377@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 22.04.2020 18:31, Stefano Stabellini wrote:
> On Wed, 22 Apr 2020, Jan Beulich wrote:
>> On 22.04.2020 15:07, Juergen Gross wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -3626,12 +3626,12 @@ do_grant_table_op(
>>>          if ( unlikely(!guest_handle_okay(cflush, count)) )
>>>              goto out;
>>>          rc = gnttab_cache_flush(cflush, &opaque_in, count);
>>> -        if ( rc > 0 )
>>> +        if ( rc >= 0 )
>>>          {
>>>              guest_handle_add_offset(cflush, rc);
>>>              uop = guest_handle_cast(cflush, void);
>>> +            opaque_out = opaque_in;
>>>          }
>>> -        opaque_out = opaque_in;
>>>          break;
>>>      }
>>>  
>>> @@ -3641,7 +3641,7 @@ do_grant_table_op(
>>>      }
>>>  
>>>    out:
>>> -    if ( rc > 0 || opaque_out != 0 )
>>> +    if ( rc > 0 || (opaque_out != 0 && rc == 0) )
>>
>> I disagree with this part - opaque_out shouldn't end up non-zero
>> when rc < 0, and it won't anymore with the change in the earlier
>> hunk.
> 
> But opaque_out could end up being non-zero when rc == 0.

Which is the case the original code meant to deal with. (I still
think it is unfortunate behavior of the cache-flush implementation
to assign meaning other than "success, done" to rc == 0.)

> I think it is a
> good improvement that we explicitly prevent rc < 0 from entering this
> if condition. This is why this new version of the patch is my favorite:
> it is the one that leads to the code most robust. 
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Well, looks like I'm outvoted then. Nevertheless thanks ...

> That said, as I mentioned before, I would be OK even without the last
> part because it would still be enough to fix the bug.

.. for also clarifying this.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 07:20:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 07:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRW9d-0000N4-AS; Thu, 23 Apr 2020 07:20:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRW9c-0000Mv-6j
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 07:20:12 +0000
X-Inumbo-ID: de2347c2-8532-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id de2347c2-8532-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 07:20:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=4y4ZGDiTEzJr3n0xuSrTaLw8Pvygwy5yikW2bKcOlm0=; b=goMFy2cNqqR3sYapl8Ubo034y
 4SuzkXgWFXXAbL0a2/FR4OoJTWtSBFahkcjDmlNt4SsoXY9Wo9wH5hq3QGr25Vhjh0vVorxfe8uuJ
 7pWWswB9J8UmIBRhbySl0f57z1aT0bPTqfJIHn38i9LsXmvMcpOFL3p9Qds0+Mf4+cUt8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRW9a-00049z-RO; Thu, 23 Apr 2020 07:20:10 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRW9a-0007V9-Ap; Thu, 23 Apr 2020 07:20:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRW9a-0000tb-AG; Thu, 23 Apr 2020 07:20:10 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149742-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149742: all pass - PUSHED
X-Osstest-Versions-This: ovmf=93f6df5f3b2553b8f5188d2a6ba70f3f5cfab0bb
X-Osstest-Versions-That: ovmf=c6a60cf4b99069f55325675c7c7e98b510f4b224
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 07:20:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149742 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149742/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 93f6df5f3b2553b8f5188d2a6ba70f3f5cfab0bb
baseline version:
 ovmf                 c6a60cf4b99069f55325675c7c7e98b510f4b224

Last test of basis   149735  2020-04-22 11:21:30 Z    0 days
Testing same since   149742  2020-04-22 23:10:49 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laszlo Ersek <lersek@redhat.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   c6a60cf4b9..93f6df5f3b  93f6df5f3b2553b8f5188d2a6ba70f3f5cfab0bb -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 07:38:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 07:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRWRA-0001P1-TT; Thu, 23 Apr 2020 07:38:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRWRA-0001Ow-Hr
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 07:38:20 +0000
X-Inumbo-ID: 66a8667a-8535-11ea-9332-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 66a8667a-8535-11ea-9332-12813bfff9fa;
 Thu, 23 Apr 2020 07:38:19 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id AF758AEF9;
 Thu, 23 Apr 2020 07:38:17 +0000 (UTC)
Subject: Re: [[PATCH v3]] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
To: Julien Grall <julien@xen.org>
References: <20200416112423.25755-1-julien@xen.org>
 <495b74dc-3ee3-ff23-99ce-2fa4a17d57a4@suse.com>
 <6ce4afd3-7f03-1083-1057-ed90876f90e0@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <71bd414c-6d21-97e5-0937-adedf78484b7@suse.com>
Date: Thu, 23 Apr 2020 09:38:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <6ce4afd3-7f03-1083-1057-ed90876f90e0@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 19:16, Julien Grall wrote:
> On 16/04/2020 13:19, Jan Beulich wrote:
>> On 16.04.2020 13:24, Julien Grall wrote:
>>> From: Julien Grall <jgrall@amazon.com>
>>>
>>> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
>>> data to guest handle marked const.
>>>
>>> Thankfully, no users of the helper will do that. Rather than hoping this
>>> can be caught during review, harden copy_to_guest_offset() so the build
>>> will fail if such users are introduced.
>>>
>>> There is no easy way to check whether a const is NULL in C99. The
>>> approach used is to introduce an unused variable that is non-const and
>>> assign the handle. If the handle were const, this would fail at build
>>> because without an explicit cast, it is not possible to assign a const
>>> variable to a non-const variable.
>>>
>>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>>> Signed-off-by: Julien Grall <jgrall@amazon.com>
>>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> with one further remark:
>>
>>> --- a/xen/include/asm-x86/guest_access.h
>>> +++ b/xen/include/asm-x86/guest_access.h
>>> @@ -87,6 +87,8 @@
>>>   #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
>>>       const typeof(*(ptr)) *_s = (ptr);                   \
>>>       char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>>> +    /* Check if the handle is not const */              \
>>> +    void *__maybe_unused _t = (hnd).p;                  \
>>
>> Not being a native speaker, to me "if" doesn't look appropriate
>> here. I'd use "that" instead, but you may want to confirm this.
>> Overall then maybe "Check that the handle is not for a const type"?
> 
> I am happy with the new suggestion. I will fixup while comitting it.
> 
> 
> I would also need a review from Stefano here also.

Would you, even under the new rules? In which case it might be
a good idea to Cc him (now done here), also to given him a more
direct means to object. Same would go for the x86 reviewers ...
All of them were Cc-ed on v2. In light of this I can't sensibly
ask that you please commit this patch soon, so that I can put
mine on top, I guess (this was the original intention when
starting to write this reply).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 07:41:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 07:41:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRWTl-000296-BU; Thu, 23 Apr 2020 07:41:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRWTj-000291-Sq
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 07:40:59 +0000
X-Inumbo-ID: c5ed097e-8535-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c5ed097e-8535-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 07:40:59 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id AAE9CAF17;
 Thu, 23 Apr 2020 07:40:57 +0000 (UTC)
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <20200422163338.GF28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <31d31516-cffc-8cba-deb6-1e6b49ab9680@suse.com>
Date: Thu, 23 Apr 2020 09:40:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200422163338.GF28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 22.04.2020 18:33, Roger Pau Monné wrote:
> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
>> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
>>  
>>      return flags;
>>  }
>> +
>> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
>> +{
>> +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
>> +                                                                   : 0) |
>> +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
>> +                                                          : 0);
> 
> Maybe I'm getting confused, but I think the above is wrong and ASID
> should _always_ be flushed when running a HVM domain in shadow mode
> regardless of whether the underlying hw is Intel or AMD, ie:
> 
> bool shadow = paging_mode_shadow(d);
> unsigned int flags = (shadow ? FLUSH_TLB : 0) |
>                      (is_hvm_domain(d) &&
>                       (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE : 0);
> 
> Is the correct version.

Oh, indeed.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 07:42:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 07:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRWVQ-0002GO-Ow; Thu, 23 Apr 2020 07:42:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRWVP-0002GH-Ho
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 07:42:43 +0000
X-Inumbo-ID: 0093d364-8536-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0093d364-8536-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 07:42:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=rB9FjzPtqX4xNCm/9XxIj3LjcefLlEHOf//2emUoGD0=; b=Vpp2FrB37e13znBp+e60DOgYf
 WQorVDUHi+fFuzlcV1liABpZUI4hoK7+uHyDJwtt01sf/PNodCJ/0FXPODl/3DXt06qMOvBWE9XQ+
 SOcsKGM2Uc3AhopMW3HnrPuE4LTzobf7i2WDetnHkTGvXFOkxUsLTu+fDYhTjwdPRFlkk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRWVJ-0004dQ-2Q; Thu, 23 Apr 2020 07:42:37 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRWVI-0008SV-Me; Thu, 23 Apr 2020 07:42:36 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRWVI-00024h-M7; Thu, 23 Apr 2020 07:42:36 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149746-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149746: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=5670fb579407f9f21ad923336adb342012d66aed
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 07:42:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149746 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149746/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
 build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  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-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              5670fb579407f9f21ad923336adb342012d66aed
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   97 days
Failing since        146211  2020-01-18 04:18:52 Z   96 days   89 attempts
Testing same since   149746  2020-04-23 04:22:49 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Chen Hanxiao <chen_han_xiao@126.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mark Asselstine <mark.asselstine@windriver.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Philipp Hahn <hahn@univention.de>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 15791 lines long.)


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:11:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRWwq-0005HF-JA; Thu, 23 Apr 2020 08:11:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Hmmv=6H=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRWwp-0005HA-RP
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:11:03 +0000
X-Inumbo-ID: f912f7e2-8539-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f912f7e2-8539-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 08:11:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=sx5Ym4SMQSoRuHPJG10Jfj3SbRobuzUHwgCiPdpDzCc=; b=spyNgKWdmNqsSOPs+ZxThhWjKx
 /Hz1G7ZIdEYEIyXB2LCF8es1mNcFTwb4QQDi7Feodjgdxzj4EvauXfSbUHHqbdJok5a7i6s5OvPJF
 1Gx64OjTpIV9ta0ngVvBEDAR9E5qdcRp+OgopkQLIfXb7gbeaw96EOsQSQXxDtSznL0Y=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRWwm-0005ji-Hh; Thu, 23 Apr 2020 08:11:00 +0000
Received: from 54-240-197-230.amazon.com ([54.240.197.230]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRWwm-0001f4-AW; Thu, 23 Apr 2020 08:11:00 +0000
Subject: Re: [[PATCH v3]] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
To: Jan Beulich <jbeulich@suse.com>
References: <20200416112423.25755-1-julien@xen.org>
 <495b74dc-3ee3-ff23-99ce-2fa4a17d57a4@suse.com>
 <6ce4afd3-7f03-1083-1057-ed90876f90e0@xen.org>
 <71bd414c-6d21-97e5-0937-adedf78484b7@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <41f87cf9-6f2a-8ac7-0dc3-21c07986f089@xen.org>
Date: Thu, 23 Apr 2020 09:10:58 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <71bd414c-6d21-97e5-0937-adedf78484b7@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 23/04/2020 08:38, Jan Beulich wrote:
> On 17.04.2020 19:16, Julien Grall wrote:
>> On 16/04/2020 13:19, Jan Beulich wrote:
>>> On 16.04.2020 13:24, Julien Grall wrote:
>>>> From: Julien Grall <jgrall@amazon.com>
>>>>
>>>> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
>>>> data to guest handle marked const.
>>>>
>>>> Thankfully, no users of the helper will do that. Rather than hoping this
>>>> can be caught during review, harden copy_to_guest_offset() so the build
>>>> will fail if such users are introduced.
>>>>
>>>> There is no easy way to check whether a const is NULL in C99. The
>>>> approach used is to introduce an unused variable that is non-const and
>>>> assign the handle. If the handle were const, this would fail at build
>>>> because without an explicit cast, it is not possible to assign a const
>>>> variable to a non-const variable.
>>>>
>>>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>>>> Signed-off-by: Julien Grall <jgrall@amazon.com>
>>>
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>> with one further remark:
>>>
>>>> --- a/xen/include/asm-x86/guest_access.h
>>>> +++ b/xen/include/asm-x86/guest_access.h
>>>> @@ -87,6 +87,8 @@
>>>>    #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
>>>>        const typeof(*(ptr)) *_s = (ptr);                   \
>>>>        char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>>>> +    /* Check if the handle is not const */              \
>>>> +    void *__maybe_unused _t = (hnd).p;                  \
>>>
>>> Not being a native speaker, to me "if" doesn't look appropriate
>>> here. I'd use "that" instead, but you may want to confirm this.
>>> Overall then maybe "Check that the handle is not for a const type"?
>>
>> I am happy with the new suggestion. I will fixup while comitting it.
>>
>>
>> I would also need a review from Stefano here also.
> 
> Would you, even under the new rules?

"2. In unusual circumstances, a more general maintainer's Ack can stand
in for or even overrule a specific maintainer's Ack.  Unusual
circumstances might include:

  - The more specific maintainer has not responded either to the
  original patch, nor to "pings", within a reasonable amount of time.
"

So it depends on your definition of "reasonable amount of time". A week 
or two seems reasonable to me for non-pressing issues.

> In which case it might be
> a good idea to Cc him (now done here), also to given him a more
> direct means to object. Same would go for the x86 reviewers ...
> All of them were Cc-ed on v2. In light of this I can't sensibly
> ask that you please commit this patch soon, so that I can put
> mine on top, I guess (this was the original intention when
> starting to write this reply).

Ah that's why he didn't responded... I thought I CCed him but it seems I 
didn't call scripts/add_maintainers.pl before sending the patch.

Thank you for adding the correct CC!

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:16:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:16:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRX22-0005bb-QM; Thu, 23 Apr 2020 08:16:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRX21-0005bW-T0
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:16:25 +0000
X-Inumbo-ID: b8f3a804-853a-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b8f3a804-853a-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 08:16:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3C580AAC7;
 Thu, 23 Apr 2020 08:16:23 +0000 (UTC)
Subject: Re: [[PATCH v3]] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
To: Julien Grall <julien@xen.org>
References: <20200416112423.25755-1-julien@xen.org>
 <495b74dc-3ee3-ff23-99ce-2fa4a17d57a4@suse.com>
 <6ce4afd3-7f03-1083-1057-ed90876f90e0@xen.org>
 <71bd414c-6d21-97e5-0937-adedf78484b7@suse.com>
 <41f87cf9-6f2a-8ac7-0dc3-21c07986f089@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <241902e8-9ded-0480-a422-6825c6ad1116@suse.com>
Date: Thu, 23 Apr 2020 10:16:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <41f87cf9-6f2a-8ac7-0dc3-21c07986f089@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.2020 10:10, Julien Grall wrote:
> Hi,
> 
> On 23/04/2020 08:38, Jan Beulich wrote:
>> On 17.04.2020 19:16, Julien Grall wrote:
>>> On 16/04/2020 13:19, Jan Beulich wrote:
>>>> On 16.04.2020 13:24, Julien Grall wrote:
>>>>> From: Julien Grall <jgrall@amazon.com>
>>>>>
>>>>> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
>>>>> data to guest handle marked const.
>>>>>
>>>>> Thankfully, no users of the helper will do that. Rather than hoping this
>>>>> can be caught during review, harden copy_to_guest_offset() so the build
>>>>> will fail if such users are introduced.
>>>>>
>>>>> There is no easy way to check whether a const is NULL in C99. The
>>>>> approach used is to introduce an unused variable that is non-const and
>>>>> assign the handle. If the handle were const, this would fail at build
>>>>> because without an explicit cast, it is not possible to assign a const
>>>>> variable to a non-const variable.
>>>>>
>>>>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>>>>> Signed-off-by: Julien Grall <jgrall@amazon.com>
>>>>
>>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>>> with one further remark:
>>>>
>>>>> --- a/xen/include/asm-x86/guest_access.h
>>>>> +++ b/xen/include/asm-x86/guest_access.h
>>>>> @@ -87,6 +87,8 @@
>>>>>    #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
>>>>>        const typeof(*(ptr)) *_s = (ptr);                   \
>>>>>        char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>>>>> +    /* Check if the handle is not const */              \
>>>>> +    void *__maybe_unused _t = (hnd).p;                  \
>>>>
>>>> Not being a native speaker, to me "if" doesn't look appropriate
>>>> here. I'd use "that" instead, but you may want to confirm this.
>>>> Overall then maybe "Check that the handle is not for a const type"?
>>>
>>> I am happy with the new suggestion. I will fixup while comitting it.
>>>
>>>
>>> I would also need a review from Stefano here also.
>>
>> Would you, even under the new rules?
> 
> "2. In unusual circumstances, a more general maintainer's Ack can stand
> in for or even overrule a specific maintainer's Ack.  Unusual
> circumstances might include:
> 
>  - The more specific maintainer has not responded either to the
>  original patch, nor to "pings", within a reasonable amount of time.
> "
> 
> So it depends on your definition of "reasonable amount of time".
> A week or two seems reasonable to me for non-pressing issues.

No, this isn't the part I was referring to - there are no unusual
circumstances here. Quite a bit further up you'll in particular
find

"In a case where a maintainer themselves submits a patch, the
 Signed-off-by meets the approval requirement (#1); so a Review
 from anyone in the community suffices for requirement #2."

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:28:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRXDW-0006Yc-Q8; Thu, 23 Apr 2020 08:28:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Hmmv=6H=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRXDV-0006YX-JQ
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:28:17 +0000
X-Inumbo-ID: 60e4bdb8-853c-11ea-9336-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 60e4bdb8-853c-11ea-9336-12813bfff9fa;
 Thu, 23 Apr 2020 08:28:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=FIOh2hKNJUanMonmJvHiW3WdcxR/skynuDn5GGxfqVY=; b=d3sLWRpUittM2Vop8GjcFP5zW9
 laDTz3rqv2/bg0kkqd1aeWIBs2r6zCeL0dFFPQ5usBGPTQbGmWOl/UVP4QtJX/4neHEnugAHmWkY0
 6D3C/KkuUkCUjBy2ZiJr7Yx3jL/8SGy6f3keP4jvL/bYc037OA1W6iD+maDejeJtsEao=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRXDR-00068c-IS; Thu, 23 Apr 2020 08:28:13 +0000
Received: from 54-240-197-238.amazon.com ([54.240.197.238]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRXDR-000355-7q; Thu, 23 Apr 2020 08:28:13 +0000
Subject: Re: [[PATCH v3]] xen/guest_access: Harden *copy_to_guest_offset() to
 prevent const dest operand
To: Jan Beulich <jbeulich@suse.com>
References: <20200416112423.25755-1-julien@xen.org>
 <495b74dc-3ee3-ff23-99ce-2fa4a17d57a4@suse.com>
 <6ce4afd3-7f03-1083-1057-ed90876f90e0@xen.org>
 <71bd414c-6d21-97e5-0937-adedf78484b7@suse.com>
 <41f87cf9-6f2a-8ac7-0dc3-21c07986f089@xen.org>
 <241902e8-9ded-0480-a422-6825c6ad1116@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <a65e16ef-95c9-4834-c980-98d080e172da@xen.org>
Date: Thu, 23 Apr 2020 09:28:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <241902e8-9ded-0480-a422-6825c6ad1116@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 23/04/2020 09:16, Jan Beulich wrote:
> On 23.04.2020 10:10, Julien Grall wrote:
>> Hi,
>>
>> On 23/04/2020 08:38, Jan Beulich wrote:
>>> On 17.04.2020 19:16, Julien Grall wrote:
>>>> On 16/04/2020 13:19, Jan Beulich wrote:
>>>>> On 16.04.2020 13:24, Julien Grall wrote:
>>>>>> From: Julien Grall <jgrall@amazon.com>
>>>>>>
>>>>>> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
>>>>>> data to guest handle marked const.
>>>>>>
>>>>>> Thankfully, no users of the helper will do that. Rather than hoping this
>>>>>> can be caught during review, harden copy_to_guest_offset() so the build
>>>>>> will fail if such users are introduced.
>>>>>>
>>>>>> There is no easy way to check whether a const is NULL in C99. The
>>>>>> approach used is to introduce an unused variable that is non-const and
>>>>>> assign the handle. If the handle were const, this would fail at build
>>>>>> because without an explicit cast, it is not possible to assign a const
>>>>>> variable to a non-const variable.
>>>>>>
>>>>>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>>>>>> Signed-off-by: Julien Grall <jgrall@amazon.com>
>>>>>
>>>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>>>> with one further remark:
>>>>>
>>>>>> --- a/xen/include/asm-x86/guest_access.h
>>>>>> +++ b/xen/include/asm-x86/guest_access.h
>>>>>> @@ -87,6 +87,8 @@
>>>>>>     #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
>>>>>>         const typeof(*(ptr)) *_s = (ptr);                   \
>>>>>>         char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
>>>>>> +    /* Check if the handle is not const */              \
>>>>>> +    void *__maybe_unused _t = (hnd).p;                  \
>>>>>
>>>>> Not being a native speaker, to me "if" doesn't look appropriate
>>>>> here. I'd use "that" instead, but you may want to confirm this.
>>>>> Overall then maybe "Check that the handle is not for a const type"?
>>>>
>>>> I am happy with the new suggestion. I will fixup while comitting it.
>>>>
>>>>
>>>> I would also need a review from Stefano here also.
>>>
>>> Would you, even under the new rules?
>>
>> "2. In unusual circumstances, a more general maintainer's Ack can stand
>> in for or even overrule a specific maintainer's Ack.  Unusual
>> circumstances might include:
>>
>>   - The more specific maintainer has not responded either to the
>>   original patch, nor to "pings", within a reasonable amount of time.
>> "
>>
>> So it depends on your definition of "reasonable amount of time".
>> A week or two seems reasonable to me for non-pressing issues.
> 
> No, this isn't the part I was referring to - there are no unusual
> circumstances here. Quite a bit further up you'll in particular
> find
> 
> "In a case where a maintainer themselves submits a patch, the
>   Signed-off-by meets the approval requirement (#1); so a Review
>   from anyone in the community suffices for requirement #2."T

This is the general rule that we haven't followed on Arm so far. In any 
case this is followed by:

"Before a maintainer checks in their own patch with another community
member's R-b but no co-maintainer Ack, it is especially important to
give their co-maintainer opportunity to give feedback, perhaps
declaring their intention to check it in without their co-maintainers
ack a day before doing so."

So let's give a couple of days for Stefano to object.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:34:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRXJV-0007Nd-FB; Thu, 23 Apr 2020 08:34:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRXJU-0007NX-5w
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:34:28 +0000
X-Inumbo-ID: 3da41bae-853d-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3da41bae-853d-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 08:34:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9DB32AE2A;
 Thu, 23 Apr 2020 08:34:24 +0000 (UTC)
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v2 0/6] x86/mem-paging: misc cleanup
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Message-ID: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Date: Thu, 23 Apr 2020 10:34:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Repeatedly looking at varying parts of this code has lead to
me accumulating a few adjustments.

1: fold p2m_mem_paging_prep()'s main if()-s
2: correct p2m_mem_paging_prep()'s error handling
3: use guest handle for XENMEM_paging_op_prep
4: add minimal lock order enforcement to p2m_mem_paging_prep()
5: move code to its dedicated source file
6: consistently use gfn_t

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:37:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRXM6-0007Ur-Tj; Thu, 23 Apr 2020 08:37:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRXM5-0007Um-PW
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:37:09 +0000
X-Inumbo-ID: 9e667482-853d-11ea-9336-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9e667482-853d-11ea-9336-12813bfff9fa;
 Thu, 23 Apr 2020 08:37:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 63DD3AFC1;
 Thu, 23 Apr 2020 08:37:07 +0000 (UTC)
Subject: [PATCH v2 1/6] x86/mem-paging: fold p2m_mem_paging_prep()'s main
 if()-s
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Message-ID: <cea2307f-1aae-51cb-20ac-fbaf4b945771@suse.com>
Date: Thu, 23 Apr 2020 10:37:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The condition of the second can be true only if the condition of the
first was met; the second half of the condition of the second then also
is redundant with an earlier check. Combine them, drop a pointless
local variable, and re-flow the affected gdprintk().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1808,6 +1808,8 @@ int p2m_mem_paging_prep(struct domain *d
     /* Allocate a page if the gfn does not have one yet */
     if ( !mfn_valid(mfn) )
     {
+        void *guest_map;
+
         /* If the user did not provide a buffer, we disallow */
         ret = -EINVAL;
         if ( unlikely(user_ptr == NULL) )
@@ -1819,22 +1821,16 @@ int p2m_mem_paging_prep(struct domain *d
             goto out;
         mfn = page_to_mfn(page);
         page_extant = 0;
-    }
-
-    /* If we were given a buffer, now is the time to use it */
-    if ( !page_extant && user_ptr )
-    {
-        void *guest_map;
-        int rc;
 
         ASSERT( mfn_valid(mfn) );
         guest_map = map_domain_page(mfn);
-        rc = copy_from_user(guest_map, user_ptr, PAGE_SIZE);
+        ret = copy_from_user(guest_map, user_ptr, PAGE_SIZE);
         unmap_domain_page(guest_map);
-        if ( rc )
+        if ( ret )
         {
-            gdprintk(XENLOG_ERR, "Failed to load paging-in gfn %lx domain %u "
-                                 "bytes left %d\n", gfn_l, d->domain_id, rc);
+            gdprintk(XENLOG_ERR,
+                     "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
+                     gfn_l, d->domain_id, ret);
             ret = -EFAULT;
             put_page(page); /* Don't leak pages */
             goto out;            



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:37:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:37:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRXMl-0007Yb-7Z; Thu, 23 Apr 2020 08:37:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRXMj-0007YP-PF
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:37:49 +0000
X-Inumbo-ID: b62f796a-853d-11ea-9336-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b62f796a-853d-11ea-9336-12813bfff9fa;
 Thu, 23 Apr 2020 08:37:48 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4DD63AFF7;
 Thu, 23 Apr 2020 08:37:47 +0000 (UTC)
Subject: [PATCH v2 2/6] x86/mem-paging: correct p2m_mem_paging_prep()'s error
 handling
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Message-ID: <bf9dd27b-a7db-de0e-a804-d687e66ecf1e@suse.com>
Date: Thu, 23 Apr 2020 10:37:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Communicating errors from p2m_set_entry() to the caller is not enough:
Neither the M2P nor the stats updates should occur in such a case.
Instead the allocated page needs to be freed again; for cleanliness
reasons also properly take into account _PGC_allocated there.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1781,7 +1781,7 @@ void p2m_mem_paging_populate(struct doma
  */
 int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l, uint64_t buffer)
 {
-    struct page_info *page;
+    struct page_info *page = NULL;
     p2m_type_t p2mt;
     p2m_access_t a;
     gfn_t gfn = _gfn(gfn_l);
@@ -1816,9 +1816,19 @@ int p2m_mem_paging_prep(struct domain *d
             goto out;
         /* Get a free page */
         ret = -ENOMEM;
-        page = alloc_domheap_page(p2m->domain, 0);
+        page = alloc_domheap_page(d, 0);
         if ( unlikely(page == NULL) )
             goto out;
+        if ( unlikely(!get_page(page, d)) )
+        {
+            /*
+             * The domain can't possibly know about this page yet, so failure
+             * here is a clear indication of something fishy going on.
+             */
+            domain_crash(d);
+            page = NULL;
+            goto out;
+        }
         mfn = page_to_mfn(page);
         page_extant = 0;
 
@@ -1832,7 +1842,6 @@ int p2m_mem_paging_prep(struct domain *d
                      "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
                      gfn_l, d->domain_id, ret);
             ret = -EFAULT;
-            put_page(page); /* Don't leak pages */
             goto out;            
         }
     }
@@ -1843,13 +1852,24 @@ int p2m_mem_paging_prep(struct domain *d
     ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
                         paging_mode_log_dirty(d) ? p2m_ram_logdirty
                                                  : p2m_ram_rw, a);
-    set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
+    if ( !ret )
+    {
+        set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
 
-    if ( !page_extant )
-        atomic_dec(&d->paged_pages);
+        if ( !page_extant )
+            atomic_dec(&d->paged_pages);
+    }
 
  out:
     gfn_unlock(p2m, gfn, 0);
+
+    if ( page )
+    {
+        if ( ret )
+            put_page_alloc_ref(page);
+        put_page(page);
+    }
+
     return ret;
 }
 



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:38:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:38:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRXNH-0007eU-HL; Thu, 23 Apr 2020 08:38:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRXNG-0007eK-7K
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:38:22 +0000
X-Inumbo-ID: c956032e-853d-11ea-9336-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c956032e-853d-11ea-9336-12813bfff9fa;
 Thu, 23 Apr 2020 08:38:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5F436AFDB;
 Thu, 23 Apr 2020 08:38:19 +0000 (UTC)
Subject: [PATCH v2 3/6] x86/mem-paging: use guest handle for
 XENMEM_paging_op_prep
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Message-ID: <43811c95-aa41-a34a-06ce-7d344cb1411d@suse.com>
Date: Thu, 23 Apr 2020 10:38:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While it should have been this way from the beginning, not doing so will
become an actual problem with PVH Dom0. The interface change is binary
compatible, but requires tools side producers to be re-built.

Drop the bogus/unnecessary page alignment restriction on the input
buffer at the same time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Use HANDLE_64() instead of HANDLE_PARAM() for function parameter.
---
Is there really no way to avoid the buffer copying in libxc?

--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -26,15 +26,33 @@ static int xc_mem_paging_memop(xc_interf
                                unsigned int op, uint64_t gfn, void *buffer)
 {
     xen_mem_paging_op_t mpo;
+    DECLARE_HYPERCALL_BOUNCE(buffer, XC_PAGE_SIZE,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    int rc;
 
     memset(&mpo, 0, sizeof(mpo));
 
     mpo.op      = op;
     mpo.domain  = domain_id;
     mpo.gfn     = gfn;
-    mpo.buffer  = (unsigned long) buffer;
 
-    return do_memory_op(xch, XENMEM_paging_op, &mpo, sizeof(mpo));
+    if ( buffer )
+    {
+        if ( xc_hypercall_bounce_pre(xch, buffer) )
+        {
+            PERROR("Could not bounce memory for XENMEM_paging_op %u", op);
+            return -1;
+        }
+
+        set_xen_guest_handle(mpo.buffer, buffer);
+    }
+
+    rc = do_memory_op(xch, XENMEM_paging_op, &mpo, sizeof(mpo));
+
+    if ( buffer )
+        xc_hypercall_bounce_post(xch, buffer);
+
+    return rc;
 }
 
 int xc_mem_paging_enable(xc_interface *xch, uint32_t domain_id,
@@ -92,28 +110,13 @@ int xc_mem_paging_prep(xc_interface *xch
 int xc_mem_paging_load(xc_interface *xch, uint32_t domain_id,
                        uint64_t gfn, void *buffer)
 {
-    int rc, old_errno;
-
     errno = EINVAL;
 
     if ( !buffer )
         return -1;
 
-    if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
-        return -1;
-
-    if ( mlock(buffer, XC_PAGE_SIZE) )
-        return -1;
-
-    rc = xc_mem_paging_memop(xch, domain_id,
-                             XENMEM_paging_op_prep,
-                             gfn, buffer);
-
-    old_errno = errno;
-    munlock(buffer, XC_PAGE_SIZE);
-    errno = old_errno;
-
-    return rc;
+    return xc_mem_paging_memop(xch, domain_id, XENMEM_paging_op_prep,
+                               gfn, buffer);
 }
 
 
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1779,7 +1779,8 @@ void p2m_mem_paging_populate(struct doma
  * mfn if populate was called for  gfn which was nominated but not evicted. In
  * this case only the p2mt needs to be forwarded.
  */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l, uint64_t buffer)
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l,
+                        XEN_GUEST_HANDLE_64(const_uint8) buffer)
 {
     struct page_info *page = NULL;
     p2m_type_t p2mt;
@@ -1788,13 +1789,9 @@ int p2m_mem_paging_prep(struct domain *d
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret, page_extant = 1;
-    const void *user_ptr = (const void *) buffer;
 
-    if ( user_ptr )
-        /* Sanity check the buffer and bail out early if trouble */
-        if ( (buffer & (PAGE_SIZE - 1)) || 
-             (!access_ok(user_ptr, PAGE_SIZE)) )
-            return -EINVAL;
+    if ( !guest_handle_okay(buffer, PAGE_SIZE) )
+        return -EINVAL;
 
     gfn_lock(p2m, gfn, 0);
 
@@ -1812,7 +1809,7 @@ int p2m_mem_paging_prep(struct domain *d
 
         /* If the user did not provide a buffer, we disallow */
         ret = -EINVAL;
-        if ( unlikely(user_ptr == NULL) )
+        if ( unlikely(guest_handle_is_null(buffer)) )
             goto out;
         /* Get a free page */
         ret = -ENOMEM;
@@ -1834,7 +1831,7 @@ int p2m_mem_paging_prep(struct domain *d
 
         ASSERT( mfn_valid(mfn) );
         guest_map = map_domain_page(mfn);
-        ret = copy_from_user(guest_map, user_ptr, PAGE_SIZE);
+        ret = copy_from_guest(guest_map, buffer, PAGE_SIZE);
         unmap_domain_page(guest_map);
         if ( ret )
         {
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -741,7 +741,8 @@ void p2m_mem_paging_drop_page(struct dom
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer);
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn,
+                        XEN_GUEST_HANDLE_64(const_uint8) buffer);
 /* Resume normal operation (in case a domain was paused) */
 struct vm_event_st;
 void p2m_mem_paging_resume(struct domain *d, struct vm_event_st *rsp);
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -396,10 +396,10 @@ struct xen_mem_paging_op {
     uint8_t     op;         /* XENMEM_paging_op_* */
     domid_t     domain;
 
-    /* PAGING_PREP IN: buffer to immediately fill page in */
-    uint64_aligned_t    buffer;
-    /* Other OPs */
-    uint64_aligned_t    gfn;           /* IN:  gfn of page being operated on */
+    /* IN: (XENMEM_paging_op_prep) buffer to immediately fill page from */
+    XEN_GUEST_HANDLE_64(const_uint8) buffer;
+    /* IN:  gfn of page being operated on */
+    uint64_aligned_t    gfn;
 };
 typedef struct xen_mem_paging_op xen_mem_paging_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_mem_paging_op_t);



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:38:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRXNf-0007j4-R8; Thu, 23 Apr 2020 08:38:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRXNf-0007is-2X
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:38:47 +0000
X-Inumbo-ID: d89c5f9a-853d-11ea-9336-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d89c5f9a-853d-11ea-9336-12813bfff9fa;
 Thu, 23 Apr 2020 08:38:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DF9E3AFC1;
 Thu, 23 Apr 2020 08:38:44 +0000 (UTC)
Subject: [PATCH v2 4/6] x86/mem-paging: add minimal lock order enforcement to
 p2m_mem_paging_prep()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Message-ID: <4af1f459-fe7a-cd61-43cb-fb3fa4f15c00@suse.com>
Date: Thu, 23 Apr 2020 10:38:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While full checking is impossible (as the lock is being acquired/
released down the call tree), perform at least a lock level check.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1813,6 +1813,7 @@ int p2m_mem_paging_prep(struct domain *d
             goto out;
         /* Get a free page */
         ret = -ENOMEM;
+        page_alloc_mm_pre_lock(d);
         page = alloc_domheap_page(d, 0);
         if ( unlikely(page == NULL) )
             goto out;



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:39:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRXOE-0007pU-9E; Thu, 23 Apr 2020 08:39:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRXOD-0007pI-7K
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:39:21 +0000
X-Inumbo-ID: eb8ad23b-853d-11ea-9336-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id eb8ad23b-853d-11ea-9336-12813bfff9fa;
 Thu, 23 Apr 2020 08:39:19 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C30BBAF4F;
 Thu, 23 Apr 2020 08:39:17 +0000 (UTC)
Subject: [PATCH v2 5/6] x86/mem-paging: move code to its dedicated source file
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Message-ID: <b9b189b1-9484-4501-6085-adf86e73f262@suse.com>
Date: Thu, 23 Apr 2020 10:39:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Do a little bit of style adjustment along the way, and drop the
"p2m_mem_paging_" prefixes from the now static functions.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,6 +25,421 @@
 #include <xen/vm_event.h>
 #include <xsm/xsm.h>
 
+#include "mm-locks.h"
+
+/*
+ * p2m_mem_paging_drop_page - Tell pager to drop its reference to a paged page
+ * @d: guest domain
+ * @gfn: guest page to drop
+ *
+ * p2m_mem_paging_drop_page() will notify the pager that a paged-out gfn was
+ * released by the guest. The pager is supposed to drop its reference of the
+ * gfn.
+ */
+void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
+                              p2m_type_t p2mt)
+{
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_PAGING,
+        .u.mem_paging.gfn = gfn
+    };
+
+    /*
+     * We allow no ring in this unique case, because it won't affect
+     * correctness of the guest execution at this point.  If this is the only
+     * page that happens to be paged-out, we'll be okay..  but it's likely the
+     * guest will crash shortly anyways.
+     */
+    int rc = vm_event_claim_slot(d, d->vm_event_paging);
+
+    if ( rc < 0 )
+        return;
+
+    /* Send release notification to pager */
+    req.u.mem_paging.flags = MEM_PAGING_DROP_PAGE;
+
+    /* Update stats unless the page hasn't yet been evicted */
+    if ( p2mt != p2m_ram_paging_out )
+        atomic_dec(&d->paged_pages);
+    else
+        /* Evict will fail now, tag this request for pager */
+        req.u.mem_paging.flags |= MEM_PAGING_EVICT_FAIL;
+
+    vm_event_put_request(d, d->vm_event_paging, &req);
+}
+
+/*
+ * p2m_mem_paging_populate - Tell pager to populate a paged page
+ * @d: guest domain
+ * @gfn: guest page in paging state
+ *
+ * p2m_mem_paging_populate() will notify the pager that a page in any of the
+ * paging states needs to be written back into the guest.
+ * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
+ * paging types because the gfn may not be backed by a mfn.
+ *
+ * The gfn can be in any of the paging states, but the pager needs only be
+ * notified when the gfn is in the paging-out path (paging_out or paged).  This
+ * function may be called more than once from several vcpus. If the vcpu belongs
+ * to the guest, the vcpu must be stopped and the pager notified that the vcpu
+ * was stopped. The pager needs to handle several requests for the same gfn.
+ *
+ * If the gfn is not in the paging-out path and the vcpu does not belong to the
+ * guest, nothing needs to be done and the function assumes that a request was
+ * already sent to the pager. In this case the caller has to try again until the
+ * gfn is fully paged in again.
+ */
+void p2m_mem_paging_populate(struct domain *d, unsigned long gfn_l)
+{
+    struct vcpu *v = current;
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_PAGING,
+        .u.mem_paging.gfn = gfn_l
+    };
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    gfn_t gfn = _gfn(gfn_l);
+    mfn_t mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int rc = vm_event_claim_slot(d, d->vm_event_paging);
+
+    /* We're paging. There should be a ring. */
+    if ( rc == -EOPNOTSUPP )
+    {
+        gdprintk(XENLOG_ERR, "Dom%d paging gfn %lx yet no ring in place\n",
+                 d->domain_id, gfn_l);
+        /* Prevent the vcpu from faulting repeatedly on the same gfn */
+        if ( v->domain == d )
+            vcpu_pause_nosync(v);
+        domain_crash(d);
+        return;
+    }
+    else if ( rc < 0 )
+        return;
+
+    /* Fix p2m mapping */
+    gfn_lock(p2m, gfn, 0);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+    /* Allow only nominated or evicted pages to enter page-in path */
+    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
+    {
+        /* Evict will fail now, tag this request for pager */
+        if ( p2mt == p2m_ram_paging_out )
+            req.u.mem_paging.flags |= MEM_PAGING_EVICT_FAIL;
+
+        rc = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+    }
+    gfn_unlock(p2m, gfn, 0);
+    if ( rc < 0 )
+        goto out_cancel;
+
+    /* Pause domain if request came from guest and gfn has paging type */
+    if ( p2m_is_paging(p2mt) && v->domain == d )
+    {
+        vm_event_vcpu_pause(v);
+        req.flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+    }
+    /* No need to inform pager if the gfn is not in the page-out path */
+    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
+    {
+        /* gfn is already on its way back and vcpu is not paused */
+    out_cancel:
+        vm_event_cancel_slot(d, d->vm_event_paging);
+        return;
+    }
+
+    /* Send request to pager */
+    req.u.mem_paging.p2mt = p2mt;
+    req.vcpu_id = v->vcpu_id;
+
+    vm_event_put_request(d, d->vm_event_paging, &req);
+}
+
+/*
+ * p2m_mem_paging_resume - Resume guest gfn
+ * @d: guest domain
+ * @rsp: vm_event response received
+ *
+ * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw. It is
+ * called by the pager.
+ *
+ * The gfn was previously either evicted and populated, or nominated and
+ * populated. If the page was evicted the p2mt will be p2m_ram_paging_in. If
+ * the page was just nominated the p2mt will be p2m_ram_paging_in_start because
+ * the pager did not call prepare().
+ *
+ * If the gfn was dropped the vcpu needs to be unpaused.
+ */
+void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    mfn_t mfn;
+
+    /* Fix p2m entry if the page was not dropped */
+    if ( !(rsp->u.mem_paging.flags & MEM_PAGING_DROP_PAGE) )
+    {
+        gfn_t gfn = _gfn(rsp->u.mem_access.gfn);
+
+        gfn_lock(p2m, gfn, 0);
+        mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+        /*
+         * Allow only pages which were prepared properly, or pages which
+         * were nominated but not evicted.
+         */
+        if ( mfn_valid(mfn) && (p2mt == p2m_ram_paging_in) )
+        {
+            int rc = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                                   paging_mode_log_dirty(d) ? p2m_ram_logdirty
+                                                            : p2m_ram_rw, a);
+
+            if ( !rc )
+                set_gpfn_from_mfn(mfn_x(mfn), gfn_x(gfn));
+        }
+        gfn_unlock(p2m, gfn, 0);
+    }
+}
+
+/*
+ * nominate - Mark a guest page as to-be-paged-out
+ * @d: guest domain
+ * @gfn: guest page to nominate
+ *
+ * Returns 0 for success or negative errno values if gfn is not pageable.
+ *
+ * nominate() is called by the pager and checks if a guest page can be paged
+ * out. If the following conditions are met the p2mt will be changed:
+ * - the gfn is backed by a mfn
+ * - the p2mt of the gfn is pageable
+ * - the mfn is not used for IO
+ * - the mfn has exactly one user and has no special meaning
+ *
+ * Once the p2mt is changed the page is readonly for the guest.  On success the
+ * pager can write the page contents to disk and later evict the page.
+ */
+static int nominate(struct domain *d, unsigned long gfn_l)
+{
+    struct page_info *page;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    gfn_t gfn = _gfn(gfn_l);
+    mfn_t mfn;
+    int ret = -EBUSY;
+
+    gfn_lock(p2m, gfn, 0);
+
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+
+    /* Check if mfn is valid */
+    if ( !mfn_valid(mfn) )
+        goto out;
+
+    /* Check p2m type */
+    if ( !p2m_is_pageable(p2mt) )
+        goto out;
+
+    /* Check for io memory page */
+    if ( is_iomem_page(mfn) )
+        goto out;
+
+    /* Check page count and type */
+    page = mfn_to_page(mfn);
+    if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
+         (1 | PGC_allocated) )
+        goto out;
+
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
+        goto out;
+
+    /* Fix p2m entry */
+    ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
+
+ out:
+    gfn_unlock(p2m, gfn, 0);
+    return ret;
+}
+
+/*
+ * evict - Mark a guest page as paged-out
+ * @d: guest domain
+ * @gfn: guest page to evict
+ *
+ * Returns 0 for success or negative errno values if eviction is not possible.
+ *
+ * evict() is called by the pager and will free a guest page and release it
+ * back to Xen. If the following conditions are met the page can be freed:
+ * - the gfn is backed by a mfn
+ * - the gfn was nominated
+ * - the mfn has still exactly one user and has no special meaning
+ *
+ * After successful nomination some other process could have mapped the page. In
+ * this case eviction can not be done. If the gfn was populated before the pager
+ * could evict it, eviction can not be done either. In this case the gfn is
+ * still backed by a mfn.
+ */
+static int evict(struct domain *d, unsigned long gfn_l)
+{
+    struct page_info *page;
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    gfn_t gfn = _gfn(gfn_l);
+    mfn_t mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int ret = -EBUSY;
+
+    gfn_lock(p2m, gfn, 0);
+
+    /* Get mfn */
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+    if ( unlikely(!mfn_valid(mfn)) )
+        goto out;
+
+    /* Allow only nominated pages */
+    if ( p2mt != p2m_ram_paging_out )
+        goto out;
+
+    /* Get the page so it doesn't get modified under Xen's feet */
+    page = mfn_to_page(mfn);
+    if ( unlikely(!get_page(page, d)) )
+        goto out;
+
+    /* Check page count and type once more */
+    if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
+         (2 | PGC_allocated) )
+        goto out_put;
+
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
+        goto out_put;
+
+    /* Decrement guest domain's ref count of the page */
+    put_page_alloc_ref(page);
+
+    /* Remove mapping from p2m table */
+    ret = p2m_set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
+                        p2m_ram_paged, a);
+
+    /* Clear content before returning the page to Xen */
+    scrub_one_page(page);
+
+    /* Track number of paged gfns */
+    atomic_inc(&d->paged_pages);
+
+ out_put:
+    /* Put the page back so it gets freed */
+    put_page(page);
+
+ out:
+    gfn_unlock(p2m, gfn, 0);
+    return ret;
+}
+
+/*
+ * prepare - Allocate a new page for the guest
+ * @d: guest domain
+ * @gfn: guest page in paging state
+ *
+ * prepare() will allocate a new page for the guest if the gfn is not backed
+ * by a mfn. It is called by the pager.
+ * It is required that the gfn was already populated. The gfn may already have a
+ * mfn if populate was called for  gfn which was nominated but not evicted. In
+ * this case only the p2mt needs to be forwarded.
+ */
+static int prepare(struct domain *d, unsigned long gfn_l,
+                   XEN_GUEST_HANDLE_64(const_uint8) buffer)
+{
+    struct page_info *page = NULL;
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    gfn_t gfn = _gfn(gfn_l);
+    mfn_t mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int ret, page_extant = 1;
+
+    if ( !guest_handle_okay(buffer, PAGE_SIZE) )
+        return -EINVAL;
+
+    gfn_lock(p2m, gfn, 0);
+
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
+
+    ret = -ENOENT;
+    /* Allow missing pages */
+    if ( (p2mt != p2m_ram_paging_in) && (p2mt != p2m_ram_paged) )
+        goto out;
+
+    /* Allocate a page if the gfn does not have one yet */
+    if ( !mfn_valid(mfn) )
+    {
+        void *guest_map;
+
+        /* If the user did not provide a buffer, we disallow */
+        ret = -EINVAL;
+        if ( unlikely(guest_handle_is_null(buffer)) )
+            goto out;
+        /* Get a free page */
+        ret = -ENOMEM;
+        page_alloc_mm_pre_lock(d);
+        page = alloc_domheap_page(d, 0);
+        if ( unlikely(page == NULL) )
+            goto out;
+        if ( unlikely(!get_page(page, d)) )
+        {
+            /*
+             * The domain can't possibly know about this page yet, so failure
+             * here is a clear indication of something fishy going on.
+             */
+            domain_crash(d);
+            page = NULL;
+            goto out;
+        }
+        mfn = page_to_mfn(page);
+        page_extant = 0;
+
+        ASSERT( mfn_valid(mfn) );
+        guest_map = map_domain_page(mfn);
+        ret = copy_from_guest(guest_map, buffer, PAGE_SIZE);
+        unmap_domain_page(guest_map);
+        if ( ret )
+        {
+            gdprintk(XENLOG_ERR,
+                     "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
+                     gfn_l, d->domain_id, ret);
+            ret = -EFAULT;
+            goto out;
+        }
+    }
+
+    /*
+     * Make the page already guest-accessible. If the pager still has a
+     * pending resume operation, it will be idempotent p2m entry-wise, but
+     * will unpause the vcpu.
+     */
+    ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                        paging_mode_log_dirty(d) ? p2m_ram_logdirty
+                                                 : p2m_ram_rw, a);
+    if ( !ret )
+    {
+        set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
+
+        if ( !page_extant )
+            atomic_dec(&d->paged_pages);
+    }
+
+ out:
+    gfn_unlock(p2m, gfn, 0);
+
+    if ( page )
+    {
+        if ( ret )
+            put_page_alloc_ref(page);
+        put_page(page);
+    }
+
+    return ret;
+}
+
 int mem_paging_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
 {
     int rc;
@@ -50,15 +465,15 @@ int mem_paging_memop(XEN_GUEST_HANDLE_PA
     switch( mpo.op )
     {
     case XENMEM_paging_op_nominate:
-        rc = p2m_mem_paging_nominate(d, mpo.gfn);
+        rc = nominate(d, mpo.gfn);
         break;
 
     case XENMEM_paging_op_evict:
-        rc = p2m_mem_paging_evict(d, mpo.gfn);
+        rc = evict(d, mpo.gfn);
         break;
 
     case XENMEM_paging_op_prep:
-        rc = p2m_mem_paging_prep(d, mpo.gfn, mpo.buffer);
+        rc = prepare(d, mpo.gfn, mpo.buffer);
         if ( !rc )
             copyback = 1;
         break;
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -23,7 +23,6 @@
  * along with this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
-#include <xen/guest_access.h> /* copy_from_guest() */
 #include <xen/iommu.h>
 #include <xen/mem_access.h>
 #include <xen/vm_event.h>
@@ -1506,418 +1505,6 @@ int set_shared_p2m_entry(struct domain *
     return rc;
 }
 
-/**
- * p2m_mem_paging_nominate - Mark a guest page as to-be-paged-out
- * @d: guest domain
- * @gfn: guest page to nominate
- *
- * Returns 0 for success or negative errno values if gfn is not pageable.
- *
- * p2m_mem_paging_nominate() is called by the pager and checks if a guest page
- * can be paged out. If the following conditions are met the p2mt will be
- * changed:
- * - the gfn is backed by a mfn
- * - the p2mt of the gfn is pageable
- * - the mfn is not used for IO
- * - the mfn has exactly one user and has no special meaning
- *
- * Once the p2mt is changed the page is readonly for the guest.  On success the
- * pager can write the page contents to disk and later evict the page.
- */
-int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn_l)
-{
-    struct page_info *page;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
-    mfn_t mfn;
-    int ret = -EBUSY;
-
-    gfn_lock(p2m, gfn, 0);
-
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-
-    /* Check if mfn is valid */
-    if ( !mfn_valid(mfn) )
-        goto out;
-
-    /* Check p2m type */
-    if ( !p2m_is_pageable(p2mt) )
-        goto out;
-
-    /* Check for io memory page */
-    if ( is_iomem_page(mfn) )
-        goto out;
-
-    /* Check page count and type */
-    page = mfn_to_page(mfn);
-    if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
-         (1 | PGC_allocated) )
-        goto out;
-
-    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
-        goto out;
-
-    /* Fix p2m entry */
-    ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
-
- out:
-    gfn_unlock(p2m, gfn, 0);
-    return ret;
-}
-
-/**
- * p2m_mem_paging_evict - Mark a guest page as paged-out
- * @d: guest domain
- * @gfn: guest page to evict
- *
- * Returns 0 for success or negative errno values if eviction is not possible.
- *
- * p2m_mem_paging_evict() is called by the pager and will free a guest page and
- * release it back to Xen. If the following conditions are met the page can be
- * freed:
- * - the gfn is backed by a mfn
- * - the gfn was nominated
- * - the mfn has still exactly one user and has no special meaning
- *
- * After successful nomination some other process could have mapped the page. In
- * this case eviction can not be done. If the gfn was populated before the pager
- * could evict it, eviction can not be done either. In this case the gfn is
- * still backed by a mfn.
- */
-int p2m_mem_paging_evict(struct domain *d, unsigned long gfn_l)
-{
-    struct page_info *page;
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
-    mfn_t mfn;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret = -EBUSY;
-
-    gfn_lock(p2m, gfn, 0);
-
-    /* Get mfn */
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-    if ( unlikely(!mfn_valid(mfn)) )
-        goto out;
-
-    /* Allow only nominated pages */
-    if ( p2mt != p2m_ram_paging_out )
-        goto out;
-
-    /* Get the page so it doesn't get modified under Xen's feet */
-    page = mfn_to_page(mfn);
-    if ( unlikely(!get_page(page, d)) )
-        goto out;
-
-    /* Check page count and type once more */
-    if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
-         (2 | PGC_allocated) )
-        goto out_put;
-
-    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
-        goto out_put;
-
-    /* Decrement guest domain's ref count of the page */
-    put_page_alloc_ref(page);
-
-    /* Remove mapping from p2m table */
-    ret = p2m_set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
-                        p2m_ram_paged, a);
-
-    /* Clear content before returning the page to Xen */
-    scrub_one_page(page);
-
-    /* Track number of paged gfns */
-    atomic_inc(&d->paged_pages);
-
- out_put:
-    /* Put the page back so it gets freed */
-    put_page(page);
-
- out:
-    gfn_unlock(p2m, gfn, 0);
-    return ret;
-}
-
-/**
- * p2m_mem_paging_drop_page - Tell pager to drop its reference to a paged page
- * @d: guest domain
- * @gfn: guest page to drop
- *
- * p2m_mem_paging_drop_page() will notify the pager that a paged-out gfn was
- * released by the guest. The pager is supposed to drop its reference of the
- * gfn.
- */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
-                                p2m_type_t p2mt)
-{
-    vm_event_request_t req = {
-        .reason = VM_EVENT_REASON_MEM_PAGING,
-        .u.mem_paging.gfn = gfn
-    };
-
-    /* We allow no ring in this unique case, because it won't affect
-     * correctness of the guest execution at this point.  If this is the only
-     * page that happens to be paged-out, we'll be okay..  but it's likely the
-     * guest will crash shortly anyways. */
-    int rc = vm_event_claim_slot(d, d->vm_event_paging);
-    if ( rc < 0 )
-        return;
-
-    /* Send release notification to pager */
-    req.u.mem_paging.flags = MEM_PAGING_DROP_PAGE;
-
-    /* Update stats unless the page hasn't yet been evicted */
-    if ( p2mt != p2m_ram_paging_out )
-        atomic_dec(&d->paged_pages);
-    else
-        /* Evict will fail now, tag this request for pager */
-        req.u.mem_paging.flags |= MEM_PAGING_EVICT_FAIL;
-
-    vm_event_put_request(d, d->vm_event_paging, &req);
-}
-
-/**
- * p2m_mem_paging_populate - Tell pager to populate a paged page
- * @d: guest domain
- * @gfn: guest page in paging state
- *
- * p2m_mem_paging_populate() will notify the pager that a page in any of the
- * paging states needs to be written back into the guest.
- * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
- * paging types because the gfn may not be backed by a mfn.
- *
- * The gfn can be in any of the paging states, but the pager needs only be
- * notified when the gfn is in the paging-out path (paging_out or paged).  This
- * function may be called more than once from several vcpus. If the vcpu belongs
- * to the guest, the vcpu must be stopped and the pager notified that the vcpu
- * was stopped. The pager needs to handle several requests for the same gfn.
- *
- * If the gfn is not in the paging-out path and the vcpu does not belong to the
- * guest, nothing needs to be done and the function assumes that a request was
- * already sent to the pager. In this case the caller has to try again until the
- * gfn is fully paged in again.
- */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn_l)
-{
-    struct vcpu *v = current;
-    vm_event_request_t req = {
-        .reason = VM_EVENT_REASON_MEM_PAGING,
-        .u.mem_paging.gfn = gfn_l
-    };
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
-    mfn_t mfn;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-
-    /* We're paging. There should be a ring */
-    int rc = vm_event_claim_slot(d, d->vm_event_paging);
-
-    if ( rc == -EOPNOTSUPP )
-    {
-        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
-                             "in place\n", d->domain_id, gfn_l);
-        /* Prevent the vcpu from faulting repeatedly on the same gfn */
-        if ( v->domain == d )
-            vcpu_pause_nosync(v);
-        domain_crash(d);
-        return;
-    }
-    else if ( rc < 0 )
-        return;
-
-    /* Fix p2m mapping */
-    gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-    /* Allow only nominated or evicted pages to enter page-in path */
-    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
-    {
-        /* Evict will fail now, tag this request for pager */
-        if ( p2mt == p2m_ram_paging_out )
-            req.u.mem_paging.flags |= MEM_PAGING_EVICT_FAIL;
-
-        rc = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
-    }
-    gfn_unlock(p2m, gfn, 0);
-    if ( rc < 0 )
-        goto out_cancel;
-
-    /* Pause domain if request came from guest and gfn has paging type */
-    if ( p2m_is_paging(p2mt) && v->domain == d )
-    {
-        vm_event_vcpu_pause(v);
-        req.flags |= VM_EVENT_FLAG_VCPU_PAUSED;
-    }
-    /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
-    {
-        /* gfn is already on its way back and vcpu is not paused */
-    out_cancel:
-        vm_event_cancel_slot(d, d->vm_event_paging);
-        return;
-    }
-
-    /* Send request to pager */
-    req.u.mem_paging.p2mt = p2mt;
-    req.vcpu_id = v->vcpu_id;
-
-    vm_event_put_request(d, d->vm_event_paging, &req);
-}
-
-/**
- * p2m_mem_paging_prep - Allocate a new page for the guest
- * @d: guest domain
- * @gfn: guest page in paging state
- *
- * p2m_mem_paging_prep() will allocate a new page for the guest if the gfn is
- * not backed by a mfn. It is called by the pager.
- * It is required that the gfn was already populated. The gfn may already have a
- * mfn if populate was called for  gfn which was nominated but not evicted. In
- * this case only the p2mt needs to be forwarded.
- */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn_l,
-                        XEN_GUEST_HANDLE_64(const_uint8) buffer)
-{
-    struct page_info *page = NULL;
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
-    mfn_t mfn;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret, page_extant = 1;
-
-    if ( !guest_handle_okay(buffer, PAGE_SIZE) )
-        return -EINVAL;
-
-    gfn_lock(p2m, gfn, 0);
-
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-
-    ret = -ENOENT;
-    /* Allow missing pages */
-    if ( (p2mt != p2m_ram_paging_in) && (p2mt != p2m_ram_paged) )
-        goto out;
-
-    /* Allocate a page if the gfn does not have one yet */
-    if ( !mfn_valid(mfn) )
-    {
-        void *guest_map;
-
-        /* If the user did not provide a buffer, we disallow */
-        ret = -EINVAL;
-        if ( unlikely(guest_handle_is_null(buffer)) )
-            goto out;
-        /* Get a free page */
-        ret = -ENOMEM;
-        page_alloc_mm_pre_lock(d);
-        page = alloc_domheap_page(d, 0);
-        if ( unlikely(page == NULL) )
-            goto out;
-        if ( unlikely(!get_page(page, d)) )
-        {
-            /*
-             * The domain can't possibly know about this page yet, so failure
-             * here is a clear indication of something fishy going on.
-             */
-            domain_crash(d);
-            page = NULL;
-            goto out;
-        }
-        mfn = page_to_mfn(page);
-        page_extant = 0;
-
-        ASSERT( mfn_valid(mfn) );
-        guest_map = map_domain_page(mfn);
-        ret = copy_from_guest(guest_map, buffer, PAGE_SIZE);
-        unmap_domain_page(guest_map);
-        if ( ret )
-        {
-            gdprintk(XENLOG_ERR,
-                     "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
-                     gfn_l, d->domain_id, ret);
-            ret = -EFAULT;
-            goto out;            
-        }
-    }
-
-    /* Make the page already guest-accessible. If the pager still has a
-     * pending resume operation, it will be idempotent p2m entry-wise,
-     * but will unpause the vcpu */
-    ret = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
-                        paging_mode_log_dirty(d) ? p2m_ram_logdirty
-                                                 : p2m_ram_rw, a);
-    if ( !ret )
-    {
-        set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
-
-        if ( !page_extant )
-            atomic_dec(&d->paged_pages);
-    }
-
- out:
-    gfn_unlock(p2m, gfn, 0);
-
-    if ( page )
-    {
-        if ( ret )
-            put_page_alloc_ref(page);
-        put_page(page);
-    }
-
-    return ret;
-}
-
-/**
- * p2m_mem_paging_resume - Resume guest gfn
- * @d: guest domain
- * @rsp: vm_event response received
- *
- * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw. It is
- * called by the pager.
- *
- * The gfn was previously either evicted and populated, or nominated and
- * populated. If the page was evicted the p2mt will be p2m_ram_paging_in. If
- * the page was just nominated the p2mt will be p2m_ram_paging_in_start because
- * the pager did not call p2m_mem_paging_prep().
- *
- * If the gfn was dropped the vcpu needs to be unpaused.
- */
-
-void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
-{
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    p2m_type_t p2mt;
-    p2m_access_t a;
-    mfn_t mfn;
-
-    /* Fix p2m entry if the page was not dropped */
-    if ( !(rsp->u.mem_paging.flags & MEM_PAGING_DROP_PAGE) )
-    {
-        gfn_t gfn = _gfn(rsp->u.mem_access.gfn);
-
-        gfn_lock(p2m, gfn, 0);
-        mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL, NULL);
-        /*
-         * Allow only pages which were prepared properly, or pages which
-         * were nominated but not evicted.
-         */
-        if ( mfn_valid(mfn) && (p2mt == p2m_ram_paging_in) )
-        {
-            int rc = p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
-                                   paging_mode_log_dirty(d) ? p2m_ram_logdirty :
-                                   p2m_ram_rw, a);
-
-            if ( !rc )
-                set_gpfn_from_mfn(mfn_x(mfn), gfn_x(gfn));
-        }
-        gfn_unlock(p2m, gfn, 0);
-    }
-}
-
 #ifdef CONFIG_HVM
 static struct p2m_domain *
 p2m_getlru_nestedp2m(struct domain *d, struct p2m_domain *p2m)
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -731,18 +731,11 @@ static inline void p2m_pod_init(struct p
 /* Modify p2m table for shared gfn */
 int set_shared_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 
-/* Check if a nominated gfn is valid to be paged out */
-int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn);
-/* Evict a frame */
-int p2m_mem_paging_evict(struct domain *d, unsigned long gfn);
 /* Tell xenpaging to drop a paged out frame */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn, 
                                 p2m_type_t p2mt);
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
-/* Prepare the p2m for paging a frame in */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn,
-                        XEN_GUEST_HANDLE_64(const_uint8) buffer);
 /* Resume normal operation (in case a domain was paused) */
 struct vm_event_st;
 void p2m_mem_paging_resume(struct domain *d, struct vm_event_st *rsp);



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 08:39:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 08:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRXOZ-0007v8-Ml; Thu, 23 Apr 2020 08:39:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRXOZ-0007uu-8S
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 08:39:43 +0000
X-Inumbo-ID: f9ae4d1a-853d-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f9ae4d1a-853d-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 08:39:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 68E07AFC1;
 Thu, 23 Apr 2020 08:39:40 +0000 (UTC)
Subject: [PATCH v2 6/6] x86/mem-paging: consistently use gfn_t
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Message-ID: <b50f9677-3b62-b071-decc-007e6a92701d@suse.com>
Date: Thu, 23 Apr 2020 10:39:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <b8437b1f-af58-70df-91d2-bd875912e57b@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Where gprintk()s get touched anyway to switch to PRI_gfn, also switch to
%pd for the domain logged.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Use gfn_t for local var in mod_l1_entry(). Use PRI_gfn when printk()
    arg is gfn_x(). Re-base.

--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -278,7 +278,7 @@ static int set_mem_type(struct domain *d
         if ( p2m_is_paging(t) )
         {
             put_gfn(d, pfn);
-            p2m_mem_paging_populate(d, pfn);
+            p2m_mem_paging_populate(d, _gfn(pfn));
             return -EAGAIN;
         }
 
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1988,7 +1988,7 @@ int hvm_hap_nested_page_fault(paddr_t gp
      * locks in such circumstance.
      */
     if ( paged )
-        p2m_mem_paging_populate(currd, gfn);
+        p2m_mem_paging_populate(currd, _gfn(gfn));
 
     if ( sharing_enomem )
     {
@@ -3222,7 +3222,7 @@ enum hvm_translation_result hvm_translat
     if ( p2m_is_paging(p2mt) )
     {
         put_page(page);
-        p2m_mem_paging_populate(v->domain, gfn_x(gfn));
+        p2m_mem_paging_populate(v->domain, gfn);
         return HVMTRANS_gfn_paged_out;
     }
     if ( p2m_is_shared(p2mt) )
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2120,16 +2120,17 @@ static int mod_l1_entry(l1_pgentry_t *pl
              paging_mode_translate(pg_dom) )
         {
             p2m_type_t p2mt;
+            gfn_t gfn = _gfn(l1e_get_pfn(nl1e));
             p2m_query_t q = l1e_get_flags(nl1e) & _PAGE_RW ?
                             P2M_ALLOC | P2M_UNSHARE : P2M_ALLOC;
 
-            page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), &p2mt, q);
+            page = get_page_from_gfn(pg_dom, gfn_x(gfn), &p2mt, q);
 
             if ( p2m_is_paged(p2mt) )
             {
                 if ( page )
                     put_page(page);
-                p2m_mem_paging_populate(pg_dom, l1e_get_pfn(nl1e));
+                p2m_mem_paging_populate(pg_dom, gfn);
                 return -ENOENT;
             }
 
@@ -3951,7 +3952,7 @@ long do_mmu_update(
                     put_page(page);
                 if ( p2m_is_paged(p2mt) )
                 {
-                    p2m_mem_paging_populate(pt_owner, gmfn);
+                    p2m_mem_paging_populate(pt_owner, _gfn(gmfn));
                     rc = -ENOENT;
                 }
                 else
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -68,7 +68,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         *pfec = PFEC_page_paged;
         if ( top_page )
             put_page(top_page);
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
+        p2m_mem_paging_populate(p2m->domain, _gfn(PFN_DOWN(cr3)));
         return gfn_x(INVALID_GFN);
     }
     if ( p2m_is_shared(p2mt) )
@@ -110,7 +110,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         {
             ASSERT(p2m_is_hostp2m(p2m));
             *pfec = PFEC_page_paged;
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+            p2m_mem_paging_populate(p2m->domain, gfn);
             return gfn_x(INVALID_GFN);
         }
         if ( p2m_is_shared(p2mt) )
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -36,12 +36,11 @@
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
-                              p2m_type_t p2mt)
+void p2m_mem_paging_drop_page(struct domain *d, gfn_t gfn, p2m_type_t p2mt)
 {
     vm_event_request_t req = {
         .reason = VM_EVENT_REASON_MEM_PAGING,
-        .u.mem_paging.gfn = gfn
+        .u.mem_paging.gfn = gfn_x(gfn)
     };
 
     /*
@@ -89,16 +88,15 @@ void p2m_mem_paging_drop_page(struct dom
  * already sent to the pager. In this case the caller has to try again until the
  * gfn is fully paged in again.
  */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn_l)
+void p2m_mem_paging_populate(struct domain *d, gfn_t gfn)
 {
     struct vcpu *v = current;
     vm_event_request_t req = {
         .reason = VM_EVENT_REASON_MEM_PAGING,
-        .u.mem_paging.gfn = gfn_l
+        .u.mem_paging.gfn = gfn_x(gfn)
     };
     p2m_type_t p2mt;
     p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int rc = vm_event_claim_slot(d, d->vm_event_paging);
@@ -106,8 +104,8 @@ void p2m_mem_paging_populate(struct doma
     /* We're paging. There should be a ring. */
     if ( rc == -EOPNOTSUPP )
     {
-        gdprintk(XENLOG_ERR, "Dom%d paging gfn %lx yet no ring in place\n",
-                 d->domain_id, gfn_l);
+        gdprintk(XENLOG_ERR, "%pd paging gfn %"PRI_gfn" yet no ring in place\n",
+                 d, gfn_x(gfn));
         /* Prevent the vcpu from faulting repeatedly on the same gfn */
         if ( v->domain == d )
             vcpu_pause_nosync(v);
@@ -218,13 +216,12 @@ void p2m_mem_paging_resume(struct domain
  * Once the p2mt is changed the page is readonly for the guest.  On success the
  * pager can write the page contents to disk and later evict the page.
  */
-static int nominate(struct domain *d, unsigned long gfn_l)
+static int nominate(struct domain *d, gfn_t gfn)
 {
     struct page_info *page;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     p2m_type_t p2mt;
     p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
     mfn_t mfn;
     int ret = -EBUSY;
 
@@ -279,12 +276,11 @@ static int nominate(struct domain *d, un
  * could evict it, eviction can not be done either. In this case the gfn is
  * still backed by a mfn.
  */
-static int evict(struct domain *d, unsigned long gfn_l)
+static int evict(struct domain *d, gfn_t gfn)
 {
     struct page_info *page;
     p2m_type_t p2mt;
     p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret = -EBUSY;
@@ -346,13 +342,12 @@ static int evict(struct domain *d, unsig
  * mfn if populate was called for  gfn which was nominated but not evicted. In
  * this case only the p2mt needs to be forwarded.
  */
-static int prepare(struct domain *d, unsigned long gfn_l,
+static int prepare(struct domain *d, gfn_t gfn,
                    XEN_GUEST_HANDLE_64(const_uint8) buffer)
 {
     struct page_info *page = NULL;
     p2m_type_t p2mt;
     p2m_access_t a;
-    gfn_t gfn = _gfn(gfn_l);
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret, page_extant = 1;
@@ -404,8 +399,8 @@ static int prepare(struct domain *d, uns
         if ( ret )
         {
             gdprintk(XENLOG_ERR,
-                     "Failed to load paging-in gfn %lx Dom%d bytes left %d\n",
-                     gfn_l, d->domain_id, ret);
+                     "Failed to load paging-in %pd gfn %"PRI_gfn" bytes left %d\n",
+                     d, gfn_x(gfn), ret);
             ret = -EFAULT;
             goto out;
         }
@@ -421,7 +416,7 @@ static int prepare(struct domain *d, uns
                                                  : p2m_ram_rw, a);
     if ( !ret )
     {
-        set_gpfn_from_mfn(mfn_x(mfn), gfn_l);
+        set_gpfn_from_mfn(mfn_x(mfn), gfn_x(gfn));
 
         if ( !page_extant )
             atomic_dec(&d->paged_pages);
@@ -465,15 +460,15 @@ int mem_paging_memop(XEN_GUEST_HANDLE_PA
     switch( mpo.op )
     {
     case XENMEM_paging_op_nominate:
-        rc = nominate(d, mpo.gfn);
+        rc = nominate(d, _gfn(mpo.gfn));
         break;
 
     case XENMEM_paging_op_evict:
-        rc = evict(d, mpo.gfn);
+        rc = evict(d, _gfn(mpo.gfn));
         break;
 
     case XENMEM_paging_op_prep:
-        rc = prepare(d, mpo.gfn, mpo.buffer);
+        rc = prepare(d, _gfn(mpo.gfn), mpo.buffer);
         if ( !rc )
             copyback = 1;
         break;
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1835,7 +1835,7 @@ void *map_domain_gfn(struct p2m_domain *
         ASSERT(p2m_is_hostp2m(p2m));
         if ( page )
             put_page(page);
-        p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+        p2m_mem_paging_populate(p2m->domain, gfn);
         *pfec = PFEC_page_paged;
         return NULL;
     }
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -848,7 +848,7 @@ int guest_wrmsr_xen(struct vcpu *v, uint
 
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, gmfn);
+                p2m_mem_paging_populate(d, _gfn(gmfn));
                 return X86EMUL_RETRY;
             }
 
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -322,7 +322,7 @@ int guest_remove_page(struct domain *d,
 
         put_gfn(d, gmfn);
 
-        p2m_mem_paging_drop_page(d, gmfn, p2mt);
+        p2m_mem_paging_drop_page(d, _gfn(gmfn), p2mt);
 
         return 0;
     }
@@ -1667,7 +1667,7 @@ int check_get_page_from_gfn(struct domai
         if ( page )
             put_page(page);
 
-        p2m_mem_paging_populate(d, gfn_x(gfn));
+        p2m_mem_paging_populate(d, gfn);
         return -EAGAIN;
     }
 #endif
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -732,10 +732,9 @@ static inline void p2m_pod_init(struct p
 int set_shared_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 
 /* Tell xenpaging to drop a paged out frame */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn, 
-                                p2m_type_t p2mt);
+void p2m_mem_paging_drop_page(struct domain *d, gfn_t gfn, p2m_type_t p2mt);
 /* Start populating a paged out frame */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
+void p2m_mem_paging_populate(struct domain *d, gfn_t gfn);
 /* Resume normal operation (in case a domain was paused) */
 struct vm_event_st;
 void p2m_mem_paging_resume(struct domain *d, struct vm_event_st *rsp);



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:19:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYxG-0007kl-SL; Thu, 23 Apr 2020 10:19:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYxF-0007kb-IB
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:19:37 +0000
X-Inumbo-ID: ecef6164-854b-11ea-83d8-bc764e2007e4
Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ecef6164-854b-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 10:19:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637173; x=1619173173;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=SdYPm/GFznwSuKyPDcCLKFoxWBcmizZriwQogmFgpi8=;
 b=pleixGnI5HRxdeecvKVYZgoo1Bog9CdpDQ+e+oqH44PnslUIBfVqW9yo
 Q1B63Xh2A4Zztg0MBI6KbVPiOZqiB3cgQeFBDNSbBNZ54NzIPDPaTlhgs
 Wu1M2ciUnUTK9dsVA3qldCAxVOdtw/vSQDVFTQWoThrFaMctXCci5ULH7 Y=;
IronPort-SDR: RruP8HKAKWseFm5VDZjhpfrDlg8mcIt3nPX+ND5I+CUaUk0Jpj/iP3XZhP277X3mSlTasC3b6n
 ampsfH6nx8rA==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="27274840"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO
 email-inbound-relay-2a-f14f4a47.us-west-2.amazon.com) ([10.43.8.2])
 by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP;
 23 Apr 2020 10:19:33 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2a-f14f4a47.us-west-2.amazon.com (Postfix) with ESMTPS
 id DA2B2A06E6; Thu, 23 Apr 2020 10:19:31 +0000 (UTC)
Received: from EX13D02EUC003.ant.amazon.com (10.43.164.10) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:31 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D02EUC003.ant.amazon.com (10.43.164.10) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:30 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:19:29 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 2/4] libc, strtol: Add isspace(), isdigit(), isxdigit(),
 isascii()
Date: Thu, 23 Apr 2020 10:19:16 +0000
Message-ID: <20200423101918.13566-3-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200423101918.13566-1-wipawel@amazon.de>
References: <20200423101918.13566-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

These ctype.h derived helper functions simplify strtol() code and will
help simplify strtoul().

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 common/lib.c            |  8 --------
 common/libc/strtol.c    |  9 +++------
 common/libc/vsnprintf.c |  8 --------
 include/xtf/libc.h      | 29 +++++++++++++++++++++++++++++
 4 files changed, 32 insertions(+), 22 deletions(-)

diff --git a/common/lib.c b/common/lib.c
index acf4da1..7381a3a 100644
--- a/common/lib.c
+++ b/common/lib.c
@@ -3,14 +3,6 @@
 #include <xtf/hypercall.h>
 #include <xtf/xenstore.h>
 
-#ifndef isdigit
-/* Avoid pulling in all of ctypes just for this. */
-static int isdigit(int c)
-{
-    return c >= '0' && c <= '9';
-}
-#endif
-
 void __noreturn panic(const char *fmt, ...)
 {
     va_list args;
diff --git a/common/libc/strtol.c b/common/libc/strtol.c
index 64ce621..f85ac7a 100644
--- a/common/libc/strtol.c
+++ b/common/libc/strtol.c
@@ -57,7 +57,7 @@ long strtol(const char *nptr, char **endptr, int base)
     s = nptr;
     do {
         c = *s++;
-    } while ( c == ' ' );
+    } while ( isspace(c) );
     if (c == '-') {
         neg = 1;
         c = *s++;
@@ -67,10 +67,7 @@ long strtol(const char *nptr, char **endptr, int base)
             c = *s++;
     }
     if ((base == 0 || base == 16) &&
-            c == '0' && (*s == 'x' || *s == 'X') &&
-            ((s[1] >= '0' && s[1] <= '9') ||
-             (s[1] >= 'A' && s[1] <= 'F') ||
-             (s[1] >= 'a' && s[1] <= 'f'))) {
+            c == '0' && (*s == 'x' || *s == 'X') && isxdigit(s[1])) {
         c = s[1];
         s += 2;
         base = 16;
@@ -104,7 +101,7 @@ long strtol(const char *nptr, char **endptr, int base)
     cutlim = cutoff % base;
     cutoff /= base;
     for ( ; ; c = *s++) {
-        if (c >= '0' && c <= '9')
+        if (isdigit(c))
             c -= '0';
         else if (c >= 'A' && c <= 'Z')
             c -= 'A' - 10;
diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
index a49fd30..495c0a5 100644
--- a/common/libc/vsnprintf.c
+++ b/common/libc/vsnprintf.c
@@ -2,14 +2,6 @@
 #include <xtf/libc.h>
 #include <xtf/compiler.h>
 
-#ifndef isdigit
-/* Avoid pulling in all of ctypes just for this. */
-static int isdigit(int c)
-{
-    return c >= '0' && c <= '9';
-}
-#endif
-
 /*
  * The subset of formatting supported:
  *
diff --git a/include/xtf/libc.h b/include/xtf/libc.h
index f352f7f..0caa7d3 100644
--- a/include/xtf/libc.h
+++ b/include/xtf/libc.h
@@ -56,6 +56,35 @@ bool arch_fmt_pointer(
     char **str, char *end, const char **fmt_ptr, const void *arg,
     int width, int precision, unsigned int flags);
 
+#ifndef isspace
+static inline int isspace(int c)
+{
+    return c == ' ' || c == '\t';
+}
+#endif
+
+#ifndef isdigit
+static inline int isdigit(int c)
+{
+    return c >= '0' && c <= '9';
+}
+#endif
+
+#ifndef isxdigit
+static inline int isxdigit(int c)
+{
+    return (isdigit(c) || (c >= 'A' && c <= 'F') ||
+           (c >= 'a' && c <= 'f'));
+}
+#endif
+
+#ifndef isascii
+static inline int isascii(int c)
+{
+    return c >= 0 && c <= 127;
+}
+#endif
+
 #endif /* XTF_LIBC_H */
 
 /*
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:19:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYxC-0007kV-Ja; Thu, 23 Apr 2020 10:19:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYxA-0007kG-SX
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:19:33 +0000
X-Inumbo-ID: ec29acf8-854b-11ea-83d8-bc764e2007e4
Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ec29acf8-854b-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 10:19:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637172; x=1619173172;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=G/m3KuxGHbfU+DBNHOF/luWPlZ6kzIdxDz0P5fCKYf8=;
 b=naRSXbVcQ9Zu3t0iYaygddzggzsMiGxN2VOYtX/OWbPVNshBlCY6kHwm
 4Z7TZlimzJguuZF171t80TrR2g1O3Z6AL184bCUFniJtd+A/w/iGEm3Sv
 sRAGzxvXiTdxTK82YALBuRqUYEDYsVCSQaKGutYZ2+qyYIg92RHcnbPIf M=;
IronPort-SDR: 9oLJ81RDEQ1LcuYVJhv2NK1JbRjTMXbjVwH6uRndoqSVxsJIbSXoC0NU9h9JPOTe8W87C9e+25
 6BSyfngpzdrg==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="27274836"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO
 email-inbound-relay-2a-f14f4a47.us-west-2.amazon.com) ([10.43.8.2])
 by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP;
 23 Apr 2020 10:19:31 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2a-f14f4a47.us-west-2.amazon.com (Postfix) with ESMTPS
 id 16DC3A07DA; Thu, 23 Apr 2020 10:19:30 +0000 (UTC)
Received: from EX13D05EUC002.ant.amazon.com (10.43.164.231) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:29 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D05EUC002.ant.amazon.com (10.43.164.231) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:28 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:19:27 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 1/4] string: add freebds libc implementation of strtol()
Date: Thu, 23 Apr 2020 10:19:15 +0000
Message-ID: <20200423101918.13566-2-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200423101918.13566-1-wipawel@amazon.de>
References: <20200423101918.13566-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Semel <phentex@amazon.de>

Added freebsd libc implementation of the strtol() function.
Original can be found here :
https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/strtol.c

Signed-off-by: Paul Semel <phentex@amazon.de>
---
 build/files.mk       |   1 +
 common/libc/strtol.c | 135 +++++++++++++++++++++++++++++++++++++++++++++++++++
 include/xtf/libc.h   |   2 +
 3 files changed, 138 insertions(+)
 create mode 100644 common/libc/strtol.c

diff --git a/build/files.mk b/build/files.mk
index dfa27e4..ebc36aa 100644
--- a/build/files.mk
+++ b/build/files.mk
@@ -13,6 +13,7 @@ obj-perarch += $(ROOT)/common/lib.o
 obj-perarch += $(ROOT)/common/libc/stdio.o
 obj-perarch += $(ROOT)/common/libc/string.o
 obj-perarch += $(ROOT)/common/libc/vsnprintf.o
+obj-perarch += $(ROOT)/common/libc/strtol.o
 obj-perarch += $(ROOT)/common/report.o
 obj-perarch += $(ROOT)/common/setup.o
 obj-perarch += $(ROOT)/common/xenbus.o
diff --git a/common/libc/strtol.c b/common/libc/strtol.c
new file mode 100644
index 0000000..64ce621
--- /dev/null
+++ b/common/libc/strtol.c
@@ -0,0 +1,135 @@
+/*-
+ * Copyright (c) 1990, 1993
+ *  The Regents of the University of California.  All rights reserved.
+ *
+ * Copyright (c) 2011 The FreeBSD Foundation
+ * All rights reserved.
+ * Portions of this software were developed by David Chisnall
+ * under sponsorship from the FreeBSD Foundation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Convert a string to a long integer.
+ *
+ * Assumes that the upper and lower case
+ * alphabets and digits are each contiguous.
+ */
+
+#include <xtf/libc.h>
+
+long strtol(const char *nptr, char **endptr, int base)
+{
+    const char *s;
+    unsigned long acc;
+    char c;
+    unsigned long cutoff;
+    int neg, any, cutlim;
+
+    /*
+     * Skip white space and pick up leading +/- sign if any.
+     * If base is 0, allow 0x for hex and 0 for octal, else
+     * assume decimal; if base is already 16, allow 0x.
+     */
+    s = nptr;
+    do {
+        c = *s++;
+    } while ( c == ' ' );
+    if (c == '-') {
+        neg = 1;
+        c = *s++;
+    } else {
+        neg = 0;
+        if (c == '+')
+            c = *s++;
+    }
+    if ((base == 0 || base == 16) &&
+            c == '0' && (*s == 'x' || *s == 'X') &&
+            ((s[1] >= '0' && s[1] <= '9') ||
+             (s[1] >= 'A' && s[1] <= 'F') ||
+             (s[1] >= 'a' && s[1] <= 'f'))) {
+        c = s[1];
+        s += 2;
+        base = 16;
+    }
+    if (base == 0)
+        base = c == '0' ? 8 : 10;
+    acc = any = 0;
+    if (base < 2 || base > 36)
+        goto noconv;
+
+    /*
+     * Compute the cutoff value between legal numbers and illegal
+     * numbers.  That is the largest legal value, divided by the
+     * base.  An input number that is greater than this value, if
+     * followed by a legal input character, is too big.  One that
+     * is equal to this value may be valid or not; the limit
+     * between valid and invalid numbers is then based on the last
+     * digit.  For instance, if the range for longs is
+     * [-2147483648..2147483647] and the input base is 10,
+     * cutoff will be set to 214748364 and cutlim to either
+     * 7 (neg==0) or 8 (neg==1), meaning that if we have accumulated
+     * a value > 214748364, or equal but the next digit is > 7 (or 8),
+     * the number is too big, and we will return a range error.
+     *
+     * Set 'any' if any `digits' consumed; make it negative to indicate
+     * overflow.
+     */
+
+    cutoff = neg ? (unsigned long)-(LONG_MIN + LONG_MAX) + LONG_MAX
+        : LONG_MAX;
+    cutlim = cutoff % base;
+    cutoff /= base;
+    for ( ; ; c = *s++) {
+        if (c >= '0' && c <= '9')
+            c -= '0';
+        else if (c >= 'A' && c <= 'Z')
+            c -= 'A' - 10;
+        else if (c >= 'a' && c <= 'z')
+            c -= 'a' - 10;
+        else
+            break;
+        if (c >= base)
+            break;
+        if (any < 0 || acc > cutoff || (acc == cutoff && c > cutlim))
+            any = -1;
+        else {
+            any = 1;
+            acc *= base;
+            acc += c;
+        }
+    }
+    if (any < 0) {
+        acc = neg ? LONG_MIN : LONG_MAX;
+    } else if (!any) {
+noconv:
+        ;
+    } else if (neg)
+        acc = -acc;
+    if (endptr != NULL)
+        *endptr = (char *)(any ? s - 1 : nptr);
+    return (acc);
+}
diff --git a/include/xtf/libc.h b/include/xtf/libc.h
index 66f834b..f352f7f 100644
--- a/include/xtf/libc.h
+++ b/include/xtf/libc.h
@@ -35,6 +35,8 @@ void *memcpy(void *dst, const void *src, size_t n);
 int memcmp(const void *s1, const void *s2, size_t n);
 #define memcmp(s1, s2, n)           __builtin_memcmp(s1, s2, n)
 
+long strtol(const char *nptr, char **endptr, int base);
+
 size_t strnlen(const char *str, size_t max);
 
 int __printf(3, 0)
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:19:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYxC-0007kP-BF; Thu, 23 Apr 2020 10:19:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYxA-0007kF-R5
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:19:33 +0000
X-Inumbo-ID: eae7a78c-854b-11ea-933e-12813bfff9fa
Received: from smtp-fw-6002.amazon.com (unknown [52.95.49.90])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id eae7a78c-854b-11ea-933e-12813bfff9fa;
 Thu, 23 Apr 2020 10:19:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637170; x=1619173170;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=J09gZiCqrnzq7LaZQLaTXoR+4ZFbAgEOhD3e9rqYQfg=;
 b=ITGfZt4tOVgmfuiVCYtTBiiWZI1exlTOZgx8hDhcXlZqJw+X0FphRx79
 sJTJ+OcyQ3fF+B5bKJpJblb6aYZW8cjaJ/npBoRPXMGjJ/VBiD5Ttpr/i
 vh4Lf+ZYGn8GjLvBUiurIdLozVCYKyAlho0OQYsBN16G98NhJleVchHkY 0=;
IronPort-SDR: PmiDU/I6+ZHxmJHnoAyDPoAqfcHNdRFFeGEfte72Je0suZWryq6O0/lvp/1v6wLsAAYXZ+eKDR
 KVDBNoJ9aFwQ==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="26939009"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2a-119b4f96.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP;
 23 Apr 2020 10:19:29 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2a-119b4f96.us-west-2.amazon.com (Postfix) with ESMTPS
 id 27D0C1A0B38; Thu, 23 Apr 2020 10:19:28 +0000 (UTC)
Received: from EX13D05EUB003.ant.amazon.com (10.43.166.253) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:27 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D05EUB003.ant.amazon.com (10.43.166.253) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:27 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:19:25 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 0/4] Add strncmp(), strtol() and strtoul() functions
Date: Thu, 23 Apr 2020 10:19:14 +0000
Message-ID: <20200423101918.13566-1-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add FreeBSD's implementation of strtol() and strtoul() functions from:
https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/strtoul.c

The FreeBSD code being added as a separate file (common/libc/strtol.c)
is under the BSD 3-clause license. Modification to COPYING file might
be needed.

Also add simple implementation of the strncmp() function.

Paul Semel (1):
  string: add freebds libc implementation of strtol()

Pawel Wieczorkiewicz (3):
  libc, strtol: Add isspace(), isdigit(), isxdigit(), isascii()
  libc, strtol: Add FreeBSD libc implementation of strtoul()
  libc: add strncmp() function

 build/files.mk          |   1 +
 common/lib.c            |   8 --
 common/libc/string.c    |  11 +++
 common/libc/strtol.c    | 201 ++++++++++++++++++++++++++++++++++++++++++++++++
 common/libc/vsnprintf.c |   8 --
 include/xtf/libc.h      |  35 +++++++++
 6 files changed, 248 insertions(+), 16 deletions(-)
 create mode 100644 common/libc/strtol.c

-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:20:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:20:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYxf-000824-9L; Thu, 23 Apr 2020 10:20:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYxe-0007uB-3O
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:20:02 +0000
X-Inumbo-ID: fd8138a4-854b-11ea-933e-12813bfff9fa
Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fd8138a4-854b-11ea-933e-12813bfff9fa;
 Thu, 23 Apr 2020 10:20:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637201; x=1619173201;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=iTRlqoQz/hwVOrBz98h6nOzsiS/zGlpC/yEg6ke2u/k=;
 b=XahiXqLR6pxW1mFqorpoJeRQmrymJZqWatRr1jLtCfgGDpbjBj+6Wm29
 dRDH20z5TREZsnnLWi2EvYAbzqXnziyoVrCuex4ylm7xvvKcgYL1M3uwD
 2GrNcqkdATBwDSE4Hc6lhSOhp1Ddly2qH5ynH6LKeLr4olAm2mb1+qKp4 0=;
IronPort-SDR: Ju56CU/S7dcvA7N2sl0BwzWqFa0Ux6JvUZ6bxeZVu7wJYFrDf9IzVvXLSEc9lTadLiyvlJlv9n
 bL3NNzc65E7w==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="39000741"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2a-53356bf6.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP;
 23 Apr 2020 10:19:59 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2a-53356bf6.us-west-2.amazon.com (Postfix) with ESMTPS
 id EA7D0A1DB7; Thu, 23 Apr 2020 10:19:58 +0000 (UTC)
Received: from EX13D02EUC004.ant.amazon.com (10.43.164.117) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:35 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D02EUC004.ant.amazon.com (10.43.164.117) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:33 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:19:32 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 4/4] libc: add strncmp() function
Date: Thu, 23 Apr 2020 10:19:18 +0000
Message-ID: <20200423101918.13566-5-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200423101918.13566-1-wipawel@amazon.de>
References: <20200423101918.13566-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 common/libc/string.c | 11 +++++++++++
 include/xtf/libc.h   |  3 +++
 2 files changed, 14 insertions(+)

diff --git a/common/libc/string.c b/common/libc/string.c
index 5c25e27..d81e324 100644
--- a/common/libc/string.c
+++ b/common/libc/string.c
@@ -56,6 +56,17 @@ int (strcmp)(const char *_s1, const char *_s2)
     return (s1 < s2) ? -1 : (s1 > s2);
 }
 
+int (strncmp)(const char *_s1, const char *_s2, size_t n)
+{
+    size_t ctr;
+    for (ctr = 0; ctr < n; ctr++) {
+        if (_s1[ctr] != _s2[ctr])
+            return (int)(_s1[ctr] - _s2[ctr]);
+    }
+
+    return 0;
+}
+
 void *(memset)(void *s, int c, size_t n)
 {
     char *p = s;
diff --git a/include/xtf/libc.h b/include/xtf/libc.h
index 75f193b..c3783a8 100644
--- a/include/xtf/libc.h
+++ b/include/xtf/libc.h
@@ -26,6 +26,9 @@ char *strncpy(char *dst, const char *src, size_t n);
 int strcmp(const char *s1, const char *s2);
 #define strcmp(s1, s2)              __builtin_strcmp(s1, s2)
 
+int strncmp(const char *s1, const char *s2, size_t n);
+#define strncmp(s1, s2, n)          __builtin_strncmp(s1, s2, n)
+
 void *memset(void *s, int c, size_t n);
 #define memset(d, c, n)             __builtin_memset(d, c, n)
 
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:20:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYxo-0008Vm-Kb; Thu, 23 Apr 2020 10:20:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYxn-0008VN-91
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:20:11 +0000
X-Inumbo-ID: 034d961a-854c-11ea-83d8-bc764e2007e4
Received: from smtp-fw-6001.amazon.com (unknown [52.95.48.154])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 034d961a-854c-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 10:20:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637211; x=1619173211;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=aBOG/6W6YvsGazAUBqvfFvgqMcAkzkVroszf6yNe9L8=;
 b=kuMJ4xYfeMFjNAdFAznC3Tr/cN2iHgkRR3/hTHI6ej+oVpT8zXVHLE4/
 EjbsU9LOJOh5QCM630+kXwv5PMaTdbJwrw+tj94AuLUiOpyKCt0SZLnVn
 x6N7uPQ4u0IRlbo2SsO9V4DR5T5fx2o70pryrH6tTz2BdxRyhRLn31GKy c=;
IronPort-SDR: TKykPitZHv6+bNPeNmKtlVtViLcZQbXOJCXY+qrfV0dNcNdOJ+/MgtTvRKy0kJx+19vEbMG38x
 RTKoKA7hPdig==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="28374691"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2b-c7131dcf.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP;
 23 Apr 2020 10:19:58 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2b-c7131dcf.us-west-2.amazon.com (Postfix) with ESMTPS
 id 3BC25A2454; Thu, 23 Apr 2020 10:19:57 +0000 (UTC)
Received: from EX13D05EUC001.ant.amazon.com (10.43.164.118) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:33 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D05EUC001.ant.amazon.com (10.43.164.118) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:19:32 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:19:30 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF 3/4] libc, strtol: Add FreeBSD libc implementation of strtoul()
Date: Thu, 23 Apr 2020 10:19:17 +0000
Message-ID: <20200423101918.13566-4-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200423101918.13566-1-wipawel@amazon.de>
References: <20200423101918.13566-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The function was derived from:
https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/strtoul.c

Sligthly modified to use ctypes helpers and ignore locale.

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 common/libc/strtol.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/xtf/libc.h   |  1 +
 2 files changed, 70 insertions(+)

diff --git a/common/libc/strtol.c b/common/libc/strtol.c
index f85ac7a..66ba787 100644
--- a/common/libc/strtol.c
+++ b/common/libc/strtol.c
@@ -130,3 +130,72 @@ long strtol(const char *nptr, char **endptr, int base)
         *endptr = (char *)(any ? s - 1 : nptr);
     return (acc);
 }
+
+/*
+ * Convert a string to an unsigned long integer.
+ *
+ * Ignores `locale' stuff. Assumes that the upper and lower case
+ * alphabets and digits are each contiguous.
+ */
+unsigned long strtoul(const char *nptr, char **endptr, int base)
+{
+    const char *s = nptr;
+    unsigned long acc;
+    unsigned char c;
+    unsigned long cutoff;
+    int neg = 0, any, cutlim;
+
+    /*
+     * See strtol for comments as to the logic used.
+     */
+    do {
+        c = *s++;
+    } while (isspace(c));
+    if (c == '-') {
+        neg = 1;
+        c = *s++;
+    } else if (c == '+')
+        c = *s++;
+    if ((base == 0 || base == 16) &&
+            c == '0' && (*s == 'x' || *s == 'X') && isxdigit(s[1])) {
+        c = s[1];
+        s += 2;
+        base = 16;
+    }
+    if (base == 0)
+        base = c == '0' ? 8 : 10;
+    acc = any = 0;
+    if (base < 2 || base > 36)
+        goto noconv;
+
+    cutoff = (unsigned long)ULONG_MAX / (unsigned long)base;
+    cutlim = (unsigned long)ULONG_MAX % (unsigned long)base;
+    for ( ; ; c = *s++) {
+        if (isdigit(c))
+            c -= '0';
+        else if (c >= 'A' && c <= 'Z')
+            c -= 'A' - 10;
+        else if (c >= 'a' && c <= 'z')
+            c -= 'a' - 10;
+        else
+            break;
+        if (c >= base)
+            break;
+        if (any < 0 || acc > cutoff || (acc == cutoff && c > cutlim))
+            any = -1;
+        else {
+            any = 1;
+            acc *= base;
+            acc += c;
+        }
+    }
+    if (any < 0) {
+        acc = ULONG_MAX;
+    } else if (!any) {
+noconv: ;
+    } else if (neg)
+        acc = -acc;
+    if (endptr != NULL)
+        *endptr = (char *)(any ? s - 1 : nptr);
+    return (acc);
+}
diff --git a/include/xtf/libc.h b/include/xtf/libc.h
index 0caa7d3..75f193b 100644
--- a/include/xtf/libc.h
+++ b/include/xtf/libc.h
@@ -36,6 +36,7 @@ int memcmp(const void *s1, const void *s2, size_t n);
 #define memcmp(s1, s2, n)           __builtin_memcmp(s1, s2, n)
 
 long strtol(const char *nptr, char **endptr, int base);
+unsigned long strtoul(const char *nptr, char **endptr, int base);
 
 size_t strnlen(const char *str, size_t max);
 
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:20:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:20:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYy8-0000B6-Vh; Thu, 23 Apr 2020 10:20:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYy7-0000AB-93
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:20:31 +0000
X-Inumbo-ID: 0f0d0f76-854c-11ea-933e-12813bfff9fa
Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0f0d0f76-854c-11ea-933e-12813bfff9fa;
 Thu, 23 Apr 2020 10:20:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637231; x=1619173231;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=FA21mCdHll/rCD+CdQJA+A8GO9v6LBIhxlYvWv3fymI=;
 b=FqZbLvn9EsPOxxKqWXbwWZcRSziErBhTbi3nJvNSmOfVbc+VBjBWYqDS
 saUMzTWA/sNAqfrx3ktVJtq59U9uy7DsVYlunoCK/NgCzhUlg2WUaSQ+B
 mEeWA4jrTWWvPStlXh6yP0rbOaPXtpH0wyzYYhurRh5ydxYNhnuKUUZtJ Q=;
IronPort-SDR: Qtdg0ScsyKudTkS6Uwe+BZ1jNO5g82NyOrJWdgcbA4QHpsIQItEEPxbvvOFDU3kbykAOoZLgie
 OjFeAGZ3kGlg==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="39000805"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP;
 23 Apr 2020 10:20:30 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com (Postfix) with ESMTPS
 id C57D0A1BEF; Thu, 23 Apr 2020 10:20:29 +0000 (UTC)
Received: from EX13D02EUC003.ant.amazon.com (10.43.164.10) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:01 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D02EUC003.ant.amazon.com (10.43.164.10) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:00 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:19:59 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF v2 v2 0/4] Small fixes and improvements
Date: Thu, 23 Apr 2020 10:19:51 +0000
Message-ID: <20200423101955.13761-1-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is the first series of XTF patches I intend to send.
It covers some relatively small changes displaying Xen version on test
start, as well as adding serial consol support for HVM guests..

Paul Semel (1):
  Enabled serial writing for hvm guests

Pawel Wieczorkiewicz (3):
  lib: Add XEN_MAJOR() and XEN_MINOR() macros
  lib: always append CR after LF in vsnprintf()
  setup: Detect and display Xen version on test startup

 arch/x86/setup.c        | 22 +++++++++++++++++++++-
 common/console.c        |  3 ++-
 common/libc/vsnprintf.c | 10 ++++++++++
 common/setup.c          |  6 +++++-
 include/xtf/framework.h |  2 +-
 include/xtf/lib.h       |  3 +++
 tests/xsa-213/main.c    |  4 ++--
 7 files changed, 44 insertions(+), 6 deletions(-)

-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:20:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYyD-0000DC-Bk; Thu, 23 Apr 2020 10:20:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYyC-0000Cf-97
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:20:36 +0000
X-Inumbo-ID: 121e585a-854c-11ea-933f-12813bfff9fa
Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 121e585a-854c-11ea-933f-12813bfff9fa;
 Thu, 23 Apr 2020 10:20:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637236; x=1619173236;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=UEPw6O3BljFwct47izeBxnxQHVPFN3vhQxafqb4+2o0=;
 b=TUB8DkG4tjLKAkHS0Yxn/ZQGIfJRRKv+Nfn0OQ1+6mYGIoC0CrPkCNlt
 fIMzIjj2xSbEIQ1utjNHMEoK2IoQAJo9PEXM7kIVgAEaQ/+DOWP2/4gL7
 mxLMpjyZowBMnG+6JVKbpbZknXNmS8nxXKzAnm9HSzRKaviYj5+iLoGON U=;
IronPort-SDR: pE/Vkb8G3n4UPrsL4P+p6sU4qAL/VOKEtuXsUVsH+a21YJdftrc4H6v2Z69Z4vKp41Icb2c8yc
 ap/6DAKwgfyg==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="39000814"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2a-119b4f96.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP;
 23 Apr 2020 10:20:35 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2a-119b4f96.us-west-2.amazon.com (Postfix) with ESMTPS
 id F003F1A096C; Thu, 23 Apr 2020 10:20:34 +0000 (UTC)
Received: from EX13D05EUC001.ant.amazon.com (10.43.164.118) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:03 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D05EUC001.ant.amazon.com (10.43.164.118) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:02 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:20:01 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF v2 v2 1/4] lib: Add XEN_MAJOR() and XEN_MINOR() macros
Date: Thu, 23 Apr 2020 10:19:52 +0000
Message-ID: <20200423101955.13761-2-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200423101955.13761-1-wipawel@amazon.de>
References: <20200423101955.13761-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

These are just a simple macros obtaining major, minor values as
returned by xen_version hypercall.

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
 include/xtf/lib.h    | 3 +++
 tests/xsa-213/main.c | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/xtf/lib.h b/include/xtf/lib.h
index 3348464..40e5731 100644
--- a/include/xtf/lib.h
+++ b/include/xtf/lib.h
@@ -20,6 +20,9 @@
 
 #define ACCESS_ONCE(x)   (*(volatile typeof(x) *)&(x))
 
+#define XEN_MAJOR(v) (((v) >> 16) & 0xFFFF)
+#define XEN_MINOR(v) ((v) & 0xFFFF)
+
 void __noreturn panic(const char *fmt, ...) __printf(1, 2);
 
 #define ASSERT(cond)                                    \
diff --git a/tests/xsa-213/main.c b/tests/xsa-213/main.c
index 64e7065..0353168 100644
--- a/tests/xsa-213/main.c
+++ b/tests/xsa-213/main.c
@@ -121,8 +121,8 @@ void test_main(void)
 {
     long rc, xen_version = hypercall_xen_version(XENVER_version, NULL);
 
-    printk("Found Xen %ld.%ld\n",
-           (xen_version >> 16) & 0xffff, xen_version & 0xffff);
+    printk("Found Xen %ld.%ld\n", XEN_MAJOR(xen_version),
+           XEN_MINOR(xen_version));
 
     xtf_set_idte(X86_VEC_AVAIL, &idte);
 
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:20:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYyG-0000Ep-LW; Thu, 23 Apr 2020 10:20:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYyF-0000EQ-Lm
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:20:39 +0000
X-Inumbo-ID: 1451a91a-854c-11ea-b4f4-bc764e2007e4
Received: from smtp-fw-6002.amazon.com (unknown [52.95.49.90])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1451a91a-854c-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 10:20:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637239; x=1619173239;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=j3FfvDGo3qJ5fQVQXM9t+enbQsU+W2azdmSHMXpnb3c=;
 b=GSdEeXrT4yJAXvX0AYbSsqOuut8UaGIicNq8g+KRdGJCmyt3WYibXFcC
 SKfRJ9600pkSOCNW3eQrAb+b2ouE9Xp1Pcx2OvMl7s5bA/5eNi0PYQoqg
 kMp/ozUq7O7s/jkKCBADY2NMVdmi5wlWy6Aj5Hh7uU0k+lVJc9wCDHB+C M=;
IronPort-SDR: rbU6kMBziHV1szQVK5WuWQIjmpuakKme6MeqhKcZJasEf/NfJOmBftSy5gESGJTu8LImbnCk5A
 bd1wItlvqVpg==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="26939148"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-2c-397e131e.us-west-2.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP;
 23 Apr 2020 10:20:38 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2c-397e131e.us-west-2.amazon.com (Postfix) with ESMTPS
 id B2B38A271A; Thu, 23 Apr 2020 10:20:37 +0000 (UTC)
Received: from EX13D02EUB001.ant.amazon.com (10.43.166.150) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:05 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D02EUB001.ant.amazon.com (10.43.166.150) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:05 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:20:03 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF v2 v2 2/4] lib: always append CR after LF in vsnprintf()
Date: Thu, 23 Apr 2020 10:19:53 +0000
Message-ID: <20200423101955.13761-3-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200423101955.13761-1-wipawel@amazon.de>
References: <20200423101955.13761-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The explicit LFCR sequence guarantees proper line by line formatting
in the output.
The '\n' character alone on some terminals is not automatically
converted to LFCR.

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
Changed since v1:
  * Emit CRLF instead of LFCR

 common/libc/vsnprintf.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
index a49fd30..b9a4fab 100644
--- a/common/libc/vsnprintf.c
+++ b/common/libc/vsnprintf.c
@@ -284,7 +284,17 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
         /* Put regular characters into the destination. */
         if ( *fmt != '%' )
         {
+            /*
+             * The '\n' character alone on some terminals is not automatically
+             * converted to CRLF.
+             * The explicit CRLF sequence guarantees proper line by line
+             * formatting in the output.
+             */
+            if ( *fmt == '\n' && str < end )
+                PUT('\r');
+
             PUT(*fmt);
+
             continue;
         }
 
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:20:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:20:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYyJ-0000GE-0Y; Thu, 23 Apr 2020 10:20:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYyH-0000FJ-98
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:20:41 +0000
X-Inumbo-ID: 14fe0462-854c-11ea-933f-12813bfff9fa
Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 14fe0462-854c-11ea-933f-12813bfff9fa;
 Thu, 23 Apr 2020 10:20:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637241; x=1619173241;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=HiisovRaNwUVzKLO6bCQTn0qmgMmDEJUOogYX7aiDJQ=;
 b=Iw/V6jbKdwyK5l81Rnpm9Nxg/yUawksT4C3FBkFFEqjiST7JlGgmFZ0o
 +a90y98N/iBC5kA6AwfT4qyTFYWWXEvvMBK9ZvVuWNPujh0XsULSpKt/n
 PZOn3lS5mOkf+VPduWTWfsRHHbK3xdKYQbVJc+Gfqf0jfbTJTbC1W0zar 0=;
IronPort-SDR: zs0Duf4Xub3vFvvZ5PitbdHS78SI57IbNFprip9HCA3wj9U1K0m3dvhPBBKHJFnAhZVAtOGfwo
 PK+s4w8LYcBw==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="39000829"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2c-6f38efd9.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP;
 23 Apr 2020 10:20:40 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166])
 by email-inbound-relay-2c-6f38efd9.us-west-2.amazon.com (Postfix) with ESMTPS
 id C6A11A2440; Thu, 23 Apr 2020 10:20:39 +0000 (UTC)
Received: from EX13D02EUB004.ant.amazon.com (10.43.166.221) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:07 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D02EUB004.ant.amazon.com (10.43.166.221) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:06 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:20:05 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF v2 v2 3/4] Enabled serial writing for hvm guests
Date: Thu, 23 Apr 2020 10:19:54 +0000
Message-ID: <20200423101955.13761-4-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200423101955.13761-1-wipawel@amazon.de>
References: <20200423101955.13761-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Semel <phentex@amazon.de>

setup.c: PV console writing is not working in Xen 4.2 for hvm
guests, so we make xtf write to COM1 serial port to get its output

Signed-off-by: Paul Semel <phentex@amazon.de>
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
Changed since v1:
  * Increase callbacks array

 arch/x86/setup.c | 14 ++++++++++++++
 common/console.c |  3 ++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 3c84e96..f6fa4df 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -238,6 +238,13 @@ static void qemu_console_write(const char *buf, size_t len)
                  : "d" (0x12));
 }
 
+static void com1_write(const char *buf, size_t len)
+{
+    asm volatile("rep; outsb"
+                 : "+S" (buf), "+c" (len)
+                 : "d" (0x3f8));
+}
+
 static void xen_console_write(const char *buf, size_t len)
 {
     hypercall_console_write(buf, len);
@@ -246,7 +253,14 @@ static void xen_console_write(const char *buf, size_t len)
 void arch_setup(void)
 {
     if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
+    {
         register_console_callback(qemu_console_write);
+    }
+
+    if ( IS_DEFINED(CONFIG_HVM) )
+    {
+        register_console_callback(com1_write);
+    }
 
     register_console_callback(xen_console_write);
 
diff --git a/common/console.c b/common/console.c
index 0724fc9..00dbbca 100644
--- a/common/console.c
+++ b/common/console.c
@@ -13,8 +13,9 @@
  * - Xen hypervisor console
  * - PV console
  * - Qemu debug console
+ * - COM1 serial console
  */
-static cons_output_cb output_fns[3];
+static cons_output_cb output_fns[4];
 static unsigned int nr_cons_cb;
 
 /* Guest PV console details. */
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:20:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:20:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYyN-0000Kc-Fw; Thu, 23 Apr 2020 10:20:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=19NY=6H=amazon.de=prvs=375504273=wipawel@srs-us1.protection.inumbo.net>)
 id 1jRYyM-0000Jo-9R
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 10:20:46 +0000
X-Inumbo-ID: 165d3ce2-854c-11ea-933f-12813bfff9fa
Received: from smtp-fw-9101.amazon.com (unknown [207.171.184.25])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 165d3ce2-854c-11ea-933f-12813bfff9fa;
 Thu, 23 Apr 2020 10:20:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
 t=1587637243; x=1619173243;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version;
 bh=CjFqQ+keD3M1wnKEBrWhKs4cY4eZTedQKArYB4JSIjI=;
 b=jahZ6TB8nHqnN8S6uIs8JGd/aYoz8wo2mwnSYi5FmZIxkNxMygSuYdUv
 4vS+DBY074lUvZmmV80tSZwFzIQX2L6K608yD6mcW/C+Z+AmMRu7+d035
 OVs+PF+1l5PtUJ065yDtr40SZI3D04mwDGr0n7xPN0ZOAzXc13T6PIsg8 I=;
IronPort-SDR: /jbhi4Q56Gsl6ZEf5UWIXHnH0gc7bFQXGSzWLpPBXKEuTjzOlH1g7u/iYEjqd2B076yb/8p1qv
 NHYEjCIi1AbQ==
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="30669955"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO
 email-inbound-relay-2b-a7fdc47a.us-west-2.amazon.com) ([10.47.23.38])
 by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP;
 23 Apr 2020 10:20:42 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162])
 by email-inbound-relay-2b-a7fdc47a.us-west-2.amazon.com (Postfix) with ESMTPS
 id EF32BC693C; Thu, 23 Apr 2020 10:20:41 +0000 (UTC)
Received: from EX13D02EUB002.ant.amazon.com (10.43.166.170) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:09 +0000
Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by
 EX13D02EUB002.ant.amazon.com (10.43.166.170) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Thu, 23 Apr 2020 10:20:08 +0000
Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33)
 by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id
 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 10:20:07 +0000
From: Pawel Wieczorkiewicz <wipawel@amazon.de>
To: <xen-devel@lists.xen.org>
Subject: [XTF v2 v2 4/4] setup: Detect and display Xen version on test startup
Date: Thu, 23 Apr 2020 10:19:55 +0000
Message-ID: <20200423101955.13761-5-wipawel@amazon.de>
X-Mailer: git-send-email 2.16.6
In-Reply-To: <20200423101955.13761-1-wipawel@amazon.de>
References: <20200423101955.13761-1-wipawel@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, wipawel@xen.org, paul@xen.org, semelpaul@gmail.com,
 andrew.cooper3@citrix.com, wipawel@amazon.de, nmanthey@amazon.de
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In arch_setup() detect Xen version by issuing xen_version hypercall
and optionally pass the version to main_xtf().

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
Changed since v1:
  * Do not limit setup_pv_console() to HVM only. It does not crash.
    It merely panics because the callbacks array wasn't increased.

 arch/x86/setup.c        | 8 +++++++-
 common/setup.c          | 6 +++++-
 include/xtf/framework.h | 2 +-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index f6fa4df..15ca3bb 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -250,8 +250,10 @@ static void xen_console_write(const char *buf, size_t len)
     hypercall_console_write(buf, len);
 }
 
-void arch_setup(void)
+void arch_setup(int *version)
 {
+    int xen_version;
+
     if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
     {
         register_console_callback(qemu_console_write);
@@ -272,6 +274,10 @@ void arch_setup(void)
 
     init_hypercalls();
 
+    xen_version = hypercall_xen_version(XENVER_version, NULL);
+    if ( version )
+        *version = xen_version;
+
     if ( !is_initdomain() )
     {
         setup_pv_console();
diff --git a/common/setup.c b/common/setup.c
index 932fc09..1d3da15 100644
--- a/common/setup.c
+++ b/common/setup.c
@@ -19,9 +19,13 @@
  */
 void __noreturn xtf_main(void)
 {
-    arch_setup();
+    int xen_version;
+
+    arch_setup(&xen_version);
 
     printk("--- Xen Test Framework ---\n");
+    printk("Found Xen: %d.%d\n", XEN_MAJOR(xen_version),
+           XEN_MINOR(xen_version));
     printk("Environment: %s\n", environment_description);
     printk("%s\n", test_title);
 
diff --git a/include/xtf/framework.h b/include/xtf/framework.h
index a71bf39..6664733 100644
--- a/include/xtf/framework.h
+++ b/include/xtf/framework.h
@@ -2,7 +2,7 @@
 #define XTF_FRAMEWORK_H
 
 /* To be implemented by each arch */
-void arch_setup(void);
+void arch_setup(int *);
 void test_setup(void);
 
 /* Single line summary of execution environment. */
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:21:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYyh-0000W2-St; Thu, 23 Apr 2020 10:21:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRYyg-0000V9-5j
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:21:06 +0000
X-Inumbo-ID: 233ae090-854c-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 233ae090-854c-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 10:21:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=dcllbC0+ScxYQw+k3GcMF2yJz8ZfskbYDdPywObVBwU=; b=1wVsuT/oaMCR00oxGHbkqedNu
 GZjh4LV4DNSg4dFeSLlX5q/DzxmGuEmngwb1P9Sb3ti97h9M2sXnKBF+4MvXfgceFpsPtOv7hIqZ9
 Xk/mOQZknKqCUvHxMBqP/05IIN848G3OGWd0AubN9peGYgM/ln4H/WFDpxBxzYpImUCFI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRYye-00008y-75; Thu, 23 Apr 2020 10:21:04 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRYyd-0001h5-Va; Thu, 23 Apr 2020 10:21:04 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRYyd-0006B0-Uw; Thu, 23 Apr 2020 10:21:03 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149741-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149741: tolerable trouble: fail/pass/starved -
 PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 xen-unstable:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: xen=a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
X-Osstest-Versions-That: xen=82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 10:21:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149741 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149741/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149705
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149705
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149705
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149705
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149705
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149705
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149705
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149705
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149705
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149705
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate               starved  n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate               starved  n/a

version targeted for testing:
 xen                  a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
baseline version:
 xen                  82dd1a956d9b68f52e830d1dddfdfb4ab4d5a638

Last test of basis   149705  2020-04-21 10:39:06 Z    1 days
Failing since        149726  2020-04-21 22:07:46 Z    1 days    2 attempts
Testing same since   149741  2020-04-22 16:56:41 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christian Lindig <christian.lindig@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Julien Grall <julien@xen.org>
  Peng Fan <peng.fan@nxp.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                starved 
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 starved 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   82dd1a956d..a62c6fe05c  a62c6fe05c4ae905b7d4cb0ca946508b7f96d522 -> master


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:21:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRYyr-0000b4-7t; Thu, 23 Apr 2020 10:21:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wmme=6H=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRYyq-0000aR-50
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:21:16 +0000
X-Inumbo-ID: 25e3e648-854c-11ea-9e09-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 25e3e648-854c-11ea-9e09-bc764e2007e4;
 Thu, 23 Apr 2020 10:21:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587637269;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=Qdrl+m80ROoxK7XC/bSwEIx/8r9Om1BCnSG37SUyoqE=;
 b=aTgQrQ8RRcQmWDlHEJNm9dcc+gVsKAR0S/7nbdAR6FT7fapWOcr/idXg
 a6+tMBS0UFku1ingiX8MNGqXMy+vM5ZQMt9nGk3FCLEZnYQ11Ta9hxAeN
 kH4TZz5swHCPVxnsU8lmqNDoYBWfHnKCRdYWk+XL7tFIX2G2Y1CAKQYCH U=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: P4ReK/0z2/dmlBVctSBcoBjuqdgwkuyGughgFn629lBWAV6pAYQdZI4j5rk1arYqoNuUyXxVcu
 8TUi1VG3YMq9uX9eP2lH7ZQ5UE28ecSdIIynw2GNE37g5b3MllfLU3rpB9Q+HUe1QFihVHZUIb
 BysRo1ot3YoElvRecOhywT0ZpRRgEzhLgUbfmUTUWIYz8/1M7+74ZQ5M/OuZhhMkNlGHP5xOGK
 E1u+I9UeBQKpNNWlaWrINaDQHW0ekU8NXrekH5DszVDWV7sDIgvlOpXMhBZHZB7OpbMP2X3Z3R
 BCA=
X-SBRS: 2.7
X-MesageID: 16434517
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,306,1583211600"; d="scan'208";a="16434517"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 1/4] golang/xenlight: add NameToDomid and DomidToName util
 functions
Thread-Topic: [PATCH 1/4] golang/xenlight: add NameToDomid and DomidToName
 util functions
Thread-Index: AQHWERYbx3dgi/1zV0KyTdtBFGxU1KiFXiqAgAAbqgCAAPRDgA==
Date: Thu, 23 Apr 2020 10:21:05 +0000
Message-ID: <ACBE3271-80FD-405A-A1A2-A07A3597A47D@citrix.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
 <e2d8d6c1293c8251be881cd471265aa8188ae2ae.1586727061.git.rosbrookn@ainfosec.com>
 <65721F76-319A-47E4-8184-116F02B2BCE3@citrix.com>
 <CAEBZRSckvUqCikFhtHECzmybwC_d8ojCfvBznvF90A7pS1A_1Q@mail.gmail.com>
In-Reply-To: <CAEBZRSckvUqCikFhtHECzmybwC_d8ojCfvBznvF90A7pS1A_1Q@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <C62B93E4BF4DC04BBEB176E85B751182@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDIyLCAyMDIwLCBhdCA4OjQ2IFBNLCBOaWNrIFJvc2Jyb29rIDxyb3Nicm9v
a25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+PiBsaWJ4bC5oIGRlZmluZXMgSU5WQUxJRF9ET01J
RCDigJQgZG8gd2Ugd2FudCB0byBkZWZpbmUgYW4gZXhwb3J0ZWQgY29uc3RhbnQgd2l0aCB0aGUg
c2FtZSBuYW1lIGFuZCB1c2UgdGhhdCBoZXJlPyAgKEFsdGhvdWdoIHBhcnQgb2YgbWUgd29uZGVy
cyBpZiBET01JRF9JTlZBTElEIHdvdWxkIGJlIGEgYmV0dGVyIG9wdGlvbi4pDQo+IA0KPiBZZWFo
LCB0aGF0IG1ha2VzIHNlbnNlLiBJJ2xsIGFkZCB0aGF0Lg0KPiANCj4+PiArICAgICB9DQo+Pj4g
Kw0KPj4+ICsgICAgIHJldHVybiBEb21pZChkb21pZCksIG5pbA0KPj4+ICt9DQo+Pj4gKw0KPj4+
ICsvLyBEb21pZFRvTmFtZSByZXR1cm5zIHRoZSBuYW1lIGZvciBhIGRvbWFpbiwgZ2l2ZW4gaXRz
IGRvbWlkLg0KPj4+ICtmdW5jIChDdHggKkNvbnRleHQpIERvbWlkVG9OYW1lKGRvbWlkIERvbWlk
KSBzdHJpbmcgew0KPj4+ICsgICAgIGNuYW1lIDo9IEMubGlieGxfZG9taWRfdG9fbmFtZShDdHgu
Y3R4LCBDLnVpbnQzMl90KGRvbWlkKSkNCj4+PiArICAgICBkZWZlciBDLmZyZWUodW5zYWZlLlBv
aW50ZXIoY25hbWUpKQ0KPj4+ICsNCj4+PiArICAgICByZXR1cm4gQy5Hb1N0cmluZyhjbmFtZSkN
Cj4+PiArfQ0KPj4gDQo+PiBJdCBsb29rcyB0byBtZSBsaWtlIGlmIHRoZSBkb21pZCBkb2VzbuKA
mXQgZXhpc3QsIGxpYnhsX2RvbWlkX3RvX25hbWUoKSB3aWxsIHJldHVybiBOVUxMOyBhbmQgdGhl
biBEb21pZFRvTmFtZSB3aWxsIHJldHVybiDigJzigJ0uICBJcyB0aGF0IHdoYXQgd2Ugd2FudD8N
Cj4+IA0KPj4gSWYgc28sIGl0IHNob3VsZCBwcm9iYWJseSBiZSBkb2N1bWVudGVkLg0KPiANCj4g
SSBjb25zaWRlcmVkIHJldHVybmluZyBhbiBlcnJvciBpZiBDLkdvU3RyaW5nKGNuYW1lKSA9PSAi
Ii4gQnV0LCB3aXRoDQo+IHRoZXNlIGZ1bmN0aW9ucyAoYXMgd2VsbCBhcyB0aGUgb3RoZXJzIGlu
IHRoZXNlIHNlcmllcyksIEkgb3B0ZWQgdG8NCj4ga2VlcCB0aGUgc2lnbmF0dXJlcyBhbGlnbmVk
IHdpdGggdGhlaXIgbGlieGwgY291bnRlcnBhcnRzIHNpbmNlIHdlJ3JlDQo+IGtlZXBpbmcgdGhl
IHBhY2thZ2UgQVBJIG1vc3RseSBvbmUtdG8tb25lIHdpdGggbGlieGwuIEkgY2FuIGFkZCBhDQo+
IHNlY29uZCByZXR1cm4gdmFsdWUgaWYgeW91IHByZWZlciwgb3RoZXJ3aXNlIEknbGwganVzdCBh
ZGQgYSBub3RlIGluDQo+IHRoZSBjb21tZW50Lg0KDQpPSyDigJQgYWRkaW5nIGEgbm90ZSBpbiB0
aGUgY29tbWVudCBpcyBmaW5lLiAgSSBtYWlubHkgd2FudGVkIHRvIG1ha2Ugc3VyZSB0aGUgcXVl
c3Rpb24gaGFkIGFjdHVhbGx5IGJlZW4gY29uc2lkZXJlZCAoYWx0aG91Z2ggb2YgY291cnNlIGRv
Y3VtZW50aW5nIHRoYXQgYmVoYXZpb3IgaXMgYWxzbyBpbXBvcnRhbnQpLg0KDQpUaGFua3MsDQog
LUdlb3JnZQ0KDQo=


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:22:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:22:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZ03-00013n-Tg; Thu, 23 Apr 2020 10:22:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wmme=6H=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRZ02-00013S-Jv
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:22:30 +0000
X-Inumbo-ID: 560a80fc-854c-11ea-83d8-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 560a80fc-854c-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 10:22:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587637349;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=Pv0utfcQrOBeVP82M/X9IHBRVbbaHAf0sAhccm4E9vY=;
 b=Dk0L7FSQoxeIPKdPycnIri/aGyJk6Gzpg1BtfnRXd4dEB+GuO7f2jFi4
 Nq/Z9ImNKzxJojgvCi/nfqw2eGOLcFw2biMZV0aIKgk+1OvEQYo8IfUax
 LZzXrvn7hQziBIVB3TArkpMtKV5EP8sKM7CfxG9yKR3mHgk1xknhKialt k=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: DocxLy6GnvEJgw8lKJEyaYM1kvQZjH2tLKyVc1vx7p86OIEFyGwbxL0UwTyJ+CB04IUiDublRr
 k4jqWT+rxT0FEDFw/0NPUaLTSwSyQxBJCKsq2++aETHaSU00t4X452vj3GsSFK4NccYnoOD60G
 cJuzgaJjqzi4CecDD9UkmRdTUy4pRmEmAKQ9XYuT+Q9Rbv2NAABbBG2IMuCAZg25TG1CWs63BL
 piqpklToTNEACUPTmJ8oTQmH6dAhOeYjGIq2Ndex71nVEW48hP3UzUC+Jdj5VcgQo53kd181Wr
 nY8=
X-SBRS: 2.7
X-MesageID: 16434562
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,306,1583211600"; d="scan'208";a="16434562"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 3/4] golang/xenlight: add DevicePciAdd/Remove wrappers
Thread-Topic: [PATCH 3/4] golang/xenlight: add DevicePciAdd/Remove wrappers
Thread-Index: AQHWERYncygAsLTYgUqugWPv615hCqiGbncA
Date: Thu, 23 Apr 2020 10:22:26 +0000
Message-ID: <7B3A2F0A-84C8-48C8-B9B2-C27ABE5F22D1@citrix.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
 <7f03220c9db0a377cd26c0c96d8a10981ec47282.1586727061.git.rosbrookn@ainfosec.com>
In-Reply-To: <7f03220c9db0a377cd26c0c96d8a10981ec47282.1586727061.git.rosbrookn@ainfosec.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8F697854FF425642AF3BBDD36E0477F8@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



> On Apr 12, 2020, at 11:02 PM, Nick Rosbrook <rosbrookn@gmail.com> wrote:
>=20
> Add DevicePciAdd and DevicePciRemove as wrappers for
> libxl_device_pci_add and libxl_device_pci remove.
>=20
> Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>

For 4.14, we should really look at adding functions to the IDL so that all =
this can be auto-generated.

Reviewed-by: George Dunlap <george.dunlap@citrix.com>



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:22:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZ0U-0001CG-Cn; Thu, 23 Apr 2020 10:22:58 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wmme=6H=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRZ0S-0001AT-V0
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:22:56 +0000
X-Inumbo-ID: 659ca5b8-854c-11ea-933f-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 659ca5b8-854c-11ea-933f-12813bfff9fa;
 Thu, 23 Apr 2020 10:22:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587637377;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=nU6Y4kkVHHkj1jrwZ1jZ8l50lzOYrnbCWh/1N9UKlek=;
 b=cFGIj76MwcdfayXLzXL7hIbvQ+LJHYyWeesvGssSf+6ylYQEAJlyWeX3
 2hA4E/chKqGNKWmH2QW82NdBVNLCJ1rXk6tH3vWxmkEPMxjhXMe1duRLH
 wgcGKilI8Sud0TLBSkXKGMDEO/PqW34BRieQQ/LfDoIfOm7uVcfBvdbE5 E=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: mspqZjDSIMvmZflvLD+zdnB7AR1trZSPEY5EelXCpIoqJ66kNS0Cq1/VtY7TlBOrHdhn7e5N/2
 2CEZ+IU3J/TGJLLvVZRRZHq4ZilWeKvKvONFX/Cplky3XXMWPRzSnS+fssymbi80T1Cw9SmD46
 zKK6KxYVxBqliq0W6fuEO8QnTRyvfwTTvRedy3Hmk+1YQetTcfwbD2R6Zqm+unN7tGbJbDNMmX
 iqINUNXSVoZTtaJsv9KxDq44eQZqvYEFu0Tm/7EIg8jei8fKwBVwwG46v7XLgeZmh8LvBEmV35
 tQ8=
X-SBRS: 2.7
X-MesageID: 16103911
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,306,1583211600"; d="scan'208";a="16103911"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 4/4] golang/xenlight: add DeviceUsbdevAdd/Remove wrappers
Thread-Topic: [PATCH 4/4] golang/xenlight: add DeviceUsbdevAdd/Remove wrappers
Thread-Index: AQHWERYd3+QkSUgUBk+84Cm8kpq52KiGbo8A
Date: Thu, 23 Apr 2020 10:22:46 +0000
Message-ID: <F8B21573-2C49-4402-9CEB-C46CF8AFDCFC@citrix.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
 <1fcd31482f5183f29e9d949c6e17183b6b101c8b.1586727061.git.rosbrookn@ainfosec.com>
In-Reply-To: <1fcd31482f5183f29e9d949c6e17183b6b101c8b.1586727061.git.rosbrookn@ainfosec.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2CB9B430F023AB4DBBCDAACE6DD933BB@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



> On Apr 12, 2020, at 11:02 PM, Nick Rosbrook <rosbrookn@gmail.com> wrote:
>=20
> Add DeviceUsbdevAdd and DeviceUsbdevRemove as wrappers for
> libxl_device_usbdev_add and libxl_device_usbdev_remove.
>=20
> Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>

Reviewed-by: George Dunlap <george.dunlap@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:25:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZ3A-0001iG-Np; Thu, 23 Apr 2020 10:25:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=IVNM=6H=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jRZ39-0001hR-Hj
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:25:43 +0000
X-Inumbo-ID: c8bd369e-854c-11ea-933f-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c8bd369e-854c-11ea-933f-12813bfff9fa;
 Thu, 23 Apr 2020 10:25:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=K6c8z0zSO4hwF1jNd7IKrbrk9Saj8OUXaoMIdtS9eWo=; b=0WnNRUP98oTYTHtbIbBzj1CNMX
 c+kZ0NZylgzBJOUmMzNg4OiZ7WlDstdm+jBCywF0OwuZOjSmlYkXxQxPAqoBt9hZJ4QG5U75XW6NE
 X1JZisI6VFmlncQVr8np+qD3Wta7b2JAyzzUJOxkHhoM5Cma/BFKJYjyZ2/rdw5IDUeQ=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jRZ37-0000M4-8i; Thu, 23 Apr 2020 10:25:41 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jRZ37-00059C-0R; Thu, 23 Apr 2020 10:25:41 +0000
Date: Thu, 23 Apr 2020 11:25:38 +0100
From: Wei Liu <wl@xen.org>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 1/2] tools: build golang tools if go compiler is present
Message-ID: <20200423102538.vxuo7s2lamkxhoo7@debian>
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>, xen-devel@lists.xenproject.org,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 22, 2020 at 08:25:25PM -0400, Nick Rosbrook wrote:
> By default, if the go compiler is found by the configure script, build
> the golang tools. If the compiler is not found, and
> --enable-golang_tools was not explicitly set, do not build to the golang

--enable-golang-tools here.

> tools.
> 
> The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove
> CONFIG_GOLANG from tools/Rules.mk since the new variable is set by
> configure.
> 
> Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>

Acked-by: Wei Liu <wl@xen.org>

Note to self: fix commit message and maybe rerun autogen.sh.


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:25:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZ3F-0001jM-W4; Thu, 23 Apr 2020 10:25:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=IVNM=6H=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jRZ3E-0001is-Hv
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:25:48 +0000
X-Inumbo-ID: cc4cb19a-854c-11ea-933f-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cc4cb19a-854c-11ea-933f-12813bfff9fa;
 Thu, 23 Apr 2020 10:25:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=sqB0POh+DlkETeDvNvjuZIZRynPRSQnUNmboT+aYH9M=; b=w/6ZTct+9ejejJj7v8lbQfg39F
 evUShwuXIZSEgMsvplQczVjewIIzOUIcQAqmD65DkLRA1pRzVHzUX/PEDtvKvjWmI47lV9vtUeZXu
 nmZM32b+IgYuXuROIHL8sOpPKAb0i6gewAnx+flueSJcCmfK7jNJlibi6pmqYOMh5/ek=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jRZ3D-0000MK-2n; Thu, 23 Apr 2020 10:25:47 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jRZ3C-00059N-QW; Thu, 23 Apr 2020 10:25:47 +0000
Date: Thu, 23 Apr 2020 11:25:43 +0100
From: Wei Liu <wl@xen.org>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 2/2] golang/xenlight: stop tracking generated files
Message-ID: <20200423102543.iy4szqmbfzsohlwd@debian>
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <f4fd2508a9cbceec2d1b8b480d4e4a15422d67d2.1587599095.git.rosbrookn@ainfosec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f4fd2508a9cbceec2d1b8b480d4e4a15422d67d2.1587599095.git.rosbrookn@ainfosec.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Nick Rosbrook <rosbrookn@ainfosec.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 22, 2020 at 08:25:26PM -0400, Nick Rosbrook wrote:
> The generated go files were tracked temporarily while the initial
> implementation of gengotypes.py was in progress. They can now be removed
> and ignored by git and hg.
> 
> While here, make sure generated files are removed by make clean.
> 
> Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>

Acked-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:30:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:30:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZ7i-0002bu-K7; Thu, 23 Apr 2020 10:30:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=IVNM=6H=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jRZ7g-0002bp-Kb
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:30:24 +0000
X-Inumbo-ID: 70e4e3f8-854d-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 70e4e3f8-854d-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 10:30:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
 MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=aPFru5k8xeaS99OltKI3qFaxgEJ+9rtIHqVXBXXSvwc=; b=0ENP90q83mbn0TqfQmxNo4h4nP
 70pxRthb9VfRCKb2p8Y2EMnLuP96FjVUex1bq43zVfq15doEeekDWWyqsqfiv0rh00U9dh0a2te78
 ZkBqIS5HZUqZ7kOmiq2xYosXMRk2TeKPLDduq5LoYoC4kaP/mXUfQqpkvwTqs1v9Yoa0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jRZ7e-0000UO-Pb; Thu, 23 Apr 2020 10:30:22 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jRZ7e-0005YI-EW; Thu, 23 Apr 2020 10:30:22 +0000
Date: Thu, 23 Apr 2020 11:30:19 +0100
From: Wei Liu <wl@xen.org>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200423103019.a43rnmub5jdszjhc@debian>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <20200422163338.GF28601@Air-de-Roger>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200422163338.GF28601@Air-de-Roger>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monn� wrote:
> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
> > @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
> >  
> >      return flags;
> >  }
> > +
> > +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
> > +{
> > +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
> > +                                                                   : 0) |
> > +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> > +                                                          : 0);
> 
> Maybe I'm getting confused, but I think the above is wrong and ASID
> should _always_ be flushed when running a HVM domain in shadow mode
> regardless of whether the underlying hw is Intel or AMD, ie:
> 
> bool shadow = paging_mode_shadow(d);
> unsigned int flags = (shadow ? FLUSH_TLB : 0) |
>                      (is_hvm_domain(d) &&
>                       (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE : 0);

This sort of long expression is prone to error. See XSA-316.

Can I request it to be broken down a bit?

Wei.


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:31:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:31:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZ8p-0002ia-VW; Thu, 23 Apr 2020 10:31:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wmme=6H=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRZ8o-0002iR-Px
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:31:34 +0000
X-Inumbo-ID: 9a60f6c2-854d-11ea-9340-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9a60f6c2-854d-11ea-9340-12813bfff9fa;
 Thu, 23 Apr 2020 10:31:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587637893;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=88ObPnjc7oqBNVVKieuFiZ6HGMnRfimNK5HLKQnG9Hg=;
 b=S5b4RiJrvj8znTcMJ0YtEilVqmGpOhsz+sXP471Q1/VrfYrMusHENCNs
 /HIzhESVXFq53H9bPO4EictJlNlaLV+zkxfcaILJw26eaFxR6qSTZjn8L
 Odd2zbnnLPdF4PBue4YwYeTAvt6gezw7pnVsUOM6wLpSITjX3HjHSyJMh E=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: pHwaMcbjdkdyF6YuN7+uS7QcWVxbGhDdbGD1I9ofIt5YRFpyvbrkE+4jl22wNJS/v9oCa+S5uX
 k8WHUI/EujUcmyvOg0FMHWKMJAGE1TCF6geFzUh/4AXfFdPPzXri0BOZVOjeNCDLwZzBVxghXf
 F4Mm8Yc2WnzsPqK+4g5GL2VyT5qlhgb1aSKRRWLfx0rsD6i9E1SgyxGpGD83dAKVDWNcjLSpAm
 dbN26HgL5u/NP3t1exU+T+adhH9PXieGVV5gP5PnBK+XVg/UXUDB4AwZXkZ4XMKjl+ba6UiQNO
 A58=
X-SBRS: 2.7
X-MesageID: 16800743
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16800743"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 0/4] More wrappers for xenlight Go package
Thread-Topic: [PATCH 0/4] More wrappers for xenlight Go package
Thread-Index: AQHWERYayi56nLJ4jUq+qxG7wsmEEaiGcQAA
Date: Thu, 23 Apr 2020 10:31:30 +0000
Message-ID: <5AAA6D77-872F-4C46-9ECD-16D433FD4CE7@citrix.com>
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1586727061.git.rosbrookn@ainfosec.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <FFEDB89BFD52564B99D9E159D7D53537@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDEyLCAyMDIwLCBhdCAxMTowMiBQTSwgTmljayBSb3Nicm9vayA8cm9zYnJv
b2tuQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGlzIHNlcmllcyBhZGRzIHdyYXBwZXJzIHRv
IHRoZSB4ZW5saWdodCBwYWNrYWdlIGZvciB2YXJpb3VzIGxpYnhsDQo+IGZ1bmN0aW9ucywgd2hp
Y2ggYXJlIG5vdyB0cml2aWFsIHRvIGFkZCB3aXRoIHRoZSBnZW5lcmF0ZWQgdHlwZXMgYW5kDQo+
IG1hcnNoYWxpbmcgaGVscGVycy4gSW4gcGFydGljdWxhciwgdGhlc2UgYXJlIGZ1bmN0aW9ucyB0
aGF0IHdvdWxkIGFsbG93IA0KPiByZWRjdGwgdG8gYmVnaW4gbWFraW5nIHRoZSB0cmFuc2l0aW9u
IHRvIHVzaW5nIHRoZSB4ZW5saWdodCBwYWNrYWdlLiBGb3INCj4gcmVmZXJlbmNlLCBJIGhhdmUg
c3RhcnRlZCBhbiBleHBlcmltZW50YWwgYnJhbmNoIHdoZXJlIEkgYW0gdXNpbmcgdGhlc2UNCj4g
ZnVuY3Rpb25zIGluIHJlZGN0bCBbMV0uDQo+IA0KPiBbMV0gaHR0cHM6Ly9naXRsYWIuY29tL2Vu
cjBuL3JlZGN0bC8tL2Jsb2IvMWJkZjdiNTE1NjU0Y2MwMzBlMDk1ZjNhNjMwYTI0NTMwZjkzMGMw
MC9pbnRlcm5hbC9zZXJ2ZXIveGVubGlnaHRfeGVuX2RyaXZlci5nbw0KPiANCj4gTmljayBSb3Ni
cm9vayAoNCk6DQo+ICBnb2xhbmcveGVubGlnaHQ6IGFkZCBOYW1lVG9Eb21pZCBhbmQgRG9taWRU
b05hbWUgdXRpbCBmdW5jdGlvbnMNCj4gIGdvbGFuZy94ZW5saWdodDogYWRkIERldmljZU5pY0Fk
ZC9SZW1vdmUgd3JhcHBlcnMNCj4gIGdvbGFuZy94ZW5saWdodDogYWRkIERldmljZVBjaUFkZC9S
ZW1vdmUgd3JhcHBlcnMNCj4gIGdvbGFuZy94ZW5saWdodDogYWRkIERldmljZVVzYmRldkFkZC9S
ZW1vdmUgd3JhcHBlcnMNCg0KRllJIEnigJl2ZSBwdXNoZWQgdGhlIGxhc3QgdGhyZWUgdG8gc3Rh
Z2luZy4NCg0KIC1HZW9yZ2U=


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:42:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:42:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZIp-0003gH-3S; Thu, 23 Apr 2020 10:41:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRZIn-0003gC-Oh
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:41:53 +0000
X-Inumbo-ID: 0af0d802-854f-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0af0d802-854f-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 10:41:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 75ECBB066;
 Thu, 23 Apr 2020 10:41:50 +0000 (UTC)
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: Wei Liu <wl@xen.org>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <20200422163338.GF28601@Air-de-Roger>
 <20200423103019.a43rnmub5jdszjhc@debian>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <0a03deaa-5842-626a-b173-b9569f69f86c@suse.com>
Date: Thu, 23 Apr 2020 12:41:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200423103019.a43rnmub5jdszjhc@debian>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.2020 12:30, Wei Liu wrote:
> On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monné wrote:
>> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
>>> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
>>>  
>>>      return flags;
>>>  }
>>> +
>>> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
>>> +{
>>> +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
>>> +                                                                   : 0) |
>>> +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
>>> +                                                          : 0);
>>
>> Maybe I'm getting confused, but I think the above is wrong and ASID
>> should _always_ be flushed when running a HVM domain in shadow mode
>> regardless of whether the underlying hw is Intel or AMD, ie:
>>
>> bool shadow = paging_mode_shadow(d);
>> unsigned int flags = (shadow ? FLUSH_TLB : 0) |
>>                      (is_hvm_domain(d) &&
>>                       (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE : 0);
> 
> This sort of long expression is prone to error. See XSA-316.

To be honest I consider it quite fine. XSA-316 was in particular
because of successive closing parentheses, of which there are
none here. (This isn't to say I would strictly mind splitting,
but I fear this would result in (multiple?) single use local
variables.)

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 10:58:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 10:58:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZYJ-0004hj-Lk; Thu, 23 Apr 2020 10:57:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Oa1P=6H=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRZYI-0004he-H4
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 10:57:54 +0000
X-Inumbo-ID: 47cbd554-8551-11ea-b4f4-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 47cbd554-8551-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 10:57:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587639473;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=2dV6oCmTP1BPgAeCpT8Uwm/lIwISJyokbfndx7DIjWE=;
 b=eErJUeyZnBBi1UZ5UaIvYV9nCaDVpAgmxWmbmNlf5gCmcgdBlkCr57SI
 FEzWrok/wNIdKdl9dh8+ZPKoDn5dbw9c03rz6sIcEFlYufm1pd6JdBxbs
 M8kzPUtyNLmqcEoBUQ4XmgMjHEugSKr8TSkOI2rbRbickyxgZBEnvJX/q Y=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 5UOOmCQV4vYuRjbI42h9g2PDLZyEvMlvKeaQpqJCzgvf+oEScb5PSfpYG+c0AIpszCRIR/D/9t
 zov/n5UMH5mQkfSCjTSKr+ADIUBgz2APt1n057+porY1qjtsL+L0QgWKuQkXQ6Uab/O1T710na
 1XLzzGj46gApX5fC+Og9Cf/oEt9w44jEErWp8LohPcCqBywqoQ6zAR6pmmYZdWfapwrGq4Vn1Z
 Fmd56CYHknf65zmxPi24j2BACwz/srP4PskAlNdl6yJQwiqgzkWAsJObjomIn0c+RwCUGqlr07
 Oxk=
X-SBRS: 2.7
X-MesageID: 16521631
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16521631"
Date: Thu, 23 Apr 2020 12:57:44 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200423105744.GG28601@Air-de-Roger>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <20200422163338.GF28601@Air-de-Roger>
 <20200423103019.a43rnmub5jdszjhc@debian>
 <0a03deaa-5842-626a-b173-b9569f69f86c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0a03deaa-5842-626a-b173-b9569f69f86c@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim
 Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 12:41:49PM +0200, Jan Beulich wrote:
> On 23.04.2020 12:30, Wei Liu wrote:
> > On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monné wrote:
> >> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
> >>> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
> >>>  
> >>>      return flags;
> >>>  }
> >>> +
> >>> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
> >>> +{
> >>> +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
> >>> +                                                                   : 0) |
> >>> +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> >>> +                                                          : 0);
> >>
> >> Maybe I'm getting confused, but I think the above is wrong and ASID
> >> should _always_ be flushed when running a HVM domain in shadow mode
> >> regardless of whether the underlying hw is Intel or AMD, ie:
> >>
> >> bool shadow = paging_mode_shadow(d);
> >> unsigned int flags = (shadow ? FLUSH_TLB : 0) |
> >>                      (is_hvm_domain(d) &&
> >>                       (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE : 0);
> > 
> > This sort of long expression is prone to error. See XSA-316.
> 
> To be honest I consider it quite fine. XSA-316 was in particular
> because of successive closing parentheses, of which there are
> none here. (This isn't to say I would strictly mind splitting,
> but I fear this would result in (multiple?) single use local
> variables.)

Right now it's exactly (including the indentation):

    bool shadow = paging_mode_shadow(d);

    return (shadow ? FLUSH_TLB : 0) |
           (is_hvm_domain(d) && (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE
                                                        : 0);

I could change it to:

    bool shadow = paging_mode_shadow(d);
    bool asid = is_hvm_domain(d) && (cpu_has_svm || shadow);

    return (shadow ? FLUSH_TLB : 0) | (asid ? FLUSH_HVM_ASID_CORE : 0);

But would result in a single use asid local variable.

I think XSA-316 was slightly different because the issue arose from
assigning and comparing a variable inside of an if condition, which is
not the case here. I however don't mind changing it if it's regarded
as potentially insecure, or hard to read.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 11:06:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 11:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZgO-0005bh-Ga; Thu, 23 Apr 2020 11:06:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Hmmv=6H=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRZgM-0005bc-LB
 for xen-devel@lists.xen.org; Thu, 23 Apr 2020 11:06:14 +0000
X-Inumbo-ID: 72477864-8552-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 72477864-8552-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 11:06:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=nRQiXUKM8d0oIrXF+wtuq5xPPyBC/bA8I1F0UfmaBX8=; b=6WEVvp00oJofP7rx2l9p+GZIy7
 AUtqkGdZfF4fD7whKJikII11/eyHqEQeJuLH4nrZ+2/NLGUK3dNMhJnnjNSePD+0Pvw0lJg+f65v7
 +77kyKZb4FoOfFgYLrutitG+uEHJIrBB9uFuYrEsjGfR+1dqcxZxMJRixRfp2GYjykR8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRZgK-0001GL-UG; Thu, 23 Apr 2020 11:06:12 +0000
Received: from 54-240-197-230.amazon.com ([54.240.197.230]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRZgK-0000KT-ND; Thu, 23 Apr 2020 11:06:12 +0000
Subject: Re: [XTF 0/4] Add strncmp(), strtol() and strtoul() functions
To: Pawel Wieczorkiewicz <wipawel@amazon.de>, xen-devel@lists.xen.org
References: <20200423101918.13566-1-wipawel@amazon.de>
From: Julien Grall <julien@xen.org>
Message-ID: <1637c166-75f5-4034-e3a0-6921aabbdfab@xen.org>
Date: Thu, 23 Apr 2020 12:06:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200423101918.13566-1-wipawel@amazon.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: semelpaul@gmail.com, andrew.cooper3@citrix.com, nmanthey@amazon.de,
 wipawel@xen.org, paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 23/04/2020 11:19, Pawel Wieczorkiewicz wrote:
> Add FreeBSD's implementation of strtol() and strtoul() functions from:
> https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/strtoul.c

I would suggest to specify the baseline used in each commit. This will 
allows us to track any changes that was made afterwards (even if it 
seems unlikely) in the FreeBSD code base.


> 
> The FreeBSD code being added as a separate file (common/libc/strtol.c)
> is under the BSD 3-clause license. Modification to COPYING file might
> be needed.
> 
> Also add simple implementation of the strncmp() function.
> 
> Paul Semel (1):
>    string: add freebds libc implementation of strtol()
> 
> Pawel Wieczorkiewicz (3):
>    libc, strtol: Add isspace(), isdigit(), isxdigit(), isascii()
>    libc, strtol: Add FreeBSD libc implementation of strtoul()
>    libc: add strncmp() function
> 
>   build/files.mk          |   1 +
>   common/lib.c            |   8 --
>   common/libc/string.c    |  11 +++
>   common/libc/strtol.c    | 201 ++++++++++++++++++++++++++++++++++++++++++++++++
>   common/libc/vsnprintf.c |   8 --
>   include/xtf/libc.h      |  35 +++++++++
>   6 files changed, 248 insertions(+), 16 deletions(-)
>   create mode 100644 common/libc/strtol.c
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 11:08:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 11:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZii-0005k7-Tm; Thu, 23 Apr 2020 11:08:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRZii-0005k2-G7
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 11:08:40 +0000
X-Inumbo-ID: c8339c8b-8552-11ea-9344-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c8339c8b-8552-11ea-9344-12813bfff9fa;
 Thu, 23 Apr 2020 11:08:39 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7B619B11F;
 Thu, 23 Apr 2020 11:08:37 +0000 (UTC)
Subject: Re: [PATCH v4] x86: irq: Do not BUG_ON multiple unbind calls for
 shared pirqs
To: paul@xen.org, 'Varad Gautam' <vrd@amazon.de>
References: <20200306160254.8465-1-paul@xen.org>
 <58f00871-2fff-be69-299e-e2b9911e0723@suse.com>
 <000301d5f63a$df5f04a0$9e1d0de0$@xen.org>
 <0648e7ac-f5d7-4207-e2c6-8418681cca13@suse.com>
 <004201d5fc70$128cc610$37a65230$@xen.org>
 <8590eadc-b561-ba7c-c474-141102ec76bd@suse.com>
 <005f01d60752$aa090980$fe1b1c80$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <ca063a1c-d328-153c-ae9f-b91d496dfaa9@suse.com>
Date: Thu, 23 Apr 2020 13:08:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <005f01d60752$aa090980$fe1b1c80$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Julien Grall' <julien@xen.org>,
 =?UTF-8?B?J1JvZ2VyIFBhdSBNb25uw6kn?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 31.03.2020 13:51, Paul Durrant wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 31 March 2020 08:41
>>
>> On 17.03.2020 16:23, Paul Durrant wrote:
>>> That looks like it will do the job. I'll see if I can get it tested.
>>
>> Any luck with this, yet?
> 
> I have asked Varad to test it. He hopes to get to it this week.

Any news here?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 11:10:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 11:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZkD-0006Tm-98; Thu, 23 Apr 2020 11:10:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRZkC-0006Th-31
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 11:10:12 +0000
X-Inumbo-ID: ff834370-8552-11ea-9344-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ff834370-8552-11ea-9344-12813bfff9fa;
 Thu, 23 Apr 2020 11:10:11 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id AEB52B090;
 Thu, 23 Apr 2020 11:10:09 +0000 (UTC)
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <20200422163338.GF28601@Air-de-Roger>
 <20200423103019.a43rnmub5jdszjhc@debian>
 <0a03deaa-5842-626a-b173-b9569f69f86c@suse.com>
 <20200423105744.GG28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <03db9d29-ccd3-a6f0-1dae-1cd4f61fab36@suse.com>
Date: Thu, 23 Apr 2020 13:10:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200423105744.GG28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.2020 12:57, Roger Pau Monné wrote:
> On Thu, Apr 23, 2020 at 12:41:49PM +0200, Jan Beulich wrote:
>> On 23.04.2020 12:30, Wei Liu wrote:
>>> On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monné wrote:
>>>> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
>>>>> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
>>>>>  
>>>>>      return flags;
>>>>>  }
>>>>> +
>>>>> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
>>>>> +{
>>>>> +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
>>>>> +                                                                   : 0) |
>>>>> +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
>>>>> +                                                          : 0);
>>>>
>>>> Maybe I'm getting confused, but I think the above is wrong and ASID
>>>> should _always_ be flushed when running a HVM domain in shadow mode
>>>> regardless of whether the underlying hw is Intel or AMD, ie:
>>>>
>>>> bool shadow = paging_mode_shadow(d);
>>>> unsigned int flags = (shadow ? FLUSH_TLB : 0) |
>>>>                      (is_hvm_domain(d) &&
>>>>                       (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE : 0);
>>>
>>> This sort of long expression is prone to error. See XSA-316.
>>
>> To be honest I consider it quite fine. XSA-316 was in particular
>> because of successive closing parentheses, of which there are
>> none here. (This isn't to say I would strictly mind splitting,
>> but I fear this would result in (multiple?) single use local
>> variables.)
> 
> Right now it's exactly (including the indentation):
> 
>     bool shadow = paging_mode_shadow(d);
> 
>     return (shadow ? FLUSH_TLB : 0) |
>            (is_hvm_domain(d) && (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE
>                                                         : 0);
> 
> I could change it to:
> 
>     bool shadow = paging_mode_shadow(d);
>     bool asid = is_hvm_domain(d) && (cpu_has_svm || shadow);
> 
>     return (shadow ? FLUSH_TLB : 0) | (asid ? FLUSH_HVM_ASID_CORE : 0);
> 
> But would result in a single use asid local variable.
> 
> I think XSA-316 was slightly different because the issue arose from
> assigning and comparing a variable inside of an if condition, which is
> not the case here. I however don't mind changing it if it's regarded
> as potentially insecure, or hard to read.

I'd be okay to ack either, but would still somewhat prefer the original
variant.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 11:18:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 11:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZsU-0006jk-3n; Thu, 23 Apr 2020 11:18:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wmme=6H=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRZsT-0006jE-3i
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 11:18:45 +0000
X-Inumbo-ID: 3107219a-8554-11ea-83d8-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3107219a-8554-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 11:18:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587640723;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=uTqedBfjuCgoZc2oAIpg3CX8jDxZEotrsFLCb2Bk3k0=;
 b=UWddsB6wzpwdKdG5KpoZBOiTJmgEszz5iyxMwhgb5FjwMwPRT2ZQWYQ4
 mXLeBa2PjRTaYVhIWjny6y53HvBYoITwo+L/qZ9nmysUfTBy5CZ0DNpse
 gecDBiZaqrJ+WZBd6bfvL5O1/Z6v1XEJZLzAk9rSnDGNepgB2hvz87Y3n A=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: QgOmS+sABo5YH0YlVXxGV+YC8w2Di1UAuVssMC8OhOYUG2BWTOLFwKSa+whhjpRGoFnsl8DJLw
 8mrxgOq10JvouwTnxL3fRk9401khN9R3AG2/ip0ygEd46ILbXLYHZ8hEavj6OEgmtOUDDDk/w0
 jxT05CC/AxuS+BOQ8TaNOpW+El9e/37qrWC9gAS3UCCPe1gfoYbpxqydMTXWFSgzlJzM4AoPMo
 COd49Oj+j12blSaRrWOkok9ECewaFE6zt2qnUiWmxe7F+kZA2qM/D4wzyHDV1/GFPxMJTsfo8/
 1o0=
X-SBRS: 2.7
X-MesageID: 16437185
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16437185"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: Golang Xen packages and the golang packaging system
Thread-Topic: Golang Xen packages and the golang packaging system
Thread-Index: AQHWGNesUpUX4UDcFkSZQD1qmZkhVKiGbqmA
Date: Thu, 23 Apr 2020 11:18:40 +0000
Message-ID: <B47CC5BA-80C8-43D1-BDB3-25BCF4FDB78F@citrix.com>
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
 <CAEBZRSe=yB6Y1TQSQqAphDw8gVKm8VhpqEYsKXgVnZjvPNPUnQ@mail.gmail.com>
In-Reply-To: <CAEBZRSe=yB6Y1TQSQqAphDw8gVKm8VhpqEYsKXgVnZjvPNPUnQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <2C69E4833A71004D812832FF787A4C8B@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDIyLCAyMDIwLCBhdCA3OjU1IFBNLCBOaWNrIFJvc2Jyb29rIDxyb3Nicm9v
a25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+PiBPbmUgcXVlc3Rpb24gSSBoYXZlIGZyb20gdGhl
IGFib3ZlIGlzIGhvdyB0aGUgeGVuLmdpdCBSRUxFQVNFLVguWS5aIHNob3VsZCBjb3JyZXNwb25k
IHRvIHRoZSB2QS5CLkMgaW4gdGhlIGdvbGFuZyBwYWNrYWdlIHJlcG8uDQo+PiANCj4+IFRoZSBv
YnZpb3VzIGFuc3dlciwgb2YgY291cnNlLCBpcyAoQSwgQiwgQykgPSAoWCwgWSwgWik7IHRoYXQg
aXMsIHhlbi5naXQgdGFnIFJFTEVBU0UtNC4xNC4wIHNob3VsZCBjcmVhdGUgYSBnb2xhbmcgcGFj
a2FnZSB0YWcgb2YgdjQuMTQuMC4NCj4+IA0KPj4gVGhlIGlzc3VlIHdpdGggdGhpcyBpcyB0aGF0
IGdvbGFuZyBhc3N1bWVzIHlvdeKAmXJlIHVzaW5nIHNlbWFudGljIHZlcnNpb25pbmc7IHNvIGEg
YGdvIGdldCAtdWAgd291bGQgbm9ybWFsbHkgZmVlbCBqdXN0aWZpZWQgaW4gdXBncmFkaW5nIGZy
b20gdjQuMTQueCB0byB2NC4xNS54Lg0KPj4gDQo+PiBBIGNvdXBsZSBvZiBwb3NzaWJsZSByZXNw
b25zZXM6DQo+PiANCj4+IDEuIERlY2xhcmUgdGhhdCBPSy4gIFRoYXQgd291bGQgbWVhbiBub3Qg
b25seSB0aGF0IHdlIGhhdmUgdG8gaGF2ZSB2NC4xNS54IGJlIGNvbXBhdGlibGUgd2l0aCBnb2xh
bmcgc291cmNlIGNvZGUgd3JpdHRlbiBhZ2FpbnN0IHY0LjE0OyBpdCB3b3VsZCBhbHNvIG1lYW4g
dGhhdCB2NC4xNS54IG5lZWRzIHRvIGJlIGFibGUgdG8gKmNvbXBpbGUqIGFnYWluc3QgbGlieGwg
dmVyc2lvbiA0LjE0LiAgV2hpY2ggbWlnaHQgYmUgYSBnb29kIGlkZWEsIGJ1dCB3ZeKAmWQgd2Fu
dCB0byB0aGluayBjYXJlZnVsbHkgYmVmb3JlIG1ha2luZyB0aGF0IGtpbmQgb2YgY29tbWl0bWVu
dC4NCj4+IA0KPj4gMi4gRGVjbGFyZSB0aGF0IHBlb3BsZSBuZWVkIHRvIHVzZSBgZ28gZ2V0IC11
PXBhdGNoYCB3aGVuIHVwZGF0aW5nLCBhbmQvb3IgdXNlIGdvLm1vZCAmYyB0byBtYW51YWxseSBy
ZXN0cmljdCB0aGUgdmVyc2lvbiBvZiBnbyB0byB1c2UgdG8gdGhlIGN1cnJlbnRseS1pbnN0YWxs
ZWQgWGVuIHZlcnNpb24NCj4+IA0KPj4gMy4gTWFwIChBLCBCLCBDKSA9IChZLCBaLCAwKS4gIChp
LmUuLCBSRUxFQVNFLTQuMTQuNSB3b3VsZCBtYWtlIHRhZyB2MTQuNS4wIC4pICBgZ28gZ2V0YCB3
b3VsZG7igJl0IHVwZGF0ZSBhdXRvbWF0aWNhbGx5LCBidXQgaXQgbWlnaHQgYmUgY29uZnVzaW5n
IHdoaWNoIHZlcnNpb24gKnNob3VsZCogYmUgdXNlZDsgcGFydGljdWxhcmx5IGlmIHdlIGV2ZXIg
cm9sbCBvdmVyIGEgbWFqb3IgdmVyc2lvbiBmb3IgWGVuLg0KPj4gDQo+PiBBbnkgb3RoZXIgcG9z
c2liaWxpdGllcz8NCj4+IA0KPj4gSSB0aGluayBJ4oCZZCBzdGFydCBvdXQgd2l0aCAjMiwgYW5k
IHRoZW4gY29uc2lkZXIgbW92aW5nIHRvICMxIGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVyZS4N
Cj4+IA0KPj4gVGhvdWdodHM/DQo+IA0KPiBXZSBzaG91bGQgYWxzbyBjb25zaWRlciBhbGlnbmlu
ZyB3aXRoIEdvIG1vZHVsZSB2ZXJzaW9uaW5nDQo+IGNvbnZlbnRpb25zLiBGb3IgZXhhbXBsZSwg
cmlnaHQgbm93IHRoZSBwYWNrYWdlIGlzIHVuc3RhYmxlLCBzbw0KPiBhY2NvcmRpbmcgdG8gY29u
dmVudGlvbiB3ZSBzaG91bGQgYmUgaW4gdjAuMS54LiBBICJ2MCIgaW5kaWNhdGVzIHRvDQo+IHRo
ZSBHbyBlY29zeXN0ZW0gdGhhdCwgYXQgdGhpcyBzdGFnZSwgd2Ugd2lsbCBsaWtlbHkgbWFrZSBi
cmVha2luZw0KPiBjaGFuZ2VzIHRvIHRoZSBwYWNrYWdlIEFQSS4gU28sIHRhZ2dpbmcgdjQuMTQu
MCBpcyBhIGJpdCBjb25mdXNpbmcNCj4gc2luY2UgdGhpcyBpbmRpY2F0ZXMgdGhhdCB3ZSBhcmUg
b24gdGhlIDR0aCBtYWpvciB2ZXJzaW9uIG9mIHRoZQ0KPiBwYWNrYWdlLCBhbmQgdGhhdCBpdCdz
IHN0YWJsZS4gU2VlIFsxXSBhbmQgWzJdIGZvciBtb3JlIG9uIHRoZXNlDQo+IGNvbnZlbnRpb25z
Lg0KPiANCj4gSG93ZXZlciwgdGhpbmdzIGFyZSBvYnZpb3VzbHkgY29tcGxpY2F0ZWQgYnkgdGhl
IGZhY3QgdGhhdCB0aGUNCj4geGVubGlnaHQgcGFja2FnZSBkZXBlbmRzIG9uIGxpYnhsLCBhbmQg
Zm9sbG93aW5nIGNvbnZlbnRpb24gbWlnaHQgbWFrZQ0KPiB0aGF0IHJlbGF0aW9uc2hpcCBsZXNz
IGNsZWFyIGFuZCBkaWZmaWN1bHQgdG8gdHJhY2suIEJ1dCwgaWYgd2Ugc3RyYXkNCj4gZnJvbSBj
b252ZW50aW9uIHdlIGF0IGxlYXN0IG5lZWQgdG8gYmUgY2xlYXIgYWJvdXQgaXQgYW5kIGhhdmUg
YSBnb29kDQo+IGV4cGxhbmF0aW9uIHdoeS4NCj4gDQo+IFRoYXQgc2FpZCwgdW5sZXNzIHdlIGNh
biBjb21lIHVwIHdpdGggYSBnb29kIHdheSB0byBmb2xsb3cgY29udmVudGlvbg0KPiAqYW5kKiBr
ZWVwIHRoZSBsaWJ4bCB2ZXJzaW9uIHNvcnRlZCwgSSB0aGluayAjMiBtYWtlcyB0aGUgbW9zdCBz
ZW5zZQ0KPiByaWdodCBub3cuDQoNClNvIHRoZSB3YXkgd2UgaGF2ZSB0aGluZ3MgcmlnaHQgbm93
LCBJIGRvbuKAmXQgdGhpbmsgIzEgaXMgYWN0dWFsbHkgcG9zc2libGU6IElmIHlvdSBoYXZlIFhl
biA0LjE0IGluc3RhbGxlZCwgYW5kIHlvdSB1cGRhdGUgdG8gYSA0LjE1IHZlcnNpb24gb2YgdGhl
IGdlbmVyYXRlZCBiaW5kaW5ncywgdGhlcmUgd2lsbCBiZSBsb2FkcyBvZiBjb2RlIHRyeWluZyB0
byBtYXJzaGFsIHN0cnVjdHVyYWwgZWxlbWVudHMgdGhhdCBkb27igJl0IGV4aXN0IHlldC4NCg0K
VW5sZXNzIHdlIGNhbiB0aGluayBvZiBhIGdvb2Qgd2F5IHRvIGhhdmUgYGdvIGJ1aWxkYCBkZXRl
Y3QgYXQgYnVpbGQtdGltZSB3aGF04oCZcyBhdmFpbGFibGUgYW5kIGNvbXBpbGUgdGhvc2Ugb3V0
LCB3ZeKAmXJlIGFsd2F5cyBnb2luZyB0byBuZWVkIGEgMS0xIGNvbm5lY3Rpb24gYmV0d2VlbiBn
b2xhbmcgeGVubGlnaHQgcGFja2FnZSBhbmQgdGhlIGluc3RhbGxlZCBYZW4gdmVyc2lvbiAodW5m
b3J0dW5hdGVseSkuDQoNCkhtbeKApiBvciwgY291bGQgd2UgYWN0dWFsbHkgdXNlIHRoZSByZWZs
ZWN0IHBhY2thZ2UgdG8gZGV0ZWN0IGl0IGF0IHJ1bnRpbWU/ICBUaGF04oCZcyBhbm5veWluZyBi
ZWNhdXNlIHlvdeKAmXJlIHN0aWxsIHN0dWNrIHVzaW5nIHRoZSBoZWFkZXJzIGNvbXBpbGVkIGlu
IGF0ICpjb21waWxlKiB0aW1lLg0KDQpUaGUgb3RoZXIgdGhpbmcgdG8gcG9pbnQgb3V0IGlzIHRo
YXQgd2UgY2FuIGFsd2F5cyBzdGFydCB3aXRoIDAueCBhbmQgdGhlbiBzd2l0Y2ggdG8gNC4xNCBp
ZiB3ZSB3YW50IHRvOyBidXQgZ29pbmcgdGhlIG90aGVyIHdheSBpcyBnb2luZyB0byBiZSBtb3Jl
IGRpZmZpY3VsdC4NCg0KSSBndWVzcyB3ZSBjb3VsZCBjYWxsIGl0IHYwLjQuMTQgZm9yIG5vdy4g
IElmIHdlIG1hbmFnZSB0byBtYWtlIGl0IGJhY2t3YXJkcy1hbmQtZm9yd2FyZHMtY29tcGF0aWJs
ZSwgd2UgY2FuIHJlbmFtZSBpdCB2MS4wOyBpZiB3ZSBkZWNpZGUgdG8gZ2l2ZSB1cCBvbiB0aGF0
IGlkZWEsIHdlIGNvdWxkIHJlbmFtZSB0aGVtIHY0LjE0LCB2NC4xNSwgJmMuDQoNCiAtR2Vvcmdl


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 11:25:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 11:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRZyW-0007Yd-R2; Thu, 23 Apr 2020 11:25:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PGxR=6H=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jRZyU-0007YY-UT
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 11:24:58 +0000
X-Inumbo-ID: 101263cc-8555-11ea-b4f4-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 101263cc-8555-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 11:24:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587641098;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=NcSlRmhEtNPJsVumN0BS4HA0FXFdXy5NSM+oQL7ceoU=;
 b=bG/1J/sWfz1tiNrqTRLxSeM1lbqS5VF+aAlZxMiuk/TaLvyhonXrQHfv
 Tr2+nrQoUyGaOXA2lmiqu6tKocfr5smcYdz/s7LY6fWCZGqh77b1IdNON
 BlT+vXGAJ1aw8OeMCmtrNawRLYAR5jBZ+F/vJdr4Lk1NpSsgL1e17aqwk c=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: i0z/cqKoOLoUJarHtJRFLh0+8g9catMGzeCXBrOgcxu7axjAEzQSxe6PVFYQwR9hZl11lVGiie
 iz+xo8tNwk7AKUL4D+M9Cy87gzCgc+aXUjvhS/j2UwttEfhJwO6+gmvk/MBW5OAztO4JfQYszd
 4O5D8uFEQYMVzwz8su+w1Tv3XBOXiAW+/YOv52nM6AUF24DpcsMFV6aU1VFSQj80Lyf7bhntF0
 AodQ6IJ7lKnE5jypcCzc7BMYTrr5gjC54wPEXoM2cDBfoVLtL+XseuHh325ujB42wILlFW3Sxt
 jRM=
X-SBRS: 2.7
X-MesageID: 16522751
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208,217";a="16522751"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-ID: <24225.31493.220592.722565@mariner.uk.xensource.com>
Date: Thu, 23 Apr 2020 12:24:53 +0100
To: George Dunlap <George.Dunlap@citrix.com>
Subject: Re: Golang Xen packages and the golang packaging  system
In-Reply-To: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Nick Rosbrook <rosbrookn@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

George Dunlap writes ("Golang Xen packages and the golang packaging  system"):
> So currently, our build system will install the xenlight package into $PREFIX/share/gocode/src/golang.xenproject.org/xenlight.  However, it actually takes a bit of wrestling to get golang to use this location, and makes it difficult to use shared code.  It would be nice if people could simply add `golang.xenproject.org/xenlight` to their dependencies, and have `go get` just DTRT.
> 
> This basically involves two things:
> 
> 1. Creating a publicly-accessible suitable git repo containing the golang package(s)
> 
> 2. Causing `curl golang.xenproject.org/$PKGNAME` to return some HTML with the following rune:
> 
> <meta name="go-import" content=“golang.xenproject.org git $URL”>
> 
> Where $URL points to the tree from #1.
> 
> We should probably also have some more human-friendly content in case someone wanders there with a web browser.
> 
> “Suitable git tree” means:
> - That it contains just the bindings.  
...
> So what we’d need to do is have a process / hook somewhere which would, on push to xenbits.xenproject.org/xen.git ’s master branch:
>  - Generate the bindings from the source code
>  - Copy these bindings into the git repo, replacing the old bindings entirely (i.e., deleting files which don’t exist any more, adding new files)
>  - Running ‘git commit’, probably with information about the commit from which this code has been generated
>  - Check to see if there is a new RELEASE-X.Y.Z tag and generate an appropriate tag
>  - Push to the git repo in step #1 above

This is quite unpleasant.  In particular, it makes a git tree out of
output files.  What will we do when someone sends us patches to the
bindings ?

Can we not instead provide some metadata at the top level of xen.git
which tells golang how to run enough of our build system to build the
needed .go files ?

Ian.


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 11:28:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 11:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRa1R-0007j6-D7; Thu, 23 Apr 2020 11:28:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PGxR=6H=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jRa1Q-0007j1-9H
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 11:28:00 +0000
X-Inumbo-ID: 7c5174c4-8555-11ea-b58d-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7c5174c4-8555-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 11:27:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587641279;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:subject:in-reply-to:references;
 bh=epYsrRI3SN9UsY22t+MtrUz4boIt6VnJq+06AUnbSDU=;
 b=c+BLPLxmKpsX3RtG3dKSpd7gT6gxKYsAzjJ76tP3rAqXs+g+nR/TRgJh
 8kqB8FigjaV4D+i1WXIwluKBfK9slTgjzi4gF30xiOXlhH3aBL26tOkYC
 ugIYE0I5OxEmy133ahm6Mn6LtSbhWGMI6L2oCF71BdYWFnZi1bqtA9Gkk s=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: b3KJVDqcyVy26IVT8xd9WBH1tz0vpN3cooNmdKCUdsXLE5+iZPfaxQqSIGPliBKmyt6424Zsf9
 HcCfeexE5Z+o7eZLDEefMCcW32tb37Na3x10H5nrWIeeKlyRPsxKieEcC7l0TENo0bIFWaxZOQ
 wXg66lE4Hjr5PYx/n97bKlgzR6hBWOfHB9qNk7tCF5etxU3rDz2p1x9vwgaDI2QA4188AloJdu
 3XGvVIwCUZX8hR2nCInXOX13D9BAfvtXefi6mnbBWFZRJkWZkOcA5DkMbwRM8FR5Tv+cVLwkzX
 e14=
X-SBRS: 2.7
X-MesageID: 16522853
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16522853"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24225.31669.536258.56822@mariner.uk.xensource.com>
Date: Thu, 23 Apr 2020 12:27:49 +0100
To: George Dunlap <George.Dunlap@citrix.com>, xen-devel
 <xen-devel@lists.xenproject.org>, Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: Golang Xen packages and the golang packaging  system
In-Reply-To: <24225.31493.220592.722565@mariner.uk.xensource.com>
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
 <24225.31493.220592.722565@mariner.uk.xensource.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Ian Jackson writes ("Re: Golang Xen packages and the golang packaging  system"):
> This is quite unpleasant.  In particular, it makes a git tree out of
> output files.  What will we do when someone sends us patches to the
> bindings ?

Also, anyone who redistributes your proposed golang package is
violating our licence unless they ship a copy of xen.git[1] too, since
the golang package is not source code.

[1] Technically, a copy of the relevant parts will do.

Ian.


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 11:49:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 11:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRaM8-00014Z-29; Thu, 23 Apr 2020 11:49:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wmme=6H=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRaM6-00014U-Kv
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 11:49:22 +0000
X-Inumbo-ID: 78a3ee4e-8558-11ea-9e09-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 78a3ee4e-8558-11ea-9e09-bc764e2007e4;
 Thu, 23 Apr 2020 11:49:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587642562;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=6PXnz8JMGFRArsksmkMy/uzvvMXtfiA47fnUrbGBi2g=;
 b=dLw2BFI67IbuIAZnkpZtZNL5OkZZaJodssy/tV7hTFFTbr8T+1xAsQMm
 3TpN0xosGBPxGK7eG7RiuZQnKRCyaKgl1Km97Gf++hUjaEwkEsnfailsA
 cWqDgC+HLVumasNsFcuWXE41/LX7ohQfbr3LmRTyQOluP+lTsUrAFCrgo 4=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: V754dtk/vuSB5qabf0l6nUbMmcL+D5/ZKAOs2PpKxmnEZrLCajwVuv6XZTO1RcApLkkVZPZ3lS
 cBR5JFB8dBtSUjpzFqbfg4IEXEz88lFeWNry6mm9tpAELbRd8k6u3zTJd3WSe6n0zEIEijIvTo
 QlPD1/qNFLlOILIZSvD7B9rRRqIapZref5ZHsU2ye8++XHePxqjNWX6Wk8ZKEWfdsBDp+TAkJn
 M9e7mPIGlza0BKM4cCXn7m8h0i+ivk0rCQBXl/ykEly4uJUbQOMG9VAwMTGiwCfQNZJ77UATX+
 OrU=
X-SBRS: 2.7
X-MesageID: 16804577
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16804577"
From: George Dunlap <George.Dunlap@citrix.com>
To: Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: Golang Xen packages and the golang packaging  system
Thread-Topic: Golang Xen packages and the golang packaging  system
Thread-Index: AQHWGL+431OGV0A6ZUWxyQX/eS/9b6iGcJeAgAAA0oCAAAYAAA==
Date: Thu, 23 Apr 2020 11:49:18 +0000
Message-ID: <4085F05B-ABEC-446A-8BB1-06DEE57D71A5@citrix.com>
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
 <24225.31493.220592.722565@mariner.uk.xensource.com>
 <24225.31669.536258.56822@mariner.uk.xensource.com>
In-Reply-To: <24225.31669.536258.56822@mariner.uk.xensource.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <C6C4BEF0DFFC0442B309DEDA5EA2651F@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Nick Rosbrook <rosbrookn@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDIzLCAyMDIwLCBhdCAxMjoyNyBQTSwgSWFuIEphY2tzb24gPGlhbi5qYWNr
c29uQGNpdHJpeC5jb20+IHdyb3RlOg0KPiANCj4gSWFuIEphY2tzb24gd3JpdGVzICgiUmU6IEdv
bGFuZyBYZW4gcGFja2FnZXMgYW5kIHRoZSBnb2xhbmcgcGFja2FnaW5nICBzeXN0ZW0iKToNCj4+
IFRoaXMgaXMgcXVpdGUgdW5wbGVhc2FudC4gIEluIHBhcnRpY3VsYXIsIGl0IG1ha2VzIGEgZ2l0
IHRyZWUgb3V0IG9mDQo+PiBvdXRwdXQgZmlsZXMuICBXaGF0IHdpbGwgd2UgZG8gd2hlbiBzb21l
b25lIHNlbmRzIHVzIHBhdGNoZXMgdG8gdGhlDQo+PiBiaW5kaW5ncyA/DQo+IA0KPiBBbHNvLCBh
bnlvbmUgd2hvIHJlZGlzdHJpYnV0ZXMgeW91ciBwcm9wb3NlZCBnb2xhbmcgcGFja2FnZSBpcw0K
PiB2aW9sYXRpbmcgb3VyIGxpY2VuY2UgdW5sZXNzIHRoZXkgc2hpcCBhIGNvcHkgb2YgeGVuLmdp
dFsxXSB0b28sIHNpbmNlDQo+IHRoZSBnb2xhbmcgcGFja2FnZSBpcyBub3Qgc291cmNlIGNvZGUu
DQo+IA0KPiBbMV0gVGVjaG5pY2FsbHksIGEgY29weSBvZiB0aGUgcmVsZXZhbnQgcGFydHMgd2ls
bCBkby4NCg0KVGhlIOKAnHJlbGV2YW50IHBhcnRz4oCdIHdvdWxkIHByaW1hcmlseSBiZSBnZW5n
b3R5cGVzLnB5LCByaWdodD8gIE9oLCBhbmQgSSBndWVzcyBsaWJ4bF90ZXN0LmlkbCBhbmQgZnJp
ZW5kcy4gIGxpYnhsX3Rlc3QuaWRsIGlzbuKAmXQgaW5jbHVkZWQgaW4gdGhlIGRpc3RyaWJ1dGlv
biBlaXRoZXIuDQoNCknigJltIG5vdCBhbiBleHBlcnQgaW4gdGhlIGdvbGFuZyBidWlsZCBzeXN0
ZW0sIGJ1dCB0aGV5IGdlbmVyYWxseSBzZWVtIHRvIGJlIHRyeWluZyB0byBrZWVwIHRoZSBmdW5j
dGlvbmFsaXR5IHNpbXBsZSAod2hpY2ggb2YgY291cnNlLCBtZWFucyBpZiB5b3Ugd2FudCB0byBk
byBhbnl0aGluZyBub24tYmFzaWMsIGl04oCZcyBpbmNyZWRpYmx5IGNvbXBsaWNhdGVkIG9yIGNv
bXBsZXRlbHkgaW1wb3NzaWJsZSkuDQoNClRoZXJl4oCZcyBhIGNvbW1hbmQsIGBnbyBnZW5lcmF0
ZWAsIHdoaWNoIHdlIGNvdWxkIHVzZSB0byBydW4gZ2VuZ290eXBlcy5weSB0byBnZW5lcmF0ZSB0
aGUgYXBwcm9wcmlhdGUgZmlsZXMuICBCdXQgSeKAmW0gbm90IHN1cmUgaG93IHRvIHVzZSB0aGF0
IGluIGEgcHJhY3RpY2FsIHdheSBmb3IgdGhpcyBzb3J0IG9mIHBhY2thZ2U6IGl0IG1pZ2h0IGVu
ZCB1cCB0aGF0IHBlb3BsZSB3YW50aW5nIHRvIHVzZSB0aGUgcGFja2FnZSB3b3VsZCBuZWVkIHRv
IG1hbnVhbGx5IGNsb25lIGl0LCB0aGVuIG1hbnVhbGx5IHJ1biBgZ28gZ2VuZXJhdGVgIGJlZm9y
ZSBtYW51YWxseSBidWlsZGluZyB0aGUgcGFja2FnZS4NCg0KQ2hlY2tpbmcgaW4gdGhlIGdlbmVy
YXRlZCBmaWxlcyBtZWFucyB0aGF0IHNvbWVvbmUgY2FuIHNpbXBseSBhZGQgYGdvbGFuZy54ZW5w
cm9qZWN0Lm9yZy94ZW5saWdodGAgYXMgYSBkZXBlbmRlbmN5IChwZXJoYXBzIHdpdGggYSBzcGVj
aWZpYyB2ZXJzaW9uIHRhZywgbGlrZSB2NC4xNCksIGFuZCBldmVyeXRoaW5nIEp1c3QgV29ya3Mu
DQoNCk5pY2sgbWF5IGhhdmUgc29tZSBpZGVhcyBvbiBob3cgdG8gdXNlIHRoZSBnb2xhbmcgYnVp
bGQgc3lzdGVtIG1vcmUgZWZmZWN0aXZlbHkuDQoNCiAtR2Vvcmdl


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 11:52:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 11:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRaOj-0001p0-Fb; Thu, 23 Apr 2020 11:52:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRaOi-0001ov-1I
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 11:52:04 +0000
X-Inumbo-ID: d8280594-8558-11ea-9348-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d8280594-8558-11ea-9348-12813bfff9fa;
 Thu, 23 Apr 2020 11:52:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=0Z7lH2MMgCwBYWYp+pwk2O2lwGg8Tb9Fq1sWmG1ehng=; b=1vhallJAy4RAmK0UTO+Ap77ln
 cN02tDlAl0FdH/UewZgrbWPH0aK+t9tejaCS+cSfvxtBuZXxA7U0G5svFj62CIrYtLCN6VIJpmqyP
 cmFd4Y7v8KVwwDAQ0uU1uUC7x774G5IF6egUSEbJ8NsTnQPgGMXuGzwH8BShRJEPww03M=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRaOf-0002DJ-MQ; Thu, 23 Apr 2020 11:52:01 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRaOf-0007Dl-Ba; Thu, 23 Apr 2020 11:52:01 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRaOf-0004sL-Ao; Thu, 23 Apr 2020 11:52:01 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149748-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149748: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=bb215898d46395080b911c15e5c3a7fff0c150cb
X-Osstest-Versions-That: xen=a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 11:52:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149748 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149748/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  bb215898d46395080b911c15e5c3a7fff0c150cb
baseline version:
 xen                  a62c6fe05c4ae905b7d4cb0ca946508b7f96d522

Last test of basis   149736  2020-04-22 13:01:28 Z    0 days
Testing same since   149748  2020-04-23 09:00:40 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   a62c6fe05c..bb215898d4  bb215898d46395080b911c15e5c3a7fff0c150cb -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 12:10:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 12:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRag0-0002xy-Cs; Thu, 23 Apr 2020 12:09:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=TH3x=6H=gmail.com=dunlapg@srs-us1.protection.inumbo.net>)
 id 1jRafz-0002xt-AF
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 12:09:55 +0000
X-Inumbo-ID: 57532b80-855b-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 57532b80-855b-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 12:09:54 +0000 (UTC)
Received: by mail-ed1-x541.google.com with SMTP id r16so4145021edw.5
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 05:09:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=umich.edu; s=google-2016-06-03;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=7XMAgNjSorNlAUmUg02GEUGsSbSZXZVuIUIfkf0XsX4=;
 b=JDqIPQQz8zebf82mcb7rGH3oc7u2L+IOHDqYQ602vq5FjXXZc94ZixXw3Pevpx+Dmr
 Y6essChB0Au976+PM4wPb8RZANtnYxCeLZDQlJX9h0i3sscUUBGV+M15OKX5W4z6OxX1
 gaHo5dz2Wub7OSBb6fAVWlvXHnjLXkR6lU0K8CezryS77t5h+nGIDR/0ENLNleM5cDgh
 /SeCJ0qU74zlPINYeZpD8B3HhdDxF9tEEI3X63eJdYu6ggfMdPAx/BQX08tKPHk7b0YY
 4nv1g0ilEOKYA3wDwo3eSmDQBzb7OBC8D2v01dOgOe+LRZp74P1r99SN4D7u6ef9teRa
 tKNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=7XMAgNjSorNlAUmUg02GEUGsSbSZXZVuIUIfkf0XsX4=;
 b=iqS4gCCnEKmZ7WoDhxBwaxXvzM9F+5eEN6pK5UdvPsTgnFGLhR8fnoFguWIUHB15mD
 m8dPGH8jsccBz/g01j4qsbEsYSPVCuc+wEQdyq1CLf8nSi/hzrbl08wPAyoLN5Bv3sSn
 MURmPejTIICxnz6lJNXhsnFpm7lGTPevP2YIUZTaO608J+xKyPbaCcMmvfy4NpZ5j7GY
 /WlisN/g3UeVGD/Rl4qc7LeFLfUm+ruW4Mzv2zGgA5S75FZCPihZfwiFVvaNrYqXXIXr
 jg+Ojm96GCXLOGmSEhnJAc+QlAroo0zQE4AjWoPmwIMQjppKT6nMLyD3xR9osMvyOBQX
 Wj1g==
X-Gm-Message-State: AGi0PubbiN8GVNv7NvujGF9Ec5Dw43UurdMcr0gWrwwoVB79i1KHdb2a
 k6pKLqj55XCoFJJ64EcGpPIpowICiNAtRJLGULM=
X-Google-Smtp-Source: APiQypL5gRH+bOxF2S63MKn9ILZsflRdH4IFWDOLVv3cL8fBh7ENohh05SyxklVAbo0HH3pGrMiKYf5kFC3EmUhOWJ0=
X-Received: by 2002:a50:d90f:: with SMTP id t15mr2365667edj.209.1587643793888; 
 Thu, 23 Apr 2020 05:09:53 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
 <20200423102538.vxuo7s2lamkxhoo7@debian>
In-Reply-To: <20200423102538.vxuo7s2lamkxhoo7@debian>
From: George Dunlap <dunlapg@umich.edu>
Date: Thu, 23 Apr 2020 13:09:43 +0100
Message-ID: <CAFLBxZbWtLLeYr_pQ54zuy1RTq0Xmts5473Ueac6PG9cv9HUOw@mail.gmail.com>
Subject: Re: [PATCH 1/2] tools: build golang tools if go compiler is present
To: Wei Liu <wl@xen.org>
Content-Type: multipart/alternative; boundary="0000000000005d592305a3f42034"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Nick Rosbrook <rosbrookn@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--0000000000005d592305a3f42034
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 23, 2020 at 11:25 AM Wei Liu <wl@xen.org> wrote:

> On Wed, Apr 22, 2020 at 08:25:25PM -0400, Nick Rosbrook wrote:
> > By default, if the go compiler is found by the configure script, build
> > the golang tools. If the compiler is not found, and
> > --enable-golang_tools was not explicitly set, do not build to the golang
>
> --enable-golang-tools here.
>
> > tools.
> >
> > The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove
> > CONFIG_GOLANG from tools/Rules.mk since the new variable is set by
> > configure.
> >
> > Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
>
> Acked-by: Wei Liu <wl@xen.org>
>
> Note to self: fix commit message and maybe rerun autogen.sh.
>

It doesn't look like that's a typo -- if you want it to be `-` instead of
`_`, the patch needs to be changed (at least as far as I can tell w/ my
admittedly limited automake-foo).

 -George

--0000000000005d592305a3f42034
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 23, 2020 at 11:25 AM Wei =
Liu &lt;<a href=3D"mailto:wl@xen.org">wl@xen.org</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Apr 22, 2020 at 08:=
25:25PM -0400, Nick Rosbrook wrote:<br>
&gt; By default, if the go compiler is found by the configure script, build=
<br>
&gt; the golang tools. If the compiler is not found, and<br>
&gt; --enable-golang_tools was not explicitly set, do not build to the gola=
ng<br>
<br>
--enable-golang-tools here.<br>
<br>
&gt; tools.<br>
&gt; <br>
&gt; The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove<br>
&gt; CONFIG_GOLANG from tools/Rules.mk since the new variable is set by<br>
&gt; configure.<br>
&gt; <br>
&gt; Signed-off-by: Nick Rosbrook &lt;<a href=3D"mailto:rosbrookn@ainfosec.=
com" target=3D"_blank">rosbrookn@ainfosec.com</a>&gt;<br>
<br>
Acked-by: Wei Liu &lt;<a href=3D"mailto:wl@xen.org" target=3D"_blank">wl@xe=
n.org</a>&gt;<br>
<br>
Note to self: fix commit message and maybe rerun autogen.sh.<br></blockquot=
e><div><br></div><div>It doesn&#39;t look like that&#39;s a typo -- if you =
want it to be `-` instead of `_`, the patch needs to be changed (at least a=
s far as I can tell w/ my admittedly limited automake-foo).</div><div><br><=
/div><div>=C2=A0-George<br></div></div></div>

--0000000000005d592305a3f42034--


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 13:10:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 13:10:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRbce-00007J-1r; Thu, 23 Apr 2020 13:10:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=IVNM=6H=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jRbcd-00007E-AO
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 13:10:31 +0000
X-Inumbo-ID: ceb708ec-8563-11ea-936a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ceb708ec-8563-11ea-936a-12813bfff9fa;
 Thu, 23 Apr 2020 13:10:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
 MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=32YgFPUNcykpCozHXzlEH9ivLTHnq6Q+ZPgnMin88fM=; b=b6U/MKFcdm7yHlvQYLa8+5QfbJ
 MyRPlpbZYdsJ4R5/r7w+exAE7OWQREETldXn+JrRV5a/HZDqcMAUrKqUMl7zlITlRhbDHNO6oSDxq
 iO98rGGAV4AriEuur0bXXDuAUm3W7fV89qDJSxK68wicEmHFtOL2pwQcZynf1JVfak+0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jRbcX-0003pM-Ry; Thu, 23 Apr 2020 13:10:25 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jRbcX-0002On-Iz; Thu, 23 Apr 2020 13:10:25 +0000
Date: Thu, 23 Apr 2020 14:10:22 +0100
From: Wei Liu <wl@xen.org>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Subject: Re: [PATCH v10 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200423131022.727e7uibyqol24xx@debian>
References: <20200416135909.16155-1-roger.pau@citrix.com>
 <20200416135909.16155-2-roger.pau@citrix.com>
 <20200422163338.GF28601@Air-de-Roger>
 <20200423103019.a43rnmub5jdszjhc@debian>
 <0a03deaa-5842-626a-b173-b9569f69f86c@suse.com>
 <20200423105744.GG28601@Air-de-Roger>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200423105744.GG28601@Air-de-Roger>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 12:57:44PM +0200, Roger Pau Monn� wrote:
> On Thu, Apr 23, 2020 at 12:41:49PM +0200, Jan Beulich wrote:
> > On 23.04.2020 12:30, Wei Liu wrote:
> > > On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monn� wrote:
> > >> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
> > >>> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
> > >>>  
> > >>>      return flags;
> > >>>  }
> > >>> +
> > >>> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
> > >>> +{
> > >>> +    unsigned int flags = (is_pv_domain(d) || paging_mode_shadow(d) ? FLUSH_TLB
> > >>> +                                                                   : 0) |
> > >>> +                         (is_hvm_domain(d) && cpu_has_svm ? FLUSH_HVM_ASID_CORE
> > >>> +                                                          : 0);
> > >>
> > >> Maybe I'm getting confused, but I think the above is wrong and ASID
> > >> should _always_ be flushed when running a HVM domain in shadow mode
> > >> regardless of whether the underlying hw is Intel or AMD, ie:
> > >>
> > >> bool shadow = paging_mode_shadow(d);
> > >> unsigned int flags = (shadow ? FLUSH_TLB : 0) |
> > >>                      (is_hvm_domain(d) &&
> > >>                       (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE : 0);
> > > 
> > > This sort of long expression is prone to error. See XSA-316.
> > 
> > To be honest I consider it quite fine. XSA-316 was in particular
> > because of successive closing parentheses, of which there are
> > none here. (This isn't to say I would strictly mind splitting,
> > but I fear this would result in (multiple?) single use local
> > variables.)
> 
> Right now it's exactly (including the indentation):
> 
>     bool shadow = paging_mode_shadow(d);
> 
>     return (shadow ? FLUSH_TLB : 0) |
>            (is_hvm_domain(d) && (cpu_has_svm || shadow) ? FLUSH_HVM_ASID_CORE
>                                                         : 0);
> 
> I could change it to:
> 
>     bool shadow = paging_mode_shadow(d);
>     bool asid = is_hvm_domain(d) && (cpu_has_svm || shadow);
> 
>     return (shadow ? FLUSH_TLB : 0) | (asid ? FLUSH_HVM_ASID_CORE : 0);

IMHO this is much clearer. I merely made a suggestion and it is up to
you and Jan to decide. :-)

Wei.


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 13:11:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 13:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRbdi-0000AL-CM; Thu, 23 Apr 2020 13:11:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=IVNM=6H=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jRbdg-0000A9-K1
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 13:11:36 +0000
X-Inumbo-ID: f4b914ae-8563-11ea-936a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f4b914ae-8563-11ea-936a-12813bfff9fa;
 Thu, 23 Apr 2020 13:11:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=Ktn+b1AR1qHekEIzVhz3tD/UWrG7ZsYuOfaVlGjXTtE=; b=LgxagEnZ2RiedO5iOUK3fjy+i9
 eyGIfIEmFso1rlaQ+e/VhljOj8LJiKHu4JWmy9zlB9IPMrVP0sXlI1U2Nv73PD5l/WoBCKTyworqR
 otP2LX7UIWaPlu508FWH941zfZpUPzVKX8wZ7gru/A4q/sdIhQx4sNrMmE9XA+HCyg00=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jRbdb-0003qG-Uj; Thu, 23 Apr 2020 13:11:31 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jRbdb-0002ba-Kj; Thu, 23 Apr 2020 13:11:31 +0000
Date: Thu, 23 Apr 2020 14:11:29 +0100
From: Wei Liu <wl@xen.org>
To: George Dunlap <dunlapg@umich.edu>
Subject: Re: [PATCH 1/2] tools: build golang tools if go compiler is present
Message-ID: <20200423131129.chfzcnkjvilnzedb@debian>
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
 <20200423102538.vxuo7s2lamkxhoo7@debian>
 <CAFLBxZbWtLLeYr_pQ54zuy1RTq0Xmts5473Ueac6PG9cv9HUOw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFLBxZbWtLLeYr_pQ54zuy1RTq0Xmts5473Ueac6PG9cv9HUOw@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Nick Rosbrook <rosbrookn@gmail.com>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 01:09:43PM +0100, George Dunlap wrote:
> On Thu, Apr 23, 2020 at 11:25 AM Wei Liu <wl@xen.org> wrote:
> 
> > On Wed, Apr 22, 2020 at 08:25:25PM -0400, Nick Rosbrook wrote:
> > > By default, if the go compiler is found by the configure script, build
> > > the golang tools. If the compiler is not found, and
> > > --enable-golang_tools was not explicitly set, do not build to the golang
> >
> > --enable-golang-tools here.
> >
> > > tools.
> > >
> > > The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove
> > > CONFIG_GOLANG from tools/Rules.mk since the new variable is set by
> > > configure.
> > >
> > > Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
> >
> > Acked-by: Wei Liu <wl@xen.org>
> >
> > Note to self: fix commit message and maybe rerun autogen.sh.
> >
> 
> It doesn't look like that's a typo -- if you want it to be `-` instead of
> `_`, the patch needs to be changed (at least as far as I can tell w/ my
> admittedly limited automake-foo).

My bad. The code indeed says --enable-golang_tools.

Wei.

> 
>  -George


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 13:19:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 13:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRbks-0000SU-6S; Thu, 23 Apr 2020 13:19:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XA1d=6H=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRbkq-0000SP-PW
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 13:19:00 +0000
X-Inumbo-ID: fe019594-8564-11ea-b4f4-bc764e2007e4
Received: from mail-lf1-x142.google.com (unknown [2a00:1450:4864:20::142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fe019594-8564-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 13:19:00 +0000 (UTC)
Received: by mail-lf1-x142.google.com with SMTP id x23so4742722lfq.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 06:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=sUVw7OVdAnwNaOAptUNLOUaZYFqjopL7OBaCovDYC0E=;
 b=WDprrvO2RGShHzgCqWSHQVYJrd6ONNoGR4PSFk5FcFzwUz2Bq/gEl07OVsRitV2E3s
 R4Z6esgk7zIVqPVn5wTCev6RxHJj38VH07eqFiw3F72EIdoxACmi780x7dZrE1pzUehh
 R4XJDQSZTK8GhuDgrYvQi26ZvA6vb2pMeMdzTUn8PZAOESXvlkTkbeytgfNgQIOwNX0h
 4AUl/9eKGS2/3BwqiObmpHo31k2kruvig+mx30GaO+5yfOjESKFGIoAzPJjJ/kyKO1cj
 5u88pK1mwiGtiMCUb2exWqBu2x3PZTOIFYxVp0cHOZxHR+Udm5fbepjzn6TbvdRbw/BX
 KEhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=sUVw7OVdAnwNaOAptUNLOUaZYFqjopL7OBaCovDYC0E=;
 b=GhUQkD/r1CshvWxU5arRFOtu5+6Rccw6AHpEFem1Nsb39JXrJgbblX0BvoEcsyW/J5
 RU1kvRmxbvxORoue59dcJtPJIAAGTiVfQjhC2ElP49CrHxhEfBsdY1Y3Cu/G4JQ6JTCX
 RPagUcbuzFoizfcPgIIAh0yz4xQWD1OiOQOtvqfvARMSldKNskbz4JDv50maNYbvAMOH
 KG5/46JN3D3VvylahfSpLPL3JT8Dc3DgnmYji4Eb5yjGmBk1ushIZa1tOS4WtvXjwKz4
 CnyH0kJx7qYQz+fMJlyBVJa7TWDfiJQMwTk5A7yaAr8CHhIETP1d3VLG/pskxsOmOt+g
 BpLg==
X-Gm-Message-State: AGi0PuaQQLY6bjThnsltYpQHi3WEBkrZz2wIJws6VO4wTTuLJUqnoe+1
 0oE4FQGBmtqWdARk9+qoo64DeGN3rg8r3ArQb38=
X-Google-Smtp-Source: APiQypLzqJ/IIKb2psk6LxzgmV7Vg5j25Bx9oh5npWl1rdbyMcw5QymHQQ49ofMGs9JisaJSGUu5Jr6sd9sk0Qx687c=
X-Received: by 2002:a05:6512:406:: with SMTP id
 u6mr2454297lfk.150.1587647938891; 
 Thu, 23 Apr 2020 06:18:58 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1586727061.git.rosbrookn@ainfosec.com>
 <7f03220c9db0a377cd26c0c96d8a10981ec47282.1586727061.git.rosbrookn@ainfosec.com>
 <7B3A2F0A-84C8-48C8-B9B2-C27ABE5F22D1@citrix.com>
In-Reply-To: <7B3A2F0A-84C8-48C8-B9B2-C27ABE5F22D1@citrix.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Thu, 23 Apr 2020 09:18:46 -0400
Message-ID: <CAEBZRSfh55wGQ_k2MC+7Bkz0FNshbbXTf=SBM=pwLLYxRBFcEQ@mail.gmail.com>
Subject: Re: [PATCH 3/4] golang/xenlight: add DevicePciAdd/Remove wrappers
To: George Dunlap <George.Dunlap@citrix.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 6:22 AM George Dunlap <George.Dunlap@citrix.com> wrote:
>
>
>
> > On Apr 12, 2020, at 11:02 PM, Nick Rosbrook <rosbrookn@gmail.com> wrote:
> >
> > Add DevicePciAdd and DevicePciRemove as wrappers for
> > libxl_device_pci_add and libxl_device_pci remove.
> >
> > Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
>
> For 4.14, we should really look at adding functions to the IDL so that all this can be auto-generated.

Agreed, there is obvious repetition here.

> Reviewed-by: George Dunlap <george.dunlap@citrix.com>

Thanks!

-NR


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 13:44:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 13:44:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRc9e-0002rQ-Aa; Thu, 23 Apr 2020 13:44:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=TH3x=6H=gmail.com=dunlapg@srs-us1.protection.inumbo.net>)
 id 1jRc9d-0002rL-Oy
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 13:44:37 +0000
X-Inumbo-ID: 922e06dc-8568-11ea-b58d-bc764e2007e4
Received: from mail-ed1-x543.google.com (unknown [2a00:1450:4864:20::543])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 922e06dc-8568-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 13:44:36 +0000 (UTC)
Received: by mail-ed1-x543.google.com with SMTP id t12so4365067edw.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 06:44:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=umich.edu; s=google-2016-06-03;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=GjcSj1p5l+/+OGkQMA0dkSJgB7UakZeOre6qdXFcV8s=;
 b=TBTay94cIfyvww2f+UarYOUOhDUOiv78LggmfuZh+AFsYe6GlVzu6pQAjFNd8qXKe8
 /Rlk50Ez2v3lTe+yg6bTDxi80OhT2Oz9V7rI7/wtr/MMjuSJlQM9R7b5j0BTIEL0vDno
 uYNHzIbUKPPX0IhLtDhxrmSg9KxTvE6UVQlMxohdBIf0WQqh8ENTeoSQSzBk0dEKqOES
 twRKbQqPwEsz6oBjB2AevyO/IYtesQpl3piYkwtP/3cdiQjvEI5dllSmCgMncGwDe6FJ
 gAXozXxrT4IFgsFuLuTK8CXcstIXbQSzW8DUPFnhF1wNZ7lLtoknQJmNjKB6e87zZda5
 na4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=GjcSj1p5l+/+OGkQMA0dkSJgB7UakZeOre6qdXFcV8s=;
 b=kp0qHE+PAE1EXG4E+SBI2WTqNrDbfbq+e4+DpkR5J/wdQPXtBwIHAsEDz+AnXDGujJ
 m2t5wktxQIXFIDBNJ9hyLLDL5CxZLrt4Tampl/S6+1I0N5cwfM00rHMGX6RVTqeCi0fo
 SPMwB73PF8SOf+SMN0sPY0Art5ob1bVikwBUqOXbBsBYX5VDXv/T+RPWQJ8ceBgpMOJ3
 bZAR0eTN1Tlm6am4113UFHeJepIPcU0jzh2JMxdIqgHmg3PWKVcCd3It1TZLAsexemHj
 /uDMqhNoYAXKpFd6eRk4v6RJV+A34WEjDA/RkiLxJKetgMsvuvFrLZ4lQ6jcB9JLck9x
 hLaw==
X-Gm-Message-State: AGi0PuaLFxvWQxg0l9rmgu1VAir54Stlmnwd1xRFO6CpzmaMUE42oZ/J
 qNZCXWbsbfMTtQfOu/Y4UIjYugAzaeZpjzl3RaE=
X-Google-Smtp-Source: APiQypJgnAXT2lstzIo19dygyd39im1hYbRTFDWenARY3of77Ut+HlWJW8y/FgN71EQbhzLu/9UlnHU/eoJTO5zHeuI=
X-Received: by 2002:a50:f74c:: with SMTP id j12mr1922508edn.197.1587649476037; 
 Thu, 23 Apr 2020 06:44:36 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
In-Reply-To: <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
From: George Dunlap <dunlapg@umich.edu>
Date: Thu, 23 Apr 2020 14:44:24 +0100
Message-ID: <CAFLBxZaKiuqpmVvP2ww9YbuTkCm9wdBKGdMJOrT=sTaJSaycqg@mail.gmail.com>
Subject: Re: [PATCH 1/2] tools: build golang tools if go compiler is present
To: Nick Rosbrook <rosbrookn@gmail.com>,
 George Dunlap <george.dunlap@citrix.com>
Content-Type: multipart/alternative; boundary="0000000000000c104305a3f57370"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--0000000000000c104305a3f57370
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 23, 2020 at 1:51 AM Nick Rosbrook <rosbrookn@gmail.com> wrote:

> By default, if the go compiler is found by the configure script, build
> the golang tools. If the compiler is not found, and
> --enable-golang_tools was not explicitly set, do not build to the golang
> tools.
>
> The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove
> CONFIG_GOLANG from tools/Rules.mk since the new variable is set by
> configure.
>
> Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
> ---
>  config/Tools.mk.in |   1 +
>  m4/golang.m4       |   4 ++
>  tools/Makefile     |   2 +-
>  tools/Rules.mk     |   2 -
>  tools/configure    | 138 +++++++++++++++++++++++++++++++++++++++++++++
>  tools/configure.ac |  12 ++++
>  6 files changed, 156 insertions(+), 3 deletions(-)
>  create mode 100644 m4/golang.m4
>
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index 189fda1596..2c219f5477 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -55,6 +55,7 @@ CONFIG_QEMU_TRAD    := @qemu_traditional@
>  CONFIG_QEMU_XEN     := @qemu_xen@
>  CONFIG_QEMUU_EXTRA_ARGS:= @EXTRA_QEMUU_CONFIGURE_ARGS@
>  CONFIG_LIBNL        := @libnl@
> +CONFIG_GOLANG_TOOLS := @golang_tools@
>
>  CONFIG_SYSTEMD      := @systemd@
>  SYSTEMD_CFLAGS      := @SYSTEMD_CFLAGS@
> diff --git a/m4/golang.m4 b/m4/golang.m4
> new file mode 100644
> index 0000000000..0b4bd54ce0
> --- /dev/null
> +++ b/m4/golang.m4
> @@ -0,0 +1,4 @@
> +AC_DEFUN([AC_PROG_GO], [
> +    dnl Check for the go compiler
> +    AC_CHECK_TOOL([GO],[go],[no])
> +])
>

AFAICT this only checks for the existence of the binary.  Will the bindings
compile with all versions of go?  If not, should we try to check the
version here?

Thanks,
 -George

--0000000000000c104305a3f57370
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 23, 2020 at 1:51 AM Nick =
Rosbrook &lt;<a href=3D"mailto:rosbrookn@gmail.com">rosbrookn@gmail.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">By d=
efault, if the go compiler is found by the configure script, build<br>
the golang tools. If the compiler is not found, and<br>
--enable-golang_tools was not explicitly set, do not build to the golang<br=
>
tools.<br>
<br>
The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove<br>
CONFIG_GOLANG from tools/Rules.mk since the new variable is set by<br>
configure.<br>
<br>
Signed-off-by: Nick Rosbrook &lt;<a href=3D"mailto:rosbrookn@ainfosec.com" =
target=3D"_blank">rosbrookn@ainfosec.com</a>&gt;<br>
---<br>
=C2=A0config/<a href=3D"http://Tools.mk.in" rel=3D"noreferrer" target=3D"_b=
lank">Tools.mk.in</a> |=C2=A0 =C2=A01 +<br>
=C2=A0m4/golang.m4=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A04 ++<br>
=C2=A0tools/Makefile=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A02 +-<br>
=C2=A0tools/Rules.mk=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A02 -<br>
=C2=A0tools/configure=C2=A0 =C2=A0 | 138 ++++++++++++++++++++++++++++++++++=
+++++++++++<br>
=C2=A0tools/<a href=3D"http://configure.ac" rel=3D"noreferrer" target=3D"_b=
lank">configure.ac</a> |=C2=A0 12 ++++<br>
=C2=A06 files changed, 156 insertions(+), 3 deletions(-)<br>
=C2=A0create mode 100644 m4/golang.m4<br>
<br>
diff --git a/config/<a href=3D"http://Tools.mk.in" rel=3D"noreferrer" targe=
t=3D"_blank">Tools.mk.in</a> b/config/<a href=3D"http://Tools.mk.in" rel=3D=
"noreferrer" target=3D"_blank">Tools.mk.in</a><br>
index 189fda1596..2c219f5477 100644<br>
--- a/config/<a href=3D"http://Tools.mk.in" rel=3D"noreferrer" target=3D"_b=
lank">Tools.mk.in</a><br>
+++ b/config/<a href=3D"http://Tools.mk.in" rel=3D"noreferrer" target=3D"_b=
lank">Tools.mk.in</a><br>
@@ -55,6 +55,7 @@ CONFIG_QEMU_TRAD=C2=A0 =C2=A0 :=3D @qemu_traditional@<br>
=C2=A0CONFIG_QEMU_XEN=C2=A0 =C2=A0 =C2=A0:=3D @qemu_xen@<br>
=C2=A0CONFIG_QEMUU_EXTRA_ARGS:=3D @EXTRA_QEMUU_CONFIGURE_ARGS@<br>
=C2=A0CONFIG_LIBNL=C2=A0 =C2=A0 =C2=A0 =C2=A0 :=3D @libnl@<br>
+CONFIG_GOLANG_TOOLS :=3D @golang_tools@<br>
<br>
=C2=A0CONFIG_SYSTEMD=C2=A0 =C2=A0 =C2=A0 :=3D @systemd@<br>
=C2=A0SYSTEMD_CFLAGS=C2=A0 =C2=A0 =C2=A0 :=3D @SYSTEMD_CFLAGS@<br>
diff --git a/m4/golang.m4 b/m4/golang.m4<br>
new file mode 100644<br>
index 0000000000..0b4bd54ce0<br>
--- /dev/null<br>
+++ b/m4/golang.m4<br>
@@ -0,0 +1,4 @@<br>
+AC_DEFUN([AC_PROG_GO], [<br>
+=C2=A0 =C2=A0 dnl Check for the go compiler<br>
+=C2=A0 =C2=A0 AC_CHECK_TOOL([GO],[go],[no])<br>
+])<br></blockquote><div><br></div><div>AFAICT this only checks for the exi=
stence of the binary.=C2=A0 Will the bindings compile with all versions of =
go?=C2=A0 If not, should we try to check the version here?</div><div><br></=
div>Thanks,</div><div class=3D"gmail_quote">=C2=A0-George<br></div></div>

--0000000000000c104305a3f57370--


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 14:17:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 14:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRcfB-0005SC-To; Thu, 23 Apr 2020 14:17:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRcfA-0005S7-Hc
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 14:17:12 +0000
X-Inumbo-ID: 1c50578a-856d-11ea-9382-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1c50578a-856d-11ea-9382-12813bfff9fa;
 Thu, 23 Apr 2020 14:17:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=00nzxHABGLX/8gFIUomy+T5cWjSp8i8EgYD4/is3iQ4=; b=RgA2WlUhg4/fn8e7/q/fie5Bk
 0B1n/0CJNpgGOuDFK8OKZ1q3E56s795p1CCFJPM5NWK1YCeem6ZokIM46a4Rznz3U1u4pq7iUxXFd
 klYRSGr0prnuZGeRjMdxhBv/fbhbzjT5Xa3VvQ3TAgua+FSRkTyffBzrN5GmLATLkSDb8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRcf3-0005Ih-VN; Thu, 23 Apr 2020 14:17:05 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRcf3-00064H-K8; Thu, 23 Apr 2020 14:17:05 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRcf3-0005MZ-JF; Thu, 23 Apr 2020 14:17:05 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149760-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149760: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f9e707aa97b204229dde5125116364c9e410ef67
X-Osstest-Versions-That: xen=bb215898d46395080b911c15e5c3a7fff0c150cb
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 14:17:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149760 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149760/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f9e707aa97b204229dde5125116364c9e410ef67
baseline version:
 xen                  bb215898d46395080b911c15e5c3a7fff0c150cb

Last test of basis   149748  2020-04-23 09:00:40 Z    0 days
Testing same since   149760  2020-04-23 12:01:07 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Nick Rosbrook <rosbrookn@ainfosec.com>
  Nick Rosbrook <rosbrookn@gmail.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   bb215898d4..f9e707aa97  f9e707aa97b204229dde5125116364c9e410ef67 -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 14:25:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 14:25:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRcmi-0006LK-SQ; Thu, 23 Apr 2020 14:25:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRcmh-0006LF-5p
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 14:24:59 +0000
X-Inumbo-ID: 32498d4e-856e-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 32498d4e-856e-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 14:24:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=QMhRQYy/ptSYStqhL+g4fPyf0HXFQNVX1RnU+C+hClw=; b=0IpjbhVsa4Ybq1T0z+vbbEWWt
 IexHsN/T+hECs7trEV/nZnmq4T+1HRucphkSYSF45bU/9v9PNsYF2aZPhjIchmsINnnKu4pbF4+7e
 D2PECbfDXdRgQtV+ux2OWqPs8FyiHnYdg67KQtb/COmbxKFj352U6ULDgBegud05iI5vc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRcma-0005Rg-7Z; Thu, 23 Apr 2020 14:24:52 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRcmZ-0006O1-FP; Thu, 23 Apr 2020 14:24:51 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRcmZ-0001ig-DU; Thu, 23 Apr 2020 14:24:51 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149744-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149744: tolerable trouble: fail/pass/starved -
 PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 qemu-mainline:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: qemuu=ee573f5326046223b6eef4ae7fbfec31d274e093
X-Osstest-Versions-That: qemuu=7769c23774d1278f60b9e40d2c0b98784de6425f
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 14:24:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149744 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149744/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149737
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149737
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149737
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149737
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149737
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149737
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate               starved  n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate               starved  n/a

version targeted for testing:
 qemuu                ee573f5326046223b6eef4ae7fbfec31d274e093
baseline version:
 qemuu                7769c23774d1278f60b9e40d2c0b98784de6425f

Last test of basis   149737  2020-04-22 13:06:30 Z    1 days
Testing same since   149744  2020-04-23 03:46:20 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Peter Maydell <peter.maydell@linaro.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                starved 
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 starved 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   7769c23774..ee573f5326  ee573f5326046223b6eef4ae7fbfec31d274e093 -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 14:30:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 14:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRcsC-00079a-Ix; Thu, 23 Apr 2020 14:30:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRcsB-00079V-7g
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 14:30:39 +0000
X-Inumbo-ID: fc52667e-856e-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fc52667e-856e-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 14:30:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=RN0XykwGYCvBg86UKe5NMMxk6IX19GvSYRjJAQlBg14=; b=cmT8O2ll5vzwN5nLqkOuqqiwx
 ChbRL2sXeql0vZX8CMevidOAe8H2aNefu0WbIgSZnMfW6ZfSuq2ZaVzddUbnEJNHhQbISXG+KeSyX
 LbnRMg3Fgc/StHhPF42mksGj/wObf46sMOpDuQPBpWjSKxbswiGIYIqonQqp4geZ4mBfA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRcs3-0005YW-AI; Thu, 23 Apr 2020 14:30:31 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRcs2-0006cR-Mw; Thu, 23 Apr 2020 14:30:30 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRcs2-0004cT-LY; Thu, 23 Apr 2020 14:30:30 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149743-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149743: regressions - trouble: fail/pass/starved
X-Osstest-Failures: linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:guest-start/debianhvm.repeat:fail:regression
 linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore.2:fail:allowable
 linux-linus:test-armhf-armhf-xl-rtds:guest-start:fail:allowable
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 linux-linus:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: linux=c578ddb39e565139897124e74e5a43e56538cb33
X-Osstest-Versions-That: linux=18bf34080c4c3beb6699181986cc97dd712498fe
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 14:30:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149743 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149743/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 guest-start/debianhvm.repeat fail REGR. vs. 149731

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     17 guest-saverestore.2      fail REGR. vs. 149731
 test-armhf-armhf-xl-rtds     12 guest-start              fail REGR. vs. 149731

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149731
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149731
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149731
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149731
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149731
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149731
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149731
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149731
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate               starved  n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate               starved  n/a

version targeted for testing:
 linux                c578ddb39e565139897124e74e5a43e56538cb33
baseline version:
 linux                18bf34080c4c3beb6699181986cc97dd712498fe

Last test of basis   149731  2020-04-22 04:00:57 Z    1 days
Testing same since   149743  2020-04-23 03:15:23 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Righi <andrea.righi@canonical.com>
  Colin Ian King <colin.king@canonical.com>
  Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
  Kees Cook <keescook@chromium.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Michael Ellerman <mpe@ellerman.id.au>
  Sandipan Das <sandipan@linux.ibm.com>
  Shuah Khan <skhan@linuxfoundation.org>
  Steven Rostedt (VMware) <rostedt@goodmis.org>
  Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
  Tyler Hicks <tyhicks@linux.microsoft.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                starved 
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 starved 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit c578ddb39e565139897124e74e5a43e56538cb33
Merge: 18bf34080c4c b87080eab4c1
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Apr 22 10:47:49 2020 -0700

    Merge tag 'linux-kselftest-5.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
    
    Pull kselftest fixes from Shuah Khan:
     "This consists of fixes to runner scripts and individual test run-time
      bugs. Includes fixes to tpm2 and memfd test run-time regressions"
    
    * tag 'linux-kselftest-5.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
      selftests/ipc: Fix test failure seen after initial test run
      Revert "Kernel selftests: tpm2: check for tpm support"
      selftests/ftrace: Add CONFIG_SAMPLE_FTRACE_DIRECT=m kconfig
      selftests/seccomp: allow clock_nanosleep instead of nanosleep
      kselftest/runner: allow to properly deliver signals to tests
      selftests/harness: fix spelling mistake "SIGARLM" -> "SIGALRM"
      selftests: Fix memfd test run-time regression
      selftests: vm: Fix 64-bit test builds for powerpc64le
      selftests: vm: Do not override definition of ARCH

commit b87080eab4c1377706c113fc9c0157f19ea8fed1
Author: Tyler Hicks <tyhicks@linux.microsoft.com>
Date:   Mon Apr 13 15:21:45 2020 -0500

    selftests/ipc: Fix test failure seen after initial test run
    
    After successfully running the IPC msgque test once, subsequent runs
    result in a test failure:
    
      $ sudo ./run_kselftest.sh
      TAP version 13
      1..1
      # selftests: ipc: msgque
      # Failed to get stats for IPC queue with id 0
      # Failed to dump queue: -22
      # Bail out!
      # # Pass 0 Fail 0 Xfail 0 Xpass 0 Skip 0 Error 0
      not ok 1 selftests: ipc: msgque # exit=1
    
    The dump_queue() function loops through the possible message queue index
    values using calls to msgctl(kern_id, MSG_STAT, ...) where kern_id
    represents the index value. The first time the test is ran, the initial
    index value of 0 is valid and the test is able to complete. The index
    value of 0 is not valid in subsequent test runs and the loop attempts to
    try index values of 1, 2, 3, and so on until a valid index value is
    found that corresponds to the message queue created earlier in the test.
    
    The msgctl() syscall returns -1 and sets errno to EINVAL when invalid
    index values are used. The test failure is caused by incorrectly
    comparing errno to -EINVAL when cycling through possible index values.
    
    Fix invalid test failures on subsequent runs of the msgque test by
    correctly comparing errno values to a non-negated EINVAL.
    
    Fixes: 3a665531a3b7 ("selftests: IPC message queue copy feature test")
    Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

commit aaa2d92efe1f972567f1691b423ab8dc606ab3a9
Author: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date:   Sun Apr 12 17:23:07 2020 +0300

    Revert "Kernel selftests: tpm2: check for tpm support"
    
    This reverts commit b32694cd0724d4ceca2c62cc7c3d3a8d1ffa11fc.
    
    The original comment was neither reviewed nor tested. Thus, this the
    *only* possible action to take.
    
    Cc: Nikita Sobolev <Nikita.Sobolev@synopsys.com>
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

commit cdfe56d9012bcff266880177c4c7caf9821f63b0
Author: Xiao Yang <yangx.jy@cn.fujitsu.com>
Date:   Sun Apr 5 09:44:57 2020 +0800

    selftests/ftrace: Add CONFIG_SAMPLE_FTRACE_DIRECT=m kconfig
    
    ftrace-direct.tc and kprobe-direct.tc require CONFIG_SAMPLE_FTRACE_DIRECT=m
    so add it to config file which is used by merge_config.sh.
    
    Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
    Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

commit d42b8dbec46c08c6bd3f9d264127bd4910581c07
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Wed Apr 8 20:57:53 2020 -0300

    selftests/seccomp: allow clock_nanosleep instead of nanosleep
    
    glibc 2.31 calls clock_nanosleep when its nanosleep function is used. So
    the restart_syscall fails after that. In order to deal with it, we trace
    clock_nanosleep and nanosleep. Then we check for either.
    
    This works just fine on systems with both glibc 2.30 and glibc 2.31,
    whereas it failed before on a system with glibc 2.31.
    
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

commit 651e0d881461ab2b1cd5cbec3a642d22fc8d6057
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Fri Apr 10 12:02:59 2020 +0200

    kselftest/runner: allow to properly deliver signals to tests
    
    While running seccomp_bpf, kill_after_ptrace() gets stuck if we run it
    via /usr/bin/timeout (that is the default), until the timeout expires.
    
    This is because /usr/bin/timeout is preventing to properly deliver
    signals to ptrace'd children (SIGSYS in this case).
    
    This problem can be easily reproduced by running:
    
     $ sudo make TARGETS=seccomp kselftest
     ...
    
     # [ RUN      ] TRACE_syscall.skip_a#
     not ok 1 selftests: seccomp: seccomp_bpf # TIMEOUT
    
    The test is hanging at this point until the timeout expires and then it
    reports the timeout error.
    
    Prevent this problem by passing --foreground to /usr/bin/timeout,
    allowing to properly deliver signals to children processes.
    
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

commit d925c896956283cf12634c4223f62ad2c080da29
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Mar 27 09:06:48 2020 +0000

    selftests/harness: fix spelling mistake "SIGARLM" -> "SIGALRM"
    
    There a few identical spelling mistakes, fix these.
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

commit ffa773e1011d57550e3bf9aea98468c1c4bea552
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Tue Apr 7 16:44:46 2020 -0600

    selftests: Fix memfd test run-time regression
    
    Commit d3fd949abd3e ("selftests: Fix memfd to support relocatable
    build (O=objdir)") introduced regression run-time regression with
    a change to include programs that should be run from shell scripts
    to list of programs that run as independent tests. This fix restores
    the original designation.
    
    Fixes: d3fd949abd3e ("selftests: Fix memfd to support relocatable build (O=objdir)")
    Reported-by: kernel test robot <rong.a.chen@intel.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

commit 963e3e9c9a127013eb4d3c82eb997068b1adbb89
Author: Sandipan Das <sandipan@linux.ibm.com>
Date:   Thu Jan 30 12:31:19 2020 +0530

    selftests: vm: Fix 64-bit test builds for powerpc64le
    
    Some tests are built only for 64-bit systems. This makes
    sure that these tests are built for both big and little
    endian variants of powerpc64.
    
    Fixes: 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on 64bit arch")
    Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
    Tested-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

commit 24c3f063c57b2a8ae21b259bcfa7690e2eb56dd9
Author: Sandipan Das <sandipan@linux.ibm.com>
Date:   Thu Jan 30 12:31:18 2020 +0530

    selftests: vm: Do not override definition of ARCH
    
    Independent builds of the vm selftests is currently broken because
    commit 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on
    64bit arch") overrides the value of ARCH with the machine name from
    uname. This does not always match the architecture names used for
    tasks like header installation.
    
    E.g. for building tests on powerpc64, we need ARCH=powerpc
    and not ARCH=ppc64 or ARCH=ppc64le. Otherwise, the build
    fails as shown below.
    
      $ uname -m
      ppc64le
    
      $ make -C tools/testing/selftests/vm
      make: Entering directory '/home/sandipan/linux/tools/testing/selftests/vm'
      make --no-builtin-rules ARCH=ppc64le -C ../../../.. headers_install
      make[1]: Entering directory '/home/sandipan/linux'
      Makefile:653: arch/ppc64le/Makefile: No such file or directory
      make[1]: *** No rule to make target 'arch/ppc64le/Makefile'.  Stop.
      make[1]: Leaving directory '/home/sandipan/linux'
      ../lib.mk:50: recipe for target 'khdr' failed
      make: *** [khdr] Error 2
      make: Leaving directory '/home/sandipan/linux/tools/testing/selftests/vm'
    
    Fixes: 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on 64bit arch")
    Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
    Tested-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 14:31:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 14:31:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRctD-0007EA-1Q; Thu, 23 Apr 2020 14:31:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRctC-0007E5-DA
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 14:31:42 +0000
X-Inumbo-ID: 229f9cc0-856f-11ea-9389-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 229f9cc0-856f-11ea-9389-12813bfff9fa;
 Thu, 23 Apr 2020 14:31:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=UWektqf9Jnbx7D/5B6Q0OmTPSQFHorx1vNIWWI+rITA=; b=fSX4xQcWMnjP/2zU9iFcWrit9
 kfZIEBU+X+XrvhqAYVw6UlZ3jAmWrUaYbB4I/6fqNdxnE4nQGcDF1lzqnAwqsSZtDcr2iWHS1SXmA
 FBHMlsLCCKH15n+gIqCzrXx1JgtKZCIPoUvgAae6l2aM3REEcxM2jZpnODdJU+z93PMGs=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRct5-0005b2-HN; Thu, 23 Apr 2020 14:31:35 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRct5-0006fA-8m; Thu, 23 Apr 2020 14:31:35 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRct5-00051D-8A; Thu, 23 Apr 2020 14:31:35 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149747-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149747: all pass - PUSHED
X-Osstest-Versions-This: ovmf=3a3a3af4a29ee36b1db11842d40b74f2de892a35
X-Osstest-Versions-That: ovmf=93f6df5f3b2553b8f5188d2a6ba70f3f5cfab0bb
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 14:31:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149747 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149747/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 3a3a3af4a29ee36b1db11842d40b74f2de892a35
baseline version:
 ovmf                 93f6df5f3b2553b8f5188d2a6ba70f3f5cfab0bb

Last test of basis   149742  2020-04-22 23:10:49 Z    0 days
Testing same since   149747  2020-04-23 07:21:34 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Fan, Zhiju <zhijux.fan@intel.com>
  Zhiju.Fan <zhijux.fan@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   93f6df5f3b..3a3a3af4a2  3a3a3af4a29ee36b1db11842d40b74f2de892a35 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 14:43:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 14:43:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRd4d-0008Dm-6q; Thu, 23 Apr 2020 14:43:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Oa1P=6H=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRd4b-0008Dh-W7
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 14:43:30 +0000
X-Inumbo-ID: cbab5a10-8570-11ea-938c-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cbab5a10-8570-11ea-938c-12813bfff9fa;
 Thu, 23 Apr 2020 14:43:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587653009;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=KT99uiiLXXxW7b5WZsHxQ+NKDnuJktuqGQH/Vslb418=;
 b=F40VKq7Kpji2ig0R2IwHEA0gsdj1kA3T1s3DESBEu+UA1mAy6X5pSBvH
 etQ6bXjGXXQ3Bww0qzlm/QXkLAAFI5B3RR3r8tO+i2IX/YC5ortgMqlt8
 D2v3irayQi4pvsuavFYdS1lIa+A4opNmb6xcND4ELgNJM7RjBYL/Br5UF 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: OolVIUDptq52i7xalbS+OChH4n9xumSf2OwlCbjh+a5/2jt51Jt3Vhz2izdflP0hqByt9pmkEV
 2q3Lrk1iCc08qyElGLk796LvmPsXMMx324WSu36hMV6BK94ayBsZ58kECyauXsYPaPpQYV/11c
 y9plY3vZt7KgV/NPapjupaKAnGUKxxhnz/UwAWudvPD8F6oW19JMf3vpE9ObO3+FFhQgzWl5UI
 XMm3dN1CxkaEChjf/3Ed1rx7ut/tX9NxPbmBgKLFwl5n3JZCAHXHBJYxFztsrIMai9rdnSByyU
 N4o=
X-SBRS: 2.7
X-MesageID: 16119446
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16119446"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH OSSTEST] examine/cpu: fix fetching number of threads
Date: Thu, 23 Apr 2020 16:43:03 +0200
Message-ID: <20200423144303.55251-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The way to fetch the number of threads from the output of xl info is
wrong, as the result of =~ is either true or false, but will never be a
numeric value.

Fix the regex to have a capture group in order to fetch the number of
threads, and store the capture in the threads variable.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 ts-examine-cpu | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ts-examine-cpu b/ts-examine-cpu
index 81cf7544..fbf01dfb 100755
--- a/ts-examine-cpu
+++ b/ts-examine-cpu
@@ -26,7 +26,8 @@ our ($whhost) = @ARGV;
 $whhost ||= 'host';
 our $ho= selecthost($whhost);
 our $info = target_cmd_output_root($ho, 'xl info', 10);
-our $threads = $info =~ /^threads_per_core\s*:\s.*/m;
+$info =~ /^threads_per_core\s*:\s(.*)$/m or die "missing or malformed info";
+our $threads = $1;
 
 logm("$ho->{Ident} threads per core: $threads");
 hostflag_putative_record($ho, "hw-smt", $threads > 1);
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 14:56:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 14:56:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRdHQ-0000ig-E6; Thu, 23 Apr 2020 14:56:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Oa1P=6H=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRdHO-0000ib-Kh
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 14:56:42 +0000
X-Inumbo-ID: a40246f2-8572-11ea-b4f4-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a40246f2-8572-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 14:56:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587653802;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=QpCI7YXxHwShyppqHcYq6H86Jk+fUGeiABo1GthUHAc=;
 b=dRm915RAk7bsygayzORyuXlPG5kQ9jj9SWls6lUHBebFsgEm+XA+kJ8T
 1weGcP9x8UxVTbBWWTVlyAH6Hlb/OK34d/HQRY25fN+MzwehwfCJkYKDK
 T6KUEzx58a+jGIvY0E/UnuvLPoL4clz5jJ/dGZgglpfctbdi7uRM+m3cD c=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: ae9DNKZbbFwHdkdP5lV6sHPol3tpC/oSKbTjUc2Wmf9altxUoU4A+B/chhz6HEiRLqOmzqzORX
 GctKTDbl+Yu0rqLLTebx+ae0WgdcBDEJWGGMHQpn/SmL6PotMdxYCxnxDlP+Qh7YtaCT0ccEZS
 2u+EvEtiPctPlfpRqAe8p2DwTehDpHxRh3fEoF6m2EclpiwHVa3L69lUSAPJZm/3i0EPiF7Ogh
 hDDPR7rzXR+rS0hFtK+wj/EKoPXf22rDcp+/LPvmeZc2C/dai2kh82N084FDp0qmytk1aSIUxZ
 Lfc=
X-SBRS: 2.7
X-MesageID: 16120326
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16120326"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v11 0/3] x86/guest: use assisted TLB flush in guest mode
Date: Thu, 23 Apr 2020 16:56:08 +0200
Message-ID: <20200423145611.55378-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George
 Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hello,

This is the remaining of the assisted TLB flush series. This last set of
patches enable the usage of the Xen assisted flush when running nested
on Xen.

Thanks, Roger.

Roger Pau Monne (3):
  x86/tlb: introduce a flush HVM ASIDs flag
  x86/tlb: allow disabling the TLB clock
  x86/tlb: use Xen L0 assisted TLB flush when available

 xen/arch/x86/flushtlb.c                | 42 +++++++++++++++++++++-----
 xen/arch/x86/guest/hypervisor.c        | 14 +++++++++
 xen/arch/x86/guest/xen/xen.c           |  6 ++++
 xen/arch/x86/mm/hap/hap.c              |  8 ++---
 xen/arch/x86/mm/hap/nested_hap.c       |  2 +-
 xen/arch/x86/mm/p2m-pt.c               |  5 +--
 xen/arch/x86/mm/paging.c               |  2 +-
 xen/arch/x86/mm/shadow/common.c        | 18 +++++------
 xen/arch/x86/mm/shadow/hvm.c           |  2 +-
 xen/arch/x86/mm/shadow/multi.c         | 22 +++++++++-----
 xen/arch/x86/smp.c                     |  7 +++++
 xen/include/asm-x86/flushtlb.h         | 26 +++++++++++++++-
 xen/include/asm-x86/guest/hypervisor.h | 17 +++++++++++
 13 files changed, 136 insertions(+), 35 deletions(-)

-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 14:56:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 14:56:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRdHT-0000iv-Lu; Thu, 23 Apr 2020 14:56:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Oa1P=6H=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRdHR-0000im-Re
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 14:56:45 +0000
X-Inumbo-ID: a549ba54-8572-11ea-9393-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a549ba54-8572-11ea-9393-12813bfff9fa;
 Thu, 23 Apr 2020 14:56:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587653803;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=A+41uuweYOPK2zy96DBA3O55H3T+IJmZa1Mxares+eM=;
 b=EBqISCT4oO84bqZUHo7IGYBTAJkMTOYMy2ORKRgLFbkDangRA0dNlJge
 FF//hbjGNO9SUM4Ng3fCR/VuID0UntrBxPJ3NjtIvSp5T2beRcQVW8zxI
 xU3LStXHdX/XZ83jAqgcqhT1IL+8smUpwdbYz9kjfkOX1hVDYnpBztp2I Q=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 987ncg5eR+9bKvSPev/w1qOuJ5pOd9jD2FCXU1gNh2FJS29nxJIiaLv/C02ZOA+IY8lo7ANQXw
 WCxn8po7KTNvqcYhE0w5eGe1VeLxga4eEnnd9lHgGVSuExEEehZl6lr2FsLaJ3tv2rcONd64AZ
 AUzwqAeWeZ0NtZC+8vzkdNAPudjzd8F+b6Xb9aZTdavag3j4CoJAlMsjzjtQQD/YFsJG2yQny5
 eHrjdWYdXItXG/aJ2andxindIhcl/jBAmI5FXo7EJ9KU7Zb1OLTMxVmgh5/nkLsx//lf7mN1sZ
 43Q=
X-SBRS: 2.7
X-MesageID: 16819479
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16819479"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v11 2/3] x86/tlb: allow disabling the TLB clock
Date: Thu, 23 Apr 2020 16:56:10 +0200
Message-ID: <20200423145611.55378-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200423145611.55378-1-roger.pau@citrix.com>
References: <20200423145611.55378-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.

This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes: Xen itself for example offers a HVMOP_flush_tlbs hypercall in
order to perform a TLB flush without having to IPI each CPU. When
using such mechanisms it's no longer possible to keep a timestamp of
the flushes on each CPU, as they are performed by the underlying
hypervisor.

Offer a boolean in order to signal Xen that the timestamped TLB
shouldn't be used. This avoids keeping the timestamps of the flushes,
and also forces NEED_FLUSH to always return true.

No functional change intended, as this change doesn't introduce any
user that disables the timestamped TLB.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/flushtlb.c        | 19 +++++++++++++------
 xen/include/asm-x86/flushtlb.h | 17 ++++++++++++++++-
 2 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 0c40b5d273..25798df50f 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -33,6 +33,9 @@
 u32 tlbflush_clock = 1U;
 DEFINE_PER_CPU(u32, tlbflush_time);
 
+/* Signals whether the TLB flush clock is in use. */
+bool __read_mostly tlb_clk_enabled = true;
+
 /*
  * pre_flush(): Increment the virtual TLB-flush clock. Returns new clock value.
  * 
@@ -83,12 +86,13 @@ static void post_flush(u32 t)
 static void do_tlb_flush(void)
 {
     unsigned long flags, cr4;
-    u32 t;
+    u32 t = 0;
 
     /* This non-reentrant function is sometimes called in interrupt context. */
     local_irq_save(flags);
 
-    t = pre_flush();
+    if ( tlb_clk_enabled )
+        t = pre_flush();
 
     if ( use_invpcid )
         invpcid_flush_all();
@@ -100,7 +104,8 @@ static void do_tlb_flush(void)
     else
         write_cr3(read_cr3());
 
-    post_flush(t);
+    if ( tlb_clk_enabled )
+        post_flush(t);
 
     local_irq_restore(flags);
 }
@@ -108,7 +113,7 @@ static void do_tlb_flush(void)
 void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
 {
     unsigned long flags, old_cr4;
-    u32 t;
+    u32 t = 0;
 
     /* Throughout this function we make this assumption: */
     ASSERT(!(cr4 & X86_CR4_PCIDE) || !(cr4 & X86_CR4_PGE));
@@ -116,7 +121,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
     /* This non-reentrant function is sometimes called in interrupt context. */
     local_irq_save(flags);
 
-    t = pre_flush();
+    if ( tlb_clk_enabled )
+        t = pre_flush();
     hvm_flush_guest_tlbs();
 
     old_cr4 = read_cr4();
@@ -169,7 +175,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
     if ( cr4 & X86_CR4_PCIDE )
         invpcid_flush_all_nonglobals();
 
-    post_flush(t);
+    if ( tlb_clk_enabled )
+        post_flush(t);
 
     local_irq_restore(flags);
 }
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 798049b6ad..8639427cce 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -21,10 +21,21 @@ extern u32 tlbflush_clock;
 /* Time at which each CPU's TLB was last flushed. */
 DECLARE_PER_CPU(u32, tlbflush_time);
 
-#define tlbflush_current_time() tlbflush_clock
+/* TLB clock is in use. */
+extern bool tlb_clk_enabled;
+
+static inline uint32_t tlbflush_current_time(void)
+{
+    /* Returning 0 from tlbflush_current_time will always force a flush. */
+    return tlb_clk_enabled ? tlbflush_clock : 0;
+}
 
 static inline void page_set_tlbflush_timestamp(struct page_info *page)
 {
+    /* Avoid the write if the TLB clock is disabled. */
+    if ( !tlb_clk_enabled )
+        return;
+
     /*
      * Prevent storing a stale time stamp, which could happen if an update
      * to tlbflush_clock plus a subsequent flush IPI happen between the
@@ -67,6 +78,10 @@ static inline void tlbflush_filter(cpumask_t *mask, uint32_t page_timestamp)
 {
     unsigned int cpu;
 
+    /* Short-circuit: there's no need to iterate if the clock is disabled. */
+    if ( !tlb_clk_enabled )
+        return;
+
     for_each_cpu ( cpu, mask )
         if ( !NEED_FLUSH(per_cpu(tlbflush_time, cpu), page_timestamp) )
             __cpumask_clear_cpu(cpu, mask);
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 14:56:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 14:56:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRdHU-0000jC-TW; Thu, 23 Apr 2020 14:56:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Oa1P=6H=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRdHT-0000it-HR
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 14:56:47 +0000
X-Inumbo-ID: a4414168-8572-11ea-b58d-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a4414168-8572-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 14:56:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587653803;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=lw0igEL+hLah+EJErxdPOZY2wmhG4dh1CdAbnB4ziu8=;
 b=aMc591cySkNIk05zQeYW3Y4S5qF1DjHvGdIdJCdU157DpKuo0JQKQejK
 lFySGpG6J51UGTLfdi4EZS4MkXHd/qcROwQ1e0OYPdIok4AViL3vGMbmr
 D4qzrlo8fWnq+RUhf4LyYIEzBuCAv9zRpAKY2KDHZ5DrtAaekQmk3rIKM g=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 6Bt5GGHe4QvAM1PydNq68I5FNT8OBYyMHNGt6Tx7xNYcuWi+O3ZhZ1KwCf5hdrSod6vdCF5mrn
 vVhKbOrEpnxjx/5y0JCI0CB9BNL/DGsp/GdqWixn6D775fZCLsjQ8aDdjfDqKgwofH2xj/Qgg9
 Tc8aHqZWnyzFN0KxaoEMbrtOqLHzrXh6CWN9e9KYqCinmzlTORvMOSPWDSy1n+iOkeMmZgbRuz
 rwpFtpfgWJeOj0cKcWAxWSta5bTDiM7wj74gisRiQom4M5XKTvtEh2CZwQL8Zv+uk6XW6KuWfs
 95o=
X-SBRS: 2.7
X-MesageID: 16389041
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16389041"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v11 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Date: Thu, 23 Apr 2020 16:56:09 +0200
Message-ID: <20200423145611.55378-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200423145611.55378-1-roger.pau@citrix.com>
References: <20200423145611.55378-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George
 Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Introduce a specific flag to request a HVM guest linear TLB flush,
which is an ASID/VPID tickle that forces a guest linear to guest
physical TLB flush for all HVM guests.

This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't require linear
TLB flushes as Xen doesn't modify the pages tables the guest runs on
in that case (ie: when using HAP). Note that shadow paging code
already takes care of issuing the necessary flushes when the shadow
page tables are modified.

In order to keep the previous behavior modify all shadow code TLB
flushes to also flush the guest linear to physical TLB if the guest is
HVM. I haven't looked at each specific shadow code TLB flush in order
to figure out whether it actually requires a guest TLB flush or not,
so there might be room for improvement in that regard.

Also perform ASID/VPID flushes when modifying the p2m tables as it's a
requirement for AMD hardware. Finally keep the flush in
switch_cr3_cr4, as it's not clear whether code could rely on
switch_cr3_cr4 also performing a guest linear TLB flush. A following
patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to
not be necessary.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v10:
 - Reword commit message.
 - Split flags generation in guest_flush_tlb_mask to a separate
   helper.
 - Move sh_flush_local into multi.c and make it use
   guest_flush_tlb_flags.
 - Flush ASID always when running HVM domains in shadow mode.

Changes since v9:
 - Introduce and use guest_flush_tlb_mask and sh_flush_local.
 - Add a local domain variable to p2m_pt_change_entry_type_global.

Changes since v8:
 - Don't flush host TLB on HAP changes.
 - Introduce a helper for shadow changes that only flushes ASIDs/VPIDs
   when the guest is HVM.
 - Introduce a helper for HAP that only flushes ASIDs/VPIDs.

Changes since v7:
 - Do not perform an ASID flush in filtered_flush_tlb_mask: the
   requested flush is related to the page need_tlbflush field and not
   to p2m changes (applies to both callers).

Changes since v6:
 - Add ASID/VPID flushes when modifying the p2m.
 - Keep the ASID/VPID flush in switch_cr3_cr4.

Changes since v5:
 - Rename FLUSH_GUESTS_TLB to FLUSH_HVM_ASID_CORE.
 - Clarify commit message.
 - Define FLUSH_HVM_ASID_CORE to 0 when !CONFIG_HVM.
---
 xen/arch/x86/flushtlb.c          | 23 +++++++++++++++++++++--
 xen/arch/x86/mm/hap/hap.c        |  8 ++++----
 xen/arch/x86/mm/hap/nested_hap.c |  2 +-
 xen/arch/x86/mm/p2m-pt.c         |  5 +++--
 xen/arch/x86/mm/paging.c         |  2 +-
 xen/arch/x86/mm/shadow/common.c  | 18 +++++++++---------
 xen/arch/x86/mm/shadow/hvm.c     |  2 +-
 xen/arch/x86/mm/shadow/multi.c   | 22 ++++++++++++++--------
 xen/include/asm-x86/flushtlb.h   |  9 +++++++++
 9 files changed, 63 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 03f92c23dc..0c40b5d273 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -7,6 +7,7 @@
  * Copyright (c) 2003-2006, K A Fraser
  */
 
+#include <xen/paging.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/softirq.h>
@@ -59,8 +60,6 @@ static u32 pre_flush(void)
         raise_softirq(NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ);
 
  skip_clocktick:
-    hvm_flush_guest_tlbs();
-
     return t2;
 }
 
@@ -118,6 +117,7 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
     local_irq_save(flags);
 
     t = pre_flush();
+    hvm_flush_guest_tlbs();
 
     old_cr4 = read_cr4();
     ASSERT(!(old_cr4 & X86_CR4_PCIDE) || !(old_cr4 & X86_CR4_PGE));
@@ -221,6 +221,9 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
             do_tlb_flush();
     }
 
+    if ( flags & FLUSH_HVM_ASID_CORE )
+        hvm_flush_guest_tlbs();
+
     if ( flags & FLUSH_CACHE )
     {
         const struct cpuinfo_x86 *c = &current_cpu_data;
@@ -254,3 +257,19 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
 
     return flags;
 }
+
+unsigned int guest_flush_tlb_flags(const struct domain *d)
+{
+    bool shadow = paging_mode_shadow(d);
+    bool asid = is_hvm_domain(d) && (cpu_has_svm || shadow);
+
+    return (shadow ? FLUSH_TLB : 0) | (asid ? FLUSH_HVM_ASID_CORE : 0);
+}
+
+void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
+{
+    unsigned int flags = guest_flush_tlb_flags(d);
+
+    if ( flags )
+        flush_mask(mask, flags);
+}
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 11829e7aad..580d1c2164 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
             p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
                                   p2m_ram_rw, p2m_ram_logdirty);
 
-            flush_tlb_mask(d->dirty_cpumask);
+            guest_flush_tlb_mask(d, d->dirty_cpumask);
 
             memset(dirty_bitmap, 0xff, size); /* consider all pages dirty */
         }
@@ -205,7 +205,7 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
          * to be read-only, or via hardware-assisted log-dirty.
          */
         p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     }
     return 0;
 }
@@ -234,7 +234,7 @@ static void hap_clean_dirty_bitmap(struct domain *d)
      * be read-only, or via hardware-assisted log-dirty.
      */
     p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
-    flush_tlb_mask(d->dirty_cpumask);
+    guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 /************************************************/
@@ -812,7 +812,7 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
 
     safe_write_pte(p, new);
     if ( old_flags & _PAGE_PRESENT )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     paging_unlock(d);
 
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index abe5958a52..f92ddc5206 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -84,7 +84,7 @@ nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
     safe_write_pte(p, new);
 
     if (old_flags & _PAGE_PRESENT)
-        flush_tlb_mask(p2m->dirty_cpumask);
+        guest_flush_tlb_mask(d, p2m->dirty_cpumask);
 
     paging_unlock(d);
 
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index eb66077496..5c0501794e 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -866,11 +866,12 @@ static void p2m_pt_change_entry_type_global(struct p2m_domain *p2m,
     l1_pgentry_t *tab;
     unsigned long gfn = 0;
     unsigned int i, changed;
+    const struct domain *d = p2m->domain;
 
     if ( pagetable_get_pfn(p2m_get_pagetable(p2m)) == 0 )
         return;
 
-    ASSERT(hap_enabled(p2m->domain));
+    ASSERT(hap_enabled(d));
 
     tab = map_domain_page(pagetable_get_mfn(p2m_get_pagetable(p2m)));
     for ( changed = i = 0; i < (1 << PAGETABLE_ORDER); ++i )
@@ -896,7 +897,7 @@ static void p2m_pt_change_entry_type_global(struct p2m_domain *p2m,
     unmap_domain_page(tab);
 
     if ( changed )
-         flush_tlb_mask(p2m->domain->dirty_cpumask);
+         guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 static int p2m_pt_change_entry_type_range(struct p2m_domain *p2m,
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index f5ff5d67a0..7c265fb5f3 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -613,7 +613,7 @@ void paging_log_dirty_range(struct domain *d,
 
     p2m_unlock(p2m);
 
-    flush_tlb_mask(d->dirty_cpumask);
+    guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 /*
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 3746dd6fb0..7ed8e7b71b 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -368,7 +368,7 @@ static int oos_remove_write_access(struct vcpu *v, mfn_t gmfn,
     }
 
     if ( ftlb )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     return 0;
 }
@@ -946,7 +946,7 @@ static void _shadow_prealloc(struct domain *d, unsigned int pages)
                 /* See if that freed up enough space */
                 if ( d->arch.paging.shadow.free_pages >= pages )
                 {
-                    flush_tlb_mask(d->dirty_cpumask);
+                    guest_flush_tlb_mask(d, d->dirty_cpumask);
                     return;
                 }
             }
@@ -1000,7 +1000,7 @@ static void shadow_blow_tables(struct domain *d)
                                pagetable_get_mfn(v->arch.shadow_table[i]), 0);
 
     /* Make sure everyone sees the unshadowings */
-    flush_tlb_mask(d->dirty_cpumask);
+    guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 void shadow_blow_tables_per_domain(struct domain *d)
@@ -1103,7 +1103,7 @@ mfn_t shadow_alloc(struct domain *d,
         if ( unlikely(!cpumask_empty(&mask)) )
         {
             perfc_incr(shadow_alloc_tlbflush);
-            flush_tlb_mask(&mask);
+            guest_flush_tlb_mask(d, &mask);
         }
         /* Now safe to clear the page for reuse */
         clear_domain_page(page_to_mfn(sp));
@@ -2296,7 +2296,7 @@ void sh_remove_shadows(struct domain *d, mfn_t gmfn, int fast, int all)
 
     /* Need to flush TLBs now, so that linear maps are safe next time we
      * take a fault. */
-    flush_tlb_mask(d->dirty_cpumask);
+    guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     paging_unlock(d);
 }
@@ -3013,7 +3013,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d, unsigned long gfn,
         {
             sh_remove_all_shadows_and_parents(d, mfn);
             if ( sh_remove_all_mappings(d, mfn, _gfn(gfn)) )
-                flush_tlb_mask(d->dirty_cpumask);
+                guest_flush_tlb_mask(d, d->dirty_cpumask);
         }
     }
 
@@ -3053,7 +3053,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d, unsigned long gfn,
                 }
                 omfn = mfn_add(omfn, 1);
             }
-            flush_tlb_mask(&flushmask);
+            guest_flush_tlb_mask(d, &flushmask);
 
             if ( npte )
                 unmap_domain_page(npte);
@@ -3340,7 +3340,7 @@ int shadow_track_dirty_vram(struct domain *d,
         }
     }
     if ( flush_tlb )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     goto out;
 
 out_sl1ma:
@@ -3410,7 +3410,7 @@ bool shadow_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
     }
 
     /* Flush TLBs on all CPUs with dirty vcpu state. */
-    flush_tlb_mask(mask);
+    guest_flush_tlb_mask(d, mask);
 
     /* Done. */
     for_each_vcpu ( d, v )
diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c
index 1e6024c71f..608360daec 100644
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -591,7 +591,7 @@ static void validate_guest_pt_write(struct vcpu *v, mfn_t gmfn,
 
     if ( rc & SHADOW_SET_FLUSH )
         /* Need to flush TLBs to pick up shadow PT changes */
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     if ( rc & SHADOW_SET_ERROR )
     {
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 5368adf474..7d16d1c1a9 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -85,6 +85,12 @@ const char *const fetch_type_names[] = {
 };
 #endif
 
+/* Helper to perform a local TLB flush. */
+static void sh_flush_local(const struct domain *d)
+{
+    flush_local(guest_flush_tlb_flags(d));
+}
+
 /**************************************************************************/
 /* Hash table mapping from guest pagetables to shadows
  *
@@ -3075,7 +3081,7 @@ static int sh_page_fault(struct vcpu *v,
         perfc_incr(shadow_rm_write_flush_tlb);
         smp_wmb();
         atomic_inc(&d->arch.paging.shadow.gtable_dirty_version);
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     }
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
@@ -3584,7 +3590,7 @@ static bool sh_invlpg(struct vcpu *v, unsigned long linear)
     if ( mfn_to_page(sl1mfn)->u.sh.type
          == SH_type_fl1_shadow )
     {
-        flush_tlb_local();
+        sh_flush_local(v->domain);
         return false;
     }
 
@@ -3798,7 +3804,7 @@ sh_update_linear_entries(struct vcpu *v)
      * linear pagetable to read a top-level shadow page table entry. But,
      * without this change, it would fetch the wrong value due to a stale TLB.
      */
-    flush_tlb_local();
+    sh_flush_local(d);
 }
 
 
@@ -3998,7 +4004,7 @@ sh_update_cr3(struct vcpu *v, int do_locking, bool noflush)
      * (old) shadow linear maps in the writeable mapping heuristics. */
 #if GUEST_PAGING_LEVELS == 2
     if ( sh_remove_write_access(d, gmfn, 2, 0) != 0 )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     sh_set_toplevel_shadow(v, 0, gmfn, SH_type_l2_shadow);
 #elif GUEST_PAGING_LEVELS == 3
     /* PAE guests have four shadow_table entries, based on the
@@ -4022,7 +4028,7 @@ sh_update_cr3(struct vcpu *v, int do_locking, bool noflush)
             }
         }
         if ( flush )
-            flush_tlb_mask(d->dirty_cpumask);
+            guest_flush_tlb_mask(d, d->dirty_cpumask);
         /* Now install the new shadows. */
         for ( i = 0; i < 4; i++ )
         {
@@ -4043,7 +4049,7 @@ sh_update_cr3(struct vcpu *v, int do_locking, bool noflush)
     }
 #elif GUEST_PAGING_LEVELS == 4
     if ( sh_remove_write_access(d, gmfn, 4, 0) != 0 )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     sh_set_toplevel_shadow(v, 0, gmfn, SH_type_l4_shadow);
     if ( !shadow_mode_external(d) && !is_pv_32bit_domain(d) )
     {
@@ -4494,7 +4500,7 @@ static void sh_pagetable_dying(paddr_t gpa)
         }
     }
     if ( flush )
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
 
     /* Remember that we've seen the guest use this interface, so we
      * can rely on it using it in future, instead of guessing at
@@ -4531,7 +4537,7 @@ static void sh_pagetable_dying(paddr_t gpa)
         mfn_to_page(gmfn)->pagetable_dying = true;
         shadow_unhook_mappings(d, smfn, 1/* user pages only */);
         /* Now flush the TLB: we removed toplevel mappings. */
-        flush_tlb_mask(d->dirty_cpumask);
+        guest_flush_tlb_mask(d, d->dirty_cpumask);
     }
 
     /* Remember that we've seen the guest use this interface, so we
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 2cfe4e6e97..798049b6ad 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -105,6 +105,12 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4);
 #define FLUSH_VCPU_STATE 0x1000
  /* Flush the per-cpu root page table */
 #define FLUSH_ROOT_PGTBL 0x2000
+#if CONFIG_HVM
+ /* Flush all HVM guests linear TLB (using ASID/VPID) */
+#define FLUSH_HVM_ASID_CORE 0x4000
+#else
+#define FLUSH_HVM_ASID_CORE 0
+#endif
 
 /* Flush local TLBs/caches. */
 unsigned int flush_area_local(const void *va, unsigned int flags);
@@ -159,4 +165,7 @@ static inline int clean_dcache_va_range(const void *p, unsigned long size)
     return clean_and_invalidate_dcache_va_range(p, size);
 }
 
+unsigned int guest_flush_tlb_flags(const struct domain *d);
+void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask);
+
 #endif /* __FLUSHTLB_H__ */
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 14:56:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 14:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRdHZ-0000lJ-9k; Thu, 23 Apr 2020 14:56:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Oa1P=6H=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRdHY-0000l4-H1
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 14:56:52 +0000
X-Inumbo-ID: a64b7dac-8572-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a64b7dac-8572-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 14:56:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587653806;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=6xDyV2T4eBxzsTghP88Qw+tODGijc2LN55Bf5M9CvYA=;
 b=IF31iiKzbbeu0G5uKW+KflYcFn/E+NQ1KSr/3NYqk0sKb7DEb8WbO851
 2kXMZRlIPQVvnt+6o5NfHdTUKhpZf9WP68oWbyUQMo4bSroa5GiEkv+se
 mEXzpGuJB79rex+1p70FiJTM0rSDaTXCMiSuvbXEL0ReI5xgkEx2Iud+U s=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: HLxOj7Zj+/LRqnIGjwgJD9AW8xDF/WuvKmYEfbwNNfqIyeV8+NyPVu8oKK81E/oC4V5b6TAwa4
 pLA75EFGZwohAF52zOO3vpKcldwU3K0VGg8YWw/t0xFHcgK6g99G6JkqZRroFi6erS/uy9girE
 2PyN9AhrtTH2Z5DHLKz9Y8JPYciOj8KMHlU1/GF5xK4XqdpNNLnwTkdtDKPsHpIrMZTUaO93NX
 T0p2kOMGeBzIOjPmc+iHOoNeR5GNmNmcpAmBf0zKQw/5Uw9siSqCGKhk6qUTmfKLJcxrHmRpeo
 o5k=
X-SBRS: 2.7
X-MesageID: 16153763
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16153763"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH v11 3/3] x86/tlb: use Xen L0 assisted TLB flush when available
Date: Thu, 23 Apr 2020 16:56:11 +0200
Message-ID: <20200423145611.55378-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
In-Reply-To: <20200423145611.55378-1-roger.pau@citrix.com>
References: <20200423145611.55378-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.

The following figures are from a PV guest running `make -j32 xen` in
shim mode with 32 vCPUs and HAP.

Using x2APIC and ALLBUT shorthand:
real	4m35.973s
user	4m35.110s
sys	36m24.117s

Using L0 assisted flush:
real    1m2.596s
user    4m34.818s
sys     5m16.374s

The implementation adds a new hook to hypervisor_ops so other
enlightenments can also implement such assisted flush just by filling
the hook.

Note that the Xen implementation completely ignores the dirty CPU mask
and the linear address passed in, and always performs a global TLB
flush on all vCPUs. This is a limitation of the hypercall provided by
Xen. Also note that local TLB flushes are not performed using the
assisted TLB flush, only remote ones.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Changes since v5:
 - Clarify commit message.
 - Test for assisted flush at setup, do this for all hypervisors.
 - Return EOPNOTSUPP if assisted flush is not available.

Changes since v4:
 - Adjust order calculation.

Changes since v3:
 - Use an alternative call for the flush hook.

Changes since v1:
 - Add a L0 assisted hook to hypervisor ops.
---
 xen/arch/x86/guest/hypervisor.c        | 14 ++++++++++++++
 xen/arch/x86/guest/xen/xen.c           |  6 ++++++
 xen/arch/x86/smp.c                     |  7 +++++++
 xen/include/asm-x86/guest/hypervisor.h | 17 +++++++++++++++++
 4 files changed, 44 insertions(+)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 647cdb1367..e46de42ded 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -18,6 +18,7 @@
  *
  * Copyright (c) 2019 Microsoft.
  */
+#include <xen/cpumask.h>
 #include <xen/init.h>
 #include <xen/types.h>
 
@@ -51,6 +52,10 @@ void __init hypervisor_setup(void)
 {
     if ( ops.setup )
         ops.setup();
+
+    /* Check if assisted flush is available and disable the TLB clock if so. */
+    if ( !hypervisor_flush_tlb(cpumask_of(smp_processor_id()), NULL, 0) )
+        tlb_clk_enabled = false;
 }
 
 int hypervisor_ap_setup(void)
@@ -73,6 +78,15 @@ void __init hypervisor_e820_fixup(struct e820map *e820)
         ops.e820_fixup(e820);
 }
 
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+                         unsigned int order)
+{
+    if ( ops.flush_tlb )
+        return alternative_call(ops.flush_tlb, mask, va, order);
+
+    return -EOPNOTSUPP;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index e74fd1e995..3bc01c8723 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -324,12 +324,18 @@ static void __init e820_fixup(struct e820map *e820)
         pv_shim_fixup_e820(e820);
 }
 
+static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int order)
+{
+    return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
+}
+
 static const struct hypervisor_ops __initconstrel ops = {
     .name = "Xen",
     .setup = setup,
     .ap_setup = ap_setup,
     .resume = resume,
     .e820_fixup = e820_fixup,
+    .flush_tlb = flush_tlb,
 };
 
 const struct hypervisor_ops *__init xg_probe(void)
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index bcead5d01b..1d9fec65de 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -15,6 +15,7 @@
 #include <xen/perfc.h>
 #include <xen/spinlock.h>
 #include <asm/current.h>
+#include <asm/guest.h>
 #include <asm/smp.h>
 #include <asm/mc146818rtc.h>
 #include <asm/flushtlb.h>
@@ -268,6 +269,12 @@ void flush_area_mask(const cpumask_t *mask, const void *va, unsigned int flags)
     if ( (flags & ~FLUSH_ORDER_MASK) &&
          !cpumask_subset(mask, cpumask_of(cpu)) )
     {
+        if ( cpu_has_hypervisor &&
+             !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID |
+                         FLUSH_ORDER_MASK)) &&
+             !hypervisor_flush_tlb(mask, va, (flags - 1) & FLUSH_ORDER_MASK) )
+            return;
+
         spin_lock(&flush_lock);
         cpumask_and(&flush_cpumask, mask, &cpu_online_map);
         cpumask_clear_cpu(cpu, &flush_cpumask);
diff --git a/xen/include/asm-x86/guest/hypervisor.h b/xen/include/asm-x86/guest/hypervisor.h
index ade10e74ea..77a1d21824 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -19,6 +19,8 @@
 #ifndef __X86_HYPERVISOR_H__
 #define __X86_HYPERVISOR_H__
 
+#include <xen/cpumask.h>
+
 #include <asm/e820.h>
 
 struct hypervisor_ops {
@@ -32,6 +34,8 @@ struct hypervisor_ops {
     void (*resume)(void);
     /* Fix up e820 map */
     void (*e820_fixup)(struct e820map *e820);
+    /* L0 assisted TLB flush */
+    int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int order);
 };
 
 #ifdef CONFIG_GUEST
@@ -41,6 +45,14 @@ void hypervisor_setup(void);
 int hypervisor_ap_setup(void);
 void hypervisor_resume(void);
 void hypervisor_e820_fixup(struct e820map *e820);
+/*
+ * L0 assisted TLB flush.
+ * mask: cpumask of the dirty vCPUs that should be flushed.
+ * va: linear address to flush, or NULL for global flushes.
+ * order: order of the linear address pointed by va.
+ */
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+                         unsigned int order);
 
 #else
 
@@ -52,6 +64,11 @@ static inline void hypervisor_setup(void) { ASSERT_UNREACHABLE(); }
 static inline int hypervisor_ap_setup(void) { return 0; }
 static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
 static inline void hypervisor_e820_fixup(struct e820map *e820) {}
+static inline int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+                                       unsigned int order)
+{
+    return -EOPNOTSUPP;
+}
 
 #endif  /* CONFIG_GUEST */
 
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 15:02:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 15:02:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRdMe-0001qF-VT; Thu, 23 Apr 2020 15:02:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PGxR=6H=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jRdMd-0001qA-T7
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 15:02:07 +0000
X-Inumbo-ID: 6581c2bd-8573-11ea-9393-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6581c2bd-8573-11ea-9393-12813bfff9fa;
 Thu, 23 Apr 2020 15:02:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587654127;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=+FJYamY5N8lDCyiPzDv2r4r51C2UiEmlW5dUQBTAE5w=;
 b=MaEsKG9bJYB2N33kVKBeS6geOHoAFEnErILps9KpJ3uLPWEHItAmqwOg
 hGysbQe6zCLfsL56II0R0tw8PCQWr4EXgysL6OcxJkInNhyswLBsKk1Y2
 Mwt6sBFHO95T3PxCOyxDxQQ+hriEdr1B7Xten0/Ftlb4P8Y/SFP7ZiEPR k=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: MS5ylVDP91qji9ffDWq+9i7tJ6p3RZa5C/VtyXvb9qjx+UYC4Guiu6WLULcJZEAX1zlYqMZsCq
 WoUbDSAtcZnvIFk1o2K2Uv8qxoMNUB9Z6wNHO7VRQDo83wt+bXENE9/pjT9NLeyoP7tYtQZYwm
 NajVELk7IW9336hAg2PWDpUiVEP+2kKkrBxcgiMrrL+RQvP1HHopDw4xrsv/dEiVOUpIdFmY1F
 W9YQ413J/BTPfHMymeBO82qyXmeHs5hjT/rvGnCREw43SOsRzpHDw8C2SclOQcTS7VSuZKDBL/
 wj0=
X-SBRS: 2.7
X-MesageID: 16154205
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16154205"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-ID: <24225.44521.720035.672690@mariner.uk.xensource.com>
Date: Thu, 23 Apr 2020 16:02:01 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH OSSTEST] examine/cpu: fix fetching number of threads
In-Reply-To: <20200423144303.55251-1-roger.pau@citrix.com>
References: <20200423144303.55251-1-roger.pau@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Roger Pau Monne writes ("[PATCH OSSTEST] examine/cpu: fix fetching number of threads"):
> The way to fetch the number of threads from the output of xl info is
> wrong, as the result of =~ is either true or false, but will never be a
> numeric value.
> 
> Fix the regex to have a capture group in order to fetch the number of
> threads, and store the capture in the threads variable.
> 
> Signed-off-by: Roger Pau Monn� <roger.pau@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

I will push this to pretest.  Hopefully it will go through quickly...


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 15:14:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 15:14:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRdYh-0002pN-9F; Thu, 23 Apr 2020 15:14:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wBk/=6H=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jRdYg-0002pI-MH
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 15:14:34 +0000
X-Inumbo-ID: 233797ea-8575-11ea-b4f4-bc764e2007e4
Received: from mail-wm1-x332.google.com (unknown [2a00:1450:4864:20::332])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 233797ea-8575-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 15:14:34 +0000 (UTC)
Received: by mail-wm1-x332.google.com with SMTP id x4so6827955wmj.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 08:14:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=/vzn4qBkrCeYMBtBLBRWz+edSeV8ZmrT6ebTgpxFFDI=;
 b=Un4feVeCR+NoZirip32SQFvXBuem79FECRYP3YAQqURbW78TlaBsjP7N7UbHdNWRXP
 q6bidbFizd7N+4YFZfLSTWqjQhZdWY0/5wVznnFYBCoxVSXncGfcj9tlCajyixWjk4mf
 tBY3ha+i1HVgdgFjMyu+8Acul96KHGB0D7k2KI2SUjTy0AzK75wMp+mEp46UiWkCsbW2
 SYIUZqxxJTWBX0vuWS98XA5ZGtWSnMmAOGf3yhQOycQmqGOQ/eIuyMiqwRU4KQcqW43k
 FQacLpem21UPuh7Xh6AdnY/utU3vPrFTRM/IQG6T7YiwC9Q7CM/JtQ9BdOXrRNQh76x+
 NAkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :thread-index:content-language;
 bh=/vzn4qBkrCeYMBtBLBRWz+edSeV8ZmrT6ebTgpxFFDI=;
 b=Hj/wezFmz/WYf6F/dgw4UrV7elb8helllFkg/6OQ1yTeE95lEZiDVPtcKCrpzSlflN
 tmGkOKSWEekKCVmtCL1EDPTr6YMuzMZyUPdkgrrrzAmA4cd8PPRjvH/bhqGK0AiK9VoX
 LNuPkqVhVUu+6foYJ5i8TOpknCJiwNJJUhkU/uzSIq463xH+VzDqIrVY/fHnq26reBiY
 UiKTNnsv5WMG4vxKWNhhaZwtFozcYa7wQQnWotuCYYm6nMnZgjjuoVDw7LimFHuegzeu
 Q+yoJ4tv9WOO16/utOIbVEoI3Uc8t7B7vcJgrZos8GDOYcGqXuJbb0mUX7dhux2uapIw
 PByQ==
X-Gm-Message-State: AGi0PuZ+4D0jYxDzpSn5FSTrCkHMpvBmUgIKOT80E5ChJhnN6LkQdt2z
 TTMWZxn/x8qwOosJ1XDRZuE=
X-Google-Smtp-Source: APiQypLjSDU2vuk4FX4IjUlqt4BM/LaxsI+w2MQN2eg6d9HPyGYv/cYOD+UZH5cXz33abQoJnJrQ/A==
X-Received: by 2002:a1c:9cc6:: with SMTP id f189mr4567477wme.75.1587654873341; 
 Thu, 23 Apr 2020 08:14:33 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.177])
 by smtp.gmail.com with ESMTPSA id 5sm4010660wmg.34.2020.04.23.08.14.31
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 23 Apr 2020 08:14:32 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>,
	"'Varad Gautam'" <vrd@amazon.de>
References: <20200306160254.8465-1-paul@xen.org>
 <58f00871-2fff-be69-299e-e2b9911e0723@suse.com>
 <000301d5f63a$df5f04a0$9e1d0de0$@xen.org>
 <0648e7ac-f5d7-4207-e2c6-8418681cca13@suse.com>
 <004201d5fc70$128cc610$37a65230$@xen.org>
 <8590eadc-b561-ba7c-c474-141102ec76bd@suse.com>
 <005f01d60752$aa090980$fe1b1c80$@xen.org>
 <ca063a1c-d328-153c-ae9f-b91d496dfaa9@suse.com>
In-Reply-To: <ca063a1c-d328-153c-ae9f-b91d496dfaa9@suse.com>
Subject: RE: [PATCH v4] x86: irq: Do not BUG_ON multiple unbind calls for
 shared pirqs
Date: Thu, 23 Apr 2020 16:14:31 +0100
Message-ID: <000a01d61981$e45d1770$ad174650$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIK2yJyYyCu4hvzDwRQ39T9TXjhmgIXPdL9AaPqNSQCpdNRqAIEmAPBAG+DHygCIj90sAJjlYbfp7J18FA=
Content-Language: en-gb
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: xen-devel@lists.xenproject.org, 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Julien Grall' <julien@xen.org>,
 =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 23 April 2020 12:09
> To: paul@xen.org; 'Varad Gautam' <vrd@amazon.de>
> Cc: xen-devel@lists.xenproject.org; 'Julien Grall' <julien@xen.org>; =
'Roger Pau Monn=C3=A9'
> <roger.pau@citrix.com>; 'Andrew Cooper' <andrew.cooper3@citrix.com>
> Subject: Re: [PATCH v4] x86: irq: Do not BUG_ON multiple unbind calls =
for shared pirqs
>=20
> On 31.03.2020 13:51, Paul Durrant wrote:
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: 31 March 2020 08:41
> >>
> >> On 17.03.2020 16:23, Paul Durrant wrote:
> >>> That looks like it will do the job. I'll see if I can get it =
tested.
> >>
> >> Any luck with this, yet?
> >
> > I have asked Varad to test it. He hopes to get to it this week.
>=20
> Any news here?
>=20

Varad tells me he is currently testing and will get back to you soon =
(hopefully today).

  Paul



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 15:30:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 15:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRdoI-0004S6-2E; Thu, 23 Apr 2020 15:30:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1pl3=6H=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jRdoH-0004S1-6K
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 15:30:41 +0000
X-Inumbo-ID: 60e2e688-8577-11ea-9397-12813bfff9fa
Received: from mga07.intel.com (unknown [134.134.136.100])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 60e2e688-8577-11ea-9397-12813bfff9fa;
 Thu, 23 Apr 2020 15:30:36 +0000 (UTC)
IronPort-SDR: thVHl0rU4oq6KqfPI82EDOkjfvuMrvzJ2F4sJfmmDdSh2Eal2E/YsGbPEYLlvOfOVNXsbchp+i
 T6ltV9wCiuhQ==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga008.jf.intel.com ([10.7.209.65])
 by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 23 Apr 2020 08:30:32 -0700
IronPort-SDR: VaEzCt1RlOv/81qEhNBDDtSOjv12dfkTZWXQ5fT0M/x159v5n3hd2+ZalBenx6NV4elADxA6L9
 MhUhRUJ09Ocg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.73,307,1583222400"; d="scan'208";a="292311799"
Received: from nsheikh-mobl1.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.208.245])
 by orsmga008.jf.intel.com with ESMTP; 23 Apr 2020 08:30:31 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v17 2/2] xen/tools: VM forking toolstack side
Date: Thu, 23 Apr 2020 08:30:07 -0700
Message-Id: <e416eac0c986fd1aba5f576d9b065a6f47660b2c.1587655725.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
References: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
 docs/man/xl.1.pod.in          |  49 +++++
 tools/libxc/include/xenctrl.h |  14 ++
 tools/libxc/xc_memshr.c       |  26 +++
 tools/libxl/libxl.h           |  12 ++
 tools/libxl/libxl_create.c    | 361 +++++++++++++++++++---------------
 tools/libxl/libxl_dm.c        |   2 +-
 tools/libxl/libxl_dom.c       |  43 +++-
 tools/libxl/libxl_internal.h  |   7 +
 tools/libxl/libxl_types.idl   |   1 +
 tools/libxl/libxl_x86.c       |  42 ++++
 tools/xl/Makefile             |   2 +-
 tools/xl/xl.h                 |   5 +
 tools/xl/xl_cmdtable.c        |  15 ++
 tools/xl/xl_forkvm.c          | 149 ++++++++++++++
 tools/xl/xl_vmcontrol.c       |  14 ++
 15 files changed, 576 insertions(+), 166 deletions(-)
 create mode 100644 tools/xl/xl_forkvm.c

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 09339282e6..67b4e8588a 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -708,6 +708,55 @@ above).
 
 =back
 
+=item B<fork-vm> [I<OPTIONS>] I<domain-id>
+
+Create a fork of a running VM.  The domain will be paused after the operation
+and remains paused while forks of it exist.  Experimental and x86 only.
+Forks can only be made of domains with HAP enabled and on Intel hardware.  The
+parent domain must be created with the xl toolstack and its configuration must
+not manually define max_grant_frames, max_maptrack_frames or max_event_channels.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-p>
+
+Leave the fork paused after creating it.
+
+=item B<--launch-dm>
+
+Specify whether the device model (QEMU) should be launched for the fork. Late
+launch allows to start the device model for an already running fork.
+
+=item B<-C>
+
+The config file to use when launching the device model.  Currently required when
+launching the device model.  Most config settings MUST match the parent domain
+exactly, only change VM name, disk path and network configurations.
+
+=item B<-Q>
+
+The path to the qemu save file to use when launching the device model.  Currently
+required when launching the device model.
+
+=item B<--fork-reset>
+
+Perform a reset operation of an already running fork.  Note that resetting may
+be less performant then creating a new fork depending on how much memory the
+fork has deduplicated during its runtime.
+
+=item B<--max-vcpus>
+
+Specify the max-vcpus matching the parent domain when not launching the dm.
+
+=item B<--allow-iommu>
+
+Specify to allow forking a domain that has IOMMU enabled. Only compatible with
+forks using --launch-dm no.
+
+=back
+
 =item B<sharing> [I<domain-id>]
 
 Display the number of shared pages for a specified domain. If no domain is
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 5f25c5a6d4..0a6ff93229 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2232,6 +2232,20 @@ int xc_memshr_range_share(xc_interface *xch,
                           uint64_t first_gfn,
                           uint64_t last_gfn);
 
+int xc_memshr_fork(xc_interface *xch,
+                   uint32_t source_domain,
+                   uint32_t client_domain,
+                   bool allow_with_iommu);
+
+/*
+ * Note: this function is only intended to be used on short-lived forks that
+ * haven't yet aquired a lot of memory. In case the fork has a lot of memory
+ * it is likely more performant to create a new fork with xc_memshr_fork.
+ *
+ * With VMs that have a lot of memory this call may block for a long time.
+ */
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain);
+
 /* Debug calls: return the number of pages referencing the shared frame backing
  * the input argument. Should be one or greater.
  *
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index 97e2e6a8d9..2300cc7075 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -239,6 +239,32 @@ int xc_memshr_debug_gref(xc_interface *xch,
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid,
+                   bool allow_with_iommu)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_fork;
+    mso.u.fork.parent_domain = pdomid;
+
+    if ( allow_with_iommu )
+        mso.u.fork.flags |= XENMEM_FORK_WITH_IOMMU_ALLOWED;
+
+    return xc_memshr_memop(xch, domid, &mso);
+}
+
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+    mso.op = XENMEM_sharing_op_fork_reset;
+
+    return xc_memshr_memop(xch, domid, &mso);
+}
+
 int xc_memshr_audit(xc_interface *xch)
 {
     xen_mem_sharing_op_t mso;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 71709dc585..4bbb0a773d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2666,6 +2666,18 @@ int libxl_psr_get_hw_info(libxl_ctx *ctx, libxl_psr_feat_type type,
                           unsigned int lvl, unsigned int *nr,
                           libxl_psr_hw_info **info);
 void libxl_psr_hw_info_list_free(libxl_psr_hw_info *list, unsigned int nr);
+
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus,
+                         bool allow_with_iommu, uint32_t *domid)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                uint32_t domid,
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 #endif
 
 /* misc */
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e7cb2dbc2b..11001d19dc 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -538,12 +538,12 @@ out:
     return ret;
 }
 
-int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
-                       libxl__domain_build_state *state,
-                       uint32_t *domid, bool soft_reset)
+static int libxl__domain_make_xs_entries(libxl__gc *gc, libxl_domain_config *d_config,
+                                         libxl__domain_build_state *state,
+                                         uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, rc, nb_vm;
+    int rc, nb_vm;
     const char *dom_type;
     char *uuid_string;
     char *dom_path, *vm_path, *libxl_path;
@@ -555,9 +555,6 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     /* convenience aliases */
     libxl_domain_create_info *info = &d_config->c_info;
-    libxl_domain_build_info *b_info = &d_config->b_info;
-
-    assert(soft_reset || *domid == INVALID_DOMID);
 
     uuid_string = libxl__uuid2string(gc, info->uuid);
     if (!uuid_string) {
@@ -565,137 +562,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         goto out;
     }
 
-    if (!soft_reset) {
-        struct xen_domctl_createdomain create = {
-            .ssidref = info->ssidref,
-            .max_vcpus = b_info->max_vcpus,
-            .max_evtchn_port = b_info->event_channels,
-            .max_grant_frames = b_info->max_grant_frames,
-            .max_maptrack_frames = b_info->max_maptrack_frames,
-        };
-
-        if (info->type != LIBXL_DOMAIN_TYPE_PV) {
-            create.flags |= XEN_DOMCTL_CDF_hvm;
-            create.flags |=
-                libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
-            create.flags |=
-                libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
-        }
-
-        assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
-        LOG(DETAIL, "passthrough: %s",
-            libxl_passthrough_to_string(info->passthrough));
-
-        if (info->passthrough != LIBXL_PASSTHROUGH_DISABLED)
-            create.flags |= XEN_DOMCTL_CDF_iommu;
-
-        if (info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT)
-            create.iommu_opts |= XEN_DOMCTL_IOMMU_no_sharept;
-
-        /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
-        libxl_uuid_copy(ctx, (libxl_uuid *)&create.handle, &info->uuid);
-
-        ret = libxl__arch_domain_prepare_config(gc, d_config, &create);
-        if (ret < 0) {
-            LOGED(ERROR, *domid, "fail to get domain config");
-            rc = ERROR_FAIL;
-            goto out;
-        }
-
-        for (;;) {
-            uint32_t local_domid;
-            bool recent;
-
-            if (info->domid == RANDOM_DOMID) {
-                uint16_t v;
-
-                ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
-                if (ret < 0)
-                    break;
-
-                v &= DOMID_MASK;
-                if (!libxl_domid_valid_guest(v))
-                    continue;
-
-                local_domid = v;
-            } else {
-                local_domid = info->domid; /* May not be valid */
-            }
-
-            ret = xc_domain_create(ctx->xch, &local_domid, &create);
-            if (ret < 0) {
-                /*
-                 * If we generated a random domid and creation failed
-                 * because that domid already exists then simply try
-                 * again.
-                 */
-                if (errno == EEXIST && info->domid == RANDOM_DOMID)
-                    continue;
-
-                LOGED(ERROR, local_domid, "domain creation fail");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /* A new domain now exists */
-            *domid = local_domid;
-
-            rc = libxl__is_domid_recent(gc, local_domid, &recent);
-            if (rc)
-                goto out;
-
-            /* The domid is not recent, so we're done */
-            if (!recent)
-                break;
-
-            /*
-             * If the domid was specified then there's no point in
-             * trying again.
-             */
-            if (libxl_domid_valid_guest(info->domid)) {
-                LOGED(ERROR, local_domid, "domain id recently used");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /*
-             * The domain is recent and so cannot be used. Clear domid
-             * here since, if xc_domain_destroy() fails below there is
-             * little point calling it again in the error path.
-             */
-            *domid = INVALID_DOMID;
-
-            ret = xc_domain_destroy(ctx->xch, local_domid);
-            if (ret < 0) {
-                LOGED(ERROR, local_domid, "domain destroy fail");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-
-            /* The domain was successfully destroyed, so we can try again */
-        }
-
-        rc = libxl__arch_domain_save_config(gc, d_config, state, &create);
-        if (rc < 0)
-            goto out;
-    }
-
-    /*
-     * If soft_reset is set the the domid will have been valid on entry.
-     * If it was not set then xc_domain_create() should have assigned a
-     * valid value. Either way, if we reach this point, domid should be
-     * valid.
-     */
-    assert(libxl_domid_valid_guest(*domid));
-
-    ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
-    if (ret < 0) {
-        LOGED(ERROR, *domid, "domain move fail");
-        rc = ERROR_FAIL;
-        goto out;
-    }
-
-    dom_path = libxl__xs_get_dompath(gc, *domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         rc = ERROR_FAIL;
         goto out;
@@ -703,12 +570,12 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     vm_path = GCSPRINTF("/vm/%s", uuid_string);
     if (!vm_path) {
-        LOGD(ERROR, *domid, "cannot allocate create paths");
+        LOGD(ERROR, domid, "cannot allocate create paths");
         rc = ERROR_FAIL;
         goto out;
     }
 
-    libxl_path = libxl__xs_libxl_path(gc, *domid);
+    libxl_path = libxl__xs_libxl_path(gc, domid);
     if (!libxl_path) {
         rc = ERROR_FAIL;
         goto out;
@@ -719,10 +586,10 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
 
     roperm[0].id = 0;
     roperm[0].perms = XS_PERM_NONE;
-    roperm[1].id = *domid;
+    roperm[1].id = domid;
     roperm[1].perms = XS_PERM_READ;
 
-    rwperm[0].id = *domid;
+    rwperm[0].id = domid;
     rwperm[0].perms = XS_PERM_NONE;
 
 retry_transaction:
@@ -740,7 +607,7 @@ retry_transaction:
                     noperm, ARRAY_SIZE(noperm));
 
     xs_write(ctx->xsh, t, GCSPRINTF("%s/vm", dom_path), vm_path, strlen(vm_path));
-    rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
+    rc = libxl__domain_rename(gc, domid, 0, info->name, t);
     if (rc)
         goto out;
 
@@ -830,7 +697,7 @@ retry_transaction:
 
     vm_list = libxl_list_vm(ctx, &nb_vm);
     if (!vm_list) {
-        LOGD(ERROR, *domid, "cannot get number of running guests");
+        LOGD(ERROR, domid, "cannot get number of running guests");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -854,7 +721,7 @@ retry_transaction:
             t = 0;
             goto retry_transaction;
         }
-        LOGED(ERROR, *domid, "domain creation ""xenstore transaction commit failed");
+        LOGED(ERROR, domid, "domain creation ""xenstore transaction commit failed");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -866,6 +733,155 @@ retry_transaction:
     return rc;
 }
 
+int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
+                       libxl__domain_build_state *state,
+                       uint32_t *domid, bool soft_reset)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret, rc;
+
+    /* convenience aliases */
+    libxl_domain_create_info *info = &d_config->c_info;
+    libxl_domain_build_info *b_info = &d_config->b_info;
+
+    assert(soft_reset || *domid == INVALID_DOMID);
+
+    if (!soft_reset) {
+        struct xen_domctl_createdomain create = {
+            .ssidref = info->ssidref,
+            .max_vcpus = b_info->max_vcpus,
+            .max_evtchn_port = b_info->event_channels,
+            .max_grant_frames = b_info->max_grant_frames,
+            .max_maptrack_frames = b_info->max_maptrack_frames,
+        };
+
+        if (info->type != LIBXL_DOMAIN_TYPE_PV) {
+            create.flags |= XEN_DOMCTL_CDF_hvm;
+            create.flags |=
+                libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+            create.flags |=
+                libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
+        }
+
+        assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
+        LOG(DETAIL, "passthrough: %s",
+            libxl_passthrough_to_string(info->passthrough));
+
+        if (info->passthrough != LIBXL_PASSTHROUGH_DISABLED)
+            create.flags |= XEN_DOMCTL_CDF_iommu;
+
+        if (info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT)
+            create.iommu_opts |= XEN_DOMCTL_IOMMU_no_sharept;
+
+        /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
+        libxl_uuid_copy(ctx, (libxl_uuid *)&create.handle, &info->uuid);
+
+        ret = libxl__arch_domain_prepare_config(gc, d_config, &create);
+        if (ret < 0) {
+            LOGED(ERROR, *domid, "fail to get domain config");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        for (;;) {
+            uint32_t local_domid;
+            bool recent;
+
+            if (info->domid == RANDOM_DOMID) {
+                uint16_t v;
+
+                ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
+                if (ret < 0)
+                    break;
+
+                v &= DOMID_MASK;
+                if (!libxl_domid_valid_guest(v))
+                    continue;
+
+                local_domid = v;
+            } else {
+                local_domid = info->domid; /* May not be valid */
+            }
+
+            ret = xc_domain_create(ctx->xch, &local_domid, &create);
+            if (ret < 0) {
+                /*
+                 * If we generated a random domid and creation failed
+                 * because that domid already exists then simply try
+                 * again.
+                 */
+                if (errno == EEXIST && info->domid == RANDOM_DOMID)
+                    continue;
+
+                LOGED(ERROR, local_domid, "domain creation fail");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* A new domain now exists */
+            *domid = local_domid;
+
+            rc = libxl__is_domid_recent(gc, local_domid, &recent);
+            if (rc)
+                goto out;
+
+            /* The domid is not recent, so we're done */
+            if (!recent)
+                break;
+
+            /*
+             * If the domid was specified then there's no point in
+             * trying again.
+             */
+            if (libxl_domid_valid_guest(info->domid)) {
+                LOGED(ERROR, local_domid, "domain id recently used");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /*
+             * The domain is recent and so cannot be used. Clear domid
+             * here since, if xc_domain_destroy() fails below there is
+             * little point calling it again in the error path.
+             */
+            *domid = INVALID_DOMID;
+
+            ret = xc_domain_destroy(ctx->xch, local_domid);
+            if (ret < 0) {
+                LOGED(ERROR, local_domid, "domain destroy fail");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* The domain was successfully destroyed, so we can try again */
+        }
+
+        rc = libxl__arch_domain_save_config(gc, d_config, state, &create);
+        if (rc < 0)
+            goto out;
+    }
+
+    /*
+     * If soft_reset is set the the domid will have been valid on entry.
+     * If it was not set then xc_domain_create() should have assigned a
+     * valid value. Either way, if we reach this point, domid should be
+     * valid.
+     */
+    assert(libxl_domid_valid_guest(*domid));
+
+    ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
+    if (ret < 0) {
+        LOGED(ERROR, *domid, "domain move fail");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl__domain_make_xs_entries(gc, d_config, state, *domid);
+
+out:
+    return rc;
+}
+
 static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
                              libxl_domain_build_info *b_info)
 {
@@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
     ret = libxl__domain_config_setdefault(gc,d_config,domid);
     if (ret) goto error_out;
 
-    ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
-                             dcs->soft_reset);
-    if (ret) {
-        LOGD(ERROR, domid, "cannot make domain: %d", ret);
+    if (!d_config->dm_restore_file)
+    {
+        ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
+                                 dcs->soft_reset);
         dcs->guest_domid = domid;
+
+        if (ret) {
+            LOGD(ERROR, domid, "cannot make domain: %d", ret);
+            ret = ERROR_FAIL;
+            goto error_out;
+        }
+    } else if (dcs->guest_domid != INVALID_DOMID) {
+        domid = dcs->guest_domid;
+
+        ret = libxl__domain_make_xs_entries(gc, d_config, &dcs->build_state, domid);
+        if (ret) {
+            LOGD(ERROR, domid, "cannot make domain: %d", ret);
+            ret = ERROR_FAIL;
+            goto error_out;
+        }
+    } else {
+        LOGD(ERROR, domid, "cannot make domain");
         ret = ERROR_FAIL;
         goto error_out;
     }
 
-    dcs->guest_domid = domid;
     dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
 
     /* post-4.13 todo: move these next bits of defaulting to
@@ -1236,7 +1268,7 @@ static void initiate_domain_create(libxl__egc *egc,
     if (ret)
         goto error_out;
 
-    if (restore_fd >= 0 || dcs->soft_reset) {
+    if (restore_fd >= 0 || dcs->soft_reset || d_config->dm_restore_file) {
         LOGD(DEBUG, domid, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
     } else  {
@@ -1312,7 +1344,16 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->sdss.dm.callback = domcreate_devmodel_started;
     dcs->sdss.callback = domcreate_devmodel_started;
 
-    if (restore_fd < 0 && !dcs->soft_reset) {
+    if (restore_fd < 0 && !dcs->soft_reset && !d_config->dm_restore_file) {
+        rc = libxl__domain_build(gc, d_config, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    if (d_config->dm_restore_file) {
+        dcs->srs.dcs = dcs;
+        dcs->srs.ao = ao;
+        state->forked_vm = true;
         rc = libxl__domain_build(gc, d_config, domid, state);
         domcreate_rebuild_done(egc, dcs, rc);
         return;
@@ -1510,6 +1551,7 @@ static void domcreate_rebuild_done(libxl__egc *egc,
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
 
     if (ret) {
         LOGD(ERROR, domid, "cannot (re-)build domain: %d", ret);
@@ -1517,6 +1559,9 @@ static void domcreate_rebuild_done(libxl__egc *egc,
         goto error_out;
     }
 
+    if (d_config->dm_restore_file)
+        state->saved_state = GCSPRINTF("%s", d_config->dm_restore_file);
+
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     libxl__multidev_begin(ao, &dcs->multidev);
@@ -1947,7 +1992,7 @@ static void domain_create_cb(libxl__egc *egc,
                              libxl__domain_create_state *dcs,
                              int rc, uint32_t domid);
 
-static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+int libxl__do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid, int restore_fd, int send_back_fd,
                             const libxl_domain_restore_params *params,
                             const libxl_asyncop_how *ao_how,
@@ -1960,6 +2005,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     GCNEW(cdcs);
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.guest_domid = *domid;
+
     libxl_domain_config_init(&cdcs->dcs.guest_config_saved);
     libxl_domain_config_copy(ctx, &cdcs->dcs.guest_config_saved, d_config);
     cdcs->dcs.restore_fd = cdcs->dcs.libxc_fd = restore_fd;
@@ -2204,8 +2251,8 @@ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             const libxl_asyncprogress_how *aop_console_how)
 {
     unset_disk_colo_restore(d_config);
-    return do_domain_create(ctx, d_config, domid, -1, -1, NULL,
-                            ao_how, aop_console_how);
+    return libxl__do_domain_create(ctx, d_config, domid, -1, -1, NULL,
+                                  ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
@@ -2221,8 +2268,8 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
         unset_disk_colo_restore(d_config);
     }
 
-    return do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
-                            params, ao_how, aop_console_how);
+    return libxl__do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
+                                   params, ao_how, aop_console_how);
 }
 
 int libxl_domain_soft_reset(libxl_ctx *ctx,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index f4007bbe50..b615f1fc88 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2803,7 +2803,7 @@ static void device_model_spawn_outcome(libxl__egc *egc,
 
     libxl__domain_build_state *state = dmss->build_state;
 
-    if (state->saved_state) {
+    if (state->saved_state && !state->forked_vm) {
         ret2 = unlink(state->saved_state);
         if (ret2) {
             LOGED(ERROR, dmss->guest_domid, "%s: failed to remove device-model state %s",
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 71cb578923..9e47162f67 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -249,9 +249,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *xs_domid, *con_domid;
-    int rc;
+    int rc = 0;
     uint64_t size;
 
+    if (state->forked_vm)
+        goto skip_fork;
+
     if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) {
         LOG(ERROR, "Couldn't set max vcpu count");
         return ERROR_FAIL;
@@ -362,7 +365,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         }
     }
 
-
     rc = libxl__arch_extra_memory(gc, info, &size);
     if (rc < 0) {
         LOGE(ERROR, "Couldn't get arch extra constant memory size");
@@ -374,6 +376,11 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         return ERROR_FAIL;
     }
 
+    rc = libxl__arch_domain_create(gc, d_config, domid);
+    if (rc)
+        goto out;
+
+skip_fork:
     xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
     state->store_domid = xs_domid ? atoi(xs_domid) : 0;
     free(xs_domid);
@@ -385,8 +392,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
 
-    rc = libxl__arch_domain_create(gc, d_config, domid);
-
+out:
     return rc;
 }
 
@@ -444,6 +450,9 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char **ents;
     int i, rc;
 
+    if (state->forked_vm)
+        goto skip_fork;
+
     if (info->num_vnuma_nodes && !info->num_vcpu_soft_affinity) {
         rc = set_vnuma_affinity(gc, domid, info);
         if (rc)
@@ -466,6 +475,7 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
         }
     }
 
+skip_fork:
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
@@ -728,14 +738,16 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
                                 int console_evtchn, unsigned long *console_mfn,
-                                domid_t store_domid, domid_t console_domid)
+                                domid_t store_domid, domid_t console_domid,
+                                bool forked_vm)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
     uint64_t str_mfn, cons_mfn;
     int i;
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM && !forked_vm)
+    {
         va_map = xc_map_foreign_range(handle, domid,
                                       XC_PAGE_SIZE, PROT_READ | PROT_WRITE,
                                       HVM_INFO_PFN);
@@ -1051,6 +1063,23 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
     struct xc_dom_image *dom = NULL;
     bool device_model = info->type == LIBXL_DOMAIN_TYPE_HVM ? true : false;
 
+    if (state->forked_vm)
+    {
+        rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
+                                  &state->store_mfn, state->console_port,
+                                  &state->console_mfn, state->store_domid,
+                                  state->console_domid, state->forked_vm);
+
+        if ( rc )
+            return rc;
+
+        return xc_dom_gnttab_seed(ctx->xch, domid, true,
+                                  state->console_mfn,
+                                  state->store_mfn,
+                                  state->console_domid,
+                                  state->store_domid);
+    }
+
     xc_dom_loginit(ctx->xch);
 
     /*
@@ -1175,7 +1204,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
     rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
                                &state->store_mfn, state->console_port,
                                &state->console_mfn, state->store_domid,
-                               state->console_domid);
+                               state->console_domid, false);
     if (rc != 0) {
         LOG(ERROR, "hvm build set params failed");
         goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5f39e44cb9..d05ff31e83 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1374,6 +1374,7 @@ typedef struct {
 
     char *saved_state;
     int dm_monitor_fd;
+    bool forked_vm;
 
     libxl__file_reference pv_kernel;
     libxl__file_reference pv_ramdisk;
@@ -4818,6 +4819,12 @@ _hidden int libxl__domain_pvcontrol(libxl__egc *egc,
 /* Check whether a domid is recent */
 int libxl__is_domid_recent(libxl__gc *gc, uint32_t domid, bool *recent);
 
+_hidden int libxl__do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                    uint32_t *domid, int restore_fd, int send_back_fd,
+                                    const libxl_domain_restore_params *params,
+                                    const libxl_asyncop_how *ao_how,
+                                    const libxl_asyncprogress_how *aop_console_how);
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7c473be74..2bb5e6319e 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -958,6 +958,7 @@ libxl_domain_config = Struct("domain_config", [
     ("on_watchdog", libxl_action_on_shutdown),
     ("on_crash", libxl_action_on_shutdown),
     ("on_soft_reset", libxl_action_on_shutdown),
+    ("dm_restore_file", string, {'const': True}),
     ], dir=DIR_IN)
 
 libxl_diskinfo = Struct("diskinfo", [
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index f8bc828e62..f6d7daa8fe 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -2,6 +2,7 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
+#include <xen-xsm/flask/flask.h>
 
 int libxl__arch_domain_prepare_config(libxl__gc *gc,
                                       libxl_domain_config *d_config,
@@ -842,6 +843,47 @@ int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
     return rc;
 }
 
+/*
+ * The parent domain is expected to be created with default settings for
+ * - max_evtch_port
+ * - max_grant_frames
+ * - max_maptrack_frames
+ */
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus,
+                         bool allow_with_iommu, uint32_t *domid)
+{
+    int rc;
+    struct xen_domctl_createdomain create = {0};
+    create.flags |= XEN_DOMCTL_CDF_hvm;
+    create.flags |= XEN_DOMCTL_CDF_hap;
+    create.flags |= XEN_DOMCTL_CDF_oos_off;
+    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
+    create.ssidref = SECINITSID_DOMU;
+    create.max_vcpus = max_vcpus;
+    create.max_evtchn_port = 1023;
+    create.max_grant_frames = LIBXL_MAX_GRANT_FRAMES_DEFAULT;
+    create.max_maptrack_frames = LIBXL_MAX_MAPTRACK_FRAMES_DEFAULT;
+
+    if ( (rc = xc_domain_create(ctx->xch, domid, &create)) )
+        return rc;
+
+    if ( (rc = xc_memshr_fork(ctx->xch, pdomid, *domid, allow_with_iommu)) )
+        xc_domain_destroy(ctx->xch, *domid);
+
+    return rc;
+}
+
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                uint32_t domid,
+                                const libxl_asyncprogress_how *aop_console_how)
+{
+    return libxl__do_domain_create(ctx, d_config, &domid, -1, -1, 0, 0, aop_console_how);
+}
+
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid)
+{
+    return xc_memshr_fork_reset(ctx->xch, domid);
+}
 
 /*
  * Local variables:
diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index af4912e67a..073222233b 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -15,7 +15,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
 CFLAGS_XL += $(CFLAGS_libxenlight)
 CFLAGS_XL += -Wshadow
 
-XL_OBJS-$(CONFIG_X86) = xl_psr.o
+XL_OBJS-$(CONFIG_X86) = xl_psr.o xl_forkvm.o
 XL_OBJS = xl.o xl_cmdtable.o xl_sxp.o xl_utils.o $(XL_OBJS-y)
 XL_OBJS += xl_parse.o xl_cpupool.o xl_flask.o
 XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 06569c6c4a..1105c34b15 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -31,6 +31,7 @@ struct cmd_spec {
 };
 
 struct domain_create {
+    uint32_t ddomid; /* fork launch dm for this domid */
     int debug;
     int daemonize;
     int monitor; /* handle guest reboots etc */
@@ -45,6 +46,7 @@ struct domain_create {
     const char *config_file;
     char *extra_config; /* extra config string */
     const char *restore_file;
+    const char *dm_restore_file;
     char *colo_proxy_script;
     bool userspace_colo_proxy;
     int migrate_fd; /* -1 means none */
@@ -128,6 +130,8 @@ int main_pciassignable_remove(int argc, char **argv);
 int main_pciassignable_list(int argc, char **argv);
 #ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
 int main_restore(int argc, char **argv);
+int main_fork_launch_dm(int argc, char **argv);
+int main_fork_reset(int argc, char **argv);
 int main_migrate_receive(int argc, char **argv);
 int main_save(int argc, char **argv);
 int main_migrate(int argc, char **argv);
@@ -212,6 +216,7 @@ int main_psr_cat_cbm_set(int argc, char **argv);
 int main_psr_cat_show(int argc, char **argv);
 int main_psr_mba_set(int argc, char **argv);
 int main_psr_mba_show(int argc, char **argv);
+int main_fork_vm(int argc, char **argv);
 #endif
 int main_qemu_monitor_command(int argc, char **argv);
 
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 08335394e5..ef634abf32 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -187,6 +187,21 @@ struct cmd_spec cmd_table[] = {
       "Restore a domain from a saved state",
       "- for internal use only",
     },
+#if defined(__i386__) || defined(__x86_64__)
+    { "fork-vm",
+      &main_fork_vm, 0, 1,
+      "Fork a domain from the running parent domid. Experimental. Most config settings must match parent.",
+      "[options] <Domid>",
+      "-h                           Print this help.\n"
+      "-C <config>                  Use config file for VM fork.\n"
+      "-Q <qemu-save-file>          Use qemu save file for VM fork.\n"
+      "--launch-dm <yes|no|late>    Launch device model (QEMU) for VM fork.\n"
+      "--fork-reset                 Reset VM fork.\n"
+      "--max-vcpus                  Specify max-vcpus matching the parent domain when not launching dm\n"
+      "-p                           Do not unpause fork VM after operation.\n"
+      "-d                           Enable debug messages.\n"
+    },
+#endif
 #endif
     { "dump-core",
       &main_dump_core, 0, 1,
diff --git a/tools/xl/xl_forkvm.c b/tools/xl/xl_forkvm.c
new file mode 100644
index 0000000000..46805b84f3
--- /dev/null
+++ b/tools/xl/xl_forkvm.c
@@ -0,0 +1,149 @@
+/*
+ * Copyright 2020 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <sys/utsname.h>
+#include <time.h>
+#include <unistd.h>
+
+#include <libxl.h>
+#include <libxl_utils.h>
+#include <libxlutil.h>
+
+#include "xl.h"
+#include "xl_utils.h"
+#include "xl_parse.h"
+
+int main_fork_vm(int argc, char **argv)
+{
+    int rc, debug = 0;
+    uint32_t domid_in = INVALID_DOMID, domid_out = INVALID_DOMID;
+    int launch_dm = 1;
+    bool reset = 0;
+    bool pause = 0;
+    bool allow_iommu = 0;
+    const char *config_file = NULL;
+    const char *dm_restore_file = NULL;
+    uint32_t max_vcpus = 0;
+
+    int opt;
+    static struct option opts[] = {
+        {"launch-dm", 1, 0, 'l'},
+        {"fork-reset", 0, 0, 'r'},
+        {"max-vcpus", 1, 0, 'm'},
+        {"allow-iommu", 1, 0, 'i'},
+        COMMON_LONG_OPTS
+    };
+
+    SWITCH_FOREACH_OPT(opt, "phdC:Q:l:rm:i", opts, "fork-vm", 1) {
+    case 'd':
+        debug = 1;
+        break;
+    case 'p':
+        pause = 1;
+        break;
+    case 'm':
+        max_vcpus = atoi(optarg);
+        break;
+    case 'C':
+        config_file = optarg;
+        break;
+    case 'Q':
+        dm_restore_file = optarg;
+        break;
+    case 'l':
+        if ( !strcmp(optarg, "no") )
+            launch_dm = 0;
+        if ( !strcmp(optarg, "yes") )
+            launch_dm = 1;
+        if ( !strcmp(optarg, "late") )
+            launch_dm = 2;
+        break;
+    case 'r':
+        reset = 1;
+        break;
+    case 'i':
+        allow_iommu = 1;
+        break;
+    default:
+        fprintf(stderr, "Unimplemented option(s)\n");
+        return EXIT_FAILURE;
+    }
+
+    if (argc-optind == 1) {
+        domid_in = atoi(argv[optind]);
+    } else {
+        help("fork-vm");
+        return EXIT_FAILURE;
+    }
+
+    if (launch_dm && (!config_file || !dm_restore_file)) {
+        fprintf(stderr, "Currently you must provide both -C and -Q options\n");
+        return EXIT_FAILURE;
+    }
+
+    if (reset) {
+        domid_out = domid_in;
+        if (libxl_domain_fork_reset(ctx, domid_in) == EXIT_FAILURE)
+            return EXIT_FAILURE;
+    }
+
+    if (launch_dm == 2 || reset) {
+        domid_out = domid_in;
+        rc = EXIT_SUCCESS;
+    } else {
+        if ( !max_vcpus )
+        {
+            fprintf(stderr, "Currently you must parent's max_vcpu for this option\n");
+            return EXIT_FAILURE;
+        }
+
+        rc = libxl_domain_fork_vm(ctx, domid_in, max_vcpus, allow_iommu, &domid_out);
+    }
+
+    if (rc == EXIT_SUCCESS) {
+        if ( launch_dm ) {
+            struct domain_create dom_info;
+            memset(&dom_info, 0, sizeof(dom_info));
+            dom_info.ddomid = domid_out;
+            dom_info.dm_restore_file = dm_restore_file;
+            dom_info.debug = debug;
+            dom_info.paused = pause;
+            dom_info.config_file = config_file;
+            dom_info.migrate_fd = -1;
+            dom_info.send_back_fd = -1;
+            rc = create_domain(&dom_info) < 0 ? EXIT_FAILURE : EXIT_SUCCESS;
+        } else if ( !pause )
+            rc = libxl_domain_unpause(ctx, domid_out, NULL);
+    }
+
+    if (rc == EXIT_SUCCESS)
+        fprintf(stderr, "fork-vm command successfully returned domid: %u\n", domid_out);
+    else if ( domid_out != INVALID_DOMID )
+        libxl_domain_destroy(ctx, domid_out, 0);
+
+    return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 17b4514c94..c64123d0a1 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -676,6 +676,12 @@ int create_domain(struct domain_create *dom_info)
 
     int restoring = (restore_file || (migrate_fd >= 0));
 
+#if defined(__i386__) || defined(__x86_64__)
+    /* VM forking */
+    uint32_t ddomid = dom_info->ddomid; // launch dm for this domain iff set
+    const char *dm_restore_file = dom_info->dm_restore_file;
+#endif
+
     libxl_domain_config_init(&d_config);
 
     if (restoring) {
@@ -928,6 +934,14 @@ start:
          * restore/migrate-receive it again.
          */
         restoring = 0;
+#if defined(__i386__) || defined(__x86_64__)
+    } else if ( ddomid ) {
+        d_config.dm_restore_file = dm_restore_file;
+        ret = libxl_domain_fork_launch_dm(ctx, &d_config, ddomid,
+                                          autoconnect_console_how);
+        domid = ddomid;
+        ddomid = INVALID_DOMID;
+#endif
     } else if (domid_soft_reset != INVALID_DOMID) {
         /* Do soft reset. */
         ret = libxl_domain_soft_reset(ctx, &d_config, domid_soft_reset,
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 15:30:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 15:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRdoD-0004Rv-QX; Thu, 23 Apr 2020 15:30:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1pl3=6H=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jRdoC-0004Rp-BL
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 15:30:36 +0000
X-Inumbo-ID: 5f0cea84-8577-11ea-9397-12813bfff9fa
Received: from mga07.intel.com (unknown [134.134.136.100])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5f0cea84-8577-11ea-9397-12813bfff9fa;
 Thu, 23 Apr 2020 15:30:33 +0000 (UTC)
IronPort-SDR: TajcVyTyurXD5NgXuYW9gSpJe6v2ZnVrBZ428hQpCskSx7luCpOCjrLIhfHXs5BC5H0ZoZFfim
 65bPhmAel3Nw==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga008.jf.intel.com ([10.7.209.65])
 by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 23 Apr 2020 08:30:31 -0700
IronPort-SDR: UPqpmh0ds16JMrdegGyL52NsidJa1OQ9CTOgRFycLgcjvHQejmILNSuTFj7o7uct+rqpgT0KY+
 JpoXWaq3RFPQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.73,307,1583222400"; d="scan'208";a="292311789"
Received: from nsheikh-mobl1.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.212.208.245])
 by orsmga008.jf.intel.com with ESMTP; 23 Apr 2020 08:30:30 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v17 1/2] mem_sharing: fix sharability check during fork reset
Date: Thu, 23 Apr 2020 08:30:06 -0700
Message-Id: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

When resetting a VM fork we ought to only remove pages that were allocated for
the fork during it's execution and the contents copied over from the parent.
This can be determined if the page is sharable as special pages used by the
fork for other purposes will not pass this test. Unfortunately during the fork
reset loop we only partially check whether that's the case. A page's type may
indicate it is sharable (pass p2m_is_sharable) but that's not a sufficient
check by itself. All checks that are normally performed before a page is
converted to the sharable type need to be performed to avoid removing pages
from the p2m that may be used for other purposes. For example, currently the
reset loop also removes the vcpu info pages from the p2m, potentially putting
the guest into infinite page-fault loops.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
v17: Changes based on feedback from Roger
---
 xen/arch/x86/mm/mem_sharing.c | 83 ++++++++++++++++++++---------------
 1 file changed, 47 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index bb74595351..344a5bfb3d 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -633,31 +633,33 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
 /* Functions that change a page's type and ownership */
 static int page_make_sharable(struct domain *d,
                               struct page_info *page,
-                              int expected_refcnt)
+                              unsigned int expected_refcnt,
+                              bool validate_only)
 {
-    bool_t drop_dom_ref;
+    int rc = 0;
+    bool drop_dom_ref = false;
 
-    spin_lock(&d->page_alloc_lock);
+    spin_lock_recursive(&d->page_alloc_lock);
 
     if ( d->is_dying )
     {
-        spin_unlock(&d->page_alloc_lock);
-        return -EBUSY;
+        rc = -EBUSY;
+        goto out;
     }
 
     /* Change page type and count atomically */
     if ( !get_page_and_type(page, d, PGT_shared_page) )
     {
-        spin_unlock(&d->page_alloc_lock);
-        return -EINVAL;
+        rc = -EINVAL;
+        goto out;
     }
 
     /* Check it wasn't already sharable and undo if it was */
     if ( (page->u.inuse.type_info & PGT_count_mask) != 1 )
     {
-        spin_unlock(&d->page_alloc_lock);
         put_page_and_type(page);
-        return -EEXIST;
+        rc = -EEXIST;
+        goto out;
     }
 
     /*
@@ -666,20 +668,26 @@ static int page_make_sharable(struct domain *d,
      */
     if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
     {
-        spin_unlock(&d->page_alloc_lock);
         /* Return type count back to zero */
         put_page_and_type(page);
-        return -E2BIG;
+        rc = -E2BIG;
+        goto out;
     }
 
-    page_set_owner(page, dom_cow);
-    drop_dom_ref = !domain_adjust_tot_pages(d, -1);
-    page_list_del(page, &d->page_list);
-    spin_unlock(&d->page_alloc_lock);
+    if ( !validate_only )
+    {
+        page_set_owner(page, dom_cow);
+        drop_dom_ref = !domain_adjust_tot_pages(d, -1);
+        page_list_del(page, &d->page_list);
+    }
+
+out:
+    spin_unlock_recursive(&d->page_alloc_lock);
 
     if ( drop_dom_ref )
         put_domain(d);
-    return 0;
+
+    return rc;
 }
 
 static int page_make_private(struct domain *d, struct page_info *page)
@@ -810,7 +818,8 @@ static int debug_gref(struct domain *d, grant_ref_t ref)
 }
 
 static int nominate_page(struct domain *d, gfn_t gfn,
-                         int expected_refcnt, shr_handle_t *phandle)
+                         unsigned int expected_refcnt, bool validate_only,
+                         shr_handle_t *phandle)
 {
     struct p2m_domain *hp2m = p2m_get_hostp2m(d);
     p2m_type_t p2mt;
@@ -879,8 +888,8 @@ static int nominate_page(struct domain *d, gfn_t gfn,
     }
 
     /* Try to convert the mfn to the sharable type */
-    ret = page_make_sharable(d, page, expected_refcnt);
-    if ( ret )
+    ret = page_make_sharable(d, page, expected_refcnt, validate_only);
+    if ( ret || validate_only )
         goto out;
 
     /*
@@ -1392,13 +1401,13 @@ static int range_share(struct domain *d, struct domain *cd,
          * We only break out if we run out of memory as individual pages may
          * legitimately be unsharable and we just want to skip over those.
          */
-        rc = nominate_page(d, _gfn(start), 0, &sh);
+        rc = nominate_page(d, _gfn(start), 0, false, &sh);
         if ( rc == -ENOMEM )
             break;
 
         if ( !rc )
         {
-            rc = nominate_page(cd, _gfn(start), 0, &ch);
+            rc = nominate_page(cd, _gfn(start), 0, false, &ch);
             if ( rc == -ENOMEM )
                 break;
 
@@ -1478,7 +1487,7 @@ int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
         /* For read-only accesses we just add a shared entry to the physmap */
         while ( parent )
         {
-            if ( !(rc = nominate_page(parent, gfn, 0, &handle)) )
+            if ( !(rc = nominate_page(parent, gfn, 0, false, &handle)) )
                 break;
 
             parent = parent->parent;
@@ -1775,20 +1784,22 @@ static int mem_sharing_fork_reset(struct domain *d, struct domain *pd)
     spin_lock_recursive(&d->page_alloc_lock);
     page_list_for_each_safe(page, tmp, &d->page_list)
     {
-        p2m_type_t p2mt;
-        p2m_access_t p2ma;
+        shr_handle_t sh;
         mfn_t mfn = page_to_mfn(page);
         gfn_t gfn = mfn_to_gfn(d, mfn);
 
-        mfn = __get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
-                                    0, NULL, false);
-
-        /* only reset pages that are sharable */
-        if ( !p2m_is_sharable(p2mt) )
-            continue;
-
-        /* take an extra reference or just skip if can't for whatever reason */
-        if ( !get_page(page, d) )
+        /*
+         * We only want to remove pages from the fork here that were copied
+         * from the parent but could be potentially re-populated using memory
+         * sharing after the reset. These pages all must be regular pages with
+         * no extra reference held to them, thus should be possible to make
+         * them sharable. Unfortunately p2m_is_sharable check is not sufficient
+         * to test this as it doesn't check the page's reference count. We thus
+         * check whether the page is convertable to the shared type using
+         * nominate_page. In case the page is already shared (ie. a share
+         * handle is returned) then we don't remove it.
+         */
+        if ( (rc = nominate_page(d, gfn, 0, true, &sh)) || sh )
             continue;
 
         /* forked memory is 4k, not splitting large pages so this must work */
@@ -1797,7 +1808,7 @@ static int mem_sharing_fork_reset(struct domain *d, struct domain *pd)
         ASSERT(!rc);
 
         put_page_alloc_ref(page);
-        put_page(page);
+        put_page_and_type(page);
     }
     spin_unlock_recursive(&d->page_alloc_lock);
 
@@ -1839,7 +1850,7 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
     {
         shr_handle_t handle;
 
-        rc = nominate_page(d, _gfn(mso.u.nominate.u.gfn), 0, &handle);
+        rc = nominate_page(d, _gfn(mso.u.nominate.u.gfn), 0, false, &handle);
         mso.u.nominate.handle = handle;
     }
     break;
@@ -1854,7 +1865,7 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
         if ( rc < 0 )
             goto out;
 
-        rc = nominate_page(d, gfn, 3, &handle);
+        rc = nominate_page(d, gfn, 3, false, &handle);
         mso.u.nominate.handle = handle;
     }
     break;
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 16:04:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 16:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jReKe-0007fO-PN; Thu, 23 Apr 2020 16:04:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XA1d=6H=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jReKc-0007fJ-Vv
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 16:04:07 +0000
X-Inumbo-ID: 0e912020-857c-11ea-83d8-bc764e2007e4
Received: from mail-lj1-x241.google.com (unknown [2a00:1450:4864:20::241])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0e912020-857c-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 16:04:06 +0000 (UTC)
Received: by mail-lj1-x241.google.com with SMTP id e25so6782953ljg.5
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 09:04:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Jl/mQ2S57lrCLWS8kOqczzvd1rhQS4QIIAeKgUoS/o0=;
 b=LBh7QMxba3fD1tuIqrdXAAqbvjS4foINqiU5D2wMEjDv/bzE14PmF2j/bVs61JVbWU
 G231u9UNmZDctbVL5xqB1CYAc5J1fKOo0+Q7SDzAGSBfnBJKBG+0dyLPE2rxXBXk0wo1
 Vn0sPgUeBV704+XAK82UfMYNSy6kgBWh2aoT1qgxdDHvarcVSQ8Y2WMoRclG+BiYAQ1v
 4n4go/kU0macg/hh44h0+Mu1duqnCb+YpPMiT0Ot7cgzW8BQ7MHuer4lkM0+4lj1kSbR
 aaNvgKBO0kjsOmkQZ68hb7nK0k5axpF4cj9svjEhHmuZIOIRmyMVdnfpr7GKVDIXtSCN
 gNcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Jl/mQ2S57lrCLWS8kOqczzvd1rhQS4QIIAeKgUoS/o0=;
 b=bbRNPkFOjxnNN7hzkSmCtmdIAstAlzfhtcuYwX506409vAgv+FnUkwTsO6Y05Oe2jT
 z9A4irFz0URBWSh2HBrlLVFKkup6B5lg1PZ6XjlV7yOUCJoVuqlZXdoXVXAMV8q0QjWr
 /lHcSRrtqUzhwzeM3TyNyhOl4tUNsnCPu1+97dEhCfA3wOq9CutqRstyar2eNbfI/Of8
 qhwKMHvHQCNuGq7pPgRTtc6mI/acD4UhUTE8uC0wV+ra6jZ2hO+q2reJ64V1GO+Lc8Sw
 9irS9B9gCtwCeY4UxHXZeePbKksU45NFOMzrisOHm49xjIBXwNzCAHuYyHMPVS/Q0p3e
 YOLA==
X-Gm-Message-State: AGi0PubdTg/gvKd8vZXMR4yyKmqw/8TC650IbLbTAyQN2VSJOjZFHXY9
 n/Up/kAowF6XyKkRD8KpXmJmcJD2190jjg2evxA=
X-Google-Smtp-Source: APiQypL29hwNrh9EZ+iZWZHtOLzHf/J/E0Fhapd0VSzs+wVwhe27mKT12iXYkhkLSmx1ng8Ns5YHUy7Qs6wEVMFbHh8=
X-Received: by 2002:a2e:95c5:: with SMTP id y5mr2936483ljh.26.1587657845012;
 Thu, 23 Apr 2020 09:04:05 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
 <CAFLBxZaKiuqpmVvP2ww9YbuTkCm9wdBKGdMJOrT=sTaJSaycqg@mail.gmail.com>
In-Reply-To: <CAFLBxZaKiuqpmVvP2ww9YbuTkCm9wdBKGdMJOrT=sTaJSaycqg@mail.gmail.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Thu, 23 Apr 2020 12:03:53 -0400
Message-ID: <CAEBZRSfG053_DYA6BCZUjg6c4oa3AHDsK5Puc4ipy=py8C6Mgw@mail.gmail.com>
Subject: Re: [PATCH 1/2] tools: build golang tools if go compiler is present
To: George Dunlap <dunlapg@umich.edu>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 9:44 AM George Dunlap <dunlapg@umich.edu> wrote:
>
>
>
> On Thu, Apr 23, 2020 at 1:51 AM Nick Rosbrook <rosbrookn@gmail.com> wrote:
>>
>> By default, if the go compiler is found by the configure script, build
>> the golang tools. If the compiler is not found, and
>> --enable-golang_tools was not explicitly set, do not build to the golang
>> tools.
>>
>> The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove
>> CONFIG_GOLANG from tools/Rules.mk since the new variable is set by
>> configure.
>>
>> Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
>> ---
>>  config/Tools.mk.in |   1 +
>>  m4/golang.m4       |   4 ++
>>  tools/Makefile     |   2 +-
>>  tools/Rules.mk     |   2 -
>>  tools/configure    | 138 +++++++++++++++++++++++++++++++++++++++++++++
>>  tools/configure.ac |  12 ++++
>>  6 files changed, 156 insertions(+), 3 deletions(-)
>>  create mode 100644 m4/golang.m4
>>
>> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
>> index 189fda1596..2c219f5477 100644
>> --- a/config/Tools.mk.in
>> +++ b/config/Tools.mk.in
>> @@ -55,6 +55,7 @@ CONFIG_QEMU_TRAD    := @qemu_traditional@
>>  CONFIG_QEMU_XEN     := @qemu_xen@
>>  CONFIG_QEMUU_EXTRA_ARGS:= @EXTRA_QEMUU_CONFIGURE_ARGS@
>>  CONFIG_LIBNL        := @libnl@
>> +CONFIG_GOLANG_TOOLS := @golang_tools@
>>
>>  CONFIG_SYSTEMD      := @systemd@
>>  SYSTEMD_CFLAGS      := @SYSTEMD_CFLAGS@
>> diff --git a/m4/golang.m4 b/m4/golang.m4
>> new file mode 100644
>> index 0000000000..0b4bd54ce0
>> --- /dev/null
>> +++ b/m4/golang.m4
>> @@ -0,0 +1,4 @@
>> +AC_DEFUN([AC_PROG_GO], [
>> +    dnl Check for the go compiler
>> +    AC_CHECK_TOOL([GO],[go],[no])
>> +])
>
>
> AFAICT this only checks for the existence of the binary.  Will the bindings compile with all versions of go?  If not, should we try to check the version here?

There are no obvious pieces to me that won't compile on fairly recent
(i.e. >= 1.9) versions of go, but yes it would probably be best to
check for a minimum version. I will do some more work to figure out an
appropriate minimum version, but I think go 1.10 might be a reasonable
start.

Thanks,

-NR


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 16:06:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 16:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jReMu-0007m5-6R; Thu, 23 Apr 2020 16:06:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XA1d=6H=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jReMs-0007m0-Ve
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 16:06:27 +0000
X-Inumbo-ID: 6221aa48-857c-11ea-9e09-bc764e2007e4
Received: from mail-lf1-x142.google.com (unknown [2a00:1450:4864:20::142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6221aa48-857c-11ea-9e09-bc764e2007e4;
 Thu, 23 Apr 2020 16:06:26 +0000 (UTC)
Received: by mail-lf1-x142.google.com with SMTP id h6so5234158lfc.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 09:06:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=mwH9Ib0J5zg1xKgoiAredKEIra7n1riZan7qItV2GyY=;
 b=RFWDHO1SNU+NdyPc/rgZkzWeIyqqxQ+7hvOLsPiXlLo47K4OqPFhFbW9P06oBlPheW
 JkU5zAbj/ujH90wK4AWAd80ngLG9+DDdO5RmWN/yyayJyc0yPQ7OB4hNdo5qVs3VVNFN
 fXITXQDNhJkTIyP/Vc7xWC5R/xuUKtSnyKqSbZI2OMjB2QEr6axb8hDnPqdqMJlOh3X8
 REgLOtqKb+UUfOO2FXs1jRCH8bYFKH65/CPB13hzKbVFL0ZejJZKAtVaND4iexDJbMFg
 GnOKoobiQM5c4NHuAOS+jYgpsOBuMh8a3b1ZwYVku2irOqRBiONwlasHk/zqWF2bw03a
 sAvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=mwH9Ib0J5zg1xKgoiAredKEIra7n1riZan7qItV2GyY=;
 b=ItuftXa38IhdR8iK5Bjxoy6zp82djo7Lu2yGDU1PvILSqIwfOmMZ7knJphoqRaOIy6
 YZY6U2yz3yFo4P2wxpz5QC1E2hzA/62LMUFBAcSfd4PMOyN/XLxGIenh6xo4ygsNPnDy
 +qiA2h3BTIWWBE6GgGADhDL65ZlJjA6QCUbx2/fBMiswC/HseUyDlgERStFbAQqz/VbI
 ATRForFMHdue+tV1xtHq2klQnfBebAnh32veH6bgRL7G9EcP9hk+3YKazEGhTGtBbBcr
 yj5YDDDbQn/0s0XncwS8jRrgzSSU3UUReX9Bnvi3SPSwgfYC4fbrYtg+q/41ZwL3QOuU
 Aa7w==
X-Gm-Message-State: AGi0PuZVkT7fWcH7V43QJVhC22/RCCfbWmQuBItETFrlQlUJTI6alsIq
 JwF1D4/ACWbMhXqbdxBQ/0ofWGF5/PPxFyl4OVm2wVb+
X-Google-Smtp-Source: APiQypI3tFYufmXQVRqZVVdLTos8zyHe2bLo9tB/ZKsu8F+Ttr/2IKfHGCczoNSTO/cJZfSsPNdug6QrSoiwttm7dQM=
X-Received: by 2002:a19:a411:: with SMTP id q17mr2955216lfc.214.1587657985332; 
 Thu, 23 Apr 2020 09:06:25 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
 <20200423102538.vxuo7s2lamkxhoo7@debian>
In-Reply-To: <20200423102538.vxuo7s2lamkxhoo7@debian>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Thu, 23 Apr 2020 12:06:14 -0400
Message-ID: <CAEBZRScj397TxGBrJ78Qi8jh_NWGOi8BL4TXciKZFayewysRNA@mail.gmail.com>
Subject: Re: [PATCH 1/2] tools: build golang tools if go compiler is present
To: Wei Liu <wl@xen.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 6:25 AM Wei Liu <wl@xen.org> wrote:
>
> On Wed, Apr 22, 2020 at 08:25:25PM -0400, Nick Rosbrook wrote:
> > By default, if the go compiler is found by the configure script, build
> > the golang tools. If the compiler is not found, and
> > --enable-golang_tools was not explicitly set, do not build to the golang
>
> --enable-golang-tools here.
>
> > tools.
> >
> > The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove
> > CONFIG_GOLANG from tools/Rules.mk since the new variable is set by
> > configure.
> >
> > Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
>
> Acked-by: Wei Liu <wl@xen.org>

Thanks!

-NR


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 16:34:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 16:34:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRenX-0001oR-1v; Thu, 23 Apr 2020 16:33:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRenV-0001oM-4Z
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 16:33:57 +0000
X-Inumbo-ID: 39c495b6-8580-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 39c495b6-8580-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 16:33:56 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9C1B7ABCF;
 Thu, 23 Apr 2020 16:33:54 +0000 (UTC)
Subject: Re: [PATCH v11 1/3] x86/tlb: introduce a flush HVM ASIDs flag
To: Roger Pau Monne <roger.pau@citrix.com>
References: <20200423145611.55378-1-roger.pau@citrix.com>
 <20200423145611.55378-2-roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <59e48d80-8ce1-3f3d-c07e-5117adea272a@suse.com>
Date: Thu, 23 Apr 2020 18:33:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200423145611.55378-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.2020 16:56, Roger Pau Monne wrote:
> Introduce a specific flag to request a HVM guest linear TLB flush,
> which is an ASID/VPID tickle that forces a guest linear to guest
> physical TLB flush for all HVM guests.
> 
> This was previously unconditionally done in each pre_flush call, but
> that's not required: HVM guests not using shadow don't require linear
> TLB flushes as Xen doesn't modify the pages tables the guest runs on
> in that case (ie: when using HAP). Note that shadow paging code
> already takes care of issuing the necessary flushes when the shadow
> page tables are modified.
> 
> In order to keep the previous behavior modify all shadow code TLB
> flushes to also flush the guest linear to physical TLB if the guest is
> HVM. I haven't looked at each specific shadow code TLB flush in order
> to figure out whether it actually requires a guest TLB flush or not,
> so there might be room for improvement in that regard.
> 
> Also perform ASID/VPID flushes when modifying the p2m tables as it's a
> requirement for AMD hardware. Finally keep the flush in
> switch_cr3_cr4, as it's not clear whether code could rely on
> switch_cr3_cr4 also performing a guest linear TLB flush. A following
> patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to
> not be necessary.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 16:40:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 16:40:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRety-0002eC-Pi; Thu, 23 Apr 2020 16:40:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRetx-0002e7-JL
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 16:40:37 +0000
X-Inumbo-ID: 283b293a-8581-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 283b293a-8581-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 16:40:36 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 72811ADB5;
 Thu, 23 Apr 2020 16:40:34 +0000 (UTC)
Subject: Re: [XEN PATCH v5 04/16] xen/build: have the root Makefile generates
 the CFLAGS
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-5-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <28aeea6d-cd52-d8bf-f114-96ec435363c6@suse.com>
Date: Thu, 23 Apr 2020 18:40:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-5-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 18:11, Anthony PERARD wrote:
> Instead of generating the CFLAGS in Rules.mk everytime we enter a new
> subdirectory, we are going to generate most of them a single time, and
> export the result in the environment so that Rules.mk can use it.  The
> only flags left to be generated are the ones that depend on the
> targets, but the variable $(c_flags) takes care of that.
> 
> Arch specific CFLAGS are generated by a new file "arch/*/arch.mk"
> which is included by the root Makefile.
> 
> We export the *FLAGS via the environment variables XEN_*FLAGS because
> Rules.mk still includes Config.mk and would add duplicated flags to
> CFLAGS.
> 
> When running Rules.mk in the root directory (xen/), the variable
> `root-make-done' is set, so `need-config' will remain undef and so the
> root Makefile will not generate the cflags again.
> 
> We can't use CFLAGS in subdirectories to add flags to particular
> targets, instead start to use CFLAGS-y. Idem for AFLAGS.
> So there are two different CFLAGS-y, the one in xen/Makefile (and
> arch.mk), and the one in subdirs that Rules.mk is going to use.
> We can't add to XEN_CFLAGS because it is exported, so making change to
> it might be propagated to subdirectory which isn't intended.
> 
> Some style change are introduced in this patch:
>     when LDFLAGS_DIRECT is included in LDFLAGS
>     use of CFLAGS-$(CONFIG_INDIRECT_THUNK) instead of ifeq().
> 
> The LTO change hasn't been tested properly, as LTO is marked as
> broken.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
with one further question:

> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -1,89 +1,10 @@
>  ########################################
>  # x86-specific definitions
>  
> -XEN_IMG_OFFSET := 0x200000
> -
> -CFLAGS += -I$(BASEDIR)/include
> -CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
> -CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
> -CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
> -CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst $(BASEDIR)/,,$(CURDIR))/$@))'
> -
> -# Prevent floating-point variables from creeping into Xen.
> -CFLAGS += -msoft-float
> -
> -ifeq ($(CONFIG_CC_IS_CLANG),y)
> -# Note: Any test which adds -no-integrated-as will cause subsequent tests to
> -# succeed, and not trigger further additions.
> -#
> -# The tests to select whether the integrated assembler is usable need to happen
> -# before testing any assembler features, or else the result of the tests would
> -# be stale if the integrated assembler is not used.
> -
> -# Older clang's built-in assembler doesn't understand .skip with labels:
> -# https://bugs.llvm.org/show_bug.cgi?id=27369
> -$(call as-option-add,CFLAGS,CC,".L0: .L1: .skip (.L1 - .L0)",,\
> -                     -no-integrated-as)
> -
> -# Check whether clang asm()-s support .include.
> -$(call as-option-add,CFLAGS,CC,".include \"asm-x86/indirect_thunk_asm.h\"",,\
> -                     -no-integrated-as)
> -
> -# Check whether clang keeps .macro-s between asm()-s:
> -# https://bugs.llvm.org/show_bug.cgi?id=36110
> -$(call as-option-add,CFLAGS,CC,\
> -                     ".macro FOO;.endm"$$(close); asm volatile $$(open)".macro FOO;.endm",\
> -                     -no-integrated-as)
> -endif
> -
> -$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
> -$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
> -$(call as-option-add,CFLAGS,CC,"vmcall",-DHAVE_AS_VMX)
> -$(call as-option-add,CFLAGS,CC,"crc32 %eax$$(comma)%eax",-DHAVE_AS_SSE4_2)
> -$(call as-option-add,CFLAGS,CC,"invept (%rax)$$(comma)%rax",-DHAVE_AS_EPT)
> -$(call as-option-add,CFLAGS,CC,"rdrand %eax",-DHAVE_AS_RDRAND)
> -$(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE)
> -$(call as-option-add,CFLAGS,CC,"xsaveopt (%rax)",-DHAVE_AS_XSAVEOPT)
> -$(call as-option-add,CFLAGS,CC,"rdseed %eax",-DHAVE_AS_RDSEED)
> -$(call as-option-add,CFLAGS,CC,"clwb (%rax)",-DHAVE_AS_CLWB)
> -$(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
> -                     -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM \
> -                     '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
> -$(call as-option-add,CFLAGS,CC,"invpcid (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
> -
> -# GAS's idea of true is -1.  Clang's idea is 1
> -$(call as-option-add,CFLAGS,CC,\
> -    ".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE)
> -
> -# Check to see whether the assmbler supports the .nop directive.
> -$(call as-option-add,CFLAGS,CC,\
> -    ".L1: .L2: .nops (.L2 - .L1)$$(comma)9",-DHAVE_AS_NOPS_DIRECTIVE)
> -
> -CFLAGS += -mno-red-zone -fpic -fno-asynchronous-unwind-tables
> -
> -# Xen doesn't use SSE interally.  If the compiler supports it, also skip the
> -# SSE setup for variadic function calls.
> -CFLAGS += -mno-sse $(call cc-option,$(CC),-mskip-rax-setup)
> -
> -# Compile with thunk-extern, indirect-branch-register if avaiable.
> -ifeq ($(CONFIG_INDIRECT_THUNK),y)
> -CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register
> -CFLAGS += -fno-jump-tables
> +ifneq ($(filter -DHAVE_AS_QUOTED_SYM,$(XEN_CFLAGS)),)
> +object_label_flags = '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$@'
> +else
> +object_label_flags = '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst $(BASEDIR)/,,$(CURDIR))/$@))'
>  endif
> -
> -# If supported by the compiler, reduce stack alignment to 8 bytes. But allow
> -# this to be overridden elsewhere.
> -$(call cc-option-add,CFLAGS-stack-boundary,CC,-mpreferred-stack-boundary=3)
> -CFLAGS += $(CFLAGS-stack-boundary)
> -
> -ifeq ($(CONFIG_UBSAN),y)
> -# Don't enable alignment sanitisation.  x86 has efficient unaligned accesses,
> -# and various things (ACPI tables, hypercall pages, stubs, etc) are wont-fix.
> -# It also causes an as-yet-unidentified crash on native boot before the
> -# console starts.
> -$(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
> -endif
> -
> -# Set up the assembler include path properly for older toolchains.
> -CFLAGS += -Wa,-I$(BASEDIR)/include
> -
> +c_flags += $(object_label_flags) $(CFLAGS-stack-boundary)
> +a_flags += $(object_label_flags) $(CFLAGS-stack-boundary)

Why are you also adding these to a_flags? It probably doesn't hurt,
but I'd prefer if it was removed (could be done while committing if
all acks arrive and other other need for av6 arises) if there's no
clear need.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 16:49:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 16:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRf1z-0002ti-Ju; Thu, 23 Apr 2020 16:48:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=0dw1=6H=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRf1y-0002td-Cu
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 16:48:54 +0000
X-Inumbo-ID: 50aa08ae-8582-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 50aa08ae-8582-11ea-9e09-bc764e2007e4;
 Thu, 23 Apr 2020 16:48:53 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E052BAD8E;
 Thu, 23 Apr 2020 16:48:51 +0000 (UTC)
Subject: Re: [XEN PATCH v5 08/16] build: Introduce $(cpp_flags)
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-9-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <62011f46-b208-334a-4070-0bd72cb21d28@suse.com>
Date: Thu, 23 Apr 2020 18:48:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-9-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 18:12, Anthony PERARD wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -123,6 +123,7 @@ $(obj-bin-y): XEN_CFLAGS := $(filter-out -flto,$(XEN_CFLAGS))
>  
>  c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_CFLAGS) '-D__OBJECT_FILE__="$@"'
>  a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_AFLAGS)
> +cpp_flags = $(filter-out -Wa$(comma)%,$(a_flags))

I can see this happening to be this way right now, but in principle
I could see a_flags to hold items applicable to assembly files only,
but not to (the preprocessing of) C files. Hence while this is fine
for now, ...

> @@ -207,7 +208,7 @@ quiet_cmd_cc_s_c = CC      $@
>  cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
>  
>  quiet_cmd_s_S = CPP     $@
> -cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
> +cmd_s_S = $(CPP) $(cpp_flags) $< -o $@

... this one is a trap waiting for someone to fall in imo. Instead
where I'd expect this patch to use $(cpp_flags) is e.g. in
xen/arch/x86/mm/Makefile:

guest_walk_%.i: guest_walk.c Makefile
	$(CPP) $(cpp_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@

And note how this currently uses $(c_flags), not $(a_flags), which
suggests that your deriving from $(a_flags) isn't correct either.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 17:22:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 17:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRfYc-00065r-CP; Thu, 23 Apr 2020 17:22:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wmme=6H=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRfYb-00065m-Gf
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 17:22:37 +0000
X-Inumbo-ID: 06474722-8587-11ea-93d9-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 06474722-8587-11ea-93d9-12813bfff9fa;
 Thu, 23 Apr 2020 17:22:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587662556;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=SXX6Cy3HxWZ7kISvWQb+UKGGpIRrggUJxZYRrimT6nU=;
 b=QYMlwYheiBuz0Ft8IuuqYM/KEk1L4K3GBFNPHAo4zYcxddGUNh6j3x30
 /UlcNDMVo4gqG75hJyTQ/JOiNEXMkeWlu4Pq3jx0KSMeZBtcy2hYBmt6u
 5xwLJEMeZLvlvlz66Q3Xl2fBCeClQin7JZIo3yBcE1wl3hAoyha0DkavD 4=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: /qzOoBD1WyV3+KRJQD94Vx/OmNKtjNdyBy9/vCbhkj2tQkdEEDAXgxIXXd7/UaxnkfdV2ybBeK
 27kZlW4uvt7V+bTsc9LYjB/WOgC/7UTUeJZZePHl3Kahpm2fy8OCZu7KqW79lWAGrc3mFkOCx3
 c6aUwuu+V6KniBWYWzMA78aRW9zQ3aDax8KLTs6EHwmvfu1HvqiSE86w+Qm1XuPNpvzuqzTeLv
 Z4HRly9ZFZKstHPqmpgHPWuWM5J28jTy68EE81uv+T7YE/1voEALzDGClsIg0y0dfussTB0rzv
 x84=
X-SBRS: 2.7
X-MesageID: 16548945
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16548945"
From: George Dunlap <George.Dunlap@citrix.com>
To: Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: Golang Xen packages and the golang packaging  system
Thread-Topic: Golang Xen packages and the golang packaging  system
Thread-Index: AQHWGL+431OGV0A6ZUWxyQX/eS/9b6iGcJeAgAAA0oCAAAYAAIAAXRsA
Date: Thu, 23 Apr 2020 17:22:33 +0000
Message-ID: <C10E07AB-FDE8-4588-95E7-6109F0FDB5E2@citrix.com>
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
 <24225.31493.220592.722565@mariner.uk.xensource.com>
 <24225.31669.536258.56822@mariner.uk.xensource.com>
 <4085F05B-ABEC-446A-8BB1-06DEE57D71A5@citrix.com>
In-Reply-To: <4085F05B-ABEC-446A-8BB1-06DEE57D71A5@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <77DAB79F4C839D46B2BC9950EA0612A4@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Nick Rosbrook <rosbrookn@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQo+IE9uIEFwciAyMywgMjAyMCwgYXQgMTI6NDkgUE0sIEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5k
dW5sYXBAY2l0cml4LmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gDQo+PiBPbiBBcHIgMjMsIDIwMjAs
IGF0IDEyOjI3IFBNLCBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AY2l0cml4LmNvbT4gd3JvdGU6
DQo+PiANCj4+IElhbiBKYWNrc29uIHdyaXRlcyAoIlJlOiBHb2xhbmcgWGVuIHBhY2thZ2VzIGFu
ZCB0aGUgZ29sYW5nIHBhY2thZ2luZyAgc3lzdGVtIik6DQo+Pj4gVGhpcyBpcyBxdWl0ZSB1bnBs
ZWFzYW50LiAgSW4gcGFydGljdWxhciwgaXQgbWFrZXMgYSBnaXQgdHJlZSBvdXQgb2YNCj4+PiBv
dXRwdXQgZmlsZXMuICBXaGF0IHdpbGwgd2UgZG8gd2hlbiBzb21lb25lIHNlbmRzIHVzIHBhdGNo
ZXMgdG8gdGhlDQo+Pj4gYmluZGluZ3MgPw0KPj4gDQo+PiBBbHNvLCBhbnlvbmUgd2hvIHJlZGlz
dHJpYnV0ZXMgeW91ciBwcm9wb3NlZCBnb2xhbmcgcGFja2FnZSBpcw0KPj4gdmlvbGF0aW5nIG91
ciBsaWNlbmNlIHVubGVzcyB0aGV5IHNoaXAgYSBjb3B5IG9mIHhlbi5naXRbMV0gdG9vLCBzaW5j
ZQ0KPj4gdGhlIGdvbGFuZyBwYWNrYWdlIGlzIG5vdCBzb3VyY2UgY29kZS4NCj4+IA0KPj4gWzFd
IFRlY2huaWNhbGx5LCBhIGNvcHkgb2YgdGhlIHJlbGV2YW50IHBhcnRzIHdpbGwgZG8uDQo+IA0K
PiBUaGUg4oCccmVsZXZhbnQgcGFydHPigJ0gd291bGQgcHJpbWFyaWx5IGJlIGdlbmdvdHlwZXMu
cHksIHJpZ2h0PyAgT2gsIGFuZCBJIGd1ZXNzIGxpYnhsX3Rlc3QuaWRsIGFuZCBmcmllbmRzLiAg
bGlieGxfdGVzdC5pZGwgaXNu4oCZdCBpbmNsdWRlZCBpbiB0aGUgZGlzdHJpYnV0aW9uIGVpdGhl
ci4NCj4gDQo+IEnigJltIG5vdCBhbiBleHBlcnQgaW4gdGhlIGdvbGFuZyBidWlsZCBzeXN0ZW0s
IGJ1dCB0aGV5IGdlbmVyYWxseSBzZWVtIHRvIGJlIHRyeWluZyB0byBrZWVwIHRoZSBmdW5jdGlv
bmFsaXR5IHNpbXBsZSAod2hpY2ggb2YgY291cnNlLCBtZWFucyBpZiB5b3Ugd2FudCB0byBkbyBh
bnl0aGluZyBub24tYmFzaWMsIGl04oCZcyBpbmNyZWRpYmx5IGNvbXBsaWNhdGVkIG9yIGNvbXBs
ZXRlbHkgaW1wb3NzaWJsZSkuDQo+IA0KPiBUaGVyZeKAmXMgYSBjb21tYW5kLCBgZ28gZ2VuZXJh
dGVgLCB3aGljaCB3ZSBjb3VsZCB1c2UgdG8gcnVuIGdlbmdvdHlwZXMucHkgdG8gZ2VuZXJhdGUg
dGhlIGFwcHJvcHJpYXRlIGZpbGVzLiAgQnV0IEnigJltIG5vdCBzdXJlIGhvdyB0byB1c2UgdGhh
dCBpbiBhIHByYWN0aWNhbCB3YXkgZm9yIHRoaXMgc29ydCBvZiBwYWNrYWdlOiBpdCBtaWdodCBl
bmQgdXAgdGhhdCBwZW9wbGUgd2FudGluZyB0byB1c2UgdGhlIHBhY2thZ2Ugd291bGQgbmVlZCB0
byBtYW51YWxseSBjbG9uZSBpdCwgdGhlbiBtYW51YWxseSBydW4gYGdvIGdlbmVyYXRlYCBiZWZv
cmUgbWFudWFsbHkgYnVpbGRpbmcgdGhlIHBhY2thZ2UuDQo+IA0KPiBDaGVja2luZyBpbiB0aGUg
Z2VuZXJhdGVkIGZpbGVzIG1lYW5zIHRoYXQgc29tZW9uZSBjYW4gc2ltcGx5IGFkZCBgZ29sYW5n
LnhlbnByb2plY3Qub3JnL3hlbmxpZ2h0YCBhcyBhIGRlcGVuZGVuY3kgKHBlcmhhcHMgd2l0aCBh
IHNwZWNpZmljIHZlcnNpb24gdGFnLCBsaWtlIHY0LjE0KSwgYW5kIGV2ZXJ5dGhpbmcgSnVzdCBX
b3Jrcy4NCj4gDQo+IE5pY2sgbWF5IGhhdmUgc29tZSBpZGVhcyBvbiBob3cgdG8gdXNlIHRoZSBn
b2xhbmcgYnVpbGQgc3lzdGVtIG1vcmUgZWZmZWN0aXZlbHkuDQoNClNvLCB0aGUgZm9sbG93aW5n
IHNlZW1zIHRvIHdvcmsgcXVpdGUgd2VsbCBhY3R1YWxseToNCg0KbWtkaXIgdmVuZG9yDQpsbiAt
cyB2ZW5kb3IvZ29sYW5nLnhlbnByb2plY3Qub3JnIC91c3Ivc2hhcmUvZ29jb2RlL3NyYy9nb2xh
bmcueGVucHJvamVjdC5vcmcNCmVjaG8g4oCcZ29sYW5nLnhlbnByb2plY3Qub3JnL3hlbmxpZ2h0
4oCdID4+IHZlbmRvci9tb2R1bGVzLnR4dA0KZ28gYnVpbGQgLW1vZD12ZW5kb3INCg0KVXNpbmcg
dGhlIGFib3ZlIG1ldGhvZCwgKHNheSkgcmVkY3RsLmdpdCB3b3VsZCBidWlsZCBleGFjdGx5IHRo
ZSBzYW1lIG9uIFhlbiA0LjE0IGFzIG9uIFhlbiA0LjE1IChhc3N1bWluZyByZWRjdGwgd2FzbuKA
mXQgdXNpbmcgYW55dGhpbmcgbm90IGF2YWlsYWJsZSBpbiA0LjE0KS4NCg0KSeKAmW0gaW5jbGlu
ZWQgdG8gc2F5IHdlIHNob3VsZCBzdGFydCB3aXRoIGp1c3QgdGVsbGluZyBwZW9wbGUgdG8gZG8g
dGhhdCwgYW5kIGxvb2sgYXQgZG9pbmcgc29tZXRoaW5nIGVsc2UgaWYgd2UgZGlzY292ZXIgdGhh
dOKAmXMgbm90IHN1aXRhYmxlIGZvciBzb21lIHJlYXNvbi4NCg0KIC1HZW9yZ2U=


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 17:28:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 17:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRfdq-0006J8-5R; Thu, 23 Apr 2020 17:28:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wmme=6H=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRfdo-0006J3-Gq
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 17:28:00 +0000
X-Inumbo-ID: c6bfebee-8587-11ea-9e09-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c6bfebee-8587-11ea-9e09-bc764e2007e4;
 Thu, 23 Apr 2020 17:27:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587662880;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=NixxDjzlzmTaPzVObK4CetDGsSL7Oud9FXalS93iAT4=;
 b=S4iMi0Ov5Z7WclKqPbB9yDFsuQqU6X1FAUEag+iu0kuzUX4gWgKxxDVI
 c2ynEsfaQWRCXly8G9PM55Xy+eZn1yiOdbgXW0NWzQdSXNbMbjsHrvE/V
 p8PBq3qth/ykcVevkQuPDb2ffRdFxd4NERbOUFNYgvSC9KI9SJ/nxg6dw s=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: rxEB/pU8dw4gPEGBsXUmcyjkWJkHZcezjs9DXmhqLsyhpVGmO9J4jE3Z7zlBAS8DaoEXyhB0cK
 LqhyPBvlhukpdRVcP2nHuRlQcRETIxxR3HVLng5ERKMrIb/kMlJHqdfzOTQ32ouAQlUxh7P9Yb
 xJwkV+5pY4PZivL20fvXawwdxB6ZFJezsJDQ8ToE7lXGQ37ibMNhBz0uJsYZB9l+18uURCdM8M
 5Jgiga2oCuD320L/IOMsUDeVh0cPUeJNV3coVIq/+cMKuFQIP1MNHhE+1/TRbI1VXbubXZ8Je2
 TGU=
X-SBRS: 2.7
X-MesageID: 16131808
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16131808"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 1/2] tools: build golang tools if go compiler is present
Thread-Topic: [PATCH 1/2] tools: build golang tools if go compiler is present
Thread-Index: AQHWGXVVEMzovBzqEEyjZLPfGUwjnqiGvR+AgAAXe4A=
Date: Thu, 23 Apr 2020 17:27:55 +0000
Message-ID: <E0E74128-3E4E-44C7-976D-098CBADF4C5D@citrix.com>
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
 <CAFLBxZaKiuqpmVvP2ww9YbuTkCm9wdBKGdMJOrT=sTaJSaycqg@mail.gmail.com>
 <CAEBZRSfG053_DYA6BCZUjg6c4oa3AHDsK5Puc4ipy=py8C6Mgw@mail.gmail.com>
In-Reply-To: <CAEBZRSfG053_DYA6BCZUjg6c4oa3AHDsK5Puc4ipy=py8C6Mgw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <6638594D1C718142A09823A8F185AB7E@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, George Dunlap <dunlapg@umich.edu>,
 Wei Liu <wl@xen.org>, Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDIzLCAyMDIwLCBhdCA1OjAzIFBNLCBOaWNrIFJvc2Jyb29rIDxyb3Nicm9v
a25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIFRodSwgQXByIDIzLCAyMDIwIGF0IDk6NDQg
QU0gR2VvcmdlIER1bmxhcCA8ZHVubGFwZ0B1bWljaC5lZHU+IHdyb3RlOg0KPj4gDQo+PiANCj4+
IA0KPj4gT24gVGh1LCBBcHIgMjMsIDIwMjAgYXQgMTo1MSBBTSBOaWNrIFJvc2Jyb29rIDxyb3Ni
cm9va25AZ21haWwuY29tPiB3cm90ZToNCj4+PiANCj4+PiBCeSBkZWZhdWx0LCBpZiB0aGUgZ28g
Y29tcGlsZXIgaXMgZm91bmQgYnkgdGhlIGNvbmZpZ3VyZSBzY3JpcHQsIGJ1aWxkDQo+Pj4gdGhl
IGdvbGFuZyB0b29scy4gSWYgdGhlIGNvbXBpbGVyIGlzIG5vdCBmb3VuZCwgYW5kDQo+Pj4gLS1l
bmFibGUtZ29sYW5nX3Rvb2xzIHdhcyBub3QgZXhwbGljaXRseSBzZXQsIGRvIG5vdCBidWlsZCB0
byB0aGUgZ29sYW5nDQo+Pj4gdG9vbHMuDQo+Pj4gDQo+Pj4gVGhlIG5ldyBjb3JyZXNwb25kaW5n
IG1ha2UgdmFyaWFibGUgaXMgQ09ORklHX0dPTEFOR19UT09MUy4gUmVtb3ZlDQo+Pj4gQ09ORklH
X0dPTEFORyBmcm9tIHRvb2xzL1J1bGVzLm1rIHNpbmNlIHRoZSBuZXcgdmFyaWFibGUgaXMgc2V0
IGJ5DQo+Pj4gY29uZmlndXJlLg0KPj4+IA0KPj4+IFNpZ25lZC1vZmYtYnk6IE5pY2sgUm9zYnJv
b2sgPHJvc2Jyb29rbkBhaW5mb3NlYy5jb20+DQo+Pj4gLS0tDQo+Pj4gY29uZmlnL1Rvb2xzLm1r
LmluIHwgICAxICsNCj4+PiBtNC9nb2xhbmcubTQgICAgICAgfCAgIDQgKysNCj4+PiB0b29scy9N
YWtlZmlsZSAgICAgfCAgIDIgKy0NCj4+PiB0b29scy9SdWxlcy5tayAgICAgfCAgIDIgLQ0KPj4+
IHRvb2xzL2NvbmZpZ3VyZSAgICB8IDEzOCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysNCj4+PiB0b29scy9jb25maWd1cmUuYWMgfCAgMTIgKysrKw0KPj4+IDYg
ZmlsZXMgY2hhbmdlZCwgMTU2IGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pDQo+Pj4gY3Jl
YXRlIG1vZGUgMTAwNjQ0IG00L2dvbGFuZy5tNA0KPj4+IA0KPj4+IGRpZmYgLS1naXQgYS9jb25m
aWcvVG9vbHMubWsuaW4gYi9jb25maWcvVG9vbHMubWsuaW4NCj4+PiBpbmRleCAxODlmZGExNTk2
Li4yYzIxOWY1NDc3IDEwMDY0NA0KPj4+IC0tLSBhL2NvbmZpZy9Ub29scy5tay5pbg0KPj4+ICsr
KyBiL2NvbmZpZy9Ub29scy5tay5pbg0KPj4+IEBAIC01NSw2ICs1NSw3IEBAIENPTkZJR19RRU1V
X1RSQUQgICAgOj0gQHFlbXVfdHJhZGl0aW9uYWxADQo+Pj4gQ09ORklHX1FFTVVfWEVOICAgICA6
PSBAcWVtdV94ZW5ADQo+Pj4gQ09ORklHX1FFTVVVX0VYVFJBX0FSR1M6PSBARVhUUkFfUUVNVVVf
Q09ORklHVVJFX0FSR1NADQo+Pj4gQ09ORklHX0xJQk5MICAgICAgICA6PSBAbGlibmxADQo+Pj4g
K0NPTkZJR19HT0xBTkdfVE9PTFMgOj0gQGdvbGFuZ190b29sc0ANCj4+PiANCj4+PiBDT05GSUdf
U1lTVEVNRCAgICAgIDo9IEBzeXN0ZW1kQA0KPj4+IFNZU1RFTURfQ0ZMQUdTICAgICAgOj0gQFNZ
U1RFTURfQ0ZMQUdTQA0KPj4+IGRpZmYgLS1naXQgYS9tNC9nb2xhbmcubTQgYi9tNC9nb2xhbmcu
bTQNCj4+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4+IGluZGV4IDAwMDAwMDAwMDAuLjBiNGJk
NTRjZTANCj4+PiAtLS0gL2Rldi9udWxsDQo+Pj4gKysrIGIvbTQvZ29sYW5nLm00DQo+Pj4gQEAg
LTAsMCArMSw0IEBADQo+Pj4gK0FDX0RFRlVOKFtBQ19QUk9HX0dPXSwgWw0KPj4+ICsgICAgZG5s
IENoZWNrIGZvciB0aGUgZ28gY29tcGlsZXINCj4+PiArICAgIEFDX0NIRUNLX1RPT0woW0dPXSxb
Z29dLFtub10pDQo+Pj4gK10pDQo+PiANCj4+IA0KPj4gQUZBSUNUIHRoaXMgb25seSBjaGVja3Mg
Zm9yIHRoZSBleGlzdGVuY2Ugb2YgdGhlIGJpbmFyeS4gIFdpbGwgdGhlIGJpbmRpbmdzIGNvbXBp
bGUgd2l0aCBhbGwgdmVyc2lvbnMgb2YgZ28/ICBJZiBub3QsIHNob3VsZCB3ZSB0cnkgdG8gY2hl
Y2sgdGhlIHZlcnNpb24gaGVyZT8NCj4gDQo+IFRoZXJlIGFyZSBubyBvYnZpb3VzIHBpZWNlcyB0
byBtZSB0aGF0IHdvbid0IGNvbXBpbGUgb24gZmFpcmx5IHJlY2VudA0KPiAoaS5lLiA+PSAxLjkp
IHZlcnNpb25zIG9mIGdvLCBidXQgeWVzIGl0IHdvdWxkIHByb2JhYmx5IGJlIGJlc3QgdG8NCj4g
Y2hlY2sgZm9yIGEgbWluaW11bSB2ZXJzaW9uLiBJIHdpbGwgZG8gc29tZSBtb3JlIHdvcmsgdG8g
ZmlndXJlIG91dCBhbg0KPiBhcHByb3ByaWF0ZSBtaW5pbXVtIHZlcnNpb24sIGJ1dCBJIHRoaW5r
IGdvIDEuMTAgbWlnaHQgYmUgYSByZWFzb25hYmxlDQo+IHN0YXJ0Lg0KDQpPSyDigJQgSSBkaWRu
4oCZdCBtZWFuIHlvdSBoYWQgdG87IEkganVzdCB0aG91Z2h0IGl0IHdhcyB3b3J0aCBicmluZ2lu
ZyB1cC4NCg0KVGhlIHVuZGVyc2NvcmUgdGhpbmcgdGhvdWdoIOKAlCBJIHRoaW5rIGl04oCZcyBh
IGJhZCBpZGVhIHRvIG1peCBgLWAgYW5kIGBfYDsg4oCUZW5hYmxlLWdvbGFuZ190b29scyBqdXN0
IGlzbuKAmXQgYSBnb29kIGlkZWEgSU1ITy4gOi0pDQoNCkRvIHlvdSBuZWVkIF90b29scz8gIENv
dWxkIGl0IGp1c3QgYmUg4oCUZW5hYmxlLWdvbGFuZz8NCg0KIC1HZW9yZ2U=


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 17:36:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 17:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRflS-00078P-1G; Thu, 23 Apr 2020 17:35:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=RhWH=6H=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jRflQ-00078K-Ni
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 17:35:52 +0000
X-Inumbo-ID: e0693716-8588-11ea-83d8-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e0693716-8588-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 17:35:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587663351;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=hcrx54si1rP3klgGMuSpmaJgdgqT335TlXkHTCBtI44=;
 b=D5AkQPim3vBhK5YJodBZw/XPJfYH5UxPJOLcOT54xgLzdeZvTWGGzmch
 GKLtO5iMUKOTCZJGDIIP5FPJNkA5J+Bl/IELDThoq5KyISnXe9gi2ojzL
 LF7eXezPJOyyF90hIKCEIqKVDQo5b3Bv7qwSYvBXaCGFzEuroLn9mNyKZ Q=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: helxfy8Jukvfpu2b7IsmhUG4IWszMFTMosjF2VRQj4AtkrwFKrBjJbQP2GHZrZUzR1prH8X5Tb
 9Fvl+u+rkvLp+6FuwDJy7OJ7NB84autrOW/0g/S5I6KcdWg9coC9fQbIX2xKTF6SPmtxrM2crP
 jj2eS1lSGiB3NPueYPT837TQX/Sdv80ROgZltsGhC/6mw4UOVlvSB2eCcfVxwPJ3yk45NDzSzF
 I6aunwkzhPhbkGfXUaNkbpliy2e7in9bvLYt4eve1sGUBgr54hMl8VASSxXaUfM0bCuuycN7ZN
 its=
X-SBRS: 2.7
X-MesageID: 16463880
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16463880"
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
To: Jan Beulich <jbeulich@suse.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
 <5dc9dbd9-fbeb-46ef-4d4e-7916c3219bb3@suse.com>
 <4e732f90-1d5f-7ae5-0f02-6b313a381df7@citrix.com>
 <6b4e5b50-51f7-566f-2a18-4bb5f4f43d59@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <62b51cff-4d6f-690b-371a-e6772ea327ab@citrix.com>
Date: Thu, 23 Apr 2020 18:35:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <6b4e5b50-51f7-566f-2a18-4bb5f4f43d59@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21/04/2020 07:02, Jan Beulich wrote:
> On 20.04.2020 20:05, Andrew Cooper wrote:
>> On 20/04/2020 15:05, Jan Beulich wrote:
>>> I'm in particular
>>> concerned that we may gain a large number of such printk()s over
>>> time, if we added them in such cases.
>> The printk() was a bit of an afterthought, but deliberately avoiding the
>> -EINVAL path was specifically not.
>>
>> In the case that the user tries to use `pv=no-32` without CONFIG_PV32,
>> they should see something other than
>>
>> (XEN) parameter "pv=no-32" unknown!
> Why - to this specific build of Xen the parameter is unknown.

Because it is unnecessarily problematic and borderline obnoxious to
users, as well as occasional Xen developers.

"you've not got the correct CONFIG_$X for that to be meaningful" is
specifically useful to separate from "I've got no idea".

>> I don't think overloading the return value is a clever move, because
>> then every parse function has to take care of ensuring that -EOPNOTSUPP
>> (or ENODEV?) never clobbers -EINVAL.
> I didn't suggest overloading the return value. Instead I
> specifically want this to go the -EINVAL path.
>
>> We could have a generic helper which looks like:
>>
>> static inline void ignored_param(const char *cfg, const char *name,
>> const char *s, const char *ss)
>> {
>>     printk(XENLOG_INFO "%s disabled - ignoring '%s=%*.s' setting\n",
>> cfg, name, s, (int)(ss - s));
>> }
>>
>> which at least would keep all the users consistent.
> Further bloating the binary with (almost) useless string literals.
> I'd specifically like to avoid this.

I don't accept that as a valid argument.

We're talking about literally tens of bytes (which will merge anyway, so
0 in practice), and a resulting UI which helps people get out of
problems rather than penalises them for having gotten into a problem to
begin with.

I will absolutely prioritise a more helpful UI over a handful of bytes.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 17:36:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 17:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRfm3-0007Az-Ah; Thu, 23 Apr 2020 17:36:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XA1d=6H=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRfm1-0007At-Vo
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 17:36:30 +0000
X-Inumbo-ID: f6973e02-8588-11ea-b58d-bc764e2007e4
Received: from mail-lj1-x244.google.com (unknown [2a00:1450:4864:20::244])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f6973e02-8588-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 17:36:29 +0000 (UTC)
Received: by mail-lj1-x244.google.com with SMTP id n6so7064140ljg.12
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 10:36:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=txrokkw3h+LyHqizXSi9SF+rKElJZ0O1ZuJ3YLvcGg4=;
 b=kX27mxiH3nzFfLzAQZcB5ccSqR78tFBRkTWKE7LXTXQafGMgccqD6bIr5a52cK6jVP
 V1iG3iB9Y5UV15vuS09mImGJCpRd9EvgM6Y7ZrXySlRsFfea3XS4biNDkglwLsRzLFNe
 A4/3Hb/RKLVRWtbfPl0Oa5Cb+ULDIqDu+ZiIgMFSvFUXkcKvoJ+8lJ1HZNbZakC6mZbK
 hyRh9hF+1pGDlT71bXlb1t5+L5s2lLg2E6n9Yjvqbky6MS1OLsCuPYK2HVVZLB5e/BtZ
 07pCpvs+5JjcpOUCBfA6hnSiSUTJh0m0TWro/AVnsIMRQhUuMX6nTHSSF4+h9trDN7Wj
 m3Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=txrokkw3h+LyHqizXSi9SF+rKElJZ0O1ZuJ3YLvcGg4=;
 b=kZkXObWuGrWP8LPg2unKCYuR6rKaeNfxmptu9N4Fkl5levVTqOnJ+NC4oNaq2e2PZ4
 9yRgoYEFYvW1ZiExqPCWQJ8+KWXIS5ghwzJ0Vnm41J5LhZLFUT2VS/lliOpho2k4+aCe
 R1CJAoeTXADSSHFdKvT7XuV31MVaJamMjpR2Vrl0iLeOk2QzeWgArAgt0MseCNwPOTqe
 Msq/g6scNaNB+fooeNisV9NiNqSySnRs7h/UBQw2XFurBCQuBzAbg8kEA1LCGLKTeM4L
 8tn+7gyKaXYj2nTnBpBxUSBgsCdD9t7n/IAN6Jkcfds9cW3jqcqEGTdHYP8sZm+U3dU3
 F4ug==
X-Gm-Message-State: AGi0Pubh8OTdK7ktYjsCiwRhUQqCBhViz25QoeGeWZg9MNV3PPtBXb1F
 eXMSfOn4qEC75i6Q/zVxZoWigdQ9uPmECBWbEys=
X-Google-Smtp-Source: APiQypL6hcTs8h/vQvmoYpK9thpWsxk9QuiUjxmQP/OJSalslrj0esN2fvolzEr7s1QzkhydsRz1mCQ11VzXTAVIujM=
X-Received: by 2002:a2e:9a82:: with SMTP id p2mr3038418lji.279.1587663388262; 
 Thu, 23 Apr 2020 10:36:28 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <c2d966b43313c9df64551b0ce31462c176445b70.1587599095.git.rosbrookn@ainfosec.com>
 <CAFLBxZaKiuqpmVvP2ww9YbuTkCm9wdBKGdMJOrT=sTaJSaycqg@mail.gmail.com>
 <CAEBZRSfG053_DYA6BCZUjg6c4oa3AHDsK5Puc4ipy=py8C6Mgw@mail.gmail.com>
 <E0E74128-3E4E-44C7-976D-098CBADF4C5D@citrix.com>
In-Reply-To: <E0E74128-3E4E-44C7-976D-098CBADF4C5D@citrix.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Thu, 23 Apr 2020 13:36:16 -0400
Message-ID: <CAEBZRSfX5DUECxgRqXzPk4=t-MoGRSrCJ_sXTc=ffG1aoGhNUg@mail.gmail.com>
Subject: Re: [PATCH 1/2] tools: build golang tools if go compiler is present
To: George Dunlap <George.Dunlap@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, George Dunlap <dunlapg@umich.edu>,
 Wei Liu <wl@xen.org>, Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> The underscore thing though =E2=80=94 I think it=E2=80=99s a bad idea to =
mix `-` and `_`; =E2=80=94enable-golang_tools just isn=E2=80=99t a good ide=
a IMHO. :-)
>
> Do you need _tools?  Could it just be =E2=80=94enable-golang?

I agree, I don't like mixing the '-' and '_'. From what I could tell,
that was how the other options were named in tools/configure.ac and
Tools.mk.in (unless I missed a way to tell the --enable flag to just
use '-'), so I went with that. I can just do --enable-golang, but I
was trying to make it a bit more descriptive if possible.

-NR


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 18:19:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 18:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRgRJ-0002En-Fc; Thu, 23 Apr 2020 18:19:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRgRI-0002Ei-Hj
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 18:19:08 +0000
X-Inumbo-ID: e76ccf2c-858e-11ea-93ec-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e76ccf2c-858e-11ea-93ec-12813bfff9fa;
 Thu, 23 Apr 2020 18:19:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=fRrrpyhUu7D8FU4vfcEaOX1N/2rxRtQoCxY4akLybB8=; b=tiw3qXK+OTYZ8krZ/FZzuiOgg
 QtXRKmoh8iuZH94XSs6NtboIOyuyyNBU2bWL5PweD/dazDFGFsnWqNZudyBK6014u4QNyx9h1rQwk
 FpNjyuwIDlHC9vqcPbjuUJmNECkeIqbW52GJUOFbBTp52i+ErpNGzoD+esSHwdWQb+YGY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRgRA-0002VY-0G; Thu, 23 Apr 2020 18:19:00 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRgR9-0003pN-GB; Thu, 23 Apr 2020 18:18:59 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRgR9-0006Ps-FH; Thu, 23 Apr 2020 18:18:59 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149749-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149749: tolerable trouble: fail/pass/starved - PUSHED
X-Osstest-Failures: linux-5.4:test-amd64-amd64-xl-rtds:guest-saverestore:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 linux-5.4:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: linux=0c418786cb3aa175823f0172d939679df9ab9a54
X-Osstest-Versions-That: linux=6ccc74c083c0d472ac64f3733f5b7bf3f99f261e
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 18:18:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149749 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149749/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     15 guest-saverestore            fail  like 149709
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat    fail  like 149728
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate               starved  n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate               starved  n/a

version targeted for testing:
 linux                0c418786cb3aa175823f0172d939679df9ab9a54
baseline version:
 linux                6ccc74c083c0d472ac64f3733f5b7bf3f99f261e

Last test of basis   149728  2020-04-22 00:08:28 Z    1 days
Testing same since   149749  2020-04-23 09:09:13 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Adrian Huang <ahuang12@lenovo.com>
  Alan Maguire <alan.maguire@oracle.com>
  Alex Deucher <alexander.deucher@amd.com>
  Alexander Gordeev <agordeev@linux.ibm.com>
  Alexandre Belloni <alexandre.belloni@bootlin.com>
  Alexei Starovoitov <ast@kernel.org>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andrew Morton <akpm@linux-foundation.org>
  Andrii Nakryiko <andriin@fb.com>
  Anton Ivanov <anton.ivanov@cambridgegreys.com>
  Aya Levin <ayal@mellanox.com>
  Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
  Baruch Siach <baruch@tkos.co.il>
  Ben Skeggs <bskeggs@redhat.com>
  Björn Töpel <bjorn.topel@intel.com>
  Bob Moore <robert.moore@intel.com>
  Borislav Petkov <bp@suse.de>
  Chao Yu <yuchao0@huawei.com>
  Chen-Yu Tsai <wens@csie.org>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian König <christian.koenig@amd.com>
  Christoph Hellwig <hch@lst.de>
  Christophe Kerello <christophe.kerello@st.com>
  Christophe Leroy <christophe.leroy@c-s.fr>
  Chuck Lever <chuck.lever@oracle.com>
  cki-project@redhat.com
  Claudiu Beznea <claudiu.beznea@microchip.com>
  Dan Carpenter <dan.carpenter@oracle.com>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Borkmann <daniel@iogearbox.net>
  Darrick J. Wong <darrick.wong@oracle.com>
  David Hildenbrand <david@redhat.com>
  David Howells <dhowells@redhat.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.com>
  Dmitry Osipenko <digetx@gmail.com>
  Domenico Andreoli <domenico.andreoli@linux.com>
  Douglas Gilbert <dgilbert@interlog.com>
  Eric Sandeen <sandeen@redhat.com>
  Erik Kaneda <erik.kaneda@intel.com>
  Florian Fainelli <f.fainelli@gmail.com>
  Frank Rowand <frank.rowand@sony.com>
  Frieder Schrempf <frieder.schrempf@kontron.de>
  Gabriel Krisman Bertazi <krisman@collabora.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Gregory CLEMENT <gregory.clement@bootlin.com>
  Grygorii Strashko <grygorii.strashko@ti.com>
  Guenter Roeck <linux@roeck-us.net>
  Guillaume Champagne <champagne.guillaume.c@gmail.com>
  Guo Ren <guoren@linux.alibaba.com>
  Heiko Carstens <heiko.carstens@de.ibm.com>
  Heiko Stuebner <heiko@sntech.de>
  Ilya Dryomov <idryomov@gmail.com>
  Jacek Anaszewski <jacek.anaszewski@gmail.com>
  Jack Zhang <Jack.Zhang1@amd.com>
  Jacob Pan <jacob.jun.pan@linux.intel.com>
  Jaegeuk Kim <jaegeuk@kernel.org>
  Jan Kara <jack@suse.cz>
  Jean-Philippe Brucker <jean-philippe@linaro.org>
  Jeffery Miller <jmiller@neverware.com>
  Jens Axboe <axboe@kernel.dk>
  Jernej Skrabec <jernej.skrabec@siol.net>
  Jerome Brunet <jbrunet@baylibre.com>
  Joerg Roedel <jroedel@suse.de>
  Johan Jonker <jbx6244@gmail.com>
  John Fastabend <john.fastabend@gmail.com>
  Jon Hunter <jonathanh@nvidia.com>
  Jonathan Cameron <Jonathan.Cameron@huawei.com>
  Jonathan Corbet <corbet@lwn.net>
  Jonathan Lemon <jonathan.lemon@gmail.com>
  Jonathan Neuschäfer <j.neuschaefer@gmx.net>
  Josh Poimboeuf <jpoimboe@redhat.com>
  Karol Herbst <kherbst@redhat.com>
  Kevin Grandemange <kevin.grandemange@allegrodvt.com>
  Kishon Vijay Abraham I <kishon@ti.com>
  KP Singh <kpsingh@google.com>
  Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
  Laurentiu Tudor <laurentiu.tudor@nxp.com>
  Li Bin <huawei.libin@huawei.com>
  Li RongQing <lirongqing@baidu.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Yi L <yi.l.liu@intel.com>
  Long Li <longli@microsoft.com>
  Lu Baolu <baolu.lu@linux.intel.com>
  Lucas Stach <l.stach@pengutronix.de>
  Luke Nelson <luke.r.nels@gmail.com>
  Luke Nelson <lukenels@cs.washington.edu>
  Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
  Magnus Karlsson <magnus.karlsson@intel.com>
  Marc Zyngier <maz@kernel.org>
  Marco Elver <elver@google.com>
  Martin Fuzzey <martin.fuzzey@flowbird.group>
  Martin K. Petersen <martin.petersen@oracle.com>
  Maxime Ripard <maxime@cerno.tech>
  Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael Walle <michael@walle.cc>
  Miquel Raynal <miquel.raynal@bootlin.com>
  Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
  Murphy Zhou <jencce.kernel@gmail.com>
  Nathan Chancellor <natechancellor@gmail.com>
  Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
  Nirmoy Das <nirmoy.das@amd.com>
  Olga Kornievskaia <kolga@netapp.com>
  Olga Kornievskaia <olga.kornievskaia@gmail.com>
  Pablo Neira Ayuso <pablo@netfilter.org>
  Paolo Valente <paolo.valente@linaro.org>
  Paul E. McKenney <paulmck@kernel.org>
  Paul Mackerras <paulus@ozlabs.org>
  Pavel Machek <pavel@ucw.cz>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Qian Cai <cai@lca.pw>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Ralph Campbell <rcampbell@nvidia.com>
  Randy Dunlap <rdunlap@infradead.org>
  Ricardo Ribalda Delgado <ribalda@kernel.org>
  Richard Weinberger <richard@nod.at>
  Rob Herring <robh@kernel.org>
  Roman Gushchin <guro@fb.com>
  Russell King <rmk+kernel@armlinux.org.uk>
  Saeed Mahameed <saeedm@mellanox.com>
  Sahitya Tummala <stummala@codeaurora.org>
  Sasha Levin <sashal@kernel.org>
  Sebastian Reichel <sebastian.reichel@collabora.com>
  Shawn Guo <shawnguo@kernel.org>
  Slava Bacherikov <slava@bacher09.org>
  Sowjanya Komatineni <skomatineni@nvidia.com>
  Stephen Boyd <sboyd@kernel.org>
  Stephen Rothwell <sfr@canb.auug.org.au>
  Steve French <stfrench@microsoft.com>
  Steven Price <steven.price@arm.com>
  Takashi Iwai <tiwai@suse.de>
  Theodore Ts'o <tytso@mit.edu>
  Thierry Reding <treding@nvidia.com>
  Thomas Richter <tmricht@linux.ibm.com>
  Tianyu Lan <Tianyu.Lan@microsoft.com>
  Trond Myklebust <trond.myklebust@hammerspace.com>
  Vasily Gorbik <gor@linux.ibm.com>
  Vegard Nossum <vegard.nossum@oracle.com>
  Vidya Sagar <vidyas@nvidia.com>
  Waiman Long <longman@redhat.com>
  Wei Liu <wei.liu@kernel.org>
  Wen Yang <wenyang@linux.alibaba.com>
  Will Deacon <will@kernel.org>
  Wim Van Sebroeck <wim@linux-watchdog.org>
  Xi Wang <xi.wang@gmail.com>
  xinhui pan <xinhui.pan@amd.com>
  Zenghui Yu <yuzenghui@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                starved 
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 starved 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   6ccc74c083c0..0c418786cb3a  0c418786cb3aa175823f0172d939679df9ab9a54 -> tested/linux-5.4


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 18:24:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 18:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRgWq-00033t-8F; Thu, 23 Apr 2020 18:24:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=RhWH=6H=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jRgWo-00033o-SU
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 18:24:50 +0000
X-Inumbo-ID: b79bb30c-858f-11ea-b4f4-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b79bb30c-858f-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 18:24:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587666289;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=ZuRPvzP5RhQQj1vPpkgmGQcC/jvY/fJcAxuR7XGimWY=;
 b=CKnj5y+ZGWIpOARsD2CWO30ooIg/eb0oVYEi7TTt1ZrM+aOQj8lGsJAP
 OXObOPpxJ4dhGMNeLVQAicyEPpqMJo+bhNKpp2wSbbDXpqjQVCNu8jbDa
 iby/fWlFcQxfflLYTaWM6mQvE79/wQmo+K/KVW6KYbsvnmQ73+8q+LDLY U=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Oy3YT2v5iaX1icqMggkX0F81kutOMdVNB+pKUOJXDGRofviPmU3r3zHo7Mqz7+QcsBZXYvEfhm
 ZW3Ejix3Ol0aEXmwECU+wQhkXxpSbkq0zf/FKUUoD2RnY9XfEppbYVVryh1BN1qQMikNWP7Z3q
 aV4TUtsAgdLTtubludoWIlp1YOdbuv2VgqBccvx+ILUIwQ1nilfp6nXcridXxOZveFJSd4k4Fk
 slCFeaeVTCAdA9sDH3cBn/nLa/6G8z+4KdQUeKqVWfcZifvVsviHcdM3/pr2+oew/vf7aD9/U7
 iLE=
X-SBRS: 2.7
X-MesageID: 16466474
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16466474"
Subject: Re: [PATCH 1/3] x86/S3: Use percpu_traps_init() rather than
 opencoding SYSCALL/SYSENTER restoration
To: Jan Beulich <jbeulich@suse.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
 <20200420145911.5708-2-andrew.cooper3@citrix.com>
 <db70738a-4750-2780-2f44-b0bcd3a5f93b@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <4ff5227c-a9a4-f6cc-2068-ddd41165ebaf@citrix.com>
Date: Thu, 23 Apr 2020 19:24:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <db70738a-4750-2780-2f44-b0bcd3a5f93b@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21/04/2020 08:24, Jan Beulich wrote:
> On 20.04.2020 16:59, Andrew Cooper wrote:
>> @@ -46,24 +36,13 @@ void restore_rest_processor_state(void)
>>      /* Restore full CR4 (inc MCE) now that the IDT is in place. */
>>      write_cr4(mmu_cr4_features);
>>  
>> -    /* Recover syscall MSRs */
>> -    wrmsrl(MSR_LSTAR, saved_lstar);
>> -    wrmsrl(MSR_CSTAR, saved_cstar);
>> -    wrmsrl(MSR_STAR, XEN_MSR_STAR);
>> -    wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
>> +    /* (re)initialise SYSCALL/SYSENTER state, amongst other things. */
>> +    percpu_traps_init();
> Without tweaks to subarch_percpu_traps_init() this assumes that,
> now and going forward, map_domain_page() will work reliably at
> this early point of resume. I'm not opposed, i.e.
> Acked-by: Jan Beulich <jbeulich@suse.com>

I think this reasonable to expect, and robust going forward.

We are properly in d[IDLE]v0 context when it comes to pagetables, and
there is nothing interesting between this point and coming fully back
online.

That said, I could easily move the call to later in the resume path for
even more certainty.

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 3ad7dfc9a3..d5a468eddd 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -297,6 +297,8 @@ static int enter_state(u32 state)
     ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);
     spec_ctrl_exit_idle(ci);
 
+    /* (re)initialise SYSCALL/SYSENTER state, amongst other things. */
+    percpu_traps_init();
+
  done:
     spin_debug_enable();
     local_irq_restore(flags);

In fact - I prefer this, because it works towards one low priority goal
of deleting {save,restore}_rest_processor_state() which I've still got a
pending series for.

Would your ack still stand if I tweak the patch in this way?

> but it would feel less fragile if the redundant re-writing of
> the stubs would be skipped in the BSP resume case (I didn't
> check whether it's also redundant for APs, but I suspect it's
> not, as the stub pages may get allocated anew).

I don't really agree.  Symmetry (even if it is expected to be redundant)
is much more easy to reason about in terms of robustness.  S3 is not a
fastpath.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 18:49:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 18:49:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRguh-0004oz-9B; Thu, 23 Apr 2020 18:49:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=RhWH=6H=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jRgug-0004ou-9s
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 18:49:30 +0000
X-Inumbo-ID: 28c4a1b3-8593-11ea-93f5-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 28c4a1b3-8593-11ea-93f5-12813bfff9fa;
 Thu, 23 Apr 2020 18:49:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587667768;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=kk5X5yCTAXbomXGohlK0iF7kF+m+7o5Mk6x6xfWmjXk=;
 b=DsgbpK2pCsgR8wnkdgFT8iSG07oDVow4gGN8HXCAwCOzADXrTM1/sUXQ
 vxWip3OuuA1ZDnR6wY1/qK6nNYwo6MlAgYXtc6LtYdpNdqpEjfNkFjOSP
 3jtOt0VIOJvR1cqHeXJzbVXOqJ8W3EbAiCpU6QPwV6baBQRPnN5ghpI6E 4=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: VfkqWQa4mK5hwnHpwUYKZ9m2V1rQyzHWF3XMO5LpZS8R40/GN4bu21d32urIPGLrbpMrVvgclZ
 NEzLkzg07utyMySx3YTkjBYp/MS+989Lzx61CXAzO5xXk0FcHVFGum6kDvuKEGtN4V7/p1uwE7
 SXwxpC4UrEd2PEsosZaobcnAA0r7xKEn0GrWAJcr53HWEdbfhFuFwFua4O1xQX9pXKOYJjx60G
 8K/uV8v1soaxQjyGf+gVqOj4OXCJaoz7hpraSCrcOSJfiQC5lHFWoXrc40OgiQ0HfBKVBPDNNX
 rHk=
X-SBRS: 2.7
X-MesageID: 16836228
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="16836228"
Subject: Re: [PATCH 3/3] x86/pv: Don't use IST for NMI/#MC/#DB in !CONFIG_PV
 builds
To: Jan Beulich <jbeulich@suse.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
 <20200420145911.5708-4-andrew.cooper3@citrix.com>
 <08a798db-3126-7ccd-17f3-476607cc9e45@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <76fa899a-2b35-8ea9-159e-c9e3dcf88f53@citrix.com>
Date: Thu, 23 Apr 2020 19:49:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <08a798db-3126-7ccd-17f3-476607cc9e45@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21/04/2020 08:48, Jan Beulich wrote:
> On 20.04.2020 16:59, Andrew Cooper wrote:
>> --- a/xen/include/asm-x86/processor.h
>> +++ b/xen/include/asm-x86/processor.h
>> @@ -441,12 +441,18 @@ struct tss_page {
>>  };
>>  DECLARE_PER_CPU(struct tss_page, tss_page);
>>  
>> +/*
>> + * Interrupt Stack Tables.  Used to force a stack switch on a CPL0=>0
>> + * interrupt/exception.  #DF uses IST all the time to detect stack overflows
>> + * cleanly.  NMI/#MC/#DB only need IST to cover the SYSCALL gap, and therefore
>> + * only necessary with PV guests.
>> + */
> Is it really only the SYSCALL gap that we mean to cover? In particular
> for #MC I'd suspect it is a good idea to switch stacks as well, to get
> onto a distinct memory page in case the #MC was stack related.

If #MC occurs on your stack, you have already lost.  The chances of only
taking a single #MC are tiny because the next-line prefetcher will be
doing its job (or it hits when the lines (plural) leave L3, which will
be in guest context at some point in the future.)

The very best you can hope for is to cleanly print something and crash -
even if you manage to run the handler, you've got no idea if the
interrupted context had a spinlock held, and Xen has no support for
changing to a different pcpu stack.

> With NMI it might as well be better to switch;

Why?  There is no benefit (with no SYSCALL in the picture), and a
downside which causes state loss.

>  I agree we don't need any
> switching for #DB.
>
> I also think that the comment at the top of current.h would want
> updating with these adjustments (which I notice lacks the #DB part
> anyway).

Oops - I totally forgot that for the XSA-260 fix.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 18:51:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 18:51:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRgw8-0005Y7-LR; Thu, 23 Apr 2020 18:51:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRgw7-0005Xz-5i
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 18:50:59 +0000
X-Inumbo-ID: 5ba41c3e-8593-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5ba41c3e-8593-11ea-b58d-bc764e2007e4;
 Thu, 23 Apr 2020 18:50:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=r+td17p8AWdbWNwXmn6Gqig3VIyptVdXSvN2Vg3zKzo=; b=llnfGcl5iuO53pAhJIKaXoic0
 tECVf7AL6/TWiCUMS7KVwkNnAzETqq5+o8HxCQ0FprEtxwwFqBDlIb4NZpUZLbT6fNi8b7zeKwHSS
 Ietz7d9+TtP7cjhrDj+PHjzJ9e8eruI6c+MaqRMcLfFRIVqfssBRjJMgpAaUVwX1Ckack=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRgw1-00038s-3q; Thu, 23 Apr 2020 18:50:53 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRgw0-00059o-QU; Thu, 23 Apr 2020 18:50:52 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRgw0-0001Je-Pp; Thu, 23 Apr 2020 18:50:52 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149769-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149769: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=aa14feb6723d3bb15a884533ade1cd9732792145
X-Osstest-Versions-That: xen=f9e707aa97b204229dde5125116364c9e410ef67
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 18:50:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149769 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149769/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  aa14feb6723d3bb15a884533ade1cd9732792145
baseline version:
 xen                  f9e707aa97b204229dde5125116364c9e410ef67

Last test of basis   149760  2020-04-23 12:01:07 Z    0 days
Testing same since   149769  2020-04-23 16:00:35 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@citrix.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f9e707aa97..aa14feb672  aa14feb6723d3bb15a884533ade1cd9732792145 -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 21:14:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 21:14:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRjB0-0000BX-9L; Thu, 23 Apr 2020 21:14:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=VVSQ=6H=gmail.com=neilsikka@srs-us1.protection.inumbo.net>)
 id 1jRjAz-0000BS-1g
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 21:14:29 +0000
X-Inumbo-ID: 6a27299a-85a7-11ea-b4f4-bc764e2007e4
Received: from mail-ed1-x52b.google.com (unknown [2a00:1450:4864:20::52b])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6a27299a-85a7-11ea-b4f4-bc764e2007e4;
 Thu, 23 Apr 2020 21:14:28 +0000 (UTC)
Received: by mail-ed1-x52b.google.com with SMTP id k22so5520897eds.6
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 14:14:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=tXogdIWucxrZKQeHtyCyKncNdg3MNzcQRHWcSlK+7OE=;
 b=m6v+tFHced7sylqDQ87Z/7XPP4yyiAT/ZiH35yQ0UytEBqk4A0/6yHzFXRuOJF2HYe
 3yeOpTq0UeCTFNtTMkCBhi+TypgLznTImWIeSawHDOWbTMo46M3Cdoelj2+Qb+B8QuRW
 lh4BP2BAE9jWsPTrT0r9VSqdqJyuaGQaAW387E/bmmfyXcnT/97SGb8AtHFNMKD0LVDh
 fkbfScH15/krbYFr3YOKt8/0ytU3r1caNGBMoOTo+K5rC99MBFjXuiUWHsE7DmvcVv5f
 AWf/kKjeoHUpR8gtanS+AMoScAMtODv2y+QwPoupvWtTUccH0mnA2xmbRkiZaeM1UGWK
 8wiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=tXogdIWucxrZKQeHtyCyKncNdg3MNzcQRHWcSlK+7OE=;
 b=FeA+wa1ezgClSm5GA/rbNjlsN5GQ5tEGJ6Ay10QoThfXx7z/GFSKw2SuqvFIr/j59+
 AvKAjjeOl6jxks0iGYmYDqUmzrMKEql7fvGG6NdhM1MlIj9WeN0+rsnV/BMYtfsh6j/Q
 leYHxzMXpvGhGnDHH9EYbvM/vHwq3B0eM/dggTLFDcxX+/eh9qft0IMTpKIrV9BU2jwm
 xj9wDgGMwkG6aIWGiaTs6Ruq+BoK0Dd9llB4XVHYvvIhUd3bRpfcqx0P8QL6/TQoBgku
 ubgTGXDWQunUbIwaaaBlWR2hN0U2hpkp5Zx9LBplZaMo48FcEJCBC7U9miO/eK0diKNs
 UaDg==
X-Gm-Message-State: AGi0PuZh8aw0Vpa23HenXIiNmZ9YvIa7769pYL3Qi6eWawOdP+5zJy9b
 +M3pwJ8h+sfs4mxx1mC+XUL8K38GGkeHarCON3s/z5+Pl30=
X-Google-Smtp-Source: APiQypIJLatPtdgm7ZCWwvQKyrrHr3rfoBDhTdg1i5mXjj0x7m8lTTqcWAruJ+7PNclBRSBkvBh6XA2TBD3kG47dNtU=
X-Received: by 2002:aa7:d4c3:: with SMTP id t3mr4375726edr.191.1587676466771; 
 Thu, 23 Apr 2020 14:14:26 -0700 (PDT)
MIME-Version: 1.0
From: Neil Sikka <neilsikka@gmail.com>
Date: Thu, 23 Apr 2020 17:14:15 -0400
Message-ID: <CAHPMNWeMQSk3gupJhOfeLJVWw5t=oZ=cXbgf9NDdhTRAm3TQ=Q@mail.gmail.com>
Subject: Locking in xl
To: Xen-devel <xen-devel@lists.xenproject.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hello,
I see that in the xl binary in xen 4.13.0, the acquire_lock() and
release_lock() functions are only called from create_domain() in
xl_vmcontrol.c, so I assume the lock provides inter-PROCESS
synchronization in the case that multiple instances of xl are running
and creating multiple domains concurrently.

However, this lock causes a bottleneck in the case that an xl restore
process is restoring a DomU with a lot of memory. While the large
amount of memory is being copied from the checkpoint file on disk to
the physical machine's RAM, all other VM creation requests on the
system are starved, leading to a performance loss. When I removed the
lock, my testing of simultaneous creation of 2 DomU's concurrently
worked and I did not see any issues.

Does anyone know what shared resource these locks are guarding? Maybe
we should be making the lock more granular.

-- 
My Blog: http://www.neilscomputerblog.blogspot.com/
Twitter: @neilsikka


From xen-devel-bounces@lists.xenproject.org Thu Apr 23 21:53:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 21:53:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRjmZ-0003SK-CX; Thu, 23 Apr 2020 21:53:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRjmY-0003SF-5P
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 21:53:18 +0000
X-Inumbo-ID: d324c2fe-85ac-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d324c2fe-85ac-11ea-83d8-bc764e2007e4;
 Thu, 23 Apr 2020 21:53:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=74xmghtWv3wzGPj1TzmEubhabXYKB0eQMNri9rzyh8Y=; b=UGX+897fvxRmJPUVYXYTj8ymr
 gbN6mB23z1tIXmjLEiYeSOuHCFNL8hRsQoNlIC55+nnUKnCnp7VFUk47uFxPu39XvUOEXMyivFv+g
 0owGppOdDRG8DsWWFzaSHnH5hGs/lT6pMjZYu0fGUEzGdwkMVoOfjlCTCl8RLCYMEcZDE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRjmQ-0006ww-V4; Thu, 23 Apr 2020 21:53:11 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRjmQ-0006bm-9j; Thu, 23 Apr 2020 21:53:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRjmQ-0006sb-9A; Thu, 23 Apr 2020 21:53:10 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149752-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149752: regressions - trouble:
 blocked/fail/pass/starved
X-Osstest-Failures: xen-unstable:build-i386-prev:xen-build:fail:regression
 xen-unstable:build-i386:xen-build:fail:regression
 xen-unstable:build-i386-xsm:xen-build:fail:regression
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 xen-unstable:test-armhf-armhf-xl-vhd:guest-start/debian.repeat:fail:heisenbug
 xen-unstable:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-pair:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-examine:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-coresched-i386-xl:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking
 xen-unstable:build-i386-libvirt:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 xen-unstable:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: xen=a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
X-Osstest-Versions-That: xen=a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 21:53:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149752 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149752/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-prev               6 xen-build                fail REGR. vs. 149741
 build-i386                    6 xen-build                fail REGR. vs. 149741
 build-i386-xsm                6 xen-build                fail REGR. vs. 149741

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate         fail pass in 149741
 test-armhf-armhf-xl-vhd      15 guest-start/debian.repeat  fail pass in 149741

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-pvshim     1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  1 build-check(1)      blocked n/a
 test-amd64-i386-examine       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-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-raw        1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)      blocked n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-coresched-i386-xl  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-shadow     1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-xsm        1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-livepatch     1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 149741 blocked in 149752
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 149741 blocked in 149752
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 149741 blocked in 149752
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 149741 blocked in 149752
 test-amd64-i386-libvirt     13 migrate-support-check fail in 149741 never pass
 test-amd64-i386-xl-pvshim    12 guest-start          fail in 149741 never pass
 test-amd64-i386-libvirt-xsm 13 migrate-support-check fail in 149741 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 149741 never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop    fail in 149741 never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149741
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149741
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149741
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149741
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149741
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149741
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate           starved in 149741 n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate               starved  n/a

version targeted for testing:
 xen                  a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
baseline version:
 xen                  a62c6fe05c4ae905b7d4cb0ca946508b7f96d522

Last test of basis   149752  2020-04-23 10:22:34 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               fail    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-prev                                             pass    
 build-i386-prev                                              fail    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                starved 
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-coresched-i386-xl                                 blocked 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         blocked 
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  blocked 
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  blocked 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       blocked 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          blocked 
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         blocked 
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    blocked 
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  blocked 
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 blocked 
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    blocked 
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       blocked 
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              blocked 
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    blocked 
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Thu Apr 23 23:46:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Apr 2020 23:46:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRlYD-00040g-2B; Thu, 23 Apr 2020 23:46:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HETR=6H=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRlYC-00040b-7y
 for xen-devel@lists.xenproject.org; Thu, 23 Apr 2020 23:46:36 +0000
X-Inumbo-ID: a5ac0463-85bc-11ea-9432-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a5ac0463-85bc-11ea-9432-12813bfff9fa;
 Thu, 23 Apr 2020 23:46:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=YTgUcQT7dHeYqNjNxaF5Yo3r3I0dQgvLHiwABNL65CY=; b=7PtL2mOExD17/TQCj1LTllZu6
 nTj+au+pZpyu3HgzxH5ncQpB5UlwwcGcrlowiEvk+60xOIrpzYIE28hZ4iY/J2IVJAny10s6cdwfx
 TPq4WpKbpNb+OM2whL2EbygyGNtSL5MqOEecuOZLRl2n7Cw7S/zKgHxx82VZesAqPCw/c=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRlY3-0000nu-1g; Thu, 23 Apr 2020 23:46:27 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRlY2-00043N-Nd; Thu, 23 Apr 2020 23:46:26 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRlY2-0001uj-Mw; Thu, 23 Apr 2020 23:46:26 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149768-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [examine test] 149768: tolerable trouble: pass/starved
X-Osstest-Failures: examine:examine-laxton1:hosts-allocate:starved:nonblocking
 examine:examine-fiano1:hosts-allocate:starved:nonblocking
 examine:examine-fiano0:hosts-allocate:starved:nonblocking
 examine:examine-laxton0:hosts-allocate:starved:nonblocking
 examine:examine-rochester0:hosts-allocate:starved:nonblocking
 examine:examine-albana0:hosts-allocate:starved:nonblocking
 examine:examine-cubietruck-braque:hosts-allocate:starved:nonblocking
 examine:examine-italia0:hosts-allocate:starved:nonblocking
 examine:examine-pinot0:hosts-allocate:starved:nonblocking
 examine:examine-rimava1:hosts-allocate:starved:nonblocking
 examine:examine-debina0:hosts-allocate:starved:nonblocking
 examine:examine-chardonnay0:hosts-allocate:starved:nonblocking
 examine:examine-elbling0:hosts-allocate:starved:nonblocking
 examine:examine-godello0:hosts-allocate:starved:nonblocking
 examine:examine-albana1:hosts-allocate:starved:nonblocking
 examine:examine-pinot1:hosts-allocate:starved:nonblocking
X-Osstest-Versions-That: flight=149739
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 23 Apr 2020 23:46:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149768 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149768/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 examine-laxton1               2 hosts-allocate               starved  n/a
 examine-fiano1                2 hosts-allocate               starved  n/a
 examine-fiano0                2 hosts-allocate               starved  n/a
 examine-laxton0               2 hosts-allocate               starved  n/a
 examine-rochester0            2 hosts-allocate               starved  n/a
 examine-albana0               2 hosts-allocate               starved  n/a
 examine-cubietruck-braque     2 hosts-allocate               starved  n/a
 examine-italia0               2 hosts-allocate               starved  n/a
 examine-pinot0                2 hosts-allocate               starved  n/a
 examine-rimava1               2 hosts-allocate               starved  n/a
 examine-debina0               2 hosts-allocate               starved  n/a
 examine-chardonnay0           2 hosts-allocate               starved  n/a
 examine-elbling0              2 hosts-allocate               starved  n/a
 examine-godello0              2 hosts-allocate               starved  n/a
 examine-albana1               2 hosts-allocate               starved  n/a
 examine-pinot1                2 hosts-allocate               starved  n/a

baseline version:
 flight               149739

jobs:
 examine-albana0                                              starved 
 examine-albana1                                              starved 
 examine-arndale-bluewater                                    pass    
 examine-cubietruck-braque                                    starved 
 examine-chardonnay0                                          starved 
 examine-chardonnay1                                          pass    
 examine-debina0                                              starved 
 examine-debina1                                              pass    
 examine-elbling0                                             starved 
 examine-elbling1                                             pass    
 examine-fiano0                                               starved 
 examine-fiano1                                               starved 
 examine-cubietruck-gleizes                                   pass    
 examine-godello0                                             starved 
 examine-godello1                                             pass    
 examine-huxelrebe0                                           pass    
 examine-huxelrebe1                                           pass    
 examine-italia0                                              starved 
 examine-arndale-lakeside                                     pass    
 examine-laxton0                                              starved 
 examine-laxton1                                              starved 
 examine-arndale-metrocentre                                  pass    
 examine-cubietruck-metzinger                                 pass    
 examine-cubietruck-picasso                                   pass    
 examine-pinot0                                               starved 
 examine-pinot1                                               starved 
 examine-rimava1                                              starved 
 examine-rochester0                                           starved 
 examine-rochester1                                           pass    
 examine-arndale-westfield                                    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


Push not applicable.



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 02:11:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 02:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRnnm-0005qY-NB; Fri, 24 Apr 2020 02:10:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRnnl-0005qT-1z
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 02:10:49 +0000
X-Inumbo-ID: cd5292d8-85d0-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cd5292d8-85d0-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 02:10:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=A9DOIxZLG8hCICvTA1wUX0g2FpSRn0N30cLqN7SGTwE=; b=Oco6dWvYry7F1YfupKA1Nu9bj
 GANMR+qxRku0RMtVsGiq/ZeABlZd0okhKz9M0rqHSt80fXWuOtlVh05sYR0NVhLVf8JtDP7JvHRM9
 MbCxREz0L2JLlpeXHifvf/b1a9A/8KRsXOv3/cwbW1qZ+a3y4PiHU//JfrS9rL/6zgy9E=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRnnf-0002Nt-4R; Fri, 24 Apr 2020 02:10:43 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRnne-0003dg-QW; Fri, 24 Apr 2020 02:10:42 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRnne-0006Hc-Ph; Fri, 24 Apr 2020 02:10:42 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149766-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149766: all pass - PUSHED
X-Osstest-Versions-This: ovmf=d5339c04d7cd47c061ec146a7b062052e3dc56ca
X-Osstest-Versions-That: ovmf=3a3a3af4a29ee36b1db11842d40b74f2de892a35
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 02:10:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149766 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149766/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 d5339c04d7cd47c061ec146a7b062052e3dc56ca
baseline version:
 ovmf                 3a3a3af4a29ee36b1db11842d40b74f2de892a35

Last test of basis   149747  2020-04-23 07:21:34 Z    0 days
Testing same since   149766  2020-04-23 14:40:11 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Hao A Wu <hao.a.wu@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   3a3a3af4a2..d5339c04d7  d5339c04d7cd47c061ec146a7b062052e3dc56ca -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 03:02:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 03:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRobq-0001Wv-U6; Fri, 24 Apr 2020 03:02:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6uIs=6I=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRobp-0001Wl-U5
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 03:02:33 +0000
X-Inumbo-ID: 08c207b6-85d8-11ea-b4f4-bc764e2007e4
Received: from mail-qk1-x741.google.com (unknown [2607:f8b0:4864:20::741])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 08c207b6-85d8-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 03:02:29 +0000 (UTC)
Received: by mail-qk1-x741.google.com with SMTP id n143so8857110qkn.8
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 20:02:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=omHxvvNf5Pv3ZOKDgsTQhZY6McIm27KQ9kB0Xgc12vs=;
 b=C2Uq/YbmHigGFo6KhCvp4kIJ8dmQfhohEld85TPbtshStz29W6ifHSHOBUk0prL1tZ
 Irawxeq6f+zokpyHBhGd8vxmxb1KQhji2GLpmm45i2z/Q2WwwrCjBiFfxbkL4P9S5Oh2
 01REU9C6XE7behfxHiB8dv5QteFbLqJC7ZUeKXiZ5FsOLwxfywS8fKeeif+ZjYqPPSTp
 ppA1Qejan35IfX7Xc6aINllAg3IzJoLg2mpVAtnZooG46RKV9mm11QUwb/c0EJeFq2b3
 1gXYBDgYk3J3QVSSHyEJUuXUiq0IjdL/F0+MXCskDxdQzpr4uh8AGzR+9uDdXKxCtbtZ
 yr6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=omHxvvNf5Pv3ZOKDgsTQhZY6McIm27KQ9kB0Xgc12vs=;
 b=tyW8IZDIrV+HcsP14e3tXf6F5laJfRbvZTZCcF71lm0P6ZROxHe8cR419W84FpITK6
 Zy4yF7mrLgLqEALEFZh7uprrCjVR80p5VQAvCkbm17coB7TopEUjHXAXQ3taSEPPcnjE
 b7Sw5yovNS+cMGiEQReKFh6vdb8ef+Z18doUfrSwyMu2GNvwNSRdeFrKkuistnhsCDnb
 PjhEm/pclaDH3cPdNe4A2Lq6jsNNLxK32QlEu8lqGshVxlievRdcLMGU3974tGF6WwX5
 OJmZpzW4C/hqJg5gON2oGSBYnftQAZYtjuXaTgzTl4uY1QfBHclUrGhJf8etCOViSLal
 D0mA==
X-Gm-Message-State: AGi0PublMr6ysNQlMq+ItzAVq+n7oBuShGIsS3r6DJHfLvz9IeK3wlaJ
 3J00Cz6J750YXr53KhjcCHdKwKzQcYs=
X-Google-Smtp-Source: APiQypJxMngb7/CVOcVv3eCLHUwJvwuuVqm7Eg3mvEw1Buwl3RBkj+MxsJv9A9JxHPigGo4k5h25YA==
X-Received: by 2002:ae9:ef93:: with SMTP id d141mr6908540qkg.311.1587697348777; 
 Thu, 23 Apr 2020 20:02:28 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id i6sm2836197qkk.123.2020.04.23.20.02.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Apr 2020 20:02:28 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 1/1] golang/xenlight: add NameToDomid and DomidToName util
 functions
Date: Thu, 23 Apr 2020 23:02:24 -0400
Message-Id: <73e709cf0a87f3728de438e4a3b849462fd098ac.1587682041.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587682041.git.rosbrookn@ainfosec.com>
References: <cover.1587682041.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1587682041.git.rosbrookn@ainfosec.com>
References: <cover.1587682041.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Many exported functions in xenlight require a domid as an argument. Make
it easier for package users to use these functions by adding wrappers
for the libxl utility functions libxl_name_to_domid and
libxl_domid_to_name.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 tools/golang/xenlight/xenlight.go | 38 ++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go
index 6b4f492550..d1d30b63e1 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -21,13 +21,13 @@ package xenlight
 #cgo LDFLAGS: -lxenlight -lyajl -lxentoollog
 #include <stdlib.h>
 #include <libxl.h>
+#include <libxl_utils.h>
 
 static const libxl_childproc_hooks childproc_hooks = { .chldowner = libxl_sigchld_owner_mainloop };
 
 void xenlight_set_chldproc(libxl_ctx *ctx) {
 	libxl_childproc_setmode(ctx, &childproc_hooks, NULL);
 }
-
 */
 import "C"
 
@@ -75,6 +75,10 @@ var libxlErrors = map[Error]string{
 	ErrorFeatureRemoved:               "Feature removed",
 }
 
+const (
+	DomidInvalid Domid = ^Domid(0)
+)
+
 func (e Error) Error() string {
 	if s, ok := libxlErrors[e]; ok {
 		return s
@@ -190,6 +194,38 @@ func (ctx *Context) Close() error {
 
 type Domid uint32
 
+// NameToDomid returns the Domid for a domain, given its name, if it exists.
+//
+// NameToDomid does not guarantee that the domid associated with name at
+// the time NameToDomid is called is the same as the domid associated with
+// name at the time NameToDomid returns.
+func (Ctx *Context) NameToDomid(name string) (Domid, error) {
+	var domid C.uint32_t
+
+	cname := C.CString(name)
+	defer C.free(unsafe.Pointer(cname))
+
+	if ret := C.libxl_name_to_domid(Ctx.ctx, cname, &domid); ret != 0 {
+		return DomidInvalid, Error(ret)
+	}
+
+	return Domid(domid), nil
+}
+
+// DomidToName returns the name for a domain, given its domid. If there
+// is no domain with the given domid, DomidToName will return the empty
+// string.
+//
+// DomidToName does not guarantee that the name (if any) associated with domid
+// at the time DomidToName is called is the same as the name (if any) associated
+// with domid at the time DomidToName returns.
+func (Ctx *Context) DomidToName(domid Domid) string {
+	cname := C.libxl_domid_to_name(Ctx.ctx, C.uint32_t(domid))
+	defer C.free(unsafe.Pointer(cname))
+
+	return C.GoString(cname)
+}
+
 // Devid is a device ID.
 type Devid int
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 03:02:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 03:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRobl-0001We-M2; Fri, 24 Apr 2020 03:02:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6uIs=6I=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRobl-0001WZ-3g
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 03:02:29 +0000
X-Inumbo-ID: 07f2cf00-85d8-11ea-9e09-bc764e2007e4
Received: from mail-qv1-xf2b.google.com (unknown [2607:f8b0:4864:20::f2b])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 07f2cf00-85d8-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 03:02:28 +0000 (UTC)
Received: by mail-qv1-xf2b.google.com with SMTP id p13so4005201qvt.12
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 20:02:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id;
 bh=xZ2OA7DktmSMaGfct2/b8NA4AgSxD4oCg90AQoIQp9s=;
 b=CjZ8G/IKIEWMOSQmgERHzYuZ6kf/eRuZ3gRiCjYiGUezDUr9EpgvU10Uo62IgZox6O
 c93ouVU0E+wBPzkGrLmDhmkps6boiDJjlrnF/q4+kYLD/AVzunh3/IPMfi2um+coBSIY
 NA6BzFPN8Zkz8nCPSocviuahympddv2GjWsENs2KXQQ+Eu6qTKOamD7cSfdA4p7bDnTS
 9OTElbCCrlYkvg3PAUaw/eFtaqAb//LEyIZTGAKtmOlEy7iNCkcmtjIqlJYXLXQbmIZ1
 ChNj4e4i+OeVL17LEiGehot1NjHkcRgeCRjLg43/135ag3+R8x+kokW7hFEzppfn9X6D
 r+rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id;
 bh=xZ2OA7DktmSMaGfct2/b8NA4AgSxD4oCg90AQoIQp9s=;
 b=D6nMFnN1pOShCvcpOR/MRHwUVMI3GTidRzjVP49niHATZzncSoyZ3oYthXw3NG+4fO
 /Q2QsMF5CJIodqYSMCz4SvdGvc6fUvuzEt61JT3i2Odl1bOKns9W+7Va1Ehzc76q23iL
 yW6Fg6xscGnUKGeiYFIl52PExCWnY5gNfVvrT6fCjoVtjJUZkOHuxZ3Hsek4gYh2p1RB
 EnlrzIAbp+t7MvsKKqjn4HiE6xQOqz5fKNz9Nr5BRkWMpnIpBHsuD9gAIZ3oSVcY3EAk
 C6ed/qOB22NReSvlojqq/B4/CJnHi7kY3/4Uql0ObS+uBXpEIfUE8z85//YB4M+K4kU6
 TcQg==
X-Gm-Message-State: AGi0PuZW2MXdKWUbFBtGFdHsOcJa8ziqd7thpv2CfQbOP3jqotOnF1Nh
 9yJ5+09BdnAoLtS/jx7tAZtnBEdQR0M=
X-Google-Smtp-Source: APiQypLYW71MCL9L8HcoLA8c7pYm8nWtXQ7/TOANIMZmJzuw5hCone8QjG4n+HV2TZMT1YVSbjlqpQ==
X-Received: by 2002:a05:6214:593:: with SMTP id
 bx19mr7422167qvb.238.1587697347359; 
 Thu, 23 Apr 2020 20:02:27 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id i6sm2836197qkk.123.2020.04.23.20.02.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Apr 2020 20:02:26 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 0/1] More wrappers for xenlight Go package
Date: Thu, 23 Apr 2020 23:02:23 -0400
Message-Id: <cover.1587682041.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This series adds wrappers to the xenlight package for various libxl
functions, which are now trivial to add with the generated types and 
marshaling helpers. In particular, these are functions that would allow
redctl to begin making the transition to using the xenlight package. For 
reference, I have started an experimental branch where I am using these
functions in redctl [1].

[1] https://gitlab.com/enr0n/redctl/-/blob/1bdf7b515654cc030e095f3a630a24530f930c00/internal/server/xenlight_xen_driver.go

Changes in v2:
 - Define constant DomidInvalid in first patch for use in NameToDomid
 - Add more detail to function comments

Nick Rosbrook (1):
  golang/xenlight: add NameToDomid and DomidToName util functions

 tools/golang/xenlight/xenlight.go | 38 ++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 03:05:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 03:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRoex-0001lB-CR; Fri, 24 Apr 2020 03:05:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6uIs=6I=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRoew-0001l3-Ib
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 03:05:46 +0000
X-Inumbo-ID: 7de48924-85d8-11ea-9e09-bc764e2007e4
Received: from mail-qt1-x834.google.com (unknown [2607:f8b0:4864:20::834])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7de48924-85d8-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 03:05:46 +0000 (UTC)
Received: by mail-qt1-x834.google.com with SMTP id e17so3419973qtp.7
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 20:05:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id;
 bh=1GC8OpGDdaEyCldFE9DhepD3xfjV6bKCiEK8/G0OGK4=;
 b=HMfIoNC2l38T0SAX9R0cS84u60KGe/t+zedGop8KXGbBjLa+3VNEZFHYHsycgS1laS
 M5xYlQqQlBuTuvuHC4OUyM+ojo+tuNvmfO0JnlKZmADRQJeeqtvfYLvf4JPmObjuhzLl
 ZCUeVzrskFsbdbl5DbDxH3RvCTY05v/SPTUgQm/Zk4Em8bampUO6/4YA2VeAUG6KMRNt
 MEXEvx0lM5gYMR1p+oi2/XZHLmSnqEssgMO9RE6RqZQyx7UQz9mrKtPEjwmXgdNUvEg7
 R3vZf8yX3SRunSSFC/NLGASDWOtho2LnjXSMoXIl3INz/dOda2zumfDeb5BFNhXUoGrs
 KBNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id;
 bh=1GC8OpGDdaEyCldFE9DhepD3xfjV6bKCiEK8/G0OGK4=;
 b=gaAqKErb5rjY9u6tck19Z6C1hOwTAGmcC4fC0ET7RT40v6wI1zzJjGyuAel4DPHJ+b
 LRV2GN+Xz2qCyp2BRFlEHqYew84J/GaS9w3Ih7foIh16cw7YcVaqXNi1z9D/KpQuSXqr
 /PvpqDwxpR8ASo8r/p4F/Sx1YfDvqB5IvDc37UZQG4/OkBcrPjaoO5qux8ixUaTjUwFZ
 IXenY9jPV2SNjYdOv1kV4Vppsrb/91498e7UhcsnjvBzwbZBptCpS4UR43YgMOuaHDaT
 INKLxB1IFTyB1gEK2iCptjOlQcrDvwJItvZumdJqnVUrim9qAy9okBuzvLcTNgPjzI1f
 yV9A==
X-Gm-Message-State: AGi0PuZNUkUR6QuV0v3WAeu4wJGr/xyNES3ZHowAh8KwjFTK0CT+6BiE
 C6u0at47J1cY68lALKZlvCLETWLY2fI=
X-Google-Smtp-Source: APiQypIXrM4vSkQoaLm+FP0k52fsmBKgVynGBDep44q/Z2OwAoZ6oYG2Z4KfCS+lPeb8thBqhrWZhw==
X-Received: by 2002:aed:3e22:: with SMTP id l31mr7388976qtf.290.1587697545315; 
 Thu, 23 Apr 2020 20:05:45 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id p10sm2949820qtu.14.2020.04.23.20.05.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Apr 2020 20:05:44 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 0/2] build golang tools
Date: Thu, 23 Apr 2020 23:05:39 -0400
Message-Id: <cover.1587695896.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Nick Rosbrook <rosbrookn@ainfosec.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

These patches add support for the golang tools in the build system.

The behavior of configure with respect to the make variable,
CONFIG_GOLANG is copied from other components, such as the Ocaml
tools. Namely, build the tools by default if the go compiler is found.

Changes in v2:
 - Change make variable to CONFIG_GOLANG, and use `golang` rather
   than golang_tools to avoid mixing underscores and hyphens in 
   configure flags.

Nick Rosbrook (2):
  tools: build golang tools if go compiler is present
  golang/xenlight: stop tracking generated files

 .gitignore                           |    3 +
 .hgignore                            |    2 +
 config/Tools.mk.in                   |    1 +
 m4/golang.m4                         |    4 +
 tools/Rules.mk                       |    2 -
 tools/configure                      |  138 +
 tools/configure.ac                   |   12 +
 tools/golang/xenlight/Makefile       |    1 +
 tools/golang/xenlight/helpers.gen.go | 4722 --------------------------
 tools/golang/xenlight/types.gen.go   | 1225 -------
 10 files changed, 161 insertions(+), 5949 deletions(-)
 create mode 100644 m4/golang.m4
 delete mode 100644 tools/golang/xenlight/helpers.gen.go
 delete mode 100644 tools/golang/xenlight/types.gen.go

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 03:05:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 03:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRof2-0001m1-K2; Fri, 24 Apr 2020 03:05:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6uIs=6I=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRof1-0001ll-IK
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 03:05:51 +0000
X-Inumbo-ID: 7ee0156e-85d8-11ea-b4f4-bc764e2007e4
Received: from mail-qk1-x741.google.com (unknown [2607:f8b0:4864:20::741])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7ee0156e-85d8-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 03:05:47 +0000 (UTC)
Received: by mail-qk1-x741.google.com with SMTP id b62so8851525qkf.6
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 20:05:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=3RBRwALRKscK7/reWkGS8WrtLddfjEdapdGxqMcDLd0=;
 b=k1ZJsCwv1cLgyTG3hFkzW5MdEHhbYMmJyLl4h/Y83gITIbvPFeS/Vy4Z1SzveAyukv
 YGVb2/g/8X+K+3LBCTCsFPFxs3YqRq7ZUhUc/OmwDIL0XXFhV8gyvKJO+4ZlNizM6nbs
 EyS3OVMoLrZ50/U6jyawV7TsPPmll5VrS5329rzEYNlBEzLO5A89jc1J2+N+Mb5tBw/1
 EI1iiJAkTsO2GweLcggoN8lhFG05y2QzsHul/kCamdAMgI34Y1+u/YF6UFOe3xu2B7Uf
 xJ50z0vZi/mz7y1q3y2Fb1Loh0D9vsgnTf2+bxnCT9+a8fGPuNF3xQSuat8MXiHm+E1Y
 dcpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=3RBRwALRKscK7/reWkGS8WrtLddfjEdapdGxqMcDLd0=;
 b=KEL+q02MHPCXCwVRXct+BK8pOza3Mt8DMEpks5dpiSHR3Li40Qr2iAY8JxnRX7QPc/
 XXI4lgMcPivxzyZccsCsj47xCSfhbO/Vjke/M1XSGzsrF9erJ3XG+eo5xXGAUQWP3LHS
 55AKY05ewgCJWspEX+ehTjC37FcUr6kWidp5rVeS1ms+ZFsMAgqiimlfwtvCi5Gajv3p
 r4wf1VljDv0ZVL9tonBGd1QcHdFAoOxfNrlYRpsMSQPoza0tlfDdiq0Rq7eEa/QvfnZ5
 5+lyIvRBJ7YycnAvXY2gs7iF1jPkywC+V+oTdFzVPxXnCEn9zw85BeNI3MRYwbeCrvWN
 qeCA==
X-Gm-Message-State: AGi0PuYH1h4draKzl/rL87lfep9HQtz30G5aNcVZWPwOMs6DQS3zaY/P
 02f9A5kG5k7p+vFYegqGZTOWGOeyP6M=
X-Google-Smtp-Source: APiQypJ7DOzxGtUTT5XCAFPUYGU+VW+Vk0kFnmM2RlCtqm3RJooQj9FMvjmlYfuzLGT5lP79I6H+Nw==
X-Received: by 2002:a37:68cd:: with SMTP id d196mr6904045qkc.188.1587697546732; 
 Thu, 23 Apr 2020 20:05:46 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id p10sm2949820qtu.14.2020.04.23.20.05.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Apr 2020 20:05:46 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 1/2] tools: build golang tools if go compiler is present
Date: Thu, 23 Apr 2020 23:05:40 -0400
Message-Id: <4dbde331aa6a0f8a78d93b86ffaa396c367fc57f.1587695896.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587695896.git.rosbrookn@ainfosec.com>
References: <cover.1587695896.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1587695896.git.rosbrookn@ainfosec.com>
References: <cover.1587695896.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

By default, if the go compiler is found by the configure script, build
the golang tools. If the compiler is not found, and --enable-golang was
not explicitly set, do not build to the golang tools.

The corresponding make variable is CONFIG_GOLANG. Remove CONFIG_GOLANG
from tools/Rules.mk since the variable is now set by configure in
config/Tools.mk.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
Acked-by: Wei Liu <wl@xen.org>
---
 config/Tools.mk.in |   1 +
 m4/golang.m4       |   4 ++
 tools/Rules.mk     |   2 -
 tools/configure    | 138 +++++++++++++++++++++++++++++++++++++++++++++
 tools/configure.ac |  12 ++++
 5 files changed, 155 insertions(+), 2 deletions(-)
 create mode 100644 m4/golang.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 189fda1596..23df47af8d 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -55,6 +55,7 @@ CONFIG_QEMU_TRAD    := @qemu_traditional@
 CONFIG_QEMU_XEN     := @qemu_xen@
 CONFIG_QEMUU_EXTRA_ARGS:= @EXTRA_QEMUU_CONFIGURE_ARGS@
 CONFIG_LIBNL        := @libnl@
+CONFIG_GOLANG       := @golang@
 
 CONFIG_SYSTEMD      := @systemd@
 SYSTEMD_CFLAGS      := @SYSTEMD_CFLAGS@
diff --git a/m4/golang.m4 b/m4/golang.m4
new file mode 100644
index 0000000000..0b4bd54ce0
--- /dev/null
+++ b/m4/golang.m4
@@ -0,0 +1,4 @@
+AC_DEFUN([AC_PROG_GO], [
+    dnl Check for the go compiler
+    AC_CHECK_TOOL([GO],[go],[no])
+])
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 9bac15c8d1..5b8cf748ad 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -35,8 +35,6 @@ XENSTORE_XENSTORED ?= y
 debug ?= y
 debug_symbols ?= $(debug)
 
-# Set CONFIG_GOLANG=y in .config (or in make) to build golang
-CONFIG_GOLANG ?= n
 XEN_GOPATH        = $(XEN_ROOT)/tools/golang
 XEN_GOCODE_URL    = golang.xenproject.org
 
diff --git a/tools/configure b/tools/configure
index 4fa5f7b937..375430df3f 100755
--- a/tools/configure
+++ b/tools/configure
@@ -664,6 +664,7 @@ pyconfig
 PYTHONPATH
 CHECKPOLICY
 XENSTORED
+GO
 OCAMLFIND
 OCAMLBUILD
 OCAMLDOC
@@ -705,6 +706,7 @@ LD86
 AS86
 qemu_traditional
 LINUX_BACKEND_MODULES
+golang
 seabios
 ovmf
 xsmpolicy
@@ -807,6 +809,7 @@ enable_ocamltools
 enable_xsmpolicy
 enable_ovmf
 enable_seabios
+enable_golang
 with_linux_backend_modules
 enable_qemu_traditional
 enable_rombios
@@ -1493,6 +1496,7 @@ Optional Features:
   --disable-xsmpolicy     Disable XSM policy compilation (default is ENABLED)
   --enable-ovmf           Enable OVMF (default is DISABLED)
   --disable-seabios       Disable SeaBIOS (default is ENABLED)
+  --disable-golang        Disable Go tools (default is ENABLED)
   --enable-qemu-traditional
                           Enable qemu traditional device model, (DEFAULT is on
                           for Linux or NetBSD x86, otherwise off)
@@ -3870,6 +3874,8 @@ esac
 
 
 
+
+
 
 
 
@@ -4200,6 +4206,29 @@ seabios=$ax_cv_seabios
 
 
 
+# Check whether --enable-golang was given.
+if test "${enable_golang+set}" = set; then :
+  enableval=$enable_golang;
+fi
+
+
+if test "x$enable_golang" = "xno"; then :
+
+    ax_cv_golang="n"
+
+elif test "x$enable_golang" = "xyes"; then :
+
+    ax_cv_golang="y"
+
+elif test -z $ax_cv_golang; then :
+
+    ax_cv_golang="y"
+
+fi
+golang=$ax_cv_golang
+
+
+
 
 # Check whether --with-linux-backend-modules was given.
 if test "${with_linux_backend_modules+set}" = set; then :
@@ -6694,6 +6723,115 @@ fi
 
 fi
 
+if test "x$golang" = "xy"; then :
+
+
+        if test -n "$ac_tool_prefix"; then
+  # Extract the first word of "${ac_tool_prefix}go", so it can be a program name with args.
+set dummy ${ac_tool_prefix}go; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_GO+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if test -n "$GO"; then
+  ac_cv_prog_GO="$GO" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+    for ac_exec_ext in '' $ac_executable_extensions; do
+  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_GO="${ac_tool_prefix}go"
+    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+fi
+fi
+GO=$ac_cv_prog_GO
+if test -n "$GO"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $GO" >&5
+$as_echo "$GO" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+fi
+if test -z "$ac_cv_prog_GO"; then
+  ac_ct_GO=$GO
+  # Extract the first word of "go", so it can be a program name with args.
+set dummy go; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_ac_ct_GO+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if test -n "$ac_ct_GO"; then
+  ac_cv_prog_ac_ct_GO="$ac_ct_GO" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+    for ac_exec_ext in '' $ac_executable_extensions; do
+  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_ac_ct_GO="go"
+    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+fi
+fi
+ac_ct_GO=$ac_cv_prog_ac_ct_GO
+if test -n "$ac_ct_GO"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_GO" >&5
+$as_echo "$ac_ct_GO" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+  if test "x$ac_ct_GO" = x; then
+    GO="no"
+  else
+    case $cross_compiling:$ac_tool_warned in
+yes:)
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
+$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
+ac_tool_warned=yes ;;
+esac
+    GO=$ac_ct_GO
+  fi
+else
+  GO="$ac_cv_prog_GO"
+fi
+
+
+    if test "x$GO" = "xno"; then :
+
+        if test "x$enable_golang" =  "xyes"; then :
+
+            as_fn_error $? "Go tools enabled, but missing go compiler" "$LINENO" 5
+
+fi
+        golang="n"
+
+fi
+
+fi
+
 
 
 
diff --git a/tools/configure.ac b/tools/configure.ac
index ea0272766f..b6f8882be4 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -73,6 +73,7 @@ m4_include([../m4/fetcher.m4])
 m4_include([../m4/ax_compare_version.m4])
 m4_include([../m4/paths.m4])
 m4_include([../m4/systemd.m4])
+m4_include([../m4/golang.m4])
 
 AX_XEN_EXPAND_CONFIG()
 
@@ -84,6 +85,7 @@ AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools])
 AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
 AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
 AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
+AX_ARG_DEFAULT_ENABLE([golang], [Disable Go tools])
 
 AC_ARG_WITH([linux-backend-modules],
     AS_HELP_STRING([--with-linux-backend-modules="mod1 mod2"],
@@ -320,6 +322,16 @@ AS_IF([test "x$ocamltools" = "xy"], [
     ])
 ])
 
+AS_IF([test "x$golang" = "xy"], [
+    AC_PROG_GO
+    AS_IF([test "x$GO" = "xno"], [
+        AS_IF([test "x$enable_golang" =  "xyes"], [
+            AC_MSG_ERROR([Go tools enabled, but missing go compiler])
+        ])
+        golang="n"
+    ])
+])
+
 m4_include([../m4/xenstored.m4])
 AX_XENSTORE_OPTIONS
 AX_XENSTORE_SET
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 03:06:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 03:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRofE-0001os-0p; Fri, 24 Apr 2020 03:06:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6uIs=6I=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRofC-0001oS-3T
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 03:06:02 +0000
X-Inumbo-ID: 82124090-85d8-11ea-83d8-bc764e2007e4
Received: from mail-qv1-xf30.google.com (unknown [2607:f8b0:4864:20::f30])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 82124090-85d8-11ea-83d8-bc764e2007e4;
 Fri, 24 Apr 2020 03:05:53 +0000 (UTC)
Received: by mail-qv1-xf30.google.com with SMTP id p13so4008100qvt.12
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 20:05:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=BCZXBNvfWFrLvAbAgLtllAJaIgqtKZrly3KUcpyy1Nc=;
 b=V3GBBShQXP2VdoB4fv/IODAXhuQJIPo9+QyUfSLlL8snhoWx5gnE6T9JM2kfZtveZa
 /iY2n8lN2gM6mdlsyCAwjZn49zk1ddULsZuDrdkx1ujz68wNXnVtDTgjkJnVzklujuBC
 R9uLVGzfoSYeut9xsa8zLHB+ofafk/CnTfcBnadnR72Slzl3630Sz8c3/1/h7XA6kqgk
 y72oY67iS1PqF4wjHAaQcVDmnf8Xa6VvqfN8HJQZF/sAT/aRar1BZ0ytiBYkA/LwxPhU
 IWVxhMtNUPdZnBUrr2EcaXFfmXVvPoZRKSBBPKVtQ5XiTZlTABURogbA+DYED82pwTuB
 f5gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=BCZXBNvfWFrLvAbAgLtllAJaIgqtKZrly3KUcpyy1Nc=;
 b=ewwFpNxkwAMVNNFPlkn9vXnv2o3sNyn5R5134bMswtmOzDL0rsmaF20c1Og17q4bjj
 ML5PSbqImhQpGg9euTq0r/F4P8MPQ/WUyrP+AVFbBIigbs+BvSrQ/R5BjPAlQcRRfQM0
 82nswWwify/KOzQYszNnUTEqr8ajtw6xsRV+cPLZsCPVvxXxYlAMD+rz1d5dTEkXgw1v
 dptAr0jzqRW+Rq3djVA4c//cpPJSa99VFrRcf+tco1PuQDqJENdszqQJAjt1skDBPjj3
 qu1x+flLIotA16OkudNwqq0JvZbZC46puftdzBt7Yf9qvgZEFtieFCqXpZr7c1jAwuT0
 JpgQ==
X-Gm-Message-State: AGi0PuYmfQaVDT055ARMwxlCT00QA4gh2H6/jnON9FaJvWMQJkaWqU1h
 4ADspdPH50BoJa25FmGbco8Nxh3IubM=
X-Google-Smtp-Source: APiQypKF5+Up5KFT4QH0jN7aVqQpIuKJH3EMLnHEmG60lL0NXGSKmGmYSw8lvjk2kQ2qbXMEQqKmuQ==
X-Received: by 2002:a0c:df02:: with SMTP id g2mr7033868qvl.115.1587697548902; 
 Thu, 23 Apr 2020 20:05:48 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id p10sm2949820qtu.14.2020.04.23.20.05.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Apr 2020 20:05:47 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 2/2] golang/xenlight: stop tracking generated files
Date: Thu, 23 Apr 2020 23:05:41 -0400
Message-Id: <272bff172dfd46625e6fa1700c05e8327fe57d2b.1587695896.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587695896.git.rosbrookn@ainfosec.com>
References: <cover.1587695896.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1587695896.git.rosbrookn@ainfosec.com>
References: <cover.1587695896.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Nick Rosbrook <rosbrookn@ainfosec.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The generated go files were tracked temporarily while the initial
implementation of gengotypes.py was in progress. They can now be removed
and ignored by git and hg.

While here, make sure generated files are removed by make clean.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
Acked-by: Wei Liu <wl@xen.org>
---
 .gitignore                           |    3 +
 .hgignore                            |    2 +
 tools/golang/xenlight/Makefile       |    1 +
 tools/golang/xenlight/helpers.gen.go | 4722 --------------------------
 tools/golang/xenlight/types.gen.go   | 1225 -------
 5 files changed, 6 insertions(+), 5947 deletions(-)
 delete mode 100644 tools/golang/xenlight/helpers.gen.go
 delete mode 100644 tools/golang/xenlight/types.gen.go

diff --git a/.gitignore b/.gitignore
index 4ca679ddbc..93c11019a2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -405,6 +405,9 @@ tools/xenstore/xenstore-watch
 tools/xl/_paths.h
 tools/xl/xl
 
+tools/golang/src
+tools/golang/*/*.gen.go
+
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
 docs/figs/*.png
diff --git a/.hgignore b/.hgignore
index 2d41670632..2ec52982e1 100644
--- a/.hgignore
+++ b/.hgignore
@@ -282,6 +282,8 @@
 ^tools/ocaml/test/xtl$
 ^tools/ocaml/test/send_debug_keys$
 ^tools/ocaml/test/list_domains$
+^tools/golang/src$
+^tools/golang/.*/.*\.gen\.go$
 ^tools/autom4te\.cache$
 ^tools/config\.h$
 ^tools/config\.log$
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
index 753132306a..144c133ced 100644
--- a/tools/golang/xenlight/Makefile
+++ b/tools/golang/xenlight/Makefile
@@ -49,6 +49,7 @@ install: build
 clean:
 	$(RM) -r $(XEN_GOPATH)$(GOXL_PKG_DIR)
 	$(RM) $(XEN_GOPATH)/pkg/*/$(XEN_GOCODE_URL)/xenlight.a
+	$(RM) *.gen.go
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
deleted file mode 100644
index 16e26d27f5..0000000000
--- a/tools/golang/xenlight/helpers.gen.go
+++ /dev/null
@@ -1,4722 +0,0 @@
-// DO NOT EDIT.
-//
-// This file is generated by:
-// gengotypes.py ../../libxl/libxl_types.idl
-//
-package xenlight
-
-import (
-	"errors"
-	"fmt"
-	"unsafe"
-)
-
-/*
-#cgo LDFLAGS: -lxenlight
-#include <stdlib.h>
-#include <libxl.h>
-
-typedef typeof(((struct libxl_channelinfo *)NULL)->u.pty)libxl_channelinfo_connection_union_pty;
-typedef typeof(((struct libxl_domain_build_info *)NULL)->u.hvm)libxl_domain_build_info_type_union_hvm;
-typedef typeof(((struct libxl_domain_build_info *)NULL)->u.pv)libxl_domain_build_info_type_union_pv;
-typedef typeof(((struct libxl_domain_build_info *)NULL)->u.pvh)libxl_domain_build_info_type_union_pvh;
-typedef typeof(((struct libxl_device_usbdev *)NULL)->u.hostdev)libxl_device_usbdev_type_union_hostdev;
-typedef typeof(((struct libxl_device_channel *)NULL)->u.socket)libxl_device_channel_connection_union_socket;
-typedef typeof(((struct libxl_event *)NULL)->u.domain_shutdown)libxl_event_type_union_domain_shutdown;
-typedef typeof(((struct libxl_event *)NULL)->u.disk_eject)libxl_event_type_union_disk_eject;
-typedef typeof(((struct libxl_event *)NULL)->u.operation_complete)libxl_event_type_union_operation_complete;
-typedef typeof(((struct libxl_psr_hw_info *)NULL)->u.cat)libxl_psr_hw_info_type_union_cat;
-typedef typeof(((struct libxl_psr_hw_info *)NULL)->u.mba)libxl_psr_hw_info_type_union_mba;
-*/
-import "C"
-
-// NewIoportRange returns an instance of IoportRange initialized with defaults.
-func NewIoportRange() (*IoportRange, error) {
-	var (
-		x  IoportRange
-		xc C.libxl_ioport_range
-	)
-
-	C.libxl_ioport_range_init(&xc)
-	defer C.libxl_ioport_range_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *IoportRange) fromC(xc *C.libxl_ioport_range) error {
-	x.First = uint32(xc.first)
-	x.Number = uint32(xc.number)
-
-	return nil
-}
-
-func (x *IoportRange) toC(xc *C.libxl_ioport_range) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_ioport_range_dispose(xc)
-		}
-	}()
-
-	xc.first = C.uint32_t(x.First)
-	xc.number = C.uint32_t(x.Number)
-
-	return nil
-}
-
-// NewIomemRange returns an instance of IomemRange initialized with defaults.
-func NewIomemRange() (*IomemRange, error) {
-	var (
-		x  IomemRange
-		xc C.libxl_iomem_range
-	)
-
-	C.libxl_iomem_range_init(&xc)
-	defer C.libxl_iomem_range_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *IomemRange) fromC(xc *C.libxl_iomem_range) error {
-	x.Start = uint64(xc.start)
-	x.Number = uint64(xc.number)
-	x.Gfn = uint64(xc.gfn)
-
-	return nil
-}
-
-func (x *IomemRange) toC(xc *C.libxl_iomem_range) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_iomem_range_dispose(xc)
-		}
-	}()
-
-	xc.start = C.uint64_t(x.Start)
-	xc.number = C.uint64_t(x.Number)
-	xc.gfn = C.uint64_t(x.Gfn)
-
-	return nil
-}
-
-// NewVgaInterfaceInfo returns an instance of VgaInterfaceInfo initialized with defaults.
-func NewVgaInterfaceInfo() (*VgaInterfaceInfo, error) {
-	var (
-		x  VgaInterfaceInfo
-		xc C.libxl_vga_interface_info
-	)
-
-	C.libxl_vga_interface_info_init(&xc)
-	defer C.libxl_vga_interface_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VgaInterfaceInfo) fromC(xc *C.libxl_vga_interface_info) error {
-	x.Kind = VgaInterfaceType(xc.kind)
-
-	return nil
-}
-
-func (x *VgaInterfaceInfo) toC(xc *C.libxl_vga_interface_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vga_interface_info_dispose(xc)
-		}
-	}()
-
-	xc.kind = C.libxl_vga_interface_type(x.Kind)
-
-	return nil
-}
-
-// NewVncInfo returns an instance of VncInfo initialized with defaults.
-func NewVncInfo() (*VncInfo, error) {
-	var (
-		x  VncInfo
-		xc C.libxl_vnc_info
-	)
-
-	C.libxl_vnc_info_init(&xc)
-	defer C.libxl_vnc_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VncInfo) fromC(xc *C.libxl_vnc_info) error {
-	if err := x.Enable.fromC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	x.Listen = C.GoString(xc.listen)
-	x.Passwd = C.GoString(xc.passwd)
-	x.Display = int(xc.display)
-	if err := x.Findunused.fromC(&xc.findunused); err != nil {
-		return fmt.Errorf("converting field Findunused: %v", err)
-	}
-
-	return nil
-}
-
-func (x *VncInfo) toC(xc *C.libxl_vnc_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vnc_info_dispose(xc)
-		}
-	}()
-
-	if err := x.Enable.toC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	if x.Listen != "" {
-		xc.listen = C.CString(x.Listen)
-	}
-	if x.Passwd != "" {
-		xc.passwd = C.CString(x.Passwd)
-	}
-	xc.display = C.int(x.Display)
-	if err := x.Findunused.toC(&xc.findunused); err != nil {
-		return fmt.Errorf("converting field Findunused: %v", err)
-	}
-
-	return nil
-}
-
-// NewSpiceInfo returns an instance of SpiceInfo initialized with defaults.
-func NewSpiceInfo() (*SpiceInfo, error) {
-	var (
-		x  SpiceInfo
-		xc C.libxl_spice_info
-	)
-
-	C.libxl_spice_info_init(&xc)
-	defer C.libxl_spice_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SpiceInfo) fromC(xc *C.libxl_spice_info) error {
-	if err := x.Enable.fromC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	x.Port = int(xc.port)
-	x.TlsPort = int(xc.tls_port)
-	x.Host = C.GoString(xc.host)
-	if err := x.DisableTicketing.fromC(&xc.disable_ticketing); err != nil {
-		return fmt.Errorf("converting field DisableTicketing: %v", err)
-	}
-	x.Passwd = C.GoString(xc.passwd)
-	if err := x.AgentMouse.fromC(&xc.agent_mouse); err != nil {
-		return fmt.Errorf("converting field AgentMouse: %v", err)
-	}
-	if err := x.Vdagent.fromC(&xc.vdagent); err != nil {
-		return fmt.Errorf("converting field Vdagent: %v", err)
-	}
-	if err := x.ClipboardSharing.fromC(&xc.clipboard_sharing); err != nil {
-		return fmt.Errorf("converting field ClipboardSharing: %v", err)
-	}
-	x.Usbredirection = int(xc.usbredirection)
-	x.ImageCompression = C.GoString(xc.image_compression)
-	x.StreamingVideo = C.GoString(xc.streaming_video)
-
-	return nil
-}
-
-func (x *SpiceInfo) toC(xc *C.libxl_spice_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_spice_info_dispose(xc)
-		}
-	}()
-
-	if err := x.Enable.toC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	xc.port = C.int(x.Port)
-	xc.tls_port = C.int(x.TlsPort)
-	if x.Host != "" {
-		xc.host = C.CString(x.Host)
-	}
-	if err := x.DisableTicketing.toC(&xc.disable_ticketing); err != nil {
-		return fmt.Errorf("converting field DisableTicketing: %v", err)
-	}
-	if x.Passwd != "" {
-		xc.passwd = C.CString(x.Passwd)
-	}
-	if err := x.AgentMouse.toC(&xc.agent_mouse); err != nil {
-		return fmt.Errorf("converting field AgentMouse: %v", err)
-	}
-	if err := x.Vdagent.toC(&xc.vdagent); err != nil {
-		return fmt.Errorf("converting field Vdagent: %v", err)
-	}
-	if err := x.ClipboardSharing.toC(&xc.clipboard_sharing); err != nil {
-		return fmt.Errorf("converting field ClipboardSharing: %v", err)
-	}
-	xc.usbredirection = C.int(x.Usbredirection)
-	if x.ImageCompression != "" {
-		xc.image_compression = C.CString(x.ImageCompression)
-	}
-	if x.StreamingVideo != "" {
-		xc.streaming_video = C.CString(x.StreamingVideo)
-	}
-
-	return nil
-}
-
-// NewSdlInfo returns an instance of SdlInfo initialized with defaults.
-func NewSdlInfo() (*SdlInfo, error) {
-	var (
-		x  SdlInfo
-		xc C.libxl_sdl_info
-	)
-
-	C.libxl_sdl_info_init(&xc)
-	defer C.libxl_sdl_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SdlInfo) fromC(xc *C.libxl_sdl_info) error {
-	if err := x.Enable.fromC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	if err := x.Opengl.fromC(&xc.opengl); err != nil {
-		return fmt.Errorf("converting field Opengl: %v", err)
-	}
-	x.Display = C.GoString(xc.display)
-	x.Xauthority = C.GoString(xc.xauthority)
-
-	return nil
-}
-
-func (x *SdlInfo) toC(xc *C.libxl_sdl_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_sdl_info_dispose(xc)
-		}
-	}()
-
-	if err := x.Enable.toC(&xc.enable); err != nil {
-		return fmt.Errorf("converting field Enable: %v", err)
-	}
-	if err := x.Opengl.toC(&xc.opengl); err != nil {
-		return fmt.Errorf("converting field Opengl: %v", err)
-	}
-	if x.Display != "" {
-		xc.display = C.CString(x.Display)
-	}
-	if x.Xauthority != "" {
-		xc.xauthority = C.CString(x.Xauthority)
-	}
-
-	return nil
-}
-
-// NewDominfo returns an instance of Dominfo initialized with defaults.
-func NewDominfo() (*Dominfo, error) {
-	var (
-		x  Dominfo
-		xc C.libxl_dominfo
-	)
-
-	C.libxl_dominfo_init(&xc)
-	defer C.libxl_dominfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Dominfo) fromC(xc *C.libxl_dominfo) error {
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	x.Domid = Domid(xc.domid)
-	x.Ssidref = uint32(xc.ssidref)
-	x.SsidLabel = C.GoString(xc.ssid_label)
-	x.Running = bool(xc.running)
-	x.Blocked = bool(xc.blocked)
-	x.Paused = bool(xc.paused)
-	x.Shutdown = bool(xc.shutdown)
-	x.Dying = bool(xc.dying)
-	x.NeverStop = bool(xc.never_stop)
-	x.ShutdownReason = ShutdownReason(xc.shutdown_reason)
-	x.OutstandingMemkb = uint64(xc.outstanding_memkb)
-	x.CurrentMemkb = uint64(xc.current_memkb)
-	x.SharedMemkb = uint64(xc.shared_memkb)
-	x.PagedMemkb = uint64(xc.paged_memkb)
-	x.MaxMemkb = uint64(xc.max_memkb)
-	x.CpuTime = uint64(xc.cpu_time)
-	x.VcpuMaxId = uint32(xc.vcpu_max_id)
-	x.VcpuOnline = uint32(xc.vcpu_online)
-	x.Cpupool = uint32(xc.cpupool)
-	x.DomainType = DomainType(xc.domain_type)
-
-	return nil
-}
-
-func (x *Dominfo) toC(xc *C.libxl_dominfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_dominfo_dispose(xc)
-		}
-	}()
-
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	xc.domid = C.libxl_domid(x.Domid)
-	xc.ssidref = C.uint32_t(x.Ssidref)
-	if x.SsidLabel != "" {
-		xc.ssid_label = C.CString(x.SsidLabel)
-	}
-	xc.running = C.bool(x.Running)
-	xc.blocked = C.bool(x.Blocked)
-	xc.paused = C.bool(x.Paused)
-	xc.shutdown = C.bool(x.Shutdown)
-	xc.dying = C.bool(x.Dying)
-	xc.never_stop = C.bool(x.NeverStop)
-	xc.shutdown_reason = C.libxl_shutdown_reason(x.ShutdownReason)
-	xc.outstanding_memkb = C.uint64_t(x.OutstandingMemkb)
-	xc.current_memkb = C.uint64_t(x.CurrentMemkb)
-	xc.shared_memkb = C.uint64_t(x.SharedMemkb)
-	xc.paged_memkb = C.uint64_t(x.PagedMemkb)
-	xc.max_memkb = C.uint64_t(x.MaxMemkb)
-	xc.cpu_time = C.uint64_t(x.CpuTime)
-	xc.vcpu_max_id = C.uint32_t(x.VcpuMaxId)
-	xc.vcpu_online = C.uint32_t(x.VcpuOnline)
-	xc.cpupool = C.uint32_t(x.Cpupool)
-	xc.domain_type = C.libxl_domain_type(x.DomainType)
-
-	return nil
-}
-
-// NewCpupoolinfo returns an instance of Cpupoolinfo initialized with defaults.
-func NewCpupoolinfo() (*Cpupoolinfo, error) {
-	var (
-		x  Cpupoolinfo
-		xc C.libxl_cpupoolinfo
-	)
-
-	C.libxl_cpupoolinfo_init(&xc)
-	defer C.libxl_cpupoolinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Cpupoolinfo) fromC(xc *C.libxl_cpupoolinfo) error {
-	x.Poolid = uint32(xc.poolid)
-	x.PoolName = C.GoString(xc.pool_name)
-	x.Sched = Scheduler(xc.sched)
-	x.NDom = uint32(xc.n_dom)
-	if err := x.Cpumap.fromC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-
-	return nil
-}
-
-func (x *Cpupoolinfo) toC(xc *C.libxl_cpupoolinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_cpupoolinfo_dispose(xc)
-		}
-	}()
-
-	xc.poolid = C.uint32_t(x.Poolid)
-	if x.PoolName != "" {
-		xc.pool_name = C.CString(x.PoolName)
-	}
-	xc.sched = C.libxl_scheduler(x.Sched)
-	xc.n_dom = C.uint32_t(x.NDom)
-	if err := x.Cpumap.toC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-
-	return nil
-}
-
-// NewChannelinfo returns an instance of Channelinfo initialized with defaults.
-func NewChannelinfo(connection ChannelConnection) (*Channelinfo, error) {
-	var (
-		x  Channelinfo
-		xc C.libxl_channelinfo
-	)
-
-	C.libxl_channelinfo_init(&xc)
-	C.libxl_channelinfo_init_connection(&xc, C.libxl_channel_connection(connection))
-	defer C.libxl_channelinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Channelinfo) fromC(xc *C.libxl_channelinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.Rref = int(xc.rref)
-	x.Connection = ChannelConnection(xc.connection)
-	switch x.Connection {
-	case ChannelConnectionUnknown:
-		x.ConnectionUnion = nil
-	case ChannelConnectionPty:
-		var connectionPty ChannelinfoConnectionUnionPty
-		if err := connectionPty.fromC(xc); err != nil {
-			return fmt.Errorf("converting field connectionPty: %v", err)
-		}
-		x.ConnectionUnion = connectionPty
-	case ChannelConnectionSocket:
-		x.ConnectionUnion = nil
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Connection)
-	}
-
-	return nil
-}
-
-func (x *ChannelinfoConnectionUnionPty) fromC(xc *C.libxl_channelinfo) error {
-	if ChannelConnection(xc.connection) != ChannelConnectionPty {
-		return errors.New("expected union key ChannelConnectionPty")
-	}
-
-	tmp := (*C.libxl_channelinfo_connection_union_pty)(unsafe.Pointer(&xc.u[0]))
-	x.Path = C.GoString(tmp.path)
-	return nil
-}
-
-func (x *Channelinfo) toC(xc *C.libxl_channelinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_channelinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref = C.int(x.Rref)
-	xc.connection = C.libxl_channel_connection(x.Connection)
-	switch x.Connection {
-	case ChannelConnectionUnknown:
-		break
-	case ChannelConnectionPty:
-		tmp, ok := x.ConnectionUnion.(ChannelinfoConnectionUnionPty)
-		if !ok {
-			return errors.New("wrong type for union key connection")
-		}
-		var pty C.libxl_channelinfo_connection_union_pty
-		if tmp.Path != "" {
-			pty.path = C.CString(tmp.Path)
-		}
-		ptyBytes := C.GoBytes(unsafe.Pointer(&pty), C.sizeof_libxl_channelinfo_connection_union_pty)
-		copy(xc.u[:], ptyBytes)
-	case ChannelConnectionSocket:
-		break
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Connection)
-	}
-
-	return nil
-}
-
-// NewVminfo returns an instance of Vminfo initialized with defaults.
-func NewVminfo() (*Vminfo, error) {
-	var (
-		x  Vminfo
-		xc C.libxl_vminfo
-	)
-
-	C.libxl_vminfo_init(&xc)
-	defer C.libxl_vminfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vminfo) fromC(xc *C.libxl_vminfo) error {
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	x.Domid = Domid(xc.domid)
-
-	return nil
-}
-
-func (x *Vminfo) toC(xc *C.libxl_vminfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vminfo_dispose(xc)
-		}
-	}()
-
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	xc.domid = C.libxl_domid(x.Domid)
-
-	return nil
-}
-
-// NewVersionInfo returns an instance of VersionInfo initialized with defaults.
-func NewVersionInfo() (*VersionInfo, error) {
-	var (
-		x  VersionInfo
-		xc C.libxl_version_info
-	)
-
-	C.libxl_version_info_init(&xc)
-	defer C.libxl_version_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VersionInfo) fromC(xc *C.libxl_version_info) error {
-	x.XenVersionMajor = int(xc.xen_version_major)
-	x.XenVersionMinor = int(xc.xen_version_minor)
-	x.XenVersionExtra = C.GoString(xc.xen_version_extra)
-	x.Compiler = C.GoString(xc.compiler)
-	x.CompileBy = C.GoString(xc.compile_by)
-	x.CompileDomain = C.GoString(xc.compile_domain)
-	x.CompileDate = C.GoString(xc.compile_date)
-	x.Capabilities = C.GoString(xc.capabilities)
-	x.Changeset = C.GoString(xc.changeset)
-	x.VirtStart = uint64(xc.virt_start)
-	x.Pagesize = int(xc.pagesize)
-	x.Commandline = C.GoString(xc.commandline)
-	x.BuildId = C.GoString(xc.build_id)
-
-	return nil
-}
-
-func (x *VersionInfo) toC(xc *C.libxl_version_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_version_info_dispose(xc)
-		}
-	}()
-
-	xc.xen_version_major = C.int(x.XenVersionMajor)
-	xc.xen_version_minor = C.int(x.XenVersionMinor)
-	if x.XenVersionExtra != "" {
-		xc.xen_version_extra = C.CString(x.XenVersionExtra)
-	}
-	if x.Compiler != "" {
-		xc.compiler = C.CString(x.Compiler)
-	}
-	if x.CompileBy != "" {
-		xc.compile_by = C.CString(x.CompileBy)
-	}
-	if x.CompileDomain != "" {
-		xc.compile_domain = C.CString(x.CompileDomain)
-	}
-	if x.CompileDate != "" {
-		xc.compile_date = C.CString(x.CompileDate)
-	}
-	if x.Capabilities != "" {
-		xc.capabilities = C.CString(x.Capabilities)
-	}
-	if x.Changeset != "" {
-		xc.changeset = C.CString(x.Changeset)
-	}
-	xc.virt_start = C.uint64_t(x.VirtStart)
-	xc.pagesize = C.int(x.Pagesize)
-	if x.Commandline != "" {
-		xc.commandline = C.CString(x.Commandline)
-	}
-	if x.BuildId != "" {
-		xc.build_id = C.CString(x.BuildId)
-	}
-
-	return nil
-}
-
-// NewDomainCreateInfo returns an instance of DomainCreateInfo initialized with defaults.
-func NewDomainCreateInfo() (*DomainCreateInfo, error) {
-	var (
-		x  DomainCreateInfo
-		xc C.libxl_domain_create_info
-	)
-
-	C.libxl_domain_create_info_init(&xc)
-	defer C.libxl_domain_create_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainCreateInfo) fromC(xc *C.libxl_domain_create_info) error {
-	x.Type = DomainType(xc._type)
-	if err := x.Hap.fromC(&xc.hap); err != nil {
-		return fmt.Errorf("converting field Hap: %v", err)
-	}
-	if err := x.Oos.fromC(&xc.oos); err != nil {
-		return fmt.Errorf("converting field Oos: %v", err)
-	}
-	x.Ssidref = uint32(xc.ssidref)
-	x.SsidLabel = C.GoString(xc.ssid_label)
-	x.Name = C.GoString(xc.name)
-	x.Domid = Domid(xc.domid)
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	if err := x.Xsdata.fromC(&xc.xsdata); err != nil {
-		return fmt.Errorf("converting field Xsdata: %v", err)
-	}
-	if err := x.Platformdata.fromC(&xc.platformdata); err != nil {
-		return fmt.Errorf("converting field Platformdata: %v", err)
-	}
-	x.Poolid = uint32(xc.poolid)
-	x.PoolName = C.GoString(xc.pool_name)
-	if err := x.RunHotplugScripts.fromC(&xc.run_hotplug_scripts); err != nil {
-		return fmt.Errorf("converting field RunHotplugScripts: %v", err)
-	}
-	if err := x.DriverDomain.fromC(&xc.driver_domain); err != nil {
-		return fmt.Errorf("converting field DriverDomain: %v", err)
-	}
-	x.Passthrough = Passthrough(xc.passthrough)
-
-	return nil
-}
-
-func (x *DomainCreateInfo) toC(xc *C.libxl_domain_create_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_create_info_dispose(xc)
-		}
-	}()
-
-	xc._type = C.libxl_domain_type(x.Type)
-	if err := x.Hap.toC(&xc.hap); err != nil {
-		return fmt.Errorf("converting field Hap: %v", err)
-	}
-	if err := x.Oos.toC(&xc.oos); err != nil {
-		return fmt.Errorf("converting field Oos: %v", err)
-	}
-	xc.ssidref = C.uint32_t(x.Ssidref)
-	if x.SsidLabel != "" {
-		xc.ssid_label = C.CString(x.SsidLabel)
-	}
-	if x.Name != "" {
-		xc.name = C.CString(x.Name)
-	}
-	xc.domid = C.libxl_domid(x.Domid)
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-	if err := x.Xsdata.toC(&xc.xsdata); err != nil {
-		return fmt.Errorf("converting field Xsdata: %v", err)
-	}
-	if err := x.Platformdata.toC(&xc.platformdata); err != nil {
-		return fmt.Errorf("converting field Platformdata: %v", err)
-	}
-	xc.poolid = C.uint32_t(x.Poolid)
-	if x.PoolName != "" {
-		xc.pool_name = C.CString(x.PoolName)
-	}
-	if err := x.RunHotplugScripts.toC(&xc.run_hotplug_scripts); err != nil {
-		return fmt.Errorf("converting field RunHotplugScripts: %v", err)
-	}
-	if err := x.DriverDomain.toC(&xc.driver_domain); err != nil {
-		return fmt.Errorf("converting field DriverDomain: %v", err)
-	}
-	xc.passthrough = C.libxl_passthrough(x.Passthrough)
-
-	return nil
-}
-
-// NewDomainRestoreParams returns an instance of DomainRestoreParams initialized with defaults.
-func NewDomainRestoreParams() (*DomainRestoreParams, error) {
-	var (
-		x  DomainRestoreParams
-		xc C.libxl_domain_restore_params
-	)
-
-	C.libxl_domain_restore_params_init(&xc)
-	defer C.libxl_domain_restore_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainRestoreParams) fromC(xc *C.libxl_domain_restore_params) error {
-	x.CheckpointedStream = int(xc.checkpointed_stream)
-	x.StreamVersion = uint32(xc.stream_version)
-	x.ColoProxyScript = C.GoString(xc.colo_proxy_script)
-	if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy); err != nil {
-		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
-	}
-
-	return nil
-}
-
-func (x *DomainRestoreParams) toC(xc *C.libxl_domain_restore_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_restore_params_dispose(xc)
-		}
-	}()
-
-	xc.checkpointed_stream = C.int(x.CheckpointedStream)
-	xc.stream_version = C.uint32_t(x.StreamVersion)
-	if x.ColoProxyScript != "" {
-		xc.colo_proxy_script = C.CString(x.ColoProxyScript)
-	}
-	if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil {
-		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
-	}
-
-	return nil
-}
-
-// NewSchedParams returns an instance of SchedParams initialized with defaults.
-func NewSchedParams() (*SchedParams, error) {
-	var (
-		x  SchedParams
-		xc C.libxl_sched_params
-	)
-
-	C.libxl_sched_params_init(&xc)
-	defer C.libxl_sched_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SchedParams) fromC(xc *C.libxl_sched_params) error {
-	x.Vcpuid = int(xc.vcpuid)
-	x.Weight = int(xc.weight)
-	x.Cap = int(xc.cap)
-	x.Period = int(xc.period)
-	x.Extratime = int(xc.extratime)
-	x.Budget = int(xc.budget)
-
-	return nil
-}
-
-func (x *SchedParams) toC(xc *C.libxl_sched_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_sched_params_dispose(xc)
-		}
-	}()
-
-	xc.vcpuid = C.int(x.Vcpuid)
-	xc.weight = C.int(x.Weight)
-	xc.cap = C.int(x.Cap)
-	xc.period = C.int(x.Period)
-	xc.extratime = C.int(x.Extratime)
-	xc.budget = C.int(x.Budget)
-
-	return nil
-}
-
-// NewVcpuSchedParams returns an instance of VcpuSchedParams initialized with defaults.
-func NewVcpuSchedParams() (*VcpuSchedParams, error) {
-	var (
-		x  VcpuSchedParams
-		xc C.libxl_vcpu_sched_params
-	)
-
-	C.libxl_vcpu_sched_params_init(&xc)
-	defer C.libxl_vcpu_sched_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VcpuSchedParams) fromC(xc *C.libxl_vcpu_sched_params) error {
-	x.Sched = Scheduler(xc.sched)
-	x.Vcpus = nil
-	if n := int(xc.num_vcpus); n > 0 {
-		cVcpus := (*[1 << 28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:n:n]
-		x.Vcpus = make([]SchedParams, n)
-		for i, v := range cVcpus {
-			if err := x.Vcpus[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Vcpus: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-func (x *VcpuSchedParams) toC(xc *C.libxl_vcpu_sched_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vcpu_sched_params_dispose(xc)
-		}
-	}()
-
-	xc.sched = C.libxl_scheduler(x.Sched)
-	if numVcpus := len(x.Vcpus); numVcpus > 0 {
-		xc.vcpus = (*C.libxl_sched_params)(C.malloc(C.ulong(numVcpus) * C.sizeof_libxl_sched_params))
-		xc.num_vcpus = C.int(numVcpus)
-		cVcpus := (*[1 << 28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:numVcpus:numVcpus]
-		for i, v := range x.Vcpus {
-			if err := v.toC(&cVcpus[i]); err != nil {
-				return fmt.Errorf("converting field Vcpus: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewDomainSchedParams returns an instance of DomainSchedParams initialized with defaults.
-func NewDomainSchedParams() (*DomainSchedParams, error) {
-	var (
-		x  DomainSchedParams
-		xc C.libxl_domain_sched_params
-	)
-
-	C.libxl_domain_sched_params_init(&xc)
-	defer C.libxl_domain_sched_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainSchedParams) fromC(xc *C.libxl_domain_sched_params) error {
-	x.Sched = Scheduler(xc.sched)
-	x.Weight = int(xc.weight)
-	x.Cap = int(xc.cap)
-	x.Period = int(xc.period)
-	x.Budget = int(xc.budget)
-	x.Extratime = int(xc.extratime)
-	x.Slice = int(xc.slice)
-	x.Latency = int(xc.latency)
-
-	return nil
-}
-
-func (x *DomainSchedParams) toC(xc *C.libxl_domain_sched_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_sched_params_dispose(xc)
-		}
-	}()
-
-	xc.sched = C.libxl_scheduler(x.Sched)
-	xc.weight = C.int(x.Weight)
-	xc.cap = C.int(x.Cap)
-	xc.period = C.int(x.Period)
-	xc.budget = C.int(x.Budget)
-	xc.extratime = C.int(x.Extratime)
-	xc.slice = C.int(x.Slice)
-	xc.latency = C.int(x.Latency)
-
-	return nil
-}
-
-// NewVnodeInfo returns an instance of VnodeInfo initialized with defaults.
-func NewVnodeInfo() (*VnodeInfo, error) {
-	var (
-		x  VnodeInfo
-		xc C.libxl_vnode_info
-	)
-
-	C.libxl_vnode_info_init(&xc)
-	defer C.libxl_vnode_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VnodeInfo) fromC(xc *C.libxl_vnode_info) error {
-	x.Memkb = uint64(xc.memkb)
-	x.Distances = nil
-	if n := int(xc.num_distances); n > 0 {
-		cDistances := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.distances))[:n:n]
-		x.Distances = make([]uint32, n)
-		for i, v := range cDistances {
-			x.Distances[i] = uint32(v)
-		}
-	}
-	x.Pnode = uint32(xc.pnode)
-	if err := x.Vcpus.fromC(&xc.vcpus); err != nil {
-		return fmt.Errorf("converting field Vcpus: %v", err)
-	}
-
-	return nil
-}
-
-func (x *VnodeInfo) toC(xc *C.libxl_vnode_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vnode_info_dispose(xc)
-		}
-	}()
-
-	xc.memkb = C.uint64_t(x.Memkb)
-	if numDistances := len(x.Distances); numDistances > 0 {
-		xc.distances = (*C.uint32_t)(C.malloc(C.size_t(numDistances * numDistances)))
-		xc.num_distances = C.int(numDistances)
-		cDistances := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.distances))[:numDistances:numDistances]
-		for i, v := range x.Distances {
-			cDistances[i] = C.uint32_t(v)
-		}
-	}
-	xc.pnode = C.uint32_t(x.Pnode)
-	if err := x.Vcpus.toC(&xc.vcpus); err != nil {
-		return fmt.Errorf("converting field Vcpus: %v", err)
-	}
-
-	return nil
-}
-
-// NewRdmReserve returns an instance of RdmReserve initialized with defaults.
-func NewRdmReserve() (*RdmReserve, error) {
-	var (
-		x  RdmReserve
-		xc C.libxl_rdm_reserve
-	)
-
-	C.libxl_rdm_reserve_init(&xc)
-	defer C.libxl_rdm_reserve_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *RdmReserve) fromC(xc *C.libxl_rdm_reserve) error {
-	x.Strategy = RdmReserveStrategy(xc.strategy)
-	x.Policy = RdmReservePolicy(xc.policy)
-
-	return nil
-}
-
-func (x *RdmReserve) toC(xc *C.libxl_rdm_reserve) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_rdm_reserve_dispose(xc)
-		}
-	}()
-
-	xc.strategy = C.libxl_rdm_reserve_strategy(x.Strategy)
-	xc.policy = C.libxl_rdm_reserve_policy(x.Policy)
-
-	return nil
-}
-
-// NewDomainBuildInfo returns an instance of DomainBuildInfo initialized with defaults.
-func NewDomainBuildInfo(dtype DomainType) (*DomainBuildInfo, error) {
-	var (
-		x  DomainBuildInfo
-		xc C.libxl_domain_build_info
-	)
-
-	C.libxl_domain_build_info_init(&xc)
-	C.libxl_domain_build_info_init_type(&xc, C.libxl_domain_type(dtype))
-	defer C.libxl_domain_build_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainBuildInfo) fromC(xc *C.libxl_domain_build_info) error {
-	x.MaxVcpus = int(xc.max_vcpus)
-	if err := x.AvailVcpus.fromC(&xc.avail_vcpus); err != nil {
-		return fmt.Errorf("converting field AvailVcpus: %v", err)
-	}
-	if err := x.Cpumap.fromC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-	if err := x.Nodemap.fromC(&xc.nodemap); err != nil {
-		return fmt.Errorf("converting field Nodemap: %v", err)
-	}
-	x.VcpuHardAffinity = nil
-	if n := int(xc.num_vcpu_hard_affinity); n > 0 {
-		cVcpuHardAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:n:n]
-		x.VcpuHardAffinity = make([]Bitmap, n)
-		for i, v := range cVcpuHardAffinity {
-			if err := x.VcpuHardAffinity[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field VcpuHardAffinity: %v", err)
-			}
-		}
-	}
-	x.VcpuSoftAffinity = nil
-	if n := int(xc.num_vcpu_soft_affinity); n > 0 {
-		cVcpuSoftAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:n:n]
-		x.VcpuSoftAffinity = make([]Bitmap, n)
-		for i, v := range cVcpuSoftAffinity {
-			if err := x.VcpuSoftAffinity[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field VcpuSoftAffinity: %v", err)
-			}
-		}
-	}
-	if err := x.NumaPlacement.fromC(&xc.numa_placement); err != nil {
-		return fmt.Errorf("converting field NumaPlacement: %v", err)
-	}
-	x.TscMode = TscMode(xc.tsc_mode)
-	x.MaxMemkb = uint64(xc.max_memkb)
-	x.TargetMemkb = uint64(xc.target_memkb)
-	x.VideoMemkb = uint64(xc.video_memkb)
-	x.ShadowMemkb = uint64(xc.shadow_memkb)
-	x.IommuMemkb = uint64(xc.iommu_memkb)
-	x.RtcTimeoffset = uint32(xc.rtc_timeoffset)
-	x.ExecSsidref = uint32(xc.exec_ssidref)
-	x.ExecSsidLabel = C.GoString(xc.exec_ssid_label)
-	if err := x.Localtime.fromC(&xc.localtime); err != nil {
-		return fmt.Errorf("converting field Localtime: %v", err)
-	}
-	if err := x.DisableMigrate.fromC(&xc.disable_migrate); err != nil {
-		return fmt.Errorf("converting field DisableMigrate: %v", err)
-	}
-	if err := x.Cpuid.fromC(&xc.cpuid); err != nil {
-		return fmt.Errorf("converting field Cpuid: %v", err)
-	}
-	x.BlkdevStart = C.GoString(xc.blkdev_start)
-	x.VnumaNodes = nil
-	if n := int(xc.num_vnuma_nodes); n > 0 {
-		cVnumaNodes := (*[1 << 28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:n:n]
-		x.VnumaNodes = make([]VnodeInfo, n)
-		for i, v := range cVnumaNodes {
-			if err := x.VnumaNodes[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field VnumaNodes: %v", err)
-			}
-		}
-	}
-	x.MaxGrantFrames = uint32(xc.max_grant_frames)
-	x.MaxMaptrackFrames = uint32(xc.max_maptrack_frames)
-	x.DeviceModelVersion = DeviceModelVersion(xc.device_model_version)
-	if err := x.DeviceModelStubdomain.fromC(&xc.device_model_stubdomain); err != nil {
-		return fmt.Errorf("converting field DeviceModelStubdomain: %v", err)
-	}
-	x.DeviceModel = C.GoString(xc.device_model)
-	x.DeviceModelSsidref = uint32(xc.device_model_ssidref)
-	x.DeviceModelSsidLabel = C.GoString(xc.device_model_ssid_label)
-	x.DeviceModelUser = C.GoString(xc.device_model_user)
-	if err := x.Extra.fromC(&xc.extra); err != nil {
-		return fmt.Errorf("converting field Extra: %v", err)
-	}
-	if err := x.ExtraPv.fromC(&xc.extra_pv); err != nil {
-		return fmt.Errorf("converting field ExtraPv: %v", err)
-	}
-	if err := x.ExtraHvm.fromC(&xc.extra_hvm); err != nil {
-		return fmt.Errorf("converting field ExtraHvm: %v", err)
-	}
-	if err := x.SchedParams.fromC(&xc.sched_params); err != nil {
-		return fmt.Errorf("converting field SchedParams: %v", err)
-	}
-	x.Ioports = nil
-	if n := int(xc.num_ioports); n > 0 {
-		cIoports := (*[1 << 28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:n:n]
-		x.Ioports = make([]IoportRange, n)
-		for i, v := range cIoports {
-			if err := x.Ioports[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Ioports: %v", err)
-			}
-		}
-	}
-	x.Irqs = nil
-	if n := int(xc.num_irqs); n > 0 {
-		cIrqs := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:n:n]
-		x.Irqs = make([]uint32, n)
-		for i, v := range cIrqs {
-			x.Irqs[i] = uint32(v)
-		}
-	}
-	x.Iomem = nil
-	if n := int(xc.num_iomem); n > 0 {
-		cIomem := (*[1 << 28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:n:n]
-		x.Iomem = make([]IomemRange, n)
-		for i, v := range cIomem {
-			if err := x.Iomem[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Iomem: %v", err)
-			}
-		}
-	}
-	if err := x.ClaimMode.fromC(&xc.claim_mode); err != nil {
-		return fmt.Errorf("converting field ClaimMode: %v", err)
-	}
-	x.EventChannels = uint32(xc.event_channels)
-	x.Kernel = C.GoString(xc.kernel)
-	x.Cmdline = C.GoString(xc.cmdline)
-	x.Ramdisk = C.GoString(xc.ramdisk)
-	x.DeviceTree = C.GoString(xc.device_tree)
-	if err := x.Acpi.fromC(&xc.acpi); err != nil {
-		return fmt.Errorf("converting field Acpi: %v", err)
-	}
-	x.Bootloader = C.GoString(xc.bootloader)
-	if err := x.BootloaderArgs.fromC(&xc.bootloader_args); err != nil {
-		return fmt.Errorf("converting field BootloaderArgs: %v", err)
-	}
-	x.TimerMode = TimerMode(xc.timer_mode)
-	if err := x.NestedHvm.fromC(&xc.nested_hvm); err != nil {
-		return fmt.Errorf("converting field NestedHvm: %v", err)
-	}
-	if err := x.Apic.fromC(&xc.apic); err != nil {
-		return fmt.Errorf("converting field Apic: %v", err)
-	}
-	if err := x.DmRestrict.fromC(&xc.dm_restrict); err != nil {
-		return fmt.Errorf("converting field DmRestrict: %v", err)
-	}
-	x.Tee = TeeType(xc.tee)
-	x.Type = DomainType(xc._type)
-	switch x.Type {
-	case DomainTypeHvm:
-		var typeHvm DomainBuildInfoTypeUnionHvm
-		if err := typeHvm.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeHvm: %v", err)
-		}
-		x.TypeUnion = typeHvm
-	case DomainTypePv:
-		var typePv DomainBuildInfoTypeUnionPv
-		if err := typePv.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typePv: %v", err)
-		}
-		x.TypeUnion = typePv
-	case DomainTypePvh:
-		var typePvh DomainBuildInfoTypeUnionPvh
-		if err := typePvh.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typePvh: %v", err)
-		}
-		x.TypeUnion = typePvh
-	case DomainTypeInvalid:
-		x.TypeUnion = nil
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-	x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version)
-	x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart)
-	x.Altp2M = Altp2MMode(xc.altp2m)
-
-	return nil
-}
-
-func (x *DomainBuildInfoTypeUnionHvm) fromC(xc *C.libxl_domain_build_info) error {
-	if DomainType(xc._type) != DomainTypeHvm {
-		return errors.New("expected union key DomainTypeHvm")
-	}
-
-	tmp := (*C.libxl_domain_build_info_type_union_hvm)(unsafe.Pointer(&xc.u[0]))
-	x.Firmware = C.GoString(tmp.firmware)
-	x.Bios = BiosType(tmp.bios)
-	if err := x.Pae.fromC(&tmp.pae); err != nil {
-		return fmt.Errorf("converting field Pae: %v", err)
-	}
-	if err := x.Apic.fromC(&tmp.apic); err != nil {
-		return fmt.Errorf("converting field Apic: %v", err)
-	}
-	if err := x.Acpi.fromC(&tmp.acpi); err != nil {
-		return fmt.Errorf("converting field Acpi: %v", err)
-	}
-	if err := x.AcpiS3.fromC(&tmp.acpi_s3); err != nil {
-		return fmt.Errorf("converting field AcpiS3: %v", err)
-	}
-	if err := x.AcpiS4.fromC(&tmp.acpi_s4); err != nil {
-		return fmt.Errorf("converting field AcpiS4: %v", err)
-	}
-	if err := x.AcpiLaptopSlate.fromC(&tmp.acpi_laptop_slate); err != nil {
-		return fmt.Errorf("converting field AcpiLaptopSlate: %v", err)
-	}
-	if err := x.Nx.fromC(&tmp.nx); err != nil {
-		return fmt.Errorf("converting field Nx: %v", err)
-	}
-	if err := x.Viridian.fromC(&tmp.viridian); err != nil {
-		return fmt.Errorf("converting field Viridian: %v", err)
-	}
-	if err := x.ViridianEnable.fromC(&tmp.viridian_enable); err != nil {
-		return fmt.Errorf("converting field ViridianEnable: %v", err)
-	}
-	if err := x.ViridianDisable.fromC(&tmp.viridian_disable); err != nil {
-		return fmt.Errorf("converting field ViridianDisable: %v", err)
-	}
-	x.Timeoffset = C.GoString(tmp.timeoffset)
-	if err := x.Hpet.fromC(&tmp.hpet); err != nil {
-		return fmt.Errorf("converting field Hpet: %v", err)
-	}
-	if err := x.VptAlign.fromC(&tmp.vpt_align); err != nil {
-		return fmt.Errorf("converting field VptAlign: %v", err)
-	}
-	x.MmioHoleMemkb = uint64(tmp.mmio_hole_memkb)
-	x.TimerMode = TimerMode(tmp.timer_mode)
-	if err := x.NestedHvm.fromC(&tmp.nested_hvm); err != nil {
-		return fmt.Errorf("converting field NestedHvm: %v", err)
-	}
-	if err := x.Altp2M.fromC(&tmp.altp2m); err != nil {
-		return fmt.Errorf("converting field Altp2M: %v", err)
-	}
-	x.SystemFirmware = C.GoString(tmp.system_firmware)
-	x.SmbiosFirmware = C.GoString(tmp.smbios_firmware)
-	x.AcpiFirmware = C.GoString(tmp.acpi_firmware)
-	x.Hdtype = Hdtype(tmp.hdtype)
-	if err := x.Nographic.fromC(&tmp.nographic); err != nil {
-		return fmt.Errorf("converting field Nographic: %v", err)
-	}
-	if err := x.Vga.fromC(&tmp.vga); err != nil {
-		return fmt.Errorf("converting field Vga: %v", err)
-	}
-	if err := x.Vnc.fromC(&tmp.vnc); err != nil {
-		return fmt.Errorf("converting field Vnc: %v", err)
-	}
-	x.Keymap = C.GoString(tmp.keymap)
-	if err := x.Sdl.fromC(&tmp.sdl); err != nil {
-		return fmt.Errorf("converting field Sdl: %v", err)
-	}
-	if err := x.Spice.fromC(&tmp.spice); err != nil {
-		return fmt.Errorf("converting field Spice: %v", err)
-	}
-	if err := x.GfxPassthru.fromC(&tmp.gfx_passthru); err != nil {
-		return fmt.Errorf("converting field GfxPassthru: %v", err)
-	}
-	x.GfxPassthruKind = GfxPassthruKind(tmp.gfx_passthru_kind)
-	x.Serial = C.GoString(tmp.serial)
-	x.Boot = C.GoString(tmp.boot)
-	if err := x.Usb.fromC(&tmp.usb); err != nil {
-		return fmt.Errorf("converting field Usb: %v", err)
-	}
-	x.Usbversion = int(tmp.usbversion)
-	x.Usbdevice = C.GoString(tmp.usbdevice)
-	if err := x.VkbDevice.fromC(&tmp.vkb_device); err != nil {
-		return fmt.Errorf("converting field VkbDevice: %v", err)
-	}
-	x.Soundhw = C.GoString(tmp.soundhw)
-	if err := x.XenPlatformPci.fromC(&tmp.xen_platform_pci); err != nil {
-		return fmt.Errorf("converting field XenPlatformPci: %v", err)
-	}
-	if err := x.UsbdeviceList.fromC(&tmp.usbdevice_list); err != nil {
-		return fmt.Errorf("converting field UsbdeviceList: %v", err)
-	}
-	x.VendorDevice = VendorDevice(tmp.vendor_device)
-	if err := x.MsVmGenid.fromC(&tmp.ms_vm_genid); err != nil {
-		return fmt.Errorf("converting field MsVmGenid: %v", err)
-	}
-	if err := x.SerialList.fromC(&tmp.serial_list); err != nil {
-		return fmt.Errorf("converting field SerialList: %v", err)
-	}
-	if err := x.Rdm.fromC(&tmp.rdm); err != nil {
-		return fmt.Errorf("converting field Rdm: %v", err)
-	}
-	x.RdmMemBoundaryMemkb = uint64(tmp.rdm_mem_boundary_memkb)
-	x.McaCaps = uint64(tmp.mca_caps)
-	return nil
-}
-
-func (x *DomainBuildInfoTypeUnionPv) fromC(xc *C.libxl_domain_build_info) error {
-	if DomainType(xc._type) != DomainTypePv {
-		return errors.New("expected union key DomainTypePv")
-	}
-
-	tmp := (*C.libxl_domain_build_info_type_union_pv)(unsafe.Pointer(&xc.u[0]))
-	x.Kernel = C.GoString(tmp.kernel)
-	x.SlackMemkb = uint64(tmp.slack_memkb)
-	x.Bootloader = C.GoString(tmp.bootloader)
-	if err := x.BootloaderArgs.fromC(&tmp.bootloader_args); err != nil {
-		return fmt.Errorf("converting field BootloaderArgs: %v", err)
-	}
-	x.Cmdline = C.GoString(tmp.cmdline)
-	x.Ramdisk = C.GoString(tmp.ramdisk)
-	x.Features = C.GoString(tmp.features)
-	if err := x.E820Host.fromC(&tmp.e820_host); err != nil {
-		return fmt.Errorf("converting field E820Host: %v", err)
-	}
-	return nil
-}
-
-func (x *DomainBuildInfoTypeUnionPvh) fromC(xc *C.libxl_domain_build_info) error {
-	if DomainType(xc._type) != DomainTypePvh {
-		return errors.New("expected union key DomainTypePvh")
-	}
-
-	tmp := (*C.libxl_domain_build_info_type_union_pvh)(unsafe.Pointer(&xc.u[0]))
-	if err := x.Pvshim.fromC(&tmp.pvshim); err != nil {
-		return fmt.Errorf("converting field Pvshim: %v", err)
-	}
-	x.PvshimPath = C.GoString(tmp.pvshim_path)
-	x.PvshimCmdline = C.GoString(tmp.pvshim_cmdline)
-	x.PvshimExtra = C.GoString(tmp.pvshim_extra)
-	return nil
-}
-
-func (x *DomainBuildInfo) toC(xc *C.libxl_domain_build_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_build_info_dispose(xc)
-		}
-	}()
-
-	xc.max_vcpus = C.int(x.MaxVcpus)
-	if err := x.AvailVcpus.toC(&xc.avail_vcpus); err != nil {
-		return fmt.Errorf("converting field AvailVcpus: %v", err)
-	}
-	if err := x.Cpumap.toC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-	if err := x.Nodemap.toC(&xc.nodemap); err != nil {
-		return fmt.Errorf("converting field Nodemap: %v", err)
-	}
-	if numVcpuHardAffinity := len(x.VcpuHardAffinity); numVcpuHardAffinity > 0 {
-		xc.vcpu_hard_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuHardAffinity) * C.sizeof_libxl_bitmap))
-		xc.num_vcpu_hard_affinity = C.int(numVcpuHardAffinity)
-		cVcpuHardAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:numVcpuHardAffinity:numVcpuHardAffinity]
-		for i, v := range x.VcpuHardAffinity {
-			if err := v.toC(&cVcpuHardAffinity[i]); err != nil {
-				return fmt.Errorf("converting field VcpuHardAffinity: %v", err)
-			}
-		}
-	}
-	if numVcpuSoftAffinity := len(x.VcpuSoftAffinity); numVcpuSoftAffinity > 0 {
-		xc.vcpu_soft_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuSoftAffinity) * C.sizeof_libxl_bitmap))
-		xc.num_vcpu_soft_affinity = C.int(numVcpuSoftAffinity)
-		cVcpuSoftAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:numVcpuSoftAffinity:numVcpuSoftAffinity]
-		for i, v := range x.VcpuSoftAffinity {
-			if err := v.toC(&cVcpuSoftAffinity[i]); err != nil {
-				return fmt.Errorf("converting field VcpuSoftAffinity: %v", err)
-			}
-		}
-	}
-	if err := x.NumaPlacement.toC(&xc.numa_placement); err != nil {
-		return fmt.Errorf("converting field NumaPlacement: %v", err)
-	}
-	xc.tsc_mode = C.libxl_tsc_mode(x.TscMode)
-	xc.max_memkb = C.uint64_t(x.MaxMemkb)
-	xc.target_memkb = C.uint64_t(x.TargetMemkb)
-	xc.video_memkb = C.uint64_t(x.VideoMemkb)
-	xc.shadow_memkb = C.uint64_t(x.ShadowMemkb)
-	xc.iommu_memkb = C.uint64_t(x.IommuMemkb)
-	xc.rtc_timeoffset = C.uint32_t(x.RtcTimeoffset)
-	xc.exec_ssidref = C.uint32_t(x.ExecSsidref)
-	if x.ExecSsidLabel != "" {
-		xc.exec_ssid_label = C.CString(x.ExecSsidLabel)
-	}
-	if err := x.Localtime.toC(&xc.localtime); err != nil {
-		return fmt.Errorf("converting field Localtime: %v", err)
-	}
-	if err := x.DisableMigrate.toC(&xc.disable_migrate); err != nil {
-		return fmt.Errorf("converting field DisableMigrate: %v", err)
-	}
-	if err := x.Cpuid.toC(&xc.cpuid); err != nil {
-		return fmt.Errorf("converting field Cpuid: %v", err)
-	}
-	if x.BlkdevStart != "" {
-		xc.blkdev_start = C.CString(x.BlkdevStart)
-	}
-	if numVnumaNodes := len(x.VnumaNodes); numVnumaNodes > 0 {
-		xc.vnuma_nodes = (*C.libxl_vnode_info)(C.malloc(C.ulong(numVnumaNodes) * C.sizeof_libxl_vnode_info))
-		xc.num_vnuma_nodes = C.int(numVnumaNodes)
-		cVnumaNodes := (*[1 << 28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:numVnumaNodes:numVnumaNodes]
-		for i, v := range x.VnumaNodes {
-			if err := v.toC(&cVnumaNodes[i]); err != nil {
-				return fmt.Errorf("converting field VnumaNodes: %v", err)
-			}
-		}
-	}
-	xc.max_grant_frames = C.uint32_t(x.MaxGrantFrames)
-	xc.max_maptrack_frames = C.uint32_t(x.MaxMaptrackFrames)
-	xc.device_model_version = C.libxl_device_model_version(x.DeviceModelVersion)
-	if err := x.DeviceModelStubdomain.toC(&xc.device_model_stubdomain); err != nil {
-		return fmt.Errorf("converting field DeviceModelStubdomain: %v", err)
-	}
-	if x.DeviceModel != "" {
-		xc.device_model = C.CString(x.DeviceModel)
-	}
-	xc.device_model_ssidref = C.uint32_t(x.DeviceModelSsidref)
-	if x.DeviceModelSsidLabel != "" {
-		xc.device_model_ssid_label = C.CString(x.DeviceModelSsidLabel)
-	}
-	if x.DeviceModelUser != "" {
-		xc.device_model_user = C.CString(x.DeviceModelUser)
-	}
-	if err := x.Extra.toC(&xc.extra); err != nil {
-		return fmt.Errorf("converting field Extra: %v", err)
-	}
-	if err := x.ExtraPv.toC(&xc.extra_pv); err != nil {
-		return fmt.Errorf("converting field ExtraPv: %v", err)
-	}
-	if err := x.ExtraHvm.toC(&xc.extra_hvm); err != nil {
-		return fmt.Errorf("converting field ExtraHvm: %v", err)
-	}
-	if err := x.SchedParams.toC(&xc.sched_params); err != nil {
-		return fmt.Errorf("converting field SchedParams: %v", err)
-	}
-	if numIoports := len(x.Ioports); numIoports > 0 {
-		xc.ioports = (*C.libxl_ioport_range)(C.malloc(C.ulong(numIoports) * C.sizeof_libxl_ioport_range))
-		xc.num_ioports = C.int(numIoports)
-		cIoports := (*[1 << 28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:numIoports:numIoports]
-		for i, v := range x.Ioports {
-			if err := v.toC(&cIoports[i]); err != nil {
-				return fmt.Errorf("converting field Ioports: %v", err)
-			}
-		}
-	}
-	if numIrqs := len(x.Irqs); numIrqs > 0 {
-		xc.irqs = (*C.uint32_t)(C.malloc(C.size_t(numIrqs * numIrqs)))
-		xc.num_irqs = C.int(numIrqs)
-		cIrqs := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:numIrqs:numIrqs]
-		for i, v := range x.Irqs {
-			cIrqs[i] = C.uint32_t(v)
-		}
-	}
-	if numIomem := len(x.Iomem); numIomem > 0 {
-		xc.iomem = (*C.libxl_iomem_range)(C.malloc(C.ulong(numIomem) * C.sizeof_libxl_iomem_range))
-		xc.num_iomem = C.int(numIomem)
-		cIomem := (*[1 << 28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:numIomem:numIomem]
-		for i, v := range x.Iomem {
-			if err := v.toC(&cIomem[i]); err != nil {
-				return fmt.Errorf("converting field Iomem: %v", err)
-			}
-		}
-	}
-	if err := x.ClaimMode.toC(&xc.claim_mode); err != nil {
-		return fmt.Errorf("converting field ClaimMode: %v", err)
-	}
-	xc.event_channels = C.uint32_t(x.EventChannels)
-	if x.Kernel != "" {
-		xc.kernel = C.CString(x.Kernel)
-	}
-	if x.Cmdline != "" {
-		xc.cmdline = C.CString(x.Cmdline)
-	}
-	if x.Ramdisk != "" {
-		xc.ramdisk = C.CString(x.Ramdisk)
-	}
-	if x.DeviceTree != "" {
-		xc.device_tree = C.CString(x.DeviceTree)
-	}
-	if err := x.Acpi.toC(&xc.acpi); err != nil {
-		return fmt.Errorf("converting field Acpi: %v", err)
-	}
-	if x.Bootloader != "" {
-		xc.bootloader = C.CString(x.Bootloader)
-	}
-	if err := x.BootloaderArgs.toC(&xc.bootloader_args); err != nil {
-		return fmt.Errorf("converting field BootloaderArgs: %v", err)
-	}
-	xc.timer_mode = C.libxl_timer_mode(x.TimerMode)
-	if err := x.NestedHvm.toC(&xc.nested_hvm); err != nil {
-		return fmt.Errorf("converting field NestedHvm: %v", err)
-	}
-	if err := x.Apic.toC(&xc.apic); err != nil {
-		return fmt.Errorf("converting field Apic: %v", err)
-	}
-	if err := x.DmRestrict.toC(&xc.dm_restrict); err != nil {
-		return fmt.Errorf("converting field DmRestrict: %v", err)
-	}
-	xc.tee = C.libxl_tee_type(x.Tee)
-	xc._type = C.libxl_domain_type(x.Type)
-	switch x.Type {
-	case DomainTypeHvm:
-		tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionHvm)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var hvm C.libxl_domain_build_info_type_union_hvm
-		if tmp.Firmware != "" {
-			hvm.firmware = C.CString(tmp.Firmware)
-		}
-		hvm.bios = C.libxl_bios_type(tmp.Bios)
-		if err := tmp.Pae.toC(&hvm.pae); err != nil {
-			return fmt.Errorf("converting field Pae: %v", err)
-		}
-		if err := tmp.Apic.toC(&hvm.apic); err != nil {
-			return fmt.Errorf("converting field Apic: %v", err)
-		}
-		if err := tmp.Acpi.toC(&hvm.acpi); err != nil {
-			return fmt.Errorf("converting field Acpi: %v", err)
-		}
-		if err := tmp.AcpiS3.toC(&hvm.acpi_s3); err != nil {
-			return fmt.Errorf("converting field AcpiS3: %v", err)
-		}
-		if err := tmp.AcpiS4.toC(&hvm.acpi_s4); err != nil {
-			return fmt.Errorf("converting field AcpiS4: %v", err)
-		}
-		if err := tmp.AcpiLaptopSlate.toC(&hvm.acpi_laptop_slate); err != nil {
-			return fmt.Errorf("converting field AcpiLaptopSlate: %v", err)
-		}
-		if err := tmp.Nx.toC(&hvm.nx); err != nil {
-			return fmt.Errorf("converting field Nx: %v", err)
-		}
-		if err := tmp.Viridian.toC(&hvm.viridian); err != nil {
-			return fmt.Errorf("converting field Viridian: %v", err)
-		}
-		if err := tmp.ViridianEnable.toC(&hvm.viridian_enable); err != nil {
-			return fmt.Errorf("converting field ViridianEnable: %v", err)
-		}
-		if err := tmp.ViridianDisable.toC(&hvm.viridian_disable); err != nil {
-			return fmt.Errorf("converting field ViridianDisable: %v", err)
-		}
-		if tmp.Timeoffset != "" {
-			hvm.timeoffset = C.CString(tmp.Timeoffset)
-		}
-		if err := tmp.Hpet.toC(&hvm.hpet); err != nil {
-			return fmt.Errorf("converting field Hpet: %v", err)
-		}
-		if err := tmp.VptAlign.toC(&hvm.vpt_align); err != nil {
-			return fmt.Errorf("converting field VptAlign: %v", err)
-		}
-		hvm.mmio_hole_memkb = C.uint64_t(tmp.MmioHoleMemkb)
-		hvm.timer_mode = C.libxl_timer_mode(tmp.TimerMode)
-		if err := tmp.NestedHvm.toC(&hvm.nested_hvm); err != nil {
-			return fmt.Errorf("converting field NestedHvm: %v", err)
-		}
-		if err := tmp.Altp2M.toC(&hvm.altp2m); err != nil {
-			return fmt.Errorf("converting field Altp2M: %v", err)
-		}
-		if tmp.SystemFirmware != "" {
-			hvm.system_firmware = C.CString(tmp.SystemFirmware)
-		}
-		if tmp.SmbiosFirmware != "" {
-			hvm.smbios_firmware = C.CString(tmp.SmbiosFirmware)
-		}
-		if tmp.AcpiFirmware != "" {
-			hvm.acpi_firmware = C.CString(tmp.AcpiFirmware)
-		}
-		hvm.hdtype = C.libxl_hdtype(tmp.Hdtype)
-		if err := tmp.Nographic.toC(&hvm.nographic); err != nil {
-			return fmt.Errorf("converting field Nographic: %v", err)
-		}
-		if err := tmp.Vga.toC(&hvm.vga); err != nil {
-			return fmt.Errorf("converting field Vga: %v", err)
-		}
-		if err := tmp.Vnc.toC(&hvm.vnc); err != nil {
-			return fmt.Errorf("converting field Vnc: %v", err)
-		}
-		if tmp.Keymap != "" {
-			hvm.keymap = C.CString(tmp.Keymap)
-		}
-		if err := tmp.Sdl.toC(&hvm.sdl); err != nil {
-			return fmt.Errorf("converting field Sdl: %v", err)
-		}
-		if err := tmp.Spice.toC(&hvm.spice); err != nil {
-			return fmt.Errorf("converting field Spice: %v", err)
-		}
-		if err := tmp.GfxPassthru.toC(&hvm.gfx_passthru); err != nil {
-			return fmt.Errorf("converting field GfxPassthru: %v", err)
-		}
-		hvm.gfx_passthru_kind = C.libxl_gfx_passthru_kind(tmp.GfxPassthruKind)
-		if tmp.Serial != "" {
-			hvm.serial = C.CString(tmp.Serial)
-		}
-		if tmp.Boot != "" {
-			hvm.boot = C.CString(tmp.Boot)
-		}
-		if err := tmp.Usb.toC(&hvm.usb); err != nil {
-			return fmt.Errorf("converting field Usb: %v", err)
-		}
-		hvm.usbversion = C.int(tmp.Usbversion)
-		if tmp.Usbdevice != "" {
-			hvm.usbdevice = C.CString(tmp.Usbdevice)
-		}
-		if err := tmp.VkbDevice.toC(&hvm.vkb_device); err != nil {
-			return fmt.Errorf("converting field VkbDevice: %v", err)
-		}
-		if tmp.Soundhw != "" {
-			hvm.soundhw = C.CString(tmp.Soundhw)
-		}
-		if err := tmp.XenPlatformPci.toC(&hvm.xen_platform_pci); err != nil {
-			return fmt.Errorf("converting field XenPlatformPci: %v", err)
-		}
-		if err := tmp.UsbdeviceList.toC(&hvm.usbdevice_list); err != nil {
-			return fmt.Errorf("converting field UsbdeviceList: %v", err)
-		}
-		hvm.vendor_device = C.libxl_vendor_device(tmp.VendorDevice)
-		if err := tmp.MsVmGenid.toC(&hvm.ms_vm_genid); err != nil {
-			return fmt.Errorf("converting field MsVmGenid: %v", err)
-		}
-		if err := tmp.SerialList.toC(&hvm.serial_list); err != nil {
-			return fmt.Errorf("converting field SerialList: %v", err)
-		}
-		if err := tmp.Rdm.toC(&hvm.rdm); err != nil {
-			return fmt.Errorf("converting field Rdm: %v", err)
-		}
-		hvm.rdm_mem_boundary_memkb = C.uint64_t(tmp.RdmMemBoundaryMemkb)
-		hvm.mca_caps = C.uint64_t(tmp.McaCaps)
-		hvmBytes := C.GoBytes(unsafe.Pointer(&hvm), C.sizeof_libxl_domain_build_info_type_union_hvm)
-		copy(xc.u[:], hvmBytes)
-	case DomainTypePv:
-		tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPv)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var pv C.libxl_domain_build_info_type_union_pv
-		if tmp.Kernel != "" {
-			pv.kernel = C.CString(tmp.Kernel)
-		}
-		pv.slack_memkb = C.uint64_t(tmp.SlackMemkb)
-		if tmp.Bootloader != "" {
-			pv.bootloader = C.CString(tmp.Bootloader)
-		}
-		if err := tmp.BootloaderArgs.toC(&pv.bootloader_args); err != nil {
-			return fmt.Errorf("converting field BootloaderArgs: %v", err)
-		}
-		if tmp.Cmdline != "" {
-			pv.cmdline = C.CString(tmp.Cmdline)
-		}
-		if tmp.Ramdisk != "" {
-			pv.ramdisk = C.CString(tmp.Ramdisk)
-		}
-		if tmp.Features != "" {
-			pv.features = C.CString(tmp.Features)
-		}
-		if err := tmp.E820Host.toC(&pv.e820_host); err != nil {
-			return fmt.Errorf("converting field E820Host: %v", err)
-		}
-		pvBytes := C.GoBytes(unsafe.Pointer(&pv), C.sizeof_libxl_domain_build_info_type_union_pv)
-		copy(xc.u[:], pvBytes)
-	case DomainTypePvh:
-		tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPvh)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var pvh C.libxl_domain_build_info_type_union_pvh
-		if err := tmp.Pvshim.toC(&pvh.pvshim); err != nil {
-			return fmt.Errorf("converting field Pvshim: %v", err)
-		}
-		if tmp.PvshimPath != "" {
-			pvh.pvshim_path = C.CString(tmp.PvshimPath)
-		}
-		if tmp.PvshimCmdline != "" {
-			pvh.pvshim_cmdline = C.CString(tmp.PvshimCmdline)
-		}
-		if tmp.PvshimExtra != "" {
-			pvh.pvshim_extra = C.CString(tmp.PvshimExtra)
-		}
-		pvhBytes := C.GoBytes(unsafe.Pointer(&pvh), C.sizeof_libxl_domain_build_info_type_union_pvh)
-		copy(xc.u[:], pvhBytes)
-	case DomainTypeInvalid:
-		break
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-	xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion)
-	xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart)
-	xc.altp2m = C.libxl_altp2m_mode(x.Altp2M)
-
-	return nil
-}
-
-// NewDeviceVfb returns an instance of DeviceVfb initialized with defaults.
-func NewDeviceVfb() (*DeviceVfb, error) {
-	var (
-		x  DeviceVfb
-		xc C.libxl_device_vfb
-	)
-
-	C.libxl_device_vfb_init(&xc)
-	defer C.libxl_device_vfb_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVfb) fromC(xc *C.libxl_device_vfb) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	if err := x.Vnc.fromC(&xc.vnc); err != nil {
-		return fmt.Errorf("converting field Vnc: %v", err)
-	}
-	if err := x.Sdl.fromC(&xc.sdl); err != nil {
-		return fmt.Errorf("converting field Sdl: %v", err)
-	}
-	x.Keymap = C.GoString(xc.keymap)
-
-	return nil
-}
-
-func (x *DeviceVfb) toC(xc *C.libxl_device_vfb) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vfb_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	if err := x.Vnc.toC(&xc.vnc); err != nil {
-		return fmt.Errorf("converting field Vnc: %v", err)
-	}
-	if err := x.Sdl.toC(&xc.sdl); err != nil {
-		return fmt.Errorf("converting field Sdl: %v", err)
-	}
-	if x.Keymap != "" {
-		xc.keymap = C.CString(x.Keymap)
-	}
-
-	return nil
-}
-
-// NewDeviceVkb returns an instance of DeviceVkb initialized with defaults.
-func NewDeviceVkb() (*DeviceVkb, error) {
-	var (
-		x  DeviceVkb
-		xc C.libxl_device_vkb
-	)
-
-	C.libxl_device_vkb_init(&xc)
-	defer C.libxl_device_vkb_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVkb) fromC(xc *C.libxl_device_vkb) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.BackendType = VkbBackend(xc.backend_type)
-	x.UniqueId = C.GoString(xc.unique_id)
-	x.FeatureDisableKeyboard = bool(xc.feature_disable_keyboard)
-	x.FeatureDisablePointer = bool(xc.feature_disable_pointer)
-	x.FeatureAbsPointer = bool(xc.feature_abs_pointer)
-	x.FeatureRawPointer = bool(xc.feature_raw_pointer)
-	x.FeatureMultiTouch = bool(xc.feature_multi_touch)
-	x.Width = uint32(xc.width)
-	x.Height = uint32(xc.height)
-	x.MultiTouchWidth = uint32(xc.multi_touch_width)
-	x.MultiTouchHeight = uint32(xc.multi_touch_height)
-	x.MultiTouchNumContacts = uint32(xc.multi_touch_num_contacts)
-
-	return nil
-}
-
-func (x *DeviceVkb) toC(xc *C.libxl_device_vkb) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vkb_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.backend_type = C.libxl_vkb_backend(x.BackendType)
-	if x.UniqueId != "" {
-		xc.unique_id = C.CString(x.UniqueId)
-	}
-	xc.feature_disable_keyboard = C.bool(x.FeatureDisableKeyboard)
-	xc.feature_disable_pointer = C.bool(x.FeatureDisablePointer)
-	xc.feature_abs_pointer = C.bool(x.FeatureAbsPointer)
-	xc.feature_raw_pointer = C.bool(x.FeatureRawPointer)
-	xc.feature_multi_touch = C.bool(x.FeatureMultiTouch)
-	xc.width = C.uint32_t(x.Width)
-	xc.height = C.uint32_t(x.Height)
-	xc.multi_touch_width = C.uint32_t(x.MultiTouchWidth)
-	xc.multi_touch_height = C.uint32_t(x.MultiTouchHeight)
-	xc.multi_touch_num_contacts = C.uint32_t(x.MultiTouchNumContacts)
-
-	return nil
-}
-
-// NewDeviceDisk returns an instance of DeviceDisk initialized with defaults.
-func NewDeviceDisk() (*DeviceDisk, error) {
-	var (
-		x  DeviceDisk
-		xc C.libxl_device_disk
-	)
-
-	C.libxl_device_disk_init(&xc)
-	defer C.libxl_device_disk_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceDisk) fromC(xc *C.libxl_device_disk) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.PdevPath = C.GoString(xc.pdev_path)
-	x.Vdev = C.GoString(xc.vdev)
-	x.Backend = DiskBackend(xc.backend)
-	x.Format = DiskFormat(xc.format)
-	x.Script = C.GoString(xc.script)
-	x.Removable = int(xc.removable)
-	x.Readwrite = int(xc.readwrite)
-	x.IsCdrom = int(xc.is_cdrom)
-	x.DirectIoSafe = bool(xc.direct_io_safe)
-	if err := x.DiscardEnable.fromC(&xc.discard_enable); err != nil {
-		return fmt.Errorf("converting field DiscardEnable: %v", err)
-	}
-	if err := x.ColoEnable.fromC(&xc.colo_enable); err != nil {
-		return fmt.Errorf("converting field ColoEnable: %v", err)
-	}
-	if err := x.ColoRestoreEnable.fromC(&xc.colo_restore_enable); err != nil {
-		return fmt.Errorf("converting field ColoRestoreEnable: %v", err)
-	}
-	x.ColoHost = C.GoString(xc.colo_host)
-	x.ColoPort = int(xc.colo_port)
-	x.ColoExport = C.GoString(xc.colo_export)
-	x.ActiveDisk = C.GoString(xc.active_disk)
-	x.HiddenDisk = C.GoString(xc.hidden_disk)
-
-	return nil
-}
-
-func (x *DeviceDisk) toC(xc *C.libxl_device_disk) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_disk_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	if x.PdevPath != "" {
-		xc.pdev_path = C.CString(x.PdevPath)
-	}
-	if x.Vdev != "" {
-		xc.vdev = C.CString(x.Vdev)
-	}
-	xc.backend = C.libxl_disk_backend(x.Backend)
-	xc.format = C.libxl_disk_format(x.Format)
-	if x.Script != "" {
-		xc.script = C.CString(x.Script)
-	}
-	xc.removable = C.int(x.Removable)
-	xc.readwrite = C.int(x.Readwrite)
-	xc.is_cdrom = C.int(x.IsCdrom)
-	xc.direct_io_safe = C.bool(x.DirectIoSafe)
-	if err := x.DiscardEnable.toC(&xc.discard_enable); err != nil {
-		return fmt.Errorf("converting field DiscardEnable: %v", err)
-	}
-	if err := x.ColoEnable.toC(&xc.colo_enable); err != nil {
-		return fmt.Errorf("converting field ColoEnable: %v", err)
-	}
-	if err := x.ColoRestoreEnable.toC(&xc.colo_restore_enable); err != nil {
-		return fmt.Errorf("converting field ColoRestoreEnable: %v", err)
-	}
-	if x.ColoHost != "" {
-		xc.colo_host = C.CString(x.ColoHost)
-	}
-	xc.colo_port = C.int(x.ColoPort)
-	if x.ColoExport != "" {
-		xc.colo_export = C.CString(x.ColoExport)
-	}
-	if x.ActiveDisk != "" {
-		xc.active_disk = C.CString(x.ActiveDisk)
-	}
-	if x.HiddenDisk != "" {
-		xc.hidden_disk = C.CString(x.HiddenDisk)
-	}
-
-	return nil
-}
-
-// NewDeviceNic returns an instance of DeviceNic initialized with defaults.
-func NewDeviceNic() (*DeviceNic, error) {
-	var (
-		x  DeviceNic
-		xc C.libxl_device_nic
-	)
-
-	C.libxl_device_nic_init(&xc)
-	defer C.libxl_device_nic_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceNic) fromC(xc *C.libxl_device_nic) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.Mtu = int(xc.mtu)
-	x.Model = C.GoString(xc.model)
-	if err := x.Mac.fromC(&xc.mac); err != nil {
-		return fmt.Errorf("converting field Mac: %v", err)
-	}
-	x.Ip = C.GoString(xc.ip)
-	x.Bridge = C.GoString(xc.bridge)
-	x.Ifname = C.GoString(xc.ifname)
-	x.Script = C.GoString(xc.script)
-	x.Nictype = NicType(xc.nictype)
-	x.RateBytesPerInterval = uint64(xc.rate_bytes_per_interval)
-	x.RateIntervalUsecs = uint32(xc.rate_interval_usecs)
-	x.Gatewaydev = C.GoString(xc.gatewaydev)
-	x.ColoftForwarddev = C.GoString(xc.coloft_forwarddev)
-	x.ColoSockMirrorId = C.GoString(xc.colo_sock_mirror_id)
-	x.ColoSockMirrorIp = C.GoString(xc.colo_sock_mirror_ip)
-	x.ColoSockMirrorPort = C.GoString(xc.colo_sock_mirror_port)
-	x.ColoSockComparePriInId = C.GoString(xc.colo_sock_compare_pri_in_id)
-	x.ColoSockComparePriInIp = C.GoString(xc.colo_sock_compare_pri_in_ip)
-	x.ColoSockComparePriInPort = C.GoString(xc.colo_sock_compare_pri_in_port)
-	x.ColoSockCompareSecInId = C.GoString(xc.colo_sock_compare_sec_in_id)
-	x.ColoSockCompareSecInIp = C.GoString(xc.colo_sock_compare_sec_in_ip)
-	x.ColoSockCompareSecInPort = C.GoString(xc.colo_sock_compare_sec_in_port)
-	x.ColoSockCompareNotifyId = C.GoString(xc.colo_sock_compare_notify_id)
-	x.ColoSockCompareNotifyIp = C.GoString(xc.colo_sock_compare_notify_ip)
-	x.ColoSockCompareNotifyPort = C.GoString(xc.colo_sock_compare_notify_port)
-	x.ColoSockRedirector0Id = C.GoString(xc.colo_sock_redirector0_id)
-	x.ColoSockRedirector0Ip = C.GoString(xc.colo_sock_redirector0_ip)
-	x.ColoSockRedirector0Port = C.GoString(xc.colo_sock_redirector0_port)
-	x.ColoSockRedirector1Id = C.GoString(xc.colo_sock_redirector1_id)
-	x.ColoSockRedirector1Ip = C.GoString(xc.colo_sock_redirector1_ip)
-	x.ColoSockRedirector1Port = C.GoString(xc.colo_sock_redirector1_port)
-	x.ColoSockRedirector2Id = C.GoString(xc.colo_sock_redirector2_id)
-	x.ColoSockRedirector2Ip = C.GoString(xc.colo_sock_redirector2_ip)
-	x.ColoSockRedirector2Port = C.GoString(xc.colo_sock_redirector2_port)
-	x.ColoFilterMirrorQueue = C.GoString(xc.colo_filter_mirror_queue)
-	x.ColoFilterMirrorOutdev = C.GoString(xc.colo_filter_mirror_outdev)
-	x.ColoFilterRedirector0Queue = C.GoString(xc.colo_filter_redirector0_queue)
-	x.ColoFilterRedirector0Indev = C.GoString(xc.colo_filter_redirector0_indev)
-	x.ColoFilterRedirector0Outdev = C.GoString(xc.colo_filter_redirector0_outdev)
-	x.ColoFilterRedirector1Queue = C.GoString(xc.colo_filter_redirector1_queue)
-	x.ColoFilterRedirector1Indev = C.GoString(xc.colo_filter_redirector1_indev)
-	x.ColoFilterRedirector1Outdev = C.GoString(xc.colo_filter_redirector1_outdev)
-	x.ColoComparePriIn = C.GoString(xc.colo_compare_pri_in)
-	x.ColoCompareSecIn = C.GoString(xc.colo_compare_sec_in)
-	x.ColoCompareOut = C.GoString(xc.colo_compare_out)
-	x.ColoCompareNotifyDev = C.GoString(xc.colo_compare_notify_dev)
-	x.ColoSockSecRedirector0Id = C.GoString(xc.colo_sock_sec_redirector0_id)
-	x.ColoSockSecRedirector0Ip = C.GoString(xc.colo_sock_sec_redirector0_ip)
-	x.ColoSockSecRedirector0Port = C.GoString(xc.colo_sock_sec_redirector0_port)
-	x.ColoSockSecRedirector1Id = C.GoString(xc.colo_sock_sec_redirector1_id)
-	x.ColoSockSecRedirector1Ip = C.GoString(xc.colo_sock_sec_redirector1_ip)
-	x.ColoSockSecRedirector1Port = C.GoString(xc.colo_sock_sec_redirector1_port)
-	x.ColoFilterSecRedirector0Queue = C.GoString(xc.colo_filter_sec_redirector0_queue)
-	x.ColoFilterSecRedirector0Indev = C.GoString(xc.colo_filter_sec_redirector0_indev)
-	x.ColoFilterSecRedirector0Outdev = C.GoString(xc.colo_filter_sec_redirector0_outdev)
-	x.ColoFilterSecRedirector1Queue = C.GoString(xc.colo_filter_sec_redirector1_queue)
-	x.ColoFilterSecRedirector1Indev = C.GoString(xc.colo_filter_sec_redirector1_indev)
-	x.ColoFilterSecRedirector1Outdev = C.GoString(xc.colo_filter_sec_redirector1_outdev)
-	x.ColoFilterSecRewriter0Queue = C.GoString(xc.colo_filter_sec_rewriter0_queue)
-	x.ColoCheckpointHost = C.GoString(xc.colo_checkpoint_host)
-	x.ColoCheckpointPort = C.GoString(xc.colo_checkpoint_port)
-
-	return nil
-}
-
-func (x *DeviceNic) toC(xc *C.libxl_device_nic) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_nic_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.mtu = C.int(x.Mtu)
-	if x.Model != "" {
-		xc.model = C.CString(x.Model)
-	}
-	if err := x.Mac.toC(&xc.mac); err != nil {
-		return fmt.Errorf("converting field Mac: %v", err)
-	}
-	if x.Ip != "" {
-		xc.ip = C.CString(x.Ip)
-	}
-	if x.Bridge != "" {
-		xc.bridge = C.CString(x.Bridge)
-	}
-	if x.Ifname != "" {
-		xc.ifname = C.CString(x.Ifname)
-	}
-	if x.Script != "" {
-		xc.script = C.CString(x.Script)
-	}
-	xc.nictype = C.libxl_nic_type(x.Nictype)
-	xc.rate_bytes_per_interval = C.uint64_t(x.RateBytesPerInterval)
-	xc.rate_interval_usecs = C.uint32_t(x.RateIntervalUsecs)
-	if x.Gatewaydev != "" {
-		xc.gatewaydev = C.CString(x.Gatewaydev)
-	}
-	if x.ColoftForwarddev != "" {
-		xc.coloft_forwarddev = C.CString(x.ColoftForwarddev)
-	}
-	if x.ColoSockMirrorId != "" {
-		xc.colo_sock_mirror_id = C.CString(x.ColoSockMirrorId)
-	}
-	if x.ColoSockMirrorIp != "" {
-		xc.colo_sock_mirror_ip = C.CString(x.ColoSockMirrorIp)
-	}
-	if x.ColoSockMirrorPort != "" {
-		xc.colo_sock_mirror_port = C.CString(x.ColoSockMirrorPort)
-	}
-	if x.ColoSockComparePriInId != "" {
-		xc.colo_sock_compare_pri_in_id = C.CString(x.ColoSockComparePriInId)
-	}
-	if x.ColoSockComparePriInIp != "" {
-		xc.colo_sock_compare_pri_in_ip = C.CString(x.ColoSockComparePriInIp)
-	}
-	if x.ColoSockComparePriInPort != "" {
-		xc.colo_sock_compare_pri_in_port = C.CString(x.ColoSockComparePriInPort)
-	}
-	if x.ColoSockCompareSecInId != "" {
-		xc.colo_sock_compare_sec_in_id = C.CString(x.ColoSockCompareSecInId)
-	}
-	if x.ColoSockCompareSecInIp != "" {
-		xc.colo_sock_compare_sec_in_ip = C.CString(x.ColoSockCompareSecInIp)
-	}
-	if x.ColoSockCompareSecInPort != "" {
-		xc.colo_sock_compare_sec_in_port = C.CString(x.ColoSockCompareSecInPort)
-	}
-	if x.ColoSockCompareNotifyId != "" {
-		xc.colo_sock_compare_notify_id = C.CString(x.ColoSockCompareNotifyId)
-	}
-	if x.ColoSockCompareNotifyIp != "" {
-		xc.colo_sock_compare_notify_ip = C.CString(x.ColoSockCompareNotifyIp)
-	}
-	if x.ColoSockCompareNotifyPort != "" {
-		xc.colo_sock_compare_notify_port = C.CString(x.ColoSockCompareNotifyPort)
-	}
-	if x.ColoSockRedirector0Id != "" {
-		xc.colo_sock_redirector0_id = C.CString(x.ColoSockRedirector0Id)
-	}
-	if x.ColoSockRedirector0Ip != "" {
-		xc.colo_sock_redirector0_ip = C.CString(x.ColoSockRedirector0Ip)
-	}
-	if x.ColoSockRedirector0Port != "" {
-		xc.colo_sock_redirector0_port = C.CString(x.ColoSockRedirector0Port)
-	}
-	if x.ColoSockRedirector1Id != "" {
-		xc.colo_sock_redirector1_id = C.CString(x.ColoSockRedirector1Id)
-	}
-	if x.ColoSockRedirector1Ip != "" {
-		xc.colo_sock_redirector1_ip = C.CString(x.ColoSockRedirector1Ip)
-	}
-	if x.ColoSockRedirector1Port != "" {
-		xc.colo_sock_redirector1_port = C.CString(x.ColoSockRedirector1Port)
-	}
-	if x.ColoSockRedirector2Id != "" {
-		xc.colo_sock_redirector2_id = C.CString(x.ColoSockRedirector2Id)
-	}
-	if x.ColoSockRedirector2Ip != "" {
-		xc.colo_sock_redirector2_ip = C.CString(x.ColoSockRedirector2Ip)
-	}
-	if x.ColoSockRedirector2Port != "" {
-		xc.colo_sock_redirector2_port = C.CString(x.ColoSockRedirector2Port)
-	}
-	if x.ColoFilterMirrorQueue != "" {
-		xc.colo_filter_mirror_queue = C.CString(x.ColoFilterMirrorQueue)
-	}
-	if x.ColoFilterMirrorOutdev != "" {
-		xc.colo_filter_mirror_outdev = C.CString(x.ColoFilterMirrorOutdev)
-	}
-	if x.ColoFilterRedirector0Queue != "" {
-		xc.colo_filter_redirector0_queue = C.CString(x.ColoFilterRedirector0Queue)
-	}
-	if x.ColoFilterRedirector0Indev != "" {
-		xc.colo_filter_redirector0_indev = C.CString(x.ColoFilterRedirector0Indev)
-	}
-	if x.ColoFilterRedirector0Outdev != "" {
-		xc.colo_filter_redirector0_outdev = C.CString(x.ColoFilterRedirector0Outdev)
-	}
-	if x.ColoFilterRedirector1Queue != "" {
-		xc.colo_filter_redirector1_queue = C.CString(x.ColoFilterRedirector1Queue)
-	}
-	if x.ColoFilterRedirector1Indev != "" {
-		xc.colo_filter_redirector1_indev = C.CString(x.ColoFilterRedirector1Indev)
-	}
-	if x.ColoFilterRedirector1Outdev != "" {
-		xc.colo_filter_redirector1_outdev = C.CString(x.ColoFilterRedirector1Outdev)
-	}
-	if x.ColoComparePriIn != "" {
-		xc.colo_compare_pri_in = C.CString(x.ColoComparePriIn)
-	}
-	if x.ColoCompareSecIn != "" {
-		xc.colo_compare_sec_in = C.CString(x.ColoCompareSecIn)
-	}
-	if x.ColoCompareOut != "" {
-		xc.colo_compare_out = C.CString(x.ColoCompareOut)
-	}
-	if x.ColoCompareNotifyDev != "" {
-		xc.colo_compare_notify_dev = C.CString(x.ColoCompareNotifyDev)
-	}
-	if x.ColoSockSecRedirector0Id != "" {
-		xc.colo_sock_sec_redirector0_id = C.CString(x.ColoSockSecRedirector0Id)
-	}
-	if x.ColoSockSecRedirector0Ip != "" {
-		xc.colo_sock_sec_redirector0_ip = C.CString(x.ColoSockSecRedirector0Ip)
-	}
-	if x.ColoSockSecRedirector0Port != "" {
-		xc.colo_sock_sec_redirector0_port = C.CString(x.ColoSockSecRedirector0Port)
-	}
-	if x.ColoSockSecRedirector1Id != "" {
-		xc.colo_sock_sec_redirector1_id = C.CString(x.ColoSockSecRedirector1Id)
-	}
-	if x.ColoSockSecRedirector1Ip != "" {
-		xc.colo_sock_sec_redirector1_ip = C.CString(x.ColoSockSecRedirector1Ip)
-	}
-	if x.ColoSockSecRedirector1Port != "" {
-		xc.colo_sock_sec_redirector1_port = C.CString(x.ColoSockSecRedirector1Port)
-	}
-	if x.ColoFilterSecRedirector0Queue != "" {
-		xc.colo_filter_sec_redirector0_queue = C.CString(x.ColoFilterSecRedirector0Queue)
-	}
-	if x.ColoFilterSecRedirector0Indev != "" {
-		xc.colo_filter_sec_redirector0_indev = C.CString(x.ColoFilterSecRedirector0Indev)
-	}
-	if x.ColoFilterSecRedirector0Outdev != "" {
-		xc.colo_filter_sec_redirector0_outdev = C.CString(x.ColoFilterSecRedirector0Outdev)
-	}
-	if x.ColoFilterSecRedirector1Queue != "" {
-		xc.colo_filter_sec_redirector1_queue = C.CString(x.ColoFilterSecRedirector1Queue)
-	}
-	if x.ColoFilterSecRedirector1Indev != "" {
-		xc.colo_filter_sec_redirector1_indev = C.CString(x.ColoFilterSecRedirector1Indev)
-	}
-	if x.ColoFilterSecRedirector1Outdev != "" {
-		xc.colo_filter_sec_redirector1_outdev = C.CString(x.ColoFilterSecRedirector1Outdev)
-	}
-	if x.ColoFilterSecRewriter0Queue != "" {
-		xc.colo_filter_sec_rewriter0_queue = C.CString(x.ColoFilterSecRewriter0Queue)
-	}
-	if x.ColoCheckpointHost != "" {
-		xc.colo_checkpoint_host = C.CString(x.ColoCheckpointHost)
-	}
-	if x.ColoCheckpointPort != "" {
-		xc.colo_checkpoint_port = C.CString(x.ColoCheckpointPort)
-	}
-
-	return nil
-}
-
-// NewDevicePci returns an instance of DevicePci initialized with defaults.
-func NewDevicePci() (*DevicePci, error) {
-	var (
-		x  DevicePci
-		xc C.libxl_device_pci
-	)
-
-	C.libxl_device_pci_init(&xc)
-	defer C.libxl_device_pci_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DevicePci) fromC(xc *C.libxl_device_pci) error {
-	x.Func = byte(xc._func)
-	x.Dev = byte(xc.dev)
-	x.Bus = byte(xc.bus)
-	x.Domain = int(xc.domain)
-	x.Vdevfn = uint32(xc.vdevfn)
-	x.VfuncMask = uint32(xc.vfunc_mask)
-	x.Msitranslate = bool(xc.msitranslate)
-	x.PowerMgmt = bool(xc.power_mgmt)
-	x.Permissive = bool(xc.permissive)
-	x.Seize = bool(xc.seize)
-	x.RdmPolicy = RdmReservePolicy(xc.rdm_policy)
-
-	return nil
-}
-
-func (x *DevicePci) toC(xc *C.libxl_device_pci) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_pci_dispose(xc)
-		}
-	}()
-
-	xc._func = C.uint8_t(x.Func)
-	xc.dev = C.uint8_t(x.Dev)
-	xc.bus = C.uint8_t(x.Bus)
-	xc.domain = C.int(x.Domain)
-	xc.vdevfn = C.uint32_t(x.Vdevfn)
-	xc.vfunc_mask = C.uint32_t(x.VfuncMask)
-	xc.msitranslate = C.bool(x.Msitranslate)
-	xc.power_mgmt = C.bool(x.PowerMgmt)
-	xc.permissive = C.bool(x.Permissive)
-	xc.seize = C.bool(x.Seize)
-	xc.rdm_policy = C.libxl_rdm_reserve_policy(x.RdmPolicy)
-
-	return nil
-}
-
-// NewDeviceRdm returns an instance of DeviceRdm initialized with defaults.
-func NewDeviceRdm() (*DeviceRdm, error) {
-	var (
-		x  DeviceRdm
-		xc C.libxl_device_rdm
-	)
-
-	C.libxl_device_rdm_init(&xc)
-	defer C.libxl_device_rdm_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceRdm) fromC(xc *C.libxl_device_rdm) error {
-	x.Start = uint64(xc.start)
-	x.Size = uint64(xc.size)
-	x.Policy = RdmReservePolicy(xc.policy)
-
-	return nil
-}
-
-func (x *DeviceRdm) toC(xc *C.libxl_device_rdm) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_rdm_dispose(xc)
-		}
-	}()
-
-	xc.start = C.uint64_t(x.Start)
-	xc.size = C.uint64_t(x.Size)
-	xc.policy = C.libxl_rdm_reserve_policy(x.Policy)
-
-	return nil
-}
-
-// NewDeviceUsbctrl returns an instance of DeviceUsbctrl initialized with defaults.
-func NewDeviceUsbctrl() (*DeviceUsbctrl, error) {
-	var (
-		x  DeviceUsbctrl
-		xc C.libxl_device_usbctrl
-	)
-
-	C.libxl_device_usbctrl_init(&xc)
-	defer C.libxl_device_usbctrl_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceUsbctrl) fromC(xc *C.libxl_device_usbctrl) error {
-	x.Type = UsbctrlType(xc._type)
-	x.Devid = Devid(xc.devid)
-	x.Version = int(xc.version)
-	x.Ports = int(xc.ports)
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-
-	return nil
-}
-
-func (x *DeviceUsbctrl) toC(xc *C.libxl_device_usbctrl) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_usbctrl_dispose(xc)
-		}
-	}()
-
-	xc._type = C.libxl_usbctrl_type(x.Type)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.version = C.int(x.Version)
-	xc.ports = C.int(x.Ports)
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-
-	return nil
-}
-
-// NewDeviceUsbdev returns an instance of DeviceUsbdev initialized with defaults.
-func NewDeviceUsbdev(utype UsbdevType) (*DeviceUsbdev, error) {
-	var (
-		x  DeviceUsbdev
-		xc C.libxl_device_usbdev
-	)
-
-	C.libxl_device_usbdev_init(&xc)
-	C.libxl_device_usbdev_init_type(&xc, C.libxl_usbdev_type(utype))
-	defer C.libxl_device_usbdev_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceUsbdev) fromC(xc *C.libxl_device_usbdev) error {
-	x.Ctrl = Devid(xc.ctrl)
-	x.Port = int(xc.port)
-	x.Type = UsbdevType(xc._type)
-	switch x.Type {
-	case UsbdevTypeHostdev:
-		var typeHostdev DeviceUsbdevTypeUnionHostdev
-		if err := typeHostdev.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeHostdev: %v", err)
-		}
-		x.TypeUnion = typeHostdev
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-func (x *DeviceUsbdevTypeUnionHostdev) fromC(xc *C.libxl_device_usbdev) error {
-	if UsbdevType(xc._type) != UsbdevTypeHostdev {
-		return errors.New("expected union key UsbdevTypeHostdev")
-	}
-
-	tmp := (*C.libxl_device_usbdev_type_union_hostdev)(unsafe.Pointer(&xc.u[0]))
-	x.Hostbus = byte(tmp.hostbus)
-	x.Hostaddr = byte(tmp.hostaddr)
-	return nil
-}
-
-func (x *DeviceUsbdev) toC(xc *C.libxl_device_usbdev) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_usbdev_dispose(xc)
-		}
-	}()
-
-	xc.ctrl = C.libxl_devid(x.Ctrl)
-	xc.port = C.int(x.Port)
-	xc._type = C.libxl_usbdev_type(x.Type)
-	switch x.Type {
-	case UsbdevTypeHostdev:
-		tmp, ok := x.TypeUnion.(DeviceUsbdevTypeUnionHostdev)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var hostdev C.libxl_device_usbdev_type_union_hostdev
-		hostdev.hostbus = C.uint8_t(tmp.Hostbus)
-		hostdev.hostaddr = C.uint8_t(tmp.Hostaddr)
-		hostdevBytes := C.GoBytes(unsafe.Pointer(&hostdev), C.sizeof_libxl_device_usbdev_type_union_hostdev)
-		copy(xc.u[:], hostdevBytes)
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-// NewDeviceDtdev returns an instance of DeviceDtdev initialized with defaults.
-func NewDeviceDtdev() (*DeviceDtdev, error) {
-	var (
-		x  DeviceDtdev
-		xc C.libxl_device_dtdev
-	)
-
-	C.libxl_device_dtdev_init(&xc)
-	defer C.libxl_device_dtdev_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceDtdev) fromC(xc *C.libxl_device_dtdev) error {
-	x.Path = C.GoString(xc.path)
-
-	return nil
-}
-
-func (x *DeviceDtdev) toC(xc *C.libxl_device_dtdev) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_dtdev_dispose(xc)
-		}
-	}()
-
-	if x.Path != "" {
-		xc.path = C.CString(x.Path)
-	}
-
-	return nil
-}
-
-// NewDeviceVtpm returns an instance of DeviceVtpm initialized with defaults.
-func NewDeviceVtpm() (*DeviceVtpm, error) {
-	var (
-		x  DeviceVtpm
-		xc C.libxl_device_vtpm
-	)
-
-	C.libxl_device_vtpm_init(&xc)
-	defer C.libxl_device_vtpm_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVtpm) fromC(xc *C.libxl_device_vtpm) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-
-	return nil
-}
-
-func (x *DeviceVtpm) toC(xc *C.libxl_device_vtpm) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vtpm_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-
-	return nil
-}
-
-// NewDeviceP9 returns an instance of DeviceP9 initialized with defaults.
-func NewDeviceP9() (*DeviceP9, error) {
-	var (
-		x  DeviceP9
-		xc C.libxl_device_p9
-	)
-
-	C.libxl_device_p9_init(&xc)
-	defer C.libxl_device_p9_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceP9) fromC(xc *C.libxl_device_p9) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Tag = C.GoString(xc.tag)
-	x.Path = C.GoString(xc.path)
-	x.SecurityModel = C.GoString(xc.security_model)
-	x.Devid = Devid(xc.devid)
-
-	return nil
-}
-
-func (x *DeviceP9) toC(xc *C.libxl_device_p9) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_p9_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	if x.Tag != "" {
-		xc.tag = C.CString(x.Tag)
-	}
-	if x.Path != "" {
-		xc.path = C.CString(x.Path)
-	}
-	if x.SecurityModel != "" {
-		xc.security_model = C.CString(x.SecurityModel)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-
-	return nil
-}
-
-// NewDevicePvcallsif returns an instance of DevicePvcallsif initialized with defaults.
-func NewDevicePvcallsif() (*DevicePvcallsif, error) {
-	var (
-		x  DevicePvcallsif
-		xc C.libxl_device_pvcallsif
-	)
-
-	C.libxl_device_pvcallsif_init(&xc)
-	defer C.libxl_device_pvcallsif_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DevicePvcallsif) fromC(xc *C.libxl_device_pvcallsif) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-
-	return nil
-}
-
-func (x *DevicePvcallsif) toC(xc *C.libxl_device_pvcallsif) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_pvcallsif_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-
-	return nil
-}
-
-// NewDeviceChannel returns an instance of DeviceChannel initialized with defaults.
-func NewDeviceChannel(connection ChannelConnection) (*DeviceChannel, error) {
-	var (
-		x  DeviceChannel
-		xc C.libxl_device_channel
-	)
-
-	C.libxl_device_channel_init(&xc)
-	C.libxl_device_channel_init_connection(&xc, C.libxl_channel_connection(connection))
-	defer C.libxl_device_channel_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceChannel) fromC(xc *C.libxl_device_channel) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.Name = C.GoString(xc.name)
-	x.Connection = ChannelConnection(xc.connection)
-	switch x.Connection {
-	case ChannelConnectionUnknown:
-		x.ConnectionUnion = nil
-	case ChannelConnectionPty:
-		x.ConnectionUnion = nil
-	case ChannelConnectionSocket:
-		var connectionSocket DeviceChannelConnectionUnionSocket
-		if err := connectionSocket.fromC(xc); err != nil {
-			return fmt.Errorf("converting field connectionSocket: %v", err)
-		}
-		x.ConnectionUnion = connectionSocket
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Connection)
-	}
-
-	return nil
-}
-
-func (x *DeviceChannelConnectionUnionSocket) fromC(xc *C.libxl_device_channel) error {
-	if ChannelConnection(xc.connection) != ChannelConnectionSocket {
-		return errors.New("expected union key ChannelConnectionSocket")
-	}
-
-	tmp := (*C.libxl_device_channel_connection_union_socket)(unsafe.Pointer(&xc.u[0]))
-	x.Path = C.GoString(tmp.path)
-	return nil
-}
-
-func (x *DeviceChannel) toC(xc *C.libxl_device_channel) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_channel_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	if x.Name != "" {
-		xc.name = C.CString(x.Name)
-	}
-	xc.connection = C.libxl_channel_connection(x.Connection)
-	switch x.Connection {
-	case ChannelConnectionUnknown:
-		break
-	case ChannelConnectionPty:
-		break
-	case ChannelConnectionSocket:
-		tmp, ok := x.ConnectionUnion.(DeviceChannelConnectionUnionSocket)
-		if !ok {
-			return errors.New("wrong type for union key connection")
-		}
-		var socket C.libxl_device_channel_connection_union_socket
-		if tmp.Path != "" {
-			socket.path = C.CString(tmp.Path)
-		}
-		socketBytes := C.GoBytes(unsafe.Pointer(&socket), C.sizeof_libxl_device_channel_connection_union_socket)
-		copy(xc.u[:], socketBytes)
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Connection)
-	}
-
-	return nil
-}
-
-// NewConnectorParam returns an instance of ConnectorParam initialized with defaults.
-func NewConnectorParam() (*ConnectorParam, error) {
-	var (
-		x  ConnectorParam
-		xc C.libxl_connector_param
-	)
-
-	C.libxl_connector_param_init(&xc)
-	defer C.libxl_connector_param_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *ConnectorParam) fromC(xc *C.libxl_connector_param) error {
-	x.UniqueId = C.GoString(xc.unique_id)
-	x.Width = uint32(xc.width)
-	x.Height = uint32(xc.height)
-
-	return nil
-}
-
-func (x *ConnectorParam) toC(xc *C.libxl_connector_param) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_connector_param_dispose(xc)
-		}
-	}()
-
-	if x.UniqueId != "" {
-		xc.unique_id = C.CString(x.UniqueId)
-	}
-	xc.width = C.uint32_t(x.Width)
-	xc.height = C.uint32_t(x.Height)
-
-	return nil
-}
-
-// NewDeviceVdispl returns an instance of DeviceVdispl initialized with defaults.
-func NewDeviceVdispl() (*DeviceVdispl, error) {
-	var (
-		x  DeviceVdispl
-		xc C.libxl_device_vdispl
-	)
-
-	C.libxl_device_vdispl_init(&xc)
-	defer C.libxl_device_vdispl_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVdispl) fromC(xc *C.libxl_device_vdispl) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.BeAlloc = bool(xc.be_alloc)
-	x.Connectors = nil
-	if n := int(xc.num_connectors); n > 0 {
-		cConnectors := (*[1 << 28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:n:n]
-		x.Connectors = make([]ConnectorParam, n)
-		for i, v := range cConnectors {
-			if err := x.Connectors[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Connectors: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-func (x *DeviceVdispl) toC(xc *C.libxl_device_vdispl) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vdispl_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.be_alloc = C.bool(x.BeAlloc)
-	if numConnectors := len(x.Connectors); numConnectors > 0 {
-		xc.connectors = (*C.libxl_connector_param)(C.malloc(C.ulong(numConnectors) * C.sizeof_libxl_connector_param))
-		xc.num_connectors = C.int(numConnectors)
-		cConnectors := (*[1 << 28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors]
-		for i, v := range x.Connectors {
-			if err := v.toC(&cConnectors[i]); err != nil {
-				return fmt.Errorf("converting field Connectors: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewVsndParams returns an instance of VsndParams initialized with defaults.
-func NewVsndParams() (*VsndParams, error) {
-	var (
-		x  VsndParams
-		xc C.libxl_vsnd_params
-	)
-
-	C.libxl_vsnd_params_init(&xc)
-	defer C.libxl_vsnd_params_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VsndParams) fromC(xc *C.libxl_vsnd_params) error {
-	x.SampleRates = nil
-	if n := int(xc.num_sample_rates); n > 0 {
-		cSampleRates := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:n:n]
-		x.SampleRates = make([]uint32, n)
-		for i, v := range cSampleRates {
-			x.SampleRates[i] = uint32(v)
-		}
-	}
-	x.SampleFormats = nil
-	if n := int(xc.num_sample_formats); n > 0 {
-		cSampleFormats := (*[1 << 28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:n:n]
-		x.SampleFormats = make([]VsndPcmFormat, n)
-		for i, v := range cSampleFormats {
-			x.SampleFormats[i] = VsndPcmFormat(v)
-		}
-	}
-	x.ChannelsMin = uint32(xc.channels_min)
-	x.ChannelsMax = uint32(xc.channels_max)
-	x.BufferSize = uint32(xc.buffer_size)
-
-	return nil
-}
-
-func (x *VsndParams) toC(xc *C.libxl_vsnd_params) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vsnd_params_dispose(xc)
-		}
-	}()
-
-	if numSampleRates := len(x.SampleRates); numSampleRates > 0 {
-		xc.sample_rates = (*C.uint32_t)(C.malloc(C.size_t(numSampleRates * numSampleRates)))
-		xc.num_sample_rates = C.int(numSampleRates)
-		cSampleRates := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:numSampleRates:numSampleRates]
-		for i, v := range x.SampleRates {
-			cSampleRates[i] = C.uint32_t(v)
-		}
-	}
-	if numSampleFormats := len(x.SampleFormats); numSampleFormats > 0 {
-		xc.sample_formats = (*C.libxl_vsnd_pcm_format)(C.malloc(C.size_t(numSampleFormats * numSampleFormats)))
-		xc.num_sample_formats = C.int(numSampleFormats)
-		cSampleFormats := (*[1 << 28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:numSampleFormats:numSampleFormats]
-		for i, v := range x.SampleFormats {
-			cSampleFormats[i] = C.libxl_vsnd_pcm_format(v)
-		}
-	}
-	xc.channels_min = C.uint32_t(x.ChannelsMin)
-	xc.channels_max = C.uint32_t(x.ChannelsMax)
-	xc.buffer_size = C.uint32_t(x.BufferSize)
-
-	return nil
-}
-
-// NewVsndStream returns an instance of VsndStream initialized with defaults.
-func NewVsndStream() (*VsndStream, error) {
-	var (
-		x  VsndStream
-		xc C.libxl_vsnd_stream
-	)
-
-	C.libxl_vsnd_stream_init(&xc)
-	defer C.libxl_vsnd_stream_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VsndStream) fromC(xc *C.libxl_vsnd_stream) error {
-	x.UniqueId = C.GoString(xc.unique_id)
-	x.Type = VsndStreamType(xc._type)
-	if err := x.Params.fromC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-
-	return nil
-}
-
-func (x *VsndStream) toC(xc *C.libxl_vsnd_stream) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vsnd_stream_dispose(xc)
-		}
-	}()
-
-	if x.UniqueId != "" {
-		xc.unique_id = C.CString(x.UniqueId)
-	}
-	xc._type = C.libxl_vsnd_stream_type(x.Type)
-	if err := x.Params.toC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-
-	return nil
-}
-
-// NewVsndPcm returns an instance of VsndPcm initialized with defaults.
-func NewVsndPcm() (*VsndPcm, error) {
-	var (
-		x  VsndPcm
-		xc C.libxl_vsnd_pcm
-	)
-
-	C.libxl_vsnd_pcm_init(&xc)
-	defer C.libxl_vsnd_pcm_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *VsndPcm) fromC(xc *C.libxl_vsnd_pcm) error {
-	x.Name = C.GoString(xc.name)
-	if err := x.Params.fromC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-	x.Streams = nil
-	if n := int(xc.num_vsnd_streams); n > 0 {
-		cStreams := (*[1 << 28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:n:n]
-		x.Streams = make([]VsndStream, n)
-		for i, v := range cStreams {
-			if err := x.Streams[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Streams: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-func (x *VsndPcm) toC(xc *C.libxl_vsnd_pcm) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vsnd_pcm_dispose(xc)
-		}
-	}()
-
-	if x.Name != "" {
-		xc.name = C.CString(x.Name)
-	}
-	if err := x.Params.toC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-	if numVsndStreams := len(x.Streams); numVsndStreams > 0 {
-		xc.streams = (*C.libxl_vsnd_stream)(C.malloc(C.ulong(numVsndStreams) * C.sizeof_libxl_vsnd_stream))
-		xc.num_vsnd_streams = C.int(numVsndStreams)
-		cStreams := (*[1 << 28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams]
-		for i, v := range x.Streams {
-			if err := v.toC(&cStreams[i]); err != nil {
-				return fmt.Errorf("converting field Streams: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewDeviceVsnd returns an instance of DeviceVsnd initialized with defaults.
-func NewDeviceVsnd() (*DeviceVsnd, error) {
-	var (
-		x  DeviceVsnd
-		xc C.libxl_device_vsnd
-	)
-
-	C.libxl_device_vsnd_init(&xc)
-	defer C.libxl_device_vsnd_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DeviceVsnd) fromC(xc *C.libxl_device_vsnd) error {
-	x.BackendDomid = Domid(xc.backend_domid)
-	x.BackendDomname = C.GoString(xc.backend_domname)
-	x.Devid = Devid(xc.devid)
-	x.ShortName = C.GoString(xc.short_name)
-	x.LongName = C.GoString(xc.long_name)
-	if err := x.Params.fromC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-	x.Pcms = nil
-	if n := int(xc.num_vsnd_pcms); n > 0 {
-		cPcms := (*[1 << 28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:n:n]
-		x.Pcms = make([]VsndPcm, n)
-		for i, v := range cPcms {
-			if err := x.Pcms[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Pcms: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-func (x *DeviceVsnd) toC(xc *C.libxl_device_vsnd) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_device_vsnd_dispose(xc)
-		}
-	}()
-
-	xc.backend_domid = C.libxl_domid(x.BackendDomid)
-	if x.BackendDomname != "" {
-		xc.backend_domname = C.CString(x.BackendDomname)
-	}
-	xc.devid = C.libxl_devid(x.Devid)
-	if x.ShortName != "" {
-		xc.short_name = C.CString(x.ShortName)
-	}
-	if x.LongName != "" {
-		xc.long_name = C.CString(x.LongName)
-	}
-	if err := x.Params.toC(&xc.params); err != nil {
-		return fmt.Errorf("converting field Params: %v", err)
-	}
-	if numVsndPcms := len(x.Pcms); numVsndPcms > 0 {
-		xc.pcms = (*C.libxl_vsnd_pcm)(C.malloc(C.ulong(numVsndPcms) * C.sizeof_libxl_vsnd_pcm))
-		xc.num_vsnd_pcms = C.int(numVsndPcms)
-		cPcms := (*[1 << 28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms]
-		for i, v := range x.Pcms {
-			if err := v.toC(&cPcms[i]); err != nil {
-				return fmt.Errorf("converting field Pcms: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewDomainConfig returns an instance of DomainConfig initialized with defaults.
-func NewDomainConfig() (*DomainConfig, error) {
-	var (
-		x  DomainConfig
-		xc C.libxl_domain_config
-	)
-
-	C.libxl_domain_config_init(&xc)
-	defer C.libxl_domain_config_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainConfig) fromC(xc *C.libxl_domain_config) error {
-	if err := x.CInfo.fromC(&xc.c_info); err != nil {
-		return fmt.Errorf("converting field CInfo: %v", err)
-	}
-	if err := x.BInfo.fromC(&xc.b_info); err != nil {
-		return fmt.Errorf("converting field BInfo: %v", err)
-	}
-	x.Disks = nil
-	if n := int(xc.num_disks); n > 0 {
-		cDisks := (*[1 << 28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:n:n]
-		x.Disks = make([]DeviceDisk, n)
-		for i, v := range cDisks {
-			if err := x.Disks[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Disks: %v", err)
-			}
-		}
-	}
-	x.Nics = nil
-	if n := int(xc.num_nics); n > 0 {
-		cNics := (*[1 << 28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:n:n]
-		x.Nics = make([]DeviceNic, n)
-		for i, v := range cNics {
-			if err := x.Nics[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Nics: %v", err)
-			}
-		}
-	}
-	x.Pcidevs = nil
-	if n := int(xc.num_pcidevs); n > 0 {
-		cPcidevs := (*[1 << 28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:n:n]
-		x.Pcidevs = make([]DevicePci, n)
-		for i, v := range cPcidevs {
-			if err := x.Pcidevs[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Pcidevs: %v", err)
-			}
-		}
-	}
-	x.Rdms = nil
-	if n := int(xc.num_rdms); n > 0 {
-		cRdms := (*[1 << 28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:n:n]
-		x.Rdms = make([]DeviceRdm, n)
-		for i, v := range cRdms {
-			if err := x.Rdms[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Rdms: %v", err)
-			}
-		}
-	}
-	x.Dtdevs = nil
-	if n := int(xc.num_dtdevs); n > 0 {
-		cDtdevs := (*[1 << 28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:n:n]
-		x.Dtdevs = make([]DeviceDtdev, n)
-		for i, v := range cDtdevs {
-			if err := x.Dtdevs[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Dtdevs: %v", err)
-			}
-		}
-	}
-	x.Vfbs = nil
-	if n := int(xc.num_vfbs); n > 0 {
-		cVfbs := (*[1 << 28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:n:n]
-		x.Vfbs = make([]DeviceVfb, n)
-		for i, v := range cVfbs {
-			if err := x.Vfbs[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Vfbs: %v", err)
-			}
-		}
-	}
-	x.Vkbs = nil
-	if n := int(xc.num_vkbs); n > 0 {
-		cVkbs := (*[1 << 28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:n:n]
-		x.Vkbs = make([]DeviceVkb, n)
-		for i, v := range cVkbs {
-			if err := x.Vkbs[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Vkbs: %v", err)
-			}
-		}
-	}
-	x.Vtpms = nil
-	if n := int(xc.num_vtpms); n > 0 {
-		cVtpms := (*[1 << 28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:n:n]
-		x.Vtpms = make([]DeviceVtpm, n)
-		for i, v := range cVtpms {
-			if err := x.Vtpms[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Vtpms: %v", err)
-			}
-		}
-	}
-	x.P9S = nil
-	if n := int(xc.num_p9s); n > 0 {
-		cP9S := (*[1 << 28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:n:n]
-		x.P9S = make([]DeviceP9, n)
-		for i, v := range cP9S {
-			if err := x.P9S[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field P9S: %v", err)
-			}
-		}
-	}
-	x.Pvcallsifs = nil
-	if n := int(xc.num_pvcallsifs); n > 0 {
-		cPvcallsifs := (*[1 << 28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:n:n]
-		x.Pvcallsifs = make([]DevicePvcallsif, n)
-		for i, v := range cPvcallsifs {
-			if err := x.Pvcallsifs[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Pvcallsifs: %v", err)
-			}
-		}
-	}
-	x.Vdispls = nil
-	if n := int(xc.num_vdispls); n > 0 {
-		cVdispls := (*[1 << 28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:n:n]
-		x.Vdispls = make([]DeviceVdispl, n)
-		for i, v := range cVdispls {
-			if err := x.Vdispls[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Vdispls: %v", err)
-			}
-		}
-	}
-	x.Vsnds = nil
-	if n := int(xc.num_vsnds); n > 0 {
-		cVsnds := (*[1 << 28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:n:n]
-		x.Vsnds = make([]DeviceVsnd, n)
-		for i, v := range cVsnds {
-			if err := x.Vsnds[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Vsnds: %v", err)
-			}
-		}
-	}
-	x.Channels = nil
-	if n := int(xc.num_channels); n > 0 {
-		cChannels := (*[1 << 28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:n:n]
-		x.Channels = make([]DeviceChannel, n)
-		for i, v := range cChannels {
-			if err := x.Channels[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Channels: %v", err)
-			}
-		}
-	}
-	x.Usbctrls = nil
-	if n := int(xc.num_usbctrls); n > 0 {
-		cUsbctrls := (*[1 << 28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:n:n]
-		x.Usbctrls = make([]DeviceUsbctrl, n)
-		for i, v := range cUsbctrls {
-			if err := x.Usbctrls[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Usbctrls: %v", err)
-			}
-		}
-	}
-	x.Usbdevs = nil
-	if n := int(xc.num_usbdevs); n > 0 {
-		cUsbdevs := (*[1 << 28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:n:n]
-		x.Usbdevs = make([]DeviceUsbdev, n)
-		for i, v := range cUsbdevs {
-			if err := x.Usbdevs[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Usbdevs: %v", err)
-			}
-		}
-	}
-	x.OnPoweroff = ActionOnShutdown(xc.on_poweroff)
-	x.OnReboot = ActionOnShutdown(xc.on_reboot)
-	x.OnWatchdog = ActionOnShutdown(xc.on_watchdog)
-	x.OnCrash = ActionOnShutdown(xc.on_crash)
-	x.OnSoftReset = ActionOnShutdown(xc.on_soft_reset)
-
-	return nil
-}
-
-func (x *DomainConfig) toC(xc *C.libxl_domain_config) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_config_dispose(xc)
-		}
-	}()
-
-	if err := x.CInfo.toC(&xc.c_info); err != nil {
-		return fmt.Errorf("converting field CInfo: %v", err)
-	}
-	if err := x.BInfo.toC(&xc.b_info); err != nil {
-		return fmt.Errorf("converting field BInfo: %v", err)
-	}
-	if numDisks := len(x.Disks); numDisks > 0 {
-		xc.disks = (*C.libxl_device_disk)(C.malloc(C.ulong(numDisks) * C.sizeof_libxl_device_disk))
-		xc.num_disks = C.int(numDisks)
-		cDisks := (*[1 << 28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:numDisks:numDisks]
-		for i, v := range x.Disks {
-			if err := v.toC(&cDisks[i]); err != nil {
-				return fmt.Errorf("converting field Disks: %v", err)
-			}
-		}
-	}
-	if numNics := len(x.Nics); numNics > 0 {
-		xc.nics = (*C.libxl_device_nic)(C.malloc(C.ulong(numNics) * C.sizeof_libxl_device_nic))
-		xc.num_nics = C.int(numNics)
-		cNics := (*[1 << 28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:numNics:numNics]
-		for i, v := range x.Nics {
-			if err := v.toC(&cNics[i]); err != nil {
-				return fmt.Errorf("converting field Nics: %v", err)
-			}
-		}
-	}
-	if numPcidevs := len(x.Pcidevs); numPcidevs > 0 {
-		xc.pcidevs = (*C.libxl_device_pci)(C.malloc(C.ulong(numPcidevs) * C.sizeof_libxl_device_pci))
-		xc.num_pcidevs = C.int(numPcidevs)
-		cPcidevs := (*[1 << 28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:numPcidevs:numPcidevs]
-		for i, v := range x.Pcidevs {
-			if err := v.toC(&cPcidevs[i]); err != nil {
-				return fmt.Errorf("converting field Pcidevs: %v", err)
-			}
-		}
-	}
-	if numRdms := len(x.Rdms); numRdms > 0 {
-		xc.rdms = (*C.libxl_device_rdm)(C.malloc(C.ulong(numRdms) * C.sizeof_libxl_device_rdm))
-		xc.num_rdms = C.int(numRdms)
-		cRdms := (*[1 << 28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:numRdms:numRdms]
-		for i, v := range x.Rdms {
-			if err := v.toC(&cRdms[i]); err != nil {
-				return fmt.Errorf("converting field Rdms: %v", err)
-			}
-		}
-	}
-	if numDtdevs := len(x.Dtdevs); numDtdevs > 0 {
-		xc.dtdevs = (*C.libxl_device_dtdev)(C.malloc(C.ulong(numDtdevs) * C.sizeof_libxl_device_dtdev))
-		xc.num_dtdevs = C.int(numDtdevs)
-		cDtdevs := (*[1 << 28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:numDtdevs:numDtdevs]
-		for i, v := range x.Dtdevs {
-			if err := v.toC(&cDtdevs[i]); err != nil {
-				return fmt.Errorf("converting field Dtdevs: %v", err)
-			}
-		}
-	}
-	if numVfbs := len(x.Vfbs); numVfbs > 0 {
-		xc.vfbs = (*C.libxl_device_vfb)(C.malloc(C.ulong(numVfbs) * C.sizeof_libxl_device_vfb))
-		xc.num_vfbs = C.int(numVfbs)
-		cVfbs := (*[1 << 28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:numVfbs:numVfbs]
-		for i, v := range x.Vfbs {
-			if err := v.toC(&cVfbs[i]); err != nil {
-				return fmt.Errorf("converting field Vfbs: %v", err)
-			}
-		}
-	}
-	if numVkbs := len(x.Vkbs); numVkbs > 0 {
-		xc.vkbs = (*C.libxl_device_vkb)(C.malloc(C.ulong(numVkbs) * C.sizeof_libxl_device_vkb))
-		xc.num_vkbs = C.int(numVkbs)
-		cVkbs := (*[1 << 28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:numVkbs:numVkbs]
-		for i, v := range x.Vkbs {
-			if err := v.toC(&cVkbs[i]); err != nil {
-				return fmt.Errorf("converting field Vkbs: %v", err)
-			}
-		}
-	}
-	if numVtpms := len(x.Vtpms); numVtpms > 0 {
-		xc.vtpms = (*C.libxl_device_vtpm)(C.malloc(C.ulong(numVtpms) * C.sizeof_libxl_device_vtpm))
-		xc.num_vtpms = C.int(numVtpms)
-		cVtpms := (*[1 << 28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:numVtpms:numVtpms]
-		for i, v := range x.Vtpms {
-			if err := v.toC(&cVtpms[i]); err != nil {
-				return fmt.Errorf("converting field Vtpms: %v", err)
-			}
-		}
-	}
-	if numP9S := len(x.P9S); numP9S > 0 {
-		xc.p9s = (*C.libxl_device_p9)(C.malloc(C.ulong(numP9S) * C.sizeof_libxl_device_p9))
-		xc.num_p9s = C.int(numP9S)
-		cP9S := (*[1 << 28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:numP9S:numP9S]
-		for i, v := range x.P9S {
-			if err := v.toC(&cP9S[i]); err != nil {
-				return fmt.Errorf("converting field P9S: %v", err)
-			}
-		}
-	}
-	if numPvcallsifs := len(x.Pvcallsifs); numPvcallsifs > 0 {
-		xc.pvcallsifs = (*C.libxl_device_pvcallsif)(C.malloc(C.ulong(numPvcallsifs) * C.sizeof_libxl_device_pvcallsif))
-		xc.num_pvcallsifs = C.int(numPvcallsifs)
-		cPvcallsifs := (*[1 << 28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:numPvcallsifs:numPvcallsifs]
-		for i, v := range x.Pvcallsifs {
-			if err := v.toC(&cPvcallsifs[i]); err != nil {
-				return fmt.Errorf("converting field Pvcallsifs: %v", err)
-			}
-		}
-	}
-	if numVdispls := len(x.Vdispls); numVdispls > 0 {
-		xc.vdispls = (*C.libxl_device_vdispl)(C.malloc(C.ulong(numVdispls) * C.sizeof_libxl_device_vdispl))
-		xc.num_vdispls = C.int(numVdispls)
-		cVdispls := (*[1 << 28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:numVdispls:numVdispls]
-		for i, v := range x.Vdispls {
-			if err := v.toC(&cVdispls[i]); err != nil {
-				return fmt.Errorf("converting field Vdispls: %v", err)
-			}
-		}
-	}
-	if numVsnds := len(x.Vsnds); numVsnds > 0 {
-		xc.vsnds = (*C.libxl_device_vsnd)(C.malloc(C.ulong(numVsnds) * C.sizeof_libxl_device_vsnd))
-		xc.num_vsnds = C.int(numVsnds)
-		cVsnds := (*[1 << 28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:numVsnds:numVsnds]
-		for i, v := range x.Vsnds {
-			if err := v.toC(&cVsnds[i]); err != nil {
-				return fmt.Errorf("converting field Vsnds: %v", err)
-			}
-		}
-	}
-	if numChannels := len(x.Channels); numChannels > 0 {
-		xc.channels = (*C.libxl_device_channel)(C.malloc(C.ulong(numChannels) * C.sizeof_libxl_device_channel))
-		xc.num_channels = C.int(numChannels)
-		cChannels := (*[1 << 28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:numChannels:numChannels]
-		for i, v := range x.Channels {
-			if err := v.toC(&cChannels[i]); err != nil {
-				return fmt.Errorf("converting field Channels: %v", err)
-			}
-		}
-	}
-	if numUsbctrls := len(x.Usbctrls); numUsbctrls > 0 {
-		xc.usbctrls = (*C.libxl_device_usbctrl)(C.malloc(C.ulong(numUsbctrls) * C.sizeof_libxl_device_usbctrl))
-		xc.num_usbctrls = C.int(numUsbctrls)
-		cUsbctrls := (*[1 << 28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:numUsbctrls:numUsbctrls]
-		for i, v := range x.Usbctrls {
-			if err := v.toC(&cUsbctrls[i]); err != nil {
-				return fmt.Errorf("converting field Usbctrls: %v", err)
-			}
-		}
-	}
-	if numUsbdevs := len(x.Usbdevs); numUsbdevs > 0 {
-		xc.usbdevs = (*C.libxl_device_usbdev)(C.malloc(C.ulong(numUsbdevs) * C.sizeof_libxl_device_usbdev))
-		xc.num_usbdevs = C.int(numUsbdevs)
-		cUsbdevs := (*[1 << 28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:numUsbdevs:numUsbdevs]
-		for i, v := range x.Usbdevs {
-			if err := v.toC(&cUsbdevs[i]); err != nil {
-				return fmt.Errorf("converting field Usbdevs: %v", err)
-			}
-		}
-	}
-	xc.on_poweroff = C.libxl_action_on_shutdown(x.OnPoweroff)
-	xc.on_reboot = C.libxl_action_on_shutdown(x.OnReboot)
-	xc.on_watchdog = C.libxl_action_on_shutdown(x.OnWatchdog)
-	xc.on_crash = C.libxl_action_on_shutdown(x.OnCrash)
-	xc.on_soft_reset = C.libxl_action_on_shutdown(x.OnSoftReset)
-
-	return nil
-}
-
-// NewDiskinfo returns an instance of Diskinfo initialized with defaults.
-func NewDiskinfo() (*Diskinfo, error) {
-	var (
-		x  Diskinfo
-		xc C.libxl_diskinfo
-	)
-
-	C.libxl_diskinfo_init(&xc)
-	defer C.libxl_diskinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Diskinfo) fromC(xc *C.libxl_diskinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.Rref = int(xc.rref)
-
-	return nil
-}
-
-func (x *Diskinfo) toC(xc *C.libxl_diskinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_diskinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref = C.int(x.Rref)
-
-	return nil
-}
-
-// NewNicinfo returns an instance of Nicinfo initialized with defaults.
-func NewNicinfo() (*Nicinfo, error) {
-	var (
-		x  Nicinfo
-		xc C.libxl_nicinfo
-	)
-
-	C.libxl_nicinfo_init(&xc)
-	defer C.libxl_nicinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Nicinfo) fromC(xc *C.libxl_nicinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.RrefTx = int(xc.rref_tx)
-	x.RrefRx = int(xc.rref_rx)
-
-	return nil
-}
-
-func (x *Nicinfo) toC(xc *C.libxl_nicinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_nicinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref_tx = C.int(x.RrefTx)
-	xc.rref_rx = C.int(x.RrefRx)
-
-	return nil
-}
-
-// NewVtpminfo returns an instance of Vtpminfo initialized with defaults.
-func NewVtpminfo() (*Vtpminfo, error) {
-	var (
-		x  Vtpminfo
-		xc C.libxl_vtpminfo
-	)
-
-	C.libxl_vtpminfo_init(&xc)
-	defer C.libxl_vtpminfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vtpminfo) fromC(xc *C.libxl_vtpminfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.Rref = int(xc.rref)
-	if err := x.Uuid.fromC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-
-	return nil
-}
-
-func (x *Vtpminfo) toC(xc *C.libxl_vtpminfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vtpminfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref = C.int(x.Rref)
-	if err := x.Uuid.toC(&xc.uuid); err != nil {
-		return fmt.Errorf("converting field Uuid: %v", err)
-	}
-
-	return nil
-}
-
-// NewUsbctrlinfo returns an instance of Usbctrlinfo initialized with defaults.
-func NewUsbctrlinfo() (*Usbctrlinfo, error) {
-	var (
-		x  Usbctrlinfo
-		xc C.libxl_usbctrlinfo
-	)
-
-	C.libxl_usbctrlinfo_init(&xc)
-	defer C.libxl_usbctrlinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Usbctrlinfo) fromC(xc *C.libxl_usbctrlinfo) error {
-	x.Type = UsbctrlType(xc._type)
-	x.Devid = Devid(xc.devid)
-	x.Version = int(xc.version)
-	x.Ports = int(xc.ports)
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.RefUrb = int(xc.ref_urb)
-	x.RefConn = int(xc.ref_conn)
-
-	return nil
-}
-
-func (x *Usbctrlinfo) toC(xc *C.libxl_usbctrlinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_usbctrlinfo_dispose(xc)
-		}
-	}()
-
-	xc._type = C.libxl_usbctrl_type(x.Type)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.version = C.int(x.Version)
-	xc.ports = C.int(x.Ports)
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.ref_urb = C.int(x.RefUrb)
-	xc.ref_conn = C.int(x.RefConn)
-
-	return nil
-}
-
-// NewVcpuinfo returns an instance of Vcpuinfo initialized with defaults.
-func NewVcpuinfo() (*Vcpuinfo, error) {
-	var (
-		x  Vcpuinfo
-		xc C.libxl_vcpuinfo
-	)
-
-	C.libxl_vcpuinfo_init(&xc)
-	defer C.libxl_vcpuinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vcpuinfo) fromC(xc *C.libxl_vcpuinfo) error {
-	x.Vcpuid = uint32(xc.vcpuid)
-	x.Cpu = uint32(xc.cpu)
-	x.Online = bool(xc.online)
-	x.Blocked = bool(xc.blocked)
-	x.Running = bool(xc.running)
-	x.VcpuTime = uint64(xc.vcpu_time)
-	if err := x.Cpumap.fromC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-	if err := x.CpumapSoft.fromC(&xc.cpumap_soft); err != nil {
-		return fmt.Errorf("converting field CpumapSoft: %v", err)
-	}
-
-	return nil
-}
-
-func (x *Vcpuinfo) toC(xc *C.libxl_vcpuinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vcpuinfo_dispose(xc)
-		}
-	}()
-
-	xc.vcpuid = C.uint32_t(x.Vcpuid)
-	xc.cpu = C.uint32_t(x.Cpu)
-	xc.online = C.bool(x.Online)
-	xc.blocked = C.bool(x.Blocked)
-	xc.running = C.bool(x.Running)
-	xc.vcpu_time = C.uint64_t(x.VcpuTime)
-	if err := x.Cpumap.toC(&xc.cpumap); err != nil {
-		return fmt.Errorf("converting field Cpumap: %v", err)
-	}
-	if err := x.CpumapSoft.toC(&xc.cpumap_soft); err != nil {
-		return fmt.Errorf("converting field CpumapSoft: %v", err)
-	}
-
-	return nil
-}
-
-// NewPhysinfo returns an instance of Physinfo initialized with defaults.
-func NewPhysinfo() (*Physinfo, error) {
-	var (
-		x  Physinfo
-		xc C.libxl_physinfo
-	)
-
-	C.libxl_physinfo_init(&xc)
-	defer C.libxl_physinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Physinfo) fromC(xc *C.libxl_physinfo) error {
-	x.ThreadsPerCore = uint32(xc.threads_per_core)
-	x.CoresPerSocket = uint32(xc.cores_per_socket)
-	x.MaxCpuId = uint32(xc.max_cpu_id)
-	x.NrCpus = uint32(xc.nr_cpus)
-	x.CpuKhz = uint32(xc.cpu_khz)
-	x.TotalPages = uint64(xc.total_pages)
-	x.FreePages = uint64(xc.free_pages)
-	x.ScrubPages = uint64(xc.scrub_pages)
-	x.OutstandingPages = uint64(xc.outstanding_pages)
-	x.SharingFreedPages = uint64(xc.sharing_freed_pages)
-	x.SharingUsedFrames = uint64(xc.sharing_used_frames)
-	x.MaxPossibleMfn = uint64(xc.max_possible_mfn)
-	x.NrNodes = uint32(xc.nr_nodes)
-	if err := x.HwCap.fromC(&xc.hw_cap); err != nil {
-		return fmt.Errorf("converting field HwCap: %v", err)
-	}
-	x.CapHvm = bool(xc.cap_hvm)
-	x.CapPv = bool(xc.cap_pv)
-	x.CapHvmDirectio = bool(xc.cap_hvm_directio)
-	x.CapHap = bool(xc.cap_hap)
-	x.CapShadow = bool(xc.cap_shadow)
-	x.CapIommuHapPtShare = bool(xc.cap_iommu_hap_pt_share)
-
-	return nil
-}
-
-func (x *Physinfo) toC(xc *C.libxl_physinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_physinfo_dispose(xc)
-		}
-	}()
-
-	xc.threads_per_core = C.uint32_t(x.ThreadsPerCore)
-	xc.cores_per_socket = C.uint32_t(x.CoresPerSocket)
-	xc.max_cpu_id = C.uint32_t(x.MaxCpuId)
-	xc.nr_cpus = C.uint32_t(x.NrCpus)
-	xc.cpu_khz = C.uint32_t(x.CpuKhz)
-	xc.total_pages = C.uint64_t(x.TotalPages)
-	xc.free_pages = C.uint64_t(x.FreePages)
-	xc.scrub_pages = C.uint64_t(x.ScrubPages)
-	xc.outstanding_pages = C.uint64_t(x.OutstandingPages)
-	xc.sharing_freed_pages = C.uint64_t(x.SharingFreedPages)
-	xc.sharing_used_frames = C.uint64_t(x.SharingUsedFrames)
-	xc.max_possible_mfn = C.uint64_t(x.MaxPossibleMfn)
-	xc.nr_nodes = C.uint32_t(x.NrNodes)
-	if err := x.HwCap.toC(&xc.hw_cap); err != nil {
-		return fmt.Errorf("converting field HwCap: %v", err)
-	}
-	xc.cap_hvm = C.bool(x.CapHvm)
-	xc.cap_pv = C.bool(x.CapPv)
-	xc.cap_hvm_directio = C.bool(x.CapHvmDirectio)
-	xc.cap_hap = C.bool(x.CapHap)
-	xc.cap_shadow = C.bool(x.CapShadow)
-	xc.cap_iommu_hap_pt_share = C.bool(x.CapIommuHapPtShare)
-
-	return nil
-}
-
-// NewConnectorinfo returns an instance of Connectorinfo initialized with defaults.
-func NewConnectorinfo() (*Connectorinfo, error) {
-	var (
-		x  Connectorinfo
-		xc C.libxl_connectorinfo
-	)
-
-	C.libxl_connectorinfo_init(&xc)
-	defer C.libxl_connectorinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Connectorinfo) fromC(xc *C.libxl_connectorinfo) error {
-	x.UniqueId = C.GoString(xc.unique_id)
-	x.Width = uint32(xc.width)
-	x.Height = uint32(xc.height)
-	x.ReqEvtch = int(xc.req_evtch)
-	x.ReqRref = int(xc.req_rref)
-	x.EvtEvtch = int(xc.evt_evtch)
-	x.EvtRref = int(xc.evt_rref)
-
-	return nil
-}
-
-func (x *Connectorinfo) toC(xc *C.libxl_connectorinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_connectorinfo_dispose(xc)
-		}
-	}()
-
-	if x.UniqueId != "" {
-		xc.unique_id = C.CString(x.UniqueId)
-	}
-	xc.width = C.uint32_t(x.Width)
-	xc.height = C.uint32_t(x.Height)
-	xc.req_evtch = C.int(x.ReqEvtch)
-	xc.req_rref = C.int(x.ReqRref)
-	xc.evt_evtch = C.int(x.EvtEvtch)
-	xc.evt_rref = C.int(x.EvtRref)
-
-	return nil
-}
-
-// NewVdisplinfo returns an instance of Vdisplinfo initialized with defaults.
-func NewVdisplinfo() (*Vdisplinfo, error) {
-	var (
-		x  Vdisplinfo
-		xc C.libxl_vdisplinfo
-	)
-
-	C.libxl_vdisplinfo_init(&xc)
-	defer C.libxl_vdisplinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vdisplinfo) fromC(xc *C.libxl_vdisplinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.BeAlloc = bool(xc.be_alloc)
-	x.Connectors = nil
-	if n := int(xc.num_connectors); n > 0 {
-		cConnectors := (*[1 << 28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:n:n]
-		x.Connectors = make([]Connectorinfo, n)
-		for i, v := range cConnectors {
-			if err := x.Connectors[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Connectors: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-func (x *Vdisplinfo) toC(xc *C.libxl_vdisplinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vdisplinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.be_alloc = C.bool(x.BeAlloc)
-	if numConnectors := len(x.Connectors); numConnectors > 0 {
-		xc.connectors = (*C.libxl_connectorinfo)(C.malloc(C.ulong(numConnectors) * C.sizeof_libxl_connectorinfo))
-		xc.num_connectors = C.int(numConnectors)
-		cConnectors := (*[1 << 28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors]
-		for i, v := range x.Connectors {
-			if err := v.toC(&cConnectors[i]); err != nil {
-				return fmt.Errorf("converting field Connectors: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewStreaminfo returns an instance of Streaminfo initialized with defaults.
-func NewStreaminfo() (*Streaminfo, error) {
-	var (
-		x  Streaminfo
-		xc C.libxl_streaminfo
-	)
-
-	C.libxl_streaminfo_init(&xc)
-	defer C.libxl_streaminfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Streaminfo) fromC(xc *C.libxl_streaminfo) error {
-	x.ReqEvtch = int(xc.req_evtch)
-	x.ReqRref = int(xc.req_rref)
-
-	return nil
-}
-
-func (x *Streaminfo) toC(xc *C.libxl_streaminfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_streaminfo_dispose(xc)
-		}
-	}()
-
-	xc.req_evtch = C.int(x.ReqEvtch)
-	xc.req_rref = C.int(x.ReqRref)
-
-	return nil
-}
-
-// NewPcminfo returns an instance of Pcminfo initialized with defaults.
-func NewPcminfo() (*Pcminfo, error) {
-	var (
-		x  Pcminfo
-		xc C.libxl_pcminfo
-	)
-
-	C.libxl_pcminfo_init(&xc)
-	defer C.libxl_pcminfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Pcminfo) fromC(xc *C.libxl_pcminfo) error {
-	x.Streams = nil
-	if n := int(xc.num_vsnd_streams); n > 0 {
-		cStreams := (*[1 << 28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:n:n]
-		x.Streams = make([]Streaminfo, n)
-		for i, v := range cStreams {
-			if err := x.Streams[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Streams: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-func (x *Pcminfo) toC(xc *C.libxl_pcminfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_pcminfo_dispose(xc)
-		}
-	}()
-
-	if numVsndStreams := len(x.Streams); numVsndStreams > 0 {
-		xc.streams = (*C.libxl_streaminfo)(C.malloc(C.ulong(numVsndStreams) * C.sizeof_libxl_streaminfo))
-		xc.num_vsnd_streams = C.int(numVsndStreams)
-		cStreams := (*[1 << 28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams]
-		for i, v := range x.Streams {
-			if err := v.toC(&cStreams[i]); err != nil {
-				return fmt.Errorf("converting field Streams: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewVsndinfo returns an instance of Vsndinfo initialized with defaults.
-func NewVsndinfo() (*Vsndinfo, error) {
-	var (
-		x  Vsndinfo
-		xc C.libxl_vsndinfo
-	)
-
-	C.libxl_vsndinfo_init(&xc)
-	defer C.libxl_vsndinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vsndinfo) fromC(xc *C.libxl_vsndinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Pcms = nil
-	if n := int(xc.num_vsnd_pcms); n > 0 {
-		cPcms := (*[1 << 28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:n:n]
-		x.Pcms = make([]Pcminfo, n)
-		for i, v := range cPcms {
-			if err := x.Pcms[i].fromC(&v); err != nil {
-				return fmt.Errorf("converting field Pcms: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-func (x *Vsndinfo) toC(xc *C.libxl_vsndinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vsndinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	if numVsndPcms := len(x.Pcms); numVsndPcms > 0 {
-		xc.pcms = (*C.libxl_pcminfo)(C.malloc(C.ulong(numVsndPcms) * C.sizeof_libxl_pcminfo))
-		xc.num_vsnd_pcms = C.int(numVsndPcms)
-		cPcms := (*[1 << 28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms]
-		for i, v := range x.Pcms {
-			if err := v.toC(&cPcms[i]); err != nil {
-				return fmt.Errorf("converting field Pcms: %v", err)
-			}
-		}
-	}
-
-	return nil
-}
-
-// NewVkbinfo returns an instance of Vkbinfo initialized with defaults.
-func NewVkbinfo() (*Vkbinfo, error) {
-	var (
-		x  Vkbinfo
-		xc C.libxl_vkbinfo
-	)
-
-	C.libxl_vkbinfo_init(&xc)
-	defer C.libxl_vkbinfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Vkbinfo) fromC(xc *C.libxl_vkbinfo) error {
-	x.Backend = C.GoString(xc.backend)
-	x.BackendId = uint32(xc.backend_id)
-	x.Frontend = C.GoString(xc.frontend)
-	x.FrontendId = uint32(xc.frontend_id)
-	x.Devid = Devid(xc.devid)
-	x.State = int(xc.state)
-	x.Evtch = int(xc.evtch)
-	x.Rref = int(xc.rref)
-
-	return nil
-}
-
-func (x *Vkbinfo) toC(xc *C.libxl_vkbinfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_vkbinfo_dispose(xc)
-		}
-	}()
-
-	if x.Backend != "" {
-		xc.backend = C.CString(x.Backend)
-	}
-	xc.backend_id = C.uint32_t(x.BackendId)
-	if x.Frontend != "" {
-		xc.frontend = C.CString(x.Frontend)
-	}
-	xc.frontend_id = C.uint32_t(x.FrontendId)
-	xc.devid = C.libxl_devid(x.Devid)
-	xc.state = C.int(x.State)
-	xc.evtch = C.int(x.Evtch)
-	xc.rref = C.int(x.Rref)
-
-	return nil
-}
-
-// NewNumainfo returns an instance of Numainfo initialized with defaults.
-func NewNumainfo() (*Numainfo, error) {
-	var (
-		x  Numainfo
-		xc C.libxl_numainfo
-	)
-
-	C.libxl_numainfo_init(&xc)
-	defer C.libxl_numainfo_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Numainfo) fromC(xc *C.libxl_numainfo) error {
-	x.Size = uint64(xc.size)
-	x.Free = uint64(xc.free)
-	x.Dists = nil
-	if n := int(xc.num_dists); n > 0 {
-		cDists := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.dists))[:n:n]
-		x.Dists = make([]uint32, n)
-		for i, v := range cDists {
-			x.Dists[i] = uint32(v)
-		}
-	}
-
-	return nil
-}
-
-func (x *Numainfo) toC(xc *C.libxl_numainfo) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_numainfo_dispose(xc)
-		}
-	}()
-
-	xc.size = C.uint64_t(x.Size)
-	xc.free = C.uint64_t(x.Free)
-	if numDists := len(x.Dists); numDists > 0 {
-		xc.dists = (*C.uint32_t)(C.malloc(C.size_t(numDists * numDists)))
-		xc.num_dists = C.int(numDists)
-		cDists := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.dists))[:numDists:numDists]
-		for i, v := range x.Dists {
-			cDists[i] = C.uint32_t(v)
-		}
-	}
-
-	return nil
-}
-
-// NewCputopology returns an instance of Cputopology initialized with defaults.
-func NewCputopology() (*Cputopology, error) {
-	var (
-		x  Cputopology
-		xc C.libxl_cputopology
-	)
-
-	C.libxl_cputopology_init(&xc)
-	defer C.libxl_cputopology_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Cputopology) fromC(xc *C.libxl_cputopology) error {
-	x.Core = uint32(xc.core)
-	x.Socket = uint32(xc.socket)
-	x.Node = uint32(xc.node)
-
-	return nil
-}
-
-func (x *Cputopology) toC(xc *C.libxl_cputopology) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_cputopology_dispose(xc)
-		}
-	}()
-
-	xc.core = C.uint32_t(x.Core)
-	xc.socket = C.uint32_t(x.Socket)
-	xc.node = C.uint32_t(x.Node)
-
-	return nil
-}
-
-// NewPcitopology returns an instance of Pcitopology initialized with defaults.
-func NewPcitopology() (*Pcitopology, error) {
-	var (
-		x  Pcitopology
-		xc C.libxl_pcitopology
-	)
-
-	C.libxl_pcitopology_init(&xc)
-	defer C.libxl_pcitopology_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Pcitopology) fromC(xc *C.libxl_pcitopology) error {
-	x.Seg = uint16(xc.seg)
-	x.Bus = byte(xc.bus)
-	x.Devfn = byte(xc.devfn)
-	x.Node = uint32(xc.node)
-
-	return nil
-}
-
-func (x *Pcitopology) toC(xc *C.libxl_pcitopology) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_pcitopology_dispose(xc)
-		}
-	}()
-
-	xc.seg = C.uint16_t(x.Seg)
-	xc.bus = C.uint8_t(x.Bus)
-	xc.devfn = C.uint8_t(x.Devfn)
-	xc.node = C.uint32_t(x.Node)
-
-	return nil
-}
-
-// NewSchedCreditParams returns an instance of SchedCreditParams initialized with defaults.
-func NewSchedCreditParams() (*SchedCreditParams, error) {
-	var (
-		x  SchedCreditParams
-		xc C.libxl_sched_credit_params
-	)
-
-	C.libxl_sched_credit_params_init(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SchedCreditParams) fromC(xc *C.libxl_sched_credit_params) error {
-	x.TsliceMs = int(xc.tslice_ms)
-	x.RatelimitUs = int(xc.ratelimit_us)
-	x.VcpuMigrDelayUs = int(xc.vcpu_migr_delay_us)
-
-	return nil
-}
-
-func (x *SchedCreditParams) toC(xc *C.libxl_sched_credit_params) (err error) {
-	xc.tslice_ms = C.int(x.TsliceMs)
-	xc.ratelimit_us = C.int(x.RatelimitUs)
-	xc.vcpu_migr_delay_us = C.int(x.VcpuMigrDelayUs)
-
-	return nil
-}
-
-// NewSchedCredit2Params returns an instance of SchedCredit2Params initialized with defaults.
-func NewSchedCredit2Params() (*SchedCredit2Params, error) {
-	var (
-		x  SchedCredit2Params
-		xc C.libxl_sched_credit2_params
-	)
-
-	C.libxl_sched_credit2_params_init(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *SchedCredit2Params) fromC(xc *C.libxl_sched_credit2_params) error {
-	x.RatelimitUs = int(xc.ratelimit_us)
-
-	return nil
-}
-
-func (x *SchedCredit2Params) toC(xc *C.libxl_sched_credit2_params) (err error) {
-	xc.ratelimit_us = C.int(x.RatelimitUs)
-
-	return nil
-}
-
-// NewDomainRemusInfo returns an instance of DomainRemusInfo initialized with defaults.
-func NewDomainRemusInfo() (*DomainRemusInfo, error) {
-	var (
-		x  DomainRemusInfo
-		xc C.libxl_domain_remus_info
-	)
-
-	C.libxl_domain_remus_info_init(&xc)
-	defer C.libxl_domain_remus_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *DomainRemusInfo) fromC(xc *C.libxl_domain_remus_info) error {
-	x.Interval = int(xc.interval)
-	if err := x.AllowUnsafe.fromC(&xc.allow_unsafe); err != nil {
-		return fmt.Errorf("converting field AllowUnsafe: %v", err)
-	}
-	if err := x.Blackhole.fromC(&xc.blackhole); err != nil {
-		return fmt.Errorf("converting field Blackhole: %v", err)
-	}
-	if err := x.Compression.fromC(&xc.compression); err != nil {
-		return fmt.Errorf("converting field Compression: %v", err)
-	}
-	if err := x.Netbuf.fromC(&xc.netbuf); err != nil {
-		return fmt.Errorf("converting field Netbuf: %v", err)
-	}
-	x.Netbufscript = C.GoString(xc.netbufscript)
-	if err := x.Diskbuf.fromC(&xc.diskbuf); err != nil {
-		return fmt.Errorf("converting field Diskbuf: %v", err)
-	}
-	if err := x.Colo.fromC(&xc.colo); err != nil {
-		return fmt.Errorf("converting field Colo: %v", err)
-	}
-	if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy); err != nil {
-		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
-	}
-
-	return nil
-}
-
-func (x *DomainRemusInfo) toC(xc *C.libxl_domain_remus_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_domain_remus_info_dispose(xc)
-		}
-	}()
-
-	xc.interval = C.int(x.Interval)
-	if err := x.AllowUnsafe.toC(&xc.allow_unsafe); err != nil {
-		return fmt.Errorf("converting field AllowUnsafe: %v", err)
-	}
-	if err := x.Blackhole.toC(&xc.blackhole); err != nil {
-		return fmt.Errorf("converting field Blackhole: %v", err)
-	}
-	if err := x.Compression.toC(&xc.compression); err != nil {
-		return fmt.Errorf("converting field Compression: %v", err)
-	}
-	if err := x.Netbuf.toC(&xc.netbuf); err != nil {
-		return fmt.Errorf("converting field Netbuf: %v", err)
-	}
-	if x.Netbufscript != "" {
-		xc.netbufscript = C.CString(x.Netbufscript)
-	}
-	if err := x.Diskbuf.toC(&xc.diskbuf); err != nil {
-		return fmt.Errorf("converting field Diskbuf: %v", err)
-	}
-	if err := x.Colo.toC(&xc.colo); err != nil {
-		return fmt.Errorf("converting field Colo: %v", err)
-	}
-	if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil {
-		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
-	}
-
-	return nil
-}
-
-// NewEvent returns an instance of Event initialized with defaults.
-func NewEvent(etype EventType) (*Event, error) {
-	var (
-		x  Event
-		xc C.libxl_event
-	)
-
-	C.libxl_event_init(&xc)
-	C.libxl_event_init_type(&xc, C.libxl_event_type(etype))
-	defer C.libxl_event_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *Event) fromC(xc *C.libxl_event) error {
-	if err := x.Link.fromC(&xc.link); err != nil {
-		return fmt.Errorf("converting field Link: %v", err)
-	}
-	x.Domid = Domid(xc.domid)
-	if err := x.Domuuid.fromC(&xc.domuuid); err != nil {
-		return fmt.Errorf("converting field Domuuid: %v", err)
-	}
-	x.ForUser = uint64(xc.for_user)
-	x.Type = EventType(xc._type)
-	switch x.Type {
-	case EventTypeDomainShutdown:
-		var typeDomainShutdown EventTypeUnionDomainShutdown
-		if err := typeDomainShutdown.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeDomainShutdown: %v", err)
-		}
-		x.TypeUnion = typeDomainShutdown
-	case EventTypeDomainDeath:
-		x.TypeUnion = nil
-	case EventTypeDiskEject:
-		var typeDiskEject EventTypeUnionDiskEject
-		if err := typeDiskEject.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeDiskEject: %v", err)
-		}
-		x.TypeUnion = typeDiskEject
-	case EventTypeOperationComplete:
-		var typeOperationComplete EventTypeUnionOperationComplete
-		if err := typeOperationComplete.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeOperationComplete: %v", err)
-		}
-		x.TypeUnion = typeOperationComplete
-	case EventTypeDomainCreateConsoleAvailable:
-		x.TypeUnion = nil
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-func (x *EventTypeUnionDomainShutdown) fromC(xc *C.libxl_event) error {
-	if EventType(xc._type) != EventTypeDomainShutdown {
-		return errors.New("expected union key EventTypeDomainShutdown")
-	}
-
-	tmp := (*C.libxl_event_type_union_domain_shutdown)(unsafe.Pointer(&xc.u[0]))
-	x.ShutdownReason = byte(tmp.shutdown_reason)
-	return nil
-}
-
-func (x *EventTypeUnionDiskEject) fromC(xc *C.libxl_event) error {
-	if EventType(xc._type) != EventTypeDiskEject {
-		return errors.New("expected union key EventTypeDiskEject")
-	}
-
-	tmp := (*C.libxl_event_type_union_disk_eject)(unsafe.Pointer(&xc.u[0]))
-	x.Vdev = C.GoString(tmp.vdev)
-	if err := x.Disk.fromC(&tmp.disk); err != nil {
-		return fmt.Errorf("converting field Disk: %v", err)
-	}
-	return nil
-}
-
-func (x *EventTypeUnionOperationComplete) fromC(xc *C.libxl_event) error {
-	if EventType(xc._type) != EventTypeOperationComplete {
-		return errors.New("expected union key EventTypeOperationComplete")
-	}
-
-	tmp := (*C.libxl_event_type_union_operation_complete)(unsafe.Pointer(&xc.u[0]))
-	x.Rc = int(tmp.rc)
-	return nil
-}
-
-func (x *Event) toC(xc *C.libxl_event) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_event_dispose(xc)
-		}
-	}()
-
-	if err := x.Link.toC(&xc.link); err != nil {
-		return fmt.Errorf("converting field Link: %v", err)
-	}
-	xc.domid = C.libxl_domid(x.Domid)
-	if err := x.Domuuid.toC(&xc.domuuid); err != nil {
-		return fmt.Errorf("converting field Domuuid: %v", err)
-	}
-	xc.for_user = C.uint64_t(x.ForUser)
-	xc._type = C.libxl_event_type(x.Type)
-	switch x.Type {
-	case EventTypeDomainShutdown:
-		tmp, ok := x.TypeUnion.(EventTypeUnionDomainShutdown)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var domain_shutdown C.libxl_event_type_union_domain_shutdown
-		domain_shutdown.shutdown_reason = C.uint8_t(tmp.ShutdownReason)
-		domain_shutdownBytes := C.GoBytes(unsafe.Pointer(&domain_shutdown), C.sizeof_libxl_event_type_union_domain_shutdown)
-		copy(xc.u[:], domain_shutdownBytes)
-	case EventTypeDomainDeath:
-		break
-	case EventTypeDiskEject:
-		tmp, ok := x.TypeUnion.(EventTypeUnionDiskEject)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var disk_eject C.libxl_event_type_union_disk_eject
-		if tmp.Vdev != "" {
-			disk_eject.vdev = C.CString(tmp.Vdev)
-		}
-		if err := tmp.Disk.toC(&disk_eject.disk); err != nil {
-			return fmt.Errorf("converting field Disk: %v", err)
-		}
-		disk_ejectBytes := C.GoBytes(unsafe.Pointer(&disk_eject), C.sizeof_libxl_event_type_union_disk_eject)
-		copy(xc.u[:], disk_ejectBytes)
-	case EventTypeOperationComplete:
-		tmp, ok := x.TypeUnion.(EventTypeUnionOperationComplete)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var operation_complete C.libxl_event_type_union_operation_complete
-		operation_complete.rc = C.int(tmp.Rc)
-		operation_completeBytes := C.GoBytes(unsafe.Pointer(&operation_complete), C.sizeof_libxl_event_type_union_operation_complete)
-		copy(xc.u[:], operation_completeBytes)
-	case EventTypeDomainCreateConsoleAvailable:
-		break
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-// NewPsrCatInfo returns an instance of PsrCatInfo initialized with defaults.
-func NewPsrCatInfo() (*PsrCatInfo, error) {
-	var (
-		x  PsrCatInfo
-		xc C.libxl_psr_cat_info
-	)
-
-	C.libxl_psr_cat_info_init(&xc)
-	defer C.libxl_psr_cat_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *PsrCatInfo) fromC(xc *C.libxl_psr_cat_info) error {
-	x.Id = uint32(xc.id)
-	x.CosMax = uint32(xc.cos_max)
-	x.CbmLen = uint32(xc.cbm_len)
-	x.CdpEnabled = bool(xc.cdp_enabled)
-
-	return nil
-}
-
-func (x *PsrCatInfo) toC(xc *C.libxl_psr_cat_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_psr_cat_info_dispose(xc)
-		}
-	}()
-
-	xc.id = C.uint32_t(x.Id)
-	xc.cos_max = C.uint32_t(x.CosMax)
-	xc.cbm_len = C.uint32_t(x.CbmLen)
-	xc.cdp_enabled = C.bool(x.CdpEnabled)
-
-	return nil
-}
-
-// NewPsrHwInfo returns an instance of PsrHwInfo initialized with defaults.
-func NewPsrHwInfo(ptype PsrFeatType) (*PsrHwInfo, error) {
-	var (
-		x  PsrHwInfo
-		xc C.libxl_psr_hw_info
-	)
-
-	C.libxl_psr_hw_info_init(&xc)
-	C.libxl_psr_hw_info_init_type(&xc, C.libxl_psr_feat_type(ptype))
-	defer C.libxl_psr_hw_info_dispose(&xc)
-
-	if err := x.fromC(&xc); err != nil {
-		return nil, err
-	}
-
-	return &x, nil
-}
-
-func (x *PsrHwInfo) fromC(xc *C.libxl_psr_hw_info) error {
-	x.Id = uint32(xc.id)
-	x.Type = PsrFeatType(xc._type)
-	switch x.Type {
-	case PsrFeatTypeCat:
-		var typeCat PsrHwInfoTypeUnionCat
-		if err := typeCat.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeCat: %v", err)
-		}
-		x.TypeUnion = typeCat
-	case PsrFeatTypeMba:
-		var typeMba PsrHwInfoTypeUnionMba
-		if err := typeMba.fromC(xc); err != nil {
-			return fmt.Errorf("converting field typeMba: %v", err)
-		}
-		x.TypeUnion = typeMba
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
-
-func (x *PsrHwInfoTypeUnionCat) fromC(xc *C.libxl_psr_hw_info) error {
-	if PsrFeatType(xc._type) != PsrFeatTypeCat {
-		return errors.New("expected union key PsrFeatTypeCat")
-	}
-
-	tmp := (*C.libxl_psr_hw_info_type_union_cat)(unsafe.Pointer(&xc.u[0]))
-	x.CosMax = uint32(tmp.cos_max)
-	x.CbmLen = uint32(tmp.cbm_len)
-	x.CdpEnabled = bool(tmp.cdp_enabled)
-	return nil
-}
-
-func (x *PsrHwInfoTypeUnionMba) fromC(xc *C.libxl_psr_hw_info) error {
-	if PsrFeatType(xc._type) != PsrFeatTypeMba {
-		return errors.New("expected union key PsrFeatTypeMba")
-	}
-
-	tmp := (*C.libxl_psr_hw_info_type_union_mba)(unsafe.Pointer(&xc.u[0]))
-	x.CosMax = uint32(tmp.cos_max)
-	x.ThrtlMax = uint32(tmp.thrtl_max)
-	x.Linear = bool(tmp.linear)
-	return nil
-}
-
-func (x *PsrHwInfo) toC(xc *C.libxl_psr_hw_info) (err error) {
-	defer func() {
-		if err != nil {
-			C.libxl_psr_hw_info_dispose(xc)
-		}
-	}()
-
-	xc.id = C.uint32_t(x.Id)
-	xc._type = C.libxl_psr_feat_type(x.Type)
-	switch x.Type {
-	case PsrFeatTypeCat:
-		tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionCat)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var cat C.libxl_psr_hw_info_type_union_cat
-		cat.cos_max = C.uint32_t(tmp.CosMax)
-		cat.cbm_len = C.uint32_t(tmp.CbmLen)
-		cat.cdp_enabled = C.bool(tmp.CdpEnabled)
-		catBytes := C.GoBytes(unsafe.Pointer(&cat), C.sizeof_libxl_psr_hw_info_type_union_cat)
-		copy(xc.u[:], catBytes)
-	case PsrFeatTypeMba:
-		tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionMba)
-		if !ok {
-			return errors.New("wrong type for union key type")
-		}
-		var mba C.libxl_psr_hw_info_type_union_mba
-		mba.cos_max = C.uint32_t(tmp.CosMax)
-		mba.thrtl_max = C.uint32_t(tmp.ThrtlMax)
-		mba.linear = C.bool(tmp.Linear)
-		mbaBytes := C.GoBytes(unsafe.Pointer(&mba), C.sizeof_libxl_psr_hw_info_type_union_mba)
-		copy(xc.u[:], mbaBytes)
-	default:
-		return fmt.Errorf("invalid union key '%v'", x.Type)
-	}
-
-	return nil
-}
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
deleted file mode 100644
index 4aaee20b95..0000000000
--- a/tools/golang/xenlight/types.gen.go
+++ /dev/null
@@ -1,1225 +0,0 @@
-// DO NOT EDIT.
-//
-// This file is generated by:
-// gengotypes.py ../../libxl/libxl_types.idl
-//
-package xenlight
-
-type Error int
-
-const (
-	ErrorNonspecific                  Error = -1
-	ErrorVersion                      Error = -2
-	ErrorFail                         Error = -3
-	ErrorNi                           Error = -4
-	ErrorNomem                        Error = -5
-	ErrorInval                        Error = -6
-	ErrorBadfail                      Error = -7
-	ErrorGuestTimedout                Error = -8
-	ErrorTimedout                     Error = -9
-	ErrorNoparavirt                   Error = -10
-	ErrorNotReady                     Error = -11
-	ErrorOseventRegFail               Error = -12
-	ErrorBufferfull                   Error = -13
-	ErrorUnknownChild                 Error = -14
-	ErrorLockFail                     Error = -15
-	ErrorJsonConfigEmpty              Error = -16
-	ErrorDeviceExists                 Error = -17
-	ErrorCheckpointDevopsDoesNotMatch Error = -18
-	ErrorCheckpointDeviceNotSupported Error = -19
-	ErrorVnumaConfigInvalid           Error = -20
-	ErrorDomainNotfound               Error = -21
-	ErrorAborted                      Error = -22
-	ErrorNotfound                     Error = -23
-	ErrorDomainDestroyed              Error = -24
-	ErrorFeatureRemoved               Error = -25
-	ErrorProtocolErrorQmp             Error = -26
-	ErrorUnknownQmpError              Error = -27
-	ErrorQmpGenericError              Error = -28
-	ErrorQmpCommandNotFound           Error = -29
-	ErrorQmpDeviceNotActive           Error = -30
-	ErrorQmpDeviceNotFound            Error = -31
-	ErrorQemuApi                      Error = -32
-)
-
-type DomainType int
-
-const (
-	DomainTypeInvalid DomainType = -1
-	DomainTypeHvm     DomainType = 1
-	DomainTypePv      DomainType = 2
-	DomainTypePvh     DomainType = 3
-)
-
-type RdmReserveStrategy int
-
-const (
-	RdmReserveStrategyIgnore RdmReserveStrategy = 0
-	RdmReserveStrategyHost   RdmReserveStrategy = 1
-)
-
-type RdmReservePolicy int
-
-const (
-	RdmReservePolicyInvalid RdmReservePolicy = -1
-	RdmReservePolicyStrict  RdmReservePolicy = 0
-	RdmReservePolicyRelaxed RdmReservePolicy = 1
-)
-
-type ChannelConnection int
-
-const (
-	ChannelConnectionUnknown ChannelConnection = 0
-	ChannelConnectionPty     ChannelConnection = 1
-	ChannelConnectionSocket  ChannelConnection = 2
-)
-
-type DeviceModelVersion int
-
-const (
-	DeviceModelVersionUnknown            DeviceModelVersion = 0
-	DeviceModelVersionQemuXenTraditional DeviceModelVersion = 1
-	DeviceModelVersionQemuXen            DeviceModelVersion = 2
-)
-
-type ConsoleType int
-
-const (
-	ConsoleTypeUnknown ConsoleType = 0
-	ConsoleTypeSerial  ConsoleType = 1
-	ConsoleTypePv      ConsoleType = 2
-	ConsoleTypeVuart   ConsoleType = 3
-)
-
-type DiskFormat int
-
-const (
-	DiskFormatUnknown DiskFormat = 0
-	DiskFormatQcow    DiskFormat = 1
-	DiskFormatQcow2   DiskFormat = 2
-	DiskFormatVhd     DiskFormat = 3
-	DiskFormatRaw     DiskFormat = 4
-	DiskFormatEmpty   DiskFormat = 5
-	DiskFormatQed     DiskFormat = 6
-)
-
-type DiskBackend int
-
-const (
-	DiskBackendUnknown DiskBackend = 0
-	DiskBackendPhy     DiskBackend = 1
-	DiskBackendTap     DiskBackend = 2
-	DiskBackendQdisk   DiskBackend = 3
-)
-
-type NicType int
-
-const (
-	NicTypeUnknown  NicType = 0
-	NicTypeVifIoemu NicType = 1
-	NicTypeVif      NicType = 2
-)
-
-type ActionOnShutdown int
-
-const (
-	ActionOnShutdownDestroy         ActionOnShutdown = 1
-	ActionOnShutdownRestart         ActionOnShutdown = 2
-	ActionOnShutdownRestartRename   ActionOnShutdown = 3
-	ActionOnShutdownPreserve        ActionOnShutdown = 4
-	ActionOnShutdownCoredumpDestroy ActionOnShutdown = 5
-	ActionOnShutdownCoredumpRestart ActionOnShutdown = 6
-	ActionOnShutdownSoftReset       ActionOnShutdown = 7
-)
-
-type Trigger int
-
-const (
-	TriggerUnknown  Trigger = 0
-	TriggerPower    Trigger = 1
-	TriggerSleep    Trigger = 2
-	TriggerNmi      Trigger = 3
-	TriggerInit     Trigger = 4
-	TriggerReset    Trigger = 5
-	TriggerS3Resume Trigger = 6
-)
-
-type TscMode int
-
-const (
-	TscModeDefault        TscMode = 0
-	TscModeAlwaysEmulate  TscMode = 1
-	TscModeNative         TscMode = 2
-	TscModeNativeParavirt TscMode = 3
-)
-
-type GfxPassthruKind int
-
-const (
-	GfxPassthruKindDefault GfxPassthruKind = 0
-	GfxPassthruKindIgd     GfxPassthruKind = 1
-)
-
-type TimerMode int
-
-const (
-	TimerModeUnknown               TimerMode = -1
-	TimerModeDelayForMissedTicks   TimerMode = 0
-	TimerModeNoDelayForMissedTicks TimerMode = 1
-	TimerModeNoMissedTicksPending  TimerMode = 2
-	TimerModeOneMissedTickPending  TimerMode = 3
-)
-
-type BiosType int
-
-const (
-	BiosTypeUnknown BiosType = 0
-	BiosTypeRombios BiosType = 1
-	BiosTypeSeabios BiosType = 2
-	BiosTypeOvmf    BiosType = 3
-)
-
-type Scheduler int
-
-const (
-	SchedulerUnknown  Scheduler = 0
-	SchedulerSedf     Scheduler = 4
-	SchedulerCredit   Scheduler = 5
-	SchedulerCredit2  Scheduler = 6
-	SchedulerArinc653 Scheduler = 7
-	SchedulerRtds     Scheduler = 8
-	SchedulerNull     Scheduler = 9
-)
-
-type ShutdownReason int
-
-const (
-	ShutdownReasonUnknown   ShutdownReason = -1
-	ShutdownReasonPoweroff  ShutdownReason = 0
-	ShutdownReasonReboot    ShutdownReason = 1
-	ShutdownReasonSuspend   ShutdownReason = 2
-	ShutdownReasonCrash     ShutdownReason = 3
-	ShutdownReasonWatchdog  ShutdownReason = 4
-	ShutdownReasonSoftReset ShutdownReason = 5
-)
-
-type VgaInterfaceType int
-
-const (
-	VgaInterfaceTypeUnknown VgaInterfaceType = 0
-	VgaInterfaceTypeCirrus  VgaInterfaceType = 1
-	VgaInterfaceTypeStd     VgaInterfaceType = 2
-	VgaInterfaceTypeNone    VgaInterfaceType = 3
-	VgaInterfaceTypeQxl     VgaInterfaceType = 4
-)
-
-type VendorDevice int
-
-const (
-	VendorDeviceNone      VendorDevice = 0
-	VendorDeviceXenserver VendorDevice = 1
-)
-
-type ViridianEnlightenment int
-
-const (
-	ViridianEnlightenmentBase                ViridianEnlightenment = 0
-	ViridianEnlightenmentFreq                ViridianEnlightenment = 1
-	ViridianEnlightenmentTimeRefCount        ViridianEnlightenment = 2
-	ViridianEnlightenmentReferenceTsc        ViridianEnlightenment = 3
-	ViridianEnlightenmentHcallRemoteTlbFlush ViridianEnlightenment = 4
-	ViridianEnlightenmentApicAssist          ViridianEnlightenment = 5
-	ViridianEnlightenmentCrashCtl            ViridianEnlightenment = 6
-	ViridianEnlightenmentSynic               ViridianEnlightenment = 7
-	ViridianEnlightenmentStimer              ViridianEnlightenment = 8
-	ViridianEnlightenmentHcallIpi            ViridianEnlightenment = 9
-)
-
-type Hdtype int
-
-const (
-	HdtypeIde  Hdtype = 1
-	HdtypeAhci Hdtype = 2
-)
-
-type CheckpointedStream int
-
-const (
-	CheckpointedStreamNone  CheckpointedStream = 0
-	CheckpointedStreamRemus CheckpointedStream = 1
-	CheckpointedStreamColo  CheckpointedStream = 2
-)
-
-type VuartType int
-
-const (
-	VuartTypeUnknown  VuartType = 0
-	VuartTypeSbsaUart VuartType = 1
-)
-
-type VkbBackend int
-
-const (
-	VkbBackendUnknown VkbBackend = 0
-	VkbBackendQemu    VkbBackend = 1
-	VkbBackendLinux   VkbBackend = 2
-)
-
-type Passthrough int
-
-const (
-	PassthroughDefault  Passthrough = 0
-	PassthroughDisabled Passthrough = 1
-	PassthroughEnabled  Passthrough = 2
-	PassthroughSyncPt   Passthrough = 3
-	PassthroughSharePt  Passthrough = 4
-)
-
-type IoportRange struct {
-	First  uint32
-	Number uint32
-}
-
-type IomemRange struct {
-	Start  uint64
-	Number uint64
-	Gfn    uint64
-}
-
-type VgaInterfaceInfo struct {
-	Kind VgaInterfaceType
-}
-
-type VncInfo struct {
-	Enable     Defbool
-	Listen     string
-	Passwd     string
-	Display    int
-	Findunused Defbool
-}
-
-type SpiceInfo struct {
-	Enable           Defbool
-	Port             int
-	TlsPort          int
-	Host             string
-	DisableTicketing Defbool
-	Passwd           string
-	AgentMouse       Defbool
-	Vdagent          Defbool
-	ClipboardSharing Defbool
-	Usbredirection   int
-	ImageCompression string
-	StreamingVideo   string
-}
-
-type SdlInfo struct {
-	Enable     Defbool
-	Opengl     Defbool
-	Display    string
-	Xauthority string
-}
-
-type Dominfo struct {
-	Uuid             Uuid
-	Domid            Domid
-	Ssidref          uint32
-	SsidLabel        string
-	Running          bool
-	Blocked          bool
-	Paused           bool
-	Shutdown         bool
-	Dying            bool
-	NeverStop        bool
-	ShutdownReason   ShutdownReason
-	OutstandingMemkb uint64
-	CurrentMemkb     uint64
-	SharedMemkb      uint64
-	PagedMemkb       uint64
-	MaxMemkb         uint64
-	CpuTime          uint64
-	VcpuMaxId        uint32
-	VcpuOnline       uint32
-	Cpupool          uint32
-	DomainType       DomainType
-}
-
-type Cpupoolinfo struct {
-	Poolid   uint32
-	PoolName string
-	Sched    Scheduler
-	NDom     uint32
-	Cpumap   Bitmap
-}
-
-type Channelinfo struct {
-	Backend         string
-	BackendId       uint32
-	Frontend        string
-	FrontendId      uint32
-	Devid           Devid
-	State           int
-	Evtch           int
-	Rref            int
-	Connection      ChannelConnection
-	ConnectionUnion channelinfoConnectionUnion
-}
-
-type channelinfoConnectionUnion interface {
-	ischannelinfoConnectionUnion()
-}
-
-type ChannelinfoConnectionUnionPty struct {
-	Path string
-}
-
-func (x ChannelinfoConnectionUnionPty) ischannelinfoConnectionUnion() {}
-
-type Vminfo struct {
-	Uuid  Uuid
-	Domid Domid
-}
-
-type VersionInfo struct {
-	XenVersionMajor int
-	XenVersionMinor int
-	XenVersionExtra string
-	Compiler        string
-	CompileBy       string
-	CompileDomain   string
-	CompileDate     string
-	Capabilities    string
-	Changeset       string
-	VirtStart       uint64
-	Pagesize        int
-	Commandline     string
-	BuildId         string
-}
-
-type DomainCreateInfo struct {
-	Type              DomainType
-	Hap               Defbool
-	Oos               Defbool
-	Ssidref           uint32
-	SsidLabel         string
-	Name              string
-	Domid             Domid
-	Uuid              Uuid
-	Xsdata            KeyValueList
-	Platformdata      KeyValueList
-	Poolid            uint32
-	PoolName          string
-	RunHotplugScripts Defbool
-	DriverDomain      Defbool
-	Passthrough       Passthrough
-}
-
-type DomainRestoreParams struct {
-	CheckpointedStream int
-	StreamVersion      uint32
-	ColoProxyScript    string
-	UserspaceColoProxy Defbool
-}
-
-type SchedParams struct {
-	Vcpuid    int
-	Weight    int
-	Cap       int
-	Period    int
-	Extratime int
-	Budget    int
-}
-
-type VcpuSchedParams struct {
-	Sched Scheduler
-	Vcpus []SchedParams
-}
-
-type DomainSchedParams struct {
-	Sched     Scheduler
-	Weight    int
-	Cap       int
-	Period    int
-	Budget    int
-	Extratime int
-	Slice     int
-	Latency   int
-}
-
-type VnodeInfo struct {
-	Memkb     uint64
-	Distances []uint32
-	Pnode     uint32
-	Vcpus     Bitmap
-}
-
-type GicVersion int
-
-const (
-	GicVersionDefault GicVersion = 0
-	GicVersionV2      GicVersion = 32
-	GicVersionV3      GicVersion = 48
-)
-
-type TeeType int
-
-const (
-	TeeTypeNone  TeeType = 0
-	TeeTypeOptee TeeType = 1
-)
-
-type RdmReserve struct {
-	Strategy RdmReserveStrategy
-	Policy   RdmReservePolicy
-}
-
-type Altp2MMode int
-
-const (
-	Altp2MModeDisabled Altp2MMode = 0
-	Altp2MModeMixed    Altp2MMode = 1
-	Altp2MModeExternal Altp2MMode = 2
-	Altp2MModeLimited  Altp2MMode = 3
-)
-
-type DomainBuildInfo struct {
-	MaxVcpus              int
-	AvailVcpus            Bitmap
-	Cpumap                Bitmap
-	Nodemap               Bitmap
-	VcpuHardAffinity      []Bitmap
-	VcpuSoftAffinity      []Bitmap
-	NumaPlacement         Defbool
-	TscMode               TscMode
-	MaxMemkb              uint64
-	TargetMemkb           uint64
-	VideoMemkb            uint64
-	ShadowMemkb           uint64
-	IommuMemkb            uint64
-	RtcTimeoffset         uint32
-	ExecSsidref           uint32
-	ExecSsidLabel         string
-	Localtime             Defbool
-	DisableMigrate        Defbool
-	Cpuid                 CpuidPolicyList
-	BlkdevStart           string
-	VnumaNodes            []VnodeInfo
-	MaxGrantFrames        uint32
-	MaxMaptrackFrames     uint32
-	DeviceModelVersion    DeviceModelVersion
-	DeviceModelStubdomain Defbool
-	DeviceModel           string
-	DeviceModelSsidref    uint32
-	DeviceModelSsidLabel  string
-	DeviceModelUser       string
-	Extra                 StringList
-	ExtraPv               StringList
-	ExtraHvm              StringList
-	SchedParams           DomainSchedParams
-	Ioports               []IoportRange
-	Irqs                  []uint32
-	Iomem                 []IomemRange
-	ClaimMode             Defbool
-	EventChannels         uint32
-	Kernel                string
-	Cmdline               string
-	Ramdisk               string
-	DeviceTree            string
-	Acpi                  Defbool
-	Bootloader            string
-	BootloaderArgs        StringList
-	TimerMode             TimerMode
-	NestedHvm             Defbool
-	Apic                  Defbool
-	DmRestrict            Defbool
-	Tee                   TeeType
-	Type                  DomainType
-	TypeUnion             domainBuildInfoTypeUnion
-	ArchArm               struct {
-		GicVersion GicVersion
-		Vuart      VuartType
-	}
-	Altp2M Altp2MMode
-}
-
-type domainBuildInfoTypeUnion interface {
-	isdomainBuildInfoTypeUnion()
-}
-
-type DomainBuildInfoTypeUnionHvm struct {
-	Firmware            string
-	Bios                BiosType
-	Pae                 Defbool
-	Apic                Defbool
-	Acpi                Defbool
-	AcpiS3              Defbool
-	AcpiS4              Defbool
-	AcpiLaptopSlate     Defbool
-	Nx                  Defbool
-	Viridian            Defbool
-	ViridianEnable      Bitmap
-	ViridianDisable     Bitmap
-	Timeoffset          string
-	Hpet                Defbool
-	VptAlign            Defbool
-	MmioHoleMemkb       uint64
-	TimerMode           TimerMode
-	NestedHvm           Defbool
-	Altp2M              Defbool
-	SystemFirmware      string
-	SmbiosFirmware      string
-	AcpiFirmware        string
-	Hdtype              Hdtype
-	Nographic           Defbool
-	Vga                 VgaInterfaceInfo
-	Vnc                 VncInfo
-	Keymap              string
-	Sdl                 SdlInfo
-	Spice               SpiceInfo
-	GfxPassthru         Defbool
-	GfxPassthruKind     GfxPassthruKind
-	Serial              string
-	Boot                string
-	Usb                 Defbool
-	Usbversion          int
-	Usbdevice           string
-	VkbDevice           Defbool
-	Soundhw             string
-	XenPlatformPci      Defbool
-	UsbdeviceList       StringList
-	VendorDevice        VendorDevice
-	MsVmGenid           MsVmGenid
-	SerialList          StringList
-	Rdm                 RdmReserve
-	RdmMemBoundaryMemkb uint64
-	McaCaps             uint64
-}
-
-func (x DomainBuildInfoTypeUnionHvm) isdomainBuildInfoTypeUnion() {}
-
-type DomainBuildInfoTypeUnionPv struct {
-	Kernel         string
-	SlackMemkb     uint64
-	Bootloader     string
-	BootloaderArgs StringList
-	Cmdline        string
-	Ramdisk        string
-	Features       string
-	E820Host       Defbool
-}
-
-func (x DomainBuildInfoTypeUnionPv) isdomainBuildInfoTypeUnion() {}
-
-type DomainBuildInfoTypeUnionPvh struct {
-	Pvshim        Defbool
-	PvshimPath    string
-	PvshimCmdline string
-	PvshimExtra   string
-}
-
-func (x DomainBuildInfoTypeUnionPvh) isdomainBuildInfoTypeUnion() {}
-
-type DeviceVfb struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-	Vnc            VncInfo
-	Sdl            SdlInfo
-	Keymap         string
-}
-
-type DeviceVkb struct {
-	BackendDomid           Domid
-	BackendDomname         string
-	Devid                  Devid
-	BackendType            VkbBackend
-	UniqueId               string
-	FeatureDisableKeyboard bool
-	FeatureDisablePointer  bool
-	FeatureAbsPointer      bool
-	FeatureRawPointer      bool
-	FeatureMultiTouch      bool
-	Width                  uint32
-	Height                 uint32
-	MultiTouchWidth        uint32
-	MultiTouchHeight       uint32
-	MultiTouchNumContacts  uint32
-}
-
-type DeviceDisk struct {
-	BackendDomid      Domid
-	BackendDomname    string
-	PdevPath          string
-	Vdev              string
-	Backend           DiskBackend
-	Format            DiskFormat
-	Script            string
-	Removable         int
-	Readwrite         int
-	IsCdrom           int
-	DirectIoSafe      bool
-	DiscardEnable     Defbool
-	ColoEnable        Defbool
-	ColoRestoreEnable Defbool
-	ColoHost          string
-	ColoPort          int
-	ColoExport        string
-	ActiveDisk        string
-	HiddenDisk        string
-}
-
-type DeviceNic struct {
-	BackendDomid                   Domid
-	BackendDomname                 string
-	Devid                          Devid
-	Mtu                            int
-	Model                          string
-	Mac                            Mac
-	Ip                             string
-	Bridge                         string
-	Ifname                         string
-	Script                         string
-	Nictype                        NicType
-	RateBytesPerInterval           uint64
-	RateIntervalUsecs              uint32
-	Gatewaydev                     string
-	ColoftForwarddev               string
-	ColoSockMirrorId               string
-	ColoSockMirrorIp               string
-	ColoSockMirrorPort             string
-	ColoSockComparePriInId         string
-	ColoSockComparePriInIp         string
-	ColoSockComparePriInPort       string
-	ColoSockCompareSecInId         string
-	ColoSockCompareSecInIp         string
-	ColoSockCompareSecInPort       string
-	ColoSockCompareNotifyId        string
-	ColoSockCompareNotifyIp        string
-	ColoSockCompareNotifyPort      string
-	ColoSockRedirector0Id          string
-	ColoSockRedirector0Ip          string
-	ColoSockRedirector0Port        string
-	ColoSockRedirector1Id          string
-	ColoSockRedirector1Ip          string
-	ColoSockRedirector1Port        string
-	ColoSockRedirector2Id          string
-	ColoSockRedirector2Ip          string
-	ColoSockRedirector2Port        string
-	ColoFilterMirrorQueue          string
-	ColoFilterMirrorOutdev         string
-	ColoFilterRedirector0Queue     string
-	ColoFilterRedirector0Indev     string
-	ColoFilterRedirector0Outdev    string
-	ColoFilterRedirector1Queue     string
-	ColoFilterRedirector1Indev     string
-	ColoFilterRedirector1Outdev    string
-	ColoComparePriIn               string
-	ColoCompareSecIn               string
-	ColoCompareOut                 string
-	ColoCompareNotifyDev           string
-	ColoSockSecRedirector0Id       string
-	ColoSockSecRedirector0Ip       string
-	ColoSockSecRedirector0Port     string
-	ColoSockSecRedirector1Id       string
-	ColoSockSecRedirector1Ip       string
-	ColoSockSecRedirector1Port     string
-	ColoFilterSecRedirector0Queue  string
-	ColoFilterSecRedirector0Indev  string
-	ColoFilterSecRedirector0Outdev string
-	ColoFilterSecRedirector1Queue  string
-	ColoFilterSecRedirector1Indev  string
-	ColoFilterSecRedirector1Outdev string
-	ColoFilterSecRewriter0Queue    string
-	ColoCheckpointHost             string
-	ColoCheckpointPort             string
-}
-
-type DevicePci struct {
-	Func         byte
-	Dev          byte
-	Bus          byte
-	Domain       int
-	Vdevfn       uint32
-	VfuncMask    uint32
-	Msitranslate bool
-	PowerMgmt    bool
-	Permissive   bool
-	Seize        bool
-	RdmPolicy    RdmReservePolicy
-}
-
-type DeviceRdm struct {
-	Start  uint64
-	Size   uint64
-	Policy RdmReservePolicy
-}
-
-type UsbctrlType int
-
-const (
-	UsbctrlTypeAuto        UsbctrlType = 0
-	UsbctrlTypePv          UsbctrlType = 1
-	UsbctrlTypeDevicemodel UsbctrlType = 2
-	UsbctrlTypeQusb        UsbctrlType = 3
-)
-
-type UsbdevType int
-
-const (
-	UsbdevTypeHostdev UsbdevType = 1
-)
-
-type DeviceUsbctrl struct {
-	Type           UsbctrlType
-	Devid          Devid
-	Version        int
-	Ports          int
-	BackendDomid   Domid
-	BackendDomname string
-}
-
-type DeviceUsbdev struct {
-	Ctrl      Devid
-	Port      int
-	Type      UsbdevType
-	TypeUnion deviceUsbdevTypeUnion
-}
-
-type deviceUsbdevTypeUnion interface {
-	isdeviceUsbdevTypeUnion()
-}
-
-type DeviceUsbdevTypeUnionHostdev struct {
-	Hostbus  byte
-	Hostaddr byte
-}
-
-func (x DeviceUsbdevTypeUnionHostdev) isdeviceUsbdevTypeUnion() {}
-
-type DeviceDtdev struct {
-	Path string
-}
-
-type DeviceVtpm struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-	Uuid           Uuid
-}
-
-type DeviceP9 struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Tag            string
-	Path           string
-	SecurityModel  string
-	Devid          Devid
-}
-
-type DevicePvcallsif struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-}
-
-type DeviceChannel struct {
-	BackendDomid    Domid
-	BackendDomname  string
-	Devid           Devid
-	Name            string
-	Connection      ChannelConnection
-	ConnectionUnion deviceChannelConnectionUnion
-}
-
-type deviceChannelConnectionUnion interface {
-	isdeviceChannelConnectionUnion()
-}
-
-type DeviceChannelConnectionUnionSocket struct {
-	Path string
-}
-
-func (x DeviceChannelConnectionUnionSocket) isdeviceChannelConnectionUnion() {}
-
-type ConnectorParam struct {
-	UniqueId string
-	Width    uint32
-	Height   uint32
-}
-
-type DeviceVdispl struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-	BeAlloc        bool
-	Connectors     []ConnectorParam
-}
-
-type VsndPcmFormat int
-
-const (
-	VsndPcmFormatS8               VsndPcmFormat = 1
-	VsndPcmFormatU8               VsndPcmFormat = 2
-	VsndPcmFormatS16Le            VsndPcmFormat = 3
-	VsndPcmFormatS16Be            VsndPcmFormat = 4
-	VsndPcmFormatU16Le            VsndPcmFormat = 5
-	VsndPcmFormatU16Be            VsndPcmFormat = 6
-	VsndPcmFormatS24Le            VsndPcmFormat = 7
-	VsndPcmFormatS24Be            VsndPcmFormat = 8
-	VsndPcmFormatU24Le            VsndPcmFormat = 9
-	VsndPcmFormatU24Be            VsndPcmFormat = 10
-	VsndPcmFormatS32Le            VsndPcmFormat = 11
-	VsndPcmFormatS32Be            VsndPcmFormat = 12
-	VsndPcmFormatU32Le            VsndPcmFormat = 13
-	VsndPcmFormatU32Be            VsndPcmFormat = 14
-	VsndPcmFormatF32Le            VsndPcmFormat = 15
-	VsndPcmFormatF32Be            VsndPcmFormat = 16
-	VsndPcmFormatF64Le            VsndPcmFormat = 17
-	VsndPcmFormatF64Be            VsndPcmFormat = 18
-	VsndPcmFormatIec958SubframeLe VsndPcmFormat = 19
-	VsndPcmFormatIec958SubframeBe VsndPcmFormat = 20
-	VsndPcmFormatMuLaw            VsndPcmFormat = 21
-	VsndPcmFormatALaw             VsndPcmFormat = 22
-	VsndPcmFormatImaAdpcm         VsndPcmFormat = 23
-	VsndPcmFormatMpeg             VsndPcmFormat = 24
-	VsndPcmFormatGsm              VsndPcmFormat = 25
-)
-
-type VsndParams struct {
-	SampleRates   []uint32
-	SampleFormats []VsndPcmFormat
-	ChannelsMin   uint32
-	ChannelsMax   uint32
-	BufferSize    uint32
-}
-
-type VsndStreamType int
-
-const (
-	VsndStreamTypeP VsndStreamType = 1
-	VsndStreamTypeC VsndStreamType = 2
-)
-
-type VsndStream struct {
-	UniqueId string
-	Type     VsndStreamType
-	Params   VsndParams
-}
-
-type VsndPcm struct {
-	Name    string
-	Params  VsndParams
-	Streams []VsndStream
-}
-
-type DeviceVsnd struct {
-	BackendDomid   Domid
-	BackendDomname string
-	Devid          Devid
-	ShortName      string
-	LongName       string
-	Params         VsndParams
-	Pcms           []VsndPcm
-}
-
-type DomainConfig struct {
-	CInfo       DomainCreateInfo
-	BInfo       DomainBuildInfo
-	Disks       []DeviceDisk
-	Nics        []DeviceNic
-	Pcidevs     []DevicePci
-	Rdms        []DeviceRdm
-	Dtdevs      []DeviceDtdev
-	Vfbs        []DeviceVfb
-	Vkbs        []DeviceVkb
-	Vtpms       []DeviceVtpm
-	P9S         []DeviceP9
-	Pvcallsifs  []DevicePvcallsif
-	Vdispls     []DeviceVdispl
-	Vsnds       []DeviceVsnd
-	Channels    []DeviceChannel
-	Usbctrls    []DeviceUsbctrl
-	Usbdevs     []DeviceUsbdev
-	OnPoweroff  ActionOnShutdown
-	OnReboot    ActionOnShutdown
-	OnWatchdog  ActionOnShutdown
-	OnCrash     ActionOnShutdown
-	OnSoftReset ActionOnShutdown
-}
-
-type Diskinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Evtch      int
-	Rref       int
-}
-
-type Nicinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Evtch      int
-	RrefTx     int
-	RrefRx     int
-}
-
-type Vtpminfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Evtch      int
-	Rref       int
-	Uuid       Uuid
-}
-
-type Usbctrlinfo struct {
-	Type       UsbctrlType
-	Devid      Devid
-	Version    int
-	Ports      int
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	State      int
-	Evtch      int
-	RefUrb     int
-	RefConn    int
-}
-
-type Vcpuinfo struct {
-	Vcpuid     uint32
-	Cpu        uint32
-	Online     bool
-	Blocked    bool
-	Running    bool
-	VcpuTime   uint64
-	Cpumap     Bitmap
-	CpumapSoft Bitmap
-}
-
-type Physinfo struct {
-	ThreadsPerCore     uint32
-	CoresPerSocket     uint32
-	MaxCpuId           uint32
-	NrCpus             uint32
-	CpuKhz             uint32
-	TotalPages         uint64
-	FreePages          uint64
-	ScrubPages         uint64
-	OutstandingPages   uint64
-	SharingFreedPages  uint64
-	SharingUsedFrames  uint64
-	MaxPossibleMfn     uint64
-	NrNodes            uint32
-	HwCap              Hwcap
-	CapHvm             bool
-	CapPv              bool
-	CapHvmDirectio     bool
-	CapHap             bool
-	CapShadow          bool
-	CapIommuHapPtShare bool
-}
-
-type Connectorinfo struct {
-	UniqueId string
-	Width    uint32
-	Height   uint32
-	ReqEvtch int
-	ReqRref  int
-	EvtEvtch int
-	EvtRref  int
-}
-
-type Vdisplinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	BeAlloc    bool
-	Connectors []Connectorinfo
-}
-
-type Streaminfo struct {
-	ReqEvtch int
-	ReqRref  int
-}
-
-type Pcminfo struct {
-	Streams []Streaminfo
-}
-
-type Vsndinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Pcms       []Pcminfo
-}
-
-type Vkbinfo struct {
-	Backend    string
-	BackendId  uint32
-	Frontend   string
-	FrontendId uint32
-	Devid      Devid
-	State      int
-	Evtch      int
-	Rref       int
-}
-
-type Numainfo struct {
-	Size  uint64
-	Free  uint64
-	Dists []uint32
-}
-
-type Cputopology struct {
-	Core   uint32
-	Socket uint32
-	Node   uint32
-}
-
-type Pcitopology struct {
-	Seg   uint16
-	Bus   byte
-	Devfn byte
-	Node  uint32
-}
-
-type SchedCreditParams struct {
-	TsliceMs        int
-	RatelimitUs     int
-	VcpuMigrDelayUs int
-}
-
-type SchedCredit2Params struct {
-	RatelimitUs int
-}
-
-type DomainRemusInfo struct {
-	Interval           int
-	AllowUnsafe        Defbool
-	Blackhole          Defbool
-	Compression        Defbool
-	Netbuf             Defbool
-	Netbufscript       string
-	Diskbuf            Defbool
-	Colo               Defbool
-	UserspaceColoProxy Defbool
-}
-
-type EventType int
-
-const (
-	EventTypeDomainShutdown               EventType = 1
-	EventTypeDomainDeath                  EventType = 2
-	EventTypeDiskEject                    EventType = 3
-	EventTypeOperationComplete            EventType = 4
-	EventTypeDomainCreateConsoleAvailable EventType = 5
-)
-
-type Event struct {
-	Link      EvLink
-	Domid     Domid
-	Domuuid   Uuid
-	ForUser   uint64
-	Type      EventType
-	TypeUnion eventTypeUnion
-}
-
-type eventTypeUnion interface {
-	iseventTypeUnion()
-}
-
-type EventTypeUnionDomainShutdown struct {
-	ShutdownReason byte
-}
-
-func (x EventTypeUnionDomainShutdown) iseventTypeUnion() {}
-
-type EventTypeUnionDiskEject struct {
-	Vdev string
-	Disk DeviceDisk
-}
-
-func (x EventTypeUnionDiskEject) iseventTypeUnion() {}
-
-type EventTypeUnionOperationComplete struct {
-	Rc int
-}
-
-func (x EventTypeUnionOperationComplete) iseventTypeUnion() {}
-
-type PsrCmtType int
-
-const (
-	PsrCmtTypeCacheOccupancy PsrCmtType = 1
-	PsrCmtTypeTotalMemCount  PsrCmtType = 2
-	PsrCmtTypeLocalMemCount  PsrCmtType = 3
-)
-
-type PsrCbmType int
-
-const (
-	PsrCbmTypeUnknown   PsrCbmType = 0
-	PsrCbmTypeL3Cbm     PsrCbmType = 1
-	PsrCbmTypeL3CbmCode PsrCbmType = 2
-	PsrCbmTypeL3CbmData PsrCbmType = 3
-	PsrCbmTypeL2Cbm     PsrCbmType = 4
-	PsrCbmTypeMbaThrtl  PsrCbmType = 5
-)
-
-type PsrCatInfo struct {
-	Id         uint32
-	CosMax     uint32
-	CbmLen     uint32
-	CdpEnabled bool
-}
-
-type PsrFeatType int
-
-const (
-	PsrFeatTypeCat PsrFeatType = 1
-	PsrFeatTypeMba PsrFeatType = 2
-)
-
-type PsrHwInfo struct {
-	Id        uint32
-	Type      PsrFeatType
-	TypeUnion psrHwInfoTypeUnion
-}
-
-type psrHwInfoTypeUnion interface {
-	ispsrHwInfoTypeUnion()
-}
-
-type PsrHwInfoTypeUnionCat struct {
-	CosMax     uint32
-	CbmLen     uint32
-	CdpEnabled bool
-}
-
-func (x PsrHwInfoTypeUnionCat) ispsrHwInfoTypeUnion() {}
-
-type PsrHwInfoTypeUnionMba struct {
-	CosMax   uint32
-	ThrtlMax uint32
-	Linear   bool
-}
-
-func (x PsrHwInfoTypeUnionMba) ispsrHwInfoTypeUnion() {}
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 03:56:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 03:56:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRpRg-00063N-5e; Fri, 24 Apr 2020 03:56:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRpRe-00063I-Ii
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 03:56:06 +0000
X-Inumbo-ID: 85950d36-85df-11ea-9453-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 85950d36-85df-11ea-9453-12813bfff9fa;
 Fri, 24 Apr 2020 03:56:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=WEt1y3q/9HDldLygKfJ9p1tvfLB/8bL/YRPJEQA0xjI=; b=hzYgnplW3jdOAiWuNE0QiM+kU
 YsUNpXeSfeMvpC/n8zU0WiMWKVs9rHKGg8sRquWQzjxgHbUPS48tUCyeqXOVbyQZHaED1oOSYZBRM
 kleY16UM+L9oXHZbGHI/EWx7ljCJoUSpOVV1fe5p4jJvMb6EumG5sZKBVlhCo5Cnl6+jo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRpRd-0004VC-0Y; Fri, 24 Apr 2020 03:56:05 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRpRc-0001k1-Mo; Fri, 24 Apr 2020 03:56:04 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRpRc-0006Qz-M7; Fri, 24 Apr 2020 03:56:04 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149764-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149764: tolerable trouble: fail/pass/starved -
 PUSHED
X-Osstest-Failures: linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:guest-start/debianhvm.repeat:fail:heisenbug
 linux-linus:test-armhf-armhf-xl-rtds:guest-start:fail:heisenbug
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore.2:fail:allowable
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 linux-linus:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: linux=c578ddb39e565139897124e74e5a43e56538cb33
X-Osstest-Versions-That: linux=18bf34080c4c3beb6699181986cc97dd712498fe
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 03:56:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149764 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149764/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 guest-start/debianhvm.repeat fail in 149743 pass in 149764
 test-armhf-armhf-xl-rtds     12 guest-start      fail in 149743 pass in 149764
 test-amd64-amd64-xl-rtds     16 guest-localmigrate         fail pass in 149743

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds    16 guest-start/debian.repeat fail REGR. vs. 149731
 test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail in 149743 REGR. vs. 149731

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149731
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149731
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149731
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149731
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149731
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149731
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149731
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149731
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate               starved  n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate               starved  n/a

version targeted for testing:
 linux                c578ddb39e565139897124e74e5a43e56538cb33
baseline version:
 linux                18bf34080c4c3beb6699181986cc97dd712498fe

Last test of basis   149731  2020-04-22 04:00:57 Z    1 days
Testing same since   149743  2020-04-23 03:15:23 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Righi <andrea.righi@canonical.com>
  Colin Ian King <colin.king@canonical.com>
  Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
  Kees Cook <keescook@chromium.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Michael Ellerman <mpe@ellerman.id.au>
  Sandipan Das <sandipan@linux.ibm.com>
  Shuah Khan <skhan@linuxfoundation.org>
  Steven Rostedt (VMware) <rostedt@goodmis.org>
  Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
  Tyler Hicks <tyhicks@linux.microsoft.com>
  Xiao Yang <yangx.jy@cn.fujitsu.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                starved 
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 starved 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   18bf34080c4c..c578ddb39e56  c578ddb39e565139897124e74e5a43e56538cb33 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 04:04:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 04:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRpa2-000716-2a; Fri, 24 Apr 2020 04:04:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6uIs=6I=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jRpa1-000711-0M
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 04:04:45 +0000
X-Inumbo-ID: ba1d8604-85e0-11ea-b58d-bc764e2007e4
Received: from mail-lf1-x12d.google.com (unknown [2a00:1450:4864:20::12d])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ba1d8604-85e0-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 04:04:43 +0000 (UTC)
Received: by mail-lf1-x12d.google.com with SMTP id 198so6545212lfo.7
 for <xen-devel@lists.xenproject.org>; Thu, 23 Apr 2020 21:04:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=5fFwBR4pUDYgSJUcqyFG/qQ4dl45iprBz6LqchmxwrU=;
 b=a/AocphZKtyrRmlFCC3sKesidSDDu39p4Sz1IuhBAJ4/nnXABK7PNFtAJ4XVixU9O0
 IefaB1cV1tJL39JsxmNiH7MFhUj+jgABC6m5xFyzN+sK1hJDFXb2MKhNC2SlIAbuJ1pP
 p1DdITNYDYkeufUWFLRl0HgihQ9GupJXTB5n8tMdj3/Pfj5qFOKmMFyu+8pAYCM//Qwe
 XEWvngiYBBtVMFmPH73oLBLZIoQEn4Xd+YM/msXMNx35CzDTt8QH2d78DczHarakAXU1
 Hr6rGMsQCn5I44ZUvy9701xChOQrVKHHPvluvRdikefGWZOGIbq9IHosJbaTOnfJVOZs
 fzDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=5fFwBR4pUDYgSJUcqyFG/qQ4dl45iprBz6LqchmxwrU=;
 b=FSVGTxX2j9bhwD0eQi/DOlaRwabV0vEKLw9P/g8VqOFOknRQ+KHra5SIhvP6qw53q7
 gfH19MfVduOjW9h28Gws4HgS2yCDiRJR3fEHQ+lrXJuXcsgydNAUz6oD8fqszocF73MD
 XIpoF5QIRwqdSBEjLuvKJB4XdVqZ1Z6Y219K6XABcoXuhFxPRyJyL3ro5yM4fwYlcG6f
 WP8MaMurVnTyKreywidd9aH+Bj7+BNGCnJ0noLy5cldr/0m4zsBk2ifrpAbdLxwuyYN+
 T5f112wbia6djng3U+h19/T76v+D+gwJVOuKfaXzjeDkH4Ra3xA/MtG3R+V5cjgknKmQ
 DtBQ==
X-Gm-Message-State: AGi0PuYXyk2v4PpFXTLJdhUF76DMOAyCHG7e+C1J7xvcm0DKOWPXakYq
 Bw45e/zehxbA/VkTNtncvbBdYjSBGzDZuSaCzPQ=
X-Google-Smtp-Source: APiQypKrhDkBJ0vi2ONFv0E6S1ZmKi4PFfIZF+QSzmNh1WRmT4Sw47WoLwCKWusPwoAkgIsvOEF4nKaoMUAxJRdEbgo=
X-Received: by 2002:a05:6512:14a:: with SMTP id
 m10mr4662613lfo.152.1587701082464; 
 Thu, 23 Apr 2020 21:04:42 -0700 (PDT)
MIME-Version: 1.0
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
 <24225.31493.220592.722565@mariner.uk.xensource.com>
 <24225.31669.536258.56822@mariner.uk.xensource.com>
 <4085F05B-ABEC-446A-8BB1-06DEE57D71A5@citrix.com>
 <C10E07AB-FDE8-4588-95E7-6109F0FDB5E2@citrix.com>
In-Reply-To: <C10E07AB-FDE8-4588-95E7-6109F0FDB5E2@citrix.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Fri, 24 Apr 2020 00:04:31 -0400
Message-ID: <CAEBZRSfUysyGhnsXDEAJiVDBeX-Kb836V-uT6Qrtomte1LKgsA@mail.gmail.com>
Subject: Re: Golang Xen packages and the golang packaging system
To: George Dunlap <George.Dunlap@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 1:22 PM George Dunlap <George.Dunlap@citrix.com> wr=
ote:
>
>
> > On Apr 23, 2020, at 12:49 PM, George Dunlap <george.dunlap@citrix.com> =
wrote:
> >
> >
> >
> >> On Apr 23, 2020, at 12:27 PM, Ian Jackson <ian.jackson@citrix.com> wro=
te:
> >>
> >> Ian Jackson writes ("Re: Golang Xen packages and the golang packaging =
 system"):
> >>> This is quite unpleasant.  In particular, it makes a git tree out of
> >>> output files.  What will we do when someone sends us patches to the
> >>> bindings ?
> >>
> >> Also, anyone who redistributes your proposed golang package is
> >> violating our licence unless they ship a copy of xen.git[1] too, since
> >> the golang package is not source code.
> >>
> >> [1] Technically, a copy of the relevant parts will do.
> >
> > The =E2=80=9Crelevant parts=E2=80=9D would primarily be gengotypes.py, =
right?  Oh, and I guess libxl_test.idl and friends.  libxl_test.idl isn=E2=
=80=99t included in the distribution either.
> >
> > I=E2=80=99m not an expert in the golang build system, but they generall=
y seem to be trying to keep the functionality simple (which of course, mean=
s if you want to do anything non-basic, it=E2=80=99s incredibly complicated=
 or completely impossible).
> >
> > There=E2=80=99s a command, `go generate`, which we could use to run gen=
gotypes.py to generate the appropriate files.  But I=E2=80=99m not sure how=
 to use that in a practical way for this sort of package: it might end up t=
hat people wanting to use the package would need to manually clone it, then=
 manually run `go generate` before manually building the package.
> >
> > Checking in the generated files means that someone can simply add `gola=
ng.xenproject.org/xenlight` as a dependency (perhaps with a specific versio=
n tag, like v4.14), and everything Just Works.
> >
> > Nick may have some ideas on how to use the golang build system more eff=
ectively.
>
> So, the following seems to work quite well actually:
>
> mkdir vendor
> ln -s vendor/golang.xenproject.org /usr/share/gocode/src/golang.xenprojec=
t.org
> echo =E2=80=9Cgolang.xenproject.org/xenlight=E2=80=9D >> vendor/modules.t=
xt
> go build -mod=3Dvendor
>
> Using the above method, (say) redctl.git would build exactly the same on =
Xen 4.14 as on Xen 4.15 (assuming redctl wasn=E2=80=99t using anything not =
available in 4.14).
>
> I=E2=80=99m inclined to say we should start with just telling people to d=
o that, and look at doing something else if we discover that=E2=80=99s not =
suitable for some reason.

If it's not viable to create another repo for the xenlight package, I
think we should should just initialize the go module, i.e. go.mod, at
xen.git/tools/golang. The downside is that tags cannot be independent
from the rest of xen.git, so users need to have `require <module
path>/xenlight@RELEASE-4.14.0` in their go.mod, but at least its `go
get`-able. And, this does not fetch the entire git tree.

This would also mean that we actually track the generated code (which
isn't really a big deal IMO, it's expected that people track their
generated gRPC code, for example).

I spent some time today trying to get `go get <vanity URL>/xenlight`
to work, after defining the go.mod (with <vanity URL>/xenlight as the
import path) in tools/golang. I *think* it's do-able with a meta-tag
like: `<meta name=3D"go-import" content=3D"<vanity URL>/xenlight mod
https://proxy.golang.org">`, but I was having a hard time getting the
package to show up on pkg.go.dev or proxy.golang.org. I'm not totally
familiar with the module proxies yet, but it seems like it could be a
way to detach ourselves from the "package is defined at the root of a
git repo" problem.

-NR


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 05:28:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 05:28:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRqsp-0005bH-GW; Fri, 24 Apr 2020 05:28:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Nbk=6I=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jRqsn-0005aY-Fq
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 05:28:13 +0000
X-Inumbo-ID: 63d8c1da-85ec-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 63d8c1da-85ec-11ea-83d8-bc764e2007e4;
 Fri, 24 Apr 2020 05:28:12 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DAFB3AD94;
 Fri, 24 Apr 2020 05:28:10 +0000 (UTC)
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
 <5dc9dbd9-fbeb-46ef-4d4e-7916c3219bb3@suse.com>
 <4e732f90-1d5f-7ae5-0f02-6b313a381df7@citrix.com>
 <6b4e5b50-51f7-566f-2a18-4bb5f4f43d59@suse.com>
 <62b51cff-4d6f-690b-371a-e6772ea327ab@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <68146423-c2cb-0bf4-4bb8-3c89ad17bbcc@suse.com>
Date: Fri, 24 Apr 2020 07:28:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <62b51cff-4d6f-690b-371a-e6772ea327ab@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.20 19:35, Andrew Cooper wrote:
> On 21/04/2020 07:02, Jan Beulich wrote:
>> On 20.04.2020 20:05, Andrew Cooper wrote:
>>> On 20/04/2020 15:05, Jan Beulich wrote:
>>>> I'm in particular
>>>> concerned that we may gain a large number of such printk()s over
>>>> time, if we added them in such cases.
>>> The printk() was a bit of an afterthought, but deliberately avoiding the
>>> -EINVAL path was specifically not.
>>>
>>> In the case that the user tries to use `pv=no-32` without CONFIG_PV32,
>>> they should see something other than
>>>
>>> (XEN) parameter "pv=no-32" unknown!
>> Why - to this specific build of Xen the parameter is unknown.
> 
> Because it is unnecessarily problematic and borderline obnoxious to
> users, as well as occasional Xen developers.
> 
> "you've not got the correct CONFIG_$X for that to be meaningful" is
> specifically useful to separate from "I've got no idea".
> 
>>> I don't think overloading the return value is a clever move, because
>>> then every parse function has to take care of ensuring that -EOPNOTSUPP
>>> (or ENODEV?) never clobbers -EINVAL.
>> I didn't suggest overloading the return value. Instead I
>> specifically want this to go the -EINVAL path.
>>
>>> We could have a generic helper which looks like:
>>>
>>> static inline void ignored_param(const char *cfg, const char *name,
>>> const char *s, const char *ss)
>>> {
>>>      printk(XENLOG_INFO "%s disabled - ignoring '%s=%*.s' setting\n",
>>> cfg, name, s, (int)(ss - s));
>>> }
>>>
>>> which at least would keep all the users consistent.
>> Further bloating the binary with (almost) useless string literals.
>> I'd specifically like to avoid this.
> 
> I don't accept that as a valid argument.
> 
> We're talking about literally tens of bytes (which will merge anyway, so
> 0 in practice), and a resulting UI which helps people get out of
> problems rather than penalises them for having gotten into a problem to
> begin with.
> 
> I will absolutely prioritise a more helpful UI over a handful of bytes.

What about a kconfig option (defaulting to "yes") enabling this feature?

That way an embedded variant can be made smaller while a server one is
more user friendly.


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 06:11:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 06:11:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRrYa-0001DK-12; Fri, 24 Apr 2020 06:11:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRrYZ-0001DF-Gw
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 06:11:23 +0000
X-Inumbo-ID: 6b9a08ec-85f2-11ea-9466-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6b9a08ec-85f2-11ea-9466-12813bfff9fa;
 Fri, 24 Apr 2020 06:11:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B07F5ADEB;
 Fri, 24 Apr 2020 06:11:20 +0000 (UTC)
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
 <5dc9dbd9-fbeb-46ef-4d4e-7916c3219bb3@suse.com>
 <4e732f90-1d5f-7ae5-0f02-6b313a381df7@citrix.com>
 <6b4e5b50-51f7-566f-2a18-4bb5f4f43d59@suse.com>
 <62b51cff-4d6f-690b-371a-e6772ea327ab@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <a0671e13-85ea-aeaf-722c-dcfee8b7e930@suse.com>
Date: Fri, 24 Apr 2020 08:11:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <62b51cff-4d6f-690b-371a-e6772ea327ab@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.2020 19:35, Andrew Cooper wrote:
> On 21/04/2020 07:02, Jan Beulich wrote:
>> On 20.04.2020 20:05, Andrew Cooper wrote:
>>> On 20/04/2020 15:05, Jan Beulich wrote:
>>>> I'm in particular
>>>> concerned that we may gain a large number of such printk()s over
>>>> time, if we added them in such cases.
>>> The printk() was a bit of an afterthought, but deliberately avoiding the
>>> -EINVAL path was specifically not.
>>>
>>> In the case that the user tries to use `pv=no-32` without CONFIG_PV32,
>>> they should see something other than
>>>
>>> (XEN) parameter "pv=no-32" unknown!
>> Why - to this specific build of Xen the parameter is unknown.
> 
> Because it is unnecessarily problematic and borderline obnoxious to
> users, as well as occasional Xen developers.
> 
> "you've not got the correct CONFIG_$X for that to be meaningful" is
> specifically useful to separate from "I've got no idea".
> 
>>> I don't think overloading the return value is a clever move, because
>>> then every parse function has to take care of ensuring that -EOPNOTSUPP
>>> (or ENODEV?) never clobbers -EINVAL.
>> I didn't suggest overloading the return value. Instead I
>> specifically want this to go the -EINVAL path.
>>
>>> We could have a generic helper which looks like:
>>>
>>> static inline void ignored_param(const char *cfg, const char *name,
>>> const char *s, const char *ss)
>>> {
>>>     printk(XENLOG_INFO "%s disabled - ignoring '%s=%*.s' setting\n",
>>> cfg, name, s, (int)(ss - s));
>>> }
>>>
>>> which at least would keep all the users consistent.
>> Further bloating the binary with (almost) useless string literals.
>> I'd specifically like to avoid this.
> 
> I don't accept that as a valid argument.
> 
> We're talking about literally tens of bytes (which will merge anyway, so
> 0 in practice), and a resulting UI which helps people get out of
> problems rather than penalises them for having gotten into a problem to
> begin with.

How will they merge? The different instances of the format string
above may/should, yes, but the different "CONFIG_xyz" literals the
callers pass won't, for example.

> I will absolutely prioritise a more helpful UI over a handful of bytes.

This "a handful of bytes doesn't matter" attitude has lead to
imo unacceptable growth of various software packages over the
years.

Anyway - I don't want to block this change over this argument,
so I'm willing to ack a patch with the helper introduced (and
preferably the "CONFIG_" part of the cfg arguments moved into
the helper's format string), as long as we plan to then make
consistent use of the helper everywhere. That said, I don't
immediately see what would be passed for "cfg" in some of
parse_iommu_param()'s cases.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 06:13:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 06:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRraB-0001Jy-CU; Fri, 24 Apr 2020 06:13:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRraA-0001Jt-L6
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 06:13:02 +0000
X-Inumbo-ID: a6c9aef4-85f2-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a6c9aef4-85f2-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 06:13:02 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 656BBADEB;
 Fri, 24 Apr 2020 06:13:00 +0000 (UTC)
Subject: Re: [PATCH 1/3] x86/S3: Use percpu_traps_init() rather than
 opencoding SYSCALL/SYSENTER restoration
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
 <20200420145911.5708-2-andrew.cooper3@citrix.com>
 <db70738a-4750-2780-2f44-b0bcd3a5f93b@suse.com>
 <4ff5227c-a9a4-f6cc-2068-ddd41165ebaf@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <32681985-49cb-339b-0ba2-9dbe11bbdc63@suse.com>
Date: Fri, 24 Apr 2020 08:13:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <4ff5227c-a9a4-f6cc-2068-ddd41165ebaf@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.2020 20:24, Andrew Cooper wrote:
> On 21/04/2020 08:24, Jan Beulich wrote:
>> On 20.04.2020 16:59, Andrew Cooper wrote:
>>> @@ -46,24 +36,13 @@ void restore_rest_processor_state(void)
>>>      /* Restore full CR4 (inc MCE) now that the IDT is in place. */
>>>      write_cr4(mmu_cr4_features);
>>>  
>>> -    /* Recover syscall MSRs */
>>> -    wrmsrl(MSR_LSTAR, saved_lstar);
>>> -    wrmsrl(MSR_CSTAR, saved_cstar);
>>> -    wrmsrl(MSR_STAR, XEN_MSR_STAR);
>>> -    wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
>>> +    /* (re)initialise SYSCALL/SYSENTER state, amongst other things. */
>>> +    percpu_traps_init();
>> Without tweaks to subarch_percpu_traps_init() this assumes that,
>> now and going forward, map_domain_page() will work reliably at
>> this early point of resume. I'm not opposed, i.e.
>> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> I think this reasonable to expect, and robust going forward.
> 
> We are properly in d[IDLE]v0 context when it comes to pagetables, and
> there is nothing interesting between this point and coming fully back
> online.
> 
> That said, I could easily move the call to later in the resume path for
> even more certainty.
> 
> diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> index 3ad7dfc9a3..d5a468eddd 100644
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -297,6 +297,8 @@ static int enter_state(u32 state)
>      ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);
>      spec_ctrl_exit_idle(ci);
>  
> +    /* (re)initialise SYSCALL/SYSENTER state, amongst other things. */
> +    percpu_traps_init();
> +
>   done:
>      spin_debug_enable();
>      local_irq_restore(flags);
> 
> In fact - I prefer this, because it works towards one low priority goal
> of deleting {save,restore}_rest_processor_state() which I've still got a
> pending series for.
> 
> Would your ack still stand if I tweak the patch in this way?

Yes.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 06:21:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 06:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRrid-0002Br-8m; Fri, 24 Apr 2020 06:21:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRrib-0002Bm-Qo
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 06:21:45 +0000
X-Inumbo-ID: de7c4220-85f3-11ea-83d8-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id de7c4220-85f3-11ea-83d8-bc764e2007e4;
 Fri, 24 Apr 2020 06:21:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 41005AF33;
 Fri, 24 Apr 2020 06:21:43 +0000 (UTC)
Subject: Re: [PATCH 3/3] x86/pv: Don't use IST for NMI/#MC/#DB in !CONFIG_PV
 builds
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200420145911.5708-1-andrew.cooper3@citrix.com>
 <20200420145911.5708-4-andrew.cooper3@citrix.com>
 <08a798db-3126-7ccd-17f3-476607cc9e45@suse.com>
 <76fa899a-2b35-8ea9-159e-c9e3dcf88f53@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3281b2cc-4bab-65f7-0583-2ee30b4f3b22@suse.com>
Date: Fri, 24 Apr 2020 08:21:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <76fa899a-2b35-8ea9-159e-c9e3dcf88f53@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.2020 20:49, Andrew Cooper wrote:
> On 21/04/2020 08:48, Jan Beulich wrote:
>> On 20.04.2020 16:59, Andrew Cooper wrote:
>>> --- a/xen/include/asm-x86/processor.h
>>> +++ b/xen/include/asm-x86/processor.h
>>> @@ -441,12 +441,18 @@ struct tss_page {
>>>  };
>>>  DECLARE_PER_CPU(struct tss_page, tss_page);
>>>  
>>> +/*
>>> + * Interrupt Stack Tables.  Used to force a stack switch on a CPL0=>0
>>> + * interrupt/exception.  #DF uses IST all the time to detect stack overflows
>>> + * cleanly.  NMI/#MC/#DB only need IST to cover the SYSCALL gap, and therefore
>>> + * only necessary with PV guests.
>>> + */
>> Is it really only the SYSCALL gap that we mean to cover? In particular
>> for #MC I'd suspect it is a good idea to switch stacks as well, to get
>> onto a distinct memory page in case the #MC was stack related.
> 
> If #MC occurs on your stack, you have already lost.  The chances of only
> taking a single #MC are tiny because the next-line prefetcher will be
> doing its job (or it hits when the lines (plural) leave L3, which will
> be in guest context at some point in the future.)

It would seem fishy behavior to me for the hardware to continue
issuing prefetches against a page that has just been noticed to
cause issues when accessed. Surely hardware at least _could_
internally mark such a page #UC or some such, to prevent further
prefetches to actually hit the bus.

> The very best you can hope for is to cleanly print something and crash -
> even if you manage to run the handler, you've got no idea if the
> interrupted context had a spinlock held, and Xen has no support for
> changing to a different pcpu stack.

But getting something printed is magnitudes better that hanging
or rebooting entirely silently.

Nevertheless, as long as you extend the description somewhat to
express this reasoning in some way
Reviewed-by: Jan Beulich <jbeulich@suse.com>
(a little hesitantly though).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 06:44:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 06:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRs4n-0003wM-4A; Fri, 24 Apr 2020 06:44:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRs4l-0003wH-Pa
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 06:44:39 +0000
X-Inumbo-ID: 10b6409f-85f7-11ea-9467-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 10b6409f-85f7-11ea-9467-12813bfff9fa;
 Fri, 24 Apr 2020 06:44:38 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 03539AC2C;
 Fri, 24 Apr 2020 06:44:36 +0000 (UTC)
Subject: Re: [xen-unstable test] 149752: regressions - trouble:
 blocked/fail/pass/starved
To: osstest service owner <osstest-admin@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <osstest-149752-mainreport@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <ac5222a2-fa77-14e6-7dd9-37c88ec98d66@suse.com>
Date: Fri, 24 Apr 2020 08:44:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <osstest-149752-mainreport@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.2020 23:53, osstest service owner wrote:
> flight 149752 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/149752/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-prev               6 xen-build                fail REGR. vs. 149741
>  build-i386                    6 xen-build                fail REGR. vs. 149741
>  build-i386-xsm                6 xen-build                fail REGR. vs. 149741

Despite this looking like a pattern hinting at a 32-bit build
issue, all three failed because of an issue with fetching ovmf
afaics.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 07:39:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 07:39:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRsvR-00088s-Di; Fri, 24 Apr 2020 07:39:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=JRE+=6I=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jRsvQ-00088n-CR
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 07:39:04 +0000
X-Inumbo-ID: ab571e1e-85fe-11ea-946c-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ab571e1e-85fe-11ea-946c-12813bfff9fa;
 Fri, 24 Apr 2020 07:39:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Reply-To:
 MIME-Version:Message-Id:Date:Subject:Cc:To:From:Sender:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=9zI96FXku7qpDvxUPWuk9DdZZnaflDMi2+UERDb/Is0=; b=yrWeB5czT5yE4+WvLvToqeUB9j
 xd01NAXarP0SZQvGsARy1A2eZviQOKI+LkbM6bWmCYsMu05klgDB+bvItGOhtQz1K9PvC+j+TOiJ5
 BRvKqJGEO36mqUYVxKwaozd4CMGXhRCKznouuzFR4uPIE6y/1nm4m1bMEXnf2ul9W6+o=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <paul@xen.org>)
 id 1jRsvN-0001Cy-TL; Fri, 24 Apr 2020 07:39:01 +0000
Received: from [54.239.6.186] (helo=CBG-R90WXYV0.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jRsvN-0005FS-G4; Fri, 24 Apr 2020 07:39:01 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [ANNOUNCE] Xen 4.14 Development Update
Date: Fri, 24 Apr 2020 08:38:59 +0100
Message-Id: <20200424073859.89-1-paul@xen.org>
X-Mailer: git-send-email 2.17.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: xen-devel@lists.xenproject.org, pdurrant@amazon.com
Cc: jgross@suse.com, andrew.cooper3@citrix.com, pdurrant@amazon.com,
 marmarek@invisiblethingslab.com, hongyxia@amazon.com, jbeulich@suse.com,
 tamas.k.lengyel@gmail.com, roger.pau@citrix.com, dwmw@amazon.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

*** ONE WEEK UNTIL LAST POSTING ***

This email only tracks big items for xen.git tree. Please reply for items
you would like to see in 4.14 so that people have an idea what
is going on and prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release about every 8
 months.
The critical dates for Xen 4.14 are as follows:

---> We are here
* Last posting date: May 1st, 2020
* Hard code freeze: May 22nd, 2020
* Release: June 26th, 2020

Note that we don't have a freeze exception scheme anymore. All patches
that wish to go into 4.14 must be posted initially no later than the
last posting date and finally no later than the hard code freeze.
All patches posted after that date will be automatically queued into next
release.

RCs will be arranged immediately after freeze.

There is also a jira instance to track all the tasks (not only big)
for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.

Some of the tasks tracked by this e-mail also have a corresponding jira task
referred by XEN-N.

There is a version number for patch series associated to each feature.
Can each owner send an update giving the latest version number if the
series has been re-posted? Also, can the owners of any completed items
please respond so that the item can be moved into the 'Completed' section.

= Projects =

== Hypervisor == 

*  Live-Updating Xen (RFC v2)
  -  David Woodhouse
  -  The latest code is available at https://xenbits.xen.org/gitweb/?p=people/dwmw2/xen.git;a=shortlog;h=refs/heads/lu-master
  -  Project wiki page at https://wiki.xenproject.org/wiki/Live-Updating_Xen

*  Non-Cooperative Live Migration (v7 (design docs))
  -  Paul Durrant

*  Secret Hiding (v5)
  -  Hongyan Xia

*  Hypervisor file system (v6)
  -  Juergen Gross

=== x86 === 

*  Linux stub domains (v4)
  -  Marek Marczykowski-Górecki

*  Virtualise MSR_ARCH_CAPS for guests
  -  Andrew Cooper

*  AMD hardware mitigations (Rome)
  -  Andrew Cooper

*  Xen ioreq server (v3)
  -  Roger Pau Monne

*  Memory read caching in emulation (v5)
  -  Jan Beulich

*  Instruction emulator improvements
  -  Jan Beulich

*  VM forking (v11)
  -  Tamas K Lengyel

=== ARM === 

== Completed == 


Paul Durrant


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 07:56:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 07:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRtBn-0001LI-Uz; Fri, 24 Apr 2020 07:55:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRtBm-0001LD-BH
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 07:55:58 +0000
X-Inumbo-ID: 07d2f882-8601-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 07d2f882-8601-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 07:55:57 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D2A24AAC7;
 Fri, 24 Apr 2020 07:55:55 +0000 (UTC)
Subject: Re: [ANNOUNCE] Xen 4.14 Development Update
To: pdurrant@amazon.com
References: <20200424073859.89-1-paul@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7809d4e7-bc08-a0d3-b623-8e0478de951d@suse.com>
Date: Fri, 24 Apr 2020 09:55:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200424073859.89-1-paul@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 09:38, Paul Durrant wrote:
> *  Memory read caching in emulation (v5)
>   -  Jan Beulich

Unless issues are found with this, it can be moved to "completed" -
I did commit this yesterday.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 08:00:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 08:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRtFm-0002RU-SU; Fri, 24 Apr 2020 08:00:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mnRG=6I=amazon.co.uk=prvs=376452958=pdurrant@srs-us1.protection.inumbo.net>)
 id 1jRtFl-0002HK-KC
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 08:00:05 +0000
X-Inumbo-ID: 9bafcd6e-8601-11ea-9e09-bc764e2007e4
Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9bafcd6e-8601-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 08:00:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt;
 s=amazon201209; t=1587715205; x=1619251205;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-transfer-encoding:mime-version:subject;
 bh=2ZpEyeazpWKchcn+U0N4QknDfDMEt2hWmGG1HfY2APA=;
 b=c2A93OBtWnLtQZxl7fs921drcBcpx5Emll5uRrqah0Zx5cvyUKyTlJid
 NVQFhbMvSxhnCQe8BHVJ6WiDwP7uMbHAVmzSAGOkUg8YpKiiL6BNjDTEZ
 JoSVfS8avbOTHzYfBU8F59AOyVbfryfzgRcIT383gDY5ZkqVwvG2+qcN9 4=;
IronPort-SDR: lZoAwJ8OU/2qsfaRG7IkGaHTlRXJ336YlHPqCVbVh3+0j2kxOO9UqwaPw1tNlhxUxsXWJet/ty
 H1bTaspdB4lA==
X-IronPort-AV: E=Sophos;i="5.73,310,1583193600"; d="scan'208";a="27429851"
Subject: RE: [ANNOUNCE] Xen 4.14 Development Update
Thread-Topic: [ANNOUNCE] Xen 4.14 Development Update
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO
 email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com) ([10.43.8.2])
 by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP;
 24 Apr 2020 07:59:53 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])
 by email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com (Postfix) with ESMTPS
 id C2AE2A2514; Fri, 24 Apr 2020 07:59:52 +0000 (UTC)
Received: from EX13D32EUC002.ant.amazon.com (10.43.164.94) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 24 Apr 2020 07:59:51 +0000
Received: from EX13D32EUC003.ant.amazon.com (10.43.164.24) by
 EX13D32EUC002.ant.amazon.com (10.43.164.94) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 24 Apr 2020 07:59:50 +0000
Received: from EX13D32EUC003.ant.amazon.com ([10.43.164.24]) by
 EX13D32EUC003.ant.amazon.com ([10.43.164.24]) with mapi id 15.00.1497.006;
 Fri, 24 Apr 2020 07:59:50 +0000
From: "Durrant, Paul" <pdurrant@amazon.co.uk>
To: Jan Beulich <jbeulich@suse.com>
Thread-Index: AQHWGguEBjuxACUXz0mOoCZT0DeYwaiH53MAgAAAkZA=
Date: Fri, 24 Apr 2020 07:59:50 +0000
Message-ID: <4b39d78bcbea431f95d391b7fa8a2163@EX13D32EUC003.ant.amazon.com>
References: <20200424073859.89-1-paul@xen.org>
 <7809d4e7-bc08-a0d3-b623-8e0478de951d@suse.com>
In-Reply-To: <7809d4e7-bc08-a0d3-b623-8e0478de951d@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.165.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBPbiAyNC4wNC4yMDIwIDA5OjM4LCBQYXVs
IER1cnJhbnQgd3JvdGU6DQo+ID4gKiAgTWVtb3J5IHJlYWQgY2FjaGluZyBpbiBlbXVsYXRpb24g
KHY1KQ0KPiA+ICAgLSAgSmFuIEJldWxpY2gNCj4gDQo+IFVubGVzcyBpc3N1ZXMgYXJlIGZvdW5k
IHdpdGggdGhpcywgaXQgY2FuIGJlIG1vdmVkIHRvICJjb21wbGV0ZWQiIC0NCj4gSSBkaWQgY29t
bWl0IHRoaXMgeWVzdGVyZGF5Lg0KPiANCg0KU29tZW9uZSBqdXN0IGRyZXcgbXkgYXR0ZW50aW9u
IHRvIHRoZSBjb21taXQgc28gb25jZSBpdCBoaXRzIG1hc3RlciBpdCBzaG91bGQgaW5kZWVkIGJl
IG1hcmtlZCBhcyBzdWNoLg0KVGhhbmtzLA0KDQogIFBhdWwNCg==


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 08:07:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 08:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRtNE-0002tJ-NF; Fri, 24 Apr 2020 08:07:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRtND-0002tE-7k
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 08:07:47 +0000
X-Inumbo-ID: ae96bb62-8602-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ae96bb62-8602-11ea-83d8-bc764e2007e4;
 Fri, 24 Apr 2020 08:07:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2Xa0bV/lQIrQ1jwTvvg6j0PVnINSLn63b4eWvHcAjDg=; b=Kp4+Hd1d20ntgz8cSTangEQ0i4
 LD04wNXoM9kzBU3sTsidAk/1psdkE4LiYveUchtH2eKir0RJ2jweflzcy1VdQl1ZXoHOyv3l7/pS1
 lqOAU2ZqhaQSj1XaVMJvc5KJ/Cd6FUtuCEvn8rkcOj+Ux0uMjWtiDx9vl2/a/w+WoZ1E=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRtNC-0002MO-45; Fri, 24 Apr 2020 08:07:46 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRtNB-0007rZ-Pt; Fri, 24 Apr 2020 08:07:46 +0000
Message-ID: <7d7155eda49856fa7f471db98b71b6a84e8beea4.camel@xen.org>
Subject: Re: [PATCH 0/6] convert more Xen page table code to the new API
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 24 Apr 2020 09:07:43 +0100
In-Reply-To: <cover.1587116799.git.hongyxia@amazon.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

A gentle ping.

On Fri, 2020-04-17 at 10:52 +0100, Hongyan Xia wrote:
> From: Hongyan Xia <hongyxia@amazon.com>
> 
> Basically just rewriting functions using the new API to map and unmap
> PTEs. Each patch is independent.
> 
> Apart from mapping and unmapping page tables, no other functional
> change
> intended.
> 
> Wei Liu (6):
>   x86_64/mm: map and unmap page tables in cleanup_frame_table
>   x86_64/mm: map and unmap page tables in subarch_init_memory
>   x86_64/mm: map and unmap page tables in subarch_memory_op
>   x86/smpboot: map and unmap page tables in cleanup_cpu_root_pgt
>   x86/pv: map and unmap page tables in mark_pv_pt_pages_rdonly
>   x86/pv: map and unmap page table in dom0_construct_pv
> 
>  xen/arch/x86/pv/dom0_build.c | 38 ++++++++++++++++++++++++--------
> ----
>  xen/arch/x86/smpboot.c       | 25 ++++++++++++++++--------
>  xen/arch/x86/x86_64/mm.c     | 32 +++++++++++++++---------------
>  3 files changed, 58 insertions(+), 37 deletions(-)
> 



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 08:58:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 08:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRu9u-00071Y-SV; Fri, 24 Apr 2020 08:58:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRu9t-00071T-DM
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 08:58:05 +0000
X-Inumbo-ID: b56ef6be-8609-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b56ef6be-8609-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 08:58:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/2MdC1L2ctLyBgf8w95S/LG9XnIkM4mVUCRkMzC5qwk=; b=n2Toi1du1DrCn+60YE5XMS71Kh
 i/Hz3kAK1HDzwEHscetMFyF7SGZ2bwqVcHloQZXRkH7I9h6N8bgmHj7HsdPg5jS13vDj4ghwaeUkY
 9o5uBipzKoSEYMw1QkyHKHzS7NEDTf25FIq2SWQ/KqfYUbgu/DEOTfdSGdkxDrmibQYo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRu9r-0003Lw-1a; Fri, 24 Apr 2020 08:58:03 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRu9q-0003Xq-PV; Fri, 24 Apr 2020 08:58:02 +0000
Subject: Re: [PATCH 1/6] x86_64/mm: map and unmap page tables in
 cleanup_frame_table
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
From: Julien Grall <julien@xen.org>
Message-ID: <cf915cac-49c9-a062-adc7-0a1b8d8a58fa@xen.org>
Date: Fri, 24 Apr 2020 09:58:00 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 17/04/2020 10:52, Hongyan Xia wrote:> diff --git 
a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c> index 
e85ef449f3..18210405f4 100644> --- a/xen/arch/x86/x86_64/mm.c> +++ 
b/xen/arch/x86/x86_64/mm.c> @@ -737,8 +737,8 @@ static void 
cleanup_frame_table(struct mem_hotadd_info *info)>   >       while (sva 
< eva)>       {> -        l3e = 
l4e_to_l3e(idle_pg_table[l4_table_offset(sva)])[> - 
l3_table_offset(sva)];> +        l3e = 
l3e_from_l4e(idle_pg_table[l4_table_offset(sva)],> + 
       l3_table_offset(sva));
This macro doesn't exist yet in the tree. It would be good to spell out 
the dependencies in the cover letter so this doesn't get merged before 
the dependency is merged.

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 08:59:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 08:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuAu-00074r-6P; Fri, 24 Apr 2020 08:59:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuAs-00074k-T7
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 08:59:06 +0000
X-Inumbo-ID: da5a87b8-8609-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id da5a87b8-8609-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 08:59:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=jnhrgM5MR2hFx+THnvICkQmvVBwJN6tCsg0p8G0T5dQ=; b=US+T7U+akTnek+F+//Al4zPTdI
 Ymh38SEvqRiF1VNwjwrz+12KMp2Uvea6MaNGXxE7DJRhsGr9pzUyi+BfBUHih9ns7hBTncssRszDW
 UyBpqLPFm5bJ0re9FHG6RlRwkwvhclJzB6X4yGduCGgLbJPx7rqTdSj+eOOvKxklZ0lE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuAr-0003N0-8P; Fri, 24 Apr 2020 08:59:05 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuAr-0003ar-0x; Fri, 24 Apr 2020 08:59:05 +0000
Subject: Re: [PATCH 1/6] x86_64/mm: map and unmap page tables in
 cleanup_frame_table
From: Julien Grall <julien@xen.org>
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
 <cf915cac-49c9-a062-adc7-0a1b8d8a58fa@xen.org>
Message-ID: <0e6aec87-f9ba-76e1-24fe-93fa4e01cc17@xen.org>
Date: Fri, 24 Apr 2020 09:59:03 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <cf915cac-49c9-a062-adc7-0a1b8d8a58fa@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24/04/2020 09:58, Julien Grall wrote:
> Hi,
> 
> On 17/04/2020 10:52, Hongyan Xia wrote:> diff --git 
> a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c> index 
> e85ef449f3..18210405f4 100644> --- a/xen/arch/x86/x86_64/mm.c> +++ 
> b/xen/arch/x86/x86_64/mm.c> @@ -737,8 +737,8 @@ static void 
> cleanup_frame_table(struct mem_hotadd_info *info)>   >       while (sva 
> < eva)>       {> -        l3e = 
> l4e_to_l3e(idle_pg_table[l4_table_offset(sva)])[> - 
> l3_table_offset(sva)];> +        l3e = 
> l3e_from_l4e(idle_pg_table[l4_table_offset(sva)],> +       
> l3_table_offset(sva));
> This macro doesn't exist yet in the tree. It would be good to spell out 
> the dependencies in the cover letter so this doesn't get merged before 
> the dependency is merged.
> 
> Reviewed-by: Julien Grall <jgrall@amazon.com>

Argh, I screwed the reply. Sorry for that. I will resend it.

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 08:59:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 08:59:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuBR-00078s-Fo; Fri, 24 Apr 2020 08:59:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuBQ-00078h-25
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 08:59:40 +0000
X-Inumbo-ID: ee1868d8-8609-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ee1868d8-8609-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 08:59:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=l9hYPuC1aPcKdkz4teGV0XrjqcxoMQyZm3WpG2h4448=; b=EXEM0Fdo0ejY6vq/SHetM604eu
 9S2GDR/juXFhe8zz3WN3vXRq15YgOOcsJAWLG1BFZMov2gTyNwV8eeS0Rw4EJ4QnyLsLoaxvcR8CQ
 /a7t9EsWt0nsi+d4cinY1t5aRRT5PJnc62SJjSROXk6uOGlR7LeSEmEjcIn71LKI/OIs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuBO-0003Nn-82; Fri, 24 Apr 2020 08:59:38 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuBN-0003cO-WB; Fri, 24 Apr 2020 08:59:38 +0000
Subject: Re: [PATCH 1/6] x86_64/mm: map and unmap page tables in
 cleanup_frame_table
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
From: Julien Grall <julien@xen.org>
Message-ID: <ca9b1554-2c91-35f4-2e6b-b7d4985b638d@xen.org>
Date: Fri, 24 Apr 2020 09:59:36 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

(resending)

On 17/04/2020 10:52, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Also fix a weird indentation.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> ---
>   xen/arch/x86/x86_64/mm.c | 14 +++++++-------
>   1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index e85ef449f3..18210405f4 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -737,8 +737,8 @@ static void cleanup_frame_table(struct mem_hotadd_info *info)
>   
>       while (sva < eva)
>       {
> -        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(sva)])[
> -          l3_table_offset(sva)];
> +        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(sva)],
> +                           l3_table_offset(sva));

This macro doesn't exist yet in the tree. It would be good to spell out 
the dependencies in the cover letter so this doesn't get merged before 
the dependency is merged.

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:02:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:02:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuE9-00080j-UA; Fri, 24 Apr 2020 09:02:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuE8-00080e-TH
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:02:28 +0000
X-Inumbo-ID: 528f9751-860a-11ea-9475-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 528f9751-860a-11ea-9475-12813bfff9fa;
 Fri, 24 Apr 2020 09:02:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=o2UT31ZSgx27RMlDVsTNhqwa3saXLusAAL8Qxf/y3Gk=; b=PH9AvQgQqHRaYzPwGVU+amm8PC
 QUwRfZUmVHQD0vC0C4bQhW9lmjnt2Ea6eTHIFg6wUcGToCWofCZpoND5z+OaTL+7r5r66KzAUdaJA
 djnDH2aubAa5HSavrr1k7fotMqKIzRIaDmvfHGZXAlXz6ZCBr6jlaMdiZ6BOW7elLgwA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuE7-0003Uz-HH; Fri, 24 Apr 2020 09:02:27 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuE7-0003wW-Ba; Fri, 24 Apr 2020 09:02:27 +0000
Subject: Re: [PATCH 1/6] x86_64/mm: map and unmap page tables in
 cleanup_frame_table
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
From: Julien Grall <julien@xen.org>
Message-ID: <a1caa70d-9c7a-b0c2-d7cf-1893db8f0ac4@xen.org>
Date: Fri, 24 Apr 2020 10:02:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 17/04/2020 10:52, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Also fix a weird indentation.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> ---
>   xen/arch/x86/x86_64/mm.c | 14 +++++++-------
>   1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index e85ef449f3..18210405f4 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -737,8 +737,8 @@ static void cleanup_frame_table(struct mem_hotadd_info *info)
>   
>       while (sva < eva)
>       {
> -        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(sva)])[
> -          l3_table_offset(sva)];
> +        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(sva)],
> +                           l3_table_offset(sva));
>           if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) ||
>                (l3e_get_flags(l3e) & _PAGE_PSE) )
>           {
> @@ -747,7 +747,7 @@ static void cleanup_frame_table(struct mem_hotadd_info *info)
>               continue;
>           }
>   
> -        l2e = l3e_to_l2e(l3e)[l2_table_offset(sva)];
> +        l2e = l2e_from_l3e(l3e, l2_table_offset(sva));
>           ASSERT(l2e_get_flags(l2e) & _PAGE_PRESENT);
>   
>           if ( (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) ==
> @@ -763,10 +763,10 @@ static void cleanup_frame_table(struct mem_hotadd_info *info)
>               continue;
>           }
>   
> -        ASSERT(l1e_get_flags(l2e_to_l1e(l2e)[l1_table_offset(sva)]) &
> -                _PAGE_PRESENT);
> -         sva = (sva & ~((1UL << PAGE_SHIFT) - 1)) +
> -                    (1UL << PAGE_SHIFT);
> +        ASSERT(l1e_get_flags(l1e_from_l2e(l2e, l1_table_offset(sva))) &
> +               _PAGE_PRESENT);
> +
> +        sva = (sva & ~((1UL << PAGE_SHIFT) - 1)) + (1UL << PAGE_SHIFT);

NIT: While you are modifying the indentation. Couldn't we use PAGE_MASK 
and PAGE_SIZE here?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:04:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:04:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuG7-00088j-Ai; Fri, 24 Apr 2020 09:04:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuG6-00088e-1o
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:04:30 +0000
X-Inumbo-ID: 9af11258-860a-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9af11258-860a-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 09:04:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=l9pGlAG8km807wCuzDUpg8cHiePGBYS9LUH0IpLN1JU=; b=GEbSPQiQE/TLfPkxwphX+q1yun
 gTphbECpHmNtrxVtC+ooHWGQ02RgnKkg4ND85NZQrYQRpNsiz5uPP1zIAEE0M4ODhxLwWmBwgmByN
 YGiKzaJSGECgZX2Ng2wDwOH7HFix2m12cXRQhc2u9KWXLng5r/Y1EvaCbypq+gkBqFyE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuG3-0003X0-UG; Fri, 24 Apr 2020 09:04:27 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuG3-000450-Nu; Fri, 24 Apr 2020 09:04:27 +0000
Subject: Re: [PATCH 2/6] x86_64/mm: map and unmap page tables in
 subarch_init_memory
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <0e14533f516ee5ce410e2cd8050f085aec4b4961.1587116799.git.hongyxia@amazon.com>
From: Julien Grall <julien@xen.org>
Message-ID: <232de7c3-77bc-1816-150f-082502e8fbff@xen.org>
Date: Fri, 24 Apr 2020 10:04:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <0e14533f516ee5ce410e2cd8050f085aec4b4961.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 17/04/2020 10:52, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:07:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:07:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuIW-0008Fu-Nm; Fri, 24 Apr 2020 09:07:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuIW-0008Fp-4z
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:07:00 +0000
X-Inumbo-ID: f4706db0-860a-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f4706db0-860a-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 09:06:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=GfXAoTKO81O9UCNI35gltwGJGQMJmPE+twwNLoah7us=; b=Cms+xhQ7pzfkBQTBW2cDb3EpzH
 gTW3SW1LePNsY0gtPQYFA+b9t0saSojsZdvoS3rgSD878vjoA5jGezvTQHj0oit/VuXFYyP/vCSI4
 BYnI/26q2BzNLytMVWV6Mm1Ha3XWevrtnC9C70G209lCnPbXJuN22pwZdF7/bwnCX5ZI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuIT-0003au-Sv; Fri, 24 Apr 2020 09:06:57 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuIT-0004Kq-MX; Fri, 24 Apr 2020 09:06:57 +0000
Subject: Re: [PATCH 3/6] x86_64/mm: map and unmap page tables in
 subarch_memory_op
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <1c88c785eb9537983a1692cc379604233ff13025.1587116799.git.hongyxia@amazon.com>
From: Julien Grall <julien@xen.org>
Message-ID: <1fe549b7-2141-c013-61de-f7196e7ba966@xen.org>
Date: Fri, 24 Apr 2020 10:06:55 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1c88c785eb9537983a1692cc379604233ff13025.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Hongyan,

On 17/04/2020 10:52, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:13:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuOx-0000fx-FI; Fri, 24 Apr 2020 09:13:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuOw-0000fs-DB
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:13:38 +0000
X-Inumbo-ID: e1a8f98a-860b-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e1a8f98a-860b-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 09:13:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/yQWa354o6CUZt+4eJYJWVc+dtItT1EC2mqjXKJ37uY=; b=R6i7R60/7eaBegofFdbFaJCAkJ
 jSesuaU8M1l2CGnTZv8+o6vBqemNJjsDv1jC++5OHPxvNRai53pt7vQ7y6RocLv9KuiglRnwITnDF
 ik3nPmEUkY4HFMMmbH0fWR8ExDijroe4L2niKVOEEUpB5yjV/xcNMCzVypB38ElB3sOg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuOu-0003il-4J; Fri, 24 Apr 2020 09:13:36 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuOt-00050e-TW; Fri, 24 Apr 2020 09:13:36 +0000
Subject: Re: [PATCH 4/6] x86/smpboot: map and unmap page tables in
 cleanup_cpu_root_pgt
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <bc0ad02ad73ac3f02e063457d69634b1f6b57ddc.1587116799.git.hongyxia@amazon.com>
From: Julien Grall <julien@xen.org>
Message-ID: <afec3c99-49e8-0304-23ef-1763df48fc9c@xen.org>
Date: Fri, 24 Apr 2020 10:13:33 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <bc0ad02ad73ac3f02e063457d69634b1f6b57ddc.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 17/04/2020 10:52, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

Reviewed-by: Julien Grall <jgrall@amazon.com>

> ---
>   xen/arch/x86/smpboot.c | 25 +++++++++++++++++--------
>   1 file changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 09264b02d1..275ce7661d 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -858,23 +858,27 @@ static void cleanup_cpu_root_pgt(unsigned int cpu)
>             r < root_table_offset(HYPERVISOR_VIRT_END); ++r )
>       {
>           l3_pgentry_t *l3t;
> +        mfn_t l3mfn;
>           unsigned int i3;
>   
>           if ( !(root_get_flags(rpt[r]) & _PAGE_PRESENT) )
>               continue;
>   
> -        l3t = l4e_to_l3e(rpt[r]);
> +        l3mfn = l4e_get_mfn(rpt[r]);
> +        l3t = map_domain_page(l3mfn);
>   
>           for ( i3 = 0; i3 < L3_PAGETABLE_ENTRIES; ++i3 )
>           {
>               l2_pgentry_t *l2t;
> +            mfn_t l2mfn;
>               unsigned int i2;
>   
>               if ( !(l3e_get_flags(l3t[i3]) & _PAGE_PRESENT) )
>                   continue;
>   
>               ASSERT(!(l3e_get_flags(l3t[i3]) & _PAGE_PSE));
> -            l2t = l3e_to_l2e(l3t[i3]);
> +            l2mfn = l3e_get_mfn(l3t[i3]);
> +            l2t = map_domain_page(l2mfn);
>   
>               for ( i2 = 0; i2 < L2_PAGETABLE_ENTRIES; ++i2 )
>               {
> @@ -882,13 +886,15 @@ static void cleanup_cpu_root_pgt(unsigned int cpu)
>                       continue;
>   
>                   ASSERT(!(l2e_get_flags(l2t[i2]) & _PAGE_PSE));
> -                free_xen_pagetable(l2e_to_l1e(l2t[i2]));
> +                free_xen_pagetable_new(l2e_get_mfn(l2t[i2]));
>               }
>   
> -            free_xen_pagetable(l2t);
> +            unmap_domain_page(l2t);
> +            free_xen_pagetable_new(l2mfn);
>           }
>   
> -        free_xen_pagetable(l3t);
> +        unmap_domain_page(l3t);
> +        free_xen_pagetable_new(l3mfn);
>       }
>   
>       free_xen_pagetable(rpt);
> @@ -896,11 +902,14 @@ static void cleanup_cpu_root_pgt(unsigned int cpu)
>       /* Also zap the stub mapping for this CPU. */
>       if ( stub_linear )
>       {
> -        l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
> -        l2_pgentry_t *l2t = l3e_to_l2e(l3t[l3_table_offset(stub_linear)]);
> -        l1_pgentry_t *l1t = l2e_to_l1e(l2t[l2_table_offset(stub_linear)]);
> +        l3_pgentry_t l3e = l3e_from_l4e(common_pgt,
> +                                        l3_table_offset(stub_linear));
> +        l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(stub_linear));
> +        l1_pgentry_t *l1t = map_l1t_from_l2e(l2e);
>   
>           l1t[l1_table_offset(stub_linear)] = l1e_empty();
> +
> +        unmap_domain_page(l1t);
>       }
>   }
>   
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:16:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:16:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuRn-0000nS-Tg; Fri, 24 Apr 2020 09:16:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuRm-0000nM-DY
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:16:34 +0000
X-Inumbo-ID: 4a5d11ab-860c-11ea-9475-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4a5d11ab-860c-11ea-9475-12813bfff9fa;
 Fri, 24 Apr 2020 09:16:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=l9pGlAG8km807wCuzDUpg8cHiePGBYS9LUH0IpLN1JU=; b=K1VN9glhAtDp0ReGFY9eouABqN
 NhuKTfYiOG2aJBFpFmlHVOmh0R5QT1nVx41uWMKbi93M0IyfoUh1f3ooaYlyBqlZ4he3C4X3xw94B
 6L3QUC2+dBGiw/Eg/9PAnWlt/7DWWgoQYVkniWaYQUsBq28p2/YuW1kHbULj7dr9hPhs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuRk-0003mB-7W; Fri, 24 Apr 2020 09:16:32 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuRk-0005Ah-0W; Fri, 24 Apr 2020 09:16:32 +0000
Subject: Re: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
From: Julien Grall <julien@xen.org>
Message-ID: <8ec34199-1f02-ad59-ec20-38e5d927b59a@xen.org>
Date: Fri, 24 Apr 2020 10:16:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 17/04/2020 10:52, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:18:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuTG-0000vV-Cc; Fri, 24 Apr 2020 09:18:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuTE-0000vQ-PO
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:18:04 +0000
X-Inumbo-ID: 808aae2c-860c-11ea-9475-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 808aae2c-860c-11ea-9475-12813bfff9fa;
 Fri, 24 Apr 2020 09:18:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=l9pGlAG8km807wCuzDUpg8cHiePGBYS9LUH0IpLN1JU=; b=JJW6mZYdbm3/lNsPpMCbnb1/UT
 vl+QJpRY2JpTonRjOJJekrUXnv3rYRDDZWFou0QbDcAkWcMpepGTdVm2nstNnDnILIS2+6NlbYJS/
 6tAc7y1V+tr+FJI39bbd34stDiWCgJvcAl3KU9DIHP1Bvb+5a9z6ZIy2OFxnk7M6eDbU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuTC-0003oz-UD; Fri, 24 Apr 2020 09:18:02 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuTC-0005GG-Ny; Fri, 24 Apr 2020 09:18:02 +0000
Subject: Re: [PATCH 6/6] x86/pv: map and unmap page table in dom0_construct_pv
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <18fda6bdeb4f20bf2272503e45c7c420e51673ac.1587116799.git.hongyxia@amazon.com>
From: Julien Grall <julien@xen.org>
Message-ID: <140cc03d-08ab-6a45-e56d-0b68e71eebd2@xen.org>
Date: Fri, 24 Apr 2020 10:18:00 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <18fda6bdeb4f20bf2272503e45c7c420e51673ac.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 17/04/2020 10:52, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:20:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuVV-0001ga-PB; Fri, 24 Apr 2020 09:20:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuVU-0001gV-Kc
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:20:24 +0000
X-Inumbo-ID: d3f68e64-860c-11ea-9476-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d3f68e64-860c-11ea-9476-12813bfff9fa;
 Fri, 24 Apr 2020 09:20:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=e+Vx3UfGuzVec4LjAQrU71RjeWzo1J/YLdYmSfGODJg=; b=LSqW0fXFixFv+IbFcJpr6ogOUs
 +Im/zgO0ofvAbOcC5SOL3WBCQ5oykQyAGB+DdHOPY/b/cuiej27gEkb+mN3KM4rlF2l88sw3ZKzAW
 RFSnN9ii8KlOGmvJ2hCUnhY2LMqOHKja0bnGzp6v6xGKpzv2V3XMX4eznFdlRxpeVXZ0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuVQ-0003s0-EX; Fri, 24 Apr 2020 09:20:20 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuVQ-0005Oi-4p; Fri, 24 Apr 2020 09:20:20 +0000
Subject: Re: [XEN PATCH v5 03/16] xen/build: use new $(c_flags) and $(a_flags)
 instead of $(CFLAGS)
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-4-anthony.perard@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <91b44d25-a10e-fdd2-2fbc-84f5ae3e5a36@xen.org>
Date: Fri, 24 Apr 2020 10:20:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-4-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Tim Deegan <tim@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 21/04/2020 17:11, Anthony PERARD wrote:
> In a later patch ("xen/build: have the root Makefile generates the
> CFLAGS), we want to generate the CFLAGS in xen/Makefile, then export
> it and have Rules.mk use a CFLAGS from the environment variables. That
> changes the flavor of the CFLAGS and flags intended for one target
> (like -D__OBJECT_FILE__ and -M%) gets propagated and duplicated. So we
> start by moving such flags out of $(CFLAGS) and into $(c_flags) which
> is to be modified by only Rules.mk.
> 
> __OBJECT_FILE__ is only used by arch/x86/mm/*.c files, so having it in
> $(c_flags) is enough, we don't need it in $(a_flags).
> 
> For include/Makefile and as-insn we can keep using CFLAGS, but since
> it doesn't have -M* flags anymore there is no need to filter them out.
> 
> The XEN_BUILD_EFI tests in arch/x86/Makefile was filtering out
> CFLAGS-y, but according to dd40177c1bc8 ("x86-64/EFI: add CFLAGS to
> check compile"), it was done to filter out -MF. CFLAGS doesn't
> have those flags anymore, so no filtering is needed.
> 
> This is inspired by the way Kbuild generates CFLAGS for each targets.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

For the Arm bits:

Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:22:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuX5-0001mK-46; Fri, 24 Apr 2020 09:22:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRuX4-0001mE-Gk
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:22:02 +0000
X-Inumbo-ID: 0e4a04e2-860d-11ea-9476-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0e4a04e2-860d-11ea-9476-12813bfff9fa;
 Fri, 24 Apr 2020 09:22:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=6LoKLiurglRXcB09V3LQifdnPvFZ0Y08tYsoZQRr1ow=; b=Y5GSGtK4WBubrOdODyO8a9v2KN
 M1Zwz1vbYi0guIaoFttUn1KqEiAd4BxHLp+G8Ij1NXXJPO+jqk0BLRZK/oVZm2GQ1kCGNmeQj3RQ+
 DiROrXuIxpMllIX3IEPPVZ30m7PomT6FgPCn8rIoES4b5vouQ26F6rGVaEWWotrH3sjI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRuX3-0003uk-TO; Fri, 24 Apr 2020 09:22:01 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRuX3-0005Tb-JE; Fri, 24 Apr 2020 09:22:01 +0000
Message-ID: <ba87751e66decae06118bbdf607a89d1406cb3e8.camel@xen.org>
Subject: Re: [PATCH 1/6] x86_64/mm: map and unmap page tables in
 cleanup_frame_table
From: Hongyan Xia <hx242@xen.org>
To: Julien Grall <julien@xen.org>, xen-devel@lists.xenproject.org
Date: Fri, 24 Apr 2020 10:21:59 +0100
In-Reply-To: <ca9b1554-2c91-35f4-2e6b-b7d4985b638d@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
 <ca9b1554-2c91-35f4-2e6b-b7d4985b638d@xen.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Julien,

On Fri, 2020-04-24 at 09:59 +0100, Julien Grall wrote:
> (resending)
> 
> On 17/04/2020 10:52, Hongyan Xia wrote:
> > From: Wei Liu <wei.liu2@citrix.com>
> > 
> > Also fix a weird indentation.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> > ---
> >   xen/arch/x86/x86_64/mm.c | 14 +++++++-------
> >   1 file changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> > index e85ef449f3..18210405f4 100644
> > --- a/xen/arch/x86/x86_64/mm.c
> > +++ b/xen/arch/x86/x86_64/mm.c
> > @@ -737,8 +737,8 @@ static void cleanup_frame_table(struct
> > mem_hotadd_info *info)
> >   
> >       while (sva < eva)
> >       {
> > -        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(sva)])[
> > -          l3_table_offset(sva)];
> > +        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(sva)],
> > +                           l3_table_offset(sva));
> 
> This macro doesn't exist yet in the tree. It would be good to spell
> out 
> the dependencies in the cover letter so this doesn't get merged
> before 
> the dependency is merged.

I believe the introduction of the new macros has been merged in staging
as 6c8afe5aadb33761431b24157d99b25eac15fc7e.

> Reviewed-by: Julien Grall <jgrall@amazon.com>

Thanks!

Hongyan



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:24:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRuZJ-0001vq-Hg; Fri, 24 Apr 2020 09:24:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRuZI-0001vl-Lw
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:24:20 +0000
X-Inumbo-ID: 60b577b6-860d-11ea-9476-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 60b577b6-860d-11ea-9476-12813bfff9fa;
 Fri, 24 Apr 2020 09:24:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=aELI3T4+eyPa04SscQFdvZE4ERWkEpOzSg/1Dlw1IRU=; b=aFXxyqH46g7t3yBlUi26zzVteR
 JXqSSfpIdhx61RR8/GFvM0ADyOyFNT8QwU0EetFZ0SBrrlNuV074YZZdAWFMMH5bt0QWyUFFRA4Rj
 88wswVKccLapBZ22rBCdNpRU9SS7ICbk2SazCZWoOsoB9QoDAVID+UPNNlS4Fx+/ybJc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRuZH-0003xp-0D; Fri, 24 Apr 2020 09:24:19 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRuZG-0005mH-OW; Fri, 24 Apr 2020 09:24:18 +0000
Subject: Re: [PATCH 1/6] x86_64/mm: map and unmap page tables in
 cleanup_frame_table
To: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org
References: <cover.1587116799.git.hongyxia@amazon.com>
 <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
 <ca9b1554-2c91-35f4-2e6b-b7d4985b638d@xen.org>
 <ba87751e66decae06118bbdf607a89d1406cb3e8.camel@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <476c7ba8-ab35-18e9-07e4-1913c540e132@xen.org>
Date: Fri, 24 Apr 2020 10:24:16 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <ba87751e66decae06118bbdf607a89d1406cb3e8.camel@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 24/04/2020 10:21, Hongyan Xia wrote:
> Hi Julien,
> 
> On Fri, 2020-04-24 at 09:59 +0100, Julien Grall wrote:
>> (resending)
>>
>> On 17/04/2020 10:52, Hongyan Xia wrote:
>>> From: Wei Liu <wei.liu2@citrix.com>
>>>
>>> Also fix a weird indentation.
>>>
>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
>>> ---
>>>    xen/arch/x86/x86_64/mm.c | 14 +++++++-------
>>>    1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
>>> index e85ef449f3..18210405f4 100644
>>> --- a/xen/arch/x86/x86_64/mm.c
>>> +++ b/xen/arch/x86/x86_64/mm.c
>>> @@ -737,8 +737,8 @@ static void cleanup_frame_table(struct
>>> mem_hotadd_info *info)
>>>    
>>>        while (sva < eva)
>>>        {
>>> -        l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(sva)])[
>>> -          l3_table_offset(sva)];
>>> +        l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(sva)],
>>> +                           l3_table_offset(sva));
>>
>> This macro doesn't exist yet in the tree. It would be good to spell
>> out
>> the dependencies in the cover letter so this doesn't get merged
>> before
>> the dependency is merged.
> 
> I believe the introduction of the new macros has been merged in staging
> as 6c8afe5aadb33761431b24157d99b25eac15fc7e.

Hmmmm you are right. I must have been blind. Sorry for the noise.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:26:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRubP-00022X-Ur; Fri, 24 Apr 2020 09:26:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRubO-00022R-VM
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:26:31 +0000
X-Inumbo-ID: ae5c684e-860d-11ea-9476-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ae5c684e-860d-11ea-9476-12813bfff9fa;
 Fri, 24 Apr 2020 09:26:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=jYF4jrB5yc31dvvRi6BttyFkYLC3kd07J3WU001+9Gg=; b=yqM8Y5INSTy8Hz923wwdF6HeP+
 f4bpIRMF3bK08ibe4K1RkmT+U4bJVws3duU8MsMBcAgP+G01kA/6qReeGxNgaLoEi3KO5ZfKO5Y8m
 YWz1FVr79sSTDZTzp7c1ddnrHe7eUoF0eT/Jhn4pD5DsQPbFMs/F0ix8ZGBVBBoZAYE0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRubK-000405-9r; Fri, 24 Apr 2020 09:26:26 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRubK-0005t1-17; Fri, 24 Apr 2020 09:26:26 +0000
Subject: Re: [XEN PATCH v5 04/16] xen/build: have the root Makefile generates
 the CFLAGS
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-5-anthony.perard@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <01254b5c-7383-1b3c-53ce-8683e61549c1@xen.org>
Date: Fri, 24 Apr 2020 10:26:23 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-5-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Anthony,

On 21/04/2020 17:11, Anthony PERARD wrote:
> Instead of generating the CFLAGS in Rules.mk everytime we enter a new
> subdirectory, we are going to generate most of them a single time, and
> export the result in the environment so that Rules.mk can use it.  The
> only flags left to be generated are the ones that depend on the
> targets, but the variable $(c_flags) takes care of that.
> 
> Arch specific CFLAGS are generated by a new file "arch/*/arch.mk"
> which is included by the root Makefile.
> 
> We export the *FLAGS via the environment variables XEN_*FLAGS because
> Rules.mk still includes Config.mk and would add duplicated flags to
> CFLAGS.
> 
> When running Rules.mk in the root directory (xen/), the variable
> `root-make-done' is set, so `need-config' will remain undef and so the
> root Makefile will not generate the cflags again.
> 
> We can't use CFLAGS in subdirectories to add flags to particular
> targets, instead start to use CFLAGS-y. Idem for AFLAGS.
> So there are two different CFLAGS-y, the one in xen/Makefile (and
> arch.mk), and the one in subdirs that Rules.mk is going to use.
> We can't add to XEN_CFLAGS because it is exported, so making change to
> it might be propagated to subdirectory which isn't intended.
> 
> Some style change are introduced in this patch:
>      when LDFLAGS_DIRECT is included in LDFLAGS
>      use of CFLAGS-$(CONFIG_INDIRECT_THUNK) instead of ifeq().
> 
> The LTO change hasn't been tested properly, as LTO is marked as
> broken.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

For the Arm bits:

Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:28:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:28:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRudE-0002BJ-BY; Fri, 24 Apr 2020 09:28:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRudD-0002BE-0v
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:28:23 +0000
X-Inumbo-ID: f11942e2-860d-11ea-9476-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f11942e2-860d-11ea-9476-12813bfff9fa;
 Fri, 24 Apr 2020 09:28:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=AHYVIHhVlAkflAFAsRfBbteTI7tbMMuMALWu9YVmlV8=; b=pusYgODybTlp/jvi1FUiqNbmbc
 GW4qoNdK/H+LV/8lTRmXZWKLTm2scGJipXaQGa1JW9+nQS3ddqmQ44iOBTa3yJIzhAsKy0SM00Hgh
 92hJ8a3JrSCDp9rpCdLXjIr+IviJY7lENDIOFiCipZG1TLPCE5z5Y96A1fEONIQ3puKk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRud7-00043m-95; Fri, 24 Apr 2020 09:28:17 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRud6-00060d-Rg; Fri, 24 Apr 2020 09:28:17 +0000
Subject: Re: [XEN PATCH v5 07/16] xen/build: Start using if_changed
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-8-anthony.perard@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <6ae6ab56-c93b-a26a-8d1c-bc79307d7e79@xen.org>
Date: Fri, 24 Apr 2020 10:28:14 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-8-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 21/04/2020 17:11, Anthony PERARD wrote:
> This patch start to use if_changed introduced in a previous commit.
> 
> Whenever if_changed is called, the target must have FORCE as
> dependency so that if_changed can check if the command line to be
> run has changed, so the macro $(real-prereqs) must be used to
> discover the dependencies without "FORCE".
> 
> Whenever a target isn't in obj-y, it should be added to extra-y so the
> .*.cmd dependency file associated with the target can be loaded. This
> is done for xsm/flask/ and both common/lib{elf,fdt}/ and
> arch/x86/Makefile.
> 
> For the targets that generate .*.d dependency files, there's going to
> be two dependency files (.*.d and .*.cmd) until we can merge them
> together in a later patch via fixdep from Linux.
> 
> One cleanup, libelf-relocate.o doesn't exist anymore.
> 
> We import cmd_ld and cmd_objcopy from Linux v5.4.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

For the Arm bits:

Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

> ---
> 
> Notes:
>      v4:
>      - typos
>      - fix missing FORCE in libfdt/Makefile
>      - typo flask vs flash in xsm
>      - in xsm, use *_H_DEPEND in command lines of mkaccess and mkflask
>        instead of $(real-prereq) to avoid including the script as argument of
>        itself.
> 
>   xen/Rules.mk               | 68 +++++++++++++++++++++++++++-----------
>   xen/arch/arm/Makefile      |  4 +--
>   xen/arch/x86/Makefile      |  1 +
>   xen/arch/x86/efi/Makefile  |  7 ++--
>   xen/common/libelf/Makefile | 12 ++++---
>   xen/common/libfdt/Makefile | 11 +++---
>   xen/xsm/flask/Makefile     | 17 +++++++---
>   7 files changed, 85 insertions(+), 35 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 21cac7f5f51a..2e28c572305a 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -56,6 +56,18 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
>   
>   include Makefile
>   
> +# Linking
> +# ---------------------------------------------------------------------------
> +
> +quiet_cmd_ld = LD      $@
> +cmd_ld = $(LD) $(XEN_LDFLAGS) -r -o $@ $(real-prereqs)
> +
> +# Objcopy
> +# ---------------------------------------------------------------------------
> +
> +quiet_cmd_objcopy = OBJCOPY $@
> +cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $< $@
> +
>   define gendep
>       ifneq ($(1),$(subst /,:,$(1)))
>           DEPS += $(dir $(1)).$(notdir $(1)).d
> @@ -164,29 +176,47 @@ else
>   	$(CC) $(c_flags) -c $< -o $@
>   endif
>   
> -%.o: %.S Makefile
> -	$(CC) $(a_flags) -c $< -o $@
> +quiet_cmd_cc_o_S = CC      $@
> +cmd_cc_o_S = $(CC) $(a_flags) -c $< -o $@
> +
> +%.o: %.S FORCE
> +	$(call if_changed,cc_o_S)
> +
> +
> +quiet_cmd_obj_init_o = INIT_O  $@
> +define cmd_obj_init_o
> +    $(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name sz rest; do \
> +        case "$$name" in \
> +        .*.local) ;; \
> +        .text|.text.*|.data|.data.*|.bss) \
> +            test $$sz != 0 || continue; \
> +            echo "Error: size of $<:$$name is 0x$$sz" >&2; \
> +            exit $$(expr $$idx + 1);; \
> +        esac; \
> +    done; \
> +    $(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
> +endef
> +
> +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o FORCE
> +	$(call if_changed,obj_init_o)
> +
> +quiet_cmd_cpp_i_c = CPP     $@
> +cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
> +
> +quiet_cmd_cc_s_c = CC      $@
> +cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
>   
> -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
> -	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name sz rest; do \
> -		case "$$name" in \
> -		.*.local) ;; \
> -		.text|.text.*|.data|.data.*|.bss) \
> -			test $$sz != 0 || continue; \
> -			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
> -			exit $$(expr $$idx + 1);; \
> -		esac; \
> -	done
> -	$(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
> +quiet_cmd_s_S = CPP     $@
> +cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
>   
> -%.i: %.c Makefile
> -	$(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
> +%.i: %.c FORCE
> +	$(call if_changed,cpp_i_c)
>   
> -%.s: %.c Makefile
> -	$(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
> +%.s: %.c FORCE
> +	$(call if_changed,cc_s_c)
>   
> -%.s: %.S Makefile
> -	$(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
> +%.s: %.S FORCE
> +	$(call if_changed,cpp_s_S)
>   
>   # Add intermediate targets:
>   # When building objects with specific suffix patterns, add intermediate
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 9f1ab2335756..b79ad55646bd 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -97,8 +97,8 @@ prelink_lto.o: $(ALL_OBJS)
>   prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
>   	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
>   else
> -prelink.o: $(ALL_OBJS)
> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
> +prelink.o: $(ALL_OBJS) FORCE
> +	$(call if_changed,ld)
>   endif
>   
>   $(TARGET)-syms: prelink.o xen.lds
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index a805e9982e85..44137d919b66 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -71,6 +71,7 @@ obj-$(CONFIG_TBOOT) += tboot.o
>   obj-y += hpet.o
>   obj-y += vm_event.o
>   obj-y += xstate.o
> +extra-y += asm-macros.i
>   
>   x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
>   
> diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
> index 490d791aae2d..3e4c395b7535 100644
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -1,7 +1,10 @@
>   CFLAGS-y += -fshort-wchar
>   
> -%.o: %.ihex
> -	$(OBJCOPY) -I ihex -O binary $< $@
> +quiet_cmd_objcopy_o_ihex = OBJCOPY $@
> +cmd_objcopy_o_ihex = $(OBJCOPY) -I ihex -O binary $< $@
> +
> +%.o: %.ihex FORCE
> +	$(call if_changed,objcopy_o_ihex)
>   
>   boot.init.o: buildid.o
>   
> diff --git a/xen/common/libelf/Makefile b/xen/common/libelf/Makefile
> index 464c448d9d37..a92326c982e9 100644
> --- a/xen/common/libelf/Makefile
> +++ b/xen/common/libelf/Makefile
> @@ -1,12 +1,16 @@
>   obj-bin-y := libelf.o
>   nocov-y += libelf.o
> +libelf-objs := libelf-tools.o libelf-loader.o libelf-dominfo.o
>   
>   SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
> +OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
>   
>   CFLAGS-y += -Wno-pointer-sign
>   
> -libelf.o: libelf-temp.o Makefile
> -	$(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
> +libelf.o: libelf-temp.o FORCE
> +	$(call if_changed,objcopy)
>   
> -libelf-temp.o: libelf-tools.o libelf-loader.o libelf-dominfo.o #libelf-relocate.o
> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
> +libelf-temp.o: $(libelf-objs) FORCE
> +	$(call if_changed,ld)
> +
> +extra-y += libelf-temp.o $(libelf-objs)
> diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> index e2a5e59380a0..6bd207cf8ffa 100644
> --- a/xen/common/libfdt/Makefile
> +++ b/xen/common/libfdt/Makefile
> @@ -1,14 +1,17 @@
>   include Makefile.libfdt
>   
>   SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
> +OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
>   
>   obj-y += libfdt.o
>   nocov-y += libfdt.o
>   
>   CFLAGS-y += -I$(BASEDIR)/include/xen/libfdt/
>   
> -libfdt.o: libfdt-temp.o Makefile
> -	$(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
> +libfdt.o: libfdt-temp.o FORCE
> +	$(call if_changed,objcopy)
>   
> -libfdt-temp.o: $(LIBFDT_OBJS)
> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $^
> +libfdt-temp.o: $(LIBFDT_OBJS) FORCE
> +	$(call if_changed,ld)
> +
> +extra-y += libfdt-temp.o $(LIBFDT_OBJS)
> diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
> index 6db396347b1f..eebfceecc5fb 100644
> --- a/xen/xsm/flask/Makefile
> +++ b/xen/xsm/flask/Makefile
> @@ -20,12 +20,21 @@ AV_H_FILES = include/av_perm_to_string.h include/av_permissions.h
>   ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
>   
>   $(obj-y) ss/built_in.o: $(ALL_H_FILES)
> +extra-y += $(ALL_H_FILES)
>   
> -$(subst include/,%/,$(FLASK_H_FILES)): $(FLASK_H_DEPEND)
> -	$(CONFIG_SHELL) policy/mkflask.sh $(AWK) include $(FLASK_H_DEPEND)
> +mkflask := policy/mkflask.sh
> +quiet_cmd_mkflask = MKFLASK $@
> +cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND)
>   
> -$(subst include/,%/,$(AV_H_FILES)): $(AV_H_DEPEND)
> -	$(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
> +$(subst include/,%/,$(FLASK_H_FILES)): $(FLASK_H_DEPEND) $(mkflask) FORCE
> +	$(call if_changed,mkflask)
> +
> +mkaccess := policy/mkaccess_vector.sh
> +quiet_cmd_mkaccess = MKACCESS VECTOR $@
> +cmd_mkaccess = $(CONFIG_SHELL) $(mkaccess) $(AWK) $(AV_H_DEPEND)
> +
> +$(subst include/,%/,$(AV_H_FILES)): $(AV_H_DEPEND) $(mkaccess) FORCE
> +	$(call if_changed,mkaccess)
>   
>   obj-bin-$(CONFIG_XSM_FLASK_POLICY) += flask-policy.o
>   flask-policy.o: policy.bin
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:29:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:29:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRueP-0002HO-QX; Fri, 24 Apr 2020 09:29:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRueP-0002HJ-E2
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:29:37 +0000
X-Inumbo-ID: 1d834a8a-860e-11ea-9476-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1d834a8a-860e-11ea-9476-12813bfff9fa;
 Fri, 24 Apr 2020 09:29:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=uYIYVyMpz7VE/0wf/jfBuIvSFVFnXx5caLjyxt1mOnk=; b=oTZQS5SpCfTc02yc8/Qp224uHr
 y8Bh9oB2QEZKI1bv6v06BJKK+1LhC2srZ7ZpGrnrt3b3PCBuVdTMX+7Qq6w0Kyo3PowFyyavYuplA
 /OoPcnwrWiXqEt5dvIVoy8uELxBvVNiC55Spr0+C0l0C+AKoQRu9fVEgioUiLQhkH0fY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRueM-00044y-Gc; Fri, 24 Apr 2020 09:29:34 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRueM-00065L-9J; Fri, 24 Apr 2020 09:29:34 +0000
Subject: Re: [XEN PATCH v5 11/16] xen/build: factorise generation of the
 linker scripts
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-12-anthony.perard@citrix.com>
From: Julien Grall <julien@xen.org>
Message-ID: <0410adc3-f694-1acd-2f75-d53507617bb9@xen.org>
Date: Fri, 24 Apr 2020 10:29:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-12-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 21/04/2020 17:12, Anthony PERARD wrote:
> In Arm and X86 makefile, generating the linker script is the same, so
> we can simply have both call the same macro.
> 
> We need to add *.lds files into extra-y so that Rules.mk can find the
> .*.cmd dependency file and load it.
> 
> Change made to the command line:
> - Use of $(CPP) instead of $(CC) -E
> - Remove -Ui386.
>    We don't compile Xen for i386 anymore, so that macro is never
>    defined. Also it doesn't make sense on Arm.
> - Use $(cpp_flags) which simply filter -Wa,% options from $(a_flags).
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

For the Arm bits:

Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:44:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:44:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRusK-0003tg-W4; Fri, 24 Apr 2020 09:44:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=G6AF=6I=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRusK-0003tb-HZ
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:44:00 +0000
X-Inumbo-ID: 1f70ec56-8610-11ea-83d8-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1f70ec56-8610-11ea-83d8-bc764e2007e4;
 Fri, 24 Apr 2020 09:43:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587721439;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=VXZGjgryJrae1JtfoT5Q7za4OT21LbeIlL/lR6RuX4E=;
 b=WJ4RVZKMpDeVUjPeSJyCl9DJLe9sSWYDiwf4h1ACU9IXpWu1fx1I7ORF
 hyFoO50ytvl27uw4bcCnTVeiEk0cLuGTSDHsUop3ALMQkG+N/khce13vK
 jz8LqoR+NK8r5nrVaZYWsXuJ139d+vtpFxlUboSRQU4YbJpfgaoZcbIuK A=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: aboi8SqV/+Uz1ny+2+ge0Er2dV8Wg5JARXJRRkOaquDZxwW6VBNBbIxTlMtLIPHSm8XHam5CuJ
 0X2Vt7VNdfa9F6jsvIALllQJP/xDUQW/m8+LyNRgdB9BSo8WRlBojuRgqTdb/F1TG0o6pncAgR
 +uqplfdfUvl+0QhnOJxpQuan+YKqgAbQMqCpe8nKoDDg9YVaC9IRnnNb/BVJ5eHx++iwWEvzaE
 pj5oloat/HZ7sspWK+dPYnipI8Wv30YqzQPAARLzQH+BOfh498AoslfEEqjAFfwrRowBDYO4st
 2pk=
X-SBRS: 2.7
X-MesageID: 16591118
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,311,1583211600"; d="scan'208";a="16591118"
Date: Fri, 24 Apr 2020 11:43:43 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Subject: Re: [PATCH v17 1/2] mem_sharing: fix sharability check during fork
 reset
Message-ID: <20200424094343.GH28601@Air-de-Roger>
References: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> When resetting a VM fork we ought to only remove pages that were allocated for
> the fork during it's execution and the contents copied over from the parent.
> This can be determined if the page is sharable as special pages used by the
> fork for other purposes will not pass this test. Unfortunately during the fork
> reset loop we only partially check whether that's the case. A page's type may
> indicate it is sharable (pass p2m_is_sharable) but that's not a sufficient
> check by itself. All checks that are normally performed before a page is
> converted to the sharable type need to be performed to avoid removing pages
> from the p2m that may be used for other purposes. For example, currently the
> reset loop also removes the vcpu info pages from the p2m, potentially putting
> the guest into infinite page-fault loops.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

I've been looking however and I'm not able to spot where you copy the
shared_info data, which I think it's also quite critical for the
domain, as it contains the info about event channels (when using L2).
Also for HVM forks the shared info should be mapped at the same gfn as
the parent, or else the child trying to access it will trigger an EPT
fault that won't be able to populate such gfn, because the shared_info
on the parent is already shared between Xen and the parent.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:45:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:45:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRutc-0003zP-Ag; Fri, 24 Apr 2020 09:45:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Spwv=6I=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jRutb-0003yt-Gm
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:45:19 +0000
X-Inumbo-ID: 4e70c274-8610-11ea-83d8-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4e70c274-8610-11ea-83d8-bc764e2007e4;
 Fri, 24 Apr 2020 09:45:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587721518;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=KC5N4t//BrdK/758khQBSQJypG6DLuN1uSuV+khPOdc=;
 b=S4RYbQXc32HuvLSOgvwdDiR4JaItvbC3uQlP/KxSbAU1A65nfkcZwGs+
 BHtx0vcNFG996+NWvJqno872whq1vqnQYQi313p0y34v+MMAdP4pWO1cA
 z45XfdwiNpyuHkyIaYt+ckMzE7O/DY2n3YPWTmPJqJYv1/ZFNk29QXXaW o=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: mln7FoVIliGeoGGILwNpKJ3MJzUgf1yttBJTr+I84JeHIDh7siYUXG4R9ialsfuXg8DSWfIfkO
 VlAQrjBQ0PSI8Ho++UZ2BP91MtYFWiRdqlBxH+RdO3pC5ZHdIfEYMI/ZSPOzmcaYHe7vwiwPZv
 XM2clDPPgmx+l1k9D+G00aZcmGfPwq72JA3oLZHKVsHSnCd1esjwqskvG0Z5xAZCDh1d48teSC
 AYqs85aJkFUpyqRKKzNplts+2mgLq6gaAau+CHF09XZmRLYI0TGA2K1KTVKBbEZSj4MnXAVbZK
 rmI=
X-SBRS: 2.7
X-MesageID: 16874873
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,311,1583211600"; d="scan'208";a="16874873"
Date: Fri, 24 Apr 2020 10:45:05 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v5 04/16] xen/build: have the root Makefile generates
 the CFLAGS
Message-ID: <20200424094505.GS4088@perard.uk.xensource.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-5-anthony.perard@citrix.com>
 <28aeea6d-cd52-d8bf-f114-96ec435363c6@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <28aeea6d-cd52-d8bf-f114-96ec435363c6@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 06:40:33PM +0200, Jan Beulich wrote:
> On 21.04.2020 18:11, Anthony PERARD wrote:
> > Instead of generating the CFLAGS in Rules.mk everytime we enter a new
> > subdirectory, we are going to generate most of them a single time, and
> > export the result in the environment so that Rules.mk can use it.  The
> > only flags left to be generated are the ones that depend on the
> > targets, but the variable $(c_flags) takes care of that.
> > 
> > Arch specific CFLAGS are generated by a new file "arch/*/arch.mk"
> > which is included by the root Makefile.
> > 
> > We export the *FLAGS via the environment variables XEN_*FLAGS because
> > Rules.mk still includes Config.mk and would add duplicated flags to
> > CFLAGS.
> > 
> > When running Rules.mk in the root directory (xen/), the variable
> > `root-make-done' is set, so `need-config' will remain undef and so the
> > root Makefile will not generate the cflags again.
> > 
> > We can't use CFLAGS in subdirectories to add flags to particular
> > targets, instead start to use CFLAGS-y. Idem for AFLAGS.
> > So there are two different CFLAGS-y, the one in xen/Makefile (and
> > arch.mk), and the one in subdirs that Rules.mk is going to use.
> > We can't add to XEN_CFLAGS because it is exported, so making change to
> > it might be propagated to subdirectory which isn't intended.
> > 
> > Some style change are introduced in this patch:
> >     when LDFLAGS_DIRECT is included in LDFLAGS
> >     use of CFLAGS-$(CONFIG_INDIRECT_THUNK) instead of ifeq().
> > 
> > The LTO change hasn't been tested properly, as LTO is marked as
> > broken.
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> with one further question:
> 
> > --- a/xen/arch/x86/Rules.mk
> > +++ b/xen/arch/x86/Rules.mk
[..]
> > +c_flags += $(object_label_flags) $(CFLAGS-stack-boundary)
> > +a_flags += $(object_label_flags) $(CFLAGS-stack-boundary)
> 
> Why are you also adding these to a_flags? It probably doesn't hurt,
> but I'd prefer if it was removed (could be done while committing if
> all acks arrive and other other need for av6 arises) if there's no
> clear need.

Those flags are already in a_flags (or previously AFLAGS). I've tried to
be careful to avoid changing the list of *flags in an already
complicated enough patch. I would like to keep this patch that way.

If the -D__OBJECT_LABEL__ and the stack-bondary flags aren't needed in
a_flags, it would be better to remove them in a separated patch, with
some explanation on why they are removed.

What is av6?

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 09:53:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 09:53:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRv1D-0004rT-4x; Fri, 24 Apr 2020 09:53:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRv1C-0004rO-4F
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 09:53:10 +0000
X-Inumbo-ID: 64044ea2-8611-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 64044ea2-8611-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 09:53:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/ApaI2gwuLAMVgD7bkSDvM0Y9yBg3I9DcRfn8mfXao8=; b=KnCgx34mnVZMUVw6gdJnDE24O
 FbEl438S93/q9vGjvAPCL/mIFuc+1NGPV8j4osbjyB8ECrRTJUVih+UtqP3gfkb/nTGbX426HHxkp
 6qFSfoidRik9Z1MoNw1klGgFqDJ3FcOfkLwsFvYoMc4tBVO9bgN/k1ylArq2tV0Eps+VQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRv15-0004ZA-Oj; Fri, 24 Apr 2020 09:53:03 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRv15-0000vD-GE; Fri, 24 Apr 2020 09:53:03 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRv15-0005ag-EA; Fri, 24 Apr 2020 09:53:03 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149773-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149773: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=e2f1e2687fe5c976d1aecbae9350e761f1d1ddc0
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 09:53:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149773 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149773/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
 build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm  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-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              e2f1e2687fe5c976d1aecbae9350e761f1d1ddc0
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   98 days
Failing since        146211  2020-01-18 04:18:52 Z   97 days   90 attempts
Testing same since   149773  2020-04-24 04:18:45 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Chen Hanxiao <chen_han_xiao@126.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mark Asselstine <mark.asselstine@windriver.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Philipp Hahn <hahn@univention.de>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 16047 lines long.)


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 10:25:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 10:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRvW6-0007XV-3n; Fri, 24 Apr 2020 10:25:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRvW5-0007XP-Kx
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 10:25:05 +0000
X-Inumbo-ID: dcebbdd8-8615-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id dcebbdd8-8615-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 10:25:05 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 82DD3AB8F;
 Fri, 24 Apr 2020 10:25:03 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86: drop cpu_has_ffxsr
Message-ID: <55bcfe11-251c-606e-6f0f-a03880efa390@suse.com>
Date: Fri, 24 Apr 2020 12:24:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

It's definition is bogus when it comes to Hygon CPUs, but since we don't
use it anywhere drop it rather than correcting it.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -66,8 +66,6 @@
 
 /* CPUID level 0x80000001.edx */
 #define cpu_has_nx              boot_cpu_has(X86_FEATURE_NX)
-#define cpu_has_ffxsr           ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) \
-                                 && boot_cpu_has(X86_FEATURE_FFXSR))
 #define cpu_has_page1gb         boot_cpu_has(X86_FEATURE_PAGE1GB)
 #define cpu_has_rdtscp          boot_cpu_has(X86_FEATURE_RDTSCP)
 #define cpu_has_3dnow_ext       boot_cpu_has(X86_FEATURE_3DNOWEXT)


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 10:30:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 10:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRvbN-00009f-6j; Fri, 24 Apr 2020 10:30:33 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=tQLy=6I=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jRvbL-00009a-Fp
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 10:30:31 +0000
X-Inumbo-ID: 9ce2aea8-8616-11ea-947a-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9ce2aea8-8616-11ea-947a-12813bfff9fa;
 Fri, 24 Apr 2020 10:30:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587724228;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=djc70Far7NLTpiozvKY04taHcaiVkaHzWm20Nlsv0uA=;
 b=bKcUlDpTyg9lvcfAfRlzKFgI65zcn2EqxZR7mXzh2GtW6FYMisB68r8o
 FmzOHkiIxJLA5t0OsV9KFY84+J6hHUzX4ov3NC21TM6Q7dO9zunRVdKyY
 Ql4d1vcIOD539fbShxdKvr3nJ8Bu5EejTu3k6HnDsCHP+o1lYymar9GfW 8=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: NCNyEJnJBXboIp/Kbkabc/tWl/B0HwtFzVApYARm94ixI8VOB1S1ZgCGcJgCRoxzk5b/cqmiBi
 Cn4pWyiLYnk1tHTQzdtaCg/CJMv8NBGLYEgES6JimN0kW0abCFeNiCiVmSq2JuZ3N8W31Kf4Oi
 Fi7gZMQRRCJGVp25oRiBr+wYJjy6nyFh/X3+VHWgz3iRaKSiKgzNQOOb+SYVcrjSwKW46omwyA
 yQp5fhB8JmaBch58QOnPDhZDj8Yat3NljZDKEpiR6+emGb8ls5tn7g9rsSL+BZFhO9S/h+KzAD
 jj0=
X-SBRS: 2.7
X-MesageID: 16176337
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,311,1583211600"; d="scan'208";a="16176337"
Subject: Re: [PATCH] x86: drop cpu_has_ffxsr
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <55bcfe11-251c-606e-6f0f-a03880efa390@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <866dfded-71ad-c6eb-e3e3-c4b1244efe79@citrix.com>
Date: Fri, 24 Apr 2020 11:30:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <55bcfe11-251c-606e-6f0f-a03880efa390@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24/04/2020 11:24, Jan Beulich wrote:
> It's definition is bogus when it comes to Hygon CPUs, but since we don't
> use it anywhere drop it rather than correcting it.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I had wondered about that too.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 10:35:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 10:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRvft-0000Q0-Nb; Fri, 24 Apr 2020 10:35:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRvfr-0000Pr-M3
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 10:35:11 +0000
X-Inumbo-ID: 465b3fd6-8617-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 465b3fd6-8617-11ea-83d8-bc764e2007e4;
 Fri, 24 Apr 2020 10:35:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=xhfyywIssX/u9GqLDNH+aeGbuO0fHxD9WwzpORFPQ2k=; b=SnSFsSK1sM0g6xirtb3DJ+OHQk
 e/eo4vvdfDIwIdrzzVVCntjoG+SXnxuB5qXTBQ7MJAQur0vpYyh27KyEF8XtX7vUjU3Ih6iDu057c
 8X5L4J3bAyE5zZpKB4aBPWCURNOKhu8vDyW04M6bBIE7QZjoy2ElbDrJTfywG1ROJYiY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRvfp-0005VW-EQ; Fri, 24 Apr 2020 10:35:09 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRvfp-0002dI-7c; Fri, 24 Apr 2020 10:35:09 +0000
Subject: Re: [PATCH 0/3] xenoprof: XSA-313 follow-up
To: paul@xen.org, 'Jan Beulich' <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
 <002801d61302$dbd21950$93764bf0$@xen.org>
 <410df70e-6e21-2d0a-8148-62ccf2a24366@xen.org>
 <004301d61724$9a5c9ab0$cf15d010$@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <660fa82f-7316-a0ec-baef-dee18f0a57ea@xen.org>
Date: Fri, 24 Apr 2020 11:35:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <004301d61724$9a5c9ab0$cf15d010$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Wei Liu' <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 20/04/2020 16:01, Paul Durrant wrote:
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Sent: 20 April 2020 15:15
>> To: paul@xen.org; 'Jan Beulich' <jbeulich@suse.com>; xen-devel@lists.xenproject.org
>> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' <george.dunlap@citrix.com>; 'Ian
>> Jackson' <ian.jackson@eu.citrix.com>; 'Stefano Stabellini' <sstabellini@kernel.org>; 'Wei Liu'
>> <wl@xen.org>
>> Subject: Re: [PATCH 0/3] xenoprof: XSA-313 follow-up
>>
>> Hi Paul,
>>
>> On 15/04/2020 09:50, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: 15 April 2020 09:45
>>>> To: xen-devel@lists.xenproject.org
>>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap <george.dunlap@citrix.com>; Ian
>> Jackson
>>>> <ian.jackson@eu.citrix.com>; Julien Grall <julien@xen.org>; Stefano Stabellini
>>>> <sstabellini@kernel.org>; Wei Liu <wl@xen.org>; Paul Durrant <paul@xen.org>
>>>> Subject: [PATCH 0/3] xenoprof: XSA-313 follow-up
>>>>
>>>> Patch 1 was considered to become part of the XSA, but it was then
>>>> decided against. The other two are a little bit of cleanup, albeit
>>>> there's certainly far more room for tidying. Yet then again Paul,
>>>> in his mail from Mar 13, was asking whether we shouldn't drop
>>>> xenoprof altogether, at which point cleaning up the code would be
>>>> wasted effort.
>>>>
>>>
>>> That's still my opinion. This is a large chunk of (only passively maintained) code which I think is
>> of very limited value (since it relates to an old tool, and it only works for PV domains).
>>
>> While there are no active user we are aware of, this is an example on
>> how to implement a profiler backend with Xen. So I would agree with
>> Andrew here.
>>
>> IIRC, the reason behind your request is it makes difficult for your
>> xenheap work. Am I correct? If so, do you have a thread explaining the
>> issues?
> 
> After shared info and grant table, it is the only other occurrence of a xenheap page shared with a non-system domain. Also, it cannot be trivially replaced with an 'extra' domheap page because its assignment changes. Thus a whole bunch of cleanup work that I was hoping to do (largely in domain_relinquish_resources and free_domheap_pages) is either ruled out, or would have to special-case this type of page.

My knowledge of xenoprof is very limited, so I might be wrong.

 From my understanding, a buffer can only be shared between two domains:
    - When in passive mode, the buffer will be shared with the primary 
profiler (always the hwdom per the check in xenoprof_op_init()).
    - When in active mode, the buffer will be shared with the domain 
requesting to be profiled.

Would it be possible to consider to have a separate buffer for the 
passive mode and active mode?

> Also, I am unconvinced that PV guests are sufficiently common these days (apart from dom0) that profiling them is of any real use.

Even an HVM guest can't profile itself, I think it would be useful to 
have dom0 to profile an HVM guest. Are you suggesting this doesn't work?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 11:12:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 11:12:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRwFo-0003hM-KD; Fri, 24 Apr 2020 11:12:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=IwUP=6I=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jRwFo-0003hH-7E
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 11:12:20 +0000
X-Inumbo-ID: 7644fde0-861c-11ea-b58d-bc764e2007e4
Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7644fde0-861c-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 11:12:19 +0000 (UTC)
Received: by mail-wr1-x444.google.com with SMTP id x18so10298473wrq.2
 for <xen-devel@lists.xenproject.org>; Fri, 24 Apr 2020 04:12:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=23+YHagCHbRrZ7doxhQOa8LERS8C5Pq3jCURQTjKpBI=;
 b=K5o09HGNi1Ou2P7Rt7wioqprLHmaemnb4jhtJCqLBu9p7DEP2o7Ggjev6f8BFAa+RP
 HUVGqTlaznAf8puRoqdPvbUE2647aajnwTRl0GA/FBBj5AzpwB0E8fqiTzVaKipKjwg7
 WOmnh25NUKYJlbuHUh3GTElQFyU5BHtTcRfL9UfzcW6SmqSBuycWHFTKAHk1PFQO44Zr
 rp0sgj+rIXEzPFvRdDs8o5f2nRbaqLqPfxS8n2SFj1xMtwrWmAk0ITRCSDvtkFNyo7rd
 V0w0h1M9LnpzdgAc62TBS9+FMUbopEKwXtq/zaKLM1VDbOt88LcY6GrTAKpTfXx9jBTX
 thpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :thread-index:content-language;
 bh=23+YHagCHbRrZ7doxhQOa8LERS8C5Pq3jCURQTjKpBI=;
 b=Lp8QjWvVH4dUL1aRwdymBlZVOBifKQ67dz8TzVykY0jkd9ICQvVj2ErGDdNFO5AYjQ
 2xnNem4xzrX1h8PYFNvuG9svROLQ5mKoNCjPjWAvhiOyi5a/xCSHeKHRawXX8ipPu+cO
 1ESy1yxixbxXsz9Ntb5AL/bVnE03ACtvbuBngY/Tb/MqCYCx4zx6S1dCxUGzejC0fAD7
 z8bpBLl3DIpxIsJAuuXELHmUtDuG5YIaJn4OI/U7dpyXN6z1gfAsvZLZpEPEOvebSH3Y
 5dwRr+gwpjiVWFFwVKiPGTBsIfd3L1Rbetb6HfZIoHEh8lMN/b8QKbDxKhqzpP63Qfw+
 jlrQ==
X-Gm-Message-State: AGi0PuZ5lNPoPZ6E6DgFfHHymQPrmRQ3gDyH0EwfD4IfCGpf7142odHi
 QAnzWDgKmEeKTOuZ039Ekp8=
X-Google-Smtp-Source: APiQypJ/e4MvRrO7/iKBAqP4kab7Qf7NdqnBG2JMz6J3JLHcOrOWwhcvAtYoApvFjMnp6n5pjRhzqw==
X-Received: by 2002:a5d:670d:: with SMTP id o13mr11296887wru.29.1587726738603; 
 Fri, 24 Apr 2020 04:12:18 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id s14sm2284047wmh.18.2020.04.24.04.12.16
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 24 Apr 2020 04:12:18 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>, "'Jan Beulich'" <jbeulich@suse.com>,
 <xen-devel@lists.xenproject.org>
References: <25c5b76f-4f95-3ba9-0ae0-dd0c1f3f8496@suse.com>
 <002801d61302$dbd21950$93764bf0$@xen.org>
 <410df70e-6e21-2d0a-8148-62ccf2a24366@xen.org>
 <004301d61724$9a5c9ab0$cf15d010$@xen.org>
 <660fa82f-7316-a0ec-baef-dee18f0a57ea@xen.org>
In-Reply-To: <660fa82f-7316-a0ec-baef-dee18f0a57ea@xen.org>
Subject: RE: [PATCH 0/3] xenoprof: XSA-313 follow-up
Date: Fri, 24 Apr 2020 12:12:16 +0100
Message-ID: <000201d61a29$37644db0$a62ce910$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKUpBz832WsrmfTrWwwQFYKS8h7/QHBHudWATlYg7wCo38NvwIHqNBwps3cKDA=
Content-Language: en-gb
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Wei Liu' <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 24 April 2020 11:35
> To: paul@xen.org; 'Jan Beulich' <jbeulich@suse.com>; xen-devel@lists.xenproject.org
> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' <george.dunlap@citrix.com>; 'Ian
> Jackson' <ian.jackson@eu.citrix.com>; 'Stefano Stabellini' <sstabellini@kernel.org>; 'Wei Liu'
> <wl@xen.org>
> Subject: Re: [PATCH 0/3] xenoprof: XSA-313 follow-up
> 
> Hi Paul,
> 
> On 20/04/2020 16:01, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Julien Grall <julien@xen.org>
> >> Sent: 20 April 2020 15:15
> >> To: paul@xen.org; 'Jan Beulich' <jbeulich@suse.com>; xen-devel@lists.xenproject.org
> >> Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap' <george.dunlap@citrix.com>; 'Ian
> >> Jackson' <ian.jackson@eu.citrix.com>; 'Stefano Stabellini' <sstabellini@kernel.org>; 'Wei Liu'
> >> <wl@xen.org>
> >> Subject: Re: [PATCH 0/3] xenoprof: XSA-313 follow-up
> >>
> >> Hi Paul,
> >>
> >> On 15/04/2020 09:50, Paul Durrant wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: 15 April 2020 09:45
> >>>> To: xen-devel@lists.xenproject.org
> >>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap <george.dunlap@citrix.com>; Ian
> >> Jackson
> >>>> <ian.jackson@eu.citrix.com>; Julien Grall <julien@xen.org>; Stefano Stabellini
> >>>> <sstabellini@kernel.org>; Wei Liu <wl@xen.org>; Paul Durrant <paul@xen.org>
> >>>> Subject: [PATCH 0/3] xenoprof: XSA-313 follow-up
> >>>>
> >>>> Patch 1 was considered to become part of the XSA, but it was then
> >>>> decided against. The other two are a little bit of cleanup, albeit
> >>>> there's certainly far more room for tidying. Yet then again Paul,
> >>>> in his mail from Mar 13, was asking whether we shouldn't drop
> >>>> xenoprof altogether, at which point cleaning up the code would be
> >>>> wasted effort.
> >>>>
> >>>
> >>> That's still my opinion. This is a large chunk of (only passively maintained) code which I think
> is
> >> of very limited value (since it relates to an old tool, and it only works for PV domains).
> >>
> >> While there are no active user we are aware of, this is an example on
> >> how to implement a profiler backend with Xen. So I would agree with
> >> Andrew here.
> >>
> >> IIRC, the reason behind your request is it makes difficult for your
> >> xenheap work. Am I correct? If so, do you have a thread explaining the
> >> issues?
> >
> > After shared info and grant table, it is the only other occurrence of a xenheap page shared with a
> non-system domain. Also, it cannot be trivially replaced with an 'extra' domheap page because its
> assignment changes. Thus a whole bunch of cleanup work that I was hoping to do (largely in
> domain_relinquish_resources and free_domheap_pages) is either ruled out, or would have to special-case
> this type of page.
> 
> My knowledge of xenoprof is very limited, so I might be wrong.
> 
>  From my understanding, a buffer can only be shared between two domains:
>     - When in passive mode, the buffer will be shared with the primary
> profiler (always the hwdom per the check in xenoprof_op_init()).
>     - When in active mode, the buffer will be shared with the domain
> requesting to be profiled.
> 
> Would it be possible to consider to have a separate buffer for the
> passive mode and active mode?

I think that may well work, yes.

> 
> > Also, I am unconvinced that PV guests are sufficiently common these days (apart from dom0) that
> profiling them is of any real use.
> 
> Even an HVM guest can't profile itself, I think it would be useful to
> have dom0 to profile an HVM guest. Are you suggesting this doesn't work?
> 

No. That may work for a PV dom0; I'll have to try it. So, yes, passive profiling may indeed still have value.

  Paul



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 11:13:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 11:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRwGU-0003lc-UD; Fri, 24 Apr 2020 11:13:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRwGT-0003lT-Jj
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 11:13:01 +0000
X-Inumbo-ID: 8f1cedfa-861c-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8f1cedfa-861c-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 11:13:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2E716ACC4;
 Fri, 24 Apr 2020 11:12:59 +0000 (UTC)
Subject: Re: [PATCH 1/6] x86_64/mm: map and unmap page tables in
 cleanup_frame_table
To: Julien Grall <julien@xen.org>, Hongyan Xia <hx242@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
 <a1caa70d-9c7a-b0c2-d7cf-1893db8f0ac4@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <aba8fe76-9a7a-7099-c04f-0ce36eaac1f8@suse.com>
Date: Fri, 24 Apr 2020 13:12:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a1caa70d-9c7a-b0c2-d7cf-1893db8f0ac4@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 11:02, Julien Grall wrote:
> On 17/04/2020 10:52, Hongyan Xia wrote:
>> @@ -763,10 +763,10 @@ static void cleanup_frame_table(struct mem_hotadd_info *info)
>>               continue;
>>           }
>>   -        ASSERT(l1e_get_flags(l2e_to_l1e(l2e)[l1_table_offset(sva)]) &
>> -                _PAGE_PRESENT);
>> -         sva = (sva & ~((1UL << PAGE_SHIFT) - 1)) +
>> -                    (1UL << PAGE_SHIFT);
>> +        ASSERT(l1e_get_flags(l1e_from_l2e(l2e, l1_table_offset(sva))) &
>> +               _PAGE_PRESENT);
>> +
>> +        sva = (sva & ~((1UL << PAGE_SHIFT) - 1)) + (1UL << PAGE_SHIFT);
> 
> NIT: While you are modifying the indentation. Couldn't we use PAGE_MASK and PAGE_SIZE here?

Oh, yes, this would be nice.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 11:21:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 11:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRwOG-0004ed-OF; Fri, 24 Apr 2020 11:21:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRwOF-0004eY-B4
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 11:21:03 +0000
X-Inumbo-ID: ad65cf38-861d-11ea-9482-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ad65cf38-861d-11ea-9482-12813bfff9fa;
 Fri, 24 Apr 2020 11:21:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D60E4AF45;
 Fri, 24 Apr 2020 11:20:58 +0000 (UTC)
Subject: Re: [XEN PATCH v5 04/16] xen/build: have the root Makefile generates
 the CFLAGS
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-5-anthony.perard@citrix.com>
 <28aeea6d-cd52-d8bf-f114-96ec435363c6@suse.com>
 <20200424094505.GS4088@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <2fc2abda-99a7-9bd0-5e91-03b8a1db0bb8@suse.com>
Date: Fri, 24 Apr 2020 13:20:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200424094505.GS4088@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 11:45, Anthony PERARD wrote:
> On Thu, Apr 23, 2020 at 06:40:33PM +0200, Jan Beulich wrote:
>> On 21.04.2020 18:11, Anthony PERARD wrote:
>>> --- a/xen/arch/x86/Rules.mk
>>> +++ b/xen/arch/x86/Rules.mk
> [..]
>>> +c_flags += $(object_label_flags) $(CFLAGS-stack-boundary)
>>> +a_flags += $(object_label_flags) $(CFLAGS-stack-boundary)
>>
>> Why are you also adding these to a_flags? It probably doesn't hurt,
>> but I'd prefer if it was removed (could be done while committing if
>> all acks arrive and other other need for av6 arises) if there's no
>> clear need.
> 
> Those flags are already in a_flags (or previously AFLAGS). I've tried to
> be careful to avoid changing the list of *flags in an already
> complicated enough patch. I would like to keep this patch that way.
> 
> If the -D__OBJECT_LABEL__ and the stack-bondary flags aren't needed in
> a_flags, it would be better to remove them in a separated patch, with
> some explanation on why they are removed.

Ah, fair point - previously we had

# Most CFLAGS are safe for assembly files:
#  -std=gnu{89,99} gets confused by #-prefixed end-of-line comments
#  -flto makes no sense and annoys clang
AFLAGS += $(filter-out -std=gnu% -flto,$(CFLAGS))

and hence implicitly inherited all kinds of inapplicable flags.
I'm fine with this (and probably other things) getting taken care
of later then.

> What is av6?

I was missing a blank: "a v6". Also s/other other/no other".

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 11:27:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 11:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRwTv-0004qC-Ea; Fri, 24 Apr 2020 11:26:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=K8ZV=6I=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jRwTu-0004q7-DC
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 11:26:54 +0000
X-Inumbo-ID: 7ee1afd2-861e-11ea-b58d-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7ee1afd2-861e-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 11:26:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587727614;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=+cOGvK2bo9ex+jkQSykUvpoAKZkGtXOSXaPvKNaQt2U=;
 b=MgH4cE41Kb1K02pnnJzjYnUhhRYtxjLUi1rqa69CWhEJgkPIfEHeFSzp
 Gjsn5yfB4SWTFH8V3Meu/m1AnV0Emok9wwzs4BBrfPP4Mo/NsjEI/W86k
 0WT3CQTuKLNreEaE15+paVZA2YAdEl/laIXUNR26VOqPjNs4ZlIQ718tt M=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: nXhKALbobonOH1jyp0JyZj5kL9471PHAk4dqZFX9m4aXySzf7BsLDwwcIxcTAEbmyPOSQO8pSU
 6hgrUfktIJd3/3nsIL/GidVmEUbNleW030mnZRsnt4BLvXqwSRWQQiHptzntkn1jUqMWnHoGdT
 JFJRKE4ykPCAfpm2/MNmkGdQ0nXmltPze/QMUAx4253U1FgvJgIC6MK5s6Lfo/VdmIN04b9mM5
 blz05152zbpG2IPrjw5pNhGJHkfVvI+JXlTNnBfPB2pVx2iIQyb08GkxV+4fPRAHH9YJcuaG/a
 CnA=
X-SBRS: 2.7
X-MesageID: 16178792
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,311,1583211600"; d="scan'208";a="16178792"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: Golang Xen packages and the golang packaging system
Thread-Topic: Golang Xen packages and the golang packaging system
Thread-Index: AQHWGe1+ESpfdvwh2EWwKepDxr2WF6iIARkA
Date: Fri, 24 Apr 2020 11:26:48 +0000
Message-ID: <E0DEA134-CB69-4992-B949-7233BFF3A1E4@citrix.com>
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
 <24225.31493.220592.722565@mariner.uk.xensource.com>
 <24225.31669.536258.56822@mariner.uk.xensource.com>
 <4085F05B-ABEC-446A-8BB1-06DEE57D71A5@citrix.com>
 <C10E07AB-FDE8-4588-95E7-6109F0FDB5E2@citrix.com>
 <CAEBZRSfUysyGhnsXDEAJiVDBeX-Kb836V-uT6Qrtomte1LKgsA@mail.gmail.com>
In-Reply-To: <CAEBZRSfUysyGhnsXDEAJiVDBeX-Kb836V-uT6Qrtomte1LKgsA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <4D3D81EB0110B94EABB2106F16FC5E59@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDI0LCAyMDIwLCBhdCA1OjA0IEFNLCBOaWNrIFJvc2Jyb29rIDxyb3Nicm9v
a25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIFRodSwgQXByIDIzLCAyMDIwIGF0IDE6MjIg
UE0gR2VvcmdlIER1bmxhcCA8R2VvcmdlLkR1bmxhcEBjaXRyaXguY29tPiB3cm90ZToNCj4+IA0K
Pj4gDQo+Pj4gT24gQXByIDIzLCAyMDIwLCBhdCAxMjo0OSBQTSwgR2VvcmdlIER1bmxhcCA8Z2Vv
cmdlLmR1bmxhcEBjaXRyaXguY29tPiB3cm90ZToNCj4+PiANCj4+PiANCj4+PiANCj4+Pj4gT24g
QXByIDIzLCAyMDIwLCBhdCAxMjoyNyBQTSwgSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGNpdHJp
eC5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gSWFuIEphY2tzb24gd3JpdGVzICgiUmU6IEdvbGFu
ZyBYZW4gcGFja2FnZXMgYW5kIHRoZSBnb2xhbmcgcGFja2FnaW5nIHN5c3RlbSIpOg0KPj4+Pj4g
VGhpcyBpcyBxdWl0ZSB1bnBsZWFzYW50LiAgSW4gcGFydGljdWxhciwgaXQgbWFrZXMgYSBnaXQg
dHJlZSBvdXQgb2YNCj4+Pj4+IG91dHB1dCBmaWxlcy4gIFdoYXQgd2lsbCB3ZSBkbyB3aGVuIHNv
bWVvbmUgc2VuZHMgdXMgcGF0Y2hlcyB0byB0aGUNCj4+Pj4+IGJpbmRpbmdzID8NCj4+Pj4gDQo+
Pj4+IEFsc28sIGFueW9uZSB3aG8gcmVkaXN0cmlidXRlcyB5b3VyIHByb3Bvc2VkIGdvbGFuZyBw
YWNrYWdlIGlzDQo+Pj4+IHZpb2xhdGluZyBvdXIgbGljZW5jZSB1bmxlc3MgdGhleSBzaGlwIGEg
Y29weSBvZiB4ZW4uZ2l0WzFdIHRvbywgc2luY2UNCj4+Pj4gdGhlIGdvbGFuZyBwYWNrYWdlIGlz
IG5vdCBzb3VyY2UgY29kZS4NCj4+Pj4gDQo+Pj4+IFsxXSBUZWNobmljYWxseSwgYSBjb3B5IG9m
IHRoZSByZWxldmFudCBwYXJ0cyB3aWxsIGRvLg0KPj4+IA0KPj4+IFRoZSDigJxyZWxldmFudCBw
YXJ0c+KAnSB3b3VsZCBwcmltYXJpbHkgYmUgZ2VuZ290eXBlcy5weSwgcmlnaHQ/ICBPaCwgYW5k
IEkgZ3Vlc3MgbGlieGxfdGVzdC5pZGwgYW5kIGZyaWVuZHMuICBsaWJ4bF90ZXN0LmlkbCBpc27i
gJl0IGluY2x1ZGVkIGluIHRoZSBkaXN0cmlidXRpb24gZWl0aGVyLg0KPj4+IA0KPj4+IEnigJlt
IG5vdCBhbiBleHBlcnQgaW4gdGhlIGdvbGFuZyBidWlsZCBzeXN0ZW0sIGJ1dCB0aGV5IGdlbmVy
YWxseSBzZWVtIHRvIGJlIHRyeWluZyB0byBrZWVwIHRoZSBmdW5jdGlvbmFsaXR5IHNpbXBsZSAo
d2hpY2ggb2YgY291cnNlLCBtZWFucyBpZiB5b3Ugd2FudCB0byBkbyBhbnl0aGluZyBub24tYmFz
aWMsIGl04oCZcyBpbmNyZWRpYmx5IGNvbXBsaWNhdGVkIG9yIGNvbXBsZXRlbHkgaW1wb3NzaWJs
ZSkuDQo+Pj4gDQo+Pj4gVGhlcmXigJlzIGEgY29tbWFuZCwgYGdvIGdlbmVyYXRlYCwgd2hpY2gg
d2UgY291bGQgdXNlIHRvIHJ1biBnZW5nb3R5cGVzLnB5IHRvIGdlbmVyYXRlIHRoZSBhcHByb3By
aWF0ZSBmaWxlcy4gIEJ1dCBJ4oCZbSBub3Qgc3VyZSBob3cgdG8gdXNlIHRoYXQgaW4gYSBwcmFj
dGljYWwgd2F5IGZvciB0aGlzIHNvcnQgb2YgcGFja2FnZTogaXQgbWlnaHQgZW5kIHVwIHRoYXQg
cGVvcGxlIHdhbnRpbmcgdG8gdXNlIHRoZSBwYWNrYWdlIHdvdWxkIG5lZWQgdG8gbWFudWFsbHkg
Y2xvbmUgaXQsIHRoZW4gbWFudWFsbHkgcnVuIGBnbyBnZW5lcmF0ZWAgYmVmb3JlIG1hbnVhbGx5
IGJ1aWxkaW5nIHRoZSBwYWNrYWdlLg0KPj4+IA0KPj4+IENoZWNraW5nIGluIHRoZSBnZW5lcmF0
ZWQgZmlsZXMgbWVhbnMgdGhhdCBzb21lb25lIGNhbiBzaW1wbHkgYWRkIGBnb2xhbmcueGVucHJv
amVjdC5vcmcveGVubGlnaHRgIGFzIGEgZGVwZW5kZW5jeSAocGVyaGFwcyB3aXRoIGEgc3BlY2lm
aWMgdmVyc2lvbiB0YWcsIGxpa2UgdjQuMTQpLCBhbmQgZXZlcnl0aGluZyBKdXN0IFdvcmtzLg0K
Pj4+IA0KPj4+IE5pY2sgbWF5IGhhdmUgc29tZSBpZGVhcyBvbiBob3cgdG8gdXNlIHRoZSBnb2xh
bmcgYnVpbGQgc3lzdGVtIG1vcmUgZWZmZWN0aXZlbHkuDQo+PiANCj4+IFNvLCB0aGUgZm9sbG93
aW5nIHNlZW1zIHRvIHdvcmsgcXVpdGUgd2VsbCBhY3R1YWxseToNCj4+IA0KPj4gbWtkaXIgdmVu
ZG9yDQo+PiBsbiAtcyB2ZW5kb3IvZ29sYW5nLnhlbnByb2plY3Qub3JnIC91c3Ivc2hhcmUvZ29j
b2RlL3NyYy9nb2xhbmcueGVucHJvamVjdC5vcmcNCj4+IGVjaG8g4oCcZ29sYW5nLnhlbnByb2pl
Y3Qub3JnL3hlbmxpZ2h04oCdID4+IHZlbmRvci9tb2R1bGVzLnR4dA0KPj4gZ28gYnVpbGQgLW1v
ZD12ZW5kb3INCj4+IA0KPj4gVXNpbmcgdGhlIGFib3ZlIG1ldGhvZCwgKHNheSkgcmVkY3RsLmdp
dCB3b3VsZCBidWlsZCBleGFjdGx5IHRoZSBzYW1lIG9uIFhlbiA0LjE0IGFzIG9uIFhlbiA0LjE1
IChhc3N1bWluZyByZWRjdGwgd2FzbuKAmXQgdXNpbmcgYW55dGhpbmcgbm90IGF2YWlsYWJsZSBp
biA0LjE0KS4NCj4+IA0KPj4gSeKAmW0gaW5jbGluZWQgdG8gc2F5IHdlIHNob3VsZCBzdGFydCB3
aXRoIGp1c3QgdGVsbGluZyBwZW9wbGUgdG8gZG8gdGhhdCwgYW5kIGxvb2sgYXQgZG9pbmcgc29t
ZXRoaW5nIGVsc2UgaWYgd2UgZGlzY292ZXIgdGhhdOKAmXMgbm90IHN1aXRhYmxlIGZvciBzb21l
IHJlYXNvbi4NCj4gDQo+IElmIGl0J3Mgbm90IHZpYWJsZSB0byBjcmVhdGUgYW5vdGhlciByZXBv
IGZvciB0aGUgeGVubGlnaHQgcGFja2FnZSwgSQ0KPiB0aGluayB3ZSBzaG91bGQgc2hvdWxkIGp1
c3QgaW5pdGlhbGl6ZSB0aGUgZ28gbW9kdWxlLCBpLmUuIGdvLm1vZCwgYXQNCj4geGVuLmdpdC90
b29scy9nb2xhbmcuIFRoZSBkb3duc2lkZSBpcyB0aGF0IHRhZ3MgY2Fubm90IGJlIGluZGVwZW5k
ZW50DQo+IGZyb20gdGhlIHJlc3Qgb2YgeGVuLmdpdCwgc28gdXNlcnMgbmVlZCB0byBoYXZlIGBy
ZXF1aXJlIDxtb2R1bGUNCj4gcGF0aD4veGVubGlnaHRAUkVMRUFTRS00LjE0LjBgIGluIHRoZWly
IGdvLm1vZCwgYnV0IGF0IGxlYXN0IGl0cyBgZ28NCj4gZ2V0YC1hYmxlLiBBbmQsIHRoaXMgZG9l
cyBub3QgZmV0Y2ggdGhlIGVudGlyZSBnaXQgdHJlZS4NCj4gDQo+IFRoaXMgd291bGQgYWxzbyBt
ZWFuIHRoYXQgd2UgYWN0dWFsbHkgdHJhY2sgdGhlIGdlbmVyYXRlZCBjb2RlICh3aGljaA0KPiBp
c24ndCByZWFsbHkgYSBiaWcgZGVhbCBJTU8sIGl0J3MgZXhwZWN0ZWQgdGhhdCBwZW9wbGUgdHJh
Y2sgdGhlaXINCj4gZ2VuZXJhdGVkIGdSUEMgY29kZSwgZm9yIGV4YW1wbGUpLg0KDQpZZXMsIEkg
d2FzIHBsYXlpbmcgd2l0aCB0aGlzIHllc3RlcmRheSBhbmQgaXQgc2VlbXMgdG8gd29yayBPSy4N
Cg0KVGhlIHRoaW5nIEkgZGlkbuKAmXQgbmVjZXNzYXJpbHkgbGlrZSBhYm91dCB0aGlzIHdhcyB0
aGF0IHN1cHBvc2UgeW91IGhhZCBhIHB1YmxpYyBwcm9qZWN0IHRoYXQgdXNlZCB0aGUgeGVubGln
aHQgYmluZGluZ3MsIGFuZCB5b3UgdXBncmFkZWQgdG8gWGVuIDQuMTUsIGJ1dCBzb21lIG9mIHlv
dXIgdXNlcnMgaGFkbuKAmXQuICBJZiB5b3UgdXBkYXRlZCB0aGlzIHRvIFJFTEVBU0UtNC4xNS4w
LCB0aGVuIGFsbCB5b3VyIGRvd25zdHJlYW1zIHdvdWxkIHN0b3Agd29ya2luZywgZXZlbiBpZiB5
b3Ugd2VyZW7igJl0IHVzaW5nIGFueSBmdW5jdGlvbmFsaXR5IHNwZWNpZmljIHRvIFhlbiA0LjE1
Lg0KDQpCdXQgSSBzdXBwb3NlIHdoYXQgdGhhdCB3b3VsZCByZWFsbHkgbWVhbiBpcyB0aGF0Og0K
MSkgV2Ugc2hvdWxkIG1ha2Ugc3VyZSB0aGF0IHhlbmxpZ2h0QFJFTEVBU0UtJFYgd29ya3Mgb24g
PiAkViBhcyB3ZWxsDQoyKSBQcm9qZWN0cyBkZXBlbmRpbmcgb24gdGhlIGJpbmRpbmdzIHNob3Vs
ZCB1c2UgdGhlIG9sZGVzdCB2ZXJzaW9uIG9mIHRoZSBYZW4gYmluZGluZ3Mgc3VpdGFibGUgZm9y
IHRoZWlyIHVzZSBjYXNlLg0KDQpCb3RoIG9mIHRob3NlIGFyZSBwcm9iYWJseSByZWFzb25hYmxl
Lg0KDQpBbm90aGVyIGlzc3VlIHRoYXQgaGFwcGVucyB3aXRoIGNoZWNraW5nIGluIGdlbmVyYXRl
ZCBjb2RlIGlzIHRoYXQgdGhlIGlkbCBjaGFuZ2VzIGFuZCBub2JvZHkgcmUtZ2VuZXJhdGVzIHRo
ZSBjb2RlLiAgV2XigJlkIHByb2JhYmx5IHdhbnQgYW4gb3NzdGVzdCBjaGVjayB0aGF0IHdvdWxk
IHJlZnVzZSB0byBwdXNoIGZyb20gc3RhZ2luZyAtPiBtYXN0ZXIgaWYgcmUtcnVubmluZyB0aGUg
Y29kZSBnZW5lcmF0b3IgcHJvZHVjZWQgYSBkaWZmZXJlbnQgb3V0cHV0LiAgKEJ1dCB0aGF0IGhh
cyBpdHMgb3duIGFubm95YW5jZXM6IGl0IHNlZW1zIHRoYXQgZGlmZmVyZW50IHZlcnNpb25zIG9m
IHB5dGhvbiBzb3J0IHRoaW5ncyBpbiBkaWZmZXJlbnQgb3JkZXJzLCBzbyBJIG9mdGVuIGhhdmUg
dG8gdGhyb3cgYXdheSBzcHVyaW91cyBjaGFuZ2VzIHRvIHRoZSBnZW5lcmF0ZWQgZmlsZXMgYmVj
YXVzZSBvdXIgdHdvIHZlcnNpb25zIG9mIHB5dGhvbiBzZWVtIHRvIG9yZGVyIHNvbWUgdGhpbmdz
IGRpZmZlcmVudGx5LikNCg0KQlRXIHRoZSBzZXBhcmF0ZSByZXBvIGlzbuKAmXQgb2ZmIHRoZSB0
YWJsZS4gIEJ1dCB0aGVyZSB3ZXJlIHNvbWUgdGhpbmdzIG90aGVyIElhbiBwb2ludGVkIG91dDoN
Cg0KMS4gVGhlIEdQTCByZXF1aXJlcyB0aGF0IHlvdSBwcm92aWRlIHRoZSDigJxwcmVmZXJyZWQg
Zm9ybSBmb3IgbW9kaWZpY2F0aW9u4oCdIHRvIGFsbCB0aGUgY29kZS4gIEnigJltIG5vdCBzdXJl
IHRoaXMgaGFzIGJlZW4gYWRqdWRpY2F0ZWQgaW4gY291cnQsIGJ1dCB0aGVyZeKAmXMgYSBzdHJv
bmcgYXJndW1lbnQgdGhhdCAqZ2VuZXJhdGVkKiBjb2RlIGRvZXNu4oCZdCBtYXRjaCB0aGF0IGNy
aXRlcmlhOiB0aGF0IHRvIHNhdGlzZnkgdGhlIEdQTCB5b3XigJlkIG5lZWQgdG8gaW5jbHVkZSBs
aWJ4bF90eXBlcy5pZGwsIGlkbC5weSwgZ2VuZ290eXBlcy5weSwgYW5kIGEgTWFrZWZpbGUgc3Vp
dGFibGUgZm9yIHR5aW5nIHRoZW0gYWxsIHRvZ2V0aGVyLiAgKE5vdCB0aGF0IHRoZSBnZW5lcmF0
aW9uIG5lZWRzIHRvIGJlIHJ1biB3aXRoIGBnbyBidWlsZGAsIGJ1dCB0aGF0IGlkZWFsbHkgdGhl
IGluZnJhc3RydWN0dXJlIHdvdWxkIGJlIHRoZXJlIHNvIHRoYXQgaXQgKmNvdWxkKiBiZSBydW4u
KQ0KDQoyLiBJYW4gd2FzIGNvbmNlcm5lZCB3aXRoIGhvdyBzb21lb25lIHVzaW5nIHRoZSBiaW5k
aW5ncyB3b3VsZCBzdWJtaXQgYSBwYXRjaCB1cHN0cmVhbS4gIFN1cHBvc2Ugc29tZW9uZSBjbG9u
ZWQgb3VyIOKAnGJpbmRpbmdz4oCdIHJlcG8sIG1hZGUgc29tZSBjaGFuZ2VzIHNvIHRoYXQgaXQg
d29ya2VkIGZvciB0aGVtLCB0aGVuIHdhbnRlZCB0byBzdWJtaXQgdGhlIHBhdGNoIHVwc3RyZWFt
LiAgSG93IHdvdWxkIHRoZXkgZG8gdGhhdD8NCg0KSSBzdXBwb3NlIGV2ZW4gaWYgd2UgZG8gYSDi
gJxkZWVwIGxpbmvigJ0gaW50byBvdXIgYWN0dWFsIHJlcG8sIGl0IHdvbuKAmXQgbmVjZXNzYXJp
bHkgYmUgb2J2aW91cyB0byBwZW9wbGUgaG93IHRvIG1vZGlmeSB0aGluZ3MgYW5kIHN1Ym1pdCBw
YXRjaGVzLiAgV2XigJlkIHByb2JhYmx5IHdhbnQgYSBob3ctdG8uDQoNCkFueXdheSwgZG8geW91
IHdhbnQgdG8gc3VibWl0IGEgcGF0Y2ggYWRkaW5nIGEgYGdvLm1vZGAgaW4gdGhlIGFwcHJvcHJp
YXRlIHBsYWNlPyAgSeKAmXZlIGFsd2F5cyBoYWQgYSBoYXJkIHRpbWUgZmlndXJpbmcgb3V0IGhv
dyBnby5tb2QgYWN0dWFsbHkgd29ya3M7IHRoZXJlIHNlZW1zIHRvIGJlIG5vICptYW51YWwqLCBv
bmx5ICpob3d0b3MqLg0KDQogLUdlb3JnZQ==


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 12:19:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 12:19:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRxIP-0000dv-Uc; Fri, 24 Apr 2020 12:19:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/kKc=6I=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jRxIN-0000dq-UR
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 12:19:04 +0000
X-Inumbo-ID: c869db64-8625-11ea-83d8-bc764e2007e4
Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c869db64-8625-11ea-83d8-bc764e2007e4;
 Fri, 24 Apr 2020 12:19:02 +0000 (UTC)
Received: by mail-ej1-x642.google.com with SMTP id pg17so7335577ejb.9
 for <xen-devel@lists.xenproject.org>; Fri, 24 Apr 2020 05:19:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=JAJKRNHFYZNqCPq3DrKNArnvYAdOjpI95Zy9oVEFu1c=;
 b=rwt6IbtzTQ0l/zzTihFF20Pd0SwAdYeEuGKMlZK46BFjVGRVyfa1MMUz2FsSlsSatf
 9dXb1gy76FVkcoDF2RKK0B5+hFy/26W9EWTA62UQZG93bwK+FQpADbI/urcdxfK8UePu
 8SDRRlVBLkgs2OxsqzUhVY7FxYdoPSzJ+UUQssFBDKZyzfllfbgKwVGtOw3Rrnxoaem7
 T00aMWqRBgyiFK4qUfxjJo6XYclk9hI64ByR7g9jHyq1R++f5Tlfm7t1m/rQ82QN57pX
 1/ftuSjvc3ihXCi2z3i9mPYwRyhYv3TcgmLJQfUs58Qp0Wembr8Sioy4rl1kqYiZq/mA
 UstQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=JAJKRNHFYZNqCPq3DrKNArnvYAdOjpI95Zy9oVEFu1c=;
 b=W2nKKjka4roWLQ1Q4LOoQcaZOIbfT0YZEzEahnyaBACjPFZ2eS3HZz6z8aT94wRcvl
 6r+UtSQdxTYU4nMpeYT6cIbAwwaExuR1WknBDo8u7i8N8VIZh+ZdpxuLJe0yxhxKW1+a
 5mfkU3j1iDp4WlnmzCJjReZ3OedDgL8peSdsrbNXsvU2R7VqC8g4f8ytCfdxRvnT2NEN
 oflDPzUA6dJUf5GTAJZfaKw6oSakkPkYCivfy4hS4YMsAHaC8O/wGEZ0tv3AjAOEQRa7
 Kfnf0Ta7t9wpgdzqmZUdP5UlqTyyf9hhOHtlzz32I/ceKINRpt9YU6an65vVbmVtjigs
 baMQ==
X-Gm-Message-State: AGi0PubhCYb+VAQXnoI3sEWdK5lMSI+dIE1aTmm/wXRidlVoZzlL/mCb
 a0sMiTv8rXWYMZxjUY0zvf6PBeD2+tE=
X-Google-Smtp-Source: APiQypKjHenzEhnzFwASOmXyMd1MC9lmOwIlxCDVcEeHo71z91HapkQ9PAMbYOwl0FZGzhhITIwOdA==
X-Received: by 2002:a17:906:ce49:: with SMTP id
 se9mr3550709ejb.345.1587730741595; 
 Fri, 24 Apr 2020 05:19:01 -0700 (PDT)
Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com.
 [209.85.221.52])
 by smtp.gmail.com with ESMTPSA id i19sm535017edy.28.2020.04.24.05.19.00
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 24 Apr 2020 05:19:01 -0700 (PDT)
Received: by mail-wr1-f52.google.com with SMTP id g13so10522110wrb.8
 for <xen-devel@lists.xenproject.org>; Fri, 24 Apr 2020 05:19:00 -0700 (PDT)
X-Received: by 2002:a05:6000:4:: with SMTP id
 h4mr11174537wrx.386.1587730740656; 
 Fri, 24 Apr 2020 05:19:00 -0700 (PDT)
MIME-Version: 1.0
References: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
 <20200424094343.GH28601@Air-de-Roger>
In-Reply-To: <20200424094343.GH28601@Air-de-Roger>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Fri, 24 Apr 2020 06:18:24 -0600
X-Gmail-Original-Message-ID: <CABfawhnRhLJ0AKjTKBx7snEOHBX5oJ2KrwbscQk=e7qXHFD3mA@mail.gmail.com>
Message-ID: <CABfawhnRhLJ0AKjTKBx7snEOHBX5oJ2KrwbscQk=e7qXHFD3mA@mail.gmail.com>
Subject: Re: [PATCH v17 1/2] mem_sharing: fix sharability check during fork
 reset
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 24, 2020 at 3:44 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.com>=
 wrote:
>
> On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> > When resetting a VM fork we ought to only remove pages that were alloca=
ted for
> > the fork during it's execution and the contents copied over from the pa=
rent.
> > This can be determined if the page is sharable as special pages used by=
 the
> > fork for other purposes will not pass this test. Unfortunately during t=
he fork
> > reset loop we only partially check whether that's the case. A page's ty=
pe may
> > indicate it is sharable (pass p2m_is_sharable) but that's not a suffici=
ent
> > check by itself. All checks that are normally performed before a page i=
s
> > converted to the sharable type need to be performed to avoid removing p=
ages
> > from the p2m that may be used for other purposes. For example, currentl=
y the
> > reset loop also removes the vcpu info pages from the p2m, potentially p=
utting
> > the guest into infinite page-fault loops.
> >
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
>
> Reviewed-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>

Thanks!

>
> I've been looking however and I'm not able to spot where you copy the
> shared_info data, which I think it's also quite critical for the
> domain, as it contains the info about event channels (when using L2).
> Also for HVM forks the shared info should be mapped at the same gfn as
> the parent, or else the child trying to access it will trigger an EPT
> fault that won't be able to populate such gfn, because the shared_info
> on the parent is already shared between Xen and the parent.

Pages that cause an EPT fault but can't be made shared get a new page
allocated for them and copied in mem_sharing_fork_page. There are many
pages like that, mostly due to QEMU mapping them and thus holding an
extra reference. That said, shared_info is manually copied during
forking in copy_special_pages, at the end of the function you will
find:

old_mfn =3D _mfn(virt_to_mfn(d->shared_info));
new_mfn =3D _mfn(virt_to_mfn(cd->shared_info));

copy_domain_page(new_mfn, old_mfn);

Cheers,
Tamas


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 12:23:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 12:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRxMG-0001RL-Is; Fri, 24 Apr 2020 12:23:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=4idh=6I=kernel.org=sashal@srs-us1.protection.inumbo.net>)
 id 1jRxMF-0001RG-EQ
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 12:23:03 +0000
X-Inumbo-ID: 578d5d0c-8626-11ea-9490-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 578d5d0c-8626-11ea-9490-12813bfff9fa;
 Fri, 24 Apr 2020 12:23:02 +0000 (UTC)
Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net
 [73.47.72.35])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 52F7A2087E;
 Fri, 24 Apr 2020 12:23:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587730982;
 bh=IUCErDYU5+chUFB9+LblbUcLmt79a5CAIndVF79zzyc=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=JVikgC0657Ql78XqcS/AYFOJZmBrwAdGlK9pf3f3BHClWX+4b3ksLDUN6Tvaevbj6
 T8o4J5/kGWcxgmmNbOTBq0XFJQmIqL9+d4aT4Mn9AAnRCtphBMuKV8IR7mkzhYbX81
 fvTnKRf9z+1rtskeh5bmsdIhyMVmzs3oMS//9SuI=
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH AUTOSEL 5.6 21/38] xen/xenbus: ensure xenbus_map_ring_valloc()
 returns proper grant status
Date: Fri, 24 Apr 2020 08:22:19 -0400
Message-Id: <20200424122237.9831-21-sashal@kernel.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200424122237.9831-1-sashal@kernel.org>
References: <20200424122237.9831-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sasha Levin <sashal@kernel.org>,
 Wei Liu <wl@xen.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Juergen Gross <jgross@suse.com>

[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]

xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).

There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.

Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.

This is part of XSA-316.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/xen/xenbus/xenbus_client.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index e17ca81561713..a38292ef79f6d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -448,7 +448,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
 			   unsigned int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	int err;
+
+	err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	/* Some hypervisors are buggy and can return 1. */
+	if (err > 0)
+		err = GNTST_general_error;
+
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 12:23:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 12:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRxMu-0001Uc-UP; Fri, 24 Apr 2020 12:23:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=4idh=6I=kernel.org=sashal@srs-us1.protection.inumbo.net>)
 id 1jRxMt-0001UR-CB
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 12:23:43 +0000
X-Inumbo-ID: 6f94db78-8626-11ea-9490-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6f94db78-8626-11ea-9490-12813bfff9fa;
 Fri, 24 Apr 2020 12:23:43 +0000 (UTC)
Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net
 [73.47.72.35])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id D339020776;
 Fri, 24 Apr 2020 12:23:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587731022;
 bh=IUCErDYU5+chUFB9+LblbUcLmt79a5CAIndVF79zzyc=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=zwo1FmAO7tVEIUmg3qmd96ARoD0Msmy6lRm4rM9OPb7JgAk0z3M4rdOXADz1TbzIa
 6GB5or2oSMJ7csl1mVMPd+4Hnav27fAEJZy2m0rE7RxKzeB7jSlJi9Gu2msVv2nqZo
 s2dDg6egHqfPY0y8HwWKqExekawle2RDvnUEI8Ss=
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH AUTOSEL 5.4 16/26] xen/xenbus: ensure xenbus_map_ring_valloc()
 returns proper grant status
Date: Fri, 24 Apr 2020 08:23:13 -0400
Message-Id: <20200424122323.10194-16-sashal@kernel.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200424122323.10194-1-sashal@kernel.org>
References: <20200424122323.10194-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sasha Levin <sashal@kernel.org>,
 Wei Liu <wl@xen.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Juergen Gross <jgross@suse.com>

[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]

xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).

There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.

Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.

This is part of XSA-316.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/xen/xenbus/xenbus_client.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index e17ca81561713..a38292ef79f6d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -448,7 +448,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
 			   unsigned int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	int err;
+
+	err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	/* Some hypervisors are buggy and can return 1. */
+	if (err > 0)
+		err = GNTST_general_error;
+
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 12:24:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 12:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRxNM-0001YL-6a; Fri, 24 Apr 2020 12:24:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=4idh=6I=kernel.org=sashal@srs-us1.protection.inumbo.net>)
 id 1jRxNK-0001Y5-Ew
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 12:24:10 +0000
X-Inumbo-ID: 7fb6fd06-8626-11ea-9490-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7fb6fd06-8626-11ea-9490-12813bfff9fa;
 Fri, 24 Apr 2020 12:24:10 +0000 (UTC)
Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net
 [73.47.72.35])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 992F0218AC;
 Fri, 24 Apr 2020 12:24:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587731049;
 bh=IN3dBcosvKC2QUoeyRI6B2svCXNsLO997YBPPyyQJAs=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=QcKJCAVJWk0V069e672XlB1HrHenrPmgC1TWWpl4v1F6a1LI+NcVyhenBsShQrSQk
 5SjoFSyrhvjVzNKQ0DHVvt8Bk8tVQk9F2RKhY3Af9SGjUkwIZRHkQPN0HB2XIR8RHQ
 RQVEK3FPXmH6sy82LuHLSqf4wASPlsi/RKVal53w=
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH AUTOSEL 4.19 11/18] xen/xenbus: ensure
 xenbus_map_ring_valloc() returns proper grant status
Date: Fri, 24 Apr 2020 08:23:48 -0400
Message-Id: <20200424122355.10453-11-sashal@kernel.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200424122355.10453-1-sashal@kernel.org>
References: <20200424122355.10453-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sasha Levin <sashal@kernel.org>,
 Wei Liu <wl@xen.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Juergen Gross <jgross@suse.com>

[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]

xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).

There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.

Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.

This is part of XSA-316.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/xen/xenbus/xenbus_client.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index a1c17000129ba..e94a61eaeceb0 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -450,7 +450,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
 			   unsigned int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	int err;
+
+	err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	/* Some hypervisors are buggy and can return 1. */
+	if (err > 0)
+		err = GNTST_general_error;
+
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 12:24:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 12:24:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRxNi-0001dR-FB; Fri, 24 Apr 2020 12:24:34 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=4idh=6I=kernel.org=sashal@srs-us1.protection.inumbo.net>)
 id 1jRxNh-0001dB-CB
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 12:24:33 +0000
X-Inumbo-ID: 8d559e91-8626-11ea-9490-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8d559e91-8626-11ea-9490-12813bfff9fa;
 Fri, 24 Apr 2020 12:24:33 +0000 (UTC)
Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net
 [73.47.72.35])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id C02322166E;
 Fri, 24 Apr 2020 12:24:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587731072;
 bh=IN3dBcosvKC2QUoeyRI6B2svCXNsLO997YBPPyyQJAs=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=boDjgKHNPrOCKY4hZ31D0V/BMpC11F8UKhhc84mBfCZ4K6odBf0QzPLoLloFGKEsE
 ZuqOF24wyFs7nLuAxe6O++mw+6mdtzz7oLV0HgDlDy0mcTIwu8ceiMkLTyPhdshnDO
 lFU8itCh2wxl59JM9GyjJNXXYaSJI4lx8lOb3Y48=
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH AUTOSEL 4.14 10/21] xen/xenbus: ensure
 xenbus_map_ring_valloc() returns proper grant status
Date: Fri, 24 Apr 2020 08:24:08 -0400
Message-Id: <20200424122419.10648-10-sashal@kernel.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200424122419.10648-1-sashal@kernel.org>
References: <20200424122419.10648-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sasha Levin <sashal@kernel.org>,
 Wei Liu <wl@xen.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Juergen Gross <jgross@suse.com>

[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]

xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).

There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.

Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.

This is part of XSA-316.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/xen/xenbus/xenbus_client.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index a1c17000129ba..e94a61eaeceb0 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -450,7 +450,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
 			   unsigned int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	int err;
+
+	err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	/* Some hypervisors are buggy and can return 1. */
+	if (err > 0)
+		err = GNTST_general_error;
+
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 12:25:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 12:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRxO7-0001iF-PO; Fri, 24 Apr 2020 12:24:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=4idh=6I=kernel.org=sashal@srs-us1.protection.inumbo.net>)
 id 1jRxO6-0001hv-Vu
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 12:24:59 +0000
X-Inumbo-ID: 9ca3adb0-8626-11ea-9490-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9ca3adb0-8626-11ea-9490-12813bfff9fa;
 Fri, 24 Apr 2020 12:24:58 +0000 (UTC)
Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net
 [73.47.72.35])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 701AE20767;
 Fri, 24 Apr 2020 12:24:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587731098;
 bh=GqiAjsB0umloZVqaiehWJl9SaeTz4QMV4YkOimw4U6U=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=HRgl4QTrgYSz6/t3DAaRPD/hnAYtZ5En1VK42rSiKB7KtjixBjS8bcRdU+QZIB/1z
 ekHGLOSYxcw38vy/X/KHa0G5D2TGRW/eelLCPqtgHk+kRYxHLK04PSIIl6HQM4aU85
 xFcqcNK6uzSuomfM3Awv6BALqMJBvPaby9PfnCi4=
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH AUTOSEL 4.9 09/13] xen/xenbus: ensure xenbus_map_ring_valloc()
 returns proper grant status
Date: Fri, 24 Apr 2020 08:24:42 -0400
Message-Id: <20200424122447.10882-9-sashal@kernel.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200424122447.10882-1-sashal@kernel.org>
References: <20200424122447.10882-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sasha Levin <sashal@kernel.org>,
 Wei Liu <wl@xen.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Juergen Gross <jgross@suse.com>

[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]

xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).

There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.

Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.

This is part of XSA-316.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/xen/xenbus/xenbus_client.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 056da6ee1a357..df27cefb2fa35 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -469,7 +469,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
 			   unsigned int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	int err;
+
+	err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	/* Some hypervisors are buggy and can return 1. */
+	if (err > 0)
+		err = GNTST_general_error;
+
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 12:25:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 12:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRxOK-0001l2-2J; Fri, 24 Apr 2020 12:25:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=4idh=6I=kernel.org=sashal@srs-us1.protection.inumbo.net>)
 id 1jRxOI-0001kh-O1
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 12:25:10 +0000
X-Inumbo-ID: a393b76f-8626-11ea-9491-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a393b76f-8626-11ea-9491-12813bfff9fa;
 Fri, 24 Apr 2020 12:25:10 +0000 (UTC)
Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net
 [73.47.72.35])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 319DD217BA;
 Fri, 24 Apr 2020 12:25:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587731109;
 bh=GqiAjsB0umloZVqaiehWJl9SaeTz4QMV4YkOimw4U6U=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=fHa4Q/kWPvpK+hfqnl4duXj+A+GRtapSjqXk8JBokUaeXJZeU7bvYlVY5GMF/0sFG
 oxRi+Xe4DT2D5MsrwqBac2VxVhWBTwaEiXKXnXVGGmWAdVeASNqUyKpxbrnEcUu2UD
 EDP34tmVw1L5MCNS2qnf8en73BVwkkbWxkrRcIjc=
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH AUTOSEL 4.4 5/8] xen/xenbus: ensure xenbus_map_ring_valloc()
 returns proper grant status
Date: Fri, 24 Apr 2020 08:25:00 -0400
Message-Id: <20200424122503.11046-5-sashal@kernel.org>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200424122503.11046-1-sashal@kernel.org>
References: <20200424122503.11046-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Sasha Levin <sashal@kernel.org>,
 Wei Liu <wl@xen.org>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Juergen Gross <jgross@suse.com>

[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]

xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).

There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.

Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.

This is part of XSA-316.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/xen/xenbus/xenbus_client.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 056da6ee1a357..df27cefb2fa35 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -469,7 +469,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
 			   unsigned int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	int err;
+
+	err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	/* Some hypervisors are buggy and can return 1. */
+	if (err > 0)
+		err = GNTST_general_error;
+
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 12:37:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 12:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRxaM-0002pp-Ej; Fri, 24 Apr 2020 12:37:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=G6AF=6I=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jRxaK-0002pk-VU
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 12:37:37 +0000
X-Inumbo-ID: 5fb1fbef-8628-11ea-9491-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5fb1fbef-8628-11ea-9491-12813bfff9fa;
 Fri, 24 Apr 2020 12:37:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587731855;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=bUIuip07xZMkH6foTuXX1izTHbky8gMaULlT4Ws10HI=;
 b=Gg8clwlbe+Rt/iSaYnDA2QjMFHVTP2SPJQ0n1L8R6oB5mewXtHfbvL5M
 FsBml9LcG3BX3TuoZrOFfWkl6sWqemdoVMYfTN9J7L/VT0egiMGSyjYb9
 0hJcysnYGCr1Dohp9P9tzFDjBV+7XOcaWulqH/8vUFi30hU6HT/D18g/B 8=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: bFtQ2m+JSaQEX8TLGR5FuMnhmmn91opAFbAqj3f8dRMCDt6Kd80FYoJE49jrC0rpC2PAyQ1o+E
 oRD7Yowc8pLTFMPKU14hRQO5VwxV+dbhLTwg35QnbACShjM+ezwlVWY0A9CJuKJ7MuEVBlOs0q
 wIzSl7q+31TIqwWFgRspxGNqVeN/j0O434YlJ3lnt1Ss2IncEjjMtOH/JcrAaoV9BOUUaZMsDG
 NbJvKYw8VTrtS1UpS1G7HnG99ah1pjO94lGOdTvpQzXRerFxqDL//1BNYjKcKB0yD/A78DVvdj
 SNg=
X-SBRS: 2.7
X-MesageID: 16882065
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,311,1583211600"; d="scan'208";a="16882065"
Date: Fri, 24 Apr 2020 14:37:28 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Subject: Re: [PATCH v17 1/2] mem_sharing: fix sharability check during fork
 reset
Message-ID: <20200424123728.GI28601@Air-de-Roger>
References: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
 <20200424094343.GH28601@Air-de-Roger>
 <CABfawhnRhLJ0AKjTKBx7snEOHBX5oJ2KrwbscQk=e7qXHFD3mA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABfawhnRhLJ0AKjTKBx7snEOHBX5oJ2KrwbscQk=e7qXHFD3mA@mail.gmail.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 24, 2020 at 06:18:24AM -0600, Tamas K Lengyel wrote:
> On Fri, Apr 24, 2020 at 3:44 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
> >
> > On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> > > When resetting a VM fork we ought to only remove pages that were allocated for
> > > the fork during it's execution and the contents copied over from the parent.
> > > This can be determined if the page is sharable as special pages used by the
> > > fork for other purposes will not pass this test. Unfortunately during the fork
> > > reset loop we only partially check whether that's the case. A page's type may
> > > indicate it is sharable (pass p2m_is_sharable) but that's not a sufficient
> > > check by itself. All checks that are normally performed before a page is
> > > converted to the sharable type need to be performed to avoid removing pages
> > > from the p2m that may be used for other purposes. For example, currently the
> > > reset loop also removes the vcpu info pages from the p2m, potentially putting
> > > the guest into infinite page-fault loops.
> > >
> > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> >
> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Thanks!
> 
> >
> > I've been looking however and I'm not able to spot where you copy the
> > shared_info data, which I think it's also quite critical for the
> > domain, as it contains the info about event channels (when using L2).
> > Also for HVM forks the shared info should be mapped at the same gfn as
> > the parent, or else the child trying to access it will trigger an EPT
> > fault that won't be able to populate such gfn, because the shared_info
> > on the parent is already shared between Xen and the parent.
> 
> Pages that cause an EPT fault but can't be made shared get a new page
> allocated for them and copied in mem_sharing_fork_page. There are many
> pages like that, mostly due to QEMU mapping them and thus holding an
> extra reference. That said, shared_info is manually copied during
> forking in copy_special_pages, at the end of the function you will
> find:
> 
> old_mfn = _mfn(virt_to_mfn(d->shared_info));
> new_mfn = _mfn(virt_to_mfn(cd->shared_info));
> 
> copy_domain_page(new_mfn, old_mfn);

Oh, sorry for the noise, I somehow missed it.

Roger.


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 13:01:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 13:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRxxZ-0005GR-Ht; Fri, 24 Apr 2020 13:01:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRxxY-0005GM-83
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 13:01:36 +0000
X-Inumbo-ID: b9d113b4-862b-11ea-949f-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b9d113b4-862b-11ea-949f-12813bfff9fa;
 Fri, 24 Apr 2020 13:01:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 140E6AE64;
 Fri, 24 Apr 2020 13:01:33 +0000 (UTC)
Subject: Re: [XEN PATCH v5 04/16] xen/build: have the root Makefile generates
 the CFLAGS
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-5-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <db4f1e4f-1ffc-522a-4b2f-9eb2315d1acc@suse.com>
Date: Fri, 24 Apr 2020 15:01:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-5-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 18:11, Anthony PERARD wrote:
> Instead of generating the CFLAGS in Rules.mk everytime we enter a new
> subdirectory, we are going to generate most of them a single time, and
> export the result in the environment so that Rules.mk can use it.  The
> only flags left to be generated are the ones that depend on the
> targets, but the variable $(c_flags) takes care of that.
> 
> Arch specific CFLAGS are generated by a new file "arch/*/arch.mk"
> which is included by the root Makefile.
> 
> We export the *FLAGS via the environment variables XEN_*FLAGS because
> Rules.mk still includes Config.mk and would add duplicated flags to
> CFLAGS.
> 
> When running Rules.mk in the root directory (xen/), the variable
> `root-make-done' is set, so `need-config' will remain undef and so the
> root Makefile will not generate the cflags again.
> 
> We can't use CFLAGS in subdirectories to add flags to particular
> targets, instead start to use CFLAGS-y. Idem for AFLAGS.
> So there are two different CFLAGS-y, the one in xen/Makefile (and
> arch.mk), and the one in subdirs that Rules.mk is going to use.
> We can't add to XEN_CFLAGS because it is exported, so making change to
> it might be propagated to subdirectory which isn't intended.
> 
> Some style change are introduced in this patch:
>     when LDFLAGS_DIRECT is included in LDFLAGS
>     use of CFLAGS-$(CONFIG_INDIRECT_THUNK) instead of ifeq().
> 
> The LTO change hasn't been tested properly, as LTO is marked as
> broken.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

While committing this, in my pre-push build test I noticed that
presumably an earlier change of yours has caused

Makefile:103: include/config/auto.conf: No such file or directory
Makefile:106: include/config/auto.conf.cmd: No such file or directory

for a build in a completely fresh tree.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 13:11:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 13:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRy6w-00069y-Is; Fri, 24 Apr 2020 13:11:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jRy6v-00069s-Sy
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 13:11:17 +0000
X-Inumbo-ID: 14c80ee8-862d-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 14c80ee8-862d-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 13:11:17 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 42620AC5B;
 Fri, 24 Apr 2020 13:11:15 +0000 (UTC)
Subject: Re: [PATCH v17 2/2] xen/tools: VM forking toolstack side
To: Tamas K Lengyel <tamas.lengyel@intel.com>,
 Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
References: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
 <e416eac0c986fd1aba5f576d9b065a6f47660b2c.1587655725.git.tamas.lengyel@intel.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <1d705ad2-a5a1-8124-b43a-421143728669@suse.com>
Date: Fri, 24 Apr 2020 15:11:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e416eac0c986fd1aba5f576d9b065a6f47660b2c.1587655725.git.tamas.lengyel@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 23.04.2020 17:30, Tamas K Lengyel wrote:
> Add necessary bits to implement "xl fork-vm" commands. The command allows the
> user to specify how to launch the device model allowing for a late-launch model
> in which the user can execute the fork without the device model and decide to
> only later launch it.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>

As before this will be left for the tool stack maintainers to
ack and commit.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 13:31:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 13:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRyQ2-0007wC-Hb; Fri, 24 Apr 2020 13:31:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Spwv=6I=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jRyQ0-0007w7-JB
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 13:31:00 +0000
X-Inumbo-ID: d59eb2c8-862f-11ea-94a7-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d59eb2c8-862f-11ea-94a7-12813bfff9fa;
 Fri, 24 Apr 2020 13:30:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587735060;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=6hLaAQpkW4639x7YvW/V4LxF0UgSQBwKs5KrkWOAxM4=;
 b=Wt/HBwxG1PI4JSo8CQTVQPAUauq12mXZTGp2QnAbDhfwabrHyRxu/3D8
 yrzeQ0DhDs9lMe4aOYEgjyTGxgA3RS6e2GJvQUrIQVJNzp5FMJ/hS1MyR
 PlrFWhQWKXGfEaTDLUS0laP70s3RSaUOh/4JQUbE7OfneTTMh73tb7MEA A=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: P4bglsE28gGPPU3nLbDa5gdGH7mOducSFM0OeoQBdyh7c+K5Ai2Q1BcNdk4ii1lJFHki4uu6S+
 vmFJdSzxq30lmN+BiEM4p51D+EgXUWaeeCOsWeRyvCk0XfGiGczmBEhexGrNT+MPaNfuWDFChP
 KDzKCfgDMMRliukh7UhiUO4VA8BoeNTisJhhuSAJw7PWlmTNIL2xpLB8acDxC5GyrwOUyNzsIC
 SkPU0OpraIxO01E+z7lPaPYb9KQme90RwerOzTQma4kfgiyNzjDe3rGYjRH8vbHp2FRvQweBCf
 dOI=
X-SBRS: 2.7
X-MesageID: 16184984
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,311,1583211600"; d="scan'208";a="16184984"
Date: Fri, 24 Apr 2020 14:30:53 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v5 04/16] xen/build: have the root Makefile generates
 the CFLAGS
Message-ID: <20200424133053.GT4088@perard.uk.xensource.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-5-anthony.perard@citrix.com>
 <db4f1e4f-1ffc-522a-4b2f-9eb2315d1acc@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <db4f1e4f-1ffc-522a-4b2f-9eb2315d1acc@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 24, 2020 at 03:01:32PM +0200, Jan Beulich wrote:
> While committing this, in my pre-push build test I noticed that
> presumably an earlier change of yours has caused
> 
> Makefile:103: include/config/auto.conf: No such file or directory
> Makefile:106: include/config/auto.conf.cmd: No such file or directory
> 
> for a build in a completely fresh tree.

Are those presumably "warning" an issue? Are the files still missing
after make has run? Didn't the build managed to build xen.gz?
There is maybe a line saying that make will re-execute.

I've seen those error before, on older version of make. But it's just
make complaining before even trying to update/create those files. But it
just create those files and start over.

Also, that would be patch "build: include include/config/auto.conf in
main Makefile" which introduce this behavior.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 13:37:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 13:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRyWW-000889-8Y; Fri, 24 Apr 2020 13:37:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=JRE+=6I=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jRyWU-000884-JP
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 13:37:42 +0000
X-Inumbo-ID: c4d745f8-8630-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c4d745f8-8630-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 13:37:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=KQPSoJU+1HLvVZmw/z9kh1rKENGUJpf0myLlauD1kak=; b=Yhoq0zlTZ32pvbpo3T53XGsCb5
 OYEzJ7R1gV52rjkTlp8DLnJfJnERP5dK4axOONMat4g6uWbdfMsvvTEqcGOjTTLRht7F5Io1HlKHW
 KJ6FlmG9INmc6DYdiT2bLpYgnaBf/bVh/fFFw4Feyd8neMb/1Mz3/1bygtC8SyevkC0I=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <paul@xen.org>)
 id 1jRyWS-0000uC-E6; Fri, 24 Apr 2020 13:37:40 +0000
Received: from [54.239.6.185] (helo=CBG-R90WXYV0.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jRyWR-0007Oc-UR; Fri, 24 Apr 2020 13:37:40 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] docs/designs: re-work the xenstore migration document...
Date: Fri, 24 Apr 2020 14:37:36 +0100
Message-Id: <20200424133736.737-1-paul@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Durrant <pdurrant@amazon.com>

... to specify a separate migration stream that will also be suitable for
live update.

The original scope of the document was to support non-cooperative migration
of guests [1] but, since then, live update of xenstored has been brought into
scope. Thus it makes more sense to define a separate image format for
serializing xenstore state that is suitable for both purposes.

The document has been limited to specifying a new image format. The mechanism
for acquiring the image for live update or migration is not covered as that
is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
also expected that, when the first implementation of live update or migration
making use of this specification is committed, that the document is moved from
docs/designs into docs/specs.

[1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Juergen Gross <jgross@suse.com>
Andrew Cooper <andrew.cooper3@citrix.com>
George Dunlap <george.dunlap@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien@xen.org>
Stefano Stabellini <sstabellini@kernel.org>
Wei Liu <wl@xen.org>
---
 docs/designs/xenstore-migration.md | 472 +++++++++++++++++++----------
 1 file changed, 309 insertions(+), 163 deletions(-)

diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
index 6ab351e8fe..c96bad48eb 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -3,254 +3,400 @@
 ## Background
 
 The design for *Non-Cooperative Migration of Guests*[1] explains that extra
-save records are required in the migrations stream to allow a guest running
-PV drivers to be migrated without its co-operation. Moreover the save
-records must include details of registered xenstore watches as well as
-content; information that cannot currently be recovered from `xenstored`,
-and hence some extension to the xenstore protocol[2] will also be required.
-
-The *libxenlight Domain Image Format* specification[3] already defines a
-record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
-transferring xenstore data pertaining to the domain directly as it is
-specified such that keys are relative to the path
-`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
-define at least one new save record type.
+save records are required in the migrations stream to allow a guest running PV
+drivers to be migrated without its co-operation. Moreover the save records must
+include details of registered xenstore watches as well ascontent; information
+that cannot currently be recovered from `xenstored`, and hence some extension
+to the xenstored implementations will also be required.
+
+As a similar set of data is needed for transferring xenstore data from one
+instance to another when live updating xenstored this document proposes an
+image format for a 'migration stream' suitable for both purposes.
 
 ## Proposal
 
-### New Save Record
+The image format consists of a _header_ followed by 1 or more _records_. Each
+record consists of a type and length field, followed by any data mandated by
+the record type. At minimum there will be a single record of type `END`
+(defined below).
 
-A new mandatory record type should be defined within the libxenlight Domain
-Image Format:
+### Header
 
-`0x00000007: DOMAIN_XENSTORE_DATA`
+The header identifies the stream as a `xenstore` stream, including the version
+of the specification that it complies with.
 
-An arbitrary number of these records may be present in the migration
-stream and may appear in any order. The format of each record should be as
-follows:
+All fields in this header must be in _big-endian_ byte order, regardless of
+the setting of the endianness bit.
 
 
 ```
     0       1       2       3       4       5       6       7    octet
 +-------+-------+-------+-------+-------+-------+-------+-------+
-| type                          | record specific data          |
-+-------------------------------+                               |
-...
-+---------------------------------------------------------------+
+| ident                                                         |
++-------------------------------+-------------------------------|
+| version                       | flags                         |
++-------------------------------+-------------------------------+
 ```
 
-where type is one of the following values
 
+| Field     | Description                                       |
+|-----------|---------------------------------------------------|
+| `ident`   | 0x78656e73746f7265 ('xenstore' in ASCII)          |
+|           |                                                   |
+| `version` | 0x00000001 (the version of the specification)     |
+|           |                                                   |
+| `flags`   | 0 (LSB): Endianness: 0 = little, 1 = big          |
+|           |                                                   |
+|           | 1-31: Reserved (must be zero)                     |
 
-| Field  | Description                                      |
-|--------|--------------------------------------------------|
-| `type` | 0x00000000: invalid                              |
-|        | 0x00000001: NODE_DATA                            |
-|        | 0x00000002: WATCH_DATA                           |
-|        | 0x00000003: TRANSACTION_DATA                     |
-|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
+### Records
 
+Records immediately follow the header and have the following format:
 
-and data is one of the record data formats described in the following
-sections.
 
+```
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| type                          | len                           |
++-------------------------------+-------------------------------+
+| body
+...
+|       | padding (0 to 7 octets)                               |
++-------+-------------------------------------------------------+
+```
+
+NOTE: padding octets here and in all subsequent format specifications must be
+      zero, unless stated otherwise.
 
-NOTE: The record data does not contain an overall length because the
-libxenlight record header specifies the length.
 
+| Field  | Description                                          |
+|--------|------------------------------------------------------|
+| `type` | 0x00000000: END                                      |
+|        | 0x00000001: GLOBAL_DATA                              |
+|        | 0x00000002: CONNECTION_DATA                          |
+|        | 0x00000003: WATCH_DATA                               |
+|        | 0x00000004: TRANSACTION_DATA                         |
+|        | 0x00000005: NODE_DATA                                |
+|        | 0x00000006 - 0xFFFFFFFF: reserved for future use     |
+|        |                                                      |
+| `len`  | The length (in octets) of `body`                     |
+|        |                                                      |
+| `body` | The type-specific record data                        |
 
-**NODE_DATA**
+The various formats of the type-specific data are described in the following
+sections:
 
+\pagebreak
 
-Each NODE_DATA record specifies a single node in xenstore and is formatted
-as follows:
+### END
 
+The end record marks the end of the image, and is the final record
+in the stream.
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| NODE_DATA                     |
-+-------------------------------+
-| path length                   |
-+-------------------------------+
-| path data                     |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
-| perm count (N)                |
-+-------------------------------+
-| perm0                         |
-+-------------------------------+
-...
-+-------------------------------+
-| permN                         |
-+-------------------------------+
-| value length                  |
-+-------------------------------+
-| value data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
 ```
 
-where perm0..N are formatted as follows:
 
+The end record contains no fields; its body length is 0.
+
+\pagebreak
+
+### GLOBAL_DATA
+
+This record is only relevant for live update. It contains details of global
+xenstored state that needs to be restored.
 
 ```
-    0       1       2       3     octet
+    0       1       2       3    octet
 +-------+-------+-------+-------+
-| perm  | pad   | domid         |
+| rw-socket-fd                  |
++-------------------------------+
+| ro-socket-fd                  |
 +-------------------------------+
 ```
 
 
-path length and value length are specified in octets (excluding the NUL
-terminator of the path). perm should be one of the ASCII values `w`, `r`,
-`b` or `n` as described in [2]. All pad values should be 0.
-All paths should be absolute (i.e. start with `/`) and as described in
-[2].
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `rw-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-write connections                       |
+|                |                                              |
+| `ro-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-only connections                        |
+
+xenstored will resume in the original process context. Hence `rw-socket-fd` and
+`ro-socket-fd` simply specify the file descriptors of the sockets.
 
 
-**WATCH_DATA**
+\pagebreak
 
+### CONNECTION_DATA
 
-Each WATCH_DATA record specifies a registered watch and is formatted as
-follows:
+For live update the image format will contain a `CONNECTION_DATA` record for
+each connection to xenstore. For migration it will only contain a record for
+the domain being migrated.
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| WATCH_DATA                    |
-+-------------------------------+
-| wpath length                  |
-+-------------------------------+
-| wpath data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| conn-id                       | pad                           |
++---------------+-----------------------------------------------+
+| conn-type     | conn-spec
 ...
++-------------------------------+-------------------------------+
+| data-len                      | data
 +-------------------------------+
-| token length                  |
-+-------------------------------+
-| token data                    |
 ...
-| pad (0 to 3 octets)           |
-+-------------------------------+
 ```
 
-wpath length and token length are specified in octets (excluding the NUL
-terminator). The wpath should be as described for the `WATCH` operation in
-[2]. The token is an arbitrary string of octets not containing any NUL
-values.
 
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | A non-zero number used to identify this         |
+|             | connection in subsequent connection-specific    |
+|             | records                                         |
+|             |                                                 |
+| `conn-type` | 0x0000: shared ring                             |
+|             | 0x0001: socket                                  |
+|             |                                                 |
+| `conn-spec` | See below                                       |
+|             |                                                 |
+| `data-len`  | The length (in octets) of any pending data not  |
+|             | yet written to the connection                   |
+|             |                                                 |
+| `data`      | Pending data (may be empty)                     |
 
-**TRANSACTION_DATA**
+The format of `conn-spec` is dependent upon `conn-type`.
 
+\pagebreak
 
-Each TRANSACTION_DATA record specifies an open transaction and is formatted
-as follows:
+For `shared ring` connections it is as follows:
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| TRANSACTION_DATA              |
-+-------------------------------+
-| tx_id                         |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
+                +-------+-------+-------+-------+-------+-------+
+                | domid         | tdomid        | flags         |
++---------------+---------------+---------------+---------------+
+| revtchn                       | levtchn                       |
++-------------------------------+-------------------------------+
+| mfn                                                           |
++---------------------------------------------------------------+
 ```
 
-where tx_id is the non-zero identifier values of an open transaction.
-
 
-### Protocol Extension
+| Field      | Description                                      |
+|------------|--------------------------------------------------|
+| `domid`    | The domain-id that owns the shared page          |
+|            |                                                  |
+| `tdomid`   | The domain-id that `domid` acts on behalf of if  |
+|            | it has been subject to an SET_TARGET             |
+|            | operation [2] or DOMID_INVALID otherwise         |
+|            |                                                  |
+| `flags`    | A bit-wise OR of:                                |
+|            | 0x0001: INTRODUCE has been issued                |
+|            | 0x0002: RELEASE has been issued                  |
+|            |                                                  |
+| `revtchn`  | The port number of the interdomain channel used  |
+|            | by `domid` to communicate with xenstored         |
+|            |                                                  |
+| `levtchn`  | For a live update this will be the port number   |
+|            | of the interdomain channel used by xenstored     |
+|            | itself otherwise, for migration, it will be -1   |
+|            |                                                  |
+| `mfn`      | The MFN of the shared page for a live update or  |
+|            | INVALID_MFN otherwise                            |
+
+Since the ABI guarantees that entry 1 in `domid`'s grant table will always
+contain the GFN of the shared page, so for a live update `mfn` can be used to
+give confidence that `domid` has not been re-cycled during the update.
+
+
+For `socket` connections it is as follows:
 
-Before xenstore state is migrated it is necessary to wait for any pending
-reads, writes, watch registrations etc. to complete, and also to make sure
-that xenstored does not start processing any new requests (so that new
-requests remain pending on the shared ring for subsequent processing on the
-new host). Hence the following operation is needed:
 
 ```
-QUIESCE                 <domid>|
-
-Complete processing of any request issued by the specified domain, and
-do not process any further requests from the shared ring.
+    0       1       2       3       4       5       6       7    octet
+                +-------+-------+-------+-------+-------+-------+
+                | flags         | socket-fd                     |
+                +---------------+-------------------------------+
 ```
 
-The `WATCH` operation does not allow specification of a `<domid>`; it is
-assumed that the watch pertains to the domain that owns the shared ring
-over which the operation is passed. Hence, for the tool-stack to be able
-to register a watch on behalf of a domain a new operation is needed:
 
-```
-ADD_DOMAIN_WATCHES      <domid>|<watch>|+
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `flags`     | A bit-wise OR of:                               |
+|             | 0001: read-only                                 |
+|             |                                                 |
+| `socket-fd` | The file descriptor of the connected socket     |
 
-Adds watches on behalf of the specified domain.
+This type of connection is only relevant for live update, where the xenstored
+resumes in the original process context. Hence `socket-fd` simply specify
+the file descriptor of the socket connection.
 
-<watch> is a NUL separated tuple of <path>|<token>. The semantics of this
-operation are identical to the domain issuing WATCH <path>|<token>| for
-each <watch>.
-```
+\pagebreak
+
+### WATCH_DATA
+
+The image format will contain a `WATCH_DATA` record for each watch registered
+by a connection for which there is `CONNECTION_DATA` record previously present.
 
-The watch information for a domain also needs to be extracted from the
-sending xenstored so the following operation is also needed:
 
 ```
-GET_DOMAIN_WATCHES      <domid>|<index>   <gencnt>|<watch>|*
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++---------------+---------------+
+| wpath-len     | token-len     |
++---------------+---------------+
+| wpath
+...
+| token
+...
+```
+
 
-Gets the list of watches that are currently registered for the domain.
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | The connection that issued the `WATCH`          |
+|             | operation [2]                                   |
+|             |                                                 |
+| `wpath-len` | The length (in octets) of `wpath` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `token-len` | The length (in octets) of `token` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `wpath`     | The watch path, as specified in the `WATCH`     |
+|             | operation                                       |
+|             |                                                 |
+| `token`     | The watch identifier token, as specified in the |
+|             | `WATCH` operation                               |
+
+\pagebreak
+
+### TRANSACTION_DATA
+
+The image format will contain a `TRANSACTION_DATA` record for each transaction
+that is pending on a connection for which there is `CONNECTION_DATA` record
+previously present.
 
-<watch> is a NUL separated tuple of <path>|<token>. The sub-list returned
-will start at <index> items into the the overall list of watches and may
-be truncated (at a <watch> boundary) such that the returned data fits
-within XENSTORE_PAYLOAD_MAX.
 
-If <index> is beyond the end of the overall list then the returned sub-
-list will be empty. If the value of <gencnt> changes then it indicates
-that the overall watch list has changed and thus it may be necessary
-to re-issue the operation for previous values of <index>.
 ```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++-------------------------------+
+```
+
+
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `conn-id`      | The connection that issued the               |
+|                | `TRANSACTION_START` operation [2]            |
+|                |                                              |
+| `tx-id`        | The transaction id passed back to the domain |
+|                | by the `TRANSACTION_START` operation         |
+
+\pagebreak
 
-To deal with transactions that were pending when the domain is migrated
-it is necessary to start transactions with the same tx_id on behalf of the
-domain in the receiving xenstored.
+### NODE_DATA
 
-NOTE: For safety each such transaction should result in an `EAGAIN` when
-the `TRANSACTION_END` operation is performed, as modifications made under
-the tx_id will not be part of the migration stream.
+For live update the image format will contain a `NODE_DATA` record for each
+node in xenstore. For migration it will only contain a record for the nodes
+relating to the domain being migrated. The `NODE_DATA` may be related to
+a _committed_ node (globally visible in xenstored) or a _pending_ node (created
+or modified by a transaction for which there is also a `TRANSACTION_DATA`
+record previously present).
 
-The `TRANSACTION_START` operation does not allow specification of a
-`<domid>`; it is assumed that the transaction pertains to the domain that
-owns the shared ring over which the operation is passed. Neither does it
-allow a `<transid>` to be specified; it is always chosen by xenstored.
-Hence, for the tool-stack to be able to open a transaction on behalf of a
-domain a new operation is needed:
 
 ```
-START_DOMAIN_TRANSACTION    <domid>|<transid>|
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++---------------+---------------+
+| access        | perm-count    |
++---------------+---------------+
+| perm1                         |
++-------------------------------+
+...
++-------------------------------+
+| permN                         |
++---------------+---------------+
+| path-len      | value-len     |
++---------------+---------------+
+| path
+...
+| value
+...
+```
+
+
+| Field        | Description                                    |
+|--------------|------------------------------------------------|
+| `conn-id`    | If this value is non-zero then this record     |
+|              | related to a pending transaction               |
+|              |                                                |
+| `tx-id`      | This value should be ignored if `conn-id` is   |
+|              | zero. Otherwise it specifies the id of the     |
+|              | pending transaction                            |
+|              |                                                |
+| `access`     | This value should be ignored if this record    |
+|              | does not relate to a pending transaction,      |
+|              | otherwise it specifies the accesses made to    |
+|              | the node and hence is a bitwise OR of:         |
+|              |                                                |
+|              | 0x0001: read                                   |
+|              | 0x0002: written                                |
+|              |                                                |
+|              | The value will be zero for a deleted node      |
+|              |                                                |
+| `perm-count` | The number (N) of node permission specifiers   |
+|              | (which will be 0 for a node deleted in a       |
+|              | pending transaction)                           |
+|              |                                                |
+| `perm1..N`   | A list of zero or more node permission         |
+|              | specifiers (see below)                         |
+|              |                                                |
+| `path-len`   | The length (in octets) of `path` including the |
+|              | NUL terminator                                 |
+|              |                                                |
+| `value-len`  | The length (in octets) of `value` (which will  |
+|              | be zero for a deleted node)                    |
+|              |                                                |
+| `path`       | The absolute path of the node                  |
+|              |                                                |
+| `value`      | The node value (which may be empty or contain  |
+|              | NUL octets)                                    |
+
+
+A node permission specifier has the following format:
 
-Starts a transaction on behalf of a domain.
 
-The semantics of this are similar to the domain issuing
-TRANSACTION_START and receiving the specified <transid> as the response.
-The main difference is that the transaction will be immediately marked as
-'conflicting' such that when the domain issues TRANSACTION_END T|, it will
-result in EAGAIN.
+```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| perm  | pad   | domid         |
++-------+-------+---------------+
 ```
 
-It may also be desirable to state in the protocol specification that
-the `INTRODUCE` operation should not clear the `<gfn>` specified such that
-a `RELEASE` operation followed by an `INTRODUCE` operation form an
-idempotent pair. The current implementation of *C xentored* does this
-(in the `domain_conn_reset()` function) but this could be dropped as this
-behaviour is not currently specified and the page will always be zeroed
-for a newly created domain.
+| Field   | Description                                         |
+|---------|-----------------------------------------------------|
+| `perm`  | One of the ASCII values `w`, `r`, `b` or `n` as     |
+|         | specified for the `SET_PERMS` operation [2]         |
+|         |                                                     |
+| `domid` | The domain-id to which the permission relates       |
 
 
 * * *
 
 [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
+
 [2] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/xenstore.txt
-[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/specs/libxl-migration-stream.pandoc
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 13:50:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 13:50:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRyik-0001HR-HL; Fri, 24 Apr 2020 13:50:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRyij-0001HJ-Vm
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 13:50:22 +0000
X-Inumbo-ID: 892232d2-8632-11ea-94ac-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 892232d2-8632-11ea-94ac-12813bfff9fa;
 Fri, 24 Apr 2020 13:50:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=v/njPgk4dearCeZbqrp9wfzKZUi7pTEmp50HKUUAMAU=; b=7MccT6GNUMbQpdUbVMcXG8830
 /4np94V88Ei9anGNav25B1oRxYZAVufiwQlkqYk7jZmb9KhaLL/rwyto7DxImtbvxDB7IzdELfmNi
 H+wIo9xg6uO9Hx0ZzuBckQCb4XFApq9ppGTnvUdXqeLwlPPtVOC5c8CRf7W6O/9HIX7rc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRyig-00018x-Th; Fri, 24 Apr 2020 13:50:18 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRyig-0004pJ-J8; Fri, 24 Apr 2020 13:50:18 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRyig-00020z-Hk; Fri, 24 Apr 2020 13:50:18 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149782-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [examine test] 149782: tolerable trouble: pass/starved
X-Osstest-Failures: examine:examine-albana1:memdisk-try-append:fail:nonblocking
 examine:examine-albana0:memdisk-try-append:fail:nonblocking
 examine:examine-elbling0:hosts-allocate:starved:nonblocking
 examine:examine-rochester0:hosts-allocate:starved:nonblocking
 examine:examine-debina0:hosts-allocate:starved:nonblocking
 examine:examine-godello0:hosts-allocate:starved:nonblocking
X-Osstest-Versions-That: flight=149768
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 13:50:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149782 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149782/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 examine-albana1               4 memdisk-try-append      fail blocked in 149768
 examine-albana0               4 memdisk-try-append      fail blocked in 149768
 examine-elbling0              2 hosts-allocate               starved  n/a
 examine-rochester0            2 hosts-allocate               starved  n/a
 examine-debina0               2 hosts-allocate               starved  n/a
 examine-godello0              2 hosts-allocate               starved  n/a

baseline version:
 flight               149768

jobs:
 examine-albana0                                              pass    
 examine-albana1                                              pass    
 examine-arndale-bluewater                                    pass    
 examine-cubietruck-braque                                    pass    
 examine-chardonnay0                                          pass    
 examine-chardonnay1                                          pass    
 examine-debina0                                              starved 
 examine-debina1                                              pass    
 examine-elbling0                                             starved 
 examine-elbling1                                             pass    
 examine-fiano0                                               pass    
 examine-fiano1                                               pass    
 examine-cubietruck-gleizes                                   pass    
 examine-godello0                                             starved 
 examine-godello1                                             pass    
 examine-huxelrebe0                                           pass    
 examine-huxelrebe1                                           pass    
 examine-italia0                                              pass    
 examine-arndale-lakeside                                     pass    
 examine-laxton0                                              pass    
 examine-laxton1                                              pass    
 examine-arndale-metrocentre                                  pass    
 examine-cubietruck-metzinger                                 pass    
 examine-cubietruck-picasso                                   pass    
 examine-pinot0                                               pass    
 examine-pinot1                                               pass    
 examine-rimava1                                              pass    
 examine-rochester0                                           starved 
 examine-rochester1                                           pass    
 examine-arndale-westfield                                    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


Push not applicable.



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 13:58:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 13:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRyqm-0001Wd-D2; Fri, 24 Apr 2020 13:58:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jRyql-0001WY-FF
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 13:58:39 +0000
X-Inumbo-ID: b1e4c88c-8633-11ea-94af-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b1e4c88c-8633-11ea-94af-12813bfff9fa;
 Fri, 24 Apr 2020 13:58:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=XIXqkuVjZvrbc8I8jvCC3CDFzOGWofH1/hN210+VV2I=; b=H/8xHGAy4YreS9Pv+4swDhvex
 zJTKYIu3JTlPBshpRIeL1DM9MbjlNzOqP9npWsIHgZNarf81GQUaE/JXrPPc1apKV9Q/uXEQbQWOa
 jnzcy068Modq5tIqYsAE0AN2XkexxKCP48OZGQ2Gtl2JFlTxqLzevhebTHJo8gF6SZBm4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRyqj-0001Ky-8w; Fri, 24 Apr 2020 13:58:37 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jRyqj-000531-0h; Fri, 24 Apr 2020 13:58:37 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jRyqi-0005jH-WF; Fri, 24 Apr 2020 13:58:36 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149771-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149771: tolerable trouble: fail/pass/starved -
 PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 xen-unstable:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: xen=aa14feb6723d3bb15a884533ade1cd9732792145
X-Osstest-Versions-That: xen=a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 13:58:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149771 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149771/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149741
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149741
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149741
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149741
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149752
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149752
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149752
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149752
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149752
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149752
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate               starved  n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate               starved  n/a

version targeted for testing:
 xen                  aa14feb6723d3bb15a884533ade1cd9732792145
baseline version:
 xen                  a62c6fe05c4ae905b7d4cb0ca946508b7f96d522

Last test of basis   149752  2020-04-23 10:22:34 Z    1 days
Testing same since   149771  2020-04-23 22:06:56 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  George Dunlap <george.dunlap@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Nick Rosbrook <rosbrookn@ainfosec.com>
  Nick Rosbrook <rosbrookn@gmail.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                starved 
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 starved 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   a62c6fe05c..aa14feb672  aa14feb6723d3bb15a884533ade1cd9732792145 -> master


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:07:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRyzB-0002fz-25; Fri, 24 Apr 2020 14:07:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Spwv=6I=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jRyz9-0002fu-Ni
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:07:19 +0000
X-Inumbo-ID: e87e1ec4-8634-11ea-b58d-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e87e1ec4-8634-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 14:07:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587737238;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=tdCk5NXIzJ3aa4ezT7t27R1n91s1HsX8DnS3V9B1Sco=;
 b=AB48RIToMQinoCCXRwNwIMJl2vWsPeL3O7UKrMkq5OD2nJnbftIdCuAt
 JhNkHg+551kr00Tze2QiTTXLO8ofObtGothzE7/3l29/hYJy17ca/mqe3
 C71jCakMsVJKpgYuUBkkCxeRv9PjTSTEmGh2vW9A20gje/bKW+lo7ZPEl w=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: cey8LrZ7vIdQ0V6oONVijFNET9rKgbRUzpu1sMQQ2nLAWU9yw0TyLnsuJjpk0U+FIzajPLT6gz
 rlClEEsOGsFpgyqGWkUmmnr0KW1EPoN2vpruaDzPErRw33iZobrHLfLemqY1maBd3Itw9mImin
 w7l46ffMc70vfZ6q1wKrM5xI4vXUGBDPxD4wirtMsdEivthQ86UgUSzId6okGFM24zNdFIMzN4
 auVNFo5LUQpZVR1eQXFeMwyI6dnmlQaCNsxTgaKy/fbfxUvnLJoZv7qI9yD+GYWqNT1PzSFjoC
 vgI=
X-SBRS: 2.7
X-MesageID: 16889590
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,311,1583211600"; d="scan'208";a="16889590"
Date: Fri, 24 Apr 2020 15:07:12 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v5 04/16] xen/build: have the root Makefile generates
 the CFLAGS
Message-ID: <20200424140712.GU4088@perard.uk.xensource.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-5-anthony.perard@citrix.com>
 <db4f1e4f-1ffc-522a-4b2f-9eb2315d1acc@suse.com>
 <20200424133053.GT4088@perard.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200424133053.GT4088@perard.uk.xensource.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 24, 2020 at 02:30:56PM +0100, Anthony PERARD wrote:
> On Fri, Apr 24, 2020 at 03:01:32PM +0200, Jan Beulich wrote:
> > While committing this, in my pre-push build test I noticed that
> > presumably an earlier change of yours has caused
> > 
> > Makefile:103: include/config/auto.conf: No such file or directory
> > Makefile:106: include/config/auto.conf.cmd: No such file or directory
> > 
> > for a build in a completely fresh tree.
> 
> Are those presumably "warning" an issue? Are the files still missing
> after make has run? Didn't the build managed to build xen.gz?
> There is maybe a line saying that make will re-execute.
> 
> I've seen those error before, on older version of make. But it's just
> make complaining before even trying to update/create those files. But it
> just create those files and start over.
> 
> Also, that would be patch "build: include include/config/auto.conf in
> main Makefile" which introduce this behavior.

I'll prepare a patch to use "-include" instead of simply "include". That
will silent the warnings and nothing else should change. Linux's Kbuild
doesn't have this issue because we have to run `make menuconfig` or
equivalent which also generates the two auto.conf* files, which I didn't
notice until now.

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz16-0002oY-I1; Fri, 24 Apr 2020 14:09:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz15-0002oS-L6
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:19 +0000
X-Inumbo-ID: 3033ac2a-8635-11ea-94b0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3033ac2a-8635-11ea-94b0-12813bfff9fa;
 Fri, 24 Apr 2020 14:09:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2Hz+zIAfCxPM0WxypIckv61MiBOdRP+edEK4gulwLqM=; b=Y2nrvvAwtn38q+VWzMN05bqF/B
 4O70K9ToA78VoX7w5D6qRG3ZYswzPElLDAEbG2HWblSmOfZVcgk/BgEHldqO9oGYr9zu9YjlV1JEl
 XB/aC3iAJ1bdo9oUfr5zGn/PIge3FEnqsUnpI1pXg90kSxJr1z7N7NN219U3h7Iw1kQg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz14-0001g4-DF; Fri, 24 Apr 2020 14:09:18 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz14-0001fN-18; Fri, 24 Apr 2020 14:09:18 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 00/15] switch to domheap for Xen page tables
Date: Fri, 24 Apr 2020 15:08:51 +0100
Message-Id: <cover.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

This series rewrites all the remaining functions and finally makes the
switch from xenheap to domheap for Xen page tables, so that they no
longer need to rely on the direct map, which is a big step towards
removing the direct map.

This series depends on the following two mini-series:
https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg00730.html
https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg00940.html

Since v1, 9 patches have already been merged. Apart from the first 2
patches in this series, the rest have not seen comments since v1 so they
only contain modifications from my side compared with v1.

---
Changed in v6:
- drop the patches that have already been merged.
- rebase and cleanup.
- rewrite map_pages_to_xen() and modify_xen_mappings() in a way that
  does not require an end_of_loop goto label.

Hongyan Xia (2):
  x86/mm: drop old page table APIs
  x86: switch to use domheap page for page tables

Wei Liu (13):
  x86/mm: map_pages_to_xen would better have one exit path
  x86/mm: make sure there is one exit path for modify_xen_mappings
  x86/mm: rewrite virt_to_xen_l*e
  x86/mm: switch to new APIs in map_pages_to_xen
  x86/mm: switch to new APIs in modify_xen_mappings
  x86_64/mm: introduce pl2e in paging_init
  x86_64/mm: switch to new APIs in paging_init
  x86_64/mm: switch to new APIs in setup_m2p_table
  efi: use new page table APIs in copy_mapping
  efi: switch to new APIs in EFI code
  x86/smpboot: clone_mapping should have one exit path
  x86/smpboot: switch pl*e to use new APIs in clone_mapping
  x86/mm: drop _new suffix for page table APIs

 xen/arch/x86/domain_page.c |  11 +-
 xen/arch/x86/efi/runtime.h |  10 +-
 xen/arch/x86/mm.c          | 262 +++++++++++++++++++++++--------------
 xen/arch/x86/setup.c       |   4 +-
 xen/arch/x86/smpboot.c     |  80 +++++++----
 xen/arch/x86/x86_64/mm.c   |  81 +++++++-----
 xen/common/efi/boot.c      |  60 ++++++---
 xen/common/efi/efi.h       |   3 +-
 xen/common/efi/runtime.c   |   8 +-
 xen/common/vmap.c          |   1 +
 xen/include/asm-x86/mm.h   |   6 +-
 xen/include/asm-x86/page.h |  13 +-
 12 files changed, 339 insertions(+), 200 deletions(-)

-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz19-0002p7-Pd; Fri, 24 Apr 2020 14:09:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz18-0002ou-EI
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:22 +0000
X-Inumbo-ID: 31fde20a-8635-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 31fde20a-8635-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 14:09:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=oqERgF2yFHKDhOM0YC1cTIHrEB14UTlYTe0Bzj5cU0s=; b=LS8ovfLB5o3NZfXfXBXoW4MvI2
 kEBuCOSMUXExf+8V7iVXqmpcK+KU0XX8sSif8H0yHKsJcWWvnEGDEgqalbzMfNffHo2ANrUrA6muF
 CmOCTuTAUpK9RWbTxmLp492RYgvnBe5658SD/7lReX8pnZJnOnvpFhKeYsxAiPOm5+MI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz17-0001gK-EM; Fri, 24 Apr 2020 14:09:21 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz17-0001fN-2g; Fri, 24 Apr 2020 14:09:21 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 02/15] x86/mm: make sure there is one exit path for
 modify_xen_mappings
Date: Fri, 24 Apr 2020 15:08:53 +0100
Message-Id: <18200ef0e71dae402fbca394f653fb57c62a2cb9.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

We will soon need to handle dynamically mapping / unmapping page
tables in the said function. Since dynamic mappings may map and unmap
pl3e in different iterations, lift pl3e out of the loop.

No functional change.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed since v4:
- drop the end_of_loop goto label.

Changed since v3:
- remove asserts on rc since it never gets changed to anything else.
---
 xen/arch/x86/mm.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 0d7f1f1265..13a34a8d57 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5462,10 +5462,12 @@ int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
 {
     bool locking = system_state > SYS_STATE_boot;
+    l3_pgentry_t *pl3e;
     l2_pgentry_t *pl2e;
     l1_pgentry_t *pl1e;
     unsigned int  i;
     unsigned long v = s;
+    int rc = -ENOMEM;
 
     /* Set of valid PTE bits which may be altered. */
 #define FLAGS_MASK (_PAGE_NX|_PAGE_RW|_PAGE_PRESENT)
@@ -5476,7 +5478,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
 
     while ( v < e )
     {
-        l3_pgentry_t *pl3e = virt_to_xen_l3e(v);
+        pl3e = virt_to_xen_l3e(v);
 
         if ( !pl3e || !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
         {
@@ -5509,7 +5511,8 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
             /* PAGE1GB: shatter the superpage and fall through. */
             l2t = alloc_xen_pagetable();
             if ( !l2t )
-                return -ENOMEM;
+                goto out;
+
             for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
                 l2e_write(l2t + i,
                           l2e_from_pfn(l3e_get_pfn(*pl3e) +
@@ -5566,7 +5569,8 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
                 /* PSE: shatter the superpage and try again. */
                 l1t = alloc_xen_pagetable();
                 if ( !l1t )
-                    return -ENOMEM;
+                    goto out;
+
                 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
                     l1e_write(&l1t[i],
                               l1e_from_pfn(l2e_get_pfn(*pl2e) + i,
@@ -5699,7 +5703,10 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
     flush_area(NULL, FLUSH_TLB_GLOBAL);
 
 #undef FLAGS_MASK
-    return 0;
+    rc = 0;
+
+ out:
+    return rc;
 }
 
 #undef flush_area
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz1B-0002pp-2D; Fri, 24 Apr 2020 14:09:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz1A-0002pb-LJ
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:24 +0000
X-Inumbo-ID: 310015c6-8635-11ea-94b0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 310015c6-8635-11ea-94b0-12813bfff9fa;
 Fri, 24 Apr 2020 14:09:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=wuKSH+etKo7Jo0+ZezG3H1XK7TumB7Bc+ci7lGz0PLk=; b=bNL3GNbndE1LgY8gb7b+rytX5a
 CZqOmiD5+qjoarwPnP/ejsBi+JEsFbuD+biyMOifNBtKcx4NNw8eV9tJN6Svhw+1Ygk2H2DIkM4y4
 OfL1z4WErTBNxP4vd6kXpJ/tU8NrWFClBVYpWX85EGxVFiD9I/4abtRckdK8yyHG6Gms=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz15-0001gC-Uk; Fri, 24 Apr 2020 14:09:19 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz15-0001fN-Iw; Fri, 24 Apr 2020 14:09:19 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 01/15] x86/mm: map_pages_to_xen would better have one exit
 path
Date: Fri, 24 Apr 2020 15:08:52 +0100
Message-Id: <65a239b5c283890f83d2e637dbb6d01a673e586b.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

We will soon rewrite the function to handle dynamically mapping and
unmapping of page tables. Since dynamic mappings may map and unmap pages
in different iterations of the while loop, we need to lift pl3e out of
the loop.

No functional change.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed since v4:
- drop the end_of_loop goto label.

Changed since v3:
- remove asserts on rc since rc never gets changed to anything else.
- reword commit message.
---
 xen/arch/x86/mm.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 355c50ff91..0d7f1f1265 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5073,9 +5073,11 @@ int map_pages_to_xen(
     unsigned int flags)
 {
     bool locking = system_state > SYS_STATE_boot;
+    l3_pgentry_t *pl3e, ol3e;
     l2_pgentry_t *pl2e, ol2e;
     l1_pgentry_t *pl1e, ol1e;
     unsigned int  i;
+    int rc = -ENOMEM;
 
 #define flush_flags(oldf) do {                 \
     unsigned int o_ = (oldf);                  \
@@ -5093,10 +5095,11 @@ int map_pages_to_xen(
 
     while ( nr_mfns != 0 )
     {
-        l3_pgentry_t ol3e, *pl3e = virt_to_xen_l3e(virt);
+        pl3e = virt_to_xen_l3e(virt);
 
         if ( !pl3e )
-            return -ENOMEM;
+            goto out;
+
         ol3e = *pl3e;
 
         if ( cpu_has_page1gb &&
@@ -5186,7 +5189,7 @@ int map_pages_to_xen(
 
             l2t = alloc_xen_pagetable();
             if ( l2t == NULL )
-                return -ENOMEM;
+                goto out;
 
             for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
                 l2e_write(l2t + i,
@@ -5215,7 +5218,7 @@ int map_pages_to_xen(
 
         pl2e = virt_to_xen_l2e(virt);
         if ( !pl2e )
-            return -ENOMEM;
+            goto out;
 
         if ( ((((virt >> PAGE_SHIFT) | mfn_x(mfn)) &
                ((1u << PAGETABLE_ORDER) - 1)) == 0) &&
@@ -5259,7 +5262,7 @@ int map_pages_to_xen(
             {
                 pl1e = virt_to_xen_l1e(virt);
                 if ( pl1e == NULL )
-                    return -ENOMEM;
+                    goto out;
             }
             else if ( l2e_get_flags(*pl2e) & _PAGE_PSE )
             {
@@ -5287,7 +5290,7 @@ int map_pages_to_xen(
 
                 l1t = alloc_xen_pagetable();
                 if ( l1t == NULL )
-                    return -ENOMEM;
+                    goto out;
 
                 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
                     l1e_write(&l1t[i],
@@ -5433,7 +5436,10 @@ int map_pages_to_xen(
 
 #undef flush_flags
 
-    return 0;
+    rc = 0;
+
+ out:
+    return rc;
 }
 
 int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz1E-0002rf-CO; Fri, 24 Apr 2020 14:09:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz1D-0002rK-EY
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:27 +0000
X-Inumbo-ID: 331297e4-8635-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 331297e4-8635-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 14:09:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ni2X3IEF9bCOanK+t7F3wzlp0i4MbnPB9Hxj61sNivc=; b=d+Fp4d1aL9GH1b3g4j4+rxL4ta
 TwDbaZHa37u7Cvuv2wcy8UtKJJMDFugu8NFHLAxy/k9CU0SD3KOBeWLqGIouWz6vVQ5eTWGt2fPne
 s/JpPeUmH+d6fXquyu+urRL0yPmmt5TamkuRdRisSkt7w60t+Vt369HR3slwOVysMg3g=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz19-0001gr-F8; Fri, 24 Apr 2020 14:09:23 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz18-0001fN-Vw; Fri, 24 Apr 2020 14:09:23 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 03/15] x86/mm: rewrite virt_to_xen_l*e
Date: Fri, 24 Apr 2020 15:08:54 +0100
Message-Id: <949d2dc54fd7d3230db6a0934d73668a9999eb1a.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Rewrite those functions to use the new APIs. Modify its callers to unmap
the pointer returned.

Note that the change of virt_to_xen_l1e() also requires vmap_to_mfn() to
unmap the page, which requires domain_page.h header in vmap.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/domain_page.c | 11 +++--
 xen/arch/x86/mm.c          | 85 +++++++++++++++++++++++++++-----------
 xen/common/vmap.c          |  1 +
 xen/include/asm-x86/page.h |  8 +++-
 4 files changed, 76 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index dd32712d2f..3a244bb500 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -333,21 +333,24 @@ void unmap_domain_page_global(const void *ptr)
 mfn_t domain_page_map_to_mfn(const void *ptr)
 {
     unsigned long va = (unsigned long)ptr;
-    const l1_pgentry_t *pl1e;
+    l1_pgentry_t l1e;
 
     if ( va >= DIRECTMAP_VIRT_START )
         return _mfn(virt_to_mfn(ptr));
 
     if ( va >= VMAP_VIRT_START && va < VMAP_VIRT_END )
     {
-        pl1e = virt_to_xen_l1e(va);
+        const l1_pgentry_t *pl1e = virt_to_xen_l1e(va);
+
         BUG_ON(!pl1e);
+        l1e = *pl1e;
+        unmap_domain_page(pl1e);
     }
     else
     {
         ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END);
-        pl1e = &__linear_l1_table[l1_linear_offset(va)];
+        l1e = __linear_l1_table[l1_linear_offset(va)];
     }
 
-    return l1e_get_mfn(*pl1e);
+    return l1e_get_mfn(l1e);
 }
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 13a34a8d57..3328d887c4 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4955,6 +4955,10 @@ void free_xen_pagetable_new(mfn_t mfn)
 
 static DEFINE_SPINLOCK(map_pgdir_lock);
 
+/*
+ * For virt_to_xen_lXe() functions, they take a virtual address and return a
+ * pointer to Xen's LX entry. Caller needs to unmap the pointer.
+ */
 static l3_pgentry_t *virt_to_xen_l3e(unsigned long v)
 {
     l4_pgentry_t *pl4e;
@@ -4963,33 +4967,36 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v)
     if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) )
     {
         bool locking = system_state > SYS_STATE_boot;
-        l3_pgentry_t *l3t = alloc_xen_pagetable();
+        l3_pgentry_t *l3t;
+        mfn_t l3mfn = alloc_xen_pagetable_new();
 
-        if ( !l3t )
+        if ( mfn_eq(l3mfn, INVALID_MFN) )
             return NULL;
+        l3t = map_domain_page(l3mfn);
         clear_page(l3t);
+        UNMAP_DOMAIN_PAGE(l3t);
         if ( locking )
             spin_lock(&map_pgdir_lock);
         if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) )
         {
-            l4_pgentry_t l4e = l4e_from_paddr(__pa(l3t), __PAGE_HYPERVISOR);
+            l4_pgentry_t l4e = l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR);
 
             l4e_write(pl4e, l4e);
             efi_update_l4_pgtable(l4_table_offset(v), l4e);
-            l3t = NULL;
+            l3mfn = INVALID_MFN;
         }
         if ( locking )
             spin_unlock(&map_pgdir_lock);
-        if ( l3t )
-            free_xen_pagetable(l3t);
+        free_xen_pagetable_new(l3mfn);
     }
 
-    return l4e_to_l3e(*pl4e) + l3_table_offset(v);
+    return map_l3t_from_l4e(*pl4e) + l3_table_offset(v);
 }
 
 static l2_pgentry_t *virt_to_xen_l2e(unsigned long v)
 {
     l3_pgentry_t *pl3e;
+    l2_pgentry_t *pl2e;
 
     pl3e = virt_to_xen_l3e(v);
     if ( !pl3e )
@@ -4998,31 +5005,40 @@ static l2_pgentry_t *virt_to_xen_l2e(unsigned long v)
     if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
     {
         bool locking = system_state > SYS_STATE_boot;
-        l2_pgentry_t *l2t = alloc_xen_pagetable();
+        l2_pgentry_t *l2t;
+        mfn_t l2mfn = alloc_xen_pagetable_new();
 
-        if ( !l2t )
+        if ( mfn_eq(l2mfn, INVALID_MFN) )
+        {
+            UNMAP_DOMAIN_PAGE(pl3e);
             return NULL;
+        }
+        l2t = map_domain_page(l2mfn);
         clear_page(l2t);
+        UNMAP_DOMAIN_PAGE(l2t);
         if ( locking )
             spin_lock(&map_pgdir_lock);
         if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
         {
-            l3e_write(pl3e, l3e_from_paddr(__pa(l2t), __PAGE_HYPERVISOR));
-            l2t = NULL;
+            l3e_write(pl3e, l3e_from_mfn(l2mfn, __PAGE_HYPERVISOR));
+            l2mfn = INVALID_MFN;
         }
         if ( locking )
             spin_unlock(&map_pgdir_lock);
-        if ( l2t )
-            free_xen_pagetable(l2t);
+        free_xen_pagetable_new(l2mfn);
     }
 
     BUG_ON(l3e_get_flags(*pl3e) & _PAGE_PSE);
-    return l3e_to_l2e(*pl3e) + l2_table_offset(v);
+    pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(v);
+    unmap_domain_page(pl3e);
+
+    return pl2e;
 }
 
 l1_pgentry_t *virt_to_xen_l1e(unsigned long v)
 {
     l2_pgentry_t *pl2e;
+    l1_pgentry_t *pl1e;
 
     pl2e = virt_to_xen_l2e(v);
     if ( !pl2e )
@@ -5031,26 +5047,34 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long v)
     if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
     {
         bool locking = system_state > SYS_STATE_boot;
-        l1_pgentry_t *l1t = alloc_xen_pagetable();
+        l1_pgentry_t *l1t;
+        mfn_t l1mfn = alloc_xen_pagetable_new();
 
-        if ( !l1t )
+        if ( mfn_eq(l1mfn, INVALID_MFN) )
+        {
+            UNMAP_DOMAIN_PAGE(pl2e);
             return NULL;
+        }
+        l1t = map_domain_page(l1mfn);
         clear_page(l1t);
+        UNMAP_DOMAIN_PAGE(l1t);
         if ( locking )
             spin_lock(&map_pgdir_lock);
         if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
         {
-            l2e_write(pl2e, l2e_from_paddr(__pa(l1t), __PAGE_HYPERVISOR));
-            l1t = NULL;
+            l2e_write(pl2e, l2e_from_mfn(l1mfn, __PAGE_HYPERVISOR));
+            l1mfn = INVALID_MFN;
         }
         if ( locking )
             spin_unlock(&map_pgdir_lock);
-        if ( l1t )
-            free_xen_pagetable(l1t);
+        free_xen_pagetable_new(l1mfn);
     }
 
     BUG_ON(l2e_get_flags(*pl2e) & _PAGE_PSE);
-    return l2e_to_l1e(*pl2e) + l1_table_offset(v);
+    pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(v);
+    unmap_domain_page(pl2e);
+
+    return pl1e;
 }
 
 /* Convert to from superpage-mapping flags for map_pages_to_xen(). */
@@ -5073,8 +5097,8 @@ int map_pages_to_xen(
     unsigned int flags)
 {
     bool locking = system_state > SYS_STATE_boot;
-    l3_pgentry_t *pl3e, ol3e;
-    l2_pgentry_t *pl2e, ol2e;
+    l3_pgentry_t *pl3e = NULL, ol3e;
+    l2_pgentry_t *pl2e = NULL, ol2e;
     l1_pgentry_t *pl1e, ol1e;
     unsigned int  i;
     int rc = -ENOMEM;
@@ -5095,6 +5119,10 @@ int map_pages_to_xen(
 
     while ( nr_mfns != 0 )
     {
+        /* Clean up mappings mapped in the previous iteration. */
+        UNMAP_DOMAIN_PAGE(pl3e);
+        UNMAP_DOMAIN_PAGE(pl2e);
+
         pl3e = virt_to_xen_l3e(virt);
 
         if ( !pl3e )
@@ -5260,9 +5288,12 @@ int map_pages_to_xen(
             /* Normal page mapping. */
             if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
             {
+                /* This forces the mapping to be populated. */
                 pl1e = virt_to_xen_l1e(virt);
                 if ( pl1e == NULL )
                     goto out;
+
+                UNMAP_DOMAIN_PAGE(pl1e);
             }
             else if ( l2e_get_flags(*pl2e) & _PAGE_PSE )
             {
@@ -5439,6 +5470,8 @@ int map_pages_to_xen(
     rc = 0;
 
  out:
+    UNMAP_DOMAIN_PAGE(pl2e);
+    UNMAP_DOMAIN_PAGE(pl3e);
     return rc;
 }
 
@@ -5462,7 +5495,7 @@ int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
 {
     bool locking = system_state > SYS_STATE_boot;
-    l3_pgentry_t *pl3e;
+    l3_pgentry_t *pl3e = NULL;
     l2_pgentry_t *pl2e;
     l1_pgentry_t *pl1e;
     unsigned int  i;
@@ -5478,6 +5511,9 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
 
     while ( v < e )
     {
+        /* Clean up mappings mapped in the previous iteration. */
+        UNMAP_DOMAIN_PAGE(pl3e);
+
         pl3e = virt_to_xen_l3e(v);
 
         if ( !pl3e || !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
@@ -5706,6 +5742,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
     rc = 0;
 
  out:
+    UNMAP_DOMAIN_PAGE(pl3e);
     return rc;
 }
 
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index faebc1ddf1..9964ab2096 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -1,6 +1,7 @@
 #ifdef VMAP_VIRT_START
 #include <xen/bitmap.h>
 #include <xen/cache.h>
+#include <xen/domain_page.h>
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/pfn.h>
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index 5acf3d3d5a..8f711f4992 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -291,7 +291,13 @@ void copy_page_sse2(void *, const void *);
 #define pfn_to_paddr(pfn)   __pfn_to_paddr(pfn)
 #define paddr_to_pfn(pa)    __paddr_to_pfn(pa)
 #define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
-#define vmap_to_mfn(va)     _mfn(l1e_get_pfn(*virt_to_xen_l1e((unsigned long)(va))))
+
+#define vmap_to_mfn(va) ({                                                  \
+        const l1_pgentry_t *pl1e_ = virt_to_xen_l1e((unsigned long)(va));   \
+        unsigned long pfn_ = l1e_get_pfn(*pl1e_);                           \
+        unmap_domain_page(pl1e_);                                           \
+        _mfn(pfn_); })
+
 #define vmap_to_page(va)    mfn_to_page(vmap_to_mfn(va))
 
 #endif /* !defined(__ASSEMBLY__) */
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz1G-0002sh-LW; Fri, 24 Apr 2020 14:09:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz1F-0002sM-LJ
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:29 +0000
X-Inumbo-ID: 342a1012-8635-11ea-94b0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 342a1012-8635-11ea-94b0-12813bfff9fa;
 Fri, 24 Apr 2020 14:09:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=BvaGecZYLh8fva2MaUDmevLZoDzUJ3x7rJ02UJL3eh0=; b=yZOmjzxk54E+5o6w8mGOwIXU2N
 gQZytQ/IR8lt2CcNimBMkA+YEIYfQq4BS1oDOdmK+Wg5weRqaXP00KF7CvmOL3GRnwTQjhamqeZTQ
 rs2EjW58S+LDHSP0US51B+VqPokHcvIvMeGPMvsPq4Fm/xbnDNoLs/38HkDFaJztJmak=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz1B-0001gx-30; Fri, 24 Apr 2020 14:09:25 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1A-0001fN-Ko; Fri, 24 Apr 2020 14:09:25 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 04/15] x86/mm: switch to new APIs in map_pages_to_xen
Date: Fri, 24 Apr 2020 15:08:55 +0100
Message-Id: <8ad392497076eb440cd2d620eefda0f0199ddaea.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Page tables allocated in that function should be mapped and unmapped
now.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/mm.c | 60 ++++++++++++++++++++++++++++-------------------
 1 file changed, 36 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 3328d887c4..2c14cdd83a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5151,7 +5151,7 @@ int map_pages_to_xen(
                 }
                 else
                 {
-                    l2_pgentry_t *l2t = l3e_to_l2e(ol3e);
+                    l2_pgentry_t *l2t = map_l2t_from_l3e(ol3e);
 
                     for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
                     {
@@ -5163,10 +5163,11 @@ int map_pages_to_xen(
                         else
                         {
                             unsigned int j;
-                            const l1_pgentry_t *l1t = l2e_to_l1e(ol2e);
+                            const l1_pgentry_t *l1t = map_l1t_from_l2e(ol2e);
 
                             for ( j = 0; j < L1_PAGETABLE_ENTRIES; j++ )
                                 flush_flags(l1e_get_flags(l1t[j]));
+                            unmap_domain_page(l1t);
                         }
                     }
                     flush_area(virt, flush_flags);
@@ -5175,9 +5176,10 @@ int map_pages_to_xen(
                         ol2e = l2t[i];
                         if ( (l2e_get_flags(ol2e) & _PAGE_PRESENT) &&
                              !(l2e_get_flags(ol2e) & _PAGE_PSE) )
-                            free_xen_pagetable(l2e_to_l1e(ol2e));
+                            free_xen_pagetable_new(l2e_get_mfn(ol2e));
                     }
-                    free_xen_pagetable(l2t);
+                    unmap_domain_page(l2t);
+                    free_xen_pagetable_new(l3e_get_mfn(ol3e));
                 }
             }
 
@@ -5194,6 +5196,7 @@ int map_pages_to_xen(
             unsigned int flush_flags =
                 FLUSH_TLB | FLUSH_ORDER(2 * PAGETABLE_ORDER);
             l2_pgentry_t *l2t;
+            mfn_t l2mfn;
 
             /* Skip this PTE if there is no change. */
             if ( ((l3e_get_pfn(ol3e) & ~(L2_PAGETABLE_ENTRIES *
@@ -5215,15 +5218,17 @@ int map_pages_to_xen(
                 continue;
             }
 
-            l2t = alloc_xen_pagetable();
-            if ( l2t == NULL )
+            l2mfn = alloc_xen_pagetable_new();
+            if ( mfn_eq(l2mfn, INVALID_MFN) )
                 goto out;
 
+            l2t = map_domain_page(l2mfn);
             for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
                 l2e_write(l2t + i,
                           l2e_from_pfn(l3e_get_pfn(ol3e) +
                                        (i << PAGETABLE_ORDER),
                                        l3e_get_flags(ol3e)));
+            UNMAP_DOMAIN_PAGE(l2t);
 
             if ( l3e_get_flags(ol3e) & _PAGE_GLOBAL )
                 flush_flags |= FLUSH_TLB_GLOBAL;
@@ -5233,15 +5238,15 @@ int map_pages_to_xen(
             if ( (l3e_get_flags(*pl3e) & _PAGE_PRESENT) &&
                  (l3e_get_flags(*pl3e) & _PAGE_PSE) )
             {
-                l3e_write_atomic(pl3e, l3e_from_mfn(virt_to_mfn(l2t),
-                                                    __PAGE_HYPERVISOR));
-                l2t = NULL;
+                l3e_write_atomic(pl3e,
+                                 l3e_from_mfn(l2mfn, __PAGE_HYPERVISOR));
+                l2mfn = INVALID_MFN;
             }
             if ( locking )
                 spin_unlock(&map_pgdir_lock);
             flush_area(virt, flush_flags);
-            if ( l2t )
-                free_xen_pagetable(l2t);
+
+            free_xen_pagetable_new(l2mfn);
         }
 
         pl2e = virt_to_xen_l2e(virt);
@@ -5269,12 +5274,13 @@ int map_pages_to_xen(
                 }
                 else
                 {
-                    l1_pgentry_t *l1t = l2e_to_l1e(ol2e);
+                    l1_pgentry_t *l1t = map_l1t_from_l2e(ol2e);
 
                     for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
                         flush_flags(l1e_get_flags(l1t[i]));
                     flush_area(virt, flush_flags);
-                    free_xen_pagetable(l1t);
+                    unmap_domain_page(l1t);
+                    free_xen_pagetable_new(l2e_get_mfn(ol2e));
                 }
             }
 
@@ -5300,6 +5306,7 @@ int map_pages_to_xen(
                 unsigned int flush_flags =
                     FLUSH_TLB | FLUSH_ORDER(PAGETABLE_ORDER);
                 l1_pgentry_t *l1t;
+                mfn_t l1mfn;
 
                 /* Skip this PTE if there is no change. */
                 if ( (((l2e_get_pfn(*pl2e) & ~(L1_PAGETABLE_ENTRIES - 1)) +
@@ -5319,14 +5326,16 @@ int map_pages_to_xen(
                     goto check_l3;
                 }
 
-                l1t = alloc_xen_pagetable();
-                if ( l1t == NULL )
+                l1mfn = alloc_xen_pagetable_new();
+                if ( mfn_eq(l1mfn, INVALID_MFN) )
                     goto out;
 
+                l1t = map_domain_page(l1mfn);
                 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
                     l1e_write(&l1t[i],
                               l1e_from_pfn(l2e_get_pfn(*pl2e) + i,
                                            lNf_to_l1f(l2e_get_flags(*pl2e))));
+                UNMAP_DOMAIN_PAGE(l1t);
 
                 if ( l2e_get_flags(*pl2e) & _PAGE_GLOBAL )
                     flush_flags |= FLUSH_TLB_GLOBAL;
@@ -5336,20 +5345,21 @@ int map_pages_to_xen(
                 if ( (l2e_get_flags(*pl2e) & _PAGE_PRESENT) &&
                      (l2e_get_flags(*pl2e) & _PAGE_PSE) )
                 {
-                    l2e_write_atomic(pl2e, l2e_from_mfn(virt_to_mfn(l1t),
+                    l2e_write_atomic(pl2e, l2e_from_mfn(l1mfn,
                                                         __PAGE_HYPERVISOR));
-                    l1t = NULL;
+                    l1mfn = INVALID_MFN;
                 }
                 if ( locking )
                     spin_unlock(&map_pgdir_lock);
                 flush_area(virt, flush_flags);
-                if ( l1t )
-                    free_xen_pagetable(l1t);
+
+                free_xen_pagetable_new(l1mfn);
             }
 
-            pl1e  = l2e_to_l1e(*pl2e) + l1_table_offset(virt);
+            pl1e  = map_l1t_from_l2e(*pl2e) + l1_table_offset(virt);
             ol1e  = *pl1e;
             l1e_write_atomic(pl1e, l1e_from_mfn(mfn, flags));
+            UNMAP_DOMAIN_PAGE(pl1e);
             if ( (l1e_get_flags(ol1e) & _PAGE_PRESENT) )
             {
                 unsigned int flush_flags = FLUSH_TLB | FLUSH_ORDER(0);
@@ -5393,12 +5403,13 @@ int map_pages_to_xen(
                     goto check_l3;
                 }
 
-                l1t = l2e_to_l1e(ol2e);
+                l1t = map_l1t_from_l2e(ol2e);
                 base_mfn = l1e_get_pfn(l1t[0]) & ~(L1_PAGETABLE_ENTRIES - 1);
                 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
                     if ( (l1e_get_pfn(l1t[i]) != (base_mfn + i)) ||
                          (l1e_get_flags(l1t[i]) != flags) )
                         break;
+                UNMAP_DOMAIN_PAGE(l1t);
                 if ( i == L1_PAGETABLE_ENTRIES )
                 {
                     l2e_write_atomic(pl2e, l2e_from_pfn(base_mfn,
@@ -5408,7 +5419,7 @@ int map_pages_to_xen(
                     flush_area(virt - PAGE_SIZE,
                                FLUSH_TLB_GLOBAL |
                                FLUSH_ORDER(PAGETABLE_ORDER));
-                    free_xen_pagetable(l2e_to_l1e(ol2e));
+                    free_xen_pagetable_new(l2e_get_mfn(ol2e));
                 }
                 else if ( locking )
                     spin_unlock(&map_pgdir_lock);
@@ -5441,7 +5452,7 @@ int map_pages_to_xen(
                 continue;
             }
 
-            l2t = l3e_to_l2e(ol3e);
+            l2t = map_l2t_from_l3e(ol3e);
             base_mfn = l2e_get_pfn(l2t[0]) & ~(L2_PAGETABLE_ENTRIES *
                                               L1_PAGETABLE_ENTRIES - 1);
             for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
@@ -5449,6 +5460,7 @@ int map_pages_to_xen(
                       (base_mfn + (i << PAGETABLE_ORDER))) ||
                      (l2e_get_flags(l2t[i]) != l1f_to_lNf(flags)) )
                     break;
+            UNMAP_DOMAIN_PAGE(l2t);
             if ( i == L2_PAGETABLE_ENTRIES )
             {
                 l3e_write_atomic(pl3e, l3e_from_pfn(base_mfn,
@@ -5458,7 +5470,7 @@ int map_pages_to_xen(
                 flush_area(virt - PAGE_SIZE,
                            FLUSH_TLB_GLOBAL |
                            FLUSH_ORDER(2*PAGETABLE_ORDER));
-                free_xen_pagetable(l3e_to_l2e(ol3e));
+                free_xen_pagetable_new(l3e_get_mfn(ol3e));
             }
             else if ( locking )
                 spin_unlock(&map_pgdir_lock);
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz1K-0002v5-2f; Fri, 24 Apr 2020 14:09:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz1I-0002uC-Eb
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:32 +0000
X-Inumbo-ID: 36be5180-8635-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 36be5180-8635-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 14:09:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=pNeKcQtUM57uOSxhr17X7t4TrlXzvDK3eAw9hbi5PGY=; b=RFo4KtVx84sLcuT1KPnVt7fXiA
 bMcFW8macFJG+R0MrV9ZLOvQoZt18IV5I6U+ngAIq9+lBVvFzO3tTMmtkTwEJYoyR3ILZTZkCMoH6
 Lcxf9h5T1lOZpsIY708/af3w89znPxI7mOI0ZuWfhp+Fi8gdl9F/L/lK9lEwvDpTT6tU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz1F-0001hM-LM; Fri, 24 Apr 2020 14:09:29 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1F-0001fN-BV; Fri, 24 Apr 2020 14:09:29 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 07/15] x86_64/mm: switch to new APIs in paging_init
Date: Fri, 24 Apr 2020 15:08:58 +0100
Message-Id: <0655cc2d3dc27141ef102076c4ad390a37191b37.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Map and unmap pages instead of relying on the direct map.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/x86_64/mm.c | 43 ++++++++++++++++++++++++++++------------
 1 file changed, 30 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 35f9de4ad4..3cf699d27b 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -478,9 +478,10 @@ void __init paging_init(void)
 {
     unsigned long i, mpt_size, va;
     unsigned int n, memflags;
-    l3_pgentry_t *l3_ro_mpt;
+    l3_pgentry_t *l3_ro_mpt = NULL;
     l2_pgentry_t *pl2e = NULL, *l2_ro_mpt = NULL;
     struct page_info *l1_pg;
+    mfn_t l3_ro_mpt_mfn, l2_ro_mpt_mfn;
 
     /*
      * We setup the L3s for 1:1 mapping if host support memory hotplug
@@ -493,22 +494,28 @@ void __init paging_init(void)
         if ( !(l4e_get_flags(idle_pg_table[l4_table_offset(va)]) &
               _PAGE_PRESENT) )
         {
-            l3_pgentry_t *pl3t = alloc_xen_pagetable();
+            l3_pgentry_t *pl3t;
+            mfn_t l3mfn = alloc_xen_pagetable_new();
 
-            if ( !pl3t )
+            if ( mfn_eq(l3mfn, INVALID_MFN) )
                 goto nomem;
+
+            pl3t = map_domain_page(l3mfn);
             clear_page(pl3t);
             l4e_write(&idle_pg_table[l4_table_offset(va)],
-                      l4e_from_paddr(__pa(pl3t), __PAGE_HYPERVISOR_RW));
+                      l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR_RW));
+            unmap_domain_page(pl3t);
         }
     }
 
     /* Create user-accessible L2 directory to map the MPT for guests. */
-    if ( (l3_ro_mpt = alloc_xen_pagetable()) == NULL )
+    l3_ro_mpt_mfn = alloc_xen_pagetable_new();
+    if ( mfn_eq(l3_ro_mpt_mfn, INVALID_MFN) )
         goto nomem;
+    l3_ro_mpt = map_domain_page(l3_ro_mpt_mfn);
     clear_page(l3_ro_mpt);
     l4e_write(&idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)],
-              l4e_from_paddr(__pa(l3_ro_mpt), __PAGE_HYPERVISOR_RO | _PAGE_USER));
+              l4e_from_mfn(l3_ro_mpt_mfn, __PAGE_HYPERVISOR_RO | _PAGE_USER));
 
     /*
      * Allocate and map the machine-to-phys table.
@@ -591,12 +598,17 @@ void __init paging_init(void)
         }
         if ( !((unsigned long)pl2e & ~PAGE_MASK) )
         {
-            if ( (l2_ro_mpt = alloc_xen_pagetable()) == NULL )
+            UNMAP_DOMAIN_PAGE(l2_ro_mpt);
+
+            l2_ro_mpt_mfn = alloc_xen_pagetable_new();
+            if ( mfn_eq(l2_ro_mpt_mfn, INVALID_MFN) )
                 goto nomem;
+
+            l2_ro_mpt = map_domain_page(l2_ro_mpt_mfn);
             clear_page(l2_ro_mpt);
             l3e_write(&l3_ro_mpt[l3_table_offset(va)],
-                      l3e_from_paddr(__pa(l2_ro_mpt),
-                                     __PAGE_HYPERVISOR_RO | _PAGE_USER));
+                      l3e_from_mfn(l2_ro_mpt_mfn,
+                                   __PAGE_HYPERVISOR_RO | _PAGE_USER));
             pl2e = l2_ro_mpt;
             ASSERT(!l2_table_offset(va));
         }
@@ -608,13 +620,16 @@ void __init paging_init(void)
     }
 #undef CNT
 #undef MFN
+    UNMAP_DOMAIN_PAGE(l2_ro_mpt);
+    UNMAP_DOMAIN_PAGE(l3_ro_mpt);
 
     /* Create user-accessible L2 directory to map the MPT for compat guests. */
-    if ( (l2_ro_mpt = alloc_xen_pagetable()) == NULL )
+    l2_ro_mpt_mfn = alloc_xen_pagetable_new();
+    if ( mfn_eq(l2_ro_mpt_mfn, INVALID_MFN) )
         goto nomem;
-    compat_idle_pg_table_l2 = l2_ro_mpt;
-    clear_page(l2_ro_mpt);
-    pl2e = l2_ro_mpt;
+    compat_idle_pg_table_l2 = map_domain_page_global(l2_ro_mpt_mfn);
+    clear_page(compat_idle_pg_table_l2);
+    pl2e = compat_idle_pg_table_l2;
     /* Allocate and map the compatibility mode machine-to-phys table. */
     mpt_size = (mpt_size >> 1) + (1UL << (L2_PAGETABLE_SHIFT - 1));
     if ( mpt_size > RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START )
@@ -662,6 +677,8 @@ void __init paging_init(void)
     return;
 
  nomem:
+    UNMAP_DOMAIN_PAGE(l2_ro_mpt);
+    UNMAP_DOMAIN_PAGE(l3_ro_mpt);
     panic("Not enough memory for m2p table\n");
 }
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz1L-0002w7-Bh; Fri, 24 Apr 2020 14:09:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz1K-0002vb-LV
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:34 +0000
X-Inumbo-ID: 347823c5-8635-11ea-94b0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 347823c5-8635-11ea-94b0-12813bfff9fa;
 Fri, 24 Apr 2020 14:09:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=FRP5OT+p4pAgqXJ05UtHfE6HCl9wkp96YVneT3eOIa0=; b=uL8nkwnXd7QcfXGekCDou49Vil
 qwk/Lpqf50CRF7R4JN7hWqvBzc20bRiwggy4XvydDZfsMEykPhlChcrWAM9NvN1GvFZ+3Y2GOC6mF
 DY8UKpELidiG+g9d6d/g+EFgW1oL7ajCM5uhp2n5kcoyIUMbOfNsuhyr6rHBczpCusnE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz1C-0001h4-JN; Fri, 24 Apr 2020 14:09:26 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1C-0001fN-9b; Fri, 24 Apr 2020 14:09:26 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 05/15] x86/mm: switch to new APIs in modify_xen_mappings
Date: Fri, 24 Apr 2020 15:08:56 +0100
Message-Id: <872b8f71cd391bc78933e9c018baab0b79b34c94.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Page tables allocated in that function should be mapped and unmapped
now.

Note that pl2e now maybe mapped and unmapped in different iterations, so
we need to add clean-ups for that.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/mm.c | 57 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 36 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 2c14cdd83a..e8c16027d8 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5508,7 +5508,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
 {
     bool locking = system_state > SYS_STATE_boot;
     l3_pgentry_t *pl3e = NULL;
-    l2_pgentry_t *pl2e;
+    l2_pgentry_t *pl2e = NULL;
     l1_pgentry_t *pl1e;
     unsigned int  i;
     unsigned long v = s;
@@ -5524,6 +5524,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
     while ( v < e )
     {
         /* Clean up mappings mapped in the previous iteration. */
+        UNMAP_DOMAIN_PAGE(pl2e);
         UNMAP_DOMAIN_PAGE(pl3e);
 
         pl3e = virt_to_xen_l3e(v);
@@ -5541,6 +5542,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
         if ( l3e_get_flags(*pl3e) & _PAGE_PSE )
         {
             l2_pgentry_t *l2t;
+            mfn_t l2mfn;
 
             if ( l2_table_offset(v) == 0 &&
                  l1_table_offset(v) == 0 &&
@@ -5557,35 +5559,38 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
             }
 
             /* PAGE1GB: shatter the superpage and fall through. */
-            l2t = alloc_xen_pagetable();
-            if ( !l2t )
+            l2mfn = alloc_xen_pagetable_new();
+            if ( mfn_eq(l2mfn, INVALID_MFN) )
                 goto out;
 
+            l2t = map_domain_page(l2mfn);
             for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
                 l2e_write(l2t + i,
                           l2e_from_pfn(l3e_get_pfn(*pl3e) +
                                        (i << PAGETABLE_ORDER),
                                        l3e_get_flags(*pl3e)));
+            UNMAP_DOMAIN_PAGE(l2t);
+
             if ( locking )
                 spin_lock(&map_pgdir_lock);
             if ( (l3e_get_flags(*pl3e) & _PAGE_PRESENT) &&
                  (l3e_get_flags(*pl3e) & _PAGE_PSE) )
             {
-                l3e_write_atomic(pl3e, l3e_from_mfn(virt_to_mfn(l2t),
-                                                    __PAGE_HYPERVISOR));
-                l2t = NULL;
+                l3e_write_atomic(pl3e,
+                                 l3e_from_mfn(l2mfn, __PAGE_HYPERVISOR));
+                l2mfn = INVALID_MFN;
             }
             if ( locking )
                 spin_unlock(&map_pgdir_lock);
-            if ( l2t )
-                free_xen_pagetable(l2t);
+
+            free_xen_pagetable_new(l2mfn);
         }
 
         /*
          * The L3 entry has been verified to be present, and we've dealt with
          * 1G pages as well, so the L2 table cannot require allocation.
          */
-        pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(v);
+        pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(v);
 
         if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
         {
@@ -5613,41 +5618,45 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
             else
             {
                 l1_pgentry_t *l1t;
-
                 /* PSE: shatter the superpage and try again. */
-                l1t = alloc_xen_pagetable();
-                if ( !l1t )
+                mfn_t l1mfn = alloc_xen_pagetable_new();
+
+                if ( mfn_eq(l1mfn, INVALID_MFN) )
                     goto out;
 
+                l1t = map_domain_page(l1mfn);
                 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
                     l1e_write(&l1t[i],
                               l1e_from_pfn(l2e_get_pfn(*pl2e) + i,
                                            l2e_get_flags(*pl2e) & ~_PAGE_PSE));
+                UNMAP_DOMAIN_PAGE(l1t);
+
                 if ( locking )
                     spin_lock(&map_pgdir_lock);
                 if ( (l2e_get_flags(*pl2e) & _PAGE_PRESENT) &&
                      (l2e_get_flags(*pl2e) & _PAGE_PSE) )
                 {
-                    l2e_write_atomic(pl2e, l2e_from_mfn(virt_to_mfn(l1t),
+                    l2e_write_atomic(pl2e, l2e_from_mfn(l1mfn,
                                                         __PAGE_HYPERVISOR));
-                    l1t = NULL;
+                    l1mfn = INVALID_MFN;
                 }
                 if ( locking )
                     spin_unlock(&map_pgdir_lock);
-                if ( l1t )
-                    free_xen_pagetable(l1t);
+
+                free_xen_pagetable_new(l1mfn);
             }
         }
         else
         {
             l1_pgentry_t nl1e, *l1t;
+            mfn_t l1mfn;
 
             /*
              * Ordinary 4kB mapping: The L2 entry has been verified to be
              * present, and we've dealt with 2M pages as well, so the L1 table
              * cannot require allocation.
              */
-            pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(v);
+            pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(v);
 
             /* Confirm the caller isn't trying to create new mappings. */
             if ( !(l1e_get_flags(*pl1e) & _PAGE_PRESENT) )
@@ -5658,6 +5667,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
                                (l1e_get_flags(*pl1e) & ~FLAGS_MASK) | nf);
 
             l1e_write_atomic(pl1e, nl1e);
+            UNMAP_DOMAIN_PAGE(pl1e);
             v += PAGE_SIZE;
 
             /*
@@ -5687,10 +5697,12 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
                 continue;
             }
 
-            l1t = l2e_to_l1e(*pl2e);
+            l1mfn = l2e_get_mfn(*pl2e);
+            l1t = map_domain_page(l1mfn);
             for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
                 if ( l1e_get_intpte(l1t[i]) != 0 )
                     break;
+            UNMAP_DOMAIN_PAGE(l1t);
             if ( i == L1_PAGETABLE_ENTRIES )
             {
                 /* Empty: zap the L2E and free the L1 page. */
@@ -5698,7 +5710,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
                 if ( locking )
                     spin_unlock(&map_pgdir_lock);
                 flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */
-                free_xen_pagetable(l1t);
+                free_xen_pagetable_new(l1mfn);
             }
             else if ( locking )
                 spin_unlock(&map_pgdir_lock);
@@ -5729,11 +5741,13 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
 
         {
             l2_pgentry_t *l2t;
+            mfn_t l2mfn = l3e_get_mfn(*pl3e);
 
-            l2t = l3e_to_l2e(*pl3e);
+            l2t = map_domain_page(l2mfn);
             for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
                 if ( l2e_get_intpte(l2t[i]) != 0 )
                     break;
+            UNMAP_DOMAIN_PAGE(l2t);
             if ( i == L2_PAGETABLE_ENTRIES )
             {
                 /* Empty: zap the L3E and free the L2 page. */
@@ -5741,7 +5755,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
                 if ( locking )
                     spin_unlock(&map_pgdir_lock);
                 flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */
-                free_xen_pagetable(l2t);
+                free_xen_pagetable_new(l2mfn);
             }
             else if ( locking )
                 spin_unlock(&map_pgdir_lock);
@@ -5754,6 +5768,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
     rc = 0;
 
  out:
+    UNMAP_DOMAIN_PAGE(pl2e);
     UNMAP_DOMAIN_PAGE(pl3e);
     return rc;
 }
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz1O-0002yZ-LU; Fri, 24 Apr 2020 14:09:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz1N-0002xq-Eu
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:37 +0000
X-Inumbo-ID: 37a37e36-8635-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 37a37e36-8635-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 14:09:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=fRkSpuClFodnft3WeIOUG75ZUCmfP/WLuHx0luTOIk0=; b=UcF2ZDXTxspxFWqMo8u0pUjDco
 KWijGwEGxYWD5cuD29mhl1j3+gwF7TffeFBF6eB5j529681ajhs1Yz1XXA0sZ6yL7nJsMD1roTDeQ
 I7qO/kbcb708/ZdcGdKOYRc4yvuM9/lQFfD8S1M26YuiI0rMiVnT4aoPnN0is+F/AuMc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz1H-0001hY-77; Fri, 24 Apr 2020 14:09:31 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1G-0001fN-Rd; Fri, 24 Apr 2020 14:09:31 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 08/15] x86_64/mm: switch to new APIs in setup_m2p_table
Date: Fri, 24 Apr 2020 15:08:59 +0100
Message-Id: <a5e7c92fdc538c23f0173bec8e3b026dcf665c11.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Also reduce the scope of l2_ro_mpt as it is only used inside the loop,
and remove two lines of l2_ro_mpt check which serve no purpose.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/x86_64/mm.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 3cf699d27b..12e9dc6eb2 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -379,13 +379,13 @@ static int setup_m2p_table(struct mem_hotadd_info *info)
 {
     unsigned long i, va, smap, emap;
     unsigned int n;
-    l2_pgentry_t *l2_ro_mpt = NULL;
     l3_pgentry_t *l3_ro_mpt = NULL;
     int ret = 0;
 
     ASSERT(l4e_get_flags(idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)])
             & _PAGE_PRESENT);
-    l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
+    l3_ro_mpt = map_l3t_from_l4e(
+                    idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
 
     smap = (info->spfn & (~((1UL << (L2_PAGETABLE_SHIFT - 3)) -1)));
     emap = ((info->epfn + ((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1 )) &
@@ -424,6 +424,7 @@ static int setup_m2p_table(struct mem_hotadd_info *info)
                 break;
         if ( n < CNT )
         {
+            l2_pgentry_t *l2_ro_mpt;
             mfn_t mfn = alloc_hotadd_mfn(info);
 
             ret = map_pages_to_xen(
@@ -440,30 +441,30 @@ static int setup_m2p_table(struct mem_hotadd_info *info)
                   _PAGE_PSE));
             if ( l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
               _PAGE_PRESENT )
-                l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]) +
-                  l2_table_offset(va);
+                l2_ro_mpt = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]);
             else
             {
-                l2_ro_mpt = alloc_xen_pagetable();
-                if ( !l2_ro_mpt )
+                mfn_t l2_ro_mpt_mfn = alloc_xen_pagetable_new();
+
+                if ( mfn_eq(l2_ro_mpt_mfn, INVALID_MFN) )
                 {
                     ret = -ENOMEM;
                     goto error;
                 }
 
+                l2_ro_mpt = map_domain_page(l2_ro_mpt_mfn);
                 clear_page(l2_ro_mpt);
                 l3e_write(&l3_ro_mpt[l3_table_offset(va)],
-                          l3e_from_paddr(__pa(l2_ro_mpt),
-                                         __PAGE_HYPERVISOR_RO | _PAGE_USER));
-                l2_ro_mpt += l2_table_offset(va);
+                          l3e_from_mfn(l2_ro_mpt_mfn,
+                                       __PAGE_HYPERVISOR_RO | _PAGE_USER));
             }
+            l2_ro_mpt += l2_table_offset(va);
 
             /* NB. Cannot be GLOBAL: guest user mode should not see it. */
             l2e_write(l2_ro_mpt, l2e_from_mfn(mfn,
                    /*_PAGE_GLOBAL|*/_PAGE_PSE|_PAGE_USER|_PAGE_PRESENT));
+            unmap_domain_page(l2_ro_mpt);
         }
-        if ( !((unsigned long)l2_ro_mpt & ~PAGE_MASK) )
-            l2_ro_mpt = NULL;
         i += ( 1UL << (L2_PAGETABLE_SHIFT - 3));
     }
 #undef CNT
@@ -471,6 +472,7 @@ static int setup_m2p_table(struct mem_hotadd_info *info)
 
     ret = setup_compat_m2p_table(info);
 error:
+    UNMAP_DOMAIN_PAGE(l3_ro_mpt);
     return ret;
 }
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz1Q-00030I-Vh; Fri, 24 Apr 2020 14:09:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz1P-0002zR-Le
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:39 +0000
X-Inumbo-ID: 35da7c9e-8635-11ea-94b0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 35da7c9e-8635-11ea-94b0-12813bfff9fa;
 Fri, 24 Apr 2020 14:09:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=QEgbzBwJFIRd1ScLggvvofYSSDEx2eZQcbh7hVPo+uI=; b=wZarron7xIIzBW7E+eHmwQVMNa
 ViVyFwLfw3guf+v0i57cFEEtYMQWjHElbIxWjU9f0tDb8zbGioYDKi5QP0Lk3Kx2YaS+E3xSgyXNF
 +tzr9+2UFxZpUt78F9Bw8zgTKMxXhy2yjtzO4U+qLTdnr+TxcpeH0O/YZVSS7v3ntIow=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz1E-0001hB-6c; Fri, 24 Apr 2020 14:09:28 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1D-0001fN-QH; Fri, 24 Apr 2020 14:09:28 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 06/15] x86_64/mm: introduce pl2e in paging_init
Date: Fri, 24 Apr 2020 15:08:57 +0100
Message-Id: <40759ec2fa21e365ad8a59ab0de59b3f7f5fb42a.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Introduce pl2e so that we can use l2_ro_mpt to point to the page table
itself.

No functional change.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/x86_64/mm.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 6557255494..35f9de4ad4 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -479,7 +479,7 @@ void __init paging_init(void)
     unsigned long i, mpt_size, va;
     unsigned int n, memflags;
     l3_pgentry_t *l3_ro_mpt;
-    l2_pgentry_t *l2_ro_mpt = NULL;
+    l2_pgentry_t *pl2e = NULL, *l2_ro_mpt = NULL;
     struct page_info *l1_pg;
 
     /*
@@ -529,7 +529,7 @@ void __init paging_init(void)
             (L2_PAGETABLE_SHIFT - 3 + PAGE_SHIFT)));
 
         if ( cpu_has_page1gb &&
-             !((unsigned long)l2_ro_mpt & ~PAGE_MASK) &&
+             !((unsigned long)pl2e & ~PAGE_MASK) &&
              (mpt_size >> L3_PAGETABLE_SHIFT) > (i >> PAGETABLE_ORDER) )
         {
             unsigned int k, holes;
@@ -589,7 +589,7 @@ void __init paging_init(void)
             memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)),
                    0xFF, 1UL << L2_PAGETABLE_SHIFT);
         }
-        if ( !((unsigned long)l2_ro_mpt & ~PAGE_MASK) )
+        if ( !((unsigned long)pl2e & ~PAGE_MASK) )
         {
             if ( (l2_ro_mpt = alloc_xen_pagetable()) == NULL )
                 goto nomem;
@@ -597,13 +597,14 @@ void __init paging_init(void)
             l3e_write(&l3_ro_mpt[l3_table_offset(va)],
                       l3e_from_paddr(__pa(l2_ro_mpt),
                                      __PAGE_HYPERVISOR_RO | _PAGE_USER));
+            pl2e = l2_ro_mpt;
             ASSERT(!l2_table_offset(va));
         }
         /* NB. Cannot be GLOBAL: guest user mode should not see it. */
         if ( l1_pg )
-            l2e_write(l2_ro_mpt, l2e_from_page(
+            l2e_write(pl2e, l2e_from_page(
                 l1_pg, /*_PAGE_GLOBAL|*/_PAGE_PSE|_PAGE_USER|_PAGE_PRESENT));
-        l2_ro_mpt++;
+        pl2e++;
     }
 #undef CNT
 #undef MFN
@@ -613,6 +614,7 @@ void __init paging_init(void)
         goto nomem;
     compat_idle_pg_table_l2 = l2_ro_mpt;
     clear_page(l2_ro_mpt);
+    pl2e = l2_ro_mpt;
     /* Allocate and map the compatibility mode machine-to-phys table. */
     mpt_size = (mpt_size >> 1) + (1UL << (L2_PAGETABLE_SHIFT - 1));
     if ( mpt_size > RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START )
@@ -625,7 +627,7 @@ void __init paging_init(void)
              sizeof(*compat_machine_to_phys_mapping))
     BUILD_BUG_ON((sizeof(*frame_table) & ~sizeof(*frame_table)) % \
                  sizeof(*compat_machine_to_phys_mapping));
-    for ( i = 0; i < (mpt_size >> L2_PAGETABLE_SHIFT); i++, l2_ro_mpt++ )
+    for ( i = 0; i < (mpt_size >> L2_PAGETABLE_SHIFT); i++, pl2e++ )
     {
         memflags = MEMF_node(phys_to_nid(i <<
             (L2_PAGETABLE_SHIFT - 2 + PAGE_SHIFT)));
@@ -647,7 +649,7 @@ void __init paging_init(void)
                         (i << L2_PAGETABLE_SHIFT)),
                0xFF, 1UL << L2_PAGETABLE_SHIFT);
         /* NB. Cannot be GLOBAL as the ptes get copied into per-VM space. */
-        l2e_write(l2_ro_mpt, l2e_from_page(l1_pg, _PAGE_PSE|_PAGE_PRESENT));
+        l2e_write(pl2e, l2e_from_page(l1_pg, _PAGE_PSE|_PAGE_PRESENT));
     }
 #undef CNT
 #undef MFN
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:09:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRz1T-00032p-Ci; Fri, 24 Apr 2020 14:09:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRz1S-00031w-F9
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:09:42 +0000
X-Inumbo-ID: 385d13f0-8635-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 385d13f0-8635-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 14:09:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=i73GryKu2F55P7dpYQ8AYC2nWGmKgcztTRkoevvtces=; b=ifCSB49tKxVEMTt06aZ/ovgvXd
 t1kpGS79L8/8OmM9hEi/dgd4F9cGlvrTrmvj8P1XtE41DVKzPKukZDFIK7+TWMMHw7CaXksJVBmO6
 MwZ6JX1GW/YZZBV7LR1N9aUar7fp1HCXfx1SU4fjf4xfPACBU270w13b5bcB7iwyc8y0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRz1I-0001he-AR; Fri, 24 Apr 2020 14:09:32 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1H-0001fN-Uj; Fri, 24 Apr 2020 14:09:32 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 09/15] efi: use new page table APIs in copy_mapping
Date: Fri, 24 Apr 2020 15:09:00 +0100
Message-Id: <6c27c79964eb16eba4743515689b9fd7eb3409d1.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

After inspection ARM doesn't have alloc_xen_pagetable so this function
is x86 only, which means it is safe for us to change.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/efi/boot.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index a6f84c945a..8e96ef8de2 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1454,16 +1454,20 @@ static __init void copy_mapping(unsigned long mfn, unsigned long end,
             continue;
         if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) )
         {
-            l3dst = alloc_xen_pagetable();
-            BUG_ON(!l3dst);
+            mfn_t l3mfn = alloc_xen_pagetable_new();
+
+            BUG_ON(mfn_eq(l3mfn, INVALID_MFN));
+            l3dst = map_domain_page(l3mfn);
             clear_page(l3dst);
             efi_l4_pgtable[l4_table_offset(mfn << PAGE_SHIFT)] =
-                l4e_from_paddr(virt_to_maddr(l3dst), __PAGE_HYPERVISOR);
+                l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR);
         }
         else
-            l3dst = l4e_to_l3e(l4e);
-        l3src = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
+            l3dst = map_l3t_from_l4e(l4e);
+        l3src = map_l3t_from_l4e(idle_pg_table[l4_table_offset(va)]);
         l3dst[l3_table_offset(mfn << PAGE_SHIFT)] = l3src[l3_table_offset(va)];
+        unmap_domain_page(l3src);
+        unmap_domain_page(l3dst);
     }
 }
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:20:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzBc-0005CH-La; Fri, 24 Apr 2020 14:20:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRzBb-0005C6-Qx
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:20:11 +0000
X-Inumbo-ID: b48f0997-8636-11ea-94b3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b48f0997-8636-11ea-94b3-12813bfff9fa;
 Fri, 24 Apr 2020 14:20:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=MuoSnDotjegD/IU7znqfvoq0uHwGPTkrgw7f3PEnI1Y=; b=xuA5mu6b8VNL589aA1Dry2Zr7c
 rLLViASjctGpaQ2FWRDrple3fV/d87zRCksnfmo+4OvQymTISmzDNAOdbdLq4BC0H5IDho41Q/hNO
 XZKWeBUqsT70ClXNZYnGxqNZslsJp4oh+XRb2WwX0MmJDtx2qbrlUoKZ6e+uG8FMjH8Q=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRzBa-0001xF-BL; Fri, 24 Apr 2020 14:20:10 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1N-0001fN-Vq; Fri, 24 Apr 2020 14:09:38 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 13/15] x86/mm: drop old page table APIs
Date: Fri, 24 Apr 2020 15:09:04 +0100
Message-Id: <d6a642544c5ce0b975cdab8ad054f7a348f17c8d.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

Two sets of old APIs, alloc/free_xen_pagetable() and lXe_to_lYe(), are
now dropped to avoid the dependency on direct map.

There are two special cases which still have not been re-written into
the new APIs, thus need special treatment:

rpt in smpboot.c cannot use ephemeral mappings yet. The problem is that
rpt is read and written in context switch code, but the mapping
infrastructure is NOT context-switch-safe, meaning we cannot map rpt in
one domain and unmap in another. Before the mapping infrastructure
supports context switches, rpt has to be globally mapped.

Also, lXe_to_lYe() during Xen image relocation cannot be converted into
map/unmap pairs. We cannot hold on to mappings while the mapping
infrastructure is being relocated! It is enough to remove the direct map
in the second e820 pass, so we still use the direct map (<4GiB) in Xen
relocation (which is during the first e820 pass).

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/mm.c          | 14 --------------
 xen/arch/x86/setup.c       |  4 ++--
 xen/arch/x86/smpboot.c     |  4 ++--
 xen/include/asm-x86/mm.h   |  2 --
 xen/include/asm-x86/page.h |  5 -----
 5 files changed, 4 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index e8c16027d8..749b6f23e5 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4913,20 +4913,6 @@ int mmcfg_intercept_write(
     return X86EMUL_OKAY;
 }
 
-void *alloc_xen_pagetable(void)
-{
-    mfn_t mfn = alloc_xen_pagetable_new();
-
-    return mfn_eq(mfn, INVALID_MFN) ? NULL : mfn_to_virt(mfn_x(mfn));
-}
-
-void free_xen_pagetable(void *v)
-{
-    mfn_t mfn = v ? virt_to_mfn(v) : INVALID_MFN;
-
-    free_xen_pagetable_new(mfn);
-}
-
 /*
  * For these PTE APIs, the caller must follow the alloc-map-unmap-free
  * lifecycle, which means explicitly mapping the PTE pages before accessing
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 885919d5c3..c76fbf80dc 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1114,7 +1114,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
                     continue;
                 *pl4e = l4e_from_intpte(l4e_get_intpte(*pl4e) +
                                         xen_phys_start);
-                pl3e = l4e_to_l3e(*pl4e);
+                pl3e = __va(l4e_get_paddr(*pl4e));
                 for ( j = 0; j < L3_PAGETABLE_ENTRIES; j++, pl3e++ )
                 {
                     /* Not present, 1GB mapping, or already relocated? */
@@ -1124,7 +1124,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
                         continue;
                     *pl3e = l3e_from_intpte(l3e_get_intpte(*pl3e) +
                                             xen_phys_start);
-                    pl2e = l3e_to_l2e(*pl3e);
+                    pl2e = __va(l3e_get_paddr(*pl3e));
                     for ( k = 0; k < L2_PAGETABLE_ENTRIES; k++, pl2e++ )
                     {
                         /* Not present, PSE, or already relocated? */
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 0e0ae56c76..71d61794ec 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -815,7 +815,7 @@ static int setup_cpu_root_pgt(unsigned int cpu)
     if ( !opt_xpti_hwdom && !opt_xpti_domu )
         return 0;
 
-    rpt = alloc_xen_pagetable();
+    rpt = alloc_xenheap_page();
     if ( !rpt )
         return -ENOMEM;
 
@@ -919,7 +919,7 @@ static void cleanup_cpu_root_pgt(unsigned int cpu)
         free_xen_pagetable_new(l3mfn);
     }
 
-    free_xen_pagetable(rpt);
+    free_xenheap_page(rpt);
 
     /* Also zap the stub mapping for this CPU. */
     if ( stub_linear )
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index 3d3f9d49ac..cf855b48fd 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -583,8 +583,6 @@ int vcpu_destroy_pagetables(struct vcpu *);
 void *do_page_walk(struct vcpu *v, unsigned long addr);
 
 /* Allocator functions for Xen pagetables. */
-void *alloc_xen_pagetable(void);
-void free_xen_pagetable(void *v);
 mfn_t alloc_xen_pagetable_new(void);
 void free_xen_pagetable_new(mfn_t mfn);
 
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index 8f711f4992..2e3056c08e 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -188,11 +188,6 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, unsigned int flags)
 #define l4e_has_changed(x,y,flags) \
     ( !!(((x).l4 ^ (y).l4) & ((PADDR_MASK&PAGE_MASK)|put_pte_flags(flags))) )
 
-/* Pagetable walking. */
-#define l2e_to_l1e(x)              ((l1_pgentry_t *)__va(l2e_get_paddr(x)))
-#define l3e_to_l2e(x)              ((l2_pgentry_t *)__va(l3e_get_paddr(x)))
-#define l4e_to_l3e(x)              ((l3_pgentry_t *)__va(l4e_get_paddr(x)))
-
 #define map_l1t_from_l2e(x)        (l1_pgentry_t *)map_domain_page(l2e_get_mfn(x))
 #define map_l2t_from_l3e(x)        (l2_pgentry_t *)map_domain_page(l3e_get_mfn(x))
 #define map_l3t_from_l4e(x)        (l3_pgentry_t *)map_domain_page(l4e_get_mfn(x))
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:20:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzBc-0005CB-D7; Fri, 24 Apr 2020 14:20:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRzBb-0005C1-7r
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:20:11 +0000
X-Inumbo-ID: b49af0d0-8636-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b49af0d0-8636-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 14:20:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=rVqrmVsGdg3zpwD9FEpHmV6lLm/2eKe7Noqaodw3sA0=; b=V8FbMqzOcf8cIbYeZPQzZWj/KA
 p7AYo5DE3aekQCANOc1ZUCpiC/yXyRvfKoPVrse5MTGHE3fyfo6EOVHo/gF1gNh8ppSwVS7s5SZbB
 BKZzSSzyZ76nwv41UdueYbSOX1zieiD5sxgDbGC6I/dT8LPLGBJILeSx3JvvTWgwE/u4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRzBa-0001xD-AC; Fri, 24 Apr 2020 14:20:10 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1M-0001fN-FH; Fri, 24 Apr 2020 14:09:36 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 12/15] x86/smpboot: switch pl*e to use new APIs in
 clone_mapping
Date: Fri, 24 Apr 2020 15:09:03 +0100
Message-Id: <a1c29e58a5d40748413e8088ad88ba4319a328d4.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/smpboot.c | 54 +++++++++++++++++++++++++++---------------
 1 file changed, 35 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 5b0e24f925..0e0ae56c76 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -672,9 +672,9 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
 {
     unsigned long linear = (unsigned long)ptr, pfn;
     unsigned int flags;
-    l3_pgentry_t *pl3e;
-    l2_pgentry_t *pl2e;
-    l1_pgentry_t *pl1e;
+    l3_pgentry_t *pl3e = NULL;
+    l2_pgentry_t *pl2e = NULL;
+    l1_pgentry_t *pl1e = NULL;
     int rc = -ENOMEM;
 
     /*
@@ -689,8 +689,8 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
          (linear >= XEN_VIRT_END && linear < DIRECTMAP_VIRT_START) )
         return -EINVAL;
 
-    pl3e = l4e_to_l3e(idle_pg_table[root_table_offset(linear)]) +
-        l3_table_offset(linear);
+    pl3e = map_l3t_from_l4e(idle_pg_table[root_table_offset(linear)]);
+    pl3e += l3_table_offset(linear);
 
     flags = l3e_get_flags(*pl3e);
     ASSERT(flags & _PAGE_PRESENT);
@@ -702,7 +702,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
     }
     else
     {
-        pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(linear);
+        pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(linear);
         flags = l2e_get_flags(*pl2e);
         ASSERT(flags & _PAGE_PRESENT);
         if ( flags & _PAGE_PSE )
@@ -713,7 +713,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
         }
         else
         {
-            pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(linear);
+            pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(linear);
             flags = l1e_get_flags(*pl1e);
             if ( !(flags & _PAGE_PRESENT) )
             {
@@ -724,48 +724,61 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
         }
     }
 
+    UNMAP_DOMAIN_PAGE(pl1e);
+    UNMAP_DOMAIN_PAGE(pl2e);
+    UNMAP_DOMAIN_PAGE(pl3e);
+
     if ( !(root_get_flags(rpt[root_table_offset(linear)]) & _PAGE_PRESENT) )
     {
-        pl3e = alloc_xen_pagetable();
-        if ( !pl3e )
+        mfn_t l3mfn = alloc_xen_pagetable_new();
+
+        if ( mfn_eq(l3mfn, INVALID_MFN) )
             goto out;
+
+        pl3e = map_domain_page(l3mfn);
         clear_page(pl3e);
         l4e_write(&rpt[root_table_offset(linear)],
-                  l4e_from_paddr(__pa(pl3e), __PAGE_HYPERVISOR));
+                  l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR));
     }
     else
-        pl3e = l4e_to_l3e(rpt[root_table_offset(linear)]);
+        pl3e = map_l3t_from_l4e(rpt[root_table_offset(linear)]);
 
     pl3e += l3_table_offset(linear);
 
     if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
     {
-        pl2e = alloc_xen_pagetable();
-        if ( !pl2e )
+        mfn_t l2mfn = alloc_xen_pagetable_new();
+
+        if ( mfn_eq(l2mfn, INVALID_MFN) )
             goto out;
+
+        pl2e = map_domain_page(l2mfn);
         clear_page(pl2e);
-        l3e_write(pl3e, l3e_from_paddr(__pa(pl2e), __PAGE_HYPERVISOR));
+        l3e_write(pl3e, l3e_from_mfn(l2mfn, __PAGE_HYPERVISOR));
     }
     else
     {
         ASSERT(!(l3e_get_flags(*pl3e) & _PAGE_PSE));
-        pl2e = l3e_to_l2e(*pl3e);
+        pl2e = map_l2t_from_l3e(*pl3e);
     }
 
     pl2e += l2_table_offset(linear);
 
     if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
     {
-        pl1e = alloc_xen_pagetable();
-        if ( !pl1e )
+        mfn_t l1mfn = alloc_xen_pagetable_new();
+
+        if ( mfn_eq(l1mfn, INVALID_MFN) )
             goto out;
+
+        pl1e = map_domain_page(l1mfn);
         clear_page(pl1e);
-        l2e_write(pl2e, l2e_from_paddr(__pa(pl1e), __PAGE_HYPERVISOR));
+        l2e_write(pl2e, l2e_from_mfn(l1mfn, __PAGE_HYPERVISOR));
     }
     else
     {
         ASSERT(!(l2e_get_flags(*pl2e) & _PAGE_PSE));
-        pl1e = l2e_to_l1e(*pl2e);
+        pl1e = map_l1t_from_l2e(*pl2e);
     }
 
     pl1e += l1_table_offset(linear);
@@ -781,6 +794,9 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
 
     rc = 0;
  out:
+    UNMAP_DOMAIN_PAGE(pl1e);
+    UNMAP_DOMAIN_PAGE(pl2e);
+    UNMAP_DOMAIN_PAGE(pl3e);
     return rc;
 }
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:20:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzBh-0005Cs-Ur; Fri, 24 Apr 2020 14:20:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRzBg-0005Cb-1p
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:20:16 +0000
X-Inumbo-ID: b4b7478a-8636-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b4b7478a-8636-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 14:20:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=WuHZzCeYG5C/b2g02WeZNMxfNBzADEMLdtqdGqvTvAU=; b=CGmFqXrswBnXEgsEUtJqz1C1Y5
 HUvGO2SmQtdlfTptXzTOW0DFxw44kXES8+86535RR/2O/aXlYD9rOcISb4t7dw5p3rKnglMNNEqoN
 w3dxw24uM2rV+bhCrWRTvJHKX9EdIas5o6vFa2oC/ERqzwNARSgPB/edOticec6jhS9k=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRzBa-0001xB-99; Fri, 24 Apr 2020 14:20:10 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1K-0001fN-VT; Fri, 24 Apr 2020 14:09:35 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 11/15] x86/smpboot: clone_mapping should have one exit path
Date: Fri, 24 Apr 2020 15:09:02 +0100
Message-Id: <7c84de54ad0ae7a2e7c0c36ac7fa43860f8de995.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

We will soon need to clean up page table mappings in the exit path.

No functional change.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/smpboot.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 275ce7661d..5b0e24f925 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -675,6 +675,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
     l3_pgentry_t *pl3e;
     l2_pgentry_t *pl2e;
     l1_pgentry_t *pl1e;
+    int rc = -ENOMEM;
 
     /*
      * Sanity check 'linear'.  We only allow cloning from the Xen virtual
@@ -715,7 +716,10 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
             pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(linear);
             flags = l1e_get_flags(*pl1e);
             if ( !(flags & _PAGE_PRESENT) )
-                return 0;
+            {
+                rc = 0;
+                goto out;
+            }
             pfn = l1e_get_pfn(*pl1e);
         }
     }
@@ -724,7 +728,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
     {
         pl3e = alloc_xen_pagetable();
         if ( !pl3e )
-            return -ENOMEM;
+            goto out;
         clear_page(pl3e);
         l4e_write(&rpt[root_table_offset(linear)],
                   l4e_from_paddr(__pa(pl3e), __PAGE_HYPERVISOR));
@@ -738,7 +742,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
     {
         pl2e = alloc_xen_pagetable();
         if ( !pl2e )
-            return -ENOMEM;
+            goto out;
         clear_page(pl2e);
         l3e_write(pl3e, l3e_from_paddr(__pa(pl2e), __PAGE_HYPERVISOR));
     }
@@ -754,7 +758,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
     {
         pl1e = alloc_xen_pagetable();
         if ( !pl1e )
-            return -ENOMEM;
+            goto out;
         clear_page(pl1e);
         l2e_write(pl2e, l2e_from_paddr(__pa(pl1e), __PAGE_HYPERVISOR));
     }
@@ -775,7 +779,9 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
     else
         l1e_write(pl1e, l1e_from_pfn(pfn, flags));
 
-    return 0;
+    rc = 0;
+ out:
+    return rc;
 }
 
 DEFINE_PER_CPU(root_pgentry_t *, root_pgt);
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:20:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzBi-0005DY-7h; Fri, 24 Apr 2020 14:20:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRzBg-0005Ci-P8
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:20:16 +0000
X-Inumbo-ID: b48f0996-8636-11ea-94b3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b48f0996-8636-11ea-94b3-12813bfff9fa;
 Fri, 24 Apr 2020 14:20:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=beV1du9ph6uMZY01rLgboEpxeFyXrD+9xnH+UQh67O0=; b=1N2DbrFADG5vUIVnUYc+z8LPWW
 +4fwBJid6FLzmIz6h8SixZRB5AJVwC03aLdR+0c4uHNwO3fxAu5I0RKmTmAMphUVW/S3A4ciG323u
 fO09oUoELw3KZXx/2ZYI8/wdi4uzdc45nHtb0r6QiZR5pVR5FgIxDEyG2GngWAhVFAgM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRzBa-0001x9-7D; Fri, 24 Apr 2020 14:20:10 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1P-0001fN-FM; Fri, 24 Apr 2020 14:09:39 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 14/15] x86: switch to use domheap page for page tables
Date: Fri, 24 Apr 2020 15:09:05 +0100
Message-Id: <6cf43a3d1cd3d18c600515b1ead65f41c2996e92.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/mm.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 749b6f23e5..7e212cc3e0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4923,10 +4923,11 @@ mfn_t alloc_xen_pagetable_new(void)
 {
     if ( system_state != SYS_STATE_early_boot )
     {
-        void *ptr = alloc_xenheap_page();
 
-        BUG_ON(!hardware_domain && !ptr);
-        return ptr ? virt_to_mfn(ptr) : INVALID_MFN;
+        struct page_info *pg = alloc_domheap_page(NULL, 0);
+
+        BUG_ON(!hardware_domain && !pg);
+        return pg ? page_to_mfn(pg) : INVALID_MFN;
     }
 
     return alloc_boot_pages(1, 1);
@@ -4936,7 +4937,7 @@ mfn_t alloc_xen_pagetable_new(void)
 void free_xen_pagetable_new(mfn_t mfn)
 {
     if ( system_state != SYS_STATE_early_boot && !mfn_eq(mfn, INVALID_MFN) )
-        free_xenheap_page(mfn_to_virt(mfn_x(mfn)));
+        free_domheap_page(mfn_to_page(mfn));
 }
 
 static DEFINE_SPINLOCK(map_pgdir_lock);
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:20:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzBm-0005FM-He; Fri, 24 Apr 2020 14:20:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRzBl-0005F3-PO
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:20:21 +0000
X-Inumbo-ID: b4c74f4a-8636-11ea-94b3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b4c74f4a-8636-11ea-94b3-12813bfff9fa;
 Fri, 24 Apr 2020 14:20:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=j6haYfYul3hln7GE8AxrUee2uyGJwIwRiYNu/Xr2Q+o=; b=LRZNLjPf6lK2q6BoGoT2L5LM2p
 345gz94VwTNpsaI178Fc1uyE+zfRnNnNxb9xCjfiIGw53UxXgM2FAhHZzfBvcfpRZkVWTOTBy0p5x
 aV16XGyd7D3JCD2zEVwBsXJxlAvFie2V/iubLiaQLlveMNLGt/RAfo70aPP6B/ZWEDHI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRzBa-0001xL-DP; Fri, 24 Apr 2020 14:20:10 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1J-0001fN-EK; Fri, 24 Apr 2020 14:09:33 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 10/15] efi: switch to new APIs in EFI code
Date: Fri, 24 Apr 2020 15:09:01 +0100
Message-Id: <f5fba4470f6d0a6a62e9e2139d6ef260a5c901f9.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/efi/runtime.h | 10 +++++++--
 xen/common/efi/boot.c      | 46 ++++++++++++++++++++++++++------------
 xen/common/efi/efi.h       |  3 ++-
 xen/common/efi/runtime.c   |  8 +++----
 4 files changed, 46 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/efi/runtime.h b/xen/arch/x86/efi/runtime.h
index d9eb8f5c27..d2483645c6 100644
--- a/xen/arch/x86/efi/runtime.h
+++ b/xen/arch/x86/efi/runtime.h
@@ -1,12 +1,18 @@
+#include <xen/domain_page.h>
+#include <xen/mm.h>
 #include <asm/atomic.h>
 #include <asm/mc146818rtc.h>
 
 #ifndef COMPAT
-l4_pgentry_t *__read_mostly efi_l4_pgtable;
+mfn_t __read_mostly efi_l4_mfn = INVALID_MFN_INITIALIZER;
 
 void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e)
 {
-    if ( efi_l4_pgtable )
+    if ( !mfn_eq(efi_l4_mfn, INVALID_MFN) )
+    {
+        l4_pgentry_t *efi_l4_pgtable = map_domain_page(efi_l4_mfn);
         l4e_write(efi_l4_pgtable + l4idx, l4e);
+        unmap_domain_page(efi_l4_pgtable);
+    }
 }
 #endif
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 8e96ef8de2..715217d2a9 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -6,6 +6,7 @@
 #include <xen/compile.h>
 #include <xen/ctype.h>
 #include <xen/dmi.h>
+#include <xen/domain_page.h>
 #include <xen/init.h>
 #include <xen/keyhandler.h>
 #include <xen/lib.h>
@@ -1442,6 +1443,7 @@ static __init void copy_mapping(unsigned long mfn, unsigned long end,
                                                  unsigned long emfn))
 {
     unsigned long next;
+    l4_pgentry_t *efi_l4_pgtable = map_domain_page(efi_l4_mfn);
 
     for ( ; mfn < end; mfn = next )
     {
@@ -1469,6 +1471,8 @@ static __init void copy_mapping(unsigned long mfn, unsigned long end,
         unmap_domain_page(l3src);
         unmap_domain_page(l3dst);
     }
+
+    unmap_domain_page(efi_l4_pgtable);
 }
 
 static bool __init ram_range_valid(unsigned long smfn, unsigned long emfn)
@@ -1489,6 +1493,7 @@ static bool __init rt_range_valid(unsigned long smfn, unsigned long emfn)
 void __init efi_init_memory(void)
 {
     unsigned int i;
+    l4_pgentry_t *efi_l4_pgtable;
     struct rt_extra {
         struct rt_extra *next;
         unsigned long smfn, emfn;
@@ -1603,8 +1608,9 @@ void __init efi_init_memory(void)
      * Set up 1:1 page tables for runtime calls. See SetVirtualAddressMap() in
      * efi_exit_boot().
      */
-    efi_l4_pgtable = alloc_xen_pagetable();
-    BUG_ON(!efi_l4_pgtable);
+    efi_l4_mfn = alloc_xen_pagetable_new();
+    BUG_ON(mfn_eq(efi_l4_mfn, INVALID_MFN));
+    efi_l4_pgtable = map_domain_page(efi_l4_mfn);
     clear_page(efi_l4_pgtable);
 
     copy_mapping(0, max_page, ram_range_valid);
@@ -1637,39 +1643,45 @@ void __init efi_init_memory(void)
 
         if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) )
         {
-            pl3e = alloc_xen_pagetable();
-            BUG_ON(!pl3e);
+            mfn_t l3mfn = alloc_xen_pagetable_new();
+
+            BUG_ON(mfn_eq(l3mfn, INVALID_MFN));
+            pl3e = map_domain_page(l3mfn);
             clear_page(pl3e);
             efi_l4_pgtable[l4_table_offset(addr)] =
-                l4e_from_paddr(virt_to_maddr(pl3e), __PAGE_HYPERVISOR);
+                l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR);
         }
         else
-            pl3e = l4e_to_l3e(l4e);
+            pl3e = map_l3t_from_l4e(l4e);
         pl3e += l3_table_offset(addr);
         if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
         {
-            pl2e = alloc_xen_pagetable();
-            BUG_ON(!pl2e);
+            mfn_t l2mfn = alloc_xen_pagetable_new();
+
+            BUG_ON(mfn_eq(l2mfn, INVALID_MFN));
+            pl2e = map_domain_page(l2mfn);
             clear_page(pl2e);
-            *pl3e = l3e_from_paddr(virt_to_maddr(pl2e), __PAGE_HYPERVISOR);
+            *pl3e = l3e_from_mfn(l2mfn, __PAGE_HYPERVISOR);
         }
         else
         {
             BUG_ON(l3e_get_flags(*pl3e) & _PAGE_PSE);
-            pl2e = l3e_to_l2e(*pl3e);
+            pl2e = map_l2t_from_l3e(*pl3e);
         }
         pl2e += l2_table_offset(addr);
         if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
         {
-            l1t = alloc_xen_pagetable();
-            BUG_ON(!l1t);
+            mfn_t l1mfn = alloc_xen_pagetable_new();
+
+            BUG_ON(mfn_eq(l1mfn, INVALID_MFN));
+            l1t = map_domain_page(l1mfn);
             clear_page(l1t);
-            *pl2e = l2e_from_paddr(virt_to_maddr(l1t), __PAGE_HYPERVISOR);
+            *pl2e = l2e_from_mfn(l1mfn, __PAGE_HYPERVISOR);
         }
         else
         {
             BUG_ON(l2e_get_flags(*pl2e) & _PAGE_PSE);
-            l1t = l2e_to_l1e(*pl2e);
+            l1t = map_l1t_from_l2e(*pl2e);
         }
         for ( i = l1_table_offset(addr);
               i < L1_PAGETABLE_ENTRIES && extra->smfn < extra->emfn;
@@ -1681,11 +1693,17 @@ void __init efi_init_memory(void)
             extra_head = extra->next;
             xfree(extra);
         }
+
+        unmap_domain_page(l1t);
+        unmap_domain_page(pl2e);
+        unmap_domain_page(pl3e);
     }
 
     /* Insert Xen mappings. */
     for ( i = l4_table_offset(HYPERVISOR_VIRT_START);
           i < l4_table_offset(DIRECTMAP_VIRT_END); ++i )
         efi_l4_pgtable[i] = idle_pg_table[i];
+
+    unmap_domain_page(efi_l4_pgtable);
 }
 #endif
diff --git a/xen/common/efi/efi.h b/xen/common/efi/efi.h
index 2e38d05f3d..e364bae3e0 100644
--- a/xen/common/efi/efi.h
+++ b/xen/common/efi/efi.h
@@ -6,6 +6,7 @@
 #include <efi/eficapsule.h>
 #include <efi/efiapi.h>
 #include <xen/efi.h>
+#include <xen/mm.h>
 #include <xen/spinlock.h>
 #include <asm/page.h>
 
@@ -29,7 +30,7 @@ extern UINTN efi_memmap_size, efi_mdesc_size;
 extern void *efi_memmap;
 
 #ifdef CONFIG_X86
-extern l4_pgentry_t *efi_l4_pgtable;
+extern mfn_t efi_l4_mfn;
 #endif
 
 extern const struct efi_pci_rom *efi_pci_roms;
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 95367694b5..375b94229e 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -85,7 +85,7 @@ struct efi_rs_state efi_rs_enter(void)
     static const u32 mxcsr = MXCSR_DEFAULT;
     struct efi_rs_state state = { .cr3 = 0 };
 
-    if ( !efi_l4_pgtable )
+    if ( mfn_eq(efi_l4_mfn, INVALID_MFN) )
         return state;
 
     state.cr3 = read_cr3();
@@ -111,7 +111,7 @@ struct efi_rs_state efi_rs_enter(void)
         lgdt(&gdt_desc);
     }
 
-    switch_cr3_cr4(virt_to_maddr(efi_l4_pgtable), read_cr4());
+    switch_cr3_cr4(mfn_to_maddr(efi_l4_mfn), read_cr4());
 
     return state;
 }
@@ -140,9 +140,9 @@ void efi_rs_leave(struct efi_rs_state *state)
 
 bool efi_rs_using_pgtables(void)
 {
-    return efi_l4_pgtable &&
+    return !mfn_eq(efi_l4_mfn, INVALID_MFN) &&
            (smp_processor_id() == efi_rs_on_cpu) &&
-           (read_cr3() == virt_to_maddr(efi_l4_pgtable));
+           (read_cr3() == mfn_to_maddr(efi_l4_mfn));
 }
 
 unsigned long efi_get_time(void)
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:20:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:20:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzBs-0005Js-0B; Fri, 24 Apr 2020 14:20:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=OF9t=6I=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jRzBq-0005IQ-PR
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:20:26 +0000
X-Inumbo-ID: b4c0268e-8636-11ea-94b3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b4c0268e-8636-11ea-94b3-12813bfff9fa;
 Fri, 24 Apr 2020 14:20:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=o5SnQls1sfBymIOf+4o9qpecybtOaO0mboyyYZ2aKLQ=; b=Hg19jqtVuBc+wGTbHQcBF73XMV
 NwqJi9b8qMUOOywxbAmYS7TBtCOv7xp37h0CLLUb7GGsyz2KTC+KfvBCBn8SQDiAgid+J558maWD9
 +FBLqgWWybabeoSoFW+rHKgsxsShMmkODR+CZvDNDbtvRmMc5PZVC5DWHRdAzTrSL0wA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jRzBa-0001xJ-CN; Fri, 24 Apr 2020 14:20:10 +0000
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jRz1R-0001fN-1h; Fri, 24 Apr 2020 14:09:41 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v6 15/15] x86/mm: drop _new suffix for page table APIs
Date: Fri, 24 Apr 2020 15:09:06 +0100
Message-Id: <9ff8ad5d4ba7602f3d7137a650aba5de52dacd80.1587735799.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
In-Reply-To: <cover.1587735799.git.hongyxia@amazon.com>
References: <cover.1587735799.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

No functional change.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/mm.c        | 48 ++++++++++++++++++++--------------------
 xen/arch/x86/smpboot.c   | 12 +++++-----
 xen/arch/x86/x86_64/mm.c | 10 ++++-----
 xen/common/efi/boot.c    | 10 ++++-----
 xen/include/asm-x86/mm.h |  4 ++--
 5 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 7e212cc3e0..a17ae0004a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -356,7 +356,7 @@ void __init arch_init_memory(void)
             ASSERT(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS);
             if ( l4_table_offset(split_va) == l4_table_offset(split_va - 1) )
             {
-                mfn_t l3mfn = alloc_xen_pagetable_new();
+                mfn_t l3mfn = alloc_xen_pagetable();
 
                 if ( !mfn_eq(l3mfn, INVALID_MFN) )
                 {
@@ -4919,7 +4919,7 @@ int mmcfg_intercept_write(
  * them. The caller must check whether the allocation has succeeded, and only
  * pass valid MFNs to map_domain_page().
  */
-mfn_t alloc_xen_pagetable_new(void)
+mfn_t alloc_xen_pagetable(void)
 {
     if ( system_state != SYS_STATE_early_boot )
     {
@@ -4934,7 +4934,7 @@ mfn_t alloc_xen_pagetable_new(void)
 }
 
 /* mfn can be INVALID_MFN */
-void free_xen_pagetable_new(mfn_t mfn)
+void free_xen_pagetable(mfn_t mfn)
 {
     if ( system_state != SYS_STATE_early_boot && !mfn_eq(mfn, INVALID_MFN) )
         free_domheap_page(mfn_to_page(mfn));
@@ -4955,7 +4955,7 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v)
     {
         bool locking = system_state > SYS_STATE_boot;
         l3_pgentry_t *l3t;
-        mfn_t l3mfn = alloc_xen_pagetable_new();
+        mfn_t l3mfn = alloc_xen_pagetable();
 
         if ( mfn_eq(l3mfn, INVALID_MFN) )
             return NULL;
@@ -4974,7 +4974,7 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v)
         }
         if ( locking )
             spin_unlock(&map_pgdir_lock);
-        free_xen_pagetable_new(l3mfn);
+        free_xen_pagetable(l3mfn);
     }
 
     return map_l3t_from_l4e(*pl4e) + l3_table_offset(v);
@@ -4993,7 +4993,7 @@ static l2_pgentry_t *virt_to_xen_l2e(unsigned long v)
     {
         bool locking = system_state > SYS_STATE_boot;
         l2_pgentry_t *l2t;
-        mfn_t l2mfn = alloc_xen_pagetable_new();
+        mfn_t l2mfn = alloc_xen_pagetable();
 
         if ( mfn_eq(l2mfn, INVALID_MFN) )
         {
@@ -5012,7 +5012,7 @@ static l2_pgentry_t *virt_to_xen_l2e(unsigned long v)
         }
         if ( locking )
             spin_unlock(&map_pgdir_lock);
-        free_xen_pagetable_new(l2mfn);
+        free_xen_pagetable(l2mfn);
     }
 
     BUG_ON(l3e_get_flags(*pl3e) & _PAGE_PSE);
@@ -5035,7 +5035,7 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long v)
     {
         bool locking = system_state > SYS_STATE_boot;
         l1_pgentry_t *l1t;
-        mfn_t l1mfn = alloc_xen_pagetable_new();
+        mfn_t l1mfn = alloc_xen_pagetable();
 
         if ( mfn_eq(l1mfn, INVALID_MFN) )
         {
@@ -5054,7 +5054,7 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long v)
         }
         if ( locking )
             spin_unlock(&map_pgdir_lock);
-        free_xen_pagetable_new(l1mfn);
+        free_xen_pagetable(l1mfn);
     }
 
     BUG_ON(l2e_get_flags(*pl2e) & _PAGE_PSE);
@@ -5163,10 +5163,10 @@ int map_pages_to_xen(
                         ol2e = l2t[i];
                         if ( (l2e_get_flags(ol2e) & _PAGE_PRESENT) &&
                              !(l2e_get_flags(ol2e) & _PAGE_PSE) )
-                            free_xen_pagetable_new(l2e_get_mfn(ol2e));
+                            free_xen_pagetable(l2e_get_mfn(ol2e));
                     }
                     unmap_domain_page(l2t);
-                    free_xen_pagetable_new(l3e_get_mfn(ol3e));
+                    free_xen_pagetable(l3e_get_mfn(ol3e));
                 }
             }
 
@@ -5205,7 +5205,7 @@ int map_pages_to_xen(
                 continue;
             }
 
-            l2mfn = alloc_xen_pagetable_new();
+            l2mfn = alloc_xen_pagetable();
             if ( mfn_eq(l2mfn, INVALID_MFN) )
                 goto out;
 
@@ -5233,7 +5233,7 @@ int map_pages_to_xen(
                 spin_unlock(&map_pgdir_lock);
             flush_area(virt, flush_flags);
 
-            free_xen_pagetable_new(l2mfn);
+            free_xen_pagetable(l2mfn);
         }
 
         pl2e = virt_to_xen_l2e(virt);
@@ -5267,7 +5267,7 @@ int map_pages_to_xen(
                         flush_flags(l1e_get_flags(l1t[i]));
                     flush_area(virt, flush_flags);
                     unmap_domain_page(l1t);
-                    free_xen_pagetable_new(l2e_get_mfn(ol2e));
+                    free_xen_pagetable(l2e_get_mfn(ol2e));
                 }
             }
 
@@ -5313,7 +5313,7 @@ int map_pages_to_xen(
                     goto check_l3;
                 }
 
-                l1mfn = alloc_xen_pagetable_new();
+                l1mfn = alloc_xen_pagetable();
                 if ( mfn_eq(l1mfn, INVALID_MFN) )
                     goto out;
 
@@ -5340,7 +5340,7 @@ int map_pages_to_xen(
                     spin_unlock(&map_pgdir_lock);
                 flush_area(virt, flush_flags);
 
-                free_xen_pagetable_new(l1mfn);
+                free_xen_pagetable(l1mfn);
             }
 
             pl1e  = map_l1t_from_l2e(*pl2e) + l1_table_offset(virt);
@@ -5406,7 +5406,7 @@ int map_pages_to_xen(
                     flush_area(virt - PAGE_SIZE,
                                FLUSH_TLB_GLOBAL |
                                FLUSH_ORDER(PAGETABLE_ORDER));
-                    free_xen_pagetable_new(l2e_get_mfn(ol2e));
+                    free_xen_pagetable(l2e_get_mfn(ol2e));
                 }
                 else if ( locking )
                     spin_unlock(&map_pgdir_lock);
@@ -5457,7 +5457,7 @@ int map_pages_to_xen(
                 flush_area(virt - PAGE_SIZE,
                            FLUSH_TLB_GLOBAL |
                            FLUSH_ORDER(2*PAGETABLE_ORDER));
-                free_xen_pagetable_new(l3e_get_mfn(ol3e));
+                free_xen_pagetable(l3e_get_mfn(ol3e));
             }
             else if ( locking )
                 spin_unlock(&map_pgdir_lock);
@@ -5546,7 +5546,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
             }
 
             /* PAGE1GB: shatter the superpage and fall through. */
-            l2mfn = alloc_xen_pagetable_new();
+            l2mfn = alloc_xen_pagetable();
             if ( mfn_eq(l2mfn, INVALID_MFN) )
                 goto out;
 
@@ -5570,7 +5570,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
             if ( locking )
                 spin_unlock(&map_pgdir_lock);
 
-            free_xen_pagetable_new(l2mfn);
+            free_xen_pagetable(l2mfn);
         }
 
         /*
@@ -5606,7 +5606,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
             {
                 l1_pgentry_t *l1t;
                 /* PSE: shatter the superpage and try again. */
-                mfn_t l1mfn = alloc_xen_pagetable_new();
+                mfn_t l1mfn = alloc_xen_pagetable();
 
                 if ( mfn_eq(l1mfn, INVALID_MFN) )
                     goto out;
@@ -5630,7 +5630,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
                 if ( locking )
                     spin_unlock(&map_pgdir_lock);
 
-                free_xen_pagetable_new(l1mfn);
+                free_xen_pagetable(l1mfn);
             }
         }
         else
@@ -5697,7 +5697,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
                 if ( locking )
                     spin_unlock(&map_pgdir_lock);
                 flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */
-                free_xen_pagetable_new(l1mfn);
+                free_xen_pagetable(l1mfn);
             }
             else if ( locking )
                 spin_unlock(&map_pgdir_lock);
@@ -5742,7 +5742,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
                 if ( locking )
                     spin_unlock(&map_pgdir_lock);
                 flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */
-                free_xen_pagetable_new(l2mfn);
+                free_xen_pagetable(l2mfn);
             }
             else if ( locking )
                 spin_unlock(&map_pgdir_lock);
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 71d61794ec..06c8e3ddf0 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -730,7 +730,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
 
     if ( !(root_get_flags(rpt[root_table_offset(linear)]) & _PAGE_PRESENT) )
     {
-        mfn_t l3mfn = alloc_xen_pagetable_new();
+        mfn_t l3mfn = alloc_xen_pagetable();
 
         if ( mfn_eq(l3mfn, INVALID_MFN) )
             goto out;
@@ -747,7 +747,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
 
     if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
     {
-        mfn_t l2mfn = alloc_xen_pagetable_new();
+        mfn_t l2mfn = alloc_xen_pagetable();
 
         if ( mfn_eq(l2mfn, INVALID_MFN) )
             goto out;
@@ -766,7 +766,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
 
     if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
     {
-        mfn_t l1mfn = alloc_xen_pagetable_new();
+        mfn_t l1mfn = alloc_xen_pagetable();
 
         if ( mfn_eq(l1mfn, INVALID_MFN) )
             goto out;
@@ -908,15 +908,15 @@ static void cleanup_cpu_root_pgt(unsigned int cpu)
                     continue;
 
                 ASSERT(!(l2e_get_flags(l2t[i2]) & _PAGE_PSE));
-                free_xen_pagetable_new(l2e_get_mfn(l2t[i2]));
+                free_xen_pagetable(l2e_get_mfn(l2t[i2]));
             }
 
             unmap_domain_page(l2t);
-            free_xen_pagetable_new(l2mfn);
+            free_xen_pagetable(l2mfn);
         }
 
         unmap_domain_page(l3t);
-        free_xen_pagetable_new(l3mfn);
+        free_xen_pagetable(l3mfn);
     }
 
     free_xenheap_page(rpt);
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 12e9dc6eb2..d37f6a3755 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -444,7 +444,7 @@ static int setup_m2p_table(struct mem_hotadd_info *info)
                 l2_ro_mpt = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]);
             else
             {
-                mfn_t l2_ro_mpt_mfn = alloc_xen_pagetable_new();
+                mfn_t l2_ro_mpt_mfn = alloc_xen_pagetable();
 
                 if ( mfn_eq(l2_ro_mpt_mfn, INVALID_MFN) )
                 {
@@ -497,7 +497,7 @@ void __init paging_init(void)
               _PAGE_PRESENT) )
         {
             l3_pgentry_t *pl3t;
-            mfn_t l3mfn = alloc_xen_pagetable_new();
+            mfn_t l3mfn = alloc_xen_pagetable();
 
             if ( mfn_eq(l3mfn, INVALID_MFN) )
                 goto nomem;
@@ -511,7 +511,7 @@ void __init paging_init(void)
     }
 
     /* Create user-accessible L2 directory to map the MPT for guests. */
-    l3_ro_mpt_mfn = alloc_xen_pagetable_new();
+    l3_ro_mpt_mfn = alloc_xen_pagetable();
     if ( mfn_eq(l3_ro_mpt_mfn, INVALID_MFN) )
         goto nomem;
     l3_ro_mpt = map_domain_page(l3_ro_mpt_mfn);
@@ -602,7 +602,7 @@ void __init paging_init(void)
         {
             UNMAP_DOMAIN_PAGE(l2_ro_mpt);
 
-            l2_ro_mpt_mfn = alloc_xen_pagetable_new();
+            l2_ro_mpt_mfn = alloc_xen_pagetable();
             if ( mfn_eq(l2_ro_mpt_mfn, INVALID_MFN) )
                 goto nomem;
 
@@ -626,7 +626,7 @@ void __init paging_init(void)
     UNMAP_DOMAIN_PAGE(l3_ro_mpt);
 
     /* Create user-accessible L2 directory to map the MPT for compat guests. */
-    l2_ro_mpt_mfn = alloc_xen_pagetable_new();
+    l2_ro_mpt_mfn = alloc_xen_pagetable();
     if ( mfn_eq(l2_ro_mpt_mfn, INVALID_MFN) )
         goto nomem;
     compat_idle_pg_table_l2 = map_domain_page_global(l2_ro_mpt_mfn);
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 715217d2a9..d70d06084c 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1456,7 +1456,7 @@ static __init void copy_mapping(unsigned long mfn, unsigned long end,
             continue;
         if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) )
         {
-            mfn_t l3mfn = alloc_xen_pagetable_new();
+            mfn_t l3mfn = alloc_xen_pagetable();
 
             BUG_ON(mfn_eq(l3mfn, INVALID_MFN));
             l3dst = map_domain_page(l3mfn);
@@ -1608,7 +1608,7 @@ void __init efi_init_memory(void)
      * Set up 1:1 page tables for runtime calls. See SetVirtualAddressMap() in
      * efi_exit_boot().
      */
-    efi_l4_mfn = alloc_xen_pagetable_new();
+    efi_l4_mfn = alloc_xen_pagetable();
     BUG_ON(mfn_eq(efi_l4_mfn, INVALID_MFN));
     efi_l4_pgtable = map_domain_page(efi_l4_mfn);
     clear_page(efi_l4_pgtable);
@@ -1643,7 +1643,7 @@ void __init efi_init_memory(void)
 
         if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) )
         {
-            mfn_t l3mfn = alloc_xen_pagetable_new();
+            mfn_t l3mfn = alloc_xen_pagetable();
 
             BUG_ON(mfn_eq(l3mfn, INVALID_MFN));
             pl3e = map_domain_page(l3mfn);
@@ -1656,7 +1656,7 @@ void __init efi_init_memory(void)
         pl3e += l3_table_offset(addr);
         if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
         {
-            mfn_t l2mfn = alloc_xen_pagetable_new();
+            mfn_t l2mfn = alloc_xen_pagetable();
 
             BUG_ON(mfn_eq(l2mfn, INVALID_MFN));
             pl2e = map_domain_page(l2mfn);
@@ -1671,7 +1671,7 @@ void __init efi_init_memory(void)
         pl2e += l2_table_offset(addr);
         if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
         {
-            mfn_t l1mfn = alloc_xen_pagetable_new();
+            mfn_t l1mfn = alloc_xen_pagetable();
 
             BUG_ON(mfn_eq(l1mfn, INVALID_MFN));
             l1t = map_domain_page(l1mfn);
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index cf855b48fd..ef7a20ac7d 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -583,8 +583,8 @@ int vcpu_destroy_pagetables(struct vcpu *);
 void *do_page_walk(struct vcpu *v, unsigned long addr);
 
 /* Allocator functions for Xen pagetables. */
-mfn_t alloc_xen_pagetable_new(void);
-void free_xen_pagetable_new(mfn_t mfn);
+mfn_t alloc_xen_pagetable(void);
+void free_xen_pagetable(mfn_t mfn);
 
 l1_pgentry_t *virt_to_xen_l1e(unsigned long v);
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:27:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:27:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzIG-0005t1-RP; Fri, 24 Apr 2020 14:27:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Nbk=6I=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jRzIF-0005sw-Je
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:27:03 +0000
X-Inumbo-ID: a8f9f23e-8637-11ea-b58d-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a8f9f23e-8637-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 14:27:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 31C50ABD0;
 Fri, 24 Apr 2020 14:26:59 +0000 (UTC)
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200424133736.737-1-paul@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <a1febde5-0a34-6480-6400-7142a6bb6f52@suse.com>
Date: Fri, 24 Apr 2020 16:26:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200424133736.737-1-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.20 15:37, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
> 
> ... to specify a separate migration stream that will also be suitable for
> live update.
> 
> The original scope of the document was to support non-cooperative migration
> of guests [1] but, since then, live update of xenstored has been brought into
> scope. Thus it makes more sense to define a separate image format for
> serializing xenstore state that is suitable for both purposes.
> 
> The document has been limited to specifying a new image format. The mechanism
> for acquiring the image for live update or migration is not covered as that
> is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
> also expected that, when the first implementation of live update or migration
> making use of this specification is committed, that the document is moved from
> docs/designs into docs/specs.
> 
> [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> ---
> Juergen Gross <jgross@suse.com>
> Andrew Cooper <andrew.cooper3@citrix.com>
> George Dunlap <george.dunlap@citrix.com>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Jan Beulich <jbeulich@suse.com>
> Julien Grall <julien@xen.org>
> Stefano Stabellini <sstabellini@kernel.org>
> Wei Liu <wl@xen.org>
> ---
>   docs/designs/xenstore-migration.md | 472 +++++++++++++++++++----------
>   1 file changed, 309 insertions(+), 163 deletions(-)
> 
> diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
> index 6ab351e8fe..c96bad48eb 100644
> --- a/docs/designs/xenstore-migration.md
> +++ b/docs/designs/xenstore-migration.md
> @@ -3,254 +3,400 @@
>   ## Background
>   
>   The design for *Non-Cooperative Migration of Guests*[1] explains that extra
> -save records are required in the migrations stream to allow a guest running
> -PV drivers to be migrated without its co-operation. Moreover the save
> -records must include details of registered xenstore watches as well as
> -content; information that cannot currently be recovered from `xenstored`,
> -and hence some extension to the xenstore protocol[2] will also be required.
> -
> -The *libxenlight Domain Image Format* specification[3] already defines a
> -record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
> -transferring xenstore data pertaining to the domain directly as it is
> -specified such that keys are relative to the path
> -`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
> -define at least one new save record type.
> +save records are required in the migrations stream to allow a guest running PV
> +drivers to be migrated without its co-operation. Moreover the save records must
> +include details of registered xenstore watches as well ascontent; information
> +that cannot currently be recovered from `xenstored`, and hence some extension
> +to the xenstored implementations will also be required.
> +
> +As a similar set of data is needed for transferring xenstore data from one
> +instance to another when live updating xenstored this document proposes an
> +image format for a 'migration stream' suitable for both purposes.
>   
>   ## Proposal
>   
> -### New Save Record
> +The image format consists of a _header_ followed by 1 or more _records_. Each
> +record consists of a type and length field, followed by any data mandated by
> +the record type. At minimum there will be a single record of type `END`
> +(defined below).
>   
> -A new mandatory record type should be defined within the libxenlight Domain
> -Image Format:
> +### Header
>   
> -`0x00000007: DOMAIN_XENSTORE_DATA`
> +The header identifies the stream as a `xenstore` stream, including the version
> +of the specification that it complies with.
>   
> -An arbitrary number of these records may be present in the migration
> -stream and may appear in any order. The format of each record should be as
> -follows:
> +All fields in this header must be in _big-endian_ byte order, regardless of
> +the setting of the endianness bit.
>   
>   
>   ```
>       0       1       2       3       4       5       6       7    octet
>   +-------+-------+-------+-------+-------+-------+-------+-------+
> -| type                          | record specific data          |
> -+-------------------------------+                               |
> -...
> -+---------------------------------------------------------------+
> +| ident                                                         |
> ++-------------------------------+-------------------------------|
> +| version                       | flags                         |
> ++-------------------------------+-------------------------------+
>   ```
>   
> -where type is one of the following values
>   
> +| Field     | Description                                       |
> +|-----------|---------------------------------------------------|
> +| `ident`   | 0x78656e73746f7265 ('xenstore' in ASCII)          |
> +|           |                                                   |
> +| `version` | 0x00000001 (the version of the specification)     |
> +|           |                                                   |
> +| `flags`   | 0 (LSB): Endianness: 0 = little, 1 = big          |
> +|           |                                                   |
> +|           | 1-31: Reserved (must be zero)                     |
>   
> -| Field  | Description                                      |
> -|--------|--------------------------------------------------|
> -| `type` | 0x00000000: invalid                              |
> -|        | 0x00000001: NODE_DATA                            |
> -|        | 0x00000002: WATCH_DATA                           |
> -|        | 0x00000003: TRANSACTION_DATA                     |
> -|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
> +### Records
>   
> +Records immediately follow the header and have the following format:
>   
> -and data is one of the record data formats described in the following
> -sections.
>   
> +```
> +    0       1       2       3       4       5       6       7    octet
> ++-------+-------+-------+-------+-------+-------+-------+-------+
> +| type                          | len                           |
> ++-------------------------------+-------------------------------+
> +| body
> +...
> +|       | padding (0 to 7 octets)                               |
> ++-------+-------------------------------------------------------+
> +```
> +
> +NOTE: padding octets here and in all subsequent format specifications must be
> +      zero, unless stated otherwise.

What about: "... are written as zero and should be ignored on read."

>   
> -NOTE: The record data does not contain an overall length because the
> -libxenlight record header specifies the length.
>   
> +| Field  | Description                                          |
> +|--------|------------------------------------------------------|
> +| `type` | 0x00000000: END                                      |
> +|        | 0x00000001: GLOBAL_DATA                              |
> +|        | 0x00000002: CONNECTION_DATA                          |
> +|        | 0x00000003: WATCH_DATA                               |
> +|        | 0x00000004: TRANSACTION_DATA                         |
> +|        | 0x00000005: NODE_DATA                                |
> +|        | 0x00000006 - 0xFFFFFFFF: reserved for future use     |
> +|        |                                                      |
> +| `len`  | The length (in octets) of `body`                     |
> +|        |                                                      |
> +| `body` | The type-specific record data                        |
>   
> -**NODE_DATA**
> +The various formats of the type-specific data are described in the following
> +sections:
>   
> +\pagebreak
>   
> -Each NODE_DATA record specifies a single node in xenstore and is formatted
> -as follows:
> +### END
>   
> +The end record marks the end of the image, and is the final record
> +in the stream.
>   
>   ```
> -    0       1       2       3     octet
> -+-------+-------+-------+-------+
> -| NODE_DATA                     |
> -+-------------------------------+
> -| path length                   |
> -+-------------------------------+
> -| path data                     |
> -...
> -| pad (0 to 3 octets)           |
> -+-------------------------------+
> -| perm count (N)                |
> -+-------------------------------+
> -| perm0                         |
> -+-------------------------------+
> -...
> -+-------------------------------+
> -| permN                         |
> -+-------------------------------+
> -| value length                  |
> -+-------------------------------+
> -| value data                    |
> -...
> -| pad (0 to 3 octets)           |
> -+-------------------------------+
> +    0       1       2       3       4       5       6       7    octet
> ++-------+-------+-------+-------+-------+-------+-------+-------+
>   ```
>   
> -where perm0..N are formatted as follows:
>   
> +The end record contains no fields; its body length is 0.
> +
> +\pagebreak
> +
> +### GLOBAL_DATA
> +
> +This record is only relevant for live update. It contains details of global
> +xenstored state that needs to be restored.
>   
>   ```
> -    0       1       2       3     octet
> +    0       1       2       3    octet
>   +-------+-------+-------+-------+
> -| perm  | pad   | domid         |
> +| rw-socket-fd                  |
> ++-------------------------------+
> +| ro-socket-fd                  |
>   +-------------------------------+
>   ```
>   
>   
> -path length and value length are specified in octets (excluding the NUL
> -terminator of the path). perm should be one of the ASCII values `w`, `r`,
> -`b` or `n` as described in [2]. All pad values should be 0.
> -All paths should be absolute (i.e. start with `/`) and as described in
> -[2].
> +| Field          | Description                                  |
> +|----------------|----------------------------------------------|
> +| `rw-socket-fd` | The file descriptor of the socket accepting  |
> +|                | read-write connections                       |
> +|                |                                              |
> +| `ro-socket-fd` | The file descriptor of the socket accepting  |
> +|                | read-only connections                        |
> +
> +xenstored will resume in the original process context. Hence `rw-socket-fd` and
> +`ro-socket-fd` simply specify the file descriptors of the sockets.
>   
>   
> -**WATCH_DATA**
> +\pagebreak
>   
> +### CONNECTION_DATA
>   
> -Each WATCH_DATA record specifies a registered watch and is formatted as
> -follows:
> +For live update the image format will contain a `CONNECTION_DATA` record for
> +each connection to xenstore. For migration it will only contain a record for
> +the domain being migrated.
>   
>   
>   ```
> -    0       1       2       3     octet
> -+-------+-------+-------+-------+
> -| WATCH_DATA                    |
> -+-------------------------------+
> -| wpath length                  |
> -+-------------------------------+
> -| wpath data                    |
> -...
> -| pad (0 to 3 octets)           |
> -+-------------------------------+
> +    0       1       2       3       4       5       6       7    octet
> ++-------+-------+-------+-------+-------+-------+-------+-------+
> +| conn-id                       | pad                           |
> ++---------------+-----------------------------------------------+
> +| conn-type     | conn-spec
>   ...
> ++-------------------------------+-------------------------------+

I'd rather drop the pad, and replace it by conn-type and a 2-byte
flag field (for the flags INTRODUCE, RELEASE, read-only).

> +| data-len                      | data
>   +-------------------------------+
> -| token length                  |
> -+-------------------------------+
> -| token data                    |
>   ...
> -| pad (0 to 3 octets)           |
> -+-------------------------------+
>   ```
>   
> -wpath length and token length are specified in octets (excluding the NUL
> -terminator). The wpath should be as described for the `WATCH` operation in
> -[2]. The token is an arbitrary string of octets not containing any NUL
> -values.
>   
> +| Field       | Description                                     |
> +|-------------|-------------------------------------------------|
> +| `conn-id`   | A non-zero number used to identify this         |
> +|             | connection in subsequent connection-specific    |
> +|             | records                                         |
> +|             |                                                 |
> +| `conn-type` | 0x0000: shared ring                             |
> +|             | 0x0001: socket                                  |
> +|             |                                                 |
> +| `conn-spec` | See below                                       |
> +|             |                                                 |
> +| `data-len`  | The length (in octets) of any pending data not  |
> +|             | yet written to the connection                   |
> +|             |                                                 |
> +| `data`      | Pending data (may be empty)                     |
>   
> -**TRANSACTION_DATA**
> +The format of `conn-spec` is dependent upon `conn-type`.
>   
> +\pagebreak
>   
> -Each TRANSACTION_DATA record specifies an open transaction and is formatted
> -as follows:
> +For `shared ring` connections it is as follows:
>   
>   
>   ```
> -    0       1       2       3     octet
> -+-------+-------+-------+-------+
> -| TRANSACTION_DATA              |
> -+-------------------------------+
> -| tx_id                         |
> -+-------------------------------+
> +    0       1       2       3       4       5       6       7    octet
> +                +-------+-------+-------+-------+-------+-------+
> +                | domid         | tdomid        | flags         |
> ++---------------+---------------+---------------+---------------+
> +| revtchn                       | levtchn                       |
> ++-------------------------------+-------------------------------+
> +| mfn                                                           |
> ++---------------------------------------------------------------+

levtchn is not needed IMO. Event channels can be closed and reopened,
so levtchn will have a new value in the common case.

With my suggestion above regarding flags we would have just 16 bytes
now, which can be aligned quite nicely in a sub-structure.

>   ```
>   
> -where tx_id is the non-zero identifier values of an open transaction.
> -
>   
> -### Protocol Extension
> +| Field      | Description                                      |
> +|------------|--------------------------------------------------|
> +| `domid`    | The domain-id that owns the shared page          |
> +|            |                                                  |
> +| `tdomid`   | The domain-id that `domid` acts on behalf of if  |
> +|            | it has been subject to an SET_TARGET             |
> +|            | operation [2] or DOMID_INVALID otherwise         |
> +|            |                                                  |
> +| `flags`    | A bit-wise OR of:                                |
> +|            | 0x0001: INTRODUCE has been issued                |
> +|            | 0x0002: RELEASE has been issued                  |
> +|            |                                                  |
> +| `revtchn`  | The port number of the interdomain channel used  |
> +|            | by `domid` to communicate with xenstored         |
> +|            |                                                  |
> +| `levtchn`  | For a live update this will be the port number   |
> +|            | of the interdomain channel used by xenstored     |
> +|            | itself otherwise, for migration, it will be -1   |
> +|            |                                                  |
> +| `mfn`      | The MFN of the shared page for a live update or  |
> +|            | INVALID_MFN otherwise                            |
> +
> +Since the ABI guarantees that entry 1 in `domid`'s grant table will always
> +contain the GFN of the shared page, so for a live update `mfn` can be used to
> +give confidence that `domid` has not been re-cycled during the update.
> +
> +
> +For `socket` connections it is as follows:
>   
> -Before xenstore state is migrated it is necessary to wait for any pending
> -reads, writes, watch registrations etc. to complete, and also to make sure
> -that xenstored does not start processing any new requests (so that new
> -requests remain pending on the shared ring for subsequent processing on the
> -new host). Hence the following operation is needed:
>   
>   ```
> -QUIESCE                 <domid>|
> -
> -Complete processing of any request issued by the specified domain, and
> -do not process any further requests from the shared ring.
> +    0       1       2       3       4       5       6       7    octet
> +                +-------+-------+-------+-------+-------+-------+
> +                | flags         | socket-fd                     |
> +                +---------------+-------------------------------+
>   ```
>   
> -The `WATCH` operation does not allow specification of a `<domid>`; it is
> -assumed that the watch pertains to the domain that owns the shared ring
> -over which the operation is passed. Hence, for the tool-stack to be able
> -to register a watch on behalf of a domain a new operation is needed:
>   
> -```
> -ADD_DOMAIN_WATCHES      <domid>|<watch>|+
> +| Field       | Description                                     |
> +|-------------|-------------------------------------------------|
> +| `flags`     | A bit-wise OR of:                               |
> +|             | 0001: read-only                                 |
> +|             |                                                 |
> +| `socket-fd` | The file descriptor of the connected socket     |
>   
> -Adds watches on behalf of the specified domain.
> +This type of connection is only relevant for live update, where the xenstored
> +resumes in the original process context. Hence `socket-fd` simply specify
> +the file descriptor of the socket connection.
>   
> -<watch> is a NUL separated tuple of <path>|<token>. The semantics of this
> -operation are identical to the domain issuing WATCH <path>|<token>| for
> -each <watch>.
> -```
> +\pagebreak
> +
> +### WATCH_DATA
> +
> +The image format will contain a `WATCH_DATA` record for each watch registered
> +by a connection for which there is `CONNECTION_DATA` record previously present.
>   
> -The watch information for a domain also needs to be extracted from the
> -sending xenstored so the following operation is also needed:
>   
>   ```
> -GET_DOMAIN_WATCHES      <domid>|<index>   <gencnt>|<watch>|*
> +    0       1       2       3    octet
> ++-------+-------+-------+-------+
> +| conn-id                       |
> ++---------------+---------------+
> +| wpath-len     | token-len     |
> ++---------------+---------------+
> +| wpath
> +...
> +| token
> +...
> +```
> +
>   
> -Gets the list of watches that are currently registered for the domain.
> +| Field       | Description                                     |
> +|-------------|-------------------------------------------------|
> +| `conn-id`   | The connection that issued the `WATCH`          |
> +|             | operation [2]                                   |
> +|             |                                                 |
> +| `wpath-len` | The length (in octets) of `wpath` including the |
> +|             | NUL terminator                                  |
> +|             |                                                 |
> +| `token-len` | The length (in octets) of `token` including the |
> +|             | NUL terminator                                  |
> +|             |                                                 |
> +| `wpath`     | The watch path, as specified in the `WATCH`     |
> +|             | operation                                       |
> +|             |                                                 |
> +| `token`     | The watch identifier token, as specified in the |
> +|             | `WATCH` operation                               |
> +
> +\pagebreak
> +
> +### TRANSACTION_DATA
> +
> +The image format will contain a `TRANSACTION_DATA` record for each transaction
> +that is pending on a connection for which there is `CONNECTION_DATA` record
> +previously present.
>   
> -<watch> is a NUL separated tuple of <path>|<token>. The sub-list returned
> -will start at <index> items into the the overall list of watches and may
> -be truncated (at a <watch> boundary) such that the returned data fits
> -within XENSTORE_PAYLOAD_MAX.
>   
> -If <index> is beyond the end of the overall list then the returned sub-
> -list will be empty. If the value of <gencnt> changes then it indicates
> -that the overall watch list has changed and thus it may be necessary
> -to re-issue the operation for previous values of <index>.
>   ```
> +    0       1       2       3    octet
> ++-------+-------+-------+-------+
> +| conn-id                       |
> ++-------------------------------+
> +| tx-id                         |
> ++-------------------------------+
> +```
> +
> +
> +| Field          | Description                                  |
> +|----------------|----------------------------------------------|
> +| `conn-id`      | The connection that issued the               |
> +|                | `TRANSACTION_START` operation [2]            |
> +|                |                                              |
> +| `tx-id`        | The transaction id passed back to the domain |
> +|                | by the `TRANSACTION_START` operation         |
> +
> +\pagebreak
>   
> -To deal with transactions that were pending when the domain is migrated
> -it is necessary to start transactions with the same tx_id on behalf of the
> -domain in the receiving xenstored.
> +### NODE_DATA
>   
> -NOTE: For safety each such transaction should result in an `EAGAIN` when
> -the `TRANSACTION_END` operation is performed, as modifications made under
> -the tx_id will not be part of the migration stream.
> +For live update the image format will contain a `NODE_DATA` record for each
> +node in xenstore. For migration it will only contain a record for the nodes
> +relating to the domain being migrated. The `NODE_DATA` may be related to
> +a _committed_ node (globally visible in xenstored) or a _pending_ node (created
> +or modified by a transaction for which there is also a `TRANSACTION_DATA`
> +record previously present).
>   
> -The `TRANSACTION_START` operation does not allow specification of a
> -`<domid>`; it is assumed that the transaction pertains to the domain that
> -owns the shared ring over which the operation is passed. Neither does it
> -allow a `<transid>` to be specified; it is always chosen by xenstored.
> -Hence, for the tool-stack to be able to open a transaction on behalf of a
> -domain a new operation is needed:
>   
>   ```
> -START_DOMAIN_TRANSACTION    <domid>|<transid>|
> +    0       1       2       3    octet
> ++-------+-------+-------+-------+
> +| conn-id                       |
> ++-------------------------------+
> +| tx-id                         |
> ++---------------+---------------+
> +| access        | perm-count    |
> ++---------------+---------------+
> +| perm1                         |
> ++-------------------------------+
> +...
> ++-------------------------------+
> +| permN                         |
> ++---------------+---------------+
> +| path-len      | value-len     |
> ++---------------+---------------+

I'd rather move path-len and value-len above perm1 in order to have
the fixed-length fields in a common structure.

> +| path
> +...
> +| value
> +...
> +```
> +
> +
> +| Field        | Description                                    |
> +|--------------|------------------------------------------------|
> +| `conn-id`    | If this value is non-zero then this record     |
> +|              | related to a pending transaction               |
> +|              |                                                |
> +| `tx-id`      | This value should be ignored if `conn-id` is   |
> +|              | zero. Otherwise it specifies the id of the     |
> +|              | pending transaction                            |
> +|              |                                                |
> +| `access`     | This value should be ignored if this record    |
> +|              | does not relate to a pending transaction,      |
> +|              | otherwise it specifies the accesses made to    |
> +|              | the node and hence is a bitwise OR of:         |
> +|              |                                                |
> +|              | 0x0001: read                                   |
> +|              | 0x0002: written                                |
> +|              |                                                |
> +|              | The value will be zero for a deleted node      |
> +|              |                                                |
> +| `perm-count` | The number (N) of node permission specifiers   |
> +|              | (which will be 0 for a node deleted in a       |
> +|              | pending transaction)                           |
> +|              |                                                |
> +| `perm1..N`   | A list of zero or more node permission         |
> +|              | specifiers (see below)                         |
> +|              |                                                |
> +| `path-len`   | The length (in octets) of `path` including the |
> +|              | NUL terminator                                 |
> +|              |                                                |
> +| `value-len`  | The length (in octets) of `value` (which will  |
> +|              | be zero for a deleted node)                    |
> +|              |                                                |
> +| `path`       | The absolute path of the node                  |
> +|              |                                                |
> +| `value`      | The node value (which may be empty or contain  |
> +|              | NUL octets)                                    |
> +
> +
> +A node permission specifier has the following format:
>   
> -Starts a transaction on behalf of a domain.
>   
> -The semantics of this are similar to the domain issuing
> -TRANSACTION_START and receiving the specified <transid> as the response.
> -The main difference is that the transaction will be immediately marked as
> -'conflicting' such that when the domain issues TRANSACTION_END T|, it will
> -result in EAGAIN.
> +```
> +    0       1       2       3    octet
> ++-------+-------+-------+-------+
> +| perm  | pad   | domid         |
> ++-------+-------+---------------+
>   ```
>   
> -It may also be desirable to state in the protocol specification that
> -the `INTRODUCE` operation should not clear the `<gfn>` specified such that
> -a `RELEASE` operation followed by an `INTRODUCE` operation form an
> -idempotent pair. The current implementation of *C xentored* does this
> -(in the `domain_conn_reset()` function) but this could be dropped as this
> -behaviour is not currently specified and the page will always be zeroed
> -for a newly created domain.
> +| Field   | Description                                         |
> +|---------|-----------------------------------------------------|
> +| `perm`  | One of the ASCII values `w`, `r`, `b` or `n` as     |
> +|         | specified for the `SET_PERMS` operation [2]         |
> +|         |                                                     |
> +| `domid` | The domain-id to which the permission relates       |
>   
>   
>   * * *
>   
>   [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
> +
>   [2] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/xenstore.txt
> -[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/specs/libxl-migration-stream.pandoc
> 

Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:31:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzMZ-0006ha-Jc; Fri, 24 Apr 2020 14:31:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Spwv=6I=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jRzMY-0006hV-PT
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:31:30 +0000
X-Inumbo-ID: 4965f088-8638-11ea-b58d-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4965f088-8638-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 14:31:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587738690;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=SKi75dnMpwCQEh3oDCg9wrmo7By5yGSUxRs6ZezakMo=;
 b=PQ+/3eJX7GwYWFv0tVfFtsrf/MxGmSpxZCHAk8lrSA1+gK0W6Yp56da9
 Eszz54lmpWLfTC8yaiIxdv/BzZ/sv346Ygzfu5Zus8i618FQwKQVrp0Bu
 R/YexstDTtea1/45Ac5z+zcIuCJf50JP4BwMOadiUogxouWS80Mlz34ft g=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: G2Ozm2MhS2omF6iXzdT0oYkkMkp6KOE5krMPkvgCyeFIComFO65N6/XWByhZvq0qXqKkq2ljXW
 cvsx5yiJ7BGujvT0yAf9J1ltIEHZUNsMUFxAXiAEbK6y6P313wf3PvD2D3iXoB+FykZ4/2gmpN
 b3mKr4PygJc2MyfeTL8b5ONRH7kjMuZDEzd6IIVuTUh21SjYV1Y8w+u292jG5urdfQzpn8n/8m
 +oGsasjBocvPz4llveVxS5FTrXngqwZIroECOjy9nQlOKTbE3Ne9OJcfnCeEO7rHs6qPFy3YGp
 jJo=
X-SBRS: 2.7
X-MesageID: 16222492
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,311,1583211600"; d="scan'208";a="16222492"
From: Anthony PERARD <anthony.perard@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [XEN PATCH] xen/build: silence make warnings about missing auto.conf*
Date: Fri, 24 Apr 2020 15:30:58 +0100
Message-ID: <20200424143058.2546905-1-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.26.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In a clean tree, both files include/config/auto.conf{,.cmd} are
missing and older version of GNU Make complain about it:
    Makefile:103: include/config/auto.conf: No such file or directory
    Makefile:106: include/config/auto.conf.cmd: No such file or directory

Those warnings are harmless, make will create the files and start over. But
to avoid confusion, we'll use "-include" to silence the warning.

Those warning started to appear with commit 6c122d3984a5 ("xen/build:
include include/config/auto.conf in main Makefile").

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index fc8eef6a2817..eedfef26b245 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -154,10 +154,10 @@ config: FORCE
 else # !config-build
 
 ifeq ($(need-config),y)
-include include/config/auto.conf
+-include include/config/auto.conf
 # Read in dependencies to all Kconfig* files, make sure to run syncconfig if
 # changes are detected.
-include include/config/auto.conf.cmd
+-include include/config/auto.conf.cmd
 
 # Allow people to just run `make` as before and not force them to configure
 $(KCONFIG_CONFIG):
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:38:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:38:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzTZ-0006w9-Ap; Fri, 24 Apr 2020 14:38:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jRzTX-0006w4-NE
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:38:43 +0000
X-Inumbo-ID: 4bdea9bc-8639-11ea-83d8-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4bdea9bc-8639-11ea-83d8-bc764e2007e4;
 Fri, 24 Apr 2020 14:38:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=L7BaNyghnXEhZJtb5wSQzjCowtGl+kDnD1Br/4ByDUQ=; b=mbrFUdK55rHhqz5kkkFEvsRZSK
 QB0/pNNl8ccfOlK8fTrlLwV7mp+GQ2PqvfpngYyAdRcB+bXUhSvzfgbCsBIO1CmV445bGroZWQY9R
 9E3zY4Dz2V5z0nlwfPnx9VSXCWW4r6UFDwzsFS3/BKl5Kl6WTDHl7LUZOYUhe5fnif7k=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jRzTW-0002NQ-Ag; Fri, 24 Apr 2020 14:38:42 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jRzTW-0003rb-4E; Fri, 24 Apr 2020 14:38:42 +0000
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200424133736.737-1-paul@xen.org>
 <a1febde5-0a34-6480-6400-7142a6bb6f52@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <c7cb8073-44ef-c92e-2962-d427e1568748@xen.org>
Date: Fri, 24 Apr 2020 15:38:40 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a1febde5-0a34-6480-6400-7142a6bb6f52@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 24/04/2020 15:26, Jürgen Groß wrote:
>> +```
>> +    0       1       2       3       4       5       6       7    octet
>> ++-------+-------+-------+-------+-------+-------+-------+-------+
>> +| type                          | len                           |
>> ++-------------------------------+-------------------------------+
>> +| body
>> +...
>> +|       | padding (0 to 7 octets)                               |
>> ++-------+-------------------------------------------------------+
>> +```
>> +
>> +NOTE: padding octets here and in all subsequent format specifications 
>> must be
>> +      zero, unless stated otherwise.
> 
> What about: "... are written as zero and should be ignored on read."

I would rather not say "ignored" because it doesn't allow us to extend 
the record if needed in a safe way. The read side should abort if it 
sees an other value than 0 in the padding.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:50:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:50:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzek-0008TN-DS; Fri, 24 Apr 2020 14:50:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=v7No=6I=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jRzej-0008TI-Bo
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:50:17 +0000
X-Inumbo-ID: e8931f8a-863a-11ea-9e09-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e8931f8a-863a-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 14:50:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587739816;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=BcTA3vtDQQUUeG3y2NL8ndNOg0AIfp294luSkOKkHhM=;
 b=iBy83Odv8CuggWC9Y6O1meGdp+F7/qNoODPZPYbb+I3nX7NR0WKQmda8
 24GHzbAoK+bzk2FleC/yQxbX9IwTTWC2+OuBTI3medmw7FzAVLZBQfE/i
 CIlj0blqed8kXJ61XpqM2SUdUCOz5sR6bOlac19W86bUi96wdmPM2hTIT Y=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: BWWAQSqWzSMmY6RWdU7xibLguAYzDTKSKBql1fkj2hNdp+Ec+MHlB9qXZJdptaXuzWLZOmrCwS
 BYdARmu9mQ2caWsjJFYpuM+OQCeGkIZdk4UTk7Gplna9UiY2Lu2EKnPNpkNhj12c4SkFE0wAou
 i7HqydVCcmIi2myZVtYOdp30LopaY4BRGpo1dmhbNBhWQF5t0v7dy8bff9KIAGO+OuNXKz2Mmn
 jGwvxKyKvstY2RrD+l5KISVCVNB1r/FGg94ncrQZvE1C2EqhRKPIw4pSXsDE+R/QvIvFn98zbT
 GXk=
X-SBRS: 2.7
X-MesageID: 16191687
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,311,1583211600"; d="scan'208";a="16191687"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24226.64676.86981.838902@mariner.uk.xensource.com>
Date: Fri, 24 Apr 2020 15:50:12 +0100
To: Maximilian Heyne <mheyne@amazon.de>
Subject: Re: [PATCH 0/3] Cleanup IOREQ server on exit
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6f476505-5e85-8a8a-d6d7-db56ea921637@amazon.de>
References: <20200313123316.122003-1-mheyne@amazon.de>
 <6f476505-5e85-8a8a-d6d7-db56ea921637@amazon.de>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Maximilian Heyne writes ("Re: [PATCH 0/3] Cleanup IOREQ server on exit"):
> Could someone please have a look at this patch? It solves an actual issue:
> Try soft-reset with qemu-xen-traditional and it will fail.

Thanks.  I reviewed this.

qemu is in deep freeze but the changes looked correct and are indeed
solving a regression.  I convinced myself that they were appropriately
low risk, so

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

for all three and I have pushed them.

In theory a backport might be appropriate since this is a bugfix but
my inclination is to leave existing releases where they are, since
anyone using qemu-trad probably wants things super-stable.  Contrary
opinions welcome.

It has been a very long time since I did an update of qemu trad so it
is possible that I have mangled the process somehow.  We will see I
guess...

Thanks also to Paul for chasing me about this.

Regards,
Ian.


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 14:51:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 14:51:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jRzg2-00006o-O4; Fri, 24 Apr 2020 14:51:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Nbk=6I=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jRzg0-00006b-Q1
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 14:51:36 +0000
X-Inumbo-ID: 181e5ccf-863b-11ea-94ba-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 181e5ccf-863b-11ea-94ba-12813bfff9fa;
 Fri, 24 Apr 2020 14:51:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 18997ACE3;
 Fri, 24 Apr 2020 14:51:34 +0000 (UTC)
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
To: Julien Grall <julien@xen.org>, Paul Durrant <paul@xen.org>,
 xen-devel@lists.xenproject.org
References: <20200424133736.737-1-paul@xen.org>
 <a1febde5-0a34-6480-6400-7142a6bb6f52@suse.com>
 <c7cb8073-44ef-c92e-2962-d427e1568748@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <8029c772-9c42-460c-e17c-85e18b32f102@suse.com>
Date: Fri, 24 Apr 2020 16:51:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <c7cb8073-44ef-c92e-2962-d427e1568748@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.20 16:38, Julien Grall wrote:
> Hi,
> 
> On 24/04/2020 15:26, Jürgen Groß wrote:
>>> +```
>>> +    0       1       2       3       4       5       6       7    octet
>>> ++-------+-------+-------+-------+-------+-------+-------+-------+
>>> +| type                          | len                           |
>>> ++-------------------------------+-------------------------------+
>>> +| body
>>> +...
>>> +|       | padding (0 to 7 octets)                               |
>>> ++-------+-------------------------------------------------------+
>>> +```
>>> +
>>> +NOTE: padding octets here and in all subsequent format 
>>> specifications must be
>>> +      zero, unless stated otherwise.
>>
>> What about: "... are written as zero and should be ignored on read."
> 
> I would rather not say "ignored" because it doesn't allow us to extend 
> the record if needed in a safe way. The read side should abort if it 
> sees an other value than 0 in the padding.

I'd rather ignore unknown fields. This allows to add optional data
without having to special case it. Writing zeroes is the important part
here, of course.

Ignoring those fields would e.g. enable a downgrade more easily, while
aborting could make that impossible.

And in case a version would write non-zero bytes (e.g. due to a bug)
this version could never be live-updated.

Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 15:44:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 15:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS0Up-0004Lw-T0; Fri, 24 Apr 2020 15:44:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jS0Uo-0004Lr-Kg
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 15:44:06 +0000
X-Inumbo-ID: 6dd1f69c-8642-11ea-94ce-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6dd1f69c-8642-11ea-94ce-12813bfff9fa;
 Fri, 24 Apr 2020 15:44:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=v3wqAYCavyypofe7MTlDKDLJYRm4yp0uzip8LrFvrKM=; b=vS03vCt1k6EmD6b8pEgVjAJrUp
 /YFl87QUp97uEWTAfb0rgoWl8gZuqMhvyA2zB9iQLAryJaIOeuRKK1WhiFP5rOAwS2CVC3RdygqUO
 fBYtcNvSqYVonTpvrWT+Rm3BVTABVxnhIpSS2VwyNZuz+wATwsqhlBmzwsR4fIejfwKo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jS0Um-0003iM-J8; Fri, 24 Apr 2020 15:44:04 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jS0Um-0000cZ-CZ; Fri, 24 Apr 2020 15:44:04 +0000
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200424133736.737-1-paul@xen.org>
 <a1febde5-0a34-6480-6400-7142a6bb6f52@suse.com>
 <c7cb8073-44ef-c92e-2962-d427e1568748@xen.org>
 <8029c772-9c42-460c-e17c-85e18b32f102@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <7ae1bb1c-0029-c3f0-1565-e5f99effee51@xen.org>
Date: Fri, 24 Apr 2020 16:44:02 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <8029c772-9c42-460c-e17c-85e18b32f102@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 24/04/2020 15:51, Jürgen Groß wrote:
> On 24.04.20 16:38, Julien Grall wrote:
>> Hi,
>>
>> On 24/04/2020 15:26, Jürgen Groß wrote:
>>>> +```
>>>> +    0       1       2       3       4       5       6       7    octet
>>>> ++-------+-------+-------+-------+-------+-------+-------+-------+
>>>> +| type                          | len                           |
>>>> ++-------------------------------+-------------------------------+
>>>> +| body
>>>> +...
>>>> +|       | padding (0 to 7 octets)                               |
>>>> ++-------+-------------------------------------------------------+
>>>> +```
>>>> +
>>>> +NOTE: padding octets here and in all subsequent format 
>>>> specifications must be
>>>> +      zero, unless stated otherwise.
>>>
>>> What about: "... are written as zero and should be ignored on read."
>>
>> I would rather not say "ignored" because it doesn't allow us to extend 
>> the record if needed in a safe way. The read side should abort if it 
>> sees an other value than 0 in the padding.
> 
> I'd rather ignore unknown fields. This allows to add optional data
> without having to special case it. 

You will need a special case for 0 in any case.

> Writing zeroes is the important part
> here, of course.
> 
> Ignoring those fields would e.g. enable a downgrade more easily, while
> aborting could make that impossible.

You are assuming the fields may contain optional data. Now imagine, we 
realize in a few months we missed some important fields. How would you 
describe the required fields?

I can see two ways:
     1) Re-using the padding fields if possible
     2) Extending the record

If you re-use the padding fields, then when you downgrade you may lose 
information. If you extend the size of the record, then you can't downgrade.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 15:55:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 15:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS0fG-0005FR-TZ; Fri, 24 Apr 2020 15:54:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Ms4E=6I=gmail.com=tamas.k.lengyel@srs-us1.protection.inumbo.net>)
 id 1jS0fF-0005FM-Ta
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 15:54:54 +0000
X-Inumbo-ID: ef9adf30-8643-11ea-b4f4-bc764e2007e4
Received: from mail-wm1-x32c.google.com (unknown [2a00:1450:4864:20::32c])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ef9adf30-8643-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 15:54:53 +0000 (UTC)
Received: by mail-wm1-x32c.google.com with SMTP id h2so11061815wmb.4
 for <xen-devel@lists.xenproject.org>; Fri, 24 Apr 2020 08:54:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=/ZqtHr3+ETOw5JhX8uQgYET34c9M1nH4rH52lecrW7o=;
 b=jzQANrGm+rWu1Zw+TbAtIPzVOV+MueEWMHaFQxVvuoZiQB5DaKEa1QqHr7CIONAQEP
 8azHKnaWGCE8FZTdKmnkS50ZwfHhbN7Q+eMoug11Dl+7PNF6Q6vWMgjMDjY006su2sQL
 +4k7TXhf4jS4c0ra/AfrOWqGbWkW6E/LnwO8N9UVAhX81mxCp8IgURjZQji79J/knbNE
 qU7H42V7QR/go45xAea+i7XK4Iut1aLFp6GGmnhKVzMVtSgr8TFjUjI/VgCQT4e0knxh
 Z4KY/4p53Vzjd+YyyiEdyAKh8w99NlMqrJUKS9nmRmkoDNs0K6XHjU5gzxTt0jwElp9a
 dSjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=/ZqtHr3+ETOw5JhX8uQgYET34c9M1nH4rH52lecrW7o=;
 b=DlswIgkG79UVEH27YaIaH/iBta+VB6xT4Bujjtw+ibG/eGkbLCOlfWsrnsO6ZwuPRS
 L9YipVAlwiLYLapn+SsSh4K1PIthywKFLIBfZxCzLZ/Jnufv2p1BBGcanMRJepx0g35o
 5tkbEhBCYpaX2lyR/Z1JneKKRD8k2dwYUsRXpna/e5mvl5bEZTaQCj2EiH335SdQ2aDJ
 AHXqsjxsULweQdg41J5brM+PuLlqxallz+W8qkykmSf2CipoNEQymNcvvjJ/emehHgLO
 ezjbbNT+SkE9ve5zTYS5t53DfI0kMSvbt7mLD3DEx6oHdkRZbYg42hj/xjlipquAqFWT
 Urng==
X-Gm-Message-State: AGi0PuZ4p8s8alZea3ZjW3Eljw9pfPRQJ9W82ecMUUACraGVCZSH6vZl
 /TDZqfNRLM0MpjaVxPAqrcnuSfYg4jynlk/hAkBNQg==
X-Google-Smtp-Source: APiQypIgltABdTL04G0DMEpfH+mSLIdZjesmvikTLrmyLu9U1G/V1JfB9jwku+czCXYTbrwwx2xToT97XT8pDxzERUA=
X-Received: by 2002:a05:600c:220c:: with SMTP id
 z12mr10644672wml.84.1587743692220; 
 Fri, 24 Apr 2020 08:54:52 -0700 (PDT)
MIME-Version: 1.0
References: <20200424073859.89-1-paul@xen.org>
In-Reply-To: <20200424073859.89-1-paul@xen.org>
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Date: Fri, 24 Apr 2020 09:54:15 -0600
Message-ID: <CABfawh=Vkwp96Q=2sFDYXAQrCHqA-MWxZHxfdTJx-fMEs0Md2Q@mail.gmail.com>
Subject: Re: [ANNOUNCE] Xen 4.14 Development Update
To: Xen-devel <xen-devel@lists.xenproject.org>,
 Paul Durrant <pdurrant@amazon.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, hongyxia@amazon.com,
 Jan Beulich <jbeulich@suse.com>, dwmw@amazon.com,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> *  VM forking (v11)
>   -  Tamas K Lengyel

v17 sent recently, hypervisor side is completely merged, only the
toolstack patch is waiting for review & merge

Tamas


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 15:59:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 15:59:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS0jh-0005QA-GF; Fri, 24 Apr 2020 15:59:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Nbk=6I=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jS0jf-0005Q5-SS
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 15:59:27 +0000
X-Inumbo-ID: 92aa066a-8644-11ea-94d3-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 92aa066a-8644-11ea-94d3-12813bfff9fa;
 Fri, 24 Apr 2020 15:59:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4EECBAC6D;
 Fri, 24 Apr 2020 15:59:25 +0000 (UTC)
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
To: Julien Grall <julien@xen.org>, Paul Durrant <paul@xen.org>,
 xen-devel@lists.xenproject.org
References: <20200424133736.737-1-paul@xen.org>
 <a1febde5-0a34-6480-6400-7142a6bb6f52@suse.com>
 <c7cb8073-44ef-c92e-2962-d427e1568748@xen.org>
 <8029c772-9c42-460c-e17c-85e18b32f102@suse.com>
 <7ae1bb1c-0029-c3f0-1565-e5f99effee51@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <33b38b41-9112-5a7f-7d3a-1663132b9603@suse.com>
Date: Fri, 24 Apr 2020 17:59:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7ae1bb1c-0029-c3f0-1565-e5f99effee51@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.20 17:44, Julien Grall wrote:
> 
> 
> On 24/04/2020 15:51, Jürgen Groß wrote:
>> On 24.04.20 16:38, Julien Grall wrote:
>>> Hi,
>>>
>>> On 24/04/2020 15:26, Jürgen Groß wrote:
>>>>> +```
>>>>> +    0       1       2       3       4       5       6       7    
>>>>> octet
>>>>> ++-------+-------+-------+-------+-------+-------+-------+-------+
>>>>> +| type                          | len                           |
>>>>> ++-------------------------------+-------------------------------+
>>>>> +| body
>>>>> +...
>>>>> +|       | padding (0 to 7 octets)                               |
>>>>> ++-------+-------------------------------------------------------+
>>>>> +```
>>>>> +
>>>>> +NOTE: padding octets here and in all subsequent format 
>>>>> specifications must be
>>>>> +      zero, unless stated otherwise.
>>>>
>>>> What about: "... are written as zero and should be ignored on read."
>>>
>>> I would rather not say "ignored" because it doesn't allow us to 
>>> extend the record if needed in a safe way. The read side should abort 
>>> if it sees an other value than 0 in the padding.
>>
>> I'd rather ignore unknown fields. This allows to add optional data
>> without having to special case it. 
> 
> You will need a special case for 0 in any case.

0 will need to have the "no optional data" semantics.

> 
>> Writing zeroes is the important part
>> here, of course.
>>
>> Ignoring those fields would e.g. enable a downgrade more easily, while
>> aborting could make that impossible.
> 
> You are assuming the fields may contain optional data. Now imagine, we 
> realize in a few months we missed some important fields. How would you 
> describe the required fields?
> 
> I can see two ways:
>      1) Re-using the padding fields if possible
>      2) Extending the record
> 
> If you re-use the padding fields, then when you downgrade you may lose 
> information. If you extend the size of the record, then you can't 
> downgrade.

If I extend the record and do a downgrade I'm losing the information,
too, as the old version won't read it in any case. BTW, extending the
record is no problem, as the length is stored in the header. Unknown
records (and extensions) will be just ignored when reading.

In your case when reusing the paddings and doing a downgrade you would
crash, as the paddings are no longer zero.

In case a downgrade should not be done due to vital information loss
then you should just not do it.


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 16:00:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 16:00:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS0l0-0006gi-W5; Fri, 24 Apr 2020 16:00:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mnRG=6I=amazon.co.uk=prvs=376452958=pdurrant@srs-us1.protection.inumbo.net>)
 id 1jS0kz-0006gZ-EE
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 16:00:49 +0000
X-Inumbo-ID: c3a13874-8644-11ea-94d3-12813bfff9fa
Received: from smtp-fw-6001.amazon.com (unknown [52.95.48.154])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c3a13874-8644-11ea-94d3-12813bfff9fa;
 Fri, 24 Apr 2020 16:00:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt;
 s=amazon201209; t=1587744049; x=1619280049;
 h=from:to:cc:date:message-id:references:in-reply-to:
 content-transfer-encoding:mime-version:subject;
 bh=cRXocry/SdioOAei97bJC5uvtohzfyAW1c6Zgm3xsq0=;
 b=skC2LTJbX9oLJopVviWbi9VGd3s82sHGEW6XoIDH/m2v3bEKEuJAvS9r
 ntu2rNrRMK2JVoYKwE/C7mM5X4lACTwjNXa7PDedik4WWjhS5LG6oYHkT
 Z3bCZ/pGewabHnbzZXtOROpaiYzq5zJYfVsaT81BH7Llc9Egt08H64sq4 A=;
IronPort-SDR: wHfuHWvDSaCzXv+GsK6wl2GSTzuQvKxwPkfpBM/9q0z3Risn2TbO96NBRUlMqKS7+KWOA3Nu4K
 tamy/xEHTqWg==
X-IronPort-AV: E=Sophos;i="5.73,311,1583193600"; d="scan'208";a="28596034"
Subject: RE: [ANNOUNCE] Xen 4.14 Development Update
Thread-Topic: [ANNOUNCE] Xen 4.14 Development Update
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO
 email-inbound-relay-1d-2c665b5d.us-east-1.amazon.com) ([10.43.8.6])
 by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP;
 24 Apr 2020 16:00:35 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166])
 by email-inbound-relay-1d-2c665b5d.us-east-1.amazon.com (Postfix) with ESMTPS
 id B8EC3A1D86; Fri, 24 Apr 2020 16:00:33 +0000 (UTC)
Received: from EX13D37EUB003.ant.amazon.com (10.43.166.251) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 24 Apr 2020 16:00:32 +0000
Received: from EX13D32EUC003.ant.amazon.com (10.43.164.24) by
 EX13D37EUB003.ant.amazon.com (10.43.166.251) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Fri, 24 Apr 2020 16:00:31 +0000
Received: from EX13D32EUC003.ant.amazon.com ([10.43.164.24]) by
 EX13D32EUC003.ant.amazon.com ([10.43.164.24]) with mapi id 15.00.1497.006;
 Fri, 24 Apr 2020 16:00:32 +0000
From: "Durrant, Paul" <pdurrant@amazon.co.uk>
To: Tamas K Lengyel <tamas.k.lengyel@gmail.com>, Xen-devel
 <xen-devel@lists.xenproject.org>
Thread-Index: AQHWGguEBjuxACUXz0mOoCZT0DeYwaiIbR6AgAABnfA=
Date: Fri, 24 Apr 2020 16:00:31 +0000
Message-ID: <6a05129703be4d34873ee5a21a808e8e@EX13D32EUC003.ant.amazon.com>
References: <20200424073859.89-1-paul@xen.org>
 <CABfawh=Vkwp96Q=2sFDYXAQrCHqA-MWxZHxfdTJx-fMEs0Md2Q@mail.gmail.com>
In-Reply-To: <CABfawh=Vkwp96Q=2sFDYXAQrCHqA-MWxZHxfdTJx-fMEs0Md2Q@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.165.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?utf-8?B?TWFyZWsgTWFyY3p5a293c2tpLUfDs3JlY2tp?=
 <marmarek@invisiblethingslab.com>, "Xia, Hongyan" <hongyxia@amazon.com>,
 Jan Beulich <jbeulich@suse.com>, "Woodhouse, David" <dwmw@amazon.co.uk>,
 =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiANCj4gPiAqICBWTSBmb3JraW5nICh2MTEp
DQo+ID4gICAtICBUYW1hcyBLIExlbmd5ZWwNCj4gDQo+IHYxNyBzZW50IHJlY2VudGx5LCBoeXBl
cnZpc29yIHNpZGUgaXMgY29tcGxldGVseSBtZXJnZWQsIG9ubHkgdGhlDQo+IHRvb2xzdGFjayBw
YXRjaCBpcyB3YWl0aW5nIGZvciByZXZpZXcgJiBtZXJnZQ0KPiANCg0KVGhhbmtzIGZvciB0aGUg
dXBkYXRlLg0KDQogIFBhdWwNCg==


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 16:03:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 16:03:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS0nk-0006r5-EZ; Fri, 24 Apr 2020 16:03:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=WQMg=6I=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jS0nj-0006qz-13
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 16:03:39 +0000
X-Inumbo-ID: 28dce3aa-8645-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 28dce3aa-8645-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 16:03:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=km2tNhygbS5JyFbHIAlrtTbSOfBt57LcUU+UeQl4Gyc=; b=2N+Oavz+Euet9G62ZFqHfh+c/6
 en/nfaZr6jpUiB95Jh4GIM+wZnBrPdFWFZW39Adakr/Lg8KW1B1MNWhRdl51m8hKDPnEDvqEYSQRH
 nV6DU6LgMFJHcbAUjZlV1FA0fidlaJnMxkyHCGKjEAEgh3lvFfaOu1N8oJNCAF6YZC4Q=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jS0nh-0004g1-J9; Fri, 24 Apr 2020 16:03:37 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jS0nh-0001qH-AT; Fri, 24 Apr 2020 16:03:37 +0000
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200424133736.737-1-paul@xen.org>
 <a1febde5-0a34-6480-6400-7142a6bb6f52@suse.com>
 <c7cb8073-44ef-c92e-2962-d427e1568748@xen.org>
 <8029c772-9c42-460c-e17c-85e18b32f102@suse.com>
 <7ae1bb1c-0029-c3f0-1565-e5f99effee51@xen.org>
 <33b38b41-9112-5a7f-7d3a-1663132b9603@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <e614fa8c-cea6-43f3-0bf2-003eabb4ae8f@xen.org>
Date: Fri, 24 Apr 2020 17:03:35 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <33b38b41-9112-5a7f-7d3a-1663132b9603@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 24/04/2020 16:59, Jürgen Groß wrote:
> On 24.04.20 17:44, Julien Grall wrote:
> If I extend the record and do a downgrade I'm losing the information,
> too, as the old version won't read it in any case. BTW, extending the
> record is no problem, as the length is stored in the header. Unknown
> records (and extensions) will be just ignored when reading.

That's very much up to the implementation. An implementation may decide 
to bail out if the record is not an exact size.

> 
> In your case when reusing the paddings and doing a downgrade you would
> crash, as the paddings are no longer zero.
> 
> In case a downgrade should not be done due to vital information loss
> then you should just not do it.

Of course, however I don't think a user will necessarily know it should 
not do it. So how do you protect against misuse?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 16:11:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 16:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS0vf-0007hi-9d; Fri, 24 Apr 2020 16:11:51 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2qtr=6I=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jS0vd-0007hd-Cc
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 16:11:49 +0000
X-Inumbo-ID: 4cae75a4-8646-11ea-9e09-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4cae75a4-8646-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 16:11:48 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A48DCAD11;
 Fri, 24 Apr 2020 16:11:46 +0000 (UTC)
Subject: Re: [XEN PATCH] xen/build: silence make warnings about missing
 auto.conf*
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200424143058.2546905-1-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <875778ca-dee2-0be4-bf35-54c439900baf@suse.com>
Date: Fri, 24 Apr 2020 18:11:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200424143058.2546905-1-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 16:30, Anthony PERARD wrote:
> In a clean tree, both files include/config/auto.conf{,.cmd} are
> missing and older version of GNU Make complain about it:
>     Makefile:103: include/config/auto.conf: No such file or directory
>     Makefile:106: include/config/auto.conf.cmd: No such file or directory
> 
> Those warnings are harmless, make will create the files and start over. But
> to avoid confusion, we'll use "-include" to silence the warning.
> 
> Those warning started to appear with commit 6c122d3984a5 ("xen/build:
> include include/config/auto.conf in main Makefile").
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 16:20:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 16:20:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS14D-00008n-5a; Fri, 24 Apr 2020 16:20:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=IwUP=6I=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jS14B-00008i-3E
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 16:20:39 +0000
X-Inumbo-ID: 886b23d4-8647-11ea-b58d-bc764e2007e4
Received: from mail-wm1-x329.google.com (unknown [2a00:1450:4864:20::329])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 886b23d4-8647-11ea-b58d-bc764e2007e4;
 Fri, 24 Apr 2020 16:20:38 +0000 (UTC)
Received: by mail-wm1-x329.google.com with SMTP id r26so11509248wmh.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Apr 2020 09:20:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=9bx51FvrRnVBJUfAFqmZlhxQJHQYPqoUXBbqDAvFKr4=;
 b=BQKWyuGvQD8pLMEHgdfFYnrgzJcKymI4F6Ie1ufnitB7O6rqrQFKW6bK3iW0rrIKbL
 NCaKwrzzuThRCRfantCUQr4TGf+uivt2V/1bDqupvLeB7r/h+xXAcjeXI3nG+Css2Pwc
 WHLJp8NHCGrAdJSN2hsGK8UXqXb73s+HjWNmPIh392jn5nKGL0gmNHoLVbiqz2hAuHEc
 wAU4yybFVet4BMUSuRVeapSKVBpDCmXJ0COUE9IJV6UfQWNVeoMh1VBjfjvdcuCUFo+v
 FQeAvJhcpznPY90EfPkc1bhOF4LwIwYwTUPMDfqREYjW2EqykqmphcMgdFok9lFskH17
 mMJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :thread-index:content-language;
 bh=9bx51FvrRnVBJUfAFqmZlhxQJHQYPqoUXBbqDAvFKr4=;
 b=mVUvSOOsPu4HWWm3vIQiYnHxFBDoAdvAZeKxaeh050DUOKEFgXDIFtHdvMn9BBbntl
 hC7L4Y3G94YI/W8Hw1twwsB4y4iSGfhUK8BQhFYDg0omrKlkww0hRdCfH+5FaI/IpSVN
 m8G4vZkC0/4YTJIZBcTQyRlO6+rP98owNYdxeHrjWrVRs2fWPlMReTLJ9gj4G/bpQwzc
 1OZ9+VYhFJGlyyjefMxjK1FtsCu7q+SisjU4+gHIjkYkGaUfwgZDprrIUbBGLsDE4eiW
 B4rhd1HyCYgorGV0sPffEwGRKHntTaTs8YIFq8/Xm4Yl/4ZdHRaXcCdCYETug+QlcbRm
 FGcA==
X-Gm-Message-State: AGi0PuYdtwjBjZ1P5+FETAf+Oeali1A/mvoobvTthsV0bDMvYm8oXQhP
 AueqAMxN/0ExZaRkVLwRn+A=
X-Google-Smtp-Source: APiQypJSgpxJFEKxQjfMKuo2AQbwwRkWk8TWMZDIt2g8G7SIOELK0aWAFmZ8ZxwiUb58eu74oUzoBw==
X-Received: by 2002:a1c:5fc4:: with SMTP id
 t187mr11461942wmb.181.1587745237395; 
 Fri, 24 Apr 2020 09:20:37 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id o3sm8880754wru.68.2020.04.24.09.20.36
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 24 Apr 2020 09:20:36 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
 =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= <jgross@suse.com>,
 <xen-devel@lists.xenproject.org>
References: <20200424133736.737-1-paul@xen.org>
 <a1febde5-0a34-6480-6400-7142a6bb6f52@suse.com>
 <c7cb8073-44ef-c92e-2962-d427e1568748@xen.org>
 <8029c772-9c42-460c-e17c-85e18b32f102@suse.com>
 <7ae1bb1c-0029-c3f0-1565-e5f99effee51@xen.org>
 <33b38b41-9112-5a7f-7d3a-1663132b9603@suse.com>
 <e614fa8c-cea6-43f3-0bf2-003eabb4ae8f@xen.org>
In-Reply-To: <e614fa8c-cea6-43f3-0bf2-003eabb4ae8f@xen.org>
Subject: RE: [PATCH] docs/designs: re-work the xenstore migration document...
Date: Fri, 24 Apr 2020 17:20:35 +0100
Message-ID: <000301d61a54$498f2020$dcad6060$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIqV5bkCWemUTYZznnWnEmKpB0tyAKBFuAqAldPX9kCaOHC9AKAOo04AlN1xhgB05tb1adws5MQ
Content-Language: en-gb
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Paul Durrant' <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 24 April 2020 17:04
> To: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>; Paul Durrant =
<paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Paul Durrant <pdurrant@amazon.com>
> Subject: Re: [PATCH] docs/designs: re-work the xenstore migration =
document...
>=20
> Hi,
>=20
> On 24/04/2020 16:59, J=C3=BCrgen Gro=C3=9F wrote:
> > On 24.04.20 17:44, Julien Grall wrote:
> > If I extend the record and do a downgrade I'm losing the =
information,
> > too, as the old version won't read it in any case. BTW, extending =
the
> > record is no problem, as the length is stored in the header. Unknown
> > records (and extensions) will be just ignored when reading.
>=20
> That's very much up to the implementation. An implementation may =
decide
> to bail out if the record is not an exact size.
>=20

It won't know. The record will be whatever size it says it is, and if =
the format doesn't match what the implementation was expecting then =
it'll probably crash.

> >
> > In your case when reusing the paddings and doing a downgrade you =
would
> > crash, as the paddings are no longer zero.
> >
> > In case a downgrade should not be done due to vital information loss
> > then you should just not do it.
>=20
> Of course, however I don't think a user will necessarily know it =
should
> not do it. So how do you protect against misuse?
>=20

The stream is versioned. If information is vital then I'd expect the =
version to be bumped, which should prevent a downgrade.

  Paul




From xen-devel-bounces@lists.xenproject.org Fri Apr 24 16:31:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 16:31:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS1EM-00013h-5m; Fri, 24 Apr 2020 16:31:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Nbk=6I=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jS1EL-00013c-0F
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 16:31:09 +0000
X-Inumbo-ID: fff18e42-8648-11ea-b4f4-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fff18e42-8648-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 16:31:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6DE59ABEA;
 Fri, 24 Apr 2020 16:31:06 +0000 (UTC)
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
To: paul@xen.org, 'Julien Grall' <julien@xen.org>,
 xen-devel@lists.xenproject.org
References: <20200424133736.737-1-paul@xen.org>
 <a1febde5-0a34-6480-6400-7142a6bb6f52@suse.com>
 <c7cb8073-44ef-c92e-2962-d427e1568748@xen.org>
 <8029c772-9c42-460c-e17c-85e18b32f102@suse.com>
 <7ae1bb1c-0029-c3f0-1565-e5f99effee51@xen.org>
 <33b38b41-9112-5a7f-7d3a-1663132b9603@suse.com>
 <e614fa8c-cea6-43f3-0bf2-003eabb4ae8f@xen.org>
 <000301d61a54$498f2020$dcad6060$@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <4763e0d9-07b9-af23-fb69-42d25ceb3295@suse.com>
Date: Fri, 24 Apr 2020 18:31:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <000301d61a54$498f2020$dcad6060$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Paul Durrant' <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.20 18:20, Paul Durrant wrote:
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Sent: 24 April 2020 17:04
>> To: Jürgen Groß <jgross@suse.com>; Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
>> Cc: Paul Durrant <pdurrant@amazon.com>
>> Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
>>
>> Hi,
>>
>> On 24/04/2020 16:59, Jürgen Groß wrote:
>>> On 24.04.20 17:44, Julien Grall wrote:
>>> If I extend the record and do a downgrade I'm losing the information,
>>> too, as the old version won't read it in any case. BTW, extending the
>>> record is no problem, as the length is stored in the header. Unknown
>>> records (and extensions) will be just ignored when reading.
>>
>> That's very much up to the implementation. An implementation may decide
>> to bail out if the record is not an exact size.
>>
> 
> It won't know. The record will be whatever size it says it is, and if the format doesn't match what the implementation was expecting then it'll probably crash.
> 
>>>
>>> In your case when reusing the paddings and doing a downgrade you would
>>> crash, as the paddings are no longer zero.
>>>
>>> In case a downgrade should not be done due to vital information loss
>>> then you should just not do it.
>>
>> Of course, however I don't think a user will necessarily know it should
>> not do it. So how do you protect against misuse?
>>
> 
> The stream is versioned. If information is vital then I'd expect the version to be bumped, which should prevent a downgrade.

Uh, this is problematic. I agree that a downgrade will be prevented, but
merely via a crash. We won't have both versions active in parallel, but
the version we are updating to will make it or not. There is no way
back.

The general rule should be to be as forgiving to errors in the stream
as possible in order _not_ to have a crashing xenstored due to strict
parameter testing.

And in case there is a potential of problems it needs to be documented
and then its up to the user to follow the documentation.


Juergen


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 16:50:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 16:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS1Wt-0002j8-Lk; Fri, 24 Apr 2020 16:50:19 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jS1Ws-0002j3-Uf
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 16:50:18 +0000
X-Inumbo-ID: ace2958b-864b-11ea-94dc-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ace2958b-864b-11ea-94dc-12813bfff9fa;
 Fri, 24 Apr 2020 16:50:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=lR6PZhVZ9dcM9/kLXtoFz/3AXyNU8c3ngFZ1xFF9kQk=; b=iwvhe59IDk9U+j75vs7aPJbw8
 LMjOeYDSZpGgpShWYatwXV8ioV9mu/lbwJ4ECPUaYb3BVD27rBHiyaN8vndGBvlKIXREG5Zkq94ER
 Is5JOe3mHQUMdrbF0EPu/qUlE7N+Ij4NKAZckFZv+cJLwrn+lOmUmr7KS25vPUl2pALdw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS1Wr-0005b5-7u; Fri, 24 Apr 2020 16:50:17 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS1Wq-0005dz-V4; Fri, 24 Apr 2020 16:50:16 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jS1Wq-0001CM-UL; Fri, 24 Apr 2020 16:50:16 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149784-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149784: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
X-Osstest-Versions-That: xen=aa14feb6723d3bb15a884533ade1cd9732792145
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 16:50:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149784 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149784/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2
baseline version:
 xen                  aa14feb6723d3bb15a884533ade1cd9732792145

Last test of basis   149769  2020-04-23 16:00:35 Z    1 days
Testing same since   149784  2020-04-24 14:00:40 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   aa14feb672..96b5c267e5  96b5c267e52657e99bd1bbf81dd51925447115e2 -> smoke


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 18:43:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 18:43:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS3IV-0003MG-DD; Fri, 24 Apr 2020 18:43:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jS3IT-0003Lk-Fc
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 18:43:33 +0000
X-Inumbo-ID: 7e738f92-865b-11ea-94f3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7e738f92-865b-11ea-94f3-12813bfff9fa;
 Fri, 24 Apr 2020 18:43:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=7MYTHGfrDcW8bzvH2vjB4kRexieJ5W1esw40pXupiEo=; b=HYUCsZyHlC1ZIlJiqMqjp29iw
 yO3gK8r+CNduSVSS/jFJn0cTtn3nut0LAIg3Us5+hlPb0KjriVjJ4MGXYbOjtll6D4alhxwuGbTi3
 HPRoxcR0tyfWRi5C3NswL/9M+DYz1+Q6alr8GhW0UA9eJ09jevYR7XcIKSYQxhIANhCHs=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS3IQ-0007yS-PS; Fri, 24 Apr 2020 18:43:30 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS3IQ-00037f-9r; Fri, 24 Apr 2020 18:43:30 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jS3IQ-0006ME-9F; Fri, 24 Apr 2020 18:43:30 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149772-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149772: tolerable trouble: fail/pass/starved -
 PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 linux-linus:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: linux=b4f633221f0aeac102e463a4be46a643b2e3b819
X-Osstest-Versions-That: linux=c578ddb39e565139897124e74e5a43e56538cb33
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 18:43:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149772 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149772/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     16 guest-localmigrate           fail  like 149764
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149764
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149764
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149764
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149764
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149764
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat    fail  like 149764
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149764
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149764
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149764
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate               starved  n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate               starved  n/a

version targeted for testing:
 linux                b4f633221f0aeac102e463a4be46a643b2e3b819
baseline version:
 linux                c578ddb39e565139897124e74e5a43e56538cb33

Last test of basis   149764  2020-04-23 14:40:00 Z    1 days
Testing same since   149772  2020-04-24 03:58:26 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Eric W. Biederman" <ebiederm@xmission.com>
  Aaro Koskinen <aaro.koskinen@iki.fi>
  Ahmad Fatoum <a.fatoum@pengutronix.de>
  Alex Elder <elder@linaro.org>
  Arnd Bergmann <arnd@arndb.de>
  Bjorn Andersson <bjorn.andersson@linaro.org>
  Bjorn Helgaas <bhelgaas@google.com>
  Christian Brauner <christian.brauner@ubuntu.com>
  Chuck Lever <chuck.lever@oracle.com>
  Eric Sandeen <sandeen@sandeen.net>
  Eric W. Biederman <ebiederm@xmission.com>
  Florian Fainelli <f.fainelli@gmail.com>
  Jason Yan <yanaijie@huawei.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  Luis Mendes <luis.p.mendes@gmail.com>
  Michal Simek <michal.simek@xilinx.com>
  Namjae Jeon <namjae.jeon@samsung.com>
  Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
  Oleg Nesterov <oleg@redhat.com>
  Pali Rohár <pali@kernel.org>
  Paul Moore <paul@paul-moore.com>
  Peng Fan <peng.fan@nxp.com>
  Rob Herring <robh@kernel.org>
  Roland Hieber <rhi@pengutronix.de>
  Tetsuhiro Kohada <Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp>
  Thierry Reding <treding@nvidia.com>
  Thomas Backlund <tmb@mageia.org>
  Tony Lindgren <tony@atomide.com>
  Vasily Averin <vvs@virtuozzo.com>
  Yihao Wu <wuyihao@linux.alibaba.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                starved 
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 starved 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   c578ddb39e56..b4f633221f0a  b4f633221f0aeac102e463a4be46a643b2e3b819 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 19:20:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 19:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS3sP-0006d6-HZ; Fri, 24 Apr 2020 19:20:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1Gyd=6I=redhat.com=armbru@srs-us1.protection.inumbo.net>)
 id 1jS3sO-0006d1-TO
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 19:20:40 +0000
X-Inumbo-ID: af1ae10e-8660-11ea-94ff-12813bfff9fa
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id af1ae10e-8660-11ea-94ff-12813bfff9fa;
 Fri, 24 Apr 2020 19:20:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1587756039;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=JCs/MUWiOabJCVAQ8sLvUQgrb8weKuUkchaXXg61HdM=;
 b=HfiW4QbjHna2jbBAEL2OUiajy2BviIqCw8Ci9M3+QkY2B7wWb0oqvuk8lXi7DUB0w3PRWz
 YRhrCqZsh8+Z1s54i4uxcwsbP13thJdcCdyQvWiSH8i92Fmlb46kdugMpgVIWkLAReiHGS
 q1Iik1A9T97qEUeBlwrvI2fB0yccwmg=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-493-0hfApBy5PNeX1QqpGuxL5A-1; Fri, 24 Apr 2020 15:20:35 -0400
X-MC-Unique: 0hfApBy5PNeX1QqpGuxL5A-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com
 [10.5.11.23])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7E07684B8A0;
 Fri, 24 Apr 2020 19:20:32 +0000 (UTC)
Received: from blackfin.pond.sub.org (ovpn-113-6.ams2.redhat.com [10.36.113.6])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id 742121A925;
 Fri, 24 Apr 2020 19:20:29 +0000 (UTC)
Received: by blackfin.pond.sub.org (Postfix, from userid 1000)
 id 2DB3011358BE; Fri, 24 Apr 2020 21:20:27 +0200 (CEST)
From: Markus Armbruster <armbru@redhat.com>
To: qemu-devel@nongnu.org
Subject: [PATCH 02/11] xen: Fix and improve handling of device_add usb-host
 errors
Date: Fri, 24 Apr 2020 21:20:18 +0200
Message-Id: <20200424192027.11404-3-armbru@redhat.com>
In-Reply-To: <20200424192027.11404-1-armbru@redhat.com>
References: <20200424192027.11404-1-armbru@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <sstabellini@kernel.org>, Gerd Hoffmann <kraxel@redhat.com>,
 Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

usbback_portid_add() leaks the error when qdev_device_add() fails.
Fix that.  While there, use the error to improve the error message.

The qemu_opts_from_qdict() similarly leaks on failure.  But any
failure there is a programming error.  Pass &error_abort.

Fixes: 816ac92ef769f9ffc534e49a1bb6177bddce7aa2
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Paul Durrant <paul@xen.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 hw/usb/xen-usb.c | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 961190d0f7..42643c3390 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -30,6 +30,7 @@
 #include "hw/usb.h"
 #include "hw/xen/xen-legacy-backend.h"
 #include "monitor/qdev.h"
+#include "qapi/error.h"
 #include "qapi/qmp/qdict.h"
 #include "qapi/qmp/qstring.h"
=20
@@ -755,13 +756,15 @@ static void usbback_portid_add(struct usbback_info *u=
sbif, unsigned port,
     qdict_put_int(qdict, "port", port);
     qdict_put_int(qdict, "hostbus", atoi(busid));
     qdict_put_str(qdict, "hostport", portname);
-    opts =3D qemu_opts_from_qdict(qemu_find_opts("device"), qdict, &local_=
err);
-    if (local_err) {
-        goto err;
-    }
+    opts =3D qemu_opts_from_qdict(qemu_find_opts("device"), qdict,
+                                &error_abort);
     usbif->ports[port - 1].dev =3D USB_DEVICE(qdev_device_add(opts, &local=
_err));
     if (!usbif->ports[port - 1].dev) {
-        goto err;
+        qobject_unref(qdict);
+        xen_pv_printf(&usbif->xendev, 0,
+                      "device %s could not be opened: %s\n",
+                      busid, error_get_pretty(local_err));
+        error_free(local_err);
     }
     qobject_unref(qdict);
     speed =3D usbif->ports[port - 1].dev->speed;
@@ -793,11 +796,6 @@ static void usbback_portid_add(struct usbback_info *us=
bif, unsigned port,
     usbback_hotplug_enq(usbif, port);
=20
     TR_BUS(&usbif->xendev, "port %d attached\n", port);
-    return;
-
-err:
-    qobject_unref(qdict);
-    xen_pv_printf(&usbif->xendev, 0, "device %s could not be opened\n", bu=
sid);
 }
=20
 static void usbback_process_port(struct usbback_info *usbif, unsigned port=
)
--=20
2.21.1



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 19:51:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 19:51:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS4Lx-0000hF-41; Fri, 24 Apr 2020 19:51:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jS4Lv-0000h4-Re
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 19:51:11 +0000
X-Inumbo-ID: ecbc3592-8664-11ea-9506-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ecbc3592-8664-11ea-9506-12813bfff9fa;
 Fri, 24 Apr 2020 19:51:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=GdGdEeVHBCou1YNUszSW5gpppT6WU0F/NuvTLMRjlUE=; b=bpYkay+WF+Rm/su7lxpkh4Tib
 JB4mSAfEyvVkbaGjfnZmpaZ7WnmomLiSlyUkwaCC49xWR2gV67ds35JPhJecN28xXCH4r1v4oNtKw
 7Kmp/UMycV6qRjqE2Wlcl4O2rlaYLxFS+NjzEfxE1o9RaHN3FOyLVtXVYE1YXS6FAH0Sg=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS4Lm-0000t4-Go; Fri, 24 Apr 2020 19:51:02 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS4Lm-0007il-8U; Fri, 24 Apr 2020 19:51:02 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jS4Lm-00077p-7q; Fri, 24 Apr 2020 19:51:02 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149785-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149785: regressions - FAIL
X-Osstest-Failures: xen-unstable-smoke:build-amd64:xen-build:fail:regression
 xen-unstable-smoke:build-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=3acfd35b61688ad9a5b843ee923221eb36e0b613
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 19:51:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149785 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149785/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 149784

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  3acfd35b61688ad9a5b843ee923221eb36e0b613
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149784  2020-04-24 14:00:40 Z    0 days
Testing same since   149785  2020-04-24 17:01:40 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-amd64-libvirt                                     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.

------------------------------------------------------------
commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Apr 24 15:49:23 2020 +0100

    Update QEMU_TRADITIONAL_REVISION
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 20:30:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 20:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS4xU-0003Q4-1D; Fri, 24 Apr 2020 20:30:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jla4=6I=nxp.com=andrei.cherechesu@srs-us1.protection.inumbo.net>)
 id 1jS4xS-0003Pz-7j
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 20:29:58 +0000
X-Inumbo-ID: 5b5f1fd0-866a-11ea-9e09-bc764e2007e4
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown
 [40.107.8.49]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5b5f1fd0-866a-11ea-9e09-bc764e2007e4;
 Fri, 24 Apr 2020 20:29:55 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Id7UHRY36KSui1J+eVFt712qXx642MwW+Iha4V3NISIJdDWPfbj8P2XKF9RBIbHsjH6H2oXiaanq1CM9z2MwIcrR8UTCC9G471O+4JH0AvU+F906tIQyvWLNtAMdlvgxHhhvUfrUSkaTPO0hZrjUITkFJ4FDH+13CgwmV02Hi2caVfGjhZtMiMugYKNHaIcTJA4r8kFi6Z0odt9924QQk/N7O4OPhuQN8H4IXArQiu3h5uDhPmr1wKzvE98k2agUhEXYykmsAcqnP2bitXWmUg1S5ex0a5JAZEWm7RpyhIUN5YjwGkNAsAqESF9UnfGEgEIWlAHuSnuS8WAuFhMGvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Qm/PBDohmG5CFOQupDFGRlbnhPnzF9MU27NvNwOhObw=;
 b=mlakdOeFMhlAtl+xXX0fX0FTKeTBlfu6ifurXIyLr7+nOBkvFR1opcgzOmT6FP2W9laexneGg2lqn2WDaEsvRyeS2++3FH1mTmnLI74S3g1/xYo/wGbNZ7ZrYLl28IqLa52W7YQxlKad2ZYtgBcdKF3Q24egWo72sgfEk2BY59y5GGVXxNkhp1vX0exKzSD/lIhVFfQr+8lLUiWm033EWRyrlPNGRiZf8hU5si5XADbjjHviE8nqXDzj2lMbTWWx4v4GhAcvk8Trvrl0dTZ6Emm2yA/8cdzXdbZWFnCRSvg3Vt5RimXB0sD1+l/2iTQ8bRFZKIUC8T9PJAxMhDm+JQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass
 header.d=nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Qm/PBDohmG5CFOQupDFGRlbnhPnzF9MU27NvNwOhObw=;
 b=NO3DqQDkTCzLQbQ0QL6I+CnlpLj/JssjlFiJxRGt0kPOTyb87zRz3zkpQT3LwQyeYtXcOuGG4YjON1xgAq2AjA0oRnFdsOPvuncoJJVkokUOQQKz028DBfr8r2sHd6MaOeVsw5lyXidjhE2QGaVXUIuaPA6ZG2cy+hznbXakKog=
Received: from VI1PR04MB5056.eurprd04.prod.outlook.com (2603:10a6:803:5a::13)
 by VI1PR04MB4302.eurprd04.prod.outlook.com (2603:10a6:803:3f::29)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Fri, 24 Apr
 2020 20:29:53 +0000
Received: from VI1PR04MB5056.eurprd04.prod.outlook.com
 ([fe80::3caf:57a5:e39f:d13b]) by VI1PR04MB5056.eurprd04.prod.outlook.com
 ([fe80::3caf:57a5:e39f:d13b%6]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020
 20:29:53 +0000
From: Andrei Cherechesu <andrei.cherechesu@nxp.com>
To: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>
Subject: arm: DomU Networking enable leads to Dom0 kernel oops
Thread-Topic: arm: DomU Networking enable leads to Dom0 kernel oops
Thread-Index: AdYaclAiZQv5zvC+SH+brmHp3N+n3w==
Date: Fri, 24 Apr 2020 20:29:53 +0000
Message-ID: <VI1PR04MB505620B32C8289C6106D0B2AF9D00@VI1PR04MB5056.eurprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=andrei.cherechesu@nxp.com; 
x-originating-ip: [78.97.145.157]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 90195d6f-4cd6-41ad-c4ad-08d7e88e3ed7
x-ms-traffictypediagnostic: VI1PR04MB4302:
x-microsoft-antispam-prvs: <VI1PR04MB430218C9D6ACE214575EBA78F9D00@VI1PR04MB4302.eurprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 03838E948C
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:VI1PR04MB5056.eurprd04.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(4636009)(346002)(39860400002)(376002)(396003)(136003)(366004)(4326008)(6506007)(66476007)(76116006)(66446008)(186003)(64756008)(9686003)(478600001)(66556008)(5660300002)(33656002)(966005)(44832011)(2906002)(71200400001)(86362001)(55016002)(66946007)(8676002)(110136005)(81156014)(316002)(8936002)(26005)(9326002)(52536014)(7696005)(10126625002);
 DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: duPTUTJfC8dXdq0OIBuPFxsnh7XKCH0h2nnR9gJ5awUWUYBGe/va9i4uVbIja36wLsB7O/RHhL3xvXvmULpY3SlNFHQKdQklWNpBsUihy73ia8DbRGblwL0T8OGFABtayKp4IYPRJ/tYYn9VIlXxCSAcHAuCcG/i+Wj01QZPOYAHmKSK70V1VvtVirbT87FbgyMANGY8SbHP8PylQYjXY/eWNNeUtLQBedm0s6j9OUx6W67ziwKkdqOd04hY4f2kDQ9EazUlC9BmFWRH/VdCYv++SrVczxtYabWOOshIaeFRQU9ipf3LT5CwpIhJaEUab3MVeBUOY2RcGI7GJhE46EQoYu0iZhPck5WHDBzk3ybtWHR4MDGSldIzZYwH0YpZ4uTsSiVJk2uAeS+tadvzV38CXtjJN+//oJkN5rfZfOEe2adiJha6OuHFFEzexkI1E8oj5nglQLzV4rHSr1A4T8U4krfbZCcVL84oN0Q86w0+AX5pEaojtydP+Va885zr0l2xGmU0V0kYjfK8Nht5bajtlyR0ppkimv2jD/lro5nyIEUJonNBvIutI3yrq1hzRpERIiV1cYDq2Wc2pmrwuw==
x-ms-exchange-antispam-messagedata: MKw+eGB/H1xYuWfnoQ5oC+CgLZawuRxr4gQXj93ulWAm8dcuAohBV4Hx8Cokg9HFu3slnGkC+85MFjCerV8KGuBMyyr8gWgpfJy8Hyy7PJMNSCRGUKAjeU4ihOMyOzHEtzCITMBS3AwQR1IKBclkSV1nFcdxPOvZfVk+zB2D2l7SXW/UwgkpKovumGWCNodHoWM9abZ20YkfYkHxOWib2Y+UzX6ap1tYE6adnf1klXMDCvkBc3Mp2pU2U+OJa0w8RhlAgstcf82HhMRwisyuSMUBQRm2mWvVn3FuHWHay2HgacQii6JBhmWO5I1oQPkq7eMh/EavDRx463M/dK4MBbLtGS3HGh5jJIjD2kxEO1yLKXnUPGbxrHyvNz9OfqbaDyyU537yJ0p23a/q33VdXj+5fkTtwfzFR2Zve5WBEGf4lK3Cj3ICl5OGdvaetmT9oDW+WVUxKVrIFFVjrTf93hrO4FhE7uJIE21ErAls7YiclZYrBK955BBxJvyH3aKwBV10FxZOAQ2dUV1DR73jh6ReCgQV6qabZWBa4OzPC/8xMVv7kxsMUXxhlQCW5gPfndqXjaQKvGerDWuPBdUA3SfaVoegia5vFNX2xzqBmYBk03G79NA4VpQ+Zw0vKg6caNhZLjNz+Dg8VyJXAmyxwkIPzSphvWLPLSg/hXFJpdzSnALu7rBvLe1HpBO2VsMDfs55xcdFo3eKcMKSKHyj6ICRmvr+lHBDAhRejYZw/k/WZ3E8se3bBd3MAuLfIeQM04SpJE5VbWG7iKS5BUJepBQoeBP2wWJZUWad3zsYgg8=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
 boundary="_000_VI1PR04MB505620B32C8289C6106D0B2AF9D00VI1PR04MB5056eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 90195d6f-4cd6-41ad-c4ad-08d7e88e3ed7
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 20:29:53.2563 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WNni15NphuuEGLk46XPSyn6vGWFirHiwkg3CzkMRKjZ01jMKo1Mz4TEm3k4uVZfW2qQtRwWHfDdnOIk68edmRr4uXQJYIFLowMWaXccEzhM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4302
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--_000_VI1PR04MB505620B32C8289C6106D0B2AF9D00VI1PR04MB5056eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

Recently I've been trying to enable the networking in a conventional DomU (=
not dom0less).
The approach I used was the one described here: https://wiki.xen.org/wiki/X=
en_Networking#Bridging.

But when I use xl to create DomU, I get a Kernel OOPS in Dom0. The setup is=
 still responsive after this
and DomU boots successfully. However, if I try to enable `eth0` in DomU (us=
ing ip link dev set eth0 up),
I get a Kernel Panic in Dom0.

Here are the complete steps:

  1.  Boot Dom0 and configure bridge:
     *   brctl addbr xenbr0
     *   brctl addif xenbr0 eth0
     *   ip link set dev xenbr0 up
     *   ip link set dev eth0 up
     *   dhclient xenbr0



  1.  ifconfig xenbr0 (ping 8.8.8.8 works):
xenbr0    Link encap:Ethernet  HWaddr B2:62:37:C9:BB:D7
          inet addr:192.168.0.185  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::b062:37ff:fec9:bbd7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:703 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:88213 (86.1 KiB)  TX bytes:3088 (3.0 KiB)


  1.  ifconfig eth0:
eth0      Link encap:Ethernet  HWaddr B2:62:37:C9:BB:D7
          inet6 addr: fe80::b062:37ff:fec9:bbd7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1535 errors:0 dropped:2 overruns:0 frame:0
          TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:450476 (439.9 KiB)  TX bytes:4248 (4.1 KiB)
          Interrupt:59 Base address:0xc000


  1.  Add bridge to DomU config file:
vif =3D [ 'bridge=3Dxenbr0' ]


  1.  root@s32g274aevb-Dom0:~# xl create /etc/xen/domU1.cfg
After this I get the Kernel OOPS, because of a failed memory
access
[  413.367873] Unable to handle kernel paging request at virtual address 00=
0006c000020070
In
               [  413.548189]  xenvif_rx_ring_slots_available+0x40/0xa0 [xe=
n_netback]

The full log is attached at [0]<https://pastebin.com/sJLfd4gL>.
Using gdb, I found out that the access corresponds to the following source =
code lines:
               =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
               (gdb)  l *xenvif_rx_ring_slots_available+0x40
0x65b0 is in xenvif_rx_ring_slots_available (/usr/src/kernel/include/linux/=
skbuff.h:4084).
4082      static inline bool skb_is_gso(const struct sk_buff *skb)
4083      {
4084                     return skb_shinfo(skb)->gso_size;
4085      }
                              =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


  1.  DomU boots, and then: root@s32g274aevb-DomU1:~# ip link set dev eth0 =
up

After this, I get a kernel panic in Dom0 because of another failed memory
access
               [ 5338.574809] Unable to handle kernel paging request at vir=
tual address 000000c0ffff0028
in
               [ 5338.753128]  xenvif_tx_build_gops+0x528/0xef8 [xen_netbac=
k]

               The full log is attached at [1]<https://pastebin.com/iaF1q3U=
M>.
               Using gdb again, I found out the corresponding source code:
                              =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(gdb) l *xenvif_tx_build_gops+0x528
0xce8 is in xenvif_tx_build_gops (/usr/src/kernel/include/linux/skbuff.h:12=
72).
1269      #ifdef NET_SKBUFF_DATA_USES_OFFSET
1270      static inline unsigned char *skb_end_pointer(const struct sk_buff=
 *skb)
1271      {
1272                     return skb->head + skb->end;
1273      }
                              =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Do you have any idea why this occurs? Have I misconfigured anything?

I've also tried to pass a static IP configuration for DomU in the config fi=
le,
and because it automatically enables eth0 at boot time, I no longer get the
oops, but a panic directly.

Thank you very much for your help,
Andrei Cherechesu,
NXP Semiconductors

--_000_VI1PR04MB505620B32C8289C6106D0B2AF9D00VI1PR04MB5056eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1783960777;
	mso-list-type:hybrid;
	mso-list-template-ids:183803794 422091018 67698689 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-weight:bold;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Recently I&#8217;ve been trying to enable the networ=
king in a conventional DomU (not dom0less).<o:p></o:p></p>
<p class=3D"MsoNormal">The approach I used was the one described here: <a h=
ref=3D"https://wiki.xen.org/wiki/Xen_Networking#Bridging">
https://wiki.xen.org/wiki/Xen_Networking#Bridging</a>.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">But when I use xl to create DomU, I get a Kernel OOP=
S in Dom0. The setup is still responsive after this<o:p></o:p></p>
<p class=3D"MsoNormal">and DomU boots successfully. However, if I try to en=
able `eth0` in DomU (using ip link dev set eth0 up),<o:p></o:p></p>
<p class=3D"MsoNormal">I get a Kernel Panic in Dom0.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Here are the complete steps:<o:p></o:p></p>
<ol style=3D"margin-top:0in" start=3D"1" type=3D"1">
<li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:l0 level1 =
lfo1"><b>Boot Dom0 and configure bridge</b>:<o:p></o:p></li><ul style=3D"ma=
rgin-top:0in" type=3D"disc">
<li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:l0 level2 =
lfo1">brctl addbr xenbr0<o:p></o:p></li><li class=3D"MsoListParagraph" styl=
e=3D"margin-left:0in;mso-list:l0 level2 lfo1">brctl addif xenbr0 eth0<o:p><=
/o:p></li><li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:=
l0 level2 lfo1">ip link set dev xenbr0 up<o:p></o:p></li><li class=3D"MsoLi=
stParagraph" style=3D"margin-left:0in;mso-list:l0 level2 lfo1">ip link set =
dev eth0 up<o:p></o:p></li><li class=3D"MsoListParagraph" style=3D"margin-l=
eft:0in;mso-list:l0 level2 lfo1">dhclient xenbr0<o:p></o:p></li></ul>
</ol>
<p class=3D"MsoListParagraph" style=3D"margin-left:1.0in"><o:p>&nbsp;</o:p>=
</p>
<ol style=3D"margin-top:0in" start=3D"2" type=3D"1">
<li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:l0 level1 =
lfo1"><b>ifconfig xenbr0
</b>(ping 8.8.8.8 works):<b><o:p></o:p></b></li></ol>
<p class=3D"MsoNormal">xenbr0&nbsp;&nbsp;&nbsp; Link encap:Ethernet&nbsp; H=
Waddr B2:62:37:C9:BB:D7<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; inet addr:192.168.0.185&nbsp; Bcast:192.168.0.255&nbsp; Mask:255.255.255=
.0<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; inet6 addr: fe80::b062:37ff:fec9:bbd7/64 Scope:Link<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; UP BROADCAST RUNNING MULTICAST&nbsp; MTU:1500&nbsp; Metric:1<o:p></o:p><=
/p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; RX packets:703 errors:0 dropped:0 overruns:0 frame:0<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; TX packets:27 errors:0 dropped:0 overruns:0 carrier:0<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; collisions:0 txqueuelen:1000 <o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;RX bytes:88213 (86.1 KiB)&nbsp; TX bytes:3088 (3.0 KiB)<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<ol style=3D"margin-top:0in" start=3D"3" type=3D"1">
<li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:l0 level1 =
lfo1"><b>ifconfig eth0</b>:<o:p></o:p></li></ol>
<p class=3D"MsoNormal">eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Link encap:Ethern=
et&nbsp; HWaddr B2:62:37:C9:BB:D7&nbsp; <o:p>
</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;inet6 addr: fe80::b062:37ff:fec9:bbd7/64 Scope:Link<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; UP BROADCAST RUNNING MULTICAST&nbsp; MTU:1500&nbsp; Metric:1<o:p></o:p><=
/p>
<p class=3D"MsoNormal">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;RX packets:1535 errors:0 dropped:2 overruns:0 frame:0<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; TX packets:43 errors:0 dropped:0 overruns:0 carrier:0<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; collisions:0 txqueuelen:1000 <o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;RX bytes:450476 (439.9 KiB)&nbsp; TX bytes:4248 (4.1 KiB)<o:p></o:p=
></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Interrupt:59 Base address:0xc000<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<ol style=3D"margin-top:0in" start=3D"4" type=3D"1">
<li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:l0 level1 =
lfo1"><b>Add bridge to DomU config file</b>:<o:p></o:p></li></ol>
<p class=3D"MsoNormal" style=3D"text-indent:.5in">vif =3D [ 'bridge=3Dxenbr=
0' ]<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-indent:.5in"><o:p>&nbsp;</o:p></p>
<ol style=3D"margin-top:0in" start=3D"5" type=3D"1">
<li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:l0 level1 =
lfo1"><b>root@s32g274aevb-Dom0:~# xl create /etc/xen/domU1.cfg<o:p></o:p></=
b></li></ol>
<p class=3D"MsoNormal" style=3D"margin-left:.5in">After this I get the Kern=
el OOPS, because of a failed memory<o:p></o:p></p>
<p class=3D"MsoNormal">access <o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-indent:.5in">[&nbsp; 413.367873] Unabl=
e to handle kernel paging request at virtual address 000006c000020070<o:p><=
/o:p></p>
<p class=3D"MsoNormal">In<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [&nbsp; 413.548189]&nbsp; xenvif_rx_ring_s=
lots_available&#43;0x40/0xa0 [xen_netback]<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-indent:.5in">The full log is attached =
at <a href=3D"https://pastebin.com/sJLfd4gL">
[0]</a>.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in">Using gdb, I found out th=
at the access corresponds to the following source code lines:<o:p></o:p></p=
>
<p class=3D"MsoNormal" style=3D"margin-left:.5in">&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in">&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (gdb)&nbsp; l *=
xenvif_rx_ring_slots_available&#43;0x40<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:1.0in">0x65b0 is in xenvif_rx_r=
ing_slots_available (/usr/src/kernel/include/linux/skbuff.h:4084).<o:p></o:=
p></p>
<p class=3D"MsoNormal" style=3D"margin-left:1.0in">4082&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; static inline bool skb_is_gso(const struct sk_buff *skb)<o:p></o=
:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:1.0in">4083&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; {<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:1.0in">4084&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; return skb_shinfo(skb)-&gt;gso_size;<o:p></o:p></=
p>
<p class=3D"MsoNormal" style=3D"margin-left:1.0in">4085&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; }<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<ol style=3D"margin-top:0in" start=3D"6" type=3D"1">
<li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:l0 level1 =
lfo1"><b>DomU boots, and then: root@s32g274aevb-DomU1:~# ip link set dev et=
h0 up</b><o:p></o:p></li></ol>
<p class=3D"MsoListParagraph">After this, I get a kernel panic in Dom0 beca=
use of another failed memory<o:p></o:p></p>
<p class=3D"MsoNormal">access<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ 5338.574809] Unable to handle kernel pag=
ing request at virtual address 000000c0ffff0028<o:p></o:p></p>
<p class=3D"MsoNormal">in<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ 5338.753128]&nbsp; xenvif_tx_build_gops&=
#43;0x528/0xef8 [xen_netback]<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The full log is attached at <a href=3D"htt=
ps://pastebin.com/iaF1q3UM">
[1]</a>.<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Using gdb again, I found out the correspon=
ding source code:<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o=
:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:.5in">(gdb) l =
*xenvif_tx_build_gops&#43;0x528<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:.5in">0xce8 is=
 in xenvif_tx_build_gops (/usr/src/kernel/include/linux/skbuff.h:1272).<o:p=
></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:.5in">1269&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; #ifdef NET_SKBUFF_DATA_USES_OFFSET<o:p></o:p></p=
>
<p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:.5in">1270&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; static inline unsigned char *skb_end_pointer(con=
st struct sk_buff *skb)<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:.5in">1271&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; {<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:.5in">1272&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return skb-&gt;head &#43; skb-&gt=
;end;<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:.5in">1273&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; }<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Do you have any idea why this occurs? Have I misconf=
igured anything?
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I&#8217;ve also tried to pass a static IP configurat=
ion for DomU in the config file,<o:p></o:p></p>
<p class=3D"MsoNormal">and because it automatically enables eth0 at boot ti=
me, I no longer get the<o:p></o:p></p>
<p class=3D"MsoNormal">oops, but a panic directly.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thank you very much for your help,<o:p></o:p></p>
<p class=3D"MsoNormal">Andrei Cherechesu,<o:p></o:p></p>
<p class=3D"MsoNormal">NXP Semiconductors <o:p></o:p></p>
</div>
</body>
</html>

--_000_VI1PR04MB505620B32C8289C6106D0B2AF9D00VI1PR04MB5056eurp_--


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 20:30:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 20:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS4y5-00046T-FG; Fri, 24 Apr 2020 20:30:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=YMss=6I=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jS4y3-00045f-Ex
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 20:30:35 +0000
X-Inumbo-ID: 7359aaf6-866a-11ea-b4f4-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7359aaf6-866a-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 20:30:35 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 63A632098B;
 Fri, 24 Apr 2020 20:30:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587760234;
 bh=34XVNqm5fYpeiInmIqijqkzKtnLoAIHcUKIwyMqVmro=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=eir61xWOHQOIedkje6F3WsKeryw6qqQIroTCyKNoSDnHmFdWxzOv9uaAuFGFxq4jR
 mtuA4m6bNTrT5Urj9sfqCpRwG0ER7N++skH7jkgN5tlxYpdiZJ5IJIZNQCWrFPw8te
 XgHfew5fMG5gMrvc83Uk3JT+IC59YvQGpjJIbY2M=
Date: Fri, 24 Apr 2020 13:30:28 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [[PATCH v3]] xen/guest_access: Harden *copy_to_guest_offset()
 to prevent const dest operand
In-Reply-To: <6ce4afd3-7f03-1083-1057-ed90876f90e0@xen.org>
Message-ID: <alpine.DEB.2.21.2004241328130.7982@sstabellini-ThinkPad-T480s>
References: <20200416112423.25755-1-julien@xen.org>
 <495b74dc-3ee3-ff23-99ce-2fa4a17d57a4@suse.com>
 <6ce4afd3-7f03-1083-1057-ed90876f90e0@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>,
 Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 17 Apr 2020, Julien Grall wrote:
> On 16/04/2020 13:19, Jan Beulich wrote:
> > On 16.04.2020 13:24, Julien Grall wrote:
> > > From: Julien Grall <jgrall@amazon.com>
> > > 
> > > At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
> > > data to guest handle marked const.
> > > 
> > > Thankfully, no users of the helper will do that. Rather than hoping this
> > > can be caught during review, harden copy_to_guest_offset() so the build
> > > will fail if such users are introduced.
> > > 
> > > There is no easy way to check whether a const is NULL in C99. The
> > > approach used is to introduce an unused variable that is non-const and
> > > assign the handle. If the handle were const, this would fail at build
> > > because without an explicit cast, it is not possible to assign a const
> > > variable to a non-const variable.
> > > 
> > > Suggested-by: Jan Beulich <jbeulich@suse.com>
> > > Signed-off-by: Julien Grall <jgrall@amazon.com>
> > 
> > Reviewed-by: Jan Beulich <jbeulich@suse.com>
> > with one further remark:
> > 
> > > --- a/xen/include/asm-x86/guest_access.h
> > > +++ b/xen/include/asm-x86/guest_access.h
> > > @@ -87,6 +87,8 @@
> > >   #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
> > >       const typeof(*(ptr)) *_s = (ptr);                   \
> > >       char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
> > > +    /* Check if the handle is not const */              \
> > > +    void *__maybe_unused _t = (hnd).p;                  \
> > 
> > Not being a native speaker, to me "if" doesn't look appropriate
> > here. I'd use "that" instead, but you may want to confirm this.
> > Overall then maybe "Check that the handle is not for a const type"?
> 
> I am happy with the new suggestion. I will fixup while comitting it.
> 
> I would also need a review from Stefano here also.

Acked-by: Stefano Stabellini <sstabellini@kernel.org>


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 20:37:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 20:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS54g-0004Lm-7B; Fri, 24 Apr 2020 20:37:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zk0B=6I=suse.com=jfehlig@srs-us1.protection.inumbo.net>)
 id 1jS54e-0004Lh-Tj
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 20:37:24 +0000
X-Inumbo-ID: 658fb50e-866b-11ea-b4f4-bc764e2007e4
Received: from m9a0014g.houston.softwaregrp.com (unknown [15.124.64.90])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 658fb50e-866b-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 20:37:24 +0000 (UTC)
Received: FROM m9a0014g.houston.softwaregrp.com (15.121.0.191) BY
 m9a0014g.houston.softwaregrp.com WITH ESMTP; 
 Fri, 24 Apr 2020 20:36:29 +0000
Received: from M4W0335.microfocus.com (2002:f78:1193::f78:1193) by
 M9W0068.microfocus.com (2002:f79:bf::f79:bf) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
 15.1.1591.10; Fri, 24 Apr 2020 20:37:16 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (15.124.8.13) by
 M4W0335.microfocus.com (15.120.17.147) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
 15.1.1591.10 via Frontend Transport; Fri, 24 Apr 2020 20:37:16 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Dv65ClBvRVPbfwnOFHiRTuD1DPOX2fEIgdTx2JxpzopkqUa/KZu7X7i4Tdd2F3AP0EuOMAZclc8mN2Ot/oT7qLHjPZKsntUjK84NMagJ6wXJ796yGyxmuDICP+6Fy7W2HNa0CbCetBxxEAQl9wxkcER4dMn9kpyOxOxipm7zVAsWfXmGqYigLHt9CRQBpLIBuHsaHWBmCzgZ2uv0/fHB7HKqb8GWavRbYE+ktQivnRBu/Gi9a6Cbs5lGmQJsu1L2QQ1TY20WmGkqZHZ71bDHmQ1CuRAI0NTo5Fq/79dkxBYvpTzd5l3dh465JcRiQsCdYMSLi81dWtqTVtuEnPsv/w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8Sx4FsPplWsCnWRaZwT5Pqt/CZZDfcbsmIRjpKSjkYk=;
 b=P+LDps1Y5qCq2NR+pwqCyKfTR+7KP/aYvE8Rh/hMhnj5EskRPP3IyCcntRX36hrwBm7Wnlog8jwQA8GFQgT8ghkV4P27hly6GuvQcbwn18BzmX1WAkkOyITJkl5cVQcCDV5E1jjSn3lSBNsFHuvy8WcvrJNQ+7Rc7/j8Xop65HWkZfrGBqd5yXY7cLUzLn87FmpCMkZBx7EVA+ZRVwHKwMsuU3yUwrcfOci48GN3c5gFkNSkcedQHcM2z1N0e+FR6MZtdTZOZNw1Jwb82cFYmdCK9ov5gFZ2w2TqCP4SMXFUU8tWSCD9Ekgz734UjT4rso8dcre89iZsau2pxspLMw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com;
 dkim=pass header.d=suse.com; arc=none
Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=jfehlig@suse.com; 
Received: from CY4PR1801MB2071.namprd18.prod.outlook.com
 (2603:10b6:910:79::35) by CY4PR1801MB2055.namprd18.prod.outlook.com
 (2603:10b6:910:7a::14) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Fri, 24 Apr
 2020 20:37:15 +0000
Received: from CY4PR1801MB2071.namprd18.prod.outlook.com
 ([fe80::b97c:cfbd:e2df:c5eb]) by CY4PR1801MB2071.namprd18.prod.outlook.com
 ([fe80::b97c:cfbd:e2df:c5eb%7]) with mapi id 15.20.2921.033; Fri, 24 Apr 2020
 20:37:15 +0000
Subject: Re: [libvirt test] 149773: regressions - FAIL
To: osstest service owner <osstest-admin@xenproject.org>,
 <xen-devel@lists.xenproject.org>
References: <osstest-149773-mainreport@xen.org>
From: Jim Fehlig <jfehlig@suse.com>
Message-ID: <7c47a937-551f-2c7a-edd3-8b172155a506@suse.com>
Date: Fri, 24 Apr 2020 14:37:12 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
In-Reply-To: <osstest-149773-mainreport@xen.org>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: SN4PR0201CA0070.namprd02.prod.outlook.com
 (2603:10b6:803:20::32) To CY4PR1801MB2071.namprd18.prod.outlook.com
 (2603:10b6:910:79::35)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.0.4] (75.169.7.53) by
 SN4PR0201CA0070.namprd02.prod.outlook.com (2603:10b6:803:20::32) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend
 Transport; Fri, 24 Apr 2020 20:37:15 +0000
X-Originating-IP: [75.169.7.53]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 18f5674d-09ba-40f5-61ff-08d7e88f4670
X-MS-TrafficTypeDiagnostic: CY4PR1801MB2055:
X-Microsoft-Antispam-PRVS: <CY4PR1801MB2055CF78ED5A70FDF42A3C42C6D00@CY4PR1801MB2055.namprd18.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:2043;
X-Forefront-PRVS: 03838E948C
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:CY4PR1801MB2071.namprd18.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(4636009)(136003)(366004)(39860400002)(376002)(396003)(346002)(4744005)(26005)(53546011)(5660300002)(66556008)(66476007)(6666004)(31686004)(66946007)(316002)(966005)(16576012)(81156014)(8936002)(31696002)(86362001)(956004)(186003)(16526019)(2616005)(2906002)(6486002)(8676002)(478600001)(52116002)(36756003);
 DIR:OUT; SFP:1102; 
Received-SPF: None (protection.outlook.com: suse.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: vgH0T+8bTFQBeBkYOFyrwJHiDxOM+aDCK2017z7gCw5U3sG3xgTs4nCYtPmeN4Z+1G0FTUw1dDtlfbgInHj8ugxCqJhlriLlDswmZdmcJEsDp/pxf/Pn83O9gy6/bxeq5WBCMOjVq2lpDYEZ+tfvuh46G6Z2vmQC2uVRRyrOOQgSKtCqJjptCN6ZbOiNmEpeakYC8F4KLHbNrIxoCxK7Z9XO3+i7NKqGON+In9FZs+kSI6aVZczzBAwT1yijUsmxisYC9CTQC5wvoGZgftHRjV4fMq0/6tv/305Ph+OAmyFBHPROix3CES6usEmTJSUF7QQYkCr6zcLkefge+hdb3DSUQAy2D9bi2n1xsU2b0jxksA4wMh1uIjAe9fEqG5aZ22si9tiFS+P/HrqZop2sGY7fp/QqB4VoKc/epfbA47zOoGOVwZNeVVw609cnhiy4HutcEETRCzj/VfshuM56adRX0dbY/q9qRg9/51sg9AX96wndaWJerfih/8zhuja870uTzM7EcHXAjAJsP3FgEA==
X-MS-Exchange-AntiSpam-MessageData: jQZcnezY1M3E4uTveFXEL+/J5hiC3kDV+8sw3Q1Fz02asBt+0HIyP/NZ14IExNsu7VPDBN8nqHhMEGzjyRrAdNxAhhgUbEgxNNDqab4LAUU4Cqaiqj3vlRK6Nh2/anfSkVLdL8qmGrAaee49x3VtFbCjIcaiGtnU0L3VufHOQZGw5UZpSMULg/RABF0f5lV98NNDoPseDLlTpwnPsd6y5SOWHuu9qlbB0ARvZFekjvPuFg6ZZgnHY2it5nQ1cz15Mustnq/ZIqlpZs9fheWk/i+WYrKDYG79v72CMK4j+7Jbv+F/SQDwXMKOuPaZnfhoosaq5M1p5ESmzRyInlnniHc1Pcyh75L6pDSf73Luchme+LEQd6o4hHQEIVKqHbhteyRFHrekwxaXwg9+2aG1E1nVMz6aWo2V+W/if80Wwml640UkHIDwAG3d13flTw0Ppju1J2LyA9M/ZkLpkh+C3F2uCEr3nCWCK9CuMYtCzM2Muaf2GMk33lxgQMOkBGusJwtpeJMB9cZo0PywmJovYZiJt9IIcUoRgMGfqgNbmwr2vBPagpwF7CkwdW8G+UURLxinX77fhWGXGEjQ9IYNvxxUAYnsZc3vigJTzHK2SGDuCWc5y5QMI+JJSbvPedkbZvpmzUSNjKrgYH6WuJHuG9Orm6l1eu8UrzXT/ZTmYV5+WnercV+1geJNLO9FwRYd+b9qdUDBSisRz5euvkeH5aeixvn5VWY+stWbBhOW/Br23mZQLbVwlFRhNIAn5MM/taQZSSq33q+X/y7sKmc96K4H0UO8tAA15xwnehe/cPw=
X-MS-Exchange-CrossTenant-Network-Message-Id: 18f5674d-09ba-40f5-61ff-08d7e88f4670
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 20:37:15.7571 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 856b813c-16e5-49a5-85ec-6f081e13b527
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tWcQIZL3WEeVLlQbuQMDKphn4KdlZ5UdsC+vyBf3nqrlLNC2U4R6omXUYApcZKM4nalapnYULOxNfbW/YLJGQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1801MB2055
X-OriginatorOrg: suse.com
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/24/20 3:53 AM, osstest service owner wrote:
> flight 149773 libvirt real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/149773/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>   build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
>   build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
>   build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
>   build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Probably best to disable these tests to avoid all the spam.

Regards,
Jim


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 20:40:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 20:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS57E-0004oV-LO; Fri, 24 Apr 2020 20:40:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6uIs=6I=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jS57D-0004iM-Np
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 20:40:03 +0000
X-Inumbo-ID: c585e4ba-866b-11ea-b4f4-bc764e2007e4
Received: from mail-lf1-x131.google.com (unknown [2a00:1450:4864:20::131])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c585e4ba-866b-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 20:40:02 +0000 (UTC)
Received: by mail-lf1-x131.google.com with SMTP id 198so8841575lfo.7
 for <xen-devel@lists.xenproject.org>; Fri, 24 Apr 2020 13:40:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=pFbhnWzBLpaJPFlQc/+IRV69nBOHleJ4A4cSCs2wfmM=;
 b=Xlr4StzVdtZzRsrMnDLKbpyYZSkP3TfTONBzjrqq0r8O2MfEnvxHDQLpB2AH+XBqwz
 xe9nxjROOrUemQ0NQdNeWfGr+dQortGORwSMDAFN1lcbnHAUabDXXphlZeqFXNkn6EDs
 7B90WXlGYt5/Un8Kr9f0kgqXYXmxXs/bhqPn3pupBzGd6DTH3xj2bHeFLwIPrXr31zYv
 qZVhKwPkZ3CVhDD67z36XF8/ZSLwAx0+b1dj6erSfN3YoT70v4bsogCQRViXgc7Sd+9w
 twudF6w2hFPOc6towN4jfWVBJ/LvSt3CE0lAR2NZin7CogA6NzcMEujR7mH1OPexGbhU
 VHug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=pFbhnWzBLpaJPFlQc/+IRV69nBOHleJ4A4cSCs2wfmM=;
 b=LRmGVhBiNB7fAHGtu5fnerljzW/QD9PxSla0bEDLTQxT7GZZMMOmlyYexTP/vqAtHZ
 zqXvX2GBvqC6L0BYjB18UA2xFG4ysjBdzJTKpKHm0tEkVRe9+p1WvTmtTYR8eSS951Q7
 YEYwvFBVlDs+L3hNnZExSiq+WfeLnVGlggBcCld5VZvaJ5LTsGIgx6t89U7zB45e8WxI
 y8+PJ5iJHNjM6QY4UiknKlsqnTtQkIiSo84CR/nSRyhseJrzb85ttNPT0YccHViUdQ6n
 XPYi4OpqEmCTeOQJPg5MTrv71oROTAETxC42YxkDeD8GJiwp1pZbMS1S5FxspuJSqvWj
 ZgUA==
X-Gm-Message-State: AGi0PubeRNcW6ZDidrlEgMF6CFfiIqowrLymo+FIm2FOrYTSft/ZrCz9
 w81YMWkzqxWqQNHt1W35V5SYPT1tCDDQML/+Yi8=
X-Google-Smtp-Source: APiQypLXmpbqAkeK/1NiIuDZujC/yxivhIssaxfwX0uJFv0T4zMgE++bC+Sash6JhBjObnyKYsXPXfcCG2pEnq+YRlk=
X-Received: by 2002:a19:1c3:: with SMTP id 186mr7474814lfb.191.1587760801306; 
 Fri, 24 Apr 2020 13:40:01 -0700 (PDT)
MIME-Version: 1.0
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
 <24225.31493.220592.722565@mariner.uk.xensource.com>
 <24225.31669.536258.56822@mariner.uk.xensource.com>
 <4085F05B-ABEC-446A-8BB1-06DEE57D71A5@citrix.com>
 <C10E07AB-FDE8-4588-95E7-6109F0FDB5E2@citrix.com>
 <CAEBZRSfUysyGhnsXDEAJiVDBeX-Kb836V-uT6Qrtomte1LKgsA@mail.gmail.com>
 <E0DEA134-CB69-4992-B949-7233BFF3A1E4@citrix.com>
In-Reply-To: <E0DEA134-CB69-4992-B949-7233BFF3A1E4@citrix.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Fri, 24 Apr 2020 16:39:50 -0400
Message-ID: <CAEBZRSe4O9ahFHViCJ9K63imUbYZA+sSe9XyNfopXGtL8DJsWw@mail.gmail.com>
Subject: Re: Golang Xen packages and the golang packaging system
To: George Dunlap <George.Dunlap@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 24, 2020 at 7:26 AM George Dunlap <George.Dunlap@citrix.com> wr=
ote:
>
>
>
> > On Apr 24, 2020, at 5:04 AM, Nick Rosbrook <rosbrookn@gmail.com> wrote:
> >
> > On Thu, Apr 23, 2020 at 1:22 PM George Dunlap <George.Dunlap@citrix.com=
> wrote:
> >>
> >>
> >>> On Apr 23, 2020, at 12:49 PM, George Dunlap <george.dunlap@citrix.com=
> wrote:
> >>>
> >>>
> >>>
> >>>> On Apr 23, 2020, at 12:27 PM, Ian Jackson <ian.jackson@citrix.com> w=
rote:
> >>>>
> >>>> Ian Jackson writes ("Re: Golang Xen packages and the golang packagin=
g system"):
> >>>>> This is quite unpleasant.  In particular, it makes a git tree out o=
f
> >>>>> output files.  What will we do when someone sends us patches to the
> >>>>> bindings ?
> >>>>
> >>>> Also, anyone who redistributes your proposed golang package is
> >>>> violating our licence unless they ship a copy of xen.git[1] too, sin=
ce
> >>>> the golang package is not source code.
> >>>>
> >>>> [1] Technically, a copy of the relevant parts will do.
> >>>
> >>> The =E2=80=9Crelevant parts=E2=80=9D would primarily be gengotypes.py=
, right?  Oh, and I guess libxl_test.idl and friends.  libxl_test.idl isn=
=E2=80=99t included in the distribution either.
> >>>
> >>> I=E2=80=99m not an expert in the golang build system, but they genera=
lly seem to be trying to keep the functionality simple (which of course, me=
ans if you want to do anything non-basic, it=E2=80=99s incredibly complicat=
ed or completely impossible).
> >>>
> >>> There=E2=80=99s a command, `go generate`, which we could use to run g=
engotypes.py to generate the appropriate files.  But I=E2=80=99m not sure h=
ow to use that in a practical way for this sort of package: it might end up=
 that people wanting to use the package would need to manually clone it, th=
en manually run `go generate` before manually building the package.
> >>>
> >>> Checking in the generated files means that someone can simply add `go=
lang.xenproject.org/xenlight` as a dependency (perhaps with a specific vers=
ion tag, like v4.14), and everything Just Works.
> >>>
> >>> Nick may have some ideas on how to use the golang build system more e=
ffectively.
> >>
> >> So, the following seems to work quite well actually:
> >>
> >> mkdir vendor
> >> ln -s vendor/golang.xenproject.org /usr/share/gocode/src/golang.xenpro=
ject.org
> >> echo =E2=80=9Cgolang.xenproject.org/xenlight=E2=80=9D >> vendor/module=
s.txt
> >> go build -mod=3Dvendor
> >>
> >> Using the above method, (say) redctl.git would build exactly the same =
on Xen 4.14 as on Xen 4.15 (assuming redctl wasn=E2=80=99t using anything n=
ot available in 4.14).
> >>
> >> I=E2=80=99m inclined to say we should start with just telling people t=
o do that, and look at doing something else if we discover that=E2=80=99s n=
ot suitable for some reason.
> >
> > If it's not viable to create another repo for the xenlight package, I
> > think we should should just initialize the go module, i.e. go.mod, at
> > xen.git/tools/golang. The downside is that tags cannot be independent
> > from the rest of xen.git, so users need to have `require <module
> > path>/xenlight@RELEASE-4.14.0` in their go.mod, but at least its `go
> > get`-able. And, this does not fetch the entire git tree.
> >
> > This would also mean that we actually track the generated code (which
> > isn't really a big deal IMO, it's expected that people track their
> > generated gRPC code, for example).
>
> Yes, I was playing with this yesterday and it seems to work OK.
>
> The thing I didn=E2=80=99t necessarily like about this was that suppose y=
ou had a public project that used the xenlight bindings, and you upgraded t=
o Xen 4.15, but some of your users hadn=E2=80=99t.  If you updated this to =
RELEASE-4.15.0, then all your downstreams would stop working, even if you w=
eren=E2=80=99t using any functionality specific to Xen 4.15.

The go.mod is really just a way of specifying dependencies. Definig a
module for xenlight does not take away the ability of downstreams to
do `go build -mod=3Dvendor`, where their preferred version of xenlight
is vendored.

> But I suppose what that would really mean is that:
> 1) We should make sure that xenlight@RELEASE-$V works on > $V as well
> 2) Projects depending on the bindings should use the oldest version of th=
e Xen bindings suitable for their use case.
>
> Both of those are probably reasonable.

I agree.

> Another issue that happens with checking in generated code is that the id=
l changes and nobody re-generates the code.  We=E2=80=99d probably want an =
osstest check that would refuse to push from staging -> master if re-runnin=
g the code generator produced a different output.  (But that has its own an=
noyances: it seems that different versions of python sort things in differe=
nt orders, so I often have to throw away spurious changes to the generated =
files because our two versions of python seem to order some things differen=
tly.)

Yeah, I have noticed that on my machine as well. I guess we could just
sort the cases by value or alphabetically before writing the switch
statements. Have you seen the re-ordering happen in other places too?

[...]

> Anyway, do you want to submit a patch adding a `go.mod` in the appropriat=
e place?  I=E2=80=99ve always had a hard time figuring out how go.mod actua=
lly works; there seems to be no *manual*, only *howtos*.

Yes, I can do that. I'm going to keep tinkering with the remote import
path and module proxy so that users could still just do `import
"golang.xenproject.org/xenlight"`, but if I can't get something like
that working I'll define the module "canonically."

Thanks,
-NR


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 20:46:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 20:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS5Dg-0005Ke-Cq; Fri, 24 Apr 2020 20:46:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qNy4=6I=gmail.com=julien.grall.oss@srs-us1.protection.inumbo.net>)
 id 1jS5De-0005KZ-J0
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 20:46:42 +0000
X-Inumbo-ID: b3797da8-866c-11ea-b4f4-bc764e2007e4
Received: from mail-wm1-x336.google.com (unknown [2a00:1450:4864:20::336])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b3797da8-866c-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 20:46:41 +0000 (UTC)
Received: by mail-wm1-x336.google.com with SMTP id e26so12178384wmk.5
 for <xen-devel@lists.xenproject.org>; Fri, 24 Apr 2020 13:46:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=jN1K5UO6MSKddnMHyc9Lm4KsL9QtSh9bow9HsleKSFU=;
 b=mchb71cmx3StgbmJISbNdoe6FRGQFtbp2sJstSHaR1DeZQzEmKJSujPZkup7OhgWpJ
 J3rWbWNVu/jXsWc2IlKIqHSNluddFCIPYhpxBlgvwKfIX704nV0Yx433dmvGxCzTn0aD
 cvAjisCqK7kvfpLH/5PAUvHTd8hR0YKsmp1E9uvO5dCGzh5pqcGaF38208b/eoD37m+o
 H6y9f6e0rGvkjARpKzazOloJVOnJBk8Q4LqXuC22GbebhDqmnerlpxYSylnixskT1fIO
 jFtOEwqnUU0773x1FEcK7iYrKSmfOxDhZ/ykB2O5eLZi4JH+TkO2uPvtNaN/M6RuK0/S
 VEwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=jN1K5UO6MSKddnMHyc9Lm4KsL9QtSh9bow9HsleKSFU=;
 b=e0pwqoZ6UAR//sPaTiV/AzVfRIJTWqgEuTbti8mVYdmP4HFKxAL5/ymFACstfj/RhZ
 SUKpRFvueWjIlKYuJdE1uY0PtC+/HywBC09m9o/4vRebnC2V0nNTVmrc2yM8dWNzRrQk
 lXE/xHquV5CkTR0xDGKQBf1iwj+6bSB3MHAdJKwyxF8ww9YWI+8j+7WgZdjSZfLY+tJI
 MzlfjYJr5ZmrntkMgMIIeYwpc5BwG5+o/ifNNv/OEEp9/gCcQrZ6bzbXFZjLbe8i+Akk
 59QI8U9k7nq2IjXUwwjZ3qxbydUHXFSP8s7rMhIXVmmXqd3EQn7uqxBVyJTt2AmUAdw3
 HJOQ==
X-Gm-Message-State: AGi0Puak/KOOfSXeRac2J1mXmkAud8o5nnqfSv+ciMUJX9WeVggUalzH
 LmdLr1v2zn1Mis1IkNCjWcXbCn6LCFTer3A6bNM=
X-Google-Smtp-Source: APiQypIlKeMVKIfYKzwb7bf2D2sTSTn5yYqF3noFYYw/QpMMNVu8jIk+Wad4dEmzIyRlnBDGzgpFqfARnX0EvcOHCMA=
X-Received: by 2002:a05:600c:28e:: with SMTP id
 14mr12803469wmk.79.1587761201071; 
 Fri, 24 Apr 2020 13:46:41 -0700 (PDT)
MIME-Version: 1.0
References: <VI1PR04MB505620B32C8289C6106D0B2AF9D00@VI1PR04MB5056.eurprd04.prod.outlook.com>
In-Reply-To: <VI1PR04MB505620B32C8289C6106D0B2AF9D00@VI1PR04MB5056.eurprd04.prod.outlook.com>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Fri, 24 Apr 2020 21:46:30 +0100
Message-ID: <CAJ=z9a2ZN0ZxzY=kdJfonLCDQXni7yr31yxNp5qwzOvWJxDUqQ@mail.gmail.com>
Subject: Re: arm: DomU Networking enable leads to Dom0 kernel oops
To: Andrei Cherechesu <andrei.cherechesu@nxp.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 24 Apr 2020 at 21:29, Andrei Cherechesu
<andrei.cherechesu@nxp.com> wrote:
>
> Hello,

Hi,

Please don't post using HTML and instead configure your client to use
plain text.

> Do you have any idea why this occurs? Have I misconfigured anything?

OOPS should never occur because something has been misconfigured. The
log suggest the address used is bogus, did you trace where the address
was coming from?

Also, looking at the log you are using 4.19.59-rt24+g9d2b51c. AFAICT,
this is not the latest version of RT for 4.19. Can you please use the
latest version to check if the bug can still be reproduced?

Cheers,


From xen-devel-bounces@lists.xenproject.org Fri Apr 24 22:39:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 22:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS6yQ-0005rW-Ls; Fri, 24 Apr 2020 22:39:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jS6yO-0005rQ-Gf
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 22:39:04 +0000
X-Inumbo-ID: 657533ee-867c-11ea-9531-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 657533ee-867c-11ea-9531-12813bfff9fa;
 Fri, 24 Apr 2020 22:39:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=y9rKEl461cLtUAKLrmwINbrnvM1Y6XeHFpbLg24nXd0=; b=EpilQ6mFB8X2Znu8ZYsxetCcI
 nNhHvGL30ntJBKx90avp/GbAsW+diGZiT/2ZMZz+55Jd65JjjAotdITZiaKGRsWL+PuqwRItD55A6
 Xa4nNb2OlsphkISZjrjPHAROuYXsqq1+7KseGosgQcAZ3dZbm5/uTgb2+Omq2w2DB7Icc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS6yM-0004Pt-9s; Fri, 24 Apr 2020 22:39:02 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS6yM-0007gV-18; Fri, 24 Apr 2020 22:39:02 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jS6yM-00021J-00; Fri, 24 Apr 2020 22:39:02 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149783-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149783: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-coresched-i386-xl:hosts-allocate:starved:nonblocking
 xen-unstable:test-amd64-coresched-amd64-xl:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This: xen=aa14feb6723d3bb15a884533ade1cd9732792145
X-Osstest-Versions-That: xen=aa14feb6723d3bb15a884533ade1cd9732792145
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 22:39:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149783 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149783/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-examine      4 memdisk-try-append         fail pass in 149771

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149771
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149771
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149771
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149771
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149771
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149771
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149771
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149771
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149771
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149771
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-coresched-i386-xl  2 hosts-allocate           starved in 149771 n/a
 test-amd64-coresched-amd64-xl  2 hosts-allocate          starved in 149771 n/a

version targeted for testing:
 xen                  aa14feb6723d3bb15a884533ade1cd9732792145
baseline version:
 xen                  aa14feb6723d3bb15a884533ade1cd9732792145

Last test of basis   149783  2020-04-24 13:59:56 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Fri Apr 24 22:51:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Apr 2020 22:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jS79o-0007QF-VA; Fri, 24 Apr 2020 22:50:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CzFP=6I=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jS79n-0007QA-LJ
 for xen-devel@lists.xenproject.org; Fri, 24 Apr 2020 22:50:51 +0000
X-Inumbo-ID: 08996d14-867e-11ea-b4f4-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 08996d14-867e-11ea-b4f4-bc764e2007e4;
 Fri, 24 Apr 2020 22:50:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Bq+lrNAdaP5YTdwMD+J6tlwsCzGEmcUexbpqwjGLH9A=; b=KS9fUB7AVNRWFomj6o79+y+1U
 FhIFwwBg334PdAaVf1RgigfcW5a79k6pximYWCWsyTa50TxcxrngET2EuaJiYUJwMJ0s9eastMBFB
 ZxPjvl3KWgeS4CBwls208I394xCQfTInqn1Mt//+S2V2ZWxbbYBaxSZUf3PFz8RZ2uQk8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS79h-0004dw-GJ; Fri, 24 Apr 2020 22:50:45 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jS79h-0008Op-4c; Fri, 24 Apr 2020 22:50:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jS79h-0006Dl-3y; Fri, 24 Apr 2020 22:50:45 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149788-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149788: regressions - FAIL
X-Osstest-Failures: xen-unstable-smoke:build-amd64:xen-build:fail:regression
 xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable-smoke:build-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Fri, 24 Apr 2020 22:50:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149788 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149788/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 149784

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149784  2020-04-24 14:00:40 Z    0 days
Failing since        149785  2020-04-24 17:01:40 Z    0 days    2 attempts
Testing same since   149788  2020-04-24 20:00:41 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-amd64-libvirt                                     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.

------------------------------------------------------------
commit f093b08c47b39da6019421a2b61d40745b3e573b
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Tue Apr 21 11:29:46 2020 -0700

    Introduce a description of the Backport and Fixes tags
    
    Create a new document under docs/process to describe our special tags.
    Add a description of the Fixes tag and the new Backport tag. Also
    clarify that lines with tags should not be split.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
    Acked-by: Wei Liu <wl@xen.org>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    CC: jbeulich@suse.com
    CC: george.dunlap@citrix.com
    CC: julien@xen.org
    CC: lars.kurth@citrix.com
    CC: andrew.cooper3@citrix.com
    CC: konrad.wilk@oracle.com

commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Apr 24 15:49:23 2020 +0100

    Update QEMU_TRADITIONAL_REVISION
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 01:55:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 01:55:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSA1s-00039Y-UB; Sat, 25 Apr 2020 01:54:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSA1r-00039T-Lf
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 01:54:51 +0000
X-Inumbo-ID: bfad66d6-8697-11ea-955d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bfad66d6-8697-11ea-955d-12813bfff9fa;
 Sat, 25 Apr 2020 01:54:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mp6QtQUf6wZey/IBA1y55TWjXBKHLRRCoZx6g1SIs5I=; b=ZjnYVTPjC98JKu/h/GyB2sM+t
 6Gh7wCfPf7acbe7teM6kjenvPOLp8UJt5HRnohXNq58LqXDogaMY7a2UJzRKMC1Xg8msEd9gHGjQy
 33hjOSQcRvHnnPM6CajUbCq9aNdjXWFZBiM89i2WzfdHv/B4mMTPl3g5ldYqkV+Sl9smw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSA1q-0006Zk-2r; Sat, 25 Apr 2020 01:54:50 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSA1p-0008Qw-R6; Sat, 25 Apr 2020 01:54:49 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSA1p-0008Qi-QU; Sat, 25 Apr 2020 01:54:49 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149791-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149791: regressions - FAIL
X-Osstest-Failures: xen-unstable-smoke:build-amd64:xen-build:fail:regression
 xen-unstable-smoke:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:build-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 01:54:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149791 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149791/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 149784

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149784  2020-04-24 14:00:40 Z    0 days
Failing since        149785  2020-04-24 17:01:40 Z    0 days    3 attempts
Testing same since   149788  2020-04-24 20:00:41 Z    0 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-amd64-libvirt                                     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.

------------------------------------------------------------
commit f093b08c47b39da6019421a2b61d40745b3e573b
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Tue Apr 21 11:29:46 2020 -0700

    Introduce a description of the Backport and Fixes tags
    
    Create a new document under docs/process to describe our special tags.
    Add a description of the Fixes tag and the new Backport tag. Also
    clarify that lines with tags should not be split.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
    Acked-by: Wei Liu <wl@xen.org>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    CC: jbeulich@suse.com
    CC: george.dunlap@citrix.com
    CC: julien@xen.org
    CC: lars.kurth@citrix.com
    CC: andrew.cooper3@citrix.com
    CC: konrad.wilk@oracle.com

commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Apr 24 15:49:23 2020 +0100

    Update QEMU_TRADITIONAL_REVISION
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 02:01:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 02:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSA8F-0004NT-OC; Sat, 25 Apr 2020 02:01:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=i+K/=6J=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jSA8E-0004NO-2q
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 02:01:26 +0000
X-Inumbo-ID: aab76dc0-8698-11ea-955e-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id aab76dc0-8698-11ea-955e-12813bfff9fa;
 Sat, 25 Apr 2020 02:01:25 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id C766D20748;
 Sat, 25 Apr 2020 02:01:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1587780084;
 bh=XL9BFXgGQ+Q4he+KpVpztArDp4B8EZdrE/Wiz58+6Lc=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=goBuyWXa1uo3OYtcaDP4LGu8ejdGmisyr6BpRZc5fetpbmLMbGS/czkh20Dm/XZWA
 th9rPUaGSKwaS4geanGszDlnncS1D0M/bxCJ9qk4TxHvyS3IKrydeZO6QtxepWrrdy
 5AmFKWo32qBcudlN3/T4t7cWyd8Ydi9DASYGFhjo=
Date: Fri, 24 Apr 2020 19:01:23 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Andrei Cherechesu <andrei.cherechesu@nxp.com>
Subject: Re: arm: DomU Networking enable leads to Dom0 kernel oops
In-Reply-To: <VI1PR04MB505620B32C8289C6106D0B2AF9D00@VI1PR04MB5056.eurprd04.prod.outlook.com>
Message-ID: <alpine.DEB.2.21.2004241443570.7982@sstabellini-ThinkPad-T480s>
References: <VI1PR04MB505620B32C8289C6106D0B2AF9D00@VI1PR04MB5056.eurprd04.prod.outlook.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-670645698-1587764760=:7982"
Content-ID: <alpine.DEB.2.21.2004241450320.7982@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-670645698-1587764760=:7982
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.21.2004241450321.7982@sstabellini-ThinkPad-T480s>

Hi Andrei,

Reply at the bottom.


On Fri, 24 Apr 2020, Andrei Cherechesu wrote:
> Hello,
> 
>  
> 
> Recently I’ve been trying to enable the networking in a conventional DomU (not dom0less).
> 
> The approach I used was the one described here: https://wiki.xen.org/wiki/Xen_Networking#Bridging.
> 
>  
> 
> But when I use xl to create DomU, I get a Kernel OOPS in Dom0. The setup is still responsive after this
> 
> and DomU boots successfully. However, if I try to enable `eth0` in DomU (using ip link dev set eth0 up),
> 
> I get a Kernel Panic in Dom0.
> 
>  
> 
> Here are the complete steps:
> 
>  1. Boot Dom0 and configure bridge:
>      +  brctl addbr xenbr0
>      +  brctl addif xenbr0 eth0
>      +  ip link set dev xenbr0 up
>      +  ip link set dev eth0 up
>      +  dhclient xenbr0
> 
>  
> 
>  2. ifconfig xenbr0 (ping 8.8.8.8 works):
> 
> xenbr0    Link encap:Ethernet  HWaddr B2:62:37:C9:BB:D7
> 
>           inet addr:192.168.0.185  Bcast:192.168.0.255  Mask:255.255.255.0
> 
>           inet6 addr: fe80::b062:37ff:fec9:bbd7/64 Scope:Link
> 
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
>           RX packets:703 errors:0 dropped:0 overruns:0 frame:0
> 
>           TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
> 
>           collisions:0 txqueuelen:1000
> 
>           RX bytes:88213 (86.1 KiB)  TX bytes:3088 (3.0 KiB)
> 
>  
> 
>  3. ifconfig eth0:
> 
> eth0      Link encap:Ethernet  HWaddr B2:62:37:C9:BB:D7 
> 
>           inet6 addr: fe80::b062:37ff:fec9:bbd7/64 Scope:Link
> 
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
>           RX packets:1535 errors:0 dropped:2 overruns:0 frame:0
> 
>           TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
> 
>           collisions:0 txqueuelen:1000
> 
>           RX bytes:450476 (439.9 KiB)  TX bytes:4248 (4.1 KiB)
> 
>           Interrupt:59 Base address:0xc000
> 
>  
> 
>  4. Add bridge to DomU config file:
> 
> vif = [ 'bridge=xenbr0' ]
> 
>  
> 
>  5. root@s32g274aevb-Dom0:~# xl create /etc/xen/domU1.cfg
> 
> After this I get the Kernel OOPS, because of a failed memory
> 
> access
> 
> [  413.367873] Unable to handle kernel paging request at virtual address 000006c000020070
 

[...]
 
> Do you have any idea why this occurs? Have I misconfigured anything?

The configuration looks correct. I have not seen this issue before, and
it goes without saying that it should not happen. PV network (vif) is
used very often so I was surprised to see an issue like this.

Then I saw Julien's reply where he noticed that you are using LinuxRT in
Dom0. I tried that once before in the last few months and I had issues
with it (issues with LinuxRT running as dom0 kernel; as domU works
fine). I had to go back to using vanilla Linux in dom0 and LinuxRT in
DomU only.  Thank you for reminding me of the problem :-)

I went back and checked my configuration, using LinuxRT in dom0 again and
trying to start a VM with PV network like you did. In my case, dom0
doesn't crash but prints the error appended below and domU hangs at
boot.  Dom0 and DomU are both 4.19.0-rt1-00002-gf6cb7e02d291. Then I
tried using upstream 5.6.4-rt3, and interestingly I got the same error
again.

But I get the same problem with or without vif=[""] in the config file,
and also this seems to be an interrupt related issue, while the one you
are seeing seems to be a memory mapping issue, so they are very
different.

I wonder why we are seeing two completely different errors. It might be
because of differences in our Linux config, or it could be due to
hardware differences. I think it makes sense for you to try a more
recent version of LinuxRT, ideally 5.6.4-rt3 like I did. Once you do
that, could you please share both your findings and your kernel .config
file? (I attached mine for 5.6.4-rt3 as a reference.)

We should be able to get to the point where we are both seeing the same
problem :-)



[   86.900974] ------------[ cut here ]------------
[   86.905134] Interrupt for port 6, but apparently not enabled; per-user (____ptrval____)
[   86.913228] WARNING: CPU: 0 PID: 2437 at drivers/xen/evtchn.c:167 evtchn_interrupt+0xfc/0x108
[   86.913231] Modules linked in:
[   86.913240] CPU: 0 PID: 2437 Comm: irq/55-evtchn:x Not tainted 4.19.0-rt1-00002-gf6cb7e02d291 #57
[   86.913242] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
[   86.913246] pstate: 80000005 (Nzcv daif -PAN -UAO)
[   86.913251] pc : evtchn_interrupt+0xfc/0x108
[   86.913256] lr : evtchn_interrupt+0xfc/0x108
[   86.913258] sp : ffffff8009f43d70
[   86.913260] x29: ffffff8009f43d70 x28: ffffffc03d045cb0 
[   86.913266] x27: ffffff80080f0000 x26: ffffff8008f1d000 
[   86.913272] x25: ffffffc03d045c9c x24: ffffff80080f0668 
[   86.913277] x23: ffffffc03d045c00 x22: 0000000000000001 
[   86.913283] x21: 0000000000000037 x20: ffffffc03c980800 
[   86.913288] x19: ffffffc03db64c00 x18: ffffff8008f1d688 
[   86.913293] x17: 0000000000000001 x16: 0000000000000007 
[   86.913299] x15: ffffff8088fc1167 x14: 0000000000000006 
[   86.913304] x13: ffffff8008fc1175 x12: 73752d726570203b 
[   86.913309] x11: 0000000000000000 x10: 0000000005f5e0ff 
[   86.913314] x9 : ffffff8009f43a50 x8 : 2820726573752d72 
[   86.913320] x7 : 0000000000000000 x6 : ffffff8008f1d688 
[   86.913325] x5 : 0000000000000003 x4 : 00000040570b3000 
[   86.913330] x3 : 0000000000000001 x2 : 0000000000000001 
[   86.913335] x1 : d7954973361fc800 x0 : 0000000000000000 
[   86.913341] Call trace:
[   86.913346]  evtchn_interrupt+0xfc/0x108
[   86.913352]  irq_forced_thread_fn+0x2c/0x90
[   86.913355]  irq_thread+0x104/0x1e0
[   86.913361]  kthread+0xf8/0x128
[   86.913366]  ret_from_fork+0x10/0x1c
[   86.913369] ---[ end trace 0000000000000002 ]---
--8323329-670645698-1587764760=:7982
Content-Type: text/plain; CHARSET=US-ASCII; NAME=.config
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.21.2004241849110.7982@sstabellini-ThinkPad-T480s>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME=.config

Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBmaWxlOyBETyBOT1QgRURJ
VC4NCiMgTGludXgvYXJtNjQgNS42LjQgS2VybmVsIENvbmZpZ3VyYXRpb24N
CiMNCg0KIw0KIyBDb21waWxlcjogYWFyY2g2NC1saW51eC1nbnUtZ2NjIChM
aW5hcm8gR0NDIDUuMy0yMDE2LjA1KSA1LjMuMSAyMDE2MDQxMg0KIw0KQ09O
RklHX0NDX0lTX0dDQz15DQpDT05GSUdfR0NDX1ZFUlNJT049NTAzMDENCkNP
TkZJR19DTEFOR19WRVJTSU9OPTANCkNPTkZJR19DQ19DQU5fTElOSz15DQpD
T05GSUdfQ0NfSEFTX0FTTV9HT1RPPXkNCkNPTkZJR19DQ19IQVNfV0FSTl9N
QVlCRV9VTklOSVRJQUxJWkVEPXkNCkNPTkZJR19JUlFfV09SSz15DQpDT05G
SUdfQlVJTERUSU1FX1RBQkxFX1NPUlQ9eQ0KQ09ORklHX1RIUkVBRF9JTkZP
X0lOX1RBU0s9eQ0KDQojDQojIEdlbmVyYWwgc2V0dXANCiMNCkNPTkZJR19J
TklUX0VOVl9BUkdfTElNSVQ9MzINCiMgQ09ORklHX0NPTVBJTEVfVEVTVCBp
cyBub3Qgc2V0DQpDT05GSUdfTE9DQUxWRVJTSU9OPSIiDQpDT05GSUdfTE9D
QUxWRVJTSU9OX0FVVE89eQ0KQ09ORklHX0JVSUxEX1NBTFQ9IiINCkNPTkZJ
R19ERUZBVUxUX0hPU1ROQU1FPSIobm9uZSkiDQpDT05GSUdfU1dBUD15DQpD
T05GSUdfU1lTVklQQz15DQpDT05GSUdfU1lTVklQQ19TWVNDVEw9eQ0KQ09O
RklHX1BPU0lYX01RVUVVRT15DQpDT05GSUdfUE9TSVhfTVFVRVVFX1NZU0NU
TD15DQpDT05GSUdfQ1JPU1NfTUVNT1JZX0FUVEFDSD15DQojIENPTkZJR19V
U0VMSUIgaXMgbm90IHNldA0KQ09ORklHX0FVRElUPXkNCkNPTkZJR19IQVZF
X0FSQ0hfQVVESVRTWVNDQUxMPXkNCkNPTkZJR19BVURJVFNZU0NBTEw9eQ0K
DQojDQojIElSUSBzdWJzeXN0ZW0NCiMNCkNPTkZJR19HRU5FUklDX0lSUV9Q
Uk9CRT15DQpDT05GSUdfR0VORVJJQ19JUlFfU0hPVz15DQpDT05GSUdfR0VO
RVJJQ19JUlFfU0hPV19MRVZFTD15DQpDT05GSUdfR0VORVJJQ19JUlFfRUZG
RUNUSVZFX0FGRl9NQVNLPXkNCkNPTkZJR19HRU5FUklDX0lSUV9NSUdSQVRJ
T049eQ0KQ09ORklHX0hBUkRJUlFTX1NXX1JFU0VORD15DQpDT05GSUdfSVJR
X0RPTUFJTj15DQpDT05GSUdfSVJRX0RPTUFJTl9ISUVSQVJDSFk9eQ0KQ09O
RklHX0dFTkVSSUNfTVNJX0lSUT15DQpDT05GSUdfR0VORVJJQ19NU0lfSVJR
X0RPTUFJTj15DQpDT05GSUdfSVJRX01TSV9JT01NVT15DQpDT05GSUdfSEFO
RExFX0RPTUFJTl9JUlE9eQ0KQ09ORklHX0lSUV9GT1JDRURfVEhSRUFESU5H
PXkNCkNPTkZJR19TUEFSU0VfSVJRPXkNCiMgQ09ORklHX0dFTkVSSUNfSVJR
X0RFQlVHRlMgaXMgbm90IHNldA0KIyBlbmQgb2YgSVJRIHN1YnN5c3RlbQ0K
DQpDT05GSUdfR0VORVJJQ19JUlFfTVVMVElfSEFORExFUj15DQpDT05GSUdf
QVJDSF9DTE9DS1NPVVJDRV9EQVRBPXkNCkNPTkZJR19HRU5FUklDX1RJTUVf
VlNZU0NBTEw9eQ0KQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFM9eQ0KQ09O
RklHX0FSQ0hfSEFTX1RJQ0tfQlJPQURDQVNUPXkNCkNPTkZJR19HRU5FUklD
X0NMT0NLRVZFTlRTX0JST0FEQ0FTVD15DQoNCiMNCiMgVGltZXJzIHN1YnN5
c3RlbQ0KIw0KQ09ORklHX1RJQ0tfT05FU0hPVD15DQpDT05GSUdfTk9fSFpf
Q09NTU9OPXkNCiMgQ09ORklHX0haX1BFUklPRElDIGlzIG5vdCBzZXQNCkNP
TkZJR19OT19IWl9JRExFPXkNCiMgQ09ORklHX05PX0haX0ZVTEwgaXMgbm90
IHNldA0KQ09ORklHX05PX0haPXkNCkNPTkZJR19ISUdIX1JFU19USU1FUlM9
eQ0KIyBlbmQgb2YgVGltZXJzIHN1YnN5c3RlbQ0KDQpDT05GSUdfSEFWRV9Q
UkVFTVBUX0xBWlk9eQ0KQ09ORklHX1BSRUVNUFRfTEFaWT15DQojIENPTkZJ
R19QUkVFTVBUX05PTkUgaXMgbm90IHNldA0KIyBDT05GSUdfUFJFRU1QVF9W
T0xVTlRBUlkgaXMgbm90IHNldA0KIyBDT05GSUdfUFJFRU1QVCBpcyBub3Qg
c2V0DQpDT05GSUdfUFJFRU1QVF9SVD15DQpDT05GSUdfUFJFRU1QVF9DT1VO
VD15DQpDT05GSUdfUFJFRU1QVElPTj15DQoNCiMNCiMgQ1BVL1Rhc2sgdGlt
ZSBhbmQgc3RhdHMgYWNjb3VudGluZw0KIw0KQ09ORklHX1RJQ0tfQ1BVX0FD
Q09VTlRJTkc9eQ0KIyBDT05GSUdfVklSVF9DUFVfQUNDT1VOVElOR19HRU4g
aXMgbm90IHNldA0KIyBDT05GSUdfSVJRX1RJTUVfQUNDT1VOVElORyBpcyBu
b3Qgc2V0DQpDT05GSUdfQlNEX1BST0NFU1NfQUNDVD15DQojIENPTkZJR19C
U0RfUFJPQ0VTU19BQ0NUX1YzIGlzIG5vdCBzZXQNCkNPTkZJR19UQVNLU1RB
VFM9eQ0KQ09ORklHX1RBU0tfREVMQVlfQUNDVD15DQpDT05GSUdfVEFTS19Y
QUNDVD15DQpDT05GSUdfVEFTS19JT19BQ0NPVU5USU5HPXkNCiMgQ09ORklH
X1BTSSBpcyBub3Qgc2V0DQojIGVuZCBvZiBDUFUvVGFzayB0aW1lIGFuZCBz
dGF0cyBhY2NvdW50aW5nDQoNCkNPTkZJR19DUFVfSVNPTEFUSU9OPXkNCg0K
Iw0KIyBSQ1UgU3Vic3lzdGVtDQojDQpDT05GSUdfVFJFRV9SQ1U9eQ0KQ09O
RklHX1BSRUVNUFRfUkNVPXkNCiMgQ09ORklHX1JDVV9FWFBFUlQgaXMgbm90
IHNldA0KQ09ORklHX1NSQ1U9eQ0KQ09ORklHX1RSRUVfU1JDVT15DQpDT05G
SUdfVEFTS1NfUkNVPXkNCkNPTkZJR19SQ1VfU1RBTExfQ09NTU9OPXkNCkNP
TkZJR19SQ1VfTkVFRF9TRUdDQkxJU1Q9eQ0KQ09ORklHX1JDVV9CT09TVD15
DQpDT05GSUdfUkNVX0JPT1NUX0RFTEFZPTUwMA0KIyBlbmQgb2YgUkNVIFN1
YnN5c3RlbQ0KDQpDT05GSUdfSUtDT05GSUc9eQ0KQ09ORklHX0lLQ09ORklH
X1BST0M9eQ0KIyBDT05GSUdfSUtIRUFERVJTIGlzIG5vdCBzZXQNCkNPTkZJ
R19MT0dfQlVGX1NISUZUPTE2DQpDT05GSUdfTE9HX0NQVV9NQVhfQlVGX1NI
SUZUPTEyDQpDT05GSUdfUFJJTlRLX1NBRkVfTE9HX0JVRl9TSElGVD0xMw0K
Q09ORklHX0dFTkVSSUNfU0NIRURfQ0xPQ0s9eQ0KDQojDQojIFNjaGVkdWxl
ciBmZWF0dXJlcw0KIw0KIyBlbmQgb2YgU2NoZWR1bGVyIGZlYXR1cmVzDQoN
CkNPTkZJR19BUkNIX1NVUFBPUlRTX05VTUFfQkFMQU5DSU5HPXkNCkNPTkZJ
R19DQ19IQVNfSU5UMTI4PXkNCkNPTkZJR19BUkNIX1NVUFBPUlRTX0lOVDEy
OD15DQpDT05GSUdfQ0dST1VQUz15DQpDT05GSUdfUEFHRV9DT1VOVEVSPXkN
CiMgQ09ORklHX01FTUNHIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19DR1JP
VVAgaXMgbm90IHNldA0KQ09ORklHX0NHUk9VUF9TQ0hFRD15DQpDT05GSUdf
RkFJUl9HUk9VUF9TQ0hFRD15DQojIENPTkZJR19DRlNfQkFORFdJRFRIIGlz
IG5vdCBzZXQNCkNPTkZJR19DR1JPVVBfUElEUz15DQpDT05GSUdfQ0dST1VQ
X1JETUE9eQ0KQ09ORklHX0NHUk9VUF9GUkVFWkVSPXkNCkNPTkZJR19DR1JP
VVBfSFVHRVRMQj15DQojIENPTkZJR19DUFVTRVRTIGlzIG5vdCBzZXQNCkNP
TkZJR19DR1JPVVBfREVWSUNFPXkNCkNPTkZJR19DR1JPVVBfQ1BVQUNDVD15
DQpDT05GSUdfQ0dST1VQX1BFUkY9eQ0KQ09ORklHX0NHUk9VUF9ERUJVRz15
DQpDT05GSUdfTkFNRVNQQUNFUz15DQpDT05GSUdfVVRTX05TPXkNCkNPTkZJ
R19JUENfTlM9eQ0KQ09ORklHX1VTRVJfTlM9eQ0KQ09ORklHX1BJRF9OUz15
DQpDT05GSUdfTkVUX05TPXkNCiMgQ09ORklHX0NIRUNLUE9JTlRfUkVTVE9S
RSBpcyBub3Qgc2V0DQojIENPTkZJR19TQ0hFRF9BVVRPR1JPVVAgaXMgbm90
IHNldA0KIyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0DQoj
IENPTkZJR19SRUxBWSBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9JTklU
UkQ9eQ0KQ09ORklHX0lOSVRSQU1GU19TT1VSQ0U9IiINCkNPTkZJR19SRF9H
WklQPXkNCkNPTkZJR19SRF9CWklQMj15DQpDT05GSUdfUkRfTFpNQT15DQpD
T05GSUdfUkRfWFo9eQ0KQ09ORklHX1JEX0xaTz15DQpDT05GSUdfUkRfTFo0
PXkNCiMgQ09ORklHX0JPT1RfQ09ORklHIGlzIG5vdCBzZXQNCkNPTkZJR19D
Q19PUFRJTUlaRV9GT1JfUEVSRk9STUFOQ0U9eQ0KIyBDT05GSUdfQ0NfT1BU
SU1JWkVfRk9SX1NJWkUgaXMgbm90IHNldA0KQ09ORklHX1NZU0NUTD15DQpD
T05GSUdfSEFWRV9VSUQxNj15DQpDT05GSUdfU1lTQ1RMX0VYQ0VQVElPTl9U
UkFDRT15DQpDT05GSUdfQlBGPXkNCkNPTkZJR19FWFBFUlQ9eQ0KQ09ORklH
X1VJRDE2PXkNCkNPTkZJR19NVUxUSVVTRVI9eQ0KIyBDT05GSUdfU0dFVE1B
U0tfU1lTQ0FMTCBpcyBub3Qgc2V0DQpDT05GSUdfU1lTRlNfU1lTQ0FMTD15
DQpDT05GSUdfRkhBTkRMRT15DQpDT05GSUdfUE9TSVhfVElNRVJTPXkNCkNP
TkZJR19QUklOVEs9eQ0KQ09ORklHX1BSSU5US19OTUk9eQ0KQ09ORklHX0JV
Rz15DQpDT05GSUdfRUxGX0NPUkU9eQ0KQ09ORklHX0JBU0VfRlVMTD15DQpD
T05GSUdfRlVURVg9eQ0KQ09ORklHX0ZVVEVYX1BJPXkNCkNPTkZJR19IQVZF
X0ZVVEVYX0NNUFhDSEc9eQ0KQ09ORklHX0VQT0xMPXkNCkNPTkZJR19TSUdO
QUxGRD15DQpDT05GSUdfVElNRVJGRD15DQpDT05GSUdfRVZFTlRGRD15DQpD
T05GSUdfU0hNRU09eQ0KQ09ORklHX0FJTz15DQpDT05GSUdfSU9fVVJJTkc9
eQ0KQ09ORklHX0FEVklTRV9TWVNDQUxMUz15DQpDT05GSUdfTUVNQkFSUklF
Uj15DQpDT05GSUdfS0FMTFNZTVM9eQ0KIyBDT05GSUdfS0FMTFNZTVNfQUxM
IGlzIG5vdCBzZXQNCkNPTkZJR19LQUxMU1lNU19CQVNFX1JFTEFUSVZFPXkN
CiMgQ09ORklHX0JQRl9TWVNDQUxMIGlzIG5vdCBzZXQNCkNPTkZJR19BUkNI
X1dBTlRfREVGQVVMVF9CUEZfSklUPXkNCiMgQ09ORklHX1VTRVJGQVVMVEZE
IGlzIG5vdCBzZXQNCkNPTkZJR19BUkNIX0hBU19NRU1CQVJSSUVSX1NZTkNf
Q09SRT15DQpDT05GSUdfUlNFUT15DQojIENPTkZJR19ERUJVR19SU0VRIGlz
IG5vdCBzZXQNCkNPTkZJR19FTUJFRERFRD15DQpDT05GSUdfSEFWRV9QRVJG
X0VWRU5UUz15DQojIENPTkZJR19QQzEwNCBpcyBub3Qgc2V0DQoNCiMNCiMg
S2VybmVsIFBlcmZvcm1hbmNlIEV2ZW50cyBBbmQgQ291bnRlcnMNCiMNCkNP
TkZJR19QRVJGX0VWRU5UUz15DQojIENPTkZJR19ERUJVR19QRVJGX1VTRV9W
TUFMTE9DIGlzIG5vdCBzZXQNCiMgZW5kIG9mIEtlcm5lbCBQZXJmb3JtYW5j
ZSBFdmVudHMgQW5kIENvdW50ZXJzDQoNCkNPTkZJR19WTV9FVkVOVF9DT1VO
VEVSUz15DQpDT05GSUdfU0xVQl9ERUJVRz15DQojIENPTkZJR19DT01QQVRf
QlJLIGlzIG5vdCBzZXQNCkNPTkZJR19TTFVCPXkNCkNPTkZJR19TTEFCX01F
UkdFX0RFRkFVTFQ9eQ0KIyBDT05GSUdfU0xBQl9GUkVFTElTVF9SQU5ET00g
aXMgbm90IHNldA0KIyBDT05GSUdfU0xBQl9GUkVFTElTVF9IQVJERU5FRCBp
cyBub3Qgc2V0DQojIENPTkZJR19TSFVGRkxFX1BBR0VfQUxMT0NBVE9SIGlz
IG5vdCBzZXQNCkNPTkZJR19TWVNURU1fREFUQV9WRVJJRklDQVRJT049eQ0K
Q09ORklHX1BST0ZJTElORz15DQojIGVuZCBvZiBHZW5lcmFsIHNldHVwDQoN
CkNPTkZJR19BUk02ND15DQpDT05GSUdfNjRCSVQ9eQ0KQ09ORklHX01NVT15
DQpDT05GSUdfQVJNNjRfUEFHRV9TSElGVD0xMg0KQ09ORklHX0FSTTY0X0NP
TlRfU0hJRlQ9NA0KQ09ORklHX0FSQ0hfTU1BUF9STkRfQklUU19NSU49MTgN
CkNPTkZJR19BUkNIX01NQVBfUk5EX0JJVFNfTUFYPTI0DQpDT05GSUdfQVJD
SF9NTUFQX1JORF9DT01QQVRfQklUU19NSU49MTENCkNPTkZJR19BUkNIX01N
QVBfUk5EX0NPTVBBVF9CSVRTX01BWD0xNg0KQ09ORklHX05PX0lPUE9SVF9N
QVA9eQ0KQ09ORklHX1NUQUNLVFJBQ0VfU1VQUE9SVD15DQpDT05GSUdfSUxM
RUdBTF9QT0lOVEVSX1ZBTFVFPTB4ZGVhZDAwMDAwMDAwMDAwMA0KQ09ORklH
X0xPQ0tERVBfU1VQUE9SVD15DQpDT05GSUdfVFJBQ0VfSVJRRkxBR1NfU1VQ
UE9SVD15DQpDT05GSUdfR0VORVJJQ19CVUc9eQ0KQ09ORklHX0dFTkVSSUNf
QlVHX1JFTEFUSVZFX1BPSU5URVJTPXkNCkNPTkZJR19HRU5FUklDX0hXRUlH
SFQ9eQ0KQ09ORklHX0dFTkVSSUNfQ1NVTT15DQpDT05GSUdfR0VORVJJQ19D
QUxJQlJBVEVfREVMQVk9eQ0KQ09ORklHX1pPTkVfRE1BPXkNCkNPTkZJR19a
T05FX0RNQTMyPXkNCkNPTkZJR19BUkNIX0VOQUJMRV9NRU1PUllfSE9UUExV
Rz15DQpDT05GSUdfU01QPXkNCkNPTkZJR19LRVJORUxfTU9ERV9ORU9OPXkN
CkNPTkZJR19GSVhfRUFSTFlDT05fTUVNPXkNCkNPTkZJR19QR1RBQkxFX0xF
VkVMUz0zDQpDT05GSUdfQVJDSF9TVVBQT1JUU19VUFJPQkVTPXkNCkNPTkZJ
R19BUkNIX1BST0NfS0NPUkVfVEVYVD15DQpDT05GSUdfQlJPS0VOX0dBU19J
TlNUPXkNCg0KIw0KIyBQbGF0Zm9ybSBzZWxlY3Rpb24NCiMNCiMgQ09ORklH
X0FSQ0hfQUNUSU9OUyBpcyBub3Qgc2V0DQojIENPTkZJR19BUkNIX0FHSUxF
WCBpcyBub3Qgc2V0DQojIENPTkZJR19BUkNIX1NVTlhJIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0FSQ0hfQUxQSU5FIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FS
Q0hfQkNNMjgzNSBpcyBub3Qgc2V0DQojIENPTkZJR19BUkNIX0JDTV9JUFJP
QyBpcyBub3Qgc2V0DQojIENPTkZJR19BUkNIX0JFUkxJTiBpcyBub3Qgc2V0
DQojIENPTkZJR19BUkNIX0JJVE1BSU4gaXMgbm90IHNldA0KIyBDT05GSUdf
QVJDSF9CUkNNU1RCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FSQ0hfRVhZTk9T
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FSQ0hfSzMgaXMgbm90IHNldA0KIyBD
T05GSUdfQVJDSF9MQVlFUlNDQVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FS
Q0hfTEcxSyBpcyBub3Qgc2V0DQojIENPTkZJR19BUkNIX0hJU0kgaXMgbm90
IHNldA0KIyBDT05GSUdfQVJDSF9NRURJQVRFSyBpcyBub3Qgc2V0DQojIENP
TkZJR19BUkNIX01FU09OIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FSQ0hfTVZF
QlUgaXMgbm90IHNldA0KIyBDT05GSUdfQVJDSF9NWEMgaXMgbm90IHNldA0K
IyBDT05GSUdfQVJDSF9RQ09NIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FSQ0hf
UkVBTFRFSyBpcyBub3Qgc2V0DQojIENPTkZJR19BUkNIX1JFTkVTQVMgaXMg
bm90IHNldA0KIyBDT05GSUdfQVJDSF9ST0NLQ0hJUCBpcyBub3Qgc2V0DQoj
IENPTkZJR19BUkNIX1MzMiBpcyBub3Qgc2V0DQojIENPTkZJR19BUkNIX1NF
QVRUTEUgaXMgbm90IHNldA0KIyBDT05GSUdfQVJDSF9TVFJBVElYMTAgaXMg
bm90IHNldA0KIyBDT05GSUdfQVJDSF9TWU5RVUFDRVIgaXMgbm90IHNldA0K
IyBDT05GSUdfQVJDSF9URUdSQSBpcyBub3Qgc2V0DQojIENPTkZJR19BUkNI
X1NQUkQgaXMgbm90IHNldA0KIyBDT05GSUdfQVJDSF9USFVOREVSIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0FSQ0hfVEhVTkRFUjIgaXMgbm90IHNldA0KIyBD
T05GSUdfQVJDSF9VTklQSElFUiBpcyBub3Qgc2V0DQojIENPTkZJR19BUkNI
X1ZFWFBSRVNTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FSQ0hfWEdFTkUgaXMg
bm90IHNldA0KIyBDT05GSUdfQVJDSF9aWCBpcyBub3Qgc2V0DQpDT05GSUdf
QVJDSF9aWU5RTVA9eQ0KIyBlbmQgb2YgUGxhdGZvcm0gc2VsZWN0aW9uDQoN
CiMNCiMgS2VybmVsIEZlYXR1cmVzDQojDQoNCiMNCiMgQVJNIGVycmF0YSB3
b3JrYXJvdW5kcyB2aWEgdGhlIGFsdGVybmF0aXZlcyBmcmFtZXdvcmsNCiMN
CkNPTkZJR19BUk02NF9XT1JLQVJPVU5EX0NMRUFOX0NBQ0hFPXkNCkNPTkZJ
R19BUk02NF9FUlJBVFVNXzgyNjMxOT15DQpDT05GSUdfQVJNNjRfRVJSQVRV
TV84MjczMTk9eQ0KQ09ORklHX0FSTTY0X0VSUkFUVU1fODI0MDY5PXkNCkNP
TkZJR19BUk02NF9FUlJBVFVNXzgxOTQ3Mj15DQpDT05GSUdfQVJNNjRfRVJS
QVRVTV84MzIwNzU9eQ0KQ09ORklHX0FSTTY0X0VSUkFUVU1fODQ1NzE5PXkN
CkNPTkZJR19BUk02NF9FUlJBVFVNXzg0MzQxOT15DQpDT05GSUdfQVJNNjRf
RVJSQVRVTV8xMDI0NzE4PXkNCkNPTkZJR19BUk02NF9FUlJBVFVNXzE0MTgw
NDA9eQ0KQ09ORklHX0FSTTY0X1dPUktBUk9VTkRfU1BFQ1VMQVRJVkVfQVRf
VkhFPXkNCkNPTkZJR19BUk02NF9FUlJBVFVNXzExNjU1MjI9eQ0KQ09ORklH
X0FSTTY0X0VSUkFUVU1fMTUzMDkyMz15DQpDT05GSUdfQVJNNjRfRVJSQVRV
TV8xMjg2ODA3PXkNCkNPTkZJR19BUk02NF9XT1JLQVJPVU5EX1NQRUNVTEFU
SVZFX0FUX05WSEU9eQ0KQ09ORklHX0FSTTY0X0VSUkFUVU1fMTMxOTM2Nz15
DQpDT05GSUdfQVJNNjRfRVJSQVRVTV8xNDYzMjI1PXkNCkNPTkZJR19BUk02
NF9FUlJBVFVNXzE1NDI0MTk9eQ0KQ09ORklHX0NBVklVTV9FUlJBVFVNXzIy
Mzc1PXkNCkNPTkZJR19DQVZJVU1fRVJSQVRVTV8yMzE1ND15DQpDT05GSUdf
Q0FWSVVNX0VSUkFUVU1fMjc0NTY9eQ0KQ09ORklHX0NBVklVTV9FUlJBVFVN
XzMwMTE1PXkNCkNPTkZJR19DQVZJVU1fVFgyX0VSUkFUVU1fMjE5PXkNCkNP
TkZJR19RQ09NX0ZBTEtPUl9FUlJBVFVNXzEwMDM9eQ0KQ09ORklHX0FSTTY0
X1dPUktBUk9VTkRfUkVQRUFUX1RMQkk9eQ0KQ09ORklHX1FDT01fRkFMS09S
X0VSUkFUVU1fMTAwOT15DQpDT05GSUdfUUNPTV9RREYyNDAwX0VSUkFUVU1f
MDA2NT15DQpDT05GSUdfU09DSU9ORVhUX1NZTlFVQUNFUl9QUkVJVFM9eQ0K
Q09ORklHX0hJU0lMSUNPTl9FUlJBVFVNXzE2MTYwMDgwMj15DQpDT05GSUdf
UUNPTV9GQUxLT1JfRVJSQVRVTV9FMTA0MT15DQpDT05GSUdfRlVKSVRTVV9F
UlJBVFVNXzAxMDAwMT15DQojIGVuZCBvZiBBUk0gZXJyYXRhIHdvcmthcm91
bmRzIHZpYSB0aGUgYWx0ZXJuYXRpdmVzIGZyYW1ld29yaw0KDQpDT05GSUdf
QVJNNjRfNEtfUEFHRVM9eQ0KIyBDT05GSUdfQVJNNjRfMTZLX1BBR0VTIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0FSTTY0XzY0S19QQUdFUyBpcyBub3Qgc2V0
DQpDT05GSUdfQVJNNjRfVkFfQklUU18zOT15DQojIENPTkZJR19BUk02NF9W
QV9CSVRTXzQ4IGlzIG5vdCBzZXQNCkNPTkZJR19BUk02NF9WQV9CSVRTPTM5
DQpDT05GSUdfQVJNNjRfUEFfQklUU180OD15DQpDT05GSUdfQVJNNjRfUEFf
QklUUz00OA0KIyBDT05GSUdfQ1BVX0JJR19FTkRJQU4gaXMgbm90IHNldA0K
Q09ORklHX0NQVV9MSVRUTEVfRU5ESUFOPXkNCiMgQ09ORklHX1NDSEVEX01D
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDSEVEX1NNVCBpcyBub3Qgc2V0DQpD
T05GSUdfTlJfQ1BVUz04DQpDT05GSUdfSE9UUExVR19DUFU9eQ0KIyBDT05G
SUdfTlVNQSBpcyBub3Qgc2V0DQpDT05GSUdfSE9MRVNfSU5fWk9ORT15DQoj
IENPTkZJR19IWl8xMDAgaXMgbm90IHNldA0KQ09ORklHX0haXzI1MD15DQoj
IENPTkZJR19IWl8zMDAgaXMgbm90IHNldA0KIyBDT05GSUdfSFpfMTAwMCBp
cyBub3Qgc2V0DQpDT05GSUdfSFo9MjUwDQpDT05GSUdfU0NIRURfSFJUSUNL
PXkNCkNPTkZJR19BUkNIX1NVUFBPUlRTX0RFQlVHX1BBR0VBTExPQz15DQpD
T05GSUdfQVJDSF9TUEFSU0VNRU1fRU5BQkxFPXkNCkNPTkZJR19BUkNIX1NQ
QVJTRU1FTV9ERUZBVUxUPXkNCkNPTkZJR19BUkNIX1NFTEVDVF9NRU1PUllf
TU9ERUw9eQ0KQ09ORklHX0FSQ0hfRkxBVE1FTV9FTkFCTEU9eQ0KQ09ORklH
X0hBVkVfQVJDSF9QRk5fVkFMSUQ9eQ0KQ09ORklHX0hXX1BFUkZfRVZFTlRT
PXkNCkNPTkZJR19TWVNfU1VQUE9SVFNfSFVHRVRMQkZTPXkNCkNPTkZJR19B
UkNIX1dBTlRfSFVHRV9QTURfU0hBUkU9eQ0KQ09ORklHX0FSQ0hfSEFTX0NB
Q0hFX0xJTkVfU0laRT15DQpDT05GSUdfQVJDSF9FTkFCTEVfU1BMSVRfUE1E
X1BUTE9DSz15DQojIENPTkZJR19TRUNDT01QIGlzIG5vdCBzZXQNCkNPTkZJ
R19QQVJBVklSVD15DQojIENPTkZJR19QQVJBVklSVF9USU1FX0FDQ09VTlRJ
TkcgaXMgbm90IHNldA0KIyBDT05GSUdfS0VYRUMgaXMgbm90IHNldA0KIyBD
T05GSUdfS0VYRUNfRklMRSBpcyBub3Qgc2V0DQojIENPTkZJR19DUkFTSF9E
VU1QIGlzIG5vdCBzZXQNCkNPTkZJR19YRU5fRE9NMD15DQpDT05GSUdfWEVO
PXkNCkNPTkZJR19GT1JDRV9NQVhfWk9ORU9SREVSPTExDQpDT05GSUdfVU5N
QVBfS0VSTkVMX0FUX0VMMD15DQpDT05GSUdfSEFSREVOX0JSQU5DSF9QUkVE
SUNUT1I9eQ0KQ09ORklHX0hBUkRFTl9FTDJfVkVDVE9SUz15DQpDT05GSUdf
QVJNNjRfU1NCRD15DQpDT05GSUdfUk9EQVRBX0ZVTExfREVGQVVMVF9FTkFC
TEVEPXkNCiMgQ09ORklHX0FSTTY0X1NXX1RUQlIwX1BBTiBpcyBub3Qgc2V0
DQpDT05GSUdfQVJNNjRfVEFHR0VEX0FERFJfQUJJPXkNCkNPTkZJR19DT01Q
QVQ9eQ0KQ09ORklHX0tVU0VSX0hFTFBFUlM9eQ0KIyBDT05GSUdfQVJNVjhf
REVQUkVDQVRFRCBpcyBub3Qgc2V0DQoNCiMNCiMgQVJNdjguMSBhcmNoaXRl
Y3R1cmFsIGZlYXR1cmVzDQojDQpDT05GSUdfQVJNNjRfSFdfQUZEQk09eQ0K
Q09ORklHX0FSTTY0X1BBTj15DQpDT05GSUdfQVJNNjRfVkhFPXkNCiMgZW5k
IG9mIEFSTXY4LjEgYXJjaGl0ZWN0dXJhbCBmZWF0dXJlcw0KDQojDQojIEFS
TXY4LjIgYXJjaGl0ZWN0dXJhbCBmZWF0dXJlcw0KIw0KQ09ORklHX0FSTTY0
X1VBTz15DQojIENPTkZJR19BUk02NF9QTUVNIGlzIG5vdCBzZXQNCkNPTkZJ
R19BUk02NF9SQVNfRVhUTj15DQpDT05GSUdfQVJNNjRfQ05QPXkNCiMgZW5k
IG9mIEFSTXY4LjIgYXJjaGl0ZWN0dXJhbCBmZWF0dXJlcw0KDQojDQojIEFS
TXY4LjMgYXJjaGl0ZWN0dXJhbCBmZWF0dXJlcw0KIw0KQ09ORklHX0FSTTY0
X1BUUl9BVVRIPXkNCiMgZW5kIG9mIEFSTXY4LjMgYXJjaGl0ZWN0dXJhbCBm
ZWF0dXJlcw0KDQojDQojIEFSTXY4LjUgYXJjaGl0ZWN0dXJhbCBmZWF0dXJl
cw0KIw0KQ09ORklHX0FSTTY0X0UwUEQ9eQ0KQ09ORklHX0FSQ0hfUkFORE9N
PXkNCiMgZW5kIG9mIEFSTXY4LjUgYXJjaGl0ZWN0dXJhbCBmZWF0dXJlcw0K
DQpDT05GSUdfQVJNNjRfU1ZFPXkNCkNPTkZJR19BUk02NF9NT0RVTEVfUExU
Uz15DQojIENPTkZJR19BUk02NF9QU0VVRE9fTk1JIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1JBTkRPTUlaRV9CQVNFIGlzIG5vdCBzZXQNCiMgZW5kIG9mIEtl
cm5lbCBGZWF0dXJlcw0KDQojDQojIEJvb3Qgb3B0aW9ucw0KIw0KQ09ORklH
X0NNRExJTkU9IiINCkNPTkZJR19FRklfU1RVQj15DQpDT05GSUdfRUZJPXkN
CiMgQ09ORklHX0RNSSBpcyBub3Qgc2V0DQojIGVuZCBvZiBCb290IG9wdGlv
bnMNCg0KQ09ORklHX1NZU1ZJUENfQ09NUEFUPXkNCkNPTkZJR19BUkNIX0VO
QUJMRV9IVUdFUEFHRV9NSUdSQVRJT049eQ0KDQojDQojIFBvd2VyIG1hbmFn
ZW1lbnQgb3B0aW9ucw0KIw0KQ09ORklHX1NVU1BFTkQ9eQ0KQ09ORklHX1NV
U1BFTkRfRlJFRVpFUj15DQojIENPTkZJR19TVVNQRU5EX1NLSVBfU1lOQyBp
cyBub3Qgc2V0DQojIENPTkZJR19ISUJFUk5BVElPTiBpcyBub3Qgc2V0DQpD
T05GSUdfUE1fU0xFRVA9eQ0KQ09ORklHX1BNX1NMRUVQX1NNUD15DQojIENP
TkZJR19QTV9BVVRPU0xFRVAgaXMgbm90IHNldA0KIyBDT05GSUdfUE1fV0FL
RUxPQ0tTIGlzIG5vdCBzZXQNCkNPTkZJR19QTT15DQojIENPTkZJR19QTV9E
RUJVRyBpcyBub3Qgc2V0DQpDT05GSUdfUE1fQ0xLPXkNCkNPTkZJR19QTV9H
RU5FUklDX0RPTUFJTlM9eQ0KIyBDT05GSUdfV1FfUE9XRVJfRUZGSUNJRU5U
X0RFRkFVTFQgaXMgbm90IHNldA0KQ09ORklHX1BNX0dFTkVSSUNfRE9NQUlO
U19TTEVFUD15DQpDT05GSUdfUE1fR0VORVJJQ19ET01BSU5TX09GPXkNCkNP
TkZJR19DUFVfUE09eQ0KIyBDT05GSUdfRU5FUkdZX01PREVMIGlzIG5vdCBz
ZXQNCkNPTkZJR19BUkNIX0hJQkVSTkFUSU9OX1BPU1NJQkxFPXkNCkNPTkZJ
R19BUkNIX1NVU1BFTkRfUE9TU0lCTEU9eQ0KIyBlbmQgb2YgUG93ZXIgbWFu
YWdlbWVudCBvcHRpb25zDQoNCiMNCiMgQ1BVIFBvd2VyIE1hbmFnZW1lbnQN
CiMNCg0KIw0KIyBDUFUgSWRsZQ0KIw0KQ09ORklHX0NQVV9JRExFPXkNCkNP
TkZJR19DUFVfSURMRV9NVUxUSVBMRV9EUklWRVJTPXkNCiMgQ09ORklHX0NQ
VV9JRExFX0dPVl9MQURERVIgaXMgbm90IHNldA0KQ09ORklHX0NQVV9JRExF
X0dPVl9NRU5VPXkNCiMgQ09ORklHX0NQVV9JRExFX0dPVl9URU8gaXMgbm90
IHNldA0KQ09ORklHX0RUX0lETEVfU1RBVEVTPXkNCg0KIw0KIyBBUk0gQ1BV
IElkbGUgRHJpdmVycw0KIw0KQ09ORklHX0FSTV9DUFVJRExFPXkNCiMgQ09O
RklHX0FSTV9QU0NJX0NQVUlETEUgaXMgbm90IHNldA0KIyBlbmQgb2YgQVJN
IENQVSBJZGxlIERyaXZlcnMNCiMgZW5kIG9mIENQVSBJZGxlDQoNCiMNCiMg
Q1BVIEZyZXF1ZW5jeSBzY2FsaW5nDQojDQpDT05GSUdfQ1BVX0ZSRVE9eQ0K
IyBDT05GSUdfQ1BVX0ZSRVFfU1RBVCBpcyBub3Qgc2V0DQojIENPTkZJR19D
UFVfRlJFUV9ERUZBVUxUX0dPVl9QRVJGT1JNQU5DRSBpcyBub3Qgc2V0DQoj
IENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9QT1dFUlNBVkUgaXMgbm90
IHNldA0KQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09WX1VTRVJTUEFDRT15
DQojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9PTkRFTUFORCBpcyBu
b3Qgc2V0DQojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9DT05TRVJW
QVRJVkUgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9H
T1ZfU0NIRURVVElMIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9GUkVRX0dP
Vl9QRVJGT1JNQU5DRSBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfRlJFUV9H
T1ZfUE9XRVJTQVZFIGlzIG5vdCBzZXQNCkNPTkZJR19DUFVfRlJFUV9HT1Zf
VVNFUlNQQUNFPXkNCiMgQ09ORklHX0NQVV9GUkVRX0dPVl9PTkRFTUFORCBp
cyBub3Qgc2V0DQojIENPTkZJR19DUFVfRlJFUV9HT1ZfQ09OU0VSVkFUSVZF
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9GUkVRX0dPVl9TQ0hFRFVUSUwg
aXMgbm90IHNldA0KDQojDQojIENQVSBmcmVxdWVuY3kgc2NhbGluZyBkcml2
ZXJzDQojDQpDT05GSUdfQ1BVRlJFUV9EVD15DQpDT05GSUdfQ1BVRlJFUV9E
VF9QTEFUREVWPXkNCiMgQ09ORklHX1FPUklRX0NQVUZSRVEgaXMgbm90IHNl
dA0KIyBlbmQgb2YgQ1BVIEZyZXF1ZW5jeSBzY2FsaW5nDQojIGVuZCBvZiBD
UFUgUG93ZXIgTWFuYWdlbWVudA0KDQojDQojIEZpcm13YXJlIERyaXZlcnMN
CiMNCiMgQ09ORklHX0FSTV9TQ01JX1BST1RPQ09MIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0FSTV9TQ1BJX1BST1RPQ09MIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0FSTV9TREVfSU5URVJGQUNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZJUk1X
QVJFX01FTU1BUCBpcyBub3Qgc2V0DQpDT05GSUdfSEFWRV9BUk1fU01DQ0M9
eQ0KQ09ORklHX0FSTV9QU0NJX0ZXPXkNCiMgQ09ORklHX0FSTV9QU0NJX0NI
RUNLRVIgaXMgbm90IHNldA0KIyBDT05GSUdfR09PR0xFX0ZJUk1XQVJFIGlz
IG5vdCBzZXQNCg0KIw0KIyBFRkkgKEV4dGVuc2libGUgRmlybXdhcmUgSW50
ZXJmYWNlKSBTdXBwb3J0DQojDQojIENPTkZJR19FRklfVkFSUyBpcyBub3Qg
c2V0DQpDT05GSUdfRUZJX0VTUlQ9eQ0KQ09ORklHX0VGSV9QQVJBTVNfRlJP
TV9GRFQ9eQ0KQ09ORklHX0VGSV9SVU5USU1FX1dSQVBQRVJTPXkNCkNPTkZJ
R19FRklfQVJNU1RVQj15DQpDT05GSUdfRUZJX0FSTVNUVUJfRFRCX0xPQURF
Uj15DQojIENPTkZJR19FRklfQ0FQU1VMRV9MT0FERVIgaXMgbm90IHNldA0K
IyBDT05GSUdfRUZJX1RFU1QgaXMgbm90IHNldA0KIyBDT05GSUdfUkVTRVRf
QVRUQUNLX01JVElHQVRJT04gaXMgbm90IHNldA0KIyBDT05GSUdfRUZJX0RJ
U0FCTEVfUENJX0RNQSBpcyBub3Qgc2V0DQojIGVuZCBvZiBFRkkgKEV4dGVu
c2libGUgRmlybXdhcmUgSW50ZXJmYWNlKSBTdXBwb3J0DQoNCkNPTkZJR19F
RklfRUFSTFlDT049eQ0KDQojDQojIFRlZ3JhIGZpcm13YXJlIGRyaXZlcg0K
Iw0KIyBlbmQgb2YgVGVncmEgZmlybXdhcmUgZHJpdmVyDQoNCiMNCiMgWnlu
cSBNUFNvQyBGaXJtd2FyZSBEcml2ZXJzDQojDQpDT05GSUdfWllOUU1QX0ZJ
Uk1XQVJFPXkNCiMgQ09ORklHX1pZTlFNUF9GSVJNV0FSRV9ERUJVRyBpcyBu
b3Qgc2V0DQojIGVuZCBvZiBaeW5xIE1QU29DIEZpcm13YXJlIERyaXZlcnMN
CiMgZW5kIG9mIEZpcm13YXJlIERyaXZlcnMNCg0KQ09ORklHX0FSQ0hfU1VQ
UE9SVFNfQUNQST15DQojIENPTkZJR19BQ1BJIGlzIG5vdCBzZXQNCkNPTkZJ
R19WSVJUVUFMSVpBVElPTj15DQojIENPTkZJR19LVk0gaXMgbm90IHNldA0K
IyBDT05GSUdfVkhPU1RfTkVUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZIT1NU
X0NST1NTX0VORElBTl9MRUdBQ1kgaXMgbm90IHNldA0KIyBDT05GSUdfQVJN
NjRfQ1JZUFRPIGlzIG5vdCBzZXQNCg0KIw0KIyBHZW5lcmFsIGFyY2hpdGVj
dHVyZS1kZXBlbmRlbnQgb3B0aW9ucw0KIw0KIyBDT05GSUdfS1BST0JFUyBp
cyBub3Qgc2V0DQojIENPTkZJR19KVU1QX0xBQkVMIGlzIG5vdCBzZXQNCkNP
TkZJR19IQVZFX0VGRklDSUVOVF9VTkFMSUdORURfQUNDRVNTPXkNCkNPTkZJ
R19IQVZFX0tQUk9CRVM9eQ0KQ09ORklHX0hBVkVfS1JFVFBST0JFUz15DQpD
T05GSUdfSEFWRV9GVU5DVElPTl9FUlJPUl9JTkpFQ1RJT049eQ0KQ09ORklH
X0hBVkVfTk1JPXkNCkNPTkZJR19IQVZFX0FSQ0hfVFJBQ0VIT09LPXkNCkNP
TkZJR19IQVZFX0RNQV9DT05USUdVT1VTPXkNCkNPTkZJR19HRU5FUklDX1NN
UF9JRExFX1RIUkVBRD15DQpDT05GSUdfR0VORVJJQ19JRExFX1BPTExfU0VU
VVA9eQ0KQ09ORklHX0FSQ0hfSEFTX0ZPUlRJRllfU09VUkNFPXkNCkNPTkZJ
R19BUkNIX0hBU19LRUVQSU5JVFJEPXkNCkNPTkZJR19BUkNIX0hBU19TRVRf
TUVNT1JZPXkNCkNPTkZJR19BUkNIX0hBU19TRVRfRElSRUNUX01BUD15DQpD
T05GSUdfSEFWRV9BUkNIX1RIUkVBRF9TVFJVQ1RfV0hJVEVMSVNUPXkNCkNP
TkZJR19IQVZFX0FTTV9NT0RWRVJTSU9OUz15DQpDT05GSUdfSEFWRV9SRUdT
X0FORF9TVEFDS19BQ0NFU1NfQVBJPXkNCkNPTkZJR19IQVZFX1JTRVE9eQ0K
Q09ORklHX0hBVkVfRlVOQ1RJT05fQVJHX0FDQ0VTU19BUEk9eQ0KQ09ORklH
X0hBVkVfQ0xLPXkNCkNPTkZJR19IQVZFX0hXX0JSRUFLUE9JTlQ9eQ0KQ09O
RklHX0hBVkVfUEVSRl9SRUdTPXkNCkNPTkZJR19IQVZFX1BFUkZfVVNFUl9T
VEFDS19EVU1QPXkNCkNPTkZJR19IQVZFX0FSQ0hfSlVNUF9MQUJFTD15DQpD
T05GSUdfSEFWRV9BUkNIX0pVTVBfTEFCRUxfUkVMQVRJVkU9eQ0KQ09ORklH
X01NVV9HQVRIRVJfVEFCTEVfRlJFRT15DQpDT05GSUdfTU1VX0dBVEhFUl9S
Q1VfVEFCTEVfRlJFRT15DQpDT05GSUdfQVJDSF9IQVZFX05NSV9TQUZFX0NN
UFhDSEc9eQ0KQ09ORklHX0hBVkVfQUxJR05FRF9TVFJVQ1RfUEFHRT15DQpD
T05GSUdfSEFWRV9DTVBYQ0hHX0xPQ0FMPXkNCkNPTkZJR19IQVZFX0NNUFhD
SEdfRE9VQkxFPXkNCkNPTkZJR19BUkNIX1dBTlRfQ09NUEFUX0lQQ19QQVJT
RV9WRVJTSU9OPXkNCkNPTkZJR19IQVZFX0FSQ0hfU0VDQ09NUF9GSUxURVI9
eQ0KQ09ORklHX0hBVkVfQVJDSF9TVEFDS0xFQUs9eQ0KQ09ORklHX0hBVkVf
U1RBQ0tQUk9URUNUT1I9eQ0KQ09ORklHX0NDX0hBU19TVEFDS1BST1RFQ1RP
Ul9OT05FPXkNCkNPTkZJR19TVEFDS1BST1RFQ1RPUj15DQpDT05GSUdfU1RB
Q0tQUk9URUNUT1JfU1RST05HPXkNCkNPTkZJR19IQVZFX0NPTlRFWFRfVFJB
Q0tJTkc9eQ0KQ09ORklHX0hBVkVfVklSVF9DUFVfQUNDT1VOVElOR19HRU49
eQ0KQ09ORklHX0hBVkVfSVJRX1RJTUVfQUNDT1VOVElORz15DQpDT05GSUdf
SEFWRV9BUkNIX1RSQU5TUEFSRU5UX0hVR0VQQUdFPXkNCkNPTkZJR19IQVZF
X0FSQ0hfSFVHRV9WTUFQPXkNCkNPTkZJR19IQVZFX01PRF9BUkNIX1NQRUNJ
RklDPXkNCkNPTkZJR19NT0RVTEVTX1VTRV9FTEZfUkVMQT15DQpDT05GSUdf
QVJDSF9IQVNfRUxGX1JBTkRPTUlaRT15DQpDT05GSUdfSEFWRV9BUkNIX01N
QVBfUk5EX0JJVFM9eQ0KQ09ORklHX0FSQ0hfTU1BUF9STkRfQklUUz0xOA0K
Q09ORklHX0hBVkVfQVJDSF9NTUFQX1JORF9DT01QQVRfQklUUz15DQpDT05G
SUdfQVJDSF9NTUFQX1JORF9DT01QQVRfQklUUz0xMQ0KQ09ORklHX0FSQ0hf
V0FOVF9ERUZBVUxUX1RPUERPV05fTU1BUF9MQVlPVVQ9eQ0KQ09ORklHX0hB
VkVfQ09QWV9USFJFQURfVExTPXkNCkNPTkZJR19DTE9ORV9CQUNLV0FSRFM9
eQ0KQ09ORklHX09MRF9TSUdTVVNQRU5EMz15DQpDT05GSUdfQ09NUEFUX09M
RF9TSUdBQ1RJT049eQ0KQ09ORklHX0NPTVBBVF8zMkJJVF9USU1FPXkNCkNP
TkZJR19BUkNIX1NVUFBPUlRTX1JUPXkNCkNPTkZJR19IQVZFX0FSQ0hfVk1B
UF9TVEFDSz15DQpDT05GSUdfVk1BUF9TVEFDSz15DQpDT05GSUdfQVJDSF9I
QVNfU1RSSUNUX0tFUk5FTF9SV1g9eQ0KQ09ORklHX1NUUklDVF9LRVJORUxf
UldYPXkNCkNPTkZJR19BUkNIX0hBU19TVFJJQ1RfTU9EVUxFX1JXWD15DQpD
T05GSUdfU1RSSUNUX01PRFVMRV9SV1g9eQ0KQ09ORklHX0hBVkVfQVJDSF9Q
UkVMMzJfUkVMT0NBVElPTlM9eQ0KQ09ORklHX0FSQ0hfVVNFX01FTVJFTUFQ
X1BST1Q9eQ0KIyBDT05GSUdfTE9DS19FVkVOVF9DT1VOVFMgaXMgbm90IHNl
dA0KDQojDQojIEdDT1YtYmFzZWQga2VybmVsIHByb2ZpbGluZw0KIw0KIyBD
T05GSUdfR0NPVl9LRVJORUwgaXMgbm90IHNldA0KQ09ORklHX0FSQ0hfSEFT
X0dDT1ZfUFJPRklMRV9BTEw9eQ0KIyBlbmQgb2YgR0NPVi1iYXNlZCBrZXJu
ZWwgcHJvZmlsaW5nDQoNCkNPTkZJR19QTFVHSU5fSE9TVENDPSIiDQpDT05G
SUdfSEFWRV9HQ0NfUExVR0lOUz15DQojIGVuZCBvZiBHZW5lcmFsIGFyY2hp
dGVjdHVyZS1kZXBlbmRlbnQgb3B0aW9ucw0KDQpDT05GSUdfUlRfTVVURVhF
Uz15DQpDT05GSUdfQkFTRV9TTUFMTD0wDQpDT05GSUdfTU9EVUxFUz15DQoj
IENPTkZJR19NT0RVTEVfRk9SQ0VfTE9BRCBpcyBub3Qgc2V0DQpDT05GSUdf
TU9EVUxFX1VOTE9BRD15DQojIENPTkZJR19NT0RVTEVfRk9SQ0VfVU5MT0FE
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01PRFZFUlNJT05TIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01PRFVMRV9TUkNWRVJTSU9OX0FMTCBpcyBub3Qgc2V0DQoj
IENPTkZJR19NT0RVTEVfU0lHIGlzIG5vdCBzZXQNCiMgQ09ORklHX01PRFVM
RV9DT01QUkVTUyBpcyBub3Qgc2V0DQojIENPTkZJR19NT0RVTEVfQUxMT1df
TUlTU0lOR19OQU1FU1BBQ0VfSU1QT1JUUyBpcyBub3Qgc2V0DQojIENPTkZJ
R19VTlVTRURfU1lNQk9MUyBpcyBub3Qgc2V0DQojIENPTkZJR19UUklNX1VO
VVNFRF9LU1lNUyBpcyBub3Qgc2V0DQpDT05GSUdfTU9EVUxFU19UUkVFX0xP
T0tVUD15DQpDT05GSUdfQkxPQ0s9eQ0KQ09ORklHX0JMS19TQ1NJX1JFUVVF
U1Q9eQ0KQ09ORklHX0JMS19ERVZfQlNHPXkNCiMgQ09ORklHX0JMS19ERVZf
QlNHTElCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSU5URUdSSVRZ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfWk9ORUQgaXMgbm90IHNl
dA0KIyBDT05GSUdfQkxLX0NNRExJTkVfUEFSU0VSIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0JMS19XQlQgaXMgbm90IHNldA0KQ09ORklHX0JMS19ERUJVR19G
Uz15DQojIENPTkZJR19CTEtfU0VEX09QQUwgaXMgbm90IHNldA0KDQojDQoj
IFBhcnRpdGlvbiBUeXBlcw0KIw0KIyBDT05GSUdfUEFSVElUSU9OX0FEVkFO
Q0VEIGlzIG5vdCBzZXQNCkNPTkZJR19NU0RPU19QQVJUSVRJT049eQ0KQ09O
RklHX0VGSV9QQVJUSVRJT049eQ0KIyBlbmQgb2YgUGFydGl0aW9uIFR5cGVz
DQoNCkNPTkZJR19CTE9DS19DT01QQVQ9eQ0KQ09ORklHX0JMS19NUV9WSVJU
SU89eQ0KQ09ORklHX0JMS19QTT15DQoNCiMNCiMgSU8gU2NoZWR1bGVycw0K
Iw0KQ09ORklHX01RX0lPU0NIRURfREVBRExJTkU9eQ0KQ09ORklHX01RX0lP
U0NIRURfS1lCRVI9eQ0KIyBDT05GSUdfSU9TQ0hFRF9CRlEgaXMgbm90IHNl
dA0KIyBlbmQgb2YgSU8gU2NoZWR1bGVycw0KDQpDT05GSUdfQVNOMT15DQpD
T05GSUdfQVJDSF9TVVBQT1JUU19BVE9NSUNfUk1XPXkNCkNPTkZJR19NVVRF
WF9TUElOX09OX09XTkVSPXkNCkNPTkZJR19SV1NFTV9TUElOX09OX09XTkVS
PXkNCkNPTkZJR19MT0NLX1NQSU5fT05fT1dORVI9eQ0KQ09ORklHX0FSQ0hf
VVNFX1FVRVVFRF9TUElOTE9DS1M9eQ0KQ09ORklHX1FVRVVFRF9TUElOTE9D
S1M9eQ0KQ09ORklHX0FSQ0hfVVNFX1FVRVVFRF9SV0xPQ0tTPXkNCkNPTkZJ
R19RVUVVRURfUldMT0NLUz15DQpDT05GSUdfQVJDSF9IQVNfU1lTQ0FMTF9X
UkFQUEVSPXkNCkNPTkZJR19GUkVFWkVSPXkNCg0KIw0KIyBFeGVjdXRhYmxl
IGZpbGUgZm9ybWF0cw0KIw0KQ09ORklHX0JJTkZNVF9FTEY9eQ0KQ09ORklH
X0NPTVBBVF9CSU5GTVRfRUxGPXkNCkNPTkZJR19FTEZDT1JFPXkNCkNPTkZJ
R19DT1JFX0RVTVBfREVGQVVMVF9FTEZfSEVBREVSUz15DQpDT05GSUdfQklO
Rk1UX1NDUklQVD15DQojIENPTkZJR19CSU5GTVRfTUlTQyBpcyBub3Qgc2V0
DQpDT05GSUdfQ09SRURVTVA9eQ0KIyBlbmQgb2YgRXhlY3V0YWJsZSBmaWxl
IGZvcm1hdHMNCg0KIw0KIyBNZW1vcnkgTWFuYWdlbWVudCBvcHRpb25zDQoj
DQpDT05GSUdfU0VMRUNUX01FTU9SWV9NT0RFTD15DQojIENPTkZJR19GTEFU
TUVNX01BTlVBTCBpcyBub3Qgc2V0DQpDT05GSUdfU1BBUlNFTUVNX01BTlVB
TD15DQpDT05GSUdfU1BBUlNFTUVNPXkNCkNPTkZJR19IQVZFX01FTU9SWV9Q
UkVTRU5UPXkNCkNPTkZJR19TUEFSU0VNRU1fRVhUUkVNRT15DQpDT05GSUdf
U1BBUlNFTUVNX1ZNRU1NQVBfRU5BQkxFPXkNCkNPTkZJR19TUEFSU0VNRU1f
Vk1FTU1BUD15DQpDT05GSUdfSEFWRV9GQVNUX0dVUD15DQpDT05GSUdfQVJD
SF9LRUVQX01FTUJMT0NLPXkNCkNPTkZJR19NRU1PUllfSVNPTEFUSU9OPXkN
CiMgQ09ORklHX01FTU9SWV9IT1RQTFVHIGlzIG5vdCBzZXQNCkNPTkZJR19T
UExJVF9QVExPQ0tfQ1BVUz00DQpDT05GSUdfQ09NUEFDVElPTj15DQpDT05G
SUdfTUlHUkFUSU9OPXkNCkNPTkZJR19DT05USUdfQUxMT0M9eQ0KQ09ORklH
X1BIWVNfQUREUl9UXzY0QklUPXkNCkNPTkZJR19CT1VOQ0U9eQ0KQ09ORklH
X01NVV9OT1RJRklFUj15DQojIENPTkZJR19LU00gaXMgbm90IHNldA0KQ09O
RklHX0RFRkFVTFRfTU1BUF9NSU5fQUREUj0zMjc2OA0KQ09ORklHX0FSQ0hf
U1VQUE9SVFNfTUVNT1JZX0ZBSUxVUkU9eQ0KIyBDT05GSUdfTUVNT1JZX0ZB
SUxVUkUgaXMgbm90IHNldA0KIyBDT05GSUdfQ0xFQU5DQUNIRSBpcyBub3Qg
c2V0DQojIENPTkZJR19GUk9OVFNXQVAgaXMgbm90IHNldA0KQ09ORklHX0NN
QT15DQojIENPTkZJR19DTUFfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdf
Q01BX0RFQlVHRlMgaXMgbm90IHNldA0KQ09ORklHX0NNQV9BUkVBUz03DQoj
IENPTkZJR19aUE9PTCBpcyBub3Qgc2V0DQojIENPTkZJR19aQlVEIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1pTTUFMTE9DIGlzIG5vdCBzZXQNCkNPTkZJR19H
RU5FUklDX0VBUkxZX0lPUkVNQVA9eQ0KIyBDT05GSUdfREVGRVJSRURfU1RS
VUNUX1BBR0VfSU5JVCBpcyBub3Qgc2V0DQojIENPTkZJR19JRExFX1BBR0Vf
VFJBQ0tJTkcgaXMgbm90IHNldA0KQ09ORklHX0FSQ0hfSEFTX1BURV9ERVZN
QVA9eQ0KQ09ORklHX0ZSQU1FX1ZFQ1RPUj15DQojIENPTkZJR19QRVJDUFVf
U1RBVFMgaXMgbm90IHNldA0KIyBDT05GSUdfR1VQX0JFTkNITUFSSyBpcyBu
b3Qgc2V0DQpDT05GSUdfQVJDSF9IQVNfUFRFX1NQRUNJQUw9eQ0KIyBlbmQg
b2YgTWVtb3J5IE1hbmFnZW1lbnQgb3B0aW9ucw0KDQpDT05GSUdfTkVUPXkN
CkNPTkZJR19DT01QQVRfTkVUTElOS19NRVNTQUdFUz15DQpDT05GSUdfTkVU
X0lOR1JFU1M9eQ0KQ09ORklHX1NLQl9FWFRFTlNJT05TPXkNCg0KIw0KIyBO
ZXR3b3JraW5nIG9wdGlvbnMNCiMNCkNPTkZJR19QQUNLRVQ9eQ0KIyBDT05G
SUdfUEFDS0VUX0RJQUcgaXMgbm90IHNldA0KQ09ORklHX1VOSVg9eQ0KQ09O
RklHX1VOSVhfU0NNPXkNCiMgQ09ORklHX1VOSVhfRElBRyBpcyBub3Qgc2V0
DQojIENPTkZJR19UTFMgaXMgbm90IHNldA0KQ09ORklHX1hGUk09eQ0KQ09O
RklHX1hGUk1fQUxHTz15DQpDT05GSUdfWEZSTV9VU0VSPXkNCiMgQ09ORklH
X1hGUk1fSU5URVJGQUNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1hGUk1fU1VC
X1BPTElDWSBpcyBub3Qgc2V0DQpDT05GSUdfWEZSTV9NSUdSQVRFPXkNCiMg
Q09ORklHX1hGUk1fU1RBVElTVElDUyBpcyBub3Qgc2V0DQpDT05GSUdfTkVU
X0tFWT15DQpDT05GSUdfTkVUX0tFWV9NSUdSQVRFPXkNCkNPTkZJR19JTkVU
PXkNCkNPTkZJR19JUF9NVUxUSUNBU1Q9eQ0KIyBDT05GSUdfSVBfQURWQU5D
RURfUk9VVEVSIGlzIG5vdCBzZXQNCkNPTkZJR19JUF9QTlA9eQ0KQ09ORklH
X0lQX1BOUF9ESENQPXkNCkNPTkZJR19JUF9QTlBfQk9PVFA9eQ0KQ09ORklH
X0lQX1BOUF9SQVJQPXkNCiMgQ09ORklHX05FVF9JUElQIGlzIG5vdCBzZXQN
CiMgQ09ORklHX05FVF9JUEdSRV9ERU1VWCBpcyBub3Qgc2V0DQpDT05GSUdf
TkVUX0lQX1RVTk5FTD15DQojIENPTkZJR19JUF9NUk9VVEUgaXMgbm90IHNl
dA0KQ09ORklHX1NZTl9DT09LSUVTPXkNCiMgQ09ORklHX05FVF9JUFZUSSBp
cyBub3Qgc2V0DQojIENPTkZJR19ORVRfRk9VIGlzIG5vdCBzZXQNCiMgQ09O
RklHX05FVF9GT1VfSVBfVFVOTkVMUyBpcyBub3Qgc2V0DQojIENPTkZJR19J
TkVUX0FIIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lORVRfRVNQIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0lORVRfSVBDT01QIGlzIG5vdCBzZXQNCkNPTkZJR19J
TkVUX1RVTk5FTD15DQpDT05GSUdfSU5FVF9ESUFHPXkNCkNPTkZJR19JTkVU
X1RDUF9ESUFHPXkNCiMgQ09ORklHX0lORVRfVURQX0RJQUcgaXMgbm90IHNl
dA0KIyBDT05GSUdfSU5FVF9SQVdfRElBRyBpcyBub3Qgc2V0DQojIENPTkZJ
R19JTkVUX0RJQUdfREVTVFJPWSBpcyBub3Qgc2V0DQojIENPTkZJR19UQ1Bf
Q09OR19BRFZBTkNFRCBpcyBub3Qgc2V0DQpDT05GSUdfVENQX0NPTkdfQ1VC
SUM9eQ0KQ09ORklHX0RFRkFVTFRfVENQX0NPTkc9ImN1YmljIg0KIyBDT05G
SUdfVENQX01ENVNJRyBpcyBub3Qgc2V0DQpDT05GSUdfSVBWNj15DQojIENP
TkZJR19JUFY2X1JPVVRFUl9QUkVGIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQ
VjZfT1BUSU1JU1RJQ19EQUQgaXMgbm90IHNldA0KIyBDT05GSUdfSU5FVDZf
QUggaXMgbm90IHNldA0KIyBDT05GSUdfSU5FVDZfRVNQIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0lORVQ2X0lQQ09NUCBpcyBub3Qgc2V0DQojIENPTkZJR19J
UFY2X01JUDYgaXMgbm90IHNldA0KIyBDT05GSUdfSVBWNl9JTEEgaXMgbm90
IHNldA0KIyBDT05GSUdfSVBWNl9WVEkgaXMgbm90IHNldA0KQ09ORklHX0lQ
VjZfU0lUPXkNCiMgQ09ORklHX0lQVjZfU0lUXzZSRCBpcyBub3Qgc2V0DQpD
T05GSUdfSVBWNl9ORElTQ19OT0RFVFlQRT15DQojIENPTkZJR19JUFY2X1RV
Tk5FTCBpcyBub3Qgc2V0DQojIENPTkZJR19JUFY2X01VTFRJUExFX1RBQkxF
UyBpcyBub3Qgc2V0DQojIENPTkZJR19JUFY2X01ST1VURSBpcyBub3Qgc2V0
DQojIENPTkZJR19JUFY2X1NFRzZfTFdUVU5ORUwgaXMgbm90IHNldA0KIyBD
T05GSUdfSVBWNl9TRUc2X0hNQUMgaXMgbm90IHNldA0KIyBDT05GSUdfTVBU
Q1AgaXMgbm90IHNldA0KQ09ORklHX05FVFdPUktfU0VDTUFSSz15DQpDT05G
SUdfTkVUX1BUUF9DTEFTU0lGWT15DQojIENPTkZJR19ORVRXT1JLX1BIWV9U
SU1FU1RBTVBJTkcgaXMgbm90IHNldA0KQ09ORklHX05FVEZJTFRFUj15DQpD
T05GSUdfTkVURklMVEVSX0FEVkFOQ0VEPXkNCkNPTkZJR19CUklER0VfTkVU
RklMVEVSPW0NCg0KIw0KIyBDb3JlIE5ldGZpbHRlciBDb25maWd1cmF0aW9u
DQojDQpDT05GSUdfTkVURklMVEVSX0lOR1JFU1M9eQ0KQ09ORklHX05FVEZJ
TFRFUl9ORVRMSU5LPXkNCkNPTkZJR19ORVRGSUxURVJfRkFNSUxZX0JSSURH
RT15DQojIENPTkZJR19ORVRGSUxURVJfTkVUTElOS19BQ0NUIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFIGlzIG5vdCBz
ZXQNCkNPTkZJR19ORVRGSUxURVJfTkVUTElOS19MT0c9eQ0KIyBDT05GSUdf
TkVURklMVEVSX05FVExJTktfT1NGIGlzIG5vdCBzZXQNCkNPTkZJR19ORl9D
T05OVFJBQ0s9bQ0KQ09ORklHX05GX0xPR19DT01NT049eQ0KIyBDT05GSUdf
TkZfTE9HX05FVERFViBpcyBub3Qgc2V0DQpDT05GSUdfTkZfQ09OTlRSQUNL
X01BUks9eQ0KIyBDT05GSUdfTkZfQ09OTlRSQUNLX1NFQ01BUksgaXMgbm90
IHNldA0KIyBDT05GSUdfTkZfQ09OTlRSQUNLX1pPTkVTIGlzIG5vdCBzZXQN
CkNPTkZJR19ORl9DT05OVFJBQ0tfUFJPQ0ZTPXkNCiMgQ09ORklHX05GX0NP
Tk5UUkFDS19FVkVOVFMgaXMgbm90IHNldA0KIyBDT05GSUdfTkZfQ09OTlRS
QUNLX1RJTUVPVVQgaXMgbm90IHNldA0KIyBDT05GSUdfTkZfQ09OTlRSQUNL
X1RJTUVTVEFNUCBpcyBub3Qgc2V0DQojIENPTkZJR19ORl9DT05OVFJBQ0tf
TEFCRUxTIGlzIG5vdCBzZXQNCkNPTkZJR19ORl9DVF9QUk9UT19EQ0NQPXkN
CkNPTkZJR19ORl9DVF9QUk9UT19TQ1RQPXkNCkNPTkZJR19ORl9DVF9QUk9U
T19VRFBMSVRFPXkNCiMgQ09ORklHX05GX0NPTk5UUkFDS19BTUFOREEgaXMg
bm90IHNldA0KIyBDT05GSUdfTkZfQ09OTlRSQUNLX0ZUUCBpcyBub3Qgc2V0
DQojIENPTkZJR19ORl9DT05OVFJBQ0tfSDMyMyBpcyBub3Qgc2V0DQojIENP
TkZJR19ORl9DT05OVFJBQ0tfSVJDIGlzIG5vdCBzZXQNCiMgQ09ORklHX05G
X0NPTk5UUkFDS19ORVRCSU9TX05TIGlzIG5vdCBzZXQNCiMgQ09ORklHX05G
X0NPTk5UUkFDS19TTk1QIGlzIG5vdCBzZXQNCiMgQ09ORklHX05GX0NPTk5U
UkFDS19QUFRQIGlzIG5vdCBzZXQNCiMgQ09ORklHX05GX0NPTk5UUkFDS19T
QU5FIGlzIG5vdCBzZXQNCiMgQ09ORklHX05GX0NPTk5UUkFDS19TSVAgaXMg
bm90IHNldA0KIyBDT05GSUdfTkZfQ09OTlRSQUNLX1RGVFAgaXMgbm90IHNl
dA0KQ09ORklHX05GX0NUX05FVExJTks9bQ0KIyBDT05GSUdfTkVURklMVEVS
X05FVExJTktfR0xVRV9DVCBpcyBub3Qgc2V0DQojIENPTkZJR19ORl9OQVQg
aXMgbm90IHNldA0KIyBDT05GSUdfTkZfVEFCTEVTIGlzIG5vdCBzZXQNCkNP
TkZJR19ORVRGSUxURVJfWFRBQkxFUz15DQoNCiMNCiMgWHRhYmxlcyBjb21i
aW5lZCBtb2R1bGVzDQojDQpDT05GSUdfTkVURklMVEVSX1hUX01BUks9eQ0K
Q09ORklHX05FVEZJTFRFUl9YVF9DT05OTUFSSz1tDQoNCiMNCiMgWHRhYmxl
cyB0YXJnZXRzDQojDQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0FV
RElUIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NI
RUNLU1VNPXkNCiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ0xBU1NJ
RlkgaXMgbm90IHNldA0KIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9D
T05OTUFSSyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFS
R0VUX0RTQ1AgaXMgbm90IHNldA0KIyBDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9ITCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFS
R0VUX0hNQVJLIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVEZJTFRFUl9YVF9U
QVJHRVRfSURMRVRJTUVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVEZJTFRF
Ul9YVF9UQVJHRVRfTEVEIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRGSUxURVJf
WFRfVEFSR0VUX0xPRz15DQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU
X01BUksgaXMgbm90IHNldA0KIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdF
VF9ORkxPRyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFS
R0VUX05GUVVFVUUgaXMgbm90IHNldA0KIyBDT05GSUdfTkVURklMVEVSX1hU
X1RBUkdFVF9SQVRFRVNUIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVEZJTFRF
Ul9YVF9UQVJHRVRfVEVFIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVEZJTFRF
Ul9YVF9UQVJHRVRfVFBST1hZIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVEZJ
TFRFUl9YVF9UQVJHRVRfU0VDTUFSSyBpcyBub3Qgc2V0DQojIENPTkZJR19O
RVRGSUxURVJfWFRfVEFSR0VUX1RDUE1TUyBpcyBub3Qgc2V0DQojIENPTkZJ
R19ORVRGSUxURVJfWFRfVEFSR0VUX1RDUE9QVFNUUklQIGlzIG5vdCBzZXQN
Cg0KIw0KIyBYdGFibGVzIG1hdGNoZXMNCiMNCiMgQ09ORklHX05FVEZJTFRF
Ul9YVF9NQVRDSF9BRERSVFlQRSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfQlBGIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVEZJ
TFRFUl9YVF9NQVRDSF9DR1JPVVAgaXMgbm90IHNldA0KIyBDT05GSUdfTkVU
RklMVEVSX1hUX01BVENIX0NMVVNURVIgaXMgbm90IHNldA0KIyBDT05GSUdf
TkVURklMVEVSX1hUX01BVENIX0NPTU1FTlQgaXMgbm90IHNldA0KIyBDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5CWVRFUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09OTkxBQkVMIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OTElNSVQgaXMg
bm90IHNldA0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OTUFSSz1t
DQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5UUkFDSz1tDQojIENP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ1BVIGlzIG5vdCBzZXQNCiMgQ09O
RklHX05FVEZJTFRFUl9YVF9NQVRDSF9EQ0NQIGlzIG5vdCBzZXQNCiMgQ09O
RklHX05FVEZJTFRFUl9YVF9NQVRDSF9ERVZHUk9VUCBpcyBub3Qgc2V0DQoj
IENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRFNDUCBpcyBub3Qgc2V0DQoj
IENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRUNOIGlzIG5vdCBzZXQNCiMg
Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9FU1AgaXMgbm90IHNldA0KIyBD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX0hBU0hMSU1JVCBpcyBub3Qgc2V0
DQojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEVMUEVSIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9ITCBpcyBub3Qgc2V0
DQojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSVBDT01QIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9JUFJBTkdFIGlzIG5v
dCBzZXQNCiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9MMlRQIGlzIG5v
dCBzZXQNCiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9MRU5HVEggaXMg
bm90IHNldA0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9MSU1JVD15DQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX01BQz15DQojIENPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfTUFSSyBpcyBub3Qgc2V0DQpDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX01VTFRJUE9SVD15DQojIENPTkZJR19ORVRGSUxURVJf
WFRfTUFUQ0hfTkZBQ0NUIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVEZJTFRF
Ul9YVF9NQVRDSF9PU0YgaXMgbm90IHNldA0KIyBDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX09XTkVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVEZJTFRF
Ul9YVF9NQVRDSF9QT0xJQ1kgaXMgbm90IHNldA0KIyBDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX1BIWVNERVYgaXMgbm90IHNldA0KIyBDT05GSUdfTkVU
RklMVEVSX1hUX01BVENIX1BLVFRZUEUgaXMgbm90IHNldA0KIyBDT05GSUdf
TkVURklMVEVSX1hUX01BVENIX1FVT1RBIGlzIG5vdCBzZXQNCiMgQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9SQVRFRVNUIGlzIG5vdCBzZXQNCiMgQ09O
RklHX05FVEZJTFRFUl9YVF9NQVRDSF9SRUFMTSBpcyBub3Qgc2V0DQojIENP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUkVDRU5UIGlzIG5vdCBzZXQNCiMg
Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TQ1RQIGlzIG5vdCBzZXQNCiMg
Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TT0NLRVQgaXMgbm90IHNldA0K
Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVEFURT1tDQojIENPTkZJR19O
RVRGSUxURVJfWFRfTUFUQ0hfU1RBVElTVElDIGlzIG5vdCBzZXQNCiMgQ09O
RklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVFJJTkcgaXMgbm90IHNldA0KIyBD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX1RDUE1TUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVElNRSBpcyBub3Qgc2V0DQoj
IENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVTMyIGlzIG5vdCBzZXQNCiMg
ZW5kIG9mIENvcmUgTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24NCg0KIyBDT05G
SUdfSVBfU0VUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX1ZTIGlzIG5vdCBz
ZXQNCg0KIw0KIyBJUDogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24NCiMNCkNP
TkZJR19ORl9ERUZSQUdfSVBWND1tDQojIENPTkZJR19ORl9TT0NLRVRfSVBW
NCBpcyBub3Qgc2V0DQojIENPTkZJR19ORl9UUFJPWFlfSVBWNCBpcyBub3Qg
c2V0DQojIENPTkZJR19ORl9EVVBfSVBWNCBpcyBub3Qgc2V0DQojIENPTkZJ
R19ORl9MT0dfQVJQIGlzIG5vdCBzZXQNCkNPTkZJR19ORl9MT0dfSVBWND15
DQpDT05GSUdfTkZfUkVKRUNUX0lQVjQ9eQ0KQ09ORklHX0lQX05GX0lQVEFC
TEVTPXkNCiMgQ09ORklHX0lQX05GX01BVENIX0FIIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0lQX05GX01BVENIX0VDTiBpcyBub3Qgc2V0DQojIENPTkZJR19J
UF9ORl9NQVRDSF9SUEZJTFRFUiBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9O
Rl9NQVRDSF9UVEwgaXMgbm90IHNldA0KQ09ORklHX0lQX05GX0ZJTFRFUj15
DQpDT05GSUdfSVBfTkZfVEFSR0VUX1JFSkVDVD15DQojIENPTkZJR19JUF9O
Rl9UQVJHRVRfU1lOUFJPWFkgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfTkZf
TkFUIGlzIG5vdCBzZXQNCkNPTkZJR19JUF9ORl9NQU5HTEU9eQ0KIyBDT05G
SUdfSVBfTkZfVEFSR0VUX0NMVVNURVJJUCBpcyBub3Qgc2V0DQojIENPTkZJ
R19JUF9ORl9UQVJHRVRfRUNOIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX05G
X1RBUkdFVF9UVEwgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfTkZfUkFXIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0lQX05GX0FSUFRBQkxFUyBpcyBub3Qgc2V0
DQojIGVuZCBvZiBJUDogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24NCg0KIw0K
IyBJUHY2OiBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbg0KIw0KIyBDT05GSUdf
TkZfU09DS0VUX0lQVjYgaXMgbm90IHNldA0KIyBDT05GSUdfTkZfVFBST1hZ
X0lQVjYgaXMgbm90IHNldA0KIyBDT05GSUdfTkZfRFVQX0lQVjYgaXMgbm90
IHNldA0KQ09ORklHX05GX1JFSkVDVF9JUFY2PXkNCkNPTkZJR19ORl9MT0df
SVBWNj15DQpDT05GSUdfSVA2X05GX0lQVEFCTEVTPXkNCiMgQ09ORklHX0lQ
Nl9ORl9NQVRDSF9BSCBpcyBub3Qgc2V0DQojIENPTkZJR19JUDZfTkZfTUFU
Q0hfRVVJNjQgaXMgbm90IHNldA0KIyBDT05GSUdfSVA2X05GX01BVENIX0ZS
QUcgaXMgbm90IHNldA0KIyBDT05GSUdfSVA2X05GX01BVENIX09QVFMgaXMg
bm90IHNldA0KIyBDT05GSUdfSVA2X05GX01BVENIX0hMIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0lQNl9ORl9NQVRDSF9JUFY2SEVBREVSIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0lQNl9ORl9NQVRDSF9NSCBpcyBub3Qgc2V0DQojIENPTkZJ
R19JUDZfTkZfTUFUQ0hfUlBGSUxURVIgaXMgbm90IHNldA0KIyBDT05GSUdf
SVA2X05GX01BVENIX1JUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQNl9ORl9N
QVRDSF9TUkggaXMgbm90IHNldA0KIyBDT05GSUdfSVA2X05GX1RBUkdFVF9I
TCBpcyBub3Qgc2V0DQpDT05GSUdfSVA2X05GX0ZJTFRFUj15DQpDT05GSUdf
SVA2X05GX1RBUkdFVF9SRUpFQ1Q9eQ0KIyBDT05GSUdfSVA2X05GX1RBUkdF
VF9TWU5QUk9YWSBpcyBub3Qgc2V0DQpDT05GSUdfSVA2X05GX01BTkdMRT15
DQojIENPTkZJR19JUDZfTkZfUkFXIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQ
Nl9ORl9OQVQgaXMgbm90IHNldA0KIyBlbmQgb2YgSVB2NjogTmV0ZmlsdGVy
IENvbmZpZ3VyYXRpb24NCg0KQ09ORklHX05GX0RFRlJBR19JUFY2PW0NCiMg
Q09ORklHX05GX0NPTk5UUkFDS19CUklER0UgaXMgbm90IHNldA0KQ09ORklH
X0JSSURHRV9ORl9FQlRBQkxFUz15DQojIENPTkZJR19CUklER0VfRUJUX0JS
T1VURSBpcyBub3Qgc2V0DQpDT05GSUdfQlJJREdFX0VCVF9UX0ZJTFRFUj15
DQpDT05GSUdfQlJJREdFX0VCVF9UX05BVD15DQojIENPTkZJR19CUklER0Vf
RUJUXzgwMl8zIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JSSURHRV9FQlRfQU1P
TkcgaXMgbm90IHNldA0KIyBDT05GSUdfQlJJREdFX0VCVF9BUlAgaXMgbm90
IHNldA0KIyBDT05GSUdfQlJJREdFX0VCVF9JUCBpcyBub3Qgc2V0DQojIENP
TkZJR19CUklER0VfRUJUX0lQNiBpcyBub3Qgc2V0DQojIENPTkZJR19CUklE
R0VfRUJUX0xJTUlUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JSSURHRV9FQlRf
TUFSSyBpcyBub3Qgc2V0DQojIENPTkZJR19CUklER0VfRUJUX1BLVFRZUEUg
aXMgbm90IHNldA0KIyBDT05GSUdfQlJJREdFX0VCVF9TVFAgaXMgbm90IHNl
dA0KIyBDT05GSUdfQlJJREdFX0VCVF9WTEFOIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0JSSURHRV9FQlRfQVJQUkVQTFkgaXMgbm90IHNldA0KIyBDT05GSUdf
QlJJREdFX0VCVF9ETkFUIGlzIG5vdCBzZXQNCkNPTkZJR19CUklER0VfRUJU
X01BUktfVD15DQojIENPTkZJR19CUklER0VfRUJUX1JFRElSRUNUIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0JSSURHRV9FQlRfU05BVCBpcyBub3Qgc2V0DQoj
IENPTkZJR19CUklER0VfRUJUX0xPRyBpcyBub3Qgc2V0DQojIENPTkZJR19C
UklER0VfRUJUX05GTE9HIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JQRklMVEVS
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX0RDQ1AgaXMgbm90IHNldA0KIyBD
T05GSUdfSVBfU0NUUCBpcyBub3Qgc2V0DQojIENPTkZJR19SRFMgaXMgbm90
IHNldA0KIyBDT05GSUdfVElQQyBpcyBub3Qgc2V0DQojIENPTkZJR19BVE0g
aXMgbm90IHNldA0KIyBDT05GSUdfTDJUUCBpcyBub3Qgc2V0DQpDT05GSUdf
U1RQPXkNCkNPTkZJR19CUklER0U9eQ0KQ09ORklHX0JSSURHRV9JR01QX1NO
T09QSU5HPXkNCkNPTkZJR19IQVZFX05FVF9EU0E9eQ0KIyBDT05GSUdfTkVU
X0RTQSBpcyBub3Qgc2V0DQojIENPTkZJR19WTEFOXzgwMjFRIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0RFQ05FVCBpcyBub3Qgc2V0DQpDT05GSUdfTExDPXkN
CiMgQ09ORklHX0xMQzIgaXMgbm90IHNldA0KIyBDT05GSUdfQVRBTEsgaXMg
bm90IHNldA0KIyBDT05GSUdfWDI1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0xB
UEIgaXMgbm90IHNldA0KIyBDT05GSUdfUEhPTkVUIGlzIG5vdCBzZXQNCiMg
Q09ORklHXzZMT1dQQU4gaXMgbm90IHNldA0KIyBDT05GSUdfSUVFRTgwMjE1
NCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfU0NIRUQgaXMgbm90IHNldA0K
IyBDT05GSUdfRENCIGlzIG5vdCBzZXQNCkNPTkZJR19ETlNfUkVTT0xWRVI9
eQ0KIyBDT05GSUdfQkFUTUFOX0FEViBpcyBub3Qgc2V0DQojIENPTkZJR19P
UEVOVlNXSVRDSCBpcyBub3Qgc2V0DQojIENPTkZJR19WU09DS0VUUyBpcyBu
b3Qgc2V0DQojIENPTkZJR19ORVRMSU5LX0RJQUcgaXMgbm90IHNldA0KIyBD
T05GSUdfTVBMUyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfTlNIIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0hTUiBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRf
U1dJVENIREVWIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9MM19NQVNURVJf
REVWIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9OQ1NJIGlzIG5vdCBzZXQN
CkNPTkZJR19SUFM9eQ0KQ09ORklHX1JGU19BQ0NFTD15DQpDT05GSUdfWFBT
PXkNCiMgQ09ORklHX0NHUk9VUF9ORVRfUFJJTyBpcyBub3Qgc2V0DQojIENP
TkZJR19DR1JPVVBfTkVUX0NMQVNTSUQgaXMgbm90IHNldA0KQ09ORklHX0JR
TD15DQojIENPTkZJR19CUEZfSklUIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRf
RkxPV19MSU1JVD15DQoNCiMNCiMgTmV0d29yayB0ZXN0aW5nDQojDQpDT05G
SUdfTkVUX1BLVEdFTj15DQojIGVuZCBvZiBOZXR3b3JrIHRlc3RpbmcNCiMg
ZW5kIG9mIE5ldHdvcmtpbmcgb3B0aW9ucw0KDQojIENPTkZJR19IQU1SQURJ
TyBpcyBub3Qgc2V0DQpDT05GSUdfQ0FOPXkNCkNPTkZJR19DQU5fUkFXPXkN
CkNPTkZJR19DQU5fQkNNPXkNCkNPTkZJR19DQU5fR1c9eQ0KIyBDT05GSUdf
Q0FOX0oxOTM5IGlzIG5vdCBzZXQNCg0KIw0KIyBDQU4gRGV2aWNlIERyaXZl
cnMNCiMNCiMgQ09ORklHX0NBTl9WQ0FOIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0NBTl9WWENBTiBpcyBub3Qgc2V0DQojIENPTkZJR19DQU5fU0xDQU4gaXMg
bm90IHNldA0KQ09ORklHX0NBTl9ERVY9eQ0KQ09ORklHX0NBTl9DQUxDX0JJ
VFRJTUlORz15DQojIENPTkZJR19DQU5fRkxFWENBTiBpcyBub3Qgc2V0DQoj
IENPTkZJR19DQU5fR1JDQU4gaXMgbm90IHNldA0KQ09ORklHX0NBTl9YSUxJ
TlhDQU49eQ0KIyBDT05GSUdfQ0FOX0NfQ0FOIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0NBTl9DQzc3MCBpcyBub3Qgc2V0DQojIENPTkZJR19DQU5fSUZJX0NB
TkZEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NBTl9NX0NBTiBpcyBub3Qgc2V0
DQojIENPTkZJR19DQU5fU0pBMTAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19D
QU5fU09GVElORyBpcyBub3Qgc2V0DQoNCiMNCiMgQ0FOIFNQSSBpbnRlcmZh
Y2VzDQojDQojIENPTkZJR19DQU5fSEkzMTFYIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0NBTl9NQ1AyNTFYIGlzIG5vdCBzZXQNCiMgZW5kIG9mIENBTiBTUEkg
aW50ZXJmYWNlcw0KDQojDQojIENBTiBVU0IgaW50ZXJmYWNlcw0KIw0KIyBD
T05GSUdfQ0FOXzhERVZfVVNCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NBTl9F
TVNfVVNCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NBTl9FU0RfVVNCMiBpcyBu
b3Qgc2V0DQojIENPTkZJR19DQU5fR1NfVVNCIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0NBTl9LVkFTRVJfVVNCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NBTl9N
Q0JBX1VTQiBpcyBub3Qgc2V0DQojIENPTkZJR19DQU5fUEVBS19VU0IgaXMg
bm90IHNldA0KIyBDT05GSUdfQ0FOX1VDQU4gaXMgbm90IHNldA0KIyBlbmQg
b2YgQ0FOIFVTQiBpbnRlcmZhY2VzDQoNCiMgQ09ORklHX0NBTl9ERUJVR19E
RVZJQ0VTIGlzIG5vdCBzZXQNCiMgZW5kIG9mIENBTiBEZXZpY2UgRHJpdmVy
cw0KDQpDT05GSUdfQlQ9eQ0KQ09ORklHX0JUX0JSRURSPXkNCkNPTkZJR19C
VF9SRkNPTU09eQ0KQ09ORklHX0JUX1JGQ09NTV9UVFk9eQ0KQ09ORklHX0JU
X0JORVA9eQ0KQ09ORklHX0JUX0JORVBfTUNfRklMVEVSPXkNCkNPTkZJR19C
VF9CTkVQX1BST1RPX0ZJTFRFUj15DQpDT05GSUdfQlRfSElEUD15DQpDT05G
SUdfQlRfSFM9eQ0KQ09ORklHX0JUX0xFPXkNCkNPTkZJR19CVF9MRURTPXkN
CiMgQ09ORklHX0JUX1NFTEZURVNUIGlzIG5vdCBzZXQNCkNPTkZJR19CVF9E
RUJVR0ZTPXkNCg0KIw0KIyBCbHVldG9vdGggZGV2aWNlIGRyaXZlcnMNCiMN
CkNPTkZJR19CVF9JTlRFTD15DQpDT05GSUdfQlRfQkNNPXkNCkNPTkZJR19C
VF9SVEw9eQ0KQ09ORklHX0JUX1FDQT15DQpDT05GSUdfQlRfSENJQlRVU0I9
eQ0KIyBDT05GSUdfQlRfSENJQlRVU0JfQVVUT1NVU1BFTkQgaXMgbm90IHNl
dA0KQ09ORklHX0JUX0hDSUJUVVNCX0JDTT15DQojIENPTkZJR19CVF9IQ0lC
VFVTQl9NVEsgaXMgbm90IHNldA0KQ09ORklHX0JUX0hDSUJUVVNCX1JUTD15
DQpDT05GSUdfQlRfSENJQlRTRElPPXkNCkNPTkZJR19CVF9IQ0lVQVJUPXkN
CkNPTkZJR19CVF9IQ0lVQVJUX1NFUkRFVj15DQpDT05GSUdfQlRfSENJVUFS
VF9IND15DQojIENPTkZJR19CVF9IQ0lVQVJUX05PS0lBIGlzIG5vdCBzZXQN
CkNPTkZJR19CVF9IQ0lVQVJUX0JDU1A9eQ0KQ09ORklHX0JUX0hDSVVBUlRf
QVRIM0s9eQ0KQ09ORklHX0JUX0hDSVVBUlRfTEw9eQ0KQ09ORklHX0JUX0hD
SVVBUlRfM1dJUkU9eQ0KQ09ORklHX0JUX0hDSVVBUlRfSU5URUw9eQ0KIyBD
T05GSUdfQlRfSENJVUFSVF9CQ00gaXMgbm90IHNldA0KQ09ORklHX0JUX0hD
SVVBUlRfUUNBPXkNCiMgQ09ORklHX0JUX0hDSVVBUlRfQUc2WFggaXMgbm90
IHNldA0KIyBDT05GSUdfQlRfSENJVUFSVF9NUlZMIGlzIG5vdCBzZXQNCkNP
TkZJR19CVF9IQ0lCQ00yMDNYPXkNCkNPTkZJR19CVF9IQ0lCUEExMFg9eQ0K
Q09ORklHX0JUX0hDSUJGVVNCPXkNCkNPTkZJR19CVF9IQ0lWSENJPXkNCkNP
TkZJR19CVF9NUlZMPXkNCkNPTkZJR19CVF9NUlZMX1NESU89eQ0KQ09ORklH
X0JUX0FUSDNLPXkNCiMgQ09ORklHX0JUX01US1NESU8gaXMgbm90IHNldA0K
IyBDT05GSUdfQlRfTVRLVUFSVCBpcyBub3Qgc2V0DQojIGVuZCBvZiBCbHVl
dG9vdGggZGV2aWNlIGRyaXZlcnMNCg0KIyBDT05GSUdfQUZfUlhSUEMgaXMg
bm90IHNldA0KIyBDT05GSUdfQUZfS0NNIGlzIG5vdCBzZXQNCkNPTkZJR19X
SVJFTEVTUz15DQpDT05GSUdfV0VYVF9DT1JFPXkNCkNPTkZJR19XRVhUX1BS
T0M9eQ0KQ09ORklHX0NGRzgwMjExPXkNCkNPTkZJR19OTDgwMjExX1RFU1RN
T0RFPXkNCiMgQ09ORklHX0NGRzgwMjExX0RFVkVMT1BFUl9XQVJOSU5HUyBp
cyBub3Qgc2V0DQpDT05GSUdfQ0ZHODAyMTFfQ0VSVElGSUNBVElPTl9PTlVT
PXkNCkNPTkZJR19DRkc4MDIxMV9SRVFVSVJFX1NJR05FRF9SRUdEQj15DQpD
T05GSUdfQ0ZHODAyMTFfVVNFX0tFUk5FTF9SRUdEQl9LRVlTPXkNCkNPTkZJ
R19DRkc4MDIxMV9FWFRSQV9SRUdEQl9LRVlESVI9IiINCkNPTkZJR19DRkc4
MDIxMV9SRUdfQ0VMTFVMQVJfSElOVFM9eQ0KQ09ORklHX0NGRzgwMjExX1JF
R19SRUxBWF9OT19JUj15DQpDT05GSUdfQ0ZHODAyMTFfREVGQVVMVF9QUz15
DQojIENPTkZJR19DRkc4MDIxMV9ERUJVR0ZTIGlzIG5vdCBzZXQNCkNPTkZJ
R19DRkc4MDIxMV9DUkRBX1NVUFBPUlQ9eQ0KQ09ORklHX0NGRzgwMjExX1dF
WFQ9eQ0KQ09ORklHX01BQzgwMjExPXkNCkNPTkZJR19NQUM4MDIxMV9IQVNf
UkM9eQ0KQ09ORklHX01BQzgwMjExX1JDX01JTlNUUkVMPXkNCkNPTkZJR19N
QUM4MDIxMV9SQ19ERUZBVUxUX01JTlNUUkVMPXkNCkNPTkZJR19NQUM4MDIx
MV9SQ19ERUZBVUxUPSJtaW5zdHJlbF9odCINCiMgQ09ORklHX01BQzgwMjEx
X01FU0ggaXMgbm90IHNldA0KQ09ORklHX01BQzgwMjExX0xFRFM9eQ0KIyBD
T05GSUdfTUFDODAyMTFfREVCVUdGUyBpcyBub3Qgc2V0DQpDT05GSUdfTUFD
ODAyMTFfTUVTU0FHRV9UUkFDSU5HPXkNCkNPTkZJR19NQUM4MDIxMV9ERUJV
R19NRU5VPXkNCiMgQ09ORklHX01BQzgwMjExX05PSU5MSU5FIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX01BQzgwMjExX1ZFUkJPU0VfREVCVUcgaXMgbm90IHNl
dA0KIyBDT05GSUdfTUFDODAyMTFfTUxNRV9ERUJVRyBpcyBub3Qgc2V0DQoj
IENPTkZJR19NQUM4MDIxMV9TVEFfREVCVUcgaXMgbm90IHNldA0KIyBDT05G
SUdfTUFDODAyMTFfSFRfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfTUFD
ODAyMTFfT0NCX0RFQlVHIGlzIG5vdCBzZXQNCiMgQ09ORklHX01BQzgwMjEx
X0lCU1NfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfTUFDODAyMTFfUFNf
REVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfTUFDODAyMTFfVERMU19ERUJV
RyBpcyBub3Qgc2V0DQpDT05GSUdfTUFDODAyMTFfU1RBX0hBU0hfTUFYX1NJ
WkU9MA0KIyBDT05GSUdfV0lNQVggaXMgbm90IHNldA0KQ09ORklHX1JGS0lM
TD15DQpDT05GSUdfUkZLSUxMX0xFRFM9eQ0KQ09ORklHX1JGS0lMTF9JTlBV
VD15DQpDT05GSUdfUkZLSUxMX0dQSU89eQ0KQ09ORklHX05FVF85UD15DQoj
IENPTkZJR19ORVRfOVBfVklSVElPIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRf
OVBfWEVOPXkNCiMgQ09ORklHX05FVF85UF9ERUJVRyBpcyBub3Qgc2V0DQoj
IENPTkZJR19DQUlGIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NFUEhfTElCIGlz
IG5vdCBzZXQNCiMgQ09ORklHX05GQyBpcyBub3Qgc2V0DQojIENPTkZJR19Q
U0FNUExFIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9JRkUgaXMgbm90IHNl
dA0KIyBDT05GSUdfTFdUVU5ORUwgaXMgbm90IHNldA0KQ09ORklHX0RTVF9D
QUNIRT15DQpDT05GSUdfR1JPX0NFTExTPXkNCiMgQ09ORklHX0ZBSUxPVkVS
IGlzIG5vdCBzZXQNCkNPTkZJR19FVEhUT09MX05FVExJTks9eQ0KQ09ORklH
X0hBVkVfRUJQRl9KSVQ9eQ0KDQojDQojIERldmljZSBEcml2ZXJzDQojDQpD
T05GSUdfQVJNX0FNQkE9eQ0KQ09ORklHX0hBVkVfUENJPXkNCiMgQ09ORklH
X1BDSSBpcyBub3Qgc2V0DQojIENPTkZJR19QQ0NBUkQgaXMgbm90IHNldA0K
DQojDQojIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMNCiMNCkNPTkZJR19VRVZF
TlRfSEVMUEVSPXkNCkNPTkZJR19VRVZFTlRfSEVMUEVSX1BBVEg9Ii9zYmlu
L2hvdHBsdWciDQpDT05GSUdfREVWVE1QRlM9eQ0KQ09ORklHX0RFVlRNUEZT
X01PVU5UPXkNCkNPTkZJR19TVEFOREFMT05FPXkNCkNPTkZJR19QUkVWRU5U
X0ZJUk1XQVJFX0JVSUxEPXkNCg0KIw0KIyBGaXJtd2FyZSBsb2FkZXINCiMN
CkNPTkZJR19GV19MT0FERVI9eQ0KQ09ORklHX0VYVFJBX0ZJUk1XQVJFPSIi
DQojIENPTkZJR19GV19MT0FERVJfVVNFUl9IRUxQRVIgaXMgbm90IHNldA0K
IyBDT05GSUdfRldfTE9BREVSX0NPTVBSRVNTIGlzIG5vdCBzZXQNCkNPTkZJ
R19GV19DQUNIRT15DQojIGVuZCBvZiBGaXJtd2FyZSBsb2FkZXINCg0KQ09O
RklHX1dBTlRfREVWX0NPUkVEVU1QPXkNCkNPTkZJR19BTExPV19ERVZfQ09S
RURVTVA9eQ0KQ09ORklHX0RFVl9DT1JFRFVNUD15DQojIENPTkZJR19ERUJV
R19EUklWRVIgaXMgbm90IHNldA0KIyBDT05GSUdfREVCVUdfREVWUkVTIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0RFQlVHX1RFU1RfRFJJVkVSX1JFTU9WRSBp
cyBub3Qgc2V0DQojIENPTkZJR19URVNUX0FTWU5DX0RSSVZFUl9QUk9CRSBp
cyBub3Qgc2V0DQpDT05GSUdfU1lTX0hZUEVSVklTT1I9eQ0KQ09ORklHX0dF
TkVSSUNfQ1BVX0FVVE9QUk9CRT15DQpDT05GSUdfR0VORVJJQ19DUFVfVlVM
TkVSQUJJTElUSUVTPXkNCkNPTkZJR19SRUdNQVA9eQ0KQ09ORklHX1JFR01B
UF9JMkM9eQ0KQ09ORklHX1JFR01BUF9TUEk9eQ0KQ09ORklHX1JFR01BUF9J
UlE9eQ0KQ09ORklHX0RNQV9TSEFSRURfQlVGRkVSPXkNCiMgQ09ORklHX0RN
QV9GRU5DRV9UUkFDRSBpcyBub3Qgc2V0DQpDT05GSUdfR0VORVJJQ19BUkNI
X1RPUE9MT0dZPXkNCiMgZW5kIG9mIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMN
Cg0KIw0KIyBCdXMgZGV2aWNlcw0KIw0KIyBDT05GSUdfQlJDTVNUQl9HSVNC
X0FSQiBpcyBub3Qgc2V0DQojIENPTkZJR19NT1hURVQgaXMgbm90IHNldA0K
IyBDT05GSUdfU0lNUExFX1BNX0JVUyBpcyBub3Qgc2V0DQojIENPTkZJR19W
RVhQUkVTU19DT05GSUcgaXMgbm90IHNldA0KIyBlbmQgb2YgQnVzIGRldmlj
ZXMNCg0KQ09ORklHX0NPTk5FQ1RPUj15DQpDT05GSUdfUFJPQ19FVkVOVFM9
eQ0KIyBDT05GSUdfR05TUyBpcyBub3Qgc2V0DQpDT05GSUdfTVREPXkNCkNP
TkZJR19NVERfVEVTVFM9bQ0KDQojDQojIFBhcnRpdGlvbiBwYXJzZXJzDQoj
DQojIENPTkZJR19NVERfQVI3X1BBUlRTIGlzIG5vdCBzZXQNCkNPTkZJR19N
VERfQ01ETElORV9QQVJUUz15DQpDT05GSUdfTVREX09GX1BBUlRTPXkNCiMg
Q09ORklHX01URF9BRlNfUEFSVFMgaXMgbm90IHNldA0KIyBDT05GSUdfTVRE
X1JFREJPT1RfUEFSVFMgaXMgbm90IHNldA0KIyBlbmQgb2YgUGFydGl0aW9u
IHBhcnNlcnMNCg0KIw0KIyBVc2VyIE1vZHVsZXMgQW5kIFRyYW5zbGF0aW9u
IExheWVycw0KIw0KQ09ORklHX01URF9CTEtERVZTPXkNCkNPTkZJR19NVERf
QkxPQ0s9eQ0KIyBDT05GSUdfRlRMIGlzIG5vdCBzZXQNCiMgQ09ORklHX05G
VEwgaXMgbm90IHNldA0KIyBDT05GSUdfSU5GVEwgaXMgbm90IHNldA0KIyBD
T05GSUdfUkZEX0ZUTCBpcyBub3Qgc2V0DQojIENPTkZJR19TU0ZEQyBpcyBu
b3Qgc2V0DQojIENPTkZJR19TTV9GVEwgaXMgbm90IHNldA0KQ09ORklHX01U
RF9PT1BTPXkNCiMgQ09ORklHX01URF9TV0FQIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01URF9QQVJUSVRJT05FRF9NQVNURVIgaXMgbm90IHNldA0KDQojDQoj
IFJBTS9ST00vRmxhc2ggY2hpcCBkcml2ZXJzDQojDQpDT05GSUdfTVREX0NG
ST15DQojIENPTkZJR19NVERfSkVERUNQUk9CRSBpcyBub3Qgc2V0DQpDT05G
SUdfTVREX0dFTl9QUk9CRT15DQojIENPTkZJR19NVERfQ0ZJX0FEVl9PUFRJ
T05TIGlzIG5vdCBzZXQNCkNPTkZJR19NVERfTUFQX0JBTktfV0lEVEhfMT15
DQpDT05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzI9eQ0KQ09ORklHX01URF9N
QVBfQkFOS19XSURUSF80PXkNCkNPTkZJR19NVERfQ0ZJX0kxPXkNCkNPTkZJ
R19NVERfQ0ZJX0kyPXkNCkNPTkZJR19NVERfQ0ZJX0lOVEVMRVhUPXkNCiMg
Q09ORklHX01URF9DRklfQU1EU1REIGlzIG5vdCBzZXQNCiMgQ09ORklHX01U
RF9DRklfU1RBQSBpcyBub3Qgc2V0DQpDT05GSUdfTVREX0NGSV9VVElMPXkN
CiMgQ09ORklHX01URF9SQU0gaXMgbm90IHNldA0KIyBDT05GSUdfTVREX1JP
TSBpcyBub3Qgc2V0DQojIENPTkZJR19NVERfQUJTRU5UIGlzIG5vdCBzZXQN
CiMgZW5kIG9mIFJBTS9ST00vRmxhc2ggY2hpcCBkcml2ZXJzDQoNCiMNCiMg
TWFwcGluZyBkcml2ZXJzIGZvciBjaGlwIGFjY2Vzcw0KIw0KIyBDT05GSUdf
TVREX0NPTVBMRVhfTUFQUElOR1MgaXMgbm90IHNldA0KIyBDT05GSUdfTVRE
X1BIWVNNQVAgaXMgbm90IHNldA0KIyBDT05GSUdfTVREX1BMQVRSQU0gaXMg
bm90IHNldA0KIyBlbmQgb2YgTWFwcGluZyBkcml2ZXJzIGZvciBjaGlwIGFj
Y2Vzcw0KDQojDQojIFNlbGYtY29udGFpbmVkIE1URCBkZXZpY2UgZHJpdmVy
cw0KIw0KQ09ORklHX01URF9EQVRBRkxBU0g9eQ0KIyBDT05GSUdfTVREX0RB
VEFGTEFTSF9XUklURV9WRVJJRlkgaXMgbm90IHNldA0KIyBDT05GSUdfTVRE
X0RBVEFGTEFTSF9PVFAgaXMgbm90IHNldA0KIyBDT05GSUdfTVREX01DSFAy
M0syNTYgaXMgbm90IHNldA0KIyBDT05GSUdfTVREX1NTVDI1TCBpcyBub3Qg
c2V0DQojIENPTkZJR19NVERfU0xSQU0gaXMgbm90IHNldA0KIyBDT05GSUdf
TVREX1BIUkFNIGlzIG5vdCBzZXQNCiMgQ09ORklHX01URF9NVERSQU0gaXMg
bm90IHNldA0KIyBDT05GSUdfTVREX0JMT0NLMk1URCBpcyBub3Qgc2V0DQoN
CiMNCiMgRGlzay1Pbi1DaGlwIERldmljZSBEcml2ZXJzDQojDQojIENPTkZJ
R19NVERfRE9DRzMgaXMgbm90IHNldA0KIyBlbmQgb2YgU2VsZi1jb250YWlu
ZWQgTVREIGRldmljZSBkcml2ZXJzDQoNCiMgQ09ORklHX01URF9PTkVOQU5E
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01URF9SQVdfTkFORCBpcyBub3Qgc2V0
DQojIENPTkZJR19NVERfU1BJX05BTkQgaXMgbm90IHNldA0KDQojDQojIExQ
RERSICYgTFBERFIyIFBDTSBtZW1vcnkgZHJpdmVycw0KIw0KIyBDT05GSUdf
TVREX0xQRERSIGlzIG5vdCBzZXQNCiMgZW5kIG9mIExQRERSICYgTFBERFIy
IFBDTSBtZW1vcnkgZHJpdmVycw0KDQpDT05GSUdfTVREX1NQSV9OT1I9eQ0K
Q09ORklHX01URF9TUElfTk9SX1VTRV80S19TRUNUT1JTPXkNCiMgQ09ORklH
X1NQSV9DQURFTkNFX1FVQURTUEkgaXMgbm90IHNldA0KIyBDT05GSUdfU1BJ
X01US19RVUFEU1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX01URF9VQkkgaXMg
bm90IHNldA0KIyBDT05GSUdfTVREX0hZUEVSQlVTIGlzIG5vdCBzZXQNCkNP
TkZJR19EVEM9eQ0KQ09ORklHX09GPXkNCiMgQ09ORklHX09GX1VOSVRURVNU
IGlzIG5vdCBzZXQNCkNPTkZJR19PRl9GTEFUVFJFRT15DQpDT05GSUdfT0Zf
RUFSTFlfRkxBVFRSRUU9eQ0KQ09ORklHX09GX0tPQko9eQ0KQ09ORklHX09G
X0RZTkFNSUM9eQ0KQ09ORklHX09GX0FERFJFU1M9eQ0KQ09ORklHX09GX0lS
UT15DQpDT05GSUdfT0ZfTkVUPXkNCkNPTkZJR19PRl9NRElPPXkNCkNPTkZJ
R19PRl9SRVNFUlZFRF9NRU09eQ0KQ09ORklHX09GX1JFU09MVkU9eQ0KQ09O
RklHX09GX09WRVJMQVk9eQ0KIyBDT05GSUdfUEFSUE9SVCBpcyBub3Qgc2V0
DQpDT05GSUdfQkxLX0RFVj15DQojIENPTkZJR19CTEtfREVWX05VTExfQkxL
IGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0xPT1A9eQ0KQ09ORklHX0JM
S19ERVZfTE9PUF9NSU5fQ09VTlQ9OA0KIyBDT05GSUdfQkxLX0RFVl9DUllQ
VE9MT09QIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfRFJCRCBpcyBu
b3Qgc2V0DQojIENPTkZJR19CTEtfREVWX05CRCBpcyBub3Qgc2V0DQpDT05G
SUdfQkxLX0RFVl9SQU09eQ0KQ09ORklHX0JMS19ERVZfUkFNX0NPVU5UPTE2
DQpDT05GSUdfQkxLX0RFVl9SQU1fU0laRT02NTUzNg0KIyBDT05GSUdfQ0RS
T01fUEtUQ0RWRCBpcyBub3Qgc2V0DQojIENPTkZJR19BVEFfT1ZFUl9FVEgg
aXMgbm90IHNldA0KQ09ORklHX1hFTl9CTEtERVZfRlJPTlRFTkQ9eQ0KQ09O
RklHX1hFTl9CTEtERVZfQkFDS0VORD15DQojIENPTkZJR19WSVJUSU9fQkxL
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUkJEIGlzIG5vdCBzZXQN
Cg0KIw0KIyBOVk1FIFN1cHBvcnQNCiMNCiMgQ09ORklHX05WTUVfRkMgaXMg
bm90IHNldA0KIyBDT05GSUdfTlZNRV9UQVJHRVQgaXMgbm90IHNldA0KIyBl
bmQgb2YgTlZNRSBTdXBwb3J0DQoNCiMNCiMgTWlzYyBkZXZpY2VzDQojDQoj
IENPTkZJR19BRDUyNVhfRFBPVCBpcyBub3Qgc2V0DQojIENPTkZJR19EVU1N
WV9JUlEgaXMgbm90IHNldA0KIyBDT05GSUdfSUNTOTMyUzQwMSBpcyBub3Qg
c2V0DQojIENPTkZJR19FTkNMT1NVUkVfU0VSVklDRVMgaXMgbm90IHNldA0K
IyBDT05GSUdfQVBEUzk4MDJBTFMgaXMgbm90IHNldA0KIyBDT05GSUdfSVNM
MjkwMDMgaXMgbm90IHNldA0KIyBDT05GSUdfSVNMMjkwMjAgaXMgbm90IHNl
dA0KIyBDT05GSUdfU0VOU09SU19UU0wyNTUwIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NFTlNPUlNfQkgxNzcwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP
UlNfQVBEUzk5MFggaXMgbm90IHNldA0KIyBDT05GSUdfSE1DNjM1MiBpcyBu
b3Qgc2V0DQojIENPTkZJR19EUzE2ODIgaXMgbm90IHNldA0KIyBDT05GSUdf
TEFUVElDRV9FQ1AzX0NPTkZJRyBpcyBub3Qgc2V0DQpDT05GSUdfU1JBTT15
DQpDT05GSUdfWElMSU5YX1NERkVDPXkNCiMgQ09ORklHX1BWUEFOSUMgaXMg
bm90IHNldA0KIyBDT05GSUdfQzJQT1JUIGlzIG5vdCBzZXQNCg0KIw0KIyBF
RVBST00gc3VwcG9ydA0KIw0KQ09ORklHX0VFUFJPTV9BVDI0PXkNCkNPTkZJ
R19FRVBST01fQVQyNT15DQojIENPTkZJR19FRVBST01fTEVHQUNZIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0VFUFJPTV9NQVg2ODc1IGlzIG5vdCBzZXQNCiMg
Q09ORklHX0VFUFJPTV85M0NYNiBpcyBub3Qgc2V0DQojIENPTkZJR19FRVBS
T01fOTNYWDQ2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0VFUFJPTV9JRFRfODlI
UEVTWCBpcyBub3Qgc2V0DQojIENPTkZJR19FRVBST01fRUUxMDA0IGlzIG5v
dCBzZXQNCiMgZW5kIG9mIEVFUFJPTSBzdXBwb3J0DQoNCiMNCiMgVGV4YXMg
SW5zdHJ1bWVudHMgc2hhcmVkIHRyYW5zcG9ydCBsaW5lIGRpc2NpcGxpbmUN
CiMNCkNPTkZJR19USV9TVD15DQojIGVuZCBvZiBUZXhhcyBJbnN0cnVtZW50
cyBzaGFyZWQgdHJhbnNwb3J0IGxpbmUgZGlzY2lwbGluZQ0KDQojIENPTkZJ
R19TRU5TT1JTX0xJUzNfU1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP
UlNfTElTM19JMkMgaXMgbm90IHNldA0KIyBDT05GSUdfQUxURVJBX1NUQVBM
IGlzIG5vdCBzZXQNCg0KIw0KIyBJbnRlbCBNSUMgJiByZWxhdGVkIHN1cHBv
cnQNCiMNCiMgQ09ORklHX1ZPUF9CVVMgaXMgbm90IHNldA0KIyBlbmQgb2Yg
SW50ZWwgTUlDICYgcmVsYXRlZCBzdXBwb3J0DQoNCiMgQ09ORklHX0VDSE8g
aXMgbm90IHNldA0KIyBDT05GSUdfTUlTQ19SVFNYX1VTQiBpcyBub3Qgc2V0
DQojIGVuZCBvZiBNaXNjIGRldmljZXMNCg0KIw0KIyBTQ1NJIGRldmljZSBz
dXBwb3J0DQojDQpDT05GSUdfU0NTSV9NT0Q9eQ0KIyBDT05GSUdfUkFJRF9B
VFRSUyBpcyBub3Qgc2V0DQpDT05GSUdfU0NTST15DQpDT05GSUdfU0NTSV9E
TUE9eQ0KQ09ORklHX1NDU0lfUFJPQ19GUz15DQoNCiMNCiMgU0NTSSBzdXBw
b3J0IHR5cGUgKGRpc2ssIHRhcGUsIENELVJPTSkNCiMNCkNPTkZJR19CTEtf
REVWX1NEPXkNCiMgQ09ORklHX0NIUl9ERVZfU1QgaXMgbm90IHNldA0KIyBD
T05GSUdfQkxLX0RFVl9TUiBpcyBub3Qgc2V0DQojIENPTkZJR19DSFJfREVW
X1NHIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NIUl9ERVZfU0NIIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NDU0lfQ09OU1RBTlRTIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NDU0lfTE9HR0lORyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1ND
QU5fQVNZTkMgaXMgbm90IHNldA0KDQojDQojIFNDU0kgVHJhbnNwb3J0cw0K
Iw0KIyBDT05GSUdfU0NTSV9TUElfQVRUUlMgaXMgbm90IHNldA0KIyBDT05G
SUdfU0NTSV9GQ19BVFRSUyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0lT
Q1NJX0FUVFJTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfU0FTX0FUVFJT
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfU0FTX0xJQlNBUyBpcyBub3Qg
c2V0DQojIENPTkZJR19TQ1NJX1NSUF9BVFRSUyBpcyBub3Qgc2V0DQojIGVu
ZCBvZiBTQ1NJIFRyYW5zcG9ydHMNCg0KQ09ORklHX1NDU0lfTE9XTEVWRUw9
eQ0KIyBDT05GSUdfSVNDU0lfVENQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lT
Q1NJX0JPT1RfU1lTRlMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9ISVNJ
X1NBUyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1VGU0hDRCBpcyBub3Qg
c2V0DQpDT05GSUdfWEVOX1NDU0lfRlJPTlRFTkQ9eQ0KIyBDT05GSUdfU0NT
SV9ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1ZJUlRJTyBpcyBu
b3Qgc2V0DQojIENPTkZJR19TQ1NJX0RIIGlzIG5vdCBzZXQNCiMgZW5kIG9m
IFNDU0kgZGV2aWNlIHN1cHBvcnQNCg0KQ09ORklHX0hBVkVfUEFUQV9QTEFU
Rk9STT15DQpDT05GSUdfQVRBPXkNCkNPTkZJR19BVEFfVkVSQk9TRV9FUlJP
Uj15DQpDT05GSUdfU0FUQV9QTVA9eQ0KDQojDQojIENvbnRyb2xsZXJzIHdp
dGggbm9uLVNGRiBuYXRpdmUgaW50ZXJmYWNlDQojDQpDT05GSUdfU0FUQV9B
SENJX1BMQVRGT1JNPXkNCkNPTkZJR19BSENJX0NFVkE9eQ0KIyBDT05GSUdf
QUhDSV9RT1JJUSBpcyBub3Qgc2V0DQojIENPTkZJR19BVEFfU0ZGIGlzIG5v
dCBzZXQNCiMgQ09ORklHX01EIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RBUkdF
VF9DT1JFIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRERVZJQ0VTPXkNCkNPTkZJ
R19NSUk9eQ0KQ09ORklHX05FVF9DT1JFPXkNCiMgQ09ORklHX0JPTkRJTkcg
aXMgbm90IHNldA0KIyBDT05GSUdfRFVNTVkgaXMgbm90IHNldA0KIyBDT05G
SUdfV0lSRUdVQVJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VRVUFMSVpFUiBp
cyBub3Qgc2V0DQojIENPTkZJR19ORVRfVEVBTSBpcyBub3Qgc2V0DQojIENP
TkZJR19NQUNWTEFOIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQVkxBTiBpcyBu
b3Qgc2V0DQojIENPTkZJR19WWExBTiBpcyBub3Qgc2V0DQojIENPTkZJR19H
RU5FVkUgaXMgbm90IHNldA0KIyBDT05GSUdfR1RQIGlzIG5vdCBzZXQNCiMg
Q09ORklHX01BQ1NFQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRDT05TT0xF
IGlzIG5vdCBzZXQNCkNPTkZJR19UVU49eQ0KIyBDT05GSUdfVFVOX1ZORVRf
Q1JPU1NfTEUgaXMgbm90IHNldA0KIyBDT05GSUdfVkVUSCBpcyBub3Qgc2V0
DQojIENPTkZJR19WSVJUSU9fTkVUIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
TU9OIGlzIG5vdCBzZXQNCg0KIw0KIyBEaXN0cmlidXRlZCBTd2l0Y2ggQXJj
aGl0ZWN0dXJlIGRyaXZlcnMNCiMNCiMgZW5kIG9mIERpc3RyaWJ1dGVkIFN3
aXRjaCBBcmNoaXRlY3R1cmUgZHJpdmVycw0KDQpDT05GSUdfRVRIRVJORVQ9
eQ0KQ09ORklHX05FVF9WRU5ET1JfQUxBQ1JJVEVDSD15DQojIENPTkZJR19B
TFRFUkFfVFNFIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfVkVORE9SX0FNQVpP
Tj15DQpDT05GSUdfTkVUX1ZFTkRPUl9BTUQ9eQ0KIyBDT05GSUdfQU1EX1hH
QkUgaXMgbm90IHNldA0KQ09ORklHX05FVF9WRU5ET1JfQVFVQU5USUE9eQ0K
Q09ORklHX05FVF9WRU5ET1JfQVJDPXkNCkNPTkZJR19ORVRfVkVORE9SX0FV
Uk9SQT15DQojIENPTkZJR19BVVJPUkFfTkI4ODAwIGlzIG5vdCBzZXQNCkNP
TkZJR19ORVRfVkVORE9SX0JST0FEQ09NPXkNCiMgQ09ORklHX0I0NCBpcyBu
b3Qgc2V0DQojIENPTkZJR19CQ01HRU5FVCBpcyBub3Qgc2V0DQojIENPTkZJ
R19TWVNURU1QT1JUIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfVkVORE9SX0NB
REVOQ0U9eQ0KQ09ORklHX01BQ0I9eQ0KQ09ORklHX01BQ0JfVVNFX0hXU1RB
TVA9eQ0KQ09ORklHX05FVF9WRU5ET1JfQ0FWSVVNPXkNCkNPTkZJR19ORVRf
VkVORE9SX0NPUlRJTkE9eQ0KIyBDT05GSUdfR0VNSU5JX0VUSEVSTkVUIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0RORVQgaXMgbm90IHNldA0KQ09ORklHX05F
VF9WRU5ET1JfRVpDSElQPXkNCiMgQ09ORklHX0VaQ0hJUF9OUFNfTUFOQUdF
TUVOVF9FTkVUIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfVkVORE9SX0dPT0dM
RT15DQpDT05GSUdfTkVUX1ZFTkRPUl9ISVNJTElDT049eQ0KIyBDT05GSUdf
SElYNUhEMl9HTUFDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJU0lfRkVNQUMg
aXMgbm90IHNldA0KIyBDT05GSUdfSElQMDRfRVRIIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0hOUyBpcyBub3Qgc2V0DQojIENPTkZJR19ITlNfRFNBRiBpcyBu
b3Qgc2V0DQojIENPTkZJR19ITlNfRU5FVCBpcyBub3Qgc2V0DQpDT05GSUdf
TkVUX1ZFTkRPUl9IVUFXRUk9eQ0KQ09ORklHX05FVF9WRU5ET1JfSTgyNVhY
PXkNCkNPTkZJR19ORVRfVkVORE9SX0lOVEVMPXkNCkNPTkZJR19ORVRfVkVO
RE9SX01BUlZFTEw9eQ0KIyBDT05GSUdfTVZNRElPIGlzIG5vdCBzZXQNCkNP
TkZJR19ORVRfVkVORE9SX01FTExBTk9YPXkNCiMgQ09ORklHX01MWFNXX0NP
UkUgaXMgbm90IHNldA0KIyBDT05GSUdfTUxYRlcgaXMgbm90IHNldA0KQ09O
RklHX05FVF9WRU5ET1JfTUlDUkVMPXkNCiMgQ09ORklHX0tTODg0MiBpcyBu
b3Qgc2V0DQojIENPTkZJR19LUzg4NTEgaXMgbm90IHNldA0KIyBDT05GSUdf
S1M4ODUxX01MTCBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX1ZFTkRPUl9NSUNS
T0NISVA9eQ0KIyBDT05GSUdfRU5DMjhKNjAgaXMgbm90IHNldA0KIyBDT05G
SUdfRU5DWDI0SjYwMCBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX1ZFTkRPUl9N
SUNST1NFTUk9eQ0KQ09ORklHX05FVF9WRU5ET1JfTkFUU0VNST15DQpDT05G
SUdfTkVUX1ZFTkRPUl9ORVRST05PTUU9eQ0KQ09ORklHX05FVF9WRU5ET1Jf
Tkk9eQ0KIyBDT05GSUdfTklfWEdFX01BTkFHRU1FTlRfRU5FVCBpcyBub3Qg
c2V0DQpDT05GSUdfTkVUX1ZFTkRPUl84MzkwPXkNCiMgQ09ORklHX0VUSE9D
IGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfVkVORE9SX1BFTlNBTkRPPXkNCkNP
TkZJR19ORVRfVkVORE9SX1FVQUxDT01NPXkNCiMgQ09ORklHX1FDQTcwMDBf
U1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1FDQTcwMDBfVUFSVCBpcyBub3Qg
c2V0DQojIENPTkZJR19RQ09NX0VNQUMgaXMgbm90IHNldA0KIyBDT05GSUdf
Uk1ORVQgaXMgbm90IHNldA0KQ09ORklHX05FVF9WRU5ET1JfUkVORVNBUz15
DQpDT05GSUdfTkVUX1ZFTkRPUl9ST0NLRVI9eQ0KQ09ORklHX05FVF9WRU5E
T1JfU0FNU1VORz15DQojIENPTkZJR19TWEdCRV9FVEggaXMgbm90IHNldA0K
Q09ORklHX05FVF9WRU5ET1JfU0VFUT15DQpDT05GSUdfTkVUX1ZFTkRPUl9T
T0xBUkZMQVJFPXkNCkNPTkZJR19ORVRfVkVORE9SX1NNU0M9eQ0KIyBDT05G
SUdfU01DOTFYIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NNU0M5MTFYIGlzIG5v
dCBzZXQNCkNPTkZJR19ORVRfVkVORE9SX1NPQ0lPTkVYVD15DQpDT05GSUdf
TkVUX1ZFTkRPUl9TVE1JQ1JPPXkNCiMgQ09ORklHX1NUTU1BQ19FVEggaXMg
bm90IHNldA0KQ09ORklHX05FVF9WRU5ET1JfU1lOT1BTWVM9eQ0KIyBDT05G
SUdfRFdDX1hMR01BQyBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX1ZFTkRPUl9W
SUE9eQ0KIyBDT05GSUdfVklBX1JISU5FIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1ZJQV9WRUxPQ0lUWSBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX1ZFTkRPUl9X
SVpORVQ9eQ0KIyBDT05GSUdfV0laTkVUX1c1MTAwIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1dJWk5FVF9XNTMwMCBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX1ZF
TkRPUl9YSUxJTlg9eQ0KQ09ORklHX1hJTElOWF9BWElfRU1BQz15DQpDT05G
SUdfTURJT19ERVZJQ0U9eQ0KQ09ORklHX01ESU9fQlVTPXkNCiMgQ09ORklH
X01ESU9fQkNNX1VOSU1BQyBpcyBub3Qgc2V0DQojIENPTkZJR19NRElPX0JJ
VEJBTkcgaXMgbm90IHNldA0KIyBDT05GSUdfTURJT19CVVNfTVVYX0dQSU8g
aXMgbm90IHNldA0KIyBDT05GSUdfTURJT19CVVNfTVVYX01NSU9SRUcgaXMg
bm90IHNldA0KIyBDT05GSUdfTURJT19CVVNfTVVYX01VTFRJUExFWEVSIGlz
IG5vdCBzZXQNCiMgQ09ORklHX01ESU9fSElTSV9GRU1BQyBpcyBub3Qgc2V0
DQojIENPTkZJR19NRElPX01TQ0NfTUlJTSBpcyBub3Qgc2V0DQojIENPTkZJ
R19NRElPX09DVEVPTiBpcyBub3Qgc2V0DQpDT05GSUdfUEhZTElOSz15DQpD
T05GSUdfUEhZTElCPXkNCkNPTkZJR19TV1BIWT15DQojIENPTkZJR19MRURf
VFJJR0dFUl9QSFkgaXMgbm90IHNldA0KDQojDQojIE1JSSBQSFkgZGV2aWNl
IGRyaXZlcnMNCiMNCiMgQ09ORklHX1NGUCBpcyBub3Qgc2V0DQojIENPTkZJ
R19BRElOX1BIWSBpcyBub3Qgc2V0DQpDT05GSUdfQU1EX1BIWT15DQojIENP
TkZJR19BUVVBTlRJQV9QSFkgaXMgbm90IHNldA0KIyBDT05GSUdfQVg4ODc5
NkJfUEhZIGlzIG5vdCBzZXQNCkNPTkZJR19CQ003WFhYX1BIWT15DQpDT05G
SUdfQkNNODdYWF9QSFk9eQ0KQ09ORklHX0JDTV9ORVRfUEhZTElCPXkNCkNP
TkZJR19CUk9BRENPTV9QSFk9eQ0KIyBDT05GSUdfQkNNODQ4ODFfUEhZIGlz
IG5vdCBzZXQNCkNPTkZJR19DSUNBREFfUEhZPXkNCiMgQ09ORklHX0NPUlRJ
TkFfUEhZIGlzIG5vdCBzZXQNCkNPTkZJR19EQVZJQ09NX1BIWT15DQojIENP
TkZJR19EUDgzODIyX1BIWSBpcyBub3Qgc2V0DQojIENPTkZJR19EUDgzVEM4
MTFfUEhZIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RQODM4NDhfUEhZIGlzIG5v
dCBzZXQNCkNPTkZJR19EUDgzODY3X1BIWT15DQojIENPTkZJR19EUDgzODY5
X1BIWSBpcyBub3Qgc2V0DQpDT05GSUdfRklYRURfUEhZPXkNCkNPTkZJR19J
Q1BMVVNfUEhZPXkNCiMgQ09ORklHX0lOVEVMX1hXQVlfUEhZIGlzIG5vdCBz
ZXQNCkNPTkZJR19MU0lfRVQxMDExQ19QSFk9eQ0KQ09ORklHX0xYVF9QSFk9
eQ0KQ09ORklHX01BUlZFTExfUEhZPXkNCiMgQ09ORklHX01BUlZFTExfMTBH
X1BIWSBpcyBub3Qgc2V0DQpDT05GSUdfTUlDUkVMX1BIWT15DQojIENPTkZJ
R19NSUNST0NISVBfUEhZIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JQ1JPQ0hJ
UF9UMV9QSFkgaXMgbm90IHNldA0KIyBDT05GSUdfTUlDUk9TRU1JX1BIWSBp
cyBub3Qgc2V0DQpDT05GSUdfTkFUSU9OQUxfUEhZPXkNCiMgQ09ORklHX05Y
UF9USkExMVhYX1BIWSBpcyBub3Qgc2V0DQpDT05GSUdfQVQ4MDNYX1BIWT15
DQpDT05GSUdfUVNFTUlfUEhZPXkNCkNPTkZJR19SRUFMVEVLX1BIWT15DQoj
IENPTkZJR19SRU5FU0FTX1BIWSBpcyBub3Qgc2V0DQojIENPTkZJR19ST0NL
Q0hJUF9QSFkgaXMgbm90IHNldA0KQ09ORklHX1NNU0NfUEhZPXkNCkNPTkZJ
R19TVEUxMFhQPXkNCiMgQ09ORklHX1RFUkFORVRJQ1NfUEhZIGlzIG5vdCBz
ZXQNCkNPTkZJR19WSVRFU1NFX1BIWT15DQpDT05GSUdfWElMSU5YX0dNSUky
UkdNSUk9eQ0KIyBDT05GSUdfTUlDUkVMX0tTODk5NU1BIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0DQojIENPTkZJR19TTElQIGlzIG5v
dCBzZXQNCkNPTkZJR19VU0JfTkVUX0RSSVZFUlM9eQ0KIyBDT05GSUdfVVNC
X0NBVEMgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0tBV0VUSCBpcyBub3Qg
c2V0DQojIENPTkZJR19VU0JfUEVHQVNVUyBpcyBub3Qgc2V0DQojIENPTkZJ
R19VU0JfUlRMODE1MCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfUlRMODE1
MiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfTEFONzhYWCBpcyBub3Qgc2V0
DQpDT05GSUdfVVNCX1VTQk5FVD15DQpDT05GSUdfVVNCX05FVF9BWDg4MTdY
PXkNCkNPTkZJR19VU0JfTkVUX0FYODgxNzlfMTc4QT15DQpDT05GSUdfVVNC
X05FVF9DRENFVEhFUj15DQojIENPTkZJR19VU0JfTkVUX0NEQ19FRU0gaXMg
bm90IHNldA0KQ09ORklHX1VTQl9ORVRfQ0RDX05DTT15DQojIENPTkZJR19V
U0JfTkVUX0hVQVdFSV9DRENfTkNNIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT
Ql9ORVRfQ0RDX01CSU0gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX05FVF9E
TTk2MDEgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX05FVF9TUjk3MDAgaXMg
bm90IHNldA0KIyBDT05GSUdfVVNCX05FVF9TUjk4MDAgaXMgbm90IHNldA0K
IyBDT05GSUdfVVNCX05FVF9TTVNDNzVYWCBpcyBub3Qgc2V0DQojIENPTkZJ
R19VU0JfTkVUX1NNU0M5NVhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9O
RVRfR0w2MjBBIGlzIG5vdCBzZXQNCkNPTkZJR19VU0JfTkVUX05FVDEwODA9
eQ0KIyBDT05GSUdfVVNCX05FVF9QTFVTQiBpcyBub3Qgc2V0DQojIENPTkZJ
R19VU0JfTkVUX01DUzc4MzAgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX05F
VF9STkRJU19IT1NUIGlzIG5vdCBzZXQNCkNPTkZJR19VU0JfTkVUX0NEQ19T
VUJTRVRfRU5BQkxFPXkNCkNPTkZJR19VU0JfTkVUX0NEQ19TVUJTRVQ9eQ0K
IyBDT05GSUdfVVNCX0FMSV9NNTYzMiBpcyBub3Qgc2V0DQojIENPTkZJR19V
U0JfQU4yNzIwIGlzIG5vdCBzZXQNCkNPTkZJR19VU0JfQkVMS0lOPXkNCkNP
TkZJR19VU0JfQVJNTElOVVg9eQ0KIyBDT05GSUdfVVNCX0VQU09OMjg4OCBp
cyBub3Qgc2V0DQojIENPTkZJR19VU0JfS0MyMTkwIGlzIG5vdCBzZXQNCkNP
TkZJR19VU0JfTkVUX1pBVVJVUz15DQojIENPTkZJR19VU0JfTkVUX0NYODIz
MTBfRVRIIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9ORVRfS0FMTUlBIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9ORVRfUU1JX1dXQU4gaXMgbm90IHNl
dA0KIyBDT05GSUdfVVNCX0hTTyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf
TkVUX0lOVDUxWDEgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0lQSEVUSCBp
cyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0lFUlJBX05FVCBpcyBub3Qgc2V0
DQojIENPTkZJR19VU0JfVkw2MDAgaXMgbm90IHNldA0KIyBDT05GSUdfVVNC
X05FVF9DSDkyMDAgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX05FVF9BUUMx
MTEgaXMgbm90IHNldA0KQ09ORklHX1dMQU49eQ0KIyBDT05GSUdfV0lSRUxF
U1NfV0RTIGlzIG5vdCBzZXQNCkNPTkZJR19XTEFOX1ZFTkRPUl9BRE1URUs9
eQ0KQ09ORklHX1dMQU5fVkVORE9SX0FUSD15DQojIENPTkZJR19BVEhfREVC
VUcgaXMgbm90IHNldA0KIyBDT05GSUdfQVRIX1JFR19EWU5BTUlDX1VTRVJf
UkVHX0hJTlRTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUSDlLIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0FUSDlLX0hUQyBpcyBub3Qgc2V0DQojIENPTkZJR19D
QVJMOTE3MCBpcyBub3Qgc2V0DQojIENPTkZJR19BVEg2S0wgaXMgbm90IHNl
dA0KIyBDT05GSUdfQVI1NTIzIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUSDEw
SyBpcyBub3Qgc2V0DQojIENPTkZJR19XQ04zNlhYIGlzIG5vdCBzZXQNCkNP
TkZJR19XTEFOX1ZFTkRPUl9BVE1FTD15DQojIENPTkZJR19BVDc2QzUwWF9V
U0IgaXMgbm90IHNldA0KQ09ORklHX1dMQU5fVkVORE9SX0JST0FEQ09NPXkN
CiMgQ09ORklHX0I0MyBpcyBub3Qgc2V0DQojIENPTkZJR19CNDNMRUdBQ1kg
aXMgbm90IHNldA0KIyBDT05GSUdfQlJDTVNNQUMgaXMgbm90IHNldA0KIyBD
T05GSUdfQlJDTUZNQUMgaXMgbm90IHNldA0KQ09ORklHX1dMQU5fVkVORE9S
X0NJU0NPPXkNCkNPTkZJR19XTEFOX1ZFTkRPUl9JTlRFTD15DQpDT05GSUdf
V0xBTl9WRU5ET1JfSU5URVJTSUw9eQ0KIyBDT05GSUdfSE9TVEFQIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1A1NF9DT01NT04gaXMgbm90IHNldA0KQ09ORklH
X1dMQU5fVkVORE9SX01BUlZFTEw9eQ0KIyBDT05GSUdfTElCRVJUQVMgaXMg
bm90IHNldA0KIyBDT05GSUdfTElCRVJUQVNfVEhJTkZJUk0gaXMgbm90IHNl
dA0KIyBDT05GSUdfTVdJRklFWCBpcyBub3Qgc2V0DQpDT05GSUdfV0xBTl9W
RU5ET1JfTUVESUFURUs9eQ0KIyBDT05GSUdfTVQ3NjAxVSBpcyBub3Qgc2V0
DQojIENPTkZJR19NVDc2eDBVIGlzIG5vdCBzZXQNCiMgQ09ORklHX01UNzZ4
MlUgaXMgbm90IHNldA0KQ09ORklHX1dMQU5fVkVORE9SX1JBTElOSz15DQoj
IENPTkZJR19SVDJYMDAgaXMgbm90IHNldA0KQ09ORklHX1dMQU5fVkVORE9S
X1JFQUxURUs9eQ0KIyBDT05GSUdfUlRMODE4NyBpcyBub3Qgc2V0DQpDT05G
SUdfUlRMX0NBUkRTPXkNCiMgQ09ORklHX1JUTDgxOTJDVSBpcyBub3Qgc2V0
DQojIENPTkZJR19SVEw4WFhYVSBpcyBub3Qgc2V0DQojIENPTkZJR19SVFc4
OCBpcyBub3Qgc2V0DQpDT05GSUdfV0xBTl9WRU5ET1JfUlNJPXkNCiMgQ09O
RklHX1JTSV85MVggaXMgbm90IHNldA0KQ09ORklHX1dMQU5fVkVORE9SX1NU
PXkNCiMgQ09ORklHX0NXMTIwMCBpcyBub3Qgc2V0DQpDT05GSUdfV0xBTl9W
RU5ET1JfVEk9eQ0KIyBDT05GSUdfV0wxMjUxIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1dMMTJYWCBpcyBub3Qgc2V0DQpDT05GSUdfV0wxOFhYPXkNCkNPTkZJ
R19XTENPUkU9eQ0KQ09ORklHX1dMQ09SRV9TUEk9eQ0KQ09ORklHX1dMQ09S
RV9TRElPPXkNCkNPTkZJR19XSUxJTktfUExBVEZPUk1fREFUQT15DQpDT05G
SUdfV0xBTl9WRU5ET1JfWllEQVM9eQ0KIyBDT05GSUdfVVNCX1pEMTIwMSBp
cyBub3Qgc2V0DQojIENPTkZJR19aRDEyMTFSVyBpcyBub3Qgc2V0DQpDT05G
SUdfV0xBTl9WRU5ET1JfUVVBTlRFTk5BPXkNCiMgQ09ORklHX01BQzgwMjEx
X0hXU0lNIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9ORVRfUk5ESVNfV0xB
TiBpcyBub3Qgc2V0DQojIENPTkZJR19WSVJUX1dJRkkgaXMgbm90IHNldA0K
DQojDQojIEVuYWJsZSBXaU1BWCAoTmV0d29ya2luZyBvcHRpb25zKSB0byBz
ZWUgdGhlIFdpTUFYIGRyaXZlcnMNCiMNCiMgQ09ORklHX1dBTiBpcyBub3Qg
c2V0DQpDT05GSUdfWEVOX05FVERFVl9GUk9OVEVORD15DQpDT05GSUdfWEVO
X05FVERFVl9CQUNLRU5EPXkNCiMgQ09ORklHX05FVERFVlNJTSBpcyBub3Qg
c2V0DQojIENPTkZJR19ORVRfRkFJTE9WRVIgaXMgbm90IHNldA0KIyBDT05G
SUdfSVNETiBpcyBub3Qgc2V0DQojIENPTkZJR19OVk0gaXMgbm90IHNldA0K
DQojDQojIElucHV0IGRldmljZSBzdXBwb3J0DQojDQpDT05GSUdfSU5QVVQ9
eQ0KQ09ORklHX0lOUFVUX0xFRFM9eQ0KIyBDT05GSUdfSU5QVVRfRkZfTUVN
TEVTUyBpcyBub3Qgc2V0DQpDT05GSUdfSU5QVVRfUE9MTERFVj15DQojIENP
TkZJR19JTlBVVF9TUEFSU0VLTUFQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lO
UFVUX01BVFJJWEtNQVAgaXMgbm90IHNldA0KDQojDQojIFVzZXJsYW5kIGlu
dGVyZmFjZXMNCiMNCiMgQ09ORklHX0lOUFVUX01PVVNFREVWIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0DQpDT05GSUdf
SU5QVVRfRVZERVY9eQ0KIyBDT05GSUdfSU5QVVRfRVZCVUcgaXMgbm90IHNl
dA0KDQojDQojIElucHV0IERldmljZSBEcml2ZXJzDQojDQpDT05GSUdfSU5Q
VVRfS0VZQk9BUkQ9eQ0KIyBDT05GSUdfS0VZQk9BUkRfQURDIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1ODggaXMgbm90IHNldA0KIyBD
T05GSUdfS0VZQk9BUkRfQURQNTU4OSBpcyBub3Qgc2V0DQpDT05GSUdfS0VZ
Qk9BUkRfQVRLQkQ9eQ0KIyBDT05GSUdfS0VZQk9BUkRfUVQxMDUwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0tFWUJPQVJEX1FUMTA3MCBpcyBub3Qgc2V0DQoj
IENPTkZJR19LRVlCT0FSRF9RVDIxNjAgaXMgbm90IHNldA0KIyBDT05GSUdf
S0VZQk9BUkRfRExJTktfRElSNjg1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0tF
WUJPQVJEX0xLS0JEIGlzIG5vdCBzZXQNCkNPTkZJR19LRVlCT0FSRF9HUElP
PXkNCkNPTkZJR19LRVlCT0FSRF9HUElPX1BPTExFRD15DQojIENPTkZJR19L
RVlCT0FSRF9UQ0E2NDE2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0tFWUJPQVJE
X1RDQTg0MTggaXMgbm90IHNldA0KIyBDT05GSUdfS0VZQk9BUkRfTUFUUklY
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0tFWUJPQVJEX0xNODMyMyBpcyBub3Qg
c2V0DQojIENPTkZJR19LRVlCT0FSRF9MTTgzMzMgaXMgbm90IHNldA0KIyBD
T05GSUdfS0VZQk9BUkRfTUFYNzM1OSBpcyBub3Qgc2V0DQojIENPTkZJR19L
RVlCT0FSRF9NQ1MgaXMgbm90IHNldA0KIyBDT05GSUdfS0VZQk9BUkRfTVBS
MTIxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0tFWUJPQVJEX05FV1RPTiBpcyBu
b3Qgc2V0DQojIENPTkZJR19LRVlCT0FSRF9PUEVOQ09SRVMgaXMgbm90IHNl
dA0KIyBDT05GSUdfS0VZQk9BUkRfU0FNU1VORyBpcyBub3Qgc2V0DQojIENP
TkZJR19LRVlCT0FSRF9TVE9XQVdBWSBpcyBub3Qgc2V0DQojIENPTkZJR19L
RVlCT0FSRF9TVU5LQkQgaXMgbm90IHNldA0KIyBDT05GSUdfS0VZQk9BUkRf
T01BUDQgaXMgbm90IHNldA0KIyBDT05GSUdfS0VZQk9BUkRfVE0yX1RPVUNI
S0VZIGlzIG5vdCBzZXQNCiMgQ09ORklHX0tFWUJPQVJEX1hUS0JEIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0tFWUJPQVJEX0NBUDExWFggaXMgbm90IHNldA0K
IyBDT05GSUdfS0VZQk9BUkRfQkNNIGlzIG5vdCBzZXQNCkNPTkZJR19JTlBV
VF9NT1VTRT15DQpDT05GSUdfTU9VU0VfUFMyPXkNCkNPTkZJR19NT1VTRV9Q
UzJfQUxQUz15DQpDT05GSUdfTU9VU0VfUFMyX0JZRD15DQpDT05GSUdfTU9V
U0VfUFMyX0xPR0lQUzJQUD15DQpDT05GSUdfTU9VU0VfUFMyX1NZTkFQVElD
Uz15DQpDT05GSUdfTU9VU0VfUFMyX1NZTkFQVElDU19TTUJVUz15DQpDT05G
SUdfTU9VU0VfUFMyX0NZUFJFU1M9eQ0KQ09ORklHX01PVVNFX1BTMl9UUkFD
S1BPSU5UPXkNCiMgQ09ORklHX01PVVNFX1BTMl9FTEFOVEVDSCBpcyBub3Qg
c2V0DQojIENPTkZJR19NT1VTRV9QUzJfU0VOVEVMSUMgaXMgbm90IHNldA0K
IyBDT05GSUdfTU9VU0VfUFMyX1RPVUNIS0lUIGlzIG5vdCBzZXQNCkNPTkZJ
R19NT1VTRV9QUzJfRk9DQUxURUNIPXkNCkNPTkZJR19NT1VTRV9QUzJfU01C
VVM9eQ0KIyBDT05GSUdfTU9VU0VfU0VSSUFMIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01PVVNFX0FQUExFVE9VQ0ggaXMgbm90IHNldA0KIyBDT05GSUdfTU9V
U0VfQkNNNTk3NCBpcyBub3Qgc2V0DQojIENPTkZJR19NT1VTRV9DWUFQQSBp
cyBub3Qgc2V0DQojIENPTkZJR19NT1VTRV9FTEFOX0kyQyBpcyBub3Qgc2V0
DQojIENPTkZJR19NT1VTRV9WU1hYWEFBIGlzIG5vdCBzZXQNCiMgQ09ORklH
X01PVVNFX0dQSU8gaXMgbm90IHNldA0KIyBDT05GSUdfTU9VU0VfU1lOQVBU
SUNTX0kyQyBpcyBub3Qgc2V0DQojIENPTkZJR19NT1VTRV9TWU5BUFRJQ1Nf
VVNCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX0pPWVNUSUNLIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0lOUFVUX1RBQkxFVCBpcyBub3Qgc2V0DQojIENP
TkZJR19JTlBVVF9UT1VDSFNDUkVFTiBpcyBub3Qgc2V0DQojIENPTkZJR19J
TlBVVF9NSVNDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JNSTRfQ09SRSBpcyBu
b3Qgc2V0DQoNCiMNCiMgSGFyZHdhcmUgSS9PIHBvcnRzDQojDQpDT05GSUdf
U0VSSU89eQ0KQ09ORklHX1NFUklPX1NFUlBPUlQ9eQ0KIyBDT05GSUdfU0VS
SU9fQU1CQUtNSSBpcyBub3Qgc2V0DQpDT05GSUdfU0VSSU9fTElCUFMyPXkN
CiMgQ09ORklHX1NFUklPX1JBVyBpcyBub3Qgc2V0DQojIENPTkZJR19TRVJJ
T19BTFRFUkFfUFMyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklPX1BTMk1V
TFQgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSU9fQVJDX1BTMiBpcyBub3Qg
c2V0DQojIENPTkZJR19TRVJJT19BUEJQUzIgaXMgbm90IHNldA0KIyBDT05G
SUdfU0VSSU9fR1BJT19QUzIgaXMgbm90IHNldA0KIyBDT05GSUdfVVNFUklP
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0dBTUVQT1JUIGlzIG5vdCBzZXQNCiMg
ZW5kIG9mIEhhcmR3YXJlIEkvTyBwb3J0cw0KIyBlbmQgb2YgSW5wdXQgZGV2
aWNlIHN1cHBvcnQNCg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0KIw0KQ09O
RklHX1RUWT15DQpDT05GSUdfVlQ9eQ0KQ09ORklHX0NPTlNPTEVfVFJBTlNM
QVRJT05TPXkNCkNPTkZJR19WVF9DT05TT0xFPXkNCkNPTkZJR19WVF9DT05T
T0xFX1NMRUVQPXkNCkNPTkZJR19IV19DT05TT0xFPXkNCkNPTkZJR19WVF9I
V19DT05TT0xFX0JJTkRJTkc9eQ0KQ09ORklHX1VOSVg5OF9QVFlTPXkNCkNP
TkZJR19MRUdBQ1lfUFRZUz15DQpDT05GSUdfTEVHQUNZX1BUWV9DT1VOVD0y
NTYNCiMgQ09ORklHX1NFUklBTF9OT05TVEFOREFSRCBpcyBub3Qgc2V0DQoj
IENPTkZJR19OX0dTTSBpcyBub3Qgc2V0DQojIENPTkZJR19UUkFDRV9TSU5L
IGlzIG5vdCBzZXQNCiMgQ09ORklHX05VTExfVFRZIGlzIG5vdCBzZXQNCkNP
TkZJR19MRElTQ19BVVRPTE9BRD15DQpDT05GSUdfREVWTUVNPXkNCg0KIw0K
IyBTZXJpYWwgZHJpdmVycw0KIw0KQ09ORklHX1NFUklBTF9FQVJMWUNPTj15
DQpDT05GSUdfU0VSSUFMXzgyNTA9eQ0KQ09ORklHX1NFUklBTF84MjUwX0RF
UFJFQ0FURURfT1BUSU9OUz15DQojIENPTkZJR19TRVJJQUxfODI1MF8xNjU1
MEFfVkFSSUFOVFMgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSUFMXzgyNTBf
RklOVEVLIGlzIG5vdCBzZXQNCkNPTkZJR19TRVJJQUxfODI1MF9DT05TT0xF
PXkNCkNPTkZJR19TRVJJQUxfODI1MF9ETUE9eQ0KQ09ORklHX1NFUklBTF84
MjUwX05SX1VBUlRTPTQNCkNPTkZJR19TRVJJQUxfODI1MF9SVU5USU1FX1VB
UlRTPTQNCiMgQ09ORklHX1NFUklBTF84MjUwX0VYVEVOREVEIGlzIG5vdCBz
ZXQNCkNPTkZJR19TRVJJQUxfODI1MF9GU0w9eQ0KIyBDT05GSUdfU0VSSUFM
XzgyNTBfRFcgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSUFMXzgyNTBfUlQy
ODhYIGlzIG5vdCBzZXQNCkNPTkZJR19TRVJJQUxfT0ZfUExBVEZPUk09eQ0K
DQojDQojIE5vbi04MjUwIHNlcmlhbCBwb3J0IHN1cHBvcnQNCiMNCiMgQ09O
RklHX1NFUklBTF9BTUJBX1BMMDEwIGlzIG5vdCBzZXQNCkNPTkZJR19TRVJJ
QUxfQU1CQV9QTDAxMT15DQpDT05GSUdfU0VSSUFMX0FNQkFfUEwwMTFfQ09O
U09MRT15DQojIENPTkZJR19TRVJJQUxfRUFSTFlDT05fQVJNX1NFTUlIT1NU
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklBTF9NQVgzMTAwIGlzIG5vdCBz
ZXQNCkNPTkZJR19TRVJJQUxfTUFYMzEwWD15DQpDT05GSUdfU0VSSUFMX1VB
UlRMSVRFPXkNCkNPTkZJR19TRVJJQUxfVUFSVExJVEVfQ09OU09MRT15DQpD
T05GSUdfU0VSSUFMX1VBUlRMSVRFX05SX1VBUlRTPTENCkNPTkZJR19TRVJJ
QUxfQ09SRT15DQpDT05GSUdfU0VSSUFMX0NPUkVfQ09OU09MRT15DQojIENP
TkZJR19TRVJJQUxfU0lGSVZFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklB
TF9TQ0NOWFAgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSUFMX1NDMTZJUzdY
WCBpcyBub3Qgc2V0DQojIENPTkZJR19TRVJJQUxfQUxURVJBX0pUQUdVQVJU
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklBTF9BTFRFUkFfVUFSVCBpcyBu
b3Qgc2V0DQojIENPTkZJR19TRVJJQUxfSUZYNlg2MCBpcyBub3Qgc2V0DQpD
T05GSUdfU0VSSUFMX1hJTElOWF9QU19VQVJUPXkNCkNPTkZJR19TRVJJQUxf
WElMSU5YX1BTX1VBUlRfQ09OU09MRT15DQojIENPTkZJR19TRVJJQUxfQVJD
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklBTF9GU0xfTFBVQVJUIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1NFUklBTF9GU0xfTElORkxFWFVBUlQgaXMgbm90
IHNldA0KIyBDT05GSUdfU0VSSUFMX0NPTkVYQU5UX0RJR0lDT0xPUiBpcyBu
b3Qgc2V0DQojIGVuZCBvZiBTZXJpYWwgZHJpdmVycw0KDQpDT05GSUdfU0VS
SUFMX01DVFJMX0dQSU89eQ0KQ09ORklHX1NFUklBTF9ERVZfQlVTPXkNCkNP
TkZJR19TRVJJQUxfREVWX0NUUkxfVFRZUE9SVD15DQojIENPTkZJR19UVFlf
UFJJTlRLIGlzIG5vdCBzZXQNCkNPTkZJR19IVkNfRFJJVkVSPXkNCkNPTkZJ
R19IVkNfSVJRPXkNCkNPTkZJR19IVkNfWEVOPXkNCkNPTkZJR19IVkNfWEVO
X0ZST05URU5EPXkNCiMgQ09ORklHX0hWQ19EQ0MgaXMgbm90IHNldA0KIyBD
T05GSUdfVklSVElPX0NPTlNPTEUgaXMgbm90IHNldA0KIyBDT05GSUdfSVBN
SV9IQU5ETEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hXX1JBTkRPTSBpcyBu
b3Qgc2V0DQojIENPTkZJR19SQVdfRFJJVkVSIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1RDR19UUE0gaXMgbm90IHNldA0KIyBDT05GSUdfWElMTFlCVVMgaXMg
bm90IHNldA0KIyBlbmQgb2YgQ2hhcmFjdGVyIGRldmljZXMNCg0KIyBDT05G
SUdfUkFORE9NX1RSVVNUX0JPT1RMT0FERVIgaXMgbm90IHNldA0KDQojDQoj
IEkyQyBzdXBwb3J0DQojDQpDT05GSUdfSTJDPXkNCkNPTkZJR19JMkNfQk9B
UkRJTkZPPXkNCkNPTkZJR19JMkNfQ09NUEFUPXkNCkNPTkZJR19JMkNfQ0hB
UkRFVj15DQpDT05GSUdfSTJDX01VWD15DQoNCiMNCiMgTXVsdGlwbGV4ZXIg
STJDIENoaXAgc3VwcG9ydA0KIw0KIyBDT05GSUdfSTJDX0FSQl9HUElPX0NI
QUxMRU5HRSBpcyBub3Qgc2V0DQojIENPTkZJR19JMkNfTVVYX0dQSU8gaXMg
bm90IHNldA0KIyBDT05GSUdfSTJDX01VWF9HUE1VWCBpcyBub3Qgc2V0DQoj
IENPTkZJR19JMkNfTVVYX0xUQzQzMDYgaXMgbm90IHNldA0KQ09ORklHX0ky
Q19NVVhfUENBOTU0MT15DQpDT05GSUdfSTJDX01VWF9QQ0E5NTR4PXkNCiMg
Q09ORklHX0kyQ19NVVhfUElOQ1RSTCBpcyBub3Qgc2V0DQojIENPTkZJR19J
MkNfTVVYX1JFRyBpcyBub3Qgc2V0DQojIENPTkZJR19JMkNfREVNVVhfUElO
Q1RSTCBpcyBub3Qgc2V0DQojIENPTkZJR19JMkNfTVVYX01MWENQTEQgaXMg
bm90IHNldA0KIyBlbmQgb2YgTXVsdGlwbGV4ZXIgSTJDIENoaXAgc3VwcG9y
dA0KDQpDT05GSUdfSTJDX0hFTFBFUl9BVVRPPXkNCkNPTkZJR19JMkNfQUxH
T0JJVD15DQoNCiMNCiMgSTJDIEhhcmR3YXJlIEJ1cyBzdXBwb3J0DQojDQoN
CiMNCiMgSTJDIHN5c3RlbSBidXMgZHJpdmVycyAobW9zdGx5IGVtYmVkZGVk
IC8gc3lzdGVtLW9uLWNoaXApDQojDQpDT05GSUdfSTJDX0NBREVOQ0U9eQ0K
IyBDT05GSUdfSTJDX0NCVVNfR1BJTyBpcyBub3Qgc2V0DQojIENPTkZJR19J
MkNfREVTSUdOV0FSRV9QTEFURk9STSBpcyBub3Qgc2V0DQojIENPTkZJR19J
MkNfRU1FVjIgaXMgbm90IHNldA0KIyBDT05GSUdfSTJDX0dQSU8gaXMgbm90
IHNldA0KIyBDT05GSUdfSTJDX05PTUFESUsgaXMgbm90IHNldA0KIyBDT05G
SUdfSTJDX09DT1JFUyBpcyBub3Qgc2V0DQojIENPTkZJR19JMkNfUENBX1BM
QVRGT1JNIGlzIG5vdCBzZXQNCiMgQ09ORklHX0kyQ19SSzNYIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0kyQ19TSU1URUMgaXMgbm90IHNldA0KQ09ORklHX0ky
Q19YSUxJTlg9eQ0KDQojDQojIEV4dGVybmFsIEkyQy9TTUJ1cyBhZGFwdGVy
IGRyaXZlcnMNCiMNCiMgQ09ORklHX0kyQ19ESU9MQU5fVTJDIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0kyQ19ST0JPVEZVWlpfT1NJRiBpcyBub3Qgc2V0DQoj
IENPTkZJR19JMkNfVEFPU19FVk0gaXMgbm90IHNldA0KIyBDT05GSUdfSTJD
X1RJTllfVVNCIGlzIG5vdCBzZXQNCg0KIw0KIyBPdGhlciBJMkMvU01CdXMg
YnVzIGRyaXZlcnMNCiMNCiMgZW5kIG9mIEkyQyBIYXJkd2FyZSBCdXMgc3Vw
cG9ydA0KDQojIENPTkZJR19JMkNfU1RVQiBpcyBub3Qgc2V0DQojIENPTkZJ
R19JMkNfU0xBVkUgaXMgbm90IHNldA0KIyBDT05GSUdfSTJDX0RFQlVHX0NP
UkUgaXMgbm90IHNldA0KIyBDT05GSUdfSTJDX0RFQlVHX0FMR08gaXMgbm90
IHNldA0KIyBDT05GSUdfSTJDX0RFQlVHX0JVUyBpcyBub3Qgc2V0DQojIGVu
ZCBvZiBJMkMgc3VwcG9ydA0KDQojIENPTkZJR19JM0MgaXMgbm90IHNldA0K
Q09ORklHX1NQST15DQojIENPTkZJR19TUElfREVCVUcgaXMgbm90IHNldA0K
Q09ORklHX1NQSV9NQVNURVI9eQ0KQ09ORklHX1NQSV9NRU09eQ0KDQojDQoj
IFNQSSBNYXN0ZXIgQ29udHJvbGxlciBEcml2ZXJzDQojDQojIENPTkZJR19T
UElfQUxURVJBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NQSV9BWElfU1BJX0VO
R0lORSBpcyBub3Qgc2V0DQpDT05GSUdfU1BJX0JJVEJBTkc9eQ0KQ09ORklH
X1NQSV9DQURFTkNFPXkNCiMgQ09ORklHX1NQSV9ERVNJR05XQVJFIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1NQSV9OWFBfRkxFWFNQSSBpcyBub3Qgc2V0DQoj
IENPTkZJR19TUElfR1BJTyBpcyBub3Qgc2V0DQojIENPTkZJR19TUElfRlNM
X1NQSSBpcyBub3Qgc2V0DQojIENPTkZJR19TUElfT0NfVElOWSBpcyBub3Qg
c2V0DQojIENPTkZJR19TUElfUEwwMjIgaXMgbm90IHNldA0KIyBDT05GSUdf
U1BJX1JPQ0tDSElQIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NQSV9TQzE4SVM2
MDIgaXMgbm90IHNldA0KIyBDT05GSUdfU1BJX1NJRklWRSBpcyBub3Qgc2V0
DQojIENPTkZJR19TUElfTVhJQyBpcyBub3Qgc2V0DQojIENPTkZJR19TUElf
WENPTU0gaXMgbm90IHNldA0KQ09ORklHX1NQSV9YSUxJTlg9eQ0KQ09ORklH
X1NQSV9aWU5RTVBfR1FTUEk9eQ0KDQojDQojIFNQSSBQcm90b2NvbCBNYXN0
ZXJzDQojDQojIENPTkZJR19TUElfU1BJREVWIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NQSV9MT09QQkFDS19URVNUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NQ
SV9UTEU2MlgwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NQSV9TTEFWRSBpcyBu
b3Qgc2V0DQojIENPTkZJR19TUE1JIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hT
SSBpcyBub3Qgc2V0DQpDT05GSUdfUFBTPXkNCiMgQ09ORklHX1BQU19ERUJV
RyBpcyBub3Qgc2V0DQoNCiMNCiMgUFBTIGNsaWVudHMgc3VwcG9ydA0KIw0K
IyBDT05GSUdfUFBTX0NMSUVOVF9LVElNRVIgaXMgbm90IHNldA0KIyBDT05G
SUdfUFBTX0NMSUVOVF9MRElTQyBpcyBub3Qgc2V0DQojIENPTkZJR19QUFNf
Q0xJRU5UX0dQSU8gaXMgbm90IHNldA0KDQojDQojIFBQUyBnZW5lcmF0b3Jz
IHN1cHBvcnQNCiMNCg0KIw0KIyBQVFAgY2xvY2sgc3VwcG9ydA0KIw0KQ09O
RklHX1BUUF8xNTg4X0NMT0NLPXkNCg0KIw0KIyBFbmFibGUgUEhZTElCIGFu
ZCBORVRXT1JLX1BIWV9USU1FU1RBTVBJTkcgdG8gc2VlIHRoZSBhZGRpdGlv
bmFsIGNsb2Nrcy4NCiMNCiMgQ09ORklHX1BUUF8xNTg4X0NMT0NLX0lEVENN
IGlzIG5vdCBzZXQNCiMgZW5kIG9mIFBUUCBjbG9jayBzdXBwb3J0DQoNCkNP
TkZJR19QSU5DVFJMPXkNCiMgQ09ORklHX0RFQlVHX1BJTkNUUkwgaXMgbm90
IHNldA0KIyBDT05GSUdfUElOQ1RSTF9BTUQgaXMgbm90IHNldA0KIyBDT05G
SUdfUElOQ1RSTF9NQ1AyM1MwOCBpcyBub3Qgc2V0DQojIENPTkZJR19QSU5D
VFJMX1NJTkdMRSBpcyBub3Qgc2V0DQojIENPTkZJR19QSU5DVFJMX1NYMTUw
WCBpcyBub3Qgc2V0DQojIENPTkZJR19QSU5DVFJMX1NUTUZYIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1BJTkNUUkxfT0NFTE9UIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1BJTkNUUkxfRVFVSUxJQlJJVU0gaXMgbm90IHNldA0KQ09ORklHX0dQ
SU9MSUI9eQ0KQ09ORklHX0dQSU9MSUJfRkFTVFBBVEhfTElNSVQ9NTEyDQpD
T05GSUdfT0ZfR1BJTz15DQpDT05GSUdfR1BJT0xJQl9JUlFDSElQPXkNCiMg
Q09ORklHX0RFQlVHX0dQSU8gaXMgbm90IHNldA0KQ09ORklHX0dQSU9fU1lT
RlM9eQ0KDQojDQojIE1lbW9yeSBtYXBwZWQgR1BJTyBkcml2ZXJzDQojDQoj
IENPTkZJR19HUElPXzc0WFhfTU1JTyBpcyBub3Qgc2V0DQojIENPTkZJR19H
UElPX0FMVEVSQSBpcyBub3Qgc2V0DQojIENPTkZJR19HUElPX0NBREVOQ0Ug
aXMgbm90IHNldA0KIyBDT05GSUdfR1BJT19EV0FQQiBpcyBub3Qgc2V0DQoj
IENPTkZJR19HUElPX0ZUR1BJTzAxMCBpcyBub3Qgc2V0DQojIENPTkZJR19H
UElPX0dFTkVSSUNfUExBVEZPUk0gaXMgbm90IHNldA0KIyBDT05GSUdfR1BJ
T19HUkdQSU8gaXMgbm90IHNldA0KIyBDT05GSUdfR1BJT19ITFdEIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0dQSU9fTUI4NlM3WCBpcyBub3Qgc2V0DQojIENP
TkZJR19HUElPX1BMMDYxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0dQSU9fU0lG
SVZFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0dQSU9fWEdFTkUgaXMgbm90IHNl
dA0KQ09ORklHX0dQSU9fWElMSU5YPXkNCkNPTkZJR19HUElPX1pZTlE9eQ0K
IyBDT05GSUdfR1BJT19BTURfRkNIIGlzIG5vdCBzZXQNCiMgZW5kIG9mIE1l
bW9yeSBtYXBwZWQgR1BJTyBkcml2ZXJzDQoNCiMNCiMgSTJDIEdQSU8gZXhw
YW5kZXJzDQojDQojIENPTkZJR19HUElPX0FEUDU1ODggaXMgbm90IHNldA0K
IyBDT05GSUdfR1BJT19BRE5QIGlzIG5vdCBzZXQNCiMgQ09ORklHX0dQSU9f
R1dfUExEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0dQSU9fTUFYNzMwMCBpcyBu
b3Qgc2V0DQojIENPTkZJR19HUElPX01BWDczMlggaXMgbm90IHNldA0KQ09O
RklHX0dQSU9fUENBOTUzWD15DQojIENPTkZJR19HUElPX1BDQTk1M1hfSVJR
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0dQSU9fUENGODU3WCBpcyBub3Qgc2V0
DQojIENPTkZJR19HUElPX1RQSUMyODEwIGlzIG5vdCBzZXQNCiMgZW5kIG9m
IEkyQyBHUElPIGV4cGFuZGVycw0KDQojDQojIE1GRCBHUElPIGV4cGFuZGVy
cw0KIw0KQ09ORklHX0dQSU9fVFBTNjUwODY9eQ0KIyBlbmQgb2YgTUZEIEdQ
SU8gZXhwYW5kZXJzDQoNCiMNCiMgU1BJIEdQSU8gZXhwYW5kZXJzDQojDQoj
IENPTkZJR19HUElPXzc0WDE2NCBpcyBub3Qgc2V0DQojIENPTkZJR19HUElP
X01BWDMxOTFYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0dQSU9fTUFYNzMwMSBp
cyBub3Qgc2V0DQojIENPTkZJR19HUElPX01DMzM4ODAgaXMgbm90IHNldA0K
IyBDT05GSUdfR1BJT19QSVNPU1IgaXMgbm90IHNldA0KIyBDT05GSUdfR1BJ
T19YUkExNDAzIGlzIG5vdCBzZXQNCiMgZW5kIG9mIFNQSSBHUElPIGV4cGFu
ZGVycw0KDQojDQojIFVTQiBHUElPIGV4cGFuZGVycw0KIw0KIyBlbmQgb2Yg
VVNCIEdQSU8gZXhwYW5kZXJzDQoNCiMgQ09ORklHX0dQSU9fTU9DS1VQIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1cxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BP
V0VSX0FWUyBpcyBub3Qgc2V0DQpDT05GSUdfUE9XRVJfUkVTRVQ9eQ0KIyBD
T05GSUdfUE9XRVJfUkVTRVRfR1BJTyBpcyBub3Qgc2V0DQojIENPTkZJR19Q
T1dFUl9SRVNFVF9HUElPX1JFU1RBUlQgaXMgbm90IHNldA0KQ09ORklHX1BP
V0VSX1JFU0VUX0xUQzI5NTI9eQ0KIyBDT05GSUdfUE9XRVJfUkVTRVRfUkVT
VEFSVCBpcyBub3Qgc2V0DQojIENPTkZJR19QT1dFUl9SRVNFVF9YR0VORSBp
cyBub3Qgc2V0DQojIENPTkZJR19QT1dFUl9SRVNFVF9TWVNDT04gaXMgbm90
IHNldA0KIyBDT05GSUdfUE9XRVJfUkVTRVRfU1lTQ09OX1BPV0VST0ZGIGlz
IG5vdCBzZXQNCiMgQ09ORklHX05WTUVNX1JFQk9PVF9NT0RFIGlzIG5vdCBz
ZXQNCkNPTkZJR19QT1dFUl9TVVBQTFk9eQ0KIyBDT05GSUdfUE9XRVJfU1VQ
UExZX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19QT1dFUl9TVVBQTFlfSFdN
T049eQ0KIyBDT05GSUdfUERBX1BPV0VSIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0dFTkVSSUNfQURDX0JBVFRFUlkgaXMgbm90IHNldA0KIyBDT05GSUdfVEVT
VF9QT1dFUiBpcyBub3Qgc2V0DQojIENPTkZJR19DSEFSR0VSX0FEUDUwNjEg
aXMgbm90IHNldA0KIyBDT05GSUdfQkFUVEVSWV9EUzI3ODAgaXMgbm90IHNl
dA0KIyBDT05GSUdfQkFUVEVSWV9EUzI3ODEgaXMgbm90IHNldA0KIyBDT05G
SUdfQkFUVEVSWV9EUzI3ODIgaXMgbm90IHNldA0KIyBDT05GSUdfQkFUVEVS
WV9MRUdPX0VWMyBpcyBub3Qgc2V0DQojIENPTkZJR19CQVRURVJZX1NCUyBp
cyBub3Qgc2V0DQojIENPTkZJR19DSEFSR0VSX1NCUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19NQU5BR0VSX1NCUyBpcyBub3Qgc2V0DQojIENPTkZJR19CQVRU
RVJZX0JRMjdYWFggaXMgbm90IHNldA0KIyBDT05GSUdfQkFUVEVSWV9NQVgx
NzA0MCBpcyBub3Qgc2V0DQojIENPTkZJR19CQVRURVJZX01BWDE3MDQyIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0NIQVJHRVJfSVNQMTcwNCBpcyBub3Qgc2V0
DQojIENPTkZJR19DSEFSR0VSX01BWDg5MDMgaXMgbm90IHNldA0KIyBDT05G
SUdfQ0hBUkdFUl9MUDg3MjcgaXMgbm90IHNldA0KIyBDT05GSUdfQ0hBUkdF
Ul9HUElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NIQVJHRVJfTUFOQUdFUiBp
cyBub3Qgc2V0DQojIENPTkZJR19DSEFSR0VSX0xUMzY1MSBpcyBub3Qgc2V0
DQojIENPTkZJR19DSEFSR0VSX0RFVEVDVE9SX01BWDE0NjU2IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0NIQVJHRVJfQlEyNDE1WCBpcyBub3Qgc2V0DQojIENP
TkZJR19DSEFSR0VSX0JRMjQxOTAgaXMgbm90IHNldA0KIyBDT05GSUdfQ0hB
UkdFUl9CUTI0MjU3IGlzIG5vdCBzZXQNCiMgQ09ORklHX0NIQVJHRVJfQlEy
NDczNSBpcyBub3Qgc2V0DQojIENPTkZJR19DSEFSR0VSX0JRMjU4OTAgaXMg
bm90IHNldA0KIyBDT05GSUdfQ0hBUkdFUl9TTUIzNDcgaXMgbm90IHNldA0K
IyBDT05GSUdfQkFUVEVSWV9HQVVHRV9MVEMyOTQxIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0NIQVJHRVJfUlQ5NDU1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0NI
QVJHRVJfVUNTMTAwMiBpcyBub3Qgc2V0DQpDT05GSUdfSFdNT049eQ0KIyBD
T05GSUdfSFdNT05fREVCVUdfQ0hJUCBpcyBub3Qgc2V0DQoNCiMNCiMgTmF0
aXZlIGRyaXZlcnMNCiMNCiMgQ09ORklHX1NFTlNPUlNfQUQ3MzE0IGlzIG5v
dCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfQUQ3NDE0IGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NFTlNPUlNfQUQ3NDE4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NF
TlNPUlNfQURNMTAyMSBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX0FE
TTEwMjUgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19BRE0xMDI2IGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfQURNMTAyOSBpcyBub3Qgc2V0
DQojIENPTkZJR19TRU5TT1JTX0FETTEwMzEgaXMgbm90IHNldA0KIyBDT05G
SUdfU0VOU09SU19BRE0xMTc3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP
UlNfQURNOTI0MCBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX0FEVDcz
MTAgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19BRFQ3NDEwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfQURUNzQxMSBpcyBub3Qgc2V0DQoj
IENPTkZJR19TRU5TT1JTX0FEVDc0NjIgaXMgbm90IHNldA0KIyBDT05GSUdf
U0VOU09SU19BRFQ3NDcwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNf
QURUNzQ3NSBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX0FTMzcwIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfQVNDNzYyMSBpcyBub3Qgc2V0
DQojIENPTkZJR19TRU5TT1JTX0FTUEVFRCBpcyBub3Qgc2V0DQojIENPTkZJ
R19TRU5TT1JTX0FUWFAxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNf
RFJJVkVURU1QIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfRFM2MjAg
aXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19EUzE2MjEgaXMgbm90IHNl
dA0KIyBDT05GSUdfU0VOU09SU19GNzE4MDVGIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NFTlNPUlNfRjcxODgyRkcgaXMgbm90IHNldA0KIyBDT05GSUdfU0VO
U09SU19GNzUzNzVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfRlRT
VEVVVEFURVMgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19HTDUxOFNN
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfR0w1MjBTTSBpcyBub3Qg
c2V0DQojIENPTkZJR19TRU5TT1JTX0c3NjBBIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NFTlNPUlNfRzc2MiBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JT
X0dQSU9fRkFOIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfSElINjEz
MCBpcyBub3Qgc2V0DQpDT05GSUdfU0VOU09SU19JSU9fSFdNT049eQ0KIyBD
T05GSUdfU0VOU09SU19JVDg3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP
UlNfSkM0MiBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX1BPV1IxMjIw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfTElORUFHRSBpcyBub3Qg
c2V0DQojIENPTkZJR19TRU5TT1JTX0xUQzI5NDUgaXMgbm90IHNldA0KIyBD
T05GSUdfU0VOU09SU19MVEMyOTQ3X0kyQyBpcyBub3Qgc2V0DQojIENPTkZJ
R19TRU5TT1JTX0xUQzI5NDdfU1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NF
TlNPUlNfTFRDMjk5MCBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX0xU
QzQxNTEgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19MVEM0MjE1IGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfTFRDNDIyMiBpcyBub3Qgc2V0
DQojIENPTkZJR19TRU5TT1JTX0xUQzQyNDUgaXMgbm90IHNldA0KIyBDT05G
SUdfU0VOU09SU19MVEM0MjYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP
UlNfTFRDNDI2MSBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX01BWDEx
MTEgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19NQVgxNjA2NSBpcyBu
b3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX01BWDE2MTkgaXMgbm90IHNldA0K
IyBDT05GSUdfU0VOU09SU19NQVgxNjY4IGlzIG5vdCBzZXQNCiMgQ09ORklH
X1NFTlNPUlNfTUFYMTk3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNf
TUFYMzE3MjIgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19NQVgzMTcz
MCBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX01BWDY2MjEgaXMgbm90
IHNldA0KIyBDT05GSUdfU0VOU09SU19NQVg2NjM5IGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NFTlNPUlNfTUFYNjY0MiBpcyBub3Qgc2V0DQojIENPTkZJR19T
RU5TT1JTX01BWDY2NTAgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19N
QVg2Njk3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfTUFYMzE3OTAg
aXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19NQ1AzMDIxIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NFTlNPUlNfVEM2NTQgaXMgbm90IHNldA0KIyBDT05G
SUdfU0VOU09SU19BRENYWCBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JT
X0xNNjMgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19MTTcwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfTE03MyBpcyBub3Qgc2V0DQojIENP
TkZJR19TRU5TT1JTX0xNNzUgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09S
U19MTTc3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfTE03OCBpcyBu
b3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX0xNODAgaXMgbm90IHNldA0KIyBD
T05GSUdfU0VOU09SU19MTTgzIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP
UlNfTE04NSBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX0xNODcgaXMg
bm90IHNldA0KIyBDT05GSUdfU0VOU09SU19MTTkwIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NFTlNPUlNfTE05MiBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5T
T1JTX0xNOTMgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19MTTk1MjM0
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfTE05NTI0MSBpcyBub3Qg
c2V0DQojIENPTkZJR19TRU5TT1JTX0xNOTUyNDUgaXMgbm90IHNldA0KIyBD
T05GSUdfU0VOU09SU19QQzg3MzYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NF
TlNPUlNfUEM4NzQyNyBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX05U
Q19USEVSTUlTVE9SIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfTkNU
NjY4MyBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX05DVDY3NzUgaXMg
bm90IHNldA0KIyBDT05GSUdfU0VOU09SU19OQ1Q3ODAyIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1NFTlNPUlNfTkNUNzkwNCBpcyBub3Qgc2V0DQojIENPTkZJ
R19TRU5TT1JTX05QQ003WFggaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09S
U19PQ0NfUDhfSTJDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfUENG
ODU5MSBpcyBub3Qgc2V0DQpDT05GSUdfUE1CVVM9eQ0KQ09ORklHX1NFTlNP
UlNfUE1CVVM9eQ0KIyBDT05GSUdfU0VOU09SU19BRE0xMjc1IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NFTlNPUlNfQkVMX1BGRSBpcyBub3Qgc2V0DQojIENP
TkZJR19TRU5TT1JTX0lCTV9DRkZQUyBpcyBub3Qgc2V0DQojIENPTkZJR19T
RU5TT1JTX0lOU1BVUl9JUFNQUyBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5T
T1JTX0lSMzUyMjEgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19JUjM4
MDY0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfSVJQUzU0MDEgaXMg
bm90IHNldA0KIyBDT05GSUdfU0VOU09SU19JU0w2ODEzNyBpcyBub3Qgc2V0
DQojIENPTkZJR19TRU5TT1JTX0xNMjUwNjYgaXMgbm90IHNldA0KIyBDT05G
SUdfU0VOU09SU19MVEMyOTc4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP
UlNfTFRDMzgxNSBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX01BWDE2
MDY0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfTUFYMjA3MzAgaXMg
bm90IHNldA0KQ09ORklHX1NFTlNPUlNfTUFYMjA3NTE9eQ0KIyBDT05GSUdf
U0VOU09SU19NQVgzMTc4NSBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JT
X01BWDM0NDQwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfTUFYODY4
OCBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX1BYRTE2MTAgaXMgbm90
IHNldA0KIyBDT05GSUdfU0VOU09SU19UUFM0MDQyMiBpcyBub3Qgc2V0DQoj
IENPTkZJR19TRU5TT1JTX1RQUzUzNjc5IGlzIG5vdCBzZXQNCiMgQ09ORklH
X1NFTlNPUlNfVUNEOTAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JT
X1VDRDkyMDAgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19YRFBFMTIy
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfWkw2MTAwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NFTlNPUlNfU0hUMTUgaXMgbm90IHNldA0KIyBDT05G
SUdfU0VOU09SU19TSFQyMSBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JT
X1NIVDN4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfU0hUQzEgaXMg
bm90IHNldA0KIyBDT05GSUdfU0VOU09SU19ETUUxNzM3IGlzIG5vdCBzZXQN
CiMgQ09ORklHX1NFTlNPUlNfRU1DMTQwMyBpcyBub3Qgc2V0DQojIENPTkZJ
R19TRU5TT1JTX0VNQzIxMDMgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09S
U19FTUM2VzIwMSBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX1NNU0M0
N00xIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfU01TQzQ3TTE5MiBp
cyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX1NNU0M0N0IzOTcgaXMgbm90
IHNldA0KIyBDT05GSUdfU0VOU09SU19TQ0g1NjI3IGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NFTlNPUlNfU0NINTYzNiBpcyBub3Qgc2V0DQojIENPTkZJR19T
RU5TT1JTX1NUVFM3NTEgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19T
TU02NjUgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19BREMxMjhEODE4
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfQURTNzgyOCBpcyBub3Qg
c2V0DQojIENPTkZJR19TRU5TT1JTX0FEUzc4NzEgaXMgbm90IHNldA0KIyBD
T05GSUdfU0VOU09SU19BTUM2ODIxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NF
TlNPUlNfSU5BMjA5IGlzIG5vdCBzZXQNCkNPTkZJR19TRU5TT1JTX0lOQTJY
WD15DQojIENPTkZJR19TRU5TT1JTX0lOQTMyMjEgaXMgbm90IHNldA0KIyBD
T05GSUdfU0VOU09SU19UQzc0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP
UlNfVEhNQzUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfVE1QMTAy
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfVE1QMTAzIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NFTlNPUlNfVE1QMTA4IGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NFTlNPUlNfVE1QNDAxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP
UlNfVE1QNDIxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfVE1QNTEz
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfVlQxMjExIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NFTlNPUlNfVzgzNzczRyBpcyBub3Qgc2V0DQojIENP
TkZJR19TRU5TT1JTX1c4Mzc4MUQgaXMgbm90IHNldA0KIyBDT05GSUdfU0VO
U09SU19XODM3OTFEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfVzgz
NzkyRCBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX1c4Mzc5MyBpcyBu
b3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX1c4Mzc5NSBpcyBub3Qgc2V0DQoj
IENPTkZJR19TRU5TT1JTX1c4M0w3ODVUUyBpcyBub3Qgc2V0DQojIENPTkZJ
R19TRU5TT1JTX1c4M0w3ODZORyBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5T
T1JTX1c4MzYyN0hGIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNfVzgz
NjI3RUhGIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RIRVJNQUwgaXMgbm90IHNl
dA0KQ09ORklHX1dBVENIRE9HPXkNCkNPTkZJR19XQVRDSERPR19DT1JFPXkN
CiMgQ09ORklHX1dBVENIRE9HX05PV0FZT1VUIGlzIG5vdCBzZXQNCkNPTkZJ
R19XQVRDSERPR19IQU5ETEVfQk9PVF9FTkFCTEVEPXkNCkNPTkZJR19XQVRD
SERPR19PUEVOX1RJTUVPVVQ9MA0KIyBDT05GSUdfV0FUQ0hET0dfU1lTRlMg
aXMgbm90IHNldA0KDQojDQojIFdhdGNoZG9nIFByZXRpbWVvdXQgR292ZXJu
b3JzDQojDQojIENPTkZJR19XQVRDSERPR19QUkVUSU1FT1VUX0dPViBpcyBu
b3Qgc2V0DQoNCiMNCiMgV2F0Y2hkb2cgRGV2aWNlIERyaXZlcnMNCiMNCiMg
Q09ORklHX1NPRlRfV0FUQ0hET0cgaXMgbm90IHNldA0KIyBDT05GSUdfR1BJ
T19XQVRDSERPRyBpcyBub3Qgc2V0DQpDT05GSUdfWElMSU5YX1dBVENIRE9H
PXkNCiMgQ09ORklHX1pJSVJBVkVfV0FUQ0hET0cgaXMgbm90IHNldA0KIyBD
T05GSUdfQVJNX1NQODA1X1dBVENIRE9HIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0FSTV9TQlNBX1dBVENIRE9HIGlzIG5vdCBzZXQNCkNPTkZJR19DQURFTkNF
X1dBVENIRE9HPXkNCiMgQ09ORklHX0RXX1dBVENIRE9HIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01BWDYzWFhfV0FUQ0hET0cgaXMgbm90IHNldA0KIyBDT05G
SUdfTUVOX0EyMV9XRFQgaXMgbm90IHNldA0KQ09ORklHX1hFTl9XRFQ9eQ0K
DQojDQojIFVTQi1iYXNlZCBXYXRjaGRvZyBDYXJkcw0KIw0KIyBDT05GSUdf
VVNCUENXQVRDSERPRyBpcyBub3Qgc2V0DQpDT05GSUdfU1NCX1BPU1NJQkxF
PXkNCiMgQ09ORklHX1NTQiBpcyBub3Qgc2V0DQpDT05GSUdfQkNNQV9QT1NT
SUJMRT15DQojIENPTkZJR19CQ01BIGlzIG5vdCBzZXQNCg0KIw0KIyBNdWx0
aWZ1bmN0aW9uIGRldmljZSBkcml2ZXJzDQojDQpDT05GSUdfTUZEX0NPUkU9
eQ0KIyBDT05GSUdfTUZEX0FDVDg5NDVBIGlzIG5vdCBzZXQNCiMgQ09ORklH
X01GRF9BUzM3MTEgaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX0FTMzcyMiBp
cyBub3Qgc2V0DQojIENPTkZJR19QTUlDX0FEUDU1MjAgaXMgbm90IHNldA0K
IyBDT05GSUdfTUZEX0FBVDI4NzBfQ09SRSBpcyBub3Qgc2V0DQojIENPTkZJ
R19NRkRfQVRNRUxfRkxFWENPTSBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRf
QVRNRUxfSExDREMgaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX0JDTTU5MFhY
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9CRDk1NzFNV1YgaXMgbm90IHNl
dA0KIyBDT05GSUdfTUZEX0FYUDIwWF9JMkMgaXMgbm90IHNldA0KIyBDT05G
SUdfTUZEX01BREVSQSBpcyBub3Qgc2V0DQojIENPTkZJR19QTUlDX0RBOTAz
WCBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRfREE5MDUyX1NQSSBpcyBub3Qg
c2V0DQojIENPTkZJR19NRkRfREE5MDUyX0kyQyBpcyBub3Qgc2V0DQojIENP
TkZJR19NRkRfREE5MDU1IGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9EQTkw
NjIgaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX0RBOTA2MyBpcyBub3Qgc2V0
DQojIENPTkZJR19NRkRfREE5MTUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01G
RF9ETE4yIGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9NQzEzWFhYX1NQSSBp
cyBub3Qgc2V0DQojIENPTkZJR19NRkRfTUMxM1hYWF9JMkMgaXMgbm90IHNl
dA0KIyBDT05GSUdfTUZEX0hJNjQyMV9QTUlDIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0hUQ19QQVNJQzMgaXMgbm90IHNldA0KIyBDT05GSUdfSFRDX0kyQ1BM
RCBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRfS0VNUExEIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01GRF84OFBNODAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01G
RF84OFBNODA1IGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF84OFBNODYwWCBp
cyBub3Qgc2V0DQojIENPTkZJR19NRkRfTUFYMTQ1NzcgaXMgbm90IHNldA0K
IyBDT05GSUdfTUZEX01BWDc3NjIwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01G
RF9NQVg3NzY1MCBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRfTUFYNzc2ODYg
aXMgbm90IHNldA0KIyBDT05GSUdfTUZEX01BWDc3NjkzIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01GRF9NQVg3Nzg0MyBpcyBub3Qgc2V0DQojIENPTkZJR19N
RkRfTUFYODkwNyBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRfTUFYODkyNSBp
cyBub3Qgc2V0DQojIENPTkZJR19NRkRfTUFYODk5NyBpcyBub3Qgc2V0DQoj
IENPTkZJR19NRkRfTUFYODk5OCBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRf
TVQ2Mzk3IGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9NRU5GMjFCTUMgaXMg
bm90IHNldA0KIyBDT05GSUdfRVpYX1BDQVAgaXMgbm90IHNldA0KIyBDT05G
SUdfTUZEX0NQQ0FQIGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9WSVBFUkJP
QVJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9SRVRVIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01GRF9QQ0Y1MDYzMyBpcyBub3Qgc2V0DQojIENPTkZJR19N
RkRfUlQ1MDMzIGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9SQzVUNTgzIGlz
IG5vdCBzZXQNCiMgQ09ORklHX01GRF9SSzgwOCBpcyBub3Qgc2V0DQojIENP
TkZJR19NRkRfUk41VDYxOCBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRfU0VD
X0NPUkUgaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX1NJNDc2WF9DT1JFIGlz
IG5vdCBzZXQNCiMgQ09ORklHX01GRF9TTTUwMSBpcyBub3Qgc2V0DQojIENP
TkZJR19NRkRfU0tZODE0NTIgaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX1NN
U0MgaXMgbm90IHNldA0KIyBDT05GSUdfQUJYNTAwX0NPUkUgaXMgbm90IHNl
dA0KIyBDT05GSUdfTUZEX1NUTVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX01G
RF9TWVNDT04gaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX1RJX0FNMzM1WF9U
U0NBREMgaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX0xQMzk0MyBpcyBub3Qg
c2V0DQojIENPTkZJR19NRkRfTFA4Nzg4IGlzIG5vdCBzZXQNCiMgQ09ORklH
X01GRF9USV9MTVUgaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX1BBTE1BUyBp
cyBub3Qgc2V0DQojIENPTkZJR19UUFM2MTA1WCBpcyBub3Qgc2V0DQojIENP
TkZJR19UUFM2NTAxMCBpcyBub3Qgc2V0DQojIENPTkZJR19UUFM2NTA3WCBp
cyBub3Qgc2V0DQpDT05GSUdfTUZEX1RQUzY1MDg2PXkNCiMgQ09ORklHX01G
RF9UUFM2NTA5MCBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRfVFBTNjUyMTcg
aXMgbm90IHNldA0KIyBDT05GSUdfTUZEX1RJX0xQODczWCBpcyBub3Qgc2V0
DQojIENPTkZJR19NRkRfVElfTFA4NzU2NSBpcyBub3Qgc2V0DQojIENPTkZJ
R19NRkRfVFBTNjUyMTggaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX1RQUzY1
ODZYIGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9UUFM2NTkxMCBpcyBub3Qg
c2V0DQojIENPTkZJR19NRkRfVFBTNjU5MTJfSTJDIGlzIG5vdCBzZXQNCiMg
Q09ORklHX01GRF9UUFM2NTkxMl9TUEkgaXMgbm90IHNldA0KIyBDT05GSUdf
TUZEX1RQUzgwMDMxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RXTDQwMzBfQ09S
RSBpcyBub3Qgc2V0DQojIENPTkZJR19UV0w2MDQwX0NPUkUgaXMgbm90IHNl
dA0KIyBDT05GSUdfTUZEX1dMMTI3M19DT1JFIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01GRF9MTTM1MzMgaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX1RDMzU4
OVggaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX1RRTVg4NiBpcyBub3Qgc2V0
DQojIENPTkZJR19NRkRfTE9DSE5BR0FSIGlzIG5vdCBzZXQNCiMgQ09ORklH
X01GRF9BUklaT05BX0kyQyBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRfQVJJ
Wk9OQV9TUEkgaXMgbm90IHNldA0KIyBDT05GSUdfTUZEX1dNODQwMCBpcyBu
b3Qgc2V0DQojIENPTkZJR19NRkRfV004MzFYX0kyQyBpcyBub3Qgc2V0DQoj
IENPTkZJR19NRkRfV004MzFYX1NQSSBpcyBub3Qgc2V0DQojIENPTkZJR19N
RkRfV004MzUwX0kyQyBpcyBub3Qgc2V0DQojIENPTkZJR19NRkRfV004OTk0
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9ST0hNX0JENzE4WFggaXMgbm90
IHNldA0KIyBDT05GSUdfTUZEX1JPSE1fQkQ3MDUyOCBpcyBub3Qgc2V0DQoj
IENPTkZJR19NRkRfUk9ITV9CRDcxODI4IGlzIG5vdCBzZXQNCiMgQ09ORklH
X01GRF9TVFBNSUMxIGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9TVE1GWCBp
cyBub3Qgc2V0DQojIENPTkZJR19SQVZFX1NQX0NPUkUgaXMgbm90IHNldA0K
IyBlbmQgb2YgTXVsdGlmdW5jdGlvbiBkZXZpY2UgZHJpdmVycw0KDQpDT05G
SUdfUkVHVUxBVE9SPXkNCiMgQ09ORklHX1JFR1VMQVRPUl9ERUJVRyBpcyBu
b3Qgc2V0DQpDT05GSUdfUkVHVUxBVE9SX0ZJWEVEX1ZPTFRBR0U9eQ0KIyBD
T05GSUdfUkVHVUxBVE9SX1ZJUlRVQUxfQ09OU1VNRVIgaXMgbm90IHNldA0K
IyBDT05GSUdfUkVHVUxBVE9SX1VTRVJTUEFDRV9DT05TVU1FUiBpcyBub3Qg
c2V0DQojIENPTkZJR19SRUdVTEFUT1JfODhQRzg2WCBpcyBub3Qgc2V0DQoj
IENPTkZJR19SRUdVTEFUT1JfQUNUODg2NSBpcyBub3Qgc2V0DQojIENPTkZJ
R19SRUdVTEFUT1JfQUQ1Mzk4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VM
QVRPUl9EQTkyMTAgaXMgbm90IHNldA0KIyBDT05GSUdfUkVHVUxBVE9SX0RB
OTIxMSBpcyBub3Qgc2V0DQojIENPTkZJR19SRUdVTEFUT1JfRkFONTM1NTUg
aXMgbm90IHNldA0KQ09ORklHX1JFR1VMQVRPUl9HUElPPXkNCiMgQ09ORklH
X1JFR1VMQVRPUl9JU0w5MzA1IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VM
QVRPUl9JU0w2MjcxQSBpcyBub3Qgc2V0DQojIENPTkZJR19SRUdVTEFUT1Jf
TFAzOTcxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9MUDM5NzIg
aXMgbm90IHNldA0KIyBDT05GSUdfUkVHVUxBVE9SX0xQODcyWCBpcyBub3Qg
c2V0DQojIENPTkZJR19SRUdVTEFUT1JfTFA4NzU1IGlzIG5vdCBzZXQNCiMg
Q09ORklHX1JFR1VMQVRPUl9MVEMzNTg5IGlzIG5vdCBzZXQNCiMgQ09ORklH
X1JFR1VMQVRPUl9MVEMzNjc2IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VM
QVRPUl9NQVgxNTg2IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9N
QVg4NjQ5IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9NQVg4NjYw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9NQVg4OTUyIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9NQ1AxNjUwMiBpcyBub3Qgc2V0
DQojIENPTkZJR19SRUdVTEFUT1JfTVA4ODU5IGlzIG5vdCBzZXQNCiMgQ09O
RklHX1JFR1VMQVRPUl9NUFE3OTIwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JF
R1VMQVRPUl9NVDYzMTEgaXMgbm90IHNldA0KIyBDT05GSUdfUkVHVUxBVE9S
X1BGVVpFMTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9QVjg4
MDYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9QVjg4MDgwIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9QVjg4MDkwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9TTEc1MTAwMCBpcyBub3Qgc2V0DQoj
IENPTkZJR19SRUdVTEFUT1JfU1k4MTA2QSBpcyBub3Qgc2V0DQojIENPTkZJ
R19SRUdVTEFUT1JfU1k4ODI0WCBpcyBub3Qgc2V0DQojIENPTkZJR19SRUdV
TEFUT1JfVFBTNTE2MzIgaXMgbm90IHNldA0KIyBDT05GSUdfUkVHVUxBVE9S
X1RQUzYyMzYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VMQVRPUl9UUFM2
NTAyMyBpcyBub3Qgc2V0DQojIENPTkZJR19SRUdVTEFUT1JfVFBTNjUwN1gg
aXMgbm90IHNldA0KQ09ORklHX1JFR1VMQVRPUl9UUFM2NTA4Nj15DQojIENP
TkZJR19SRUdVTEFUT1JfVFBTNjUxMzIgaXMgbm90IHNldA0KIyBDT05GSUdf
UkVHVUxBVE9SX1RQUzY1MjRYIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFR1VM
QVRPUl9WQ1RSTCBpcyBub3Qgc2V0DQojIENPTkZJR19SQ19DT1JFIGlzIG5v
dCBzZXQNCkNPTkZJR19NRURJQV9TVVBQT1JUPXkNCg0KIw0KIyBNdWx0aW1l
ZGlhIGNvcmUgc3VwcG9ydA0KIw0KQ09ORklHX01FRElBX0NBTUVSQV9TVVBQ
T1JUPXkNCiMgQ09ORklHX01FRElBX0FOQUxPR19UVl9TVVBQT1JUIGlzIG5v
dCBzZXQNCiMgQ09ORklHX01FRElBX0RJR0lUQUxfVFZfU1VQUE9SVCBpcyBu
b3Qgc2V0DQojIENPTkZJR19NRURJQV9SQURJT19TVVBQT1JUIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX01FRElBX1NEUl9TVVBQT1JUIGlzIG5vdCBzZXQNCiMg
Q09ORklHX01FRElBX0NFQ19TVVBQT1JUIGlzIG5vdCBzZXQNCkNPTkZJR19N
RURJQV9DT05UUk9MTEVSPXkNCkNPTkZJR19WSURFT19ERVY9eQ0KQ09ORklH
X1ZJREVPX1Y0TDJfU1VCREVWX0FQST15DQpDT05GSUdfVklERU9fVjRMMj15
DQpDT05GSUdfVklERU9fVjRMMl9JMkM9eQ0KIyBDT05GSUdfVklERU9fQURW
X0RFQlVHIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX0ZJWEVEX01JTk9S
X1JBTkdFUyBpcyBub3Qgc2V0DQpDT05GSUdfVjRMMl9GV05PREU9eQ0KDQoj
DQojIE1lZGlhIGRyaXZlcnMNCiMNCkNPTkZJR19NRURJQV9VU0JfU1VQUE9S
VD15DQoNCiMNCiMgV2ViY2FtIGRldmljZXMNCiMNCkNPTkZJR19VU0JfVklE
RU9fQ0xBU1M9eQ0KQ09ORklHX1VTQl9WSURFT19DTEFTU19JTlBVVF9FVkRF
Vj15DQpDT05GSUdfVVNCX0dTUENBPW0NCiMgQ09ORklHX1VTQl9NNTYwMiBp
cyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RWMDZYWCBpcyBub3Qgc2V0DQoj
IENPTkZJR19VU0JfR0w4NjAgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dT
UENBX0JFTlEgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dTUENBX0NPTkVY
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9HU1BDQV9DUElBMSBpcyBub3Qg
c2V0DQojIENPTkZJR19VU0JfR1NQQ0FfRFRDUzAzMyBpcyBub3Qgc2V0DQoj
IENPTkZJR19VU0JfR1NQQ0FfRVRPTVMgaXMgbm90IHNldA0KIyBDT05GSUdf
VVNCX0dTUENBX0ZJTkVQSVggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dT
UENBX0pFSUxJTkogaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dTUENBX0pM
MjAwNUJDRCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfR1NQQ0FfS0lORUNU
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9HU1BDQV9LT05JQ0EgaXMgbm90
IHNldA0KIyBDT05GSUdfVVNCX0dTUENBX01BUlMgaXMgbm90IHNldA0KIyBD
T05GSUdfVVNCX0dTUENBX01SOTczMTBBIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1VTQl9HU1BDQV9OVzgwWCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfR1NQ
Q0FfT1Y1MTkgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dTUENBX09WNTM0
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9HU1BDQV9PVjUzNF85IGlzIG5v
dCBzZXQNCiMgQ09ORklHX1VTQl9HU1BDQV9QQUMyMDcgaXMgbm90IHNldA0K
IyBDT05GSUdfVVNCX0dTUENBX1BBQzczMDIgaXMgbm90IHNldA0KIyBDT05G
SUdfVVNCX0dTUENBX1BBQzczMTEgaXMgbm90IHNldA0KIyBDT05GSUdfVVNC
X0dTUENBX1NFNDAxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9HU1BDQV9T
TjlDMjAyOCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfR1NQQ0FfU045QzIw
WCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfR1NQQ0FfU09OSVhCIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1VTQl9HU1BDQV9TT05JWEogaXMgbm90IHNldA0K
IyBDT05GSUdfVVNCX0dTUENBX1NQQ0E1MDAgaXMgbm90IHNldA0KIyBDT05G
SUdfVVNCX0dTUENBX1NQQ0E1MDEgaXMgbm90IHNldA0KIyBDT05GSUdfVVNC
X0dTUENBX1NQQ0E1MDUgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dTUENB
X1NQQ0E1MDYgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dTUENBX1NQQ0E1
MDggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dTUENBX1NQQ0E1NjEgaXMg
bm90IHNldA0KIyBDT05GSUdfVVNCX0dTUENBX1NQQ0ExNTI4IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1VTQl9HU1BDQV9TUTkwNSBpcyBub3Qgc2V0DQojIENP
TkZJR19VU0JfR1NQQ0FfU1E5MDVDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT
Ql9HU1BDQV9TUTkzMFggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dTUENB
X1NUSzAxNCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfR1NQQ0FfU1RLMTEz
NSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfR1NQQ0FfU1RWMDY4MCBpcyBu
b3Qgc2V0DQojIENPTkZJR19VU0JfR1NQQ0FfU1VOUExVUyBpcyBub3Qgc2V0
DQojIENPTkZJR19VU0JfR1NQQ0FfVDYxMyBpcyBub3Qgc2V0DQojIENPTkZJ
R19VU0JfR1NQQ0FfVE9QUk8gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dT
UENBX1RPVVBURUsgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dTUENBX1RW
ODUzMiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfR1NQQ0FfVkMwMzJYIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9HU1BDQV9WSUNBTSBpcyBub3Qgc2V0
DQojIENPTkZJR19VU0JfR1NQQ0FfWElSTElOS19DSVQgaXMgbm90IHNldA0K
IyBDT05GSUdfVVNCX0dTUENBX1pDM1hYIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1VTQl9QV0MgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fQ1BJQTIgaXMg
bm90IHNldA0KIyBDT05GSUdfVVNCX1pSMzY0WFggaXMgbm90IHNldA0KIyBD
T05GSUdfVVNCX1NUS1dFQkNBTSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf
UzIyNTUgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fVVNCVFYgaXMgbm90
IHNldA0KDQojDQojIFdlYmNhbSwgVFYgKGFuYWxvZy9kaWdpdGFsKSBVU0Ig
ZGV2aWNlcw0KIw0KIyBDT05GSUdfVklERU9fRU0yOFhYIGlzIG5vdCBzZXQN
CkNPTkZJR19WNExfUExBVEZPUk1fRFJJVkVSUz15DQojIENPTkZJR19WSURF
T19DQURFTkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX0FTUEVFRCBp
cyBub3Qgc2V0DQojIENPTkZJR19WSURFT19NVVggaXMgbm90IHNldA0KQ09O
RklHX1ZJREVPX1hJTElOWD15DQpDT05GSUdfVklERU9fWElMSU5YX1RQRz15
DQpDT05GSUdfVklERU9fWElMSU5YX1ZUQz15DQojIENPTkZJR19WNExfTUVN
Mk1FTV9EUklWRVJTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1Y0TF9URVNUX0RS
SVZFUlMgaXMgbm90IHNldA0KDQojDQojIFN1cHBvcnRlZCBNTUMvU0RJTyBh
ZGFwdGVycw0KIw0KIyBDT05GSUdfQ1lQUkVTU19GSVJNV0FSRSBpcyBub3Qg
c2V0DQpDT05GSUdfVklERU9CVUYyX0NPUkU9eQ0KQ09ORklHX1ZJREVPQlVG
Ml9WNEwyPXkNCkNPTkZJR19WSURFT0JVRjJfTUVNT1BTPXkNCkNPTkZJR19W
SURFT0JVRjJfRE1BX0NPTlRJRz15DQpDT05GSUdfVklERU9CVUYyX1ZNQUxM
T0M9eQ0KDQojDQojIE1lZGlhIGFuY2lsbGFyeSBkcml2ZXJzICh0dW5lcnMs
IHNlbnNvcnMsIGkyYywgc3BpLCBmcm9udGVuZHMpDQojDQpDT05GSUdfTUVE
SUFfU1VCRFJWX0FVVE9TRUxFQ1Q9eQ0KDQojDQojIEkyQyBFbmNvZGVycywg
ZGVjb2RlcnMsIHNlbnNvcnMgYW5kIG90aGVyIGhlbHBlciBjaGlwcw0KIw0K
DQojDQojIEF1ZGlvIGRlY29kZXJzLCBwcm9jZXNzb3JzIGFuZCBtaXhlcnMN
CiMNCiMgQ09ORklHX1ZJREVPX1RWQVVESU8gaXMgbm90IHNldA0KIyBDT05G
SUdfVklERU9fVERBNzQzMiBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19U
REE5ODQwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX1REQTE5OTdYIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX1RFQTY0MTVDIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1ZJREVPX1RFQTY0MjAgaXMgbm90IHNldA0KIyBDT05GSUdf
VklERU9fTVNQMzQwMCBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19DUzMz
MDggaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fQ1M1MzQ1IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1ZJREVPX0NTNTNMMzJBIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1ZJREVPX1RMVjMyMEFJQzIzQiBpcyBub3Qgc2V0DQojIENPTkZJR19W
SURFT19VREExMzQyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX1dNODc3
NSBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19XTTg3MzkgaXMgbm90IHNl
dA0KIyBDT05GSUdfVklERU9fVlAyN1NNUFggaXMgbm90IHNldA0KIyBDT05G
SUdfVklERU9fU09OWV9CVEZfTVBYIGlzIG5vdCBzZXQNCg0KIw0KIyBSRFMg
ZGVjb2RlcnMNCiMNCiMgQ09ORklHX1ZJREVPX1NBQTY1ODggaXMgbm90IHNl
dA0KDQojDQojIFZpZGVvIGRlY29kZXJzDQojDQojIENPTkZJR19WSURFT19B
RFY3MTgwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX0FEVjcxODMgaXMg
bm90IHNldA0KIyBDT05GSUdfVklERU9fQURWNzQ4WCBpcyBub3Qgc2V0DQoj
IENPTkZJR19WSURFT19BRFY3NjA0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJ
REVPX0FEVjc4NDIgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fQlQ4MTkg
aXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fQlQ4NTYgaXMgbm90IHNldA0K
IyBDT05GSUdfVklERU9fQlQ4NjYgaXMgbm90IHNldA0KIyBDT05GSUdfVklE
RU9fS1MwMTI3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX01MODZWNzY2
NyBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19TQUE3MTEwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1ZJREVPX1NBQTcxMVggaXMgbm90IHNldA0KIyBDT05G
SUdfVklERU9fVEMzNTg3NDMgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9f
VFZQNTE0WCBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19UVlA1MTUwIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX1RWUDcwMDIgaXMgbm90IHNldA0K
IyBDT05GSUdfVklERU9fVFcyODA0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJ
REVPX1RXOTkwMyBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19UVzk5MDYg
aXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fVFc5OTEwIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1ZJREVPX1ZQWDMyMjAgaXMgbm90IHNldA0KDQojDQojIFZp
ZGVvIGFuZCBhdWRpbyBkZWNvZGVycw0KIw0KIyBDT05GSUdfVklERU9fU0FB
NzE3WCBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19DWDI1ODQwIGlzIG5v
dCBzZXQNCg0KIw0KIyBWaWRlbyBlbmNvZGVycw0KIw0KIyBDT05GSUdfVklE
RU9fU0FBNzEyNyBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19TQUE3MTg1
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX0FEVjcxNzAgaXMgbm90IHNl
dA0KIyBDT05GSUdfVklERU9fQURWNzE3NSBpcyBub3Qgc2V0DQojIENPTkZJ
R19WSURFT19BRFY3MzQzIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX0FE
VjczOTMgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fQURWNzUxMSBpcyBu
b3Qgc2V0DQojIENPTkZJR19WSURFT19BRDkzODlCIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1ZJREVPX0FLODgxWCBpcyBub3Qgc2V0DQojIENPTkZJR19WSURF
T19USFM4MjAwIGlzIG5vdCBzZXQNCg0KIw0KIyBDYW1lcmEgc2Vuc29yIGRl
dmljZXMNCiMNCiMgQ09ORklHX1ZJREVPX0hJNTU2IGlzIG5vdCBzZXQNCiMg
Q09ORklHX1ZJREVPX0lNWDIxNCBpcyBub3Qgc2V0DQojIENPTkZJR19WSURF
T19JTVgyNTggaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fSU1YMjc0IGlz
IG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX0lNWDI5MCBpcyBub3Qgc2V0DQoj
IENPTkZJR19WSURFT19JTVgzMTkgaXMgbm90IHNldA0KIyBDT05GSUdfVklE
RU9fSU1YMzU1IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX09WMjY0MCBp
cyBub3Qgc2V0DQojIENPTkZJR19WSURFT19PVjI2NTkgaXMgbm90IHNldA0K
IyBDT05GSUdfVklERU9fT1YyNjgwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJ
REVPX09WMjY4NSBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19PVjU2NDAg
aXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fT1Y1NjQ1IGlzIG5vdCBzZXQN
CiMgQ09ORklHX1ZJREVPX09WNTY0NyBpcyBub3Qgc2V0DQojIENPTkZJR19W
SURFT19PVjY2NTAgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fT1Y1Njcw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX09WNTY3NSBpcyBub3Qgc2V0
DQojIENPTkZJR19WSURFT19PVjU2OTUgaXMgbm90IHNldA0KIyBDT05GSUdf
VklERU9fT1Y3MjUxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX09WNzcy
WCBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19PVjc2NDAgaXMgbm90IHNl
dA0KIyBDT05GSUdfVklERU9fT1Y3NjcwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1ZJREVPX09WNzc0MCBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19PVjg4
NTYgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fT1Y5NjQwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1ZJREVPX09WOTY1MCBpcyBub3Qgc2V0DQojIENPTkZJ
R19WSURFT19PVjEzODU4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX1ZT
NjYyNCBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19NVDlNMDAxIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1ZJREVPX01UOU0wMzIgaXMgbm90IHNldA0KIyBD
T05GSUdfVklERU9fTVQ5TTExMSBpcyBub3Qgc2V0DQojIENPTkZJR19WSURF
T19NVDlQMDMxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX01UOVQwMDEg
aXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fTVQ5VDExMiBpcyBub3Qgc2V0
DQojIENPTkZJR19WSURFT19NVDlWMDExIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1ZJREVPX01UOVYwMzIgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fTVQ5
VjExMSBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19TUjAzMFBDMzAgaXMg
bm90IHNldA0KIyBDT05GSUdfVklERU9fTk9PTjAxMFBDMzAgaXMgbm90IHNl
dA0KIyBDT05GSUdfVklERU9fTTVNT0xTIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1ZJREVPX1JKNTROMSBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19TNUs2
QUEgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fUzVLNkEzIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1ZJREVPX1M1SzRFQ0dYIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1ZJREVPX1M1SzVCQUYgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9f
U01JQVBQIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX0VUOEVLOCBpcyBu
b3Qgc2V0DQojIENPTkZJR19WSURFT19TNUM3M00zIGlzIG5vdCBzZXQNCg0K
Iw0KIyBMZW5zIGRyaXZlcnMNCiMNCiMgQ09ORklHX1ZJREVPX0FENTgyMCBp
cyBub3Qgc2V0DQojIENPTkZJR19WSURFT19BSzczNzUgaXMgbm90IHNldA0K
IyBDT05GSUdfVklERU9fRFc5NzE0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJ
REVPX0RXOTgwN19WQ00gaXMgbm90IHNldA0KDQojDQojIEZsYXNoIGRldmlj
ZXMNCiMNCiMgQ09ORklHX1ZJREVPX0FEUDE2NTMgaXMgbm90IHNldA0KIyBD
T05GSUdfVklERU9fTE0zNTYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVP
X0xNMzY0NiBpcyBub3Qgc2V0DQoNCiMNCiMgVmlkZW8gaW1wcm92ZW1lbnQg
Y2hpcHMNCiMNCiMgQ09ORklHX1ZJREVPX1VQRDY0MDMxQSBpcyBub3Qgc2V0
DQojIENPTkZJR19WSURFT19VUEQ2NDA4MyBpcyBub3Qgc2V0DQoNCiMNCiMg
QXVkaW8vVmlkZW8gY29tcHJlc3Npb24gY2hpcHMNCiMNCiMgQ09ORklHX1ZJ
REVPX1NBQTY3NTJIUyBpcyBub3Qgc2V0DQoNCiMNCiMgU0RSIHR1bmVyIGNo
aXBzDQojDQoNCiMNCiMgTWlzY2VsbGFuZW91cyBoZWxwZXIgY2hpcHMNCiMN
CiMgQ09ORklHX1ZJREVPX1RIUzczMDMgaXMgbm90IHNldA0KIyBDT05GSUdf
VklERU9fTTUyNzkwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX0kyQyBp
cyBub3Qgc2V0DQojIENPTkZJR19WSURFT19TVF9NSVBJRDAyIGlzIG5vdCBz
ZXQNCiMgZW5kIG9mIEkyQyBFbmNvZGVycywgZGVjb2RlcnMsIHNlbnNvcnMg
YW5kIG90aGVyIGhlbHBlciBjaGlwcw0KDQojDQojIFNQSSBoZWxwZXIgY2hp
cHMNCiMNCiMgQ09ORklHX1ZJREVPX0dTMTY2MiBpcyBub3Qgc2V0DQojIGVu
ZCBvZiBTUEkgaGVscGVyIGNoaXBzDQoNCiMNCiMgTWVkaWEgU1BJIEFkYXB0
ZXJzDQojDQojIGVuZCBvZiBNZWRpYSBTUEkgQWRhcHRlcnMNCg0KIw0KIyBD
dXN0b21pc2UgRFZCIEZyb250ZW5kcw0KIw0KDQojDQojIFRvb2xzIHRvIGRl
dmVsb3AgbmV3IGZyb250ZW5kcw0KIw0KIyBlbmQgb2YgQ3VzdG9taXNlIERW
QiBGcm9udGVuZHMNCg0KIw0KIyBHcmFwaGljcyBzdXBwb3J0DQojDQpDT05G
SUdfRFJNPXkNCiMgQ09ORklHX0RSTV9EUF9BVVhfQ0hBUkRFViBpcyBub3Qg
c2V0DQojIENPTkZJR19EUk1fREVCVUdfTU0gaXMgbm90IHNldA0KIyBDT05G
SUdfRFJNX0RFQlVHX1NFTEZURVNUIGlzIG5vdCBzZXQNCkNPTkZJR19EUk1f
S01TX0hFTFBFUj15DQpDT05GSUdfRFJNX0tNU19GQl9IRUxQRVI9eQ0KIyBD
T05GSUdfRFJNX0RFQlVHX0RQX01TVF9UT1BPTE9HWV9SRUZTIGlzIG5vdCBz
ZXQNCkNPTkZJR19EUk1fRkJERVZfRU1VTEFUSU9OPXkNCkNPTkZJR19EUk1f
RkJERVZfT1ZFUkFMTE9DPTEwMA0KIyBDT05GSUdfRFJNX0ZCREVWX0xFQUtf
UEhZU19TTUVNIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9MT0FEX0VESURf
RklSTVdBUkUgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX0RQX0NFQyBpcyBu
b3Qgc2V0DQpDT05GSUdfRFJNX0dFTV9DTUFfSEVMUEVSPXkNCkNPTkZJR19E
Uk1fS01TX0NNQV9IRUxQRVI9eQ0KDQojDQojIEkyQyBlbmNvZGVyIG9yIGhl
bHBlciBjaGlwcw0KIw0KIyBDT05GSUdfRFJNX0kyQ19DSDcwMDYgaXMgbm90
IHNldA0KIyBDT05GSUdfRFJNX0kyQ19TSUwxNjQgaXMgbm90IHNldA0KIyBD
T05GSUdfRFJNX0kyQ19OWFBfVERBOTk4WCBpcyBub3Qgc2V0DQojIENPTkZJ
R19EUk1fSTJDX05YUF9UREE5OTUwIGlzIG5vdCBzZXQNCiMgZW5kIG9mIEky
QyBlbmNvZGVyIG9yIGhlbHBlciBjaGlwcw0KDQojDQojIEFSTSBkZXZpY2Vz
DQojDQojIENPTkZJR19EUk1fSERMQ0QgaXMgbm90IHNldA0KQ09ORklHX0RS
TV9NQUxJX0RJU1BMQVk9eQ0KIyBDT05GSUdfRFJNX0tPTUVEQSBpcyBub3Qg
c2V0DQojIGVuZCBvZiBBUk0gZGV2aWNlcw0KDQojDQojIEFDUCAoQXVkaW8g
Q29Qcm9jZXNzb3IpIENvbmZpZ3VyYXRpb24NCiMNCiMgZW5kIG9mIEFDUCAo
QXVkaW8gQ29Qcm9jZXNzb3IpIENvbmZpZ3VyYXRpb24NCg0KIyBDT05GSUdf
RFJNX1ZHRU0gaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX1ZLTVMgaXMgbm90
IHNldA0KIyBDT05GSUdfRFJNX1VETCBpcyBub3Qgc2V0DQojIENPTkZJR19E
Uk1fUkNBUl9EV19IRE1JIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9SQ0FS
X0xWRFMgaXMgbm90IHNldA0KQ09ORklHX0RSTV9SQ0FSX1dSSVRFQkFDSz15
DQojIENPTkZJR19EUk1fVklSVElPX0dQVSBpcyBub3Qgc2V0DQpDT05GSUdf
RFJNX1BBTkVMPXkNCg0KIw0KIyBEaXNwbGF5IFBhbmVscw0KIw0KIyBDT05G
SUdfRFJNX1BBTkVMX0xWRFMgaXMgbm90IHNldA0KQ09ORklHX0RSTV9QQU5F
TF9TSU1QTEU9eQ0KIyBDT05GSUdfRFJNX1BBTkVMX0lMSVRFS19JTDkzMjIg
aXMgbm90IHNldA0KIyBDT05GSUdfRFJNX1BBTkVMX1NBTVNVTkdfTEQ5MDQw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9QQU5FTF9MR19MQjAzNVEwMiBp
cyBub3Qgc2V0DQojIENPTkZJR19EUk1fUEFORUxfTEdfTEc0NTczIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0RSTV9QQU5FTF9ORUNfTkw4MDQ4SEwxMSBpcyBu
b3Qgc2V0DQojIENPTkZJR19EUk1fUEFORUxfTk9WQVRFS19OVDM5MDE2IGlz
IG5vdCBzZXQNCiMgQ09ORklHX0RSTV9QQU5FTF9PTElNRVhfTENEX09MSU5V
WElOTyBpcyBub3Qgc2V0DQojIENPTkZJR19EUk1fUEFORUxfU0FNU1VOR19T
NkU2M00wIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9QQU5FTF9TQU1TVU5H
X1M2RThBQTAgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX1BBTkVMX1NFSUtP
XzQzV1ZGMUcgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX1BBTkVMX1NIQVJQ
X0xTMDM3VjdEVzAxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9QQU5FTF9T
SVRST05JWF9TVDc3ODlWIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9QQU5F
TF9TT05ZX0FDWDU2NUFLTSBpcyBub3Qgc2V0DQojIENPTkZJR19EUk1fUEFO
RUxfVFBPX1REMDI4VFRFQzEgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX1BB
TkVMX1RQT19URDA0M01URUExIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9Q
QU5FTF9UUE9fVFBHMTEwIGlzIG5vdCBzZXQNCiMgZW5kIG9mIERpc3BsYXkg
UGFuZWxzDQoNCkNPTkZJR19EUk1fQlJJREdFPXkNCkNPTkZJR19EUk1fUEFO
RUxfQlJJREdFPXkNCg0KIw0KIyBEaXNwbGF5IEludGVyZmFjZSBCcmlkZ2Vz
DQojDQojIENPTkZJR19EUk1fQ0ROU19EU0kgaXMgbm90IHNldA0KIyBDT05G
SUdfRFJNX0RVTUJfVkdBX0RBQyBpcyBub3Qgc2V0DQojIENPTkZJR19EUk1f
TFZEU19DT0RFQyBpcyBub3Qgc2V0DQojIENPTkZJR19EUk1fTUVHQUNISVBT
X1NURFBYWFhYX0dFX0I4NTBWM19GVyBpcyBub3Qgc2V0DQojIENPTkZJR19E
Uk1fTlhQX1BUTjM0NjAgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX1BBUkFE
RV9QUzg2MjIgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX1NJTF9TSUk4NjIw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9TSUk5MDJYIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0RSTV9TSUk5MjM0IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RS
TV9USElORV9USEM2M0xWRDEwMjQgaXMgbm90IHNldA0KIyBDT05GSUdfRFJN
X1RPU0hJQkFfVEMzNTg3NjQgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX1RP
U0hJQkFfVEMzNTg3NjcgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX1RJX1RG
UDQxMCBpcyBub3Qgc2V0DQojIENPTkZJR19EUk1fVElfU042NURTSTg2IGlz
IG5vdCBzZXQNCiMgQ09ORklHX0RSTV9BTkFMT0dJWF9BTlg2MzQ1IGlzIG5v
dCBzZXQNCiMgQ09ORklHX0RSTV9BTkFMT0dJWF9BTlg3OFhYIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0RSTV9JMkNfQURWNzUxMSBpcyBub3Qgc2V0DQojIGVu
ZCBvZiBEaXNwbGF5IEludGVyZmFjZSBCcmlkZ2VzDQoNCiMgQ09ORklHX0RS
TV9FVE5BVklWIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9BUkNQR1UgaXMg
bm90IHNldA0KIyBDT05GSUdfRFJNX0hJU0lfS0lSSU4gaXMgbm90IHNldA0K
IyBDT05GSUdfRFJNX01YU0ZCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9H
TTEyVTMyMCBpcyBub3Qgc2V0DQojIENPTkZJR19USU5ZRFJNX0hYODM1N0Qg
aXMgbm90IHNldA0KIyBDT05GSUdfVElOWURSTV9JTEk5MjI1IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1RJTllEUk1fSUxJOTM0MSBpcyBub3Qgc2V0DQojIENP
TkZJR19USU5ZRFJNX01JMDI4M1FUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RJ
TllEUk1fUkVQQVBFUiBpcyBub3Qgc2V0DQojIENPTkZJR19USU5ZRFJNX1NU
NzU4NiBpcyBub3Qgc2V0DQojIENPTkZJR19USU5ZRFJNX1NUNzczNVIgaXMg
bm90IHNldA0KIyBDT05GSUdfRFJNX1BMMTExIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0RSTV9YRU4gaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX0xJTUEgaXMg
bm90IHNldA0KIyBDT05GSUdfRFJNX1BBTkZST1NUIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0RSTV9MRUdBQ1kgaXMgbm90IHNldA0KQ09ORklHX0RSTV9QQU5F
TF9PUklFTlRBVElPTl9RVUlSS1M9eQ0KDQojDQojIEZyYW1lIGJ1ZmZlciBE
ZXZpY2VzDQojDQpDT05GSUdfRkJfQ01ETElORT15DQpDT05GSUdfRkJfTk9U
SUZZPXkNCkNPTkZJR19GQj15DQojIENPTkZJR19GSVJNV0FSRV9FRElEIGlz
IG5vdCBzZXQNCkNPTkZJR19GQl9DRkJfRklMTFJFQ1Q9eQ0KQ09ORklHX0ZC
X0NGQl9DT1BZQVJFQT15DQpDT05GSUdfRkJfQ0ZCX0lNQUdFQkxJVD15DQpD
T05GSUdfRkJfU1lTX0ZJTExSRUNUPXkNCkNPTkZJR19GQl9TWVNfQ09QWUFS
RUE9eQ0KQ09ORklHX0ZCX1NZU19JTUFHRUJMSVQ9eQ0KIyBDT05GSUdfRkJf
Rk9SRUlHTl9FTkRJQU4gaXMgbm90IHNldA0KQ09ORklHX0ZCX1NZU19GT1BT
PXkNCkNPTkZJR19GQl9ERUZFUlJFRF9JTz15DQojIENPTkZJR19GQl9NT0RF
X0hFTFBFUlMgaXMgbm90IHNldA0KIyBDT05GSUdfRkJfVElMRUJMSVRUSU5H
IGlzIG5vdCBzZXQNCg0KIw0KIyBGcmFtZSBidWZmZXIgaGFyZHdhcmUgZHJp
dmVycw0KIw0KIyBDT05GSUdfRkJfQVJNQ0xDRCBpcyBub3Qgc2V0DQojIENP
TkZJR19GQl9VVkVTQSBpcyBub3Qgc2V0DQojIENPTkZJR19GQl9FRkkgaXMg
bm90IHNldA0KIyBDT05GSUdfRkJfT1BFTkNPUkVTIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0ZCX1MxRDEzWFhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZCX1NN
U0NVRlggaXMgbm90IHNldA0KIyBDT05GSUdfRkJfVURMIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0ZCX0lCTV9HWFQ0NTAwIGlzIG5vdCBzZXQNCkNPTkZJR19G
Ql9YSUxJTlg9eQ0KIyBDT05GSUdfRkJfVklSVFVBTCBpcyBub3Qgc2V0DQpD
T05GSUdfWEVOX0ZCREVWX0ZST05URU5EPXkNCiMgQ09ORklHX0ZCX01FVFJP
Tk9NRSBpcyBub3Qgc2V0DQpDT05GSUdfRkJfU0lNUExFPXkNCiMgQ09ORklH
X0ZCX1NTRDEzMDcgaXMgbm90IHNldA0KIyBlbmQgb2YgRnJhbWUgYnVmZmVy
IERldmljZXMNCg0KIw0KIyBCYWNrbGlnaHQgJiBMQ0QgZGV2aWNlIHN1cHBv
cnQNCiMNCkNPTkZJR19MQ0RfQ0xBU1NfREVWSUNFPW0NCiMgQ09ORklHX0xD
RF9MNEYwMDI0MlQwMyBpcyBub3Qgc2V0DQojIENPTkZJR19MQ0RfTE1TMjgz
R0YwNSBpcyBub3Qgc2V0DQojIENPTkZJR19MQ0RfTFRWMzUwUVYgaXMgbm90
IHNldA0KIyBDT05GSUdfTENEX0lMSTkyMlggaXMgbm90IHNldA0KIyBDT05G
SUdfTENEX0lMSTkzMjAgaXMgbm90IHNldA0KIyBDT05GSUdfTENEX1RETzI0
TSBpcyBub3Qgc2V0DQojIENPTkZJR19MQ0RfVkdHMjQzMkE0IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0xDRF9QTEFURk9STSBpcyBub3Qgc2V0DQojIENPTkZJ
R19MQ0RfQU1TMzY5RkcwNiBpcyBub3Qgc2V0DQojIENPTkZJR19MQ0RfTE1T
NTAxS0YwMyBpcyBub3Qgc2V0DQojIENPTkZJR19MQ0RfSFg4MzU3IGlzIG5v
dCBzZXQNCiMgQ09ORklHX0xDRF9PVE0zMjI1QSBpcyBub3Qgc2V0DQpDT05G
SUdfQkFDS0xJR0hUX0NMQVNTX0RFVklDRT15DQpDT05GSUdfQkFDS0xJR0hU
X0dFTkVSSUM9eQ0KIyBDT05GSUdfQkFDS0xJR0hUX1FDT01fV0xFRCBpcyBu
b3Qgc2V0DQojIENPTkZJR19CQUNLTElHSFRfQURQODg2MCBpcyBub3Qgc2V0
DQojIENPTkZJR19CQUNLTElHSFRfQURQODg3MCBpcyBub3Qgc2V0DQojIENP
TkZJR19CQUNLTElHSFRfTE0zNjM5IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JB
Q0tMSUdIVF9HUElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JBQ0tMSUdIVF9M
VjUyMDdMUCBpcyBub3Qgc2V0DQojIENPTkZJR19CQUNLTElHSFRfQkQ2MTA3
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JBQ0tMSUdIVF9BUkNYQ05OIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0JBQ0tMSUdIVF9MRUQgaXMgbm90IHNldA0KIyBl
bmQgb2YgQmFja2xpZ2h0ICYgTENEIGRldmljZSBzdXBwb3J0DQoNCkNPTkZJ
R19WSURFT01PREVfSEVMUEVSUz15DQpDT05GSUdfSERNST15DQoNCiMNCiMg
Q29uc29sZSBkaXNwbGF5IGRyaXZlciBzdXBwb3J0DQojDQpDT05GSUdfRFVN
TVlfQ09OU09MRT15DQpDT05GSUdfRFVNTVlfQ09OU09MRV9DT0xVTU5TPTgw
DQpDT05GSUdfRFVNTVlfQ09OU09MRV9ST1dTPTI1DQpDT05GSUdfRlJBTUVC
VUZGRVJfQ09OU09MRT15DQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRV9E
RVRFQ1RfUFJJTUFSWT15DQojIENPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xF
X1JPVEFUSU9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZSQU1FQlVGRkVSX0NP
TlNPTEVfREVGRVJSRURfVEFLRU9WRVIgaXMgbm90IHNldA0KIyBlbmQgb2Yg
Q29uc29sZSBkaXNwbGF5IGRyaXZlciBzdXBwb3J0DQoNCiMgQ09ORklHX0xP
R08gaXMgbm90IHNldA0KIyBlbmQgb2YgR3JhcGhpY3Mgc3VwcG9ydA0KDQpD
T05GSUdfU09VTkQ9eQ0KQ09ORklHX1NORD15DQpDT05GSUdfU05EX1RJTUVS
PXkNCkNPTkZJR19TTkRfUENNPXkNCkNPTkZJR19TTkRfSFdERVA9eQ0KQ09O
RklHX1NORF9SQVdNSURJPXkNCkNPTkZJR19TTkRfSkFDSz15DQpDT05GSUdf
U05EX0pBQ0tfSU5QVVRfREVWPXkNCiMgQ09ORklHX1NORF9PU1NFTVVMIGlz
IG5vdCBzZXQNCkNPTkZJR19TTkRfUENNX1RJTUVSPXkNCiMgQ09ORklHX1NO
RF9IUlRJTUVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9EWU5BTUlDX01J
Tk9SUyBpcyBub3Qgc2V0DQpDT05GSUdfU05EX1NVUFBPUlRfT0xEX0FQST15
DQpDT05GSUdfU05EX1BST0NfRlM9eQ0KQ09ORklHX1NORF9WRVJCT1NFX1BS
T0NGUz15DQojIENPTkZJR19TTkRfVkVSQk9TRV9QUklOVEsgaXMgbm90IHNl
dA0KIyBDT05GSUdfU05EX0RFQlVHIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NO
RF9TRVFVRU5DRVIgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX0RSSVZFUlMg
aXMgbm90IHNldA0KDQojDQojIEhELUF1ZGlvDQojDQojIGVuZCBvZiBIRC1B
dWRpbw0KDQpDT05GSUdfU05EX0hEQV9QUkVBTExPQ19TSVpFPTY0DQpDT05G
SUdfU05EX1NQST15DQpDT05GSUdfU05EX1VTQj15DQpDT05GSUdfU05EX1VT
Ql9BVURJTz15DQpDT05GSUdfU05EX1VTQl9BVURJT19VU0VfTUVESUFfQ09O
VFJPTExFUj15DQojIENPTkZJR19TTkRfVVNCX1VBMTAxIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1NORF9VU0JfQ0FJQVEgaXMgbm90IHNldA0KIyBDT05GSUdf
U05EX1VTQl82RklSRSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfVVNCX0hJ
RkFDRSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfQkNEMjAwMCBpcyBub3Qg
c2V0DQojIENPTkZJR19TTkRfVVNCX1BPRCBpcyBub3Qgc2V0DQojIENPTkZJ
R19TTkRfVVNCX1BPREhEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9VU0Jf
VE9ORVBPUlQgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1VTQl9WQVJJQVgg
aXMgbm90IHNldA0KQ09ORklHX1NORF9TT0M9eQ0KIyBDT05GSUdfU05EX1NP
Q19BTURfQUNQIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9BVE1FTF9TT0Mg
aXMgbm90IHNldA0KIyBDT05GSUdfU05EX0RFU0lHTldBUkVfSTJTIGlzIG5v
dCBzZXQNCg0KIw0KIyBTb0MgQXVkaW8gZm9yIEZyZWVzY2FsZSBDUFVzDQoj
DQoNCiMNCiMgQ29tbW9uIFNvQyBBdWRpbyBvcHRpb25zIGZvciBGcmVlc2Nh
bGUgQ1BVczoNCiMNCiMgQ09ORklHX1NORF9TT0NfRlNMX0FTUkMgaXMgbm90
IHNldA0KIyBDT05GSUdfU05EX1NPQ19GU0xfU0FJIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NORF9TT0NfRlNMX0FVRE1JWCBpcyBub3Qgc2V0DQojIENPTkZJ
R19TTkRfU09DX0ZTTF9TU0kgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NP
Q19GU0xfU1BESUYgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19GU0xf
RVNBSSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0ZTTF9NSUNGSUwg
aXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19JTVhfQVVETVVYIGlzIG5v
dCBzZXQNCiMgZW5kIG9mIFNvQyBBdWRpbyBmb3IgRnJlZXNjYWxlIENQVXMN
Cg0KIyBDT05GSUdfU05EX0kyU19ISTYyMTBfSTJTIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NORF9TT0NfSU1HIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9T
T0NfTVRLX0JUQ1ZTRCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1NP
Rl9UT1BMRVZFTCBpcyBub3Qgc2V0DQoNCiMNCiMgU1RNaWNyb2VsZWN0cm9u
aWNzIFNUTTMyIFNPQyBhdWRpbyBzdXBwb3J0DQojDQojIGVuZCBvZiBTVE1p
Y3JvZWxlY3Ryb25pY3MgU1RNMzIgU09DIGF1ZGlvIHN1cHBvcnQNCg0KQ09O
RklHX1NORF9TT0NfWElMSU5YX0kyUz15DQpDT05GSUdfU05EX1NPQ19YSUxJ
TlhfQVVESU9fRk9STUFUVEVSPXkNCiMgQ09ORklHX1NORF9TT0NfWElMSU5Y
X1NQRElGIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfWFRGUEdBX0ky
UyBpcyBub3Qgc2V0DQojIENPTkZJR19aWF9URE0gaXMgbm90IHNldA0KQ09O
RklHX1NORF9TT0NfSTJDX0FORF9TUEk9eQ0KDQojDQojIENPREVDIGRyaXZl
cnMNCiMNCiMgQ09ORklHX1NORF9TT0NfQUM5N19DT0RFQyBpcyBub3Qgc2V0
DQojIENPTkZJR19TTkRfU09DX0FEQVUxNzAxIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NORF9TT0NfQURBVTE3NjFfSTJDIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1NORF9TT0NfQURBVTE3NjFfU1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NO
RF9TT0NfQURBVTcwMDIgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19B
REFVNzExOF9IVyBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0FEQVU3
MTE4X0kyQyBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0FLNDEwNCBp
cyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0FLNDExOCBpcyBub3Qgc2V0
DQojIENPTkZJR19TTkRfU09DX0FLNDQ1OCBpcyBub3Qgc2V0DQojIENPTkZJ
R19TTkRfU09DX0FLNDU1NCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09D
X0FLNDYxMyBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0FLNDY0MiBp
cyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0FLNTM4NiBpcyBub3Qgc2V0
DQojIENPTkZJR19TTkRfU09DX0FLNTU1OCBpcyBub3Qgc2V0DQojIENPTkZJ
R19TTkRfU09DX0FMQzU2MjMgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NP
Q19CRDI4NjIzIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfQlRfU0NP
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfQ1MzNUwzMiBpcyBub3Qg
c2V0DQojIENPTkZJR19TTkRfU09DX0NTMzVMMzMgaXMgbm90IHNldA0KIyBD
T05GSUdfU05EX1NPQ19DUzM1TDM0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NO
RF9TT0NfQ1MzNUwzNSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0NT
MzVMMzYgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19DUzQyTDQyIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfQ1M0Mkw1MV9JMkMgaXMgbm90
IHNldA0KIyBDT05GSUdfU05EX1NPQ19DUzQyTDUyIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NORF9TT0NfQ1M0Mkw1NiBpcyBub3Qgc2V0DQojIENPTkZJR19T
TkRfU09DX0NTNDJMNzMgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19D
UzQyNjUgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19DUzQyNzAgaXMg
bm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19DUzQyNzFfSTJDIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NORF9TT0NfQ1M0MjcxX1NQSSBpcyBub3Qgc2V0DQoj
IENPTkZJR19TTkRfU09DX0NTNDJYWDhfSTJDIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NORF9TT0NfQ1M0MzEzMCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRf
U09DX0NTNDM0MSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0NTNDM0
OSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0NTNTNMMzAgaXMgbm90
IHNldA0KIyBDT05GSUdfU05EX1NPQ19DWDIwNzJYIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NORF9TT0NfREE3MjEzIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NO
RF9TT0NfRE1JQyBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0VTNzEz
NCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX0VTNzI0MSBpcyBub3Qg
c2V0DQojIENPTkZJR19TTkRfU09DX0VTODMxNiBpcyBub3Qgc2V0DQojIENP
TkZJR19TTkRfU09DX0VTODMyOF9JMkMgaXMgbm90IHNldA0KIyBDT05GSUdf
U05EX1NPQ19FUzgzMjhfU1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9T
T0NfR1RNNjAxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfSU5OT19S
SzMwMzYgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19NQVg5ODA4OCBp
cyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX01BWDk4MzU3QSBpcyBub3Qg
c2V0DQojIENPTkZJR19TTkRfU09DX01BWDk4NTA0IGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NORF9TT0NfTUFYOTg2NyBpcyBub3Qgc2V0DQojIENPTkZJR19T
TkRfU09DX01BWDk4OTI3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0Nf
TUFYOTgzNzMgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19NQVg5ODYw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfTVNNODkxNl9XQ0RfRElH
SVRBTCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1BDTTE2ODEgaXMg
bm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19QQ00xNzg5X0kyQyBpcyBub3Qg
c2V0DQojIENPTkZJR19TTkRfU09DX1BDTTE3OVhfSTJDIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1NORF9TT0NfUENNMTc5WF9TUEkgaXMgbm90IHNldA0KIyBD
T05GSUdfU05EX1NPQ19QQ00xODZYX0kyQyBpcyBub3Qgc2V0DQojIENPTkZJ
R19TTkRfU09DX1BDTTE4NlhfU1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NO
RF9TT0NfUENNMzA2MF9JMkMgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NP
Q19QQ00zMDYwX1NQSSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1BD
TTMxNjhBX0kyQyBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1BDTTMx
NjhBX1NQSSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1BDTTUxMnhf
STJDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfUENNNTEyeF9TUEkg
aXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19SSzMzMjggaXMgbm90IHNl
dA0KIyBDT05GSUdfU05EX1NPQ19SVDU2MTYgaXMgbm90IHNldA0KIyBDT05G
SUdfU05EX1NPQ19SVDU2MzEgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NP
Q19TR1RMNTAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1NJTVBM
RV9BTVBMSUZJRVIgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19TSVJG
X0FVRElPX0NPREVDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfU1BE
SUYgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19TU00yMzA1IGlzIG5v
dCBzZXQNCiMgQ09ORklHX1NORF9TT0NfU1NNMjYwMl9TUEkgaXMgbm90IHNl
dA0KIyBDT05GSUdfU05EX1NPQ19TU00yNjAyX0kyQyBpcyBub3Qgc2V0DQoj
IENPTkZJR19TTkRfU09DX1NTTTQ1NjcgaXMgbm90IHNldA0KIyBDT05GSUdf
U05EX1NPQ19TVEEzMlggaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19T
VEEzNTAgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19TVElfU0FTIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfVEFTMjU1MiBpcyBub3Qgc2V0
DQojIENPTkZJR19TTkRfU09DX1RBUzI1NjIgaXMgbm90IHNldA0KIyBDT05G
SUdfU05EX1NPQ19UQVMyNzcwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9T
T0NfVEFTNTA4NiBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1RBUzU3
MVggaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19UQVM1NzIwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1NORF9TT0NfVEFTNjQyNCBpcyBub3Qgc2V0DQoj
IENPTkZJR19TTkRfU09DX1REQTc0MTkgaXMgbm90IHNldA0KIyBDT05GSUdf
U05EX1NPQ19URkE5ODc5IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0Nf
VExWMzIwQUlDMjNfSTJDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0Nf
VExWMzIwQUlDMjNfU1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0Nf
VExWMzIwQUlDMzFYWCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1RM
VjMyMEFJQzMyWDRfSTJDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0Nf
VExWMzIwQUlDMzJYNF9TUEkgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NP
Q19UTFYzMjBBSUMzWCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1RT
M0EyMjdFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfVFNDUzQyWFgg
aXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19UU0NTNDU0IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NORF9TT0NfVURBMTMzNCBpcyBub3Qgc2V0DQojIENP
TkZJR19TTkRfU09DX1dNODUxMCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRf
U09DX1dNODUyMyBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1dNODUy
NCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1dNODU4MCBpcyBub3Qg
c2V0DQojIENPTkZJR19TTkRfU09DX1dNODcxMSBpcyBub3Qgc2V0DQojIENP
TkZJR19TTkRfU09DX1dNODcyOCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRf
U09DX1dNODczMSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1dNODcz
NyBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1dNODc0MSBpcyBub3Qg
c2V0DQojIENPTkZJR19TTkRfU09DX1dNODc1MCBpcyBub3Qgc2V0DQojIENP
TkZJR19TTkRfU09DX1dNODc1MyBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRf
U09DX1dNODc3MCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1dNODc3
NiBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX1dNODc4MiBpcyBub3Qg
c2V0DQojIENPTkZJR19TTkRfU09DX1dNODgwNF9JMkMgaXMgbm90IHNldA0K
IyBDT05GSUdfU05EX1NPQ19XTTg4MDRfU1BJIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NORF9TT0NfV004OTAzIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9T
T0NfV004OTA0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfV004OTYw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfV004OTYyIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NORF9TT0NfV004OTc0IGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NORF9TT0NfV004OTc4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9T
T0NfV004OTg1IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfWlhfQVVE
OTZQMjIgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19NQVg5NzU5IGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0NfTVQ2MzUxIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1NORF9TT0NfTVQ2MzU4IGlzIG5vdCBzZXQNCiMgQ09ORklH
X1NORF9TT0NfTVQ2NjYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TT0Nf
TkFVODU0MCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09DX05BVTg4MTAg
aXMgbm90IHNldA0KIyBDT05GSUdfU05EX1NPQ19OQVU4ODIyIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NORF9TT0NfTkFVODgyNCBpcyBub3Qgc2V0DQojIENP
TkZJR19TTkRfU09DX1RQQTYxMzBBMiBpcyBub3Qgc2V0DQojIGVuZCBvZiBD
T0RFQyBkcml2ZXJzDQoNCiMgQ09ORklHX1NORF9TSU1QTEVfQ0FSRCBpcyBu
b3Qgc2V0DQojIENPTkZJR19TTkRfQVVESU9fR1JBUEhfQ0FSRCBpcyBub3Qg
c2V0DQojIENPTkZJR19TTkRfWEVOX0ZST05URU5EIGlzIG5vdCBzZXQNCg0K
Iw0KIyBISUQgc3VwcG9ydA0KIw0KQ09ORklHX0hJRD15DQojIENPTkZJR19I
SURfQkFUVEVSWV9TVFJFTkdUSCBpcyBub3Qgc2V0DQojIENPTkZJR19ISURS
QVcgaXMgbm90IHNldA0KIyBDT05GSUdfVUhJRCBpcyBub3Qgc2V0DQpDT05G
SUdfSElEX0dFTkVSSUM9eQ0KDQojDQojIFNwZWNpYWwgSElEIGRyaXZlcnMN
CiMNCiMgQ09ORklHX0hJRF9BNFRFQ0ggaXMgbm90IHNldA0KIyBDT05GSUdf
SElEX0FDQ1VUT1VDSCBpcyBub3Qgc2V0DQojIENPTkZJR19ISURfQUNSVVgg
aXMgbm90IHNldA0KIyBDT05GSUdfSElEX0FQUExFIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0hJRF9BUFBMRUlSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9B
U1VTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9BVVJFQUwgaXMgbm90IHNl
dA0KIyBDT05GSUdfSElEX0JFTEtJTiBpcyBub3Qgc2V0DQojIENPTkZJR19I
SURfQkVUT1BfRkYgaXMgbm90IHNldA0KIyBDT05GSUdfSElEX0JJR0JFTl9G
RiBpcyBub3Qgc2V0DQojIENPTkZJR19ISURfQ0hFUlJZIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0hJRF9DSElDT05ZIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJ
RF9DT1JTQUlSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9DT1VHQVIgaXMg
bm90IHNldA0KIyBDT05GSUdfSElEX01BQ0FMTFkgaXMgbm90IHNldA0KIyBD
T05GSUdfSElEX1BST0RJS0VZUyBpcyBub3Qgc2V0DQojIENPTkZJR19ISURf
Q01FRElBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9DUkVBVElWRV9TQjA1
NDAgaXMgbm90IHNldA0KIyBDT05GSUdfSElEX0NZUFJFU1MgaXMgbm90IHNl
dA0KIyBDT05GSUdfSElEX0RSQUdPTlJJU0UgaXMgbm90IHNldA0KIyBDT05G
SUdfSElEX0VNU19GRiBpcyBub3Qgc2V0DQojIENPTkZJR19ISURfRUxBTiBp
cyBub3Qgc2V0DQojIENPTkZJR19ISURfRUxFQ09NIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0hJRF9FTE8gaXMgbm90IHNldA0KIyBDT05GSUdfSElEX0VaS0VZ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9HRU1CSVJEIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0hJRF9HRlJNIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9I
T0xURUsgaXMgbm90IHNldA0KIyBDT05GSUdfSElEX0dUNjgzUiBpcyBub3Qg
c2V0DQojIENPTkZJR19ISURfS0VZVE9VQ0ggaXMgbm90IHNldA0KIyBDT05G
SUdfSElEX0tZRSBpcyBub3Qgc2V0DQojIENPTkZJR19ISURfVUNMT0dJQyBp
cyBub3Qgc2V0DQojIENPTkZJR19ISURfV0FMVE9QIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0hJRF9WSUVXU09OSUMgaXMgbm90IHNldA0KIyBDT05GSUdfSElE
X0dZUkFUSU9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9JQ0FERSBpcyBu
b3Qgc2V0DQojIENPTkZJR19ISURfSVRFIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0hJRF9KQUJSQSBpcyBub3Qgc2V0DQojIENPTkZJR19ISURfVFdJTkhBTiBp
cyBub3Qgc2V0DQojIENPTkZJR19ISURfS0VOU0lOR1RPTiBpcyBub3Qgc2V0
DQojIENPTkZJR19ISURfTENQT1dFUiBpcyBub3Qgc2V0DQojIENPTkZJR19I
SURfTEVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9MRU5PVk8gaXMgbm90
IHNldA0KIyBDT05GSUdfSElEX0xPR0lURUNIIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0hJRF9NQUdJQ01PVVNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9N
QUxUUk9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9NQVlGTEFTSCBpcyBu
b3Qgc2V0DQojIENPTkZJR19ISURfUkVEUkFHT04gaXMgbm90IHNldA0KIyBD
T05GSUdfSElEX01JQ1JPU09GVCBpcyBub3Qgc2V0DQojIENPTkZJR19ISURf
TU9OVEVSRVkgaXMgbm90IHNldA0KIyBDT05GSUdfSElEX01VTFRJVE9VQ0gg
aXMgbm90IHNldA0KIyBDT05GSUdfSElEX05USSBpcyBub3Qgc2V0DQojIENP
TkZJR19ISURfTlRSSUcgaXMgbm90IHNldA0KIyBDT05GSUdfSElEX09SVEVL
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9QQU5USEVSTE9SRCBpcyBub3Qg
c2V0DQojIENPTkZJR19ISURfUEVOTU9VTlQgaXMgbm90IHNldA0KIyBDT05G
SUdfSElEX1BFVEFMWU5YIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9QSUNP
TENEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9QTEFOVFJPTklDUyBpcyBu
b3Qgc2V0DQojIENPTkZJR19ISURfUFJJTUFYIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0hJRF9SRVRST0RFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9ST0ND
QVQgaXMgbm90IHNldA0KIyBDT05GSUdfSElEX1NBSVRFSyBpcyBub3Qgc2V0
DQojIENPTkZJR19ISURfU0FNU1VORyBpcyBub3Qgc2V0DQojIENPTkZJR19I
SURfU09OWSBpcyBub3Qgc2V0DQojIENPTkZJR19ISURfU1BFRURMSU5LIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0hJRF9TVEVBTSBpcyBub3Qgc2V0DQojIENP
TkZJR19ISURfU1RFRUxTRVJJRVMgaXMgbm90IHNldA0KIyBDT05GSUdfSElE
X1NVTlBMVVMgaXMgbm90IHNldA0KIyBDT05GSUdfSElEX1JNSSBpcyBub3Qg
c2V0DQojIENPTkZJR19ISURfR1JFRU5BU0lBIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0hJRF9TTUFSVEpPWVBMVVMgaXMgbm90IHNldA0KIyBDT05GSUdfSElE
X1RJVk8gaXMgbm90IHNldA0KIyBDT05GSUdfSElEX1RPUFNFRUQgaXMgbm90
IHNldA0KIyBDT05GSUdfSElEX1RISU5HTSBpcyBub3Qgc2V0DQojIENPTkZJ
R19ISURfVEhSVVNUTUFTVEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJRF9V
RFJBV19QUzMgaXMgbm90IHNldA0KIyBDT05GSUdfSElEX1dBQ09NIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0hJRF9XSUlNT1RFIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0hJRF9YSU5NTyBpcyBub3Qgc2V0DQojIENPTkZJR19ISURfWkVST1BM
VVMgaXMgbm90IHNldA0KIyBDT05GSUdfSElEX1pZREFDUk9OIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0hJRF9TRU5TT1JfSFVCIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0hJRF9BTFBTIGlzIG5vdCBzZXQNCiMgZW5kIG9mIFNwZWNpYWwgSElE
IGRyaXZlcnMNCg0KIw0KIyBVU0IgSElEIHN1cHBvcnQNCiMNCkNPTkZJR19V
U0JfSElEPXkNCiMgQ09ORklHX0hJRF9QSUQgaXMgbm90IHNldA0KIyBDT05G
SUdfVVNCX0hJRERFViBpcyBub3Qgc2V0DQojIGVuZCBvZiBVU0IgSElEIHN1
cHBvcnQNCg0KIw0KIyBJMkMgSElEIHN1cHBvcnQNCiMNCiMgQ09ORklHX0ky
Q19ISUQgaXMgbm90IHNldA0KIyBlbmQgb2YgSTJDIEhJRCBzdXBwb3J0DQoj
IGVuZCBvZiBISUQgc3VwcG9ydA0KDQpDT05GSUdfVVNCX09IQ0lfTElUVExF
X0VORElBTj15DQpDT05GSUdfVVNCX1NVUFBPUlQ9eQ0KQ09ORklHX1VTQl9D
T01NT049eQ0KIyBDT05GSUdfVVNCX0xFRF9UUklHIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VTQl9VTFBJX0JVUyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf
Q09OTl9HUElPIGlzIG5vdCBzZXQNCkNPTkZJR19VU0JfQVJDSF9IQVNfSENE
PXkNCkNPTkZJR19VU0I9eQ0KQ09ORklHX1VTQl9BTk5PVU5DRV9ORVdfREVW
SUNFUz15DQoNCiMNCiMgTWlzY2VsbGFuZW91cyBVU0Igb3B0aW9ucw0KIw0K
IyBDT05GSUdfVVNCX0RFRkFVTFRfUEVSU0lTVCBpcyBub3Qgc2V0DQojIENP
TkZJR19VU0JfRFlOQU1JQ19NSU5PUlMgaXMgbm90IHNldA0KQ09ORklHX1VT
Ql9PVEc9eQ0KIyBDT05GSUdfVVNCX09UR19XSElURUxJU1QgaXMgbm90IHNl
dA0KIyBDT05GSUdfVVNCX09UR19CTEFDS0xJU1RfSFVCIGlzIG5vdCBzZXQN
CkNPTkZJR19VU0JfT1RHX0ZTTT15DQojIENPTkZJR19VU0JfTEVEU19UUklH
R0VSX1VTQlBPUlQgaXMgbm90IHNldA0KQ09ORklHX1VTQl9BVVRPU1VTUEVO
RF9ERUxBWT0yDQojIENPTkZJR19VU0JfTU9OIGlzIG5vdCBzZXQNCg0KIw0K
IyBVU0IgSG9zdCBDb250cm9sbGVyIERyaXZlcnMNCiMNCiMgQ09ORklHX1VT
Ql9DNjdYMDBfSENEIGlzIG5vdCBzZXQNCkNPTkZJR19VU0JfWEhDSV9IQ0Q9
eQ0KIyBDT05GSUdfVVNCX1hIQ0lfREJHQ0FQIGlzIG5vdCBzZXQNCkNPTkZJ
R19VU0JfWEhDSV9QTEFURk9STT15DQojIENPTkZJR19VU0JfRUhDSV9IQ0Qg
aXMgbm90IHNldA0KIyBDT05GSUdfVVNCX09YVTIxMEhQX0hDRCBpcyBub3Qg
c2V0DQojIENPTkZJR19VU0JfSVNQMTE2WF9IQ0QgaXMgbm90IHNldA0KIyBD
T05GSUdfVVNCX0ZPVEcyMTBfSENEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT
Ql9NQVgzNDIxX0hDRCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfT0hDSV9I
Q0QgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NMODExX0hDRCBpcyBub3Qg
c2V0DQojIENPTkZJR19VU0JfUjhBNjY1OTdfSENEIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VTQl9IQ0RfVEVTVF9NT0RFIGlzIG5vdCBzZXQNCg0KIw0KIyBV
U0IgRGV2aWNlIENsYXNzIGRyaXZlcnMNCiMNCiMgQ09ORklHX1VTQl9BQ00g
aXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1BSSU5URVIgaXMgbm90IHNldA0K
IyBDT05GSUdfVVNCX1dETSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfVE1D
IGlzIG5vdCBzZXQNCg0KIw0KIyBOT1RFOiBVU0JfU1RPUkFHRSBkZXBlbmRz
IG9uIFNDU0kgYnV0IEJMS19ERVZfU0QgbWF5DQojDQoNCiMNCiMgYWxzbyBi
ZSBuZWVkZWQ7IHNlZSBVU0JfU1RPUkFHRSBIZWxwIGZvciBtb3JlIGluZm8N
CiMNCkNPTkZJR19VU0JfU1RPUkFHRT15DQojIENPTkZJR19VU0JfU1RPUkFH
RV9ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9SRUFM
VEVLIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TVE9SQUdFX0RBVEFGQUIg
aXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfRlJFRUNPTSBpcyBu
b3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9JU0QyMDAgaXMgbm90IHNl
dA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfVVNCQVQgaXMgbm90IHNldA0KIyBD
T05GSUdfVVNCX1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQNCiMgQ09ORklH
X1VTQl9TVE9SQUdFX1NERFI1NSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf
U1RPUkFHRV9KVU1QU0hPVCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RP
UkFHRV9BTEFVREEgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0Vf
T05FVE9VQ0ggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfS0FS
TUEgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfQ1lQUkVTU19B
VEFDQiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9FTkVfVUI2
MjUwIGlzIG5vdCBzZXQNCkNPTkZJR19VU0JfVUFTPXkNCg0KIw0KIyBVU0Ig
SW1hZ2luZyBkZXZpY2VzDQojDQojIENPTkZJR19VU0JfTURDODAwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1VTQl9NSUNST1RFSyBpcyBub3Qgc2V0DQojIENP
TkZJR19VU0JJUF9DT1JFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9DRE5T
MyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfTVVTQl9IRFJDIGlzIG5vdCBz
ZXQNCkNPTkZJR19VU0JfRFdDMz15DQojIENPTkZJR19VU0JfRFdDM19IT1NU
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9EV0MzX0dBREdFVCBpcyBub3Qg
c2V0DQpDT05GSUdfVVNCX0RXQzNfRFVBTF9ST0xFPXkNCg0KIw0KIyBQbGF0
Zm9ybSBHbHVlIERyaXZlciBTdXBwb3J0DQojDQpDT05GSUdfVVNCX0RXQzNf
T0ZfU0lNUExFPXkNCiMgQ09ORklHX1VTQl9EV0MyIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VTQl9DSElQSURFQSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf
SVNQMTc2MCBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIHBvcnQgZHJpdmVycw0K
Iw0KIyBDT05GSUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0DQoNCiMNCiMgVVNC
IE1pc2NlbGxhbmVvdXMgZHJpdmVycw0KIw0KIyBDT05GSUdfVVNCX0VNSTYy
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9FTUkyNiBpcyBub3Qgc2V0DQoj
IENPTkZJR19VU0JfQURVVFVYIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9T
RVZTRUcgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0xFR09UT1dFUiBpcyBu
b3Qgc2V0DQojIENPTkZJR19VU0JfTENEIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1VTQl9DWVBSRVNTX0NZN0M2MyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf
Q1lUSEVSTSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfSURNT1VTRSBpcyBu
b3Qgc2V0DQojIENPTkZJR19VU0JfRlRESV9FTEFOIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VTQl9BUFBMRURJU1BMQVkgaXMgbm90IHNldA0KIyBDT05GSUdf
VVNCX0xEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9UUkFOQ0VWSUJSQVRP
UiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfSU9XQVJSSU9SIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1VTQl9URVNUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT
Ql9FSFNFVF9URVNUX0ZJWFRVUkUgaXMgbm90IHNldA0KIyBDT05GSUdfVVNC
X0lTSUdIVEZXIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9ZVVJFWCBpcyBu
b3Qgc2V0DQojIENPTkZJR19VU0JfRVpVU0JfRlgyIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VTQl9IVUJfVVNCMjUxWEIgaXMgbm90IHNldA0KIyBDT05GSUdf
VVNCX0hTSUNfVVNCMzUwMyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfSFNJ
Q19VU0I0NjA0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9MSU5LX0xBWUVS
X1RFU1QgaXMgbm90IHNldA0KDQojDQojIFVTQiBQaHlzaWNhbCBMYXllciBk
cml2ZXJzDQojDQpDT05GSUdfVVNCX1BIWT15DQojIENPTkZJR19OT1BfVVNC
X1hDRUlWIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9HUElPX1ZCVVMgaXMg
bm90IHNldA0KIyBDT05GSUdfVVNCX0lTUDEzMDEgaXMgbm90IHNldA0KIyBD
T05GSUdfVVNCX1VMUEkgaXMgbm90IHNldA0KIyBlbmQgb2YgVVNCIFBoeXNp
Y2FsIExheWVyIGRyaXZlcnMNCg0KQ09ORklHX1VTQl9HQURHRVQ9eQ0KIyBD
T05GSUdfVVNCX0dBREdFVF9ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19V
U0JfR0FER0VUX0RFQlVHX0ZJTEVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT
Ql9HQURHRVRfREVCVUdfRlMgaXMgbm90IHNldA0KQ09ORklHX1VTQl9HQURH
RVRfVkJVU19EUkFXPTINCkNPTkZJR19VU0JfR0FER0VUX1NUT1JBR0VfTlVN
X0JVRkZFUlM9Mg0KDQojDQojIFVTQiBQZXJpcGhlcmFsIENvbnRyb2xsZXIN
CiMNCiMgQ09ORklHX1VTQl9GT1RHMjEwX1VEQyBpcyBub3Qgc2V0DQojIENP
TkZJR19VU0JfR1JfVURDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9SOEE2
NjU5NyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfUFhBMjdYIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1VTQl9NVl9VREMgaXMgbm90IHNldA0KIyBDT05GSUdf
VVNCX01WX1UzRCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU05QX1VEQ19Q
TEFUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9NNjY1OTIgaXMgbm90IHNl
dA0KIyBDT05GSUdfVVNCX0JEQ19VREMgaXMgbm90IHNldA0KIyBDT05GSUdf
VVNCX05FVDIyNzIgaXMgbm90IHNldA0KQ09ORklHX1VTQl9HQURHRVRfWElM
SU5YPXkNCiMgQ09ORklHX1VTQl9EVU1NWV9IQ0QgaXMgbm90IHNldA0KIyBl
bmQgb2YgVVNCIFBlcmlwaGVyYWwgQ29udHJvbGxlcg0KDQpDT05GSUdfVVNC
X0xJQkNPTVBPU0lURT15DQpDT05GSUdfVVNCX1VfRVRIRVI9eQ0KQ09ORklH
X1VTQl9GX0VDTT1tDQpDT05GSUdfVVNCX0ZfRUVNPXkNCkNPTkZJR19VU0Jf
Rl9TVUJTRVQ9bQ0KQ09ORklHX1VTQl9GX1JORElTPW0NCkNPTkZJR19VU0Jf
Rl9NQVNTX1NUT1JBR0U9eQ0KQ09ORklHX1VTQl9DT05GSUdGUz15DQojIENP
TkZJR19VU0JfQ09ORklHRlNfU0VSSUFMIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1VTQl9DT05GSUdGU19BQ00gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0NP
TkZJR0ZTX09CRVggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0NPTkZJR0ZT
X05DTSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfQ09ORklHRlNfRUNNIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9DT05GSUdGU19FQ01fU1VCU0VUIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9DT05GSUdGU19STkRJUyBpcyBub3Qg
c2V0DQpDT05GSUdfVVNCX0NPTkZJR0ZTX0VFTT15DQpDT05GSUdfVVNCX0NP
TkZJR0ZTX01BU1NfU1RPUkFHRT15DQojIENPTkZJR19VU0JfQ09ORklHRlNf
Rl9MQl9TUyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfQ09ORklHRlNfRl9G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfQ09ORklHRlNfRl9VQUMxIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9DT05GSUdGU19GX1VBQzFfTEVHQUNZ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9DT05GSUdGU19GX1VBQzIgaXMg
bm90IHNldA0KIyBDT05GSUdfVVNCX0NPTkZJR0ZTX0ZfTUlESSBpcyBub3Qg
c2V0DQojIENPTkZJR19VU0JfQ09ORklHRlNfRl9ISUQgaXMgbm90IHNldA0K
IyBDT05GSUdfVVNCX0NPTkZJR0ZTX0ZfVVZDIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1VTQl9DT05GSUdGU19GX1BSSU5URVIgaXMgbm90IHNldA0KIyBDT05G
SUdfVVNCX1pFUk8gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0FVRElPIGlz
IG5vdCBzZXQNCkNPTkZJR19VU0JfRVRIPW0NCkNPTkZJR19VU0JfRVRIX1JO
RElTPXkNCkNPTkZJR19VU0JfRVRIX0VFTT15DQojIENPTkZJR19VU0JfR19O
Q00gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dBREdFVEZTIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1VTQl9GVU5DVElPTkZTIGlzIG5vdCBzZXQNCkNPTkZJ
R19VU0JfTUFTU19TVE9SQUdFPW0NCiMgQ09ORklHX1VTQl9HX1NFUklBTCBp
cyBub3Qgc2V0DQojIENPTkZJR19VU0JfTUlESV9HQURHRVQgaXMgbm90IHNl
dA0KIyBDT05GSUdfVVNCX0dfUFJJTlRFUiBpcyBub3Qgc2V0DQojIENPTkZJ
R19VU0JfQ0RDX0NPTVBPU0lURSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf
R19BQ01fTVMgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dfTVVMVEkgaXMg
bm90IHNldA0KIyBDT05GSUdfVVNCX0dfSElEIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1VTQl9HX0RCR1AgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0dfV0VC
Q0FNIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RZUEVDIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VTQl9ST0xFX1NXSVRDSCBpcyBub3Qgc2V0DQpDT05GSUdfTU1D
PXkNCkNPTkZJR19QV1JTRVFfRU1NQz15DQojIENPTkZJR19QV1JTRVFfU0Q4
Nzg3IGlzIG5vdCBzZXQNCkNPTkZJR19QV1JTRVFfU0lNUExFPXkNCkNPTkZJ
R19NTUNfQkxPQ0s9eQ0KQ09ORklHX01NQ19CTE9DS19NSU5PUlM9OA0KIyBD
T05GSUdfU0RJT19VQVJUIGlzIG5vdCBzZXQNCiMgQ09ORklHX01NQ19URVNU
IGlzIG5vdCBzZXQNCg0KIw0KIyBNTUMvU0QvU0RJTyBIb3N0IENvbnRyb2xs
ZXIgRHJpdmVycw0KIw0KIyBDT05GSUdfTU1DX0RFQlVHIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01NQ19BUk1NTUNJIGlzIG5vdCBzZXQNCkNPTkZJR19NTUNf
U0RIQ0k9eQ0KQ09ORklHX01NQ19TREhDSV9QTFRGTT15DQpDT05GSUdfTU1D
X1NESENJX09GX0FSQVNBTj15DQojIENPTkZJR19NTUNfU0RIQ0lfT0ZfQVNQ
RUVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX01NQ19TREhDSV9PRl9BVDkxIGlz
IG5vdCBzZXQNCiMgQ09ORklHX01NQ19TREhDSV9PRl9EV0NNU0hDIGlzIG5v
dCBzZXQNCiMgQ09ORklHX01NQ19TREhDSV9DQURFTkNFIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01NQ19TREhDSV9GX1NESDMwIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01NQ19TREhDSV9NSUxCRUFVVCBpcyBub3Qgc2V0DQojIENPTkZJR19N
TUNfU1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX01NQ19EVyBpcyBub3Qgc2V0
DQojIENPTkZJR19NTUNfVlVCMzAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01N
Q19VU0hDIGlzIG5vdCBzZXQNCiMgQ09ORklHX01NQ19VU0RISTZST0wwIGlz
IG5vdCBzZXQNCkNPTkZJR19NTUNfQ1FIQ0k9eQ0KIyBDT05GSUdfTU1DX01U
SyBpcyBub3Qgc2V0DQojIENPTkZJR19NTUNfU0RIQ0lfWEVOT04gaXMgbm90
IHNldA0KIyBDT05GSUdfTU1DX1NESENJX09NQVAgaXMgbm90IHNldA0KIyBD
T05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldA0KQ09ORklHX05FV19MRURTPXkN
CkNPTkZJR19MRURTX0NMQVNTPXkNCiMgQ09ORklHX0xFRFNfQ0xBU1NfRkxB
U0ggaXMgbm90IHNldA0KIyBDT05GSUdfTEVEU19CUklHSFRORVNTX0hXX0NI
QU5HRUQgaXMgbm90IHNldA0KDQojDQojIExFRCBkcml2ZXJzDQojDQojIENP
TkZJR19MRURTX0FOMzAyNTlBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xFRFNf
QkNNNjMyOCBpcyBub3Qgc2V0DQojIENPTkZJR19MRURTX0JDTTYzNTggaXMg
bm90IHNldA0KIyBDT05GSUdfTEVEU19DUjAwMTQxMTQgaXMgbm90IHNldA0K
IyBDT05GSUdfTEVEU19FTDE1MjAzMDAwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0xFRFNfTE0zNTMwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xFRFNfTE0zNTMy
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0xFRFNfTE0zNjQyIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0xFRFNfTE0zNjkyWCBpcyBub3Qgc2V0DQojIENPTkZJR19M
RURTX1BDQTk1MzIgaXMgbm90IHNldA0KQ09ORklHX0xFRFNfR1BJTz15DQoj
IENPTkZJR19MRURTX0xQMzk0NCBpcyBub3Qgc2V0DQojIENPTkZJR19MRURT
X0xQMzk1MiBpcyBub3Qgc2V0DQojIENPTkZJR19MRURTX0xQNTUyMSBpcyBu
b3Qgc2V0DQojIENPTkZJR19MRURTX0xQNTUyMyBpcyBub3Qgc2V0DQojIENP
TkZJR19MRURTX0xQNTU2MiBpcyBub3Qgc2V0DQojIENPTkZJR19MRURTX0xQ
ODUwMSBpcyBub3Qgc2V0DQojIENPTkZJR19MRURTX0xQODg2MCBpcyBub3Qg
c2V0DQojIENPTkZJR19MRURTX1BDQTk1NVggaXMgbm90IHNldA0KIyBDT05G
SUdfTEVEU19QQ0E5NjNYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xFRFNfREFD
MTI0UzA4NSBpcyBub3Qgc2V0DQojIENPTkZJR19MRURTX1JFR1VMQVRPUiBp
cyBub3Qgc2V0DQojIENPTkZJR19MRURTX0JEMjgwMiBpcyBub3Qgc2V0DQoj
IENPTkZJR19MRURTX0xUMzU5MyBpcyBub3Qgc2V0DQojIENPTkZJR19MRURT
X1RDQTY1MDcgaXMgbm90IHNldA0KIyBDT05GSUdfTEVEU19UTEM1OTFYWCBp
cyBub3Qgc2V0DQojIENPTkZJR19MRURTX0xNMzU1eCBpcyBub3Qgc2V0DQoj
IENPTkZJR19MRURTX0lTMzFGTDMxOVggaXMgbm90IHNldA0KIyBDT05GSUdf
TEVEU19JUzMxRkwzMlhYIGlzIG5vdCBzZXQNCg0KIw0KIyBMRUQgZHJpdmVy
IGZvciBibGluaygxKSBVU0IgUkdCIExFRCBpcyB1bmRlciBTcGVjaWFsIEhJ
RCBkcml2ZXJzIChISURfVEhJTkdNKQ0KIw0KIyBDT05GSUdfTEVEU19CTElO
S00gaXMgbm90IHNldA0KIyBDT05GSUdfTEVEU19NTFhSRUcgaXMgbm90IHNl
dA0KIyBDT05GSUdfTEVEU19VU0VSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xF
RFNfU1BJX0JZVEUgaXMgbm90IHNldA0KIyBDT05GSUdfTEVEU19USV9MTVVf
Q09NTU9OIGlzIG5vdCBzZXQNCg0KIw0KIyBMRUQgVHJpZ2dlcnMNCiMNCkNP
TkZJR19MRURTX1RSSUdHRVJTPXkNCkNPTkZJR19MRURTX1RSSUdHRVJfVElN
RVI9eQ0KQ09ORklHX0xFRFNfVFJJR0dFUl9PTkVTSE9UPXkNCiMgQ09ORklH
X0xFRFNfVFJJR0dFUl9ESVNLIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xFRFNf
VFJJR0dFUl9NVEQgaXMgbm90IHNldA0KQ09ORklHX0xFRFNfVFJJR0dFUl9I
RUFSVEJFQVQ9eQ0KQ09ORklHX0xFRFNfVFJJR0dFUl9CQUNLTElHSFQ9eQ0K
IyBDT05GSUdfTEVEU19UUklHR0VSX0FDVElWSVRZIGlzIG5vdCBzZXQNCkNP
TkZJR19MRURTX1RSSUdHRVJfR1BJTz15DQpDT05GSUdfTEVEU19UUklHR0VS
X0RFRkFVTFRfT049eQ0KDQojDQojIGlwdGFibGVzIHRyaWdnZXIgaXMgdW5k
ZXIgTmV0ZmlsdGVyIGNvbmZpZyAoTEVEIHRhcmdldCkNCiMNCkNPTkZJR19M
RURTX1RSSUdHRVJfVFJBTlNJRU5UPXkNCkNPTkZJR19MRURTX1RSSUdHRVJf
Q0FNRVJBPXkNCiMgQ09ORklHX0xFRFNfVFJJR0dFUl9QQU5JQyBpcyBub3Qg
c2V0DQojIENPTkZJR19MRURTX1RSSUdHRVJfTkVUREVWIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0xFRFNfVFJJR0dFUl9QQVRURVJOIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0xFRFNfVFJJR0dFUl9BVURJTyBpcyBub3Qgc2V0DQojIENPTkZJ
R19BQ0NFU1NJQklMSVRZIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lORklOSUJB
TkQgaXMgbm90IHNldA0KQ09ORklHX0VEQUNfU1VQUE9SVD15DQpDT05GSUdf
RURBQz15DQpDT05GSUdfRURBQ19MRUdBQ1lfU1lTRlM9eQ0KIyBDT05GSUdf
RURBQ19ERUJVRyBpcyBub3Qgc2V0DQpDT05GSUdfRURBQ19TWU5PUFNZUz15
DQojIENPTkZJR19FREFDX1hHRU5FIGlzIG5vdCBzZXQNCkNPTkZJR19SVENf
TElCPXkNCkNPTkZJR19SVENfQ0xBU1M9eQ0KQ09ORklHX1JUQ19IQ1RPU1lT
PXkNCkNPTkZJR19SVENfSENUT1NZU19ERVZJQ0U9InJ0YzAiDQpDT05GSUdf
UlRDX1NZU1RPSEM9eQ0KQ09ORklHX1JUQ19TWVNUT0hDX0RFVklDRT0icnRj
MCINCiMgQ09ORklHX1JUQ19ERUJVRyBpcyBub3Qgc2V0DQpDT05GSUdfUlRD
X05WTUVNPXkNCg0KIw0KIyBSVEMgaW50ZXJmYWNlcw0KIw0KQ09ORklHX1JU
Q19JTlRGX1NZU0ZTPXkNCkNPTkZJR19SVENfSU5URl9QUk9DPXkNCkNPTkZJ
R19SVENfSU5URl9ERVY9eQ0KIyBDT05GSUdfUlRDX0lOVEZfREVWX1VJRV9F
TVVMIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfVEVTVCBpcyBub3Qg
c2V0DQoNCiMNCiMgSTJDIFJUQyBkcml2ZXJzDQojDQojIENPTkZJR19SVENf
RFJWX0FCQjVaRVMzIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfQUJF
T1o5IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfQUJYODBYIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfRFMxMzA3IGlzIG5vdCBzZXQNCiMg
Q09ORklHX1JUQ19EUlZfRFMxMzc0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JU
Q19EUlZfRFMxNjcyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfSFlN
ODU2MyBpcyBub3Qgc2V0DQojIENPTkZJR19SVENfRFJWX01BWDY5MDAgaXMg
bm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9SUzVDMzcyIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1JUQ19EUlZfSVNMMTIwOCBpcyBub3Qgc2V0DQojIENPTkZJ
R19SVENfRFJWX0lTTDEyMDIyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQ19E
UlZfSVNMMTIwMjYgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9YMTIw
NSBpcyBub3Qgc2V0DQojIENPTkZJR19SVENfRFJWX1BDRjg1MjMgaXMgbm90
IHNldA0KIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTA2MyBpcyBub3Qgc2V0DQoj
IENPTkZJR19SVENfRFJWX1BDRjg1MzYzIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1JUQ19EUlZfUENGODU2MyBpcyBub3Qgc2V0DQojIENPTkZJR19SVENfRFJW
X1BDRjg1ODMgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9NNDFUODAg
aXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9CUTMySyBpcyBub3Qgc2V0
DQojIENPTkZJR19SVENfRFJWX1MzNTM5MEEgaXMgbm90IHNldA0KIyBDT05G
SUdfUlRDX0RSVl9GTTMxMzAgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RS
Vl9SWDgwMTAgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9SWDg1ODEg
aXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9SWDgwMjUgaXMgbm90IHNl
dA0KIyBDT05GSUdfUlRDX0RSVl9FTTMwMjcgaXMgbm90IHNldA0KIyBDT05G
SUdfUlRDX0RSVl9SVjMwMjggaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RS
Vl9SVjg4MDMgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9TRDMwNzgg
aXMgbm90IHNldA0KDQojDQojIFNQSSBSVEMgZHJpdmVycw0KIw0KIyBDT05G
SUdfUlRDX0RSVl9NNDFUOTMgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RS
Vl9NNDFUOTQgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9EUzEzMDIg
aXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9EUzEzMDUgaXMgbm90IHNl
dA0KIyBDT05GSUdfUlRDX0RSVl9EUzEzNDMgaXMgbm90IHNldA0KIyBDT05G
SUdfUlRDX0RSVl9EUzEzNDcgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RS
Vl9EUzEzOTAgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9NQVg2OTE2
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfUjk3MDEgaXMgbm90IHNl
dA0KIyBDT05GSUdfUlRDX0RSVl9SWDQ1ODEgaXMgbm90IHNldA0KIyBDT05G
SUdfUlRDX0RSVl9SWDYxMTAgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RS
Vl9SUzVDMzQ4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfTUFYNjkw
MiBpcyBub3Qgc2V0DQojIENPTkZJR19SVENfRFJWX1BDRjIxMjMgaXMgbm90
IHNldA0KIyBDT05GSUdfUlRDX0RSVl9NQ1A3OTUgaXMgbm90IHNldA0KQ09O
RklHX1JUQ19JMkNfQU5EX1NQST15DQoNCiMNCiMgU1BJIGFuZCBJMkMgUlRD
IGRyaXZlcnMNCiMNCiMgQ09ORklHX1JUQ19EUlZfRFMzMjMyIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1JUQ19EUlZfUENGMjEyNyBpcyBub3Qgc2V0DQojIENP
TkZJR19SVENfRFJWX1JWMzAyOUMyIGlzIG5vdCBzZXQNCg0KIw0KIyBQbGF0
Zm9ybSBSVEMgZHJpdmVycw0KIw0KIyBDT05GSUdfUlRDX0RSVl9EUzEyODYg
aXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9EUzE1MTEgaXMgbm90IHNl
dA0KIyBDT05GSUdfUlRDX0RSVl9EUzE1NTMgaXMgbm90IHNldA0KIyBDT05G
SUdfUlRDX0RSVl9EUzE2ODVfRkFNSUxZIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1JUQ19EUlZfRFMxNzQyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQ19EUlZf
RFMyNDA0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfRUZJIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfU1RLMTdUQTggaXMgbm90IHNldA0K
IyBDT05GSUdfUlRDX0RSVl9NNDhUODYgaXMgbm90IHNldA0KIyBDT05GSUdf
UlRDX0RSVl9NNDhUMzUgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9N
NDhUNTkgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9NU002MjQyIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1JUQ19EUlZfQlE0ODAyIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1JUQ19EUlZfUlA1QzAxIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1JUQ19EUlZfVjMwMjAgaXMgbm90IHNldA0KQ09ORklHX1JUQ19EUlZfWllO
UU1QPXkNCg0KIw0KIyBvbi1DUFUgUlRDIGRyaXZlcnMNCiMNCiMgQ09ORklH
X1JUQ19EUlZfUEwwMzAgaXMgbm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9Q
TDAzMSBpcyBub3Qgc2V0DQojIENPTkZJR19SVENfRFJWX0NBREVOQ0UgaXMg
bm90IHNldA0KIyBDT05GSUdfUlRDX0RSVl9GVFJUQzAxMCBpcyBub3Qgc2V0
DQojIENPTkZJR19SVENfRFJWX1NOVlMgaXMgbm90IHNldA0KIyBDT05GSUdf
UlRDX0RSVl9SNzMwMSBpcyBub3Qgc2V0DQoNCiMNCiMgSElEIFNlbnNvciBS
VEMgZHJpdmVycw0KIw0KQ09ORklHX0RNQURFVklDRVM9eQ0KIyBDT05GSUdf
RE1BREVWSUNFU19ERUJVRyBpcyBub3Qgc2V0DQoNCiMNCiMgRE1BIERldmlj
ZXMNCiMNCkNPTkZJR19ETUFfRU5HSU5FPXkNCkNPTkZJR19ETUFfT0Y9eQ0K
IyBDT05GSUdfQUxURVJBX01TR0RNQSBpcyBub3Qgc2V0DQojIENPTkZJR19B
TUJBX1BMMDhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FYSV9ETUFDIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0JDTV9TQkFfUkFJRCBpcyBub3Qgc2V0DQojIENP
TkZJR19EV19BWElfRE1BQyBpcyBub3Qgc2V0DQojIENPTkZJR19GU0xfRURN
QSBpcyBub3Qgc2V0DQojIENPTkZJR19GU0xfUURNQSBpcyBub3Qgc2V0DQoj
IENPTkZJR19ISVNJX0RNQSBpcyBub3Qgc2V0DQojIENPTkZJR19JTlRFTF9J
RE1BNjQgaXMgbm90IHNldA0KIyBDT05GSUdfTVZfWE9SX1YyIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1BMMzMwX0RNQSBpcyBub3Qgc2V0DQpDT05GSUdfWElM
SU5YX0RNQT15DQpDT05GSUdfWElMSU5YX1pZTlFNUF9ETUE9eQ0KIyBDT05G
SUdfUUNPTV9ISURNQV9NR01UIGlzIG5vdCBzZXQNCiMgQ09ORklHX1FDT01f
SElETUEgaXMgbm90IHNldA0KIyBDT05GSUdfRFdfRE1BQyBpcyBub3Qgc2V0
DQojIENPTkZJR19TRl9QRE1BIGlzIG5vdCBzZXQNCg0KIw0KIyBETUEgQ2xp
ZW50cw0KIw0KIyBDT05GSUdfQVNZTkNfVFhfRE1BIGlzIG5vdCBzZXQNCkNP
TkZJR19ETUFURVNUPXkNCkNPTkZJR19ETUFfRU5HSU5FX1JBSUQ9eQ0KDQoj
DQojIERNQUJVRiBvcHRpb25zDQojDQpDT05GSUdfU1lOQ19GSUxFPXkNCiMg
Q09ORklHX1NXX1NZTkMgaXMgbm90IHNldA0KIyBDT05GSUdfVURNQUJVRiBp
cyBub3Qgc2V0DQojIENPTkZJR19ETUFCVUZfU0VMRlRFU1RTIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0RNQUJVRl9IRUFQUyBpcyBub3Qgc2V0DQojIGVuZCBv
ZiBETUFCVUYgb3B0aW9ucw0KDQojIENPTkZJR19BVVhESVNQTEFZIGlzIG5v
dCBzZXQNCkNPTkZJR19VSU89eQ0KQ09ORklHX1VJT19QRFJWX0dFTklSUT1t
DQpDT05GSUdfVUlPX0RNRU1fR0VOSVJRPW0NCiMgQ09ORklHX1VJT19QUlVT
UyBpcyBub3Qgc2V0DQojIENPTkZJR19WRklPIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1ZJUlRfRFJJVkVSUyBpcyBub3Qgc2V0DQpDT05GSUdfVklSVElPPXkN
CkNPTkZJR19WSVJUSU9fTUVOVT15DQojIENPTkZJR19WSVJUSU9fQkFMTE9P
TiBpcyBub3Qgc2V0DQojIENPTkZJR19WSVJUSU9fSU5QVVQgaXMgbm90IHNl
dA0KIyBDT05GSUdfVklSVElPX01NSU8gaXMgbm90IHNldA0KDQojDQojIE1p
Y3Jvc29mdCBIeXBlci1WIGd1ZXN0IHN1cHBvcnQNCiMNCiMgZW5kIG9mIE1p
Y3Jvc29mdCBIeXBlci1WIGd1ZXN0IHN1cHBvcnQNCg0KIw0KIyBYZW4gZHJp
dmVyIHN1cHBvcnQNCiMNCkNPTkZJR19YRU5fQkFMTE9PTj15DQpDT05GSUdf
WEVOX1NDUlVCX1BBR0VTX0RFRkFVTFQ9eQ0KQ09ORklHX1hFTl9ERVZfRVZU
Q0hOPXkNCkNPTkZJR19YRU5fQkFDS0VORD15DQpDT05GSUdfWEVORlM9eQ0K
Q09ORklHX1hFTl9DT01QQVRfWEVORlM9eQ0KQ09ORklHX1hFTl9TWVNfSFlQ
RVJWSVNPUj15DQpDT05GSUdfWEVOX1hFTkJVU19GUk9OVEVORD15DQpDT05G
SUdfWEVOX0dOVERFVj15DQpDT05GSUdfWEVOX0dSQU5UX0RFVl9BTExPQz15
DQojIENPTkZJR19YRU5fR1JBTlRfRE1BX0FMTE9DIGlzIG5vdCBzZXQNCkNP
TkZJR19TV0lPVExCX1hFTj15DQojIENPTkZJR19YRU5fUFZDQUxMU19GUk9O
VEVORCBpcyBub3Qgc2V0DQpDT05GSUdfWEVOX1BWQ0FMTFNfQkFDS0VORD15
DQpDT05GSUdfWEVOX1BSSVZDTUQ9eQ0KQ09ORklHX1hFTl9FRkk9eQ0KQ09O
RklHX1hFTl9BVVRPX1hMQVRFPXkNCiMgZW5kIG9mIFhlbiBkcml2ZXIgc3Vw
cG9ydA0KDQojIENPTkZJR19HUkVZQlVTIGlzIG5vdCBzZXQNCkNPTkZJR19T
VEFHSU5HPXkNCiMgQ09ORklHX1BSSVNNMl9VU0IgaXMgbm90IHNldA0KIyBD
T05GSUdfQ09NRURJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUTExJQiBpcyBu
b3Qgc2V0DQojIENPTkZJR19SVEw4NzIzQlMgaXMgbm90IHNldA0KIyBDT05G
SUdfUjg3MTJVIGlzIG5vdCBzZXQNCiMgQ09ORklHX1I4MTg4RVUgaXMgbm90
IHNldA0KIyBDT05GSUdfVlQ2NjU2IGlzIG5vdCBzZXQNCg0KIw0KIyBJSU8g
c3RhZ2luZyBkcml2ZXJzDQojDQoNCiMNCiMgQWNjZWxlcm9tZXRlcnMNCiMN
CiMgQ09ORklHX0FESVMxNjIwMyBpcyBub3Qgc2V0DQojIENPTkZJR19BRElT
MTYyNDAgaXMgbm90IHNldA0KIyBlbmQgb2YgQWNjZWxlcm9tZXRlcnMNCg0K
Iw0KIyBBbmFsb2cgdG8gZGlnaXRhbCBjb252ZXJ0ZXJzDQojDQojIENPTkZJ
R19BRDc4MTYgaXMgbm90IHNldA0KIyBDT05GSUdfQUQ3MTkyIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0FENzI4MCBpcyBub3Qgc2V0DQojIGVuZCBvZiBBbmFs
b2cgdG8gZGlnaXRhbCBjb252ZXJ0ZXJzDQoNCiMNCiMgQW5hbG9nIGRpZ2l0
YWwgYmktZGlyZWN0aW9uIGNvbnZlcnRlcnMNCiMNCiMgQ09ORklHX0FEVDcz
MTYgaXMgbm90IHNldA0KIyBlbmQgb2YgQW5hbG9nIGRpZ2l0YWwgYmktZGly
ZWN0aW9uIGNvbnZlcnRlcnMNCg0KIw0KIyBDYXBhY2l0YW5jZSB0byBkaWdp
dGFsIGNvbnZlcnRlcnMNCiMNCiMgQ09ORklHX0FENzE1MCBpcyBub3Qgc2V0
DQojIENPTkZJR19BRDc3NDYgaXMgbm90IHNldA0KIyBlbmQgb2YgQ2FwYWNp
dGFuY2UgdG8gZGlnaXRhbCBjb252ZXJ0ZXJzDQoNCiMNCiMgRGlyZWN0IERp
Z2l0YWwgU3ludGhlc2lzDQojDQojIENPTkZJR19BRDk4MzIgaXMgbm90IHNl
dA0KIyBDT05GSUdfQUQ5ODM0IGlzIG5vdCBzZXQNCiMgZW5kIG9mIERpcmVj
dCBEaWdpdGFsIFN5bnRoZXNpcw0KDQojDQojIE5ldHdvcmsgQW5hbHl6ZXIs
IEltcGVkYW5jZSBDb252ZXJ0ZXJzDQojDQojIENPTkZJR19BRDU5MzMgaXMg
bm90IHNldA0KIyBlbmQgb2YgTmV0d29yayBBbmFseXplciwgSW1wZWRhbmNl
IENvbnZlcnRlcnMNCg0KIw0KIyBBY3RpdmUgZW5lcmd5IG1ldGVyaW5nIElD
DQojDQojIENPTkZJR19BREU3ODU0IGlzIG5vdCBzZXQNCiMgZW5kIG9mIEFj
dGl2ZSBlbmVyZ3kgbWV0ZXJpbmcgSUMNCg0KIw0KIyBSZXNvbHZlciB0byBk
aWdpdGFsIGNvbnZlcnRlcnMNCiMNCiMgQ09ORklHX0FEMlMxMjEwIGlzIG5v
dCBzZXQNCiMgZW5kIG9mIFJlc29sdmVyIHRvIGRpZ2l0YWwgY29udmVydGVy
cw0KIyBlbmQgb2YgSUlPIHN0YWdpbmcgZHJpdmVycw0KDQojDQojIFNwZWFr
dXAgY29uc29sZSBzcGVlY2gNCiMNCiMgQ09ORklHX1NQRUFLVVAgaXMgbm90
IHNldA0KIyBlbmQgb2YgU3BlYWt1cCBjb25zb2xlIHNwZWVjaA0KDQojIENP
TkZJR19TVEFHSU5HX01FRElBIGlzIG5vdCBzZXQNCg0KIw0KIyBBbmRyb2lk
DQojDQojIENPTkZJR19BU0hNRU0gaXMgbm90IHNldA0KQ09ORklHX0lPTj15
DQpDT05GSUdfSU9OX1NZU1RFTV9IRUFQPXkNCkNPTkZJR19JT05fQ01BX0hF
QVA9eQ0KIyBlbmQgb2YgQW5kcm9pZA0KDQojIENPTkZJR19TVEFHSU5HX0JP
QVJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xURV9HRE03MjRYIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0dTX0ZQR0FCT09UIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1VOSVNZU1NQQVIgaXMgbm90IHNldA0KQ09ORklHX0NPTU1PTl9DTEtfWExO
WF9DTEtXWlJEPXkNCiMgQ09ORklHX0ZCX1RGVCBpcyBub3Qgc2V0DQojIENP
TkZJR19XSUxDMTAwMF9TRElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX1dJTEMx
MDAwX1NQSSBpcyBub3Qgc2V0DQojIENPTkZJR19NT1NUIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0tTNzAxMCBpcyBub3Qgc2V0DQojIENPTkZJR19QSTQzMyBp
cyBub3Qgc2V0DQoNCiMNCiMgR2Fza2V0IGRldmljZXMNCiMNCiMgZW5kIG9m
IEdhc2tldCBkZXZpY2VzDQoNCiMgQ09ORklHX1hJTF9BWElTX0ZJRk8gaXMg
bm90IHNldA0KIyBDT05GSUdfRklFTERCVVNfREVWIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VTQl9XVVNCX0NCQUYgaXMgbm90IHNldA0KIyBDT05GSUdfVVdC
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NUQUdJTkdfRVhGQVRfRlMgaXMgbm90
IHNldA0KIyBDT05GSUdfV0ZYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0dPTERG
SVNIIGlzIG5vdCBzZXQNCiMgQ09ORklHX01GRF9DUk9TX0VDIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0NIUk9NRV9QTEFURk9STVMgaXMgbm90IHNldA0KIyBD
T05GSUdfTUVMTEFOT1hfUExBVEZPUk0gaXMgbm90IHNldA0KQ09ORklHX0NM
S0RFVl9MT09LVVA9eQ0KQ09ORklHX0hBVkVfQ0xLX1BSRVBBUkU9eQ0KQ09O
RklHX0NPTU1PTl9DTEs9eQ0KDQojDQojIENvbW1vbiBDbG9jayBGcmFtZXdv
cmsNCiMNCiMgQ09ORklHX0NPTU1PTl9DTEtfVkVSU0FUSUxFIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0NMS19IU0RLIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NP
TU1PTl9DTEtfTUFYOTQ4NSBpcyBub3Qgc2V0DQojIENPTkZJR19DT01NT05f
Q0xLX1NJNTM0MSBpcyBub3Qgc2V0DQojIENPTkZJR19DT01NT05fQ0xLX1NJ
NTM1MSBpcyBub3Qgc2V0DQojIENPTkZJR19DT01NT05fQ0xLX1NJNTE0IGlz
IG5vdCBzZXQNCiMgQ09ORklHX0NPTU1PTl9DTEtfU0k1NDQgaXMgbm90IHNl
dA0KQ09ORklHX0NPTU1PTl9DTEtfU0k1NzA9eQ0KIyBDT05GSUdfQ09NTU9O
X0NMS19DRENFNzA2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0NPTU1PTl9DTEtf
Q0RDRTkyNSBpcyBub3Qgc2V0DQojIENPTkZJR19DT01NT05fQ0xLX0NTMjAw
MF9DUCBpcyBub3Qgc2V0DQojIENPTkZJR19DTEtfUU9SSVEgaXMgbm90IHNl
dA0KIyBDT05GSUdfQ09NTU9OX0NMS19YR0VORSBpcyBub3Qgc2V0DQojIENP
TkZJR19DT01NT05fQ0xLX1ZDNSBpcyBub3Qgc2V0DQojIENPTkZJR19DT01N
T05fQ0xLX0ZJWEVEX01NSU8gaXMgbm90IHNldA0KQ09ORklHX0NPTU1PTl9D
TEtfWllOUU1QPXkNCiMgZW5kIG9mIENvbW1vbiBDbG9jayBGcmFtZXdvcmsN
Cg0KIyBDT05GSUdfSFdTUElOTE9DSyBpcyBub3Qgc2V0DQoNCiMNCiMgQ2xv
Y2sgU291cmNlIGRyaXZlcnMNCiMNCkNPTkZJR19USU1FUl9PRj15DQpDT05G
SUdfVElNRVJfUFJPQkU9eQ0KQ09ORklHX0FSTV9BUkNIX1RJTUVSPXkNCiMg
Q09ORklHX0FSTV9BUkNIX1RJTUVSX0VWVFNUUkVBTSBpcyBub3Qgc2V0DQpD
T05GSUdfQVJNX0FSQ0hfVElNRVJfT09MX1dPUktBUk9VTkQ9eQ0KQ09ORklH
X0ZTTF9FUlJBVFVNX0EwMDg1ODU9eQ0KQ09ORklHX0hJU0lMSUNPTl9FUlJB
VFVNXzE2MTAxMDEwMT15DQpDT05GSUdfQVJNNjRfRVJSQVRVTV84NTg5MjE9
eQ0KIyBDT05GSUdfTUlDUk9DSElQX1BJVDY0QiBpcyBub3Qgc2V0DQojIGVu
ZCBvZiBDbG9jayBTb3VyY2UgZHJpdmVycw0KDQpDT05GSUdfTUFJTEJPWD15
DQojIENPTkZJR19BUk1fTUhVIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BMQVRG
T1JNX01IVSBpcyBub3Qgc2V0DQojIENPTkZJR19QTDMyMF9NQk9YIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0FMVEVSQV9NQk9YIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01BSUxCT1hfVEVTVCBpcyBub3Qgc2V0DQpDT05GSUdfWllOUU1QX0lQ
SV9NQk9YPXkNCkNPTkZJR19JT01NVV9JT1ZBPXkNCkNPTkZJR19JT01NVV9B
UEk9eQ0KQ09ORklHX0lPTU1VX1NVUFBPUlQ9eQ0KDQojDQojIEdlbmVyaWMg
SU9NTVUgUGFnZXRhYmxlIFN1cHBvcnQNCiMNCkNPTkZJR19JT01NVV9JT19Q
R1RBQkxFPXkNCkNPTkZJR19JT01NVV9JT19QR1RBQkxFX0xQQUU9eQ0KIyBD
T05GSUdfSU9NTVVfSU9fUEdUQUJMRV9MUEFFX1NFTEZURVNUIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0lPTU1VX0lPX1BHVEFCTEVfQVJNVjdTIGlzIG5vdCBz
ZXQNCiMgZW5kIG9mIEdlbmVyaWMgSU9NTVUgUGFnZXRhYmxlIFN1cHBvcnQN
Cg0KIyBDT05GSUdfSU9NTVVfREVCVUdGUyBpcyBub3Qgc2V0DQojIENPTkZJ
R19JT01NVV9ERUZBVUxUX1BBU1NUSFJPVUdIIGlzIG5vdCBzZXQNCkNPTkZJ
R19PRl9JT01NVT15DQpDT05GSUdfSU9NTVVfRE1BPXkNCkNPTkZJR19BUk1f
U01NVT15DQojIENPTkZJR19BUk1fU01NVV9MRUdBQ1lfRFRfQklORElOR1Mg
aXMgbm90IHNldA0KQ09ORklHX0FSTV9TTU1VX0RJU0FCTEVfQllQQVNTX0JZ
X0RFRkFVTFQ9eQ0KIyBDT05GSUdfQVJNX1NNTVVfVjMgaXMgbm90IHNldA0K
IyBDT05GSUdfVklSVElPX0lPTU1VIGlzIG5vdCBzZXQNCg0KIw0KIyBSZW1v
dGVwcm9jIGRyaXZlcnMNCiMNCkNPTkZJR19SRU1PVEVQUk9DPXkNCiMgZW5k
IG9mIFJlbW90ZXByb2MgZHJpdmVycw0KDQojDQojIFJwbXNnIGRyaXZlcnMN
CiMNCkNPTkZJR19SUE1TRz1tDQojIENPTkZJR19SUE1TR19DSEFSIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1JQTVNHX1FDT01fR0xJTktfUlBNIGlzIG5vdCBz
ZXQNCkNPTkZJR19SUE1TR19WSVJUSU89bQ0KIyBlbmQgb2YgUnBtc2cgZHJp
dmVycw0KDQojIENPTkZJR19TT1VORFdJUkUgaXMgbm90IHNldA0KDQojDQoj
IFNPQyAoU3lzdGVtIE9uIENoaXApIHNwZWNpZmljIERyaXZlcnMNCiMNCg0K
Iw0KIyBBbWxvZ2ljIFNvQyBkcml2ZXJzDQojDQojIGVuZCBvZiBBbWxvZ2lj
IFNvQyBkcml2ZXJzDQoNCiMNCiMgQXNwZWVkIFNvQyBkcml2ZXJzDQojDQoj
IGVuZCBvZiBBc3BlZWQgU29DIGRyaXZlcnMNCg0KIw0KIyBCcm9hZGNvbSBT
b0MgZHJpdmVycw0KIw0KIyBDT05GSUdfU09DX0JSQ01TVEIgaXMgbm90IHNl
dA0KIyBlbmQgb2YgQnJvYWRjb20gU29DIGRyaXZlcnMNCg0KIw0KIyBOWFAv
RnJlZXNjYWxlIFFvcklRIFNvQyBkcml2ZXJzDQojDQojIENPTkZJR19RVUlD
Q19FTkdJTkUgaXMgbm90IHNldA0KIyBDT05GSUdfRlNMX1JDUE0gaXMgbm90
IHNldA0KIyBlbmQgb2YgTlhQL0ZyZWVzY2FsZSBRb3JJUSBTb0MgZHJpdmVy
cw0KDQojDQojIGkuTVggU29DIGRyaXZlcnMNCiMNCiMgZW5kIG9mIGkuTVgg
U29DIGRyaXZlcnMNCg0KIw0KIyBRdWFsY29tbSBTb0MgZHJpdmVycw0KIw0K
IyBlbmQgb2YgUXVhbGNvbW0gU29DIGRyaXZlcnMNCg0KIyBDT05GSUdfU09D
X1RJIGlzIG5vdCBzZXQNCg0KIw0KIyBYaWxpbnggU29DIGRyaXZlcnMNCiMN
CkNPTkZJR19YSUxJTlhfVkNVPW0NCkNPTkZJR19aWU5RTVBfUE9XRVI9eQ0K
Q09ORklHX1pZTlFNUF9QTV9ET01BSU5TPXkNCiMgZW5kIG9mIFhpbGlueCBT
b0MgZHJpdmVycw0KIyBlbmQgb2YgU09DIChTeXN0ZW0gT24gQ2hpcCkgc3Bl
Y2lmaWMgRHJpdmVycw0KDQojIENPTkZJR19QTV9ERVZGUkVRIGlzIG5vdCBz
ZXQNCkNPTkZJR19FWFRDT049eQ0KDQojDQojIEV4dGNvbiBEZXZpY2UgRHJp
dmVycw0KIw0KIyBDT05GSUdfRVhUQ09OX0FEQ19KQUNLIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0VYVENPTl9GU0E5NDgwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0VYVENPTl9HUElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VYVENPTl9NQVgz
MzU1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0VYVENPTl9QVE41MTUwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0VYVENPTl9SVDg5NzNBIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0VYVENPTl9TTTU1MDIgaXMgbm90IHNldA0KIyBDT05GSUdfRVhU
Q09OX1VTQl9HUElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX01FTU9SWSBpcyBu
b3Qgc2V0DQpDT05GSUdfSUlPPXkNCkNPTkZJR19JSU9fQlVGRkVSPXkNCiMg
Q09ORklHX0lJT19CVUZGRVJfQ0IgaXMgbm90IHNldA0KIyBDT05GSUdfSUlP
X0JVRkZFUl9IV19DT05TVU1FUiBpcyBub3Qgc2V0DQpDT05GSUdfSUlPX0tG
SUZPX0JVRj15DQpDT05GSUdfSUlPX1RSSUdHRVJFRF9CVUZGRVI9eQ0KIyBD
T05GSUdfSUlPX0NPTkZJR0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19JSU9fVFJJ
R0dFUj15DQpDT05GSUdfSUlPX0NPTlNVTUVSU19QRVJfVFJJR0dFUj0yDQoj
IENPTkZJR19JSU9fU1dfREVWSUNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lJ
T19TV19UUklHR0VSIGlzIG5vdCBzZXQNCg0KIw0KIyBBY2NlbGVyb21ldGVy
cw0KIw0KIyBDT05GSUdfQURJUzE2MjAxIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0FESVMxNjIwOSBpcyBub3Qgc2V0DQojIENPTkZJR19BRFhMMzQ1X0kyQyBp
cyBub3Qgc2V0DQojIENPTkZJR19BRFhMMzQ1X1NQSSBpcyBub3Qgc2V0DQoj
IENPTkZJR19BRFhMMzcyX1NQSSBpcyBub3Qgc2V0DQojIENPTkZJR19BRFhM
MzcyX0kyQyBpcyBub3Qgc2V0DQojIENPTkZJR19CTUExODAgaXMgbm90IHNl
dA0KIyBDT05GSUdfQk1BMjIwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JNQTQw
MCBpcyBub3Qgc2V0DQojIENPTkZJR19CTUMxNTBfQUNDRUwgaXMgbm90IHNl
dA0KIyBDT05GSUdfREEyODAgaXMgbm90IHNldA0KIyBDT05GSUdfREEzMTEg
aXMgbm90IHNldA0KIyBDT05GSUdfRE1BUkQwNiBpcyBub3Qgc2V0DQojIENP
TkZJR19ETUFSRDA5IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RNQVJEMTAgaXMg
bm90IHNldA0KIyBDT05GSUdfSUlPX1NUX0FDQ0VMXzNBWElTIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0tYU0Q5IGlzIG5vdCBzZXQNCiMgQ09ORklHX0tYQ0pL
MTAxMyBpcyBub3Qgc2V0DQojIENPTkZJR19NQzMyMzAgaXMgbm90IHNldA0K
IyBDT05GSUdfTU1BNzQ1NV9JMkMgaXMgbm90IHNldA0KIyBDT05GSUdfTU1B
NzQ1NV9TUEkgaXMgbm90IHNldA0KIyBDT05GSUdfTU1BNzY2MCBpcyBub3Qg
c2V0DQojIENPTkZJR19NTUE4NDUyIGlzIG5vdCBzZXQNCiMgQ09ORklHX01N
QTk1NTEgaXMgbm90IHNldA0KIyBDT05GSUdfTU1BOTU1MyBpcyBub3Qgc2V0
DQojIENPTkZJR19NWEM0MDA1IGlzIG5vdCBzZXQNCiMgQ09ORklHX01YQzYy
NTUgaXMgbm90IHNldA0KIyBDT05GSUdfU0NBMzAwMCBpcyBub3Qgc2V0DQoj
IENPTkZJR19TVEs4MzEyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NUSzhCQTUw
IGlzIG5vdCBzZXQNCiMgZW5kIG9mIEFjY2VsZXJvbWV0ZXJzDQoNCiMNCiMg
QW5hbG9nIHRvIGRpZ2l0YWwgY29udmVydGVycw0KIw0KIyBDT05GSUdfQUQ3
MDkxUjUgaXMgbm90IHNldA0KIyBDT05GSUdfQUQ3MTI0IGlzIG5vdCBzZXQN
CiMgQ09ORklHX0FENzI2NiBpcyBub3Qgc2V0DQojIENPTkZJR19BRDcyOTEg
aXMgbm90IHNldA0KIyBDT05GSUdfQUQ3MjkyIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0FENzI5OCBpcyBub3Qgc2V0DQojIENPTkZJR19BRDc0NzYgaXMgbm90
IHNldA0KIyBDT05GSUdfQUQ3NjA2X0lGQUNFX1BBUkFMTEVMIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0FENzYwNl9JRkFDRV9TUEkgaXMgbm90IHNldA0KIyBD
T05GSUdfQUQ3NzY2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FENzc2OF8xIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0FENzc4MCBpcyBub3Qgc2V0DQojIENPTkZJ
R19BRDc3OTEgaXMgbm90IHNldA0KIyBDT05GSUdfQUQ3NzkzIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0FENzg4NyBpcyBub3Qgc2V0DQojIENPTkZJR19BRDc5
MjMgaXMgbm90IHNldA0KIyBDT05GSUdfQUQ3OTQ5IGlzIG5vdCBzZXQNCiMg
Q09ORklHX0FENzk5WCBpcyBub3Qgc2V0DQojIENPTkZJR19DQzEwMDAxX0FE
QyBpcyBub3Qgc2V0DQojIENPTkZJR19FTlZFTE9QRV9ERVRFQ1RPUiBpcyBu
b3Qgc2V0DQojIENPTkZJR19ISTg0MzUgaXMgbm90IHNldA0KIyBDT05GSUdf
SFg3MTEgaXMgbm90IHNldA0KIyBDT05GSUdfTFRDMjQ3MSBpcyBub3Qgc2V0
DQojIENPTkZJR19MVEMyNDg1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0xUQzI0
OTYgaXMgbm90IHNldA0KIyBDT05GSUdfTFRDMjQ5NyBpcyBub3Qgc2V0DQoj
IENPTkZJR19NQVgxMDI3IGlzIG5vdCBzZXQNCiMgQ09ORklHX01BWDExMTAw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01BWDExMTggaXMgbm90IHNldA0KIyBD
T05GSUdfTUFYMTM2MyBpcyBub3Qgc2V0DQojIENPTkZJR19NQVg5NjExIGlz
IG5vdCBzZXQNCiMgQ09ORklHX01DUDMyMFggaXMgbm90IHNldA0KIyBDT05G
SUdfTUNQMzQyMiBpcyBub3Qgc2V0DQojIENPTkZJR19NQ1AzOTExIGlzIG5v
dCBzZXQNCiMgQ09ORklHX05BVTc4MDIgaXMgbm90IHNldA0KIyBDT05GSUdf
U0RfQURDX01PRFVMQVRPUiBpcyBub3Qgc2V0DQojIENPTkZJR19USV9BREMw
ODFDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RJX0FEQzA4MzIgaXMgbm90IHNl
dA0KIyBDT05GSUdfVElfQURDMDg0UzAyMSBpcyBub3Qgc2V0DQojIENPTkZJ
R19USV9BREMxMjEzOCBpcyBub3Qgc2V0DQojIENPTkZJR19USV9BREMxMDhT
MTAyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RJX0FEQzEyOFMwNTIgaXMgbm90
IHNldA0KIyBDT05GSUdfVElfQURDMTYxUzYyNiBpcyBub3Qgc2V0DQojIENP
TkZJR19USV9BRFMxMDE1IGlzIG5vdCBzZXQNCiMgQ09ORklHX1RJX0FEUzc5
NTAgaXMgbm90IHNldA0KIyBDT05GSUdfVElfQURTODM0NCBpcyBub3Qgc2V0
DQojIENPTkZJR19USV9BRFM4Njg4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1RJ
X0FEUzEyNFMwOCBpcyBub3Qgc2V0DQojIENPTkZJR19USV9UTEM0NTQxIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1ZGNjEwX0FEQyBpcyBub3Qgc2V0DQpDT05G
SUdfWElMSU5YX1hBREM9eQ0KIyBlbmQgb2YgQW5hbG9nIHRvIGRpZ2l0YWwg
Y29udmVydGVycw0KDQojDQojIEFuYWxvZyBGcm9udCBFbmRzDQojDQojIENP
TkZJR19JSU9fUkVTQ0FMRSBpcyBub3Qgc2V0DQojIGVuZCBvZiBBbmFsb2cg
RnJvbnQgRW5kcw0KDQojDQojIEFtcGxpZmllcnMNCiMNCiMgQ09ORklHX0FE
ODM2NiBpcyBub3Qgc2V0DQojIGVuZCBvZiBBbXBsaWZpZXJzDQoNCiMNCiMg
Q2hlbWljYWwgU2Vuc29ycw0KIw0KIyBDT05GSUdfQVRMQVNfUEhfU0VOU09S
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JNRTY4MCBpcyBub3Qgc2V0DQojIENP
TkZJR19DQ1M4MTEgaXMgbm90IHNldA0KIyBDT05GSUdfSUFRQ09SRSBpcyBu
b3Qgc2V0DQojIENPTkZJR19QTVM3MDAzIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1NFTlNJUklPTl9TR1AzMCBpcyBub3Qgc2V0DQojIENPTkZJR19TUFMzMCBp
cyBub3Qgc2V0DQojIENPTkZJR19WWjg5WCBpcyBub3Qgc2V0DQojIGVuZCBv
ZiBDaGVtaWNhbCBTZW5zb3JzDQoNCiMNCiMgSGlkIFNlbnNvciBJSU8gQ29t
bW9uDQojDQojIGVuZCBvZiBIaWQgU2Vuc29yIElJTyBDb21tb24NCg0KIw0K
IyBTU1AgU2Vuc29yIENvbW1vbg0KIw0KIyBDT05GSUdfSUlPX1NTUF9TRU5T
T1JIVUIgaXMgbm90IHNldA0KIyBlbmQgb2YgU1NQIFNlbnNvciBDb21tb24N
Cg0KIw0KIyBEaWdpdGFsIHRvIGFuYWxvZyBjb252ZXJ0ZXJzDQojDQojIENP
TkZJR19BRDUwNjQgaXMgbm90IHNldA0KIyBDT05GSUdfQUQ1MzYwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0FENTM4MCBpcyBub3Qgc2V0DQojIENPTkZJR19B
RDU0MjEgaXMgbm90IHNldA0KIyBDT05GSUdfQUQ1NDQ2IGlzIG5vdCBzZXQN
CiMgQ09ORklHX0FENTQ0OSBpcyBub3Qgc2V0DQojIENPTkZJR19BRDU1OTJS
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FENTU5M1IgaXMgbm90IHNldA0KIyBD
T05GSUdfQUQ1NTA0IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FENTYyNFJfU1BJ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0xUQzE2NjAgaXMgbm90IHNldA0KIyBD
T05GSUdfTFRDMjYzMiBpcyBub3Qgc2V0DQojIENPTkZJR19BRDU2ODZfU1BJ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FENTY5Nl9JMkMgaXMgbm90IHNldA0K
IyBDT05GSUdfQUQ1NzU1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FENTc1OCBp
cyBub3Qgc2V0DQojIENPTkZJR19BRDU3NjEgaXMgbm90IHNldA0KIyBDT05G
SUdfQUQ1NzY0IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FENTc5MSBpcyBub3Qg
c2V0DQojIENPTkZJR19BRDczMDMgaXMgbm90IHNldA0KIyBDT05GSUdfQUQ4
ODAxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RQT1RfREFDIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0RTNDQyNCBpcyBub3Qgc2V0DQojIENPTkZJR19NNjIzMzIg
aXMgbm90IHNldA0KIyBDT05GSUdfTUFYNTE3IGlzIG5vdCBzZXQNCiMgQ09O
RklHX01BWDU4MjEgaXMgbm90IHNldA0KIyBDT05GSUdfTUNQNDcyNSBpcyBu
b3Qgc2V0DQojIENPTkZJR19NQ1A0OTIyIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1RJX0RBQzA4MlMwODUgaXMgbm90IHNldA0KIyBDT05GSUdfVElfREFDNTU3
MSBpcyBub3Qgc2V0DQojIENPTkZJR19USV9EQUM3MzExIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1RJX0RBQzc2MTIgaXMgbm90IHNldA0KIyBDT05GSUdfVkY2
MTBfREFDIGlzIG5vdCBzZXQNCiMgZW5kIG9mIERpZ2l0YWwgdG8gYW5hbG9n
IGNvbnZlcnRlcnMNCg0KIw0KIyBJSU8gZHVtbXkgZHJpdmVyDQojDQojIGVu
ZCBvZiBJSU8gZHVtbXkgZHJpdmVyDQoNCiMNCiMgRnJlcXVlbmN5IFN5bnRo
ZXNpemVycyBERFMvUExMDQojDQoNCiMNCiMgQ2xvY2sgR2VuZXJhdG9yL0Rp
c3RyaWJ1dGlvbg0KIw0KIyBDT05GSUdfQUQ5NTIzIGlzIG5vdCBzZXQNCiMg
ZW5kIG9mIENsb2NrIEdlbmVyYXRvci9EaXN0cmlidXRpb24NCg0KIw0KIyBQ
aGFzZS1Mb2NrZWQgTG9vcCAoUExMKSBmcmVxdWVuY3kgc3ludGhlc2l6ZXJz
DQojDQojIENPTkZJR19BREY0MzUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FE
RjQzNzEgaXMgbm90IHNldA0KIyBlbmQgb2YgUGhhc2UtTG9ja2VkIExvb3Ag
KFBMTCkgZnJlcXVlbmN5IHN5bnRoZXNpemVycw0KIyBlbmQgb2YgRnJlcXVl
bmN5IFN5bnRoZXNpemVycyBERFMvUExMDQoNCiMNCiMgRGlnaXRhbCBneXJv
c2NvcGUgc2Vuc29ycw0KIw0KIyBDT05GSUdfQURJUzE2MDgwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0FESVMxNjEzMCBpcyBub3Qgc2V0DQojIENPTkZJR19B
RElTMTYxMzYgaXMgbm90IHNldA0KIyBDT05GSUdfQURJUzE2MjYwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0FEWFJTNDUwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0JNRzE2MCBpcyBub3Qgc2V0DQojIENPTkZJR19GWEFTMjEwMDJDIGlzIG5v
dCBzZXQNCiMgQ09ORklHX01QVTMwNTBfSTJDIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0lJT19TVF9HWVJPXzNBWElTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lU
RzMyMDAgaXMgbm90IHNldA0KIyBlbmQgb2YgRGlnaXRhbCBneXJvc2NvcGUg
c2Vuc29ycw0KDQojDQojIEhlYWx0aCBTZW5zb3JzDQojDQoNCiMNCiMgSGVh
cnQgUmF0ZSBNb25pdG9ycw0KIw0KIyBDT05GSUdfQUZFNDQwMyBpcyBub3Qg
c2V0DQojIENPTkZJR19BRkU0NDA0IGlzIG5vdCBzZXQNCiMgQ09ORklHX01B
WDMwMTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01BWDMwMTAyIGlzIG5vdCBz
ZXQNCiMgZW5kIG9mIEhlYXJ0IFJhdGUgTW9uaXRvcnMNCiMgZW5kIG9mIEhl
YWx0aCBTZW5zb3JzDQoNCiMNCiMgSHVtaWRpdHkgc2Vuc29ycw0KIw0KIyBD
T05GSUdfQU0yMzE1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RIVDExIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0hEQzEwMFggaXMgbm90IHNldA0KIyBDT05GSUdf
SFRTMjIxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hUVTIxIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1NJNzAwNSBpcyBub3Qgc2V0DQojIENPTkZJR19TSTcwMjAg
aXMgbm90IHNldA0KIyBlbmQgb2YgSHVtaWRpdHkgc2Vuc29ycw0KDQojDQoj
IEluZXJ0aWFsIG1lYXN1cmVtZW50IHVuaXRzDQojDQojIENPTkZJR19BRElT
MTY0MDAgaXMgbm90IHNldA0KIyBDT05GSUdfQURJUzE2NDYwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0FESVMxNjQ4MCBpcyBub3Qgc2V0DQojIENPTkZJR19C
TUkxNjBfSTJDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JNSTE2MF9TUEkgaXMg
bm90IHNldA0KIyBDT05GSUdfRlhPUzg3MDBfSTJDIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0ZYT1M4NzAwX1NQSSBpcyBub3Qgc2V0DQojIENPTkZJR19LTVg2
MSBpcyBub3Qgc2V0DQojIENPTkZJR19JTlZfTVBVNjA1MF9JMkMgaXMgbm90
IHNldA0KIyBDT05GSUdfSU5WX01QVTYwNTBfU1BJIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0lJT19TVF9MU002RFNYIGlzIG5vdCBzZXQNCiMgZW5kIG9mIElu
ZXJ0aWFsIG1lYXN1cmVtZW50IHVuaXRzDQoNCiMNCiMgTGlnaHQgc2Vuc29y
cw0KIw0KIyBDT05GSUdfQURKRF9TMzExIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0FEVVgxMDIwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FMMzMyMEEgaXMgbm90
IHNldA0KIyBDT05GSUdfQVBEUzkzMDAgaXMgbm90IHNldA0KIyBDT05GSUdf
QVBEUzk5NjAgaXMgbm90IHNldA0KIyBDT05GSUdfQkgxNzUwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0JIMTc4MCBpcyBub3Qgc2V0DQojIENPTkZJR19DTTMy
MTgxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NNMzIzMiBpcyBub3Qgc2V0DQoj
IENPTkZJR19DTTMzMjMgaXMgbm90IHNldA0KIyBDT05GSUdfQ00zNjA1IGlz
IG5vdCBzZXQNCiMgQ09ORklHX0NNMzY2NTEgaXMgbm90IHNldA0KIyBDT05G
SUdfR1AyQVAwMjBBMDBGIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNPUlNf
SVNMMjkwMTggaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19JU0wyOTAy
OCBpcyBub3Qgc2V0DQojIENPTkZJR19JU0wyOTEyNSBpcyBub3Qgc2V0DQoj
IENPTkZJR19KU0ExMjEyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JQUjA1MjEg
aXMgbm90IHNldA0KIyBDT05GSUdfTFRSNTAxIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0xWMDEwNENTIGlzIG5vdCBzZXQNCiMgQ09ORklHX01BWDQ0MDAwIGlz
IG5vdCBzZXQNCiMgQ09ORklHX01BWDQ0MDA5IGlzIG5vdCBzZXQNCiMgQ09O
RklHX05PQTEzMDUgaXMgbm90IHNldA0KIyBDT05GSUdfT1BUMzAwMSBpcyBu
b3Qgc2V0DQojIENPTkZJR19QQTEyMjAzMDAxIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NJMTEzMyBpcyBub3Qgc2V0DQojIENPTkZJR19TSTExNDUgaXMgbm90
IHNldA0KIyBDT05GSUdfU1RLMzMxMCBpcyBub3Qgc2V0DQojIENPTkZJR19T
VF9VVklTMjUgaXMgbm90IHNldA0KIyBDT05GSUdfVENTMzQxNCBpcyBub3Qg
c2V0DQojIENPTkZJR19UQ1MzNDcyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NF
TlNPUlNfVFNMMjU2MyBpcyBub3Qgc2V0DQojIENPTkZJR19UU0wyNTgzIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1RTTDI3NzIgaXMgbm90IHNldA0KIyBDT05G
SUdfVFNMNDUzMSBpcyBub3Qgc2V0DQojIENPTkZJR19VUzUxODJEIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1ZDTkw0MDAwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1ZDTkw0MDM1IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZFTUw2MDMwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1ZFTUw2MDcwIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1ZMNjE4MCBpcyBub3Qgc2V0DQojIENPTkZJR19aT1BUMjIwMSBpcyBub3Qg
c2V0DQojIGVuZCBvZiBMaWdodCBzZW5zb3JzDQoNCiMNCiMgTWFnbmV0b21l
dGVyIHNlbnNvcnMNCiMNCiMgQ09ORklHX0FLODk3NCBpcyBub3Qgc2V0DQoj
IENPTkZJR19BSzg5NzUgaXMgbm90IHNldA0KIyBDT05GSUdfQUswOTkxMSBp
cyBub3Qgc2V0DQojIENPTkZJR19CTUMxNTBfTUFHTl9JMkMgaXMgbm90IHNl
dA0KIyBDT05GSUdfQk1DMTUwX01BR05fU1BJIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01BRzMxMTAgaXMgbm90IHNldA0KIyBDT05GSUdfTU1DMzUyNDAgaXMg
bm90IHNldA0KIyBDT05GSUdfSUlPX1NUX01BR05fM0FYSVMgaXMgbm90IHNl
dA0KIyBDT05GSUdfU0VOU09SU19ITUM1ODQzX0kyQyBpcyBub3Qgc2V0DQoj
IENPTkZJR19TRU5TT1JTX0hNQzU4NDNfU1BJIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NFTlNPUlNfUk0zMTAwX0kyQyBpcyBub3Qgc2V0DQojIENPTkZJR19T
RU5TT1JTX1JNMzEwMF9TUEkgaXMgbm90IHNldA0KIyBlbmQgb2YgTWFnbmV0
b21ldGVyIHNlbnNvcnMNCg0KIw0KIyBNdWx0aXBsZXhlcnMNCiMNCiMgQ09O
RklHX0lJT19NVVggaXMgbm90IHNldA0KIyBlbmQgb2YgTXVsdGlwbGV4ZXJz
DQoNCiMNCiMgSW5jbGlub21ldGVyIHNlbnNvcnMNCiMNCiMgZW5kIG9mIElu
Y2xpbm9tZXRlciBzZW5zb3JzDQoNCiMNCiMgVHJpZ2dlcnMgLSBzdGFuZGFs
b25lDQojDQojIENPTkZJR19JSU9fSU5URVJSVVBUX1RSSUdHRVIgaXMgbm90
IHNldA0KIyBDT05GSUdfSUlPX1NZU0ZTX1RSSUdHRVIgaXMgbm90IHNldA0K
IyBlbmQgb2YgVHJpZ2dlcnMgLSBzdGFuZGFsb25lDQoNCiMNCiMgRGlnaXRh
bCBwb3RlbnRpb21ldGVycw0KIw0KIyBDT05GSUdfQUQ1MjcyIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0RTMTgwMyBpcyBub3Qgc2V0DQojIENPTkZJR19NQVg1
NDMyIGlzIG5vdCBzZXQNCiMgQ09ORklHX01BWDU0ODEgaXMgbm90IHNldA0K
IyBDT05GSUdfTUFYNTQ4NyBpcyBub3Qgc2V0DQojIENPTkZJR19NQ1A0MDE4
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01DUDQxMzEgaXMgbm90IHNldA0KIyBD
T05GSUdfTUNQNDUzMSBpcyBub3Qgc2V0DQojIENPTkZJR19NQ1A0MTAxMCBp
cyBub3Qgc2V0DQojIENPTkZJR19UUEwwMTAyIGlzIG5vdCBzZXQNCiMgZW5k
IG9mIERpZ2l0YWwgcG90ZW50aW9tZXRlcnMNCg0KIw0KIyBEaWdpdGFsIHBv
dGVudGlvc3RhdHMNCiMNCiMgQ09ORklHX0xNUDkxMDAwIGlzIG5vdCBzZXQN
CiMgZW5kIG9mIERpZ2l0YWwgcG90ZW50aW9zdGF0cw0KDQojDQojIFByZXNz
dXJlIHNlbnNvcnMNCiMNCiMgQ09ORklHX0FCUDA2ME1HIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0JNUDI4MCBpcyBub3Qgc2V0DQojIENPTkZJR19ETEhMNjBE
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RQUzMxMCBpcyBub3Qgc2V0DQojIENP
TkZJR19IUDAzIGlzIG5vdCBzZXQNCiMgQ09ORklHX01QTDExNV9JMkMgaXMg
bm90IHNldA0KIyBDT05GSUdfTVBMMTE1X1NQSSBpcyBub3Qgc2V0DQojIENP
TkZJR19NUEwzMTE1IGlzIG5vdCBzZXQNCiMgQ09ORklHX01TNTYxMSBpcyBu
b3Qgc2V0DQojIENPTkZJR19NUzU2MzcgaXMgbm90IHNldA0KIyBDT05GSUdf
SUlPX1NUX1BSRVNTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1Q1NDAzIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0hQMjA2QyBpcyBub3Qgc2V0DQojIENPTkZJR19a
UEEyMzI2IGlzIG5vdCBzZXQNCiMgZW5kIG9mIFByZXNzdXJlIHNlbnNvcnMN
Cg0KIw0KIyBMaWdodG5pbmcgc2Vuc29ycw0KIw0KIyBDT05GSUdfQVMzOTM1
IGlzIG5vdCBzZXQNCiMgZW5kIG9mIExpZ2h0bmluZyBzZW5zb3JzDQoNCiMN
CiMgUHJveGltaXR5IGFuZCBkaXN0YW5jZSBzZW5zb3JzDQojDQojIENPTkZJ
R19JU0wyOTUwMSBpcyBub3Qgc2V0DQojIENPTkZJR19MSURBUl9MSVRFX1Yy
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01CMTIzMiBpcyBub3Qgc2V0DQojIENP
TkZJR19QSU5HIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JGRDc3NDAyIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1NSRjA0IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NY
OTUwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TUkYwOCBpcyBub3Qgc2V0DQoj
IENPTkZJR19WTDUzTDBYX0kyQyBpcyBub3Qgc2V0DQojIGVuZCBvZiBQcm94
aW1pdHkgYW5kIGRpc3RhbmNlIHNlbnNvcnMNCg0KIw0KIyBSZXNvbHZlciB0
byBkaWdpdGFsIGNvbnZlcnRlcnMNCiMNCiMgQ09ORklHX0FEMlM5MCBpcyBu
b3Qgc2V0DQojIENPTkZJR19BRDJTMTIwMCBpcyBub3Qgc2V0DQojIGVuZCBv
ZiBSZXNvbHZlciB0byBkaWdpdGFsIGNvbnZlcnRlcnMNCg0KIw0KIyBUZW1w
ZXJhdHVyZSBzZW5zb3JzDQojDQojIENPTkZJR19MVEMyOTgzIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX01BWElNX1RIRVJNT0NPVVBMRSBpcyBub3Qgc2V0DQoj
IENPTkZJR19NTFg5MDYxNCBpcyBub3Qgc2V0DQojIENPTkZJR19NTFg5MDYz
MiBpcyBub3Qgc2V0DQojIENPTkZJR19UTVAwMDYgaXMgbm90IHNldA0KIyBD
T05GSUdfVE1QMDA3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1RTWVMwMSBpcyBu
b3Qgc2V0DQojIENPTkZJR19UU1lTMDJEIGlzIG5vdCBzZXQNCiMgQ09ORklH
X01BWDMxODU2IGlzIG5vdCBzZXQNCiMgZW5kIG9mIFRlbXBlcmF0dXJlIHNl
bnNvcnMNCg0KIyBDT05GSUdfUFdNIGlzIG5vdCBzZXQNCg0KIw0KIyBJUlEg
Y2hpcCBzdXBwb3J0DQojDQpDT05GSUdfSVJRQ0hJUD15DQpDT05GSUdfQVJN
X0dJQz15DQpDT05GSUdfQVJNX0dJQ19NQVhfTlI9MQ0KQ09ORklHX0FSTV9H
SUNfVjM9eQ0KQ09ORklHX0FSTV9HSUNfVjNfSVRTPXkNCiMgQ09ORklHX0FM
X0ZJQyBpcyBub3Qgc2V0DQpDT05GSUdfUEFSVElUSU9OX1BFUkNQVT15DQoj
IGVuZCBvZiBJUlEgY2hpcCBzdXBwb3J0DQoNCiMgQ09ORklHX0lQQUNLX0JV
UyBpcyBub3Qgc2V0DQpDT05GSUdfUkVTRVRfQ09OVFJPTExFUj15DQojIENP
TkZJR19SRVNFVF9CUkNNU1RCX1JFU0NBTCBpcyBub3Qgc2V0DQojIENPTkZJ
R19SRVNFVF9JTlRFTF9HVyBpcyBub3Qgc2V0DQojIENPTkZJR19SRVNFVF9U
SV9TWVNDT04gaXMgbm90IHNldA0KDQojDQojIFBIWSBTdWJzeXN0ZW0NCiMN
CkNPTkZJR19HRU5FUklDX1BIWT15DQojIENPTkZJR19QSFlfWEdFTkUgaXMg
bm90IHNldA0KIyBDT05GSUdfQkNNX0tPTkFfVVNCMl9QSFkgaXMgbm90IHNl
dA0KIyBDT05GSUdfUEhZX0NBREVOQ0VfRFAgaXMgbm90IHNldA0KIyBDT05G
SUdfUEhZX0NBREVOQ0VfRFBIWSBpcyBub3Qgc2V0DQojIENPTkZJR19QSFlf
Q0FERU5DRV9TSUVSUkEgaXMgbm90IHNldA0KIyBDT05GSUdfUEhZX0ZTTF9J
TVg4TVFfVVNCIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BIWV9NSVhFTF9NSVBJ
X0RQSFkgaXMgbm90IHNldA0KIyBDT05GSUdfUEhZX1BYQV8yOE5NX0hTSUMg
aXMgbm90IHNldA0KIyBDT05GSUdfUEhZX1BYQV8yOE5NX1VTQjIgaXMgbm90
IHNldA0KIyBDT05GSUdfUEhZX0NQQ0FQX1VTQiBpcyBub3Qgc2V0DQojIENP
TkZJR19QSFlfTUFQUEhPTkVfTURNNjYwMCBpcyBub3Qgc2V0DQojIENPTkZJ
R19QSFlfSU5URUxfRU1NQyBpcyBub3Qgc2V0DQojIGVuZCBvZiBQSFkgU3Vi
c3lzdGVtDQoNCiMgQ09ORklHX1BPV0VSQ0FQIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01DQiBpcyBub3Qgc2V0DQoNCiMNCiMgUGVyZm9ybWFuY2UgbW9uaXRv
ciBzdXBwb3J0DQojDQojIENPTkZJR19BUk1fQ0NJX1BNVSBpcyBub3Qgc2V0
DQojIENPTkZJR19BUk1fQ0NOIGlzIG5vdCBzZXQNCkNPTkZJR19BUk1fUE1V
PXkNCiMgQ09ORklHX0FSTV9EU1VfUE1VIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0FSTV9TUEVfUE1VIGlzIG5vdCBzZXQNCiMgZW5kIG9mIFBlcmZvcm1hbmNl
IG1vbml0b3Igc3VwcG9ydA0KDQpDT05GSUdfUkFTPXkNCg0KIw0KIyBBbmRy
b2lkDQojDQpDT05GSUdfQU5EUk9JRD15DQojIENPTkZJR19BTkRST0lEX0JJ
TkRFUl9JUEMgaXMgbm90IHNldA0KIyBlbmQgb2YgQW5kcm9pZA0KDQojIENP
TkZJR19MSUJOVkRJTU0gaXMgbm90IHNldA0KIyBDT05GSUdfREFYIGlzIG5v
dCBzZXQNCkNPTkZJR19OVk1FTT15DQpDT05GSUdfTlZNRU1fU1lTRlM9eQ0K
Q09ORklHX05WTUVNX1pZTlFNUD15DQoNCiMNCiMgSFcgdHJhY2luZyBzdXBw
b3J0DQojDQojIENPTkZJR19TVE0gaXMgbm90IHNldA0KIyBDT05GSUdfSU5U
RUxfVEggaXMgbm90IHNldA0KIyBlbmQgb2YgSFcgdHJhY2luZyBzdXBwb3J0
DQoNCkNPTkZJR19GUEdBPXkNCiMgQ09ORklHX0FMVEVSQV9QUl9JUF9DT1JF
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZQR0FfTUdSX0FMVEVSQV9QU19TUEkg
aXMgbm90IHNldA0KIyBDT05GSUdfRlBHQV9NR1JfWElMSU5YX1NQSSBpcyBu
b3Qgc2V0DQojIENPTkZJR19GUEdBX01HUl9JQ0U0MF9TUEkgaXMgbm90IHNl
dA0KIyBDT05GSUdfRlBHQV9NR1JfTUFDSFhPMl9TUEkgaXMgbm90IHNldA0K
Q09ORklHX0ZQR0FfQlJJREdFPXkNCiMgQ09ORklHX0FMVEVSQV9GUkVFWkVf
QlJJREdFIGlzIG5vdCBzZXQNCkNPTkZJR19YSUxJTlhfUFJfREVDT1VQTEVS
PXkNCkNPTkZJR19GUEdBX1JFR0lPTj15DQojIENPTkZJR19PRl9GUEdBX1JF
R0lPTiBpcyBub3Qgc2V0DQojIENPTkZJR19GUEdBX0RGTCBpcyBub3Qgc2V0
DQpDT05GSUdfRlBHQV9NR1JfWllOUU1QX0ZQR0E9eQ0KIyBDT05GSUdfRlNJ
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1RFRSBpcyBub3Qgc2V0DQpDT05GSUdf
UE1fT1BQPXkNCiMgQ09ORklHX1NJT1ggaXMgbm90IHNldA0KIyBDT05GSUdf
U0xJTUJVUyBpcyBub3Qgc2V0DQojIENPTkZJR19JTlRFUkNPTk5FQ1QgaXMg
bm90IHNldA0KIyBDT05GSUdfQ09VTlRFUiBpcyBub3Qgc2V0DQojIGVuZCBv
ZiBEZXZpY2UgRHJpdmVycw0KDQojDQojIEZpbGUgc3lzdGVtcw0KIw0KQ09O
RklHX0RDQUNIRV9XT1JEX0FDQ0VTUz15DQojIENPTkZJR19WQUxJREFURV9G
U19QQVJTRVIgaXMgbm90IHNldA0KQ09ORklHX0ZTX0lPTUFQPXkNCkNPTkZJ
R19FWFQyX0ZTPXkNCiMgQ09ORklHX0VYVDJfRlNfWEFUVFIgaXMgbm90IHNl
dA0KQ09ORklHX0VYVDNfRlM9eQ0KIyBDT05GSUdfRVhUM19GU19QT1NJWF9B
Q0wgaXMgbm90IHNldA0KIyBDT05GSUdfRVhUM19GU19TRUNVUklUWSBpcyBu
b3Qgc2V0DQpDT05GSUdfRVhUNF9GUz15DQpDT05GSUdfRVhUNF9GU19QT1NJ
WF9BQ0w9eQ0KQ09ORklHX0VYVDRfRlNfU0VDVVJJVFk9eQ0KIyBDT05GSUdf
RVhUNF9ERUJVRyBpcyBub3Qgc2V0DQpDT05GSUdfSkJEMj15DQojIENPTkZJ
R19KQkQyX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19GU19NQkNBQ0hFPXkN
CiMgQ09ORklHX1JFSVNFUkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0pG
U19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19YRlNfRlMgaXMgbm90IHNldA0K
IyBDT05GSUdfR0ZTMl9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19PQ0ZTMl9G
UyBpcyBub3Qgc2V0DQpDT05GSUdfQlRSRlNfRlM9eQ0KIyBDT05GSUdfQlRS
RlNfRlNfUE9TSVhfQUNMIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JUUkZTX0ZT
X0NIRUNLX0lOVEVHUklUWSBpcyBub3Qgc2V0DQojIENPTkZJR19CVFJGU19G
U19SVU5fU0FOSVRZX1RFU1RTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JUUkZT
X0RFQlVHIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JUUkZTX0FTU0VSVCBpcyBu
b3Qgc2V0DQojIENPTkZJR19CVFJGU19GU19SRUZfVkVSSUZZIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX05JTEZTMl9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19G
MkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZTX0RBWCBpcyBub3Qgc2V0
DQpDT05GSUdfRlNfUE9TSVhfQUNMPXkNCkNPTkZJR19FWFBPUlRGUz15DQoj
IENPTkZJR19FWFBPUlRGU19CTE9DS19PUFMgaXMgbm90IHNldA0KQ09ORklH
X0ZJTEVfTE9DS0lORz15DQpDT05GSUdfTUFOREFUT1JZX0ZJTEVfTE9DS0lO
Rz15DQojIENPTkZJR19GU19FTkNSWVBUSU9OIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0ZTX1ZFUklUWSBpcyBub3Qgc2V0DQpDT05GSUdfRlNOT1RJRlk9eQ0K
Q09ORklHX0ROT1RJRlk9eQ0KQ09ORklHX0lOT1RJRllfVVNFUj15DQojIENP
TkZJR19GQU5PVElGWSBpcyBub3Qgc2V0DQpDT05GSUdfUVVPVEE9eQ0KIyBD
T05GSUdfUVVPVEFfTkVUTElOS19JTlRFUkZBQ0UgaXMgbm90IHNldA0KQ09O
RklHX1BSSU5UX1FVT1RBX1dBUk5JTkc9eQ0KIyBDT05GSUdfUVVPVEFfREVC
VUcgaXMgbm90IHNldA0KQ09ORklHX1FVT1RBX1RSRUU9eQ0KIyBDT05GSUdf
UUZNVF9WMSBpcyBub3Qgc2V0DQpDT05GSUdfUUZNVF9WMj15DQpDT05GSUdf
UVVPVEFDVEw9eQ0KQ09ORklHX0FVVE9GUzRfRlM9eQ0KQ09ORklHX0FVVE9G
U19GUz15DQojIENPTkZJR19GVVNFX0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19P
VkVSTEFZX0ZTPXkNCkNPTkZJR19PVkVSTEFZX0ZTX1JFRElSRUNUX0RJUj15
DQpDT05GSUdfT1ZFUkxBWV9GU19SRURJUkVDVF9BTFdBWVNfRk9MTE9XPXkN
CkNPTkZJR19PVkVSTEFZX0ZTX0lOREVYPXkNCiMgQ09ORklHX09WRVJMQVlf
RlNfTkZTX0VYUE9SVCBpcyBub3Qgc2V0DQojIENPTkZJR19PVkVSTEFZX0ZT
X1hJTk9fQVVUTyBpcyBub3Qgc2V0DQojIENPTkZJR19PVkVSTEFZX0ZTX01F
VEFDT1BZIGlzIG5vdCBzZXQNCg0KIw0KIyBDYWNoZXMNCiMNCiMgQ09ORklH
X0ZTQ0FDSEUgaXMgbm90IHNldA0KIyBlbmQgb2YgQ2FjaGVzDQoNCiMNCiMg
Q0QtUk9NL0RWRCBGaWxlc3lzdGVtcw0KIw0KIyBDT05GSUdfSVNPOTY2MF9G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19VREZfRlMgaXMgbm90IHNldA0KIyBl
bmQgb2YgQ0QtUk9NL0RWRCBGaWxlc3lzdGVtcw0KDQojDQojIERPUy9GQVQv
TlQgRmlsZXN5c3RlbXMNCiMNCkNPTkZJR19GQVRfRlM9eQ0KQ09ORklHX01T
RE9TX0ZTPXkNCkNPTkZJR19WRkFUX0ZTPXkNCkNPTkZJR19GQVRfREVGQVVM
VF9DT0RFUEFHRT00MzcNCkNPTkZJR19GQVRfREVGQVVMVF9JT0NIQVJTRVQ9
Imlzbzg4NTktMSINCiMgQ09ORklHX0ZBVF9ERUZBVUxUX1VURjggaXMgbm90
IHNldA0KIyBDT05GSUdfTlRGU19GUyBpcyBub3Qgc2V0DQojIGVuZCBvZiBE
T1MvRkFUL05UIEZpbGVzeXN0ZW1zDQoNCiMNCiMgUHNldWRvIGZpbGVzeXN0
ZW1zDQojDQpDT05GSUdfUFJPQ19GUz15DQojIENPTkZJR19QUk9DX0tDT1JF
IGlzIG5vdCBzZXQNCkNPTkZJR19QUk9DX1NZU0NUTD15DQpDT05GSUdfUFJP
Q19QQUdFX01PTklUT1I9eQ0KIyBDT05GSUdfUFJPQ19DSElMRFJFTiBpcyBu
b3Qgc2V0DQpDT05GSUdfS0VSTkZTPXkNCkNPTkZJR19TWVNGUz15DQpDT05G
SUdfVE1QRlM9eQ0KQ09ORklHX1RNUEZTX1BPU0lYX0FDTD15DQpDT05GSUdf
VE1QRlNfWEFUVFI9eQ0KQ09ORklHX0hVR0VUTEJGUz15DQpDT05GSUdfSFVH
RVRMQl9QQUdFPXkNCkNPTkZJR19NRU1GRF9DUkVBVEU9eQ0KQ09ORklHX0FS
Q0hfSEFTX0dJR0FOVElDX1BBR0U9eQ0KQ09ORklHX0NPTkZJR0ZTX0ZTPXkN
CkNPTkZJR19FRklWQVJfRlM9bQ0KIyBlbmQgb2YgUHNldWRvIGZpbGVzeXN0
ZW1zDQoNCkNPTkZJR19NSVNDX0ZJTEVTWVNURU1TPXkNCiMgQ09ORklHX09S
QU5HRUZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FERlNfRlMgaXMgbm90
IHNldA0KIyBDT05GSUdfQUZGU19GUyBpcyBub3Qgc2V0DQpDT05GSUdfRUNS
WVBUX0ZTPXkNCiMgQ09ORklHX0VDUllQVF9GU19NRVNTQUdJTkcgaXMgbm90
IHNldA0KIyBDT05GSUdfSEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hG
U1BMVVNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQkVGU19GUyBpcyBub3Qg
c2V0DQojIENPTkZJR19CRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfRUZT
X0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19KRkZTMl9GUz15DQpDT05GSUdfSkZG
UzJfRlNfREVCVUc9MA0KQ09ORklHX0pGRlMyX0ZTX1dSSVRFQlVGRkVSPXkN
CiMgQ09ORklHX0pGRlMyX0ZTX1dCVUZfVkVSSUZZIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0pGRlMyX1NVTU1BUlkgaXMgbm90IHNldA0KQ09ORklHX0pGRlMy
X0ZTX1hBVFRSPXkNCkNPTkZJR19KRkZTMl9GU19QT1NJWF9BQ0w9eQ0KQ09O
RklHX0pGRlMyX0ZTX1NFQ1VSSVRZPXkNCkNPTkZJR19KRkZTMl9DT01QUkVT
U0lPTl9PUFRJT05TPXkNCkNPTkZJR19KRkZTMl9aTElCPXkNCkNPTkZJR19K
RkZTMl9MWk89eQ0KQ09ORklHX0pGRlMyX1JUSU1FPXkNCkNPTkZJR19KRkZT
Ml9SVUJJTj15DQojIENPTkZJR19KRkZTMl9DTU9ERV9OT05FIGlzIG5vdCBz
ZXQNCkNPTkZJR19KRkZTMl9DTU9ERV9QUklPUklUWT15DQojIENPTkZJR19K
RkZTMl9DTU9ERV9TSVpFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0pGRlMyX0NN
T0RFX0ZBVk9VUkxaTyBpcyBub3Qgc2V0DQpDT05GSUdfQ1JBTUZTPXkNCkNP
TkZJR19DUkFNRlNfQkxPQ0tERVY9eQ0KIyBDT05GSUdfQ1JBTUZTX01URCBp
cyBub3Qgc2V0DQojIENPTkZJR19TUVVBU0hGUyBpcyBub3Qgc2V0DQojIENP
TkZJR19WWEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JTklYX0ZTIGlz
IG5vdCBzZXQNCiMgQ09ORklHX09NRlNfRlMgaXMgbm90IHNldA0KIyBDT05G
SUdfSFBGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19RTlg0RlNfRlMgaXMg
bm90IHNldA0KIyBDT05GSUdfUU5YNkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1JPTUZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BTVE9SRSBpcyBu
b3Qgc2V0DQojIENPTkZJR19TWVNWX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1VGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19FUk9GU19GUyBpcyBub3Qg
c2V0DQpDT05GSUdfTkVUV09SS19GSUxFU1lTVEVNUz15DQpDT05GSUdfTkZT
X0ZTPXkNCkNPTkZJR19ORlNfVjI9eQ0KQ09ORklHX05GU19WMz15DQpDT05G
SUdfTkZTX1YzX0FDTD15DQpDT05GSUdfTkZTX1Y0PXkNCiMgQ09ORklHX05G
U19TV0FQIGlzIG5vdCBzZXQNCkNPTkZJR19ORlNfVjRfMT15DQpDT05GSUdf
TkZTX1Y0XzI9eQ0KQ09ORklHX1BORlNfRklMRV9MQVlPVVQ9eQ0KQ09ORklH
X1BORlNfRkxFWEZJTEVfTEFZT1VUPW0NCkNPTkZJR19ORlNfVjRfMV9JTVBM
RU1FTlRBVElPTl9JRF9ET01BSU49Imtlcm5lbC5vcmciDQojIENPTkZJR19O
RlNfVjRfMV9NSUdSQVRJT04gaXMgbm90IHNldA0KQ09ORklHX1JPT1RfTkZT
PXkNCiMgQ09ORklHX05GU19VU0VfTEVHQUNZX0ROUyBpcyBub3Qgc2V0DQpD
T05GSUdfTkZTX1VTRV9LRVJORUxfRE5TPXkNCkNPTkZJR19ORlNfRElTQUJM
RV9VRFBfU1VQUE9SVD15DQojIENPTkZJR19ORlNEIGlzIG5vdCBzZXQNCkNP
TkZJR19HUkFDRV9QRVJJT0Q9eQ0KQ09ORklHX0xPQ0tEPXkNCkNPTkZJR19M
T0NLRF9WND15DQpDT05GSUdfTkZTX0FDTF9TVVBQT1JUPXkNCkNPTkZJR19O
RlNfQ09NTU9OPXkNCkNPTkZJR19TVU5SUEM9eQ0KQ09ORklHX1NVTlJQQ19H
U1M9eQ0KQ09ORklHX1NVTlJQQ19CQUNLQ0hBTk5FTD15DQojIENPTkZJR19T
VU5SUENfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfQ0VQSF9GUyBpcyBu
b3Qgc2V0DQojIENPTkZJR19DSUZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NP
REFfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQUZTX0ZTIGlzIG5vdCBzZXQN
CiMgQ09ORklHXzlQX0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19OTFM9eQ0KQ09O
RklHX05MU19ERUZBVUxUPSJpc284ODU5LTEiDQpDT05GSUdfTkxTX0NPREVQ
QUdFXzQzNz15DQojIENPTkZJR19OTFNfQ09ERVBBR0VfNzM3IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV83NzUgaXMgbm90IHNldA0KIyBD
T05GSUdfTkxTX0NPREVQQUdFXzg1MCBpcyBub3Qgc2V0DQojIENPTkZJR19O
TFNfQ09ERVBBR0VfODUyIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RF
UEFHRV84NTUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1
NyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODYwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjEgaXMgbm90IHNldA0K
IyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MiBpcyBub3Qgc2V0DQojIENPTkZJ
R19OTFNfQ09ERVBBR0VfODYzIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19D
T0RFUEFHRV84NjQgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdF
Xzg2NSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY2IGlz
IG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjkgaXMgbm90IHNl
dA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzkzNiBpcyBub3Qgc2V0DQojIENP
TkZJR19OTFNfQ09ERVBBR0VfOTUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M
U19DT0RFUEFHRV85MzIgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ
QUdFXzk0OSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODc0
IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzggaXMgbm90IHNl
dA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTAgaXMgbm90IHNldA0KIyBD
T05GSUdfTkxTX0NPREVQQUdFXzEyNTEgaXMgbm90IHNldA0KIyBDT05GSUdf
TkxTX0FTQ0lJIGlzIG5vdCBzZXQNCkNPTkZJR19OTFNfSVNPODg1OV8xPXkN
CiMgQ09ORklHX05MU19JU084ODU5XzIgaXMgbm90IHNldA0KIyBDT05GSUdf
TkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1
OV80IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzUgaXMgbm90
IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfNiBpcyBub3Qgc2V0DQojIENP
TkZJR19OTFNfSVNPODg1OV83IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19J
U084ODU5XzkgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTMg
aXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTQgaXMgbm90IHNl
dA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTUgaXMgbm90IHNldA0KIyBDT05G
SUdfTkxTX0tPSThfUiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfS09JOF9V
IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19NQUNfUk9NQU4gaXMgbm90IHNl
dA0KIyBDT05GSUdfTkxTX01BQ19DRUxUSUMgaXMgbm90IHNldA0KIyBDT05G
SUdfTkxTX01BQ19DRU5URVVSTyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNf
TUFDX0NST0FUSUFOIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19NQUNfQ1lS
SUxMSUMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX01BQ19HQUVMSUMgaXMg
bm90IHNldA0KIyBDT05GSUdfTkxTX01BQ19HUkVFSyBpcyBub3Qgc2V0DQoj
IENPTkZJR19OTFNfTUFDX0lDRUxBTkQgaXMgbm90IHNldA0KIyBDT05GSUdf
TkxTX01BQ19JTlVJVCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfTUFDX1JP
TUFOSUFOIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19NQUNfVFVSS0lTSCBp
cyBub3Qgc2V0DQojIENPTkZJR19OTFNfVVRGOCBpcyBub3Qgc2V0DQojIENP
TkZJR19ETE0gaXMgbm90IHNldA0KIyBDT05GSUdfVU5JQ09ERSBpcyBub3Qg
c2V0DQpDT05GSUdfSU9fV1E9eQ0KIyBlbmQgb2YgRmlsZSBzeXN0ZW1zDQoN
CiMNCiMgU2VjdXJpdHkgb3B0aW9ucw0KIw0KQ09ORklHX0tFWVM9eQ0KIyBD
T05GSUdfS0VZU19SRVFVRVNUX0NBQ0hFIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1BFUlNJU1RFTlRfS0VZUklOR1MgaXMgbm90IHNldA0KIyBDT05GSUdfQklH
X0tFWVMgaXMgbm90IHNldA0KIyBDT05GSUdfRU5DUllQVEVEX0tFWVMgaXMg
bm90IHNldA0KIyBDT05GSUdfS0VZX0RIX09QRVJBVElPTlMgaXMgbm90IHNl
dA0KIyBDT05GSUdfU0VDVVJJVFlfRE1FU0dfUkVTVFJJQ1QgaXMgbm90IHNl
dA0KIyBDT05GSUdfU0VDVVJJVFkgaXMgbm90IHNldA0KIyBDT05GSUdfU0VD
VVJJVFlGUyBpcyBub3Qgc2V0DQpDT05GSUdfSEFWRV9IQVJERU5FRF9VU0VS
Q09QWV9BTExPQ0FUT1I9eQ0KIyBDT05GSUdfSEFSREVORURfVVNFUkNPUFkg
aXMgbm90IHNldA0KIyBDT05GSUdfRk9SVElGWV9TT1VSQ0UgaXMgbm90IHNl
dA0KIyBDT05GSUdfU1RBVElDX1VTRVJNT0RFSEVMUEVSIGlzIG5vdCBzZXQN
CkNPTkZJR19ERUZBVUxUX1NFQ1VSSVRZX0RBQz15DQpDT05GSUdfTFNNPSJs
b2NrZG93bix5YW1hLGxvYWRwaW4sc2FmZXNldGlkLGludGVncml0eSINCg0K
Iw0KIyBLZXJuZWwgaGFyZGVuaW5nIG9wdGlvbnMNCiMNCg0KIw0KIyBNZW1v
cnkgaW5pdGlhbGl6YXRpb24NCiMNCkNPTkZJR19JTklUX1NUQUNLX05PTkU9
eQ0KIyBDT05GSUdfSU5JVF9PTl9BTExPQ19ERUZBVUxUX09OIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0lOSVRfT05fRlJFRV9ERUZBVUxUX09OIGlzIG5vdCBz
ZXQNCiMgZW5kIG9mIE1lbW9yeSBpbml0aWFsaXphdGlvbg0KIyBlbmQgb2Yg
S2VybmVsIGhhcmRlbmluZyBvcHRpb25zDQojIGVuZCBvZiBTZWN1cml0eSBv
cHRpb25zDQoNCkNPTkZJR19YT1JfQkxPQ0tTPXkNCkNPTkZJR19DUllQVE89
eQ0KDQojDQojIENyeXB0byBjb3JlIG9yIGhlbHBlcg0KIw0KQ09ORklHX0NS
WVBUT19BTEdBUEk9eQ0KQ09ORklHX0NSWVBUT19BTEdBUEkyPXkNCkNPTkZJ
R19DUllQVE9fQUVBRD15DQpDT05GSUdfQ1JZUFRPX0FFQUQyPXkNCkNPTkZJ
R19DUllQVE9fU0tDSVBIRVI9eQ0KQ09ORklHX0NSWVBUT19TS0NJUEhFUjI9
eQ0KQ09ORklHX0NSWVBUT19IQVNIPXkNCkNPTkZJR19DUllQVE9fSEFTSDI9
eQ0KQ09ORklHX0NSWVBUT19STkc9eQ0KQ09ORklHX0NSWVBUT19STkcyPXkN
CkNPTkZJR19DUllQVE9fUk5HX0RFRkFVTFQ9eQ0KQ09ORklHX0NSWVBUT19B
S0NJUEhFUjI9eQ0KQ09ORklHX0NSWVBUT19BS0NJUEhFUj15DQpDT05GSUdf
Q1JZUFRPX0tQUDI9eQ0KQ09ORklHX0NSWVBUT19LUFA9eQ0KQ09ORklHX0NS
WVBUT19BQ09NUDI9eQ0KQ09ORklHX0NSWVBUT19NQU5BR0VSPXkNCkNPTkZJ
R19DUllQVE9fTUFOQUdFUjI9eQ0KIyBDT05GSUdfQ1JZUFRPX1VTRVIgaXMg
bm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX01BTkFHRVJfRElTQUJMRV9URVNU
UyBpcyBub3Qgc2V0DQojIENPTkZJR19DUllQVE9fTUFOQUdFUl9FWFRSQV9U
RVNUUyBpcyBub3Qgc2V0DQpDT05GSUdfQ1JZUFRPX0dGMTI4TVVMPXkNCkNP
TkZJR19DUllQVE9fTlVMTD15DQpDT05GSUdfQ1JZUFRPX05VTEwyPXkNCiMg
Q09ORklHX0NSWVBUT19QQ1JZUFQgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZ
UFRPX0NSWVBURCBpcyBub3Qgc2V0DQpDT05GSUdfQ1JZUFRPX0FVVEhFTkM9
bQ0KIyBDT05GSUdfQ1JZUFRPX1RFU1QgaXMgbm90IHNldA0KQ09ORklHX0NS
WVBUT19FTkdJTkU9bQ0KDQojDQojIFB1YmxpYy1rZXkgY3J5cHRvZ3JhcGh5
DQojDQpDT05GSUdfQ1JZUFRPX1JTQT15DQojIENPTkZJR19DUllQVE9fREgg
aXMgbm90IHNldA0KQ09ORklHX0NSWVBUT19FQ0M9eQ0KQ09ORklHX0NSWVBU
T19FQ0RIPXkNCiMgQ09ORklHX0NSWVBUT19FQ1JEU0EgaXMgbm90IHNldA0K
IyBDT05GSUdfQ1JZUFRPX0NVUlZFMjU1MTkgaXMgbm90IHNldA0KDQojDQoj
IEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiB3aXRoIEFzc29jaWF0ZWQgRGF0
YQ0KIw0KQ09ORklHX0NSWVBUT19DQ009eQ0KQ09ORklHX0NSWVBUT19HQ009
eQ0KIyBDT05GSUdfQ1JZUFRPX0NIQUNIQTIwUE9MWTEzMDUgaXMgbm90IHNl
dA0KIyBDT05GSUdfQ1JZUFRPX0FFR0lTMTI4IGlzIG5vdCBzZXQNCkNPTkZJ
R19DUllQVE9fU0VRSVY9eQ0KQ09ORklHX0NSWVBUT19FQ0hBSU5JVj1tDQoN
CiMNCiMgQmxvY2sgbW9kZXMNCiMNCkNPTkZJR19DUllQVE9fQ0JDPXkNCiMg
Q09ORklHX0NSWVBUT19DRkIgaXMgbm90IHNldA0KQ09ORklHX0NSWVBUT19D
VFI9eQ0KIyBDT05GSUdfQ1JZUFRPX0NUUyBpcyBub3Qgc2V0DQpDT05GSUdf
Q1JZUFRPX0VDQj15DQojIENPTkZJR19DUllQVE9fTFJXIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0NSWVBUT19PRkIgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZ
UFRPX1BDQkMgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX1hUUyBpcyBu
b3Qgc2V0DQojIENPTkZJR19DUllQVE9fS0VZV1JBUCBpcyBub3Qgc2V0DQoj
IENPTkZJR19DUllQVE9fQURJQU5UVU0gaXMgbm90IHNldA0KIyBDT05GSUdf
Q1JZUFRPX0VTU0lWIGlzIG5vdCBzZXQNCg0KIw0KIyBIYXNoIG1vZGVzDQoj
DQpDT05GSUdfQ1JZUFRPX0NNQUM9eQ0KQ09ORklHX0NSWVBUT19ITUFDPXkN
CiMgQ09ORklHX0NSWVBUT19YQ0JDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NS
WVBUT19WTUFDIGlzIG5vdCBzZXQNCg0KIw0KIyBEaWdlc3QNCiMNCkNPTkZJ
R19DUllQVE9fQ1JDMzJDPXkNCiMgQ09ORklHX0NSWVBUT19DUkMzMiBpcyBu
b3Qgc2V0DQpDT05GSUdfQ1JZUFRPX1hYSEFTSD15DQpDT05GSUdfQ1JZUFRP
X0JMQUtFMkI9eQ0KIyBDT05GSUdfQ1JZUFRPX0JMQUtFMlMgaXMgbm90IHNl
dA0KQ09ORklHX0NSWVBUT19DUkNUMTBESUY9eQ0KQ09ORklHX0NSWVBUT19H
SEFTSD15DQojIENPTkZJR19DUllQVE9fUE9MWTEzMDUgaXMgbm90IHNldA0K
IyBDT05GSUdfQ1JZUFRPX01ENCBpcyBub3Qgc2V0DQpDT05GSUdfQ1JZUFRP
X01ENT15DQojIENPTkZJR19DUllQVE9fTUlDSEFFTF9NSUMgaXMgbm90IHNl
dA0KIyBDT05GSUdfQ1JZUFRPX1JNRDEyOCBpcyBub3Qgc2V0DQojIENPTkZJ
R19DUllQVE9fUk1EMTYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSWVBUT19S
TUQyNTYgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX1JNRDMyMCBpcyBu
b3Qgc2V0DQojIENPTkZJR19DUllQVE9fU0hBMSBpcyBub3Qgc2V0DQpDT05G
SUdfQ1JZUFRPX1NIQTI1Nj15DQojIENPTkZJR19DUllQVE9fU0hBNTEyIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0NSWVBUT19TSEEzIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0NSWVBUT19TTTMgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRP
X1NUUkVFQk9HIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSWVBUT19UR1IxOTIg
aXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX1dQNTEyIGlzIG5vdCBzZXQN
Cg0KIw0KIyBDaXBoZXJzDQojDQpDT05GSUdfQ1JZUFRPX0FFUz15DQojIENP
TkZJR19DUllQVE9fQUVTX1RJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSWVBU
T19BTlVCSVMgaXMgbm90IHNldA0KQ09ORklHX0NSWVBUT19BUkM0PXkNCiMg
Q09ORklHX0NSWVBUT19CTE9XRklTSCBpcyBub3Qgc2V0DQojIENPTkZJR19D
UllQVE9fQ0FNRUxMSUEgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX0NB
U1Q1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSWVBUT19DQVNUNiBpcyBub3Qg
c2V0DQojIENPTkZJR19DUllQVE9fREVTIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0NSWVBUT19GQ1JZUFQgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX0tI
QVpBRCBpcyBub3Qgc2V0DQojIENPTkZJR19DUllQVE9fU0FMU0EyMCBpcyBu
b3Qgc2V0DQojIENPTkZJR19DUllQVE9fQ0hBQ0hBMjAgaXMgbm90IHNldA0K
IyBDT05GSUdfQ1JZUFRPX1NFRUQgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZ
UFRPX1NFUlBFTlQgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX1NNNCBp
cyBub3Qgc2V0DQojIENPTkZJR19DUllQVE9fVEVBIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0NSWVBUT19UV09GSVNIIGlzIG5vdCBzZXQNCg0KIw0KIyBDb21w
cmVzc2lvbg0KIw0KIyBDT05GSUdfQ1JZUFRPX0RFRkxBVEUgaXMgbm90IHNl
dA0KIyBDT05GSUdfQ1JZUFRPX0xaTyBpcyBub3Qgc2V0DQojIENPTkZJR19D
UllQVE9fODQyIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSWVBUT19MWjQgaXMg
bm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX0xaNEhDIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0NSWVBUT19aU1REIGlzIG5vdCBzZXQNCg0KIw0KIyBSYW5kb20g
TnVtYmVyIEdlbmVyYXRpb24NCiMNCiMgQ09ORklHX0NSWVBUT19BTlNJX0NQ
Uk5HIGlzIG5vdCBzZXQNCkNPTkZJR19DUllQVE9fRFJCR19NRU5VPXkNCkNP
TkZJR19DUllQVE9fRFJCR19ITUFDPXkNCiMgQ09ORklHX0NSWVBUT19EUkJH
X0hBU0ggaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX0RSQkdfQ1RSIGlz
IG5vdCBzZXQNCkNPTkZJR19DUllQVE9fRFJCRz15DQpDT05GSUdfQ1JZUFRP
X0pJVFRFUkVOVFJPUFk9eQ0KQ09ORklHX0NSWVBUT19VU0VSX0FQST15DQoj
IENPTkZJR19DUllQVE9fVVNFUl9BUElfSEFTSCBpcyBub3Qgc2V0DQpDT05G
SUdfQ1JZUFRPX1VTRVJfQVBJX1NLQ0lQSEVSPXkNCiMgQ09ORklHX0NSWVBU
T19VU0VSX0FQSV9STkcgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX1VT
RVJfQVBJX0FFQUQgaXMgbm90IHNldA0KQ09ORklHX0NSWVBUT19IQVNIX0lO
Rk89eQ0KDQojDQojIENyeXB0byBsaWJyYXJ5IHJvdXRpbmVzDQojDQpDT05G
SUdfQ1JZUFRPX0xJQl9BRVM9eQ0KQ09ORklHX0NSWVBUT19MSUJfQVJDND15
DQojIENPTkZJR19DUllQVE9fTElCX0JMQUtFMlMgaXMgbm90IHNldA0KIyBD
T05GSUdfQ1JZUFRPX0xJQl9DSEFDSEEgaXMgbm90IHNldA0KIyBDT05GSUdf
Q1JZUFRPX0xJQl9DVVJWRTI1NTE5IGlzIG5vdCBzZXQNCkNPTkZJR19DUllQ
VE9fTElCX1BPTFkxMzA1X1JTSVpFPTkNCiMgQ09ORklHX0NSWVBUT19MSUJf
UE9MWTEzMDUgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRPX0xJQl9DSEFD
SEEyMFBPTFkxMzA1IGlzIG5vdCBzZXQNCkNPTkZJR19DUllQVE9fTElCX1NI
QTI1Nj15DQpDT05GSUdfQ1JZUFRPX0hXPXkNCiMgQ09ORklHX0NSWVBUT19E
RVZfQVRNRUxfRUNDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSWVBUT19ERVZf
QVRNRUxfU0hBMjA0QSBpcyBub3Qgc2V0DQojIENPTkZJR19DUllQVE9fREVW
X0NDUCBpcyBub3Qgc2V0DQpDT05GSUdfQ1JZUFRPX0RFVl9WSVJUSU89bQ0K
IyBDT05GSUdfQ1JZUFRPX0RFVl9TQUZFWENFTCBpcyBub3Qgc2V0DQojIENP
TkZJR19DUllQVE9fREVWX0NDUkVFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NS
WVBUT19ERVZfSElTSV9TRUMgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JZUFRP
X0RFVl9BTUxPR0lDX0dYTCBpcyBub3Qgc2V0DQpDT05GSUdfQVNZTU1FVFJJ
Q19LRVlfVFlQRT15DQpDT05GSUdfQVNZTU1FVFJJQ19QVUJMSUNfS0VZX1NV
QlRZUEU9eQ0KQ09ORklHX1g1MDlfQ0VSVElGSUNBVEVfUEFSU0VSPXkNCiMg
Q09ORklHX1BLQ1M4X1BSSVZBVEVfS0VZX1BBUlNFUiBpcyBub3Qgc2V0DQpD
T05GSUdfUEtDUzdfTUVTU0FHRV9QQVJTRVI9eQ0KIyBDT05GSUdfUEtDUzdf
VEVTVF9LRVkgaXMgbm90IHNldA0KIyBDT05GSUdfU0lHTkVEX1BFX0ZJTEVf
VkVSSUZJQ0FUSU9OIGlzIG5vdCBzZXQNCg0KIw0KIyBDZXJ0aWZpY2F0ZXMg
Zm9yIHNpZ25hdHVyZSBjaGVja2luZw0KIw0KQ09ORklHX1NZU1RFTV9UUlVT
VEVEX0tFWVJJTkc9eQ0KQ09ORklHX1NZU1RFTV9UUlVTVEVEX0tFWVM9IiIN
CiMgQ09ORklHX1NZU1RFTV9FWFRSQV9DRVJUSUZJQ0FURSBpcyBub3Qgc2V0
DQojIENPTkZJR19TRUNPTkRBUllfVFJVU1RFRF9LRVlSSU5HIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1NZU1RFTV9CTEFDS0xJU1RfS0VZUklORyBpcyBub3Qg
c2V0DQojIGVuZCBvZiBDZXJ0aWZpY2F0ZXMgZm9yIHNpZ25hdHVyZSBjaGVj
a2luZw0KDQojDQojIExpYnJhcnkgcm91dGluZXMNCiMNCkNPTkZJR19SQUlE
Nl9QUT15DQpDT05GSUdfUkFJRDZfUFFfQkVOQ0hNQVJLPXkNCiMgQ09ORklH
X1BBQ0tJTkcgaXMgbm90IHNldA0KQ09ORklHX0JJVFJFVkVSU0U9eQ0KQ09O
RklHX0hBVkVfQVJDSF9CSVRSRVZFUlNFPXkNCkNPTkZJR19HRU5FUklDX1NU
Uk5DUFlfRlJPTV9VU0VSPXkNCkNPTkZJR19HRU5FUklDX1NUUk5MRU5fVVNF
Uj15DQpDT05GSUdfR0VORVJJQ19ORVRfVVRJTFM9eQ0KIyBDT05GSUdfQ09S
RElDIGlzIG5vdCBzZXQNCkNPTkZJR19SQVRJT05BTD15DQpDT05GSUdfR0VO
RVJJQ19QQ0lfSU9NQVA9eQ0KQ09ORklHX0FSQ0hfVVNFX0NNUFhDSEdfTE9D
S1JFRj15DQpDT05GSUdfQVJDSF9IQVNfRkFTVF9NVUxUSVBMSUVSPXkNCiMg
Q09ORklHX0lORElSRUNUX1BJTyBpcyBub3Qgc2V0DQojIENPTkZJR19DUkNf
Q0NJVFQgaXMgbm90IHNldA0KQ09ORklHX0NSQzE2PXkNCiMgQ09ORklHX0NS
Q19UMTBESUYgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JDX0lUVV9UIGlzIG5v
dCBzZXQNCkNPTkZJR19DUkMzMj15DQojIENPTkZJR19DUkMzMl9TRUxGVEVT
VCBpcyBub3Qgc2V0DQpDT05GSUdfQ1JDMzJfU0xJQ0VCWTg9eQ0KIyBDT05G
SUdfQ1JDMzJfU0xJQ0VCWTQgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JDMzJf
U0FSV0FURSBpcyBub3Qgc2V0DQojIENPTkZJR19DUkMzMl9CSVQgaXMgbm90
IHNldA0KIyBDT05GSUdfQ1JDNjQgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JD
NCBpcyBub3Qgc2V0DQpDT05GSUdfQ1JDNz15DQpDT05GSUdfTElCQ1JDMzJD
PXkNCiMgQ09ORklHX0NSQzggaXMgbm90IHNldA0KQ09ORklHX1hYSEFTSD15
DQpDT05GSUdfQVVESVRfR0VORVJJQz15DQpDT05GSUdfQVVESVRfQVJDSF9D
T01QQVRfR0VORVJJQz15DQpDT05GSUdfQVVESVRfQ09NUEFUX0dFTkVSSUM9
eQ0KIyBDT05GSUdfUkFORE9NMzJfU0VMRlRFU1QgaXMgbm90IHNldA0KQ09O
RklHX1pMSUJfSU5GTEFURT15DQpDT05GSUdfWkxJQl9ERUZMQVRFPXkNCkNP
TkZJR19MWk9fQ09NUFJFU1M9eQ0KQ09ORklHX0xaT19ERUNPTVBSRVNTPXkN
CkNPTkZJR19MWjRfREVDT01QUkVTUz15DQpDT05GSUdfWlNURF9DT01QUkVT
Uz15DQpDT05GSUdfWlNURF9ERUNPTVBSRVNTPXkNCkNPTkZJR19YWl9ERUM9
eQ0KQ09ORklHX1haX0RFQ19YODY9eQ0KQ09ORklHX1haX0RFQ19QT1dFUlBD
PXkNCkNPTkZJR19YWl9ERUNfSUE2ND15DQpDT05GSUdfWFpfREVDX0FSTT15
DQpDT05GSUdfWFpfREVDX0FSTVRIVU1CPXkNCkNPTkZJR19YWl9ERUNfU1BB
UkM9eQ0KQ09ORklHX1haX0RFQ19CQ0o9eQ0KIyBDT05GSUdfWFpfREVDX1RF
U1QgaXMgbm90IHNldA0KQ09ORklHX0RFQ09NUFJFU1NfR1pJUD15DQpDT05G
SUdfREVDT01QUkVTU19CWklQMj15DQpDT05GSUdfREVDT01QUkVTU19MWk1B
PXkNCkNPTkZJR19ERUNPTVBSRVNTX1haPXkNCkNPTkZJR19ERUNPTVBSRVNT
X0xaTz15DQpDT05GSUdfREVDT01QUkVTU19MWjQ9eQ0KQ09ORklHX0dFTkVS
SUNfQUxMT0NBVE9SPXkNCkNPTkZJR19JTlRFUlZBTF9UUkVFPXkNCkNPTkZJ
R19BU1NPQ0lBVElWRV9BUlJBWT15DQpDT05GSUdfSEFTX0lPTUVNPXkNCkNP
TkZJR19IQVNfRE1BPXkNCkNPTkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQ0K
Q09ORklHX05FRURfRE1BX01BUF9TVEFURT15DQpDT05GSUdfQVJDSF9ETUFf
QUREUl9UXzY0QklUPXkNCkNPTkZJR19ETUFfREVDTEFSRV9DT0hFUkVOVD15
DQpDT05GSUdfQVJDSF9IQVNfU0VUVVBfRE1BX09QUz15DQpDT05GSUdfQVJD
SF9IQVNfVEVBUkRPV05fRE1BX09QUz15DQpDT05GSUdfQVJDSF9IQVNfU1lO
Q19ETUFfRk9SX0RFVklDRT15DQpDT05GSUdfQVJDSF9IQVNfU1lOQ19ETUFf
Rk9SX0NQVT15DQpDT05GSUdfQVJDSF9IQVNfRE1BX1BSRVBfQ09IRVJFTlQ9
eQ0KQ09ORklHX1NXSU9UTEI9eQ0KQ09ORklHX0RNQV9OT05DT0hFUkVOVF9N
TUFQPXkNCkNPTkZJR19ETUFfUkVNQVA9eQ0KQ09ORklHX0RNQV9ESVJFQ1Rf
UkVNQVA9eQ0KQ09ORklHX0RNQV9DTUE9eQ0KDQojDQojIERlZmF1bHQgY29u
dGlndW91cyBtZW1vcnkgYXJlYSBzaXplOg0KIw0KQ09ORklHX0NNQV9TSVpF
X01CWVRFUz0yNTYNCkNPTkZJR19DTUFfU0laRV9TRUxfTUJZVEVTPXkNCiMg
Q09ORklHX0NNQV9TSVpFX1NFTF9QRVJDRU5UQUdFIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0NNQV9TSVpFX1NFTF9NSU4gaXMgbm90IHNldA0KIyBDT05GSUdf
Q01BX1NJWkVfU0VMX01BWCBpcyBub3Qgc2V0DQpDT05GSUdfQ01BX0FMSUdO
TUVOVD04DQojIENPTkZJR19ETUFfQVBJX0RFQlVHIGlzIG5vdCBzZXQNCkNP
TkZJR19TR0xfQUxMT0M9eQ0KQ09ORklHX0NQVV9STUFQPXkNCkNPTkZJR19E
UUw9eQ0KQ09ORklHX0dMT0I9eQ0KIyBDT05GSUdfR0xPQl9TRUxGVEVTVCBp
cyBub3Qgc2V0DQpDT05GSUdfTkxBVFRSPXkNCkNPTkZJR19DTFpfVEFCPXkN
CiMgQ09ORklHX0lSUV9QT0xMIGlzIG5vdCBzZXQNCkNPTkZJR19NUElMSUI9
eQ0KQ09ORklHX0xJQkZEVD15DQpDT05GSUdfT0lEX1JFR0lTVFJZPXkNCkNP
TkZJR19VQ1MyX1NUUklORz15DQpDT05GSUdfSEFWRV9HRU5FUklDX1ZEU089
eQ0KQ09ORklHX0dFTkVSSUNfR0VUVElNRU9GREFZPXkNCkNPTkZJR19GT05U
X1NVUFBPUlQ9eQ0KIyBDT05GSUdfRk9OVFMgaXMgbm90IHNldA0KQ09ORklH
X0ZPTlRfOHg4PXkNCkNPTkZJR19GT05UXzh4MTY9eQ0KQ09ORklHX1NHX1BP
T0w9eQ0KQ09ORklHX1NCSVRNQVA9eQ0KIyBDT05GSUdfU1RSSU5HX1NFTEZU
RVNUIGlzIG5vdCBzZXQNCiMgZW5kIG9mIExpYnJhcnkgcm91dGluZXMNCg0K
Iw0KIyBLZXJuZWwgaGFja2luZw0KIw0KDQojDQojIHByaW50ayBhbmQgZG1l
c2cgb3B0aW9ucw0KIw0KQ09ORklHX1BSSU5US19USU1FPXkNCiMgQ09ORklH
X1BSSU5US19DQUxMRVIgaXMgbm90IHNldA0KQ09ORklHX0NPTlNPTEVfTE9H
TEVWRUxfREVGQVVMVD03DQpDT05GSUdfQ09OU09MRV9MT0dMRVZFTF9RVUlF
VD00DQpDT05GSUdfQ09OU09MRV9MT0dMRVZFTF9FTUVSR0VOQ1k9NQ0KQ09O
RklHX01FU1NBR0VfTE9HTEVWRUxfREVGQVVMVD00DQojIENPTkZJR19CT09U
X1BSSU5US19ERUxBWSBpcyBub3Qgc2V0DQojIENPTkZJR19EWU5BTUlDX0RF
QlVHIGlzIG5vdCBzZXQNCkNPTkZJR19TWU1CT0xJQ19FUlJOQU1FPXkNCkNP
TkZJR19ERUJVR19CVUdWRVJCT1NFPXkNCiMgZW5kIG9mIHByaW50ayBhbmQg
ZG1lc2cgb3B0aW9ucw0KDQojDQojIENvbXBpbGUtdGltZSBjaGVja3MgYW5k
IGNvbXBpbGVyIG9wdGlvbnMNCiMNCkNPTkZJR19ERUJVR19JTkZPPXkNCiMg
Q09ORklHX0RFQlVHX0lORk9fUkVEVUNFRCBpcyBub3Qgc2V0DQojIENPTkZJ
R19ERUJVR19JTkZPX1NQTElUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQlVH
X0lORk9fRFdBUkY0IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQlVHX0lORk9f
QlRGIGlzIG5vdCBzZXQNCiMgQ09ORklHX0dEQl9TQ1JJUFRTIGlzIG5vdCBz
ZXQNCkNPTkZJR19FTkFCTEVfTVVTVF9DSEVDSz15DQpDT05GSUdfRlJBTUVf
V0FSTj0yMDQ4DQojIENPTkZJR19TVFJJUF9BU01fU1lNUyBpcyBub3Qgc2V0
DQojIENPTkZJR19SRUFEQUJMRV9BU00gaXMgbm90IHNldA0KIyBDT05GSUdf
SEVBREVSU19JTlNUQUxMIGlzIG5vdCBzZXQNCkNPTkZJR19PUFRJTUlaRV9J
TkxJTklORz15DQojIENPTkZJR19ERUJVR19TRUNUSU9OX01JU01BVENIIGlz
IG5vdCBzZXQNCkNPTkZJR19TRUNUSU9OX01JU01BVENIX1dBUk5fT05MWT15
DQpDT05GSUdfQVJDSF9XQU5UX0ZSQU1FX1BPSU5URVJTPXkNCkNPTkZJR19G
UkFNRV9QT0lOVEVSPXkNCiMgQ09ORklHX0RFQlVHX0ZPUkNFX1dFQUtfUEVS
X0NQVSBpcyBub3Qgc2V0DQojIGVuZCBvZiBDb21waWxlLXRpbWUgY2hlY2tz
IGFuZCBjb21waWxlciBvcHRpb25zDQoNCiMNCiMgR2VuZXJpYyBLZXJuZWwg
RGVidWdnaW5nIEluc3RydW1lbnRzDQojDQpDT05GSUdfTUFHSUNfU1lTUlE9
eQ0KQ09ORklHX01BR0lDX1NZU1JRX0RFRkFVTFRfRU5BQkxFPTB4MQ0KQ09O
RklHX01BR0lDX1NZU1JRX1NFUklBTD15DQpDT05GSUdfREVCVUdfRlM9eQ0K
Q09ORklHX0hBVkVfQVJDSF9LR0RCPXkNCiMgQ09ORklHX0tHREIgaXMgbm90
IHNldA0KQ09ORklHX0FSQ0hfSEFTX1VCU0FOX1NBTklUSVpFX0FMTD15DQoj
IENPTkZJR19VQlNBTiBpcyBub3Qgc2V0DQpDT05GSUdfVUJTQU5fQUxJR05N
RU5UPXkNCiMgZW5kIG9mIEdlbmVyaWMgS2VybmVsIERlYnVnZ2luZyBJbnN0
cnVtZW50cw0KDQpDT05GSUdfREVCVUdfS0VSTkVMPXkNCkNPTkZJR19ERUJV
R19NSVNDPXkNCg0KIw0KIyBNZW1vcnkgRGVidWdnaW5nDQojDQojIENPTkZJ
R19QQUdFX0VYVEVOU0lPTiBpcyBub3Qgc2V0DQojIENPTkZJR19ERUJVR19Q
QUdFQUxMT0MgaXMgbm90IHNldA0KIyBDT05GSUdfUEFHRV9PV05FUiBpcyBu
b3Qgc2V0DQojIENPTkZJR19QQUdFX1BPSVNPTklORyBpcyBub3Qgc2V0DQoj
IENPTkZJR19ERUJVR19ST0RBVEFfVEVTVCBpcyBub3Qgc2V0DQpDT05GSUdf
R0VORVJJQ19QVERVTVA9eQ0KIyBDT05GSUdfUFREVU1QX0RFQlVHRlMgaXMg
bm90IHNldA0KIyBDT05GSUdfREVCVUdfT0JKRUNUUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19TTFVCX0RFQlVHX09OIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NM
VUJfU1RBVFMgaXMgbm90IHNldA0KQ09ORklHX0hBVkVfREVCVUdfS01FTUxF
QUs9eQ0KIyBDT05GSUdfREVCVUdfS01FTUxFQUsgaXMgbm90IHNldA0KIyBD
T05GSUdfREVCVUdfU1RBQ0tfVVNBR0UgaXMgbm90IHNldA0KIyBDT05GSUdf
U0NIRURfU1RBQ0tfRU5EX0NIRUNLIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RF
QlVHX1ZNIGlzIG5vdCBzZXQNCkNPTkZJR19BUkNIX0hBU19ERUJVR19WSVJU
VUFMPXkNCiMgQ09ORklHX0RFQlVHX1ZJUlRVQUwgaXMgbm90IHNldA0KIyBD
T05GSUdfREVCVUdfTUVNT1JZX0lOSVQgaXMgbm90IHNldA0KIyBDT05GSUdf
REVCVUdfUEVSX0NQVV9NQVBTIGlzIG5vdCBzZXQNCkNPTkZJR19IQVZFX0FS
Q0hfS0FTQU49eQ0KQ09ORklHX0hBVkVfQVJDSF9LQVNBTl9TV19UQUdTPXkN
CkNPTkZJR19DQ19IQVNfS0FTQU5fR0VORVJJQz15DQojIENPTkZJR19LQVNB
TiBpcyBub3Qgc2V0DQpDT05GSUdfS0FTQU5fU1RBQ0s9MQ0KIyBlbmQgb2Yg
TWVtb3J5IERlYnVnZ2luZw0KDQojIENPTkZJR19ERUJVR19TSElSUSBpcyBu
b3Qgc2V0DQoNCiMNCiMgRGVidWcgT29wcywgTG9ja3VwcyBhbmQgSGFuZ3MN
CiMNCiMgQ09ORklHX1BBTklDX09OX09PUFMgaXMgbm90IHNldA0KQ09ORklH
X1BBTklDX09OX09PUFNfVkFMVUU9MA0KQ09ORklHX1BBTklDX1RJTUVPVVQ9
MA0KIyBDT05GSUdfU09GVExPQ0tVUF9ERVRFQ1RPUiBpcyBub3Qgc2V0DQoj
IENPTkZJR19ERVRFQ1RfSFVOR19UQVNLIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1dRX1dBVENIRE9HIGlzIG5vdCBzZXQNCiMgZW5kIG9mIERlYnVnIE9vcHMs
IExvY2t1cHMgYW5kIEhhbmdzDQoNCiMNCiMgU2NoZWR1bGVyIERlYnVnZ2lu
Zw0KIw0KIyBDT05GSUdfU0NIRURfREVCVUcgaXMgbm90IHNldA0KQ09ORklH
X1NDSEVEX0lORk89eQ0KIyBDT05GSUdfU0NIRURTVEFUUyBpcyBub3Qgc2V0
DQojIGVuZCBvZiBTY2hlZHVsZXIgRGVidWdnaW5nDQoNCiMgQ09ORklHX0RF
QlVHX1RJTUVLRUVQSU5HIGlzIG5vdCBzZXQNCkNPTkZJR19ERUJVR19QUkVF
TVBUPXkNCg0KIw0KIyBMb2NrIERlYnVnZ2luZyAoc3BpbmxvY2tzLCBtdXRl
eGVzLCBldGMuLi4pDQojDQpDT05GSUdfTE9DS19ERUJVR0dJTkdfU1VQUE9S
VD15DQojIENPTkZJR19QUk9WRV9MT0NLSU5HIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0xPQ0tfU1RBVCBpcyBub3Qgc2V0DQojIENPTkZJR19ERUJVR19SVF9N
VVRFWEVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQlVHX1NQSU5MT0NLIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0RFQlVHX01VVEVYRVMgaXMgbm90IHNldA0K
IyBDT05GSUdfREVCVUdfV1dfTVVURVhfU0xPV1BBVEggaXMgbm90IHNldA0K
IyBDT05GSUdfREVCVUdfUldTRU1TIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RF
QlVHX0xPQ0tfQUxMT0MgaXMgbm90IHNldA0KIyBDT05GSUdfREVCVUdfQVRP
TUlDX1NMRUVQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xPQ0tfVE9SVFVSRV9U
RVNUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1dXX01VVEVYX1NFTEZURVNUIGlz
IG5vdCBzZXQNCiMgZW5kIG9mIExvY2sgRGVidWdnaW5nIChzcGlubG9ja3Ms
IG11dGV4ZXMsIGV0Yy4uLikNCg0KIyBDT05GSUdfU1RBQ0tUUkFDRSBpcyBu
b3Qgc2V0DQojIENPTkZJR19XQVJOX0FMTF9VTlNFRURFRF9SQU5ET00gaXMg
bm90IHNldA0KIyBDT05GSUdfREVCVUdfS09CSkVDVCBpcyBub3Qgc2V0DQpD
T05GSUdfSEFWRV9ERUJVR19CVUdWRVJCT1NFPXkNCg0KIw0KIyBEZWJ1ZyBr
ZXJuZWwgZGF0YSBzdHJ1Y3R1cmVzDQojDQojIENPTkZJR19ERUJVR19MSVNU
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQlVHX1BMSVNUIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0RFQlVHX1NHIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQlVH
X05PVElGSUVSUyBpcyBub3Qgc2V0DQojIENPTkZJR19CVUdfT05fREFUQV9D
T1JSVVBUSU9OIGlzIG5vdCBzZXQNCiMgZW5kIG9mIERlYnVnIGtlcm5lbCBk
YXRhIHN0cnVjdHVyZXMNCg0KIyBDT05GSUdfREVCVUdfQ1JFREVOVElBTFMg
aXMgbm90IHNldA0KDQojDQojIFJDVSBEZWJ1Z2dpbmcNCiMNCiMgQ09ORklH
X1JDVV9QRVJGX1RFU1QgaXMgbm90IHNldA0KIyBDT05GSUdfUkNVX1RPUlRV
UkVfVEVTVCBpcyBub3Qgc2V0DQpDT05GSUdfUkNVX0NQVV9TVEFMTF9USU1F
T1VUPTIxDQpDT05GSUdfUkNVX1RSQUNFPXkNCiMgQ09ORklHX1JDVV9FUVNf
REVCVUcgaXMgbm90IHNldA0KIyBlbmQgb2YgUkNVIERlYnVnZ2luZw0KDQoj
IENPTkZJR19ERUJVR19XUV9GT1JDRV9SUl9DUFUgaXMgbm90IHNldA0KIyBD
T05GSUdfREVCVUdfQkxPQ0tfRVhUX0RFVlQgaXMgbm90IHNldA0KIyBDT05G
SUdfQ1BVX0hPVFBMVUdfU1RBVEVfQ09OVFJPTCBpcyBub3Qgc2V0DQojIENP
TkZJR19MQVRFTkNZVE9QIGlzIG5vdCBzZXQNCkNPTkZJR19IQVZFX0ZVTkNU
SU9OX1RSQUNFUj15DQpDT05GSUdfSEFWRV9GVU5DVElPTl9HUkFQSF9UUkFD
RVI9eQ0KQ09ORklHX0hBVkVfRFlOQU1JQ19GVFJBQ0U9eQ0KQ09ORklHX0hB
VkVfRlRSQUNFX01DT1VOVF9SRUNPUkQ9eQ0KQ09ORklHX0hBVkVfU1lTQ0FM
TF9UUkFDRVBPSU5UUz15DQpDT05GSUdfSEFWRV9DX1JFQ09SRE1DT1VOVD15
DQpDT05GSUdfVFJBQ0VfQ0xPQ0s9eQ0KQ09ORklHX1RSQUNJTkdfU1VQUE9S
VD15DQojIENPTkZJR19GVFJBQ0UgaXMgbm90IHNldA0KIyBDT05GSUdfU0FN
UExFUyBpcyBub3Qgc2V0DQpDT05GSUdfQVJDSF9IQVNfREVWTUVNX0lTX0FM
TE9XRUQ9eQ0KQ09ORklHX1NUUklDVF9ERVZNRU09eQ0KIyBDT05GSUdfSU9f
U1RSSUNUX0RFVk1FTSBpcyBub3Qgc2V0DQoNCiMNCiMgYXJtNjQgRGVidWdn
aW5nDQojDQojIENPTkZJR19QSURfSU5fQ09OVEVYVElEUiBpcyBub3Qgc2V0
DQojIENPTkZJR19BUk02NF9SQU5ET01JWkVfVEVYVF9PRkZTRVQgaXMgbm90
IHNldA0KIyBDT05GSUdfREVCVUdfV1ggaXMgbm90IHNldA0KIyBDT05GSUdf
REVCVUdfQUxJR05fUk9EQVRBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQlVH
X0VGSSBpcyBub3Qgc2V0DQojIENPTkZJR19BUk02NF9SRUxPQ19URVNUIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0NPUkVTSUdIVCBpcyBub3Qgc2V0DQojIGVu
ZCBvZiBhcm02NCBEZWJ1Z2dpbmcNCg0KIw0KIyBLZXJuZWwgVGVzdGluZyBh
bmQgQ292ZXJhZ2UNCiMNCiMgQ09ORklHX0tVTklUIGlzIG5vdCBzZXQNCiMg
Q09ORklHX05PVElGSUVSX0VSUk9SX0lOSkVDVElPTiBpcyBub3Qgc2V0DQoj
IENPTkZJR19GQVVMVF9JTkpFQ1RJT04gaXMgbm90IHNldA0KQ09ORklHX0FS
Q0hfSEFTX0tDT1Y9eQ0KQ09ORklHX1JVTlRJTUVfVEVTVElOR19NRU5VPXkN
CiMgQ09ORklHX0xLRFRNIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RFU1RfTElT
VF9TT1JUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RFU1RfU09SVCBpcyBub3Qg
c2V0DQojIENPTkZJR19CQUNLVFJBQ0VfU0VMRl9URVNUIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1JCVFJFRV9URVNUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JF
RURfU09MT01PTl9URVNUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOVEVSVkFM
X1RSRUVfVEVTVCBpcyBub3Qgc2V0DQojIENPTkZJR19QRVJDUFVfVEVTVCBp
cyBub3Qgc2V0DQojIENPTkZJR19BVE9NSUM2NF9TRUxGVEVTVCBpcyBub3Qg
c2V0DQojIENPTkZJR19URVNUX0hFWERVTVAgaXMgbm90IHNldA0KIyBDT05G
SUdfVEVTVF9TVFJJTkdfSEVMUEVSUyBpcyBub3Qgc2V0DQojIENPTkZJR19U
RVNUX1NUUlNDUFkgaXMgbm90IHNldA0KIyBDT05GSUdfVEVTVF9LU1RSVE9Y
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1RFU1RfUFJJTlRGIGlzIG5vdCBzZXQN
CiMgQ09ORklHX1RFU1RfQklUTUFQIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RF
U1RfQklURklFTEQgaXMgbm90IHNldA0KIyBDT05GSUdfVEVTVF9VVUlEIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1RFU1RfWEFSUkFZIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1RFU1RfT1ZFUkZMT1cgaXMgbm90IHNldA0KIyBDT05GSUdfVEVT
VF9SSEFTSFRBQkxFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RFU1RfSEFTSCBp
cyBub3Qgc2V0DQojIENPTkZJR19URVNUX0lEQSBpcyBub3Qgc2V0DQojIENP
TkZJR19URVNUX0xLTSBpcyBub3Qgc2V0DQojIENPTkZJR19URVNUX1ZNQUxM
T0MgaXMgbm90IHNldA0KIyBDT05GSUdfVEVTVF9VU0VSX0NPUFkgaXMgbm90
IHNldA0KIyBDT05GSUdfVEVTVF9CUEYgaXMgbm90IHNldA0KIyBDT05GSUdf
VEVTVF9CTEFDS0hPTEVfREVWIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZJTkRf
QklUX0JFTkNITUFSSyBpcyBub3Qgc2V0DQojIENPTkZJR19URVNUX0ZJUk1X
QVJFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RFU1RfU1lTQ1RMIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1RFU1RfVURFTEFZIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1RFU1RfU1RBVElDX0tFWVMgaXMgbm90IHNldA0KIyBDT05GSUdfVEVTVF9L
TU9EIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RFU1RfTUVNQ0FUX1AgaXMgbm90
IHNldA0KIyBDT05GSUdfVEVTVF9TVEFDS0lOSVQgaXMgbm90IHNldA0KIyBD
T05GSUdfVEVTVF9NRU1JTklUIGlzIG5vdCBzZXQNCiMgQ09ORklHX01FTVRF
U1QgaXMgbm90IHNldA0KIyBlbmQgb2YgS2VybmVsIFRlc3RpbmcgYW5kIENv
dmVyYWdlDQojIGVuZCBvZiBLZXJuZWwgaGFja2luZw0K

--8323329-670645698-1587764760=:7982--


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 04:55:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 04:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSCqE-0001ew-3s; Sat, 25 Apr 2020 04:55:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSCqD-0001er-5b
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 04:55:01 +0000
X-Inumbo-ID: e6efe9bc-86b0-11ea-957a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e6efe9bc-86b0-11ea-957a-12813bfff9fa;
 Sat, 25 Apr 2020 04:54:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=CVbjJ3TM/9js+A7brigOXcZTYu3WgiIY8Gpu3IU0uVc=; b=OIofLEyAJjdb8N2nnS73mbtNb
 /F/AYHzZMWPTcldynrQjX+sZUPUAEObVOMFB3gz7jsdYLBVspArci6w0p/d3rXwZPVHHvTG+ckgf4
 1JAWBB8b3dDOkyW/OA7Po6cDIHIUbTv+jZTtVwVP8IPECqEErym4pxBTOQ8awF/iv7Vws=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSCq5-0002QD-B3; Sat, 25 Apr 2020 04:54:53 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSCq5-0001Nb-3o; Sat, 25 Apr 2020 04:54:53 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSCq5-0007F0-3J; Sat, 25 Apr 2020 04:54:53 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149797-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149797: regressions - FAIL
X-Osstest-Failures: xen-unstable-smoke:build-amd64:xen-build:fail:regression
 xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:build-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 04:54:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149797 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149797/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 149784

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149784  2020-04-24 14:00:40 Z    0 days
Failing since        149785  2020-04-24 17:01:40 Z    0 days    4 attempts
Testing same since   149788  2020-04-24 20:00:41 Z    0 days    3 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-amd64-libvirt                                     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.

------------------------------------------------------------
commit f093b08c47b39da6019421a2b61d40745b3e573b
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Tue Apr 21 11:29:46 2020 -0700

    Introduce a description of the Backport and Fixes tags
    
    Create a new document under docs/process to describe our special tags.
    Add a description of the Fixes tag and the new Backport tag. Also
    clarify that lines with tags should not be split.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
    Acked-by: Wei Liu <wl@xen.org>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    CC: jbeulich@suse.com
    CC: george.dunlap@citrix.com
    CC: julien@xen.org
    CC: lars.kurth@citrix.com
    CC: andrew.cooper3@citrix.com
    CC: konrad.wilk@oracle.com

commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Apr 24 15:49:23 2020 +0100

    Update QEMU_TRADITIONAL_REVISION
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 05:42:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 05:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSDaG-000604-TB; Sat, 25 Apr 2020 05:42:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSDaF-0005zz-CS
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 05:42:35 +0000
X-Inumbo-ID: 8c304d26-86b7-11ea-957d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8c304d26-86b7-11ea-957d-12813bfff9fa;
 Sat, 25 Apr 2020 05:42:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=imj19MU+bMo/JTfVuIWcf0LQy1GQ/IiqlFzruwXIcYM=; b=fz2KTVOu4CMtfgmWa3qKan/SR
 a2/vWSNuOTijn0TDCYaKyN9GBxvRSrSmHOReWCFziW04e/o+X1vfkqEPO2tZkdZema+9vjo3XiAN7
 YaN1WM3JgSBJAcdML4uiDg1uFIFkiBam+gSDpY76Kd62saN4PEjxMaOuLjG0AhWSAetGY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSDa7-0003gh-I7; Sat, 25 Apr 2020 05:42:27 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSDa7-00037T-8j; Sat, 25 Apr 2020 05:42:27 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSDa7-0008W0-5M; Sat, 25 Apr 2020 05:42:27 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149786-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149786: regressions - FAIL
X-Osstest-Failures: linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:guest-start/debianhvm.repeat:fail:regression
 linux-linus:test-armhf-armhf-xl-vhd:guest-start:fail:regression
 linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore:fail:allowable
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=4544db3f848f1d5d0f48d39c22c9636aecf73cf6
X-Osstest-Versions-That: linux=b4f633221f0aeac102e463a4be46a643b2e3b819
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 05:42:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149786 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149786/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 guest-start/debianhvm.repeat fail REGR. vs. 149772
 test-armhf-armhf-xl-vhd      11 guest-start              fail REGR. vs. 149772

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     15 guest-saverestore        fail REGR. vs. 149772

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149772
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149772
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149772
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149772
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149772
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149772
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149772
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149772
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                4544db3f848f1d5d0f48d39c22c9636aecf73cf6
baseline version:
 linux                b4f633221f0aeac102e463a4be46a643b2e3b819

Last test of basis   149772  2020-04-24 03:58:26 Z    1 days
Testing same since   149786  2020-04-24 19:09:32 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Akshu Agrawal <akshu.agrawal@amd.com>
  Alex Deucher <alexander.deucher@amd.com>
  Alex Deucher <alexdeucher@gmail.com>
  Alexander Tsoy <alexander@tsoy.me>
  Alexey Skobkin <skobkin-ru@ya.ru>
  Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
  Andrzej Hajda <a.hajda@samsung.com>
  Andy Yan <andy.yan@rock-chips.com>
  Bjorn Andersson <bjorn.andersson@linaro.org>
  Brendan Higgins <brendanhiggins@google.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Charles Keepax <ckeepax@opensource.cirrus.com>
  Chris Wilson <chris@chris-wilson.co.uk>
  Christian König <christian.koenig@amd.com>
  Daniel Vetter <daniel.vetter@ffwll.ch>
  Dave Airlie <airlied@redhat.com>
  David Howells <dhowells@redhat.com>
  Fabio Estevam <festevam@gmail.com>
  Gregor Pintar <grpintar@gmail.com>
  Gyeongtaek Lee <gt82.lee@samsung.com>
  Hans de Goede <hdegoede@redhat.com>
  Jani Nikula <jani.nikula@intel.com>
  Jason Yan <yanaijie@huawei.com>
  Jeremie Francois (on alpha) <jeremie.francois@gmail.com>
  Jernej Skrabec <jernej.skrabec@siol.net>
  Jerome Brunet <jbrunet@baylibre.com>
  Jessica Yu <jeyu@kernel.org>
  Johan Jonker <jbx6244@gmail.com>
  José Roberto de Souza <jose.souza@intel.com>
  Kailang Yang <kailang@realtek.com>
  Krzysztof Kozlowski <krzk@kernel.org>
  Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lyude Paul <lyude@redhat.com>
  Marek Szyprowski <m.szyprowski@samsung.com>
  Mark Brown <broonie@kernel.org>
  Mark Rutland <mark.rutland@arm.com>
  Markus Elfring <elfring@users.sourceforge.net>
  Masahiro Yamada <masahiroy@kernel.org>
  Matt Roper <matthew.d.roper@intel.com>
  Matthias Blankertz <matthias.blankertz@cetitec.com>
  Maxime Ripard <maxime@cerno.tech>
  Mengbing Wang <Mengbing.Wang@amd.com>
  Mikita Lipski <mikita.lipski@amd.com>
  Neil Armstrong <narmstrong@baylibre.com>
  Oliver Barta <oliver.barta@aptiv.com>
  Olivier Moysan <olivier.moysan@st.com>
  Philipp Puschmann <p.puschmann@pironex.de>
  Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
  Prike Liang <Prike.Liang@amd.com>
  Randy Dunlap <rdunlap@infradead.org>
  Rodrigo Vivi <rodrigo.vivi@intel.com>
  Sam Ravnborg <sam@ravnborg.org>
  Sandeep Raghuraman <sandy.8925@gmail.com>
  Sebastian Fricke <sebastian.fricke.linux@gmail.com>
  Sebastian Reichel <sebastian.reichel@collabora.com>
  Shengjiu Wang <shengjiu.wang@nxp.com>
  Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
  Stephan Gerhold <stephan@gerhold.net>
  Takashi Iwai <tiwai@suse.de>
  Tomi Valkeinen <tomi.valkeinen@ti.com>
  Vasily Khoruzhick <anarsoul@gmail.com>
  Vitor Massaru Iha <vitor@massaru.org>
  Will Deacon <will@kernel.org>
  Xin Tan <tanxin.ctf@gmail.com>
  Xiyu Yang <xiyuyang19@fudan.edu.cn>
  YueHaibing <yuehaibing@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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 2140 lines long.)


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 06:18:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 06:18:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSE94-0000FN-VT; Sat, 25 Apr 2020 06:18:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSE93-0000FH-Pe
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 06:18:33 +0000
X-Inumbo-ID: 938779f0-86bc-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 938779f0-86bc-11ea-b58d-bc764e2007e4;
 Sat, 25 Apr 2020 06:18:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Kdo0sfXrkFQvPlyj+6ihFkxqqFeCf/4jJbx/2m6+cgo=; b=gvuE5SwESOwkjxEn8uviIrpz4
 Alt2vRhSD8FF9o9kXFB4WndKFONxhNWAT3x/RGNjwWNra3d6MY81PwZYKA3vMoxBpHXdciPQ/bxJL
 cD/LSn8YRv6DhlOW8pbjlYEiUtk2wxyPe8JcOTdt8saeH3heXZQLimmXlXuACbVEWBx/Q=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSE8x-0004V3-BB; Sat, 25 Apr 2020 06:18:27 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSE8x-00048c-49; Sat, 25 Apr 2020 06:18:27 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSE8x-00010a-3U; Sat, 25 Apr 2020 06:18:27 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149803-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149803: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=6ebb00cd789478ef9017e3eb6b3db4260e57d4bb
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 06:18:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149803 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149803/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
 build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      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-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-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-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-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              6ebb00cd789478ef9017e3eb6b3db4260e57d4bb
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   99 days
Failing since        146211  2020-01-18 04:18:52 Z   98 days   91 attempts
Testing same since   149803  2020-04-25 04:18:54 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Chen Hanxiao <chen_han_xiao@126.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mark Asselstine <mark.asselstine@windriver.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Philipp Hahn <hahn@univention.de>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 16301 lines long.)


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 07:49:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 07:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSFZA-0007i8-U3; Sat, 25 Apr 2020 07:49:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSFZ9-0007i3-Jb
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 07:49:35 +0000
X-Inumbo-ID: 4d3898b4-86c9-11ea-9592-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4d3898b4-86c9-11ea-9592-12813bfff9fa;
 Sat, 25 Apr 2020 07:49:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=T/13owPnx4X50usBXWLc7EDghao2uWY1ksqUjF3Omv0=; b=Y4UcoWjE1haydq8bO45zcu/Ht
 f2ZDJCj/L77qXKDNFvjIip2FjXKTLVdCd/mZSy5t0xnQha4WmUdr3sTJe3J/bI2JhcLxHE5bKPKOF
 SVcWJqCSutkZiQjYlB6lhTB+fjJ4fO7AVd24cZSl6t0ZAG4OD/DKSE5RWfWbkMqEyb2yQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSFZ6-0006Kp-PX; Sat, 25 Apr 2020 07:49:32 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSFZ6-0001qC-He; Sat, 25 Apr 2020 07:49:32 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSFZ6-0000PT-H1; Sat, 25 Apr 2020 07:49:32 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149805-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149805: regressions - FAIL
X-Osstest-Failures: xen-unstable-smoke:build-amd64:xen-build:fail:regression
 xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable-smoke:build-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 07:49:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149805 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149805/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 149784

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149784  2020-04-24 14:00:40 Z    0 days
Failing since        149785  2020-04-24 17:01:40 Z    0 days    5 attempts
Testing same since   149788  2020-04-24 20:00:41 Z    0 days    4 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-amd64-libvirt                                     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.

------------------------------------------------------------
commit f093b08c47b39da6019421a2b61d40745b3e573b
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Tue Apr 21 11:29:46 2020 -0700

    Introduce a description of the Backport and Fixes tags
    
    Create a new document under docs/process to describe our special tags.
    Add a description of the Fixes tag and the new Backport tag. Also
    clarify that lines with tags should not be split.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
    Acked-by: Wei Liu <wl@xen.org>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    CC: jbeulich@suse.com
    CC: george.dunlap@citrix.com
    CC: julien@xen.org
    CC: lars.kurth@citrix.com
    CC: andrew.cooper3@citrix.com
    CC: konrad.wilk@oracle.com

commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Apr 24 15:49:23 2020 +0100

    Update QEMU_TRADITIONAL_REVISION
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 08:48:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 08:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSGTa-0004gg-2C; Sat, 25 Apr 2020 08:47:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=RPhZ=6J=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jSGTY-0004gb-Mf
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 08:47:52 +0000
X-Inumbo-ID: 7257669a-86d1-11ea-b4f4-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7257669a-86d1-11ea-b4f4-bc764e2007e4;
 Sat, 25 Apr 2020 08:47:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587804472;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=6eXs67H6WfVRWswCqQZiAo7PiJtJlw0T0C3CIHgs5Do=;
 b=YjuyUhvMGk55crH7BFABiZwJ8zqeS/EOGVN/X4mOZPuvcr8xstRIxqX9
 7ouJ9mGWd4HvTuuGYwHRPygOQqlO/KM9Mi7B6NJnsSUyggY0WM5Swpz8Z
 cVF+vGK0bUOfGSbdNvEGXwIXp3i0wphBJbSci58l9JLHNzLa4+922/qd2 A=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: /BKjbrL1uODt6x6haPO7zjnfHMU4WKcu1Xpox4umeOeOurQUzMDX18XGkLbrKKkuaF4I/zhPyJ
 tTBko86ehNg22gMduOOn0h9+MZdVfqXIS8rloqlYDOaLGq2BovVkdooXh/SD8f7GiWi6+9d4Ol
 XqjFYH9wvWp6oNSbqJ1v3HwnNNdkLT2xg9aQmpnyC2wtCiGM1TVmiKbeyOqSVWqoEywmUBr/WV
 6v9uc6jQLdKHc9kxSMDFmFD9tD972becXOVWc7sE2ikqSC8pk45yNiW7gmLGds0TNB+q3QS0TC
 AwU=
X-SBRS: 2.7
X-MesageID: 16257269
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,315,1583211600"; d="scan'208";a="16257269"
Date: Sat, 25 Apr 2020 10:47:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [xen-unstable-smoke test] 149805: regressions - FAIL
Message-ID: <20200425084741.GJ28601@Air-de-Roger>
References: <osstest-149805-mainreport@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <osstest-149805-mainreport@xen.org>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sat, Apr 25, 2020 at 07:49:32AM +0000, osstest service owner wrote:
> flight 149805 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/149805/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   6 xen-build                fail REGR. vs. 149784

This seems to fail in the qemu-trad clone:

+ /home/osstest/build.149805.build-amd64/xen/tools/../scripts/git-checkout.sh git://cache:9419/git://xenbits.xen.org/qemu-xen-traditional.git 3c659044118e34603161457db9934a34f816d78b qemu-xen-traditional-dir
Cloning into 'qemu-xen-traditional-dir-remote.tmp'...
fatal: reference is not a tree: 3c659044118e34603161457db9934a34f816d78b
Makefile:148: recipe for target 'qemu-xen-traditional-dir-find' failed
make[2]: Leaving directory '/home/osstest/build.149805.build-amd64/xen/tools'
make[2]: *** [qemu-xen-traditional-dir-find] Error 128
/home/osstest/build.149805.build-amd64/xen/tools/../tools/Rules.mk:232: recipe for target 'subdirs-all' failed
make[1]: Leaving directory '/home/osstest/build.149805.build-amd64/xen/tools'
make[1]: *** [subdirs-all] Error 2
Makefile:63: recipe for target 'build-tools' failed
make: *** [build-tools] Error 2

AFAICT qemu-xen-traditional hasn't been updated in 18 months, I think
you updated the revision in the Xen tree but didn't push the patches
to the qemu-xen-trad repo?

Roger.


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 08:58:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 08:58:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSGd9-0005Zi-1Y; Sat, 25 Apr 2020 08:57:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSGd7-0005Zd-3b
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 08:57:45 +0000
X-Inumbo-ID: d07d2f92-86d2-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d07d2f92-86d2-11ea-b58d-bc764e2007e4;
 Sat, 25 Apr 2020 08:57:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Message-Id:Subject:To:Sender:
 Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=SsFGeskfRRkif1RKC3o8tonywz1LiBffeEIbBWU3jcI=; b=reNWO7jOHBsqcHS/GV+k3418yQ
 6nNUi58btyI17eaEEmXMRyk1mfQAigcFtqSIAeXrbZYgV548JYNzS5ojR+pxckmoh3mAEu2wssx7f
 US3OBP1VqqFu9/dRNUH1ntzOmlbjE1AlJNzaQOTsUqzpXb/rd9Ndh5NY3OjrJPHqbIHM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSGd0-0008Fy-KL; Sat, 25 Apr 2020 08:57:38 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSGd0-0005go-5m; Sat, 25 Apr 2020 08:57:38 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSGd0-0001IM-5B; Sat, 25 Apr 2020 08:57:38 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Subject: [xen-unstable-smoke bisection] complete build-amd64
Message-Id: <E1jSGd0-0001IM-5B@osstest.test-lab.xenproject.org>
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 08:57:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build

Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  3acfd35b61688ad9a5b843ee923221eb36e0b613
  Bug not present: 96b5c267e52657e99bd1bbf81dd51925447115e2
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149815/


  commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
  Author: Ian Jackson <ian.jackson@eu.citrix.com>
  Date:   Fri Apr 24 15:49:23 2020 +0100
  
      Update QEMU_TRADITIONAL_REVISION
      
      Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build --summary-out=tmp/149815.bisection-summary --basis-template=149784 --blessings=real,real-bisect xen-unstable-smoke build-amd64 xen-build
Searching for failure / basis pass:
 149805 fail [host=huxelrebe0] / 149784 [host=albana0] 149769 [host=godello1] 149760 [host=godello1] 149748 [host=debina0] 149736 [host=fiano1] 149733 [host=italia0] 149727 [host=godello1] 149724 [host=italia0] 149720 [host=godello1] 149713 [host=godello1] 149699 [host=albana1] 149688 [host=albana1] 149686 [host=albana1] 149654 [host=debina0] 149645 [host=godello1] 149644 [host=albana0] 149602 [host=godello1] 149599 [host=pinot0] 149568 [host=italia0] 149523 [host=pinot0] 149499 [host=chardonnay\
 0] 149401 [host=huxelrebe1] 149391 [host=huxelrebe1] 149382 [host=debina1] 149296 [host=debina1] 149284 [host=albana0] 149278 [host=fiano1] 149240 [host=italia0] 149225 [host=albana0] 149213 [host=italia0] 149132 [host=italia0] 149110 ok.
Failure / basis pass flights: 149805 / 149110
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
(tree in basispass but not in latest: qemu)
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 933ebad2470a169504799a1d95b8e410bd9847ef f093b08c47b39da6019421a2b61d40745b3e573b
Basis pass 933ebad2470a169504799a1d95b8e410bd9847ef a87676c4a32f94d79fcaf5b4e0eb59e880e0f032
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#a87676c4a32f94d79fcaf5b4e0eb59e880e0f032-f093b08c47b39da6019421a2b61d40745b3e573b
Loaded 5001 nodes in revision graph
Searching for test results:
 149110 pass 933ebad2470a169504799a1d95b8e410bd9847ef a87676c4a32f94d79fcaf5b4e0eb59e880e0f032
 149132 [host=italia0]
 149213 [host=italia0]
 149225 [host=albana0]
 149240 [host=italia0]
 149284 [host=albana0]
 149278 [host=fiano1]
 149296 [host=debina1]
 149382 [host=debina1]
 149391 [host=huxelrebe1]
 149401 [host=huxelrebe1]
 149499 [host=chardonnay0]
 149523 [host=pinot0]
 149568 [host=italia0]
 149644 [host=albana0]
 149599 [host=pinot0]
 149688 [host=albana1]
 149602 [host=godello1]
 149645 [host=godello1]
 149654 [host=debina0]
 149686 [host=albana1]
 149699 [host=albana1]
 149713 [host=godello1]
 149720 [host=godello1]
 149801 pass 933ebad2470a169504799a1d95b8e410bd9847ef 6c122d3984a5efb1f187cde0e478e4e346202f2b
 149788 [host=godello1]
 149724 [host=italia0]
 149789 [host=godello1]
 149727 [host=godello1]
 149733 [host=italia0]
 149769 [host=godello1]
 149736 [host=fiano1]
 149748 [host=debina0]
 149796 pass 933ebad2470a169504799a1d95b8e410bd9847ef a87676c4a32f94d79fcaf5b4e0eb59e880e0f032
 149760 [host=godello1]
 149790 [host=godello1]
 149784 [host=albana0]
 149804 pass 933ebad2470a169504799a1d95b8e410bd9847ef e321576f4047661111c7e069f03fc96294d7bb32
 149785 [host=godello1]
 149793 [host=godello1]
 149798 fail 933ebad2470a169504799a1d95b8e410bd9847ef f093b08c47b39da6019421a2b61d40745b3e573b
 149787 [host=godello1]
 149812 pass 933ebad2470a169504799a1d95b8e410bd9847ef 96b5c267e52657e99bd1bbf81dd51925447115e2
 149794 [host=godello1]
 149799 pass 933ebad2470a169504799a1d95b8e410bd9847ef 8c4aed6ee1073f01f257d170c14c41af7a9cfd39
 149791 fail 933ebad2470a169504799a1d95b8e410bd9847ef f093b08c47b39da6019421a2b61d40745b3e573b
 149795 [host=godello1]
 149802 pass 933ebad2470a169504799a1d95b8e410bd9847ef aa14feb6723d3bb15a884533ade1cd9732792145
 149800 pass 933ebad2470a169504799a1d95b8e410bd9847ef 8b8d011ad868df38afae6282103087556beaa1f9
 149808 fail 933ebad2470a169504799a1d95b8e410bd9847ef 3acfd35b61688ad9a5b843ee923221eb36e0b613
 149806 pass 933ebad2470a169504799a1d95b8e410bd9847ef 96b5c267e52657e99bd1bbf81dd51925447115e2
 149797 fail 933ebad2470a169504799a1d95b8e410bd9847ef f093b08c47b39da6019421a2b61d40745b3e573b
 149810 pass 933ebad2470a169504799a1d95b8e410bd9847ef 96b5c267e52657e99bd1bbf81dd51925447115e2
 149815 fail 933ebad2470a169504799a1d95b8e410bd9847ef 3acfd35b61688ad9a5b843ee923221eb36e0b613
 149805 fail 933ebad2470a169504799a1d95b8e410bd9847ef f093b08c47b39da6019421a2b61d40745b3e573b
 149811 fail 933ebad2470a169504799a1d95b8e410bd9847ef 3acfd35b61688ad9a5b843ee923221eb36e0b613
Searching for interesting versions
 Result found: flight 149110 (pass), for basis pass
 Result found: flight 149791 (fail), for basis failure
 Repro found: flight 149796 (pass), for basis pass
 Repro found: flight 149797 (fail), for basis failure
 0 revisions at 933ebad2470a169504799a1d95b8e410bd9847ef 96b5c267e52657e99bd1bbf81dd51925447115e2
No revisions left to test, checking graph state.
 Result found: flight 149806 (pass), for last pass
 Result found: flight 149808 (fail), for first failure
 Repro found: flight 149810 (pass), for last pass
 Repro found: flight 149811 (fail), for first failure
 Repro found: flight 149812 (pass), for last pass
 Repro found: flight 149815 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  3acfd35b61688ad9a5b843ee923221eb36e0b613
  Bug not present: 96b5c267e52657e99bd1bbf81dd51925447115e2
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149815/


  commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
  Author: Ian Jackson <ian.jackson@eu.citrix.com>
  Date:   Fri Apr 24 15:49:23 2020 +0100
  
      Update QEMU_TRADITIONAL_REVISION
      
      Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

pnmtopng: 224 colors found
Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
149815: tolerable ALL FAIL

flight 149815 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/149815/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-amd64                   6 xen-build               fail baseline untested


jobs:
 build-amd64                                                  fail    


------------------------------------------------------------
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



From xen-devel-bounces@lists.xenproject.org Sat Apr 25 09:01:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 09:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSGgY-0006OS-Iw; Sat, 25 Apr 2020 09:01:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=RPhZ=6J=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jSGgX-0006ON-Bx
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 09:01:17 +0000
X-Inumbo-ID: 513f970a-86d3-11ea-9599-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 513f970a-86d3-11ea-9599-12813bfff9fa;
 Sat, 25 Apr 2020 09:01:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587805275;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=O3sa6ilycJjGZncHn47Gzj2fxIElXn+IwOpcCrdTk2M=;
 b=P4JON1UE3mhfG5rVDOqJSMJSu2S9M6C8bd70a1t0BNNEQnuxV4Bf5UQQ
 yvsR3U9a0FcalTKbuPg+Hop7aN/BKSqg3CDWqvNWEeDuOMJzu6Inydi23
 CMnAFozo5QvYbQj2uwUEgpn1ubexx2S5z8FpO7tsTth5NYnXn/7uQIjVZ 0=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: ahsmVPWdzXumDMeF3ETP5iLVDh/vc9SLSF3WjRrQpiDWALpdJ+skEr9gy/67JzmJiPZlHoZdxh
 ILT3qNEwwDPqn1k7RCMOFUfFbuN+k/kHtpgUQg97exQ1EIbjevLtzI9kNcyUOFJck3bWHGjvke
 QAngl2HRsNWnCMaCRoZ0pLs/vbHCRjNvsJixyQztmJmpmnRKHaNgnySmVAFRhA0YEwf9b2g4SG
 lN8yr74PRFRX6fkHTM1UpEwYOTW7aViYEc9DSB0oc9A3Ymn5ngHXFBvuqfWWtF5hxakRnYoSCo
 Qwo=
X-SBRS: 2.7
X-MesageID: 16494186
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,315,1583211600"; d="scan'208";a="16494186"
Date: Sat, 25 Apr 2020 11:01:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Subject: Re: [PATCH v17 1/2] mem_sharing: fix sharability check during fork
 reset
Message-ID: <20200425090107.GK28601@Air-de-Roger>
References: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
 <20200424094343.GH28601@Air-de-Roger>
 <CABfawhnRhLJ0AKjTKBx7snEOHBX5oJ2KrwbscQk=e7qXHFD3mA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABfawhnRhLJ0AKjTKBx7snEOHBX5oJ2KrwbscQk=e7qXHFD3mA@mail.gmail.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 24, 2020 at 06:18:24AM -0600, Tamas K Lengyel wrote:
> On Fri, Apr 24, 2020 at 3:44 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
> >
> > On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> > > When resetting a VM fork we ought to only remove pages that were allocated for
> > > the fork during it's execution and the contents copied over from the parent.
> > > This can be determined if the page is sharable as special pages used by the
> > > fork for other purposes will not pass this test. Unfortunately during the fork
> > > reset loop we only partially check whether that's the case. A page's type may
> > > indicate it is sharable (pass p2m_is_sharable) but that's not a sufficient
> > > check by itself. All checks that are normally performed before a page is
> > > converted to the sharable type need to be performed to avoid removing pages
> > > from the p2m that may be used for other purposes. For example, currently the
> > > reset loop also removes the vcpu info pages from the p2m, potentially putting
> > > the guest into infinite page-fault loops.
> > >
> > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> >
> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Thanks!
> 
> >
> > I've been looking however and I'm not able to spot where you copy the
> > shared_info data, which I think it's also quite critical for the
> > domain, as it contains the info about event channels (when using L2).
> > Also for HVM forks the shared info should be mapped at the same gfn as
> > the parent, or else the child trying to access it will trigger an EPT
> > fault that won't be able to populate such gfn, because the shared_info
> > on the parent is already shared between Xen and the parent.
> 
> Pages that cause an EPT fault but can't be made shared get a new page
> allocated for them and copied in mem_sharing_fork_page. There are many
> pages like that, mostly due to QEMU mapping them and thus holding an
> extra reference. That said, shared_info is manually copied during
> forking in copy_special_pages, at the end of the function you will
> find:
> 
> old_mfn = _mfn(virt_to_mfn(d->shared_info));
> new_mfn = _mfn(virt_to_mfn(cd->shared_info));
> 
> copy_domain_page(new_mfn, old_mfn);

Yes, that's indeed fine, you need to copy the contents of the shared
info page, but for HVM you also need to make sure the shared info page
is mapped at the same gfn as the parent. HVM guest issue a hypercall
to request the mapping of the shared info page to a specific gfn,
since it's not added to the guest physmap by default.
XENMAPSPACE_shared_info is used in order to request the shared info
page to be mapped at a specific gfn.

AFAICT during fork such shared info mapping is not replicated to the
child, and hence the child trying to access the gfn of the shared info
page would just result in EPT faults that won't be fixed (because the
parent shared info page cannot be shared with the child)?

You should be able to use get_gpfn_from_mfn in order to get the parent
gfn where the shared info mfn is mapped (if any), and then replicate
this in the child using it's own shared info.

On fork reset you should check if the child shared info gfn != parent
shared info gfn and reinstate the parent state if different from the
child.

Roger.


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 09:50:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 09:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSHRn-0001zO-F1; Sat, 25 Apr 2020 09:50:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fCYS=6J=gmail.com=julien.grall.oss@srs-us1.protection.inumbo.net>)
 id 1jSHRl-0001lg-Oh
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 09:50:05 +0000
X-Inumbo-ID: 23572df6-86da-11ea-b4f4-bc764e2007e4
Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 23572df6-86da-11ea-b4f4-bc764e2007e4;
 Sat, 25 Apr 2020 09:50:04 +0000 (UTC)
Received: by mail-wm1-x341.google.com with SMTP id z6so14508781wml.2
 for <xen-devel@lists.xenproject.org>; Sat, 25 Apr 2020 02:50:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=P83MWiJLspWz5CoTkxUlVDfhmogvMWXyi7+fA//NOl8=;
 b=Ivw39+wz+G0NFLwkZeySIBfjvyqGspHWjCwteL3UMdVMLgM5RDKW1mqLozbYLxLJXv
 FK9w8XzyPk0JdRxKxStQwAj1X02cj08LvVpHYVMfZZGOQPVhY1IE1EHVl9eQKK/kNnxd
 uxlbVKJ5naU8t187ACEBDWEQnjHkl5a6Opf62MI7jF4gRSTK01oXPfWNutPNfdV9o+8O
 zWZf1BU66X0Bwf44DG8SJcDxeDMH2jVVOT8ECw3Mt9n8MSak28tI5VdLGPOQKmhXGcuU
 ZMtlx0Q3dddswhf3Wa5b/WfMG25AOQKE57xLs9OsSEiSvtuuq4K5vTBMcdmpr3rA6wIJ
 W+vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=P83MWiJLspWz5CoTkxUlVDfhmogvMWXyi7+fA//NOl8=;
 b=mJJPa2bVIJVSwe1VxVMbxwSx2LVVYk0tluteSmm2LP9hIYrL0kHhUDvKlOYdZ0G9QW
 +eK1Jd/Q0KO+OG0gb20TNAMr5fbhnUyyvvE+igCnOIPM3IRW1VaYSlhvzBiAa/1q2rf2
 YfZPf2ZBvQkG4qhC7aA9ir6dr6ebVv4duv/iuhUBFyBp2oCVLeeUSBLDNw4ndFDjERNP
 y1osRrxRat728XBpmW5SYu69+RUUkGd8ybX/emSIA8IVwkwj7xTbqeYd26eZYZqq/0x4
 daUlvhW5X+e5FQHuImnfmYYUAbrusCLQW14qzGyLwAplM+uyL5MwmpnkQHqA2nyRePEY
 YUGw==
X-Gm-Message-State: AGi0PuYm37sLcyOj1HipoeYQgAHBN6sDWXiNJ2X2on+FmAzR2I1HNioL
 CZyc6DCqgXpsaarQo3EvQ09CFXtEdcg0hGPAlDc=
X-Google-Smtp-Source: APiQypKpGphSRhwcDztpS/ydi7slLsT+Xvor8/o0Jx6Ed5n5mZ+n8z6UNpnFyzmcpsoSeoS0Hgw6xtZEsyV7h8hnT5w=
X-Received: by 2002:a05:600c:28e:: with SMTP id
 14mr15994809wmk.79.1587808203851; 
 Sat, 25 Apr 2020 02:50:03 -0700 (PDT)
MIME-Version: 1.0
References: <VI1PR04MB505620B32C8289C6106D0B2AF9D00@VI1PR04MB5056.eurprd04.prod.outlook.com>
 <alpine.DEB.2.21.2004241443570.7982@sstabellini-ThinkPad-T480s>
In-Reply-To: <alpine.DEB.2.21.2004241443570.7982@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Sat, 25 Apr 2020 10:49:52 +0100
Message-ID: <CAJ=z9a284froER_-dNQKWwzXkPJ5S0yodY1vyqukqDywxWtCXg@mail.gmail.com>
Subject: Re: arm: DomU Networking enable leads to Dom0 kernel oops
To: Stefano Stabellini <sstabellini@kernel.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrei Cherechesu <andrei.cherechesu@nxp.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sat, 25 Apr 2020 at 03:01, Stefano Stabellini <sstabellini@kernel.org> wrote:
> [   86.900974] ------------[ cut here ]------------
> [   86.905134] Interrupt for port 6, but apparently not enabled; per-user (____ptrval____)
> [   86.913228] WARNING: CPU: 0 PID: 2437 at drivers/xen/evtchn.c:167 evtchn_interrupt+0xfc/0x108

The implementation of the evtchn_interrupt() is relying to be called
in the top-half. On RT, interrupts handlers are forced to be threaded
and use the IRQF_ONESHOT semantics if they were not threaded before.

However, IRQF_ONESHOT is completely broken for event channels (this is
not RT's fault) and hence why you see the warning here.

Note that you can't force to run evtchn_interrupt() in the top-half
because it relies on functions that may sleep.

See https://lkml.org/lkml/2019/2/19/642.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 09:52:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 09:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSHU5-00029Z-Ss; Sat, 25 Apr 2020 09:52:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fCYS=6J=gmail.com=julien.grall.oss@srs-us1.protection.inumbo.net>)
 id 1jSHU4-00029Q-2U
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 09:52:28 +0000
X-Inumbo-ID: 787038b4-86da-11ea-9e09-bc764e2007e4
Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 787038b4-86da-11ea-9e09-bc764e2007e4;
 Sat, 25 Apr 2020 09:52:27 +0000 (UTC)
Received: by mail-wm1-x344.google.com with SMTP id e26so13871145wmk.5
 for <xen-devel@lists.xenproject.org>; Sat, 25 Apr 2020 02:52:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=mhiwjUVO3pvs9LohGSC/ZEgeoDI0uOiNlhznjfKLXb0=;
 b=n+WwkRDrGZvAc4dwegFPqwcnTq7llv6oSb5+I+Uv+dW/aWNaajD9FX9gwyEc1UVckh
 xsnbjJexxF0zOOchIA6AR0L4oz9dOxP6MXoW4DA1dkGyCPquWh7lJD5UYVHC6scHr+Fv
 6M7ICHjALapfAMZCpwnNtRah3K5Lo7F5+qpUtUYhP8Td2muj8VDuSnK3rXZ5N+XmFzjz
 OVBhA8kO2Nf1YWhJMwPzJ+jxa4IwRlRkAVd+E9/40FuLNdtUUXWZxj2X67WiVJDK9aVr
 vKnFg28ydnaFzpR1YfigpMsiPGpNkG4PIQMDz1i/sxD49cFswb17TFS2RLgmenD/1G7d
 QKkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=mhiwjUVO3pvs9LohGSC/ZEgeoDI0uOiNlhznjfKLXb0=;
 b=H1/1cUoIpwPkgPzeHDpnngf63jN4h/gf5rXamDAkiJJYVRCvaGR/qG/enIfKpe4g1r
 mHD9o9ya6YJ1OaHKcXOawNslrLDOuBP7QctRBqkTXJeDz9ehnjxG5nXOxjoirMrsc6j7
 U6wFonKNUSRdTPqHeHf1qcLjvrqQZJqUr+sb4URYmXQqLII63o4XOl2S5VoE3tvLPim+
 5U5nxVnnoJumSgJe14MtgN2l+hHpSgb4dVmaJu19n3h+BGL7/Lx0oCpNji1Ur0r99slV
 tmAowayPl9VuCQOg8d99nAl33qEF598ssnEZzSLYNp5+0Q+GWulsbGx0eIGcpYnTF6Eo
 CvmA==
X-Gm-Message-State: AGi0PuZ5J8rCDENw3VbiWGnyJSLMGhL508F+zejFRi4/uTZDXA9zEIsX
 GocufCtOQ9Jz05OgC+c7Ci7XZUUpGx8ulc+8pu4=
X-Google-Smtp-Source: APiQypKLdMR3b4cQH7v+TUtu9GDqHaPnB2anQehT+zego9pgV2TWlKpftI4p1rSdS8BWCCAr2IXRJgJTJ6gjn1Q5IcI=
X-Received: by 2002:a05:600c:28e:: with SMTP id
 14mr16005273wmk.79.1587808346645; 
 Sat, 25 Apr 2020 02:52:26 -0700 (PDT)
MIME-Version: 1.0
References: <VI1PR04MB505620B32C8289C6106D0B2AF9D00@VI1PR04MB5056.eurprd04.prod.outlook.com>
 <alpine.DEB.2.21.2004241443570.7982@sstabellini-ThinkPad-T480s>
 <CAJ=z9a284froER_-dNQKWwzXkPJ5S0yodY1vyqukqDywxWtCXg@mail.gmail.com>
In-Reply-To: <CAJ=z9a284froER_-dNQKWwzXkPJ5S0yodY1vyqukqDywxWtCXg@mail.gmail.com>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Sat, 25 Apr 2020 10:52:15 +0100
Message-ID: <CAJ=z9a0s-KGyP--kFzBdohzf509toZBq6qHrnt8JQEaLAaQ7=Q@mail.gmail.com>
Subject: Re: arm: DomU Networking enable leads to Dom0 kernel oops
To: Stefano Stabellini <sstabellini@kernel.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrei Cherechesu <andrei.cherechesu@nxp.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sat, 25 Apr 2020 at 10:49, Julien Grall <julien.grall.oss@gmail.com> wrote:
>
> On Sat, 25 Apr 2020 at 03:01, Stefano Stabellini <sstabellini@kernel.org> wrote:
> > [   86.900974] ------------[ cut here ]------------
> > [   86.905134] Interrupt for port 6, but apparently not enabled; per-user (____ptrval____)
> > [   86.913228] WARNING: CPU: 0 PID: 2437 at drivers/xen/evtchn.c:167 evtchn_interrupt+0xfc/0x108
>
> The implementation of the evtchn_interrupt() is relying to be called
> in the top-half. On RT, interrupts handlers are forced to be threaded
> and use the IRQF_ONESHOT semantics if they were not threaded before.
>
> However, IRQF_ONESHOT is completely broken for event channels (this is
> not RT's fault) and hence why you see the warning here.
>
> Note that you can't force to run evtchn_interrupt() in the top-half
> because it relies on functions that may sleep.
>
> See https://lkml.org/lkml/2019/2/19/642.

Here at better link with the full conversation:

https://lore.kernel.org/lkml/5e256d9a-572c-e01e-7706-407f99245b00@arm.com/

>
> Cheers,
>
> --
> Julien Grall


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 09:53:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 09:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSHUf-0002F1-71; Sat, 25 Apr 2020 09:53:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSHUd-0002Er-S7
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 09:53:03 +0000
X-Inumbo-ID: 8a707538-86da-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8a707538-86da-11ea-9e09-bc764e2007e4;
 Sat, 25 Apr 2020 09:52:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Y+yuzevqqnBNk3PBGityRyRWic2i8s/QYVCRlMTKl5E=; b=S+bDDAADIn8oXJ0ABcNX4+d67
 1pUOFCF7lAbTZRXZ7tmJLpuB5gn6SmVuzrz48kBkoPA4yD39/0YBndAwrAW1spCEsbEpZJ7z1mRik
 Sa4yUwhs3Vrjo5gbZP6Jh4o6cgglU/0sDwNJxW+Qchm+vSrRsqlUIGhtIvJrpVT6J1CUs=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSHUW-0000yB-SZ; Sat, 25 Apr 2020 09:52:56 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSHUW-0000On-Jt; Sat, 25 Apr 2020 09:52:56 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSHUW-0002MW-JD; Sat, 25 Apr 2020 09:52:56 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149792-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149792: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
X-Osstest-Versions-That: xen=aa14feb6723d3bb15a884533ade1cd9732792145
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 09:52:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149792 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149792/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149783
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149783
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149783
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149783
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149783
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149783
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149783
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149783
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149783
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149783
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2
baseline version:
 xen                  aa14feb6723d3bb15a884533ade1cd9732792145

Last test of basis   149783  2020-04-24 13:59:56 Z    0 days
Testing same since   149792  2020-04-24 23:06:33 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   aa14feb672..96b5c267e5  96b5c267e52657e99bd1bbf81dd51925447115e2 -> master


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 11:01:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 11:01:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSIYa-0008AA-RX; Sat, 25 Apr 2020 11:01:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSIYY-0008A5-Us
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 11:01:11 +0000
X-Inumbo-ID: 10cde6fc-86e4-11ea-95a8-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 10cde6fc-86e4-11ea-95a8-12813bfff9fa;
 Sat, 25 Apr 2020 11:01:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ZzZgKynuYLj6TNIZ+JKRy3FHtgMYryytF2paB2GhVaM=; b=W5x3Zac6D3DL3GtAXFXUZZPYl
 hsD7y44YcF+mdjawnVSg++Kx61/z9vRCpiDfSYztbj9SQdZGtngpP99yowUhHZ+V1fxoMDWpEvsO3
 VP911nKTVwpvO528qI+bBzEJT7T3ZMgbGW2gSgRJX5zw4qXYpZGA+4dB/zKVfgW9JCX0A=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSIYV-0003DB-RC; Sat, 25 Apr 2020 11:01:07 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSIYV-000496-GY; Sat, 25 Apr 2020 11:01:07 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSIYV-0008KM-Ft; Sat, 25 Apr 2020 11:01:07 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149813-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149813: regressions - FAIL
X-Osstest-Failures: xen-unstable-smoke:build-amd64:xen-build:fail:regression
 xen-unstable-smoke:build-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 11:01:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149813 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149813/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 149784

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149784  2020-04-24 14:00:40 Z    0 days
Failing since        149785  2020-04-24 17:01:40 Z    0 days    6 attempts
Testing same since   149788  2020-04-24 20:00:41 Z    0 days    5 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-amd64-libvirt                                     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.

------------------------------------------------------------
commit f093b08c47b39da6019421a2b61d40745b3e573b
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Tue Apr 21 11:29:46 2020 -0700

    Introduce a description of the Backport and Fixes tags
    
    Create a new document under docs/process to describe our special tags.
    Add a description of the Fixes tag and the new Backport tag. Also
    clarify that lines with tags should not be split.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
    Acked-by: Wei Liu <wl@xen.org>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    CC: jbeulich@suse.com
    CC: george.dunlap@citrix.com
    CC: julien@xen.org
    CC: lars.kurth@citrix.com
    CC: andrew.cooper3@citrix.com
    CC: konrad.wilk@oracle.com

commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Apr 24 15:49:23 2020 +0100

    Update QEMU_TRADITIONAL_REVISION
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 12:32:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 12:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSJyt-00077R-SM; Sat, 25 Apr 2020 12:32:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=B69V=6J=tklsoftware.com=tamas@srs-us1.protection.inumbo.net>)
 id 1jSJys-00077M-RG
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 12:32:27 +0000
X-Inumbo-ID: d17c9a22-86f0-11ea-83d8-bc764e2007e4
Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d17c9a22-86f0-11ea-83d8-bc764e2007e4;
 Sat, 25 Apr 2020 12:32:25 +0000 (UTC)
Received: by mail-ed1-x541.google.com with SMTP id t12so9520644edw.3
 for <xen-devel@lists.xenproject.org>; Sat, 25 Apr 2020 05:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=tklengyel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=x7DGA0Y8hxTOAX6mUz79wqHjrw0aGHZMj/KL2ans5kU=;
 b=Qq+t3shK7GbYPv/jtsUcJ0KaHHlmMzcLvNx8EmqiN//TBgmBRVajhYsp4LL7hxzAiL
 Va+4028UT8qZ00ZEuJBIUyecojmmO4j+3ZF0S2FkHQYFdkkyTkqwzzDLg+n4EVZpCUJe
 mZ3indeVME4TT3kQNsVVtMvTMuW7pYLrD2PVjCO8m7AOK0V/z2c1hE+muwvR164q2Q81
 vHAs317WVhPFqWKWxa8+LZykIDxboBWKZRQa3o030/84uX1ysgVee8hYI+MbEoT9Ut+h
 LqYcRrEStmzWuiRDiJ7Fxf4MAGyrKtQRYSlxnEleJUFss4/1gYnSLTsAihUYNlgF0K4m
 9tYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=x7DGA0Y8hxTOAX6mUz79wqHjrw0aGHZMj/KL2ans5kU=;
 b=pGvA/a2W3UjDMf3hn1JgwOSbkI9yxeiGz+rbOVUejLAVMyO6lVhs2iCLGDU2nT3r9o
 3NzMHzouf/ZC1nfsMRa1FvzUnB+iQ2VTAEFBwgGA8/8Eay6illrWY6y+E8KU5JRftc88
 KkdovVt6+j3mgIZX7VzsQkNrF7upTwsQsVfa0hHTDU2dOWKVkoQJpAifgZbhzL4SIjfJ
 Ts8pEjuAE5SV9uFyWkpFrGxGJscXoPxDVIUyO0Ds6/AjBCqOs/5AcDFpOhGfe05vCil0
 Ue2ZuGucEBFhihOIkjFW4uS7Xz/ZF110kpjahlk68hGIDujA6G6oA8XorempgvsW27Tn
 oFhA==
X-Gm-Message-State: AGi0PuZ6MRYCY1Iy7RWuZTXQvku2YyJQMhOXOZQXU4wvlkmChPQ9GWdB
 ZxpeYiudGKy1ucF28RpMd7vW394ZH9A=
X-Google-Smtp-Source: APiQypIogJAEVLsaRfCsJxR9hwDfHl/PYMfLc+taZB8mCk5DrA7yX8l0yFb7EkKtJA+y1nb8sx8tWw==
X-Received: by 2002:a50:bb07:: with SMTP id y7mr11351468ede.358.1587817944489; 
 Sat, 25 Apr 2020 05:32:24 -0700 (PDT)
Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com.
 [209.85.221.42])
 by smtp.gmail.com with ESMTPSA id u18sm802506edx.27.2020.04.25.05.32.22
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 25 Apr 2020 05:32:23 -0700 (PDT)
Received: by mail-wr1-f42.google.com with SMTP id j2so14729556wrs.9
 for <xen-devel@lists.xenproject.org>; Sat, 25 Apr 2020 05:32:22 -0700 (PDT)
X-Received: by 2002:a05:6000:4:: with SMTP id
 h4mr17470403wrx.386.1587817942599; 
 Sat, 25 Apr 2020 05:32:22 -0700 (PDT)
MIME-Version: 1.0
References: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
 <20200424094343.GH28601@Air-de-Roger>
 <CABfawhnRhLJ0AKjTKBx7snEOHBX5oJ2KrwbscQk=e7qXHFD3mA@mail.gmail.com>
 <20200425090107.GK28601@Air-de-Roger>
In-Reply-To: <20200425090107.GK28601@Air-de-Roger>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Sat, 25 Apr 2020 06:31:46 -0600
X-Gmail-Original-Message-ID: <CABfawh=e-DjK2ONDV5DagMncLEvP-xA--+YsMOMuUWdM1hx0ug@mail.gmail.com>
Message-ID: <CABfawh=e-DjK2ONDV5DagMncLEvP-xA--+YsMOMuUWdM1hx0ug@mail.gmail.com>
Subject: Re: [PATCH v17 1/2] mem_sharing: fix sharability check during fork
 reset
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sat, Apr 25, 2020 at 3:01 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.com>=
 wrote:
>
> On Fri, Apr 24, 2020 at 06:18:24AM -0600, Tamas K Lengyel wrote:
> > On Fri, Apr 24, 2020 at 3:44 AM Roger Pau Monn=C3=A9 <roger.pau@citrix.=
com> wrote:
> > >
> > > On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> > > > When resetting a VM fork we ought to only remove pages that were al=
located for
> > > > the fork during it's execution and the contents copied over from th=
e parent.
> > > > This can be determined if the page is sharable as special pages use=
d by the
> > > > fork for other purposes will not pass this test. Unfortunately duri=
ng the fork
> > > > reset loop we only partially check whether that's the case. A page'=
s type may
> > > > indicate it is sharable (pass p2m_is_sharable) but that's not a suf=
ficient
> > > > check by itself. All checks that are normally performed before a pa=
ge is
> > > > converted to the sharable type need to be performed to avoid removi=
ng pages
> > > > from the p2m that may be used for other purposes. For example, curr=
ently the
> > > > reset loop also removes the vcpu info pages from the p2m, potential=
ly putting
> > > > the guest into infinite page-fault loops.
> > > >
> > > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> > >
> > > Reviewed-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> >
> > Thanks!
> >
> > >
> > > I've been looking however and I'm not able to spot where you copy the
> > > shared_info data, which I think it's also quite critical for the
> > > domain, as it contains the info about event channels (when using L2).
> > > Also for HVM forks the shared info should be mapped at the same gfn a=
s
> > > the parent, or else the child trying to access it will trigger an EPT
> > > fault that won't be able to populate such gfn, because the shared_inf=
o
> > > on the parent is already shared between Xen and the parent.
> >
> > Pages that cause an EPT fault but can't be made shared get a new page
> > allocated for them and copied in mem_sharing_fork_page. There are many
> > pages like that, mostly due to QEMU mapping them and thus holding an
> > extra reference. That said, shared_info is manually copied during
> > forking in copy_special_pages, at the end of the function you will
> > find:
> >
> > old_mfn =3D _mfn(virt_to_mfn(d->shared_info));
> > new_mfn =3D _mfn(virt_to_mfn(cd->shared_info));
> >
> > copy_domain_page(new_mfn, old_mfn);
>
> Yes, that's indeed fine, you need to copy the contents of the shared
> info page, but for HVM you also need to make sure the shared info page
> is mapped at the same gfn as the parent. HVM guest issue a hypercall
> to request the mapping of the shared info page to a specific gfn,
> since it's not added to the guest physmap by default.
> XENMAPSPACE_shared_info is used in order to request the shared info
> page to be mapped at a specific gfn.
>
> AFAICT during fork such shared info mapping is not replicated to the
> child, and hence the child trying to access the gfn of the shared info
> page would just result in EPT faults that won't be fixed (because the
> parent shared info page cannot be shared with the child)?
>
> You should be able to use get_gpfn_from_mfn in order to get the parent
> gfn where the shared info mfn is mapped (if any), and then replicate
> this in the child using it's own shared info.
>
> On fork reset you should check if the child shared info gfn !=3D parent
> shared info gfn and reinstate the parent state if different from the
> child.

OK, I see what you mean. In the way things set up currently the EPT
fault-loop problem doesn't happen since the page does get copied, it
just gets copied to a new mfn not the one d->shared_info points to. So
whatever issue that may bring it must be subtle because we haven't
noticed any instability.

Also, looking at the save/restore code in libxc it seems to me that
shared_info is actually a PV specific page and it doesn't get
saved/restored with an HVM domain. The hvm code paths don't process
REC_TYPE_SHARED_INFO at all. So since forks are exclusively for HVM
domains, do we really need it and if so, why doesn't HVM save/restore
need it?

Tamas


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 14:46:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 14:46:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSM4V-0001DD-3i; Sat, 25 Apr 2020 14:46:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSM4U-0001D8-Ib
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 14:46:22 +0000
X-Inumbo-ID: 845440d4-8703-11ea-9e09-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 845440d4-8703-11ea-9e09-bc764e2007e4;
 Sat, 25 Apr 2020 14:46:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=XSDnAeqYXTN8aODJMfzG01G6dAtKXotO5tw5pzBvfQc=; b=uVCfVW3JnIO1scLfm/jhvdJfz
 fp0ffrPJetXmzNQhewuRge6eagmDzXhbMl8c5zps1Ep7eN8T15kpmZkvQwG2g/4yFkDqxAF7K00bc
 VbAYkC8UKl6i3vHqFqwfwgn89hy6JMeIONf6cNho4IPSAua1dRfk7a+AvNT//P1ehihp8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSM4O-0007nF-2w; Sat, 25 Apr 2020 14:46:16 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSM4N-00076F-FT; Sat, 25 Apr 2020 14:46:15 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSM4N-00029S-Ep; Sat, 25 Apr 2020 14:46:15 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149818-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149818: regressions - FAIL
X-Osstest-Failures: xen-unstable-smoke:build-amd64:xen-build:fail:regression
 xen-unstable-smoke:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable-smoke:build-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 14:46:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149818 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149818/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 149784

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149784  2020-04-24 14:00:40 Z    1 days
Failing since        149785  2020-04-24 17:01:40 Z    0 days    7 attempts
Testing same since   149788  2020-04-24 20:00:41 Z    0 days    6 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-amd64-libvirt                                     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.

------------------------------------------------------------
commit f093b08c47b39da6019421a2b61d40745b3e573b
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Tue Apr 21 11:29:46 2020 -0700

    Introduce a description of the Backport and Fixes tags
    
    Create a new document under docs/process to describe our special tags.
    Add a description of the Fixes tag and the new Backport tag. Also
    clarify that lines with tags should not be split.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
    Acked-by: Wei Liu <wl@xen.org>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    CC: jbeulich@suse.com
    CC: george.dunlap@citrix.com
    CC: julien@xen.org
    CC: lars.kurth@citrix.com
    CC: andrew.cooper3@citrix.com
    CC: konrad.wilk@oracle.com

commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Apr 24 15:49:23 2020 +0100

    Update QEMU_TRADITIONAL_REVISION
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 14:52:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 14:52:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSMAj-00022l-SC; Sat, 25 Apr 2020 14:52:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSMAj-00022g-6Y
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 14:52:49 +0000
X-Inumbo-ID: 6a14bdb0-8704-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6a14bdb0-8704-11ea-b58d-bc764e2007e4;
 Sat, 25 Apr 2020 14:52:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=f5dwPdjWsKQQ71upVjGjwcs9LTEbSnFbePVEo83gpV4=; b=XXwERVfiM9qdC1dHyM/BTF2W4
 GHCpR53Llo3vCnZ2dm04Uqe40jBQXeUNDD8uB13gnX58i3HkldMhgIHVrKXXXXhta6MmLu6jAARea
 TRZKnw/zNE/00XXdodALLN7FzIc1BOQpQa5EQ99Sw74qB6zheGWdFN3IYU2LW8frZqvBk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSMAb-0007vx-Hs; Sat, 25 Apr 2020 14:52:41 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSMAb-0007IK-7C; Sat, 25 Apr 2020 14:52:41 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSMAb-0003oC-6W; Sat, 25 Apr 2020 14:52:41 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149807-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149807: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=ab51cac00ef2859f20a73d33a53f3a8987b65e11
X-Osstest-Versions-That: linux=b4f633221f0aeac102e463a4be46a643b2e3b819
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 14:52:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149807 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149807/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     16 guest-localmigrate           fail  like 149772
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149772
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149772
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149772
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149772
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149772
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149772
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149772
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149772
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                ab51cac00ef2859f20a73d33a53f3a8987b65e11
baseline version:
 linux                b4f633221f0aeac102e463a4be46a643b2e3b819

Last test of basis   149772  2020-04-24 03:58:26 Z    1 days
Failing since        149786  2020-04-24 19:09:32 Z    0 days    2 attempts
Testing same since   149807  2020-04-25 05:44:52 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Akshu Agrawal <akshu.agrawal@amd.com>
  Alessandro Rubini <rubini@gnudd.com>
  Alex Deucher <alexander.deucher@amd.com>
  Alex Deucher <alexdeucher@gmail.com>
  Alexander Aring <alex.aring@gmail.com>
  Alexander Tsoy <alexander@tsoy.me>
  Alexei Starovoitov <ast@kernel.org>
  Alexey Skobkin <skobkin-ru@ya.ru>
  Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
  Andrey Ignatov <rdna@fb.com>
  Andrii Nakryiko <andriin@fb.com>
  Andrzej Hajda <a.hajda@samsung.com>
  Andy Yan <andy.yan@rock-chips.com>
  Avinash Patil <avinashp@quantenna.com>
  Baruch Siach <baruch@tkos.co.il>
  Bjorn Andersson <bjorn.andersson@linaro.org>
  Bjorn Helgaas <bhelgaas@google.com>
  Bo YU <tsu.yubo@gmail.com>
  Brendan Higgins <brendanhiggins@google.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Charles Keepax <ckeepax@opensource.cirrus.com>
  Chris Rorvick <chris@rorvick.com>
  Chris Wilson <chris@chris-wilson.co.uk>
  Christian König <christian.koenig@amd.com>
  Damien Le Moal <damien.lemoal@wdc.com>
  Dan Carpenter <dan.carpenter@oracle.com>
  Daniel Vetter <daniel.vetter@ffwll.ch>
  Dave Airlie <airlied@redhat.com>
  David Ahern <dsahern@gmail.com>
  David Howells <dhowells@redhat.com>
  David S. Miller <davem@davemloft.net>
  Dejin Zheng <zhengdejin5@gmail.com>
  Diego Elio Pettenò <flameeyes@flameeyes.com>
  Doug Berger <opendmb@gmail.com>
  Douglas Anderson <dianders@chromium.org>
  Douglas Gilbert <dgilbert@interlog.com>
  Eric Dumazet <edumazet@google.com>
  Fabio Estevam <festevam@gmail.com>
  Florian Fainelli <f.fainelli@gmail.com>
  Florian Westphal <fw@strlen.de>
  Gregor Pintar <grpintar@gmail.com>
  Gyeongtaek Lee <gt82.lee@samsung.com>
  Hans de Goede <hdegoede@redhat.com>
  Hillf Danton <hdanton@sina.com>
  Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
  Ilan Peer <ilan.peer@intel.com>
  Ioana Ciornei <ioana.ciornei@nxp.com>
  Jakub Wilk <jwilk@jwilk.net>
  Jani Nikula <jani.nikula@intel.com>
  Jann Horn <jannh@google.com>
  Jason Gunthorpe <jgg@mellanox.com>
  Jason Yan <yanaijie@huawei.com>
  Jens Axboe <axboe@kernel.dk>
  Jere Leppänen <jere.leppanen@nokia.com>
  Jeremie Francois (on alpha) <jeremie.francois@gmail.com>
  Jernej Skrabec <jernej.skrabec@siol.net>
  Jerome Brunet <jbrunet@baylibre.com>
  Jesper Dangaard Brouer <brouer@redhat.com>
  Jessica Yu <jeyu@kernel.org>
  Jianpeng Ma <jianpeng.ma@intel.com>
  Jiri Slaby <jslaby@suse.cz>
  Johan Jonker <jbx6244@gmail.com>
  Johannes Berg <johannes.berg@intel.com>
  John Haxby <john.haxby@oracle.com>
  John Oldman <john.oldman@polehill.co.uk>
  Jonathan Corbet <corbet@lwn.net>
  José Roberto de Souza <jose.souza@intel.com>
  Julien Beraud <julien.beraud@orolia.com>
  Kai-Heng Feng <kai.heng.feng@canonical.com>
  Kailang Yang <kailang@realtek.com>
  Kalle Valo <kvalo@codeaurora.org>
  Krzysztof Kozlowski <krzk@kernel.org>
  Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Luca Coelho <luciano.coelho@intel.com>
  Luke Nelson <luke.r.nels@gmail.com>
  Luke Nelson <lukenels@cs.washington.edu>
  Lyude Paul <lyude@redhat.com>
  Ma, Jianpeng <jianpeng.ma@intel.com>
  Maciej Żenczykowski <maze@google.com>
  Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
  Manoj Malviya <manojmalviya@chelsio.com>
  Marc Zyngier <maz@kernel.org>
  Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
  Marek Szyprowski <m.szyprowski@samsung.com>
  Mark Brown <broonie@kernel.org>
  Mark Rutland <mark.rutland@arm.com>
  Markus Elfring <elfring@users.sourceforge.net>
  Martin K. Petersen <martin.petersen@oracle.com>
  Martin KaFai Lau <kafai@fb.com>
  Masahiro Yamada <masahiroy@kernel.org>
  Matt Roper <matthew.d.roper@intel.com>
  Matthias Blankertz <matthias.blankertz@cetitec.com>
  Maxim Mikityanskiy <maximmi@mellanox.com>
  Maxime Ripard <maxime@cerno.tech>
  Mengbing Wang <Mengbing.Wang@amd.com>
  Mikita Lipski <mikita.lipski@amd.com>
  Mordechay Goodstein <mordechay.goodstein@intel.com>
  Neil Armstrong <narmstrong@baylibre.com>
  Niklas Schnelle <schnelle@linux.ibm.com>
  Nikolay Borisov <nborisov@suse.com>
  Nils ANDRÉ-CHANG <nils@nilsand.re>
  Oliver Barta <oliver.barta@aptiv.com>
  Olivier Moysan <olivier.moysan@st.com>
  Ong Boon Leong <boon.leong.ong@intel.com>
  Pablo Neira Ayuso <pablo@netfilter.org>
  Paolo Abeni <pabeni@redhat.com>
  Paul Blakey <paulb@mellanox.com>
  Paul Moore <paul@paul-moore.com>
  Philipp Puschmann <p.puschmann@pironex.de>
  Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
  Pravin B Shelar <pshelar@ovn.org>
  Prike Liang <Prike.Liang@amd.com>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
  Randy Dunlap <rdunlap@infradead.org>
  Rodrigo Vivi <rodrigo.vivi@intel.com>
  Rohit Maheshwari <rohitm@chelsio.com>
  Roi Dayan <roid@mellanox.com>
  Russell King <rmk+kernel@armlinux.org.uk>
  Ryder Lee <ryder.lee@mediatek.com>
  Sabrina Dubroca <sd@queasysnail.net>
  Saeed Mahameed <saeedm@mellanox.com>
  Salvatore Bonaccorso <carnil@debian.org>
  Sam Ravnborg <sam@ravnborg.org>
  Sandeep Raghuraman <sandy.8925@gmail.com>
  Sebastian Fricke <sebastian.fricke.linux@gmail.com>
  Sebastian Reichel <sebastian.reichel@collabora.com>
  Sedat Dilek <sedat.dilek@gmail.com>
  Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
  Shengjiu Wang <shengjiu.wang@nxp.com>
  Soheil Hassas Yeganeh <soheil@google.com>
  Song Liu <songliubraving@fb.com>
  Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
  Stanislav Fomichev <sdf@google.com>
  Stephan Gerhold <stephan@gerhold.net>
  Stephen Hemminger <stephen@networkplumber.org>
  Steven Rostedt (VMware) <rostedt@goodmis.org>
  Sumit Garg <sumit.garg@linaro.org>
  Taehee Yoo <ap420073@gmail.com>
  Takashi Iwai <tiwai@suse.de>
  Tang Bin <tangbin@cmss.chinamobile.com>
  Tejun Heo <tj@kernel.org>
  Todd Brandt <todd.e.brandt@linux.intel.com>
  Toke Høiland-Jørgensen <toke@redhat.com>
  Tomi Valkeinen <tomi.valkeinen@ti.com>
  Tonghao Zhang <xiangxia.m.yue@gmail.com>
  Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com>
  Vasily Khoruzhick <anarsoul@gmail.com>
  Vishal Kulkarni <vishal@chelsio.com>
  Vishal Kulkarni <vishal@chelsio.com>"
  Vitor Massaru Iha <vitor@massaru.org>
  Vladimir Oltean <vladimir.oltean@nxp.com>
  Voon Weifeng <weifeng.voon@intel.com>
  Waiman Long <longman@redhat.com>
  Wang YanQing <udknight@gmail.com>
  Wei Yongjun <weiyongjun1@huawei.com>
  Will Deacon <will@kernel.org>
  Wu Bo <wubo40@huawei.com>
  Xi Wang <xi.wang@gmail.com>
  Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
  Xin Tan <tanxin.ctf@gmail.com>
  Xiumei Mu <xmu@redhat.com>
  Xiyu Yang <xiyuyang19@fudan.edu.cn>
  YueHaibing <yuehaibing@huawei.com>
  Yuiko Oshino <yuiko.oshino@microchip.com>
  Zhang Shengju <zhangshengju@cmss.chinamobile.com>
  Zhiqiang Liu <liuzhiqiang26@huawei.com>
  Zhu Yanjun <yanjunz@mellanox.com>
  Zou Wei <zou_wei@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   b4f633221f0a..ab51cac00ef2  ab51cac00ef2859f20a73d33a53f3a8987b65e11 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 17:51:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 17:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSOxd-0000Rs-A2; Sat, 25 Apr 2020 17:51:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSOxc-0000Rn-G7
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 17:51:28 +0000
X-Inumbo-ID: 62ce1556-871d-11ea-b58d-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 62ce1556-871d-11ea-b58d-bc764e2007e4;
 Sat, 25 Apr 2020 17:51:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=e0mFjqp+Ra85IEdoLIuQdWMSfKBPG/RfYpuvr7wKxzw=; b=QZhICZL8TTDHy1IFepEs2X4OQ
 tcNoLv27Rd/bYgWI4DQwvShckw9LDDtSg9WnPI6GgCHr7n5n7egGXjoAMSAYxjKIH7DWZ8qZUzDzq
 CeQu4scHdJXg4XMgElwVDwW9sxBoRu/6MeXoOuHG+xfcc+g8CMnRo43Sd5KjlmPIdPpYs=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSOxa-0003gf-NX; Sat, 25 Apr 2020 17:51:26 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSOxa-0005TQ-FV; Sat, 25 Apr 2020 17:51:26 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSOxa-0001Sn-Eu; Sat, 25 Apr 2020 17:51:26 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149821-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149821: regressions - FAIL
X-Osstest-Failures: xen-unstable-smoke:build-amd64:xen-build:fail:regression
 xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking
 xen-unstable-smoke:build-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 17:51:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149821 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149821/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 149784

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149784  2020-04-24 14:00:40 Z    1 days
Failing since        149785  2020-04-24 17:01:40 Z    1 days    8 attempts
Testing same since   149788  2020-04-24 20:00:41 Z    0 days    7 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-amd64-libvirt                                     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.

------------------------------------------------------------
commit f093b08c47b39da6019421a2b61d40745b3e573b
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Tue Apr 21 11:29:46 2020 -0700

    Introduce a description of the Backport and Fixes tags
    
    Create a new document under docs/process to describe our special tags.
    Add a description of the Fixes tag and the new Backport tag. Also
    clarify that lines with tags should not be split.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
    Acked-by: Wei Liu <wl@xen.org>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    CC: jbeulich@suse.com
    CC: george.dunlap@citrix.com
    CC: julien@xen.org
    CC: lars.kurth@citrix.com
    CC: andrew.cooper3@citrix.com
    CC: konrad.wilk@oracle.com

commit 3acfd35b61688ad9a5b843ee923221eb36e0b613
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Apr 24 15:49:23 2020 +0100

    Update QEMU_TRADITIONAL_REVISION
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 20:09:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 20:09:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSR6o-0002uP-HQ; Sat, 25 Apr 2020 20:09:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSR6n-0002uK-3p
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 20:09:05 +0000
X-Inumbo-ID: 9c0a1384-8730-11ea-9612-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9c0a1384-8730-11ea-9612-12813bfff9fa;
 Sat, 25 Apr 2020 20:09:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=UaTSYnKHG/NwD4OPgEXoD3lQVTh1aG8Rf1S7EkAHvnM=; b=AON1pc2VN63hhpqoB4rFqXtKH
 vKAN33ehXZIgy5eL+VbVlRaUjVS7pjc7UuN7SCN/p1/f4GGei02T1zV3f8kRhtoEdXmtA0Hbua50v
 XRPwq4KiF7+omwn5+ynqfylPeQK5bE0ylNs8bfkM571pCVxs94Zg6rBiG4jSgvulHpGoo=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSR6l-0006c1-9o; Sat, 25 Apr 2020 20:09:03 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSR6l-0002FW-2r; Sat, 25 Apr 2020 20:09:03 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSR6l-00080S-2H; Sat, 25 Apr 2020 20:09:03 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149822-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149822: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 20:09:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149822 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149822/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149784  2020-04-24 14:00:40 Z    1 days
Failing since        149785  2020-04-24 17:01:40 Z    1 days    9 attempts
Testing same since   149788  2020-04-24 20:00:41 Z    1 days    8 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   96b5c267e5..f093b08c47  f093b08c47b39da6019421a2b61d40745b3e573b -> smoke


From xen-devel-bounces@lists.xenproject.org Sat Apr 25 22:48:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Apr 2020 22:48:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSTaW-0007Ug-Ss; Sat, 25 Apr 2020 22:47:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JVj9=6J=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSTaV-0007Ub-6y
 for xen-devel@lists.xenproject.org; Sat, 25 Apr 2020 22:47:55 +0000
X-Inumbo-ID: c8e0cbe4-8746-11ea-9628-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c8e0cbe4-8746-11ea-9628-12813bfff9fa;
 Sat, 25 Apr 2020 22:47:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=v42xJ2G2gnyt+7pO9Wdk7Jj9BmBKuLJiNk6I/Ly53x0=; b=knXkWp7IpXuOjJU2qzg5tjmt2
 BSX9vwaO36GzZb/A2SPIOFKH5Frxj7LzTVql6ddizUTggiNWXUjocJyfooiu+2kxqre4IZrv4/bal
 PHJe4yoIw2twDQZM3qiu6YfXZBO134WxyNppOusZR3wpFHEBaKC6Rub1+iduxJjJZzUco=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSTaN-0001Qk-Ew; Sat, 25 Apr 2020 22:47:47 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSTaN-0001nf-71; Sat, 25 Apr 2020 22:47:47 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSTaN-0005pK-6J; Sat, 25 Apr 2020 22:47:47 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149816-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149816: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sat, 25 Apr 2020 22:47:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149816 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149816/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149792

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149792
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149792
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149792
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149792
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149792
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149792
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149792
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149792
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149792
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149792
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149816  2020-04-25 09:54:24 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Sun Apr 26 04:07:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Apr 2020 04:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSYZj-0006Z4-8n; Sun, 26 Apr 2020 04:07:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Wn3c=6K=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSYZh-0006YL-Mi
 for xen-devel@lists.xenproject.org; Sun, 26 Apr 2020 04:07:25 +0000
X-Inumbo-ID: 6c774afe-8773-11ea-9660-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6c774afe-8773-11ea-9660-12813bfff9fa;
 Sun, 26 Apr 2020 04:07:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=3Qsbzcu8Of4wDV2HHx9bp6n6M6vQVPxFh7wo5WlsLVs=; b=B64O1XuclFruhd0l+k3R1/GoL
 Tv1B2oAworbzIxBZ457Sp6J/0h/jeGUGZ57tlMaKLdZnfVJhDCofjl6/AXNuNSlqH2NQPIUNanpRv
 Pe8ShNSCWSYrdGTEm6n+dcd0oDrnNveRlXHAoJHcYg4sN4UBsRGPVVtUHqvV7qNG/0ukE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSYZb-0006qD-MC; Sun, 26 Apr 2020 04:07:19 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSYZb-0001Ph-C0; Sun, 26 Apr 2020 04:07:19 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSYZb-0007C1-9O; Sun, 26 Apr 2020 04:07:19 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149823-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149823: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=b2768df24ec400dd4f7fa79542f797e904812053
X-Osstest-Versions-That: linux=ab51cac00ef2859f20a73d33a53f3a8987b65e11
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 26 Apr 2020 04:07:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149823 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149823/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149807
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149807
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149807
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149807
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149807
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149807
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149807
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149807
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149807
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                b2768df24ec400dd4f7fa79542f797e904812053
baseline version:
 linux                ab51cac00ef2859f20a73d33a53f3a8987b65e11

Last test of basis   149807  2020-04-25 05:44:52 Z    0 days
Testing same since   149823  2020-04-25 19:38:22 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Eric W. Biederman" <ebiederm@xmission.com>
  Andrei Vagin <avagin@gmail.com>
  Borislav Petkov <bp@suse.de>
  Christian Brauner <christian.brauner@ubuntu.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  Eric W. Biederman <ebiederm@xmission.com>
  Giovanni Gherdovich <ggherdovich@suse.cz>
  Harry Pan <harry.pan@intel.com>
  Ian Rogers <irogers@google.com>
  Josh Poimboeuf <jpoimboe@redhat.com>
  Julien Thierry <jthierry@redhat.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Peter Zijlstra <peterz@infradead.org>
  Quentin Perret <qperret@google.com>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Thomas Gleixner <tglx@linutronix.de>
  Vincenzo Frascino <vincenzo.frascino@arm.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   ab51cac00ef2..b2768df24ec4  b2768df24ec400dd4f7fa79542f797e904812053 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sun Apr 26 06:15:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Apr 2020 06:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSaZN-0000mm-Qp; Sun, 26 Apr 2020 06:15:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Wn3c=6K=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSaZN-0000me-67
 for xen-devel@lists.xenproject.org; Sun, 26 Apr 2020 06:15:13 +0000
X-Inumbo-ID: 466f090c-8785-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 466f090c-8785-11ea-ae69-bc764e2007e4;
 Sun, 26 Apr 2020 06:15:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=6NcfLfhllQRvMvRSZ03XpX1iA8UF7avvG/Po3CH2nbk=; b=EKHIyCM3ZLwMZorUmJH2GdmSo
 g6pzt7d1UqG0k9apO0STrLbmbBjJjbMKGTA130QycmKzm6fXe6Hd9xBDbjO38/F3dH3FRj3qawaRi
 Y9QNrFFJ4luS9niZoDef0DdrkRbb0bXyHqeHcYEl+rwaB6OkVIvFu82rwwHAXRumnQESI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSaZG-0001RX-RO; Sun, 26 Apr 2020 06:15:06 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSaZG-0006u6-JC; Sun, 26 Apr 2020 06:15:06 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSaZG-000532-IN; Sun, 26 Apr 2020 06:15:06 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149825-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149825: all pass - PUSHED
X-Osstest-Versions-This: ovmf=c5c5c980dbaadf32193ac5e4ed2a35b665e0c76e
X-Osstest-Versions-That: ovmf=d5339c04d7cd47c061ec146a7b062052e3dc56ca
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 26 Apr 2020 06:15:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149825 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149825/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 c5c5c980dbaadf32193ac5e4ed2a35b665e0c76e
baseline version:
 ovmf                 d5339c04d7cd47c061ec146a7b062052e3dc56ca

Last test of basis   149766  2020-04-23 14:40:11 Z    2 days
Testing same since   149825  2020-04-26 01:40:21 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Guomin Jiang <guomin.jiang@intel.com>
  kuqin <kuqin@microsoft.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   d5339c04d7..c5c5c980db  c5c5c980dbaadf32193ac5e4ed2a35b665e0c76e -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Sun Apr 26 06:57:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Apr 2020 06:57:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSbDl-00046y-1P; Sun, 26 Apr 2020 06:56:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Wn3c=6K=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSbDj-00046t-Uf
 for xen-devel@lists.xenproject.org; Sun, 26 Apr 2020 06:56:55 +0000
X-Inumbo-ID: 1afb4a47-878b-11ea-9673-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1afb4a47-878b-11ea-9673-12813bfff9fa;
 Sun, 26 Apr 2020 06:56:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=UKO2WPumPdYhB2KGqzTbLXKJtdrRWBJt/7uFK11hyq8=; b=H4IBkfPjzZlrHwHPYf5ATpFCA
 SqERgS16APaAiRc02+HiNwm2zSjNHf0mt5zgPwoZbLaoHZ+FBHEMXW5M5haSsEvq1nn+cZN/Qymv0
 wrAyCYuMHBpmZyHIrqoFqugmsvRD6GP7opsfYPmOoG9gv+UTpejvLsH5eyiJSWejJl++8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSbDg-0002Hj-PY; Sun, 26 Apr 2020 06:56:52 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSbDg-0008Js-B5; Sun, 26 Apr 2020 06:56:52 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSbDg-0005ti-AN; Sun, 26 Apr 2020 06:56:52 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149826-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149826: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=6ebb00cd789478ef9017e3eb6b3db4260e57d4bb
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 26 Apr 2020 06:56:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149826 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149826/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
 build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-arm64-arm64-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      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       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              6ebb00cd789478ef9017e3eb6b3db4260e57d4bb
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z  100 days
Failing since        146211  2020-01-18 04:18:52 Z   99 days   92 attempts
Testing same since   149803  2020-04-25 04:18:54 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Chen Hanxiao <chen_han_xiao@126.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mark Asselstine <mark.asselstine@windriver.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Philipp Hahn <hahn@univention.de>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 16301 lines long.)


From xen-devel-bounces@lists.xenproject.org Sun Apr 26 10:10:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Apr 2020 10:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSeEd-0003gL-5n; Sun, 26 Apr 2020 10:10:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Wn3c=6K=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSeEb-0003Vr-Ju
 for xen-devel@lists.xenproject.org; Sun, 26 Apr 2020 10:10:01 +0000
X-Inumbo-ID: 16e32bb6-87a6-11ea-9686-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 16e32bb6-87a6-11ea-9686-12813bfff9fa;
 Sun, 26 Apr 2020 10:10:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=7wGYEHgU7+QpRIG/+r/0jjEgmjMDQYzNyElS5Z6FR0k=; b=e+VQLkj4osr8h44/wyF2ka3/2
 Ox74inbROujZWlPwafT1hECKAEKimBogtXFhXKoIGMWWCrukDtJayN/ZvS/VZ8/ideJGCqDVhQuqZ
 DSz+QtOEX1gMzBHQpzkVcUk76kG6pf3eHCRZMcI8VCZzdZlnfg3UO0juTtcJNAgehVlyk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSeEa-0006mB-HM; Sun, 26 Apr 2020 10:10:00 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSeEa-0006vI-8c; Sun, 26 Apr 2020 10:10:00 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSeEa-0000MT-80; Sun, 26 Apr 2020 10:10:00 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149827-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149827: all pass - PUSHED
X-Osstest-Versions-This: ovmf=0f1946b6626e263c7f764c21cc241cc9faf8a1ae
X-Osstest-Versions-That: ovmf=c5c5c980dbaadf32193ac5e4ed2a35b665e0c76e
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 26 Apr 2020 10:10:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149827 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149827/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 0f1946b6626e263c7f764c21cc241cc9faf8a1ae
baseline version:
 ovmf                 c5c5c980dbaadf32193ac5e4ed2a35b665e0c76e

Last test of basis   149825  2020-04-26 01:40:21 Z    0 days
Testing same since   149827  2020-04-26 06:40:24 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Shenglei Zhang <shenglei.zhang@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   c5c5c980db..0f1946b662  0f1946b6626e263c7f764c21cc241cc9faf8a1ae -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Sun Apr 26 10:12:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Apr 2020 10:12:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSeH6-0004Ex-KK; Sun, 26 Apr 2020 10:12:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Wn3c=6K=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSeH6-0004Er-4v
 for xen-devel@lists.xenproject.org; Sun, 26 Apr 2020 10:12:36 +0000
X-Inumbo-ID: 705db80a-87a6-11ea-9686-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 705db80a-87a6-11ea-9686-12813bfff9fa;
 Sun, 26 Apr 2020 10:12:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=i6Pomo+0QZ5P0PSDsn4n1LvJJUJJuR0UM5ipf+r2TQA=; b=YU/HuntA7SslD+LLiataJLwTw
 QjMl2d82GsQkZJw7lQwm5/eWeS6ibEKxr1HSZDu28YuMzkMdzXSXCQFxs6WFS3IO42LSyO5QwWs4S
 W9zBg2ZreGqQMoQkybbo/eM1YkbDuxUSz8ReBoHEba4tSUxJuHqQOhWD6gFLcPWl4HKLc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSeH0-0006q2-KA; Sun, 26 Apr 2020 10:12:30 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSeH0-0006yI-C8; Sun, 26 Apr 2020 10:12:30 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSeH0-0001Tu-BT; Sun, 26 Apr 2020 10:12:30 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149828-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-coverity test] 149828: all pass - PUSHED
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=5730ac3c8346f56fe8ee90249cdcbdab2a4d5791
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 26 Apr 2020 10:12:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149828 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149828/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  5730ac3c8346f56fe8ee90249cdcbdab2a4d5791

Last test of basis   149734  2020-04-22 09:18:32 Z    4 days
Testing same since   149828  2020-04-26 09:18:45 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  George Dunlap <george.dunlap@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Nick Rosbrook <rosbrookn@ainfosec.com>
  Nick Rosbrook <rosbrookn@gmail.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wl@xen.org>

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
   5730ac3c83..f093b08c47  f093b08c47b39da6019421a2b61d40745b3e573b -> coverity-tested/smoke


From xen-devel-bounces@lists.xenproject.org Sun Apr 26 10:35:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Apr 2020 10:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSedA-00063E-Jk; Sun, 26 Apr 2020 10:35:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Wn3c=6K=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSed9-000638-Qp
 for xen-devel@lists.xenproject.org; Sun, 26 Apr 2020 10:35:23 +0000
X-Inumbo-ID: a26d13f6-87a9-11ea-9688-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a26d13f6-87a9-11ea-9688-12813bfff9fa;
 Sun, 26 Apr 2020 10:35:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=rCga6xWsbCpV04rSe+IXlDUs+/0XLm4hWp0jKDDYSlU=; b=I4AdoH/IevQ96z/wCz2l1b7zt
 Otogk9xbgRzz0nWgGtTGa4yAHXD6Z3cPxerZQcmHzVQ43bYy6vcM31SSFqG1Np7TxZ0uD7jXvTxtB
 6EZLMSC/1DiJQcHE1++EH+nu0diQsc/qTjJ/uTrBn7jhgYavYGzoID6ig0iOc/jkFQ3Qc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSed9-0007Hp-3h; Sun, 26 Apr 2020 10:35:23 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSed8-0007Wl-Is; Sun, 26 Apr 2020 10:35:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSed8-0006l0-IG; Sun, 26 Apr 2020 10:35:22 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149824-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149824: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=96b5c267e52657e99bd1bbf81dd51925447115e2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 26 Apr 2020 10:35:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149824 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149824/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149816

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149816
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149816
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149816
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149816
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149816
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149816
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149816
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149816
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149816
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  96b5c267e52657e99bd1bbf81dd51925447115e2

Last test of basis   149816  2020-04-25 09:54:24 Z    1 days
Testing same since   149824  2020-04-25 23:07:27 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Stefano Stabellini <stefano.stabellini@xilinx.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   96b5c267e5..f093b08c47  f093b08c47b39da6019421a2b61d40745b3e573b -> master


From xen-devel-bounces@lists.xenproject.org Sun Apr 26 19:19:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Apr 2020 19:19:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSmna-0007AH-9Q; Sun, 26 Apr 2020 19:18:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ExO4=6K=yahoo.com=akm2tosher@srs-us1.protection.inumbo.net>)
 id 1jSmnY-0007AC-KV
 for xen-devel@lists.xenproject.org; Sun, 26 Apr 2020 19:18:41 +0000
X-Inumbo-ID: bbd43e7a-87f2-11ea-ae69-bc764e2007e4
Received: from sonic301-32.consmr.mail.ne1.yahoo.com (unknown [66.163.184.201])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bbd43e7a-87f2-11ea-ae69-bc764e2007e4;
 Sun, 26 Apr 2020 19:18:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1587928718; bh=pKjB4e1F4k6gQJpbfvWCA3uwHiFewYLBTulB8UVmSNU=;
 h=Date:From:To:Subject:References:From:Subject;
 b=CxGuJNDrhMHDq4QOIfT5Xk8pST8M34U5QpnhdP1kBXi9H23BFDY7iKsmRloaBfh9cLlAFZhU35VufQ2vMLSA5w3rI2oCjMkUDivu4vesuvpinU+v++FEIwNXTTUidXvTG7QChAOdOWaehFeln2NJmr2uDv1BcLxkcZly95BWvWwHTRoFmZj0mwkbW4U45P2NPmkwkCqd/UgpBUm5RF7ymJOM8P1SFNH55CAWw3DnYyDVmkpmQUntJUn1OGP+Zc8oZytZJPeYJkrNaQIPo92hFbc0DKeK1ICVmm3rl4ZVcDUoOmh/JvTZ1z2XV0g3zF4UfcaiNMHPUqM0p9Dh7+G7dA==
X-YMail-OSG: GK2PDk4VM1n07sRq3JSRT51S_cEflXcO8ujiQX4Y4njAfojnHWwVBoRPxBbS_fJ
 EPE8lo4r9lSLuMrxiHKgtELx.aCYD.WkyXGHi7wm8gCDhk8XpWwx7zuCQ1ymj0cJlUIZeAKp2Kk6
 L8mw7Y2I4YHw4gFuKRpkrqVnrDe9BaGOsfXAnxufz7YEF31PR7.G.r32.B4dOsy0jSNb4BUhpRZs
 _ikkbvNwIOKXVTHY_lGZuSgMb_2zsnQqPlonzVL0tB8G_L.hnLkuulh5H4wq4sbFDsk82v5jfUTB
 QZqbSW4HNDYq8OiTRheYu4i3Ubn_xtaz42oEZ6SOCMb1m.uBvnrqpRAqdM32TkAaTf7OsPIDFQUU
 Q6xe0cGlIhla_J58GZNRDqv_xHhCIVlV.QyXnniUvkABPthdbh9Upe5EPDyEPBvqwuJ90BEtDXy3
 Q3lbMYjQ2.ZWF23rnGY9hUciHS_5IvaAsD700aoLrLG4WEmVsk_KWrWrw3amvrM0XH97EeKuX9WG
 GCbD3RLIArwOxMkOdU6AK4xkSKGAaq5qAJ2nzxjj9F._zuABQ.kN5iNteNbQ9Nmy2pQ03iNMHkDd
 WmOJOgAQTIQuR8KWnL1kdtiZEC1VU22cJzCXcHV3bc5Ld1hkQgMafXC.R6j0jo_yayDMmJm9rhf2
 x5HC3E3jlb0qakv.iv9HjXtwqadugfv5ky27psrirY5usDO5BU9PVLf7QbyhX8ugWlR5diZ6YKFZ
 iCawZTdCmqlhwvtAGNSvTmmLEzA2ki4xyByTBRGSiIJgmGJeFpFZsNUJhD5Pa..bvmIme1V6JLed
 gQm9FcXn9MAKW.xuks2S8M_SjefITfskYlR0rIhaTXPz0d3FaXLsNG.E0AdbKlt3IV0sCKhPanIv
 hIL5giWo7KESi5EiQvOyaJYTnPK3Etk5.AI5gxmrpbNuCeKjwkwrICJCX7LyRu9GlAwpyEh8MSRf
 kFX7xiIurx8X_fsmzgYIRl3yQYtd6TiocUzj5r22Xsj3zDQbPyoUNdbleK9e4zyhCWMxf6lu_9Qg
 mpukpidEFvBbWLG8TH2QCeQQCRiTOGYLt02tyDGsLe4GwqBiFaHoZDY0qtaxIZecgZ8gmyzPiQtB
 G.fnJRqYeEn1qevMy4XczvYW5iGwdKJ_6zn1BBG3xegLiEbDNA.vHDmY4JN7hPedId6b23W49hVW
 pq7synpgZrV0qDZ_WmePyA6kMpDpJvdJlN0SA6EL32sD1_y.dIzZETD8.nx_mSiMGEm1.9St7aqC
 7kno3bdA9mjHia0jmVUOwuOp1z2FdRkgUfu5v1yAReg1TtQogYPxjrvi5iagKKWg1wMuDtifYd.9
 YwUrgFAdnN0LqmSTv
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic301.consmr.mail.ne1.yahoo.com with HTTP; Sun, 26 Apr 2020 19:18:38 +0000
Date: Sun, 26 Apr 2020 19:18:33 +0000 (UTC)
From: tosher 1 <akm2tosher@yahoo.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Message-ID: <1359850718.562651.1587928713792@mail.yahoo.com>
Subject: Xen network domain performance for 10Gb NIC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
References: <1359850718.562651.1587928713792.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.15756 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64;
 x64; rv:75.0) Gecko/20100101 Firefox/75.0
Content-Length: 1149
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

 Hi everyone,

Lately, I have been experimenting with 10Gb NIC performance on Xen domains. I have found that network performance is very poor for PV networking when a driver domain is used as a network backend.

My experimental setup is I have two machines connected by the 10Gb network: a server running the Xen hypervisor and a desktop machine working as a client. I have Ubuntu 18.04.3 LTS running on the Dom0, Domus, Driver Domain, and client desktop, where the Xen version is 4.9. I measured the network bandwidth using iPerf3.

The network bandwidth between a DomU using Dom0 as backend and the client desktop is like 9.39Gbits/sec. However, when I use a network driver domain, which has the 10Gb NIC by PCI pass through, the bandwidth between the DomU and the client desktop is like 2.41Gbit/sec is one direction and 4.48Gbits/sec in another direction. Here, by direction, I mean the client-server direction for iPerf3.

These results indicate a huge performance degradation, which is unexpected. I am wondering if I am missing any key points here which I should have taken care of or if there is any tweak that I can apply.

Thanks,
Mehrab


From xen-devel-bounces@lists.xenproject.org Sun Apr 26 21:36:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Apr 2020 21:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSowg-0001oW-AD; Sun, 26 Apr 2020 21:36:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Wn3c=6K=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSowe-0001oR-7r
 for xen-devel@lists.xenproject.org; Sun, 26 Apr 2020 21:36:12 +0000
X-Inumbo-ID: ef4f89ff-8805-11ea-96e4-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ef4f89ff-8805-11ea-96e4-12813bfff9fa;
 Sun, 26 Apr 2020 21:36:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/po9XdWMYSKjfoTeP+FhlkYv+yju+/v3sKDCOXOyPEY=; b=Fxw5Hqg9zJKQHWS1Hex2W5Sf6
 kggUVcBE6kcNMISyZ0DErOdCfPmDC9T0N+y7c7NOxnl+uVkY/gFR5Jr0hukfFzs0OmcSbG74FHC/1
 HpvcdfOkfc3Xqk8H4b41uWK47WfWBHiGjZRlFzyDHRS4laZtrFXVnLOLJ3fAhc683y53I=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSowX-0004W6-Pr; Sun, 26 Apr 2020 21:36:05 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSowX-0001AY-H9; Sun, 26 Apr 2020 21:36:05 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSowX-0003LN-EF; Sun, 26 Apr 2020 21:36:05 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149829-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149829: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-saverestore:fail:heisenbug
 xen-unstable:test-armhf-armhf-xl-vhd:guest-start:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=f093b08c47b39da6019421a2b61d40745b3e573b
From: osstest service owner <osstest-admin@xenproject.org>
Date: Sun, 26 Apr 2020 21:36:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149829 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149829/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds     15 guest-saverestore          fail pass in 149824
 test-armhf-armhf-xl-vhd      11 guest-start                fail pass in 149824

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 16 guest-localmigrate fail in 149824 blocked in 149829
 test-armhf-armhf-xl-vhd     12 migrate-support-check fail in 149824 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 149824 never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149824
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149824
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149824
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149824
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149824
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149824
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149824
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149824
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149824
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b

Last test of basis   149829  2020-04-26 10:37:15 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      fail    


------------------------------------------------------------
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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 03:22:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 03:22:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSuLE-0003oE-SJ; Mon, 27 Apr 2020 03:21:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6V0E=6L=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSuLE-0003o9-3v
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 03:21:56 +0000
X-Inumbo-ID: 396fe760-8836-11ea-9726-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 396fe760-8836-11ea-9726-12813bfff9fa;
 Mon, 27 Apr 2020 03:21:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=K5BZsN2Z0Mya1Jl1SzDMDDhIArhSPRL1JhPpmXT/ysg=; b=Ap0ahDxEfDznnfbQdncljFHCn
 mqRVR/shRj9PaH6Q05kGkaiHdhzJMVoMDHTSp4/GAIDq8IRbpuJcwnZzCV+MxNQPrwff1xKZ/ida+
 l04FJmGzdsSHFmishy/cALuGmObe5appXoEm5ogtClw4nq70/yQu1EV8xSRs2ajbwx68Y=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSuL3-0002e3-VO; Mon, 27 Apr 2020 03:21:46 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSuL3-0006XX-A1; Mon, 27 Apr 2020 03:21:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSuL3-0007Jj-97; Mon, 27 Apr 2020 03:21:45 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149830-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149830: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=e9a61afb69f07b1c5880984d45e5cc232ec1bf6f
X-Osstest-Versions-That: linux=b2768df24ec400dd4f7fa79542f797e904812053
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 27 Apr 2020 03:21:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149830 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149830/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149823
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149823
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149823
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149823
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149823
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149823
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149823
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149823
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149823
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                e9a61afb69f07b1c5880984d45e5cc232ec1bf6f
baseline version:
 linux                b2768df24ec400dd4f7fa79542f797e904812053

Last test of basis   149823  2020-04-25 19:38:22 Z    1 days
Testing same since   149830  2020-04-26 18:38:51 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alan Stern <stern@rowland.harvard.edu>
  Alexander Schmidt <alexs@linux.ibm.com>
  Alexandre Belloni <alexandre.belloni@bootlin.com>
  Alexandru Ardelean <alexandru.ardelean@analog.com>
  Amit Singh Tomar <amittomer25@gmail.com>
  Anatoly Pugachev <matorola@gmail.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrey Konovalov <andreyknvl@google.com>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Arnd Bergmann <arnd@arndb.de>
  Badhri Jagan Sridharan <badhri@google.com>
  Benjamin Lee <ben@b1c1l1.com>
  Changming Liu <liu.changm@northeastern.edu>
  Chris Packham <chris.packham@alliedtelesis.co.nz>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Christophe Leroy <christophe.leroy@c-s.fr>
  Claudio Imbrenda <imbrenda@linux.ibm.com>
  Colin Ian King <colin.king@canonical.com>
  Cristian Birsan <cristian.birsan@microchip.com>
  Dan Carpenter <dan.carpenter@oracle.com>
  Dmitry Safonov <dima@arista.com>
  Douglas Anderson <dianders@chromium.org>
  Fabrice Gasnier <fabrice.gasnier@st.com>
  Felipe Balbi <balbi@kernel.org>
  Geert Uytterhoeven <geert+renesas@glider.be>
  Georgi Djakov <georgi.djakov@linaro.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Hans de Goede <hdegoede@redhat.com>
  Hao Bui <hao.bui.yg@renesas.com>
  Heikki Krogerus <heikki.krogerus@linux.intel.com>
  Herbert Xu <herbert@gondor.apana.org.au>
  Ian Abbott <abbotti@mev.co.uk>
  Jann Horn <jannh@google.com>
  Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
  Jiri Slaby <jslaby@suse.cz>
  Jonas Karlsson <jonas.karlsson@actia.se>
  Jonathan Cameron <Jonathan.Cameron@huawei.com>
  Jonathan Cox <jonathan@jdcox.net>
  Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>
  KAZUMI HARADA <kazumi.harada.rh@renesas.com>
  Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
  Lars Engebretsen <lars@engebretsen.ch>
  Lars-Peter Clausen <lars@metafoo.de>
  Lary Gibaud <yarl-baudig@mailoo.org>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lorenzo Bianconi <lorenzo@kernel.org>
  Luis Chamberlain <mcgrof@kernel.org>
  Luis Mendes <luis.p.mendes@gmail.com>
  Malcolm Priestley <tvboxspy@gmail.com>
  Mark Brown <broonie@kernel.org>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Hennerich <michael.hennerich@analog.com>
  Michal Simek <michal.simek@xilinx.com>
  Mike Tipton <mdtipton@codeaurora.org>
  Mircea Caprioru <mircea.caprioru@analog.com>
  Moritz Fischer <mdf@kernel.org>
  Naoki Kiryu <naonaokiryu2@gmail.com>
  Nathan Chancellor <natechancellor@gmail.com>
  Nicolas Pitre <nico@fluxnic.net>
  Niklas Schnelle <schnelle@linux.ibm.com>
  Oliver Neukum <oneukum@suse.com>
  Olivier Moysan <olivier.moysan@st.com>
  Paul Zimmerman <pauldzim@gmail.com>
  Philipp Rudo <prudo@linux.ibm.com>
  Rob Herring <robh@kernel.org>
  Sam Ravnborg <sam@ravnborg.org>
  Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
  Sriharsha Allenki <sallenki@codeaurora.org>
  Syed Nayyar Waris <syednwaris@gmail.com>
  Thierry Reding <treding@nvidia.com>
  Thinh Nguyen <Thinh.Nguyen@synopsys.com>
  Thinh Nguyen <thinhn@synopsys.com>
  Udipto Goswami <ugoswami@codeaurora.org>
  Vasily Gorbik <gor@linux.ibm.com>
  Vitor Soares <vitor.soares@synopsys.com>
  William Breathitt Gray <vilhelm.gray@gmail.com>
  Wu Hao <hao.wu@intel.com>
  Xin Tan <tanxin.ctf@gmail.com>
  Xiyu Yang <xiyuyang19@fudan.edu.cn>
  Xu Yilun <yilun.xu@intel.com>
  Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
  YueHaibing <yuehaibing@huawei.com>
  Zou Wei <zou_wei@huawei.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   b2768df24ec4..e9a61afb69f0  e9a61afb69f07b1c5880984d45e5cc232ec1bf6f -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 03:40:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 03:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSudE-0005VU-Jk; Mon, 27 Apr 2020 03:40:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=UCaW=6L=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jSudD-0005VP-3A
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 03:40:31 +0000
X-Inumbo-ID: d76de5aa-8838-11ea-b07b-bc764e2007e4
Received: from mail-qt1-x842.google.com (unknown [2607:f8b0:4864:20::842])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d76de5aa-8838-11ea-b07b-bc764e2007e4;
 Mon, 27 Apr 2020 03:40:30 +0000 (UTC)
Received: by mail-qt1-x842.google.com with SMTP id x12so12688149qts.9;
 Sun, 26 Apr 2020 20:40:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=971x6VUzt76Bct6RLVEpnOoU0De5EYNxXyo8sYPzQmE=;
 b=fJZ7kZcKJtbBfe+iCziz8YSJaX/kV2w5DHb9qqvwqgk1Jn720L80bLQjqwGd/vN8jP
 cj9n/WXlDZwl2w3dztFuFEFrZ8nmSHWSWJSGAweaFJGsFFj1rcQ6d3iUFuEzJ8hz6TD5
 bGGlB+vwZxJvo+nAq6zyIwveQ6mCBZ287E3f2o/Pvb+J2Ql0Tn2xa9FfvvT5QeDXO2mN
 GfL3YTSvLpq3CQuhNlQPxFq9W54E6FzvncFhUF5newECjprdK4lRbz9ybMsizFcek3ZP
 2jwlDIKkmK+NTwYI2L645CsCCJVFC3MerFLnmRLrV9idFrX3ao6OcOo2wdI73VDK3FHr
 2aqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=971x6VUzt76Bct6RLVEpnOoU0De5EYNxXyo8sYPzQmE=;
 b=C2ZI4/+EhTLuMrS8IT880oPir38geKdVTZdv4OaNjWSgfndereRBldrbE0LJ5eS/pm
 2Ew8xkOnTeenwMqgPk9bfIcbWkoVqqf13PQ6WPjq36D4L6A8KwtfyWThTI5wIWYhwd8J
 t6pNszIiFm/CfouAyj+WK4eQmAR8/qh2q3BL6WuTUptJp9dIVm+OKO0p50K79x+4wtGK
 6zz12Y1fXh5Bv4hv4NxsotiNaofU5qlqeGNbcVrrBsAji0mWyEcjAugPfduJaBXGB2US
 MS/PtDtsxsLOA1g19VK9CZ6qbvd4LxEKvrt6+0NbMNk4NbVb4Wu/kbVWRBAC8lPx+Hmc
 IHrg==
X-Gm-Message-State: AGi0PubXH2R+h+qa4tTH4PaVQ3cGps22p6NuesaMt1vHNq081uUe08mz
 SBIlH2T+5sf2q7c0Tn+zEv7CeOl7
X-Google-Smtp-Source: APiQypJt0895FDL4vWX46DmjCi786MaTYClG+nR3fpMeXWIF2T9Ni/vZsZAjRQ6qkVOyoPVXvl1A1g==
X-Received: by 2002:ac8:108b:: with SMTP id a11mr21431996qtj.173.1587958829051; 
 Sun, 26 Apr 2020 20:40:29 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:d026:4ef9:a4d0:cab2])
 by smtp.gmail.com with ESMTPSA id d4sm9421866qtc.48.2020.04.26.20.40.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 26 Apr 2020 20:40:28 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH] mini-os: Avoid segfaults in tc{g,s}etattr
Date: Sun, 26 Apr 2020 23:40:19 -0400
Message-Id: <20200427034019.6251-1-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: samuel.thibault@ens-lyon.org, Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit c96c22f1d94 "mini-os: minimal implementations of some termios
functions" introduced implementations of tcgetattr and tcsetattr.
However, they do not check if files[fildes].cons.dev is non-NULL before
dereferencing.  This is not a problem for FDs allocated through
alloc_fd, but the files array pre-allocates FDs 0-2 for stdio.  Those
entries have a NULL .dev, so tc{g,s}etattr on them segfault.

ioemu-stubdom segfaults when term_init() calls tcgetattr on FD 0.

Restore tcgetattr and tcsetattr behavior when .dev is NULL equivalent to
unsupported_function as it was before c96c22f1d94.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
I can't get ioemu-stubdom to start without this.  With this, the guest
just reboots immediately, but it does that with a non-stubdom
device_model_version="qemu-xen-traditional" .  The same guest disk image
(cirros 0.5.1) boots with a linux stubdom or non-stubdom Ubuntu
qemu-system-x86_64.

 lib/sys.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/lib/sys.c b/lib/sys.c
index da434fc..c6a7b9f 100644
--- a/lib/sys.c
+++ b/lib/sys.c
@@ -1472,6 +1472,11 @@ int tcsetattr(int fildes, int action, const struct termios *tios)
             return -1;
     }
 
+    if (files[fildes].cons.dev == NULL) {
+        errno = ENOSYS;
+        return -1;
+    }
+
     if (tios->c_oflag & OPOST)
         files[fildes].cons.dev->is_raw = false;
     else
@@ -1492,6 +1497,11 @@ int tcgetattr(int fildes, struct termios *tios)
         return -1;
     }
 
+    if (files[fildes].cons.dev == NULL) {
+        errno = ENOSYS;
+        return 0;
+    }
+
     if (tios == NULL) {
         errno = EINVAL;
         return -1;
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 05:28:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 05:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSwJR-0007aV-31; Mon, 27 Apr 2020 05:28:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=5iRA=6L=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jSwJQ-0007aQ-KI
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 05:28:12 +0000
X-Inumbo-ID: e203fda6-8847-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e203fda6-8847-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 05:28:11 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E3573AE28;
 Mon, 27 Apr 2020 05:28:08 +0000 (UTC)
Subject: Re: Xen network domain performance for 10Gb NIC
To: tosher 1 <akm2tosher@yahoo.com>, Xen-devel <xen-devel@lists.xenproject.org>
References: <1359850718.562651.1587928713792.ref@mail.yahoo.com>
 <1359850718.562651.1587928713792@mail.yahoo.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <a06fdec5-9e9e-2319-e7f7-d68fdb48ffba@suse.com>
Date: Mon, 27 Apr 2020 07:28:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <1359850718.562651.1587928713792@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 26.04.20 21:18, tosher 1 wrote:
>   Hi everyone,
> 
> Lately, I have been experimenting with 10Gb NIC performance on Xen domains. I have found that network performance is very poor for PV networking when a driver domain is used as a network backend.
> 
> My experimental setup is I have two machines connected by the 10Gb network: a server running the Xen hypervisor and a desktop machine working as a client. I have Ubuntu 18.04.3 LTS running on the Dom0, Domus, Driver Domain, and client desktop, where the Xen version is 4.9. I measured the network bandwidth using iPerf3.
> 
> The network bandwidth between a DomU using Dom0 as backend and the client desktop is like 9.39Gbits/sec. However, when I use a network driver domain, which has the 10Gb NIC by PCI pass through, the bandwidth between the DomU and the client desktop is like 2.41Gbit/sec is one direction and 4.48Gbits/sec in another direction. Here, by direction, I mean the client-server direction for iPerf3.
> 
> These results indicate a huge performance degradation, which is unexpected. I am wondering if I am missing any key points here which I should have taken care of or if there is any tweak that I can apply.

Is the driver domain PV or HVM?

How many vcpus do dom0, the driver domain and the guest have?


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 06:18:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 06:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSx5a-0003P8-2z; Mon, 27 Apr 2020 06:17:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6V0E=6L=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jSx5Y-0003Nk-Vh
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 06:17:57 +0000
X-Inumbo-ID: d54439c6-884e-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d54439c6-884e-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 06:17:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=8MSYy79NqAe8GNbViCAmAQZVgTGjrWgeA4fX2dCk/yU=; b=uOBFpDiFAautaTWt4QT+cqPQL
 oJS69mOsHd6rODxPSxECFQbcqhF5Y33zSySQdI6CxRt5j4+Vh1Tx3h94f5lQ0yZrDX3DXvQANYDBW
 HmW79I+dnc7vuuofCu4Xmxo8Oid0RQZzQpCuX4s8D/3bxIcG/4oHohzGxdwrgy0eJeHX4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSx5X-0006ke-8d; Mon, 27 Apr 2020 06:17:55 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jSx5X-0007Pt-0G; Mon, 27 Apr 2020 06:17:55 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jSx5W-00026K-Vh; Mon, 27 Apr 2020 06:17:54 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149833-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149833: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=6ebb00cd789478ef9017e3eb6b3db4260e57d4bb
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 27 Apr 2020 06:17:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149833 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149833/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
 build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-amd64-i386-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-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 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
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              6ebb00cd789478ef9017e3eb6b3db4260e57d4bb
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z  101 days
Failing since        146211  2020-01-18 04:18:52 Z  100 days   93 attempts
Testing same since   149803  2020-04-25 04:18:54 Z    2 days    3 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Chen Hanxiao <chen_han_xiao@126.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mark Asselstine <mark.asselstine@windriver.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Philipp Hahn <hahn@univention.de>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 16301 lines long.)


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 07:03:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 07:03:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSxnf-0007a2-ML; Mon, 27 Apr 2020 07:03:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jrem=6L=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jSxnd-0007Zx-Tz
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 07:03:29 +0000
X-Inumbo-ID: 324b6cb0-8855-11ea-ae69-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 324b6cb0-8855-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 07:03:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587971008;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=BN3wGjAuN8c6DF9G6lxWdWTjyeenKN9BrohQiVa706k=;
 b=gnNrF8BOYMSKJfITc9OwDPqscKju3TrJ9DsPIsyKS0xdaPnVUU4Lt7em
 LqeBiO6pQmhpwCTpnH/GsDZT39vBgvNAlphYG1UynL2k2Bz/pphNpiqSx
 UfpGxnn1lkqLPFOZAS5JXTJkG3qIQ/ghH6zwSj1runOAC09au79zqMLVP I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: KKixjztdLUHt7/4mGwYZ2EU00Qdufx4HQ47+20+ml1fDoCHHlUPCXXEq0jMErO1/nz3itTOtCU
 AIxgpdxXav6fezM2D/eVXBhdTKhNDrNi1EuCZCoMSxd3mxcPLFlXeJsss60LZ9TMk78cqMPpYI
 doJKdTj9mawzSCfytBrCNvR0mjt6f6l/aGbgUu/sbJsL4MePH9MP8jTmHzJyHVpfB8XV1sRDkT
 m64F8/ga+gT3OmHkk6OeR2HVlr0ku5zUmYUZE6T9XeuCC7eay/OfqOXCw8WWF2a84AYhLfhqql
 uOc=
X-SBRS: 2.7
X-MesageID: 16969369
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,323,1583211600"; d="scan'208";a="16969369"
Date: Mon, 27 Apr 2020 09:03:17 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: tosher 1 <akm2tosher@yahoo.com>
Subject: Re: Xen network domain performance for 10Gb NIC
Message-ID: <20200427070317.GL28601@Air-de-Roger>
References: <1359850718.562651.1587928713792.ref@mail.yahoo.com>
 <1359850718.562651.1587928713792@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <1359850718.562651.1587928713792@mail.yahoo.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sun, Apr 26, 2020 at 07:18:33PM +0000, tosher 1 wrote:
>  Hi everyone,
> 
> Lately, I have been experimenting with 10Gb NIC performance on Xen domains. I have found that network performance is very poor for PV networking when a driver domain is used as a network backend.
> 
> My experimental setup is I have two machines connected by the 10Gb network: a server running the Xen hypervisor and a desktop machine working as a client. I have Ubuntu 18.04.3 LTS running on the Dom0, Domus, Driver Domain, and client desktop, where the Xen version is 4.9. I measured the network bandwidth using iPerf3.
> 
> The network bandwidth between a DomU using Dom0 as backend and the client desktop is like 9.39Gbits/sec. However, when I use a network driver domain, which has the 10Gb NIC by PCI pass through, the bandwidth between the DomU and the client desktop is like 2.41Gbit/sec is one direction and 4.48Gbits/sec in another direction. Here, by direction, I mean the client-server direction for iPerf3.
> 
> These results indicate a huge performance degradation, which is unexpected. I am wondering if I am missing any key points here which I should have taken care of or if there is any tweak that I can apply.

Driver domains with passthrough devices need to perform IOMMU
operations in order to add/remove page table entries when doing grant
maps (ie: IOMMU TLB flushes), while dom0 doesn't need to because it
has the whole RAM identity mapped in the IOMMU tables. Depending on
how fast your IOMMU is and what capabilities it has doing such
operations can introduce a significant amount of overhead.

I would give a try to a newer version of Xen also, there have been
some changes in IOMMU management, but I would guess your bottleneck
doesn't come from the code itself, but rather from the IOMMU.

Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 07:26:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 07:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSy9v-0000tp-Kj; Mon, 27 Apr 2020 07:26:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wbbE=6L=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jSy9u-0000tk-MN
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 07:26:30 +0000
X-Inumbo-ID: 694a37d4-8858-11ea-ae69-bc764e2007e4
Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 694a37d4-8858-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 07:26:29 +0000 (UTC)
Received: by mail-wr1-x442.google.com with SMTP id d15so17602887wrx.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 00:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=2sFt+Wl5nQfbKLhBnpXj+yuRCjH0wwQbgpo5vn/ll8E=;
 b=hY7F9sxspBbbidu6h43ncIlRd48Kx+6NDy194cOob4Y89WwbxUyVsHK8K0fGH1MFos
 wAl294tUW9Q2rsW6wYYdNsEy3qLbpjPQKERMCHmK9rZqagVhW1blmpBP2R5Y0C0V0EqW
 LDAlNkWPJs3DlxU8vQSIvSxoqKGUL8M0xLQeDoIW2LhKeJt+b4g873RDJBVKvHP2wXfd
 SnolXGT6rFFel1uTGVOZQsNEXxkx9xiylj1K2Zlk5HwArGGNKUjGGbHu+drW/su/9b6A
 hl4uUj2FHGpgJKJ7qEydqJrTEOGTyCUyhm//UpCgzpDiqCziX0rIdVxrFh0K+4pUnPXI
 6BIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=2sFt+Wl5nQfbKLhBnpXj+yuRCjH0wwQbgpo5vn/ll8E=;
 b=e62znsbTseP0PsFQhNi8tREqWz1N1F4tjlnJ9dMxhGwdn6obIaaY6BBAChlhWz00Uk
 7JB3DuMG2/mfpgIfGb6D/00k/R8uNg75oXJ+he9ZsXk1w3pSWlGnphDftqvn+CTrnXvc
 DXlqzE8y4kXCEP6AnnvL38ZK7+H7I/lF965gTyqSoEzh/tdi0LOwVd5zL7iDP4uZqjHz
 w/hKXwortDlnDW8PJmktQ8TtW0Pfa/PN9uBt306feD8DTK2f7i4tA/6g5ZOHzkv14xEk
 N8f8tcWjafnO7zc2k3vzek5eD79lgN54WVb6ajxCeiuqBizpiOCllVlEPViqy+Xthuqr
 NBTA==
X-Gm-Message-State: AGi0PubCfkie9Jj/zYppPOIRpaH/4RJlQb0RcqzfyM7hhFdc0sZqJR0R
 trZqs978euT+mdiwvkPxWik=
X-Google-Smtp-Source: APiQypK2bKec+4ymIXmjGvWiw4APZjCRf7StyGXywZhrVDw9ZyQWJ8wBUrrtAwZCfZuryHtH8dsfvQ==
X-Received: by 2002:a5d:6ccb:: with SMTP id c11mr26822982wrc.416.1587972388993; 
 Mon, 27 Apr 2020 00:26:28 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id a125sm14253155wme.3.2020.04.27.00.26.27
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 27 Apr 2020 00:26:28 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Markus Armbruster'" <armbru@redhat.com>,
	<qemu-devel@nongnu.org>
References: <20200424192027.11404-1-armbru@redhat.com>
 <20200424192027.11404-3-armbru@redhat.com>
In-Reply-To: <20200424192027.11404-3-armbru@redhat.com>
Subject: RE: [PATCH 02/11] xen: Fix and improve handling of device_add
 usb-host errors
Date: Mon, 27 Apr 2020 08:26:26 +0100
Message-ID: <000501d61c65$2a65af30$7f310d90$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQMXmDKzuqWE9I5CndWgcA3L3a4P9AL+km1ypfGklyA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Anthony Perard' <anthony.perard@citrix.com>,
 xen-devel@lists.xenproject.org, 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Gerd Hoffmann' <kraxel@redhat.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Markus Armbruster <armbru@redhat.com>
> Sent: 24 April 2020 20:20
> To: qemu-devel@nongnu.org
> Cc: Stefano Stabellini <sstabellini@kernel.org>; Anthony Perard <anthony.perard@citrix.com>; Paul
> Durrant <paul@xen.org>; Gerd Hoffmann <kraxel@redhat.com>; xen-devel@lists.xenproject.org
> Subject: [PATCH 02/11] xen: Fix and improve handling of device_add usb-host errors
> 
> usbback_portid_add() leaks the error when qdev_device_add() fails.
> Fix that.  While there, use the error to improve the error message.
> 
> The qemu_opts_from_qdict() similarly leaks on failure.  But any
> failure there is a programming error.  Pass &error_abort.
> 
> Fixes: 816ac92ef769f9ffc534e49a1bb6177bddce7aa2
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Paul Durrant <paul@xen.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: xen-devel@lists.xenproject.org
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>  hw/usb/xen-usb.c | 18 ++++++++----------
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
> index 961190d0f7..42643c3390 100644
> --- a/hw/usb/xen-usb.c
> +++ b/hw/usb/xen-usb.c
> @@ -30,6 +30,7 @@
>  #include "hw/usb.h"
>  #include "hw/xen/xen-legacy-backend.h"
>  #include "monitor/qdev.h"
> +#include "qapi/error.h"
>  #include "qapi/qmp/qdict.h"
>  #include "qapi/qmp/qstring.h"
> 
> @@ -755,13 +756,15 @@ static void usbback_portid_add(struct usbback_info *usbif, unsigned port,
>      qdict_put_int(qdict, "port", port);
>      qdict_put_int(qdict, "hostbus", atoi(busid));
>      qdict_put_str(qdict, "hostport", portname);
> -    opts = qemu_opts_from_qdict(qemu_find_opts("device"), qdict, &local_err);
> -    if (local_err) {
> -        goto err;
> -    }
> +    opts = qemu_opts_from_qdict(qemu_find_opts("device"), qdict,
> +                                &error_abort);
>      usbif->ports[port - 1].dev = USB_DEVICE(qdev_device_add(opts, &local_err));
>      if (!usbif->ports[port - 1].dev) {
> -        goto err;
> +        qobject_unref(qdict);
> +        xen_pv_printf(&usbif->xendev, 0,
> +                      "device %s could not be opened: %s\n",
> +                      busid, error_get_pretty(local_err));
> +        error_free(local_err);

Previously the goto caused the function to bail out. Should there not be a 'return' here?

>      }
>      qobject_unref(qdict);
>      speed = usbif->ports[port - 1].dev->speed;
> @@ -793,11 +796,6 @@ static void usbback_portid_add(struct usbback_info *usbif, unsigned port,
>      usbback_hotplug_enq(usbif, port);
> 
>      TR_BUS(&usbif->xendev, "port %d attached\n", port);
> -    return;
> -
> -err:
> -    qobject_unref(qdict);
> -    xen_pv_printf(&usbif->xendev, 0, "device %s could not be opened\n", busid);
>  }
> 
>  static void usbback_process_port(struct usbback_info *usbif, unsigned port)
> --
> 2.21.1




From xen-devel-bounces@lists.xenproject.org Mon Apr 27 07:42:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 07:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSyPK-0002Yn-5M; Mon, 27 Apr 2020 07:42:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=5iRA=6L=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jSyPI-0002Yi-Tl
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 07:42:24 +0000
X-Inumbo-ID: a20c6d92-885a-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a20c6d92-885a-11ea-b07b-bc764e2007e4;
 Mon, 27 Apr 2020 07:42:24 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5B50CADD5;
 Mon, 27 Apr 2020 07:42:22 +0000 (UTC)
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200424133736.737-1-paul@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <0736f34f-77a1-6e75-138f-06806c970d9b@suse.com>
Date: Mon, 27 Apr 2020 09:42:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200424133736.737-1-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.20 15:37, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
> 
> ... to specify a separate migration stream that will also be suitable for
> live update.
> 
> The original scope of the document was to support non-cooperative migration
> of guests [1] but, since then, live update of xenstored has been brought into
> scope. Thus it makes more sense to define a separate image format for
> serializing xenstore state that is suitable for both purposes.
> 
> The document has been limited to specifying a new image format. The mechanism
> for acquiring the image for live update or migration is not covered as that
> is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
> also expected that, when the first implementation of live update or migration
> making use of this specification is committed, that the document is moved from
> docs/designs into docs/specs.

Can we please add a general remark:

Records depending other records (e.g. watch records referencing a
connection record via a connection-id, or node records for a node
being a child of another node in the stream) must always be located
after the record they depend on.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 07:44:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 07:44:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSyRi-0002jd-N6; Mon, 27 Apr 2020 07:44:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wbbE=6L=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jSyRh-0002jV-BU
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 07:44:53 +0000
X-Inumbo-ID: faad5060-885a-11ea-ae69-bc764e2007e4
Received: from mail-wm1-x32f.google.com (unknown [2a00:1450:4864:20::32f])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id faad5060-885a-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 07:44:52 +0000 (UTC)
Received: by mail-wm1-x32f.google.com with SMTP id y24so19322482wma.4
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 00:44:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=g6pM6x7gWp0YETTZ6dn06MEPiM8VR9+qkaMRBEgIvJ8=;
 b=SRigLwwr5De/BO6748ot9+kpyuTZSu4QNyYz64rvaYfop2GrQFP0nXrArxWeJP0l54
 0mxivZSX1OJjB8csrkB/dpfMIoUaxRKwo9wS/A4Bxwrj0Rf7tT26VZHK27y8x4655Av1
 yNd5qAlW4WFZaRQvJEDgeHaeUE08FWfAc62PTUJ4Ds8eOOVFjmCtukTVxw+ydtfsqPed
 8AX3V3Rhzrlqig+MQkZYCcZtmkIa3H+SB/zhAy3G6EWafnnClegZm/Qmkcjkxz8KWimN
 y+orwc8R6EZ8au8oKqUWkyGEbh0orhj948/0EjGGc14+ZilTy2GgNs2uTMjQdkpzx8cW
 sJgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=g6pM6x7gWp0YETTZ6dn06MEPiM8VR9+qkaMRBEgIvJ8=;
 b=dCz2LhZ6IWTlPogjHbKiCZ6LujLn9kQ3tPZFQpLn/AISh1ekCuf7E4MauXE2w4t8ci
 f4Z6aJHaS4yQL3xyKucH/Q8CufguH0gtkLDlcXiiYl1UpL2aR3gyT28hXPfjvKgSc7I1
 z2Y68n3xkTxFLYii4gt8hwU4Bps0ziCVGrSy2YJeiTVcAvNKHVwGumbttIni/5pGj6RX
 93FmRYVbjvBw3Qh7SsqQwOD1zIyKy1IVaySaBSCitPkEsTKbWV5/XpwAHKeCszdf3/mf
 EXmGIRUUlSCwP5J4EC8VHFH1lWSwzR2j5/CfwpTwz/RZXYsL5Rajq02Obech3D6ZBvgM
 OxVA==
X-Gm-Message-State: AGi0PuYKz0f3T3KnhomQnK54SB3qoTH/S5PLM4mLbEcdzg6HPPzZ7F1v
 wxbseL2C8LGfimoRektAouc=
X-Google-Smtp-Source: APiQypIwhbHAz3bXtuMpMSJgb+iC889k2+S14nqii22IxN8UVSobf2zmihJ2q7mpqMinL6X6LnZcPg==
X-Received: by 2002:a1c:dc55:: with SMTP id t82mr26327745wmg.12.1587973491882; 
 Mon, 27 Apr 2020 00:44:51 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id v7sm13126966wmg.3.2020.04.27.00.44.50
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 27 Apr 2020 00:44:51 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= <jgross@suse.com>,
 <xen-devel@lists.xenproject.org>
References: <20200424133736.737-1-paul@xen.org>
 <0736f34f-77a1-6e75-138f-06806c970d9b@suse.com>
In-Reply-To: <0736f34f-77a1-6e75-138f-06806c970d9b@suse.com>
Subject: RE: [PATCH] docs/designs: re-work the xenstore migration document...
Date: Mon, 27 Apr 2020 08:44:50 +0100
Message-ID: <000601d61c67$bbd647c0$3382d740$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQIqV5bkCWemUTYZznnWnEmKpB0tyAGsFIK3p9a/THA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Paul Durrant' <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>
> Sent: 27 April 2020 08:42
> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Paul Durrant <pdurrant@amazon.com>
> Subject: Re: [PATCH] docs/designs: re-work the xenstore migration =
document...
>=20
> On 24.04.20 15:37, Paul Durrant wrote:
> > From: Paul Durrant <pdurrant@amazon.com>
> >
> > ... to specify a separate migration stream that will also be =
suitable for
> > live update.
> >
> > The original scope of the document was to support non-cooperative =
migration
> > of guests [1] but, since then, live update of xenstored has been =
brought into
> > scope. Thus it makes more sense to define a separate image format =
for
> > serializing xenstore state that is suitable for both purposes.
> >
> > The document has been limited to specifying a new image format. The =
mechanism
> > for acquiring the image for live update or migration is not covered =
as that
> > is more appropriately dealt with by a patch to =
docs/misc/xenstore.txt. It is
> > also expected that, when the first implementation of live update or =
migration
> > making use of this specification is committed, that the document is =
moved from
> > docs/designs into docs/specs.
>=20
> Can we please add a general remark:
>=20
> Records depending other records (e.g. watch records referencing a
> connection record via a connection-id, or node records for a node
> being a child of another node in the stream) must always be located
> after the record they depend on.
>=20

Sure. I'll call that out at the beginning of the records section.

  Paul

>=20
> Juergen



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 07:53:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 07:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSyaM-0003dP-KD; Mon, 27 Apr 2020 07:53:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=m6ex=6L=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jSyaK-0003dK-G9
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 07:53:48 +0000
X-Inumbo-ID: 3922cca2-885c-11ea-9745-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3922cca2-885c-11ea-9745-12813bfff9fa;
 Mon, 27 Apr 2020 07:53:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=S2VSSQT2kfz3fL8yU/OB6ihdy22xumVyR3OIKwJAw10=; b=KFC3Jcqe2X22p2b3CcG5hWiANn
 VSdrsvupXkJKwjlxh45Rj223WNMJbEeTlXCbDvssilxs4VvD/CHh/2FXeSjYaNKp0K95w9yRAGeAd
 4d9tQO3kKBzRS90UOhtA6t4U0ZE7PMM7c1QqJ6DQ0BZg30a1Jtrxk+w63kPrHNlOFIis=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <paul@xen.org>)
 id 1jSyaI-0000Gk-6p; Mon, 27 Apr 2020 07:53:46 +0000
Received: from [54.239.6.186] (helo=CBG-R90WXYV0.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jSyaH-0001yS-Mv; Mon, 27 Apr 2020 07:53:46 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2] docs/designs: re-work the xenstore migration document...
Date: Mon, 27 Apr 2020 08:53:42 +0100
Message-Id: <20200427075342.149-1-paul@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Durrant <pdurrant@amazon.com>

... to specify a separate migration stream that will also be suitable for
live update.

The original scope of the document was to support non-cooperative migration
of guests [1] but, since then, live update of xenstored has been brought into
scope. Thus it makes more sense to define a separate image format for
serializing xenstore state that is suitable for both purposes.

The document has been limited to specifying a new image format. The mechanism
for acquiring the image for live update or migration is not covered as that
is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
also expected that, when the first implementation of live update or migration
making use of this specification is committed, that the document is moved from
docs/designs into docs/specs.

[1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Juergen Gross <jgross@suse.com>
Andrew Cooper <andrew.cooper3@citrix.com>
George Dunlap <george.dunlap@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien@xen.org>
Stefano Stabellini <sstabellini@kernel.org>
Wei Liu <wl@xen.org>

v2:
 - Address comments from Juergen
---
 docs/designs/xenstore-migration.md | 475 +++++++++++++++++++----------
 1 file changed, 312 insertions(+), 163 deletions(-)

diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
index 6ab351e8fe..815aaeee59 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -3,254 +3,403 @@
 ## Background
 
 The design for *Non-Cooperative Migration of Guests*[1] explains that extra
-save records are required in the migrations stream to allow a guest running
-PV drivers to be migrated without its co-operation. Moreover the save
-records must include details of registered xenstore watches as well as
-content; information that cannot currently be recovered from `xenstored`,
-and hence some extension to the xenstore protocol[2] will also be required.
-
-The *libxenlight Domain Image Format* specification[3] already defines a
-record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
-transferring xenstore data pertaining to the domain directly as it is
-specified such that keys are relative to the path
-`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
-define at least one new save record type.
+save records are required in the migrations stream to allow a guest running PV
+drivers to be migrated without its co-operation. Moreover the save records must
+include details of registered xenstore watches as well ascontent; information
+that cannot currently be recovered from `xenstored`, and hence some extension
+to the xenstored implementations will also be required.
+
+As a similar set of data is needed for transferring xenstore data from one
+instance to another when live updating xenstored this document proposes an
+image format for a 'migration stream' suitable for both purposes.
 
 ## Proposal
 
-### New Save Record
+The image format consists of a _header_ followed by 1 or more _records_. Each
+record consists of a type and length field, followed by any data mandated by
+the record type. At minimum there will be a single record of type `END`
+(defined below).
 
-A new mandatory record type should be defined within the libxenlight Domain
-Image Format:
+### Header
 
-`0x00000007: DOMAIN_XENSTORE_DATA`
+The header identifies the stream as a `xenstore` stream, including the version
+of the specification that it complies with.
 
-An arbitrary number of these records may be present in the migration
-stream and may appear in any order. The format of each record should be as
-follows:
+All fields in this header must be in _big-endian_ byte order, regardless of
+the setting of the endianness bit.
 
 
 ```
     0       1       2       3       4       5       6       7    octet
 +-------+-------+-------+-------+-------+-------+-------+-------+
-| type                          | record specific data          |
-+-------------------------------+                               |
-...
-+---------------------------------------------------------------+
+| ident                                                         |
++-------------------------------+-------------------------------|
+| version                       | flags                         |
++-------------------------------+-------------------------------+
 ```
 
-where type is one of the following values
 
+| Field     | Description                                       |
+|-----------|---------------------------------------------------|
+| `ident`   | 0x78656e73746f7265 ('xenstore' in ASCII)          |
+|           |                                                   |
+| `version` | 0x00000001 (the version of the specification)     |
+|           |                                                   |
+| `flags`   | 0 (LSB): Endianness: 0 = little, 1 = big          |
+|           |                                                   |
+|           | 1-31: Reserved (must be zero)                     |
 
-| Field  | Description                                      |
-|--------|--------------------------------------------------|
-| `type` | 0x00000000: invalid                              |
-|        | 0x00000001: NODE_DATA                            |
-|        | 0x00000002: WATCH_DATA                           |
-|        | 0x00000003: TRANSACTION_DATA                     |
-|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
+### Records
 
+Records immediately follow the header and have the following format:
 
-and data is one of the record data formats described in the following
-sections.
 
+```
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| type                          | len                           |
++-------------------------------+-------------------------------+
+| body
+...
+|       | padding (0 to 7 octets)                               |
++-------+-------------------------------------------------------+
+```
+
+NOTE: padding octets here and in all subsequent format specifications must be
+      written as zero and should be ignored when the stream is read.
 
-NOTE: The record data does not contain an overall length because the
-libxenlight record header specifies the length.
 
+| Field  | Description                                          |
+|--------|------------------------------------------------------|
+| `type` | 0x00000000: END                                      |
+|        | 0x00000001: GLOBAL_DATA                              |
+|        | 0x00000002: CONNECTION_DATA                          |
+|        | 0x00000003: WATCH_DATA                               |
+|        | 0x00000004: TRANSACTION_DATA                         |
+|        | 0x00000005: NODE_DATA                                |
+|        | 0x00000006 - 0xFFFFFFFF: reserved for future use     |
+|        |                                                      |
+| `len`  | The length (in octets) of `body`                     |
+|        |                                                      |
+| `body` | The type-specific record data                        |
 
-**NODE_DATA**
+Some records will depend on other records in the migration stream. Records
+upon which other records depend must always appear earlier in the stream.
 
+The various formats of the type-specific data are described in the following
+sections:
 
-Each NODE_DATA record specifies a single node in xenstore and is formatted
-as follows:
+\pagebreak
 
+### END
+
+The end record marks the end of the image, and is the final record
+in the stream.
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| NODE_DATA                     |
-+-------------------------------+
-| path length                   |
-+-------------------------------+
-| path data                     |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
-| perm count (N)                |
-+-------------------------------+
-| perm0                         |
-+-------------------------------+
-...
-+-------------------------------+
-| permN                         |
-+-------------------------------+
-| value length                  |
-+-------------------------------+
-| value data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
 ```
 
-where perm0..N are formatted as follows:
 
+The end record contains no fields; its body length is 0.
+
+\pagebreak
+
+### GLOBAL_DATA
+
+This record is only relevant for live update. It contains details of global
+xenstored state that needs to be restored.
 
 ```
-    0       1       2       3     octet
+    0       1       2       3    octet
 +-------+-------+-------+-------+
-| perm  | pad   | domid         |
+| rw-socket-fd                  |
++-------------------------------+
+| ro-socket-fd                  |
 +-------------------------------+
 ```
 
 
-path length and value length are specified in octets (excluding the NUL
-terminator of the path). perm should be one of the ASCII values `w`, `r`,
-`b` or `n` as described in [2]. All pad values should be 0.
-All paths should be absolute (i.e. start with `/`) and as described in
-[2].
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `rw-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-write connections                       |
+|                |                                              |
+| `ro-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-only connections                        |
+
+xenstored will resume in the original process context. Hence `rw-socket-fd` and
+`ro-socket-fd` simply specify the file descriptors of the sockets.
 
 
-**WATCH_DATA**
+\pagebreak
 
+### CONNECTION_DATA
 
-Each WATCH_DATA record specifies a registered watch and is formatted as
-follows:
+For live update the image format will contain a `CONNECTION_DATA` record for
+each connection to xenstore. For migration it will only contain a record for
+the domain being migrated.
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| WATCH_DATA                    |
-+-------------------------------+
-| wpath length                  |
-+-------------------------------+
-| wpath data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| conn-id                       | pad                           |
++---------------+-----------------------------------------------+
+| conn-type     | conn-spec
 ...
++-------------------------------+-------------------------------+
+| data-len                      | data
 +-------------------------------+
-| token length                  |
-+-------------------------------+
-| token data                    |
 ...
-| pad (0 to 3 octets)           |
-+-------------------------------+
 ```
 
-wpath length and token length are specified in octets (excluding the NUL
-terminator). The wpath should be as described for the `WATCH` operation in
-[2]. The token is an arbitrary string of octets not containing any NUL
-values.
 
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | A non-zero number used to identify this         |
+|             | connection in subsequent connection-specific    |
+|             | records                                         |
+|             |                                                 |
+| `conn-type` | 0x0000: shared ring                             |
+|             | 0x0001: socket                                  |
+|             |                                                 |
+| `conn-spec` | See below                                       |
+|             |                                                 |
+| `data-len`  | The length (in octets) of any pending data not  |
+|             | yet written to the connection                   |
+|             |                                                 |
+| `data`      | Pending data (may be empty)                     |
 
-**TRANSACTION_DATA**
+The format of `conn-spec` is dependent upon `conn-type`.
 
+\pagebreak
 
-Each TRANSACTION_DATA record specifies an open transaction and is formatted
-as follows:
+For `shared ring` connections it is as follows:
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| TRANSACTION_DATA              |
-+-------------------------------+
-| tx_id                         |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
+                +-------+-------+-------+-------+-------+-------+
+                | domid         | tdomid        | flags         |
++---------------+---------------+---------------+---------------+
+| revtchn                       | levtchn                       |
++-------------------------------+-------------------------------+
+| mfn                                                           |
++---------------------------------------------------------------+
 ```
 
-where tx_id is the non-zero identifier values of an open transaction.
-
 
-### Protocol Extension
+| Field      | Description                                      |
+|------------|--------------------------------------------------|
+| `domid`    | The domain-id that owns the shared page          |
+|            |                                                  |
+| `tdomid`   | The domain-id that `domid` acts on behalf of if  |
+|            | it has been subject to an SET_TARGET             |
+|            | operation [2] or DOMID_INVALID otherwise         |
+|            |                                                  |
+| `flags`    | A bit-wise OR of:                                |
+|            | 0x0001: INTRODUCE has been issued                |
+|            | 0x0002: RELEASE has been issued                  |
+|            |                                                  |
+| `revtchn`  | The port number of the interdomain channel used  |
+|            | by `domid` to communicate with xenstored         |
+|            |                                                  |
+| `levtchn`  | For a live update this will be the port number   |
+|            | of the interdomain channel used by xenstored     |
+|            | itself otherwise, for migration, it will be -1   |
+|            |                                                  |
+| `mfn`      | The MFN of the shared page for a live update or  |
+|            | INVALID_MFN otherwise                            |
+
+Since the ABI guarantees that entry 1 in `domid`'s grant table will always
+contain the GFN of the shared page, so for a live update `mfn` can be used to
+give confidence that `domid` has not been re-cycled during the update.
+
+
+For `socket` connections it is as follows:
 
-Before xenstore state is migrated it is necessary to wait for any pending
-reads, writes, watch registrations etc. to complete, and also to make sure
-that xenstored does not start processing any new requests (so that new
-requests remain pending on the shared ring for subsequent processing on the
-new host). Hence the following operation is needed:
 
 ```
-QUIESCE                 <domid>|
-
-Complete processing of any request issued by the specified domain, and
-do not process any further requests from the shared ring.
+    0       1       2       3       4       5       6       7    octet
+                +-------+-------+-------+-------+-------+-------+
+                | flags         | socket-fd                     |
+                +---------------+-------------------------------+
 ```
 
-The `WATCH` operation does not allow specification of a `<domid>`; it is
-assumed that the watch pertains to the domain that owns the shared ring
-over which the operation is passed. Hence, for the tool-stack to be able
-to register a watch on behalf of a domain a new operation is needed:
 
-```
-ADD_DOMAIN_WATCHES      <domid>|<watch>|+
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `flags`     | A bit-wise OR of:                               |
+|             | 0001: read-only                                 |
+|             |                                                 |
+| `socket-fd` | The file descriptor of the connected socket     |
 
-Adds watches on behalf of the specified domain.
+This type of connection is only relevant for live update, where the xenstored
+resumes in the original process context. Hence `socket-fd` simply specify
+the file descriptor of the socket connection.
 
-<watch> is a NUL separated tuple of <path>|<token>. The semantics of this
-operation are identical to the domain issuing WATCH <path>|<token>| for
-each <watch>.
-```
+\pagebreak
+
+### WATCH_DATA
+
+The image format will contain a `WATCH_DATA` record for each watch registered
+by a connection for which there is `CONNECTION_DATA` record previously present.
 
-The watch information for a domain also needs to be extracted from the
-sending xenstored so the following operation is also needed:
 
 ```
-GET_DOMAIN_WATCHES      <domid>|<index>   <gencnt>|<watch>|*
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++---------------+---------------+
+| wpath-len     | token-len     |
++---------------+---------------+
+| wpath
+...
+| token
+...
+```
+
 
-Gets the list of watches that are currently registered for the domain.
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | The connection that issued the `WATCH`          |
+|             | operation [2]                                   |
+|             |                                                 |
+| `wpath-len` | The length (in octets) of `wpath` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `token-len` | The length (in octets) of `token` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `wpath`     | The watch path, as specified in the `WATCH`     |
+|             | operation                                       |
+|             |                                                 |
+| `token`     | The watch identifier token, as specified in the |
+|             | `WATCH` operation                               |
+
+\pagebreak
+
+### TRANSACTION_DATA
+
+The image format will contain a `TRANSACTION_DATA` record for each transaction
+that is pending on a connection for which there is `CONNECTION_DATA` record
+previously present.
 
-<watch> is a NUL separated tuple of <path>|<token>. The sub-list returned
-will start at <index> items into the the overall list of watches and may
-be truncated (at a <watch> boundary) such that the returned data fits
-within XENSTORE_PAYLOAD_MAX.
 
-If <index> is beyond the end of the overall list then the returned sub-
-list will be empty. If the value of <gencnt> changes then it indicates
-that the overall watch list has changed and thus it may be necessary
-to re-issue the operation for previous values of <index>.
 ```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++-------------------------------+
+```
+
+
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `conn-id`      | The connection that issued the               |
+|                | `TRANSACTION_START` operation [2]            |
+|                |                                              |
+| `tx-id`        | The transaction id passed back to the domain |
+|                | by the `TRANSACTION_START` operation         |
+
+\pagebreak
 
-To deal with transactions that were pending when the domain is migrated
-it is necessary to start transactions with the same tx_id on behalf of the
-domain in the receiving xenstored.
+### NODE_DATA
 
-NOTE: For safety each such transaction should result in an `EAGAIN` when
-the `TRANSACTION_END` operation is performed, as modifications made under
-the tx_id will not be part of the migration stream.
+For live update the image format will contain a `NODE_DATA` record for each
+node in xenstore. For migration it will only contain a record for the nodes
+relating to the domain being migrated. The `NODE_DATA` may be related to
+a _committed_ node (globally visible in xenstored) or a _pending_ node (created
+or modified by a transaction for which there is also a `TRANSACTION_DATA`
+record previously present).
 
-The `TRANSACTION_START` operation does not allow specification of a
-`<domid>`; it is assumed that the transaction pertains to the domain that
-owns the shared ring over which the operation is passed. Neither does it
-allow a `<transid>` to be specified; it is always chosen by xenstored.
-Hence, for the tool-stack to be able to open a transaction on behalf of a
-domain a new operation is needed:
 
 ```
-START_DOMAIN_TRANSACTION    <domid>|<transid>|
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++---------------+---------------+
+| access        | perm-count    |
++---------------+---------------+
+| perm1                         |
++-------------------------------+
+...
++-------------------------------+
+| permN                         |
++---------------+---------------+
+| path-len      | value-len     |
++---------------+---------------+
+| path
+...
+| value
+...
+```
+
+
+| Field        | Description                                    |
+|--------------|------------------------------------------------|
+| `conn-id`    | If this value is non-zero then this record     |
+|              | related to a pending transaction               |
+|              |                                                |
+| `tx-id`      | This value should be ignored if `conn-id` is   |
+|              | zero. Otherwise it specifies the id of the     |
+|              | pending transaction                            |
+|              |                                                |
+| `access`     | This value should be ignored if this record    |
+|              | does not relate to a pending transaction,      |
+|              | otherwise it specifies the accesses made to    |
+|              | the node and hence is a bitwise OR of:         |
+|              |                                                |
+|              | 0x0001: read                                   |
+|              | 0x0002: written                                |
+|              |                                                |
+|              | The value will be zero for a deleted node      |
+|              |                                                |
+| `perm-count` | The number (N) of node permission specifiers   |
+|              | (which will be 0 for a node deleted in a       |
+|              | pending transaction)                           |
+|              |                                                |
+| `perm1..N`   | A list of zero or more node permission         |
+|              | specifiers (see below)                         |
+|              |                                                |
+| `path-len`   | The length (in octets) of `path` including the |
+|              | NUL terminator                                 |
+|              |                                                |
+| `value-len`  | The length (in octets) of `value` (which will  |
+|              | be zero for a deleted node)                    |
+|              |                                                |
+| `path`       | The absolute path of the node                  |
+|              |                                                |
+| `value`      | The node value (which may be empty or contain  |
+|              | NUL octets)                                    |
+
+
+A node permission specifier has the following format:
 
-Starts a transaction on behalf of a domain.
 
-The semantics of this are similar to the domain issuing
-TRANSACTION_START and receiving the specified <transid> as the response.
-The main difference is that the transaction will be immediately marked as
-'conflicting' such that when the domain issues TRANSACTION_END T|, it will
-result in EAGAIN.
+```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| perm  | pad   | domid         |
++-------+-------+---------------+
 ```
 
-It may also be desirable to state in the protocol specification that
-the `INTRODUCE` operation should not clear the `<gfn>` specified such that
-a `RELEASE` operation followed by an `INTRODUCE` operation form an
-idempotent pair. The current implementation of *C xentored* does this
-(in the `domain_conn_reset()` function) but this could be dropped as this
-behaviour is not currently specified and the page will always be zeroed
-for a newly created domain.
+| Field   | Description                                         |
+|---------|-----------------------------------------------------|
+| `perm`  | One of the ASCII values `w`, `r`, `b` or `n` as     |
+|         | specified for the `SET_PERMS` operation [2]         |
+|         |                                                     |
+| `domid` | The domain-id to which the permission relates       |
 
 
 * * *
 
 [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
+
 [2] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/xenstore.txt
-[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/specs/libxl-migration-stream.pandoc
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 07:54:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 07:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSybC-0003iJ-3q; Mon, 27 Apr 2020 07:54:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=S7B6=6L=ens-lyon.org=samuel.thibault@srs-us1.protection.inumbo.net>)
 id 1jSybB-0003iA-Ev
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 07:54:41 +0000
X-Inumbo-ID: 54033638-885c-11ea-9745-12813bfff9fa
Received: from hera.aquilenet.fr (unknown [185.233.100.1])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 54033638-885c-11ea-9745-12813bfff9fa;
 Mon, 27 Apr 2020 07:54:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 2AFA8CEF9;
 Mon, 27 Apr 2020 09:54:31 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id nw7wnHQHPFDg; Mon, 27 Apr 2020 09:54:30 +0200 (CEST)
Received: from function (lfbn-bor-1-797-11.w86-234.abo.wanadoo.fr
 [86.234.239.11])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 49EB5C9D2;
 Mon, 27 Apr 2020 09:54:30 +0200 (CEST)
Received: from samy by function with local (Exim 4.93)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1jSyaz-006Sd2-B3; Mon, 27 Apr 2020 09:54:29 +0200
Date: Mon, 27 Apr 2020 09:54:29 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Jason Andryuk <jandryuk@gmail.com>
Subject: Re: [PATCH] mini-os: Avoid segfaults in tc{g,s}etattr
Message-ID: <20200427075429.mshevnm2ype7tq32@function>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Jason Andryuk <jandryuk@gmail.com>,
 minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
References: <20200427034019.6251-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200427034019.6251-1-jandryuk@gmail.com>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Jason Andryuk, le dim. 26 avril 2020 23:40:19 -0400, a ecrit:
> Commit c96c22f1d94 "mini-os: minimal implementations of some termios
> functions" introduced implementations of tcgetattr and tcsetattr.
> However, they do not check if files[fildes].cons.dev is non-NULL before
> dereferencing.  This is not a problem for FDs allocated through
> alloc_fd, but the files array pre-allocates FDs 0-2 for stdio.  Those
> entries have a NULL .dev, so tc{g,s}etattr on them segfault.
> 
> ioemu-stubdom segfaults when term_init() calls tcgetattr on FD 0.
> 
> Restore tcgetattr and tcsetattr behavior when .dev is NULL equivalent to
> unsupported_function as it was before c96c22f1d94.
> 
> Signed-off-by: Jason Andryuk <jandryuk@gmail.com>

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Thanks!

> ---
> I can't get ioemu-stubdom to start without this.  With this, the guest
> just reboots immediately, but it does that with a non-stubdom
> device_model_version="qemu-xen-traditional" .  The same guest disk image
> (cirros 0.5.1) boots with a linux stubdom or non-stubdom Ubuntu
> qemu-system-x86_64.
> 
>  lib/sys.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/lib/sys.c b/lib/sys.c
> index da434fc..c6a7b9f 100644
> --- a/lib/sys.c
> +++ b/lib/sys.c
> @@ -1472,6 +1472,11 @@ int tcsetattr(int fildes, int action, const struct termios *tios)
>              return -1;
>      }
>  
> +    if (files[fildes].cons.dev == NULL) {
> +        errno = ENOSYS;
> +        return -1;
> +    }
> +
>      if (tios->c_oflag & OPOST)
>          files[fildes].cons.dev->is_raw = false;
>      else
> @@ -1492,6 +1497,11 @@ int tcgetattr(int fildes, struct termios *tios)
>          return -1;
>      }
>  
> +    if (files[fildes].cons.dev == NULL) {
> +        errno = ENOSYS;
> +        return 0;
> +    }
> +
>      if (tios == NULL) {
>          errno = EINVAL;
>          return -1;
> -- 
> 2.20.1
> 


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 08:03:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 08:03:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSyjh-0005DW-GF; Mon, 27 Apr 2020 08:03:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jSyjf-0005DR-JY
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 08:03:27 +0000
X-Inumbo-ID: 928614c4-885d-11ea-9747-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 928614c4-885d-11ea-9747-12813bfff9fa;
 Mon, 27 Apr 2020 08:03:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B4D7CACF2;
 Mon, 27 Apr 2020 08:03:24 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86: refine guest_mode()
Message-ID: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
Date: Mon, 27 Apr 2020 10:03:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The 2nd of the assertions as well as the macro's return value have been
assuming we're on the primary stack. While for most IST exceptions we
eventually switch back to the main one, for #DF we intentionally never
do, and hence a #DF actually triggering on a user mode insn (which then
is still a Xen bug) would in turn trigger this assertion, rather than
cleanly logging state.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
While we could go further and also assert we're on the correct IST
stack in an "else" ti the "if()" added, I'm not fully convinced this
would be generally helpful. I'll be happy to adjust accordingly if
others think differently; at such a point though I think this should
then no longer be a macro.

--- a/xen/include/asm-x86/regs.h
+++ b/xen/include/asm-x86/regs.h
@@ -10,9 +10,10 @@
     /* Frame pointer must point into current CPU stack. */                    \
     ASSERT(diff < STACK_SIZE);                                                \
     /* If not a guest frame, it must be a hypervisor frame. */                \
-    ASSERT((diff == 0) || (r->cs == __HYPERVISOR_CS));                        \
+    if ( diff < PRIMARY_STACK_SIZE )                                          \
+        ASSERT(!diff || ((r)->cs == __HYPERVISOR_CS));                        \
     /* Return TRUE if it's a guest frame. */                                  \
-    (diff == 0);                                                              \
+    !diff || ((r)->cs != __HYPERVISOR_CS);                                    \
 })
 
 #endif /* __X86_REGS_H__ */


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 08:28:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 08:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jSz7C-00070f-Ew; Mon, 27 Apr 2020 08:27:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jrem=6L=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jSz7B-00070a-QN
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 08:27:45 +0000
X-Inumbo-ID: f7a6e2c2-8860-11ea-b07b-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f7a6e2c2-8860-11ea-b07b-bc764e2007e4;
 Mon, 27 Apr 2020 08:27:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587976065;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=VamndsIc6D4njTKjruX3ezIU6Oaxfq7corgjz5d5xS4=;
 b=iXesne0S654rhx3qKkZ80tTlALciI5+qfTgHWbvDXF8Bdv/VsmCSp/0F
 Qz3/ASF8wfSEVSr3jXf2K0jSHCURQfLRLm+ye4hjzZdGDX/X+OIHa8ySu
 s3ZhU/G+ZECimOwRkDxfCb9i9B7NhC+KJx7pG6Fwg4MXyPl5OkgYTFn02 o=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: HbSE5VdzEWDEh3BCDRYkZrCPom25cCnaUppFJG9/MwFoaO2ULKeO79inTeJy4TGsyvUxIe8QN4
 gBQ3LyiIaoY6y40M6HFOAUaS5KroPzHdwDED7itd6Fr442BvY5gmmNiX1kHJ4RmbVAWvLPul5g
 bMApA6y2Me3Cyma+Tod/qu/Pttt9FsApANXnu0RVi45vWtNxhg5Ye6I3k6OvDsO+ZIZIz0AITa
 rSXfOTxeP8lm8dI2VzuagUifCt9QFvxVl/SK3jXmJ2tcie3aBSqumJyk+H2EVYCsFQ6VfGcXtF
 Qwk=
X-SBRS: 2.7
X-MesageID: 16268685
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,323,1583211600"; d="scan'208";a="16268685"
Date: Mon, 27 Apr 2020 10:27:34 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Subject: Re: [PATCH v17 1/2] mem_sharing: fix sharability check during fork
 reset
Message-ID: <20200427082734.GM28601@Air-de-Roger>
References: <70ea4889e30ed35760329331ddfeb279fcd80786.1587655725.git.tamas.lengyel@intel.com>
 <20200424094343.GH28601@Air-de-Roger>
 <CABfawhnRhLJ0AKjTKBx7snEOHBX5oJ2KrwbscQk=e7qXHFD3mA@mail.gmail.com>
 <20200425090107.GK28601@Air-de-Roger>
 <CABfawh=e-DjK2ONDV5DagMncLEvP-xA--+YsMOMuUWdM1hx0ug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABfawh=e-DjK2ONDV5DagMncLEvP-xA--+YsMOMuUWdM1hx0ug@mail.gmail.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sat, Apr 25, 2020 at 06:31:46AM -0600, Tamas K Lengyel wrote:
> On Sat, Apr 25, 2020 at 3:01 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
> >
> > On Fri, Apr 24, 2020 at 06:18:24AM -0600, Tamas K Lengyel wrote:
> > > On Fri, Apr 24, 2020 at 3:44 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
> > > >
> > > > On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> > > > > When resetting a VM fork we ought to only remove pages that were allocated for
> > > > > the fork during it's execution and the contents copied over from the parent.
> > > > > This can be determined if the page is sharable as special pages used by the
> > > > > fork for other purposes will not pass this test. Unfortunately during the fork
> > > > > reset loop we only partially check whether that's the case. A page's type may
> > > > > indicate it is sharable (pass p2m_is_sharable) but that's not a sufficient
> > > > > check by itself. All checks that are normally performed before a page is
> > > > > converted to the sharable type need to be performed to avoid removing pages
> > > > > from the p2m that may be used for other purposes. For example, currently the
> > > > > reset loop also removes the vcpu info pages from the p2m, potentially putting
> > > > > the guest into infinite page-fault loops.
> > > > >
> > > > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> > > >
> > > > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> > >
> > > Thanks!
> > >
> > > >
> > > > I've been looking however and I'm not able to spot where you copy the
> > > > shared_info data, which I think it's also quite critical for the
> > > > domain, as it contains the info about event channels (when using L2).
> > > > Also for HVM forks the shared info should be mapped at the same gfn as
> > > > the parent, or else the child trying to access it will trigger an EPT
> > > > fault that won't be able to populate such gfn, because the shared_info
> > > > on the parent is already shared between Xen and the parent.
> > >
> > > Pages that cause an EPT fault but can't be made shared get a new page
> > > allocated for them and copied in mem_sharing_fork_page. There are many
> > > pages like that, mostly due to QEMU mapping them and thus holding an
> > > extra reference. That said, shared_info is manually copied during
> > > forking in copy_special_pages, at the end of the function you will
> > > find:
> > >
> > > old_mfn = _mfn(virt_to_mfn(d->shared_info));
> > > new_mfn = _mfn(virt_to_mfn(cd->shared_info));
> > >
> > > copy_domain_page(new_mfn, old_mfn);
> >
> > Yes, that's indeed fine, you need to copy the contents of the shared
> > info page, but for HVM you also need to make sure the shared info page
> > is mapped at the same gfn as the parent. HVM guest issue a hypercall
> > to request the mapping of the shared info page to a specific gfn,
> > since it's not added to the guest physmap by default.
> > XENMAPSPACE_shared_info is used in order to request the shared info
> > page to be mapped at a specific gfn.
> >
> > AFAICT during fork such shared info mapping is not replicated to the
> > child, and hence the child trying to access the gfn of the shared info
> > page would just result in EPT faults that won't be fixed (because the
> > parent shared info page cannot be shared with the child)?
> >
> > You should be able to use get_gpfn_from_mfn in order to get the parent
> > gfn where the shared info mfn is mapped (if any), and then replicate
> > this in the child using it's own shared info.
> >
> > On fork reset you should check if the child shared info gfn != parent
> > shared info gfn and reinstate the parent state if different from the
> > child.
> 
> OK, I see what you mean. In the way things set up currently the EPT
> fault-loop problem doesn't happen since the page does get copied, it
> just gets copied to a new mfn not the one d->shared_info points to. So
> whatever issue that may bring it must be subtle because we haven't
> noticed any instability.

In any case I think it would be good if you could add such mapping on
domain fork and reset, as you already partially handle the shared info
page by copying the data from the parent into the child. Or at least
add a FIXME comment to note the fact that a child trying to access the
shared info page won't work.

> Also, looking at the save/restore code in libxc it seems to me that
> shared_info is actually a PV specific page and it doesn't get
> saved/restored with an HVM domain. The hvm code paths don't process
> REC_TYPE_SHARED_INFO at all. So since forks are exclusively for HVM
> domains, do we really need it and if so, why doesn't HVM save/restore
> need it?

HVM domains on suspend/resume are aware of the need to re-instate the
shared info mapping, as it's part of the protocol and the guest is
actively cooperating on such actions. The same happens with the vcpu
info pages or the PV timers for example: they are not saved during a
suspend/resume and the guest needs to setup them again on restore.

Fork however is completely transparent from a guest PoV, and hence
there's no way to signal the child it needs to setup the shared info
mapping (or any other mapping or interface FWIW).

Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 09:47:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 09:47:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT0Lb-0005U6-Q4; Mon, 27 Apr 2020 09:46:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oTJa=6L=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jT0La-0005U1-If
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 09:46:42 +0000
X-Inumbo-ID: fdc748d0-886b-11ea-974f-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id fdc748d0-886b-11ea-974f-12813bfff9fa;
 Mon, 27 Apr 2020 09:46:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587980799;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=oJswjhzBTiefkpVsFIjUnMokq0duzsFgotK/E6vUzs0=;
 b=fO33Me8oOtV8iMg8K+POh+mZ2QewR550AYIbUAta3hcAcAzWGlp+SN5u
 OiCD2hbHdapMAOR9IXwWyNQLApaakky7iRKzjBKPDaJPtE8sR9flNHHKs
 xNxyNjyqeELl7N+LBsItRtPyJrahhP4uH+jP/p9eX1mzXZZdPkQvdJBjp 0=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: tkJBaL4wiIXD/F8yyz9kgBaUnDKE/smQCOWhVNPgoFXHBClaPONtp13GZzhwnnUvtH6aE58RjV
 P0n4JpDzgtPQFkzrMtBWZuCFtBlg3vcwbUlL9f6C0LWBOL2F8xgqBXgGv1eS5lCUeGQ7fOBLOk
 GEAPhbgfr4DgU5+y3W0/OLcRsRmyENFA7R3iSl+q2n+KyMx+1zQ1pm/XMH6kNXfGQFjV6BUsxs
 zhUlFG+PaPwLSeyuWODI2gxn6OswmdeQO4H48LBNqJjZUNmW0Q4FEKwibgmo47rpqV4/4e/Pj/
 J2A=
X-SBRS: 2.7
X-MesageID: 16604035
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,323,1583211600"; d="scan'208";a="16604035"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH 2/2] golang/xenlight: stop tracking generated files
Thread-Topic: [PATCH 2/2] golang/xenlight: stop tracking generated files
Thread-Index: AQHWGQW3KWV19rAkYkmTfkaVJgFqA6iMneeA
Date: Mon, 27 Apr 2020 09:46:35 +0000
Message-ID: <F960BC2C-8E5C-4E1E-9808-988844012426@citrix.com>
References: <cover.1587599094.git.rosbrookn@ainfosec.com>
 <f4fd2508a9cbceec2d1b8b480d4e4a15422d67d2.1587599095.git.rosbrookn@ainfosec.com>
In-Reply-To: <f4fd2508a9cbceec2d1b8b480d4e4a15422d67d2.1587599095.git.rosbrookn@ainfosec.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <6A2FB48AC54E2F41A42B80EB69F4639F@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 Nick Rosbrook <rosbrookn@ainfosec.com>, Jan Beulich <jbeulich@suse.com>, Ian
 Jackson <Ian.Jackson@citrix.com>, xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQo+IE9uIEFwciAyMywgMjAyMCwgYXQgMToyNSBBTSwgTmljayBSb3Nicm9vayA8cm9zYnJvb2tu
QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGUgZ2VuZXJhdGVkIGdvIGZpbGVzIHdlcmUgdHJh
Y2tlZCB0ZW1wb3JhcmlseSB3aGlsZSB0aGUgaW5pdGlhbA0KPiBpbXBsZW1lbnRhdGlvbiBvZiBn
ZW5nb3R5cGVzLnB5IHdhcyBpbiBwcm9ncmVzcy4gVGhleSBjYW4gbm93IGJlIHJlbW92ZWQNCj4g
YW5kIGlnbm9yZWQgYnkgZ2l0IGFuZCBoZy4NCj4gDQo+IFdoaWxlIGhlcmUsIG1ha2Ugc3VyZSBn
ZW5lcmF0ZWQgZmlsZXMgYXJlIHJlbW92ZWQgYnkgbWFrZSBjbGVhbi4NCj4gDQo+IFNpZ25lZC1v
ZmYtYnk6IE5pY2sgUm9zYnJvb2sgPHJvc2Jyb29rbkBhaW5mb3NlYy5jb20+DQoNCkp1c3QgdG8g
YmUgY2xlYXIsIHRvIG9ubG9va2VycyAocGFydGljdWxhcmx5IGNvbW1pdHRlcnMpOiBpdOKAmXMg
bG9va2luZyBsaWtlIHdl4oCZcmUgZ29pbmcgdG8gbGVhdmUgdGhlIGdlbmVyYXRlZCBmaWxlcyBp
biB0aGUgdHJlZTsgc28gdGhpcyBwYXRjaCBpcyBwcm9iYWJseSBvYnNvbGV0ZS4NCg0KIC1HZW9y
Z2U=


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 09:59:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 09:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT0Xv-0006Vh-T2; Mon, 27 Apr 2020 09:59:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jrem=6L=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jT0Xu-0006Vc-Sf
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 09:59:26 +0000
X-Inumbo-ID: c492fad0-886d-11ea-9750-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c492fad0-886d-11ea-9750-12813bfff9fa;
 Mon, 27 Apr 2020 09:59:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587981562;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=48S0TXs23gXxDUUpiYjHmCrV+8owKESkeo9sF5f/npw=;
 b=OJFazssvCnUwwe3X6KS0EFZoAqNS+aAdco9+nQbikLVuBHUhQ6KNqtcZ
 ylTQ7i/E9AzIdOHMPW7XKRwC3Tz3lascPupfOefv4zqYpxlnZoHMa/ag/
 UQ3Q5U0BeAWREZ/wpwhYCbxf/UP2PziiPn6YI30HoJgmuDHAyeGQw1Gy0 I=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: XAk5OT5Q7kEAVDG/t14KFml7B60zZImLnw5T3t6TycVbKoeVa2QuV9bPjEUdFgVUxuPiLJw0gp
 vkwvd6YtX2ecbC+xjfLVDlS1zn8f/qWpfY91SJh5h1QCJJKnkb63QuqT9VlOwACK5OL2/fYbSw
 r5V0HLLqFvrXZ88RW2AONrskWtk2lWJDS9B1pSk9U15DtPfw7W37T3Y35V8ZuAbL4l3P4nldw+
 XWAiifdiCPxBfdP608xjLShy7hjvuNNXypb8MUho9GwoL4wVcq4uVwBbbLDW9dEGUHPGHQRYUB
 fsg=
X-SBRS: 2.7
X-MesageID: 16304291
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,323,1583211600"; d="scan'208";a="16304291"
Date: Mon, 27 Apr 2020 11:59:13 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86: refine guest_mode()
Message-ID: <20200427095913.GN28601@Air-de-Roger>
References: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 10:03:05AM +0200, Jan Beulich wrote:
> The 2nd of the assertions as well as the macro's return value have been
> assuming we're on the primary stack. While for most IST exceptions we
> eventually switch back to the main one, for #DF we intentionally never
> do, and hence a #DF actually triggering on a user mode insn (which then
> is still a Xen bug) would in turn trigger this assertion, rather than
> cleanly logging state.
> 
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> While we could go further and also assert we're on the correct IST
> stack in an "else" ti the "if()" added, I'm not fully convinced this
> would be generally helpful. I'll be happy to adjust accordingly if
> others think differently; at such a point though I think this should
> then no longer be a macro.
> 
> --- a/xen/include/asm-x86/regs.h
> +++ b/xen/include/asm-x86/regs.h
> @@ -10,9 +10,10 @@
>      /* Frame pointer must point into current CPU stack. */                    \
>      ASSERT(diff < STACK_SIZE);                                                \
>      /* If not a guest frame, it must be a hypervisor frame. */                \
> -    ASSERT((diff == 0) || (r->cs == __HYPERVISOR_CS));                        \
> +    if ( diff < PRIMARY_STACK_SIZE )                                          \
> +        ASSERT(!diff || ((r)->cs == __HYPERVISOR_CS));                        \

Why not use:

ASSERT(diff >= PRIMARY_STACK_SIZE || !diff || ((r)->cs == __HYPERVISOR_CS));

I'm not sure I fully understand this layout, is it possible that you
also need to account for the size of cpu_info?

Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 10:12:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 10:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT0kq-0008ET-2u; Mon, 27 Apr 2020 10:12:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Fhyl=6L=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jT0ko-0008EO-Nm
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 10:12:46 +0000
X-Inumbo-ID: a3ee47ba-886f-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a3ee47ba-886f-11ea-9887-bc764e2007e4;
 Mon, 27 Apr 2020 10:12:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
 MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ikXeH5pqkWd9nkgispYOKOu5xKy4tP8PB0LrN6CIN/M=; b=paeT7ovTS2gkLQosjxIwZmw7VE
 JXp/LlvIh+bmeiBBOPVq55p6FeptftX/QUbvZFyJG0RzJv3wQ+gxCYT6e0uU2JDPhIEbSjwt0slVv
 ryEVq0ZZxIApTU3+g0ATWn1VMITytz+dObtA3MhL76XkmA7X1f/pUxOlUAWN3rUDgbxY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jT0ki-0003iC-9I; Mon, 27 Apr 2020 10:12:40 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jT0kh-0005Ee-Vi; Mon, 27 Apr 2020 10:12:40 +0000
Date: Mon, 27 Apr 2020 11:12:35 +0100
From: Wei Liu <wl@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v11 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200427101235.6xko3lvt3qajo64m@debian>
References: <20200423145611.55378-1-roger.pau@citrix.com>
 <20200423145611.55378-2-roger.pau@citrix.com>
 <59e48d80-8ce1-3f3d-c07e-5117adea272a@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <59e48d80-8ce1-3f3d-c07e-5117adea272a@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 06:33:49PM +0200, Jan Beulich wrote:
> On 23.04.2020 16:56, Roger Pau Monne wrote:
> > Introduce a specific flag to request a HVM guest linear TLB flush,
> > which is an ASID/VPID tickle that forces a guest linear to guest
> > physical TLB flush for all HVM guests.
> > 
> > This was previously unconditionally done in each pre_flush call, but
> > that's not required: HVM guests not using shadow don't require linear
> > TLB flushes as Xen doesn't modify the pages tables the guest runs on
> > in that case (ie: when using HAP). Note that shadow paging code
> > already takes care of issuing the necessary flushes when the shadow
> > page tables are modified.
> > 
> > In order to keep the previous behavior modify all shadow code TLB
> > flushes to also flush the guest linear to physical TLB if the guest is
> > HVM. I haven't looked at each specific shadow code TLB flush in order
> > to figure out whether it actually requires a guest TLB flush or not,
> > so there might be room for improvement in that regard.
> > 
> > Also perform ASID/VPID flushes when modifying the p2m tables as it's a
> > requirement for AMD hardware. Finally keep the flush in
> > switch_cr3_cr4, as it's not clear whether code could rely on
> > switch_cr3_cr4 also performing a guest linear TLB flush. A following
> > patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to
> > not be necessary.
> > 
> > Signed-off-by: Roger Pau Monn� <roger.pau@citrix.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 

Tim, ICYMI, this patch needs your ack.

Wei.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 10:15:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 10:15:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT0n8-0008MT-I9; Mon, 27 Apr 2020 10:15:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Fhyl=6L=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jT0n6-0008MO-W0
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 10:15:09 +0000
X-Inumbo-ID: f6cc111b-886f-11ea-9752-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f6cc111b-886f-11ea-9752-12813bfff9fa;
 Mon, 27 Apr 2020 10:15:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=vb/isXTPmI5esXbhkTiYfHZ3Ej80IyiyEFLunqYZLPQ=; b=o3O7eZ5bmzmhkg8i2eJ3y0qEKR
 +cs77r+4+Fm/oBa1K5oHpur6SvJK4sDIkMRypF80zFXiRL5mP+hSjwdyaqXjuz5QeI329jk3LqQ6F
 wWMPCVcTu5D60mFVm2KGOn1YzV945xxFhGiqU/GlHNppwSLO97Glbsq54AmCmvcYdLUI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jT0n0-0003ks-RN; Mon, 27 Apr 2020 10:15:02 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jT0n0-0005Lt-Hg; Mon, 27 Apr 2020 10:15:02 +0000
Date: Mon, 27 Apr 2020 11:14:59 +0100
From: Wei Liu <wl@xen.org>
To: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Subject: Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
Message-ID: <20200427101459.elteymh3qugnh5na@debian>
References: <6d63f89124c7445be3185ab6722992b707dab72b.1586186121.git.tamas.lengyel@intel.com>
 <20200409154243.6ouh7r37fwm32mjg@debian>
 <CABfawhndtUA3hVyq9ObbuGRJOVg84qxPgEpc-HsEMxn7A7j_jA@mail.gmail.com>
 <20200409162159.cb2h7a6tmkbaduay@debian>
 <CABfawhnaDS=nGn3+NqoY_nWXvu0cfsAmpYjiv9VqkT6C0Ow1FA@mail.gmail.com>
 <20200409171113.cajvhjlftadqqq73@debian>
 <CABfawhmdSdC2kKzE5jLLCtkR9Pb4mcT6iRdzv0s=v0mQiju_Kg@mail.gmail.com>
 <CABfawhnw2O6GPXEwk0-vAkAVpwn95F-pcpahOpQUo23Luz7eFg@mail.gmail.com>
 <20200410161906.tjonj2btem5nqkpp@debian>
 <CABfawhn2=-WiEyT--Z-h-mYBSc2uwU8X7VGaTmc6GRzOAEXzLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABfawhn2=-WiEyT--Z-h-mYBSc2uwU8X7VGaTmc6GRzOAEXzLQ@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>,
 Tamas K Lengyel <tamas.lengyel@intel.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 10, 2020 at 10:20:49AM -0600, Tamas K Lengyel wrote:
> On Fri, Apr 10, 2020 at 10:19 AM Wei Liu <wl@xen.org> wrote:
> >
> > On Fri, Apr 10, 2020 at 10:05:50AM -0600, Tamas K Lengyel wrote:
> > > On Thu, Apr 9, 2020 at 11:30 AM Tamas K Lengyel
> > > <tamas.k.lengyel@gmail.com> wrote:
> > > >
> > > > On Thu, Apr 9, 2020 at 11:11 AM Wei Liu <wl@xen.org> wrote:
> > > > >
> > > > > On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> > > > > [...]
> > > > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > +/*
> > > > > > > > > > + * The parent domain is expected to be created with default settings for
> > > > > > > > > > + * - max_evtch_port
> > > > > > > > > > + * - max_grant_frames
> > > > > > > > > > + * - max_maptrack_frames
> > > > > > > > > > + */
> > > > > > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus, uint32_t *domid)
> > > > > > > > > > +{
> > > > > > > > > > +    int rc;
> > > > > > > > > > +    struct xen_domctl_createdomain create = {0};
> > > > > > > > > > +    create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > > > > > +    create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > > > > > +    create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > > > > > +    create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > > > > > > > > +    create.ssidref = SECINITSID_DOMU;
> > > > > > > > > > +    create.max_vcpus = max_vcpus;
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Some questions:
> > > > > > > > >
> > > > > > > > > Why does the caller need to specify the number of vcpus?
> > > > > > > > >
> > > > > > > > > Since the parent (source) domain is around, can you retrieve its domain
> > > > > > > > > configuration such that you know its max_vcpus and other information
> > > > > > > > > including max_evtchn_port and maptrack frames?
> > > > > > > >
> > > > > > > > Because we want to avoid having to issue an extra hypercall for these.
> > > > > > > > Normally these pieces of information will be available for the user
> > > > > > > > and won't change, so we save time by not querying for it every time a
> > > > > > > > fork is created. Remember, we might be creating thousands of forks in
> > > > > > > > a very short time, so those extra hypercalls add up.
> > > > > > >
> > > > > > > I see. Speed is a big concern to you.
> > > > > > >
> > > > > > > What I was referring to doesn't require issuing hypercalls but requires
> > > > > > > calling libxl_retrieve_domain_configuration. That's likely to be even
> > > > > > > slower than making a hypercall.
> > > > > >
> > > > > > Right. We only want to parse the domain config if the device model is
> > > > > > being launched.
> > > > > >
> > > > > > >
> > > > > > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> > > > > > > supported (as in Xen's support statement) going forward, because it is
> > > > > > > leaky.
> > > > > >
> > > > > > What do you mean by leaky?
> > > > >
> > > > > It requires the caller to specify the number of max_vcpus. The reason
> > > > > for doing that is because you want to avoid extra hypercall(s). There is
> > > > > nothing that stops someone from coming along in the future claiming some
> > > > > other parameters are required because of the same concern you have
> > > > > today. It is an optimisation, not a must-have in terms of functionality.
> > > > >
> > > > > To me the number shouldn't be specified by the caller in the first
> > > > > place. It is like forking a process somehow requires you to specify how
> > > > > many threads it will have.
> > > >
> > > > I agree. It's not how I wanted to have the interface work but
> > > > unfortunately this was the least "ugly" of the possible solutions
> > > > given the circumstances.
> > >
> > > By the way, it would be trivial to query the parent in case max_vcpus
> > > is not provided by the user. But I would still like to keep the option
> > > available to skip that step if the number is known already. Let me
> > > know if you would like me to add that.
> >
> > I'm still waiting for Ian and Anthony to chime in to see whether they
> > agree to keep this interface unstable.
> >
> > At the end of the day, if it is unstable, I don't really care that much.
> > I'm happy to let you (the developer and user) have more say in that
> > case.  I will instead divert my (limited) time to code that your patch
> > touches which is also used by other stable functions.
> 
> SGTM

Ian and Anthony, your opinions?

Wei.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 10:33:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 10:33:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT14R-0001h7-4L; Mon, 27 Apr 2020 10:33:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jrem=6L=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jT14P-0001h2-F3
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 10:33:01 +0000
X-Inumbo-ID: 776ffe1a-8872-11ea-ae69-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 776ffe1a-8872-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 10:33:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587983580;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=vYnkF0mZ7/2AyhwHdflxwXuELDdcHc50UWwOclnYv28=;
 b=RCcOWayZ4pF3J+7/mLUP09kBN74xg+i664B+tb9z6hQ11zTyGnoqmwLa
 Ahq1LHxDs0RlROYohaWNSH0iL0c5gqD/gc0JqKNJSBoBRnJKOJmkLU34a
 9+sQrAEznwIIRg/KzX+lZ9UT2zz8Nf2S6NgtL4FZnr2MtX3XE/Hjh5jYq k=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: gqCE6zVTPsc3jCY3aTD9CgysNlsbxYQWFAg5MYacmEFT3nuTtM0eOowMZP9Et1ondLIWFWSYta
 9hmbkcrAs28IBxUDY1ITUr/r1Vgr2MZv7bdgi1hVJg3hS3iVlgwxiQi5An9vyTku8gRWNPdkAh
 T/cHPb2nN17XEFaHaL/USfApmeCNS44aN3wQkQ/GdR1KoL2SzzHOrjWGnFUh9/tXvl+UPgCQm7
 qqyvicH+4TRNH4B2ycAKBTcGFCN6bdDjoAnZ3TKC3GCP1jA+BI6QZCMiC7Em3UxCdQQSD+IHr/
 ec4=
X-SBRS: 2.7
X-MesageID: 16977722
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,323,1583211600"; d="scan'208";a="16977722"
Date: Mon, 27 Apr 2020 12:32:52 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tim Deegan <tim@xen.org>
Subject: Re: [PATCH v11 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200427103252.GO28601@Air-de-Roger>
References: <20200423145611.55378-1-roger.pau@citrix.com>
 <20200423145611.55378-2-roger.pau@citrix.com>
 <59e48d80-8ce1-3f3d-c07e-5117adea272a@suse.com>
 <20200427101235.6xko3lvt3qajo64m@debian>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200427101235.6xko3lvt3qajo64m@debian>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Wei Liu <wl@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 11:12:35AM +0100, Wei Liu wrote:
> On Thu, Apr 23, 2020 at 06:33:49PM +0200, Jan Beulich wrote:
> > On 23.04.2020 16:56, Roger Pau Monne wrote:
> > > Introduce a specific flag to request a HVM guest linear TLB flush,
> > > which is an ASID/VPID tickle that forces a guest linear to guest
> > > physical TLB flush for all HVM guests.
> > > 
> > > This was previously unconditionally done in each pre_flush call, but
> > > that's not required: HVM guests not using shadow don't require linear
> > > TLB flushes as Xen doesn't modify the pages tables the guest runs on
> > > in that case (ie: when using HAP). Note that shadow paging code
> > > already takes care of issuing the necessary flushes when the shadow
> > > page tables are modified.
> > > 
> > > In order to keep the previous behavior modify all shadow code TLB
> > > flushes to also flush the guest linear to physical TLB if the guest is
> > > HVM. I haven't looked at each specific shadow code TLB flush in order
> > > to figure out whether it actually requires a guest TLB flush or not,
> > > so there might be room for improvement in that regard.
> > > 
> > > Also perform ASID/VPID flushes when modifying the p2m tables as it's a
> > > requirement for AMD hardware. Finally keep the flush in
> > > switch_cr3_cr4, as it's not clear whether code could rely on
> > > switch_cr3_cr4 also performing a guest linear TLB flush. A following
> > > patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to
> > > not be necessary.
> > > 
> > > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > 
> > Reviewed-by: Jan Beulich <jbeulich@suse.com>
> > 
> 
> Tim, ICYMI, this patch needs your ack.

Let me put Tim on the To: field, more likely to raise attention.

Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 10:36:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 10:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT17u-0001pC-KY; Mon, 27 Apr 2020 10:36:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=5iRA=6L=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jT17t-0001p7-BL
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 10:36:37 +0000
X-Inumbo-ID: f7901602-8872-11ea-9756-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f7901602-8872-11ea-9756-12813bfff9fa;
 Mon, 27 Apr 2020 10:36:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id ABE8EAC5B;
 Mon, 27 Apr 2020 10:36:33 +0000 (UTC)
Subject: Re: [PATCH v2] docs/designs: re-work the xenstore migration
 document...
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200427075342.149-1-paul@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <6004fb95-42e1-1ee3-5215-0d0dede73f0f@suse.com>
Date: Mon, 27 Apr 2020 12:36:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200427075342.149-1-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.20 09:53, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
> 
> ... to specify a separate migration stream that will also be suitable for
> live update.
> 
> The original scope of the document was to support non-cooperative migration
> of guests [1] but, since then, live update of xenstored has been brought into
> scope. Thus it makes more sense to define a separate image format for
> serializing xenstore state that is suitable for both purposes.
> 
> The document has been limited to specifying a new image format. The mechanism
> for acquiring the image for live update or migration is not covered as that
> is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
> also expected that, when the first implementation of live update or migration
> making use of this specification is committed, that the document is moved from
> docs/designs into docs/specs.
> 
> [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> ---
> Juergen Gross <jgross@suse.com>
> Andrew Cooper <andrew.cooper3@citrix.com>
> George Dunlap <george.dunlap@citrix.com>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Jan Beulich <jbeulich@suse.com>
> Julien Grall <julien@xen.org>
> Stefano Stabellini <sstabellini@kernel.org>
> Wei Liu <wl@xen.org>

Mind adding CC: before those mail addresses in order to let git add
those to the recipients list?

> 
> v2:
>   - Address comments from Juergen

Not all unfortunately. :-(

> +### CONNECTION_DATA
>   
> -Each WATCH_DATA record specifies a registered watch and is formatted as
> -follows:
> +For live update the image format will contain a `CONNECTION_DATA` record for
> +each connection to xenstore. For migration it will only contain a record for
> +the domain being migrated.
>   
>   
>   ```
> -    0       1       2       3     octet
> -+-------+-------+-------+-------+
> -| WATCH_DATA                    |
> -+-------------------------------+
> -| wpath length                  |
> -+-------------------------------+
> -| wpath data                    |
> -...
> -| pad (0 to 3 octets)           |
> -+-------------------------------+
> +    0       1       2       3       4       5       6       7    octet
> ++-------+-------+-------+-------+-------+-------+-------+-------+
> +| conn-id                       | pad                           |
> ++---------------+-----------------------------------------------+
> +| conn-type     | conn-spec
>   ...

I asked whether it wouldn't be better to drop the pad and move conn-type
and a 2-byte (unified) flag field at its position. This together ...

> ++-------------------------------+-------------------------------+
> +| data-len                      | data
>   +-------------------------------+
> -| token length                  |
> -+-------------------------------+
> -| token data                    |
>   ...
> -| pad (0 to 3 octets)           |
> -+-------------------------------+
>   ```
>   
> -wpath length and token length are specified in octets (excluding the NUL
> -terminator). The wpath should be as described for the `WATCH` operation in
> -[2]. The token is an arbitrary string of octets not containing any NUL
> -values.
>   
> +| Field       | Description                                     |
> +|-------------|-------------------------------------------------|
> +| `conn-id`   | A non-zero number used to identify this         |
> +|             | connection in subsequent connection-specific    |
> +|             | records                                         |
> +|             |                                                 |
> +| `conn-type` | 0x0000: shared ring                             |
> +|             | 0x0001: socket                                  |
> +|             |                                                 |
> +| `conn-spec` | See below                                       |
> +|             |                                                 |
> +| `data-len`  | The length (in octets) of any pending data not  |
> +|             | yet written to the connection                   |
> +|             |                                                 |
> +| `data`      | Pending data (may be empty)                     |
>   
> -**TRANSACTION_DATA**
> +The format of `conn-spec` is dependent upon `conn-type`.
>   
> +\pagebreak
>   
> -Each TRANSACTION_DATA record specifies an open transaction and is formatted
> -as follows:
> +For `shared ring` connections it is as follows:
>   
>   
>   ```
> -    0       1       2       3     octet
> -+-------+-------+-------+-------+
> -| TRANSACTION_DATA              |
> -+-------------------------------+
> -| tx_id                         |
> -+-------------------------------+
> +    0       1       2       3       4       5       6       7    octet
> +                +-------+-------+-------+-------+-------+-------+
> +                | domid         | tdomid        | flags         |
> ++---------------+---------------+---------------+---------------+
> +| revtchn                       | levtchn                       |
> ++-------------------------------+-------------------------------+
> +| mfn                                                           |
> ++---------------------------------------------------------------+

... with dropping levtchn (which isn't needed IMO) will make it much
easier to have a union in C (which needs to be aligned to 8 bytes
and have a length of a multiple of 8 bytes due to mfn).

So something like:

struct xs_state_connection {
     uint32_t conn_id;
     uint16_t conn_type;
#define XS_STATE_CONN_TYPE_RING   0
#define XS_STATE_CONN_TYPE_SOCKET 1
     uint16_t flags;
#define XS_STATE_CONN_INTRODUCED  0x0001
#define XS_STATE_CONN_RELEASED    0x0002
#define XS_STATE_CONN_READONLY    0x0004
     union {
         struct {
             uint16_t domid;
             uint16_t tdomid;
#define XS_STATE_DOMID_INVALID  0xffffU
             uint32_t evtchn;
             uint64_t mfn;
#define XS_STATE_MFN_INVALID    0xffffffffffffffffUL
         } ring;
         int32_t socket_fd;
     } spec;
     uint32_t data_out_len;
     uint8_t  data[];
};

>   ```
>   
> -where tx_id is the non-zero identifier values of an open transaction.
> -
>   
> -### Protocol Extension
> +| Field      | Description                                      |
> +|------------|--------------------------------------------------|
> +| `domid`    | The domain-id that owns the shared page          |
> +|            |                                                  |
> +| `tdomid`   | The domain-id that `domid` acts on behalf of if  |
> +|            | it has been subject to an SET_TARGET             |
> +|            | operation [2] or DOMID_INVALID otherwise         |

DOMID_INVALID needs to be defined (or we need a reference where it is
coming from).

> +|            |                                                  |
> +| `flags`    | A bit-wise OR of:                                |
> +|            | 0x0001: INTRODUCE has been issued                |
> +|            | 0x0002: RELEASE has been issued                  |
> +|            |                                                  |
> +| `revtchn`  | The port number of the interdomain channel used  |
> +|            | by `domid` to communicate with xenstored         |
> +|            |                                                  |
> +| `levtchn`  | For a live update this will be the port number   |
> +|            | of the interdomain channel used by xenstored     |
> +|            | itself otherwise, for migration, it will be -1   |
> +|            |                                                  |
> +| `mfn`      | The MFN of the shared page for a live update or  |
> +|            | INVALID_MFN otherwise                            |

INVALID_MFN is an internal detail of the hypervisor. We should have a
local definition for it here (as in my example above).

> +
> +Since the ABI guarantees that entry 1 in `domid`'s grant table will always
> +contain the GFN of the shared page, so for a live update `mfn` can be used to
> +give confidence that `domid` has not been re-cycled during the update.
> +
> +
> +For `socket` connections it is as follows:
>   
> -Before xenstore state is migrated it is necessary to wait for any pending
> -reads, writes, watch registrations etc. to complete, and also to make sure
> -that xenstored does not start processing any new requests (so that new
> -requests remain pending on the shared ring for subsequent processing on the
> -new host). Hence the following operation is needed:
>   
>   ```
> -QUIESCE                 <domid>|
> -
> -Complete processing of any request issued by the specified domain, and
> -do not process any further requests from the shared ring.
> +    0       1       2       3       4       5       6       7    octet
> +                +-------+-------+-------+-------+-------+-------+
> +                | flags         | socket-fd                     |
> +                +---------------+-------------------------------+

> -START_DOMAIN_TRANSACTION    <domid>|<transid>|
> +    0       1       2       3    octet
> ++-------+-------+-------+-------+
> +| conn-id                       |
> ++-------------------------------+
> +| tx-id                         |
> ++---------------+---------------+
> +| access        | perm-count    |
> ++---------------+---------------+
> +| perm1                         |
> ++-------------------------------+
> +...
> ++-------------------------------+
> +| permN                         |
> ++---------------+---------------+
> +| path-len      | value-len     |
> ++---------------+---------------+
> +| path
> +...
> +| value
> +...
> +```
> +
> +
> +| Field        | Description                                    |
> +|--------------|------------------------------------------------|
> +| `conn-id`    | If this value is non-zero then this record     |
> +|              | related to a pending transaction               |
> +|              |                                                |
> +| `tx-id`      | This value should be ignored if `conn-id` is   |
> +|              | zero. Otherwise it specifies the id of the     |
> +|              | pending transaction                            |
> +|              |                                                |
> +| `access`     | This value should be ignored if this record    |
> +|              | does not relate to a pending transaction,      |
> +|              | otherwise it specifies the accesses made to    |
> +|              | the node and hence is a bitwise OR of:         |
> +|              |                                                |
> +|              | 0x0001: read                                   |
> +|              | 0x0002: written                                |
> +|              |                                                |
> +|              | The value will be zero for a deleted node      |
> +|              |                                                |
> +| `perm-count` | The number (N) of node permission specifiers   |
> +|              | (which will be 0 for a node deleted in a       |
> +|              | pending transaction)                           |
> +|              |                                                |
> +| `perm1..N`   | A list of zero or more node permission         |
> +|              | specifiers (see below)                         |
> +|              |                                                |
> +| `path-len`   | The length (in octets) of `path` including the |
> +|              | NUL terminator                                 |
> +|              |                                                |
> +| `value-len`  | The length (in octets) of `value` (which will  |
> +|              | be zero for a deleted node)                    |

I asked you to put the path-len and value-len fields before the perm
array.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 10:45:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 10:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1Gf-0002kf-HO; Mon, 27 Apr 2020 10:45:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wbbE=6L=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jT1Gf-0002ka-0s
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 10:45:41 +0000
X-Inumbo-ID: 3bfaa248-8874-11ea-9887-bc764e2007e4
Received: from mail-wr1-x432.google.com (unknown [2a00:1450:4864:20::432])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3bfaa248-8874-11ea-9887-bc764e2007e4;
 Mon, 27 Apr 2020 10:45:39 +0000 (UTC)
Received: by mail-wr1-x432.google.com with SMTP id i10so19940272wrv.10
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 03:45:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=WEVE4TsyCLep1MWm1ZY6XVXdPklSUFZrElyYlI+g/3I=;
 b=p2RqmUmMnaaLc5fxGjcCGeWEXzgPOj/kng4/8rDUWPU+pBGnOh5XmNxFPI3Ea9LNfu
 pc6cjIlIpti3G3PPXvdUOlird+saqjkIRox40lS+OI8zNQgsh7+9gntrpnlC7k1H6ySX
 HNDHGYEaqYkFxlHiy1Zv4ecr8uBM/cNBqIIMnSpDmtAag5fo/lfC9oxPEVKtSv9HNs24
 SvqT45QoKVd8O4SurzZP42Rk9akOz3g0kyTT+XNVYxVAY68WO10J5CVc5BTF553MaWRC
 LA7gt7Hgcx5Zue2ozOS4mOl+gNEPHVg5pZDYoiDtOYTVi3+fRka0mRpMsHg8zHhnFYAN
 BWlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=WEVE4TsyCLep1MWm1ZY6XVXdPklSUFZrElyYlI+g/3I=;
 b=VsPSf0sWGXx40+0BHc+p10hFsIvlo0wMAiseCrput86NxzxYt62vYFaDhLRL0yrNYN
 SjeoJQ++g04ETdQSESHuX6N4QyrP08tOz430QbgWBhSygKc+tSqgm9jLip1P8yzf/apn
 w7zZkzMkTuO5Vm8yrebTURJZvXYYdwc3t5ElhdpwVdFXPMHH+05i00+XxMuiAqRDAibR
 2PhdZv2fGI8T0JBSrWQSLqPCJCUNI22wXq94iH/m9n0gc1H2PpPh6+IKgZ9jaS2AaKSZ
 Jqrr2zsfhF2eCSffs5HYZNI8xYRj2f7dbZMnCUQLbLi09OqOBG/dABzUDoCDKaANerVj
 Gjhw==
X-Gm-Message-State: AGi0PuZHG9EL9hGxdyeueDrltwgyGSN9hzTB0z0GBXE/QeZzgsicGaZV
 U1XS7uI/zF+2DW5nO8L6M94=
X-Google-Smtp-Source: APiQypK4qM0dGaDEnak8dZq802PD7W7ZgLWqNHVmZYS3kZQ5Y69KoSU1ADQNdAvPRi5OrwuGQ8DY+g==
X-Received: by 2002:a5d:5304:: with SMTP id e4mr25278919wrv.87.1587984338817; 
 Mon, 27 Apr 2020 03:45:38 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id f63sm14956356wma.47.2020.04.27.03.45.37
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 27 Apr 2020 03:45:38 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= <jgross@suse.com>,
 <xen-devel@lists.xenproject.org>
References: <20200427075342.149-1-paul@xen.org>
 <6004fb95-42e1-1ee3-5215-0d0dede73f0f@suse.com>
In-Reply-To: <6004fb95-42e1-1ee3-5215-0d0dede73f0f@suse.com>
Subject: RE: [PATCH v2] docs/designs: re-work the xenstore migration
 document...
Date: Mon, 27 Apr 2020 11:45:37 +0100
Message-ID: <000a01d61c80$fd1e47a0$f75ad6e0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJEJDb5RQM5hDvWa+75ajX7plb9lwK+35WRp5rBKeA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Paul Durrant' <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>
> Sent: 27 April 2020 11:37
> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Paul Durrant <pdurrant@amazon.com>
> Subject: Re: [PATCH v2] docs/designs: re-work the xenstore migration =
document...
>=20
> On 27.04.20 09:53, Paul Durrant wrote:
> > From: Paul Durrant <pdurrant@amazon.com>
> >
> > ... to specify a separate migration stream that will also be =
suitable for
> > live update.
> >
> > The original scope of the document was to support non-cooperative =
migration
> > of guests [1] but, since then, live update of xenstored has been =
brought into
> > scope. Thus it makes more sense to define a separate image format =
for
> > serializing xenstore state that is suitable for both purposes.
> >
> > The document has been limited to specifying a new image format. The =
mechanism
> > for acquiring the image for live update or migration is not covered =
as that
> > is more appropriately dealt with by a patch to =
docs/misc/xenstore.txt. It is
> > also expected that, when the first implementation of live update or =
migration
> > making use of this specification is committed, that the document is =
moved from
> > docs/designs into docs/specs.
> >
> > [1] See =
https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Ddocs/designs/non=
-cooperative-migration.md
> >
> > Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> > ---
> > Juergen Gross <jgross@suse.com>
> > Andrew Cooper <andrew.cooper3@citrix.com>
> > George Dunlap <george.dunlap@citrix.com>
> > Ian Jackson <ian.jackson@eu.citrix.com>
> > Jan Beulich <jbeulich@suse.com>
> > Julien Grall <julien@xen.org>
> > Stefano Stabellini <sstabellini@kernel.org>
> > Wei Liu <wl@xen.org>
>=20
> Mind adding CC: before those mail addresses in order to let git add
> those to the recipients list?
>=20

D'oh... good spot.

> >
> > v2:
> >   - Address comments from Juergen
>=20
> Not all unfortunately. :-(
>=20

OK.

> > +### CONNECTION_DATA
> >
> > -Each WATCH_DATA record specifies a registered watch and is =
formatted as
> > -follows:
> > +For live update the image format will contain a `CONNECTION_DATA` =
record for
> > +each connection to xenstore. For migration it will only contain a =
record for
> > +the domain being migrated.
> >
> >
> >   ```
> > -    0       1       2       3     octet
> > -+-------+-------+-------+-------+
> > -| WATCH_DATA                    |
> > -+-------------------------------+
> > -| wpath length                  |
> > -+-------------------------------+
> > -| wpath data                    |
> > -...
> > -| pad (0 to 3 octets)           |
> > -+-------------------------------+
> > +    0       1       2       3       4       5       6       7    =
octet
> > ++-------+-------+-------+-------+-------+-------+-------+-------+
> > +| conn-id                       | pad                           |
> > ++---------------+-----------------------------------------------+
> > +| conn-type     | conn-spec
> >   ...
>=20
> I asked whether it wouldn't be better to drop the pad and move =
conn-type
> and a 2-byte (unified) flag field at its position. This together ...
>=20
> > ++-------------------------------+-------------------------------+
> > +| data-len                      | data
> >   +-------------------------------+
> > -| token length                  |
> > -+-------------------------------+
> > -| token data                    |
> >   ...
> > -| pad (0 to 3 octets)           |
> > -+-------------------------------+
> >   ```
> >
> > -wpath length and token length are specified in octets (excluding =
the NUL
> > -terminator). The wpath should be as described for the `WATCH` =
operation in
> > -[2]. The token is an arbitrary string of octets not containing any =
NUL
> > -values.
> >
> > +| Field       | Description                                     |
> > +|-------------|-------------------------------------------------|
> > +| `conn-id`   | A non-zero number used to identify this         |
> > +|             | connection in subsequent connection-specific    |
> > +|             | records                                         |
> > +|             |                                                 |
> > +| `conn-type` | 0x0000: shared ring                             |
> > +|             | 0x0001: socket                                  |
> > +|             |                                                 |
> > +| `conn-spec` | See below                                       |
> > +|             |                                                 |
> > +| `data-len`  | The length (in octets) of any pending data not  |
> > +|             | yet written to the connection                   |
> > +|             |                                                 |
> > +| `data`      | Pending data (may be empty)                     |
> >
> > -**TRANSACTION_DATA**
> > +The format of `conn-spec` is dependent upon `conn-type`.
> >
> > +\pagebreak
> >
> > -Each TRANSACTION_DATA record specifies an open transaction and is =
formatted
> > -as follows:
> > +For `shared ring` connections it is as follows:
> >
> >
> >   ```
> > -    0       1       2       3     octet
> > -+-------+-------+-------+-------+
> > -| TRANSACTION_DATA              |
> > -+-------------------------------+
> > -| tx_id                         |
> > -+-------------------------------+
> > +    0       1       2       3       4       5       6       7    =
octet
> > +                +-------+-------+-------+-------+-------+-------+
> > +                | domid         | tdomid        | flags         |
> > ++---------------+---------------+---------------+---------------+
> > +| revtchn                       | levtchn                       |
> > ++-------------------------------+-------------------------------+
> > +| mfn                                                           |
> > ++---------------------------------------------------------------+
>=20
> ... with dropping levtchn (which isn't needed IMO) will make it much
> easier to have a union in C (which needs to be aligned to 8 bytes
> and have a length of a multiple of 8 bytes due to mfn).
>=20
> So something like:
>=20
> struct xs_state_connection {
>      uint32_t conn_id;
>      uint16_t conn_type;
> #define XS_STATE_CONN_TYPE_RING   0
> #define XS_STATE_CONN_TYPE_SOCKET 1
>      uint16_t flags;
> #define XS_STATE_CONN_INTRODUCED  0x0001
> #define XS_STATE_CONN_RELEASED    0x0002
> #define XS_STATE_CONN_READONLY    0x0004
>      union {
>          struct {
>              uint16_t domid;
>              uint16_t tdomid;
> #define XS_STATE_DOMID_INVALID  0xffffU
>              uint32_t evtchn;
>              uint64_t mfn;
> #define XS_STATE_MFN_INVALID    0xffffffffffffffffUL
>          } ring;
>          int32_t socket_fd;
>      } spec;
>      uint32_t data_out_len;
>      uint8_t  data[];
> };

The issue is making sure that the mfn is properly aligned. If I can drop =
the levtchn then this gets easier.

>=20
> >   ```
> >
> > -where tx_id is the non-zero identifier values of an open =
transaction.
> > -
> >
> > -### Protocol Extension
> > +| Field      | Description                                      |
> > +|------------|--------------------------------------------------|
> > +| `domid`    | The domain-id that owns the shared page          |
> > +|            |                                                  |
> > +| `tdomid`   | The domain-id that `domid` acts on behalf of if  |
> > +|            | it has been subject to an SET_TARGET             |
> > +|            | operation [2] or DOMID_INVALID otherwise         |
>=20
> DOMID_INVALID needs to be defined (or we need a reference where it is
> coming from).

OK. It's in a public header... I'll reference it.

>=20
> > +|            |                                                  |
> > +| `flags`    | A bit-wise OR of:                                |
> > +|            | 0x0001: INTRODUCE has been issued                |
> > +|            | 0x0002: RELEASE has been issued                  |
> > +|            |                                                  |
> > +| `revtchn`  | The port number of the interdomain channel used  |
> > +|            | by `domid` to communicate with xenstored         |
> > +|            |                                                  |
> > +| `levtchn`  | For a live update this will be the port number   |
> > +|            | of the interdomain channel used by xenstored     |
> > +|            | itself otherwise, for migration, it will be -1   |
> > +|            |                                                  |
> > +| `mfn`      | The MFN of the shared page for a live update or  |
> > +|            | INVALID_MFN otherwise                            |
>=20
> INVALID_MFN is an internal detail of the hypervisor. We should have a
> local definition for it here (as in my example above).

OK. I'll define it as all-1s.

>=20
> > +
> > +Since the ABI guarantees that entry 1 in `domid`'s grant table will =
always
> > +contain the GFN of the shared page, so for a live update `mfn` can =
be used to
> > +give confidence that `domid` has not been re-cycled during the =
update.
> > +
> > +
> > +For `socket` connections it is as follows:
> >
> > -Before xenstore state is migrated it is necessary to wait for any =
pending
> > -reads, writes, watch registrations etc. to complete, and also to =
make sure
> > -that xenstored does not start processing any new requests (so that =
new
> > -requests remain pending on the shared ring for subsequent =
processing on the
> > -new host). Hence the following operation is needed:
> >
> >   ```
> > -QUIESCE                 <domid>|
> > -
> > -Complete processing of any request issued by the specified domain, =
and
> > -do not process any further requests from the shared ring.
> > +    0       1       2       3       4       5       6       7    =
octet
> > +                +-------+-------+-------+-------+-------+-------+
> > +                | flags         | socket-fd                     |
> > +                +---------------+-------------------------------+
>=20
> > -START_DOMAIN_TRANSACTION    <domid>|<transid>|
> > +    0       1       2       3    octet
> > ++-------+-------+-------+-------+
> > +| conn-id                       |
> > ++-------------------------------+
> > +| tx-id                         |
> > ++---------------+---------------+
> > +| access        | perm-count    |
> > ++---------------+---------------+
> > +| perm1                         |
> > ++-------------------------------+
> > +...
> > ++-------------------------------+
> > +| permN                         |
> > ++---------------+---------------+
> > +| path-len      | value-len     |
> > ++---------------+---------------+
> > +| path
> > +...
> > +| value
> > +...
> > +```
> > +
> > +
> > +| Field        | Description                                    |
> > +|--------------|------------------------------------------------|
> > +| `conn-id`    | If this value is non-zero then this record     |
> > +|              | related to a pending transaction               |
> > +|              |                                                |
> > +| `tx-id`      | This value should be ignored if `conn-id` is   |
> > +|              | zero. Otherwise it specifies the id of the     |
> > +|              | pending transaction                            |
> > +|              |                                                |
> > +| `access`     | This value should be ignored if this record    |
> > +|              | does not relate to a pending transaction,      |
> > +|              | otherwise it specifies the accesses made to    |
> > +|              | the node and hence is a bitwise OR of:         |
> > +|              |                                                |
> > +|              | 0x0001: read                                   |
> > +|              | 0x0002: written                                |
> > +|              |                                                |
> > +|              | The value will be zero for a deleted node      |
> > +|              |                                                |
> > +| `perm-count` | The number (N) of node permission specifiers   |
> > +|              | (which will be 0 for a node deleted in a       |
> > +|              | pending transaction)                           |
> > +|              |                                                |
> > +| `perm1..N`   | A list of zero or more node permission         |
> > +|              | specifiers (see below)                         |
> > +|              |                                                |
> > +| `path-len`   | The length (in octets) of `path` including the |
> > +|              | NUL terminator                                 |
> > +|              |                                                |
> > +| `value-len`  | The length (in octets) of `value` (which will  |
> > +|              | be zero for a deleted node)                    |
>=20
> I asked you to put the path-len and value-len fields before the perm
> array.

I missed that. I'll move them.

  Paul

>=20
>=20
> Juergen



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 10:53:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 10:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1NZ-0003dc-CZ; Mon, 27 Apr 2020 10:52:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6V0E=6L=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jT1NY-0003dX-LZ
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 10:52:48 +0000
X-Inumbo-ID: 37ece016-8875-11ea-9758-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 37ece016-8875-11ea-9758-12813bfff9fa;
 Mon, 27 Apr 2020 10:52:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=lg9MJ8l9YCrn1BvqxZTpLfb8Xa/Ubs1KJSy1fUYgk9E=; b=IJbz9TI6TgLEI+hv3WaHhpAYR
 mcunAG8YcFrdLbhKTvsALJh5fOQKIF1S8Q35+Fdfuc0IG+yfRy6ZKmvdSODGFwHlVMptpezQTSVG2
 CTPZLY7bdB+s3d/BFpftmYcCdJNuThBq9AqMH680bOvMTi1Ys5SFdFwBYO8svC/V6PRSk=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jT1NR-0004Wb-PA; Mon, 27 Apr 2020 10:52:41 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jT1NR-00076i-CX; Mon, 27 Apr 2020 10:52:41 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jT1NR-0004X2-Bs; Mon, 27 Apr 2020 10:52:41 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149834-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149834: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=8d4c17a90b0a9b3d82628461090a54a2c7897154
X-Osstest-Versions-That: xen=f093b08c47b39da6019421a2b61d40745b3e573b
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 27 Apr 2020 10:52:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149834 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149834/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  8d4c17a90b0a9b3d82628461090a54a2c7897154
baseline version:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b

Last test of basis   149822  2020-04-25 18:00:23 Z    1 days
Testing same since   149834  2020-04-27 08:01:51 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Stefano Stabellini <sstabellini@kernel.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f093b08c47..8d4c17a90b  8d4c17a90b0a9b3d82628461090a54a2c7897154 -> smoke


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:09:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1dF-0004jp-Sa; Mon, 27 Apr 2020 11:09:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1dE-0004jk-MK
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:09:00 +0000
X-Inumbo-ID: 7e17c2b6-8877-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7e17c2b6-8877-11ea-9887-bc764e2007e4;
 Mon, 27 Apr 2020 11:08:59 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 36FCFAC5F;
 Mon, 27 Apr 2020 11:08:57 +0000 (UTC)
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v7 00/11] x86emul: further work
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Message-ID: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Date: Mon, 27 Apr 2020 13:08:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

At least the RDPRU patches is still at least partly RFC. I'd
appreciate though if at least some of the series could go in
rather sooner than later. Note in particular that there's no
strong ordering throughout the entire series, i.e. certain
later parts could be arranged for to go in earlier. This is
also specifically the case for what is now the last patch.

 1: x86emul: disable FPU/MMX/SIMD insn emulation when !HVM
 2: x86emul: support MOVDIR{I,64B} insns
 3: x86emul: support ENQCMD insn
 4: x86emul: support SERIALIZE
 5: x86emul: support X{SUS,RES}LDTRK
 6: x86emul: support FNSTENV and FNSAVE
 7: x86emul: support FLDENV and FRSTOR
 8: x86emul: support FXSAVE/FXRSTOR
 9: x86/HVM: scale MPERF values reported to guests (on AMD)
10: x86emul: support RDPRU
11: x86/HVM: don't needlessly intercept APERF/MPERF/TSC MSR reads

Main changes from v6 are, besides three new patches and some
re-ordering, the integration into this series of what is now
patch 1 (for later patches now depending even more heavily on
it), and the dropping (for the time being) of the MCOMMIT one.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:11:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1fl-0005WR-AH; Mon, 27 Apr 2020 11:11:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1fk-0005WH-3c
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:11:36 +0000
X-Inumbo-ID: daa307c0-8877-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id daa307c0-8877-11ea-b07b-bc764e2007e4;
 Mon, 27 Apr 2020 11:11:34 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B3A2DABE2;
 Mon, 27 Apr 2020 11:11:32 +0000 (UTC)
Subject: [PATCH v7 01/11] x86emul: disable FPU/MMX/SIMD insn emulation when
 !HVM
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <5f02f488-f0b4-8153-7d0c-9a97e8fe093e@suse.com>
Date: Mon, 27 Apr 2020 13:11:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In a pure PV environment (the PV shim in particular) we don't really
need emulation of all these. To limit #ifdef-ary utilize some of the
CASE_*() macros we have, by providing variants expanding to
(effectively) nothing (really a label, which in turn requires passing
-Wno-unused-label to the compiler when build such configurations).

Due to the mixture of macro and #ifdef use, the placement of some of
the #ifdef-s is a little arbitrary.

The resulting object file's .text is less than half the size of the
original, and looks to also be compiling a little more quickly.

This is meant as a first step; more parts can likely be disabled down
the road.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v7: Integrate into this series. Re-base.
---
I'll be happy to take suggestions allowing to avoid -Wno-unused-label.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -73,6 +73,9 @@ obj-y += vm_event.o
 obj-y += xstate.o
 extra-y += asm-macros.i
 
+ifneq ($(CONFIG_HVM),y)
+x86_emulate.o: CFLAGS-y += -Wno-unused-label
+endif
 x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
 
 efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -42,6 +42,12 @@
     }                                                      \
 })
 
+#ifndef CONFIG_HVM
+# define X86EMUL_NO_FPU
+# define X86EMUL_NO_MMX
+# define X86EMUL_NO_SIMD
+#endif
+
 #include "x86_emulate/x86_emulate.c"
 
 int x86emul_read_xcr(unsigned int reg, uint64_t *val,
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3492,6 +3492,7 @@ x86_decode(
             op_bytes = 4;
         break;
 
+#ifndef X86EMUL_NO_SIMD
     case simd_packed_int:
         switch ( vex.pfx )
         {
@@ -3557,6 +3558,7 @@ x86_decode(
     case simd_256:
         op_bytes = 32;
         break;
+#endif /* !X86EMUL_NO_SIMD */
 
     default:
         op_bytes = 0;
@@ -3711,6 +3713,7 @@ x86_emulate(
         break;
     }
 
+#ifndef X86EMUL_NO_SIMD
     /* With a memory operand, fetch the mask register in use (if any). */
     if ( ea.type == OP_MEM && evex.opmsk &&
          _get_fpu(fpu_type = X86EMUL_FPU_opmask, ctxt, ops) == X86EMUL_OKAY )
@@ -3741,6 +3744,7 @@ x86_emulate(
         put_fpu(X86EMUL_FPU_opmask, false, state, ctxt, ops);
         fpu_type = X86EMUL_FPU_none;
     }
+#endif /* !X86EMUL_NO_SIMD */
 
     /* Decode (but don't fetch) the destination operand: register or memory. */
     switch ( d & DstMask )
@@ -4386,11 +4390,13 @@ x86_emulate(
         singlestep = _regs.eflags & X86_EFLAGS_TF;
         break;
 
+#ifndef X86EMUL_NO_FPU
     case 0x9b:  /* wait/fwait */
         host_and_vcpu_must_have(fpu);
         get_fpu(X86EMUL_FPU_wait);
         emulate_fpu_insn_stub(b);
         break;
+#endif
 
     case 0x9c: /* pushf */
         if ( (_regs.eflags & X86_EFLAGS_VM) &&
@@ -4800,6 +4806,7 @@ x86_emulate(
         break;
     }
 
+#ifndef X86EMUL_NO_FPU
     case 0xd8: /* FPU 0xd8 */
         host_and_vcpu_must_have(fpu);
         get_fpu(X86EMUL_FPU_fpu);
@@ -5134,6 +5141,7 @@ x86_emulate(
             }
         }
         break;
+#endif /* !X86EMUL_NO_FPU */
 
     case 0xe0 ... 0xe2: /* loop{,z,nz} */ {
         unsigned long count = get_loop_count(&_regs, ad_bytes);
@@ -6079,6 +6087,8 @@ x86_emulate(
     case X86EMUL_OPC(0x0f, 0x19) ... X86EMUL_OPC(0x0f, 0x1f): /* nop */
         break;
 
+#ifndef X86EMUL_NO_MMX
+
     case X86EMUL_OPC(0x0f, 0x0e): /* femms */
         host_and_vcpu_must_have(3dnow);
         asm volatile ( "femms" );
@@ -6099,39 +6109,71 @@ x86_emulate(
         state->simd_size = simd_other;
         goto simd_0f_imm8;
 
-#define CASE_SIMD_PACKED_INT(pfx, opc)       \
+#endif /* !X86EMUL_NO_MMX */
+
+#if !defined(X86EMUL_NO_SIMD) && !defined(X86EMUL_NO_MMX)
+# define CASE_SIMD_PACKED_INT(pfx, opc)      \
     case X86EMUL_OPC(pfx, opc):              \
     case X86EMUL_OPC_66(pfx, opc)
-#define CASE_SIMD_PACKED_INT_VEX(pfx, opc)   \
+#elif !defined(X86EMUL_NO_SIMD)
+# define CASE_SIMD_PACKED_INT(pfx, opc)      \
+    case X86EMUL_OPC_66(pfx, opc)
+#elif !defined(X86EMUL_NO_MMX)
+# define CASE_SIMD_PACKED_INT(pfx, opc)      \
+    case X86EMUL_OPC(pfx, opc)
+#else
+# define CASE_SIMD_PACKED_INT(pfx, opc) C##pfx##_##opc
+#endif
+
+#ifndef X86EMUL_NO_SIMD
+
+# define CASE_SIMD_PACKED_INT_VEX(pfx, opc)  \
     CASE_SIMD_PACKED_INT(pfx, opc):          \
     case X86EMUL_OPC_VEX_66(pfx, opc)
 
-#define CASE_SIMD_ALL_FP(kind, pfx, opc)     \
+# define CASE_SIMD_ALL_FP(kind, pfx, opc)    \
     CASE_SIMD_PACKED_FP(kind, pfx, opc):     \
     CASE_SIMD_SCALAR_FP(kind, pfx, opc)
-#define CASE_SIMD_PACKED_FP(kind, pfx, opc)  \
+# define CASE_SIMD_PACKED_FP(kind, pfx, opc) \
     case X86EMUL_OPC##kind(pfx, opc):        \
     case X86EMUL_OPC##kind##_66(pfx, opc)
-#define CASE_SIMD_SCALAR_FP(kind, pfx, opc)  \
+# define CASE_SIMD_SCALAR_FP(kind, pfx, opc) \
     case X86EMUL_OPC##kind##_F3(pfx, opc):   \
     case X86EMUL_OPC##kind##_F2(pfx, opc)
-#define CASE_SIMD_SINGLE_FP(kind, pfx, opc)  \
+# define CASE_SIMD_SINGLE_FP(kind, pfx, opc) \
     case X86EMUL_OPC##kind(pfx, opc):        \
     case X86EMUL_OPC##kind##_F3(pfx, opc)
 
-#define CASE_SIMD_ALL_FP_VEX(pfx, opc)       \
+# define CASE_SIMD_ALL_FP_VEX(pfx, opc)      \
     CASE_SIMD_ALL_FP(, pfx, opc):            \
     CASE_SIMD_ALL_FP(_VEX, pfx, opc)
-#define CASE_SIMD_PACKED_FP_VEX(pfx, opc)    \
+# define CASE_SIMD_PACKED_FP_VEX(pfx, opc)   \
     CASE_SIMD_PACKED_FP(, pfx, opc):         \
     CASE_SIMD_PACKED_FP(_VEX, pfx, opc)
-#define CASE_SIMD_SCALAR_FP_VEX(pfx, opc)    \
+# define CASE_SIMD_SCALAR_FP_VEX(pfx, opc)   \
     CASE_SIMD_SCALAR_FP(, pfx, opc):         \
     CASE_SIMD_SCALAR_FP(_VEX, pfx, opc)
-#define CASE_SIMD_SINGLE_FP_VEX(pfx, opc)    \
+# define CASE_SIMD_SINGLE_FP_VEX(pfx, opc)   \
     CASE_SIMD_SINGLE_FP(, pfx, opc):         \
     CASE_SIMD_SINGLE_FP(_VEX, pfx, opc)
 
+#else
+
+# define CASE_SIMD_PACKED_INT_VEX(pfx, opc)  \
+    CASE_SIMD_PACKED_INT(pfx, opc)
+
+# define CASE_SIMD_ALL_FP(kind, pfx, opc)    C##kind##pfx##_##opc
+# define CASE_SIMD_PACKED_FP(kind, pfx, opc) Cp##kind##pfx##_##opc
+# define CASE_SIMD_SCALAR_FP(kind, pfx, opc) Cs##kind##pfx##_##opc
+# define CASE_SIMD_SINGLE_FP(kind, pfx, opc) C##kind##pfx##_##opc
+
+# define CASE_SIMD_ALL_FP_VEX(pfx, opc)    CASE_SIMD_ALL_FP(, pfx, opc)
+# define CASE_SIMD_PACKED_FP_VEX(pfx, opc) CASE_SIMD_PACKED_FP(, pfx, opc)
+# define CASE_SIMD_SCALAR_FP_VEX(pfx, opc) CASE_SIMD_SCALAR_FP(, pfx, opc)
+# define CASE_SIMD_SINGLE_FP_VEX(pfx, opc) CASE_SIMD_SINGLE_FP(, pfx, opc)
+
+#endif
+
     CASE_SIMD_SCALAR_FP(, 0x0f, 0x2b):     /* movnts{s,d} xmm,mem */
         host_and_vcpu_must_have(sse4a);
         /* fall through */
@@ -6269,6 +6311,8 @@ x86_emulate(
         insn_bytes = EVEX_PFX_BYTES + 2;
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_66(0x0f, 0x12):       /* movlpd m64,xmm */
     case X86EMUL_OPC_VEX_66(0x0f, 0x12):   /* vmovlpd m64,xmm,xmm */
     CASE_SIMD_PACKED_FP_VEX(0x0f, 0x13):   /* movlp{s,d} xmm,m64 */
@@ -6375,6 +6419,8 @@ x86_emulate(
         avx512_vlen_check(false);
         goto simd_zmm;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC(0x0f, 0x20): /* mov cr,reg */
     case X86EMUL_OPC(0x0f, 0x21): /* mov dr,reg */
     case X86EMUL_OPC(0x0f, 0x22): /* mov reg,cr */
@@ -6401,6 +6447,8 @@ x86_emulate(
             goto done;
         break;
 
+#if !defined(X86EMUL_NO_MMX) && !defined(X86EMUL_NO_SIMD)
+
     case X86EMUL_OPC_66(0x0f, 0x2a):       /* cvtpi2pd mm/m64,xmm */
         if ( ea.type == OP_REG )
         {
@@ -6412,6 +6460,8 @@ x86_emulate(
         op_bytes = (b & 4) && (vex.pfx & VEX_PREFIX_DOUBLE_MASK) ? 16 : 8;
         goto simd_0f_fp;
 
+#endif /* !X86EMUL_NO_MMX && !X86EMUL_NO_SIMD */
+
     CASE_SIMD_SCALAR_FP_VEX(0x0f, 0x2a):   /* {,v}cvtsi2s{s,d} r/m,xmm */
         if ( vex.opcx == vex_none )
         {
@@ -6758,6 +6808,8 @@ x86_emulate(
             dst.val = src.val;
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_VEX(0x0f, 0x4a):    /* kadd{w,q} k,k,k */
         if ( !vex.w )
             host_and_vcpu_must_have(avx512dq);
@@ -6812,6 +6864,8 @@ x86_emulate(
         generate_exception_if(!vex.l || vex.w, EXC_UD);
         goto opmask_common;
 
+#endif /* X86EMUL_NO_SIMD */
+
     CASE_SIMD_PACKED_FP_VEX(0x0f, 0x50):   /* movmskp{s,d} xmm,reg */
                                            /* vmovmskp{s,d} {x,y}mm,reg */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xd7):  /* pmovmskb {,x}mm,reg */
@@ -6895,6 +6949,8 @@ x86_emulate(
                          evex.w);
         goto avx512f_all_fp;
 
+#ifndef X86EMUL_NO_SIMD
+
     CASE_SIMD_PACKED_FP_VEX(0x0f, 0x5b):   /* cvt{ps,dq}2{dq,ps} xmm/mem,xmm */
                                            /* vcvt{ps,dq}2{dq,ps} {x,y}mm/mem,{x,y}mm */
     case X86EMUL_OPC_F3(0x0f, 0x5b):       /* cvttps2dq xmm/mem,xmm */
@@ -6925,6 +6981,8 @@ x86_emulate(
         op_bytes = 16 << evex.lr;
         goto simd_zmm;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x60): /* punpcklbw {,x}mm/mem,{,x}mm */
                                           /* vpunpcklbw {x,y}mm/mem,{x,y}mm,{x,y}mm */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x61): /* punpcklwd {,x}mm/mem,{,x}mm */
@@ -6951,6 +7009,7 @@ x86_emulate(
                                           /* vpackusbw {x,y}mm/mem,{x,y}mm,{x,y}mm */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x6b): /* packsswd {,x}mm/mem,{,x}mm */
                                           /* vpacksswd {x,y}mm/mem,{x,y}mm,{x,y}mm */
+#ifndef X86EMUL_NO_SIMD
     case X86EMUL_OPC_66(0x0f, 0x6c):     /* punpcklqdq xmm/m128,xmm */
     case X86EMUL_OPC_VEX_66(0x0f, 0x6c): /* vpunpcklqdq {x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_66(0x0f, 0x6d):     /* punpckhqdq xmm/m128,xmm */
@@ -7035,6 +7094,7 @@ x86_emulate(
                                           /* vpsubd {x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_66(0x0f, 0xfb):     /* psubq xmm/m128,xmm */
     case X86EMUL_OPC_VEX_66(0x0f, 0xfb): /* vpsubq {x,y}mm/mem,{x,y}mm,{x,y}mm */
+#endif /* !X86EMUL_NO_SIMD */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xfc): /* paddb {,x}mm/mem,{,x}mm */
                                           /* vpaddb {x,y}mm/mem,{x,y}mm,{x,y}mm */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xfd): /* paddw {,x}mm/mem,{,x}mm */
@@ -7042,6 +7102,7 @@ x86_emulate(
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xfe): /* paddd {,x}mm/mem,{,x}mm */
                                           /* vpaddd {x,y}mm/mem,{x,y}mm,{x,y}mm */
     simd_0f_int:
+#ifndef X86EMUL_NO_SIMD
         if ( vex.opcx != vex_none )
         {
     case X86EMUL_OPC_VEX_66(0x0f38, 0x00): /* vpshufb {x,y}mm/mem,{x,y}mm,{x,y}mm */
@@ -7083,11 +7144,14 @@ x86_emulate(
         }
         if ( vex.pfx )
             goto simd_0f_sse2;
+#endif /* !X86EMUL_NO_SIMD */
     simd_0f_mmx:
         host_and_vcpu_must_have(mmx);
         get_fpu(X86EMUL_FPU_mmx);
         goto simd_0f_common;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_EVEX_66(0x0f, 0xf6): /* vpsadbw [xyz]mm/mem,[xyz]mm,[xyz]mm */
         generate_exception_if(evex.opmsk, EXC_UD);
         /* fall through */
@@ -7181,6 +7245,8 @@ x86_emulate(
         generate_exception_if(!evex.w, EXC_UD);
         goto avx512f_no_sae;
 
+#endif /* X86EMUL_NO_SIMD */
+
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x6e): /* mov{d,q} r/m,{,x}mm */
                                           /* vmov{d,q} r/m,xmm */
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x7e): /* mov{d,q} {,x}mm,r/m */
@@ -7222,6 +7288,8 @@ x86_emulate(
         ASSERT(!state->simd_size);
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_EVEX_66(0x0f, 0x6e): /* vmov{d,q} r/m,xmm */
     case X86EMUL_OPC_EVEX_66(0x0f, 0x7e): /* vmov{d,q} xmm,r/m */
         generate_exception_if((evex.lr || evex.opmsk || evex.brs ||
@@ -7294,11 +7362,15 @@ x86_emulate(
         d |= TwoOp;
         /* fall through */
     case X86EMUL_OPC_66(0x0f, 0xd6):     /* movq xmm,xmm/m64 */
+#endif /* !X86EMUL_NO_SIMD */
+#ifndef X86EMUL_NO_MMX
     case X86EMUL_OPC(0x0f, 0x6f):        /* movq mm/m64,mm */
     case X86EMUL_OPC(0x0f, 0x7f):        /* movq mm,mm/m64 */
+#endif
         op_bytes = 8;
         goto simd_0f_int;
 
+#ifndef X86EMUL_NO_SIMD
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0x70):/* pshuf{w,d} $imm8,{,x}mm/mem,{,x}mm */
                                          /* vpshufd $imm8,{x,y}mm/mem,{x,y}mm */
     case X86EMUL_OPC_F3(0x0f, 0x70):     /* pshufhw $imm8,xmm/m128,xmm */
@@ -7307,12 +7379,15 @@ x86_emulate(
     case X86EMUL_OPC_VEX_F2(0x0f, 0x70): /* vpshuflw $imm8,{x,y}mm/mem,{x,y}mm */
         d = (d & ~SrcMask) | SrcMem | TwoOp;
         op_bytes = vex.pfx ? 16 << vex.l : 8;
+#endif
     simd_0f_int_imm8:
         if ( vex.opcx != vex_none )
         {
+#ifndef X86EMUL_NO_SIMD
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0e): /* vpblendw $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0f): /* vpalignr $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x42): /* vmpsadbw $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
+#endif
             if ( vex.l )
             {
     simd_0f_imm8_avx2:
@@ -7320,6 +7395,7 @@ x86_emulate(
             }
             else
             {
+#ifndef X86EMUL_NO_SIMD
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x08): /* vroundps $imm8,{x,y}mm/mem,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x09): /* vroundpd $imm8,{x,y}mm/mem,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0a): /* vroundss $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
@@ -7327,6 +7403,7 @@ x86_emulate(
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0c): /* vblendps $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x0d): /* vblendpd $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x40): /* vdpps $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
+#endif
     simd_0f_imm8_avx:
                 host_and_vcpu_must_have(avx);
             }
@@ -7360,6 +7437,8 @@ x86_emulate(
         insn_bytes = PFX_BYTES + 3;
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_EVEX_66(0x0f, 0x70): /* vpshufd $imm8,[xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_F3(0x0f, 0x70): /* vpshufhw $imm8,[xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_F2(0x0f, 0x70): /* vpshuflw $imm8,[xyz]mm/mem,[xyz]mm{k} */
@@ -7418,6 +7497,9 @@ x86_emulate(
         opc[1] = modrm;
         opc[2] = imm1;
         insn_bytes = PFX_BYTES + 3;
+
+#endif /* X86EMUL_NO_SIMD */
+
     simd_0f_reg_only:
         opc[insn_bytes - PFX_BYTES] = 0xc3;
 
@@ -7428,6 +7510,8 @@ x86_emulate(
         ASSERT(!state->simd_size);
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_EVEX_66(0x0f, 0x71): /* Grp12 */
         switch ( modrm_reg & 7 )
         {
@@ -7459,6 +7543,9 @@ x86_emulate(
         }
         goto unrecognized_insn;
 
+#endif /* !X86EMUL_NO_SIMD */
+#ifndef X86EMUL_NO_MMX
+
     case X86EMUL_OPC(0x0f, 0x73):        /* Grp14 */
         switch ( modrm_reg & 7 )
         {
@@ -7468,6 +7555,9 @@ x86_emulate(
         }
         goto unrecognized_insn;
 
+#endif /* !X86EMUL_NO_MMX */
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_66(0x0f, 0x73):
     case X86EMUL_OPC_VEX_66(0x0f, 0x73):
         switch ( modrm_reg & 7 )
@@ -7498,7 +7588,12 @@ x86_emulate(
         }
         goto unrecognized_insn;
 
+#endif /* !X86EMUL_NO_SIMD */
+
+#ifndef X86EMUL_NO_MMX
     case X86EMUL_OPC(0x0f, 0x77):        /* emms */
+#endif
+#ifndef X86EMUL_NO_SIMD
     case X86EMUL_OPC_VEX(0x0f, 0x77):    /* vzero{all,upper} */
         if ( vex.opcx != vex_none )
         {
@@ -7544,6 +7639,7 @@ x86_emulate(
 #endif
         }
         else
+#endif /* !X86EMUL_NO_SIMD */
         {
             host_and_vcpu_must_have(mmx);
             get_fpu(X86EMUL_FPU_mmx);
@@ -7557,6 +7653,8 @@ x86_emulate(
         insn_bytes = PFX_BYTES + 1;
         goto simd_0f_reg_only;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_66(0x0f, 0x78):     /* Grp17 */
         switch ( modrm_reg & 7 )
         {
@@ -7654,6 +7752,8 @@ x86_emulate(
         op_bytes = 8;
         goto simd_zmm;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC(0x0f, 0x80) ... X86EMUL_OPC(0x0f, 0x8f): /* jcc (near) */
         if ( test_cc(b, _regs.eflags) )
             jmp_rel((int32_t)src.val);
@@ -7664,6 +7764,8 @@ x86_emulate(
         dst.val = test_cc(b, _regs.eflags);
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_VEX(0x0f, 0x91):    /* kmov{w,q} k,mem */
     case X86EMUL_OPC_VEX_66(0x0f, 0x91): /* kmov{b,d} k,mem */
         generate_exception_if(ea.type != OP_MEM, EXC_UD);
@@ -7812,6 +7914,8 @@ x86_emulate(
         dst.type = OP_NONE;
         break;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC(0x0f, 0xa2): /* cpuid */
         msr_val = 0;
         fail_if(ops->cpuid == NULL);
@@ -7908,6 +8012,7 @@ x86_emulate(
     case X86EMUL_OPC(0x0f, 0xae): case X86EMUL_OPC_66(0x0f, 0xae): /* Grp15 */
         switch ( modrm_reg & 7 )
         {
+#ifndef X86EMUL_NO_SIMD
         case 2: /* ldmxcsr */
             generate_exception_if(vex.pfx, EXC_UD);
             vcpu_must_have(sse);
@@ -7926,6 +8031,7 @@ x86_emulate(
             get_fpu(vex.opcx ? X86EMUL_FPU_ymm : X86EMUL_FPU_xmm);
             asm volatile ( "stmxcsr %0" : "=m" (dst.val) );
             break;
+#endif /* X86EMUL_NO_SIMD */
 
         case 5: /* lfence */
             fail_if(modrm_mod != 3);
@@ -7974,6 +8080,8 @@ x86_emulate(
         }
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_VEX(0x0f, 0xae): /* Grp15 */
         switch ( modrm_reg & 7 )
         {
@@ -7988,6 +8096,8 @@ x86_emulate(
         }
         goto unrecognized_insn;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC_F3(0x0f, 0xae): /* Grp15 */
         fail_if(modrm_mod != 3);
         generate_exception_if((modrm_reg & 4) || !mode_64bit(), EXC_UD);
@@ -8227,6 +8337,8 @@ x86_emulate(
         }
         goto simd_0f_imm8_avx;
 
+#ifndef X86EMUL_NO_SIMD
+
     CASE_SIMD_ALL_FP(_EVEX, 0x0f, 0xc2): /* vcmp{p,s}{s,d} $imm8,[xyz]mm/mem,[xyz]mm,k{k} */
         generate_exception_if((evex.w != (evex.pfx & VEX_PREFIX_DOUBLE_MASK) ||
                                (ea.type != OP_REG && evex.brs &&
@@ -8253,6 +8365,8 @@ x86_emulate(
         insn_bytes = EVEX_PFX_BYTES + 3;
         break;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC(0x0f, 0xc3): /* movnti */
         /* Ignore the non-temporal hint for now. */
         vcpu_must_have(sse2);
@@ -8267,6 +8381,8 @@ x86_emulate(
         ea.type = OP_MEM;
         goto simd_0f_int_imm8;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_EVEX_66(0x0f, 0xc4):   /* vpinsrw $imm8,r32/m16,xmm,xmm */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x20): /* vpinsrb $imm8,r32/m8,xmm,xmm */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x22): /* vpinsr{d,q} $imm8,r/m,xmm,xmm */
@@ -8284,6 +8400,8 @@ x86_emulate(
         state->simd_size = simd_other;
         goto avx512f_imm8_no_sae;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xc5):  /* pextrw $imm8,{,x}mm,reg */
                                            /* vpextrw $imm8,xmm,reg */
         generate_exception_if(vex.l, EXC_UD);
@@ -8299,6 +8417,8 @@ x86_emulate(
         insn_bytes = PFX_BYTES + 3;
         goto simd_0f_to_gpr;
 
+#ifndef X86EMUL_NO_SIMD
+
     CASE_SIMD_PACKED_FP(_EVEX, 0x0f, 0xc6): /* vshufp{s,d} $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
         generate_exception_if(evex.w != (evex.pfx & VEX_PREFIX_DOUBLE_MASK),
                               EXC_UD);
@@ -8313,6 +8433,8 @@ x86_emulate(
         avx512_vlen_check(false);
         goto simd_imm8_zmm;
 
+#endif /* X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC(0x0f, 0xc7): /* Grp9 */
     {
         union {
@@ -8503,6 +8625,8 @@ x86_emulate(
         }
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_EVEX_66(0x0f, 0xd2): /* vpsrld xmm/m128,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f, 0xd3): /* vpsrlq xmm/m128,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f, 0xe2): /* vpsra{d,q} xmm/m128,[xyz]mm,[xyz]mm{k} */
@@ -8524,12 +8648,18 @@ x86_emulate(
         generate_exception_if(evex.w != (b & 1), EXC_UD);
         goto avx512f_no_sae;
 
+#endif /* !X86EMUL_NO_SIMD */
+#ifndef X86EMUL_NO_MMX
+
     case X86EMUL_OPC(0x0f, 0xd4):        /* paddq mm/m64,mm */
     case X86EMUL_OPC(0x0f, 0xf4):        /* pmuludq mm/m64,mm */
     case X86EMUL_OPC(0x0f, 0xfb):        /* psubq mm/m64,mm */
         vcpu_must_have(sse2);
         goto simd_0f_mmx;
 
+#endif /* !X86EMUL_NO_MMX */
+#if !defined(X86EMUL_NO_MMX) && !defined(X86EMUL_NO_SIMD)
+
     case X86EMUL_OPC_F3(0x0f, 0xd6):     /* movq2dq mm,xmm */
     case X86EMUL_OPC_F2(0x0f, 0xd6):     /* movdq2q xmm,mm */
         generate_exception_if(ea.type != OP_REG, EXC_UD);
@@ -8537,6 +8667,9 @@ x86_emulate(
         host_and_vcpu_must_have(mmx);
         goto simd_0f_int;
 
+#endif /* !X86EMUL_NO_MMX && !X86EMUL_NO_SIMD */
+#ifndef X86EMUL_NO_MMX
+
     case X86EMUL_OPC(0x0f, 0xe7):        /* movntq mm,m64 */
         generate_exception_if(ea.type != OP_MEM, EXC_UD);
         sfence = true;
@@ -8552,6 +8685,9 @@ x86_emulate(
         vcpu_must_have(mmxext);
         goto simd_0f_mmx;
 
+#endif /* !X86EMUL_NO_MMX */
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_EVEX_66(0x0f, 0xda): /* vpminub [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f, 0xde): /* vpmaxub [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f, 0xe4): /* vpmulhuw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
@@ -8572,6 +8708,8 @@ x86_emulate(
         op_bytes = 8 << (!!(vex.pfx & VEX_PREFIX_DOUBLE_MASK) + vex.l);
         goto simd_0f_cvt;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     CASE_SIMD_PACKED_INT_VEX(0x0f, 0xf7): /* {,v}maskmov{q,dqu} {,x}mm,{,x}mm */
         generate_exception_if(ea.type != OP_REG, EXC_UD);
         if ( vex.opcx != vex_none )
@@ -8675,6 +8813,8 @@ x86_emulate(
         insn_bytes = PFX_BYTES + 3;
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_VEX_66(0x0f38, 0x19): /* vbroadcastsd xmm/m64,ymm */
     case X86EMUL_OPC_VEX_66(0x0f38, 0x1a): /* vbroadcastf128 m128,ymm */
         generate_exception_if(!vex.l, EXC_UD);
@@ -9257,6 +9397,8 @@ x86_emulate(
         ASSERT(!state->simd_size);
         break;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC_66(0x0f38, 0x82): /* invpcid reg,m128 */
         vcpu_must_have(invpcid);
         generate_exception_if(ea.type != OP_MEM, EXC_UD);
@@ -9299,6 +9441,8 @@ x86_emulate(
         state->simd_size = simd_none;
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x83): /* vpmultishiftqb [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
         generate_exception_if(!evex.w, EXC_UD);
         host_and_vcpu_must_have(avx512_vbmi);
@@ -9862,6 +10006,8 @@ x86_emulate(
         generate_exception_if(evex.brs || evex.opmsk, EXC_UD);
         goto avx512f_no_sae;
 
+#endif /* !X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC(0x0f38, 0xf0): /* movbe m,r */
     case X86EMUL_OPC(0x0f38, 0xf1): /* movbe r,m */
         vcpu_must_have(movbe);
@@ -10027,6 +10173,8 @@ x86_emulate(
                             : "0" ((uint32_t)src.val), "rm" (_regs.edx) );
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x00): /* vpermq $imm8,ymm/m256,ymm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x01): /* vpermpd $imm8,ymm/m256,ymm */
         generate_exception_if(!vex.l || !vex.w, EXC_UD);
@@ -10087,6 +10235,8 @@ x86_emulate(
         avx512_vlen_check(b & 2);
         goto simd_imm8_zmm;
 
+#endif /* X86EMUL_NO_SIMD */
+
     CASE_SIMD_PACKED_INT(0x0f3a, 0x0f): /* palignr $imm8,{,x}mm/mem,{,x}mm */
         host_and_vcpu_must_have(ssse3);
         if ( vex.pfx )
@@ -10114,6 +10264,8 @@ x86_emulate(
         insn_bytes = PFX_BYTES + 4;
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x42): /* vdbpsadbw $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
         generate_exception_if(evex.w, EXC_UD);
         /* fall through */
@@ -10612,6 +10764,8 @@ x86_emulate(
         generate_exception_if(vex.l, EXC_UD);
         goto simd_0f_imm8_avx;
 
+#endif /* X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC_VEX_F2(0x0f3a, 0xf0): /* rorx imm,r/m,r */
         vcpu_must_have(bmi2);
         generate_exception_if(vex.l || vex.reg != 0xf, EXC_UD);
@@ -10626,6 +10780,8 @@ x86_emulate(
             asm ( "rorl %b1,%k0" : "=g" (dst.val) : "c" (imm1), "0" (src.val) );
         break;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_XOP(08, 0x85): /* vpmacssww xmm,xmm/m128,xmm,xmm */
     case X86EMUL_OPC_XOP(08, 0x86): /* vpmacsswd xmm,xmm/m128,xmm,xmm */
     case X86EMUL_OPC_XOP(08, 0x87): /* vpmacssdql xmm,xmm/m128,xmm,xmm */
@@ -10661,6 +10817,8 @@ x86_emulate(
         host_and_vcpu_must_have(xop);
         goto simd_0f_imm8_ymm;
 
+#endif /* X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC_XOP(09, 0x01): /* XOP Grp1 */
         switch ( modrm_reg & 7 )
         {
@@ -10720,6 +10878,8 @@ x86_emulate(
         }
         goto unrecognized_insn;
 
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_XOP(09, 0x82): /* vfrczss xmm/m128,xmm */
     case X86EMUL_OPC_XOP(09, 0x83): /* vfrczsd xmm/m128,xmm */
         generate_exception_if(vex.l, EXC_UD);
@@ -10775,6 +10935,8 @@ x86_emulate(
         host_and_vcpu_must_have(xop);
         goto simd_0f_ymm;
 
+#endif /* X86EMUL_NO_SIMD */
+
     case X86EMUL_OPC_XOP(0a, 0x10): /* bextr imm,r/m,r */
     {
         uint8_t *buf = get_stub(stub);



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:12:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1gG-0005ZT-Mx; Mon, 27 Apr 2020 11:12:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1gF-0005ZK-LT
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:12:07 +0000
X-Inumbo-ID: edc30c06-8877-11ea-9760-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id edc30c06-8877-11ea-9760-12813bfff9fa;
 Mon, 27 Apr 2020 11:12:06 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C9477ABE2;
 Mon, 27 Apr 2020 11:12:04 +0000 (UTC)
Subject: [PATCH v7 02/11] x86emul: support MOVDIR{I,64B} insns
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <1a689076-bc31-543c-3ffd-99f646461669@suse.com>
Date: Mon, 27 Apr 2020 13:12:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Introduce a new blk() hook, paralleling the rmw() one in a certain way,
but being intended for larger data sizes, and hence its HVM intermediate
handling function doesn't fall back to splitting the operation if the
requested virtual address can't be mapped.

Note that SDM revision 071 doesn't specify exception behavior for
ModRM.mod == 0b11; assuming #UD here.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul@xen.org>
---
v7: Add blk_NONE. Move  harness'es setting of .blk. Correct indentation.
    Re-base.
v6: Fold MOVDIRI and MOVDIR64B changes again. Use blk() for both. All
    tags dropped.
v5: Introduce/use ->blk() hook. Correct asm() operands.
v4: Split MOVDIRI and MOVDIR64B and move this one ahead. Re-base.
v3: Update description.
---
(SDE: -tnt)

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -652,6 +652,18 @@ static int cmpxchg(
     return X86EMUL_OKAY;
 }
 
+static int blk(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    uint32_t *eflags,
+    struct x86_emulate_state *state,
+    struct x86_emulate_ctxt *ctxt)
+{
+    return x86_emul_blk((void *)offset, p_data, bytes, eflags, state, ctxt);
+}
+
 static int read_segment(
     enum x86_segment seg,
     struct segment_register *reg,
@@ -721,6 +733,7 @@ static struct x86_emulate_ops emulops =
     .insn_fetch = fetch,
     .write      = write,
     .cmpxchg    = cmpxchg,
+    .blk        = blk,
     .read_segment = read_segment,
     .cpuid      = emul_test_cpuid,
     .read_cr    = emul_test_read_cr,
@@ -2339,6 +2352,50 @@ int main(int argc, char **argv)
         goto fail;
     printf("okay\n");
 
+    printf("%-40s", "Testing movdiri %edx,(%ecx)...");
+    if ( stack_exec && cpu_has_movdiri )
+    {
+        instr[0] = 0x0f; instr[1] = 0x38; instr[2] = 0xf9; instr[3] = 0x11;
+
+        regs.eip = (unsigned long)&instr[0];
+        regs.ecx = (unsigned long)memset(res, -1, 16);
+        regs.edx = 0x44332211;
+
+        rc = x86_emulate(&ctxt, &emulops);
+        if ( (rc != X86EMUL_OKAY) ||
+             (regs.eip != (unsigned long)&instr[4]) ||
+             res[0] != 0x44332211 || ~res[1] )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing movdir64b 144(%edx),%ecx...");
+    if ( stack_exec && cpu_has_movdir64b )
+    {
+        instr[0] = 0x66; instr[1] = 0x0f; instr[2] = 0x38; instr[3] = 0xf8;
+        instr[4] = 0x8a; instr[5] = 0x90; instr[8] = instr[7] = instr[6] = 0;
+
+        regs.eip = (unsigned long)&instr[0];
+        for ( i = 0; i < 64; ++i )
+            res[i] = i - 20;
+        regs.edx = (unsigned long)res;
+        regs.ecx = (unsigned long)(res + 16);
+
+        rc = x86_emulate(&ctxt, &emulops);
+        if ( (rc != X86EMUL_OKAY) ||
+             (regs.eip != (unsigned long)&instr[9]) ||
+             res[15] != -5 || res[32] != 12 )
+            goto fail;
+        for ( i = 16; i < 32; ++i )
+            if ( res[i] != i )
+                goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
     printf("%-40s", "Testing movq %mm3,(%ecx)...");
     if ( stack_exec && cpu_has_mmx )
     {
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -154,6 +154,8 @@ static inline bool xcr0_mask(uint64_t ma
 #define cpu_has_avx512_vnni (cp.feat.avx512_vnni && xcr0_mask(0xe6))
 #define cpu_has_avx512_bitalg (cp.feat.avx512_bitalg && xcr0_mask(0xe6))
 #define cpu_has_avx512_vpopcntdq (cp.feat.avx512_vpopcntdq && xcr0_mask(0xe6))
+#define cpu_has_movdiri    cp.feat.movdiri
+#define cpu_has_movdir64b  cp.feat.movdir64b
 #define cpu_has_avx512_4vnniw (cp.feat.avx512_4vnniw && xcr0_mask(0xe6))
 #define cpu_has_avx512_4fmaps (cp.feat.avx512_4fmaps && xcr0_mask(0xe6))
 #define cpu_has_avx512_bf16 (cp.feat.avx512_bf16 && xcr0_mask(0xe6))
--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -47,6 +47,7 @@ $(call as-option-add,CFLAGS,CC,"rdseed %
 $(call as-option-add,CFLAGS,CC,"clwb (%rax)",-DHAVE_AS_CLWB)
 $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1",-DHAVE_AS_QUOTED_SYM)
 $(call as-option-add,CFLAGS,CC,"invpcid (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
+$(call as-option-add,CFLAGS,CC,"movdiri %rax$$(comma)(%rax)",-DHAVE_AS_MOVDIR)
 
 # GAS's idea of true is -1.  Clang's idea is 1
 $(call as-option-add,CFLAGS,CC,\
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1441,6 +1441,44 @@ static int hvmemul_rmw(
     return rc;
 }
 
+static int hvmemul_blk(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    uint32_t *eflags,
+    struct x86_emulate_state *state,
+    struct x86_emulate_ctxt *ctxt)
+{
+    struct hvm_emulate_ctxt *hvmemul_ctxt =
+        container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
+    unsigned long addr;
+    uint32_t pfec = PFEC_page_present | PFEC_write_access;
+    int rc;
+    void *mapping = NULL;
+
+    rc = hvmemul_virtual_to_linear(
+        seg, offset, bytes, NULL, hvm_access_write, hvmemul_ctxt, &addr);
+    if ( rc != X86EMUL_OKAY || !bytes )
+        return rc;
+
+    if ( is_x86_system_segment(seg) )
+        pfec |= PFEC_implicit;
+    else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
+        pfec |= PFEC_user_mode;
+
+    mapping = hvmemul_map_linear_addr(addr, bytes, pfec, hvmemul_ctxt);
+    if ( IS_ERR(mapping) )
+        return ~PTR_ERR(mapping);
+    if ( !mapping )
+        return X86EMUL_UNHANDLEABLE;
+
+    rc = x86_emul_blk(mapping, p_data, bytes, eflags, state, ctxt);
+    hvmemul_unmap_linear_addr(mapping, addr, bytes, hvmemul_ctxt);
+
+    return rc;
+}
+
 static int hvmemul_write_discard(
     enum x86_segment seg,
     unsigned long offset,
@@ -2512,6 +2550,7 @@ static const struct x86_emulate_ops hvm_
     .write         = hvmemul_write,
     .rmw           = hvmemul_rmw,
     .cmpxchg       = hvmemul_cmpxchg,
+    .blk           = hvmemul_blk,
     .validate      = hvmemul_validate,
     .rep_ins       = hvmemul_rep_ins,
     .rep_outs      = hvmemul_rep_outs,
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -548,6 +548,8 @@ static const struct ext0f38_table {
     [0xf1] = { .to_mem = 1, .two_op = 1 },
     [0xf2 ... 0xf3] = {},
     [0xf5 ... 0xf7] = {},
+    [0xf8] = { .simd_size = simd_other },
+    [0xf9] = { .to_mem = 1, .two_op = 1 /* Mov */ },
 };
 
 /* Shift values between src and dst sizes of pmov{s,z}x{b,w,d}{w,d,q}. */
@@ -851,6 +853,10 @@ struct x86_emulate_state {
         rmw_xchg,
         rmw_xor,
     } rmw;
+    enum {
+        blk_NONE,
+        blk_movdir,
+    } blk;
     uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
     uint8_t sib_index, sib_scale;
     uint8_t rex_prefix;
@@ -1914,6 +1920,8 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
 #define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
 #define vcpu_has_rdpid()       (ctxt->cpuid->feat.rdpid)
+#define vcpu_has_movdiri()     (ctxt->cpuid->feat.movdiri)
+#define vcpu_has_movdir64b()   (ctxt->cpuid->feat.movdir64b)
 #define vcpu_has_avx512_4vnniw() (ctxt->cpuid->feat.avx512_4vnniw)
 #define vcpu_has_avx512_4fmaps() (ctxt->cpuid->feat.avx512_4fmaps)
 #define vcpu_has_avx512_bf16() (ctxt->cpuid->feat.avx512_bf16)
@@ -2722,10 +2730,12 @@ x86_decode_0f38(
     {
     case 0x00 ... 0xef:
     case 0xf2 ... 0xf5:
-    case 0xf7 ... 0xff:
+    case 0xf7 ... 0xf8:
+    case 0xfa ... 0xff:
         op_bytes = 0;
         /* fall through */
     case 0xf6: /* adcx / adox */
+    case 0xf9: /* movdiri */
         ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
         break;
 
@@ -10173,6 +10183,34 @@ x86_emulate(
                             : "0" ((uint32_t)src.val), "rm" (_regs.edx) );
         break;
 
+    case X86EMUL_OPC_66(0x0f38, 0xf8): /* movdir64b r,m512 */
+        host_and_vcpu_must_have(movdir64b);
+        generate_exception_if(ea.type != OP_MEM, EXC_UD);
+        src.val = truncate_ea(*dst.reg);
+        generate_exception_if(!is_aligned(x86_seg_es, src.val, 64, ctxt, ops),
+                              EXC_GP, 0);
+        fail_if(!ops->blk);
+        state->blk = blk_movdir;
+        BUILD_BUG_ON(sizeof(*mmvalp) < 64);
+        if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp, 64,
+                             ctxt)) != X86EMUL_OKAY ||
+             (rc = ops->blk(x86_seg_es, src.val, mmvalp, 64, &_regs.eflags,
+                            state, ctxt)) != X86EMUL_OKAY )
+            goto done;
+        state->simd_size = simd_none;
+        break;
+
+    case X86EMUL_OPC(0x0f38, 0xf9): /* movdiri mem,r */
+        host_and_vcpu_must_have(movdiri);
+        generate_exception_if(dst.type != OP_MEM, EXC_UD);
+        fail_if(!ops->blk);
+        state->blk = blk_movdir;
+        if ( (rc = ops->blk(dst.mem.seg, dst.mem.off, &src.val, op_bytes,
+                            &_regs.eflags, state, ctxt)) != X86EMUL_OKAY )
+            goto done;
+        dst.type = OP_NONE;
+        break;
+
 #ifndef X86EMUL_NO_SIMD
 
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x00): /* vpermq $imm8,ymm/m256,ymm */
@@ -11431,6 +11469,77 @@ int x86_emul_rmw(
 
     return X86EMUL_OKAY;
 }
+
+int x86_emul_blk(
+    void *ptr,
+    void *data,
+    unsigned int bytes,
+    uint32_t *eflags,
+    struct x86_emulate_state *state,
+    struct x86_emulate_ctxt *ctxt)
+{
+    switch ( state->blk )
+    {
+        /*
+         * Throughout this switch(), memory clobbers are used to compensate
+         * that other operands may not properly express the (full) memory
+         * ranges covered.
+         */
+    case blk_movdir:
+        switch ( bytes )
+        {
+#ifdef __x86_64__
+        case sizeof(uint32_t):
+# ifdef HAVE_AS_MOVDIR
+            asm ( "movdiri %0, (%1)"
+                  :: "r" (*(uint32_t *)data), "r" (ptr) : "memory" );
+# else
+            /* movdiri %esi, (%rdi) */
+            asm ( ".byte 0x0f, 0x38, 0xf9, 0x37"
+                  :: "S" (*(uint32_t *)data), "D" (ptr) : "memory" );
+# endif
+            break;
+#endif
+
+        case sizeof(unsigned long):
+#ifdef HAVE_AS_MOVDIR
+            asm ( "movdiri %0, (%1)"
+                  :: "r" (*(unsigned long *)data), "r" (ptr) : "memory" );
+#else
+            /* movdiri %rsi, (%rdi) */
+            asm ( ".byte 0x48, 0x0f, 0x38, 0xf9, 0x37"
+                  :: "S" (*(unsigned long *)data), "D" (ptr) : "memory" );
+#endif
+            break;
+
+        case 64:
+            if ( ((unsigned long)ptr & 0x3f) )
+            {
+                ASSERT_UNREACHABLE();
+                return X86EMUL_UNHANDLEABLE;
+            }
+#ifdef HAVE_AS_MOVDIR
+            asm ( "movdir64b (%0), %1" :: "r" (data), "r" (ptr) : "memory" );
+#else
+            /* movdir64b (%rsi), %rdi */
+            asm ( ".byte 0x66, 0x0f, 0x38, 0xf8, 0x3e"
+                  :: "S" (data), "D" (ptr) : "memory" );
+#endif
+            break;
+
+        default:
+            ASSERT_UNREACHABLE();
+            return X86EMUL_UNHANDLEABLE;
+        }
+        break;
+
+    default:
+        ASSERT_UNREACHABLE();
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    return X86EMUL_OKAY;
+}
 
 static void __init __maybe_unused build_assertions(void)
 {
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -310,6 +310,22 @@ struct x86_emulate_ops
         struct x86_emulate_ctxt *ctxt);
 
     /*
+     * blk: Emulate a large (block) memory access.
+     * @p_data: [IN/OUT] (optional) Pointer to source/destination buffer.
+     * @eflags: [IN/OUT] Pointer to EFLAGS to be updated according to
+     *                   instruction effects.
+     * @state:  [IN/OUT] Pointer to (opaque) emulator state.
+     */
+    int (*blk)(
+        enum x86_segment seg,
+        unsigned long offset,
+        void *p_data,
+        unsigned int bytes,
+        uint32_t *eflags,
+        struct x86_emulate_state *state,
+        struct x86_emulate_ctxt *ctxt);
+
+    /*
      * validate: Post-decode, pre-emulate hook to allow caller controlled
      * filtering.
      */
@@ -793,6 +809,14 @@ x86_emul_rmw(
     unsigned int bytes,
     uint32_t *eflags,
     struct x86_emulate_state *state,
+    struct x86_emulate_ctxt *ctxt);
+int
+x86_emul_blk(
+    void *ptr,
+    void *data,
+    unsigned int bytes,
+    uint32_t *eflags,
+    struct x86_emulate_state *state,
     struct x86_emulate_ctxt *ctxt);
 
 static inline void x86_emul_hw_exception(
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -118,6 +118,8 @@
 #define cpu_has_avx512_bitalg   boot_cpu_has(X86_FEATURE_AVX512_BITALG)
 #define cpu_has_avx512_vpopcntdq boot_cpu_has(X86_FEATURE_AVX512_VPOPCNTDQ)
 #define cpu_has_rdpid           boot_cpu_has(X86_FEATURE_RDPID)
+#define cpu_has_movdiri         boot_cpu_has(X86_FEATURE_MOVDIRI)
+#define cpu_has_movdir64b       boot_cpu_has(X86_FEATURE_MOVDIR64B)
 
 /* CPUID level 0x80000007.edx */
 #define cpu_has_itsc            boot_cpu_has(X86_FEATURE_ITSC)
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -238,6 +238,8 @@ XEN_CPUFEATURE(AVX512_BITALG, 6*32+12) /
 XEN_CPUFEATURE(AVX512_VPOPCNTDQ, 6*32+14) /*A  POPCNT for vectors of DW/QW */
 XEN_CPUFEATURE(RDPID,         6*32+22) /*A  RDPID instruction */
 XEN_CPUFEATURE(CLDEMOTE,      6*32+25) /*A  CLDEMOTE instruction */
+XEN_CPUFEATURE(MOVDIRI,       6*32+27) /*A  MOVDIRI instruction */
+XEN_CPUFEATURE(MOVDIR64B,     6*32+28) /*A  MOVDIR64B instruction */
 
 /* AMD-defined CPU features, CPUID level 0x80000007.edx, word 7 */
 XEN_CPUFEATURE(ITSC,          7*32+ 8) /*   Invariant TSC */



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:12:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:12:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1gr-0005fr-1A; Mon, 27 Apr 2020 11:12:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1gp-0005fb-NG
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:12:43 +0000
X-Inumbo-ID: 037d4c1e-8878-11ea-9760-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 037d4c1e-8878-11ea-9760-12813bfff9fa;
 Mon, 27 Apr 2020 11:12:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 13D87ABE2;
 Mon, 27 Apr 2020 11:12:41 +0000 (UTC)
Subject: [PATCH v7 03/11] x86emul: support ENQCMD insn
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <2ba70a45-25e2-c6e8-371a-8c14dd5f61ec@suse.com>
Date: Mon, 27 Apr 2020 13:12:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Note that the ISA extensions document revision 037 doesn't specify
exception behavior for ModRM.mod == 0b11; assuming #UD here.

No tests are being added to the harness - this would be quite hard,
we can't just issue the insns against RAM. Their similarity with
MOVDIR64B should have the test case there be god enough to cover any
fundamental flaws.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
TBD: This doesn't (can't) consult PASID translation tables yet, as we
     have no VMX code for this so far. I guess for this we will want to
     replace the direct ->read_msr(MSR_IA32_PASID, ...) with a new
     ->read_pasid() hook.
---
v7: Re-base.
v6: Re-base.
v5: New.

--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -48,6 +48,7 @@ $(call as-option-add,CFLAGS,CC,"clwb (%r
 $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1",-DHAVE_AS_QUOTED_SYM)
 $(call as-option-add,CFLAGS,CC,"invpcid (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
 $(call as-option-add,CFLAGS,CC,"movdiri %rax$$(comma)(%rax)",-DHAVE_AS_MOVDIR)
+$(call as-option-add,CFLAGS,CC,"enqcmd (%rax)$$(comma)%rax",-DHAVE_AS_ENQCMD)
 
 # GAS's idea of true is -1.  Clang's idea is 1
 $(call as-option-add,CFLAGS,CC,\
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -855,6 +855,7 @@ struct x86_emulate_state {
     } rmw;
     enum {
         blk_NONE,
+        blk_enqcmd,
         blk_movdir,
     } blk;
     uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
@@ -901,6 +902,7 @@ typedef union {
     uint64_t __attribute__ ((aligned(16))) xmm[2];
     uint64_t __attribute__ ((aligned(32))) ymm[4];
     uint64_t __attribute__ ((aligned(64))) zmm[8];
+    uint32_t data32[16];
 } mmval_t;
 
 /*
@@ -1922,6 +1924,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_rdpid()       (ctxt->cpuid->feat.rdpid)
 #define vcpu_has_movdiri()     (ctxt->cpuid->feat.movdiri)
 #define vcpu_has_movdir64b()   (ctxt->cpuid->feat.movdir64b)
+#define vcpu_has_enqcmd()      (ctxt->cpuid->feat.enqcmd)
 #define vcpu_has_avx512_4vnniw() (ctxt->cpuid->feat.avx512_4vnniw)
 #define vcpu_has_avx512_4fmaps() (ctxt->cpuid->feat.avx512_4fmaps)
 #define vcpu_has_avx512_bf16() (ctxt->cpuid->feat.avx512_bf16)
@@ -10200,6 +10203,36 @@ x86_emulate(
         state->simd_size = simd_none;
         break;
 
+    case X86EMUL_OPC_F2(0x0f38, 0xf8): /* enqcmd r,m512 */
+    case X86EMUL_OPC_F3(0x0f38, 0xf8): /* enqcmds r,m512 */
+        host_and_vcpu_must_have(enqcmd);
+        generate_exception_if(ea.type != OP_MEM, EXC_UD);
+        generate_exception_if(vex.pfx != vex_f2 && !mode_ring0(), EXC_GP, 0);
+        src.val = truncate_ea(*dst.reg);
+        generate_exception_if(!is_aligned(x86_seg_es, src.val, 64, ctxt, ops),
+                              EXC_GP, 0);
+        fail_if(!ops->blk);
+        BUILD_BUG_ON(sizeof(*mmvalp) < 64);
+        if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp, 64,
+                             ctxt)) != X86EMUL_OKAY )
+            goto done;
+        if ( vex.pfx == vex_f2 ) /* enqcmd */
+        {
+            fail_if(!ops->read_msr);
+            if ( (rc = ops->read_msr(MSR_IA32_PASID,
+                                     &msr_val, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            generate_exception_if(!(msr_val & PASID_VALID), EXC_GP, 0);
+            mmvalp->data32[0] = MASK_EXTR(msr_val, PASID_PASID_MASK);
+        }
+        mmvalp->data32[0] &= ~0x7ff00000;
+        state->blk = blk_enqcmd;
+        if ( (rc = ops->blk(x86_seg_es, src.val, mmvalp, 64, &_regs.eflags,
+                            state, ctxt)) != X86EMUL_OKAY )
+            goto done;
+        state->simd_size = simd_none;
+        break;
+
     case X86EMUL_OPC(0x0f38, 0xf9): /* movdiri mem,r */
         host_and_vcpu_must_have(movdiri);
         generate_exception_if(dst.type != OP_MEM, EXC_UD);
@@ -11480,11 +11513,36 @@ int x86_emul_blk(
 {
     switch ( state->blk )
     {
+        bool zf;
+
         /*
          * Throughout this switch(), memory clobbers are used to compensate
          * that other operands may not properly express the (full) memory
          * ranges covered.
          */
+    case blk_enqcmd:
+        ASSERT(bytes == 64);
+        if ( ((unsigned long)ptr & 0x3f) )
+        {
+            ASSERT_UNREACHABLE();
+            return X86EMUL_UNHANDLEABLE;
+        }
+        *eflags &= ~EFLAGS_MASK;
+#ifdef HAVE_AS_ENQCMD
+        asm ( "enqcmds (%[src]), %[dst]" ASM_FLAG_OUT(, "; setz %0")
+              : [zf] ASM_FLAG_OUT("=@ccz", "=qm") (zf)
+              : [src] "r" (data), [dst] "r" (ptr) : "memory" );
+#else
+        /* enqcmds (%rsi), %rdi */
+        asm ( ".byte 0xf3, 0x0f, 0x38, 0xf8, 0x3e"
+              ASM_FLAG_OUT(, "; setz %[zf]")
+              : [zf] ASM_FLAG_OUT("=@ccz", "=qm") (zf)
+              : "S" (data), "D" (ptr) : "memory" );
+#endif
+        if ( zf )
+            *eflags |= X86_EFLAGS_ZF;
+        break;
+
     case blk_movdir:
         switch ( bytes )
         {
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -120,6 +120,7 @@
 #define cpu_has_rdpid           boot_cpu_has(X86_FEATURE_RDPID)
 #define cpu_has_movdiri         boot_cpu_has(X86_FEATURE_MOVDIRI)
 #define cpu_has_movdir64b       boot_cpu_has(X86_FEATURE_MOVDIR64B)
+#define cpu_has_enqcmd          boot_cpu_has(X86_FEATURE_ENQCMD)
 
 /* CPUID level 0x80000007.edx */
 #define cpu_has_itsc            boot_cpu_has(X86_FEATURE_ITSC)
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -420,6 +420,10 @@
 #define MSR_IA32_TSC_DEADLINE		0x000006E0
 #define MSR_IA32_ENERGY_PERF_BIAS	0x000001b0
 
+#define MSR_IA32_PASID			0x00000d93
+#define  PASID_PASID_MASK		0x000fffff
+#define  PASID_VALID			0x80000000
+
 /* Platform Shared Resource MSRs */
 #define MSR_IA32_CMT_EVTSEL		0x00000c8d
 #define MSR_IA32_CMT_EVTSEL_UE_MASK	0x0000ffff
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -240,6 +240,7 @@ XEN_CPUFEATURE(RDPID,         6*32+22) /
 XEN_CPUFEATURE(CLDEMOTE,      6*32+25) /*A  CLDEMOTE instruction */
 XEN_CPUFEATURE(MOVDIRI,       6*32+27) /*A  MOVDIRI instruction */
 XEN_CPUFEATURE(MOVDIR64B,     6*32+28) /*A  MOVDIR64B instruction */
+XEN_CPUFEATURE(ENQCMD,        6*32+29) /*   ENQCMD{,S} instructions */
 
 /* AMD-defined CPU features, CPUID level 0x80000007.edx, word 7 */
 XEN_CPUFEATURE(ITSC,          7*32+ 8) /*   Invariant TSC */



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:13:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:13:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1hZ-0005nX-Ac; Mon, 27 Apr 2020 11:13:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=5iRA=6L=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jT1hY-0005nP-CX
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:13:28 +0000
X-Inumbo-ID: 1e154dba-8878-11ea-9761-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1e154dba-8878-11ea-9761-12813bfff9fa;
 Mon, 27 Apr 2020 11:13:27 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D70CDAE2C;
 Mon, 27 Apr 2020 11:13:25 +0000 (UTC)
Subject: Re: [PATCH v2] docs/designs: re-work the xenstore migration
 document...
To: paul@xen.org, xen-devel@lists.xenproject.org
References: <20200427075342.149-1-paul@xen.org>
 <6004fb95-42e1-1ee3-5215-0d0dede73f0f@suse.com>
 <000a01d61c80$fd1e47a0$f75ad6e0$@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <ff0a5505-77aa-905b-7b77-af418a586a47@suse.com>
Date: Mon, 27 Apr 2020 13:13:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <000a01d61c80$fd1e47a0$f75ad6e0$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Paul Durrant' <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.20 12:45, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jürgen Groß <jgross@suse.com>
>> Sent: 27 April 2020 11:37
>> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
>> Cc: Paul Durrant <pdurrant@amazon.com>
>> Subject: Re: [PATCH v2] docs/designs: re-work the xenstore migration document...
>>
>> On 27.04.20 09:53, Paul Durrant wrote:
>>> From: Paul Durrant <pdurrant@amazon.com>
>>>
>>> ... to specify a separate migration stream that will also be suitable for
>>> live update.
>>>
>>> The original scope of the document was to support non-cooperative migration
>>> of guests [1] but, since then, live update of xenstored has been brought into
>>> scope. Thus it makes more sense to define a separate image format for
>>> serializing xenstore state that is suitable for both purposes.
>>>
>>> The document has been limited to specifying a new image format. The mechanism
>>> for acquiring the image for live update or migration is not covered as that
>>> is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
>>> also expected that, when the first implementation of live update or migration
>>> making use of this specification is committed, that the document is moved from
>>> docs/designs into docs/specs.
>>>
>>> [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
>>>
>>> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
>>> ---
>>> Juergen Gross <jgross@suse.com>
>>> Andrew Cooper <andrew.cooper3@citrix.com>
>>> George Dunlap <george.dunlap@citrix.com>
>>> Ian Jackson <ian.jackson@eu.citrix.com>
>>> Jan Beulich <jbeulich@suse.com>
>>> Julien Grall <julien@xen.org>
>>> Stefano Stabellini <sstabellini@kernel.org>
>>> Wei Liu <wl@xen.org>
>>
>> Mind adding CC: before those mail addresses in order to let git add
>> those to the recipients list?
>>
> 
> D'oh... good spot.
> 
>>>
>>> v2:
>>>    - Address comments from Juergen
>>
>> Not all unfortunately. :-(
>>
> 
> OK.
> 
>>> +### CONNECTION_DATA
>>>
>>> -Each WATCH_DATA record specifies a registered watch and is formatted as
>>> -follows:
>>> +For live update the image format will contain a `CONNECTION_DATA` record for
>>> +each connection to xenstore. For migration it will only contain a record for
>>> +the domain being migrated.
>>>
>>>
>>>    ```
>>> -    0       1       2       3     octet
>>> -+-------+-------+-------+-------+
>>> -| WATCH_DATA                    |
>>> -+-------------------------------+
>>> -| wpath length                  |
>>> -+-------------------------------+
>>> -| wpath data                    |
>>> -...
>>> -| pad (0 to 3 octets)           |
>>> -+-------------------------------+
>>> +    0       1       2       3       4       5       6       7    octet
>>> ++-------+-------+-------+-------+-------+-------+-------+-------+
>>> +| conn-id                       | pad                           |
>>> ++---------------+-----------------------------------------------+
>>> +| conn-type     | conn-spec
>>>    ...
>>
>> I asked whether it wouldn't be better to drop the pad and move conn-type
>> and a 2-byte (unified) flag field at its position. This together ...
>>
>>> ++-------------------------------+-------------------------------+
>>> +| data-len                      | data
>>>    +-------------------------------+
>>> -| token length                  |
>>> -+-------------------------------+
>>> -| token data                    |
>>>    ...
>>> -| pad (0 to 3 octets)           |
>>> -+-------------------------------+
>>>    ```
>>>
>>> -wpath length and token length are specified in octets (excluding the NUL
>>> -terminator). The wpath should be as described for the `WATCH` operation in
>>> -[2]. The token is an arbitrary string of octets not containing any NUL
>>> -values.
>>>
>>> +| Field       | Description                                     |
>>> +|-------------|-------------------------------------------------|
>>> +| `conn-id`   | A non-zero number used to identify this         |
>>> +|             | connection in subsequent connection-specific    |
>>> +|             | records                                         |
>>> +|             |                                                 |
>>> +| `conn-type` | 0x0000: shared ring                             |
>>> +|             | 0x0001: socket                                  |
>>> +|             |                                                 |
>>> +| `conn-spec` | See below                                       |
>>> +|             |                                                 |
>>> +| `data-len`  | The length (in octets) of any pending data not  |
>>> +|             | yet written to the connection                   |
>>> +|             |                                                 |
>>> +| `data`      | Pending data (may be empty)                     |
>>>
>>> -**TRANSACTION_DATA**
>>> +The format of `conn-spec` is dependent upon `conn-type`.
>>>
>>> +\pagebreak
>>>
>>> -Each TRANSACTION_DATA record specifies an open transaction and is formatted
>>> -as follows:
>>> +For `shared ring` connections it is as follows:
>>>
>>>
>>>    ```
>>> -    0       1       2       3     octet
>>> -+-------+-------+-------+-------+
>>> -| TRANSACTION_DATA              |
>>> -+-------------------------------+
>>> -| tx_id                         |
>>> -+-------------------------------+
>>> +    0       1       2       3       4       5       6       7    octet
>>> +                +-------+-------+-------+-------+-------+-------+
>>> +                | domid         | tdomid        | flags         |
>>> ++---------------+---------------+---------------+---------------+
>>> +| revtchn                       | levtchn                       |
>>> ++-------------------------------+-------------------------------+
>>> +| mfn                                                           |
>>> ++---------------------------------------------------------------+
>>
>> ... with dropping levtchn (which isn't needed IMO) will make it much
>> easier to have a union in C (which needs to be aligned to 8 bytes
>> and have a length of a multiple of 8 bytes due to mfn).
>>
>> So something like:
>>
>> struct xs_state_connection {
>>       uint32_t conn_id;
>>       uint16_t conn_type;
>> #define XS_STATE_CONN_TYPE_RING   0
>> #define XS_STATE_CONN_TYPE_SOCKET 1
>>       uint16_t flags;
>> #define XS_STATE_CONN_INTRODUCED  0x0001
>> #define XS_STATE_CONN_RELEASED    0x0002
>> #define XS_STATE_CONN_READONLY    0x0004
>>       union {
>>           struct {
>>               uint16_t domid;
>>               uint16_t tdomid;
>> #define XS_STATE_DOMID_INVALID  0xffffU
>>               uint32_t evtchn;
>>               uint64_t mfn;
>> #define XS_STATE_MFN_INVALID    0xffffffffffffffffUL
>>           } ring;
>>           int32_t socket_fd;
>>       } spec;
>>       uint32_t data_out_len;
>>       uint8_t  data[];
>> };
> 
> The issue is making sure that the mfn is properly aligned. If I can drop the levtchn then this gets easier.
> 
>>
>>>    ```
>>>
>>> -where tx_id is the non-zero identifier values of an open transaction.
>>> -
>>>
>>> -### Protocol Extension
>>> +| Field      | Description                                      |
>>> +|------------|--------------------------------------------------|
>>> +| `domid`    | The domain-id that owns the shared page          |
>>> +|            |                                                  |
>>> +| `tdomid`   | The domain-id that `domid` acts on behalf of if  |
>>> +|            | it has been subject to an SET_TARGET             |
>>> +|            | operation [2] or DOMID_INVALID otherwise         |
>>
>> DOMID_INVALID needs to be defined (or we need a reference where it is
>> coming from).
> 
> OK. It's in a public header... I'll reference it.
> 
>>
>>> +|            |                                                  |
>>> +| `flags`    | A bit-wise OR of:                                |
>>> +|            | 0x0001: INTRODUCE has been issued                |

Just realized, I think we can drop those flags.

Reasoning: if INTRODUCE hasn't been issued, there can't be an active
connection to Xenstore for that domain, as Xenstore doesn't know about
the parameters to connect (especially the event channel is missing).

>>> +|            | 0x0002: RELEASE has been issued                  |

And the same applies here: RELEASE will drop the connection to the
domain, so it can't appear in a connection record.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:14:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:14:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1i8-0005st-OE; Mon, 27 Apr 2020 11:14:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1i7-0005sg-EE
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:14:03 +0000
X-Inumbo-ID: 32edfb1b-8878-11ea-9761-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 32edfb1b-8878-11ea-9761-12813bfff9fa;
 Mon, 27 Apr 2020 11:14:02 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id AB6BBAC69;
 Mon, 27 Apr 2020 11:14:00 +0000 (UTC)
Subject: [PATCH v7 04/11] x86emul: support SERIALIZE
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <e1437bfa-1f02-87ad-e22c-9ca00e43610d@suse.com>
Date: Mon, 27 Apr 2020 13:13:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

... enabling its use by all guest kinds at the same time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v7: Re-base.
v6: New.

--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -214,6 +214,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
         {"avx512-4vnniw",0x00000007,  0, CPUID_REG_EDX,  2,  1},
         {"avx512-4fmaps",0x00000007,  0, CPUID_REG_EDX,  3,  1},
         {"md-clear",     0x00000007,  0, CPUID_REG_EDX, 10,  1},
+        {"serialize",    0x00000007,  0, CPUID_REG_EDX, 14,  1},
         {"cet-ibt",      0x00000007,  0, CPUID_REG_EDX, 20,  1},
         {"ibrsb",        0x00000007,  0, CPUID_REG_EDX, 26,  1},
         {"stibp",        0x00000007,  0, CPUID_REG_EDX, 27,  1},
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -161,6 +161,7 @@ static const char *const str_7d0[32] =
 
     [10] = "md-clear",
     /* 12 */                [13] = "tsx-force-abort",
+    [14] = "serialize",
 
     [18] = "pconfig",
     [20] = "cet-ibt",
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -158,6 +158,7 @@ static inline bool xcr0_mask(uint64_t ma
 #define cpu_has_movdir64b  cp.feat.movdir64b
 #define cpu_has_avx512_4vnniw (cp.feat.avx512_4vnniw && xcr0_mask(0xe6))
 #define cpu_has_avx512_4fmaps (cp.feat.avx512_4fmaps && xcr0_mask(0xe6))
+#define cpu_has_serialize  cp.feat.serialize
 #define cpu_has_avx512_bf16 (cp.feat.avx512_bf16 && xcr0_mask(0xe6))
 
 #define cpu_has_xgetbv1   (cpu_has_xsave && cp.xstate.xgetbv1)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1927,6 +1927,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_enqcmd()      (ctxt->cpuid->feat.enqcmd)
 #define vcpu_has_avx512_4vnniw() (ctxt->cpuid->feat.avx512_4vnniw)
 #define vcpu_has_avx512_4fmaps() (ctxt->cpuid->feat.avx512_4fmaps)
+#define vcpu_has_serialize()   (ctxt->cpuid->feat.serialize)
 #define vcpu_has_avx512_bf16() (ctxt->cpuid->feat.avx512_bf16)
 
 #define vcpu_must_have(feat) \
@@ -5660,6 +5661,18 @@ x86_emulate(
                 goto done;
             break;
 
+        case 0xe8:
+            switch ( vex.pfx )
+            {
+            case vex_none: /* serialize */
+                host_and_vcpu_must_have(serialize);
+                asm volatile ( ".byte 0x0f, 0x01, 0xe8" );
+                break;
+            default:
+                goto unimplemented_insn;
+            }
+            break;
+
         case 0xf8: /* swapgs */
             generate_exception_if(!mode_64bit(), EXC_UD);
             generate_exception_if(!mode_ring0(), EXC_GP, 0);
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -129,6 +129,7 @@
 #define cpu_has_avx512_4vnniw   boot_cpu_has(X86_FEATURE_AVX512_4VNNIW)
 #define cpu_has_avx512_4fmaps   boot_cpu_has(X86_FEATURE_AVX512_4FMAPS)
 #define cpu_has_tsx_force_abort boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)
+#define cpu_has_serialize       boot_cpu_has(X86_FEATURE_SERIALIZE)
 
 /* CPUID level 0x00000007:1.eax */
 #define cpu_has_avx512_bf16     boot_cpu_has(X86_FEATURE_AVX512_BF16)
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -258,6 +258,7 @@ XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /
 XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation Single Precision */
 XEN_CPUFEATURE(MD_CLEAR,      9*32+10) /*A  VERW clears microarchitectural buffers */
 XEN_CPUFEATURE(TSX_FORCE_ABORT, 9*32+13) /* MSR_TSX_FORCE_ABORT.RTM_ABORT */
+XEN_CPUFEATURE(SERIALIZE,     9*32+14) /*A  SERIALIZE insn */
 XEN_CPUFEATURE(CET_IBT,       9*32+20) /*   CET - Indirect Branch Tracking */
 XEN_CPUFEATURE(IBRSB,         9*32+26) /*A  IBRS and IBPB support (used by Intel) */
 XEN_CPUFEATURE(STIBP,         9*32+27) /*A  STIBP */



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:14:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1iW-0005xA-1E; Mon, 27 Apr 2020 11:14:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1iU-0005wo-Lr
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:14:26 +0000
X-Inumbo-ID: 40f9c7f2-8878-11ea-9761-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 40f9c7f2-8878-11ea-9761-12813bfff9fa;
 Mon, 27 Apr 2020 11:14:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 60DD7ADE3;
 Mon, 27 Apr 2020 11:14:24 +0000 (UTC)
Subject: [PATCH v7 05/11] x86emul: support X{SUS,RES}LDTRK
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <53feebc9-4596-0698-486a-219c97b0580d@suse.com>
Date: Mon, 27 Apr 2020 13:14:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

There's nothing to be done by the emulator, as we unconditionally abort
any XBEGIN.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v6: New.

--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -208,6 +208,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
         {"avx512-vnni",  0x00000007,  0, CPUID_REG_ECX, 11,  1},
         {"avx512-bitalg",0x00000007,  0, CPUID_REG_ECX, 12,  1},
         {"avx512-vpopcntdq",0x00000007,0,CPUID_REG_ECX, 14,  1},
+        {"tsxldtrk",     0x00000007,  0, CPUID_REG_ECX, 16,  1},
         {"rdpid",        0x00000007,  0, CPUID_REG_ECX, 22,  1},
         {"cldemote",     0x00000007,  0, CPUID_REG_ECX, 25,  1},
 
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -128,6 +128,7 @@ static const char *const str_7c0[32] =
     [10] = "vpclmulqdq",       [11] = "avx512_vnni",
     [12] = "avx512_bitalg",
     [14] = "avx512_vpopcntdq",
+    [16] = "tsxldtrk",
 
     [22] = "rdpid",
     /* 24 */                   [25] = "cldemote",
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1921,6 +1921,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_avx512_vnni() (ctxt->cpuid->feat.avx512_vnni)
 #define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
 #define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
+#define vcpu_has_tsxldtrk()    (ctxt->cpuid->feat.tsxldtrk)
 #define vcpu_has_rdpid()       (ctxt->cpuid->feat.rdpid)
 #define vcpu_has_movdiri()     (ctxt->cpuid->feat.movdiri)
 #define vcpu_has_movdir64b()   (ctxt->cpuid->feat.movdir64b)
@@ -5668,6 +5669,20 @@ x86_emulate(
                 host_and_vcpu_must_have(serialize);
                 asm volatile ( ".byte 0x0f, 0x01, 0xe8" );
                 break;
+            case vex_f2: /* xsusldtrk */
+                vcpu_must_have(tsxldtrk);
+                break;
+            default:
+                goto unimplemented_insn;
+            }
+            break;
+
+        case 0xe9:
+            switch ( vex.pfx )
+            {
+            case vex_f2: /* xresldtrk */
+                vcpu_must_have(tsxldtrk);
+                break;
             default:
                 goto unimplemented_insn;
             }
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -236,6 +236,7 @@ XEN_CPUFEATURE(VPCLMULQDQ,    6*32+10) /
 XEN_CPUFEATURE(AVX512_VNNI,   6*32+11) /*A  Vector Neural Network Instrs */
 XEN_CPUFEATURE(AVX512_BITALG, 6*32+12) /*A  Support for VPOPCNT[B,W] and VPSHUFBITQMB */
 XEN_CPUFEATURE(AVX512_VPOPCNTDQ, 6*32+14) /*A  POPCNT for vectors of DW/QW */
+XEN_CPUFEATURE(TSXLDTRK,      6*32+16) /*A  TSX load tracking suspend/resume insns */
 XEN_CPUFEATURE(RDPID,         6*32+22) /*A  RDPID instruction */
 XEN_CPUFEATURE(CLDEMOTE,      6*32+25) /*A  CLDEMOTE instruction */
 XEN_CPUFEATURE(MOVDIRI,       6*32+27) /*A  MOVDIRI instruction */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -284,6 +284,9 @@ def crunch_numbers(state):
         # as dependent features simplifies Xen's logic, and prevents the guest
         # from seeing implausible configurations.
         IBRSB: [STIBP, SSBD],
+
+        # In principle the TSXLDTRK insns could also be considered independent.
+        RTM: [TSXLDTRK],
     }
 
     deep_features = tuple(sorted(deps.keys()))



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:14:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:14:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1iz-00062N-Ae; Mon, 27 Apr 2020 11:14:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1iy-00062D-Gk
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:14:56 +0000
X-Inumbo-ID: 527ae830-8878-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 527ae830-8878-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 11:14:55 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C39AAABE2;
 Mon, 27 Apr 2020 11:14:53 +0000 (UTC)
Subject: [PATCH v7 06/11] x86emul: support FNSTENV and FNSAVE
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <f60987c4-c4b0-9e43-00b9-8ecc0d5d2594@suse.com>
Date: Mon, 27 Apr 2020 13:14:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

To avoid introducing another boolean into emulator state, the
rex_prefix field gets (ab)used to convey the real/VM86 vs protected mode
info (affecting structure layout, albeit not size) to x86_emul_blk().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
TBD: The full 16-bit padding fields in the 32-bit structures get filled
     with all ones by modern CPUs (i.e. other than the comment says for
     FIP and FDP). We may want to mirror this as well (for the real mode
     variant), even if those fields' contents are unspecified.
---
v7: New.

--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -120,6 +120,7 @@ static inline bool xcr0_mask(uint64_t ma
 }
 
 #define cache_line_size() (cp.basic.clflush_size * 8)
+#define cpu_has_fpu        cp.basic.fpu
 #define cpu_has_mmx        cp.basic.mmx
 #define cpu_has_fxsr       cp.basic.fxsr
 #define cpu_has_sse        cp.basic.sse
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -748,6 +748,25 @@ static struct x86_emulate_ops emulops =
 
 #define MMAP_ADDR 0x100000
 
+/*
+ * 64-bit OSes may not (be able to) properly restore the two selectors in
+ * the FPU environment. Zap them so that memcmp() on two saved images will
+ * work regardless of whether a context switch occurred in the middle.
+ */
+static void zap_fpsel(unsigned int *env, bool is_32bit)
+{
+    if ( is_32bit )
+    {
+        env[4] &= ~0xffff;
+        env[6] &= ~0xffff;
+    }
+    else
+    {
+        env[2] &= ~0xffff;
+        env[3] &= ~0xffff;
+    }
+}
+
 #ifdef __x86_64__
 # define STKVAL_DISP 64
 static const struct {
@@ -2394,6 +2413,62 @@ int main(int argc, char **argv)
         printf("okay\n");
     }
     else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing fnstenv 4(%ecx)...");
+    if ( stack_exec && cpu_has_fpu )
+    {
+        const uint16_t three = 3;
+
+        asm volatile ( "fninit\n\t"
+                       "fld1\n\t"
+                       "fidivs %1\n\t"
+                       "fstenv %0"
+                       : "=m" (res[9]) : "m" (three) : "memory" );
+        zap_fpsel(&res[9], true);
+        instr[0] = 0xd9; instr[1] = 0x71; instr[2] = 0x04;
+        regs.eip = (unsigned long)&instr[0];
+        regs.ecx = (unsigned long)res;
+        res[8] = 0xaa55aa55;
+        rc = x86_emulate(&ctxt, &emulops);
+        zap_fpsel(&res[1], true);
+        if ( (rc != X86EMUL_OKAY) ||
+             memcmp(res + 1, res + 9, 28) ||
+             res[8] != 0xaa55aa55 ||
+             (regs.eip != (unsigned long)&instr[3]) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing 16-bit fnsave (%ecx)...");
+    if ( stack_exec && cpu_has_fpu )
+    {
+        const uint16_t five = 5;
+
+        asm volatile ( "fninit\n\t"
+                       "fld1\n\t"
+                       "fidivs %1\n\t"
+                       "fsaves %0"
+                       : "=m" (res[25]) : "m" (five) : "memory" );
+        zap_fpsel(&res[25], false);
+        asm volatile ( "frstors %0" :: "m" (res[25]) : "memory" );
+        instr[0] = 0x66; instr[1] = 0xdd; instr[2] = 0x31;
+        regs.eip = (unsigned long)&instr[0];
+        regs.ecx = (unsigned long)res;
+        res[23] = 0xaa55aa55;
+        res[24] = 0xaa55aa55;
+        rc = x86_emulate(&ctxt, &emulops);
+        if ( (rc != X86EMUL_OKAY) ||
+             memcmp(res, res + 25, 94) ||
+             (res[23] >> 16) != 0xaa55 ||
+             res[24] != 0xaa55aa55 ||
+             (regs.eip != (unsigned long)&instr[3]) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
         printf("skipped\n");
 
     printf("%-40s", "Testing movq %mm3,(%ecx)...");
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -856,6 +856,9 @@ struct x86_emulate_state {
     enum {
         blk_NONE,
         blk_enqcmd,
+#ifndef X86EMUL_NO_FPU
+        blk_fst, /* FNSTENV, FNSAVE */
+#endif
         blk_movdir,
     } blk;
     uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
@@ -897,6 +900,50 @@ struct x86_emulate_state {
 #define PTR_POISON NULL /* 32-bit builds are for user-space, so NULL is OK. */
 #endif
 
+#ifndef X86EMUL_NO_FPU
+struct x87_env16 {
+    uint16_t fcw;
+    uint16_t fsw;
+    uint16_t ftw;
+    union {
+        struct {
+            uint16_t fip_lo;
+            uint16_t fop:11, :1, fip_hi:4;
+            uint16_t fdp_lo;
+            uint16_t :12, fdp_hi:4;
+        } real;
+        struct {
+            uint16_t fip;
+            uint16_t fcs;
+            uint16_t fdp;
+            uint16_t fds;
+        } prot;
+    } mode;
+};
+
+struct x87_env32 {
+    uint32_t fcw:16, :16;
+    uint32_t fsw:16, :16;
+    uint32_t ftw:16, :16;
+    union {
+        struct {
+            /* some CPUs/FPUs also store the full FIP here */
+            uint32_t fip_lo:16, :16;
+            uint32_t fop:11, :1, fip_hi:16, :4;
+            /* some CPUs/FPUs also store the full FDP here */
+            uint32_t fdp_lo:16, :16;
+            uint32_t :12, fdp_hi:16, :4;
+        } real;
+        struct {
+            uint32_t fip;
+            uint32_t fcs:16, fop:11, :5;
+            uint32_t fdp;
+            uint32_t fds:16, :16;
+        } prot;
+    } mode;
+};
+#endif
+
 typedef union {
     uint64_t mmx;
     uint64_t __attribute__ ((aligned(16))) xmm[2];
@@ -4912,9 +4959,19 @@ x86_emulate(
                     goto done;
                 emulate_fpu_insn_memsrc(b, modrm_reg & 7, src.val);
                 break;
-            case 6: /* fnstenv - TODO */
+            case 6: /* fnstenv */
+                fail_if(!ops->blk);
+                state->blk = blk_fst;
+                /* REX is meaningless for this insn by this point. */
+                rex_prefix = in_protmode(ctxt, ops);
+                if ( (rc = ops->blk(ea.mem.seg, ea.mem.off, NULL,
+                                    op_bytes > 2 ? sizeof(struct x87_env32)
+                                                 : sizeof(struct x87_env16),
+                                    &_regs.eflags,
+                                    state, ctxt)) != X86EMUL_OKAY )
+                    goto done;
                 state->fpu_ctrl = true;
-                goto unimplemented_insn;
+                break;
             case 7: /* fnstcw m2byte */
                 state->fpu_ctrl = true;
             fpu_memdst16:
@@ -5068,9 +5125,21 @@ x86_emulate(
                 emulate_fpu_insn_memdst(b, modrm_reg & 7, dst.val);
                 break;
             case 4: /* frstor - TODO */
-            case 6: /* fnsave - TODO */
                 state->fpu_ctrl = true;
                 goto unimplemented_insn;
+            case 6: /* fnsave */
+                fail_if(!ops->blk);
+                state->blk = blk_fst;
+                /* REX is meaningless for this insn by this point. */
+                rex_prefix = in_protmode(ctxt, ops);
+                if ( (rc = ops->blk(ea.mem.seg, ea.mem.off, NULL,
+                                    op_bytes > 2 ? sizeof(struct x87_env32) + 80
+                                                 : sizeof(struct x87_env16) + 80,
+                                    &_regs.eflags,
+                                    state, ctxt)) != X86EMUL_OKAY )
+                    goto done;
+                state->fpu_ctrl = true;
+                break;
             case 7: /* fnstsw m2byte */
                 state->fpu_ctrl = true;
                 goto fpu_memdst16;
@@ -11542,6 +11611,12 @@ int x86_emul_blk(
     switch ( state->blk )
     {
         bool zf;
+        struct {
+            struct x87_env32 env;
+            struct {
+               uint8_t bytes[10];
+            } freg[8];
+        } fpstate;
 
         /*
          * Throughout this switch(), memory clobbers are used to compensate
@@ -11571,6 +11646,91 @@ int x86_emul_blk(
             *eflags |= X86_EFLAGS_ZF;
         break;
 
+#ifndef X86EMUL_NO_FPU
+    case blk_fst:
+        ASSERT(!data);
+
+        if ( bytes > sizeof(fpstate.env) )
+            asm ( "fnsave %0" : "=m" (fpstate) );
+        else
+            asm ( "fnstenv %0" : "=m" (fpstate.env) );
+
+        /* state->rex_prefix carries CR0.PE && !EFLAGS.VM setting */
+        switch ( bytes )
+        {
+        case sizeof(fpstate.env):
+        case sizeof(fpstate):
+            if ( !state->rex_prefix )
+            {
+                unsigned int fip = fpstate.env.mode.prot.fip +
+                                   (fpstate.env.mode.prot.fcs << 4);
+                unsigned int fdp = fpstate.env.mode.prot.fdp +
+                                   (fpstate.env.mode.prot.fds << 4);
+                unsigned int fop = fpstate.env.mode.prot.fop;
+
+                memset(&fpstate.env.mode, 0, sizeof(fpstate.env.mode));
+                fpstate.env.mode.real.fip_lo = fip;
+                fpstate.env.mode.real.fip_hi = fip >> 16;
+                fpstate.env.mode.real.fop = fop;
+                fpstate.env.mode.real.fdp_lo = fdp;
+                fpstate.env.mode.real.fdp_hi = fdp >> 16;
+            }
+            memcpy(ptr, &fpstate.env, sizeof(fpstate.env));
+            if ( bytes == sizeof(fpstate.env) )
+                ptr = NULL;
+            else
+                ptr += sizeof(fpstate.env);
+            break;
+
+        case sizeof(struct x87_env16):
+        case sizeof(struct x87_env16) + sizeof(fpstate.freg):
+            if ( state->rex_prefix )
+            {
+                struct x87_env16 *env = ptr;
+
+                env->fcw = fpstate.env.fcw;
+                env->fsw = fpstate.env.fsw;
+                env->ftw = fpstate.env.ftw;
+                env->mode.prot.fip = fpstate.env.mode.prot.fip;
+                env->mode.prot.fcs = fpstate.env.mode.prot.fcs;
+                env->mode.prot.fdp = fpstate.env.mode.prot.fdp;
+                env->mode.prot.fds = fpstate.env.mode.prot.fds;
+            }
+            else
+            {
+                unsigned int fip = fpstate.env.mode.prot.fip +
+                                   (fpstate.env.mode.prot.fcs << 4);
+                unsigned int fdp = fpstate.env.mode.prot.fdp +
+                                   (fpstate.env.mode.prot.fds << 4);
+                struct x87_env16 env = {
+                    .fcw = fpstate.env.fcw,
+                    .fsw = fpstate.env.fsw,
+                    .ftw = fpstate.env.ftw,
+                    .mode.real.fip_lo = fip,
+                    .mode.real.fip_hi = fip >> 16,
+                    .mode.real.fop = fpstate.env.mode.prot.fop,
+                    .mode.real.fdp_lo = fdp,
+                    .mode.real.fdp_hi = fdp >> 16
+                };
+
+                memcpy(ptr, &env, sizeof(env));
+            }
+            if ( bytes == sizeof(struct x87_env16) )
+                ptr = NULL;
+            else
+                ptr += sizeof(struct x87_env16);
+            break;
+
+        default:
+            ASSERT_UNREACHABLE();
+            return X86EMUL_UNHANDLEABLE;
+        }
+
+        if ( ptr )
+            memcpy(ptr, fpstate.freg, sizeof(fpstate.freg));
+        break;
+#endif
+
     case blk_movdir:
         switch ( bytes )
         {



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:15:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1jK-00067D-Ki; Mon, 27 Apr 2020 11:15:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1jJ-00066w-7N
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:15:17 +0000
X-Inumbo-ID: 5ef45d44-8878-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5ef45d44-8878-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 11:15:16 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id ACB24AC5F;
 Mon, 27 Apr 2020 11:15:14 +0000 (UTC)
Subject: [PATCH v7 07/11] x86emul: support FLDENV and FRSTOR
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <57961e56-49eb-3347-b315-ada999bab89f@suse.com>
Date: Mon, 27 Apr 2020 13:15:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While the Intel SDM claims that FRSTOR itself may raise #MF upon
completion, this was confirmed by Intel to be a doc error which will be
corrected in due course; behavior is like FLDENV, and like old hard copy
manuals describe it. Otherwise we'd have to emulate the insn by filling
st(N) in suitable order, followed by FLDENV.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v7: New.

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -2442,6 +2442,27 @@ int main(int argc, char **argv)
     else
         printf("skipped\n");
 
+    printf("%-40s", "Testing fldenv 8(%edx)...");
+    if ( stack_exec && cpu_has_fpu )
+    {
+        asm volatile ( "fnstenv %0\n\t"
+                       "fninit"
+                       : "=m" (res[2]) :: "memory" );
+        zap_fpsel(&res[2], true);
+        instr[0] = 0xd9; instr[1] = 0x62; instr[2] = 0x08;
+        regs.eip = (unsigned long)&instr[0];
+        regs.edx = (unsigned long)res;
+        rc = x86_emulate(&ctxt, &emulops);
+        asm volatile ( "fnstenv %0" : "=m" (res[9]) :: "memory" );
+        if ( (rc != X86EMUL_OKAY) ||
+             memcmp(res + 2, res + 9, 28) ||
+             (regs.eip != (unsigned long)&instr[3]) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
     printf("%-40s", "Testing 16-bit fnsave (%ecx)...");
     if ( stack_exec && cpu_has_fpu )
     {
@@ -2468,6 +2489,31 @@ int main(int argc, char **argv)
             goto fail;
         printf("okay\n");
     }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing frstor (%edx)...");
+    if ( stack_exec && cpu_has_fpu )
+    {
+        const uint16_t seven = 7;
+
+        asm volatile ( "fninit\n\t"
+                       "fld1\n\t"
+                       "fidivs %1\n\t"
+                       "fnsave %0\n\t"
+                       : "=&m" (res[0]) : "m" (seven) : "memory" );
+        zap_fpsel(&res[0], true);
+        instr[0] = 0xdd; instr[1] = 0x22;
+        regs.eip = (unsigned long)&instr[0];
+        regs.edx = (unsigned long)res;
+        rc = x86_emulate(&ctxt, &emulops);
+        asm volatile ( "fnsave %0" : "=m" (res[27]) :: "memory" );
+        if ( (rc != X86EMUL_OKAY) ||
+             memcmp(res, res + 27, 108) ||
+             (regs.eip != (unsigned long)&instr[2]) )
+            goto fail;
+        printf("okay\n");
+    }
     else
         printf("skipped\n");
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -857,6 +857,7 @@ struct x86_emulate_state {
         blk_NONE,
         blk_enqcmd,
 #ifndef X86EMUL_NO_FPU
+        blk_fld, /* FLDENV, FRSTOR */
         blk_fst, /* FNSTENV, FNSAVE */
 #endif
         blk_movdir,
@@ -4948,21 +4949,14 @@ x86_emulate(
                 dst.bytes = 4;
                 emulate_fpu_insn_memdst(b, modrm_reg & 7, dst.val);
                 break;
-            case 4: /* fldenv - TODO */
-                state->fpu_ctrl = true;
-                goto unimplemented_insn;
-            case 5: /* fldcw m2byte */
-                state->fpu_ctrl = true;
-            fpu_memsrc16:
-                if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
-                                     2, ctxt)) != X86EMUL_OKAY )
-                    goto done;
-                emulate_fpu_insn_memsrc(b, modrm_reg & 7, src.val);
-                break;
+            case 4: /* fldenv */
+                /* Raise #MF now if there are pending unmasked exceptions. */
+                emulate_fpu_insn_stub(0xd9, 0xd0 /* fnop */);
+                /* fall through */
             case 6: /* fnstenv */
                 fail_if(!ops->blk);
-                state->blk = blk_fst;
-                /* REX is meaningless for this insn by this point. */
+                state->blk = modrm_reg & 2 ? blk_fst : blk_fld;
+                /* REX is meaningless for these insns by this point. */
                 rex_prefix = in_protmode(ctxt, ops);
                 if ( (rc = ops->blk(ea.mem.seg, ea.mem.off, NULL,
                                     op_bytes > 2 ? sizeof(struct x87_env32)
@@ -4972,6 +4966,14 @@ x86_emulate(
                     goto done;
                 state->fpu_ctrl = true;
                 break;
+            case 5: /* fldcw m2byte */
+                state->fpu_ctrl = true;
+            fpu_memsrc16:
+                if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+                                     2, ctxt)) != X86EMUL_OKAY )
+                    goto done;
+                emulate_fpu_insn_memsrc(b, modrm_reg & 7, src.val);
+                break;
             case 7: /* fnstcw m2byte */
                 state->fpu_ctrl = true;
             fpu_memdst16:
@@ -5124,13 +5126,14 @@ x86_emulate(
                 dst.bytes = 8;
                 emulate_fpu_insn_memdst(b, modrm_reg & 7, dst.val);
                 break;
-            case 4: /* frstor - TODO */
-                state->fpu_ctrl = true;
-                goto unimplemented_insn;
+            case 4: /* frstor */
+                /* Raise #MF now if there are pending unmasked exceptions. */
+                emulate_fpu_insn_stub(0xd9, 0xd0 /* fnop */);
+                /* fall through */
             case 6: /* fnsave */
                 fail_if(!ops->blk);
-                state->blk = blk_fst;
-                /* REX is meaningless for this insn by this point. */
+                state->blk = modrm_reg & 2 ? blk_fst : blk_fld;
+                /* REX is meaningless for these insns by this point. */
                 rex_prefix = in_protmode(ctxt, ops);
                 if ( (rc = ops->blk(ea.mem.seg, ea.mem.off, NULL,
                                     op_bytes > 2 ? sizeof(struct x87_env32) + 80
@@ -11647,6 +11650,89 @@ int x86_emul_blk(
         break;
 
 #ifndef X86EMUL_NO_FPU
+    case blk_fld:
+        ASSERT(!data);
+
+        /* state->rex_prefix carries CR0.PE && !EFLAGS.VM setting */
+        switch ( bytes )
+        {
+        case sizeof(fpstate.env):
+        case sizeof(fpstate):
+            memcpy(&fpstate.env, ptr, sizeof(fpstate.env));
+            if ( !state->rex_prefix )
+            {
+                unsigned int fip = fpstate.env.mode.real.fip_lo +
+                                   (fpstate.env.mode.real.fip_hi << 16);
+                unsigned int fdp = fpstate.env.mode.real.fdp_lo +
+                                   (fpstate.env.mode.real.fdp_hi << 16);
+                unsigned int fop = fpstate.env.mode.real.fop;
+
+                fpstate.env.mode.prot.fip = fip & 0xf;
+                fpstate.env.mode.prot.fcs = fip >> 4;
+                fpstate.env.mode.prot.fop = fop;
+                fpstate.env.mode.prot.fdp = fdp & 0xf;
+                fpstate.env.mode.prot.fds = fdp >> 4;
+            }
+
+            if ( bytes == sizeof(fpstate.env) )
+                ptr = NULL;
+            else
+                ptr += sizeof(fpstate.env);
+            break;
+
+        case sizeof(struct x87_env16):
+        case sizeof(struct x87_env16) + sizeof(fpstate.freg):
+        {
+            const struct x87_env16 *env = ptr;
+
+            fpstate.env.fcw = env->fcw;
+            fpstate.env.fsw = env->fsw;
+            fpstate.env.ftw = env->ftw;
+
+            if ( state->rex_prefix )
+            {
+                fpstate.env.mode.prot.fip = env->mode.prot.fip;
+                fpstate.env.mode.prot.fcs = env->mode.prot.fcs;
+                fpstate.env.mode.prot.fdp = env->mode.prot.fdp;
+                fpstate.env.mode.prot.fds = env->mode.prot.fds;
+                fpstate.env.mode.prot.fop = 0; /* unknown */
+            }
+            else
+            {
+                unsigned int fip = env->mode.real.fip_lo +
+                                   (env->mode.real.fip_hi << 16);
+                unsigned int fdp = env->mode.real.fdp_lo +
+                                   (env->mode.real.fdp_hi << 16);
+                unsigned int fop = env->mode.real.fop;
+
+                fpstate.env.mode.prot.fip = fip & 0xf;
+                fpstate.env.mode.prot.fcs = fip >> 4;
+                fpstate.env.mode.prot.fop = fop;
+                fpstate.env.mode.prot.fdp = fdp & 0xf;
+                fpstate.env.mode.prot.fds = fdp >> 4;
+            }
+
+            if ( bytes == sizeof(*env) )
+                ptr = NULL;
+            else
+                ptr += sizeof(*env);
+            break;
+        }
+
+        default:
+            ASSERT_UNREACHABLE();
+            return X86EMUL_UNHANDLEABLE;
+        }
+
+        if ( ptr )
+        {
+            memcpy(fpstate.freg, ptr, sizeof(fpstate.freg));
+            asm volatile ( "frstor %0" :: "m" (fpstate) );
+        }
+        else
+            asm volatile ( "fldenv %0" :: "m" (fpstate.env) );
+        break;
+
     case blk_fst:
         ASSERT(!data);
 



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:15:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1jv-0006Fw-2r; Mon, 27 Apr 2020 11:15:55 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1ju-0006Fh-17
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:15:54 +0000
X-Inumbo-ID: 7496dcd1-8878-11ea-9763-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7496dcd1-8878-11ea-9763-12813bfff9fa;
 Mon, 27 Apr 2020 11:15:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0619DAD6B;
 Mon, 27 Apr 2020 11:15:50 +0000 (UTC)
Subject: [PATCH v7 08/11] x86emul: support FXSAVE/FXRSTOR
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <47c22359-cd7e-22d8-f74b-c45d8dc47b5d@suse.com>
Date: Mon, 27 Apr 2020 13:15:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Note that FPU selector handling as well as MXCSR mask saving for now
does not honor differences between host and guest visible featuresets.

Since operation of the insns on CR4.OSFXSR is implementation dependent,
the easiest solution is used: Simply don't look at the bit in the first
place.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v7: New.

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -767,6 +767,12 @@ static void zap_fpsel(unsigned int *env,
     }
 }
 
+static void zap_xfpsel(unsigned int *env)
+{
+    env[3] &= ~0xffff;
+    env[5] &= ~0xffff;
+}
+
 #ifdef __x86_64__
 # define STKVAL_DISP 64
 static const struct {
@@ -2517,6 +2523,91 @@ int main(int argc, char **argv)
     else
         printf("skipped\n");
 
+    printf("%-40s", "Testing fxsave 4(%ecx)...");
+    if ( stack_exec && cpu_has_fxsr )
+    {
+        const uint16_t nine = 9;
+
+        memset(res + 0x80, 0xcc, 0x400);
+        if ( cpu_has_sse2 )
+            asm volatile ( "pcmpeqd %xmm7, %xmm7\n\t"
+                           "pxor %xmm6, %xmm6\n\t"
+                           "psubw %xmm7, %xmm6" );
+        asm volatile ( "fninit\n\t"
+                       "fld1\n\t"
+                       "fidivs %1\n\t"
+                       "fxsave %0"
+                       : "=m" (res[0x100]) : "m" (nine) : "memory" );
+        zap_xfpsel(&res[0x100]);
+        instr[0] = 0x0f; instr[1] = 0xae; instr[2] = 0x41; instr[3] = 0x04;
+        regs.eip = (unsigned long)&instr[0];
+        regs.ecx = (unsigned long)(res + 0x7f);
+        memset(res + 0x100 + 0x74, 0x33, 0x30);
+        memset(res + 0x80 + 0x74, 0x33, 0x30);
+        rc = x86_emulate(&ctxt, &emulops);
+        zap_xfpsel(&res[0x80]);
+        if ( (rc != X86EMUL_OKAY) ||
+             memcmp(res + 0x80, res + 0x100, 0x200) ||
+             (regs.eip != (unsigned long)&instr[4]) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing fxrstor -4(%ecx)...");
+    if ( stack_exec && cpu_has_fxsr )
+    {
+        const uint16_t eleven = 11;
+
+        memset(res + 0x80, 0xcc, 0x400);
+        asm volatile ( "fxsave %0" : "=m" (res[0x80]) :: "memory" );
+        zap_xfpsel(&res[0x80]);
+        if ( cpu_has_sse2 )
+            asm volatile ( "pxor %xmm7, %xmm6\n\t"
+                           "pxor %xmm7, %xmm3\n\t"
+                           "pxor %xmm7, %xmm0\n\t"
+                           "pxor %xmm7, %xmm7" );
+        asm volatile ( "fninit\n\t"
+                       "fld1\n\t"
+                       "fidivs %0\n\t"
+                       :: "m" (eleven) );
+        instr[0] = 0x0f; instr[1] = 0xae; instr[2] = 0x49; instr[3] = 0xfc;
+        regs.eip = (unsigned long)&instr[0];
+        regs.ecx = (unsigned long)(res + 0x81);
+        rc = x86_emulate(&ctxt, &emulops);
+        asm volatile ( "fxsave %0" : "=m" (res[0x100]) :: "memory" );
+        if ( (rc != X86EMUL_OKAY) ||
+             memcmp(res + 0x100, res + 0x80, 0x200) ||
+             (regs.eip != (unsigned long)&instr[4]) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+#ifdef __x86_64__
+    printf("%-40s", "Testing fxsaveq 8(%edx)...");
+    if ( stack_exec && cpu_has_fxsr )
+    {
+        memset(res + 0x80, 0xcc, 0x400);
+        asm volatile ( "fxsaveq %0" : "=m" (res[0x100]) :: "memory" );
+        instr[0] = 0x48; instr[1] = 0x0f; instr[2] = 0xae; instr[3] = 0x42; instr[4] = 0x08;
+        regs.eip = (unsigned long)&instr[0];
+        regs.edx = (unsigned long)(res + 0x7e);
+        memset(res + 0x100 + 0x74, 0x33, 0x30);
+        memset(res + 0x80 + 0x74, 0x33, 0x30);
+        rc = x86_emulate(&ctxt, &emulops);
+        if ( (rc != X86EMUL_OKAY) ||
+             memcmp(res + 0x80, res + 0x100, 0x200) ||
+             (regs.eip != (unsigned long)&instr[5]) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+#endif
+
     printf("%-40s", "Testing movq %mm3,(%ecx)...");
     if ( stack_exec && cpu_has_mmx )
     {
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -30,6 +30,13 @@ struct cpuid_policy cp;
 static char fpu_save_area[4096] __attribute__((__aligned__((64))));
 static bool use_xsave;
 
+/*
+ * Re-use the area above also as scratch space for the emulator itself.
+ * (When debugging the emulator, care needs to be taken when inserting
+ * printf() or alike function calls into regions using this.)
+ */
+#define FXSAVE_AREA ((struct x86_fxsr *)fpu_save_area)
+
 void emul_save_fpu_state(void)
 {
     if ( use_xsave )
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -860,6 +860,11 @@ struct x86_emulate_state {
         blk_fld, /* FLDENV, FRSTOR */
         blk_fst, /* FNSTENV, FNSAVE */
 #endif
+#if !defined(X86EMUL_NO_FPU) && !defined(X86EMUL_NO_MMX) && \
+    !defined(X86EMUL_NO_SIMD)
+        blk_fxrstor,
+        blk_fxsave,
+#endif
         blk_movdir,
     } blk;
     uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
@@ -953,6 +958,29 @@ typedef union {
     uint32_t data32[16];
 } mmval_t;
 
+struct x86_fxsr {
+    uint16_t fcw;
+    uint16_t fsw;
+    uint16_t ftw:8, :8;
+    uint16_t fop;
+    union {
+        struct {
+            uint32_t offs;
+            uint32_t sel:16, :16;
+        };
+        uint64_t addr;
+    } fip, fdp;
+    uint32_t mxcsr;
+    uint32_t mxcsr_mask;
+    struct {
+        uint8_t data[10];
+        uint8_t _[6];
+    } fpreg[8];
+    uint64_t __attribute__ ((aligned(16))) xmm[16][2];
+    uint64_t _[6];
+    uint64_t avl[6];
+};
+
 /*
  * While proper alignment gets specified above, this doesn't get honored by
  * the compiler for automatic variables. Use this helper to instantiate a
@@ -1910,6 +1938,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_cmov()        (ctxt->cpuid->basic.cmov)
 #define vcpu_has_clflush()     (ctxt->cpuid->basic.clflush)
 #define vcpu_has_mmx()         (ctxt->cpuid->basic.mmx)
+#define vcpu_has_fxsr()        (ctxt->cpuid->basic.fxsr)
 #define vcpu_has_sse()         (ctxt->cpuid->basic.sse)
 #define vcpu_has_sse2()        (ctxt->cpuid->basic.sse2)
 #define vcpu_has_sse3()        (ctxt->cpuid->basic.sse3)
@@ -8125,6 +8154,30 @@ x86_emulate(
     case X86EMUL_OPC(0x0f, 0xae): case X86EMUL_OPC_66(0x0f, 0xae): /* Grp15 */
         switch ( modrm_reg & 7 )
         {
+#if !defined(X86EMUL_NO_FPU) && !defined(X86EMUL_NO_MMX) && \
+    !defined(X86EMUL_NO_SIMD)
+        case 0: /* fxsave */
+        case 1: /* fxrstor */
+            generate_exception_if(vex.pfx, EXC_UD);
+            vcpu_must_have(fxsr);
+            generate_exception_if(ea.type != OP_MEM, EXC_UD);
+            generate_exception_if(!is_aligned(ea.mem.seg, ea.mem.off, 16,
+                                              ctxt, ops),
+                                  EXC_GP, 0);
+            fail_if(!ops->blk);
+            /*
+             * This could also be X86EMUL_FPU_mmx, but it shouldn't be
+             * X86EMUL_FPU_xmm, as we don't want CR4.OSFXSR checked.
+             */
+            get_fpu(X86EMUL_FPU_fpu);
+            state->blk = modrm_reg & 1 ? blk_fxrstor : blk_fxsave;
+            if ( (rc = ops->blk(ea.mem.seg, ea.mem.off, NULL,
+                                sizeof(struct x86_fxsr), &_regs.eflags,
+                                state, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            break;
+#endif /* X86EMUL_NO_{FPU,MMX,SIMD} */
+
 #ifndef X86EMUL_NO_SIMD
         case 2: /* ldmxcsr */
             generate_exception_if(vex.pfx, EXC_UD);
@@ -11611,6 +11664,8 @@ int x86_emul_blk(
     struct x86_emulate_state *state,
     struct x86_emulate_ctxt *ctxt)
 {
+    int rc = X86EMUL_OKAY;
+
     switch ( state->blk )
     {
         bool zf;
@@ -11815,7 +11870,79 @@ int x86_emul_blk(
         if ( ptr )
             memcpy(ptr, fpstate.freg, sizeof(fpstate.freg));
         break;
-#endif
+
+# if !defined(X86EMUL_NO_MMX) && !defined(X86EMUL_NO_SIMD)
+
+    case blk_fxrstor:
+    {
+        struct x86_fxsr *fxsr = FXSAVE_AREA;
+
+        ASSERT(!data);
+        ASSERT(bytes == sizeof(*fxsr));
+
+        if ( mode_64bit() )
+        {
+            /* We could probably also copy the entire area. */
+            memcpy(fxsr, ptr, offsetof(struct x86_fxsr, _));
+            memset(fxsr->_, 0, sizeof(*fxsr) - offsetof(struct x86_fxsr, _));
+        }
+        else
+        {
+            memcpy(fxsr, ptr, offsetof(struct x86_fxsr, xmm[8]));
+            /*
+             * We can't issue a suitable FXRSTOR loading just XMM0...XMM7. Zeroing
+             * the high registers to be loaded isn't entirely correct, but the
+             * alternative would be quite a bit more involved: Synthesize the insn
+             * from FRSTOR, LDMXCSR, and individual XMM register loads.
+             */
+            memset(fxsr->xmm[8], 0,
+                   sizeof(*fxsr) - offsetof(struct x86_fxsr, xmm[8]));
+        }
+
+        generate_exception_if(fxsr->mxcsr & ~mxcsr_mask, EXC_GP, 0);
+
+#  ifdef __x86_64__
+        if ( state->rex_prefix & REX_W )
+        {
+            /*
+             * The only way to force fxrstorq on a wide range of gas versions.
+             * On older versions the rex64 prefix works only if we force an
+             * addressing mode that doesn't require extended registers.
+             */
+            asm volatile ( ".byte 0x48; fxrstor (%0)"
+                           :: "R" (fxsr), "m" (*fxsr) );
+        }
+        else
+#  endif
+            asm volatile ( "fxrstor %0" :: "m" (*fxsr) );
+        break;
+    }
+
+    case blk_fxsave:
+        ASSERT(!data);
+        ASSERT(bytes == sizeof(struct x86_fxsr));
+
+#  ifdef __x86_64__
+        if ( !mode_64bit() )
+        {
+            struct x86_fxsr *fxsr = FXSAVE_AREA;
+
+            asm volatile ( "fxsave %0" : "=m" (*fxsr) );
+            memcpy(ptr, fxsr, offsetof(struct x86_fxsr, xmm[8]));
+        }
+        else if ( state->rex_prefix & REX_W )
+        {
+            /* See above for why operand/constraints are this way. */
+            asm volatile ( ".byte 0x48; fxsave (%0)"
+                           :: "R" (ptr) : "memory" );
+        }
+        else
+#  endif
+            asm volatile ( "fxsave (%0)" :: "r" (ptr) : "memory" );
+        break;
+
+# endif /* X86EMUL_NO_{MMX,SIMD} */
+#endif /* X86EMUL_NO_FPU */
 
     case blk_movdir:
         switch ( bytes )
@@ -11870,7 +11997,8 @@ int x86_emul_blk(
         return X86EMUL_UNHANDLEABLE;
     }
 
-    return X86EMUL_OKAY;
+ done:
+    return rc;
 }
 
 static void __init __maybe_unused build_assertions(void)
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -42,6 +42,8 @@
     }                                                      \
 })
 
+#define FXSAVE_AREA current->arch.fpu_ctxt
+
 #ifndef CONFIG_HVM
 # define X86EMUL_NO_FPU
 # define X86EMUL_NO_MMX



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:16:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:16:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1kO-0006Md-Cx; Mon, 27 Apr 2020 11:16:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1kN-0006MT-Rw
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:16:23 +0000
X-Inumbo-ID: 86e24154-8878-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 86e24154-8878-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 11:16:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B0FFDAC5F;
 Mon, 27 Apr 2020 11:16:21 +0000 (UTC)
Subject: [PATCH v7 09/11] x86/HVM: scale MPERF values reported to guests (on
 AMD)
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <9cf48f0e-8135-9fb3-656f-ea60cae1269c@suse.com>
Date: Mon, 27 Apr 2020 13:16:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

AMD's PM specifies that MPERF (and its r/o counterpart) reads are
affected by the TSC ratio. Hence when processing such reads in software
we too should scale the values. While we don't currently (yet) expose
the underlying feature flags, besides us allowing the MSRs to be read
nevertheless, RDPRU is going to expose the values even to user space.

Furthermore, due to the not exposed feature flags, this change has the
effect of making properly inaccessible (for reads) the two MSRs.

Note that writes to MPERF (and APERF) continue to be unsupported.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: New.
---
I did consider whether to put the code in guest_rdmsr() instead, but
decided that it's better to have it next to TSC handling.

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3478,6 +3478,22 @@ int hvm_msr_read_intercept(unsigned int
         *msr_content = v->arch.hvm.msr_tsc_adjust;
         break;
 
+    case MSR_MPERF_RD_ONLY:
+        if ( !d->arch.cpuid->extd.efro )
+        {
+            goto gp_fault;
+
+    case MSR_IA32_MPERF:
+            if ( !(d->arch.cpuid->basic.raw[6].c &
+                   CPUID6_ECX_APERFMPERF_CAPABILITY) )
+                goto gp_fault;
+        }
+        if ( rdmsr_safe(msr, *msr_content) )
+            goto gp_fault;
+        if ( d->arch.cpuid->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) )
+            *msr_content = hvm_get_guest_tsc_fixed(v, *msr_content);
+        break;
+
     case MSR_APIC_BASE:
         *msr_content = vcpu_vlapic(v)->hw.apic_base_msr;
         break;
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -405,6 +405,9 @@
 #define MSR_IA32_MPERF			0x000000e7
 #define MSR_IA32_APERF			0x000000e8
 
+#define MSR_MPERF_RD_ONLY		0xc00000e7
+#define MSR_APERF_RD_ONLY		0xc00000e8
+
 #define MSR_IA32_THERM_CONTROL		0x0000019a
 #define MSR_IA32_THERM_INTERRUPT	0x0000019b
 #define MSR_IA32_THERM_STATUS		0x0000019c



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:17:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1l8-0006TW-N6; Mon, 27 Apr 2020 11:17:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1l7-0006TL-6s
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:17:09 +0000
X-Inumbo-ID: a1a9b79c-8878-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a1a9b79c-8878-11ea-9887-bc764e2007e4;
 Mon, 27 Apr 2020 11:17:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9D613ABE2;
 Mon, 27 Apr 2020 11:17:06 +0000 (UTC)
Subject: [PATCH v7 10/11] x86emul: support RDPRU
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <b6e63373-afab-7866-4bba-8883b64b40d5@suse.com>
Date: Mon, 27 Apr 2020 13:17:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

While the PM doesn't say so, this assumes that the MPERF value read this
way gets scaled similarly to its reading through RDMSR.

Also introduce the SVM related constants at this occasion.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v6: Re-base.
v5: The CPUID field used is just 8 bits wide.
v4: Add GENERAL2_INTERCEPT_RDPRU and VMEXIT_RDPRU enumerators. Fold
    handling of out of bounds indexes into switch(). Avoid
    recalculate_misc() clobbering what recalculate_cpu_policy() has
    done. Re-base.
v3: New.
---
RFC: Andrew promised to take care of the CPUID side of this; re-base
     over his work once available.

--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -264,6 +264,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
 
         {"clzero",       0x80000008, NA, CPUID_REG_EBX,  0,  1},
         {"rstr-fp-err-ptrs", 0x80000008, NA, CPUID_REG_EBX, 2, 1},
+        {"rdpru",        0x80000008, NA, CPUID_REG_EBX,  4,  1},
         {"wbnoinvd",     0x80000008, NA, CPUID_REG_EBX,  9,  1},
         {"ibpb",         0x80000008, NA, CPUID_REG_EBX, 12,  1},
         {"ppin",         0x80000008, NA, CPUID_REG_EBX, 23,  1},
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -148,6 +148,8 @@ static const char *const str_e8b[32] =
     [ 0] = "clzero",
     [ 2] = "rstr-fp-err-ptrs",
 
+    [ 4] = "rdpru",
+
     /* [ 8] */            [ 9] = "wbnoinvd",
 
     [12] = "ibpb",
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -683,6 +683,13 @@ static int read_msr(
 {
     switch ( reg )
     {
+    case 0x000000e8: /* APERF */
+    case 0xc00000e8: /* APERF_RD_ONLY */
+#define APERF_LO_VALUE 0xAEAEAEAE
+#define APERF_HI_VALUE 0xEAEAEAEA
+        *val = ((uint64_t)APERF_HI_VALUE << 32) | APERF_LO_VALUE;
+        return X86EMUL_OKAY;
+
     case 0xc0000080: /* EFER */
         *val = ctxt->addr_size > 32 ? 0x500 /* LME|LMA */ : 0;
         return X86EMUL_OKAY;
@@ -2421,6 +2428,30 @@ int main(int argc, char **argv)
     else
         printf("skipped\n");
 
+    printf("%-40s", "Testing rdpru...");
+    instr[0] = 0x0f; instr[1] = 0x01; instr[2] = 0xfd;
+    regs.eip = (unsigned long)&instr[0];
+    regs.ecx = 1;
+    regs.eflags = EFLAGS_ALWAYS_SET;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.eax != APERF_LO_VALUE) || (regs.edx != APERF_HI_VALUE) ||
+         !(regs.eflags & X86_EFLAGS_CF) ||
+         (regs.eip != (unsigned long)&instr[3]) )
+        goto fail;
+    if ( ctxt.cpuid->extd.rdpru_max < 0xffff )
+    {
+        regs.eip = (unsigned long)&instr[0];
+        regs.ecx = ctxt.cpuid->extd.rdpru_max + 1;
+        regs.eflags = EFLAGS_ALWAYS_SET | X86_EFLAGS_CF;
+        rc = x86_emulate(&ctxt, &emulops);
+        if ( (rc != X86EMUL_OKAY) || regs.eax || regs.edx ||
+             (regs.eflags & X86_EFLAGS_CF) ||
+             (regs.eip != (unsigned long)&instr[3]) )
+            goto fail;
+    }
+    printf("okay\n");
+
     printf("%-40s", "Testing fnstenv 4(%ecx)...");
     if ( stack_exec && cpu_has_fpu )
     {
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -84,6 +84,8 @@ bool emul_test_init(void)
     cp.feat.avx512pf = cp.feat.avx512f;
     cp.feat.rdpid = true;
     cp.extd.clzero = true;
+    cp.extd.rdpru = true;
+    cp.extd.rdpru_max = 1;
 
     if ( cpu_has_xsave )
     {
@@ -156,11 +158,11 @@ int emul_test_cpuid(
     }
 
     /*
-     * The emulator doesn't itself use CLZERO, so we can always run the
+     * The emulator doesn't itself use CLZERO/RDPRU, so we can always run the
      * respective test(s).
      */
     if ( leaf == 0x80000008 )
-        res->b |= 1U << 0;
+        res->b |= (1U << 0) | (1U << 4);
 
     return X86EMUL_OKAY;
 }
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -243,8 +243,6 @@ static void recalculate_misc(struct cpui
     /* Most of Power/RAS hidden from guests. */
     p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
 
-    p->extd.raw[0x8].d = 0;
-
     switch ( p->x86_vendor )
     {
     case X86_VENDOR_INTEL:
@@ -263,6 +261,7 @@ static void recalculate_misc(struct cpui
 
         p->extd.raw[0x8].a &= 0x0000ffff;
         p->extd.raw[0x8].c = 0;
+        p->extd.raw[0x8].d = 0;
         break;
 
     case X86_VENDOR_AMD:
@@ -281,6 +280,7 @@ static void recalculate_misc(struct cpui
 
         p->extd.raw[0x8].a &= 0x0000ffff; /* GuestMaxPhysAddr hidden. */
         p->extd.raw[0x8].c &= 0x0003f0ff;
+        p->extd.raw[0x8].d &= 0xffff0000;
 
         p->extd.raw[0x9] = EMPTY_LEAF;
 
@@ -643,6 +643,11 @@ void recalculate_cpuid_policy(struct dom
 
     p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
 
+    if ( p->extd.rdpru )
+        p->extd.rdpru_max = min(p->extd.rdpru_max, max->extd.rdpru_max);
+    else
+        p->extd.rdpru_max = 0;
+
     recalculate_xstate(p);
     recalculate_misc(p);
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1967,6 +1967,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_fma4()        (ctxt->cpuid->extd.fma4)
 #define vcpu_has_tbm()         (ctxt->cpuid->extd.tbm)
 #define vcpu_has_clzero()      (ctxt->cpuid->extd.clzero)
+#define vcpu_has_rdpru()       (ctxt->cpuid->extd.rdpru)
 #define vcpu_has_wbnoinvd()    (ctxt->cpuid->extd.wbnoinvd)
 
 #define vcpu_has_bmi1()        (ctxt->cpuid->feat.bmi1)
@@ -5855,6 +5856,50 @@ x86_emulate(
                 limit -= sizeof(zero);
             }
             break;
+
+        case 0xfd: /* rdpru */
+            vcpu_must_have(rdpru);
+
+            if ( !mode_ring0() )
+            {
+                fail_if(!ops->read_cr);
+                if ( (rc = ops->read_cr(4, &cr4, ctxt)) != X86EMUL_OKAY )
+                    goto done;
+                generate_exception_if(cr4 & X86_CR4_TSD, EXC_UD);
+            }
+
+            switch ( _regs.ecx | -(_regs.ecx > ctxt->cpuid->extd.rdpru_max) )
+            {
+            case 0:  n = MSR_IA32_MPERF; break;
+            case 1:  n = MSR_IA32_APERF; break;
+            default: n = 0; break;
+            }
+
+            _regs.eflags &= ~EFLAGS_MASK;
+            if ( n )
+            {
+                fail_if(!ops->read_msr);
+                switch ( rc = ops->read_msr(n, &msr_val, ctxt) )
+                {
+                case X86EMUL_OKAY:
+                    _regs.eflags |= X86_EFLAGS_CF;
+                    break;
+
+                case X86EMUL_EXCEPTION:
+                    x86_emul_reset_event(ctxt);
+                    rc = X86EMUL_OKAY;
+                    break;
+
+                default:
+                    goto done;
+                }
+            }
+
+            if ( !(_regs.eflags & X86_EFLAGS_CF) )
+                msr_val = 0;
+            _regs.r(dx) = msr_val >> 32;
+            _regs.r(ax) = (uint32_t)msr_val;
+            break;
         }
 
 #define _GRP7(mod, reg) \
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -74,7 +74,8 @@ enum GenericIntercept2bits
     GENERAL2_INTERCEPT_MONITOR = 1 << 10,
     GENERAL2_INTERCEPT_MWAIT   = 1 << 11,
     GENERAL2_INTERCEPT_MWAIT_CONDITIONAL = 1 << 12,
-    GENERAL2_INTERCEPT_XSETBV  = 1 << 13
+    GENERAL2_INTERCEPT_XSETBV  = 1 << 13,
+    GENERAL2_INTERCEPT_RDPRU   = 1 << 14,
 };
 
 
@@ -298,6 +299,7 @@ enum VMEXIT_EXITCODE
     VMEXIT_MWAIT            = 139, /* 0x8b */
     VMEXIT_MWAIT_CONDITIONAL= 140, /* 0x8c */
     VMEXIT_XSETBV           = 141, /* 0x8d */
+    VMEXIT_RDPRU            = 142, /* 0x8e */
     VMEXIT_NPF              = 1024, /* 0x400, nested paging fault */
     VMEXIT_INVALID          =  -1
 };
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -250,6 +250,7 @@ XEN_CPUFEATURE(EFRO,          7*32+10) /
 /* AMD-defined CPU features, CPUID level 0x80000008.ebx, word 8 */
 XEN_CPUFEATURE(CLZERO,        8*32+ 0) /*A  CLZERO instruction */
 XEN_CPUFEATURE(RSTR_FP_ERR_PTRS, 8*32+ 2) /*A  (F)X{SAVE,RSTOR} always saves/restores FPU Error pointers */
+XEN_CPUFEATURE(RDPRU,         8*32+ 4) /*A  RDPRU instruction */
 XEN_CPUFEATURE(WBNOINVD,      8*32+ 9) /*   WBNOINVD instruction */
 XEN_CPUFEATURE(IBPB,          8*32+12) /*A  IBPB support only (no IBRS, used by AMD) */
 XEN_CPUFEATURE(AMD_PPIN,      8*32+23) /*   Protected Processor Inventory Number */
--- a/xen/include/xen/lib/x86/cpuid.h
+++ b/xen/include/xen/lib/x86/cpuid.h
@@ -263,7 +263,7 @@ struct cpuid_policy
                 struct { DECL_BITFIELD(e8b); };
             };
             uint32_t nc:8, :4, apic_id_size:4, :16;
-            uint32_t /* d */:32;
+            uint8_t :8, :8, rdpru_max, :8;
         };
     } extd;
 



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:17:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:17:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1lX-0006YR-06; Mon, 27 Apr 2020 11:17:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT1lV-0006Y8-Po
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:17:33 +0000
X-Inumbo-ID: b06a97a6-8878-11ea-9763-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b06a97a6-8878-11ea-9763-12813bfff9fa;
 Mon, 27 Apr 2020 11:17:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 34106ABE2;
 Mon, 27 Apr 2020 11:17:31 +0000 (UTC)
Subject: [PATCH v7 11/11] x86/HVM: don't needlessly intercept APERF/MPERF/TSC
 MSR reads
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Message-ID: <13f4ca33-08e3-3993-4418-61a84b458795@suse.com>
Date: Mon, 27 Apr 2020 13:17:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e28f9cdf-00bc-4a48-c5bf-96f5055c7291@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

If the hardware can handle accesses, we should allow it to do so. This
way we can expose EFRO to HVM guests, and "all" that's left for exposing
APERF/MPERF is to figure out how to handle writes to these MSRs. (Note
that the leaf 6 guest CPUID checks will evaluate to false for now, as
recalculate_misc() zaps the entire leaf.)

For TSC the intercepts are made mirror the RDTSC ones.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
---
v4: Make TSC intercepts mirror RDTSC ones. Re-base.
v3: New.

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -595,6 +595,7 @@ static void svm_cpuid_policy_changed(str
     struct vmcb_struct *vmcb = svm->vmcb;
     const struct cpuid_policy *cp = v->domain->arch.cpuid;
     u32 bitmap = vmcb_get_exception_intercepts(vmcb);
+    unsigned int mode;
 
     if ( opt_hvm_fep ||
          (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
@@ -607,6 +608,17 @@ static void svm_cpuid_policy_changed(str
     /* Give access to MSR_PRED_CMD if the guest has been told about it. */
     svm_intercept_msr(v, MSR_PRED_CMD,
                       cp->extd.ibpb ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW);
+
+    /* Allow direct reads from APERF/MPERF if permitted by the policy. */
+    mode = cp->basic.raw[6].c & CPUID6_ECX_APERFMPERF_CAPABILITY
+           ? MSR_INTERCEPT_WRITE : MSR_INTERCEPT_RW;
+    svm_intercept_msr(v, MSR_IA32_APERF, mode);
+    svm_intercept_msr(v, MSR_IA32_MPERF, mode);
+
+    /* Allow direct access to their r/o counterparts if permitted. */
+    mode = cp->extd.efro ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW;
+    svm_intercept_msr(v, MSR_APERF_RD_ONLY, mode);
+    svm_intercept_msr(v, MSR_MPERF_RD_ONLY, mode);
 }
 
 void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state)
@@ -860,7 +872,10 @@ static void svm_set_rdtsc_exiting(struct
     {
         general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
         general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
+        svm_enable_intercept_for_msr(v, MSR_IA32_TSC);
     }
+    else
+        svm_intercept_msr(v, MSR_IA32_TSC, MSR_INTERCEPT_WRITE);
 
     vmcb_set_general1_intercepts(vmcb, general1_intercepts);
     vmcb_set_general2_intercepts(vmcb, general2_intercepts);
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -108,6 +108,7 @@ static int construct_vmcb(struct vcpu *v
     {
         vmcb->_general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
         vmcb->_general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
+        svm_intercept_msr(v, MSR_IA32_TSC, MSR_INTERCEPT_WRITE);
     }
 
     /* Guest segment limits. */
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1141,8 +1141,13 @@ static int construct_vmcs(struct vcpu *v
         vmx_clear_msr_intercept(v, MSR_IA32_SYSENTER_CS, VMX_MSR_RW);
         vmx_clear_msr_intercept(v, MSR_IA32_SYSENTER_ESP, VMX_MSR_RW);
         vmx_clear_msr_intercept(v, MSR_IA32_SYSENTER_EIP, VMX_MSR_RW);
+
+        if ( !(v->arch.hvm.vmx.exec_control & CPU_BASED_RDTSC_EXITING) )
+            vmx_clear_msr_intercept(v, MSR_IA32_TSC, VMX_MSR_R);
+
         if ( paging_mode_hap(d) && (!is_iommu_enabled(d) || iommu_snoop) )
             vmx_clear_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW);
+
         if ( (vmexit_ctl & VM_EXIT_CLEAR_BNDCFGS) &&
              (vmentry_ctl & VM_ENTRY_LOAD_BNDCFGS) )
             vmx_clear_msr_intercept(v, MSR_IA32_BNDCFGS, VMX_MSR_RW);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -585,6 +585,18 @@ static void vmx_cpuid_policy_changed(str
         vmx_clear_msr_intercept(v, MSR_FLUSH_CMD, VMX_MSR_RW);
     else
         vmx_set_msr_intercept(v, MSR_FLUSH_CMD, VMX_MSR_RW);
+
+    /* Allow direct reads from APERF/MPERF if permitted by the policy. */
+    if ( cp->basic.raw[6].c & CPUID6_ECX_APERFMPERF_CAPABILITY )
+    {
+        vmx_clear_msr_intercept(v, MSR_IA32_APERF, VMX_MSR_R);
+        vmx_clear_msr_intercept(v, MSR_IA32_MPERF, VMX_MSR_R);
+    }
+    else
+    {
+        vmx_set_msr_intercept(v, MSR_IA32_APERF, VMX_MSR_R);
+        vmx_set_msr_intercept(v, MSR_IA32_MPERF, VMX_MSR_R);
+    }
 }
 
 int vmx_guest_x86_mode(struct vcpu *v)
@@ -1250,7 +1262,12 @@ static void vmx_set_rdtsc_exiting(struct
     vmx_vmcs_enter(v);
     v->arch.hvm.vmx.exec_control &= ~CPU_BASED_RDTSC_EXITING;
     if ( enable )
+    {
         v->arch.hvm.vmx.exec_control |= CPU_BASED_RDTSC_EXITING;
+        vmx_set_msr_intercept(v, MSR_IA32_TSC, VMX_MSR_R);
+    }
+    else
+        vmx_clear_msr_intercept(v, MSR_IA32_TSC, VMX_MSR_R);
     vmx_update_cpu_exec_control(v);
     vmx_vmcs_exit(v);
 }
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -245,7 +245,7 @@ XEN_CPUFEATURE(ENQCMD,        6*32+29) /
 
 /* AMD-defined CPU features, CPUID level 0x80000007.edx, word 7 */
 XEN_CPUFEATURE(ITSC,          7*32+ 8) /*   Invariant TSC */
-XEN_CPUFEATURE(EFRO,          7*32+10) /*   APERF/MPERF Read Only interface */
+XEN_CPUFEATURE(EFRO,          7*32+10) /*S  APERF/MPERF Read Only interface */
 
 /* AMD-defined CPU features, CPUID level 0x80000008.ebx, word 8 */
 XEN_CPUFEATURE(CLZERO,        8*32+ 0) /*A  CLZERO instruction */



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:26:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT1tZ-0007Zx-0k; Mon, 27 Apr 2020 11:25:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wbbE=6L=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jT1tY-0007Zs-Dv
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:25:52 +0000
X-Inumbo-ID: d9760e90-8879-11ea-b9cf-bc764e2007e4
Received: from mail-wm1-x32d.google.com (unknown [2a00:1450:4864:20::32d])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d9760e90-8879-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 11:25:51 +0000 (UTC)
Received: by mail-wm1-x32d.google.com with SMTP id h4so5843121wmb.4
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 04:25:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=4PTJ5kD22A/3+2M6HVI7JbzS+j7YC4waLleUbiUPfIY=;
 b=bRRUQ0XtluqOtsTL0/WkJAFidCnCu68C4vuc1sxACwzFhC5bRP4vY8ucgjAfeV1Iyr
 AR7glySvJVxUZZpCKYxIgP+bCrKHQHFPqIgaSDvvPYUGCBmw9YkXcWdHk2qZvHdBB28x
 63g/IIWEiQpx18yl/GGeN9yAM2dueLlauZkdnT0/UQck2PRM5djxj6xQB/xut8V223Lq
 mrrw6bqWjMqwX4jK3fp+JeBRXoELNqeTA64F1Q/xAArrtSdFYocLFTTAmW7Ky2kdyukA
 6weeYYFc1mW0drPLc/Igz1+CJSLFUxq/lUylDn7vxQ8LbpkFTLJa1PZngQ3PhxC3D1Fu
 X6RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=4PTJ5kD22A/3+2M6HVI7JbzS+j7YC4waLleUbiUPfIY=;
 b=MLI+r8GukdkP5HkIKXTIkIZHLJAa+WwaJ3fwGrmT56mfA5zyGQaJRXac9Z4XHOy3Jw
 xIvanrApG36pvJg/wk0AQy4+4l3OUgWpzYWrfQnaVXoWnMtbE818mqTIFQQXmv1Gyn3K
 iAsCr9bt9zZl2q/aXfz5jFKqFWeB2sM6WQs1g8C9WApoqgwLozKfoYlz9RmVHeDDlfE2
 7JDiDXSEBPAmhWhoR4NlXoViHL8q1L9oX56flPeP32IOkcohdP6Gl2l9XjCX+VRew6wy
 gqxNXEe/hfbVS2Uzov8dJMoeSKj2h3an38UWy0840N8junMnWKHJJdQSzdpv7K0X3I0Y
 EWNg==
X-Gm-Message-State: AGi0PuYLl5d08jUy6j/XdfSeEwpSyJIfBAFQPZEU4Je+c7oMQqkqDRbr
 2DZwMEhEFcMugWd7/3SJR5A=
X-Google-Smtp-Source: APiQypI3ZnCBuJp3J2rb++Y99bp5yL4EqA19FA8pEojcqgAx6XbsAhjxKFthZqV7PbFWhNhTHiqpwg==
X-Received: by 2002:a7b:c5d4:: with SMTP id n20mr8327898wmk.92.1587986750512; 
 Mon, 27 Apr 2020 04:25:50 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id v16sm15041219wml.30.2020.04.27.04.25.49
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 27 Apr 2020 04:25:50 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= <jgross@suse.com>,
 <xen-devel@lists.xenproject.org>
References: <20200427075342.149-1-paul@xen.org>
 <6004fb95-42e1-1ee3-5215-0d0dede73f0f@suse.com>
 <000a01d61c80$fd1e47a0$f75ad6e0$@xen.org>
 <ff0a5505-77aa-905b-7b77-af418a586a47@suse.com>
In-Reply-To: <ff0a5505-77aa-905b-7b77-af418a586a47@suse.com>
Subject: RE: [PATCH v2] docs/designs: re-work the xenstore migration
 document...
Date: Mon, 27 Apr 2020 12:25:48 +0100
Message-ID: <000c01d61c86$9a9ffd20$cfdff760$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJEJDb5RQM5hDvWa+75ajX7plb9lwK+35WRAi412S8Btzh3pKd7oJrQ
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Paul Durrant' <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>
> Sent: 27 April 2020 12:13
> To: paul@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Paul Durrant' <pdurrant@amazon.com>
> Subject: Re: [PATCH v2] docs/designs: re-work the xenstore migration =
document...
>=20
> On 27.04.20 12:45, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>
> >> Sent: 27 April 2020 11:37
> >> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> >> Cc: Paul Durrant <pdurrant@amazon.com>
> >> Subject: Re: [PATCH v2] docs/designs: re-work the xenstore =
migration document...
> >>
> >> On 27.04.20 09:53, Paul Durrant wrote:
> >>> From: Paul Durrant <pdurrant@amazon.com>
> >>>
> >>> ... to specify a separate migration stream that will also be =
suitable for
> >>> live update.
> >>>
> >>> The original scope of the document was to support non-cooperative =
migration
> >>> of guests [1] but, since then, live update of xenstored has been =
brought into
> >>> scope. Thus it makes more sense to define a separate image format =
for
> >>> serializing xenstore state that is suitable for both purposes.
> >>>
> >>> The document has been limited to specifying a new image format. =
The mechanism
> >>> for acquiring the image for live update or migration is not =
covered as that
> >>> is more appropriately dealt with by a patch to =
docs/misc/xenstore.txt. It is
> >>> also expected that, when the first implementation of live update =
or migration
> >>> making use of this specification is committed, that the document =
is moved from
> >>> docs/designs into docs/specs.
> >>>
> >>> [1] See =
https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Ddocs/designs/non=
-cooperative-
> migration.md
> >>>
> >>> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> >>> ---
> >>> Juergen Gross <jgross@suse.com>
> >>> Andrew Cooper <andrew.cooper3@citrix.com>
> >>> George Dunlap <george.dunlap@citrix.com>
> >>> Ian Jackson <ian.jackson@eu.citrix.com>
> >>> Jan Beulich <jbeulich@suse.com>
> >>> Julien Grall <julien@xen.org>
> >>> Stefano Stabellini <sstabellini@kernel.org>
> >>> Wei Liu <wl@xen.org>
> >>
> >> Mind adding CC: before those mail addresses in order to let git add
> >> those to the recipients list?
> >>
> >
> > D'oh... good spot.
> >
> >>>
> >>> v2:
> >>>    - Address comments from Juergen
> >>
> >> Not all unfortunately. :-(
> >>
> >
> > OK.
> >
> >>> +### CONNECTION_DATA
> >>>
> >>> -Each WATCH_DATA record specifies a registered watch and is =
formatted as
> >>> -follows:
> >>> +For live update the image format will contain a `CONNECTION_DATA` =
record for
> >>> +each connection to xenstore. For migration it will only contain a =
record for
> >>> +the domain being migrated.
> >>>
> >>>
> >>>    ```
> >>> -    0       1       2       3     octet
> >>> -+-------+-------+-------+-------+
> >>> -| WATCH_DATA                    |
> >>> -+-------------------------------+
> >>> -| wpath length                  |
> >>> -+-------------------------------+
> >>> -| wpath data                    |
> >>> -...
> >>> -| pad (0 to 3 octets)           |
> >>> -+-------------------------------+
> >>> +    0       1       2       3       4       5       6       7    =
octet
> >>> ++-------+-------+-------+-------+-------+-------+-------+-------+
> >>> +| conn-id                       | pad                           |
> >>> ++---------------+-----------------------------------------------+
> >>> +| conn-type     | conn-spec
> >>>    ...
> >>
> >> I asked whether it wouldn't be better to drop the pad and move =
conn-type
> >> and a 2-byte (unified) flag field at its position. This together =
...
> >>
> >>> ++-------------------------------+-------------------------------+
> >>> +| data-len                      | data
> >>>    +-------------------------------+
> >>> -| token length                  |
> >>> -+-------------------------------+
> >>> -| token data                    |
> >>>    ...
> >>> -| pad (0 to 3 octets)           |
> >>> -+-------------------------------+
> >>>    ```
> >>>
> >>> -wpath length and token length are specified in octets (excluding =
the NUL
> >>> -terminator). The wpath should be as described for the `WATCH` =
operation in
> >>> -[2]. The token is an arbitrary string of octets not containing =
any NUL
> >>> -values.
> >>>
> >>> +| Field       | Description                                     |
> >>> +|-------------|-------------------------------------------------|
> >>> +| `conn-id`   | A non-zero number used to identify this         |
> >>> +|             | connection in subsequent connection-specific    |
> >>> +|             | records                                         |
> >>> +|             |                                                 |
> >>> +| `conn-type` | 0x0000: shared ring                             |
> >>> +|             | 0x0001: socket                                  |
> >>> +|             |                                                 |
> >>> +| `conn-spec` | See below                                       |
> >>> +|             |                                                 |
> >>> +| `data-len`  | The length (in octets) of any pending data not  |
> >>> +|             | yet written to the connection                   |
> >>> +|             |                                                 |
> >>> +| `data`      | Pending data (may be empty)                     |
> >>>
> >>> -**TRANSACTION_DATA**
> >>> +The format of `conn-spec` is dependent upon `conn-type`.
> >>>
> >>> +\pagebreak
> >>>
> >>> -Each TRANSACTION_DATA record specifies an open transaction and is =
formatted
> >>> -as follows:
> >>> +For `shared ring` connections it is as follows:
> >>>
> >>>
> >>>    ```
> >>> -    0       1       2       3     octet
> >>> -+-------+-------+-------+-------+
> >>> -| TRANSACTION_DATA              |
> >>> -+-------------------------------+
> >>> -| tx_id                         |
> >>> -+-------------------------------+
> >>> +    0       1       2       3       4       5       6       7    =
octet
> >>> +                +-------+-------+-------+-------+-------+-------+
> >>> +                | domid         | tdomid        | flags         |
> >>> ++---------------+---------------+---------------+---------------+
> >>> +| revtchn                       | levtchn                       |
> >>> ++-------------------------------+-------------------------------+
> >>> +| mfn                                                           |
> >>> ++---------------------------------------------------------------+
> >>
> >> ... with dropping levtchn (which isn't needed IMO) will make it =
much
> >> easier to have a union in C (which needs to be aligned to 8 bytes
> >> and have a length of a multiple of 8 bytes due to mfn).
> >>
> >> So something like:
> >>
> >> struct xs_state_connection {
> >>       uint32_t conn_id;
> >>       uint16_t conn_type;
> >> #define XS_STATE_CONN_TYPE_RING   0
> >> #define XS_STATE_CONN_TYPE_SOCKET 1
> >>       uint16_t flags;
> >> #define XS_STATE_CONN_INTRODUCED  0x0001
> >> #define XS_STATE_CONN_RELEASED    0x0002
> >> #define XS_STATE_CONN_READONLY    0x0004
> >>       union {
> >>           struct {
> >>               uint16_t domid;
> >>               uint16_t tdomid;
> >> #define XS_STATE_DOMID_INVALID  0xffffU
> >>               uint32_t evtchn;
> >>               uint64_t mfn;
> >> #define XS_STATE_MFN_INVALID    0xffffffffffffffffUL
> >>           } ring;
> >>           int32_t socket_fd;
> >>       } spec;
> >>       uint32_t data_out_len;
> >>       uint8_t  data[];
> >> };
> >
> > The issue is making sure that the mfn is properly aligned. If I can =
drop the levtchn then this gets
> easier.
> >
> >>
> >>>    ```
> >>>
> >>> -where tx_id is the non-zero identifier values of an open =
transaction.
> >>> -
> >>>
> >>> -### Protocol Extension
> >>> +| Field      | Description                                      |
> >>> +|------------|--------------------------------------------------|
> >>> +| `domid`    | The domain-id that owns the shared page          |
> >>> +|            |                                                  |
> >>> +| `tdomid`   | The domain-id that `domid` acts on behalf of if  |
> >>> +|            | it has been subject to an SET_TARGET             |
> >>> +|            | operation [2] or DOMID_INVALID otherwise         |
> >>
> >> DOMID_INVALID needs to be defined (or we need a reference where it =
is
> >> coming from).
> >
> > OK. It's in a public header... I'll reference it.
> >
> >>
> >>> +|            |                                                  |
> >>> +| `flags`    | A bit-wise OR of:                                |
> >>> +|            | 0x0001: INTRODUCE has been issued                |
>=20
> Just realized, I think we can drop those flags.
>=20
> Reasoning: if INTRODUCE hasn't been issued, there can't be an active
> connection to Xenstore for that domain, as Xenstore doesn't know about
> the parameters to connect (especially the event channel is missing).
>=20
> >>> +|            | 0x0002: RELEASE has been issued                  |
>=20
> And the same applies here: RELEASE will drop the connection to the
> domain, so it can't appear in a connection record.
>=20

I think the presence of the RESUME command in xenstore.txt makes it =
non-obvious that we can forget about a domain once RELEASE has been =
called. The text there does say:

"It is not clear whether this is possible since one would
normally expect a domain not to be restarted after being shut
down without being destroyed in the meantime.  There are
currently no users of this request in xen-unstable."

So, perhaps this would be the time to remove RESUME from the spec?

  Paul

>=20
> Juergen



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 11:43:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 11:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT2A9-0000vn-Gf; Mon, 27 Apr 2020 11:43:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6V0E=6L=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jT2A8-0000vi-KG
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 11:43:00 +0000
X-Inumbo-ID: 3e370f80-887c-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3e370f80-887c-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 11:42:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=FPuVAkXG6I9GNcH5tY7pdaS/qcQnFd/+im0gG9ivFsQ=; b=4Pkv0JIaY9g86H+RjWespb8hn
 0TdIey9vsiKMgEW9ivk4Bjxc6zF8+RpQWHvwfSiUauCY84a3m22+46T4HxL5nWTUVqew07XNSwJxq
 xoBL1ifzNh7JsqFWVKj5ycSsnULwRcXZaY9qhYj9MRNvNT+b4aJW+KIZWmgFrN77ACp0E=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jT2A6-0005cd-N4; Mon, 27 Apr 2020 11:42:58 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jT2A6-00007Y-DH; Mon, 27 Apr 2020 11:42:58 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jT2A6-0007IJ-CQ; Mon, 27 Apr 2020 11:42:58 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149831-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149831: tolerable FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-saverestore:fail:heisenbug
 xen-unstable:test-armhf-armhf-xl-vhd:guest-start:fail:heisenbug
 xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:heisenbug
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f093b08c47b39da6019421a2b61d40745b3e573b
X-Osstest-Versions-That: xen=f093b08c47b39da6019421a2b61d40745b3e573b
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 27 Apr 2020 11:42:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149831 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149831/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds    15 guest-saverestore fail in 149829 pass in 149831
 test-armhf-armhf-xl-vhd      11 guest-start      fail in 149829 pass in 149831
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat  fail pass in 149829

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     16 guest-localmigrate           fail  like 149824
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149829
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149829
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149829
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149829
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149829
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149829
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149829
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149829
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149829
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b
baseline version:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b

Last test of basis   149831  2020-04-27 01:52:33 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 12:20:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 12:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT2jr-0003oI-Mt; Mon, 27 Apr 2020 12:19:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jT2jq-0003oD-Rc
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 12:19:54 +0000
X-Inumbo-ID: 65fdf948-8881-11ea-b9cf-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 65fdf948-8881-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 12:19:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587989993;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=yhIT++WUz3JBK47J7vBNhG48F+SESFJvhU4bGq730OA=;
 b=J24wNcy44tGbVzvhEb4lfK+13sgckZwnvbAdN6acGYb7h4kYw5bnwwx6
 XxPEzSgKNEvsOup7iLXsTH2hlUYTBrHTlmIMQ+/mxb8iur+vvfoKMed/q
 dcCd+Ad0/WURHJtFAQ8q7T1ggIjM6nNm7WatTA8v6sxeiixEgUwfCSYmG o=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: xOs0uufsrCvCre/24xsB1/FOxtcsIWYMGDPxi555n/RyQHVagA8VMfgpcjxQXdnpcaewRpvK+t
 P8Iz7/3IAObkvMT4RAUN8bxumTb0aTBK4TydEBrGz82mLwo87adyHUSIlxhz5+k3QvoAI6eUhQ
 JD7YSSXEWTF6z+0/7YD8KS8nUq1aKEcP1R7g9vFm2rnFI2YaVdTWsaEmoMCLGPCgSS7fmh/LkG
 ywZTLgJX6sP8N0ufGOPabftEPwDmxK+fywGjmabNv51cRyqIKnK3i2TnipXB7XJjHFtV4AGjYV
 a0Y=
X-SBRS: 2.7
X-MesageID: 16697123
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16697123"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/pvh: Override opt_console_xen earlier
Date: Mon, 27 Apr 2020 13:19:44 +0100
Message-ID: <20200427121944.1443-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This allows printk() to work from the start of day, and backtraces from as
early as the IDT is set up.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/boot/head.S | 3 +++
 xen/arch/x86/setup.c     | 5 -----
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 153a53f250..150f7f90a2 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -402,6 +402,9 @@ __pvh_start:
 
         mov     %ebx, sym_esi(pvh_start_info_pa)
 
+        /* Force xen console.  Will revert to user choice in init code. */
+        movb    $-1, sym_esi(opt_console_xen)
+
         /* Prepare gdt and segments */
         add     %esi, sym_esi(gdt_boot_base)
         lgdt    sym_esi(gdt_boot_descr)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 885919d5c3..eb56d78c2f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -728,11 +728,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
     if ( pvh_boot )
     {
-        /*
-         * Force xen console to be enabled. We will reset it later in console
-         * initialisation code.
-         */
-        opt_console_xen = -1;
         ASSERT(mbi_p == 0);
         pvh_init(&mbi, &mod);
     }
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 12:20:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 12:20:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT2kj-0004U8-0j; Mon, 27 Apr 2020 12:20:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jT2ki-0004U2-4Y
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 12:20:48 +0000
X-Inumbo-ID: 85c5c15c-8881-11ea-b9cf-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 85c5c15c-8881-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 12:20:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587990046;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=Je4yHc+ycBtigxSRy6fNqNx3QMdRCG0sFZ0n2Nx1dZY=;
 b=Wy0415kzxskm14qOLKEsWCqiYahYPksRHAwn0zXKLMIiosJWC0bV7QF5
 6AFfRt9BsRYYycD+FcKaeQql5XrfSRJUkF0DaSKQdIbjAzdn0qykqy4eW
 H4Vpga6u3DtirD/66cGebiaQtdCd0jm+1YvDI8bjNBnIWRNmYcaxV9S4z Y=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: iaWWOWNG/Pp5tz6dh7l+fv+Bg27150nCKEr1fxiFVhnpQOmiZBjlM4NlWi5kn5b/CZsSu1E5Sq
 SIcdIZRnAXvWq988NvknaB+CYT/jhI/MPqUQz3cTCMckABHFQTvNtoYijZFJTguS0tGBWMUbyI
 bwsCWDryBPuNvqJiAg7eENOcGchzIraE3rp7R8bhd+2xul338n9ldBj6g8jWj3IcIyPpP7SVVT
 YZWL5J8WhBY/qqJx2LZAEcRZOmaIsCstd8LJ1NMjk/CqnBw+dFw1bKodhaG9j+jsgeDlSCPzRf
 ASA=
X-SBRS: 2.7
X-MesageID: 16610838
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16610838"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/ioemul: Rewrite stub generation
Date: Mon, 27 Apr 2020 13:20:41 +0100
Message-ID: <20200427122041.7162-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The logic is completely undocumented and almost impossible to follow.  It
actually uses return oriented programming.  Rewrite it to conform to more
normal call mechanics, and leave a big comment explaining thing.  As well as
the code being easier to follow, it will execute faster as it isn't fighting
the branch predictor.

Move the ioemul_handle_quirk() function pointer from traps.c to
ioport_emulate.c.  There is no reason for it to be in neither of the two
translation units which use it.  Alter the behaviour to return the number of
bytes written into the stub.

Access the addresses of the host/guest helpers with extern const char arrays.
Nothing good will come of C thinking they are regular functions.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
--
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/ioport_emulate.c  | 11 ++---
 xen/arch/x86/pv/emul-priv-op.c | 91 +++++++++++++++++++++++++++++++-----------
 xen/arch/x86/pv/gpr_switch.S   | 37 +++++------------
 xen/arch/x86/traps.c           |  3 --
 xen/include/asm-x86/io.h       |  3 +-
 5 files changed, 85 insertions(+), 60 deletions(-)

diff --git a/xen/arch/x86/ioport_emulate.c b/xen/arch/x86/ioport_emulate.c
index 499c1f6056..f7511a9c49 100644
--- a/xen/arch/x86/ioport_emulate.c
+++ b/xen/arch/x86/ioport_emulate.c
@@ -8,7 +8,10 @@
 #include <xen/sched.h>
 #include <xen/dmi.h>
 
-static bool ioemul_handle_proliant_quirk(
+unsigned int (*ioemul_handle_quirk)(
+    u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs);
+
+static unsigned int ioemul_handle_proliant_quirk(
     u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs)
 {
     static const char stub[] = {
@@ -19,18 +22,16 @@ static bool ioemul_handle_proliant_quirk(
         0xa8, 0x80, /*    test $0x80, %al */
         0x75, 0xfb, /*    jnz 1b          */
         0x9d,       /*    popf            */
-        0xc3,       /*    ret             */
     };
     uint16_t port = regs->dx;
     uint8_t value = regs->al;
 
     if ( (opcode != 0xee) || (port != 0xcd4) || !(value & 0x80) )
-        return false;
+        return 0;
 
     memcpy(io_emul_stub, stub, sizeof(stub));
-    BUILD_BUG_ON(IOEMUL_QUIRK_STUB_BYTES < sizeof(stub));
 
-    return true;
+    return sizeof(stub);
 }
 
 /* This table is the set of system-specific I/O emulation hooks. */
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index e24b84f46a..f150886711 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -54,51 +54,96 @@ struct priv_op_ctxt {
     unsigned int bpmatch;
 };
 
-/* I/O emulation support. Helper routines for, and type of, the stack stub. */
-void host_to_guest_gpr_switch(struct cpu_user_regs *);
-unsigned long guest_to_host_gpr_switch(unsigned long);
+/* I/O emulation helpers.  Use non-standard calling conventions. */
+extern const char load_guest_gprs[], save_guest_gprs[];
 
 typedef void io_emul_stub_t(struct cpu_user_regs *);
 
 static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 opcode,
                                           unsigned int port, unsigned int bytes)
 {
+    /*
+     * Construct a stub for IN/OUT emulation.
+     *
+     * Some platform drivers communicate with the SMM handler using GPRs as a
+     * mailbox.  Therefore, we must perform the emulation with the hardware
+     * domain's registers in view.
+     *
+     * We write a stub of the following form, using the guest load/save
+     * helpers (abnormal calling conventions), and one of several possible
+     * stubs performing the real I/O.
+     */
+    static const char prologue[] = {
+        0x53,       /* push %rbx */
+        0x55,       /* push %rbp */
+        0x41, 0x54, /* push %r12 */
+        0x41, 0x55, /* push %r13 */
+        0x41, 0x56, /* push %r14 */
+        0x41, 0x57, /* push %r15 */
+        0x57,       /* push %rdi (param for save_guest_gprs) */
+    };              /* call load_guest_gprs */
+                    /* <I/O stub> */
+                    /* call save_guest_gprs */
+    static const char epilogue[] = {
+        0x5f,       /* pop %rdi  */
+        0x41, 0x5f, /* pop %r15  */
+        0x41, 0x5e, /* pop %r14  */
+        0x41, 0x5d, /* pop %r13  */
+        0x41, 0x5c, /* pop %r12  */
+        0x5d,       /* pop %rbp  */
+        0x5b,       /* pop %rbx  */
+        0xc3,       /* ret       */
+    };
+
     struct stubs *this_stubs = &this_cpu(stubs);
     unsigned long stub_va = this_stubs->addr + STUB_BUF_SIZE / 2;
-    long disp;
-    bool use_quirk_stub = false;
+    unsigned int quirk_bytes = 0;
+    char *p;
+
+    /* Helpers - Read outer scope but only modify p. */
+#define APPEND_BUFF(b) ({ memcpy(p, b, sizeof(b)); p += sizeof(b); })
+#define APPEND_CALL(f)                                                  \
+    ({                                                                  \
+        long disp = (long)(f) - (stub_va + p - ctxt->io_emul_stub + 5); \
+        BUG_ON((int32_t)disp != disp);                                  \
+        *p++ = 0xe8;                                                    \
+        *(int32_t *)p = disp; p += 4;                                   \
+    })
 
     if ( !ctxt->io_emul_stub )
         ctxt->io_emul_stub =
             map_domain_page(_mfn(this_stubs->mfn)) + (stub_va & ~PAGE_MASK);
 
-    /* call host_to_guest_gpr_switch */
-    ctxt->io_emul_stub[0] = 0xe8;
-    disp = (long)host_to_guest_gpr_switch - (stub_va + 5);
-    BUG_ON((int32_t)disp != disp);
-    *(int32_t *)&ctxt->io_emul_stub[1] = disp;
+    p = ctxt->io_emul_stub;
+
+    APPEND_BUFF(prologue);
+    APPEND_CALL(load_guest_gprs);
 
+    /* Some platforms might need to quirk the stub for specific inputs. */
     if ( unlikely(ioemul_handle_quirk) )
-        use_quirk_stub = ioemul_handle_quirk(opcode, &ctxt->io_emul_stub[5],
-                                             ctxt->ctxt.regs);
+    {
+        quirk_bytes = ioemul_handle_quirk(opcode, p, ctxt->ctxt.regs);
+        p += quirk_bytes;
+    }
 
-    if ( !use_quirk_stub )
+    /* Default I/O stub. */
+    if ( likely(!quirk_bytes) )
     {
-        /* data16 or nop */
-        ctxt->io_emul_stub[5] = (bytes != 2) ? 0x90 : 0x66;
-        /* <io-access opcode> */
-        ctxt->io_emul_stub[6] = opcode;
-        /* imm8 or nop */
-        ctxt->io_emul_stub[7] = !(opcode & 8) ? port : 0x90;
-        /* ret (jumps to guest_to_host_gpr_switch) */
-        ctxt->io_emul_stub[8] = 0xc3;
+        *p++ = (bytes != 2) ? 0x90 : 0x66;  /* data16 or nop */
+        *p++ = opcode;                      /* <opcode>      */
+        *p++ = !(opcode & 8) ? port : 0x90; /* imm8 or nop   */
     }
 
-    BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(9, /* Default emul stub */
-                                         5 + IOEMUL_QUIRK_STUB_BYTES));
+    APPEND_CALL(save_guest_gprs);
+    APPEND_BUFF(epilogue);
+
+    BUG_ON(STUB_BUF_SIZE / 2 < (p - ctxt->io_emul_stub));
 
     /* Handy function-typed pointer to the stub. */
     return (void *)stub_va;
+
+#undef APPEND_CALL
+#undef APPEND_BUFF
 }
 
 
diff --git a/xen/arch/x86/pv/gpr_switch.S b/xen/arch/x86/pv/gpr_switch.S
index 6d26192c2c..e3f8037b69 100644
--- a/xen/arch/x86/pv/gpr_switch.S
+++ b/xen/arch/x86/pv/gpr_switch.S
@@ -9,59 +9,42 @@
 
 #include <asm/asm_defns.h>
 
-ENTRY(host_to_guest_gpr_switch)
-        movq  (%rsp), %rcx
-        movq  %rdi, (%rsp)
+/* Load guest GPRs.  Parameter in %rdi, clobbers all registers. */
+ENTRY(load_guest_gprs)
         movq  UREGS_rdx(%rdi), %rdx
-        pushq %rbx
         movq  UREGS_rax(%rdi), %rax
         movq  UREGS_rbx(%rdi), %rbx
-        pushq %rbp
         movq  UREGS_rsi(%rdi), %rsi
         movq  UREGS_rbp(%rdi), %rbp
-        pushq %r12
-        movq  UREGS_r8(%rdi), %r8
+        movq  UREGS_r8 (%rdi), %r8
         movq  UREGS_r12(%rdi), %r12
-        pushq %r13
-        movq  UREGS_r9(%rdi), %r9
+        movq  UREGS_r9 (%rdi), %r9
         movq  UREGS_r13(%rdi), %r13
-        pushq %r14
         movq  UREGS_r10(%rdi), %r10
         movq  UREGS_r14(%rdi), %r14
-        pushq %r15
         movq  UREGS_r11(%rdi), %r11
         movq  UREGS_r15(%rdi), %r15
-        pushq %rcx /* dummy push, filled by guest_to_host_gpr_switch pointer */
-        pushq %rcx
-        leaq  guest_to_host_gpr_switch(%rip),%rcx
-        movq  %rcx,8(%rsp)
         movq  UREGS_rcx(%rdi), %rcx
         movq  UREGS_rdi(%rdi), %rdi
         ret
 
-ENTRY(guest_to_host_gpr_switch)
+/* Save guest GPRs.  Parameter on the stack above the return address. */
+ENTRY(save_guest_gprs)
         pushq %rdi
-        movq  7*8(%rsp), %rdi
+        movq  2*8(%rsp), %rdi
         movq  %rax, UREGS_rax(%rdi)
-        popq  UREGS_rdi(%rdi)
+        popq        UREGS_rdi(%rdi)
         movq  %r15, UREGS_r15(%rdi)
         movq  %r11, UREGS_r11(%rdi)
-        popq  %r15
         movq  %r14, UREGS_r14(%rdi)
         movq  %r10, UREGS_r10(%rdi)
-        popq  %r14
         movq  %r13, UREGS_r13(%rdi)
-        movq  %r9, UREGS_r9(%rdi)
-        popq  %r13
+        movq  %r9,  UREGS_r9 (%rdi)
         movq  %r12, UREGS_r12(%rdi)
-        movq  %r8, UREGS_r8(%rdi)
-        popq  %r12
+        movq  %r8,  UREGS_r8 (%rdi)
         movq  %rbp, UREGS_rbp(%rdi)
         movq  %rsi, UREGS_rsi(%rdi)
-        popq  %rbp
         movq  %rbx, UREGS_rbx(%rdi)
         movq  %rdx, UREGS_rdx(%rdi)
-        popq  %rbx
         movq  %rcx, UREGS_rcx(%rdi)
-        popq  %rcx
         ret
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index e838846c6b..9df050dcf4 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -116,9 +116,6 @@ idt_entry_t *idt_tables[NR_CPUS] __read_mostly;
  */
 DEFINE_PER_CPU_PAGE_ALIGNED(struct tss_page, tss_page);
 
-bool (*ioemul_handle_quirk)(
-    u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs);
-
 static int debug_stack_lines = 20;
 integer_param("debug_stack_lines", debug_stack_lines);
 
diff --git a/xen/include/asm-x86/io.h b/xen/include/asm-x86/io.h
index 8708b79b99..c4ec52cba7 100644
--- a/xen/include/asm-x86/io.h
+++ b/xen/include/asm-x86/io.h
@@ -49,8 +49,7 @@ __OUT(w,"w",short)
 __OUT(l,,int)
 
 /* Function pointer used to handle platform specific I/O port emulation. */
-#define IOEMUL_QUIRK_STUB_BYTES 10
-extern bool (*ioemul_handle_quirk)(
+extern unsigned int (*ioemul_handle_quirk)(
     u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs);
 
 #endif
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 12:59:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 12:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT3MC-0007Ql-2N; Mon, 27 Apr 2020 12:59:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oTJa=6L=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jT3MA-0007Qg-SF
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 12:59:30 +0000
X-Inumbo-ID: ee5870c0-8886-11ea-b9cf-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ee5870c0-8886-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 12:59:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587992370;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=nc+ZiMNFYJW8OIa0ORxshgyGsoDs2vZyXDpv4+xPoOc=;
 b=UjNBJk4aWK0zZf3c8u5qHGzeFE579Vl6OKGIYmaZzHOqeQX0wmw5IRYU
 dHqhVVkljJWF/2+ikaqGKFdYrYBN6IgGPhnR8MYeoBQDY/HJ0+SLrhUM8
 aVEOFFEXUUb8lGJ5cfYq/cM5J+cwQlf5CNTSOc7f6/IwRmx+qRobNu6KX A=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: ZwvWdwgWnd+9EzfoTUuAOIANHIVr10hEtBYsA/jQDLNX75wNgBIP6xnPQR6cXSQwI9PZTY9Zry
 i6wqmGQSwJiM5zYuFK6ibVjpwGr9uWBf+o5hlhdRD9Q8yIOSjwKEf8RNFP7FocgOvtDQ+7yILR
 tqDwDVhG9tlI/O1a3YjEg+Kp8slWd1SdG9nUe+6EnKqyeRJZn6oI5XrEdKRRSxav9fuklbSSXm
 mb9UUcQE8m6LSXsjRQvQRsGJR+x/UoNiJmR8Sjt+HHtVIChI7Cr56BrXdqebeU0vSEdToL1/nL
 UrQ=
X-SBRS: 2.7
X-MesageID: 16313416
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16313416"
From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Subject: Re: [PATCH v2 1/1] golang/xenlight: add NameToDomid and DomidToName
 util functions
Thread-Topic: [PATCH v2 1/1] golang/xenlight: add NameToDomid and DomidToName
 util functions
Thread-Index: AQHWGeTLlIhJvo8WaUufFBMrVdiAt6iM0gqA
Date: Mon, 27 Apr 2020 12:59:25 +0000
Message-ID: <59C12770-F12A-45B7-AB62-8BB3A0DC96D8@citrix.com>
References: <cover.1587682041.git.rosbrookn@ainfosec.com>
 <73e709cf0a87f3728de438e4a3b849462fd098ac.1587682041.git.rosbrookn@ainfosec.com>
In-Reply-To: <73e709cf0a87f3728de438e4a3b849462fd098ac.1587682041.git.rosbrookn@ainfosec.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <22A51F5E6C95384495B8EA5989CB86B1@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDI0LCAyMDIwLCBhdCA0OjAyIEFNLCBOaWNrIFJvc2Jyb29rIDxyb3Nicm9v
a25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE1hbnkgZXhwb3J0ZWQgZnVuY3Rpb25zIGluIHhl
bmxpZ2h0IHJlcXVpcmUgYSBkb21pZCBhcyBhbiBhcmd1bWVudC4gTWFrZQ0KPiBpdCBlYXNpZXIg
Zm9yIHBhY2thZ2UgdXNlcnMgdG8gdXNlIHRoZXNlIGZ1bmN0aW9ucyBieSBhZGRpbmcgd3JhcHBl
cnMNCj4gZm9yIHRoZSBsaWJ4bCB1dGlsaXR5IGZ1bmN0aW9ucyBsaWJ4bF9uYW1lX3RvX2RvbWlk
IGFuZA0KPiBsaWJ4bF9kb21pZF90b19uYW1lLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogTmljayBS
b3Nicm9vayA8cm9zYnJvb2tuQGFpbmZvc2VjLmNvbT4NCj4gLS0tDQo+IHRvb2xzL2dvbGFuZy94
ZW5saWdodC94ZW5saWdodC5nbyB8IDM4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0N
Cj4gMSBmaWxlIGNoYW5nZWQsIDM3IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gDQo+
IGRpZmYgLS1naXQgYS90b29scy9nb2xhbmcveGVubGlnaHQveGVubGlnaHQuZ28gYi90b29scy9n
b2xhbmcveGVubGlnaHQveGVubGlnaHQuZ28NCj4gaW5kZXggNmI0ZjQ5MjU1MC4uZDFkMzBiNjNl
MSAxMDA2NDQNCj4gLS0tIGEvdG9vbHMvZ29sYW5nL3hlbmxpZ2h0L3hlbmxpZ2h0LmdvDQo+ICsr
KyBiL3Rvb2xzL2dvbGFuZy94ZW5saWdodC94ZW5saWdodC5nbw0KPiBAQCAtMjEsMTMgKzIxLDEz
IEBAIHBhY2thZ2UgeGVubGlnaHQNCj4gI2NnbyBMREZMQUdTOiAtbHhlbmxpZ2h0IC1seWFqbCAt
bHhlbnRvb2xsb2cNCj4gI2luY2x1ZGUgPHN0ZGxpYi5oPg0KPiAjaW5jbHVkZSA8bGlieGwuaD4N
Cj4gKyNpbmNsdWRlIDxsaWJ4bF91dGlscy5oPg0KPiANCj4gc3RhdGljIGNvbnN0IGxpYnhsX2No
aWxkcHJvY19ob29rcyBjaGlsZHByb2NfaG9va3MgPSB7IC5jaGxkb3duZXIgPSBsaWJ4bF9zaWdj
aGxkX293bmVyX21haW5sb29wIH07DQo+IA0KPiB2b2lkIHhlbmxpZ2h0X3NldF9jaGxkcHJvYyhs
aWJ4bF9jdHggKmN0eCkgew0KPiAJbGlieGxfY2hpbGRwcm9jX3NldG1vZGUoY3R4LCAmY2hpbGRw
cm9jX2hvb2tzLCBOVUxMKTsNCj4gfQ0KPiAtDQo+ICovDQo+IGltcG9ydCAiQyINCj4gDQo+IEBA
IC03NSw2ICs3NSwxMCBAQCB2YXIgbGlieGxFcnJvcnMgPSBtYXBbRXJyb3Jdc3RyaW5new0KPiAJ
RXJyb3JGZWF0dXJlUmVtb3ZlZDogICAgICAgICAgICAgICAiRmVhdHVyZSByZW1vdmVkIiwNCj4g
fQ0KPiANCj4gK2NvbnN0ICgNCj4gKwlEb21pZEludmFsaWQgRG9taWQgPSBeRG9taWQoMCkNCg0K
Tm90IHRvIGJlIGEgc3RpY2tsZXIsIGJ1dCBhcmUgd2UgcG9zaXRpdmUgdGhhdCB0aGlzIHdpbGwg
YWx3YXlzIHJlc3VsdCBpbiB0aGUgc2FtZSB2YWx1ZSBhcyBDLklOVkFMSURfRE9NSUQ/DQoNClRo
ZXJlIGFyZSBzb21lIGZ1bmN0aW9ucyB0aGF0IHdpbGwgcmV0dXJuIElOVkFMSURfRE9NSUQsIG9y
IGFjY2VwdCBJTlZBTElEX0RPTUlEIGFzIGFuIGFyZ3VtZW50LiAgVXNlcnMgb2YgdGhlIGB4ZW5s
aWdodGAgcGFja2FnZSB3aWxsIHByZXN1bWFibHkgbmVlZCB0byBjb21wYXJlIGFnYWluc3QgdGhp
cyB2YWx1ZSBhbmQvb3IgcGFzcyBpdCBpbi4NCg0KSXQgc2VlbXMgbGlrZSB3ZSBjb3VsZDoNCg0K
MS4gUmVseSBvbiBsYW5ndWFnZSBsYXd5ZXJpbmcgdG8ganVzdGlmeSBvdXIgYXNzdW1wdGlvbiB0
aGF0IF5Eb21pZCgwKSB3aWxsIGFsd2F5cyBiZSB0aGUgc2FtZSBhcyBDIOKAnH4w4oCdDQoNCjIu
IE9uIG1hcnNoYWxsaW5nIGludG8gLyBvdXQgb2YgQywgY29udmVydCBDLklOVkFMSURfRE9NSUQg
dG8gRG9taWRJbnZhbGlkDQoNCjMuIFNldCBEb21pZCA9IEMuSU5WQUxJRF9ET01JRA0KDQpJZiB5
b3XigJlyZSBjb25maWRlbnQgaW4geW91ciBsYW5ndWFnZSBsYXd5ZXJpbmcgc2tpbGxzLCBJIGNv
dWxkIGFjY2VwdCAjMTsgYnV0IEnigJlkIHByZWZlciBhIGNvbW1lbnQgd2l0aCBzb21lIHNvcnQg
b2YgcmVmZXJlbmNlLiAgQnV0IGlmIGl0IHdlcmUgbWUgSeKAmWQganVzdCBnbyB3aXRoICMzOyBw
YXJ0aWN1bGFybHkgZ2l2ZW4gdGhhdCB0aGlzIHZhbHVlIGNvdWxkIHRoZW9yZXRpY2FsbHkgY2hh
bmdlIChsaWJ4bCBoYXMgYSBzdGFibGUgQVBJLCBub3QgYSBzdGFibGUgQUJJKS4NCg0KRXZlcnl0
aGluZyBlbHNlIGxvb2tzIGdvb2QuDQoNCklmIHlvdSB3YW50IEkgY291bGQgcy9+RG9taWQoMCkv
Qy5JTlZBTElEX0RPTUlELzsgbXlzZWxmLCBhZGQgbXkgUi1iIGFuZCBjaGVjayBpdCBpbi4NCg0K
IC1HZW9yZ2UNCg0K


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 13:00:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 13:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT3N2-00088f-Bn; Mon, 27 Apr 2020 13:00:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=R4Dr=6L=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jT3N0-00088Q-D1
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 13:00:22 +0000
X-Inumbo-ID: 0d2d80da-8887-11ea-977f-12813bfff9fa
Received: from mail-wm1-f65.google.com (unknown [209.85.128.65])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0d2d80da-8887-11ea-977f-12813bfff9fa;
 Mon, 27 Apr 2020 13:00:21 +0000 (UTC)
Received: by mail-wm1-f65.google.com with SMTP id r26so20370247wmh.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 06:00:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-disposition:in-reply-to:user-agent;
 bh=LnUbjfdhnW2cQzPGXLw/I6yVbj5MKutvg/n8jzalU2I=;
 b=sYBNMB7eg3kL1WanWgjrQLQXbjzGZgC/XJTsnTFeq4u1Eht06XU4wDjuYSidvJIOup
 KOBVqo59a7zau3An/WjXn7h+u+IaffwSyVdTlnLZpj84MedoR6lKxBLc8TJ0Z+BhIdp8
 AiXtGbVhVFfMlu8iJ1HbXlvc84iLLj+xgQqeyz2wXU3Kf0eDrDjbSuRNI9fQBpRu6up+
 XyWXfRxrPX5fAmu/ZBeN2fDWXKvnJiIu69IQTWPUkzkCqQ1W+D+RMBi0F25YqYCxKEe9
 Fw4TMpZ+cjMxaMsQe6p7fQUI6pAkrjBh859fAlzSqNwiZly7LUySQ7No48wRNdEjjNjD
 in7A==
X-Gm-Message-State: AGi0PubWBgrs+u3Wk80YsaYJAaSK2X605GaxeEAZHN1hnmrnV1XY9EHT
 IH0cAntbtfCh8z5py6icUrU=
X-Google-Smtp-Source: APiQypIabbyAMng5fSK2vjnfXexnB1Afetfm/uNn9kexjA2b7LMEfmHv4wnIxGxjBJKvnDSS7rruBA==
X-Received: by 2002:a7b:cbd6:: with SMTP id n22mr25144368wmi.98.1587992420782; 
 Mon, 27 Apr 2020 06:00:20 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id l15sm15083570wmi.48.2020.04.27.06.00.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 06:00:20 -0700 (PDT)
Date: Mon, 27 Apr 2020 13:00:18 +0000
From: Wei Liu <wl@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/pvh: Override opt_console_xen earlier
Message-ID: <20200427130018.une7jgupa7zggsok@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <20200427121944.1443-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200427121944.1443-1-andrew.cooper3@citrix.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 01:19:44PM +0100, Andrew Cooper wrote:
> This allows printk() to work from the start of day, and backtraces from as
> early as the IDT is set up.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 13:17:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 13:17:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT3dH-00012g-Ax; Mon, 27 Apr 2020 13:17:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jT3dF-00012b-QB
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 13:17:09 +0000
X-Inumbo-ID: 657b7ce0-8889-11ea-9781-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 657b7ce0-8889-11ea-9781-12813bfff9fa;
 Mon, 27 Apr 2020 13:17:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587993429;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=QNEMRm3aOz/vXC8CThrtL8kmn4AaSrbSZctPyHtEiqg=;
 b=V7cPtWxvpnaSY7nVZpu5Z+qoAcG7HwA3IGp+kdWFU9eq2NVAgHaFNJDL
 2dU2/H3M7tlzK2cA+woEQfpRcOTZdwHiOlG4JqjZ1BdpunzA8vmh6Atia
 CnJ7oDzkwiy6HKUE5dmb6f98BZp4Vle3kmYkCkIK/jgQK67vQlSg+NTgJ k=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: c9V0w1vFC+arBDDaY6OKbwzFhPivBwS/QKG2WCazcjtQ3c4wVyITEXmrlY9xYqvl4pkkFX0fyi
 yyRFgxOl6RSqDAut/ss6JhGIuxz4iEHR1/aE22EUxzegR1DNsyux4UJcsYYOPm4wliqiBECp4W
 SgfDYlCoRZvjV5eWT1ASiMVaj+txbOY+iejoZipFVHqt/WC9kt0ISG6wVMBGxznUHAd0s4QCYs
 beJn3BbC9niUXaoI7NBAaJniuMTzQOD4JojIMFJHcryk0plTD+8ae+bCjSl4bWSCyuCs6WcMvp
 n8E=
X-SBRS: 2.7
X-MesageID: 16552859
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16552859"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/IST: Fix comment about stack layout
Date: Mon, 27 Apr 2020 14:17:02 +0100
Message-ID: <20200427131702.13991-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This was an oversight in c/s 5d37af364dc "x86/traps: Use an Interrupt Stack
Table for #DB" which introduced the #DB IST to begin with.

Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/include/asm-x86/current.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-x86/current.h b/xen/include/asm-x86/current.h
index 0b47485337..39c2c6cbf8 100644
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -18,7 +18,7 @@
  * 6 - Primary stack
  * 5 - Optionally not present (MEMORY_GUARD)
  * 4 - Unused; optionally not present (MEMORY_GUARD)
- * 3 - Unused; optionally not present (MEMORY_GUARD)
+ * 3 -  DB IST stack
  * 2 - MCE IST stack
  * 1 - NMI IST stack
  * 0 - Double Fault IST stack
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 13:20:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 13:20:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT3g0-0001Aj-PJ; Mon, 27 Apr 2020 13:20:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=R4Dr=6L=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jT3fz-0001Ae-3N
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 13:19:59 +0000
X-Inumbo-ID: cab1314a-8889-11ea-b07b-bc764e2007e4
Received: from mail-wm1-f66.google.com (unknown [209.85.128.66])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cab1314a-8889-11ea-b07b-bc764e2007e4;
 Mon, 27 Apr 2020 13:19:58 +0000 (UTC)
Received: by mail-wm1-f66.google.com with SMTP id v8so16969wma.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 06:19:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-disposition:content-transfer-encoding
 :in-reply-to:user-agent;
 bh=SpZYwT0NHxT5rnUVIzIdlq47W3ArxQiY9+1sf5kBekg=;
 b=GSNHGRevoqrQMh1/nIKRrYuGQxQrARTftXFyZ5tiG2U35aOET9H8g/pN3qlCvOSSNk
 UPfbt0U+pBqek46K9BEfpD9URxwpUm/F5beHUyXciuE+NhejPauNU0b+N1zl04Hmx+v6
 ksubtrU+fc8wj/msg4KSEfCeyyTyotxky/wKfXAqp6At5SU5KA3m5Za5VE45x7o1oEZ3
 O0ZTj2pOTd9JgUTOamnxnM5ukQA4hWX//c0423WMmR0WhI9wxDlLH1IpgHhOX4GaI+tJ
 glz4kOSWA1ukV8hLJKLJfSvm5cfn0cdUBgLouKPTbvg63X1rxgYHyNW81RI/MyURNCiS
 zF+w==
X-Gm-Message-State: AGi0PuauvxXkF/yyY8/BV5w4JoANW37pYW+nh/YGt8+j5M6Cqk1vfBYP
 pu4MNRETBtyPWMX1HfD3lMQ=
X-Google-Smtp-Source: APiQypJzZ95E02qae4Hy8mtG8raa8tBypLV8WSL8JLAGhiSz4EhJY+0YuMZszu6mfBSOrnF6n7E3sA==
X-Received: by 2002:a1c:7d4b:: with SMTP id y72mr26905153wmc.11.1587993597744; 
 Mon, 27 Apr 2020 06:19:57 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id h1sm16355648wme.42.2020.04.27.06.19.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 06:19:57 -0700 (PDT)
Date: Mon, 27 Apr 2020 13:19:55 +0000
From: Wei Liu <wl@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/IST: Fix comment about stack layout
Message-ID: <20200427131955.tqcnjdppinr4oopk@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <20200427131702.13991-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200427131702.13991-1-andrew.cooper3@citrix.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 02:17:02PM +0100, Andrew Cooper wrote:
> This was an oversight in c/s 5d37af364dc "x86/traps: Use an Interrupt Stack
> Table for #DB" which introduced the #DB IST to begin with.
> 
> Reported-by: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Wei Liu <wl@xen.org>
> CC: Roger Pau Monn� <roger.pau@citrix.com>
> ---
>  xen/include/asm-x86/current.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-x86/current.h b/xen/include/asm-x86/current.h
> index 0b47485337..39c2c6cbf8 100644
> --- a/xen/include/asm-x86/current.h
> +++ b/xen/include/asm-x86/current.h
> @@ -18,7 +18,7 @@
>   * 6 - Primary stack
>   * 5 - Optionally not present (MEMORY_GUARD)
>   * 4 - Unused; optionally not present (MEMORY_GUARD)
> - * 3 - Unused; optionally not present (MEMORY_GUARD)
> + * 3 -  DB IST stack

There seems to be an extraneous space before "DB".

Wei.

>   * 2 - MCE IST stack
>   * 1 - NMI IST stack
>   * 0 - Double Fault IST stack
> -- 
> 2.11.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 13:24:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 13:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT3kO-00023W-Bw; Mon, 27 Apr 2020 13:24:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Ku7H=6L=gmail.com=dunlapg@srs-us1.protection.inumbo.net>)
 id 1jT3kM-00023R-8A
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 13:24:30 +0000
X-Inumbo-ID: 6c34ed18-888a-11ea-9887-bc764e2007e4
Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6c34ed18-888a-11ea-9887-bc764e2007e4;
 Mon, 27 Apr 2020 13:24:29 +0000 (UTC)
Received: by mail-ed1-x542.google.com with SMTP id s10so13410575edy.9
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 06:24:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=umich.edu; s=google-2016-06-03;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=WlBltR0rEF03k7xkTSaqZHk68lS67ZBdaAH6vyJV058=;
 b=o2/G6uxdtI8Tp1vMhgc8VqL4utKm7mZKffwOvQvlQ7zAm0yGFrXgPWNhLTiIsDdRuf
 D5N3P/aQ6kYuy6be9JpDJa0mzxZSg0ZDwpIKA9k7l7T9fNOAbJC8isCO6U9Ov9i2qAkY
 09OSXp6vKPgtTxXr99T2DJayi0mMRWTs3YJslflKQ0BvmJyqZE/6Rpj1jITwVfL1vMct
 rGLBdeR9+ONIK7UsoOmPZev9rU+K2AAeSlPGDLIJxIBpheJqVnU623/LqINb7qaeYkxo
 N3o7VDQ9wt7wH59A0xhIzz2liEAedx25SNLb3i83NpuIS6M5Vnab68iH89SFytdjPaEO
 pB9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=WlBltR0rEF03k7xkTSaqZHk68lS67ZBdaAH6vyJV058=;
 b=Q16KVfgsz4Y6ivf91xxdi+HsyYafvnRBfEA0eBdncJ/XNXUM0UQMHTvVSRnz2YkVvL
 S0zDfa2JV6d+qm5hWiQIJMOhkvuOFpm1eTn3ayaqEP6D1EBxy76ywBxn2hrycf7pFXUq
 DO73kmdpPETwAld04Vl4+tlcQSURbuI/2TuteJPKz7Ned5q4+4wVB5uYjgxbNXX7izCa
 KBNlEw+pZlowOEvGGJDQq53eSiWqez0pMYyhHFCUueJ5CQOpoTMfQClM6P4sALmHM9Tn
 j1AZ/uUeykVmbqcIXdvX/pf6gcVHRvtAMx8uPKGtK+t8SQEXR6OH3CQ28iRiFyjIP6Or
 B4vw==
X-Gm-Message-State: AGi0PuY3n6IrYXsY373GSGi25GzZ9HjI9GJSmT0LFypfc5ooyAVwFW+y
 xJMew3O4m4cqaWvREr6YM5yRea1Dcx2aoARwNX8=
X-Google-Smtp-Source: APiQypKgcdsaIUIbxSJbmjbCj3JjvyT+M/mQtGUqrOGBK4LLoFE78D+niHyID1BSkNhlejCaReMzQNuCv4dKQ97SnsQ=
X-Received: by 2002:a50:d90f:: with SMTP id t15mr18115503edj.209.1587993868740; 
 Mon, 27 Apr 2020 06:24:28 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587695896.git.rosbrookn@ainfosec.com>
 <4dbde331aa6a0f8a78d93b86ffaa396c367fc57f.1587695896.git.rosbrookn@ainfosec.com>
In-Reply-To: <4dbde331aa6a0f8a78d93b86ffaa396c367fc57f.1587695896.git.rosbrookn@ainfosec.com>
From: George Dunlap <dunlapg@umich.edu>
Date: Mon, 27 Apr 2020 14:24:17 +0100
Message-ID: <CAFLBxZZ_HpaTxbk6eOg_xQ7OjYUR4TJB3nKCh7BZEru3ewzqXQ@mail.gmail.com>
Subject: Re: [PATCH v2 1/2] tools: build golang tools if go compiler is present
To: Nick Rosbrook <rosbrookn@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000073acbe05a445a2d7"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--00000000000073acbe05a445a2d7
Content-Type: text/plain; charset="UTF-8"

On Fri, Apr 24, 2020 at 4:11 AM Nick Rosbrook <rosbrookn@gmail.com> wrote:

> By default, if the go compiler is found by the configure script, build
> the golang tools. If the compiler is not found, and --enable-golang was
> not explicitly set, do not build to the golang tools.
>
> The corresponding make variable is CONFIG_GOLANG. Remove CONFIG_GOLANG
> from tools/Rules.mk since the variable is now set by configure in
> config/Tools.mk.
>
> Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
> Acked-by: Wei Liu <wl@xen.org>
>

LGTM:

Acked-by: George Dunlap <george.dunlap@citrix.com>

--00000000000073acbe05a445a2d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 24, 2020 at 4:11 AM Nick =
Rosbrook &lt;<a href=3D"mailto:rosbrookn@gmail.com">rosbrookn@gmail.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">By d=
efault, if the go compiler is found by the configure script, build<br>
the golang tools. If the compiler is not found, and --enable-golang was<br>
not explicitly set, do not build to the golang tools.<br>
<br>
The corresponding make variable is CONFIG_GOLANG. Remove CONFIG_GOLANG<br>
from tools/Rules.mk since the variable is now set by configure in<br>
config/Tools.mk.<br>
<br>
Signed-off-by: Nick Rosbrook &lt;<a href=3D"mailto:rosbrookn@ainfosec.com" =
target=3D"_blank">rosbrookn@ainfosec.com</a>&gt;<br>
Acked-by: Wei Liu &lt;<a href=3D"mailto:wl@xen.org" target=3D"_blank">wl@xe=
n.org</a>&gt;<br></blockquote><div><br></div><div>LGTM:</div><div><br></div=
><div>Acked-by: George Dunlap &lt;<a href=3D"mailto:george.dunlap@citrix.co=
m">george.dunlap@citrix.com</a>&gt;</div><br></div></div>

--00000000000073acbe05a445a2d7--


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 13:30:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 13:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT3pu-0002rB-17; Mon, 27 Apr 2020 13:30:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=5iRA=6L=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jT3pt-0002r6-Ji
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 13:30:13 +0000
X-Inumbo-ID: 376c168c-888b-11ea-978a-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 376c168c-888b-11ea-978a-12813bfff9fa;
 Mon, 27 Apr 2020 13:30:10 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C4CC8ACA1;
 Mon, 27 Apr 2020 13:30:08 +0000 (UTC)
Subject: Re: [PATCH v2] docs/designs: re-work the xenstore migration
 document...
To: paul@xen.org, xen-devel@lists.xenproject.org
References: <20200427075342.149-1-paul@xen.org>
 <6004fb95-42e1-1ee3-5215-0d0dede73f0f@suse.com>
 <000a01d61c80$fd1e47a0$f75ad6e0$@xen.org>
 <ff0a5505-77aa-905b-7b77-af418a586a47@suse.com>
 <000c01d61c86$9a9ffd20$cfdff760$@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <5008fa39-016a-6e40-50f8-fe068f57772d@suse.com>
Date: Mon, 27 Apr 2020 15:30:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <000c01d61c86$9a9ffd20$cfdff760$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Paul Durrant' <pdurrant@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.20 13:25, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jürgen Groß <jgross@suse.com>
>> Sent: 27 April 2020 12:13
>> To: paul@xen.org; xen-devel@lists.xenproject.org
>> Cc: 'Paul Durrant' <pdurrant@amazon.com>
>> Subject: Re: [PATCH v2] docs/designs: re-work the xenstore migration document...
>>
>> On 27.04.20 12:45, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Jürgen Groß <jgross@suse.com>
>>>> Sent: 27 April 2020 11:37
>>>> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
>>>> Cc: Paul Durrant <pdurrant@amazon.com>
>>>> Subject: Re: [PATCH v2] docs/designs: re-work the xenstore migration document...
>>>>
>>>> On 27.04.20 09:53, Paul Durrant wrote:
>>>>> From: Paul Durrant <pdurrant@amazon.com>
>>>>>
>>>>> ... to specify a separate migration stream that will also be suitable for
>>>>> live update.
>>>>>
>>>>> The original scope of the document was to support non-cooperative migration
>>>>> of guests [1] but, since then, live update of xenstored has been brought into
>>>>> scope. Thus it makes more sense to define a separate image format for
>>>>> serializing xenstore state that is suitable for both purposes.
>>>>>
>>>>> The document has been limited to specifying a new image format. The mechanism
>>>>> for acquiring the image for live update or migration is not covered as that
>>>>> is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
>>>>> also expected that, when the first implementation of live update or migration
>>>>> making use of this specification is committed, that the document is moved from
>>>>> docs/designs into docs/specs.
>>>>>
>>>>> [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-
>> migration.md
>>>>>
>>>>> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
>>>>> ---
>>>>> Juergen Gross <jgross@suse.com>
>>>>> Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> George Dunlap <george.dunlap@citrix.com>
>>>>> Ian Jackson <ian.jackson@eu.citrix.com>
>>>>> Jan Beulich <jbeulich@suse.com>
>>>>> Julien Grall <julien@xen.org>
>>>>> Stefano Stabellini <sstabellini@kernel.org>
>>>>> Wei Liu <wl@xen.org>
>>>>
>>>> Mind adding CC: before those mail addresses in order to let git add
>>>> those to the recipients list?
>>>>
>>>
>>> D'oh... good spot.
>>>
>>>>>
>>>>> v2:
>>>>>     - Address comments from Juergen
>>>>
>>>> Not all unfortunately. :-(
>>>>
>>>
>>> OK.
>>>
>>>>> +### CONNECTION_DATA
>>>>>
>>>>> -Each WATCH_DATA record specifies a registered watch and is formatted as
>>>>> -follows:
>>>>> +For live update the image format will contain a `CONNECTION_DATA` record for
>>>>> +each connection to xenstore. For migration it will only contain a record for
>>>>> +the domain being migrated.
>>>>>
>>>>>
>>>>>     ```
>>>>> -    0       1       2       3     octet
>>>>> -+-------+-------+-------+-------+
>>>>> -| WATCH_DATA                    |
>>>>> -+-------------------------------+
>>>>> -| wpath length                  |
>>>>> -+-------------------------------+
>>>>> -| wpath data                    |
>>>>> -...
>>>>> -| pad (0 to 3 octets)           |
>>>>> -+-------------------------------+
>>>>> +    0       1       2       3       4       5       6       7    octet
>>>>> ++-------+-------+-------+-------+-------+-------+-------+-------+
>>>>> +| conn-id                       | pad                           |
>>>>> ++---------------+-----------------------------------------------+
>>>>> +| conn-type     | conn-spec
>>>>>     ...
>>>>
>>>> I asked whether it wouldn't be better to drop the pad and move conn-type
>>>> and a 2-byte (unified) flag field at its position. This together ...
>>>>
>>>>> ++-------------------------------+-------------------------------+
>>>>> +| data-len                      | data
>>>>>     +-------------------------------+
>>>>> -| token length                  |
>>>>> -+-------------------------------+
>>>>> -| token data                    |
>>>>>     ...
>>>>> -| pad (0 to 3 octets)           |
>>>>> -+-------------------------------+
>>>>>     ```
>>>>>
>>>>> -wpath length and token length are specified in octets (excluding the NUL
>>>>> -terminator). The wpath should be as described for the `WATCH` operation in
>>>>> -[2]. The token is an arbitrary string of octets not containing any NUL
>>>>> -values.
>>>>>
>>>>> +| Field       | Description                                     |
>>>>> +|-------------|-------------------------------------------------|
>>>>> +| `conn-id`   | A non-zero number used to identify this         |
>>>>> +|             | connection in subsequent connection-specific    |
>>>>> +|             | records                                         |
>>>>> +|             |                                                 |
>>>>> +| `conn-type` | 0x0000: shared ring                             |
>>>>> +|             | 0x0001: socket                                  |
>>>>> +|             |                                                 |
>>>>> +| `conn-spec` | See below                                       |
>>>>> +|             |                                                 |
>>>>> +| `data-len`  | The length (in octets) of any pending data not  |
>>>>> +|             | yet written to the connection                   |
>>>>> +|             |                                                 |
>>>>> +| `data`      | Pending data (may be empty)                     |
>>>>>
>>>>> -**TRANSACTION_DATA**
>>>>> +The format of `conn-spec` is dependent upon `conn-type`.
>>>>>
>>>>> +\pagebreak
>>>>>
>>>>> -Each TRANSACTION_DATA record specifies an open transaction and is formatted
>>>>> -as follows:
>>>>> +For `shared ring` connections it is as follows:
>>>>>
>>>>>
>>>>>     ```
>>>>> -    0       1       2       3     octet
>>>>> -+-------+-------+-------+-------+
>>>>> -| TRANSACTION_DATA              |
>>>>> -+-------------------------------+
>>>>> -| tx_id                         |
>>>>> -+-------------------------------+
>>>>> +    0       1       2       3       4       5       6       7    octet
>>>>> +                +-------+-------+-------+-------+-------+-------+
>>>>> +                | domid         | tdomid        | flags         |
>>>>> ++---------------+---------------+---------------+---------------+
>>>>> +| revtchn                       | levtchn                       |
>>>>> ++-------------------------------+-------------------------------+
>>>>> +| mfn                                                           |
>>>>> ++---------------------------------------------------------------+
>>>>
>>>> ... with dropping levtchn (which isn't needed IMO) will make it much
>>>> easier to have a union in C (which needs to be aligned to 8 bytes
>>>> and have a length of a multiple of 8 bytes due to mfn).
>>>>
>>>> So something like:
>>>>
>>>> struct xs_state_connection {
>>>>        uint32_t conn_id;
>>>>        uint16_t conn_type;
>>>> #define XS_STATE_CONN_TYPE_RING   0
>>>> #define XS_STATE_CONN_TYPE_SOCKET 1
>>>>        uint16_t flags;
>>>> #define XS_STATE_CONN_INTRODUCED  0x0001
>>>> #define XS_STATE_CONN_RELEASED    0x0002
>>>> #define XS_STATE_CONN_READONLY    0x0004
>>>>        union {
>>>>            struct {
>>>>                uint16_t domid;
>>>>                uint16_t tdomid;
>>>> #define XS_STATE_DOMID_INVALID  0xffffU
>>>>                uint32_t evtchn;
>>>>                uint64_t mfn;
>>>> #define XS_STATE_MFN_INVALID    0xffffffffffffffffUL
>>>>            } ring;
>>>>            int32_t socket_fd;
>>>>        } spec;
>>>>        uint32_t data_out_len;
>>>>        uint8_t  data[];
>>>> };
>>>
>>> The issue is making sure that the mfn is properly aligned. If I can drop the levtchn then this gets
>> easier.
>>>
>>>>
>>>>>     ```
>>>>>
>>>>> -where tx_id is the non-zero identifier values of an open transaction.
>>>>> -
>>>>>
>>>>> -### Protocol Extension
>>>>> +| Field      | Description                                      |
>>>>> +|------------|--------------------------------------------------|
>>>>> +| `domid`    | The domain-id that owns the shared page          |
>>>>> +|            |                                                  |
>>>>> +| `tdomid`   | The domain-id that `domid` acts on behalf of if  |
>>>>> +|            | it has been subject to an SET_TARGET             |
>>>>> +|            | operation [2] or DOMID_INVALID otherwise         |
>>>>
>>>> DOMID_INVALID needs to be defined (or we need a reference where it is
>>>> coming from).
>>>
>>> OK. It's in a public header... I'll reference it.
>>>
>>>>
>>>>> +|            |                                                  |
>>>>> +| `flags`    | A bit-wise OR of:                                |
>>>>> +|            | 0x0001: INTRODUCE has been issued                |
>>
>> Just realized, I think we can drop those flags.
>>
>> Reasoning: if INTRODUCE hasn't been issued, there can't be an active
>> connection to Xenstore for that domain, as Xenstore doesn't know about
>> the parameters to connect (especially the event channel is missing).
>>
>>>>> +|            | 0x0002: RELEASE has been issued                  |
>>
>> And the same applies here: RELEASE will drop the connection to the
>> domain, so it can't appear in a connection record.
>>
> 
> I think the presence of the RESUME command in xenstore.txt makes it non-obvious that we can forget about a domain once RELEASE has been called. The text there does say:
> 
> "It is not clear whether this is possible since one would
> normally expect a domain not to be restarted after being shut
> down without being destroyed in the meantime.  There are
> currently no users of this request in xen-unstable."
> 
> So, perhaps this would be the time to remove RESUME from the spec?

+1


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 13:31:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 13:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT3qp-0002vk-DQ; Mon, 27 Apr 2020 13:31:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=UCaW=6L=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jT3qo-0002vZ-L1
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 13:31:10 +0000
X-Inumbo-ID: 5795514e-888b-11ea-ae69-bc764e2007e4
Received: from mail-lj1-x241.google.com (unknown [2a00:1450:4864:20::241])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5795514e-888b-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 13:31:04 +0000 (UTC)
Received: by mail-lj1-x241.google.com with SMTP id g4so17600294ljl.2;
 Mon, 27 Apr 2020 06:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=BXSutSaL3U/QnQdOrk5RMz1W2afQvWJhycyk5uFYBlM=;
 b=cvTxq3G4KceguELJwbfuu230la5pvZXWBu0Gv/apJ2gdqILROr6K9DZp0zfXNeAXa2
 JEtmNvVyiG06eOnPrR6brRKzW9cWhejvFJnYzjVwB8xBHuUm2t7LpTCLOifTI5GeXkhO
 P00N2RS+YFJBF7UrP68MqPb4QOX2HiRG7yYBE3+LeDNCbBAEKUtUFgEe0bHWv68vJvlu
 EKMa5zoG2w4JVARl8o9ratVthIix2U4M1m22ySNCp5s4nbMNj2Oy01uMaNEEemFF2iVS
 L7mfYDlHXaUX9pk5kaHMchDRmZM+y4QZy9sQqY0ZWCm5fW28fy56d8xaYI2tkaH8jTz5
 Ii8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=BXSutSaL3U/QnQdOrk5RMz1W2afQvWJhycyk5uFYBlM=;
 b=nx3zayfSoeMlMKnk20VrMONA2u7AJgagDVra19H+QxbU8AMixzIMuCzuqp583RuhhV
 /rMY5WKqnJAmnVzb5j+Q8OVNOvZklx4qpbZH2sRwjG5YxwxUXtT4RnidWMKLeRsLvjxO
 GspfSr8bIZW7v+X9PUCDKpG/peMbqf7wZLQsxkmCKxlXv9bhKrVbFQfTBWos0eN7MJjO
 mwcTnN9UH/C5x0c4XNrRz6Kj2VigQ1V94ioOog80l3zskw5X4klWpvXbFh5laitaaFM4
 /xtrl2CRn3eOxQggpH2ecxe7/HN5iAJjl6zy59/dr6SePkrdoH4AtZW+UNAjkgEL37PL
 qNyQ==
X-Gm-Message-State: AGi0Pua0Msr+hhyojxArl0Httch+5HrtF+cXjkwtfGHcryuLOSr/K0do
 lQSdZnT84oVesGkyGCSkWh3nZEsfb5juryy9nFk=
X-Google-Smtp-Source: APiQypIG26yA+2Qnkf7imCJP1+eUS2LoVzIzaMi4JkV0OYpff/hgrOAP+MlEppppFo3QPXwTCgb+m2V+IuRVz8yqE5k=
X-Received: by 2002:a05:651c:1055:: with SMTP id
 x21mr11562351ljm.210.1587994263334; 
 Mon, 27 Apr 2020 06:31:03 -0700 (PDT)
MIME-Version: 1.0
References: <20200427034019.6251-1-jandryuk@gmail.com>
 <20200427075429.mshevnm2ype7tq32@function>
In-Reply-To: <20200427075429.mshevnm2ype7tq32@function>
From: Jason Andryuk <jandryuk@gmail.com>
Date: Mon, 27 Apr 2020 09:30:50 -0400
Message-ID: <CAKf6xpuh3v0H-22=7y83ioYsm2GnKOs+FO8nN2s3djXanUL9BQ@mail.gmail.com>
Subject: Re: [PATCH] mini-os: Avoid segfaults in tc{g,s}etattr
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Jason Andryuk <jandryuk@gmail.com>, 
 minios-devel@lists.xenproject.org, xen-devel <xen-devel@lists.xenproject.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 3:54 AM Samuel Thibault
<samuel.thibault@ens-lyon.org> wrote:
>
> Jason Andryuk, le dim. 26 avril 2020 23:40:19 -0400, a ecrit:
> > Commit c96c22f1d94 "mini-os: minimal implementations of some termios
> > functions" introduced implementations of tcgetattr and tcsetattr.
> > However, they do not check if files[fildes].cons.dev is non-NULL before
> > dereferencing.  This is not a problem for FDs allocated through
> > alloc_fd, but the files array pre-allocates FDs 0-2 for stdio.  Those
> > entries have a NULL .dev, so tc{g,s}etattr on them segfault.
> >
> > ioemu-stubdom segfaults when term_init() calls tcgetattr on FD 0.
> >
> > Restore tcgetattr and tcsetattr behavior when .dev is NULL equivalent to
> > unsupported_function as it was before c96c22f1d94.
> >
> > Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
>
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
> Thanks!

Thank you!

> > ---
> > I can't get ioemu-stubdom to start without this.  With this, the guest
> > just reboots immediately, but it does that with a non-stubdom
> > device_model_version="qemu-xen-traditional" .  The same guest disk image
> > (cirros 0.5.1) boots with a linux stubdom or non-stubdom Ubuntu
> > qemu-system-x86_64.

Ubuntu gcc-9 adds -fcf-protection by default.  Somehow that flag
caused rombios (I think) to restart.  Setting -fcf-protection=none
like below (probably just the EMBEDDED_EXTRA_CFLAGS part) lets rombios
start properly.  The hypervisor needs it as well via
EXTRA_CFLAGS_XEN_CORE=-fcf-protection=none and maybe also added to
xen/arch/x86/boot/build32.mk .

diff --git a/Config.mk b/Config.mk
index 0f303c79b2..efb3d42bc4 100644
--- a/Config.mk
+++ b/Config.mk
@@ -205,6 +205,7 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))

 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
+EMBEDDED_EXTRA_CFLAGS += -fcf-protection=none

 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
diff --git a/tools/firmware/Rules.mk b/tools/firmware/Rules.mk
index 26bbddccd4..0d33514d53 100644
--- a/tools/firmware/Rules.mk
+++ b/tools/firmware/Rules.mk
@@ -17,3 +17,4 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))

 # Extra CFLAGS suitable for an embedded type of environment.
 CFLAGS += -fno-builtin -msoft-float
+CFLAGS += -fcf-protection=none


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 13:51:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 13:51:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT4AE-0004ru-Ax; Mon, 27 Apr 2020 13:51:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=X1yy=6L=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jT4AC-0004rp-NR
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 13:51:12 +0000
X-Inumbo-ID: 26f5ef64-888e-11ea-b9cf-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 26f5ef64-888e-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 13:51:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587995471;
 h=from:to:cc:subject:date:message-id:content-id:
 content-transfer-encoding:mime-version;
 bh=UcWnhtSZ6cC6QO5mr6qFRlLEE54J/LZMNHSoYiv0dwM=;
 b=g4b+SkqIvwsf/2FlAmLK3hh042BAywa1rlLxntLq9CGnNmcHuPen21xn
 VG5ghL9MLuM0F8duhp0OVCEqxunxXEDp1wKwhad+8D053LPlKzdVM9WLx
 Dl7nnIded5nceEATTWE287iR24he68EVbQcp3xkEAqvMl1XhdmYAyZwZD A=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: URtzDiMgmtSMA4aYWDr6tyjtUQnvWNKUzq4tQrxlpfupUqhI/kMqD3+4njZcP6PhNzGAALmk5S
 pGCfTgJi0xXElycLM7tOwAlkmqAVt89mYAHGNsPp0bBwkbcA7TXMB62p8dSK3wGQv/ePIRK0jy
 t1KeGScbkq6J0XfURM42Xu1Cd+y7RmR0JWGgCjzVOn5WFZKhbFAMW/BfSuzDQUs5hQjepQBuYr
 Ndwv5bIXZdDRSO4sqRGNZ+68r1OYqD9IrOCsCr6BaKM2XMf5V8J15BmstH5PDjGwrz+5ZXp8X5
 rdc=
X-SBRS: 2.7
X-MesageID: 16618100
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16618100"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: Juergen Gross <jgross@suse.com>
Subject: Cpu on/offlining crash with core scheduling
Thread-Topic: Cpu on/offlining crash with core scheduling
Thread-Index: AQHWHJp8dUHIzvCapEuuomD+efJ+EQ==
Date: Mon, 27 Apr 2020 13:49:37 +0000
Message-ID: <1587995374653.73805@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-imapappendstamp: AMSPEX02CL03.citrite.net (15.00.1497.006)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2E1EC7D64281F04492A83B8A7C2ABA48@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Sergey
 Dyasli <sergey.dyasli@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Juergen,=0A=
=0A=
When I'm testing vcpu pinning with something like:=0A=
=0A=
     # xl vcpu-pin 0 0 2=0A=
     # xen-hptool cpu-offline 3=0A=
=0A=
     (offline / online CPUs {2,3} if the above is successful)=0A=
=0A=
I'm reliably seeing the following crash on the latest staging:=0A=
=0A=
(XEN) Watchdog timer detects that CPU1 is stuck!=0A=
(XEN) ----[ Xen-4.14-unstable  x86_64  debug=3Dy   Not tainted ]----=0A=
(XEN) CPU:    1=0A=
(XEN) RIP:    e008:[<ffff82d08025266d>] common/sched/core.c#sched_wait_rend=
ezvous_in+0x16c/0x385=0A=
(XEN) RFLAGS: 0000000000000002   CONTEXT: hypervisor=0A=
(XEN) rax: 000000000000f001   rbx: ffff82d0805c9118   rcx: ffff83085e750301=
=0A=
(XEN) rdx: 0000000000000001   rsi: ffff83086499b972   rdi: ffff83085e7503a6=
=0A=
(XEN) rbp: ffff83085e7dfe28   rsp: ffff83085e7dfdd8   r8:  ffff830864985440=
=0A=
(XEN) r9:  ffff83085e714068   r10: 0000000000000014   r11: 00000056b6a1aab2=
=0A=
(XEN) r12: ffff83086499e490   r13: ffff82d0805f26e0   r14: ffff83085e7503a0=
=0A=
(XEN) r15: 0000000000000001   cr0: 0000000080050033   cr4: 0000000000362660=
=0A=
(XEN) cr3: 0000000823a8e000   cr2: 00006026000f6fc0=0A=
(XEN) fsb: 0000000000000000   gsb: ffff888138dc0000   gss: 0000000000000000=
=0A=
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008=0A=
(XEN) Xen code around <ffff82d08025266d> (common/sched/core.c#sched_wait_re=
ndezvous_in+0x16c/0x385):=0A=
(XEN)  4c 89 f7 e8 dc a5 fd ff <4b> 8b 44 fd 00 48 8b 04 18 4c 3b 70 10 0f =
85 3f=0A=
(XEN) Xen stack trace from rsp=3Dffff83085e7dfdd8:=0A=
(XEN)    00000056b42128a6 ffff83086499ff30 ffff83086498a000 ffff83085e7dfe4=
8=0A=
(XEN)    0000000100000001 00000056b42128a6 ffff83086499e490 000000000000000=
0=0A=
(XEN)    0000000000000001 0000000000000001 ffff83085e7dfe78 ffff82d080252ae=
8=0A=
(XEN)    ffff83086498a000 0000000180230434 ffff83085e7503a0 ffff82d0805ceb0=
0=0A=
(XEN)    ffffffffffffffff ffff82d0805cea80 0000000000000000 ffff82d0805dea8=
0=0A=
(XEN)    ffff83085e7dfeb0 ffff82d08022c232 0000000000000001 ffff82d0805ceb0=
0=0A=
(XEN)    0000000000000001 0000000000000001 0000000000000001 ffff83085e7dfec=
0=0A=
(XEN)    ffff82d08022c2cd ffff83085e7dfef0 ffff82d08031cae9 ffff83086498a00=
0=0A=
(XEN)    ffff83086498a000 0000000000000001 0000000000000001 ffff83085e7dfde=
8=0A=
(XEN)    ffff88813021d700 ffff88813021d700 0000000000000000 000000000000000=
0=0A=
(XEN)    0000000000000007 ffff88813021d700 0000000000000246 0000000000007ff=
0=0A=
(XEN)    0000000000000000 000000000001ca00 0000000000000000 ffffffff810013a=
a=0A=
(XEN)    ffffffff8203d210 deadbeefdeadf00d deadbeefdeadf00d 000001000000000=
0=0A=
(XEN)    ffffffff810013aa 000000000000e033 0000000000000246 ffffc900400dfeb=
0=0A=
(XEN)    000000000000e02b 0000000000000000 0000000000000000 000000000000000=
0=0A=
(XEN)    0000000000000000 0000e01000000001 ffff83086498a000 00000037e43bd00=
0=0A=
(XEN)    0000000000362660 0000000000000000 8000000864980002 000006010000000=
0=0A=
(XEN)    0000000000000000=0A=
(XEN) Xen call trace:=0A=
(XEN)    [<ffff82d08025266d>] R common/sched/core.c#sched_wait_rendezvous_i=
n+0x16c/0x385=0A=
(XEN)    [<ffff82d080252ae8>] F common/sched/core.c#sched_slave+0x262/0x31e=
=0A=
(XEN)    [<ffff82d08022c232>] F common/softirq.c#__do_softirq+0x8a/0xbc=0A=
(XEN)    [<ffff82d08022c2cd>] F do_softirq+0x13/0x15=0A=
(XEN)    [<ffff82d08031cae9>] F arch/x86/domain.c#idle_loop+0x57/0xa7=0A=
(XEN)=0A=
(XEN) CPU0 @ e008:ffff82d08022c2b7 (process_pending_softirqs+0x53/0x56)=0A=
(XEN) CPU4 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callbacks=
+0x22e/0x24b)=0A=
(XEN) CPU2 @ e008:ffff82d08022c26f (process_pending_softirqs+0xb/0x56)=0A=
(XEN) CPU7 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callbacks=
+0x22e/0x24b)=0A=
(XEN) CPU3 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callbacks=
+0x22e/0x24b)=0A=
(XEN) CPU5 @ e008:ffff82d08022cc34 (_spin_lock+0x4d/0x62)=0A=
(XEN) CPU6 @ e008:ffff82d08022c264 (process_pending_softirqs+0/0x56)=0A=
(XEN)=0A=
(XEN) ****************************************=0A=
(XEN) Panic on CPU 1:=0A=
(XEN) FATAL TRAP: vector =3D 2 (nmi)=0A=
(XEN) [error_code=3D0000] , IN INTERRUPT CONTEXT=0A=
(XEN) ****************************************=0A=
(XEN)=0A=
(XEN) Reboot in five seconds...=0A=
(XEN) Executing kexec image on cpu1=0A=
(XEN) Shot down all CPUs=0A=
=0A=
=0A=
Is this something you can reproduce?=0A=
=0A=
--=0A=
Thanks,=0A=
Sergey=0A=


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 13:55:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 13:55:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT4EO-00054b-T4; Mon, 27 Apr 2020 13:55:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oTJa=6L=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jT4EO-00054T-4C
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 13:55:32 +0000
X-Inumbo-ID: c204b1e8-888e-11ea-b07b-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c204b1e8-888e-11ea-b07b-bc764e2007e4;
 Mon, 27 Apr 2020 13:55:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587995732;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=J36PZq0kqFOF4s314pkPTDMzn2pH4/e+72WdA2Thru8=;
 b=R8yVadpYnOR6pZM5KcWu28fh4A9i7YKkEBdMNfb8bvR7J210hYdWvhhh
 HPyIGbcT9dLc1Qp8CGI+nue1uPUUa5MsIA0xbT6thh+sNcdMV8Z0xUugo
 o8VUMwGnWGcmS2WOU49R8M7k2ieoMBWWvi43NmfM080hDXd30dYbj6119 M=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Pt04EeFHVcraiLoSHWM1T2bWTxs/ijhxN6q7ehpiNRd7NqjV9WyPXeStPeRfHA+kaH9NFfqyrx
 rk2HT2qGOJ4Xrw/6MU69bpapPX2szImRwHxtUpjGuWBpPPHR+FN7LRtr4/zYyA/+kZM3XSMcUy
 LWWniYxlBq/rUKisZTj5dEIG5Kosa2O5QfjDt+nIUG8j3MV9QGW1K/tam7nYuB0Rl7zFK64oJO
 SrgDwZUJCjMyuz36ndxh2KWrKkxD3WuGPOrejr0h3oGoMufdMR0d698GJFyo3RaieWnEKt/ZCu
 jXs=
X-SBRS: 2.7
X-MesageID: 16318850
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16318850"
From: George Dunlap <George.Dunlap@citrix.com>
To: Juergen Gross <JGross@suse.com>
Subject: Re: [PATCH v7 03/12] docs: add feature document for Xen hypervisor
 sysfs-like support
Thread-Topic: [PATCH v7 03/12] docs: add feature document for Xen hypervisor
 sysfs-like support
Thread-Index: AQHWCQXuk74OuSkPsUygWIUgRyzUHaiNA2+A
Date: Mon, 27 Apr 2020 13:55:27 +0000
Message-ID: <AB2368EA-FE62-4735-8064-98DE220B6F9E@citrix.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-4-jgross@suse.com>
In-Reply-To: <20200402154616.16927-4-jgross@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <0805748851396540939A1D33DBE3A576@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <Andrew.Cooper3@citrix.com>, Jan
 Beulich <jbeulich@suse.com>, Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQo+IE9uIEFwciAyLCAyMDIwLCBhdCA0OjQ2IFBNLCBKdWVyZ2VuIEdyb3NzIDxKR3Jvc3NAc3Vz
ZS5jb20+IHdyb3RlOg0KW3NuaXBdDQo+ICsqIHtWQUxVRSwgVkFMVUUsIC4uLiB9IC0tIGEgbGlz
dCBvZiBwb3NzaWJsZSB2YWx1ZXMgc2VwYXJhdGVkIGJ5ICIsIiBhbmQNCj4gKyAgZW5jbG9zZWQg
aW4gInsiIGFuZCAifSIuDQpbc25pcF0NCj4gK1NvIGFuIGVudHJ5IGNvdWxkIGxvb2sgbGlrZSB0
aGlzOg0KPiArDQo+ICsgICAgL2NwdS1idWdzL2FjdGl2ZS1wdi94cHRpID0gKCJObyJ8eyJkb20w
IiwgImRvbVUiLCAiUENJRCBvbiJ9KSBbdyxYODYsUFZdDQo+ICsNCj4gK1Bvc3NpYmxlIHZhbHVl
cyB3b3VsZCBiZSAiTm8iIG9yIGEgbGlzdCBvZiAiZG9tMCIsICJkb21VIiwgYW5kICJQQ0lEIG9u
Ii4NCg0KT25lIHRoaW5nIHRoYXQgd2FzbuKAmXQgY2xlYXIgdG8gbWUgaGVyZTogIERvZXMgdGhl
IOKAnGxpc3TigJ0gbG9vayBsaWtlDQoNCiAgICDigJxkb20wIiwg4oCcZG9tVSIsIOKAnFBDSUQg
b27igJ0NCg0Kb3IgDQoNCiAgICB7ZG9tMCwgZG9tVSwgUENJRCBvbn0NCg0Kb3INCg0KICAgIHvi
gJxkb20w4oCdLCDigJxkb21V4oCdLCDigJxQQ0lEIG9u4oCdfQ0KDQo/DQoNCkFub3RoZXIgcXVl
c3Rpb24gdGhhdCBvY2N1cnMgdG8gbWUgZnJvbSBhc2tpbmcgdGhpcyBxdWVzdGlvbjogaW4gYSBj
YXNlIGxpa2UgdGhpcywgYXJlIHdlIGdlbmVyYWxseSBleHBlY3RpbmcgdG8gaGF2ZSBvcHRpb25z
IHdpdGggc3BhY2VzIGluIHRoZW0gKGxpa2Ug4oCcUENJRCBvbuKAnSk/IEFuZC9vciwgYXJlIHdl
IGV4cGVjdGluZyB0aGUgc3RyaW5ncyB0aGVtc2VsdmVzIHRvIGhhdmUgcXVvdGVzIGluIHRoZW0/
IElmIHNvLCBjb21tYW5kcyB0byBtYW5pcHVsYXRlIHRoZXNlIHdpbGwgc3RhcnQgdG8gbG9vayBh
IGxpdHRsZSBnbmFybHk6DQoNCiAgICB4ZW5oeXBmcyB3cml0ZSA8cGF0aD4g4oCce1zigJ1kb20w
XOKAnSwgXOKAnVBDSUQgb25c4oCdfeKAnQ0KDQpJdCBzZWVtcyBsaWtlIGl0IHdvdWxkIGJlIG5p
Y2VyIHRvIGJlIGFibGUgdG8gd3JpdGU6DQoNCiAgICB4ZW5oeXBmcyB3cml0ZSA8cGF0aD4gIntk
b20wLCBQQ0lELW9ufeKAnQ0KDQooTWF5YmUgdGhpcyB3aWxsIGJlIG1hZGUgbW9yZSBjbGVhciBs
YXRlciBpbiB0aGUgc2VyaWVzLCBqdXN0IHRob3VnaHQgSeKAmWQgc2hhcmUgbXkgdGhvdWdodHMg
LyBjb25mdXNpb24gaGVyZS4pDQoNCiAtR2Vvcmdl


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 14:09:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 14:09:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT4Rc-0006LP-Gh; Mon, 27 Apr 2020 14:09:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT4Rb-0006LK-GS
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 14:09:11 +0000
X-Inumbo-ID: a9fce6d6-8890-11ea-9797-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a9fce6d6-8890-11ea-9797-12813bfff9fa;
 Mon, 27 Apr 2020 14:09:10 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 59E49ABB2;
 Mon, 27 Apr 2020 14:09:08 +0000 (UTC)
Subject: Re: [PATCH] x86: refine guest_mode()
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
 <20200427095913.GN28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <40d5c1b8-b68e-1aa8-b17e-77ba9afc6529@suse.com>
Date: Mon, 27 Apr 2020 16:08:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200427095913.GN28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.2020 11:59, Roger Pau Monné wrote:
> On Mon, Apr 27, 2020 at 10:03:05AM +0200, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/regs.h
>> +++ b/xen/include/asm-x86/regs.h
>> @@ -10,9 +10,10 @@
>>      /* Frame pointer must point into current CPU stack. */                    \
>>      ASSERT(diff < STACK_SIZE);                                                \
>>      /* If not a guest frame, it must be a hypervisor frame. */                \
>> -    ASSERT((diff == 0) || (r->cs == __HYPERVISOR_CS));                        \
>> +    if ( diff < PRIMARY_STACK_SIZE )                                          \
>> +        ASSERT(!diff || ((r)->cs == __HYPERVISOR_CS));                        \
> 
> Why not use:
> 
> ASSERT(diff >= PRIMARY_STACK_SIZE || !diff || ((r)->cs == __HYPERVISOR_CS));

Except for the longer (without being helpful imo) string reported if
the assertion triggers, I see not difference.

> I'm not sure I fully understand this layout, is it possible that you
> also need to account for the size of cpu_info?

Depends on how paranoid we want the checking here to be, but in going
further I wouldn't want this to become sub-page fine-grained if we
aren't first doing e.g. what I'm mentioning in the post-commit-message
remark.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 14:11:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 14:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT4Tv-00076a-UD; Mon, 27 Apr 2020 14:11:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT4Tu-00076V-2Z
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 14:11:34 +0000
X-Inumbo-ID: ff759734-8890-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ff759734-8890-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 14:11:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E3322ABB2;
 Mon, 27 Apr 2020 14:11:31 +0000 (UTC)
Subject: Re: [PATCH] x86/IST: Fix comment about stack layout
To: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200427131702.13991-1-andrew.cooper3@citrix.com>
 <20200427131955.tqcnjdppinr4oopk@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e9000549-f51a-430d-14ea-d5d4d5171ef2@suse.com>
Date: Mon, 27 Apr 2020 16:11:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200427131955.tqcnjdppinr4oopk@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.2020 15:19, Wei Liu wrote:
>> --- a/xen/include/asm-x86/current.h
>> +++ b/xen/include/asm-x86/current.h
>> @@ -18,7 +18,7 @@
>>   * 6 - Primary stack
>>   * 5 - Optionally not present (MEMORY_GUARD)
>>   * 4 - Unused; optionally not present (MEMORY_GUARD)
>> - * 3 - Unused; optionally not present (MEMORY_GUARD)
>> + * 3 -  DB IST stack
> 
> There seems to be an extraneous space before "DB".

I guess #DB was meant. With that

Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 14:12:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 14:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT4US-00079L-6y; Mon, 27 Apr 2020 14:12:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jT4UQ-00079C-JL
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 14:12:06 +0000
X-Inumbo-ID: 12afac5e-8891-11ea-b07b-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 12afac5e-8891-11ea-b07b-bc764e2007e4;
 Mon, 27 Apr 2020 14:12:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587996726;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=jXUEm1PTaUOMP/eGkSnRISxH2N3b47mp86SBXqTFxsA=;
 b=HQyx3ZKsgzV9B9NU+yftde48mbPIN4mMR0hnaU6kYf2Rfw2bwuUmrg4z
 FMMEaCiW0pNk5I7/Iyw4eyO0R+TJHPXBrjMOwWB6MiumQVZa8lu143PCP
 yEX+639+DWlvUdB9UksDq94DLp2mGD3YRekOza1jk2rLwx+flWb7N0QRJ M=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: QRNQ54Z/WDflkmhtlh0cQ5oCv0/rybnATTDaESuXIwMqCNWsm9ycpqX49YhsofDHO1wxKM++5R
 hhuErKfogIzEq8eT24EqSG+JAApEf1B8QqXO6qe0DCqgmCbhqzgUJ7CjxgzVLp9O1daXqk+Lj8
 RFw1tYMiUNvAjlcVIIuaY+V0onm+tAKyRnqiMfgf7MIPxMGovjJiDgOKgJ7ApeqKx1o5lmeO4l
 vDJJyiJjCThNLlu24j2amQR/mgcoBKCSUuIgE9jy4l85BoOVPo1Y8TFwWwm1ywcZvjWqWETSp0
 uhc=
X-SBRS: 2.7
X-MesageID: 16320225
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16320225"
Subject: Re: [PATCH] x86/IST: Fix comment about stack layout
To: Wei Liu <wl@xen.org>
References: <20200427131702.13991-1-andrew.cooper3@citrix.com>
 <20200427131955.tqcnjdppinr4oopk@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <4e71ae01-6310-b292-dab0-1941c0bca6d9@citrix.com>
Date: Mon, 27 Apr 2020 15:12:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200427131955.tqcnjdppinr4oopk@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27/04/2020 14:19, Wei Liu wrote:
> On Mon, Apr 27, 2020 at 02:17:02PM +0100, Andrew Cooper wrote:
>> This was an oversight in c/s 5d37af364dc "x86/traps: Use an Interrupt Stack
>> Table for #DB" which introduced the #DB IST to begin with.
>>
>> Reported-by: Jan Beulich <JBeulich@suse.com>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Wei Liu <wl@xen.org>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> ---
>>  xen/include/asm-x86/current.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/include/asm-x86/current.h b/xen/include/asm-x86/current.h
>> index 0b47485337..39c2c6cbf8 100644
>> --- a/xen/include/asm-x86/current.h
>> +++ b/xen/include/asm-x86/current.h
>> @@ -18,7 +18,7 @@
>>   * 6 - Primary stack
>>   * 5 - Optionally not present (MEMORY_GUARD)
>>   * 4 - Unused; optionally not present (MEMORY_GUARD)
>> - * 3 - Unused; optionally not present (MEMORY_GUARD)
>> + * 3 -  DB IST stack
> There seems to be an extraneous space before "DB".

Yes.  The alternative would be for misaligned tabulation with the lower
"IST stack".

~Andrew

>
> Wei.
>
>>   * 2 - MCE IST stack
>>   * 1 - NMI IST stack
>>   * 0 - Double Fault IST stack
>> -- 
>> 2.11.0
>>



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 14:35:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 14:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT4qj-0000iQ-4t; Mon, 27 Apr 2020 14:35:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jT4qh-0000iL-Ue
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 14:35:07 +0000
X-Inumbo-ID: 4a0c3d0e-8894-11ea-ae69-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4a0c3d0e-8894-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 14:35:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587998106;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=qfPwzTU8z22Y826YRtb7uFhL6caY9cIuJp0bLZ1nSDk=;
 b=D9HhxJQqrkPoDC2jqd7X0FjScfG2t9T0fkptYMb5douH4/9j1voUQPl0
 LyP3Os/caXwCi4gf1qODLTXN643wgfaB4T0gmUU19VjMhzpZQ7I6nmIFq
 PqV75m/veBZIocO26Xwnqs8fgNVADMIBT+rq3bKyUxN3RJhk9S4SXlZCx U=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: ssJjDd9S96dLAJP/8qOACJCYo+nL+EhG9ojo3Ow4+UPHwSA+wl+aAQ2PxlkBWLhx5bGrNjz7aG
 Yp94yMgLkt68CHfcHNhSGuTf6D/oDh+J4EPDQWrA56YiY6Ib5Bw25yPriuemIYTjj6xAHRpYVv
 0G1hD5j6CiDnW+yvyuzj8mWC/LUfkmpyPJNrzGOqqd5AtiPcvqJi7jmK+rpgMPA/7z4ymPTPvn
 MJW8F6nLDpnBaZNNOTz0Fpk+0sNCUVNHv3ld0FN1h8sE4EG2hihgbAZVBOJRhNldavAiYfh/xs
 Xtc=
X-SBRS: 2.7
X-MesageID: 16707710
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16707710"
Subject: Re: [PATCH] x86: refine guest_mode()
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <1704f4f6-7e77-971c-2c94-4f6a6719c34a@citrix.com>
Date: Mon, 27 Apr 2020 15:35:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27/04/2020 09:03, Jan Beulich wrote:
> The 2nd of the assertions as well as the macro's return value have been
> assuming we're on the primary stack. While for most IST exceptions we
> eventually switch back to the main one,

"we switch to the main one when interrupting user mode".

"eventually" isn't accurate as it is before we enter C.

>  for #DF we intentionally never
> do, and hence a #DF actually triggering on a user mode insn (which then
> is still a Xen bug) would in turn trigger this assertion, rather than
> cleanly logging state.
>
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> While we could go further and also assert we're on the correct IST
> stack in an "else" ti the "if()" added, I'm not fully convinced this
> would be generally helpful. I'll be happy to adjust accordingly if
> others think differently; at such a point though I think this should
> then no longer be a macro.
>
> --- a/xen/include/asm-x86/regs.h
> +++ b/xen/include/asm-x86/regs.h
> @@ -10,9 +10,10 @@
>      /* Frame pointer must point into current CPU stack. */                    \
>      ASSERT(diff < STACK_SIZE);                                                \
>      /* If not a guest frame, it must be a hypervisor frame. */                \
> -    ASSERT((diff == 0) || (r->cs == __HYPERVISOR_CS));                        \
> +    if ( diff < PRIMARY_STACK_SIZE )                                          \
> +        ASSERT(!diff || ((r)->cs == __HYPERVISOR_CS));                        \
>      /* Return TRUE if it's a guest frame. */                                  \
> -    (diff == 0);                                                              \
> +    !diff || ((r)->cs != __HYPERVISOR_CS);                                    \

The (diff == 0) already worried me before because it doesn't fail safe,
but this makes things more problematic.  Consider the case back when we
had __HYPERVISOR_CS32.

Guest mode is strictly "(r)->cs & 3".

Everything else is expectations about how things ought to be laid out,
but for safety in release builds, the final judgement should not depend
on the expectations evaluating true.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 14:53:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 14:53:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT588-0002VR-Qt; Mon, 27 Apr 2020 14:53:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oTJa=6L=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jT587-0002VM-QG
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 14:53:07 +0000
X-Inumbo-ID: cd7dec12-8896-11ea-979f-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cd7dec12-8896-11ea-979f-12813bfff9fa;
 Mon, 27 Apr 2020 14:53:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1587999186;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=9DYxkeewgV9HN51YorpsBNq7toaYubW4PXRlkINECSA=;
 b=iejMp5HjrohXaeuaPVTNJb9h3euUdztR+hhRFhtF1kyDxCqT2xQ0WO00
 u9e8Jc3EHuGf5zK8yY9vrhNa97FXkiEoVfmtBqM7JM1VAy0IBZ8V4BCoe
 JyA2O8+XA4dd9l18/2l8z4Tqd/+oAsU/KFSL6/XQRxM70EASHEIx2xpSb o=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: CuaWtyIHlDESKnT8b+f9JHscWtBGC8v7OKdfh4p5xheYxazfMu2QiVNZieZoELJXz3fMnUF8Mn
 //PVB0TZ/AUCxv6vHrVJoM+0vfkyHmpE2NcCflOmJC54njzVPnMu17f51ArZx8JAWogLb/9Ha4
 8wHZbYJF5FADjUa8RraysxOGB/CaOLBt8YcC58ELhEZcYljBXAMdVL0zK8NMbYKTxEz6HWb/WK
 qe7n1599Sz49fgjZX/Xu0RGpa1Yx37IaMu4cdgG/M6IIPzkBTHIePxAwdIqhvUrj82HSGwozN1
 mFA=
X-SBRS: 2.7
X-MesageID: 16708959
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16708959"
From: George Dunlap <George.Dunlap@citrix.com>
To: Juergen Gross <JGross@suse.com>
Subject: Re: [PATCH v7 05/12] libs: add libxenhypfs
Thread-Topic: [PATCH v7 05/12] libs: add libxenhypfs
Thread-Index: AQHWCQXg1A1EagdjCU+LQG90+ev/tKiNE4YA
Date: Mon, 27 Apr 2020 14:53:03 +0000
Message-ID: <936102D2-0655-43EA-B52A-DED46E9E07D0@citrix.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-6-jgross@suse.com>
In-Reply-To: <20200402154616.16927-6-jgross@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <40B40089106A524BB53839123E594002@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <Andrew.Cooper3@citrix.com>, Jan
 Beulich <jbeulich@suse.com>, Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDIsIDIwMjAsIGF0IDQ6NDYgUE0sIEp1ZXJnZW4gR3Jvc3MgPEpHcm9zc0Bz
dXNlLmNvbT4gd3JvdGU6DQo+IA0KPiBBZGQgdGhlIG5ldyBsaWJyYXJ5IGxpYnhlbmh5cGZzIGZv
ciBhY2Nlc3MgdG8gdGhlIGh5cGVydmlzb3IgZmlsZXN5c3RlbS4NCj4gDQo+IFNpZ25lZC1vZmYt
Ynk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCj4gQWNrZWQtYnk6IFdlaSBMaXUg
PHdsQHhlbi5vcmc+DQoNCkp1c3QgYSBmZXcgcXVlc3Rpb25zLi4uDQoNCj4gKy8qIFJldHVybmVk
IGJ1ZmZlciBhbmQgZGlyZW50IHNob3VsZCBiZSBmcmVlZCB2aWEgZnJlZSgpLiAqLw0KPiArdm9p
ZCAqeGVuaHlwZnNfcmVhZF9yYXcoeGVuaHlwZnNfaGFuZGxlICpmc2hkbCwgY29uc3QgY2hhciAq
cGF0aCwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB4ZW5oeXBmc19kaXJlbnQg
KipkaXJlbnQpOw0KPiArDQo+ICsvKiBSZXR1cm5lZCBidWZmZXIgc2hvdWxkIGJlIGZyZWVkIHZp
YSBmcmVlKCkuICovDQo+ICtjaGFyICp4ZW5oeXBmc19yZWFkKHhlbmh5cGZzX2hhbmRsZSAqZnNo
ZGwsIGNvbnN0IGNoYXIgKnBhdGgpOw0KDQpXaGF04oCZcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVu
IHRoZXNlIHR3bz8gIEFuZCB3aGF04oCZcyB0aGUgYGRpcmVudGAgYXJndW1lbnQgdG8geGVuaHlw
ZnNfcmVhZF9yYXcoKSBmb3I/DQoNCiAtR2VvcmdlDQoNCg==


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:06:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT5L4-0003bq-2F; Mon, 27 Apr 2020 15:06:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=m6ex=6L=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jT5L2-0003bl-D8
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:06:28 +0000
X-Inumbo-ID: ab063624-8898-11ea-97a5-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ab063624-8898-11ea-97a5-12813bfff9fa;
 Mon, 27 Apr 2020 15:06:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=musSBhNJyvDBisUPoFZUEgX32SY7Gykg87vzZNmJm6c=; b=PQUjLOh61kxKfg7hxQ72s0AImM
 GvdFkQbG2mqGnRktpBj1kcGbV4LPNz9kEb13C1dOvOm3vPcm9nsbvXrnEW1Mln2kvvjR0YJunLenS
 Jpiyi8u8mkwq0EHlLDxJ2bMQkgWwJE/P8x0M8LMIpeHE8phMbo/Kbt/e86APTMild+Yw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <paul@xen.org>)
 id 1jT5L0-0001YW-T5; Mon, 27 Apr 2020 15:06:26 +0000
Received: from [54.239.6.186] (helo=CBG-R90WXYV0.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jT5L0-0006Id-DC; Mon, 27 Apr 2020 15:06:26 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v3] docs/designs: re-work the xenstore migration document...
Date: Mon, 27 Apr 2020 16:06:20 +0100
Message-Id: <20200427150620.540-1-paul@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Durrant <pdurrant@amazon.com>

... to specify a separate migration stream that will also be suitable for
live update.

The original scope of the document was to support non-cooperative migration
of guests [1] but, since then, live update of xenstored has been brought into
scope. Thus it makes more sense to define a separate image format for
serializing xenstore state that is suitable for both purposes.

The document has been limited to specifying a new image format. The mechanism
for acquiring the image for live update or migration is not covered as that
is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
also expected that, when the first implementation of live update or migration
making use of this specification is committed, that the document is moved from
docs/designs into docs/specs.

NOTE: It will only be necessary to save and restore state for active xenstore
      connections, but the documentation for 'RESUME' in xenstore.txt implies
      otherwise. That command is unused so this patch deletes it from the
      specification.

[1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Wei Liu <wl@xen.org>

v3:
 - Address missed comments from Juergen

v2:
 - Address comments from Juergen
---
 docs/designs/xenstore-migration.md | 470 +++++++++++++++++++----------
 docs/misc/xenstore.txt             |  17 --
 2 files changed, 308 insertions(+), 179 deletions(-)

diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
index 6ab351e8fe..61db212507 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -3,254 +3,400 @@
 ## Background
 
 The design for *Non-Cooperative Migration of Guests*[1] explains that extra
-save records are required in the migrations stream to allow a guest running
-PV drivers to be migrated without its co-operation. Moreover the save
-records must include details of registered xenstore watches as well as
-content; information that cannot currently be recovered from `xenstored`,
-and hence some extension to the xenstore protocol[2] will also be required.
-
-The *libxenlight Domain Image Format* specification[3] already defines a
-record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
-transferring xenstore data pertaining to the domain directly as it is
-specified such that keys are relative to the path
-`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
-define at least one new save record type.
+save records are required in the migrations stream to allow a guest running PV
+drivers to be migrated without its co-operation. Moreover the save records must
+include details of registered xenstore watches as well ascontent; information
+that cannot currently be recovered from `xenstored`, and hence some extension
+to the xenstored implementations will also be required.
+
+As a similar set of data is needed for transferring xenstore data from one
+instance to another when live updating xenstored this document proposes an
+image format for a 'migration stream' suitable for both purposes.
 
 ## Proposal
 
-### New Save Record
+The image format consists of a _header_ followed by 1 or more _records_. Each
+record consists of a type and length field, followed by any data mandated by
+the record type. At minimum there will be a single record of type `END`
+(defined below).
 
-A new mandatory record type should be defined within the libxenlight Domain
-Image Format:
+### Header
 
-`0x00000007: DOMAIN_XENSTORE_DATA`
+The header identifies the stream as a `xenstore` stream, including the version
+of the specification that it complies with.
 
-An arbitrary number of these records may be present in the migration
-stream and may appear in any order. The format of each record should be as
-follows:
+All fields in this header must be in _big-endian_ byte order, regardless of
+the setting of the endianness bit.
 
 
 ```
     0       1       2       3       4       5       6       7    octet
 +-------+-------+-------+-------+-------+-------+-------+-------+
-| type                          | record specific data          |
-+-------------------------------+                               |
-...
-+---------------------------------------------------------------+
+| ident                                                         |
++-------------------------------+-------------------------------|
+| version                       | flags                         |
++-------------------------------+-------------------------------+
 ```
 
-where type is one of the following values
 
+| Field     | Description                                       |
+|-----------|---------------------------------------------------|
+| `ident`   | 0x78656e73746f7265 ('xenstore' in ASCII)          |
+|           |                                                   |
+| `version` | 0x00000001 (the version of the specification)     |
+|           |                                                   |
+| `flags`   | 0 (LSB): Endianness: 0 = little, 1 = big          |
+|           |                                                   |
+|           | 1-31: Reserved (must be zero)                     |
 
-| Field  | Description                                      |
-|--------|--------------------------------------------------|
-| `type` | 0x00000000: invalid                              |
-|        | 0x00000001: NODE_DATA                            |
-|        | 0x00000002: WATCH_DATA                           |
-|        | 0x00000003: TRANSACTION_DATA                     |
-|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
+### Records
 
+Records immediately follow the header and have the following format:
 
-and data is one of the record data formats described in the following
-sections.
 
+```
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| type                          | len                           |
++-------------------------------+-------------------------------+
+| body
+...
+|       | padding (0 to 7 octets)                               |
++-------+-------------------------------------------------------+
+```
+
+NOTE: padding octets here and in all subsequent format specifications must be
+      written as zero and should be ignored when the stream is read.
 
-NOTE: The record data does not contain an overall length because the
-libxenlight record header specifies the length.
 
+| Field  | Description                                          |
+|--------|------------------------------------------------------|
+| `type` | 0x00000000: END                                      |
+|        | 0x00000001: GLOBAL_DATA                              |
+|        | 0x00000002: CONNECTION_DATA                          |
+|        | 0x00000003: WATCH_DATA                               |
+|        | 0x00000004: TRANSACTION_DATA                         |
+|        | 0x00000005: NODE_DATA                                |
+|        | 0x00000006 - 0xFFFFFFFF: reserved for future use     |
+|        |                                                      |
+| `len`  | The length (in octets) of `body`                     |
+|        |                                                      |
+| `body` | The type-specific record data                        |
 
-**NODE_DATA**
+Some records will depend on other records in the migration stream. Records
+upon which other records depend must always appear earlier in the stream.
 
+The various formats of the type-specific data are described in the following
+sections:
 
-Each NODE_DATA record specifies a single node in xenstore and is formatted
-as follows:
+\pagebreak
 
+### END
+
+The end record marks the end of the image, and is the final record
+in the stream.
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| NODE_DATA                     |
-+-------------------------------+
-| path length                   |
-+-------------------------------+
-| path data                     |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
-| perm count (N)                |
-+-------------------------------+
-| perm0                         |
-+-------------------------------+
-...
-+-------------------------------+
-| permN                         |
-+-------------------------------+
-| value length                  |
-+-------------------------------+
-| value data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
 ```
 
-where perm0..N are formatted as follows:
 
+The end record contains no fields; its body length is 0.
+
+\pagebreak
+
+### GLOBAL_DATA
+
+This record is only relevant for live update. It contains details of global
+xenstored state that needs to be restored.
 
 ```
-    0       1       2       3     octet
+    0       1       2       3    octet
 +-------+-------+-------+-------+
-| perm  | pad   | domid         |
+| rw-socket-fd                  |
++-------------------------------+
+| ro-socket-fd                  |
 +-------------------------------+
 ```
 
 
-path length and value length are specified in octets (excluding the NUL
-terminator of the path). perm should be one of the ASCII values `w`, `r`,
-`b` or `n` as described in [2]. All pad values should be 0.
-All paths should be absolute (i.e. start with `/`) and as described in
-[2].
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `rw-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-write connections                       |
+|                |                                              |
+| `ro-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-only connections                        |
 
+xenstored will resume in the original process context. Hence `rw-socket-fd` and
+`ro-socket-fd` simply specify the file descriptors of the sockets.
 
-**WATCH_DATA**
 
+\pagebreak
 
-Each WATCH_DATA record specifies a registered watch and is formatted as
-follows:
+### CONNECTION_DATA
+
+For live update the image format will contain a `CONNECTION_DATA` record for
+each connection to xenstore. For migration it will only contain a record for
+the domain being migrated.
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| WATCH_DATA                    |
-+-------------------------------+
-| wpath length                  |
-+-------------------------------+
-| wpath data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| conn-id                       | conn-type     | conn-spec
 ...
++-------------------------------+-------------------------------+
+| data-len                      | data
 +-------------------------------+
-| token length                  |
-+-------------------------------+
-| token data                    |
 ...
-| pad (0 to 3 octets)           |
-+-------------------------------+
 ```
 
-wpath length and token length are specified in octets (excluding the NUL
-terminator). The wpath should be as described for the `WATCH` operation in
-[2]. The token is an arbitrary string of octets not containing any NUL
-values.
 
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | A non-zero number used to identify this         |
+|             | connection in subsequent connection-specific    |
+|             | records                                         |
+|             |                                                 |
+| `conn-type` | 0x0000: shared ring                             |
+|             | 0x0001: socket                                  |
+|             |                                                 |
+| `conn-spec` | See below                                       |
+|             |                                                 |
+| `data-len`  | The length (in octets) of any pending data not  |
+|             | yet written to the connection                   |
+|             |                                                 |
+| `data`      | Pending data (may be empty)                     |
 
-**TRANSACTION_DATA**
+The format of `conn-spec` is dependent upon `conn-type`.
 
+\pagebreak
 
-Each TRANSACTION_DATA record specifies an open transaction and is formatted
-as follows:
+For `shared ring` connections it is as follows:
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| TRANSACTION_DATA              |
-+-------------------------------+
-| tx_id                         |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
+                                                +-------+-------+
+                                                | flags         |
++---------------+---------------+---------------+---------------+
+| domid         | tdomid        | evtchn                        |
++-------------------------------+-------------------------------+
+| mfn                                                           |
++---------------------------------------------------------------+
 ```
 
-where tx_id is the non-zero identifier values of an open transaction.
 
+| Field     | Description                                       |
+|-----------|---------------------------------------------------|
+| `domid`   | The domain-id that owns the shared page           |
+|           |                                                   |
+| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
+|           | it has been subject to an SET_TARGET              |
+|           | operation [2] or DOMID_INVALID [3] otherwise      |
+|           |                                                   |
+| `flags`   | Must be zero                                      |
+|           |                                                   |
+| `evtchn`  | The port number of the interdomain channel used   |
+|           | by `domid` to communicate with xenstored          |
+|           |                                                   |
+| `mfn`     | The MFN of the shared page for a live update or   |
+|           | ~0 (i.e. all bits set) otherwise                  |
 
-### Protocol Extension
+Since the ABI guarantees that entry 1 in `domid`'s grant table will always
+contain the GFN of the shared page, so for a live update `mfn` can be used to
+give confidence that `domid` has not been re-cycled during the update.
 
-Before xenstore state is migrated it is necessary to wait for any pending
-reads, writes, watch registrations etc. to complete, and also to make sure
-that xenstored does not start processing any new requests (so that new
-requests remain pending on the shared ring for subsequent processing on the
-new host). Hence the following operation is needed:
 
-```
-QUIESCE                 <domid>|
+For `socket` connections it is as follows:
+
 
-Complete processing of any request issued by the specified domain, and
-do not process any further requests from the shared ring.
+```
+                                                +-------+-------+
+                                                | flags         |
++---------------+---------------+---------------+---------------+
+| socket-fd                     | pad                           |
++-------------------------------+-------------------------------+
+| pad                                                           |
++---------------------------------------------------------------+
 ```
 
-The `WATCH` operation does not allow specification of a `<domid>`; it is
-assumed that the watch pertains to the domain that owns the shared ring
-over which the operation is passed. Hence, for the tool-stack to be able
-to register a watch on behalf of a domain a new operation is needed:
 
-```
-ADD_DOMAIN_WATCHES      <domid>|<watch>|+
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `flags`     | A bit-wise OR of:                               |
+|             | 0001: read-only                                 |
+|             |                                                 |
+| `socket-fd` | The file descriptor of the connected socket     |
 
-Adds watches on behalf of the specified domain.
+This type of connection is only relevant for live update, where the xenstored
+resumes in the original process context. Hence `socket-fd` simply specify
+the file descriptor of the socket connection.
 
-<watch> is a NUL separated tuple of <path>|<token>. The semantics of this
-operation are identical to the domain issuing WATCH <path>|<token>| for
-each <watch>.
-```
+\pagebreak
+
+### WATCH_DATA
+
+The image format will contain a `WATCH_DATA` record for each watch registered
+by a connection for which there is `CONNECTION_DATA` record previously present.
 
-The watch information for a domain also needs to be extracted from the
-sending xenstored so the following operation is also needed:
 
 ```
-GET_DOMAIN_WATCHES      <domid>|<index>   <gencnt>|<watch>|*
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++---------------+---------------+
+| wpath-len     | token-len     |
++---------------+---------------+
+| wpath
+...
+| token
+...
+```
+
 
-Gets the list of watches that are currently registered for the domain.
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | The connection that issued the `WATCH`          |
+|             | operation [2]                                   |
+|             |                                                 |
+| `wpath-len` | The length (in octets) of `wpath` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `token-len` | The length (in octets) of `token` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `wpath`     | The watch path, as specified in the `WATCH`     |
+|             | operation                                       |
+|             |                                                 |
+| `token`     | The watch identifier token, as specified in the |
+|             | `WATCH` operation                               |
 
-<watch> is a NUL separated tuple of <path>|<token>. The sub-list returned
-will start at <index> items into the the overall list of watches and may
-be truncated (at a <watch> boundary) such that the returned data fits
-within XENSTORE_PAYLOAD_MAX.
+\pagebreak
 
-If <index> is beyond the end of the overall list then the returned sub-
-list will be empty. If the value of <gencnt> changes then it indicates
-that the overall watch list has changed and thus it may be necessary
-to re-issue the operation for previous values of <index>.
+### TRANSACTION_DATA
+
+The image format will contain a `TRANSACTION_DATA` record for each transaction
+that is pending on a connection for which there is `CONNECTION_DATA` record
+previously present.
+
+
+```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++-------------------------------+
 ```
 
-To deal with transactions that were pending when the domain is migrated
-it is necessary to start transactions with the same tx_id on behalf of the
-domain in the receiving xenstored.
 
-NOTE: For safety each such transaction should result in an `EAGAIN` when
-the `TRANSACTION_END` operation is performed, as modifications made under
-the tx_id will not be part of the migration stream.
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `conn-id`      | The connection that issued the               |
+|                | `TRANSACTION_START` operation [2]            |
+|                |                                              |
+| `tx-id`        | The transaction id passed back to the domain |
+|                | by the `TRANSACTION_START` operation         |
+
+\pagebreak
+
+### NODE_DATA
+
+For live update the image format will contain a `NODE_DATA` record for each
+node in xenstore. For migration it will only contain a record for the nodes
+relating to the domain being migrated. The `NODE_DATA` may be related to
+a _committed_ node (globally visible in xenstored) or a _pending_ node (created
+or modified by a transaction for which there is also a `TRANSACTION_DATA`
+record previously present).
 
-The `TRANSACTION_START` operation does not allow specification of a
-`<domid>`; it is assumed that the transaction pertains to the domain that
-owns the shared ring over which the operation is passed. Neither does it
-allow a `<transid>` to be specified; it is always chosen by xenstored.
-Hence, for the tool-stack to be able to open a transaction on behalf of a
-domain a new operation is needed:
 
 ```
-START_DOMAIN_TRANSACTION    <domid>|<transid>|
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++---------------+---------------+
+| access        | perm-count    |
++---------------+---------------+
+| perm1                         |
++-------------------------------+
+...
++-------------------------------+
+| permN                         |
++---------------+---------------+
+| path-len      | value-len     |
++---------------+---------------+
+| path
+...
+| value
+...
+```
+
+
+| Field        | Description                                    |
+|--------------|------------------------------------------------|
+| `conn-id`    | If this value is non-zero then this record     |
+|              | related to a pending transaction               |
+|              |                                                |
+| `tx-id`      | This value should be ignored if `conn-id` is   |
+|              | zero. Otherwise it specifies the id of the     |
+|              | pending transaction                            |
+|              |                                                |
+| `access`     | This value should be ignored if this record    |
+|              | does not relate to a pending transaction,      |
+|              | otherwise it specifies the accesses made to    |
+|              | the node and hence is a bitwise OR of:         |
+|              |                                                |
+|              | 0x0001: read                                   |
+|              | 0x0002: written                                |
+|              |                                                |
+|              | The value will be zero for a deleted node      |
+|              |                                                |
+| `perm-count` | The number (N) of node permission specifiers   |
+|              | (which will be 0 for a node deleted in a       |
+|              | pending transaction)                           |
+|              |                                                |
+| `perm1..N`   | A list of zero or more node permission         |
+|              | specifiers (see below)                         |
+|              |                                                |
+| `path-len`   | The length (in octets) of `path` including the |
+|              | NUL terminator                                 |
+|              |                                                |
+| `value-len`  | The length (in octets) of `value` (which will  |
+|              | be zero for a deleted node)                    |
+|              |                                                |
+| `path`       | The absolute path of the node                  |
+|              |                                                |
+| `value`      | The node value (which may be empty or contain  |
+|              | NUL octets)                                    |
+
+
+A node permission specifier has the following format:
 
-Starts a transaction on behalf of a domain.
 
-The semantics of this are similar to the domain issuing
-TRANSACTION_START and receiving the specified <transid> as the response.
-The main difference is that the transaction will be immediately marked as
-'conflicting' such that when the domain issues TRANSACTION_END T|, it will
-result in EAGAIN.
+```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| perm  | pad   | domid         |
++-------+-------+---------------+
 ```
 
-It may also be desirable to state in the protocol specification that
-the `INTRODUCE` operation should not clear the `<gfn>` specified such that
-a `RELEASE` operation followed by an `INTRODUCE` operation form an
-idempotent pair. The current implementation of *C xentored* does this
-(in the `domain_conn_reset()` function) but this could be dropped as this
-behaviour is not currently specified and the page will always be zeroed
-for a newly created domain.
+| Field   | Description                                         |
+|---------|-----------------------------------------------------|
+| `perm`  | One of the ASCII values `w`, `r`, `b` or `n` as     |
+|         | specified for the `SET_PERMS` operation [2]         |
+|         |                                                     |
+| `domid` | The domain-id to which the permission relates       |
 
 
 * * *
 
 [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
+
 [2] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/xenstore.txt
-[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/specs/libxl-migration-stream.pandoc
+
+[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/xen.h;hb=HEAD#l612
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index 04ce0ba607..cb8009cb68 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -289,23 +289,6 @@ IS_DOMAIN_INTRODUCED	<domid>|		T| or F|
 	ie, if INTRODUCE for the domain has not yet been followed by
 	domain destruction or explicit RELEASE.
 
-RESUME			<domid>|
-
-	Arranges that @releaseDomain events will once more be
-	generated when the domain becomes shut down.  This might have
-	to be used if a domain were to be shut down (generating one
-	@releaseDomain) and then subsequently restarted, since the
-	state-sensitive algorithm in xenstored will not otherwise send
-	further watch event notifications if the domain were to be
-	shut down again.
-
-	It is not clear whether this is possible since one would
-	normally expect a domain not to be restarted after being shut
-	down without being destroyed in the meantime.  There are
-	currently no users of this request in xen-unstable.
-
-	xenstored prevents the use of RESUME other than by dom0.
-
 SET_TARGET		<domid>|<tdomid>|
 	Notifies xenstored that domain <domid> is targeting domain
 	<tdomid>. This grants domain <domid> full access to paths
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:13:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT5S3-0004Y4-W6; Mon, 27 Apr 2020 15:13:43 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=5iRA=6L=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jT5S3-0004Xz-9D
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:13:43 +0000
X-Inumbo-ID: ade19a05-8899-11ea-97a8-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ade19a05-8899-11ea-97a8-12813bfff9fa;
 Mon, 27 Apr 2020 15:13:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2AE05ABCF;
 Mon, 27 Apr 2020 15:13:40 +0000 (UTC)
Subject: Re: [PATCH v3] docs/designs: re-work the xenstore migration
 document...
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200427150620.540-1-paul@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <a0c12699-1abc-8d31-9afc-0d201cf93ebc@suse.com>
Date: Mon, 27 Apr 2020 17:13:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200427150620.540-1-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.20 17:06, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
> 
> ... to specify a separate migration stream that will also be suitable for
> live update.
> 
> The original scope of the document was to support non-cooperative migration
> of guests [1] but, since then, live update of xenstored has been brought into
> scope. Thus it makes more sense to define a separate image format for
> serializing xenstore state that is suitable for both purposes.
> 
> The document has been limited to specifying a new image format. The mechanism
> for acquiring the image for live update or migration is not covered as that
> is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
> also expected that, when the first implementation of live update or migration
> making use of this specification is committed, that the document is moved from
> docs/designs into docs/specs.
> 
> NOTE: It will only be necessary to save and restore state for active xenstore
>        connections, but the documentation for 'RESUME' in xenstore.txt implies
>        otherwise. That command is unused so this patch deletes it from the
>        specification.
> 
> [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> ---
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Wei Liu <wl@xen.org>
> 
> v3:
>   - Address missed comments from Juergen

Not all :-(

> 
> v2:
>   - Address comments from Juergen
> ---

...

> +### NODE_DATA
> +
> +For live update the image format will contain a `NODE_DATA` record for each
> +node in xenstore. For migration it will only contain a record for the nodes
> +relating to the domain being migrated. The `NODE_DATA` may be related to
> +a _committed_ node (globally visible in xenstored) or a _pending_ node (created
> +or modified by a transaction for which there is also a `TRANSACTION_DATA`
> +record previously present).
>   
> -The `TRANSACTION_START` operation does not allow specification of a
> -`<domid>`; it is assumed that the transaction pertains to the domain that
> -owns the shared ring over which the operation is passed. Neither does it
> -allow a `<transid>` to be specified; it is always chosen by xenstored.
> -Hence, for the tool-stack to be able to open a transaction on behalf of a
> -domain a new operation is needed:
>   
>   ```
> -START_DOMAIN_TRANSACTION    <domid>|<transid>|
> +    0       1       2       3    octet
> ++-------+-------+-------+-------+
> +| conn-id                       |
> ++-------------------------------+
> +| tx-id                         |
> ++---------------+---------------+
> +| access        | perm-count    |
> ++---------------+---------------+
> +| perm1                         |
> ++-------------------------------+
> +...
> ++-------------------------------+
> +| permN                         |
> ++---------------+---------------+
> +| path-len      | value-len     |
> ++---------------+---------------+


path-len and value-len are still after perm1...permN, which makes it
impossible to include them in a struct.

Could you please either move them before the perm array or tell me why
not?


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:16:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT5UJ-0004eU-Ce; Mon, 27 Apr 2020 15:16:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT5UI-0004eO-D5
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:16:02 +0000
X-Inumbo-ID: 0110367d-889a-11ea-97a9-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0110367d-889a-11ea-97a9-12813bfff9fa;
 Mon, 27 Apr 2020 15:16:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0CC60AE2E;
 Mon, 27 Apr 2020 15:15:59 +0000 (UTC)
Subject: Re: [PATCH] x86: refine guest_mode()
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
 <1704f4f6-7e77-971c-2c94-4f6a6719c34a@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <5bbe6425-396c-d934-b5af-53b594a4afbc@suse.com>
Date: Mon, 27 Apr 2020 17:15:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1704f4f6-7e77-971c-2c94-4f6a6719c34a@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.2020 16:35, Andrew Cooper wrote:
> On 27/04/2020 09:03, Jan Beulich wrote:
>> The 2nd of the assertions as well as the macro's return value have been
>> assuming we're on the primary stack. While for most IST exceptions we
>> eventually switch back to the main one,
> 
> "we switch to the main one when interrupting user mode".
> 
> "eventually" isn't accurate as it is before we enter C.

Right, will change.

>> --- a/xen/include/asm-x86/regs.h
>> +++ b/xen/include/asm-x86/regs.h
>> @@ -10,9 +10,10 @@
>>      /* Frame pointer must point into current CPU stack. */                    \
>>      ASSERT(diff < STACK_SIZE);                                                \
>>      /* If not a guest frame, it must be a hypervisor frame. */                \
>> -    ASSERT((diff == 0) || (r->cs == __HYPERVISOR_CS));                        \
>> +    if ( diff < PRIMARY_STACK_SIZE )                                          \
>> +        ASSERT(!diff || ((r)->cs == __HYPERVISOR_CS));                        \
>>      /* Return TRUE if it's a guest frame. */                                  \
>> -    (diff == 0);                                                              \
>> +    !diff || ((r)->cs != __HYPERVISOR_CS);                                    \
> 
> The (diff == 0) already worried me before because it doesn't fail safe,
> but this makes things more problematic.  Consider the case back when we
> had __HYPERVISOR_CS32.

Yes - if __HYPERVISOR_CS32 would ever have been to be used for
anything, it would have needed checking for here.

> Guest mode is strictly "(r)->cs & 3".

As long as CS (a) gets properly saved (it's a "manual" step for
SYSCALL/SYSRET as well as #VMEXIT) and (b) didn't get clobbered. I
didn't write this code, I don't think, so I can only guess that
there were intentions behind this along these lines.

> Everything else is expectations about how things ought to be laid out,
> but for safety in release builds, the final judgement should not depend
> on the expectations evaluating true.

Well, I can switch to a purely CS.RPL based approach, as long as
we're happy to live with the possible downside mentioned above.
Of course this would then end up being a more intrusive change
than originally intended ...

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:18:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:18:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT5Wq-0004nv-RP; Mon, 27 Apr 2020 15:18:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jrem=6L=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jT5Wq-0004np-1E
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:18:40 +0000
X-Inumbo-ID: 5dc71430-889a-11ea-97a9-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5dc71430-889a-11ea-97a9-12813bfff9fa;
 Mon, 27 Apr 2020 15:18:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588000717;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=Pj8UqhKWdd240jsKB4Zxj2hveO4Nbw1TsD2WG40rUXo=;
 b=N5g7/tAndb0wtu1WzgxWm9+gIpQeDle5C0yl81tW3/2dg380ZISSQhTU
 F0f3uiOaC9zoog6GDkDONz9V03elnjHfPHrRN1LtLLVmiMVQwwc16NaBE
 yOpRAGHyiR/3MNbm3ngB7f5s1+vwiPwA8kHH7xJEN2PrYUtSeRjvK9KMi 4=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: S5u8J53EIvOwZQtoIW0tIhGFZ+3WaDHa3MRP8r/u1V+VErkXbN69jfBwJocQvkpHaZQalb6K4G
 8denFvGrP72Vw7RM4lWnKHf4donrBWqX//9IYgENINCKbQKM9jZh9mAl3EyXm7XgOXCW5oSNy7
 E942denuJ6RAJ0qtulE94i4A7e3jdlTJkL+Ec3lLwB4UA1S5XyHL+c6/P2hVgMgBmAfd8TdE03
 CrM9lz9t/odBDUtRhlup3Kh6tnNdyQEeFVauaZYHDaeEqI5Ha4X32paBY1K38xXNwHiEvIJMKJ
 IMs=
X-SBRS: 2.7
X-MesageID: 16997998
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16997998"
Date: Mon, 27 Apr 2020 17:18:29 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/ioemul: Rewrite stub generation
Message-ID: <20200427151829.GP28601@Air-de-Roger>
References: <20200427122041.7162-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200427122041.7162-1-andrew.cooper3@citrix.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 01:20:41PM +0100, Andrew Cooper wrote:
> The logic is completely undocumented and almost impossible to follow.  It
> actually uses return oriented programming.  Rewrite it to conform to more
> normal call mechanics, and leave a big comment explaining thing.  As well as
> the code being easier to follow, it will execute faster as it isn't fighting
> the branch predictor.
> 
> Move the ioemul_handle_quirk() function pointer from traps.c to
> ioport_emulate.c.

Seeing as the newest quirk was added in 2008, I wonder if such quirks
are still relevant?

Maybe they are also used by newer boxes, I really have no idea.

> There is no reason for it to be in neither of the two
> translation units which use it.  Alter the behaviour to return the number of
> bytes written into the stub.
> 
> Access the addresses of the host/guest helpers with extern const char arrays.
> Nothing good will come of C thinking they are regular functions.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> --
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Wei Liu <wl@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> ---
>  xen/arch/x86/ioport_emulate.c  | 11 ++---
>  xen/arch/x86/pv/emul-priv-op.c | 91 +++++++++++++++++++++++++++++++-----------
>  xen/arch/x86/pv/gpr_switch.S   | 37 +++++------------
>  xen/arch/x86/traps.c           |  3 --
>  xen/include/asm-x86/io.h       |  3 +-
>  5 files changed, 85 insertions(+), 60 deletions(-)
> 
> diff --git a/xen/arch/x86/ioport_emulate.c b/xen/arch/x86/ioport_emulate.c
> index 499c1f6056..f7511a9c49 100644
> --- a/xen/arch/x86/ioport_emulate.c
> +++ b/xen/arch/x86/ioport_emulate.c
> @@ -8,7 +8,10 @@
>  #include <xen/sched.h>
>  #include <xen/dmi.h>
>  
> -static bool ioemul_handle_proliant_quirk(
> +unsigned int (*ioemul_handle_quirk)(
> +    u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs);

uint8_t for opcode and also I think regs can be made const?

(at least looking at the only implementation from
ioemul_handle_proliant_quirk). I'm not familiar with this area
however.

> +
> +static unsigned int ioemul_handle_proliant_quirk(
>      u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs)
>  {
>      static const char stub[] = {
> @@ -19,18 +22,16 @@ static bool ioemul_handle_proliant_quirk(
>          0xa8, 0x80, /*    test $0x80, %al */
>          0x75, 0xfb, /*    jnz 1b          */
>          0x9d,       /*    popf            */
> -        0xc3,       /*    ret             */
>      };
>      uint16_t port = regs->dx;
>      uint8_t value = regs->al;
>  
>      if ( (opcode != 0xee) || (port != 0xcd4) || !(value & 0x80) )
> -        return false;
> +        return 0;
>  
>      memcpy(io_emul_stub, stub, sizeof(stub));
> -    BUILD_BUG_ON(IOEMUL_QUIRK_STUB_BYTES < sizeof(stub));
>  
> -    return true;
> +    return sizeof(stub);
>  }
>  
>  /* This table is the set of system-specific I/O emulation hooks. */
> diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
> index e24b84f46a..f150886711 100644
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -54,51 +54,96 @@ struct priv_op_ctxt {
>      unsigned int bpmatch;
>  };
>  
> -/* I/O emulation support. Helper routines for, and type of, the stack stub. */
> -void host_to_guest_gpr_switch(struct cpu_user_regs *);
> -unsigned long guest_to_host_gpr_switch(unsigned long);
> +/* I/O emulation helpers.  Use non-standard calling conventions. */
> +extern const char load_guest_gprs[], save_guest_gprs[];
>  
>  typedef void io_emul_stub_t(struct cpu_user_regs *);
>  
>  static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 opcode,
>                                            unsigned int port, unsigned int bytes)
>  {
> +    /*
> +     * Construct a stub for IN/OUT emulation.
> +     *
> +     * Some platform drivers communicate with the SMM handler using GPRs as a
> +     * mailbox.  Therefore, we must perform the emulation with the hardware
> +     * domain's registers in view.
> +     *
> +     * We write a stub of the following form, using the guest load/save
> +     * helpers (abnormal calling conventions), and one of several possible
> +     * stubs performing the real I/O.
> +     */
> +    static const char prologue[] = {
> +        0x53,       /* push %rbx */
> +        0x55,       /* push %rbp */
> +        0x41, 0x54, /* push %r12 */
> +        0x41, 0x55, /* push %r13 */
> +        0x41, 0x56, /* push %r14 */
> +        0x41, 0x57, /* push %r15 */
> +        0x57,       /* push %rdi (param for save_guest_gprs) */
> +    };              /* call load_guest_gprs */
> +                    /* <I/O stub> */
> +                    /* call save_guest_gprs */
> +    static const char epilogue[] = {
> +        0x5f,       /* pop %rdi  */
> +        0x41, 0x5f, /* pop %r15  */
> +        0x41, 0x5e, /* pop %r14  */
> +        0x41, 0x5d, /* pop %r13  */
> +        0x41, 0x5c, /* pop %r12  */
> +        0x5d,       /* pop %rbp  */
> +        0x5b,       /* pop %rbx  */
> +        0xc3,       /* ret       */
> +    };
> +
>      struct stubs *this_stubs = &this_cpu(stubs);
>      unsigned long stub_va = this_stubs->addr + STUB_BUF_SIZE / 2;
> -    long disp;
> -    bool use_quirk_stub = false;
> +    unsigned int quirk_bytes = 0;
> +    char *p;
> +
> +    /* Helpers - Read outer scope but only modify p. */
> +#define APPEND_BUFF(b) ({ memcpy(p, b, sizeof(b)); p += sizeof(b); })
> +#define APPEND_CALL(f)                                                  \
> +    ({                                                                  \
> +        long disp = (long)(f) - (stub_va + p - ctxt->io_emul_stub + 5); \
> +        BUG_ON((int32_t)disp != disp);                                  \

I'm not sure I get the point of using signed integers instead of
unsigned ones, AFAICT you just want to check that the displacement is
< 4GB so that a relative call can be used?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:29:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:29:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT5gi-0005n2-Qs; Mon, 27 Apr 2020 15:28:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7OvG=6L=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jT5gh-0005mx-IA
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:28:51 +0000
X-Inumbo-ID: cb74ff28-889b-11ea-97ac-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cb74ff28-889b-11ea-97ac-12813bfff9fa;
 Mon, 27 Apr 2020 15:28:50 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 020A3AF3B;
 Mon, 27 Apr 2020 15:28:48 +0000 (UTC)
Subject: Re: [PATCH] x86/ioemul: Rewrite stub generation
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200427122041.7162-1-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <ca3374ed-6e00-7ab2-8255-f74c16b5ad3d@suse.com>
Date: Mon, 27 Apr 2020 17:28:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200427122041.7162-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.2020 14:20, Andrew Cooper wrote:
> The logic is completely undocumented and almost impossible to follow.  It
> actually uses return oriented programming.  Rewrite it to conform to more
> normal call mechanics, and leave a big comment explaining thing.  As well as
> the code being easier to follow, it will execute faster as it isn't fighting
> the branch predictor.
> 
> Move the ioemul_handle_quirk() function pointer from traps.c to
> ioport_emulate.c.  There is no reason for it to be in neither of the two
> translation units which use it.  Alter the behaviour to return the number of
> bytes written into the stub.
> 
> Access the addresses of the host/guest helpers with extern const char arrays.
> Nothing good will come of C thinking they are regular functions.

I agree with the C aspect, but imo the assembly routines should,
with the changes you make, be marked as being ordinary functions.
A reasonable linker would then warn about the C file wanting an
STT_OBJECT while the assembly file provides an STT_FUNC. I'd
therefore prefer, along with marking the functions as such, to
have them also declared as functions in C.

> --- a/xen/arch/x86/ioport_emulate.c
> +++ b/xen/arch/x86/ioport_emulate.c
> @@ -8,7 +8,10 @@
>  #include <xen/sched.h>
>  #include <xen/dmi.h>
>  
> -static bool ioemul_handle_proliant_quirk(
> +unsigned int (*ioemul_handle_quirk)(
> +    u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs);

Would you mind adding __read_mostly on this occasion?

> @@ -19,18 +22,16 @@ static bool ioemul_handle_proliant_quirk(
>          0xa8, 0x80, /*    test $0x80, %al */
>          0x75, 0xfb, /*    jnz 1b          */
>          0x9d,       /*    popf            */
> -        0xc3,       /*    ret             */
>      };
>      uint16_t port = regs->dx;
>      uint8_t value = regs->al;
>  
>      if ( (opcode != 0xee) || (port != 0xcd4) || !(value & 0x80) )
> -        return false;
> +        return 0;
>  
>      memcpy(io_emul_stub, stub, sizeof(stub));
> -    BUILD_BUG_ON(IOEMUL_QUIRK_STUB_BYTES < sizeof(stub));

So you treat a build failure for a runtime crash. I can see the
advantages of the new approach, but the original got away with
less stub space. If our L1_CACHE_SHIFT wasn't hard coded to 7
just to cover some unusual CPUs, your new approach would, if I
got the counting and calculations right, not work (with a value
resulting in a 64-byte cache line size). Introducing a Kconfig
option for this should imo not come with a need to re-work the
logic here again. Therefore I'd like us to think about a way
to make the space needed not exceed 32 bytes.

One option might be to arrange for some or all of R12-R15 to
not need spilling. And of course there then still ought to be
a BUILD_BUG_ON() identifying ahead of any testing that yet
smaller cache line sizes would indeed require re-work here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:40:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT5s3-0007PV-UD; Mon, 27 Apr 2020 15:40:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=5iRA=6L=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jT5s2-0007PQ-MB
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:40:34 +0000
X-Inumbo-ID: 6e679fbe-889d-11ea-97b2-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6e679fbe-889d-11ea-97b2-12813bfff9fa;
 Mon, 27 Apr 2020 15:40:33 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7DD4DACBD;
 Mon, 27 Apr 2020 15:40:31 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: Stefano Stabellini <sstabellini@kernel.org>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
Date: Mon, 27 Apr 2020 17:40:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Stefano,

On 06.04.20 14:29, Jan Beulich wrote:
> On 03.04.2020 17:45, Jürgen Groß wrote:
>> On 03.04.20 17:33, Jan Beulich wrote:
>>> On 03.04.2020 17:12, Jürgen Groß wrote:
>>>> On 03.04.20 16:31, Jan Beulich wrote:
>>>>> On 02.04.2020 17:46, Juergen Gross wrote:
>>>>>> --- a/xen/common/Kconfig
>>>>>> +++ b/xen/common/Kconfig
>>>>>> @@ -353,6 +353,16 @@ config DOM0_MEM
>>>>>>             Leave empty if you are not sure what to specify.
>>>>>>     +config HYPFS_CONFIG
>>>>>> +    bool "Provide hypervisor .config via hypfs entry"
>>>>>> +    default y
>>>>>
>>>>> My initial reaction was to ask for "depends on HYPFS", but then
>>>>> I noticed the earlier patch doesn't introduce such. Am I
>>>>> mis-remembering that it was agreed to make the whole thing
>>>>> possible to disable at least in EXPERT mode?
>>>>
>>>> No, I don't remember that agreement.
>>>>
>>>> And TBH I'm not sure this is a good idea, as that would at once make the
>>>> plan to replace at least some sysctl and/or domctl interfaces impossible
>>>> (like e.g. the last 3 patches of the series are doing already), or at
>>>> least would tie the related functionality to CONFIG_HYPFS.
>>>
>>> I think that would be fine - that's what config setting are for.
>>> Someone caring about space may not care about runtime setting of
>>> parameters.
>>
>> So right now it would start with a plain hypfs available or not.
>>
>> The next step would be in patch 12 to tell the user he will lose the
>> capability of setting runtime parameters.
>>
>> Another planned extension would be to control per-cpupool settings,
>> which would the go away (possibly functionality being unconditionally
>> available today).
>>
>> Next would be the lack of being able to control per-domain mitigations
>> like XPTI or L1TF, which I'd like to add.
>>
>> Another thing I wanted to add is some debugging stuff (e.g. to switch
>> lock profiling using hypfs).
>>
>> And the list will go on.
> 
> Understood.
> 
>> Does it really make sense to make a central control and information
>> interface conditional?
> 
> None of the above may be of interest to e.g. embedded use cases.
> 
>> I'd like at least a second opinion on that topic.
> 
> Yes, further opinions would surely help.

Any opinion on making hypfs configurable?

It would be quite some code churn and I want to avoid it in case you
see no benefit in configuring it out for embedded.


Juergen



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:45:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT5wr-0007f4-HT; Mon, 27 Apr 2020 15:45:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6V0E=6L=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jT5wp-0007ex-S4
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:45:31 +0000
X-Inumbo-ID: 1f6e0078-889e-11ea-b07b-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1f6e0078-889e-11ea-b07b-bc764e2007e4;
 Mon, 27 Apr 2020 15:45:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=d3EydN2rnNNLbtdS3vs546R8x3PwbsSKaKk2w3aiAps=; b=FDjYg6daKudr4JHNDOGZo2Okw
 g0o4p8jtKmuAbM32BnPYIOIWLJKGt6vyRm9iVKLxwDUocaDKj5DbSSLdPfZXTRrkJvNLwlyzws64g
 X/54YMQZyV2bO0XkLFTaFlpGwAxv5R7oS/QrBRve8VWGdH69AjScI2aJmJgUTuv23FEJ0=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jT5wo-0002MB-1H; Mon, 27 Apr 2020 15:45:30 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jT5wn-0002GE-Ow; Mon, 27 Apr 2020 15:45:29 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jT5wn-0003HX-O9; Mon, 27 Apr 2020 15:45:29 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149832-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149832: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=6a8b55ed4056ea5559ebe4f6a4b247f627870d4c
X-Osstest-Versions-That: linux=e9a61afb69f07b1c5880984d45e5cc232ec1bf6f
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 27 Apr 2020 15:45:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149832 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149832/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149830

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149830
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149830
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149830
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149830
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149830
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149830
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149830
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149830
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                6a8b55ed4056ea5559ebe4f6a4b247f627870d4c
baseline version:
 linux                e9a61afb69f07b1c5880984d45e5cc232ec1bf6f

Last test of basis   149830  2020-04-26 18:38:51 Z    0 days
Testing same since   149832  2020-04-27 03:24:02 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Linus Torvalds <torvalds@linux-foundation.org>
  Paulo Alcantara (SUSE) <pc@cjr.nz>
  Paulo Alcantara <pc@cjr.nz>
  Ronnie Sahlberg <lsahlber@redhat.com>
  Steve French <stfrench@microsoft.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   e9a61afb69f0..6a8b55ed4056  6a8b55ed4056ea5559ebe4f6a4b247f627870d4c -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:48:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT5zM-0007o9-3n; Mon, 27 Apr 2020 15:48:08 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wbbE=6L=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jT5zK-0007o2-0O
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:48:06 +0000
X-Inumbo-ID: 7b76056e-889e-11ea-ae69-bc764e2007e4
Received: from mail-wr1-x432.google.com (unknown [2a00:1450:4864:20::432])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7b76056e-889e-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 15:48:05 +0000 (UTC)
Received: by mail-wr1-x432.google.com with SMTP id x17so20395700wrt.5
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 08:48:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=TNaqKHv3xB3gmXqjA49ijYMM+WpJCPmIY1aodHuOlJE=;
 b=BoIGJ9cemSqxisz1jMWM9erc4D0d/aUz6Jur8jpz7WW9DuEmEnOSPzaaf2hR7p9l6O
 PFmwlb0pfE7pSLE7U10j00Td+soMHkraI5jNAGsX0r4yrXaUS0lCFNPnKvbBVtwz68SL
 g0+utS24vpdBWtTACaRgMKLV/0kKBPAABndRMwFVPL/HcQO24KYC0VD++eS3c4fP2hKM
 jRD83ITTipAgHjdROze0jY/3NwwFHDlCKu3oBcgsl71fC0yU3AKO2IFEXcPdfu8o283q
 xpnAB6zAANaYRKjGnUysnhVNqPapD27NIhqZlesWXS+Xk75iU691QMBoabZMVcvGA4Ws
 +CYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :thread-index:content-language;
 bh=TNaqKHv3xB3gmXqjA49ijYMM+WpJCPmIY1aodHuOlJE=;
 b=GPlC3eZuS9PBk3ptjHpxNTveg7+VVPslQMVFrBU/qO1FPNTb8EmTEvAdySfuwdO8lY
 tsO7+u4CLPCyTyCZ09QhL5z+N4G+AIvXyyL4C4lXfSN3tj+aI88fQxMCqIgwOabHVqzV
 h+IYEsHo9VQAO8KAqYMZLJDkyzHoyivCNPIKBCD65Shvx6yi3c8nXpkgQ7i86GDe3cO4
 XxcF3znos8sWePuH5EF5PedOgCR7Hi5ITlHusDGbImsVmSwi5VUSRkNSEZbA/ny0J1qy
 Y3rySXG2ISoCwAYID0zq+hy511ntqspogy33PxH2ZoyGYXw9yxZpCKuo76HvtcEFqHEI
 bcQw==
X-Gm-Message-State: AGi0PuYpzLS/vYnA42dAtHsn5jwk6SxFbJJEaWS6CvF/VcyggkfbD2CA
 mu7+HYTyvqt/4SFFNLI47uo=
X-Google-Smtp-Source: APiQypLGvNPeJ4Tocw3jHtNcO5krBLXS8mMXEKNlJ3IaZU0vSQDu/b6wOCZvOR4spRWjl8dh+PjgrQ==
X-Received: by 2002:a5d:61c5:: with SMTP id q5mr28278051wrv.260.1588002484199; 
 Mon, 27 Apr 2020 08:48:04 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id f23sm15826186wml.4.2020.04.27.08.48.02
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 27 Apr 2020 08:48:03 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= <jgross@suse.com>,
 <xen-devel@lists.xenproject.org>
References: <20200427150620.540-1-paul@xen.org>
 <a0c12699-1abc-8d31-9afc-0d201cf93ebc@suse.com>
In-Reply-To: <a0c12699-1abc-8d31-9afc-0d201cf93ebc@suse.com>
Subject: RE: [PATCH v3] docs/designs: re-work the xenstore migration
 document...
Date: Mon, 27 Apr 2020 16:48:01 +0100
Message-ID: <000701d61cab$3c88c530$b59a4f90$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFx+WbLmvmkc5bbO+rA6uYcvUAufgIJ5csbqUUUI/A=
Content-Language: en-gb
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>
> Sent: 27 April 2020 16:14
> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Paul Durrant <pdurrant@amazon.com>; Andrew Cooper =
<andrew.cooper3@citrix.com>; George Dunlap
> <george.dunlap@citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; =
Jan Beulich <jbeulich@suse.com>;
> Julien Grall <julien@xen.org>; Stefano Stabellini =
<sstabellini@kernel.org>; Wei Liu <wl@xen.org>
> Subject: Re: [PATCH v3] docs/designs: re-work the xenstore migration =
document...
>=20
> On 27.04.20 17:06, Paul Durrant wrote:
> > From: Paul Durrant <pdurrant@amazon.com>
> >
> > ... to specify a separate migration stream that will also be =
suitable for
> > live update.
> >
> > The original scope of the document was to support non-cooperative =
migration
> > of guests [1] but, since then, live update of xenstored has been =
brought into
> > scope. Thus it makes more sense to define a separate image format =
for
> > serializing xenstore state that is suitable for both purposes.
> >
> > The document has been limited to specifying a new image format. The =
mechanism
> > for acquiring the image for live update or migration is not covered =
as that
> > is more appropriately dealt with by a patch to =
docs/misc/xenstore.txt. It is
> > also expected that, when the first implementation of live update or =
migration
> > making use of this specification is committed, that the document is =
moved from
> > docs/designs into docs/specs.
> >
> > NOTE: It will only be necessary to save and restore state for active =
xenstore
> >        connections, but the documentation for 'RESUME' in =
xenstore.txt implies
> >        otherwise. That command is unused so this patch deletes it =
from the
> >        specification.
> >
> > [1] See =
https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Ddocs/designs/non=
-cooperative-migration.md
> >
> > Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> > ---
> > Cc: Juergen Gross <jgross@suse.com>
> > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: George Dunlap <george.dunlap@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Jan Beulich <jbeulich@suse.com>
> > Cc: Julien Grall <julien@xen.org>
> > Cc: Stefano Stabellini <sstabellini@kernel.org>
> > Cc: Wei Liu <wl@xen.org>
> >
> > v3:
> >   - Address missed comments from Juergen
>=20
> Not all :-(
>=20
> >
> > v2:
> >   - Address comments from Juergen
> > ---
>=20
> ...
>=20
> > +### NODE_DATA
> > +
> > +For live update the image format will contain a `NODE_DATA` record =
for each
> > +node in xenstore. For migration it will only contain a record for =
the nodes
> > +relating to the domain being migrated. The `NODE_DATA` may be =
related to
> > +a _committed_ node (globally visible in xenstored) or a _pending_ =
node (created
> > +or modified by a transaction for which there is also a =
`TRANSACTION_DATA`
> > +record previously present).
> >
> > -The `TRANSACTION_START` operation does not allow specification of a
> > -`<domid>`; it is assumed that the transaction pertains to the =
domain that
> > -owns the shared ring over which the operation is passed. Neither =
does it
> > -allow a `<transid>` to be specified; it is always chosen by =
xenstored.
> > -Hence, for the tool-stack to be able to open a transaction on =
behalf of a
> > -domain a new operation is needed:
> >
> >   ```
> > -START_DOMAIN_TRANSACTION    <domid>|<transid>|
> > +    0       1       2       3    octet
> > ++-------+-------+-------+-------+
> > +| conn-id                       |
> > ++-------------------------------+
> > +| tx-id                         |
> > ++---------------+---------------+
> > +| access        | perm-count    |
> > ++---------------+---------------+
> > +| perm1                         |
> > ++-------------------------------+
> > +...
> > ++-------------------------------+
> > +| permN                         |
> > ++---------------+---------------+
> > +| path-len      | value-len     |
> > ++---------------+---------------+
>=20
>=20
> path-len and value-len are still after perm1...permN, which makes it
> impossible to include them in a struct.
>=20
> Could you please either move them before the perm array or tell me why
> not?

Gah, sorry, I meant to move them and then forgot again. I'll send v4.

  Paul

>=20
>=20
> Juergen



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:50:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT61q-00007l-HY; Mon, 27 Apr 2020 15:50:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=m6ex=6L=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jT61p-00007g-LG
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:50:41 +0000
X-Inumbo-ID: d8061de6-889e-11ea-b07b-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d8061de6-889e-11ea-b07b-bc764e2007e4;
 Mon, 27 Apr 2020 15:50:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=vAwTngtf3oFnJq6Lj++fHwLp7IY5766d1HTWb5OIy3g=; b=Cu1qJdQE8IXaH0aGo7GRjRgicb
 h7qLqnB8VdLT5zuQAoDKkU8AiaN8nx7TiOlSNLbYy0COjOqHy3+uQDjxZC7uw9y/wknRi0n9Cp0X9
 okDqh7X24+LUazjpXajZo0tSFY3IAHIMwnT1eNtDUsAQ0x9Tbg1eyKBC/CCExjKo9xS0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <paul@xen.org>)
 id 1jT61n-0002TQ-4C; Mon, 27 Apr 2020 15:50:39 +0000
Received: from [54.239.6.186] (helo=CBG-R90WXYV0.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jT61m-0001nF-JE; Mon, 27 Apr 2020 15:50:38 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v4] docs/designs: re-work the xenstore migration document...
Date: Mon, 27 Apr 2020 16:50:35 +0100
Message-Id: <20200427155035.668-1-paul@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Durrant <pdurrant@amazon.com>

... to specify a separate migration stream that will also be suitable for
live update.

The original scope of the document was to support non-cooperative migration
of guests [1] but, since then, live update of xenstored has been brought into
scope. Thus it makes more sense to define a separate image format for
serializing xenstore state that is suitable for both purposes.

The document has been limited to specifying a new image format. The mechanism
for acquiring the image for live update or migration is not covered as that
is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
also expected that, when the first implementation of live update or migration
making use of this specification is committed, that the document is moved from
docs/designs into docs/specs.

NOTE: It will only be necessary to save and restore state for active xenstore
      connections, but the documentation for 'RESUME' in xenstore.txt implies
      otherwise. That command is unused so this patch deletes it from the
      specification.

[1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Wei Liu <wl@xen.org>

v4:
 - move path-len and value-len earlier in NODE_DATA

v3:
 - Address missed comments from Juergen

v2:
 - Address comments from Juergen
---
 docs/designs/xenstore-migration.md | 470 +++++++++++++++++++----------
 docs/misc/xenstore.txt             |  17 --
 2 files changed, 308 insertions(+), 179 deletions(-)

diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
index 6ab351e8fe..51d8b85171 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -3,254 +3,400 @@
 ## Background
 
 The design for *Non-Cooperative Migration of Guests*[1] explains that extra
-save records are required in the migrations stream to allow a guest running
-PV drivers to be migrated without its co-operation. Moreover the save
-records must include details of registered xenstore watches as well as
-content; information that cannot currently be recovered from `xenstored`,
-and hence some extension to the xenstore protocol[2] will also be required.
-
-The *libxenlight Domain Image Format* specification[3] already defines a
-record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
-transferring xenstore data pertaining to the domain directly as it is
-specified such that keys are relative to the path
-`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
-define at least one new save record type.
+save records are required in the migrations stream to allow a guest running PV
+drivers to be migrated without its co-operation. Moreover the save records must
+include details of registered xenstore watches as well ascontent; information
+that cannot currently be recovered from `xenstored`, and hence some extension
+to the xenstored implementations will also be required.
+
+As a similar set of data is needed for transferring xenstore data from one
+instance to another when live updating xenstored this document proposes an
+image format for a 'migration stream' suitable for both purposes.
 
 ## Proposal
 
-### New Save Record
+The image format consists of a _header_ followed by 1 or more _records_. Each
+record consists of a type and length field, followed by any data mandated by
+the record type. At minimum there will be a single record of type `END`
+(defined below).
 
-A new mandatory record type should be defined within the libxenlight Domain
-Image Format:
+### Header
 
-`0x00000007: DOMAIN_XENSTORE_DATA`
+The header identifies the stream as a `xenstore` stream, including the version
+of the specification that it complies with.
 
-An arbitrary number of these records may be present in the migration
-stream and may appear in any order. The format of each record should be as
-follows:
+All fields in this header must be in _big-endian_ byte order, regardless of
+the setting of the endianness bit.
 
 
 ```
     0       1       2       3       4       5       6       7    octet
 +-------+-------+-------+-------+-------+-------+-------+-------+
-| type                          | record specific data          |
-+-------------------------------+                               |
-...
-+---------------------------------------------------------------+
+| ident                                                         |
++-------------------------------+-------------------------------|
+| version                       | flags                         |
++-------------------------------+-------------------------------+
 ```
 
-where type is one of the following values
 
+| Field     | Description                                       |
+|-----------|---------------------------------------------------|
+| `ident`   | 0x78656e73746f7265 ('xenstore' in ASCII)          |
+|           |                                                   |
+| `version` | 0x00000001 (the version of the specification)     |
+|           |                                                   |
+| `flags`   | 0 (LSB): Endianness: 0 = little, 1 = big          |
+|           |                                                   |
+|           | 1-31: Reserved (must be zero)                     |
 
-| Field  | Description                                      |
-|--------|--------------------------------------------------|
-| `type` | 0x00000000: invalid                              |
-|        | 0x00000001: NODE_DATA                            |
-|        | 0x00000002: WATCH_DATA                           |
-|        | 0x00000003: TRANSACTION_DATA                     |
-|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
+### Records
 
+Records immediately follow the header and have the following format:
 
-and data is one of the record data formats described in the following
-sections.
 
+```
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| type                          | len                           |
++-------------------------------+-------------------------------+
+| body
+...
+|       | padding (0 to 7 octets)                               |
++-------+-------------------------------------------------------+
+```
+
+NOTE: padding octets here and in all subsequent format specifications must be
+      written as zero and should be ignored when the stream is read.
 
-NOTE: The record data does not contain an overall length because the
-libxenlight record header specifies the length.
 
+| Field  | Description                                          |
+|--------|------------------------------------------------------|
+| `type` | 0x00000000: END                                      |
+|        | 0x00000001: GLOBAL_DATA                              |
+|        | 0x00000002: CONNECTION_DATA                          |
+|        | 0x00000003: WATCH_DATA                               |
+|        | 0x00000004: TRANSACTION_DATA                         |
+|        | 0x00000005: NODE_DATA                                |
+|        | 0x00000006 - 0xFFFFFFFF: reserved for future use     |
+|        |                                                      |
+| `len`  | The length (in octets) of `body`                     |
+|        |                                                      |
+| `body` | The type-specific record data                        |
 
-**NODE_DATA**
+Some records will depend on other records in the migration stream. Records
+upon which other records depend must always appear earlier in the stream.
 
+The various formats of the type-specific data are described in the following
+sections:
 
-Each NODE_DATA record specifies a single node in xenstore and is formatted
-as follows:
+\pagebreak
 
+### END
+
+The end record marks the end of the image, and is the final record
+in the stream.
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| NODE_DATA                     |
-+-------------------------------+
-| path length                   |
-+-------------------------------+
-| path data                     |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
-| perm count (N)                |
-+-------------------------------+
-| perm0                         |
-+-------------------------------+
-...
-+-------------------------------+
-| permN                         |
-+-------------------------------+
-| value length                  |
-+-------------------------------+
-| value data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
 ```
 
-where perm0..N are formatted as follows:
 
+The end record contains no fields; its body length is 0.
+
+\pagebreak
+
+### GLOBAL_DATA
+
+This record is only relevant for live update. It contains details of global
+xenstored state that needs to be restored.
 
 ```
-    0       1       2       3     octet
+    0       1       2       3    octet
 +-------+-------+-------+-------+
-| perm  | pad   | domid         |
+| rw-socket-fd                  |
++-------------------------------+
+| ro-socket-fd                  |
 +-------------------------------+
 ```
 
 
-path length and value length are specified in octets (excluding the NUL
-terminator of the path). perm should be one of the ASCII values `w`, `r`,
-`b` or `n` as described in [2]. All pad values should be 0.
-All paths should be absolute (i.e. start with `/`) and as described in
-[2].
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `rw-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-write connections                       |
+|                |                                              |
+| `ro-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-only connections                        |
 
+xenstored will resume in the original process context. Hence `rw-socket-fd` and
+`ro-socket-fd` simply specify the file descriptors of the sockets.
 
-**WATCH_DATA**
 
+\pagebreak
 
-Each WATCH_DATA record specifies a registered watch and is formatted as
-follows:
+### CONNECTION_DATA
+
+For live update the image format will contain a `CONNECTION_DATA` record for
+each connection to xenstore. For migration it will only contain a record for
+the domain being migrated.
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| WATCH_DATA                    |
-+-------------------------------+
-| wpath length                  |
-+-------------------------------+
-| wpath data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| conn-id                       | conn-type     | conn-spec
 ...
++-------------------------------+-------------------------------+
+| data-len                      | data
 +-------------------------------+
-| token length                  |
-+-------------------------------+
-| token data                    |
 ...
-| pad (0 to 3 octets)           |
-+-------------------------------+
 ```
 
-wpath length and token length are specified in octets (excluding the NUL
-terminator). The wpath should be as described for the `WATCH` operation in
-[2]. The token is an arbitrary string of octets not containing any NUL
-values.
 
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | A non-zero number used to identify this         |
+|             | connection in subsequent connection-specific    |
+|             | records                                         |
+|             |                                                 |
+| `conn-type` | 0x0000: shared ring                             |
+|             | 0x0001: socket                                  |
+|             |                                                 |
+| `conn-spec` | See below                                       |
+|             |                                                 |
+| `data-len`  | The length (in octets) of any pending data not  |
+|             | yet written to the connection                   |
+|             |                                                 |
+| `data`      | Pending data (may be empty)                     |
 
-**TRANSACTION_DATA**
+The format of `conn-spec` is dependent upon `conn-type`.
 
+\pagebreak
 
-Each TRANSACTION_DATA record specifies an open transaction and is formatted
-as follows:
+For `shared ring` connections it is as follows:
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| TRANSACTION_DATA              |
-+-------------------------------+
-| tx_id                         |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
+                                                +-------+-------+
+                                                | flags         |
++---------------+---------------+---------------+---------------+
+| domid         | tdomid        | evtchn                        |
++-------------------------------+-------------------------------+
+| mfn                                                           |
++---------------------------------------------------------------+
 ```
 
-where tx_id is the non-zero identifier values of an open transaction.
 
+| Field     | Description                                       |
+|-----------|---------------------------------------------------|
+| `domid`   | The domain-id that owns the shared page           |
+|           |                                                   |
+| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
+|           | it has been subject to an SET_TARGET              |
+|           | operation [2] or DOMID_INVALID [3] otherwise      |
+|           |                                                   |
+| `flags`   | Must be zero                                      |
+|           |                                                   |
+| `evtchn`  | The port number of the interdomain channel used   |
+|           | by `domid` to communicate with xenstored          |
+|           |                                                   |
+| `mfn`     | The MFN of the shared page for a live update or   |
+|           | ~0 (i.e. all bits set) otherwise                  |
 
-### Protocol Extension
+Since the ABI guarantees that entry 1 in `domid`'s grant table will always
+contain the GFN of the shared page, so for a live update `mfn` can be used to
+give confidence that `domid` has not been re-cycled during the update.
 
-Before xenstore state is migrated it is necessary to wait for any pending
-reads, writes, watch registrations etc. to complete, and also to make sure
-that xenstored does not start processing any new requests (so that new
-requests remain pending on the shared ring for subsequent processing on the
-new host). Hence the following operation is needed:
 
-```
-QUIESCE                 <domid>|
+For `socket` connections it is as follows:
+
 
-Complete processing of any request issued by the specified domain, and
-do not process any further requests from the shared ring.
+```
+                                                +-------+-------+
+                                                | flags         |
++---------------+---------------+---------------+---------------+
+| socket-fd                     | pad                           |
++-------------------------------+-------------------------------+
+| pad                                                           |
++---------------------------------------------------------------+
 ```
 
-The `WATCH` operation does not allow specification of a `<domid>`; it is
-assumed that the watch pertains to the domain that owns the shared ring
-over which the operation is passed. Hence, for the tool-stack to be able
-to register a watch on behalf of a domain a new operation is needed:
 
-```
-ADD_DOMAIN_WATCHES      <domid>|<watch>|+
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `flags`     | A bit-wise OR of:                               |
+|             | 0001: read-only                                 |
+|             |                                                 |
+| `socket-fd` | The file descriptor of the connected socket     |
 
-Adds watches on behalf of the specified domain.
+This type of connection is only relevant for live update, where the xenstored
+resumes in the original process context. Hence `socket-fd` simply specify
+the file descriptor of the socket connection.
 
-<watch> is a NUL separated tuple of <path>|<token>. The semantics of this
-operation are identical to the domain issuing WATCH <path>|<token>| for
-each <watch>.
-```
+\pagebreak
+
+### WATCH_DATA
+
+The image format will contain a `WATCH_DATA` record for each watch registered
+by a connection for which there is `CONNECTION_DATA` record previously present.
 
-The watch information for a domain also needs to be extracted from the
-sending xenstored so the following operation is also needed:
 
 ```
-GET_DOMAIN_WATCHES      <domid>|<index>   <gencnt>|<watch>|*
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++---------------+---------------+
+| wpath-len     | token-len     |
++---------------+---------------+
+| wpath
+...
+| token
+...
+```
+
 
-Gets the list of watches that are currently registered for the domain.
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | The connection that issued the `WATCH`          |
+|             | operation [2]                                   |
+|             |                                                 |
+| `wpath-len` | The length (in octets) of `wpath` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `token-len` | The length (in octets) of `token` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `wpath`     | The watch path, as specified in the `WATCH`     |
+|             | operation                                       |
+|             |                                                 |
+| `token`     | The watch identifier token, as specified in the |
+|             | `WATCH` operation                               |
 
-<watch> is a NUL separated tuple of <path>|<token>. The sub-list returned
-will start at <index> items into the the overall list of watches and may
-be truncated (at a <watch> boundary) such that the returned data fits
-within XENSTORE_PAYLOAD_MAX.
+\pagebreak
 
-If <index> is beyond the end of the overall list then the returned sub-
-list will be empty. If the value of <gencnt> changes then it indicates
-that the overall watch list has changed and thus it may be necessary
-to re-issue the operation for previous values of <index>.
+### TRANSACTION_DATA
+
+The image format will contain a `TRANSACTION_DATA` record for each transaction
+that is pending on a connection for which there is `CONNECTION_DATA` record
+previously present.
+
+
+```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++-------------------------------+
 ```
 
-To deal with transactions that were pending when the domain is migrated
-it is necessary to start transactions with the same tx_id on behalf of the
-domain in the receiving xenstored.
 
-NOTE: For safety each such transaction should result in an `EAGAIN` when
-the `TRANSACTION_END` operation is performed, as modifications made under
-the tx_id will not be part of the migration stream.
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `conn-id`      | The connection that issued the               |
+|                | `TRANSACTION_START` operation [2]            |
+|                |                                              |
+| `tx-id`        | The transaction id passed back to the domain |
+|                | by the `TRANSACTION_START` operation         |
+
+\pagebreak
+
+### NODE_DATA
+
+For live update the image format will contain a `NODE_DATA` record for each
+node in xenstore. For migration it will only contain a record for the nodes
+relating to the domain being migrated. The `NODE_DATA` may be related to
+a _committed_ node (globally visible in xenstored) or a _pending_ node (created
+or modified by a transaction for which there is also a `TRANSACTION_DATA`
+record previously present).
 
-The `TRANSACTION_START` operation does not allow specification of a
-`<domid>`; it is assumed that the transaction pertains to the domain that
-owns the shared ring over which the operation is passed. Neither does it
-allow a `<transid>` to be specified; it is always chosen by xenstored.
-Hence, for the tool-stack to be able to open a transaction on behalf of a
-domain a new operation is needed:
 
 ```
-START_DOMAIN_TRANSACTION    <domid>|<transid>|
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++---------------+---------------+
+| path-len      | value-len     |
++---------------+---------------+
+| access        | perm-count    |
++---------------+---------------+
+| perm1                         |
++-------------------------------+
+...
++-------------------------------+
+| permN                         |
++---------------+---------------+
+| path
+...
+| value
+...
+```
+
+
+| Field        | Description                                    |
+|--------------|------------------------------------------------|
+| `conn-id`    | If this value is non-zero then this record     |
+|              | related to a pending transaction               |
+|              |                                                |
+| `tx-id`      | This value should be ignored if `conn-id` is   |
+|              | zero. Otherwise it specifies the id of the     |
+|              | pending transaction                            |
+|              |                                                |
+| `path-len`   | The length (in octets) of `path` including the |
+|              | NUL terminator                                 |
+|              |                                                |
+| `value-len`  | The length (in octets) of `value` (which will  |
+|              | be zero for a deleted node)                    |
+|              |                                                |
+| `access`     | This value should be ignored if this record    |
+|              | does not relate to a pending transaction,      |
+|              | otherwise it specifies the accesses made to    |
+|              | the node and hence is a bitwise OR of:         |
+|              |                                                |
+|              | 0x0001: read                                   |
+|              | 0x0002: written                                |
+|              |                                                |
+|              | The value will be zero for a deleted node      |
+|              |                                                |
+| `perm-count` | The number (N) of node permission specifiers   |
+|              | (which will be 0 for a node deleted in a       |
+|              | pending transaction)                           |
+|              |                                                |
+| `perm1..N`   | A list of zero or more node permission         |
+|              | specifiers (see below)                         |
+|              |                                                |
+| `path`       | The absolute path of the node                  |
+|              |                                                |
+| `value`      | The node value (which may be empty or contain  |
+|              | NUL octets)                                    |
+
+
+A node permission specifier has the following format:
 
-Starts a transaction on behalf of a domain.
 
-The semantics of this are similar to the domain issuing
-TRANSACTION_START and receiving the specified <transid> as the response.
-The main difference is that the transaction will be immediately marked as
-'conflicting' such that when the domain issues TRANSACTION_END T|, it will
-result in EAGAIN.
+```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| perm  | pad   | domid         |
++-------+-------+---------------+
 ```
 
-It may also be desirable to state in the protocol specification that
-the `INTRODUCE` operation should not clear the `<gfn>` specified such that
-a `RELEASE` operation followed by an `INTRODUCE` operation form an
-idempotent pair. The current implementation of *C xentored* does this
-(in the `domain_conn_reset()` function) but this could be dropped as this
-behaviour is not currently specified and the page will always be zeroed
-for a newly created domain.
+| Field   | Description                                         |
+|---------|-----------------------------------------------------|
+| `perm`  | One of the ASCII values `w`, `r`, `b` or `n` as     |
+|         | specified for the `SET_PERMS` operation [2]         |
+|         |                                                     |
+| `domid` | The domain-id to which the permission relates       |
 
 
 * * *
 
 [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
+
 [2] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/xenstore.txt
-[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/specs/libxl-migration-stream.pandoc
+
+[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/xen.h;hb=HEAD#l612
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index 04ce0ba607..cb8009cb68 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -289,23 +289,6 @@ IS_DOMAIN_INTRODUCED	<domid>|		T| or F|
 	ie, if INTRODUCE for the domain has not yet been followed by
 	domain destruction or explicit RELEASE.
 
-RESUME			<domid>|
-
-	Arranges that @releaseDomain events will once more be
-	generated when the domain becomes shut down.  This might have
-	to be used if a domain were to be shut down (generating one
-	@releaseDomain) and then subsequently restarted, since the
-	state-sensitive algorithm in xenstored will not otherwise send
-	further watch event notifications if the domain were to be
-	shut down again.
-
-	It is not clear whether this is possible since one would
-	normally expect a domain not to be restarted after being shut
-	down without being destroyed in the meantime.  There are
-	currently no users of this request in xen-unstable.
-
-	xenstored prevents the use of RESUME other than by dom0.
-
 SET_TARGET		<domid>|<tdomid>|
 	Notifies xenstored that domain <domid> is targeting domain
 	<tdomid>. This grants domain <domid> full access to paths
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 15:55:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 15:55:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT66c-0000Pb-9I; Mon, 27 Apr 2020 15:55:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=5iRA=6L=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jT66a-0000PW-Kf
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 15:55:36 +0000
X-Inumbo-ID: 88380cec-889f-11ea-97b3-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 88380cec-889f-11ea-97b3-12813bfff9fa;
 Mon, 27 Apr 2020 15:55:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8DEB5ACBD;
 Mon, 27 Apr 2020 15:55:33 +0000 (UTC)
Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration
 document...
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200427155035.668-1-paul@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <91f47537-a954-47c9-0b9e-8aa9ee90f449@suse.com>
Date: Mon, 27 Apr 2020 17:55:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200427155035.668-1-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.20 17:50, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
> 
> ... to specify a separate migration stream that will also be suitable for
> live update.
> 
> The original scope of the document was to support non-cooperative migration
> of guests [1] but, since then, live update of xenstored has been brought into
> scope. Thus it makes more sense to define a separate image format for
> serializing xenstore state that is suitable for both purposes.
> 
> The document has been limited to specifying a new image format. The mechanism
> for acquiring the image for live update or migration is not covered as that
> is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
> also expected that, when the first implementation of live update or migration
> making use of this specification is committed, that the document is moved from
> docs/designs into docs/specs.
> 
> NOTE: It will only be necessary to save and restore state for active xenstore
>        connections, but the documentation for 'RESUME' in xenstore.txt implies
>        otherwise. That command is unused so this patch deletes it from the
>        specification.
> 
> [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 16:01:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 16:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT6Bo-0001ka-QW; Mon, 27 Apr 2020 16:01:00 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jrem=6L=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jT6Bn-0001kV-VQ
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 16:01:00 +0000
X-Inumbo-ID: 48418e64-88a0-11ea-97b3-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 48418e64-88a0-11ea-97b3-12813bfff9fa;
 Mon, 27 Apr 2020 16:00:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588003258;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=YG0ApSthlCMFZiia2oF76yi2aWS/H+oIXsuYehyDp/E=;
 b=B3LB7gh2Po5JYW689f3IguOWfny6NbPgIBqURIvL8E2XrLXogDHu0E5X
 Guajp8DPlav5xvVNZNzpqhmmVH4FhBH7D+UeNT596NmLs0Yc/tnAjOZc9
 vbS7Muy/lBwrWIJf91Ism3guLfbJELrsfZlhbpKlZDBTtqborRl75xVFD k=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 9zur46vGKK/qFZaEWsAB61CxK9BcPgkJHG8PxvRWcHxXyOKSdlqE9U/w88jxMJX5ISSPUV1tKP
 CyKni0UoSmh/15RkwgeLg4mT9yAgYnsmwwbh23qmkJGm3L+PZQPEHX4BBHcleHJ/zy5LOxd34J
 0s1GkCHhKXxtj0WwqpAu5O9xQDqkA5/w7102dg+JiADTuy3eJawSRr++gYdK3LXhR8Am5V0h58
 kqdcj/ViuT9A548h3gbPQbTHwbMleJV3lucZLObsxcvcYaEAn6qv0lIzVvXOPeIosHNBbc6PQg
 ggw=
X-SBRS: 2.7
X-MesageID: 16328224
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16328224"
Date: Mon, 27 Apr 2020 18:00:48 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86: refine guest_mode()
Message-ID: <20200427160048.GQ28601@Air-de-Roger>
References: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
 <20200427095913.GN28601@Air-de-Roger>
 <40d5c1b8-b68e-1aa8-b17e-77ba9afc6529@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <40d5c1b8-b68e-1aa8-b17e-77ba9afc6529@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 04:08:59PM +0200, Jan Beulich wrote:
> On 27.04.2020 11:59, Roger Pau Monné wrote:
> > On Mon, Apr 27, 2020 at 10:03:05AM +0200, Jan Beulich wrote:
> >> --- a/xen/include/asm-x86/regs.h
> >> +++ b/xen/include/asm-x86/regs.h
> >> @@ -10,9 +10,10 @@
> >>      /* Frame pointer must point into current CPU stack. */                    \
> >>      ASSERT(diff < STACK_SIZE);                                                \
> >>      /* If not a guest frame, it must be a hypervisor frame. */                \
> >> -    ASSERT((diff == 0) || (r->cs == __HYPERVISOR_CS));                        \
> >> +    if ( diff < PRIMARY_STACK_SIZE )                                          \
> >> +        ASSERT(!diff || ((r)->cs == __HYPERVISOR_CS));                        \
> > 
> > Why not use:
> > 
> > ASSERT(diff >= PRIMARY_STACK_SIZE || !diff || ((r)->cs == __HYPERVISOR_CS));
> 
> Except for the longer (without being helpful imo) string reported if
> the assertion triggers, I see not difference.

Wanted to avoid the empty if on non-debug builds, but I assume the
compiler will already optimize it out.

> > I'm not sure I fully understand this layout, is it possible that you
> > also need to account for the size of cpu_info?
> 
> Depends on how paranoid we want the checking here to be, but in going
> further I wouldn't want this to become sub-page fine-grained if we
> aren't first doing e.g. what I'm mentioning in the post-commit-message
> remark.

Right, leaving it as-is is fine, just wanted to be sure I fully
understand the layout.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 16:02:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 16:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT6D7-0001tw-5Y; Mon, 27 Apr 2020 16:02:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rzTj=6L=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jT6D6-0001tp-5B
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 16:02:20 +0000
X-Inumbo-ID: 7865be62-88a0-11ea-ae69-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7865be62-88a0-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 16:02:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588003339;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=Dai7Q/Zx0jChj1lAaZFDtJzKdmUoogQnUUXhDiXNpbs=;
 b=Bz5ynJh7xwamSaiam3ROzrZbnDf1oucrc/pykJrhmyQ/jLyE/2ycqSwQ
 fHAHATDFOy5TRGKhTFFAxlGHX+1NhlPPPJWthBamfAb0VxRpXyT42PIyy
 71UiLbVx9sZfw9+/d9ZULDZaKQCNN5GwdD1J0bmOXRMGZjFK+QMDbro3D E=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: fjbrm+tdmofxt+CTMxCMPUq0+QuiqNE6yMJC5sMD5JwvOHBvJIGLiOX5UnI7WAI/+SVpLTt4wz
 okXkyHqBGBrYd3n9/G+fJUTuHy0+kjag4S3SzcW8PopFHur6ipuBBe/kBQJM3Ecj3k1Hd8uOyS
 F16DKM877GXr5y6rK9VCq6+Rcaq0lvKc8+pBkBqQ6zA629dTtObgu4R7APzaD+B7d9xuPIHZgZ
 rAOqIod57GRyW9BR8m2BeUZSOtAGPg9MMlqFY2ftzMBVxZMAlRhs+X4z7D3Snns4fZ9bTaBoaG
 4os=
X-SBRS: 2.7
X-MesageID: 16328364
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16328364"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24231.513.288498.17105@mariner.uk.xensource.com>
Date: Mon, 27 Apr 2020 17:02:09 +0100
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v3 10/17] tools/libxl: Plumb a restore boolean into
 libxl__domain_build_state
In-Reply-To: <20200414202321.17580-1-andrew.cooper3@citrix.com>
References: <20200127143444.25538-11-andrew.cooper3@citrix.com>
 <20200414202321.17580-1-andrew.cooper3@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony
 Perard <anthony.perard@citrix.com>, Xen-devel <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Andrew Cooper writes ("[PATCH v3 10/17] tools/libxl: Plumb a restore boolean into libxl__domain_build_state"):
> To fix CPUID handling, libxl__build_pre() is going to have to distinguish
> between a brand new VM vs one which is being migrated-in/resumed.
> 
> Transcribe dcs->restore_fd into dbs->restore in initiate_domain_create()
> only (specifically avoiding the stubdom state in libxl__spawn_stub_dm()).
> 
> While tweaking initiate_domain_create(), make a new dbs alias and simplify
> later code, and drop the local restore_fd alias as the new dbs->restore is
> more intuitive in context.
> 
> No functional change.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 16:07:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 16:07:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT6I3-000272-R0; Mon, 27 Apr 2020 16:07:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rzTj=6L=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jT6I2-00026x-NW
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 16:07:26 +0000
X-Inumbo-ID: 2eeab3fe-88a1-11ea-97b4-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2eeab3fe-88a1-11ea-97b4-12813bfff9fa;
 Mon, 27 Apr 2020 16:07:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588003645;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=r/4sxsISStf0Mfn4DrU0OKjJgriEsajDBe7zAhLtdp0=;
 b=Q4vGExcVLRWwNjPAD/9f9QH8ej5+6LAYwgBom+w3cd2LfFyKGIAio/xE
 Ol/YweEDC2MEUCsKTfZCS76Ic26z1x1XJQ9HBeHkFWviKmRsjfOXg56dY
 xCGrd3AlmSNbTXOhWSXJnaW8wZOzCNtV2A3f/18A8sv5k6sKtcyCOALWD U=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: oTUXQeaZ+xD5dA/1M0FCTA8gfr3i3CbCdi+/sXiq7ryHR9U78HHoNRI6hY9LQMXu78sgHZq2Aa
 PjL9owqwIA7ksAF2WxHzgpUvhixnBpw0BGKZE13uSQGipM91OjmMHHotAWfQPOzT2bRSBRXVpe
 h/mVNxRaq5FRtFO21m8U0v13LkEfqHWhT6euo6eyXjga3biI6ClMordrrb2hhKuzN0Yjhbpwe8
 Fy/ZdOo2eoKTFv88fsmYFpFT7/2pXx3k1Ps8fTpGoeFj54unBDOa7HjQFpYmGZGgYVIMN+ENtJ
 7Fk=
X-SBRS: 2.7
X-MesageID: 16628494
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16628494"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-ID: <24231.823.216156.673425@mariner.uk.xensource.com>
Date: Mon, 27 Apr 2020 17:07:19 +0100
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [PATCH v2 03/17] tools/migration: Drop IHDR_VERSION constant from
 libxc and python [and 1 more messages]
In-Reply-To: <b016711e-034d-cf00-1434-beb75b9c263d@citrix.com>,
 <2076e9a4-c07e-9aab-1cc2-f38f7eacd8c0@citrix.com>
References: <20200127143444.25538-1-andrew.cooper3@citrix.com>
 <20200127143444.25538-8-andrew.cooper3@citrix.com>
 <24148.2202.912512.939428@mariner.uk.xensource.com>
 <cea79256-f260-1710-a783-dadec276e32a@citrix.com>
 <24161.10156.858608.199136@mariner.uk.xensource.com>
 <2076e9a4-c07e-9aab-1cc2-f38f7eacd8c0@citrix.com>
 <20200127143444.25538-4-andrew.cooper3@citrix.com>
 <24148.1780.909250.638385@mariner.uk.xensource.com>
 <1f074dca-9798-1ed9-0163-882eb2079d53@citrix.com>
 <24161.12968.77707.404087@mariner.uk.xensource.com>
 <b016711e-034d-cf00-1434-beb75b9c263d@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Andrew Cooper writes ("Re: [PATCH v2 03/17] tools/migration: Drop IHDR_VERSION constant from libxc and python"):
> I presume you mean here 2x send IHDR and 2x receive IHDR, one C and one
> Python in each case.
> 
> I understand what you're suggesting.� I completely disagree with it, as
> it obfuscates the logic and introduces a source of bugs for zero gain.
...
> The only thing IHDR_VERSION_* usefully gets you is the ability to get
> the defines accidentally wrong, and introduce bugs that way.

Andrew Cooper writes ("Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END inference for v2 compatibility"):
> On 05/03/2020 16:24, Ian Jackson wrote:
> > You could handle that with a small bit of code around one of the call
> > sites to adjust the error handling.  (Also, what a mess, but I guess
> > we're here now...)
> 
> ... which is the majority the code you're trying to abstract away.
...
> tl;dr I could put an #ifdef x86'd static inline in the root common
> header (xc_sr_common.h), but the overall complexity is greater than what
> is presented here.

I still don't agree with you I'm afraid.  I went back through our
messages, and looked at the code again, and I think we are probably
still not communicating well.  However, I thought about how best to
deal with this disagreement.  As the actual author of much of this
code, and certainly the person putting a lot of effort in, you should
get quite a bit of leeway.

I considered taking your branch and showing you what I meant in code
terms.  But ultimately I think this is a waste of our time and I don't
want us to get into a pointless argument.  I don't think these issues
matter enough to be worth the debate.  I don't think there are actual
bugs here - we're talking about matters of style and taste.

So,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

It would probably have been better for me to have got to this point
earlier.

Sorry,
Ian.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 16:12:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 16:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT6ND-00030D-FD; Mon, 27 Apr 2020 16:12:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rzTj=6L=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jT6NC-000308-3z
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 16:12:46 +0000
X-Inumbo-ID: edcef56e-88a1-11ea-97b4-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id edcef56e-88a1-11ea-97b4-12813bfff9fa;
 Mon, 27 Apr 2020 16:12:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588003965;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=9AwmgF3mgN+ShcKHRp3IUlOF91gtP/iS0pVbkfj3lXg=;
 b=TwJ7sDdcydGQtru2Ea6cFPtjiuaidDTI6ItEuO3yX8azPumx978CS09z
 vpnjpgp7IAzWR3ZK+wbFQEztQAn8BakBUtxYVtNTODujp6axt4feTZtXR
 bM3V6N6x/pqc5ykXhr9uAo75SfntulNS3rOb8BtUNrQi/SJjg2qk58jxz s=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Tv+J6ABWmQzkxLd9svLuiPF4trNRZeAv+HVj6YcTAgQmWPtEFZtrSPDLqqmO2LpWB+KHgwKIR0
 EBD/4xMY2SIFALoHQQQ8EQ/wgBDDIZBcE/FEpxYYpEfX0IIbf4Rb4Oz8a9CdOG4UoSZ6rpPmw/
 m8/+gz/sh1ViyXwTeLYTUX6LutBu8gcwUazLAOUYh3CuDarip/JISY/UjkV/qOOS0L+l7y6JtA
 B9Pg63jvkvfi5uTMWxgFf31DYRbpSSGAJ9X+iRyENxqZzfGpsoLmYDQGh1l3GFjoUJuSsHPQIX
 x/A=
X-SBRS: 2.7
X-MesageID: 16628802
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16628802"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24231.1144.546403.318433@mariner.uk.xensource.com>
Date: Mon, 27 Apr 2020 17:12:40 +0100
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 14/17] libxc/save: Write X86_{CPUID,MSR}_DATA records
In-Reply-To: <20200127143444.25538-15-andrew.cooper3@citrix.com>
References: <20200127143444.25538-1-andrew.cooper3@citrix.com>
 <20200127143444.25538-15-andrew.cooper3@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Andrew Cooper writes ("[PATCH v2 14/17] libxc/save: Write X86_{CPUID,MSR}_DATA records"):
> With all other plumbing in place, obtain the CPU Policy from Xen and
> write it into the migration stream.

Thanks for your earlier explanation in the thread:

  In all cases with migration development, the receive side logic
  (previous patch) has to come before the save side logic (this patch), or
  the result will break bisection with the receive side choking on an
  unknown record type.

  From the "whole series" point of view, compatibility is also the
  destination side discarding the data because libxl still needs its order
  of CPUID handling shuffling to cope.

I still would have some comments about the compatibility implications
*in the commit message*; maybe an abbreviated version the text above.

Nevertheless,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 16:19:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 16:19:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT6TD-0003D0-5v; Mon, 27 Apr 2020 16:18:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jT6TB-0003Cu-LS
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 16:18:57 +0000
X-Inumbo-ID: cac0871d-88a2-11ea-97b4-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cac0871d-88a2-11ea-97b4-12813bfff9fa;
 Mon, 27 Apr 2020 16:18:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588004336;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=FOWGreBxz92IOJgB0QwEMGiJIHFEFFCTUhDLgRDWo5Y=;
 b=NA+yBDDFKFapsxRdnWeQN5/6QBC3ah0TvvjPt6vinH3m8/IWTswOmR3z
 KXswDvJYSk5TCfqn81FH6o7KR4xp8u0LXWssaM48gVwhafzZLBb8eWMy6
 juw9nTRIgOScd0befpD1lTqSBuPN5OAyoXnHw+DBhxNEovCbihUBYxAJl I=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Y8frG35IAEqDcJJd14AgMqpxM8LXM5meRBA/E0va8hFfHxbwrG+dbKsAJmh3noNWdL+BVq7q3O
 vUfOVbyIKMyk8Bv8MFGY1BT6AZ8cBC6Af27VoS4UjeCyeU9XsSXMh4u5iWsO0TgpZ1lvyP4ca5
 9KqPRB2TD6yVf5FyEEIX9Wk6Wgo44T641KnesgRpYtrZttYyM7AsKWprpzmYfi/eTKaj5hP+nm
 /m8ZJfbRjhR2Uc3+J45NuVZRfa3ZyUL879uilNYxIuAb7rYExUxkwPH/a5HUGyD9OdvZp+heSk
 pkY=
X-SBRS: 2.7
X-MesageID: 16329530
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16329530"
Subject: Re: [PATCH] x86/ioemul: Rewrite stub generation
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200427122041.7162-1-andrew.cooper3@citrix.com>
 <20200427151829.GP28601@Air-de-Roger>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <cd4ae124-ce0b-85e6-bae7-94d32e1dba73@citrix.com>
Date: Mon, 27 Apr 2020 17:18:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200427151829.GP28601@Air-de-Roger>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27/04/2020 16:18, Roger Pau Monné wrote:
> On Mon, Apr 27, 2020 at 01:20:41PM +0100, Andrew Cooper wrote:
>> The logic is completely undocumented and almost impossible to follow.  It
>> actually uses return oriented programming.  Rewrite it to conform to more
>> normal call mechanics, and leave a big comment explaining thing.  As well as
>> the code being easier to follow, it will execute faster as it isn't fighting
>> the branch predictor.
>>
>> Move the ioemul_handle_quirk() function pointer from traps.c to
>> ioport_emulate.c.
> Seeing as the newest quirk was added in 2008, I wonder if such quirks
> are still relevant?
>
> Maybe they are also used by newer boxes, I really have no idea.

Its not something which I'd consider altering in this patch anyway.

>
>> +
>> +static unsigned int ioemul_handle_proliant_quirk(
>>      u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs)
>>  {
>>      static const char stub[] = {
>> @@ -19,18 +22,16 @@ static bool ioemul_handle_proliant_quirk(
>>          0xa8, 0x80, /*    test $0x80, %al */
>>          0x75, 0xfb, /*    jnz 1b          */
>>          0x9d,       /*    popf            */
>> -        0xc3,       /*    ret             */
>>      };
>>      uint16_t port = regs->dx;
>>      uint8_t value = regs->al;
>>  
>>      if ( (opcode != 0xee) || (port != 0xcd4) || !(value & 0x80) )
>> -        return false;
>> +        return 0;
>>  
>>      memcpy(io_emul_stub, stub, sizeof(stub));
>> -    BUILD_BUG_ON(IOEMUL_QUIRK_STUB_BYTES < sizeof(stub));
>>  
>> -    return true;
>> +    return sizeof(stub);
>>  }
>>  
>>  /* This table is the set of system-specific I/O emulation hooks. */
>> diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
>> index e24b84f46a..f150886711 100644
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -54,51 +54,96 @@ struct priv_op_ctxt {
>>      unsigned int bpmatch;
>>  };
>>  
>> -/* I/O emulation support. Helper routines for, and type of, the stack stub. */
>> -void host_to_guest_gpr_switch(struct cpu_user_regs *);
>> -unsigned long guest_to_host_gpr_switch(unsigned long);
>> +/* I/O emulation helpers.  Use non-standard calling conventions. */
>> +extern const char load_guest_gprs[], save_guest_gprs[];
>>  
>>  typedef void io_emul_stub_t(struct cpu_user_regs *);
>>  
>>  static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 opcode,
>>                                            unsigned int port, unsigned int bytes)
>>  {
>> +    /*
>> +     * Construct a stub for IN/OUT emulation.
>> +     *
>> +     * Some platform drivers communicate with the SMM handler using GPRs as a
>> +     * mailbox.  Therefore, we must perform the emulation with the hardware
>> +     * domain's registers in view.
>> +     *
>> +     * We write a stub of the following form, using the guest load/save
>> +     * helpers (abnormal calling conventions), and one of several possible
>> +     * stubs performing the real I/O.
>> +     */
>> +    static const char prologue[] = {
>> +        0x53,       /* push %rbx */
>> +        0x55,       /* push %rbp */
>> +        0x41, 0x54, /* push %r12 */
>> +        0x41, 0x55, /* push %r13 */
>> +        0x41, 0x56, /* push %r14 */
>> +        0x41, 0x57, /* push %r15 */
>> +        0x57,       /* push %rdi (param for save_guest_gprs) */
>> +    };              /* call load_guest_gprs */
>> +                    /* <I/O stub> */
>> +                    /* call save_guest_gprs */
>> +    static const char epilogue[] = {
>> +        0x5f,       /* pop %rdi  */
>> +        0x41, 0x5f, /* pop %r15  */
>> +        0x41, 0x5e, /* pop %r14  */
>> +        0x41, 0x5d, /* pop %r13  */
>> +        0x41, 0x5c, /* pop %r12  */
>> +        0x5d,       /* pop %rbp  */
>> +        0x5b,       /* pop %rbx  */
>> +        0xc3,       /* ret       */
>> +    };
>> +
>>      struct stubs *this_stubs = &this_cpu(stubs);
>>      unsigned long stub_va = this_stubs->addr + STUB_BUF_SIZE / 2;
>> -    long disp;
>> -    bool use_quirk_stub = false;
>> +    unsigned int quirk_bytes = 0;
>> +    char *p;
>> +
>> +    /* Helpers - Read outer scope but only modify p. */
>> +#define APPEND_BUFF(b) ({ memcpy(p, b, sizeof(b)); p += sizeof(b); })
>> +#define APPEND_CALL(f)                                                  \
>> +    ({                                                                  \
>> +        long disp = (long)(f) - (stub_va + p - ctxt->io_emul_stub + 5); \
>> +        BUG_ON((int32_t)disp != disp);                                  \
> I'm not sure I get the point of using signed integers instead of
> unsigned ones, AFAICT you just want to check that the displacement is
> < 4GB so that a relative call can be used?

Displacements are +/- 2G, not <4G.

Using unsigned here would be buggy.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 16:24:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 16:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT6YT-00047Q-W3; Mon, 27 Apr 2020 16:24:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jrem=6L=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jT6YS-00047L-F4
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 16:24:24 +0000
X-Inumbo-ID: 8ddd0428-88a3-11ea-97b5-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8ddd0428-88a3-11ea-97b5-12813bfff9fa;
 Mon, 27 Apr 2020 16:24:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588004664;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=q/rpydCk44pAeEWZsE66SR2vog6LZXWorQceKobYUZY=;
 b=Yyew8StL4bBYlUNmBNA2MZzZiszQ1IHgX0eYEOLH6Tb/9klDP0h6jis2
 576LHHFH/Q7UrKts07cUSfKFG4MX55V6lyoDIgTtSLJzxsH2ZtF7No/Tp
 RGfo5pzxr9+PBNnGIs+5aXLJ+Yae46KSJwzZG6dx92uE6BcmJv5zlVNIq Q=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: pzsfqlt2MCbZV+Y8lSRxc85fTCPutaEfwwRMIXJNWAg98B/0vCmgd2lpRibYKcsJHmgWOYqzPL
 cKG+zvNhxOVGtUeUomfNnz91zc7OX7oFnUZpngi+/Zeive5HgmIqpUY19wym1/IhLG/sZuM5WH
 LtCb8/MYjQUx5X/naJL4kGTdg5GYiqU3wOslOhPInurDPfP5gSsBLOdJwfqj804zcWtRnwdqLk
 tj4MEpGNVNCfG4AVKItYF3x4KDVt5UL86G3SMOYMf8PBJPiSj9ErbD55V2M1oMXuHGe2Jf6lsF
 k18=
X-SBRS: 2.7
X-MesageID: 16298457
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="16298457"
Date: Mon, 27 Apr 2020 18:23:59 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/ioemul: Rewrite stub generation
Message-ID: <20200427162359.GR28601@Air-de-Roger>
References: <20200427122041.7162-1-andrew.cooper3@citrix.com>
 <20200427151829.GP28601@Air-de-Roger>
 <cd4ae124-ce0b-85e6-bae7-94d32e1dba73@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <cd4ae124-ce0b-85e6-bae7-94d32e1dba73@citrix.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 05:18:52PM +0100, Andrew Cooper wrote:
> On 27/04/2020 16:18, Roger Pau Monné wrote:
> > On Mon, Apr 27, 2020 at 01:20:41PM +0100, Andrew Cooper wrote:
> >> +    /* Helpers - Read outer scope but only modify p. */
> >> +#define APPEND_BUFF(b) ({ memcpy(p, b, sizeof(b)); p += sizeof(b); })
> >> +#define APPEND_CALL(f)                                                  \
> >> +    ({                                                                  \
> >> +        long disp = (long)(f) - (stub_va + p - ctxt->io_emul_stub + 5); \
> >> +        BUG_ON((int32_t)disp != disp);                                  \
> > I'm not sure I get the point of using signed integers instead of
> > unsigned ones, AFAICT you just want to check that the displacement is
> > < 4GB so that a relative call can be used?
> 
> Displacements are +/- 2G, not <4G.
> 
> Using unsigned here would be buggy.

Right, sorry for the noise:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

With the minor nits pointed above in the ioemul_handle_quirk.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 16:26:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 16:26:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT6Zz-0004Cl-BV; Mon, 27 Apr 2020 16:25:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oTJa=6L=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jT6Zy-0004Cf-Gu
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 16:25:58 +0000
X-Inumbo-ID: c5ef3bf6-88a3-11ea-ae69-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c5ef3bf6-88a3-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 16:25:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588004757;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=AaJel5qhef3WV4a7x6x4j2jvv6bUS3ZyIdHAUH1Bhds=;
 b=S0IiEuEIIXsntHtIXLBezzLRSwAw2wFEIORNbKvNWEJ0WcNLeiXto6/Q
 YYBovKqbPxKWBc+R8sgzUcGU1jTALKNrKU8Y6Sth1r5ETKorgShPVhHT1
 il/8JunVMvYVZ0y5IJllJIhFO9V5OmOXLECrYL7TB250J8of4nlMU+JOr A=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: qcUmMNUDSUxqpZoOPp4vszVcTszMM3sTpXQZ5BUEBKFF/Ad0juXEiUDxQkcG46IoHzEhtMnBIk
 4LocM6UEZAIjI6gyPoJki7ndUbOTjcm+sv1QsxXNUDf6rTqFWZquk+lU6u2SpEmHpnltvQT1Wf
 HKJy19HiUdElHQOgCfO1VFiL2JTI8yzMkeWU59W7a/aUaFrJpMJMUESBb/tArUluOzxqSi2LwU
 xR4wAFu8dNAlu8Vs33roilvk82xmgBsQAJHjI5xsNW7jZ0AtPWmpSAihCEkFgEpUCdFsiffMfQ
 g/g=
X-SBRS: 2.7
X-MesageID: 17002825
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="17002825"
From: George Dunlap <George.Dunlap@citrix.com>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
Thread-Topic: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
Thread-Index: AQHWCQXiBGUb+wr760WOfoEenUG4zahnVWoAgAALjICAAAX/gIAAAzMAgASARQCAITZdgIAADK2A
Date: Mon, 27 Apr 2020 16:25:53 +0000
Message-ID: <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
 <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
In-Reply-To: <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <2FA018FB7608324CA306BCC9EAAD71C2@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew
 Cooper <Andrew.Cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDI3LCAyMDIwLCBhdCA0OjQwIFBNLCBKw7xyZ2VuIEdyb8OfIDxqZ3Jvc3NA
c3VzZS5jb20+IHdyb3RlOg0KPiANCj4gU3RlZmFubywNCj4gDQo+IE9uIDA2LjA0LjIwIDE0OjI5
LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+IE9uIDAzLjA0LjIwMjAgMTc6NDUsIErDvHJnZW4gR3Jv
w58gd3JvdGU6DQo+Pj4gT24gMDMuMDQuMjAgMTc6MzMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+
PiBPbiAwMy4wNC4yMDIwIDE3OjEyLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4+Pj4gT24gMDMu
MDQuMjAgMTY6MzEsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+Pj4+IE9uIDAyLjA0LjIwMjAgMTc6
NDYsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+Pj4+Pj4+IC0tLSBhL3hlbi9jb21tb24vS2NvbmZp
Zw0KPj4+Pj4+PiArKysgYi94ZW4vY29tbW9uL0tjb25maWcNCj4+Pj4+Pj4gQEAgLTM1Myw2ICsz
NTMsMTYgQEAgY29uZmlnIERPTTBfTUVNDQo+Pj4+Pj4+ICAgICAgICAgICAgTGVhdmUgZW1wdHkg
aWYgeW91IGFyZSBub3Qgc3VyZSB3aGF0IHRvIHNwZWNpZnkuDQo+Pj4+Pj4+ICAgICtjb25maWcg
SFlQRlNfQ09ORklHDQo+Pj4+Pj4+ICsgICAgYm9vbCAiUHJvdmlkZSBoeXBlcnZpc29yIC5jb25m
aWcgdmlhIGh5cGZzIGVudHJ5Ig0KPj4+Pj4+PiArICAgIGRlZmF1bHQgeQ0KPj4+Pj4+IA0KPj4+
Pj4+IE15IGluaXRpYWwgcmVhY3Rpb24gd2FzIHRvIGFzayBmb3IgImRlcGVuZHMgb24gSFlQRlMi
LCBidXQgdGhlbg0KPj4+Pj4+IEkgbm90aWNlZCB0aGUgZWFybGllciBwYXRjaCBkb2Vzbid0IGlu
dHJvZHVjZSBzdWNoLiBBbSBJDQo+Pj4+Pj4gbWlzLXJlbWVtYmVyaW5nIHRoYXQgaXQgd2FzIGFn
cmVlZCB0byBtYWtlIHRoZSB3aG9sZSB0aGluZw0KPj4+Pj4+IHBvc3NpYmxlIHRvIGRpc2FibGUg
YXQgbGVhc3QgaW4gRVhQRVJUIG1vZGU/DQo+Pj4+PiANCj4+Pj4+IE5vLCBJIGRvbid0IHJlbWVt
YmVyIHRoYXQgYWdyZWVtZW50Lg0KPj4+Pj4gDQo+Pj4+PiBBbmQgVEJIIEknbSBub3Qgc3VyZSB0
aGlzIGlzIGEgZ29vZCBpZGVhLCBhcyB0aGF0IHdvdWxkIGF0IG9uY2UgbWFrZSB0aGUNCj4+Pj4+
IHBsYW4gdG8gcmVwbGFjZSBhdCBsZWFzdCBzb21lIHN5c2N0bCBhbmQvb3IgZG9tY3RsIGludGVy
ZmFjZXMgaW1wb3NzaWJsZQ0KPj4+Pj4gKGxpa2UgZS5nLiB0aGUgbGFzdCAzIHBhdGNoZXMgb2Yg
dGhlIHNlcmllcyBhcmUgZG9pbmcgYWxyZWFkeSksIG9yIGF0DQo+Pj4+PiBsZWFzdCB3b3VsZCB0
aWUgdGhlIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSB0byBDT05GSUdfSFlQRlMuDQo+Pj4+IA0KPj4+
PiBJIHRoaW5rIHRoYXQgd291bGQgYmUgZmluZSAtIHRoYXQncyB3aGF0IGNvbmZpZyBzZXR0aW5n
IGFyZSBmb3IuDQo+Pj4+IFNvbWVvbmUgY2FyaW5nIGFib3V0IHNwYWNlIG1heSBub3QgY2FyZSBh
Ym91dCBydW50aW1lIHNldHRpbmcgb2YNCj4+Pj4gcGFyYW1ldGVycy4NCj4+PiANCj4+PiBTbyBy
aWdodCBub3cgaXQgd291bGQgc3RhcnQgd2l0aCBhIHBsYWluIGh5cGZzIGF2YWlsYWJsZSBvciBu
b3QuDQo+Pj4gDQo+Pj4gVGhlIG5leHQgc3RlcCB3b3VsZCBiZSBpbiBwYXRjaCAxMiB0byB0ZWxs
IHRoZSB1c2VyIGhlIHdpbGwgbG9zZSB0aGUNCj4+PiBjYXBhYmlsaXR5IG9mIHNldHRpbmcgcnVu
dGltZSBwYXJhbWV0ZXJzLg0KPj4+IA0KPj4+IEFub3RoZXIgcGxhbm5lZCBleHRlbnNpb24gd291
bGQgYmUgdG8gY29udHJvbCBwZXItY3B1cG9vbCBzZXR0aW5ncywNCj4+PiB3aGljaCB3b3VsZCB0
aGUgZ28gYXdheSAocG9zc2libHkgZnVuY3Rpb25hbGl0eSBiZWluZyB1bmNvbmRpdGlvbmFsbHkN
Cj4+PiBhdmFpbGFibGUgdG9kYXkpLg0KPj4+IA0KPj4+IE5leHQgd291bGQgYmUgdGhlIGxhY2sg
b2YgYmVpbmcgYWJsZSB0byBjb250cm9sIHBlci1kb21haW4gbWl0aWdhdGlvbnMNCj4+PiBsaWtl
IFhQVEkgb3IgTDFURiwgd2hpY2ggSSdkIGxpa2UgdG8gYWRkLg0KPj4+IA0KPj4+IEFub3RoZXIg
dGhpbmcgSSB3YW50ZWQgdG8gYWRkIGlzIHNvbWUgZGVidWdnaW5nIHN0dWZmIChlLmcuIHRvIHN3
aXRjaA0KPj4+IGxvY2sgcHJvZmlsaW5nIHVzaW5nIGh5cGZzKS4NCj4+PiANCj4+PiBBbmQgdGhl
IGxpc3Qgd2lsbCBnbyBvbi4NCj4+IFVuZGVyc3Rvb2QuDQo+Pj4gRG9lcyBpdCByZWFsbHkgbWFr
ZSBzZW5zZSB0byBtYWtlIGEgY2VudHJhbCBjb250cm9sIGFuZCBpbmZvcm1hdGlvbg0KPj4+IGlu
dGVyZmFjZSBjb25kaXRpb25hbD8NCj4+IE5vbmUgb2YgdGhlIGFib3ZlIG1heSBiZSBvZiBpbnRl
cmVzdCB0byBlLmcuIGVtYmVkZGVkIHVzZSBjYXNlcy4NCj4+PiBJJ2QgbGlrZSBhdCBsZWFzdCBh
IHNlY29uZCBvcGluaW9uIG9uIHRoYXQgdG9waWMuDQo+PiBZZXMsIGZ1cnRoZXIgb3BpbmlvbnMg
d291bGQgc3VyZWx5IGhlbHAuDQo+IA0KPiBBbnkgb3BpbmlvbiBvbiBtYWtpbmcgaHlwZnMgY29u
ZmlndXJhYmxlPw0KPiANCj4gSXQgd291bGQgYmUgcXVpdGUgc29tZSBjb2RlIGNodXJuIGFuZCBJ
IHdhbnQgdG8gYXZvaWQgaXQgaW4gY2FzZSB5b3UNCj4gc2VlIG5vIGJlbmVmaXQgaW4gY29uZmln
dXJpbmcgaXQgb3V0IGZvciBlbWJlZGRlZC4NCg0KSnVzdCB0byByZXBseSB3aXRoIHdoYXQgSSBz
YWlkIG9uIElSQzoNCg0KRmlyc3Qgb2YgYWxsLCBpZiBpdCB3ZXJlIGZyZWUsIEkgdGhpbmsgdGhh
dCBoYXZpbmcgQ09ORklHX0hZUEZTIHdvdWxkIGJlIHZhbHVhYmxlLiAgU3ViLW9wdGlvbnMgc2hv
dWxkIGJlIG1hZGUgYXZhaWxhYmxlIG9uIGEgY2FzZS1ieS1jYXNlIGJhc2lzOyBJIHRoaW5rIENP
TkZJR19IWVBGU19DT05GSUcgd291bGQgYmUgdmFsdWFibGUsIGJ1dCBJIGRvbuKAmXQgc2VlIGFu
eSBwb2ludCBpbiBoYXZpbmcgQ09ORklHX0hZUEZTX1JVTlRJTUVfUEFSQU1FVEVSLg0KDQpIb3dl
dmVyLCAgSnVlcmdlbiBzZWVtcyB0byB0aGluayBpdCB3b3VsZCByZXF1aXJlIGEgbG90IG9mIGNo
dXJuIHRvIHRoZSBjdXJyZW50IHNlcmllcy4gIEkgZG9u4oCZdCBxdWl0ZSB1bmRlcnN0YW5kIHdo
eTsgYnV0IHN1cHBvc2luZyB0aGF04oCZcyBzbzogSW4gZ2VuZXJhbCwgdGhlIHBlb3BsZSB3aG8g
d2FudCBhIGZlYXR1cmUgc2hvdWxkIGJlIHRoZSBvbmVzIHdobyBkbyB0aGUgd29yayB0byBtYWtl
IGl0LiAgSSB0aGluayBpdCB3b3VsZCBiZSBwZXJmZWN0bHkgcmVhc29uYWJsZSBmb3IgSnVlcmdl
biB0byBzYXksIOKAnFRoaXMgaXMgYSBsb3Qgb2Ygd29yayB0aGF0IEkgZG9u4oCZdCBoYXZlIHRp
bWUgdG8gZG8gYmVmb3JlIHRoZSA0LjE0IHJlbGVhc2U7IGlmIHBlb3BsZSB3YW50IHRvIGJlIGFi
bGUgdG8gZGlzYWJsZSB0aGlzIGZlYXR1cmUsIHRoZXkgY2FuIHBvc3QgdGhlaXIgb3duIHBhdGNo
ZXMu4oCdICAoSXTigJlzIGFsc28gcGVyZmVjdGx5IHJlYXNvbmFibGUgZm9yIGhpbSB0byBkbyB0
aGUgd29yayBoaW1zZWxmIGp1c3QgdG8gYmUgaGVscGZ1bC4pDQoNClRoZSBkaXNjdXNzaW9uIGFi
b3V0IENPTkZJR19FWFBFUlQgaXMgc29ydCBvZiB0aGUgc2FtZS4gIElmIHdlIGhhdmUgQ09ORklH
X0hZUEZTLCBpdCB3b3VsZCBvYnZpb3VzbHkgYmUgbW9yZSB2YWx1YWJsZSBpZiBpdCB3ZXJlICpu
b3QqIGluIENPTkZJR19FWFBFUlQsIHNvIHRoYXQgcGVvcGxlIGNvdWxkIGNoYW5nZSBpdCB3aGls
ZSBzdGlsbCBiZWluZyBzZWN1cml0eSBzdXBwb3J0ZWQuDQoNCklmIEphbiBpcyBPSyB3aXRoIGl0
IHNpbXBseSBiZWluZyBvdXRzaWRlIENPTkZJR19FWFBFUlQsIHRoZW4gZ3JlYXQuICBCdXQgaWYg
aGUgaW5zaXN0cyBvbiBzb21lIGtpbmQgb2YgdGVzdGluZyBmb3IgaXQgdG8gYmUgb3V0c2lkZSBv
ZiBDT05GSUdfRVhQRVJULCB0aGVuIGFnYWluLCB0aGUgcGVvcGxlIHdobyB3YW50IGl0IHRvIGJl
IHNlY3VyaXR5IHN1cHBvcnRlZCBzaG91bGQgYmUgdGhlIG9uZXMgd2hvIGRvIHRoZSB3b3JrIHRv
IG1ha2UgaXQgaGFwcGVuLg0KDQpIb3BlIHRoYXQgbWFrZXMgc2Vuc2UuIDotKQ0KDQogLUdlb3Jn
ZQ==


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 16:36:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 16:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT6k0-0005Bw-CF; Mon, 27 Apr 2020 16:36:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BtrQ=6L=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jT6jz-0005Br-HO
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 16:36:19 +0000
X-Inumbo-ID: 370f49d8-88a5-11ea-b9cf-bc764e2007e4
Received: from mga12.intel.com (unknown [192.55.52.136])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 370f49d8-88a5-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 16:36:16 +0000 (UTC)
IronPort-SDR: 6aKooz1thBqvXDvwqwubCtsRfPA4ZJdjTh2JQkaKZZGZKF3Q80cPJEwg3x0mrJ1wi839j+W7pn
 SKWy4e45k6pA==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga007.fm.intel.com ([10.253.24.52])
 by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 27 Apr 2020 09:36:15 -0700
IronPort-SDR: fIxKDoxW3NEB5x0T+1W2eUbk66JHIjak0g21kHPa7AFHzxGqpCiPR93bd1TRSH7U+PAEforAfx
 MAAfaMbbD5lA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.73,324,1583222400"; d="scan'208";a="247457283"
Received: from tlengyel-mobl2.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.135.4.141])
 by fmsmga007.fm.intel.com with ESMTP; 27 Apr 2020 09:36:14 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] mem_sharing: map shared_info page to same gfn during fork
Date: Mon, 27 Apr 2020 09:36:05 -0700
Message-Id: <08d022bbca06c59624817ac9e23ddcb288121763.1588004969.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

During a VM fork we copy the shared_info page; however, we also need to ensure
that the page is mapped into the same GFN in the fork as its in the parent.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Suggested-by: Roger Pau Monne <roger.pau@citrix.com>
---
 xen/arch/x86/mm/mem_sharing.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 344a5bfb3d..acbf21b22c 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1656,6 +1656,7 @@ static void copy_tsc(struct domain *cd, struct domain *d)
 static int copy_special_pages(struct domain *cd, struct domain *d)
 {
     mfn_t new_mfn, old_mfn;
+    gfn_t old_gfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(cd);
     static const unsigned int params[] =
     {
@@ -1701,6 +1702,34 @@ static int copy_special_pages(struct domain *cd, struct domain *d)
     new_mfn = _mfn(virt_to_mfn(cd->shared_info));
     copy_domain_page(new_mfn, old_mfn);
 
+    old_gfn = _gfn(get_gpfn_from_mfn(mfn_x(old_mfn)));
+
+    if ( !gfn_eq(old_gfn, INVALID_GFN) )
+    {
+        /* let's make sure shared_info is mapped to the same gfn */
+        gfn_t new_gfn = _gfn(get_gpfn_from_mfn(mfn_x(new_mfn)));
+
+        if ( !gfn_eq(new_gfn, INVALID_GFN) && !gfn_eq(old_gfn, new_gfn) )
+        {
+            /* if shared info is mapped to a different gfn just remove it */
+            rc = p2m->set_entry(p2m, new_gfn, INVALID_MFN, PAGE_ORDER_4K,
+                                p2m_invalid, p2m->default_access, -1);
+            if ( rc )
+                return rc;
+
+            new_gfn = INVALID_GFN;
+        }
+
+        if ( gfn_eq(new_gfn, INVALID_GFN) )
+        {
+            /* if shared info is not currently mapped then map it */
+            rc = p2m->set_entry(p2m, old_gfn, new_mfn, PAGE_ORDER_4K,
+                                p2m_ram_rw, p2m->default_access, -1);
+            if ( rc )
+                return rc;
+        }
+    }
+
     return 0;
 }
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Mon Apr 27 17:20:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 17:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT7Q1-0000VM-Sp; Mon, 27 Apr 2020 17:19:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rzTj=6L=citrix.com=ian.jackson@srs-us1.protection.inumbo.net>)
 id 1jT7Q0-0000VH-EV
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 17:19:44 +0000
X-Inumbo-ID: 48b36e84-88ab-11ea-ae69-bc764e2007e4
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 48b36e84-88ab-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 17:19:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588007983;
 h=from:mime-version:content-transfer-encoding:message-id:
 date:to:cc:subject:in-reply-to:references;
 bh=dUsJOvSfZAJHLaULfouDWhHbDdrV8NyEAwO3SKAz4Qw=;
 b=HJSH3mD6QY0dcsTKIONkUxZZOjZGXnjcNG3Pduy/1PwAdbePIl3rTn2T
 8PuH/oJMV55VDPBbc4Snymri9n3G+gFtZeI8J/I+7pkjs7ptFAq2JtlSi
 ep6fftGlb/hsv3MGluXa+PfDVKTjO6HCzqRZlsQ16y+pObx3G2fM/EQ1o 8=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=ian.jackson@citrix.com;
 spf=Pass smtp.mailfrom=Ian.Jackson@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 ian.jackson@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="ian.jackson@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Ian.Jackson@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="Ian.Jackson@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Ian.Jackson@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: RTfL2MK298dSewkDORuNIH88IT9ojSZwpeM2g+p0eEdXIpHDsNaIVwaxe7K6ruaSve6SKe1JMF
 eTvX7ZnTNPUbnlRTf1Wbj0amjcV9svFLXw9w1u0edx/36NqIMs6RAGqOwGM4QXZ7RqikSa1Bxt
 Ffb3EyGScmIYfbIDHPNJeNv4RMirrw2aRbOIO1WEfyj811rI9DsDOswGT6vYKH+exz1fskHEz3
 mQ+nK0tzdNQhSFUk2TMFe/W1iR0Poq8I1+sgw8TT4oOk9+WI0f//Z4V6s4qRnJLXoJqXHNkbtP
 jFc=
X-SBRS: 2.7
X-MesageID: 17005976
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,324,1583211600"; d="scan'208";a="17005976"
From: Ian Jackson <ian.jackson@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24231.5161.862828.377795@mariner.uk.xensource.com>
Date: Mon, 27 Apr 2020 18:19:37 +0100
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [PATCH 01/12] libxc/save: Shrink code volume where possible
In-Reply-To: <a10d1572-d5c5-716a-0651-aee2345348dd@citrix.com>
References: <20191224151932.6304-1-andrew.cooper3@citrix.com>
 <20191224151932.6304-2-andrew.cooper3@citrix.com>
 <24093.61657.676890.721999@mariner.uk.xensource.com>
 <a10d1572-d5c5-716a-0651-aee2345348dd@citrix.com>
X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Andrew Cooper writes ("Re: [PATCH 01/12] libxc/save: Shrink code volume where possible"):
> On 14/01/2020 16:48, Ian Jackson wrote:
> > Andrew Cooper writes ("[PATCH 01/12] libxc/save: Shrink code volume where possible"):
> >> A property of how the error handling (0 on success, nonzero otherwise)
> >> allows these calls to be chained together with the ternary operatior.
> > I'm quite surprised to find a suggestion like this coming from you in
> > particular.
> 
> What probably is relevant is that ?: is a common construct in the
> hypervisor, which I suppose does colour my expectation of people knowing
> exactly what it means and how it behaves.

I expect other C programmers to know what ?: does, too.  But I think
using it to implement the error monad is quite unusual.  I asked
around a bit and my feeling is still that this isn't an improvement.

> > Or just to permit
> >    rc = write_one_vcpu_basic(ctx, i);    if (rc) goto error;
> > (ie on a single line).
> 
> OTOH, it should come as no surprise that I'd rather drop this patch
> entirely than go with these alternatives, both of which detract from
> code clarity. The former for hiding control flow, and the latter for
> being atypical layout which unnecessary cognitive load to follow.

I think, then, that it would be best to drop this patch, unless Wei
(or someone else) disagrees with me.

Sorry,
Ian.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 17:29:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 17:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT7ZC-0001TP-QZ; Mon, 27 Apr 2020 17:29:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6V0E=6L=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jT7ZB-0001TK-6u
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 17:29:13 +0000
X-Inumbo-ID: 9c120968-88ac-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9c120968-88ac-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 17:29:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=5SCBwc1vU9nLu6cLAnOLZdHaBMnc0uMTGOaOgbYQKik=; b=ln1oo0gYUiniRgD6/ynGSvgmT
 IxyOg1fuzL/r5fipV7ccOO63dFXaHaKfAR8l6hx2L6VDyGZXgFwRsiP4P9yq7cWwhLhm1jaiAh/Lh
 H90B+vM/asHrivC3MEUOFoJVWVKg1790HtI+ehz69N6ce8Gyngitrzjks80LsmAnn0K30=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jT7ZA-00052O-2R; Mon, 27 Apr 2020 17:29:12 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jT7Z9-000173-HF; Mon, 27 Apr 2020 17:29:11 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jT7Z9-0008P5-Et; Mon, 27 Apr 2020 17:29:11 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149837-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149837: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=df669de074c395a3b2eeb975fddd3da4c148da13
X-Osstest-Versions-That: xen=8d4c17a90b0a9b3d82628461090a54a2c7897154
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 27 Apr 2020 17:29:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149837 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149837/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  df669de074c395a3b2eeb975fddd3da4c148da13
baseline version:
 xen                  8d4c17a90b0a9b3d82628461090a54a2c7897154

Last test of basis   149834  2020-04-27 08:01:51 Z    0 days
Testing same since   149837  2020-04-27 14:00:43 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@citrix.com>
  Nick Rosbrook <rosbrookn@ainfosec.com>
  Nick Rosbrook <rosbrookn@gmail.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   8d4c17a90b..df669de074  df669de074c395a3b2eeb975fddd3da4c148da13 -> smoke


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 18:52:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 18:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT8rB-00015d-7d; Mon, 27 Apr 2020 18:51:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ib6x=6L=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jT8rA-00015Y-IS
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 18:51:52 +0000
X-Inumbo-ID: 27c60990-88b8-11ea-9887-bc764e2007e4
Received: from mail-lf1-x141.google.com (unknown [2a00:1450:4864:20::141])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 27c60990-88b8-11ea-9887-bc764e2007e4;
 Mon, 27 Apr 2020 18:51:51 +0000 (UTC)
Received: by mail-lf1-x141.google.com with SMTP id t11so14730629lfe.4
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 11:51:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=xJWtaGV3HpFJmnzJ96JfxLKzBXP4eI5AWSVq/c564Ak=;
 b=OyM1Skkym1k1VllShjxlEO5SPWnla5Rt3Qx3x0V7ETOw4ic1VvpXCQ3OkK60qQAp3C
 PTDoHH58ozbS/WzBHBnZ62XIk4AbOwZiYi9KmV1x3w8asIuoszHtcRaeXccHReOoCLlY
 60G2lBBEtYmjKLAgWcmUuSXaKHywL36qdMYYaF/AHRIhVaDk3T8QvSSTMr/5qiFsG2VY
 sx/Y2yhrS+qEvmp5qaqCtGoKClJCTxQKa72MEVlS3wON1WURQIEA5ovfEBBiSqhsOM7Z
 ZCerHaAksaw/CSoaM1nJyrjztKP0NR4Ii9gHRLRHwUMqVWzC1sXV01zEdtthbfFl3QYX
 a55A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=xJWtaGV3HpFJmnzJ96JfxLKzBXP4eI5AWSVq/c564Ak=;
 b=BBbTKeVZMZcv8jtrHrwVPiu/q0kmP1vxaJwbgzz2Ph9twO/cPyQTp7talIScLaxC+D
 dnO6ETzL11hoe5RSd0xo29YAm6brVT36xwp5xix6ogZzuPf18ka4QshMmJuFyXhrCqBi
 uhxwIa/wtdyjKz3XjSwypEnAn0LQ9vGCaIlTiO2lTLzDsFa8rStS64flF1fBqWva67/V
 iLtGVETudzRxV4feY5za210XA80sFCYKZ5C4+giTFmiWQVT0S5WBQ+v/d9ecnmGy/Lio
 OtQ7W05P/Nf5aLJTmjZ2K+Kp66Olelr4W0KYPBVBfEHW4cXDPlrbma8nqIK5n6MEqDTX
 L7LQ==
X-Gm-Message-State: AGi0PuYi3RNO0DJsQp34rddKDvVwqgD2eXOlJoxuMiRsoDbTf89uNNv9
 dyrMyUiTKkuCySqrm5oj81JNmCyK/21qEZ5s59o=
X-Google-Smtp-Source: APiQypLfZ/PWH3jcNEAS+wxdyNhmnLSeoENPIPfV7urhegmMSzJKEE7ZthCVD3yPpodQEY/L6jYpEVysgDkCpEy1cgU=
X-Received: by 2002:a05:6512:490:: with SMTP id
 v16mr16612049lfq.71.1588013510582; 
 Mon, 27 Apr 2020 11:51:50 -0700 (PDT)
MIME-Version: 1.0
References: <cover.1587682041.git.rosbrookn@ainfosec.com>
 <73e709cf0a87f3728de438e4a3b849462fd098ac.1587682041.git.rosbrookn@ainfosec.com>
 <59C12770-F12A-45B7-AB62-8BB3A0DC96D8@citrix.com>
In-Reply-To: <59C12770-F12A-45B7-AB62-8BB3A0DC96D8@citrix.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Mon, 27 Apr 2020 14:51:39 -0400
Message-ID: <CAEBZRSdtmyuKP4+yv8-2FjAkmBAc8L9MNr9r5cT4yUcyNM_v=g@mail.gmail.com>
Subject: Re: [PATCH v2 1/1] golang/xenlight: add NameToDomid and DomidToName
 util functions
To: George Dunlap <George.Dunlap@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Ian Jackson <Ian.Jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 8:59 AM George Dunlap <George.Dunlap@citrix.com> wr=
ote:
>
>
>
> > On Apr 24, 2020, at 4:02 AM, Nick Rosbrook <rosbrookn@gmail.com> wrote:
> >
> > Many exported functions in xenlight require a domid as an argument. Mak=
e
> > it easier for package users to use these functions by adding wrappers
> > for the libxl utility functions libxl_name_to_domid and
> > libxl_domid_to_name.
> >
> > Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
> > ---
> > tools/golang/xenlight/xenlight.go | 38 ++++++++++++++++++++++++++++++-
> > 1 file changed, 37 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/=
xenlight.go
> > index 6b4f492550..d1d30b63e1 100644
> > --- a/tools/golang/xenlight/xenlight.go
> > +++ b/tools/golang/xenlight/xenlight.go
> > @@ -21,13 +21,13 @@ package xenlight
> > #cgo LDFLAGS: -lxenlight -lyajl -lxentoollog
> > #include <stdlib.h>
> > #include <libxl.h>
> > +#include <libxl_utils.h>
> >
> > static const libxl_childproc_hooks childproc_hooks =3D { .chldowner =3D=
 libxl_sigchld_owner_mainloop };
> >
> > void xenlight_set_chldproc(libxl_ctx *ctx) {
> >       libxl_childproc_setmode(ctx, &childproc_hooks, NULL);
> > }
> > -
> > */
> > import "C"
> >
> > @@ -75,6 +75,10 @@ var libxlErrors =3D map[Error]string{
> >       ErrorFeatureRemoved:               "Feature removed",
> > }
> >
> > +const (
> > +     DomidInvalid Domid =3D ^Domid(0)
>
> Not to be a stickler, but are we positive that this will always result in=
 the same value as C.INVALID_DOMID?
>
> There are some functions that will return INVALID_DOMID, or accept INVALI=
D_DOMID as an argument.  Users of the `xenlight` package will presumably ne=
ed to compare against this value and/or pass it in.
>
> It seems like we could:
>
> 1. Rely on language lawyering to justify our assumption that ^Domid(0) wi=
ll always be the same as C =E2=80=9C~0=E2=80=9D
>
> 2. On marshalling into / out of C, convert C.INVALID_DOMID to DomidInvali=
d
>
> 3. Set Domid =3D C.INVALID_DOMID

I just tested this way, and it does not work as expected. Since
C.INVALID_DOMID is #define'd, cgo does not know it is intended to be
used as uint32_t, and decides to declare C.INVALID_DOMID as int. So,
C.INVALID_DOMID =3D ^int(0) =3D -1, which overflows Domid.

I tried a few things in the cgo preamble without any luck.
Essentially, one cannot define a const uint32_t in C space, and use
that to define a const in Go space.

Any ideas?

-NR


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 19:28:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 19:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT9Q8-00040A-3N; Mon, 27 Apr 2020 19:28:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=vXlK=6L=yahoo.com=akm2tosher@srs-us1.protection.inumbo.net>)
 id 1jT9Q6-0003zr-Ir
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 19:27:58 +0000
X-Inumbo-ID: 32d102cc-88bd-11ea-ae69-bc764e2007e4
Received: from sonic315-21.consmr.mail.ne1.yahoo.com (unknown [66.163.190.147])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 32d102cc-88bd-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 19:27:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1588015676; bh=IYkeoNs4JtRYr21msPhC3mQ4YJ5CNxllenBLvvqmKrw=;
 h=Date:From:To:In-Reply-To:References:Subject:From:Subject;
 b=OI7QZYg4/Pd73OzFnI5VWU+arixdVmVA1K9W73fW6ABoohSJ3A5edrEzTogHMeS+H1HVnfDcQm8TjABv69VaDIfM40jlCO8IhoG/FidPhi2nXcJkzWRp+gd7ZC/UWwl5VYby4eVzwuLyO45y+l5Pm/q6ForVE75411lQF7XHApTSYHV1kFcJhct1ZzcgagQzw/3DiHfM3+qf5qG23spbZ/izVuJSYIsenlnycDfmg6kY7zdf+nDcZvJ2nkdba/XRw7L1ZWY2LYXaokqPm2DChUOLn5gImVdwgg603GYXVnrzHbNoswUEAOy5GhsDp3uMXWpaZPoo/u6BPTCLxzg4yA==
X-YMail-OSG: QbapiF4VM1keGjavqEbRJMb6b9nlrnIxpIY3nBzFoRCeUvzz_QIMlJjPqLmgBjU
 ME6_5Z0jlP85h0GFRuPc.CBoQB0mMDdzKvgwYuvfelLmlQlvMRl_Pj7VeBbarAHErpsK.sTQjHUY
 x5wnIeQ8O2Yn8Y7i26DylMOHvRQC04e3cPzOKD.herWKPuR0KgPYGOl7j.VAliMgdMT3Zuxu95F_
 R.6aHSwxxkq4xgt5dd8MthKHl5ZiAMNtyKJOm9FMs3_UtGTHJAwPpZLtxak3Le3RrL.sz6bWOUQ2
 5sFabgTnhi3YxGfuaJ2W529k62Uq9gR6N3w1FUPKzZa1LjNruVID6TvDI_bwqSbBqd8NnJl5hZEa
 lx27ndLA8sWn798TtvNBHlMZxFarT.yNIJSygma7qsc5PnHsy0kbJYbKY5StCpsfAzT71BgYUltS
 Vab0uwogSqywRsFulsN9UBegJQzBfrn3PJ1W4DV0HyHj3zAhC57xI.JPncorf0ljFPJdEH4QtlrU
 a6ELaO7pOG_1nrW9SI_JHbAXlGFqqMKM2XcKjySNIwxqG4lhm4ChiS9yPeSzo_It_ybUKGaFdHPH
 StJKC3HwWn_bHFmwHKuRNQdIEIO06mArsIPKHsziwPsqZi2Gpse7pxal9.43lpIpaQIthiPY0y0A
 3yAQs5foqXVLYV4Lyg97I8sc8KVsFCq8MAJaOFMgIaHKYdT7nQmTvnBHyhzFK85e1Ir5lGttyNsO
 QaTPSuPahhdizCAjCdwqqtxJa13nf.k4GpqEN84XTHkp8xy7ixYP6xgQwoXVNd.IWsJ_T6OyILXw
 uZotscnGJw6em7YwpfIOTUTMJCuk9E2PZpt4iFPnMws.xmmHiMyxHHd0X.ZZvcni6Gz5vtxCyIPK
 S4m0xD54Fm2gBLggsQTHgCQAlb1R1z73hvDH_wEkZFbQEJXBmym0GS68LNrhRu1TQbnhj2ZWVzoL
 qZAVDhQu.fClrKWEGlCXjZvxroZ0RoFjbQS.uKP7_cYUw0Cp_7u0TYHLm4aQTBJYNcF9yJPJuW4L
 DlfkMhhX4sG1d3zMSu99kkAMi6hblWAVDM3NuCrQjo.kY6BHbnhrmzgPZvUMfeVXS.kOOfJvm1iz
 BTA6oE3qczr.2D0BmWK0Zfvy9jCVE2IK4jAiqlHdUBVfS3eAlDEK1DvJKVSvdp.JU9uvaGB_C5t.
 Iv4xHRJUhmiyK7FwGmyfFqb01h88Q1aZHRyFiDu6KQ.HrnijYO9GojC631l9oqIxnfSS2Yf19pLC
 4LWrbTk7XuVcGibmobplP05Uded2h8jvV8OrTxZOPkq8JzRDkxFjWgklJL7P7TCup0U7df1ORxLt
 0oL7vTdLUdcs3pW_PVVbHayKChGqJK0ir
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic315.consmr.mail.ne1.yahoo.com with HTTP; Mon, 27 Apr 2020 19:27:56 +0000
Date: Mon, 27 Apr 2020 19:27:55 +0000 (UTC)
From: tosher 1 <akm2tosher@yahoo.com>
To: Xen-devel <xen-devel@lists.xenproject.org>, 
 =?UTF-8?Q?J=C3=BCrgen_Gro=C3=9F?= <jgross@suse.com>
Message-ID: <738028694.1121290.1588015675832@mail.yahoo.com>
In-Reply-To: <a06fdec5-9e9e-2319-e7f7-d68fdb48ffba@suse.com>
References: <1359850718.562651.1587928713792.ref@mail.yahoo.com>
 <1359850718.562651.1587928713792@mail.yahoo.com>
 <a06fdec5-9e9e-2319-e7f7-d68fdb48ffba@suse.com>
Subject: Re: Xen network domain performance for 10Gb NIC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: WebService/1.1.15756 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64;
 x64; rv:75.0) Gecko/20100101 Firefox/75.0
Content-Length: 395
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The driver domain is HVM. Both the driver domain and=20






On Monday, April 27, 2020, 1:28:13 AM EDT, J=C3=BCrgen Gro=C3=9F <jgross@su=
se.com> wrote:=20




> Is the driver domain PV or HVM?

The driver domain is HVM.

> How many vcpus do dom0, the driver domain and the guest have?

Dom0 has 12 vcpus, pinned. Both the driver domain and the guest have 4 vcpu=
s, pinned as well.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 19:53:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 19:53:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT9o5-0006gW-5i; Mon, 27 Apr 2020 19:52:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=R4Dr=6L=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jT9o3-0006gR-Ub
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 19:52:43 +0000
X-Inumbo-ID: a86f153e-88c0-11ea-b9cf-bc764e2007e4
Received: from mail-wm1-f67.google.com (unknown [209.85.128.67])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a86f153e-88c0-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 19:52:43 +0000 (UTC)
Received: by mail-wm1-f67.google.com with SMTP id v8so618057wma.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 12:52:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-disposition:in-reply-to:user-agent;
 bh=CDFsWD9ltBZh+kkR8XQfWxcPeNZOq2AAsVExkrBHq80=;
 b=BYTtmxty9B+0//VJntPPCib41pEdOqlmDp+ZLS76YrT24ajIjHuyuhAoYbmpH6YMUs
 y0Z91uoNVjUW3GnsdUK6/66893JE9eeqxGem00fQYw2N894KK5sd3QF4wPFRiKcIIZez
 cuxDWGiB2wquZonNF4qUSgKt6f/cbq7SXPaIOo355FIVI+xg+wf2fKVqAyFd7KK0bF/X
 +0zB6/Dska8aYASQrOzVuWALmvYLc90cKOGTrS9pbjC4FrR+wws1FhKQ1hAv4mAr583+
 01AJ/GFQF64vwh+tn3jGlA4numQvUL3Lu1tAt5UyYnBuazgHavFksceOqNK/znZ23hb+
 QCrA==
X-Gm-Message-State: AGi0PuZxPxC74Y3tiWJBINWaS/jnX7KMQlK1/3f8R0SnEiIDrNlzeZFl
 n08cTTul0gROH7LTYgcSk0k=
X-Google-Smtp-Source: APiQypJTOJ1p1gP1T4h+rz+LT+5fETxu91u+a8Yv3SsYdY5NzCbxyajE8xZY5v4r358Ncgs22pQRUw==
X-Received: by 2002:a05:600c:1109:: with SMTP id
 b9mr347585wma.116.1588017162583; 
 Mon, 27 Apr 2020 12:52:42 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id y18sm235486wmc.45.2020.04.27.12.52.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 12:52:41 -0700 (PDT)
Date: Mon, 27 Apr 2020 19:52:40 +0000
From: Wei Liu <wl@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 2/2] x86: drop high compat r/o M2P table address range
Message-ID: <20200427195240.dskoev3u2ohzklpu@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
 <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
 <520c95ba-f9d0-4260-5426-b450c2310c3c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <520c95ba-f9d0-4260-5426-b450c2310c3c@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Hongyan Xia <hx242@xen.org>, julien@xen.org, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 15, 2020 at 10:23:58AM +0200, Jan Beulich wrote:
> Now that we don't properly hook things up into the page tables anymore
> we also don't need to set aside an address range. Drop it, using
> compat_idle_pg_table_l2[] simply (explicitly) from slot 0.
> 
> While doing the re-arrangement, which is accompanied by the dropping or
> replacing of some local variables, restrict the scopes of some further
> ones at the same time.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Wei Liu <wl@xen.org>

> ---
> TBD: With the changed usage perhaps we want to also rename
>      compat_idle_pg_table_l2[] (to e.g. compat_idle_l2_entries[])?

No opinion on this.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 19:55:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 19:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT9r0-0006of-LJ; Mon, 27 Apr 2020 19:55:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=R4Dr=6L=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jT9qz-0006oa-Tp
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 19:55:45 +0000
X-Inumbo-ID: 13e77915-88c1-11ea-97d6-12813bfff9fa
Received: from mail-wm1-f67.google.com (unknown [209.85.128.67])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 13e77915-88c1-11ea-97d6-12813bfff9fa;
 Mon, 27 Apr 2020 19:55:45 +0000 (UTC)
Received: by mail-wm1-f67.google.com with SMTP id g12so269816wmh.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 12:55:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-disposition:in-reply-to:user-agent;
 bh=S630ISA74E4eIpHiCILDqtw5ut5cEEBYYClHZyJxO0Q=;
 b=XbqeJPm32pcatwBo/PWBxg+2L6XLOZ3bhlW+oviX43whvXB8M1v3z/vHNbjpUZ5rNR
 ZqUpOUI+O6hmlhD2kFSF4TLvrUJ+xOr6TlGJKniEa3sShD3rlnnrFRz65XuI8zx/2hUV
 +/yVVMqMsHfyQx2T/cwWMVxB6XfCu/oULFMlFhsGv0Tv4ftCuRXKbrpkHDoTol714luj
 WKy88mcqzNhSjYM1LPgOl15ak9CPyoADij6GCHahUysx84jH1zlKL5HueE1yTIIyNhTg
 Fz6yUrxXUVDyTH1BVomrXBrhJCpNj/NdT6pO3tDyvin2bMVltoL3slU9lbzf0jOl8i2d
 xpQw==
X-Gm-Message-State: AGi0PuZ0cNcHPOcuIjfNUDxuPbnOWkV9f80jZQPkTUyFwA0FsKjP+1ge
 iLFKzpVBcf9Q/qh1bXtJPAg=
X-Google-Smtp-Source: APiQypITpZfvbKhA/dWTvMvMFTg7nSsqAxNzsjSqBBHtzhXdGaQvxSZZScEU9FCwwYio1L5awOaVTA==
X-Received: by 2002:a1c:ed04:: with SMTP id l4mr329007wmh.93.1588017344484;
 Mon, 27 Apr 2020 12:55:44 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id j10sm290547wmi.18.2020.04.27.12.55.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 12:55:43 -0700 (PDT)
Date: Mon, 27 Apr 2020 19:55:42 +0000
From: Wei Liu <wl@xen.org>
To: Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH 01/12] libxc/save: Shrink code volume where possible
Message-ID: <20200427195542.yiuvw4xgfjfzn6wh@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <20191224151932.6304-1-andrew.cooper3@citrix.com>
 <20191224151932.6304-2-andrew.cooper3@citrix.com>
 <24093.61657.676890.721999@mariner.uk.xensource.com>
 <a10d1572-d5c5-716a-0651-aee2345348dd@citrix.com>
 <24231.5161.862828.377795@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24231.5161.862828.377795@mariner.uk.xensource.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 06:19:37PM +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 01/12] libxc/save: Shrink code volume where possible"):
> > On 14/01/2020 16:48, Ian Jackson wrote:
> > > Andrew Cooper writes ("[PATCH 01/12] libxc/save: Shrink code volume where possible"):
> > >> A property of how the error handling (0 on success, nonzero otherwise)
> > >> allows these calls to be chained together with the ternary operatior.
> > > I'm quite surprised to find a suggestion like this coming from you in
> > > particular.
> > 
> > What probably is relevant is that ?: is a common construct in the
> > hypervisor, which I suppose does colour my expectation of people knowing
> > exactly what it means and how it behaves.
> 
> I expect other C programmers to know what ?: does, too.  But I think
> using it to implement the error monad is quite unusual.  I asked
> around a bit and my feeling is still that this isn't an improvement.
> 
> > > Or just to permit
> > >    rc = write_one_vcpu_basic(ctx, i);    if (rc) goto error;
> > > (ie on a single line).
> > 
> > OTOH, it should come as no surprise that I'd rather drop this patch
> > entirely than go with these alternatives, both of which detract from
> > code clarity. The former for hiding control flow, and the latter for
> > being atypical layout which unnecessary cognitive load to follow.
> 
> I think, then, that it would be best to drop this patch, unless Wei
> (or someone else) disagrees with me.

I don't feel strongly either way.

Wei.


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 20:00:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 20:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT9vi-0007iQ-9n; Mon, 27 Apr 2020 20:00:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jT9vh-0007iL-I3
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 20:00:37 +0000
X-Inumbo-ID: c24f8d02-88c1-11ea-b9cf-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c24f8d02-88c1-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 20:00:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588017637;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=cBAIWx1mjz1mmjuR3O7FLxWCZF8TQzeCU7IWocKU03U=;
 b=MV6L6B3rmmW5Si+OkpBkrkkbVhUTp04L26XmZ3RuzK/yVkBsw96pcgKO
 zq7sgFl0x55LMdgB189C//+UnZ+AcjE9I2MxMPijdIzhj+0SF3NTvqBSa
 CjG6ym7i2zDT77zkI+7EGqxnTacc9SjFx0G8NE8+uUL5soBDEYV0ws0Jm s=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: yLfmEku0OXbrO79fZT8ijTwuS0/jjHJeb/B4NFj/VdovsuoK5UoPCUV3iRHRjy3wHV3/mmuZa0
 xFXak9pZhs0Y9OXBAwXNgxFpwDauxmaneJIwBu3CQn7Q7o3ABQW/y/PNWE7HuGwW/gQhYaEwDg
 ywzsSg6ltgDe7X4SmYhkaQKl6eAA1h4RbDzNXvtc+HIk4lSFX81ckFIB9WEve6ISFMZtMdLKAa
 wbSvpAg+TPvPk66ioK0gArEfc1T57F+Gp+ODF49xq6MgHU+S49C1ELJiit+3jn7+F5SlVhS3Tm
 daw=
X-SBRS: 2.7
X-MesageID: 16311133
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,325,1583211600"; d="scan'208";a="16311133"
Subject: Re: [PATCH 01/12] libxc/save: Shrink code volume where possible
To: Wei Liu <wl@xen.org>, Ian Jackson <ian.jackson@citrix.com>
References: <20191224151932.6304-1-andrew.cooper3@citrix.com>
 <20191224151932.6304-2-andrew.cooper3@citrix.com>
 <24093.61657.676890.721999@mariner.uk.xensource.com>
 <a10d1572-d5c5-716a-0651-aee2345348dd@citrix.com>
 <24231.5161.862828.377795@mariner.uk.xensource.com>
 <20200427195542.yiuvw4xgfjfzn6wh@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <df22f0c7-0bca-ea42-976b-3de530cc83cf@citrix.com>
Date: Mon, 27 Apr 2020 21:00:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200427195542.yiuvw4xgfjfzn6wh@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27/04/2020 20:55, Wei Liu wrote:
> On Mon, Apr 27, 2020 at 06:19:37PM +0100, Ian Jackson wrote:
>> Andrew Cooper writes ("Re: [PATCH 01/12] libxc/save: Shrink code volume where possible"):
>>> On 14/01/2020 16:48, Ian Jackson wrote:
>>>> Andrew Cooper writes ("[PATCH 01/12] libxc/save: Shrink code volume where possible"):
>>>>> A property of how the error handling (0 on success, nonzero otherwise)
>>>>> allows these calls to be chained together with the ternary operatior.
>>>> I'm quite surprised to find a suggestion like this coming from you in
>>>> particular.
>>> What probably is relevant is that ?: is a common construct in the
>>> hypervisor, which I suppose does colour my expectation of people knowing
>>> exactly what it means and how it behaves.
>> I expect other C programmers to know what ?: does, too.  But I think
>> using it to implement the error monad is quite unusual.  I asked
>> around a bit and my feeling is still that this isn't an improvement.
>>
>>>> Or just to permit
>>>>    rc = write_one_vcpu_basic(ctx, i);    if (rc) goto error;
>>>> (ie on a single line).
>>> OTOH, it should come as no surprise that I'd rather drop this patch
>>> entirely than go with these alternatives, both of which detract from
>>> code clarity. The former for hiding control flow, and the latter for
>>> being atypical layout which unnecessary cognitive load to follow.
>> I think, then, that it would be best to drop this patch, unless Wei
>> (or someone else) disagrees with me.
> I don't feel strongly either way.

I'm confused... I dropped this 3 and a half months ago, because it was
blindingly obvious it was going nowhere.

This is the v1 series which was totally superseded by the v2 series also
posted in January.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 20:02:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 20:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jT9xm-0007ut-PD; Mon, 27 Apr 2020 20:02:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jT9xl-0007uo-Mr
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 20:02:45 +0000
X-Inumbo-ID: 0f036b6e-88c2-11ea-97d6-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0f036b6e-88c2-11ea-97d6-12813bfff9fa;
 Mon, 27 Apr 2020 20:02:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588017765;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=H2x1itjd5jI6EgS/a4zpFdSG4k055RmadBs+oKN7xxQ=;
 b=MtXbsP46PZ3iyDgjgp/ZjDZLYwc5p+oUbSY2QuzgN+yU0cyX/Tvhf+i4
 ELmNbhR184uAXoJDpXC2Ni8zP/FS2DQtG8eKjd1lm1OPPz1DR+KVTT1FH
 KInqXywlp4w1XuOZtMxyK8mBOR9sm2K6Dll4VHr2oK+pTzYrUWehfsk8t U=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: W7zyM92+KRmsfq+2fn/u8KfCVJow7RaxopA33TYtohG2wZTo6GXnp8Nv8D5TPrz2MII1BnPdOW
 50hgHHurnu7BABX2bgt1ZRamy/EQLnUPz/O2CaOwRNSDlqPlXXln5gyP+yuAI2dBmBion6Md+r
 uMOsJHXSRra+8SlJpwOFFguH1jeysR4u+mA+Mtt+o+1HDUOtMKilaXcYy6m1Nc6bqq9KnRvBc5
 oG669OxWGTn7cvPA4+SbRakDvyPAlWaDg3ZNzDuq0chDyg7/fdyiaTR/AlkeXf0vUyMlW6I4HE
 4vE=
X-SBRS: 2.7
X-MesageID: 16311260
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,325,1583211600"; d="scan'208";a="16311260"
Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit
 PV support
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>, Jan Beulich
 <jbeulich@suse.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-2-andrew.cooper3@citrix.com>
 <5dc9dbd9-fbeb-46ef-4d4e-7916c3219bb3@suse.com>
 <4e732f90-1d5f-7ae5-0f02-6b313a381df7@citrix.com>
 <6b4e5b50-51f7-566f-2a18-4bb5f4f43d59@suse.com>
 <62b51cff-4d6f-690b-371a-e6772ea327ab@citrix.com>
 <68146423-c2cb-0bf4-4bb8-3c89ad17bbcc@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <5e488903-2916-773d-402e-5aedab4e0af0@citrix.com>
Date: Mon, 27 Apr 2020 21:02:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <68146423-c2cb-0bf4-4bb8-3c89ad17bbcc@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24/04/2020 06:28, Jürgen Groß wrote:
> On 23.04.20 19:35, Andrew Cooper wrote:
>> On 21/04/2020 07:02, Jan Beulich wrote:
>>> On 20.04.2020 20:05, Andrew Cooper wrote:
>>>> On 20/04/2020 15:05, Jan Beulich wrote:
>>>>> I'm in particular
>>>>> concerned that we may gain a large number of such printk()s over
>>>>> time, if we added them in such cases.
>>>> The printk() was a bit of an afterthought, but deliberately
>>>> avoiding the
>>>> -EINVAL path was specifically not.
>>>>
>>>> In the case that the user tries to use `pv=no-32` without CONFIG_PV32,
>>>> they should see something other than
>>>>
>>>> (XEN) parameter "pv=no-32" unknown!
>>> Why - to this specific build of Xen the parameter is unknown.
>>
>> Because it is unnecessarily problematic and borderline obnoxious to
>> users, as well as occasional Xen developers.
>>
>> "you've not got the correct CONFIG_$X for that to be meaningful" is
>> specifically useful to separate from "I've got no idea".
>>
>>>> I don't think overloading the return value is a clever move, because
>>>> then every parse function has to take care of ensuring that
>>>> -EOPNOTSUPP
>>>> (or ENODEV?) never clobbers -EINVAL.
>>> I didn't suggest overloading the return value. Instead I
>>> specifically want this to go the -EINVAL path.
>>>
>>>> We could have a generic helper which looks like:
>>>>
>>>> static inline void ignored_param(const char *cfg, const char *name,
>>>> const char *s, const char *ss)
>>>> {
>>>>      printk(XENLOG_INFO "%s disabled - ignoring '%s=%*.s' setting\n",
>>>> cfg, name, s, (int)(ss - s));
>>>> }
>>>>
>>>> which at least would keep all the users consistent.
>>> Further bloating the binary with (almost) useless string literals.
>>> I'd specifically like to avoid this.
>>
>> I don't accept that as a valid argument.
>>
>> We're talking about literally tens of bytes (which will merge anyway, so
>> 0 in practice), and a resulting UI which helps people get out of
>> problems rather than penalises them for having gotten into a problem to
>> begin with.
>>
>> I will absolutely prioritise a more helpful UI over a handful of bytes.
>
> What about a kconfig option (defaulting to "yes") enabling this feature?

IMO, that's literally not worth the bytes taken to implement.

> That way an embedded variant can be made smaller while a server one is
> more user friendly.

There is far lower hanging fruit for an embedded usecase, and its not at
all a foregone conclusion that such a usecase would want the less user
friendly version.  (Embedded very definitely doesn't mean that it won't
have users interacting with the command line).

I would certainly recommend against attempting to speculatively fix
something which isn't a problem, based on guesswork about what a
hypothetical group of people might want while totally ignoring the far
larger savings to be gained by e.g. making CONFIG_INTEL/AMD work.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 20:11:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 20:11:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTA5t-0000T7-Mx; Mon, 27 Apr 2020 20:11:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTA5r-0000NF-Gp
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 20:11:07 +0000
X-Inumbo-ID: 3a104952-88c3-11ea-b9cf-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3a104952-88c3-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 20:11:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588018266;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=zJF13uOfPS1k7La0Qt5UBmdfkp78c8eikm7xlXJNmjU=;
 b=WqpGT0xre9kkIZUFXuXqn+wEVg5I3hDhQzPLfXsYTJOXHkwuOVylIlGT
 ha6vg6jAyPPHwaM6y1ImqmINM8o9iBfYUoSwJP4WArt0NneJpdBix/qbs
 XnG9+NeKr8OQtPYImBmi7qrhc0Rfs0slDM5Wp6U6Z1bxdt9xBck4eZ7wr o=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: xurQuLw/TGb+EyvRba8dDpZ/Pb9+oDghvQ234hokG3xO+xRRNMuZ3vCQcfRXTQfiFeb8qERzFt
 mEdr+Arln/7MllOHJgTmYt8igkcZCmmuD/fnwI9fn6C8StQR9TqIzDBLafiAxc1Jvc3WivGnHH
 LvM2mJlzvP1VSwZ8qmnxkTfBGL4nJ7ltnPJVV5EQmgNJ4aU252mjW9KN7cQDUwQthAkdcJwUSh
 EgHjdTPdq/2evbAS9SdwIYjW5VAvJF6FwlQFEiu4NfQ9D+vnwiJK/k9yk9nFlguLU3qIFKxdB1
 X9Q=
X-SBRS: 2.7
X-MesageID: 16642720
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,325,1583211600"; d="scan'208";a="16642720"
Subject: Re: [PATCH] x86: refine guest_mode()
To: Jan Beulich <jbeulich@suse.com>
References: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
 <1704f4f6-7e77-971c-2c94-4f6a6719c34a@citrix.com>
 <5bbe6425-396c-d934-b5af-53b594a4afbc@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <16939982-3ccc-f848-0694-61b154dca89a@citrix.com>
Date: Mon, 27 Apr 2020 21:11:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5bbe6425-396c-d934-b5af-53b594a4afbc@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27/04/2020 16:15, Jan Beulich wrote:
> On 27.04.2020 16:35, Andrew Cooper wrote:
>> On 27/04/2020 09:03, Jan Beulich wrote:
>>> The 2nd of the assertions as well as the macro's return value have been
>>> assuming we're on the primary stack. While for most IST exceptions we
>>> eventually switch back to the main one,
>> "we switch to the main one when interrupting user mode".
>>
>> "eventually" isn't accurate as it is before we enter C.
> Right, will change.
>
>>> --- a/xen/include/asm-x86/regs.h
>>> +++ b/xen/include/asm-x86/regs.h
>>> @@ -10,9 +10,10 @@
>>>      /* Frame pointer must point into current CPU stack. */                    \
>>>      ASSERT(diff < STACK_SIZE);                                                \
>>>      /* If not a guest frame, it must be a hypervisor frame. */                \
>>> -    ASSERT((diff == 0) || (r->cs == __HYPERVISOR_CS));                        \
>>> +    if ( diff < PRIMARY_STACK_SIZE )                                          \
>>> +        ASSERT(!diff || ((r)->cs == __HYPERVISOR_CS));                        \
>>>      /* Return TRUE if it's a guest frame. */                                  \
>>> -    (diff == 0);                                                              \
>>> +    !diff || ((r)->cs != __HYPERVISOR_CS);                                    \
>> The (diff == 0) already worried me before because it doesn't fail safe,
>> but this makes things more problematic.  Consider the case back when we
>> had __HYPERVISOR_CS32.
> Yes - if __HYPERVISOR_CS32 would ever have been to be used for
> anything, it would have needed checking for here.
>
>> Guest mode is strictly "(r)->cs & 3".
> As long as CS (a) gets properly saved (it's a "manual" step for
> SYSCALL/SYSRET as well as #VMEXIT) and (b) didn't get clobbered. I
> didn't write this code, I don't think, so I can only guess that
> there were intentions behind this along these lines.

Hmm - the VMExit case might be problematic here, due to the variability
in the poison used.

>
>> Everything else is expectations about how things ought to be laid out,
>> but for safety in release builds, the final judgement should not depend
>> on the expectations evaluating true.
> Well, I can switch to a purely CS.RPL based approach, as long as
> we're happy to live with the possible downside mentioned above.
> Of course this would then end up being a more intrusive change
> than originally intended ...

I'd certainly prefer to go for something which is more robust, even if
it is a larger change.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 22:20:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 22:20:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTC6z-0003nB-Fl; Mon, 27 Apr 2020 22:20:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=niBk=6L=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTC6y-0003n6-My
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 22:20:24 +0000
X-Inumbo-ID: 494374f0-88d5-11ea-b9cf-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 494374f0-88d5-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 22:20:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588026024;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=3sraytr6HrfoRHDcADWH34H1LOvDJDFtM1bTiIrvDVo=;
 b=JcndWCZRfCws8eD+Rp1vd5U/W4CnBYposM5kO0eKAEffApSLPf7ash+Y
 ckHzwYgkjfZVFgR7MeMREQIsCHnpkT3enWKcAlGpmsE6OMwNm0EEVyzV0
 LoiJweNPB4zDaM3HfeQOG/IGP0DAp5pvbNy/MunWEO7JJ0O3hsbbGbl8I A=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Bu2StfbPck1E+pVw/UOyPFrjx2PoKDBaIRezDdvmIwEmU8y01JyJ50JJjk/kexf3rXfQozMJDm
 OW4v3EFfhbsBC9qDGsxprm44xCJCn2dQCjgK2taUqHJ9yxsqdu9lfOjxyuJSp6umINKdsmN+K5
 9zAnBFZX6A9GUzJ0EICa7C6AFlV5G2OXdPGWys383QRAK8B6ZLXMPVHGItOLPbJICiN+/GfVRN
 EIHHXYs+znl4ziPO/YBKukzsLjmeRvKmbmDkJirt34fgAhVFNnYUfjElKXOTVOqVEetOWABnq1
 1ZE=
X-SBRS: 2.7
X-MesageID: 16317181
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,325,1583211600"; d="scan'208";a="16317181"
Subject: Re: [PATCH] x86/ioemul: Rewrite stub generation
To: Jan Beulich <jbeulich@suse.com>
References: <20200427122041.7162-1-andrew.cooper3@citrix.com>
 <ca3374ed-6e00-7ab2-8255-f74c16b5ad3d@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <ec073c8d-61a2-79ef-1ffe-d34e26a5319d@citrix.com>
Date: Mon, 27 Apr 2020 23:20:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <ca3374ed-6e00-7ab2-8255-f74c16b5ad3d@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27/04/2020 16:28, Jan Beulich wrote:
> On 27.04.2020 14:20, Andrew Cooper wrote:
>> The logic is completely undocumented and almost impossible to follow.  It
>> actually uses return oriented programming.  Rewrite it to conform to more
>> normal call mechanics, and leave a big comment explaining thing.  As well as
>> the code being easier to follow, it will execute faster as it isn't fighting
>> the branch predictor.
>>
>> Move the ioemul_handle_quirk() function pointer from traps.c to
>> ioport_emulate.c.  There is no reason for it to be in neither of the two
>> translation units which use it.  Alter the behaviour to return the number of
>> bytes written into the stub.
>>
>> Access the addresses of the host/guest helpers with extern const char arrays.
>> Nothing good will come of C thinking they are regular functions.
> I agree with the C aspect, but imo the assembly routines should,
> with the changes you make, be marked as being ordinary functions.

Despite the changes, they are still very much not ordinary functions,
and cannot be used by C.

I have no objection to marking them as STT_FUNCTION (as this doesn't
mean C function), but...

> A reasonable linker would then warn about the C file wanting an
> STT_OBJECT while the assembly file provides an STT_FUNC. I'd
> therefore prefer, along with marking the functions as such, to
> have them also declared as functions in C.

... there is literally nothing safe which C can do with them other than
manipulate their address.

Writing it like this is specifically prevents something from compiling
which will explode at runtime, is someone is naive enough to try using
the function from C.

>> --- a/xen/arch/x86/ioport_emulate.c
>> +++ b/xen/arch/x86/ioport_emulate.c
>> @@ -8,7 +8,10 @@
>>  #include <xen/sched.h>
>>  #include <xen/dmi.h>
>>  
>> -static bool ioemul_handle_proliant_quirk(
>> +unsigned int (*ioemul_handle_quirk)(
>> +    u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs);
> Would you mind adding __read_mostly on this occasion?
>
>> @@ -19,18 +22,16 @@ static bool ioemul_handle_proliant_quirk(
>>          0xa8, 0x80, /*    test $0x80, %al */
>>          0x75, 0xfb, /*    jnz 1b          */
>>          0x9d,       /*    popf            */
>> -        0xc3,       /*    ret             */
>>      };
>>      uint16_t port = regs->dx;
>>      uint8_t value = regs->al;
>>  
>>      if ( (opcode != 0xee) || (port != 0xcd4) || !(value & 0x80) )
>> -        return false;
>> +        return 0;
>>  
>>      memcpy(io_emul_stub, stub, sizeof(stub));
>> -    BUILD_BUG_ON(IOEMUL_QUIRK_STUB_BYTES < sizeof(stub));
> So you treat a build failure for a runtime crash.

I presume you mean s/treat/trade/ here, and the answer is no, not really.

There is nothing which actually forced a connection between the build
time checks and runtime behaviour, so it was only a facade of safety,
not real safety.

>  I can see the
> advantages of the new approach, but the original got away with
> less stub space.

Stub space doesn't matter, so long as it fits.  In particular, ...

> If our L1_CACHE_SHIFT wasn't hard coded to 7
> just to cover some unusual CPUs, your new approach would, if I
> got the counting and calculations right, not work (with a value
> resulting in a 64-byte cache line size).

... the SYSCALL stubs use 64 bytes so Xen cannot function with a shift
less than 7.

> Introducing a Kconfig
> option for this should imo not come with a need to re-work the
> logic here again. Therefore I'd like us to think about a way
> to make the space needed not exceed 32 bytes.

And why would we ever want an option like that?  (I know how you're
going to answer this, so I'm going to pre-emptively point out that there
are hundreds of kilobytes of easier-to-shrink per-cpu data structures
than this one).

Honestly, this suggestion is a total waste of time and effort.  It is an
enormous amount of complexity to micro-optimise a problem which doesn't
exist in the first place.

The stubs are already 128 bytes per CPU and cannot be made smaller. 
Attempting to turn this particular stub into <32 has no benefit (the
stubs don't actually get smaller), and major costs.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 23:11:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 23:11:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTCtq-0008QW-BZ; Mon, 27 Apr 2020 23:10:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6V0E=6L=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTCtp-0008QR-7q
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 23:10:53 +0000
X-Inumbo-ID: 5636921c-88dc-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5636921c-88dc-11ea-b9cf-bc764e2007e4;
 Mon, 27 Apr 2020 23:10:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=iIdr/Au9MJ5KfuNHiXTzAIPoInNajhOmWp10I6lUj5s=; b=1+XeZJWHCwl+nAQ7bah+V1reE
 1YvyMeMlnnQE5IwST2zIVuFgm5FdikueygDh1Eh/tiD5+6eio2b9OLKG8PAWjlc9g5fS+mRZNhVHW
 GmbDQZ2H1QWznIuOCT648ZIj9L9SYt7fUueC7q2Iwq4E0i1lFg7x5YjP5kbV+iVrtk05w=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTCtm-0003ez-MN; Mon, 27 Apr 2020 23:10:50 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTCtm-0003g6-AQ; Mon, 27 Apr 2020 23:10:50 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTCtm-00047K-9f; Mon, 27 Apr 2020 23:10:50 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149835-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149835: regressions - FAIL
X-Osstest-Failures: xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:regression
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=8d4c17a90b0a9b3d82628461090a54a2c7897154
X-Osstest-Versions-That: xen=f093b08c47b39da6019421a2b61d40745b3e573b
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 27 Apr 2020 23:10:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149835 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149835/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine      4 memdisk-try-append       fail REGR. vs. 149831

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149831
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149831
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149831
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149831
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149831
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149831
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149831
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149831
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149831
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149831
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  8d4c17a90b0a9b3d82628461090a54a2c7897154
baseline version:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b

Last test of basis   149831  2020-04-27 01:52:33 Z    0 days
Testing same since   149835  2020-04-27 12:07:17 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Stefano Stabellini <sstabellini@kernel.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8d4c17a90b0a9b3d82628461090a54a2c7897154
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Mon Apr 27 09:31:13 2020 +0200

    xen/build: silence make warnings about missing auto.conf*
    
    In a clean tree, both files include/config/auto.conf{,.cmd} are
    missing and older version of GNU Make complain about it:
        Makefile:103: include/config/auto.conf: No such file or directory
        Makefile:106: include/config/auto.conf.cmd: No such file or directory
    
    Those warnings are harmless, make will create the files and start over. But
    to avoid confusion, we'll use "-include" to silence the warning.
    
    Those warning started to appear with commit 6c122d3984a5 ("xen/build:
    include include/config/auto.conf in main Makefile").
    
    Reported-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>

commit d0ee8e9ca4d4163e42dcd5f1cf13e4fae30a4190
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Apr 27 09:30:16 2020 +0200

    guestcopy: evaluate {,__}copy{,_field}_to_guest*() ptr argument just once
    
    There's nothing wrong with having e.g.
    
        copy_to_guest(uarg, ptr++, 1);
    
    yet until now this would increment "ptr" twice.
    
    Also drop a pair of unneeded parentheses from every instance at this
    occasion.
    
    Fixes: b7954cc59831 ("Enhance guest memory accessor macros so that source operands can be")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>

commit 4bdf6b5a7fec876e9bbd70ebe605828ad0fb12a4
Author: Julien Grall <jgrall@amazon.com>
Date:   Mon Apr 27 09:28:21 2020 +0200

    guest_access: harden *copy_to_guest_offset() to prevent const dest operand
    
    At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
    data to guest handle marked const.
    
    Thankfully, no users of the helper will do that. Rather than hoping this
    can be caught during review, harden copy_to_guest_offset() so the build
    will fail if such users are introduced.
    
    There is no easy way to check whether a const is NULL in C99. The
    approach used is to introduce an unused variable that is non-const and
    assign the handle. If the handle were const, this would fail at build
    because without an explicit cast, it is not possible to assign a const
    variable to a non-const variable.
    
    Suggested-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 23:14:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 23:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTCxZ-0000Gd-1f; Mon, 27 Apr 2020 23:14:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6V0E=6L=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTCxY-0000GY-2U
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 23:14:44 +0000
X-Inumbo-ID: df901f2e-88dc-11ea-97e8-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id df901f2e-88dc-11ea-97e8-12813bfff9fa;
 Mon, 27 Apr 2020 23:14:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=zKHrERwvV5fx7z1Yq/+zcUoUvlbpF1FzHG5UaIwayMA=; b=0TtWyClgBEeJV4Ve9Hb66M+X/
 Iq8WK+0zpNquxR6TgYdKe97my6KhvAzwKA08ZkMvx/cktJf5dTVVacNN31F95CzOLaena3Am+w7GU
 P5tzv/7531uUrWbE4VucNZFVWK1yZ/nEQ+Sl9UlmhOSBYJ5+HpL+NkVXV6fJb2lJVtnac=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTCxV-0003kT-6B; Mon, 27 Apr 2020 23:14:41 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTCxU-0003vj-UE; Mon, 27 Apr 2020 23:14:40 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTCxU-0005sP-TZ; Mon, 27 Apr 2020 23:14:40 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149836-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.13-testing test] 149836: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.13-testing:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.13-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=35b80b2a011416383466f21e32cb72cf73df491b
X-Osstest-Versions-That: xen=b66ce5058ec9ce84418cedd39b2bf07b7c5a1f65
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 27 Apr 2020 23:14:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149836 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149836/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149664
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat    fail  like 149664
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass

version targeted for testing:
 xen                  35b80b2a011416383466f21e32cb72cf73df491b
baseline version:
 xen                  b66ce5058ec9ce84418cedd39b2bf07b7c5a1f65

Last test of basis   149664  2020-04-14 23:36:10 Z   12 days
Testing same since   149836  2020-04-27 13:36:20 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Dario Faggioli <dfaggioli@suse.com>
  Harsha Shamsundara Havanur <havanur@amazon.com>
  Jan Beulich <jbeulich@suse.com>
  Jeff Kubascik <jeff.kubascik@dornerworks.com>
  Julien Grall <jgrall@amazon.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Sergey Dyasli <sergey.dyasli@citrix.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   b66ce5058e..35b80b2a01  35b80b2a011416383466f21e32cb72cf73df491b -> stable-4.13


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 23:20:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 23:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTD2t-00015M-Nc; Mon, 27 Apr 2020 23:20:15 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HlLs=6L=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTD2r-00015H-RM
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 23:20:13 +0000
X-Inumbo-ID: a5277d72-88dd-11ea-97e8-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a5277d72-88dd-11ea-97e8-12813bfff9fa;
 Mon, 27 Apr 2020 23:20:13 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id C031E2075E;
 Mon, 27 Apr 2020 23:20:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588029612;
 bh=2FzNr9AYi2Z56St5oDtdr82wY2gpMQyGUJOeexzVjIE=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=BgZp0SkDI7vO4118g7F0iAARmoGbMGqpVKsNzNqOz6+xieZb2qUIJKRFbwnxLEV3W
 2RxPGBgyEotbGst2iOX00wmj96IV8D5nZmm8sowEA900EIAbG1xB+Y6q6NQ1JS5KNI
 rw/mSAzLb//x9I4m2NqgdEVbMttCC95rtDHOcIN8=
Date: Mon, 27 Apr 2020 16:20:11 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: jgross@suse.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] xen/evtchn and forced threaded irq
In-Reply-To: <CAF3u54Ct7nBjoLw9Vzb=aZVu=N5Ccp5_k6GxLo_ZSA=YCsco6A@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2004271552430.29217@sstabellini-ThinkPad-T480s>
References: <5e256d9a-572c-e01e-7706-407f99245b00@arm.com>
 <20190220000209.GA4091@localhost.localdomain>
 <a872d480-9f1b-6cd7-e507-ac4fcdf705af@arm.com>
 <21214d47-9c68-e6bf-007a-4047cc2b02f9@oracle.com>
 <8f7445d7-fa50-f3e9-44f5-cc2aebd020f4@arm.com>
 <15bc52cb-82d8-4d2c-e5a8-c6ae8de90276@oracle.com>
 <5df8888a-4a29-fccd-bac2-a9c170244029@arm.com>
 <1574a7fe-a5ac-4bc2-d3f0-967d8d01e5f1@oracle.com>
 <1100e6b1-6fa8-06f0-8ecc-b0699a2ce5f4@arm.com>
 <20190221080752.zy2qlzb4vi7tbu3p@Air-de-Roger>
 <CAF3u54Ct7nBjoLw9Vzb=aZVu=N5Ccp5_k6GxLo_ZSA=YCsco6A@mail.gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1847598456-1588028657=:29217"
Content-ID: <alpine.DEB.2.21.2004271607590.29217@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 julien.grall@gmail.com, Julien Grall <julien.grall@arm.com>,
 Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>,
 Dave P Martin <dave.martin@arm.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1847598456-1588028657=:29217
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.21.2004271607591.29217@sstabellini-ThinkPad-T480s>

On Thu, 21 Feb 2019, Julien Grall wrote:
> Hi Roger,
> 
> On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, <roger.pau@citrix.com> wrote:
>       FWIW, you can also mask the interrupt while waiting for the thread to
>       execute the interrupt handler. Ie:
> 
> 
> Thank you for providing steps, however where would the masking be done? By the irqchip or a custom solution?
> 
> 
>       1. Interrupt injected
>       2. Execute guest event channel callback
>       3. Scan for pending interrupts
>       4. Mask interrupt
>       5. Clear pending field
>       6. Queue threaded handler
>       7. Go to 3 until all interrupts are drained
>       [...]
>       8. Execute interrupt handler in thread
>       9. Unmask interrupt
> 
>       That should prevent you from stacking interrupts?

Sorry for coming late to the thread, and thanks Julien for pointing it
out to me. I am afraid I was the one to break the flow back in 2011 with
the following commit:

  7e186bdd0098 xen: do not clear and mask evtchns in __xen_evtchn_do_upcall

Oops :-)


Xen event channels have their own workflow; the one Roger wrote above.
They used to be handled using handle_fasteoi_irq until 7e186bdd0098,
then I switched (almost) all of them to handle_edge_irq.

Looking closely at irq handling again, it doesn't look like we can do
what we need with handle_edge_irq today: we can't mask the event channel
before clearing it. But we can do that if we go back to using
handle_fasteoi_irq.

In fact, I managed to verify that LinuxRT works fine as dom0 with the
attached dynamic.patch that switches back xen_dynamic_chip IRQs to
handle_fasteoi_irq.


>From the rest of this thread, it looks like the issue might appear with
PIRQs as well. Thus, I wrote a second patch pirqs.patch to switch back
to handle_fasteoi_irq PIRQs as well. However, Xen on ARM does not use
PIRQs so I couldn't test it at all. I would appreciate if Boris/Juegen
tested it. Let me know what you want me to do with the second patch.
--8323329-1847598456-1588028657=:29217
Content-Type: text/x-diff; name=dynamic.patch
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.21.2004271620110.29217@sstabellini-ThinkPad-T480s>
Content-Description: 
Content-Disposition: attachment; filename=dynamic.patch

RnJvbSBjZTI2YzM3MWE4ZmY3YjQ5Yzk4YTNiOGM3YjU3MTk5MTU0Y2JjYTU5
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogU3RlZmFubyBTdGFi
ZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0KRGF0ZTogTW9uLCAy
NyBBcHIgMjAyMCAxNjoxNToyNiAtMDcwMA0KU3ViamVjdDogW1BBVENIXSB4
ZW46IHVzZSBoYW5kbGVfZmFzdGVvaV9pcnEgdG8gaGFuZGxlIHhlbiBldmVu
dHMNCg0KV2hlbiBoYW5kbGluZyBYZW4gZXZlbnRzLCB3ZSBuZWVkIHRvIG1h
a2Ugc3VyZSB0aGUgZm9sbG93aW5nIHNlcXVlbmNlIGlzDQpmb2xsb3dlZDoN
Cg0KLSBtYXNrIGV2ZW50DQotIGhhbmRsZSBldmVudCBhbmQgY2xlYXIgZXZl
bnQgKHRoZSBvcmRlciBkb2VzIG5vdCBtYXR0ZXIpDQotIHVubWFzayBldmVu
dA0KDQpJdCBpcyBub3QgcG9zc2libGUgdG8gaW1wbGVtZW50IHRoaXMgZmxv
dyB3aXRoIGhhbmRsZV9lZGdlX2lycSwgc28NCnN3aXRjaCBiYWNrIHRvIGhh
bmRsZV9mYXN0ZW9pX2lycS4gUGxlYXNlIG5vdGUgdGhhdCBYZW4gZXZlbnQg
aXJxcyBhcmUNCk9ORVNIT1QuIEFsc28gbm90ZSB0aGF0IGhhbmRsZV9mYXN0
ZW9pX2lycSB3YXMgaW4tdXNlIGJlZm9yZSB0aGUNCmZvbGxvd2luZyBjb21t
aXQsIHRoYXQgaXMgcGFydGlhbGx5IHJldmVydGVkIGJ5IHRoaXMgcGF0Y2g6
DQoNCjdlMTg2YmRkMDA5OCB4ZW46IGRvIG5vdCBjbGVhciBhbmQgbWFzayBl
dnRjaG5zIGluIF9feGVuX2V2dGNobl9kb191cGNhbGwNCg0KUElSUSBoYW5k
bGluZyBpcyBsZWZ0IHVuY2hhbmdlZC4NCg0KVGhpcyBwYXRjaCBmaXhlcyBh
IGRvbVUgaGFuZyBvYnNlcnZlZCB3aGVuIHVzaW5nIExpbnV4UlQgYXMgZG9t
MCBrZXJuZWwuDQoNCkxpbms6IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2xr
bWwvNWUyNTZkOWEtNTcyYy1lMDFlLTc3MDYtNDA3Zjk5MjQ1YjAwQGFybS5j
b20vDQpTaWduZWQtb2ZmLWJ5OiBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZh
bm8uc3RhYmVsbGluaUB4aWxpbnguY29tPg0KLS0tDQogZHJpdmVycy94ZW4v
ZXZlbnRzL2V2ZW50c19iYXNlLmMgfCAxMyArKystLS0tLS0tLS0tDQogMSBm
aWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKSwgMTAgZGVsZXRpb25zKC0p
DQoNCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9ldmVudHMvZXZlbnRzX2Jh
c2UuYyBiL2RyaXZlcnMveGVuL2V2ZW50cy9ldmVudHNfYmFzZS5jDQppbmRl
eCA0OTllZmY3ZDNmNjUuLjVmOWI4MTA0ZGJjZiAxMDA2NDQNCi0tLSBhL2Ry
aXZlcnMveGVuL2V2ZW50cy9ldmVudHNfYmFzZS5jDQorKysgYi9kcml2ZXJz
L3hlbi9ldmVudHMvZXZlbnRzX2Jhc2UuYw0KQEAgLTg0NSw3ICs4NDUsNyBA
QCBpbnQgYmluZF9ldnRjaG5fdG9faXJxKHVuc2lnbmVkIGludCBldnRjaG4p
DQogCQkJZ290byBvdXQ7DQogDQogCQlpcnFfc2V0X2NoaXBfYW5kX2hhbmRs
ZXJfbmFtZShpcnEsICZ4ZW5fZHluYW1pY19jaGlwLA0KLQkJCQkJICAgICAg
aGFuZGxlX2VkZ2VfaXJxLCAiZXZlbnQiKTsNCisJCQkJCSAgICAgIGhhbmRs
ZV9mYXN0ZW9pX2lycSwgImV2ZW50Iik7DQogDQogCQlyZXQgPSB4ZW5faXJx
X2luZm9fZXZ0Y2huX3NldHVwKGlycSwgZXZ0Y2huKTsNCiAJCWlmIChyZXQg
PCAwKSB7DQpAQCAtOTc4LDcgKzk3OCw3IEBAIGludCBiaW5kX3ZpcnFfdG9f
aXJxKHVuc2lnbmVkIGludCB2aXJxLCB1bnNpZ25lZCBpbnQgY3B1LCBib29s
IHBlcmNwdSkNCiAJCQkJCQkgICAgICBoYW5kbGVfcGVyY3B1X2lycSwgInZp
cnEiKTsNCiAJCWVsc2UNCiAJCQlpcnFfc2V0X2NoaXBfYW5kX2hhbmRsZXJf
bmFtZShpcnEsICZ4ZW5fZHluYW1pY19jaGlwLA0KLQkJCQkJCSAgICAgIGhh
bmRsZV9lZGdlX2lycSwgInZpcnEiKTsNCisJCQkJCQkgICAgICBoYW5kbGVf
ZmFzdGVvaV9pcnEsICJ2aXJxIik7DQogDQogCQliaW5kX3ZpcnEudmlycSA9
IHZpcnE7DQogCQliaW5kX3ZpcnEudmNwdSA9IHhlbl92Y3B1X25yKGNwdSk7
DQpAQCAtMTM3NywxMiArMTM3Nyw2IEBAIHN0YXRpYyB2b2lkIGFja19keW5p
cnEoc3RydWN0IGlycV9kYXRhICpkYXRhKQ0KIAkJY2xlYXJfZXZ0Y2huKGV2
dGNobik7DQogfQ0KIA0KLXN0YXRpYyB2b2lkIG1hc2tfYWNrX2R5bmlycShz
dHJ1Y3QgaXJxX2RhdGEgKmRhdGEpDQotew0KLQlkaXNhYmxlX2R5bmlycShk
YXRhKTsNCi0JYWNrX2R5bmlycShkYXRhKTsNCi19DQotDQogc3RhdGljIGlu
dCByZXRyaWdnZXJfZHluaXJxKHN0cnVjdCBpcnFfZGF0YSAqZGF0YSkNCiB7
DQogCXVuc2lnbmVkIGludCBldnRjaG4gPSBldnRjaG5fZnJvbV9pcnEoZGF0
YS0+aXJxKTsNCkBAIC0xNTg1LDggKzE1NzksNyBAQCBzdGF0aWMgc3RydWN0
IGlycV9jaGlwIHhlbl9keW5hbWljX2NoaXAgX19yZWFkX21vc3RseSA9IHsN
CiAJLmlycV9tYXNrCQk9IGRpc2FibGVfZHluaXJxLA0KIAkuaXJxX3VubWFz
awkJPSBlbmFibGVfZHluaXJxLA0KIA0KLQkuaXJxX2FjawkJPSBhY2tfZHlu
aXJxLA0KLQkuaXJxX21hc2tfYWNrCQk9IG1hc2tfYWNrX2R5bmlycSwNCisJ
LmlycV9lb2kJCT0gYWNrX2R5bmlycSwNCiANCiAJLmlycV9zZXRfYWZmaW5p
dHkJPSBzZXRfYWZmaW5pdHlfaXJxLA0KIAkuaXJxX3JldHJpZ2dlcgkJPSBy
ZXRyaWdnZXJfZHluaXJxLA0KLS0gDQoyLjE3LjENCg0K

--8323329-1847598456-1588028657=:29217
Content-Type: text/x-diff; name=pirqs.patch
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.21.2004271620111.29217@sstabellini-ThinkPad-T480s>
Content-Description: 
Content-Disposition: attachment; filename=pirqs.patch

ZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL2V2ZW50cy9ldmVudHNfYmFzZS5j
IGIvZHJpdmVycy94ZW4vZXZlbnRzL2V2ZW50c19iYXNlLmMNCmluZGV4IDVm
OWI4MTA0ZGJjZi4uNTdhMjljOTRmZWZjIDEwMDY0NA0KLS0tIGEvZHJpdmVy
cy94ZW4vZXZlbnRzL2V2ZW50c19iYXNlLmMNCisrKyBiL2RyaXZlcnMveGVu
L2V2ZW50cy9ldmVudHNfYmFzZS5jDQpAQCAtNDk4LDEyICs0OTgsNiBAQCBz
dGF0aWMgdm9pZCBlb2lfcGlycShzdHJ1Y3QgaXJxX2RhdGEgKmRhdGEpDQog
CX0NCiB9DQogDQotc3RhdGljIHZvaWQgbWFza19hY2tfcGlycShzdHJ1Y3Qg
aXJxX2RhdGEgKmRhdGEpDQotew0KLQlkaXNhYmxlX2R5bmlycShkYXRhKTsN
Ci0JZW9pX3BpcnEoZGF0YSk7DQotfQ0KLQ0KIHN0YXRpYyB1bnNpZ25lZCBp
bnQgX19zdGFydHVwX3BpcnEodW5zaWduZWQgaW50IGlycSkNCiB7DQogCXN0
cnVjdCBldnRjaG5fYmluZF9waXJxIGJpbmRfcGlycTsNCkBAIC02ODQsMTMg
KzY3OCw5IEBAIGludCB4ZW5fYmluZF9waXJxX2dzaV90b19pcnEodW5zaWdu
ZWQgZ3NpLA0KIAl9DQogDQogCXBpcnFfcXVlcnlfdW5tYXNrKGlycSk7DQot
CS8qIFdlIHRyeSB0byB1c2UgdGhlIGhhbmRsZXIgd2l0aCB0aGUgYXBwcm9w
cmlhdGUgc2VtYW50aWMgZm9yIHRoZQ0KLQkgKiB0eXBlIG9mIGludGVycnVw
dDogaWYgdGhlIGludGVycnVwdCBpcyBhbiBlZGdlIHRyaWdnZXJlZA0KLQkg
KiBpbnRlcnJ1cHQgd2UgdXNlIGhhbmRsZV9lZGdlX2lycS4NCi0JICoNCi0J
ICogT24gdGhlIG90aGVyIGhhbmQgaWYgdGhlIGludGVycnVwdCBpcyBsZXZl
bCB0cmlnZ2VyZWQgd2UgdXNlDQotCSAqIGhhbmRsZV9mYXN0ZW9pX2lycSBs
aWtlIHRoZSBuYXRpdmUgY29kZSBkb2VzIGZvciB0aGlzIGtpbmQgb2YNCi0J
ICogaW50ZXJydXB0cy4NCisJLyogV2UgdXNlIGhhbmRsZV9mYXN0ZW9pX2ly
cSBmb3IgUElSUXMgYmVjYXVzZSB3ZSB3YW50IHRvIGtlZXANCisJICogdGhl
IGV2dGNobiBtYXNrZWQgd2hpbGUgaGFuZGxpbmcgYW5kIGNsZWFyaW5nIHRo
ZSBldmVudC4NCisJICogVW5tYXNraW5nIHRoZSBldnRjaG4gc2hvdWxkIG9u
bHkgaGFwcGVuIGFmdGVyIGNsZWFyaW5nIGl0Lg0KIAkgKg0KIAkgKiBEZXBl
bmRpbmcgb24gdGhlIFhlbiB2ZXJzaW9uLCBwaXJxX25lZWRzX2VvaSBtaWdo
dCByZXR1cm4gdHJ1ZQ0KIAkgKiBub3Qgb25seSBmb3IgbGV2ZWwgdHJpZ2dl
cmVkIGludGVycnVwdHMgYnV0IGZvciBlZGdlIHRyaWdnZXJlZA0KQEAgLTY5
OSwxMiArNjg5LDggQEAgaW50IHhlbl9iaW5kX3BpcnFfZ3NpX3RvX2lycSh1
bnNpZ25lZCBnc2ksDQogCSAqIGhhc24ndCByZWNlaXZlZCBhbiBlb2kgeWV0
LiBUaGVyZWZvcmUgdXNpbmcgdGhlIGZhc3Rlb2kgaGFuZGxlcg0KIAkgKiBp
cyB0aGUgcmlnaHQgY2hvaWNlIGVpdGhlciB3YXkuDQogCSAqLw0KLQlpZiAo
c2hhcmVhYmxlKQ0KLQkJaXJxX3NldF9jaGlwX2FuZF9oYW5kbGVyX25hbWUo
aXJxLCAmeGVuX3BpcnFfY2hpcCwNCi0JCQkJaGFuZGxlX2Zhc3Rlb2lfaXJx
LCBuYW1lKTsNCi0JZWxzZQ0KLQkJaXJxX3NldF9jaGlwX2FuZF9oYW5kbGVy
X25hbWUoaXJxLCAmeGVuX3BpcnFfY2hpcCwNCi0JCQkJaGFuZGxlX2VkZ2Vf
aXJxLCBuYW1lKTsNCisJaXJxX3NldF9jaGlwX2FuZF9oYW5kbGVyX25hbWUo
aXJxLCAmeGVuX3BpcnFfY2hpcCwNCisJCQloYW5kbGVfZmFzdGVvaV9pcnEs
IG5hbWUpOw0KIA0KIG91dDoNCiAJbXV0ZXhfdW5sb2NrKCZpcnFfbWFwcGlu
Z191cGRhdGVfbG9jayk7DQpAQCAtNzM5LDcgKzcyNSw3IEBAIGludCB4ZW5f
YmluZF9waXJxX21zaV90b19pcnEoc3RydWN0IHBjaV9kZXYgKmRldiwgc3Ry
dWN0IG1zaV9kZXNjICptc2lkZXNjLA0KIAkJZ290byBvdXQ7DQogDQogCWZv
ciAoaSA9IDA7IGkgPCBudmVjOyBpKyspIHsNCi0JCWlycV9zZXRfY2hpcF9h
bmRfaGFuZGxlcl9uYW1lKGlycSArIGksICZ4ZW5fcGlycV9jaGlwLCBoYW5k
bGVfZWRnZV9pcnEsIG5hbWUpOw0KKwkJaXJxX3NldF9jaGlwX2FuZF9oYW5k
bGVyX25hbWUoaXJxICsgaSwgJnhlbl9waXJxX2NoaXAsIGhhbmRsZV9mYXN0
ZW9pX2lycSwgbmFtZSk7DQogDQogCQlyZXQgPSB4ZW5faXJxX2luZm9fcGly
cV9zZXR1cChpcnEgKyBpLCAwLCBwaXJxICsgaSwgMCwgZG9taWQsDQogCQkJ
CQkgICAgICBpID09IDAgPyAwIDogUElSUV9NU0lfR1JPVVApOw0KQEAgLTE1
OTYsOSArMTU4Miw3IEBAIHN0YXRpYyBzdHJ1Y3QgaXJxX2NoaXAgeGVuX3Bp
cnFfY2hpcCBfX3JlYWRfbW9zdGx5ID0gew0KIAkuaXJxX21hc2sJCT0gZGlz
YWJsZV9keW5pcnEsDQogCS5pcnFfdW5tYXNrCQk9IGVuYWJsZV9keW5pcnEs
DQogDQotCS5pcnFfYWNrCQk9IGVvaV9waXJxLA0KIAkuaXJxX2VvaQkJPSBl
b2lfcGlycSwNCi0JLmlycV9tYXNrX2FjawkJPSBtYXNrX2Fja19waXJxLA0K
IA0KIAkuaXJxX3NldF9hZmZpbml0eQk9IHNldF9hZmZpbml0eV9pcnEsDQog
DQotLSANCjIuMTcuMQ0KDQo=

--8323329-1847598456-1588028657=:29217--


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 23:21:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 23:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTD4C-0001IY-5l; Mon, 27 Apr 2020 23:21:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HlLs=6L=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTD4B-0001IN-Ph
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 23:21:35 +0000
X-Inumbo-ID: d6388a0a-88dd-11ea-ae69-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d6388a0a-88dd-11ea-ae69-bc764e2007e4;
 Mon, 27 Apr 2020 23:21:35 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id BA3072075E;
 Mon, 27 Apr 2020 23:21:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588029694;
 bh=nx/nmVldIYIOy9rsYk4VVkSu6iXjMMKfmu5BQ+ZhcWw=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=QmRbRaSsPI74rTpOqE00WGqPkL5WZDa9yawhH0qThzIvAMBSDrsFB5A3MqmaKy7RH
 yti1KTxfKEnR0hnKK0ZnVtHeTZ+oVz0VmmouYM8URZfshs2UB0BbiwkNxd/o4odZWI
 EPhnof4TE+5fHtGALqfV6JTfNY944+Nlfu7aEtc0=
Date: Mon, 27 Apr 2020 16:21:34 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien.grall.oss@gmail.com>
Subject: Re: arm: DomU Networking enable leads to Dom0 kernel oops
In-Reply-To: <CAJ=z9a0s-KGyP--kFzBdohzf509toZBq6qHrnt8JQEaLAaQ7=Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2004271620190.29217@sstabellini-ThinkPad-T480s>
References: <VI1PR04MB505620B32C8289C6106D0B2AF9D00@VI1PR04MB5056.eurprd04.prod.outlook.com>
 <alpine.DEB.2.21.2004241443570.7982@sstabellini-ThinkPad-T480s>
 <CAJ=z9a284froER_-dNQKWwzXkPJ5S0yodY1vyqukqDywxWtCXg@mail.gmail.com>
 <CAJ=z9a0s-KGyP--kFzBdohzf509toZBq6qHrnt8JQEaLAaQ7=Q@mail.gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Andrei Cherechesu <andrei.cherechesu@nxp.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Sat, 25 Apr 2020, Julien Grall wrote:
> On Sat, 25 Apr 2020 at 10:49, Julien Grall <julien.grall.oss@gmail.com> wrote:
> >
> > On Sat, 25 Apr 2020 at 03:01, Stefano Stabellini <sstabellini@kernel.org> wrote:
> > > [   86.900974] ------------[ cut here ]------------
> > > [   86.905134] Interrupt for port 6, but apparently not enabled; per-user (____ptrval____)
> > > [   86.913228] WARNING: CPU: 0 PID: 2437 at drivers/xen/evtchn.c:167 evtchn_interrupt+0xfc/0x108
> >
> > The implementation of the evtchn_interrupt() is relying to be called
> > in the top-half. On RT, interrupts handlers are forced to be threaded
> > and use the IRQF_ONESHOT semantics if they were not threaded before.
> >
> > However, IRQF_ONESHOT is completely broken for event channels (this is
> > not RT's fault) and hence why you see the warning here.
> >
> > Note that you can't force to run evtchn_interrupt() in the top-half
> > because it relies on functions that may sleep.
> >
> > See https://lkml.org/lkml/2019/2/19/642.
> 
> Here at better link with the full conversation:
> 
> https://lore.kernel.org/lkml/5e256d9a-572c-e01e-7706-407f99245b00@arm.com/

Many thanks for pointing it out to me. I think I know what the problem
is. I replied to that thread with a patch that fixes my LinuxRT issue on ARM:

https://marc.info/?l=xen-devel&m=158802965821440&w=2


From xen-devel-bounces@lists.xenproject.org Mon Apr 27 23:54:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Apr 2020 23:54:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTDZw-0004KT-B4; Mon, 27 Apr 2020 23:54:24 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6V0E=6L=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTDZu-0004KM-F3
 for xen-devel@lists.xenproject.org; Mon, 27 Apr 2020 23:54:22 +0000
X-Inumbo-ID: 6a3d58ee-88e2-11ea-97eb-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6a3d58ee-88e2-11ea-97eb-12813bfff9fa;
 Mon, 27 Apr 2020 23:54:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=hdlechMe9svi048ZbpC99RGV/b4cddgc3zkRwlV48iw=; b=IuAd19OhIRTXWcBmY5TW9JPB+
 Ov93VCmVz+O2gCSFBDN3S/TBSZh017K1VSvE1DmIxr9l6ilEYIrMQap86Oguhjk7626X9ftqC0ygJ
 dujMQa9ZBkCA8ybAvD6VmvTeeuXqFXdK2pyTnKDlyJjbTHSI8BBvz8ohzt+pvurDNNcGU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTDZt-0004Y2-9V; Mon, 27 Apr 2020 23:54:21 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTDZt-00074j-0S; Mon, 27 Apr 2020 23:54:21 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTDZs-0005gR-W7; Mon, 27 Apr 2020 23:54:20 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149839-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149839: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=dd0882f912005b56653013025ebd160862e360ad
X-Osstest-Versions-That: xen=df669de074c395a3b2eeb975fddd3da4c148da13
From: osstest service owner <osstest-admin@xenproject.org>
Date: Mon, 27 Apr 2020 23:54:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149839 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149839/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  dd0882f912005b56653013025ebd160862e360ad
baseline version:
 xen                  df669de074c395a3b2eeb975fddd3da4c148da13

Last test of basis   149837  2020-04-27 14:00:43 Z    0 days
Testing same since   149839  2020-04-27 21:01:50 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   df669de074..dd0882f912  dd0882f912005b56653013025ebd160862e360ad -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 02:58:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 02:58:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTGRz-0002F0-Ff; Tue, 28 Apr 2020 02:58:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qrdk=6M=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTGRy-0002Ev-Hf
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 02:58:22 +0000
X-Inumbo-ID: 1dbfdfa4-88fc-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1dbfdfa4-88fc-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 02:58:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=PBDKrhCGgiL1u4q9NMQ/Jq5POPMS3ZYPJLEwNQSi8ck=; b=PH+HdW4CMVUoM2g0p2KtwmQ58
 optn7wrPJMcJtmyr7cG5gOXyhSlMCwbNTqoBOXQ0p/XXAdux0qT6EjjEhiggDdCqcGeyrQNep//K9
 yvQdyFmPEwZ+NqJ2U/2YK7bQ51V66jorbK36FCz4nOxvKrAFkAJVAOpcSXGlXxBFzw3VE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTGRv-0006uN-Tm; Tue, 28 Apr 2020 02:58:19 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTGRv-000824-L2; Tue, 28 Apr 2020 02:58:19 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTGRv-0004oy-KO; Tue, 28 Apr 2020 02:58:19 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149838-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.12-testing test] 149838: regressions - FAIL
X-Osstest-Failures: xen-4.12-testing:test-armhf-armhf-xl-credit2:xen-boot:fail:regression
 xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=e6a2681148382e9227f54b70a5df8e895914c877
X-Osstest-Versions-That: xen=3536f8dc39cc7311715340b87a04a89fac468406
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 28 Apr 2020 02:58:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149838 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149838/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   7 xen-boot                 fail REGR. vs. 149646

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow2    17 guest-localmigrate/x10       fail  like 149646
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 xen                  e6a2681148382e9227f54b70a5df8e895914c877
baseline version:
 xen                  3536f8dc39cc7311715340b87a04a89fac468406

Last test of basis   149646  2020-04-14 13:05:53 Z   13 days
Testing same since   149838  2020-04-27 14:06:02 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Harsha Shamsundara Havanur <havanur@amazon.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit e6a2681148382e9227f54b70a5df8e895914c877
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Mon Apr 27 15:58:42 2020 +0200

    build,xsm: fix multiple call
    
    Both script mkflask.sh and mkaccess_vector.sh generates multiple
    files. Exploits the 'multi-target pattern rule' trick to call each
    scripts only once.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    master commit: 52f3f319851e40892fbafeae53e512c7d61f03d0
    master date: 2020-04-23 09:59:05 +0200

commit d32cbbc141837600aa74f331c31a06df3777a2fb
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Apr 27 15:57:13 2020 +0200

    x86: validate VM assist value in arch_set_info_guest()
    
    While I can't spot anything that would go wrong, just like the
    respective hypercall only permits applicable bits to be set, we should
    also do so when loading guest context.
    
    Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: a62c6fe05c4ae905b7d4cb0ca946508b7f96d522
    master date: 2020-04-22 13:01:10 +0200

commit 8d2ea0f4c830a3a6a7e7a19aa4f7d8a9fd854521
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Apr 27 15:55:51 2020 +0200

    x86/HVM: expose VM assist hypercall
    
    In preparation for the addition of VMASST_TYPE_runstate_update_flag
    commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
    the hypercall for Arm. I consider it not logical that it then isn't also
    exposed to x86 HVM guests (with the same single feature permitted to be
    enabled as Arm has); Linux actually tries to use it afaict.
    
    Rather than introducing yet another thin wrapper around vm_assist(),
    make that function the main handler, requiring a per-arch
    arch_vm_assist_valid_mask() definition instead.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Julien Grall <jgrall@amazon.com>
    master commit: f13404d57f55a97838f1c16a366fbc3231ec21f1
    master date: 2020-04-22 12:58:25 +0200

commit a6366e0f884db4302354ce7372ece93aeb95207f
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Apr 27 15:54:14 2020 +0200

    x86: Enumeration for Control-flow Enforcement Technology
    
    The CET spec has been published and guest kernels are starting to get support.
    Introduce the CPUID and MSRs, and fully block the MSRs from guest use.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Wei Liu <wl@xen.org>
    master commit: 4803a67114279a656a54a23cebed646da32efeb6
    master date: 2020-04-21 16:52:03 +0100

commit 55d65346d70b779f082b7764480e745cb51e675f
Author: Roger Pau Monné <roger.pau@citrix.com>
Date:   Mon Apr 27 15:53:26 2020 +0200

    x86/vtd: relax EPT page table sharing check
    
    The EPT page tables can be shared with the IOMMU as long as the page
    sizes supported by EPT are also supported by the IOMMU.
    
    Current code checks that both the IOMMU and EPT support the same page
    sizes, but this is not strictly required, the IOMMU supporting more
    page sizes than EPT is fine and shouldn't block page table sharing.
    
    This is likely not a common case (IOMMU supporting more page sizes
    than EPT), but should still be fixed for correctness.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    master commit: 3957e12c02670b97855ef0933b373f99993fa598
    master date: 2020-04-21 10:54:56 +0200

commit 6bf8bdd5c66148c991b9e046491956b84fdb0fb5
Author: Harsha Shamsundara Havanur <havanur@amazon.com>
Date:   Mon Apr 27 15:52:45 2020 +0200

    hvmloader: enable MMIO and I/O decode, after all resource allocation
    
    It was observed that PCI MMIO and/or IO BARs were programmed with
    memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
    during PCI setup phase. This resulted in incorrect memory mapping as
    soon as the lower half of the 64 bit bar is programmed.
    This displaced any RAM mappings under 4G. After the
    upper half is programmed PCI memory mapping is restored to its
    intended high mem location, but the RAM displaced is not restored.
    The OS then continues to boot and function until it tries to access
    the displaced RAM at which point it suffers a page fault and crashes.
    
    This patch address the issue by deferring enablement of memory and
    I/O decode in command register until all the resources, like interrupts
    I/O and/or MMIO BARs for all the PCI device functions are programmed,
    in the descending order of memory requested.
    
    Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    master commit: a8e0c228c79f3a000e19183090eb41fca173b034
    master date: 2020-04-16 10:58:46 +0200

commit e8032787d44ff9dfe157bda9e7f47e1c58faa973
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Apr 27 15:51:14 2020 +0200

    x86/boot: Fix early exception handling with CONFIG_PERF_COUNTERS
    
    The PERFC_INCR() macro uses current->processor, but current is not valid
    during early boot.  This causes the following crash to occur if
    e.g. rdmsr_safe() has to recover from a #GP fault.
    
      (XEN) Early fatal page fault at e008:ffff82d0803b1a39 (cr2=0000000000000004, ec=0000)
      (XEN) ----[ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]----
      (XEN) CPU:    0
      (XEN) RIP:    e008:[<ffff82d0803b1a39>] x86_64/entry.S#handle_exception_saved+0x64/0xb8
      ...
      (XEN) Xen call trace:
      (XEN)    [<ffff82d0803b1a39>] R x86_64/entry.S#handle_exception_saved+0x64/0xb8
      (XEN)    [<ffff82d0806394fe>] F __start_xen+0x2cd/0x2980
      (XEN)    [<ffff82d0802000ec>] F __high_start+0x4c/0x4e
    
    Furthermore, the PERFC_INCR() macro is wildly inefficient.  There has been a
    single caller for many releases now, so inline it and delete the macro
    completely.
    
    There is no need to reference current at all.  What is actually needed is the
    per_cpu_offset which can be obtained directly from the top-of-stack block.
    This simplifies the counter handling to 3 instructions and no spilling to the
    stack at all.
    
    The same breakage from above is now handled properly:
    
      (XEN) traps.c:1591: GPF (0000): ffff82d0806394fe [__start_xen+0x2cd/0x2980] -> ffff82d0803b3bfb
    
    Reported-by: Julien Grall <jgrall@amazon.com>
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Julien Grall <jgrall@amazon.com>
    master commit: 615bfe42c6d183a0e54a0525ef82b58580d01619
    master date: 2020-04-16 09:48:38 +0100

commit 499a2944d7651acacfb81ac9ec9ef720ca05883b
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Apr 27 15:49:38 2020 +0200

    x86/EFI: also fill boot_tsc_stamp on the xen.efi boot path
    
    Commit e3a379c35eff ("x86/time: always count s_time from Xen boot")
    introducing this missed adjusting this path as well.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Wei Liu <wl@xen.org>
    master commit: 0dbc112e727f6c17f306c864950bdf83dece5cd5
    master date: 2020-04-14 11:42:11 +0200
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:05:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHUy-0000MP-8K; Tue, 28 Apr 2020 04:05:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHUx-0000MK-0Y
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:05:31 +0000
X-Inumbo-ID: 7f625486-8905-11ea-ae69-bc764e2007e4
Received: from mail-qk1-x741.google.com (unknown [2607:f8b0:4864:20::741])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7f625486-8905-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:29 +0000 (UTC)
Received: by mail-qk1-x741.google.com with SMTP id l78so20534399qke.7
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=SSkRhzb3hdUii5pdYsRs72uZgeElz9D/Us23IyrCwco=;
 b=lyDTN0WquyldQiEzSG09jVte+I38DXlC/EnL+OdK9omxTuORBc/Hqxq/pN45kk5GAN
 ff/9+l+GyOze/OyT1f4wCNYdT9kHHJitgJ+hDUhMlBdrSWaujt6w+neRAZ4nxPfgWCxB
 fr+bh0EVwr6cNRy38e4YgxMR7JNtDpCbZRBKlT24/ZLtLJYTguL2xmaA4UD2BDl2vWj8
 MuVFDn+TJP67ed2DFHXs/dYnFdgjY8uqNKrz3pkscz19JQMZLZprmP2ae7CcI9CSxMaY
 xBtF+FA4p7FJ94Ktb8JqmR5wKFuWVbMFfYyb362UjIZkzuJVF3JkD9Tbd27HrLRSJ+6G
 aF7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=SSkRhzb3hdUii5pdYsRs72uZgeElz9D/Us23IyrCwco=;
 b=E+f2c3fj3cCSvD4mmejR70F9OS8KftxTKbbbhnYuNthCNXJS5eQFknj+tNmyBe9dcj
 rOj0fWzgSNSKf+CohUK/2lsi6Q2pPvYDY73oMh1VJNBUTi3xipUgb7ZnTX7bIuGdNyxC
 ZE893S8tBtWKgQmSTj7KZLJQ92pXa5WTGQ7sjSCTlWNv+3oNVbL6F+CCKZPaCfvoPFDC
 jxZIN8DKcMXSoeTLSY7f3hCBs/BYxD+pzbXmHiPrfH97KZZDHajvTw3qNVQS7p2NEmpE
 j2riPvmrUJSE1I7Fu0JnCEMquJaPgJEwka/8nnyEP2DLKmq1sUY40Eb6bLKmRr9keP2g
 KURg==
X-Gm-Message-State: AGi0PubaUh58JmN1Tv92/O26s8Z4Fqa26i75fCTLg4DOTtA6liLlHVNz
 z8pvEkypKVIRuS2AbAc+g0H3TYUNZL8=
X-Google-Smtp-Source: APiQypJVEZhagpxazMsT4JZtYimyUeczpPaKVzJ3ppbhvW3zQ1eD9vYf5HId9dbCYWMnlgdu7Mzz0A==
X-Received: by 2002:a37:638d:: with SMTP id
 x135mr23666881qkb.366.1588046728656; 
 Mon, 27 Apr 2020 21:05:28 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:27 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 01/21] Document ioemu MiniOS stubdomain protocol
Date: Tue, 28 Apr 2020 00:04:13 -0400
Message-Id: <20200428040433.23504-2-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Jason Andryuk <jandryuk@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Add documentation based on reverse-engineered toolstack-ioemu stubdomain
protocol.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 docs/misc/stubdom.txt | 53 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
index 882a18cab4..64c77d9b64 100644
--- a/docs/misc/stubdom.txt
+++ b/docs/misc/stubdom.txt
@@ -23,6 +23,59 @@ and https://wiki.xen.org/wiki/Device_Model_Stub_Domains for more
 information on device model stub domains
 
 
+Toolstack to MiniOS ioemu stubdomain protocol
+---------------------------------------------
+
+This section describe communication protocol between toolstack and
+qemu-traditional running in MiniOS stubdomain. The protocol include
+expectations of both qemu and stubdomain itself.
+
+Setup (done by toolstack, expected by stubdomain):
+ - Block devices for target domain are connected as PV disks to stubdomain,
+   according to configuration order, starting with xvda
+ - Network devices for target domain are connected as PV nics to stubdomain,
+   according to configuration order, starting with 0
+ - if graphics output is expected, VFB and VKB devices are set for stubdomain
+   (its backend is responsible for exposing them using appropriate protocol
+   like VNC or Spice)
+ - other target domain's devices are not connected at this point to stubdomain
+   (may be hot-plugged later)
+ - QEMU command line (space separated arguments) is stored in
+   /vm/<target-uuid>/image/dmargs xenstore path
+ - target domain id is stored in /local/domain/<stubdom-id>/target xenstore path
+?? - bios type is stored in /local/domain/<target-id>/hvmloader/bios
+ - stubdomain's console 0 is connected to qemu log file
+ - stubdomain's console 1 is connected to qemu save file (for saving state)
+ - stubdomain's console 2 is connected to qemu save file (for restoring state)
+ - next consoles are connected according to target guest's serial console configuration
+
+Startup:
+1. PV stubdomain is started with ioemu-stubdom.gz kernel and no initrd
+2. stubdomain initialize relevant devices
+3. stubdomain signal readiness by writing "running" to /local/domain/<stubdom-id>/device-model/<target-id>/state xenstore path
+4. now stubdomain is considered running
+
+Runtime control (hotplug etc):
+Toolstack can issue command through xenstore. The sequence is (from toolstack POV):
+1. Write parameter to /local/domain/<stubdom-id>/device-model/<target-id>/parameter.
+2. Write command to /local/domain/<stubdom-id>/device-model/<target-id>/command.
+3. Wait for command result in /local/domain/<stubdom-id>/device-model/<target-id>/state (command specific value).
+4. Write "running" back to /local/domain/<stubdom-id>/device-model/<target-id>/state.
+
+Defined commands:
+ - "pci-ins" - PCI hot plug, results:
+   - "pci-inserted" - success
+   - "pci-insert-failed" - failure
+ - "pci-rem" - PCI hot remove, results:
+   - "pci-removed" - success
+   - ??
+ - "save" - save domain state to console 1, results:
+   - "paused" - success
+ - "continue" - resume domain execution, after loading state from console 2 (require -loadvm command argument), results:
+   - "running" - success
+
+
+
                                    PV-GRUB
                                    =======
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:05:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHUu-0000MD-0N; Tue, 28 Apr 2020 04:05:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHUs-0000M8-3Q
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:05:26 +0000
X-Inumbo-ID: 7cea8480-8905-11ea-ae69-bc764e2007e4
Received: from mail-qt1-x841.google.com (unknown [2607:f8b0:4864:20::841])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7cea8480-8905-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:25 +0000 (UTC)
Received: by mail-qt1-x841.google.com with SMTP id c23so15747159qtp.11
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=4/7xFqOrb91eS4rpAZKI6VWcij3qXjaaQ78Xq4yTH7A=;
 b=mSZOcgl5dO6nLIWcecW4coY9gcxK2Tmt62F03Y66nsUaRLvy3c2aB7SWDRalFpZpCu
 NpDPptPits4/ACz8s9DtSianweoXTIXrFZQ1NQP3fgZG9ydpcrBrCuzQOfQcUaS6BdFQ
 V4iOgqFOVB5Fc/FJI6ZUgBd+sx5wQ9ktDe3gEgYphZ1T+G9nxrpHw1uIfiAD1EVvej/w
 qLiWXA5hr/DY/WwXLVF+3Q3j7Jmo1Q0UaV6yh8X/zcry8l2Y9CXGrCPXSYIh42ak3faw
 +ZUwDKwrjFJr+s8quWso1p+KYrGGr4ZkuWBXlpxqjZtZiofiFamei1jXd5ZNdHyQFt/D
 KISw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=4/7xFqOrb91eS4rpAZKI6VWcij3qXjaaQ78Xq4yTH7A=;
 b=hH4l4SBdlUrS0FHxGGo4/EbyUK7c+lL4GLYNFij46t3unxnxzSPEYHFhaNqKC4skg6
 tFbXju0SVnUGqHfo6pbfIT3N4xLPgocKN3hRPg17bo5HZG5gR/492DH7GwIKvboT4Ty8
 cZU+8zmzrQKVe+OB5ZveE/87OLP6ihSVHcCQj53pGI5Kv9Z7nBL3JfFiDBWmdbRLoNt2
 hfM8ER06pTr8Cxe4DrMSDKfVa4EQwlERbKQOh+oqBzol0HTjbfpP3kDFMwyVr0bdmFA6
 AoWCrRWIztFngifsSdzerI3eWQr77mTSbuJW1yIYQJxxNWDL453ls3W3DQCVFix+fDEY
 UmBA==
X-Gm-Message-State: AGi0Pub5y8P810L6DEhk3YU/GgTWuo9iZhmC+V5Nm4+xRiTqfl8w9k1y
 VuLzYEhMCOTX0SAAnhkz2kScRsNqTAc=
X-Google-Smtp-Source: APiQypItCpdAcvCLTTP23gV2A0RgbABCgaSFaHr8HjvJYzrouYh5nUtoCnxl4tyryN7Uj8OPhrqUeA==
X-Received: by 2002:ac8:1a8a:: with SMTP id x10mr26141504qtj.154.1588046724342; 
 Mon, 27 Apr 2020 21:05:24 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:23 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 00/21] Add support for qemu-xen runnning in a Linux-based
 stubdomain
Date: Tue, 28 Apr 2020 00:04:12 -0400
Message-Id: <20200428040433.23504-1-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Jason Andryuk <jandryuk@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Simon Gaiser <simon@invisiblethingslab.com>,
 Jan Beulich <jbeulich@suse.com>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>, Eric Shelton <eshelton@pobox.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

In coordination with Marek, I'm making a submission of his patches for Linux
stubdomain device-model support.  I made a few of my own additions, but Marek
did the heavy lifting.  Thank you, Marek.

Below is mostly the v4 cover leter with a few additions.

General idea is to allow freely set device_model_version and
device_model_stubdomain_override and choose the right options based on this
choice.  Also, allow to specific path to stubdomain kernel/ramdisk, for greater
flexibility.

First two patches add documentation about expected toolstack-stubdomain-qemu
interface, both for MiniOS stubdomain and Linux stubdomain.

Initial version has no QMP support - in initial patches it is completely
disabled, which means no suspend/restore and no PCI passthrough.

Later patches add QMP over libvchan connection support. The actual connection
is made in a separate process. As discussed on Xen Summit 2019, this allows to
apply some basic checks and/or filtering (not part of this series), to limit
libxl exposure for potentially malicious stubdomain.

Jason's additions ensure the qmp-proxy (vchan-socket-proxy) processes and
sockets are cleaned up and add some documentation.

The actual stubdomain implementation is here:

    https://github.com/marmarek/qubes-vmm-xen-stubdom-linux
    (branch for-upstream, tag for-upstream-v3)

See readme there for build instructions.  Marek's version requires dracut.  I
have hacked up a version usable install with initramfs-tools:

   https://github.com/jandryuk/qubes-vmm-xen-stubdom-linux
   (branch initramfs-tools)

Few comments/questions about the stubdomain code:

1. There are extra patches for qemu that are necessary to run it in stubdomain.
While it is desirable to upstream them, I think it can be done after merging
libxl part. Stubdomain's qemu build will in most cases be separate anyway, to
limit qemu's dependencies (so the stubdomain size).

2. By default Linux hvc-xen console frontend is unreliable for data transfer
(qemu state save/restore) - it drops data sent faster than client is reading
it. To fix it, console device needs to be switched into raw mode (`stty raw
/dev/hvc1`). Especially for restoring qemu state it is tricky, as it would need
to be done before opening the device, but stty (obviously) needs to open the
device first. To solve this problem, for now the repository contains kernel
patch which changes the default for all hvc consoles. Again, this isn't
practical problem, as the kernel for stubdomain is built separately. But it
would be nice to have something working with vanilla kernel. I see those
options:
  - convert it to kernel cmdline parameter (hvc_console_raw=1 ?)
  - use channels instead of consoles (and on the kernel side change the default
    to "raw" only for channels); while in theory better design, libxl part will
    be more complex, as channels can be connected to sockets but not files, so
    libxl would need to read/write to it exactly when qemu write/read the data,
    not before/after as it is done now

3. Mini-OS stubdoms use dmargs xenstore key as a string.  Linux stubdoms use
dmargs as a directory for numbered entries.  Should they be different names?

Remaining parts for eliminating dom0's instance of qemu:
 - do not force QDISK backend for CDROM
 - multiple consoles support in xenconsoled

Changes in v2:
 - apply review comments by Jason Andryuk
Changes in v3:
 - rework qemu arguments handling (separate xenstore keys, instead of \x1b separator)
 - add QMP over libvchan, instead of console
 - add protocol documentation
 - a lot of minor changes, see individual patches for full changes list
 - split xenconsoled patches into separate series
Changes in v4:
 - extract vchan connection into a separate process
 - rebase on master
 - various fixes
Changes in v5:
 - Marek: apply review comments from Jason Andryuk
 - Jason: Clean up qmp-proxy processes and sockets

Cc: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Cc: Simon Gaiser <simon@invisiblethingslab.com>
Cc: Eric Shelton <eshelton@pobox.com>
Cc: Ian Jackson <ian.jackson@citrix.com>
Cc: Wei Liu <wl@xen.org>

Eric Shelton (1):
  libxl: Handle Linux stubdomain specific QEMU options.

Jason Andryuk (5):
  docs: Add device-model-domid to xenstore-paths
  libxl: Check stubdomain kernel & ramdisk presence
  libxl: Refactor kill_device_model to libxl__kill_xs_path
  libxl: Kill vchan-socket-proxy when cleaning up qmp
  tools: Clean up vchan-socket-proxy socket

Marek Marczykowski-Górecki (15):
  Document ioemu MiniOS stubdomain protocol
  Document ioemu Linux stubdomain protocol
  libxl: fix qemu-trad cmdline for no sdl/vnc case
  libxl: Allow running qemu-xen in stubdomain
  libxl: write qemu arguments into separate xenstore keys
  xl: add stubdomain related options to xl config parser
  tools/libvchan: notify server when client is connected
  libxl: add save/restore support for qemu-xen in stubdomain
  tools: add missing libxenvchan cflags
  tools: add simple vchan-socket-proxy
  libxl: use vchan for QMP access with Linux stubdomain
  Regenerate autotools files
  libxl: require qemu in dom0 even if stubdomain is in use
  libxl: ignore emulated IDE disks beyond the first 4
  libxl: consider also qemu in stubdomain in libxl__dm_active check

 .gitignore                          |   1 +
 configure                           |  14 +-
 docs/configure                      |  14 +-
 docs/man/xl.cfg.5.pod.in            |  27 +-
 docs/misc/stubdom.txt               | 103 ++++++
 docs/misc/xenstore-paths.pandoc     |   5 +
 stubdom/configure                   |  14 +-
 tools/Rules.mk                      |   2 +-
 tools/config.h.in                   |   3 +
 tools/configure                     |  46 ++-
 tools/configure.ac                  |   9 +
 tools/libvchan/Makefile             |   8 +-
 tools/libvchan/init.c               |   3 +
 tools/libvchan/vchan-socket-proxy.c | 500 ++++++++++++++++++++++++++++
 tools/libxl/libxl_aoutils.c         |  32 ++
 tools/libxl/libxl_create.c          |  46 ++-
 tools/libxl/libxl_dm.c              | 484 +++++++++++++++++++++------
 tools/libxl/libxl_domain.c          |   7 +
 tools/libxl/libxl_internal.h        |  22 ++
 tools/libxl/libxl_mem.c             |   6 +-
 tools/libxl/libxl_qmp.c             |  27 +-
 tools/libxl/libxl_types.idl         |   3 +
 tools/xl/xl_parse.c                 |   7 +
 23 files changed, 1205 insertions(+), 178 deletions(-)
 create mode 100644 tools/libvchan/vchan-socket-proxy.c

-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:05:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHV7-0000Nr-PL; Tue, 28 Apr 2020 04:05:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHV7-0000NG-14
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:05:41 +0000
X-Inumbo-ID: 8493327c-8905-11ea-b07b-bc764e2007e4
Received: from mail-qv1-xf44.google.com (unknown [2607:f8b0:4864:20::f44])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8493327c-8905-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:38 +0000 (UTC)
Received: by mail-qv1-xf44.google.com with SMTP id t8so9767793qvw.5
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=MJ/wYWaIjP7f/7FREcfMpppu/JiqlH2FlZ3lrFsDLA4=;
 b=s/ry4TNhkeyiE/CLvIMK4n0nF/fmFPiReG/8ypM0JBO77Pxfbx9bmOZWUeGka/9g3n
 sVFSrodQSuasNMSayb9oShCWv5NHaqWYhDTc6xUA3C9CfVn4w9bY7tqDRiVNs4bq+I3f
 zkPBiNww8ZL+BQKA/V7uLnuR9u3mZoFXCsiHH8wZTLU9mWsFH5BMXJTQYFE9e8e4K7Fl
 6DwirhucY+FSieVTDC8gAi2KgAYNs0OakeNDHEhLbEd2i9AwPwo0nSpWs4t01YMC2GBC
 FnYsHVwrRziElstqoP90yK7Qi4XNL7Y/gS74+QUL0BT9E3cdzaDthvBy6Se3q9DSvOBs
 jEuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=MJ/wYWaIjP7f/7FREcfMpppu/JiqlH2FlZ3lrFsDLA4=;
 b=YX3dBevT/cC5e2XayThPn2zTfdBXrsqgGN0MMJIsrUogjgycytuAMmMfp2lQ/+igb0
 VGA9NnW4nbQiprvu/AZyXZrjJK/kP5/3ICKKqLvw40m30fQ/y4HI+f59O9kODdk1qYRu
 xw++tjGHJkTT4lVHwCLfo2uywz7lGWZ0KTX9kTsTvgvs9cOn1568Qc7U50XieNv2XNGy
 NdMOJtvHAPe2YaKEIh64jBwFDtpqSyw1OXkeexsLlLNJzukNalH8NIEqRAKfAY0Nl+bR
 JtYGFM0RoqAqvfCq4y9iArYzJK1DLJbryihJxmwCxPky4RxMcdb0NffedNy8z3xGCp0x
 JprQ==
X-Gm-Message-State: AGi0PuYFv6A53V2flDb64SPREwxFKWsNbeQ5b+nzdMoAgLSS0ez1rHaL
 MKY5uvxqRlOz7qHso8csLi/+MhPn
X-Google-Smtp-Source: APiQypJI07Mxea/Un6qnNGKeAqvst+331zueBYLP+BJJ5zZRFAdjrm2anrdQvvDxr8R7MWoY70R5fQ==
X-Received: by 2002:ad4:4e4d:: with SMTP id
 eb13mr24927138qvb.169.1588046737427; 
 Mon, 27 Apr 2020 21:05:37 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:36 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 03/21] libxl: fix qemu-trad cmdline for no sdl/vnc case
Date: Tue, 28 Apr 2020 00:04:15 -0400
Message-Id: <20200428040433.23504-4-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wei.liu2@citrix.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

When qemu is running in stubdomain, any attempt to initialize vnc/sdl
there will crash it (on failed attempt to load a keymap from a file). If
vfb is present, all those cases are skipped. But since
b053f0c4c9e533f3d97837cf897eb920b8355ed3 "libxl: do not start dom0 qemu
for stubdomain when not needed" it is possible to create a stubdomain
without vfb and contrary to the comment -vnc none do trigger VNC
initialization code (just skips exposing it externally).
Change the implicit SDL avoiding method to -nographics option, used when
none of SDL or VNC is enabled.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Acked-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
Changes in v2:
 - typo in qemu option
Changes in v3:
 - add missing { }
---
 tools/libxl/libxl_dm.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index f4007bbe50..b91e63db6f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -734,14 +734,15 @@ static int libxl__build_device_model_args_old(libxl__gc *gc,
         if (libxl_defbool_val(vnc->findunused)) {
             flexarray_append(dm_args, "-vncunused");
         }
-    } else
+    } else if (!sdl) {
         /*
          * VNC is not enabled by default by qemu-xen-traditional,
-         * however passing -vnc none causes SDL to not be
-         * (unexpectedly) enabled by default. This is overridden by
-         * explicitly passing -sdl below as required.
+         * however skipping -vnc causes SDL to be
+         * (unexpectedly) enabled by default. If undesired, disable graphics at
+         * all.
          */
-        flexarray_append_pair(dm_args, "-vnc", "none");
+        flexarray_append(dm_args, "-nographic");
+    }
 
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:05:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHV2-0000Mm-GT; Tue, 28 Apr 2020 04:05:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHV2-0000Mg-0q
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:05:36 +0000
X-Inumbo-ID: 819d7a8c-8905-11ea-b07b-bc764e2007e4
Received: from mail-qt1-x843.google.com (unknown [2607:f8b0:4864:20::843])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 819d7a8c-8905-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:33 +0000 (UTC)
Received: by mail-qt1-x843.google.com with SMTP id e17so12874799qtp.7
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=ft2YmkVf5v7GMI2mzGT4dRGSFWsB0nPaCI36YbESKr8=;
 b=sVEVcVYnKPJjrq4/ke5l41TPF1bRBUxnpkdzKAAetypbH0YtLcJQfHzW4NDxQAlx8h
 g9t6gKVPkzCGtikIs9K85o/VTn+0tHtOIL/Scau0Zo8w2c69prN9PuxxVPC29KIwEEBm
 TaQYvFGz1Q1o4hUuo+xgJOj8bGzEguc27tsBfGSGsq6NuRMhJa7rV3uB3UQbGdOI5RCz
 4OXA25r3L2vAh2jTju3c2wkRc8tK3JcLSA3ffp2PGO/tglR8yStVqVXB/ZVSvRHFMWBc
 Oh1qCTOATZCBSDG3qWpaguqb7Pr36twkJwsWMThmVOKtBzHUnOMCH3DDNrORrh2DEIhb
 rO/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=ft2YmkVf5v7GMI2mzGT4dRGSFWsB0nPaCI36YbESKr8=;
 b=DhsrpUoKiNHTthpiy8lucpuD3NoupMI7ObKqaQ+JB2MOuOyXRwqPxBh+VH7NTv7VW1
 gIraHEg9ZHGCDwLx2PLJAVhPwU4buOO0z4jvcIFX8FNEVmznBde56F9TwLrE+YmNym2H
 jM++ReA8gkik06i/CfNYdqyme9nu+U5xgaibSjlMZqacIIA5r9s+L77poPLLNvFhdbJz
 KpPDt87qyblipgtZd0gDlJ77tbBUZz9Sc60fAZpqnc7SN3kznOmGqqtR2BC6XkhDD+Kf
 NF8Nn9I3CproDr5+nyXKbydso5QwTbT683rKHwxyQQARud6sz4EzXl8GG88YxTxz4ikI
 y48g==
X-Gm-Message-State: AGi0Pub961nj07KQU4R56aTsfsiBwIgQoVZl7gS8J0f4IUsKYprz36k3
 avgauVeoWomRT0DS7N9LVf5hc+vOVno=
X-Google-Smtp-Source: APiQypIc5wyrWf8cCdgYHLVkj8RK8dV3U2UUDijNgtYbDYWMSmDJzl1Q9Dxovh2ORFbNzTqUnBk3rA==
X-Received: by 2002:ac8:4818:: with SMTP id g24mr15395296qtq.377.1588046732407; 
 Mon, 27 Apr 2020 21:05:32 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:31 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 02/21] Document ioemu Linux stubdomain protocol
Date: Tue, 28 Apr 2020 00:04:14 -0400
Message-Id: <20200428040433.23504-3-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Jason Andryuk <jandryuk@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, George Dunlap <george.dunlap@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Add documentation for upcoming Linux stubdomain for qemu-upstream.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 docs/misc/stubdom.txt | 50 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
index 64c77d9b64..bb5e87dfb9 100644
--- a/docs/misc/stubdom.txt
+++ b/docs/misc/stubdom.txt
@@ -75,6 +75,56 @@ Defined commands:
    - "running" - success
 
 
+Toolstack to Linux ioemu stubdomain protocol
+--------------------------------------------
+
+This section describe communication protocol between toolstack and
+qemu-upstream running in Linux stubdomain. The protocol include
+expectations of both stubdomain, and qemu.
+
+Setup (done by toolstack, expected by stubdomain):
+ - Block devices for target domain are connected as PV disks to stubdomain,
+   according to configuration order, starting with xvda
+ - Network devices for target domain are connected as PV nics to stubdomain,
+   according to configuration order, starting with 0
+ - [not implemented] if graphics output is expected, VFB and VKB devices are set for stubdomain
+   (its backend is responsible for exposing them using appropriate protocol
+   like VNC or Spice)
+ - other target domain's devices are not connected at this point to stubdomain
+   (may be hot-plugged later)
+ - QEMU command line is stored in
+   /vm/<target-uuid>/image/dmargs xenstore dir, each argument as separate key
+   in form /vm/<target-uuid>/image/dmargs/NNN, where NNN is 0-padded argument
+   number
+ - target domain id is stored in /local/domain/<stubdom-id>/target xenstore path
+?? - bios type is stored in /local/domain/<target-id>/hvmloader/bios
+ - stubdomain's console 0 is connected to qemu log file
+ - stubdomain's console 1 is connected to qemu save file (for saving state)
+ - stubdomain's console 2 is connected to qemu save file (for restoring state)
+ - next consoles are connected according to target guest's serial console configuration
+
+Environment exposed by stubdomain to qemu (needed to construct appropriate qemu command line and later interact with qmp):
+ - target domain's disks are available as /dev/xvd[a-z]
+ - console 2 (incoming domain state) is connected with FD 3
+ - console 1 (saving domain state) is added over QMP to qemu as "fdset-id 1" (done by stubdomain, toolstack doesn't need to care about it)
+ - nics are connected to relevant stubdomain PV vifs when available (qemu -netdev should specify ifname= explicitly)
+
+Startup:
+1. toolstack starts PV stubdomain with stubdom-linux-kernel kernel and stubdom-linux-initrd initrd
+2. stubdomain initialize relevant devices
+3. stubdomain starts qemu with requested command line, plus few stubdomain specific ones - including local qmp access options
+4. stubdomain starts vchan server on /local/domain/<stubdom-id>/device-model/<target-id>/qmp-vchan, exposing qmp socket to the toolstack
+5. qemu signal readiness by writing "running" to /local/domain/<stubdom-id>/device-model/<target-id>/state xenstore path
+6. now device model is considered running
+
+QEMU can be controlled using QMP over vchan at /local/domain/<stubdom-id>/device-model/<target-id>/qmp-vchan. Only one simultaneous connection is supported and toolstack needs to ensure that.
+
+Limitations:
+ - PCI passthrough require permissive mode
+ - only one nic is supported
+ - at most 26 emulated disks are supported (more are still available as PV disks)
+ - graphics output (VNC/SDL/Spice) not supported
+
 
                                    PV-GRUB
                                    =======
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:05:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVD-0000Qf-5i; Tue, 28 Apr 2020 04:05:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVC-0000QF-1R
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:05:46 +0000
X-Inumbo-ID: 86acac3c-8905-11ea-ae69-bc764e2007e4
Received: from mail-qt1-x844.google.com (unknown [2607:f8b0:4864:20::844])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 86acac3c-8905-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:41 +0000 (UTC)
Received: by mail-qt1-x844.google.com with SMTP id 71so16251205qtc.12
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=Ddex++nzv2WYh9FC7KtYSgOC1YbK2YwKv0Rii0LLw7o=;
 b=ov+oNqKtDHx8DQ6zzoPSKXyhC8TM3EG+VH40bPsL9hNcHFe9tfYq4VzQbVz4Os602K
 4I2dA1/0OJH0Z9RUNYpIz8EVGWZfhVWLiNCEhV7ja7rfnWNCxGyb8HoXRebyYxv4GN+h
 HILcBRI9M2qpn04fhGk+Z0qbf5gMq2FbmlsytmE6XicGBsO1cIX30q9PMW/obElBHCnQ
 im5n36eDkzV031uhYZo/oaaaM5APjF40WbWHTTwpwaZhuppvq0BQRZCaw7SblfYjoh+o
 ju+oI28j6Z5Y3TkG6GclxGHu74lFY/1bRsKCHxaFKTyj4fRrLjEZdkRgNQEl3WlSH3v2
 DyHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=Ddex++nzv2WYh9FC7KtYSgOC1YbK2YwKv0Rii0LLw7o=;
 b=c4Vsrm9EulKiGKHEvmDjsRzAQmZSORP3s4jI8cNI0PNoJG539non9wutFA3Stkqo2P
 Y8t7IGq+iFR4wLLQmwT2pWqqTLqZfjuMu5c7xYnFPO/r9wFNROWpAPzyuhBprkrPafJH
 N105JwTrfGsUtKB9HbY8Xz1lhwZPeLSCS8r4WGI2jVQ1o63Ax5TeGgpd45dpLnW71g1B
 DbqOZJicgpmNglueLNCFZ2lxHHabAuG7fwNHBWJaFOZ6pZjmezl0OfzRyRLztLuUlzZB
 g16U5P1LC6KXFRkf3aAh49Fdf/8192qMarz3Y8utG6zYFAJxKmHmchqSC0/1NvaDzEUS
 /wQA==
X-Gm-Message-State: AGi0PuaRuQXKeFKRUuQauXTI1w08rFFIdHbyHYyvRWLGexi1aQ+z2yt8
 85Jdq+XrJmOjpnr0GnmffdALcPfa
X-Google-Smtp-Source: APiQypK2jyLGMQGUp4b+E6gCVFV9GE91aXQSlv5XtU2jGUZO+IfaXAVglrJHHI50rqkvZlcfV547Fg==
X-Received: by 2002:ac8:33fd:: with SMTP id d58mr24272862qtb.213.1588046740924; 
 Mon, 27 Apr 2020 21:05:40 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:39 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 04/21] libxl: Allow running qemu-xen in stubdomain
Date: Tue, 28 Apr 2020 00:04:16 -0400
Message-Id: <20200428040433.23504-5-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Do not prohibit anymore using stubdomain with qemu-xen.
To help distingushing MiniOS and Linux stubdomain, add helper inline
functions libxl__stubdomain_is_linux() and
libxl__stubdomain_is_linux_running(). Those should be used where really
the difference is about MiniOS/Linux, not qemu-xen/qemu-xen-traditional.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>

---
Changes in v3:
 - new patch, instead of "libxl: Add "stubdomain_version" to
 domain_build_info"
 - helper functions as suggested by Ian Jackson
---
 tools/libxl/libxl_create.c   |  9 ---------
 tools/libxl/libxl_internal.h | 17 +++++++++++++++++
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e7cb2dbc2b..7423ee8e57 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -171,15 +171,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         }
     }
 
-    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
-        b_info->device_model_version !=
-            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
-        libxl_defbool_val(b_info->device_model_stubdomain)) {
-        LOG(ERROR,
-            "device model stubdomains require \"qemu-xen-traditional\"");
-        return ERROR_INVAL;
-    }
-
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->avail_vcpus.size) {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5f39e44cb9..ebbf926897 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2320,6 +2320,23 @@ _hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
   /* Return the system-wide default device model */
 _hidden libxl_device_model_version libxl__default_device_model(libxl__gc *gc);
 
+static inline
+bool libxl__stubdomain_is_linux_running(libxl__gc *gc, uint32_t domid)
+{
+    /* same logic as in libxl__stubdomain_is_linux */
+    return libxl__device_model_version_running(gc, domid)
+        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+}
+
+static inline
+bool libxl__stubdomain_is_linux(libxl_domain_build_info *b_info)
+{
+    /* right now qemu-tranditional implies MiniOS stubdomain and qemu-xen
+     * implies Linux stubdomain */
+    return libxl_defbool_val(b_info->device_model_stubdomain) &&
+        b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+}
+
 #define DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, fmt, _a...)              \
     libxl__sprintf(gc, "/local/domain/%u/device-model/%u" fmt, dm_domid,   \
                    domid, ##_a)
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:05:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVI-0000Sn-EZ; Tue, 28 Apr 2020 04:05:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVH-0000SD-1K
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:05:51 +0000
X-Inumbo-ID: 89bbd01a-8905-11ea-ae69-bc764e2007e4
Received: from mail-qk1-x742.google.com (unknown [2607:f8b0:4864:20::742])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 89bbd01a-8905-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:46 +0000 (UTC)
Received: by mail-qk1-x742.google.com with SMTP id h124so3365584qke.11
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=4ZHa799QMBrK+LH740solrl4J2E+hLWHdCeWlcMTowY=;
 b=pGbobHFmvz0cl/Kn4uXU40BhrUeZBRnbPh4NyVZSC0ERdgcfSQShYB9ae1lcsW1kpR
 v87BSGIIWwYP3CAK/fPuo2tofFL9arLZXDWXVXmbAWj06z3MPsuqtBa6kb4wxCxwRqOp
 fcyIyKXl4jifo7b0pFkY1nwuHDJ/04f2y8KBb4i0mF1UpjEYiXJWzEfHXrvBEJqPMJbH
 clI90W8EG5yxcdCxABiy6a3ZljMZY/j6HtZpvblU+kVf7WCRMeQeCt7fX5qlsZ6v9WVv
 kvToUQBihglpQb1ShDbTQLt+wuwCU2/QhnqDuBlSMbM0COiP5KX5Fzr5CoFtbLuEunx7
 jZMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=4ZHa799QMBrK+LH740solrl4J2E+hLWHdCeWlcMTowY=;
 b=MGdba816Lp2t64JQLLMBGd1qr5FZGVm6ShAyHkGziYcY1WoxF7Bv6AonCr6cQI9u7F
 ES+X5GzSZeVMzZq6Uz9XyiIcvCk1eILA57nVmkAO/xuwFtU/GD4ijUbIqgC8kSIRAhSG
 3s4qpmiad3ybfvzJi6pShYY90R4qdreWmxz6cfgjyh4p71dN8BbVCax7vdyaha2BnFG7
 rDNUKQEBJ6Xl2Q/J3M32EaScWCubigcRnbTyXQMi7TVsrvORUTHCsxIyV4vRnAVpOaPc
 S4kHaGjsD5QpbSuvfnFVF3seFtBF4b3LO6W1GqhQwbcG8uwSjK4l/FcLWSY5wCAgSkpY
 IDCw==
X-Gm-Message-State: AGi0PuYxumrWI09BML4XAj4y4F7O+Vn50hbiTt6/LBLc1jj/6Afe4Okf
 WdsLb3DmZnwNw2mXlzZFl7Sxs25k
X-Google-Smtp-Source: APiQypK8hBSDJawGiQcW2x0qN4Gz1UkjtRjYpUNAZaKRxT6Xw6Y8nL+dPMV+ldsp933HJaYVL5CtrQ==
X-Received: by 2002:a37:b58:: with SMTP id 85mr2554988qkl.353.1588046745597;
 Mon, 27 Apr 2020 21:05:45 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:44 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 05/21] libxl: Handle Linux stubdomain specific QEMU options.
Date: Tue, 28 Apr 2020 00:04:17 -0400
Message-Id: <20200428040433.23504-6-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Jason Andryuk <jandryuk@gmail.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Simon Gaiser <simon@invisiblethingslab.com>,
 Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>, Eric Shelton <eshelton@pobox.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Eric Shelton <eshelton@pobox.com>

This patch creates an appropriate command line for the QEMU instance
running in a Linux-based stubdomain.

NOTE: a number of items are not currently implemented for Linux-based
stubdomains, such as:
- save/restore
- QMP socket
- graphics output (e.g., VNC)

Signed-off-by: Eric Shelton <eshelton@pobox.com>

Simon:
 * fix disk path
 * fix cdrom path and "format"

Signed-off-by: Simon Gaiser <simon@invisiblethingslab.com>
[drop Qubes-specific parts]
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Allow setting stubdomain_ramdisk independently from stubdomain_kernel
Add a qemu- prefix for qemu-stubdom-linux-{kernel,rootfs} since stubdom
doesn't convey device-model.  Use qemu- since this code is qemu specific.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
Changes in v2:
 - fix serial specified with serial=[ ... ] syntax
 - error out on multiple consoles (incompatible with stubdom)
 - drop erroneous chunk about cdrom
Changes in v3:
 - change to use libxl__stubdomain_is_linux instead of
   b_info->stubdomain_version
 - drop libxl__stubdomain_version_running, prefer
   libxl__stubdomain_is_linux_running introduced by previous patch
 - drop ifup/ifdown script - stubdomain will handle that with qemu
   events itself
 - slightly simplify -serial argument
 - add support for multiple serial consoles, do not ignore
   b_info.u.serial(_list)
 - add error checking for more than 26 emulated disks ("/dev/xvd%c"
   format string)
Changes in v5:
 - commit message fixup to match patch contents - Marek
 - file names are now qemu-stubdom-linux-{kernel,rootfs} - Jason
 - allow setting ramdisk independently of kernel - Jason
---
 tools/libxl/libxl_create.c   |  45 +++++++++
 tools/libxl/libxl_dm.c       | 190 ++++++++++++++++++++++++-----------
 tools/libxl/libxl_internal.h |   1 +
 tools/libxl/libxl_mem.c      |   6 +-
 tools/libxl/libxl_types.idl  |   3 +
 5 files changed, 184 insertions(+), 61 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 7423ee8e57..3b5535f2c8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -171,6 +171,40 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         }
     }
 
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        libxl_defbool_val(b_info->device_model_stubdomain)) {
+        if (!b_info->stubdomain_kernel) {
+            switch (b_info->device_model_version) {
+                case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+                    b_info->stubdomain_kernel =
+                        libxl__abs_path(NOGC, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
+                    break;
+                case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+                    b_info->stubdomain_kernel =
+                        libxl__abs_path(NOGC,
+                                "qemu-stubdom-linux-kernel",
+                                libxl__xenfirmwaredir_path());
+                    break;
+                default:
+                    abort();
+            }
+        }
+        if (!b_info->stubdomain_ramdisk) {
+            switch (b_info->device_model_version) {
+                case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+                    break;
+                case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+                    b_info->stubdomain_ramdisk =
+                        libxl__abs_path(NOGC,
+                                "qemu-stubdom-linux-rootfs",
+                                libxl__xenfirmwaredir_path());
+                    break;
+                default:
+                    abort();
+            }
+        }
+    }
+
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->avail_vcpus.size) {
@@ -206,6 +240,17 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->target_memkb = b_info->max_memkb;
 
+    if (b_info->stubdomain_memkb == LIBXL_MEMKB_DEFAULT) {
+        if (libxl_defbool_val(b_info->device_model_stubdomain)) {
+            if (libxl__stubdomain_is_linux(b_info))
+                b_info->stubdomain_memkb = LIBXL_LINUX_STUBDOM_MEM * 1024;
+            else
+                b_info->stubdomain_memkb = 28 * 1024; // MiniOS
+        } else {
+            b_info->stubdomain_memkb = 0; // no stubdomain
+        }
+    }
+
     libxl_defbool_setdefault(&b_info->claim_mode, false);
 
     libxl_defbool_setdefault(&b_info->localtime, false);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index b91e63db6f..5a7d55686f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1188,6 +1188,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
     int i, connection, devid;
     uint64_t ram_size;
     const char *path, *chardev;
+    bool is_stubdom = libxl_defbool_val(b_info->device_model_stubdomain);
 
     dm_args = flexarray_make(gc, 16, 1);
     dm_envs = flexarray_make(gc, 16, 1);
@@ -1197,39 +1198,42 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
     flexarray_vappend(dm_args, dm,
                       "-xen-domid",
                       GCSPRINTF("%d", guest_domid), NULL);
+    flexarray_append(dm_args, "-no-shutdown");
 
-    flexarray_append(dm_args, "-chardev");
-    if (state->dm_monitor_fd >= 0) {
-        flexarray_append(dm_args,
-            GCSPRINTF("socket,id=libxl-cmd,fd=%d,server,nowait",
-                      state->dm_monitor_fd));
+    /* There is currently no way to access the QMP socket in the stubdom */
+    if (!is_stubdom) {
+        flexarray_append(dm_args, "-chardev");
+        if (state->dm_monitor_fd >= 0) {
+            flexarray_append(dm_args,
+                GCSPRINTF("socket,id=libxl-cmd,fd=%d,server,nowait",
+                          state->dm_monitor_fd));
 
-        /*
-         * Start QEMU with its "CPU" paused, it will not start any emulation
-         * until the QMP command "cont" is used. This also prevent QEMU from
-         * writing "running" to the "state" xenstore node so we only use this
-         * flag when we have the QMP based startup notification.
-         * */
-        flexarray_append(dm_args, "-S");
-    } else {
-        flexarray_append(dm_args,
-                         GCSPRINTF("socket,id=libxl-cmd,"
-                                   "path=%s,server,nowait",
-                                   libxl__qemu_qmp_path(gc, guest_domid)));
-    }
+            /*
+             * Start QEMU with its "CPU" paused, it will not start any emulation
+             * until the QMP command "cont" is used. This also prevent QEMU from
+             * writing "running" to the "state" xenstore node so we only use this
+             * flag when we have the QMP based startup notification.
+             * */
+            flexarray_append(dm_args, "-S");
+        } else {
+            flexarray_append(dm_args,
+                             GCSPRINTF("socket,id=libxl-cmd,"
+                                       "path=%s,server,nowait",
+                                       libxl__qemu_qmp_path(gc, guest_domid)));
+        }
 
-    flexarray_append(dm_args, "-no-shutdown");
-    flexarray_append(dm_args, "-mon");
-    flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
+        flexarray_append(dm_args, "-mon");
+        flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
 
-    flexarray_append(dm_args, "-chardev");
-    flexarray_append(dm_args,
-                     GCSPRINTF("socket,id=libxenstat-cmd,"
-                                    "path=%s/qmp-libxenstat-%d,server,nowait",
-                                    libxl__run_dir_path(), guest_domid));
+        flexarray_append(dm_args, "-chardev");
+        flexarray_append(dm_args,
+                         GCSPRINTF("socket,id=libxenstat-cmd,"
+                                        "path=%s/qmp-libxenstat-%d,server,nowait",
+                                        libxl__run_dir_path(), guest_domid));
 
-    flexarray_append(dm_args, "-mon");
-    flexarray_append(dm_args, "chardev=libxenstat-cmd,mode=control");
+        flexarray_append(dm_args, "-mon");
+        flexarray_append(dm_args, "chardev=libxenstat-cmd,mode=control");
+    }
 
     for (i = 0; i < guest_config->num_channels; i++) {
         connection = guest_config->channels[i].connection;
@@ -1273,7 +1277,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
         flexarray_vappend(dm_args, "-name", c_info->name, NULL);
     }
 
-    if (vnc) {
+    if (vnc && !is_stubdom) {
         char *vncarg = NULL;
 
         flexarray_append(dm_args, "-vnc");
@@ -1312,7 +1316,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
         }
 
         flexarray_append(dm_args, vncarg);
-    } else
+    } else if (!is_stubdom)
         /*
          * Ensure that by default no vnc server is created.
          */
@@ -1324,7 +1328,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
      */
     flexarray_append_pair(dm_args, "-display", "none");
 
-    if (sdl) {
+    if (sdl && !is_stubdom) {
         flexarray_append(dm_args, "-sdl");
         if (sdl->display)
             flexarray_append_pair(dm_envs, "DISPLAY", sdl->display);
@@ -1366,18 +1370,34 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
             {
                 LOGD(ERROR, guest_domid, "Both serial and serial_list set");
                 return ERROR_INVAL;
-            }
-            if (b_info->u.hvm.serial) {
-                flexarray_vappend(dm_args,
-                                  "-serial", b_info->u.hvm.serial, NULL);
-            } else if (b_info->u.hvm.serial_list) {
-                char **p;
-                for (p = b_info->u.hvm.serial_list;
-                     *p;
-                     p++) {
-                    flexarray_vappend(dm_args,
-                                      "-serial",
-                                      *p, NULL);
+            } else {
+                if (b_info->u.hvm.serial) {
+                    if (is_stubdom) {
+                        /* see spawn_stub_launch_dm() for connecting STUBDOM_CONSOLE_SERIAL */
+                        flexarray_vappend(dm_args,
+                                          "-serial",
+                                          GCSPRINTF("/dev/hvc%d", STUBDOM_CONSOLE_SERIAL),
+                                          NULL);
+                    } else {
+                        flexarray_vappend(dm_args,
+                                          "-serial", b_info->u.hvm.serial, NULL);
+                    }
+                } else if (b_info->u.hvm.serial_list) {
+                    char **p;
+                    /* see spawn_stub_launch_dm() for connecting STUBDOM_CONSOLE_SERIAL */
+                    for (p = b_info->u.hvm.serial_list, i = 0;
+                         *p;
+                         p++, i++) {
+                        if (is_stubdom)
+                            flexarray_vappend(dm_args,
+                                              "-serial",
+                                              GCSPRINTF("/dev/hvc%d", STUBDOM_CONSOLE_SERIAL + i),
+                                              NULL);
+                        else
+                            flexarray_vappend(dm_args,
+                                              "-serial",
+                                              *p, NULL);
+                    }
                 }
             }
         }
@@ -1386,7 +1406,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
             flexarray_append(dm_args, "-nographic");
         }
 
-        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable) && !is_stubdom) {
             const libxl_spice_info *spice = &b_info->u.hvm.spice;
             char *spiceoptions = dm_spice_options(gc, spice);
             if (!spiceoptions)
@@ -1813,7 +1833,9 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
              * If qemu isn't doing the interpreting, the parameter is
              * always raw
              */
-            if (disks[i].backend == LIBXL_DISK_BACKEND_QDISK)
+            if (libxl_defbool_val(b_info->device_model_stubdomain))
+                format = "host_device";
+            else if (disks[i].backend == LIBXL_DISK_BACKEND_QDISK)
                 format = libxl__qemu_disk_format_string(disks[i].format);
             else
                 format = libxl__qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
@@ -1824,6 +1846,16 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
                          disks[i].vdev);
                     continue;
                 }
+            } else if (libxl_defbool_val(b_info->device_model_stubdomain)) {
+                if (disk > 'z' - 'a') {
+                    LOGD(WARN, guest_domid,
+                            "Emulation of only first %d disks is supported with qemu-xen in stubdomain.\n"
+                            "Disk %d will be available via PV drivers but not as an emulated disk.",
+                            'z' - 'a',
+                            disk);
+                    continue;
+                }
+                target_path = GCSPRINTF("/dev/xvd%c", 'a' + disk);
             } else {
                 if (format == NULL) {
                     LOGD(WARN, guest_domid,
@@ -1964,7 +1996,7 @@ static int libxl__build_device_model_args(libxl__gc *gc,
                                         char ***args, char ***envs,
                                         const libxl__domain_build_state *state,
                                         int *dm_state_fd)
-/* dm_state_fd may be NULL iff caller knows we are using old stubdom
+/* dm_state_fd may be NULL iff caller knows we are using stubdom
  * and therefore will be passing a filename rather than a fd. */
 {
     switch (guest_config->b_info.device_model_version) {
@@ -1974,8 +2006,10 @@ static int libxl__build_device_model_args(libxl__gc *gc,
                                                   args, envs,
                                                   state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        assert(dm_state_fd != NULL);
-        assert(*dm_state_fd < 0);
+        if (!libxl_defbool_val(guest_config->b_info.device_model_stubdomain)) {
+            assert(dm_state_fd != NULL);
+            assert(*dm_state_fd < 0);
+	}
         return libxl__build_device_model_args_new(gc, dm,
                                                   guest_domid, guest_config,
                                                   args, envs,
@@ -2080,6 +2114,16 @@ retry_transaction:
     return 0;
 }
 
+static int libxl__store_libxl_entry(libxl__gc *gc, uint32_t domid,
+                                    const char *name, const char *value)
+{
+    char *path = NULL;
+
+    path = libxl__xs_libxl_path(gc, domid);
+    path = libxl__sprintf(gc, "%s/%s", path, name);
+    return libxl__xs_printf(gc, XBT_NULL, path, "%s", value);
+}
+
 static void dmss_init(libxl__dm_spawn_state *dmss)
 {
     libxl__ev_qmp_init(&dmss->qmp);
@@ -2138,10 +2182,14 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
     dmss_init(&sdss->pvqemu);
     libxl__xswait_init(&sdss->xswait);
 
-    if (guest_config->b_info.device_model_version !=
-        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
-        ret = ERROR_INVAL;
-        goto out;
+    assert(libxl_defbool_val(guest_config->b_info.device_model_stubdomain));
+
+    if (libxl__stubdomain_is_linux(&guest_config->b_info)) {
+        if (d_state->saved_state) {
+            LOG(ERROR, "Save/Restore not supported yet with Linux Stubdom.");
+            ret = -1;
+            goto out;
+        }
     }
 
     sdss->pvqemu.guest_domid = INVALID_DOMID;
@@ -2163,8 +2211,8 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
 
     dm_config->b_info.shadow_memkb = 0;
     dm_config->b_info.max_vcpus = 1;
-    dm_config->b_info.max_memkb = 28 * 1024 +
-        guest_config->b_info.video_memkb;
+    dm_config->b_info.max_memkb = guest_config->b_info.stubdomain_memkb;
+    dm_config->b_info.max_memkb += guest_config->b_info.video_memkb;
     dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
 
     dm_config->b_info.max_grant_frames = guest_config->b_info.max_grant_frames;
@@ -2203,10 +2251,8 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
         dm_config->num_vkbs = 1;
     }
 
-    stubdom_state->pv_kernel.path
-        = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
-    stubdom_state->pv_cmdline = GCSPRINTF(" -d %d", guest_domid);
-    stubdom_state->pv_ramdisk.path = "";
+    stubdom_state->pv_kernel.path = guest_config->b_info.stubdomain_kernel;
+    stubdom_state->pv_ramdisk.path = guest_config->b_info.stubdomain_ramdisk;
 
     /* fixme: this function can leak the stubdom if it fails */
     ret = libxl__domain_make(gc, dm_config, stubdom_state,
@@ -2226,6 +2272,8 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
         goto out;
     }
 
+    libxl__store_libxl_entry(gc, guest_domid, "dm-version",
+        libxl_device_model_version_to_string(dm_config->b_info.device_model_version));
     libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args);
     libxl__xs_printf(gc, XBT_NULL,
                      GCSPRINTF("%s/image/device-model-domid",
@@ -2235,6 +2283,15 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
                      GCSPRINTF("%s/target",
                                libxl__xs_get_dompath(gc, dm_domid)),
                      "%d", guest_domid);
+    if (guest_config->b_info.device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+        /* qemu-xen is used as a dm in the stubdomain, so we set the bios
+         * accroding to this */
+        libxl__xs_printf(gc, XBT_NULL,
+                        libxl__sprintf(gc, "%s/hvmloader/bios",
+                                       libxl__xs_get_dompath(gc, guest_domid)),
+                        "%s",
+                        libxl_bios_type_to_string(guest_config->b_info.u.hvm.bios));
+    }
     ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid);
     if (ret<0) {
         LOGED(ERROR, guest_domid, "setting target domain %d -> %d",
@@ -2316,6 +2373,11 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
 
     if (guest_config->b_info.u.hvm.serial)
         num_console++;
+    else if (guest_config->b_info.u.hvm.serial_list) {
+        char **serial = guest_config->b_info.u.hvm.serial_list;
+        while (*(serial++))
+            num_console++;
+    }
 
     console = libxl__calloc(gc, num_console, sizeof(libxl__device_console));
 
@@ -2349,8 +2411,18 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
                     console[i].output =
                         GCSPRINTF("pipe:%s", d_state->saved_state);
                 break;
+            case STUBDOM_CONSOLE_SERIAL:
+                if (guest_config->b_info.u.hvm.serial) {
+                    console[i].output = guest_config->b_info.u.hvm.serial;
+                    break;
+                }
+                /* fall-through */
             default:
-                console[i].output = "pty";
+                /* Serial_list is set, as otherwise num_consoles would be
+                 * smaller and consoles 0-2 are handled above. */
+                assert(guest_config->b_info.u.hvm.serial_list);
+                console[i].output = guest_config->b_info.u.hvm.serial_list[
+                    i-STUBDOM_CONSOLE_SERIAL];
                 break;
         }
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ebbf926897..a8f0eed945 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -119,6 +119,7 @@
 #define STUBDOM_CONSOLE_RESTORE 2
 #define STUBDOM_CONSOLE_SERIAL 3
 #define STUBDOM_SPECIAL_CONSOLES 3
+#define LIBXL_LINUX_STUBDOM_MEM 128
 #define TAP_DEVICE_SUFFIX "-emu"
 #define DOMID_XS_PATH "domid"
 #define PVSHIM_BASENAME "xen-shim"
diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
index bc7b95aa74..e52a9624ea 100644
--- a/tools/libxl/libxl_mem.c
+++ b/tools/libxl/libxl_mem.c
@@ -459,8 +459,10 @@ int libxl__domain_need_memory_calculate(libxl__gc *gc,
     case LIBXL_DOMAIN_TYPE_PVH:
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += LIBXL_HVM_EXTRA_MEMORY;
-        if (libxl_defbool_val(b_info->device_model_stubdomain))
-            *need_memkb += 32 * 1024;
+        if (libxl_defbool_val(b_info->device_model_stubdomain)) {
+            *need_memkb += b_info->stubdomain_memkb;
+            *need_memkb += b_info->video_memkb;
+        }
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         *need_memkb += LIBXL_PV_EXTRA_MEMORY;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7c473be74..9d3f05f399 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -518,6 +518,9 @@ libxl_domain_build_info = Struct("domain_build_info",[
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
+    ("stubdomain_memkb",   MemKB),
+    ("stubdomain_kernel",  string),
+    ("stubdomain_ramdisk", string),
     # if you set device_model you must set device_model_version too
     ("device_model",     string),
     ("device_model_ssidref", uint32),
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:05:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:05:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVM-0000Vl-Sg; Tue, 28 Apr 2020 04:05:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVM-0000VL-1W
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:05:56 +0000
X-Inumbo-ID: 8b13d8fe-8905-11ea-ae69-bc764e2007e4
Received: from mail-qk1-x741.google.com (unknown [2607:f8b0:4864:20::741])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8b13d8fe-8905-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:49 +0000 (UTC)
Received: by mail-qk1-x741.google.com with SMTP id o135so8118574qke.6
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=Yoxvi6Fn0hUGtZXkSZVhDlRzjiYf6QAuf1u1v/s9kVg=;
 b=nyhTvCVteicwBRfml1F/1X9SEKlXDcf0mV1eQmWK1EqABYdVryIuvIWhhsMnu5K8of
 64/qp10xpdfNjGbCJcC6a/ZI0NNTRp/HpMHeDJSA5yWtbxof6Sf4Kj4XIQVpwLp9Xjli
 cM1Gi+DnVw7F46KsqUWwf85COaMdI8069FpwngO4fqJeU+qCSFJcL+Pmn6r62xRAjQqs
 YFDZ11NJviyEcUU5DT/tjhWei5q5aecQViZxokdThfy9tWrMOWwZ7Kspgf51XIyKpMWX
 tnp2PAMeJygPKGOo394xbhwcy4PNrRH06cN9toIFuKguFiPYAwP3Fk5726zETIIH92nM
 OAig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=Yoxvi6Fn0hUGtZXkSZVhDlRzjiYf6QAuf1u1v/s9kVg=;
 b=YClyXe6Zo0d5pmPf5CdWeciYWELbBrw+DyEc0lk/dJyS6FAYdetAtkSQUk9KcSX1U1
 8G9jyi5f51vIoPAJYEf+y+9z8Suz6Rfu7XqGhagKsScEYWSkkhVq1WhNN2EGvJ4T3rKa
 mGkjtat0igr98ZfnNg5/xFtldWvFl92T/WI5dNLCAuik08jps2rSRf1Ywwu5JnrDHSIL
 cbQq5d7JA0eivxOBF0SonCIb1Pw11SvFWAfba2xCYK6CrzKP6CprTUtFV7NenboYps4l
 8UpMDYkjmxOFmKvPqC1tOOE/jz46ZjkK4zRPut4mb+swknJ7rPHYdvqR09+9aSF1aqGW
 VkbA==
X-Gm-Message-State: AGi0PuZrHIehQLGkfA2K1s+/QzwDPEMHoAZ5KSWBYV/vFR3CVM92M/iU
 SQvpQgVe4GGu6dOae3RBncVi4NcN
X-Google-Smtp-Source: APiQypLZoo0Q1RhuT991ZsJO2xnFOfB8H+6LeffSoO1ivN3ZzIMZHQ8XBInLAOiRw0Wm6TYx5CCiFw==
X-Received: by 2002:a37:6594:: with SMTP id z142mr25445572qkb.55.1588046748320; 
 Mon, 27 Apr 2020 21:05:48 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:47 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 06/21] libxl: write qemu arguments into separate xenstore
 keys
Date: Tue, 28 Apr 2020 00:04:18 -0400
Message-Id: <20200428040433.23504-7-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

This allows using arguments with spaces, like -append, without
nominating any special "separator" character.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
Changes in v3:
 - previous version of this patch "libxl: use \x1b to separate qemu
   arguments for linux stubdomain" used specific non-printable
   separator, but it was rejected as xenstore doesn't cope well with
   non-printable chars
---
 tools/libxl/libxl_dm.c | 39 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5a7d55686f..bdc23554eb 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2065,6 +2065,40 @@ static int libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc *gc,
     return 0;
 }
 
+static int libxl__write_stub_linux_dmargs(libxl__gc *gc,
+                                    int dm_domid, int guest_domid,
+                                    char **args)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int i;
+    char *vm_path;
+    char *path;
+    struct xs_permissions roperm[2];
+    xs_transaction_t t;
+
+    roperm[0].id = 0;
+    roperm[0].perms = XS_PERM_NONE;
+    roperm[1].id = dm_domid;
+    roperm[1].perms = XS_PERM_READ;
+
+    vm_path = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("/local/domain/%d/vm", guest_domid));
+    path = GCSPRINTF("%s/image/dmargs", vm_path);
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    xs_write(ctx->xsh, t, path, "", 0);
+    xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
+    i = 1;
+    for (i=1; args[i] != NULL; i++)
+        xs_write(ctx->xsh, t, GCSPRINTF("%s/%03d", path, i), args[i], strlen(args[i]));
+
+    xs_set_permissions(ctx->xsh, t, GCSPRINTF("%s/rtc/timeoffset", vm_path), roperm, ARRAY_SIZE(roperm));
+    if (!xs_transaction_end(ctx->xsh, t, 0))
+        if (errno == EAGAIN)
+            goto retry_transaction;
+    return 0;
+}
+
 static int libxl__write_stub_dmargs(libxl__gc *gc,
                                     int dm_domid, int guest_domid,
                                     char **args)
@@ -2274,7 +2308,10 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
 
     libxl__store_libxl_entry(gc, guest_domid, "dm-version",
         libxl_device_model_version_to_string(dm_config->b_info.device_model_version));
-    libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args);
+    if (libxl__stubdomain_is_linux(&guest_config->b_info))
+        libxl__write_stub_linux_dmargs(gc, dm_domid, guest_domid, args);
+    else
+        libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args);
     libxl__xs_printf(gc, XBT_NULL,
                      GCSPRINTF("%s/image/device-model-domid",
                                libxl__xs_get_dompath(gc, guest_domid)),
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVS-0000Yo-5r; Tue, 28 Apr 2020 04:06:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVR-0000Y3-1j
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:01 +0000
X-Inumbo-ID: 8ce4326e-8905-11ea-9887-bc764e2007e4
Received: from mail-qk1-x741.google.com (unknown [2607:f8b0:4864:20::741])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8ce4326e-8905-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:52 +0000 (UTC)
Received: by mail-qk1-x741.google.com with SMTP id l78so20535005qke.7
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=ScCYPQwHljuvh1NyG9qLCW4etudB53sNPzGGuSEsg5E=;
 b=DD8dKbE2UyuORRV4e6/jwNd1KZZCUDLQzDSt56sCVNhtvNq/JNdETGi9a0zmgy+4v6
 51xv70N0uBsYFjgyxXLnoSwdN0Dm3W6YJwojBumX6l2lcWloZhYl8jDe5U/ym3oiAM/o
 V+aSGC3FrQnDdJPjs4MhwJekCGUqZk7oRQbPZXRpAKoYMQouUAqmGXaPZqv3pmcvdAC9
 gYayFUrcN2KjqpbCSVGS3xtqxjvIj/RI6M5IY/N+WmVvrirRdi1XB+lpF2EDqUTR8ahc
 yaitGp2AqxkbzD80sDStZcO5iWFnzTglhehiY1FbpdhW6Pd1xk+BkAoBtc3Xyy7NQbeI
 1IQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=ScCYPQwHljuvh1NyG9qLCW4etudB53sNPzGGuSEsg5E=;
 b=V7DWXszAsAfWJ9jGYmzRvowVMFjFgIMk/djDKAJkzO7aZ6tyT5v8BZJkrHhP0BcZDw
 1fmEHS3fVLDyrMf9RRfMXe8VWlkR02OnPT+3K3/DK91ezyg1xvrE/wKRiXpclvDjkXTj
 OkDRJDh42/EowSW1l7rc5jG3bT3WFZPQP+JO46T/Ro/r4bXNU3IHtI17LZOlFt2PhpV/
 21Rp5oH8rtEeY9JJug1lL6AypCo101O0V6K2GYlgcbddnmy8gc5pUg2a/Uemo/wCMHMb
 Ph70qUJXTy2l8sfHIXnyck655GAE5go++1UCMxA17V4p1RDFzDKZURzNhScVp/DiToyn
 xOLA==
X-Gm-Message-State: AGi0Pua53Sqk1urZyBWdcYC474RkTryTMJZe8kYIqiuP/+ogw/+YOeFo
 u1dYxS5neatVxgGFBkHn91EdufnE
X-Google-Smtp-Source: APiQypLQj+SpdbcefmCI0JV61LJufloBhRsV9i3XEZ3SYaTXit5sr4pE9fwesQz6rYAUnf+MDR7hVw==
X-Received: by 2002:a37:d93:: with SMTP id 141mr26036151qkn.32.1588046751337; 
 Mon, 27 Apr 2020 21:05:51 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:50 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 07/21] xl: add stubdomain related options to xl config
 parser
Date: Tue, 28 Apr 2020 00:04:19 -0400
Message-Id: <20200428040433.23504-8-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 docs/man/xl.cfg.5.pod.in | 27 +++++++++++++++++++++++----
 tools/xl/xl_parse.c      |  7 +++++++
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 0e9e58a41a..c9bc181a95 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2733,10 +2733,29 @@ model which they were installed with.
 
 =item B<device_model_override="PATH">
 
-Override the path to the binary to be used as the device-model. The
-binary provided here MUST be consistent with the
-B<device_model_version> which you have specified. You should not
-normally need to specify this option.
+Override the path to the binary to be used as the device-model running in
+toolstack domain. The binary provided here MUST be consistent with the
+B<device_model_version> which you have specified. You should not normally need
+to specify this option.
+
+=item B<stubdomain_kernel="PATH">
+
+Override the path to the kernel image used as device-model stubdomain.
+The binary provided here MUST be consistent with the
+B<device_model_version> which you have specified.
+In case of B<qemu-xen-traditional> it is expected to be MiniOS-based stubdomain
+image, in case of B<qemu-xen> it is expected to be Linux-based stubdomain
+kernel.
+
+=item B<stubdomain_ramdisk="PATH">
+
+Override the path to the ramdisk image used as device-model stubdomain.
+The binary provided here is to be used by a kernel pointed by B<stubdomain_kernel>.
+It is known to be used only by Linux-based stubdomain kernel.
+
+=item B<stubdomain_memory=MBYTES>
+
+Start the stubdomain with MBYTES megabytes of RAM. Default is 128.
 
 =item B<device_model_stubdomain_override=BOOLEAN>
 
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 4450d59f16..61b4ef7b7e 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2525,6 +2525,13 @@ skip_usbdev:
     xlu_cfg_replace_string(config, "device_model_user",
                            &b_info->device_model_user, 0);
 
+    xlu_cfg_replace_string (config, "stubdomain_kernel",
+                            &b_info->stubdomain_kernel, 0);
+    xlu_cfg_replace_string (config, "stubdomain_ramdisk",
+                            &b_info->stubdomain_ramdisk, 0);
+    if (!xlu_cfg_get_long (config, "stubdomain_memory", &l, 0))
+        b_info->stubdomain_memkb = l * 1024;
+
 #define parse_extra_args(type)                                            \
     e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
                                     &b_info->extra##type, 0);            \
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVX-0000cR-Gb; Tue, 28 Apr 2020 04:06:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVW-0000bQ-1q
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:06 +0000
X-Inumbo-ID: 8f39d6e0-8905-11ea-9887-bc764e2007e4
Received: from mail-qt1-x844.google.com (unknown [2607:f8b0:4864:20::844])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8f39d6e0-8905-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:55 +0000 (UTC)
Received: by mail-qt1-x844.google.com with SMTP id e17so12875241qtp.7
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=Cw7c/W+2mWKsQFqee8I2XqBHCRi5cVGdl4h/Cw+zkCI=;
 b=deeKyblR46LgGqs9LOHt2LrBIUW7UhBvbPlNksDocNlNzNQXfU0IRiWcxIj4fzHDvq
 +ZnbUyKwrkSubIidY3mhQDZ7mYKBnwLDbllr1DULYmbPtMCDo4mY07K2NFekai+aq1W0
 DuNJPDKdvX3hGjbdZSQ5ThdLfj5jsgmJb12UCM7+FTU8KxoeJYdSlHVzN+5+MmmJUWTE
 +PHzKolEnL61VD9ofKDuF3nJpdlHSD9oG4378SrNombZBkv8nn181IGhqHdS38Cqdr5N
 1cB52mtMUP4/+P/hO0ZwmiLsd5QdJB8ivXvVD877DJUYBr5KI3GVTe4csXLB0gWdRTn6
 F+Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=Cw7c/W+2mWKsQFqee8I2XqBHCRi5cVGdl4h/Cw+zkCI=;
 b=FJdY94niJoIiLt54dQeyOVAIoWGwSoKwrTBEHMABJh8sjivSNeI6GLHJFLquf4BZbu
 Auof7MJnuPDNmshiNrJg1E1fFMYNwwVf8vxqJzHFytfnoUz53goDVFb9k9tOvPIvkUbu
 HTs093ilWoayBzwv0r8r519otfM3sA9DLj4O7qrYk0cKDwQC4z6Rj2svOM3UxLG+6G/w
 Mvf0NvfD668pmzhQ5njazHTMUilXEojaKmzXJhxEOt2IFodG0tpL1t6F0mqkdbl3PimG
 N4PXJ0gcxSSu1be5YSOXG9A3tbQpcnEft7WzNl6JdRLhJeJLiELnhM3gp0lZL0cWv59e
 x+iA==
X-Gm-Message-State: AGi0PuZWkCkkAk/cgYatK25CUBviJhi1HLmRboPQVzUtihoCToCkMkmz
 ngufZnZcpkJkTO8X+eSZh+/++vnd
X-Google-Smtp-Source: APiQypJehUmb9f9TUjkaI9CqrTXfXqqf+UmnSUDU0BrdPRFrcHyxJvAdCWseTeNJ8YwjyqRJyeHMug==
X-Received: by 2002:ac8:4757:: with SMTP id k23mr26167284qtp.206.1588046755362; 
 Mon, 27 Apr 2020 21:05:55 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:54 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 08/21] tools/libvchan: notify server when client is
 connected
Date: Tue, 28 Apr 2020 00:04:20 -0400
Message-Id: <20200428040433.23504-9-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Let the server know when the client is connected. Otherwise server will
notice only when client send some data.
This change does not break existing clients, as libvchan user should
handle spurious notifications anyway (for example acknowledge of remote
side reading the data).

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Replace spaces with tabs to match the file's whitespace.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
Marek: I had this patch in Qubes for a long time and totally forgot it
wasn't upstream thing...
---
 tools/libvchan/init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
index 180833dc2f..ad4b64fbe3 100644
--- a/tools/libvchan/init.c
+++ b/tools/libvchan/init.c
@@ -447,6 +447,9 @@ struct libxenvchan *libxenvchan_client_init(struct xentoollog_logger *logger,
 	ctrl->ring->cli_live = 1;
 	ctrl->ring->srv_notify = VCHAN_NOTIFY_WRITE;
 
+	/* wake up the server */
+	xenevtchn_notify(ctrl->event, ctrl->event_port);
+
  out:
 	if (xs)
 		xs_daemon_close(xs);
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVb-0000fi-QU; Tue, 28 Apr 2020 04:06:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVb-0000fA-1x
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:11 +0000
X-Inumbo-ID: 913a2be8-8905-11ea-ae69-bc764e2007e4
Received: from mail-qt1-x844.google.com (unknown [2607:f8b0:4864:20::844])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 913a2be8-8905-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 04:05:59 +0000 (UTC)
Received: by mail-qt1-x844.google.com with SMTP id 71so16251513qtc.12
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:05:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=qv1Q9DnV7+kaRXi7fO8SZeqk2BXV8QqwlY5OCm77OCE=;
 b=L4eAre5KFeI+b0nlRSuCm1sXm4alzuHrtT3B0Zeyr1sS1JAWrnwaQkU4+PXdx/h6ZA
 BiR6WDA7iQX+M9iZ+zmaz4IGNTCCpIIz4cYNzx/5sIDbnaYHzKr3Qsc5aI7wh68WyN72
 y98te83uayOpg3jKH1nqTfnYV6HOrHmWPez7jQr8U4mqVkrCtbfM8nobljR/FK7Fpr9V
 nGQTRbit091mV3Bm+OGokCvMoqGjkL2PaaJF99dWa9qF1nyAKNtapYUS2DX7B8MJmC9M
 MfsQf+gWb8hMh8PFMn7gN8smG0KLt+WwOYWTs3MF2hM16w6Ivdu3nZXSpp/mBSAy5CLR
 oDsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=qv1Q9DnV7+kaRXi7fO8SZeqk2BXV8QqwlY5OCm77OCE=;
 b=YGp8vaDP9D2BDhcCbyclr3PlifvQz/h5tpqvVzQv4fZlUqh9Hgy1pvs1rW6st5nuUq
 d52DFGSIDU0mtMfwN1T9XQA4RsmfzpPnK99byhQ/Sy4oZ2o9aZ6OoY6veqsK2gR1E6zi
 Ho5k2mg24et/gTLz4xHOjvszTtyk9UIgwSkEfSaENoeA1+eUE0jTUfwFwZjwjMWloug2
 F8hqkIIHJPUSlzFglsg9zYJLBsaFdP8/n7Y7RoqpcMSdZYaLPHSDVLQ1FqPEU10A8sio
 foImfmgVAolyDYkEX1O7vQoJbyGAn0EfXKB8qaLhFw59OnLcNlKCjo7qYD+ewa/hJAPE
 JUuw==
X-Gm-Message-State: AGi0PubOUnfcVdQgDB1PonECXz1Ge6vv/QsASPVGqhVXWM/KAfreoZU6
 deLnTSyXHik2ZySEKfPTWY7tL8iH
X-Google-Smtp-Source: APiQypKQwAKlZIZvCmo9Y3whpXQpmhBwZR7/XpW/aL14R/yGGmP1n+QQPTCC3GBNPRQJFnzcvzvkYQ==
X-Received: by 2002:ac8:4a06:: with SMTP id x6mr27416022qtq.163.1588046758653; 
 Mon, 27 Apr 2020 21:05:58 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.05.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:05:57 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 09/21] libxl: add save/restore support for qemu-xen in
 stubdomain
Date: Tue, 28 Apr 2020 00:04:21 -0400
Message-Id: <20200428040433.23504-10-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Rely on a wrapper script in stubdomain to attach FD 3/4 of qemu to
relevant consoles.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Address TODO in dm_state_save_to_fdset: Only remove savefile for
non-stubdom.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
Changes in v3:
 - adjust for qmp_ev*
 - assume specific fdset id in qemu set in stubdomain
Changes in v5:
 - Only remove savefile for non-stubdom
---
 tools/libxl/libxl_dm.c  | 23 +++++++++++------------
 tools/libxl/libxl_qmp.c | 27 +++++++++++++++++++++++++--
 2 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bdc23554eb..45d0dd56f5 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1744,10 +1744,17 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
     }
 
     if (state->saved_state) {
-        /* This file descriptor is meant to be used by QEMU */
-        *dm_state_fd = open(state->saved_state, O_RDONLY);
-        flexarray_append(dm_args, "-incoming");
-        flexarray_append(dm_args, GCSPRINTF("fd:%d",*dm_state_fd));
+        if (is_stubdom) {
+            /* Linux stubdomain connects specific FD to STUBDOM_CONSOLE_RESTORE
+             */
+            flexarray_append(dm_args, "-incoming");
+            flexarray_append(dm_args, "fd:3");
+        } else {
+            /* This file descriptor is meant to be used by QEMU */
+            *dm_state_fd = open(state->saved_state, O_RDONLY);
+            flexarray_append(dm_args, "-incoming");
+            flexarray_append(dm_args, GCSPRINTF("fd:%d",*dm_state_fd));
+        }
     }
     for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
         flexarray_append(dm_args, b_info->extra[i]);
@@ -2218,14 +2225,6 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
 
     assert(libxl_defbool_val(guest_config->b_info.device_model_stubdomain));
 
-    if (libxl__stubdomain_is_linux(&guest_config->b_info)) {
-        if (d_state->saved_state) {
-            LOG(ERROR, "Save/Restore not supported yet with Linux Stubdom.");
-            ret = -1;
-            goto out;
-        }
-    }
-
     sdss->pvqemu.guest_domid = INVALID_DOMID;
 
     libxl_domain_create_info_init(&dm_config->c_info);
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index efaba91086..c394000ea9 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -962,6 +962,7 @@ static void dm_stopped(libxl__egc *egc, libxl__ev_qmp *ev,
                        const libxl__json_object *response, int rc);
 static void dm_state_fd_ready(libxl__egc *egc, libxl__ev_qmp *ev,
                               const libxl__json_object *response, int rc);
+static void dm_state_save_to_fdset(libxl__egc *egc, libxl__ev_qmp *ev, int fdset);
 static void dm_state_saved(libxl__egc *egc, libxl__ev_qmp *ev,
                            const libxl__json_object *response, int rc);
 
@@ -994,10 +995,17 @@ static void dm_stopped(libxl__egc *egc, libxl__ev_qmp *ev,
     EGC_GC;
     libxl__domain_suspend_state *dsps = CONTAINER_OF(ev, *dsps, qmp);
     const char *const filename = dsps->dm_savefile;
+    uint32_t dm_domid = libxl_get_stubdom_id(CTX, dsps->domid);
 
     if (rc)
         goto error;
 
+    if (dm_domid) {
+        /* see Linux stubdom interface in docs/stubdom.txt */
+        dm_state_save_to_fdset(egc, ev, 1);
+        return;
+    }
+
     ev->payload_fd = open(filename, O_WRONLY | O_CREAT, 0600);
     if (ev->payload_fd < 0) {
         LOGED(ERROR, ev->domid,
@@ -1028,7 +1036,6 @@ static void dm_state_fd_ready(libxl__egc *egc, libxl__ev_qmp *ev,
     EGC_GC;
     int fdset;
     const libxl__json_object *o;
-    libxl__json_object *args = NULL;
     libxl__domain_suspend_state *dsps = CONTAINER_OF(ev, *dsps, qmp);
 
     close(ev->payload_fd);
@@ -1043,6 +1050,21 @@ static void dm_state_fd_ready(libxl__egc *egc, libxl__ev_qmp *ev,
         goto error;
     }
     fdset = libxl__json_object_get_integer(o);
+    dm_state_save_to_fdset(egc, ev, fdset);
+    return;
+
+error:
+    assert(rc);
+    libxl__remove_file(gc, dsps->dm_savefile);
+    dsps->callback_device_model_done(egc, dsps, rc);
+}
+
+static void dm_state_save_to_fdset(libxl__egc *egc, libxl__ev_qmp *ev, int fdset)
+{
+    EGC_GC;
+    int rc;
+    libxl__json_object *args = NULL;
+    libxl__domain_suspend_state *dsps = CONTAINER_OF(ev, *dsps, qmp);
 
     ev->callback = dm_state_saved;
 
@@ -1060,7 +1082,8 @@ static void dm_state_fd_ready(libxl__egc *egc, libxl__ev_qmp *ev,
 
 error:
     assert(rc);
-    libxl__remove_file(gc, dsps->dm_savefile);
+    if (!libxl_get_stubdom_id(CTX, dsps->domid))
+        libxl__remove_file(gc, dsps->dm_savefile);
     dsps->callback_device_model_done(egc, dsps, rc);
 }
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVh-0000jX-3o; Tue, 28 Apr 2020 04:06:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVg-0000it-1v
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:16 +0000
X-Inumbo-ID: 92d151c0-8905-11ea-ae69-bc764e2007e4
Received: from mail-qv1-xf41.google.com (unknown [2607:f8b0:4864:20::f41])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 92d151c0-8905-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:01 +0000 (UTC)
Received: by mail-qv1-xf41.google.com with SMTP id v38so9754348qvf.6
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=Arrq//I+mnu3nWRhCeF/WBnbP/Hq+npxYP1a8HiQr4M=;
 b=hZfZ4crkIQkgZ0ilyZj7UayWCfCwD+E4gTg95iTtvNGHVCXBpP6JO+EKbfFAtbur5/
 XMrybm1+PWaWtIxOHwg9ezkODI7gtMF+TRNy8bsmHT+5fOxh0Z0WbGbVLUnjUbWsUg0X
 on3C8KGJlx3lJvEEJGeqIg9nZptVUuQ1gqM6kHFBOeDXexsHcffQQ5lseJF3DZnot1nx
 PwDAxQyDm2bHa4n5OeUgI3eTvGIsiAO4HMGMzPO4TFsDmq0vsVmLDFEmUQe8EEPA+qrT
 FXYnrF1Y5Ers0Vm4oLNZck/PgVHoN/hGxQ50IXLmRrFxtyxeRSs8hyuV5zZKN1GAbsJL
 ffrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=Arrq//I+mnu3nWRhCeF/WBnbP/Hq+npxYP1a8HiQr4M=;
 b=YS36gTsCkhzUJPT900QzpDX3jxC5geWVUSLaljhTQac2Sv/HBzdsAc+xff+4oXxBIg
 cD1angYxLzn95GzAOdzrtez8239dnQnLX8srek786iuiUKPSDuPWZIM3ASddYFtJBgTZ
 OK9cYKP8Vuy0+oPGOxdsiaT/P+1iafZWdCKo0Ytq2qPzfkc+xaj52VvLS1NW2BSC0Ref
 Etm3YUifqnlb2pwaqv/4wYfwo6WCHUeMRJR3hIhwgfhdRBEvI+QI/bLSJSIXlct7SgIp
 /k0KHInXEJ3gGI88ECmlA9o4r3ZmEZOSTaqPw11x53nCqsHDDlRel+dRrBz8tfFpZxUT
 iGTg==
X-Gm-Message-State: AGi0PuanxHEss2z2iuai4v0F2sMLSxBgV/voNRUy6aKxUM1EYkI9e3o7
 UqmM00eBta5ns/OziRAB6ZBYiuva
X-Google-Smtp-Source: APiQypJSQIX/p45NGmrU9FSEZUsYzvUfUxsQE748u+PA4e1GlPc+Pgs202mVFF7tbxjemvGsvyfuHA==
X-Received: by 2002:a0c:dd8c:: with SMTP id v12mr25165846qvk.134.1588046761385; 
 Mon, 27 Apr 2020 21:06:01 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:00 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 10/21] tools: add missing libxenvchan cflags
Date: Tue, 28 Apr 2020 00:04:22 -0400
Message-Id: <20200428040433.23504-11-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

libxenvchan.h include xenevtchn.h and xengnttab.h, so applications built
with it needs applicable -I in CFLAGS too.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 tools/Rules.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 9bac15c8d1..078eb7230a 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -159,7 +159,7 @@ SHDEPS_libxenstat  = $(SHLIB_libxenctrl) $(SHLIB_libxenstore)
 LDLIBS_libxenstat  = $(SHDEPS_libxenstat) $(XEN_LIBXENSTAT)/libxenstat$(libextension)
 SHLIB_libxenstat   = $(SHDEPS_libxenstat) -Wl,-rpath-link=$(XEN_LIBXENSTAT)
 
-CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN)
+CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) $(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn)
 SHDEPS_libxenvchan = $(SHLIB_libxentoollog) $(SHLIB_libxenstore) $(SHLIB_libxenevtchn) $(SHLIB_libxengnttab)
 LDLIBS_libxenvchan = $(SHDEPS_libxenvchan) $(XEN_LIBVCHAN)/libxenvchan$(libextension)
 SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) -Wl,-rpath-link=$(XEN_LIBVCHAN)
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVm-0000nh-ID; Tue, 28 Apr 2020 04:06:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVl-0000mk-27
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:21 +0000
X-Inumbo-ID: 94dd3b14-8905-11ea-b07b-bc764e2007e4
Received: from mail-qk1-x733.google.com (unknown [2607:f8b0:4864:20::733])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 94dd3b14-8905-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:05 +0000 (UTC)
Received: by mail-qk1-x733.google.com with SMTP id b188so18961187qkd.9
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=igivI7+/HwMdigsHAPp76Z5QjR1GMgCyDtDB+aqMExI=;
 b=MV4b/bL97n6Tw0fTgrGdew4XotX04c6cNTbmA3PDXUiz4F8i8YjGA3iz0FsWmncQRF
 ybkDZYgm9yAg0k8Rsj6ii1ple/mhuVHKl2PBmt4Wo98QwfTGSqhr9/A9dJ9YrZVq/8lQ
 aKIs6NqBwV7+pZ61xsQrQ73IyVkBMrMdSyjDGTLsHpwM47QdU+PHR9XO+EnemLOrVcor
 2FT03F4VmL0Y/ajNw4W0f++S07ye3K/QZnj67FnaUQ/0kD8A8egNhaIIY/0uP9ryxjpQ
 HyxvjM7pb3dVeIjd66GKN2iyXHBNpO/zRpUri649Q87BbbFRe7iqvxVLDFOIRhGebEsU
 EYug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=igivI7+/HwMdigsHAPp76Z5QjR1GMgCyDtDB+aqMExI=;
 b=D8Rw6h1voS1F6WkN4ng13dFUfpix8tKfbdOnjgFyflYfq/ztxfBBuNv0BGWD+KPJty
 mIfBNHgRxBr9V/s9qY8lq0ep9hyP4Y9YgQ7XaO8DSQ3UfEAVOwOxebuVtoz+I/Vy1gXh
 tNFN09hXBIZKEsJgIi9MXSFCrlnDbi0CH83XbPwYG5lM26ExDh4hV3GQWslV/Mf7bJF+
 5JFR3msZJoUVy/UJwhUt6OrzcU2x4v+aH994kJVY+Ane3qr0N0VIBVS/37Yiw64X/SQD
 M6LqxeiRI2jhifqLadLAmYxcjUbPYsrsEcm7jgrtyAlBpFzorcQ9XHb1H7+Ng/tlAPnH
 uCbg==
X-Gm-Message-State: AGi0PuYtNXflx30szWF3gwTeR/Ic9JvHxDB7UM+HK+GPEHKsAzG4MCfG
 1UnBC534L/+qksc0w4u1aPpjVm9s
X-Google-Smtp-Source: APiQypKShq5B1JtltMTsAwXjnv+Qf0joWoZY07FvVc1+vt02pbOidyBwVrQ2DFfz4231atGTEYqCSQ==
X-Received: by 2002:a37:690:: with SMTP id 138mr26032733qkg.414.1588046764271; 
 Mon, 27 Apr 2020 21:06:04 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:03 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 11/21] tools: add simple vchan-socket-proxy
Date: Tue, 28 Apr 2020 00:04:23 -0400
Message-Id: <20200428040433.23504-12-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Add a simple proxy for tunneling socket connection over vchan. This is
based on existing vchan-node* applications, but extended with socket
support. vchan-socket-proxy serves both as a client and as a server,
depending on parameters. It can be used to transparently communicate
with an application in another domian that normally expose UNIX socket
interface. Specifically, it's written to communicate with qemu running
within stubdom.

Server mode listens for vchan connections and when one is opened,
connects to a pointed UNIX socket.  Client mode listens on UNIX
socket and when someone connects, opens a vchan connection.  Only
a single connection at a time is supported.

Additionally, socket can be provided as a number - in which case it's
interpreted as already open FD (in case of UNIX listening socket -
listen() needs to be already called). Or "-" meaning stdin/stdout - in
which case it is reduced to vchan-node2 functionality.

Example usage:

1. (in dom0) vchan-socket-proxy --mode=client <DOMID>
    /local/domain/<DOMID>/data/vchan/1234 /run/qemu.(DOMID)

2. (in DOMID) vchan-socket-proxy --mode=server 0
   /local/domain/<DOMID>/data/vchan/1234 /run/qemu.(DOMID)

This will listen on /run/qemu.(DOMID) in dom0 and whenever connection is
made, it will connect to DOMID, where server process will connect to
/run/qemu.(DOMID) there. When client disconnects, vchan connection is
terminated and server vchan-socket-proxy process also disconnects from
qemu.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
Changes on v5:
 - Ensure bindir directory is present
 - String and comment fixes
---
 .gitignore                          |   1 +
 tools/libvchan/Makefile             |   8 +-
 tools/libvchan/vchan-socket-proxy.c | 478 ++++++++++++++++++++++++++++
 3 files changed, 486 insertions(+), 1 deletion(-)
 create mode 100644 tools/libvchan/vchan-socket-proxy.c

diff --git a/.gitignore b/.gitignore
index 4ca679ddbc..1760e54464 100644
--- a/.gitignore
+++ b/.gitignore
@@ -368,6 +368,7 @@ tools/misc/xenwatchdogd
 tools/misc/xen-hvmcrash
 tools/misc/xen-lowmemd
 tools/libvchan/vchan-node[12]
+tools/libvchan/vchan-socket-proxy
 tools/ocaml/*/.ocamldep.make
 tools/ocaml/*/*.cm[ixao]
 tools/ocaml/*/*.cmxa
diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
index 7892750c3e..913bcc8884 100644
--- a/tools/libvchan/Makefile
+++ b/tools/libvchan/Makefile
@@ -13,6 +13,7 @@ LIBVCHAN_PIC_OBJS = $(patsubst %.o,%.opic,$(LIBVCHAN_OBJS))
 LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxengnttab) $(LDLIBS_libxenevtchn)
 $(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) $(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn)
 $(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn)
+vchan-socket-proxy.o: CFLAGS += $(CFLAGS_libxenstore) $(CFLAGS_libxenctrl) $(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn)
 
 MAJOR = 4.14
 MINOR = 0
@@ -39,7 +40,7 @@ $(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
 $(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
 
 .PHONY: all
-all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
+all: libxenvchan.so vchan-node1 vchan-node2 vchan-socket-proxy libxenvchan.a $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
 
 libxenvchan.so: libxenvchan.so.$(MAJOR)
 	ln -sf $< $@
@@ -59,13 +60,18 @@ vchan-node1: $(NODE_OBJS) libxenvchan.so
 vchan-node2: $(NODE2_OBJS) libxenvchan.so
 	$(CC) $(LDFLAGS) -o $@ $(NODE2_OBJS) $(LDLIBS_libxenvchan) $(APPEND_LDFLAGS)
 
+vchan-socket-proxy: vchan-socket-proxy.o libxenvchan.so
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenvchan) $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 .PHONY: install
 install: all
 	$(INSTALL_DIR) $(DESTDIR)$(libdir)
 	$(INSTALL_DIR) $(DESTDIR)$(includedir)
+	$(INSTALL_DIR) $(DESTDIR)$(bindir)
 	$(INSTALL_PROG) libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)
 	ln -sf libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)/libxenvchan.so.$(MAJOR)
 	ln -sf libxenvchan.so.$(MAJOR) $(DESTDIR)$(libdir)/libxenvchan.so
+	$(INSTALL_PROG) vchan-socket-proxy $(DESTDIR)$(bindir)
 	$(INSTALL_DATA) libxenvchan.h $(DESTDIR)$(includedir)
 	$(INSTALL_DATA) libxenvchan.a $(DESTDIR)$(libdir)
 	$(INSTALL_DATA) xenvchan.pc $(DESTDIR)$(PKG_INSTALLDIR)
diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c
new file mode 100644
index 0000000000..13700c5d67
--- /dev/null
+++ b/tools/libvchan/vchan-socket-proxy.c
@@ -0,0 +1,478 @@
+/**
+ * @file
+ * @section AUTHORS
+ *
+ * Copyright (C) 2010  Rafal Wojtczuk  <rafal@invisiblethingslab.com>
+ *
+ *  Authors:
+ *       Rafal Wojtczuk  <rafal@invisiblethingslab.com>
+ *       Daniel De Graaf <dgdegra@tycho.nsa.gov>
+ *       Marek Marczykowski-Górecki  <marmarek@invisiblethingslab.com>
+ *
+ * @section LICENSE
+ *
+ *  This program is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this program; If not, see <http://www.gnu.org/licenses/>.
+ *
+ * @section DESCRIPTION
+ *
+ * This is a vchan to unix socket proxy. Vchan server is set, and on client
+ * connection, local socket connection is established. Communication is bidirectional.
+ * One client is served at a time, clients needs to coordinate this themselves.
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <sys/socket.h>
+#include <sys/un.h>
+#include <getopt.h>
+
+#include <xenstore.h>
+#include <xenctrl.h>
+#include <libxenvchan.h>
+
+static void usage(char** argv)
+{
+    fprintf(stderr, "usage:\n"
+        "\t%s [options] domainid nodepath [socket-path|file-no|-]\n"
+        "\n"
+        "options:\n"
+        "\t-m, --mode=client|server - vchan connection mode (client by default)\n"
+        "\t-s, --state-path=path - xenstore path where write \"running\" to \n"
+        "\t                        at startup\n"
+        "\t-v, --verbose - verbose logging\n"
+        "\n"
+        "client: client of a vchan connection, fourth parameter can be:\n"
+        "\tsocket-path: listen on a UNIX socket at this path and connect to vchan\n"
+        "\t             whenever new connection is accepted;\n"
+        "\t             handle multiple _subsequent_ connections, until terminated\n"
+        "\n"
+        "\tfile-no:     except open FD of a socket in listen mode;\n"
+        "\t             otherwise similar to socket-path\n"
+        "\n"
+        "\t-:           open vchan connection immediately and pass the data\n"
+        "\t             from stdin/stdout; terminate when vchan connection\n"
+        "\t             is closed\n"
+        "\n"
+        "server: server of a vchan connection, fourth parameter can be:\n"
+        "\tsocket-path: connect to this UNIX socket when new vchan connection\n"
+        "\t             is accepted;\n"
+        "\t             handle multiple _subsequent_ connections, until terminated\n"
+        "\n"
+        "\tfile-no:     pass data to/from this FD; terminate when vchan connection\n"
+        "\t             is closed\n"
+        "\n"
+        "\t-:           pass data to/from stdin/stdout; terminate when vchan\n"
+        "\t             connection is closed\n",
+        argv[0]);
+    exit(1);
+}
+
+#define BUFSIZE 8192
+char inbuf[BUFSIZE];
+char outbuf[BUFSIZE];
+int insiz = 0;
+int outsiz = 0;
+int verbose = 0;
+
+static void vchan_wr(struct libxenvchan *ctrl) {
+    int ret;
+
+    if (!insiz)
+        return;
+    ret = libxenvchan_write(ctrl, inbuf, insiz);
+    if (ret < 0) {
+        fprintf(stderr, "vchan write failed\n");
+        exit(1);
+    }
+    if (verbose)
+        fprintf(stderr, "wrote %d bytes to vchan\n", ret);
+    if (ret > 0) {
+        insiz -= ret;
+        memmove(inbuf, inbuf + ret, insiz);
+    }
+}
+
+static void socket_wr(int output_fd) {
+    int ret;
+
+    if (!outsiz)
+        return;
+    ret = write(output_fd, outbuf, outsiz);
+    if (ret < 0 && errno != EAGAIN)
+        exit(1);
+    if (ret > 0) {
+        outsiz -= ret;
+        memmove(outbuf, outbuf + ret, outsiz);
+    }
+}
+
+static int set_nonblocking(int fd, int nonblocking) {
+    int flags = fcntl(fd, F_GETFL);
+    if (flags == -1)
+        return -1;
+
+    if (nonblocking)
+        flags |= O_NONBLOCK;
+    else
+        flags &= ~O_NONBLOCK;
+
+    if (fcntl(fd, F_SETFL, flags) == -1)
+        return -1;
+
+    return 0;
+}
+
+static int connect_socket(const char *path_or_fd) {
+    int fd;
+    char *endptr;
+    struct sockaddr_un addr;
+
+    fd = strtoll(path_or_fd, &endptr, 0);
+    if (*endptr == '\0') {
+        set_nonblocking(fd, 1);
+        return fd;
+    }
+
+    fd = socket(AF_UNIX, SOCK_STREAM, 0);
+    if (fd == -1)
+        return -1;
+
+    addr.sun_family = AF_UNIX;
+    strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path));
+    if (connect(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) {
+        close(fd);
+        return -1;
+    }
+
+    set_nonblocking(fd, 1);
+
+    return fd;
+}
+
+static int listen_socket(const char *path_or_fd) {
+    int fd;
+    char *endptr;
+    struct sockaddr_un addr;
+
+    fd = strtoll(path_or_fd, &endptr, 0);
+    if (*endptr == '\0') {
+        return fd;
+    }
+
+    /* if not a number, assume a socket path */
+    fd = socket(AF_UNIX, SOCK_STREAM, 0);
+    if (fd == -1)
+        return -1;
+
+    addr.sun_family = AF_UNIX;
+    strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path));
+    if (bind(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) {
+        close(fd);
+        return -1;
+    }
+    if (listen(fd, 5) != 0) {
+        close(fd);
+        return -1;
+    }
+
+    return fd;
+}
+
+static struct libxenvchan *connect_vchan(int domid, const char *path) {
+    struct libxenvchan *ctrl = NULL;
+    struct xs_handle *xs = NULL;
+    xc_interface *xc = NULL;
+    xc_dominfo_t dominfo;
+    char **watch_ret;
+    unsigned int watch_num;
+    int ret;
+
+    xs = xs_open(XS_OPEN_READONLY);
+    if (!xs) {
+        perror("xs_open");
+        goto out;
+    }
+    xc = xc_interface_open(NULL, NULL, XC_OPENFLAG_NON_REENTRANT);
+    if (!xc) {
+        perror("xc_interface_open");
+        goto out;
+    }
+    /* wait for vchan server to create *path* */
+    xs_watch(xs, path, "path");
+    xs_watch(xs, "@releaseDomain", "release");
+    while ((watch_ret = xs_read_watch(xs, &watch_num))) {
+        /* don't care about exact which fired the watch */
+        free(watch_ret);
+        ctrl = libxenvchan_client_init(NULL, domid, path);
+        if (ctrl)
+            break;
+
+        ret = xc_domain_getinfo(xc, domid, 1, &dominfo);
+        /* break the loop if domain is definitely not there anymore, but
+         * continue if it is or the call failed (like EPERM) */
+        if (ret == -1 && errno == ESRCH)
+            break;
+        if (ret == 1 && (dominfo.domid != (uint32_t)domid || dominfo.dying))
+            break;
+    }
+
+out:
+    if (xc)
+        xc_interface_close(xc);
+    if (xs)
+        xs_close(xs);
+    return ctrl;
+}
+
+
+static void discard_buffers(struct libxenvchan *ctrl) {
+    /* discard local buffers */
+    insiz = 0;
+    outsiz = 0;
+
+    /* discard remaining incoming data */
+    while (libxenvchan_data_ready(ctrl)) {
+        if (libxenvchan_read(ctrl, inbuf, BUFSIZE) == -1) {
+            perror("vchan read");
+            exit(1);
+        }
+    }
+}
+
+int data_loop(struct libxenvchan *ctrl, int input_fd, int output_fd)
+{
+    int ret;
+    int libxenvchan_fd;
+    int max_fd;
+
+    libxenvchan_fd = libxenvchan_fd_for_select(ctrl);
+    for (;;) {
+        fd_set rfds;
+        fd_set wfds;
+        FD_ZERO(&rfds);
+        FD_ZERO(&wfds);
+
+        max_fd = -1;
+        if (input_fd != -1 && insiz != BUFSIZE) {
+            FD_SET(input_fd, &rfds);
+            if (input_fd > max_fd)
+                max_fd = input_fd;
+        }
+        if (output_fd != -1 && outsiz) {
+            FD_SET(output_fd, &wfds);
+            if (output_fd > max_fd)
+                max_fd = output_fd;
+        }
+        FD_SET(libxenvchan_fd, &rfds);
+        if (libxenvchan_fd > max_fd)
+            max_fd = libxenvchan_fd;
+        ret = select(max_fd + 1, &rfds, &wfds, NULL, NULL);
+        if (ret < 0) {
+            perror("select");
+            exit(1);
+        }
+        if (FD_ISSET(libxenvchan_fd, &rfds)) {
+            libxenvchan_wait(ctrl);
+            if (!libxenvchan_is_open(ctrl)) {
+                if (verbose)
+                    fprintf(stderr, "vchan client disconnected\n");
+                while (outsiz)
+                    socket_wr(output_fd);
+                close(output_fd);
+                close(input_fd);
+                discard_buffers(ctrl);
+                break;
+            }
+            vchan_wr(ctrl);
+        }
+
+        if (FD_ISSET(input_fd, &rfds)) {
+            ret = read(input_fd, inbuf + insiz, BUFSIZE - insiz);
+            if (ret < 0 && errno != EAGAIN)
+                exit(1);
+            if (verbose)
+                fprintf(stderr, "from-unix: %.*s\n", ret, inbuf + insiz);
+            if (ret == 0) {
+                /* EOF on socket, write everything in the buffer and close the
+                 * input_fd socket */
+                while (insiz) {
+                    vchan_wr(ctrl);
+                    libxenvchan_wait(ctrl);
+                }
+                close(input_fd);
+                input_fd = -1;
+                /* TODO: maybe signal the vchan client somehow? */
+                break;
+            }
+            if (ret)
+                insiz += ret;
+            vchan_wr(ctrl);
+        }
+        if (FD_ISSET(output_fd, &wfds))
+            socket_wr(output_fd);
+        while (libxenvchan_data_ready(ctrl) && outsiz < BUFSIZE) {
+            ret = libxenvchan_read(ctrl, outbuf + outsiz, BUFSIZE - outsiz);
+            if (ret < 0)
+                exit(1);
+            if (verbose)
+                fprintf(stderr, "from-vchan: %.*s\n", ret, outbuf + outsiz);
+            outsiz += ret;
+            socket_wr(output_fd);
+        }
+    }
+    return 0;
+}
+
+/**
+    Simple libxenvchan application, both client and server.
+    Both sides may write and read, both from the libxenvchan and from
+    stdin/stdout (just like netcat).
+*/
+
+static struct option options[] = {
+    { "mode",       required_argument, NULL, 'm' },
+    { "verbose",          no_argument, NULL, 'v' },
+    { "state-path", required_argument, NULL, 's' },
+    { }
+};
+
+int main(int argc, char **argv)
+{
+    int is_server = 0;
+    int socket_fd = -1;
+    int input_fd, output_fd;
+    struct libxenvchan *ctrl = NULL;
+    const char *socket_path;
+    int domid;
+    const char *vchan_path;
+    const char *state_path = NULL;
+    int opt;
+
+    while ((opt = getopt_long(argc, argv, "m:vs:", options, NULL)) != -1) {
+        switch (opt) {
+            case 'm':
+                if (strcmp(optarg, "server") == 0)
+                    is_server = 1;
+                else if (strcmp(optarg, "client") == 0)
+                    is_server = 0;
+                else {
+                    fprintf(stderr, "invalid argument for --mode: %s\n", optarg);
+                    usage(argv);
+                    return 1;
+                }
+                break;
+            case 'v':
+                verbose = 1;
+                break;
+            case 's':
+                state_path = optarg;
+                break;
+            case '?':
+                usage(argv);
+        }
+    }
+
+    if (argc-optind != 3)
+        usage(argv);
+
+    domid = atoi(argv[optind]);
+    vchan_path = argv[optind+1];
+    socket_path = argv[optind+2];
+
+    if (is_server) {
+        ctrl = libxenvchan_server_init(NULL, domid, vchan_path, 0, 0);
+        if (!ctrl) {
+            perror("libxenvchan_server_init");
+            exit(1);
+        }
+    } else {
+        if (strcmp(socket_path, "-") == 0) {
+            input_fd = 0;
+            output_fd = 1;
+        } else {
+            socket_fd = listen_socket(socket_path);
+            if (socket_fd == -1) {
+                perror("listen socket");
+                return 1;
+            }
+        }
+    }
+
+    if (state_path) {
+        struct xs_handle *xs;
+
+        xs = xs_open(0);
+        if (!xs) {
+            perror("xs_open");
+            return 1;
+        }
+        if (!xs_write(xs, XBT_NULL, state_path, "running", strlen("running"))) {
+            perror("xs_write");
+            return 1;
+        }
+        xs_close(xs);
+    }
+
+    for (;;) {
+        if (is_server) {
+            /* wait for vchan connection */
+            while (libxenvchan_is_open(ctrl) != 1)
+                libxenvchan_wait(ctrl);
+            /* vchan client connected, setup local FD if needed */
+            if (strcmp(socket_path, "-") == 0) {
+                input_fd = 0;
+                output_fd = 1;
+            } else {
+                input_fd = output_fd = connect_socket(socket_path);
+            }
+            if (input_fd == -1) {
+                perror("connect socket");
+                return 1;
+            }
+            if (data_loop(ctrl, input_fd, output_fd) != 0)
+                break;
+            /* keep it running only when get UNIX socket path */
+            if (socket_path[0] != '/')
+                break;
+        } else {
+            /* wait for local socket connection */
+            if (strcmp(socket_path, "-") != 0)
+                input_fd = output_fd = accept(socket_fd, NULL, NULL);
+            if (input_fd == -1) {
+                perror("accept");
+                return 1;
+            }
+            set_nonblocking(input_fd, 1);
+            set_nonblocking(output_fd, 1);
+            ctrl = connect_vchan(domid, vchan_path);
+            if (!ctrl) {
+                perror("vchan client init");
+                return 1;
+            }
+            if (data_loop(ctrl, input_fd, output_fd) != 0)
+                break;
+            /* don't reconnect if output was stdout */
+            if (strcmp(socket_path, "-") == 0)
+                break;
+
+            libxenvchan_close(ctrl);
+            ctrl = NULL;
+        }
+    }
+    return 0;
+}
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVr-0000rj-Ru; Tue, 28 Apr 2020 04:06:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVq-0000qH-2L
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:26 +0000
X-Inumbo-ID: 96654e22-8905-11ea-b9cf-bc764e2007e4
Received: from mail-qk1-x743.google.com (unknown [2607:f8b0:4864:20::743])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 96654e22-8905-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:07 +0000 (UTC)
Received: by mail-qk1-x743.google.com with SMTP id c63so20582478qke.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=5ROtHVehXF/HD8/78X0tTT0dK2u2H5EIad+/RrtpdTg=;
 b=P6O3nAlsgkTlkXmN+WDZpgbuwKGNNPWtCnPC3L0Hj51zAMoHm7Qn21i0IhM6nS5WOY
 RXNEZ27GuE2pkt0A8HgYn4Dmdmgnpbb/LY3HhDFAytBXp0E7mjdqc/myoL83YzxbnkFV
 yya8+Hu6eT4VZXb8fvsBb8Cfuw8nUZZyWUNJj7Nk41/gUBbFUT/ISvjrc7WLt9OsFOaj
 NUU/qubzeLQ9kazwDylwjj1dHO3dQCcolLpvGdFO8JcmwJoOxAJxpccbZXEoGmcjWNQI
 wVHToW1F5AlPqzezUkygkfSO4nl9h6x6u0FXwELLAReCrJkGhjvfK1mS2of+Tvqy1s9v
 Pb2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=5ROtHVehXF/HD8/78X0tTT0dK2u2H5EIad+/RrtpdTg=;
 b=ch+77KcxsfkA+7HCVacSXW/YRSwbGMJAF7jwF4OgWkPplQUbipDS5q4pwF4FKTw9wP
 ZQ7HZWc8/l1reyii+Myxrp2tTgSyFvrN03VgHROGtryMXvNcMT9uwCYU375frTg0dkz9
 E3hhzo0nl0Ggtzf6nPFWyg7atY3vgw4tCx1wtF5LIi+FI0sQASJpRJOYWbXJV6KGfcU8
 5jF7tbcjl8WUoK9vPrtVymzeQL/f8fqJ88ktBKXl169ALJr6QikvfyqfYtjeAOdE060H
 7V+aKfsDXm8ntXHki3oHzMI8FR2aGMIKuOtfaFdqLVDFQDrD0wAFiens8rLgNjUS7BSl
 yzHg==
X-Gm-Message-State: AGi0PuYesVgzf/Jh4u3mix18aZeLuzfMcd20sGpiRaYiVLfOT3kBGyF+
 V6BUrg19f/V10XA7Xt9u/gVkW+8Z
X-Google-Smtp-Source: APiQypJcR19nCEvHNRTrQGfPB7p+WNgdZ1ISZps0CR6Nvzwdz9zVhohRx6RqqDgArjUAutTSgB3wMQ==
X-Received: by 2002:a37:ac18:: with SMTP id e24mr26234983qkm.234.1588046767112; 
 Mon, 27 Apr 2020 21:06:07 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:06 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 12/21] libxl: use vchan for QMP access with Linux stubdomain
Date: Tue, 28 Apr 2020 00:04:24 -0400
Message-Id: <20200428040433.23504-13-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Access to QMP of QEMU in Linux stubdomain is possible over vchan
connection. Handle the actual vchan connection in a separate process
(vchan-socket-proxy). This simplified integration with QMP (already
quite complex), but also allows preliminary filtering of (potentially
malicious) QMP input.
Since only one client can be connected to vchan server at the same time
and it is not enforced by the libxenvchan itself, additional client-side
locking is needed. It is implicitly implemented by vchan-socket-proxy,
as it handle only one connection at a time. Note that qemu supports only
one simultaneous client on a control socket anyway (but in UNIX socket
case, it enforce it server-side), so it doesn't add any extra
limitation.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
Changes in v4:
 - new patch, in place of both "libxl: use vchan for QMP access ..."
Changes in v5:
 - Use device-model/%u/qmp-proxy-state xenstore path
 - Rephrase comment
---
 tools/configure.ac           |   9 ++
 tools/libxl/libxl_dm.c       | 163 +++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_internal.h |   1 +
 3 files changed, 165 insertions(+), 8 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index ea0272766f..1c0ed4c3b1 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -192,6 +192,15 @@ AC_SUBST(qemu_xen)
 AC_SUBST(qemu_xen_path)
 AC_SUBST(qemu_xen_systemd)
 
+AC_ARG_WITH([stubdom-qmp-proxy],
+    AC_HELP_STRING([--stubdom-qmp-proxy@<:@=PATH@:>@],
+        [Use supplied binary PATH as a QMP proxy into stubdomain]),[
+    stubdom_qmp_proxy="$withval"
+],[
+    stubdom_qmp_proxy="$bindir/vchan-socket-proxy"
+])
+AC_DEFINE_UNQUOTED([STUBDOM_QMP_PROXY_PATH], ["$stubdom_qmp_proxy"], [QMP proxy path])
+
 AC_ARG_WITH([system-seabios],
     AS_HELP_STRING([--with-system-seabios@<:@=PATH@:>@],
        [Use system supplied seabios PATH instead of building and installing
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 45d0dd56f5..e420c3fc7b 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1200,7 +1200,11 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
                       GCSPRINTF("%d", guest_domid), NULL);
     flexarray_append(dm_args, "-no-shutdown");
 
-    /* There is currently no way to access the QMP socket in the stubdom */
+    /*
+     * QMP access to qemu running in stubdomain is done over vchan. The
+     * stubdomain init script adds the appropriate monitor options for
+     * vchan-socket-proxy.
+     */
     if (!is_stubdom) {
         flexarray_append(dm_args, "-chardev");
         if (state->dm_monitor_fd >= 0) {
@@ -2194,6 +2198,23 @@ static void stubdom_pvqemu_unpaused(libxl__egc *egc,
 static void stubdom_xswait_cb(libxl__egc *egc, libxl__xswait_state *xswait,
                               int rc, const char *p);
 
+static void spawn_qmp_proxy(libxl__egc *egc,
+                            libxl__stub_dm_spawn_state *sdss);
+
+static void qmp_proxy_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                              const char *xsdata);
+
+static void qmp_proxy_startup_failed(libxl__egc *egc,
+                                     libxl__spawn_state *spawn,
+                                     int rc);
+
+static void qmp_proxy_detached(libxl__egc *egc,
+                               libxl__spawn_state *spawn);
+
+static void qmp_proxy_spawn_outcome(libxl__egc *egc,
+                                    libxl__stub_dm_spawn_state *sdss,
+                                    int rc);
+
 char *libxl__stub_dm_name(libxl__gc *gc, const char *guest_name)
 {
     return GCSPRINTF("%s-dm", guest_name);
@@ -2476,24 +2497,150 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
             goto out;
     }
 
+    sdss->qmp_proxy_spawn.ao = ao;
+    if (libxl__stubdomain_is_linux(&guest_config->b_info)) {
+        spawn_qmp_proxy(egc, sdss);
+    } else {
+        qmp_proxy_spawn_outcome(egc, sdss, 0);
+    }
+
+    return;
+
+out:
+    assert(ret);
+    qmp_proxy_spawn_outcome(egc, sdss, ret);
+}
+
+static void spawn_qmp_proxy(libxl__egc *egc,
+                            libxl__stub_dm_spawn_state *sdss)
+{
+    STATE_AO_GC(sdss->qmp_proxy_spawn.ao);
+    const uint32_t guest_domid = sdss->dm.guest_domid;
+    const uint32_t dm_domid = sdss->pvqemu.guest_domid;
+    const char *dom_path = libxl__xs_get_dompath(gc, dm_domid);
+    char **args;
+    int nr = 0;
+    int rc, logfile_w, null;
+
+    if (access(STUBDOM_QMP_PROXY_PATH, X_OK) < 0) {
+        LOGED(ERROR, guest_domid, "qmp proxy %s is not executable", STUBDOM_QMP_PROXY_PATH);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    sdss->qmp_proxy_spawn.what = GCSPRINTF("domain %d device model qmp proxy", guest_domid);
+    sdss->qmp_proxy_spawn.pidpath = GCSPRINTF("%s/image/qmp-proxy-pid", dom_path);
+    sdss->qmp_proxy_spawn.xspath = DEVICE_MODEL_XS_PATH(gc, LIBXL_TOOLSTACK_DOMID,
+                                                        dm_domid, "/qmp-proxy-state");
+    sdss->qmp_proxy_spawn.timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
+    sdss->qmp_proxy_spawn.midproc_cb = libxl__spawn_record_pid;
+    sdss->qmp_proxy_spawn.confirm_cb = qmp_proxy_confirm;
+    sdss->qmp_proxy_spawn.failure_cb = qmp_proxy_startup_failed;
+    sdss->qmp_proxy_spawn.detached_cb = qmp_proxy_detached;
+
+    const int arraysize = 6;
+    GCNEW_ARRAY(args, arraysize);
+    args[nr++] = STUBDOM_QMP_PROXY_PATH;
+    args[nr++] = GCSPRINTF("--state-path=%s", sdss->qmp_proxy_spawn.xspath);
+    args[nr++] = GCSPRINTF("%u", dm_domid);
+    args[nr++] = GCSPRINTF("%s/device-model/%u/qmp-vchan", dom_path, guest_domid);
+    args[nr++] = (char*)libxl__qemu_qmp_path(gc, guest_domid);
+    args[nr++] = NULL;
+    assert(nr == arraysize);
+
+    logfile_w = libxl__create_qemu_logfile(gc, GCSPRINTF("qmp-proxy-%s",
+                                                         sdss->dm_config.c_info.name));
+    if (logfile_w < 0) {
+        rc = logfile_w;
+        goto out;
+    }
+    null = open("/dev/null", O_RDWR);
+    if (null < 0) {
+        LOGED(ERROR, guest_domid, "unable to open /dev/null");
+        rc = ERROR_FAIL;
+        goto out_close;
+    }
+
+    rc = libxl__spawn_spawn(egc, &sdss->qmp_proxy_spawn);
+    if (rc < 0)
+        goto out_close;
+    if (!rc) { /* inner child */
+        setsid();
+        libxl__exec(gc, null, null, logfile_w, STUBDOM_QMP_PROXY_PATH, args, NULL);
+        /* unreachable */
+    }
+
+    rc = 0;
+
+out_close:
+    if (logfile_w >= 0)
+        close(logfile_w);
+    if (null >= 0)
+        close(null);
+out:
+    if (rc)
+        qmp_proxy_spawn_outcome(egc, sdss, rc);
+}
+
+static void qmp_proxy_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                              const char *xsdata)
+{
+    STATE_AO_GC(spawn->ao);
+
+    if (!xsdata)
+        return;
+
+    if (strcmp(xsdata, "running"))
+        return;
+
+    libxl__spawn_initiate_detach(gc, spawn);
+}
+
+static void qmp_proxy_startup_failed(libxl__egc *egc,
+                                     libxl__spawn_state *spawn,
+                                     int rc)
+{
+    libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(spawn, *sdss, qmp_proxy_spawn);
+    qmp_proxy_spawn_outcome(egc, sdss, rc);
+}
+
+static void qmp_proxy_detached(libxl__egc *egc,
+                               libxl__spawn_state *spawn)
+{
+    libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(spawn, *sdss, qmp_proxy_spawn);
+    qmp_proxy_spawn_outcome(egc, sdss, 0);
+}
+
+static void qmp_proxy_spawn_outcome(libxl__egc *egc,
+                                    libxl__stub_dm_spawn_state *sdss,
+                                    int rc)
+{
+    STATE_AO_GC(sdss->qmp_proxy_spawn.ao);
+    int need_pvqemu = libxl__need_xenpv_qemu(gc, &sdss->dm_config);
+
+    if (rc) goto out;
+
+    if (need_pvqemu < 0) {
+        rc = need_pvqemu;
+        goto out;
+    }
+
     sdss->pvqemu.spawn.ao = ao;
-    sdss->pvqemu.guest_domid = dm_domid;
     sdss->pvqemu.guest_config = &sdss->dm_config;
     sdss->pvqemu.build_state = &sdss->dm_state;
     sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
-
-    if (!need_qemu) {
+    if (need_pvqemu) {
+        libxl__spawn_local_dm(egc, &sdss->pvqemu);
+    } else {
         /* If dom0 qemu not needed, do not launch it */
         spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, 0);
-    } else {
-        libxl__spawn_local_dm(egc, &sdss->pvqemu);
     }
 
     return;
 
 out:
-    assert(ret);
-    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
+    assert(rc);
+    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, rc);
 }
 
 static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a8f0eed945..00cfbe1fac 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4159,6 +4159,7 @@ typedef struct {
     libxl__destroy_domid_state dis;
     libxl__multidev multidev;
     libxl__xswait_state xswait;
+    libxl__spawn_state qmp_proxy_spawn;
 } libxl__stub_dm_spawn_state;
 
 _hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHVw-0000w2-AJ; Tue, 28 Apr 2020 04:06:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHVv-0000uw-2a
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:31 +0000
X-Inumbo-ID: 97cf9628-8905-11ea-9887-bc764e2007e4
Received: from mail-qk1-x736.google.com (unknown [2607:f8b0:4864:20::736])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 97cf9628-8905-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:10 +0000 (UTC)
Received: by mail-qk1-x736.google.com with SMTP id 20so20510581qkl.10
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=V/z9lnZ0BRCy+VnythBjJZ2hhGpF1b82Kvc/b7advnU=;
 b=q8wkYTHAKnhWREAxnGMsaBI2I5+A9JCTsJ7hKQ8+7bSR7oUX1XZiDxmLyxZKRMj0T3
 Wr3k49T9e11IeTlJkKB2xIxgSyS3RUxOhyVC9yu33t0I2FRrfXJTFZGoJuZijF9idj3r
 ZwYmIEOMI7TPjZYXF1GtRtnXGoZxXSTZK5oQnWUjif3lx+hK+UW202v6f8QmKFXIcbQ1
 5if9AuOnvbrIDibCqPSQz1UroUrvhsa7mdLuPEgDgNH2OBp1zAeLLO+E0Fv+9r8j58hY
 dkWnrN0JiFI75jnenO2ddBcCFF8SuRVR24ph053HGcTaBYJB3iK1IXNFtXfNDePebwb0
 ooaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=V/z9lnZ0BRCy+VnythBjJZ2hhGpF1b82Kvc/b7advnU=;
 b=PBGK2rVTfgomm9kqQy8TeWt0kVp/lKexcxh447GLmNcU5XLe1SX6MRbkSJzia4VdR/
 wGLwPMAWe+0XckS/Ek1Ov8+3PxFCXfQ3qMqzjHcxkivb+Og9MapOm+CSkCAbD/p2FO4t
 68N3fAxo4qUGNPUnqzwTyCOX1PBN5qZwgPpuzKNt5XYJwA7drEcmnaP+0rC4pYdrqB6F
 M0JWAjkw3GJwDIimQcSSz1Gb14o8KJ4HmmIK14D22gTgIWnBS29RdZuawJ5Dhat3uGwx
 YiCwXySQ2A0x4/6X01sJYLwEo3Pa2XCmtiRASoJVDACqerKWyWwm9UIaNjfMwEIz9tPk
 51oA==
X-Gm-Message-State: AGi0PuZP5mnWNmWVK3mh+16T22OmMLaWrNFXPMAdBCkwv2eQ9yDUPecd
 0QwV4//DdB7aZsa2lFSxbx4pjIyw
X-Google-Smtp-Source: APiQypIvLkZzfSVB1plttzJ6y6qYj5X45wQJja+PvCKKj+WyiRCGg2ns9uvaHgA/oyELOz1BuY+/YA==
X-Received: by 2002:a37:387:: with SMTP id 129mr25703101qkd.147.1588046769511; 
 Mon, 27 Apr 2020 21:06:09 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:08 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 13/21] Regenerate autotools files
Date: Tue, 28 Apr 2020 00:04:25 -0400
Message-Id: <20200428040433.23504-14-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@citrix.com>, Jason Andryuk <jandryuk@gmail.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Since we have those generated files committed to the repo (why?!),
update them after changing configure.ac.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 configure         | 14 +-------------
 docs/configure    | 14 +-------------
 stubdom/configure | 14 +-------------
 tools/config.h.in |  3 +++
 tools/configure   | 46 ++++++++++++++++++++++++++++------------------
 5 files changed, 34 insertions(+), 57 deletions(-)

diff --git a/configure b/configure
index 9da3970cef..8af54e8a5a 100755
--- a/configure
+++ b/configure
@@ -644,7 +644,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -723,7 +722,6 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
@@ -976,15 +974,6 @@ do
   | -silent | --silent | --silen | --sile | --sil)
     silent=yes ;;
 
-  -runstatedir | --runstatedir | --runstatedi | --runstated \
-  | --runstate | --runstat | --runsta | --runst | --runs \
-  | --run | --ru | --r)
-    ac_prev=runstatedir ;;
-  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
-  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
-  | --run=* | --ru=* | --r=*)
-    runstatedir=$ac_optarg ;;
-
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
     ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1122,7 +1111,7 @@ fi
 for ac_var in	exec_prefix prefix bindir sbindir libexecdir datarootdir \
 		datadir sysconfdir sharedstatedir localstatedir includedir \
 		oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-		libdir localedir mandir runstatedir
+		libdir localedir mandir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1275,7 +1264,6 @@ Fine tuning of the installation directories:
   --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
-  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIR            object code libraries [EPREFIX/lib]
   --includedir=DIR        C header files [PREFIX/include]
   --oldincludedir=DIR     C header files for non-gcc [/usr/include]
diff --git a/docs/configure b/docs/configure
index 9e3ed60462..93e9dcf404 100755
--- a/docs/configure
+++ b/docs/configure
@@ -634,7 +634,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -711,7 +710,6 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
@@ -964,15 +962,6 @@ do
   | -silent | --silent | --silen | --sile | --sil)
     silent=yes ;;
 
-  -runstatedir | --runstatedir | --runstatedi | --runstated \
-  | --runstate | --runstat | --runsta | --runst | --runs \
-  | --run | --ru | --r)
-    ac_prev=runstatedir ;;
-  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
-  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
-  | --run=* | --ru=* | --r=*)
-    runstatedir=$ac_optarg ;;
-
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
     ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1110,7 +1099,7 @@ fi
 for ac_var in	exec_prefix prefix bindir sbindir libexecdir datarootdir \
 		datadir sysconfdir sharedstatedir localstatedir includedir \
 		oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-		libdir localedir mandir runstatedir
+		libdir localedir mandir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1263,7 +1252,6 @@ Fine tuning of the installation directories:
   --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
-  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIR            object code libraries [EPREFIX/lib]
   --includedir=DIR        C header files [PREFIX/include]
   --oldincludedir=DIR     C header files for non-gcc [/usr/include]
diff --git a/stubdom/configure b/stubdom/configure
index da03da535a..f7604a37f7 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -661,7 +661,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -751,7 +750,6 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
@@ -1004,15 +1002,6 @@ do
   | -silent | --silent | --silen | --sile | --sil)
     silent=yes ;;
 
-  -runstatedir | --runstatedir | --runstatedi | --runstated \
-  | --runstate | --runstat | --runsta | --runst | --runs \
-  | --run | --ru | --r)
-    ac_prev=runstatedir ;;
-  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
-  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
-  | --run=* | --ru=* | --r=*)
-    runstatedir=$ac_optarg ;;
-
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
     ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1150,7 +1139,7 @@ fi
 for ac_var in	exec_prefix prefix bindir sbindir libexecdir datarootdir \
 		datadir sysconfdir sharedstatedir localstatedir includedir \
 		oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-		libdir localedir mandir runstatedir
+		libdir localedir mandir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1303,7 +1292,6 @@ Fine tuning of the installation directories:
   --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
-  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIR            object code libraries [EPREFIX/lib]
   --includedir=DIR        C header files [PREFIX/include]
   --oldincludedir=DIR     C header files for non-gcc [/usr/include]
diff --git a/tools/config.h.in b/tools/config.h.in
index 5a5944ebe1..5abf6092de 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -123,6 +123,9 @@
 /* Define to 1 if you have the ANSI C header files. */
 #undef STDC_HEADERS
 
+/* QMP proxy path */
+#undef STUBDOM_QMP_PROXY_PATH
+
 /* Enable large inode numbers on Mac OS X 10.5.  */
 #ifndef _DARWIN_USE_64_BIT_INODE
 # define _DARWIN_USE_64_BIT_INODE 1
diff --git a/tools/configure b/tools/configure
index 4fa5f7b937..fef684f0be 100755
--- a/tools/configure
+++ b/tools/configure
@@ -770,7 +770,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -811,6 +810,7 @@ with_linux_backend_modules
 enable_qemu_traditional
 enable_rombios
 with_system_qemu
+with_stubdom_qmp_proxy
 with_system_seabios
 with_system_ovmf
 enable_ipxe
@@ -896,7 +896,6 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
@@ -1149,15 +1148,6 @@ do
   | -silent | --silent | --silen | --sile | --sil)
     silent=yes ;;
 
-  -runstatedir | --runstatedir | --runstatedi | --runstated \
-  | --runstate | --runstat | --runsta | --runst | --runs \
-  | --run | --ru | --r)
-    ac_prev=runstatedir ;;
-  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
-  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
-  | --run=* | --ru=* | --r=*)
-    runstatedir=$ac_optarg ;;
-
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
     ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1295,7 +1285,7 @@ fi
 for ac_var in	exec_prefix prefix bindir sbindir libexecdir datarootdir \
 		datadir sysconfdir sharedstatedir localstatedir includedir \
 		oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-		libdir localedir mandir runstatedir
+		libdir localedir mandir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1448,7 +1438,6 @@ Fine tuning of the installation directories:
   --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
-  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIR            object code libraries [EPREFIX/lib]
   --includedir=DIR        C header files [PREFIX/include]
   --oldincludedir=DIR     C header files for non-gcc [/usr/include]
@@ -1531,6 +1520,9 @@ Optional Packages:
                           Use system supplied qemu PATH or qemu (taken from
                           $PATH) as qemu-xen device model instead of building
                           and installing our own version
+  --stubdom-qmp-proxy[=PATH]
+                          Use supplied binary PATH as a QMP proxy into
+                          stubdomain
   --with-system-seabios[=PATH]
                           Use system supplied seabios PATH instead of building
                           and installing our own version
@@ -3378,7 +3370,7 @@ else
     We can't simply define LARGE_OFF_T to be 9223372036854775807,
     since some C++ compilers masquerading as C compilers
     incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
 		       && LARGE_OFF_T % 2147483647 == 1)
 		      ? 1 : -1];
@@ -3424,7 +3416,7 @@ else
     We can't simply define LARGE_OFF_T to be 9223372036854775807,
     since some C++ compilers masquerading as C compilers
     incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
 		       && LARGE_OFF_T % 2147483647 == 1)
 		      ? 1 : -1];
@@ -3448,7 +3440,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
     We can't simply define LARGE_OFF_T to be 9223372036854775807,
     since some C++ compilers masquerading as C compilers
     incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
 		       && LARGE_OFF_T % 2147483647 == 1)
 		      ? 1 : -1];
@@ -3493,7 +3485,7 @@ else
     We can't simply define LARGE_OFF_T to be 9223372036854775807,
     since some C++ compilers masquerading as C compilers
     incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
 		       && LARGE_OFF_T % 2147483647 == 1)
 		      ? 1 : -1];
@@ -3517,7 +3509,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
     We can't simply define LARGE_OFF_T to be 9223372036854775807,
     since some C++ compilers masquerading as C compilers
     incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
 		       && LARGE_OFF_T % 2147483647 == 1)
 		      ? 1 : -1];
@@ -4519,6 +4511,24 @@ _ACEOF
 
 
 
+# Check whether --with-stubdom-qmp-proxy was given.
+if test "${with_stubdom_qmp_proxy+set}" = set; then :
+  withval=$with_stubdom_qmp_proxy;
+    stubdom_qmp_proxy="$withval"
+
+else
+
+    stubdom_qmp_proxy="$bindir/vchan-socket-proxy"
+
+fi
+
+
+cat >>confdefs.h <<_ACEOF
+#define STUBDOM_QMP_PROXY_PATH "$stubdom_qmp_proxy"
+_ACEOF
+
+
+
 # Check whether --with-system-seabios was given.
 if test "${with_system_seabios+set}" = set; then :
   withval=$with_system_seabios;
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHW1-000105-JN; Tue, 28 Apr 2020 04:06:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHW0-0000yu-34
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:36 +0000
X-Inumbo-ID: 98fb0b72-8905-11ea-b9cf-bc764e2007e4
Received: from mail-qt1-x841.google.com (unknown [2607:f8b0:4864:20::841])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 98fb0b72-8905-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:12 +0000 (UTC)
Received: by mail-qt1-x841.google.com with SMTP id x12so15749996qts.9
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=V6avmJFZc+UWlxb0gGCz2wXyfeB09ISjRm2mBdCGWKo=;
 b=gHhcNzKd0B20C9Seb4++4x1AHSa6TgznykVY3MOBbi33xEoDIMvUyUQ0gf38MLA7pi
 k38QmKbgz41K+Re/IQ3O6ICmwEt+IsjmwhGbHrc/6lltqvGPqOiIhgz7hKXRsQ8WELfO
 NsRBUnJzu/aIihfDz8VRX98qrJCfPWFVK5lIZKRksJVgwZ3xDfBAYKcKf+T3qBcEc//O
 zDb3zVZOu3h0uZ5oE+h4mga4YOkTV8ko6z5kCkAln6ot+SKTlWTsZ1d1yh7Tvv+wwbGX
 Zv9Kbm/s4IYfSEbuVL5u8Bi/ec2kZ4XtW7Qk4SAHtDmBc1t4jzV0kEh5YUJLkvYlaa7F
 8ymg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=V6avmJFZc+UWlxb0gGCz2wXyfeB09ISjRm2mBdCGWKo=;
 b=OuWrx8pxT+a3o2vzsFtZMMbvAdcjOUF34zh/89lNBaGrXW2YIMXJGil+9AwaBi00wt
 ikRQ9jZkZNUF3UfKkXrnac1pOKOnZIFJz9k/YmiG1RoRtw1rk2oR1szznHQwKyqqeaLi
 Iy4cwr7yCKzr77TYWNtUXOoI++GFYQzHnRLclQLU36NgA/Yv97ZIzowvNpXpmgsgHzhb
 7MvR29XOeXt1I/kZN0DqyxW/3T2SE2zIuw4SjFqDZO5a6iJU6b/U+ozLYuLKDO/KPMGO
 0aZ05B6PMMLUetkyzsR4WIcdOwHjXyH0/huXTfG0rPAlTPiW1Q4OJxvMwBJFRBncCfcy
 AB0A==
X-Gm-Message-State: AGi0Pubvof+kEQwRiC+7RlELKHwGA33vakzaWf0VOXaJtoKEW9hUQW6j
 K6Guy4rfbyql9ygaCFfRVW/SKc3j
X-Google-Smtp-Source: APiQypLtIFkRQ9ztGRweNh7AvLHZZFN3cakXNXaLfZXUPmzuAF73gA4rDryPkiibyzokzqgib7/NvA==
X-Received: by 2002:ac8:12c2:: with SMTP id b2mr26438790qtj.7.1588046771686;
 Mon, 27 Apr 2020 21:06:11 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:11 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 14/21] libxl: require qemu in dom0 even if stubdomain is in
 use
Date: Tue, 28 Apr 2020 00:04:26 -0400
Message-Id: <20200428040433.23504-15-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Until xenconsoled learns how to handle multiple consoles, this is needed
for save/restore support (qemu state is transferred over secondary
consoles).
Additionally, Linux-based stubdomain waits for all the backends to
initialize during boot. Lack of some console backends results in
stubdomain startup timeout.

This is a temporary patch until xenconsoled will be improved.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 tools/libxl/libxl_dm.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index e420c3fc7b..5e5e7a27b3 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2484,7 +2484,11 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
         }
     }
 
-    need_qemu = libxl__need_xenpv_qemu(gc, dm_config);
+    /*
+     * Until xenconsoled learns how to handle multiple consoles, require qemu
+     * in dom0 to serve consoles for a stubdomain - it require at least 3 of them.
+     */
+    need_qemu = 1 || libxl__need_xenpv_qemu(gc, &sdss->dm_config);
 
     for (i = 0; i < num_console; i++) {
         libxl__device device;
@@ -2616,7 +2620,11 @@ static void qmp_proxy_spawn_outcome(libxl__egc *egc,
                                     int rc)
 {
     STATE_AO_GC(sdss->qmp_proxy_spawn.ao);
-    int need_pvqemu = libxl__need_xenpv_qemu(gc, &sdss->dm_config);
+    /*
+     * Until xenconsoled learns how to handle multiple consoles, require qemu
+     * in dom0 to serve consoles for a stubdomain - it require at least 3 of them.
+     */
+    int need_pvqemu = 1 || libxl__need_xenpv_qemu(gc, &sdss->dm_config);
 
     if (rc) goto out;
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHW6-000155-UC; Tue, 28 Apr 2020 04:06:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHW5-000133-39
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:41 +0000
X-Inumbo-ID: 9a67bcd0-8905-11ea-b9cf-bc764e2007e4
Received: from mail-qt1-x844.google.com (unknown [2607:f8b0:4864:20::844])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9a67bcd0-8905-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:14 +0000 (UTC)
Received: by mail-qt1-x844.google.com with SMTP id o10so16293260qtr.6
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=YHrTNz7tUN0rhzka1j5HZ0Hi5er6+RNP2GXkixa7DZ0=;
 b=KAI4oMLxyg3xRmENF7haPFheBvn4T3kZi+YuTHh2Mmc9InbCorIxcghMes5jhjE+yC
 vvkrY9I3RYVxSE2+9IJjegn8obmRQV9Re4LYWORn441i04NPgeSjJ9A9scacv1f4Kfje
 AGUHF12l2Jx4JhoO6dVYFXwnqqEvorUxfWva2M+OUw+ZwCXmWma36dhFX/FmL1UIX3I7
 7DWLe1u7M3dwgxD3pIMZK0V0jrdfDBK0Kl2UIOTeUZ2JTK6LP8jRIBkA9XM2pfRexJ1q
 ashqcgQQn2LL0aHO3Jz2I3CVhUDc3dzeFGf4hoHadAppY6FFVKRGqNrqEybESITJeRrj
 lFfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=YHrTNz7tUN0rhzka1j5HZ0Hi5er6+RNP2GXkixa7DZ0=;
 b=oMZ1OVkctMa9LLkx1Tc/OFu9qboDTPSJvFEOLihSdU+M+j4Khv0XlvTTL+Zb9ICSqZ
 mi6Di5/L+ma7KtIjlyNfixoNll/IJox083JYzkHC1qZCgulq7eFbFKNcWgBRt30ffRaW
 MG9TJBM2cXUJo3fMX9n0iySxBw+eG+iayoq8A3uKKU55efocXst71QkrPT5dnZ3ZEdnD
 Vrhbxh8mZ1PW5v8xbhE+33S2P8Fn/AitQUfmF/L6TDagBHQd9juzWGTJLvCiCniUq8T/
 nn3NXeAJOtddN5Wu1gaFXCKJ4eABRhlqDDjPw6hGSiC6vkW4lbWqkCcushsOALC8Xw9t
 IhGA==
X-Gm-Message-State: AGi0PuZeeMeyFVG6yj/7UTkM/E+r25VIj4a0eGbkuXfX1PBMzI8Y7rfW
 mb+H2tldVMLrC6lx9VtY+cGYd9LN
X-Google-Smtp-Source: APiQypKF61HS+kx09HNopaG/vRRFYcaVVZv+78ro8jhSj9i+JGmvZMcS7GD1DlUW/ybvMVPjplME2g==
X-Received: by 2002:ac8:7ca2:: with SMTP id z2mr26929152qtv.122.1588046774039; 
 Mon, 27 Apr 2020 21:06:14 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:13 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 15/21] libxl: ignore emulated IDE disks beyond the first 4
Date: Tue, 28 Apr 2020 00:04:27 -0400
Message-Id: <20200428040433.23504-16-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Qemu supports only 4 emulated IDE disks, when given more (or with higher
indexes), it will fail to start. Since the disks can still be accessible
using PV interface, just ignore emulated path and log a warning, instead
of rejecting the configuration altogether.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 tools/libxl/libxl_dm.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5e5e7a27b3..03d7a38f1f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1891,6 +1891,13 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
             }
 
             if (disks[i].is_cdrom) {
+                if (disk > 4) {
+                    LOGD(WARN, guest_domid, "Emulated CDROM can be only one of the first 4 disks.\n"
+                         "Disk %s will be available via PV drivers but not as an "
+                         "emulated disk.",
+                         disks[i].vdev);
+                    continue;
+                }
                 drive = libxl__sprintf(gc,
                          "if=ide,index=%d,readonly=on,media=cdrom,id=ide-%i",
                          disk, dev_number);
@@ -1968,6 +1975,10 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
                                                        &disks[i],
                                                        colo_mode);
                 } else {
+                    LOGD(WARN, guest_domid, "Only 4 emulated IDE disks are supported.\n"
+                         "Disk %s will be available via PV drivers but not as an "
+                         "emulated disk.",
+                         disks[i].vdev);
                     continue; /* Do not emulate this disk */
                 }
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHWB-00019C-7z; Tue, 28 Apr 2020 04:06:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHWA-00017y-3R
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:46 +0000
X-Inumbo-ID: 9ba326e8-8905-11ea-b9cf-bc764e2007e4
Received: from mail-qk1-x744.google.com (unknown [2607:f8b0:4864:20::744])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9ba326e8-8905-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:16 +0000 (UTC)
Received: by mail-qk1-x744.google.com with SMTP id g74so20494237qke.13
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=0j8wm36LGsZqMjdI5/1E69Neum61HZiB3dp5bB5iUEk=;
 b=Mdu81/O2RzmWfDxrvXDw5rcc1CZ6Xsh4Q18owuxthBbFAIgut43vsvxCJ4saCVC95N
 2woUMyQQ5Kgz8JAqz+/A3kTNKHC25OIUtIqEu59BUqArpKQ6pi5UOvASRlIKYWF0+bSz
 wiK08CdkoRJeROnUx8cXmKSLHdD39dszJpukRMdZ9LFxSFg03vRm52vm9GIUqDePXcqf
 lBHIVyuNNnBB3TmRsIPKan15vbyljHbNdUmP0MaF/cmIYlsgZPvK3cFiDJMhip6YLKvP
 8HL+RfdXNCAsxgxUzbLMWY2BKQior59rBQnore4RImww8eXrxAQSFQQA56KLSLyAfG8j
 BWRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=0j8wm36LGsZqMjdI5/1E69Neum61HZiB3dp5bB5iUEk=;
 b=lMS1NfveQLpEo2Wltx2Ob8kQvt4LxF3UY2rbDjTTv9WOH03aKbje05ay1Fv9t8d6zJ
 RjKTL4SvHxDAtRdo6P6xjoTcKKfvtqou2sN10aBvWL9zObB8qp8IzvYsViDPh1OFBJkk
 dinc+UZCrE/m6tJJYoXiDxuzANjzTWVG0DqFG9M/mKwQ5gLylPH2ytt9+x0Viobh1q/5
 MrMrFmARt3rQ6lkz3m77vjxA5xiGUO2o25ni77ZLFKY93o/8KDUErPHyO/AwrNFy/QUI
 MSalfCzBBLyJbdkGScjXrSzxu2K+usZTRgP7Mcjiq2378aBflseEKghxO6YbR42lYyQr
 5kdA==
X-Gm-Message-State: AGi0PuZyzaKHWJFbSBkUIurqE54J+LlM+qIIsYYxL/BP3wYKVImhDc8I
 1A5ttNz4Y+ELaxREistDuskAEs9G
X-Google-Smtp-Source: APiQypIAfqI9RLEm3UJaxI6J7R1wp5n5o3ctkhdgmYwxhOYUKYvV+Y/lYiibhmQO8rNP5tVYJRf73w==
X-Received: by 2002:a05:620a:2091:: with SMTP id
 e17mr9825551qka.70.1588046776119; 
 Mon, 27 Apr 2020 21:06:16 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:15 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 16/21] libxl: consider also qemu in stubdomain in
 libxl__dm_active check
Date: Tue, 28 Apr 2020 00:04:28 -0400
Message-Id: <20200428040433.23504-17-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>,
 =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Since qemu-xen can now run in stubdomain too, handle this case when
checking it's state too.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 tools/libxl/libxl_dm.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 03d7a38f1f..5d61da1de8 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -3749,12 +3749,18 @@ out:
 
 int libxl__dm_active(libxl__gc *gc, uint32_t domid)
 {
-    char *pid, *path;
+    char *pid, *dm_domid, *path;
 
     path = GCSPRINTF("/local/domain/%d/image/device-model-pid", domid);
     pid = libxl__xs_read(gc, XBT_NULL, path);
 
-    return pid != NULL;
+    if (pid)
+        return true;
+
+    path = GCSPRINTF("/local/domain/%d/image/device-model-domid", domid);
+    dm_domid = libxl__xs_read(gc, XBT_NULL, path);
+
+    return dm_domid != NULL;
 }
 
 int libxl__dm_check_start(libxl__gc *gc, libxl_domain_config *d_config,
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHWG-0001F1-PM; Tue, 28 Apr 2020 04:06:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHWF-0001DT-3g
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:51 +0000
X-Inumbo-ID: 9d2d764e-8905-11ea-b9cf-bc764e2007e4
Received: from mail-qk1-x743.google.com (unknown [2607:f8b0:4864:20::743])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9d2d764e-8905-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:19 +0000 (UTC)
Received: by mail-qk1-x743.google.com with SMTP id 20so20510772qkl.10
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=RNheJoXDK0K0JeJe6uhrnBacMxojGYzO1+cdpKez/ow=;
 b=WF44xZ98MbEqysIwXm59CFTp7aVINuuJNv49m5uht/uEANPnERO56jm3GpsAysKbpp
 u5GIEPaV4UCT/QZXDhHMriZYU6011lernF5uW+ohugKx5G44zXnSN8ZByu7OWQpHXRkL
 u7Inx1zus8PDNMjAu0Dysd7egNcSc4xA92TpeZitx5E4fN1bYilHbHABK5olfjgis1EG
 cf5Vc34F96HxiNUYtPXN75X5Xa/iHdt8JAeys/zcXKdpSR2zpc2diqkbKJ4Z+WPWaOvf
 /zdS2Qk3sG/+dchcPINlOHQaP+C5vQ36JgllafTIn5V8CHjaYHFrjjrnxB5rzHcb/m33
 WdfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=RNheJoXDK0K0JeJe6uhrnBacMxojGYzO1+cdpKez/ow=;
 b=mlgOyzwVCXw1auTsyzmRMeE8ro4j0Y1yVQUZ7Dli8e3aZyowm1fTq3+oLTYVmDrshm
 ME9TxU4mwvr/AVdkiN3ITS6LRaVhmFwx3lrRkWWsRhgaWRxd9A6QLDkGStbsHytpkjaw
 PrcGjnh8vh9lkaHxLNBRqZypHloJHpvnTNRxKs03A+ogmzW1fjHU2tO9mfdOnlIO6TCF
 1LppCLCNm/z9Vn7KmgGAUrKNeuyMLG1Tdi0DL2K/VmAyZM3rIRvFHxLKiEGzGkBW4ynV
 C2X35sP84SQm6tMUoNwQ+lxiGZoj6F3KjEBx+dpoEEQpG3Eng3/uZ11hycBLHV5/LxbV
 8UOg==
X-Gm-Message-State: AGi0PubKwC+i69Rv7wtzPESt00DhtmHmJ0bMebc1o5Zav9dL/YWPZzBb
 Nyg4DwNeGixaNXzZvl//nN6ne4W0
X-Google-Smtp-Source: APiQypKTQrnyHkhvu7IhjdgEeifBCZzOtEu99tsC1xbisqoyyUiV5TFZ2REIzDzPQ9iZAzsOuVpVMw==
X-Received: by 2002:a05:620a:13b5:: with SMTP id
 m21mr25161994qki.208.1588046778722; 
 Mon, 27 Apr 2020 21:06:18 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:17 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 17/21] docs: Add device-model-domid to xenstore-paths
Date: Tue, 28 Apr 2020 00:04:29 -0400
Message-Id: <20200428040433.23504-18-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Jason Andryuk <jandryuk@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Ian Jackson <ian.jackson@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Document device-model-domid for when using a device model stubdomain.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 docs/misc/xenstore-paths.pandoc | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/docs/misc/xenstore-paths.pandoc b/docs/misc/xenstore-paths.pandoc
index a152f5ea68..766e8008dc 100644
--- a/docs/misc/xenstore-paths.pandoc
+++ b/docs/misc/xenstore-paths.pandoc
@@ -148,6 +148,11 @@ The domain's own ID.
 The process ID of the device model associated with this domain, if it
 has one.
 
+#### ~/image/device-model-domid = INTEGER   [INTERNAL]
+
+The domain ID of the device model stubdomain associated with this domain,
+if it has one.
+
 #### ~/cpu/[0-9]+/availability = ("online"|"offline") [PV]
 
 One node for each virtual CPU up to the guest's configured
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:06:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHWM-0001Ku-3f; Tue, 28 Apr 2020 04:06:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHWK-0001Iw-3t
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:06:56 +0000
X-Inumbo-ID: 9e6a4e92-8905-11ea-9887-bc764e2007e4
Received: from mail-qv1-xf43.google.com (unknown [2607:f8b0:4864:20::f43])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9e6a4e92-8905-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:21 +0000 (UTC)
Received: by mail-qv1-xf43.google.com with SMTP id y19so9757487qvv.4
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=tSVk0kCBf7n4qF0esOSMv85t4GqldCzE2h0PjonxwNo=;
 b=tb3C2eJPTwYyxOnSmKGXZljy6Xj8fMhjs5HuQD8Vo64C3gCYuL18KIppYOHXsYwK7S
 9MlT9sfKYnoL164NSLh0g6nALsr6TQLbIT5Z2v0NJr2du8KnF0ipA624WA5okByRMqq8
 suG1EkswxIIiMTevCVjug9Jd1YYMRxRWK/E6+kwITZef1w/hcKo2Bqtdu2DThZwJC7Qd
 MPnmf0qOCrzws/GMBLD/u+mm9eoezCeUVSMG4LRCY3xIz0eOgWm/R1dFNyzAc7bogJa0
 c4Z9mXQcIDTqcU6jL7yB8uCpOcU/Kue6I2mQHzlW3Y2fuq7ybh95BI57VZi25QTcxmnQ
 6rdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=tSVk0kCBf7n4qF0esOSMv85t4GqldCzE2h0PjonxwNo=;
 b=cVcmxGvUqxisn40Y+HCmsk+ESt2+nZFpw511vF3NMncUwnVdqPcgpQDNINeoxJq1Pf
 qWjsK3JtjV828HfwwFlNZUp4f1hBTx/LQNw54oB2WEHgUQUyt7SwVUzCr5T9LGfTpZZh
 10WvZ7RnsoFJcTQ90QEdVf2fMQfiSlXREZg4QR/kwbwldmpboRQ36kk/qHhViYoa2A+D
 VLdwfkcwLvPMIWqNTXNS4Owu/FrtfsGHioHDLpnCDwoOj/XU2CgfiIq7IBPJg8IfS+Rl
 Btlpwu4G1gaCVrpWisybvGGtftPnp9pmUlP2Br6lQvV8h2rMZb3N37yZArTZ/f1qhdA9
 jmBQ==
X-Gm-Message-State: AGi0PuYqG2kLqTMemEywuf2p6QN9ehtKBWzmf4F8ZXsynXtsFh6c6JJm
 1wJ9qlPsI8copSYHlS7oP++Dw/AY
X-Google-Smtp-Source: APiQypKCttcK2Qg1o1j3J3JV4xEZ+88l5p38LSqrSIpq5oCLR1KYCeyyYSPJ6jK6YDCgqvheDVdG6w==
X-Received: by 2002:a0c:da0e:: with SMTP id x14mr26232279qvj.47.1588046780850; 
 Mon, 27 Apr 2020 21:06:20 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:20 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 18/21] libxl: Check stubdomain kernel & ramdisk presence
Date: Tue, 28 Apr 2020 00:04:30 -0400
Message-Id: <20200428040433.23504-19-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Just out of context is the following comment for libxl__domain_make:
/* fixme: this function can leak the stubdom if it fails */

When the stubdomain kernel or ramdisk is not present, the domid and
stubdomain name will indeed be leaked.  Avoid the leak by checking the
file presence and erroring out when absent.  It doesn't fix all cases,
but it avoids a big one when using a linux device model stubdomain.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 tools/libxl/libxl_dm.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5d61da1de8..a57c13bdf4 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2316,6 +2316,22 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
         dm_config->num_vkbs = 1;
     }
 
+    if (guest_config->b_info.stubdomain_kernel &&
+        access(guest_config->b_info.stubdomain_kernel, R_OK) != 0) {
+        LOGED(ERROR, guest_domid, "could not access stubdomain kernel %s",
+              guest_config->b_info.stubdomain_kernel);
+        ret = ERROR_INVAL;
+        goto out;
+    }
+
+    if (guest_config->b_info.stubdomain_ramdisk &&
+        access(guest_config->b_info.stubdomain_ramdisk, R_OK) != 0) {
+        LOGED(ERROR, guest_domid, "could not access stubdomain ramdisk %s",
+              guest_config->b_info.stubdomain_ramdisk);
+        ret = ERROR_INVAL;
+        goto out;
+    }
+
     stubdom_state->pv_kernel.path = guest_config->b_info.stubdomain_kernel;
     stubdom_state->pv_ramdisk.path = guest_config->b_info.stubdomain_ramdisk;
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:07:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHWQ-0001Om-EQ; Tue, 28 Apr 2020 04:07:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHWP-0001Nr-49
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:07:01 +0000
X-Inumbo-ID: 9fb25ad8-8905-11ea-9887-bc764e2007e4
Received: from mail-qk1-x742.google.com (unknown [2607:f8b0:4864:20::742])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9fb25ad8-8905-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:23 +0000 (UTC)
Received: by mail-qk1-x742.google.com with SMTP id t3so20591207qkg.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=6DQChgQe+3bSXOEkWGb6D1mzdbV5n3lQYWfTuCEquu8=;
 b=Xse0tAdbdB+fF1IFKZRUS6Q/2MFCrE/2W06iDpxBq7FbgQC2NuqemaAC+9W8hkPvjG
 RqfHvzkCNFw0RhDpx9gbkTyscUSqwwx27vcOZ1aHw5AXlhA3p19LUHtcuLW9qT0rcsI/
 /pLIQBDW1oqSM1YXXe8B9TaNlKsAxzYdv2ynChzZ0jal7NlQkA2iv2vgm6kVyjxYV0mU
 EzOazIJ39GlhuF4YzXL88CYZdy6D0bDW8MeGEKZnogBP8RgM9o2RQ0LG5BgqEe/J25JC
 LayBQ9TrDy0f+tJ1kOiciYt4/bP2/3/BrMzrNzGT88IcBzcLK1ZAXO3tqJXCd3634KMe
 2e7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=6DQChgQe+3bSXOEkWGb6D1mzdbV5n3lQYWfTuCEquu8=;
 b=sZsnEMzYTmNbsL0N9pv7MsKQkm3fquB0vI8C3wbp5zTx+1d5Mq4FXi1wmYOiNH8CfR
 /HqzCZuzJp7Fwdo/VxpVXwgC0lH9oQsdj6t26vE8tZUpxlmuBgwfNiFkUs1Sb1cPcb/Q
 r81p2O9ZDHnG3iXPdm6VWM/PAorTB18Pd2FidFIPRQ1mQNP4F2QpeFRc0xWaahxM9aiT
 eVpeo24npYbSgCwjgDt9EEf3PaDEIgVyu+3qqcE8X92vtp/Zw+2NGryBs7c325/3aMDq
 8nrPkK/OIlwABj3ugPpQ19lt5sqkaJhmUORuIE3Da7CQK8D+MbC6K1+sCf8kq11/bxI9
 mv6A==
X-Gm-Message-State: AGi0PuawhNxJC+gG5krOqTo/KuYnaViA9wbgJNpgIxvibioUynPWm4xN
 cfsg+8WuxWJW+ZAD/olMGDR2rQbJ
X-Google-Smtp-Source: APiQypL32vsxRZanS1NtlmQKFUKLhxnlSdDfEXm+decCbPDZhmOs0AEQ68A8akHQ39nI7acivelvmQ==
X-Received: by 2002:a05:620a:13b9:: with SMTP id
 m25mr25458664qki.456.1588046782950; 
 Mon, 27 Apr 2020 21:06:22 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:22 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 19/21] libxl: Refactor kill_device_model to
 libxl__kill_xs_path
Date: Tue, 28 Apr 2020 00:04:31 -0400
Message-Id: <20200428040433.23504-20-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Move kill_device_model to libxl__kill_xs_path so we have a helper to
kill a process from a pid stored in xenstore.  We'll be using it to kill
vchan-qmp-proxy.

libxl__kill_xs_path takes a "what" string for use in printing error
messages.  kill_device_model is retained in libxl_dm.c to provide the
string.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 tools/libxl/libxl_aoutils.c  | 32 ++++++++++++++++++++++++++++++++
 tools/libxl/libxl_dm.c       | 27 +--------------------------
 tools/libxl/libxl_internal.h |  3 +++
 3 files changed, 36 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 1be858c93c..c4c095a5ba 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -626,6 +626,38 @@ void libxl__kill(libxl__gc *gc, pid_t pid, int sig, const char *what)
                 what, (unsigned long)pid, sig);
 }
 
+/* Generic function to signal (HUP) a pid stored in xenstore */
+int libxl__kill_xs_path(libxl__gc *gc, const char *xs_path_pid,
+                        const char *what)
+{
+    const char *xs_pid;
+    int ret, pid;
+
+    ret = libxl__xs_read_checked(gc, XBT_NULL, xs_path_pid, &xs_pid);
+    if (ret || !xs_pid) {
+        LOG(ERROR, "unable to find %s pid in %s", what, xs_path_pid);
+        ret = ret ? : ERROR_FAIL;
+        goto out;
+    }
+    pid = atoi(xs_pid);
+
+    ret = kill(pid, SIGHUP);
+    if (ret < 0 && errno == ESRCH) {
+        LOG(ERROR, "%s already exited", what);
+        ret = 0;
+    } else if (ret == 0) {
+        LOG(DEBUG, "%s signaled", what);
+        ret = 0;
+    } else {
+        LOGE(ERROR, "failed to kill %s [%d]", what, pid);
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+out:
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a57c13bdf4..10ca4226ba 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -3397,32 +3397,7 @@ out:
 /* Generic function to signal a Qemu instance to exit */
 static int kill_device_model(libxl__gc *gc, const char *xs_path_pid)
 {
-    const char *xs_pid;
-    int ret, pid;
-
-    ret = libxl__xs_read_checked(gc, XBT_NULL, xs_path_pid, &xs_pid);
-    if (ret || !xs_pid) {
-        LOG(ERROR, "unable to find device model pid in %s", xs_path_pid);
-        ret = ret ? : ERROR_FAIL;
-        goto out;
-    }
-    pid = atoi(xs_pid);
-
-    ret = kill(pid, SIGHUP);
-    if (ret < 0 && errno == ESRCH) {
-        LOG(ERROR, "Device Model already exited");
-        ret = 0;
-    } else if (ret == 0) {
-        LOG(DEBUG, "Device Model signaled");
-        ret = 0;
-    } else {
-        LOGE(ERROR, "failed to kill Device Model [%d]", pid);
-        ret = ERROR_FAIL;
-        goto out;
-    }
-
-out:
-    return ret;
+    return libxl__kill_xs_path(gc, xs_path_pid, "Device Model");
 }
 
 /* Helper to destroy a Qdisk backend */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 00cfbe1fac..32aa797714 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2707,6 +2707,9 @@ int libxl__async_exec_start(libxl__async_exec_state *aes);
 bool libxl__async_exec_inuse(const libxl__async_exec_state *aes);
 
 _hidden void libxl__kill(libxl__gc *gc, pid_t pid, int sig, const char *what);
+/* kill SIGHUP a pid stored in xenstore */
+_hidden int libxl__kill_xs_path(libxl__gc *gc, const char *xs_path_pid,
+                                const char *what);
 
 /*----- device addition/removal -----*/
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:07:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:07:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHWV-0001U8-PS; Tue, 28 Apr 2020 04:07:07 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHWU-0001SI-4H
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:07:06 +0000
X-Inumbo-ID: a1128498-8905-11ea-b07b-bc764e2007e4
Received: from mail-qv1-xf42.google.com (unknown [2607:f8b0:4864:20::f42])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a1128498-8905-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:25 +0000 (UTC)
Received: by mail-qv1-xf42.google.com with SMTP id y19so9757542qvv.4
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=OmhxLHIrfW/RVN+5SOVZowWAiFw0cbMfDhtgV3wqCnU=;
 b=bg3Zvrsiv9zFYEa7cM5egtX3ROnTgjnrSRZM1p8HrJD7F7FrT7TlrnPZGsmZzEzL4J
 b/2pDHw/WTDLcNYgFN0+74nMz9im+XtS3TQNEewchEmgSc70bLKM4JEAJvw1sBsQvkFi
 f3z2EBAxhoF9o24idxWib8NC3zFgfUlM9o+5ULORuy7gzdWgd9uezem5DxhTHDX62V43
 KBVVWGTX40Dr7YF081F9jzvfsquJ++gCRlf1rfpeC67SaAyzHGJaiqijK+6EEY+l3FC0
 THR95kTDJ8g9MrQnJwMjvcf3RSpK2gRnTE2CE7BVOZu4mplpvRWZr/XIDx4VgbNhK3Rq
 i6iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=OmhxLHIrfW/RVN+5SOVZowWAiFw0cbMfDhtgV3wqCnU=;
 b=m6XvqjW87BozZVH5zFj2cA5jZTUGFz6tzQrzocTySwtHDZM4m00zTkRg5bm8iq3hp4
 QTmCT9/Z+quEN3jrjvZzhpoblDo03ufoUZVYpLkuIW9QE7TEo7/793WdmYv2jul4yego
 ti5RNve2I0DW894kyy6wrMXonHSMZYJWlg4MmwNpIRVDLBssu0R5jQsD3z6ANEuF/r0e
 gcvODuSWLALg83NsOk7eF/TQMSUw4O28vBlNoTRCsdI2DVBrxn26f/0YyV+W4aSbS7eX
 0jhuckqTcr9lQ5jlRZwccRhiyPTMvXBHhlGZzatI3NkODmnqJSLwsjBq2xoYwuK3qlDq
 FEDQ==
X-Gm-Message-State: AGi0PubbDDpT1j9Q3lBNCnwifcjTBIiX7wcfn6+FC+j+olMSfeAzGnI/
 zbfHve+uMaNnNkdxSnEWAsYvnvI9
X-Google-Smtp-Source: APiQypI52GnSDDusVyNK8D3yfYR5vLp0fsZOWFVjbEe/0XywspZxG4Cr6dMdTn7fq5ST5MCLx8XDQw==
X-Received: by 2002:a0c:99ca:: with SMTP id y10mr19107544qve.217.1588046785230; 
 Mon, 27 Apr 2020 21:06:25 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:24 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 20/21] libxl: Kill vchan-socket-proxy when cleaning up qmp
Date: Tue, 28 Apr 2020 00:04:32 -0400
Message-Id: <20200428040433.23504-21-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
 Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We need to kill the vchan-socket-proxy so we don't leak the daemonized
processes.  libxl__stubdomain_is_linux_running works against the
guest_domid, but the xenstore path is beneath the stubdomain.  This
leads to the use of libxl_is_stubdom in addition to
libxl__stubdomain_is_linux_running so that the stubdomain calls kill for
the qmp-proxy

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
libxl__qmp_cleanup was considered, but it is not called for guests with
a stubdomain.
---
 tools/libxl/libxl_domain.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index fef2cd4e13..3b66e25aa7 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1260,10 +1260,17 @@ static void dm_destroy_cb(libxl__egc *egc,
     libxl__destroy_domid_state *dis = CONTAINER_OF(ddms, *dis, ddms);
     STATE_AO_GC(dis->ao);
     uint32_t domid = dis->domid;
+    uint32_t target_domid;
 
     if (rc < 0)
         LOGD(ERROR, domid, "libxl__destroy_device_model failed");
 
+    if (libxl_is_stubdom(CTX, domid, &target_domid) &&
+        libxl__stubdomain_is_linux_running(gc, target_domid)) {
+        char *path = GCSPRINTF("/local/domain/%d/image/qmp-proxy-pid", domid);
+        libxl__kill_xs_path(gc, path, "QMP Proxy");
+    }
+
     dis->drs.ao = ao;
     dis->drs.domid = domid;
     dis->drs.callback = devices_destroy_cb;
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 04:07:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 04:07:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTHWb-0001Yz-2z; Tue, 28 Apr 2020 04:07:13 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTHWZ-0001XE-4f
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 04:07:11 +0000
X-Inumbo-ID: a27849d0-8905-11ea-b07b-bc764e2007e4
Received: from mail-qv1-xf41.google.com (unknown [2607:f8b0:4864:20::f41])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a27849d0-8905-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 04:06:28 +0000 (UTC)
Received: by mail-qv1-xf41.google.com with SMTP id ck5so2986161qvb.11
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 21:06:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=62xznBzAJrZ5cBLJ6CH8pd+32QEr+JtnkMAlzxn5W2w=;
 b=bXTbQKnEynKDrvf8b9s3N/Gt9pB8jg+WpOAo3c8oczvyv/ZvMx+Vz3Bn27Up4YWLhM
 pmI5N8dyG6Pn80b8u4Rs/p5RxJUa0F7ar1LyF35vSW78hZaMa2OuEACpw/PLuYyov53k
 MmNcd5WjTDs2x3P5BjU1YDc+ONa/e89QUC/sd1cj2y3b+EOmQVuViqLcE8Y194DIlQ8R
 /ZVPOE+ylmS4+QEEEKxVwZ2ZYS2AtEKLUAwdH0hMbt5W8dWS0nhwUXM+df/lQEjZZnsI
 I+gZPwCllD/WUwUX61N31ah7t1g+yc8XKuGuR/ZtdwSqjjOXTiYIIJmOClGJX1VgAWsA
 yWUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=62xznBzAJrZ5cBLJ6CH8pd+32QEr+JtnkMAlzxn5W2w=;
 b=YTd2Xviyk3xILYpKkufTSXSgFFLeMhbMiXOzYNZlrO130JRyznnAzlRT2dzVAV5yHe
 Ok7N5PFKlMlc3QF4o8zW22dCKYvgAPveMzmXY1Eh1ecuxv3Y8Hcn90Woi6rGVssu5NuO
 9kkpe9hgeDSCh9r50QQJcCVYYu4wLxzGsJu57BDDmFGIFd1/fWtZEmw2tWnkarx76SoO
 69sh3V6S+qz/1jhoNBa4XeKU0s3vclyniVai3tjsAKdKo9mVtf7w5l0edFUAK5oLLyhl
 0mU6R6fkzHQXXVv+sihMfBLAoTLtV+MVUe/MWBXA+XxELnJuAYgio0k7GBmHXYjTIuI1
 x2mw==
X-Gm-Message-State: AGi0PuZ3C7t97Yw8ixIxgMddEmYK5DWpbNfvidkVuUjpjOnsYAf0qXxy
 uFWegAJxV+2HNL3wmHChNgpmvmcm
X-Google-Smtp-Source: APiQypJJz9jy7S7Ew3uCA+nDzpyziyVQvXa9uf0vY7aQB+TGNx4mkQ5nvc2OxG8y5z5GaMBVpJH3xQ==
X-Received: by 2002:a05:6214:188a:: with SMTP id
 cx10mr26208160qvb.119.1588046787600; 
 Mon, 27 Apr 2020 21:06:27 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:f1d1:23b9:fc94:a1a9])
 by smtp.gmail.com with ESMTPSA id v2sm13445480qth.66.2020.04.27.21.06.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 21:06:26 -0700 (PDT)
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5 21/21] tools: Clean up vchan-socket-proxy socket
Date: Tue, 28 Apr 2020 00:04:33 -0400
Message-Id: <20200428040433.23504-22-jandryuk@gmail.com>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428040433.23504-1-jandryuk@gmail.com>
References: <20200428040433.23504-1-jandryuk@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

To avoid socket files lingering in /run/xen, have vchan-socket-proxy
clean up the sockets it creates.  Use a signal handler as well as atexit
to handle both means of termination.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 tools/libvchan/vchan-socket-proxy.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c
index 13700c5d67..0fb42964b5 100644
--- a/tools/libvchan/vchan-socket-proxy.c
+++ b/tools/libvchan/vchan-socket-proxy.c
@@ -33,6 +33,7 @@
 
 #include <stdlib.h>
 #include <stdio.h>
+#include <signal.h>
 #include <string.h>
 #include <unistd.h>
 #include <fcntl.h>
@@ -88,6 +89,22 @@ char outbuf[BUFSIZE];
 int insiz = 0;
 int outsiz = 0;
 int verbose = 0;
+char *cleanup_socket;
+
+static void cleanup(void)
+{
+    if (cleanup_socket) {
+        unlink(cleanup_socket);
+        free(cleanup_socket);
+        cleanup_socket = NULL;
+    }
+}
+
+static void cleanup_exit(int signum)
+{
+    cleanup();
+    exit(0);
+}
 
 static void vchan_wr(struct libxenvchan *ctrl) {
     int ret;
@@ -394,6 +411,9 @@ int main(int argc, char **argv)
     vchan_path = argv[optind+1];
     socket_path = argv[optind+2];
 
+    signal(SIGHUP, cleanup_exit);
+    signal(SIGTERM, cleanup_exit);
+
     if (is_server) {
         ctrl = libxenvchan_server_init(NULL, domid, vchan_path, 0, 0);
         if (!ctrl) {
@@ -410,6 +430,8 @@ int main(int argc, char **argv)
                 perror("listen socket");
                 return 1;
             }
+            cleanup_socket = strdup(socket_path);
+            atexit(cleanup);
         }
     }
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 05:24:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 05:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTIiu-00022K-KG; Tue, 28 Apr 2020 05:24:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=g9hW=6M=yahoo.com=akm2tosher@srs-us1.protection.inumbo.net>)
 id 1jTIit-00022B-Dq
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 05:23:59 +0000
X-Inumbo-ID: 765c863a-8910-11ea-b07b-bc764e2007e4
Received: from sonic309-22.consmr.mail.ne1.yahoo.com (unknown [66.163.184.148])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 765c863a-8910-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 05:23:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1588051438; bh=IccE9zI+jOrXmKqMzxvR5CDxzXIxE/txvHbTNvRih9E=;
 h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject;
 b=eplkXkbYo7bZMWXZmhQPEqM4FSPVGWHniJSNIo5IpNafsJZbU/GZKAL1xPEWuV5j/HtcwhOQ1cLVmHWuq5P7105iq8bvuX7p/Sp3UhEp3moJTnFhepAdSwO7ozXIF4qjlJMi/+FVxIfuiwEiLbB/cer2CMMuGu4LRj0PHQ9VGUaocmurSbrYGlnOLM27ZQanWTl3exh8kA+szGDcNA008QpTGCsxfURQwKqaAcXcxFmtxutepQiI9wcYcyF4cCHUsNdD7DI1J1+UfnH6HN1S4y5ZOz4GOZykEX21AwPFdlGYA7zA0bfjoNsip6SUBc0dXC+Tusp8ufhvsV3YKNcDkQ==
X-YMail-OSG: pUfwYCIVM1lj5kAFb91FVjcGeb2TUqP.RmXfA7Q1ZM1W9oq2qaRXvaYcLePsBNR
 epdP2uqD.1uHHvwmL9DVHHyGUzqoonWntpZ3tYSHJXf7c2Ef4lfGX0i2.cJ9NgmKCTrUETYjaaFW
 BY03BVoJ7l1sLkPDWmeOpoBSB7CglcQi5QKxYy8FimJqlW3xGRcdVLHQeeh5XrecMztvuHFligea
 y.AUMEbbr.BnWglG356nNBDVQe9fZKe6Man.IXrawg64BiBwnZRY3grU6JMo5.jf3LWE0O5U00uo
 zqZj6z22YAd_Ga7oVBAInpvvQf2r00MsfIKc8hBS_ZKPJKy5PFkJ_0vD_6HMkrD21fgSvNPndt9h
 XKRdX7XVyk7NCpexdWaxejlqFTHkpwkdvkgHOJylyuAqrmma3_HDN62gpmTcCi9OZxDRxj5mCdZk
 YQ09ttiM6Vj4qb9CGLFb5yTM7K5WEEvJ7H7i.09bBFGXM8alyaINxE7dHR86sO5SQeI4e0flWeKi
 ye7wE_LOWk2kvvhD_moAar6pbUJOqikLapcU3c.oKTgOKtAGZz3haJ4zN3VLtIqTNtN5w1c29_sa
 X0MFF0DcBvbN1Y78KJ3.lFdtlr935ps2MkeJFuUplni6OGawRV53DbBV31yufFPL1WVpk49e38gy
 o_9uaNLnIBenBozerUiR7H0T.6QkI98m8pM.0YOPh0zEDk0LPd54uceF_XIbIWJEbC90RgJaUPYS
 Ohr8.yBixAhDuHhrD__hVVrluOG1nQGTw6eJz740jvv5nKLmS1LuLep1YeJwQbIAbj6gfY3fEWUa
 HogGFNhGQ6zgEGzjrQbPNnHCrVNl1UJOJa4uSxftAjv2CsI3Uxt5TI0r0T6IkASQX1oh7uerAL3M
 x34QVMBY4VgATI6dz35by5I2Z1pDBsYDYj8q4Dx.WTooV85VDCST2Bt3U_p4Wefmer7B.1xT4q2U
 M2SR45cF2ZcKqUFlMmcoqQDTksil_Y7YJ_1S04SntT7KtGv5Iolzg_rjp9IpMyTb0gSalwoq8o79
 77RkuS8h5B00qxNqqwCyAp0FHO6cy6VsJ2uyT2OF2DsUomsK8vG31Ri9NcJAzq4v9pfZr0UvnSpo
 7Rr_oIa2FhwIAec84vPyjeMLZqgKeLQSse87s5SzpZETm1DwnC9Np8rDvSKfG5aoovoC9otj0acR
 YOSun6xNTqn7gSALXbR4wIdKWNfSiMXi4fEqfurGi5n1LCYsZQKZRvZ5yl6IeW7yrUXb9JE.F883
 qk18vStXOLui7JXDxyYxSUoSwv5LZ3jldPwPikArKP5PDL6aaUo4AdMzbT_ZEYdmvYWz7HV1NQsD
 lDqazezO5jQK2.l7rF3uKm0Mv1lBll8MWQKMDE1I-
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic309.consmr.mail.ne1.yahoo.com with HTTP; Tue, 28 Apr 2020 05:23:58 +0000
Date: Tue, 28 Apr 2020 05:23:55 +0000 (UTC)
From: tosher 1 <akm2tosher@yahoo.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Message-ID: <1693679742.27711.1588051435928@mail.yahoo.com>
In-Reply-To: <20200427070317.GL28601@Air-de-Roger>
References: <1359850718.562651.1587928713792.ref@mail.yahoo.com>
 <1359850718.562651.1587928713792@mail.yahoo.com>
 <20200427070317.GL28601@Air-de-Roger>
Subject: Re: Xen network domain performance for 10Gb NIC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.15802 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64;
 x64; rv:75.0) Gecko/20100101 Firefox/75.0
Content-Length: 598
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> Driver domains with passthrough devices need to perform IOMMU
operations in order to add/remove page table entries when doing grant
maps (ie: IOMMU TLB flushes), while dom0 doesn't need to because it
has the whole RAM identity mapped in the IOMMU tables. Depending on
how fast your IOMMU is and what capabilities it has doing such
operations can introduce a significant amount of overhead.

It makes sense to me. Do you know, in general, how to measure IOMMU performance, and what features/properties of IOMMU can contribute to getting a better network throughput? Please let me know. 

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 06:15:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 06:15:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTJWC-0006xE-UT; Tue, 28 Apr 2020 06:14:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTJWC-0006x9-An
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 06:14:56 +0000
X-Inumbo-ID: 93d1ed02-8917-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 93d1ed02-8917-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 06:14:55 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E4800AECD;
 Tue, 28 Apr 2020 06:14:52 +0000 (UTC)
Subject: Re: [PATCH 0/2] x86: high compat r/o M2P table handling adjustments
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <cover.1586352238.git.hongyxia@amazon.com>
 <91728ed9a191160e6405267f5ae05cb6d3724f22.1586352238.git.hongyxia@amazon.com>
 <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
Message-ID: <e8902061-702b-e049-a541-a4422de70a9e@suse.com>
Date: Tue, 28 Apr 2020 08:14:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <fc61fd42-0e09-0f13-bccb-ba0202d936ca@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Hongyan Xia <hx242@xen.org>, xen-devel@lists.xenproject.org, julien@xen.org,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 15.04.2020 10:21, Jan Beulich wrote:
> While looking at "x86_64/mm: map and unmap page tables in
> destroy_compat_m2p_mapping" it occurred to me that the mappings
> changed there can be dropped altogether, as can the linear
> address range used for this. Note that both patches have only
> been lightly tested so far, I guess in particular the 2nd one
> may still have issues.
> 
> 1: x86: drop unnecessary page table walking in compat r/o M2P handling
> 2: x86: drop high compat r/o M2P table address range

Just fyi - with the reviews I've got I'm intending to commit
this later this week, unless I hear otherwise soon.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 06:30:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 06:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTJl3-0000Bo-EO; Tue, 28 Apr 2020 06:30:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTJl2-0000Bj-99
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 06:30:16 +0000
X-Inumbo-ID: b862ae20-8919-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b862ae20-8919-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 06:30:15 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 97538AC12;
 Tue, 28 Apr 2020 06:30:13 +0000 (UTC)
Subject: Re: [PATCH] x86: refine guest_mode()
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <7b62d06c-1369-2857-81c0-45e2434357f4@suse.com>
 <1704f4f6-7e77-971c-2c94-4f6a6719c34a@citrix.com>
 <5bbe6425-396c-d934-b5af-53b594a4afbc@suse.com>
 <16939982-3ccc-f848-0694-61b154dca89a@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <5ce12c86-c894-4a2c-9fa6-1c2a6007ca28@suse.com>
Date: Tue, 28 Apr 2020 08:30:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <16939982-3ccc-f848-0694-61b154dca89a@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.2020 22:11, Andrew Cooper wrote:
> On 27/04/2020 16:15, Jan Beulich wrote:
>> On 27.04.2020 16:35, Andrew Cooper wrote:
>>> On 27/04/2020 09:03, Jan Beulich wrote:
>>>> The 2nd of the assertions as well as the macro's return value have been
>>>> assuming we're on the primary stack. While for most IST exceptions we
>>>> eventually switch back to the main one,
>>> "we switch to the main one when interrupting user mode".
>>>
>>> "eventually" isn't accurate as it is before we enter C.
>> Right, will change.
>>
>>>> --- a/xen/include/asm-x86/regs.h
>>>> +++ b/xen/include/asm-x86/regs.h
>>>> @@ -10,9 +10,10 @@
>>>>      /* Frame pointer must point into current CPU stack. */                    \
>>>>      ASSERT(diff < STACK_SIZE);                                                \
>>>>      /* If not a guest frame, it must be a hypervisor frame. */                \
>>>> -    ASSERT((diff == 0) || (r->cs == __HYPERVISOR_CS));                        \
>>>> +    if ( diff < PRIMARY_STACK_SIZE )                                          \
>>>> +        ASSERT(!diff || ((r)->cs == __HYPERVISOR_CS));                        \
>>>>      /* Return TRUE if it's a guest frame. */                                  \
>>>> -    (diff == 0);                                                              \
>>>> +    !diff || ((r)->cs != __HYPERVISOR_CS);                                    \
>>> The (diff == 0) already worried me before because it doesn't fail safe,
>>> but this makes things more problematic.  Consider the case back when we
>>> had __HYPERVISOR_CS32.
>> Yes - if __HYPERVISOR_CS32 would ever have been to be used for
>> anything, it would have needed checking for here.
>>
>>> Guest mode is strictly "(r)->cs & 3".
>> As long as CS (a) gets properly saved (it's a "manual" step for
>> SYSCALL/SYSRET as well as #VMEXIT) and (b) didn't get clobbered. I
>> didn't write this code, I don't think, so I can only guess that
>> there were intentions behind this along these lines.
> 
> Hmm - the VMExit case might be problematic here, due to the variability
> in the poison used.

"Variability" is an understatement - there's no poisoning at all
in release builds afaics (and to be honest it seems a somewhat
pointless to write the same values over and over again in debug
mode). With this, ...

>>> Everything else is expectations about how things ought to be laid out,
>>> but for safety in release builds, the final judgement should not depend
>>> on the expectations evaluating true.
>> Well, I can switch to a purely CS.RPL based approach, as long as
>> we're happy to live with the possible downside mentioned above.
>> Of course this would then end up being a more intrusive change
>> than originally intended ...
> 
> I'd certainly prefer to go for something which is more robust, even if
> it is a larger change.

... what's your suggestion? Basing on _just_ CS.RPL obviously won't
work. Not even if we put in place the guest's CS (albeit that
somewhat depends on the meaning we assign to the macro's returned
value). Using current inside the macro to determine whether the
guest is HVM would also seem fragile to me - there are quite a few
uses of guest_mode(). Which would leave passing in a const struct
vcpu * (or domain *), requiring to touch all call sites, including
Arm's.

Compared to this it would seem to me that the change as presented
is a clear improvement without becoming overly large of a change.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 06:30:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 06:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTJlV-0000En-NT; Tue, 28 Apr 2020 06:30:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wX7d=6M=gmail.com=gorbak25@srs-us1.protection.inumbo.net>)
 id 1jTJkb-0007ym-QT
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 06:29:49 +0000
X-Inumbo-ID: a8812798-8919-11ea-b9cf-bc764e2007e4
Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a8812798-8919-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 06:29:48 +0000 (UTC)
Received: by mail-wr1-x444.google.com with SMTP id k1so23236866wrx.4
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 23:29:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=6BE++WsHDYO/WOBqJLui7tOCRnqB8ihSSf6W8ZHJC58=;
 b=nM9hl7S7+RQTxl+m0wJsf+Uu39xU2juocV+4M9QJrHIoCFJvGsuda+dbtbNNNC/9/9
 mVR8wmkJ/tJRrYnmlLK4j1TcQwphdLKdugvkCOYO6oZXIfwLH4JGEAQUC0zUS633O5bH
 rLVNnETO10FU58TlVyXSCb4qyjobuNqSUn3sRZ5/M+6BLkAmigKTu/9rErt+DYJgO+x1
 UeiUS5fGO5n2RRKGY0yR8Ubx+h7aTmb3FbV4osINY5RLLa9a371bXCr7MChrtwdPuqoJ
 6utk6llcKNACK+u1/711wpRJJRLljc1j1q5eS+Ai0alnoDUWafB2vpccVKZtKav+Ws+I
 ziIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=6BE++WsHDYO/WOBqJLui7tOCRnqB8ihSSf6W8ZHJC58=;
 b=lwt63TqmMIO0TJ2Iia8IDYUwpgclgyDj5BA1eRc+MpGSJmDBmqeRWh7bqXbv/f7l2T
 XlnIruGeIgl4UO58X1uyCrbT8ux2B6EqeWK2WdThCkeEvH1eYKfWx6h6i7HocLs/97Vg
 /ygwc6z1HWJXdg+xuUXpNH2zuPX0n1kpWhJ37HA8hj9eGoSyr8byZrS5LNS7iHWkeo8Y
 3nEsW2687mzOwAsKu93pX7I1R5c4kQAgDLyTg5+GWR3Wev2U3HhjyLi7FGYi6UNq5Xtz
 UhCSngK6xyWbAsAjEbZRbeah+AAWj7RJLZ1/IVgBrbsfZ2Y3jhnMuPPSPHbp6blA8V+d
 e//w==
X-Gm-Message-State: AGi0PuarvOu+Qde1KlRygcQn5ITLbHOWvH0euiIr0KiLhYEDmdf7uVux
 YMdMad9fuel8bXXIgXUePuM=
X-Google-Smtp-Source: APiQypKMJeOYX3PcohWzIS41hAKPeyC3HjuX1SjsDhBdVcAyjumoMDzsHpT/1m0Gnu0C1B4RG+D8jw==
X-Received: by 2002:adf:dd8a:: with SMTP id x10mr31936913wrl.308.1588055387873; 
 Mon, 27 Apr 2020 23:29:47 -0700 (PDT)
Received: from localhost.localdomain (public-gprs351065.centertel.pl.
 [37.47.2.154])
 by smtp.gmail.com with ESMTPSA id a205sm2030564wmh.29.2020.04.27.23.29.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 23:29:47 -0700 (PDT)
From: Grzegorz Uriasz <gorbak25@gmail.com>
To: qemu-devel@nongnu.org
Subject: [PATCH 0/2] Fix QEMU crashes when passing IGD to a guest VM under XEN
Date: Tue, 28 Apr 2020 06:28:45 +0000
Message-Id: <20200428062847.7764-1-gorbak25@gmail.com>
X-Mailer: git-send-email 2.26.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Tue, 28 Apr 2020 06:30:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: artur@puzio.waw.pl, Stefano Stabellini <sstabellini@kernel.org>,
 Paul Durrant <paul@xen.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, Grzegorz Uriasz <gorbak25@gmail.com>,
 Anthony Perard <anthony.perard@citrix.com>, j.nowak26@student.uw.edu.pl,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


Hi,

This patch series is a small subset of a bigger patch set spanning few projects aiming to isolate the GPU
in QUBES OS to a dedicated security domain. I'm doing this together with 3 colleagues as part of our Bachelors thesis.

When passing an Intel Graphic Device to a HVM guest under XEN, QEMU sometimes crashes
when starting the VM. It turns out that the code responsible for setting up
the legacy VBIOS for the IGD contains a bug which results in a memcpy of an undefined size
between the QEMU heap and the physical memory of the guest.

If the size of the memcpy is small enough qemu does not crash - this means that this
bug is actually a small security issue - a hostile guest kernel might determine the memory layout of
QEMU simply by looking at physical memory beyond 0xdffff - this defeats ASLR and might make exploitation
easier if other issues were to be found.

The problem is the current mechanism for obtaining a copy of the ROM of the IGD.
We first allocate a buffer which holds the vbios - the size of which is obtained from sysfs.
We then try to read the rom from sysfs, if we fail then we just return without setting the size of the buffer.
This would be ok if the size of the ROM reported by sysfs would be 0, but the size is always 32 pages as this corresponds
to legacy memory ranges. It turns out that reading the ROM fails on every single device I've tested(spanning few
generations of IGD), which means qemu never sets the size of the buffer and returns a valid pointer to code which
basically does a memcpy of an undefined size.

I'm including two patches.
The first one fixes the security issue by making failing to read the ROM from sysfs fatal.
The second patch introduces a better method for obtaining the VBIOS. I've haven't yet seen a single device on which
the old code was working, the new code basically creates a shadow copy directly by reading from /dev/mem - this
should be fine as a quick grep of the codebase shows that this approach is already being used to handle MSI.
I've tested the new code on few different laptops and it works fine and the guest VMS finally stopped complaining that
the VBIOS tables are missing.

Grzegorz Uriasz (2):
  Fix undefined behaviour
  Improve legacy vbios handling

 hw/xen/xen_pt.c          |  8 +++++--
 hw/xen/xen_pt_graphics.c | 48 +++++++++++++++++++++++++++++++++++++---
 hw/xen/xen_pt_load_rom.c | 13 +++++------
 3 files changed, 57 insertions(+), 12 deletions(-)

-- 
2.26.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 06:30:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 06:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTJlV-0000F2-Uv; Tue, 28 Apr 2020 06:30:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wX7d=6M=gmail.com=gorbak25@srs-us1.protection.inumbo.net>)
 id 1jTJkl-0007z5-Ly
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 06:29:59 +0000
X-Inumbo-ID: aea86df2-8919-11ea-b07b-bc764e2007e4
Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id aea86df2-8919-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 06:29:59 +0000 (UTC)
Received: by mail-wm1-x342.google.com with SMTP id x4so1372373wmj.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 23:29:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=/xdW9TlF14cno7Dox1YULYIivWRvz4pvd3kbVi7j+L4=;
 b=LFE04p88MpHoPldLuBL/ef/Ua1bNp9e+y/AioN8MiM9U5SHhMHb2oaOuIHdrgUrfvp
 OwWz5i3q1Tu4LjPp1sZH+uewJSXti8ttRSe8d4o4Yu9774I62ekPt4PWwGGhSWeKwURe
 Ujhqmqn4J7uo8NwSOeHNm7zB07nEI89ZLHKzkvQ6aAibNYyiRGvStPM8fWwvmlIgeLf0
 kL5lPAGouNRIDqC54gdYhcUeIT8+TvQlmoaylTU7gdf5GOflOAULoHvyg0STXeW1JqD2
 b3Wb8+3KZ0w1uJGCNf8Yoy4RhiJJW0ZhIBUJTUGabjsPKXlvUQHvXTzw9rBHXagIZJky
 8iiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=/xdW9TlF14cno7Dox1YULYIivWRvz4pvd3kbVi7j+L4=;
 b=RQ+aRrLA2DpPXB1QVykAnR26xrUDjC0lGMb0qPmX/x6uW0Re9tV1UZn5BlVK+XZ85E
 E5To4QvS9hjJ15zHwQ25u7QSPYRWta0Uz91/CGKEXuoPkw7BhUMUsyGCDncAtYTPJKGz
 LqYtvBHq7FwvV4wepJhoF+CUwAzj61/3MXYTrn3kX/hxTdCtsAkLh8xaQ1Q5f/K1qAUB
 xDc5AlmDuWgnij1cDBwVRnp00wMqNAGagzSon6vAiNJR/aaY18pB1NKO3B7uJqO4MCNc
 TFdiGc8ygkQ4GVAsAWbMFN/Y2khc93LtB2R+g289RmXCYnlbuV5qxg/8s7PbO/gOVpXA
 /GJg==
X-Gm-Message-State: AGi0PubY9upUSytV46+pHkCCcZl0puaKxYSJ3DRjCUbm9hwM25WYkkBU
 3pT5t2ZJoAPVcautz2iD6sw=
X-Google-Smtp-Source: APiQypJjAWImZKi6yyETe7bMvdVFmRMyX+Q/xhJCHdWzOGMOtz5pIllYGMr6MRFpzeCK7ibGxixnWw==
X-Received: by 2002:a1c:8106:: with SMTP id c6mr2746244wmd.88.1588055398259;
 Mon, 27 Apr 2020 23:29:58 -0700 (PDT)
Received: from localhost.localdomain (public-gprs351065.centertel.pl.
 [37.47.2.154])
 by smtp.gmail.com with ESMTPSA id a205sm2030564wmh.29.2020.04.27.23.29.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 23:29:57 -0700 (PDT)
From: Grzegorz Uriasz <gorbak25@gmail.com>
To: qemu-devel@nongnu.org
Subject: [PATCH 1/2] Fix undefined behaviour
Date: Tue, 28 Apr 2020 06:28:46 +0000
Message-Id: <20200428062847.7764-2-gorbak25@gmail.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200428062847.7764-1-gorbak25@gmail.com>
References: <20200428062847.7764-1-gorbak25@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Tue, 28 Apr 2020 06:30:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: artur@puzio.waw.pl, Stefano Stabellini <sstabellini@kernel.org>,
 Paul Durrant <paul@xen.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, Grzegorz Uriasz <gorbak25@gmail.com>,
 Anthony Perard <anthony.perard@citrix.com>, j.nowak26@student.uw.edu.pl,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>
---
 hw/xen/xen_pt_load_rom.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index a50a80837e..9f100dc159 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -38,12 +38,12 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
     fp = fopen(rom_file, "r+");
     if (fp == NULL) {
         if (errno != ENOENT) {
-            error_report("pci-assign: Cannot open %s: %s", rom_file, strerror(errno));
+            warn_report("pci-assign: Cannot open %s: %s", rom_file, strerror(errno));
         }
         return NULL;
     }
     if (fstat(fileno(fp), &st) == -1) {
-        error_report("pci-assign: Cannot stat %s: %s", rom_file, strerror(errno));
+        warn_report("pci-assign: Cannot stat %s: %s", rom_file, strerror(errno));
         goto close_rom;
     }
 
@@ -59,10 +59,9 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
     memset(ptr, 0xff, st.st_size);
 
     if (!fread(ptr, 1, st.st_size, fp)) {
-        error_report("pci-assign: Cannot read from host %s", rom_file);
-        error_printf("Device option ROM contents are probably invalid "
-                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
-                     "or load from file with romfile=\n");
+        warn_report("pci-assign: Cannot read from host %s", rom_file);
+        memory_region_unref(&dev->rom);
+        ptr = NULL;
         goto close_rom;
     }
 
-- 
2.26.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 06:30:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 06:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTJlW-0000FR-7F; Tue, 28 Apr 2020 06:30:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wX7d=6M=gmail.com=gorbak25@srs-us1.protection.inumbo.net>)
 id 1jTJkq-0008HL-Uc
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 06:30:04 +0000
X-Inumbo-ID: b1ca9e74-8919-11ea-9887-bc764e2007e4
Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b1ca9e74-8919-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 06:30:04 +0000 (UTC)
Received: by mail-wr1-x444.google.com with SMTP id k13so23235831wrw.7
 for <xen-devel@lists.xenproject.org>; Mon, 27 Apr 2020 23:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=yaK0Tjz4Mh+yIXINkTHSBD8ilpF6Ag6GsRW6Q4ivbTA=;
 b=R5NuyA6+wVEyDRerxt4JF4uR7UXbtDIJQluhU5qdZRUx9wPQijBaoWHuKExJN5wcHQ
 dVVb7NvWWvf+1x2czH+0zGPevI1byLqnHr0MPTULlbp1TmfLkOR7zhSX12CHtxPziZqE
 gIYYkCH2yH67+b14kvapCJJAkntr5shxNmrmXBWoPuyBdwMyFzJ3yTMESUZS+Y0tVk4w
 DTWuCjUR+LEPcrjoz1zyxDLbyWhlSB376x47pXgSXHBY/FF+FiAJhzVWWhXvFZ2IEc+f
 tHNOsxrLpYTCg1pxz6A04Dsg5icQdRwAAw0m5HdjYoYhhxeOJb88DkJS8DbXJXz+Th1F
 xAyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=yaK0Tjz4Mh+yIXINkTHSBD8ilpF6Ag6GsRW6Q4ivbTA=;
 b=f2Rf9mam1p9kw5Quesark8tiqfc1nUAMeOmxTHBIkKgpr7lF4KqK2SFn3M3KLhYVCv
 t9SwceIwCXfftfWB+aQuwZTtPwBu7rUDDRzB+PB4vvOMQ4xcq5FhgGFACaDKHIqwpzLV
 f/BYL3y5ZNcHk5Fi1P1ji3Sasfe7Mxdf0KVNe7C3CN6gWrW/3c+cM3Rlz2eybx+X1wdy
 9bsFFAsTBRdLsffCnV5yxUtvXKKDk7iCBLwWfGu76pAv/OyRmUWIa+aZJ2tM6s56e7V3
 ADP7TPqQ3WzS2arkYZYC+9cpnzUf7Y1CzD1k3yUSFmBRCYBN/Uo8uAxGYj1VQSjAp5bd
 z2Tg==
X-Gm-Message-State: AGi0PuZZrIho/gmRMHxuWPtJjRBtxlfbSv/UfcsYcQy/rUKBTSGm598e
 PvxZyFsGrZRo7nEulvrG4tM=
X-Google-Smtp-Source: APiQypJu6V8g7t351GQHZKstcuogANA7URIwmgoWma5c7hYJSKzrp8DyniKXjLah1RJeLvvREzjpfw==
X-Received: by 2002:adf:f8c6:: with SMTP id f6mr34233073wrq.276.1588055403438; 
 Mon, 27 Apr 2020 23:30:03 -0700 (PDT)
Received: from localhost.localdomain (public-gprs351065.centertel.pl.
 [37.47.2.154])
 by smtp.gmail.com with ESMTPSA id a205sm2030564wmh.29.2020.04.27.23.30.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Apr 2020 23:30:02 -0700 (PDT)
From: Grzegorz Uriasz <gorbak25@gmail.com>
To: qemu-devel@nongnu.org
Subject: [PATCH 2/2] Improve legacy vbios handling
Date: Tue, 28 Apr 2020 06:28:47 +0000
Message-Id: <20200428062847.7764-3-gorbak25@gmail.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200428062847.7764-1-gorbak25@gmail.com>
References: <20200428062847.7764-1-gorbak25@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Tue, 28 Apr 2020 06:30:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: artur@puzio.waw.pl, Stefano Stabellini <sstabellini@kernel.org>,
 Paul Durrant <paul@xen.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, Grzegorz Uriasz <gorbak25@gmail.com>,
 Anthony Perard <anthony.perard@citrix.com>, j.nowak26@student.uw.edu.pl,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>
---
 hw/xen/xen_pt.c          |  8 +++++--
 hw/xen/xen_pt_graphics.c | 48 +++++++++++++++++++++++++++++++++++++---
 hw/xen/xen_pt_load_rom.c |  2 +-
 3 files changed, 52 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index b91082cb8b..ffc3559dd4 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -483,8 +483,12 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd)
                    i, r->size, r->base_addr, type);
     }
 
-    /* Register expansion ROM address */
-    if (d->rom.base_addr && d->rom.size) {
+    /*
+     * Register expansion ROM address. If we are dealing with a ROM
+     * shadow copy for legacy vga devices then don't bother to map it
+     * as previous code creates a proper shadow copy
+     */
+    if (d->rom.base_addr && d->rom.size && !(is_igd_vga_passthrough(d))) {
         uint32_t bar_data = 0;
 
         /* Re-set BAR reported by OS, otherwise ROM can't be read. */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index a3bc7e3921..fe0ef2685c 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -129,7 +129,7 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
     return 0;
 }
 
-static void *get_vgabios(XenPCIPassthroughState *s, int *size,
+static void *get_sysfs_vgabios(XenPCIPassthroughState *s, int *size,
                        XenHostPCIDevice *dev)
 {
     return pci_assign_dev_load_option_rom(&s->dev, size,
@@ -137,6 +137,45 @@ static void *get_vgabios(XenPCIPassthroughState *s, int *size,
                                           dev->dev, dev->func);
 }
 
+static void xen_pt_direct_vbios_copy(XenPCIPassthroughState *s, Error **errp)
+{
+    int fd = -1;
+    void *guest_bios = NULL;
+    void *host_vbios = NULL;
+    /* This is always 32 pages in the real mode reserved region */
+    int bios_size = 32 << XC_PAGE_SHIFT;
+    int vbios_addr = 0xc0000;
+
+    fd = open("/dev/mem", O_RDONLY);
+    if (fd == -1) {
+        error_setg(errp, "Can't open /dev/mem: %s", strerror(errno));
+        return;
+    }
+    host_vbios = mmap(NULL, bios_size,
+            PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, fd, vbios_addr);
+    close(fd);
+
+    if (host_vbios == MAP_FAILED) {
+        error_setg(errp, "Failed to mmap host vbios: %s", strerror(errno));
+        return;
+    }
+
+    memory_region_init_ram(&s->dev.rom, OBJECT(&s->dev),
+            "legacy_vbios.rom", bios_size, &error_abort);
+    guest_bios = memory_region_get_ram_ptr(&s->dev.rom);
+    memcpy(guest_bios, host_vbios, bios_size);
+
+    if (munmap(host_vbios, bios_size) == -1) {
+        XEN_PT_LOG(&s->dev, "Failed to unmap host vbios: %s\n", strerror(errno));
+    }
+
+    cpu_physical_memory_write(vbios_addr, guest_bios, bios_size);
+    memory_region_set_address(&s->dev.rom, vbios_addr);
+    pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->dev.rom);
+    s->dev.has_rom = true;
+    XEN_PT_LOG(&s->dev, "Legacy VBIOS registered\n");
+}
+
 /* Refer to Seabios. */
 struct rom_header {
     uint16_t signature;
@@ -179,9 +218,11 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
         return;
     }
 
-    bios = get_vgabios(s, &bios_size, dev);
+    bios = get_sysfs_vgabios(s, &bios_size, dev);
     if (!bios) {
-        error_setg(errp, "VGA: Can't get VBIOS");
+        XEN_PT_LOG(&s->dev, "Unable to get host VBIOS from sysfs - "
+                            "falling back to a direct copy of memory ranges\n");
+        xen_pt_direct_vbios_copy(s, errp);
         return;
     }
 
@@ -223,6 +264,7 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
 
     /* Currently we fixed this address as a primary for legacy BIOS. */
     cpu_physical_memory_write(0xc0000, bios, bios_size);
+    XEN_PT_LOG(&s->dev, "Legacy VBIOS registered\n");
 }
 
 uint32_t igd_read_opregion(XenPCIPassthroughState *s)
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 9f100dc159..8cd9aa84dc 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -65,7 +65,7 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
         goto close_rom;
     }
 
-    pci_register_bar(dev, PCI_ROM_SLOT, 0, &dev->rom);
+    pci_register_bar(dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_SPACE_MEMORY, &dev->rom);
     dev->has_rom = true;
     *size = st.st_size;
 close_rom:
-- 
2.26.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 07:07:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 07:07:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTKL7-0003O9-VY; Tue, 28 Apr 2020 07:07:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=p0bN=6M=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jTKL7-0003O4-03
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 07:07:33 +0000
X-Inumbo-ID: ed9705a0-891e-11ea-ae69-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ed9705a0-891e-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 07:07:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588057652;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=eAIEH6PwI+/cm8d/4tCn9x5yNlj1YcxBr6Y/UP99M1c=;
 b=HcFc+UZglBnqB1/hganI/pg1/IvR7lrmo+INutoRqnI+JmIejXmZ9yHW
 GIANo+rk+vm/+yIZm9JTyMc5JBNIxpoq/AopXGwknHEWB/cHDuF3oZ/nW
 IYNlPhVKrxQJt2j/OpOiWS7hiQf4weXjcfdopm/st1ZoAGtLvdTvPzF6O s=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 4yJmwIG3VKIi3zwwoo7bxWkGV8dIafWEOwB4BR8DvhsJoR+Ok1woIU0Ge3C2fGgJwuwVBo1lQg
 jB0Fus8wyEau+hj04wJx4NH8CyTuiAUf4EV3nL1/Y+c+TyY49QjseB5B42hQtfG9Se/PpdKzLi
 dUnrsQCRXgJlO6EAjz1Ffm5gGqGdeVjSkjcxGFtsNtMTKOQ6lZegkN0KQ9Ik1r+8eLKjTiGzs8
 K3s1sIbcHzC5xzi7yTTDA7fznheyOkB+5S5Ziakd/3LUXd6RP4lSrbwKS86B/DQ9AnSU1ZSbXu
 Drs=
X-SBRS: 2.7
X-MesageID: 16366027
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,327,1583211600"; d="scan'208";a="16366027"
Date: Tue, 28 Apr 2020 09:07:24 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: tosher 1 <akm2tosher@yahoo.com>
Subject: Re: Xen network domain performance for 10Gb NIC
Message-ID: <20200428070724.GS28601@Air-de-Roger>
References: <1359850718.562651.1587928713792.ref@mail.yahoo.com>
 <1359850718.562651.1587928713792@mail.yahoo.com>
 <20200427070317.GL28601@Air-de-Roger>
 <1693679742.27711.1588051435928@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <1693679742.27711.1588051435928@mail.yahoo.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 28, 2020 at 05:23:55AM +0000, tosher 1 wrote:
> > Driver domains with passthrough devices need to perform IOMMU
> operations in order to add/remove page table entries when doing grant
> maps (ie: IOMMU TLB flushes), while dom0 doesn't need to because it
> has the whole RAM identity mapped in the IOMMU tables. Depending on
> how fast your IOMMU is and what capabilities it has doing such
> operations can introduce a significant amount of overhead.
> 
> It makes sense to me. Do you know, in general, how to measure IOMMU performance, and what features/properties of IOMMU can contribute to getting a better network throughput? Please let me know. 

Hm, not really. You would have to modify Xen and/or the Linux kernel
in order to time the IOMMU or the grant map operations in order to get
an idea.

Do you get the expected performance from the driver domain when not
using it as a backend? Ie: running the iperf benchmarks directly on
the driver domain and not on the guest.

Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 07:20:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 07:20:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTKXt-00052Z-Az; Tue, 28 Apr 2020 07:20:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTKXr-00052U-Rg
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 07:20:43 +0000
X-Inumbo-ID: c517941c-8920-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c517941c-8920-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 07:20:43 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 427CFAD63;
 Tue, 28 Apr 2020 07:20:41 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: George Dunlap <George.Dunlap@citrix.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
 <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
 <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <fb0e92cc-102f-7f87-1ad6-f3ccce1eee60@suse.com>
Date: Tue, 28 Apr 2020 09:20:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <Andrew.Cooper3@citrix.com>,
 Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 27.04.2020 18:25, George Dunlap wrote:
> If Jan is OK with it simply being outside CONFIG_EXPERT, then great.  But if he insists on some kind of testing for it to be outside of CONFIG_EXPERT, then again, the people who want it to be security supported should be the ones who do the work to make it happen.

I don't understand this part, I'm afraid: Without a config option,
the code is going to be security supported as long as it doesn't
get marked otherwise (experimental or what not). With an option
depending on EXPERT, what would become security unsupported is the
non-default (i.e. disabled) setting. There's not a whole lot to
test there, it's merely a formal consequence of our general rules.
(Of course, over time dependencies of other code may develop on
the information being available e.g. to Dom0 userland. Just like
there's Linux userland code assuming the kernel config is
available in certain ways [I don't necessarily mean the equivalent
of hypfs here], to then use it in what I'd call abusive ways in at
least some cases.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 07:42:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 07:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTKt4-0006zq-6n; Tue, 28 Apr 2020 07:42:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=CDey=6M=nxp.com=peng.fan@srs-us1.protection.inumbo.net>)
 id 1jTKt3-0006zl-3o
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 07:42:37 +0000
X-Inumbo-ID: d356ab8c-8923-11ea-983b-12813bfff9fa
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown
 [40.107.6.65]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d356ab8c-8923-11ea-983b-12813bfff9fa;
 Tue, 28 Apr 2020 07:42:35 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=lE3TeS5dkRT/u0hmCvM+eWzPLB/At1kA+AJHv7vlEVoZiahHi7TWvqFJ3CW+B0Pp1C+TCZ44qLrF4MVPE9qXIdzJINB9q3tO00NRdgpLQr8bq7tAscdeJouVx8pS0bA5X/avp4D+v8jE7qLZZA8suanrSGetQPS/b96cmd5tiC8PvC6p+HUlXp+SqlfJY58WR8+fOtqZZDLtToObqmkaOOduNMrJtitkBqyGw+kVPaCiCRYl7DrjtBYJI3sC5z+lmETLEp2QJP2ycdcejjREtA38gK6eDH2uGQtrlKMjwV+cbJ7YnRUNE3LO4GnqiJwsEDa2WxdmYLKmVdfi/iFt2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ghtKKDlC9f/+o/B0RxHJt1RlPJtIYobSgYs1yRAo1cI=;
 b=SZ5d5zWMRofV6V/kqtNluQH1KQcezb7683XBFwPvv3701E1+ud47gZVj7qAY1lLmsoZ+1YqNXPkiNP1UhljelUCAd4V7vCe2Ia+IcYC6um/87jxNfNP+YXLfyQRwdiaMX+RpdMHNTLyYp9gQ5c1aX+uS+Uk9s3+wCLe6AVrb2uM0QyV2psNsGGyM0TJ9cQ2C3mFISoObM/RVTi5rB/NbSxw9WdHg1prWdF58ELlUFRUECmIZLiLogeoeCrDME3UBh2wRv3lL4h6gb/52GaPkc473XTJ9Vu4sXzyUSKJBthJqo8slD3O6AodAuujSfFqXWgmKaEynfL6SdtA9hqFuTQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass
 header.d=nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ghtKKDlC9f/+o/B0RxHJt1RlPJtIYobSgYs1yRAo1cI=;
 b=fBYvXLKCy2zEG7eiAYyVyOngVT1E4RUUXYhQiz0AqIH6J67vbSM5ozgw757p1HrBl5edY3pGoRE1n8YTTKyQ7Fi9fnpuiTWOL04UMxa/TrNS99QNLKV8Itg4J1oc5J8QZzo/PEBhqrH+OIVkVRmxGttUOQ8L7QVOCWPCNBSObV4=
Authentication-Results: oracle.com; dkim=none (message not signed)
 header.d=none;oracle.com; dmarc=none action=none header.from=nxp.com;
Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14)
 by DB6PR0402MB2775.eurprd04.prod.outlook.com (2603:10a6:4:99::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Tue, 28 Apr
 2020 07:42:33 +0000
Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com
 ([fe80::d17b:d767:19c3:b871]) by DB6PR0402MB2760.eurprd04.prod.outlook.com
 ([fe80::d17b:d767:19c3:b871%6]) with mapi id 15.20.2937.023; Tue, 28 Apr 2020
 07:42:33 +0000
From: peng.fan@nxp.com
To: konrad.wilk@oracle.com, boris.ostrovsky@oracle.com, jgross@suse.com,
 sstabellini@kernel.org
Subject: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
Date: Tue, 28 Apr 2020 15:33:45 +0800
Message-Id: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
X-Mailer: git-send-email 2.7.4
Content-Type: text/plain
X-ClientProxiedBy: SG2PR0601CA0010.apcprd06.prod.outlook.com (2603:1096:3::20)
 To DB6PR0402MB2760.eurprd04.prod.outlook.com
 (2603:10a6:4:a1::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost.localdomain (119.31.174.66) by
 SG2PR0601CA0010.apcprd06.prod.outlook.com (2603:1096:3::20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id
 15.20.2937.13 via Frontend Transport; Tue, 28 Apr 2020 07:42:30 +0000
X-Mailer: git-send-email 2.7.4
X-Originating-IP: [119.31.174.66]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 88a53fa9-b69f-49ae-8dbf-08d7eb47b69b
X-MS-TrafficTypeDiagnostic: DB6PR0402MB2775:|DB6PR0402MB2775:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <DB6PR0402MB27757FDEE7409ECED1B91F8188AC0@DB6PR0402MB2775.eurprd04.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:2803;
X-Forefront-PRVS: 0387D64A71
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(4636009)(346002)(366004)(396003)(39860400002)(136003)(376002)(186003)(26005)(5660300002)(69590400007)(86362001)(478600001)(66946007)(6512007)(66476007)(66556008)(956004)(9686003)(45080400002)(6506007)(6666004)(36756003)(2616005)(4326008)(8936002)(8676002)(52116002)(16526019)(2906002)(81156014)(6486002)(316002);
 DIR:OUT; SFP:1101; 
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: VKLdp/orntAdGjO+9DyQ4iWLhiOQ6BgNDkN1hq0yxTdn7Qnp+7uxxsKph9uTzfaBd7DhDH2G28HIPcbi/kk+r0R+Ns54lJbHPaz3rBRfhIDg/aXvMwzWcoU/YCRsS9JJ4BVifM/FPfFajNKlHcKVlo+fmXuvLiAP5cibm70lFz0TQIt210nVAbdTOEYwPvQoWIuI13njpa+EQ119648x8k+ZCoaFjo8UQ0uDeYlDeb3sH8ZJMuVqy2Lj61E7v1QtYA9wF0mcMsOwl/qoj20WdZ0QpaOA0kSMFQx2lrww1F6lIV9DDcAGTPKkJWHtTb+BDM3hmPXN3dtGxOCmq4YnENpX6dR+9t36ZyXr670vIQFQkASFzwGEhWf92kbEZqEXR4AE0nUM3TdoSaK9gvamJFYmGkDxj/kbicEmQwvIDDr7WzZOgpit7KruZ3VbCE0zxCB/NmhDyCcZcsYJMMqeQYdZooUOmFcABAHQ2bnRUeWP21YGxZ6Sti+V9Hoxc9cG
X-MS-Exchange-AntiSpam-MessageData: Zk7f7i+o2viB7Jgl5mrSR1/CCHr1NRenCZXGkkc/I+9xeNir+x4bIyepOt+yyoBzeLU4aXh0vNk+quNbMS/Ia8ojfThG/bghsfrsNVBgC+/RrqxZaC2/nSbu4Ut72DIAhgFN+3bbta4YlnHkg2W+qTk2BaVm771muo/SDeTw8YVkV3cxyQ28p6+d8D3lkXfSYDeGi7JYIIWbSxJg4lCZm7+JRabwjUEpFAv9NdqmSnuIJEz8b2X/kdurSUGSn4+hVhuzTLisSJYbfSbBmz2rK7gHbLjZxECqI5Xjv8AC3iasGI+RVF8FBp6Ca3ee+CsagUFdL8McUvHdMoORbYWMcN32yiBUDGAXY7lVLe2Ia6tGyMKRQShoKfiLnEPwZsBdRziqtiSP60N78vj12q81hAuN2OtN/eV6WTkzcm6GweOhENmyQ9dv30LQCVOzr6HTfYRJoyRcy0q/tTdNMdGn1upXdtgHiP3v0ohyjwcPkDtGqUWm2huXcgjO7bCaJ9/V1kkNDSzfEOCuIts643/JeA6GM86lGVRYjGP7Awn7pcHmXOGgk0htVDBlZyvdX7NfVYOcD0AU55ER7U2ALt0br1SoRxasbEjom/NUPU3PICzdFomFXM9jWeK9pivCLhW6BvQ7fUTEKKU7q5HTU5avpdaOn1nxM0l6Felzo8Yrv+GkIGiRw6lKS5rga6FaSdJ2FYloKDNClLDgwO+jy4IoiHaXl1zojySo9Om5PLllJCz0sbOLB2cCL1obBJwcciVPL6z0nF7uzchcL4Ym9wIpd9q0Chn8bz74XlrGZXOgGFI=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 88a53fa9-b69f-49ae-8dbf-08d7eb47b69b
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2020 07:42:33.7546 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gpAo6zFgx2yanelGIdZXEjn9aRuVxqn9rP/bKhZp507od0M+GKbRuN5wF0Oov1eF4dgWG1zimXqHquqgOPdhmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2775
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, iommu@lists.linux-foundation.org,
 Peng Fan <peng.fan@nxp.com>, linux-kernel@vger.kernel.org, linux-imx@nxp.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Peng Fan <peng.fan@nxp.com>

When booting xen on i.MX8QM, met:
"
[    3.602128] Unable to handle kernel paging request at virtual address 0000000000272d40
[    3.610804] Mem abort info:
[    3.613905]   ESR = 0x96000004
[    3.617332]   EC = 0x25: DABT (current EL), IL = 32 bits
[    3.623211]   SET = 0, FnV = 0
[    3.626628]   EA = 0, S1PTW = 0
[    3.630128] Data abort info:
[    3.633362]   ISV = 0, ISS = 0x00000004
[    3.637630]   CM = 0, WnR = 0
[    3.640955] [0000000000272d40] user address but active_mm is swapper
[    3.647983] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[    3.654137] Modules linked in:
[    3.677285] Hardware name: Freescale i.MX8QM MEK (DT)
[    3.677302] Workqueue: events deferred_probe_work_func
[    3.684253] imx6q-pcie 5f000000.pcie: PCI host bridge to bus 0000:00
[    3.688297] pstate: 60000005 (nZCv daif -PAN -UAO)
[    3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0
[    3.693993] pci_bus 0000:00: root bus resource [bus 00-ff]
[    3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0
"

In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask) or
range_straddles_page_boundary(phys, size) are true, it will
create contiguous region. So when free, we need to free contiguous
region use upper check condition.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/xen/swiotlb-xen.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index b6d27762c6f8..ab96e468584f 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
 	/* Convert the size to actually allocated. */
 	size = 1UL << (order + XEN_PAGE_SHIFT);
 
-	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
-		     range_straddles_page_boundary(phys, size)) &&
+	if (((dev_addr + size - 1 > dma_mask) ||
+	    range_straddles_page_boundary(phys, size)) &&
 	    TestClearPageXenRemapped(virt_to_page(vaddr)))
 		xen_destroy_contiguous_region(phys, order);
 
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 07:59:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 07:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTL9G-00084a-Nb; Tue, 28 Apr 2020 07:59:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTL9F-00084T-R7
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 07:59:21 +0000
X-Inumbo-ID: 2a752f5e-8926-11ea-983b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2a752f5e-8926-11ea-983b-12813bfff9fa;
 Tue, 28 Apr 2020 07:59:20 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CA857ABCF;
 Tue, 28 Apr 2020 07:59:18 +0000 (UTC)
Subject: Ping: [PATCH v3 0/5] (remaining) XSA-292 follow-up
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <3ce4ab2c-8cb6-1482-6ce9-3d5b019e10c1@suse.com>
Message-ID: <b3cb2f58-0e7d-e6c6-80d3-04590bf8bd21@suse.com>
Date: Tue, 28 Apr 2020 09:59:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3ce4ab2c-8cb6-1482-6ce9-3d5b019e10c1@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Andrew,

On 25.09.2019 17:19, Jan Beulich wrote:
> 1: x86: suppress XPTI-related TLB flushes when possible
> 2: x86/mm: honor opt_pcid also for 32-bit PV domains

I realize these two weren't entirely uncontroversial. May I
please ask that you get back to them, more than half a year
after their posting? For patch 1 I don't think I got
anything back yet on v2 / v3. For patch 2 see
https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg01721.html

> 3: x86/HVM: move NOFLUSH handling out of hvm_set_cr3()

See
https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg01689.html
https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg01737.html

> 4: x86/HVM: refuse CR3 loads with reserved (upper) bits set
> 5: x86/HVM: cosmetics to hvm_set_cr3()

These two have your ack, but depend on at least patch 3 afaict.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 08:02:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 08:02:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTLCM-00010s-Gd; Tue, 28 Apr 2020 08:02:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=vdy4=6M=bombadil.srs.infradead.org=batv+04e88780fe354b781c6f+6092+infradead.org+hch@srs-us1.protection.inumbo.net>)
 id 1jTLCK-00010l-6Z
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 08:02:32 +0000
X-Inumbo-ID: 91d4795c-8926-11ea-b07b-bc764e2007e4
Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 91d4795c-8926-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 08:02:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version
 :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
 Content-Transfer-Encoding:Content-ID:Content-Description;
 bh=0Gc8wiZaH5vxzoL7Y4RD61mnokWImM3/OUm105M5x4Q=; b=AkRzSgUBS3spTGGb1FU2ZdnFp4
 7BKimlNU77GlBbuUM/8B5MPQQ/E6pQxNnqbGv+7iaZdB1yzXSBR4E6U5GIwvyG6VLpIOzmZt8b+Af
 FhXp4/msJvZ5wc9Q/RiSGYZjj5WugzIgMCgyvRtTHLiMoRI/isejvWR1rP9hHQqpa9qWD+mUpziT9
 uaVqa13Hhc/t59XAU11bOMVnUb4ynS0/3sHmfE672BTSnYmRzfdf+63SFCOFf2DKOM2/lg8NAzimF
 fD0PTuRTAIjTIr+c2X26hXxC4p/Xa5P+lwbVfvO9LSTlCL0fe8zEy86Odd6yWyhlALdnxCk28aydq
 KqW8hdGw==;
Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red
 Hat Linux)) id 1jTLBy-0000XO-Ed; Tue, 28 Apr 2020 08:02:10 +0000
Date: Tue, 28 Apr 2020 01:02:10 -0700
From: Christoph Hellwig <hch@infradead.org>
To: peng.fan@nxp.com
Subject: Re: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
Message-ID: <20200428080210.GA25643@infradead.org>
References: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by
 bombadil.infradead.org. See http://www.infradead.org/rpr.html
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: jgross@suse.com, sstabellini@kernel.org, konrad.wilk@oracle.com,
 linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
 linux-imx@nxp.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 28, 2020 at 03:33:45PM +0800, peng.fan@nxp.com wrote:
> 
> In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask) or
> range_straddles_page_boundary(phys, size) are true, it will
> create contiguous region. So when free, we need to free contiguous
> region use upper check condition.
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
>  drivers/xen/swiotlb-xen.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index b6d27762c6f8..ab96e468584f 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
>  	/* Convert the size to actually allocated. */
>  	size = 1UL << (order + XEN_PAGE_SHIFT);
>  
> -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> -		     range_straddles_page_boundary(phys, size)) &&
> +	if (((dev_addr + size - 1 > dma_mask) ||
> +	    range_straddles_page_boundary(phys, size)) &&
>  	    TestClearPageXenRemapped(virt_to_page(vaddr)))

No need for the inner braces.

But more importantly please factor our a helper that can be used by
alloc and free to make sure that they always stay in sync.  Something
like:

static inline bool xen_swiotlb_need_contiguous_region(struct device *dev,
		phys_addr_t phys, size_t size)
{
	
	return xen_phys_to_bus(phys) + size - 1 > dev->coherent_dma_mask ||
		range_straddles_page_boundary(phys, size))
}



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 08:09:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 08:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTLIo-0001F5-7a; Tue, 28 Apr 2020 08:09:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=DYx7=6M=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTLIm-0001F0-4A
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 08:09:12 +0000
X-Inumbo-ID: 8a78174e-8927-11ea-983b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8a78174e-8927-11ea-983b-12813bfff9fa;
 Tue, 28 Apr 2020 08:09:11 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4E629AC4A;
 Tue, 28 Apr 2020 08:09:09 +0000 (UTC)
Subject: Re: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
To: peng.fan@nxp.com, konrad.wilk@oracle.com, boris.ostrovsky@oracle.com,
 sstabellini@kernel.org
References: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <1c01e97a-adcd-a703-55b5-8975b4ce4d2c@suse.com>
Date: Tue, 28 Apr 2020 10:09:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, iommu@lists.linux-foundation.org,
 linux-kernel@vger.kernel.org, linux-imx@nxp.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.20 09:33, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> When booting xen on i.MX8QM, met:
> "
> [    3.602128] Unable to handle kernel paging request at virtual address 0000000000272d40
> [    3.610804] Mem abort info:
> [    3.613905]   ESR = 0x96000004
> [    3.617332]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    3.623211]   SET = 0, FnV = 0
> [    3.626628]   EA = 0, S1PTW = 0
> [    3.630128] Data abort info:
> [    3.633362]   ISV = 0, ISS = 0x00000004
> [    3.637630]   CM = 0, WnR = 0
> [    3.640955] [0000000000272d40] user address but active_mm is swapper
> [    3.647983] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [    3.654137] Modules linked in:
> [    3.677285] Hardware name: Freescale i.MX8QM MEK (DT)
> [    3.677302] Workqueue: events deferred_probe_work_func
> [    3.684253] imx6q-pcie 5f000000.pcie: PCI host bridge to bus 0000:00
> [    3.688297] pstate: 60000005 (nZCv daif -PAN -UAO)
> [    3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0
> [    3.693993] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0
> "
> 
> In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask) or
> range_straddles_page_boundary(phys, size) are true, it will
> create contiguous region. So when free, we need to free contiguous
> region use upper check condition.

No, this will break PV guests on x86.

I think there is something wrong with your setup in combination with
the ARM xen_create_contiguous_region() implementation.

Stefano?


Juergen

> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
>   drivers/xen/swiotlb-xen.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index b6d27762c6f8..ab96e468584f 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
>   	/* Convert the size to actually allocated. */
>   	size = 1UL << (order + XEN_PAGE_SHIFT);
>   
> -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> -		     range_straddles_page_boundary(phys, size)) &&
> +	if (((dev_addr + size - 1 > dma_mask) ||
> +	    range_straddles_page_boundary(phys, size)) &&
>   	    TestClearPageXenRemapped(virt_to_page(vaddr)))
>   		xen_destroy_contiguous_region(phys, order);
>   
> 



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 08:10:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 08:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTLJe-0001i1-Iy; Tue, 28 Apr 2020 08:10:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTLJe-0001dv-1D
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 08:10:06 +0000
X-Inumbo-ID: aac78ade-8927-11ea-b07b-bc764e2007e4
Received: from mail-wm1-x32b.google.com (unknown [2a00:1450:4864:20::32b])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id aac78ade-8927-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 08:10:05 +0000 (UTC)
Received: by mail-wm1-x32b.google.com with SMTP id 188so1663849wmc.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 01:10:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=tqa9n9EoSDAPwWeVvhR+Uj2qxGKno9fvpdj73k0ySF0=;
 b=gYDoaOI16qKm0ihSWCygBBdWCDnhE++szBYSLccatExDMbjbQ+PXEHfibgnsbzjFCb
 inUlb2LhfwjDteWTkbizCmhwEyo0A3czN2uPx0BjLsHLY5684Lz4ALiyPiVofW7yiMz6
 L3uBJkZnS3/O5gngb/WkEp3XYAET1+dSevY9G2Ozd7QdcD62nk4HCMiGRYYdv1Q7OlTA
 SwZ3LVlGvgUBXIktcyICxsN8tphHOac9MKQvpBsPgh34a59oVCU3fnH0CAJaAyIR/S7T
 0jA3CYcxKdl2SbMeBeZ2mzuaE4BRpEfnWZJpLWwKTom67tpY0GkFucaRewvCU6W66Hjs
 3hYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=tqa9n9EoSDAPwWeVvhR+Uj2qxGKno9fvpdj73k0ySF0=;
 b=f4fd3xtNwRJ0GYD3Bu11E0eCWY69S/nSfyW5r4Li4zcp93Qeo58Zj585GXUST/ddm+
 7uuWyxbmpuIPc73u333DjlFcz1S9s67LJofunMvyWyW/4erQQdwVEZVVdm7anBSiPAWi
 ZKCVI0bJGL4JUmNHQRZDIuJFiaSMRpUdRcU1ddRnLDdy7x8w8t0yRvojzMZtt9Se4A75
 a9M+BBnWPdpy8BMZlvFn/0tBrzSKcgqTBywRnY0dSdPbM1kTFIkXfqXaZsdtcjjPLjYo
 c4aZFjFHrHD5K1X6zOfOtVH58SkLMmvtTGS44GupOWugah/kHDEWR5Ejb8DCH+CWnrSI
 MVrw==
X-Gm-Message-State: AGi0PuZ6feTjM9E5z6Rco+cthePpTMvWEMR1soKJqFvdzoA/rtxosBeI
 hOUbjOMYeVjabDOh171INWM=
X-Google-Smtp-Source: APiQypI7ne91jSGdPfgFLjPDbWwiOo2xKnOh99cblKMQobaj588UxOZv1r75AYV27BnAwN7EilS/wg==
X-Received: by 2002:a05:600c:1008:: with SMTP id
 c8mr3067783wmc.14.1588061404689; 
 Tue, 28 Apr 2020 01:10:04 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id h13sm23315817wrs.22.2020.04.28.01.10.03
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 01:10:04 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Grzegorz Uriasz'" <gorbak25@gmail.com>,
	<qemu-devel@nongnu.org>
References: <20200428062847.7764-1-gorbak25@gmail.com>
 <20200428062847.7764-2-gorbak25@gmail.com>
In-Reply-To: <20200428062847.7764-2-gorbak25@gmail.com>
Subject: RE: [PATCH 1/2] Fix undefined behaviour
Date: Tue, 28 Apr 2020 09:10:02 +0100
Message-ID: <000001d61d34$6c0218f0$44064ad0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJZJJhe4DhOB0QFT+Ee5i7aNCDcTgF4qWDWp3xZsEA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: artur@puzio.waw.pl, 'Stefano Stabellini' <sstabellini@kernel.org>,
 jakub@bartmin.ski, marmarek@invisiblethingslab.com,
 'Anthony Perard' <anthony.perard@citrix.com>, j.nowak26@student.uw.edu.pl,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Grzegorz Uriasz <gorbak25@gmail.com>
> Sent: 28 April 2020 07:29
> To: qemu-devel@nongnu.org
> Cc: Grzegorz Uriasz <gorbak25@gmail.com>; marmarek@invisiblethingslab.com; artur@puzio.waw.pl;
> jakub@bartmin.ski; j.nowak26@student.uw.edu.pl; Stefano Stabellini <sstabellini@kernel.org>; Anthony
> Perard <anthony.perard@citrix.com>; Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Subject: [PATCH 1/2] Fix undefined behaviour
> 
> Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>

I think we need more of a commit comment for both this and patch #2 to explain why you are making the changes.

  Paul 



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 08:22:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 08:22:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTLVC-00031U-Q6; Tue, 28 Apr 2020 08:22:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=CDey=6M=nxp.com=peng.fan@srs-us1.protection.inumbo.net>)
 id 1jTLVB-00031P-Ke
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 08:22:01 +0000
X-Inumbo-ID: 545344ca-8929-11ea-983f-12813bfff9fa
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown
 [40.107.8.77]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 545344ca-8929-11ea-983f-12813bfff9fa;
 Tue, 28 Apr 2020 08:21:59 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=U5H2aIphdnPovewkY4VGFM4sEWxGucBW08FKFscQtKPSo9JzDk83sn//dkPshb8CeHlyiwcMQWK7JlKSFG8m2gPT15fGczgFqHJKnXQrMydMTfwCmRYvE137VjCp9vzSaG2zx5y8ROWCU3wSIH1xlLCVaF0VBnL7BiN5RDU9ejiwwEeN+Gc3aILVhr8ppOqlcwkmHNVLLmK/JGSfrcxWp6h9LwDgo0Ht9va0l5JwI0gXyaZ9KDHx5Jahb3+MQeUBhIh0Y01LTKxDCpODY+lGL+j+7CJEGMmxR9Wk9WL3riy6Yjnv5sECpgr4RStHdaR6wdX09SuXbQQxs/zapVBk9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wQixSruRATExyVZtZCrE5ENirdmhwGn1bocmC67jGto=;
 b=JWTlSPsac0kD2VNKVZCJuqVb8yJeVNJrGdMB2QQkeBHzICO4rhsDXXCdamZegwYAI9PymtAvRHupoCXQhG6AHjN3Z8XTFy9CImnCWTy/LFi2Pxd9YjIvjXSO8nPTTEu55yqOIGxyMDgvJqWrojnQiWbW4ewiA0VydSyIn+bF+pqEp50DhmzcrWAaaUWZZf21X/VHRdWzr1FE+dzvIkINks9JygKiWZ3zX56b3O9II45qjrnu9loXz4TJWEJ6SdF2q9+/12dL1DK8pH0YmLE9fRZmviR2iW89hEaLPTm4QQAiK5fkYM+vJ1dRMdB9j/kA/PiGVpFoJz2JymrHkGjn0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass
 header.d=nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wQixSruRATExyVZtZCrE5ENirdmhwGn1bocmC67jGto=;
 b=ndxswZISDVn8wI6Z0pa9Aw8u9R77/2lMLv4rcsuApcCCn+mP/W1rpAYxiMQzTd4tb8hOffvPNImYOHoGljIltHbV0B3IDSfINwfj24ABLEO5cSQ8yRPKvcYEYef4Cj8ab5WxMjTdLR3Fv1cNwzn0z0+kwjGYGGkptDJ05hULEhA=
Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14)
 by DB6PR0402MB2711.eurprd04.prod.outlook.com (2603:10a6:4:96::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Tue, 28 Apr
 2020 08:21:57 +0000
Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com
 ([fe80::d17b:d767:19c3:b871]) by DB6PR0402MB2760.eurprd04.prod.outlook.com
 ([fe80::d17b:d767:19c3:b871%6]) with mapi id 15.20.2937.023; Tue, 28 Apr 2020
 08:21:57 +0000
From: Peng Fan <peng.fan@nxp.com>
To: Christoph Hellwig <hch@infradead.org>
Subject: RE: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
Thread-Topic: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
Thread-Index: AQHWHTCUGLGxU19LnkuMxSfwKxPy/aiOLEEAgAAFDsA=
Date: Tue, 28 Apr 2020 08:21:57 +0000
Message-ID: <DB6PR0402MB2760981C819B03D6B5647E9288AC0@DB6PR0402MB2760.eurprd04.prod.outlook.com>
References: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
 <20200428080210.GA25643@infradead.org>
In-Reply-To: <20200428080210.GA25643@infradead.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: infradead.org; dkim=none (message not signed)
 header.d=none;infradead.org; dmarc=none action=none header.from=nxp.com;
x-originating-ip: [119.31.174.71]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 3a00cf67-1e01-4158-e862-08d7eb4d37b0
x-ms-traffictypediagnostic: DB6PR0402MB2711:|DB6PR0402MB2711:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB6PR0402MB2711A6F924BF5D255E08D54E88AC0@DB6PR0402MB2711.eurprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0387D64A71
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(4636009)(396003)(366004)(39860400002)(376002)(346002)(136003)(66946007)(8936002)(66476007)(9686003)(2906002)(52536014)(6506007)(5660300002)(44832011)(186003)(6916009)(54906003)(478600001)(4326008)(76116006)(66446008)(26005)(86362001)(316002)(8676002)(7696005)(55016002)(33656002)(81156014)(64756008)(66556008)(71200400001);
 DIR:OUT; SFP:1101; 
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VM71IWGXE3SwEEh2mDk7gfmURNYDtfOPiQj91KRW0oVO6zySpVZux+pfJsu72Otvr8aotNQYOSehTedrTwzWpe1QoVKsPaxrBS2uJCZRz+k/Ti/FWihC/qhket7/H2A/dMro2leaDWFfiTkyQi86o/3oB3pmCKu8vNgH/IYlbKxN5gpPbHfNmRG5e34YbWRwnWCQFF/QcH8gLKhrPS6VGCYrDwwfUV6BZu/bIJcY2Pb72ldDOY8LcrTM99B4lsLlp8UPK8/bf+pkYiLHmF45rW2YfNHxWUqCKg9Z+OL16I2/K4FhUxIHpylsugUhfh61KPY+KQTkEgSTJT1J08RkMx+hP/LjJtCqlZyFZf56x9eqls093YNM/AgCmP6VCKc6n1+aTJh46jQr/BGhjwKwxV7IJgNfC1PJp/4UYYs+6OGpDK6ZaFoIWdIAP65LFy7t
x-ms-exchange-antispam-messagedata: bYjanyY2rDDlFDlA3j/qvRVrfl4J6802rWDkQ9uV/kKT/zwxdiUtD/47rXKxWNUTmHQrbuCQhq603T2gXVvQzykLu5y60RQ84yZVpOhSallw4eSExSHMZW1XHVbKtLKBEGbUplGBinzav8gLdlwMow8DalH0SJSmqGT+hmj6+dxJYjlL6SgJw8idJG6sPgM8aPuISLKzvThngtJ+Ix26DQ+t+oulWLL/O30DXZY0RSJCrcszh0DLLstawAbkKGBmZJGGj0XvWYkvSFErdSRfWCgJoGtYgkQ2ImGT1Zk5Yx5p+X/Yd2hnQBmbzXep/NIZjqROsLkCe0s4bee8YNggotbfKcsADeoqKqVzlHEHLXMDmAsSELO6OPaH3uCBOcauDGY5IeB/WZU1ubK5Kq4t0+zvyon1lchAHXFvCVPzPP4gjiamBr1uESYi6lJkz71GRGcO2JBreWTWSncwQGIjknVd4HZ8erlKsX/2Io3P2onci7MRpfzoKuVnVCcJSxq+JbnYBJ9E18xw7Mgzz7uOzMrSjYRAaeMl2ZVpUldJ8oKZMu579Zc07Y324gB8bQTIiS9d+ujTCk5NERg3LCppFoI1OaGoBtki8rXtaMIee1wxWTyyZdOcxIkiyp2JboSHiXuQjFXvXhuX8HNmrU9t+cUyw3aU5ehSpRgU0L1Sndha+0H2Qi47DL4G0ervA6cbC6XJRXD7pFDELqg5c9mniNSTdI67onWQMZY/kLSXLSl+P2vUl0yJ0EC42zh4CNCOb+ZpDSnvluQJs7/EcVfk+Hj4DbniN1Y1WRVocXKAIZU=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a00cf67-1e01-4158-e862-08d7eb4d37b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 08:21:57.4904 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XDN9/R5qN4ueHEAz+1Qrdqcr+lModtbpD/a/8lw00gnsSqQ6YQ5/jqmVdggcWCIfKhL7RQmhdDqD99sRV+flRQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2711
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "jgross@suse.com" <jgross@suse.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
 dl-linux-imx <linux-imx@nxp.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> Subject: Re: [PATCH] xen/swiotlb: correct the check for
> xen_destroy_contiguous_region
>=20
> On Tue, Apr 28, 2020 at 03:33:45PM +0800, peng.fan@nxp.com wrote:
> >
> > In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <=3D dma_mask)
> > or range_straddles_page_boundary(phys, size) are true, it will create
> > contiguous region. So when free, we need to free contiguous region use
> > upper check condition.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> >  drivers/xen/swiotlb-xen.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index b6d27762c6f8..ab96e468584f 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev,
> size_t size, void *vaddr,
> >  	/* Convert the size to actually allocated. */
> >  	size =3D 1UL << (order + XEN_PAGE_SHIFT);
> >
> > -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> > -		     range_straddles_page_boundary(phys, size)) &&
> > +	if (((dev_addr + size - 1 > dma_mask) ||
> > +	    range_straddles_page_boundary(phys, size)) &&
> >  	    TestClearPageXenRemapped(virt_to_page(vaddr)))
>=20
> No need for the inner braces.
>=20
> But more importantly please factor our a helper that can be used by alloc=
 and
> free to make sure that they always stay in sync.  Something

Thanks for reviewing. I'll take your suggestion in v2. Before that,
I would wait to see if there are more comments in this patch,
because there are several history commits touching this place.

Thanks,
Peng.

> like:
>=20
> static inline bool xen_swiotlb_need_contiguous_region(struct device *dev,
> 		phys_addr_t phys, size_t size)
> {
>=20
> 	return xen_phys_to_bus(phys) + size - 1 > dev->coherent_dma_mask ||
> 		range_straddles_page_boundary(phys, size)) }



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 08:24:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 08:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTLXi-0003A8-Br; Tue, 28 Apr 2020 08:24:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=lSul=6M=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jTLXg-0003A3-I1
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 08:24:36 +0000
X-Inumbo-ID: b14a0a6a-8929-11ea-ae69-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b14a0a6a-8929-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 08:24:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588062275;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=M/bJKdnKVYMF+ypyvWnnUGP820YYdLpMtI1STxc6/no=;
 b=WdBjpSShDVeQcMJ3eUn98qSnFFG1wWXCXO41gSotzVTvWMylSNizxZvZ
 PozuVXLtfLcnSjF/Zc5DonHsD0Ko2Dx6HgKNmAuQv5wbJadaSrxiSCtj9
 4A+Rr81ZEM/Xbkx6pjH4Pu25u36DG/ng/UwZGTGyndkruyiurmKvYDMWo Q=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: yGgEGI5YSWmVwi5KodKROZDHhuw3qA4DxVdRilOziMe2IJnDel3Ds8Dl7zj3ibpYmq6CvYwVXN
 z6vZsx2aRFWt6Y/Rm3QAhA312eFNDufYI1MOMgw//z8jqG04AWl4Qa75M6d4zeVLMXYGkpAFOB
 Cb/pm9itu8rGRgb1ZDb4k7AGK2nXIa6670BrMD9QvW/ZMpb0vcjg3pcvP/zTU28hAiij+O/cPX
 QajZXfnBGqHBd60+r7ydHIMg7f+qo0LvQEflodm7DQO0UEuPP8elKG2P4py352K8yre0QfP1Un
 MhQ=
X-SBRS: 2.7
X-MesageID: 16668029
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,327,1583211600"; d="scan'208";a="16668029"
From: George Dunlap <George.Dunlap@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
Thread-Topic: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
Thread-Index: AQHWCQXiBGUb+wr760WOfoEenUG4zahnVWoAgAALjICAAAX/gIAAAzMAgASARQCAITZdgIAADK2AgAD5+wCAABHcgA==
Date: Tue, 28 Apr 2020 08:24:31 +0000
Message-ID: <064958B4-1FCC-4300-A98A-7A1D608376F8@citrix.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
 <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
 <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
 <fb0e92cc-102f-7f87-1ad6-f3ccce1eee60@suse.com>
In-Reply-To: <fb0e92cc-102f-7f87-1ad6-f3ccce1eee60@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <CB215CE703199D48A6D0C54C19446017@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew
 Cooper <Andrew.Cooper3@citrix.com>, Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDI4LCAyMDIwLCBhdCA4OjIwIEFNLCBKYW4gQmV1bGljaCA8amJldWxpY2hA
c3VzZS5jb20+IHdyb3RlOg0KPiANCj4gT24gMjcuMDQuMjAyMCAxODoyNSwgR2VvcmdlIER1bmxh
cCB3cm90ZToNCj4+IElmIEphbiBpcyBPSyB3aXRoIGl0IHNpbXBseSBiZWluZyBvdXRzaWRlIENP
TkZJR19FWFBFUlQsIHRoZW4gZ3JlYXQuICBCdXQgaWYgaGUgaW5zaXN0cyBvbiBzb21lIGtpbmQg
b2YgdGVzdGluZyBmb3IgaXQgdG8gYmUgb3V0c2lkZSBvZiBDT05GSUdfRVhQRVJULCB0aGVuIGFn
YWluLCB0aGUgcGVvcGxlIHdobyB3YW50IGl0IHRvIGJlIHNlY3VyaXR5IHN1cHBvcnRlZCBzaG91
bGQgYmUgdGhlIG9uZXMgd2hvIGRvIHRoZSB3b3JrIHRvIG1ha2UgaXQgaGFwcGVuLg0KPiANCj4g
SSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgcGFydCwgSSdtIGFmcmFpZDogV2l0aG91dCBhIGNvbmZp
ZyBvcHRpb24sDQo+IHRoZSBjb2RlIGlzIGdvaW5nIHRvIGJlIHNlY3VyaXR5IHN1cHBvcnRlZCBh
cyBsb25nIGFzIGl0IGRvZXNuJ3QNCj4gZ2V0IG1hcmtlZCBvdGhlcndpc2UgKGV4cGVyaW1lbnRh
bCBvciB3aGF0IG5vdCkuIFdpdGggYW4gb3B0aW9uDQo+IGRlcGVuZGluZyBvbiBFWFBFUlQsIHdo
YXQgd291bGQgYmVjb21lIHNlY3VyaXR5IHVuc3VwcG9ydGVkIGlzIHRoZQ0KPiBub24tZGVmYXVs
dCAoaS5lLiBkaXNhYmxlZCkgc2V0dGluZy4gVGhlcmUncyBub3QgYSB3aG9sZSBsb3QgdG8NCj4g
dGVzdCB0aGVyZSwgaXQncyBtZXJlbHkgYSBmb3JtYWwgY29uc2VxdWVuY2Ugb2Ygb3VyIGdlbmVy
YWwgcnVsZXMuDQo+IChPZiBjb3Vyc2UsIG92ZXIgdGltZSBkZXBlbmRlbmNpZXMgb2Ygb3RoZXIg
Y29kZSBtYXkgZGV2ZWxvcCBvbg0KPiB0aGUgaW5mb3JtYXRpb24gYmVpbmcgYXZhaWxhYmxlIGUu
Zy4gdG8gRG9tMCB1c2VybGFuZC4gSnVzdCBsaWtlDQo+IHRoZXJlJ3MgTGludXggdXNlcmxhbmQg
Y29kZSBhc3N1bWluZyB0aGUga2VybmVsIGNvbmZpZyBpcw0KPiBhdmFpbGFibGUgaW4gY2VydGFp
biB3YXlzIFtJIGRvbid0IG5lY2Vzc2FyaWx5IG1lYW4gdGhlIGVxdWl2YWxlbnQNCj4gb2YgaHlw
ZnMgaGVyZV0sIHRvIHRoZW4gdXNlIGl0IGluIHdoYXQgSSdkIGNhbGwgYWJ1c2l2ZSB3YXlzIGlu
IGF0DQo+IGxlYXN0IHNvbWUgY2FzZXMuKQ0KDQpIZXJl4oCZcyBhbiBhcmd1bWVudCB5b3UgbWln
aHQgbWFrZToNCg0K4oCcQXMgYSBtZW1iZXIgb2YgdGhlIHNlY3VyaXR5IHRlYW0sIEkgZG9u4oCZ
dCB3YW50IHRvIGJlIG9uIHRoZSBob29rIGZvciBpc3N1aW5nIFhTQXMgZm9yIGNvZGUgd2hpY2gg
aXNu4oCZdCBhdCBsZWFzdCBzbW9rZS10ZXN0ZWQuICBUaGVyZWZvcmUsIEkgb3Bwb3NlIGFueSBw
YXRjaCBhZGRpbmcgQ09ORklHX0hZUEZTIG91dHNpZGUgb2YgQ09ORklHX0VYUEVSVCwgKnVubGVz
cyogdGhlcmUgaXMgYSBjb25jcmV0ZSBwbGFuIGZvciBnZXR0aW5nIHJlZ3VsYXIgdGVzdGluZyBm
b3IgQ09ORklHX0hZUEZTPW4u4oCdDQoNCknigJltIG5vdCBzYXlpbmcgdGhhdOKAmXMgYW4gYXJn
dW1lbnQgeW91ICpzaG91bGQqIG1ha2UuICBCdXQgcGVyc29uYWxseSBJIGRvbuKAmXQgaGF2ZSBh
IHN0cm9uZyBhcmd1bWVudCBhZ2FpbnN0IHN1Y2ggYW4gYXJndW1lbnQuIFNvLCBpdCBzZWVtcyB0
byBtZSwgaWYgeW91IGRpZCBtYWtlIGl0LCB5b3UgaGF2ZSBhIHJlYXNvbmFibGUgY2hhbmNlIG9m
IGNhcnJ5aW5nIHlvdXIgcG9pbnQuDQoNCk5vdyBjb25zaWRlciB0aGlzIGh5cG90aGV0aWNhbCB1
bml2ZXJzZSB3aGVyZSB5b3UgbWFkZSB0aGF0IGFyZ3VtZW50IGFuZCBub2JvZHkgb3Bwb3NlZCBp
dC4gIEluIG9yZGVyIHRvIGdldCBhIHBhcnRpY3VsYXIgZmVhdHVyZSAoQ09ORklHX0hZUEZTPW4g
c2VjdXJpdHkgc3VwcG9ydGVkKSwgdGhlcmUgaXMgZXh0cmEgd29yayB0aGF0IG5lZWRzIHRvIGJl
IGRvbmUgKGdldHRpbmcgQ09ORklHX0hZUEZTPW4gdGVzdGVkIHJlZ3VsYXJseSkuICBNeSBwb2lu
dCB3YXMsIHRoZSBleHBlY3RhdGlvbiBzaG91bGQgYmUgdGhhdCB0aGUgZXh0cmEgd29yayB3aWxs
IGJlIGRvbmUgYnkgdGhlIHBlb3BsZSB3aG8gd2FudCBvciBiZW5lZml0IGZyb20gdGhlIGZlYXR1
cmU7IHRoZSBzZXJpZXMgc2hvdWxkbuKAmXQgYmUgYmxvY2tlZCB1bnRpbCBKdWVyZ2VuIGltcGxl
bWVudHMgQ09ORklHX0hZUEZTPW4gdGVzdGluZyAoc2luY2UgaGUgZG9lc27igJl0IHBlcnNvbmFs
bHkgaGF2ZSBhIHN0YWtlIGluIHRoYXQgZmVhdHVyZSkuDQoNCk5vdyBvYnZpb3VzbHksIGRvaW5n
IHdvcmsgdG8gaGVscCBzb21lb25lIGVsc2Ugb3V0IGluIHRoZSBjb21tdW5pdHkgaXMgb2YgY291
cnNlIGEgZ29vZCB0aGluZyB0byBkbzsgaXQgYnVpbGRzIGdvb2R3aWxsLCB1c2VzIG91ciBhZ2dy
ZWdhdGUgcmVzb3VyY2VzIG1vcmUgZWZmaWNpZW50bHksIGFuZCBtYWtlcyBvdXIgY29tbXVuaXR5
IG1vcmUgZW5qb3lhYmxlIHRvIHdvcmsgd2l0aC4gIEJ1dCB0aGUgZ29vZHdpbGwgcHJpbWFyaWx5
IGNvbWVzIGZyb20gdGhlIGZhY3QgdGhhdCBpdCB3YXMgZG9uZSBhcyBhIHZvbHVudGFyeSBjaG9p
Y2UsIG5vdCBhcyBhIHJlcXVpcmVtZW50Lg0KDQpKdWVyZ2VuIHdhcyBiYWxraW5nIGF0IGhhdmlu
ZyB0byBkbyB3aGF0IGhlIHNhdyBhcyBleHRyYSB3b3JrIHRvIGltcGxlbWVudCBDT05GSUdfSFlQ
RlMuICBJIHdhbnRlZCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgZXZlbiB0aG91Z2ggSSBzZWUgdmFs
dWUgaW4gaGF2aW5nIENPTkZJR19IWVBGUywgKmhlKiBkb2VzbuKAmXQgaGF2ZSB0byBkbyB0aGUg
d29yayBpZiBoZSBkb2VzbuKAmXQgd2FudCB0byAoYWx0aG91Z2ggaXQgd291bGQgY2VydGFpbmx5
IGJlIGFwcHJlY2lhdGVkIGlmIGhlIGRpZCkuICBBbmQgdGhpcyBwYXJhZ3JhcGggd2FzIGV4dGVu
ZGluZyB0aGUgc2FtZSBwcmluY2lwbGUgaW50byB0aGUgaHlwb3RoZXRpY2FsIHVuaXZlcnNlIHdo
ZXJlIHNvbWVvbmUgaW5zaXN0ZWQgdGhhdCBDT05GSUdfSFlQRlM9biBoYWQgdG8gYmUgdGVzdGVk
IGJlZm9yZSBiZWluZyBzZWN1cml0eSBzdXBwb3J0ZWQuDQoNCkhvcGUgdGhhdCBtYWtlcyBzZW5z
ZS4gOi0pDQoNCiAtR2Vvcmdl


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 08:24:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 08:24:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTLXp-0003B9-LI; Tue, 28 Apr 2020 08:24:45 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTLXo-0003B0-E0
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 08:24:44 +0000
X-Inumbo-ID: b5f9de78-8929-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b5f9de78-8929-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 08:24:43 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6948AAC2C;
 Tue, 28 Apr 2020 08:24:41 +0000 (UTC)
Subject: Re: [PATCH] x86/ioemul: Rewrite stub generation
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200427122041.7162-1-andrew.cooper3@citrix.com>
 <ca3374ed-6e00-7ab2-8255-f74c16b5ad3d@suse.com>
 <ec073c8d-61a2-79ef-1ffe-d34e26a5319d@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <76b879d9-c3b5-900d-55d9-60b48e98adfa@suse.com>
Date: Tue, 28 Apr 2020 10:24:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <ec073c8d-61a2-79ef-1ffe-d34e26a5319d@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.2020 00:20, Andrew Cooper wrote:
> On 27/04/2020 16:28, Jan Beulich wrote:
>> On 27.04.2020 14:20, Andrew Cooper wrote:
>>> The logic is completely undocumented and almost impossible to follow.  It
>>> actually uses return oriented programming.  Rewrite it to conform to more
>>> normal call mechanics, and leave a big comment explaining thing.  As well as
>>> the code being easier to follow, it will execute faster as it isn't fighting
>>> the branch predictor.
>>>
>>> Move the ioemul_handle_quirk() function pointer from traps.c to
>>> ioport_emulate.c.  There is no reason for it to be in neither of the two
>>> translation units which use it.  Alter the behaviour to return the number of
>>> bytes written into the stub.
>>>
>>> Access the addresses of the host/guest helpers with extern const char arrays.
>>> Nothing good will come of C thinking they are regular functions.
>> I agree with the C aspect, but imo the assembly routines should,
>> with the changes you make, be marked as being ordinary functions.
> 
> Despite the changes, they are still very much not ordinary functions,
> and cannot be used by C.
> 
> I have no objection to marking them as STT_FUNCTION (as this doesn't
> mean C function), but...
> 
>> A reasonable linker would then warn about the C file wanting an
>> STT_OBJECT while the assembly file provides an STT_FUNC. I'd
>> therefore prefer, along with marking the functions as such, to
>> have them also declared as functions in C.
> 
> ... there is literally nothing safe which C can do with them other than
> manipulate their address.
> 
> Writing it like this is specifically prevents something from compiling
> which will explode at runtime, is someone is naive enough to try using
> the function from C.

Besides being certain that such an attempt, if it made it into a
submitted patch in the first place, would be caught by review, I
don't see you addressing my main counter argument. Preventing a
declared function to be called can be had by other means, e.g.
__attribute__((__warning__())).

>>> @@ -19,18 +22,16 @@ static bool ioemul_handle_proliant_quirk(
>>>          0xa8, 0x80, /*    test $0x80, %al */
>>>          0x75, 0xfb, /*    jnz 1b          */
>>>          0x9d,       /*    popf            */
>>> -        0xc3,       /*    ret             */
>>>      };
>>>      uint16_t port = regs->dx;
>>>      uint8_t value = regs->al;
>>>  
>>>      if ( (opcode != 0xee) || (port != 0xcd4) || !(value & 0x80) )
>>> -        return false;
>>> +        return 0;
>>>  
>>>      memcpy(io_emul_stub, stub, sizeof(stub));
>>> -    BUILD_BUG_ON(IOEMUL_QUIRK_STUB_BYTES < sizeof(stub));
>> So you treat a build failure for a runtime crash.
> 
> I presume you mean s/treat/trade/ here, and the answer is no, not really.
> 
> There is nothing which actually forced a connection between the build
> time checks and runtime behaviour, so it was only a facade of safety,
> not real safety.

I'm not following, I'm afraid: The above together with

    BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(9, /* Default emul stub */
                                         5 + IOEMUL_QUIRK_STUB_BYTES));

(where the literal numbers live next to what they describe)
did very well provide some level of guarding.

>>  I can see the
>> advantages of the new approach, but the original got away with
>> less stub space.
> 
> Stub space doesn't matter, so long as it fits.  In particular, ...
> 
>> If our L1_CACHE_SHIFT wasn't hard coded to 7
>> just to cover some unusual CPUs, your new approach would, if I
>> got the counting and calculations right, not work (with a value
>> resulting in a 64-byte cache line size).
> 
> ... the SYSCALL stubs use 64 bytes so Xen cannot function with a shift
> less than 7.

Oh, my fault - I read the STUB_BUF_SHIFT expression as min() when
it really is max(). So yes, we can rely on there being 64 bytes.
(Everything further down therefore becomes moot afaict.)

>> Introducing a Kconfig
>> option for this should imo not come with a need to re-work the
>> logic here again. Therefore I'd like us to think about a way
>> to make the space needed not exceed 32 bytes.
> 
> And why would we ever want an option like that?  (I know how you're
> going to answer this, so I'm going to pre-emptively point out that there
> are hundreds of kilobytes of easier-to-shrink per-cpu data structures
> than this one).

Not sure what per-CPU data structures you talk about. I wasn't
thinking of space savings in particular, but rather about getting
our setting in sync with actual hardware. Its value is, afaics,
used in a far more relevant way by xmalloc() and friends.

Jan

> Honestly, this suggestion is a total waste of time and effort.  It is an
> enormous amount of complexity to micro-optimise a problem which doesn't
> exist in the first place.
> 
> The stubs are already 128 bytes per CPU and cannot be made smaller. 
> Attempting to turn this particular stub into <32 has no benefit (the
> stubs don't actually get smaller), and major costs.
> 
> ~Andrew
> 



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 08:25:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 08:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTLYy-0003KJ-1H; Tue, 28 Apr 2020 08:25:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=CDey=6M=nxp.com=peng.fan@srs-us1.protection.inumbo.net>)
 id 1jTLYx-0003KC-Dj
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 08:25:55 +0000
X-Inumbo-ID: dfb53abe-8929-11ea-983f-12813bfff9fa
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown
 [40.107.8.41]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id dfb53abe-8929-11ea-983f-12813bfff9fa;
 Tue, 28 Apr 2020 08:25:53 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=jaPwuwp+LNVMO5sbHRRKw3zb1MbyMhefKPIvpfsY81hJeyvrUJsyuYVNgES2f4tTeJr94vNzFR9oApFmMjHfxMvJvR3DFuwEhNXc2hUIbU9E7Wf8A+LZlsig11tU4A60lyZooGAYL4PajcGYy/8jXgn82D/Xt4YgUCQDGu90sdg5BJOHosyUYWW8Ta6fB35nAn099Qr4G75TgHdqKxuOSOdm8oaELB4SWQDPF21rgBxsYs8ylgj4TiaCeWPbSYPnp391lOG9Hk8+pHMbFUGQOvnWN3YhHzgqhObrDa3h1ZGV/gQNWEBE9UayT2ux1gaOJQKUtmN0ToAvOesmSJ4ozg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Dlw8bIFYxUY28tZAnQDAnDvvkdqtZ78OGLsv81bSHCc=;
 b=hznfmm4daLQax9hlivpBd2uwMCSzEqdrnWvIJtq8X7OM33i8/lBdzdGbXxorK4suAWi4XeMa+CUV4VoaMbgFqOyJ081ZHqZl7e4nSib9GV0ab9jzEEBFX3TZznn/l2kSduqqv/maxzHppnd2kwm0UMY2ljPnIjAcku6odIg62n7RxZRcDMNP/YuijgRJdJUxXaYJeor1PxqUHnFILRXiaUO1mF5sWWS18sswKpUfy9fk8SYmDqpdrKa0OG4KrLphoGh5IyY9j2QQToSPU45BMvfK3qhmyeesLqNISAGwcFSYNha+TsoJV0DLlz5ajhfvsAbkFtwYtcq9Hui4ds6MCg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass
 header.d=nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Dlw8bIFYxUY28tZAnQDAnDvvkdqtZ78OGLsv81bSHCc=;
 b=ozCRrozuW7lhxMex/g5kIxsJKEN5W9AnVlaI/l+N2UXjY2PjiLT4kmdxlvwk9LBFGQ/dXri0YKkkcBDGbkQZ5ubwBEKXmbYW16Yg1ew3igACX6uvj+dL94N2g1AzQLuqaxkwFGj8uz5g3tsp5aMB73LNNQTkmWahbsDPsGG3Vhc=
Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14)
 by DB6PR0402MB2774.eurprd04.prod.outlook.com (2603:10a6:4:96::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Tue, 28 Apr
 2020 08:25:51 +0000
Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com
 ([fe80::d17b:d767:19c3:b871]) by DB6PR0402MB2760.eurprd04.prod.outlook.com
 ([fe80::d17b:d767:19c3:b871%6]) with mapi id 15.20.2937.023; Tue, 28 Apr 2020
 08:25:51 +0000
From: Peng Fan <peng.fan@nxp.com>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>
Subject: RE: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
Thread-Topic: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
Thread-Index: AQHWHTCUGLGxU19LnkuMxSfwKxPy/aiOLjMAgAAEXoA=
Date: Tue, 28 Apr 2020 08:25:51 +0000
Message-ID: <DB6PR0402MB2760A05135338B0CBB28123488AC0@DB6PR0402MB2760.eurprd04.prod.outlook.com>
References: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
 <1c01e97a-adcd-a703-55b5-8975b4ce4d2c@suse.com>
In-Reply-To: <1c01e97a-adcd-a703-55b5-8975b4ce4d2c@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: suse.com; dkim=none (message not signed)
 header.d=none;suse.com; dmarc=none action=none header.from=nxp.com;
x-originating-ip: [119.31.174.71]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 3c952341-0a09-49f0-1c35-08d7eb4dc2fa
x-ms-traffictypediagnostic: DB6PR0402MB2774:|DB6PR0402MB2774:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB6PR0402MB2774DAE2ED2273FB88D0E18488AC0@DB6PR0402MB2774.eurprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0387D64A71
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(4636009)(39860400002)(396003)(376002)(136003)(346002)(366004)(52536014)(186003)(33656002)(81156014)(8676002)(5660300002)(44832011)(6506007)(53546011)(66556008)(64756008)(66476007)(26005)(7696005)(66446008)(76116006)(66946007)(86362001)(71200400001)(45080400002)(2906002)(316002)(4326008)(9686003)(8936002)(54906003)(478600001)(110136005)(55016002);
 DIR:OUT; SFP:1101; 
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wp5M9pRkZTNfLrbzQWLN5xAF4qPHU2zhrJC2H9zEZx6TdtZ+MqwgC/bWFSjXVv6/rC34FM4Co8KucAkwII+8CeUgRRjlgHDz9uL8ZDT4IvRT5iaGMKNa2IiOC0oxvGH6wvj0Yo9fivLxN4dRce36dnAFgPzKB77vq9hARJyWYgz5Ie+yqUbLZe09bqKLR8PjhEhYb7tbQUOwrDdC6S0RtoyGsUxgpZComiFqOVOjJ4RTkKsCy1WdJghuc4br8cGoP8IGuZDvW69kUJF3GL3FU2kcMYeLmU4uDJLU1twH1S6bBplJRxtvbHjw2DWbYNRzN93yQn9SbdsjVtaeeKsRmnIVMggmDEsZk0iAYiOfTs5ToTSTFcXkLMsHNPnY2smmd8hlAnVthUUxwsTF6f3FeCSEOAozBEXYlZ2ljSsMFQfKS7KWPybYLS1Wa/CLoUYy
x-ms-exchange-antispam-messagedata: 9DTbD4fEBCogK3eME4Bq825PLA2tr3PbNEFE5q7ldawQmCTD2tBgamLD6UdnddwH29bQN8O8/RKIxRYemi63lCC6zLoVC+Z4dZOTWF72GDzuRZ6OvnX45MnmRDx2wVmhoZvPA1WBssbA8b3WBM1r4YcrWp0Op/Aisu1zdBUOwGYmFXU1gKlxnHMVv+3/O15dVpVx5rdiYqQughkgD8QZMQIx70fyGw4nSlRC3qhDEGk9NHOYLrTXGsRfeOl52lA3268bAMSdTUQKb7qb01+IE/b/6sX8RQFkpusJdXeiNJDWE3TNpxMxa1MMhVQi/yMEmUaP2vU7uCRhKHF7eYPZ9YADWsqp+q8BkTKeuaU7JxVg3jv1h3phLuDXiEO2JuDHs9E91vp8wNge+4fWm4Lr7rkQgO6XFSSxs7n0jrapQDwWBMoEigN7nWdPn5CJ1s0WcsU4up/fYM8xBG5WFm7+ve6GyL4SnpkMv5FqpWnVaYsr3+n0FlBH0JeURVHpVtGVBVyUwT2McSHNFjWQVBrwWFdPNooXZ4AZN7VZ+QV6i2hH90YGIVf+27dgaJIxwO9J21IZsnI18gGCWJ28CKFyJaa8pZxPII6blawP4NBdTVv6ReGpcVGK49WyNotHH9YQxPmv6d/CXaJGROJlz4E0E9QptTNVD0sJd+8jrl6SooTGrgaRn1keBYeZkEUCRilzcbKzoqXfCanYe9cYmOkHi/+lTF8Aid6ivKJVU0ijaihseqwsHx7JGvHddUnzBLcQGKGnm0nNBgaFLBpo6TuEBVIqUIR6Jl/W0OgmCq3YSVU=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3c952341-0a09-49f0-1c35-08d7eb4dc2fa
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 08:25:51.0895 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: J7dODyBu4e4WcytpCWJycYreIF9rtxjPzZXKF59BrTxzikPu8cwCgPkE7S1s9RDlQmREveKlk/PO3GYuaRRTmQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2774
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 dl-linux-imx <linux-imx@nxp.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

PiBTdWJqZWN0OiBSZTogW1BBVENIXSB4ZW4vc3dpb3RsYjogY29ycmVjdCB0aGUgY2hlY2sgZm9y
DQo+IHhlbl9kZXN0cm95X2NvbnRpZ3VvdXNfcmVnaW9uDQo+IA0KPiBPbiAyOC4wNC4yMCAwOToz
MywgcGVuZy5mYW5AbnhwLmNvbSB3cm90ZToNCj4gPiBGcm9tOiBQZW5nIEZhbiA8cGVuZy5mYW5A
bnhwLmNvbT4NCj4gPg0KPiA+IFdoZW4gYm9vdGluZyB4ZW4gb24gaS5NWDhRTSwgbWV0Og0KPiA+
ICINCj4gPiBbICAgIDMuNjAyMTI4XSBVbmFibGUgdG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVx
dWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MNCj4gMDAwMDAwMDAwMDI3MmQ0MA0KPiA+IFsgICAgMy42
MTA4MDRdIE1lbSBhYm9ydCBpbmZvOg0KPiA+IFsgICAgMy42MTM5MDVdICAgRVNSID0gMHg5NjAw
MDAwNA0KPiA+IFsgICAgMy42MTczMzJdICAgRUMgPSAweDI1OiBEQUJUIChjdXJyZW50IEVMKSwg
SUwgPSAzMiBiaXRzDQo+ID4gWyAgICAzLjYyMzIxMV0gICBTRVQgPSAwLCBGblYgPSAwDQo+ID4g
WyAgICAzLjYyNjYyOF0gICBFQSA9IDAsIFMxUFRXID0gMA0KPiA+IFsgICAgMy42MzAxMjhdIERh
dGEgYWJvcnQgaW5mbzoNCj4gPiBbICAgIDMuNjMzMzYyXSAgIElTViA9IDAsIElTUyA9IDB4MDAw
MDAwMDQNCj4gPiBbICAgIDMuNjM3NjMwXSAgIENNID0gMCwgV25SID0gMA0KPiA+IFsgICAgMy42
NDA5NTVdIFswMDAwMDAwMDAwMjcyZDQwXSB1c2VyIGFkZHJlc3MgYnV0IGFjdGl2ZV9tbSBpcw0K
PiBzd2FwcGVyDQo+ID4gWyAgICAzLjY0Nzk4M10gSW50ZXJuYWwgZXJyb3I6IE9vcHM6IDk2MDAw
MDA0IFsjMV0gUFJFRU1QVCBTTVANCj4gPiBbICAgIDMuNjU0MTM3XSBNb2R1bGVzIGxpbmtlZCBp
bjoNCj4gPiBbICAgIDMuNjc3Mjg1XSBIYXJkd2FyZSBuYW1lOiBGcmVlc2NhbGUgaS5NWDhRTSBN
RUsgKERUKQ0KPiA+IFsgICAgMy42NzczMDJdIFdvcmtxdWV1ZTogZXZlbnRzIGRlZmVycmVkX3By
b2JlX3dvcmtfZnVuYw0KPiA+IFsgICAgMy42ODQyNTNdIGlteDZxLXBjaWUgNWYwMDAwMDAucGNp
ZTogUENJIGhvc3QgYnJpZGdlIHRvIGJ1cyAwMDAwOjAwDQo+ID4gWyAgICAzLjY4ODI5N10gcHN0
YXRlOiA2MDAwMDAwNSAoblpDdiBkYWlmIC1QQU4gLVVBTykNCj4gPiBbICAgIDMuNjg4MzEwXSBw
YyA6IHhlbl9zd2lvdGxiX2ZyZWVfY29oZXJlbnQrMHgxODAvMHgxYzANCj4gPiBbICAgIDMuNjkz
OTkzXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFtidXMgMDAtZmZdDQo+ID4g
WyAgICAzLjcwMTAwMl0gbHIgOiB4ZW5fc3dpb3RsYl9mcmVlX2NvaGVyZW50KzB4NDQvMHgxYzAN
Cj4gPiAiDQo+ID4NCj4gPiBJbiB4ZW5fc3dpb3RsYl9hbGxvY19jb2hlcmVudCwgaWYgIShkZXZf
YWRkciArIHNpemUgLSAxIDw9IGRtYV9tYXNrKQ0KPiA+IG9yIHJhbmdlX3N0cmFkZGxlc19wYWdl
X2JvdW5kYXJ5KHBoeXMsIHNpemUpIGFyZSB0cnVlLCBpdCB3aWxsIGNyZWF0ZQ0KPiA+IGNvbnRp
Z3VvdXMgcmVnaW9uLiBTbyB3aGVuIGZyZWUsIHdlIG5lZWQgdG8gZnJlZSBjb250aWd1b3VzIHJl
Z2lvbiB1c2UNCj4gPiB1cHBlciBjaGVjayBjb25kaXRpb24uDQo+IA0KPiBObywgdGhpcyB3aWxs
IGJyZWFrIFBWIGd1ZXN0cyBvbiB4ODYuDQoNCkNvdWxkIHlvdSBzaGFyZSBtb3JlIGRldGFpbHMg
d2h5IGFsbG9jIGFuZCBmcmVlIG5vdCBtYXRjaGluZyBmb3IgdGhlIGNoZWNrPw0KDQpUaGFua3Ms
DQpQZW5nLg0KDQo+IA0KPiBJIHRoaW5rIHRoZXJlIGlzIHNvbWV0aGluZyB3cm9uZyB3aXRoIHlv
dXIgc2V0dXAgaW4gY29tYmluYXRpb24gd2l0aCB0aGUgQVJNDQo+IHhlbl9jcmVhdGVfY29udGln
dW91c19yZWdpb24oKSBpbXBsZW1lbnRhdGlvbi4NCj4gDQo+IFN0ZWZhbm8/DQo+IA0KPiANCj4g
SnVlcmdlbg0KPiANCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFBlbmcgRmFuIDxwZW5nLmZhbkBu
eHAuY29tPg0KPiA+IC0tLQ0KPiA+ICAgZHJpdmVycy94ZW4vc3dpb3RsYi14ZW4uYyB8IDQgKyst
LQ0KPiA+ICAgMSBmaWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkN
Cj4gPg0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9zd2lvdGxiLXhlbi5jIGIvZHJpdmVy
cy94ZW4vc3dpb3RsYi14ZW4uYw0KPiA+IGluZGV4IGI2ZDI3NzYyYzZmOC4uYWI5NmU0Njg1ODRm
IDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMveGVuL3N3aW90bGIteGVuLmMNCj4gPiArKysgYi9k
cml2ZXJzL3hlbi9zd2lvdGxiLXhlbi5jDQo+ID4gQEAgLTM0Niw4ICszNDYsOCBAQCB4ZW5fc3dp
b3RsYl9mcmVlX2NvaGVyZW50KHN0cnVjdCBkZXZpY2UgKmh3ZGV2LA0KPiBzaXplX3Qgc2l6ZSwg
dm9pZCAqdmFkZHIsDQo+ID4gICAJLyogQ29udmVydCB0aGUgc2l6ZSB0byBhY3R1YWxseSBhbGxv
Y2F0ZWQuICovDQo+ID4gICAJc2l6ZSA9IDFVTCA8PCAob3JkZXIgKyBYRU5fUEFHRV9TSElGVCk7
DQo+ID4NCj4gPiAtCWlmICghV0FSTl9PTigoZGV2X2FkZHIgKyBzaXplIC0gMSA+IGRtYV9tYXNr
KSB8fA0KPiA+IC0JCSAgICAgcmFuZ2Vfc3RyYWRkbGVzX3BhZ2VfYm91bmRhcnkocGh5cywgc2l6
ZSkpICYmDQo+ID4gKwlpZiAoKChkZXZfYWRkciArIHNpemUgLSAxID4gZG1hX21hc2spIHx8DQo+
ID4gKwkgICAgcmFuZ2Vfc3RyYWRkbGVzX3BhZ2VfYm91bmRhcnkocGh5cywgc2l6ZSkpICYmDQo+
ID4gICAJICAgIFRlc3RDbGVhclBhZ2VYZW5SZW1hcHBlZCh2aXJ0X3RvX3BhZ2UodmFkZHIpKSkN
Cj4gPiAgIAkJeGVuX2Rlc3Ryb3lfY29udGlndW91c19yZWdpb24ocGh5cywgb3JkZXIpOw0KPiA+
DQo+ID4NCg0K


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 08:39:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 08:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTLlz-0004Yf-ML; Tue, 28 Apr 2020 08:39:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTLlx-0004YX-NQ
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 08:39:21 +0000
X-Inumbo-ID: bebf5202-892b-11ea-9841-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bebf5202-892b-11ea-9841-12813bfff9fa;
 Tue, 28 Apr 2020 08:39:17 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id F27CFAC2C;
 Tue, 28 Apr 2020 08:39:14 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: George Dunlap <George.Dunlap@citrix.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
 <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
 <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
 <fb0e92cc-102f-7f87-1ad6-f3ccce1eee60@suse.com>
 <064958B4-1FCC-4300-A98A-7A1D608376F8@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <23606595-8ce0-5151-d800-1dc0d97513d1@suse.com>
Date: Tue, 28 Apr 2020 10:39:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <064958B4-1FCC-4300-A98A-7A1D608376F8@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <Andrew.Cooper3@citrix.com>,
 Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.2020 10:24, George Dunlap wrote:
>> On Apr 28, 2020, at 8:20 AM, Jan Beulich <jbeulich@suse.com> wrote:
>> On 27.04.2020 18:25, George Dunlap wrote:
>>> If Jan is OK with it simply being outside CONFIG_EXPERT, then great.  But if he insists on some kind of testing for it to be outside of CONFIG_EXPERT, then again, the people who want it to be security supported should be the ones who do the work to make it happen.
>>
>> I don't understand this part, I'm afraid: Without a config option,
>> the code is going to be security supported as long as it doesn't
>> get marked otherwise (experimental or what not). With an option
>> depending on EXPERT, what would become security unsupported is the
>> non-default (i.e. disabled) setting. There's not a whole lot to
>> test there, it's merely a formal consequence of our general rules.
>> (Of course, over time dependencies of other code may develop on
>> the information being available e.g. to Dom0 userland. Just like
>> there's Linux userland code assuming the kernel config is
>> available in certain ways [I don't necessarily mean the equivalent
>> of hypfs here], to then use it in what I'd call abusive ways in at
>> least some cases.)
> 
> Here’s an argument you might make:
> 
> “As a member of the security team, I don’t want to be on the hook for issuing XSAs for code which isn’t at least smoke-tested.  Therefore, I oppose any patch adding CONFIG_HYPFS outside of CONFIG_EXPERT, *unless* there is a concrete plan for getting regular testing for CONFIG_HYPFS=n.”
> 
> I’m not saying that’s an argument you *should* make.  But personally I don’t have a strong argument against such an argument. So, it seems to me, if you did make it, you have a reasonable chance of carrying your point.
> 
> Now consider this hypothetical universe where you made that argument and nobody opposed it.  In order to get a particular feature (CONFIG_HYPFS=n security supported), there is extra work that needs to be done (getting CONFIG_HYPFS=n tested regularly).  My point was, the expectation should be that the extra work will be done by the people who want or benefit from the feature; the series shouldn’t be blocked until Juergen implements CONFIG_HYPFS=n testing (since he doesn’t personally have a stake in that feature).
> 
> Now obviously, doing work to help someone else out in the community is of course a good thing to do; it builds goodwill, uses our aggregate resources more efficiently, and makes our community more enjoyable to work with.  But the goodwill primarily comes from the fact that it was done as a voluntary choice, not as a requirement.
> 
> Juergen was balking at having to do what he saw as extra work to implement CONFIG_HYPFS.  I wanted to make it clear that even though I see value in having CONFIG_HYPFS, *he* doesn’t have to do the work if he doesn’t want to (although it would certainly be appreciated if he did).  And this paragraph was extending the same principle into the hypothetical universe where someone insisted that CONFIG_HYPFS=n had to be tested before being security supported.
> 
> Hope that makes sense. :-)

Yes, it does, thanks for the clarification. I can see what you describe
as a valid perspective to take, but really in my request to Jürgen I
took another: Now that we have Kconfig, additions of larger bodies of
code (possibly also just in terms of binary size) should imo generally
be questioned whether they want/need to be built for everyone. I.e. it
is not to be left to people being worried about binary sizes to arrange
for things to not be built, but for people contributing new but not
entirely essential code to consider making it option from the very
beginning.

In particular, seeing which patch we're discussing, I find it far less
helpful to have CONFIG_HYPFS_CONFIG when there's no CONFIG_HYPFS, at
least as long as our .config-s are still tiny compared to Linux'es.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 08:58:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 08:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTM4e-0006Rc-GE; Tue, 28 Apr 2020 08:58:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=OLmA=6M=linaro.org=peter.maydell@srs-us1.protection.inumbo.net>)
 id 1jTM4c-0006RX-S0
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 08:58:38 +0000
X-Inumbo-ID: 730d78fe-892e-11ea-ae69-bc764e2007e4
Received: from mail-ot1-x342.google.com (unknown [2607:f8b0:4864:20::342])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 730d78fe-892e-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 08:58:38 +0000 (UTC)
Received: by mail-ot1-x342.google.com with SMTP id g19so31329899otk.5
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 01:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=l2hpbDrVJDciMglrrU6QNbB6BSWSRP9sNw8h+DZwl/E=;
 b=EDLQaW9E3CXg8He4UmN+mR0fEW7PkVCjsogjpBqyWB2YHXKapUzAqLVnU7d2Qr1vAt
 ljhC6vEWo4GcdS2pKiRUyJRmhXk7m9zGQ3C15wRycRhjNFTwmSi0bnJnhFSZKHVNxtKG
 EAMFrmSiAQkxGOjWqIlzA3Yu7v82FM9lhKKu4EszxgsQtM+kG8dLouG9omH0EKjBOv5m
 fSuA8ARjSnuClyTLewRIms/YsPHpwEpos2XkBYZFM4j5v1gjObMC7cQGsAzVATsFLM6E
 nr5A0jn5r8ZO63XZPhxrZtPZYCufHrqMDV+7Qc7agQIq0B0ySdpebP1Va8M0/t7vvpog
 7ngg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=l2hpbDrVJDciMglrrU6QNbB6BSWSRP9sNw8h+DZwl/E=;
 b=UnlVBH8klmogWir7Y5DFVjRv8wJKe3VdV3ZleaEDnK1MqaJJKmztwPz/hy3oEqsB7h
 HoE5XkdoYOlaOGhZV3BAOryweOx+efM48vNjRmcZxQu1h+DgOsaWf4BFNftDo1LAv+NB
 PtF9ndenhrBW7AZETaxCVSvz94p3+QPn3BCBYoSn3pW5wfdLAD9J2lpARR88Ft00WFR8
 vWT1a9ufWJlGDeU6eeNaTW4IsRmKQG0epb8eC65sSxxzpq1vprVFkKkIILaN6Ds+zqbV
 DmlESw0Yuy5N/RdphnUlySqgn1zwT7x2mVW/2h4qe17Cy8kqmC27BLUQI2ZV3aUfY5Cb
 FS1Q==
X-Gm-Message-State: AGi0PuYj61xJ9Q3Ltf17UfBqARhMgh6ukubJ5uO6B7y6TCYDLQGt1eC3
 U1Ke4zKa8yuT9HLcZDiQqX24rxFqswfc/kM0piRZUw==
X-Google-Smtp-Source: APiQypIrD3QflSxSxLsW4iAYUu9Iyq5O44bhWnqv0s1vyoi6VmbguW78rAQZAx4jY7BePqINbh4ZmrXF2AJEaNtw3Rs=
X-Received: by 2002:aca:897:: with SMTP id 145mr209020oii.48.1588064317665;
 Tue, 28 Apr 2020 01:58:37 -0700 (PDT)
MIME-Version: 1.0
References: <20200428062847.7764-1-gorbak25@gmail.com>
 <20200428062847.7764-2-gorbak25@gmail.com>
In-Reply-To: <20200428062847.7764-2-gorbak25@gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 28 Apr 2020 09:58:26 +0100
Message-ID: <CAFEAcA-Ze1phEVK7DoFEtHY_qzyDd1tnakYRqwURD0YWMEGvEQ@mail.gmail.com>
Subject: Re: [PATCH 1/2] Fix undefined behaviour
To: Grzegorz Uriasz <gorbak25@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: artur@puzio.waw.pl, Stefano Stabellini <sstabellini@kernel.org>,
 Paul Durrant <paul@xen.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, QEMU Developers <qemu-devel@nongnu.org>,
 j.nowak26@student.uw.edu.pl, Anthony Perard <anthony.perard@citrix.com>,
 "open list:X86" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, 28 Apr 2020 at 08:50, Grzegorz Uriasz <gorbak25@gmail.com> wrote:
>
> Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>
> ---
>  hw/xen/xen_pt_load_rom.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)

The subject doesn't match the patch contents and there is
no long-form part of the commit message explaining why...

thanks
-- PMM


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 09:05:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 09:05:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTMBa-0007OR-9t; Tue, 28 Apr 2020 09:05:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=c5nG=6M=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTMBZ-0007OM-Eb
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 09:05:49 +0000
X-Inumbo-ID: 73ac1288-892f-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 73ac1288-892f-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 09:05:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=7Ex4oGeyJtMHGteGUUOu2sfpGBhX9fsCbpakoUC4KV4=; b=fsZ4eaJRUAfJq/t66c3nZc3KnW
 eatKSV/D7Vos2beo/FYJE+oKL368WrNDGsPhg78pI6Bofulj5Z/W4ym5+rPIhBc0M1YBjbTWfWKu4
 ZCCFuQ2guTv84DWazTRQoDdVL8SZ7Ejvcggqq1hMqwago8SEkd/8cmjeSoYtrtiiEeQc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTMBV-0007DN-3O; Tue, 28 Apr 2020 09:05:45 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTMBU-0000W3-Nl; Tue, 28 Apr 2020 09:05:45 +0000
Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration
 document...
To: Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200427155035.668-1-paul@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <7ab25832-66e6-020f-b343-059f21771054@xen.org>
Date: Tue, 28 Apr 2020 10:05:42 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200427155035.668-1-paul@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 27/04/2020 16:50, Paul Durrant wrote:
> diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
> index 6ab351e8fe..51d8b85171 100644
> --- a/docs/designs/xenstore-migration.md
> +++ b/docs/designs/xenstore-migration.md
> @@ -3,254 +3,400 @@
>   ## Background
>   
>   The design for *Non-Cooperative Migration of Guests*[1] explains that extra
> -save records are required in the migrations stream to allow a guest running
> -PV drivers to be migrated without its co-operation. Moreover the save
> -records must include details of registered xenstore watches as well as
> -content; information that cannot currently be recovered from `xenstored`,
> -and hence some extension to the xenstore protocol[2] will also be required.
> -
> -The *libxenlight Domain Image Format* specification[3] already defines a
> -record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
> -transferring xenstore data pertaining to the domain directly as it is
> -specified such that keys are relative to the path
> -`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
> -define at least one new save record type.
> +save records are required in the migrations stream to allow a guest running PV
> +drivers to be migrated without its co-operation. Moreover the save records must
> +include details of registered xenstore watches as well ascontent; information

s/ascontent/as content/

[...]

> +### END
> +
> +The end record marks the end of the image, and is the final record
> +in the stream.
>   
>   ```
> -    0       1       2       3     octet
> -+-------+-------+-------+-------+
> -| NODE_DATA                     |
> -+-------------------------------+
> -| path length                   |
> -+-------------------------------+
> -| path data                     |
> -...
> -| pad (0 to 3 octets)           |
> -+-------------------------------+
> -| perm count (N)                |
> -+-------------------------------+
> -| perm0                         |
> -+-------------------------------+
> -...
> -+-------------------------------+
> -| permN                         |
> -+-------------------------------+
> -| value length                  |
> -+-------------------------------+
> -| value data                    |
> -...
> -| pad (0 to 3 octets)           |
> -+-------------------------------+
> +    0       1       2       3       4       5       6       7    octet
> ++-------+-------+-------+-------+-------+-------+-------+-------+
>   ```
>   
> -where perm0..N are formatted as follows:
>   
> +The end record contains no fields; its body length is 0.
> +
> +\pagebreak
> +
> +### GLOBAL_DATA
> +
> +This record is only relevant for live update. It contains details of global
> +xenstored state that needs to be restored.

Reading this paragraph, it sounds like GLOBAL_DATA should always be 
present in the liveupdate stream. However ...

[...]

> -path length and value length are specified in octets (excluding the NUL
> -terminator of the path). perm should be one of the ASCII values `w`, `r`,
> -`b` or `n` as described in [2]. All pad values should be 0.
> -All paths should be absolute (i.e. start with `/`) and as described in
> -[2].
> +| Field          | Description                                  |
> +|----------------|----------------------------------------------|
> +| `rw-socket-fd` | The file descriptor of the socket accepting  |
> +|                | read-write connections                       |
> +|                |                                              |
> +| `ro-socket-fd` | The file descriptor of the socket accepting  |
> +|                | read-only connections                        |
>   
> +xenstored will resume in the original process context. Hence `rw-socket-fd` and
> +`ro-socket-fd` simply specify the file descriptors of the sockets.

... sockets may not always be available in XenStored. So should we 
reserve a value for "not in-use socket"?

[...]

> -wpath length and token length are specified in octets (excluding the NUL
> -terminator). The wpath should be as described for the `WATCH` operation in
> -[2]. The token is an arbitrary string of octets not containing any NUL
> -values.
>   
> +| Field       | Description                                     |
> +|-------------|-------------------------------------------------|
> +| `conn-id`   | A non-zero number used to identify this         |
> +|             | connection in subsequent connection-specific    |
> +|             | records                                         |
> +|             |                                                 |
> +| `conn-type` | 0x0000: shared ring                             |
> +|             | 0x0001: socket                                  |

I would write "0x0002 - 0xFFFF: reserved for future use" to match the 
rest of the specification.

[...]

> -where tx_id is the non-zero identifier values of an open transaction.
>   
> +| Field     | Description                                       |
> +|-----------|---------------------------------------------------|
> +| `domid`   | The domain-id that owns the shared page           |
> +|           |                                                   |
> +| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
> +|           | it has been subject to an SET_TARGET              |
> +|           | operation [2] or DOMID_INVALID [3] otherwise      |
> +|           |                                                   |
> +| `flags`   | Must be zero                                      |
> +|           |                                                   |
> +| `evtchn`  | The port number of the interdomain channel used   |
> +|           | by `domid` to communicate with xenstored          |
> +|           |                                                   |
> +| `mfn`     | The MFN of the shared page for a live update or   |
> +|           | ~0 (i.e. all bits set) otherwise                  |
>   
> -### Protocol Extension
> +Since the ABI guarantees that entry 1 in `domid`'s grant table will always
> +contain the GFN of the shared page, so for a live update `mfn` can be used to
> +give confidence that `domid` has not been re-cycled during the update.

I am confused, there is no way a XenStored running in an Arm domain can 
map the MFN of the shared page. So how is this going to work out?

[...]

> -START_DOMAIN_TRANSACTION    <domid>|<transid>|
> +    0       1       2       3    octet
> ++-------+-------+-------+-------+
> +| conn-id                       |
> ++-------------------------------+
> +| tx-id                         |
> ++---------------+---------------+
> +| path-len      | value-len     |
> ++---------------+---------------+
> +| access        | perm-count    |
> ++---------------+---------------+
> +| perm1                         |
> ++-------------------------------+
> +...
> ++-------------------------------+
> +| permN                         |
> ++---------------+---------------+
> +| path
> +...
> +| value
> +...
> +```
> +
> +
> +| Field        | Description                                    |
> +|--------------|------------------------------------------------|
> +| `conn-id`    | If this value is non-zero then this record     |
> +|              | related to a pending transaction               |

If conn-id is 0, how do you know the owner of the node?

> +|              |                                                |
> +| `tx-id`      | This value should be ignored if `conn-id` is   |
> +|              | zero. Otherwise it specifies the id of the     |
> +|              | pending transaction                            |
> +|              |                                                |
> +| `path-len`   | The length (in octets) of `path` including the |
> +|              | NUL terminator                                 |
> +|              |                                                |
> +| `value-len`  | The length (in octets) of `value` (which will  |
> +|              | be zero for a deleted node)                    |
> +|              |                                                |
> +| `access`     | This value should be ignored if this record    |
> +|              | does not relate to a pending transaction,      |
> +|              | otherwise it specifies the accesses made to    |
> +|              | the node and hence is a bitwise OR of:         |
> +|              |                                                |
> +|              | 0x0001: read                                   |
> +|              | 0x0002: written                                |
> +|              |                                                |
> +|              | The value will be zero for a deleted node      |
> +|              |                                                |
> +| `perm-count` | The number (N) of node permission specifiers   |
> +|              | (which will be 0 for a node deleted in a       |
> +|              | pending transaction)                           |
> +|              |                                                |
> +| `perm1..N`   | A list of zero or more node permission         |
> +|              | specifiers (see below)                         |

This is a bit odd to start at one. Does it mean perm0 exists and not 
preserved?

> +|              |                                                |
> +| `path`       | The absolute path of the node                  |
> +|              |                                                |
> +| `value`      | The node value (which may be empty or contain  |
> +|              | NUL octets)                                    |

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 09:43:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 09:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTMm9-0002Ud-Az; Tue, 28 Apr 2020 09:43:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=c5nG=6M=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTMm7-0002UY-LQ
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 09:43:35 +0000
X-Inumbo-ID: ba8ee572-8934-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ba8ee572-8934-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 09:43:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=CLxcQIFLF32J9+tiUSzaNz79a2kscluBH/BRJRCbHHE=; b=rEMTVotaNXsDQvKG7maLHzYgyO
 6DC2zdlK4lVW+w1Qc/5089DuxuFtq8bHur3up6Qg/VzH8u5bRQZjdYxMfkvr6GGXHRKH+AcOHV/wd
 NGUgTELLOx6tGPKmY6e0D3jE+MSdPwfW7DPnBKLPvpmjsj5dBP8X3QLihOsI5uN8/AxA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTMm6-0007xi-NI; Tue, 28 Apr 2020 09:43:34 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTMm6-0003Kj-9S; Tue, 28 Apr 2020 09:43:34 +0000
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: Jan Beulich <jbeulich@suse.com>, George Dunlap <George.Dunlap@citrix.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
 <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
 <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
 <fb0e92cc-102f-7f87-1ad6-f3ccce1eee60@suse.com>
 <064958B4-1FCC-4300-A98A-7A1D608376F8@citrix.com>
 <23606595-8ce0-5151-d800-1dc0d97513d1@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <304ab794-4d04-ae0d-d644-a7ddb0f23bf4@xen.org>
Date: Tue, 28 Apr 2020 10:43:32 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <23606595-8ce0-5151-d800-1dc0d97513d1@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 28/04/2020 09:39, Jan Beulich wrote:
> On 28.04.2020 10:24, George Dunlap wrote:
>>> On Apr 28, 2020, at 8:20 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>> On 27.04.2020 18:25, George Dunlap wrote:
>>>> If Jan is OK with it simply being outside CONFIG_EXPERT, then great.  But if he insists on some kind of testing for it to be outside of CONFIG_EXPERT, then again, the people who want it to be security supported should be the ones who do the work to make it happen.
>>>
>>> I don't understand this part, I'm afraid: Without a config option,
>>> the code is going to be security supported as long as it doesn't
>>> get marked otherwise (experimental or what not). With an option
>>> depending on EXPERT, what would become security unsupported is the
>>> non-default (i.e. disabled) setting. There's not a whole lot to
>>> test there, it's merely a formal consequence of our general rules.
>>> (Of course, over time dependencies of other code may develop on
>>> the information being available e.g. to Dom0 userland. Just like
>>> there's Linux userland code assuming the kernel config is
>>> available in certain ways [I don't necessarily mean the equivalent
>>> of hypfs here], to then use it in what I'd call abusive ways in at
>>> least some cases.)
>>
>> Here’s an argument you might make:
>>
>> “As a member of the security team, I don’t want to be on the hook for issuing XSAs for code which isn’t at least smoke-tested.  Therefore, I oppose any patch adding CONFIG_HYPFS outside of CONFIG_EXPERT, *unless* there is a concrete plan for getting regular testing for CONFIG_HYPFS=n.”
>>
>> I’m not saying that’s an argument you *should* make.  But personally I don’t have a strong argument against such an argument. So, it seems to me, if you did make it, you have a reasonable chance of carrying your point.
>>
>> Now consider this hypothetical universe where you made that argument and nobody opposed it.  In order to get a particular feature (CONFIG_HYPFS=n security supported), there is extra work that needs to be done (getting CONFIG_HYPFS=n tested regularly).  My point was, the expectation should be that the extra work will be done by the people who want or benefit from the feature; the series shouldn’t be blocked until Juergen implements CONFIG_HYPFS=n testing (since he doesn’t personally have a stake in that feature).
>>
>> Now obviously, doing work to help someone else out in the community is of course a good thing to do; it builds goodwill, uses our aggregate resources more efficiently, and makes our community more enjoyable to work with.  But the goodwill primarily comes from the fact that it was done as a voluntary choice, not as a requirement.
>>
>> Juergen was balking at having to do what he saw as extra work to implement CONFIG_HYPFS.  I wanted to make it clear that even though I see value in having CONFIG_HYPFS, *he* doesn’t have to do the work if he doesn’t want to (although it would certainly be appreciated if he did).  And this paragraph was extending the same principle into the hypothetical universe where someone insisted that CONFIG_HYPFS=n had to be tested before being security supported.
>>
>> Hope that makes sense. :-)
> 
> Yes, it does, thanks for the clarification. I can see what you describe
> as a valid perspective to take, but really in my request to Jürgen I
> took another: Now that we have Kconfig, additions of larger bodies of
> code (possibly also just in terms of binary size) should imo generally
> be questioned whether they want/need to be built for everyone. I.e. it
> is not to be left to people being worried about binary sizes to arrange
> for things to not be built, but for people contributing new but not
> entirely essential code to consider making it option from the very
> beginning.

I like the idea to have a more configurable Xen but this also comes at 
the expense of the testing/support.

At the moment, we are getting around the problem by gating the new 
config options with CONFIG_EXPERT. I have stoppped counting the number 
of time I sweared because my config got rewritten when using 'make 
clean' or explain to someone else how to use it.

As it stands, CONFIG_EXPERT is unusable and most likely anything behind 
it will rot quite quickly. So if we want to add more stuff behind it, 
then I would suggest to make it more accessible so any developper can 
experiment with it.

Going forward, I would expect the embedded folks to want more part of 
Xen configurable. Requesting them to use CONFIG_EXPERT may be an issue 
as this means we would not security support them. At the same time, I 
understand that exposing a CONFIG increase the testing matrix. How about 
declaring we are supporting/testing a given set of .config? On Arm it 
would be defconfig and tiny.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 09:46:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 09:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTMof-0002bQ-Om; Tue, 28 Apr 2020 09:46:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=v0V7=6M=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jTMof-0002bL-06
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 09:46:13 +0000
X-Inumbo-ID: 17227152-8935-11ea-9846-12813bfff9fa
Received: from mail-wr1-f66.google.com (unknown [209.85.221.66])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 17227152-8935-11ea-9846-12813bfff9fa;
 Tue, 28 Apr 2020 09:46:11 +0000 (UTC)
Received: by mail-wr1-f66.google.com with SMTP id j2so23862577wrs.9
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 02:46:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-disposition:in-reply-to:user-agent;
 bh=vNPKI8dZx+Js36heDOFqxHvf7xx5J4kd02lTrLE7UPI=;
 b=b1Cm8uBfTYpROIbhjZGpG2r9opPWoq9HtJ5CqCox2Pe+08sHKX2t2NDKV6hW3FXB0n
 eKrL4sQ6NM/CIg0EDAUQpk1rrZj+yJH7WlSXxj47eY58+B6bnJvF9FvadWH0egbwOOR3
 Lj5PfJXLLqaOgvkL3Ix2UbZ1LpvJxNWl0VozL4mN/kmVOB07ib36emGQ+wE3etqco3Le
 A/0w5fXs11oRWtCWxl+Evgc95+ypOSZ22DE1vWtVDL2NXMgIGok5Dd1mKIFIH9Sf8R9M
 p6LVCrbFbjd38Dc0o7XBZjnXRNRG9/wBJUez7OlTXzK7KObnMu0VP5IJCi0MIQrzKi/Z
 KtqA==
X-Gm-Message-State: AGi0PuYEwzPTFSHBiIFji6JvC+8hYeEJjXpZYULprOnfFhQ4n2op8M8+
 8vLlTc2pWrH9aNW5nE+sFV8=
X-Google-Smtp-Source: APiQypJ8vaa3KS8dzpNzdFkGVM+VsA/aQpoiQf67GCHEgnmp15SwMEn7QVvlAm28il1KSyykw86hOA==
X-Received: by 2002:adf:8543:: with SMTP id 61mr30446313wrh.243.1588067170691; 
 Tue, 28 Apr 2020 02:46:10 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id h16sm27739488wrw.36.2020.04.28.02.46.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Apr 2020 02:46:09 -0700 (PDT)
Date: Tue, 28 Apr 2020 09:46:08 +0000
From: Wei Liu <wl@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 01/12] libxc/save: Shrink code volume where possible
Message-ID: <20200428094608.7ynqp2djjmxcshzf@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <20191224151932.6304-1-andrew.cooper3@citrix.com>
 <20191224151932.6304-2-andrew.cooper3@citrix.com>
 <24093.61657.676890.721999@mariner.uk.xensource.com>
 <a10d1572-d5c5-716a-0651-aee2345348dd@citrix.com>
 <24231.5161.862828.377795@mariner.uk.xensource.com>
 <20200427195542.yiuvw4xgfjfzn6wh@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
 <df22f0c7-0bca-ea42-976b-3de530cc83cf@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <df22f0c7-0bca-ea42-976b-3de530cc83cf@citrix.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wl@xen.org>,
 Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 09:00:30PM +0100, Andrew Cooper wrote:
> On 27/04/2020 20:55, Wei Liu wrote:
> > On Mon, Apr 27, 2020 at 06:19:37PM +0100, Ian Jackson wrote:
> >> Andrew Cooper writes ("Re: [PATCH 01/12] libxc/save: Shrink code volume where possible"):
> >>> On 14/01/2020 16:48, Ian Jackson wrote:
> >>>> Andrew Cooper writes ("[PATCH 01/12] libxc/save: Shrink code volume where possible"):
> >>>>> A property of how the error handling (0 on success, nonzero otherwise)
> >>>>> allows these calls to be chained together with the ternary operatior.
> >>>> I'm quite surprised to find a suggestion like this coming from you in
> >>>> particular.
> >>> What probably is relevant is that ?: is a common construct in the
> >>> hypervisor, which I suppose does colour my expectation of people knowing
> >>> exactly what it means and how it behaves.
> >> I expect other C programmers to know what ?: does, too.  But I think
> >> using it to implement the error monad is quite unusual.  I asked
> >> around a bit and my feeling is still that this isn't an improvement.
> >>
> >>>> Or just to permit
> >>>>    rc = write_one_vcpu_basic(ctx, i);    if (rc) goto error;
> >>>> (ie on a single line).
> >>> OTOH, it should come as no surprise that I'd rather drop this patch
> >>> entirely than go with these alternatives, both of which detract from
> >>> code clarity. The former for hiding control flow, and the latter for
> >>> being atypical layout which unnecessary cognitive load to follow.
> >> I think, then, that it would be best to drop this patch, unless Wei
> >> (or someone else) disagrees with me.
> > I don't feel strongly either way.
> 
> I'm confused... I dropped this 3 and a half months ago, because it was
> blindingly obvious it was going nowhere.
> 
> This is the v1 series which was totally superseded by the v2 series also
> posted in January.

OK. I saw Ian's reply on 27th and thought it was still in progress.

Wei.


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 10:00:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 10:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTN1y-0003gA-3J; Tue, 28 Apr 2020 09:59:58 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTN1x-0003g5-Fk
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 09:59:57 +0000
X-Inumbo-ID: 00c5851d-8937-11ea-9846-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 00c5851d-8937-11ea-9846-12813bfff9fa;
 Tue, 28 Apr 2020 09:59:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B8B45AD07;
 Tue, 28 Apr 2020 09:59:50 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: Julien Grall <julien@xen.org>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
 <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
 <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
 <fb0e92cc-102f-7f87-1ad6-f3ccce1eee60@suse.com>
 <064958B4-1FCC-4300-A98A-7A1D608376F8@citrix.com>
 <23606595-8ce0-5151-d800-1dc0d97513d1@suse.com>
 <304ab794-4d04-ae0d-d644-a7ddb0f23bf4@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <26926b3c-11ee-345b-5602-c4607dbe37ae@suse.com>
Date: Tue, 28 Apr 2020 11:59:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <304ab794-4d04-ae0d-d644-a7ddb0f23bf4@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>, Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.2020 11:43, Julien Grall wrote:
> Hi Jan,
> 
> On 28/04/2020 09:39, Jan Beulich wrote:
>> On 28.04.2020 10:24, George Dunlap wrote:
>>>> On Apr 28, 2020, at 8:20 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 27.04.2020 18:25, George Dunlap wrote:
>>>>> If Jan is OK with it simply being outside CONFIG_EXPERT, then great.  But if he insists on some kind of testing for it to be outside of CONFIG_EXPERT, then again, the people who want it to be security supported should be the ones who do the work to make it happen.
>>>>
>>>> I don't understand this part, I'm afraid: Without a config option,
>>>> the code is going to be security supported as long as it doesn't
>>>> get marked otherwise (experimental or what not). With an option
>>>> depending on EXPERT, what would become security unsupported is the
>>>> non-default (i.e. disabled) setting. There's not a whole lot to
>>>> test there, it's merely a formal consequence of our general rules.
>>>> (Of course, over time dependencies of other code may develop on
>>>> the information being available e.g. to Dom0 userland. Just like
>>>> there's Linux userland code assuming the kernel config is
>>>> available in certain ways [I don't necessarily mean the equivalent
>>>> of hypfs here], to then use it in what I'd call abusive ways in at
>>>> least some cases.)
>>>
>>> Here’s an argument you might make:
>>>
>>> “As a member of the security team, I don’t want to be on the hook for issuing XSAs for code which isn’t at least smoke-tested.  Therefore, I oppose any patch adding CONFIG_HYPFS outside of CONFIG_EXPERT, *unless* there is a concrete plan for getting regular testing for CONFIG_HYPFS=n.”
>>>
>>> I’m not saying that’s an argument you *should* make.  But personally I don’t have a strong argument against such an argument. So, it seems to me, if you did make it, you have a reasonable chance of carrying your point.
>>>
>>> Now consider this hypothetical universe where you made that argument and nobody opposed it.  In order to get a particular feature (CONFIG_HYPFS=n security supported), there is extra work that needs to be done (getting CONFIG_HYPFS=n tested regularly).  My point was, the expectation should be that the extra work will be done by the people who want or benefit from the feature; the series shouldn’t be blocked until Juergen implements CONFIG_HYPFS=n testing (since he doesn’t personally have a stake in that feature).
>>>
>>> Now obviously, doing work to help someone else out in the community is of course a good thing to do; it builds goodwill, uses our aggregate resources more efficiently, and makes our community more enjoyable to work with.  But the goodwill primarily comes from the fact that it was done as a voluntary choice, not as a requirement.
>>>
>>> Juergen was balking at having to do what he saw as extra work to implement CONFIG_HYPFS.  I wanted to make it clear that even though I see value in having CONFIG_HYPFS, *he* doesn’t have to do the work if he doesn’t want to (although it would certainly be appreciated if he did).  And this paragraph was extending the same principle into the hypothetical universe where someone insisted that CONFIG_HYPFS=n had to be tested before being security supported.
>>>
>>> Hope that makes sense. :-)
>>
>> Yes, it does, thanks for the clarification. I can see what you describe
>> as a valid perspective to take, but really in my request to Jürgen I
>> took another: Now that we have Kconfig, additions of larger bodies of
>> code (possibly also just in terms of binary size) should imo generally
>> be questioned whether they want/need to be built for everyone. I.e. it
>> is not to be left to people being worried about binary sizes to arrange
>> for things to not be built, but for people contributing new but not
>> entirely essential code to consider making it option from the very
>> beginning.
> 
> I like the idea to have a more configurable Xen but this also comes at the expense of the testing/support.
> 
> At the moment, we are getting around the problem by gating the new config options with CONFIG_EXPERT. I have stoppped counting the number of time I sweared because my config got rewritten when using 'make clean' or explain to someone else how to use it.
> 
> As it stands, CONFIG_EXPERT is unusable and most likely anything behind it will rot quite quickly. So if we want to add more stuff behind it, then I would suggest to make it more accessible so any developper can experiment with it.

This complaint is not new; what I'm missing are concrete suggestions
on how to improve the situation.

> Going forward, I would expect the embedded folks to want more part of Xen configurable. Requesting them to use CONFIG_EXPERT may be an issue as this means we would not security support them. At the same time, I understand that exposing a CONFIG increase the testing matrix. How about declaring we are supporting/testing a given set of .config? On Arm it would be defconfig and tiny.

We could do this, sure, but it would end up being rather limiting at
least on the x86 side.

Considering how frequently this is coming up, perhaps instead we
should drop use of EXPERT mostly or altogether, and declare that
we're willing to live with the fallout? We could document options
or option combinations we specifically exclude from being supported
then ...

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 10:00:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 10:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTN2q-0004W5-El; Tue, 28 Apr 2020 10:00:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=p0bN=6M=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jTN2p-0004Vu-7r
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 10:00:51 +0000
X-Inumbo-ID: 23726972-8937-11ea-ae69-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 23726972-8937-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 10:00:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588068050;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=8OesVpAHyRD5/QC7oXevGEfVAZ+AqDF+l3jln2eeii8=;
 b=fUVIknj5xTOycoJv3MLeLLHw4A4zAsQ3z1/kdFX+LNZS31sZZdRj/8Ks
 k09L6s14SZrUtKcnPfQESLEKG4AecUa1m/bJBBsjlnytkot+v0xJhqGJ6
 sWVXtsTr3oLfS+Zh47rT6z0KhcA3UQyK7uTqYXSSReDaonwe8wqxgg+E/ M=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Q9XRAlwYkBHl97eX9Mn/+A5sOWPeQeABfBWYRpa0Ikk5cv3r9ye7Sh3rHW9GECWizqyQG0VRDE
 uRieiNWx9FeEMn4ll9XM87vFiDPZkNyvtzJRjIZAFOu6lk1Lv4wPM6pQXo36JINH0DwHAU3LDu
 MVcFQRfc6GBK2DVqeOude+yf7+Q5gSg2cbPAvFR6d1ktOTM8bCEUYnY0NxP39D7VhzKAP6Qn/g
 IWLsaxNt7Q5mklrtDMfgABrDCO7Vpm5/wrFK0OZj6SYb54HLk9wZz2LvNTRP942uPRdpQCx+7i
 CgY=
X-SBRS: 2.7
X-MesageID: 16671844
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,327,1583211600"; d="scan'208";a="16671844"
Date: Tue, 28 Apr 2020 12:00:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Subject: Re: [PATCH] mem_sharing: map shared_info page to same gfn during fork
Message-ID: <20200428100042.GT28601@Air-de-Roger>
References: <08d022bbca06c59624817ac9e23ddcb288121763.1588004969.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <08d022bbca06c59624817ac9e23ddcb288121763.1588004969.git.tamas.lengyel@intel.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 09:36:05AM -0700, Tamas K Lengyel wrote:
> During a VM fork we copy the shared_info page; however, we also need to ensure
> that the page is mapped into the same GFN in the fork as its in the parent.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> Suggested-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  xen/arch/x86/mm/mem_sharing.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 344a5bfb3d..acbf21b22c 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1656,6 +1656,7 @@ static void copy_tsc(struct domain *cd, struct domain *d)
>  static int copy_special_pages(struct domain *cd, struct domain *d)
>  {
>      mfn_t new_mfn, old_mfn;
> +    gfn_t old_gfn;
>      struct p2m_domain *p2m = p2m_get_hostp2m(cd);
>      static const unsigned int params[] =
>      {
> @@ -1701,6 +1702,34 @@ static int copy_special_pages(struct domain *cd, struct domain *d)
>      new_mfn = _mfn(virt_to_mfn(cd->shared_info));
>      copy_domain_page(new_mfn, old_mfn);
>  
> +    old_gfn = _gfn(get_gpfn_from_mfn(mfn_x(old_mfn)));
> +
> +    if ( !gfn_eq(old_gfn, INVALID_GFN) )

I think you need to compare the parent shared info gfn against the
child shared info gfn, in case the child has mapped the shared info
but the parent doesn't have it mapped. In which case you want to
remove the mapping when doing a fork reset.

> +    {
> +        /* let's make sure shared_info is mapped to the same gfn */
> +        gfn_t new_gfn = _gfn(get_gpfn_from_mfn(mfn_x(new_mfn)));
> +
> +        if ( !gfn_eq(new_gfn, INVALID_GFN) && !gfn_eq(old_gfn, new_gfn) )

You can then remove the last condition in this if.

> +        {
> +            /* if shared info is mapped to a different gfn just remove it */
> +            rc = p2m->set_entry(p2m, new_gfn, INVALID_MFN, PAGE_ORDER_4K,
> +                                p2m_invalid, p2m->default_access, -1);
> +            if ( rc )
> +                return rc;
> +
> +            new_gfn = INVALID_GFN;
> +        }
> +
> +        if ( gfn_eq(new_gfn, INVALID_GFN) )

And this should then be if ( !gfn_eq(old_gfn, INVALID_GFN) ) ...

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 10:06:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 10:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTN80-0004of-5A; Tue, 28 Apr 2020 10:06:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=c5nG=6M=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTN7y-0004oa-Jj
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 10:06:10 +0000
X-Inumbo-ID: e214778a-8937-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e214778a-8937-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 10:06:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2428JvOxmqbJVE6MC3VW9164x8yTcsFVcaiWK3PSEyc=; b=WbVKq00uIgL8khQwD0Vx0EzIkD
 t6EAysqr/P5uXHd9PJgrEZgrc0lYG5GLvRiNxOrk72VEynUW/lm8NShi9igI4E/2jeJdznt7nasER
 zW+EauAezyfK5bLHFyWSBl/Yc8KeeQBfzmdw5h6m6R1ZK8GQNMusncw+YlY+PcxtjN4c=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTN7x-0008WG-Bp; Tue, 28 Apr 2020 10:06:09 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTN7x-00056B-0q; Tue, 28 Apr 2020 10:06:09 +0000
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
 <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
 <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
 <fb0e92cc-102f-7f87-1ad6-f3ccce1eee60@suse.com>
 <064958B4-1FCC-4300-A98A-7A1D608376F8@citrix.com>
 <23606595-8ce0-5151-d800-1dc0d97513d1@suse.com>
 <304ab794-4d04-ae0d-d644-a7ddb0f23bf4@xen.org>
 <26926b3c-11ee-345b-5602-c4607dbe37ae@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <e8d3539b-618b-969d-4c56-a08959393a4a@xen.org>
Date: Tue, 28 Apr 2020 11:06:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <26926b3c-11ee-345b-5602-c4607dbe37ae@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <Andrew.Cooper3@citrix.com>,
 George Dunlap <George.Dunlap@citrix.com>, Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 28/04/2020 10:59, Jan Beulich wrote:
> On 28.04.2020 11:43, Julien Grall wrote:
>> Hi Jan,
>>
>> On 28/04/2020 09:39, Jan Beulich wrote:
>>> On 28.04.2020 10:24, George Dunlap wrote:
>>>>> On Apr 28, 2020, at 8:20 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>> On 27.04.2020 18:25, George Dunlap wrote:
>>>>>> If Jan is OK with it simply being outside CONFIG_EXPERT, then great.  But if he insists on some kind of testing for it to be outside of CONFIG_EXPERT, then again, the people who want it to be security supported should be the ones who do the work to make it happen.
>>>>>
>>>>> I don't understand this part, I'm afraid: Without a config option,
>>>>> the code is going to be security supported as long as it doesn't
>>>>> get marked otherwise (experimental or what not). With an option
>>>>> depending on EXPERT, what would become security unsupported is the
>>>>> non-default (i.e. disabled) setting. There's not a whole lot to
>>>>> test there, it's merely a formal consequence of our general rules.
>>>>> (Of course, over time dependencies of other code may develop on
>>>>> the information being available e.g. to Dom0 userland. Just like
>>>>> there's Linux userland code assuming the kernel config is
>>>>> available in certain ways [I don't necessarily mean the equivalent
>>>>> of hypfs here], to then use it in what I'd call abusive ways in at
>>>>> least some cases.)
>>>>
>>>> Here’s an argument you might make:
>>>>
>>>> “As a member of the security team, I don’t want to be on the hook for issuing XSAs for code which isn’t at least smoke-tested.  Therefore, I oppose any patch adding CONFIG_HYPFS outside of CONFIG_EXPERT, *unless* there is a concrete plan for getting regular testing for CONFIG_HYPFS=n.”
>>>>
>>>> I’m not saying that’s an argument you *should* make.  But personally I don’t have a strong argument against such an argument. So, it seems to me, if you did make it, you have a reasonable chance of carrying your point.
>>>>
>>>> Now consider this hypothetical universe where you made that argument and nobody opposed it.  In order to get a particular feature (CONFIG_HYPFS=n security supported), there is extra work that needs to be done (getting CONFIG_HYPFS=n tested regularly).  My point was, the expectation should be that the extra work will be done by the people who want or benefit from the feature; the series shouldn’t be blocked until Juergen implements CONFIG_HYPFS=n testing (since he doesn’t personally have a stake in that feature).
>>>>
>>>> Now obviously, doing work to help someone else out in the community is of course a good thing to do; it builds goodwill, uses our aggregate resources more efficiently, and makes our community more enjoyable to work with.  But the goodwill primarily comes from the fact that it was done as a voluntary choice, not as a requirement.
>>>>
>>>> Juergen was balking at having to do what he saw as extra work to implement CONFIG_HYPFS.  I wanted to make it clear that even though I see value in having CONFIG_HYPFS, *he* doesn’t have to do the work if he doesn’t want to (although it would certainly be appreciated if he did).  And this paragraph was extending the same principle into the hypothetical universe where someone insisted that CONFIG_HYPFS=n had to be tested before being security supported.
>>>>
>>>> Hope that makes sense. :-)
>>>
>>> Yes, it does, thanks for the clarification. I can see what you describe
>>> as a valid perspective to take, but really in my request to Jürgen I
>>> took another: Now that we have Kconfig, additions of larger bodies of
>>> code (possibly also just in terms of binary size) should imo generally
>>> be questioned whether they want/need to be built for everyone. I.e. it
>>> is not to be left to people being worried about binary sizes to arrange
>>> for things to not be built, but for people contributing new but not
>>> entirely essential code to consider making it option from the very
>>> beginning.
>>
>> I like the idea to have a more configurable Xen but this also comes at the expense of the testing/support.
>>
>> At the moment, we are getting around the problem by gating the new config options with CONFIG_EXPERT. I have stoppped counting the number of time I sweared because my config got rewritten when using 'make clean' or explain to someone else how to use it.
>>
>> As it stands, CONFIG_EXPERT is unusable and most likely anything behind it will rot quite quickly. So if we want to add more stuff behind it, then I would suggest to make it more accessible so any developper can experiment with it.
> 
> This complaint is not new; what I'm missing are concrete suggestions
> on how to improve the situation.

It is quite easy to improve, rather than specifying on the command line 
we could introduce a new Kconfig option so the user can select it normally.

This would not be very different compare to what Linux does.

> 
>> Going forward, I would expect the embedded folks to want more part of Xen configurable. Requesting them to use CONFIG_EXPERT may be an issue as this means we would not security support them. At the same time, I understand that exposing a CONFIG increase the testing matrix. How about declaring we are supporting/testing a given set of .config? On Arm it would be defconfig and tiny.
> 
> We could do this, sure, but it would end up being rather limiting at
> least on the x86 side.

It would not be worse than where we are today, right?

> 
> Considering how frequently this is coming up, perhaps instead we
> should drop use of EXPERT mostly or altogether, and declare that
> we're willing to live with the fallout? We could document options
> or option combinations we specifically exclude from being supported
> then ...

I would not suggest to remove EXPERT so far, just to make easier to use
of EXPERT.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 10:10:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 10:10:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTNCW-0005dS-PV; Tue, 28 Apr 2020 10:10:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=DYx7=6M=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTNCV-0005dN-W1
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 10:10:52 +0000
X-Inumbo-ID: 89587f5a-8938-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 89587f5a-8938-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 10:10:50 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B67FCAD4D;
 Tue, 28 Apr 2020 10:10:48 +0000 (UTC)
Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration
 document...
To: Julien Grall <julien@xen.org>, Paul Durrant <paul@xen.org>,
 xen-devel@lists.xenproject.org
References: <20200427155035.668-1-paul@xen.org>
 <7ab25832-66e6-020f-b343-059f21771054@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <f13de8bc-ca5d-2341-3797-b34f9f2c70ef@suse.com>
Date: Tue, 28 Apr 2020 12:10:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7ab25832-66e6-020f-b343-059f21771054@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.20 11:05, Julien Grall wrote:
> Hi Paul,
> 
> On 27/04/2020 16:50, Paul Durrant wrote:
>> diff --git a/docs/designs/xenstore-migration.md 
>> b/docs/designs/xenstore-migration.md
>> index 6ab351e8fe..51d8b85171 100644
>> --- a/docs/designs/xenstore-migration.md
>> +++ b/docs/designs/xenstore-migration.md
>> @@ -3,254 +3,400 @@
>>   ## Background
>>   The design for *Non-Cooperative Migration of Guests*[1] explains 
>> that extra
>> -save records are required in the migrations stream to allow a guest 
>> running
>> -PV drivers to be migrated without its co-operation. Moreover the save
>> -records must include details of registered xenstore watches as well as
>> -content; information that cannot currently be recovered from 
>> `xenstored`,
>> -and hence some extension to the xenstore protocol[2] will also be 
>> required.
>> -
>> -The *libxenlight Domain Image Format* specification[3] already defines a
>> -record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
>> -transferring xenstore data pertaining to the domain directly as it is
>> -specified such that keys are relative to the path
>> -`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
>> -define at least one new save record type.
>> +save records are required in the migrations stream to allow a guest 
>> running PV
>> +drivers to be migrated without its co-operation. Moreover the save 
>> records must
>> +include details of registered xenstore watches as well ascontent; 
>> information
> 
> s/ascontent/as content/
> 
> [...]
> 
>> +### END
>> +
>> +The end record marks the end of the image, and is the final record
>> +in the stream.
>>   ```
>> -    0       1       2       3     octet
>> -+-------+-------+-------+-------+
>> -| NODE_DATA                     |
>> -+-------------------------------+
>> -| path length                   |
>> -+-------------------------------+
>> -| path data                     |
>> -...
>> -| pad (0 to 3 octets)           |
>> -+-------------------------------+
>> -| perm count (N)                |
>> -+-------------------------------+
>> -| perm0                         |
>> -+-------------------------------+
>> -...
>> -+-------------------------------+
>> -| permN                         |
>> -+-------------------------------+
>> -| value length                  |
>> -+-------------------------------+
>> -| value data                    |
>> -...
>> -| pad (0 to 3 octets)           |
>> -+-------------------------------+
>> +    0       1       2       3       4       5       6       7    octet
>> ++-------+-------+-------+-------+-------+-------+-------+-------+
>>   ```
>> -where perm0..N are formatted as follows:
>> +The end record contains no fields; its body length is 0.
>> +
>> +\pagebreak
>> +
>> +### GLOBAL_DATA
>> +
>> +This record is only relevant for live update. It contains details of 
>> global
>> +xenstored state that needs to be restored.
> 
> Reading this paragraph, it sounds like GLOBAL_DATA should always be 
> present in the liveupdate stream. However ...
> 
> [...]
> 
>> -path length and value length are specified in octets (excluding the NUL
>> -terminator of the path). perm should be one of the ASCII values `w`, 
>> `r`,
>> -`b` or `n` as described in [2]. All pad values should be 0.
>> -All paths should be absolute (i.e. start with `/`) and as described in
>> -[2].
>> +| Field          | Description                                  |
>> +|----------------|----------------------------------------------|
>> +| `rw-socket-fd` | The file descriptor of the socket accepting  |
>> +|                | read-write connections                       |
>> +|                |                                              |
>> +| `ro-socket-fd` | The file descriptor of the socket accepting  |
>> +|                | read-only connections                        |
>> +xenstored will resume in the original process context. Hence 
>> `rw-socket-fd` and
>> +`ro-socket-fd` simply specify the file descriptors of the sockets.
> 
> ... sockets may not always be available in XenStored. So should we 
> reserve a value for "not in-use socket"?

Yes, this should be -1 (implying that both fields should be signed
types).

> 
> [...]
> 
>> -wpath length and token length are specified in octets (excluding the NUL
>> -terminator). The wpath should be as described for the `WATCH` 
>> operation in
>> -[2]. The token is an arbitrary string of octets not containing any NUL
>> -values.
>> +| Field       | Description                                     |
>> +|-------------|-------------------------------------------------|
>> +| `conn-id`   | A non-zero number used to identify this         |
>> +|             | connection in subsequent connection-specific    |
>> +|             | records                                         |
>> +|             |                                                 |
>> +| `conn-type` | 0x0000: shared ring                             |
>> +|             | 0x0001: socket                                  |
> 
> I would write "0x0002 - 0xFFFF: reserved for future use" to match the 
> rest of the specification.
> 
> [...]
> 
>> -where tx_id is the non-zero identifier values of an open transaction.
>> +| Field     | Description                                       |
>> +|-----------|---------------------------------------------------|
>> +| `domid`   | The domain-id that owns the shared page           |
>> +|           |                                                   |
>> +| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
>> +|           | it has been subject to an SET_TARGET              |
>> +|           | operation [2] or DOMID_INVALID [3] otherwise      |
>> +|           |                                                   |
>> +| `flags`   | Must be zero                                      |
>> +|           |                                                   |
>> +| `evtchn`  | The port number of the interdomain channel used   |
>> +|           | by `domid` to communicate with xenstored          |
>> +|           |                                                   |
>> +| `mfn`     | The MFN of the shared page for a live update or   |
>> +|           | ~0 (i.e. all bits set) otherwise                  |
>> -### Protocol Extension
>> +Since the ABI guarantees that entry 1 in `domid`'s grant table will 
>> always
>> +contain the GFN of the shared page, so for a live update `mfn` can be 
>> used to
>> +give confidence that `domid` has not been re-cycled during the update.
> 
> I am confused, there is no way a XenStored running in an Arm domain can 
> map the MFN of the shared page. So how is this going to work out?

I guess this will be a MFN for PV guests and a guest PFN else.

> 
> [...]
> 
>> -START_DOMAIN_TRANSACTION    <domid>|<transid>|
>> +    0       1       2       3    octet
>> ++-------+-------+-------+-------+
>> +| conn-id                       |
>> ++-------------------------------+
>> +| tx-id                         |
>> ++---------------+---------------+
>> +| path-len      | value-len     |
>> ++---------------+---------------+
>> +| access        | perm-count    |
>> ++---------------+---------------+
>> +| perm1                         |
>> ++-------------------------------+
>> +...
>> ++-------------------------------+
>> +| permN                         |
>> ++---------------+---------------+
>> +| path
>> +...
>> +| value
>> +...
>> +```
>> +
>> +
>> +| Field        | Description                                    |
>> +|--------------|------------------------------------------------|
>> +| `conn-id`    | If this value is non-zero then this record     |
>> +|              | related to a pending transaction               |
> 
> If conn-id is 0, how do you know the owner of the node?

The first permission entry's domid is the owner.

> 
>> +|              |                                                |
>> +| `tx-id`      | This value should be ignored if `conn-id` is   |
>> +|              | zero. Otherwise it specifies the id of the     |
>> +|              | pending transaction                            |
>> +|              |                                                |
>> +| `path-len`   | The length (in octets) of `path` including the |
>> +|              | NUL terminator                                 |
>> +|              |                                                |
>> +| `value-len`  | The length (in octets) of `value` (which will  |
>> +|              | be zero for a deleted node)                    |
>> +|              |                                                |
>> +| `access`     | This value should be ignored if this record    |
>> +|              | does not relate to a pending transaction,      |
>> +|              | otherwise it specifies the accesses made to    |
>> +|              | the node and hence is a bitwise OR of:         |
>> +|              |                                                |
>> +|              | 0x0001: read                                   |
>> +|              | 0x0002: written                                |
>> +|              |                                                |
>> +|              | The value will be zero for a deleted node      |
>> +|              |                                                |
>> +| `perm-count` | The number (N) of node permission specifiers   |
>> +|              | (which will be 0 for a node deleted in a       |
>> +|              | pending transaction)                           |
>> +|              |                                                |
>> +| `perm1..N`   | A list of zero or more node permission         |
>> +|              | specifiers (see below)                         |
> 
> This is a bit odd to start at one. Does it mean perm0 exists and not 
> preserved?

Why? perm0 does not exist. If you have N permissions 1..N is just fine.
If you have no permissions (N=0) you won't have any permX entry.

In theory you could say perm0..N-1, but this would result in perm0..-1
for N=0 which would be really odd.


Juergen


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 10:19:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 10:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTNL8-0005xZ-Qt; Tue, 28 Apr 2020 10:19:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=DYx7=6M=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTNL7-0005xU-75
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 10:19:45 +0000
X-Inumbo-ID: c7411d62-8939-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c7411d62-8939-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 10:19:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E60A4AED6;
 Tue, 28 Apr 2020 10:19:41 +0000 (UTC)
Subject: Re: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
To: Peng Fan <peng.fan@nxp.com>,
 "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
 "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>
References: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
 <1c01e97a-adcd-a703-55b5-8975b4ce4d2c@suse.com>
 <DB6PR0402MB2760A05135338B0CBB28123488AC0@DB6PR0402MB2760.eurprd04.prod.outlook.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <dba804ea-4268-24ff-7447-ddef00e9e20c@suse.com>
Date: Tue, 28 Apr 2020 12:19:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <DB6PR0402MB2760A05135338B0CBB28123488AC0@DB6PR0402MB2760.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 dl-linux-imx <linux-imx@nxp.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.20 10:25, Peng Fan wrote:
>> Subject: Re: [PATCH] xen/swiotlb: correct the check for
>> xen_destroy_contiguous_region
>>
>> On 28.04.20 09:33, peng.fan@nxp.com wrote:
>>> From: Peng Fan <peng.fan@nxp.com>
>>>
>>> When booting xen on i.MX8QM, met:
>>> "
>>> [    3.602128] Unable to handle kernel paging request at virtual address
>> 0000000000272d40
>>> [    3.610804] Mem abort info:
>>> [    3.613905]   ESR = 0x96000004
>>> [    3.617332]   EC = 0x25: DABT (current EL), IL = 32 bits
>>> [    3.623211]   SET = 0, FnV = 0
>>> [    3.626628]   EA = 0, S1PTW = 0
>>> [    3.630128] Data abort info:
>>> [    3.633362]   ISV = 0, ISS = 0x00000004
>>> [    3.637630]   CM = 0, WnR = 0
>>> [    3.640955] [0000000000272d40] user address but active_mm is
>> swapper
>>> [    3.647983] Internal error: Oops: 96000004 [#1] PREEMPT SMP
>>> [    3.654137] Modules linked in:
>>> [    3.677285] Hardware name: Freescale i.MX8QM MEK (DT)
>>> [    3.677302] Workqueue: events deferred_probe_work_func
>>> [    3.684253] imx6q-pcie 5f000000.pcie: PCI host bridge to bus 0000:00
>>> [    3.688297] pstate: 60000005 (nZCv daif -PAN -UAO)
>>> [    3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0
>>> [    3.693993] pci_bus 0000:00: root bus resource [bus 00-ff]
>>> [    3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0
>>> "
>>>
>>> In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask)
>>> or range_straddles_page_boundary(phys, size) are true, it will create
>>> contiguous region. So when free, we need to free contiguous region use
>>> upper check condition.
>>
>> No, this will break PV guests on x86.
> 
> Could you share more details why alloc and free not matching for the check?

xen_create_contiguous_region() is needed only in case:

- the bus address is not within dma_mask, or
- the memory region is not physically contiguous (can happen only for
   PV guests)

In any case it should arrange for the memory to be suitable for the
DMA operation, so to be contiguous and within dma_mask afterwards. So
xen_destroy_contiguous_region() should only ever called for areas
which match above criteria, as otherwise we can be sure
xen_create_contiguous_region() was not used for making the area DMA-able
in the beginning.

And this is very important in the PV case, as in those guests the page
tables are containing the host-PFNs, not the guest-PFNS, and
xen_create_contiguous_region() will fiddle with host- vs. guest-PFN
arrangements, and xen_destroy_contiguous_region() is reverting this
fiddling. Any call of xen_destroy_contiguous_region() for an area it
was not intended to be called for might swap physical pages beneath
random virtual addresses, which was the reason for this test to be
added by me.


Juergen

> 
> Thanks,
> Peng.
> 
>>
>> I think there is something wrong with your setup in combination with the ARM
>> xen_create_contiguous_region() implementation.
>>
>> Stefano?
>>
>>
>> Juergen
>>
>>>
>>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>> ---
>>>    drivers/xen/swiotlb-xen.c | 4 ++--
>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>>> index b6d27762c6f8..ab96e468584f 100644
>>> --- a/drivers/xen/swiotlb-xen.c
>>> +++ b/drivers/xen/swiotlb-xen.c
>>> @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev,
>> size_t size, void *vaddr,
>>>    	/* Convert the size to actually allocated. */
>>>    	size = 1UL << (order + XEN_PAGE_SHIFT);
>>>
>>> -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
>>> -		     range_straddles_page_boundary(phys, size)) &&
>>> +	if (((dev_addr + size - 1 > dma_mask) ||
>>> +	    range_straddles_page_boundary(phys, size)) &&
>>>    	    TestClearPageXenRemapped(virt_to_page(vaddr)))
>>>    		xen_destroy_contiguous_region(phys, order);
>>>
>>>
> 



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 10:23:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 10:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTNOd-0006pA-C4; Tue, 28 Apr 2020 10:23:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=c5nG=6M=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTNOc-0006p5-CC
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 10:23:22 +0000
X-Inumbo-ID: 48d53462-893a-11ea-9848-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 48d53462-893a-11ea-9848-12813bfff9fa;
 Tue, 28 Apr 2020 10:23:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=WdL+tRd89XoXFlZNEtfi3nhZsBi/cccWkhKZhUzmap4=; b=TtT4g4Tm7N8qC8Ecl8715+TUne
 jZnduYwhZ2c/L9gpeINZngTeIhuxjtdRAvg+KVh4vjguJc1QSu2Y2FYcgnEHWH3lmFhU6co3cp3sz
 VCxDkEHsZn5C0nq+reR6WCdWjVhGZoYR16V0PoRqKQ0ex4CClsRuja4Ut8/ONsZw2heY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTNOY-0000SX-W2; Tue, 28 Apr 2020 10:23:18 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTNOY-0006Om-HW; Tue, 28 Apr 2020 10:23:18 +0000
Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration
 document...
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org
References: <20200427155035.668-1-paul@xen.org>
 <7ab25832-66e6-020f-b343-059f21771054@xen.org>
 <f13de8bc-ca5d-2341-3797-b34f9f2c70ef@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <2087b3dd-7d2c-3ab3-d6ce-a4d132f7ec4d@xen.org>
Date: Tue, 28 Apr 2020 11:23:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <f13de8bc-ca5d-2341-3797-b34f9f2c70ef@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Juergen,

On 28/04/2020 11:10, Jürgen Groß wrote:
> On 28.04.20 11:05, Julien Grall wrote:
>>> -where tx_id is the non-zero identifier values of an open transaction.
>>> +| Field     | Description                                       |
>>> +|-----------|---------------------------------------------------|
>>> +| `domid`   | The domain-id that owns the shared page           |
>>> +|           |                                                   |
>>> +| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
>>> +|           | it has been subject to an SET_TARGET              |
>>> +|           | operation [2] or DOMID_INVALID [3] otherwise      |
>>> +|           |                                                   |
>>> +| `flags`   | Must be zero                                      |
>>> +|           |                                                   |
>>> +| `evtchn`  | The port number of the interdomain channel used   |
>>> +|           | by `domid` to communicate with xenstored          |
>>> +|           |                                                   |
>>> +| `mfn`     | The MFN of the shared page for a live update or   |
>>> +|           | ~0 (i.e. all bits set) otherwise                  |
>>> -### Protocol Extension
>>> +Since the ABI guarantees that entry 1 in `domid`'s grant table will 
>>> always
>>> +contain the GFN of the shared page, so for a live update `mfn` can 
>>> be used to
>>> +give confidence that `domid` has not been re-cycled during the update.
>>
>> I am confused, there is no way a XenStored running in an Arm domain 
>> can map the MFN of the shared page. So how is this going to work out?
> 
> I guess this will be a MFN for PV guests and a guest PFN else.

If we use Xen terminology (xen/include/xen/mm.h), this would be a GFN.

> 
>>
>> [...]
>>
>>> -START_DOMAIN_TRANSACTION    <domid>|<transid>|
>>> +    0       1       2       3    octet
>>> ++-------+-------+-------+-------+
>>> +| conn-id                       |
>>> ++-------------------------------+
>>> +| tx-id                         |
>>> ++---------------+---------------+
>>> +| path-len      | value-len     |
>>> ++---------------+---------------+
>>> +| access        | perm-count    |
>>> ++---------------+---------------+
>>> +| perm1                         |
>>> ++-------------------------------+
>>> +...
>>> ++-------------------------------+
>>> +| permN                         |
>>> ++---------------+---------------+
>>> +| path
>>> +...
>>> +| value
>>> +...
>>> +```
>>> +
>>> +
>>> +| Field        | Description                                    |
>>> +|--------------|------------------------------------------------|
>>> +| `conn-id`    | If this value is non-zero then this record     |
>>> +|              | related to a pending transaction               |
>>
>> If conn-id is 0, how do you know the owner of the node?
> 
> The first permission entry's domid is the owner.

I think this should be spell out in the specification.

> 
>>
>>> +|              |                                                |
>>> +| `tx-id`      | This value should be ignored if `conn-id` is   |
>>> +|              | zero. Otherwise it specifies the id of the     |
>>> +|              | pending transaction                            |
>>> +|              |                                                |
>>> +| `path-len`   | The length (in octets) of `path` including the |
>>> +|              | NUL terminator                                 |
>>> +|              |                                                |
>>> +| `value-len`  | The length (in octets) of `value` (which will  |
>>> +|              | be zero for a deleted node)                    |
>>> +|              |                                                |
>>> +| `access`     | This value should be ignored if this record    |
>>> +|              | does not relate to a pending transaction,      |
>>> +|              | otherwise it specifies the accesses made to    |
>>> +|              | the node and hence is a bitwise OR of:         |
>>> +|              |                                                |
>>> +|              | 0x0001: read                                   |
>>> +|              | 0x0002: written                                |
>>> +|              |                                                |
>>> +|              | The value will be zero for a deleted node      |
>>> +|              |                                                |
>>> +| `perm-count` | The number (N) of node permission specifiers   |
>>> +|              | (which will be 0 for a node deleted in a       |
>>> +|              | pending transaction)                           |
>>> +|              |                                                |
>>> +| `perm1..N`   | A list of zero or more node permission         |
>>> +|              | specifiers (see below)                         |
>>
>> This is a bit odd to start at one. Does it mean perm0 exists and not 
>> preserved?
> 
> Why? perm0 does not exist. If you have N permissions 1..N is just fine.
> If you have no permissions (N=0) you won't have any permX entry.
> 
> In theory you could say perm0..N-1, but this would result in perm0..-1
> for N=0 which would be really odd.

As it is odd to me to start at 1 (I am used to index starting at 0) ;). 
The more it wasn't clear how you would specify the owner. So I thought 
perm0 had a specific meaning.

If you clarify perm1 is the owner, then it may make easier to figure out 
that perm0 doesn't exist.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 10:39:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 10:39:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTNeV-0007tC-QW; Tue, 28 Apr 2020 10:39:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bVBP=6M=puzio.waw.pl=artur@srs-us1.protection.inumbo.net>)
 id 1jTMjF-0002M8-8j
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 09:40:38 +0000
X-Inumbo-ID: 4eea4bcc-8934-11ea-ae69-bc764e2007e4
Received: from puzio.waw.pl (unknown [2001:41d0:401:3100::3f29])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4eea4bcc-8934-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 09:40:34 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by puzio.waw.pl (Postfix) with ESMTP id E4B4F1C492;
 Tue, 28 Apr 2020 11:40:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puzio.waw.pl;
 s=default; t=1588066846;
 bh=JkOniP87jULWq0LQ3Z7u0q7SiZfMusLTsWD8rZJuaqs=;
 h=Subject:To:Cc:References:From:Date:In-Reply-To;
 b=vSNw6kM11+eO/ZFLrZw/9SUpJepaNyK2VBwUFEBG5g5Pm7I+TZPVYuyfyGRW7pWpi
 CkIv0StlHxScBGYAJbx2FQq4o9jGRGVPciTiU6pw+u/vrnAzegj2y4rnmSwQr0ri8w
 W0Pgi3HWdn6c48E/q093H8spQ3hjf/weanLIUubkKj6FcOfmdcohRHO6FFNjA+DgQG
 oSWhjVvP2JQsWjBG20Ftba4JOHTiP8IGeHmMjyjFXxN9JptIrXO3wi87xCsjM1J0dP
 4UL1aJcJyWrxPeIbR5hb3ld2ph9rMDX+22yv7/nFAeKsyuNWqlV/jrO8kWx5LE1WM1
 6Fz6iuHRwCxmA==
X-Fuglu-Suspect: b4cc723c9a65426cad6da44d8fdc13c1
X-Fuglu-Spamstatus: NO
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on vps345931.ovh.net
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED
 autolearn=ham autolearn_force=no
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: artur@puzio.waw.pl)
 by puzio.waw.pl (Postfix) with ESMTPSA;
 Tue, 28 Apr 2020 11:40:41 +0200 (CEST)
Subject: Re: [PATCH 1/2] Fix undefined behaviour
To: paul@xen.org, 'Grzegorz Uriasz' <gorbak25@gmail.com>, qemu-devel@nongnu.org
References: <20200428062847.7764-1-gorbak25@gmail.com>
 <20200428062847.7764-2-gorbak25@gmail.com>
 <000001d61d34$6c0218f0$44064ad0$@xen.org>
From: Artur Puzio <artur@puzio.waw.pl>
Message-ID: <90a8b709-c506-92e2-800c-e1558f18df94@puzio.waw.pl>
Date: Tue, 28 Apr 2020 11:40:46 +0200
MIME-Version: 1.0
In-Reply-To: <000001d61d34$6c0218f0$44064ad0$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US-large
X-Mailman-Approved-At: Tue, 28 Apr 2020 10:39:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, 'Anthony Perard' <anthony.perard@citrix.com>,
 j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.2020 10:10, Paul Durrant wrote:
>> -----Original Message-----
>> From: Grzegorz Uriasz <gorbak25@gmail.com>
>> Sent: 28 April 2020 07:29
>> To: qemu-devel@nongnu.org
>> Cc: Grzegorz Uriasz <gorbak25@gmail.com>; marmarek@invisiblethingslab.com; artur@puzio.waw.pl;
>> jakub@bartmin.ski; j.nowak26@student.uw.edu.pl; Stefano Stabellini <sstabellini@kernel.org>; Anthony
>> Perard <anthony.perard@citrix.com>; Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
>> Subject: [PATCH 1/2] Fix undefined behaviour
>>
>> Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>
> I think we need more of a commit comment for both this and patch #2 to explain why you are making the changes.
>
>   Paul 

I agree Grzegorz should improve the commit messages. In the mean time
see email with subject "[PATCH 0/2] Fix QEMU crashes when passing IGD to
a guest VM under XEN", it contains quite detailed explanation for both
"Fix undefined behaviour" and "Improve legacy vbios handling" patches.

Artur Puzio



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 10:48:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 10:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTNmz-0000Pb-Mn; Tue, 28 Apr 2020 10:48:33 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qrdk=6M=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTNmz-0000PW-0d
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 10:48:33 +0000
X-Inumbo-ID: cba91e0a-893d-11ea-984b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cba91e0a-893d-11ea-984b-12813bfff9fa;
 Tue, 28 Apr 2020 10:48:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=zYjn1I6QAf2AsaH9/7ZvseG3BIQ9iEpXWNAEaji35UM=; b=r8x9CrlJHUyQJ6QIdxUtH3GC8
 gjD3A950WiyDZLPTc2QxEum9MQ3oqOavyQaxAOB/L0jLu4uGNMZW9ZjlnS0cif0tbfufdkc1RodaI
 8GrCifOJp3E37mHaGX20ZkM8oHHZaxV1edJMEfWQeruTrgtyp7j6U05PRn9HeEbgUAdNY=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTNmu-0000xE-Qb; Tue, 28 Apr 2020 10:48:28 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTNmu-0007H4-J9; Tue, 28 Apr 2020 10:48:28 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTNmu-0007Pj-I7; Tue, 28 Apr 2020 10:48:28 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149840-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149840: regressions - FAIL
X-Osstest-Failures: linux-linus:test-arm64-arm64-examine:reboot:fail:regression
 linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:regression
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=51184ae37e0518fd90cb437a2fbc953ae558cd0d
X-Osstest-Versions-That: linux=6a8b55ed4056ea5559ebe4f6a4b247f627870d4c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 28 Apr 2020 10:48:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149840 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149840/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-examine      8 reboot                   fail REGR. vs. 149832
 test-amd64-amd64-examine      4 memdisk-try-append       fail REGR. vs. 149832

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds    16 guest-start/debian.repeat fail REGR. vs. 149832

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149832
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149832
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149832
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149832
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149832
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149832
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149832
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149832
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149832
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                51184ae37e0518fd90cb437a2fbc953ae558cd0d
baseline version:
 linux                6a8b55ed4056ea5559ebe4f6a4b247f627870d4c

Last test of basis   149832  2020-04-27 03:24:02 Z    1 days
Testing same since   149840  2020-04-27 21:08:47 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  David Sterba <dsterba@suse.com>
  Dexuan Cui <decui@microsoft.com>
  Filipe Manana <fdmanana@suse.com>
  Josef Bacik <josef@toxicpanda.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Michael Kelley <mikelley@microsoft.com>
  Nishad Kamdar <nishadkamdar@gmail.com>
  Wei Liu <wei.liu@kernel.org>
  Xin Tan <tanxin.ctf@gmail.com>
  Xiyu Yang <xiyuyang19@fudan.edu.cn>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     fail    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 328 lines long.)


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 10:58:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 10:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTNwT-0001OY-O9; Tue, 28 Apr 2020 10:58:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qrdk=6M=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTNwS-0001OT-BW
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 10:58:20 +0000
X-Inumbo-ID: 2b06124e-893f-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2b06124e-893f-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 10:58:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=hrmXqixgihfphD82VVfg7faTfB9wG26uz/a1DuuJfbI=; b=yfoaz5h632Pe+OBd5tpqp2nzh
 5bwgqCPRflxRzFVoqHSZScG1vkoFvlX1LppBzqwxMqg6yP3EejyBWnovuldgjyLoWaGUls/LquP64
 nZBwWvc0LMNUB0WI/Y0UAyOVZZo5LjepcPEeqxfMV2/0cbAREhRhTtHShaE7d8XlDbxSc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTNwQ-00019S-Dy; Tue, 28 Apr 2020 10:58:18 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTNwQ-0007gH-12; Tue, 28 Apr 2020 10:58:18 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTNwQ-0006Dx-0N; Tue, 28 Apr 2020 10:58:18 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149850-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149850: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=c1165f70c2a51efc389801d25e06c44099fb7c83
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 28 Apr 2020 10:58:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149850 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149850/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
 build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-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-amd64-libvirt-pair  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-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-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              c1165f70c2a51efc389801d25e06c44099fb7c83
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z  102 days
Failing since        146211  2020-01-18 04:18:52 Z  101 days   94 attempts
Testing same since   149850  2020-04-28 04:25:46 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Chen Hanxiao <chen_han_xiao@126.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mark Asselstine <mark.asselstine@windriver.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Philipp Hahn <hahn@univention.de>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 16703 lines long.)


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:17:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:17:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOEN-0003EG-CA; Tue, 28 Apr 2020 11:16:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=v0V7=6M=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jTOEL-0003EB-R3
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:16:49 +0000
X-Inumbo-ID: c03122bc-8941-11ea-984c-12813bfff9fa
Received: from mail-wr1-f65.google.com (unknown [209.85.221.65])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c03122bc-8941-11ea-984c-12813bfff9fa;
 Tue, 28 Apr 2020 11:16:48 +0000 (UTC)
Received: by mail-wr1-f65.google.com with SMTP id k13so24203800wrw.7;
 Tue, 28 Apr 2020 04:16:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-disposition:in-reply-to:user-agent;
 bh=3axJ3aVDA0BwPqLJzXtdYrDrS24VN47nr3PXqYGqeqY=;
 b=UOOzMuZqy3GCOAJgFgiTclT8d+tULYqM9tK0xeZgzyvCbxkDMP+RQWlBAh/QXG8BG1
 40vBkG3bekB38+K0wBqqbcsfQSQE2WhZGsWR/xHa+cD774QDMp3guuK0XXI7YYAK1p5B
 KWAtufMVmIZlTjrxpKDj5E2XPqxZW83RDFMPU5hXnHXqgdAORtDJqDoQuTMZ7eNJsAxq
 +BsVqRyQFznT9N95ObyWZmcNuWrws0kr0ZVSydQZubd+4hJzFgG6dSH5C1M6FIvSty7P
 vXSqGDx4sfgXuAPTuy6IoDQ+nN3TxJh+6i40AwDa487U+Xy0a7h4D5HP6cohwAwfGGwc
 9iFA==
X-Gm-Message-State: AGi0PuYsGCHz9tH7HA2V4Huv78rn7nb0DLu8Xxqru1MJN4lRIFEw/Vf+
 quVrBxZmH0KivdDBqY+s9Sw=
X-Google-Smtp-Source: APiQypJ0jQhlL0xNOmLCng7VZBTA6DCBnlDn7QwYj0GOyf2dHr3Q6qBy399GNpj9a4s8d6eboDeYCA==
X-Received: by 2002:a5d:6b89:: with SMTP id n9mr32802147wrx.356.1588072607486; 
 Tue, 28 Apr 2020 04:16:47 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id e13sm15605383wrp.15.2020.04.28.04.16.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Apr 2020 04:16:46 -0700 (PDT)
Date: Tue, 28 Apr 2020 11:16:45 +0000
From: Wei Liu <wl@xen.org>
To: Jason Andryuk <jandryuk@gmail.com>
Subject: Re: [PATCH] mini-os: Avoid segfaults in tc{g,s}etattr
Message-ID: <20200428111645.pa6xfs6t6rifu6fu@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <20200427034019.6251-1-jandryuk@gmail.com>
 <20200427075429.mshevnm2ype7tq32@function>
 <CAKf6xpuh3v0H-22=7y83ioYsm2GnKOs+FO8nN2s3djXanUL9BQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKf6xpuh3v0H-22=7y83ioYsm2GnKOs+FO8nN2s3djXanUL9BQ@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 minios-devel@lists.xenproject.org, Jan Beulich <JBeulich@suse.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 09:30:50AM -0400, Jason Andryuk wrote:
> On Mon, Apr 27, 2020 at 3:54 AM Samuel Thibault
> <samuel.thibault@ens-lyon.org> wrote:
> >
> > Jason Andryuk, le dim. 26 avril 2020 23:40:19 -0400, a ecrit:
> > > Commit c96c22f1d94 "mini-os: minimal implementations of some termios
> > > functions" introduced implementations of tcgetattr and tcsetattr.
> > > However, they do not check if files[fildes].cons.dev is non-NULL before
> > > dereferencing.  This is not a problem for FDs allocated through
> > > alloc_fd, but the files array pre-allocates FDs 0-2 for stdio.  Those
> > > entries have a NULL .dev, so tc{g,s}etattr on them segfault.
> > >
> > > ioemu-stubdom segfaults when term_init() calls tcgetattr on FD 0.
> > >
> > > Restore tcgetattr and tcsetattr behavior when .dev is NULL equivalent to
> > > unsupported_function as it was before c96c22f1d94.
> > >
> > > Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
> >
> > Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> >
> > Thanks!
> 
> Thank you!
> 
> > > ---
> > > I can't get ioemu-stubdom to start without this.  With this, the guest
> > > just reboots immediately, but it does that with a non-stubdom
> > > device_model_version="qemu-xen-traditional" .  The same guest disk image
> > > (cirros 0.5.1) boots with a linux stubdom or non-stubdom Ubuntu
> > > qemu-system-x86_64.
> 
> Ubuntu gcc-9 adds -fcf-protection by default.  Somehow that flag
> caused rombios (I think) to restart.  Setting -fcf-protection=none
> like below (probably just the EMBEDDED_EXTRA_CFLAGS part) lets rombios
> start properly.  The hypervisor needs it as well via
> EXTRA_CFLAGS_XEN_CORE=-fcf-protection=none and maybe also added to
> xen/arch/x86/boot/build32.mk .

Are you able to turn this into a proper patch? I suspect you will need
to test the availability of this new (?) flag.

Also Cc Jan and Andrew because it affects hypervisor build too.

> 
> diff --git a/Config.mk b/Config.mk
> index 0f303c79b2..efb3d42bc4 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -205,6 +205,7 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
> 
>  EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
>  EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
> +EMBEDDED_EXTRA_CFLAGS += -fcf-protection=none
> 
>  XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
>  # All the files at that location were downloaded from elsewhere on
> diff --git a/tools/firmware/Rules.mk b/tools/firmware/Rules.mk
> index 26bbddccd4..0d33514d53 100644
> --- a/tools/firmware/Rules.mk
> +++ b/tools/firmware/Rules.mk
> @@ -17,3 +17,4 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
> 
>  # Extra CFLAGS suitable for an embedded type of environment.
>  CFLAGS += -fno-builtin -msoft-float
> +CFLAGS += -fcf-protection=none
> 


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:18:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOGM-0003Nm-RU; Tue, 28 Apr 2020 11:18:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=v0V7=6M=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jTOGM-0003Ng-H3
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:18:54 +0000
X-Inumbo-ID: 07e3a24c-8942-11ea-984c-12813bfff9fa
Received: from mail-wm1-f66.google.com (unknown [209.85.128.66])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 07e3a24c-8942-11ea-984c-12813bfff9fa;
 Tue, 28 Apr 2020 11:18:48 +0000 (UTC)
Received: by mail-wm1-f66.google.com with SMTP id z6so2424013wml.2;
 Tue, 28 Apr 2020 04:18:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-disposition:in-reply-to:user-agent;
 bh=fBwuZ4QzlGUHOQQ5r8cLpSzseKT/A8Yt+G/+bSzTF6E=;
 b=A3WnMMln2VBVGixAR+4iur7IvC8YjxLYf137vjfswSDJGlWsH3AEfVi4PY5BOwWkl7
 RAdEe31q6+HfvMSkggEgcVbZFUsCMHdLXqYV6y0y8Gt08h/Gt+4PfuSlYUxM0l+lrCC2
 Yr7QEhG979QhUPNkJpUq/TIpfddNzl7SZIHRNJEzD1V0sn4J6xODfZarqZ5wU1JQF5SC
 MUG27PlAU8Tc2OLq1df6GIrvuYUBJJiQIj2SjG1QkRJU9FWnRR8kQVnYt2QEoo52Mxig
 fknPZNyX6OYH4r8nUYXt5RyiyFC8bSGE0hgT7z1HUCfFLD7EO/OLO14AksXpnkOdV8Nb
 vmPQ==
X-Gm-Message-State: AGi0PubuidhADGo3cf+DkAoE/3kcw/IuE4xqyU+j3f7umNedZDJMwgdp
 Lq72mdV3Bc3Yw85vE+oZ8RY=
X-Google-Smtp-Source: APiQypJWZwjuZkDC+XnOTrbzKQjlLQTeFTcMngmgsCo5IN4ctQ64OfCibTgjZom76XIVJ865Q5GXbw==
X-Received: by 2002:a1c:7c18:: with SMTP id x24mr3788296wmc.146.1588072727849; 
 Tue, 28 Apr 2020 04:18:47 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id s14sm3010581wme.33.2020.04.28.04.18.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Apr 2020 04:18:47 -0700 (PDT)
Date: Tue, 28 Apr 2020 11:18:45 +0000
From: Wei Liu <wl@xen.org>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Jason Andryuk <jandryuk@gmail.com>,
 minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] mini-os: Avoid segfaults in tc{g,s}etattr
Message-ID: <20200428111845.ee7373zz7pn3bdc5@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <20200427034019.6251-1-jandryuk@gmail.com>
 <20200427075429.mshevnm2ype7tq32@function>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200427075429.mshevnm2ype7tq32@function>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Mon, Apr 27, 2020 at 09:54:29AM +0200, Samuel Thibault wrote:
> Jason Andryuk, le dim. 26 avril 2020 23:40:19 -0400, a ecrit:
> > Commit c96c22f1d94 "mini-os: minimal implementations of some termios
> > functions" introduced implementations of tcgetattr and tcsetattr.
> > However, they do not check if files[fildes].cons.dev is non-NULL before
> > dereferencing.  This is not a problem for FDs allocated through
> > alloc_fd, but the files array pre-allocates FDs 0-2 for stdio.  Those
> > entries have a NULL .dev, so tc{g,s}etattr on them segfault.
> > 
> > ioemu-stubdom segfaults when term_init() calls tcgetattr on FD 0.
> > 
> > Restore tcgetattr and tcsetattr behavior when .dev is NULL equivalent to
> > unsupported_function as it was before c96c22f1d94.
> > 
> > Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
> 
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> 
> Thanks!

Applied. Thanks.


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:23:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOL5-0004IL-Fd; Tue, 28 Apr 2020 11:23:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=lSul=6M=citrix.com=george.dunlap@srs-us1.protection.inumbo.net>)
 id 1jTOL4-0004IG-J5
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:23:46 +0000
X-Inumbo-ID: b8ceacbe-8942-11ea-984c-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b8ceacbe-8942-11ea-984c-12813bfff9fa;
 Tue, 28 Apr 2020 11:23:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588073026;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=W4eRcM/1fGYE1Bqj6113bhJpdc2nDV1DGVYvSE2t48E=;
 b=NZ4ZfZt4LPfv8Rof5mUXjdHlDB2T+YRGLhhJL7nh937i5u0q3yOCgcp3
 oHmqTbGpIo/WuTIBy2VVrvRCEYU44uUj1sCzEoKd/TZyDXujMtzGPvKdm
 XnllczikO3fp0a0J/1Vydpr4bDrdmkgldR559xhp3NC+qCVDmZ0V+KY9u s=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=George.Dunlap@citrix.com;
 spf=Pass smtp.mailfrom=George.Dunlap@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 George.Dunlap@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 George.Dunlap@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="George.Dunlap@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="George.Dunlap@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: DSIFuDARWv1h9gWzyu0uGbVxM7j1UZvTqpZcgAJAiIcYRpw5qfJI9AyZxHNpsRxlFd4fRtjowP
 fvItZcq1nChkeFWWSkCQSnRTONeE0p1dVAj2lG7Kq3gfQ+3lMIKPdRWxrPp1V+aiPBSHM/NiFg
 eTI2FIciualDnrTT53qvPqWrkgdfWvYQfIzGPsjUalrMOnybi/sJnNxnW4c1bAnzOs+M196M7R
 N1lCk4mfNG6t16JoGIMtjYJETtdEQG/0jQ2LG2uu+OtU7u3EOoL4oCTqWIRIstZuCGR1ARA2ml
 /bA=
X-SBRS: 2.7
X-MesageID: 16345346
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,327,1583211600"; d="scan'208";a="16345346"
From: George Dunlap <George.Dunlap@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
Thread-Topic: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
Thread-Index: AQHWCQXiBGUb+wr760WOfoEenUG4zahnVWoAgAALjICAAAX/gIAAAzMAgASARQCAITZdgIAADK2AgAD5+wCAABHcgIAABB0AgAAt8QA=
Date: Tue, 28 Apr 2020 11:23:41 +0000
Message-ID: <563C8FE9-E852-43F6-9FCC-EEEA14B60473@citrix.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
 <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
 <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
 <fb0e92cc-102f-7f87-1ad6-f3ccce1eee60@suse.com>
 <064958B4-1FCC-4300-A98A-7A1D608376F8@citrix.com>
 <23606595-8ce0-5151-d800-1dc0d97513d1@suse.com>
In-Reply-To: <23606595-8ce0-5151-d800-1dc0d97513d1@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <0CCE51591D9DBA47992A79C5631485CF@citrix.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew
 Cooper <Andrew.Cooper3@citrix.com>, Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

DQoNCj4gT24gQXByIDI4LCAyMDIwLCBhdCA5OjM5IEFNLCBKYW4gQmV1bGljaCA8amJldWxpY2hA
c3VzZS5jb20+IHdyb3RlOg0KPiANCj4gT24gMjguMDQuMjAyMCAxMDoyNCwgR2VvcmdlIER1bmxh
cCB3cm90ZToNCj4+PiBPbiBBcHIgMjgsIDIwMjAsIGF0IDg6MjAgQU0sIEphbiBCZXVsaWNoIDxq
YmV1bGljaEBzdXNlLmNvbT4gd3JvdGU6DQo+Pj4gT24gMjcuMDQuMjAyMCAxODoyNSwgR2Vvcmdl
IER1bmxhcCB3cm90ZToNCj4+Pj4gSWYgSmFuIGlzIE9LIHdpdGggaXQgc2ltcGx5IGJlaW5nIG91
dHNpZGUgQ09ORklHX0VYUEVSVCwgdGhlbiBncmVhdC4gIEJ1dCBpZiBoZSBpbnNpc3RzIG9uIHNv
bWUga2luZCBvZiB0ZXN0aW5nIGZvciBpdCB0byBiZSBvdXRzaWRlIG9mIENPTkZJR19FWFBFUlQs
IHRoZW4gYWdhaW4sIHRoZSBwZW9wbGUgd2hvIHdhbnQgaXQgdG8gYmUgc2VjdXJpdHkgc3VwcG9y
dGVkIHNob3VsZCBiZSB0aGUgb25lcyB3aG8gZG8gdGhlIHdvcmsgdG8gbWFrZSBpdCBoYXBwZW4u
DQo+Pj4gDQo+Pj4gSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgcGFydCwgSSdtIGFmcmFpZDogV2l0
aG91dCBhIGNvbmZpZyBvcHRpb24sDQo+Pj4gdGhlIGNvZGUgaXMgZ29pbmcgdG8gYmUgc2VjdXJp
dHkgc3VwcG9ydGVkIGFzIGxvbmcgYXMgaXQgZG9lc24ndA0KPj4+IGdldCBtYXJrZWQgb3RoZXJ3
aXNlIChleHBlcmltZW50YWwgb3Igd2hhdCBub3QpLiBXaXRoIGFuIG9wdGlvbg0KPj4+IGRlcGVu
ZGluZyBvbiBFWFBFUlQsIHdoYXQgd291bGQgYmVjb21lIHNlY3VyaXR5IHVuc3VwcG9ydGVkIGlz
IHRoZQ0KPj4+IG5vbi1kZWZhdWx0IChpLmUuIGRpc2FibGVkKSBzZXR0aW5nLiBUaGVyZSdzIG5v
dCBhIHdob2xlIGxvdCB0bw0KPj4+IHRlc3QgdGhlcmUsIGl0J3MgbWVyZWx5IGEgZm9ybWFsIGNv
bnNlcXVlbmNlIG9mIG91ciBnZW5lcmFsIHJ1bGVzLg0KPj4+IChPZiBjb3Vyc2UsIG92ZXIgdGlt
ZSBkZXBlbmRlbmNpZXMgb2Ygb3RoZXIgY29kZSBtYXkgZGV2ZWxvcCBvbg0KPj4+IHRoZSBpbmZv
cm1hdGlvbiBiZWluZyBhdmFpbGFibGUgZS5nLiB0byBEb20wIHVzZXJsYW5kLiBKdXN0IGxpa2UN
Cj4+PiB0aGVyZSdzIExpbnV4IHVzZXJsYW5kIGNvZGUgYXNzdW1pbmcgdGhlIGtlcm5lbCBjb25m
aWcgaXMNCj4+PiBhdmFpbGFibGUgaW4gY2VydGFpbiB3YXlzIFtJIGRvbid0IG5lY2Vzc2FyaWx5
IG1lYW4gdGhlIGVxdWl2YWxlbnQNCj4+PiBvZiBoeXBmcyBoZXJlXSwgdG8gdGhlbiB1c2UgaXQg
aW4gd2hhdCBJJ2QgY2FsbCBhYnVzaXZlIHdheXMgaW4gYXQNCj4+PiBsZWFzdCBzb21lIGNhc2Vz
LikNCj4+IA0KPj4gSGVyZeKAmXMgYW4gYXJndW1lbnQgeW91IG1pZ2h0IG1ha2U6DQo+PiANCj4+
IOKAnEFzIGEgbWVtYmVyIG9mIHRoZSBzZWN1cml0eSB0ZWFtLCBJIGRvbuKAmXQgd2FudCB0byBi
ZSBvbiB0aGUgaG9vayBmb3IgaXNzdWluZyBYU0FzIGZvciBjb2RlIHdoaWNoIGlzbuKAmXQgYXQg
bGVhc3Qgc21va2UtdGVzdGVkLiAgVGhlcmVmb3JlLCBJIG9wcG9zZSBhbnkgcGF0Y2ggYWRkaW5n
IENPTkZJR19IWVBGUyBvdXRzaWRlIG9mIENPTkZJR19FWFBFUlQsICp1bmxlc3MqIHRoZXJlIGlz
IGEgY29uY3JldGUgcGxhbiBmb3IgZ2V0dGluZyByZWd1bGFyIHRlc3RpbmcgZm9yIENPTkZJR19I
WVBGUz1uLuKAnQ0KPj4gDQo+PiBJ4oCZbSBub3Qgc2F5aW5nIHRoYXTigJlzIGFuIGFyZ3VtZW50
IHlvdSAqc2hvdWxkKiBtYWtlLiAgQnV0IHBlcnNvbmFsbHkgSSBkb27igJl0IGhhdmUgYSBzdHJv
bmcgYXJndW1lbnQgYWdhaW5zdCBzdWNoIGFuIGFyZ3VtZW50LiBTbywgaXQgc2VlbXMgdG8gbWUs
IGlmIHlvdSBkaWQgbWFrZSBpdCwgeW91IGhhdmUgYSByZWFzb25hYmxlIGNoYW5jZSBvZiBjYXJy
eWluZyB5b3VyIHBvaW50Lg0KPj4gDQo+PiBOb3cgY29uc2lkZXIgdGhpcyBoeXBvdGhldGljYWwg
dW5pdmVyc2Ugd2hlcmUgeW91IG1hZGUgdGhhdCBhcmd1bWVudCBhbmQgbm9ib2R5IG9wcG9zZWQg
aXQuICBJbiBvcmRlciB0byBnZXQgYSBwYXJ0aWN1bGFyIGZlYXR1cmUgKENPTkZJR19IWVBGUz1u
IHNlY3VyaXR5IHN1cHBvcnRlZCksIHRoZXJlIGlzIGV4dHJhIHdvcmsgdGhhdCBuZWVkcyB0byBi
ZSBkb25lIChnZXR0aW5nIENPTkZJR19IWVBGUz1uIHRlc3RlZCByZWd1bGFybHkpLiAgTXkgcG9p
bnQgd2FzLCB0aGUgZXhwZWN0YXRpb24gc2hvdWxkIGJlIHRoYXQgdGhlIGV4dHJhIHdvcmsgd2ls
bCBiZSBkb25lIGJ5IHRoZSBwZW9wbGUgd2hvIHdhbnQgb3IgYmVuZWZpdCBmcm9tIHRoZSBmZWF0
dXJlOyB0aGUgc2VyaWVzIHNob3VsZG7igJl0IGJlIGJsb2NrZWQgdW50aWwgSnVlcmdlbiBpbXBs
ZW1lbnRzIENPTkZJR19IWVBGUz1uIHRlc3RpbmcgKHNpbmNlIGhlIGRvZXNu4oCZdCBwZXJzb25h
bGx5IGhhdmUgYSBzdGFrZSBpbiB0aGF0IGZlYXR1cmUpLg0KPj4gDQo+PiBOb3cgb2J2aW91c2x5
LCBkb2luZyB3b3JrIHRvIGhlbHAgc29tZW9uZSBlbHNlIG91dCBpbiB0aGUgY29tbXVuaXR5IGlz
IG9mIGNvdXJzZSBhIGdvb2QgdGhpbmcgdG8gZG87IGl0IGJ1aWxkcyBnb29kd2lsbCwgdXNlcyBv
dXIgYWdncmVnYXRlIHJlc291cmNlcyBtb3JlIGVmZmljaWVudGx5LCBhbmQgbWFrZXMgb3VyIGNv
bW11bml0eSBtb3JlIGVuam95YWJsZSB0byB3b3JrIHdpdGguIEJ1dCB0aGUgZ29vZHdpbGwgcHJp
bWFyaWx5IGNvbWVzIGZyb20gdGhlIGZhY3QgdGhhdCBpdCB3YXMgZG9uZSBhcyBhIHZvbHVudGFy
eSBjaG9pY2UsIG5vdCBhcyBhIHJlcXVpcmVtZW50Lg0KPj4gDQo+PiBKdWVyZ2VuIHdhcyBiYWxr
aW5nIGF0IGhhdmluZyB0byBkbyB3aGF0IGhlIHNhdyBhcyBleHRyYSB3b3JrIHRvIGltcGxlbWVu
dCBDT05GSUdfSFlQRlMuICBJIHdhbnRlZCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgZXZlbiB0aG91
Z2ggSSBzZWUgdmFsdWUgaW4gaGF2aW5nIENPTkZJR19IWVBGUywgKmhlKiBkb2VzbuKAmXQgaGF2
ZSB0byBkbyB0aGUgd29yayBpZiBoZSBkb2VzbuKAmXQgd2FudCB0byAoYWx0aG91Z2ggaXQgd291
bGQgY2VydGFpbmx5IGJlIGFwcHJlY2lhdGVkIGlmIGhlIGRpZCkuICBBbmQgdGhpcyBwYXJhZ3Jh
cGggd2FzIGV4dGVuZGluZyB0aGUgc2FtZSBwcmluY2lwbGUgaW50byB0aGUgaHlwb3RoZXRpY2Fs
IHVuaXZlcnNlIHdoZXJlIHNvbWVvbmUgaW5zaXN0ZWQgdGhhdCBDT05GSUdfSFlQRlM9biBoYWQg
dG8gYmUgdGVzdGVkIGJlZm9yZSBiZWluZyBzZWN1cml0eSBzdXBwb3J0ZWQuDQo+PiANCj4+IEhv
cGUgdGhhdCBtYWtlcyBzZW5zZS4gOi0pDQo+IA0KPiBZZXMsIGl0IGRvZXMsIHRoYW5rcyBmb3Ig
dGhlIGNsYXJpZmljYXRpb24uIEkgY2FuIHNlZSB3aGF0IHlvdSBkZXNjcmliZQ0KPiBhcyBhIHZh
bGlkIHBlcnNwZWN0aXZlIHRvIHRha2UsIGJ1dCByZWFsbHkgaW4gbXkgcmVxdWVzdCB0byBKw7xy
Z2VuIEkNCj4gdG9vayBhbm90aGVyOiBOb3cgdGhhdCB3ZSBoYXZlIEtjb25maWcsIGFkZGl0aW9u
cyBvZiBsYXJnZXIgYm9kaWVzIG9mDQo+IGNvZGUgKHBvc3NpYmx5IGFsc28ganVzdCBpbiB0ZXJt
cyBvZiBiaW5hcnkgc2l6ZSkgc2hvdWxkIGltbyBnZW5lcmFsbHkNCj4gYmUgcXVlc3Rpb25lZCB3
aGV0aGVyIHRoZXkgd2FudC9uZWVkIHRvIGJlIGJ1aWx0IGZvciBldmVyeW9uZS4gSS5lLiBpdA0K
PiBpcyBub3QgdG8gYmUgbGVmdCB0byBwZW9wbGUgYmVpbmcgd29ycmllZCBhYm91dCBiaW5hcnkg
c2l6ZXMgdG8gYXJyYW5nZQ0KPiBmb3IgdGhpbmdzIHRvIG5vdCBiZSBidWlsdCwgYnV0IGZvciBw
ZW9wbGUgY29udHJpYnV0aW5nIG5ldyBidXQgbm90DQo+IGVudGlyZWx5IGVzc2VudGlhbCBjb2Rl
IHRvIGNvbnNpZGVyIG1ha2luZyBpdCBvcHRpb24gZnJvbSB0aGUgdmVyeQ0KPiBiZWdpbm5pbmcu
DQoNCkkgdGhpbmsgdGhhdOKAmXMgYSByZWFzb25hYmxlIHBvc2l0aW9uIHRvIHRha2UsIGJ1dCBu
ZWVkcyB0byBiZSBiYWxhbmNlZCBvbiB0aGUgYW1vdW50IG9mIHdvcmsgdGhhdCB0aGlzIHdvdWxk
IGFjdHVhbGx5IHJlcXVpcmUuICBJZiBpdCBvbmx5IHJlcXVpcmVzIGFkZGluZyBhIGhhbmRmdWwg
b2YgI2lmZGVm4oCZcyBhbmQgbWF5YmUgbWFraW5nIGEgZmV3IHN0dWJzLCB0aGVuIHllcywgYXNr
aW5nIHRoZSBzdWJtaXR0ZXIgdG8gbWFrZSB0aGUgY2hhbmdlIG1ha2VzIHNlbnNlLiAgQnV0IGlm
IGl0IHJlcXVpcmVzIHRocmVlIGRvemVuICNpZmRlZuKAmXMgdGhyb3VnaG91dCB0aGUgY29kZSBh
bmQgYSBmYWlybHkgbWFqb3IgYXJjaGl0ZWN0dXJhbCBjaGFuZ2UsIHRoZW4gSSB0aGluayBpdOKA
mXMgcmVhc29uYWJsZSBmb3IgYSBzdWJtaXR0ZXIgdG8gcHVzaCBiYWNrLg0KDQpJIGRvbuKAmXQg
cmVhbGx5IHVuZGVyc3RhbmQgd2h5IEp1ZXJnZW4gdGhpbmtzIGFkZGluZyBDT05GSUdfSFlQRlMg
d291bGQgY2F1c2UgYSBsb3Qgb2YgY29kZSBjaHVybjsgbXkgYXJndW1lbnRhdGlvbiBoZXJlIGlz
IGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgaGlzIGFzc2Vzc21lbnQgaXMgY29ycmVjdC4N
Cg0KIC1HZW9yZ2UNCg0K


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:23:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOLF-0004Ku-Tj; Tue, 28 Apr 2020 11:23:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=v0V7=6M=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jTOLE-0004Kc-JR
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:23:56 +0000
X-Inumbo-ID: bb7bcb86-8942-11ea-984c-12813bfff9fa
Received: from mail-wm1-f67.google.com (unknown [209.85.128.67])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bb7bcb86-8942-11ea-984c-12813bfff9fa;
 Tue, 28 Apr 2020 11:23:49 +0000 (UTC)
Received: by mail-wm1-f67.google.com with SMTP id u16so2415473wmc.5;
 Tue, 28 Apr 2020 04:23:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=CrEIeTB9JLvrBJcFHNug+oMluBW3s7BuIXlpN/mb6aE=;
 b=tw/IHPfSD3J4Y/AwII5qXgvdD5vcAKFLT7GfpBx7XgaQXrNgpkStRDlNAedsAxMWPp
 IRV5+XQzp+LvV+H4iQxVSYIbaDuiam12wF+JGPXWZWPhVSzeQ9Au33Nuyy9WhFtpHKtw
 VhxBViKzVTX0qyEmbTl9Bg7pCGzjtKabTtuibAh/6QEHtjVEG5whQWui010MsPtJs4AY
 OyN678VlvkFSnrrLVGRLt7cw+aef+LYyQ+XlGvyn6+OJIsX2aiAY26d91zj4FwCPtzMO
 DCr2OLj+CehwW/BQUPOUJVO1yeuY5sIJ5I2I+ewcyfq9ZdJb5WnrRtnDrgUsFlk800JM
 WAtQ==
X-Gm-Message-State: AGi0PuYnwXsSicXoMNQVGL2N88po4JY5Pt+xp9STXFDRXYOoO3TWn4/g
 S+2akllt3wm1zaLIUYmEiw07cu5GZT4=
X-Google-Smtp-Source: APiQypLgZ7cCFOMPURfhADdu5tVLrztIKA+SKGQ94G0JDKXnx19Tkt7i0G2ASZR6dlPCRBnAneHiuQ==
X-Received: by 2002:a1c:2e07:: with SMTP id u7mr4077683wmu.74.1588073028875;
 Tue, 28 Apr 2020 04:23:48 -0700 (PDT)
Received: from localhost.localdomain (44.142.6.51.dyn.plus.net. [51.6.142.44])
 by smtp.gmail.com with ESMTPSA id
 h17sm2871913wmm.6.2020.04.28.04.23.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Apr 2020 04:23:48 -0700 (PDT)
From: Wei Liu <wl@xen.org>
To: Xen Development List <xen-devel@lists.xenproject.org>
Subject: [PATCH] MAINTAINERS: list myself as mini-os reviewer
Date: Tue, 28 Apr 2020 12:23:46 +0100
Message-Id: <20200428112346.10498-1-wl@xen.org>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, minios-devel@lists.xenproject.org,
 Jan Beulich <jbeulich@suse.com>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

I probably don't have much time to actually review patches, but I do
want to be CC'ed such that I can commit patches in a timely manner.

Signed-off-by: Wei Liu <wl@xen.org>
---
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: minios-devel@lists.xenproject.org
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8a4c869704b0..e3748167550c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -374,6 +374,7 @@ F:	xen/test/livepatch/*
 
 MINI-OS
 M:	Samuel Thibault <samuel.thibault@ens-lyon.org>
+R:	Wei Liu <wl@xen.org>
 S:	Supported
 L:	minios-devel@lists.xenproject.org
 T:	git https://xenbits.xenproject.org/git-http/mini-os.git
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:24:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOLt-0004R5-6S; Tue, 28 Apr 2020 11:24:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NU6p=6M=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTOLr-0004Qx-5m
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:24:35 +0000
X-Inumbo-ID: d5bb1af7-8942-11ea-984c-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d5bb1af7-8942-11ea-984c-12813bfff9fa;
 Tue, 28 Apr 2020 11:24:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588073074;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=d2ppzpQoYuZU0fIiUWjzTipilifiem79IQGnX/DQMpQ=;
 b=F5iKSkWaYhvvjOu3OnvNwT+NSYLb9wfr1VkjMd09lpssBLL6Slw2SxcO
 Ap3QjegErqium6H9IbPWe9E15w5pNQhXiUVejwQ6kVIdxNKt8+rDmWu4q
 nBsAB61ZKMQW+4PeC2/o4CQbpz/W3qrCMrmFd0B/Drz8kMx6JIgBFBW97 Q=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: tAn3GjkbWo7SxIv9t5t5Z7/3OqX5McoKXHQMtxUiQS1z+mfbPfTu+cYirne7WjPqmFO0zBDNg4
 N7ndSmJUx9r14aJw2P5G9ztoKBXUuenrLos8YTTjaRuudU1gmNtUDR6zyfSqL/x/G9fvlRLfYR
 e0G4Xh8/vc1mx6hIkXHzoFUGysM6QstK/BrAe/mWS5OH+/riNzVqBABE/Frbad1mYxSmcHScOS
 uQGl9XEnVyj854gKZzR2bD4ALZxaXiSyU5+nkeAz9wWMweYtJ3waMzf+YI7HnbLnxdTjX/sPy1
 7ac=
X-SBRS: 2.7
X-MesageID: 16675484
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,327,1583211600"; d="scan'208";a="16675484"
Subject: Re: [PATCH] mini-os: Avoid segfaults in tc{g,s}etattr
To: Wei Liu <wl@xen.org>, Jason Andryuk <jandryuk@gmail.com>
References: <20200427034019.6251-1-jandryuk@gmail.com>
 <20200427075429.mshevnm2ype7tq32@function>
 <CAKf6xpuh3v0H-22=7y83ioYsm2GnKOs+FO8nN2s3djXanUL9BQ@mail.gmail.com>
 <20200428111645.pa6xfs6t6rifu6fu@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <3ed7eb87-070c-28ea-4f8a-aa4421cea93a@citrix.com>
Date: Tue, 28 Apr 2020 12:24:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200428111645.pa6xfs6t6rifu6fu@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org,
 Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28/04/2020 12:16, Wei Liu wrote:
>>>> ---
>>>> I can't get ioemu-stubdom to start without this.  With this, the guest
>>>> just reboots immediately, but it does that with a non-stubdom
>>>> device_model_version="qemu-xen-traditional" .  The same guest disk image
>>>> (cirros 0.5.1) boots with a linux stubdom or non-stubdom Ubuntu
>>>> qemu-system-x86_64.
>> Ubuntu gcc-9 adds -fcf-protection by default.  Somehow that flag
>> caused rombios (I think) to restart.  Setting -fcf-protection=none
>> like below (probably just the EMBEDDED_EXTRA_CFLAGS part) lets rombios
>> start properly.

All it does is insert ENDBR{32,64} instructions, which are nops on older
processors.

I suspect that it is not the -fcf-protection= directly, but some change
in alignment of a critical function.

>>   The hypervisor needs it as well via
>> EXTRA_CFLAGS_XEN_CORE=-fcf-protection=none and maybe also added to
>> xen/arch/x86/boot/build32.mk .
> Are you able to turn this into a proper patch? I suspect you will need
> to test the availability of this new (?) flag.
>
> Also Cc Jan and Andrew because it affects hypervisor build too.

I need to chase this up.  It is a GCC bug breaking the hypervisor build,
and I'm moderately disinclined to hack around it, seeing as
-fcf-protection is something we want in due course.

The bug is that GCC falsely declares that -fcf-protection is
incompatible with -mindirect-thunk=extern, despite me spending a week
during the Spectre embargo period specifically arranging for the two to
be compatible, because we knew we'd want to build retpoline-safe
binaries which could also use CET on newer hardware.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:30:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTORE-0005Ij-UU; Tue, 28 Apr 2020 11:30:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=DYx7=6M=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTORE-0005IL-Av
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:30:08 +0000
X-Inumbo-ID: 9c40af88-8943-11ea-984e-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9c40af88-8943-11ea-984e-12813bfff9fa;
 Tue, 28 Apr 2020 11:30:07 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0ED4FADCE;
 Tue, 28 Apr 2020 11:30:05 +0000 (UTC)
Subject: Re: [PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor
 filesystem
To: George Dunlap <George.Dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
References: <20200402154616.16927-1-jgross@suse.com>
 <20200402154616.16927-9-jgross@suse.com>
 <19f84540-6b49-f99d-805a-e07f56330f31@suse.com>
 <b9ddd1fb-d868-bb69-3b6b-27531beda2fa@suse.com>
 <f7d1f3aa-3a7e-fcb2-3163-5e67756e8452@suse.com>
 <17d65095-a51e-2e00-38ee-7c1c83d2bb99@suse.com>
 <51e0f0d2-f9ce-83fd-79fa-ae4805356612@suse.com>
 <31c7f4fe-847c-96f5-e598-dba99b0bb61a@suse.com>
 <085E1F72-EC22-43D6-8F7E-EDC132CC787D@citrix.com>
 <fb0e92cc-102f-7f87-1ad6-f3ccce1eee60@suse.com>
 <064958B4-1FCC-4300-A98A-7A1D608376F8@citrix.com>
 <23606595-8ce0-5151-d800-1dc0d97513d1@suse.com>
 <563C8FE9-E852-43F6-9FCC-EEEA14B60473@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <b243c222-fb17-4efa-3b25-aad52c2d0eb1@suse.com>
Date: Tue, 28 Apr 2020 13:30:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <563C8FE9-E852-43F6-9FCC-EEEA14B60473@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <Andrew.Cooper3@citrix.com>,
 Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.20 13:23, George Dunlap wrote:
> 
> 
>> On Apr 28, 2020, at 9:39 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 28.04.2020 10:24, George Dunlap wrote:
>>>> On Apr 28, 2020, at 8:20 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 27.04.2020 18:25, George Dunlap wrote:
>>>>> If Jan is OK with it simply being outside CONFIG_EXPERT, then great.  But if he insists on some kind of testing for it to be outside of CONFIG_EXPERT, then again, the people who want it to be security supported should be the ones who do the work to make it happen.
>>>>
>>>> I don't understand this part, I'm afraid: Without a config option,
>>>> the code is going to be security supported as long as it doesn't
>>>> get marked otherwise (experimental or what not). With an option
>>>> depending on EXPERT, what would become security unsupported is the
>>>> non-default (i.e. disabled) setting. There's not a whole lot to
>>>> test there, it's merely a formal consequence of our general rules.
>>>> (Of course, over time dependencies of other code may develop on
>>>> the information being available e.g. to Dom0 userland. Just like
>>>> there's Linux userland code assuming the kernel config is
>>>> available in certain ways [I don't necessarily mean the equivalent
>>>> of hypfs here], to then use it in what I'd call abusive ways in at
>>>> least some cases.)
>>>
>>> Here’s an argument you might make:
>>>
>>> “As a member of the security team, I don’t want to be on the hook for issuing XSAs for code which isn’t at least smoke-tested.  Therefore, I oppose any patch adding CONFIG_HYPFS outside of CONFIG_EXPERT, *unless* there is a concrete plan for getting regular testing for CONFIG_HYPFS=n.”
>>>
>>> I’m not saying that’s an argument you *should* make.  But personally I don’t have a strong argument against such an argument. So, it seems to me, if you did make it, you have a reasonable chance of carrying your point.
>>>
>>> Now consider this hypothetical universe where you made that argument and nobody opposed it.  In order to get a particular feature (CONFIG_HYPFS=n security supported), there is extra work that needs to be done (getting CONFIG_HYPFS=n tested regularly).  My point was, the expectation should be that the extra work will be done by the people who want or benefit from the feature; the series shouldn’t be blocked until Juergen implements CONFIG_HYPFS=n testing (since he doesn’t personally have a stake in that feature).
>>>
>>> Now obviously, doing work to help someone else out in the community is of course a good thing to do; it builds goodwill, uses our aggregate resources more efficiently, and makes our community more enjoyable to work with. But the goodwill primarily comes from the fact that it was done as a voluntary choice, not as a requirement.
>>>
>>> Juergen was balking at having to do what he saw as extra work to implement CONFIG_HYPFS.  I wanted to make it clear that even though I see value in having CONFIG_HYPFS, *he* doesn’t have to do the work if he doesn’t want to (although it would certainly be appreciated if he did).  And this paragraph was extending the same principle into the hypothetical universe where someone insisted that CONFIG_HYPFS=n had to be tested before being security supported.
>>>
>>> Hope that makes sense. :-)
>>
>> Yes, it does, thanks for the clarification. I can see what you describe
>> as a valid perspective to take, but really in my request to Jürgen I
>> took another: Now that we have Kconfig, additions of larger bodies of
>> code (possibly also just in terms of binary size) should imo generally
>> be questioned whether they want/need to be built for everyone. I.e. it
>> is not to be left to people being worried about binary sizes to arrange
>> for things to not be built, but for people contributing new but not
>> entirely essential code to consider making it option from the very
>> beginning.
> 
> I think that’s a reasonable position to take, but needs to be balanced on the amount of work that this would actually require.  If it only requires adding a handful of #ifdef’s and maybe making a few stubs, then yes, asking the submitter to make the change makes sense.  But if it requires three dozen #ifdef’s throughout the code and a fairly major architectural change, then I think it’s reasonable for a submitter to push back.
> 
> I don’t really understand why Juergen thinks adding CONFIG_HYPFS would cause a lot of code churn; my argumentation here is based on the assumption that his assessment is correct.

The main problem I'm seeing is the setting of runtime parameters.

This will need a complete different set of macros for defining those
parameters, split across multiple patches. And I'm fairly sure I'll
need to touch each custom_runtime_param handling function, too, in
order not to add dead code.


Juergen


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:30:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:30:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTORY-0005NM-71; Tue, 28 Apr 2020 11:30:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=sOCy=6M=ens-lyon.org=samuel.thibault@srs-us1.protection.inumbo.net>)
 id 1jTORW-0005NC-NO
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:30:26 +0000
X-Inumbo-ID: a6fbc0de-8943-11ea-984e-12813bfff9fa
Received: from hera.aquilenet.fr (unknown [185.233.100.1])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a6fbc0de-8943-11ea-984e-12813bfff9fa;
 Tue, 28 Apr 2020 11:30:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id D0A12DFE8;
 Tue, 28 Apr 2020 13:30:23 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HAMh4u15Eazi; Tue, 28 Apr 2020 13:30:22 +0200 (CEST)
Received: from function (unknown [IPv6:2a01:cb19:956:1b00:9eb6:d0ff:fe88:c3c7])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 7430EDFE2;
 Tue, 28 Apr 2020 13:30:22 +0200 (CEST)
Received: from samy by function with local (Exim 4.93)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1jTORQ-00A1hJ-MP; Tue, 28 Apr 2020 13:30:20 +0200
Date: Tue, 28 Apr 2020 13:30:20 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wl@xen.org>
Subject: Re: [PATCH] MAINTAINERS: list myself as mini-os reviewer
Message-ID: <20200428113020.twmgdpcddmbaj73l@function>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Wei Liu <wl@xen.org>,
 Xen Development List <xen-devel@lists.xenproject.org>,
 minios-devel@lists.xenproject.org,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <20200428112346.10498-1-wl@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200428112346.10498-1-wl@xen.org>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, minios-devel@lists.xenproject.org,
 Jan Beulich <jbeulich@suse.com>,
 Xen Development List <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Wei Liu, le mar. 28 avril 2020 12:23:46 +0100, a ecrit:
> I probably don't have much time to actually review patches, but I do
> want to be CC'ed such that I can commit patches in a timely manner.
> 
> Signed-off-by: Wei Liu <wl@xen.org>

I actually thought you were already referenced there...

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
> Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Cc: minios-devel@lists.xenproject.org
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8a4c869704b0..e3748167550c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -374,6 +374,7 @@ F:	xen/test/livepatch/*
>  
>  MINI-OS
>  M:	Samuel Thibault <samuel.thibault@ens-lyon.org>
> +R:	Wei Liu <wl@xen.org>
>  S:	Supported
>  L:	minios-devel@lists.xenproject.org
>  T:	git https://xenbits.xenproject.org/git-http/mini-os.git
> -- 
> 2.20.1
> 

-- 
Samuel
<s> je la connaissais pas celle la : "make: Entering an unknown directory"
 -+- #ens-mim -+-


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:32:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOTl-0005eP-LV; Tue, 28 Apr 2020 11:32:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTOTk-0005eK-1j
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:32:44 +0000
X-Inumbo-ID: f90ff143-8943-11ea-984e-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f90ff143-8943-11ea-984e-12813bfff9fa;
 Tue, 28 Apr 2020 11:32:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C4FD9AC69;
 Tue, 28 Apr 2020 11:32:40 +0000 (UTC)
Subject: Re: [PATCH] MAINTAINERS: list myself as mini-os reviewer
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, Wei Liu <wl@xen.org>
References: <20200428112346.10498-1-wl@xen.org>
 <20200428113020.twmgdpcddmbaj73l@function>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <1e76003b-c1b3-3010-02ea-d45cf977feb0@suse.com>
Date: Tue, 28 Apr 2020 13:32:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200428113020.twmgdpcddmbaj73l@function>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, minios-devel@lists.xenproject.org,
 Xen Development List <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.2020 13:30, Samuel Thibault wrote:
> Wei Liu, le mar. 28 avril 2020 12:23:46 +0100, a ecrit:
>> I probably don't have much time to actually review patches, but I do
>> want to be CC'ed such that I can commit patches in a timely manner.
>>
>> Signed-off-by: Wei Liu <wl@xen.org>
> 
> I actually thought you were already referenced there...
> 
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Acked-by: Jan Beulich <jbeulich@suse.com>


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:37:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOYZ-0005rA-BC; Tue, 28 Apr 2020 11:37:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=KfNV=6M=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jTOYX-0005r0-9l
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:37:41 +0000
X-Inumbo-ID: a7e412de-8944-11ea-b07b-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a7e412de-8944-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 11:37:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=H7VgQJ8LNzUCWww4xat13apJceeEkolvQkj8XJzN5c8=; b=liaJeXKXY4W7mQMQusUnEePmLk
 o9BpxT9uXL8zZU+9jUVM0rsFqYALI00edicC/n7XjwswNHjY1kT1idc6nj8Uhn8o9pCli2yPNJNwA
 LYVC4Ughi1ifnZ6e6lruiw3T04kPzvDJwZSOdPcuDR+o/nu+8SXbXUgkGbidoc2NWRSI=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jTOYQ-00020f-H8; Tue, 28 Apr 2020 11:37:34 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jTOYQ-0003bF-7f; Tue, 28 Apr 2020 11:37:34 +0000
Date: Tue, 28 Apr 2020 12:37:31 +0100
From: Wei Liu <wl@xen.org>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, Wei Liu <wl@xen.org>,
 Xen Development List <xen-devel@lists.xenproject.org>,
 minios-devel@lists.xenproject.org,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH] MAINTAINERS: list myself as mini-os reviewer
Message-ID: <20200428113731.ra4jxikqmuv6mtvv@debian>
References: <20200428112346.10498-1-wl@xen.org>
 <20200428113020.twmgdpcddmbaj73l@function>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200428113020.twmgdpcddmbaj73l@function>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 28, 2020 at 01:30:20PM +0200, Samuel Thibault wrote:
> Wei Liu, le mar. 28 avril 2020 12:23:46 +0100, a ecrit:
> > I probably don't have much time to actually review patches, but I do
> > want to be CC'ed such that I can commit patches in a timely manner.
> > 
> > Signed-off-by: Wei Liu <wl@xen.org>
> 
> I actually thought you were already referenced there...

No I wasn't. Before the introduction of R: tag the only way to get CC'ed
was to step up as a maintainer. And I had had far too many hats
already...

Wei.


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:45:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:45:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOfg-0006pL-4A; Tue, 28 Apr 2020 11:45:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTOff-0006pG-P1
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:45:03 +0000
X-Inumbo-ID: b2630ade-8945-11ea-ae69-bc764e2007e4
Received: from mail-qv1-xf42.google.com (unknown [2607:f8b0:4864:20::f42])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b2630ade-8945-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 11:45:02 +0000 (UTC)
Received: by mail-qv1-xf42.google.com with SMTP id 59so8068808qva.13;
 Tue, 28 Apr 2020 04:45:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=message-id:from:to:cc:subject:date:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=fd/M3Ffs7OwceegYsMYGTqbAvT1dTQERp72SccZnPBY=;
 b=JYPyhmIYgn8bTgIM0SaWBtvgEIJKI+Bpac4lm1AzE4bMxnjcc8+SGaOTlLbhU/Chkq
 hBUq326SK/Su6heJlXHBdUJp4ddB0PBZnbSNlUcyIw39KOvLayr1nmfRr7I/q50vtZdS
 cBdLP+icy9Z5ALxHub/yq9S6AbIqt3ffUk93G5RxvqlH41UtvIi1CcpIioel5VeQ31FO
 +MWm7mOoLG9jzOEXodi7+0cynz4b5Y10o8u4r11kpL5K6O3lMSvPVbvNnfs+pePUoJ0J
 je5trHddards1xLVs2+vlZhduttcoWuKFeB/5uJ+1AekQe+WRkX2sb52pTNwUUzIQdW3
 Xanw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:message-id:from:to:cc:subject:date:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=fd/M3Ffs7OwceegYsMYGTqbAvT1dTQERp72SccZnPBY=;
 b=aRHERUPBBlkcjGAsuTQ1TVm4lgAmySWUFawlwSM/cdSB/r7mjtLbBAIggwvNDZlGyu
 pO1Bt9W47QvNt0DSLfzSqG7VMvNDUxoISRyD6vmvJGBBqgmUtm3C5jQfrJUdVgwhuMhr
 MQvmt2PGVrYi2LVnHNIjISJdZ+xYThXRhXcRdS6VnfdN26+bL2maG/krm7y/24gnqhKS
 Y1tebl/F7si8kek8aKJrx2fXLtnVbfGCAkeGdFlV7xKLajocQoGAs5s3j5uTKO+RmjTN
 lqyQxg0Ob5Md7XgNWJ2YcWbleUUsa1j0SZ2XXBcYr296v+tYFJLzEeG1jzKlWKGODx97
 bOLQ==
X-Gm-Message-State: AGi0PuaHVY+LeLAk1TNa72KXQnZ4AuOTWqOlzGTTc/A5pWNcAmqxg4j5
 fxJx3cCCJXHfvfXdz2Lfz2w=
X-Google-Smtp-Source: APiQypJ7BqPEg+ekb3cUEqbx6s21kP9AG6R4IzIL1zPHxr4AcZKRRps4r/ApG4naung0Pjzx+NKdkA==
X-Received: by 2002:a0c:f1d0:: with SMTP id u16mr27874790qvl.160.1588074302277; 
 Tue, 28 Apr 2020 04:45:02 -0700 (PDT)
Received: from shine.lan ([2001:470:8:67e:15d1:d31e:91aa:b702])
 by smtp.gmail.com with ESMTPSA id 205sm13055464qkj.1.2020.04.28.04.45.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Apr 2020 04:45:01 -0700 (PDT)
Message-ID: <5ea8173d.1c69fb81.915ba.8400@mx.google.com>
X-Google-Original-Message-ID: <3ed7eb87-070c-28ea-4f8a-aa4421cea93a@citrix.com> (raw)
From: Jason Andryuk <jandryuk@gmail.com>
To: andrew.cooper3@citrix.com, Wei Liu <wl@xen.org>,
 Jason Andryuk <jandryuk@gmail.com>
Subject: Re: [PATCH] mini-os: Avoid segfaults in tc{g,s}etattr
Date: Tue, 28 Apr 2020 07:44:07 -0400
X-Mailer: git-send-email 2.20.1
In-Reply-To: <20200428111645.pa6xfs6t6rifu6fu@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <3ed7eb87-070c-28ea-4f8a-aa4421cea93a@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, samuel.thibault@ens-lyon.org,
 Stefan Bader <stefan.bader@canonical.com>, JBeulich@suse.com,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Andrew Cooper <andrew.cooper3@citrix.com>

Andrew Cooper wrote:
>On 28/04/2020 12:16, Wei Liu wrote:
>>>>> ---
>>>>> I can't get ioemu-stubdom to start without this.  With this, the guest
>>>>> just reboots immediately, but it does that with a non-stubdom
>>>>> device_model_version="qemu-xen-traditional" .  The same guest disk image
>>>>> (cirros 0.5.1) boots with a linux stubdom or non-stubdom Ubuntu
>>>>> qemu-system-x86_64.
>>> Ubuntu gcc-9 adds -fcf-protection by default.  Somehow that flag
>>> caused rombios (I think) to restart.  Setting -fcf-protection=none
>>> like below (probably just the EMBEDDED_EXTRA_CFLAGS part) lets rombios
>>> start properly.
>
>All it does is insert ENDBR{32,64} instructions, which are nops on older
>processors.
>
>I suspect that it is not the -fcf-protection= directly, but some change
>in alignment of a critical function.
>
>>>   The hypervisor needs it as well via
>>> EXTRA_CFLAGS_XEN_CORE=-fcf-protection=none and maybe also added to
>>> xen/arch/x86/boot/build32.mk .
>> Are you able to turn this into a proper patch? I suspect you will need
>> to test the availability of this new (?) flag.
>>
>> Also Cc Jan and Andrew because it affects hypervisor build too.
>
>I need to chase this up.  It is a GCC bug breaking the hypervisor build,
>and I'm moderately disinclined to hack around it, seeing as
>-fcf-protection is something we want in due course.
>
>The bug is that GCC falsely declares that -fcf-protection is
>incompatible with -mindirect-thunk=extern, despite me spending a week
>during the Spectre embargo period specifically arranging for the two to
>be compatible, because we knew we'd want to build retpoline-safe
>binaries which could also use CET on newer hardware.

The gcc manual states:
  "Note that -mindirect-branch=thunk-extern is incompatible with
   -fcf-protection=branch since the external thunk cannot be modified
   to disable control-flow check."

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

Below is what I was preparing to submit as a patch.  So, yes it hacks around
it, but it isn't messy.

---
Disable fcf-protection to build working binaries

Ubuntu gcc-9 enables -fcf-protection by default, which conflicts with
-mindirect-branch=extern and prevents building the hypervisor with
CONFIG_INDIRECT_THUNK:
xmalloc.h:81:1: error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not
compatible

Stefan Bader also noticed that build32.mk requires -fcf-protection=none
or else the hypervisor will not boot.
https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1863260  Similarly,
rombios reboots almost immediately without -fcf-protection=none.  Both
of those can be handled by setting it in EMBEDDED_EXTRA_CFLAGS.

CC: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
 Config.mk             | 1 +
 xen/arch/x86/Rules.mk | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Config.mk b/Config.mk
index 0f303c79b2..efb3d42bc4 100644
--- a/Config.mk
+++ b/Config.mk
@@ -205,6 +205,7 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 
 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
+EMBEDDED_EXTRA_CFLAGS += -fcf-protection=none
 
 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 4b7ab78467..c3cbae69d2 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -69,6 +69,7 @@ CFLAGS += -mno-sse $(call cc-option,$(CC),-mskip-rax-setup)
 ifeq ($(CONFIG_INDIRECT_THUNK),y)
 CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register
 CFLAGS += -fno-jump-tables
+$(call cc-option-add,CFLAGS,CC,-fcf-protection=none)
 endif
 
 # If supported by the compiler, reduce stack alignment to 8 bytes. But allow
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:55:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:55:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOpY-0007qo-Fr; Tue, 28 Apr 2020 11:55:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NU6p=6M=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTOpX-0007qf-2N
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:55:15 +0000
X-Inumbo-ID: 1b569975-8947-11ea-984f-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1b569975-8947-11ea-984f-12813bfff9fa;
 Tue, 28 Apr 2020 11:55:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588074910;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=enUyvB+FB7mIYnf4Lgty66y0JScU1/TJBrpTb6nLWdg=;
 b=hsvHj0Q+B7e5O1c4px8KmV/0/V0Ta18m9m1TBWkPHK0BBNHXJqtQUytg
 Vz5CYouMkIdnm1eqC+v6HPXffMBN/ABnNb6CuZUsrKY4S+nZlhIYDAiCd
 XV3SUB6PFxSc2SSIxYNeYA8v3OATkRjgmtE7QGZla6VTA/IUjoxFT7drx Y=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: qRGEp+/ruFgmzHfI3f2hn8wrW70I6cFQLjEwobFlX0hnz5KBqeD/A4WzTzMA9j5OoVxC5igpM0
 pXStId8iGGBl+HTIb0zGtRP5AvARC5E/9WmT89PlD4oCFIR/3Ix4+LxIyTUa6useHVcLLo8dLu
 s8tTbZj8iU3a+wXZrAG4aWUXEenqiNIhbmAGEWn58DdEkVZkYEBk491V28A77rX5pljBCgRBDp
 slLmkraaSr/U94kNxinex/LPy+2XaEARZ0oIA4l9wTQuah3fkq7I6BG0DYVaOksLJJlBehnYj7
 NGU=
X-SBRS: 2.7
X-MesageID: 16378220
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,327,1583211600"; d="scan'208";a="16378220"
Subject: Re: [PATCH] mini-os: Avoid segfaults in tc{g,s}etattr
To: Jason Andryuk <jandryuk@gmail.com>, Wei Liu <wl@xen.org>
References: <3ed7eb87-070c-28ea-4f8a-aa4421cea93a@citrix.com>
 <5ea8173d.1c69fb81.915ba.8400@mx.google.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <c242b963-ae80-1ca0-9b4d-fe2c8f66b6a2@citrix.com>
Date: Tue, 28 Apr 2020 12:55:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5ea8173d.1c69fb81.915ba.8400@mx.google.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, samuel.thibault@ens-lyon.org, Stefan
 Bader <stefan.bader@canonical.com>, JBeulich@suse.com,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28/04/2020 12:44, Jason Andryuk wrote:
> From: Andrew Cooper <andrew.cooper3@citrix.com>
>
> Andrew Cooper wrote:
>> On 28/04/2020 12:16, Wei Liu wrote:
>>>>>> ---
>>>>>> I can't get ioemu-stubdom to start without this.  With this, the guest
>>>>>> just reboots immediately, but it does that with a non-stubdom
>>>>>> device_model_version="qemu-xen-traditional" .  The same guest disk image
>>>>>> (cirros 0.5.1) boots with a linux stubdom or non-stubdom Ubuntu
>>>>>> qemu-system-x86_64.
>>>> Ubuntu gcc-9 adds -fcf-protection by default.  Somehow that flag
>>>> caused rombios (I think) to restart.  Setting -fcf-protection=none
>>>> like below (probably just the EMBEDDED_EXTRA_CFLAGS part) lets rombios
>>>> start properly.
>> All it does is insert ENDBR{32,64} instructions, which are nops on older
>> processors.
>>
>> I suspect that it is not the -fcf-protection= directly, but some change
>> in alignment of a critical function.
>>
>>>>   The hypervisor needs it as well via
>>>> EXTRA_CFLAGS_XEN_CORE=-fcf-protection=none and maybe also added to
>>>> xen/arch/x86/boot/build32.mk .
>>> Are you able to turn this into a proper patch? I suspect you will need
>>> to test the availability of this new (?) flag.
>>>
>>> Also Cc Jan and Andrew because it affects hypervisor build too.
>> I need to chase this up.  It is a GCC bug breaking the hypervisor build,
>> and I'm moderately disinclined to hack around it, seeing as
>> -fcf-protection is something we want in due course.
>>
>> The bug is that GCC falsely declares that -fcf-protection is
>> incompatible with -mindirect-thunk=extern, despite me spending a week
>> during the Spectre embargo period specifically arranging for the two to
>> be compatible, because we knew we'd want to build retpoline-safe
>> binaries which could also use CET on newer hardware.
> The gcc manual states:
>   "Note that -mindirect-branch=thunk-extern is incompatible with
>    -fcf-protection=branch since the external thunk cannot be modified
>    to disable control-flow check."
>
> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

Yes.  This is false.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654

but sadly tumbleweeds.

I'll start a thread on the email list.

>
> Below is what I was preparing to submit as a patch.  So, yes it hacks around
> it, but it isn't messy.
>
> ---
> Disable fcf-protection to build working binaries
>
> Ubuntu gcc-9 enables -fcf-protection by default, which conflicts with
> -mindirect-branch=extern and prevents building the hypervisor with
> CONFIG_INDIRECT_THUNK:
> xmalloc.h:81:1: error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not
> compatible
>
> Stefan Bader also noticed that build32.mk requires -fcf-protection=none
> or else the hypervisor will not boot.
> https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1863260  Similarly,
> rombios reboots almost immediately without -fcf-protection=none.  Both
> of those can be handled by setting it in EMBEDDED_EXTRA_CFLAGS.
>
> CC: Stefan Bader <stefan.bader@canonical.com>
> Signed-off-by: Jason Andryuk <jandryuk@gmail.com>

Sadly, this isn't really appropriate.  We specifically do want to use
both -fcf-protection and -mindirect-branch=thunk-extern together, when
GCC isn't broken.

Overriding -fcf-protection is ok but only when we're certain we've got a
buggy GCC, so that when this bug is fixed, we can return to sensible
behaviour.

~Andrew

> ---
>  Config.mk             | 1 +
>  xen/arch/x86/Rules.mk | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/Config.mk b/Config.mk
> index 0f303c79b2..efb3d42bc4 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -205,6 +205,7 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
>  
>  EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
>  EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
> +EMBEDDED_EXTRA_CFLAGS += -fcf-protection=none
>  
>  XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
>  # All the files at that location were downloaded from elsewhere on
> diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> index 4b7ab78467..c3cbae69d2 100644
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -69,6 +69,7 @@ CFLAGS += -mno-sse $(call cc-option,$(CC),-mskip-rax-setup)
>  ifeq ($(CONFIG_INDIRECT_THUNK),y)
>  CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register
>  CFLAGS += -fno-jump-tables
> +$(call cc-option-add,CFLAGS,CC,-fcf-protection=none)
>  endif
>  
>  # If supported by the compiler, reduce stack alignment to 8 bytes. But allow



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 11:58:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 11:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTOso-000808-Vc; Tue, 28 Apr 2020 11:58:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=E+rP=6M=amazon.de=prvs=3804056da=vrd@srs-us1.protection.inumbo.net>)
 id 1jTOsn-000803-Np
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 11:58:37 +0000
X-Inumbo-ID: 97c14680-8947-11ea-9887-bc764e2007e4
Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 97c14680-8947-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 11:58:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
 t=1588075117; x=1619611117;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=VCHozhHCzEt8gvPcvw+Aj+TYcv2/gXWyxMdkkGaGAs4=;
 b=rsGICUpONvzEbVt8JUif2vOnUyTTj/pO079rigc4vwSt7lpHI+UJ+q4n
 Oo0JTCt26lPpMS9ue4uDUPTfBA02VZqnIPpQX5yGV+r8iDznfJfanBDJS
 ukPxsyp8FvaP7c75VoVtkIbwbAmWsNjErd+PZ63q7Q4re4KwzLXVRLYf/ o=;
IronPort-SDR: ux2S0iDAqYSkxrk8+AUdX+QMyv5GYigZ1GS0JCOtjyoFGxu5PFZW+s7kSADQEkSnzGfhF5o/bb
 r4OR350Dhdlw==
X-IronPort-AV: E=Sophos;i="5.73,327,1583193600"; d="scan'208";a="27908179"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO
 email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.43.8.2])
 by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP;
 28 Apr 2020 11:58:24 +0000
Received: from EX13MTAUEA002.ant.amazon.com
 (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])
 by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (Postfix) with ESMTPS
 id 6890F282D25; Tue, 28 Apr 2020 11:58:23 +0000 (UTC)
Received: from EX13D22EUA003.ant.amazon.com (10.43.165.210) by
 EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 28 Apr 2020 11:58:22 +0000
Received: from EX13MTAUWA001.ant.amazon.com (10.43.160.58) by
 EX13D22EUA003.ant.amazon.com (10.43.165.210) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 28 Apr 2020 11:58:21 +0000
Received: from u908889d5e8f057.ant.amazon.com (10.1.212.23) by
 mail-relay.amazon.com (10.43.160.118) with Microsoft SMTP Server (TLS) id
 15.0.1497.2 via Frontend Transport; Tue, 28 Apr 2020 11:58:18 +0000
Subject: Re: [PATCH v4] x86: irq: Do not BUG_ON multiple unbind calls for
 shared pirqs
To: Jan Beulich <jbeulich@suse.com>, <paul@xen.org>
References: <20200306160254.8465-1-paul@xen.org>
 <58f00871-2fff-be69-299e-e2b9911e0723@suse.com>
 <000301d5f63a$df5f04a0$9e1d0de0$@xen.org>
 <0648e7ac-f5d7-4207-e2c6-8418681cca13@suse.com>
From: <vrd@amazon.com>
Message-ID: <8bcd4d23-cb03-bb3e-360e-4213cd2d7b49@amazon.com>
Date: Tue, 28 Apr 2020 13:58:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <0648e7ac-f5d7-4207-e2c6-8418681cca13@suse.com>
Content-Language: en-US
Precedence: Bulk
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: base64
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, 'Varad Gautam' <vrd@amazon.de>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>, 'Julien
 Grall' <julien@xen.org>,
 =?UTF-8?B?J1JvZ2VyIFBhdSBNb25uw6kn?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

SGkgSmFuLAoKT24gMy8xMC8yMCAzOjE5IFBNLCBKYW4gQmV1bGljaCB3cm90ZToKPiBPbiAwOS4w
My4yMDIwIDE4OjQ3LCBQYXVsIER1cnJhbnQgd3JvdGU6Cj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQo+Pj4gRnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgo+Pj4gU2Vu
dDogMDkgTWFyY2ggMjAyMCAxNjoyOQo+Pj4gVG86IHBhdWxAeGVuLm9yZwo+Pj4gQ2M6IHhlbi1k
ZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZzsgVmFyYWQgR2F1dGFtIDx2cmRAYW1hem9uLmRlPjsg
SnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyCj4+PiBQYXUgTW9ubsOpIDxyb2dl
ci5wYXVAY2l0cml4LmNvbT47IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5j
b20+Cj4+PiBTdWJqZWN0OiBSZTogW1BBVENIIHY0XSB4ODY6IGlycTogRG8gbm90IEJVR19PTiBt
dWx0aXBsZSB1bmJpbmQgY2FsbHMgZm9yIHNoYXJlZCBwaXJxcwo+Pj4KPj4+IE9uIDA2LjAzLjIw
MjAgMTc6MDIsIHBhdWxAeGVuLm9yZyB3cm90ZToKPj4+PiBGcm9tOiBWYXJhZCBHYXV0YW0gPHZy
ZEBhbWF6b24uZGU+Cj4+Pj4KPj4+PiBYRU5fRE9NQ1RMX2Rlc3Ryb3lkb21haW4gY3JlYXRlcyBh
IGNvbnRpbnVhdGlvbiBpZiBkb21haW5fa2lsbCAtRVJFU1RBUlRTLgo+Pj4+IEluIHRoYXQgc2Nl
bmFyaW8sIGl0IGlzIHBvc3NpYmxlIHRvIHJlY2VpdmUgbXVsdGlwbGUgX19waXJxX2d1ZXN0X3Vu
YmluZAo+Pj4+IGNhbGxzIGZvciB0aGUgc2FtZSBwaXJxIGZyb20gZG9tYWluX2tpbGwsIGlmIHRo
ZSBwaXJxIGhhcyBub3QgeWV0IGJlZW4KPj4+PiByZW1vdmVkIGZyb20gdGhlIGRvbWFpbidzIHBp
cnFfdHJlZSwgYXM6Cj4+Pj4gICAgZG9tYWluX2tpbGwoKQo+Pj4+ICAgICAgLT4gZG9tYWluX3Jl
bGlucXVpc2hfcmVzb3VyY2VzKCkKPj4+PiAgICAgICAgLT4gcGNpX3JlbGVhc2VfZGV2aWNlcygp
Cj4+Pj4gICAgICAgICAgLT4gcGNpX2NsZWFuX2RwY2lfaXJxKCkKPj4+PiAgICAgICAgICAgIC0+
IHBpcnFfZ3Vlc3RfdW5iaW5kKCkKPj4+PiAgICAgICAgICAgICAgLT4gX19waXJxX2d1ZXN0X3Vu
YmluZCgpCj4+Pj4KPj4+PiBGb3IgYSBzaGFyZWQgcGlycSAobnJfZ3Vlc3RzID4gMSksIHRoZSBm
aXJzdCBjYWxsIHdvdWxkIHphcCB0aGUgY3VycmVudAo+Pj4+IGRvbWFpbiBmcm9tIHRoZSBwaXJx
J3MgZ3Vlc3RzW10gbGlzdCwgYnV0IHRoZSBhY3Rpb24gaGFuZGxlciBpcyBuZXZlciBmcmVlZAo+
Pj4+IGFzIHRoZXJlIGFyZSBvdGhlciBndWVzdHMgdXNpbmcgdGhpcyBwaXJxLiBBcyBhIHJlc3Vs
dCwgb24gdGhlIHNlY29uZCBjYWxsLAo+Pj4+IF9fcGlycV9ndWVzdF91bmJpbmQgc2VhcmNoZXMg
Zm9yIHRoZSBjdXJyZW50IGRvbWFpbiB3aGljaCBoYXMgYmVlbiByZW1vdmVkCj4+Pj4gZnJvbSB0
aGUgZ3Vlc3RzW10gbGlzdCwgYW5kIGhpdHMgYSBCVUdfT04uCj4+Pj4KPj4+PiBNYWtlIF9fcGly
cV9ndWVzdF91bmJpbmQgc2FmZSB0byBiZSBjYWxsZWQgbXVsdGlwbGUgdGltZXMgYnkgbGV0dGlu
ZyB4ZW4KPj4+PiBjb250aW51ZSBpZiBhIHNoYXJlZCBwaXJxIGhhcyBhbHJlYWR5IGJlZW4gdW5i
b3VuZCBmcm9tIHRoaXMgZ3Vlc3QuIFRoZQo+Pj4+IFBJUlEgd2lsbCBiZSBjbGVhbmVkIHVwIGZy
b20gdGhlIGRvbWFpbidzIHBpcnFfdHJlZSBkdXJpbmcgdGhlIGRlc3RydWN0aW9uCj4+Pj4gaW4g
Y29tcGxldGVfZG9tYWluX2Rlc3Ryb3kgYW55d2F5Lgo+Pj4+Cj4+Pj4gU2lnbmVkLW9mZi1ieTog
VmFyYWQgR2F1dGFtIDx2cmRAYW1hem9uLmRlPgo+Pj4+IFt0YWtpbmcgb3ZlciBmcm9tIFZhcmFk
IGF0IHY0XQo+Pj4+IFNpZ25lZC1vZmYtYnk6IFBhdWwgRHVycmFudCA8cGF1bEB4ZW4ub3JnPgo+
Pj4+IC0tLQo+Pj4+IENjOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cj4+Pj4gQ2M6
IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+Cj4+Pj4gQ2M6IFJvZ2VyIFBhdSBNb25uw6kg
PHJvZ2VyLnBhdUBjaXRyaXguY29tPgo+Pj4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29v
cGVyM0BjaXRyaXguY29tPgo+Pj4+Cj4+Pj4gUm9nZXIgc3VnZ2VzdGVkIGNsZWFuaW5nIHRoZSBl
bnRyeSBmcm9tIHRoZSBkb21haW4gcGlycV90cmVlIHNvIHRoYXQKPj4+PiB3ZSBuZWVkIG5vdCBt
YWtlIGl0IHNhZmUgdG8gcmUtY2FsbCBfX3BpcnFfZ3Vlc3RfdW5iaW5kKCkuIFRoaXMgc2VlbXMg
bGlrZQo+Pj4+IGEgcmVhc29uYWJsZSBzdWdnZXN0aW9uIGJ1dCB0aGUgc2VtYW50aWNzIG9mIHRo
ZSBjb2RlIGFyZSBhbG1vc3QKPj4+PiBpbXBlbmV0cmFibGUgKGUuZy4gJ3BpcnEnIGlzIHVzZWQg
dG8gbWVhbiBhbiBpbmRleCwgYSBwb2ludGVyIGFuZCBpcyBhbHNvCj4+Pj4gdGhlIG5hbWUgb2Yg
c3RydWN0IHNvIHlvdSBnZW5lcmFsbHkgaGF2ZSBsaXR0bGUgaWRlYSB3aGF0IGl0IGFjdGFsbHkg
bWVhbnMpCj4+Pj4gc28gSSBwcmVmZXIgdG8gc3RpY2sgd2l0aCBhIHNtYWxsIGZpeCB0aGF0IEkg
Y2FuIGFjdHVhbGx5IHJlYXNvbiBhYm91dC4KPj4+Pgo+Pj4+IHY0Ogo+Pj4+ICAgLSBSZS13b3Jr
IHRoZSBndWVzdCBhcnJheSBzZWFyY2ggdG8gbWFrZSBpdCBjbGVhcmVyCj4+PiBJLmUuIHRoZXJl
IGFyZSBjb3NtZXRpYyBkaWZmZXJlbmNlcyB0byB2MyAoc2VlIGJlbG93KSwgYnV0Cj4+PiB0ZWNo
bmljYWxseSBpdCdzIHN0aWxsIHRoZSBzYW1lLiBJIGNhbid0IGJlbGlldmUgdGhlIHJlLXVzZQo+
Pj4gb2YgInBpcnEiIGZvciBkaWZmZXJlbnQgZW50aXRpZXMgaXMgdGhpcyBiaWcgb2YgYSBwcm9i
bGVtLgo+PiBQbGVhc2Ugc3VnZ2VzdCBjb2RlIGlmIHlvdSB0aGluayBpdCBvdWdodCB0byBiZSBk
b25lIGRpZmZlcmVudGVseS4gSSB0cmllZC4KPiBIb3cgYWJvdXQgdGhpcz8gSXQncyBhZG1pdHRl
ZGx5IG1vcmUgY29kZSwgYnV0IGltbyBsZXNzIGFkIGhvYy4KPiBJJ3ZlIHNtb2tlIHRlc3RlZCBp
dCwgYnV0IEkgZGVwZW5kIG9uIHlvdSBvciBWYXJhZCB0byBjaGVjayB0aGF0Cj4gaXQgYWN0dWFs
bHkgYWRkcmVzc2VzIHRoZSByZXBvcnRlZCBpc3N1ZS4KPgo+IEphbgo+Cj4geDg2L3Bhc3MtdGhy
b3VnaDogYXZvaWQgZG91YmxlIElSUSB1bmJpbmQgZHVyaW5nIGRvbWFpbiBjbGVhbnVwCgoKSSBo
YXZlIHRlc3RlZCB0aGF0IHRoaXMgcGF0Y2ggcHJldmVudHMgX19waXJxX2d1ZXN0X3VuYmluZCBv
biBhbiAKYWxyZWFkeS11bmJvdW5kIHBpcnEKZHVyaW5nIHRoZSBjb250aW51YXRpb24gY2FsbCBm
b3IgZG9tYWluX2tpbGwgLUVSRVNUQVJULCBieSB1c2luZyBhIAptb2RpZmllZCB4ZW4gdGhhdApm
b3JjZXMgYW4gLUVSRVNUQVJUIGZyb20gcGlycV9ndWVzdF91bmJpbmQgdG8gY3JlYXRlIHRoZSBj
b250aW51YXRpb24uIApJdCBmaXhlcyB0aGUKdW5kZXJseWluZyBpc3N1ZS4KClRlc3RlZC1ieTog
VmFyYWQgR2F1dGFtIDx2cmRAYW1hem9uLmRlPgoKCj4KPiBYRU5fRE9NQ1RMX2Rlc3Ryb3lkb21h
aW4gY3JlYXRlcyBhIGNvbnRpbnVhdGlvbiBpZiBkb21haW5fa2lsbCAtRVJFU1RBUlRTLgo+IElu
IHRoYXQgc2NlbmFyaW8sIGl0IGlzIHBvc3NpYmxlIHRvIHJlY2VpdmUgbXVsdGlwbGUgX3BpcnFf
Z3Vlc3RfdW5iaW5kCj4gY2FsbHMgZm9yIHRoZSBzYW1lIHBpcnEgZnJvbSBkb21haW5fa2lsbCwg
aWYgdGhlIHBpcnEgaGFzIG5vdCB5ZXQgYmVlbgo+IHJlbW92ZWQgZnJvbSB0aGUgZG9tYWluJ3Mg
cGlycV90cmVlLCBhczoKPiAgICBkb21haW5fa2lsbCgpCj4gICAgICAtPiBkb21haW5fcmVsaW5x
dWlzaF9yZXNvdXJjZXMoKQo+ICAgICAgICAtPiBwY2lfcmVsZWFzZV9kZXZpY2VzKCkKPiAgICAg
ICAgICAtPiBwY2lfY2xlYW5fZHBjaV9pcnEoKQo+ICAgICAgICAgICAgLT4gcGlycV9ndWVzdF91
bmJpbmQoKQo+ICAgICAgICAgICAgICAtPiBfX3BpcnFfZ3Vlc3RfdW5iaW5kKCkKPgo+IEF2b2lk
IHJlY3VycmluZyBpbnZvY2F0aW9ucyBvZiBwaXJxX2d1ZXN0X3VuYmluZCgpIGJ5IHJlbW92aW5n
IHRoZSBwSVJRCj4gZnJvbSB0aGUgdHJlZSBiZWluZyBpdGVyYXRlZCBhZnRlciB0aGUgZmlyc3Qg
Y2FsbCB0aGVyZS4gSW4gY2FzZSBzdWNoIGEKPiByZW1vdmVkIGVudHJ5IHN0aWxsIGhhcyBhIHNv
ZnRpcnEgb3V0c3RhbmRpbmcsIHJlY29yZCBpdCBhbmQgcmUtY2hlY2sKPiB1cG9uIHJlLWludm9j
YXRpb24uCj4KPiBSZXBvcnRlZC1ieTogVmFyYWQgR2F1dGFtIDx2cmRAYW1hem9uLmRlPgo+IFNp
Z25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KPgo+IC0tLSB1bnN0
YWJsZS5vcmlnL3hlbi9hcmNoL3g4Ni9pcnEuYwo+ICsrKyB1bnN0YWJsZS94ZW4vYXJjaC94ODYv
aXJxLmMKPiBAQCAtMTMyMyw3ICsxMzIzLDcgQEAgdm9pZCAocGlycV9jbGVhbnVwX2NoZWNrKShz
dHJ1Y3QgcGlycSAqcAo+ICAgICAgIH0KPgo+ICAgICAgIGlmICggcmFkaXhfdHJlZV9kZWxldGUo
JmQtPnBpcnFfdHJlZSwgcGlycS0+cGlycSkgIT0gcGlycSApCj4gLSAgICAgICAgQlVHKCk7Cj4g
KyAgICAgICAgQlVHX09OKCFkLT5pc19keWluZyk7Cj4gICB9Cj4KPiAgIC8qIEZsdXNoIGFsbCBy
ZWFkeSBFT0lzIGZyb20gdGhlIHRvcCBvZiB0aGlzIENQVSdzIHBlbmRpbmctRU9JIHN0YWNrLiAq
Lwo+IC0tLSB1bnN0YWJsZS5vcmlnL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3BjaS5jCj4gKysr
IHVuc3RhYmxlL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3BjaS5jCj4gQEAgLTg3Myw3ICs4NzMs
MTQgQEAgc3RhdGljIGludCBwY2lfY2xlYW5fZHBjaV9pcnEoc3RydWN0IGRvbQo+ICAgICAgICAg
ICB4ZnJlZShkaWdsKTsKPiAgICAgICB9Cj4KPiAtICAgIHJldHVybiBwdF9waXJxX3NvZnRpcnFf
YWN0aXZlKHBpcnFfZHBjaSkgPyAtRVJFU1RBUlQgOiAwOwo+ICsgICAgcmFkaXhfdHJlZV9kZWxl
dGUoJmQtPnBpcnFfdHJlZSwgZHBjaV9waXJxKHBpcnFfZHBjaSktPnBpcnEpOwo+ICsKPiArICAg
IGlmICggIXB0X3BpcnFfc29mdGlycV9hY3RpdmUocGlycV9kcGNpKSApCj4gKyAgICAgICAgcmV0
dXJuIDA7Cj4gKwo+ICsgICAgZG9tYWluX2dldF9pcnFfZHBjaShkKS0+cGVuZGluZ19waXJxX2Rw
Y2kgPSBwaXJxX2RwY2k7Cj4gKwo+ICsgICAgcmV0dXJuIC1FUkVTVEFSVDsKPiAgIH0KPgo+ICAg
c3RhdGljIGludCBwY2lfY2xlYW5fZHBjaV9pcnFzKHN0cnVjdCBkb21haW4gKmQpCj4gQEAgLTg5
MCw4ICs4OTcsMTggQEAgc3RhdGljIGludCBwY2lfY2xlYW5fZHBjaV9pcnFzKHN0cnVjdCBkbwo+
ICAgICAgIGh2bV9pcnFfZHBjaSA9IGRvbWFpbl9nZXRfaXJxX2RwY2koZCk7Cj4gICAgICAgaWYg
KCBodm1faXJxX2RwY2kgIT0gTlVMTCApCj4gICAgICAgewo+IC0gICAgICAgIGludCByZXQgPSBw
dF9waXJxX2l0ZXJhdGUoZCwgcGNpX2NsZWFuX2RwY2lfaXJxLCBOVUxMKTsKPiArICAgICAgICBp
bnQgcmV0ID0gMDsKPiArCj4gKyAgICAgICAgaWYgKCBodm1faXJxX2RwY2ktPnBlbmRpbmdfcGly
cV9kcGNpICkKPiArICAgICAgICB7Cj4gKyAgICAgICAgICAgIGlmICggcHRfcGlycV9zb2Z0aXJx
X2FjdGl2ZShodm1faXJxX2RwY2ktPnBlbmRpbmdfcGlycV9kcGNpKSApCj4gKyAgICAgICAgICAg
ICAgICAgcmV0ID0gLUVSRVNUQVJUOwo+ICsgICAgICAgICAgICBlbHNlCj4gKyAgICAgICAgICAg
ICAgICAgaHZtX2lycV9kcGNpLT5wZW5kaW5nX3BpcnFfZHBjaSA9IE5VTEw7Cj4gKyAgICAgICAg
fQo+Cj4gKyAgICAgICAgaWYgKCAhcmV0ICkKPiArICAgICAgICAgICAgcmV0ID0gcHRfcGlycV9p
dGVyYXRlKGQsIHBjaV9jbGVhbl9kcGNpX2lycSwgTlVMTCk7Cj4gICAgICAgICAgIGlmICggcmV0
ICkKPiAgICAgICAgICAgewo+ICAgICAgICAgICAgICAgc3Bpbl91bmxvY2soJmQtPmV2ZW50X2xv
Y2spOwo+IC0tLSB1bnN0YWJsZS5vcmlnL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL2lycS5oCj4g
KysrIHVuc3RhYmxlL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL2lycS5oCj4gQEAgLTE1OCw2ICsx
NTgsOCBAQCBzdHJ1Y3QgaHZtX2lycV9kcGNpIHsKPiAgICAgICBERUNMQVJFX0JJVE1BUChpc2Fp
cnFfbWFwLCBOUl9JU0FJUlFTKTsKPiAgICAgICAvKiBSZWNvcmQgb2YgbWFwcGVkIExpbmtzICov
Cj4gICAgICAgdWludDhfdCBsaW5rX2NudFtOUl9MSU5LXTsKPiArICAgIC8qIENsZWFuIHVwOiBF
bnRyeSB3aXRoIGEgc29mdGlycSBpbnZvY2F0aW9uIHBlbmRpbmcgLyBpbiBwcm9ncmVzcy4gKi8K
PiArICAgIHN0cnVjdCBodm1fcGlycV9kcGNpICpwZW5kaW5nX3BpcnFfZHBjaTsKPiAgIH07Cj4K
PiAgIC8qIE1hY2hpbmUgSVJRIHRvIGd1ZXN0IGRldmljZS9pbnR4IG1hcHBpbmcuICovCj4KPgoK
CgoKQW1hem9uIERldmVsb3BtZW50IENlbnRlciBHZXJtYW55IEdtYkgKS3JhdXNlbnN0ci4gMzgK
MTAxMTcgQmVybGluCkdlc2NoYWVmdHNmdWVocnVuZzogQ2hyaXN0aWFuIFNjaGxhZWdlciwgSm9u
YXRoYW4gV2Vpc3MKRWluZ2V0cmFnZW4gYW0gQW10c2dlcmljaHQgQ2hhcmxvdHRlbmJ1cmcgdW50
ZXIgSFJCIDE0OTE3MyBCClNpdHo6IEJlcmxpbgpVc3QtSUQ6IERFIDI4OSAyMzcgODc5CgoK



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 12:18:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 12:18:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTPCB-0001gk-K0; Tue, 28 Apr 2020 12:18:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTPC9-0001gf-ST
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 12:18:37 +0000
X-Inumbo-ID: 62d50170-894a-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 62d50170-894a-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 12:18:37 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 50CE4AC5F;
 Tue, 28 Apr 2020 12:18:35 +0000 (UTC)
Subject: Re: [PATCH v4] x86: irq: Do not BUG_ON multiple unbind calls for
 shared pirqs
To: vrd@amazon.com
References: <20200306160254.8465-1-paul@xen.org>
 <58f00871-2fff-be69-299e-e2b9911e0723@suse.com>
 <000301d5f63a$df5f04a0$9e1d0de0$@xen.org>
 <0648e7ac-f5d7-4207-e2c6-8418681cca13@suse.com>
 <8bcd4d23-cb03-bb3e-360e-4213cd2d7b49@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e69ea420-d32d-0c6b-5bb8-e02f750bc11e@suse.com>
Date: Tue, 28 Apr 2020 14:18:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <8bcd4d23-cb03-bb3e-360e-4213cd2d7b49@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Julien Grall' <julien@xen.org>, paul@xen.org,
 'Andrew Cooper' <andrew.cooper3@citrix.com>, 'Varad Gautam' <vrd@amazon.de>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?B?J1JvZ2VyIFBhdSBNb25uw6kn?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.2020 13:58, vrd@amazon.com wrote:
> On 3/10/20 3:19 PM, Jan Beulich wrote:
>> On 09.03.2020 18:47, Paul Durrant wrote:
>>> Please suggest code if you think it ought to be done differentely. I tried.
>> How about this? It's admittedly more code, but imo less ad hoc.
>> I've smoke tested it, but I depend on you or Varad to check that
>> it actually addresses the reported issue.
>>
>> Jan
>>
>> x86/pass-through: avoid double IRQ unbind during domain cleanup
> 
> 
> I have tested that this patch prevents __pirq_guest_unbind on an already-unbound pirq
> during the continuation call for domain_kill -ERESTART, by using a modified xen that
> forces an -ERESTART from pirq_guest_unbind to create the continuation. It fixes the
> underlying issue.
> 
> Tested-by: Varad Gautam <vrd@amazon.de>

Thanks much; I'll formally submit the patch then.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 12:21:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 12:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTPFJ-0002Wd-38; Tue, 28 Apr 2020 12:21:53 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTPFH-0002WW-Ia
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 12:21:51 +0000
X-Inumbo-ID: d659f13d-894a-11ea-9851-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d659f13d-894a-11ea-9851-12813bfff9fa;
 Tue, 28 Apr 2020 12:21:51 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 360C1ABC2;
 Tue, 28 Apr 2020 12:21:49 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86/pass-through: avoid double IRQ unbind during domain
 cleanup
Message-ID: <6fddc420-b582-cb2f-92ce-b3e067c420c4@suse.com>
Date: Tue, 28 Apr 2020 14:21:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Varad Gautam <vrd@amazon.de>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTs.
In that scenario, it is possible to receive multiple _pirq_guest_unbind
calls for the same pirq from domain_kill, if the pirq has not yet been
removed from the domain's pirq_tree, as:
  domain_kill()
    -> domain_relinquish_resources()
      -> pci_release_devices()
        -> pci_clean_dpci_irq()
          -> pirq_guest_unbind()
            -> __pirq_guest_unbind()

Avoid recurring invocations of pirq_guest_unbind() by removing the pIRQ
from the tree being iterated after the first call there. In case such a
removed entry still has a softirq outstanding, record it and re-check
upon re-invocation.

Reported-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Varad Gautam <vrd@amazon.de>

--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1323,7 +1323,7 @@ void (pirq_cleanup_check)(struct pirq *p
     }
 
     if ( radix_tree_delete(&d->pirq_tree, pirq->pirq) != pirq )
-        BUG();
+        BUG_ON(!d->is_dying);
 }
 
 /* Flush all ready EOIs from the top of this CPU's pending-EOI stack. */
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -873,7 +873,14 @@ static int pci_clean_dpci_irq(struct dom
         xfree(digl);
     }
 
-    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
+    radix_tree_delete(&d->pirq_tree, dpci_pirq(pirq_dpci)->pirq);
+
+    if ( !pt_pirq_softirq_active(pirq_dpci) )
+        return 0;
+
+    domain_get_irq_dpci(d)->pending_pirq_dpci = pirq_dpci;
+
+    return -ERESTART;
 }
 
 static int pci_clean_dpci_irqs(struct domain *d)
@@ -890,8 +897,18 @@ static int pci_clean_dpci_irqs(struct do
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+        int ret = 0;
+
+        if ( hvm_irq_dpci->pending_pirq_dpci )
+        {
+            if ( pt_pirq_softirq_active(hvm_irq_dpci->pending_pirq_dpci) )
+                 ret = -ERESTART;
+            else
+                 hvm_irq_dpci->pending_pirq_dpci = NULL;
+        }
 
+        if ( !ret )
+            ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
         if ( ret )
         {
             spin_unlock(&d->event_lock);
--- a/xen/include/asm-x86/hvm/irq.h
+++ b/xen/include/asm-x86/hvm/irq.h
@@ -158,6 +158,8 @@ struct hvm_irq_dpci {
     DECLARE_BITMAP(isairq_map, NR_ISAIRQS);
     /* Record of mapped Links */
     uint8_t link_cnt[NR_LINK];
+    /* Clean up: Entry with a softirq invocation pending / in progress. */
+    struct hvm_pirq_dpci *pending_pirq_dpci;
 };
 
 /* Machine IRQ to guest device/intx mapping. */


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 12:31:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 12:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTPOu-0003VR-1a; Tue, 28 Apr 2020 12:31:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTPOs-0003VM-VF
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 12:31:47 +0000
X-Inumbo-ID: 39246530-894c-11ea-b9cf-bc764e2007e4
Received: from mail-wr1-x42d.google.com (unknown [2a00:1450:4864:20::42d])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 39246530-894c-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 12:31:46 +0000 (UTC)
Received: by mail-wr1-x42d.google.com with SMTP id s10so24459478wrr.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 05:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=Y/c/NzUHCK2f/tJUzdiFamW51J/iCZVsYfpiawOF+c4=;
 b=Q9BOqfd2htbpyscDLSZMMqaPOVH1g9dEt2nOgCWr2XAZ6IXZdM1E90C//+qoPdiRGK
 MXN1sCq2xBaBOm5BBayW5kMTY1Lw1loXfYkO5ya1e+f8tmjjNPE+Cbe2RLW4lWjOJlYF
 68CY4Yh5lpTFd+tyME80ov8TyZLnuXS0GDK480bOUv0Uynr+3YLmZRoD9ns9A3YbwEr/
 +XqIirRlm/nWLLgf1K6mcMy/HP67lHCL0IJ8v6fZoUHkz8kF/+Bq8zEhXU+cGdr3ONMx
 lLYUUOq52d6Y2AChgT5JNvQaP2k44f6S4dIdT/kZ5fQw9uGVO7drfmp2O/5blPO9zPmg
 6ggw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=Y/c/NzUHCK2f/tJUzdiFamW51J/iCZVsYfpiawOF+c4=;
 b=GFztkuAaot6xUQFJXInmGp+zZqx0R2ltY4rryxUa+rWsdG3y2JMCMQRRzkr/mmxkvv
 y8dKt5UFkZZsYy7BrKHemYcPmmB4tDyMqGg2kw/ZsnHnU7qVs7mhc9xvZGduQ8E2ChSh
 8z9bjZLrjiT3IBaRCf/19lZRSlbivbS3+NVCc1/CXg9GOdwn48Cyo5GjKSJmRgt77P7l
 drEeZoMJ5HMUIrGj+slynl9EVAd4TtUyCcmi9/3cY3RjT2xv6rp9uN0AqKWeXusjYEkT
 G3lJW1u7qiiX5FuCq4J9cWNU/c64jEC+S2OOLHvtyiSYoTwJx+AXTAv6sSlxghuSz5VM
 vq7w==
X-Gm-Message-State: AGi0Puar+6QjhgYaYZgS4gv9Gwy6g/vTjeQxfCM2e1dtVH5zy9XAL9Ym
 F8aWA0jVdD/tF/bwFGonCnM=
X-Google-Smtp-Source: APiQypL7A0BiNYtq7xE29+cCkkSBWdgJkXVffi0DcJYd7lVnkeMcPcoBerYXdX9cjjB/DxUWRk4wpQ==
X-Received: by 2002:adf:db41:: with SMTP id f1mr31359840wrj.13.1588077105429; 
 Tue, 28 Apr 2020 05:31:45 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id s14sm3274430wme.33.2020.04.28.05.31.44
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 05:31:44 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>,
	<xen-devel@lists.xenproject.org>
References: <6fddc420-b582-cb2f-92ce-b3e067c420c4@suse.com>
In-Reply-To: <6fddc420-b582-cb2f-92ce-b3e067c420c4@suse.com>
Subject: RE: [PATCH] x86/pass-through: avoid double IRQ unbind during domain
 cleanup
Date: Tue, 28 Apr 2020 13:31:43 +0100
Message-ID: <000801d61d58$fa4c4bc0$eee4e340$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQEjcmVwjE85LwcvcW4bMeoM9/PKGKnzzLaQ
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Andrew Cooper' <andrew.cooper3@citrix.com>, 'Varad Gautam' <vrd@amazon.de>,
 'Wei Liu' <wl@xen.org>,
 =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 28 April 2020 13:22
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant <paul@xen.org>; Varad Gautam <vrd@amazon.de>; Andrew =
Cooper
> <andrew.cooper3@citrix.com>; Roger Pau Monn=C3=A9 =
<roger.pau@citrix.com>; Wei Liu <wl@xen.org>
> Subject: [PATCH] x86/pass-through: avoid double IRQ unbind during =
domain cleanup
>=20
> XEN_DOMCTL_destroydomain creates a continuation if domain_kill =
-ERESTARTs.
> In that scenario, it is possible to receive multiple =
_pirq_guest_unbind
> calls for the same pirq from domain_kill, if the pirq has not yet been
> removed from the domain's pirq_tree, as:
>   domain_kill()
>     -> domain_relinquish_resources()
>       -> pci_release_devices()
>         -> pci_clean_dpci_irq()
>           -> pirq_guest_unbind()
>             -> __pirq_guest_unbind()
>=20
> Avoid recurring invocations of pirq_guest_unbind() by removing the =
pIRQ
> from the tree being iterated after the first call there. In case such =
a
> removed entry still has a softirq outstanding, record it and re-check
> upon re-invocation.
>=20
> Reported-by: Varad Gautam <vrd@amazon.de>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Varad Gautam <vrd@amazon.de>

Reviewed-by: Paul Durrant <paul@xen.org>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 12:32:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 12:32:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTPPt-0003ZI-BU; Tue, 28 Apr 2020 12:32:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTPPs-0003Z9-95
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 12:32:48 +0000
X-Inumbo-ID: 5dbdd28c-894c-11ea-ae69-bc764e2007e4
Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5dbdd28c-894c-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 12:32:47 +0000 (UTC)
Received: by mail-wr1-x441.google.com with SMTP id j1so24451672wrt.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 05:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=m6zv80HQf6wTcYQSdLFqcBDzcXmAOK9wtyk4ase4ObY=;
 b=UYkOlWR7pmh9AitmIVOtSNLHPamv1uvz2vG8OGwJCys6mr5J5au5MGwKWkJUUdByz+
 TdH6xseGDAuMaBCR3mP6ZVDWTih1nJNteqk0YAhU4KWnCd2vf5Jby+NRPtw8aZKzFDJv
 2NCxN8zCzpg7UAA+qRKzQGOlzWLdc3LE2grMIoEicWDfRMNsAtPYR3t2Ac7fFq5yWHnZ
 AjJJX6IDkGYXwzHpxdK5EaxeAtNK6J05O3OMbzNlcV6x8yVEAnFw+P1EijYYRwwQ4aEi
 O2JtYP086wTMIqMDWHqgtCbVwKDTj++PbfqsBl6YcM/De/CEGuurUx4grLlLp7wy5uVB
 ou9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=m6zv80HQf6wTcYQSdLFqcBDzcXmAOK9wtyk4ase4ObY=;
 b=KgnslLPiA5GIgGiFg8J3N2l50LRtzw1XKE0D6ZrDpTuD2uueimnfUJayP9vezx7g6W
 eupAXxspMm9LJwdxpynNKupUPWB3Iko+V8Fd8vH9veMVF1UdwYxKN15H3gm5ZToOxPQ0
 D80gI1Gm00Yy8YTaQVo0wCr7XCoEgNwmoaG0D3AY8ldW4ooln7qWEF3I/XZls4faghXH
 pDS09x7B+C6ZQ870ljw3h6LBIbngGir8C9ht0H3gWVn6xVSJUL7B1juaftTZ6SKvu9Zd
 du3/K81SxWY381LouyJYhChHqDsWNrxL5Mdk0BAevA7mrV3eJbfDf/Wgy58YFlNWOWqQ
 +KPg==
X-Gm-Message-State: AGi0Pub+qAm/fSNCaq1c1w9J02DL/9LUjk217mPH8fYl8fXk11GjXE+D
 y1mZcHVSiRJqKPkVp3XDLfw=
X-Google-Smtp-Source: APiQypI7gTYIM6odIWFB8N/KeFsoFgmr4S2wZyu5Gyw0XqI1rYMkdIh9CrcJhU1Y0HSwF5rnO2i7ZQ==
X-Received: by 2002:a05:6000:110a:: with SMTP id
 z10mr32848766wrw.389.1588077166799; 
 Tue, 28 Apr 2020 05:32:46 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id t16sm3069026wmi.27.2020.04.28.05.32.45
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 05:32:46 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Artur Puzio'" <artur@puzio.waw.pl>,
 "'Grzegorz Uriasz'" <gorbak25@gmail.com>, <qemu-devel@nongnu.org>
References: <20200428062847.7764-1-gorbak25@gmail.com>
 <20200428062847.7764-2-gorbak25@gmail.com>
 <000001d61d34$6c0218f0$44064ad0$@xen.org>
 <90a8b709-c506-92e2-800c-e1558f18df94@puzio.waw.pl>
In-Reply-To: <90a8b709-c506-92e2-800c-e1558f18df94@puzio.waw.pl>
Subject: RE: [PATCH 1/2] Fix undefined behaviour
Date: Tue, 28 Apr 2020 13:32:44 +0100
Message-ID: <000901d61d59$1edbe270$5c93a750$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJZJJhe4DhOB0QFT+Ee5i7aNCDcTgF4qWDWAdBYvl8CjAnLpqdZwHhQ
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, 'Anthony Perard' <anthony.perard@citrix.com>,
 j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Artur Puzio <artur@puzio.waw.pl>
> Sent: 28 April 2020 10:41
> To: paul@xen.org; 'Grzegorz Uriasz' <gorbak25@gmail.com>; qemu-devel@nongnu.org
> Cc: marmarek@invisiblethingslab.com; jakub@bartmin.ski; j.nowak26@student.uw.edu.pl; 'Stefano
> Stabellini' <sstabellini@kernel.org>; 'Anthony Perard' <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org
> Subject: Re: [PATCH 1/2] Fix undefined behaviour
> 
> On 28.04.2020 10:10, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Grzegorz Uriasz <gorbak25@gmail.com>
> >> Sent: 28 April 2020 07:29
> >> To: qemu-devel@nongnu.org
> >> Cc: Grzegorz Uriasz <gorbak25@gmail.com>; marmarek@invisiblethingslab.com; artur@puzio.waw.pl;
> >> jakub@bartmin.ski; j.nowak26@student.uw.edu.pl; Stefano Stabellini <sstabellini@kernel.org>;
> Anthony
> >> Perard <anthony.perard@citrix.com>; Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> >> Subject: [PATCH 1/2] Fix undefined behaviour
> >>
> >> Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>
> > I think we need more of a commit comment for both this and patch #2 to explain why you are making
> the changes.
> >
> >   Paul
> 
> I agree Grzegorz should improve the commit messages. In the mean time
> see email with subject "[PATCH 0/2] Fix QEMU crashes when passing IGD to
> a guest VM under XEN", it contains quite detailed explanation for both
> "Fix undefined behaviour" and "Improve legacy vbios handling" patches.
> 

Ok. Can you please make sure maintainers are cc-ed on patch #0 too.

  Paul



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 12:33:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 12:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTPQa-0003g8-LE; Tue, 28 Apr 2020 12:33:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTPQZ-0003g1-DD
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 12:33:31 +0000
X-Inumbo-ID: 776bcf54-894c-11ea-9887-bc764e2007e4
Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 776bcf54-894c-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 12:33:30 +0000 (UTC)
Received: by mail-wm1-x342.google.com with SMTP id u127so2670156wmg.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 05:33:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=xS+yLt7ge8xiOU6IbkcdYZBC50HgTxf9aJlIZ1nJYHo=;
 b=pwXMbRm965oGRSmqS9QK6ybMcOArhlrKCxr6DUbrardiaOo/WWT13yRtOgrbRol+zY
 fl8GqfcIV7wsXMVM2uX8XxUhi6emqs5bILfBJklf0XHrf6fGiM0qLEMoQjZbhevdJqaG
 cYmuGk2qAPtONV4+MKK5x6/G5G5S0wXtp9OmXak/eWwzEldSUyWK+7tPMy5NcYw6HwVZ
 0Ije/o8dTJ3zSrPQtcEdse7cXhCTxrL280SYxqoHc+kruGRkU1aS3vugv/5KYAfu17Pc
 eidJoS07uuovyaJnoVWpW2pEV82hHKTKCFg4O5mDl/50yPoOkje/1qiQFdzgtpGJX1Yh
 Rung==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=xS+yLt7ge8xiOU6IbkcdYZBC50HgTxf9aJlIZ1nJYHo=;
 b=uVWaHnIEh1DJ/9HEIcJRgUWjCCU+NTeUEuQl/RHfLBn0DQ6zO2mlOXjwVrvAFWginv
 z9xMLXmI92qiJRamWqJysuRSWHF6pSAFl+aikCPoxgbZ4uvmsyT3GYJSiLHsUrBd0SbP
 lGVXUISeOVmrgI7+3bcOVDZ97EaPEoApeYMd2QHTq9oOnkhGsdr3zzUN3Vnm+Owd++Yi
 RZEqGjWLEtHRqA/CN6HvIUxXUfaOL0uolQLsbGFbeukEx/larU+s+FpG1JFPJL6Cocww
 /6VcTdaKQJi6GHWXvk3/4Wp8xkjPlg0mASCRU4mnMmtpdYReHu8J90sXdqC1noGiq+kP
 V6Qg==
X-Gm-Message-State: AGi0PuZUesC0Zk3skuuTj2wQ40eGkHmoQrPU6b3XFqJu6A/7GSyJpLCc
 imToz1ZwYDzzMtlSI561QW8=
X-Google-Smtp-Source: APiQypJb9wVCnw5brzV8/l7uPCSh68KOalMqsEymBwz9CA88NFzc/Eqb4BKGTikR72h8Jw8/LAix7Q==
X-Received: by 2002:a1c:f609:: with SMTP id w9mr4291826wmc.123.1588077209864; 
 Tue, 28 Apr 2020 05:33:29 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id t67sm3404801wmg.40.2020.04.28.05.33.28
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 05:33:29 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: <paul@xen.org>, "'Artur Puzio'" <artur@puzio.waw.pl>,
 "'Grzegorz Uriasz'" <gorbak25@gmail.com>, <qemu-devel@nongnu.org>
References: <20200428062847.7764-1-gorbak25@gmail.com>
 <20200428062847.7764-2-gorbak25@gmail.com>
 <000001d61d34$6c0218f0$44064ad0$@xen.org>
 <90a8b709-c506-92e2-800c-e1558f18df94@puzio.waw.pl>
 <000901d61d59$1edbe270$5c93a750$@xen.org>
In-Reply-To: <000901d61d59$1edbe270$5c93a750$@xen.org>
Subject: RE: [PATCH 1/2] Fix undefined behaviour
Date: Tue, 28 Apr 2020 13:33:27 +0100
Message-ID: <000a01d61d59$38898600$a99c9200$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJZJJhe4DhOB0QFT+Ee5i7aNCDcTgF4qWDWAdBYvl8CjAnLpgJCzKCMp0eqVnA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, 'Anthony Perard' <anthony.perard@citrix.com>,
 j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Paul Durrant <xadimgnik@gmail.com>
> Sent: 28 April 2020 13:33
> To: 'Artur Puzio' <artur@puzio.waw.pl>; 'Grzegorz Uriasz' <gorbak25@gmail.com>; qemu-devel@nongnu.org
> Cc: marmarek@invisiblethingslab.com; jakub@bartmin.ski; j.nowak26@student.uw.edu.pl; 'Stefano
> Stabellini' <sstabellini@kernel.org>; 'Anthony Perard' <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org
> Subject: RE: [PATCH 1/2] Fix undefined behaviour
> 
> > -----Original Message-----
> > From: Artur Puzio <artur@puzio.waw.pl>
> > Sent: 28 April 2020 10:41
> > To: paul@xen.org; 'Grzegorz Uriasz' <gorbak25@gmail.com>; qemu-devel@nongnu.org
> > Cc: marmarek@invisiblethingslab.com; jakub@bartmin.ski; j.nowak26@student.uw.edu.pl; 'Stefano
> > Stabellini' <sstabellini@kernel.org>; 'Anthony Perard' <anthony.perard@citrix.com>; xen-
> > devel@lists.xenproject.org
> > Subject: Re: [PATCH 1/2] Fix undefined behaviour
> >
> > On 28.04.2020 10:10, Paul Durrant wrote:
> > >> -----Original Message-----
> > >> From: Grzegorz Uriasz <gorbak25@gmail.com>
> > >> Sent: 28 April 2020 07:29
> > >> To: qemu-devel@nongnu.org
> > >> Cc: Grzegorz Uriasz <gorbak25@gmail.com>; marmarek@invisiblethingslab.com; artur@puzio.waw.pl;
> > >> jakub@bartmin.ski; j.nowak26@student.uw.edu.pl; Stefano Stabellini <sstabellini@kernel.org>;
> > Anthony
> > >> Perard <anthony.perard@citrix.com>; Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> > >> Subject: [PATCH 1/2] Fix undefined behaviour
> > >>
> > >> Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>
> > > I think we need more of a commit comment for both this and patch #2 to explain why you are making
> > the changes.
> > >
> > >   Paul
> >
> > I agree Grzegorz should improve the commit messages. In the mean time
> > see email with subject "[PATCH 0/2] Fix QEMU crashes when passing IGD to
> > a guest VM under XEN", it contains quite detailed explanation for both
> > "Fix undefined behaviour" and "Improve legacy vbios handling" patches.
> >
> 
> Ok. Can you please make sure maintainers are cc-ed on patch #0 too.
> 

Actually they are, sorry. My MUA is playing tricks on me.

  Paul



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 12:46:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 12:46:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTPcw-0004k6-SY; Tue, 28 Apr 2020 12:46:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTPcv-0004k1-5G
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 12:46:17 +0000
X-Inumbo-ID: 3fb9b966-894e-11ea-9887-bc764e2007e4
Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3fb9b966-894e-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 12:46:16 +0000 (UTC)
Received: by mail-wr1-x442.google.com with SMTP id d15so22863653wrx.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 05:46:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=ZF6X9MK9bnvI26djs/DVkR1dePxmQfXjJO91jKtNZaI=;
 b=MuEVij+ATJixfr7xYv3LAxQTZSxAP48f2SHI09pHWjB8Y5AWPgaUwoJ952vQ6As0WR
 JN7gu7BAslSh2L4jar7GXXldIgPe+qoQlUItgpmnjBGYBKWJPvHrfH1lHqXvn57rojal
 YJvUsyudiVLtE2x2iQw36f/xzkIzSJNjUEsd90XqBbvcCE346PIAnL73H0Twg5dky9LE
 YPPjoeecWXSyYa5MnjPHp9OK/cegVto+ISB7WX0lRqTjhYmo7eBe2bLZrdMONizOw9eI
 e1BfNjZXnReQattnZI/8vJ216oFyHHmoFXZ5JY64FQ150sidvJ5w5D69JduIa+IfgUOZ
 E6YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=ZF6X9MK9bnvI26djs/DVkR1dePxmQfXjJO91jKtNZaI=;
 b=N8AUA5R+EsjthW008JMN2I7XwD0MWZ0FI4aDrxH7GsW9ADZx0nbztiveUE5cghugiU
 beCulDgXGSmOGMspv8GrS3p9ahYvZVygam9A00tV5l6rARO2yTQLGH2pJ0NsZ1nQ4m15
 tHF/jKzoioVcGnVYbKYKGqrpO/9cOBTouwp/4ESEh/oGVzaS949ezwu//lSHinYHRQ4B
 1l491F5Vyi/osG5Xk4tbd19aDYtHXb/HRpN/elAu3fhjV5X086rr9ANlcZwXuw9kR6pj
 lSc1MpDnn8iiZji6pV64inTOnAAfgGZ5DGEnAw3x6m07ScBII6DcIAKoF9YorksE9BIh
 p0ug==
X-Gm-Message-State: AGi0PuZh+s7+CtBin1lnqSKianBvFIq9ntXDfmsP/GvhM3dAPnS0XL7T
 E9m6uItgUQfatAeXIIzyWJo=
X-Google-Smtp-Source: APiQypJ+u2WXmP+PC2RK+xFrWRwLTUQ7Pgj/tubCq2+LXb16T0NOIoc4iw3xLO1SwnfPE2LvWareYw==
X-Received: by 2002:a05:6000:12c5:: with SMTP id
 l5mr34127675wrx.185.1588077975432; 
 Tue, 28 Apr 2020 05:46:15 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id r2sm3273942wmg.2.2020.04.28.05.46.13
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 05:46:14 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
 =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= <jgross@suse.com>,
 <xen-devel@lists.xenproject.org>
References: <20200427155035.668-1-paul@xen.org>
 <7ab25832-66e6-020f-b343-059f21771054@xen.org>
 <f13de8bc-ca5d-2341-3797-b34f9f2c70ef@suse.com>
 <2087b3dd-7d2c-3ab3-d6ce-a4d132f7ec4d@xen.org>
In-Reply-To: <2087b3dd-7d2c-3ab3-d6ce-a4d132f7ec4d@xen.org>
Subject: RE: [PATCH v4] docs/designs: re-work the xenstore migration
 document...
Date: Tue, 28 Apr 2020 13:46:12 +0100
Message-ID: <000c01d61d5b$00bc05c0$02341140$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQHlntLxHS5TXNWYohOpoPk3VAlj7gIKOtGYAd6p4dIC8EMlIKg4raFw
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 28 April 2020 11:23
> To: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>; Paul Durrant =
<paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Paul Durrant <pdurrant@amazon.com>; Andrew Cooper =
<andrew.cooper3@citrix.com>; George Dunlap
> <george.dunlap@citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; =
Jan Beulich <jbeulich@suse.com>;
> Stefano Stabellini <sstabellini@kernel.org>; Wei Liu <wl@xen.org>
> Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration =
document...
>=20
> Hi Juergen,
>=20
> On 28/04/2020 11:10, J=C3=BCrgen Gro=C3=9F wrote:
> > On 28.04.20 11:05, Julien Grall wrote:
> >>> -where tx_id is the non-zero identifier values of an open =
transaction.
> >>> +| Field     | Description                                       |
> >>> +|-----------|---------------------------------------------------|
> >>> +| `domid`   | The domain-id that owns the shared page           |
> >>> +|           |                                                   |
> >>> +| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
> >>> +|           | it has been subject to an SET_TARGET              |
> >>> +|           | operation [2] or DOMID_INVALID [3] otherwise      |
> >>> +|           |                                                   |
> >>> +| `flags`   | Must be zero                                      |
> >>> +|           |                                                   |
> >>> +| `evtchn`  | The port number of the interdomain channel used   |
> >>> +|           | by `domid` to communicate with xenstored          |
> >>> +|           |                                                   |
> >>> +| `mfn`     | The MFN of the shared page for a live update or   |
> >>> +|           | ~0 (i.e. all bits set) otherwise                  |
> >>> -### Protocol Extension
> >>> +Since the ABI guarantees that entry 1 in `domid`'s grant table =
will
> >>> always
> >>> +contain the GFN of the shared page, so for a live update `mfn` =
can
> >>> be used to
> >>> +give confidence that `domid` has not been re-cycled during the =
update.
> >>
> >> I am confused, there is no way a XenStored running in an Arm domain
> >> can map the MFN of the shared page. So how is this going to work =
out?
> >
> > I guess this will be a MFN for PV guests and a guest PFN else.
>=20
> If we use Xen terminology (xen/include/xen/mm.h), this would be a GFN.
>=20

TBH I'm not sure a GFN would give much confidence about domain recycling =
as it would likely be the same for many domains, I think. We really need =
a UUID.

> >
> >>
> >> [...]
> >>
> >>> -START_DOMAIN_TRANSACTION    <domid>|<transid>|
> >>> +    0       1       2       3    octet
> >>> ++-------+-------+-------+-------+
> >>> +| conn-id                       |
> >>> ++-------------------------------+
> >>> +| tx-id                         |
> >>> ++---------------+---------------+
> >>> +| path-len      | value-len     |
> >>> ++---------------+---------------+
> >>> +| access        | perm-count    |
> >>> ++---------------+---------------+
> >>> +| perm1                         |
> >>> ++-------------------------------+
> >>> +...
> >>> ++-------------------------------+
> >>> +| permN                         |
> >>> ++---------------+---------------+
> >>> +| path
> >>> +...
> >>> +| value
> >>> +...
> >>> +```
> >>> +
> >>> +
> >>> +| Field        | Description                                    |
> >>> +|--------------|------------------------------------------------|
> >>> +| `conn-id`    | If this value is non-zero then this record     |
> >>> +|              | related to a pending transaction               |
> >>
> >> If conn-id is 0, how do you know the owner of the node?
> >
> > The first permission entry's domid is the owner.
>=20
> I think this should be spell out in the specification.
>=20

In xenstore.txt, there is a reference to =
https://wiki.xen.org/wiki/XenBus

This explains things reasonably well; I'll reference it here and add =
some words too.

  Paul



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 12:47:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 12:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTPeF-0004q9-C9; Tue, 28 Apr 2020 12:47:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTPeE-0004q3-W9
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 12:47:39 +0000
X-Inumbo-ID: 7085517c-894e-11ea-9887-bc764e2007e4
Received: from mail-wr1-x42c.google.com (unknown [2a00:1450:4864:20::42c])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7085517c-894e-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 12:47:38 +0000 (UTC)
Received: by mail-wr1-x42c.google.com with SMTP id t14so24464179wrw.12
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 05:47:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=ErEIyyQ3V6iE5U/AwpRS3bONjYKSX3eqDWb2d89ylxw=;
 b=aFDLNzyHZomn8Opz5BPVWSnjkaJlxp+Jyu/sfIQVpAkGWPYIMBAig+lyl68dlOzb72
 1nS1wMayIESUT4CIoh0YdRi7wlpi9yG6sezRAeSeRWahjLNs3rC/Ki42UCXzIPWLJUNs
 j3p+ULk5n6m1O3dNtif4Rsw/zEC+hM1qemKCFU1f9FWDpWx4sCPakUKwI0iWaoSdfmUK
 mu7NgrYvancBJ0lkAGFNfB1vOfoa3FiWgGHDhucuNdkQJWlcztQSKh6Ual2Q33ZQ1mYt
 /crfBjKybFJZPIHcJRl/lfWrc1UzV6ENnWacYY/S6ibCiPQ7ZS51bX8hYNI76jBJ/Xhx
 zl+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=ErEIyyQ3V6iE5U/AwpRS3bONjYKSX3eqDWb2d89ylxw=;
 b=c6sl59PL3eNZfIhuyX15y6dpCaF5dk3AFAB1bxb7tbzd2wPKb6eGbUGwU2G0EcBE6/
 qQbm1vkTRfBX9quvg5pqUxWzsunzl6SOYkTidbDV05dkNjYUkDUjZdddRzATTeQzwKOU
 h3ADVrclzodNmIGiZ0KWdv660Kaq6rs/rCCls7pkYDuCtEvoW1mqILwyl18/MVtCr4F2
 5FAGaqfLupMDlln8C6Q0rBHnsuMjJFOJG6VrMwHZcUU97eH5Pr2oJMzED8UxwcCM+z+u
 ivjwUVXH2c0Ex767npaC2JNeqvKlXuaTQXkSR7GkhkMBYfrBngB0kcSvNeBanDyxX5B4
 Zn1g==
X-Gm-Message-State: AGi0PuYsxNzWRk/g19xvwVzg0qCgH3mis2WxVDZO7dEDHtcv7KRFwjK7
 JILgTRtohOenA+e+41U4KuC7tuF5qkQ=
X-Google-Smtp-Source: APiQypJwaDPzJSwNiojSVsXMNm1mIEx5K60/rDf4rOOVASKHNckbaXYfreQdnSiGIrVEUa7lzBKiMg==
X-Received: by 2002:adf:cd12:: with SMTP id w18mr33524978wrm.177.1588078057315; 
 Tue, 28 Apr 2020 05:47:37 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id a10sm14694519wrg.32.2020.04.28.05.47.35
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 05:47:36 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200427155035.668-1-paul@xen.org>
 <7ab25832-66e6-020f-b343-059f21771054@xen.org>
In-Reply-To: <7ab25832-66e6-020f-b343-059f21771054@xen.org>
Subject: RE: [PATCH v4] docs/designs: re-work the xenstore migration
 document...
Date: Tue, 28 Apr 2020 13:47:35 +0100
Message-ID: <000d01d61d5b$31b6c7a0$952456e0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQHlntLxHS5TXNWYohOpoPk3VAlj7gIKOtGYqF8j1wA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Juergen Gross' <jgross@suse.com>,
 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 28 April 2020 10:06
> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Paul Durrant <pdurrant@amazon.com>; Juergen Gross <jgross@suse.com>; Andrew Cooper
> <andrew.cooper3@citrix.com>; George Dunlap <george.dunlap@citrix.com>; Ian Jackson
> <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>; Stefano Stabellini
> <sstabellini@kernel.org>; Wei Liu <wl@xen.org>
> Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration document...
> 
> Hi Paul,
> 
> On 27/04/2020 16:50, Paul Durrant wrote:
> > diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
> > index 6ab351e8fe..51d8b85171 100644
> > --- a/docs/designs/xenstore-migration.md
> > +++ b/docs/designs/xenstore-migration.md
> > @@ -3,254 +3,400 @@
> >   ## Background
> >
> >   The design for *Non-Cooperative Migration of Guests*[1] explains that extra
> > -save records are required in the migrations stream to allow a guest running
> > -PV drivers to be migrated without its co-operation. Moreover the save
> > -records must include details of registered xenstore watches as well as
> > -content; information that cannot currently be recovered from `xenstored`,
> > -and hence some extension to the xenstore protocol[2] will also be required.
> > -
> > -The *libxenlight Domain Image Format* specification[3] already defines a
> > -record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
> > -transferring xenstore data pertaining to the domain directly as it is
> > -specified such that keys are relative to the path
> > -`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
> > -define at least one new save record type.
> > +save records are required in the migrations stream to allow a guest running PV
> > +drivers to be migrated without its co-operation. Moreover the save records must
> > +include details of registered xenstore watches as well ascontent; information
> 
> s/ascontent/as content/
> 

Oh yes.

> [...]
> 
> > +### END
> > +
> > +The end record marks the end of the image, and is the final record
> > +in the stream.
> >
> >   ```
> > -    0       1       2       3     octet
> > -+-------+-------+-------+-------+
> > -| NODE_DATA                     |
> > -+-------------------------------+
> > -| path length                   |
> > -+-------------------------------+
> > -| path data                     |
> > -...
> > -| pad (0 to 3 octets)           |
> > -+-------------------------------+
> > -| perm count (N)                |
> > -+-------------------------------+
> > -| perm0                         |
> > -+-------------------------------+
> > -...
> > -+-------------------------------+
> > -| permN                         |
> > -+-------------------------------+
> > -| value length                  |
> > -+-------------------------------+
> > -| value data                    |
> > -...
> > -| pad (0 to 3 octets)           |
> > -+-------------------------------+
> > +    0       1       2       3       4       5       6       7    octet
> > ++-------+-------+-------+-------+-------+-------+-------+-------+
> >   ```
> >
> > -where perm0..N are formatted as follows:
> >
> > +The end record contains no fields; its body length is 0.
> > +
> > +\pagebreak
> > +
> > +### GLOBAL_DATA
> > +
> > +This record is only relevant for live update. It contains details of global
> > +xenstored state that needs to be restored.
> 
> Reading this paragraph, it sounds like GLOBAL_DATA should always be
> present in the liveupdate stream. However ...
> 
> [...]
> 
> > -path length and value length are specified in octets (excluding the NUL
> > -terminator of the path). perm should be one of the ASCII values `w`, `r`,
> > -`b` or `n` as described in [2]. All pad values should be 0.
> > -All paths should be absolute (i.e. start with `/`) and as described in
> > -[2].
> > +| Field          | Description                                  |
> > +|----------------|----------------------------------------------|
> > +| `rw-socket-fd` | The file descriptor of the socket accepting  |
> > +|                | read-write connections                       |
> > +|                |                                              |
> > +| `ro-socket-fd` | The file descriptor of the socket accepting  |
> > +|                | read-only connections                        |
> >
> > +xenstored will resume in the original process context. Hence `rw-socket-fd` and
> > +`ro-socket-fd` simply specify the file descriptors of the sockets.
> 
> ... sockets may not always be available in XenStored. So should we
> reserve a value for "not in-use socket"?
> 

Ok.

> [...]
> 
> > -wpath length and token length are specified in octets (excluding the NUL
> > -terminator). The wpath should be as described for the `WATCH` operation in
> > -[2]. The token is an arbitrary string of octets not containing any NUL
> > -values.
> >
> > +| Field       | Description                                     |
> > +|-------------|-------------------------------------------------|
> > +| `conn-id`   | A non-zero number used to identify this         |
> > +|             | connection in subsequent connection-specific    |
> > +|             | records                                         |
> > +|             |                                                 |
> > +| `conn-type` | 0x0000: shared ring                             |
> > +|             | 0x0001: socket                                  |
> 
> I would write "0x0002 - 0xFFFF: reserved for future use" to match the
> rest of the specification.
> 

Ok.

  Paul




From xen-devel-bounces@lists.xenproject.org Tue Apr 28 12:56:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 12:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTPmT-0005q3-8s; Tue, 28 Apr 2020 12:56:09 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=DYx7=6M=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTPmR-0005py-TM
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 12:56:07 +0000
X-Inumbo-ID: 9f994ee0-894f-11ea-9854-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9f994ee0-894f-11ea-9854-12813bfff9fa;
 Tue, 28 Apr 2020 12:56:06 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6534DAC6C;
 Tue, 28 Apr 2020 12:56:04 +0000 (UTC)
Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration
 document...
To: paul@xen.org, 'Julien Grall' <julien@xen.org>,
 xen-devel@lists.xenproject.org
References: <20200427155035.668-1-paul@xen.org>
 <7ab25832-66e6-020f-b343-059f21771054@xen.org>
 <f13de8bc-ca5d-2341-3797-b34f9f2c70ef@suse.com>
 <2087b3dd-7d2c-3ab3-d6ce-a4d132f7ec4d@xen.org>
 <000c01d61d5b$00bc05c0$02341140$@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <bb0a87e5-4112-107a-b15b-0edf1e616f87@suse.com>
Date: Tue, 28 Apr 2020 14:56:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <000c01d61d5b$00bc05c0$02341140$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.20 14:46, Paul Durrant wrote:
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Sent: 28 April 2020 11:23
>> To: Jürgen Groß <jgross@suse.com>; Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
>> Cc: Paul Durrant <pdurrant@amazon.com>; Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap
>> <george.dunlap@citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>;
>> Stefano Stabellini <sstabellini@kernel.org>; Wei Liu <wl@xen.org>
>> Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration document...
>>
>> Hi Juergen,
>>
>> On 28/04/2020 11:10, Jürgen Groß wrote:
>>> On 28.04.20 11:05, Julien Grall wrote:
>>>>> -where tx_id is the non-zero identifier values of an open transaction.
>>>>> +| Field     | Description                                       |
>>>>> +|-----------|---------------------------------------------------|
>>>>> +| `domid`   | The domain-id that owns the shared page           |
>>>>> +|           |                                                   |
>>>>> +| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
>>>>> +|           | it has been subject to an SET_TARGET              |
>>>>> +|           | operation [2] or DOMID_INVALID [3] otherwise      |
>>>>> +|           |                                                   |
>>>>> +| `flags`   | Must be zero                                      |
>>>>> +|           |                                                   |
>>>>> +| `evtchn`  | The port number of the interdomain channel used   |
>>>>> +|           | by `domid` to communicate with xenstored          |
>>>>> +|           |                                                   |
>>>>> +| `mfn`     | The MFN of the shared page for a live update or   |
>>>>> +|           | ~0 (i.e. all bits set) otherwise                  |
>>>>> -### Protocol Extension
>>>>> +Since the ABI guarantees that entry 1 in `domid`'s grant table will
>>>>> always
>>>>> +contain the GFN of the shared page, so for a live update `mfn` can
>>>>> be used to
>>>>> +give confidence that `domid` has not been re-cycled during the update.
>>>>
>>>> I am confused, there is no way a XenStored running in an Arm domain
>>>> can map the MFN of the shared page. So how is this going to work out?
>>>
>>> I guess this will be a MFN for PV guests and a guest PFN else.
>>
>> If we use Xen terminology (xen/include/xen/mm.h), this would be a GFN.
>>
> 
> TBH I'm not sure a GFN would give much confidence about domain recycling as it would likely be the same for many domains, I think. We really need a UUID.

No, we need a per-host domain value, which is associated with a domain
and which is unique during the life-time of the host.

E.g. a global counter, which is incremented at each domain creation and
stored in struct domain.


Juergen


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 12:59:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 12:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTPq0-0005z3-PQ; Tue, 28 Apr 2020 12:59:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTPpz-0005yy-Uk
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 12:59:47 +0000
X-Inumbo-ID: 22f8b85c-8950-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 22f8b85c-8950-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 12:59:47 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 74E15AE8A;
 Tue, 28 Apr 2020 12:59:45 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] PCI: drop a redundant variable from pci_add_device()
Message-ID: <75d1c852-e6ea-d3f3-3624-c77fb678412a@suse.com>
Date: Tue, 28 Apr 2020 14:59:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Surrounding code already uses the available alternative, after all.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -760,7 +760,6 @@ int pci_add_device(u16 seg, u8 bus, u8 d
             {
                 unsigned int idx = pos + PCI_SRIOV_BAR + i * 4;
                 uint32_t bar = pci_conf_read32(pdev->sbdf, idx);
-                pci_sbdf_t sbdf = PCI_SBDF3(seg, bus, devfn);
 
                 if ( (bar & PCI_BASE_ADDRESS_SPACE) ==
                      PCI_BASE_ADDRESS_SPACE_IO )
@@ -771,7 +770,8 @@ int pci_add_device(u16 seg, u8 bus, u8 d
                            seg, bus, slot, func, i);
                     continue;
                 }
-                ret = pci_size_mem_bar(sbdf, idx, NULL, &pdev->vf_rlen[i],
+                ret = pci_size_mem_bar(pdev->sbdf, idx, NULL,
+                                       &pdev->vf_rlen[i],
                                        PCI_BAR_VF |
                                        ((i == PCI_SRIOV_NUM_BARS - 1) ?
                                         PCI_BAR_LAST : 0));


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 13:48:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 13:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTQb2-00025X-JQ; Tue, 28 Apr 2020 13:48:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTQb1-00025S-G8
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 13:48:23 +0000
X-Inumbo-ID: ed009fba-8956-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ed009fba-8956-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 13:48:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id ABA53ACD0;
 Tue, 28 Apr 2020 13:48:20 +0000 (UTC)
Subject: Re: [XEN PATCH v5 09/16] xen/build: use if_changed on built_in.o
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-10-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6c6d20f5-d8ab-ee15-d2fc-e19b1dced99a@suse.com>
Date: Tue, 28 Apr 2020 15:48:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-10-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 18:12, Anthony PERARD wrote:
> In the case where $(obj-y) is empty, we also replace $(c_flags) by
> $(XEN_CFLAGS) to avoid generating an .%.d dependency file. This avoid
> make trying to include %.h file in the ld command if $(obj-y) isn't
> empty anymore on a second run.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

Personally I'd prefer ...

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -130,15 +130,24 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
>  c_flags += $(CFLAGS-y)
>  a_flags += $(CFLAGS-y) $(AFLAGS-y)
>  
> -built_in.o: $(obj-y) $(extra-y)
> -ifeq ($(obj-y),)
> -	$(CC) $(c_flags) -c -x c /dev/null -o $@
> -else
> +quiet_cmd_ld_builtin = LD      $@
>  ifeq ($(CONFIG_LTO),y)
> -	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
> +cmd_ld_builtin = \
> +    $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
>  else
> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
> +cmd_ld_builtin = \
> +    $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
>  endif
> +
> +quiet_cmd_cc_builtin = LD      $@
> +cmd_cc_builtin = \
> +    $(CC) $(XEN_CFLAGS) -c -x c /dev/null -o $@
> +
> +built_in.o: $(obj-y) $(extra-y) FORCE
> +ifeq ($(obj-y),)
> +	$(call if_changed,cc_builtin)
> +else
> +	$(call if_changed,ld_builtin)
>  endif

...

   $(call if_changed,$(if $(obj-y),ld,cc)_builtin)

but perhaps I'm the only one.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 13:50:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 13:50:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTQdQ-0002ov-2x; Tue, 28 Apr 2020 13:50:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTQdO-0002oq-Nm
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 13:50:50 +0000
X-Inumbo-ID: 44d6c6ec-8957-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 44d6c6ec-8957-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 13:50:50 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0789BAC64;
 Tue, 28 Apr 2020 13:50:47 +0000 (UTC)
Subject: Re: [XEN PATCH v5 11/16] xen/build: factorise generation of the
 linker scripts
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-12-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <5b2caf05-506d-7d61-cd41-375c069a0433@suse.com>
Date: Tue, 28 Apr 2020 15:50:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-12-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 18:12, Anthony PERARD wrote:
> In Arm and X86 makefile, generating the linker script is the same, so
> we can simply have both call the same macro.
> 
> We need to add *.lds files into extra-y so that Rules.mk can find the
> .*.cmd dependency file and load it.
> 
> Change made to the command line:
> - Use of $(CPP) instead of $(CC) -E
> - Remove -Ui386.
>   We don't compile Xen for i386 anymore, so that macro is never
>   defined. Also it doesn't make sense on Arm.
> - Use $(cpp_flags) which simply filter -Wa,% options from $(a_flags).
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

For the non-Arm bits
Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:01:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:01:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTQnh-00040N-7R; Tue, 28 Apr 2020 14:01:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xuLu=6M=citrix.com=anthony.perard@srs-us1.protection.inumbo.net>)
 id 1jTQnf-00040I-9p
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:01:27 +0000
X-Inumbo-ID: bfb32e4a-8958-11ea-ae69-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bfb32e4a-8958-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 14:01:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588082486;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=3ZI32rbX7vbjAnfVe3E63LPPSn3OkMfFTsauLKrnmIo=;
 b=WDY89AaC4IG1IBupmpKds+db7lSHvuaxZXykpkIkcoqOW3ney0451LDx
 GZkFonoo6GukzcI1xAsc2wtMhLkxTbJFdXZf2IJhKJgVR8yBOmAOsL2c4
 wAhchPcwNIvlrHinVolFJ3EzRRLpq4qORgv0QS9X4Mwsgk80wuiIC/QdO I=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=anthony.perard@citrix.com;
 spf=Pass smtp.mailfrom=anthony.perard@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 anthony.perard@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 anthony.perard@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="anthony.perard@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="anthony.perard@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: z3GuTzryai4oOgRNCvJGwRm3OLXhYUCVzzYaBSEdTPcuAoeKjszrM1F6qT+MwLrsDzsB9qFU9Y
 iI6x8+k2pl47aMJfSRGEU+OEzOf0ZZ5INi4qWPKWLDrw6ZmzRJqeSJricfezHlBZQhPDNRtbTe
 6/vZi4EjkUb3EySiIFlWGlypI635jtoE8zI+i+QPr3FwDRaE8ozmoLPlZboHcAHy0neBCZJAV6
 LRh7QCswcKGvjmw6R1vdT7kv/YYZSDNIhxKUChnWoTvolP+D7EK7fZ0HLgcSUnLJj+mDahyfFk
 /0c=
X-SBRS: 2.7
X-MesageID: 16626119
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,327,1583211600"; d="scan'208";a="16626119"
Date: Tue, 28 Apr 2020 15:01:19 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH v5 08/16] build: Introduce $(cpp_flags)
Message-ID: <20200428140119.GC2116@perard.uk.xensource.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-9-anthony.perard@citrix.com>
 <62011f46-b208-334a-4070-0bd72cb21d28@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <62011f46-b208-334a-4070-0bd72cb21d28@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian
 Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 23, 2020 at 06:48:51PM +0200, Jan Beulich wrote:
> On 21.04.2020 18:12, Anthony PERARD wrote:
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -123,6 +123,7 @@ $(obj-bin-y): XEN_CFLAGS := $(filter-out -flto,$(XEN_CFLAGS))
> >  
> >  c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_CFLAGS) '-D__OBJECT_FILE__="$@"'
> >  a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_AFLAGS)
> > +cpp_flags = $(filter-out -Wa$(comma)%,$(a_flags))
> 
> I can see this happening to be this way right now, but in principle
> I could see a_flags to hold items applicable to assembly files only,
> but not to (the preprocessing of) C files. Hence while this is fine
> for now, ...
> 
> > @@ -207,7 +208,7 @@ quiet_cmd_cc_s_c = CC      $@
> >  cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
> >  
> >  quiet_cmd_s_S = CPP     $@
> > -cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
> > +cmd_s_S = $(CPP) $(cpp_flags) $< -o $@
> 
> ... this one is a trap waiting for someone to fall in imo. Instead
> where I'd expect this patch to use $(cpp_flags) is e.g. in
> xen/arch/x86/mm/Makefile:
> 
> guest_walk_%.i: guest_walk.c Makefile
> 	$(CPP) $(cpp_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
> 
> And note how this currently uses $(c_flags), not $(a_flags), which
> suggests that your deriving from $(a_flags) isn't correct either.

I think we can drop this patch for now, and change patch "xen/build:
factorise generation of the linker scripts" to not use $(cpp_flags).

If we derive $(cpp_flags) from $(c_flags) instead, we would need to
find out if CPP commands using a_flags can use c_flags instead.

On the other hand, I've looked at Linux source code, and they use
$(cpp_flags) for only a few targets, only to generate the .lds scripts.
For other rules, they use either a_flags or c_flags, for example:
    %.i: %.c ; uses $(c_flags)
    %.i: %.S ; uses $(a_flags)
    %.s: %.S ; uses $(a_flags)

(Also, they use -Qunused-arguments clang's options, so they don't need
to filter out -Wa,* arguments, I think.)

So, maybe having a single $(cpp_flags) when running the CPP command
isn't such a good idea.

So, would dropping $(cpp_flags) for now, and rework the *FLAGS later, be
good enough?

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:06:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:06:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTQs6-0004BF-Ux; Tue, 28 Apr 2020 14:06:02 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTQs6-0004BA-8U
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:06:02 +0000
X-Inumbo-ID: 63a7b23d-8959-11ea-9867-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 63a7b23d-8959-11ea-9867-12813bfff9fa;
 Tue, 28 Apr 2020 14:06:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 07C04AA7C;
 Tue, 28 Apr 2020 14:05:58 +0000 (UTC)
Subject: Re: [XEN PATCH v5 13/16] xen,symbols: rework file symbols selection
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-14-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e67399ed-43d1-544c-6a85-29df59e42006@suse.com>
Date: Tue, 28 Apr 2020 16:05:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-14-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 18:12, Anthony PERARD wrote:
> We want to use the same rune to build mm/*/guest_*.o as the one use to
> build every other *.o object. The consequence it that file symbols that
> the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
> 
> For example, when building arch/x86/mm/guest_walk_2.o from guest_walk.c,
> this would be the difference of file symbol present in the object when
> building with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y:
> 
> (1) Currently we have those two file symbols:
>     guest_walk.c
>     guest_walk_2.o
> (2) When building with the same rune, we will have:
>     arch/x86/mm/guest_walk.c
>     guest_walk_2.o

So I had to go to the v4 discussion to understand this again. As said
there, it may be obvious to you but despite having been the one to
introduce the objcopy step there, it is not to me. Hence my continued
desire to have this at least briefly mentioned here, as it's not
otherwise noticeable from looking at the patch itself.

The code change itself looks okay to me, but I'll want to ack this
change only once I can follow the description from a single pass of
reading through it. I'm sorry for the extra trouble.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:07:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTQtm-0004Hj-Ae; Tue, 28 Apr 2020 14:07:46 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTQtl-0004Hb-Hp
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:07:45 +0000
X-Inumbo-ID: a1a0864a-8959-11ea-9867-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a1a0864a-8959-11ea-9867-12813bfff9fa;
 Tue, 28 Apr 2020 14:07:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 27CADACD0;
 Tue, 28 Apr 2020 14:07:43 +0000 (UTC)
Subject: Re: [XEN PATCH v5 14/16] build: use if_changed to build mm/*/guest_%.o
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-15-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <7b5e2e65-a4ee-2b12-74cb-7a52fb1cc488@suse.com>
Date: Tue, 28 Apr 2020 16:07:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-15-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 18:12, Anthony PERARD wrote:
> Use if_changed for building all guest_%.o objects, and make use of
> command that already exist.
> 
> The current command only runs `CC`, but the runes to build every other
> object in Xen also runs `objcopy` (when CONFIG_ENFORCE_UNIQUE_SYMBOLS=y)
> which modify the file symbol. But with patch
> "xen,symbols: rework file symbols selection", ./symbols should still
> select the file symbols directive intended to be used for guest_%.o
> objects.
> 
> The goal here is to reduce the number of commands written in
> makefiles.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:07:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTQty-0004L3-J8; Tue, 28 Apr 2020 14:07:58 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NU6p=6M=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTQtx-0004JX-0f
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:07:57 +0000
X-Inumbo-ID: a750e0be-8959-11ea-9867-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a750e0be-8959-11ea-9867-12813bfff9fa;
 Tue, 28 Apr 2020 14:07:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588082875;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=5OhOUoQl2/DHZ7IzNIxIAeEo7gVuL/FeA3J14VLMssI=;
 b=PGdIsfQ+meNyJDZ/rkveUnkevmmgWiE76N2yyljF0GWxlOziSWuKXnq7
 OYtDIeFhluvimKa7ob7tkd/l8/zM5vcBlIOVbvymkvDa2fK1I1mxwda4Y
 FGFjuN2DKtWDENDHHaNjbxolNivcq12hqO/leu5F6RKtr4ShevgCWrqJd A=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 9CAhl/zs8Ogk/RBGZ6jNVnZP3Cf4fxN2gvwm5M10M9MmGyOUDfUzDY0/PJkEpF50xyreWYUFf3
 UZhPHht45gzBcVr6gI52vFrUDXf7vPqUC4hGM6QKdcxv+3vwtmnAFAuYBlJey4IcDGZbx2W75s
 3ZYy05eg64Fre0f0fv/qnRmUqVMwVT0rdxx3KSGie4wE6aU63xnUwdcCtGZKJ4tz2VaHaM8CSt
 /xqgrwzmroUmo8vhFrF4IRs7ikoAaQC+q48y9GAcH4Iyt0PHa17BMqbZdNWb15cFbK/zheuEuf
 2gs=
X-SBRS: 2.7
X-MesageID: 17062337
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,327,1583211600"; d="scan'208";a="17062337"
Subject: Re: [PATCH] PCI: drop a redundant variable from pci_add_device()
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <75d1c852-e6ea-d3f3-3624-c77fb678412a@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <88fdaeee-1c4f-0e11-dfdd-f3a81b4b7f0d@citrix.com>
Date: Tue, 28 Apr 2020 15:07:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <75d1c852-e6ea-d3f3-3624-c77fb678412a@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28/04/2020 13:59, Jan Beulich wrote:
> Surrounding code already uses the available alternative, after all.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:21:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTR6b-00064z-PG; Tue, 28 Apr 2020 14:21:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTR6a-00064u-Iq
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:21:00 +0000
X-Inumbo-ID: 7b5ba72e-895b-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7b5ba72e-895b-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 14:20:59 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C4F49ACD0;
 Tue, 28 Apr 2020 14:20:57 +0000 (UTC)
Subject: Re: [XEN PATCH v5 08/16] build: Introduce $(cpp_flags)
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-9-anthony.perard@citrix.com>
 <62011f46-b208-334a-4070-0bd72cb21d28@suse.com>
 <20200428140119.GC2116@perard.uk.xensource.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <86af7c75-8f8b-db0a-7420-343ccd70fc33@suse.com>
Date: Tue, 28 Apr 2020 16:20:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200428140119.GC2116@perard.uk.xensource.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.2020 16:01, Anthony PERARD wrote:
> On Thu, Apr 23, 2020 at 06:48:51PM +0200, Jan Beulich wrote:
>> On 21.04.2020 18:12, Anthony PERARD wrote:
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -123,6 +123,7 @@ $(obj-bin-y): XEN_CFLAGS := $(filter-out -flto,$(XEN_CFLAGS))
>>>  
>>>  c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_CFLAGS) '-D__OBJECT_FILE__="$@"'
>>>  a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_AFLAGS)
>>> +cpp_flags = $(filter-out -Wa$(comma)%,$(a_flags))
>>
>> I can see this happening to be this way right now, but in principle
>> I could see a_flags to hold items applicable to assembly files only,
>> but not to (the preprocessing of) C files. Hence while this is fine
>> for now, ...
>>
>>> @@ -207,7 +208,7 @@ quiet_cmd_cc_s_c = CC      $@
>>>  cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
>>>  
>>>  quiet_cmd_s_S = CPP     $@
>>> -cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
>>> +cmd_s_S = $(CPP) $(cpp_flags) $< -o $@
>>
>> ... this one is a trap waiting for someone to fall in imo. Instead
>> where I'd expect this patch to use $(cpp_flags) is e.g. in
>> xen/arch/x86/mm/Makefile:
>>
>> guest_walk_%.i: guest_walk.c Makefile
>> 	$(CPP) $(cpp_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
>>
>> And note how this currently uses $(c_flags), not $(a_flags), which
>> suggests that your deriving from $(a_flags) isn't correct either.
> 
> I think we can drop this patch for now, and change patch "xen/build:
> factorise generation of the linker scripts" to not use $(cpp_flags).
> 
> If we derive $(cpp_flags) from $(c_flags) instead, we would need to
> find out if CPP commands using a_flags can use c_flags instead.
> 
> On the other hand, I've looked at Linux source code, and they use
> $(cpp_flags) for only a few targets, only to generate the .lds scripts.
> For other rules, they use either a_flags or c_flags, for example:
>     %.i: %.c ; uses $(c_flags)
>     %.i: %.S ; uses $(a_flags)
>     %.s: %.S ; uses $(a_flags)

The first on really ought to be use cpp_flags. I couldn't find the
middle one. The last one clearly has to do something about -Wa,
options, but apart from this I'd consider a_flags appropriate to
use there.

> (Also, they use -Qunused-arguments clang's options, so they don't need
> to filter out -Wa,* arguments, I think.)

Maybe we should do so too then?

> So, maybe having a single $(cpp_flags) when running the CPP command
> isn't such a good idea.

Right - after all in particular the use of CPP to produce .lds is
an abuse, as the source file (named .lds.S) isn't really what its
name says.

> So, would dropping $(cpp_flags) for now, and rework the *FLAGS later, be
> good enough?

I don't think so, no, I'm sorry. cpp_flags should be there for its
real purpose. Whether the .lds.S -> .lds rule can use it, or should
use a_flags, or yet something else is a different thing.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:34:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRJj-0007DC-T8; Tue, 28 Apr 2020 14:34:35 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTRJj-0007D7-0T
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:34:35 +0000
X-Inumbo-ID: 60fe42fe-895d-11ea-b9cf-bc764e2007e4
Received: from mail-wr1-x429.google.com (unknown [2a00:1450:4864:20::429])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 60fe42fe-895d-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 14:34:34 +0000 (UTC)
Received: by mail-wr1-x429.google.com with SMTP id d15so23291738wrx.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 07:34:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=F/0k6PJTNvTws5L0YkLQ8tz0zw1BoEzEH61WEN+YUXY=;
 b=WtN12I4JJt6raKYhua4fiZBL08xGq/s/hpCv6pu7OvdMoXU84aTm7MYeLs9Dc3haEI
 Jdum/U5LZuNldzd4fF8AOeTb06w9DtBmgTJN3RGiR26umD7/YqW+Vc4Urpto3xynj8Z1
 TZKD060inTnDwVHlT+Got5ps51T2Qn+PwwPhcG84rnKn/lRf5Oe3c8bWR+6JTaFRo4LJ
 1iZ9W10EFU6iY+9U20MbUYusP09If65VdQjuj1Lnh2SWTmqaYtI+ZdPMQrbqFZuX5gxy
 dTbT3aRSM2J3nJzysGeq85YF2/+JuHhTwkjUExUhSsH/a0Xl4AvXbppAxv6ry6UwrH0I
 W3aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject
 :date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=F/0k6PJTNvTws5L0YkLQ8tz0zw1BoEzEH61WEN+YUXY=;
 b=Lwpm0ur2MzXVOMhecd9CtjWlJkmB3HKC+L/Hv1VzHA3v/fihfe9ggANuPeqlaFKFzx
 Q0vd0+0w8ZIYD2u8vhGSOqw3kKeFexcfsSa+JzrrQbdrNIQZv/+r/8qw8XlLKONtmNfp
 zRtf+9F0SPFoMg7FRFpOsTsLSTu4k3uuH7to9IOJ/8jNswO4pLhL/L1VZZiWRm/OCWYN
 Vve9zXt8LWQY7Q8jLR66GZksxo+TBFX0xva5BobRoMssVkHEqsdsatNEX01T+7xTX/YA
 6Wgo3P7JnITUUNZAHHAQatMAy4o1ISYHcflcJBRUkzXaxIzAeGacmkexwyEHYX5DPejn
 QOqw==
X-Gm-Message-State: AGi0PuY/tJLA6VY4y5qwNlTMCkb9wnZAOmFRfm90tYsCiCIE1Lft6mPv
 zMk2CuuTkskdr4Hv6snIyjQ=
X-Google-Smtp-Source: APiQypLTUoIXkwlKc1eanndW+mEC1uU52R4qcSRH5XSGNqOEnuPaO6YcVE5oqpCdXCNfrv8IJr1M9w==
X-Received: by 2002:a5d:5651:: with SMTP id j17mr32738201wrw.406.1588084473763; 
 Tue, 28 Apr 2020 07:34:33 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id c83sm3768848wmd.23.2020.04.28.07.34.32
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 07:34:33 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Jan Beulich'" <jbeulich@suse.com>,
	<xen-devel@lists.xenproject.org>
References: <75d1c852-e6ea-d3f3-3624-c77fb678412a@suse.com>
In-Reply-To: <75d1c852-e6ea-d3f3-3624-c77fb678412a@suse.com>
Subject: RE: [PATCH] PCI: drop a redundant variable from pci_add_device()
Date: Tue, 28 Apr 2020 15:34:31 +0100
Message-ID: <000e01d61d6a$22295000$667bf000$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQKG/isN7hcHCscEKMpqEFl4lUzD96cs1uzw
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 28 April 2020 14:00
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant <paul@xen.org>
> Subject: [PATCH] PCI: drop a redundant variable from pci_add_device()
> 
> Surrounding code already uses the available alternative, after all.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 

Reviewed-by: Paul Durrant <paul@xen.org>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:37:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:37:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRMK-0007KT-BH; Tue, 28 Apr 2020 14:37:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTRMJ-0007KO-HZ
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:37:15 +0000
X-Inumbo-ID: c08a4e8e-895d-11ea-9872-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c08a4e8e-895d-11ea-9872-12813bfff9fa;
 Tue, 28 Apr 2020 14:37:14 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9D259AB91;
 Tue, 28 Apr 2020 14:37:12 +0000 (UTC)
Subject: Re: [XEN PATCH v5 15/16] build, include: rework compat-build-source.py
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-16-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <fe3eaa36-7145-ca73-a0d1-5ca220edebff@suse.com>
Date: Tue, 28 Apr 2020 16:37:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-16-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 18:12, Anthony PERARD wrote:
> Improvement are:
> - give the path to xlat.lst as argument
> - include `grep -v` in compat-build-source.py script, we don't need to
>   write this in several scripted language.
> 
> No changes in final compat/%.h headers.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:39:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRON-0007Sx-NX; Tue, 28 Apr 2020 14:39:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTROM-0007Sq-6Y
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:39:22 +0000
X-Inumbo-ID: 0c236c04-895e-11ea-9872-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0c236c04-895e-11ea-9872-12813bfff9fa;
 Tue, 28 Apr 2020 14:39:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id ADB4AAA7C;
 Tue, 28 Apr 2020 14:39:19 +0000 (UTC)
Subject: Re: [XEN PATCH v5 16/16] build, include: rework compat-build-header.py
To: Anthony PERARD <anthony.perard@citrix.com>
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-17-anthony.perard@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <28e89622-5020-c9cd-9518-3726f29dff37@suse.com>
Date: Tue, 28 Apr 2020 16:39:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-17-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 21.04.2020 18:12, Anthony PERARD wrote:
> Replace a mix of shell script and python script by all python script.
> 
> No change to the final generated headers.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 
> Notes:
>     v5:
>     - Removed -P from CPP when generating compat/%.i
>       -> keep removing linemarkers and keep de-duplicating empty lines.
>       So that all the blank line that currently exist in the generated
>       headers stays in place.

Thanks for doing these adjustments. However, my Python isn't good
enough to actually ack this patch, I'm afraid.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:50:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRYz-0000fj-RA; Tue, 28 Apr 2020 14:50:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTRYy-0000fb-NK
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:50:20 +0000
X-Inumbo-ID: 946837f6-895f-11ea-ae69-bc764e2007e4
Received: from mail-wr1-x429.google.com (unknown [2a00:1450:4864:20::429])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 946837f6-895f-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 14:50:19 +0000 (UTC)
Received: by mail-wr1-x429.google.com with SMTP id s10so25004401wrr.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 07:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=jetBIG79dStyA5xjWjEgrRqpRB6Q9dvYvXjWfbTeQ1g=;
 b=p8ww9LjnyyVBgw2qJSPEClpPnqmNwGQ2aaRCQW6rdWCGKm4ssB8Wy0MP6Ei8s8m2na
 odAqZ85z+2b69auOR+RXdKO1fFy8dQBHI1UjpF/Cg/OGIhzk3H2zjI0ooPEHFABheR6R
 8kSWBtdacdqrQwm8CxEurN7AAkh5YvZLxOvbLR0JUOv0SS2HT36ki8//MpO49oEdfvo+
 KWmUUexi4PTD/ring8peWFLBnXkj9L9ewmzWMWkYtjmZVdPhAKpVBj5ZQzdbywv5rhid
 cSE22Vaa23hFHzUCLvHz38u6jn4iCegpvXbrDDO0oFE1pxLIPgNtXAZwgtKRIALApPbM
 Q3HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=jetBIG79dStyA5xjWjEgrRqpRB6Q9dvYvXjWfbTeQ1g=;
 b=VdgBPI2Nu+E+5KDKibaPPvAJDkpe5QRT2bX4Azq442XNGq/bJ2Db28HXZaKkVJpR+W
 UU97vJQvIvKTeg2/v0MGIvm2dZ+8CenF0C2+EfMt5KD4xWAD7gNvayL+1IQzPwWCI6D1
 nHxFIq7CI7hedW4l1vpmI7L5+GvkyKMq2DSLUZ8tiCuLekTL6fP3e6u/YEsq6nOf2bD2
 6CYYC6T7r1Z4J0uYXuafl9kLlM5ejf2Jils9+nHlN2SE+mOP1gtHCySTQZ3vUERSjZk6
 ucqeyU+GL+yppYcXB9Xl0ZgiQJP0DpjlbLgVSMk99gVjLPowqSjlY5Oj/p3ZrlOD1Jxn
 qs7Q==
X-Gm-Message-State: AGi0PuYl7q+abtFPc/l+M1W/o6QIvIlTN5S/c905zulkh/h/jGWYCMvv
 Gy02NQK9ZmfkIMPyh+tMMNA=
X-Google-Smtp-Source: APiQypLgXk0QlU/44WrRv89aJ5zNSltj36+tvHynPDGF93IhLKDKTe92g5pdzni0yW9j094PR4BmMw==
X-Received: by 2002:a5d:6acc:: with SMTP id u12mr36346317wrw.198.1588085418968; 
 Tue, 28 Apr 2020 07:50:18 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.188])
 by smtp.gmail.com with ESMTPSA id y18sm3860378wmc.45.2020.04.28.07.50.17
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 07:50:18 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= <jgross@suse.com>,
 "'Julien Grall'" <julien@xen.org>, <xen-devel@lists.xenproject.org>
References: <20200427155035.668-1-paul@xen.org>
 <7ab25832-66e6-020f-b343-059f21771054@xen.org>
 <f13de8bc-ca5d-2341-3797-b34f9f2c70ef@suse.com>
 <2087b3dd-7d2c-3ab3-d6ce-a4d132f7ec4d@xen.org>
 <000c01d61d5b$00bc05c0$02341140$@xen.org>
 <bb0a87e5-4112-107a-b15b-0edf1e616f87@suse.com>
In-Reply-To: <bb0a87e5-4112-107a-b15b-0edf1e616f87@suse.com>
Subject: RE: [PATCH v4] docs/designs: re-work the xenstore migration
 document...
Date: Tue, 28 Apr 2020 15:50:16 +0100
Message-ID: <000f01d61d6c$5583e8f0$008bbad0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQHlntLxHS5TXNWYohOpoPk3VAlj7gIKOtGYAd6p4dIC8EMlIAIdFegiAglAXqKoF56wcA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>
> Sent: 28 April 2020 13:56
> To: paul@xen.org; 'Julien Grall' <julien@xen.org>; =
xen-devel@lists.xenproject.org
> Cc: 'Paul Durrant' <pdurrant@amazon.com>; 'Andrew Cooper' =
<andrew.cooper3@citrix.com>; 'George Dunlap'
> <george.dunlap@citrix.com>; 'Ian Jackson' <ian.jackson@eu.citrix.com>; =
'Jan Beulich'
> <jbeulich@suse.com>; 'Stefano Stabellini' <sstabellini@kernel.org>; =
'Wei Liu' <wl@xen.org>
> Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration =
document...
>=20
> On 28.04.20 14:46, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Julien Grall <julien@xen.org>
> >> Sent: 28 April 2020 11:23
> >> To: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>; Paul Durrant =
<paul@xen.org>; xen-devel@lists.xenproject.org
> >> Cc: Paul Durrant <pdurrant@amazon.com>; Andrew Cooper =
<andrew.cooper3@citrix.com>; George Dunlap
> >> <george.dunlap@citrix.com>; Ian Jackson =
<ian.jackson@eu.citrix.com>; Jan Beulich
> <jbeulich@suse.com>;
> >> Stefano Stabellini <sstabellini@kernel.org>; Wei Liu <wl@xen.org>
> >> Subject: Re: [PATCH v4] docs/designs: re-work the xenstore =
migration document...
> >>
> >> Hi Juergen,
> >>
> >> On 28/04/2020 11:10, J=C3=BCrgen Gro=C3=9F wrote:
> >>> On 28.04.20 11:05, Julien Grall wrote:
> >>>>> -where tx_id is the non-zero identifier values of an open =
transaction.
> >>>>> +| Field     | Description                                       =
|
> >>>>> =
+|-----------|---------------------------------------------------|
> >>>>> +| `domid`   | The domain-id that owns the shared page           =
|
> >>>>> +|           |                                                   =
|
> >>>>> +| `tdomid`  | The domain-id that `domid` acts on behalf of if   =
|
> >>>>> +|           | it has been subject to an SET_TARGET              =
|
> >>>>> +|           | operation [2] or DOMID_INVALID [3] otherwise      =
|
> >>>>> +|           |                                                   =
|
> >>>>> +| `flags`   | Must be zero                                      =
|
> >>>>> +|           |                                                   =
|
> >>>>> +| `evtchn`  | The port number of the interdomain channel used   =
|
> >>>>> +|           | by `domid` to communicate with xenstored          =
|
> >>>>> +|           |                                                   =
|
> >>>>> +| `mfn`     | The MFN of the shared page for a live update or   =
|
> >>>>> +|           | ~0 (i.e. all bits set) otherwise                  =
|
> >>>>> -### Protocol Extension
> >>>>> +Since the ABI guarantees that entry 1 in `domid`'s grant table =
will
> >>>>> always
> >>>>> +contain the GFN of the shared page, so for a live update `mfn` =
can
> >>>>> be used to
> >>>>> +give confidence that `domid` has not been re-cycled during the =
update.
> >>>>
> >>>> I am confused, there is no way a XenStored running in an Arm =
domain
> >>>> can map the MFN of the shared page. So how is this going to work =
out?
> >>>
> >>> I guess this will be a MFN for PV guests and a guest PFN else.
> >>
> >> If we use Xen terminology (xen/include/xen/mm.h), this would be a =
GFN.
> >>
> >
> > TBH I'm not sure a GFN would give much confidence about domain =
recycling as it would likely be the
> same for many domains, I think. We really need a UUID.
>=20
> No, we need a per-host domain value, which is associated with a domain
> and which is unique during the life-time of the host.
>=20
> E.g. a global counter, which is incremented at each domain creation =
and
> stored in struct domain.
>=20

Can we just drop this and fall back on the fact that libxl now prevents =
domids from being recycled for 60s?

  Paul



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:51:29 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:51:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRa4-0000pq-9m; Tue, 28 Apr 2020 14:51:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=DYx7=6M=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTRa3-0000pl-2D
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:51:27 +0000
X-Inumbo-ID: bc0e917e-895f-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bc0e917e-895f-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 14:51:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 228A3AD88;
 Tue, 28 Apr 2020 14:51:24 +0000 (UTC)
Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration
 document...
To: paul@xen.org, 'Julien Grall' <julien@xen.org>,
 xen-devel@lists.xenproject.org
References: <20200427155035.668-1-paul@xen.org>
 <7ab25832-66e6-020f-b343-059f21771054@xen.org>
 <f13de8bc-ca5d-2341-3797-b34f9f2c70ef@suse.com>
 <2087b3dd-7d2c-3ab3-d6ce-a4d132f7ec4d@xen.org>
 <000c01d61d5b$00bc05c0$02341140$@xen.org>
 <bb0a87e5-4112-107a-b15b-0edf1e616f87@suse.com>
 <000f01d61d6c$5583e8f0$008bbad0$@xen.org>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <39de560f-4bda-387c-6d6e-5b9495642d0c@suse.com>
Date: Tue, 28 Apr 2020 16:51:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <000f01d61d6c$5583e8f0$008bbad0$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.20 16:50, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jürgen Groß <jgross@suse.com>
>> Sent: 28 April 2020 13:56
>> To: paul@xen.org; 'Julien Grall' <julien@xen.org>; xen-devel@lists.xenproject.org
>> Cc: 'Paul Durrant' <pdurrant@amazon.com>; 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'George Dunlap'
>> <george.dunlap@citrix.com>; 'Ian Jackson' <ian.jackson@eu.citrix.com>; 'Jan Beulich'
>> <jbeulich@suse.com>; 'Stefano Stabellini' <sstabellini@kernel.org>; 'Wei Liu' <wl@xen.org>
>> Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration document...
>>
>> On 28.04.20 14:46, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Julien Grall <julien@xen.org>
>>>> Sent: 28 April 2020 11:23
>>>> To: Jürgen Groß <jgross@suse.com>; Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
>>>> Cc: Paul Durrant <pdurrant@amazon.com>; Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap
>>>> <george.dunlap@citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; Jan Beulich
>> <jbeulich@suse.com>;
>>>> Stefano Stabellini <sstabellini@kernel.org>; Wei Liu <wl@xen.org>
>>>> Subject: Re: [PATCH v4] docs/designs: re-work the xenstore migration document...
>>>>
>>>> Hi Juergen,
>>>>
>>>> On 28/04/2020 11:10, Jürgen Groß wrote:
>>>>> On 28.04.20 11:05, Julien Grall wrote:
>>>>>>> -where tx_id is the non-zero identifier values of an open transaction.
>>>>>>> +| Field     | Description                                       |
>>>>>>> +|-----------|---------------------------------------------------|
>>>>>>> +| `domid`   | The domain-id that owns the shared page           |
>>>>>>> +|           |                                                   |
>>>>>>> +| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
>>>>>>> +|           | it has been subject to an SET_TARGET              |
>>>>>>> +|           | operation [2] or DOMID_INVALID [3] otherwise      |
>>>>>>> +|           |                                                   |
>>>>>>> +| `flags`   | Must be zero                                      |
>>>>>>> +|           |                                                   |
>>>>>>> +| `evtchn`  | The port number of the interdomain channel used   |
>>>>>>> +|           | by `domid` to communicate with xenstored          |
>>>>>>> +|           |                                                   |
>>>>>>> +| `mfn`     | The MFN of the shared page for a live update or   |
>>>>>>> +|           | ~0 (i.e. all bits set) otherwise                  |
>>>>>>> -### Protocol Extension
>>>>>>> +Since the ABI guarantees that entry 1 in `domid`'s grant table will
>>>>>>> always
>>>>>>> +contain the GFN of the shared page, so for a live update `mfn` can
>>>>>>> be used to
>>>>>>> +give confidence that `domid` has not been re-cycled during the update.
>>>>>>
>>>>>> I am confused, there is no way a XenStored running in an Arm domain
>>>>>> can map the MFN of the shared page. So how is this going to work out?
>>>>>
>>>>> I guess this will be a MFN for PV guests and a guest PFN else.
>>>>
>>>> If we use Xen terminology (xen/include/xen/mm.h), this would be a GFN.
>>>>
>>>
>>> TBH I'm not sure a GFN would give much confidence about domain recycling as it would likely be the
>> same for many domains, I think. We really need a UUID.
>>
>> No, we need a per-host domain value, which is associated with a domain
>> and which is unique during the life-time of the host.
>>
>> E.g. a global counter, which is incremented at each domain creation and
>> stored in struct domain.
>>
> 
> Can we just drop this and fall back on the fact that libxl now prevents domids from being recycled for 60s?

In any case this discussion does not belong to this patch IMO.


Juergen


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:51:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRa6-0000qP-HT; Tue, 28 Apr 2020 14:51:30 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qrdk=6M=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTRa5-0000qB-TV
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:51:29 +0000
X-Inumbo-ID: babe6bd2-895f-11ea-9879-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id babe6bd2-895f-11ea-9879-12813bfff9fa;
 Tue, 28 Apr 2020 14:51:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=VXQW0aGOziQq3XxMJiLMjGVGcfC3JDcrecFv8GdSmdM=; b=GvzglPl523BkkY0gjam2Z/T4o
 E0NmbqdzY99wgD8dC76HVVbT2PfN/oOt26ntfCj+JOSXr6+d5ofsJ9onazM4YqzzxZoMg43hx3Hr3
 MiN5MvhziaKNjOY0VbcH1c6ddaqAUT308jgVTXFbeNqezgtFTRCh1oRYzTqy8j09uazrI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTRZz-0006Af-EW; Tue, 28 Apr 2020 14:51:23 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTRZz-00065V-7K; Tue, 28 Apr 2020 14:51:23 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTRZz-0001S2-6k; Tue, 28 Apr 2020 14:51:23 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149857-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149857: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=2add344e6a4ef690871157b87b0e7d52bc6db9e4
X-Osstest-Versions-That: xen=dd0882f912005b56653013025ebd160862e360ad
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 28 Apr 2020 14:51:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149857 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149857/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  2add344e6a4ef690871157b87b0e7d52bc6db9e4
baseline version:
 xen                  dd0882f912005b56653013025ebd160862e360ad

Last test of basis   149839  2020-04-27 21:01:50 Z    0 days
Testing same since   149857  2020-04-28 12:00:23 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   dd0882f912..2add344e6a  2add344e6a4ef690871157b87b0e7d52bc6db9e4 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:54:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRco-00016O-0Z; Tue, 28 Apr 2020 14:54:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=v0V7=6M=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jTRcn-00016F-3O
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:54:17 +0000
X-Inumbo-ID: 219bc3a4-8960-11ea-9879-12813bfff9fa
Received: from mail-wr1-f65.google.com (unknown [209.85.221.65])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 219bc3a4-8960-11ea-9879-12813bfff9fa;
 Tue, 28 Apr 2020 14:54:16 +0000 (UTC)
Received: by mail-wr1-f65.google.com with SMTP id k1so25031667wrx.4
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 07:54:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:cc:subject:to:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=VoPA4W7BZVH2jWUzs+94ypS6QS/QPthapxnGLEr38SQ=;
 b=rWP/gNc07yNm9/tpiyY1muD1fIQLTmFX0KGClE+A+YzXQZ17wppBBumRP3jjc5Bqda
 3eLVJeVjmn3E9/5b/Ljlr76Zh7QdLFAVd33okoA7RmfTm5YiSzqpUGMghG7I27jWeNNO
 9pX4H4lEFP8V07lYUZLZU09hyZx7iTVgjLL4dPXAbBj4rN37/5r+xGetIfZimq7+xAnd
 aGHmvDP20CfHb+veLK8EbdyqZBwpc0td5oh5rHKP+wQO4LbHeTWcnusxcJnAB4Yo7e5t
 MK+XtQa2PxfgDS5cvnjJH2lQME5xiN30AyADAqLvzF4UeKSh2hPrss85vI70enfN+LZu
 JBCw==
X-Gm-Message-State: AGi0PuYZyGQd9gf7tf12nPRtHmmJ2u8AApT12994CKEDOSppl9bZOgcR
 uQvMRcLVf5+psrgnkt3uiDk=
X-Google-Smtp-Source: APiQypKw+9/PVGXtY8GYvMPHL86MIn6z3tjyNarh4OGinN+KhwrRlvfZlZ2zpEwcxsXJ+FXbzh1VxQ==
X-Received: by 2002:adf:cc8d:: with SMTP id p13mr35125363wrj.114.1588085655818; 
 Tue, 28 Apr 2020 07:54:15 -0700 (PDT)
Received: from [192.168.1.64] (44.142.6.51.dyn.plus.net. [51.6.142.44])
 by smtp.gmail.com with ESMTPSA id z18sm25264753wrw.41.2020.04.28.07.54.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Apr 2020 07:54:15 -0700 (PDT)
Subject: Re: [XEN PATCH v5 16/16] build, include: rework compat-build-header.py
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
References: <20200421161208.2429539-1-anthony.perard@citrix.com>
 <20200421161208.2429539-17-anthony.perard@citrix.com>
From: Wei Liu <wl@xen.org>
Message-ID: <af8752f1-9684-48d5-19ad-800c989cefa0@xen.org>
Date: Tue, 28 Apr 2020 15:54:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200421161208.2429539-17-anthony.perard@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 wl@xen.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 21/04/2020 17:12, Anthony PERARD wrote:
> Replace a mix of shell script and python script by all python script.
> 
> No change to the final generated headers.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

To the best of my knowledge this patch is doing the right transformation.

Acked-by: Wei Liu <wl@xen.org>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 14:58:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 14:58:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRh4-0001Hn-JU; Tue, 28 Apr 2020 14:58:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=DYx7=6M=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTRh3-0001Hi-4D
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 14:58:41 +0000
X-Inumbo-ID: bebdd44c-8960-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bebdd44c-8960-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 14:58:40 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 77637ACC3;
 Tue, 28 Apr 2020 14:58:38 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] tools/xenstore: simplify socket initialization
Date: Tue, 28 Apr 2020 16:58:37 +0200
Message-Id: <20200428145837.6099-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The setup of file descriptors for the Xenstore sockets is needlessly
complicated: the space is allocated dynamically, while two static
variables really would do the job.

For tearing down the sockets it is easier to widen the scope of the
file descriptors from function to file.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/xenstore/xenstored_core.c | 69 ++++++++++++++++-------------------------
 1 file changed, 27 insertions(+), 42 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 551fe38f57..7bd959f28b 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -70,6 +70,9 @@ static struct pollfd *fds;
 static unsigned int current_array_size;
 static unsigned int nr_fds;
 
+static int sock = -1;
+static int ro_sock = -1;
+
 #define ROUNDUP(_x, _w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 
 static bool verbose = false;
@@ -310,8 +313,7 @@ fail:
 	return -1;
 }
 
-static void initialize_fds(int sock, int *p_sock_pollfd_idx,
-			   int ro_sock, int *p_ro_sock_pollfd_idx,
+static void initialize_fds(int *p_sock_pollfd_idx, int *p_ro_sock_pollfd_idx,
 			   int *ptimeout)
 {
 	struct connection *conn;
@@ -1789,43 +1791,29 @@ void corrupt(struct connection *conn, const char *fmt, ...)
 	check_store();
 }
 
-
-#ifdef NO_SOCKETS
-static void init_sockets(int **psock, int **pro_sock)
-{
-	static int minus_one = -1;
-	*psock = *pro_sock = &minus_one;
-}
-#else
-static int destroy_fd(void *_fd)
+#ifndef NO_SOCKETS
+static void destroy_fds(void)
 {
-	int *fd = _fd;
-	close(*fd);
-	return 0;
+	if (sock >= 0)
+		close(sock);
+	if (ro_sock >= 0)
+		close(ro_sock);
 }
 
-static void init_sockets(int **psock, int **pro_sock)
+static void init_sockets(void)
 {
 	struct sockaddr_un addr;
-	int *sock, *ro_sock;
 	const char *soc_str = xs_daemon_socket();
 	const char *soc_str_ro = xs_daemon_socket_ro();
 
 	/* Create sockets for them to listen to. */
-	*psock = sock = talloc(talloc_autofree_context(), int);
-	if (!sock)
-		barf_perror("No memory when creating sockets");
-	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*sock < 0)
+	atexit(destroy_fds);
+	sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (sock < 0)
 		barf_perror("Could not create socket");
-	*pro_sock = ro_sock = talloc(talloc_autofree_context(), int);
-	if (!ro_sock)
-		barf_perror("No memory when creating sockets");
-	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*ro_sock < 0)
+	ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (ro_sock < 0)
 		barf_perror("Could not create socket");
-	talloc_set_destructor(sock, destroy_fd);
-	talloc_set_destructor(ro_sock, destroy_fd);
 
 	/* FIXME: Be more sophisticated, don't mug running daemon. */
 	unlink(soc_str);
@@ -1836,24 +1824,21 @@ static void init_sockets(int **psock, int **pro_sock)
 	if(strlen(soc_str) >= sizeof(addr.sun_path))
 		barf_perror("socket string '%s' too long", soc_str);
 	strcpy(addr.sun_path, soc_str);
-	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+	if (bind(sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
 		barf_perror("Could not bind socket to %s", soc_str);
 
 	if(strlen(soc_str_ro) >= sizeof(addr.sun_path))
 		barf_perror("socket string '%s' too long", soc_str_ro);
 	strcpy(addr.sun_path, soc_str_ro);
-	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+	if (bind(ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
 		barf_perror("Could not bind socket to %s", soc_str_ro);
 
 	if (chmod(soc_str, 0600) != 0
 	    || chmod(soc_str_ro, 0660) != 0)
 		barf_perror("Could not chmod sockets");
 
-	if (listen(*sock, 1) != 0
-	    || listen(*ro_sock, 1) != 0)
+	if (listen(sock, 1) != 0 || listen(ro_sock, 1) != 0)
 		barf_perror("Could not listen on sockets");
-
-
 }
 #endif
 
@@ -1909,7 +1894,7 @@ int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
-	int opt, *sock = NULL, *ro_sock = NULL;
+	int opt;
 	int sock_pollfd_idx = -1, ro_sock_pollfd_idx = -1;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1997,7 +1982,9 @@ int main(int argc, char *argv[])
 
 	talloc_enable_null_tracking();
 
-	init_sockets(&sock, &ro_sock);
+#ifndef NO_SOCKETS
+	init_sockets();
+#endif
 
 	init_pipe(reopen_log_pipe);
 
@@ -2025,8 +2012,7 @@ int main(int argc, char *argv[])
 		tracefile = talloc_strdup(NULL, tracefile);
 
 	/* Get ready to listen to the tools. */
-	initialize_fds(*sock, &sock_pollfd_idx, *ro_sock, &ro_sock_pollfd_idx,
-		       &timeout);
+	initialize_fds(&sock_pollfd_idx, &ro_sock_pollfd_idx, &timeout);
 
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
@@ -2067,7 +2053,7 @@ int main(int argc, char *argv[])
 				barf_perror("sock poll failed");
 				break;
 			} else if (fds[sock_pollfd_idx].revents & POLLIN) {
-				accept_connection(*sock, true);
+				accept_connection(sock, true);
 				sock_pollfd_idx = -1;
 			}
 		}
@@ -2077,7 +2063,7 @@ int main(int argc, char *argv[])
 				barf_perror("ro sock poll failed");
 				break;
 			} else if (fds[ro_sock_pollfd_idx].revents & POLLIN) {
-				accept_connection(*ro_sock, false);
+				accept_connection(ro_sock, false);
 				ro_sock_pollfd_idx = -1;
 			}
 		}
@@ -2144,8 +2130,7 @@ int main(int argc, char *argv[])
 			}
 		}
 
-		initialize_fds(*sock, &sock_pollfd_idx, *ro_sock,
-			       &ro_sock_pollfd_idx, &timeout);
+		initialize_fds(&sock_pollfd_idx, &ro_sock_pollfd_idx, &timeout);
 	}
 }
 
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:00:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:00:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRiU-00022c-VA; Tue, 28 Apr 2020 15:00:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=KfNV=6M=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jTRiT-00021D-Oi
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:00:09 +0000
X-Inumbo-ID: f3ae3dfe-8960-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f3ae3dfe-8960-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 15:00:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=J+NHKJa/jRyEJy0/LP08QbrjXlFQcDFOHxnhibHPQfE=; b=6/zrzz9bCHr8cUroV/z0uHJMpm
 30zqYAWmCaqNaVRFIQHCheQUyopBRA4eKHPjn2kGPMT/SHgEng3NlpqfQ45Vx3iIvubs06jn6Zn/N
 svzrGXhB9EftTC46wAW4GJ6Vc6BT53QlkdO9DAvHK0uoSUgOsnSpqvApamtKPcZR4BGw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jTRiS-0006Q3-0q; Tue, 28 Apr 2020 15:00:08 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jTRiR-0002hr-L7; Tue, 28 Apr 2020 15:00:07 +0000
Date: Tue, 28 Apr 2020 16:00:04 +0100
From: Wei Liu <wl@xen.org>
To: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH] tools/xenstore: simplify socket initialization
Message-ID: <20200428150004.le3ic6rla2erpfnq@debian>
References: <20200428145837.6099-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200428145837.6099-1-jgross@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 28, 2020 at 04:58:37PM +0200, Juergen Gross wrote:
> The setup of file descriptors for the Xenstore sockets is needlessly
> complicated: the space is allocated dynamically, while two static
> variables really would do the job.
> 
> For tearing down the sockets it is easier to widen the scope of the
> file descriptors from function to file.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Wei Liu <wl@xen.org>


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:06:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRod-0002Lf-NS; Tue, 28 Apr 2020 15:06:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=6sfs=6M=xen.org=paul@srs-us1.protection.inumbo.net>)
 id 1jTRoc-0002La-Kv
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:06:30 +0000
X-Inumbo-ID: d6500ce6-8961-11ea-987d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d6500ce6-8961-11ea-987d-12813bfff9fa;
 Tue, 28 Apr 2020 15:06:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=nY9X/UITXafMt7b0KKyKWmsrbnu6eiWS6AQxzL+QedI=; b=GNuKZMAov2XN2AykApKeqqEjBO
 w0+lVQIx3CvvGOIMtNs3AktM9toSzkW9HywNoRXOlLPkwBtn+CS06BI0wpx8ePXrjBHqocUXAZjJA
 exdhi6xvke6HmzGLq7eblISuAWaB4Z/jqeUbj33pVQJlQlxJY0DLTGWWKOzpfynhaQ1o=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <paul@xen.org>)
 id 1jTRoa-0006Xj-A6; Tue, 28 Apr 2020 15:06:28 +0000
Received: from [54.239.6.186] (helo=CBG-R90WXYV0.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <paul@xen.org>)
 id 1jTRoZ-0003IE-Oi; Tue, 28 Apr 2020 15:06:28 +0000
From: Paul Durrant <paul@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v5] docs/designs: re-work the xenstore migration document...
Date: Tue, 28 Apr 2020 16:06:24 +0100
Message-Id: <20200428150624.265-1-paul@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Paul Durrant <pdurrant@amazon.com>

... to specify a separate migration stream that will also be suitable for
live update.

The original scope of the document was to support non-cooperative migration
of guests [1] but, since then, live update of xenstored has been brought into
scope. Thus it makes more sense to define a separate image format for
serializing xenstore state that is suitable for both purposes.

The document has been limited to specifying a new image format. The mechanism
for acquiring the image for live update or migration is not covered as that
is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
also expected that, when the first implementation of live update or migration
making use of this specification is committed, that the document is moved from
docs/designs into docs/specs.

NOTE: It will only be necessary to save and restore state for active xenstore
      connections, but the documentation for 'RESUME' in xenstore.txt implies
      otherwise. That command is unused so this patch deletes it from the
      specification.

[1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Wei Liu <wl@xen.org>

v5:
 - Addressed comments from Julien
 - Dropped 'mfn' from shared ring 'conn-spec' as its feasibility/utility is
   debatable

v4:
 - Move path-len and value-len earlier in NODE_DATA

v3:
 - Address missed comments from Juergen

v2:
 - Address comments from Juergen
---
 docs/designs/xenstore-migration.md | 469 +++++++++++++++++++----------
 docs/misc/xenstore.txt             |  17 --
 2 files changed, 307 insertions(+), 179 deletions(-)

diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
index 6ab351e8fe..34a2afd17e 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -3,254 +3,399 @@
 ## Background
 
 The design for *Non-Cooperative Migration of Guests*[1] explains that extra
-save records are required in the migrations stream to allow a guest running
-PV drivers to be migrated without its co-operation. Moreover the save
-records must include details of registered xenstore watches as well as
-content; information that cannot currently be recovered from `xenstored`,
-and hence some extension to the xenstore protocol[2] will also be required.
-
-The *libxenlight Domain Image Format* specification[3] already defines a
-record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
-transferring xenstore data pertaining to the domain directly as it is
-specified such that keys are relative to the path
-`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
-define at least one new save record type.
+save records are required in the migrations stream to allow a guest running PV
+drivers to be migrated without its co-operation. Moreover the save records must
+include details of registered xenstore watches as well as content; information
+that cannot currently be recovered from `xenstored`, and hence some extension
+to the xenstored implementations will also be required.
+
+As a similar set of data is needed for transferring xenstore data from one
+instance to another when live updating xenstored this document proposes an
+image format for a 'migration stream' suitable for both purposes.
 
 ## Proposal
 
-### New Save Record
+The image format consists of a _header_ followed by 1 or more _records_. Each
+record consists of a type and length field, followed by any data mandated by
+the record type. At minimum there will be a single record of type `END`
+(defined below).
 
-A new mandatory record type should be defined within the libxenlight Domain
-Image Format:
+### Header
 
-`0x00000007: DOMAIN_XENSTORE_DATA`
+The header identifies the stream as a `xenstore` stream, including the version
+of the specification that it complies with.
 
-An arbitrary number of these records may be present in the migration
-stream and may appear in any order. The format of each record should be as
-follows:
+All fields in this header must be in _big-endian_ byte order, regardless of
+the setting of the endianness bit.
 
 
 ```
     0       1       2       3       4       5       6       7    octet
 +-------+-------+-------+-------+-------+-------+-------+-------+
-| type                          | record specific data          |
-+-------------------------------+                               |
-...
-+---------------------------------------------------------------+
+| ident                                                         |
++-------------------------------+-------------------------------|
+| version                       | flags                         |
++-------------------------------+-------------------------------+
 ```
 
-where type is one of the following values
 
+| Field     | Description                                       |
+|-----------|---------------------------------------------------|
+| `ident`   | 0x78656e73746f7265 ('xenstore' in ASCII)          |
+|           |                                                   |
+| `version` | 0x00000001 (the version of the specification)     |
+|           |                                                   |
+| `flags`   | 0 (LSB): Endianness: 0 = little, 1 = big          |
+|           |                                                   |
+|           | 1-31: Reserved (must be zero)                     |
 
-| Field  | Description                                      |
-|--------|--------------------------------------------------|
-| `type` | 0x00000000: invalid                              |
-|        | 0x00000001: NODE_DATA                            |
-|        | 0x00000002: WATCH_DATA                           |
-|        | 0x00000003: TRANSACTION_DATA                     |
-|        | 0x00000004 - 0xFFFFFFFF: reserved for future use |
+### Records
 
+Records immediately follow the header and have the following format:
 
-and data is one of the record data formats described in the following
-sections.
+
+```
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| type                          | len                           |
++-------------------------------+-------------------------------+
+| body
+...
+|       | padding (0 to 7 octets)                               |
++-------+-------------------------------------------------------+
+```
+
+NOTE: padding octets here and in all subsequent format specifications must be
+      written as zero and should be ignored when the stream is read.
 
 
-NOTE: The record data does not contain an overall length because the
-libxenlight record header specifies the length.
+| Field  | Description                                          |
+|--------|------------------------------------------------------|
+| `type` | 0x00000000: END                                      |
+|        | 0x00000001: GLOBAL_DATA                              |
+|        | 0x00000002: CONNECTION_DATA                          |
+|        | 0x00000003: WATCH_DATA                               |
+|        | 0x00000004: TRANSACTION_DATA                         |
+|        | 0x00000005: NODE_DATA                                |
+|        | 0x00000006 - 0xFFFFFFFF: reserved for future use     |
+|        |                                                      |
+| `len`  | The length (in octets) of `body`                     |
+|        |                                                      |
+| `body` | The type-specific record data                        |
 
+Some records will depend on other records in the migration stream. Records
+upon which other records depend must always appear earlier in the stream.
 
-**NODE_DATA**
+The various formats of the type-specific data are described in the following
+sections:
 
+\pagebreak
 
-Each NODE_DATA record specifies a single node in xenstore and is formatted
-as follows:
+### END
 
+The end record marks the end of the image, and is the final record
+in the stream.
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| NODE_DATA                     |
-+-------------------------------+
-| path length                   |
-+-------------------------------+
-| path data                     |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
-| perm count (N)                |
-+-------------------------------+
-| perm0                         |
-+-------------------------------+
-...
-+-------------------------------+
-| permN                         |
-+-------------------------------+
-| value length                  |
-+-------------------------------+
-| value data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
 ```
 
-where perm0..N are formatted as follows:
 
+The end record contains no fields; its body length is 0.
+
+\pagebreak
+
+### GLOBAL_DATA
+
+This record is only relevant for live update. It contains details of global
+xenstored state that needs to be restored.
 
 ```
-    0       1       2       3     octet
+    0       1       2       3    octet
 +-------+-------+-------+-------+
-| perm  | pad   | domid         |
+| rw-socket-fd                  |
++-------------------------------+
+| ro-socket-fd                  |
 +-------------------------------+
 ```
 
 
-path length and value length are specified in octets (excluding the NUL
-terminator of the path). perm should be one of the ASCII values `w`, `r`,
-`b` or `n` as described in [2]. All pad values should be 0.
-All paths should be absolute (i.e. start with `/`) and as described in
-[2].
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `rw-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-write connections                       |
+|                |                                              |
+| `ro-socket-fd` | The file descriptor of the socket accepting  |
+|                | read-only connections                        |
+
+xenstored will resume in the original process context. Hence `rw-socket-fd` and
+`ro-socket-fd` simply specify the file descriptors of the sockets. Sockets
+are not always used, however, and so -1 will be used to denote an unused
+socket.
 
 
-**WATCH_DATA**
+\pagebreak
 
+### CONNECTION_DATA
 
-Each WATCH_DATA record specifies a registered watch and is formatted as
-follows:
+For live update the image format will contain a `CONNECTION_DATA` record for
+each connection to xenstore. For migration it will only contain a record for
+the domain being migrated.
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| WATCH_DATA                    |
-+-------------------------------+
-| wpath length                  |
-+-------------------------------+
-| wpath data                    |
-...
-| pad (0 to 3 octets)           |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
++-------+-------+-------+-------+-------+-------+-------+-------+
+| conn-id                       | conn-type     | conn-spec
 ...
++-------------------------------+-------------------------------+
+| data-len                      | data
 +-------------------------------+
-| token length                  |
-+-------------------------------+
-| token data                    |
 ...
-| pad (0 to 3 octets)           |
-+-------------------------------+
 ```
 
-wpath length and token length are specified in octets (excluding the NUL
-terminator). The wpath should be as described for the `WATCH` operation in
-[2]. The token is an arbitrary string of octets not containing any NUL
-values.
 
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | A non-zero number used to identify this         |
+|             | connection in subsequent connection-specific    |
+|             | records                                         |
+|             |                                                 |
+| `conn-type` | 0x0000: shared ring                             |
+|             | 0x0001: socket                                  |
+|             | 0x0002 - 0xFFFF: reserved for future use        |
+|             |                                                 |
+| `conn-spec` | See below                                       |
+|             |                                                 |
+| `data-len`  | The length (in octets) of any pending data not  |
+|             | yet written to the connection                   |
+|             |                                                 |
+| `data`      | Pending data (may be empty)                     |
 
-**TRANSACTION_DATA**
+The format of `conn-spec` is dependent upon `conn-type`.
 
+\pagebreak
 
-Each TRANSACTION_DATA record specifies an open transaction and is formatted
-as follows:
+For `shared ring` connections it is as follows:
 
 
 ```
-    0       1       2       3     octet
-+-------+-------+-------+-------+
-| TRANSACTION_DATA              |
-+-------------------------------+
-| tx_id                         |
-+-------------------------------+
+    0       1       2       3       4       5       6       7    octet
+                                                +-------+-------+
+                                                | flags         |
++---------------+---------------+---------------+---------------+
+| domid         | tdomid        | evtchn                        |
++-------------------------------+-------------------------------+
 ```
 
-where tx_id is the non-zero identifier values of an open transaction.
 
+| Field     | Description                                       |
+|-----------|---------------------------------------------------|
+| `domid`   | The domain-id that owns the shared page           |
+|           |                                                   |
+| `tdomid`  | The domain-id that `domid` acts on behalf of if   |
+|           | it has been subject to an SET_TARGET              |
+|           | operation [2] or DOMID_INVALID [3] otherwise      |
+|           |                                                   |
+| `flags`   | Must be zero                                      |
+|           |                                                   |
+| `evtchn`  | The port number of the interdomain channel used   |
+|           | by `domid` to communicate with xenstored          |
+|           |                                                   |
 
-### Protocol Extension
+Since the ABI guarantees that entry 1 in `domid`'s grant table will always
+contain the GFN of the shared page.
 
-Before xenstore state is migrated it is necessary to wait for any pending
-reads, writes, watch registrations etc. to complete, and also to make sure
-that xenstored does not start processing any new requests (so that new
-requests remain pending on the shared ring for subsequent processing on the
-new host). Hence the following operation is needed:
+For `socket` connections it is as follows:
 
-```
-QUIESCE                 <domid>|
 
-Complete processing of any request issued by the specified domain, and
-do not process any further requests from the shared ring.
+```
+                                                +-------+-------+
+                                                | flags         |
++---------------+---------------+---------------+---------------+
+| socket-fd                     | pad                           |
++-------------------------------+-------------------------------+
 ```
 
-The `WATCH` operation does not allow specification of a `<domid>`; it is
-assumed that the watch pertains to the domain that owns the shared ring
-over which the operation is passed. Hence, for the tool-stack to be able
-to register a watch on behalf of a domain a new operation is needed:
 
-```
-ADD_DOMAIN_WATCHES      <domid>|<watch>|+
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `flags`     | A bit-wise OR of:                               |
+|             | 0001: read-only                                 |
+|             |                                                 |
+| `socket-fd` | The file descriptor of the connected socket     |
 
-Adds watches on behalf of the specified domain.
+This type of connection is only relevant for live update, where the xenstored
+resumes in the original process context. Hence `socket-fd` simply specify
+the file descriptor of the socket connection.
 
-<watch> is a NUL separated tuple of <path>|<token>. The semantics of this
-operation are identical to the domain issuing WATCH <path>|<token>| for
-each <watch>.
-```
+\pagebreak
+
+### WATCH_DATA
+
+The image format will contain a `WATCH_DATA` record for each watch registered
+by a connection for which there is `CONNECTION_DATA` record previously present.
 
-The watch information for a domain also needs to be extracted from the
-sending xenstored so the following operation is also needed:
 
 ```
-GET_DOMAIN_WATCHES      <domid>|<index>   <gencnt>|<watch>|*
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++---------------+---------------+
+| wpath-len     | token-len     |
++---------------+---------------+
+| wpath
+...
+| token
+...
+```
+
+
+| Field       | Description                                     |
+|-------------|-------------------------------------------------|
+| `conn-id`   | The connection that issued the `WATCH`          |
+|             | operation [2]                                   |
+|             |                                                 |
+| `wpath-len` | The length (in octets) of `wpath` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `token-len` | The length (in octets) of `token` including the |
+|             | NUL terminator                                  |
+|             |                                                 |
+| `wpath`     | The watch path, as specified in the `WATCH`     |
+|             | operation                                       |
+|             |                                                 |
+| `token`     | The watch identifier token, as specified in the |
+|             | `WATCH` operation                               |
+
+\pagebreak
 
-Gets the list of watches that are currently registered for the domain.
+### TRANSACTION_DATA
 
-<watch> is a NUL separated tuple of <path>|<token>. The sub-list returned
-will start at <index> items into the the overall list of watches and may
-be truncated (at a <watch> boundary) such that the returned data fits
-within XENSTORE_PAYLOAD_MAX.
+The image format will contain a `TRANSACTION_DATA` record for each transaction
+that is pending on a connection for which there is `CONNECTION_DATA` record
+previously present.
 
-If <index> is beyond the end of the overall list then the returned sub-
-list will be empty. If the value of <gencnt> changes then it indicates
-that the overall watch list has changed and thus it may be necessary
-to re-issue the operation for previous values of <index>.
+
+```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++-------------------------------+
 ```
 
-To deal with transactions that were pending when the domain is migrated
-it is necessary to start transactions with the same tx_id on behalf of the
-domain in the receiving xenstored.
 
-NOTE: For safety each such transaction should result in an `EAGAIN` when
-the `TRANSACTION_END` operation is performed, as modifications made under
-the tx_id will not be part of the migration stream.
+| Field          | Description                                  |
+|----------------|----------------------------------------------|
+| `conn-id`      | The connection that issued the               |
+|                | `TRANSACTION_START` operation [2]            |
+|                |                                              |
+| `tx-id`        | The transaction id passed back to the domain |
+|                | by the `TRANSACTION_START` operation         |
 
-The `TRANSACTION_START` operation does not allow specification of a
-`<domid>`; it is assumed that the transaction pertains to the domain that
-owns the shared ring over which the operation is passed. Neither does it
-allow a `<transid>` to be specified; it is always chosen by xenstored.
-Hence, for the tool-stack to be able to open a transaction on behalf of a
-domain a new operation is needed:
+\pagebreak
 
+### NODE_DATA
+
+For live update the image format will contain a `NODE_DATA` record for each
+node in xenstore. For migration it will only contain a record for the nodes
+relating to the domain being migrated. The `NODE_DATA` may be related to
+a _committed_ node (globally visible in xenstored) or a _pending_ node (created
+or modified by a transaction for which there is also a `TRANSACTION_DATA`
+record previously present).
+
+
+```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| conn-id                       |
++-------------------------------+
+| tx-id                         |
++---------------+---------------+
+| path-len      | value-len     |
++---------------+---------------+
+| access        | perm-count    |
++---------------+---------------+
+| perm1                         |
++-------------------------------+
+...
++-------------------------------+
+| permN                         |
++---------------+---------------+
+| path
+...
+| value
+...
 ```
-START_DOMAIN_TRANSACTION    <domid>|<transid>|
 
-Starts a transaction on behalf of a domain.
 
-The semantics of this are similar to the domain issuing
-TRANSACTION_START and receiving the specified <transid> as the response.
-The main difference is that the transaction will be immediately marked as
-'conflicting' such that when the domain issues TRANSACTION_END T|, it will
-result in EAGAIN.
+| Field        | Description                                    |
+|--------------|------------------------------------------------|
+| `conn-id`    | If this value is non-zero then this record     |
+|              | related to a pending transaction               |
+|              |                                                |
+| `tx-id`      | This value should be ignored if `conn-id` is   |
+|              | zero. Otherwise it specifies the id of the     |
+|              | pending transaction                            |
+|              |                                                |
+| `path-len`   | The length (in octets) of `path` including the |
+|              | NUL terminator                                 |
+|              |                                                |
+| `value-len`  | The length (in octets) of `value` (which will  |
+|              | be zero for a deleted node)                    |
+|              |                                                |
+| `access`     | This value should be ignored if this record    |
+|              | does not relate to a pending transaction,      |
+|              | otherwise it specifies the accesses made to    |
+|              | the node and hence is a bitwise OR of:         |
+|              |                                                |
+|              | 0x0001: read                                   |
+|              | 0x0002: written                                |
+|              |                                                |
+|              | The value will be zero for a deleted node      |
+|              |                                                |
+| `perm-count` | The number (N) of node permission specifiers   |
+|              | (which will be 0 for a node deleted in a       |
+|              | pending transaction)                           |
+|              |                                                |
+| `perm1..N`   | A list of zero or more node permission         |
+|              | specifiers (see below)                         |
+|              |                                                |
+| `path`       | The absolute path of the node                  |
+|              |                                                |
+| `value`      | The node value (which may be empty or contain  |
+|              | NUL octets)                                    |
+
+
+A node permission specifier has the following format:
+
+
+```
+    0       1       2       3    octet
++-------+-------+-------+-------+
+| perm  | pad   | domid         |
++-------+-------+---------------+
 ```
 
-It may also be desirable to state in the protocol specification that
-the `INTRODUCE` operation should not clear the `<gfn>` specified such that
-a `RELEASE` operation followed by an `INTRODUCE` operation form an
-idempotent pair. The current implementation of *C xentored* does this
-(in the `domain_conn_reset()` function) but this could be dropped as this
-behaviour is not currently specified and the page will always be zeroed
-for a newly created domain.
+| Field   | Description                                         |
+|---------|-----------------------------------------------------|
+| `perm`  | One of the ASCII values `w`, `r`, `b` or `n` as     |
+|         | specified for the `SET_PERMS` operation [2]         |
+|         |                                                     |
+| `domid` | The domain-id to which the permission relates       |
 
+Note that perm1 defines the domain owning the code. See [4] for more
+explanation of node permissions.
 
 * * *
 
 [1] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
+
 [2] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/xenstore.txt
-[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/specs/libxl-migration-stream.pandoc
+
+[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/xen.h;hb=HEAD#l612
+
+[4] https://wiki.xen.org/wiki/XenBus
\ No newline at end of file
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index 04ce0ba607..cb8009cb68 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -289,23 +289,6 @@ IS_DOMAIN_INTRODUCED	<domid>|		T| or F|
 	ie, if INTRODUCE for the domain has not yet been followed by
 	domain destruction or explicit RELEASE.
 
-RESUME			<domid>|
-
-	Arranges that @releaseDomain events will once more be
-	generated when the domain becomes shut down.  This might have
-	to be used if a domain were to be shut down (generating one
-	@releaseDomain) and then subsequently restarted, since the
-	state-sensitive algorithm in xenstored will not otherwise send
-	further watch event notifications if the domain were to be
-	shut down again.
-
-	It is not clear whether this is possible since one would
-	normally expect a domain not to be restarted after being shut
-	down without being destroyed in the meantime.  There are
-	currently no users of this request in xen-unstable.
-
-	xenstored prevents the use of RESUME other than by dom0.
-
 SET_TARGET		<domid>|<tdomid>|
 	Notifies xenstored that domain <domid> is targeting domain
 	<tdomid>. This grants domain <domid> full access to paths
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:11:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:11:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRtW-0003F4-Fb; Tue, 28 Apr 2020 15:11:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTRtV-0003Ez-12
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:11:33 +0000
X-Inumbo-ID: 8b0536e8-8962-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8b0536e8-8962-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 15:11:32 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6FD35AE0F;
 Tue, 28 Apr 2020 15:11:30 +0000 (UTC)
Subject: Re: [PATCH 1/6] x86_64/mm: map and unmap page tables in
 cleanup_frame_table
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <12c4fe0c0c05b9f76377c085d8a6558beae64003.1587116799.git.hongyxia@amazon.com>
 <a1caa70d-9c7a-b0c2-d7cf-1893db8f0ac4@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <87e3db0e-1d6d-c248-9442-106923cb4ea7@suse.com>
Date: Tue, 28 Apr 2020 17:11:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a1caa70d-9c7a-b0c2-d7cf-1893db8f0ac4@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 11:02, Julien Grall wrote:
> On 17/04/2020 10:52, Hongyan Xia wrote:
>> @@ -763,10 +763,10 @@ static void cleanup_frame_table(struct mem_hotadd_info *info)
>>               continue;
>>           }
>>   -        ASSERT(l1e_get_flags(l2e_to_l1e(l2e)[l1_table_offset(sva)]) &
>> -                _PAGE_PRESENT);
>> -         sva = (sva & ~((1UL << PAGE_SHIFT) - 1)) +
>> -                    (1UL << PAGE_SHIFT);
>> +        ASSERT(l1e_get_flags(l1e_from_l2e(l2e, l1_table_offset(sva))) &
>> +               _PAGE_PRESENT);
>> +
>> +        sva = (sva & ~((1UL << PAGE_SHIFT) - 1)) + (1UL << PAGE_SHIFT);
> 
> NIT: While you are modifying the indentation. Couldn't we use PAGE_MASK and PAGE_SIZE here?

And with this (which I think can be done while committing)
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:12:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:12:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTRuY-0003JX-Pu; Tue, 28 Apr 2020 15:12:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTRuX-0003JN-6c
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:12:37 +0000
X-Inumbo-ID: b15503dc-8962-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b15503dc-8962-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 15:12:36 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 05A1CAC8F;
 Tue, 28 Apr 2020 15:12:34 +0000 (UTC)
Subject: Re: [PATCH 2/6] x86_64/mm: map and unmap page tables in
 subarch_init_memory
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <0e14533f516ee5ce410e2cd8050f085aec4b4961.1587116799.git.hongyxia@amazon.com>
 <232de7c3-77bc-1816-150f-082502e8fbff@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <0ca51b67-cb06-6a96-f848-453aca3ac72f@suse.com>
Date: Tue, 28 Apr 2020 17:12:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <232de7c3-77bc-1816-150f-082502e8fbff@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 11:04, Julien Grall wrote:
> On 17/04/2020 10:52, Hongyan Xia wrote:
>> From: Wei Liu <wei.liu2@citrix.com>
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> 
> Reviewed-by: Julien Grall <jgrall@amazon.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:23:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:23:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTS4z-0004Ok-SR; Tue, 28 Apr 2020 15:23:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTS4z-0004Od-1c
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:23:25 +0000
X-Inumbo-ID: 337a08a2-8964-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 337a08a2-8964-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 15:23:24 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A34A2AD9A;
 Tue, 28 Apr 2020 15:23:22 +0000 (UTC)
Subject: Re: [PATCH 3/6] x86_64/mm: map and unmap page tables in
 subarch_memory_op
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <1c88c785eb9537983a1692cc379604233ff13025.1587116799.git.hongyxia@amazon.com>
 <1fe549b7-2141-c013-61de-f7196e7ba966@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <378cf8d2-28b7-5754-fc32-e48bfc3c7299@suse.com>
Date: Tue, 28 Apr 2020 17:23:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1fe549b7-2141-c013-61de-f7196e7ba966@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 11:06, Julien Grall wrote:
> On 17/04/2020 10:52, Hongyan Xia wrote:
>> From: Wei Liu <wei.liu2@citrix.com>
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> 
> Reviewed-by: Julien Grall <jgrall@amazon.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:26:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:26:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTS7q-0004Vz-B1; Tue, 28 Apr 2020 15:26:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTS7p-0004Vt-Nv
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:26:21 +0000
X-Inumbo-ID: 9cc16490-8964-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9cc16490-8964-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 15:26:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7B374AB7F;
 Tue, 28 Apr 2020 15:26:19 +0000 (UTC)
Subject: Re: [PATCH 4/6] x86/smpboot: map and unmap page tables in
 cleanup_cpu_root_pgt
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <bc0ad02ad73ac3f02e063457d69634b1f6b57ddc.1587116799.git.hongyxia@amazon.com>
 <afec3c99-49e8-0304-23ef-1763df48fc9c@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <332fec70-3661-d0c3-25de-dc5a7a5ee4b3@suse.com>
Date: Tue, 28 Apr 2020 17:26:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <afec3c99-49e8-0304-23ef-1763df48fc9c@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 11:13, Julien Grall wrote:
> On 17/04/2020 10:52, Hongyan Xia wrote:
>> From: Wei Liu <wei.liu2@citrix.com>
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> 
> Reviewed-by: Julien Grall <jgrall@amazon.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:29:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:29:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSAd-0004e4-Pb; Tue, 28 Apr 2020 15:29:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jz34=6M=intel.com=tamas.lengyel@srs-us1.protection.inumbo.net>)
 id 1jTSAc-0004dz-JO
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:29:14 +0000
X-Inumbo-ID: 026b3d0c-8965-11ea-b9cf-bc764e2007e4
Received: from mga06.intel.com (unknown [134.134.136.31])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 026b3d0c-8965-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 15:29:11 +0000 (UTC)
IronPort-SDR: EdMYaLnUHsftwJTNCVwDNzKpjjKDqJs94bQxQDIwTiV6JPJhyhJYeKTBU9tnwkngHNDZhoIUvd
 Q1aPO5MyoqHw==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 28 Apr 2020 08:29:10 -0700
IronPort-SDR: xj0EbWvHko3qZ+zrB/VnZT14E9RwkXTMaOZtUZ539XzXawhJoh+nXipBTLHQHjab549XZxzWQG
 srL6R4Yhue6w==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.73,328,1583222400"; d="scan'208";a="302736438"
Received: from saborios-mobl3.amr.corp.intel.com (HELO localhost.localdomain)
 ([10.213.167.78])
 by FMSMGA003.fm.intel.com with ESMTP; 28 Apr 2020 08:29:09 -0700
From: Tamas K Lengyel <tamas.lengyel@intel.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2] mem_sharing: map shared_info page to same gfn during fork
Date: Tue, 28 Apr 2020 08:29:00 -0700
Message-Id: <6497e71a791bbc17b1ace3f5f260bd61275b76ba.1588087596.git.tamas.lengyel@intel.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Tamas K Lengyel <tamas.lengyel@intel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

During a VM fork we copy the shared_info page; however, we also need to ensure
that the page is mapped into the same GFN in the fork as its in the parent.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Suggested-by: Roger Pau Monne <roger.pau@citrix.com>
---
 xen/arch/x86/mm/mem_sharing.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 344a5bfb3d..a1dea8fedb 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1656,6 +1656,7 @@ static void copy_tsc(struct domain *cd, struct domain *d)
 static int copy_special_pages(struct domain *cd, struct domain *d)
 {
     mfn_t new_mfn, old_mfn;
+    gfn_t new_gfn, old_gfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(cd);
     static const unsigned int params[] =
     {
@@ -1701,6 +1702,30 @@ static int copy_special_pages(struct domain *cd, struct domain *d)
     new_mfn = _mfn(virt_to_mfn(cd->shared_info));
     copy_domain_page(new_mfn, old_mfn);
 
+    old_gfn = _gfn(get_gpfn_from_mfn(mfn_x(old_mfn)));
+    new_gfn = _gfn(get_gpfn_from_mfn(mfn_x(new_mfn)));
+
+    if ( !gfn_eq(old_gfn, new_gfn) )
+    {
+        if ( !gfn_eq(new_gfn, INVALID_GFN) )
+        {
+            /* if shared_info is mapped to a different gfn just remove it */
+            rc = p2m->set_entry(p2m, new_gfn, INVALID_MFN, PAGE_ORDER_4K,
+                                p2m_invalid, p2m->default_access, -1);
+            if ( rc )
+                return rc;
+        }
+
+        if ( !gfn_eq(old_gfn, INVALID_GFN) )
+        {
+            /* now map it to the same gfn as the parent */
+            rc = p2m->set_entry(p2m, old_gfn, new_mfn, PAGE_ORDER_4K,
+                                p2m_ram_rw, p2m->default_access, -1);
+            if ( rc )
+                return rc;
+        }
+    }
+
     return 0;
 }
 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:33:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSEo-0005Zn-B2; Tue, 28 Apr 2020 15:33:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTSEn-0005Zi-BM
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:33:33 +0000
X-Inumbo-ID: 9e0a19a4-8965-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9e0a19a4-8965-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 15:33:32 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0F258AB7F;
 Tue, 28 Apr 2020 15:33:31 +0000 (UTC)
Subject: Re: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
To: Hongyan Xia <hx242@xen.org>, Wei Liu <wl@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
Date: Tue, 28 Apr 2020 17:33:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 17.04.2020 11:52, Hongyan Xia wrote:
> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -50,17 +50,17 @@ static __init void mark_pv_pt_pages_rdonly(struct domain *d,
>      unsigned long count;
>      struct page_info *page;
>      l4_pgentry_t *pl4e;
> -    l3_pgentry_t *pl3e;
> -    l2_pgentry_t *pl2e;
> -    l1_pgentry_t *pl1e;
> +    l3_pgentry_t *pl3e, *l3t;
> +    l2_pgentry_t *pl2e, *l2t;
> +    l1_pgentry_t *pl1e, *l1t;

I don't quite see why the new local variables get introduced:
unmap_domain_page(), iirc, is quite fine with a non-page-
aligned argument.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:34:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:34:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSFf-0005db-Kd; Tue, 28 Apr 2020 15:34:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/MZc=6M=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTSFe-0005dR-5g
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:34:26 +0000
X-Inumbo-ID: bd79fc82-8965-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bd79fc82-8965-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 15:34:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DA763ACE3;
 Tue, 28 Apr 2020 15:34:23 +0000 (UTC)
Subject: Re: [PATCH 6/6] x86/pv: map and unmap page table in dom0_construct_pv
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <18fda6bdeb4f20bf2272503e45c7c420e51673ac.1587116799.git.hongyxia@amazon.com>
 <140cc03d-08ab-6a45-e56d-0b68e71eebd2@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <beda12fd-cb61-8db4-8bbd-992f33fa5310@suse.com>
Date: Tue, 28 Apr 2020 17:34:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <140cc03d-08ab-6a45-e56d-0b68e71eebd2@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 11:18, Julien Grall wrote:
> On 17/04/2020 10:52, Hongyan Xia wrote:
>> From: Wei Liu <wei.liu2@citrix.com>
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> 
> Reviewed-by: Julien Grall <jgrall@amazon.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:35:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:35:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSGY-0005jL-Ug; Tue, 28 Apr 2020 15:35:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTSGX-0005jA-N7
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:35:21 +0000
X-Inumbo-ID: ddfa6780-8965-11ea-b9cf-bc764e2007e4
Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ddfa6780-8965-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 15:35:20 +0000 (UTC)
Received: by mail-wm1-x343.google.com with SMTP id e26so3276619wmk.5
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 08:35:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=fCjEYnE9PVG8y7Lh3ojI15FhTSU5CvGePZ0rY21bNck=;
 b=kVUyIEYoi+whoLpExbhLNwUvhO56n3/ILSbdLJ+XR+b/cDWAZhqnyIAdosLZZttLWO
 PmX+tO++aiDdV++Uz2UuGU2ouIRdBlPh5l4B64gKqWErj2SHSxij0utFDDbIVW/TIrSw
 Mk26696W3XfUHGh1AZv0FpDjm4MHppqIEnkFGEtF7mBtm7DRGJRVUzEibz2ghW9PSASj
 m5Q98ij8Q0v3H5I1aUH8pJHStSZfZJira+Bk6gLIZsE1bNLhk6LOVmTj9UjxeXjHmVyX
 ZR1lMBIdVI88N3wDKgG76Zor6QIwdYHyjYlewzzVuVWuCb97NADiQVKqHdm3D+/A/TB5
 j6KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=fCjEYnE9PVG8y7Lh3ojI15FhTSU5CvGePZ0rY21bNck=;
 b=iJ4eEmJkUhBtcV8Ka7KDnDSi2yxb2LFQT/PQcDEnNb+4uBWMsfJk3uc/9+PjiBiIKT
 KpYeG0PrTwlpahV7doYni/f6/WE3vzc2/obo3FrQBiy4LGMI8ZGpJ0kQ7G1fLX6g4dtr
 K53dzoaMvHw6UJlPBZoRJcrpmwBtSIY95THd10FH9Ixc1v4H07bTXs1SBsIVBIKC73Bt
 S3km15S40AJIj3mVRuP5C2oZTIzZeCSGKUIQFkjFX4mlSyl0oWclzl59+VCtLZ5O27J/
 a5moSJX6nmbrmravmDfPBcaOlFtacusvFzfEWUI0S64CF91xPtXvAwLief9Oq3F91U0s
 O8KQ==
X-Gm-Message-State: AGi0PuYbMuLx2VH8Rtc6MguGaKzVIsc54QM03/p5FOwBk0XSSCE4w6ov
 hn/c7UQDxpCY/eugwlirq6U=
X-Google-Smtp-Source: APiQypIuZKXzZZX8ylJ+u7WQ8tQ/8lfYFC8z0zx8BWhiwEU1K7VgTmUpsy/P5pdJOC4Tzm7TnK5OOg==
X-Received: by 2002:a7b:c390:: with SMTP id s16mr5051546wmj.14.1588088119216; 
 Tue, 28 Apr 2020 08:35:19 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id g69sm4005194wmg.17.2020.04.28.08.35.17
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 08:35:18 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-2-paul@xen.org>
 <2f69484c-d043-bded-0a88-2587241aaa94@xen.org>
In-Reply-To: <2f69484c-d043-bded-0a88-2587241aaa94@xen.org>
Subject: RE: [PATCH v2 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
Date: Tue, 28 Apr 2020 16:35:16 +0100
Message-ID: <001401d61d72$9ef9da20$dced8e60$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQIOC3/NwyZzJjhdRz0oBcI7Is/lxwF9QIbqAXe2hfeoBx6rIA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>,
 'Volodymyr Babchuk' <Volodymyr_Babchuk@epam.com>,
 =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 20 April 2020 18:21
> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Paul Durrant <pdurrant@amazon.com>; Andrew Cooper =
<andrew.cooper3@citrix.com>; George Dunlap
> <george.dunlap@citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; =
Jan Beulich <jbeulich@suse.com>;
> Stefano Stabellini <sstabellini@kernel.org>; Wei Liu <wl@xen.org>; =
Volodymyr Babchuk
> <Volodymyr_Babchuk@epam.com>; Roger Pau Monn=C3=A9 =
<roger.pau@citrix.com>
> Subject: Re: [PATCH v2 1/5] xen/common: introduce a new framework for =
save/restore of 'domain' context
>=20
> Hi Paul,
>=20
> On 07/04/2020 18:38, Paul Durrant wrote:
> > To allow enlightened HVM guests (i.e. those that have PV drivers) to =
be
> > migrated without their co-operation it will be necessary to transfer =
'PV'
> > state such as event channel state, grant entry state, etc.
> >
> > Currently there is a framework (entered via the hvm_save/load() =
functions)
> > that allows a domain's 'HVM' (architectural) state to be transferred =
but
> > 'PV' state is also common with pure PV guests and so this framework =
is not
> > really suitable.
> >
> > This patch adds the new public header and low level implementation =
of a new
> > common framework, entered via the domain_save/load() functions. =
Subsequent
> > patches will introduce other parts of the framework, and code that =
will
> > make use of it within the current version of the libxc migration =
stream.
> >
> > This patch also marks the HVM-only framework as deprecated in favour =
of the
> > new framework.
> >
> > Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> > ---
> > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: George Dunlap <george.dunlap@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Jan Beulich <jbeulich@suse.com>
> > Cc: Julien Grall <julien@xen.org>
> > Cc: Stefano Stabellini <sstabellini@kernel.org>
> > Cc: Wei Liu <wl@xen.org>
> > Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> > Cc: "Roger Pau Monn=C3=A9" <roger.pau@citrix.com>
> >
> > v2:
> >   - Allow multi-stage save/load to avoid the need to double-buffer
> >   - Get rid of the masks and add an 'ignore' flag instead
> >   - Create copy function union to preserve const save buffer
> >   - Deprecate HVM-only framework
> > ---
> >   xen/common/Makefile                    |   1 +
> >   xen/common/save.c                      | 329 =
+++++++++++++++++++++++++
> >   xen/include/public/arch-arm/hvm/save.h |   5 +
> >   xen/include/public/arch-x86/hvm/save.h |   5 +
> >   xen/include/public/save.h              |  84 +++++++
> >   xen/include/xen/save.h                 | 152 ++++++++++++
> >   6 files changed, 576 insertions(+)
> >   create mode 100644 xen/common/save.c
> >   create mode 100644 xen/include/public/save.h
> >   create mode 100644 xen/include/xen/save.h
> >
> > diff --git a/xen/common/Makefile b/xen/common/Makefile
> > index e8cde65370..90553ba5d7 100644
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -37,6 +37,7 @@ obj-y +=3D radix-tree.o
> >   obj-y +=3D rbtree.o
> >   obj-y +=3D rcupdate.o
> >   obj-y +=3D rwlock.o
> > +obj-y +=3D save.o
> >   obj-y +=3D shutdown.o
> >   obj-y +=3D softirq.o
> >   obj-y +=3D sort.o
> > diff --git a/xen/common/save.c b/xen/common/save.c
> > new file mode 100644
> > index 0000000000..6cdac3785b
> > --- /dev/null
> > +++ b/xen/common/save.c
> > @@ -0,0 +1,329 @@
> > +/*
> > + * save.c: Save and restore PV guest state common to all domain =
types.
> > + *
> > + * Copyright Amazon.com Inc. or its affiliates.
> > + *
> > + * 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 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 <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#include <xen/save.h>
> > +
> > +union domain_copy_entry {
> > +    domain_write_entry write;
> > +    domain_read_entry read;
> > +};
> > +
> > +struct domain_context {
> > +    bool log;
> > +    struct domain_save_descriptor desc;
> > +    size_t data_len;
>=20
> What is data_len?
>=20

It=E2=80=99s used for internal accounting.

> > +    union domain_copy_entry copy;
> > +    void *priv;
> > +};
> > +
> > +static struct {
> > +    const char *name;
> > +    bool per_vcpu;
> > +    domain_save_handler save;
> > +    domain_load_handler load;
> > +} handlers[DOMAIN_SAVE_CODE_MAX + 1];
> > +
> > +void __init domain_register_save_type(unsigned int tc, const char =
*name,
> > +                                      bool per_vcpu,
> > +                                      domain_save_handler save,
> > +                                      domain_load_handler load)
> > +{
> > +    BUG_ON(tc > ARRAY_SIZE(handlers));
> > +
> > +    ASSERT(!handlers[tc].save);
> > +    ASSERT(!handlers[tc].load);
> > +
> > +    handlers[tc].name =3D name;
> > +    handlers[tc].per_vcpu =3D per_vcpu;
> > +    handlers[tc].save =3D save;
> > +    handlers[tc].load =3D load;
> > +}
> > +
> > +int domain_save_begin(struct domain_context *c, unsigned int tc,
> > +                      const char *name, const struct vcpu *v, =
size_t len)
> > +{
> > +    int rc;
> > +
> > +    if ( c->log )
> > +        gdprintk(XENLOG_INFO, "%pv save: %s (%lu)\n", v, name,
> > +                 (unsigned long)len);
>=20
> How about using %zu rather than a cast here?
>=20

Yes, that would be better.

> > +
> > +    BUG_ON(tc !=3D c->desc.typecode);
> > +    BUG_ON(v->vcpu_id !=3D c->desc.vcpu_id);
>=20
> I can't find any answer on my question about this part. I understand =
the
> code would be buggy if this happen, but is it warrant to crash the =
host?
> Couldn't you just return an error and continue to run?
>=20

Since it means buggy code I could ASSERT and error out, yes.

> > +
> > +    ASSERT(!c->data_len);
> > +    c->data_len =3D c->desc.length =3D len;
> > +
> > +    rc =3D c->copy.write(c->priv, &c->desc, sizeof(c->desc));
> > +    if ( rc )
> > +        return rc;
> > +
> > +    c->desc.length =3D 0;
>=20
> This is confusing, why would you need to reset c->desc.length but not
> the rest of the fields?
>=20

Because I use it to accumulate the length of the saved data and then =
cross check it against data_len in domain_save_end() below.

> > +
> > +    return 0;
> > +}
> > +
> > +int domain_save_data(struct domain_context *c, const void *src, =
size_t len)
> > +{
> > +    if ( c->desc.length + len > c->data_len )
> > +        return -ENOSPC;
> > +
> > +    c->desc.length +=3D len;
> > +
> > +    return c->copy.write(c->priv, src, len);
> > +}
> > +
> > +int domain_save_end(struct domain_context *c)
> > +{
> > +    /*
> > +     * If desc.length does not match the length specified in
> > +     * domain_save_begin(), there should have been more data.
> > +     */
> > +    if ( c->desc.length !=3D c->data_len )
>=20
> This suggests you know in advance the size of the record.

That depends on what you mean by 'in advance'. I'd expect the caller of =
domain_save_begin() to know exactly.

> I have seen
> some cases where we don't know the size in advance. A good example if
> when saving grants. You know the maximum of grant used by the guest =
but
> you don't know yet the number of grants used. You might need to walk =
the
> "list" twice or allocate a temporary buffer. None of them are ideal.
>=20
> Another example is when saving memory, we may want to compact page
> informations to save space.
>=20
> This problem is going to be more relevant for LiveUpdate where we need
> to be able to create the stream in a very short amount of time.
> Allocating any temporary buffer and/or walking the list twice is going
> to kill the performance.
>=20
> I would suggest to consider a different approach where you update the
> record length at the end.
>=20
> FWIW, this below the current approach for the LU stream (IIRC David =
sent
> a prototype recently). A record is opened using =
lu_stream_open_record(),
> you then have two way to add data:
>      - lu_stream_append() -> This takes a buffer and write to the =
stream.
>      - lu_stream_reserve() -> Pre-allocate space in the stream and
> return a pointer to the beginning of the reserved region.
>      - lu_stream_end_reservation() -> Takes the actual size in =
parameter
> and update the stream size.
>      - lu_stream_close_record() -> Update the header with the total
> length and update the position in the stream.
>=20

That sounds quite LU specific. For LM we still need to know up-front the =
maximal size of the buffer, and I was trying to work on the basis of =
never having to update previously saved data but I guess there's no =
actual harm in doing so, so we could avoid domain_save_begin() =
specifying the length.

> > +        return -EIO;
>=20
> I noticed that all the pasding check have been dropped. I still think =
we
> need implicit padding to harden the code.
>=20

I'd still view that as buggy code.

> > +
> > +    c->data_len =3D 0;
> > +
> > +    return 0;
> > +}
> > +
> > +int domain_save(struct domain *d, domain_write_entry write, void =
*priv,
> > +                bool dry_run)
> > +{
> > +    struct domain_context c =3D {
> > +        .copy.write =3D write,
> > +        .priv =3D priv,
> > +        .log =3D !dry_run,
> > +    };
> > +    struct domain_save_header h =3D {
> > +        .magic =3D DOMAIN_SAVE_MAGIC,
> > +        .version =3D DOMAIN_SAVE_VERSION,
> > +    };
> > +    struct domain_save_header e;
> > +    unsigned int i;
> > +    int rc;
> > +
> > +    ASSERT(d !=3D current->domain);
> > +
> > +    if ( d->is_dying )
>=20
> I can't find an answer to my question about d->is_dying. What if the
> guest die afterwards? What does protect us against domain_kill()?
>=20
> [...]

As I said in a previous response, nothing protects against =
domain_kill(), this check is just supposed to avoid doing 'unnecessary' =
work for a domain we know is already dying. For LU though I guess we do =
need to save (some) state for even a dying domain, so the individual =
save handlers actually need to make the decision on whether they are =
going to do anything.

>=20
> > +int domain_load(struct domain *d, domain_read_entry read, void =
*priv)
> > +{
> > +    struct domain_context c =3D {
> > +        .copy.read =3D read,
> > +        .priv =3D priv,
> > +        .log =3D true,
> > +    };
> > +    struct domain_save_header h;
> > +    int rc;
> > +
> > +    ASSERT(d !=3D current->domain);
> > +
> > +    if ( d->is_dying )
> > +        return -EINVAL;
>=20
> Same here.
>=20
>=20
> > diff --git a/xen/include/public/save.h b/xen/include/public/save.h
> > new file mode 100644
> > index 0000000000..7e5f8752bd
> > --- /dev/null
> > +++ b/xen/include/public/save.h
> > @@ -0,0 +1,84 @@
> > +/*
> > + * save.h
> > + *
> > + * Structure definitions for common PV/HVM domain state that is =
held by
> > + * Xen and must be saved along with the domain's memory.
> > + *
> > + * Copyright Amazon.com Inc. or its affiliates.
> > + *
> > + * Permission is hereby granted, free of charge, to any person =
obtaining a copy
> > + * of this software and associated documentation files (the =
"Software"), to
> > + * deal in the Software without restriction, including without =
limitation the
> > + * rights to use, copy, modify, merge, publish, distribute, =
sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the =
Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be =
included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, =
EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF =
MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO =
EVENT SHALL THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR =
OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, =
ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR =
OTHER
> > + * DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#ifndef __XEN_PUBLIC_SAVE_H__
> > +#define __XEN_PUBLIC_SAVE_H__
>=20
> Does this header need to be exposed outside of Xen and the tools?
>=20

Probably not.

> > +
> > +#include "xen.h"
> > +
> > +/* Each entry is preceded by a descriptor */
> > +struct domain_save_descriptor {
> > +    uint16_t typecode;
> > +    /*
> > +     * Each entry will contain either to global or per-vcpu domain =
state.
> > +     * Entries relating to global state should have zero in this =
field.
> > +     */
> > +    uint16_t vcpu_id;
> > +    uint32_t flags;
> > +    /*
> > +     * When restoring state this flag can be set in a descriptor to =
cause
> > +     * its content to be ignored.
>=20
> Could you give examples where you would want to ignore a descriptor?
>=20

I was thinking of the case when, e.g. you want to update something in =
the shared_info... You save a context blob, modify the shared_info =
record, and then restore the context blob with all other records marked =
as 'ignore' since they have not been modified.

> > +     *
> > +     * NOTE: It is invalid to set this flag for HEADER or END =
records (see
> > +     *       below).
> > +     */
> > +#define _DOMAIN_SAVE_FLAG_IGNORE 0
> > +#define DOMAIN_SAVE_FLAG_IGNORE (1u << _DOMAIN_SAVE_FLAG_IGNORE)
> > +
> > +    /* Entry length not including this descriptor */
> > +    uint64_t length;
> > +};
> > +
> > +/*
> > + * Each entry has a type associated with it. =
DECLARE_DOMAIN_SAVE_TYPE
> > + * binds these things together.
> > + */
> > +#define DECLARE_DOMAIN_SAVE_TYPE(_x, _code, _type) \
> > +    struct __DOMAIN_SAVE_TYPE_##_x { char c[_code]; _type t; };
> > +
> > +#define DOMAIN_SAVE_CODE(_x) \
> > +    (sizeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->c))
> > +#define DOMAIN_SAVE_TYPE(_x) \
> > +    typeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->t)
> > +
> > +/* Terminating entry */
> > +struct domain_save_end {};
> > +DECLARE_DOMAIN_SAVE_TYPE(END, 0, struct domain_save_end);
> > +
> > +#define DOMAIN_SAVE_MAGIC   0x53415645
> > +#define DOMAIN_SAVE_VERSION 0x00000001
> > +
> > +/* Initial entry */
> > +struct domain_save_header {
> > +    uint32_t magic;             /* Must be DOMAIN_SAVE_MAGIC */
> > +    uint32_t version;           /* Save format version */
>=20
>=20
> I haven't seen any answer about xen version here. For the record:
>=20
> "Let's imagine in 4.14 we introduced a bug in the saving part. This is
> solved in 4.15 but somehow the version is not bumped. How would you
> differentiate the streams saved by Xen 4.14 so you can still migrate?

I'd assume testing would at least save and restore on 4.14. If we then =
fixed a bug then why would we not bump the version?

>=20
> If you record the version of Xen in the record automatically, then you
> at least have a way to differentiate the two versions."
>=20

OK, I guess redundant version information is not going to be harmful.

  Paul



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:36:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSHQ-0005pI-CO; Tue, 28 Apr 2020 15:36:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTSHP-0005p9-1H
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:36:15 +0000
X-Inumbo-ID: fe512bc2-8965-11ea-ae69-bc764e2007e4
Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fe512bc2-8965-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 15:36:14 +0000 (UTC)
Received: by mail-wm1-x344.google.com with SMTP id k12so3292043wmj.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 08:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=sZw6wmR3//GO8uGKaUgt+ATL89wawQJw2yUmRNDpiTs=;
 b=pRlghg/fl+V23+w3Fq2+oKZe4Q7u7kpX0v1uekaE4woddTOLnJPcpOvmgQyln4GaFY
 DFxtptWv6O9RGVtIjYSe0j5woda65qV/NkFff+NP8Z+6XBW4M7wDwedLMNgu0i3pEWb7
 Dq1zcYr2tFgi+zeMdLe4Qo7URqD2RDhmBZH+1vAGHWAydkU9OKwtt8kV1qX1aR1/WG8y
 VjfsyLk9Yi8LRTtZrW8lH8BVsY1le4LEKXJe0yo7YqEz7CaZvBRatx86gMsCl5UZvEn8
 /J3uFkZGnV28GADzQkM6cbIazNd/jKUQRudhKCxGQrKOES18+0cqorwGIWrQLEkloHsx
 AMKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=sZw6wmR3//GO8uGKaUgt+ATL89wawQJw2yUmRNDpiTs=;
 b=Bp8ji7BEu/K5EXDypoOQN6CVSata/xls+W2HHfpg7T1jburYrztS0NxzGzBMAw6P+S
 nKgTAvyLIVvJg5b3ZBIGF68XCDbHhchRTuVf1uT6OgwiRboFFIx4vzP312B27UWS+wZ9
 iWIfXNFtr1OaW6BEnsw952qY4zljQmgxUCE267oVWXxMqg6lNBRhs0OsVjOQ+fbSllhl
 0A0V23VRKZCczetpChCgoGn9aCBRDv4s0v3mq/V+d68ma+Diw6mvhIobohXumkKVbQpf
 lJ9T1YGK/NjjbURmhFsqU37GLr4oPoU54HwHX422bIBORWpJxQT57kpK2KluTJKGWIHk
 hoUQ==
X-Gm-Message-State: AGi0PuaWO1vE6GTMVAF4XuCjR6LsDTgG7WLXgZx1MFCmAqc1KhCze+aM
 D2TAXbWqLRcWcwRmJ2WXckw=
X-Google-Smtp-Source: APiQypLpRYiCbEdKpYoZfdbhZaq1W+0LL3GbXHFxAujs5ZZChPAX12UUYq6QrA1sqdgXy55ZFQE7vA==
X-Received: by 2002:a7b:cb0c:: with SMTP id u12mr5683899wmj.137.1588088173603; 
 Tue, 28 Apr 2020 08:36:13 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id k133sm4189153wma.0.2020.04.28.08.36.11
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 08:36:12 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-3-paul@xen.org>
 <f4aa5e9f-4a1c-c02a-1cee-a43591492556@xen.org>
In-Reply-To: <f4aa5e9f-4a1c-c02a-1cee-a43591492556@xen.org>
Subject: RE: [PATCH v2 2/5] xen/common/domctl: introduce
 XEN_DOMCTL_get/setdomaincontext
Date: Tue, 28 Apr 2020 16:36:11 +0100
Message-ID: <001501d61d72$bf619910$3e24cb30$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQIOC3/NwyZzJjhdRz0oBcI7Is/lxwJNGvp/Abca5S6n/qyzMA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>,
 'Daniel De Graaf' <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 20 April 2020 18:26
> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Paul Durrant <pdurrant@amazon.com>; Daniel De Graaf <dgdegra@tycho.nsa.gov>; Ian Jackson
> <ian.jackson@eu.citrix.com>; Wei Liu <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; George
> Dunlap <george.dunlap@citrix.com>; Jan Beulich <jbeulich@suse.com>; Stefano Stabellini
> <sstabellini@kernel.org>
> Subject: Re: [PATCH v2 2/5] xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
> 
> Hi Paul,
> 
> On 07/04/2020 18:38, Paul Durrant wrote:
> > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> > index 1ad34c35eb..8ab39acf0c 100644
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -38,7 +38,7 @@
> >   #include "hvm/save.h"
> >   #include "memory.h"
> >
> > -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000012
> > +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000013
> >
> >   /*
> >    * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> > @@ -1129,6 +1129,44 @@ struct xen_domctl_vuart_op {
> >                                    */
> >   };
> >
> > +/*
> > + * Get/Set domain PV context. The same struct xen_domctl_domaincontext
> 
> I think you want to update the comments to match the split.

Oh yes.

> 
> > + * is used for both commands but with slightly different field semantics
> > + * as follows:
> 
> Reviewed-by: Julien Grall <jgrall@amazon.com>
> 

Thanks,

  Paul

> 
> Cheers,
> 
> 
> --
> Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:36:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:36:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSHv-0005u3-Lg; Tue, 28 Apr 2020 15:36:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Fewl=6M=gmail.com=wei.liu.linux@srs-us1.protection.inumbo.net>)
 id 1jTSHu-0005tq-FZ
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:36:46 +0000
X-Inumbo-ID: 1100b97c-8966-11ea-9885-12813bfff9fa
Received: from mail-wr1-f65.google.com (unknown [209.85.221.65])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1100b97c-8966-11ea-9885-12813bfff9fa;
 Tue, 28 Apr 2020 15:36:45 +0000 (UTC)
Received: by mail-wr1-f65.google.com with SMTP id d17so25188504wrg.11
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 08:36:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=gDQQvbPT3Kzf63XvecjBNGYEsk2bb2xd9NhLfULiqJg=;
 b=cjSlJUoKTogoeoKOW04Xhg+PRZJQ5mO37o+gijfepUxYBzE3B+xIgh6rT21B9t76dc
 mmNIW+BFNWpbZQpUFpSiIg3K1x3wdLDjzV7qdi0QqCUl3yHjZhVg2tMuErdTq3DGZhWa
 v+wmV3NMdSRqtnV8r3CS5HbncQG+DqxMbV/X9kipObBUx+HhlvK9xzojdoj+Kvs/avfr
 rPgf+NYh5hwJupm8gYBXVaV7x8vDi0Vp6OKcGLPmLeoPLNwAwwyU6uSmSsEo2Pc6C5Gv
 wB4HKZ2c0JdpvDQUW7RIunSGWp/zyIlfR/xLHf5p2x62wlaKkPeKB6OWVrun0ITS87yc
 hurQ==
X-Gm-Message-State: AGi0PuYHrrQ8qsDnJp7/hP6mnvCx2zJrJJ1+GRTXwRxjqZ1qmEvODWqI
 n2qzNRDNudQWALLM22Hi7uY=
X-Google-Smtp-Source: APiQypIOusuwAcr33CB5Ldy0/gal7sLr8hHFrxFgnuMNsSelBzKOp9T5ByiX4HEIJfDkRsL82eG/gw==
X-Received: by 2002:adf:84c2:: with SMTP id 60mr33197060wrg.65.1588088204974; 
 Tue, 28 Apr 2020 08:36:44 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id w12sm25355384wrk.56.2020.04.28.08.36.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Apr 2020 08:36:43 -0700 (PDT)
From: Wei Liu <wei.liu@kernel.org>
To: linux-pci@vger.kernel.org,
 Xen Development List <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/xen: drop an unused parameter gsi_override
Date: Tue, 28 Apr 2020 15:36:40 +0000
Message-Id: <20200428153640.76476-1-wei.liu@kernel.org>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Wei Liu <wei.liu@kernel.org>,
 sstabellini@kernel.org, konrad.wilk@oracle.com, x86@kernel.org,
 linux-kernel@vger.kernel.org, Michael Kelley <mikelley@microsoft.com>,
 boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

All callers within the same file pass in -1 (no override).

Signed-off-by: Wei Liu <wei.liu@kernel.org>
---
 arch/x86/pci/xen.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 91220cc25854..e3f1ca316068 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -60,8 +60,7 @@ static int xen_pcifront_enable_irq(struct pci_dev *dev)
 }
 
 #ifdef CONFIG_ACPI
-static int xen_register_pirq(u32 gsi, int gsi_override, int triggering,
-			     bool set_pirq)
+static int xen_register_pirq(u32 gsi, int triggering, bool set_pirq)
 {
 	int rc, pirq = -1, irq = -1;
 	struct physdev_map_pirq map_irq;
@@ -94,9 +93,6 @@ static int xen_register_pirq(u32 gsi, int gsi_override, int triggering,
 		name = "ioapic-level";
 	}
 
-	if (gsi_override >= 0)
-		gsi = gsi_override;
-
 	irq = xen_bind_pirq_gsi_to_irq(gsi, map_irq.pirq, shareable, name);
 	if (irq < 0)
 		goto out;
@@ -112,12 +108,12 @@ static int acpi_register_gsi_xen_hvm(struct device *dev, u32 gsi,
 	if (!xen_hvm_domain())
 		return -1;
 
-	return xen_register_pirq(gsi, -1 /* no GSI override */, trigger,
+	return xen_register_pirq(gsi, trigger,
 				 false /* no mapping of GSI to PIRQ */);
 }
 
 #ifdef CONFIG_XEN_DOM0
-static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polarity)
+static int xen_register_gsi(u32 gsi, int triggering, int polarity)
 {
 	int rc, irq;
 	struct physdev_setup_gsi setup_gsi;
@@ -128,7 +124,7 @@ static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polar
 	printk(KERN_DEBUG "xen: registering gsi %u triggering %d polarity %d\n",
 			gsi, triggering, polarity);
 
-	irq = xen_register_pirq(gsi, gsi_override, triggering, true);
+	irq = xen_register_pirq(gsi, triggering, true);
 
 	setup_gsi.gsi = gsi;
 	setup_gsi.triggering = (triggering == ACPI_EDGE_SENSITIVE ? 0 : 1);
@@ -148,7 +144,7 @@ static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polar
 static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
 				 int trigger, int polarity)
 {
-	return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, polarity);
+	return xen_register_gsi(gsi, trigger, polarity);
 }
 #endif
 #endif
@@ -491,7 +487,7 @@ int __init pci_xen_initial_domain(void)
 		if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
 			continue;
 
-		xen_register_pirq(irq, -1 /* no GSI override */,
+		xen_register_pirq(irq,
 			trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE,
 			true /* Map GSI to PIRQ */);
 	}
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:37:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSIk-00062U-0L; Tue, 28 Apr 2020 15:37:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xCBN=6M=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTSIi-00062K-Dg
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:37:36 +0000
X-Inumbo-ID: 2e888844-8966-11ea-9887-bc764e2007e4
Received: from mail-wr1-x432.google.com (unknown [2a00:1450:4864:20::432])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2e888844-8966-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 15:37:35 +0000 (UTC)
Received: by mail-wr1-x432.google.com with SMTP id b11so25165612wrs.6
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 08:37:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=hRYwxPFLHwj8CVn3Z8B1w3R87u1K31acM/EV4UOOpmU=;
 b=oMrXPqb2Oz7Fae5LM2feUPLVhTSvYHrxLXEwT7Y0S4Ii6WjDM5bp7tFVK9KO0hGwQ7
 o5DX7Yn4nB0F84B7l5aHRAeqXQSqSZiUkely3xp8d1OaRP8iETpb1+YgTyrrInOHQdMz
 RB7XkMwpscAcGVGGiMJqt/5x71q+7udnLcNzk1Ktar0ZDNkeoBL8bkY9pqPcvwvz3bNp
 KS5HThU5Cjq9DwReqw0tlvy/0YA3wOwGgkPzwqwHt/a4mVgycdv3lLLJ/MkH9uoXl2AX
 zDmmGOC8Fa2xZSRVn9LxyYv+kqXNPVzb/TJ7+W9Y38PqWUQ2sB8asRVBFPafT5EXMrwQ
 Fb+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=hRYwxPFLHwj8CVn3Z8B1w3R87u1K31acM/EV4UOOpmU=;
 b=YWB9/xD8BSeLIeDEiuew1yMd7Yp+Se3QXo8AmaAAvlfdqqatpNbNn+rLcofk4eKHES
 UcRjrLThuYfY/HI48FpnLqC0wY3CabUTz6SDqRzCGMFhDDLKy7kflhJW/km0Mu9CD5wA
 lAa8vMgjJjdtMEnugAVbsRwI+9ncZOui3lUWF++1U3Cze0LXgK3B98/t7y1cdGBjL60B
 z+nPoFcy/e4oGtGb4zIvxrgR5exIWVOlKPM3hZp3aeKDiKD4FFAKfbd3miv+yMMMDT7x
 4jRY+jBQMsqchD/WC7EYMSzkR2dT+bBOxYtyUXd/YSkMYufA2YP6mGzioV2kDih4glKO
 ApBQ==
X-Gm-Message-State: AGi0PuYk07tBIBjubGydFRGEKVeAP5wId3frBpoInS69o5sb08UKuaDL
 ufjl+cVMIbujbtpKXkhMbZ0=
X-Google-Smtp-Source: APiQypLOL8BqwVPA1RpYH8LBHUM+RBTIsWULv9hfsmarBGHNKon21M+JAtfhMf0+D/R+00uEbYnrZQ==
X-Received: by 2002:adf:cc81:: with SMTP id p1mr36049277wrj.372.1588088254520; 
 Tue, 28 Apr 2020 08:37:34 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id w10sm27108845wrg.52.2020.04.28.08.37.33
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 28 Apr 2020 08:37:33 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-5-paul@xen.org>
 <7f0821ed-34e8-2a63-aaab-bf781fdfb9e7@xen.org>
In-Reply-To: <7f0821ed-34e8-2a63-aaab-bf781fdfb9e7@xen.org>
Subject: RE: [PATCH v2 4/5] common/domain: add a domain context record for
 shared_info...
Date: Tue, 28 Apr 2020 16:37:32 +0100
Message-ID: <001601d61d72$efb23840$cf16a8c0$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQIOC3/NwyZzJjhdRz0oBcI7Is/lxwI2behTA1TXHdCn8nRy4A==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: 20 April 2020 18:35
> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Cc: Paul Durrant <pdurrant@amazon.com>; Ian Jackson <ian.jackson@eu.citrix.com>; Wei Liu <wl@xen.org>;
> Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap <george.dunlap@citrix.com>; Jan Beulich
> <jbeulich@suse.com>; Stefano Stabellini <sstabellini@kernel.org>
> Subject: Re: [PATCH v2 4/5] common/domain: add a domain context record for shared_info...
> 
> Hi Paul,
> 
> On 07/04/2020 18:38, Paul Durrant wrote:
> > ... and update xen-domctx to dump some information describing the record.
> >
> > Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> > ---
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Wei Liu <wl@xen.org>
> > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: George Dunlap <george.dunlap@citrix.com>
> > Cc: Jan Beulich <jbeulich@suse.com>
> > Cc: Julien Grall <julien@xen.org>
> > Cc: Stefano Stabellini <sstabellini@kernel.org>
> >
> > v2:
> >   - Drop the header change to define a 'Xen' page size and instead use a
> >     variable length struct now that the framework makes this is feasible
> >   - Guard use of 'has_32bit_shinfo' in common code with CONFIG_COMPAT
> > ---
> >   tools/misc/xen-domctx.c   | 11 ++++++
> >   xen/common/domain.c       | 81 +++++++++++++++++++++++++++++++++++++++
> >   xen/include/public/save.h | 10 ++++-
> >   3 files changed, 101 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/misc/xen-domctx.c b/tools/misc/xen-domctx.c
> > index d663522a8b..a8d3922321 100644
> > --- a/tools/misc/xen-domctx.c
> > +++ b/tools/misc/xen-domctx.c
> > @@ -59,6 +59,16 @@ static void dump_header(struct domain_save_descriptor *desc)
> >       off += desc->length;
> >   }
> >
> > +static void dump_shared_info(struct domain_save_descriptor *desc)
> > +{
> > +    DOMAIN_SAVE_TYPE(SHARED_INFO) s;
> > +    READ(s);
> > +    printf("    SHARED_INFO: field_width %u buffer size: %lu\n",
> > +           s.field_width, desc->length - sizeof(s));
> > +
> > +    off += desc->length;
> > +}
> > +
> >   static void dump_end(struct domain_save_descriptor *desc)
> >   {
> >       DOMAIN_SAVE_TYPE(END) e;
> > @@ -125,6 +135,7 @@ int main(int argc, char **argv)
> >           switch (desc.typecode)
> >           {
> >           case DOMAIN_SAVE_CODE(HEADER): dump_header(&desc); break;
> > +        case DOMAIN_SAVE_CODE(SHARED_INFO): dump_shared_info(&desc); break;
> >           case DOMAIN_SAVE_CODE(END): dump_end(&desc); return 0;
> >           default:
> >               printf("Unknown type %u: skipping\n", desc.typecode);
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 3dcd73f67c..8b72462e07 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -33,6 +33,7 @@
> >   #include <xen/xenoprof.h>
> >   #include <xen/irq.h>
> >   #include <xen/argo.h>
> > +#include <xen/save.h>
> >   #include <asm/debugger.h>
> >   #include <asm/p2m.h>
> >   #include <asm/processor.h>
> > @@ -1646,6 +1647,86 @@ int continue_hypercall_on_cpu(
> >       return 0;
> >   }
> >
> > +static int save_shared_info(const struct vcpu *v, struct domain_context *c,
> > +                            bool dry_run)
> > +{
> > +    struct domain *d = v->domain;
> > +    struct domain_shared_info_context ctxt = {};
> > +    size_t hdr_size = offsetof(typeof(ctxt), buffer);
> > +    size_t size = hdr_size + PAGE_SIZE;
> > +    int rc;
> > +
> > +    rc = DOMAIN_SAVE_BEGIN(SHARED_INFO, c, v, size);
> > +    if ( rc )
> > +        return rc;
> > +
> > +    if ( !dry_run )
> 
> NIT: I think the if is not necessary here as you don't skip that much code.
> 

I know, but it is illustrative so I'd rather keep it.

> > +        ctxt.field_width =
> > +#ifdef CONFIG_COMPAT
> > +            has_32bit_shinfo(d) ? 4 :
> > +#endif
> > +            8;
> > +
> > +    rc = domain_save_data(c, &ctxt, hdr_size);
> > +    if ( rc )
> > +        return rc;
> > +
> > +    rc = domain_save_data(c, d->shared_info, PAGE_SIZE);
> > +    if ( rc )
> > +        return rc;
> > +
> > +    return domain_save_end(c);
> > +}
> > +
> > +static int load_shared_info(struct vcpu *v, struct domain_context *c)
> > +{
> > +    struct domain *d = v->domain;
> > +    struct domain_shared_info_context ctxt = {};
> > +    size_t hdr_size = offsetof(typeof(ctxt), buffer);
> > +    size_t size = hdr_size + PAGE_SIZE;
> > +    unsigned int i;
> > +    int rc;
> > +
> > +    rc = DOMAIN_LOAD_BEGIN(SHARED_INFO, c, v, size, true);
> > +    if ( rc )
> > +        return rc;
> > +
> > +    rc = domain_load_data(c, &ctxt, hdr_size);
> > +    if ( rc )
> > +        return rc;
> > +
> > +    for ( i = 0; i < ARRAY_SIZE(ctxt.pad); i++ )
> > +        if ( ctxt.pad[i] )
> > +            return -EINVAL;
> > +
> > +    switch ( ctxt.field_width )
> > +    {
> > +#ifdef CONFIG_COMPAT
> > +    case 4:
> > +        d->arch.has_32bit_shinfo = 1;
> > +        break;
> > +#endif
> > +    case 8:
> > +#ifdef CONFIG_COMPAT
> > +        d->arch.has_32bit_shinfo = 0;
> > +#endif
> > +        break;
> > +
> > +    default:
> > +        rc = -EINVAL;
> > +        break;
> > +    }
> > +
> > +    rc = domain_load_data(c, d->shared_info, PAGE_SIZE);
> > +    if ( rc )
> > +        return rc;
> > +
> > +    return domain_load_end(c);
> > +}
> > +
> > +DOMAIN_REGISTER_SAVE_RESTORE(SHARED_INFO, false, save_shared_info,
> > +                             load_shared_info);
> > +
> >   /*
> >    * Local variables:
> >    * mode: C
> > diff --git a/xen/include/public/save.h b/xen/include/public/save.h
> > index 7e5f8752bd..ed994a8765 100644
> > --- a/xen/include/public/save.h
> > +++ b/xen/include/public/save.h
> > @@ -79,6 +79,14 @@ struct domain_save_header {
> >   };
> >   DECLARE_DOMAIN_SAVE_TYPE(HEADER, 1, struct domain_save_header);
> >
> > -#define DOMAIN_SAVE_CODE_MAX 1
> > +struct domain_shared_info_context {
> > +    uint8_t field_width;
> > +    uint8_t pad[7];
> > +    uint8_t buffer[]; /* Implementation specific size */
> 
> I would recommend to use buffer[XEN_FLEX_ARRAY_DIM].
> 

Ok.

  Paul

> Cheers,
> 
> --
> Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:49:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:49:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSUI-0007AM-98; Tue, 28 Apr 2020 15:49:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=KfNV=6M=xen.org=wl@srs-us1.protection.inumbo.net>)
 id 1jTSUH-0007AH-0P
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:49:33 +0000
X-Inumbo-ID: da310ce2-8967-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id da310ce2-8967-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 15:49:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
 :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID
 :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:
 Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe
 :List-Post:List-Owner:List-Archive;
 bh=KPzvRysY2ohXq7P+b0bo07gMgLcm6XfJbumUCT2gh1o=; b=i9hHPfTJ3GQO43bqutkwlBGmaE
 DkZyg+WqC2aehZxhUmmkaCj+wV9a5njhYHUurL1UqH0ndbwnmRCWzaaDEiojEFTJbKkNErxtSJZMe
 5fjjeOL2oy/50IXLBVYPZKId+4KM4NPboP6L5b2jryNfTUrAx4wfRl/YoiiDisHXW5HM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <wl@xen.org>)
 id 1jTSUF-0007YH-Ha; Tue, 28 Apr 2020 15:49:31 +0000
Received: from 44.142.6.51.dyn.plus.net ([51.6.142.44] helo=debian)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <wl@xen.org>)
 id 1jTSUF-0006UT-8F; Tue, 28 Apr 2020 15:49:31 +0000
Date: Tue, 28 Apr 2020 16:49:28 +0100
From: Wei Liu <wl@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
Message-ID: <20200428154928.nrhnl6xln2ci5qrf@debian>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
 <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Hongyan Xia <hx242@xen.org>, julien@xen.org, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 28, 2020 at 05:33:29PM +0200, Jan Beulich wrote:
> On 17.04.2020 11:52, Hongyan Xia wrote:
> > --- a/xen/arch/x86/pv/dom0_build.c
> > +++ b/xen/arch/x86/pv/dom0_build.c
> > @@ -50,17 +50,17 @@ static __init void mark_pv_pt_pages_rdonly(struct domain *d,
> >      unsigned long count;
> >      struct page_info *page;
> >      l4_pgentry_t *pl4e;
> > -    l3_pgentry_t *pl3e;
> > -    l2_pgentry_t *pl2e;
> > -    l1_pgentry_t *pl1e;
> > +    l3_pgentry_t *pl3e, *l3t;
> > +    l2_pgentry_t *pl2e, *l2t;
> > +    l1_pgentry_t *pl1e, *l1t;
> 
> I don't quite see why the new local variables get introduced:
> unmap_domain_page(), iirc, is quite fine with a non-page-
> aligned argument.

(Assuming this is actually written by me)

I wanted to make things abundantly clear: plXe points to an entry while
lXt points to the start of a page table.

In a long function the distinction could be helpful; in a short function
(like this one?) not so much.

Wei.

> 
> Jan


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:51:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSWU-00081d-M5; Tue, 28 Apr 2020 15:51:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=DYx7=6M=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTSWT-00081Y-Gy
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:51:49 +0000
X-Inumbo-ID: 2b4cbcde-8968-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2b4cbcde-8968-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 15:51:48 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2BA73AC85;
 Tue, 28 Apr 2020 15:51:47 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
Date: Tue, 28 Apr 2020 17:51:44 +0200
Message-Id: <20200428155144.8253-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
of the domain's xenstore ring page and the event channel of the
domain for communicating with Xenstore.

The gfn is not really needed. It is stored in the per-domain struct
in xenstored and in case of another XS_INTRODUCE for the domain it
is tested to match the original value. If it doesn't match the
command is aborted via EINVAL.

Today there shouldn't be multiple XS_INTRODUCE requests for the same
domain issued, so the mfn/gfn can just be ignored and multiple
XS_INTRODUCE commands can be rejected without testing the mfn/gfn.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/xenstore/xenstored_domain.c | 47 ++++++++++++++++-----------------------
 1 file changed, 19 insertions(+), 28 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 5858185211..17328f9fc9 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -369,7 +369,6 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
 	struct domain *domain;
 	char *vec[3];
 	unsigned int domid;
-	unsigned long mfn;
 	evtchn_port_t port;
 	int rc;
 	struct xenstore_domain_interface *interface;
@@ -381,7 +380,7 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
 		return EACCES;
 
 	domid = atoi(vec[0]);
-	mfn = atol(vec[1]);
+	/* Ignore the mfn, we don't need it. */
 	port = atoi(vec[2]);
 
 	/* Sanity check args. */
@@ -390,34 +389,26 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
 
 	domain = find_domain_by_domid(domid);
 
-	if (domain == NULL) {
-		interface = map_interface(domid);
-		if (!interface)
-			return errno;
-		/* Hang domain off "in" until we're finished. */
-		domain = new_domain(in, domid, port);
-		if (!domain) {
-			rc = errno;
-			unmap_interface(interface);
-			return rc;
-		}
-		domain->interface = interface;
-		domain->mfn = mfn;
-
-		/* Now domain belongs to its connection. */
-		talloc_steal(domain->conn, domain);
-
-		fire_watches(NULL, in, "@introduceDomain", false);
-	} else if ((domain->mfn == mfn) && (domain->conn != conn)) {
-		/* Use XS_INTRODUCE for recreating the xenbus event-channel. */
-		if (domain->port)
-			xenevtchn_unbind(xce_handle, domain->port);
-		rc = xenevtchn_bind_interdomain(xce_handle, domid, port);
-		domain->port = (rc == -1) ? 0 : rc;
-		domain->remote_port = port;
-	} else
+	if (domain)
 		return EINVAL;
 
+	interface = map_interface(domid);
+	if (!interface)
+		return errno;
+	/* Hang domain off "in" until we're finished. */
+	domain = new_domain(in, domid, port);
+	if (!domain) {
+		rc = errno;
+		unmap_interface(interface);
+		return rc;
+	}
+	domain->interface = interface;
+
+	/* Now domain belongs to its connection. */
+	talloc_steal(domain->conn, domain);
+
+	fire_watches(NULL, in, "@introduceDomain", false);
+
 	domain_conn_reset(domain);
 
 	send_ack(conn, XS_INTRODUCE);
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:55:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSaB-0008Gg-G5; Tue, 28 Apr 2020 15:55:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=i5jw=6M=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jTSaA-0008GV-DH
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:55:38 +0000
X-Inumbo-ID: b3ffbbd0-8968-11ea-988f-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b3ffbbd0-8968-11ea-988f-12813bfff9fa;
 Tue, 28 Apr 2020 15:55:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=a0ZAuTYZ7Ajr+Ft2sbyzrZuwe2LT3VI+hvVn/LVRoiM=; b=7Lcq6YUVJBJAGmzyP7Wr5Xg+GJ
 NUOnR7Xn/ez/dUyfv1Emn/Pqj/OOEFgXuI8hk6bG5djA26jlxOuvtorCRRe0hRE984zXrVNxdnsVw
 ICSGhqymtyQi3ANy8zbo6jm7mo1v30BUU0kroO5LY/1brw3kxo+FBVX2e7H2sIWwG3Wc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jTSa8-0007gQ-On; Tue, 28 Apr 2020 15:55:36 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=edge-cache-129.e-maa3.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jTSa8-0006wA-Ea; Tue, 28 Apr 2020 15:55:36 +0000
Message-ID: <9df9c5163fde5d25ceb756b20714c58be93b2c6c.camel@xen.org>
Subject: Re: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>
Date: Tue, 28 Apr 2020 16:55:34 +0100
In-Reply-To: <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
 <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, julien@xen.org,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, 2020-04-28 at 17:33 +0200, Jan Beulich wrote:
> On 17.04.2020 11:52, Hongyan Xia wrote:
> > --- a/xen/arch/x86/pv/dom0_build.c
> > +++ b/xen/arch/x86/pv/dom0_build.c
> > @@ -50,17 +50,17 @@ static __init void
> > mark_pv_pt_pages_rdonly(struct domain *d,
> >      unsigned long count;
> >      struct page_info *page;
> >      l4_pgentry_t *pl4e;
> > -    l3_pgentry_t *pl3e;
> > -    l2_pgentry_t *pl2e;
> > -    l1_pgentry_t *pl1e;
> > +    l3_pgentry_t *pl3e, *l3t;
> > +    l2_pgentry_t *pl2e, *l2t;
> > +    l1_pgentry_t *pl1e, *l1t;
> 
> I don't quite see why the new local variables get introduced:
> unmap_domain_page(), iirc, is quite fine with a non-page-
> aligned argument.

You are right, although in this function, where plXe points to may not
be the page we want to unmap. When plXe becomes aligned and points to a
new page, we actually want to unmap the page before it increments to an
aligned value.

Hongyan



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 15:59:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 15:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSe3-0008TY-5m; Tue, 28 Apr 2020 15:59:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=i5jw=6M=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jTSe1-0008TT-Ud
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 15:59:37 +0000
X-Inumbo-ID: 42b1ceae-8969-11ea-988f-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 42b1ceae-8969-11ea-988f-12813bfff9fa;
 Tue, 28 Apr 2020 15:59:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ppQsHtm98qZKijDsUilyUsTwOuED/FJ0k4mJz7RHGaY=; b=aaauZszztN5RoHmFkXUxKkRaSc
 5g9M8NlWe4yADOo6h9R0elWD+MEhOil1TCjUqnAgKt4x63PUl4UX/fH36IPtLNi6eBkl3MxuESuu2
 fwpK8VZ+7gBY+M30yO+kkoQOgYTUWx9DZoEwZoKI3cVDUZf/6zWvuDNy4Km4NW0f0AVQ=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jTSe0-0007mQ-BG; Tue, 28 Apr 2020 15:59:36 +0000
Received: from 54-240-197-228.amazon.com ([54.240.197.228]
 helo=edge-cache-129.e-maa3.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jTSe0-0007Df-0g; Tue, 28 Apr 2020 15:59:36 +0000
Message-ID: <c33dcaee9c8796da8816de9168f91ce90de61fc5.camel@xen.org>
Subject: Re: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>
Date: Tue, 28 Apr 2020 16:59:34 +0100
In-Reply-To: <9df9c5163fde5d25ceb756b20714c58be93b2c6c.camel@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
 <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
 <9df9c5163fde5d25ceb756b20714c58be93b2c6c.camel@xen.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, julien@xen.org,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, 2020-04-28 at 16:55 +0100, Hongyan Xia wrote:
> On Tue, 2020-04-28 at 17:33 +0200, Jan Beulich wrote:
> > On 17.04.2020 11:52, Hongyan Xia wrote:
> > > --- a/xen/arch/x86/pv/dom0_build.c
> > > +++ b/xen/arch/x86/pv/dom0_build.c
> > > @@ -50,17 +50,17 @@ static __init void
> > > mark_pv_pt_pages_rdonly(struct domain *d,
> > >      unsigned long count;
> > >      struct page_info *page;
> > >      l4_pgentry_t *pl4e;
> > > -    l3_pgentry_t *pl3e;
> > > -    l2_pgentry_t *pl2e;
> > > -    l1_pgentry_t *pl1e;
> > > +    l3_pgentry_t *pl3e, *l3t;
> > > +    l2_pgentry_t *pl2e, *l2t;
> > > +    l1_pgentry_t *pl1e, *l1t;
> > 
> > I don't quite see why the new local variables get introduced:
> > unmap_domain_page(), iirc, is quite fine with a non-page-
> > aligned argument.
> 
> You are right, although in this function, where plXe points to may
> not
> be the page we want to unmap. When plXe becomes aligned and points to
> a
> new page, we actually want to unmap the page before it increments to
> an
> aligned value.

Hmm, we can just unmap(plXe - 1) if my logic is correct, and save 3
local variables.

Hongyan



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 16:09:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 16:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSns-0001Zd-6h; Tue, 28 Apr 2020 16:09:48 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=g9hW=6M=yahoo.com=akm2tosher@srs-us1.protection.inumbo.net>)
 id 1jTSnq-0001ZX-UJ
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 16:09:47 +0000
X-Inumbo-ID: adab919e-896a-11ea-9898-12813bfff9fa
Received: from sonic306-21.consmr.mail.ne1.yahoo.com (unknown [66.163.189.83])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id adab919e-896a-11ea-9898-12813bfff9fa;
 Tue, 28 Apr 2020 16:09:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1588090185; bh=OAdW46J7CromgWWVcRHytxOrM8LrphxeB10hAjaElg8=;
 h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject;
 b=AQWUDM/XObwjc54jqMlTuW82NZVI1Kg22sEzNAogV/L6XZLOzif2nUBTxvOafACuwzZE9Lo4W3qpKi/cOIswTOM3GpoIfnMf4DzXI0NIpigLBG/5kUQqDz9EX6s6LQZDqs0GPnC+IIKWoRrpnoAPSWrP5c7wSNbF/I+YFaNYxX5StBDBCGZYzYO+hahY0LrcmnI5PI2iMGEQnvFAgavqAq7arlA7rUIa1C1gI3EmlqGy8VpLCsXndZ8gIxJMIoM4+M/uybkEdwuOBWViJAyatFe7Sne+8ARC0x60kLq6RYyjt2E5KU3JUuPaBfhODvkoOPJYEBxth6VtuCUdFzYnTg==
X-YMail-OSG: CvW6M8UVM1lbCE2JEsw6rZBOghZK.dYFcA4I4oqU2dxsGsH.RKNkVLFZjBpMyxd
 tgxtq1QMloyYXENcoP9ZzM57P0zTG4FIWvq4MOjCYuNFIOpXdHpXql_M.U3M7fxAGN2rT_15Voea
 3JRupSt4h7xOGrzp3BaBm7MqYjRx2OZm0kw4I.Hdl19OVh407yiL9mH6suvP4jpAUNIrCtKk1L4h
 CC6bxaVscNBytDlLD1BHFbxMmfcVEZ_cfSGzzBoq2Vfoa3p8WsnqNVR2gFu1TD_vD8p1FhXOk3dK
 _PgJp6hbiCveJupQPyptBsVvb5ZBdosQWda2euXom6WyOIZP0C.enQLbJbdEoJgpG5kxZfw.moU.
 KT66oCXxbtbx_mJ6thZ0fMeJpDOnEoIm61nUWMF19jTw5qMMACD1kAJsU.wTCXUGVjVgtegzRw3t
 fGplwGjNcxK47ymvp5dumBCw7AVlewED_8QOUcgeT7LlzG1BldoHG_ESxaleEbaqDaNhG8CjMqfG
 OvaOziXcSYIyHIqcnzotIAUze8P9K.IiaAfe2fK2IPPwnIo8CJa7LSPqQ_qdQ3DCtXKtDmqD1Io0
 paGiwhyYEX.xpsBZC5MRU5ZJ675aHvAyD3f2WwbD0YRw8XY27uKq5dlMuspMUJJHTGZM4FbPUNWl
 ssHCPLnARaLHvXIm3bULBYa5_gSxjKRU2MPIBv5Duz6FBu6zc76C9xvNaCL_NA3kZZw.cLZh9u2M
 l6U2MZFLNaRW5bueLiJgWwJ8jMEM0U3Sl2FVV1vz7YpTfYB3YzBJwOMnXqJYeyhpPbIz5UqBxdyK
 hOoHAgDjh1SZGrmGp8V7QGCSaUs9N3eittyNV1O9itKYMqt.4iQ0spAXVuibDe8FBmXSIFL0WWDy
 oncp2dqwGrIqpgkFlQ5QRQAmq2YLB7gzh6sTz09vU36Ta6WloHtGlJErU0vrIZMQbKS6GdXAenKf
 ZN85qhujHmI_jiIQj85kvQz_sKy81KKDtHeWwvbikzJ3TouI4MEatHfGJ4sz3jo23iFx9rXVltO1
 jNH4YWGmTp0fnWt8H.K7tCPDIfELBWydIBetfsSyA_12hS6Y91EH8Byusuv5wJV8v_tWiceS3hET
 4HJv2Ge_JNA0IffCcjsfnvo3fVpgeA7n0dNGvY2CPmYM5E58QnTAXyHJtWusC2S9wVOKc95aVKaK
 E6avTHwbE7rVjV2RKt6HzKsZiZzE.0xVxYnbFLJaK2R9A7rvuV0Q_9XiPNCZkcsZjqcod9Z0kOPy
 bRIEO6yeJB_jsZSFKGRZS2P1xY5L6cuYnrQ1iptFMFcoDsg1_wyXoc1kz4ys_Y41xgIF0yo5rfQz
 jB4tDWlJg7T3w0w04TZy6CBDvghma5UubgJYkH_ZFeQ--
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic306.consmr.mail.ne1.yahoo.com with HTTP; Tue, 28 Apr 2020 16:09:45 +0000
Date: Tue, 28 Apr 2020 16:08:08 +0000 (UTC)
From: tosher 1 <akm2tosher@yahoo.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Message-ID: <986397088.1609373.1588090088941@mail.yahoo.com>
In-Reply-To: <20200428070724.GS28601@Air-de-Roger>
References: <1359850718.562651.1587928713792.ref@mail.yahoo.com>
 <1359850718.562651.1587928713792@mail.yahoo.com>
 <20200427070317.GL28601@Air-de-Roger>
 <1693679742.27711.1588051435928@mail.yahoo.com>
 <20200428070724.GS28601@Air-de-Roger>
Subject: Re: Xen network domain performance for 10Gb NIC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.15756 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64;
 x64; rv:75.0) Gecko/20100101 Firefox/75.0
Content-Length: 278
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> Do you get the expected performance from the driver domain when not
> using it as a backend? Ie: running the iperf benchmarks directly on
> the driver domain and not on the guest.


Yes, the bandwidth between the driver domain and the client machine is close to 10Gbits/sec.


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 16:14:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 16:14:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSsH-0002U8-QW; Tue, 28 Apr 2020 16:14:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=p0bN=6M=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jTSsG-0002U2-KX
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 16:14:20 +0000
X-Inumbo-ID: 50745ac8-896b-11ea-ae69-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 50745ac8-896b-11ea-ae69-bc764e2007e4;
 Tue, 28 Apr 2020 16:14:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588090460;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=zq0Jx5MHlQZq+e3iKREbzZrUiDP1DyzQrc4wS1gRCRs=;
 b=CDLg+Gb12VRMV5wTqoVTvMF+b9O5mfvKahp42A2N2/CXbfB0X6LD39UZ
 n2HLWqwCXlzwOrHOsOIBvllh6ru8fqU57iX+FuSAWP5mESloudgWaSZF1
 lP/0gdDt1Hzz+9vFcR0LtsY5BGRzKzTZLUvlYzW0aG5fTzkOZwQgF6rq2 k=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: PjWnpGOBbuz85tqkA2j/L9iUdkjp2Jaip1l/lKs3PgLQd48ltaXueK86FHN6OHrnHffQkFw5Om
 77X+hF7YXXPFOcdOqC6hMVxcnqd8zHc3Ucw0mK/LINtUIVStN1EbeDCWqh/fNF+lFJLDmk7OtP
 tZzJLMzaRX56K1uZvkbZghHFvh0zjP9PusJot3ZcbKzm3Neex969aXuC7hNN7wnCMNwlxxXgfk
 prDl9OvNXz/qt2/VTSqARr9E5RQWp7004umGu8UJedUGi9lSueLfQ93QIVgge6Q1cX7MIwy+cp
 TFM=
X-SBRS: 2.7
X-MesageID: 16398089
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,328,1583211600"; d="scan'208";a="16398089"
Date: Tue, 28 Apr 2020 18:14:12 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86/pass-through: avoid double IRQ unbind during domain
 cleanup
Message-ID: <20200428161412.GU28601@Air-de-Roger>
References: <6fddc420-b582-cb2f-92ce-b3e067c420c4@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6fddc420-b582-cb2f-92ce-b3e067c420c4@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Varad Gautam <vrd@amazon.de>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 28, 2020 at 02:21:48PM +0200, Jan Beulich wrote:
> XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTs.
> In that scenario, it is possible to receive multiple _pirq_guest_unbind
> calls for the same pirq from domain_kill, if the pirq has not yet been
> removed from the domain's pirq_tree, as:
>   domain_kill()
>     -> domain_relinquish_resources()
>       -> pci_release_devices()
>         -> pci_clean_dpci_irq()
>           -> pirq_guest_unbind()
>             -> __pirq_guest_unbind()
> 
> Avoid recurring invocations of pirq_guest_unbind() by removing the pIRQ
> from the tree being iterated after the first call there. In case such a
> removed entry still has a softirq outstanding, record it and re-check
> upon re-invocation.
> 
> Reported-by: Varad Gautam <vrd@amazon.de>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Varad Gautam <vrd@amazon.de>
> 
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1323,7 +1323,7 @@ void (pirq_cleanup_check)(struct pirq *p
>      }
>  
>      if ( radix_tree_delete(&d->pirq_tree, pirq->pirq) != pirq )
> -        BUG();
> +        BUG_ON(!d->is_dying);

I think to keep the previous behavior this should be:

BUG_ON(!is_hvm_domain(d) || !d->is_dying);

Since the pirqs will only be removed elsewhere if the domain is HVM?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 16:22:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 16:22:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTSzh-0003Qj-Kb; Tue, 28 Apr 2020 16:22:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=p0bN=6M=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jTSzg-0003QD-5o
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 16:22:00 +0000
X-Inumbo-ID: 622fa5c8-896c-11ea-9887-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 622fa5c8-896c-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 16:21:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588090919;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=YEIR6lkiB/vvWUrTM9RuT9UpmhODMwm7qcp3z1l7Syg=;
 b=hf87GNqTcslMklKW547o2sY8noFIlPYHGMqPncqxaR9G6XZZT9FEZHYr
 zoEu+/zNN1RMMywmYn7UriK5+/JjWkByn/dNL5f/cLFlpcRlOD90pAvJH
 neddLK7Whxx/lblGEIiwbXriOsn/5Gohji1uLT7KAwZMf0AH6KXzJ+cuQ I=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: bwZcZLAWlNU4h0n7xoZC2L0JEoUdNnKIQDhL+bt+JH63mXf6EQZ3oCGzI1jYRm9Fgpp6ZtGRMb
 eaCf80bHkgFYU1zfJhwrPdrA0/j/CzKjucwaDxG8khv9hENPBwtal69vZ9ai+3KNQSffZlKv/1
 Lky6HJd30dwLknxI9o+XqKaRECxVsZEXjrw1qGT4IcO6DfYCmJFaHhecpWHVTFHV6CE81kwx/b
 UvP1fC0GsG4nF7iutPv4PQLHRgfZ2lpkgtll6KsZgwRHLwKQitmIzlAfhdo7LQRRRX5DcVhFgP
 YU4=
X-SBRS: 2.7
X-MesageID: 16637665
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,328,1583211600"; d="scan'208";a="16637665"
Date: Tue, 28 Apr 2020 18:21:52 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: tosher 1 <akm2tosher@yahoo.com>
Subject: Re: Xen network domain performance for 10Gb NIC
Message-ID: <20200428162152.GV28601@Air-de-Roger>
References: <1359850718.562651.1587928713792.ref@mail.yahoo.com>
 <1359850718.562651.1587928713792@mail.yahoo.com>
 <20200427070317.GL28601@Air-de-Roger>
 <1693679742.27711.1588051435928@mail.yahoo.com>
 <20200428070724.GS28601@Air-de-Roger>
 <986397088.1609373.1588090088941@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <986397088.1609373.1588090088941@mail.yahoo.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 28, 2020 at 04:08:08PM +0000, tosher 1 wrote:
> > Do you get the expected performance from the driver domain when not
> > using it as a backend? Ie: running the iperf benchmarks directly on
> > the driver domain and not on the guest.
> 
> 
> Yes, the bandwidth between the driver domain and the client machine is close to 10Gbits/sec.

Also note that doing grant map / unmap operations from HVM domains is
much more expensive than doing them from PV domains, even without an
IOMMU. Xen needs to modify the domain p2m and issue a flush, and then
the guest (usually) needs to map the newly populated memory in it's
page tables in order to access it.

This and the addition of the IOMMU TLB flush could well explain why
you are seeing such a degraded performance. I'm afraid the only way to
figure out exactly what is causing the bottleneck will be to time the
different operations in Xen. You can compare against a PV dom0 in
order to get an idea.

Roger.


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 16:31:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 16:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTT8P-0004K9-Jz; Tue, 28 Apr 2020 16:31:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qrdk=6M=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTT8O-0004JQ-Ir
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 16:31:00 +0000
X-Inumbo-ID: a0a34477-896d-11ea-989a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a0a34477-896d-11ea-989a-12813bfff9fa;
 Tue, 28 Apr 2020 16:30:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tkAdSzwU71cGa99Gk6P2HExpW+l7ZY3gBpyiDcQ1TA0=; b=IT5CXPGf6LWv3bGpr/ofRih/C
 piCGwNcv/6IYeiOWINsTvvQiXwQuLVtqP+EDLrUSUabj3K+t4I4TRKl2FuRvaVEsSNxhZoZOWFCOl
 egTZiKGRDleRWWDdkEOlZ5Dtc0oGh/E/skFmGkmX8LF4g4kCQsdomzUKWcnZ7iiMNX/zI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTT8H-0000XL-IX; Tue, 28 Apr 2020 16:30:53 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTT8H-0003Af-2B; Tue, 28 Apr 2020 16:30:53 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTT8H-0005oT-1e; Tue, 28 Apr 2020 16:30:53 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149842-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149842: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=df669de074c395a3b2eeb975fddd3da4c148da13
X-Osstest-Versions-That: xen=f093b08c47b39da6019421a2b61d40745b3e573b
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 28 Apr 2020 16:30:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149842 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149842/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149831
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149831
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149831
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149831
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149831
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149831
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149831
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149831
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149831
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149831
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  df669de074c395a3b2eeb975fddd3da4c148da13
baseline version:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b

Last test of basis   149831  2020-04-27 01:52:33 Z    1 days
Failing since        149835  2020-04-27 12:07:17 Z    1 days    2 attempts
Testing same since   149842  2020-04-27 23:38:49 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  George Dunlap <george.dunlap@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Nick Rosbrook <rosbrookn@ainfosec.com>
  Nick Rosbrook <rosbrookn@gmail.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f093b08c47..df669de074  df669de074c395a3b2eeb975fddd3da4c148da13 -> master


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 16:51:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 16:51:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTTRr-0006LW-QU; Tue, 28 Apr 2020 16:51:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qrdk=6M=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTTRq-0006LJ-0w
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 16:51:06 +0000
X-Inumbo-ID: 6e8e7f7a-8970-11ea-98a0-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6e8e7f7a-8970-11ea-98a0-12813bfff9fa;
 Tue, 28 Apr 2020 16:50:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=pf9vR48BdFStlr6bcXdtYkEt8EhnldQP4BFcrMC88dU=; b=0fp0Jx9vW6V+yoYPPgtYPYWaX
 dbE0bl/h/99zJs30NR+4ruJumaslM99knf3Nfu0gBBE+hJOn+BpOU8M8Xh1M2Jy3oSNVwFcAdBWnt
 kJyfnvCvs+3LZ5c6EoCafCb6DO3m3Kdysfot+I3+rQqGUX60EP73KK9YGsWDP3ooWOw8M=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTTRh-0000wb-2h; Tue, 28 Apr 2020 16:50:57 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTTRg-0003u6-Na; Tue, 28 Apr 2020 16:50:56 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTTRg-0003Ee-Mn; Tue, 28 Apr 2020 16:50:56 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149845-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.12-testing test] 149845: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: xen=e6a2681148382e9227f54b70a5df8e895914c877
X-Osstest-Versions-That: xen=3536f8dc39cc7311715340b87a04a89fac468406
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 28 Apr 2020 16:50:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149845 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149845/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow2    17 guest-localmigrate/x10       fail  like 149646
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 xen                  e6a2681148382e9227f54b70a5df8e895914c877
baseline version:
 xen                  3536f8dc39cc7311715340b87a04a89fac468406

Last test of basis   149646  2020-04-14 13:05:53 Z   14 days
Testing same since   149838  2020-04-27 14:06:02 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Harsha Shamsundara Havanur <havanur@amazon.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    fail    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   3536f8dc39..e6a2681148  e6a2681148382e9227f54b70a5df8e895914c877 -> stable-4.12


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 17:25:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 17:25:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTTyd-000150-Ut; Tue, 28 Apr 2020 17:24:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LWR1=6M=oracle.com=konrad.wilk@srs-us1.protection.inumbo.net>)
 id 1jTTyc-00014u-R9
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 17:24:58 +0000
X-Inumbo-ID: 2ee475f0-8975-11ea-b9cf-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2ee475f0-8975-11ea-b9cf-bc764e2007e4;
 Tue, 28 Apr 2020 17:24:58 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03SHMjTX035908;
 Tue, 28 Apr 2020 17:24:54 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=date : from : to : cc
 : subject : message-id : references : mime-version : content-type :
 in-reply-to : content-transfer-encoding; s=corp-2020-01-29;
 bh=a1DRwVeeZI8m8zRrIZSIlkJajtV66/ligL8DUqPAkjE=;
 b=aJO9db+uOkB7e+WYGZXpXPaUytTt5+432QDnBzrkB9IFcDAm8NdTKrnhgbvT90fu5xwA
 ZfS/N++Pru08Hu4sTwXFhs3NaEABtCV42M4IZQuMuD2W3Xh3GaaAYYYOStSePUOT7hV9
 X2IVRvEYZq+fIT+cLXn5Tzc5LR6tq0EOUUBG8ye13FKmxtE4HhmB8ifs7ueHYkXhU0CF
 j8EF6v8Nsr9DTn9Nu70LDxzl/C9xSaTsCawSc7q4yo1AyQF+vT+jhOtOfOfKiuAD1qSl
 0ca+4QpA2ZUocSNimSYRkVjffZRD5BnfNYy8KXGOidf4Ya6FwUWZ+oN3DnEkBmTVRRzF 3w== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by aserp2120.oracle.com with ESMTP id 30nucg1bx6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 28 Apr 2020 17:24:54 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03SHMxng050675;
 Tue, 28 Apr 2020 17:24:53 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by aserp3020.oracle.com with ESMTP id 30my0dseh2-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 28 Apr 2020 17:24:53 +0000
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03SHOpMO019149;
 Tue, 28 Apr 2020 17:24:52 GMT
Received: from char.us.oracle.com (/10.152.32.25)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 28 Apr 2020 10:24:51 -0700
Received: by char.us.oracle.com (Postfix, from userid 1000)
 id BC1D26A011D; Tue, 28 Apr 2020 13:25:14 -0400 (EDT)
Date: Tue, 28 Apr 2020 13:25:14 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, joe.jin@oracle.com
Subject: Re: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
Message-ID: <20200428172514.GA24178@char.us.oracle.com>
References: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
 <1c01e97a-adcd-a703-55b5-8975b4ce4d2c@suse.com>
 <DB6PR0402MB2760A05135338B0CBB28123488AC0@DB6PR0402MB2760.eurprd04.prod.outlook.com>
 <dba804ea-4268-24ff-7447-ddef00e9e20c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <dba804ea-4268-24ff-7447-ddef00e9e20c@suse.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 spamscore=0
 suspectscore=2 adultscore=0 mlxlogscore=999 bulkscore=0 phishscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004280137
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011
 priorityscore=1501
 mlxlogscore=999 impostorscore=0 suspectscore=2 malwarescore=0
 lowpriorityscore=0 mlxscore=0 spamscore=0 adultscore=0 phishscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004280137
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
 dl-linux-imx <linux-imx@nxp.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 28, 2020 at 12:19:41PM +0200, J=FCrgen Gro=DF wrote:
> On 28.04.20 10:25, Peng Fan wrote:

Adding Joe Jin.

Joe, didn't you have some ideas on how this could be implemented?

> > > Subject: Re: [PATCH] xen/swiotlb: correct the check for
> > > xen_destroy_contiguous_region
> > >=20
> > > On 28.04.20 09:33, peng.fan@nxp.com wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >=20
> > > > When booting xen on i.MX8QM, met:
> > > > "
> > > > [    3.602128] Unable to handle kernel paging request at virtual =
address
> > > 0000000000272d40
> > > > [    3.610804] Mem abort info:
> > > > [    3.613905]   ESR =3D 0x96000004
> > > > [    3.617332]   EC =3D 0x25: DABT (current EL), IL =3D 32 bits
> > > > [    3.623211]   SET =3D 0, FnV =3D 0
> > > > [    3.626628]   EA =3D 0, S1PTW =3D 0
> > > > [    3.630128] Data abort info:
> > > > [    3.633362]   ISV =3D 0, ISS =3D 0x00000004
> > > > [    3.637630]   CM =3D 0, WnR =3D 0
> > > > [    3.640955] [0000000000272d40] user address but active_mm is
> > > swapper
> > > > [    3.647983] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > > > [    3.654137] Modules linked in:
> > > > [    3.677285] Hardware name: Freescale i.MX8QM MEK (DT)
> > > > [    3.677302] Workqueue: events deferred_probe_work_func
> > > > [    3.684253] imx6q-pcie 5f000000.pcie: PCI host bridge to bus 0=
000:00
> > > > [    3.688297] pstate: 60000005 (nZCv daif -PAN -UAO)
> > > > [    3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0
> > > > [    3.693993] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > [    3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0
> > > > "
> > > >=20
> > > > In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <=3D dma_=
mask)
> > > > or range_straddles_page_boundary(phys, size) are true, it will cr=
eate
> > > > contiguous region. So when free, we need to free contiguous regio=
n use
> > > > upper check condition.
> > >=20
> > > No, this will break PV guests on x86.
> >=20
> > Could you share more details why alloc and free not matching for the =
check?
>=20
> xen_create_contiguous_region() is needed only in case:
>=20
> - the bus address is not within dma_mask, or
> - the memory region is not physically contiguous (can happen only for
>   PV guests)
>=20
> In any case it should arrange for the memory to be suitable for the
> DMA operation, so to be contiguous and within dma_mask afterwards. So
> xen_destroy_contiguous_region() should only ever called for areas
> which match above criteria, as otherwise we can be sure
> xen_create_contiguous_region() was not used for making the area DMA-abl=
e
> in the beginning.
>=20
> And this is very important in the PV case, as in those guests the page
> tables are containing the host-PFNs, not the guest-PFNS, and
> xen_create_contiguous_region() will fiddle with host- vs. guest-PFN
> arrangements, and xen_destroy_contiguous_region() is reverting this
> fiddling. Any call of xen_destroy_contiguous_region() for an area it
> was not intended to be called for might swap physical pages beneath
> random virtual addresses, which was the reason for this test to be
> added by me.
>=20
>=20
> Juergen
>=20
> >=20
> > Thanks,
> > Peng.
> >=20
> > >=20
> > > I think there is something wrong with your setup in combination wit=
h the ARM
> > > xen_create_contiguous_region() implementation.
> > >=20
> > > Stefano?
> > >=20
> > >=20
> > > Juergen
> > >=20
> > > >=20
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > >    drivers/xen/swiotlb-xen.c | 4 ++--
> > > >    1 file changed, 2 insertions(+), 2 deletions(-)
> > > >=20
> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.=
c
> > > > index b6d27762c6f8..ab96e468584f 100644
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwde=
v,
> > > size_t size, void *vaddr,
> > > >    	/* Convert the size to actually allocated. */
> > > >    	size =3D 1UL << (order + XEN_PAGE_SHIFT);
> > > >=20
> > > > -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> > > > -		     range_straddles_page_boundary(phys, size)) &&
> > > > +	if (((dev_addr + size - 1 > dma_mask) ||
> > > > +	    range_straddles_page_boundary(phys, size)) &&
> > > >    	    TestClearPageXenRemapped(virt_to_page(vaddr)))
> > > >    		xen_destroy_contiguous_region(phys, order);
> > > >=20
> > > >=20
> >=20
>=20


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 17:37:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 17:37:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTUAj-00027c-4x; Tue, 28 Apr 2020 17:37:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FM82=6M=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jTUAh-00027U-6J
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 17:37:27 +0000
X-Inumbo-ID: ec830c9c-8976-11ea-9887-bc764e2007e4
Received: from mail-lf1-x131.google.com (unknown [2a00:1450:4864:20::131])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ec830c9c-8976-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 17:37:26 +0000 (UTC)
Received: by mail-lf1-x131.google.com with SMTP id l11so17626457lfc.5
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 10:37:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=rWGQpfmnmwquRYh9uVw0uaulvFXrkfI1cdoNKjCi8X8=;
 b=H/Q4D4lsqj/iLKcvJf6EYGYH3vVgdCnlUmI1FtjBRVfnDgH6n0kbB8yMBy8GYxYYw5
 MGCDEbhyzzs5kcr8aMZvpYFTBVYC2XmbVTHjDE9aToQavlc4+DItyysjhCmDrH+tx4QI
 BsyaC2xgfWqSwc8t1M+77Pt8tu9BqG1IjEaPgb53c94LIeVZG6ZAHn/WIzJuD3MlfY+s
 nkTtUaD1PgBIx+Xm6fbfSEuV2+AChildm5juiRro11Z2WOzT3QC8qiYT0mXkfqSUT5oM
 CgjDhgbmQB9I9HaS2wLO7pS8rc8/BRbSAnekw12m82qRttYkIJZ7MgGkTfvG7CZFiDQ1
 SWng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=rWGQpfmnmwquRYh9uVw0uaulvFXrkfI1cdoNKjCi8X8=;
 b=jlZE5HnIl98pF5WslE3tkpPhnRLX0c7y6g5OvKRi+xAO7KBG2tqPdTVLuX9lJkMMu9
 AIxQcP223401+A2wWimO2A1FEXV3CR4kY7WwkXw2OjBRY2+i7kCKGqQAswFpF0bKR56A
 VZT/f44TXCLCjccc2szamywMwifj4JSCIsUBBNQ6672q9rrmbQ/2WoQhryTQnXyT8twm
 ZTbn4CL7686gwM2b6g/8XIyJjkjf9oKbKTIKGvlMZA/MhKr9qJXAJZszuh0Uv5TAwUCh
 oBqBIZaDOxDE7G57X/jJiiFkfW/AKAN2pfOZ6CjVrg06070YKGL5G8IauYpK5FW6Wbok
 wuAg==
X-Gm-Message-State: AGi0PuYHYVDirbEjAqxwBNcX2ciM5QRxxZp/3wZnkSMYpta76+OZeD/9
 94xqLO/XAPRMV99iQIh/FaztjtV1iDpIZtFwKBI=
X-Google-Smtp-Source: APiQypJa4QmBjZkGkyoxCWf61IrkuYYmhRnxUxUw/kU8pBeT4Sa9ntAqVwnptI9+yRsfyZyN9hlclii/EGwVRpZG340=
X-Received: by 2002:a05:6512:406:: with SMTP id
 u6mr20105978lfk.150.1588095444980; 
 Tue, 28 Apr 2020 10:37:24 -0700 (PDT)
MIME-Version: 1.0
References: <FC32A2FB-F339-4F3A-8237-0A4334ADF3D2@citrix.com>
 <24225.31493.220592.722565@mariner.uk.xensource.com>
 <24225.31669.536258.56822@mariner.uk.xensource.com>
 <4085F05B-ABEC-446A-8BB1-06DEE57D71A5@citrix.com>
 <C10E07AB-FDE8-4588-95E7-6109F0FDB5E2@citrix.com>
 <CAEBZRSfUysyGhnsXDEAJiVDBeX-Kb836V-uT6Qrtomte1LKgsA@mail.gmail.com>
 <E0DEA134-CB69-4992-B949-7233BFF3A1E4@citrix.com>
In-Reply-To: <E0DEA134-CB69-4992-B949-7233BFF3A1E4@citrix.com>
From: Nick Rosbrook <rosbrookn@gmail.com>
Date: Tue, 28 Apr 2020 13:37:12 -0400
Message-ID: <CAEBZRSfbjsSeh7ukKA8-PeuGRap986UzY1C8thB=ECryOUGFnA@mail.gmail.com>
Subject: Re: Golang Xen packages and the golang packaging system
To: George Dunlap <George.Dunlap@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <Ian.Jackson@citrix.com>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> BTW the separate repo isn=E2=80=99t off the table.  But there were some t=
hings other Ian pointed out:

After trying (and failing) to get a go module with a remote import
path like `golang.xenproject.org/xenlight` defined in xen.git, I would
like to circle back to the separate repo.

In theory, modules are not supposed to be tightly coupled with vcs,
but in practice they are. It seems like you cannot define a module
with a remote import path without pointing to the repo *root*. I tried
many ways, but every attempt resulted in `go get enr0n.net/xenlight`
downloading the root of xen.git as the "module", while the actual
module in tools/golang/xenlight was excluded since it was seen as a
nested go module. If you want to get around these issues, I think you
would need to define your own module proxy. Or, we would need to just
give up on the "vanity" URL and use
`xenbits.xen.org/git-http/xen.git/tools/golang/xenlight` as the import
path.

For reference, I did get a test module `enr0n.net/xenlight` that
points to github.com/enr0n/xenlight working. That part is trivial if
you are able to point to the repo root.

Overall, between fighting with Go modules, tagging versions, and
making sure code is re-generated on IDL changes, it seems to me that
there are more negatives with putting the module in xen.git than there
are with putting the module in its own repo.

> 1. The GPL requires that you provide the =E2=80=9Cpreferred form for modi=
fication=E2=80=9D to all the code.  I=E2=80=99m not sure this has been adju=
dicated in court, but there=E2=80=99s a strong argument that *generated* co=
de doesn=E2=80=99t match that criteria: that to satisfy the GPL you=E2=80=
=99d need to include libxl_types.idl, idl.py, gengotypes.py, and a Makefile=
 suitable for tying them all together.  (Not that the generation needs to b=
e run with `go build`, but that ideally the infrastructure would be there s=
o that it *could* be run.)

Is there anything involved in solving this issue besides making sure
those files are copied to the repo in addition to the generated go
files? Or is there some concern in doing so?

> 2. Ian was concerned with how someone using the bindings would submit a p=
atch upstream.  Suppose someone cloned our =E2=80=9Cbindings=E2=80=9D repo,=
 made some changes so that it worked for them, then wanted to submit the pa=
tch upstream.  How would they do that?

I think we could mostly solve this with a good README explaining what
to do. It's not uncommon to see (a) generated Go code with // DO NOT
EDIT at the top, and (b) repos (mirrors) on github that do not accept
PRs. Or am I oversimplifying?

Thanks,
-NR


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 18:38:03 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 18:38:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTV71-0007la-MC; Tue, 28 Apr 2020 18:37:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=nCd5=6M=oracle.com=joe.jin@srs-us1.protection.inumbo.net>)
 id 1jTV70-0007lV-Te
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 18:37:42 +0000
X-Inumbo-ID: 57f964fa-897f-11ea-9887-bc764e2007e4
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 57f964fa-897f-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 18:37:42 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03SIZxks071067;
 Tue, 28 Apr 2020 18:37:39 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=subject : to : cc :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type : content-transfer-encoding; s=corp-2020-01-29;
 bh=74BgaBiqTi1MFfdeF1NQG8LUiYgFzHAykVzSoYx6QBg=;
 b=yCx7580ve6ar3ZE9++qy042uW6rV/MJ7ZA6jH372uOrQnI/ynkqq5kpzKX9q1nMQjGA4
 1/J0DvI0bTa87AxpD4bFmQXx9l1ny95pcnxYwE+MqQ/af+URHBHXVif0EyPgypBXrqJN
 HCrs325cPsfx0lzMQZHwZO7ZbtnBQJOhp+BPgthX7abDl5jbWxINARX8OXW66hAf/sWi
 zjww8/j3mcP14IY0op6WGYB17RPfaHZ7IRrT5ZsIpR7hn2jJiXXW4yQWiTz21fDLs4Bd
 /apyl5GHq8msghEv+Hycd9JlPE2tTwL/P8EYKyNLJUY5Ve0XPtCBSDjIgm+vZ/tzZECJ 1g== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by userp2130.oracle.com with ESMTP id 30p01nr8kb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 28 Apr 2020 18:37:39 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03SIWCwQ019256;
 Tue, 28 Apr 2020 18:37:39 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by userp3020.oracle.com with ESMTP id 30mxx0fanf-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 28 Apr 2020 18:37:39 +0000
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
 by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03SIbbGw026927;
 Tue, 28 Apr 2020 18:37:37 GMT
Received: from [10.159.229.42] (/10.159.229.42)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 28 Apr 2020 11:37:37 -0700
Subject: Re: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
 =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
References: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
 <1c01e97a-adcd-a703-55b5-8975b4ce4d2c@suse.com>
 <DB6PR0402MB2760A05135338B0CBB28123488AC0@DB6PR0402MB2760.eurprd04.prod.outlook.com>
 <dba804ea-4268-24ff-7447-ddef00e9e20c@suse.com>
 <20200428172514.GA24178@char.us.oracle.com>
From: Joe Jin <joe.jin@oracle.com>
Message-ID: <bbd41468-9d58-0ff9-3c31-ff53dbe375af@oracle.com>
Date: Tue, 28 Apr 2020 11:37:35 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200428172514.GA24178@char.us.oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 spamscore=0 bulkscore=0
 suspectscore=2 mlxlogscore=999 phishscore=0 malwarescore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004280146
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 spamscore=0 clxscore=1011
 phishscore=0 mlxlogscore=999 adultscore=0 priorityscore=1501 mlxscore=0
 suspectscore=2 malwarescore=0 lowpriorityscore=0 impostorscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004280146
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Peng Fan <peng.fan@nxp.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
 dl-linux-imx <linux-imx@nxp.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/28/20 10:25 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 28, 2020 at 12:19:41PM +0200, Jürgen Groß wrote:
>> On 28.04.20 10:25, Peng Fan wrote:
> 
> Adding Joe Jin.
> 
> Joe, didn't you have some ideas on how this could be implemented?
> 
>>>> Subject: Re: [PATCH] xen/swiotlb: correct the check for
>>>> xen_destroy_contiguous_region
>>>>
>>>> On 28.04.20 09:33, peng.fan@nxp.com wrote:
>>>>> From: Peng Fan <peng.fan@nxp.com>
>>>>>
>>>>> When booting xen on i.MX8QM, met:
>>>>> "
>>>>> [    3.602128] Unable to handle kernel paging request at virtual address
>>>> 0000000000272d40
>>>>> [    3.610804] Mem abort info:
>>>>> [    3.613905]   ESR = 0x96000004
>>>>> [    3.617332]   EC = 0x25: DABT (current EL), IL = 32 bits
>>>>> [    3.623211]   SET = 0, FnV = 0
>>>>> [    3.626628]   EA = 0, S1PTW = 0
>>>>> [    3.630128] Data abort info:
>>>>> [    3.633362]   ISV = 0, ISS = 0x00000004
>>>>> [    3.637630]   CM = 0, WnR = 0
>>>>> [    3.640955] [0000000000272d40] user address but active_mm is
>>>> swapper
>>>>> [    3.647983] Internal error: Oops: 96000004 [#1] PREEMPT SMP
>>>>> [    3.654137] Modules linked in:
>>>>> [    3.677285] Hardware name: Freescale i.MX8QM MEK (DT)
>>>>> [    3.677302] Workqueue: events deferred_probe_work_func
>>>>> [    3.684253] imx6q-pcie 5f000000.pcie: PCI host bridge to bus 0000:00
>>>>> [    3.688297] pstate: 60000005 (nZCv daif -PAN -UAO)
>>>>> [    3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0
>>>>> [    3.693993] pci_bus 0000:00: root bus resource [bus 00-ff]
>>>>> [    3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0
>>>>> "
>>>>>
>>>>> In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask)
>>>>> or range_straddles_page_boundary(phys, size) are true, it will create
>>>>> contiguous region. So when free, we need to free contiguous region use
>>>>> upper check condition.
>>>>
>>>> No, this will break PV guests on x86.
>>>
>>> Could you share more details why alloc and free not matching for the check?
>>
>> xen_create_contiguous_region() is needed only in case:
>>
>> - the bus address is not within dma_mask, or
>> - the memory region is not physically contiguous (can happen only for
>>   PV guests)
>>
>> In any case it should arrange for the memory to be suitable for the
>> DMA operation, so to be contiguous and within dma_mask afterwards. So
>> xen_destroy_contiguous_region() should only ever called for areas
>> which match above criteria, as otherwise we can be sure
>> xen_create_contiguous_region() was not used for making the area DMA-able
>> in the beginning.

I agreed with Juergen's explanation, That is my understanding.

Peng, if panic caused by (dev_addr + size - 1 > dma_mask), you should check
how you get the addr, if memory created by xen_create_contiguous_region(),
memory must be with in [0 - dma_mask].

Thanks,
Joe

>>
>> And this is very important in the PV case, as in those guests the page
>> tables are containing the host-PFNs, not the guest-PFNS, and
>> xen_create_contiguous_region() will fiddle with host- vs. guest-PFN
>> arrangements, and xen_destroy_contiguous_region() is reverting this
>> fiddling. Any call of xen_destroy_contiguous_region() for an area it
>> was not intended to be called for might swap physical pages beneath
>> random virtual addresses, which was the reason for this test to be
>> added by me.
>>
>>
>> Juergen
>>
>>>
>>> Thanks,
>>> Peng.
>>>
>>>>
>>>> I think there is something wrong with your setup in combination with the ARM
>>>> xen_create_contiguous_region() implementation.
>>>>
>>>> Stefano?
>>>>
>>>>
>>>> Juergen
>>>>
>>>>>
>>>>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>>>> ---
>>>>>    drivers/xen/swiotlb-xen.c | 4 ++--
>>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>>>>> index b6d27762c6f8..ab96e468584f 100644
>>>>> --- a/drivers/xen/swiotlb-xen.c
>>>>> +++ b/drivers/xen/swiotlb-xen.c
>>>>> @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev,
>>>> size_t size, void *vaddr,
>>>>>    	/* Convert the size to actually allocated. */
>>>>>    	size = 1UL << (order + XEN_PAGE_SHIFT);
>>>>>
>>>>> -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
>>>>> -		     range_straddles_page_boundary(phys, size)) &&
>>>>> +	if (((dev_addr + size - 1 > dma_mask) ||
>>>>> +	    range_straddles_page_boundary(phys, size)) &&
>>>>>    	    TestClearPageXenRemapped(virt_to_page(vaddr)))
>>>>>    		xen_destroy_contiguous_region(phys, order);
>>>>>
>>>>>
>>>
>>



From xen-devel-bounces@lists.xenproject.org Tue Apr 28 18:46:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 18:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTVFk-0000KA-IR; Tue, 28 Apr 2020 18:46:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=vXCi=6M=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTVFj-0000K5-Su
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 18:46:43 +0000
X-Inumbo-ID: 9a7b599a-8980-11ea-98b7-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 9a7b599a-8980-11ea-98b7-12813bfff9fa;
 Tue, 28 Apr 2020 18:46:43 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 36DFA206A1;
 Tue, 28 Apr 2020 18:46:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588099602;
 bh=dhUsOr1v2mBAanhqQ0gOmvuHvZAHd5hliZZQ3LNcyPk=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=rpFe5bw3nYfTZI/Fw4t782dUbbzbY/e1wgEYuElBHaqtvWX/hfJsEsGLS2XuWDjW+
 bIa1bjuq3y0DPZGSRea+vJdpT7vRGCrl1tbdpGUSeE9+xCmrQUgbqzVktKSAA0Vkgk
 G9OeZjGFgkrrokBQpvUJ6AmBsdTd+Dw9M6vbLLqs=
Date: Tue, 28 Apr 2020 11:46:41 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: =?UTF-8?Q?J=C3=BCrgen_Gro=C3=9F?= <jgross@suse.com>
Subject: Re: [PATCH] xen/swiotlb: correct the check for
 xen_destroy_contiguous_region
In-Reply-To: <1c01e97a-adcd-a703-55b5-8975b4ce4d2c@suse.com>
Message-ID: <alpine.DEB.2.21.2004281118130.29217@sstabellini-ThinkPad-T480s>
References: <1588059225-11245-1-git-send-email-peng.fan@nxp.com>
 <1c01e97a-adcd-a703-55b5-8975b4ce4d2c@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-325783116-1588098351=:29217"
Content-ID: <alpine.DEB.2.21.2004281125590.29217@sstabellini-ThinkPad-T480s>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: peng.fan@nxp.com, sstabellini@kernel.org, konrad.wilk@oracle.com,
 linux-kernel@vger.kernel.org, hch@infradead.org,
 iommu@lists.linux-foundation.org, linux-imx@nxp.com,
 xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-325783116-1588098351=:29217
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.21.2004281125591.29217@sstabellini-ThinkPad-T480s>

On Tue, 28 Apr 2020, Jürgen Groß wrote:
> On 28.04.20 09:33, peng.fan@nxp.com wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> > 
> > When booting xen on i.MX8QM, met:
> > "
> > [    3.602128] Unable to handle kernel paging request at virtual address
> > 0000000000272d40
> > [    3.610804] Mem abort info:
> > [    3.613905]   ESR = 0x96000004
> > [    3.617332]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [    3.623211]   SET = 0, FnV = 0
> > [    3.626628]   EA = 0, S1PTW = 0
> > [    3.630128] Data abort info:
> > [    3.633362]   ISV = 0, ISS = 0x00000004
> > [    3.637630]   CM = 0, WnR = 0
> > [    3.640955] [0000000000272d40] user address but active_mm is swapper
> > [    3.647983] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > [    3.654137] Modules linked in:
> > [    3.677285] Hardware name: Freescale i.MX8QM MEK (DT)
> > [    3.677302] Workqueue: events deferred_probe_work_func
> > [    3.684253] imx6q-pcie 5f000000.pcie: PCI host bridge to bus 0000:00
> > [    3.688297] pstate: 60000005 (nZCv daif -PAN -UAO)
> > [    3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0
> > [    3.693993] pci_bus 0000:00: root bus resource [bus 00-ff]
> > [    3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0
> > "
> > 
> > In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask) or
> > range_straddles_page_boundary(phys, size) are true, it will
> > create contiguous region. So when free, we need to free contiguous
> > region use upper check condition.
> 
> No, this will break PV guests on x86.
> 
> I think there is something wrong with your setup in combination with
> the ARM xen_create_contiguous_region() implementation.
> 
> Stefano?

Let me start by asking Peng a couple of questions:


Peng, could you please add a printk to check which one of the two
conditions is True for you?  Is it (dev_addr + size - 1 > dma_mask) or
range_straddles_page_boundary(phys, size)?

Is hwdev->coherent_dma_mask set for your DMA capable device?

Finally, is this patch supposed to fix the crash you are seeing? If not,
can you tell where is the crash exactly?



Juergen, keep in mind that xen_create_contiguous_region does nothing on
ARM because in dom0 guest_phys == phys. xen_create_contiguous_region
simply sets dma_handle to phys. Whatever condition caused the code to
take the xen_create_contiguous_region branch in
xen_swiotlb_alloc_coherent, it will also cause it to WARN in
xen_swiotlb_free_coherent.


range_straddles_page_boundary should never return True because
guest_phys == phys. That leaves us with the dma_mask check:

  dev_addr + size - 1 <= dma_mask

dev_addr is the dma_handle allocated by xen_alloc_coherent_pages.
dma_mask is either DMA_BIT_MASK(32) or hwdev->coherent_dma_mask.

The implementation of xen_alloc_coherent_pages has been recently changed
to use dma_direct_alloc.


Christoff, does dma_direct_alloc respect hwdev->coherent_dma_mask if
present? Also, can it return highmem pages?



> Juergen
> 
> > 
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> >   drivers/xen/swiotlb-xen.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index b6d27762c6f8..ab96e468584f 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
> > size, void *vaddr,
> >   	/* Convert the size to actually allocated. */
> >   	size = 1UL << (order + XEN_PAGE_SHIFT);
> >   -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> > -		     range_straddles_page_boundary(phys, size)) &&
> > +	if (((dev_addr + size - 1 > dma_mask) ||
> > +	    range_straddles_page_boundary(phys, size)) &&
> >   	    TestClearPageXenRemapped(virt_to_page(vaddr)))
> >   		xen_destroy_contiguous_region(phys, order);
> >   
> 
--8323329-325783116-1588098351=:29217--


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 19:00:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 19:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTVSY-0001Ne-QB; Tue, 28 Apr 2020 18:59:58 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qrdk=6M=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTVSX-0001NZ-2y
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 18:59:57 +0000
X-Inumbo-ID: 72f2800e-8982-11ea-98b8-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 72f2800e-8982-11ea-98b8-12813bfff9fa;
 Tue, 28 Apr 2020 18:59:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=wWwnsp40vzqIENqvlEsJO+tSgOV42urXwz8ku1QUisU=; b=JfzXPR+gPGpMNzURayncVTByz
 LrefkVK1I1zsmlfxPBUPO/oikqOWsI+SpAqFQvCJr0jvsjsP85NVwlXnvY6PRt7x9vQp9lb+X7xU0
 GjSCn9EjPMDlrGSSftBsWZXyvXimml2XgLehMPoadFmg0/KbKTYaDwUdI1BvMJWadfYU4=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTVSU-0003dv-Uo; Tue, 28 Apr 2020 18:59:54 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTVSU-0001hy-MS; Tue, 28 Apr 2020 18:59:54 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTVSU-00017i-Lh; Tue, 28 Apr 2020 18:59:54 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149863-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149863: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6
X-Osstest-Versions-That: xen=2add344e6a4ef690871157b87b0e7d52bc6db9e4
From: osstest service owner <osstest-admin@xenproject.org>
Date: Tue, 28 Apr 2020 18:59:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149863 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149863/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6
baseline version:
 xen                  2add344e6a4ef690871157b87b0e7d52bc6db9e4

Last test of basis   149857  2020-04-28 12:00:23 Z    0 days
Testing same since   149863  2020-04-28 16:01:08 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Hongyan Xia <hongyxia@amazon.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Wei Liu <wei.liu2@citrix.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   2add344e6a..4ec07971f1  4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 20:55:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 20:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTXFX-00043v-BG; Tue, 28 Apr 2020 20:54:39 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NU6p=6M=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTXFW-00043q-E9
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 20:54:38 +0000
X-Inumbo-ID: 782ed33c-8992-11ea-98c8-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 782ed33c-8992-11ea-98c8-12813bfff9fa;
 Tue, 28 Apr 2020 20:54:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588107276;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=vtgMfbKlG7tTO0fahEHKsiKahuUO8TfrKT+QDlOVgps=;
 b=EbpVeAgFuWIbio9deIK+mLbAXWV7TTPMGYcYzu9TiEU0JPRRTY+hb3Pu
 HKmElkzcGsi2YrKxLRwhJrNLP+D5Me1PYjEMEY/aVcM90Uw6gmErXeDTX
 2G0vg6plGspaj3chSGSp3I4Pdjwis7p1Fxm+lGjyEqJWRR59xrv5z374n g=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: jSqHBU5uG/lWXYn6GIU52x7haex7qbb861udEKyjJOJNlOkil53pFu3+Hx9r+bpZfz0LBUNkbm
 pZznoZrIJRAY+hS3F8nl63l6w2vh3kbG3t3LtbC29YTZF4LaJ21HvTnKSuEnUOQRI2/BHeJzAm
 9Cb2jlJe0f1OjRtdJh99WdbK9fO2gxT8BNaLgCq0pAcE7GRju8kGdRi9RxQJqoQfteUZAz6A8x
 OEC6dMPNoIJKwBHSzrGVdUCqZGLQ6ZAZXPefuMgKW5fGE2cKoZLoyOrJGe3JqeacKCpjdoRerd
 Tx4=
X-SBRS: 2.7
X-MesageID: 16713410
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,328,1583211600"; d="scan'208";a="16713410"
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xenproject.org>
References: <20200428155144.8253-1-jgross@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <130909f7-e9e2-93b4-5b54-aa55178d1bd3@citrix.com>
Date: Tue, 28 Apr 2020 21:54:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200428155144.8253-1-jgross@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28/04/2020 16:51, Juergen Gross wrote:
> The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
> of the domain's xenstore ring page and the event channel of the
> domain for communicating with Xenstore.
>
> The gfn is not really needed. It is stored in the per-domain struct
> in xenstored and in case of another XS_INTRODUCE for the domain it
> is tested to match the original value. If it doesn't match the
> command is aborted via EINVAL.
>
> Today there shouldn't be multiple XS_INTRODUCE requests for the same
> domain issued, so the mfn/gfn can just be ignored and multiple
> XS_INTRODUCE commands can be rejected without testing the mfn/gfn.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

In hindsight, this is cleanup following c/s 38eeb3864d "tools/xenstored:
Drop mapping of the ring via foreign map".

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 20:56:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 20:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTXGw-00048C-Nd; Tue, 28 Apr 2020 20:56:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=pugY=6M=gmail.com=julien.grall.oss@srs-us1.protection.inumbo.net>)
 id 1jTXGv-000486-IN
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 20:56:05 +0000
X-Inumbo-ID: abeed82a-8992-11ea-9887-bc764e2007e4
Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id abeed82a-8992-11ea-9887-bc764e2007e4;
 Tue, 28 Apr 2020 20:56:03 +0000 (UTC)
Received: by mail-wm1-x344.google.com with SMTP id e26so253264wmk.5
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 13:56:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=KKvsDRiFjALps8a6wOB2tzLVbtwckFH331UbKPAJ6KA=;
 b=nxKSt14czAl95ARfnssZwExIdlnG6FY8cW5lG200nGW8FbUwOcMHk431d2EN5ynXEP
 KFFORKkQn3QyMVphbsxrEB7TIJTDw0K8NXHg187TAn+3QYDl1lLuoVjuB8utZ/iVIB1a
 11xAaKuUZegPzcMMHP/ThMzp7aJ9Lju8AwFj8rx3Ee2FGpYNgK3Gre+AICAtibhSCsEo
 i6BzbrUsqyu4lc6hjsBJ3Zdv42sanssP3B/NNNu+E2neMiVbIyNXTPTpmJvDHFjYUY9g
 Ps1OqhXPbyklHnvDvVIie7iakJM2otkZSI19zZ1i5iqTHTyinaW0pdYu8exuvAhOVpnT
 7LdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=KKvsDRiFjALps8a6wOB2tzLVbtwckFH331UbKPAJ6KA=;
 b=RmUnYqAFbKFtTYEL49sNlM5kIJWHroqklgyugUH5aTZio5zzN1DjIAXlU1C46gr455
 +gjgLwVSGUaM9/tO2Po38zJplPIBXgBe15OPM1gLC83FuJt5DESkBD+QAWJUrJxN89vU
 ah6oi0qFyMvgXvzidpwMkRqVg4MkfedMfnMwfTKpiTkiC/2TwvRvDON1uxd7S6dS4Jhh
 Vg36TbrQ4EBDCdGMuP/duspWyPRHf3o/3E6LYB1BuRTLS9qGlUsEXRbiV3Paeov7J38y
 9Id+z2s0BWoAMm0hzSJ/QxMqifrAvJuq8sv355Xzt2zfdTGOLWNSCFG3NA9khqL3BRrg
 TCYg==
X-Gm-Message-State: AGi0PuZwk13PBkIA5uv2Jda/fT9DIWN5ag7XdyJC1yS7n6H3oRLMxPLA
 MhxkhMKCmhRlD+c6gpZe0sApcimxFDGCw5NNfM8=
X-Google-Smtp-Source: APiQypKOdI8Quh3q1ys0N7VYAg8WD3bL952HfWMSzWK6lgCzFOqwp5qxGp8/NIaah4TguR2AxIUxY1GW4Me1NT2rVHw=
X-Received: by 2002:a7b:c8cc:: with SMTP id f12mr6217140wml.7.1588107362653;
 Tue, 28 Apr 2020 13:56:02 -0700 (PDT)
MIME-Version: 1.0
References: <20200428155144.8253-1-jgross@suse.com>
In-Reply-To: <20200428155144.8253-1-jgross@suse.com>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Tue, 28 Apr 2020 21:55:51 +0100
Message-ID: <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: Juergen Gross <jgross@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Juergen,

On Tue, 28 Apr 2020 at 16:53, Juergen Gross <jgross@suse.com> wrote:
>
> The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
> of the domain's xenstore ring page and the event channel of the
> domain for communicating with Xenstore.
>
> The gfn is not really needed. It is stored in the per-domain struct
> in xenstored and in case of another XS_INTRODUCE for the domain it
> is tested to match the original value. If it doesn't match the
> command is aborted via EINVAL.
>
> Today there shouldn't be multiple XS_INTRODUCE requests for the same
> domain issued, so the mfn/gfn can just be ignored and multiple
> XS_INTRODUCE commands can be rejected without testing the mfn/gfn.

So there is a comment in the else part:

/* Use XS_INTRODUCE for recreating the xenbus event-channel. */

>From the commit message this is not entirely clear why we want to
prevent recreating the event-channel. Can you expand it?

>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  tools/xenstore/xenstored_domain.c | 47 ++++++++++++++++-----------------------
>  1 file changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 5858185211..17328f9fc9 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -369,7 +369,6 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
>         struct domain *domain;
>         char *vec[3];
>         unsigned int domid;
> -       unsigned long mfn;
>         evtchn_port_t port;
>         int rc;
>         struct xenstore_domain_interface *interface;
> @@ -381,7 +380,7 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
>                 return EACCES;
>
>         domid = atoi(vec[0]);
> -       mfn = atol(vec[1]);
> +       /* Ignore the mfn, we don't need it. */

s/mfn/GFN/

>         port = atoi(vec[2]);
>
>         /* Sanity check args. */
> @@ -390,34 +389,26 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
>
>         domain = find_domain_by_domid(domid);
>
> -       if (domain == NULL) {
> -               interface = map_interface(domid);
> -               if (!interface)
> -                       return errno;
> -               /* Hang domain off "in" until we're finished. */
> -               domain = new_domain(in, domid, port);
> -               if (!domain) {
> -                       rc = errno;
> -                       unmap_interface(interface);
> -                       return rc;
> -               }
> -               domain->interface = interface;
> -               domain->mfn = mfn;

AFAICT domain->mfn is not used anymore, so could we remove the field?

Cheers,


From xen-devel-bounces@lists.xenproject.org Tue Apr 28 20:59:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Apr 2020 20:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTXKK-0004L0-9z; Tue, 28 Apr 2020 20:59:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vxmr=6M=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTXKJ-0004Kr-Tt
 for xen-devel@lists.xenproject.org; Tue, 28 Apr 2020 20:59:35 +0000
X-Inumbo-ID: 2a06d32a-8993-11ea-b07b-bc764e2007e4
Received: from mail-lj1-x243.google.com (unknown [2a00:1450:4864:20::243])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2a06d32a-8993-11ea-b07b-bc764e2007e4;
 Tue, 28 Apr 2020 20:59:35 +0000 (UTC)
Received: by mail-lj1-x243.google.com with SMTP id h4so186789ljg.12
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 13:59:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=HyILoaA1hxgjmTMdOG8qTPVjYqSUyF3z5EnUpxojgbU=;
 b=FF6Pbcimpffl1JgklYWfIck8oCUH8bXMr46L7flIw3UZisPPIF29uIVi3KoQ/o7Kpa
 LTw9vUK/psLeN6DJrpO/vHShWKvRhb094ibLbvmFy3e3KIc43uPWTG7ZM2YhGntHBW5G
 KB5iRCeIvbQU3BwMSnL+gssRw5lCjjrqjud5/SOcHnEWvIP/aC/l6wNFq60KmrR4Zoek
 vmnemb5kMraTMre9rzrYOhY/zo7cxamLafx1D/KjKuTjRVrWQ2O5KI4YAkBeB1xvgjY+
 Sw81FwqgM3+R0NcvRLkvb54WRwU4+J+mVtrFMFUqQd/b4pSdOjzUWpaZpcEEYNtXdNea
 frdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=HyILoaA1hxgjmTMdOG8qTPVjYqSUyF3z5EnUpxojgbU=;
 b=HPyW2yQMVuEzpsyPsfK9sSwK6DkrOvUxM8w/dyE9FOOe3w06s/ss5mJoi0pvxB/X3P
 BJfAxZOA6RtX22jk37A7emiLa4K2Nd3RD2ZKGgsyAJbKMOrUU+CDeY0JpGedinjtedfe
 kD5vMIq86PIxXqkgxGdFJw13KGCYj4UJJO5EacbPPUZ6yu2UVOqXs69PO4fAz1qJdl36
 yJ2yM0PHm55ZbJ66w3OAiJnuywV/NIzaTaN5fFFwuqXaDJcAnNp8F3cw09Dx9l5WPES0
 4JM1PThAYqiM+kOuU0cY2Q9AZVbV7YYj+fJaJKwqfO/hFC/1/hweDb7UI7RPFzKc1Sby
 tdEw==
X-Gm-Message-State: AGi0Puauul9MtL/BS5FkW691Rlk1tA1iXoQ51WWFVYcgOiDE+qVn7xko
 fMWHD86YpEAL0HLn7ELRuWR7ugR4yuVo/DPaN8I=
X-Google-Smtp-Source: APiQypJWGlTn7zYo3pqLM6dIPZTTI02fZMODCGuqDyPmlJ5VDsqjWJ3D0RuIEzMSU7O4cCDzAuWaF9X9qY7HWbJhsKQ=
X-Received: by 2002:a19:ca0e:: with SMTP id a14mr20514674lfg.105.1588107574099; 
 Tue, 28 Apr 2020 13:59:34 -0700 (PDT)
MIME-Version: 1.0
References: <cfbb5553-b9dc-ee86-145f-3cab92289c4d@suse.com>
 <20200317152310.114567-1-jandryuk@gmail.com>
 <7aca5da4-2ae5-8d3d-e7df-69eb7ffb743c@suse.com>
In-Reply-To: <7aca5da4-2ae5-8d3d-e7df-69eb7ffb743c@suse.com>
From: Jason Andryuk <jandryuk@gmail.com>
Date: Tue, 28 Apr 2020 16:59:22 -0400
Message-ID: <CAKf6xpv4BSKbf7234srJcXRQGFhJY5A6q61OEAkj4N+xbmh0AA@mail.gmail.com>
Subject: Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several
 people have reproduced
To: Jan Beulich <jbeulich@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Aaron Janse <aaron@ajanse.me>,
 xen-devel <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 17, 2020 at 5:31 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 17.03.2020 16:23, Jason Andryuk wrote:
> > Below is the diff.  It was messier and I tidied it up some.
>
> I've looked into this some more. I can see how what we currently
> do is not in line with firmware handing off with LegacyReplacement
> mode enabled. However, this case doesn't look to apply here:

Thanks for taking a look again.  Sorry for the slow response.  I
wanted to dig through the linux history to see if there was a reason
for enabling the periodic timer there, but I haven't gotten around to
it.

> So right now the only possible approach I see to address your
> problem is to add yet another fallback mode to check_timer(),
> forcing LegacyReplacement mode to be enabled. But between /
> after which step(s) to put this there isn't at all obvious to me.

I don't really have a good suggestion here.

Aaron, I'm curious to know if you've tried this patch on your hardware
and if it helped.

Thanks again,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 00:37:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 00:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTaif-0008Dj-FW; Wed, 29 Apr 2020 00:36:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTaie-0008Dc-Q0
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 00:36:56 +0000
X-Inumbo-ID: 864bb3bc-89b1-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 864bb3bc-89b1-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 00:36:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Uvu9X4S2pKs+BFrSUu4d17FkHARTkUFK7rzJAU/fIpI=; b=6EwGgoegpfc2tScavB1A7qskH
 vbpZ3frtwzuTjBcCVj1Ouyf5AJNr1Db1qoqt9BfLfRoQHlvGZj/Q75fx1saYo9DDH0K7ZkZBm8eHB
 dl8OZ7eg5YGg5NEqNd84iqkWgKv16Su5XsKyhlVWru483W612nCjAtlqRs0PoTeMJgXFc=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTaic-0003eL-60; Wed, 29 Apr 2020 00:36:54 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTaib-00045A-VN; Wed, 29 Apr 2020 00:36:54 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTaib-0007oH-SN; Wed, 29 Apr 2020 00:36:53 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149854-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149854: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-arm64-arm64-examine:reboot:fail:heisenbug
 linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug
 linux-linus:test-arm64-arm64-xl-xsm:xen-boot:fail:heisenbug
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=51184ae37e0518fd90cb437a2fbc953ae558cd0d
X-Osstest-Versions-That: linux=6a8b55ed4056ea5559ebe4f6a4b247f627870d4c
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 00:36:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149854 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149854/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-examine      8 reboot           fail in 149840 pass in 149854
 test-amd64-amd64-examine    4 memdisk-try-append fail in 149840 pass in 149854
 test-arm64-arm64-xl-xsm       7 xen-boot                   fail pass in 149840

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds    16 guest-start/debian.repeat fail REGR. vs. 149832

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149832
 test-arm64-arm64-xl-xsm     13 migrate-support-check fail in 149840 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 149840 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149832
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149832
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149832
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149832
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149832
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149832
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149832
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149832
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-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-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                51184ae37e0518fd90cb437a2fbc953ae558cd0d
baseline version:
 linux                6a8b55ed4056ea5559ebe4f6a4b247f627870d4c

Last test of basis   149832  2020-04-27 03:24:02 Z    1 days
Testing same since   149840  2020-04-27 21:08:47 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  David Sterba <dsterba@suse.com>
  Dexuan Cui <decui@microsoft.com>
  Filipe Manana <fdmanana@suse.com>
  Josef Bacik <josef@toxicpanda.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Michael Kelley <mikelley@microsoft.com>
  Nishad Kamdar <nishadkamdar@gmail.com>
  Wei Liu <wei.liu@kernel.org>
  Xin Tan <tanxin.ctf@gmail.com>
  Xiyu Yang <xiyuyang19@fudan.edu.cn>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      fail    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   6a8b55ed4056..51184ae37e05  51184ae37e0518fd90cb437a2fbc953ae558cd0d -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 02:18:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 02:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTcIF-0006hu-1s; Wed, 29 Apr 2020 02:17:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NpAr=6N=oracle.com=boris.ostrovsky@srs-us1.protection.inumbo.net>)
 id 1jTcIE-0006ho-2k
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 02:17:46 +0000
X-Inumbo-ID: 9cb94a02-89bf-11ea-b07b-bc764e2007e4
Received: from aserp2120.oracle.com (unknown [141.146.126.78])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9cb94a02-89bf-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 02:17:45 +0000 (UTC)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03T28lwe009353;
 Wed, 29 Apr 2020 02:17:42 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=subject : to : cc :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type : content-transfer-encoding; s=corp-2020-01-29;
 bh=nnvLXbiq2ZbmsYZffTwlsQbzMEvVCTHxcq/SE4uAlp4=;
 b=qMAOjevYzwVxyH/ljORcP4Nj/o3lTLwkgh7sj5vlBKHMB8ZM+H3ywmHiM8D6ABecs0O/
 6DAEPvAAlUXKX5iDmLmkfkMsIAKD1gDWY6l87n6HnKvP7FOgThyMR2WnuuKx5xSssU+A
 HtgWPHVJK8WRexqAJsy+UirEnzgKtelO63IojSouzq2zWUBN5gpiupIwvgABn4ZELcmM
 iOak1W6JbYsZBdg27FmeiX7OyV7oNYW8zzr14NlAPYTiViNkcsdhBMmMkZ1meW12hleP
 yJueUuocAb72RMd4k4ZVFeebsk1mH3w0OvD0Zywe6JVL4WPBo1+i9+jqxG3ykBInrgSD mg== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by aserp2120.oracle.com with ESMTP id 30nucg37vy-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Apr 2020 02:17:42 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03T285IL000873;
 Wed, 29 Apr 2020 02:17:41 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])
 by userp3020.oracle.com with ESMTP id 30pvcysa7u-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Apr 2020 02:17:41 +0000
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
 by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03T2HbfO012985;
 Wed, 29 Apr 2020 02:17:37 GMT
Received: from [10.39.225.159] (/10.39.225.159)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Tue, 28 Apr 2020 19:17:37 -0700
Subject: Re: [PATCH] x86/xen: drop an unused parameter gsi_override
To: Wei Liu <wei.liu@kernel.org>, linux-pci@vger.kernel.org,
 Xen Development List <xen-devel@lists.xenproject.org>
References: <20200428153640.76476-1-wei.liu@kernel.org>
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Autocrypt: addr=boris.ostrovsky@oracle.com; keydata=
 xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV
 PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M
 MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5
 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM
 d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom
 woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2
 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2
 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS
 Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP
 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry
 b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8
 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g
 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z
 JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS
 VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK
 jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE
 qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9
 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/
 kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T
 m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB
 nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o
 hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB
 Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q
 yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz
 kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4
 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i
 BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC
 gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw
 XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ
 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK
 kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4
 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G
 jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh
 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ
 PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj
 u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu
 qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd
 t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4
 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh
 Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ
 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM
 Jg6OxFYd01z+a+oL
Message-ID: <3d3c2073-90c8-d3b1-0dd4-4045c3f01a5e@oracle.com>
Date: Tue, 28 Apr 2020 22:17:35 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200428153640.76476-1-wei.liu@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 mlxlogscore=999
 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004290015
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011
 priorityscore=1501
 mlxlogscore=999 impostorscore=0 suspectscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 spamscore=0 adultscore=0 phishscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004290015
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, sstabellini@kernel.org,
 konrad.wilk@oracle.com, x86@kernel.org, linux-kernel@vger.kernel.org,
 Michael Kelley <mikelley@microsoft.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


On 4/28/20 11:36 AM, Wei Liu wrote:
> All callers within the same file pass in -1 (no override).
>
> Signed-off-by: Wei Liu <wei.liu@kernel.org>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>






From xen-devel-bounces@lists.xenproject.org Wed Apr 29 03:04:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 03:04:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTd1a-0002uJ-Sh; Wed, 29 Apr 2020 03:04:38 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6cw0=6N=gmail.com=gorbak25@srs-us1.protection.inumbo.net>)
 id 1jTd1Z-0002uE-9H
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 03:04:37 +0000
X-Inumbo-ID: 28467d32-89c6-11ea-ae69-bc764e2007e4
Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 28467d32-89c6-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 03:04:36 +0000 (UTC)
Received: by mail-wr1-x441.google.com with SMTP id g13so671771wrb.8
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 20:04:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=R6q50vp6hRSEnb/zKd1obSRsfWUOxnyEo7uYejY6auA=;
 b=oVdWbkzK4f0DHuYFQTk7fZkYoaZ/hc+B4N3+gC8aedHEAVltwiJ6rH3phiWtzS80ti
 VaQ19JiC6n8L8cOUt1EuX8o2sbTy+vg7tMlIX5v2vsXmoVmpkhfobBtPVipLCSPfnleN
 dvBKET91uwWTlU12jLpUv3i4wTWBXV2aHAefVCXL8ISwNumcL8RFnrRO0zFqkR2CzDif
 9kocUQWlGooEOaVzGdtzP3eLEHp9QHn0NX+kN61JfLc3DgfMi/yDpBuI1yfDk57wfG2E
 sreTZxKU/vJcPngvcim2Z/QeE3dAU33GKhSQbZ7wzlVfXHzBfJSm38T61sIkCunJ4Iqi
 J0Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=R6q50vp6hRSEnb/zKd1obSRsfWUOxnyEo7uYejY6auA=;
 b=ipar+Ar9g/j8+QSC/XR6QGVS4/NKsk7acUyiWdK9XlhxL0devF21g1NNZVgF9L6hYQ
 Orwima2Q5HUGX6I/HS1lnapLP0xVJKv0tD5WiI52gaGwzJ7JRHioLEeesc9b+CyfnpnC
 ACYDTYX54v+N8GNNevgf+CSCFNzZlNxFJnZ+h/De7YJtgpqlHBOf+qCKMBC8vXqYO27U
 0zrUpPTK+GLoaP9advoFo2N7hXappqYryDvBc+JYlfJ7fuSLdKAjZl4/eOA8EZzrC7hN
 kJgMMjQfCh2yuwi4L42MUU5YEF0Hc1rPHiShPNkUUcGmY/83/N2aAbGuRXynigrbD7w1
 tzLA==
X-Gm-Message-State: AGi0PuZc2CrADqpvFM+gqHeZMmarUmRUxl+ll16WC3bE2eWrQ6amrvMV
 s8Jyy0z1aVU2qzvE/aXSX9I=
X-Google-Smtp-Source: APiQypKh84TmqBY76LL+9V6XYeNoWav0vxXwJ7Fz7g8GT3hJ3Fu0UZxeitOY36z79gZqFKFL1stxCQ==
X-Received: by 2002:adf:e681:: with SMTP id r1mr39637110wrm.213.1588129475663; 
 Tue, 28 Apr 2020 20:04:35 -0700 (PDT)
Received: from localhost.localdomain (public-gprs636909.centertel.pl.
 [5.184.31.46])
 by smtp.gmail.com with ESMTPSA id o6sm19713725wrw.63.2020.04.28.20.04.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Apr 2020 20:04:34 -0700 (PDT)
From: Grzegorz Uriasz <gorbak25@gmail.com>
To: qemu-devel@nongnu.org
Subject: [PATCH v2 0/2] Fix QEMU crashes when passing IGD to a guest VM under
 XEN
Date: Wed, 29 Apr 2020 03:04:07 +0000
Message-Id: <20200429030409.9406-1-gorbak25@gmail.com>
X-Mailer: git-send-email 2.26.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: artur@puzio.waw.pl, Stefano Stabellini <sstabellini@kernel.org>,
 Paul Durrant <paul@xen.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, Grzegorz Uriasz <gorbak25@gmail.com>,
 Anthony Perard <anthony.perard@citrix.com>, j.nowak26@student.uw.edu.pl,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is the v1 cover letter - the patches now include a detailed description of the changes.

Hi,

This patch series is a small subset of a bigger patch set spanning few projects aiming to isolate the GPU
in QUBES OS to a dedicated security domain. I'm doing this together with 3 colleagues as part of our Bachelors thesis.

When passing an Intel Graphic Device to a HVM guest under XEN, QEMU sometimes crashes
when starting the VM. It turns out that the code responsible for setting up
the legacy VBIOS for the IGD contains a bug which results in a memcpy of an undefined size
between the QEMU heap and the physical memory of the guest.

If the size of the memcpy is small enough qemu does not crash - this means that this
bug is actually a small security issue - a hostile guest kernel might determine the memory layout of
QEMU simply by looking at physical memory beyond 0xdffff - this defeats ASLR and might make exploitation
easier if other issues were to be found.

The problem is the current mechanism for obtaining a copy of the ROM of the IGD.
We first allocate a buffer which holds the vbios - the size of which is obtained from sysfs.
We then try to read the rom from sysfs, if we fail then we just return without setting the size of the buffer.
This would be ok if the size of the ROM reported by sysfs would be 0, but the size is always 32 pages as this corresponds
to legacy memory ranges. It turns out that reading the ROM fails on every single device I've tested(spanning few
generations of IGD), which means qemu never sets the size of the buffer and returns a valid pointer to code which
basically does a memcpy of an undefined size.

I'm including two patches.
The first one fixes the security issue by making failing to read the ROM from sysfs fatal.
The second patch introduces a better method for obtaining the VBIOS. I've haven't yet seen a single device on which
the old code was working, the new code basically creates a shadow copy directly by reading from /dev/mem - this
should be fine as a quick grep of the codebase shows that this approach is already being used to handle MSI.
I've tested the new code on few different laptops and it works fine and the guest VMS finally stopped complaining that
the VBIOS tables are missing.

Grzegorz Uriasz (2):
  Fix undefined behaviour
  Improve legacy vbios handling

 hw/xen/xen_pt.c          |  8 +++++--
 hw/xen/xen_pt_graphics.c | 48 +++++++++++++++++++++++++++++++++++++---
 hw/xen/xen_pt_load_rom.c | 13 +++++------
 3 files changed, 57 insertions(+), 12 deletions(-)

-- 
2.26.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 03:04:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 03:04:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTd1g-0002uW-4P; Wed, 29 Apr 2020 03:04:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6cw0=6N=gmail.com=gorbak25@srs-us1.protection.inumbo.net>)
 id 1jTd1e-0002uP-6v
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 03:04:42 +0000
X-Inumbo-ID: 2a06e332-89c6-11ea-ae69-bc764e2007e4
Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2a06e332-89c6-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 03:04:39 +0000 (UTC)
Received: by mail-wr1-x443.google.com with SMTP id x18so706488wrq.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 20:04:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=qRzsulywIjE+sQcPoBEKngALHTHNWGcwn3UAFri5+Is=;
 b=B5oRsmOxxtULX0ELvlErFeZeY0jak0zTDw+T63dGQmt8YuEujgUo5u+ir5d7gG3q7b
 Hvri0SdTK51dwZCcRpky83W1etxumYRvsNFey41OECwRVZLsKA4Vh1iGEqcirnik+pS/
 szJVElSA3+3/MF+CVST65JqGVCfNJFJ13WZ78y/8v5YsiPP4jXZgKTGpFSV1Wm8dgxDo
 IDC+89MFvelQhTdaOtZVVm9HMmQXBv1ODxhFOQG0+xAoA1cNHLVByWacU6QBzgFMf+e4
 3FL9wXYnFlyWytZpMjh1IPXLcwyJk1D5ZiE2/nQjpoqCX5dUZG0s4VBCkquww1F21hae
 mw4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=qRzsulywIjE+sQcPoBEKngALHTHNWGcwn3UAFri5+Is=;
 b=RyatFJUCb5sZiGNYP57Vmfyr53LAcmtS/GWYWDz8Q1BPFqgrAgbrSxek14FMnN3LSZ
 ZSzWAP8VhI4+vEDAZoKCQpvmDuDrwf/Bo1vgzUqTJo4926wkaGLQSz7z9ETj/1YygnQU
 UTIwp+Pgda3vVn8ap36jLo+ubBX2/lE60e0L+6aR+iwiwZvDDgoOA5D7RxvOvpf2F1WB
 /gnE561hGe/DSSlx0DianrTvaD/ZmjGY9NYJXr3GRNJq4uOHee8DHYQ+dzeBBZjDmWMB
 Gtr8Q6rdy4guoNkmaQ0CxLXiNwt1KYJZyYoqa8dBswUTTMf8HAZ3kS4ByRHSFxR8xWTv
 c1aQ==
X-Gm-Message-State: AGi0PubSgAjzQtIzjnXzjGmln5ceUkrNbGSu8/Q5WIdTb4cCcL6pUYYj
 1NSJJCsyME/EbYCWvPd/1G8=
X-Google-Smtp-Source: APiQypKtASVRZtrLSNfnMWkMLsFzDJUoGhbpBBFcLg/HpdRqjRqKpuxw46KWnaiyvF30jck0ZguBLw==
X-Received: by 2002:adf:fc4f:: with SMTP id e15mr36701072wrs.415.1588129478643; 
 Tue, 28 Apr 2020 20:04:38 -0700 (PDT)
Received: from localhost.localdomain (public-gprs636909.centertel.pl.
 [5.184.31.46])
 by smtp.gmail.com with ESMTPSA id o6sm19713725wrw.63.2020.04.28.20.04.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Apr 2020 20:04:38 -0700 (PDT)
From: Grzegorz Uriasz <gorbak25@gmail.com>
To: qemu-devel@nongnu.org
Subject: [PATCH v2 1/2] Fix undefined behaviour
Date: Wed, 29 Apr 2020 03:04:08 +0000
Message-Id: <20200429030409.9406-2-gorbak25@gmail.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200429030409.9406-1-gorbak25@gmail.com>
References: <20200429030409.9406-1-gorbak25@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: artur@puzio.waw.pl, Stefano Stabellini <sstabellini@kernel.org>,
 Paul Durrant <paul@xen.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, Grzegorz Uriasz <gorbak25@gmail.com>,
 Anthony Perard <anthony.perard@citrix.com>, j.nowak26@student.uw.edu.pl,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This patch fixes qemu crashes when passing through an IGD device to HVM guests under XEN. The problem is that on almost every laptop
reading the IGD ROM from SYSFS will fail, the reason for it is that the IGD rom is polymorphic and it modifies itself
during bootup - this results in an invalid rom image - the kernel checks whether the image is valid and when that's not the case
it won't allow userspace to read it. It seems that when the code was first written(xen_pt_load_rom.c) the kernel's back then didn't check
whether the rom is valid and just passed the contents to userspace - because of this qemu also tries to repair the rom later in the code.
When stating the rom the kernel isn't validating the rom contents so it is returning the proper size of the rom(32 4kb pages).

This results in undefined behaviour - pci_assign_dev_load_option_rom is creating a buffer and then writes the size of the buffer to a pointer.
In pci_assign_dev_load_option_rom under old kernels if the fstat would succeed then fread would also succeed - this means if the buffer
is allocated the size of the buffer will be set. On newer kernels this is not the case - on all laptops I've tested(spanning a few
generations of IGD) the fstat is successful and the buffer is allocated but the fread is failing - as the buffer is not deallocated
the function is returning a valid pointer without setting the size of the buffer for the caller. The caller of pci_assign_dev_load_option_rom
is holding the size of the buffer in an uninitialized variable and is just checking whether pci_assign_dev_load_option_rom returned a valid pointer.
This later results in cpu_physical_memory_write(0xc0000, result_of_pci_assign_dev_load_option_rom, unitialized_variable) which
depending on the compiler parameters, configure flags, etc... might crash qemu or might work - the xen 4.12 stable release with default configure
parameters works but changing the compiler options slightly(for instance by enabling qemu debug) results in qemu crashing ¯\_(;-;)_/¯

The only situation when the original pci_assign_dev_load_option_rom works is when the IDG is not the boot gpu - this won't happen on any laptop and
will be rare on desktops.

This patch deallocates the buffer and returns NULL if reading the VBIOS fails - the caller of the function then properly shuts down qemu.
The next patch in the series introduces a better method for getting the vbios so qemu does not exit when pci_assign_dev_load_option_rom fails -
this is the reason I've changed error_report to warn_report as whether a failure in pci_assign_dev_load_option_rom is fatal
depends on the caller.

Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>
---
 hw/xen/xen_pt_load_rom.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index a50a80837e..9f100dc159 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -38,12 +38,12 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
     fp = fopen(rom_file, "r+");
     if (fp == NULL) {
         if (errno != ENOENT) {
-            error_report("pci-assign: Cannot open %s: %s", rom_file, strerror(errno));
+            warn_report("pci-assign: Cannot open %s: %s", rom_file, strerror(errno));
         }
         return NULL;
     }
     if (fstat(fileno(fp), &st) == -1) {
-        error_report("pci-assign: Cannot stat %s: %s", rom_file, strerror(errno));
+        warn_report("pci-assign: Cannot stat %s: %s", rom_file, strerror(errno));
         goto close_rom;
     }
 
@@ -59,10 +59,9 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
     memset(ptr, 0xff, st.st_size);
 
     if (!fread(ptr, 1, st.st_size, fp)) {
-        error_report("pci-assign: Cannot read from host %s", rom_file);
-        error_printf("Device option ROM contents are probably invalid "
-                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
-                     "or load from file with romfile=\n");
+        warn_report("pci-assign: Cannot read from host %s", rom_file);
+        memory_region_unref(&dev->rom);
+        ptr = NULL;
         goto close_rom;
     }
 
-- 
2.26.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 03:04:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 03:04:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTd1k-0002vA-Cz; Wed, 29 Apr 2020 03:04:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6cw0=6N=gmail.com=gorbak25@srs-us1.protection.inumbo.net>)
 id 1jTd1j-0002um-6S
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 03:04:47 +0000
X-Inumbo-ID: 2b74c630-89c6-11ea-9887-bc764e2007e4
Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2b74c630-89c6-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 03:04:41 +0000 (UTC)
Received: by mail-wm1-x342.google.com with SMTP id e26so293207wmk.5
 for <xen-devel@lists.xenproject.org>; Tue, 28 Apr 2020 20:04:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=MFxxzEsM5GfOkfgyaKw8Kz24FnJBi9lLjF7uh1T3+yM=;
 b=Ml9H7kdFfKHLrPPnYLICG9djXTuB/GA+1a6LqrTQxGGNkNJxCNdRS2clqs+BPiSaDo
 SyDSYfAFPEVvMLZE53vt6LjJUGrWhyg2uP48+5Sp8JH/PFYvzj47b4hIdShvxZBnCvzt
 d/MHprmO+6eDewWi8n5QAuvcyvODR4vbkp3lFjbCmAr5WpDkeuyk8frileoa4IteY9nl
 63aJmdKg+mGax5YgJy6sQ5P8fsduxB/TCCu0sSM5W6EAyEP9+wr5mzYCYLTrFRWlaPgN
 vegKSMP7+zwJX5Dsx86WJlzPqx2lM0Ue6tru7DS1zb1UpztfuArjUPSTwPkXfGEVRaoA
 Jfnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=MFxxzEsM5GfOkfgyaKw8Kz24FnJBi9lLjF7uh1T3+yM=;
 b=eWQZPnPjNYQYJ0zbukeSqBCGUpVm3h6A4jt18vBFzuxD9glKCTLewuYghvOIJiMoLv
 5q47DUXIFFWbtM7QfCrq3NuzleE06Aqgjz5Nu3I2oS3s2b6z1m/fr4Uz6lxhiwqQZ/Um
 IKylFjCiI19fBdlkUncdirOmUUcnqeOtFV/kIuBjL0YMooCHShPLfekbhM1DkKqmF2EF
 yJm6oGfMQxaxeaPMl6e/h03WsQQ+pQJkHcqbe0jnB8BX80eZVtJT5h8wEpcVc+JNi/+7
 9ziDK9F7IIlji/dIrHd2Lm+pioHbzjkxaa+jlPfN8cEjV+9HNwB0jkLYAZOcnrIXCBRO
 9z4A==
X-Gm-Message-State: AGi0PuZcNTYqGpmL3Fw2HEdtWNm+rhIDsZJWYjnfi9CegnUtwf/nUw5u
 2WFnZn1uvXKEya8Nhpd2h5I=
X-Google-Smtp-Source: APiQypJ7i6XB4Z4DtGjW0thFBqIHvxddUzWj5q8KwPgw4tknkPlZoRrX8MoglxKZaemp9rCnP0Ki8A==
X-Received: by 2002:a1c:cc1a:: with SMTP id h26mr525239wmb.127.1588129480910; 
 Tue, 28 Apr 2020 20:04:40 -0700 (PDT)
Received: from localhost.localdomain (public-gprs636909.centertel.pl.
 [5.184.31.46])
 by smtp.gmail.com with ESMTPSA id o6sm19713725wrw.63.2020.04.28.20.04.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Apr 2020 20:04:40 -0700 (PDT)
From: Grzegorz Uriasz <gorbak25@gmail.com>
To: qemu-devel@nongnu.org
Subject: [PATCH v2 2/2] Improve legacy vbios handling
Date: Wed, 29 Apr 2020 03:04:09 +0000
Message-Id: <20200429030409.9406-3-gorbak25@gmail.com>
X-Mailer: git-send-email 2.26.1
In-Reply-To: <20200429030409.9406-1-gorbak25@gmail.com>
References: <20200429030409.9406-1-gorbak25@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: artur@puzio.waw.pl, Stefano Stabellini <sstabellini@kernel.org>,
 Paul Durrant <paul@xen.org>, jakub@bartmin.ski,
 marmarek@invisiblethingslab.com, Grzegorz Uriasz <gorbak25@gmail.com>,
 Anthony Perard <anthony.perard@citrix.com>, j.nowak26@student.uw.edu.pl,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The current method of getting the vbios is broken - it just isn't working on any device I've tested - the reason
for this is explained in the previous patch. The vbios is polymorphic and getting a proper unmodified copy is
often not possible without reverse engineering the firmware. We don't need an unmodified copy for most purposes -
an unmodified copy is only needed for initializing the bios framebuffer and providing the bios with a corrupted
copy of the rom won't do any damage as the bios will just ignore the rom.

After the i915 driver takes over the vbios is only needed for reading some metadata/configuration stuff etc...
I've tested that not having any kind of vbios in the guest actually works fine but on older generations of IGD
there are some slight hiccups. To maximize compatibility the best approach is to just copy the results of the vbios
execution directly to the guest. It turns out the vbios is always present on an hardcoded memory range in a reserved
memory range from real mode - all we need to do is to memcpy it into the guest.

The following patch does 2 things:
1) When pci_assign_dev_load_option_rom fails to read the vbios from sysfs(this works only when the igd is not the
boot gpu - this is unlikely to happen) it falls back to using /dev/mem to copy the vbios directly to the guest.
Using /dev/mem should be fine as there is more xen specific pci code which also relies on /dev/mem.
2) When dealing with IGD in the more generic code we skip the allocation of the rom resource - the reason for this is to prevent
a malicious guest from modifying the vbios in the host -> this is needed as someone might try to pwn the i915 driver in the host by doing so
(attach igd to guest, guest modifies vbios, the guest is terminated and the idg is reattached to the host, i915 driver in the host uses data from the modified vbios).
This is also needed to not overwrite the proper shadow copy made before.

I've tested this patch and it works fine - the guest isn't complaining about the missing vbios tables and the pci config
space in the guest looks fine.

Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>
---
 hw/xen/xen_pt.c          |  8 +++++--
 hw/xen/xen_pt_graphics.c | 48 +++++++++++++++++++++++++++++++++++++---
 hw/xen/xen_pt_load_rom.c |  2 +-
 3 files changed, 52 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index b91082cb8b..ffc3559dd4 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -483,8 +483,12 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd)
                    i, r->size, r->base_addr, type);
     }
 
-    /* Register expansion ROM address */
-    if (d->rom.base_addr && d->rom.size) {
+    /*
+     * Register expansion ROM address. If we are dealing with a ROM
+     * shadow copy for legacy vga devices then don't bother to map it
+     * as previous code creates a proper shadow copy
+     */
+    if (d->rom.base_addr && d->rom.size && !(is_igd_vga_passthrough(d))) {
         uint32_t bar_data = 0;
 
         /* Re-set BAR reported by OS, otherwise ROM can't be read. */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index a3bc7e3921..fe0ef2685c 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -129,7 +129,7 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
     return 0;
 }
 
-static void *get_vgabios(XenPCIPassthroughState *s, int *size,
+static void *get_sysfs_vgabios(XenPCIPassthroughState *s, int *size,
                        XenHostPCIDevice *dev)
 {
     return pci_assign_dev_load_option_rom(&s->dev, size,
@@ -137,6 +137,45 @@ static void *get_vgabios(XenPCIPassthroughState *s, int *size,
                                           dev->dev, dev->func);
 }
 
+static void xen_pt_direct_vbios_copy(XenPCIPassthroughState *s, Error **errp)
+{
+    int fd = -1;
+    void *guest_bios = NULL;
+    void *host_vbios = NULL;
+    /* This is always 32 pages in the real mode reserved region */
+    int bios_size = 32 << XC_PAGE_SHIFT;
+    int vbios_addr = 0xc0000;
+
+    fd = open("/dev/mem", O_RDONLY);
+    if (fd == -1) {
+        error_setg(errp, "Can't open /dev/mem: %s", strerror(errno));
+        return;
+    }
+    host_vbios = mmap(NULL, bios_size,
+            PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, fd, vbios_addr);
+    close(fd);
+
+    if (host_vbios == MAP_FAILED) {
+        error_setg(errp, "Failed to mmap host vbios: %s", strerror(errno));
+        return;
+    }
+
+    memory_region_init_ram(&s->dev.rom, OBJECT(&s->dev),
+            "legacy_vbios.rom", bios_size, &error_abort);
+    guest_bios = memory_region_get_ram_ptr(&s->dev.rom);
+    memcpy(guest_bios, host_vbios, bios_size);
+
+    if (munmap(host_vbios, bios_size) == -1) {
+        XEN_PT_LOG(&s->dev, "Failed to unmap host vbios: %s\n", strerror(errno));
+    }
+
+    cpu_physical_memory_write(vbios_addr, guest_bios, bios_size);
+    memory_region_set_address(&s->dev.rom, vbios_addr);
+    pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->dev.rom);
+    s->dev.has_rom = true;
+    XEN_PT_LOG(&s->dev, "Legacy VBIOS registered\n");
+}
+
 /* Refer to Seabios. */
 struct rom_header {
     uint16_t signature;
@@ -179,9 +218,11 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
         return;
     }
 
-    bios = get_vgabios(s, &bios_size, dev);
+    bios = get_sysfs_vgabios(s, &bios_size, dev);
     if (!bios) {
-        error_setg(errp, "VGA: Can't get VBIOS");
+        XEN_PT_LOG(&s->dev, "Unable to get host VBIOS from sysfs - "
+                            "falling back to a direct copy of memory ranges\n");
+        xen_pt_direct_vbios_copy(s, errp);
         return;
     }
 
@@ -223,6 +264,7 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
 
     /* Currently we fixed this address as a primary for legacy BIOS. */
     cpu_physical_memory_write(0xc0000, bios, bios_size);
+    XEN_PT_LOG(&s->dev, "Legacy VBIOS registered\n");
 }
 
 uint32_t igd_read_opregion(XenPCIPassthroughState *s)
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 9f100dc159..8cd9aa84dc 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -65,7 +65,7 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
         goto close_rom;
     }
 
-    pci_register_bar(dev, PCI_ROM_SLOT, 0, &dev->rom);
+    pci_register_bar(dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_SPACE_MEMORY, &dev->rom);
     dev->has_rom = true;
     *size = st.st_size;
 close_rom:
-- 
2.26.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 03:52:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 03:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTdlB-0007gG-0w; Wed, 29 Apr 2020 03:51:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTdlA-0007gB-7p
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 03:51:44 +0000
X-Inumbo-ID: bd4fe728-89cc-11ea-9905-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bd4fe728-89cc-11ea-9905-12813bfff9fa;
 Wed, 29 Apr 2020 03:51:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=pZ9+nsafYLa5GaRVImxPtxtKJjvqV2xqtDA+1w/U2ho=; b=6pp1QypGc/yDFq+i3lpCfrHOk
 4bB28r8WIlG0Kiw1+QauS8YIY/FTSIVKKcN/rHh/DAevZOVe6eXV/f9307Dut2TMzggk9PYTpsyrK
 g+HY18Ew9N/ojB0j+ZJphZAZWsXeRLAF9v53HW0VBKmeCDeelN9EQmk73i/MZ0q4nKimI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTdl8-0005br-UA; Wed, 29 Apr 2020 03:51:42 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTdl8-0005ty-KP; Wed, 29 Apr 2020 03:51:42 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTdl8-0007AO-JE; Wed, 29 Apr 2020 03:51:42 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149867-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149867: all pass - PUSHED
X-Osstest-Versions-This: ovmf=099dfbb29d8bf0a30e397e3f5baf1da437b8f0ba
X-Osstest-Versions-That: ovmf=0f1946b6626e263c7f764c21cc241cc9faf8a1ae
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 03:51:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149867 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149867/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 099dfbb29d8bf0a30e397e3f5baf1da437b8f0ba
baseline version:
 ovmf                 0f1946b6626e263c7f764c21cc241cc9faf8a1ae

Last test of basis   149827  2020-04-26 06:40:24 Z    2 days
Testing same since   149867  2020-04-28 18:09:26 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@arm.com>
  Laszlo Ersek <lersek@redhat.com>
  Michael Kubacki <michael.kubacki@microsoft.com>
  Ray Ni <ray.ni@intel.com>
  Sean Brogan <sean.brogan@microsoft.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   0f1946b662..099dfbb29d  099dfbb29d8bf0a30e397e3f5baf1da437b8f0ba -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 05:13:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 05:13:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTf1h-0008KS-7j; Wed, 29 Apr 2020 05:12:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTf1f-0008KN-IV
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 05:12:51 +0000
X-Inumbo-ID: 1226cc2a-89d8-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1226cc2a-89d8-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 05:12:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=DgIeHH/2igNog5t+qu7kNZlbVr8Oi7Uyy5E6Pe0IBDY=; b=S8o2n/T+pZyepQVOpjU61CCW0
 26U8arvfuVZuaqw9q7DMZQ14dHsR1EvYQ5COW9LZQ24T+e894xaEkTYY74LpjGOhA0fBtvKkvPKfS
 /KrChCowPMT6iTivFG+Rko9dljC1jH7gZd9SWZ/CTUHd270hIV4uSrBfhTLiwXfA9+6LA=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTf1d-0000OJ-O3; Wed, 29 Apr 2020 05:12:49 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTf1d-0001bT-Ct; Wed, 29 Apr 2020 05:12:49 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTf1d-0002VP-Bp; Wed, 29 Apr 2020 05:12:49 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149865-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149865: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=2add344e6a4ef690871157b87b0e7d52bc6db9e4
X-Osstest-Versions-That: xen=df669de074c395a3b2eeb975fddd3da4c148da13
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 05:12:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149865 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149865/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds    16 guest-start/debian.repeat fail REGR. vs. 149842

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149842
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149842
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149842
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149842
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149842
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149842
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149842
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149842
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149842
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149842
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  2add344e6a4ef690871157b87b0e7d52bc6db9e4
baseline version:
 xen                  df669de074c395a3b2eeb975fddd3da4c148da13

Last test of basis   149842  2020-04-27 23:38:49 Z    1 days
Testing same since   149865  2020-04-28 16:32:15 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   df669de074..2add344e6a  2add344e6a4ef690871157b87b0e7d52bc6db9e4 -> master


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 05:49:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 05:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTfaj-0002yG-NS; Wed, 29 Apr 2020 05:49:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=W7WZ=6N=redhat.com=armbru@srs-us1.protection.inumbo.net>)
 id 1jTfai-0002yB-BV
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 05:49:04 +0000
X-Inumbo-ID: 21d71d96-89dd-11ea-b07b-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 21d71d96-89dd-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 05:49:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588139343;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=HmW2vLbhLurlVohyVKvZrq0+70fmkVlDb+QAD99GkFc=;
 b=brVQC9frLlaAG6QwY6mUijxDwYefsAaTa5/GwDQEqmu9LgFWGwtqzGGMlbk9qY/ySQ4iQ1
 JSk7z4Q/1xKhpqtniNvLJgcB37oG1DIfWjdMvqGXPUZES+b5iGXySJmdn43a5tTPwIye9U
 6IXDj5tH4eXGfLxN+30ph8BhM+8noFg=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-342-_W6aP5KmPouk2XvqZk6Hpg-1; Wed, 29 Apr 2020 01:49:01 -0400
X-MC-Unique: _W6aP5KmPouk2XvqZk6Hpg-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com
 [10.5.11.22])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F13CD107ACCA;
 Wed, 29 Apr 2020 05:48:59 +0000 (UTC)
Received: from blackfin.pond.sub.org (ovpn-113-6.ams2.redhat.com [10.36.113.6])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id F178F1002395;
 Wed, 29 Apr 2020 05:48:56 +0000 (UTC)
Received: by blackfin.pond.sub.org (Postfix, from userid 1000)
 id 7520211358BC; Wed, 29 Apr 2020 07:48:55 +0200 (CEST)
From: Markus Armbruster <armbru@redhat.com>
To: Paul Durrant <xadimgnik@gmail.com>
Subject: Re: [PATCH 02/11] xen: Fix and improve handling of device_add
 usb-host errors
References: <20200424192027.11404-1-armbru@redhat.com>
 <20200424192027.11404-3-armbru@redhat.com>
 <000501d61c65$2a65af30$7f310d90$@xen.org>
Date: Wed, 29 Apr 2020 07:48:55 +0200
In-Reply-To: <000501d61c65$2a65af30$7f310d90$@xen.org> (Paul Durrant's message
 of "Mon, 27 Apr 2020 08:26:26 +0100")
Message-ID: <87a72ux2ns.fsf@dusky.pond.sub.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, paul@xen.org,
 qemu-devel@nongnu.org, 'Gerd Hoffmann' <kraxel@redhat.com>,
 'Anthony Perard' <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Paul Durrant <xadimgnik@gmail.com> writes:

>> -----Original Message-----
>> From: Markus Armbruster <armbru@redhat.com>
>> Sent: 24 April 2020 20:20
>> To: qemu-devel@nongnu.org
>> Cc: Stefano Stabellini <sstabellini@kernel.org>; Anthony Perard <anthony=
.perard@citrix.com>; Paul
>> Durrant <paul@xen.org>; Gerd Hoffmann <kraxel@redhat.com>; xen-devel@lis=
ts.xenproject.org
>> Subject: [PATCH 02/11] xen: Fix and improve handling of device_add usb-h=
ost errors
>>=20
>> usbback_portid_add() leaks the error when qdev_device_add() fails.
>> Fix that.  While there, use the error to improve the error message.
>>=20
>> The qemu_opts_from_qdict() similarly leaks on failure.  But any
>> failure there is a programming error.  Pass &error_abort.
>>=20
>> Fixes: 816ac92ef769f9ffc534e49a1bb6177bddce7aa2
>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>> Cc: Anthony Perard <anthony.perard@citrix.com>
>> Cc: Paul Durrant <paul@xen.org>
>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>> Cc: xen-devel@lists.xenproject.org
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>> ---
>>  hw/usb/xen-usb.c | 18 ++++++++----------
>>  1 file changed, 8 insertions(+), 10 deletions(-)
>>=20
>> diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
>> index 961190d0f7..42643c3390 100644
>> --- a/hw/usb/xen-usb.c
>> +++ b/hw/usb/xen-usb.c
>> @@ -30,6 +30,7 @@
>>  #include "hw/usb.h"
>>  #include "hw/xen/xen-legacy-backend.h"
>>  #include "monitor/qdev.h"
>> +#include "qapi/error.h"
>>  #include "qapi/qmp/qdict.h"
>>  #include "qapi/qmp/qstring.h"
>>=20
>> @@ -755,13 +756,15 @@ static void usbback_portid_add(struct usbback_info=
 *usbif, unsigned port,
>>      qdict_put_int(qdict, "port", port);
>>      qdict_put_int(qdict, "hostbus", atoi(busid));
>>      qdict_put_str(qdict, "hostport", portname);
>> -    opts =3D qemu_opts_from_qdict(qemu_find_opts("device"), qdict, &loc=
al_err);
>> -    if (local_err) {
>> -        goto err;
>> -    }
>> +    opts =3D qemu_opts_from_qdict(qemu_find_opts("device"), qdict,
>> +                                &error_abort);
>>      usbif->ports[port - 1].dev =3D USB_DEVICE(qdev_device_add(opts, &lo=
cal_err));
>>      if (!usbif->ports[port - 1].dev) {
>> -        goto err;
>> +        qobject_unref(qdict);
>> +        xen_pv_printf(&usbif->xendev, 0,
>> +                      "device %s could not be opened: %s\n",
>> +                      busid, error_get_pretty(local_err));
>> +        error_free(local_err);
>
> Previously the goto caused the function to bail out. Should there not be =
a 'return' here?

Owww, of course.  Thanks!

>
>>      }
>>      qobject_unref(qdict);
>>      speed =3D usbif->ports[port - 1].dev->speed;
>> @@ -793,11 +796,6 @@ static void usbback_portid_add(struct usbback_info =
*usbif, unsigned port,
>>      usbback_hotplug_enq(usbif, port);
>>=20
>>      TR_BUS(&usbif->xendev, "port %d attached\n", port);
>> -    return;
>> -
>> -err:
>> -    qobject_unref(qdict);
>> -    xen_pv_printf(&usbif->xendev, 0, "device %s could not be opened\n",=
 busid);
>>  }
>>=20
>>  static void usbback_process_port(struct usbback_info *usbif, unsigned p=
ort)
>> --
>> 2.21.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 05:51:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 05:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTfct-0003px-3d; Wed, 29 Apr 2020 05:51:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fvgr=6N=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTfcr-0003pr-Co
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 05:51:17 +0000
X-Inumbo-ID: 7057b296-89dd-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7057b296-89dd-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 05:51:15 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1C630AC79;
 Wed, 29 Apr 2020 05:51:14 +0000 (UTC)
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: Julien Grall <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
Date: Wed, 29 Apr 2020 07:51:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.20 22:55, Julien Grall wrote:
> Hi Juergen,
> 
> On Tue, 28 Apr 2020 at 16:53, Juergen Gross <jgross@suse.com> wrote:
>>
>> The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
>> of the domain's xenstore ring page and the event channel of the
>> domain for communicating with Xenstore.
>>
>> The gfn is not really needed. It is stored in the per-domain struct
>> in xenstored and in case of another XS_INTRODUCE for the domain it
>> is tested to match the original value. If it doesn't match the
>> command is aborted via EINVAL.
>>
>> Today there shouldn't be multiple XS_INTRODUCE requests for the same
>> domain issued, so the mfn/gfn can just be ignored and multiple
>> XS_INTRODUCE commands can be rejected without testing the mfn/gfn.
> 
> So there is a comment in the else part:
> 
> /* Use XS_INTRODUCE for recreating the xenbus event-channel. */
> 
>  From the commit message this is not entirely clear why we want to
> prevent recreating the event-channel. Can you expand it?

Recreating the event channel would be fine, but I don't see why it
would ever be needed. And XS_INTRODUCE is called only at domain creation
time today, so there is obviously no need for repeating this call.

Maybe the idea was to do this after sending a XS_RESUME command, which
isn't used anywhere in Xen and is another part of Xenstore which doesn't
make any sense today.

> 
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   tools/xenstore/xenstored_domain.c | 47 ++++++++++++++++-----------------------
>>   1 file changed, 19 insertions(+), 28 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index 5858185211..17328f9fc9 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -369,7 +369,6 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
>>          struct domain *domain;
>>          char *vec[3];
>>          unsigned int domid;
>> -       unsigned long mfn;
>>          evtchn_port_t port;
>>          int rc;
>>          struct xenstore_domain_interface *interface;
>> @@ -381,7 +380,7 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
>>                  return EACCES;
>>
>>          domid = atoi(vec[0]);
>> -       mfn = atol(vec[1]);
>> +       /* Ignore the mfn, we don't need it. */
> 
> s/mfn/GFN/

Okay, then I should probably change the parameter description, too.

> 
>>          port = atoi(vec[2]);
>>
>>          /* Sanity check args. */
>> @@ -390,34 +389,26 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
>>
>>          domain = find_domain_by_domid(domid);
>>
>> -       if (domain == NULL) {
>> -               interface = map_interface(domid);
>> -               if (!interface)
>> -                       return errno;
>> -               /* Hang domain off "in" until we're finished. */
>> -               domain = new_domain(in, domid, port);
>> -               if (!domain) {
>> -                       rc = errno;
>> -                       unmap_interface(interface);
>> -                       return rc;
>> -               }
>> -               domain->interface = interface;
>> -               domain->mfn = mfn;
> 
> AFAICT domain->mfn is not used anymore, so could we remove the field?

Oh, yes, I missed that.


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 06:06:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 06:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTfr5-0004zm-CA; Wed, 29 Apr 2020 06:05:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTfr3-0004zh-JJ
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 06:05:57 +0000
X-Inumbo-ID: 7d34c056-89df-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7d34c056-89df-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 06:05:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Yti7EmUpQsEXqjE+qKeMrS+4tnioSmFLjWzmWWL71XQ=; b=VqW5s5OgI39jRygZikn7aX5/b
 +3XiRzoo28mm+UHsWp2ipFQnDDK3wy+9NT87j5ALcjzwC1vfWzOSyVBskFKHjRQEEtP/YkWzrwLV8
 6NcKnUnc8Usw6Idi3Zo5wNq4e1j65MNmRNEKT0Tf6Pq6PwJJt3H58VxOmSBy0NwgcA1HI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTfr1-0001Q2-Np; Wed, 29 Apr 2020 06:05:55 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTfr1-0005HL-F4; Wed, 29 Apr 2020 06:05:55 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTfr1-00067t-EO; Wed, 29 Apr 2020 06:05:55 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149866-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149866: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: qemuu=fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6
X-Osstest-Versions-That: qemuu=ee573f5326046223b6eef4ae7fbfec31d274e093
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 06:05:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149866 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149866/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds    16 guest-start/debian.repeat fail REGR. vs. 149744

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149744
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149744
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149744
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149744
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149744
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149744
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-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-thunderx 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 qemuu                fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6
baseline version:
 qemuu                ee573f5326046223b6eef4ae7fbfec31d274e093

Last test of basis   149744  2020-04-23 03:46:20 Z    6 days
Testing same since   149866  2020-04-28 17:07:10 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Peter Maydell <peter.maydell@linaro.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   ee573f5326..fdd76fecdd  fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6 -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 06:07:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 06:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTft0-00056G-QL; Wed, 29 Apr 2020 06:07:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=4BoJ=6N=xen.org=tim@srs-us1.protection.inumbo.net>)
 id 1jTfsz-00056A-JG
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 06:07:57 +0000
X-Inumbo-ID: c5080d66-89df-11ea-ae69-bc764e2007e4
Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c5080d66-89df-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 06:07:57 +0000 (UTC)
Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD))
 (envelope-from <tim@xen.org>)
 id 1jTfst-000Bac-6g; Wed, 29 Apr 2020 06:07:51 +0000
Date: Wed, 29 Apr 2020 07:07:51 +0100
From: Tim Deegan <tim@xen.org>
To: Wei Liu <wl@xen.org>
Subject: Re: [PATCH v11 1/3] x86/tlb: introduce a flush HVM ASIDs flag
Message-ID: <20200429060751.GA44460@deinos.phlegethon.org>
References: <20200423145611.55378-1-roger.pau@citrix.com>
 <20200423145611.55378-2-roger.pau@citrix.com>
 <59e48d80-8ce1-3f3d-c07e-5117adea272a@suse.com>
 <20200427101235.6xko3lvt3qajo64m@debian>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200427101235.6xko3lvt3qajo64m@debian>
User-Agent: Mutt/1.11.1 (2018-12-01)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
 SAEximRunCond expanded to false
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

At 11:12 +0100 on 27 Apr (1587985955), Wei Liu wrote:
> On Thu, Apr 23, 2020 at 06:33:49PM +0200, Jan Beulich wrote:
> > On 23.04.2020 16:56, Roger Pau Monne wrote:
> > > Introduce a specific flag to request a HVM guest linear TLB flush,
> > > which is an ASID/VPID tickle that forces a guest linear to guest
> > > physical TLB flush for all HVM guests.
> > > 
> > > This was previously unconditionally done in each pre_flush call, but
> > > that's not required: HVM guests not using shadow don't require linear
> > > TLB flushes as Xen doesn't modify the pages tables the guest runs on
> > > in that case (ie: when using HAP). Note that shadow paging code
> > > already takes care of issuing the necessary flushes when the shadow
> > > page tables are modified.
> > > 
> > > In order to keep the previous behavior modify all shadow code TLB
> > > flushes to also flush the guest linear to physical TLB if the guest is
> > > HVM. I haven't looked at each specific shadow code TLB flush in order
> > > to figure out whether it actually requires a guest TLB flush or not,
> > > so there might be room for improvement in that regard.
> > > 
> > > Also perform ASID/VPID flushes when modifying the p2m tables as it's a
> > > requirement for AMD hardware. Finally keep the flush in
> > > switch_cr3_cr4, as it's not clear whether code could rely on
> > > switch_cr3_cr4 also performing a guest linear TLB flush. A following
> > > patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to
> > > not be necessary.
> > > 
> > > Signed-off-by: Roger Pau Monn� <roger.pau@citrix.com>
> > 
> > Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> Tim, ICYMI, this patch needs your ack.

Sorry!  Thanks for the reminder.

Acked-by: Tim Deegan <tim@xen.org>



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 07:21:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 07:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTh1f-0003q1-L1; Wed, 29 Apr 2020 07:20:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=W7WZ=6N=redhat.com=armbru@srs-us1.protection.inumbo.net>)
 id 1jTh1e-0003pw-8B
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 07:20:58 +0000
X-Inumbo-ID: f8675ac2-89e9-11ea-b07b-bc764e2007e4
Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id f8675ac2-89e9-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 07:20:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588144857;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=LuKMz2cunkuyvgsHrtA6mHRQurhlf+Q6ZpdMc5OyeVA=;
 b=YPBuMTW12EnWYveR326vcqxkUUOw4frNJbAtyhAipiuA0hgFz5JL6whaTMw2e4O+Mnfxbt
 9gurWbor2RBwrMN0b2Sq0sbQH2yv2DuyF1tAnNRAHqhKp6IUTJyzEvcYv19xLPoYOp81kT
 0wqxC3oboz2YgAv5ig0GfGr4fNLkklE=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-212-PhhyA91fOTm_1kO8hKGi9g-1; Wed, 29 Apr 2020 03:20:55 -0400
X-MC-Unique: PhhyA91fOTm_1kO8hKGi9g-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com
 [10.5.11.15])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CB9DFBFC5;
 Wed, 29 Apr 2020 07:20:53 +0000 (UTC)
Received: from blackfin.pond.sub.org (ovpn-113-6.ams2.redhat.com [10.36.113.6])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id 75ED25D779;
 Wed, 29 Apr 2020 07:20:53 +0000 (UTC)
Received: by blackfin.pond.sub.org (Postfix, from userid 1000)
 id 3BA1911358D0; Wed, 29 Apr 2020 09:20:49 +0200 (CEST)
From: Markus Armbruster <armbru@redhat.com>
To: qemu-devel@nongnu.org
Subject: [PULL 19/32] xen/pt: Fix flawed conversion to realize()
Date: Wed, 29 Apr 2020 09:20:35 +0200
Message-Id: <20200429072048.29963-20-armbru@redhat.com>
In-Reply-To: <20200429072048.29963-1-armbru@redhat.com>
References: <20200429072048.29963-1-armbru@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <sstabellini@kernel.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The conversion of xen_pt_initfn() to xen_pt_realize() blindly replaced
XEN_PT_ERR() by error_setg().  Several error conditions that did not
fail xen_pt_initfn() now fail xen_pt_realize().  Unsurprisingly, the
cleanup on these errors looks highly suspicious.

Revert the inappropriate replacements.

Fixes: 5a11d0f7549e24a10e178a9dc8ff5e698031d9a6
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Paul Durrant <paul@xen.org>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Message-Id: <20200422130719.28225-10-armbru@redhat.com>
---
 hw/xen/xen_pt.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index b91082cb8b..81d5ad8da7 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -858,8 +858,8 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
=20
     rc =3D xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
     if (rc < 0) {
-        error_setg_errno(errp, errno, "Mapping machine irq %u to"
-                         " pirq %i failed", machine_irq, pirq);
+        XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (err: %d)=
\n",
+                   machine_irq, pirq, errno);
=20
         /* Disable PCI intx assertion (turn on bit10 of devctl) */
         cmd |=3D PCI_COMMAND_INTX_DISABLE;
@@ -880,8 +880,8 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
                                        PCI_SLOT(d->devfn),
                                        e_intx);
         if (rc < 0) {
-            error_setg_errno(errp, errno, "Binding of interrupt %u failed"=
,
-                             e_intx);
+            XEN_PT_ERR(d, "Binding of interrupt %i failed! (err: %d)\n",
+                       e_intx, errno);
=20
             /* Disable PCI intx assertion (turn on bit10 of devctl) */
             cmd |=3D PCI_COMMAND_INTX_DISABLE;
@@ -889,8 +889,8 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
=20
             if (xen_pt_mapped_machine_irq[machine_irq] =3D=3D 0) {
                 if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq))=
 {
-                    error_setg_errno(errp, errno, "Unmapping of machine"
-                            " interrupt %u failed", machine_irq);
+                    XEN_PT_ERR(d, "Unmapping of machine interrupt %i faile=
d!"
+                               " (err: %d)\n", machine_irq, errno);
                 }
             }
             s->machine_irq =3D 0;
--=20
2.21.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 07:31:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 07:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jThBR-0004p8-Jz; Wed, 29 Apr 2020 07:31:05 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jThBP-0004p3-Qx
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 07:31:03 +0000
X-Inumbo-ID: 614c4b14-89eb-11ea-9917-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 614c4b14-89eb-11ea-9917-12813bfff9fa;
 Wed, 29 Apr 2020 07:31:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=1CWIOHl/xopULArUOSwQegsq50P4EMeHVEHYJFeI3LM=; b=qNDjyauU2dFP4BbXmS5bWsBTY
 g+H3TQvjQRVPaUcj2GSA02u1m4wPtim4Y7aHky1jYpWl5OUXrBsUg33MLcQS/NsEYcZUj2BYq0O1Q
 0Mk9yexvUYrzJqQ1J5KAwfw/Atr4bcPk5hlESXhYUZLev2UeHNz1cl39j6JpNKYs0QL08=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jThBO-0002yz-HF; Wed, 29 Apr 2020 07:31:02 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jThBO-0001Jc-7v; Wed, 29 Apr 2020 07:31:02 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jThBO-0006em-7H; Wed, 29 Apr 2020 07:31:02 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149870-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149870: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=c4ccb0d0ce57264361dd2ca704f9037935f7f44d
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 07:31:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149870 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149870/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
 build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              c4ccb0d0ce57264361dd2ca704f9037935f7f44d
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z  103 days
Failing since        146211  2020-01-18 04:18:52 Z  102 days   95 attempts
Testing same since   149870  2020-04-29 04:18:52 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Chen Hanxiao <chen_han_xiao@126.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mark Asselstine <mark.asselstine@windriver.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Philipp Hahn <hahn@univention.de>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 16767 lines long.)


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 07:37:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 07:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jThHZ-00057e-Bc; Wed, 29 Apr 2020 07:37:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jThHY-00057Z-Md
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 07:37:24 +0000
X-Inumbo-ID: 430828de-89ec-11ea-9917-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 430828de-89ec-11ea-9917-12813bfff9fa;
 Wed, 29 Apr 2020 07:37:22 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 180B7AF5C;
 Wed, 29 Apr 2020 07:37:20 +0000 (UTC)
Subject: Re: [PATCH] x86/pass-through: avoid double IRQ unbind during domain
 cleanup
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <6fddc420-b582-cb2f-92ce-b3e067c420c4@suse.com>
 <20200428161412.GU28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <c0f222dc-2b7a-be54-29a1-75bcc5686dde@suse.com>
Date: Wed, 29 Apr 2020 09:37:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200428161412.GU28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Varad Gautam <vrd@amazon.de>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.2020 18:14, Roger Pau Monné wrote:
> On Tue, Apr 28, 2020 at 02:21:48PM +0200, Jan Beulich wrote:
>> XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTs.
>> In that scenario, it is possible to receive multiple _pirq_guest_unbind
>> calls for the same pirq from domain_kill, if the pirq has not yet been
>> removed from the domain's pirq_tree, as:
>>   domain_kill()
>>     -> domain_relinquish_resources()
>>       -> pci_release_devices()
>>         -> pci_clean_dpci_irq()
>>           -> pirq_guest_unbind()
>>             -> __pirq_guest_unbind()
>>
>> Avoid recurring invocations of pirq_guest_unbind() by removing the pIRQ
>> from the tree being iterated after the first call there. In case such a
>> removed entry still has a softirq outstanding, record it and re-check
>> upon re-invocation.
>>
>> Reported-by: Varad Gautam <vrd@amazon.de>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Varad Gautam <vrd@amazon.de>
>>
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -1323,7 +1323,7 @@ void (pirq_cleanup_check)(struct pirq *p
>>      }
>>  
>>      if ( radix_tree_delete(&d->pirq_tree, pirq->pirq) != pirq )
>> -        BUG();
>> +        BUG_ON(!d->is_dying);
> 
> I think to keep the previous behavior this should be:
> 
> BUG_ON(!is_hvm_domain(d) || !d->is_dying);
> 
> Since the pirqs will only be removed elsewhere if the domain is HVM?

pirq_cleanup_check() is a generic hook, and hence I consider it more
correct to not have it behave differently in this regard for different
types of guests. IOW while it _may_ (didn't check) not be the case
today that this can be called multiple times even for PV guests, I'd
view this as legitimate behavior.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:07:30 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jThkd-00006o-K9; Wed, 29 Apr 2020 08:07:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/uTc=6N=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jThkd-00006i-0O
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:07:27 +0000
X-Inumbo-ID: 763a71cc-89f0-11ea-ae69-bc764e2007e4
Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 763a71cc-89f0-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 08:07:26 +0000 (UTC)
Received: by mail-wr1-x444.google.com with SMTP id j1so1360725wrt.1
 for <xen-devel@lists.xenproject.org>; Wed, 29 Apr 2020 01:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=ax/00jztm/qnemFteNHTg0gbhwqdcLui9LbTXg76E5k=;
 b=dDLsXhupuinNGpg5xkRKzJWfoxsiuGHHPtNhmNedrrz/A/+UvUbdHEW6K6E2UvY6ZT
 i5Ufo8hCxjCAwZffnWpqVNDwNV3Nr597TcrfkfmLekDJ4b28DLo3bSlMyNoAWcJcvLIK
 /1WnYwxr7+mLTANoSGBc8mZvLekY4CTZPzkSYbsfEXs5YegBY3OLNAOziopDNnOCQi+d
 Y9aF4A5sT52oDkS8HjKuvZMRrGQo2ZR9VEefITgfFVbXweXFYWvZr6iX4dgGfFfurCxu
 dayP7s5xzjgYf49ZjbtVoXHHdRUVkr6dJDbHD9oBbuhFacO7axo/YS+T1X0rVsiD1RPh
 W3zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=ax/00jztm/qnemFteNHTg0gbhwqdcLui9LbTXg76E5k=;
 b=Euo2yFGNengqz6qvSHbikYE+6YlcoW9xs7ZAyoD2/ynQCgPL/6tI9dSYmSyP2V49mt
 NGVIHXdg0NHgCEijHE8AVmj+SqCPNczLICAdnL3F0ouASLXs+Mv7XhKGp9aoTpnE7azX
 214w3VoxwQ9OwgR5vliYlXS+OL+7NsJmmnRAelhkLxcCL0WWCdUg5MCaRIStODwY1g/C
 AA9v6Yf9HNy++qunJK3euwD3yL08avr53jxolp8cnUZ6mu6lWdTGATWl1l87q5hF5uVv
 C28DM8qR1Z4lqC7v5Roqn64WWeNb6a0/LWqS5dHi/NFfGzdUfg3CaP4OCWYYdX38T9zT
 dzVA==
X-Gm-Message-State: AGi0Puar0rFF6GKDjbbfBBSqUBr3bcS0aQyV9Xydx+xCJApJgFR0T8UQ
 LfkcQSi80x3XJPS8oijIL/M=
X-Google-Smtp-Source: APiQypI6cFaukOff+Om1OyGYSBYy0HdNoxXqnGGwg7wGAhZ/qZmmPxhAD0dd/UYBlieQpyB7HvLsrA==
X-Received: by 2002:a5d:6844:: with SMTP id o4mr1605691wrw.392.1588147645328; 
 Wed, 29 Apr 2020 01:07:25 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.185])
 by smtp.gmail.com with ESMTPSA id v16sm6512863wml.30.2020.04.29.01.07.23
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 29 Apr 2020 01:07:24 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Grzegorz Uriasz'" <gorbak25@gmail.com>,
	<qemu-devel@nongnu.org>
References: <20200429030409.9406-1-gorbak25@gmail.com>
 <20200429030409.9406-2-gorbak25@gmail.com>
In-Reply-To: <20200429030409.9406-2-gorbak25@gmail.com>
Subject: RE: [PATCH v2 1/2] Fix undefined behaviour
Date: Wed, 29 Apr 2020 09:07:22 +0100
Message-ID: <002001d61dfd$37500210$a5f00630$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQFtlR//ELGf2l/FYLvu2IzrckebEAJdwmQ+qU3eScA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: artur@puzio.waw.pl, 'Stefano Stabellini' <sstabellini@kernel.org>,
 jakub@bartmin.ski, marmarek@invisiblethingslab.com,
 'Anthony Perard' <anthony.perard@citrix.com>, j.nowak26@student.uw.edu.pl,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Grzegorz Uriasz <gorbak25@gmail.com>
> Sent: 29 April 2020 04:04
> To: qemu-devel@nongnu.org
> Cc: Grzegorz Uriasz <gorbak25@gmail.com>; =
marmarek@invisiblethingslab.com; artur@puzio.waw.pl;
> jakub@bartmin.ski; j.nowak26@student.uw.edu.pl; Stefano Stabellini =
<sstabellini@kernel.org>; Anthony
> Perard <anthony.perard@citrix.com>; Paul Durrant <paul@xen.org>; =
xen-devel@lists.xenproject.org
> Subject: [PATCH v2 1/2] Fix undefined behaviour
>=20
> This patch fixes qemu crashes when passing through an IGD device to =
HVM guests under XEN. The problem
> is that on almost every laptop
> reading the IGD ROM from SYSFS will fail, the reason for it is that =
the IGD rom is polymorphic and it
> modifies itself
> during bootup - this results in an invalid rom image - the kernel =
checks whether the image is valid
> and when that's not the case
> it won't allow userspace to read it. It seems that when the code was =
first written(xen_pt_load_rom.c)
> the kernel's back then didn't check
> whether the rom is valid and just passed the contents to userspace - =
because of this qemu also tries
> to repair the rom later in the code.
> When stating the rom the kernel isn't validating the rom contents so =
it is returning the proper size
> of the rom(32 4kb pages).
>=20
> This results in undefined behaviour - pci_assign_dev_load_option_rom =
is creating a buffer and then
> writes the size of the buffer to a pointer.
> In pci_assign_dev_load_option_rom under old kernels if the fstat would =
succeed then fread would also
> succeed - this means if the buffer
> is allocated the size of the buffer will be set. On newer kernels this =
is not the case - on all
> laptops I've tested(spanning a few
> generations of IGD) the fstat is successful and the buffer is =
allocated but the fread is failing - as
> the buffer is not deallocated
> the function is returning a valid pointer without setting the size of =
the buffer for the caller. The
> caller of pci_assign_dev_load_option_rom
> is holding the size of the buffer in an uninitialized variable and is =
just checking whether
> pci_assign_dev_load_option_rom returned a valid pointer.
> This later results in cpu_physical_memory_write(0xc0000, =
result_of_pci_assign_dev_load_option_rom,
> unitialized_variable) which
> depending on the compiler parameters, configure flags, etc... might =
crash qemu or might work - the xen
> 4.12 stable release with default configure
> parameters works but changing the compiler options slightly(for =
instance by enabling qemu debug)
> results in qemu crashing =C2=AF\_(;-;)_/=C2=AF
>=20
> The only situation when the original pci_assign_dev_load_option_rom =
works is when the IDG is not the

I think you mean IGD

> boot gpu - this won't happen on any laptop and
> will be rare on desktops.
>=20
> This patch deallocates the buffer and returns NULL if reading the =
VBIOS fails - the caller of the
> function then properly shuts down qemu.
> The next patch in the series introduces a better method for getting =
the vbios so qemu does not exit
> when pci_assign_dev_load_option_rom fails -
> this is the reason I've changed error_report to warn_report as whether =
a failure in
> pci_assign_dev_load_option_rom is fatal
> depends on the caller.
>=20
> Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>

With the typo fixed...

Reviewed-by: Paul Durrant <paul@xen.org>



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:08:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jThln-0000Cw-Ul; Wed, 29 Apr 2020 08:08:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LUw1=6N=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jThln-0000Co-6r
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:08:39 +0000
X-Inumbo-ID: a141fc14-89f0-11ea-b07b-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a141fc14-89f0-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 08:08:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588147719;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=SvqjqrMYBeAWdvlE9uFbwfuApkwoz+pxaUFqhR/+AoA=;
 b=KcLtX1tRC/kTzz7KR9Vof3r8xWtATbx70RKjV/AZUEfuDhRoSHq6C5PP
 a6UiUD5/pbHlDiNfAXAKgbp14DplkDLJ7ZJhb4SinX19Zh7htiLYbLAtt
 wPdriXa0kmRnc6BvketpYU0Eu7DtnBSk/UnbGmqig1Hg/rOtjek1CVsv3 4=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: v+W0FvZPDADtrtRFyvHbab+JiVV7fLX9G3uXuDTHaxcIc25z7eq8h3OottxwssSEcZTrdaTqQ8
 ZhVpsDmPm7UBG83APn4+G4HkINBNvID4TCPHPcHmM0q5V0l6m54ks/MKTBZYC7xAtUGtb0wt/+
 UVTwUeDKCmixs4MteQnWjJAzaaJl73IFSGW2xX8mCWQBvWNs9B4x7CVNYioN2q+EMiFdfbekuT
 Vzjbuhnw/OrzpcWXxboy3QrptaISwW9Z5OW1OpZ3VnpTIuNAiLUliw8lq2OW3X1uNZDe3WsOik
 KIE=
X-SBRS: 2.7
X-MesageID: 16406208
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,330,1583211600"; d="scan'208";a="16406208"
Date: Wed, 29 Apr 2020 10:08:26 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Subject: Re: [PATCH v2] mem_sharing: map shared_info page to same gfn during
 fork
Message-ID: <20200429080826.GW28601@Air-de-Roger>
References: <6497e71a791bbc17b1ace3f5f260bd61275b76ba.1588087596.git.tamas.lengyel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6497e71a791bbc17b1ace3f5f260bd61275b76ba.1588087596.git.tamas.lengyel@intel.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, Apr 28, 2020 at 08:29:00AM -0700, Tamas K Lengyel wrote:
> During a VM fork we copy the shared_info page; however, we also need to ensure
> that the page is mapped into the same GFN in the fork as its in the parent.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> Suggested-by: Roger Pau Monne <roger.pau@citrix.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks!


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:09:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jThn1-0000LG-Dh; Wed, 29 Apr 2020 08:09:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fvgr=6N=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jThn0-0000L6-Gv
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:09:54 +0000
X-Inumbo-ID: ce019890-89f0-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ce019890-89f0-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 08:09:53 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id AFEB3ACC4;
 Wed, 29 Apr 2020 08:09:51 +0000 (UTC)
Subject: Re: Cpu on/offlining crash with core scheduling
To: Sergey Dyasli <sergey.dyasli@citrix.com>
References: <1587995374653.73805@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <103f3e30-a67e-77b7-9e92-572ee4b5d159@suse.com>
Date: Wed, 29 Apr 2020 10:09:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1587995374653.73805@citrix.com>
Content-Type: multipart/mixed; boundary="------------CDE6B0D50FE84F03F4E32008"
Content-Language: en-US
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is a multi-part message in MIME format.
--------------CDE6B0D50FE84F03F4E32008
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 27.04.20 15:49, Sergey Dyasli wrote:
> Hi Juergen,
> 
> When I'm testing vcpu pinning with something like:
> 
>       # xl vcpu-pin 0 0 2
>       # xen-hptool cpu-offline 3
> 
>       (offline / online CPUs {2,3} if the above is successful)
> 
> I'm reliably seeing the following crash on the latest staging:
> 
> (XEN) Watchdog timer detects that CPU1 is stuck!
> (XEN) ----[ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]----
> (XEN) CPU:    1
> (XEN) RIP:    e008:[<ffff82d08025266d>] common/sched/core.c#sched_wait_rendezvous_in+0x16c/0x385
> (XEN) RFLAGS: 0000000000000002   CONTEXT: hypervisor
> (XEN) rax: 000000000000f001   rbx: ffff82d0805c9118   rcx: ffff83085e750301
> (XEN) rdx: 0000000000000001   rsi: ffff83086499b972   rdi: ffff83085e7503a6
> (XEN) rbp: ffff83085e7dfe28   rsp: ffff83085e7dfdd8   r8:  ffff830864985440
> (XEN) r9:  ffff83085e714068   r10: 0000000000000014   r11: 00000056b6a1aab2
> (XEN) r12: ffff83086499e490   r13: ffff82d0805f26e0   r14: ffff83085e7503a0
> (XEN) r15: 0000000000000001   cr0: 0000000080050033   cr4: 0000000000362660
> (XEN) cr3: 0000000823a8e000   cr2: 00006026000f6fc0
> (XEN) fsb: 0000000000000000   gsb: ffff888138dc0000   gss: 0000000000000000
> (XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen code around <ffff82d08025266d> (common/sched/core.c#sched_wait_rendezvous_in+0x16c/0x385):
> (XEN)  4c 89 f7 e8 dc a5 fd ff <4b> 8b 44 fd 00 48 8b 04 18 4c 3b 70 10 0f 85 3f
> (XEN) Xen stack trace from rsp=ffff83085e7dfdd8:
> (XEN)    00000056b42128a6 ffff83086499ff30 ffff83086498a000 ffff83085e7dfe48
> (XEN)    0000000100000001 00000056b42128a6 ffff83086499e490 0000000000000000
> (XEN)    0000000000000001 0000000000000001 ffff83085e7dfe78 ffff82d080252ae8
> (XEN)    ffff83086498a000 0000000180230434 ffff83085e7503a0 ffff82d0805ceb00
> (XEN)    ffffffffffffffff ffff82d0805cea80 0000000000000000 ffff82d0805dea80
> (XEN)    ffff83085e7dfeb0 ffff82d08022c232 0000000000000001 ffff82d0805ceb00
> (XEN)    0000000000000001 0000000000000001 0000000000000001 ffff83085e7dfec0
> (XEN)    ffff82d08022c2cd ffff83085e7dfef0 ffff82d08031cae9 ffff83086498a000
> (XEN)    ffff83086498a000 0000000000000001 0000000000000001 ffff83085e7dfde8
> (XEN)    ffff88813021d700 ffff88813021d700 0000000000000000 0000000000000000
> (XEN)    0000000000000007 ffff88813021d700 0000000000000246 0000000000007ff0
> (XEN)    0000000000000000 000000000001ca00 0000000000000000 ffffffff810013aa
> (XEN)    ffffffff8203d210 deadbeefdeadf00d deadbeefdeadf00d 0000010000000000
> (XEN)    ffffffff810013aa 000000000000e033 0000000000000246 ffffc900400dfeb0
> (XEN)    000000000000e02b 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000e01000000001 ffff83086498a000 00000037e43bd000
> (XEN)    0000000000362660 0000000000000000 8000000864980002 0000060100000000
> (XEN)    0000000000000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82d08025266d>] R common/sched/core.c#sched_wait_rendezvous_in+0x16c/0x385
> (XEN)    [<ffff82d080252ae8>] F common/sched/core.c#sched_slave+0x262/0x31e
> (XEN)    [<ffff82d08022c232>] F common/softirq.c#__do_softirq+0x8a/0xbc
> (XEN)    [<ffff82d08022c2cd>] F do_softirq+0x13/0x15
> (XEN)    [<ffff82d08031cae9>] F arch/x86/domain.c#idle_loop+0x57/0xa7
> (XEN)
> (XEN) CPU0 @ e008:ffff82d08022c2b7 (process_pending_softirqs+0x53/0x56)
> (XEN) CPU4 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callbacks+0x22e/0x24b)
> (XEN) CPU2 @ e008:ffff82d08022c26f (process_pending_softirqs+0xb/0x56)
> (XEN) CPU7 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callbacks+0x22e/0x24b)
> (XEN) CPU3 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callbacks+0x22e/0x24b)
> (XEN) CPU5 @ e008:ffff82d08022cc34 (_spin_lock+0x4d/0x62)
> (XEN) CPU6 @ e008:ffff82d08022c264 (process_pending_softirqs+0/0x56)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 1:
> (XEN) FATAL TRAP: vector = 2 (nmi)
> (XEN) [error_code=0000] , IN INTERRUPT CONTEXT
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> (XEN) Executing kexec image on cpu1
> (XEN) Shot down all CPUs
> 
> 
> Is this something you can reproduce?

Yes, I was able to hit this.

Attached patch is fixing it for me. Could you give it a try?


Juergen

--------------CDE6B0D50FE84F03F4E32008
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-xen-sched-allow-rcu-work-to-happen-when-syncing-cpus.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-xen-sched-allow-rcu-work-to-happen-when-syncing-cpus.pa";
 filename*1="tch"

>From 44b530f4bb9c94ae4e429b83d730237f11410a5f Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Wed, 29 Apr 2020 09:40:46 +0200
Subject: [PATCH] xen/sched: allow rcu work to happen when syncing cpus in core
 scheduling

With RCU barriers moved from tasklets to normal RCU processing cpu
offlining in core scheduling might deadlock due to cpu synchronization
required by RCU processing and core scheduling concurrently.

Fix that by bailing out from core scheduling synchronization in case
of pending RCU work. Additionally the RCU softirq is now required to
be of higher priority than the scheduling softirqs in order to do
RCU processing before entering the scheduler again, as bailing out from
the core scheduling synchronization requires to raise another softirq
SCHED_SLAVE, which would bypass RCU processing again.

Reported-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/sched/core.c   | 10 +++++++---
 xen/include/xen/softirq.h |  2 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d94b95285f..a099e37b0f 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2457,13 +2457,17 @@ static struct sched_unit *sched_wait_rendezvous_in(struct sched_unit *prev,
             v = unit2vcpu_cpu(prev, cpu);
         }
         /*
-         * Coming from idle might need to do tasklet work.
+         * Check for any work to be done which might need cpu synchronization.
+         * This is either pending RCU work, or tasklet work when coming from
+         * idle.
          * In order to avoid deadlocks we can't do that here, but have to
-         * continue the idle loop.
+         * schedule the previous vcpu again, which will lead to the desired
+         * processing to be done.
          * Undo the rendezvous_in_cnt decrement and schedule another call of
          * sched_slave().
          */
-        if ( is_idle_unit(prev) && sched_tasklet_check_cpu(cpu) )
+        if ( rcu_pending(cpu) ||
+             (is_idle_unit(prev) && sched_tasklet_check_cpu(cpu)) )
         {
             struct vcpu *vprev = current;
 
diff --git a/xen/include/xen/softirq.h b/xen/include/xen/softirq.h
index b4724f5c8b..1f6c4783da 100644
--- a/xen/include/xen/softirq.h
+++ b/xen/include/xen/softirq.h
@@ -4,10 +4,10 @@
 /* Low-latency softirqs come first in the following list. */
 enum {
     TIMER_SOFTIRQ = 0,
+    RCU_SOFTIRQ,
     SCHED_SLAVE_SOFTIRQ,
     SCHEDULE_SOFTIRQ,
     NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ,
-    RCU_SOFTIRQ,
     TASKLET_SOFTIRQ,
     NR_COMMON_SOFTIRQS
 };
-- 
2.16.4


--------------CDE6B0D50FE84F03F4E32008--


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:21:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jThxn-00027A-Fb; Wed, 29 Apr 2020 08:21:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/uTc=6N=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jThxm-000274-5j
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:21:02 +0000
X-Inumbo-ID: 5c0487b4-89f2-11ea-b9cf-bc764e2007e4
Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5c0487b4-89f2-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 08:21:01 +0000 (UTC)
Received: by mail-wr1-x442.google.com with SMTP id j2so1363617wrs.9
 for <xen-devel@lists.xenproject.org>; Wed, 29 Apr 2020 01:21:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=bYaqg9ydbwBt0js6txP6ki/prPNP0trtCyBSqQbrobQ=;
 b=X/ifDRcsX//oWfrKOCF95UTlM8nTjbfEN2YNN8a3lxS7/WXdwJIVECtAdjJMtF6dnl
 9rKyYKthAh8vSUTJq/7CwI8XjEKKjH0tImI32k7XRHe/9ygtRgrOD8FwtbVCKB2pDgR1
 w9AwHePJ19NNJ3vz6Hgu1fGmjs8D/PP+R0nQOycHVYgIobXh02Z7Ey74T7Eue9qJWSW6
 ozgwk+VYqqDqjXVCw7Utot5okJA9LYrZs9SOb5PKO8DE70sY6pMdQL+Cjw2BhERZnzAg
 qQXjCHzVgi3oY7+Lxgev+Bb/e24I90hkUId50P5i4nOUY0TD0km9L2Vz7HAbA3AB0IaL
 5Z9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :thread-index:content-language;
 bh=bYaqg9ydbwBt0js6txP6ki/prPNP0trtCyBSqQbrobQ=;
 b=oU970X3EXyxM4HMUKpqthKeIzwdK1S7QuksQ1F6onQSDyReYMfjANitiHvMGmNu740
 MLK/rnJ8oI/59g/kUQfPduI+idIM0W1kQb2J/Yn8GsR/6TXEuuVZpOgkdQnkk2/ESDQl
 QKjeIa4Gxvcq3pkVyRzl6zRLM+9etgStfOgSEtuJEx0Ft2h/yityVY6qWgPqp4VhiU/N
 bYkK0N4WnPOhqIniOv5x1pHZRkzWS3/FShhoYlbXzHAXap07zIvsbWcpip4/c7rTN1D3
 hr+D1jiHPkwZmsFe0vP0fxPw1/Sed7W9K69WlKCYKLwR9QcXnU8UOJ8ouXuRHEXlypND
 fncQ==
X-Gm-Message-State: AGi0Puby7jf2ToZeprP6XyAJGEBD4i+johH2R0LtaGGCiGApNyO/hu/f
 RaX7id4uQ0XWdTAPC3AFkP8=
X-Google-Smtp-Source: APiQypIdTB9pj3s5+HsG0ipZxTuN6qEj6czRhMIH2sYciiFQV+4evNyC5gWUJUJvyUxzDBEnb/V7wA==
X-Received: by 2002:a5d:4b43:: with SMTP id w3mr38262885wrs.208.1588148460211; 
 Wed, 29 Apr 2020 01:21:00 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.186])
 by smtp.gmail.com with ESMTPSA id i25sm6530739wml.43.2020.04.29.01.20.58
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 29 Apr 2020 01:20:59 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Grzegorz Uriasz'" <gorbak25@gmail.com>,
	<qemu-devel@nongnu.org>
References: <20200429030409.9406-1-gorbak25@gmail.com>
 <20200429030409.9406-3-gorbak25@gmail.com>
In-Reply-To: <20200429030409.9406-3-gorbak25@gmail.com>
Subject: RE: [PATCH v2 2/2] Improve legacy vbios handling
Date: Wed, 29 Apr 2020 09:20:58 +0100
Message-ID: <000101d61dff$1d0f5b60$572e1220$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFtlR//ELGf2l/FYLvu2IzrckebEAI2wQ0TqU8dnlA=
Content-Language: en-gb
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: artur@puzio.waw.pl, 'Stefano Stabellini' <sstabellini@kernel.org>,
 jakub@bartmin.ski, marmarek@invisiblethingslab.com,
 'Anthony Perard' <anthony.perard@citrix.com>, j.nowak26@student.uw.edu.pl,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Grzegorz Uriasz <gorbak25@gmail.com>
> Sent: 29 April 2020 04:04
> To: qemu-devel@nongnu.org
> Cc: Grzegorz Uriasz <gorbak25@gmail.com>; marmarek@invisiblethingslab.com; artur@puzio.waw.pl;
> jakub@bartmin.ski; j.nowak26@student.uw.edu.pl; Stefano Stabellini <sstabellini@kernel.org>; Anthony
> Perard <anthony.perard@citrix.com>; Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
> Subject: [PATCH v2 2/2] Improve legacy vbios handling
> 
> The current method of getting the vbios is broken - it just isn't working on any device I've tested -
> the reason
> for this is explained in the previous patch. The vbios is polymorphic and getting a proper unmodified
> copy is
> often not possible without reverse engineering the firmware. We don't need an unmodified copy for most
> purposes -
> an unmodified copy is only needed for initializing the bios framebuffer and providing the bios with a
> corrupted
> copy of the rom won't do any damage as the bios will just ignore the rom.
> 
> After the i915 driver takes over the vbios is only needed for reading some metadata/configuration
> stuff etc...
> I've tested that not having any kind of vbios in the guest actually works fine but on older
> generations of IGD
> there are some slight hiccups. To maximize compatibility the best approach is to just copy the results
> of the vbios
> execution directly to the guest. It turns out the vbios is always present on an hardcoded memory range
> in a reserved
> memory range from real mode - all we need to do is to memcpy it into the guest.
> 
> The following patch does 2 things:
> 1) When pci_assign_dev_load_option_rom fails to read the vbios from sysfs(this works only when the igd
> is not the
> boot gpu - this is unlikely to happen) it falls back to using /dev/mem to copy the vbios directly to
> the guest.

Why bother with sysfs if it is unlikely to work?

> Using /dev/mem should be fine as there is more xen specific pci code which also relies on /dev/mem.
> 2) When dealing with IGD in the more generic code we skip the allocation of the rom resource - the
> reason for this is to prevent
> a malicious guest from modifying the vbios in the host -> this is needed as someone might try to pwn
> the i915 driver in the host by doing so
> (attach igd to guest, guest modifies vbios, the guest is terminated and the idg is reattached to the
> host, i915 driver in the host uses data from the modified vbios).
> This is also needed to not overwrite the proper shadow copy made before.
> 
> I've tested this patch and it works fine - the guest isn't complaining about the missing vbios tables
> and the pci config
> space in the guest looks fine.
> 
> Signed-off-by: Grzegorz Uriasz <gorbak25@gmail.com>
> ---
>  hw/xen/xen_pt.c          |  8 +++++--
>  hw/xen/xen_pt_graphics.c | 48 +++++++++++++++++++++++++++++++++++++---
>  hw/xen/xen_pt_load_rom.c |  2 +-
>  3 files changed, 52 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index b91082cb8b..ffc3559dd4 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -483,8 +483,12 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd)
>                     i, r->size, r->base_addr, type);
>      }
> 
> -    /* Register expansion ROM address */
> -    if (d->rom.base_addr && d->rom.size) {
> +    /*
> +     * Register expansion ROM address. If we are dealing with a ROM
> +     * shadow copy for legacy vga devices then don't bother to map it
> +     * as previous code creates a proper shadow copy
> +     */
> +    if (d->rom.base_addr && d->rom.size && !(is_igd_vga_passthrough(d))) {

You don't need brackets around the function call.

  Paul

>          uint32_t bar_data = 0;
> 
>          /* Re-set BAR reported by OS, otherwise ROM can't be read. */
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index a3bc7e3921..fe0ef2685c 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -129,7 +129,7 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
>      return 0;
>  }
> 
> -static void *get_vgabios(XenPCIPassthroughState *s, int *size,
> +static void *get_sysfs_vgabios(XenPCIPassthroughState *s, int *size,
>                         XenHostPCIDevice *dev)
>  {
>      return pci_assign_dev_load_option_rom(&s->dev, size,
> @@ -137,6 +137,45 @@ static void *get_vgabios(XenPCIPassthroughState *s, int *size,
>                                            dev->dev, dev->func);
>  }
> 
> +static void xen_pt_direct_vbios_copy(XenPCIPassthroughState *s, Error **errp)
> +{
> +    int fd = -1;
> +    void *guest_bios = NULL;
> +    void *host_vbios = NULL;
> +    /* This is always 32 pages in the real mode reserved region */
> +    int bios_size = 32 << XC_PAGE_SHIFT;
> +    int vbios_addr = 0xc0000;
> +
> +    fd = open("/dev/mem", O_RDONLY);
> +    if (fd == -1) {
> +        error_setg(errp, "Can't open /dev/mem: %s", strerror(errno));
> +        return;
> +    }
> +    host_vbios = mmap(NULL, bios_size,
> +            PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, fd, vbios_addr);
> +    close(fd);
> +
> +    if (host_vbios == MAP_FAILED) {
> +        error_setg(errp, "Failed to mmap host vbios: %s", strerror(errno));
> +        return;
> +    }
> +
> +    memory_region_init_ram(&s->dev.rom, OBJECT(&s->dev),
> +            "legacy_vbios.rom", bios_size, &error_abort);
> +    guest_bios = memory_region_get_ram_ptr(&s->dev.rom);
> +    memcpy(guest_bios, host_vbios, bios_size);
> +
> +    if (munmap(host_vbios, bios_size) == -1) {
> +        XEN_PT_LOG(&s->dev, "Failed to unmap host vbios: %s\n", strerror(errno));
> +    }
> +
> +    cpu_physical_memory_write(vbios_addr, guest_bios, bios_size);
> +    memory_region_set_address(&s->dev.rom, vbios_addr);
> +    pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->dev.rom);
> +    s->dev.has_rom = true;
> +    XEN_PT_LOG(&s->dev, "Legacy VBIOS registered\n");
> +}
> +
>  /* Refer to Seabios. */
>  struct rom_header {
>      uint16_t signature;
> @@ -179,9 +218,11 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
>          return;
>      }
> 
> -    bios = get_vgabios(s, &bios_size, dev);
> +    bios = get_sysfs_vgabios(s, &bios_size, dev);
>      if (!bios) {
> -        error_setg(errp, "VGA: Can't get VBIOS");
> +        XEN_PT_LOG(&s->dev, "Unable to get host VBIOS from sysfs - "
> +                            "falling back to a direct copy of memory ranges\n");
> +        xen_pt_direct_vbios_copy(s, errp);
>          return;
>      }
> 
> @@ -223,6 +264,7 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
> 
>      /* Currently we fixed this address as a primary for legacy BIOS. */
>      cpu_physical_memory_write(0xc0000, bios, bios_size);
> +    XEN_PT_LOG(&s->dev, "Legacy VBIOS registered\n");
>  }
> 
>  uint32_t igd_read_opregion(XenPCIPassthroughState *s)
> diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
> index 9f100dc159..8cd9aa84dc 100644
> --- a/hw/xen/xen_pt_load_rom.c
> +++ b/hw/xen/xen_pt_load_rom.c
> @@ -65,7 +65,7 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
>          goto close_rom;
>      }
> 
> -    pci_register_bar(dev, PCI_ROM_SLOT, 0, &dev->rom);
> +    pci_register_bar(dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_SPACE_MEMORY, &dev->rom);
>      dev->has_rom = true;
>      *size = st.st_size;
>  close_rom:
> --
> 2.26.1




From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:22:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jThzB-0002Kg-Qy; Wed, 29 Apr 2020 08:22:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jThzB-0002Ka-D4
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:22:29 +0000
X-Inumbo-ID: 8f764a7e-89f2-11ea-991b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8f764a7e-89f2-11ea-991b-12813bfff9fa;
 Wed, 29 Apr 2020 08:22:27 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 44278AD4F;
 Wed, 29 Apr 2020 08:22:25 +0000 (UTC)
Subject: Re: [PATCH v4] x86: clear RDRAND CPUID bit on AMD family 15h/16h
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <69382ba7-b562-2c8c-1843-b17ce6c512f1@suse.com>
 <68aa71c6-a41b-9f7c-f3ca-94060fae5db0@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <c150ef54-4519-2b9f-6029-cdefb13ef6c2@suse.com>
Date: Wed, 29 Apr 2020 10:22:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <68aa71c6-a41b-9f7c-f3ca-94060fae5db0@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Paul Durrant <Paul.Durrant@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 02.04.2020 16:25, Andrew Cooper wrote:
> On 09/03/2020 09:08, Jan Beulich wrote:
>> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
>>
>>     There have been reports of RDRAND issues after resuming from suspend on
>>     some AMD family 15h and family 16h systems. This issue stems from a BIOS
>>     not performing the proper steps during resume to ensure RDRAND continues
>>     to function properly.
>>
>>     Update the CPU initialization to clear the RDRAND CPUID bit for any family
>>     15h and 16h processor that supports RDRAND. If it is known that the family
>>     15h or family 16h system does not have an RDRAND resume issue or that the
>>     system will not be placed in suspend, the "cpuid=rdrand" kernel parameter
> 
> I'm not sure what is best to do here.  The type suggests that this is a
> verbatim copy of the Linux commit message, but this tiny detail is Xen
> specific.

It simply didn't seem to make sense to leave the Linux way of
specifying this in here, just to then say further down what the
correct (Xen) way is.

>> ---
>> Still slightly RFC, and still in particular because of the change to
>> parse_xen_cpuid():
> 
> FWIW, that is very similar to XenServer's AVX512 off-by-default bodge
> until the default vs max policy work is ready.
> 
> I don't have a better suggestion right now, but hopefully something
> better might become obvious when we've got more users.  Either way, I'm
> expecting it to turn into a "switch ( mid->bit )" expression in due course.

IOW do you want me to use switch() right away?

>> @@ -646,6 +647,25 @@ static void init_amd(struct cpuinfo_x86
>>  		if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value))
>>  			amd_acpi_c1e_quirk = true;
>>  		break;
>> +
>> +	case 0x15: case 0x16:
>> +		/*
>> +		 * There are too many Fam15/Fam16 systems where upon resume
> 
> "some" systems.
> 
>> +		 * from S3 firmware fails to re-setup properly functioning
>> +		 * RDRAND.
> 
> I think this needs another sentence of explanation.
> 
> By the time we can spot the problem, it is too late to take evasive
> action, and there is nothing Xen can do to repair the problem.

Sure, added.

>>   Clear the feature unless force-enabled on the
>> +		 * command line.
>> +		 */
>> +		if (c == &boot_cpu_data &&
>> +		    cpu_has(c, X86_FEATURE_RDRAND) &&
>> +		    !is_forced_cpu_cap(X86_FEATURE_RDRAND)) {
>> +			static const char __initconst text[] =
>> +				"RDRAND may cease to work on this hardware upon resume from S3.\n"
>> +				"Please choose an explicit cpuid={no-}rdrand setting.\n";
>> +
>> +			setup_clear_cpu_cap(X86_FEATURE_RDRAND);
>> +			warning_add(text);
> 
> What do you think to clobbering RDRAND via the CPUMASK registers in this
> case?  We've got full control there, and it would stop PV userspace as well.

Why would such be needed? The host_policy -> pv_max_cpuid_policy
-> recalculate_cpuid_policy() propagation already causes the flag
to get zapped from guest policies once it got cleared here. And
it's the guest policy that controls what gets put in the masking
MSRs for PV guests, isn't it?

>> @@ -498,6 +504,28 @@ void identify_cpu(struct cpuinfo_x86 *c)
>>  	printk("\n");
>>  #endif
>>  
>> +	/*
>> +	 * If RDRAND is available, make an attempt to check that it actually
>> +	 * (still) works.
>> +	 */
> 
> Do you think it would be helpful to test in the opposite case as well. 
> If we come back from S3 and find that RDRAND does actually work, then it
> is safe to tell the user that they can re-enable.

I'd view this as a nice-to-have that isn't all that obvious how to
actually implement in a sufficiently clean way. For example, we
can't use arch_get_random() in that case. Therefore I'd prefer if
this extra courtesy could be left out of here for now, and - if
indeed deemed useful - be added later.

>> +	if (cpu_has(c, X86_FEATURE_RDRAND)) {
>> +		unsigned int prev = 0;
>> +
>> +		for (i = 0; i < 5; ++i)
>> +		{
>> +			unsigned int cur = arch_get_random();
>> +
>> +			if (prev && cur != prev)
>> +				break;
>> +			prev = cur;
>> +			cpu_relax();
> 
> Why the relax?  We're not polling hammering the memory bus waiting for
> an unknown period of time until something changes.
> 
> We simply need up to 5 random numbers as fast as the RNG can produce
> them (which is actually quite slow.  RDRAND has ~350 cycle latency minimum.)

Dropped; I put it there simply to give the hardware some breathing
room between adjacent requests.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:25:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTi2H-0002UH-9t; Wed, 29 Apr 2020 08:25:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fvgr=6N=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTi2F-0002UB-RJ
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:25:39 +0000
X-Inumbo-ID: 01264b7e-89f3-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 01264b7e-89f3-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 08:25:38 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 8CF7CAB3D;
 Wed, 29 Apr 2020 08:25:36 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2] tools/xenstore: don't store domU's mfn of ring page in
 xenstored
Date: Wed, 29 Apr 2020 10:25:34 +0200
Message-Id: <20200429082534.4143-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
of the domain's xenstore ring page and the event channel of the
domain for communicating with Xenstore.

The gfn is not really needed. It is stored in the per-domain struct
in xenstored and in case of another XS_INTRODUCE for the domain it
is tested to match the original value. If it doesn't match the
command is aborted via EINVAL.

Today there aren't multiple XS_INTRODUCE requests for the same domain
issued, so the mfn/gfn can just be ignored and multiple XS_INTRODUCE
commands can be rejected without testing the mfn/gfn.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
V2:
- remove mfn from struct domain (Julien Grall)
- replace mfn by gfn in comments (Julien Grall)
---
 tools/xenstore/xenstored_domain.c | 53 +++++++++++++++------------------------
 1 file changed, 20 insertions(+), 33 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 5858185211..1ca11e5e9e 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -55,10 +55,6 @@ struct domain
 	   repeated domain introductions. */
 	evtchn_port_t remote_port;
 
-	/* The mfn associated with the event channel, used only to validate
-	   repeated domain introductions. */
-	unsigned long mfn;
-
 	/* Domain path in store. */
 	char *path;
 
@@ -363,13 +359,12 @@ static void domain_conn_reset(struct domain *domain)
 	domain->interface->rsp_cons = domain->interface->rsp_prod = 0;
 }
 
-/* domid, mfn, evtchn, path */
+/* domid, gfn, evtchn, path */
 int do_introduce(struct connection *conn, struct buffered_data *in)
 {
 	struct domain *domain;
 	char *vec[3];
 	unsigned int domid;
-	unsigned long mfn;
 	evtchn_port_t port;
 	int rc;
 	struct xenstore_domain_interface *interface;
@@ -381,7 +376,7 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
 		return EACCES;
 
 	domid = atoi(vec[0]);
-	mfn = atol(vec[1]);
+	/* Ignore the gfn, we don't need it. */
 	port = atoi(vec[2]);
 
 	/* Sanity check args. */
@@ -390,34 +385,26 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
 
 	domain = find_domain_by_domid(domid);
 
-	if (domain == NULL) {
-		interface = map_interface(domid);
-		if (!interface)
-			return errno;
-		/* Hang domain off "in" until we're finished. */
-		domain = new_domain(in, domid, port);
-		if (!domain) {
-			rc = errno;
-			unmap_interface(interface);
-			return rc;
-		}
-		domain->interface = interface;
-		domain->mfn = mfn;
-
-		/* Now domain belongs to its connection. */
-		talloc_steal(domain->conn, domain);
-
-		fire_watches(NULL, in, "@introduceDomain", false);
-	} else if ((domain->mfn == mfn) && (domain->conn != conn)) {
-		/* Use XS_INTRODUCE for recreating the xenbus event-channel. */
-		if (domain->port)
-			xenevtchn_unbind(xce_handle, domain->port);
-		rc = xenevtchn_bind_interdomain(xce_handle, domid, port);
-		domain->port = (rc == -1) ? 0 : rc;
-		domain->remote_port = port;
-	} else
+	if (domain)
 		return EINVAL;
 
+	interface = map_interface(domid);
+	if (!interface)
+		return errno;
+	/* Hang domain off "in" until we're finished. */
+	domain = new_domain(in, domid, port);
+	if (!domain) {
+		rc = errno;
+		unmap_interface(interface);
+		return rc;
+	}
+	domain->interface = interface;
+
+	/* Now domain belongs to its connection. */
+	talloc_steal(domain->conn, domain);
+
+	fire_watches(NULL, in, "@introduceDomain", false);
+
 	domain_conn_reset(domain);
 
 	send_ack(conn, XS_INTRODUCE);
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:26:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:26:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTi33-0002Z0-Ns; Wed, 29 Apr 2020 08:26:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LUw1=6N=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jTi31-0002Yo-Sr
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:26:27 +0000
X-Inumbo-ID: 1cc10112-89f3-11ea-991b-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1cc10112-89f3-11ea-991b-12813bfff9fa;
 Wed, 29 Apr 2020 08:26:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588148784;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=bpJFR9uAOQ0x077VV4diKS8R0/Zg4CNCJAVOa/uFOzM=;
 b=aLLFp9UaajnAOq1hNrEIwIp9+Bps04bEWEQw3UyRCZQVws+D3/aC8axl
 pawvPNr7fvSmXLY3N0w8FWZJ6GQuNPylG19i7/9Uvptu94Te+tUg6P5R2
 ufLJOhlQd18Q2+5uy4uZFu1y6qCTtZZGQ9Ly/cJJyR6Odr5HnAVWfDreT Y=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: rIaHzzxQD/ESbr87uXYRZPe2i4L18R/d/Jr5rvSs4APZ68kPopx2tHdyTSMDR205+bd1tCj8t1
 ZYV2Y6CooYCjoJoqQWQ3+1kMd2+y3tApBDba+g87BWYFnaUgTxFTAEB++tf/lb1x/w2vx0ZBUQ
 p8GR7GT/+qVuMmUPe596jmCYQXJlSUTAvbtw14aVzMiZlW0fJE2ynl+GouwHb3BQowWlkA5ELp
 9Sg4lIuBeFfAm6EwHKiibQePwRygSv1FpjMQGSoGxAFktBNOw47glIeQNBS60iJU+GDA/EDlMu
 rvg=
X-SBRS: 2.7
X-MesageID: 16822264
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,330,1583211600"; d="scan'208";a="16822264"
Date: Wed, 29 Apr 2020 10:26:16 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86/pass-through: avoid double IRQ unbind during domain
 cleanup
Message-ID: <20200429082616.GX28601@Air-de-Roger>
References: <6fddc420-b582-cb2f-92ce-b3e067c420c4@suse.com>
 <20200428161412.GU28601@Air-de-Roger>
 <c0f222dc-2b7a-be54-29a1-75bcc5686dde@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c0f222dc-2b7a-be54-29a1-75bcc5686dde@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Varad Gautam <vrd@amazon.de>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 29, 2020 at 09:37:11AM +0200, Jan Beulich wrote:
> On 28.04.2020 18:14, Roger Pau Monné wrote:
> > On Tue, Apr 28, 2020 at 02:21:48PM +0200, Jan Beulich wrote:
> >> XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTs.
> >> In that scenario, it is possible to receive multiple _pirq_guest_unbind
> >> calls for the same pirq from domain_kill, if the pirq has not yet been
> >> removed from the domain's pirq_tree, as:
> >>   domain_kill()
> >>     -> domain_relinquish_resources()
> >>       -> pci_release_devices()
> >>         -> pci_clean_dpci_irq()
> >>           -> pirq_guest_unbind()
> >>             -> __pirq_guest_unbind()
> >>
> >> Avoid recurring invocations of pirq_guest_unbind() by removing the pIRQ
> >> from the tree being iterated after the first call there. In case such a
> >> removed entry still has a softirq outstanding, record it and re-check
> >> upon re-invocation.
> >>
> >> Reported-by: Varad Gautam <vrd@amazon.de>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> Tested-by: Varad Gautam <vrd@amazon.de>
> >>
> >> --- a/xen/arch/x86/irq.c
> >> +++ b/xen/arch/x86/irq.c
> >> @@ -1323,7 +1323,7 @@ void (pirq_cleanup_check)(struct pirq *p
> >>      }
> >>  
> >>      if ( radix_tree_delete(&d->pirq_tree, pirq->pirq) != pirq )
> >> -        BUG();
> >> +        BUG_ON(!d->is_dying);
> > 
> > I think to keep the previous behavior this should be:
> > 
> > BUG_ON(!is_hvm_domain(d) || !d->is_dying);
> > 
> > Since the pirqs will only be removed elsewhere if the domain is HVM?
> 
> pirq_cleanup_check() is a generic hook, and hence I consider it more
> correct to not have it behave differently in this regard for different
> types of guests. IOW while it _may_ (didn't check) not be the case
> today that this can be called multiple times even for PV guests, I'd
> view this as legitimate behavior.

Previous to this patch pirq_cleanup_check couldn't be called multiple
times, as it would result in the BUG triggering, that was true for
both PV and HVM. Now that the removal of PIRQs from the tree is done
elsewhere for HVM when the domain is dying the check needs to be
relaxed for HVM at least. I would prefer if it was kept as-is for PV
(since there's been no change in behavior for PV that could allow for
multiple calls to pirq_cleanup_check), or else a small comment in the
commit message would help clarify this is done on purpose.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:34:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:34:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTiAL-0003ZD-Hk; Wed, 29 Apr 2020 08:34:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTiAJ-0003Z7-Sa
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:33:59 +0000
X-Inumbo-ID: 281258b2-89f4-11ea-991b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 281258b2-89f4-11ea-991b-12813bfff9fa;
 Wed, 29 Apr 2020 08:33:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=PXaz4WsdYC1NZr0B5MfR11X2HSxyd4AtDUNA4U4i3W4=; b=sdVMf6m3Kmq0gOvsDID3jMh5S
 6Gr+asG0OR8D596svaXLoHihGNCnP1AmrGEMPjsLdBA5sqYVHcg9W8MituKl4mKPhthcO0Bkgi6+p
 icB9uMokEcP3cLq/AHi92l8A2jWaMB/Lw+kbfCjM4k9duiukdm8ntlVHu+jhyOERp/Kho=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTiAC-0004gC-EH; Wed, 29 Apr 2020 08:33:52 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTiAB-0003PI-To; Wed, 29 Apr 2020 08:33:52 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTiAB-00034P-T9; Wed, 29 Apr 2020 08:33:51 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149869-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149869: all pass - PUSHED
X-Osstest-Versions-This: ovmf=b2034179e8feed9c7d3bc8f9d40a18fd236c5b57
X-Osstest-Versions-That: ovmf=099dfbb29d8bf0a30e397e3f5baf1da437b8f0ba
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 08:33:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149869 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149869/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 b2034179e8feed9c7d3bc8f9d40a18fd236c5b57
baseline version:
 ovmf                 099dfbb29d8bf0a30e397e3f5baf1da437b8f0ba

Last test of basis   149867  2020-04-28 18:09:26 Z    0 days
Testing same since   149869  2020-04-29 03:52:49 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Abner Chang <abner.chang@hpe.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Laszlo Ersek <lersek@redhat.com>
  Michael Kubacki <michael.kubacki@microsoft.com>
  Sean Brogan <sean.brogan@microsoft.com>
  Shenglei Zhang <shenglei.zhang@intel.com>
  Zhang, Shenglei <shenglei.zhang@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   099dfbb29d..b2034179e8  b2034179e8feed9c7d3bc8f9d40a18fd236c5b57 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:35:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTiBp-0003fI-Tx; Wed, 29 Apr 2020 08:35:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTiBp-0003fC-8u
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:35:33 +0000
X-Inumbo-ID: 637db996-89f4-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 637db996-89f4-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 08:35:32 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id BD6F6AB3D;
 Wed, 29 Apr 2020 08:35:30 +0000 (UTC)
Subject: Re: [PATCH] x86/pass-through: avoid double IRQ unbind during domain
 cleanup
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <6fddc420-b582-cb2f-92ce-b3e067c420c4@suse.com>
 <20200428161412.GU28601@Air-de-Roger>
 <c0f222dc-2b7a-be54-29a1-75bcc5686dde@suse.com>
 <20200429082616.GX28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <33a52f15-caff-a0f8-8387-b0c552c80c26@suse.com>
Date: Wed, 29 Apr 2020 10:35:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200429082616.GX28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Varad Gautam <vrd@amazon.de>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 10:26, Roger Pau Monné wrote:
> On Wed, Apr 29, 2020 at 09:37:11AM +0200, Jan Beulich wrote:
>> On 28.04.2020 18:14, Roger Pau Monné wrote:
>>> On Tue, Apr 28, 2020 at 02:21:48PM +0200, Jan Beulich wrote:
>>>> XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTs.
>>>> In that scenario, it is possible to receive multiple _pirq_guest_unbind
>>>> calls for the same pirq from domain_kill, if the pirq has not yet been
>>>> removed from the domain's pirq_tree, as:
>>>>   domain_kill()
>>>>     -> domain_relinquish_resources()
>>>>       -> pci_release_devices()
>>>>         -> pci_clean_dpci_irq()
>>>>           -> pirq_guest_unbind()
>>>>             -> __pirq_guest_unbind()
>>>>
>>>> Avoid recurring invocations of pirq_guest_unbind() by removing the pIRQ
>>>> from the tree being iterated after the first call there. In case such a
>>>> removed entry still has a softirq outstanding, record it and re-check
>>>> upon re-invocation.
>>>>
>>>> Reported-by: Varad Gautam <vrd@amazon.de>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> Tested-by: Varad Gautam <vrd@amazon.de>
>>>>
>>>> --- a/xen/arch/x86/irq.c
>>>> +++ b/xen/arch/x86/irq.c
>>>> @@ -1323,7 +1323,7 @@ void (pirq_cleanup_check)(struct pirq *p
>>>>      }
>>>>  
>>>>      if ( radix_tree_delete(&d->pirq_tree, pirq->pirq) != pirq )
>>>> -        BUG();
>>>> +        BUG_ON(!d->is_dying);
>>>
>>> I think to keep the previous behavior this should be:
>>>
>>> BUG_ON(!is_hvm_domain(d) || !d->is_dying);
>>>
>>> Since the pirqs will only be removed elsewhere if the domain is HVM?
>>
>> pirq_cleanup_check() is a generic hook, and hence I consider it more
>> correct to not have it behave differently in this regard for different
>> types of guests. IOW while it _may_ (didn't check) not be the case
>> today that this can be called multiple times even for PV guests, I'd
>> view this as legitimate behavior.
> 
> Previous to this patch pirq_cleanup_check couldn't be called multiple
> times, as it would result in the BUG triggering, that was true for
> both PV and HVM. Now that the removal of PIRQs from the tree is done
> elsewhere for HVM when the domain is dying the check needs to be
> relaxed for HVM at least. I would prefer if it was kept as-is for PV
> (since there's been no change in behavior for PV that could allow for
> multiple calls to pirq_cleanup_check), or else a small comment in the
> commit message would help clarify this is done on purpose.

I've added

"Note that pirq_cleanup_check() gets relaxed beyond what's strictly
 needed here, to avoid introducing an asymmetry there between HVM and PV
 guests."

Does this sound suitable to you?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 08:46:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 08:46:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTiLu-0004gJ-Uw; Wed, 29 Apr 2020 08:45:58 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LUw1=6N=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jTiLt-0004gE-D9
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 08:45:57 +0000
X-Inumbo-ID: d71ca528-89f5-11ea-ae69-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d71ca528-89f5-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 08:45:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588149956;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=jgMcp44px7m9bZzpUfQGPceiMmhwv2HG4wgwug6MFF0=;
 b=TCtDRtCE1qeJjt8Y4CbCgJIhwnH7tqtOv4Mz98QUkzLrd2WOPAmgU725
 fZgT518XcIlW3JmEInowFZiaBWNKcoJOqENFRuV6vfiVsy6kTiLxmVf+i
 UGeno0PmnwNDiY+L/EChjQOvVLDFsskt9rlW3KFXgMqGIHfv2fXCLr8LF 0=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: gCvkSgTjJo84ZDeUYMdzC2v7xf6cFSyPl9n/WY80HAIABPRR5svIdwUHLmNBHSsrRkICrHjhOO
 lfa+CPeOo7uud4xhLzuHdN+YE2fc+gYFsDFhzpOlgcWXeB5X0WQHXsaaDLr2sDHjaQRxL0P6wS
 dhkJ4S675qet+j3BUcLWEYmFz7c7nRUFWAb/FjCOLqyfNKh1ee0iis3h6Nez1L+BDXU12vnk/w
 /7hYeZaRwwrWEJDMMCgfHbr9Och5AXUDDVaz2P+u4wQ/DMu6Xej6ofa0PlB4FTlMGEatgIyzaw
 NaM=
X-SBRS: 2.7
X-MesageID: 16407752
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,330,1583211600"; d="scan'208";a="16407752"
Date: Wed, 29 Apr 2020 10:45:48 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86/pass-through: avoid double IRQ unbind during domain
 cleanup
Message-ID: <20200429084548.GY28601@Air-de-Roger>
References: <6fddc420-b582-cb2f-92ce-b3e067c420c4@suse.com>
 <20200428161412.GU28601@Air-de-Roger>
 <c0f222dc-2b7a-be54-29a1-75bcc5686dde@suse.com>
 <20200429082616.GX28601@Air-de-Roger>
 <33a52f15-caff-a0f8-8387-b0c552c80c26@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <33a52f15-caff-a0f8-8387-b0c552c80c26@suse.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Varad Gautam <vrd@amazon.de>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 29, 2020 at 10:35:24AM +0200, Jan Beulich wrote:
> On 29.04.2020 10:26, Roger Pau Monné wrote:
> > On Wed, Apr 29, 2020 at 09:37:11AM +0200, Jan Beulich wrote:
> >> On 28.04.2020 18:14, Roger Pau Monné wrote:
> >>> On Tue, Apr 28, 2020 at 02:21:48PM +0200, Jan Beulich wrote:
> >>>> XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTs.
> >>>> In that scenario, it is possible to receive multiple _pirq_guest_unbind
> >>>> calls for the same pirq from domain_kill, if the pirq has not yet been
> >>>> removed from the domain's pirq_tree, as:
> >>>>   domain_kill()
> >>>>     -> domain_relinquish_resources()
> >>>>       -> pci_release_devices()
> >>>>         -> pci_clean_dpci_irq()
> >>>>           -> pirq_guest_unbind()
> >>>>             -> __pirq_guest_unbind()
> >>>>
> >>>> Avoid recurring invocations of pirq_guest_unbind() by removing the pIRQ
> >>>> from the tree being iterated after the first call there. In case such a
> >>>> removed entry still has a softirq outstanding, record it and re-check
> >>>> upon re-invocation.
> >>>>
> >>>> Reported-by: Varad Gautam <vrd@amazon.de>
> >>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>> Tested-by: Varad Gautam <vrd@amazon.de>
> >>>>
> >>>> --- a/xen/arch/x86/irq.c
> >>>> +++ b/xen/arch/x86/irq.c
> >>>> @@ -1323,7 +1323,7 @@ void (pirq_cleanup_check)(struct pirq *p
> >>>>      }
> >>>>  
> >>>>      if ( radix_tree_delete(&d->pirq_tree, pirq->pirq) != pirq )
> >>>> -        BUG();
> >>>> +        BUG_ON(!d->is_dying);
> >>>
> >>> I think to keep the previous behavior this should be:
> >>>
> >>> BUG_ON(!is_hvm_domain(d) || !d->is_dying);
> >>>
> >>> Since the pirqs will only be removed elsewhere if the domain is HVM?
> >>
> >> pirq_cleanup_check() is a generic hook, and hence I consider it more
> >> correct to not have it behave differently in this regard for different
> >> types of guests. IOW while it _may_ (didn't check) not be the case
> >> today that this can be called multiple times even for PV guests, I'd
> >> view this as legitimate behavior.
> > 
> > Previous to this patch pirq_cleanup_check couldn't be called multiple
> > times, as it would result in the BUG triggering, that was true for
> > both PV and HVM. Now that the removal of PIRQs from the tree is done
> > elsewhere for HVM when the domain is dying the check needs to be
> > relaxed for HVM at least. I would prefer if it was kept as-is for PV
> > (since there's been no change in behavior for PV that could allow for
> > multiple calls to pirq_cleanup_check), or else a small comment in the
> > commit message would help clarify this is done on purpose.
> 
> I've added
> 
> "Note that pirq_cleanup_check() gets relaxed beyond what's strictly
>  needed here, to avoid introducing an asymmetry there between HVM and PV
>  guests."
> 
> Does this sound suitable to you?

Yes, thanks. With that:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Roger.


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 09:15:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 09:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTioe-0007VB-AD; Wed, 29 Apr 2020 09:15:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WYUl=6N=citrix.com=sergey.dyasli@srs-us1.protection.inumbo.net>)
 id 1jTiod-0007V6-8B
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 09:15:39 +0000
X-Inumbo-ID: fcb3b4da-89f9-11ea-b9cf-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fcb3b4da-89f9-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 09:15:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588151737;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 bh=9XuqZjXLEDLA7Jw3hoiSW1FuO4sc8HAIQkKF8epLdEI=;
 b=fL3ZhL0nrf6D8mpir0t3zWoA6vH00eALCSKZYLSMyRfBLkch+6HLv5Hy
 tsK+2kjqusMrPmKkHXAv9Hmu7EfmBk1ad/kFhxvCZuV3FqYgqy4f9iInI
 19ErnmLlHaqXIRsk2LhWRRKrGMKBKJyNHMEKzakgWIfqNxJDtPlHwfaT8 A=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=sergey.dyasli@citrix.com;
 spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 sergey.dyasli@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 sergey.dyasli@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="sergey.dyasli@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="sergey.dyasli@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 1ooR5Dv6leMjWF2Ggpi5ZAC8aL9Kfj5/egqHpjXwJw3dPbBh2UWYua8G8/MnB5lZX/oAVA5Vip
 wRgMhYRVcwXLcCiNbw+B0N4QKZ0xvoCH8nkdCOF+Irc0LcyULnzIS6n3d67v/53vU4O+IwRD9K
 IXec7U3xcjxeiicUNz4OcQSI/sdhXILLRu/isjT17zQXjSM+mrMbOpwQsIMBCbf9h9+S8meuet
 umwQBAdI5Hkt5BYMklRZs7X00Ll+QtM7xhFNuGwtKlJXLaivPrnPGYoOzOdmTXGhoFteEHb8s3
 FyI=
X-SBRS: 2.7
X-MesageID: 16678296
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,331,1583211600"; d="scan'208";a="16678296"
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
Subject: Re: Cpu on/offlining crash with core scheduling
Thread-Topic: Cpu on/offlining crash with core scheduling
Thread-Index: AQHWHJp8dUHIzvCapEuuomD+efJ+EaiPoGGAgAAihQA=
Date: Wed, 29 Apr 2020 09:15:33 +0000
Message-ID: <1588151726659.12791@citrix.com>
References: <1587995374653.73805@citrix.com>
 <103f3e30-a67e-77b7-9e92-572ee4b5d159@suse.com>
In-Reply-To: <103f3e30-a67e-77b7-9e92-572ee4b5d159@suse.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-imapappendstamp: AMSPEX02CL03.citrite.net (15.00.1497.006)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <804E099997A35842B8634514648679C6@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Sergey
 Dyasli <sergey.dyasli@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 09:09, J=FCrgen Gro=DF wrote:=0A=
> On 27.04.20 15:49, Sergey Dyasli wrote:=0A=
>> Hi Juergen,=0A=
>>=0A=
>> When I'm testing vcpu pinning with something like:=0A=
>>=0A=
>> =A0=A0=A0=A0=A0 # xl vcpu-pin 0 0 2=0A=
>> =A0=A0=A0=A0=A0 # xen-hptool cpu-offline 3=0A=
>>=0A=
>> =A0=A0=A0=A0=A0 (offline / online CPUs {2,3} if the above is successful)=
=0A=
>>=0A=
>> I'm reliably seeing the following crash on the latest staging:=0A=
>>=0A=
>> (XEN) Watchdog timer detects that CPU1 is stuck!=0A=
>> (XEN) ----[ Xen-4.14-unstable=A0 x86_64=A0 debug=3Dy=A0=A0 Not tainted ]=
----=0A=
>> (XEN) CPU:=A0=A0=A0 1=0A=
>> (XEN) RIP:=A0=A0=A0 e008:[<ffff82d08025266d>] common/sched/core.c#sched_=
wait_rendezvous_in+0x16c/0x385=0A=
>> (XEN) RFLAGS: 0000000000000002=A0=A0 CONTEXT: hypervisor=0A=
>> (XEN) rax: 000000000000f001=A0=A0 rbx: ffff82d0805c9118=A0=A0 rcx: ffff8=
3085e750301=0A=
>> (XEN) rdx: 0000000000000001=A0=A0 rsi: ffff83086499b972=A0=A0 rdi: ffff8=
3085e7503a6=0A=
>> (XEN) rbp: ffff83085e7dfe28=A0=A0 rsp: ffff83085e7dfdd8=A0=A0 r8:=A0 fff=
f830864985440=0A=
>> (XEN) r9:=A0 ffff83085e714068=A0=A0 r10: 0000000000000014=A0=A0 r11: 000=
00056b6a1aab2=0A=
>> (XEN) r12: ffff83086499e490=A0=A0 r13: ffff82d0805f26e0=A0=A0 r14: ffff8=
3085e7503a0=0A=
>> (XEN) r15: 0000000000000001=A0=A0 cr0: 0000000080050033=A0=A0 cr4: 00000=
00000362660=0A=
>> (XEN) cr3: 0000000823a8e000=A0=A0 cr2: 00006026000f6fc0=0A=
>> (XEN) fsb: 0000000000000000=A0=A0 gsb: ffff888138dc0000=A0=A0 gss: 00000=
00000000000=0A=
>> (XEN) ds: 002b=A0=A0 es: 002b=A0=A0 fs: 0000=A0=A0 gs: 0000=A0=A0 ss: e0=
10=A0=A0 cs: e008=0A=
>> (XEN) Xen code around <ffff82d08025266d> (common/sched/core.c#sched_wait=
_rendezvous_in+0x16c/0x385):=0A=
>> (XEN)=A0 4c 89 f7 e8 dc a5 fd ff <4b> 8b 44 fd 00 48 8b 04 18 4c 3b 70 1=
0 0f 85 3f=0A=
>> (XEN) Xen stack trace from rsp=3Dffff83085e7dfdd8:=0A=
>> (XEN)=A0=A0=A0 00000056b42128a6 ffff83086499ff30 ffff83086498a000 ffff83=
085e7dfe48=0A=
>> (XEN)=A0=A0=A0 0000000100000001 00000056b42128a6 ffff83086499e490 000000=
0000000000=0A=
>> (XEN)=A0=A0=A0 0000000000000001 0000000000000001 ffff83085e7dfe78 ffff82=
d080252ae8=0A=
>> (XEN)=A0=A0=A0 ffff83086498a000 0000000180230434 ffff83085e7503a0 ffff82=
d0805ceb00=0A=
>> (XEN)=A0=A0=A0 ffffffffffffffff ffff82d0805cea80 0000000000000000 ffff82=
d0805dea80=0A=
>> (XEN)=A0=A0=A0 ffff83085e7dfeb0 ffff82d08022c232 0000000000000001 ffff82=
d0805ceb00=0A=
>> (XEN)=A0=A0=A0 0000000000000001 0000000000000001 0000000000000001 ffff83=
085e7dfec0=0A=
>> (XEN)=A0=A0=A0 ffff82d08022c2cd ffff83085e7dfef0 ffff82d08031cae9 ffff83=
086498a000=0A=
>> (XEN)=A0=A0=A0 ffff83086498a000 0000000000000001 0000000000000001 ffff83=
085e7dfde8=0A=
>> (XEN)=A0=A0=A0 ffff88813021d700 ffff88813021d700 0000000000000000 000000=
0000000000=0A=
>> (XEN)=A0=A0=A0 0000000000000007 ffff88813021d700 0000000000000246 000000=
0000007ff0=0A=
>> (XEN)=A0=A0=A0 0000000000000000 000000000001ca00 0000000000000000 ffffff=
ff810013aa=0A=
>> (XEN)=A0=A0=A0 ffffffff8203d210 deadbeefdeadf00d deadbeefdeadf00d 000001=
0000000000=0A=
>> (XEN)=A0=A0=A0 ffffffff810013aa 000000000000e033 0000000000000246 ffffc9=
00400dfeb0=0A=
>> (XEN)=A0=A0=A0 000000000000e02b 0000000000000000 0000000000000000 000000=
0000000000=0A=
>> (XEN)=A0=A0=A0 0000000000000000 0000e01000000001 ffff83086498a000 000000=
37e43bd000=0A=
>> (XEN)=A0=A0=A0 0000000000362660 0000000000000000 8000000864980002 000006=
0100000000=0A=
>> (XEN)=A0=A0=A0 0000000000000000=0A=
>> (XEN) Xen call trace:=0A=
>> (XEN)=A0=A0=A0 [<ffff82d08025266d>] R common/sched/core.c#sched_wait_ren=
dezvous_in+0x16c/0x385=0A=
>> (XEN)=A0=A0=A0 [<ffff82d080252ae8>] F common/sched/core.c#sched_slave+0x=
262/0x31e=0A=
>> (XEN)=A0=A0=A0 [<ffff82d08022c232>] F common/softirq.c#__do_softirq+0x8a=
/0xbc=0A=
>> (XEN)=A0=A0=A0 [<ffff82d08022c2cd>] F do_softirq+0x13/0x15=0A=
>> (XEN)=A0=A0=A0 [<ffff82d08031cae9>] F arch/x86/domain.c#idle_loop+0x57/0=
xa7=0A=
>> (XEN)=0A=
>> (XEN) CPU0 @ e008:ffff82d08022c2b7 (process_pending_softirqs+0x53/0x56)=
=0A=
>> (XEN) CPU4 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callba=
cks+0x22e/0x24b)=0A=
>> (XEN) CPU2 @ e008:ffff82d08022c26f (process_pending_softirqs+0xb/0x56)=
=0A=
>> (XEN) CPU7 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callba=
cks+0x22e/0x24b)=0A=
>> (XEN) CPU3 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callba=
cks+0x22e/0x24b)=0A=
>> (XEN) CPU5 @ e008:ffff82d08022cc34 (_spin_lock+0x4d/0x62)=0A=
>> (XEN) CPU6 @ e008:ffff82d08022c264 (process_pending_softirqs+0/0x56)=0A=
>> (XEN)=0A=
>> (XEN) ****************************************=0A=
>> (XEN) Panic on CPU 1:=0A=
>> (XEN) FATAL TRAP: vector =3D 2 (nmi)=0A=
>> (XEN) [error_code=3D0000] , IN INTERRUPT CONTEXT=0A=
>> (XEN) ****************************************=0A=
>> (XEN)=0A=
>> (XEN) Reboot in five seconds...=0A=
>> (XEN) Executing kexec image on cpu1=0A=
>> (XEN) Shot down all CPUs=0A=
>>=0A=
>>=0A=
>> Is this something you can reproduce?=0A=
> =0A=
> Yes, I was able to hit this.=0A=
> =0A=
> Attached patch is fixing it for me. Could you give it a try?=0A=
=0A=
The patch fixes the immediate issue:=0A=
=0A=
	Tested-by: Sergey Dyasli <sergey.dyasli@citrix.com>=0A=
	=0A=
Thanks!=0A=
=0A=
However, when running the following script:=0A=
=0A=
	while :; do xen-hptool cpu-offline 3; xen-hptool cpu-offline 2; xen-hptool=
 cpu-online 3; xen-hptool cpu-online 2; sleep 0.1; done=0A=
	=0A=
there was some weirdness with the utility on some invocations:=0A=
=0A=
	xen-hptool: symbol lookup error: /lib64/libxenctrl.so.4.14: undefined symb=
ol: xc__hypercall_buffer_free=0A=
	Segmentation fault (core dumped)=0A=
	xen-hptool: symbol lookup error: /lib64/libxenctrl.so.4.14: undefined symb=
ol: xc__hypercall_bounce_post=0A=
	xen-hptool: relocation error: /lib64/libxenctrl.so.4.14: symbol xencall_fr=
ee_buffer, version VERS_1.0 not defined in file libxencall.so.1 with link t=
ime reference=0A=
	=0A=
And after a while it all ended up in:=0A=
=0A=
[  634.817181] BUG: unable to handle kernel NULL pointer dereference at 000=
0000000000060=0A=
[  634.817197] PGD 67866067 P4D 67866067 PUD 4cb6067 PMD 0=0A=
[  634.817208] Oops: 0000 [#1] SMP NOPTI=0A=
[  634.817215] CPU: 6 PID: 17284 Comm: xen-hptool Tainted: G           O   =
   4.19.0+1 #1=0A=
[  634.817224] Hardware name: Supermicro MBI-6119G-T4/B2SS1-F, BIOS 2.0a 06=
/10/2017=0A=
[  634.817237] RIP: e030:wq_worker_waking_up+0xd/0x30=0A=
[  634.817301] Code: 59 fb ff ff b8 01 00 00 00 48 83 c4 08 c3 0f 1f 44 00 =
00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 89 f3 e8 53 51 00 00 <f7=
> 40 60 c8 =0A=
01 00 00 75 10 48 8b 40 40 39 58 04 75 09 f0 ff 80 00=0A=
[  634.817322] RSP: e02b:ffffc90044117c58 EFLAGS: 00010002=0A=
[  634.817329] RAX: 0000000000000000 RBX: 0000000000000004 RCX: ffff888138d=
21700=0A=
[  634.817338] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffff88812a8=
dba00=0A=
[  634.817347] RBP: ffff888138d21700 R08: ffff88812a8dba80 R09: 00000000000=
00000=0A=
[  634.817357] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000=
00000=0A=
[  634.817366] R13: ffffc90044117c98 R14: 0000000000000000 R15: 00000000000=
00004=0A=
[  634.817386] FS:  00007f175d011740(0000) GS:ffff888138d80000(0000) knlGS:=
0000000000000000=0A=
[  634.817394] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033=0A=
[  634.817399] CR2: 0000000000000060 CR3: 0000000067974000 CR4: 00000000000=
40660=0A=
[  634.817410] Call Trace:=0A=
[  634.817417]  ttwu_do_activate+0x5f/0x80=0A=
[  634.817422]  try_to_wake_up+0x1e1/0x450=0A=
[  634.817427]  __queue_work+0x116/0x360=0A=
[  634.817432]  queue_work_on+0x24/0x40=0A=
[  634.817438]  pty_write+0x8f/0xa0=0A=
[  634.817443]  n_tty_write+0x1c5/0x480=0A=
[  634.817448]  ? do_wait_intr_irq+0xa0/0xa0=0A=
[  634.817452]  tty_write+0x154/0x2c0=0A=
[  634.817457]  ? process_echoes+0x70/0x70=0A=
[  634.817462]  __vfs_write+0x36/0x1a0=0A=
[  634.817468]  ? do_vfs_ioctl+0xa9/0x630=0A=
[  634.817472]  vfs_write+0xad/0x1a0=0A=
[  634.817477]  ksys_write+0x52/0xc0=0A=
[  634.817482]  do_syscall_64+0x4e/0x100=0A=
[  634.817488]  entry_SYSCALL_64_after_hwframe+0x44/0xa9=0A=
[  634.817494] RIP: 0033:0x7f175c0b9cd0=0A=
[  634.817499] Code: 73 01 c3 48 8b 0d c0 61 2d 00 f7 d8 64 89 01 48 83 c8 =
ff c3 66 0f 1f 44 00 00 83 3d cd c2 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48=
> 3d 01 f0 =0A=
ff ff 73 31 c3 48 83 ec 08 e8 ee cb 01 00 48 89 04 24=0A=
[  634.817514] RSP: 002b:00007ffc6651bfd8 EFLAGS: 00000246 ORIG_RAX: 000000=
0000000001=0A=
[  634.817521] RAX: ffffffffffffffda RBX: 000000000000001b RCX: 00007f175c0=
b9cd0=0A=
[  634.817528] RDX: 000000000000001b RSI: 00007f175d021000 RDI: 00000000000=
00001=0A=
[  634.817535] RBP: 00007f175d021000 R08: 0a796c6c75667373 R09: 00007f175c0=
1716d=0A=
[  634.817542] R10: 00007ffc6651c0a0 R11: 0000000000000246 R12: 00007f175c3=
91400=0A=
[  634.817548] R13: 000000000000001b R14: 0000000000000d70 R15: 00007f175c3=
8c858=0A=
[  634.817556] Modules linked in: nfsv3 nfs_acl nfs lockd grace fscache bnx=
2fc(O) cnic(O) uio fcoe libfcoe libfc scsi_transport_fc openvswitch nsh nf_=
nat_ipv6 =0A=
nf_nat_ipv4 nf_conncount nf_nat 8021q garp mrp stp llc ipt_REJECT nf_reject=
_ipv4 xt_tcpudp xt_multiport xt_conntrack nf_conntrack nf_defrag_ipv6 nf_de=
frag_ipv4 =0A=
libcrc32c iptable_filter dm_multipath sunrpc dm_mod intel_powerclamp crct10=
dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 cry=
pto_simd =0A=
ipmi_si cryptd glue_helper ipmi_devintf ipmi_msghandler mei_me mei intel_ra=
pl_perf sg intel_pch_thermal ie31200_edac i2c_i801 video backlight acpi_pow=
er_meter =0A=
xen_wdt ip_tables x_tables hid_generic usbhid hid sd_mod ahci libahci xhci_=
pci libata xhci_hcd intel_ish_ipc igb(O) intel_ishtp scsi_dh_rdac scsi_dh_h=
p_sw =0A=
scsi_dh_emc scsi_dh_alua=0A=
[  634.817636]  scsi_mod ipv6 crc_ccitt=0A=
[  634.817642] CR2: 0000000000000060=0A=
[  634.817647] ---[ end trace b370af17485413d2 ]---=0A=
[  634.872560] RIP: e030:wq_worker_waking_up+0xd/0x30=0A=
[  634.872566] Code: 59 fb ff ff b8 01 00 00 00 48 83 c4 08 c3 0f 1f 44 00 =
00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 89 f3 e8 53 51 00 00 <f7=
> 40 60 c8 =0A=
01 00 00 75 10 48 8b 40 40 39 58 04 75 09 f0 ff 80 00=0A=
[  634.872582] RSP: e02b:ffffc90044117c58 EFLAGS: 00010002=0A=
[  634.872587] RAX: 0000000000000000 RBX: 0000000000000004 RCX: ffff888138d=
21700=0A=
[  634.872594] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffff88812a8=
dba00=0A=
[  634.872601] RBP: ffff888138d21700 R08: ffff88812a8dba80 R09: 00000000000=
00000=0A=
[  634.872608] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000=
00000=0A=
[  634.872614] R13: ffffc90044117c98 R14: 0000000000000000 R15: 00000000000=
00004=0A=
[  634.872627] FS:  00007f175d011740(0000) GS:ffff888138d80000(0000) knlGS:=
0000000000000000=0A=
[  634.872634] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033=0A=
[  634.872640] CR2: 0000000000000060 CR3: 0000000067974000 CR4: 00000000000=
40660=0A=
=0A=
--=0A=
Thanks,=0A=
Sergey=0A=
=0A=


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 09:22:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 09:22:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTiuv-00007a-HO; Wed, 29 Apr 2020 09:22:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTiuu-00007T-FG
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 09:22:08 +0000
X-Inumbo-ID: e59af8ac-89fa-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e59af8ac-89fa-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 09:22:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=IBvFVP9Y/af3Zy8vF1YUEhbF2HZkcqpnP3dwYHZKchE=; b=S1/cXFGtpTSdXGygCTxAMyksE8
 i47m/LH3YPCH58pEGobUArtB2pGPfMv1+dxz6vlkG+QZJkTlTs6xdy1b819yXi3qBFYAnPKAxulBK
 nd2YS+2SqewTShQgmuYkUPfzrQphOw2eh/AkqZ/3YvoTgulZxAw7SN6t1VZuX9yUz7RU=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTiuq-0005a6-Km; Wed, 29 Apr 2020 09:22:04 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTiuq-0008AH-Dl; Wed, 29 Apr 2020 09:22:04 +0000
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 Julien Grall <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
Date: Wed, 29 Apr 2020 10:22:02 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 Igor Druzhinin <igor.druzhinin@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Juergen,

On 29/04/2020 06:51, Jürgen Groß wrote:
> On 28.04.20 22:55, Julien Grall wrote:
>> Hi Juergen,
>>
>> On Tue, 28 Apr 2020 at 16:53, Juergen Gross <jgross@suse.com> wrote:
>>>
>>> The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
>>> of the domain's xenstore ring page and the event channel of the
>>> domain for communicating with Xenstore.
>>>
>>> The gfn is not really needed. It is stored in the per-domain struct
>>> in xenstored and in case of another XS_INTRODUCE for the domain it
>>> is tested to match the original value. If it doesn't match the
>>> command is aborted via EINVAL.
>>>
>>> Today there shouldn't be multiple XS_INTRODUCE requests for the same
>>> domain issued, so the mfn/gfn can just be ignored and multiple
>>> XS_INTRODUCE commands can be rejected without testing the mfn/gfn.
>>
>> So there is a comment in the else part:
>>
>> /* Use XS_INTRODUCE for recreating the xenbus event-channel. */
>>
>>  From the commit message this is not entirely clear why we want to
>> prevent recreating the event-channel. Can you expand it?
> 
> Recreating the event channel would be fine, but I don't see why it
> would ever be needed. And XS_INTRODUCE is called only at domain creation
> time today, so there is obviously no need for repeating this call.
> 
> Maybe the idea was to do this after sending a XS_RESUME command, which
> isn't used anywhere in Xen and is another part of Xenstore which doesn't
> make any sense today.

Commit f6cc37ea8ac71385b60507c034519f304da75f4c "tools/oxenstored: port 
XS_INTRODUCE evtchn rebind function from cxenstored" added the exact 
same behavior in the OCaml XenStored last year.

This was introduced 12 years after C XenStored, so surely someone think 
this is useful. We should check why this was introduced in OCaml 
XenStored (I have CCed the author of the patch).

If we still think this is not useful, then you should add an explanation 
in the commit message why the two implementations diverge and possibly 
update the spec.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 09:26:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 09:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTiz3-0000KN-1w; Wed, 29 Apr 2020 09:26:25 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QE4t=6N=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jTiz1-0000KG-J1
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 09:26:23 +0000
X-Inumbo-ID: 7dec2310-89fb-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 7dec2310-89fb-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 09:26:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=YgStSeu4NexQHRS0NB9VnK+4/BDFKBvIfbBLjZnjZjs=; b=vtlJZKEfCrBI8ebJ29AZhXZUmJ
 tnAFPt8yY4llVvkSop9gYTsrlGHMrdKUujJCTiZyE1HHVR76IjMpZ5zuXpLkKQb3vU7OFftn3bpeL
 OmfP2bQqaRkTL4WqQlbFhjRxiDHr8ZxLmC1MJw/geikG1uY4ilxs8ppdyydue8v6+7aw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jTiyz-0005eH-EN; Wed, 29 Apr 2020 09:26:21 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=s3-prod-r2d2-p7995.iad7.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jTiyz-0008Sx-2W; Wed, 29 Apr 2020 09:26:21 +0000
Message-ID: <e18871ea997a304394adbbc92e724ae0ec56d87a.camel@xen.org>
Subject: Re: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>
Date: Wed, 29 Apr 2020 10:26:19 +0100
In-Reply-To: <c33dcaee9c8796da8816de9168f91ce90de61fc5.camel@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
 <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
 <9df9c5163fde5d25ceb756b20714c58be93b2c6c.camel@xen.org>
 <c33dcaee9c8796da8816de9168f91ce90de61fc5.camel@xen.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, julien@xen.org,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Tue, 2020-04-28 at 16:59 +0100, Hongyan Xia wrote:
> On Tue, 2020-04-28 at 16:55 +0100, Hongyan Xia wrote:
> > On Tue, 2020-04-28 at 17:33 +0200, Jan Beulich wrote:
> > > On 17.04.2020 11:52, Hongyan Xia wrote:
> > > > --- a/xen/arch/x86/pv/dom0_build.c
> > > > +++ b/xen/arch/x86/pv/dom0_build.c
> > > > @@ -50,17 +50,17 @@ static __init void
> > > > mark_pv_pt_pages_rdonly(struct domain *d,
> > > >      unsigned long count;
> > > >      struct page_info *page;
> > > >      l4_pgentry_t *pl4e;
> > > > -    l3_pgentry_t *pl3e;
> > > > -    l2_pgentry_t *pl2e;
> > > > -    l1_pgentry_t *pl1e;
> > > > +    l3_pgentry_t *pl3e, *l3t;
> > > > +    l2_pgentry_t *pl2e, *l2t;
> > > > +    l1_pgentry_t *pl1e, *l1t;
> > > 
> > > I don't quite see why the new local variables get introduced:
> > > unmap_domain_page(), iirc, is quite fine with a non-page-
> > > aligned argument.
> > 
> > You are right, although in this function, where plXe points to may
> > not
> > be the page we want to unmap. When plXe becomes aligned and points
> > to
> > a
> > new page, we actually want to unmap the page before it increments
> > to
> > an
> > aligned value.
> 
> Hmm, we can just unmap(plXe - 1) if my logic is correct, and save 3
> local variables.

Sorry for monologuing, but I still prefer separating plXe and lXt
because it makes it clear what we are unmapping. Unmapping plXe - 1 is
a bit hackish.

But if people do not have a problem with plXe - 1, I will post a new
revision for that.

Hongyan



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 10:14:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 10:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTjjk-000585-UC; Wed, 29 Apr 2020 10:14:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTjjj-000580-35
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 10:14:39 +0000
X-Inumbo-ID: 388c1d8c-8a02-11ea-b07b-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 388c1d8c-8a02-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 10:14:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=oivrNt+PAN4AkBDVZ5G/D9Cv4y6xo/WADZZODDu/NBU=; b=y+qJx+TMmaNBfo8Z03ksDKKJQ
 Ks2jL5jNv3c50RqWe1hKGo5z8yBL7hmTahoy7G05UKgau+1nP/T4eiBb/E/CtYZ7xSuES56zH1x8d
 h2ByDvhwZ4He3pwcWqUdGZk1MM8vygyPf7zVqH/pK1CpjRTnXd3Wa9YsKybfRzjVRI5iM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTjjd-0006cP-05; Wed, 29 Apr 2020 10:14:33 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTjjc-0000hp-E3; Wed, 29 Apr 2020 10:14:32 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTjjc-0004XH-DQ; Wed, 29 Apr 2020 10:14:32 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149873-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-coverity test] 149873: all pass - PUSHED
X-Osstest-Versions-This: xen=4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6
X-Osstest-Versions-That: xen=f093b08c47b39da6019421a2b61d40745b3e573b
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 10:14:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149873 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149873/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen                  4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6
baseline version:
 xen                  f093b08c47b39da6019421a2b61d40745b3e573b

Last test of basis   149828  2020-04-26 09:18:45 Z    3 days
Testing same since   149873  2020-04-29 09:19:00 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  George Dunlap <george.dunlap@citrix.com>
  Hongyan Xia <hongyxia@amazon.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Julien Grall <jgrall@amazon.com>
  Nick Rosbrook <rosbrookn@ainfosec.com>
  Nick Rosbrook <rosbrookn@gmail.com>
  Stefano Stabellini <sstabellini@kernel.org>
  Wei Liu <wei.liu2@citrix.com>
  Wei Liu <wl@xen.org>

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
   f093b08c47..4ec07971f1  4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6 -> coverity-tested/smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 10:17:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 10:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTjm1-0005Ec-Bd; Wed, 29 Apr 2020 10:17:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTjm0-0005EW-2K
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 10:17:00 +0000
X-Inumbo-ID: 8f72f6b6-8a02-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8f72f6b6-8a02-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 10:16:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=HBPAi74v+CsWXhsSg1lNB9l8jf/ww8X2N9+hlG4Jr00=; b=BT1RN0XUwjyvUCpTqx9qlu5il
 uhbr4EMQEAZtPjUBycmf+sX7x+Z3bqN8cIVTtygoQox0Es4ookDZdSahOFCNscFXQlp1WXxfgG0oB
 1Vymotl+WmRmkn8JyFJlFzwWooM/FcfqB60caNZhUE9fMyYOuV/aSp2ZcPU8RWk2IWE1Y=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTjly-0006fa-Oq; Wed, 29 Apr 2020 10:16:58 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTjly-0000uI-Hb; Wed, 29 Apr 2020 10:16:58 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTjly-0004yT-H0; Wed, 29 Apr 2020 10:16:58 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149872-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149872: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=e9aca9470ed86966f9c0fd0db85132ff28d652c4
X-Osstest-Versions-That: xen=4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 10:16:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149872 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149872/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  e9aca9470ed86966f9c0fd0db85132ff28d652c4
baseline version:
 xen                  4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6

Last test of basis   149863  2020-04-28 16:01:08 Z    0 days
Testing same since   149872  2020-04-29 08:02:03 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Tim Deegan <tim@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4ec07971f1..e9aca9470e  e9aca9470ed86966f9c0fd0db85132ff28d652c4 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 10:39:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 10:39:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTk7e-0007Bl-9Y; Wed, 29 Apr 2020 10:39:22 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xGEm=6N=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jTk7c-0007Bg-K8
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 10:39:20 +0000
X-Inumbo-ID: ae657f6e-8a05-11ea-9927-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ae657f6e-8a05-11ea-9927-12813bfff9fa;
 Wed, 29 Apr 2020 10:39:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588156760;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=9IhIiKA1ZIM0ahmF7IoijqekFzA8jgUXqg5Ly1OOxGo=;
 b=a523cy1Bljz5i09D3HSFLN2iPaVHUlkzjZ4t5IYcRqvgJd9fyOKV4Mub
 oMHYhCvKtVo7IoxR0spk54VPIg2svkRI5ZZy2PonxwK6BoFK1PBz/0A79
 CsFGBcw7Uj1z6RO2+0nkMsBebJeK1omazkm/xBi7HIUmtKSdr67azQsNT A=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: UFJ7nNXNPLu2zemBh5egOYyELBvLAEUV3DXPgVhuP5NKATw35u9I8WzDiS+eRQeO94zf4MvsOv
 2vivAQKbH4vwllMpPbqrftC4dSxnsGr+bL201kvgh8MVU0F2LLXe/lwlbiOgT/SM81fJE+AqON
 Xdr69XT58sFzC5+hdQAsLf/X428us4iifNVhW1x00JVXEtVOmcSTBTVvLsXW5Lgfpo6vqKY48t
 0gcm59YHyYLZ5jBfH8KjbytwtVa8v3HyU+yPPVEgSGXhl56WCAWeB5jpkm4MQcQZ2/qaIhcUPP
 Ij0=
X-SBRS: 2.7
X-MesageID: 16681920
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,331,1583211600"; d="scan'208";a="16681920"
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: Julien Grall <julien@xen.org>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>, Julien Grall <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
Date: Wed, 29 Apr 2020 11:39:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 10:22, Julien Grall wrote:
> Hi Juergen,
> 
> On 29/04/2020 06:51, Jürgen Groß wrote:
>>
>> Recreating the event channel would be fine, but I don't see why it
>> would ever be needed. And XS_INTRODUCE is called only at domain creation
>> time today, so there is obviously no need for repeating this call.
>>
>> Maybe the idea was to do this after sending a XS_RESUME command, which
>> isn't used anywhere in Xen and is another part of Xenstore which doesn't
>> make any sense today.
> 
> Commit f6cc37ea8ac71385b60507c034519f304da75f4c "tools/oxenstored: port XS_INTRODUCE evtchn rebind function from cxenstored" added the exact same behavior in the OCaml XenStored last year.
> 
> This was introduced 12 years after C XenStored, so surely someone think this is useful. We should check why this was introduced in OCaml XenStored (I have CCed the author of the patch).
> 
> If we still think this is not useful, then you should add an explanation in the commit message why the two implementations diverge and possibly update the spec.

Thanks for CC, Julien.

We indeed already use this functionality in our toolstack for guest kdump
functions. It's not possible in XAPI to adopt libxl model where almost everything
is restarted for a domain entering kdump, so we have to use this message to
rebind xenstore evtchn after soft reset without shutting down backends and
recreating the whole subtree (frontends reconnect fine after that).

We obviously only require it for now to be present in oxenstored only.
Please don't remove this functionality if possible.

Igor 


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 10:41:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 10:41:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTkA1-000849-Oa; Wed, 29 Apr 2020 10:41:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=UoNI=6N=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jTkA0-000844-O5
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 10:41:48 +0000
X-Inumbo-ID: 06b917fc-8a06-11ea-ae69-bc764e2007e4
Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 06b917fc-8a06-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 10:41:48 +0000 (UTC)
Received: by mail-wm1-x343.google.com with SMTP id y24so1462622wma.4
 for <xen-devel@lists.xenproject.org>; Wed, 29 Apr 2020 03:41:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=DftQOi/0ZZ65kQGBjKhjDE6NVGdkGHPGvh7+6NEfCIE=;
 b=JB0u8o+ofud/6GLH1aBjwGbjh2F72l2MzXQLgSGL/S7l3W9R9rAy1fGRThc2w6R2r5
 PJ9CQfqM50uRhUY3iOAqZN+1nvaTJU8Hm0UFWQltCAZzQLpLKR2UeoSVDsJnf3dlSBh/
 zJNCbwM41L4S6L3OB4gcJyq01oDVJGQnaNsDec5TgR16Zj+5mfjih5FzpVSH9tYS1OqH
 oJixayzSK/reIVDYgKM7lCPcJb2pMml/DZvkqGfG67iTXuC/gkbRz76v2tk1ofTLGeP7
 TkWtTXRsnQsDEyFkJw1TRW0u3okUmeNYOw48YaB6BZUH0/M0WCwBTaX1qyn3F68UxsDv
 ZjnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:date:message-id
 :mime-version:content-transfer-encoding;
 bh=DftQOi/0ZZ65kQGBjKhjDE6NVGdkGHPGvh7+6NEfCIE=;
 b=cFq5lAgDyvCY/GWt1wdUncvSoHg/IYN65XmwFSiUNXyfgFjUIuR+LFpu26QZeNVthh
 VVgT9NAG1B5XFkE8xMayAeBCeZE/Fu9xmuRk4mIu3CWcfUBta34Z+Q4zq17Hqn3Ui7Jv
 90vRIqQgEXAcZPVpwNcZqvhV+orPQF58nQa+YlwUygiK+YoETH6ehZ14WmJDWBqZliDb
 7hFI6zMGj3GzPXKlI8lWhGBBELxliSR2EFKctmcAvpeEM8EyDCTt6SoE2Va/Y6gC4T7K
 Nm+z4UpklUIO8ZMzUNdQpC0xEMJ8Kw9h8F90Z/p488q+6aK+o0zSAgTOB2HCkxJq4mgB
 m9pA==
X-Gm-Message-State: AGi0PubUNICGv81LTheFsdD97JyRD/YJz/lTlwnzQvxuotEjv8EO6SE9
 e/+d+HbJViHFOnCgl8xi6AEoSxOtv8s=
X-Google-Smtp-Source: APiQypIJ5yNPYFk1U3Xqscn/+94PcbzPa7A42oLwYxfRYauXgdOAK26PwiTzw/sDX9Y1yTxs1j+mCg==
X-Received: by 2002:a1c:4304:: with SMTP id q4mr2738653wma.152.1588156907008; 
 Wed, 29 Apr 2020 03:41:47 -0700 (PDT)
Received: from localhost.localdomain (44.142.6.51.dyn.plus.net. [51.6.142.44])
 by smtp.gmail.com with ESMTPSA id
 n2sm30270332wrq.74.2020.04.29.03.41.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 29 Apr 2020 03:41:46 -0700 (PDT)
From: Wei Liu <wl@xen.org>
X-Google-Original-From: Wei Liu <liuwe@microsoft.com>
To: Xen Development List <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/hyperv: stash and use the configured max VP index
Date: Wed, 29 Apr 2020 11:41:44 +0100
Message-Id: <20200429104144.17816-1-liuwe@microsoft.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <liuwe@microsoft.com>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michael Kelley <mikelley@microsoft.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The value returned from CPUID is the maximum number for virtual
processors supported by Hyper-V. It could be larger than the maximum
number of virtual processors configured.

Stash the configured number into a variable and use it in calculations.

Signed-off-by: Wei Liu <liuwe@microsoft.com>
---
 xen/arch/x86/guest/hyperv/hyperv.c  | 4 ++++
 xen/arch/x86/guest/hyperv/private.h | 1 +
 xen/arch/x86/guest/hyperv/tlb.c     | 2 +-
 xen/arch/x86/guest/hyperv/util.c    | 2 +-
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c
index 91a6782cd986..84221b751453 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -33,6 +33,7 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
 DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
 DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
 
+unsigned int __read_mostly hv_max_vp_index;
 static bool __read_mostly hcall_page_ready;
 
 static uint64_t generate_guest_id(void)
@@ -143,6 +144,9 @@ static int setup_hypercall_pcpu_arg(void)
     rdmsrl(HV_X64_MSR_VP_INDEX, vp_index_msr);
     this_cpu(hv_vp_index) = vp_index_msr;
 
+    if ( vp_index_msr > hv_max_vp_index )
+        hv_max_vp_index = vp_index_msr;
+
     return 0;
 }
 
diff --git a/xen/arch/x86/guest/hyperv/private.h b/xen/arch/x86/guest/hyperv/private.h
index 354fc7f685a7..fea3e291e944 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -28,6 +28,7 @@
 DECLARE_PER_CPU(void *, hv_input_page);
 DECLARE_PER_CPU(void *, hv_vp_assist);
 DECLARE_PER_CPU(unsigned int, hv_vp_index);
+extern unsigned int hv_max_vp_index;
 
 static inline unsigned int hv_vp_index(unsigned int cpu)
 {
diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
index 1d723d6ee679..0a44071481bd 100644
--- a/xen/arch/x86/guest/hyperv/tlb.c
+++ b/xen/arch/x86/guest/hyperv/tlb.c
@@ -166,7 +166,7 @@ int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
         {
             unsigned int vpid = hv_vp_index(cpu);
 
-            if ( vpid >= ms_hyperv.max_vp_index )
+            if ( vpid >= hv_max_vp_index )
             {
                 local_irq_restore(irq_flags);
                 return -ENXIO;
diff --git a/xen/arch/x86/guest/hyperv/util.c b/xen/arch/x86/guest/hyperv/util.c
index bec61c2afd87..2c5f421b7bd9 100644
--- a/xen/arch/x86/guest/hyperv/util.c
+++ b/xen/arch/x86/guest/hyperv/util.c
@@ -33,7 +33,7 @@ int cpumask_to_vpset(struct hv_vpset *vpset,
 {
     int nr = 1;
     unsigned int cpu, vcpu_bank, vcpu_offset;
-    unsigned int max_banks = ms_hyperv.max_vp_index / 64;
+    unsigned int max_banks = hv_max_vp_index / 64;
 
     /* Up to 64 banks can be represented by valid_bank_mask */
     if ( max_banks > 64 )
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 10:49:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 10:49:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTkHV-0008IP-NX; Wed, 29 Apr 2020 10:49:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fvgr=6N=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTkHV-0008IK-3x
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 10:49:33 +0000
X-Inumbo-ID: 1b6a55b6-8a07-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1b6a55b6-8a07-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 10:49:32 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 363C3ABAD;
 Wed, 29 Apr 2020 10:49:30 +0000 (UTC)
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: Igor Druzhinin <igor.druzhinin@citrix.com>, Julien Grall
 <julien@xen.org>, Julien Grall <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
Date: Wed, 29 Apr 2020 12:49:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.20 12:39, Igor Druzhinin wrote:
> On 29/04/2020 10:22, Julien Grall wrote:
>> Hi Juergen,
>>
>> On 29/04/2020 06:51, Jürgen Groß wrote:
>>>
>>> Recreating the event channel would be fine, but I don't see why it
>>> would ever be needed. And XS_INTRODUCE is called only at domain creation
>>> time today, so there is obviously no need for repeating this call.
>>>
>>> Maybe the idea was to do this after sending a XS_RESUME command, which
>>> isn't used anywhere in Xen and is another part of Xenstore which doesn't
>>> make any sense today.
>>
>> Commit f6cc37ea8ac71385b60507c034519f304da75f4c "tools/oxenstored: port XS_INTRODUCE evtchn rebind function from cxenstored" added the exact same behavior in the OCaml XenStored last year.
>>
>> This was introduced 12 years after C XenStored, so surely someone think this is useful. We should check why this was introduced in OCaml XenStored (I have CCed the author of the patch).
>>
>> If we still think this is not useful, then you should add an explanation in the commit message why the two implementations diverge and possibly update the spec.
> 
> Thanks for CC, Julien.
> 
> We indeed already use this functionality in our toolstack for guest kdump
> functions. It's not possible in XAPI to adopt libxl model where almost everything
> is restarted for a domain entering kdump, so we have to use this message to
> rebind xenstore evtchn after soft reset without shutting down backends and
> recreating the whole subtree (frontends reconnect fine after that).
> 
> We obviously only require it for now to be present in oxenstored only.
> Please don't remove this functionality if possible.

If I read handling in libxl correctly, in the soft reset case XS_RELEASE
is issued before doing another XS_INTRODUCE. XS_RELEASE will result in
xenstored throwing away its related struct domain, so XS_INTRODUCE will
be possible again.


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 11:02:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 11:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTkU0-0001hK-Uc; Wed, 29 Apr 2020 11:02:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTkU0-0001hC-2G
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 11:02:28 +0000
X-Inumbo-ID: e965e790-8a08-11ea-992b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e965e790-8a08-11ea-992b-12813bfff9fa;
 Wed, 29 Apr 2020 11:02:27 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E102AAE17;
 Wed, 29 Apr 2020 11:02:24 +0000 (UTC)
Subject: Re: [PATCH v2 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: Paul Durrant <paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-2-paul@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <d5013c9d-b1a9-6139-a120-741332d6e086@suse.com>
Date: Wed, 29 Apr 2020 13:02:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200407173847.1595-2-paul@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 19:38, Paul Durrant wrote:
> +void __init domain_register_save_type(unsigned int tc, const char *name,
> +                                      bool per_vcpu,
> +                                      domain_save_handler save,
> +                                      domain_load_handler load)
> +{
> +    BUG_ON(tc > ARRAY_SIZE(handlers));

>=

> +    ASSERT(!handlers[tc].save);
> +    ASSERT(!handlers[tc].load);
> +
> +    handlers[tc].name = name;
> +    handlers[tc].per_vcpu = per_vcpu;
> +    handlers[tc].save = save;
> +    handlers[tc].load = load;
> +}
> +
> +int domain_save_begin(struct domain_context *c, unsigned int tc,
> +                      const char *name, const struct vcpu *v, size_t len)

I find it quite odd for a function like this one to take a
struct vcpu * rather than a struct domain *. See also below
comment on the vcpu_id field in the public header.

> +{
> +    int rc;
> +
> +    if ( c->log )
> +        gdprintk(XENLOG_INFO, "%pv save: %s (%lu)\n", v, name,
> +                 (unsigned long)len);
> +
> +    BUG_ON(tc != c->desc.typecode);
> +    BUG_ON(v->vcpu_id != c->desc.vcpu_id);
> +
> +    ASSERT(!c->data_len);
> +    c->data_len = c->desc.length = len;
> +
> +    rc = c->copy.write(c->priv, &c->desc, sizeof(c->desc));
> +    if ( rc )
> +        return rc;
> +
> +    c->desc.length = 0;
> +
> +    return 0;
> +}
> +
> +int domain_save_data(struct domain_context *c, const void *src, size_t len)
> +{
> +    if ( c->desc.length + len > c->data_len )
> +        return -ENOSPC;
> +
> +    c->desc.length += len;
> +
> +    return c->copy.write(c->priv, src, len);
> +}
> +
> +int domain_save_end(struct domain_context *c)

I'm sure there is a reason for the split into three load/save
functions (begin/data/end), but I can't figure it and the
description also doesn't explain it. They're all used together
only afaics, in domain_{save,load}_entry(). Or wait, there are
DOMAIN_{SAVE,LOAD}_BEGIN() macros apparently allowing separate
use of ..._begin(), but then it's still not clear why ..._end()
need to be separate from ..._data().

> +int domain_save(struct domain *d, domain_write_entry write, void *priv,
> +                bool dry_run)
> +{
> +    struct domain_context c = {
> +        .copy.write = write,
> +        .priv = priv,
> +        .log = !dry_run,
> +    };
> +    struct domain_save_header h = {

const? Perhaps even static?

> +        .magic = DOMAIN_SAVE_MAGIC,
> +        .version = DOMAIN_SAVE_VERSION,
> +    };
> +    struct domain_save_header e;
> +    unsigned int i;
> +    int rc;
> +
> +    ASSERT(d != current->domain);
> +
> +    if ( d->is_dying )
> +        return -EINVAL;

Could I talk you into using less generic an error code here, e.g.
-ESRCH or -ENXIO? There look to be further uses of EINVAL that
may want replacing.

> +    domain_pause(d);
> +
> +    c.desc.typecode = DOMAIN_SAVE_CODE(HEADER);
> +
> +    rc = DOMAIN_SAVE_ENTRY(HEADER, &c, d->vcpu[0], &h, sizeof(h));
> +    if ( rc )
> +        goto out;
> +
> +    for ( i = 0; i < ARRAY_SIZE(handlers); i++ )
> +    {
> +        domain_save_handler save = handlers[i].save;
> +
> +        if ( !save )
> +            continue;
> +
> +        memset(&c.desc, 0, sizeof(c.desc));
> +        c.desc.typecode = i;
> +
> +        if ( handlers[i].per_vcpu )
> +        {
> +            struct vcpu *v;
> +
> +            for_each_vcpu ( d, v )
> +            {
> +                c.desc.vcpu_id = v->vcpu_id;
> +
> +                rc = save(v, &c, dry_run);
> +                if ( rc )
> +                    goto out;
> +            }
> +        }
> +        else
> +        {
> +            rc = save(d->vcpu[0], &c, dry_run);
> +            if ( rc )
> +                goto out;
> +        }
> +    }
> +
> +    memset(&c.desc, 0, sizeof(c.desc));
> +    c.desc.typecode = DOMAIN_SAVE_CODE(END);
> +
> +    rc = DOMAIN_SAVE_ENTRY(END, &c, d->vcpu[0], &e, 0);

By the looks of it you're passing uninitialized e here; it's just
that the struct has no members. It would look less odd if you used
NULL here. Otherwise please don't use literal 0, but sizeof() for
the last parameter.

> +int domain_load_begin(struct domain_context *c, unsigned int tc,
> +                      const char *name, const struct vcpu *v, size_t len,
> +                      bool exact)
> +{
> +    if ( c->log )
> +        gdprintk(XENLOG_INFO, "%pv load: %s (%lu)\n", v, name,
> +                 (unsigned long)len);
> +
> +    BUG_ON(tc != c->desc.typecode);
> +    BUG_ON(v->vcpu_id != c->desc.vcpu_id);
> +
> +    if ( (exact && (len != c->desc.length)) ||
> +         (len < c->desc.length) )
> +        return -EINVAL;

How about

    if ( exact ? len != c->desc.length
               : len < c->desc.length )

? I'm also unsure about the < - don't you mean > instead? Too
little data would be compensated by zero padding, but too
much data can't be dealt with. But maybe I'm getting the sense
of len wrong ...

> +int domain_load(struct domain *d, domain_read_entry read, void *priv)
> +{
> +    struct domain_context c = {
> +        .copy.read = read,
> +        .priv = priv,
> +        .log = true,
> +    };
> +    struct domain_save_header h;
> +    int rc;
> +
> +    ASSERT(d != current->domain);
> +
> +    if ( d->is_dying )
> +        return -EINVAL;
> +
> +    rc = c.copy.read(c.priv, &c.desc, sizeof(c.desc));
> +    if ( rc )
> +        return rc;
> +
> +    if ( c.desc.typecode != DOMAIN_SAVE_CODE(HEADER) || c.desc.vcpu_id ||
> +         c.desc.flags )
> +        return -EINVAL;
> +
> +    rc = DOMAIN_LOAD_ENTRY(HEADER, &c, d->vcpu[0], &h, sizeof(h), true);
> +    if ( rc )
> +        return rc;
> +
> +    if ( h.magic != DOMAIN_SAVE_MAGIC || h.version != DOMAIN_SAVE_VERSION )
> +        return -EINVAL;
> +
> +    domain_pause(d);
> +
> +    for (;;)
> +    {
> +        unsigned int i;
> +        unsigned int flags;
> +        domain_load_handler load;
> +        struct vcpu *v;
> +
> +        rc = c.copy.read(c.priv, &c.desc, sizeof(c.desc));
> +        if ( rc )
> +            break;
> +
> +        rc = -EINVAL;
> +
> +        flags = c.desc.flags;
> +        if ( flags & ~DOMAIN_SAVE_FLAG_IGNORE )
> +            break;
> +
> +        if ( c.desc.typecode == DOMAIN_SAVE_CODE(END) ) {

Brace placement.

> +            if ( !(flags & DOMAIN_SAVE_FLAG_IGNORE) )
> +                rc = DOMAIN_LOAD_ENTRY(END, &c, d->vcpu[0], NULL, 0, true);

The public header says DOMAIN_SAVE_FLAG_IGNORE is invalid for
END.

> +            break;
> +        }
> +
> +        i = c.desc.typecode;
> +        if ( i >= ARRAY_SIZE(handlers) )
> +            break;
> +
> +        if ( (!handlers[i].per_vcpu && c.desc.vcpu_id) ||
> +             (c.desc.vcpu_id >= d->max_vcpus) )
> +            break;
> +
> +        v = d->vcpu[c.desc.vcpu_id];
> +
> +        if ( flags & DOMAIN_SAVE_FLAG_IGNORE )
> +        {
> +            /* Sink the data */
> +            rc = domain_load_entry(&c, c.desc.typecode, "IGNORED",
> +                                   v, NULL, c.desc.length, true);

IOW the read handlers need to be able to deal with a NULL dst?
Sounds a little fragile to me. Is there a reason
domain_load_data() can't skip the call to read()?

> --- /dev/null
> +++ b/xen/include/public/save.h
> @@ -0,0 +1,84 @@
> +/*
> + * save.h
> + *
> + * Structure definitions for common PV/HVM domain state that is held by
> + * Xen and must be saved along with the domain's memory.
> + *
> + * Copyright Amazon.com Inc. or its affiliates.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __XEN_PUBLIC_SAVE_H__
> +#define __XEN_PUBLIC_SAVE_H__
> +
> +#include "xen.h"
> +
> +/* Each entry is preceded by a descriptor */
> +struct domain_save_descriptor {

Throughout this new public header, let's please play nice in name
space terms: Prefix global scope items with xen_ / XEN_
respectively, and don't introduce violations of the standard's
rules (e.g. _DOMAIN_SAVE_FLAG_IGNORE below). The latter point also
goes for naming outside of the public header, of course.

> +    uint16_t typecode;
> +    /*
> +     * Each entry will contain either to global or per-vcpu domain state.

s/contain/apply/ or drop "to"?

> +     * Entries relating to global state should have zero in this field.

Is there a reason to specify zero?

> +     */
> +    uint16_t vcpu_id;

Seeing (possibly) multi-instance records in HVM state (PIC, IO-APIC, HPET),
wouldn't it be better to generalize this to ID, meaning "vCPU ID" just for
per-vCPU state?

> +    uint32_t flags;
> +    /*
> +     * When restoring state this flag can be set in a descriptor to cause
> +     * its content to be ignored.
> +     *
> +     * NOTE: It is invalid to set this flag for HEADER or END records (see
> +     *       below).
> +     */
> +#define _DOMAIN_SAVE_FLAG_IGNORE 0
> +#define DOMAIN_SAVE_FLAG_IGNORE (1u << _DOMAIN_SAVE_FLAG_IGNORE)

As per your reply to Julien I think this wants further clarification on
the intentions with this flag. I'm also uncertain it is a good idea to
allow such partial restores - there may be dependencies between records,
and hence things can easily go wrong in perhaps non-obvious ways.

> +    /* Entry length not including this descriptor */
> +    uint64_t length;

Do you really envision descriptors with more than 4Gb of data? If so,
for 32-bit purposes wouldn't this want to be uint64_aligned_t?

> +};
> +
> +/*
> + * Each entry has a type associated with it. DECLARE_DOMAIN_SAVE_TYPE
> + * binds these things together.
> + */
> +#define DECLARE_DOMAIN_SAVE_TYPE(_x, _code, _type) \
> +    struct __DOMAIN_SAVE_TYPE_##_x { char c[_code]; _type t; };
> +
> +#define DOMAIN_SAVE_CODE(_x) \
> +    (sizeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->c))
> +#define DOMAIN_SAVE_TYPE(_x) \
> +    typeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->t)

Just like the typeof() I dont think the sizeof() needs an outer
pair of parentheses. I also don't see why 0 gets parenthesized.

> +/* Terminating entry */
> +struct domain_save_end {};
> +DECLARE_DOMAIN_SAVE_TYPE(END, 0, struct domain_save_end);

If the header gets a __XEN__ || __XEN_TOOLS__ restriction, as
suggested by Julien, using 0 here may be fine. If not, char[0]
and typeof() aren't legal plain C and hence would need to be
avoided.

> --- /dev/null
> +++ b/xen/include/xen/save.h
> @@ -0,0 +1,152 @@
> +/*
> + * save.h: support routines for save/restore
> + *
> + * Copyright Amazon.com Inc. or its affiliates.
> + *
> + * 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 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 <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __XEN_SAVE_H__
> +#define __XEN_SAVE_H__
> +
> +#include <xen/sched.h>
> +#include <xen/types.h>
> +#include <xen/init.h>

Please sort these.

> +#include <public/xen.h>
> +#include <public/save.h>

The latter includes the former anyway - is the former necessary
for some reason nevertheless?

> +struct domain_context;
> +
> +int domain_save_begin(struct domain_context *c, unsigned int tc,
> +                      const char *name, const struct vcpu *v, size_t len);
> +
> +#define DOMAIN_SAVE_BEGIN(_x, _c, _v, _len) \
> +        domain_save_begin((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_len))

In new code I'd like to ask for no leading underscores on macro
parameters as well as no unnecessary parenthesization of macro
parameters (e.g. when they simply get passed on to another macro
or function without being part of a larger expression).

> +int domain_save_data(struct domain_context *c, const void *data, size_t len);
> +int domain_save_end(struct domain_context *c);
> +
> +static inline int domain_save_entry(struct domain_context *c,
> +                                    unsigned int tc, const char *name,
> +                                    const struct vcpu *v, const void *src,
> +                                    size_t len)
> +{
> +    int rc;
> +
> +    rc = domain_save_begin(c, tc, name, v, len);
> +    if ( rc )
> +        return rc;
> +
> +    rc = domain_save_data(c, src, len);
> +    if ( rc )
> +        return rc;
> +
> +    return domain_save_end(c);
> +}
> +
> +#define DOMAIN_SAVE_ENTRY(_x, _c, _v, _src, _len) \
> +    domain_save_entry((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_src), (_len))
> +
> +int domain_load_begin(struct domain_context *c, unsigned int tc,
> +                      const char *name, const struct vcpu *v, size_t len,
> +                      bool exact);
> +
> +#define DOMAIN_LOAD_BEGIN(_x, _c, _v, _len, _exact) \
> +        domain_load_begin((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_len), \
> +                          (_exact));
> +
> +int domain_load_data(struct domain_context *c, void *data, size_t len);
> +int domain_load_end(struct domain_context *c);
> +
> +static inline int domain_load_entry(struct domain_context *c,
> +                                    unsigned int tc, const char *name,
> +                                    const struct vcpu *v, void *dst,
> +                                    size_t len, bool exact)
> +{
> +    int rc;
> +
> +    rc = domain_load_begin(c, tc, name, v, len, exact);
> +    if ( rc )
> +        return rc;
> +
> +    rc = domain_load_data(c, dst, len);
> +    if ( rc )
> +        return rc;
> +
> +    return domain_load_end(c);
> +}
> +
> +#define DOMAIN_LOAD_ENTRY(_x, _c, _v, _dst, _len, _exact) \
> +    domain_load_entry((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_dst), (_len), \
> +                          (_exact))
> +
> +/*
> + * The 'dry_run' flag indicates that the caller of domain_save() (see
> + * below) is not trying to actually acquire the data, only the size
> + * of the data. The save handler can therefore limit work to only that
> + * which is necessary to call DOMAIN_SAVE_BEGIN/ENTRY() with an accurate
> + * value for '_len'.
> + */
> +typedef int (*domain_save_handler)(const struct vcpu *v,
> +                                   struct domain_context *h,
> +                                   bool dry_run);
> +typedef int (*domain_load_handler)(struct vcpu *v,
> +                                   struct domain_context *h);

Does a load handler have a need to modify struct domain_context?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 11:04:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 11:04:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTkVe-0001nw-B5; Wed, 29 Apr 2020 11:04:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTkVd-0001nr-54
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 11:04:09 +0000
X-Inumbo-ID: 25eab45c-8a09-11ea-992b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 25eab45c-8a09-11ea-992b-12813bfff9fa;
 Wed, 29 Apr 2020 11:04:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 111A9AC44;
 Wed, 29 Apr 2020 11:04:07 +0000 (UTC)
Subject: Re: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
 <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
 <9df9c5163fde5d25ceb756b20714c58be93b2c6c.camel@xen.org>
 <c33dcaee9c8796da8816de9168f91ce90de61fc5.camel@xen.org>
 <e18871ea997a304394adbbc92e724ae0ec56d87a.camel@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <ec318c48-41c3-5cbf-e03e-8838d9f488ba@suse.com>
Date: Wed, 29 Apr 2020 13:04:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <e18871ea997a304394adbbc92e724ae0ec56d87a.camel@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 11:26, Hongyan Xia wrote:
> But if people do not have a problem with plXe - 1, I will post a new
> revision for that.

I'd prefer that; I could live with the current version, but I'm
not in favor of it.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 11:04:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 11:04:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTkWJ-0001rP-Ma; Wed, 29 Apr 2020 11:04:51 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xGEm=6N=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jTkWI-0001rF-DF
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 11:04:50 +0000
X-Inumbo-ID: 3e280b78-8a09-11ea-9887-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3e280b78-8a09-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 11:04:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588158289;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=LjuH2KmdeMFyY8lpzTjtHPe82pEtcfRL4wNcgMqa3tQ=;
 b=aVRb57hfYy9CoDdrzLmhqUARH9opvVI03xIXfcdv2NUIYcA6kCcbk5Ah
 azH5sZsK5Rxco4+3urt51iemABW2blrFW3dincoqMSeCCzYHRxzHtXegs
 +SPrNbLGxx6+hKSYknsr2ym5S8O/7GSXgJDcXo6uDSD7x+ReTRAOe6Bvc 8=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 7uHk95UT+G1/bkQvlkFII66f6rcZWFxW2w5el+WAoZJqYqIVE1SWYtaXJ5/VTfHkU+l0euGOoN
 2P41A+qtWzyrQY50tshRBGB3e0Wo0H9jd7HwhxlUqHdKNNNqVanEDDPYJDyyYF0wPKVgclY55O
 wONN/rWogRrSQg2RaZiQ1rU45UR/SwFqj6y9EJ52NxzBDM4ldGb024OYhTYZc2FMSIX9W5xUHz
 iWAHOYEhNuHmCYkCLQBBDUByqftXGVhM/Aj2EYGqUMBEaLwbBhmmGWD5N8RxSI7nOiJvdWF0HR
 cHk=
X-SBRS: 2.7
X-MesageID: 16683154
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,331,1583211600"; d="scan'208";a="16683154"
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>, Julien Grall
 <julien@xen.org>, Julien Grall <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
 <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
Date: Wed, 29 Apr 2020 12:04:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 11:49, Jürgen Groß wrote:
> On 29.04.20 12:39, Igor Druzhinin wrote:
>> On 29/04/2020 10:22, Julien Grall wrote:
>>> Hi Juergen,
>>>
>>> On 29/04/2020 06:51, Jürgen Groß wrote:
>>>>
>>>> Recreating the event channel would be fine, but I don't see why it
>>>> would ever be needed. And XS_INTRODUCE is called only at domain creation
>>>> time today, so there is obviously no need for repeating this call.
>>>>
>>>> Maybe the idea was to do this after sending a XS_RESUME command, which
>>>> isn't used anywhere in Xen and is another part of Xenstore which doesn't
>>>> make any sense today.
>>>
>>> Commit f6cc37ea8ac71385b60507c034519f304da75f4c "tools/oxenstored: port XS_INTRODUCE evtchn rebind function from cxenstored" added the exact same behavior in the OCaml XenStored last year.
>>>
>>> This was introduced 12 years after C XenStored, so surely someone think this is useful. We should check why this was introduced in OCaml XenStored (I have CCed the author of the patch).
>>>
>>> If we still think this is not useful, then you should add an explanation in the commit message why the two implementations diverge and possibly update the spec.
>>
>> Thanks for CC, Julien.
>>
>> We indeed already use this functionality in our toolstack for guest kdump
>> functions. It's not possible in XAPI to adopt libxl model where almost everything
>> is restarted for a domain entering kdump, so we have to use this message to
>> rebind xenstore evtchn after soft reset without shutting down backends and
>> recreating the whole subtree (frontends reconnect fine after that).
>>
>> We obviously only require it for now to be present in oxenstored only.
>> Please don't remove this functionality if possible.
> 
> If I read handling in libxl correctly, in the soft reset case XS_RELEASE
> is issued before doing another XS_INTRODUCE. XS_RELEASE will result in
> xenstored throwing away its related struct domain, so XS_INTRODUCE will
> be possible again.

>From what I remember it was not possible to keep xenstored data for a domain
and at the same time perform release-introduce cycle (at least in oxenstored).
It also involved firing @releaseDomain which caused havoc in other part of
the toolstack.

Igor


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 11:05:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 11:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTkWm-0001w8-66; Wed, 29 Apr 2020 11:05:20 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTkWk-0001vq-Ub
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 11:05:19 +0000
X-Inumbo-ID: 4f1296ce-8a09-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4f1296ce-8a09-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 11:05:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=al5kzuD/JTHVR9JFCIRLrRgLQ3rTqHqUQ/TkNOZ8+eg=; b=ZcelP/YvipMjEY1dslJBFREzf3
 8bN1EbOp0niocNVMrlNoU/sqIefMxiHzIIMF2t2pPRNhCVhsGPGsGsx0B9fCzFAUaAEMYvssevbgq
 yLXEsu9IDsvvi4yI++j1dcNk/o26MdDHXR9pV+MRfEhcgWJtu+d29OB9/LW/Ybqjn7yk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTkWd-0007Zm-Q7; Wed, 29 Apr 2020 11:05:11 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTkWd-00013j-7t; Wed, 29 Apr 2020 11:05:11 +0000
Subject: Re: [PATCH v2 1/5] xen/common: introduce a new framework for
 save/restore of 'domain' context
To: xen-devel@lists.xenproject.org
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-2-paul@xen.org>
 <2f69484c-d043-bded-0a88-2587241aaa94@xen.org>
 <001401d61d72$9ef9da20$dced8e60$@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <a0029c32-fd46-956a-136b-bb5c901415d6@xen.org>
Date: Wed, 29 Apr 2020 12:05:08 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <001401d61d72$9ef9da20$dced8e60$@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, 'Jan Beulich' <jbeulich@suse.com>,
 'Volodymyr Babchuk' <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?B?J1JvZ2VyIFBhdSBNb25uw6kn?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Paul,

On 28/04/2020 16:35, Paul Durrant wrote:
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Sent: 20 April 2020 18:21
>> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
>> Cc: Paul Durrant <pdurrant@amazon.com>; Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap
>> <george.dunlap@citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>;
>> Stefano Stabellini <sstabellini@kernel.org>; Wei Liu <wl@xen.org>; Volodymyr Babchuk
>> <Volodymyr_Babchuk@epam.com>; Roger Pau Monné <roger.pau@citrix.com>
>> Subject: Re: [PATCH v2 1/5] xen/common: introduce a new framework for save/restore of 'domain' context
>>
>> Hi Paul,
>>
>> On 07/04/2020 18:38, Paul Durrant wrote:
>>> To allow enlightened HVM guests (i.e. those that have PV drivers) to be
>>> migrated without their co-operation it will be necessary to transfer 'PV'
>>> state such as event channel state, grant entry state, etc.
>>>
>>> Currently there is a framework (entered via the hvm_save/load() functions)
>>> that allows a domain's 'HVM' (architectural) state to be transferred but
>>> 'PV' state is also common with pure PV guests and so this framework is not
>>> really suitable.
>>>
>>> This patch adds the new public header and low level implementation of a new
>>> common framework, entered via the domain_save/load() functions. Subsequent
>>> patches will introduce other parts of the framework, and code that will
>>> make use of it within the current version of the libxc migration stream.
>>>
>>> This patch also marks the HVM-only framework as deprecated in favour of the
>>> new framework.
>>>
>>> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
>>> ---
>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Cc: George Dunlap <george.dunlap@citrix.com>
>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>>> Cc: Julien Grall <julien@xen.org>
>>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>>> Cc: Wei Liu <wl@xen.org>
>>> Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
>>> Cc: "Roger Pau Monné" <roger.pau@citrix.com>
>>>
>>> v2:
>>>    - Allow multi-stage save/load to avoid the need to double-buffer
>>>    - Get rid of the masks and add an 'ignore' flag instead
>>>    - Create copy function union to preserve const save buffer
>>>    - Deprecate HVM-only framework
>>> ---
>>>    xen/common/Makefile                    |   1 +
>>>    xen/common/save.c                      | 329 +++++++++++++++++++++++++
>>>    xen/include/public/arch-arm/hvm/save.h |   5 +
>>>    xen/include/public/arch-x86/hvm/save.h |   5 +
>>>    xen/include/public/save.h              |  84 +++++++
>>>    xen/include/xen/save.h                 | 152 ++++++++++++
>>>    6 files changed, 576 insertions(+)
>>>    create mode 100644 xen/common/save.c
>>>    create mode 100644 xen/include/public/save.h
>>>    create mode 100644 xen/include/xen/save.h
>>>
>>> diff --git a/xen/common/Makefile b/xen/common/Makefile
>>> index e8cde65370..90553ba5d7 100644
>>> --- a/xen/common/Makefile
>>> +++ b/xen/common/Makefile
>>> @@ -37,6 +37,7 @@ obj-y += radix-tree.o
>>>    obj-y += rbtree.o
>>>    obj-y += rcupdate.o
>>>    obj-y += rwlock.o
>>> +obj-y += save.o
>>>    obj-y += shutdown.o
>>>    obj-y += softirq.o
>>>    obj-y += sort.o
>>> diff --git a/xen/common/save.c b/xen/common/save.c
>>> new file mode 100644
>>> index 0000000000..6cdac3785b
>>> --- /dev/null
>>> +++ b/xen/common/save.c
>>> @@ -0,0 +1,329 @@
>>> +/*
>>> + * save.c: Save and restore PV guest state common to all domain types.
>>> + *
>>> + * Copyright Amazon.com Inc. or its affiliates.
>>> + *
>>> + * 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 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 <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#include <xen/save.h>
>>> +
>>> +union domain_copy_entry {
>>> +    domain_write_entry write;
>>> +    domain_read_entry read;
>>> +};
>>> +
>>> +struct domain_context {
>>> +    bool log;
>>> +    struct domain_save_descriptor desc;
>>> +    size_t data_len;
>>
>> What is data_len?
>>
> 
> It’s used for internal accounting.

Can you add a comment explaining it?

> 
>>> +    union domain_copy_entry copy;
>>> +    void *priv;
>>> +};
>>> +
>>> +static struct {
>>> +    const char *name;
>>> +    bool per_vcpu;
>>> +    domain_save_handler save;
>>> +    domain_load_handler load;
>>> +} handlers[DOMAIN_SAVE_CODE_MAX + 1];
>>> +
>>> +void __init domain_register_save_type(unsigned int tc, const char *name,
>>> +                                      bool per_vcpu,
>>> +                                      domain_save_handler save,
>>> +                                      domain_load_handler load)
>>> +{
>>> +    BUG_ON(tc > ARRAY_SIZE(handlers));
>>> +
>>> +    ASSERT(!handlers[tc].save);
>>> +    ASSERT(!handlers[tc].load);
>>> +
>>> +    handlers[tc].name = name;
>>> +    handlers[tc].per_vcpu = per_vcpu;
>>> +    handlers[tc].save = save;
>>> +    handlers[tc].load = load;
>>> +}
>>> +
>>> +int domain_save_begin(struct domain_context *c, unsigned int tc,
>>> +                      const char *name, const struct vcpu *v, size_t len)
>>> +{
>>> +    int rc;
>>> +
>>> +    if ( c->log )
>>> +        gdprintk(XENLOG_INFO, "%pv save: %s (%lu)\n", v, name,
>>> +                 (unsigned long)len);
>>
>> How about using %zu rather than a cast here?
>>
> 
> Yes, that would be better.
> 
>>> +
>>> +    BUG_ON(tc != c->desc.typecode);
>>> +    BUG_ON(v->vcpu_id != c->desc.vcpu_id);
>>
>> I can't find any answer on my question about this part. I understand the
>> code would be buggy if this happen, but is it warrant to crash the host?
>> Couldn't you just return an error and continue to run?
>>
> 
> Since it means buggy code I could ASSERT and error out, yes.

That would be better, thanks!

> 
>>> +
>>> +    ASSERT(!c->data_len);
>>> +    c->data_len = c->desc.length = len;
>>> +
>>> +    rc = c->copy.write(c->priv, &c->desc, sizeof(c->desc));
>>> +    if ( rc )
>>> +        return rc;
>>> +
>>> +    c->desc.length = 0;
>>
>> This is confusing, why would you need to reset c->desc.length but not
>> the rest of the fields?
>>
> 
> Because I use it to accumulate the length of the saved data and then cross check it against data_len in domain_save_end() below.
> 
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +int domain_save_data(struct domain_context *c, const void *src, size_t len)
>>> +{
>>> +    if ( c->desc.length + len > c->data_len )
>>> +        return -ENOSPC;
>>> +
>>> +    c->desc.length += len;
>>> +
>>> +    return c->copy.write(c->priv, src, len);
>>> +}
>>> +
>>> +int domain_save_end(struct domain_context *c)
>>> +{
>>> +    /*
>>> +     * If desc.length does not match the length specified in
>>> +     * domain_save_begin(), there should have been more data.
>>> +     */
>>> +    if ( c->desc.length != c->data_len )
>>
>> This suggests you know in advance the size of the record.
> 
> That depends on what you mean by 'in advance'. I'd expect the caller of domain_save_begin() to know exactly.
> 
>> I have seen
>> some cases where we don't know the size in advance. A good example if
>> when saving grants. You know the maximum of grant used by the guest but
>> you don't know yet the number of grants used. You might need to walk the
>> "list" twice or allocate a temporary buffer. None of them are ideal.
>>
>> Another example is when saving memory, we may want to compact page
>> informations to save space.
>>
>> This problem is going to be more relevant for LiveUpdate where we need
>> to be able to create the stream in a very short amount of time.
>> Allocating any temporary buffer and/or walking the list twice is going
>> to kill the performance.
>>
>> I would suggest to consider a different approach where you update the
>> record length at the end.
>>
>> FWIW, this below the current approach for the LU stream (IIRC David sent
>> a prototype recently). A record is opened using lu_stream_open_record(),
>> you then have two way to add data:
>>       - lu_stream_append() -> This takes a buffer and write to the stream.
>>       - lu_stream_reserve() -> Pre-allocate space in the stream and
>> return a pointer to the beginning of the reserved region.
>>       - lu_stream_end_reservation() -> Takes the actual size in parameter
>> and update the stream size.
>>       - lu_stream_close_record() -> Update the header with the total
>> length and update the position in the stream.
>>
> 
> That sounds quite LU specific. For LM we still need to know up-front the maximal size of the buffer, 

I described the function from an LU PoV, but thsi is mostly replace 
lu_stream_reserve() by a function that check you have at least N bytes 
free in your stream.

> and I was trying to work on the basis of never having to update previously saved data but I guess there's no actual harm in doing so, so we could avoid domain_save_begin() specifying the length.

It depends what we want to achieve in term of memory space and time. If 
we want to avoid modifying previously saved data, then we would need to 
walk the elements twice or allocate a temporary buffer. They will both 
consume space and time.

A good example for LM is when we need to save the event channels. The 
maximum number of event channels is known in advance but you don't know 
how many of them are used. We could save all of them (even the free 
ones) but this is a waste of space.

To avoid the temporary buffer or walking the elements twice, our 
internal tree contain open-code code to rewrite the record in the event 
channels save function.

> 
>>> +        return -EIO;
>>
>> I noticed that all the pasding check have been dropped. I still think we
>> need implicit padding to harden the code.
>>
> 
> I'd still view that as buggy code.
> 
>>> +
>>> +    c->data_len = 0;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +int domain_save(struct domain *d, domain_write_entry write, void *priv,
>>> +                bool dry_run)
>>> +{
>>> +    struct domain_context c = {
>>> +        .copy.write = write,
>>> +        .priv = priv,
>>> +        .log = !dry_run,
>>> +    };
>>> +    struct domain_save_header h = {
>>> +        .magic = DOMAIN_SAVE_MAGIC,
>>> +        .version = DOMAIN_SAVE_VERSION,
>>> +    };
>>> +    struct domain_save_header e;
>>> +    unsigned int i;
>>> +    int rc;
>>> +
>>> +    ASSERT(d != current->domain);
>>> +
>>> +    if ( d->is_dying )
>>
>> I can't find an answer to my question about d->is_dying. What if the
>> guest die afterwards? What does protect us against domain_kill()?
>>
>> [...]
> 
> As I said in a previous response, nothing protects against domain_kill(), this check is just supposed to avoid doing 'unnecessary' work for a domain we know is already dying. 

Regardless LU (see below), I would argue that if a user purposefully 
call domain_save() on a dying domain, then he/she already accepted the cost.

Beside, this give a false idea that domain_kill() cannot be called in 
parallel. So I would rather drop this check unless we can make it safe.

> For LU though I guess we do need to save (some) state for even a dying domain, so the individual save handlers actually need to make the decision on whether they are going to do anything.

That's correct we would want to preserve states for dying domain.

>>
>>> +int domain_load(struct domain *d, domain_read_entry read, void *priv)
>>> +{
>>> +    struct domain_context c = {
>>> +        .copy.read = read,
>>> +        .priv = priv,
>>> +        .log = true,
>>> +    };
>>> +    struct domain_save_header h;
>>> +    int rc;
>>> +
>>> +    ASSERT(d != current->domain);
>>> +
>>> +    if ( d->is_dying )
>>> +        return -EINVAL;
>>
>> Same here.
>>
>>
>>> diff --git a/xen/include/public/save.h b/xen/include/public/save.h
>>> new file mode 100644
>>> index 0000000000..7e5f8752bd
>>> --- /dev/null
>>> +++ b/xen/include/public/save.h
>>> @@ -0,0 +1,84 @@
>>> +/*
>>> + * save.h
>>> + *
>>> + * Structure definitions for common PV/HVM domain state that is held by
>>> + * Xen and must be saved along with the domain's memory.
>>> + *
>>> + * Copyright Amazon.com Inc. or its affiliates.
>>> + *
>>> + * Permission is hereby granted, free of charge, to any person obtaining a copy
>>> + * of this software and associated documentation files (the "Software"), to
>>> + * deal in the Software without restriction, including without limitation the
>>> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
>>> + * sell copies of the Software, and to permit persons to whom the Software is
>>> + * furnished to do so, subject to the following conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be included in
>>> + * all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>>> + * DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +#ifndef __XEN_PUBLIC_SAVE_H__
>>> +#define __XEN_PUBLIC_SAVE_H__
>>
>> Does this header need to be exposed outside of Xen and the tools?
>>
> 
> Probably not.
> 
>>> +
>>> +#include "xen.h"
>>> +
>>> +/* Each entry is preceded by a descriptor */
>>> +struct domain_save_descriptor {
>>> +    uint16_t typecode;
>>> +    /*
>>> +     * Each entry will contain either to global or per-vcpu domain state.
>>> +     * Entries relating to global state should have zero in this field.
>>> +     */
>>> +    uint16_t vcpu_id;
>>> +    uint32_t flags;
>>> +    /*
>>> +     * When restoring state this flag can be set in a descriptor to cause
>>> +     * its content to be ignored.
>>
>> Could you give examples where you would want to ignore a descriptor?
>>
> 
> I was thinking of the case when, e.g. you want to update something in the shared_info... You save a context blob, modify the shared_info record, and then restore the context blob with all other records marked as 'ignore' since they have not been modified.

How about introducing a domctl similar to 
XEN_DOMCTL_gethvmcontext_partial? This would only give you the 
shared_info record and make easier for the user to use.

> 
>>> +     *
>>> +     * NOTE: It is invalid to set this flag for HEADER or END records (see
>>> +     *       below).
>>> +     */
>>> +#define _DOMAIN_SAVE_FLAG_IGNORE 0
>>> +#define DOMAIN_SAVE_FLAG_IGNORE (1u << _DOMAIN_SAVE_FLAG_IGNORE)
>>> +
>>> +    /* Entry length not including this descriptor */
>>> +    uint64_t length;
>>> +};
>>> +
>>> +/*
>>> + * Each entry has a type associated with it. DECLARE_DOMAIN_SAVE_TYPE
>>> + * binds these things together.
>>> + */
>>> +#define DECLARE_DOMAIN_SAVE_TYPE(_x, _code, _type) \
>>> +    struct __DOMAIN_SAVE_TYPE_##_x { char c[_code]; _type t; };
>>> +
>>> +#define DOMAIN_SAVE_CODE(_x) \
>>> +    (sizeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->c))
>>> +#define DOMAIN_SAVE_TYPE(_x) \
>>> +    typeof(((struct __DOMAIN_SAVE_TYPE_##_x *)(0))->t)
>>> +
>>> +/* Terminating entry */
>>> +struct domain_save_end {};
>>> +DECLARE_DOMAIN_SAVE_TYPE(END, 0, struct domain_save_end);
>>> +
>>> +#define DOMAIN_SAVE_MAGIC   0x53415645
>>> +#define DOMAIN_SAVE_VERSION 0x00000001
>>> +
>>> +/* Initial entry */
>>> +struct domain_save_header {
>>> +    uint32_t magic;             /* Must be DOMAIN_SAVE_MAGIC */
>>> +    uint32_t version;           /* Save format version */
>>
>>
>> I haven't seen any answer about xen version here. For the record:
>>
>> "Let's imagine in 4.14 we introduced a bug in the saving part. This is
>> solved in 4.15 but somehow the version is not bumped. How would you
>> differentiate the streams saved by Xen 4.14 so you can still migrate?
> 
> I'd assume testing would at least save and restore on 4.14. If we then fixed a bug then why would we not bump the version?

Do you mean we would test save/restore between 4.14 and 4.15 (and 
vice-versa)? If so, this may work but we need this to be part of OSSTest 
so we can catch this. Otherwise there are chance we don't catch 
regression in the stream.

> 
>>
>> If you record the version of Xen in the record automatically, then you
>> at least have a way to differentiate the two versions."
>>
> 
> OK, I guess redundant version information is not going to be harmful.
> 
>    Paul
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 11:09:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 11:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTkaV-0002AK-Pi; Wed, 29 Apr 2020 11:09:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTkaU-0002AF-Cs
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 11:09:10 +0000
X-Inumbo-ID: d94d50eb-8a09-11ea-992b-12813bfff9fa
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d94d50eb-8a09-11ea-992b-12813bfff9fa;
 Wed, 29 Apr 2020 11:09:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588158549;
 h=from:to:cc:subject:date:message-id:mime-version;
 bh=+Mpp+ZiKK/GN+G1qHHbpqgfpTjZ0iwfW7+0MYUZWHa0=;
 b=S1tAY0moUM+LACguwUV2EbyWBBfsbiTFpwQQbXZeV9P9tp/Qp7pSFkI7
 ibStcnwMMFFd0WHwsX2lzpUFvz7Ffd3/mw+5snj3mRrrnTK4ng8vaTbPg
 Ep9GhmGvpoFZuESkxdRwK/Yv2sVGQY9kz3hqUEirb1CmpD0EWkPdIhuqP I=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: IipDfsvVfyuOULKzjBnm4yi3ldiVKOdjz/WPOlbQyFBt9zVo3D5dQEthKrRWYwhV/O02oQoRSs
 skBBtlLu4Rbw3SeBJLpjLVaByEpq8nqI2nVwaDVCJ+A2gwxW8GOVQUUv3YqD/DXGVi/gQkIk0Z
 GBGbMSVP+k0BCbPXY0rkem3v3S17gAc2CWhB+PpjEWPH8dnE1RLcVOJ6LIfdHEYuWF1Ol/jNbA
 BSDbqqt/xAZ1RrMlfnXkCbjzeuMlcPAGFjwNBXg7u5uERaP7D2p+HRHDEWIYUslijYAOXUmNi4
 h3U=
X-SBRS: 2.7
X-MesageID: 17119842
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,331,1583211600"; d="scan'208";a="17119842"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/S3: Drop {save, restore}_rest_processor_state() completely
Date: Wed, 29 Apr 2020 12:09:03 +0100
Message-ID: <20200429110903.15418-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

There is no need to save/restore FS/GS/XCR0 state.  It will be handled
suitably on the context switch away from the idle.

The CR4 restoration in restore_rest_processor_state() was actually fighting
later code in enter_state() which tried to keep CR4.MCE clear until everything
was set up.  Delete the intermediate restoration, and defer final restoration
until after MCE is reconfigured.

Changing PAT should be done before paging is enabled.  Move it into the
trampoline during setup for 64bit.

The only remaing piece of restoration is load_system_tables(), so suspend.c
can be deleted in its entirety.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monne <roger.pau@citrix.com>
---
 xen/arch/x86/acpi/Makefile      |  2 +-
 xen/arch/x86/acpi/power.c       |  9 ++++----
 xen/arch/x86/acpi/suspend.c     | 49 -----------------------------------------
 xen/arch/x86/acpi/wakeup_prot.S |  4 +---
 xen/arch/x86/boot/trampoline.S  |  5 +++++
 5 files changed, 11 insertions(+), 58 deletions(-)
 delete mode 100644 xen/arch/x86/acpi/suspend.c

diff --git a/xen/arch/x86/acpi/Makefile b/xen/arch/x86/acpi/Makefile
index 1b9e625713..041377e2bb 100644
--- a/xen/arch/x86/acpi/Makefile
+++ b/xen/arch/x86/acpi/Makefile
@@ -1,4 +1,4 @@
 obj-y += cpufreq/
 
-obj-y += lib.o power.o suspend.o cpu_idle.o cpuidle_menu.o
+obj-y += lib.o power.o cpu_idle.o cpuidle_menu.o
 obj-bin-y += boot.init.o wakeup_prot.o
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 6dfd4c7891..0cda362045 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -195,7 +195,6 @@ static int enter_state(u32 state)
     unsigned long flags;
     int error;
     struct cpu_info *ci;
-    unsigned long cr4;
 
     if ( (state <= ACPI_STATE_S0) || (state > ACPI_S_STATES_MAX) )
         return -EINVAL;
@@ -270,15 +269,15 @@ static int enter_state(u32 state)
 
     system_state = SYS_STATE_resume;
 
-    /* Restore CR4 and EFER from cached values. */
-    cr4 = read_cr4();
-    write_cr4(cr4 & ~X86_CR4_MCE);
+    /* Restore EFER from cached value. */
     write_efer(read_efer());
 
     device_power_up(SAVED_ALL);
 
     mcheck_init(&boot_cpu_data, false);
-    write_cr4(cr4);
+
+    /* Restore CR4 from cached value, now MCE is set up. */
+    write_cr4(read_cr4());
 
     printk(XENLOG_INFO "Finishing wakeup from ACPI S%d state.\n", state);
 
diff --git a/xen/arch/x86/acpi/suspend.c b/xen/arch/x86/acpi/suspend.c
deleted file mode 100644
index 3c1a3cbb34..0000000000
--- a/xen/arch/x86/acpi/suspend.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * Portions are:
- *  Copyright (c) 2002 Pavel Machek <pavel@suse.cz>
- *  Copyright (c) 2001 Patrick Mochel <mochel@osdl.org>
- */
-
-#include <xen/acpi.h>
-#include <xen/smp.h>
-#include <asm/processor.h>
-#include <asm/msr.h>
-#include <asm/debugreg.h>
-#include <asm/hvm/hvm.h>
-#include <asm/hvm/support.h>
-#include <asm/i387.h>
-#include <asm/xstate.h>
-#include <xen/hypercall.h>
-
-static unsigned long saved_fs_base, saved_gs_base, saved_kernel_gs_base;
-static uint64_t saved_xcr0;
-
-void save_rest_processor_state(void)
-{
-    saved_fs_base = rdfsbase();
-    saved_gs_base = rdgsbase();
-    rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
-
-    if ( cpu_has_xsave )
-        saved_xcr0 = get_xcr0();
-}
-
-
-void restore_rest_processor_state(void)
-{
-    load_system_tables();
-
-    /* Restore full CR4 (inc MCE) now that the IDT is in place. */
-    write_cr4(mmu_cr4_features);
-
-    wrfsbase(saved_fs_base);
-    wrgsbase(saved_gs_base);
-    wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
-
-    if ( cpu_has_xsave && !set_xcr0(saved_xcr0) )
-        BUG();
-
-    wrmsrl(MSR_IA32_CR_PAT, XEN_MSR_PAT);
-
-    mtrr_bp_restore();
-}
diff --git a/xen/arch/x86/acpi/wakeup_prot.S b/xen/arch/x86/acpi/wakeup_prot.S
index 0ce96e26a9..4dba6020a7 100644
--- a/xen/arch/x86/acpi/wakeup_prot.S
+++ b/xen/arch/x86/acpi/wakeup_prot.S
@@ -15,8 +15,6 @@ ENTRY(do_suspend_lowlevel)
         mov     %cr0, %rax
         mov     %rax, saved_cr0(%rip)
 
-        call    save_rest_processor_state
-
         /* enter sleep state physically */
         mov     $3, %edi
         call    acpi_enter_sleep_state
@@ -51,7 +49,7 @@ ENTRY(s3_resume)
         lretq
 1:
 
-        call restore_rest_processor_state
+        call    load_system_tables
 
 .Lsuspend_err:
         pop     %r15
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index 18c6638924..662e6bdd3c 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -91,6 +91,11 @@ trampoline_protmode_entry:
         and     %edi,%edx
         wrmsr
 1:
+        /* Set up PAT before enabling paging. */
+        mov     $XEN_MSR_PAT & 0xffffffff, %eax
+        mov     $XEN_MSR_PAT >> 32, %edx
+        mov     $MSR_IA32_CR_PAT, %ecx
+        wrmsr
 
         /* Set up EFER (Extended Feature Enable Register). */
         movl    $MSR_EFER,%ecx
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 11:17:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 11:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTkhx-00037t-It; Wed, 29 Apr 2020 11:16:53 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTkhw-00037o-3r
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 11:16:52 +0000
X-Inumbo-ID: ec974524-8a0a-11ea-992b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ec974524-8a0a-11ea-992b-12813bfff9fa;
 Wed, 29 Apr 2020 11:16:51 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C703AAB8F;
 Wed, 29 Apr 2020 11:16:49 +0000 (UTC)
Subject: Re: [PATCH] x86/S3: Drop {save,restore}_rest_processor_state()
 completely
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200429110903.15418-1-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <42c1a2ec-51a1-7b03-aea5-f8ffe80d6928@suse.com>
Date: Wed, 29 Apr 2020 13:16:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200429110903.15418-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 13:09, Andrew Cooper wrote:
> --- a/xen/arch/x86/boot/trampoline.S
> +++ b/xen/arch/x86/boot/trampoline.S
> @@ -91,6 +91,11 @@ trampoline_protmode_entry:
>          and     %edi,%edx
>          wrmsr
>  1:
> +        /* Set up PAT before enabling paging. */
> +        mov     $XEN_MSR_PAT & 0xffffffff, %eax
> +        mov     $XEN_MSR_PAT >> 32, %edx
> +        mov     $MSR_IA32_CR_PAT, %ecx
> +        wrmsr

Doesn't this also eliminate the need for cpu_init() doing this?
If you agree with that one also dropped
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 11:32:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 11:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTkx9-0004yp-7M; Wed, 29 Apr 2020 11:32:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTkx8-0004yk-RO
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 11:32:34 +0000
X-Inumbo-ID: 1dc41f1d-8a0d-11ea-992d-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1dc41f1d-8a0d-11ea-992d-12813bfff9fa;
 Wed, 29 Apr 2020 11:32:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588159953;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=rm10g/pmVmevI6nWsXuFqiMQ6fsjExpLtCzN2n+htn0=;
 b=CFHbj7wKwucufm9dChV3WGBglpHe7QXzSqDy9ZwMzTjHVt2ZZBYcIk5S
 EigxKID5V/ArPP6ZmohwDQlJ+kH4ntnf3RBLYeUbHy+WwTxHVmpNzoKVc
 gRPappx7H5BOu0playRP7/dxSnt+z3S29aT/BheYMgwrRlthaGwQ2EbIp Y=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Umv1e6mIv9aR8mAxOwSrXA9kGgUL7UNKO+HNgDRQBRUgsLtmUeLzg1Q7/er83xjh2oqVeefWJT
 fGdwsPSLU2f4tZV++3/Fxov9Jyh0PbxEtw/pODVrv79ey6dyj/jIpBhMvu8NCgKoaIj1wvjnFx
 xzBqQ52wU9KvCequpVpBImq65M698ZMjmg3iDxK19ElWE4k+c0d7pLRB4HH+OGOyQYDZ9iAcJJ
 RgS6RiFqHaVHZ6PNHKF3/aJKAczw2w6HIk8/6zKC9gqjlRn40Bk/lHoiNiGMRAN2cTWiZJc3wN
 E/k=
X-SBRS: 2.7
X-MesageID: 16744108
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,331,1583211600"; d="scan'208";a="16744108"
Subject: Re: [PATCH] x86/S3: Drop {save,restore}_rest_processor_state()
 completely
To: Jan Beulich <jbeulich@suse.com>
References: <20200429110903.15418-1-andrew.cooper3@citrix.com>
 <42c1a2ec-51a1-7b03-aea5-f8ffe80d6928@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <52bdc00f-7778-bd06-14e1-d5c6086466d3@citrix.com>
Date: Wed, 29 Apr 2020 12:32:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <42c1a2ec-51a1-7b03-aea5-f8ffe80d6928@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>, Roger
 Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 12:16, Jan Beulich wrote:
> On 29.04.2020 13:09, Andrew Cooper wrote:
>> --- a/xen/arch/x86/boot/trampoline.S
>> +++ b/xen/arch/x86/boot/trampoline.S
>> @@ -91,6 +91,11 @@ trampoline_protmode_entry:
>>          and     %edi,%edx
>>          wrmsr
>>  1:
>> +        /* Set up PAT before enabling paging. */
>> +        mov     $XEN_MSR_PAT & 0xffffffff, %eax
>> +        mov     $XEN_MSR_PAT >> 32, %edx
>> +        mov     $MSR_IA32_CR_PAT, %ecx
>> +        wrmsr
> Doesn't this also eliminate the need for cpu_init() doing this?
> If you agree with that one also dropped
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

That doesn't cover the BSP on either the legacy or EFI paths.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 11:36:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 11:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTl0e-00057S-PV; Wed, 29 Apr 2020 11:36:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTl0d-00057N-UE
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 11:36:11 +0000
X-Inumbo-ID: 9c4a368c-8a0d-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9c4a368c-8a0d-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 11:36:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=qjXpwEI8pmNqP61doaYY/e4MqEdfHra1eikNU+wk3zI=; b=KmRHl0ZpioNfHsiLHk3Way5Dd
 KpT62dy0PzKPM11VCVZACn4GLKo8C2HXwyN7//zYK2yrpk1jXQwzGSjPaeJAHhUcl+KZorfHzJbD6
 0EbO6VogFRquOHJR7f/PpPy6Kk4MB0OhZ5V8bbXRowjzMbRIYGLknnvHSVB/TYAcHTL3o=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTl0W-00089M-PF; Wed, 29 Apr 2020 11:36:04 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTl0W-0004sI-H4; Wed, 29 Apr 2020 11:36:04 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTl0W-00014y-GM; Wed, 29 Apr 2020 11:36:04 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149868-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149868: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore.2:fail:allowable
 linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=96c9a7802af7d500a582d89a8b864584fe878c1b
X-Osstest-Versions-That: linux=51184ae37e0518fd90cb437a2fbc953ae558cd0d
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 11:36:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149868 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149868/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     17 guest-saverestore.2      fail REGR. vs. 149854

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-examine      4 memdisk-try-append           fail  like 149840
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149854
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149854
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149854
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149854
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149854
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149854
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat    fail  like 149854
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149854
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149854
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                96c9a7802af7d500a582d89a8b864584fe878c1b
baseline version:
 linux                51184ae37e0518fd90cb437a2fbc953ae558cd0d

Last test of basis   149854  2020-04-28 10:51:07 Z    1 days
Testing same since   149868  2020-04-29 00:40:01 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Aharon Landau <aharonl@mellanox.com>
  Al Viro <viro@zeniv.linux.org.uk>
  Alaa Hleihel <alaa@mellanox.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Colin Ian King <colin.king@canonical.com>
  Dan Carpenter <dan.carpenter@oracle.com>
  David Howells <dhowells@redhat.com>
  Jason Gunthorpe <jgg@mellanox.com>
  Leon Romanovsky <leonro@mellanox.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Mike Marciniszyn <mike.marciniszyn@intel.com>
  Shiraz Saleem <shiraz.saleem@intel.com>
  Sudip Mukherjee <sudipm.mukherjee@gmail.com>
  Yishai Hadas <yishaih@mellanox.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   51184ae37e05..96c9a7802af7  96c9a7802af7d500a582d89a8b864584fe878c1b -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 11:47:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 11:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTlBT-00068E-Sh; Wed, 29 Apr 2020 11:47:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=UoNI=6N=gmail.com=wei.liu.xen@srs-us1.protection.inumbo.net>)
 id 1jTlBS-000689-RE
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 11:47:22 +0000
X-Inumbo-ID: 2f90ed68-8a0f-11ea-b9cf-bc764e2007e4
Received: from mail-wr1-f67.google.com (unknown [209.85.221.67])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2f90ed68-8a0f-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 11:47:22 +0000 (UTC)
Received: by mail-wr1-f67.google.com with SMTP id x18so2151042wrq.2
 for <xen-devel@lists.xenproject.org>; Wed, 29 Apr 2020 04:47:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-disposition:in-reply-to:user-agent;
 bh=sSZEYL8vziV8hz9ASR5iV4i9EF1ovhAMH5rPsBEzMD8=;
 b=ZgmigyJc3qsrLrBKHMMxEBsmWGl7a5BsI01I6S7/yVEP3Vy8C0z9hMSSAfgrW8LuoZ
 +jPO7UtcuAXzXZZW2njRiKtNoQEdStm6Ky0VLOGFRDKV+Ul++8Dkw83otluO2h1TETaJ
 EWg+HzDcPYa4aym+5kMM5FD0IBu25OOWXrC5j14GLF9uiciR8kJZoMVw1Aja47HFI+tv
 pGrIuDfA/tydfjxoF0aJvZtu7bshR35NDOX9nsuaDnCvIOUmRtHI9XKNyodW1nz3SCjG
 h83mY3zh3ylCOZrDzwZGYYoF6QXk3eOdkAR2MBS+mOxyGTq09ByZ2d9pVNvjAJB1rZeO
 QYRg==
X-Gm-Message-State: AGi0Pua9PdUzcTOl81d07YnCCdyqRaHjUf0GmliJgTD9/46GTNGWi1bB
 7oaFb0s+YgxpOVefohetSgc7T08S
X-Google-Smtp-Source: APiQypIn/09EinWnIz8JP1RZZ7lAR7qt45/pc9qtUkVeWe9FOrP+4dFRupvBVMQuvlmwmNVv8sWHcg==
X-Received: by 2002:adf:afdf:: with SMTP id y31mr38389936wrd.120.1588160840962; 
 Wed, 29 Apr 2020 04:47:20 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id h2sm7754246wmf.34.2020.04.29.04.47.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 29 Apr 2020 04:47:20 -0700 (PDT)
Date: Wed, 29 Apr 2020 11:47:18 +0000
From: Wei Liu <wl@xen.org>
To: Xen Development List <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/hyperv: stash and use the configured max VP index
Message-ID: <20200429114718.zclpy6r6sbxuo6ph@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <20200429104144.17816-1-liuwe@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200429104144.17816-1-liuwe@microsoft.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <liuwe@microsoft.com>, Wei Liu <wl@xen.org>,
 Paul Durrant <paul@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michael Kelley <mikelley@microsoft.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 29, 2020 at 11:41:44AM +0100, Wei Liu wrote:
> The value returned from CPUID is the maximum number for virtual
> processors supported by Hyper-V. It could be larger than the maximum
> number of virtual processors configured.
> 
> Stash the configured number into a variable and use it in calculations.
> 
> Signed-off-by: Wei Liu <liuwe@microsoft.com>
> ---
>  xen/arch/x86/guest/hyperv/hyperv.c  | 4 ++++
>  xen/arch/x86/guest/hyperv/private.h | 1 +
>  xen/arch/x86/guest/hyperv/tlb.c     | 2 +-
>  xen/arch/x86/guest/hyperv/util.c    | 2 +-
>  4 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c
> index 91a6782cd986..84221b751453 100644
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -33,6 +33,7 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
>  DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
>  DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
>  
> +unsigned int __read_mostly hv_max_vp_index;
>  static bool __read_mostly hcall_page_ready;
>  
>  static uint64_t generate_guest_id(void)
> @@ -143,6 +144,9 @@ static int setup_hypercall_pcpu_arg(void)
>      rdmsrl(HV_X64_MSR_VP_INDEX, vp_index_msr);
>      this_cpu(hv_vp_index) = vp_index_msr;
>  
> +    if ( vp_index_msr > hv_max_vp_index )
> +        hv_max_vp_index = vp_index_msr;
> +
>      return 0;
>  }
>  
> diff --git a/xen/arch/x86/guest/hyperv/private.h b/xen/arch/x86/guest/hyperv/private.h
> index 354fc7f685a7..fea3e291e944 100644
> --- a/xen/arch/x86/guest/hyperv/private.h
> +++ b/xen/arch/x86/guest/hyperv/private.h
> @@ -28,6 +28,7 @@
>  DECLARE_PER_CPU(void *, hv_input_page);
>  DECLARE_PER_CPU(void *, hv_vp_assist);
>  DECLARE_PER_CPU(unsigned int, hv_vp_index);
> +extern unsigned int hv_max_vp_index;
>  
>  static inline unsigned int hv_vp_index(unsigned int cpu)
>  {
> diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
> index 1d723d6ee679..0a44071481bd 100644
> --- a/xen/arch/x86/guest/hyperv/tlb.c
> +++ b/xen/arch/x86/guest/hyperv/tlb.c
> @@ -166,7 +166,7 @@ int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
>          {
>              unsigned int vpid = hv_vp_index(cpu);
>  
> -            if ( vpid >= ms_hyperv.max_vp_index )
> +            if ( vpid >= hv_max_vp_index )

I think the >= should be changed to > here.

Wei.

>              {
>                  local_irq_restore(irq_flags);
>                  return -ENXIO;
> diff --git a/xen/arch/x86/guest/hyperv/util.c b/xen/arch/x86/guest/hyperv/util.c
> index bec61c2afd87..2c5f421b7bd9 100644
> --- a/xen/arch/x86/guest/hyperv/util.c
> +++ b/xen/arch/x86/guest/hyperv/util.c
> @@ -33,7 +33,7 @@ int cpumask_to_vpset(struct hv_vpset *vpset,
>  {
>      int nr = 1;
>      unsigned int cpu, vcpu_bank, vcpu_offset;
> -    unsigned int max_banks = ms_hyperv.max_vp_index / 64;
> +    unsigned int max_banks = hv_max_vp_index / 64;
>  
>      /* Up to 64 banks can be represented by valid_bank_mask */
>      if ( max_banks > 64 )
> -- 
> 2.20.1
> 


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 12:29:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 12:29:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTlqF-0001cR-OW; Wed, 29 Apr 2020 12:29:31 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fvgr=6N=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTlqE-0001cM-Hr
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 12:29:30 +0000
X-Inumbo-ID: 11fe7332-8a15-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 11fe7332-8a15-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 12:29:29 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 55B39AEDD;
 Wed, 29 Apr 2020 12:29:27 +0000 (UTC)
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: Igor Druzhinin <igor.druzhinin@citrix.com>, Julien Grall
 <julien@xen.org>, Julien Grall <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
 <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
 <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <f80aff47-8617-8f59-0d34-bf0385128b62@suse.com>
Date: Wed, 29 Apr 2020 14:29:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.20 13:04, Igor Druzhinin wrote:
> On 29/04/2020 11:49, Jürgen Groß wrote:
>> On 29.04.20 12:39, Igor Druzhinin wrote:
>>> On 29/04/2020 10:22, Julien Grall wrote:
>>>> Hi Juergen,
>>>>
>>>> On 29/04/2020 06:51, Jürgen Groß wrote:
>>>>>
>>>>> Recreating the event channel would be fine, but I don't see why it
>>>>> would ever be needed. And XS_INTRODUCE is called only at domain creation
>>>>> time today, so there is obviously no need for repeating this call.
>>>>>
>>>>> Maybe the idea was to do this after sending a XS_RESUME command, which
>>>>> isn't used anywhere in Xen and is another part of Xenstore which doesn't
>>>>> make any sense today.
>>>>
>>>> Commit f6cc37ea8ac71385b60507c034519f304da75f4c "tools/oxenstored: port XS_INTRODUCE evtchn rebind function from cxenstored" added the exact same behavior in the OCaml XenStored last year.
>>>>
>>>> This was introduced 12 years after C XenStored, so surely someone think this is useful. We should check why this was introduced in OCaml XenStored (I have CCed the author of the patch).
>>>>
>>>> If we still think this is not useful, then you should add an explanation in the commit message why the two implementations diverge and possibly update the spec.
>>>
>>> Thanks for CC, Julien.
>>>
>>> We indeed already use this functionality in our toolstack for guest kdump
>>> functions. It's not possible in XAPI to adopt libxl model where almost everything
>>> is restarted for a domain entering kdump, so we have to use this message to
>>> rebind xenstore evtchn after soft reset without shutting down backends and
>>> recreating the whole subtree (frontends reconnect fine after that).
>>>
>>> We obviously only require it for now to be present in oxenstored only.
>>> Please don't remove this functionality if possible.
>>
>> If I read handling in libxl correctly, in the soft reset case XS_RELEASE
>> is issued before doing another XS_INTRODUCE. XS_RELEASE will result in
>> xenstored throwing away its related struct domain, so XS_INTRODUCE will
>> be possible again.
> 
>  From what I remember it was not possible to keep xenstored data for a domain
> and at the same time perform release-introduce cycle (at least in oxenstored).
> It also involved firing @releaseDomain which caused havoc in other part of
> the toolstack.

Wei, Ian, can you please tell me where I'm wrong?

A soft reset should restart the domain in a clean state. AFAIK libxl is
handling that by doing kind of in-place save-restore, including calling
xs_release_domain() and later xs_introduce_domain(). This should result
in xenstored throwing away all state it has regarding the domain and
then restarting with a new (internal) domain instance.

Is XAPI doing soft reset differently? Why should there be a need for
keeping xenstored data across a soft reset?


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 12:29:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 12:29:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTlqc-0001eJ-1P; Wed, 29 Apr 2020 12:29:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QE4t=6N=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jTlqb-0001e9-1n
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 12:29:53 +0000
X-Inumbo-ID: 1fb4de8a-8a15-11ea-993d-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1fb4de8a-8a15-11ea-993d-12813bfff9fa;
 Wed, 29 Apr 2020 12:29:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:
 References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=xzqoS5LBTFFcm6HUrxQtenW6a+6Xm50klkOFRqNlNPg=; b=E+NHz1VRrwfPDDKQLqQ13yObus
 9dcCdcYMLBfukGC6HRBGVKyR0abzNWlj3YS6R7r6XkA2FBsszXmmgMgtaw6fttdDkGFCUbGh2YutD
 GS1r5SPZw/e9bF81UqH2h7ZdJUAudYZHuByfj9kC/BKg276EpoIBCCjkjuBj0I5IBlZg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jTlqZ-0000jO-5C; Wed, 29 Apr 2020 12:29:51 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=s3-prod-r2d2-p7995.iad7.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jTlqY-0007FW-QQ; Wed, 29 Apr 2020 12:29:51 +0000
Message-ID: <40644d63e00a10636943f6322707c0ad6a73e11c.camel@xen.org>
Subject: Re: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Date: Wed, 29 Apr 2020 13:29:48 +0100
In-Reply-To: <ec318c48-41c3-5cbf-e03e-8838d9f488ba@suse.com>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
 <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
 <9df9c5163fde5d25ceb756b20714c58be93b2c6c.camel@xen.org>
 <c33dcaee9c8796da8816de9168f91ce90de61fc5.camel@xen.org>
 <e18871ea997a304394adbbc92e724ae0ec56d87a.camel@xen.org>
 <ec318c48-41c3-5cbf-e03e-8838d9f488ba@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

(Looks like other patches in this series have been merged. Replying to
this one only.)

From: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 5 Feb 2019 16:32:54 +0000
Subject: [PATCH] x86/pv: map and unmap page tables in
mark_pv_pt_pages_rdonly

Also, clean up the initialisation of plXe.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
---
 xen/arch/x86/pv/dom0_build.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/pv/dom0_build.c
b/xen/arch/x86/pv/dom0_build.c
index abfbe5f436..3522eb0114 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -49,18 +49,11 @@ static __init void mark_pv_pt_pages_rdonly(struct
domain *d,
 {
     unsigned long count;
     struct page_info *page;
-    l4_pgentry_t *pl4e;
-    l3_pgentry_t *pl3e;
-    l2_pgentry_t *pl2e;
-    l1_pgentry_t *pl1e;
-
-    pl4e = l4start + l4_table_offset(vpt_start);
-    pl3e = l4e_to_l3e(*pl4e);
-    pl3e += l3_table_offset(vpt_start);
-    pl2e = l3e_to_l2e(*pl3e);
-    pl2e += l2_table_offset(vpt_start);
-    pl1e = l2e_to_l1e(*pl2e);
-    pl1e += l1_table_offset(vpt_start);
+    l4_pgentry_t *pl4e = l4start + l4_table_offset(vpt_start);
+    l3_pgentry_t *pl3e = map_l3t_from_l4e(*pl4e) +
l3_table_offset(vpt_start);
+    l2_pgentry_t *pl2e = map_l2t_from_l3e(*pl3e) +
l2_table_offset(vpt_start);
+    l1_pgentry_t *pl1e = map_l1t_from_l2e(*pl2e) +
l1_table_offset(vpt_start);
+
     for ( count = 0; count < nr_pt_pages; count++ )
     {
         l1e_remove_flags(*pl1e, _PAGE_RW);
@@ -85,12 +78,21 @@ static __init void mark_pv_pt_pages_rdonly(struct
domain *d,
             if ( !((unsigned long)++pl2e & (PAGE_SIZE - 1)) )
             {
                 if ( !((unsigned long)++pl3e & (PAGE_SIZE - 1)) )
-                    pl3e = l4e_to_l3e(*++pl4e);
-                pl2e = l3e_to_l2e(*pl3e);
+                {
+                    /* Need to unmap the page before the increment. */
+                    unmap_domain_page(pl3e - 1);
+                    pl3e = map_l3t_from_l4e(*++pl4e);
+                }
+                unmap_domain_page(pl2e - 1);
+                pl2e = map_l2t_from_l3e(*pl3e);
             }
-            pl1e = l2e_to_l1e(*pl2e);
+            unmap_domain_page(pl1e - 1);
+            pl1e = map_l1t_from_l2e(*pl2e);
         }
     }
+    unmap_domain_page(pl1e);
+    unmap_domain_page(pl2e);
+    unmap_domain_page(pl3e);
 }
 
 static __init void setup_pv_physmap(struct domain *d, unsigned long
pgtbl_pfn,
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 12:35:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 12:35:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTlvT-0002fc-Ny; Wed, 29 Apr 2020 12:34:55 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTlvS-0002fU-Dd
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 12:34:54 +0000
X-Inumbo-ID: cf212721-8a15-11ea-993e-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cf212721-8a15-11ea-993e-12813bfff9fa;
 Wed, 29 Apr 2020 12:34:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588163687;
 h=subject:from:to:cc:references:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=9k33F4hgR+V4F3y/9N2bCfa6gb428rr3sfTfFTQyvSM=;
 b=ZMTdjQEu6bUmkAYDo/Dw5Q1AID6paoicCLhjzXwhoFMnOjnNRK8n9YYW
 sqPb9nSsJIOqjVKPdwsfbMrRtoEu368+/flOa594MaRAYwNCHPNKeYoF5
 y/xXp87f9yzW3FoO50gHb+pEAGKIoDdJID9tEAwZbjoKzfOAOULOKL4lM s=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: pZvIiy9Omj3s7gRbP5t5GHyKCL2lkLtdfHUx5DQu2JH6lhg4euykVWArxXFitrZ4e9Nil9B+ie
 4At2nQrn1TOpG2WoGa0p3h+4/idmHFqDZsgdYPil9jL977TS4cW5XOag1iUp7B+VFO/gfGBCrQ
 kbyapf8EmMwvg52GEpqFDSiHtC53ZhvdafP1GostWIMoUZFcTOC6BrJtml0D45knvRhWQR1oVc
 9Pmj3vyUEMYkh4tmUvd/jtEhsbfuq9ZLIL/4HcChyHmeCTmqVc72YeG2KV7iNqqSauF6MRhbDl
 kSo=
X-SBRS: 2.7
X-MesageID: 16421262
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16421262"
Subject: Re: [PATCH] mini-os: Avoid segfaults in tc{g,s}etattr
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jason Andryuk <jandryuk@gmail.com>, Wei Liu <wl@xen.org>
References: <3ed7eb87-070c-28ea-4f8a-aa4421cea93a@citrix.com>
 <5ea8173d.1c69fb81.915ba.8400@mx.google.com>
 <c242b963-ae80-1ca0-9b4d-fe2c8f66b6a2@citrix.com>
Message-ID: <34cc563f-9e05-b55c-54f4-55104d2d42b5@citrix.com>
Date: Wed, 29 Apr 2020 13:34:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <c242b963-ae80-1ca0-9b4d-fe2c8f66b6a2@citrix.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: minios-devel@lists.xenproject.org, samuel.thibault@ens-lyon.org,
 JBeulich@suse.com, Stefan Bader <stefan.bader@canonical.com>,
 xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28/04/2020 12:55, Andrew Cooper wrote:
>> Below is what I was preparing to submit as a patch.  So, yes it hacks around
>> it, but it isn't messy.
>>
>> ---
>> Disable fcf-protection to build working binaries
>>
>> Ubuntu gcc-9 enables -fcf-protection by default, which conflicts with
>> -mindirect-branch=extern and prevents building the hypervisor with
>> CONFIG_INDIRECT_THUNK:
>> xmalloc.h:81:1: error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not
>> compatible
>>
>> Stefan Bader also noticed that build32.mk requires -fcf-protection=none
>> or else the hypervisor will not boot.
>> https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1863260  Similarly,
>> rombios reboots almost immediately without -fcf-protection=none.  Both
>> of those can be handled by setting it in EMBEDDED_EXTRA_CFLAGS.
>>
>> CC: Stefan Bader <stefan.bader@canonical.com>
>> Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
> Sadly, this isn't really appropriate.  We specifically do want to use
> both -fcf-protection and -mindirect-branch=thunk-extern together, when
> GCC isn't broken.
>
> Overriding -fcf-protection is ok but only when we're certain we've got a
> buggy GCC, so that when this bug is fixed, we can return to sensible
> behaviour.

GCC has been adjusted on master
(https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9be3bb2c0a258fd6a7d3d05d232a21930c757d3c)
and the gcc-9 branch
(https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a03efb266fcbf4a01285fff871a5bfe5caac4944). 
This should be fixed for GCC 10 and 9.4

I checked the resulting hypervisor build with both -fcf-protection and
retpolines, and it works fine.

The question now is what to do all the buggy GCCs out there.  We can
either ignore the problem and it will eventually go away, or spot the
problematic compiler and clobber -fcf-protection.

We also need to see what is wrong with RomBIOS, because that is weird. 
However, we should not be interfering with the HOSTCC settings.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 12:50:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 12:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmA5-0003kl-4Y; Wed, 29 Apr 2020 12:50:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xGEm=6N=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jTmA3-0003kg-Vc
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 12:50:00 +0000
X-Inumbo-ID: eebc625a-8a17-11ea-9940-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id eebc625a-8a17-11ea-9940-12813bfff9fa;
 Wed, 29 Apr 2020 12:49:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588164598;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=3zT7Oma2mWJOk67Ve3hPzUQDxqWMW4fWXMq8ea7erOs=;
 b=aTE7bkZRvVNLCT3t/CQ5bYW98ebOJ8MJ3+mKQWXGr62c2DsvVepKrGN/
 0DM1SUsMpIwXNuTXV485C7l1Spf9/kkl+vyv/8Hk3v4lpOuh9T0nbGqqT
 fO1YaKR2NeKuPqSNI1FzOku/lFVuvzjT6riStBWgqg0xanw60DCUs7W3t o=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: HmKz6e68QJUTs3S+JTQKPrrkm0JvAt+reZFXgTklAaSLR/Q/Wa51AnAlWh94ClSw8TB0MBC5AO
 qa4aRAaFpR5AZQ5qbe3WpK70mk2UM419NhzaSbVANKjMzLmgBSOSFZWWi3MFYYGabu2i1bd/Fg
 Iq4CSNRR1aQfITYxvvm6vSNi/ZDvBCGs5UNO8gXnCVuSd7MANtzGgxmENjHZ9GLI9zBlZPGrTc
 XQP+7zTTNsy2IsDWGHAjqLLi9e0Q5Y93HiU9Qh54Bh+K2bHDxN9bkRqblvPaz2vpCra2cnsomB
 bMA=
X-SBRS: 2.7
X-MesageID: 16748867
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16748867"
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>, Julien Grall
 <julien@xen.org>, Julien Grall <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
 <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
 <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
 <f80aff47-8617-8f59-0d34-bf0385128b62@suse.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <a23c3d72-f5c8-5c3f-2c2f-5a9ca1065d1f@citrix.com>
Date: Wed, 29 Apr 2020 13:49:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <f80aff47-8617-8f59-0d34-bf0385128b62@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Paul Durrant <paul@xen.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 13:29, Jürgen Groß wrote:
> On 29.04.20 13:04, Igor Druzhinin wrote:
>> On 29/04/2020 11:49, Jürgen Groß wrote:
>>> On 29.04.20 12:39, Igor Druzhinin wrote:
>>>> On 29/04/2020 10:22, Julien Grall wrote:
>>>>> Hi Juergen,
>>>>>
>>>>> On 29/04/2020 06:51, Jürgen Groß wrote:
>>>>>>
>>>>>> Recreating the event channel would be fine, but I don't see why it
>>>>>> would ever be needed. And XS_INTRODUCE is called only at domain creation
>>>>>> time today, so there is obviously no need for repeating this call.
>>>>>>
>>>>>> Maybe the idea was to do this after sending a XS_RESUME command, which
>>>>>> isn't used anywhere in Xen and is another part of Xenstore which doesn't
>>>>>> make any sense today.
>>>>>
>>>>> Commit f6cc37ea8ac71385b60507c034519f304da75f4c "tools/oxenstored: port XS_INTRODUCE evtchn rebind function from cxenstored" added the exact same behavior in the OCaml XenStored last year.
>>>>>
>>>>> This was introduced 12 years after C XenStored, so surely someone think this is useful. We should check why this was introduced in OCaml XenStored (I have CCed the author of the patch).
>>>>>
>>>>> If we still think this is not useful, then you should add an explanation in the commit message why the two implementations diverge and possibly update the spec.
>>>>
>>>> Thanks for CC, Julien.
>>>>
>>>> We indeed already use this functionality in our toolstack for guest kdump
>>>> functions. It's not possible in XAPI to adopt libxl model where almost everything
>>>> is restarted for a domain entering kdump, so we have to use this message to
>>>> rebind xenstore evtchn after soft reset without shutting down backends and
>>>> recreating the whole subtree (frontends reconnect fine after that).
>>>>
>>>> We obviously only require it for now to be present in oxenstored only.
>>>> Please don't remove this functionality if possible.
>>>
>>> If I read handling in libxl correctly, in the soft reset case XS_RELEASE
>>> is issued before doing another XS_INTRODUCE. XS_RELEASE will result in
>>> xenstored throwing away its related struct domain, so XS_INTRODUCE will
>>> be possible again.
>>
>>  From what I remember it was not possible to keep xenstored data for a domain
>> and at the same time perform release-introduce cycle (at least in oxenstored).
>> It also involved firing @releaseDomain which caused havoc in other part of
>> the toolstack.
> 
> Wei, Ian, can you please tell me where I'm wrong?
> 
> A soft reset should restart the domain in a clean state. AFAIK libxl is
> handling that by doing kind of in-place save-restore, including calling
> xs_release_domain() and later xs_introduce_domain(). This should result
> in xenstored throwing away all state it has regarding the domain and
> then restarting with a new (internal) domain instance.
> 
> Is XAPI doing soft reset differently? Why should there be a need for
> keeping xenstored data across a soft reset?

Yes, XAPI is doing soft reset differently from libxl. You need to keep xenstore
data to at least keep backends working without the need to reinitialize them 
before entering kdump kernel. We do the same thing while entering crash kernel
in Windows after BSOD (CC Paul as he recommended this approach).
There are other reasons to not reset xenstore data.

I considered XS_INTRODUCE functionality to be part of xenstored ABI and we built
a lot of infrastructure on top of that. So I don't think it could be easily removed now.

Igor


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 12:56:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 12:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmGM-0004ha-Um; Wed, 29 Apr 2020 12:56:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/uTc=6N=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTmGL-0004hV-Co
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 12:56:29 +0000
X-Inumbo-ID: d6e2baa2-8a18-11ea-ae69-bc764e2007e4
Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d6e2baa2-8a18-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 12:56:28 +0000 (UTC)
Received: by mail-wr1-x442.google.com with SMTP id g13so2382298wrb.8
 for <xen-devel@lists.xenproject.org>; Wed, 29 Apr 2020 05:56:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=xdsgoWXumKd5PBD8fAL20/Hh07hdmUgSfJ8ZmCCGikw=;
 b=HPLWJqvFFNQ5DjEe2HHgWA1st14oyE9VJz7ym5OIoA2MAMNk5ACj9tra/96/GHeotE
 An3VmN9ouRIGU69IcyGYHHG8Xi1xtZZlGWKYOWamTTAT0rqZqkcbkFffoifefvOn7xaf
 Fvqk/bUnBqdX3pbu7OyyRd6rM8itrzFbl4CyLiIKBSup6IjbCCBMyT7o+eFj5ltCTFTy
 U/dcl+Az2v981qYIo+sriqqlSg03v147TXW7+HeLUjOeX7Z8rfL9iqTBQZktu71elJId
 G70GL79sICNrhay0uS1ejB+OOKTNZ24UleDssOQPsH+3zDzlNDyj4XALawnLEdXOmXgn
 2iPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=xdsgoWXumKd5PBD8fAL20/Hh07hdmUgSfJ8ZmCCGikw=;
 b=MfTdhB2qZvlfLwhhPD7gR982qx+XnKXubNaTtTNgdMSfevz6qCVFQJz7B9EffFFyWc
 MGIedhR0IjJyFr9MJv4UDZouhkRWaJuTIDzY0fZkJCirpuxJByAcd8esGqNfm0ju9wZz
 IsGWys51CL92WWxLiv01hzgDvxVYrh9D+lCl46CfkKfcO92yKE3Bi7wnwgghLDyZYW0J
 pXo1UaN0Ui0qIyTxlMzVfpDSVECIhOHJICQmfzSjXeiENKn8QbZzYZ4TGgfYi3jPy4pv
 gtFYCx1Z5JiuosAZ17MPUTiMDWlEDFM09MyWATJnKhVwDH1H3X33p7aLFaCUTlN8lGZY
 Yy6g==
X-Gm-Message-State: AGi0PuaWF/aKqXTlQwLI/JepZuszicQlZAerKIUlmmjWzyLC/f76xF83
 Sh78/er1mnKflfjWhaQUuug=
X-Google-Smtp-Source: APiQypLyVordswB8gLPg0rRFuxldP65DGiHcAgq2gwivzldHpn2I8ahk8Lo/eBuqi7xY+Q+LiDuY1w==
X-Received: by 2002:adf:ee91:: with SMTP id b17mr39157104wro.109.1588164987260; 
 Wed, 29 Apr 2020 05:56:27 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id v1sm30936382wrv.19.2020.04.29.05.56.25
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 29 Apr 2020 05:56:26 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Igor Druzhinin'" <igor.druzhinin@citrix.com>,
 =?UTF-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= <jgross@suse.com>,
 "'Julien Grall'" <julien@xen.org>,
 "'Julien Grall'" <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
 <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
 <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
 <f80aff47-8617-8f59-0d34-bf0385128b62@suse.com>
 <a23c3d72-f5c8-5c3f-2c2f-5a9ca1065d1f@citrix.com>
In-Reply-To: <a23c3d72-f5c8-5c3f-2c2f-5a9ca1065d1f@citrix.com>
Subject: RE: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
Date: Wed, 29 Apr 2020 13:56:24 +0100
Message-ID: <000001d61e25$97f86530$c7e92f90$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQI5DSqNP/4D/SMDjCtgzueaLTX80QC4bkXHAbDXqJ8CsNUfVQLT/QPPATMMdVoBnbvEPwMR4MQ0ANMkKK2nVRCVUA==
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'xen-devel' <xen-devel@lists.xenproject.org>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>, 'Wei Liu' <wl@xen.org>,
 andrew.cooper3@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Igor Druzhinin <igor.druzhinin@citrix.com>
> Sent: 29 April 2020 13:50
> To: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>; Julien Grall =
<julien@xen.org>; Julien Grall
> <julien.grall.oss@gmail.com>
> Cc: xen-devel <xen-devel@lists.xenproject.org>; Ian Jackson =
<ian.jackson@eu.citrix.com>; Wei Liu
> <wl@xen.org>; andrew.cooper3@citrix.com; Paul Durrant <paul@xen.org>
> Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring =
page in xensotred
>=20
> On 29/04/2020 13:29, J=C3=BCrgen Gro=C3=9F wrote:
> > On 29.04.20 13:04, Igor Druzhinin wrote:
> >> On 29/04/2020 11:49, J=C3=BCrgen Gro=C3=9F wrote:
> >>> On 29.04.20 12:39, Igor Druzhinin wrote:
> >>>> On 29/04/2020 10:22, Julien Grall wrote:
> >>>>> Hi Juergen,
> >>>>>
> >>>>> On 29/04/2020 06:51, J=C3=BCrgen Gro=C3=9F wrote:
> >>>>>>
> >>>>>> Recreating the event channel would be fine, but I don't see why =
it
> >>>>>> would ever be needed. And XS_INTRODUCE is called only at domain =
creation
> >>>>>> time today, so there is obviously no need for repeating this =
call.
> >>>>>>
> >>>>>> Maybe the idea was to do this after sending a XS_RESUME =
command, which
> >>>>>> isn't used anywhere in Xen and is another part of Xenstore =
which doesn't
> >>>>>> make any sense today.
> >>>>>
> >>>>> Commit f6cc37ea8ac71385b60507c034519f304da75f4c =
"tools/oxenstored: port XS_INTRODUCE evtchn
> rebind function from cxenstored" added the exact same behavior in the =
OCaml XenStored last year.
> >>>>>
> >>>>> This was introduced 12 years after C XenStored, so surely =
someone think this is useful. We
> should check why this was introduced in OCaml XenStored (I have CCed =
the author of the patch).
> >>>>>
> >>>>> If we still think this is not useful, then you should add an =
explanation in the commit message
> why the two implementations diverge and possibly update the spec.
> >>>>
> >>>> Thanks for CC, Julien.
> >>>>
> >>>> We indeed already use this functionality in our toolstack for =
guest kdump
> >>>> functions. It's not possible in XAPI to adopt libxl model where =
almost everything
> >>>> is restarted for a domain entering kdump, so we have to use this =
message to
> >>>> rebind xenstore evtchn after soft reset without shutting down =
backends and
> >>>> recreating the whole subtree (frontends reconnect fine after =
that).
> >>>>
> >>>> We obviously only require it for now to be present in oxenstored =
only.
> >>>> Please don't remove this functionality if possible.
> >>>
> >>> If I read handling in libxl correctly, in the soft reset case =
XS_RELEASE
> >>> is issued before doing another XS_INTRODUCE. XS_RELEASE will =
result in
> >>> xenstored throwing away its related struct domain, so XS_INTRODUCE =
will
> >>> be possible again.
> >>
> >>  From what I remember it was not possible to keep xenstored data =
for a domain
> >> and at the same time perform release-introduce cycle (at least in =
oxenstored).
> >> It also involved firing @releaseDomain which caused havoc in other =
part of
> >> the toolstack.
> >
> > Wei, Ian, can you please tell me where I'm wrong?
> >
> > A soft reset should restart the domain in a clean state. AFAIK libxl =
is
> > handling that by doing kind of in-place save-restore, including =
calling
> > xs_release_domain() and later xs_introduce_domain(). This should =
result
> > in xenstored throwing away all state it has regarding the domain and
> > then restarting with a new (internal) domain instance.
> >
> > Is XAPI doing soft reset differently? Why should there be a need for
> > keeping xenstored data across a soft reset?
>=20
> Yes, XAPI is doing soft reset differently from libxl. You need to keep =
xenstore
> data to at least keep backends working without the need to =
reinitialize them
> before entering kdump kernel. We do the same thing while entering =
crash kernel
> in Windows after BSOD (CC Paul as he recommended this approach).

IIRC I recommended not involving Xen or the toolstack in entering the =
crash kernel... they don't need to know. Windows quite happily enters =
its crash kernel, rebuilds its Xen interfaces and re-attaches to PV =
backends without any external intervention.

  Paul

> There are other reasons to not reset xenstore data.
>=20
> I considered XS_INTRODUCE functionality to be part of xenstored ABI =
and we built
> a lot of infrastructure on top of that. So I don't think it could be =
easily removed now.
>=20
> Igor



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:06:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:06:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmQD-0005kz-2E; Wed, 29 Apr 2020 13:06:41 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTmQB-0005ku-5l
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:06:39 +0000
X-Inumbo-ID: 424e8bc7-8a1a-11ea-9943-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 424e8bc7-8a1a-11ea-9943-12813bfff9fa;
 Wed, 29 Apr 2020 13:06:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588165598;
 h=from:to:cc:subject:date:message-id:in-reply-to:
 references:mime-version:content-transfer-encoding;
 bh=EcAqKbxyIDlbEFV0rEwU3rkviPU5aoTqDIu39pAVTWc=;
 b=JZg32YrpWzv+EhqmUi2uhRa2jwjkP160+tWEolBShqflfUfLvakGr+qG
 gy0g+dsKJWRt78baJK8bN/6bCbsrhWb81GFEXWDsY/Qf5uL39aVGZ9dLh
 bqHSP6puMNltC6SGjP3+kaaHBg8NSk572qgB5OibxjoyUXUHraO45Lg2X M=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: AKsluUFstkbhSrqP+6s5WH75u7kb+Mb7KKRVzjqK5yTZghRUaJRXucU0bmWEhmI91Fy23QG0cn
 5OenJbw0OYKmcFjcdC8+17n6aejtcyFlA1eUcLGqAUbQ64eY4tzhR82h8U39b/ThmvmK3xrNZn
 oFXja4mr7FTExXCbsiUm/19E5ZK54WngTK0kuZmzEClb4tfdVd7GCCfHqU6Pra1CfEHHc8vLru
 rqW0szwy4+vBoWsrxXkJoqAi5DGS+I5TbRkILvsx5Q38pcv/JeC5NPMJebj7nke61cFcVp9LGP
 yp8=
X-SBRS: 2.7
X-MesageID: 16692388
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16692388"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH v2 1/3] x86/pv: Options to disable and/or compile out 32bit PV
 support
Date: Wed, 29 Apr 2020 14:06:31 +0100
Message-ID: <20200429130631.6018-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
In-Reply-To: <20200417155004.16806-2-andrew.cooper3@citrix.com>
References: <20200417155004.16806-2-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is the start of some performance and security-hardening improvements,
based on the fact that 32bit PV guests are few and far between these days.

Ring1 is full of architectural corner cases, such as counting as supervisor
from a paging point of view.  This accounts for a substantial performance hit
on processors from the last 8 years (adjusting SMEP/SMAP on every privilege
transition), and the gap is only going to get bigger with new hardware
features.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>

v2:
 * Fix typos, __init
 * Introduce no_config_param() wrapper
---
 docs/misc/xen-command-line.pandoc | 12 +++++++++++-
 xen/arch/x86/Kconfig              | 16 ++++++++++++++++
 xen/arch/x86/pv/domain.c          | 34 ++++++++++++++++++++++++++++++++++
 xen/arch/x86/setup.c              |  9 +++++++--
 xen/include/asm-x86/pv/domain.h   |  6 ++++++
 xen/include/xen/param.h           |  9 +++++++++
 6 files changed, 83 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index acd0b3d994..ee12b0f53f 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1694,7 +1694,17 @@ The following resources are available:
     CDP, one COS will corespond two CBMs other than one with CAT, due to the
     sum of CBMs is fixed, that means actual `cos_max` in use will automatically
     reduce to half when CDP is enabled.
-	
+
+### pv
+    = List of [ 32=<bool> ]
+
+    Applicability: x86
+
+Controls for aspects of PV guest support.
+
+*   The `32` boolean controls whether 32bit PV guests can be created.  It
+    defaults to `true`, and is ignored when `CONFIG_PV32` is compiled out.
+
 ### pv-linear-pt (x86)
 > `= <boolean>`
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index a69be983d6..96432f1f69 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -49,6 +49,22 @@ config PV
 
 	  If unsure, say Y.
 
+config PV32
+	bool "Support for 32bit PV guests"
+	depends on PV
+	default y
+	---help---
+	  The 32bit PV ABI uses Ring1, an area of the x86 architecture which
+	  was deprecated and mostly removed in the AMD64 spec.  As a result,
+	  it occasionally conflicts with newer x86 hardware features, causing
+	  overheads for Xen to maintain backwards compatibility.
+
+	  People may wish to disable 32bit PV guests for attack surface
+	  reduction, or performance reasons.  Backwards compatibility can be
+	  provided via the PV Shim mechanism.
+
+	  If unsure, say Y.
+
 config PV_LINEAR_PT
        bool "Support for PV linear pagetables"
        depends on PV
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 43da5c179f..3579dc063e 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -16,6 +16,38 @@
 #include <asm/pv/domain.h>
 #include <asm/shadow.h>
 
+#ifdef CONFIG_PV32
+int8_t __read_mostly opt_pv32 = -1;
+#endif
+
+static __init int parse_pv(const char *s)
+{
+    const char *ss;
+    int val, rc = 0;
+
+    do {
+        ss = strchr(s, ',');
+        if ( !ss )
+            ss = strchr(s, '\0');
+
+        if ( (val = parse_boolean("32", s, ss)) >= 0 )
+        {
+#ifdef CONFIG_PV32
+            opt_pv32 = val;
+#else
+            no_config_param("PV32", "pv", s, ss);
+#endif
+        }
+        else
+            rc = -EINVAL;
+
+        s = ss + 1;
+    } while ( *ss );
+
+    return rc;
+}
+custom_param("pv", parse_pv);
+
 static __read_mostly enum {
     PCID_OFF,
     PCID_ALL,
@@ -174,6 +206,8 @@ int switch_compat(struct domain *d)
 
     BUILD_BUG_ON(offsetof(struct shared_info, vcpu_info) != 0);
 
+    if ( !opt_pv32 )
+        return -EOPNOTSUPP;
     if ( is_hvm_domain(d) || domain_tot_pages(d) != 0 )
         return -EACCES;
     if ( is_pv_32bit_domain(d) )
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index eb56d78c2f..9e9576344c 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -53,6 +53,7 @@
 #include <asm/spec_ctrl.h>
 #include <asm/guest.h>
 #include <asm/microcode.h>
+#include <asm/pv/domain.h>
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool __initdata opt_nosmp;
@@ -1870,8 +1871,12 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
     {
         snprintf(s, sizeof(s), "xen-%d.%d-x86_64 ", major, minor);
         safe_strcat(*info, s);
-        snprintf(s, sizeof(s), "xen-%d.%d-x86_32p ", major, minor);
-        safe_strcat(*info, s);
+
+        if ( opt_pv32 )
+        {
+            snprintf(s, sizeof(s), "xen-%d.%d-x86_32p ", major, minor);
+            safe_strcat(*info, s);
+        }
     }
     if ( hvm_enabled )
     {
diff --git a/xen/include/asm-x86/pv/domain.h b/xen/include/asm-x86/pv/domain.h
index 7a69bfb303..df9716ff26 100644
--- a/xen/include/asm-x86/pv/domain.h
+++ b/xen/include/asm-x86/pv/domain.h
@@ -23,6 +23,12 @@
 
 #include <xen/sched.h>
 
+#ifdef CONFIG_PV32
+extern int8_t opt_pv32;
+#else
+# define opt_pv32 false
+#endif
+
 /*
  * PCID values for the address spaces of 64-bit pv domains:
  *
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index d4578cd27f..a1dc3ba8f0 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -127,4 +127,13 @@ extern const struct kernel_param __param_start[], __param_end[];
     string_param(_name, _var); \
     string_runtime_only_param(_name, _var)
 
+static inline void no_config_param(const char *cfg, const char *param,
+                                   const char *s, const char *e)
+{
+    int len = e ? ({ ASSERT(e >= s); e - s; }) : strlen(s);
+
+    printk(XENLOG_INFO "CONFIG_%s disabled - ignoring '%s=%*s' setting\n",
+           cfg, param, len, s);
+}
+
 #endif /* _XEN_PARAM_H */
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:06:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmQQ-0005la-Ak; Wed, 29 Apr 2020 13:06:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fvgr=6N=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jTmQP-0005lP-3a
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:06:53 +0000
X-Inumbo-ID: 4a4d6b09-8a1a-11ea-9943-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4a4d6b09-8a1a-11ea-9943-12813bfff9fa;
 Wed, 29 Apr 2020 13:06:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E4468ACD0;
 Wed, 29 Apr 2020 13:06:49 +0000 (UTC)
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: Igor Druzhinin <igor.druzhinin@citrix.com>, Julien Grall
 <julien@xen.org>, Julien Grall <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
 <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
 <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
 <f80aff47-8617-8f59-0d34-bf0385128b62@suse.com>
 <a23c3d72-f5c8-5c3f-2c2f-5a9ca1065d1f@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <0f553a2e-9541-8d47-c354-0e8273b4b783@suse.com>
Date: Wed, 29 Apr 2020 15:06:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a23c3d72-f5c8-5c3f-2c2f-5a9ca1065d1f@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Paul Durrant <paul@xen.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.20 14:49, Igor Druzhinin wrote:
> On 29/04/2020 13:29, Jürgen Groß wrote:
>> On 29.04.20 13:04, Igor Druzhinin wrote:
>>> On 29/04/2020 11:49, Jürgen Groß wrote:
>>>> On 29.04.20 12:39, Igor Druzhinin wrote:
>>>>> On 29/04/2020 10:22, Julien Grall wrote:
>>>>>> Hi Juergen,
>>>>>>
>>>>>> On 29/04/2020 06:51, Jürgen Groß wrote:
>>>>>>>
>>>>>>> Recreating the event channel would be fine, but I don't see why it
>>>>>>> would ever be needed. And XS_INTRODUCE is called only at domain creation
>>>>>>> time today, so there is obviously no need for repeating this call.
>>>>>>>
>>>>>>> Maybe the idea was to do this after sending a XS_RESUME command, which
>>>>>>> isn't used anywhere in Xen and is another part of Xenstore which doesn't
>>>>>>> make any sense today.
>>>>>>
>>>>>> Commit f6cc37ea8ac71385b60507c034519f304da75f4c "tools/oxenstored: port XS_INTRODUCE evtchn rebind function from cxenstored" added the exact same behavior in the OCaml XenStored last year.
>>>>>>
>>>>>> This was introduced 12 years after C XenStored, so surely someone think this is useful. We should check why this was introduced in OCaml XenStored (I have CCed the author of the patch).
>>>>>>
>>>>>> If we still think this is not useful, then you should add an explanation in the commit message why the two implementations diverge and possibly update the spec.
>>>>>
>>>>> Thanks for CC, Julien.
>>>>>
>>>>> We indeed already use this functionality in our toolstack for guest kdump
>>>>> functions. It's not possible in XAPI to adopt libxl model where almost everything
>>>>> is restarted for a domain entering kdump, so we have to use this message to
>>>>> rebind xenstore evtchn after soft reset without shutting down backends and
>>>>> recreating the whole subtree (frontends reconnect fine after that).
>>>>>
>>>>> We obviously only require it for now to be present in oxenstored only.
>>>>> Please don't remove this functionality if possible.
>>>>
>>>> If I read handling in libxl correctly, in the soft reset case XS_RELEASE
>>>> is issued before doing another XS_INTRODUCE. XS_RELEASE will result in
>>>> xenstored throwing away its related struct domain, so XS_INTRODUCE will
>>>> be possible again.
>>>
>>>   From what I remember it was not possible to keep xenstored data for a domain
>>> and at the same time perform release-introduce cycle (at least in oxenstored).
>>> It also involved firing @releaseDomain which caused havoc in other part of
>>> the toolstack.
>>
>> Wei, Ian, can you please tell me where I'm wrong?
>>
>> A soft reset should restart the domain in a clean state. AFAIK libxl is
>> handling that by doing kind of in-place save-restore, including calling
>> xs_release_domain() and later xs_introduce_domain(). This should result
>> in xenstored throwing away all state it has regarding the domain and
>> then restarting with a new (internal) domain instance.
>>
>> Is XAPI doing soft reset differently? Why should there be a need for
>> keeping xenstored data across a soft reset?
> 
> Yes, XAPI is doing soft reset differently from libxl. You need to keep xenstore
> data to at least keep backends working without the need to reinitialize them
> before entering kdump kernel. We do the same thing while entering crash kernel
> in Windows after BSOD (CC Paul as he recommended this approach).
> There are other reasons to not reset xenstore data.
> 
> I considered XS_INTRODUCE functionality to be part of xenstored ABI and we built
> a lot of infrastructure on top of that. So I don't think it could be easily removed now.

Nobody wants to remove XS_INTRODUCE. It was just questioned there is a
need to call XS_INTRODUCE multiple times for a domain without a call of
XS_RELEASE in between.

In case there is such a need this means we either should just drop the
test for the mfn to match and recreate the event-channel (which will do
no harm IMO), or we need to keep the mfn in the live-update state record
with the knowledge that it is far from being a good indicator for the
test whether a domain is known already or not (two HVM domains using a
similar configuration with the very same kernel will use the same gfn
probably).

As only dom0 is allowed to use XS_INTRODUCE and I'm not aware of any
problems with neither XS_INTRODUCE failing due to illegal calls (no mfn
match), nor with potentially recreating the event channel for a "wrong"
domain, I suggest to just allow XS_INTRODUCE to be called as often as
the toolstack wants to.

In the end that was the primary reason to write this patch: to remove
the need to have the mfn in the live-update state record.

Thoughts?


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:13:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmX7-0006oo-2A; Wed, 29 Apr 2020 13:13:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTmX6-0006oj-EP
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:13:48 +0000
X-Inumbo-ID: 424855fc-8a1b-11ea-b9cf-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 424855fc-8a1b-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 13:13:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588166027;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=2oGmrEgKMupQrM7FVAvm/it+FPw2mTp7sakYHmPaIos=;
 b=OXl4JbduLQCePVp5F3IuzeYQ7Pa5jV9v+xm2kMQsAtBf2+s8VuIQJtiv
 MvWIp/eQmqtMYNZMzfSNiTxsG2UPKvQDoqEVw8/9zO0MUrcm9CWaXAiFU
 tXrDFwcLDs3VuU1y7PruKCAO3d9gaC+e1naflj0+MZgCzlT9wDIMKT9Dm Y=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: FgeK8dkL4dcP776bljb4Zo7RG+3Ja7DWkiAvMBcOwT/j4+NqyHsQRYX9AOv0Aw3/aDkV6kuttG
 WLfmtqZQPjj2E6Yyphne98g6S40LXyYhB0RW4Hz5Vg5oI+jDVriyfv2tn6ZXdwOsPPcz+FA40c
 jGoR+LD0C02uOL3utqHtj4iUpepGUkWf0vy6TDrUSSfbpTQX+P6Jy8vLT6RpRxSnQqsBbwXtjM
 +gwo1KtWP2qXjuT9WigCVhbEh/EHUFEzGn+G5ZTX95w3e04Q31n49gL+0lckgU7gvjOIXD+tbu
 rXY=
X-SBRS: 2.7
X-MesageID: 16837954
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16837954"
Subject: Re: [PATCH 2/3] x86/pv: Short-circuit is_pv_{32,64}bit_domain() in
 !CONFIG_PV32 builds
To: Jan Beulich <jbeulich@suse.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-3-andrew.cooper3@citrix.com>
 <9b721f94-92de-8d23-b9a4-fdaae13aec38@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <0300a420-2979-d788-c158-12d580e412ee@citrix.com>
Date: Wed, 29 Apr 2020 14:13:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9b721f94-92de-8d23-b9a4-fdaae13aec38@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 20/04/2020 15:09, Jan Beulich wrote:
> On 17.04.2020 17:50, Andrew Cooper wrote:
>> --- a/xen/arch/x86/pv/domain.c
>> +++ b/xen/arch/x86/pv/domain.c
>> @@ -215,7 +215,7 @@ int switch_compat(struct domain *d)
>>          return 0;
>>  
>>      d->arch.has_32bit_shinfo = 1;
>> -    d->arch.is_32bit_pv = 1;
>> +    d->arch.pv.is_32bit = 1;
>>  
>>      for_each_vcpu( d, v )
>>      {
>> @@ -235,7 +235,7 @@ int switch_compat(struct domain *d)
>>      return 0;
>>  
>>   undo_and_fail:
>> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
>>      for_each_vcpu( d, v )
>>      {
>>          free_compat_arg_xlat(v);
>> @@ -358,7 +358,7 @@ int pv_domain_initialise(struct domain *d)
>>      d->arch.ctxt_switch = &pv_csw;
>>  
>>      /* 64-bit PV guest by default. */
>> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
> Switch to true/false while you're touching these?

Yes, but I'm tempted to delete these lines in the final hunk.  Its
writing zeros into a zeroed structures.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:16:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:16:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTma5-0006vx-HR; Wed, 29 Apr 2020 13:16:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xGEm=6N=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jTma4-0006vs-Sr
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:16:52 +0000
X-Inumbo-ID: afde216e-8a1b-11ea-ae69-bc764e2007e4
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id afde216e-8a1b-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 13:16:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588166211;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=li7mdtzKQF/3GuwIKiRLZGF3S+9lCMvTSVu9CWtxfxA=;
 b=XWJzPsBeoAMrjCpgVkXr6+j3E9JYBljvgDz+HWctgpSurgQO9JLTsN6D
 XpQAoHqd85+G7KfmrhDCDjwq7nkuOC/lZiQmsBSuVSDexsyNZ33TgKhBX
 mUugh+7xxlyvy3B8PwvKkdogY9bMG4mZos7u2JaF/Jnd3c9hEKqvyS7GZ 8=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: IA8d+2jwmHBxcmYi/W7rRyNbopQ6ZwT70My7h5Mts90e3AffUB9bwXft4nj6SDIGeVMvUr1RJ3
 TtvoIByi3OHRVgS49yM+eofZ/FFx1d/CLfyfa3ptjj84Rn9OMtjkxJi20L+xmyXmx8i0rdbgOC
 qUzmHpp3JlHNKmdKQfJV/l7ycV3yRfAot2Fpl4FTWJV8lmb63dq55o+JKCEIx5+QiV1fjLNqut
 2qQhd9K4WtT6IOSTGNK33C1pcsBp/xm+YaecT4pIRgue3NfZ9y9NKjHjZvu+WDSaJu9TSlEzmI
 BPE=
X-SBRS: 2.7
X-MesageID: 16750942
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16750942"
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: <paul@xen.org>, =?UTF-8?B?J0rDvHJnZW4gR3Jvw58n?= <jgross@suse.com>,
 'Julien Grall' <julien@xen.org>, 'Julien Grall' <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
 <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
 <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
 <f80aff47-8617-8f59-0d34-bf0385128b62@suse.com>
 <a23c3d72-f5c8-5c3f-2c2f-5a9ca1065d1f@citrix.com>
 <000001d61e25$97f86530$c7e92f90$@xen.org>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <0eaea23f-8b4a-2c67-2fc4-827cf26dbd8d@citrix.com>
Date: Wed, 29 Apr 2020 14:16:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <000001d61e25$97f86530$c7e92f90$@xen.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'xen-devel' <xen-devel@lists.xenproject.org>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>, 'Wei Liu' <wl@xen.org>,
 andrew.cooper3@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 13:56, Paul Durrant wrote:
>> -----Original Message-----
>> From: Igor Druzhinin <igor.druzhinin@citrix.com>
>> Sent: 29 April 2020 13:50
>> To: Jürgen Groß <jgross@suse.com>; Julien Grall <julien@xen.org>; Julien Grall
>> <julien.grall.oss@gmail.com>
>> Cc: xen-devel <xen-devel@lists.xenproject.org>; Ian Jackson <ian.jackson@eu.citrix.com>; Wei Liu
>> <wl@xen.org>; andrew.cooper3@citrix.com; Paul Durrant <paul@xen.org>
>> Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred
>>
>> On 29/04/2020 13:29, Jürgen Groß wrote:
>>>
>>> Wei, Ian, can you please tell me where I'm wrong?
>>>
>>> A soft reset should restart the domain in a clean state. AFAIK libxl is
>>> handling that by doing kind of in-place save-restore, including calling
>>> xs_release_domain() and later xs_introduce_domain(). This should result
>>> in xenstored throwing away all state it has regarding the domain and
>>> then restarting with a new (internal) domain instance.
>>>
>>> Is XAPI doing soft reset differently? Why should there be a need for
>>> keeping xenstored data across a soft reset?
>>
>> Yes, XAPI is doing soft reset differently from libxl. You need to keep xenstore
>> data to at least keep backends working without the need to reinitialize them
>> before entering kdump kernel. We do the same thing while entering crash kernel
>> in Windows after BSOD (CC Paul as he recommended this approach).
> 
> IIRC I recommended not involving Xen or the toolstack in entering the crash kernel... they don't need to know. Windows quite happily enters its crash kernel, rebuilds its Xen interfaces and re-attaches to PV backends without any external intervention.

In case of kdump toolstack certainly needs to know as it gets shutdown code 5 and
needs to restart the domain.

And I'm not completely sure it's possible to enter kdump without calling soft reset
at all. Even if it's possible I'd be cautious to do it in production for the future.

Igor


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:22:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:22:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmfS-0007tE-78; Wed, 29 Apr 2020 13:22:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/uTc=6N=gmail.com=xadimgnik@srs-us1.protection.inumbo.net>)
 id 1jTmfR-0007t7-4g
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:22:25 +0000
X-Inumbo-ID: 766b47bc-8a1c-11ea-b07b-bc764e2007e4
Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 766b47bc-8a1c-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 13:22:24 +0000 (UTC)
Received: by mail-wr1-x443.google.com with SMTP id t14so2478635wrw.12
 for <xen-devel@lists.xenproject.org>; Wed, 29 Apr 2020 06:22:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:content-transfer-encoding:content-language
 :thread-index; bh=7QaBiRW4xSkhhUWlHoNtsHvIq9713jNgN1BqjrnK9uk=;
 b=YtbTmF8dFZKWbgUOPRP5VnunwnlokKjJM0ORMySyVIATrGZGQOAuhGaAkMCmZbiFm/
 HabuNvVyaRf262oL44TjuCQnT34mf/szbeZ3XLyKk02MHeBlPVTxpLVIwP9CXZEhDgFP
 iczLKhAA4sQ8zRr1NaxN1nFULOZckoBl+6I6JhU6Mkksx+wXF7e8gRN2MQLtkWfGPt1D
 LUtwmsbY10wSJGc1tQOdCyT3qxTn+IfZyWB0tgb7mlHOn24jGoNXdkUyijqexeKK6E3s
 r+couGiVxWcA4khojNbAktI/HQXSXivwmzLS2OJtLt4J9D2nH+a2CWSUdHyxHzDEWv7n
 6kmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to
 :subject:date:message-id:mime-version:content-transfer-encoding
 :content-language:thread-index;
 bh=7QaBiRW4xSkhhUWlHoNtsHvIq9713jNgN1BqjrnK9uk=;
 b=FvjOp0SEFqgkD1sx4U1ZRJVxMfdGjh+66HoGDId+u36x6mRbamHwyrOFb+yWM3gt9F
 BgJ/5ZuGyUqxXSkVZ2ed9MOvb6muO+oKR/kQsEDaIHEFzYyJt161+LhjxDfYXxHS9zlk
 0oKS7kIbsxGV59PL5mSpfFZGnto5MO1xXjJVHlxDcMft3SAz7Tq2MdA/qeicwu7SHjuz
 mwM0CFtQVxP0feWG/SBkKuXG9zKUTCpOfKtsj0vh6GVQsMr936OPzw4lSIpMiK0QgapA
 jW6EDUCGmtqq8uw5on/dEQz53a1T9gENqQMGUh1wxu7O/Za1oq+D3pNy4hAxZJl7UUsQ
 9LGQ==
X-Gm-Message-State: AGi0PuYO6M3JR9bW2jHh1K0P+1Pvug24sUIfV45VUbir+Y++Ym9RXMFt
 sfH53SywRWQjUalEcX9N7s8=
X-Google-Smtp-Source: APiQypI/eUep6KdlA0qho55MsHdOEUyLGfPtC+5OPviSGtlu7aqqQy4JoazPfYzayvvE1XLVmsyUyA==
X-Received: by 2002:a5d:4381:: with SMTP id i1mr38005620wrq.194.1588166543490; 
 Wed, 29 Apr 2020 06:22:23 -0700 (PDT)
Received: from CBGR90WXYV0 ([54.239.6.187])
 by smtp.gmail.com with ESMTPSA id k3sm33414039wru.90.2020.04.29.06.22.21
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 29 Apr 2020 06:22:22 -0700 (PDT)
From: Paul Durrant <xadimgnik@gmail.com>
X-Google-Original-From: "Paul Durrant" <paul@xen.org>
To: "'Igor Druzhinin'" <igor.druzhinin@citrix.com>,
 =?UTF-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= <jgross@suse.com>,
 "'Julien Grall'" <julien@xen.org>,
 "'Julien Grall'" <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
 <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
 <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
 <f80aff47-8617-8f59-0d34-bf0385128b62@suse.com>
 <a23c3d72-f5c8-5c3f-2c2f-5a9ca1065d1f@citrix.com>
 <000001d61e25$97f86530$c7e92f90$@xen.org>
 <0eaea23f-8b4a-2c67-2fc4-827cf26dbd8d@citrix.com>
In-Reply-To: <0eaea23f-8b4a-2c67-2fc4-827cf26dbd8d@citrix.com>
Subject: RE: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
Date: Wed, 29 Apr 2020 14:22:21 +0100
Message-ID: <000101d61e29$37890f70$a69b2e50$@xen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQI5DSqNP/4D/SMDjCtgzueaLTX80QC4bkXHAbDXqJ8CsNUfVQLT/QPPATMMdVoBnbvEPwMR4MQ0ANMkKK0Bz5197wJMukkIpzQ1JXA=
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: paul@xen.org
Cc: 'xen-devel' <xen-devel@lists.xenproject.org>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>, 'Wei Liu' <wl@xen.org>,
 andrew.cooper3@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

> -----Original Message-----
> From: Igor Druzhinin <igor.druzhinin@citrix.com>
> Sent: 29 April 2020 14:17
> To: paul@xen.org; 'J=C3=BCrgen Gro=C3=9F' <jgross@suse.com>; 'Julien =
Grall' <julien@xen.org>; 'Julien Grall'
> <julien.grall.oss@gmail.com>
> Cc: 'xen-devel' <xen-devel@lists.xenproject.org>; 'Ian Jackson' =
<ian.jackson@eu.citrix.com>; 'Wei Liu'
> <wl@xen.org>; andrew.cooper3@citrix.com
> Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring =
page in xensotred
>=20
> On 29/04/2020 13:56, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Igor Druzhinin <igor.druzhinin@citrix.com>
> >> Sent: 29 April 2020 13:50
> >> To: J=C3=BCrgen Gro=C3=9F <jgross@suse.com>; Julien Grall =
<julien@xen.org>; Julien Grall
> >> <julien.grall.oss@gmail.com>
> >> Cc: xen-devel <xen-devel@lists.xenproject.org>; Ian Jackson =
<ian.jackson@eu.citrix.com>; Wei Liu
> >> <wl@xen.org>; andrew.cooper3@citrix.com; Paul Durrant =
<paul@xen.org>
> >> Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring =
page in xensotred
> >>
> >> On 29/04/2020 13:29, J=C3=BCrgen Gro=C3=9F wrote:
> >>>
> >>> Wei, Ian, can you please tell me where I'm wrong?
> >>>
> >>> A soft reset should restart the domain in a clean state. AFAIK =
libxl is
> >>> handling that by doing kind of in-place save-restore, including =
calling
> >>> xs_release_domain() and later xs_introduce_domain(). This should =
result
> >>> in xenstored throwing away all state it has regarding the domain =
and
> >>> then restarting with a new (internal) domain instance.
> >>>
> >>> Is XAPI doing soft reset differently? Why should there be a need =
for
> >>> keeping xenstored data across a soft reset?
> >>
> >> Yes, XAPI is doing soft reset differently from libxl. You need to =
keep xenstore
> >> data to at least keep backends working without the need to =
reinitialize them
> >> before entering kdump kernel. We do the same thing while entering =
crash kernel
> >> in Windows after BSOD (CC Paul as he recommended this approach).
> >
> > IIRC I recommended not involving Xen or the toolstack in entering =
the crash kernel... they don't
> need to know. Windows quite happily enters its crash kernel, rebuilds =
its Xen interfaces and re-
> attaches to PV backends without any external intervention.
>=20
> In case of kdump toolstack certainly needs to know as it gets shutdown =
code 5 and
> needs to restart the domain.
>=20

The toolstack needs to restart the domain once the crash has completed, =
yes.

> And I'm not completely sure it's possible to enter kdump without =
calling soft reset
> at all. Even if it's possible I'd be cautious to do it in production =
for the future.
>=20

If it is not possible at the moment then IMO it should be made so; =
having soft reset in the toolstack is a layering violation IMO.

  Paul




From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:22:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmfp-0007w9-KH; Wed, 29 Apr 2020 13:22:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTmfn-0007vs-Iu
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:22:47 +0000
X-Inumbo-ID: 843a31e6-8a1c-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 843a31e6-8a1c-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 13:22:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=7+F1l2FcWfs/7ZNEI5erNsE7mfBro9fYkLosgj4p+jg=; b=G2fhviyLBXq7IGGaD1ga1JEv9I
 zWO2XJbDl+3C/RBf2c96nLCTgCb1lr1U+UlIDRsjzzicD5j/U0Up2nfYE+gaHYEnzNGPsnwC9WY/I
 nJunPrpd/yvumE+orsHsLixE7O4pPKgo/H0TVzgXlS2rz4ip5jcmlRBW9wuTi9quMPx8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTmfj-0001kn-Vs; Wed, 29 Apr 2020 13:22:43 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTmfj-0002tJ-M2; Wed, 29 Apr 2020 13:22:43 +0000
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
To: Jan Beulich <jbeulich@suse.com>
References: <9d4b738a-4487-6bfc-3076-597d074c7b47@suse.com>
 <e820e1b9-7a7e-21f3-1ea0-d939de1905dd@suse.com>
 <9108f918-ee44-0740-48e0-7e0b0c761e1b@xen.org>
 <2025316a-de36-91d9-521c-547af668f919@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <b7cf3ad4-2537-9df8-7a8a-743cd0fe45c0@xen.org>
Date: Wed, 29 Apr 2020 14:22:40 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <2025316a-de36-91d9-521c-547af668f919@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
 George Dunlap <george.dunlap@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 22/04/2020 10:32, Jan Beulich wrote:
> On 22.04.2020 10:17, Julien Grall wrote:
>> On 21/04/2020 10:13, Jan Beulich wrote:
>>> First of all avoid excessive conversions. copy_{from,to}_guest(), for
>>> example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
>>>
>>> Further
>>> - do_physdev_op_compat() didn't use the param form for its parameter,
>>> - {hap,shadow}_track_dirty_vram() wrongly used the param form,
>>> - compat processor Px logic failed to check compatibility of native and
>>>     compat structures not further converted.
>>>
>>> As this eliminates all users of guest_handle_from_param() and as there's
>>> no real need to allow for conversions in both directions, drop the
>>> macros as well.
>>
>> I was kind of expecting both guest_handle_from_param() and
>> guest_handle_to_param() to be dropped together. May I ask why
>> you still need guest_handle_to_param()?
> 
> There are three (iirc) uses left which I don't really see how
> to sensibly replace. Take a look at the different callers of
> x86's vcpumask_to_pcpumask(), for example.

Oh, const_guest_handle_from_ptr() is returning a GUEST_HANDLE_PARAM. 
This is a bit odd but fair enough.

> 
>>> --- a/xen/include/xen/acpi.h
>>> +++ b/xen/include/xen/acpi.h
>>> @@ -184,8 +184,8 @@ static inline unsigned int acpi_get_csub
>>>    static inline void acpi_set_csubstate_limit(unsigned int new_limit) { return; }
>>>    #endif
>>>    -#ifdef XEN_GUEST_HANDLE_PARAM
>>> -int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32));
>>> +#ifdef XEN_GUEST_HANDLE
>>> +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32));
>>>    #endif
>>
>> Do we really need to keep the #ifdef here?
> 
> I think so, yes, or else the original one wouldn't have been
> needed either. (Consider the header getting included without
> any of the public headers having got included first.) Dropping
> (if it was possible) this would be an orthogonal change imo.

Fair point.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:22:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmft-0007xB-Sm; Wed, 29 Apr 2020 13:22:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=TOqq=6N=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jTmfs-0007wz-Jm
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:22:52 +0000
X-Inumbo-ID: 84d37e78-8a1c-11ea-9887-bc764e2007e4
Received: from mail-lj1-x241.google.com (unknown [2a00:1450:4864:20::241])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 84d37e78-8a1c-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 13:22:48 +0000 (UTC)
Received: by mail-lj1-x241.google.com with SMTP id u15so2606670ljd.3
 for <xen-devel@lists.xenproject.org>; Wed, 29 Apr 2020 06:22:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=rs9WsZy3UHGbspvjzO3df88pFT8WLgTk+2Zcxlo9B34=;
 b=f3XkZRM+HS2WLok4TniJocpSaAQDoCcsRg2eZ1kbYtnNe4HevBF0z3EwR+vtJHa9JP
 b/Wx5SRmKtnLFkIKeW5aKijeko00vsWqTWz7ukvC6FDTSlgQDx9gaEsbcmMYruBaxIzE
 uuHqY6vzISZKniYkxnN/WbYntcOBZektyX71tgKg9wGWl774kLCHfGLQUx8Oagkgc6bX
 hQFgKk9PDAfrTSZKryPOBq6/d88C8MyzVW6GVKNaKJKpthZYlT8VpDe2IW5TOjyIGpq4
 HiZDbWsVCwA7ReCdMwMo/BU2OueeJsGxe1B8oXJbs2+TdK1nmJTRCSCpcjUbBk1Pg5on
 fMPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=rs9WsZy3UHGbspvjzO3df88pFT8WLgTk+2Zcxlo9B34=;
 b=ltF6xjANTDNFnLmJmkZc1tqHUzHZIuulOwV3SYjt09WFy17HK2Udd0v6GeTnLBUtg8
 btjaXs8BrOyjIrqm/Jrs97kE8gfRi9liI1fZ9RenpCoMqKbxAiIcLT6z64Vs3qbqSTdq
 zIJ6/f9KgYdgS8Jg3NE6Zfr3DR1R8oijPK4nEbOftZld2pcn5Ygtxge5gzOBWSWF6aRH
 Y3SgPHkzWxxKwMmxQqJkDnPVKQAdtXXnC1tW5dJoAGPJmYTOFKVDpOPppO23MXfcld6y
 4O+EUVSQrlg491jjtDYQgaYJfMgNtqR2o9rXcG3O3+J/fHF3vgHbjnnKIGYRRs7uJfQk
 owqQ==
X-Gm-Message-State: AGi0PuaNKW02iWq/Z49LYeLDozkRLwRCSSLOmz24v/qnp2CFIwBsK7Ll
 7/pPmCNQTmL7GQYeiEZm3VayG6D4bbHkmWqKq29JIw==
X-Google-Smtp-Source: APiQypJS7j0POpX3bUUaJOP2Za5NIykhPxp+ktRsjuIS2sAjVhIgm+Pnz0BaiURcWz6CgTGXS64qt2hBl9BdDVHPrLE=
X-Received: by 2002:a2e:700b:: with SMTP id l11mr17194226ljc.255.1588166567421; 
 Wed, 29 Apr 2020 06:22:47 -0700 (PDT)
MIME-Version: 1.0
References: <20200424073859.89-1-paul@xen.org>
In-Reply-To: <20200424073859.89-1-paul@xen.org>
From: Jason Andryuk <jandryuk@gmail.com>
Date: Wed, 29 Apr 2020 09:22:36 -0400
Message-ID: <CAKf6xptEUFra2QN=sdUEB5+gkP+zt+LXyWP5YBrxaySvXhOXRA@mail.gmail.com>
Subject: Re: [ANNOUNCE] Xen 4.14 Development Update
To: xen-devel <xen-devel@lists.xenproject.org>,
 Paul Durrant <pdurrant@amazon.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, hongyxia@amazon.com,
 Jan Beulich <jbeulich@suse.com>, tamas.k.lengyel@gmail.com, dwmw@amazon.com,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, Apr 24, 2020 at 3:40 AM Paul Durrant <paul@xen.org> wrote:
> *  Linux stub domains (v4)
>   -  Marek Marczykowski-G=C3=B3recki

In coordination with Marek, I've posted v5.

-Jason


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:26:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:26:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmjQ-0008EJ-Dq; Wed, 29 Apr 2020 13:26:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTmjP-0008EE-Q4
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:26:31 +0000
X-Inumbo-ID: 0993a872-8a1d-11ea-9949-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0993a872-8a1d-11ea-9949-12813bfff9fa;
 Wed, 29 Apr 2020 13:26:31 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DFD55AF86;
 Wed, 29 Apr 2020 13:26:28 +0000 (UTC)
Subject: Re: [PATCH] x86/S3: Drop {save,restore}_rest_processor_state()
 completely
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200429110903.15418-1-andrew.cooper3@citrix.com>
 <42c1a2ec-51a1-7b03-aea5-f8ffe80d6928@suse.com>
 <52bdc00f-7778-bd06-14e1-d5c6086466d3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8cfa1ae3-24ef-5885-d758-ccb188e4e4e2@suse.com>
Date: Wed, 29 Apr 2020 15:25:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <52bdc00f-7778-bd06-14e1-d5c6086466d3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 13:32, Andrew Cooper wrote:
> On 29/04/2020 12:16, Jan Beulich wrote:
>> On 29.04.2020 13:09, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/boot/trampoline.S
>>> +++ b/xen/arch/x86/boot/trampoline.S
>>> @@ -91,6 +91,11 @@ trampoline_protmode_entry:
>>>          and     %edi,%edx
>>>          wrmsr
>>>  1:
>>> +        /* Set up PAT before enabling paging. */
>>> +        mov     $XEN_MSR_PAT & 0xffffffff, %eax
>>> +        mov     $XEN_MSR_PAT >> 32, %edx
>>> +        mov     $MSR_IA32_CR_PAT, %ecx
>>> +        wrmsr
>> Doesn't this also eliminate the need for cpu_init() doing this?
>> If you agree with that one also dropped
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> That doesn't cover the BSP on either the legacy or EFI paths.

The legacy path, afaict, uses it:

.Lskip_realmode:
        /* EBX == 0 indicates we are the BP (Boot Processor). */
        xor     %ebx,%ebx

        /* Jump to the common bootstrap entry point. */
        jmp     trampoline_protmode_entry

The xen.efi entry path really should have the change you make
mirrored anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:27:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmkM-0008J3-Nw; Wed, 29 Apr 2020 13:27:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xGEm=6N=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jTmkL-0008Iv-Mp
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:27:29 +0000
X-Inumbo-ID: 2bb28838-8a1d-11ea-9887-bc764e2007e4
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2bb28838-8a1d-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 13:27:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588166849;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=nEY+BgwN9s5pLDZw5R6QofIdPvR9bPDUkz6NuKW7k/I=;
 b=J252ACjSjCUS0LXWZ2H6w1A06RdJFkdgo/VTvLouq7jELbLSnTTQ/fWF
 6BXlcKLE9s9XF98YUP3YZmNrT59ZmaB5U39EBGm8G6lr+x0x4D2l2QJON
 K/0tD98Jduq5hptYwwh3IY/+KZf+ZQcoslZWPsT6BarEeIXVKxK06uv+6 w=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: BOnBCUTpubBaykhefaGF8rXKtsZPc+Fut07Ttpr8cDUc7K3JPLRUqr429FR1wG89VJTSVSE1GS
 fl7FwBdzOT5hUdijEUuDrOwZ/vasJB/CWjA2eBEkYNrEGzLRaJoi2KNOSAWP3dmZLbIHvaKtc4
 zGL0RHraMEA524hZOQFnF2VYLJQIp/2+5iw7JDpHiVYY89G12Ni947dpdoJ/63Nb5naEKop093
 H5cQi9AyovxuecMchRcX1aVmCmE0L4Aql4m9yWww3BqDv2UYCOkLnxNAyufS417zkUEEeFs0ep
 SZ0=
X-SBRS: 2.7
X-MesageID: 16694309
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16694309"
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: <paul@xen.org>, =?UTF-8?B?J0rDvHJnZW4gR3Jvw58n?= <jgross@suse.com>,
 'Julien Grall' <julien@xen.org>, 'Julien Grall' <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
 <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
 <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
 <f80aff47-8617-8f59-0d34-bf0385128b62@suse.com>
 <a23c3d72-f5c8-5c3f-2c2f-5a9ca1065d1f@citrix.com>
 <000001d61e25$97f86530$c7e92f90$@xen.org>
 <0eaea23f-8b4a-2c67-2fc4-827cf26dbd8d@citrix.com>
 <000101d61e29$37890f70$a69b2e50$@xen.org>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <df06904d-1915-bf13-f0ac-c1c78bf05287@citrix.com>
Date: Wed, 29 Apr 2020 14:27:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <000101d61e29$37890f70$a69b2e50$@xen.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'xen-devel' <xen-devel@lists.xenproject.org>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>, 'Wei Liu' <wl@xen.org>,
 andrew.cooper3@citrix.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 14:22, Paul Durrant wrote:
>> -----Original Message-----
>> From: Igor Druzhinin <igor.druzhinin@citrix.com>
>> Sent: 29 April 2020 14:17
>> To: paul@xen.org; 'Jürgen Groß' <jgross@suse.com>; 'Julien Grall' <julien@xen.org>; 'Julien Grall'
>> <julien.grall.oss@gmail.com>
>> Cc: 'xen-devel' <xen-devel@lists.xenproject.org>; 'Ian Jackson' <ian.jackson@eu.citrix.com>; 'Wei Liu'
>> <wl@xen.org>; andrew.cooper3@citrix.com
>> Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred
>>
>> On 29/04/2020 13:56, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Igor Druzhinin <igor.druzhinin@citrix.com>
>>>> Sent: 29 April 2020 13:50
>>>> To: Jürgen Groß <jgross@suse.com>; Julien Grall <julien@xen.org>; Julien Grall
>>>> <julien.grall.oss@gmail.com>
>>>> Cc: xen-devel <xen-devel@lists.xenproject.org>; Ian Jackson <ian.jackson@eu.citrix.com>; Wei Liu
>>>> <wl@xen.org>; andrew.cooper3@citrix.com; Paul Durrant <paul@xen.org>
>>>> Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred
>>>>
>>>> On 29/04/2020 13:29, Jürgen Groß wrote:
>>>>>
>>>>> Wei, Ian, can you please tell me where I'm wrong?
>>>>>
>>>>> A soft reset should restart the domain in a clean state. AFAIK libxl is
>>>>> handling that by doing kind of in-place save-restore, including calling
>>>>> xs_release_domain() and later xs_introduce_domain(). This should result
>>>>> in xenstored throwing away all state it has regarding the domain and
>>>>> then restarting with a new (internal) domain instance.
>>>>>
>>>>> Is XAPI doing soft reset differently? Why should there be a need for
>>>>> keeping xenstored data across a soft reset?
>>>>
>>>> Yes, XAPI is doing soft reset differently from libxl. You need to keep xenstore
>>>> data to at least keep backends working without the need to reinitialize them
>>>> before entering kdump kernel. We do the same thing while entering crash kernel
>>>> in Windows after BSOD (CC Paul as he recommended this approach).
>>>
>>> IIRC I recommended not involving Xen or the toolstack in entering the crash kernel... they don't
>> need to know. Windows quite happily enters its crash kernel, rebuilds its Xen interfaces and re-
>> attaches to PV backends without any external intervention.
>>
>> In case of kdump toolstack certainly needs to know as it gets shutdown code 5 and
>> needs to restart the domain.
>>
> 
> The toolstack needs to restart the domain once the crash has completed, yes.

To clarify, what I meant is that once crash happened (before kdump kernel is loaded)
toolstack gets code 5 and then it's supposed to call soft reset and unpause the domain
to actually load into crash kernel.

I didn't mean that after crash kernel is finished the domain has to be restarted - that's
obvious.

Igor

 


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:29:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmm6-0008R0-3l; Wed, 29 Apr 2020 13:29:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTmm4-0008Qv-Ak
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:29:16 +0000
X-Inumbo-ID: 6ba63afc-8a1d-11ea-9949-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6ba63afc-8a1d-11ea-9949-12813bfff9fa;
 Wed, 29 Apr 2020 13:29:15 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 166B5ABD0;
 Wed, 29 Apr 2020 13:29:14 +0000 (UTC)
Subject: Re: [PATCH 2/3] x86/pv: Short-circuit is_pv_{32,64}bit_domain() in
 !CONFIG_PV32 builds
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-3-andrew.cooper3@citrix.com>
 <9b721f94-92de-8d23-b9a4-fdaae13aec38@suse.com>
 <0300a420-2979-d788-c158-12d580e412ee@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <128b382e-e601-d09f-95de-fa9f7b0b2318@suse.com>
Date: Wed, 29 Apr 2020 15:29:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <0300a420-2979-d788-c158-12d580e412ee@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 15:13, Andrew Cooper wrote:
> On 20/04/2020 15:09, Jan Beulich wrote:
>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/pv/domain.c
>>> +++ b/xen/arch/x86/pv/domain.c
>>> @@ -215,7 +215,7 @@ int switch_compat(struct domain *d)
>>>          return 0;
>>>  
>>>      d->arch.has_32bit_shinfo = 1;
>>> -    d->arch.is_32bit_pv = 1;
>>> +    d->arch.pv.is_32bit = 1;
>>>  
>>>      for_each_vcpu( d, v )
>>>      {
>>> @@ -235,7 +235,7 @@ int switch_compat(struct domain *d)
>>>      return 0;
>>>  
>>>   undo_and_fail:
>>> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>>> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
>>>      for_each_vcpu( d, v )
>>>      {
>>>          free_compat_arg_xlat(v);
>>> @@ -358,7 +358,7 @@ int pv_domain_initialise(struct domain *d)
>>>      d->arch.ctxt_switch = &pv_csw;
>>>  
>>>      /* 64-bit PV guest by default. */
>>> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>>> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
>> Switch to true/false while you're touching these?
> 
> Yes, but I'm tempted to delete these lines in the final hunk.  Its
> writing zeros into a zeroed structures.

Oh, yes, agreed.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:31:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmnp-0000lf-F6; Wed, 29 Apr 2020 13:31:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTmnn-0000lY-QF
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:31:03 +0000
X-Inumbo-ID: ab9fd03c-8a1d-11ea-b07b-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ab9fd03c-8a1d-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 13:31:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588167062;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=iC8mJG/AEFwNyrWHK8ITgLLgwTUDW/UrdDSueSb5tKc=;
 b=Lqvwh5zwIwSpyhj8neljvnqiyu1ebaz+6DWzFcNAu8E+L+wqctdrrUA7
 oiBvuzhCeYwJNjCHGlp1JOdiJcDgRJz3hf+N4j3xEZJGZnVhW0+XWVMe3
 VngV116w4AMsr08Hqz9YLmE8C6/jxY7pFlK+pDoW7EwSF0BonuTPZDB7s k=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: nBh+I0hfGfTKV36PgXd3nvJfdwLgGc0R+jCZJeEzfwRQK7iHaJfIoBD4IHFkNUxl31pu7jbl90
 jbJVQsvPGc+3YL6iM2Sc3epxg6zhu2wDOSspcChLZTCLSR/s0WFCCBD7zOWu5fIDWgnIQzghQU
 CFpYtwCsFsiFQY/2WtvFhx1a7doybqVsOLj66xmClDfyJ0+qUDXzgTH9/25VXNa+tPpPJ+C5Qs
 vaAHGjhz0cK843MeGN1EtzZPZk5ptIsqxhzPcLkCvoeS2T+A/TQ52QxvpNydbboulggO5tPep4
 p6w=
X-SBRS: 2.7
X-MesageID: 16839299
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16839299"
Subject: Re: [PATCH 2/3] x86/pv: Short-circuit is_pv_{32,64}bit_domain() in
 !CONFIG_PV32 builds
To: Jan Beulich <jbeulich@suse.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-3-andrew.cooper3@citrix.com>
 <9b721f94-92de-8d23-b9a4-fdaae13aec38@suse.com>
 <0300a420-2979-d788-c158-12d580e412ee@citrix.com>
 <128b382e-e601-d09f-95de-fa9f7b0b2318@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <7ac2cb5a-063c-9d47-b808-fb40556fd0a0@citrix.com>
Date: Wed, 29 Apr 2020 14:30:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <128b382e-e601-d09f-95de-fa9f7b0b2318@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 14:29, Jan Beulich wrote:
> On 29.04.2020 15:13, Andrew Cooper wrote:
>> On 20/04/2020 15:09, Jan Beulich wrote:
>>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/pv/domain.c
>>>> +++ b/xen/arch/x86/pv/domain.c
>>>> @@ -215,7 +215,7 @@ int switch_compat(struct domain *d)
>>>>          return 0;
>>>>  
>>>>      d->arch.has_32bit_shinfo = 1;
>>>> -    d->arch.is_32bit_pv = 1;
>>>> +    d->arch.pv.is_32bit = 1;
>>>>  
>>>>      for_each_vcpu( d, v )
>>>>      {
>>>> @@ -235,7 +235,7 @@ int switch_compat(struct domain *d)
>>>>      return 0;
>>>>  
>>>>   undo_and_fail:
>>>> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>>>> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
>>>>      for_each_vcpu( d, v )
>>>>      {
>>>>          free_compat_arg_xlat(v);
>>>> @@ -358,7 +358,7 @@ int pv_domain_initialise(struct domain *d)
>>>>      d->arch.ctxt_switch = &pv_csw;
>>>>  
>>>>      /* 64-bit PV guest by default. */
>>>> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>>>> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
>>> Switch to true/false while you're touching these?
>> Yes, but I'm tempted to delete these lines in the final hunk.  Its
>> writing zeros into a zeroed structures.
> Oh, yes, agreed.

Can I take this as an ack then?

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:32:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmol-0000zI-PH; Wed, 29 Apr 2020 13:32:03 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTmok-0000z9-PG
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:32:02 +0000
X-Inumbo-ID: ced3a178-8a1d-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ced3a178-8a1d-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 13:32:02 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 344EDAEF7;
 Wed, 29 Apr 2020 13:32:00 +0000 (UTC)
Subject: Re: [PATCH 5/6] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587116799.git.hongyxia@amazon.com>
 <9287363e13924f4a633b47b53c23b3466e26e4a8.1587116799.git.hongyxia@amazon.com>
 <fbb4a755-c450-77dd-2aa5-44c01b42a5ff@suse.com>
 <9df9c5163fde5d25ceb756b20714c58be93b2c6c.camel@xen.org>
 <c33dcaee9c8796da8816de9168f91ce90de61fc5.camel@xen.org>
 <e18871ea997a304394adbbc92e724ae0ec56d87a.camel@xen.org>
 <ec318c48-41c3-5cbf-e03e-8838d9f488ba@suse.com>
 <40644d63e00a10636943f6322707c0ad6a73e11c.camel@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <a41b36ed-1dcd-c5e5-2889-1dddaf7b866a@suse.com>
Date: Wed, 29 Apr 2020 15:31:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <40644d63e00a10636943f6322707c0ad6a73e11c.camel@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 14:29, Hongyan Xia wrote:
> (Looks like other patches in this series have been merged. Replying to
> this one only.)

Please send as a proper patch, this one came through ...

> From: Wei Liu <wei.liu2@citrix.com>
> Date: Tue, 5 Feb 2019 16:32:54 +0000
> Subject: [PATCH] x86/pv: map and unmap page tables in
> mark_pv_pt_pages_rdonly
> 
> Also, clean up the initialisation of plXe.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> Reviewed-by: Julien Grall <jgrall@amazon.com>
> ---
>  xen/arch/x86/pv/dom0_build.c | 32 +++++++++++++++++---------------
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/x86/pv/dom0_build.c
> b/xen/arch/x86/pv/dom0_build.c
> index abfbe5f436..3522eb0114 100644
> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -49,18 +49,11 @@ static __init void mark_pv_pt_pages_rdonly(struct
> domain *d,
>  {
>      unsigned long count;
>      struct page_info *page;
> -    l4_pgentry_t *pl4e;
> -    l3_pgentry_t *pl3e;
> -    l2_pgentry_t *pl2e;
> -    l1_pgentry_t *pl1e;
> -
> -    pl4e = l4start + l4_table_offset(vpt_start);
> -    pl3e = l4e_to_l3e(*pl4e);
> -    pl3e += l3_table_offset(vpt_start);
> -    pl2e = l3e_to_l2e(*pl3e);
> -    pl2e += l2_table_offset(vpt_start);
> -    pl1e = l2e_to_l1e(*pl2e);
> -    pl1e += l1_table_offset(vpt_start);
> +    l4_pgentry_t *pl4e = l4start + l4_table_offset(vpt_start);
> +    l3_pgentry_t *pl3e = map_l3t_from_l4e(*pl4e) +
> l3_table_offset(vpt_start);
> +    l2_pgentry_t *pl2e = map_l2t_from_l3e(*pl3e) +
> l2_table_offset(vpt_start);
> +    l1_pgentry_t *pl1e = map_l1t_from_l2e(*pl2e) +
> l1_table_offset(vpt_start);

... mangled anyway. I also think with the change made you need to
drop the R-b.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:37:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:37:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmtc-0001CO-Gz; Wed, 29 Apr 2020 13:37:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTmta-0001CJ-QI
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:37:02 +0000
X-Inumbo-ID: 8152fcfe-8a1e-11ea-b9cf-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 8152fcfe-8a1e-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 13:37:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588167422;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=bDfJHutl9EzSZTAYAL2zW90ecsr9qcqaCG9w1LCKlkQ=;
 b=YlIjnSTgWBF+mtNpzbctq3JftF/fQOFG/MrGlVil987G7xwPYYH+73T5
 8IG9KmifVw2H19qscuK/wrqXzUl1zxKmIpc/5TugvvNxiAnM9ONzpqbBV
 TH3VLRocZKfpMsuvtVRCVGaD2NXxBeZKf6cjDN7LXHYuZNdf82yXKNwHp s=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 2feEWLwWUHRi30tXrRzHurej/4D2KF04Cptc3lgFLQeKkd1qyiHmijGF+BkHK1HuIjPOzovalv
 7lu0WELBsIag/SOE6o3Z2K2Xw0Idkxy8ofrlVaUc1hMjpDFp0JT8ht5v1gYOP7tcKIEbt/TyLZ
 aHjW2pWkHt7Qq8GfV7Xwy/eseTXKCbCBu+cug8w0lgMw424a4qG1Q8a2wBeiNa+ZWXklx2+i1G
 Npy69wrFCN8YIYCyooAcD6s8jI1osLoUhCyx0Cw7k6JLAlAKsUtr6cEGuYuvFF9g1rN3ZzYsFq
 9y4=
X-SBRS: 2.7
X-MesageID: 16426266
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16426266"
Subject: Re: [PATCH] x86/S3: Drop {save,restore}_rest_processor_state()
 completely
To: Jan Beulich <jbeulich@suse.com>
References: <20200429110903.15418-1-andrew.cooper3@citrix.com>
 <42c1a2ec-51a1-7b03-aea5-f8ffe80d6928@suse.com>
 <52bdc00f-7778-bd06-14e1-d5c6086466d3@citrix.com>
 <8cfa1ae3-24ef-5885-d758-ccb188e4e4e2@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <afb3cf2d-5d8d-0f4a-b75f-069191871f87@citrix.com>
Date: Wed, 29 Apr 2020 14:36:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <8cfa1ae3-24ef-5885-d758-ccb188e4e4e2@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>, Roger
 Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 14:25, Jan Beulich wrote:
> On 29.04.2020 13:32, Andrew Cooper wrote:
>> On 29/04/2020 12:16, Jan Beulich wrote:
>>> On 29.04.2020 13:09, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/boot/trampoline.S
>>>> +++ b/xen/arch/x86/boot/trampoline.S
>>>> @@ -91,6 +91,11 @@ trampoline_protmode_entry:
>>>>          and     %edi,%edx
>>>>          wrmsr
>>>>  1:
>>>> +        /* Set up PAT before enabling paging. */
>>>> +        mov     $XEN_MSR_PAT & 0xffffffff, %eax
>>>> +        mov     $XEN_MSR_PAT >> 32, %edx
>>>> +        mov     $MSR_IA32_CR_PAT, %ecx
>>>> +        wrmsr
>>> Doesn't this also eliminate the need for cpu_init() doing this?
>>> If you agree with that one also dropped
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> That doesn't cover the BSP on either the legacy or EFI paths.
> The legacy path, afaict, uses it:
>
> .Lskip_realmode:
>         /* EBX == 0 indicates we are the BP (Boot Processor). */
>         xor     %ebx,%ebx
>
>         /* Jump to the common bootstrap entry point. */
>         jmp     trampoline_protmode_entry

Oh, of course.

> The xen.efi entry path really should have the change you make
> mirrored anyway.

Are you happy for it to go in efi_arch_post_exit_boot()?  We don't
disable paging, but that is the point where we switch from the EFI
pagetables to Xen's.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:37:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:37:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmuL-0001Fj-QT; Wed, 29 Apr 2020 13:37:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTmuK-0001Fc-Ey
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:37:48 +0000
X-Inumbo-ID: 9cf15bfe-8a1e-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9cf15bfe-8a1e-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 13:37:48 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 35C10AEA1;
 Wed, 29 Apr 2020 13:37:46 +0000 (UTC)
Subject: Re: [PATCH 2/3] x86/pv: Short-circuit is_pv_{32,64}bit_domain() in
 !CONFIG_PV32 builds
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-1-andrew.cooper3@citrix.com>
 <20200417155004.16806-3-andrew.cooper3@citrix.com>
 <9b721f94-92de-8d23-b9a4-fdaae13aec38@suse.com>
 <0300a420-2979-d788-c158-12d580e412ee@citrix.com>
 <128b382e-e601-d09f-95de-fa9f7b0b2318@suse.com>
 <7ac2cb5a-063c-9d47-b808-fb40556fd0a0@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <97d0cc20-4b0b-947e-9c7e-8c1ef7724314@suse.com>
Date: Wed, 29 Apr 2020 15:37:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <7ac2cb5a-063c-9d47-b808-fb40556fd0a0@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 15:30, Andrew Cooper wrote:
> On 29/04/2020 14:29, Jan Beulich wrote:
>> On 29.04.2020 15:13, Andrew Cooper wrote:
>>> On 20/04/2020 15:09, Jan Beulich wrote:
>>>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>>>> --- a/xen/arch/x86/pv/domain.c
>>>>> +++ b/xen/arch/x86/pv/domain.c
>>>>> @@ -215,7 +215,7 @@ int switch_compat(struct domain *d)
>>>>>          return 0;
>>>>>  
>>>>>      d->arch.has_32bit_shinfo = 1;
>>>>> -    d->arch.is_32bit_pv = 1;
>>>>> +    d->arch.pv.is_32bit = 1;
>>>>>  
>>>>>      for_each_vcpu( d, v )
>>>>>      {
>>>>> @@ -235,7 +235,7 @@ int switch_compat(struct domain *d)
>>>>>      return 0;
>>>>>  
>>>>>   undo_and_fail:
>>>>> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>>>>> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
>>>>>      for_each_vcpu( d, v )
>>>>>      {
>>>>>          free_compat_arg_xlat(v);
>>>>> @@ -358,7 +358,7 @@ int pv_domain_initialise(struct domain *d)
>>>>>      d->arch.ctxt_switch = &pv_csw;
>>>>>  
>>>>>      /* 64-bit PV guest by default. */
>>>>> -    d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>>>>> +    d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = 0;
>>>> Switch to true/false while you're touching these?
>>> Yes, but I'm tempted to delete these lines in the final hunk.  Its
>>> writing zeros into a zeroed structures.
>> Oh, yes, agreed.
> 
> Can I take this as an ack then?

Sorry, didn't realize I didn't give one yet with the adjustments
made:
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:39:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmvp-0001Oc-6C; Wed, 29 Apr 2020 13:39:21 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xGEm=6N=citrix.com=igor.druzhinin@srs-us1.protection.inumbo.net>)
 id 1jTmvn-0001OW-58
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:39:19 +0000
X-Inumbo-ID: d2d2f764-8a1e-11ea-9887-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d2d2f764-8a1e-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 13:39:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588167559;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=HDoCv6n49nZoScnJXmlMsM86nR5HqteBVwOZytz3nyk=;
 b=CAgTiHmJ5xr7l4EoBUT5NasxY7Jdj28jDfnKzgFp0EBMRoRK21yXrmGN
 lbsS318d2bt3XSdypLwHquVseqNkGvIw7IaKAacepKtnpjEW9NO+T9lMn
 57gptL2AS/v52U6I9J0ZkETbtsBs4T9CDw+nFIdLeH8eRd+VgVJQMnzR6 0=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=igor.druzhinin@citrix.com;
 spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 igor.druzhinin@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 igor.druzhinin@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="igor.druzhinin@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="igor.druzhinin@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 0KZS6gNMFOfEp4CssVpwJOh2eDAU5TMsa16gsX8xhd/pGxFj8JOBznKozmftpIzkhEWeDf5kYC
 qiYU7H/awF4/16wA6/sH/DChT9uPnuRn/7HBE8Jh4EH6p7hWeiNTFDDi43RqyzIbBI1offV4fE
 BXWa6RPWjBZSdFqGaQypoitgx5PIVSmLeFR7ml/HPKLbHhktjoMaTGY1BtBRca50r78b0nCtvk
 y3ZSN6bRBBWoWb9GRrT6SuQOvAaGeEB/3P23c/HqZHKOVOzcYgKfJKPSE7KwMAUtBhg8lv1zRQ
 /pY=
X-SBRS: 2.7
X-MesageID: 16454740
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16454740"
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in
 xensotred
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>, Julien Grall
 <julien@xen.org>, Julien Grall <julien.grall.oss@gmail.com>
References: <20200428155144.8253-1-jgross@suse.com>
 <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com>
 <d1c41bd7-676e-c50a-416d-c62efcbdd41d@suse.com>
 <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org>
 <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com>
 <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com>
 <c07e5106-d8de-f6a7-e406-b25ee9ff6d49@citrix.com>
 <f80aff47-8617-8f59-0d34-bf0385128b62@suse.com>
 <a23c3d72-f5c8-5c3f-2c2f-5a9ca1065d1f@citrix.com>
 <0f553a2e-9541-8d47-c354-0e8273b4b783@suse.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-ID: <eb16ae71-a4d9-354b-a96d-a0e496609b12@citrix.com>
Date: Wed, 29 Apr 2020 14:39:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <0f553a2e-9541-8d47-c354-0e8273b4b783@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Paul Durrant <paul@xen.org>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>,
 "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 14:06, Jürgen Groß wrote:
> On 29.04.20 14:49, Igor Druzhinin wrote:
>> On 29/04/2020 13:29, Jürgen Groß wrote:
>>> On 29.04.20 13:04, Igor Druzhinin wrote:
>>
>> Yes, XAPI is doing soft reset differently from libxl. You need to keep xenstore
>> data to at least keep backends working without the need to reinitialize them
>> before entering kdump kernel. We do the same thing while entering crash kernel
>> in Windows after BSOD (CC Paul as he recommended this approach).
>> There are other reasons to not reset xenstore data.
>>
>> I considered XS_INTRODUCE functionality to be part of xenstored ABI and we built
>> a lot of infrastructure on top of that. So I don't think it could be easily removed now.
> 
> Nobody wants to remove XS_INTRODUCE. It was just questioned there is a
> need to call XS_INTRODUCE multiple times for a domain without a call of
> XS_RELEASE in between.

Sorry, I didn't mean the whole XS_INTRODUCE but that particular bit that
allows it to rebind the channels without calling XS_RELEASE first as the
latter has a lot of implications from toolstack point of view.

> In case there is such a need this means we either should just drop the
> test for the mfn to match and recreate the event-channel (which will do
> no harm IMO), or we need to keep the mfn in the live-update state record
> with the knowledge that it is far from being a good indicator for the
> test whether a domain is known already or not (two HVM domains using a
> similar configuration with the very same kernel will use the same gfn
> probably).
> 
> As only dom0 is allowed to use XS_INTRODUCE and I'm not aware of any
> problems with neither XS_INTRODUCE failing due to illegal calls (no mfn
> match), nor with potentially recreating the event channel for a "wrong"
> domain, I suggest to just allow XS_INTRODUCE to be called as often as
> the toolstack wants to.

If that means keeping the current semantics of XS_INTRODUCE - I'd be quite
happy with that.

Igor


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:43:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTmzR-0002LC-Kn; Wed, 29 Apr 2020 13:43:05 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTmzR-0002L7-8L
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:43:05 +0000
X-Inumbo-ID: 59333d6e-8a1f-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 59333d6e-8a1f-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 13:43:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0D1D5AED5;
 Wed, 29 Apr 2020 13:43:01 +0000 (UTC)
Subject: Re: [PATCH] x86/S3: Drop {save,restore}_rest_processor_state()
 completely
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200429110903.15418-1-andrew.cooper3@citrix.com>
 <42c1a2ec-51a1-7b03-aea5-f8ffe80d6928@suse.com>
 <52bdc00f-7778-bd06-14e1-d5c6086466d3@citrix.com>
 <8cfa1ae3-24ef-5885-d758-ccb188e4e4e2@suse.com>
 <afb3cf2d-5d8d-0f4a-b75f-069191871f87@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f13578bf-2143-f63d-1ffb-9b83579fd4b8@suse.com>
Date: Wed, 29 Apr 2020 15:43:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <afb3cf2d-5d8d-0f4a-b75f-069191871f87@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 15:36, Andrew Cooper wrote:
> On 29/04/2020 14:25, Jan Beulich wrote:
>> On 29.04.2020 13:32, Andrew Cooper wrote:
>>> On 29/04/2020 12:16, Jan Beulich wrote:
>>>> On 29.04.2020 13:09, Andrew Cooper wrote:
>>>>> --- a/xen/arch/x86/boot/trampoline.S
>>>>> +++ b/xen/arch/x86/boot/trampoline.S
>>>>> @@ -91,6 +91,11 @@ trampoline_protmode_entry:
>>>>>          and     %edi,%edx
>>>>>          wrmsr
>>>>>  1:
>>>>> +        /* Set up PAT before enabling paging. */
>>>>> +        mov     $XEN_MSR_PAT & 0xffffffff, %eax
>>>>> +        mov     $XEN_MSR_PAT >> 32, %edx
>>>>> +        mov     $MSR_IA32_CR_PAT, %ecx
>>>>> +        wrmsr
>>>> Doesn't this also eliminate the need for cpu_init() doing this?
>>>> If you agree with that one also dropped
>>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>> That doesn't cover the BSP on either the legacy or EFI paths.
>> The legacy path, afaict, uses it:
>>
>> .Lskip_realmode:
>>         /* EBX == 0 indicates we are the BP (Boot Processor). */
>>         xor     %ebx,%ebx
>>
>>         /* Jump to the common bootstrap entry point. */
>>         jmp     trampoline_protmode_entry
> 
> Oh, of course.
> 
>> The xen.efi entry path really should have the change you make
>> mirrored anyway.
> 
> Are you happy for it to go in efi_arch_post_exit_boot()?  We don't
> disable paging, but that is the point where we switch from the EFI
> pagetables to Xen's.

Yes, that's the most "symmetrical" place, I think.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:51:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTn6w-0003AT-Da; Wed, 29 Apr 2020 13:50:50 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTn6v-0003AO-CK
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:50:49 +0000
X-Inumbo-ID: 6e62be16-8a20-11ea-b07b-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6e62be16-8a20-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 13:50:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=N48nF/4JazOXIfCNCTVbQ1nJm/Q+FTp0FlZjJR13mIY=; b=q0c3JsG+YX38kL2pl7f/831sI
 AwCGpazWQh1jOoP6JSCAq176Rj0Y+yYBWVh0UEwN3fKjmx19kBRiDy4csLEerN2NvsP9MJ5XkbJKk
 ZRo2OqwV1Is55kUDgvVhPPSxprb7WP5btBncRg/5O3ERihYUiViXQIumSokxa22JlEhJI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTn6u-0002Ir-7K; Wed, 29 Apr 2020 13:50:48 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTn6t-00028T-VZ; Wed, 29 Apr 2020 13:50:48 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTn6t-0002Z9-Uv; Wed, 29 Apr 2020 13:50:47 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149874-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149874: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f9bf746258eb53011f863571c7073037202b6743
X-Osstest-Versions-That: xen=e9aca9470ed86966f9c0fd0db85132ff28d652c4
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 13:50:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149874 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149874/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  f9bf746258eb53011f863571c7073037202b6743
baseline version:
 xen                  e9aca9470ed86966f9c0fd0db85132ff28d652c4

Last test of basis   149872  2020-04-29 08:02:03 Z    0 days
Testing same since   149874  2020-04-29 11:00:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Wei Liu <liuwe@microsoft.com>
  Wei Liu <wl@xen.org>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   e9aca9470e..f9bf746258  f9bf746258eb53011f863571c7073037202b6743 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:55:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:55:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTnBe-0003U0-Ss; Wed, 29 Apr 2020 13:55:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTnBe-0003Tv-48
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:55:42 +0000
X-Inumbo-ID: 1ce41a16-8a21-11ea-994e-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1ce41a16-8a21-11ea-994e-12813bfff9fa;
 Wed, 29 Apr 2020 13:55:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A898AABBE;
 Wed, 29 Apr 2020 13:55:39 +0000 (UTC)
Subject: Re: [PATCH v2 1/3] x86/pv: Options to disable and/or compile out
 32bit PV support
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200417155004.16806-2-andrew.cooper3@citrix.com>
 <20200429130631.6018-1-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6f629cab-e729-5201-3315-130b0a1d3082@suse.com>
Date: Wed, 29 Apr 2020 15:55:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200429130631.6018-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 15:06, Andrew Cooper wrote:
> This is the start of some performance and security-hardening improvements,
> based on the fact that 32bit PV guests are few and far between these days.
> 
> Ring1 is full of architectural corner cases, such as counting as supervisor
> from a paging point of view.  This accounts for a substantial performance hit
> on processors from the last 8 years (adjusting SMEP/SMAP on every privilege
> transition), and the gap is only going to get bigger with new hardware
> features.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Wei Liu <wl@xen.org>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 13:58:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 13:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTnEi-0003bq-CG; Wed, 29 Apr 2020 13:58:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QE4t=6N=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jTnEg-0003bl-HG
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:58:50 +0000
X-Inumbo-ID: 8d461552-8a21-11ea-994e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8d461552-8a21-11ea-994e-12813bfff9fa;
 Wed, 29 Apr 2020 13:58:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=RyoHK9CWiP4cTF2qLMov6hNKsFgTL3Rt8QhUOblogIs=; b=j38OwX+5FgdgsemPpy4hdkCMtS
 8hMDC1URLzSLHwkNZcSvYGQwa6iDA6RRAPI+9+A1Q2uUR/a8JbqVHVWvOg0lMYeyh4gOtnZ1zKe4Z
 Pv5tNL276aIWvXx+M+bEP85wSeT+tS6CBi/wkZxjw/JdsrqX8V4c/OTiv5olbi8uL6+M=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jTnEf-0002SL-Fs; Wed, 29 Apr 2020 13:58:49 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jTnEf-0005dg-44; Wed, 29 Apr 2020 13:58:49 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] x86/pv: map and unmap page tables in mark_pv_pt_pages_rdonly
Date: Wed, 29 Apr 2020 14:58:28 +0100
Message-Id: <8e1bf04e22f978e93c3e4e60be4c629dd449b8d5.1588168703.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Also, clean up the initialisation of plXe.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

---
Changed since last revision:
- lift this patch out since others in the series have been merged.
- remove lXt variables and reuse plXe for unmapping.
- clean up plXe initialisation.
- drop a Reviewed-by.
---
 xen/arch/x86/pv/dom0_build.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index abfbe5f436..3522eb0114 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -49,18 +49,11 @@ static __init void mark_pv_pt_pages_rdonly(struct domain *d,
 {
     unsigned long count;
     struct page_info *page;
-    l4_pgentry_t *pl4e;
-    l3_pgentry_t *pl3e;
-    l2_pgentry_t *pl2e;
-    l1_pgentry_t *pl1e;
-
-    pl4e = l4start + l4_table_offset(vpt_start);
-    pl3e = l4e_to_l3e(*pl4e);
-    pl3e += l3_table_offset(vpt_start);
-    pl2e = l3e_to_l2e(*pl3e);
-    pl2e += l2_table_offset(vpt_start);
-    pl1e = l2e_to_l1e(*pl2e);
-    pl1e += l1_table_offset(vpt_start);
+    l4_pgentry_t *pl4e = l4start + l4_table_offset(vpt_start);
+    l3_pgentry_t *pl3e = map_l3t_from_l4e(*pl4e) + l3_table_offset(vpt_start);
+    l2_pgentry_t *pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(vpt_start);
+    l1_pgentry_t *pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(vpt_start);
+
     for ( count = 0; count < nr_pt_pages; count++ )
     {
         l1e_remove_flags(*pl1e, _PAGE_RW);
@@ -85,12 +78,21 @@ static __init void mark_pv_pt_pages_rdonly(struct domain *d,
             if ( !((unsigned long)++pl2e & (PAGE_SIZE - 1)) )
             {
                 if ( !((unsigned long)++pl3e & (PAGE_SIZE - 1)) )
-                    pl3e = l4e_to_l3e(*++pl4e);
-                pl2e = l3e_to_l2e(*pl3e);
+                {
+                    /* Need to unmap the page before the increment. */
+                    unmap_domain_page(pl3e - 1);
+                    pl3e = map_l3t_from_l4e(*++pl4e);
+                }
+                unmap_domain_page(pl2e - 1);
+                pl2e = map_l2t_from_l3e(*pl3e);
             }
-            pl1e = l2e_to_l1e(*pl2e);
+            unmap_domain_page(pl1e - 1);
+            pl1e = map_l1t_from_l2e(*pl2e);
         }
     }
+    unmap_domain_page(pl1e);
+    unmap_domain_page(pl2e);
+    unmap_domain_page(pl3e);
 }
 
 static __init void setup_pv_physmap(struct domain *d, unsigned long pgtbl_pfn,
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:01:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTnH7-0004ar-TA; Wed, 29 Apr 2020 14:01:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTnH6-0004am-FI
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:01:20 +0000
X-Inumbo-ID: e628a857-8a21-11ea-994f-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e628a857-8a21-11ea-994f-12813bfff9fa;
 Wed, 29 Apr 2020 14:01:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=i/95LpClsUeFq99vq1tqBaMwmsXIXtcaN8D+iinWUmI=; b=oY1NApYZ0SqS6mQHCQZZ89OTj+
 aKrNwjoW3MaakxUxFg5QF8jPRShzedyUSdBdxcWWK4tZJK2Jqb8nXhA8Vp6DdLLIGM0Q8AoGUsWes
 rXzMBCHWe9KTjzKkPwOzdZQMgNOVwQpgL7TfXPDe6uwb2S02wYcJwuUDZqWTJQ9yHtXE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTnH1-0002bx-0i; Wed, 29 Apr 2020 14:01:15 +0000
Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTnH0-0005zp-Pw; Wed, 29 Apr 2020 14:01:14 +0000
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Jan Beulich <jbeulich@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
 <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
 <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <9eb39857-2e33-4a6b-1825-f9dc537a6515@xen.org>
Date: Wed, 29 Apr 2020 15:01:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 22/04/2020 10:20, Jan Beulich wrote:
>> Even if it was possible to use the sub-structs defined in the header
>> that way, keep in mind that we also wrote:
>>
>>          /* dummy member to force sizeof(struct xen_pvcalls_request)
>>           * to match across archs */
>>          struct xen_pvcalls_dummy {
>>              uint8_t dummy[56];
>>          } dummy;
> 
> This has nothing to do with how a consumer may use the structs.
> 
>> And the spec also clarifies that the size of each specific request is
>> always 56 bytes.
> 
> Sure, and I didn't mean to imply that a consumer would be allowed
> to break this requirement. Still something like this
> 
> int pvcall_new_socket(struct xen_pvcalls_socket *s) {
>      struct xen_pvcalls_request req = {
>          .req_id = REQ_ID,
>          .cmd = PVCALLS_SOCKET,
>          .u.socket = *s,
>      };
> 
>      return pvcall(&req);
> }
> 
> may break.

I think I understand your concern now. So yes I agree this would break 
32-bit consumer.

As the padding is at the end of the structure, I think a 32-bit frontend 
and 64-bit backend (or vice-versa) should currently work without any 
trouble. The problem would come later if we decide to extend a command.

I will document the padding only for non 32-bit x86 guest and rework the 
documentation.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:04:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:04:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTnKA-0004jZ-C2; Wed, 29 Apr 2020 14:04:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTnK9-0004jT-JA
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:04:29 +0000
X-Inumbo-ID: 57672754-8a22-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 57672754-8a22-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 14:04:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=fPrq0LkZOC7k5Uqx95LCrFkonS/mudOdDJGeWNVEmfI=; b=3EmRirxSothWlg8e3QBo7GvY/o
 ET6uYHz4eQIrk1sxq/iW003r5rKMIlJS1yzeFqLubHSofH05SWJ6X8RKVmvnS61BoHuH2TVeZC+ml
 Jvm9oYWXV7ck1VC/umhy5BSRgfMY5mLF4D+/u0TO+myLLvVAVG/mmOLwrx8HwiS+GPQ8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTnK4-0002fv-UJ; Wed, 29 Apr 2020 14:04:24 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTnK4-0006Ay-Lq; Wed, 29 Apr 2020 14:04:24 +0000
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Jan Beulich <jbeulich@suse.com>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
 <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
 <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
 <c8e66108-7ac1-fb51-841f-21886b731f04@xen.org>
 <f02f09ec-b643-8321-e235-ce0ee5526ab3@suse.com>
 <69deb8f4-bafe-734c-f6fa-de41ecf539d2@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <c38f4581-42a6-bb4a-1f84-066528edd3ee@xen.org>
Date: Wed, 29 Apr 2020 15:04:22 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <69deb8f4-bafe-734c-f6fa-de41ecf539d2@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

Gentle ping. Any comments on the direction to take?

On 09/04/2020 10:28, Julien Grall wrote:
> 
> 
> On 09/04/2020 09:06, Jan Beulich wrote:
>> On 09.04.2020 10:01, Julien Grall wrote:
>>> Hi,
>>>
>>> On 09/04/2020 07:30, Jan Beulich wrote:
>>>> On 09.04.2020 00:05, Julien Grall wrote:
>>>> I don't see why a new port may not also want
>>>> to go that route instead of the x86/Arm one.
>>> I could accept that someone would want to reinvent a new ABI
>>> from scratch for just an hypothetical new arch. However it would
>>> be quite an effort to reinvent XEN_GUEST_HANDLE(). The chance is
>>> RISC-V is only going to re-use what Arm did as Arm already did
>>> with x86.
>>>
>>> I would like to avoid to introduce a new directory asm-generic
>>> with just one header in it. Maybe you have some other headers in
>>> mind?
>>
>> I recall having wondered a few times whether we shouldn't use this
>> concept elsewhere. One case iirc was bitops stuff. Looking over
>> the Linux ones, some atomic and barrier fallback implementations
>> may also sensibly live there, and there are likely more.
> 
> In theory it makes sense but, in the current state of Xen, 'asm-generic' 
> means they are common to Arm and x86. This is basically the same 
> definition as for the directory 'xen'. So how do you draw a line which 
> files go where?
> 
> To be honest, I don't think we can draw a line without a 3rd 
> architecture. So I would recommend to wait until then to create an 
> asm-generic directory.
> 
> Meanwhile, I still think the consolidation in xen/ is useful as it makes 
> easier to maintain. It is also going to make easier for RISCv (or a new 
> arch) as they don't have to worry about duplication (if any).
> 
> In the event they decide to purse their own route, then it is not going 
> to be a massive pain to move part of xen/guest_access.h in 
> asm-generic/guest_access.h and include the latter from {xen, asm} 
> /guest_access.h.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:05:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTnL6-0004nK-MJ; Wed, 29 Apr 2020 14:05:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTnL5-0004nB-M1
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:05:27 +0000
X-Inumbo-ID: 79ab65fa-8a22-11ea-994f-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 79ab65fa-8a22-11ea-994f-12813bfff9fa;
 Wed, 29 Apr 2020 14:05:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B29E3AF92;
 Wed, 29 Apr 2020 14:05:24 +0000 (UTC)
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Julien Grall <julien@xen.org>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
 <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
 <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
 <9eb39857-2e33-4a6b-1825-f9dc537a6515@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <423c0369-9c90-dbfe-2f90-d49a2ce5b283@suse.com>
Date: Wed, 29 Apr 2020 16:05:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9eb39857-2e33-4a6b-1825-f9dc537a6515@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 16:01, Julien Grall wrote:
> Hi,
> 
> On 22/04/2020 10:20, Jan Beulich wrote:
>>> Even if it was possible to use the sub-structs defined in the header
>>> that way, keep in mind that we also wrote:
>>>
>>>          /* dummy member to force sizeof(struct xen_pvcalls_request)
>>>           * to match across archs */
>>>          struct xen_pvcalls_dummy {
>>>              uint8_t dummy[56];
>>>          } dummy;
>>
>> This has nothing to do with how a consumer may use the structs.
>>
>>> And the spec also clarifies that the size of each specific request is
>>> always 56 bytes.
>>
>> Sure, and I didn't mean to imply that a consumer would be allowed
>> to break this requirement. Still something like this
>>
>> int pvcall_new_socket(struct xen_pvcalls_socket *s) {
>>      struct xen_pvcalls_request req = {
>>          .req_id = REQ_ID,
>>          .cmd = PVCALLS_SOCKET,
>>          .u.socket = *s,
>>      };
>>
>>      return pvcall(&req);
>> }
>>
>> may break.
> 
> I think I understand your concern now. So yes I agree this would break 32-bit consumer.
> 
> As the padding is at the end of the structure, I think a 32-bit frontend and 64-bit backend (or vice-versa) should currently work without any trouble. The problem would come later if we decide to extend a command.

Can commands be extended at all, i.e. don't extensions require new
commands? The issue I've described has nothing to do with future
extending of any of the affected structures.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:07:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTnNE-0004wj-2x; Wed, 29 Apr 2020 14:07:40 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTnND-0004we-2M
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:07:39 +0000
X-Inumbo-ID: c8315702-8a22-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c8315702-8a22-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 14:07:38 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7277CAC6C;
 Wed, 29 Apr 2020 14:07:36 +0000 (UTC)
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Julien Grall <julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
 <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
 <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
 <c8e66108-7ac1-fb51-841f-21886b731f04@xen.org>
 <f02f09ec-b643-8321-e235-ce0ee5526ab3@suse.com>
 <69deb8f4-bafe-734c-f6fa-de41ecf539d2@xen.org>
 <c38f4581-42a6-bb4a-1f84-066528edd3ee@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <48d591a8-ce4f-2952-19f8-983637c9cfa5@suse.com>
Date: Wed, 29 Apr 2020 16:07:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <c38f4581-42a6-bb4a-1f84-066528edd3ee@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 16:04, Julien Grall wrote:
> Gentle ping. Any comments on the direction to take?

Just to avoid misunderstanding - while the mail was sent with me as
the only one on the To list, I don't think I've been meant, as I've
voiced my opinion. I assume you rather meant to ping others to chime
in?

Jan

> On 09/04/2020 10:28, Julien Grall wrote:
>>
>>
>> On 09/04/2020 09:06, Jan Beulich wrote:
>>> On 09.04.2020 10:01, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 09/04/2020 07:30, Jan Beulich wrote:
>>>>> On 09.04.2020 00:05, Julien Grall wrote:
>>>>> I don't see why a new port may not also want
>>>>> to go that route instead of the x86/Arm one.
>>>> I could accept that someone would want to reinvent a new ABI
>>>> from scratch for just an hypothetical new arch. However it would
>>>> be quite an effort to reinvent XEN_GUEST_HANDLE(). The chance is
>>>> RISC-V is only going to re-use what Arm did as Arm already did
>>>> with x86.
>>>>
>>>> I would like to avoid to introduce a new directory asm-generic
>>>> with just one header in it. Maybe you have some other headers in
>>>> mind?
>>>
>>> I recall having wondered a few times whether we shouldn't use this
>>> concept elsewhere. One case iirc was bitops stuff. Looking over
>>> the Linux ones, some atomic and barrier fallback implementations
>>> may also sensibly live there, and there are likely more.
>>
>> In theory it makes sense but, in the current state of Xen, 'asm-generic' means they are common to Arm and x86. This is basically the same definition as for the directory 'xen'. So how do you draw a line which files go where?
>>
>> To be honest, I don't think we can draw a line without a 3rd architecture. So I would recommend to wait until then to create an asm-generic directory.
>>
>> Meanwhile, I still think the consolidation in xen/ is useful as it makes easier to maintain. It is also going to make easier for RISCv (or a new arch) as they don't have to worry about duplication (if any).
>>
>> In the event they decide to purse their own route, then it is not going to be a massive pain to move part of xen/guest_access.h in asm-generic/guest_access.h and include the latter from {xen, asm} /guest_access.h.
> 
> Cheers,
> 



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:11:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTnQn-0005sG-JH; Wed, 29 Apr 2020 14:11:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTnQm-0005sB-D9
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:11:20 +0000
X-Inumbo-ID: 4c1f8c00-8a23-11ea-9951-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4c1f8c00-8a23-11ea-9951-12813bfff9fa;
 Wed, 29 Apr 2020 14:11:19 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 1C4D1AC6C;
 Wed, 29 Apr 2020 14:11:18 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86/CPUID: correct error indicator for max extended leaf
Message-ID: <fa32442e-158f-f855-efad-09f4d6696adf@suse.com>
Date: Wed, 29 Apr 2020 16:11:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

With the max base leaf using 0, this one should be using the extended
leaf counterpart thereof, rather than some arbitrary extended leaf.

Fixes: 588a966a572e ("libx86: Introduce x86_cpu_policies_are_compatible()")
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/cpu-policy/test-cpu-policy.c
+++ b/tools/tests/cpu-policy/test-cpu-policy.c
@@ -570,7 +570,7 @@ static void test_is_compatible_failure(v
         {
             .name = "Host extd.max_leaf out of range",
             .guest_cpuid.extd.max_leaf = 1,
-            .e = { 0x80000008, -1, -1 },
+            .e = { 0x80000000, -1, -1 },
         },
         {
             .name = "Host no CPUID faulting, Guest wanted",
--- a/xen/lib/x86/policy.c
+++ b/xen/lib/x86/policy.c
@@ -19,7 +19,7 @@ int x86_cpu_policies_are_compatible(cons
         FAIL_CPUID(0, NA);
 
     if ( guest->cpuid->extd.max_leaf > host->cpuid->extd.max_leaf )
-        FAIL_CPUID(0x80000008, NA);
+        FAIL_CPUID(0x80000000, NA);
 
     /* TODO: Audit more CPUID data. */
 


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:13:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTnSl-00060P-1A; Wed, 29 Apr 2020 14:13:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTnSj-00060K-TQ
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:13:21 +0000
X-Inumbo-ID: 94e42ca2-8a23-11ea-b07b-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 94e42ca2-8a23-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 14:13:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=7cRXFVAsjQUAcB1MW95QZdhmmxu4by21uWPG+RodSt0=; b=M0ppYuIrWULkBYEdVAQiggzJG2
 iU6ylyGPp65NXZEFKNTo+EPqEe0KKx6WgBqShJo/xk0Q12Hz9GvLYL4CPUtLfF+rvcOKvgA87xv5k
 RDKW1+DrPhXlpIs9Q5mfHVuOlwWpTtKf/mNZe7w6JAwMKlq9bFsyxo8zrmdt1yISEFxA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTnSf-0002rO-Dx; Wed, 29 Apr 2020 14:13:17 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTnSf-0007BI-6a; Wed, 29 Apr 2020 14:13:17 +0000
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Jan Beulich <jbeulich@suse.com>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
 <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
 <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
 <c8e66108-7ac1-fb51-841f-21886b731f04@xen.org>
 <f02f09ec-b643-8321-e235-ce0ee5526ab3@suse.com>
 <69deb8f4-bafe-734c-f6fa-de41ecf539d2@xen.org>
 <c38f4581-42a6-bb4a-1f84-066528edd3ee@xen.org>
 <48d591a8-ce4f-2952-19f8-983637c9cfa5@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <208798a2-e0e5-916f-cf8d-31a976fa3e39@xen.org>
Date: Wed, 29 Apr 2020 15:13:14 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <48d591a8-ce4f-2952-19f8-983637c9cfa5@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 29/04/2020 15:07, Jan Beulich wrote:
> On 29.04.2020 16:04, Julien Grall wrote:
>> Gentle ping. Any comments on the direction to take?
> 
> Just to avoid misunderstanding - while the mail was sent with me as
> the only one on the To list, I don't think I've been meant, as I've
> voiced my opinion. I assume you rather meant to ping others to chime
> in?

I barely pay attention to CC vs TO. If I am on the list of recipients of 
an e-mail, then I will at least have a glance.

This e-mail is directed to you specifically and also the others. While 
you may have voiced some of your opinion already, you haven't replied 
back how you would decide whether an header should be added in xen or 
asm-generic.

So can you please have another and explain how the line can be drawn 
with just two architectures in place.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:15:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:15:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTnUL-000671-Du; Wed, 29 Apr 2020 14:15:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTnUK-00066w-64
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:15:00 +0000
X-Inumbo-ID: cf62daa4-8a23-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cf62daa4-8a23-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 14:14:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=PVFkJQZhuj4UDnCiCNLSK8NTIxMziKd2mEPqxVB/yvI=; b=4oI9G1nHDMASB+MPmjpdIBchPR
 7a3uHk59GZdjuacgXNkslBNOUTTYvabv15bhHDVLxSF0xK5X8dAHq5s1zCmS9uqNOgoIx+mg+7VGF
 zLiYmzEBpYM5FZrYkcdSuCcUB5zQ9BJBfbDeSkfUiDJHdqfVKvlASboIHoOnV27Qe43k=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTnUH-0002tK-Lm; Wed, 29 Apr 2020 14:14:57 +0000
Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jTnUH-0007F1-Bu; Wed, 29 Apr 2020 14:14:57 +0000
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Jan Beulich <jbeulich@suse.com>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
 <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
 <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
 <9eb39857-2e33-4a6b-1825-f9dc537a6515@xen.org>
 <423c0369-9c90-dbfe-2f90-d49a2ce5b283@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <4cd108f9-3ad0-2262-fa7c-d2247660c635@xen.org>
Date: Wed, 29 Apr 2020 15:14:55 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <423c0369-9c90-dbfe-2f90-d49a2ce5b283@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 29/04/2020 15:05, Jan Beulich wrote:
> On 29.04.2020 16:01, Julien Grall wrote:
>> Hi,
>>
>> On 22/04/2020 10:20, Jan Beulich wrote:
>>>> Even if it was possible to use the sub-structs defined in the header
>>>> that way, keep in mind that we also wrote:
>>>>
>>>>           /* dummy member to force sizeof(struct xen_pvcalls_request)
>>>>            * to match across archs */
>>>>           struct xen_pvcalls_dummy {
>>>>               uint8_t dummy[56];
>>>>           } dummy;
>>>
>>> This has nothing to do with how a consumer may use the structs.
>>>
>>>> And the spec also clarifies that the size of each specific request is
>>>> always 56 bytes.
>>>
>>> Sure, and I didn't mean to imply that a consumer would be allowed
>>> to break this requirement. Still something like this
>>>
>>> int pvcall_new_socket(struct xen_pvcalls_socket *s) {
>>>       struct xen_pvcalls_request req = {
>>>           .req_id = REQ_ID,
>>>           .cmd = PVCALLS_SOCKET,
>>>           .u.socket = *s,
>>>       };
>>>
>>>       return pvcall(&req);
>>> }
>>>
>>> may break.
>>
>> I think I understand your concern now. So yes I agree this would break 32-bit consumer.
>>
>> As the padding is at the end of the structure, I think a 32-bit frontend and 64-bit backend (or vice-versa) should currently work without any trouble. The problem would come later if we decide to extend a command.
> 
> Can commands be extended at all, i.e. don't extensions require new
> commands? The issue I've described has nothing to do with future
> extending of any of the affected structures.

I think my point wasn't conveyed correctly. The implicit padding is at 
the end of the structure for all the consumers but 32-bit x86. So 
without any modification, I think 32-bit frontend can still communicate 
with 64-bit backend (or vice-versa).

Therefore I suggest to rework the documentation and add the implicit 
padding just for all the architectures but 32-bit x86.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:29:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:29:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTni7-0007D2-To; Wed, 29 Apr 2020 14:29:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTni6-0007Cx-RH
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:29:14 +0000
X-Inumbo-ID: cc58919e-8a25-11ea-ae69-bc764e2007e4
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cc58919e-8a25-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 14:29:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588170555;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=QsJPr9iVs6pqzFsZwMChw0wq8FGtmGYc2t1CUvxjZ0E=;
 b=cMe6R79w66lO15WHnAprk5W+aTmC9VVh7xQD+tStKZ+mfY3Hd8FABYix
 XVxa28202UKig7TIx1bz0wuPP4Sjk4D3nEWw7rgO+BLFmTTm38B3GMVY9
 fji/nyZ3iXbEiN24yuur2zgdKc3N26APIMS6TeHZTpDLCj9Y99LQACL34 8=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Q47QSwH1T/DS5B0ActYX3BQu40sA6UWVichvIGhQv22eweOT6gBHgkeeVuEHtztef6rU5hyLwr
 ukCJgeKovpRasPAdwNpp0KxLNPCWw0B0+rSd7Gv6/KHnjzEp5+yzTztf3UeMIMX3tWbOC8b2Mr
 aGwN16dG4NN67xCUDIRIhZGXWckExnmPeNswvEYip1z2VTdnozmTflJvRxykGV/Auo/sfW6RMt
 jAN6hsdT8SobS3pNBtqsV9vhEE6t7jK42X/hsnOCNJsCFVKpFVcyOCVZqDSP17RePYpPTcw8Ir
 gVk=
X-SBRS: 2.7
X-MesageID: 16430618
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16430618"
Subject: Re: [PATCH] x86/CPUID: correct error indicator for max extended leaf
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <fa32442e-158f-f855-efad-09f4d6696adf@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <56366abc-78cc-64f7-f122-bdeac9a8ee3c@citrix.com>
Date: Wed, 29 Apr 2020 15:29:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <fa32442e-158f-f855-efad-09f4d6696adf@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 15:11, Jan Beulich wrote:
> With the max base leaf using 0, this one should be using the extended
> leaf counterpart thereof, rather than some arbitrary extended leaf.
>
> Fixes: 588a966a572e ("libx86: Introduce x86_cpu_policies_are_compatible()")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:50:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:50:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTo2v-0001OO-OB; Wed, 29 Apr 2020 14:50:45 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTo2u-0001OJ-A9
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:50:44 +0000
X-Inumbo-ID: cc7124cc-8a28-11ea-9953-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cc7124cc-8a28-11ea-9953-12813bfff9fa;
 Wed, 29 Apr 2020 14:50:42 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7E2C9AF7F;
 Wed, 29 Apr 2020 14:50:40 +0000 (UTC)
Subject: Re: [PATCH v2 2/5] xen/common/domctl: introduce
 XEN_DOMCTL_get/setdomaincontext
To: Paul Durrant <paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-3-paul@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <70d94284-264b-b03d-1577-fafcf125a9b1@suse.com>
Date: Wed, 29 Apr 2020 16:50:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200407173847.1595-3-paul@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Daniel De Graaf <dgdegra@tycho.nsa.gov>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 19:38, Paul Durrant wrote:
> @@ -358,6 +359,113 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
>      return ERR_PTR(ret);
>  }
>  
> +struct domctl_context
> +{
> +    void *buffer;
> +    size_t len;
> +    size_t cur;
> +};
> +
> +static int accumulate_size(void *priv, const void *data, size_t len)
> +{
> +    struct domctl_context *c = priv;
> +
> +    if ( c->len + len < c->len )
> +        return -EOVERFLOW;
> +
> +    c->len += len;
> +
> +    return 0;
> +}
> +
> +static int save_data(void *priv, const void *data, size_t len)
> +{
> +    struct domctl_context *c = priv;
> +
> +    if ( c->len - c->cur < len )
> +        return -ENOSPC;
> +
> +    memcpy(c->buffer + c->cur, data, len);
> +    c->cur += len;
> +
> +    return 0;
> +}
> +
> +static int getdomaincontext(struct domain *d,
> +                            struct xen_domctl_getdomaincontext *gdc)
> +{
> +    struct domctl_context c = { };

Please can you use ZERO_BLOCK_PTR or some such for the buffer
field, such that errnoeous use of the field would not end up
as a (PV-controllable) NULL deref. (Yes, it's a domctl, but
still.) This being common code you also want to get things
right for Arm, irrespective of whether the code will be dead
there for now.

> +    int rc;
> +
> +    if ( d == current->domain )
> +        return -EPERM;
> +
> +    if ( guest_handle_is_null(gdc->buffer) ) /* query for buffer size */
> +    {
> +        if ( gdc->size )
> +            return -EINVAL;
> +
> +        /* dry run to acquire buffer size */
> +        rc = domain_save(d, accumulate_size, &c, true);
> +        if ( rc )
> +            return rc;
> +
> +        gdc->size = c.len;
> +        return 0;
> +    }
> +
> +    c.len = gdc->size;
> +    c.buffer = xmalloc_bytes(c.len);

What sizes are we looking at here? It may be better to use vmalloc()
right from the start. If not, I'd like to advocate for using
xmalloc_array() instead of xmalloc_bytes() - see the almost-XSA
commit cf38b4926e2b.

> +    if ( !c.buffer )
> +        return -ENOMEM;
> +
> +    rc = domain_save(d, save_data, &c, false);
> +
> +    gdc->size = c.cur;
> +    if ( !rc && copy_to_guest(gdc->buffer, c.buffer, gdc->size) )

As to my remark in patch 1 on the size field, applying to this size
field too - copy_to_user{,_hvm}() don't support a 64-bit value (on
y86 at least).

> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -38,7 +38,7 @@
>  #include "hvm/save.h"
>  #include "memory.h"
>  
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000012
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000013

I don't see you making any change making the interface backwards
incompatible, hence no need for the bump.

> @@ -1129,6 +1129,44 @@ struct xen_domctl_vuart_op {
>                                   */
>  };
>  
> +/*
> + * Get/Set domain PV context. The same struct xen_domctl_domaincontext
> + * is used for both commands but with slightly different field semantics
> + * as follows:
> + *
> + * XEN_DOMCTL_getdomaincontext
> + * ---------------------------
> + *
> + * buffer (IN):   The buffer into which the context data should be
> + *                copied, or NULL to query the buffer size that should
> + *                be allocated.
> + * size (IN/OUT): If 'buffer' is NULL then the value passed in must be
> + *                zero, and the value passed out will be the size of the
> + *                buffer to allocate.
> + *                If 'buffer' is non-NULL then the value passed in must
> + *                be the size of the buffer into which data may be copied.

This leaves open whether the size also gets updated in this latter
case.

> + */
> +struct xen_domctl_getdomaincontext {
> +    uint64_t size;

If this is to remain 64-bits (with too large values suitably taken
care of for all cases - see above), uint64_aligned_t please for
consistency, if nothing else.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:54:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTo6F-0001g4-7q; Wed, 29 Apr 2020 14:54:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTo6E-0001fz-DR
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:54:10 +0000
X-Inumbo-ID: 47faf0be-8a29-11ea-9954-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 47faf0be-8a29-11ea-9954-12813bfff9fa;
 Wed, 29 Apr 2020 14:54:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A18CFABD7;
 Wed, 29 Apr 2020 14:54:07 +0000 (UTC)
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Julien Grall <julien@xen.org>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
 <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
 <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
 <c8e66108-7ac1-fb51-841f-21886b731f04@xen.org>
 <f02f09ec-b643-8321-e235-ce0ee5526ab3@suse.com>
 <69deb8f4-bafe-734c-f6fa-de41ecf539d2@xen.org>
 <c38f4581-42a6-bb4a-1f84-066528edd3ee@xen.org>
 <48d591a8-ce4f-2952-19f8-983637c9cfa5@suse.com>
 <208798a2-e0e5-916f-cf8d-31a976fa3e39@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <a3e48e70-0fff-c4dc-1e46-4e436e8b84e2@suse.com>
Date: Wed, 29 Apr 2020 16:54:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <208798a2-e0e5-916f-cf8d-31a976fa3e39@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 16:13, Julien Grall wrote:
> So can you please have another and explain how the line can be drawn with just two architectures in place.

There are abstract considerations that can be used to draw the
line, as well as knowledge of people on architectures Xen doesn't
run on, but where one can - with such knowledge - extrapolate how
it would want to be implemented.

I don't think the question at this point is where to draw the
line, but whether to have asm-generic/ in the first place.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 14:56:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 14:56:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTo8M-0001n1-Ka; Wed, 29 Apr 2020 14:56:22 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTo8M-0001mw-2M
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 14:56:22 +0000
X-Inumbo-ID: 966a8aa2-8a29-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 966a8aa2-8a29-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 14:56:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 44FBFABD7;
 Wed, 29 Apr 2020 14:56:19 +0000 (UTC)
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Julien Grall <julien@xen.org>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
 <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
 <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
 <9eb39857-2e33-4a6b-1825-f9dc537a6515@xen.org>
 <423c0369-9c90-dbfe-2f90-d49a2ce5b283@suse.com>
 <4cd108f9-3ad0-2262-fa7c-d2247660c635@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <33f4c492-6400-6386-8dbe-b6b098e97fec@suse.com>
Date: Wed, 29 Apr 2020 16:56:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <4cd108f9-3ad0-2262-fa7c-d2247660c635@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 16:14, Julien Grall wrote:
> Hi Jan,
> 
> On 29/04/2020 15:05, Jan Beulich wrote:
>> On 29.04.2020 16:01, Julien Grall wrote:
>>> Hi,
>>>
>>> On 22/04/2020 10:20, Jan Beulich wrote:
>>>>> Even if it was possible to use the sub-structs defined in the header
>>>>> that way, keep in mind that we also wrote:
>>>>>
>>>>>           /* dummy member to force sizeof(struct xen_pvcalls_request)
>>>>>            * to match across archs */
>>>>>           struct xen_pvcalls_dummy {
>>>>>               uint8_t dummy[56];
>>>>>           } dummy;
>>>>
>>>> This has nothing to do with how a consumer may use the structs.
>>>>
>>>>> And the spec also clarifies that the size of each specific request is
>>>>> always 56 bytes.
>>>>
>>>> Sure, and I didn't mean to imply that a consumer would be allowed
>>>> to break this requirement. Still something like this
>>>>
>>>> int pvcall_new_socket(struct xen_pvcalls_socket *s) {
>>>>       struct xen_pvcalls_request req = {
>>>>           .req_id = REQ_ID,
>>>>           .cmd = PVCALLS_SOCKET,
>>>>           .u.socket = *s,
>>>>       };
>>>>
>>>>       return pvcall(&req);
>>>> }
>>>>
>>>> may break.
>>>
>>> I think I understand your concern now. So yes I agree this would break 32-bit consumer.
>>>
>>> As the padding is at the end of the structure, I think a 32-bit frontend and 64-bit backend (or vice-versa) should currently work without any trouble. The problem would come later if we decide to extend a command.
>>
>> Can commands be extended at all, i.e. don't extensions require new
>> commands? The issue I've described has nothing to do with future
>> extending of any of the affected structures.
> 
> I think my point wasn't conveyed correctly. The implicit padding is at
> the end of the structure for all the consumers but 32-bit x86. So
> without any modification, I think 32-bit frontend can still communicate
> with 64-bit backend (or vice-versa).

There's no issue communicating afaics, as for communication
you wouldn't use the sub-structures, but the single container
one. The problem is, as described, with possible uses internal
to one side of the communication.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 15:00:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 15:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jToC3-0002bM-5h; Wed, 29 Apr 2020 15:00:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jToC1-0002bH-GV
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 15:00:09 +0000
X-Inumbo-ID: 1d2884d7-8a2a-11ea-9958-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1d2884d7-8a2a-11ea-9958-12813bfff9fa;
 Wed, 29 Apr 2020 15:00:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 00123AEAA;
 Wed, 29 Apr 2020 15:00:06 +0000 (UTC)
Subject: Re: [PATCH v2] x86/pv: map and unmap page tables in
 mark_pv_pt_pages_rdonly
To: Hongyan Xia <hx242@xen.org>
References: <8e1bf04e22f978e93c3e4e60be4c629dd449b8d5.1588168703.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f2e068c1-ecda-0b20-b5bf-2d6be739f833@suse.com>
Date: Wed, 29 Apr 2020 17:00:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <8e1bf04e22f978e93c3e4e60be4c629dd449b8d5.1588168703.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 15:58, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> 
> Also, clean up the initialisation of plXe.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 15:04:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 15:04:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jToFf-0002uN-Nn; Wed, 29 Apr 2020 15:03:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jToFe-0002uI-Gn
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 15:03:54 +0000
X-Inumbo-ID: a44f7d52-8a2a-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a44f7d52-8a2a-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 15:03:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=xcbd0ibdT6Qilva0QIS3QsLb+OTzX7FjV7RwU7OlFgM=; b=YOqxTH17sT9mU9q1Wb/X28jBkC
 VO0X6lDp6n2rsKyYo7iUsysCNQgs8aMo4p6p1NM89FQ936xwWdNnVHG48QXCoK3wWx5GzNUj7gNxo
 ehR6unvfUPHx43JYPJvbmp2NP6XiMIc8ST9VTkyLmv/ihJujXiGkqptX4RSCi8OfIbos=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jToFa-0003pI-AM; Wed, 29 Apr 2020 15:03:50 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jToFa-0002bm-30; Wed, 29 Apr 2020 15:03:50 +0000
Subject: Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in
 xen/guest_access.h
To: Jan Beulich <jbeulich@suse.com>
References: <20200404131017.27330-1-julien@xen.org>
 <20200404131017.27330-7-julien@xen.org>
 <e2588f6e-1f13-b66f-8e3d-b8568f67b62a@suse.com>
 <041a9f9f-cc9e-eac5-cdd2-555fb1c88e6f@xen.org>
 <cf6c0e0b-ade0-587f-ea0e-80b02b21b1a9@suse.com>
 <c8e66108-7ac1-fb51-841f-21886b731f04@xen.org>
 <f02f09ec-b643-8321-e235-ce0ee5526ab3@suse.com>
 <69deb8f4-bafe-734c-f6fa-de41ecf539d2@xen.org>
 <c38f4581-42a6-bb4a-1f84-066528edd3ee@xen.org>
 <48d591a8-ce4f-2952-19f8-983637c9cfa5@suse.com>
 <208798a2-e0e5-916f-cf8d-31a976fa3e39@xen.org>
 <a3e48e70-0fff-c4dc-1e46-4e436e8b84e2@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <a5c64ae8-5a32-1616-df34-30efb0dfb8de@xen.org>
Date: Wed, 29 Apr 2020 16:03:47 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a3e48e70-0fff-c4dc-1e46-4e436e8b84e2@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 29/04/2020 15:54, Jan Beulich wrote:
> On 29.04.2020 16:13, Julien Grall wrote:
>> So can you please have another and explain how the line can be drawn with just two architectures in place.
> 
> There are abstract considerations that can be used to draw the
> line, as well as knowledge of people on architectures Xen doesn't
> run on, but where one can - with such knowledge - extrapolate how
> it would want to be implemented.
 >
> I don't think the question at this point is where to draw the
> line, but whether to have asm-generic/ in the first place.

Well the two come together. You can't add a new directory with no clear 
view how this is going to be used.

At the moment, this would result at best bikeshedding because 
developpers may have a different opinion on how a new architecture would 
be implemented in Xen.

If you have a 3rd architectures then it would be easier to argue the 
header should be added in asm-generic/ or xen/:
    - asm-generic/ should be used if 2 of the architectures are using 
the same interface
    - xen/ should be if the 3 architectures are using the same interface

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 15:04:36 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 15:04:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jToGK-0002wd-1E; Wed, 29 Apr 2020 15:04:36 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jToGI-0002wV-R8
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 15:04:34 +0000
X-Inumbo-ID: bc15c8b0-8a2a-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id bc15c8b0-8a2a-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 15:04:34 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5727DABD7;
 Wed, 29 Apr 2020 15:04:32 +0000 (UTC)
Subject: Re: [PATCH v2 3/5] tools/misc: add xen-domctx to present domain
 context
To: Paul Durrant <paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-4-paul@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <76e91373-1f7c-bd68-2800-83163fb22aa2@suse.com>
Date: Wed, 29 Apr 2020 17:04:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200407173847.1595-4-paul@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 19:38, Paul Durrant wrote:
> +int main(int argc, char **argv)
> +{
> +    uint32_t domid;
> +    unsigned int entry;
> +    xc_interface *xch;
> +    int rc;
> +
> +    if ( argc != 2 || !argv[1] || (rc = atoi(argv[1])) < 0 )
> +    {
> +        fprintf(stderr, "usage: %s <domid>\n", argv[0]);
> +        exit(1);
> +    }

Perhaps also allow dumping just a single (vCPU or other) ID?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 15:06:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 15:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jToIb-00035s-G0; Wed, 29 Apr 2020 15:06:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jToIa-00035l-Mt
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 15:06:56 +0000
X-Inumbo-ID: 10f8b4dc-8a2b-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 10f8b4dc-8a2b-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 15:06:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=cIT7cIOQOS7x4/SAdKPDnjC8HObYullJAfnmre0sfzk=; b=1J0HK0mEGIjjarsyCAki8gqgJd
 EU95CkkBAsUawtq0mTApeps9xxi6U8kp4OFUZ2SXThtGzIVw/JzfmrBvEa/khSUmgHfgFRmljHB9t
 +9ZXCbKpfVKLadO3625+hi5sf+TLw4ewoZmsZVADP8BnoFv9krwLMgk+7vTG5OFTNNFc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jToIW-0003tf-1x; Wed, 29 Apr 2020 15:06:52 +0000
Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jToIV-0002rp-RW; Wed, 29 Apr 2020 15:06:51 +0000
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Jan Beulich <jbeulich@suse.com>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
 <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
 <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
 <9eb39857-2e33-4a6b-1825-f9dc537a6515@xen.org>
 <423c0369-9c90-dbfe-2f90-d49a2ce5b283@suse.com>
 <4cd108f9-3ad0-2262-fa7c-d2247660c635@xen.org>
 <33f4c492-6400-6386-8dbe-b6b098e97fec@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <d9d7c77c-35d2-9096-7c4b-49f6d0931d5e@xen.org>
Date: Wed, 29 Apr 2020 16:06:49 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <33f4c492-6400-6386-8dbe-b6b098e97fec@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>



On 29/04/2020 15:56, Jan Beulich wrote:
> On 29.04.2020 16:14, Julien Grall wrote:
>> Hi Jan,
>>
>> On 29/04/2020 15:05, Jan Beulich wrote:
>>> On 29.04.2020 16:01, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 22/04/2020 10:20, Jan Beulich wrote:
>>>>>> Even if it was possible to use the sub-structs defined in the header
>>>>>> that way, keep in mind that we also wrote:
>>>>>>
>>>>>>            /* dummy member to force sizeof(struct xen_pvcalls_request)
>>>>>>             * to match across archs */
>>>>>>            struct xen_pvcalls_dummy {
>>>>>>                uint8_t dummy[56];
>>>>>>            } dummy;
>>>>>
>>>>> This has nothing to do with how a consumer may use the structs.
>>>>>
>>>>>> And the spec also clarifies that the size of each specific request is
>>>>>> always 56 bytes.
>>>>>
>>>>> Sure, and I didn't mean to imply that a consumer would be allowed
>>>>> to break this requirement. Still something like this
>>>>>
>>>>> int pvcall_new_socket(struct xen_pvcalls_socket *s) {
>>>>>        struct xen_pvcalls_request req = {
>>>>>            .req_id = REQ_ID,
>>>>>            .cmd = PVCALLS_SOCKET,
>>>>>            .u.socket = *s,
>>>>>        };
>>>>>
>>>>>        return pvcall(&req);
>>>>> }
>>>>>
>>>>> may break.
>>>>
>>>> I think I understand your concern now. So yes I agree this would break 32-bit consumer.
>>>>
>>>> As the padding is at the end of the structure, I think a 32-bit frontend and 64-bit backend (or vice-versa) should currently work without any trouble. The problem would come later if we decide to extend a command.
>>>
>>> Can commands be extended at all, i.e. don't extensions require new
>>> commands? The issue I've described has nothing to do with future
>>> extending of any of the affected structures.
>>
>> I think my point wasn't conveyed correctly. The implicit padding is at
>> the end of the structure for all the consumers but 32-bit x86. So
>> without any modification, I think 32-bit frontend can still communicate
>> with 64-bit backend (or vice-versa).
> 
> There's no issue communicating afaics, as for communication
> you wouldn't use the sub-structures, but the single container
> one. The problem is, as described, with possible uses internal
> to one side of the communication.

I am sorry but I can't figure out how this is an issue. The problem you 
described would only happen if you are calling a 64-bit library from a 
32-bit software. Is it even possible?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 15:23:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 15:23:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jToYM-00051v-1n; Wed, 29 Apr 2020 15:23:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jToYK-00051q-Es
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 15:23:12 +0000
X-Inumbo-ID: 54d4b186-8a2d-11ea-995b-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 54d4b186-8a2d-11ea-995b-12813bfff9fa;
 Wed, 29 Apr 2020 15:23:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2BFF4AC7F;
 Wed, 29 Apr 2020 15:23:07 +0000 (UTC)
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Julien Grall <julien@xen.org>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
 <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
 <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
 <9eb39857-2e33-4a6b-1825-f9dc537a6515@xen.org>
 <423c0369-9c90-dbfe-2f90-d49a2ce5b283@suse.com>
 <4cd108f9-3ad0-2262-fa7c-d2247660c635@xen.org>
 <33f4c492-6400-6386-8dbe-b6b098e97fec@suse.com>
 <d9d7c77c-35d2-9096-7c4b-49f6d0931d5e@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <1494fe06-b353-00a5-17a6-c11cee269519@suse.com>
Date: Wed, 29 Apr 2020 17:23:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d9d7c77c-35d2-9096-7c4b-49f6d0931d5e@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 17:06, Julien Grall wrote:
> 
> 
> On 29/04/2020 15:56, Jan Beulich wrote:
>> On 29.04.2020 16:14, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 29/04/2020 15:05, Jan Beulich wrote:
>>>> On 29.04.2020 16:01, Julien Grall wrote:
>>>>> Hi,
>>>>>
>>>>> On 22/04/2020 10:20, Jan Beulich wrote:
>>>>>>> Even if it was possible to use the sub-structs defined in the header
>>>>>>> that way, keep in mind that we also wrote:
>>>>>>>
>>>>>>>            /* dummy member to force sizeof(struct xen_pvcalls_request)
>>>>>>>             * to match across archs */
>>>>>>>            struct xen_pvcalls_dummy {
>>>>>>>                uint8_t dummy[56];
>>>>>>>            } dummy;
>>>>>>
>>>>>> This has nothing to do with how a consumer may use the structs.
>>>>>>
>>>>>>> And the spec also clarifies that the size of each specific request is
>>>>>>> always 56 bytes.
>>>>>>
>>>>>> Sure, and I didn't mean to imply that a consumer would be allowed
>>>>>> to break this requirement. Still something like this
>>>>>>
>>>>>> int pvcall_new_socket(struct xen_pvcalls_socket *s) {
>>>>>>        struct xen_pvcalls_request req = {
>>>>>>            .req_id = REQ_ID,
>>>>>>            .cmd = PVCALLS_SOCKET,
>>>>>>            .u.socket = *s,
>>>>>>        };
>>>>>>
>>>>>>        return pvcall(&req);
>>>>>> }
>>>>>>
>>>>>> may break.
>>>>>
>>>>> I think I understand your concern now. So yes I agree this would break 32-bit consumer.
>>>>>
>>>>> As the padding is at the end of the structure, I think a 32-bit frontend and 64-bit backend (or vice-versa) should currently work without any trouble. The problem would come later if we decide to extend a command.
>>>>
>>>> Can commands be extended at all, i.e. don't extensions require new
>>>> commands? The issue I've described has nothing to do with future
>>>> extending of any of the affected structures.
>>>
>>> I think my point wasn't conveyed correctly. The implicit padding is at
>>> the end of the structure for all the consumers but 32-bit x86. So
>>> without any modification, I think 32-bit frontend can still communicate
>>> with 64-bit backend (or vice-versa).
>>
>> There's no issue communicating afaics, as for communication
>> you wouldn't use the sub-structures, but the single container
>> one. The problem is, as described, with possible uses internal
>> to one side of the communication.
> 
> I am sorry but I can't figure out how this is an issue. The
> problem you described would only happen if you are calling a
> 64-bit library from a 32-bit software.

Why? The example given doesn't require such.

> Is it even possible?

In principle yes, I think. I don't think OSes like Linux allow this,
though.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 15:30:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 15:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTofk-0005qr-RL; Wed, 29 Apr 2020 15:30:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=2IrC=6N=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jTofj-0005qm-0x
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 15:30:51 +0000
X-Inumbo-ID: 677ce262-8a2e-11ea-995f-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 677ce262-8a2e-11ea-995f-12813bfff9fa;
 Wed, 29 Apr 2020 15:30:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ijjegwEn0CAzh+QSqwb8f+T0GHqZbpbNPXUWw44g7O8=; b=HVWNs9jYZPzce/6MDiL7UcaBG5
 J5P0o6reth+TuCymSBOa3ugK8GnZ/CpVsEDm7GbR2nc/iGzZBZQuSiXgTYTmt6xjNHp7wJvlSJ2Ck
 D178tDbVRZ7OQDiQrcxyp7VjlF3lhf+7V7KjQmpbH9b3O7JF2xmYlJkMQyTT0B012joc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jTofg-0004K3-5p; Wed, 29 Apr 2020 15:30:48 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jToff-0004Sm-TK; Wed, 29 Apr 2020 15:30:48 +0000
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Jan Beulich <jbeulich@suse.com>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
 <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
 <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
 <9eb39857-2e33-4a6b-1825-f9dc537a6515@xen.org>
 <423c0369-9c90-dbfe-2f90-d49a2ce5b283@suse.com>
 <4cd108f9-3ad0-2262-fa7c-d2247660c635@xen.org>
 <33f4c492-6400-6386-8dbe-b6b098e97fec@suse.com>
 <d9d7c77c-35d2-9096-7c4b-49f6d0931d5e@xen.org>
 <1494fe06-b353-00a5-17a6-c11cee269519@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <92be4ce7-3963-7ee6-7ee2-28a180411c9c@xen.org>
Date: Wed, 29 Apr 2020 16:30:45 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1494fe06-b353-00a5-17a6-c11cee269519@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 29/04/2020 16:23, Jan Beulich wrote:
> On 29.04.2020 17:06, Julien Grall wrote:
>>
>>
>> On 29/04/2020 15:56, Jan Beulich wrote:
>>> On 29.04.2020 16:14, Julien Grall wrote:
>>>> Hi Jan,
>>>>
>>>> On 29/04/2020 15:05, Jan Beulich wrote:
>>>>> On 29.04.2020 16:01, Julien Grall wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 22/04/2020 10:20, Jan Beulich wrote:
>>>>>>>> Even if it was possible to use the sub-structs defined in the header
>>>>>>>> that way, keep in mind that we also wrote:
>>>>>>>>
>>>>>>>>             /* dummy member to force sizeof(struct xen_pvcalls_request)
>>>>>>>>              * to match across archs */
>>>>>>>>             struct xen_pvcalls_dummy {
>>>>>>>>                 uint8_t dummy[56];
>>>>>>>>             } dummy;
>>>>>>>
>>>>>>> This has nothing to do with how a consumer may use the structs.
>>>>>>>
>>>>>>>> And the spec also clarifies that the size of each specific request is
>>>>>>>> always 56 bytes.
>>>>>>>
>>>>>>> Sure, and I didn't mean to imply that a consumer would be allowed
>>>>>>> to break this requirement. Still something like this
>>>>>>>
>>>>>>> int pvcall_new_socket(struct xen_pvcalls_socket *s) {
>>>>>>>         struct xen_pvcalls_request req = {
>>>>>>>             .req_id = REQ_ID,
>>>>>>>             .cmd = PVCALLS_SOCKET,
>>>>>>>             .u.socket = *s,
>>>>>>>         };
>>>>>>>
>>>>>>>         return pvcall(&req);
>>>>>>> }
>>>>>>>
>>>>>>> may break.
>>>>>>
>>>>>> I think I understand your concern now. So yes I agree this would break 32-bit consumer.
>>>>>>
>>>>>> As the padding is at the end of the structure, I think a 32-bit frontend and 64-bit backend (or vice-versa) should currently work without any trouble. The problem would come later if we decide to extend a command.
>>>>>
>>>>> Can commands be extended at all, i.e. don't extensions require new
>>>>> commands? The issue I've described has nothing to do with future
>>>>> extending of any of the affected structures.
>>>>
>>>> I think my point wasn't conveyed correctly. The implicit padding is at
>>>> the end of the structure for all the consumers but 32-bit x86. So
>>>> without any modification, I think 32-bit frontend can still communicate
>>>> with 64-bit backend (or vice-versa).
>>>
>>> There's no issue communicating afaics, as for communication
>>> you wouldn't use the sub-structures, but the single container
>>> one. The problem is, as described, with possible uses internal
>>> to one side of the communication.
>>
>> I am sorry but I can't figure out how this is an issue. The
>> problem you described would only happen if you are calling a
>> 64-bit library from a 32-bit software.
> 
> Why? The example given doesn't require such.

Your example is only valid if we change the padding. In my previous 
e-mail I wrote "without modification" (i.e existing code) and marking 
the implicit padding only for 64-bit x86 and Arm. So there is no change 
in the size of the structure and therefore there is no issue to 
recompile as the size would not change.

>> Is it even possible?
> 
> In principle yes, I think. I don't think OSes like Linux allow this,
> though.
Do we really have to care about this?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 15:58:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 15:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTp66-00084e-0M; Wed, 29 Apr 2020 15:58:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yqvu=6N=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jTp65-00084Z-Jw
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 15:58:05 +0000
X-Inumbo-ID: 34104781-8a32-11ea-9964-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 34104781-8a32-11ea-9964-12813bfff9fa;
 Wed, 29 Apr 2020 15:58:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 11BAFAB91;
 Wed, 29 Apr 2020 15:58:01 +0000 (UTC)
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
To: Julien Grall <julien@xen.org>
References: <20200419104948.31200-1-julien@xen.org>
 <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
 <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org>
 <6fc59120-664e-6a07-5196-57e1dbfb0dde@suse.com>
 <alpine.DEB.2.21.2004211609410.24585@sstabellini-ThinkPad-T480s>
 <240bc5e8-f8fd-217a-fa10-7628ac9d4e6e@suse.com>
 <9eb39857-2e33-4a6b-1825-f9dc537a6515@xen.org>
 <423c0369-9c90-dbfe-2f90-d49a2ce5b283@suse.com>
 <4cd108f9-3ad0-2262-fa7c-d2247660c635@xen.org>
 <33f4c492-6400-6386-8dbe-b6b098e97fec@suse.com>
 <d9d7c77c-35d2-9096-7c4b-49f6d0931d5e@xen.org>
 <1494fe06-b353-00a5-17a6-c11cee269519@suse.com>
 <92be4ce7-3963-7ee6-7ee2-28a180411c9c@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <2bb47891-bf3c-1bb4-8c54-02f6a7ea4676@suse.com>
Date: Wed, 29 Apr 2020 17:57:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <92be4ce7-3963-7ee6-7ee2-28a180411c9c@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 17:30, Julien Grall wrote:
> Hi Jan,
> 
> On 29/04/2020 16:23, Jan Beulich wrote:
>> On 29.04.2020 17:06, Julien Grall wrote:
>>>
>>>
>>> On 29/04/2020 15:56, Jan Beulich wrote:
>>>> On 29.04.2020 16:14, Julien Grall wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 29/04/2020 15:05, Jan Beulich wrote:
>>>>>> On 29.04.2020 16:01, Julien Grall wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 22/04/2020 10:20, Jan Beulich wrote:
>>>>>>>>> Even if it was possible to use the sub-structs defined in the header
>>>>>>>>> that way, keep in mind that we also wrote:
>>>>>>>>>
>>>>>>>>>             /* dummy member to force sizeof(struct xen_pvcalls_request)
>>>>>>>>>              * to match across archs */
>>>>>>>>>             struct xen_pvcalls_dummy {
>>>>>>>>>                 uint8_t dummy[56];
>>>>>>>>>             } dummy;
>>>>>>>>
>>>>>>>> This has nothing to do with how a consumer may use the structs.
>>>>>>>>
>>>>>>>>> And the spec also clarifies that the size of each specific request is
>>>>>>>>> always 56 bytes.
>>>>>>>>
>>>>>>>> Sure, and I didn't mean to imply that a consumer would be allowed
>>>>>>>> to break this requirement. Still something like this
>>>>>>>>
>>>>>>>> int pvcall_new_socket(struct xen_pvcalls_socket *s) {
>>>>>>>>         struct xen_pvcalls_request req = {
>>>>>>>>             .req_id = REQ_ID,
>>>>>>>>             .cmd = PVCALLS_SOCKET,
>>>>>>>>             .u.socket = *s,
>>>>>>>>         };
>>>>>>>>
>>>>>>>>         return pvcall(&req);
>>>>>>>> }
>>>>>>>>
>>>>>>>> may break.
>>>>>>>
>>>>>>> I think I understand your concern now. So yes I agree this would break 32-bit consumer.
>>>>>>>
>>>>>>> As the padding is at the end of the structure, I think a 32-bit frontend and 64-bit backend (or vice-versa) should currently work without any trouble. The problem would come later if we decide to extend a command.
>>>>>>
>>>>>> Can commands be extended at all, i.e. don't extensions require new
>>>>>> commands? The issue I've described has nothing to do with future
>>>>>> extending of any of the affected structures.
>>>>>
>>>>> I think my point wasn't conveyed correctly. The implicit padding is at
>>>>> the end of the structure for all the consumers but 32-bit x86. So
>>>>> without any modification, I think 32-bit frontend can still communicate
>>>>> with 64-bit backend (or vice-versa).
>>>>
>>>> There's no issue communicating afaics, as for communication
>>>> you wouldn't use the sub-structures, but the single container
>>>> one. The problem is, as described, with possible uses internal
>>>> to one side of the communication.
>>>
>>> I am sorry but I can't figure out how this is an issue. The
>>> problem you described would only happen if you are calling a
>>> 64-bit library from a 32-bit software.
>>
>> Why? The example given doesn't require such.
> 
> Your example is only valid if we change the padding. In my previous
> e-mail I wrote "without modification" (i.e existing code) and
> marking the implicit padding only for 64-bit x86 and Arm. So there
> is no change in the size of the structure and therefore there is no
> issue to recompile as the size would not change.

Oh, sorry, yes. I was mislead by "I think 32-bit frontend can still
communicate with 64-bit backend (or vice-versa)", because I never
said there would be such an issue.

>>> Is it even possible?
>>
>> In principle yes, I think. I don't think OSes like Linux allow this,
>> though.
> Do we really have to care about this?

I don't think we do, but this is a moot point anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 16:08:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 16:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTpGF-0001DQ-Ut; Wed, 29 Apr 2020 16:08:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=uIcr=6N=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jTpGE-0001DL-PX
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 16:08:34 +0000
X-Inumbo-ID: acda2e01-8a33-11ea-9965-12813bfff9fa
Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id acda2e01-8a33-11ea-9965-12813bfff9fa;
 Wed, 29 Apr 2020 16:08:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588176513;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:
 content-transfer-encoding:content-transfer-encoding;
 bh=RqcnavPFirGVOTXHhjY5q5DM9FLFgis6bxz7RvWdVJE=;
 b=QZPrrd8zNNebgZXnzhIAYA2aP84wbXzXTC4SfYYO6rv5ju2/aeWwsXYRoUwkzVKNDRurdJ
 YxExOEc0hr+rJQkkFgPUr+ph31cSB3GXU2c+/TgswYJtJaAdE4hLZ9KBhaCdgY7s0ei/vk
 ZW/gaMqEpwiuaxXcYVMdRLbEU5DvYnE=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-480-F36vCcGRMVu93iH7TXheIg-1; Wed, 29 Apr 2020 12:08:26 -0400
X-MC-Unique: F36vCcGRMVu93iH7TXheIg-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E4E0C1895A28;
 Wed, 29 Apr 2020 16:08:21 +0000 (UTC)
Received: from t480s.redhat.com (ovpn-114-55.ams2.redhat.com [10.36.114.55])
 by smtp.corp.redhat.com (Postfix) with ESMTP id BAF7C605FB;
 Wed, 29 Apr 2020 16:08:07 +0000 (UTC)
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with
 kexec-tools
Date: Wed, 29 Apr 2020 18:08:00 +0200
Message-Id: <20200429160803.109056-1-david@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: linux-hyperv@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
 "Michael S . Tsirkin" <mst@redhat.com>,
 Benjamin Herrenschmidt <benh@kernel.crashing.org>,
 Jason Wang <jasowang@redhat.com>, Heiko Carstens <heiko.carstens@de.ibm.com>,
 Pingfan Liu <kernelfans@gmail.com>, virtualization@lists.linux-foundation.org,
 linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
 "K. Y. Srinivasan" <kys@microsoft.com>,
 Dan Williams <dan.j.williams@intel.com>, virtio-dev@lists.oasis-open.org,
 Wei Liu <wei.liu@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Dave Jiang <dave.jiang@intel.com>, Baoquan He <bhe@redhat.com>,
 linux-nvdimm@lists.01.org, Michael Ellerman <mpe@ellerman.id.au>,
 David Hildenbrand <david@redhat.com>, linux-acpi@vger.kernel.org,
 Wei Yang <richard.weiyang@gmail.com>, xen-devel@lists.xenproject.org,
 Len Brown <lenb@kernel.org>, Nathan Lynch <nathanl@linux.ibm.com>,
 Stephen Hemminger <sthemmin@microsoft.com>, Vasily Gorbik <gor@linux.ibm.com>,
 linux-s390@vger.kernel.org, Haiyang Zhang <haiyangz@microsoft.com>,
 Leonardo Bras <leobras.c@gmail.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, Michal Hocko <mhocko@kernel.org>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Oscar Salvador <osalvador@suse.de>, Juergen Gross <jgross@suse.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "Rafael J. Wysocki" <rjw@rjwysocki.net>, Thomas Gleixner <tglx@linutronix.de>,
 Eric Biederman <ebiederm@xmission.com>,
 Vishal Verma <vishal.l.verma@intel.com>,
 Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This series is based on [1]:
	[PATCH v2 00/10] virtio-mem: paravirtualized memory
That will hopefull get picked up soon, rebased to -next.

The following patches were reverted from -next [2]:
	[PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use
As discussed in that thread, they should be reverted from -next already.

In theory, if people agree, we could take the first two patches via the
-mm tree now and the last (virtio-mem) patch via MST's tree once picking =
up
virtio-mem. No strong feelings.


Memory added by virtio-mem is special and might contain logical holes,
especially after memory unplug, but also when adding memory in
sub-section size. While memory in these holes can usually be read, that
memory should not be touched. virtio-mem managed device memory is never
exposed via any firmware memmap (esp., e820). The device driver will
request to plug memory from the hypervisor and add it to Linux.

On a cold start, all memory is unplugged, and the guest driver will first
request to plug memory from the hypervisor, to then add it to Linux. Afte=
r
a reboot, all memory will get unplugged (except in rare, special cases). =
In
case the device driver comes up and detects that some memory is still
plugged after a reboot, it will manually request to unplug all memory fro=
m
the hypervisor first - to then request to plug memory from the hypervisor
and add to Linux. This is essentially a defragmentation step, where all
logical holes are removed.

As the device driver is responsible for detecting, adding and managing th=
at
memory, also kexec should treat it like that. It is special. We need a wa=
y
to teach kexec-tools to not add that memory to the fixed-up firmware
memmap, to not place kexec images onto this memory, but still allow kdump
to dump it. Add a flag to tell memory hotplug code to
not create /sys/firmware/memmap entries and to indicate it via
"System RAM (driver managed)" in /proc/iomem.

Before this series, kexec_file_load() already did the right thing (for
virtio-mem) by not adding that memory to the fixed-up firmware memmap and
letting the device driver handle it. With this series, also kexec_load() =
-
which relies on user space to provide a fixed up firmware memmap - does
the right thing with virtio-mem memory.

When the virtio-mem device driver(s) come up, they will request to unplug
all memory from the hypervisor first (esp. defragment), to then request t=
o
plug consecutive memory ranges from the hypervisor, and add them to Linux
- just like on a reboot where we still have memory plugged.

[1] https://lore.kernel.org/r/20200311171422.10484-1-david@redhat.com/
[2] https://lore.kernel.org/r/20200326180730.4754-1-james.morse@arm.com

David Hildenbrand (3):
  mm/memory_hotplug: Prepare passing flags to add_memory() and friends
  mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
  virtio-mem: Add memory with MHP_DRIVER_MANAGED

 arch/powerpc/platforms/powernv/memtrace.c     |  2 +-
 .../platforms/pseries/hotplug-memory.c        |  2 +-
 drivers/acpi/acpi_memhotplug.c                |  2 +-
 drivers/base/memory.c                         |  2 +-
 drivers/dax/kmem.c                            |  2 +-
 drivers/hv/hv_balloon.c                       |  2 +-
 drivers/s390/char/sclp_cmd.c                  |  2 +-
 drivers/virtio/virtio_mem.c                   |  3 +-
 drivers/xen/balloon.c                         |  2 +-
 include/linux/memory_hotplug.h                | 15 +++++++--
 mm/memory_hotplug.c                           | 31 +++++++++++++------
 11 files changed, 44 insertions(+), 21 deletions(-)

--=20
2.25.3



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 16:08:47 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 16:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTpGR-0001Ea-6j; Wed, 29 Apr 2020 16:08:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=uIcr=6N=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jTpGQ-0001EP-4s
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 16:08:46 +0000
X-Inumbo-ID: b3aa2d70-8a33-11ea-b07b-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id b3aa2d70-8a33-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 16:08:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588176524;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=XYhvWnh78BGQe9YyWp6wcKx6XbrYaXpSvd1mbPRPY60=;
 b=M1sZqX0QD6fQbYwExxTu0mo9fr7B/L/HNn7A6SxPLGybih3/yMG+mGMNTeTKlXsvYeKE/9
 yPIXVzggqpItdDhguMpYu8Mk/1LQJCCklTkshkaQenW6dkH9Ox8ICMfRT0Ss+zbcSeKtcd
 t5AeWikw89bfFRTTky0hpqB14dTDrkU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-399-2bUbEQbdOxe-eNDNJjJLWA-1; Wed, 29 Apr 2020 12:08:36 -0400
X-MC-Unique: 2bUbEQbdOxe-eNDNJjJLWA-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2D3D8108597A;
 Wed, 29 Apr 2020 16:08:32 +0000 (UTC)
Received: from t480s.redhat.com (ovpn-114-55.ams2.redhat.com [10.36.114.55])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 434A0605DD;
 Wed, 29 Apr 2020 16:08:24 +0000 (UTC)
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH v1 1/3] mm/memory_hotplug: Prepare passing flags to
 add_memory() and friends
Date: Wed, 29 Apr 2020 18:08:01 +0200
Message-Id: <20200429160803.109056-2-david@redhat.com>
In-Reply-To: <20200429160803.109056-1-david@redhat.com>
References: <20200429160803.109056-1-david@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: linux-hyperv@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
 "Michael S . Tsirkin" <mst@redhat.com>,
 Benjamin Herrenschmidt <benh@kernel.crashing.org>,
 Jason Wang <jasowang@redhat.com>, Heiko Carstens <heiko.carstens@de.ibm.com>,
 Pingfan Liu <kernelfans@gmail.com>, virtualization@lists.linux-foundation.org,
 linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
 "K. Y. Srinivasan" <kys@microsoft.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, virtio-dev@lists.oasis-open.org,
 Wei Liu <wei.liu@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Dave Jiang <dave.jiang@intel.com>, Baoquan He <bhe@redhat.com>,
 linux-nvdimm@lists.01.org, Vishal Verma <vishal.l.verma@intel.com>,
 David Hildenbrand <david@redhat.com>, linux-acpi@vger.kernel.org,
 Wei Yang <richard.weiyang@gmail.com>, xen-devel@lists.xenproject.org,
 Len Brown <lenb@kernel.org>, Nathan Lynch <nathanl@linux.ibm.com>,
 Vasily Gorbik <gor@linux.ibm.com>, linux-s390@vger.kernel.org,
 Haiyang Zhang <haiyangz@microsoft.com>, Leonardo Bras <leobras.c@gmail.com>,
 Stephen Hemminger <sthemmin@microsoft.com>,
 Dan Williams <dan.j.williams@intel.com>, Michal Hocko <mhocko@kernel.org>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Oscar Salvador <osalvador@suse.de>, Juergen Gross <jgross@suse.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "Rafael J. Wysocki" <rjw@rjwysocki.net>, Thomas Gleixner <tglx@linutronix.de>,
 Eric Biederman <ebiederm@xmission.com>, Michael Ellerman <mpe@ellerman.id.au>,
 Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We soon want to pass flags - prepare for that.

This patch is based on a similar patch by Oscar Salvador:

https://lkml.kernel.org/r/20190625075227.15193-3-osalvador@suse.de

Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Leonardo Bras <leobras.c@gmail.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-nvdimm@lists.01.org
Cc: linux-hyperv@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 arch/powerpc/platforms/powernv/memtrace.c       |  2 +-
 arch/powerpc/platforms/pseries/hotplug-memory.c |  2 +-
 drivers/acpi/acpi_memhotplug.c                  |  2 +-
 drivers/base/memory.c                           |  2 +-
 drivers/dax/kmem.c                              |  2 +-
 drivers/hv/hv_balloon.c                         |  2 +-
 drivers/s390/char/sclp_cmd.c                    |  2 +-
 drivers/virtio/virtio_mem.c                     |  2 +-
 drivers/xen/balloon.c                           |  2 +-
 include/linux/memory_hotplug.h                  |  7 ++++---
 mm/memory_hotplug.c                             | 11 ++++++-----
 11 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/pla=
tforms/powernv/memtrace.c
index 13b369d2cc45..a7475d18c671 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -224,7 +224,7 @@ static int memtrace_online(void)
 			ent->mem =3D 0;
 		}
=20
-		if (add_memory(ent->nid, ent->start, ent->size)) {
+		if (add_memory(ent->nid, ent->start, ent->size, 0)) {
 			pr_err("Failed to add trace memory to node %d\n",
 				ent->nid);
 			ret +=3D 1;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/power=
pc/platforms/pseries/hotplug-memory.c
index 5ace2f9a277e..ae44eba46ca0 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -646,7 +646,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
 	block_sz =3D memory_block_size_bytes();
=20
 	/* Add the memory */
-	rc =3D __add_memory(lmb->nid, lmb->base_addr, block_sz);
+	rc =3D __add_memory(lmb->nid, lmb->base_addr, block_sz, 0);
 	if (rc) {
 		invalidate_lmb_associativity_index(lmb);
 		return rc;
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplu=
g.c
index e294f44a7850..d91b3584d4b2 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -207,7 +207,7 @@ static int acpi_memory_enable_device(struct acpi_memo=
ry_device *mem_device)
 		if (node < 0)
 			node =3D memory_add_physaddr_to_nid(info->start_addr);
=20
-		result =3D __add_memory(node, info->start_addr, info->length);
+		result =3D __add_memory(node, info->start_addr, info->length, 0);
=20
 		/*
 		 * If the memory block has been used by the kernel, add_memory()
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 2b09b68b9f78..c0ef7d9e310a 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -432,7 +432,7 @@ static ssize_t probe_store(struct device *dev, struct=
 device_attribute *attr,
=20
 	nid =3D memory_add_physaddr_to_nid(phys_addr);
 	ret =3D __add_memory(nid, phys_addr,
-			   MIN_MEMORY_BLOCK_SIZE * sections_per_block);
+			   MIN_MEMORY_BLOCK_SIZE * sections_per_block, 0);
=20
 	if (ret)
 		goto out;
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 3d0a7e702c94..e159184e0ba0 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -65,7 +65,7 @@ int dev_dax_kmem_probe(struct device *dev)
 	new_res->flags =3D IORESOURCE_SYSTEM_RAM;
 	new_res->name =3D dev_name(dev);
=20
-	rc =3D add_memory(numa_node, new_res->start, resource_size(new_res));
+	rc =3D add_memory(numa_node, new_res->start, resource_size(new_res), 0)=
;
 	if (rc) {
 		release_resource(new_res);
 		kfree(new_res);
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 32e3bc0aa665..0194bed1a573 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -726,7 +726,7 @@ static void hv_mem_hot_add(unsigned long start, unsig=
ned long size,
=20
 		nid =3D memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
 		ret =3D add_memory(nid, PFN_PHYS((start_pfn)),
-				(HA_CHUNK << PAGE_SHIFT));
+				(HA_CHUNK << PAGE_SHIFT), 0);
=20
 		if (ret) {
 			pr_err("hot_add memory failed error is %d\n", ret);
diff --git a/drivers/s390/char/sclp_cmd.c b/drivers/s390/char/sclp_cmd.c
index a864b21af602..a6a908244c74 100644
--- a/drivers/s390/char/sclp_cmd.c
+++ b/drivers/s390/char/sclp_cmd.c
@@ -406,7 +406,7 @@ static void __init add_memory_merged(u16 rn)
 	if (!size)
 		goto skip_add;
 	for (addr =3D start; addr < start + size; addr +=3D block_size)
-		add_memory(0, addr, block_size);
+		add_memory(0, addr, block_size, 0);
 skip_add:
 	first_rn =3D rn;
 	num =3D 1;
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 96e687531933..3101cbf9e59d 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -421,7 +421,7 @@ static int virtio_mem_mb_add(struct virtio_mem *vm, u=
nsigned long mb_id)
 		nid =3D memory_add_physaddr_to_nid(addr);
=20
 	dev_dbg(&vm->vdev->dev, "adding memory block: %lu\n", mb_id);
-	return add_memory(nid, addr, memory_block_size_bytes());
+	return add_memory(nid, addr, memory_block_size_bytes(), 0);
 }
=20
 /*
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 0c142bcab79d..6ec0373fa624 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -347,7 +347,7 @@ static enum bp_state reserve_additional_memory(void)
 	mutex_unlock(&balloon_mutex);
 	/* add_memory_resource() requires the device_hotplug lock */
 	lock_device_hotplug();
-	rc =3D add_memory_resource(nid, resource);
+	rc =3D add_memory_resource(nid, resource, 0);
 	unlock_device_hotplug();
 	mutex_lock(&balloon_mutex);
=20
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplu=
g.h
index d641828e5596..bf0e3edb8688 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -340,9 +340,10 @@ extern void set_zone_contiguous(struct zone *zone);
 extern void clear_zone_contiguous(struct zone *zone);
=20
 extern void __ref free_area_init_core_hotplug(int nid);
-extern int __add_memory(int nid, u64 start, u64 size);
-extern int add_memory(int nid, u64 start, u64 size);
-extern int add_memory_resource(int nid, struct resource *resource);
+extern int __add_memory(int nid, u64 start, u64 size, unsigned long flag=
s);
+extern int add_memory(int nid, u64 start, u64 size, unsigned long flags)=
;
+extern int add_memory_resource(int nid, struct resource *resource,
+			       unsigned long flags);
 extern void move_pfn_range_to_zone(struct zone *zone, unsigned long star=
t_pfn,
 		unsigned long nr_pages, struct vmem_altmap *altmap);
 extern void remove_pfn_range_from_zone(struct zone *zone,
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 4ac6395ee2fc..ebdf6541d074 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1000,7 +1000,8 @@ static int online_memory_block(struct memory_block =
*mem, void *arg)
  *
  * we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLU=
G
  */
-int __ref add_memory_resource(int nid, struct resource *res)
+int __ref add_memory_resource(int nid, struct resource *res,
+			      unsigned long flags)
 {
 	struct mhp_params params =3D { .pgprot =3D PAGE_KERNEL };
 	u64 start, size;
@@ -1078,7 +1079,7 @@ int __ref add_memory_resource(int nid, struct resou=
rce *res)
 }
=20
 /* requires device_hotplug_lock, see add_memory_resource() */
-int __ref __add_memory(int nid, u64 start, u64 size)
+int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags=
)
 {
 	struct resource *res;
 	int ret;
@@ -1087,18 +1088,18 @@ int __ref __add_memory(int nid, u64 start, u64 si=
ze)
 	if (IS_ERR(res))
 		return PTR_ERR(res);
=20
-	ret =3D add_memory_resource(nid, res);
+	ret =3D add_memory_resource(nid, res, flags);
 	if (ret < 0)
 		release_memory_resource(res);
 	return ret;
 }
=20
-int add_memory(int nid, u64 start, u64 size)
+int add_memory(int nid, u64 start, u64 size, unsigned long flags)
 {
 	int rc;
=20
 	lock_device_hotplug();
-	rc =3D __add_memory(nid, start, size);
+	rc =3D __add_memory(nid, start, size, flags);
 	unlock_device_hotplug();
=20
 	return rc;
--=20
2.25.3



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 16:08:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 16:08:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTpGU-0001Fb-KK; Wed, 29 Apr 2020 16:08:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=uIcr=6N=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jTpGS-0001FN-Nm
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 16:08:48 +0000
X-Inumbo-ID: b525c10a-8a33-11ea-9965-12813bfff9fa
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id b525c10a-8a33-11ea-9965-12813bfff9fa;
 Wed, 29 Apr 2020 16:08:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588176527;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=uhuWZGDE9ZNfsUlRzjnVfD2BmrQPIPuqvz9+u5pM+h4=;
 b=iAt9ZbRTwyAierkY82djN/bjTNfedMKw9wi6s7saue4KzVLJOa/zuKTdkryJJzrip1GMEc
 2kIMs8u6KjBBxqt1la983q/woNfO3s+A7pMf9wGV4arVFvhMSmMB8c61nYK+o+n2gi2DpF
 7MHEPZuPmq8FUwIV9dgkLqVG2s+QuyE=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-403-JfUNgq6rMea1vtiPscJa6Q-1; Wed, 29 Apr 2020 12:08:43 -0400
X-MC-Unique: JfUNgq6rMea1vtiPscJa6Q-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3C4CC462;
 Wed, 29 Apr 2020 16:08:41 +0000 (UTC)
Received: from t480s.redhat.com (ovpn-114-55.ams2.redhat.com [10.36.114.55])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 7BC8E60621;
 Wed, 29 Apr 2020 16:08:32 +0000 (UTC)
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
Date: Wed, 29 Apr 2020 18:08:02 +0200
Message-Id: <20200429160803.109056-3-david@redhat.com>
In-Reply-To: <20200429160803.109056-1-david@redhat.com>
References: <20200429160803.109056-1-david@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, linux-acpi@vger.kernel.org,
 Baoquan He <bhe@redhat.com>, linux-nvdimm@lists.01.org,
 linux-s390@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 David Hildenbrand <david@redhat.com>,
 virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
 Wei Yang <richard.weiyang@gmail.com>, Eric Biederman <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Some paravirtualized devices that add memory via add_memory() and
friends (esp. virtio-mem) don't want to create entries in
/sys/firmware/memmap/ - primarily to hinder kexec from adding this
memory to the boot memmap of the kexec kernel.

In fact, such memory is never exposed via the firmware (e.g., e820), but
only via the device, so exposing this memory via /sys/firmware/memmap/ is
wrong:
 "kexec needs the raw firmware-provided memory map to setup the
  parameter segment of the kernel that should be booted with
  kexec. Also, the raw memory map is useful for debugging. For
  that reason, /sys/firmware/memmap is an interface that provides
  the raw memory map to userspace." [1]

We want to let user space know that memory which is always detected,
added, and managed via a (device) driver - like memory managed by
virtio-mem - is special. It cannot be used for placing kexec segments
and the (device) driver is responsible for re-adding memory that
(eventually shrunk/grown/defragmented) memory after a reboot/kexec. It
should e.g., not be added to a fixed up firmware memmap. However, it shou=
ld
be dumped by kdump.

Also, such memory could behave differently than an ordinary DIMM - e.g.,
memory managed by virtio-mem can have holes inside added memory resource,
which should not be touched, especially for writing.

Let's expose that memory as "System RAM (driver managed)" e.g., via
/pro/iomem.

We don't have to worry about firmware_map_remove() on the removal path.
If there is no entry, it will simply return with -EINVAL.

[1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-m=
emmap

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 include/linux/memory_hotplug.h |  8 ++++++++
 mm/memory_hotplug.c            | 20 ++++++++++++++++----
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplu=
g.h
index bf0e3edb8688..cc538584b39e 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -68,6 +68,14 @@ struct mhp_params {
 	pgprot_t pgprot;
 };
=20
+/* Flags used for add_memory() and friends. */
+
+/*
+ * Don't create entries in /sys/firmware/memmap/ and expose memory as
+ * "System RAM (driver managed)" in e.g., /proc/iomem
+ */
+#define MHP_DRIVER_MANAGED		1
+
 /*
  * Zone resizing functions
  *
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ebdf6541d074..cfa0721280aa 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -98,11 +98,11 @@ void mem_hotplug_done(void)
 u64 max_mem_size =3D U64_MAX;
=20
 /* add this memory to iomem resource */
-static struct resource *register_memory_resource(u64 start, u64 size)
+static struct resource *register_memory_resource(u64 start, u64 size,
+						 const char *resource_name)
 {
 	struct resource *res;
 	unsigned long flags =3D  IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
-	char *resource_name =3D "System RAM";
=20
 	/*
 	 * Make sure value parsed from 'mem=3D' only restricts memory adding
@@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resou=
rce *res,
 	BUG_ON(ret);
=20
 	/* create new memmap entry */
-	firmware_map_add_hotplug(start, start + size, "System RAM");
+	if (!(flags & MHP_DRIVER_MANAGED))
+		firmware_map_add_hotplug(start, start + size, "System RAM");
=20
 	/* device_online() will take the lock when calling online_pages() */
 	mem_hotplug_done();
@@ -1081,10 +1082,21 @@ int __ref add_memory_resource(int nid, struct res=
ource *res,
 /* requires device_hotplug_lock, see add_memory_resource() */
 int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags=
)
 {
+	const char *resource_name =3D "System RAM";
 	struct resource *res;
 	int ret;
=20
-	res =3D register_memory_resource(start, size);
+	/*
+	 * Indicate that memory managed by a driver is special. It's always
+	 * detected and added via a driver, should not be given to the kexec
+	 * kernel for booting when manually crafting the firmware memmap, and
+	 * no kexec segments should be placed on it. However, kdump should
+	 * dump this memory.
+	 */
+	if (flags & MHP_DRIVER_MANAGED)
+		resource_name =3D "System RAM (driver managed)";
+
+	res =3D register_memory_resource(start, size, resource_name);
 	if (IS_ERR(res))
 		return PTR_ERR(res);
=20
--=20
2.25.3



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 16:08:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 16:08:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTpGV-0001GM-Sq; Wed, 29 Apr 2020 16:08:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=uIcr=6N=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jTpGV-0001G0-85
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 16:08:51 +0000
X-Inumbo-ID: b71d877d-8a33-11ea-9965-12813bfff9fa
Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id b71d877d-8a33-11ea-9965-12813bfff9fa;
 Wed, 29 Apr 2020 16:08:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588176530;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=cZEMgwn0RdunIfg2yunfCJF8r1H9z41yqLf2sGNY0wM=;
 b=M0WbGyn9Y19J0as6sn0UpHe8NbyjD34/LSPGlzdKvj7WR00VV9+gvk4tmvIkwqCWT9U/4T
 wcWrDIQHYBZab7OgRPUYvsSApxpciT/uXpP1HQryPqjU8Nb+B1PJZpe6xqLGi4nMBznR0Q
 gsl9e4Zwo6FfbniZqKlhsXg5FO9KvSU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-494-pvtDQR0OOPCL64QlN-zLcg-1; Wed, 29 Apr 2020 12:08:46 -0400
X-MC-Unique: pvtDQR0OOPCL64QlN-zLcg-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B80BA107ACCA;
 Wed, 29 Apr 2020 16:08:44 +0000 (UTC)
Received: from t480s.redhat.com (ovpn-114-55.ams2.redhat.com [10.36.114.55])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 8D1E3605F7;
 Wed, 29 Apr 2020 16:08:41 +0000 (UTC)
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH v1 3/3] virtio-mem: Add memory with MHP_DRIVER_MANAGED
Date: Wed, 29 Apr 2020 18:08:03 +0200
Message-Id: <20200429160803.109056-4-david@redhat.com>
In-Reply-To: <20200429160803.109056-1-david@redhat.com>
References: <20200429160803.109056-1-david@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, linux-acpi@vger.kernel.org,
 linux-nvdimm@lists.01.org, linux-s390@vger.kernel.org,
 Jason Wang <jasowang@redhat.com>, "Michael S . Tsirkin" <mst@redhat.com>,
 David Hildenbrand <david@redhat.com>,
 virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
 Eric Biederman <ebiederm@xmission.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We don't want /sys/firmware/memmap entries and we want to indicate
our memory as "System RAM (driver managed)" in /proc/iomem. This is
especially relevant for kexec-tools, which have to be updated to
support dumping virtio-mem memory after this patch. Expected behavior in
kexec-tools:
- Don't use this memory when creating a fixed-up firmware memmap. Works
  now out of the box on x86-64.
- Don't use this memory for placing kexec segments. Works now out of the
  box on x86-64.
- Consider "System RAM (driver managed)" when creating the elfcorehdr
  for kdump. This memory has to be dumped. Needs update of kexec-tools.

With this patch on x86-64:

/proc/iomem:
	00000000-00000fff : Reserved
	00001000-0009fbff : System RAM
	[...]
	fffc0000-ffffffff : Reserved
	100000000-13fffffff : System RAM
	140000000-147ffffff : System RAM (driver managed)
	340000000-347ffffff : System RAM (driver managed)
	348000000-34fffffff : System RAM (driver managed)
	[..]
	3280000000-32ffffffff : PCI Bus 0000:00

/sys/firmware/memmap:
	0000000000000000-000000000009fc00 (System RAM)
	000000000009fc00-00000000000a0000 (Reserved)
	00000000000f0000-0000000000100000 (Reserved)
	0000000000100000-00000000bffe0000 (System RAM)
	00000000bffe0000-00000000c0000000 (Reserved)
	00000000feffc000-00000000ff000000 (Reserved)
	00000000fffc0000-0000000100000000 (Reserved)
	0000000100000000-0000000140000000 (System RAM)

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 drivers/virtio/virtio_mem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 3101cbf9e59d..6f658d1aeac4 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -421,7 +421,8 @@ static int virtio_mem_mb_add(struct virtio_mem *vm, u=
nsigned long mb_id)
 		nid =3D memory_add_physaddr_to_nid(addr);
=20
 	dev_dbg(&vm->vdev->dev, "adding memory block: %lu\n", mb_id);
-	return add_memory(nid, addr, memory_block_size_bytes(), 0);
+	return add_memory(nid, addr, memory_block_size_bytes(),
+			  MHP_DRIVER_MANAGED);
 }
=20
 /*
--=20
2.25.3



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 16:35:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 16:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTpfw-0004S2-9v; Wed, 29 Apr 2020 16:35:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTpfu-0004Rx-Lv
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 16:35:06 +0000
X-Inumbo-ID: 60d96b66-8a37-11ea-9972-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 60d96b66-8a37-11ea-9972-12813bfff9fa;
 Wed, 29 Apr 2020 16:35:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=yRvN8J8q9jjrmxfwbVMbgdwnaNimMyFuQhKle4rck9s=; b=uZNNQXbq/tdAggmzaaPX5zHXS
 Lttu6yqZrtQznE5DBtex008qVzjHJ1ZQodbueEHkRQ2uVcGvxOB3SVTWISSKWNe69oZKWzrc8P5nQ
 8DyO0s9+QMhBcbOmzMXe3ovciFC/SEWh0OjO4H3wyVsJCO4bA0/qN/IQJyDLtLZeaHkvM=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTpfr-00062V-Ts; Wed, 29 Apr 2020 16:35:03 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTpfr-0002ar-K3; Wed, 29 Apr 2020 16:35:03 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTpfr-0000y9-Fy; Wed, 29 Apr 2020 16:35:03 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149871-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149871: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6
X-Osstest-Versions-That: xen=2add344e6a4ef690871157b87b0e7d52bc6db9e4
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 16:35:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149871 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149871/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149865

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149865
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149865
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149865
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149865
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149865
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149865
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149865
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149865
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149865
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6
baseline version:
 xen                  2add344e6a4ef690871157b87b0e7d52bc6db9e4

Last test of basis   149865  2020-04-28 16:32:15 Z    0 days
Testing same since   149871  2020-04-29 05:14:21 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Hongyan Xia <hongyxia@amazon.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Wei Liu <wei.liu2@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   2add344e6a..4ec07971f1  4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6 -> master


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 16:42:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 16:42:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTpmb-0005Rt-6V; Wed, 29 Apr 2020 16:42:01 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=7tx0=6N=gmail.com=wei.liu.linux@srs-us1.protection.inumbo.net>)
 id 1jTpmZ-0005Ro-ON
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 16:41:59 +0000
X-Inumbo-ID: 57f8d71a-8a38-11ea-b07b-bc764e2007e4
Received: from mail-wm1-f66.google.com (unknown [209.85.128.66])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 57f8d71a-8a38-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 16:41:59 +0000 (UTC)
Received: by mail-wm1-f66.google.com with SMTP id e26so2772630wmk.5
 for <xen-devel@lists.xenproject.org>; Wed, 29 Apr 2020 09:41:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-disposition:in-reply-to:user-agent;
 bh=b1NmnG+Bha+R6DCsicsXkjR18of0wt/SYtjmCqwDrqU=;
 b=ByMUSrur6ph09MPg67mnA/w3gvsZAN4fqFrrccbWGrJn9CygTcsy2RyBFxs71jUdf8
 b5Qp4+vKbEW9Y/HFn9F8MWUEaXDjacqh4BUOc6eNPq9lM4U/dycOv4OQIZaJ7PuvbS51
 LyWeE2vr0pqxFDRB+3/fN/W2jVxpmUpNMAkvAuAmGf7nbyzwBSqoDF/ihDAQ5OArHyoH
 n6CpYLsGD5S0mfJoMB3HpofGmft3UzxKt19LJZapdTJ3empXGO2aAdEPkH1ejcxEeFsz
 CbKsERjvsMIXv2WG1wpqBJ1qcnINLcqHS2RagZytfEZMDNUjGjJdL0VpI/1So31J8+uR
 MFsg==
X-Gm-Message-State: AGi0PuY94vbXo4LiPLEIIM0Goq5kADKYknv0yHklXFcTTiVfK1V78fGw
 etsKBr5AsBRIdYqWER04nNA=
X-Google-Smtp-Source: APiQypK92COmCk6jtDXQuM8RbqIzlQmTZkmvIjtD7/GMtqebIJTWbJ+7ip3K+A9bRbw+AFyvMNQEDw==
X-Received: by 2002:a1c:2383:: with SMTP id j125mr4175112wmj.6.1588178518352; 
 Wed, 29 Apr 2020 09:41:58 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net
 ([51.145.34.42])
 by smtp.gmail.com with ESMTPSA id i25sm8360761wml.43.2020.04.29.09.41.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 29 Apr 2020 09:41:57 -0700 (PDT)
Date: Wed, 29 Apr 2020 16:41:55 +0000
From: Wei Liu <wei.liu@kernel.org>
To: David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH v1 1/3] mm/memory_hotplug: Prepare passing flags to
 add_memory() and friends
Message-ID: <20200429164154.ctflq4ouwrwwe4wq@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
References: <20200429160803.109056-1-david@redhat.com>
 <20200429160803.109056-2-david@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200429160803.109056-2-david@redhat.com>
User-Agent: NeoMutt/20180716
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: linux-hyperv@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
 "Michael S . Tsirkin" <mst@redhat.com>,
 Benjamin Herrenschmidt <benh@kernel.crashing.org>,
 Jason Wang <jasowang@redhat.com>, Heiko Carstens <heiko.carstens@de.ibm.com>,
 Pingfan Liu <kernelfans@gmail.com>, virtualization@lists.linux-foundation.org,
 linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
 "K. Y. Srinivasan" <kys@microsoft.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, virtio-dev@lists.oasis-open.org,
 Wei Liu <wei.liu@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Dave Jiang <dave.jiang@intel.com>, Baoquan He <bhe@redhat.com>,
 linux-nvdimm@lists.01.org, Vishal Verma <vishal.l.verma@intel.com>,
 linux-acpi@vger.kernel.org, Wei Yang <richard.weiyang@gmail.com>,
 xen-devel@lists.xenproject.org, Len Brown <lenb@kernel.org>,
 Nathan Lynch <nathanl@linux.ibm.com>, Vasily Gorbik <gor@linux.ibm.com>,
 linux-s390@vger.kernel.org, Haiyang Zhang <haiyangz@microsoft.com>,
 Leonardo Bras <leobras.c@gmail.com>,
 Stephen Hemminger <sthemmin@microsoft.com>,
 Dan Williams <dan.j.williams@intel.com>, Michal Hocko <mhocko@kernel.org>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Oscar Salvador <osalvador@suse.de>, Juergen Gross <jgross@suse.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "Rafael J. Wysocki" <rjw@rjwysocki.net>, linux-kernel@vger.kernel.org,
 Thomas Gleixner <tglx@linutronix.de>, Eric Biederman <ebiederm@xmission.com>,
 Michael Ellerman <mpe@ellerman.id.au>,
 Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 29, 2020 at 06:08:01PM +0200, David Hildenbrand wrote:
> We soon want to pass flags - prepare for that.
> 
> This patch is based on a similar patch by Oscar Salvador:
> 
> https://lkml.kernel.org/r/20190625075227.15193-3-osalvador@suse.de
> 
[...]
> ---
>  drivers/hv/hv_balloon.c                         |  2 +-

> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 32e3bc0aa665..0194bed1a573 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -726,7 +726,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
>  
>  		nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
>  		ret = add_memory(nid, PFN_PHYS((start_pfn)),
> -				(HA_CHUNK << PAGE_SHIFT));
> +				(HA_CHUNK << PAGE_SHIFT), 0);
>  
>  		if (ret) {
>  			pr_err("hot_add memory failed error is %d\n", ret);

Acked-by: Wei Liu <wei.liu@kernel.org>


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 17:18:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 17:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTqLb-0008TF-Pl; Wed, 29 Apr 2020 17:18:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PJZR=6N=gmail.com=ayushdosaj2313@srs-us1.protection.inumbo.net>)
 id 1jTqLa-0008TA-Gk
 for xen-devel@lists.xen.org; Wed, 29 Apr 2020 17:18:10 +0000
X-Inumbo-ID: 65e8daa0-8a3d-11ea-ae69-bc764e2007e4
Received: from mail-oi1-x229.google.com (unknown [2607:f8b0:4864:20::229])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 65e8daa0-8a3d-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 17:18:09 +0000 (UTC)
Received: by mail-oi1-x229.google.com with SMTP id 19so2483646oiy.8
 for <xen-devel@lists.xen.org>; Wed, 29 Apr 2020 10:18:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=pRcvpi37jJZmtN/lvIL5Lo9a2UxvC2fhXJil7fmcwi0=;
 b=PNp95T4iv3qJGMcIajDyfhDo7y6S5C0cfeNWd86PJSdGzxr4m47eLG4fzuNv58o8jD
 Qfmt7Lfy+W8LyOlDgGFQ31xHFG3EhDwxbCyQkt6IKuQ/+XTAGuWs+w383mU4hsnJWVh0
 gFeWGQTHrcb4DU5qRo0ApXVuHl6DYSus0eTqhMObJ5rQnTRU7fFakF7d8EwaGFa+3foC
 SFET43BLcqVBFiBMqNCYESvGbAMU1gWQB7pUvUWyfhmjrH9ydYc+esZy9QI2yhcR6zDN
 g62CJGAeMjN7rCn/4d2P7aVlpR1ydBG2XEiYMTNzy4nWRc2YCEvynoxBrRR3Bp4xH25+
 4Y6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=pRcvpi37jJZmtN/lvIL5Lo9a2UxvC2fhXJil7fmcwi0=;
 b=HwOcAPVwYiSltM1qWvgGo90jSOXmyXJvSXC+jArr0uuvzDbQ8e/gBrex5xZnf0gWCS
 Dw+5keXwfyVf0aZyGgr6/rm64bR3PL8UWjmEkZg0uTjvccVKrN8fO6WBa1vKRVXjJf5t
 DojgsDQh4NJZG7sFttkGr6bqG52vl5pBhzP0GZwE/HDgX2fLDKNxRDUfqZ/lDTImMKeF
 naWKw/Uakwe0Ubt5r+xN1LyBCcxDHlz/6CYU+yQzz1V9xeTl4pYMFLlUPK/OT+mQ0L3n
 SKGQ/ocwXviaQROzAj7RdYj4X+REBonUwtEMktTXiV133MYab5ckt+MLjqfkqkaiAp+L
 CuLg==
X-Gm-Message-State: AGi0PuZFgRQ7D8DtXjUorGzAoOIXTcYTFlZ+kReIZcvkyOxYUkqUR9sj
 Q6+/p4hira8vTVUPeyYNBG7kK4C1TBKl05NPpm/Tsv3ydN8=
X-Google-Smtp-Source: APiQypL4HVbQtW3CmTMgllhOzv6HKjGIcXxiVG/c7nHl+jiI1xqc6LlG1CQyWXInKmwjcibEbnczFF6/Y+VKWkg9RCo=
X-Received: by 2002:aca:5716:: with SMTP id l22mr2331785oib.43.1588180688822; 
 Wed, 29 Apr 2020 10:18:08 -0700 (PDT)
MIME-Version: 1.0
From: Ayush Dosaj <ayushdosaj2313@gmail.com>
Date: Wed, 29 Apr 2020 22:47:57 +0530
Message-ID: <CAOCxVi0s5X+=Hug2_M-AyXvYpiwqfkf7G2Y66kp44MQ-xgO+KA@mail.gmail.com>
Subject: Xen Compilation Error on Ubuntu 20.04
To: xen-devel@lists.xen.org
Content-Type: multipart/alternative; boundary="000000000000cbfdf305a4712183"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--000000000000cbfdf305a4712183
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Xen development team,

I am Ayush. I compiled Xen Hypervisor from source on Ubuntu 20.04 machine
running on an intel-i9 CPU.
I am getting compilation error due to the following two flags.
Error: error: =E2=80=98-mindirect-branch=E2=80=99 and =E2=80=98-fcf-protect=
ion=E2=80=99 are not compatible.

Complete Error logs can be found at https://paste.ubuntu.com/p/xvvyPnhW5c/

And when I compiled Xen commenting the two flags in Rules.mk file, it
compiles and installs properly but on boot-up i see a blank black screen
and i am stuck there.


Best,
Ayush Dosaj

--000000000000cbfdf305a4712183
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default"><font size=3D"2"><span style=
=3D"font-family:georgia,serif">Hi Xen development team,</span></font></div>=
<div class=3D"gmail_default"><font size=3D"2"><span style=3D"font-family:ge=
orgia,serif"><br></span></font></div><div class=3D"gmail_default"><font siz=
e=3D"2"><span style=3D"font-family:georgia,serif">I am Ayush. I compiled Xe=
n Hypervisor from source on Ubuntu 20.04 machine running on an intel-i9 CPU=
.</span></font></div><div class=3D"gmail_default"><font size=3D"2"><span st=
yle=3D"font-family:georgia,serif">I am getting compilation error due to the=
 following two flags.</span></font></div><div class=3D"gmail_default"><font=
 size=3D"2"><span style=3D"font-family:georgia,serif">Error: error: =E2=80=
=98-mindirect-branch=E2=80=99 and =E2=80=98-fcf-protection=E2=80=99 are not=
 compatible.</span></font></div><div class=3D"gmail_default"><font size=3D"=
2"><span style=3D"font-family:georgia,serif"><br></span></font></div><div c=
lass=3D"gmail_default"><div class=3D"gmail_default"><font size=3D"2"><span =
style=3D"font-family:georgia,serif">Complete Error logs can be found at <a =
href=3D"https://paste.ubuntu.com/p/xvvyPnhW5c/">https://paste.ubuntu.com/p/=
xvvyPnhW5c/</a></span></font></div><div class=3D"gmail_default"><font size=
=3D"2"><span style=3D"font-family:georgia,serif"></span></font></div><font =
size=3D"2"><span style=3D"font-family:georgia,serif"></span></font></div><d=
iv class=3D"gmail_default"><font size=3D"2"><span style=3D"font-family:geor=
gia,serif"><br></span></font></div><div class=3D"gmail_default"><font size=
=3D"2"><span style=3D"font-family:georgia,serif">And when I compiled Xen co=
mmenting the two flags in Rules.mk file, it compiles and installs properly =
but on boot-up i see a blank black screen and i am stuck there.<br></span><=
/font></div><div class=3D"gmail_default"><font size=3D"2"><span style=3D"fo=
nt-family:georgia,serif"><br></span></font></div><div class=3D"gmail_defaul=
t"><font size=3D"2"><span style=3D"font-family:georgia,serif"><br></span></=
font></div><div class=3D"gmail_default"><font size=3D"2"><span style=3D"fon=
t-family:georgia,serif">Best,<br></span></font></div><div dir=3D"ltr" class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><d=
iv><div dir=3D"ltr"><div style=3D"text-align:left"><div><font size=3D"2"><s=
pan style=3D"font-family:georgia,serif">Ayush Dosaj<span class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif"></span></span></font=
></div><div><font size=3D"2"><span style=3D"font-family:monospace"><br></sp=
an></font></div><div><font size=3D"2"><br></font></div></div></div></div></=
div></div></div>

--000000000000cbfdf305a4712183--


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 17:25:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 17:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTqSK-00011f-Hk; Wed, 29 Apr 2020 17:25:08 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTqSI-00011a-Ek
 for xen-devel@lists.xen.org; Wed, 29 Apr 2020 17:25:06 +0000
X-Inumbo-ID: 5d2b9262-8a3e-11ea-997e-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5d2b9262-8a3e-11ea-997e-12813bfff9fa;
 Wed, 29 Apr 2020 17:25:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588181105;
 h=subject:to:references:from:message-id:date:mime-version:
 in-reply-to:content-transfer-encoding;
 bh=Jxx3E0+xY6ycqkAc3LMwC7yiu3O28kLwU+Q8+HQtZXo=;
 b=O5RkZ3g88WOTwXrml/hmoXMcXYDC6IItEsM9qvjDyBj8Zj7ysAuIXrre
 52eBGjq3/W3z/WTFqozBDPMnmu9IR3tompxiaPPavjMgMXED3HpGnHGJI
 uGlyt26C4uBpsk2Rhcry+lLnTBrXYTjpcSPobqddLh3AnCo0FMQ4Jfkha Y=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: Ym6dmozcLmazND390vLhLMc2uWUqGlmXUySLhGrNPtYWfqTIbhRvqGHSbvf0jZtsrvAZTCgMSZ
 iU57ociEth7v9uwIJLgqy7rVvLDDJOvNGUn2FRWwUr4WqvdsC4cFDc4hY7AFwF7ZB9X+d27Zqk
 Mrph36Kv97DnQz++2lZJ4HrF9n5aih1PUgZ45MiHJALI+JZQFKLhTu3T3EjBnpwiVJ7BT8KJK0
 9zYwNJhZcljL1GshCZ3a4aKn6/Kw9XsDnMiCaE4K9A9Bkk45UGoamP8bk5nPdFUMkbI1VC0+Zf
 QgI=
X-SBRS: 2.7
X-MesageID: 16712695
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16712695"
Subject: Re: Xen Compilation Error on Ubuntu 20.04
To: Ayush Dosaj <ayushdosaj2313@gmail.com>, <xen-devel@lists.xen.org>
References: <CAOCxVi0s5X+=Hug2_M-AyXvYpiwqfkf7G2Y66kp44MQ-xgO+KA@mail.gmail.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <e92bb8ab-3dd2-bb19-d524-d78279f9508a@citrix.com>
Date: Wed, 29 Apr 2020 18:25:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAOCxVi0s5X+=Hug2_M-AyXvYpiwqfkf7G2Y66kp44MQ-xgO+KA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29/04/2020 18:17, Ayush Dosaj wrote:
> Hi Xen development team,
> 
> I am Ayush. I compiled Xen Hypervisor from source on Ubuntu 20.04
> machine running on an intel-i9 CPU.
> I am getting compilation error due to the following two flags.
> Error: error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible.
> 
> Complete Error logs can be found at https://paste.ubuntu.com/p/xvvyPnhW5c/
> 
> And when I compiled Xen commenting the two flags in Rules.mk file, it
> compiles and installs properly but on boot-up i see a blank black screen
> and i am stuck there.

That is a GCC bug (these options are actually fine in combination).  It
got fixed earlier today in master, and backported for GCC 9.4

You can work around it by appending -fcf-protection=none to CFLAGS

I wouldn't try editing the logic around -mindirect-branch, as that is
related to retpoline safety for Spectre v2, and probably relies on the
build matching the code.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 17:28:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 17:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTqVz-0001Ak-3I; Wed, 29 Apr 2020 17:28:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PJZR=6N=gmail.com=ayushdosaj2313@srs-us1.protection.inumbo.net>)
 id 1jTqVx-0001Af-Qj
 for xen-devel@lists.xen.org; Wed, 29 Apr 2020 17:28:53 +0000
X-Inumbo-ID: e5662e94-8a3e-11ea-ae69-bc764e2007e4
Received: from mail-oi1-x22b.google.com (unknown [2607:f8b0:4864:20::22b])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e5662e94-8a3e-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 17:28:53 +0000 (UTC)
Received: by mail-oi1-x22b.google.com with SMTP id q204so2500861oia.13
 for <xen-devel@lists.xen.org>; Wed, 29 Apr 2020 10:28:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=4U+CbPsYJzZOuV7fYM3/9Vnh9J75q+MjwFmxdff0SVU=;
 b=Apt0ngunMXGwlSy6/ECTZZ7YElz/d2VZxWkKVarABAmzeibDDAFAu6/b26NUGygYDG
 hsWOfbjv8m6w8TN9L+27KbU7JsgTSg6Um0ytXqJMjwciwhzonlfQu/3tP9XecTDLenX4
 enedlEtI60vLbXF1Q0qjNnx5EmuBjS6yRWdZC+t5lSmw7pI6DgESJ+BrVha7I70ZpgPE
 8lQIEkcQSwBJYLmniYTYRfq+FOqTO5vpg/unlW9N0XhIESMg6p90a+1ZnL030tB73qYf
 /TpPpz8YzidLVy9yvyx1o5sNEj3YhxcQQanH1vMRcCCkasoKb6n1Uh93OMcb6F+6eBe3
 clGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=4U+CbPsYJzZOuV7fYM3/9Vnh9J75q+MjwFmxdff0SVU=;
 b=etTcP3yaFt3szIsUgRJkwC5N4qWgeoztGfXR8c81vH58s1JIbilhHVqgoATnLVPec4
 4HsmSZSLhRRXwjfP5Qmuvkezg7CV0Vqv29VOhPUNpihkEo/QrdF6MNZoO9VJ+7YoSqlw
 vUAVfPQIAnIVWU/i1dXt/acu3FGnT4Pcpmc768noj+sUFrd/6FTNpfAOVPwtTAWlG8ui
 vUmbSS1c1Ux2XReabXx0wM4Oqrc0PwTO3j2DoP0XjBOrv+JlsOUUi+9YagR5Nn82lrSr
 mVCv7NcI5lWWPHyzzUZeaa1c5Jx5nxkL174KDHhwbNvZxPRTNHl0v57kD7V8tx6wyvjS
 /7iw==
X-Gm-Message-State: AGi0PubVDepQhN1t497EXq7TlDOI04gl7mheP8jQIlb01TuI1jMnXQz2
 gSUHc4AffCbA17cn2VVWgb9wiTxAMUyxRvm5saE=
X-Google-Smtp-Source: APiQypI/wTBxHfkvThL9OCVtbTfg8EslNNNt0NdZAFXDdjTIgwP5R45MglsVHbC2c3242PZmPgi2VW23EEog59Tjj80=
X-Received: by 2002:aca:4bc2:: with SMTP id y185mr2380206oia.164.1588181332450; 
 Wed, 29 Apr 2020 10:28:52 -0700 (PDT)
MIME-Version: 1.0
References: <CAOCxVi0s5X+=Hug2_M-AyXvYpiwqfkf7G2Y66kp44MQ-xgO+KA@mail.gmail.com>
 <e92bb8ab-3dd2-bb19-d524-d78279f9508a@citrix.com>
In-Reply-To: <e92bb8ab-3dd2-bb19-d524-d78279f9508a@citrix.com>
From: Ayush Dosaj <ayushdosaj2313@gmail.com>
Date: Wed, 29 Apr 2020 22:58:40 +0530
Message-ID: <CAOCxVi1PWM_9t03f=_qn0PXkKB1gN4504h+ijMpwqGU9VpR48g@mail.gmail.com>
Subject: Re: Xen Compilation Error on Ubuntu 20.04
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: multipart/alternative; boundary="00000000000028e2e905a47148af"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--00000000000028e2e905a47148af
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Awesome, thanks!

On Wed, Apr 29, 2020 at 10:55 PM Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 29/04/2020 18:17, Ayush Dosaj wrote:
> > Hi Xen development team,
> >
> > I am Ayush. I compiled Xen Hypervisor from source on Ubuntu 20.04
> > machine running on an intel-i9 CPU.
> > I am getting compilation error due to the following two flags.
> > Error: error: =E2=80=98-mindirect-branch=E2=80=99 and =E2=80=98-fcf-pro=
tection=E2=80=99 are not
> compatible.
> >
> > Complete Error logs can be found at
> https://paste.ubuntu.com/p/xvvyPnhW5c/
> >
> > And when I compiled Xen commenting the two flags in Rules.mk file, it
> > compiles and installs properly but on boot-up i see a blank black scree=
n
> > and i am stuck there.
>
> That is a GCC bug (these options are actually fine in combination).  It
> got fixed earlier today in master, and backported for GCC 9.4
>
> You can work around it by appending -fcf-protection=3Dnone to CFLAGS
>
> I wouldn't try editing the logic around -mindirect-branch, as that is
> related to retpoline safety for Spectre v2, and probably relies on the
> build matching the code.
>
> ~Andrew
>


--=20
Ayush Dosaj
VIT Vellore

--00000000000028e2e905a47148af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small">Awesome, thanks! <br></div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr =
29, 2020 at 10:55 PM Andrew Cooper &lt;<a href=3D"mailto:andrew.cooper3@cit=
rix.com">andrew.cooper3@citrix.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">On 29/04/2020 18:17, Ayush Dosaj wrote:<b=
r>
&gt; Hi Xen development team,<br>
&gt; <br>
&gt; I am Ayush. I compiled Xen Hypervisor from source on Ubuntu 20.04<br>
&gt; machine running on an intel-i9 CPU.<br>
&gt; I am getting compilation error due to the following two flags.<br>
&gt; Error: error: =E2=80=98-mindirect-branch=E2=80=99 and =E2=80=98-fcf-pr=
otection=E2=80=99 are not compatible.<br>
&gt; <br>
&gt; Complete Error logs can be found at <a href=3D"https://paste.ubuntu.co=
m/p/xvvyPnhW5c/" rel=3D"noreferrer" target=3D"_blank">https://paste.ubuntu.=
com/p/xvvyPnhW5c/</a><br>
&gt; <br>
&gt; And when I compiled Xen commenting the two flags in Rules.mk file, it<=
br>
&gt; compiles and installs properly but on boot-up i see a blank black scre=
en<br>
&gt; and i am stuck there.<br>
<br>
That is a GCC bug (these options are actually fine in combination).=C2=A0 I=
t<br>
got fixed earlier today in master, and backported for GCC 9.4<br>
<br>
You can work around it by appending -fcf-protection=3Dnone to CFLAGS<br>
<br>
I wouldn&#39;t try editing the logic around -mindirect-branch, as that is<b=
r>
related to retpoline safety for Spectre v2, and probably relies on the<br>
build matching the code.<br>
<br>
~Andrew<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div style=3D"text-a=
lign:left"><div style=3D"font-family:arial,helvetica,sans-serif">Ayush Dosa=
j</div><div style=3D"font-family:arial,helvetica,sans-serif">VIT Vellore</d=
iv><div><br></div></div></div></div></div></div>

--00000000000028e2e905a47148af--


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 17:36:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 17:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTqdI-00029O-UI; Wed, 29 Apr 2020 17:36:28 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=vbvF=6N=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jTqdH-00029J-AP
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 17:36:27 +0000
X-Inumbo-ID: f363e5b2-8a3f-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f363e5b2-8a3f-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 17:36:26 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 87C6CAC37;
 Wed, 29 Apr 2020 17:36:24 +0000 (UTC)
Subject: [PATCH 0/2] xen: credit2: limit the number of CPUs per runqueue
From: Dario Faggioli <dfaggioli@suse.com>
To: xen-devel@lists.xenproject.org
Date: Wed, 29 Apr 2020 19:36:23 +0200
Message-ID: <158818022727.24327.14309662489731832234.stgit@Palanthas>
User-Agent: StGit/0.21
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In Credit2, the CPUs are assigned to runqueues according to the host
topology. For instance, if we want per-socket runqueues (which is the
default), the CPUs that are in the same socket will end up in the same
runqueue.

This is generally good for scalability, at least until the number of
CPUs that end up in the same runqueue is not too high. In fact, all this
CPUs will compete for the same spinlock, for making scheduling decisions
and manipulating the scheduler data structures. Therefore, if they are
too many, that can become a bottleneck.

This has not been an issue so far, but architectures with 128 CPUs per
socket are now available, and it is certainly unideal to have so many
CPUs in the same runqueue, competing for the same locks, etc.

Let's therefore set a cap to the total number of CPUs that can share a
runqueue. The value is set to 16, by default, but can be changed with
a boot command line parameter.

Note that this is orthogonal and independent from the activity of
introducing runqueue arrangement mechanisms and chriteria. In fact,
we very well may want to implement the capability of having, say, per-LLC
runqueues, or per-die (where that is defined) runqueues. In fact, this
would work well on current system, but nothing guarantees that, in
future, there won't be an architecture with hundreds of CPUs per DIE or
LLC... And we'll be back to where we are now.

Therefore, even if we are actually planning to add some new runqueue
organization criteria, fixing a limit for the number of CPUs that
will ever share a runqueue, whatever the underlying topology is, is
still useful.

Note also that, if the host has hyperthreading (and we are not using
core-scheduling), additional care is taken to avoid splitting CPUs that
are hyperthread siblings among different runqueues.

---
Dario Faggioli (2):
      xen: credit2: factor cpu to runqueue matching in a function
      xen: credit2: limit the max number of CPUs in a runqueue

 xen/common/sched/cpupool.c |    2 -
 xen/common/sched/credit2.c |  130 +++++++++++++++++++++++++++++++++++++++-----
 xen/common/sched/private.h |    2 +
 3 files changed, 119 insertions(+), 15 deletions(-)

--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 17:36:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 17:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTqdN-00029f-6L; Wed, 29 Apr 2020 17:36:33 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LUw1=6N=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jTqdM-00029W-8I
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 17:36:32 +0000
X-Inumbo-ID: f3728f0e-8a3f-11ea-b07b-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f3728f0e-8a3f-11ea-b07b-bc764e2007e4;
 Wed, 29 Apr 2020 17:36:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588181787;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=aGTSaS8O3UBuwxmxOAb6nZh9nvU3qR7640hwUvfNwrE=;
 b=KWbEu/hk939WF+o68z3HfDhsllyAxIF2M+krFP6RUgb4U2X+4wWuwUoV
 8DFY/SyVtteJAo4oQ139lwNXboBCSHMQL7NKDqcouU6K5Cd52EHRYx71P
 dtpQNIxx2Ut5t1NLnL3CGagdWfE02P7U7sMOk58pWutZAs22L+9K1xI4x M=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: PzHf/MW00sqHEWTJR42cTIhXggS28enIJkbUXx4fQm5KsB5mgtsXAfqRHNBoPqJ1PUwX5sBEVP
 +PSXBfrYfViK6VKjYl2B4EOFKWKJrFq+nuc9Njuv6AS42ixpveOCsAG1dzjWzo9Ti5Xc/LMfcJ
 SNShQoKsr+f3OCHtsv+wV10s89D6eFskYgQCO/CVZyJsUsaYa511xPGwhl/mdIdK2IN7K4ZjiP
 9UnOU4j37Gn6wtv+39bQkftjq4pkh3AjEGUG+x2aSRBHq9EMdRRrkOjutRTMm8cYJsTwzaPtHN
 Fq0=
X-SBRS: 2.7
X-MesageID: 16473605
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16473605"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/hap: be more selective with assisted TLB flush
Date: Wed, 29 Apr 2020 19:36:01 +0200
Message-ID: <20200429173601.77605-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

When doing an assisted flush on HAP the purpose of the
on_selected_cpus is just to trigger a vmexit on remote CPUs that are
in guest context, and hence just using is_vcpu_dirty_cpu is too lax,
also check that the vCPU is running.

While there also pass NULL as the data parameter of on_selected_cpus,
the dummy handler doesn't consume the data in any way.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/mm/hap/hap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 580d1c2164..0275cdf5c8 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -719,7 +719,7 @@ static bool flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
         hvm_asid_flush_vcpu(v);
 
         cpu = read_atomic(&v->dirty_cpu);
-        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) )
+        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v->is_running )
             __cpumask_set_cpu(cpu, mask);
     }
 
@@ -729,7 +729,7 @@ static bool flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
      * not currently running will already be flushed when scheduled because of
      * the ASID tickle done in the loop above.
      */
-    on_selected_cpus(mask, dummy_flush, mask, 0);
+    on_selected_cpus(mask, dummy_flush, NULL, 0);
 
     return true;
 }
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 17:36:35 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 17:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTqdP-0002AW-Iv; Wed, 29 Apr 2020 17:36:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=vbvF=6N=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jTqdN-00029s-KT
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 17:36:33 +0000
X-Inumbo-ID: f68dd874-8a3f-11ea-9980-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f68dd874-8a3f-11ea-9980-12813bfff9fa;
 Wed, 29 Apr 2020 17:36:31 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 265DFAC37;
 Wed, 29 Apr 2020 17:36:30 +0000 (UTC)
Subject: [PATCH 1/2] xen: credit2: factor cpu to runqueue matching in a
 function
From: Dario Faggioli <dfaggioli@suse.com>
To: xen-devel@lists.xenproject.org
Date: Wed, 29 Apr 2020 19:36:30 +0200
Message-ID: <158818178990.24327.6732870355943077303.stgit@Palanthas>
In-Reply-To: <158818022727.24327.14309662489731832234.stgit@Palanthas>
References: <158818022727.24327.14309662489731832234.stgit@Palanthas>
User-Agent: StGit/0.21
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: George Dunlap <george.dunlap@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Just move the big if() condition in an inline function.

No functional change intended.

Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
---
Cc: George Dunlap <george.dunlap@citrix.com>
---
 xen/common/sched/credit2.c |   28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 34f05c3e2a..697c9f917d 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -838,6 +838,20 @@ static inline bool same_core(unsigned int cpua, unsigned int cpub)
            cpu_to_core(cpua) == cpu_to_core(cpub);
 }
 
+static inline bool
+cpu_runqueue_match(const struct csched2_runqueue_data *rqd, unsigned int cpu)
+{
+    unsigned int peer_cpu = rqd->pick_bias;
+
+    BUG_ON(cpu_to_socket(peer_cpu) == XEN_INVALID_SOCKET_ID);
+
+    /* OPT_RUNQUEUE_CPU will never find an existing runqueue. */
+    return opt_runqueue == OPT_RUNQUEUE_ALL ||
+           (opt_runqueue == OPT_RUNQUEUE_CORE && same_core(peer_cpu, cpu)) ||
+           (opt_runqueue == OPT_RUNQUEUE_SOCKET && same_socket(peer_cpu, cpu)) ||
+           (opt_runqueue == OPT_RUNQUEUE_NODE && same_node(peer_cpu, cpu));
+}
+
 static struct csched2_runqueue_data *
 cpu_add_to_runqueue(struct csched2_private *prv, unsigned int cpu)
 {
@@ -855,21 +869,11 @@ cpu_add_to_runqueue(struct csched2_private *prv, unsigned int cpu)
     rqd_ins = &prv->rql;
     list_for_each_entry ( rqd, &prv->rql, rql )
     {
-        unsigned int peer_cpu;
-
         /* Remember first unused queue index. */
         if ( !rqi_unused && rqd->id > rqi )
             rqi_unused = true;
 
-        peer_cpu = rqd->pick_bias;
-        BUG_ON(cpu_to_socket(cpu) == XEN_INVALID_SOCKET_ID ||
-               cpu_to_socket(peer_cpu) == XEN_INVALID_SOCKET_ID);
-
-        /* OPT_RUNQUEUE_CPU will never find an existing runqueue. */
-        if ( opt_runqueue == OPT_RUNQUEUE_ALL ||
-             (opt_runqueue == OPT_RUNQUEUE_CORE && same_core(peer_cpu, cpu)) ||
-             (opt_runqueue == OPT_RUNQUEUE_SOCKET && same_socket(peer_cpu, cpu)) ||
-             (opt_runqueue == OPT_RUNQUEUE_NODE && same_node(peer_cpu, cpu)) )
+        if ( cpu_runqueue_match(rqd, cpu) )
         {
             rqd_valid = true;
             break;
@@ -3744,6 +3748,8 @@ csched2_alloc_pdata(const struct scheduler *ops, int cpu)
     struct csched2_pcpu *spc;
     struct csched2_runqueue_data *rqd;
 
+    BUG_ON(cpu_to_socket(cpu) == XEN_INVALID_SOCKET_ID);
+
     spc = xzalloc(struct csched2_pcpu);
     if ( spc == NULL )
         return ERR_PTR(-ENOMEM);



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 17:36:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 17:36:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTqdT-0002CB-SU; Wed, 29 Apr 2020 17:36:39 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=vbvF=6N=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jTqdS-0002Bo-Lt
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 17:36:38 +0000
X-Inumbo-ID: fa24707e-8a3f-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id fa24707e-8a3f-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 17:36:37 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id C7367ACC5;
 Wed, 29 Apr 2020 17:36:35 +0000 (UTC)
Subject: [PATCH 2/2] xen: credit2: limit the max number of CPUs in a runqueue
From: Dario Faggioli <dfaggioli@suse.com>
To: xen-devel@lists.xenproject.org
Date: Wed, 29 Apr 2020 19:36:35 +0200
Message-ID: <158818179558.24327.11334680191217289878.stgit@Palanthas>
In-Reply-To: <158818022727.24327.14309662489731832234.stgit@Palanthas>
References: <158818022727.24327.14309662489731832234.stgit@Palanthas>
User-Agent: StGit/0.21
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

In Credit2 CPUs (can) share runqueues, depending on the topology. For
instance, with per-socket runqueues (the default) all the CPUs that are
part of the same socket share a runqueue.

On platform with a huge number of CPUs per socket, that could be a
problem. An example is AMD EPYC2 servers, where we can have up to 128
CPUs in a socket.

It is of course possible to define other, still topology-based, runqueue
arrangements (e.g., per-LLC, per-DIE, etc). But that may still result in
runqueues with too many CPUs on other/future platforms.

Therefore, let's set a limit to the max number of CPUs that can share a
Credit2 runqueue. The actual value is configurable (at boot time), the
default being 16. If, for instance,  there are more than 16 CPUs in a
socket, they'll be split among two (or more) runqueues.

Note: with core scheduling enabled, this parameter sets the max number
of *scheduling resources* that can share a runqueue. Therefore, with
granularity set to core (and assumint 2 threads per core), we will have
at most 16 cores per runqueue, which corresponds to 32 threads. But that
is fine, considering how core scheduling works.

Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>
---
 xen/common/sched/cpupool.c |    2 -
 xen/common/sched/credit2.c |  104 ++++++++++++++++++++++++++++++++++++++++++--
 xen/common/sched/private.h |    2 +
 3 files changed, 103 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index d40345b585..0227457285 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -37,7 +37,7 @@ static cpumask_t cpupool_locked_cpus;
 
 static DEFINE_SPINLOCK(cpupool_lock);
 
-static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
+enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
 static unsigned int __read_mostly sched_granularity = 1;
 
 #ifdef CONFIG_HAS_SCHED_GRANULARITY
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 697c9f917d..abe4d048c8 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -471,6 +471,16 @@ static int __init parse_credit2_runqueue(const char *s)
 }
 custom_param("credit2_runqueue", parse_credit2_runqueue);
 
+/*
+ * How many CPUs will be put, at most, in the same runqueue.
+ * Runqueues are still arranged according to the host topology (and
+ * according to the value of the 'credit2_runqueue' parameter). But
+ * we also have a cap to the number of CPUs that share runqueues.
+ * As soon as we reach the limit, a new runqueue will be created.
+ */
+static unsigned int __read_mostly opt_max_cpus_runqueue = 16;
+integer_param("sched_credit2_max_cpus_runqueue", opt_max_cpus_runqueue);
+
 /*
  * Per-runqueue data
  */
@@ -852,14 +862,61 @@ cpu_runqueue_match(const struct csched2_runqueue_data *rqd, unsigned int cpu)
            (opt_runqueue == OPT_RUNQUEUE_NODE && same_node(peer_cpu, cpu));
 }
 
+/* Additional checks, to avoid separating siblings in different runqueues. */
+static bool
+cpu_runqueue_smt_match(const struct csched2_runqueue_data *rqd, unsigned int cpu)
+{
+    unsigned int nr_sibl = cpumask_weight(per_cpu(cpu_sibling_mask, cpu));
+    unsigned int rcpu, nr_smts = 0;
+
+    /*
+     * If we put the CPU in this runqueue, we must be sure that there will
+     * be enough room for accepting its hyperthread sibling(s) here as well.
+     */
+    cpumask_clear(cpumask_scratch_cpu(cpu));
+    for_each_cpu ( rcpu, &rqd->active )
+    {
+        ASSERT(rcpu != cpu);
+        if ( !cpumask_test_cpu(rcpu, cpumask_scratch_cpu(cpu)) )
+        {
+            /*
+             * For each CPU already in the runqueue, account for it and for
+             * its sibling(s), independently from whether such sibling(s) are
+             * in the runqueue already or not.
+             *
+             * Of course, if there are sibling CPUs in the runqueue already,
+             * only count them once.
+             */
+            cpumask_or(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
+                       per_cpu(cpu_sibling_mask, rcpu));
+            nr_smts += nr_sibl;
+        }
+    }
+    /*
+     * We know that neither the CPU, nor any of its sibling are here,
+     * or we wouldn't even have entered the function.
+     */
+    ASSERT(!cpumask_intersects(cpumask_scratch_cpu(cpu),
+                               per_cpu(cpu_sibling_mask, cpu)));
+
+    /* Try adding CPU and its sibling(s) to the count and check... */
+    nr_smts += nr_sibl;
+
+    if ( nr_smts <= opt_max_cpus_runqueue )
+        return true;
+
+    return false;
+}
+
 static struct csched2_runqueue_data *
 cpu_add_to_runqueue(struct csched2_private *prv, unsigned int cpu)
 {
     struct csched2_runqueue_data *rqd, *rqd_new;
+    struct csched2_runqueue_data *rqd_valid = NULL;
     struct list_head *rqd_ins;
     unsigned long flags;
     int rqi = 0;
-    bool rqi_unused = false, rqd_valid = false;
+    bool rqi_unused = false;
 
     /* Prealloc in case we need it - not allowed with interrupts off. */
     rqd_new = xzalloc(struct csched2_runqueue_data);
@@ -873,11 +930,44 @@ cpu_add_to_runqueue(struct csched2_private *prv, unsigned int cpu)
         if ( !rqi_unused && rqd->id > rqi )
             rqi_unused = true;
 
-        if ( cpu_runqueue_match(rqd, cpu) )
+        /*
+         * Check whether the CPU should (according to the topology) and also
+         * can (if we there aren't too many already) go in this runqueue.
+         */
+        if ( rqd->refcnt < opt_max_cpus_runqueue &&
+             cpu_runqueue_match(rqd, cpu) )
         {
-            rqd_valid = true;
-            break;
+            cpumask_t *siblings = per_cpu(cpu_sibling_mask, cpu);
+
+            dprintk(XENLOG_DEBUG, "CPU %d matches runq %d, cpus={%*pbl} (max %d)\n",
+                    cpu, rqd->id, CPUMASK_PR(&rqd->active),
+                    opt_max_cpus_runqueue);
+
+            /*
+             * If we're using core (or socket!) scheduling, or we don't have
+             * hyperthreading, no need to do any further checking.
+             *
+             * If no (to both), but our sibling is already in this runqueue,
+             * then it's also ok for the CPU to stay in this runqueue..
+             *
+             * Otherwise, do some more checks, to better account for SMT.
+             */
+            if ( opt_sched_granularity != SCHED_GRAN_cpu ||
+                 cpumask_weight(siblings) <= 1 ||
+                 cpumask_intersects(&rqd->active, siblings) )
+            {
+                dprintk(XENLOG_DEBUG, "runq %d selected\n", rqd->id);
+                rqd_valid = rqd;
+                break;
+            }
+            else if ( cpu_runqueue_smt_match(rqd, cpu) )
+            {
+                dprintk(XENLOG_DEBUG, "considering runq %d...\n", rqd->id);
+                rqd_valid = rqd;
+            }
         }
+	else
+            dprintk(XENLOG_DEBUG, "ignoring runq %d\n", rqd->id);
 
         if ( !rqi_unused )
         {
@@ -900,6 +990,12 @@ cpu_add_to_runqueue(struct csched2_private *prv, unsigned int cpu)
         rqd->pick_bias = cpu;
         rqd->id = rqi;
     }
+    else
+        rqd = rqd_valid;
+
+    printk(XENLOG_INFO "CPU %d (sibling={%*pbl}) will go to runqueue %d with {%*pbl}\n",
+           cpu, CPUMASK_PR(per_cpu(cpu_sibling_mask, cpu)), rqd->id,
+           CPUMASK_PR(&rqd->active));
 
     rqd->refcnt++;
 
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index 367811a12f..e964e3f407 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -30,6 +30,8 @@ enum sched_gran {
     SCHED_GRAN_socket
 };
 
+extern enum sched_gran opt_sched_granularity;
+
 /*
  * In order to allow a scheduler to remap the lock->cpu mapping,
  * we have a per-cpu pointer, along with a pre-allocated set of



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 17:57:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 17:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTqxQ-0004PW-O9; Wed, 29 Apr 2020 17:57:16 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTqxO-0004PR-TJ
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 17:57:14 +0000
X-Inumbo-ID: d6e29dcc-8a42-11ea-9987-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d6e29dcc-8a42-11ea-9987-12813bfff9fa;
 Wed, 29 Apr 2020 17:57:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=rMDN1ZVsODeMRM+wPjxooLF560gldpbnqsba374Rtz4=; b=a7Pf/IyAxhQl4K7RrQyEPhmqe
 m3P9JR2HyYEMaNeVZ1p3wUo4h0Zk1bU1aY5J27tQUEiqn3AQp4adMb6c5YCIBp+QMNAjH+faNbUkH
 zZSybfXz/Ue/thwJHSoQa+cCM2gWDwBhSI9LXHmeyAoIAPCIW+1+JTdRAyDh/F+B+4LJs=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTqxG-0007ZD-Fc; Wed, 29 Apr 2020 17:57:06 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTqxG-00082Y-3q; Wed, 29 Apr 2020 17:57:06 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTqxG-0006J0-22; Wed, 29 Apr 2020 17:57:06 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149876-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149876: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=46d8f69d466a05863737fb81d8c9ef39c3be8b45
X-Osstest-Versions-That: xen=f9bf746258eb53011f863571c7073037202b6743
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 17:57:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149876 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149876/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  46d8f69d466a05863737fb81d8c9ef39c3be8b45
baseline version:
 xen                  f9bf746258eb53011f863571c7073037202b6743

Last test of basis   149874  2020-04-29 11:00:59 Z    0 days
Testing same since   149876  2020-04-29 14:01:03 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Juergen Gross <jgross@suse.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f9bf746258..46d8f69d46  46d8f69d466a05863737fb81d8c9ef39c3be8b45 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 18:47:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 18:47:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTrjm-0000rW-Le; Wed, 29 Apr 2020 18:47:14 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTrjl-0000rR-Vp
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 18:47:14 +0000
X-Inumbo-ID: d30ef2ac-8a49-11ea-9995-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d30ef2ac-8a49-11ea-9995-12813bfff9fa;
 Wed, 29 Apr 2020 18:47:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=xMf3P7u141zwp7/gF6tUtcszeAqWnBx03BfUQ22s9lM=; b=ISNsLJowl45iHOpNcBe4cdMCw
 hZowL0Tu+KuxfbAi/5w8QwytdlErJPzeii1CEFwzpfIcpA9eodzLtSLamjgIRfU29NP9cEyAu5iPq
 ti1iybPQcmGpsRs7kd5i/uup8XDpT970VjfVTQmWN1eYU+bPG97lmYGJHqz+L1KfF6YgI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTrje-000063-Ej; Wed, 29 Apr 2020 18:47:06 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTrje-0001YU-6a; Wed, 29 Apr 2020 18:47:06 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTrje-000659-5x; Wed, 29 Apr 2020 18:47:06 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149875-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-upstream-unstable test] 149875: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-upstream-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-upstream-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-upstream-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-upstream-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-upstream-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-upstream-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: qemuu=410cc30fdc590417ae730d635bbc70257adf6750
X-Osstest-Versions-That: qemuu=933ebad2470a169504799a1d95b8e410bd9847ef
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 18:47:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149875 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149875/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 141899
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 141899
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 141899
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 141899
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 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-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 qemuu                410cc30fdc590417ae730d635bbc70257adf6750
baseline version:
 qemuu                933ebad2470a169504799a1d95b8e410bd9847ef

Last test of basis   141899  2019-09-27 10:37:51 Z  215 days
Testing same since   149875  2020-04-29 12:38:30 Z    0 days    1 attempts

------------------------------------------------------------
404 people touched revisions under test,
not listing them all

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   933ebad247..410cc30fdc  410cc30fdc590417ae730d635bbc70257adf6750 -> master


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 20:17:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 20:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTt8M-0001Bh-Od; Wed, 29 Apr 2020 20:16:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hWzR=6N=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTt8L-0001Ba-30
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 20:16:41 +0000
X-Inumbo-ID: 55f0f178-8a56-11ea-b9cf-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 55f0f178-8a56-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 20:16:40 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 854E92083B;
 Wed, 29 Apr 2020 20:16:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588191399;
 bh=+WwQinBy5HLz5vqGNTrSlYo5fEFhi7mlHNUQ/AiAnDA=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=FpcIkNXDMLpFoA+lgnm212TXYbj5FppIknp/xXdVA2xSRm8unHppnQHB5ccvCg0ey
 7Eus42oLMPnGkMor9mL96VC75uhMjwYNgB4/s7HuZqwq5Z84H4MEd66Zxf1s1eBs9b
 D0j3WerYOE3Fkow14YZR+VDHfTldbyYIBNTn9Bnk=
Date: Wed, 29 Apr 2020 13:16:31 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH 0/12] direct-map DomUs
In-Reply-To: <4a62c7c1-710f-21a9-a6cc-03aa290e18b1@xen.org>
Message-ID: <alpine.DEB.2.21.2004291313030.28941@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <4a62c7c1-710f-21a9-a6cc-03aa290e18b1@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Artem_Mygaiev@epam.com, peng.fan@nxp.com,
 Stefano Stabellini <sstabellini@kernel.org>, andrew.cooper3@citrix.com,
 George.Dunlap@citrix.com, Bertrand.Marquis@arm.com, jbeulich@suse.com,
 xen-devel@lists.xenproject.org, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, 16 Apr 2020, Julien Grall wrote:
> > Stefano Stabellini (12):
> >        xen: introduce xen_dom_flags
> >        xen/arm: introduce arch_xen_dom_flags and direct_map
> >        xen/arm: introduce 1:1 mapping for domUs
> >        xen: split alloc_heap_pages in two halves for reusability
> >        xen: introduce reserve_heap_pages
> >        xen/arm: reserve 1:1 memory for direct_map domUs
> >        xen/arm: new vgic: rename vgic_cpu/dist_base to c/dbase
> >        xen/arm: if is_domain_direct_mapped use native addresses for GICv2
> >        xen/arm: if is_domain_direct_mapped use native addresses for GICv3
> >        xen/arm: if is_domain_direct_mapped use native UART address for vPL011
> 
> The 3 patches above cover addresses but not interrupts. Why?

Hi Julien,

I take that you are referring to GUEST_VPL011_SPI, right?


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 20:18:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 20:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTtAJ-0001IZ-6A; Wed, 29 Apr 2020 20:18:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTtAH-0001IS-9j
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 20:18:41 +0000
X-Inumbo-ID: 9ab19790-8a56-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9ab19790-8a56-11ea-b9cf-bc764e2007e4;
 Wed, 29 Apr 2020 20:18:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=4Xi4TbKEqEtfoUrt6sMAIk6sCp1zu4+YK9OwAWUphc0=; b=3hw6MmmCg5rzTwQb8Jx/btQaV
 K0dwkifq2Y/5+fhfZN+3evepVt3oP7wITrlAP833hM1JXlKq14jHlsGF+qLUfVExfl7WGHy9lze8M
 avi0+bPdECgMwGF8yrP1aaz7OTR38QggJkexUdxSN648pWVuvZ13v69T1s+CzRleYK6eQ=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTtAB-0001pl-DH; Wed, 29 Apr 2020 20:18:35 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTtAB-0004w7-4c; Wed, 29 Apr 2020 20:18:35 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTtAB-0004fF-3v; Wed, 29 Apr 2020 20:18:35 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149883-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149883: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=4304ff420e51b973ec9eb9dafd64a917dd9c0fb1
X-Osstest-Versions-That: xen=46d8f69d466a05863737fb81d8c9ef39c3be8b45
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 20:18:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149883 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149883/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  4304ff420e51b973ec9eb9dafd64a917dd9c0fb1
baseline version:
 xen                  46d8f69d466a05863737fb81d8c9ef39c3be8b45

Last test of basis   149876  2020-04-29 14:01:03 Z    0 days
Testing same since   149883  2020-04-29 18:01:04 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   46d8f69d46..4304ff420e  4304ff420e51b973ec9eb9dafd64a917dd9c0fb1 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 20:47:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 20:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTtc9-0004Gq-Or; Wed, 29 Apr 2020 20:47:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hWzR=6N=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTtc8-0004Gl-D0
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 20:47:28 +0000
X-Inumbo-ID: a2e1feed-8a5a-11ea-99b9-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a2e1feed-8a5a-11ea-99b9-12813bfff9fa;
 Wed, 29 Apr 2020 20:47:27 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id D662220BED;
 Wed, 29 Apr 2020 20:47:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588193247;
 bh=3R5YYifFP5fZiK4rtqCpLdImbEXA1mR8/vPbWuFFGzY=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=NKBTPyB9z71TIQjkA788m1hA2KjtCBKH/c+2b6Er23nthghLoIDSLNJEv6EaLq5sM
 4jk0fsW309mkRVC5WaIryQdFZm/hzcdMa1cJwBhMmILklm2o7wnfbn3U6COzjMJfV3
 pvtE0hRTSQSbTuifrSduImRyICBj62pFl/mLDZ1c=
Date: Wed, 29 Apr 2020 13:47:25 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH 12/12] xen/arm: call iomem_permit_access for passthrough
 devices
In-Reply-To: <521c8e55-73e8-950f-2d94-70b0c664bd3d@xen.org>
Message-ID: <alpine.DEB.2.21.2004291318270.28941@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-12-sstabellini@kernel.org>
 <521c8e55-73e8-950f-2d94-70b0c664bd3d@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr_Babchuk@epam.com, Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 15 Apr 2020, Julien Grall wrote:
> On 15/04/2020 02:02, Stefano Stabellini wrote:
> > iomem_permit_access should be called for MMIO regions of devices
> > assigned to a domain. Currently it is not called for MMIO regions of
> > passthrough devices of Dom0less guests. This patch fixes it.
> 
> You can already have cases today where the MMIO regions are mapped to the
> guest but the guest doesn't have permission on them.
> 
> Can you explain why this is a problem here?

I don't remember the original problem that prompted me into doing this
investigation. It came up while I was developing and testing this
series: I noticed the discrepancy compared to the regular (not dom0less)
device assignment code path
(tools/libxl/libxl_create.c:domcreate_launch_dm).

Now I removed this patch from the series, went back to test it, and it
still works fine. Oops, it is not needed after all :-)


I think it makes sense to remove this patch from this series, I'll do
that.

But doesn't it make sense to give domU permission if it is going to get
the memory mapped? But admittedly I can't think of something that would
break because of the lack of the iomem_permit_access call in this code
path.


> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > ---
> >   xen/arch/arm/domain_build.c | 11 +++++++++++
> >   1 file changed, 11 insertions(+)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index d0fc497d07..d3d42eef5d 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1846,6 +1846,17 @@ static int __init handle_passthrough_prop(struct
> > kernel_info *kinfo,
> >               return -EINVAL;
> >           }
> >   +        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
> > +                                  paddr_to_pfn(PAGE_ALIGN(mstart + size -
> > 1)));
> > +        if ( res )
> > +        {
> > +            printk(XENLOG_ERR "Unable to permit to dom%d access to"
> > +                   " 0x%"PRIx64" - 0x%"PRIx64"\n",
> > +                   kinfo->d->domain_id,
> > +                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
> > +            return res;
> > +        }
> > +
> >           res = map_regions_p2mt(kinfo->d,
> >                                  gaddr_to_gfn(gstart),
> >                                  PFN_DOWN(size),
> > 
> 
> -- 
> Julien Grall
> 


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 21:39:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 21:39:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTuQA-0000iK-O6; Wed, 29 Apr 2020 21:39:10 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4OoD=6N=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jTuQ9-0000iF-AB
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 21:39:09 +0000
X-Inumbo-ID: daa06ba0-8a61-11ea-99c5-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id daa06ba0-8a61-11ea-99c5-12813bfff9fa;
 Wed, 29 Apr 2020 21:39:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588196347;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=aZVGHYP4QKwl6RonE5nEe5V/P6Tr3xyY8ohRc2QN858=;
 b=AcDkrj4s/0nvbRSjNcViV2acVUrGuxpyFy+ZOkMfBZsUTjuIe2E0U7mx
 L+Wwh+wedYXW/2vg4uPO3zIWp7OvNs9lhHzKVcRvvoGVGvd5Qn3EKuenk
 T6zezQ20//fuD+FisBxF3XSy/BQkmJhYq4LjHb4u0NzdtnbPE1B9bcAEG Q=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: ojIZxgykRp9cbQx+zLJsUVZ/V6tjGivFewLzRLyQg1olcru5QcIBWHzlvehWDSXnKHg1gNlbN9
 jt4PiDOer6PgB11b7t8C7XwAd5SxTp/9cuaL/4oGDHWRruM+XxQPr0coyndqhSyx0SJS1yeqT5
 vwXBrT5KkBOEvcDsV8mibpjeW/EosM1zWuFR2Ayx7ca5ovYlvvKcO/GjEnpzdz55UsgKfAkyx2
 DdhKy9ccO5KZ7oKrNunE97Ubd6GiLK+ypwmOCdfnpuEMln89CRKy+0JxCgKyUIpiTqx9jKAX5g
 u5A=
X-SBRS: 2.7
X-MesageID: 16783390
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,333,1583211600"; d="scan'208";a="16783390"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/msr: Fix XEN_MSR_PAT to build with older binutils
Date: Wed, 29 Apr 2020 22:39:01 +0100
Message-ID: <20200429213901.16105-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Older binutils complains with:
  trampoline.S:95: Error: junk `ul&0xffffffff' after expression

Use an assembly-safe constant.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/include/asm-x86/processor.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index ea6e5497f4..8f6f5a97dd 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -99,7 +99,7 @@
  * Host IA32_CR_PAT value to cover all memory types.  This is not the default
  * MSR_PAT value, and is an ABI with PV guests.
  */
-#define XEN_MSR_PAT 0x050100070406ul
+#define XEN_MSR_PAT _AC(0x050100070406, ULL)
 
 #ifndef __ASSEMBLY__
 
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Wed Apr 29 21:56:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 21:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTugI-0002da-6Y; Wed, 29 Apr 2020 21:55:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hWzR=6N=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTugH-0002dV-FR
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 21:55:49 +0000
X-Inumbo-ID: 2f784d94-8a64-11ea-99c8-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2f784d94-8a64-11ea-99c8-12813bfff9fa;
 Wed, 29 Apr 2020 21:55:49 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 1E0F520757;
 Wed, 29 Apr 2020 21:55:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588197348;
 bh=diUTY46+qY1IsVc/mNZYrPbo+l09ZUWCWIW8EicgNEY=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=rmnWq5Sgtw/6VswTwO4tNgtEhHlfx+ZAPpplH7c42S8BmouIEac2pL/+Ya5pYzPkI
 Cmx2JE+Jz4rsGhw1RIoUSIOxdrIrrqEBJUu8f4cQ2uqrPJ22OOGuzOD7RMIsc+3m5C
 gtZ2EZD/G+MC3c+Rv2GAH/7f1Zj23OyZ9XJ7Rtvc=
Date: Wed, 29 Apr 2020 14:55:47 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH 11/12] xen/arm: if xen_force don't try to setup the IOMMU
In-Reply-To: <4b4263ba-bf6f-e578-037d-edb8add52aad@xen.org>
Message-ID: <alpine.DEB.2.21.2004291400340.28941@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-11-sstabellini@kernel.org>
 <4b4263ba-bf6f-e578-037d-edb8add52aad@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr_Babchuk@epam.com, Stefano Stabellini <stefano.stabellini@xilinx.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 15 Apr 2020, Julien Grall wrote:
> Hi Stefano,
> 
> On 15/04/2020 02:02, Stefano Stabellini wrote:
> > If xen_force (which means xen,force-assign-without-iommu was requested)
> > don't try to add the device to the IOMMU. Return early instead.
> 
> 
> Could you explain why this is an issue to call xen_force after
> iommu_add_dt_device()?

There are two issues. I should add info about both of them to the commit
message.


The first issue is that an error returned by iommu_add_dt_device (for
any reason) would cause handle_passthrough_prop to stop and return error
right away. But actually the iommu is not needed for that device if
xen_force is set.

(In fact, one of the reasons why a user might want to set
force-assign-without-iommu is because there are iommu issues with a
device.)


The second issue is about the usage of "xen,force-assign-without-iommu":
it would be useful to let the user set "xen,force-assign-without-iommu"
for devices that are described as behind a SMMU in device tree, but
the SMMU can't actually be used for some reason. Of course, the user
could always manually edit the device tree to make it look like as if
the device is not behind an IOMMU. That would work OK. However, I think
it would be better to avoid making that a requirement.

If we want to allow "xen,force-assign-without-iommu" for a device behind
a SMMU then we need this patch, otherwise this would happen:

    res = iommu_add_dt_device(node); // succeeds
    if ( xen_force && !dt_device_is_protected(node) ) // fails because the device is protected
        return 0;
    return iommu_assign_dt_device(kinfo->d, node); // fails because !is_iommu_enabled(d) which is fine but then handle_prop_pfdt returns error too



All in all, I thought it would make sense to avoid any iommu settings
and potential iommu errors altogether if xen_force is set and return
early.


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 22:46:40 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 22:46:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTvTB-0007SR-4N; Wed, 29 Apr 2020 22:46:21 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hWzR=6N=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTvT9-0007SM-Qk
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 22:46:19 +0000
X-Inumbo-ID: 3d9bb134-8a6b-11ea-99d1-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3d9bb134-8a6b-11ea-99d1-12813bfff9fa;
 Wed, 29 Apr 2020 22:46:19 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 1415320757;
 Wed, 29 Apr 2020 22:46:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588200378;
 bh=oedlrQGaxlAcZq0TWpE/UHeneElBWnwqThY9pMSIxW8=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=N6cX7XWLvD8dMTs9Npwfe6WZQQwp4SCCf92uriYplgYfZaSgbfz1z7C+tnuHLVs77
 eTyNOjJeRJK+W30+ULFIpsjhz/XqbLiGaXhXlwFqnwa9hkqNDPK4UjsDg48CF3oRhd
 XVtw2jeBJsGmvdT5ZQ5xaKczoZRofRJy0MNhGi3U=
Date: Wed, 29 Apr 2020 15:46:17 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 05/12] xen: introduce reserve_heap_pages
In-Reply-To: <3129ab49-5898-9d2e-8fbb-d1fcaf6cdec7@suse.com>
Message-ID: <alpine.DEB.2.21.2004291510270.28941@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-5-sstabellini@kernel.org>
 <3129ab49-5898-9d2e-8fbb-d1fcaf6cdec7@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 17 Apr 2020, Jan Beulich wrote:
> On 15.04.2020 03:02, Stefano Stabellini wrote:
> > Introduce a function named reserve_heap_pages (similar to
> > alloc_heap_pages) that allocates a requested memory range. Call
> > __alloc_heap_pages for the implementation.
> > 
> > Change __alloc_heap_pages so that the original page doesn't get
> > modified, giving back unneeded memory top to bottom rather than bottom
> > to top.
> 
> While it may be less of a problem within a zone, doing so is
> against our general "return high pages first" policy.

Is this something you'd be OK with anyway?

If not, do you have a suggestion on how to do it better? I couldn't find
a nice way to do it without code duplication, or a big nasty 'if' in the
middle of the function.


> > @@ -1073,7 +1073,42 @@ static struct page_info *alloc_heap_pages(
> >          return NULL;
> >      }
> >  
> > -    __alloc_heap_pages(&pg, order, memflags, d);
> > +    __alloc_heap_pages(pg, order, memflags, d);
> > +    return pg;
> > +}
> > +
> > +static struct page_info *reserve_heap_pages(struct domain *d,
> > +                                            paddr_t start,
> > +                                            unsigned int order,
> > +                                            unsigned int memflags)
> > +{
> > +    nodeid_t node;
> > +    unsigned int zone;
> > +    struct page_info *pg;
> > +
> > +    if ( unlikely(order > MAX_ORDER) )
> > +        return NULL;
> > +
> > +    spin_lock(&heap_lock);
> > +
> > +    /*
> > +     * Claimed memory is considered unavailable unless the request
> > +     * is made by a domain with sufficient unclaimed pages.
> > +     */
> > +    if ( (outstanding_claims + (1UL << order) > total_avail_pages) &&
> > +          ((memflags & MEMF_no_refcount) ||
> > +           !d || d->outstanding_pages < (1UL << order)) )
> > +    {
> > +        spin_unlock(&heap_lock);
> > +        return NULL;
> > +    }
> 
> Where would such a claim come from? Given the purpose I'd assume
> the function (as well as reserve_domheap_pages()) can actually be
> __init. With that I'd then also be okay with them getting built
> unconditionally, i.e. even on x86.

Yes, you are right, I'll make the function __init and also remove this
check on claimed memory.


> > +    pg = maddr_to_page(start);
> > +    node = phys_to_nid(start);
> > +    zone = page_to_zone(pg);
> > +    page_list_del(pg, &heap(node, zone, order));
> > +
> > +    __alloc_heap_pages(pg, order, memflags, d);
> 
> I agree with Julien in not seeing how this can be safe / correct.

I haven't seen any issues so far in my testing -- I imagine it is
because there aren't many memory allocations after setup_mm() and before
create_domUs()  (which on ARM is called just before
domain_unpause_by_systemcontroller at the end of start_xen.)


I gave a quick look at David's series. Is the idea that I should add a
patch to do the following:

- avoiding adding these ranges to xenheap in setup_mm, wait for later
  (a bit like reserved_mem regions)

- in construct_domU, add the range to xenheap and reserve it with reserve_heap_pages

Is that right?


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 22:51:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 22:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTvXw-0008Pf-OL; Wed, 29 Apr 2020 22:51:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MXSB=6N=gmail.com=bobbyeshleman@srs-us1.protection.inumbo.net>)
 id 1jTvXv-0008Pa-Gj
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 22:51:15 +0000
X-Inumbo-ID: edf673de-8a6b-11ea-ae69-bc764e2007e4
Received: from mail-qt1-x832.google.com (unknown [2607:f8b0:4864:20::832])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id edf673de-8a6b-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 22:51:14 +0000 (UTC)
Received: by mail-qt1-x832.google.com with SMTP id e17so3421950qtp.7
 for <xen-devel@lists.xenproject.org>; Wed, 29 Apr 2020 15:51:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=date:from:to:cc:subject:message-id:mime-version:content-disposition;
 bh=seb2/D9RvdMJfBjkiDlGc8MKTgqVCXYE1BAnT3EqnTo=;
 b=dUhH15OHuLOFuxTl1EGav/ft+g5kRqNDF1xEL2JSto9GgHmivyPpM9WtsLsbZQgzjf
 AE+oVrfLeS6mwKyRev5Ljy49inb4nq9thwarJFp/gpOYMsMmYndx5f2x0pFnGC/dkorP
 vnjPJKxe7j2hfe4H4YfAc+kdyuPCXUkmzFJagUusVCqmf86f9NpEzLa3xldB/5LIhuI+
 daJ+cy97MrncG1+7gg0SIEtlqVCT3EeIHvAxEJbH9YBWXVRE3f9V8hdjDDoBraQ0Qosp
 PKphiWufpt4IbZPNuNFw0DruL7NLoKF3MYxC0+dSaJe1pHF8i0fop+5l1UlbtYYr+2Ih
 iwMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version
 :content-disposition;
 bh=seb2/D9RvdMJfBjkiDlGc8MKTgqVCXYE1BAnT3EqnTo=;
 b=CZFjrVDvwoaAgRLANbMbvmbusEn4S1croWBP+xoBDvJZBzUs/xEqodFcIqd2ZdDuhH
 abvSTkezL2IOgBaGJNHYd22srsILQrQhTKt/SvOfe9HEveeoQe5Mbzwa631jyoomDfYo
 rQR0QaEMbPP5uW2SCnivU31Vx7YtYX3Y7VkKb3i1LdvxjKo4lvdW9JCPXwaHpdJ8kCey
 1dhr/A0Ge9B8mkUfjJJOSoJSj61GSpnmQPZA3w2V5bjUJ2rtaKMAlefYX5Qy0Lso6CiP
 6PtIEs6xUFQl8AEgKRoNRaqIB9oqO+HIRv/60aIA6qde7xAaEGkGkRU2rC3YY0S51UsH
 uzEQ==
X-Gm-Message-State: AGi0PuZLD9kDuqJzwflFjpqg9yAW66o7bzW3WOK5Dgo+feQ6jk81VBCN
 0x1ZZiumEhUD/mJYkX1GY1/WETFpwn4=
X-Google-Smtp-Source: APiQypKPc4cD+wE26dyP4UCO3+l2ZkosPoQjmE6nnQbXERvg+KXqomZV+r1qClSgWPP8uiJfolo0XQ==
X-Received: by 2002:ac8:7758:: with SMTP id g24mr633111qtu.85.1588200673753;
 Wed, 29 Apr 2020 15:51:13 -0700 (PDT)
Received: from bobbye-pc ([216.186.244.35])
 by smtp.gmail.com with ESMTPSA id s15sm545122qtc.31.2020.04.29.15.51.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 29 Apr 2020 15:51:12 -0700 (PDT)
Date: Wed, 29 Apr 2020 17:51:08 -0500
From: Bobby Eshleman <bobbyeshleman@gmail.com>
To: xen-devel@lists.xenproject.org
Subject: [RFC] UEFI Secure Boot on Xen Hosts
Message-ID: <20200429225108.GA54201@bobbye-pc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: michal.zygowski@3mdeb.com, daniel.kiper@oracle.com,
 krystian.hebel@3mdeb.com, olivier.lambert@vates.fr, piotr.krol@3mdeb.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hey all,

We're looking to develop UEFI Secure Boot support for grub-loaded Xen and
ultimately for XCP-ng (I'm on the XCP-ng team at Vates).

In addition to carrying the chain-of-trust through the entire boot sequence
into dom0, we would also like to build something akin to Linux's Lockdown for
dom0 and its privileged interfaces.

It appears that there are various options and we'd like to discuss them with
the community.

# Option #1: PE/COFF and Shim

Shim installs a verification protocol available to subsequent programs via EFI
boot services.  The protocol is called SHIM_LOCK and it is currently supported
by xen.efi.

Shim requires the payload under verification to be a PE/COFF executable.  In
order to support both shim and maintain the multiboot2 protocol, Daniel Kiper's
patchset [1]  (among other things) incorporates the PE/COFF header
into xen.gz and adds dom0 verification via SHIM_LOCK in
efi_multiboot2().

There appears that some work will be needed on top of this patchset, but not
much as it seems most of the foot work has been done.

AFAIK, the changes needed in GRUB for this approach are already upstream (the
shim_lock module is upstream), and shim would go untouched.

# Option #2: Extended Multiboot2 and Shim

Another approach that could be taken is to embed Xen's signature into a
new multiboot2 header and then modify shim to support it.  This would
arguably be more readable than embedding the PE/COFF header, would add
value to shim, and would fit nicely with the mb2 header code that
already exists in Xen.  The downside being that it would require a shim
fork.  Grub2 would be unchanged.

I'm not familliar with Microsoft's signing process.  I do know they
support template submissions based on shim, and I'm not sure if such a
big change would impact their approval process.

# Option #3: Lean on Grub2's LoadFile2() Verification

Grub2 will provide a LoadFile2() method to subsequent programs that supports
signature verification of arbitrary files.  Linux is moving in the
direction of using LoadFile2() for loading the initrd [2], and Grub2 will
support verifying the signatures of files loaded via LoadFile2().  This is set
for release in GRUB 2.06 sometime in the latter half of 2020.

In Xen, this approach could be used for loading dom0 as well, offering a very
simple verified load interface.

Currently the initrd argument passed from Linux to LoadFile2() is a vendor
media device path GUID [3].

Changes to Xen:
- Xen would need to pass these device paths to Grub
- Xen would be changed to load dom0 with the LoadFile2() interface via boot services

Changes to Grub:
- Xen dom0 kernel/initrd device paths would need to be introduced to Grub

Potential Issues:
- How will Xen handle more boot modules than just a dom0 and dom0
  initrd?
- Would each boot module need a unique vendor guid?
- Would this interfere with the DomB proposal?  I suspect not because
  the DomB proposal suggests launching DomUs from an already booted
  DomB, at which point other means could be used.

We'd just like to get the conversation going on this topic before we
dive too far into implementing something.  Are any of these approaches a
hard no for upstreaming?  Do any stand out as best candidates?  Any
feedback / questions / criticisms would be greatly appreciated.

Thanks,
Bobby Eshleman


# References

1. Daniel Kiper's patchset:
    https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01292.html
2. Linux loading initrd with LoadFile2():
    https://lkml.org/lkml/2020/2/17/331
3. The vendor media guid for initrd:
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/libstub/efi-stub-helper.c#n311


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 23:10:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 23:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTvpz-0001CT-Gi; Wed, 29 Apr 2020 23:09:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hWzR=6N=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTvpy-0001CO-5U
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 23:09:54 +0000
X-Inumbo-ID: 88ba721a-8a6e-11ea-9887-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 88ba721a-8a6e-11ea-9887-bc764e2007e4;
 Wed, 29 Apr 2020 23:09:53 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 94C52206D9;
 Wed, 29 Apr 2020 23:09:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588201793;
 bh=ogQClBdgkF4ZlfvC1m+J7l7r216UsRuYxc3VelIEtO4=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=Qzp8c+9HNGyyh0YlFav0Ov0171e0EDWkJMhBiZd6/XU8s3aT2c42DUW0ilGsYca1P
 z0W3Mw0Z8U8jTvwAADMvlNDg61hC5t3sAxRlPFsF1Cr3zVgj6GHmfUIeo0/ZXmGlrq
 ZrQEy2Sx6R5atMU6GuHgyhnNlGwIRpTcufiNeNzI=
Date: Wed, 29 Apr 2020 16:09:51 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 04/12] xen: split alloc_heap_pages in two halves for
 reusability
In-Reply-To: <348994e9-7b32-33fc-0e40-f7e1a6543b92@suse.com>
Message-ID: <alpine.DEB.2.21.2004291609440.28941@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-4-sstabellini@kernel.org>
 <348994e9-7b32-33fc-0e40-f7e1a6543b92@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Fri, 17 Apr 2020, Jan Beulich wrote:
> On 15.04.2020 03:02, Stefano Stabellini wrote:
> > --- a/xen/common/page_alloc.c
> > +++ b/xen/common/page_alloc.c
> > @@ -911,54 +911,18 @@ static struct page_info *get_free_buddy(unsigned int zone_lo,
> >      }
> >  }
> >  
> > -/* Allocate 2^@order contiguous pages. */
> > -static struct page_info *alloc_heap_pages(
> > -    unsigned int zone_lo, unsigned int zone_hi,
> > -    unsigned int order, unsigned int memflags,
> > -    struct domain *d)
> > +static void __alloc_heap_pages(struct page_info **pgo,
> > +                               unsigned int order,
> > +                               unsigned int memflags,
> > +                               struct domain *d)
> 
> Along the line of Wei's reply, I'd suggest the name to better reflect
> the difference to alloc_heap_pages() itself. Maybe
> alloc_pages_from_buddy() or alloc_buddy_pages()?
> 
> In addition
> - no double leading underscores please
> - instead of the function returning void and taking
>   struct page_info **pgo, why not have it take and return
>   struct page_info *?
> - add a comment about the non-standard locking behavior

I made all these changes


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 23:20:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 23:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTw07-0002rh-FU; Wed, 29 Apr 2020 23:20:23 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTw06-0002rb-DP
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 23:20:22 +0000
X-Inumbo-ID: ff2b5904-8a6f-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id ff2b5904-8a6f-11ea-ae69-bc764e2007e4;
 Wed, 29 Apr 2020 23:20:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=5hyFd66exywvMa7Ne+91ndOWTYMbATLgnbI2nGM+R0I=; b=PChShtRXFKW7seA4PZsg/JUjg
 Mt7SrlxBWxwJtjPjCkC+hR4ANOe9ZsBNPZEPypHu+rChY9P+Jz6JoAi85cRCogzgOI7J+I5LCUhel
 SZSOOQVvRzcQw3g5224ZnK7UjW+cmPGYFdwy94KnGj0e/kp3EtGkvN9FfLP2qi8hFM2P0=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTw05-0005B5-BB; Wed, 29 Apr 2020 23:20:21 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTw05-000705-0I; Wed, 29 Apr 2020 23:20:21 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTw04-00054k-Vr; Wed, 29 Apr 2020 23:20:20 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149884-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149884: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=8065e1b41688592778de76c731c62f34e71f3129
X-Osstest-Versions-That: xen=4304ff420e51b973ec9eb9dafd64a917dd9c0fb1
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 23:20:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149884 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149884/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  8065e1b41688592778de76c731c62f34e71f3129
baseline version:
 xen                  4304ff420e51b973ec9eb9dafd64a917dd9c0fb1

Last test of basis   149883  2020-04-29 18:01:04 Z    0 days
Testing same since   149884  2020-04-29 21:02:20 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4304ff420e..8065e1b416  8065e1b41688592778de76c731c62f34e71f3129 -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 23:46:51 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 23:46:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTwPP-00056E-LE; Wed, 29 Apr 2020 23:46:31 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=totz=6N=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTwPO-000569-F8
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 23:46:30 +0000
X-Inumbo-ID: a592a86c-8a73-11ea-99dd-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a592a86c-8a73-11ea-99dd-12813bfff9fa;
 Wed, 29 Apr 2020 23:46:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=8PrMnlZzTaie1zQJnwh+xjfdkffK92EoQ3HBR8GbA/4=; b=RLYArM6XP8CADw4NDDKWrdLrt
 Ew+J3kp+4x6TgqunAkYyAur+aDrScToLylmAYUOIabbsHhvLAl65Wi9Y1/cR8LkImt0flgfj04RKd
 0Dw/c/4MFoutf6IyxYQXR5loXngth0d9jFNAFQ57MTVNVKNmwDwvAVzbeq6QFDusHvM44=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTwPN-0005d9-0p; Wed, 29 Apr 2020 23:46:29 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTwPM-0001Bd-Lz; Wed, 29 Apr 2020 23:46:28 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTwPM-0005p2-LB; Wed, 29 Apr 2020 23:46:28 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149877-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149877: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=a7922a3c81f34f45b1ebc9670a7769edc4c42a43
X-Osstest-Versions-That: qemuu=fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6
From: osstest service owner <osstest-admin@xenproject.org>
Date: Wed, 29 Apr 2020 23:46:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149877 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149877/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10       fail  like 149866
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149866
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149866
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149866
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149866
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149866
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-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-thunderx 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 qemuu                a7922a3c81f34f45b1ebc9670a7769edc4c42a43
baseline version:
 qemuu                fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6

Last test of basis   149866  2020-04-28 17:07:10 Z    1 days
Testing same since   149877  2020-04-29 14:36:19 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Peter Maydell <peter.maydell@linaro.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   fdd76fecdd..a7922a3c81  a7922a3c81f34f45b1ebc9670a7769edc4c42a43 -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Wed Apr 29 23:57:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Apr 2020 23:57:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTwaM-00069P-Ou; Wed, 29 Apr 2020 23:57:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hWzR=6N=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTwaL-00069K-HD
 for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 23:57:49 +0000
X-Inumbo-ID: 3a1d0974-8a75-11ea-99de-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3a1d0974-8a75-11ea-99de-12813bfff9fa;
 Wed, 29 Apr 2020 23:57:48 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id AFCD7206D9;
 Wed, 29 Apr 2020 23:57:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588204668;
 bh=lyOc+qDnLIA/VmUz/1uihooqx28w/cmElWlWhvNSQ4E=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=nLG/uTXq6mLlc+tvM+1kmZCSktEMPfpdbYfBy+jwuPnIiZAFtfbOD0+eh0R91XPjz
 DzJvugFOJTrD+G27g2g6np0G2RhpXRwM8UWpypilsfzv56SMhNC/qM7jnlZLkDVf9D
 KIqp3bdEDAnewW0PyhC6D6tjQCjaUjCh/7B02Tsc=
Date: Wed, 29 Apr 2020 16:57:47 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 01/12] xen: introduce xen_dom_flags
In-Reply-To: <aede4742-03e1-e47b-354a-5475f63fff86@suse.com>
Message-ID: <alpine.DEB.2.21.2004291628070.28941@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-1-sstabellini@kernel.org>
 <aede4742-03e1-e47b-354a-5475f63fff86@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 Dario Faggioli <dfaggioli@suse.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 15 Apr 2020, Jan Beulich wrote:
> On 15.04.2020 03:02, Stefano Stabellini wrote:
> > We are passing an extra special boolean flag at domain creation to
> > specify whether we want to the domain to be privileged (i.e. dom0) or
> > not. Another flag will be introduced later in this series.
> > 
> > Introduce a new struct xen_dom_flags and move the privileged flag to it.
> > Other flags will be added to struct xen_dom_flags.
> 
> I'm unsure whether introducing a 2nd structure is worth it here.
> We could as well define some internal-use-only flags for
> struct xen_domctl_createdomain's respective field.

Yep, great idea, I'll do that instead.


> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -529,7 +529,8 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> >  }
> >  
> >  int arch_domain_create(struct domain *d,
> > -                       struct xen_domctl_createdomain *config)
> > +                       struct xen_domctl_createdomain *config,
> > +                       struct xen_dom_flags *flags)
> 
> const (also elsewhere)?

All of this goes away now, using the exising flag field in
xen_domctl_createdomain, reserving the top 16 bits for internal usage.


> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -706,6 +706,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >          .max_maptrack_frames = -1,
> >      };
> >      const char *hypervisor_name;
> > +    struct xen_dom_flags flags = { !pv_shim };
> 
> Here and elsewhere please use field designators right away, even if
> there's only a single field now.
> 
> > @@ -363,7 +363,7 @@ struct domain *domain_create(domid_t domid,
> >      ASSERT(is_system_domain(d) ? config == NULL : config != NULL);
> >  
> >      /* Sort out our idea of is_control_domain(). */
> > -    d->is_privileged = is_priv;
> > +    d->is_privileged =  flags ? flags->is_priv : false;
> 
> Stray double blanks.
> 
> > --- a/xen/common/domctl.c
> > +++ b/xen/common/domctl.c
> > @@ -364,6 +364,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> >      bool_t copyback = 0;
> >      struct xen_domctl curop, *op = &curop;
> >      struct domain *d;
> > +    struct xen_dom_flags flags ={ false };
> 
> Missing blank.
> 
> > --- a/xen/include/xen/domain.h
> > +++ b/xen/include/xen/domain.h
> > @@ -63,8 +63,13 @@ void arch_vcpu_destroy(struct vcpu *v);
> >  int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset);
> >  void unmap_vcpu_info(struct vcpu *v);
> >  
> > +struct xen_dom_flags {
> > +    bool is_priv;
> 
> Use a single bit bitfield instead? May even want to consider passing
> this struct by value then.
 


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 00:34:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 00:34:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTx9p-0002AL-TJ; Thu, 30 Apr 2020 00:34:29 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=kEmr=6O=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jTx9o-0002AG-Ld
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 00:34:28 +0000
X-Inumbo-ID: 5976da0a-8a7a-11ea-9887-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5976da0a-8a7a-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 00:34:28 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 5F71120731;
 Thu, 30 Apr 2020 00:34:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588206867;
 bh=XInN9WD+q3mgzx+OHQrHGVwTAvRCMnc5MpQJ2vldbY4=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=osh6jMnhqZJ8WvNP0G/J9F0GTph3J+dT9FOwp4SV6WvoUQhLY4LUeujQEENvrkZbw
 iYPhrsSL0sCpb1QC/JZ7gfeVtinBDsjWb3/dqr/HXDc4gLB9zesZBOvX8L9OCtyXld
 TJSXfm5mN7FN3qYVacfzMhia+AvVAJijX89A/P/Q=
Date: Wed, 29 Apr 2020 17:34:26 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 02/12] xen/arm: introduce arch_xen_dom_flags and direct_map
In-Reply-To: <4130f640-a664-a9e7-fcd7-85bbd58287e4@suse.com>
Message-ID: <alpine.DEB.2.21.2004291733570.28941@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-2-sstabellini@kernel.org>
 <4130f640-a664-a9e7-fcd7-85bbd58287e4@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, 15 Apr 2020, Jan Beulich wrote:
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2527,6 +2527,7 @@ int __init construct_dom0(struct domain *d)
> >  
> >      iommu_hwdom_init(d);
> >  
> > +    d->arch.direct_map = true;
> 
> Shouldn't this get set via arch_domain_create() instead?

Yes you are right, this is unnecessary and I can remove it.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 02:33:11 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 02:33:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jTz0O-0002rB-GX; Thu, 30 Apr 2020 02:32:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DLrL=6O=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jTz0O-0002r6-0S
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 02:32:52 +0000
X-Inumbo-ID: e1e4c07c-8a8a-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e1e4c07c-8a8a-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 02:32:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=uB4wIJ7bUbVM7wuO5tf2VwnlrACIAVUb5OGdkMmA3pY=; b=0YSkZY+1hndnSCXe76QfRlAFy
 RiPFsv/HBlsSdCcCV8ISWuFSCGSIB5qC/CjOfw+akSJkmnlOiQqDVM4zJ5WLNdL+NBylbZ7I3MdhZ
 wArVs1WC3zsBWCREcuXkTLiPPSdJBQQGUR61huwwv+61OU2ZnzQRfI7GuwefPmsF81S1Q=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTz0K-0007IL-HS; Thu, 30 Apr 2020 02:32:48 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jTz0K-0000nJ-6C; Thu, 30 Apr 2020 02:32:48 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jTz0K-0007NC-56; Thu, 30 Apr 2020 02:32:48 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149878-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 149878: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-5.4:test-armhf-armhf-xl-rtds:guest-stop:fail:allowable
 linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=aa73bcc376865c23e61dcebd467697b527901be8
X-Osstest-Versions-That: linux=0c418786cb3aa175823f0172d939679df9ab9a54
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 30 Apr 2020 02:32:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149878 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149878/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds     15 guest-stop               fail REGR. vs. 149749

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149749
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop             fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                aa73bcc376865c23e61dcebd467697b527901be8
baseline version:
 linux                0c418786cb3aa175823f0172d939679df9ab9a54

Last test of basis   149749  2020-04-23 09:09:13 Z    6 days
Testing same since   149878  2020-04-29 14:40:04 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Eric W. Biederman" <ebiederm@xmission.com>
  "Yan, Zheng" <zyan@redhat.com>
  Ahmad Fatoum <a.fatoum@pengutronix.de>
  Alan Stern <stern@rowland.harvard.edu>
  Alex Deucher <alexander.deucher@amd.com>
  Alexander Tsoy <alexander@tsoy.me>
  Alexandre Belloni <alexandre.belloni@bootlin.com>
  Alexey Skobkin <skobkin-ru@ya.ru>
  Amit Singh Tomar <amittomer25@gmail.com>
  Andrew Melnychenko <andrew@daynix.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andrzej Pietrasiewicz <andrzej.p@collabora.com>
  Arnd Bergmann <arnd@arndb.de>
  Aurelien Jarno <aurelien@aurel32.net>
  Badhri Jagan Sridharan <badhri@google.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Changming Liu <liu.changm@northeastern.edu>
  Chris Packham <chris.packham@alliedtelesis.co.nz>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Brauner <christian.brauner@ubuntu.com>
  Christoph Hellwig <hch@lst.de>
  Christophe Leroy <christophe.leroy@c-s.fr>
  Chuck Lever <chuck.lever@oracle.com>
  Cornelia Huck <cohuck@redhat.com>
  Dan Carpenter <dan.carpenter@oracle.com>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Borkmann <daniel@iogearbox.net>
  David Ahern <dsahern@gmail.com>
  David Howells <dhowells@redhat.com>
  David S. Miller <davem@davemloft.net>
  Dick Kennedy <dick.kennedy@broadcom.com>
  Dmitry Monakhov <dmonakhov@gmail.com>
  Don Brace <don.brace@microsemi.com>
  Doug Berger <opendmb@gmail.com>
  Eric Biggers <ebiggers@google.com>
  Eric Dumazet <edumazet@google.com>
  Eric W. Biederman <ebiederm@xmission.com>
  Evan Green <evgreen@chromium.org>
  Fabrice Gasnier <fabrice.gasnier@st.com>
  Felipe Balbi <balbi@kernel.org>
  Florian Fainelli <f.fainelli@gmail.com>
  František Kučera <franta-linux@frantovo.cz>
  Ganesh Goudar <ganeshgr@linux.ibm.com>
  Geert Uytterhoeven <geert+renesas@glider.be>
  George Wilson <gcwilson@linux.ibm.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Guenter Roeck <linux@roeck-us.net>
  Gyeongtaek Lee <gt82.lee@samsung.com>
  H. Peter Anvin (Intel) <hpa@zytor.com>
  Halil Pasic <pasic@linux.ibm.com>
  Hans de Goede <hdegoede@redhat.com>
  Hao Bui <hao.bui.yg@renesas.com>
  Heiner Kallweit <hkallweit1@gmail.com>
  Ian Abbott <abbotti@mev.co.uk>
  Ilan Peer <ilan.peer@intel.com>
  Ilya Dryomov <idryomov@gmail.com>
  Ingo Molnar <mingo@kernel.org>
  Isabel Zhang <isabel.zhang@amd.com>
  Jaegeuk Kim <jaegeuk@kernel.org>
  James Morse <james.morse@arm.com>
  James Smart <jsmart2021@gmail.com>
  Jan Kara <jack@suse.cz>
  Jann Horn <jannh@google.com>
  Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
  Javed Hasan <jhasan@marvell.com>
  Jens Axboe <axboe@kernel.dk>
  Jiri Olsa <jolsa@kernel.org>
  Jiri Slaby <jslaby@suse.cz>
  Johannes Berg <johannes.berg@intel.com>
  John Haxby <john.haxby@oracle.com>
  Jonas Karlsson <jonas.karlsson@actia.se>
  Jonathan Cameron <Jonathan.Cameron@huawei.com>
  Jonathan Cox <jonathan@jdcox.net>
  Kai Vehmanen <kai.vehmanen@linux.intel.com>
  Kai-Heng Feng <kai.heng.feng@canonical.com>
  Kailang Yang <kailang@realtek.com>
  Kalle Valo <kvalo@codeaurora.org>
  Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>
  KAZUMI HARADA <kazumi.harada.rh@renesas.com>
  Keith Busch <kbusch@kernel.org>
  Kevin Barnett <kevin.barnett@microsemi.com>
  Kishon Vijay Abraham I <kishon@ti.com>
  Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
  Lars Engebretsen <lars@engebretsen.ch>
  Lars-Peter Clausen <lars@metafoo.de>
  Lary Gibaud <yarl-baudig@mailoo.org>
  Linh Pham <phaml@us.ibm.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Longpeng <longpeng2@huawei.com>
  Luca Coelho <luciano.coelho@intel.com>
  Lucas Stach <l.stach@pengutronix.de>
  Luis Chamberlain <mcgrof@kernel.org>
  Luis Mendes <luis.p.mendes@gmail.com>
  Malcolm Priestley <tvboxspy@gmail.com>
  Manoj Malviya <manojmalviya@chelsio.com>
  Marc Zyngier <maz@kernel.org>
  Mark Brown <broonie@kernel.org>
  Martin K. Petersen <martin.petersen@oracle.com>
  Masahiro Yamada <masahiroy@kernel.org>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael S. Tsirkin <mst@redhat.com>
  Michal Simek <michal.simek@xilinx.com>
  Mika Westerberg <mika.westerberg@linux.intel.com>
  Miroslav Benes <mbenes@suse.cz>
  Mordechay Goodstein <mordechay.goodstein@intel.com>
  Moritz Fischer <mdf@kernel.org>
  Muchun Song <songmuchun@bytedance.com>
  Murthy Bhat <Murthy.Bhat@microsemi.com>
  Naoki Kiryu <naonaokiryu2@gmail.com>
  Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
  Nicholas Piggin <npiggin@gmail.com>
  Nick Bowler <nbowler@draconx.ca>
  Nicolas Dichtel <nicolas.dichtel@6wind.com>
  Nicolas Pitre <nico@fluxnic.net>
  Oleg Nesterov <oleg@redhat.com>
  Oliver Neukum <oneukum@suse.com>
  Olivier Moysan <olivier.moysan@st.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <paul@paul-moore.com>
  Paul Zimmerman <pauldzim@gmail.com>
  Paulo Alcantara (SUSE) <pc@cjr.nz>
  Paulo Alcantara <pc@cjr.nz>
  Peter Oberparleiter <oberpar@linux.ibm.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
  Pravin B Shelar <pshelar@ovn.org>
  Qiujun Huang <hqjagain@gmail.com>
  Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
  Randall Huang <huangrandall@google.com>
  Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
  Roland Hieber <rhi@pengutronix.de>
  Sabrina Dubroca <sd@queasysnail.net>
  Sagi Grimberg <sagi@grimberg.me>
  Sam Ravnborg <sam@ravnborg.org>
  Santosh Sivaraj <santosh@fossix.org>
  Sasha Levin <sashal@kernel.org>
  Saurav Kashyap <skashyap@marvell.com>
  Sean Christopherson <sean.j.christopherson@intel.com>
  Soheil Hassas Yeganeh <soheil@google.com>
  Sriharsha Allenki <sallenki@codeaurora.org>
  Steve French <stfrench@microsoft.com>
  Steven Rostedt (VMware) <rostedt@goodmis.org>
  Sudip Mukherjee <sudipm.mukherjee@gmail.com>
  Sumit Garg <sumit.garg@linaro.org>
  Taehee Yoo <ap420073@gmail.com>
  Takashi Iwai <tiwai@suse.de>
  Tero Kristo <t-kristo@ti.com>
  Theodore Ts'o <tytso@mit.edu>
  Thierry Reding <thierry.reding@gmail.com>
  Thinh Nguyen <Thinh.Nguyen@synopsys.com>
  Thinh Nguyen <thinhn@synopsys.com>
  Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
  Tonghao Zhang <xiangxia.m.yue@gmail.com>
  Udipto Goswami <ugoswami@codeaurora.org>
  Uros Bizjak <ubizjak@gmail.com>
  Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
  Vasily Averin <vvs@virtuozzo.com>
  Vasily Gorbik <gor@linux.ibm.com>
  Vishal Kulkarni <vishal@chelsio.com>
  Vishal Kulkarni <vishal@chelsio.com>"
  Waiman Long <longman@redhat.com>
  Will Deacon <will@kernel.org>
  William Dauchy <w.dauchy@criteo.com>
  Wim Van Sebroeck <wim@linux-watchdog.org>
  Wu Bo <wubo40@huawei.com>
  Wu Hao <hao.wu@intel.com>
  Xin Tan <tanxin.ctf@gmail.com>
  Xiyu Yang <xiyuyang19@fudan.edu.cn>
  Xu Yilun <yilun.xu@intel.com>
  Yan, Zheng <zyan@redhat.com>
  Yongqiang Sun <yongqiang.sun@amd.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   0c418786cb3a..aa73bcc37686  aa73bcc376865c23e61dcebd467697b527901be8 -> tested/linux-5.4


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 05:39:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 05:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU1uL-0003nc-Gf; Thu, 30 Apr 2020 05:38:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jU1uJ-0003nX-He
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 05:38:47 +0000
X-Inumbo-ID: dbfe6f7c-8aa4-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id dbfe6f7c-8aa4-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 05:38:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 6276BAF17;
 Thu, 30 Apr 2020 05:38:44 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v3] tools/xenstore: don't store domU's mfn of ring page in
 xenstored
Date: Thu, 30 Apr 2020 07:38:42 +0200
Message-Id: <20200430053842.4376-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
of the domain's xenstore ring page and the event channel of the
domain for communicating with Xenstore.

The gfn is not really needed. It is stored in the per-domain struct
in xenstored and in case of another XS_INTRODUCE for the domain it
is tested to match the original value. If it doesn't match the
command is aborted via EINVAL, otherwise the event channel to the
domain is recreated.

As XS_INTRODUCE is limited to dom0 and there is no real downside of
recreating the event channel just omit the test for the gfn to
match and don't return EINVAL for multiple XS_INTRODUCE calls.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2:
- remove mfn from struct domain (Julien Grall)
- replace mfn by gfn in comments (Julien Grall)

V3:
- allow multiple XS_INTRODUCE calls (Igor Druzhinin)
---
 tools/xenstore/xenstored_domain.c | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 5858185211..06359503f0 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -55,10 +55,6 @@ struct domain
 	   repeated domain introductions. */
 	evtchn_port_t remote_port;
 
-	/* The mfn associated with the event channel, used only to validate
-	   repeated domain introductions. */
-	unsigned long mfn;
-
 	/* Domain path in store. */
 	char *path;
 
@@ -363,13 +359,12 @@ static void domain_conn_reset(struct domain *domain)
 	domain->interface->rsp_cons = domain->interface->rsp_prod = 0;
 }
 
-/* domid, mfn, evtchn, path */
+/* domid, gfn, evtchn, path */
 int do_introduce(struct connection *conn, struct buffered_data *in)
 {
 	struct domain *domain;
 	char *vec[3];
 	unsigned int domid;
-	unsigned long mfn;
 	evtchn_port_t port;
 	int rc;
 	struct xenstore_domain_interface *interface;
@@ -381,7 +376,7 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
 		return EACCES;
 
 	domid = atoi(vec[0]);
-	mfn = atol(vec[1]);
+	/* Ignore the gfn, we don't need it. */
 	port = atoi(vec[2]);
 
 	/* Sanity check args. */
@@ -402,21 +397,19 @@ int do_introduce(struct connection *conn, struct buffered_data *in)
 			return rc;
 		}
 		domain->interface = interface;
-		domain->mfn = mfn;
 
 		/* Now domain belongs to its connection. */
 		talloc_steal(domain->conn, domain);
 
 		fire_watches(NULL, in, "@introduceDomain", false);
-	} else if ((domain->mfn == mfn) && (domain->conn != conn)) {
+	} else {
 		/* Use XS_INTRODUCE for recreating the xenbus event-channel. */
 		if (domain->port)
 			xenevtchn_unbind(xce_handle, domain->port);
 		rc = xenevtchn_bind_interdomain(xce_handle, domid, port);
 		domain->port = (rc == -1) ? 0 : rc;
 		domain->remote_port = port;
-	} else
-		return EINVAL;
+	}
 
 	domain_conn_reset(domain);
 
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 06:29:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 06:29:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU2hW-0000Jj-Ij; Thu, 30 Apr 2020 06:29:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU2hV-0000Je-9p
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 06:29:37 +0000
X-Inumbo-ID: f5894f5a-8aab-11ea-9a02-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id f5894f5a-8aab-11ea-9a02-12813bfff9fa;
 Thu, 30 Apr 2020 06:29:35 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 43A4EAB76;
 Thu, 30 Apr 2020 06:29:33 +0000 (UTC)
Subject: Re: [PATCH 05/12] xen: introduce reserve_heap_pages
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-5-sstabellini@kernel.org>
 <3129ab49-5898-9d2e-8fbb-d1fcaf6cdec7@suse.com>
 <alpine.DEB.2.21.2004291510270.28941@sstabellini-ThinkPad-T480s>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <8a517cbc-9ff7-5b9e-f2c9-08c411703d5d@suse.com>
Date: Thu, 30 Apr 2020 08:29:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004291510270.28941@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.2020 00:46, Stefano Stabellini wrote:
> On Fri, 17 Apr 2020, Jan Beulich wrote:
>> On 15.04.2020 03:02, Stefano Stabellini wrote:
>>> Introduce a function named reserve_heap_pages (similar to
>>> alloc_heap_pages) that allocates a requested memory range. Call
>>> __alloc_heap_pages for the implementation.
>>>
>>> Change __alloc_heap_pages so that the original page doesn't get
>>> modified, giving back unneeded memory top to bottom rather than bottom
>>> to top.
>>
>> While it may be less of a problem within a zone, doing so is
>> against our general "return high pages first" policy.
> 
> Is this something you'd be OK with anyway?

As a last resort, maybe. But it really depends on why it needs to be
this way.

> If not, do you have a suggestion on how to do it better? I couldn't find
> a nice way to do it without code duplication, or a big nasty 'if' in the
> middle of the function.

I'd first need to understand the problem to solve.

>>> +    pg = maddr_to_page(start);
>>> +    node = phys_to_nid(start);
>>> +    zone = page_to_zone(pg);
>>> +    page_list_del(pg, &heap(node, zone, order));
>>> +
>>> +    __alloc_heap_pages(pg, order, memflags, d);
>>
>> I agree with Julien in not seeing how this can be safe / correct.
> 
> I haven't seen any issues so far in my testing -- I imagine it is
> because there aren't many memory allocations after setup_mm() and before
> create_domUs()  (which on ARM is called just before
> domain_unpause_by_systemcontroller at the end of start_xen.)
> 
> 
> I gave a quick look at David's series. Is the idea that I should add a
> patch to do the following:
> 
> - avoiding adding these ranges to xenheap in setup_mm, wait for later
>   (a bit like reserved_mem regions)
> 
> - in construct_domU, add the range to xenheap and reserve it with reserve_heap_pages
> 
> Is that right?

This may be one way, but it may also be not the only possible one.
The main thing to arrange for is that there is either a guarantee
for these ranges to be free (which I think you want to check in
any event, rather than risking to give out something that's already
in use elsewhere), or that you skip ranges which are already in use
(potentially altering [decreasing?] what the specific domain gets
allocated).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 06:46:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 06:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU2xE-0002Ec-Tg; Thu, 30 Apr 2020 06:45:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU2xD-0002EX-IL
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 06:45:51 +0000
X-Inumbo-ID: 3a6d4408-8aae-11ea-9a07-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3a6d4408-8aae-11ea-9a07-12813bfff9fa;
 Thu, 30 Apr 2020 06:45:50 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2F909AB76;
 Thu, 30 Apr 2020 06:45:48 +0000 (UTC)
Subject: Re: [PATCH 2/2] xen: credit2: limit the max number of CPUs in a
 runqueue
To: Dario Faggioli <dfaggioli@suse.com>
References: <158818022727.24327.14309662489731832234.stgit@Palanthas>
 <158818179558.24327.11334680191217289878.stgit@Palanthas>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3db33b8a-ba97-f302-a325-e989ff0e7084@suse.com>
Date: Thu, 30 Apr 2020 08:45:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <158818179558.24327.11334680191217289878.stgit@Palanthas>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
 George Dunlap <george.dunlap@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 19:36, Dario Faggioli wrote:
> @@ -852,14 +862,61 @@ cpu_runqueue_match(const struct csched2_runqueue_data *rqd, unsigned int cpu)
>             (opt_runqueue == OPT_RUNQUEUE_NODE && same_node(peer_cpu, cpu));
>  }
>  
> +/* Additional checks, to avoid separating siblings in different runqueues. */
> +static bool
> +cpu_runqueue_smt_match(const struct csched2_runqueue_data *rqd, unsigned int cpu)
> +{
> +    unsigned int nr_sibl = cpumask_weight(per_cpu(cpu_sibling_mask, cpu));
> +    unsigned int rcpu, nr_smts = 0;
> +
> +    /*
> +     * If we put the CPU in this runqueue, we must be sure that there will
> +     * be enough room for accepting its hyperthread sibling(s) here as well.
> +     */
> +    cpumask_clear(cpumask_scratch_cpu(cpu));
> +    for_each_cpu ( rcpu, &rqd->active )
> +    {
> +        ASSERT(rcpu != cpu);
> +        if ( !cpumask_test_cpu(rcpu, cpumask_scratch_cpu(cpu)) )
> +        {
> +            /*
> +             * For each CPU already in the runqueue, account for it and for
> +             * its sibling(s), independently from whether such sibling(s) are
> +             * in the runqueue already or not.
> +             *
> +             * Of course, if there are sibling CPUs in the runqueue already,
> +             * only count them once.
> +             */
> +            cpumask_or(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
> +                       per_cpu(cpu_sibling_mask, rcpu));
> +            nr_smts += nr_sibl;

This being common code, is it appropriate to assume all CPUs having
the same number of siblings? Even beyond that, iirc the sibling mask
represents the online or parked siblings, but not offline ones. For
the purpose here, don't you rather care about the full set?

What about HT vs AMD Fam15's CUs? Do you want both to be treated
the same here?

Also could you outline the intentions with this logic in the
description, to be able to match the goal with what gets done?

> +        }
> +    }
> +    /*
> +     * We know that neither the CPU, nor any of its sibling are here,
> +     * or we wouldn't even have entered the function.
> +     */
> +    ASSERT(!cpumask_intersects(cpumask_scratch_cpu(cpu),
> +                               per_cpu(cpu_sibling_mask, cpu)));
> +
> +    /* Try adding CPU and its sibling(s) to the count and check... */
> +    nr_smts += nr_sibl;
> +
> +    if ( nr_smts <= opt_max_cpus_runqueue )
> +        return true;
> +
> +    return false;

Fold these into

    return nr_smts <= opt_max_cpus_runqueue;

?

> @@ -873,11 +930,44 @@ cpu_add_to_runqueue(struct csched2_private *prv, unsigned int cpu)
>          if ( !rqi_unused && rqd->id > rqi )
>              rqi_unused = true;
>  
> -        if ( cpu_runqueue_match(rqd, cpu) )
> +        /*
> +         * Check whether the CPU should (according to the topology) and also
> +         * can (if we there aren't too many already) go in this runqueue.

Nit: Stray "we"?

> +         */
> +        if ( rqd->refcnt < opt_max_cpus_runqueue &&
> +             cpu_runqueue_match(rqd, cpu) )
>          {
> -            rqd_valid = true;
> -            break;
> +            cpumask_t *siblings = per_cpu(cpu_sibling_mask, cpu);
> +
> +            dprintk(XENLOG_DEBUG, "CPU %d matches runq %d, cpus={%*pbl} (max %d)\n",
> +                    cpu, rqd->id, CPUMASK_PR(&rqd->active),
> +                    opt_max_cpus_runqueue);
> +
> +            /*
> +             * If we're using core (or socket!) scheduling, or we don't have
> +             * hyperthreading, no need to do any further checking.
> +             *
> +             * If no (to both), but our sibling is already in this runqueue,
> +             * then it's also ok for the CPU to stay in this runqueue..

Nit: Stray full 2nd stop?

> +             * Otherwise, do some more checks, to better account for SMT.
> +             */
> +            if ( opt_sched_granularity != SCHED_GRAN_cpu ||
> +                 cpumask_weight(siblings) <= 1 ||
> +                 cpumask_intersects(&rqd->active, siblings) )
> +            {
> +                dprintk(XENLOG_DEBUG, "runq %d selected\n", rqd->id);
> +                rqd_valid = rqd;
> +                break;
> +            }
> +            else if ( cpu_runqueue_smt_match(rqd, cpu) )
> +            {
> +                dprintk(XENLOG_DEBUG, "considering runq %d...\n", rqd->id);
> +                rqd_valid = rqd;
> +            }
>          }
> +	else

Hard tab slipped in.

> @@ -900,6 +990,12 @@ cpu_add_to_runqueue(struct csched2_private *prv, unsigned int cpu)
>          rqd->pick_bias = cpu;
>          rqd->id = rqi;
>      }
> +    else
> +        rqd = rqd_valid;
> +
> +    printk(XENLOG_INFO "CPU %d (sibling={%*pbl}) will go to runqueue %d with {%*pbl}\n",
> +           cpu, CPUMASK_PR(per_cpu(cpu_sibling_mask, cpu)), rqd->id,
> +           CPUMASK_PR(&rqd->active));

Iirc there's one per-CPU printk() already. On large systems this isn't
very nice, so I'd like to ask that their total number at least not get
further grown. Ideally there would be a less verbose summary after all
CPUs have been brought up at boot, with per-CPU info be logged only
during CPU hot online.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 06:50:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 06:50:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU31P-00031A-F6; Thu, 30 Apr 2020 06:50:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU31O-000314-2t
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 06:50:10 +0000
X-Inumbo-ID: d4ec1946-8aae-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d4ec1946-8aae-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 06:50:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B1840AC24;
 Thu, 30 Apr 2020 06:50:07 +0000 (UTC)
Subject: Re: [PATCH] x86/msr: Fix XEN_MSR_PAT to build with older binutils
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20200429213901.16105-1-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <f15270a6-33d0-5e6e-cefa-01961b965f89@suse.com>
Date: Thu, 30 Apr 2020 08:50:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200429213901.16105-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 23:39, Andrew Cooper wrote:
> Older binutils complains with:
>   trampoline.S:95: Error: junk `ul&0xffffffff' after expression
> 
> Use an assembly-safe constant.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 07:01:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 07:01:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU3Cg-0004PS-J8; Thu, 30 Apr 2020 07:01:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU3Cf-0004OQ-9V
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 07:01:49 +0000
X-Inumbo-ID: 75143c7c-8ab0-11ea-9a07-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 75143c7c-8ab0-11ea-9a07-12813bfff9fa;
 Thu, 30 Apr 2020 07:01:47 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A60E8AC44;
 Thu, 30 Apr 2020 07:01:45 +0000 (UTC)
Subject: Re: [RFC] UEFI Secure Boot on Xen Hosts
To: Bobby Eshleman <bobbyeshleman@gmail.com>
References: <20200429225108.GA54201@bobbye-pc>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <ebdd7b4a-767b-1b72-a344-78b190f42ceb@suse.com>
Date: Thu, 30 Apr 2020 09:01:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200429225108.GA54201@bobbye-pc>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: michal.zygowski@3mdeb.com, daniel.kiper@oracle.com,
 krystian.hebel@3mdeb.com, xen-devel@lists.xenproject.org,
 olivier.lambert@vates.fr, piotr.krol@3mdeb.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.2020 00:51, Bobby Eshleman wrote:
> Hey all,
> 
> We're looking to develop UEFI Secure Boot support for grub-loaded Xen and
> ultimately for XCP-ng (I'm on the XCP-ng team at Vates).
> 
> In addition to carrying the chain-of-trust through the entire boot sequence
> into dom0, we would also like to build something akin to Linux's Lockdown for
> dom0 and its privileged interfaces.
> 
> It appears that there are various options and we'd like to discuss them with
> the community.
> 
> # Option #1: PE/COFF and Shim
> 
> Shim installs a verification protocol available to subsequent programs via EFI
> boot services.  The protocol is called SHIM_LOCK and it is currently supported
> by xen.efi.
> 
> Shim requires the payload under verification to be a PE/COFF executable.  In
> order to support both shim and maintain the multiboot2 protocol, Daniel Kiper's
> patchset [1]  (among other things) incorporates the PE/COFF header
> into xen.gz and adds dom0 verification via SHIM_LOCK in
> efi_multiboot2().
> 
> There appears that some work will be needed on top of this patchset, but not
> much as it seems most of the foot work has been done.
> 
> AFAIK, the changes needed in GRUB for this approach are already upstream (the
> shim_lock module is upstream), and shim would go untouched.
> 
> # Option #2: Extended Multiboot2 and Shim
> 
> Another approach that could be taken is to embed Xen's signature into a
> new multiboot2 header and then modify shim to support it.  This would
> arguably be more readable than embedding the PE/COFF header, would add
> value to shim, and would fit nicely with the mb2 header code that
> already exists in Xen.  The downside being that it would require a shim
> fork.  Grub2 would be unchanged.
> 
> I'm not familliar with Microsoft's signing process.  I do know they
> support template submissions based on shim, and I'm not sure if such a
> big change would impact their approval process.
> 
> # Option #3: Lean on Grub2's LoadFile2() Verification
> 
> Grub2 will provide a LoadFile2() method to subsequent programs that supports
> signature verification of arbitrary files.  Linux is moving in the
> direction of using LoadFile2() for loading the initrd [2], and Grub2 will
> support verifying the signatures of files loaded via LoadFile2().  This is set
> for release in GRUB 2.06 sometime in the latter half of 2020.
> 
> In Xen, this approach could be used for loading dom0 as well, offering a very
> simple verified load interface.
> 
> Currently the initrd argument passed from Linux to LoadFile2() is a vendor
> media device path GUID [3].
> 
> Changes to Xen:
> - Xen would need to pass these device paths to Grub
> - Xen would be changed to load dom0 with the LoadFile2() interface via boot services
> 
> Changes to Grub:
> - Xen dom0 kernel/initrd device paths would need to be introduced to Grub
> 
> Potential Issues:
> - How will Xen handle more boot modules than just a dom0 and dom0
>   initrd?
> - Would each boot module need a unique vendor guid?
> - Would this interfere with the DomB proposal?  I suspect not because
>   the DomB proposal suggests launching DomUs from an already booted
>   DomB, at which point other means could be used.
> 
> We'd just like to get the conversation going on this topic before we
> dive too far into implementing something.  Are any of these approaches a
> hard no for upstreaming?  Do any stand out as best candidates?  Any
> feedback / questions / criticisms would be greatly appreciated.

A shim fork doesn't look desirable, which would rule out #2 unless there
is an option there to avoid the fork.

If the potential issues listed for #3 can be suitably addressed, I can't
currently see a reason to prefer either of the two remaining options; I
vaguely recall though that Daniel's change for #1 didn't look overly
appealing, but perhaps this can be taken care of.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 07:19:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 07:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU3U2-0005bi-72; Thu, 30 Apr 2020 07:19:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jU3U1-0005bd-0F
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 07:19:45 +0000
X-Inumbo-ID: f6d712f0-8ab2-11ea-b07b-bc764e2007e4
Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id f6d712f0-8ab2-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 07:19:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588231183;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=1ZVQP21/gRpjdQaiA5iEEwLdE4gKxXG18sO+uoyk77w=;
 b=YyXKqWpmaEqbqG0mQbsp3TYTvS8Kap4mcBdi9+EIrFBzWh84U3znmfH9o6xtGBVz/Wm2qv
 jc3YLrrjM3DiMqntWdQjbQCKBFBUqk7LjpNpcnOP+6j+FQMe360QpmANXaS7cNUF/PUQ7C
 Cz+d01l2y2QD2eUgGH8kRwf1hIl7KUU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-331-rM1ylhAbMHiuxvT_teIprA-1; Thu, 30 Apr 2020 03:19:37 -0400
X-MC-Unique: rM1ylhAbMHiuxvT_teIprA-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
 [10.5.11.12])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 16BAAEC1A7;
 Thu, 30 Apr 2020 07:19:35 +0000 (UTC)
Received: from [10.36.113.172] (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id B9F7360BF4;
 Thu, 30 Apr 2020 07:19:27 +0000 (UTC)
Subject: Re: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
To: linux-kernel@vger.kernel.org
References: <20200429160803.109056-1-david@redhat.com>
 <20200429160803.109056-3-david@redhat.com>
From: David Hildenbrand <david@redhat.com>
Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata=
 mQINBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABtCREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT6JAlgEEwEIAEICGwMFCQlmAYAGCwkIBwMCBhUI
 AgkKCwQWAgMBAh4BAheAFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl3pImkCGQEACgkQTd4Q
 9wD/g1o+VA//SFvIHUAvul05u6wKv/pIR6aICPdpF9EIgEU448g+7FfDgQwcEny1pbEzAmiw
 zAXIQ9H0NZh96lcq+yDLtONnXk/bEYWHHUA014A1wqcYNRY8RvY1+eVHb0uu0KYQoXkzvu+s
 Dncuguk470XPnscL27hs8PgOP6QjG4jt75K2LfZ0eAqTOUCZTJxA8A7E9+XTYuU0hs7QVrWJ
 jQdFxQbRMrYz7uP8KmTK9/Cnvqehgl4EzyRaZppshruKMeyheBgvgJd5On1wWq4ZUV5PFM4x
 II3QbD3EJfWbaJMR55jI9dMFa+vK7MFz3rhWOkEx/QR959lfdRSTXdxs8V3zDvChcmRVGN8U
 Vo93d1YNtWnA9w6oCW1dnDZ4kgQZZSBIjp6iHcA08apzh7DPi08jL7M9UQByeYGr8KuR4i6e
 RZI6xhlZerUScVzn35ONwOC91VdYiQgjemiVLq1WDDZ3B7DIzUZ4RQTOaIWdtXBWb8zWakt/
 ztGhsx0e39Gvt3391O1PgcA7ilhvqrBPemJrlb9xSPPRbaNAW39P8ws/UJnzSJqnHMVxbRZC
 Am4add/SM+OCP0w3xYss1jy9T+XdZa0lhUvJfLy7tNcjVG/sxkBXOaSC24MFPuwnoC9WvCVQ
 ZBxouph3kqc4Dt5X1EeXVLeba+466P1fe1rC8MbcwDkoUo65Ag0EVcufkQEQAOfX3n0g0fZz
 Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
 T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
 CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
 NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
 lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
 AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
 N7eop7uh+6bezi+rugUI+w6DABEBAAGJAiUEGAECAA8FAlXLn5ECGwwFCQlmAYAACgkQTd4Q
 9wD/g1qA6w/+M+ggFv+JdVsz5+ZIc6MSyGUozASX+bmIuPeIecc9UsFRatc91LuJCKMkD9Uv
 GOcWSeFpLrSGRQ1Z7EMzFVU//qVs6uzhsNk0RYMyS0B6oloW3FpyQ+zOVylFWQCzoyyf227y
 GW8HnXunJSC+4PtlL2AY4yZjAVAPLK2l6mhgClVXTQ/S7cBoTQKP+jvVJOoYkpnFxWE9pn4t
 H5QIFk7Ip8TKr5k3fXVWk4lnUi9MTF/5L/mWqdyIO1s7cjharQCstfWCzWrVeVctpVoDfJWp
 4LwTuQ5yEM2KcPeElLg5fR7WB2zH97oI6/Ko2DlovmfQqXh9xWozQt0iGy5tWzh6I0JrlcxJ
 ileZWLccC4XKD1037Hy2FLAjzfoWgwBLA6ULu0exOOdIa58H4PsXtkFPrUF980EEibUp0zFz
 GotRVekFAceUaRvAj7dh76cToeZkfsjAvBVb4COXuhgX6N4pofgNkW2AtgYu1nUsPAo+NftU
 CxrhjHtLn4QEBpkbErnXQyMjHpIatlYGutVMS91XTQXYydCh5crMPs7hYVsvnmGHIaB9ZMfB
 njnuI31KBiLUks+paRkHQlFcgS2N3gkRBzH7xSZ+t7Re3jvXdXEzKBbQ+dC3lpJB0wPnyMcX
 FOTT3aZT7IgePkt5iC/BKBk3hqKteTnJFeVIT7EC+a6YUFg=
Organization: Red Hat GmbH
Message-ID: <a7305cd8-8b2f-1d8f-7654-ecf777c46df6@redhat.com>
Date: Thu, 30 Apr 2020 09:19:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200429160803.109056-3-david@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, linux-acpi@vger.kernel.org,
 Baoquan He <bhe@redhat.com>, linux-nvdimm@lists.01.org,
 linux-s390@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Dave Hansen <dave.hansen@linux.intel.com>,
 virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
 Wei Yang <richard.weiyang@gmail.com>, Eric Biederman <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org, Dan Williams <dan.j.williams@intel.com>,
 Pavel Tatashin <pasha.tatashin@soleen.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.20 18:08, David Hildenbrand wrote:
> Some paravirtualized devices that add memory via add_memory() and
> friends (esp. virtio-mem) don't want to create entries in
> /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> memory to the boot memmap of the kexec kernel.
>=20
> In fact, such memory is never exposed via the firmware (e.g., e820), bu=
t
> only via the device, so exposing this memory via /sys/firmware/memmap/ =
is
> wrong:
>  "kexec needs the raw firmware-provided memory map to setup the
>   parameter segment of the kernel that should be booted with
>   kexec. Also, the raw memory map is useful for debugging. For
>   that reason, /sys/firmware/memmap is an interface that provides
>   the raw memory map to userspace." [1]
>=20
> We want to let user space know that memory which is always detected,
> added, and managed via a (device) driver - like memory managed by
> virtio-mem - is special. It cannot be used for placing kexec segments
> and the (device) driver is responsible for re-adding memory that
> (eventually shrunk/grown/defragmented) memory after a reboot/kexec. It
> should e.g., not be added to a fixed up firmware memmap. However, it sh=
ould
> be dumped by kdump.
>=20
> Also, such memory could behave differently than an ordinary DIMM - e.g.=
,
> memory managed by virtio-mem can have holes inside added memory resourc=
e,
> which should not be touched, especially for writing.
>=20
> Let's expose that memory as "System RAM (driver managed)" e.g., via
> /pro/iomem.
>=20
> We don't have to worry about firmware_map_remove() on the removal path.
> If there is no entry, it will simply return with -EINVAL.
>=20
> [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware=
-memmap
>=20
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  include/linux/memory_hotplug.h |  8 ++++++++
>  mm/memory_hotplug.c            | 20 ++++++++++++++++----
>  2 files changed, 24 insertions(+), 4 deletions(-)
>=20
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotp=
lug.h
> index bf0e3edb8688..cc538584b39e 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -68,6 +68,14 @@ struct mhp_params {
>  	pgprot_t pgprot;
>  };
> =20
> +/* Flags used for add_memory() and friends. */
> +
> +/*
> + * Don't create entries in /sys/firmware/memmap/ and expose memory as
> + * "System RAM (driver managed)" in e.g., /proc/iomem
> + */
> +#define MHP_DRIVER_MANAGED		1
> +
>  /*
>   * Zone resizing functions
>   *
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index ebdf6541d074..cfa0721280aa 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -98,11 +98,11 @@ void mem_hotplug_done(void)
>  u64 max_mem_size =3D U64_MAX;
> =20
>  /* add this memory to iomem resource */
> -static struct resource *register_memory_resource(u64 start, u64 size)
> +static struct resource *register_memory_resource(u64 start, u64 size,
> +						 const char *resource_name)
>  {
>  	struct resource *res;
>  	unsigned long flags =3D  IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> -	char *resource_name =3D "System RAM";
> =20
>  	/*
>  	 * Make sure value parsed from 'mem=3D' only restricts memory adding
> @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct res=
ource *res,
>  	BUG_ON(ret);
> =20
>  	/* create new memmap entry */
> -	firmware_map_add_hotplug(start, start + size, "System RAM");
> +	if (!(flags & MHP_DRIVER_MANAGED))
> +		firmware_map_add_hotplug(start, start + size, "System RAM");
> =20
>  	/* device_online() will take the lock when calling online_pages() */
>  	mem_hotplug_done();
> @@ -1081,10 +1082,21 @@ int __ref add_memory_resource(int nid, struct r=
esource *res,
>  /* requires device_hotplug_lock, see add_memory_resource() */
>  int __ref __add_memory(int nid, u64 start, u64 size, unsigned long fla=
gs)
>  {
> +	const char *resource_name =3D "System RAM";
>  	struct resource *res;
>  	int ret;
> =20
> -	res =3D register_memory_resource(start, size);
> +	/*
> +	 * Indicate that memory managed by a driver is special. It's always
> +	 * detected and added via a driver, should not be given to the kexec
> +	 * kernel for booting when manually crafting the firmware memmap, and
> +	 * no kexec segments should be placed on it. However, kdump should
> +	 * dump this memory.
> +	 */
> +	if (flags & MHP_DRIVER_MANAGED)
> +		resource_name =3D "System RAM (driver managed)";
> +
> +	res =3D register_memory_resource(start, size, resource_name);
>  	if (IS_ERR(res))
>  		return PTR_ERR(res);
> =20
>=20

BTW, I was wondering if this is actually also something that
drivers/dax/kmem.c wants to use for adding memory.

Just because we decided to use some DAX memory in the current kernel as
system ram, doesn't mean we should make that decision for the kexec
kernel (e.g., using it as initial memory, placing kexec binaries onto
it, etc.). This is also not what we would observe during a real reboot.

I can see that the "System RAM" resource will show up as child resource
under the device e.g., in /proc/iomem.

However, entries in /sys/firmware/memmap/ are created as "System RAM".

--=20
Thanks,

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 07:21:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 07:21:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU3VH-0006KW-Kn; Thu, 30 Apr 2020 07:21:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU3VG-0006Jz-1v
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 07:21:02 +0000
X-Inumbo-ID: 23b0e469-8ab3-11ea-9a09-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 23b0e469-8ab3-11ea-9a09-12813bfff9fa;
 Thu, 30 Apr 2020 07:21:00 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 5315EADF8;
 Thu, 30 Apr 2020 07:20:58 +0000 (UTC)
Subject: Re: [PATCH] x86/hap: be more selective with assisted TLB flush
To: Roger Pau Monne <roger.pau@citrix.com>
References: <20200429173601.77605-1-roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <4257a323-d37f-4af0-bdc6-a3f65c19438a@suse.com>
Date: Thu, 30 Apr 2020 09:20:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200429173601.77605-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.2020 19:36, Roger Pau Monne wrote:
> When doing an assisted flush on HAP the purpose of the
> on_selected_cpus is just to trigger a vmexit on remote CPUs that are
> in guest context, and hence just using is_vcpu_dirty_cpu is too lax,
> also check that the vCPU is running.

Am I right to understand that the change is relevant only to
cover the period of time between ->is_running becoming false
and ->dirty_cpu becoming VCPU_CPU_CLEAN? I.e. ...

> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -719,7 +719,7 @@ static bool flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
>          hvm_asid_flush_vcpu(v);
>  
>          cpu = read_atomic(&v->dirty_cpu);
> -        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) )
> +        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v->is_running )

... the previous logic would have suitably covered the switch-to
path, but doesn't properly cover the switch-from one, due to our
lazy context switch approach? If so, I agree with the change:
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It might be worth mentioning this detail in the description then,
though.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 07:35:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 07:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU3j3-0007St-UQ; Thu, 30 Apr 2020 07:35:17 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jU3j2-0007Sn-Ew
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 07:35:16 +0000
X-Inumbo-ID: 21e265ec-8ab5-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 21e265ec-8ab5-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 07:35:15 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A6492ADF8;
 Thu, 30 Apr 2020 07:35:13 +0000 (UTC)
Subject: Re: [PATCH 2/2] xen: credit2: limit the max number of CPUs in a
 runqueue
To: Dario Faggioli <dfaggioli@suse.com>, xen-devel@lists.xenproject.org
References: <158818022727.24327.14309662489731832234.stgit@Palanthas>
 <158818179558.24327.11334680191217289878.stgit@Palanthas>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <b368ccef-d3b1-1338-6325-8f81a963876d@suse.com>
Date: Thu, 30 Apr 2020 09:35:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <158818179558.24327.11334680191217289878.stgit@Palanthas>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.20 19:36, Dario Faggioli wrote:
> In Credit2 CPUs (can) share runqueues, depending on the topology. For
> instance, with per-socket runqueues (the default) all the CPUs that are
> part of the same socket share a runqueue.
> 
> On platform with a huge number of CPUs per socket, that could be a
> problem. An example is AMD EPYC2 servers, where we can have up to 128
> CPUs in a socket.
> 
> It is of course possible to define other, still topology-based, runqueue
> arrangements (e.g., per-LLC, per-DIE, etc). But that may still result in
> runqueues with too many CPUs on other/future platforms.
> 
> Therefore, let's set a limit to the max number of CPUs that can share a
> Credit2 runqueue. The actual value is configurable (at boot time), the
> default being 16. If, for instance,  there are more than 16 CPUs in a
> socket, they'll be split among two (or more) runqueues.

Did you think about balancing the runqueues regarding the number of
cpus? E.g. in case of max being 16 and having 20 cpus to put 10 in each
runqueue? I know this will need more logic as cpus are added one by one,
but the result would be much better IMO.

> 
> Note: with core scheduling enabled, this parameter sets the max number
> of *scheduling resources* that can share a runqueue. Therefore, with
> granularity set to core (and assumint 2 threads per core), we will have
> at most 16 cores per runqueue, which corresponds to 32 threads. But that
> is fine, considering how core scheduling works.
> 
> Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
> ---
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Juergen Gross <jgross@suse.com>
> ---
>   xen/common/sched/cpupool.c |    2 -
>   xen/common/sched/credit2.c |  104 ++++++++++++++++++++++++++++++++++++++++++--
>   xen/common/sched/private.h |    2 +
>   3 files changed, 103 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
> index d40345b585..0227457285 100644
> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -37,7 +37,7 @@ static cpumask_t cpupool_locked_cpus;
>   
>   static DEFINE_SPINLOCK(cpupool_lock);
>   
> -static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
> +enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;

Please don't use the global option value, but the per-cpupool one.

>   static unsigned int __read_mostly sched_granularity = 1;
>   
>   #ifdef CONFIG_HAS_SCHED_GRANULARITY
> diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
> index 697c9f917d..abe4d048c8 100644
> --- a/xen/common/sched/credit2.c
> +++ b/xen/common/sched/credit2.c
> @@ -471,6 +471,16 @@ static int __init parse_credit2_runqueue(const char *s)
>   }
>   custom_param("credit2_runqueue", parse_credit2_runqueue);
>   
> +/*
> + * How many CPUs will be put, at most, in the same runqueue.
> + * Runqueues are still arranged according to the host topology (and
> + * according to the value of the 'credit2_runqueue' parameter). But
> + * we also have a cap to the number of CPUs that share runqueues.
> + * As soon as we reach the limit, a new runqueue will be created.
> + */
> +static unsigned int __read_mostly opt_max_cpus_runqueue = 16;
> +integer_param("sched_credit2_max_cpus_runqueue", opt_max_cpus_runqueue);
> +
>   /*
>    * Per-runqueue data
>    */
> @@ -852,14 +862,61 @@ cpu_runqueue_match(const struct csched2_runqueue_data *rqd, unsigned int cpu)
>              (opt_runqueue == OPT_RUNQUEUE_NODE && same_node(peer_cpu, cpu));
>   }
>   
> +/* Additional checks, to avoid separating siblings in different runqueues. */
> +static bool
> +cpu_runqueue_smt_match(const struct csched2_runqueue_data *rqd, unsigned int cpu)
> +{
> +    unsigned int nr_sibl = cpumask_weight(per_cpu(cpu_sibling_mask, cpu));

Shouldn't you mask away siblings not in the cpupool?

> +    unsigned int rcpu, nr_smts = 0;
> +
> +    /*
> +     * If we put the CPU in this runqueue, we must be sure that there will
> +     * be enough room for accepting its hyperthread sibling(s) here as well.
> +     */
> +    cpumask_clear(cpumask_scratch_cpu(cpu));
> +    for_each_cpu ( rcpu, &rqd->active )
> +    {
> +        ASSERT(rcpu != cpu);
> +        if ( !cpumask_test_cpu(rcpu, cpumask_scratch_cpu(cpu)) )
> +        {
> +            /*
> +             * For each CPU already in the runqueue, account for it and for
> +             * its sibling(s), independently from whether such sibling(s) are
> +             * in the runqueue already or not.
> +             *
> +             * Of course, if there are sibling CPUs in the runqueue already,
> +             * only count them once.
> +             */
> +            cpumask_or(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
> +                       per_cpu(cpu_sibling_mask, rcpu));

Again, local cpupool only!


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 08:12:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 08:12:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU4Il-0002lr-90; Thu, 30 Apr 2020 08:12:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JErk=6O=intel.com=dan.j.williams@srs-us1.protection.inumbo.net>)
 id 1jU4Ik-0002lm-1e
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 08:12:10 +0000
X-Inumbo-ID: 47a3b5ba-8aba-11ea-b9cf-bc764e2007e4
Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 47a3b5ba-8aba-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 08:12:06 +0000 (UTC)
Received: by mail-ej1-x643.google.com with SMTP id re23so3944623ejb.4
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 01:12:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=intel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=aPyH7cBulXkr69UeTYsLw8J8jsMaQ8KU1AV45QxO0GM=;
 b=aRdqN+obvpVV2A+fgMLJy4RekybxRVDiG7lp8OF4bnZx2Ywvd3iCU/W+kNS4ZeZMFO
 s2KHcqmsaIITIji0juOY7H6rW7Fc6dWrzMOI3EIosswh9jq3YYccKaX2xhcXTvz1nd5V
 aBV+pihhUiUdyrUO5BWYQElkaX6/osTUoFcDUd3gIMpaDgbgaWZ7XiKQfHXqUsjsTevr
 xcbBoOAzO8ZeJrHgjs2FlN5xkisQM2/NaUdROIGlFFS2pMP9xFv8klIZrmKxkYMDnngC
 ZkScurbP2qpL3FH2QS0j799ldY6mMF4VeS1bCDMrE9KedwDuMF2flKOw3iR6FucwjAe8
 uO/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=aPyH7cBulXkr69UeTYsLw8J8jsMaQ8KU1AV45QxO0GM=;
 b=ncjp6DQ+JPF8wUR8slml2arMLU0gJdYNTBiIqNFVaPiE4N0K4crh86eefUO6j5Ulnd
 R12sfRNHYF3NkVZloDA4Zlnm4gs3DoRw7bcV139YSdMugazdc/qUHIGcphpoVhV5hZZy
 44EqcX+x0/GMzY8y5666VBnXmyySr7H+eY1r0WMu5FM1QUaIJ8sxch8LfMmQ+17L2qcI
 2P06/ep4QC0eoMofwf7/v5Lpfi+I3zWd4vkmLTc/yKih7desxQelJe738hW11nrxrT1d
 j9KAEQgw7LaFcQplmvJrhCOhiUwxHFX6bUcVIQLSENsTPhsYLysI2Ms92MlV8gyKEsEN
 4CKw==
X-Gm-Message-State: AGi0PuYBcroFS56uLt8kWquXdolVBH8ILht8MHTtaTglAspok4YFlLNJ
 W16SFySQvorsQeU+HI0nsII67h2sDYoB3eTwbPZWBcBGARY=
X-Google-Smtp-Source: APiQypKwCBG4S6M4oBR8TWLxl5ZHi3zkP+L9vXXaCbuE040rlsosdGPooBbFU8EQOuJGeo1PTMYPgjG4Ewt4MDGe5kI=
X-Received: by 2002:a17:906:7750:: with SMTP id
 o16mr1646531ejn.12.1588234325407; 
 Thu, 30 Apr 2020 01:12:05 -0700 (PDT)
MIME-Version: 1.0
References: <20200429160803.109056-1-david@redhat.com>
 <20200429160803.109056-3-david@redhat.com>
 <a7305cd8-8b2f-1d8f-7654-ecf777c46df6@redhat.com>
In-Reply-To: <a7305cd8-8b2f-1d8f-7654-ecf777c46df6@redhat.com>
From: Dan Williams <dan.j.williams@intel.com>
Date: Thu, 30 Apr 2020 01:11:54 -0700
Message-ID: <CAPcyv4i04+QLxiOyz04_eef2DFetEFKBUmi2A4xxw9abQD8hNQ@mail.gmail.com>
Subject: Re: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
To: David Hildenbrand <david@redhat.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Pavel Tatashin <pasha.tatashin@soleen.com>,
 Baoquan He <bhe@redhat.com>, Linux MM <linux-mm@kvack.org>,
 Wei Yang <richard.weiyang@gmail.com>, linux-s390 <linux-s390@vger.kernel.org>,
 linux-nvdimm <linux-nvdimm@lists.01.org>,
 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 Dave Hansen <dave.hansen@linux.intel.com>,
 virtualization@lists.linux-foundation.org,
 Linux ACPI <linux-acpi@vger.kernel.org>,
 "Michael S . Tsirkin" <mst@redhat.com>, Eric Biederman <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 29.04.20 18:08, David Hildenbrand wrote:
> > Some paravirtualized devices that add memory via add_memory() and
> > friends (esp. virtio-mem) don't want to create entries in
> > /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> > memory to the boot memmap of the kexec kernel.
> >
> > In fact, such memory is never exposed via the firmware (e.g., e820), but
> > only via the device, so exposing this memory via /sys/firmware/memmap/ is
> > wrong:
> >  "kexec needs the raw firmware-provided memory map to setup the
> >   parameter segment of the kernel that should be booted with
> >   kexec. Also, the raw memory map is useful for debugging. For
> >   that reason, /sys/firmware/memmap is an interface that provides
> >   the raw memory map to userspace." [1]
> >
> > We want to let user space know that memory which is always detected,
> > added, and managed via a (device) driver - like memory managed by
> > virtio-mem - is special. It cannot be used for placing kexec segments
> > and the (device) driver is responsible for re-adding memory that
> > (eventually shrunk/grown/defragmented) memory after a reboot/kexec. It
> > should e.g., not be added to a fixed up firmware memmap. However, it should
> > be dumped by kdump.
> >
> > Also, such memory could behave differently than an ordinary DIMM - e.g.,
> > memory managed by virtio-mem can have holes inside added memory resource,
> > which should not be touched, especially for writing.
> >
> > Let's expose that memory as "System RAM (driver managed)" e.g., via
> > /pro/iomem.
> >
> > We don't have to worry about firmware_map_remove() on the removal path.
> > If there is no entry, it will simply return with -EINVAL.
> >
> > [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
> >
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Michal Hocko <mhocko@suse.com>
> > Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> > Cc: Wei Yang <richard.weiyang@gmail.com>
> > Cc: Baoquan He <bhe@redhat.com>
> > Cc: Eric Biederman <ebiederm@xmission.com>
> > Signed-off-by: David Hildenbrand <david@redhat.com>
> > ---
> >  include/linux/memory_hotplug.h |  8 ++++++++
> >  mm/memory_hotplug.c            | 20 ++++++++++++++++----
> >  2 files changed, 24 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> > index bf0e3edb8688..cc538584b39e 100644
> > --- a/include/linux/memory_hotplug.h
> > +++ b/include/linux/memory_hotplug.h
> > @@ -68,6 +68,14 @@ struct mhp_params {
> >       pgprot_t pgprot;
> >  };
> >
> > +/* Flags used for add_memory() and friends. */
> > +
> > +/*
> > + * Don't create entries in /sys/firmware/memmap/ and expose memory as
> > + * "System RAM (driver managed)" in e.g., /proc/iomem
> > + */
> > +#define MHP_DRIVER_MANAGED           1
> > +
> >  /*
> >   * Zone resizing functions
> >   *
> > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > index ebdf6541d074..cfa0721280aa 100644
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -98,11 +98,11 @@ void mem_hotplug_done(void)
> >  u64 max_mem_size = U64_MAX;
> >
> >  /* add this memory to iomem resource */
> > -static struct resource *register_memory_resource(u64 start, u64 size)
> > +static struct resource *register_memory_resource(u64 start, u64 size,
> > +                                              const char *resource_name)
> >  {
> >       struct resource *res;
> >       unsigned long flags =  IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> > -     char *resource_name = "System RAM";
> >
> >       /*
> >        * Make sure value parsed from 'mem=' only restricts memory adding
> > @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res,
> >       BUG_ON(ret);
> >
> >       /* create new memmap entry */
> > -     firmware_map_add_hotplug(start, start + size, "System RAM");
> > +     if (!(flags & MHP_DRIVER_MANAGED))
> > +             firmware_map_add_hotplug(start, start + size, "System RAM");
> >
> >       /* device_online() will take the lock when calling online_pages() */
> >       mem_hotplug_done();
> > @@ -1081,10 +1082,21 @@ int __ref add_memory_resource(int nid, struct resource *res,
> >  /* requires device_hotplug_lock, see add_memory_resource() */
> >  int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags)
> >  {
> > +     const char *resource_name = "System RAM";
> >       struct resource *res;
> >       int ret;
> >
> > -     res = register_memory_resource(start, size);
> > +     /*
> > +      * Indicate that memory managed by a driver is special. It's always
> > +      * detected and added via a driver, should not be given to the kexec
> > +      * kernel for booting when manually crafting the firmware memmap, and
> > +      * no kexec segments should be placed on it. However, kdump should
> > +      * dump this memory.
> > +      */
> > +     if (flags & MHP_DRIVER_MANAGED)
> > +             resource_name = "System RAM (driver managed)";
> > +
> > +     res = register_memory_resource(start, size, resource_name);
> >       if (IS_ERR(res))
> >               return PTR_ERR(res);
> >
> >
>
> BTW, I was wondering if this is actually also something that
> drivers/dax/kmem.c wants to use for adding memory.
>
> Just because we decided to use some DAX memory in the current kernel as
> system ram, doesn't mean we should make that decision for the kexec
> kernel (e.g., using it as initial memory, placing kexec binaries onto
> it, etc.). This is also not what we would observe during a real reboot.

Agree.

> I can see that the "System RAM" resource will show up as child resource
> under the device e.g., in /proc/iomem.
>
> However, entries in /sys/firmware/memmap/ are created as "System RAM".

True. Do you think this rename should just be limited to what type
/sys/firmware/memmap/ emits? I have the concern, but no proof
currently, that there are /proc/iomem walkers that explicitly look for
"System RAM", but might be thrown off by "System RAM (driver
managed)". I was not aware of /sys/firmware/memmap until about 5
minutes ago.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 08:16:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 08:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU4NK-0002uR-SD; Thu, 30 Apr 2020 08:16:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=13pL=6O=gmail.com=ayushdosaj2313@srs-us1.protection.inumbo.net>)
 id 1jU4NJ-0002uM-4S
 for xen-devel@lists.xen.org; Thu, 30 Apr 2020 08:16:53 +0000
X-Inumbo-ID: f2042468-8aba-11ea-ae69-bc764e2007e4
Received: from mail-oi1-x234.google.com (unknown [2607:f8b0:4864:20::234])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f2042468-8aba-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 08:16:51 +0000 (UTC)
Received: by mail-oi1-x234.google.com with SMTP id a2so4481227oia.11
 for <xen-devel@lists.xen.org>; Thu, 30 Apr 2020 01:16:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=PSbV9BzdXx84MTWhjheATmsVhCcessEhtCWJHTsqRdY=;
 b=ouKJPbiXN4f5LLaS3L0cX5S+saFHmpCa7ITYX/xngYnkKNA53qTyPEnzuTp9mzxFSF
 ZgD/FpHyfdPXqsY/WmBOR4SQ1uUQ5TTrQTY9LEac9YGpQJnmyPtI5CGtWmrAlHi+gGsa
 Q6SsF8C3DX8+EBbHqVCYz7tSzt6FVeTy6JZVCZLJC+FLwO/jbUcABw1THZkRZS9u3/tG
 qgnvmbpYk2tU/zD7YiUfH9R4V4AWmHJABKjMViqkCbRF0616M9GLrshkk2GmagEhjmjU
 WEoG3w/SRlTj5nuUk96fm3l9N0Di7RXB0be7+HJWNZQUkLnkLat8KUh0PFYcaqqaDVrr
 yzbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=PSbV9BzdXx84MTWhjheATmsVhCcessEhtCWJHTsqRdY=;
 b=iOEgGLPdxLgPV9dyayHz64gtCqpggTr367Dz03pgCRsOQPEhtILVypwcdYNxOx0gy9
 rNIBGdopL5kxl2jPxZ0SFbaJdXfNFzpyUT8RTJ1aHGKlsL6yuPeSaSRpkZLoNdI5+t/q
 zVqfNEa1cLStkjDmuRzWAJwW+tEtfp0govZv4T+ZOceBB0Au8SoaDUSkT1Oj76/hTBRI
 1yH+BYS90vIJjiQG6RlcyBg8pecJSn5ms4Fdcu6u3QhbxM7n3eS6QuNBBIqjvz//9lJ8
 dUR58k8FZboM4AZDshhrrEpdloM/v6xR3pEZJnk4xhpszEW7kFiC6cXMn/EJkie7NeMl
 shEA==
X-Gm-Message-State: AGi0PuYY6pSAscahzvN0yaEF2Yy4DtyzYRi4buWZE0prJxxDXYNo9o+i
 p9IE/QSmYSmJGuP56aA3iP3ZVMzWeb8kyVktIQY=
X-Google-Smtp-Source: APiQypJLsWzZb5LbKoUVfTM9sohctVRyJ5FJmzybE4/l/fHoVNbNPe++FfEma1bfm7pFoqAuCEb+ut9hUuVqW06XofM=
X-Received: by 2002:aca:c78d:: with SMTP id x135mr894063oif.91.1588234611251; 
 Thu, 30 Apr 2020 01:16:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAOCxVi0s5X+=Hug2_M-AyXvYpiwqfkf7G2Y66kp44MQ-xgO+KA@mail.gmail.com>
 <e92bb8ab-3dd2-bb19-d524-d78279f9508a@citrix.com>
 <CAOCxVi1PWM_9t03f=_qn0PXkKB1gN4504h+ijMpwqGU9VpR48g@mail.gmail.com>
In-Reply-To: <CAOCxVi1PWM_9t03f=_qn0PXkKB1gN4504h+ijMpwqGU9VpR48g@mail.gmail.com>
From: Ayush Dosaj <ayushdosaj2313@gmail.com>
Date: Thu, 30 Apr 2020 13:46:39 +0530
Message-ID: <CAOCxVi0=iKzeJ0gfZ8XoMTXYrZaHbok=F30pw1rNdsUhkQcXjw@mail.gmail.com>
Subject: Re: Xen Compilation Error on Ubuntu 20.04
To: Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: multipart/alternative; boundary="000000000000d2df0805a47daf94"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

--000000000000d2df0805a47daf94
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Andrew, Xen Development team.

I compiled and installed Xen by appending -fcf-protection=3Dnone to CFLAGS =
on
Ubuntu 20.04 but it still crashes on startup.

On Wed, Apr 29, 2020 at 10:58 PM Ayush Dosaj <ayushdosaj2313@gmail.com>
wrote:

> Awesome, thanks!
>
> On Wed, Apr 29, 2020 at 10:55 PM Andrew Cooper <andrew.cooper3@citrix.com=
>
> wrote:
>
>> On 29/04/2020 18:17, Ayush Dosaj wrote:
>> > Hi Xen development team,
>> >
>> > I am Ayush. I compiled Xen Hypervisor from source on Ubuntu 20.04
>> > machine running on an intel-i9 CPU.
>> > I am getting compilation error due to the following two flags.
>> > Error: error: =E2=80=98-mindirect-branch=E2=80=99 and =E2=80=98-fcf-pr=
otection=E2=80=99 are not
>> compatible.
>> >
>> > Complete Error logs can be found at
>> https://paste.ubuntu.com/p/xvvyPnhW5c/
>> >
>> > And when I compiled Xen commenting the two flags in Rules.mk file, it
>> > compiles and installs properly but on boot-up i see a blank black scre=
en
>> > and i am stuck there.
>>
>> That is a GCC bug (these options are actually fine in combination).  It
>> got fixed earlier today in master, and backported for GCC 9.4
>>
>> You can work around it by appending -fcf-protection=3Dnone to CFLAGS
>>
>> I wouldn't try editing the logic around -mindirect-branch, as that is
>> related to retpoline safety for Spectre v2, and probably relies on the
>> build matching the code.
>>
>> ~Andrew
>>
>
>
> --
> Ayush Dosaj
> VIT Vellore
>
>

--=20
Ayush Dosaj

--000000000000d2df0805a47daf94
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small"><div class=3D"gmail_default">Hi Andrew,=
 Xen Development team.</div><div class=3D"gmail_default"><br></div><div cla=
ss=3D"gmail_default">I compiled and installed Xen by appending -fcf-protect=
ion=3Dnone to CFLAGS on Ubuntu 20.04 but it still crashes on startup.</div>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Wed, Apr 29, 2020 at 10:58 PM Ayush Dosaj &lt;<a href=3D"mailto:ay=
ushdosaj2313@gmail.com">ayushdosaj2313@gmail.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small">Awesome, thanks! <br></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 29, 2020 at 10:55 PM Andrew=
 Cooper &lt;<a href=3D"mailto:andrew.cooper3@citrix.com" target=3D"_blank">=
andrew.cooper3@citrix.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">On 29/04/2020 18:17, Ayush Dosaj wrote:<br>
&gt; Hi Xen development team,<br>
&gt; <br>
&gt; I am Ayush. I compiled Xen Hypervisor from source on Ubuntu 20.04<br>
&gt; machine running on an intel-i9 CPU.<br>
&gt; I am getting compilation error due to the following two flags.<br>
&gt; Error: error: =E2=80=98-mindirect-branch=E2=80=99 and =E2=80=98-fcf-pr=
otection=E2=80=99 are not compatible.<br>
&gt; <br>
&gt; Complete Error logs can be found at <a href=3D"https://paste.ubuntu.co=
m/p/xvvyPnhW5c/" rel=3D"noreferrer" target=3D"_blank">https://paste.ubuntu.=
com/p/xvvyPnhW5c/</a><br>
&gt; <br>
&gt; And when I compiled Xen commenting the two flags in Rules.mk file, it<=
br>
&gt; compiles and installs properly but on boot-up i see a blank black scre=
en<br>
&gt; and i am stuck there.<br>
<br>
That is a GCC bug (these options are actually fine in combination).=C2=A0 I=
t<br>
got fixed earlier today in master, and backported for GCC 9.4<br>
<br>
You can work around it by appending -fcf-protection=3Dnone to CFLAGS<br>
<br>
I wouldn&#39;t try editing the logic around -mindirect-branch, as that is<b=
r>
related to retpoline safety for Spectre v2, and probably relies on the<br>
build matching the code.<br>
<br>
~Andrew<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr"><div dir=
=3D"ltr"><div><div dir=3D"ltr"><div style=3D"text-align:left"><div style=3D=
"font-family:arial,helvetica,sans-serif">Ayush Dosaj</div><div style=3D"fon=
t-family:arial,helvetica,sans-serif">VIT Vellore</div><div><br></div></div>=
</div></div></div></div>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"=
text-align:left"><div style=3D"font-family:arial,helvetica,sans-serif">Ayus=
h Dosaj</div><div><br></div></div></div></div></div>

--000000000000d2df0805a47daf94--


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 08:20:41 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 08:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU4Qv-0003hK-CI; Thu, 30 Apr 2020 08:20:37 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jU4Qt-0003hF-Nm
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 08:20:36 +0000
X-Inumbo-ID: 76e3a9ce-8abb-11ea-ae69-bc764e2007e4
Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 76e3a9ce-8abb-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 08:20:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588234834;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=Oj3Gb/CDuSGT8ulKk/yMbVBXnCO14VNDywwKRzXNY0s=;
 b=CNsohpyauJPtjQ/VmSkfpGVmgmJU9KEMOK6sD+Xe+GCdvedOQwALCwy3HRRUPAyXJbSBR/
 1r3aGP4tkGvfblDR2fQBiXzEbCJ6fxVXxdkKM346i2r71bEEfd/EGUFxRwQpLpTBlefNaX
 +d5s6L3UUyHnZ1sigepsUvdzooTywIk=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-286-dm43KJQWPbG-0H4SvcZs2g-1; Thu, 30 Apr 2020 04:20:32 -0400
X-MC-Unique: dm43KJQWPbG-0H4SvcZs2g-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com
 [10.5.11.22])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 848AB1902EA2;
 Thu, 30 Apr 2020 08:20:29 +0000 (UTC)
Received: from [10.36.113.172] (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 44A771002395;
 Thu, 30 Apr 2020 08:20:22 +0000 (UTC)
Subject: Re: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
To: Dan Williams <dan.j.williams@intel.com>
References: <20200429160803.109056-1-david@redhat.com>
 <20200429160803.109056-3-david@redhat.com>
 <a7305cd8-8b2f-1d8f-7654-ecf777c46df6@redhat.com>
 <CAPcyv4i04+QLxiOyz04_eef2DFetEFKBUmi2A4xxw9abQD8hNQ@mail.gmail.com>
From: David Hildenbrand <david@redhat.com>
Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata=
 mQINBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABtCREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT6JAlgEEwEIAEICGwMFCQlmAYAGCwkIBwMCBhUI
 AgkKCwQWAgMBAh4BAheAFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl3pImkCGQEACgkQTd4Q
 9wD/g1o+VA//SFvIHUAvul05u6wKv/pIR6aICPdpF9EIgEU448g+7FfDgQwcEny1pbEzAmiw
 zAXIQ9H0NZh96lcq+yDLtONnXk/bEYWHHUA014A1wqcYNRY8RvY1+eVHb0uu0KYQoXkzvu+s
 Dncuguk470XPnscL27hs8PgOP6QjG4jt75K2LfZ0eAqTOUCZTJxA8A7E9+XTYuU0hs7QVrWJ
 jQdFxQbRMrYz7uP8KmTK9/Cnvqehgl4EzyRaZppshruKMeyheBgvgJd5On1wWq4ZUV5PFM4x
 II3QbD3EJfWbaJMR55jI9dMFa+vK7MFz3rhWOkEx/QR959lfdRSTXdxs8V3zDvChcmRVGN8U
 Vo93d1YNtWnA9w6oCW1dnDZ4kgQZZSBIjp6iHcA08apzh7DPi08jL7M9UQByeYGr8KuR4i6e
 RZI6xhlZerUScVzn35ONwOC91VdYiQgjemiVLq1WDDZ3B7DIzUZ4RQTOaIWdtXBWb8zWakt/
 ztGhsx0e39Gvt3391O1PgcA7ilhvqrBPemJrlb9xSPPRbaNAW39P8ws/UJnzSJqnHMVxbRZC
 Am4add/SM+OCP0w3xYss1jy9T+XdZa0lhUvJfLy7tNcjVG/sxkBXOaSC24MFPuwnoC9WvCVQ
 ZBxouph3kqc4Dt5X1EeXVLeba+466P1fe1rC8MbcwDkoUo65Ag0EVcufkQEQAOfX3n0g0fZz
 Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
 T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
 CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
 NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
 lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
 AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
 N7eop7uh+6bezi+rugUI+w6DABEBAAGJAiUEGAECAA8FAlXLn5ECGwwFCQlmAYAACgkQTd4Q
 9wD/g1qA6w/+M+ggFv+JdVsz5+ZIc6MSyGUozASX+bmIuPeIecc9UsFRatc91LuJCKMkD9Uv
 GOcWSeFpLrSGRQ1Z7EMzFVU//qVs6uzhsNk0RYMyS0B6oloW3FpyQ+zOVylFWQCzoyyf227y
 GW8HnXunJSC+4PtlL2AY4yZjAVAPLK2l6mhgClVXTQ/S7cBoTQKP+jvVJOoYkpnFxWE9pn4t
 H5QIFk7Ip8TKr5k3fXVWk4lnUi9MTF/5L/mWqdyIO1s7cjharQCstfWCzWrVeVctpVoDfJWp
 4LwTuQ5yEM2KcPeElLg5fR7WB2zH97oI6/Ko2DlovmfQqXh9xWozQt0iGy5tWzh6I0JrlcxJ
 ileZWLccC4XKD1037Hy2FLAjzfoWgwBLA6ULu0exOOdIa58H4PsXtkFPrUF980EEibUp0zFz
 GotRVekFAceUaRvAj7dh76cToeZkfsjAvBVb4COXuhgX6N4pofgNkW2AtgYu1nUsPAo+NftU
 CxrhjHtLn4QEBpkbErnXQyMjHpIatlYGutVMS91XTQXYydCh5crMPs7hYVsvnmGHIaB9ZMfB
 njnuI31KBiLUks+paRkHQlFcgS2N3gkRBzH7xSZ+t7Re3jvXdXEzKBbQ+dC3lpJB0wPnyMcX
 FOTT3aZT7IgePkt5iC/BKBk3hqKteTnJFeVIT7EC+a6YUFg=
Organization: Red Hat GmbH
Message-ID: <e32522cd-31bb-e129-47a6-9ec13b570506@redhat.com>
Date: Thu, 30 Apr 2020 10:20:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAPcyv4i04+QLxiOyz04_eef2DFetEFKBUmi2A4xxw9abQD8hNQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Pavel Tatashin <pasha.tatashin@soleen.com>,
 Baoquan He <bhe@redhat.com>, Linux MM <linux-mm@kvack.org>,
 Wei Yang <richard.weiyang@gmail.com>, linux-s390 <linux-s390@vger.kernel.org>,
 linux-nvdimm <linux-nvdimm@lists.01.org>,
 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 Dave Hansen <dave.hansen@linux.intel.com>,
 virtualization@lists.linux-foundation.org,
 Linux ACPI <linux-acpi@vger.kernel.org>,
 "Michael S . Tsirkin" <mst@redhat.com>, Eric Biederman <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.20 10:11, Dan Williams wrote:
> On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand <david@redhat.com> w=
rote:
>>
>> On 29.04.20 18:08, David Hildenbrand wrote:
>>> Some paravirtualized devices that add memory via add_memory() and
>>> friends (esp. virtio-mem) don't want to create entries in
>>> /sys/firmware/memmap/ - primarily to hinder kexec from adding this
>>> memory to the boot memmap of the kexec kernel.
>>>
>>> In fact, such memory is never exposed via the firmware (e.g., e820), =
but
>>> only via the device, so exposing this memory via /sys/firmware/memmap=
/ is
>>> wrong:
>>>  "kexec needs the raw firmware-provided memory map to setup the
>>>   parameter segment of the kernel that should be booted with
>>>   kexec. Also, the raw memory map is useful for debugging. For
>>>   that reason, /sys/firmware/memmap is an interface that provides
>>>   the raw memory map to userspace." [1]
>>>
>>> We want to let user space know that memory which is always detected,
>>> added, and managed via a (device) driver - like memory managed by
>>> virtio-mem - is special. It cannot be used for placing kexec segments
>>> and the (device) driver is responsible for re-adding memory that
>>> (eventually shrunk/grown/defragmented) memory after a reboot/kexec. I=
t
>>> should e.g., not be added to a fixed up firmware memmap. However, it =
should
>>> be dumped by kdump.
>>>
>>> Also, such memory could behave differently than an ordinary DIMM - e.=
g.,
>>> memory managed by virtio-mem can have holes inside added memory resou=
rce,
>>> which should not be touched, especially for writing.
>>>
>>> Let's expose that memory as "System RAM (driver managed)" e.g., via
>>> /pro/iomem.
>>>
>>> We don't have to worry about firmware_map_remove() on the removal pat=
h.
>>> If there is no entry, it will simply return with -EINVAL.
>>>
>>> [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmwa=
re-memmap
>>>
>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>> Cc: Michal Hocko <mhocko@suse.com>
>>> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
>>> Cc: Wei Yang <richard.weiyang@gmail.com>
>>> Cc: Baoquan He <bhe@redhat.com>
>>> Cc: Eric Biederman <ebiederm@xmission.com>
>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>> ---
>>>  include/linux/memory_hotplug.h |  8 ++++++++
>>>  mm/memory_hotplug.c            | 20 ++++++++++++++++----
>>>  2 files changed, 24 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_ho=
tplug.h
>>> index bf0e3edb8688..cc538584b39e 100644
>>> --- a/include/linux/memory_hotplug.h
>>> +++ b/include/linux/memory_hotplug.h
>>> @@ -68,6 +68,14 @@ struct mhp_params {
>>>       pgprot_t pgprot;
>>>  };
>>>
>>> +/* Flags used for add_memory() and friends. */
>>> +
>>> +/*
>>> + * Don't create entries in /sys/firmware/memmap/ and expose memory a=
s
>>> + * "System RAM (driver managed)" in e.g., /proc/iomem
>>> + */
>>> +#define MHP_DRIVER_MANAGED           1
>>> +
>>>  /*
>>>   * Zone resizing functions
>>>   *
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>> index ebdf6541d074..cfa0721280aa 100644
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -98,11 +98,11 @@ void mem_hotplug_done(void)
>>>  u64 max_mem_size =3D U64_MAX;
>>>
>>>  /* add this memory to iomem resource */
>>> -static struct resource *register_memory_resource(u64 start, u64 size=
)
>>> +static struct resource *register_memory_resource(u64 start, u64 size=
,
>>> +                                              const char *resource_n=
ame)
>>>  {
>>>       struct resource *res;
>>>       unsigned long flags =3D  IORESOURCE_SYSTEM_RAM | IORESOURCE_BUS=
Y;
>>> -     char *resource_name =3D "System RAM";
>>>
>>>       /*
>>>        * Make sure value parsed from 'mem=3D' only restricts memory a=
dding
>>> @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct r=
esource *res,
>>>       BUG_ON(ret);
>>>
>>>       /* create new memmap entry */
>>> -     firmware_map_add_hotplug(start, start + size, "System RAM");
>>> +     if (!(flags & MHP_DRIVER_MANAGED))
>>> +             firmware_map_add_hotplug(start, start + size, "System R=
AM");
>>>
>>>       /* device_online() will take the lock when calling online_pages=
() */
>>>       mem_hotplug_done();
>>> @@ -1081,10 +1082,21 @@ int __ref add_memory_resource(int nid, struct=
 resource *res,
>>>  /* requires device_hotplug_lock, see add_memory_resource() */
>>>  int __ref __add_memory(int nid, u64 start, u64 size, unsigned long f=
lags)
>>>  {
>>> +     const char *resource_name =3D "System RAM";
>>>       struct resource *res;
>>>       int ret;
>>>
>>> -     res =3D register_memory_resource(start, size);
>>> +     /*
>>> +      * Indicate that memory managed by a driver is special. It's al=
ways
>>> +      * detected and added via a driver, should not be given to the =
kexec
>>> +      * kernel for booting when manually crafting the firmware memma=
p, and
>>> +      * no kexec segments should be placed on it. However, kdump sho=
uld
>>> +      * dump this memory.
>>> +      */
>>> +     if (flags & MHP_DRIVER_MANAGED)
>>> +             resource_name =3D "System RAM (driver managed)";
>>> +
>>> +     res =3D register_memory_resource(start, size, resource_name);
>>>       if (IS_ERR(res))
>>>               return PTR_ERR(res);
>>>
>>>
>>
>> BTW, I was wondering if this is actually also something that
>> drivers/dax/kmem.c wants to use for adding memory.
>>
>> Just because we decided to use some DAX memory in the current kernel a=
s
>> system ram, doesn't mean we should make that decision for the kexec
>> kernel (e.g., using it as initial memory, placing kexec binaries onto
>> it, etc.). This is also not what we would observe during a real reboot=
.
>=20
> Agree.
>=20
>> I can see that the "System RAM" resource will show up as child resourc=
e
>> under the device e.g., in /proc/iomem.
>>
>> However, entries in /sys/firmware/memmap/ are created as "System RAM".
>=20
> True. Do you think this rename should just be limited to what type
> /sys/firmware/memmap/ emits? I have the concern, but no proof

We could split this patch into

MHP_NO_FIRMWARE_MEMMAP (create firmware memmap entries)

and

MHP_DRIVER_MANAGED (name of the resource)

See below, the latter might not be needed.

> currently, that there are /proc/iomem walkers that explicitly look for
> "System RAM", but might be thrown off by "System RAM (driver
> managed)". I was not aware of /sys/firmware/memmap until about 5
> minutes ago.

The only two users of /proc/iomem I am aware of are kexec-tools and some
s390x tools.

kexec-tools on x86-64 uses /sys/firmware/memmap to craft the initial
memmap, but uses /proc/iomem to
a) Find places for kexec images
b) Detect memory regions to dump via kdump

I am not yet sure if we really need the "System RAM (driver managed)"
part. If we can teach kexec-tools to
a) Don't place kexec images on "System RAM" that has a parent resource
(most likely requires kexec-tools changes)
b) Consider for kdump "System RAM" that has a parent resource
we might be able to avoid renaming that. (I assume that's already done)

E.g., regarding virtio-mem (patch #3) I am currently also looking into
creating a parent resource instead, like dax/kmem to avoid the rename:

:/# cat /proc/iomem
00000000-00000fff : Reserved
[...]
100000000-13fffffff : System RAM
140000000-33fffffff : virtio0
  140000000-147ffffff : System RAM
  148000000-14fffffff : System RAM
  150000000-157ffffff : System RAM
340000000-303fffffff : virtio1
  340000000-347ffffff : System RAM
3280000000-32ffffffff : PCI Bus 0000:00



--=20
Thanks,

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 08:29:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 08:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU4Yx-0003vC-7Q; Thu, 30 Apr 2020 08:28:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/gX9=6O=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jU4Yw-0003v7-KS
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 08:28:54 +0000
X-Inumbo-ID: a01f4bee-8abc-11ea-ae69-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a01f4bee-8abc-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 08:28:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588235333;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=zlmJPOZCYWIUpubzos1hzhtSRn6gIoLTRbJuO70c0rE=;
 b=Y9RtkVo4qSXEVNepDHSS1MSQMYJy5z9oMUG5dBoVALDx9qvH8xogK6/O
 4wh+onDx4uZmhcxDA1skt4Z/mnLdRUshuTLrRvo7G1UKVfQ4VvRhgrizC
 DmMLgSmUZ021cD2lx3zOznPP5rq5YESqcr8DmEiO+hIleEbnhPog4II6V E=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: eWKkNHgFWKOXqnJV6HMQGDt5c31msB0u2EpxFbbFRBtcoyKOp/oNADGEbEBg1weYpLDG/lb+51
 af7SydN3vPw5f4QyK795XAaMbTWUq4MQOAQGVfsxy+5qXSpWvE42iPczplnZEM/8dnHj98pjN3
 xRhj+8yCAdHIy/KIur+g5ALyXQ5uD7qww51jPsgruJyRelqFK9DBrf1qGvCwrpnRsMM3sea7XO
 mU6FkDKkbUZMTgwkB01yVWLHNCBAzvS1VwgCkN723ZI5cqUU5+xgE1MJPG1EKOq4Cml9/pBMLB
 f+M=
X-SBRS: 2.7
X-MesageID: 16891367
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,334,1583211600"; d="scan'208";a="16891367"
Date: Thu, 30 Apr 2020 10:28:44 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86/hap: be more selective with assisted TLB flush
Message-ID: <20200430082844.GZ28601@Air-de-Roger>
References: <20200429173601.77605-1-roger.pau@citrix.com>
 <4257a323-d37f-4af0-bdc6-a3f65c19438a@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <4257a323-d37f-4af0-bdc6-a3f65c19438a@suse.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 09:20:58AM +0200, Jan Beulich wrote:
> On 29.04.2020 19:36, Roger Pau Monne wrote:
> > When doing an assisted flush on HAP the purpose of the
> > on_selected_cpus is just to trigger a vmexit on remote CPUs that are
> > in guest context, and hence just using is_vcpu_dirty_cpu is too lax,
> > also check that the vCPU is running.
> 
> Am I right to understand that the change is relevant only to
> cover the period of time between ->is_running becoming false
> and ->dirty_cpu becoming VCPU_CPU_CLEAN? I.e. ...
> 
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -719,7 +719,7 @@ static bool flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
> >          hvm_asid_flush_vcpu(v);
> >  
> >          cpu = read_atomic(&v->dirty_cpu);
> > -        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) )
> > +        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v->is_running )
> 
> ... the previous logic would have suitably covered the switch-to
> path, but doesn't properly cover the switch-from one, due to our
> lazy context switch approach?

Yes. Also __context_switch is not called from context_switch when
switching to the idle vcpu, and hence dirty_cpu is not cleared.

> If so, I agree with the change:
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> It might be worth mentioning this detail in the description then,
> though.

Would you mind adding to the commit message if you agree:

"Due to the lazy context switching done by Xen dirty_cpu won't always be
cleared when the guest vCPU is not running, and hence relying on
is_running allows more fine grained control of whether the vCPU is
actually running."

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 08:34:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 08:34:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU4dw-0004iI-N2; Thu, 30 Apr 2020 08:34:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU4dw-0004iD-9J
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 08:34:04 +0000
X-Inumbo-ID: 57b30174-8abd-11ea-9a10-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 57b30174-8abd-11ea-9a10-12813bfff9fa;
 Thu, 30 Apr 2020 08:34:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 84A34AB7F;
 Thu, 30 Apr 2020 08:33:59 +0000 (UTC)
Subject: Re: [PATCH] x86/hap: be more selective with assisted TLB flush
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200429173601.77605-1-roger.pau@citrix.com>
 <4257a323-d37f-4af0-bdc6-a3f65c19438a@suse.com>
 <20200430082844.GZ28601@Air-de-Roger>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <d5a0308b-0ac3-21f5-9a07-e1402005b663@suse.com>
Date: Thu, 30 Apr 2020 10:33:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200430082844.GZ28601@Air-de-Roger>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.2020 10:28, Roger Pau Monné wrote:
> On Thu, Apr 30, 2020 at 09:20:58AM +0200, Jan Beulich wrote:
>> On 29.04.2020 19:36, Roger Pau Monne wrote:
>>> When doing an assisted flush on HAP the purpose of the
>>> on_selected_cpus is just to trigger a vmexit on remote CPUs that are
>>> in guest context, and hence just using is_vcpu_dirty_cpu is too lax,
>>> also check that the vCPU is running.
>>
>> Am I right to understand that the change is relevant only to
>> cover the period of time between ->is_running becoming false
>> and ->dirty_cpu becoming VCPU_CPU_CLEAN? I.e. ...
>>
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -719,7 +719,7 @@ static bool flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
>>>          hvm_asid_flush_vcpu(v);
>>>  
>>>          cpu = read_atomic(&v->dirty_cpu);
>>> -        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) )
>>> +        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v->is_running )
>>
>> ... the previous logic would have suitably covered the switch-to
>> path, but doesn't properly cover the switch-from one, due to our
>> lazy context switch approach?
> 
> Yes. Also __context_switch is not called from context_switch when
> switching to the idle vcpu, and hence dirty_cpu is not cleared.
> 
>> If so, I agree with the change:
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> It might be worth mentioning this detail in the description then,
>> though.
> 
> Would you mind adding to the commit message if you agree:
> 
> "Due to the lazy context switching done by Xen dirty_cpu won't always be
> cleared when the guest vCPU is not running, and hence relying on
> is_running allows more fine grained control of whether the vCPU is
> actually running."

Sure; I'll give it over the weekend though for others to comment, if
so desired.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 08:34:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 08:34:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU4e8-0004js-V9; Thu, 30 Apr 2020 08:34:16 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JErk=6O=intel.com=dan.j.williams@srs-us1.protection.inumbo.net>)
 id 1jU4e8-0004jn-Bu
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 08:34:16 +0000
X-Inumbo-ID: 5ddc9dd0-8abd-11ea-ae69-bc764e2007e4
Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 5ddc9dd0-8abd-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 08:34:13 +0000 (UTC)
Received: by mail-ej1-x641.google.com with SMTP id n4so3966276ejs.11
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 01:34:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=intel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=87dIcS/jrU3IxflLIkdtnvU4qll0iHvEZNuLGZ4o7wI=;
 b=C7NzSwQeQ8r7hb6zu0mE43nN5BVsWOZy21t9s86oMspwPoqNG+2r9QwYXMI253bkO+
 f2NXbqJEZlVUDXw2jKOJXTdMksOMSeCU/1+d1/KW3kPK6bDnIkjaV85ydvslVx7+7VaK
 H/Wy8s3jtrbog9dFPbt+U8g4F9a/kPxAFzoHfDtTpSCDud/nTiDKxbIHNOx4gDT1cWli
 scShmtfTOkTf1D6LztaDjOZAMAIUOcl9E1Ehg4s+icpPrmffJn6TfhOtMJuuVZZemCWo
 u5q8IaOdIkls7C87+V/X7frCMtH72XB/et/faVXvhnFad5uP3/TQ8BbSLNTCllAusarT
 BwFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=87dIcS/jrU3IxflLIkdtnvU4qll0iHvEZNuLGZ4o7wI=;
 b=eBK7HnCm2+L9Ye86kGh2AOY2F3sNS/Z+gbFKxnbgmfAnuhNSSETHX6IqLSwc0Ah27b
 1h6VpKIUuDIVpooJDKOlbG7K4CfzE34nYrXvkqRNi+DGwtBFO87WHBZUmUfUL/oo9dVO
 fxToH3GCwBGRo5CqrySxVoOAZu7kxhCFeAJWElhvEAdA4vpDazEzsRqhZshdP0ZFK47o
 BBrMA3iuV4ESMm+j8UujRX+m6wrNo0PBCz60axlUDJTA/+IWwrgNOVFSCQWV3Wc+jQLm
 yaw3l637rmMQ7MlqlgtC5sUyXmSh2mONCfAmtacFF95X2x43eAFpxlfJybdtBMCvJ4sb
 xjvQ==
X-Gm-Message-State: AGi0Pub8WUzp0yGb/xZYONJzKrZ3FlofcgfpoGcMHyuPgfJtqzlQOBQ8
 leTLheZJ4KZlMSt3L4zV2KFzNQuPIP3P3AdG7ZO/GA==
X-Google-Smtp-Source: APiQypLBVztlIIHfr3wCtEt+MVa/TaJHl/O1nuNqStB0TwAKkS6wTTbCgFJlPXMDG8iI601GTPaB481cRsH+FNdImHY=
X-Received: by 2002:a17:906:7750:: with SMTP id
 o16mr1715515ejn.12.1588235651152; 
 Thu, 30 Apr 2020 01:34:11 -0700 (PDT)
MIME-Version: 1.0
References: <20200429160803.109056-1-david@redhat.com>
 <20200429160803.109056-3-david@redhat.com>
 <a7305cd8-8b2f-1d8f-7654-ecf777c46df6@redhat.com>
 <CAPcyv4i04+QLxiOyz04_eef2DFetEFKBUmi2A4xxw9abQD8hNQ@mail.gmail.com>
 <e32522cd-31bb-e129-47a6-9ec13b570506@redhat.com>
In-Reply-To: <e32522cd-31bb-e129-47a6-9ec13b570506@redhat.com>
From: Dan Williams <dan.j.williams@intel.com>
Date: Thu, 30 Apr 2020 01:34:00 -0700
Message-ID: <CAPcyv4gjRE23BHsBAnaVWAPUHWdenxYMUwDBnDF7UmoejmmbNQ@mail.gmail.com>
Subject: Re: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
To: David Hildenbrand <david@redhat.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Pavel Tatashin <pasha.tatashin@soleen.com>,
 Baoquan He <bhe@redhat.com>, Linux MM <linux-mm@kvack.org>,
 Wei Yang <richard.weiyang@gmail.com>, linux-s390 <linux-s390@vger.kernel.org>,
 linux-nvdimm <linux-nvdimm@lists.01.org>,
 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 Dave Hansen <dave.hansen@linux.intel.com>,
 virtualization@lists.linux-foundation.org,
 Linux ACPI <linux-acpi@vger.kernel.org>,
 "Michael S . Tsirkin" <mst@redhat.com>, Eric Biederman <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 1:21 AM David Hildenbrand <david@redhat.com> wrote:
> >> Just because we decided to use some DAX memory in the current kernel as
> >> system ram, doesn't mean we should make that decision for the kexec
> >> kernel (e.g., using it as initial memory, placing kexec binaries onto
> >> it, etc.). This is also not what we would observe during a real reboot.
> >
> > Agree.
> >
> >> I can see that the "System RAM" resource will show up as child resource
> >> under the device e.g., in /proc/iomem.
> >>
> >> However, entries in /sys/firmware/memmap/ are created as "System RAM".
> >
> > True. Do you think this rename should just be limited to what type
> > /sys/firmware/memmap/ emits? I have the concern, but no proof
>
> We could split this patch into
>
> MHP_NO_FIRMWARE_MEMMAP (create firmware memmap entries)
>
> and
>
> MHP_DRIVER_MANAGED (name of the resource)
>
> See below, the latter might not be needed.
>
> > currently, that there are /proc/iomem walkers that explicitly look for
> > "System RAM", but might be thrown off by "System RAM (driver
> > managed)". I was not aware of /sys/firmware/memmap until about 5
> > minutes ago.
>
> The only two users of /proc/iomem I am aware of are kexec-tools and some
> s390x tools.
>
> kexec-tools on x86-64 uses /sys/firmware/memmap to craft the initial
> memmap, but uses /proc/iomem to
> a) Find places for kexec images
> b) Detect memory regions to dump via kdump
>
> I am not yet sure if we really need the "System RAM (driver managed)"
> part. If we can teach kexec-tools to
> a) Don't place kexec images on "System RAM" that has a parent resource
> (most likely requires kexec-tools changes)
> b) Consider for kdump "System RAM" that has a parent resource
> we might be able to avoid renaming that. (I assume that's already done)
>
> E.g., regarding virtio-mem (patch #3) I am currently also looking into
> creating a parent resource instead, like dax/kmem to avoid the rename:
>
> :/# cat /proc/iomem
> 00000000-00000fff : Reserved
> [...]
> 100000000-13fffffff : System RAM
> 140000000-33fffffff : virtio0
>   140000000-147ffffff : System RAM
>   148000000-14fffffff : System RAM
>   150000000-157ffffff : System RAM
> 340000000-303fffffff : virtio1
>   340000000-347ffffff : System RAM
> 3280000000-32ffffffff : PCI Bus 0000:00

Looks good to me if it flies with kexec-tools.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 09:04:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 09:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU57M-0007PB-MX; Thu, 30 Apr 2020 09:04:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PrLm=6O=yahoo.com=hack3rcon@srs-us1.protection.inumbo.net>)
 id 1jU57L-0007P6-AK
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 09:04:27 +0000
X-Inumbo-ID: 972f255e-8ac1-11ea-9a10-12813bfff9fa
Received: from sonic314-15.consmr.mail.bf2.yahoo.com (unknown [74.6.132.125])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 972f255e-8ac1-11ea-9a10-12813bfff9fa;
 Thu, 30 Apr 2020 09:04:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1588237465; bh=/7sBjh3keCAW2bgBGj6YqVJynaVkYahyXKffvsIGTdY=;
 h=Date:From:Reply-To:To:Subject:References:From:Subject;
 b=P67kmvrEp07HQU/UB27Pb4QcFYzN67LLLQr9UiOpgltvWOIrG0/5XtSRrp2MIG62B+6JXM1XxSKXJ94khCHLACihYLzkOmqurvK55XKh2HLFGSZ1En5PnkrqKJHdCK+lo3EVifCAkQCiAGxrC/pmdPgiwGAyVoGuy6i0QeoqiubXPekN+9g1OiGrDOyV4aa+hD89IyP8FcJrs3MiFY36apO/wIzSBksr2xpkdaXAVxfqwWHHT2a8zkJdq1QDnuv3vN5AzI85F7Kr8N29I1Dv55CtfX6mVyNbH1RfY0j+2zWdbmzgWvhzP3i/q9vYt45MT0CbFIGMPl2J4llCdcwT+A==
X-YMail-OSG: 9.LgjRgVM1nyBhfI9MwQvmuZZM6VIRaipz3qshivA59IohJ1dcy0snAX1GUGg8P
 7TiymCgXsPTPvHe1TdRu0W6kmyALoqZlG2OqDvHHI3LrSl1sZaEhWTOde29BLkGIy5LZrXpG1iQe
 aT3LzziN6jCl0U8sGz24hbcj8uIPlAM0d_CRC0bgmaOReuiTd4b1u_TAz_vZxiXhSSsKMJsnYnTO
 a7lWsdY4UaJZfARMbfhLdh3GhGJ_Ae8qNJndy0Eci4uPf.YRWqyD9c6NV6TThsqDxeElBTPKUlL6
 aL.ogvAoNBv_lHq_rY0XpMwSHh5jST0KmwSce_9GgLkj10w6HLUc10oh5IGg0nS5.qxDWXnt7mzo
 KIEGGABTTAUJI.EakiKuftIlWxS3aJyNKT2.KyuNbbCHOsiOw._hFlBNa9OnrK24Up_Iq.JdP.Xu
 37ECQ.psy94GEc90TDu_bPUIXAkPz.0oY4dA5s3P.UJpTs3Q_cck3umjX7dubrwMLXwhFqzG.o0_
 YlpXoufau1KJwA7Y_VQdLcB92iudjX39Y6AIx5Tvx87nh2Tu8BLUW1QwoMWbacoNSJ0Oopo7BYxs
 ilxHcby9jDS8YmSr_7cvBQmhb45uRJf0l8BPGZSCR1Ntj.dvXF38EeP8ChPCl62laTBl5932XPfx
 06sy8P9AGnCJ6FeJcYTjh49voYDF8QpNYWFn2NmlurDCP4PrNAFk9ANpc5KbHvNtrNE0XyphY9wK
 meFMTz2QAogTOwnSLRT4xcvnud2X8uir6ce_ZrGaIsrmAuUSPnAr8dnQ7QQ.BVTmwAT0A5.VaScu
 lgusg4Zp2UN5RH3bj7FTZsKsBO89alO_6afImxLdzbagN904.Oi6G9h4ik6V8nqQxlXuIPaE24u_
 Ul3Xa8WcHD.nR1zvPk9f3mCkKdc54MTSgOvbLz82vGCLj81O.4D.0p6tLuXXds.FGsGrVDe1oRg8
 ek0LEl9ycTT5YKmF6P9c.MqjeM0_PJqiUB3ZPYuHtzaknfi_MBmc2bvLFDg5C8HiZknpCuTIRw1O
 1HTtwn9h6YTSCOOd.BG_47ZDnQ7tqSBuXdphKudzoWaemp2lZQMAZqmsVohvBWROb_WgTCiF6pED
 KSPYxkTdA_JtpIWhd8bgmvbHXxIjuxAbVSYlexoiV4orRMe5w26L8gRj.iknULw6jSIZ6dXJuMxS
 hXlfOMdzVRhWAwAWwjNh4tyzhkJ2EghgwxJ8LkTE9Vucj8I3poyhu3jWE10OpKS3mdWNuFWThMuz
 hYL5nJZUT2Q.VqUlLqAM9ZCcLdzHHTXbKnuUA42WdRnz2Nuj.98OqwqtUSJfwHq2F1g8UI11jvqn
 FnNc9WoTvdYyjLRs2mMNH2gmPsWrm58IDKc74SX3ujA--
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic314.consmr.mail.bf2.yahoo.com with HTTP; Thu, 30 Apr 2020 09:04:25 +0000
Date: Thu, 30 Apr 2020 09:04:22 +0000 (UTC)
From: Jason Long <hack3rcon@yahoo.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Message-ID: <573229028.266395.1588237462419@mail.yahoo.com>
Subject: Is it an April Fools' Day Joke?
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_266394_787268304.1588237462418"
References: <573229028.266395.1588237462419.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.15756 YahooMailAndroidMobile YMobile/1.0
 (com.yahoo.mobile.client.android.mail/6.6.2; Android/7.1.1; NMF26F; bbc100;
 BlackBerry; BBC100-1; 5.16; 1184x720; )
Content-Length: 710
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Reply-To: "hack3rcon@yahoo.com" <hack3rcon@yahoo.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

------=_Part_266394_787268304.1588237462418
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hello,According to "https://xenproject.org/2017/04/01/xen-hypervisor-to-be-rewritten/" article, is just a joke or real?
Thanks.
------=_Part_266394_787268304.1588237462418
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hello,<div id="yMail_cursorElementTracker_1588237394745">According to "https://xenproject.org/2017/04/01/xen-hypervisor-to-be-rewritten/" article, is just a joke or real?</div><div id="yMail_cursorElementTracker_1588237423684"><br></div><div id="yMail_cursorElementTracker_1588237423923">Thanks.</div>
------=_Part_266394_787268304.1588237462418--


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 09:18:06 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 09:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU5KI-0008Iq-T2; Thu, 30 Apr 2020 09:17:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/gX9=6O=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jU5KH-0008Il-QG
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 09:17:49 +0000
X-Inumbo-ID: 757ff7ed-8ac3-11ea-9a12-12813bfff9fa
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 757ff7ed-8ac3-11ea-9a12-12813bfff9fa;
 Thu, 30 Apr 2020 09:17:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588238268;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=3tElwOR5SMvygmh076A/T3p277AnxQXNp6ZmGgUyWcs=;
 b=EiHyYPXS4L+0jtD/Rysju4C/LUMqiHS53ufV1HX+8D5sj8RvAU++aOxA
 oHPCNY96MR9zSsmXygzgHDUPdkQVc3pzrQaH7IBX5YGP0HwfgfSDnGpPU
 z2vSGQcucLzqbG+JRCdlWpnzJxbL8trTHCwF1UP9kg/45Z7J61fXm+pTW k=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: El3z5Pex9n1Vnt4iBED7+gKnfwSD+n80nkFwZBKKJeHx72O4VmnQQJopwFqDF1jVYu3hvQ6vRx
 fax7vP/VNOhqVsylSpv8nRmRXuGD/14Xk1HNIi+TaP9wbABNoPhGxLEPdlaXZIQrndvyTj7btL
 whjTfyK3ouxXHwoOZ7WQkPjpTPh1hKd/CA7PqOWG+7Eg0p4Shv1nX0ErAvledG7qaRWVWb0thF
 uaQyy+zPRVDLpPFd3HRMo2pm7/J6PY9b3eNMQrz9wU97zdPmANojtlVhgC7RuS5gYcJdvl0UGa
 /Kw=
X-SBRS: 2.7
X-MesageID: 16893124
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,334,1583211600"; d="scan'208";a="16893124"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/hvm: allow for more fine grained assisted flush
Date: Thu, 30 Apr 2020 11:17:25 +0200
Message-ID: <20200430091725.80656-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.26.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, George
 Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Roger Pau Monne <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Improve the assisted flush by expanding the interface and allowing for
more fine grained TLB flushes to be issued using the HVMOP_flush_tlbs
hypercall. Support for such advanced flushes is signaled in CPUID
using the XEN_HVM_CPUID_ADVANCED_FLUSH flag.

The new features make use of the NULL parameter so far passed in the
hypercall in order to convey extra data to perform more selective
flushes: a virtual address, an order field, a flags field and finally a
vCPU bitmap. Note that not all features are implemented as part of
this patch, but are already added to the interface in order to avoid
having to introduce yet a new CPUID flag when the new features are
added.

The feature currently implemented is the usage of a guest provided
vCPU bitmap in order to signal which vCPUs require a TLB flush,
instead of assuming all vCPUs must be flushed. Note that not
implementing the rest of the features just make the flush less
efficient, but it's still correct and safe.

Finally add support for Xen running in guest mode (Xen on Xen or PV
shim mode) to use the newly introduced flush options when available.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/guest/xen/xen.c        | 22 +++++++++++++++++-
 xen/arch/x86/hvm/hvm.c              | 35 ++++++++++++++++++++++++-----
 xen/arch/x86/traps.c                |  4 +++-
 xen/include/public/arch-x86/cpuid.h |  2 ++
 xen/include/public/hvm/hvm_op.h     | 23 ++++++++++++++++++-
 5 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 2ff63d370a..310ce0c6fb 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -326,7 +326,27 @@ static void __init e820_fixup(struct e820map *e820)
 
 static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int flags)
 {
-    return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
+    xen_hvm_flush_tlbs_t op = {
+        .va = (unsigned long)va,
+        .order = (flags - 1) & FLUSH_ORDER_MASK,
+        .flags = ((flags & FLUSH_TLB_GLOBAL) ? HVMOP_flush_global : 0) |
+                 ((flags & FLUSH_VA_VALID) ? HVMOP_flush_va_valid : 0),
+        .mask_size = BITS_TO_LONGS(nr_cpu_ids),
+    };
+    static int8_t __read_mostly advanced_flush = -1;
+
+    if ( advanced_flush == -1 )
+    {
+        uint32_t eax, ebx, ecx, edx;
+
+        ASSERT(xen_cpuid_base);
+        cpuid(xen_cpuid_base + 4, &eax, &ebx, &ecx, &edx);
+        advanced_flush = (eax & XEN_HVM_CPUID_ADVANCED_FLUSH) ? 1 : 0;
+    }
+
+    set_xen_guest_handle(op.vcpu_mask, cpumask_bits(mask));
+
+    return xen_hypercall_hvm_op(HVMOP_flush_tlbs, advanced_flush ? &op : NULL);
 }
 
 static const struct hypervisor_ops __initconstrel ops = {
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 814b7020d8..1d41b6e2ea 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4011,17 +4011,42 @@ static void hvm_s3_resume(struct domain *d)
     }
 }
 
-static bool always_flush(void *ctxt, struct vcpu *v)
+static bool flush_check(void *mask, struct vcpu *v)
 {
-    return true;
+    return mask ? test_bit(v->vcpu_id, (unsigned long *)mask) : true;
 }
 
-static int hvmop_flush_tlb_all(void)
+static int hvmop_flush_tlb(XEN_GUEST_HANDLE_PARAM(xen_hvm_flush_tlbs_t) uop)
 {
+    xen_hvm_flush_tlbs_t op;
+    DECLARE_BITMAP(mask, HVM_MAX_VCPUS) = { };
+    bool valid_mask = false;
+
     if ( !is_hvm_domain(current->domain) )
         return -EINVAL;
 
-    return paging_flush_tlb(always_flush, NULL) ? 0 : -ERESTART;
+    if ( !guest_handle_is_null(uop) )
+    {
+        if ( copy_from_guest(&op, uop, 1) )
+            return -EFAULT;
+
+        /*
+         * TODO: implement support for the other features present in
+         * xen_hvm_flush_tlbs_t: flushing a specific virtual address and not
+         * flushing global mappings.
+         */
+
+        if ( op.mask_size > ARRAY_SIZE(mask) )
+            return -EINVAL;
+
+        if ( copy_from_guest(mask, op.vcpu_mask, op.mask_size) )
+            return -EFAULT;
+
+        valid_mask = true;
+    }
+
+    return paging_flush_tlb(flush_check, valid_mask ? mask : NULL) ? 0
+                                                                   : -ERESTART;
 }
 
 static int hvmop_set_evtchn_upcall_vector(
@@ -5017,7 +5042,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
 
     case HVMOP_flush_tlbs:
-        rc = guest_handle_is_null(arg) ? hvmop_flush_tlb_all() : -EINVAL;
+        rc = hvmop_flush_tlb(guest_handle_cast(arg, xen_hvm_flush_tlbs_t));
         break;
 
     case HVMOP_get_mem_type:
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index e838846c6b..b07da2fd33 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -966,8 +966,10 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
         /*
          * Indicate that memory mapped from other domains (either grants or
          * foreign pages) has valid IOMMU entries.
+         *
+         * Also signal support for more selective assisted flush support.
          */
-        res->a |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
+        res->a |= XEN_HVM_CPUID_IOMMU_MAPPINGS | XEN_HVM_CPUID_ADVANCED_FLUSH;
 
         /* Indicate presence of vcpu id and set it in ebx */
         res->a |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
index ce46305bee..b980ed91f6 100644
--- a/xen/include/public/arch-x86/cpuid.h
+++ b/xen/include/public/arch-x86/cpuid.h
@@ -102,6 +102,8 @@
 #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
 #define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu id is present in EBX */
 #define XEN_HVM_CPUID_DOMID_PRESENT    (1u << 4) /* domid is present in ECX */
+/* Supports more fine grained assisted flush, see HVMOP_flush_tlbs. */
+#define XEN_HVM_CPUID_ADVANCED_FLUSH   (1u << 5)
 
 /*
  * Leaf 6 (0x40000x05)
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index 870ec52060..ca6ae678bc 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -99,8 +99,29 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_pci_link_route_t);
 
 #endif /* __XEN_INTERFACE_VERSION__ < 0x00040900 */
 
-/* Flushes all VCPU TLBs: @arg must be NULL. */
+/*
+ * Flushes all VCPU TLBs: @arg can be NULL or xen_hvm_flush_tlbs_t.
+ *
+ * Support for passing a xen_hvm_flush_tlbs_t parameter is signaled in CPUID,
+ * see XEN_HVM_CPUID_ADVANCED_FLUSH.
+ */
 #define HVMOP_flush_tlbs          5
+struct xen_hvm_flush_tlbs {
+    /* Virtual address to be flushed. */
+    uint64_t va;
+    uint16_t order;
+    uint16_t flags;
+/* Flush global mappings. */
+#define HVMOP_flush_global      (1u << 0)
+/* VA for the flush has a valid mapping. */
+#define HVMOP_flush_va_valid    (1u << 1)
+    /* Number of uint64_t elements in vcpu_mask. */
+    uint32_t mask_size;
+    /* Bitmask of vcpus that should be flushed. */
+    XEN_GUEST_HANDLE(const_uint64) vcpu_mask;
+};
+typedef struct xen_hvm_flush_tlbs xen_hvm_flush_tlbs_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_flush_tlbs_t);
 
 /*
  * hvmmem_type_t should not be defined when generating the corresponding
-- 
2.26.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 09:50:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 09:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU5pt-0002yf-HD; Thu, 30 Apr 2020 09:50:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DLrL=6O=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jU5ps-0002ya-HG
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 09:50:28 +0000
X-Inumbo-ID: 04f08c4e-8ac8-11ea-9a1a-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 04f08c4e-8ac8-11ea-9a1a-12813bfff9fa;
 Thu, 30 Apr 2020 09:50:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=PxBNkF7+riN5bP8ocWX9q2/g6vbgYkPJ0mooDLs5ODw=; b=s9i9LsdXxBe6kO8EYpUWn2YG1
 2/7FaG+Nb9gMXBWfgcrJa28Zu1e4Xo4QiTB14n6HUcTXWrX0NUKyr2w8hMdS6vYwdo+2BiFmFoaTn
 qmIdZTyG0r4pZcuXi62G/Gkm3LhZCjL9SF8ZUQFsVEsFTlwbnNpUwoYxVpfonWr8k/FlI=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jU5pq-0007uv-NW; Thu, 30 Apr 2020 09:50:26 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jU5pq-0008Nm-FF; Thu, 30 Apr 2020 09:50:26 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jU5pq-0000dx-E9; Thu, 30 Apr 2020 09:50:26 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149881-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149881: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-saverestore.2:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=f9bf746258eb53011f863571c7073037202b6743
X-Osstest-Versions-That: xen=4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 30 Apr 2020 09:50:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149881 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149881/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     17 guest-saverestore.2     fail blocked in 149871
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149871
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149871
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149871
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149871
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149871
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149871
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149871
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149871
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149871
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  f9bf746258eb53011f863571c7073037202b6743
baseline version:
 xen                  4ec07971f1c5a236a0d8c528d806efb6bfd3d1a6

Last test of basis   149871  2020-04-29 05:14:21 Z    1 days
Testing same since   149881  2020-04-29 16:37:39 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <liuwe@microsoft.com>
  Wei Liu <wl@xen.org>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4ec07971f1..f9bf746258  f9bf746258eb53011f863571c7073037202b6743 -> master


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:00:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU5z7-0003It-Qr; Thu, 30 Apr 2020 10:00:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rLHY=6O=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jU5z6-0003Io-2o
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:00:00 +0000
X-Inumbo-ID: 5922d6a4-8ac9-11ea-9a1a-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 5922d6a4-8ac9-11ea-9a1a-12813bfff9fa;
 Thu, 30 Apr 2020 09:59:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588240798;
 h=from:to:cc:subject:date:message-id:mime-version:
 content-transfer-encoding;
 bh=JNA2EqtL+1PvxFWyMchGBptIJFGtuDtjmUmW4f6lunw=;
 b=FxlSxna6K0BieRCQmkbok9T7uD1A4x9jRFAqRQnnV7faGsXTxG3OjSIj
 I4luP8ZlSzg2IJAcizy+0SsTlh3irsujLzOCiCf4n/NTjlOh9+fz7p9+c
 ynmMXjX/Ax9k7AFfsCXG49yxc9OK2IsyV662SykmpDKUxRbMa1uhiTqv2 8=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: T7+UfYGJ/hxUYpCQq/cbrS/bkyROfMxy9vZZJrlt2dc7LtHJgzXW09coTpnq1Wgnp2ogL7sFDK
 AIz7kQicSgNcj8wba6nnskG4kPmq0lxHc9vOkmv1Wt2Yondis6IBep/ijqcT1sbqwkk1FQ5ded
 LpAysGfoc11SNdW87j/NcLXe826Lci2RcxC9WOcMXUaE2DYB71ldwdctLVMb57L8QsSM29FPEg
 SsL2G1tRFWYj2URId9/Uxq7eJ/Tfkop5iWxaV4qQPSEoAzdha7PMf2XKAZaS/11c2AedoqIeU1
 Y9I=
X-SBRS: 2.7
X-MesageID: 16749621
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,334,1583211600"; d="scan'208";a="16749621"
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/amd: Initial support for Fam19h processors
Date: Thu, 30 Apr 2020 10:59:47 +0100
Message-ID: <20200430095947.31958-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Fam19h is very similar to Fam17h in these regards.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/acpi/cpu_idle.c     | 1 +
 xen/arch/x86/cpu/microcode/amd.c | 1 +
 xen/arch/x86/cpu/vpmu_amd.c      | 1 +
 xen/arch/x86/nmi.c               | 2 +-
 xen/arch/x86/traps.c             | 2 +-
 5 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index e00f2a82de..b83446e77d 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -1356,6 +1356,7 @@ static void amd_cpuidle_init(struct acpi_processor_power *power)
 
     switch ( c->x86 )
     {
+    case 0x19:
     case 0x18:
         if ( boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
         {
diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index 13bf9f4dee..89b656bd2b 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -125,6 +125,7 @@ static bool_t verify_patch_size(uint32_t patch_size)
         max_size = F16H_MPB_MAX_SIZE;
         break;
     case 0x17:
+    case 0x19:
         max_size = F17H_MPB_MAX_SIZE;
         break;
     default:
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index 3c6799b42c..eba47cd2a0 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -576,6 +576,7 @@ int __init amd_vpmu_init(void)
     {
     case 0x15:
     case 0x17:
+    case 0x19:
         num_counters = F15H_NUM_COUNTERS;
         counters = AMD_F15H_COUNTERS;
         ctrls = AMD_F15H_CTRLS;
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index c3f92ed231..014524486f 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -398,7 +398,7 @@ void setup_apic_nmi_watchdog(void)
     case X86_VENDOR_AMD:
         switch (boot_cpu_data.x86) {
         case 6:
-        case 0xf ... 0x17:
+        case 0xf ... 0x19:
             setup_k7_watchdog();
             break;
         default:
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 0bcf554e93..33e5d21ece 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1939,7 +1939,7 @@ static unsigned int calc_ler_msr(void)
         switch ( boot_cpu_data.x86 )
         {
         case 6:
-        case 0xf ... 0x17:
+        case 0xf ... 0x19:
             return MSR_IA32_LASTINTFROMIP;
         }
         break;
-- 
2.11.0



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:16:20 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:16:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6Ej-00051K-9P; Thu, 30 Apr 2020 10:16:09 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/gX9=6O=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jU6Eh-00050b-8w
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:16:07 +0000
X-Inumbo-ID: 9a126efc-8acb-11ea-b9cf-bc764e2007e4
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9a126efc-8acb-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 10:16:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588241766;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=gHM5xaEnupw7A89FhNhhvExQxC2eIu4fTQ1Mu+651Go=;
 b=BPAQAVg2Z+rhepVeLxxnBHLg9SdmQ/jneQy3hIzdD0gcSwqk9XW7OyQD
 XkTQvW7yvCBjflKSgDaZmEJA8OywYetOEAS1Eo0N4mwvt1DwcATLJtdQE
 RfL5lls2SjoMMJDMo7LAoefKMGKOsemx3XT0wNYRfyev+VIjqvJghrTMd c=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: cDUZ/JW8Rb9GDPYHkVGwiHA93AGCj4sImeakv5AsCDn74Nzn9SQMCH33b8ci8hYPO1IHQ7sT7C
 GF1UdCSEk/YhlJoBAj7MLa+tkeXfuEv/jdCPJZt8HWv4/hwfTrei8yDwkjhUhOpxlHbAcltRmY
 g6aaD7ODNTNSvXu/n0OOOGRpstXM1StNXrohoWaD5LPxqi1P5m2CLAawPTiGhdCVRbtMrEWdf6
 UQe2ePLmnTzoDN+wP/Dghhb6NdDHP8G+fpA0FXJMfUSr/jfHhrZ+6CnVUQXDLcuLYQnoq2j9Ul
 FYo=
X-SBRS: 2.7
X-MesageID: 16509149
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,334,1583211600"; d="scan'208";a="16509149"
Date: Thu, 30 Apr 2020 12:15:58 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Wei Liu <wl@xen.org>
Subject: Re: [PATCH] x86/hyperv: stash and use the configured max VP index
Message-ID: <20200430101558.GA28601@Air-de-Roger>
References: <20200429104144.17816-1-liuwe@microsoft.com>
 <20200429114718.zclpy6r6sbxuo6ph@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200429114718.zclpy6r6sbxuo6ph@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <liuwe@microsoft.com>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Michael Kelley <mikelley@microsoft.com>, Jan Beulich <jbeulich@suse.com>,
 Xen Development List <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Wed, Apr 29, 2020 at 11:47:18AM +0000, Wei Liu wrote:
> On Wed, Apr 29, 2020 at 11:41:44AM +0100, Wei Liu wrote:
> > The value returned from CPUID is the maximum number for virtual
> > processors supported by Hyper-V. It could be larger than the maximum
> > number of virtual processors configured.
> > 
> > Stash the configured number into a variable and use it in calculations.
> > 
> > Signed-off-by: Wei Liu <liuwe@microsoft.com>
> > ---
> >  xen/arch/x86/guest/hyperv/hyperv.c  | 4 ++++
> >  xen/arch/x86/guest/hyperv/private.h | 1 +
> >  xen/arch/x86/guest/hyperv/tlb.c     | 2 +-
> >  xen/arch/x86/guest/hyperv/util.c    | 2 +-
> >  4 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c
> > index 91a6782cd986..84221b751453 100644
> > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > @@ -33,6 +33,7 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
> >  DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
> >  DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
> >  
> > +unsigned int __read_mostly hv_max_vp_index;
> >  static bool __read_mostly hcall_page_ready;
> >  
> >  static uint64_t generate_guest_id(void)
> > @@ -143,6 +144,9 @@ static int setup_hypercall_pcpu_arg(void)
> >      rdmsrl(HV_X64_MSR_VP_INDEX, vp_index_msr);
> >      this_cpu(hv_vp_index) = vp_index_msr;
> >  
> > +    if ( vp_index_msr > hv_max_vp_index )
> > +        hv_max_vp_index = vp_index_msr;
> > +
> >      return 0;
> >  }
> >  
> > diff --git a/xen/arch/x86/guest/hyperv/private.h b/xen/arch/x86/guest/hyperv/private.h
> > index 354fc7f685a7..fea3e291e944 100644
> > --- a/xen/arch/x86/guest/hyperv/private.h
> > +++ b/xen/arch/x86/guest/hyperv/private.h
> > @@ -28,6 +28,7 @@
> >  DECLARE_PER_CPU(void *, hv_input_page);
> >  DECLARE_PER_CPU(void *, hv_vp_assist);
> >  DECLARE_PER_CPU(unsigned int, hv_vp_index);
> > +extern unsigned int hv_max_vp_index;
> >  
> >  static inline unsigned int hv_vp_index(unsigned int cpu)
> >  {
> > diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
> > index 1d723d6ee679..0a44071481bd 100644
> > --- a/xen/arch/x86/guest/hyperv/tlb.c
> > +++ b/xen/arch/x86/guest/hyperv/tlb.c
> > @@ -166,7 +166,7 @@ int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
> >          {
> >              unsigned int vpid = hv_vp_index(cpu);
> >  
> > -            if ( vpid >= ms_hyperv.max_vp_index )
> > +            if ( vpid >= hv_max_vp_index )
> 
> I think the >= should be changed to > here.

I agree. With this fixed:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks!


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:21:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6Js-0005pE-1O; Thu, 30 Apr 2020 10:21:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/gX9=6O=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jU6Jr-0005p9-Ds
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:21:27 +0000
X-Inumbo-ID: 58e29ec4-8acc-11ea-9a1c-12813bfff9fa
Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 58e29ec4-8acc-11ea-9a1c-12813bfff9fa;
 Thu, 30 Apr 2020 10:21:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588242086;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=ggJ/mzOxAnjp3smHakokm7L1fh4d18CLf092ECK0ntk=;
 b=KEFW1kEJby8enjkNxbCaln3EC1Aqt5CPHMLu+I86YP8RqkJBcetg/9LB
 DXNkSut6ZlYkIh56Pp4Wj34aIsln1hZQxKbymrZdKtbdFY7dbnU0NTxzD
 8EprfCt7C0wiHnN7ZRBKHw9y47XJDNw0+SSc2Olu03NT3FasMR21cgawe w=;
Authentication-Results: esa2.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 5SKjl5jiAYZDwY6PORGaIVkQ9c5POU2fDN0Jr7Su/DnvJ/Nga0hv0Z5lQB1mz2bgX1BP9Gr4y/
 I+dCxo56uY1cujUy+w/HJcnnWgpcYvjvqqMc8ElTLfYAbuxHJ/ZkJcTTTszhQpr7hh6/d6O1B/
 8rDEw5WyfPimsDBOISyp9GMbLisv6veMTPh2RM/a6ha6oJqPWZg6y9nMXSziAxf9h0ga//5FTC
 ShE8krNDfysHnxGOM1p/yJXqx5eHWUYv4mvnsYhQladWqvhqlWqXbZFTPr4NmaR23KIegZ7tT3
 I0o=
X-SBRS: 2.7
X-MesageID: 16509521
X-Ironport-Server: esa2.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,334,1583211600"; d="scan'208";a="16509521"
Date: Thu, 30 Apr 2020 12:21:18 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Wei Liu <wl@xen.org>
Subject: Re: [PATCH] x86/hyperv: stash and use the configured max VP index
Message-ID: <20200430102118.GB28601@Air-de-Roger>
References: <20200429104144.17816-1-liuwe@microsoft.com>
 <20200429114718.zclpy6r6sbxuo6ph@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>
 <20200430101558.GA28601@Air-de-Roger>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200430101558.GA28601@Air-de-Roger>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <liuwe@microsoft.com>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Michael Kelley <mikelley@microsoft.com>, Jan Beulich <jbeulich@suse.com>,
 Xen Development List <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 12:15:58PM +0200, Roger Pau Monné wrote:
> On Wed, Apr 29, 2020 at 11:47:18AM +0000, Wei Liu wrote:
> > On Wed, Apr 29, 2020 at 11:41:44AM +0100, Wei Liu wrote:
> > > The value returned from CPUID is the maximum number for virtual
> > > processors supported by Hyper-V. It could be larger than the maximum
> > > number of virtual processors configured.
> > > 
> > > Stash the configured number into a variable and use it in calculations.
> > > 
> > > Signed-off-by: Wei Liu <liuwe@microsoft.com>
> > > ---
> > >  xen/arch/x86/guest/hyperv/hyperv.c  | 4 ++++
> > >  xen/arch/x86/guest/hyperv/private.h | 1 +
> > >  xen/arch/x86/guest/hyperv/tlb.c     | 2 +-
> > >  xen/arch/x86/guest/hyperv/util.c    | 2 +-
> > >  4 files changed, 7 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c
> > > index 91a6782cd986..84221b751453 100644
> > > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > > @@ -33,6 +33,7 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
> > >  DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
> > >  DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
> > >  
> > > +unsigned int __read_mostly hv_max_vp_index;
> > >  static bool __read_mostly hcall_page_ready;
> > >  
> > >  static uint64_t generate_guest_id(void)
> > > @@ -143,6 +144,9 @@ static int setup_hypercall_pcpu_arg(void)
> > >      rdmsrl(HV_X64_MSR_VP_INDEX, vp_index_msr);
> > >      this_cpu(hv_vp_index) = vp_index_msr;
> > >  
> > > +    if ( vp_index_msr > hv_max_vp_index )
> > > +        hv_max_vp_index = vp_index_msr;
> > > +
> > >      return 0;
> > >  }
> > >  
> > > diff --git a/xen/arch/x86/guest/hyperv/private.h b/xen/arch/x86/guest/hyperv/private.h
> > > index 354fc7f685a7..fea3e291e944 100644
> > > --- a/xen/arch/x86/guest/hyperv/private.h
> > > +++ b/xen/arch/x86/guest/hyperv/private.h
> > > @@ -28,6 +28,7 @@
> > >  DECLARE_PER_CPU(void *, hv_input_page);
> > >  DECLARE_PER_CPU(void *, hv_vp_assist);
> > >  DECLARE_PER_CPU(unsigned int, hv_vp_index);
> > > +extern unsigned int hv_max_vp_index;
> > >  
> > >  static inline unsigned int hv_vp_index(unsigned int cpu)
> > >  {
> > > diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
> > > index 1d723d6ee679..0a44071481bd 100644
> > > --- a/xen/arch/x86/guest/hyperv/tlb.c
> > > +++ b/xen/arch/x86/guest/hyperv/tlb.c
> > > @@ -166,7 +166,7 @@ int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
> > >          {
> > >              unsigned int vpid = hv_vp_index(cpu);
> > >  
> > > -            if ( vpid >= ms_hyperv.max_vp_index )
> > > +            if ( vpid >= hv_max_vp_index )
> > 
> > I think the >= should be changed to > here.
> 
> I agree. With this fixed:
> 
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

FWIW, I think it should also be nice to add an ASSERT_UNREACHABLE in
the if body, as now it shouldn't be possible for vpid to be greater
than hv_max_vp_index unless something has gone really wrong?

Roger.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:24:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6Mh-0005xQ-Fp; Thu, 30 Apr 2020 10:24:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU6Mg-0005xL-Fv
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:24:22 +0000
X-Inumbo-ID: c194a3ae-8acc-11ea-9a1c-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c194a3ae-8acc-11ea-9a1c-12813bfff9fa;
 Thu, 30 Apr 2020 10:24:21 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0297FAC8F;
 Thu, 30 Apr 2020 10:24:19 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86/HyperV: correct hv_hcall_page for xen.efi build
Message-ID: <c45d6098-a4e1-b565-4180-cc6da433dc57@suse.com>
Date: Thu, 30 Apr 2020 12:24:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Paul Durrant <paul@xen.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Along the lines of what the not reverted part of 3c4b2eef4941 ("x86:
refine link time stub area related assertion") did, we need to transform
the absolute HV_HCALL_PAGE into the image base relative hv_hcall_page
(or else there'd be no need for two distinct symbols). Otherwise
mkreloc, as used for generating the base relocations of xen.efi, will
spit out warnings like "Difference at .text:0009b74f is 0xc0000000
(expected 0x40000000)". As long as the offending relocations are PC
relative ones, the generated binary is correct afaict, but if there ever
was the absolute address stored, xen.efi would miss a fixup for it.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Build tested only (and generated binary inspected) - Wei, please check
that this doesn't break things.

--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -327,7 +327,7 @@ SECTIONS
 #endif
 
 #ifdef CONFIG_HYPERV_GUEST
-  hv_hcall_page = ABSOLUTE(HV_HCALL_PAGE);
+  hv_hcall_page = ABSOLUTE(HV_HCALL_PAGE - XEN_VIRT_START + __XEN_VIRT_START);
 #endif
 
   /* Sections to be discarded */


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:25:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6NJ-00060G-PL; Thu, 30 Apr 2020 10:25:01 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU6NI-000604-3x
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:25:00 +0000
X-Inumbo-ID: d790ebd6-8acc-11ea-9a1c-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id d790ebd6-8acc-11ea-9a1c-12813bfff9fa;
 Thu, 30 Apr 2020 10:24:58 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 0C697AC5B;
 Thu, 30 Apr 2020 10:24:56 +0000 (UTC)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86/EFI: correct section offsets in mkreloc diagnostics
Message-ID: <5708d246-694a-424f-0998-261f26ccd118@suse.com>
Date: Thu, 30 Apr 2020 12:24:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

These are more helpful if they point at the address where the relocated
value starts, rather than at the specific byte of the difference.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/efi/mkreloc.c
+++ b/xen/arch/x86/efi/mkreloc.c
@@ -238,7 +238,7 @@ static void diff_sections(const unsigned
             fprintf(stderr,
                     "Difference at %.8s:%08" PRIxFAST32 " is %#" PRIxFAST64
                     " (expected %#" PRIxFAST64 ")\n",
-                    sec->name, i, delta, diff);
+                    sec->name, i - disp, delta, diff);
             continue;
         }
         if ( width == 8 && (val1.u64 < base || val1.u64 > end) )
@@ -263,14 +263,14 @@ static void diff_sections(const unsigned
         {
             fprintf(stderr,
                     "Cannot handle decreasing RVA (at %.8s:%08" PRIxFAST32 ")\n",
-                    sec->name, i);
+                    sec->name, i - disp);
             exit(3);
         }
 
         if ( !(sec->flags & COFF_SECTION_WRITEABLE) )
             fprintf(stderr,
                     "Warning: relocation to r/o section %.8s:%08" PRIxFAST32 "\n",
-                    sec->name, i);
+                    sec->name, i - disp);
 
         printf("\t.word (%u << 12) | 0x%03" PRIxFAST32 "\n",
                reloc, sec->rva + i - disp - rva);


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:29:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:29:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6Rv-0006D3-BC; Thu, 30 Apr 2020 10:29:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jU6Ru-0006Cy-2J
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:29:46 +0000
X-Inumbo-ID: 82c08520-8acd-11ea-9a1d-12813bfff9fa
Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id 82c08520-8acd-11ea-9a1d-12813bfff9fa;
 Thu, 30 Apr 2020 10:29:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588242585;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:
 content-transfer-encoding:content-transfer-encoding;
 bh=F00GW0IDxO2YtXf8I1Htd7Li0LSvuJyIHlJhh9ba9cc=;
 b=ET/HEcMaPnnU8Ikjs61jZltkM1jseyY3c45PGlU7miJREHCpkXXQLaY03Qe9vKzx/vNlZE
 eKvP6zLAHOsdyXX/QZKFc24fU77NAjotl1JoCYIApC469dlGO4tppelP/N8c24f7OyH2V1
 H3WFLVSoOOPwCGabrnnBfqff3BfwSUU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-319-F5xrMv_8M0upE38nqrJ6fA-1; Thu, 30 Apr 2020 06:29:37 -0400
X-MC-Unique: F5xrMv_8M0upE38nqrJ6fA-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com
 [10.5.11.15])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0BD301899521;
 Thu, 30 Apr 2020 10:29:32 +0000 (UTC)
Received: from t480s.redhat.com (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 963F15D780;
 Thu, 30 Apr 2020 10:29:16 +0000 (UTC)
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/3] mm/memory_hotplug: Allow to not create firmware memmap
 entries
Date: Thu, 30 Apr 2020 12:29:05 +0200
Message-Id: <20200430102908.10107-1-david@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: linux-hyperv@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
 "Michael S . Tsirkin" <mst@redhat.com>,
 Benjamin Herrenschmidt <benh@kernel.crashing.org>,
 Jason Wang <jasowang@redhat.com>, Dave Hansen <dave.hansen@linux.intel.com>,
 Heiko Carstens <heiko.carstens@de.ibm.com>, Pingfan Liu <kernelfans@gmail.com>,
 virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
 Paul Mackerras <paulus@samba.org>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Dan Williams <dan.j.williams@intel.com>, virtio-dev@lists.oasis-open.org,
 Wei Liu <wei.liu@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Dave Jiang <dave.jiang@intel.com>, Baoquan He <bhe@redhat.com>,
 linux-nvdimm@lists.01.org, Michael Ellerman <mpe@ellerman.id.au>,
 David Hildenbrand <david@redhat.com>, linux-acpi@vger.kernel.org,
 Wei Yang <richard.weiyang@gmail.com>, xen-devel@lists.xenproject.org,
 Len Brown <lenb@kernel.org>, Nathan Lynch <nathanl@linux.ibm.com>,
 Stephen Hemminger <sthemmin@microsoft.com>,
 Pavel Tatashin <pasha.tatashin@soleen.com>, Vasily Gorbik <gor@linux.ibm.com>,
 linux-s390@vger.kernel.org, Haiyang Zhang <haiyangz@microsoft.com>,
 Leonardo Bras <leobras.c@gmail.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, Michal Hocko <mhocko@kernel.org>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Oscar Salvador <osalvador@suse.de>, Juergen Gross <jgross@suse.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "Rafael J. Wysocki" <rjw@rjwysocki.net>, Thomas Gleixner <tglx@linutronix.de>,
 Eric Biederman <ebiederm@xmission.com>,
 Vishal Verma <vishal.l.verma@intel.com>,
 Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

This is the follow up of [1]:
	[PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with
	kexec-tools

I realized that this is not only helpful for virtio-mem, but also for
dax/kmem - it's a fix for that use case (see patch #3) of persistent
memory.

Also, while testing, I discovered that kexec-tools will *not* add dax/kme=
m
memory (anything not directly under the root when parsing /proc/iomem) to
the elfcorehdr, so this memory will never get included in a dump. This
probably has to be fixed in kexec-tools - virtio-mem will require this as
well.

v1 -> v2:
- Don't change the resource name
- Rename the flag to MHP_NO_FIRMWARE_MEMMAP to reflect what it is doing
- Rephrase subjects/descriptions
- Use the flag for dax/kmem

I'll have to rebase virtio-mem on these changes, there will be a resend.

[1] https://lkml.kernel.org/r/20200429160803.109056-1-david@redhat.com

David Hildenbrand (3):
  mm/memory_hotplug: Prepare passing flags to add_memory() and friends
  mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
  device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP

 arch/powerpc/platforms/powernv/memtrace.c       |  2 +-
 arch/powerpc/platforms/pseries/hotplug-memory.c |  2 +-
 drivers/acpi/acpi_memhotplug.c                  |  2 +-
 drivers/base/memory.c                           |  2 +-
 drivers/dax/kmem.c                              |  3 ++-
 drivers/hv/hv_balloon.c                         |  2 +-
 drivers/s390/char/sclp_cmd.c                    |  2 +-
 drivers/xen/balloon.c                           |  2 +-
 include/linux/memory_hotplug.h                  | 15 ++++++++++++---
 mm/memory_hotplug.c                             | 14 ++++++++------
 10 files changed, 29 insertions(+), 17 deletions(-)

--=20
2.25.3



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:29:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:29:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6S2-0006Db-JQ; Thu, 30 Apr 2020 10:29:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jU6S1-0006DG-F7
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:29:53 +0000
X-Inumbo-ID: 86aa3276-8acd-11ea-ae69-bc764e2007e4
Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 86aa3276-8acd-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 10:29:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588242591;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=SZ5IMSF8ZkjNCkTQzjTv952CxqGeCi/XaPtFmGo7H8U=;
 b=fm39ePLNVN1RuPVswXNCmUj7p06bS1/kxRMLGUuq9/cIB6i/h9JjD34LG3b/pJuhEHf5/7
 r6redKOruVYad9KUaLG6RdMovt51NVUQlG1s6QUBwsO0Cju6+FTsqa7e3kIySuN458STLv
 smKwi2Qq0ez3rV9LoJ34ytMxgMEilAw=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-431-WETd19g0OlqD5GCQnge_oQ-1; Thu, 30 Apr 2020 06:29:44 -0400
X-MC-Unique: WETd19g0OlqD5GCQnge_oQ-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com
 [10.5.11.15])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6843A100CCC1;
 Thu, 30 Apr 2020 10:29:40 +0000 (UTC)
Received: from t480s.redhat.com (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 591C45EDEE;
 Thu, 30 Apr 2020 10:29:32 +0000 (UTC)
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH v2 1/3] mm/memory_hotplug: Prepare passing flags to
 add_memory() and friends
Date: Thu, 30 Apr 2020 12:29:06 +0200
Message-Id: <20200430102908.10107-2-david@redhat.com>
In-Reply-To: <20200430102908.10107-1-david@redhat.com>
References: <20200430102908.10107-1-david@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: linux-hyperv@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
 "Michael S . Tsirkin" <mst@redhat.com>,
 Benjamin Herrenschmidt <benh@kernel.crashing.org>,
 Jason Wang <jasowang@redhat.com>, Heiko Carstens <heiko.carstens@de.ibm.com>,
 Pingfan Liu <kernelfans@gmail.com>, virtualization@lists.linux-foundation.org,
 linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
 "K. Y. Srinivasan" <kys@microsoft.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, virtio-dev@lists.oasis-open.org,
 Wei Liu <wei.liu@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Dave Jiang <dave.jiang@intel.com>, Baoquan He <bhe@redhat.com>,
 linux-nvdimm@lists.01.org, Vishal Verma <vishal.l.verma@intel.com>,
 David Hildenbrand <david@redhat.com>, linux-acpi@vger.kernel.org,
 Wei Yang <richard.weiyang@gmail.com>, xen-devel@lists.xenproject.org,
 Len Brown <lenb@kernel.org>, Nathan Lynch <nathanl@linux.ibm.com>,
 Vasily Gorbik <gor@linux.ibm.com>, linux-s390@vger.kernel.org,
 Haiyang Zhang <haiyangz@microsoft.com>, Leonardo Bras <leobras.c@gmail.com>,
 Stephen Hemminger <sthemmin@microsoft.com>,
 Dan Williams <dan.j.williams@intel.com>, Michal Hocko <mhocko@kernel.org>,
 Christian Borntraeger <borntraeger@de.ibm.com>,
 Oscar Salvador <osalvador@suse.de>, Juergen Gross <jgross@suse.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "Rafael J. Wysocki" <rjw@rjwysocki.net>, Thomas Gleixner <tglx@linutronix.de>,
 Eric Biederman <ebiederm@xmission.com>, Michael Ellerman <mpe@ellerman.id.au>,
 Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We soon want to pass flags - prepare for that.

This patch is based on a similar patch by Oscar Salvador:

https://lkml.kernel.org/r/20190625075227.15193-3-osalvador@suse.de

Acked-by: Wei Liu <wei.liu@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Leonardo Bras <leobras.c@gmail.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-nvdimm@lists.01.org
Cc: linux-hyperv@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 arch/powerpc/platforms/powernv/memtrace.c       |  2 +-
 arch/powerpc/platforms/pseries/hotplug-memory.c |  2 +-
 drivers/acpi/acpi_memhotplug.c                  |  2 +-
 drivers/base/memory.c                           |  2 +-
 drivers/dax/kmem.c                              |  2 +-
 drivers/hv/hv_balloon.c                         |  2 +-
 drivers/s390/char/sclp_cmd.c                    |  2 +-
 drivers/xen/balloon.c                           |  2 +-
 include/linux/memory_hotplug.h                  |  7 ++++---
 mm/memory_hotplug.c                             | 11 ++++++-----
 10 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/pla=
tforms/powernv/memtrace.c
index 13b369d2cc45..a7475d18c671 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -224,7 +224,7 @@ static int memtrace_online(void)
 			ent->mem =3D 0;
 		}
=20
-		if (add_memory(ent->nid, ent->start, ent->size)) {
+		if (add_memory(ent->nid, ent->start, ent->size, 0)) {
 			pr_err("Failed to add trace memory to node %d\n",
 				ent->nid);
 			ret +=3D 1;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/power=
pc/platforms/pseries/hotplug-memory.c
index 5ace2f9a277e..ae44eba46ca0 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -646,7 +646,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
 	block_sz =3D memory_block_size_bytes();
=20
 	/* Add the memory */
-	rc =3D __add_memory(lmb->nid, lmb->base_addr, block_sz);
+	rc =3D __add_memory(lmb->nid, lmb->base_addr, block_sz, 0);
 	if (rc) {
 		invalidate_lmb_associativity_index(lmb);
 		return rc;
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplu=
g.c
index e294f44a7850..d91b3584d4b2 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -207,7 +207,7 @@ static int acpi_memory_enable_device(struct acpi_memo=
ry_device *mem_device)
 		if (node < 0)
 			node =3D memory_add_physaddr_to_nid(info->start_addr);
=20
-		result =3D __add_memory(node, info->start_addr, info->length);
+		result =3D __add_memory(node, info->start_addr, info->length, 0);
=20
 		/*
 		 * If the memory block has been used by the kernel, add_memory()
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 2b09b68b9f78..c0ef7d9e310a 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -432,7 +432,7 @@ static ssize_t probe_store(struct device *dev, struct=
 device_attribute *attr,
=20
 	nid =3D memory_add_physaddr_to_nid(phys_addr);
 	ret =3D __add_memory(nid, phys_addr,
-			   MIN_MEMORY_BLOCK_SIZE * sections_per_block);
+			   MIN_MEMORY_BLOCK_SIZE * sections_per_block, 0);
=20
 	if (ret)
 		goto out;
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 3d0a7e702c94..e159184e0ba0 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -65,7 +65,7 @@ int dev_dax_kmem_probe(struct device *dev)
 	new_res->flags =3D IORESOURCE_SYSTEM_RAM;
 	new_res->name =3D dev_name(dev);
=20
-	rc =3D add_memory(numa_node, new_res->start, resource_size(new_res));
+	rc =3D add_memory(numa_node, new_res->start, resource_size(new_res), 0)=
;
 	if (rc) {
 		release_resource(new_res);
 		kfree(new_res);
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 32e3bc0aa665..0194bed1a573 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -726,7 +726,7 @@ static void hv_mem_hot_add(unsigned long start, unsig=
ned long size,
=20
 		nid =3D memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
 		ret =3D add_memory(nid, PFN_PHYS((start_pfn)),
-				(HA_CHUNK << PAGE_SHIFT));
+				(HA_CHUNK << PAGE_SHIFT), 0);
=20
 		if (ret) {
 			pr_err("hot_add memory failed error is %d\n", ret);
diff --git a/drivers/s390/char/sclp_cmd.c b/drivers/s390/char/sclp_cmd.c
index a864b21af602..a6a908244c74 100644
--- a/drivers/s390/char/sclp_cmd.c
+++ b/drivers/s390/char/sclp_cmd.c
@@ -406,7 +406,7 @@ static void __init add_memory_merged(u16 rn)
 	if (!size)
 		goto skip_add;
 	for (addr =3D start; addr < start + size; addr +=3D block_size)
-		add_memory(0, addr, block_size);
+		add_memory(0, addr, block_size, 0);
 skip_add:
 	first_rn =3D rn;
 	num =3D 1;
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 0c142bcab79d..6ec0373fa624 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -347,7 +347,7 @@ static enum bp_state reserve_additional_memory(void)
 	mutex_unlock(&balloon_mutex);
 	/* add_memory_resource() requires the device_hotplug lock */
 	lock_device_hotplug();
-	rc =3D add_memory_resource(nid, resource);
+	rc =3D add_memory_resource(nid, resource, 0);
 	unlock_device_hotplug();
 	mutex_lock(&balloon_mutex);
=20
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplu=
g.h
index 7dca9cd6076b..0151fb935c09 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -339,9 +339,10 @@ extern void set_zone_contiguous(struct zone *zone);
 extern void clear_zone_contiguous(struct zone *zone);
=20
 extern void __ref free_area_init_core_hotplug(int nid);
-extern int __add_memory(int nid, u64 start, u64 size);
-extern int add_memory(int nid, u64 start, u64 size);
-extern int add_memory_resource(int nid, struct resource *resource);
+extern int __add_memory(int nid, u64 start, u64 size, unsigned long flag=
s);
+extern int add_memory(int nid, u64 start, u64 size, unsigned long flags)=
;
+extern int add_memory_resource(int nid, struct resource *resource,
+			       unsigned long flags);
 extern void move_pfn_range_to_zone(struct zone *zone, unsigned long star=
t_pfn,
 		unsigned long nr_pages, struct vmem_altmap *altmap);
 extern void remove_pfn_range_from_zone(struct zone *zone,
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 555137bd0882..c01be92693e3 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1004,7 +1004,8 @@ static int online_memory_block(struct memory_block =
*mem, void *arg)
  *
  * we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLU=
G
  */
-int __ref add_memory_resource(int nid, struct resource *res)
+int __ref add_memory_resource(int nid, struct resource *res,
+			      unsigned long flags)
 {
 	struct mhp_params params =3D { .pgprot =3D PAGE_KERNEL };
 	u64 start, size;
@@ -1082,7 +1083,7 @@ int __ref add_memory_resource(int nid, struct resou=
rce *res)
 }
=20
 /* requires device_hotplug_lock, see add_memory_resource() */
-int __ref __add_memory(int nid, u64 start, u64 size)
+int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags=
)
 {
 	struct resource *res;
 	int ret;
@@ -1091,18 +1092,18 @@ int __ref __add_memory(int nid, u64 start, u64 si=
ze)
 	if (IS_ERR(res))
 		return PTR_ERR(res);
=20
-	ret =3D add_memory_resource(nid, res);
+	ret =3D add_memory_resource(nid, res, flags);
 	if (ret < 0)
 		release_memory_resource(res);
 	return ret;
 }
=20
-int add_memory(int nid, u64 start, u64 size)
+int add_memory(int nid, u64 start, u64 size, unsigned long flags)
 {
 	int rc;
=20
 	lock_device_hotplug();
-	rc =3D __add_memory(nid, start, size);
+	rc =3D __add_memory(nid, start, size, flags);
 	unlock_device_hotplug();
=20
 	return rc;
--=20
2.25.3



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:29:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:29:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6S7-0006F8-0t; Thu, 30 Apr 2020 10:29:59 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jU6S6-0006Ex-Ax
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:29:58 +0000
X-Inumbo-ID: 882ef636-8acd-11ea-b07b-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 882ef636-8acd-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 10:29:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588242594;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=cBxdneYzv1oFt6rUtmxHP8L8tmn6FMG5Rn0MO+hCbf0=;
 b=JgnBcs7KbVtrO7Y5XfXBFfSQ+NrjRi8mdy5Cr5AYJ+OR4F9XWVZhy+DVTG3KrWbLdA9f/W
 AE5Ax6d9xrMiHXyk++HbDJzk88SljTr7qQpELHA22vggLAR1Z5u6neaCXRulDFOFU0OktS
 bNjc7fOsnXDTZ/hgIM25m0vmQuSgup8=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-323-ZkDsTUQ-OxW7sjqOoV_anw-1; Thu, 30 Apr 2020 06:29:51 -0400
X-MC-Unique: ZkDsTUQ-OxW7sjqOoV_anw-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com
 [10.5.11.15])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 920BB45F;
 Thu, 30 Apr 2020 10:29:49 +0000 (UTC)
Received: from t480s.redhat.com (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id B43035EDEB;
 Thu, 30 Apr 2020 10:29:40 +0000 (UTC)
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 12:29:07 +0200
Message-Id: <20200430102908.10107-3-david@redhat.com>
In-Reply-To: <20200430102908.10107-1-david@redhat.com>
References: <20200430102908.10107-1-david@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, linux-acpi@vger.kernel.org,
 Baoquan He <bhe@redhat.com>, linux-nvdimm@lists.01.org,
 linux-s390@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 David Hildenbrand <david@redhat.com>,
 virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
 Wei Yang <richard.weiyang@gmail.com>, Eric Biederman <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Some devices/drivers that add memory via add_memory() and friends (e.g.,
dax/kmem, but also virtio-mem in the future) don't want to create entries
in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
memory to the boot memmap of the kexec kernel.

In fact, such memory is never exposed via the firmware memmap as System
RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
wrong:
 "kexec needs the raw firmware-provided memory map to setup the
  parameter segment of the kernel that should be booted with
  kexec. Also, the raw memory map is useful for debugging. For
  that reason, /sys/firmware/memmap is an interface that provides
  the raw memory map to userspace." [1]

We don't have to worry about firmware_map_remove() on the removal path.
If there is no entry, it will simply return with -EINVAL.

[1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-m=
emmap

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 include/linux/memory_hotplug.h | 8 ++++++++
 mm/memory_hotplug.c            | 3 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplu=
g.h
index 0151fb935c09..4ca418a731eb 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -68,6 +68,14 @@ struct mhp_params {
 	pgprot_t pgprot;
 };
=20
+/* Flags used for add_memory() and friends. */
+
+/*
+ * Don't create entries in /sys/firmware/memmap/. The memory is detected=
 and
+ * added via a device driver, not via the initial (firmware) memmap.
+ */
+#define MHP_NO_FIRMWARE_MEMMAP		1
+
 /*
  * Zone resizing functions
  *
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c01be92693e3..e94ede9cad00 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resou=
rce *res,
 	BUG_ON(ret);
=20
 	/* create new memmap entry */
-	firmware_map_add_hotplug(start, start + size, "System RAM");
+	if (!(flags & MHP_NO_FIRMWARE_MEMMAP))
+		firmware_map_add_hotplug(start, start + size, "System RAM");
=20
 	/* device_online() will take the lock when calling online_pages() */
 	mem_hotplug_done();
--=20
2.25.3



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:30:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6SC-0006Tr-9a; Thu, 30 Apr 2020 10:30:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jU6SB-0006Oi-B4
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:30:03 +0000
X-Inumbo-ID: 8be0b594-8acd-11ea-ae69-bc764e2007e4
Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 8be0b594-8acd-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 10:30:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588242600;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=+3PNEjodfSmVCKHuEI1uD9BcIkwvNKm68jAUXOCtpHs=;
 b=eJdl+5kSxklF6hY4hhpJgJ5wBqUY+iieKDyUMx+o0m74fIv7Qe4OBqEa/qyIw2TcTwQgmO
 pdUfpm+ipjSWIQCN+pXan0W3gohsbMPr0+bP6wu02FhT7uqqqVp3SMFAFy3EC4L2JxZjog
 0ydh85w5oPR2slQ2l8kE5GcHIMP9PqE=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-276-WVVkTXmBNpi7HsRCgZds0w-1; Thu, 30 Apr 2020 06:29:56 -0400
X-MC-Unique: WVVkTXmBNpi7HsRCgZds0w-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com
 [10.5.11.15])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E3AB28015D1;
 Thu, 30 Apr 2020 10:29:53 +0000 (UTC)
Received: from t480s.redhat.com (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id E14155EDEE;
 Thu, 30 Apr 2020 10:29:49 +0000 (UTC)
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with
 MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 12:29:08 +0200
Message-Id: <20200430102908.10107-4-david@redhat.com>
In-Reply-To: <20200430102908.10107-1-david@redhat.com>
References: <20200430102908.10107-1-david@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, linux-acpi@vger.kernel.org,
 Baoquan He <bhe@redhat.com>, linux-nvdimm@lists.01.org,
 linux-s390@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 David Hildenbrand <david@redhat.com>,
 Dave Hansen <dave.hansen@linux.intel.com>,
 virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
 Wei Yang <richard.weiyang@gmail.com>, Eric Biederman <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org, Dan Williams <dan.j.williams@intel.com>,
 Pavel Tatashin <pasha.tatashin@soleen.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Currently, when adding memory, we create entries in /sys/firmware/memmap/
as "System RAM". This does not reflect the reality and will lead to
kexec-tools to add that memory to the fixed-up initial memmap for a
kexec kernel (loaded via kexec_load()). The memory will be considered
initial System RAM by the kexec kernel.

We should let the kexec kernel decide how to use that memory - just as
we do during an ordinary reboot.

Before configuring the namespace:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-33fffffff : namespace0.0
	3280000000-32ffffffff : PCI Bus 0000:00

After configuring the namespace:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  148200000-33fffffff : dax0.0
	3280000000-32ffffffff : PCI Bus 0000:00

After loading kmem:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  150000000-33fffffff : dax0.0
	    150000000-33fffffff : System RAM
	3280000000-32ffffffff : PCI Bus 0000:00

After a proper reboot:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  148200000-33fffffff : dax0.0
	3280000000-32ffffffff : PCI Bus 0000:00

Within the kexec kernel before this change:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  150000000-33fffffff : System RAM
	3280000000-32ffffffff : PCI Bus 0000:00

Within the kexec kernel after this change:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  148200000-33fffffff : dax0.0
	3280000000-32ffffffff : PCI Bus 0000:00

/sys/firmware/memmap/ before this change:
	0000000000000000-000000000009fc00 (System RAM)
	000000000009fc00-00000000000a0000 (Reserved)
	00000000000f0000-0000000000100000 (Reserved)
	0000000000100000-00000000bffdf000 (System RAM)
	00000000bffdf000-00000000c0000000 (Reserved)
	00000000feffc000-00000000ff000000 (Reserved)
	00000000fffc0000-0000000100000000 (Reserved)
	0000000100000000-0000000140000000 (System RAM)
	0000000150000000-0000000340000000 (System RAM)

/sys/firmware/memmap/ after a proper reboot:
	0000000000000000-000000000009fc00 (System RAM)
	000000000009fc00-00000000000a0000 (Reserved)
	00000000000f0000-0000000000100000 (Reserved)
	0000000000100000-00000000bffdf000 (System RAM)
	00000000bffdf000-00000000c0000000 (Reserved)
	00000000feffc000-00000000ff000000 (Reserved)
	00000000fffc0000-0000000100000000 (Reserved)
	0000000100000000-0000000140000000 (System RAM)

/sys/firmware/memmap/ after this change:
	0000000000000000-000000000009fc00 (System RAM)
	000000000009fc00-00000000000a0000 (Reserved)
	00000000000f0000-0000000000100000 (Reserved)
	0000000000100000-00000000bffdf000 (System RAM)
	00000000bffdf000-00000000c0000000 (Reserved)
	00000000feffc000-00000000ff000000 (Reserved)
	00000000fffc0000-0000000100000000 (Reserved)
	0000000100000000-0000000140000000 (System RAM)

kexec-tools already seem to basically ignore any System RAM that's not
on top level when searching for areas to place kexec images - but also
for determining crash areas to dump via kdump. This behavior is not
changed by this patch. kexec-tools probably has to be fixed to also
include this memory in system dumps.

Note: kexec_file_load() does the right thing already within the kernel.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 drivers/dax/kmem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index e159184e0ba0..929823a79816 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -65,7 +65,8 @@ int dev_dax_kmem_probe(struct device *dev)
 	new_res->flags =3D IORESOURCE_SYSTEM_RAM;
 	new_res->name =3D dev_name(dev);
=20
-	rc =3D add_memory(numa_node, new_res->start, resource_size(new_res), 0)=
;
+	rc =3D add_memory(numa_node, new_res->start, resource_size(new_res),
+			MHP_NO_FIRMWARE_MEMMAP);
 	if (rc) {
 		release_resource(new_res);
 		kfree(new_res);
--=20
2.25.3



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:35:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6Xe-0007Jk-Vl; Thu, 30 Apr 2020 10:35:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/gX9=6O=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jU6Xd-0007Jf-3n
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:35:41 +0000
X-Inumbo-ID: 54ea7ec1-8ace-11ea-9a1f-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 54ea7ec1-8ace-11ea-9a1f-12813bfff9fa;
 Thu, 30 Apr 2020 10:35:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588242939;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=b1jSX8WWP+O6RhMgYTtNX8VYzmI+wHx5nFiZBRwR9wM=;
 b=PuYvAsV3tlkTcXhOLHMpBD2SGdfaftJl+w+sq/hAVbcq2voiDHNdJhdF
 UFuh1QLlaC2GMK9iYC3XQFcSGxx+5pI5vGLOq5dXiN7r28xHxFuZqJ0Ct
 EIPWirBQXvNII6dMrzKkaEqXEisNW6VSfRF4RTijcTo4EoZmfycl2zl5N E=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 9wmQUI7Y/J/JVVHT7l3vKSy8QgErDhWuxyOM1ujkpOdAvgL+HCJYegi5obES0wmAfSUJmOJlqW
 QTW5ZUv93d9v2FgdxYFJYmGmMcmv31xikBzFBYV2nbzsnpAcVL4LktTZblrr+mWv3MpvSGATZe
 s5cef8nQY8d1ScCd4g+LORcO95ru8mjYTRW48TRM+p1k8ddyjvbSzKbNmzAkLDBpkGDVfYsyxB
 zExCLQGealL72UdvBiWgHnTBn/aH/uCKe1w0+6tUQcbnZCyChngxKD3fI4qZ7Z0+BTU6ogMtS7
 PvM=
X-SBRS: 2.7
X-MesageID: 16483360
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,334,1583211600"; d="scan'208";a="16483360"
Date: Thu, 30 Apr 2020 12:35:28 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/amd: Initial support for Fam19h processors
Message-ID: <20200430103528.GC28601@Air-de-Roger>
References: <20200430095947.31958-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20200430095947.31958-1-andrew.cooper3@citrix.com>
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 10:59:47AM +0100, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
> index c3f92ed231..014524486f 100644
> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -398,7 +398,7 @@ void setup_apic_nmi_watchdog(void)
>      case X86_VENDOR_AMD:
>          switch (boot_cpu_data.x86) {
>          case 6:
> -        case 0xf ... 0x17:
> +        case 0xf ... 0x19:
>              setup_k7_watchdog();
>              break;
>          default:
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 0bcf554e93..33e5d21ece 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1939,7 +1939,7 @@ static unsigned int calc_ler_msr(void)
>          switch ( boot_cpu_data.x86 )
>          {
>          case 6:
> -        case 0xf ... 0x17:
> +        case 0xf ... 0x19:
>              return MSR_IA32_LASTINTFROMIP;

You seem to also add support for Fam18h here and in the chunk above,
is this intentional?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:38:21 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:38:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6aC-0007Rh-Cs; Thu, 30 Apr 2020 10:38:20 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rLHY=6O=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jU6aB-0007Ra-Fn
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:38:19 +0000
X-Inumbo-ID: b457ed70-8ace-11ea-9a1f-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b457ed70-8ace-11ea-9a1f-12813bfff9fa;
 Thu, 30 Apr 2020 10:38:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588243098;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=gcI19hGtn1GKElfxwHAkQJ9FSP2EwE2MKIynqnJ9Vo4=;
 b=H5rZxK4lnAR8ek03KGz+hwmaql76imybIL0SyNd5oFOtCZIXvDyiEN4m
 nPGKjV+q1DY1zCwgh00NePB2DLZw/7szeeaaKggUz1AUpulXHMYcyek9Z
 3qn5K3/zrTorJRLBTWEv1v4IFNdpiLYHbq92p6w2cs/MP40duDMUstDR8 8=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: t4QuuI+NpQQlk4DwrMPdz54JCBm5MvPXMvlITmRpVz8V2CxHR9eAQNUxzzDm/8qDVMMj6z4OCS
 ZS5069TqYxgPvh5Ye2eb5+853md5cNQGMa4i/OmBF1bQ3Ddz4b9VZBf4oPTHn5mK0yJPBm1Cv5
 4BB3/cfw+vXjSB+zok5lTGEltb64uQvejYGL32gKyhPyFpnnHDc5u/r3p8BornutHEviVKNsZ9
 0b1tyfRD5z2CEHRGA6FL0xLt704IEdDdniwDeRBVVnQiPTXz4z7UsJcAQ3tbmibvhT2n6xvjAs
 3Wo=
X-SBRS: 2.7
X-MesageID: 16483458
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,334,1583211600"; d="scan'208";a="16483458"
Subject: Re: [PATCH] x86/amd: Initial support for Fam19h processors
To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
References: <20200430095947.31958-1-andrew.cooper3@citrix.com>
 <20200430103528.GC28601@Air-de-Roger>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <9ae757ef-1cc4-98ef-8b68-161b0717ac22@citrix.com>
Date: Thu, 30 Apr 2020 11:38:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200430103528.GC28601@Air-de-Roger>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30/04/2020 11:35, Roger Pau Monné wrote:
> On Thu, Apr 30, 2020 at 10:59:47AM +0100, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
>> index c3f92ed231..014524486f 100644
>> --- a/xen/arch/x86/nmi.c
>> +++ b/xen/arch/x86/nmi.c
>> @@ -398,7 +398,7 @@ void setup_apic_nmi_watchdog(void)
>>      case X86_VENDOR_AMD:
>>          switch (boot_cpu_data.x86) {
>>          case 6:
>> -        case 0xf ... 0x17:
>> +        case 0xf ... 0x19:
>>              setup_k7_watchdog();
>>              break;
>>          default:
>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>> index 0bcf554e93..33e5d21ece 100644
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1939,7 +1939,7 @@ static unsigned int calc_ler_msr(void)
>>          switch ( boot_cpu_data.x86 )
>>          {
>>          case 6:
>> -        case 0xf ... 0x17:
>> +        case 0xf ... 0x19:
>>              return MSR_IA32_LASTINTFROMIP;
> You seem to also add support for Fam18h here and in the chunk above,
> is this intentional?

Yes.  Honestly, these details have never changed since the K7.  I'm
tempted to drop the family logic entirely.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 10:42:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 10:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6dq-0008DJ-UJ; Thu, 30 Apr 2020 10:42:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/gX9=6O=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jU6dq-0008DE-5h
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 10:42:06 +0000
X-Inumbo-ID: 3b71a09e-8acf-11ea-ae69-bc764e2007e4
Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3b71a09e-8acf-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 10:42:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588243325;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=uYM6bDQJzrQLgCW/7eeeoqfzMnwT9rFLZiGFOJHen4k=;
 b=b+fDGYdO6BobacvpSu5HajPCLFX+U9mGrp7QOHCB+UWmJNCyUy6Puxd1
 S8XgPzs9wUYnIzZc9eZDepmUm+AGvJ5iCi+t1LkjbtC5y7u9C71y4ec2K
 C31GctdswyIMqBdRPZo3MxIdyjXREFyZZAkTuc0GneNkWSs1ZcYgqe8RM c=;
Authentication-Results: esa6.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: 4oieARdwbP9SgqvQXcEgC0K6wiB/5KbykvgSTBZMHDkkbkY1fYiSqVAZrrFyU+WRrkzaCHm/6+
 V5Ci9a6NYMr5cOlgt4i1xe/eDKHaSYBThplA+HwMc3ZDrBZhv4V0+bMQZTyeeM7uOABA8DUhMp
 L1K4uKANdJnRzZdgYf3Vme4TP3e82aKJzudTaKyv8jHlFJN1KIBhw8u1RkWK/WqSo5uHBnasGG
 GLxnhiPiXKTsQ6EApA9oHfUhbURBvvszOswMiIe+Knzfzeel6oConb4rr950r2KxlWpqh7bowP
 MNo=
X-SBRS: 2.7
X-MesageID: 16896266
X-Ironport-Server: esa6.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,334,1583211600"; d="scan'208";a="16896266"
Date: Thu, 30 Apr 2020 12:41:58 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/amd: Initial support for Fam19h processors
Message-ID: <20200430104158.GD28601@Air-de-Roger>
References: <20200430095947.31958-1-andrew.cooper3@citrix.com>
 <20200430103528.GC28601@Air-de-Roger>
 <9ae757ef-1cc4-98ef-8b68-161b0717ac22@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9ae757ef-1cc4-98ef-8b68-161b0717ac22@citrix.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 Jan Beulich <JBeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 11:38:14AM +0100, Andrew Cooper wrote:
> On 30/04/2020 11:35, Roger Pau Monné wrote:
> > On Thu, Apr 30, 2020 at 10:59:47AM +0100, Andrew Cooper wrote:
> >> diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
> >> index c3f92ed231..014524486f 100644
> >> --- a/xen/arch/x86/nmi.c
> >> +++ b/xen/arch/x86/nmi.c
> >> @@ -398,7 +398,7 @@ void setup_apic_nmi_watchdog(void)
> >>      case X86_VENDOR_AMD:
> >>          switch (boot_cpu_data.x86) {
> >>          case 6:
> >> -        case 0xf ... 0x17:
> >> +        case 0xf ... 0x19:
> >>              setup_k7_watchdog();
> >>              break;
> >>          default:
> >> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> >> index 0bcf554e93..33e5d21ece 100644
> >> --- a/xen/arch/x86/traps.c
> >> +++ b/xen/arch/x86/traps.c
> >> @@ -1939,7 +1939,7 @@ static unsigned int calc_ler_msr(void)
> >>          switch ( boot_cpu_data.x86 )
> >>          {
> >>          case 6:
> >> -        case 0xf ... 0x17:
> >> +        case 0xf ... 0x19:
> >>              return MSR_IA32_LASTINTFROMIP;
> > You seem to also add support for Fam18h here and in the chunk above,
> > is this intentional?
> 
> Yes.  Honestly, these details have never changed since the K7.  I'm
> tempted to drop the family logic entirely.

Ack, just wanted to be sure the changes where intentional:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Re dropping the logic - as you wish.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 11:01:08 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 11:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU6w6-0001SY-MJ; Thu, 30 Apr 2020 11:00:58 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jU6w4-0001ST-OK
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 11:00:56 +0000
X-Inumbo-ID: dd608c24-8ad1-11ea-9a22-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id dd608c24-8ad1-11ea-9a22-12813bfff9fa;
 Thu, 30 Apr 2020 11:00:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=/JuMaoQK3/yKKWTgd5NYymon2SfOLFfbIdK1YvAE+to=; b=eSbXiFiq9/lU7eQee3VMboUyF1
 KH5BVzNaUwdCRQglwrjq3AsZ9XXhO8BW6CEwcE7lriPfoS3HrGwtu+5AQulIEtD0cChP7tJ8yvuGs
 qoS3tEc+v8dV7aSeLGDsxbCNXBS3R2qb0Hp1lReCvAbpkZlx9jBorvvGeEA4FKQceMHk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jU6w3-0000ut-4c; Thu, 30 Apr 2020 11:00:55 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jU6w2-0002r0-On; Thu, 30 Apr 2020 11:00:54 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH] tools/xl: vcpu-pin: Skip global affinity when the hard
 affinity is not changed
Date: Thu, 30 Apr 2020 12:00:51 +0100
Message-Id: <20200430110051.8965-1-julien@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: julien@xen.org, Wei Liu <wl@xen.org>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 Pawel Wieczorkiewicz <wipawel@amazon.de>,
 Anthony PERARD <anthony.perard@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

After XSA-273, it is not possible to modify the vCPU soft affinity using
xl vcpu-pin without modifying the hard affinity. Instead the command
will crash.

42sh> gdb /usr/local/sbin/xl
(gdb) r vcpu-pin 0 0 - 10
[...]
Program received signal SIGSEGV, Segmentation fault.
[...]
(gdb) bt

This is happening because 'xl' will use NULL when an affinity doesn't
need to be modified. However, we will still try to apply the global
affinity in the this case.

As the hard affinity is not changed, then we don't need to apply the
global affinity. So skip it when hard is NULL.

Backport: 4.6+ # Any release with XSA-273
Fixes: aa67b97ed342 ("xl.conf: Add global affinity masks")
Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 tools/xl/xl_vcpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/xl/xl_vcpu.c b/tools/xl/xl_vcpu.c
index 9ff5354f749b..66877a57dee4 100644
--- a/tools/xl/xl_vcpu.c
+++ b/tools/xl/xl_vcpu.c
@@ -283,7 +283,7 @@ int main_vcpupin(int argc, char **argv)
     }
 
     /* Only hard affinity matters here */
-    if (!ignore_masks) {
+    if (!ignore_masks && hard) {
         libxl_dominfo dominfo;
 
         if (libxl_domain_info(ctx, &dominfo, domid)) {
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 11:09:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 11:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU74W-0001g6-Ia; Thu, 30 Apr 2020 11:09:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU74U-0001g1-U7
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 11:09:38 +0000
X-Inumbo-ID: 147bf224-8ad3-11ea-9a27-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 147bf224-8ad3-11ea-9a27-12813bfff9fa;
 Thu, 30 Apr 2020 11:09:37 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 34D70AC11;
 Thu, 30 Apr 2020 11:09:36 +0000 (UTC)
Subject: Re: [PATCH] x86/amd: Initial support for Fam19h processors
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <20200430095947.31958-1-andrew.cooper3@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <471aaf7e-497f-edd2-6eb0-06d337a23538@suse.com>
Date: Thu, 30 Apr 2020 13:09:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200430095947.31958-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.2020 11:59, Andrew Cooper wrote:
> Fam19h is very similar to Fam17h in these regards.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

Nevertheless a question:

> --- a/xen/arch/x86/cpu/microcode/amd.c
> +++ b/xen/arch/x86/cpu/microcode/amd.c
> @@ -125,6 +125,7 @@ static bool_t verify_patch_size(uint32_t patch_size)
>          max_size = F16H_MPB_MAX_SIZE;
>          break;
>      case 0x17:
> +    case 0x19:
>          max_size = F17H_MPB_MAX_SIZE;
>          break;

Didn't you indicate to me the other day that the upper bound would
grow?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 11:15:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 11:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU7A6-0002U3-89; Thu, 30 Apr 2020 11:15:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=lQFv=6O=oracle.com=daniel.kiper@srs-us1.protection.inumbo.net>)
 id 1jU7A4-0002Ty-VY
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 11:15:25 +0000
X-Inumbo-ID: e2d309a0-8ad3-11ea-ae69-bc764e2007e4
Received: from userp2130.oracle.com (unknown [156.151.31.86])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id e2d309a0-8ad3-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 11:15:24 +0000 (UTC)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03UBDIlI112155;
 Thu, 30 Apr 2020 11:15:13 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=date : from : to : cc
 : subject : message-id : references : mime-version : content-type :
 in-reply-to; s=corp-2020-01-29;
 bh=UmHe1H6wPtrCHpXlVgbnEScgG23D8lHVT+O3L6FXUrg=;
 b=uRnGYT/jYknvwDMEHxo5L1MPnbt/xVFwbxZd/WNjWn4At9V+Y7iw2KbJGB/s03+sEKxz
 5X85hmmckUI92A20joYC5pUFta2vx20qMa8+uw3D/7nKnRtkZnzaRCOK4BsGEoJNdg6W
 wbj7zGbTXgcRBlj60yeoRyGGu4fzC4p0H83BKdRk/wDwICJCLUSObR2TzZ4qdo+i3yqE
 IV3UC/iPVs+3fQTR0rs5eAXNHiVk0BCG838DI+qUyLmGbkNwWkdXaRN2zPxsegLN2IUD
 HV4vgPPQcf+tDdr8PHM8KYoLebGl8UPGg2m2D8ZzCXypLdcSqDhxNLRe/ZNU6iXipXDn Lw== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2130.oracle.com with ESMTP id 30p01p1bwg-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 30 Apr 2020 11:15:12 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03UBDPDp190368;
 Thu, 30 Apr 2020 11:15:12 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userp3030.oracle.com with ESMTP id 30qtjwvg6d-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 30 Apr 2020 11:15:12 +0000
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03UBF6Z9011614;
 Thu, 30 Apr 2020 11:15:07 GMT
Received: from tomti.i.net-space.pl (/10.175.213.85)
 by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Thu, 30 Apr 2020 04:15:06 -0700
Date: Thu, 30 Apr 2020 13:15:01 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [RFC] UEFI Secure Boot on Xen Hosts
Message-ID: <20200430111501.336wte64pwsfptze@tomti.i.net-space.pl>
References: <20200429225108.GA54201@bobbye-pc>
 <ebdd7b4a-767b-1b72-a344-78b190f42ceb@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ebdd7b4a-767b-1b72-a344-78b190f42ceb@suse.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9606
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 suspectscore=0
 malwarescore=0 bulkscore=0 phishscore=0 mlxlogscore=999 mlxscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004300093
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9606
 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 spamscore=0 clxscore=1011
 phishscore=0 mlxlogscore=999 adultscore=0 priorityscore=1501 mlxscore=0
 suspectscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000
 definitions=main-2004300093
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: michal.zygowski@3mdeb.com, Bobby Eshleman <bobbyeshleman@gmail.com>,
 olivier.lambert@vates.fr, krystian.hebel@3mdeb.com,
 xen-devel@lists.xenproject.org, ardb@kernel.org, piotr.krol@3mdeb.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Adding Ard...

On Thu, Apr 30, 2020 at 09:01:45AM +0200, Jan Beulich wrote:
> On 30.04.2020 00:51, Bobby Eshleman wrote:
> > Hey all,
> >
> > We're looking to develop UEFI Secure Boot support for grub-loaded Xen and
> > ultimately for XCP-ng (I'm on the XCP-ng team at Vates).
> >
> > In addition to carrying the chain-of-trust through the entire boot sequence
> > into dom0, we would also like to build something akin to Linux's Lockdown for
> > dom0 and its privileged interfaces.
> >
> > It appears that there are various options and we'd like to discuss them with
> > the community.
> >
> > # Option #1: PE/COFF and Shim
> >
> > Shim installs a verification protocol available to subsequent programs via EFI
> > boot services.  The protocol is called SHIM_LOCK and it is currently supported
> > by xen.efi.
> >
> > Shim requires the payload under verification to be a PE/COFF executable.  In
> > order to support both shim and maintain the multiboot2 protocol, Daniel Kiper's
> > patchset [1]  (among other things) incorporates the PE/COFF header
> > into xen.gz and adds dom0 verification via SHIM_LOCK in
> > efi_multiboot2().
> >
> > There appears that some work will be needed on top of this patchset, but not
> > much as it seems most of the foot work has been done.
> >
> > AFAIK, the changes needed in GRUB for this approach are already upstream (the
> > shim_lock module is upstream), and shim would go untouched.
> >
> > # Option #2: Extended Multiboot2 and Shim
> >
> > Another approach that could be taken is to embed Xen's signature into a
> > new multiboot2 header and then modify shim to support it.  This would
> > arguably be more readable than embedding the PE/COFF header, would add
> > value to shim, and would fit nicely with the mb2 header code that
> > already exists in Xen.  The downside being that it would require a shim
> > fork.  Grub2 would be unchanged.

Here you have to change the Multiboot2 protocol and singing tools too.
So, I do not consider this as a viable solution.

> > I'm not familliar with Microsoft's signing process.  I do know they
> > support template submissions based on shim, and I'm not sure if such a
> > big change would impact their approval process.
> >
> > # Option #3: Lean on Grub2's LoadFile2() Verification
> >
> > Grub2 will provide a LoadFile2() method to subsequent programs that supports
> > signature verification of arbitrary files.  Linux is moving in the
> > direction of using LoadFile2() for loading the initrd [2], and Grub2 will
> > support verifying the signatures of files loaded via LoadFile2().  This is set
> > for release in GRUB 2.06 sometime in the latter half of 2020.

s/for release in/after release/

> > In Xen, this approach could be used for loading dom0 as well, offering a very
> > simple verified load interface.
> >
> > Currently the initrd argument passed from Linux to LoadFile2() is a vendor
> > media device path GUID [3].
> >
> > Changes to Xen:
> > - Xen would need to pass these device paths to Grub
> > - Xen would be changed to load dom0 with the LoadFile2() interface via boot services
> >
> > Changes to Grub:
> > - Xen dom0 kernel/initrd device paths would need to be introduced to Grub

Maybe partially but certainly there will be some differences...

> > Potential Issues:
> > - How will Xen handle more boot modules than just a dom0 and dom0
> >   initrd?
> > - Would each boot module need a unique vendor guid?

AIUI yes but Ard, who designed this new boot protocol, may say more
about that.

Anyway, the advantage of this new protocol is that it uses UEFI API to
load and execute PE kernel and its modules. This means that it will be
architecture independent. However, IIRC, if we want to add new modules
types to the Xen then we have to teach all bootloaders in the wild about
new GUIDs. Ard, am I correct?

> > - Would this interfere with the DomB proposal?  I suspect not because
> >   the DomB proposal suggests launching DomUs from an already booted
> >   DomB, at which point other means could be used.
> >
> > We'd just like to get the conversation going on this topic before we
> > dive too far into implementing something.  Are any of these approaches a
> > hard no for upstreaming?  Do any stand out as best candidates?  Any
> > feedback / questions / criticisms would be greatly appreciated.
>
> A shim fork doesn't look desirable, which would rule out #2 unless there
> is an option there to avoid the fork.
>
> If the potential issues listed for #3 can be suitably addressed, I can't
> currently see a reason to prefer either of the two remaining options; I
> vaguely recall though that Daniel's change for #1 didn't look overly
> appealing, but perhaps this can be taken care of.

Daniel


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 11:17:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 11:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU7CN-0002b2-Lu; Thu, 30 Apr 2020 11:17:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DLrL=6O=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jU7CM-0002ax-KC
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 11:17:46 +0000
X-Inumbo-ID: 346dcaac-8ad4-11ea-9a28-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 346dcaac-8ad4-11ea-9a28-12813bfff9fa;
 Thu, 30 Apr 2020 11:17:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=pugIXiQUo0KV3Zqqrons0PFy3ISoWn6TRWY1qYeqWPA=; b=57cbev+1iqSZGcu8RKgn9xCDb
 sr9gALnKCNBnp0BtqHz5y4/v7CF8l64PQ2E04qkYTctpOBBAJak3CIaU636ySsmLKIRyT/ei6zHx2
 eGHcEHELHddWMD4MI1402cKJcxY0EnSq10CtmxciGc63Mzbye4VscmbeEKJGpX7UbEkGU=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jU7CG-0001F1-BZ; Thu, 30 Apr 2020 11:17:40 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jU7CG-0004P5-39; Thu, 30 Apr 2020 11:17:40 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jU7CG-0000CB-2X; Thu, 30 Apr 2020 11:17:40 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149888-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 149888: tolerable all pass - PUSHED
X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=0135be8bd8cd60090298f02310691b688d95c3a8
X-Osstest-Versions-That: xen=8065e1b41688592778de76c731c62f34e71f3129
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 30 Apr 2020 11:17:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149888 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149888/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  0135be8bd8cd60090298f02310691b688d95c3a8
baseline version:
 xen                  8065e1b41688592778de76c731c62f34e71f3129

Last test of basis   149884  2020-04-29 21:02:20 Z    0 days
Testing same since   149888  2020-04-30 09:00:53 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Hongyan Xia <hongyxia@amazon.com>
  Jan Beulich <jbeulich@suse.com>
  Tamas K Lengyel <tamas.lengyel@intel.com>
  Varad Gautam <vrd@amazon.de>
  Wei Liu <wei.liu2@citrix.com>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   8065e1b416..0135be8bd8  0135be8bd8cd60090298f02310691b688d95c3a8 -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 11:24:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 11:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU7IF-0003QL-Ao; Thu, 30 Apr 2020 11:23:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qeDo=6O=intel.com=dave.hansen@srs-us1.protection.inumbo.net>)
 id 1jU7ID-0003QG-Qs
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 11:23:49 +0000
X-Inumbo-ID: 0ed7245e-8ad5-11ea-9a28-12813bfff9fa
Received: from mga06.intel.com (unknown [134.134.136.31])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0ed7245e-8ad5-11ea-9a28-12813bfff9fa;
 Thu, 30 Apr 2020 11:23:47 +0000 (UTC)
IronPort-SDR: KnI6ugwYN6dLmmWIB5xQwYCbSj/i1ksEBrfPmyWmPvSdAk3XLRMEcH4LMmU/W1OpDi4ybOfR68
 4ovn7MZdFfbg==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga006.jf.intel.com ([10.7.209.51])
 by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 30 Apr 2020 04:23:46 -0700
IronPort-SDR: SHV7wT4BPVHKAo0WmoTz8aq1kRHCx/RdPvBe0nAp3qbMO/SAPWXKmXN7i75QlP4e04SgRh2wTx
 AK59XRR1ll/g==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.73,334,1583222400"; d="scan'208";a="261745559"
Received: from isdasana-mobl1.amr.corp.intel.com (HELO [10.254.74.214])
 ([10.254.74.214])
 by orsmga006.jf.intel.com with ESMTP; 30 Apr 2020 04:23:46 -0700
Subject: Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with
 MHP_NO_FIRMWARE_MEMMAP
To: David Hildenbrand <david@redhat.com>, linux-kernel@vger.kernel.org
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-4-david@redhat.com>
From: Dave Hansen <dave.hansen@intel.com>
Autocrypt: addr=dave.hansen@intel.com; keydata=
 xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC
 oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY
 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb
 ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz
 VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W
 iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn
 c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1
 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb
 ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL
 QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzShEYXZpZCBDaHJp
 c3RvcGhlciBIYW5zZW4gPGRhdmVAc3I3MS5uZXQ+wsF7BBMBAgAlAhsDBgsJCAcDAgYVCAIJ
 CgsEFgIDAQIeAQIXgAUCTo3k0QIZAQAKCRBoNZUwcMmSsMO2D/421Xg8pimb9mPzM5N7khT0
 2MCnaGssU1T59YPE25kYdx2HntwdO0JA27Wn9xx5zYijOe6B21ufrvsyv42auCO85+oFJWfE
 K2R/IpLle09GDx5tcEmMAHX6KSxpHmGuJmUPibHVbfep2aCh9lKaDqQR07gXXWK5/yU1Dx0r
 VVFRaHTasp9fZ9AmY4K9/BSA3VkQ8v3OrxNty3OdsrmTTzO91YszpdbjjEFZK53zXy6tUD2d
 e1i0kBBS6NLAAsqEtneplz88T/v7MpLmpY30N9gQU3QyRC50jJ7LU9RazMjUQY1WohVsR56d
 ORqFxS8ChhyJs7BI34vQusYHDTp6PnZHUppb9WIzjeWlC7Jc8lSBDlEWodmqQQgp5+6AfhTD
 kDv1a+W5+ncq+Uo63WHRiCPuyt4di4/0zo28RVcjtzlGBZtmz2EIC3vUfmoZbO/Gn6EKbYAn
 rzz3iU/JWV8DwQ+sZSGu0HmvYMt6t5SmqWQo/hyHtA7uF5Wxtu1lCgolSQw4t49ZuOyOnQi5
 f8R3nE7lpVCSF1TT+h8kMvFPv3VG7KunyjHr3sEptYxQs4VRxqeirSuyBv1TyxT+LdTm6j4a
 mulOWf+YtFRAgIYyyN5YOepDEBv4LUM8Tz98lZiNMlFyRMNrsLV6Pv6SxhrMxbT6TNVS5D+6
 UorTLotDZKp5+M7BTQRUY85qARAAsgMW71BIXRgxjYNCYQ3Xs8k3TfAvQRbHccky50h99TUY
 sqdULbsb3KhmY29raw1bgmyM0a4DGS1YKN7qazCDsdQlxIJp9t2YYdBKXVRzPCCsfWe1dK/q
 66UVhRPP8EGZ4CmFYuPTxqGY+dGRInxCeap/xzbKdvmPm01Iw3YFjAE4PQ4hTMr/H76KoDbD
 cq62U50oKC83ca/PRRh2QqEqACvIH4BR7jueAZSPEDnzwxvVgzyeuhwqHY05QRK/wsKuhq7s
 UuYtmN92Fasbxbw2tbVLZfoidklikvZAmotg0dwcFTjSRGEg0Gr3p/xBzJWNavFZZ95Rj7Et
 db0lCt0HDSY5q4GMR+SrFbH+jzUY/ZqfGdZCBqo0cdPPp58krVgtIGR+ja2Mkva6ah94/oQN
 lnCOw3udS+Eb/aRcM6detZr7XOngvxsWolBrhwTQFT9D2NH6ryAuvKd6yyAFt3/e7r+HHtkU
 kOy27D7IpjngqP+b4EumELI/NxPgIqT69PQmo9IZaI/oRaKorYnDaZrMXViqDrFdD37XELwQ
 gmLoSm2VfbOYY7fap/AhPOgOYOSqg3/Nxcapv71yoBzRRxOc4FxmZ65mn+q3rEM27yRztBW9
 AnCKIc66T2i92HqXCw6AgoBJRjBkI3QnEkPgohQkZdAb8o9WGVKpfmZKbYBo4pEAEQEAAcLB
 XwQYAQIACQUCVGPOagIbDAAKCRBoNZUwcMmSsJeCEACCh7P/aaOLKWQxcnw47p4phIVR6pVL
 e4IEdR7Jf7ZL00s3vKSNT+nRqdl1ugJx9Ymsp8kXKMk9GSfmZpuMQB9c6io1qZc6nW/3TtvK
 pNGz7KPPtaDzvKA4S5tfrWPnDr7n15AU5vsIZvgMjU42gkbemkjJwP0B1RkifIK60yQqAAlT
 YZ14P0dIPdIPIlfEPiAWcg5BtLQU4Wg3cNQdpWrCJ1E3m/RIlXy/2Y3YOVVohfSy+4kvvYU3
 lXUdPb04UPw4VWwjcVZPg7cgR7Izion61bGHqVqURgSALt2yvHl7cr68NYoFkzbNsGsye9ft
 M9ozM23JSgMkRylPSXTeh5JIK9pz2+etco3AfLCKtaRVysjvpysukmWMTrx8QnI5Nn5MOlJj
 1Ov4/50JY9pXzgIDVSrgy6LYSMc4vKZ3QfCY7ipLRORyalFDF3j5AGCMRENJjHPD6O7bl3Xo
 4DzMID+8eucbXxKiNEbs21IqBZbbKdY1GkcEGTE7AnkA3Y6YB7I/j9mQ3hCgm5muJuhM/2Fr
 OPsw5tV/LmQ5GXH0JQ/TZXWygyRFyyI2FqNTx4WHqUn3yFj8rwTAU1tluRUYyeLy0ayUlKBH
 ybj0N71vWO936MqP6haFERzuPAIpxj2ezwu0xb1GjTk4ynna6h5GjnKgdfOWoRtoWndMZxbA
 z5cecg==
Message-ID: <20b86ced-7c47-02ca-0e0e-1bd5d6cc95c1@intel.com>
Date: Thu, 30 Apr 2020 04:23:42 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200430102908.10107-4-david@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, linux-acpi@vger.kernel.org,
 Baoquan He <bhe@redhat.com>, linux-nvdimm@lists.01.org,
 linux-s390@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Dave Hansen <dave.hansen@linux.intel.com>,
 virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
 Wei Yang <richard.weiyang@gmail.com>, Eric Biederman <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org, Dan Williams <dan.j.williams@intel.com>,
 Pavel Tatashin <pasha.tatashin@soleen.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/30/20 3:29 AM, David Hildenbrand wrote:
> Currently, when adding memory, we create entries in /sys/firmware/memmap/
> as "System RAM". This does not reflect the reality and will lead to
> kexec-tools to add that memory to the fixed-up initial memmap for a
> kexec kernel (loaded via kexec_load()). The memory will be considered
> initial System RAM by the kexec kernel.
> 
> We should let the kexec kernel decide how to use that memory - just as
> we do during an ordinary reboot.
...
> -	rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0);
> +	rc = add_memory(numa_node, new_res->start, resource_size(new_res),
> +			MHP_NO_FIRMWARE_MEMMAP);

Looks fine.  But, if you send another revision, could you add a comment
about the actual goal of MHP_NO_FIRMWARE_MEMMAP?  Maybe:

	/*
	 * MHP_NO_FIRMWARE_MEMMAP ensures that future
	 * kexec'd kernels will not treat this as RAM.
	 */

Not a biggie, though.

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 11:30:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 11:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU7OG-0003t2-Vl; Thu, 30 Apr 2020 11:30:04 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU7OF-0003iO-6g
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 11:30:03 +0000
X-Inumbo-ID: ed73165a-8ad5-11ea-9a28-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id ed73165a-8ad5-11ea-9a28-12813bfff9fa;
 Thu, 30 Apr 2020 11:30:00 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id DE5F5AF9F;
 Thu, 30 Apr 2020 11:29:58 +0000 (UTC)
Subject: Re: [PATCH v2 4/5] common/domain: add a domain context record for
 shared_info...
To: paul@xen.org
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-5-paul@xen.org>
 <7f0821ed-34e8-2a63-aaab-bf781fdfb9e7@xen.org>
 <001601d61d72$efb23840$cf16a8c0$@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <66028521-6b46-2aa8-1ba9-2ce703bbbfd8@suse.com>
Date: Thu, 30 Apr 2020 13:29:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <001601d61d72$efb23840$cf16a8c0$@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
 'Julien Grall' <julien@xen.org>, 'Wei Liu' <wl@xen.org>,
 'Andrew Cooper' <andrew.cooper3@citrix.com>,
 'Paul Durrant' <pdurrant@amazon.com>,
 'Ian Jackson' <ian.jackson@eu.citrix.com>,
 'George Dunlap' <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 28.04.2020 17:37, Paul Durrant wrote:
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Sent: 20 April 2020 18:35
>> To: Paul Durrant <paul@xen.org>; xen-devel@lists.xenproject.org
>> Cc: Paul Durrant <pdurrant@amazon.com>; Ian Jackson <ian.jackson@eu.citrix.com>; Wei Liu <wl@xen.org>;
>> Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap <george.dunlap@citrix.com>; Jan Beulich
>> <jbeulich@suse.com>; Stefano Stabellini <sstabellini@kernel.org>
>> Subject: Re: [PATCH v2 4/5] common/domain: add a domain context record for shared_info...
>>
>> Hi Paul,
>>
>> On 07/04/2020 18:38, Paul Durrant wrote:
>>> ... and update xen-domctx to dump some information describing the record.
>>>
>>> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
>>> ---
>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>> Cc: Wei Liu <wl@xen.org>
>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Cc: George Dunlap <george.dunlap@citrix.com>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>>> Cc: Julien Grall <julien@xen.org>
>>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>>>
>>> v2:
>>>   - Drop the header change to define a 'Xen' page size and instead use a
>>>     variable length struct now that the framework makes this is feasible
>>>   - Guard use of 'has_32bit_shinfo' in common code with CONFIG_COMPAT
>>> ---
>>>   tools/misc/xen-domctx.c   | 11 ++++++
>>>   xen/common/domain.c       | 81 +++++++++++++++++++++++++++++++++++++++
>>>   xen/include/public/save.h | 10 ++++-
>>>   3 files changed, 101 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tools/misc/xen-domctx.c b/tools/misc/xen-domctx.c
>>> index d663522a8b..a8d3922321 100644
>>> --- a/tools/misc/xen-domctx.c
>>> +++ b/tools/misc/xen-domctx.c
>>> @@ -59,6 +59,16 @@ static void dump_header(struct domain_save_descriptor *desc)
>>>       off += desc->length;
>>>   }
>>>
>>> +static void dump_shared_info(struct domain_save_descriptor *desc)
>>> +{
>>> +    DOMAIN_SAVE_TYPE(SHARED_INFO) s;
>>> +    READ(s);
>>> +    printf("    SHARED_INFO: field_width %u buffer size: %lu\n",
>>> +           s.field_width, desc->length - sizeof(s));
>>> +
>>> +    off += desc->length;
>>> +}
>>> +
>>>   static void dump_end(struct domain_save_descriptor *desc)
>>>   {
>>>       DOMAIN_SAVE_TYPE(END) e;
>>> @@ -125,6 +135,7 @@ int main(int argc, char **argv)
>>>           switch (desc.typecode)
>>>           {
>>>           case DOMAIN_SAVE_CODE(HEADER): dump_header(&desc); break;
>>> +        case DOMAIN_SAVE_CODE(SHARED_INFO): dump_shared_info(&desc); break;
>>>           case DOMAIN_SAVE_CODE(END): dump_end(&desc); return 0;
>>>           default:
>>>               printf("Unknown type %u: skipping\n", desc.typecode);
>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>> index 3dcd73f67c..8b72462e07 100644
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -33,6 +33,7 @@
>>>   #include <xen/xenoprof.h>
>>>   #include <xen/irq.h>
>>>   #include <xen/argo.h>
>>> +#include <xen/save.h>
>>>   #include <asm/debugger.h>
>>>   #include <asm/p2m.h>
>>>   #include <asm/processor.h>
>>> @@ -1646,6 +1647,86 @@ int continue_hypercall_on_cpu(
>>>       return 0;
>>>   }
>>>
>>> +static int save_shared_info(const struct vcpu *v, struct domain_context *c,
>>> +                            bool dry_run)
>>> +{
>>> +    struct domain *d = v->domain;
>>> +    struct domain_shared_info_context ctxt = {};
>>> +    size_t hdr_size = offsetof(typeof(ctxt), buffer);
>>> +    size_t size = hdr_size + PAGE_SIZE;
>>> +    int rc;
>>> +
>>> +    rc = DOMAIN_SAVE_BEGIN(SHARED_INFO, c, v, size);
>>> +    if ( rc )
>>> +        return rc;
>>> +
>>> +    if ( !dry_run )
>>
>> NIT: I think the if is not necessary here as you don't skip that much code.
>>
> 
> I know, but it is illustrative so I'd rather keep it.

While I agree with the "illustrative", I'd really see this be part
of the struct initializer. Plus its use here made me wonder ...

>>> +        ctxt.field_width =
>>> +#ifdef CONFIG_COMPAT
>>> +            has_32bit_shinfo(d) ? 4 :
>>> +#endif
>>> +            8;
>>> +
>>> +    rc = domain_save_data(c, &ctxt, hdr_size);
>>> +    if ( rc )
>>> +        return rc;
>>> +
>>> +    rc = domain_save_data(c, d->shared_info, PAGE_SIZE);
>>> +    if ( rc )
>>> +        return rc;

... why these don't get skipped. It took me going back through
earlier patches to find that there's effectively redundancy in
the passed arguments in that the write callback chosen varies with
whether "dry_run" is true or false.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 11:56:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 11:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU7nS-0005yO-Qn; Thu, 30 Apr 2020 11:56:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU7nR-0005yJ-O6
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 11:56:05 +0000
X-Inumbo-ID: 915e6a3c-8ad9-11ea-9a2f-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 915e6a3c-8ad9-11ea-9a2f-12813bfff9fa;
 Thu, 30 Apr 2020 11:56:04 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 3D31BAC7F;
 Thu, 30 Apr 2020 11:56:02 +0000 (UTC)
Subject: Re: [PATCH v2 4/5] common/domain: add a domain context record for
 shared_info...
To: Paul Durrant <paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-5-paul@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <4f1f401e-2382-1929-407b-37d5a2b64013@suse.com>
Date: Thu, 30 Apr 2020 13:56:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200407173847.1595-5-paul@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Paul Durrant <pdurrant@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 19:38, Paul Durrant wrote:
> --- a/tools/misc/xen-domctx.c
> +++ b/tools/misc/xen-domctx.c
> @@ -59,6 +59,16 @@ static void dump_header(struct domain_save_descriptor *desc)
>      off += desc->length;
>  }
>  
> +static void dump_shared_info(struct domain_save_descriptor *desc)
> +{
> +    DOMAIN_SAVE_TYPE(SHARED_INFO) s;
> +    READ(s);
> +    printf("    SHARED_INFO: field_width %u buffer size: %lu\n",
> +           s.field_width, desc->length - sizeof(s));
> +
> +    off += desc->length;
> +}

And nothing about the actual contents of the shared info struct?

> @@ -1646,6 +1647,86 @@ int continue_hypercall_on_cpu(
>      return 0;
>  }
>  
> +static int save_shared_info(const struct vcpu *v, struct domain_context *c,
> +                            bool dry_run)
> +{
> +    struct domain *d = v->domain;

const?

> +    struct domain_shared_info_context ctxt = {};
> +    size_t hdr_size = offsetof(typeof(ctxt), buffer);
> +    size_t size = hdr_size + PAGE_SIZE;
> +    int rc;
> +
> +    rc = DOMAIN_SAVE_BEGIN(SHARED_INFO, c, v, size);
> +    if ( rc )
> +        return rc;
> +
> +    if ( !dry_run )
> +        ctxt.field_width =
> +#ifdef CONFIG_COMPAT
> +            has_32bit_shinfo(d) ? 4 :
> +#endif
> +            8;

What are 4 and 8 to represent here? Taking Arm32 into account, the
only things I could think of are sizeof(xen_ulong_t) or
sizeof(guest_handle). I'd prefer if literal numbers could be avoided
here, such that it would become clear what property is really meant.

> +    rc = domain_save_data(c, &ctxt, hdr_size);
> +    if ( rc )
> +        return rc;
> +
> +    rc = domain_save_data(c, d->shared_info, PAGE_SIZE);
> +    if ( rc )
> +        return rc;
> +
> +    return domain_save_end(c);
> +}
> +
> +static int load_shared_info(struct vcpu *v, struct domain_context *c)
> +{
> +    struct domain *d = v->domain;
> +    struct domain_shared_info_context ctxt = {};
> +    size_t hdr_size = offsetof(typeof(ctxt), buffer);
> +    size_t size = hdr_size + PAGE_SIZE;
> +    unsigned int i;
> +    int rc;
> +
> +    rc = DOMAIN_LOAD_BEGIN(SHARED_INFO, c, v, size, true);
> +    if ( rc )
> +        return rc;
> +
> +    rc = domain_load_data(c, &ctxt, hdr_size);
> +    if ( rc )
> +        return rc;
> +
> +    for ( i = 0; i < ARRAY_SIZE(ctxt.pad); i++ )
> +        if ( ctxt.pad[i] )
> +            return -EINVAL;
> +
> +    switch ( ctxt.field_width )
> +    {
> +#ifdef CONFIG_COMPAT
> +    case 4:
> +        d->arch.has_32bit_shinfo = 1;

true and ...

> +        break;
> +#endif
> +    case 8:
> +#ifdef CONFIG_COMPAT
> +        d->arch.has_32bit_shinfo = 0;

... false respectively, please.

> +#endif
> +        break;
> +
> +    default:
> +        rc = -EINVAL;
> +        break;
> +    }
> +
> +    rc = domain_load_data(c, d->shared_info, PAGE_SIZE);
> +    if ( rc )
> +        return rc;
> +
> +    return domain_load_end(c);
> +}

While you check the padding fields of the header above, what about
currently unused fields of the shared_info struct itself?

There's a connection between shared_info and vcpu_info - this way
you may or may not restore vcpu_info - depending on guest behavior.
There not being a patch in the series to deal with vcpu_info, the
description here should imo at least outline the intended
interaction (including e.g. ordering between the [supposed] records).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 11:57:44 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 11:57:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU7p2-00063o-5u; Thu, 30 Apr 2020 11:57:44 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU7p0-00063i-Ue
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 11:57:42 +0000
X-Inumbo-ID: cb6817c8-8ad9-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cb6817c8-8ad9-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 11:57:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 12525AB89;
 Thu, 30 Apr 2020 11:57:40 +0000 (UTC)
Subject: Re: [PATCH v2 5/5] tools/libxc: make use of domain context
 SHARED_INFO record...
To: Paul Durrant <paul@xen.org>
References: <20200407173847.1595-1-paul@xen.org>
 <20200407173847.1595-6-paul@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <fe6e5919-ee1f-7a35-ff37-ca2b304a7682@suse.com>
Date: Thu, 30 Apr 2020 13:57:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200407173847.1595-6-paul@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Paul Durrant <pdurrant@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 07.04.2020 19:38, Paul Durrant wrote:
> ... in the save/restore code.
> 
> This patch replaces direct mapping of the shared_info_frame (retrieved
> using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
> SHARED_INFO record.
> 
> No modifications are made to the definition of the migration stream at
> this point. Subsequent patches will define a record in the libxc domain
> image format for passing domain context and convert the save/restore code
> to use that.
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> ---
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Wei Liu <wl@xen.org>
> 
> v2:
>  - Re-based (now making use of DOMAIN_SAVE_FLAG_IGNORE)
> ---
>  tools/libxc/xc_sr_common.h         |  7 +++-
>  tools/libxc/xc_sr_common_x86.c     | 59 ++++++++++++++++++++++++++++++
>  tools/libxc/xc_sr_common_x86.h     |  4 ++
>  tools/libxc/xc_sr_common_x86_pv.c  | 53 +++++++++++++++++++++++++++
>  tools/libxc/xc_sr_common_x86_pv.h  |  3 ++
>  tools/libxc/xc_sr_restore_x86_pv.c | 40 ++++++++------------
>  tools/libxc/xc_sr_save_x86_pv.c    | 26 ++-----------
>  tools/libxc/xg_save_restore.h      |  1 +
>  8 files changed, 144 insertions(+), 49 deletions(-)

The underlying interface being arch-independent, shouldn't at least
some of the new code go into other than xc_sr_*x86*?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 12:04:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 12:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU7v2-0006y4-1y; Thu, 30 Apr 2020 12:03:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=BIwo=6O=kernel.org=ardb@srs-us1.protection.inumbo.net>)
 id 1jU7ZG-000584-0k
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 11:41:26 +0000
X-Inumbo-ID: 8558e80e-8ad7-11ea-9a2a-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8558e80e-8ad7-11ea-9a2a-12813bfff9fa;
 Thu, 30 Apr 2020 11:41:25 +0000 (UTC)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com
 [209.85.166.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 71CD12076D
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 11:41:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588246884;
 bh=94Cb00cw2YL1QH1+9zuA6LjdU8ZZLvi1vRLitBmfivU=;
 h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
 b=SKBAEyU6gDyezLNM9/YPnha9O7uf7VffoUJaCimYnXWaqr0lJVR4jsXW+sKQp8cmI
 Upj5GDoxafdLiHlr2xF6Kwu1SWuzL3Vj7Mfz3rSmD8jeKSfdh88ahHgbptiNjcbVHJ
 BQKtk3D6grKqHyFpCXK9Sy3ubIg4CnqSF5DmrL2I=
Received: by mail-io1-f47.google.com with SMTP id u11so1091878iow.4
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 04:41:24 -0700 (PDT)
X-Gm-Message-State: AGi0PuatvH9nBjPXOZN3jRJV+hksx3aZkqVfJ5NAlH+RA/1rbm6DLqg4
 njPuc1yOGwqnp9nRGvbAVKstNAVo0MCIED+gDoE=
X-Google-Smtp-Source: APiQypIIb8uy4dJ9kuhxCA8nd1ZpGi0t7TUZDtJTwcqSdv1SIbIj17IjDVxzeTtyg/8lb0xjHYR0lmTAyIEiPPHVWX0=
X-Received: by 2002:a02:969a:: with SMTP id w26mr1266527jai.71.1588246883795; 
 Thu, 30 Apr 2020 04:41:23 -0700 (PDT)
MIME-Version: 1.0
References: <20200429225108.GA54201@bobbye-pc>
 <ebdd7b4a-767b-1b72-a344-78b190f42ceb@suse.com>
 <20200430111501.336wte64pwsfptze@tomti.i.net-space.pl>
In-Reply-To: <20200430111501.336wte64pwsfptze@tomti.i.net-space.pl>
From: Ard Biesheuvel <ardb@kernel.org>
Date: Thu, 30 Apr 2020 13:41:12 +0200
X-Gmail-Original-Message-ID: <CAMj1kXF1vRtqbGS-eptB682h1xJ8LYQi74YaTZgM1nyYcpFsYA@mail.gmail.com>
Message-ID: <CAMj1kXF1vRtqbGS-eptB682h1xJ8LYQi74YaTZgM1nyYcpFsYA@mail.gmail.com>
Subject: Re: [RFC] UEFI Secure Boot on Xen Hosts
To: Daniel Kiper <daniel.kiper@oracle.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Thu, 30 Apr 2020 12:03:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: michal.zygowski@3mdeb.com, Bobby Eshleman <bobbyeshleman@gmail.com>,
 olivier.lambert@vates.fr, krystian.hebel@3mdeb.com,
 Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
 piotr.krol@3mdeb.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, 30 Apr 2020 at 13:15, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>
> Adding Ard...
>
> On Thu, Apr 30, 2020 at 09:01:45AM +0200, Jan Beulich wrote:
> > On 30.04.2020 00:51, Bobby Eshleman wrote:
> > > Hey all,
> > >
> > > We're looking to develop UEFI Secure Boot support for grub-loaded Xen and
> > > ultimately for XCP-ng (I'm on the XCP-ng team at Vates).
> > >
> > > In addition to carrying the chain-of-trust through the entire boot sequence
> > > into dom0, we would also like to build something akin to Linux's Lockdown for
> > > dom0 and its privileged interfaces.
> > >
> > > It appears that there are various options and we'd like to discuss them with
> > > the community.
> > >
> > > # Option #1: PE/COFF and Shim
> > >
> > > Shim installs a verification protocol available to subsequent programs via EFI
> > > boot services.  The protocol is called SHIM_LOCK and it is currently supported
> > > by xen.efi.
> > >
> > > Shim requires the payload under verification to be a PE/COFF executable.  In
> > > order to support both shim and maintain the multiboot2 protocol, Daniel Kiper's
> > > patchset [1]  (among other things) incorporates the PE/COFF header
> > > into xen.gz and adds dom0 verification via SHIM_LOCK in
> > > efi_multiboot2().
> > >
> > > There appears that some work will be needed on top of this patchset, but not
> > > much as it seems most of the foot work has been done.
> > >
> > > AFAIK, the changes needed in GRUB for this approach are already upstream (the
> > > shim_lock module is upstream), and shim would go untouched.
> > >
> > > # Option #2: Extended Multiboot2 and Shim
> > >
> > > Another approach that could be taken is to embed Xen's signature into a
> > > new multiboot2 header and then modify shim to support it.  This would
> > > arguably be more readable than embedding the PE/COFF header, would add
> > > value to shim, and would fit nicely with the mb2 header code that
> > > already exists in Xen.  The downside being that it would require a shim
> > > fork.  Grub2 would be unchanged.
>
> Here you have to change the Multiboot2 protocol and singing tools too.
> So, I do not consider this as a viable solution.
>
> > > I'm not familliar with Microsoft's signing process.  I do know they
> > > support template submissions based on shim, and I'm not sure if such a
> > > big change would impact their approval process.
> > >
> > > # Option #3: Lean on Grub2's LoadFile2() Verification
> > >
> > > Grub2 will provide a LoadFile2() method to subsequent programs that supports
> > > signature verification of arbitrary files.  Linux is moving in the
> > > direction of using LoadFile2() for loading the initrd [2], and Grub2 will
> > > support verifying the signatures of files loaded via LoadFile2().  This is set
> > > for release in GRUB 2.06 sometime in the latter half of 2020.
>
> s/for release in/after release/
>
> > > In Xen, this approach could be used for loading dom0 as well, offering a very
> > > simple verified load interface.
> > >
> > > Currently the initrd argument passed from Linux to LoadFile2() is a vendor
> > > media device path GUID [3].
> > >
> > > Changes to Xen:
> > > - Xen would need to pass these device paths to Grub
> > > - Xen would be changed to load dom0 with the LoadFile2() interface via boot services
> > >
> > > Changes to Grub:
> > > - Xen dom0 kernel/initrd device paths would need to be introduced to Grub
>
> Maybe partially but certainly there will be some differences...
>
> > > Potential Issues:
> > > - How will Xen handle more boot modules than just a dom0 and dom0
> > >   initrd?
> > > - Would each boot module need a unique vendor guid?
>
> AIUI yes but Ard, who designed this new boot protocol, may say more
> about that.
>
> Anyway, the advantage of this new protocol is that it uses UEFI API to
> load and execute PE kernel and its modules. This means that it will be
> architecture independent. However, IIRC, if we want to add new modules
> types to the Xen then we have to teach all bootloaders in the wild about
> new GUIDs. Ard, am I correct?
>

Well, if you are passing multiple files that are not interchangeable,
each bootloader will need to do something, right? It could be another
GUID, or we could extend the initrd media device path to take
discriminators.

So today, we have

VendorMedia(5568e427-68fc-4f3d-ac74-ca555231cc68)

which identifies /the/ initrd on Linux. As long as this keeps working
as intended, I have no objections extending this to

VendorMedia(5568e427-68fc-4f3d-ac74-ca555231cc68)/File(...)

etc, if we can agree that omitting the File() part means the unnamed
initrd, and that L"initrd" is reserved as a file name. That way, you
can choose any abstract file name you want, but please note that the
loader still needs to provide some kind of mapping of how these
abstract file names relate to actual files selected by the user.

One thing to keep in mind, though, is that this protocol goes away
after ExitBootServices().



> > > - Would this interfere with the DomB proposal?  I suspect not because
> > >   the DomB proposal suggests launching DomUs from an already booted
> > >   DomB, at which point other means could be used.
> > >
> > > We'd just like to get the conversation going on this topic before we
> > > dive too far into implementing something.  Are any of these approaches a
> > > hard no for upstreaming?  Do any stand out as best candidates?  Any
> > > feedback / questions / criticisms would be greatly appreciated.
> >
> > A shim fork doesn't look desirable, which would rule out #2 unless there
> > is an option there to avoid the fork.
> >
> > If the potential issues listed for #3 can be suitably addressed, I can't
> > currently see a reason to prefer either of the two remaining options; I
> > vaguely recall though that Daniel's change for #1 didn't look overly
> > appealing, but perhaps this can be taken care of.
>
> Daniel


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 12:28:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 12:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU8IU-0000EQ-0o; Thu, 30 Apr 2020 12:28:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=0VdV=6O=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jU8IS-0000EL-RP
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 12:28:08 +0000
X-Inumbo-ID: 0bdf434a-8ade-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0bdf434a-8ade-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 12:28:08 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 2073AAB3D;
 Thu, 30 Apr 2020 12:28:06 +0000 (UTC)
Message-ID: <d60d5b917d517b1dfa8292cfb456639c736ec173.camel@suse.com>
Subject: Re: [PATCH 2/2] xen: credit2: limit the max number of CPUs in a
 runqueue
From: Dario Faggioli <dfaggioli@suse.com>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, 
 xen-devel@lists.xenproject.org
Date: Thu, 30 Apr 2020 14:28:05 +0200
In-Reply-To: <b368ccef-d3b1-1338-6325-8f81a963876d@suse.com>
References: <158818022727.24327.14309662489731832234.stgit@Palanthas>
 <158818179558.24327.11334680191217289878.stgit@Palanthas>
 <b368ccef-d3b1-1338-6325-8f81a963876d@suse.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-s/aWSZG5acsW9gBFj9A8"
User-Agent: Evolution 3.36.1 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-s/aWSZG5acsW9gBFj9A8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2020-04-30 at 09:35 +0200, J=C3=BCrgen Gro=C3=9F wrote:
> On 29.04.20 19:36, Dario Faggioli wrote:
> >=20
> > Therefore, let's set a limit to the max number of CPUs that can
> > share a
> > Credit2 runqueue. The actual value is configurable (at boot time),
> > the
> > default being 16. If, for instance,  there are more than 16 CPUs in
> > a
> > socket, they'll be split among two (or more) runqueues.
>=20
> Did you think about balancing the runqueues regarding the number of
> cpus? E.g. in case of max being 16 and having 20 cpus to put 10 in
> each
> runqueue? I know this will need more logic as cpus are added one by
> one,
> but the result would be much better IMO.
>
I know. Point is, CPUs not only are added one by one, but they can,
once the system is running, be offlined/onlined or moved among
cpupools.

Therefore, if we have 20 CPUs, even if we put 10 in each runqueue at
boot, if the admin removes 4 CPUs that happened to be all in the same
runqueue, we end up in an unbalanced (6 vs 10) situation again. So we'd
indeed need full runqueue online rebalancing logic, which will probably
end up being quite complex and I'm not sure it's worth it.

That being said, I can try to make things a bit more fair, when CPUs
come up and are added to the pool. Something around the line of adding
them to the runqueue with the least number of CPUs in it (among the
suitable ones, of course).

With that, when the user removes 4 CPUs, we will have the 6 vs 10
situation. But we would make sure that, when she adds them back, we
will go back to 10 vs. 10, instead than, say, 6 vs 14 or something like
that.

Was something like this that you had in mind? And in any case, what do
you think about it?

> > --- a/xen/common/sched/cpupool.c
> > +++ b/xen/common/sched/cpupool.c
> > @@ -37,7 +37,7 @@ static cpumask_t cpupool_locked_cpus;
> >  =20
> >   static DEFINE_SPINLOCK(cpupool_lock);
> >  =20
> > -static enum sched_gran __read_mostly opt_sched_granularity =3D
> > SCHED_GRAN_cpu;
> > +enum sched_gran __read_mostly opt_sched_granularity =3D
> > SCHED_GRAN_cpu;
>=20
> Please don't use the global option value, but the per-cpupool one.
>=20
Yep, you're right. Will do.

> > +/* Additional checks, to avoid separating siblings in different
> > runqueues. */
> > +static bool
> > +cpu_runqueue_smt_match(const struct csched2_runqueue_data *rqd,
> > unsigned int cpu)
> > +{
> > +    unsigned int nr_sibl =3D
> > cpumask_weight(per_cpu(cpu_sibling_mask, cpu));
>=20
> Shouldn't you mask away siblings not in the cpupool?
>=20
So, point here is: if I have Pool-0 and Pool-1, each with 2 runqueues
and CPU 0 is in Pool-1, when I add CPU 1 --which is CPU 0's sibling--
to Pool-0, I always want to make sure that there is room for both CPUs
0 and 1 in the runqueue of Pool-0 where I'm putting it (CPU 0). Even if
CPU 1 is currently in another pool.

This way if, in future, CPU 1 is removed from Pool-1 and added to
Pool-0, I am sure it can go in the same runqueue where CPU 0 is. If I
don't consider CPUs which currently are in another pool, we risk that
when/if they're added to this very pool, they'll end up in a different
runqueue.

And we don't want that.

Makes sense?

Thanks and Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-s/aWSZG5acsW9gBFj9A8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6qxFUACgkQFkJ4iaW4
c+7aQxAA2saLKaSV21pfDWZRUmzV547i+wZJDXjspbfOMC8Vmm2oVmQ9/213+fLf
0wN7PWSWxjw1YTRXT7FsWOcWsbv1Z3mxeqOcwcCYOyzt/fpsLZayw3N2/5dPogqg
riXTBdIIL7hUEvGBneH7P7KdGFcjjMAZofH7fFT4PvcuKbDTt9iOFVrpTWOwqPS6
+zfFFEfFeN4egYKlp25X6M95GiC+TA56GrlMhWWuwRBESKkaRwvo8qvX1qF1waVP
6UCOfBr65XjoQTRNI0xdkCdebQ9enDMWJRLqYKOBGsY9Yl4MRgPnePEg+XhxQeoe
6AfqrcBfAFAuE08K32YO4RPmRM31kjJV0ouTpl6v97J+JgVmqNwNbNcW8TV92Il1
1TU6+lny2MZ/VcolS+M9/1D7xGvEgRDAoy2ibt1Lw57HeTKb5ko+GckpAR0bWhbl
epdzPuQlfBLpGOvt/nC0dBlbL+lAFJS1StzoG1UEa0a+rPpxqUp92gBsyEMqO0uv
25fZL4o2bH2l46ui2p2Om3wX4Yh2fxEfx5MmadVGE8x3Xzntb8DhKzsySfhCUEWd
S+0m3mWdTVCN/+lRMeQLvy86gi8LsqWdg3TS/s5EpNcX02HwDuxuiN8Bg3pA9oO0
WjUydtPkUDFcIjYgxHMhKvzP+GDirPxyUoVfWOmqZ/u4JGsG0qM=
=3ATS
-----END PGP SIGNATURE-----

--=-s/aWSZG5acsW9gBFj9A8--



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 12:42:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 12:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU8Wf-0001nK-AZ; Thu, 30 Apr 2020 12:42:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU8Wd-0001nF-Hq
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 12:42:47 +0000
X-Inumbo-ID: 17b6538c-8ae0-11ea-9a3e-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 17b6538c-8ae0-11ea-9a3e-12813bfff9fa;
 Thu, 30 Apr 2020 12:42:46 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 20EB5AC64;
 Thu, 30 Apr 2020 12:42:45 +0000 (UTC)
Subject: Re: [PATCH v6 09/15] efi: use new page table APIs in copy_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587735799.git.hongyxia@amazon.com>
 <6c27c79964eb16eba4743515689b9fd7eb3409d1.1587735799.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <6f2447ba-e12a-9241-6c2c-a7a49059c09b@suse.com>
Date: Thu, 30 Apr 2020 14:42:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <6c27c79964eb16eba4743515689b9fd7eb3409d1.1587735799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, julien@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 16:09, Hongyan Xia wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1454,16 +1454,20 @@ static __init void copy_mapping(unsigned long mfn, unsigned long end,
>              continue;
>          if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) )
>          {
> -            l3dst = alloc_xen_pagetable();
> -            BUG_ON(!l3dst);
> +            mfn_t l3mfn = alloc_xen_pagetable_new();
> +
> +            BUG_ON(mfn_eq(l3mfn, INVALID_MFN));
> +            l3dst = map_domain_page(l3mfn);
>              clear_page(l3dst);
>              efi_l4_pgtable[l4_table_offset(mfn << PAGE_SHIFT)] =
> -                l4e_from_paddr(virt_to_maddr(l3dst), __PAGE_HYPERVISOR);
> +                l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR);
>          }
>          else
> -            l3dst = l4e_to_l3e(l4e);
> -        l3src = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
> +            l3dst = map_l3t_from_l4e(l4e);
> +        l3src = map_l3t_from_l4e(idle_pg_table[l4_table_offset(va)]);
>          l3dst[l3_table_offset(mfn << PAGE_SHIFT)] = l3src[l3_table_offset(va)];
> +        unmap_domain_page(l3src);
> +        unmap_domain_page(l3dst);
>      }
>  }

This looks very inefficient - you establish and tear down two mappings
per loop iteration, when really you may end up copying all 512 slots
between the same pair of L3 tables.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 12:43:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 12:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU8Xd-0001sH-Kl; Thu, 30 Apr 2020 12:43:49 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jU8Xb-0001s2-Ry
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 12:43:47 +0000
X-Inumbo-ID: 3bcc51ea-8ae0-11ea-b07b-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3bcc51ea-8ae0-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 12:43:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=B5YPe1nFqxyWzM16OSEtEbJ+OP5IgkIlMTCrJ2yOq/8=; b=auDwSJj7RviXmcyqNdaBpVCNoO
 /QBRkkkdjPE5HkebLJgyBmv45eEbeSzxRiOtu9If62MOLn+vHKqAJgk7aqj8YN/Lx+vDq64PILpav
 8plEZi2xGGdL4qXwkMx6kcn14CxLcp7eZTKoJ78kI859TQ5hL56CgueL6gSv31OkZj/0=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jU8Xa-0002qH-HS; Thu, 30 Apr 2020 12:43:46 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jU8Xa-0001dc-8S; Thu, 30 Apr 2020 12:43:46 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 1/2] xen/Kconfig: define EXPERT a bool rather than a string
Date: Thu, 30 Apr 2020 13:43:42 +0100
Message-Id: <20200430124343.29886-2-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200430124343.29886-1-julien@xen.org>
References: <20200430124343.29886-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <jgrall@amazon.com>, julien@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Since commit f80fe2b34f08 "xen: Update Kconfig to Linux v5.4" EXPERT
can only have two values (enabled or disabled). So switch from a string
to a bool.

Take the opportunity to replace all "EXPERT = y" to "EXPERT".

Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/Kconfig                     |  3 +--
 xen/Kconfig.debug               |  2 +-
 xen/arch/arm/Kconfig            | 10 +++++-----
 xen/arch/x86/Kconfig            |  6 +++---
 xen/common/Kconfig              | 14 +++++++-------
 xen/common/sched/Kconfig        |  2 +-
 xen/drivers/passthrough/Kconfig |  2 +-
 7 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/xen/Kconfig b/xen/Kconfig
index 073042f46730..120b5f412993 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -35,8 +35,7 @@ config DEFCONFIG_LIST
 	default ARCH_DEFCONFIG
 
 config EXPERT
-	string
-	default y if "$(XEN_CONFIG_EXPERT)" = "y"
+	def_bool y if "$(XEN_CONFIG_EXPERT)" = "y"
 
 config LTO
 	bool "Link Time Optimisation"
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index ee6ee33b69be..fad3050d4f7b 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -11,7 +11,7 @@ config DEBUG
 
 	  You probably want to say 'N' here.
 
-if DEBUG || EXPERT = "y"
+if DEBUG || EXPERT
 
 config CRASH_DEBUG
 	bool "Crash Debugging Support"
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d51f66072e2e..6a43576dac5e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -33,7 +33,7 @@ source "arch/Kconfig"
 
 config ACPI
 	bool
-	prompt "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT = "y"
+	prompt "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT
 	depends on ARM_64
 	---help---
 
@@ -51,7 +51,7 @@ config GICV3
 
 config HAS_ITS
         bool
-        prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
+        prompt "GICv3 ITS MSI controller support" if EXPERT
         depends on GICV3 && !NEW_VGIC
 
 config HVM
@@ -81,7 +81,7 @@ config SBSA_VUART_CONSOLE
 	  SBSA Generic UART implements a subset of ARM PL011 UART.
 
 config ARM_SSBD
-	bool "Speculative Store Bypass Disable" if EXPERT = "y"
+	bool "Speculative Store Bypass Disable" if EXPERT
 	depends on HAS_ALTERNATIVE
 	default y
 	help
@@ -91,7 +91,7 @@ config ARM_SSBD
 	  If unsure, say Y.
 
 config HARDEN_BRANCH_PREDICTOR
-	bool "Harden the branch predictor against aliasing attacks" if EXPERT = "y"
+	bool "Harden the branch predictor against aliasing attacks" if EXPERT
 	default y
 	help
 	  Speculation attacks against some high-performance processors rely on
@@ -108,7 +108,7 @@ config HARDEN_BRANCH_PREDICTOR
 	  If unsure, say Y.
 
 config TEE
-	bool "Enable TEE mediators support" if EXPERT = "y"
+	bool "Enable TEE mediators support" if EXPERT
 	default n
 	help
 	  This option enables generic TEE mediators support. It allows guests
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index a69be983d6f3..3237cb2f31f4 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -112,7 +112,7 @@ config BIGMEM
 	  If unsure, say N.
 
 config HVM_FEP
-	bool "HVM Forced Emulation Prefix support" if EXPERT = "y"
+	bool "HVM Forced Emulation Prefix support" if EXPERT
 	default DEBUG
 	depends on HVM
 	---help---
@@ -132,7 +132,7 @@ config HVM_FEP
 
 config TBOOT
 	def_bool y
-	prompt "Xen tboot support" if EXPERT = "y"
+	prompt "Xen tboot support" if EXPERT
 	select CRYPTO
 	---help---
 	  Allows support for Trusted Boot using the Intel(R) Trusted Execution
@@ -217,7 +217,7 @@ config HYPERV_GUEST
 endif
 
 config MEM_SHARING
-	bool "Xen memory sharing support" if EXPERT = "y"
+	bool "Xen memory sharing support" if EXPERT
 	depends on HVM
 
 endmenu
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index a6914fcae98b..fe9b41f72128 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -12,7 +12,7 @@ config CORE_PARKING
 	bool
 
 config GRANT_TABLE
-	bool "Grant table support" if EXPERT = "y"
+	bool "Grant table support" if EXPERT
 	default y
 	---help---
 	  Grant table provides a generic mechanism to memory sharing
@@ -128,7 +128,7 @@ config KEXEC
 	  If unsure, say Y.
 
 config EFI_SET_VIRTUAL_ADDRESS_MAP
-    bool "EFI: call SetVirtualAddressMap()" if EXPERT = "y"
+    bool "EFI: call SetVirtualAddressMap()" if EXPERT
     ---help---
       Call EFI SetVirtualAddressMap() runtime service to setup memory map for
       further runtime services. According to UEFI spec, it isn't strictly
@@ -139,7 +139,7 @@ config EFI_SET_VIRTUAL_ADDRESS_MAP
 
 config XENOPROF
 	def_bool y
-	prompt "Xen Oprofile Support" if EXPERT = "y"
+	prompt "Xen Oprofile Support" if EXPERT
 	depends on X86
 	---help---
 	  Xen OProfile (Xenoprof) is a system-wide profiler for Xen virtual
@@ -176,7 +176,7 @@ config XSM_FLASK
 
 config XSM_FLASK_AVC_STATS
 	def_bool y
-	prompt "Maintain statistics on the FLASK access vector cache" if EXPERT = "y"
+	prompt "Maintain statistics on the FLASK access vector cache" if EXPERT
 	depends on XSM_FLASK
 	---help---
 	  Maintain counters on the access vector cache that can be viewed using
@@ -249,7 +249,7 @@ config LATE_HWDOM
 	  If unsure, say N.
 
 config ARGO
-	bool "Argo: hypervisor-mediated interdomain communication" if EXPERT = "y"
+	bool "Argo: hypervisor-mediated interdomain communication" if EXPERT
 	---help---
 	  Enables a hypercall for domains to ask the hypervisor to perform
 	  data transfer of messages between domains.
@@ -321,7 +321,7 @@ config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
 	  build becoming overly verbose.
 
 config CMDLINE
-	string "Built-in hypervisor command string" if EXPERT = "y"
+	string "Built-in hypervisor command string" if EXPERT
 	default ""
 	---help---
 	  Enter arguments here that should be compiled into the hypervisor
@@ -354,7 +354,7 @@ config DOM0_MEM
 	  Leave empty if you are not sure what to specify.
 
 config TRACEBUFFER
-	bool "Enable tracing infrastructure" if EXPERT = "y"
+	bool "Enable tracing infrastructure" if EXPERT
 	default y
 	---help---
 	  Enable tracing infrastructure and pre-defined tracepoints within Xen.
diff --git a/xen/common/sched/Kconfig b/xen/common/sched/Kconfig
index 883ac87cab65..61231aacaa1c 100644
--- a/xen/common/sched/Kconfig
+++ b/xen/common/sched/Kconfig
@@ -1,5 +1,5 @@
 menu "Schedulers"
-	visible if EXPERT = "y"
+	visible if EXPERT
 
 config SCHED_CREDIT
 	bool "Credit scheduler support"
diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index e7e62ccd63c3..73f4ad89ecbc 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -14,7 +14,7 @@ config ARM_SMMU
 	  ARM SMMU architecture.
 
 config IPMMU_VMSA
-	bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs" if EXPERT = "y"
+	bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs" if EXPERT
 	depends on ARM_64
 	---help---
 	  Support for implementations of the Renesas IPMMU-VMSA found
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 12:43:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 12:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU8Xd-0001sN-Sz; Thu, 30 Apr 2020 12:43:49 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jU8Xb-0001s3-US
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 12:43:47 +0000
X-Inumbo-ID: 3b1bef31-8ae0-11ea-9a3e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3b1bef31-8ae0-11ea-9a3e-12813bfff9fa;
 Thu, 30 Apr 2020 12:43:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Rb4tS9NJ8SZ1ohKOUTAAEEo8r3jML2X8FNBVDKVIVCs=; b=QlXevOI90bsWZ6a7NQ7g8ECkab
 4nVn+X/d1jNT2D8e63D3Qh+reGVDcA/kKWGtW7zo8S4fuJfkKuXg9+P+D3M/6a8eRrxdnKve1vwFc
 5dDENMVTOn9PV8ImE6Oj+XUvKpKnoDpI2a7CLTUOKaA541UBNwL/G/OFXElInGnpyNrw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jU8XZ-0002qD-PL; Thu, 30 Apr 2020 12:43:45 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jU8XZ-0001dc-En; Thu, 30 Apr 2020 12:43:45 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/2] xen: Allow EXPERT mode to be selected from the menuconfig
 directly
Date: Thu, 30 Apr 2020 13:43:41 +0100
Message-Id: <20200430124343.29886-1-julien@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <jgrall@amazon.com>, julien@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Hi all,

This small series is meant to make easier to experiment when using Xen.
See patch #2 for more details.

Cheers,

Julien Grall (2):
  xen/Kconfig: define EXPERT a bool rather than a string
  xen: Allow EXPERT mode to be selected from the menuconfig directly

 xen/Kconfig                     | 11 +++++++++--
 xen/Kconfig.debug               |  2 +-
 xen/Makefile                    |  1 -
 xen/arch/arm/Kconfig            | 10 +++++-----
 xen/arch/x86/Kconfig            |  6 +++---
 xen/common/Kconfig              | 14 +++++++-------
 xen/common/sched/Kconfig        |  2 +-
 xen/drivers/passthrough/Kconfig |  2 +-
 8 files changed, 27 insertions(+), 21 deletions(-)

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 12:43:54 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 12:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU8Xi-0001uB-9U; Thu, 30 Apr 2020 12:43:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jU8Xg-0001td-UW
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 12:43:52 +0000
X-Inumbo-ID: 3c40a5e0-8ae0-11ea-9a3e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3c40a5e0-8ae0-11ea-9a3e-12813bfff9fa;
 Thu, 30 Apr 2020 12:43:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=LkqaSMJfdGvWDRCP/rOkol/7V/PWobTan66+EekWFD4=; b=6/UpCgPkdC1jM2aA4yPSH+PiVj
 vwE/xaJvrv8+OcQu6/AMjNGTRpAPYX/lS5tn0AdrdZxQp4cLIfh9LvTSsHhmP3xrCcuKTBnAyy/5/
 fqOU9BRssakWSDOhi/nyglAlg2tFCutmquJDm27ke8qIW3TsgaV7LlqYN0G9WXF6MKyE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jU8Xb-0002qN-Ay; Thu, 30 Apr 2020 12:43:47 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jU8Xb-0001dc-28; Thu, 30 Apr 2020 12:43:47 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 2/2] xen: Allow EXPERT mode to be selected from the menuconfig
 directly
Date: Thu, 30 Apr 2020 13:43:43 +0100
Message-Id: <20200430124343.29886-3-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200430124343.29886-1-julien@xen.org>
References: <20200430124343.29886-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <jgrall@amazon.com>, julien@xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

EXPERT mode is currently used to gate any options that are in technical
preview or not security supported At the moment, the only way to select
it is to use XEN_CONFIG_EXPERT=y on the make command line.

However, if the user forget to add the option of one of the make
command (even a clean), then .config will get rewritten. This may lead
to a rather frustrating experience as it is difficult to diagnostic the
issue.

A lot of the options behind EXPERT would benefit to get more tested in
order to be mark as fully supported in the future.

In order to make easier to experiment, the option EXPERT can now be
selected from the menuconfig rather than make command line. This does
not change the fact a kernel with EXPERT mode selected will not be
security supported.

Signed-off-by: Julien Grall <jgrall@amazon.com>

---

This may require some changes in OSSTest as we select the EXPERT mode
when building (This is necessary for booting Xen on Thunder-X box).
---
 xen/Kconfig  | 10 +++++++++-
 xen/Makefile |  1 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/Kconfig b/xen/Kconfig
index 120b5f412993..34c318bfa2c7 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -35,7 +35,15 @@ config DEFCONFIG_LIST
 	default ARCH_DEFCONFIG
 
 config EXPERT
-	def_bool y if "$(XEN_CONFIG_EXPERT)" = "y"
+	bool "Configure standard Xen features (expert users)"
+	help
+	  This option allows certain base Xen options and settings
+	  to be disabled or tweaked. This is for specialized environments
+	  which can tolerate a "non-standard" Xen.
+	  Only use this if you really know what you are doing.
+	  Xen binaries built with this option enabled are not security
+	  supported.
+	default n
 
 config LTO
 	bool "Link Time Optimisation"
diff --git a/xen/Makefile b/xen/Makefile
index 2b1dacb49754..286f374b549f 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -11,7 +11,6 @@ export XEN_DOMAIN	?= $(shell ([ -x /bin/dnsdomainname ] && /bin/dnsdomainname) |
 export XEN_BUILD_DATE	?= $(shell LC_ALL=C date)
 export XEN_BUILD_TIME	?= $(shell LC_ALL=C date +%T)
 export XEN_BUILD_HOST	?= $(shell hostname)
-export XEN_CONFIG_EXPERT ?= n
 
 # Best effort attempt to find a python interpreter, defaulting to Python 3 if
 # available.  Fall back to just `python` if `which` is nowhere to be found.
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 12:52:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 12:52:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU8g1-0002wQ-5d; Thu, 30 Apr 2020 12:52:29 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jU8g0-0002wI-0N
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 12:52:28 +0000
X-Inumbo-ID: 70ac402c-8ae1-11ea-9a40-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 70ac402c-8ae1-11ea-9a40-12813bfff9fa;
 Thu, 30 Apr 2020 12:52:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 9791BAB3D;
 Thu, 30 Apr 2020 12:52:23 +0000 (UTC)
Subject: Re: [PATCH 2/2] xen: credit2: limit the max number of CPUs in a
 runqueue
To: Dario Faggioli <dfaggioli@suse.com>, xen-devel@lists.xenproject.org
References: <158818022727.24327.14309662489731832234.stgit@Palanthas>
 <158818179558.24327.11334680191217289878.stgit@Palanthas>
 <b368ccef-d3b1-1338-6325-8f81a963876d@suse.com>
 <d60d5b917d517b1dfa8292cfb456639c736ec173.camel@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <7e039c65-4532-c3ea-8707-72a86cf48e0e@suse.com>
Date: Thu, 30 Apr 2020 14:52:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d60d5b917d517b1dfa8292cfb456639c736ec173.camel@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.20 14:28, Dario Faggioli wrote:
> On Thu, 2020-04-30 at 09:35 +0200, Jürgen Groß wrote:
>> On 29.04.20 19:36, Dario Faggioli wrote:
>>>
>>> Therefore, let's set a limit to the max number of CPUs that can
>>> share a
>>> Credit2 runqueue. The actual value is configurable (at boot time),
>>> the
>>> default being 16. If, for instance,  there are more than 16 CPUs in
>>> a
>>> socket, they'll be split among two (or more) runqueues.
>>
>> Did you think about balancing the runqueues regarding the number of
>> cpus? E.g. in case of max being 16 and having 20 cpus to put 10 in
>> each
>> runqueue? I know this will need more logic as cpus are added one by
>> one,
>> but the result would be much better IMO.
>>
> I know. Point is, CPUs not only are added one by one, but they can,
> once the system is running, be offlined/onlined or moved among
> cpupools.
> 
> Therefore, if we have 20 CPUs, even if we put 10 in each runqueue at
> boot, if the admin removes 4 CPUs that happened to be all in the same
> runqueue, we end up in an unbalanced (6 vs 10) situation again. So we'd
> indeed need full runqueue online rebalancing logic, which will probably
> end up being quite complex and I'm not sure it's worth it.
> 
> That being said, I can try to make things a bit more fair, when CPUs
> come up and are added to the pool. Something around the line of adding
> them to the runqueue with the least number of CPUs in it (among the
> suitable ones, of course).
> 
> With that, when the user removes 4 CPUs, we will have the 6 vs 10
> situation. But we would make sure that, when she adds them back, we
> will go back to 10 vs. 10, instead than, say, 6 vs 14 or something like
> that.
> 
> Was something like this that you had in mind? And in any case, what do
> you think about it?

Yes, this would be better already.

> 
>>> --- a/xen/common/sched/cpupool.c
>>> +++ b/xen/common/sched/cpupool.c
>>> @@ -37,7 +37,7 @@ static cpumask_t cpupool_locked_cpus;
>>>    
>>>    static DEFINE_SPINLOCK(cpupool_lock);
>>>    
>>> -static enum sched_gran __read_mostly opt_sched_granularity =
>>> SCHED_GRAN_cpu;
>>> +enum sched_gran __read_mostly opt_sched_granularity =
>>> SCHED_GRAN_cpu;
>>
>> Please don't use the global option value, but the per-cpupool one.
>>
> Yep, you're right. Will do.
> 
>>> +/* Additional checks, to avoid separating siblings in different
>>> runqueues. */
>>> +static bool
>>> +cpu_runqueue_smt_match(const struct csched2_runqueue_data *rqd,
>>> unsigned int cpu)
>>> +{
>>> +    unsigned int nr_sibl =
>>> cpumask_weight(per_cpu(cpu_sibling_mask, cpu));
>>
>> Shouldn't you mask away siblings not in the cpupool?
>>
> So, point here is: if I have Pool-0 and Pool-1, each with 2 runqueues
> and CPU 0 is in Pool-1, when I add CPU 1 --which is CPU 0's sibling--
> to Pool-0, I always want to make sure that there is room for both CPUs
> 0 and 1 in the runqueue of Pool-0 where I'm putting it (CPU 0). Even if
> CPU 1 is currently in another pool.
> 
> This way if, in future, CPU 1 is removed from Pool-1 and added to
> Pool-0, I am sure it can go in the same runqueue where CPU 0 is. If I
> don't consider CPUs which currently are in another pool, we risk that
> when/if they're added to this very pool, they'll end up in a different
> runqueue.
> 
> And we don't want that.
> 
> Makes sense?

Yes.

You should add a comment in this regard.

And you should either reject the case of less cpus per queue than
siblings per core, or you should handle this situation. Otherwise you
won't ever find a suitable run-queue. :-)


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 12:55:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 12:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU8iY-00033l-Jv; Thu, 30 Apr 2020 12:55:06 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jU8iY-00033g-74
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 12:55:06 +0000
X-Inumbo-ID: cf7c5754-8ae1-11ea-9a43-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id cf7c5754-8ae1-11ea-9a43-12813bfff9fa;
 Thu, 30 Apr 2020 12:55:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=A+9ZwCAs6Ak667bWqIBnVNtQqduDdWH0n+/Tw5qPVbA=; b=s60S29kZsvnoUaCl6Lxlh4uDGZ
 srVsCXpgMvP6wZbPks0IjiqtATGIVIM53gX/5/Q+nXm5qwPMbiQoZzzIpXjGj8ekcdeKVHBaQwbm4
 XNZ7UC36ul6CTboneaAc0Hw1L/gd2zUm0/NG6rUTiFeJ/9RXsFzxtH0eg4qopErKE8rM=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jU8iR-00033y-18; Thu, 30 Apr 2020 12:54:59 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jU8iQ-0002Gt-QC; Thu, 30 Apr 2020 12:54:58 +0000
Subject: Re: [PATCH 0/12] direct-map DomUs
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <4a62c7c1-710f-21a9-a6cc-03aa290e18b1@xen.org>
 <alpine.DEB.2.21.2004291313030.28941@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <91b9d1d9-6e6f-c8b9-55ac-a3477b20a17b@xen.org>
Date: Thu, 30 Apr 2020 13:54:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004291313030.28941@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Artem_Mygaiev@epam.com, peng.fan@nxp.com, andrew.cooper3@citrix.com,
 George.Dunlap@citrix.com, Bertrand.Marquis@arm.com, jbeulich@suse.com,
 xen-devel@lists.xenproject.org, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Stefano,

On 29/04/2020 21:16, Stefano Stabellini wrote:
> On Thu, 16 Apr 2020, Julien Grall wrote:
>>> Stefano Stabellini (12):
>>>         xen: introduce xen_dom_flags
>>>         xen/arm: introduce arch_xen_dom_flags and direct_map
>>>         xen/arm: introduce 1:1 mapping for domUs
>>>         xen: split alloc_heap_pages in two halves for reusability
>>>         xen: introduce reserve_heap_pages
>>>         xen/arm: reserve 1:1 memory for direct_map domUs
>>>         xen/arm: new vgic: rename vgic_cpu/dist_base to c/dbase
>>>         xen/arm: if is_domain_direct_mapped use native addresses for GICv2
>>>         xen/arm: if is_domain_direct_mapped use native addresses for GICv3
>>>         xen/arm: if is_domain_direct_mapped use native UART address for vPL011
>>
>> The 3 patches above cover addresses but not interrupts. Why?
> 
> Hi Julien,
> 
> I take that you are referring to GUEST_VPL011_SPI, right?

GUEST_VPL011_SPI is at least one of them. For long term, we may want to 
consider PPIs as well (e.g timer).

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 12:55:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 12:55:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU8j4-000370-T9; Thu, 30 Apr 2020 12:55:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jU8j4-00036p-6K
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 12:55:38 +0000
X-Inumbo-ID: e297f320-8ae1-11ea-9a43-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e297f320-8ae1-11ea-9a43-12813bfff9fa;
 Thu, 30 Apr 2020 12:55:36 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id B3D4CAE84;
 Thu, 30 Apr 2020 12:55:34 +0000 (UTC)
Subject: Re: [PATCH v6 10/15] efi: switch to new APIs in EFI code
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587735799.git.hongyxia@amazon.com>
 <f5fba4470f6d0a6a62e9e2139d6ef260a5c901f9.1587735799.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <b5ca6bf6-d093-f8d7-0adc-29356590f0a7@suse.com>
Date: Thu, 30 Apr 2020 14:55:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <f5fba4470f6d0a6a62e9e2139d6ef260a5c901f9.1587735799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 16:09, Hongyan Xia wrote:
> --- a/xen/arch/x86/efi/runtime.h
> +++ b/xen/arch/x86/efi/runtime.h
> @@ -1,12 +1,18 @@
> +#include <xen/domain_page.h>
> +#include <xen/mm.h>
>  #include <asm/atomic.h>
>  #include <asm/mc146818rtc.h>
>  
>  #ifndef COMPAT
> -l4_pgentry_t *__read_mostly efi_l4_pgtable;
> +mfn_t __read_mostly efi_l4_mfn = INVALID_MFN_INITIALIZER;
>  
>  void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e)
>  {
> -    if ( efi_l4_pgtable )
> +    if ( !mfn_eq(efi_l4_mfn, INVALID_MFN) )
> +    {
> +        l4_pgentry_t *efi_l4_pgtable = map_domain_page(efi_l4_mfn);
>          l4e_write(efi_l4_pgtable + l4idx, l4e);

Blank line between declaration(s) and statement(s) please.

Also, while I realize the choice of name of the local variable
is (presumably) to avoid further code churn, I think it isn't
really suitable for a local variable (also elsewhere below).

> @@ -1489,6 +1493,7 @@ static bool __init rt_range_valid(unsigned long smfn, unsigned long emfn)
>  void __init efi_init_memory(void)
>  {
>      unsigned int i;
> +    l4_pgentry_t *efi_l4_pgtable;
>      struct rt_extra {
>          struct rt_extra *next;
>          unsigned long smfn, emfn;
> @@ -1603,8 +1608,9 @@ void __init efi_init_memory(void)
>       * Set up 1:1 page tables for runtime calls. See SetVirtualAddressMap() in
>       * efi_exit_boot().
>       */
> -    efi_l4_pgtable = alloc_xen_pagetable();
> -    BUG_ON(!efi_l4_pgtable);
> +    efi_l4_mfn = alloc_xen_pagetable_new();
> +    BUG_ON(mfn_eq(efi_l4_mfn, INVALID_MFN));
> +    efi_l4_pgtable = map_domain_page(efi_l4_mfn);
>      clear_page(efi_l4_pgtable);
>  
>      copy_mapping(0, max_page, ram_range_valid);

Why don't you pass the already mapped L4 table into this function,
rather than mapping the same page a 2nd time there?

> @@ -1681,11 +1693,17 @@ void __init efi_init_memory(void)
>              extra_head = extra->next;
>              xfree(extra);
>          }
> +
> +        unmap_domain_page(l1t);
> +        unmap_domain_page(pl2e);
> +        unmap_domain_page(pl3e);

All three should be pulled further up, each to the earliest
possible place (and then using the uppercase version of the
construct as suitable).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 13:01:49 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 13:01:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU8ow-00040I-Mo; Thu, 30 Apr 2020 13:01:42 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jU8ov-00040B-Dn
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 13:01:41 +0000
X-Inumbo-ID: bb57e79d-8ae2-11ea-9a44-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bb57e79d-8ae2-11ea-9a44-12813bfff9fa;
 Thu, 30 Apr 2020 13:01:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=lIURlg8nYfs0ZUyF0+k0do0WTwB1qNS01kZoRIe5i3Q=; b=OijnRJ2q1Sb6GsHDVJb012sN6r
 Qt46Rz1cIKm3Trsw1StgPMP2H3BliSDGMSdz/qY5RfIt8f/G19F3G1ccirWKmwMW1BInu4nJYad38
 dPeaBhjwSAhQ0IVrvUl75hl78eONbhqjW18cp45qeEm6MwwfSxz08v9UjSgW77cke7Yk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jU8os-0003Er-FB; Thu, 30 Apr 2020 13:01:38 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jU8os-0002sS-6s; Thu, 30 Apr 2020 13:01:38 +0000
Subject: Re: [PATCH 12/12] xen/arm: call iomem_permit_access for passthrough
 devices
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-12-sstabellini@kernel.org>
 <521c8e55-73e8-950f-2d94-70b0c664bd3d@xen.org>
 <alpine.DEB.2.21.2004291318270.28941@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <f7f01eca-2415-e102-318f-0c58606fda96@xen.org>
Date: Thu, 30 Apr 2020 14:01:36 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004291318270.28941@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Stefano,

On 29/04/2020 21:47, Stefano Stabellini wrote:
> On Wed, 15 Apr 2020, Julien Grall wrote: 
> But doesn't it make sense to give domU permission if it is going to get
> the memory mapped? But admittedly I can't think of something that would
> break because of the lack of the iomem_permit_access call in this code
> path.

On Arm, the permissions are only useful if you plan you DomU to delegate 
the regions to another domain. As your domain is not even aware it is 
running on Xen (we don't expose 'xen' node in the DT), it makes little 
sense to add the permission.

Even today, you can map IOMEM to a DomU and then revert the permission 
right after. They IOMEM will still be mapped in the guest and it will 
act normaly.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 13:37:17 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 13:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU9N3-0006V1-GH; Thu, 30 Apr 2020 13:36:57 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rLHY=6O=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jU9N2-0006Uu-7U
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 13:36:56 +0000
X-Inumbo-ID: a7c6f538-8ae7-11ea-9a4e-12813bfff9fa
Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id a7c6f538-8ae7-11ea-9a4e-12813bfff9fa;
 Thu, 30 Apr 2020 13:36:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588253815;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=tKHTrswLZqWU3bWqcbH3P8MMvB8kyTpecbbl/gntUO0=;
 b=KnwXkBykeIlEWHRQvepS7cDMOjF/FKQrZ57H215alZDdaboRoZApI+Hc
 6I4gQCgsIVdGhWwIHxLNEdNZvzKQcLzFh2IuH0ow8MmuzZZK5q4icsVgj
 UpPdN9uIVLaQQiZCyjEI76MtXKgPaSXHM0S9WLolyacEKXYtRaDexjNTL Q=;
Authentication-Results: esa3.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: J4vXe4bX9qcPev/7haIPJkvCvNDM02JO93GIZDG+WVj25KobvXl79siOIpkLu/JVhikakFRBV4
 Thw2N1T2clWjzIsYZQDfwRCkxGINUsVYOXQT92cGIZpHp1jZUHciIHYRW0vXPrGFdOeioykKbS
 cPMKng/8czHOmL7n069LFs/29knDovUgKDfxYNntxWssAQAR6HU3jr6BFH3IYTCGeZlNS27KjV
 jcQNBscdfXNzA4mywFbCkgaYNaO+rhz9nW0mQX5vQeTR9Lb/Oy7bEyE3TNSxOR4NWZCZ1viXfr
 UuI=
X-SBRS: 2.7
X-MesageID: 16494974
X-Ironport-Server: esa3.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,336,1583211600"; d="scan'208";a="16494974"
Subject: Re: [PATCH] x86/EFI: correct section offsets in mkreloc diagnostics
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>
References: <5708d246-694a-424f-0998-261f26ccd118@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <917b9609-56d9-2e63-819f-2ed5e2741025@citrix.com>
Date: Thu, 30 Apr 2020 14:36:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5708d246-694a-424f-0998-261f26ccd118@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30/04/2020 11:24, Jan Beulich wrote:
> These are more helpful if they point at the address where the relocated
> value starts, rather than at the specific byte of the difference.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 13:51:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 13:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU9bJ-00085F-Q6; Thu, 30 Apr 2020 13:51:41 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jU9bH-00085A-Lr
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 13:51:39 +0000
X-Inumbo-ID: b6e6dcb6-8ae9-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b6e6dcb6-8ae9-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 13:51:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=+yo8jQWDE6EDVgFXhgJvePM3Ow/54L7D3f3iwH/OW0I=; b=ugX7VFld/NDBY5+IF/qpjs/47Q
 tyolP1uI+0Z8JJ83ZNbwDK5JS2apl7yW32OiF83RSGtY1BCp1nhR1M9unp65I7PBdzoca7YErS729
 MS8QVmkhQpoB7YnB1QbVjIoTEbn+gOrg0/JIjuvNAhDpOCltPDNliT3F5gCjXpqkbdso=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jU9bF-00047Y-DC; Thu, 30 Apr 2020 13:51:37 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jU9bF-00060C-63; Thu, 30 Apr 2020 13:51:37 +0000
Subject: Re: [PATCH 11/12] xen/arm: if xen_force don't try to setup the IOMMU
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-11-sstabellini@kernel.org>
 <4b4263ba-bf6f-e578-037d-edb8add52aad@xen.org>
 <alpine.DEB.2.21.2004291400340.28941@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <b60d6ae3-e300-04a1-a884-e73d01a108d5@xen.org>
Date: Thu, 30 Apr 2020 14:51:35 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004291400340.28941@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Stefano,

On 29/04/2020 22:55, Stefano Stabellini wrote:
> On Wed, 15 Apr 2020, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 15/04/2020 02:02, Stefano Stabellini wrote:
>>> If xen_force (which means xen,force-assign-without-iommu was requested)
>>> don't try to add the device to the IOMMU. Return early instead.
>>
>>
>> Could you explain why this is an issue to call xen_force after
>> iommu_add_dt_device()?
> 
> There are two issues. I should add info about both of them to the commit
> message.
> 
> 
> The first issue is that an error returned by iommu_add_dt_device (for
> any reason) would cause handle_passthrough_prop to stop and return error
> right away. But actually the iommu is not needed for that device if
> xen_force is set.

During boot, Xen will configure the IOMMUs to fault on any DMA 
transactions that are not valid. So if you don't call 
iommu_assign_dt_device(), then your device will be unusable.

Without your patch, the user will know directly something went wrong. 
With your patch, the fault may occur much later and be more difficult to 
diagnostics.

> (In fact, one of the reasons why a user might want to set
> force-assign-without-iommu is because there are iommu issues with a
> device.)
This would not work because of the reasons I explained above. The only 
way would be to configure the IOMMU in bypass mode for that device.

So you would still need to call the IOMMU subsystem.

> 
> 
> The second issue is about the usage of "xen,force-assign-without-iommu":
> it would be useful to let the user set "xen,force-assign-without-iommu"
> for devices that are described as behind a SMMU in device tree, but
> the SMMU can't actually be used for some reason. Of course, the user
> could always manually edit the device tree to make it look like as if
> the device is not behind an IOMMU. That would work OK. However, I think
> it would be better to avoid making that a requirement.

 From the documentation:

"If xen,force-assign-without-iommu is present, Xen allows to assign a
device even if it is not behind an IOMMU. This renders your platform
*unsafe* if the device is DMA-capable."

xen,force-assign-without-iommu was never meant to be used if the device 
is protected behind an IOMMU. If you want to do that, then your patch is 
not going to be sufficient (see why above).

> 
> If we want to allow "xen,force-assign-without-iommu" for a device behind
> a SMMU then we need this patch, otherwise this would happen:
> 
>      res = iommu_add_dt_device(node); // succeeds
>      if ( xen_force && !dt_device_is_protected(node) ) // fails because the device is protected
>          return 0;
>      return iommu_assign_dt_device(kinfo->d, node); // fails because !is_iommu_enabled(d) which is fine but then handle_prop_pfdt returns error too

You are mixing two things here... xen,force-assign-without-iommu doesn't 
have a say on whether the IOMMU will be used for a domain. This decision 
is only based on whether a partial DT exists and (with your patch #3) 
whether the DomU memory is direct mapped.

The problem here is your are not enabling the IOMMU when a direct 
mapping is used. I don't think we want the direct mapping option to 
disable the IOMMU. This should be a separate option (maybe a bool 
property iommu).

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:02:13 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU9lL-0000c9-Sq; Thu, 30 Apr 2020 14:02:03 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=0VdV=6O=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jU9lK-0000c4-O6
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:02:02 +0000
X-Inumbo-ID: 29e57f6e-8aeb-11ea-9a55-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 29e57f6e-8aeb-11ea-9a55-12813bfff9fa;
 Thu, 30 Apr 2020 14:02:01 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E2E1EAC24;
 Thu, 30 Apr 2020 14:01:59 +0000 (UTC)
Message-ID: <93b8fef9e1ec7a06fac3a697276d43564118df5b.camel@suse.com>
Subject: Re: [PATCH 2/2] xen: credit2: limit the max number of CPUs in a
 runqueue
From: Dario Faggioli <dfaggioli@suse.com>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, 
 xen-devel@lists.xenproject.org
Date: Thu, 30 Apr 2020 16:01:59 +0200
In-Reply-To: <7e039c65-4532-c3ea-8707-72a86cf48e0e@suse.com>
References: <158818022727.24327.14309662489731832234.stgit@Palanthas>
 <158818179558.24327.11334680191217289878.stgit@Palanthas>
 <b368ccef-d3b1-1338-6325-8f81a963876d@suse.com>
 <d60d5b917d517b1dfa8292cfb456639c736ec173.camel@suse.com>
 <7e039c65-4532-c3ea-8707-72a86cf48e0e@suse.com>
Organization: SUSE
Content-Type: multipart/signed; micalg="pgp-sha256";
 protocol="application/pgp-signature"; boundary="=-JpCMH30dOivjgC0gYGpK"
User-Agent: Evolution 3.36.1 
MIME-Version: 1.0
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--=-JpCMH30dOivjgC0gYGpK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2020-04-30 at 14:52 +0200, J=C3=BCrgen Gro=C3=9F wrote:
> On 30.04.20 14:28, Dario Faggioli wrote:
> > On Thu, 2020-04-30 at 09:35 +0200, J=C3=BCrgen Gro=C3=9F wrote:
> > >=20
> > With that, when the user removes 4 CPUs, we will have the 6 vs 10
> > situation. But we would make sure that, when she adds them back, we
> > will go back to 10 vs. 10, instead than, say, 6 vs 14 or something
> > like
> > that.
> >=20
> > Was something like this that you had in mind? And in any case, what
> > do
> > you think about it?
>=20
> Yes, this would be better already.
>=20
Right, I'll give a try at this, and let's see how it ends up looking
like.

> > This way if, in future, CPU 1 is removed from Pool-1 and added to
> > Pool-0, I am sure it can go in the same runqueue where CPU 0 is. If
> > I
> > don't consider CPUs which currently are in another pool, we risk
> > that
> > when/if they're added to this very pool, they'll end up in a
> > different
> > runqueue.
> >=20
> > And we don't want that.
> >=20
> Yes.
>=20
Cool. :-)

> You should add a comment in this regard.
>=20
Sure.

> And you should either reject the case of less cpus per queue than
> siblings per core, or you should handle this situation. Otherwise you
> won't ever find a suitable run-queue. :-)
>=20
Right, and in fact I had a check for that, rejecting smaller
max-cpus-per-runqueue than siblings, where we validate also the other
scheduling parameters. But indeed it's not there now, so I guess I
removed it by mistake before sending.

And now that I double check, I'm also missing documenting the new
parameters.

Thanks and Regards
--=20
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


--=-JpCMH30dOivjgC0gYGpK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl6q2lcACgkQFkJ4iaW4
c+4Xcw//WRmKpUHFdXw9LvUblxoFqFfZvlP84rWjxNCdaRpL87ZI2Emd3hMVUhvD
JR+L1VJgkxKWossI1kVQ5GPp/7N2LUitvqke57BAkqO87hcQGRigB4/CWGgBQH67
wEXMCzROWdmjIsAzqxmiSYK/7Gyx619rdlK0ewyQri/mt0nrxbVCIX/88DgtxGi9
vE6SEO7U21uHc9+eaD45sHwx0Axr6l6sfglMzJkz2H1YGpFaWOBZn8MAH2Wt+rNp
pQCpaO9DEX+cdDpglBwXp1XqQ1kcZ7tLHu3CpLUXAWOn6sioSRZ/jczl6gCeT7Er
mupydr088uHRO/sFXxtPDF+yiLVT/m6w9/wzaJ41wUVYmj8W/9lcB2bJ7ihVRSGr
b9yeIbVGuAoXHbkcaFYaDLVd0ld4SfH0xEgyN4UbaUs85zzMM5EpwuZ1V4zSpDBO
ASj/lBC1G/uZS+jQqL0mnJOf+VsPwmNmt9xDCubv6cgmPERxf4OE/SVrjAKZknuM
glN/u3wsTbAVcoc88sqrRtfgWkZPDo4ui4RSryPMGG5cRaYoxD+3z4TuL6m6zEb/
9jYMTBCNtuNdm+cubY5YcieL0ezIN3K9KlJQwDvFwbmTuY6RJD913iixSseymaXf
jPLYYIouG5l+TwTK8Ttync5TNR6K55hzKpIxIruQI7rb0LUHngk=
=0QnT
-----END PGP SIGNATURE-----

--=-JpCMH30dOivjgC0gYGpK--



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:10:25 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jU9tK-0001Sf-Q1; Thu, 30 Apr 2020 14:10:18 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DLrL=6O=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jU9tJ-0001Sa-Jb
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:10:17 +0000
X-Inumbo-ID: 4f4f40a6-8aec-11ea-9a5b-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4f4f40a6-8aec-11ea-9a5b-12813bfff9fa;
 Thu, 30 Apr 2020 14:10:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=9MXkjsDUUt1XSoMIc8i0fVdYPcYtn5tPEW5Y1X/BRls=; b=BbW2XiRSMkPp0AduzOM3sGIXb
 O4D7m8IUkYY0A+d/Cl4aOWVDwx4/X7WGfkOOytYImoHMp99mzUy+muXN8LhXA6FFOcgoJx2Rkuk+Z
 AATEM6to3Zo2tbOuuPF34QE02Ji1Buh+zrPJZx/gxst1RTz1sjQOQnkwKRIXsOAGfRWfw=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jU9tG-0004YU-Br; Thu, 30 Apr 2020 14:10:14 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jU9tF-0004vM-Lq; Thu, 30 Apr 2020 14:10:13 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jU9tF-0003EF-Ko; Thu, 30 Apr 2020 14:10:13 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149886-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [libvirt test] 149886: regressions - FAIL
X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression
 libvirt:build-i386-libvirt:libvirt-build:fail:regression
 libvirt:build-arm64-libvirt:libvirt-build:fail:regression
 libvirt:build-armhf-libvirt:libvirt-build:fail:regression
 libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
 libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
 libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
X-Osstest-Versions-This: libvirt=c4ccb0d0ce57264361dd2ca704f9037935f7f44d
X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 30 Apr 2020 14:10:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149886 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149886/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-i386-libvirt            6 libvirt-build            fail REGR. vs. 146182
 build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 146182
 build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  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-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   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-pair  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              c4ccb0d0ce57264361dd2ca704f9037935f7f44d
baseline version:
 libvirt              a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z  104 days
Failing since        146211  2020-01-18 04:18:52 Z  103 days   96 attempts
Testing same since   149870  2020-04-29 04:18:52 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@redhat.com>
  Arnaud Patard <apatard@hupstream.com>
  Bjoern Walk <bwalk@linux.ibm.com>
  Boris Fiuczynski <fiuczy@linux.ibm.com>
  Chen Hanxiao <chen_han_xiao@126.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christian Ehrhardt <christian.ehrhardt@canonical.com>
  Christian Schoenebeck <qemu_oss@crudebyte.com>
  Collin Walling <walling@linux.ibm.com>
  Cornelia Huck <cohuck@redhat.com>
  Daniel Henrique Barboza <danielhb413@gmail.com>
  Daniel P. Berrangé <berrange@redhat.com>
  Daniel Veillard <veillard@redhat.com>
  Dario Faggioli <dfaggioli@suse.com>
  Erik Skultety <eskultet@redhat.com>
  Gaurav Agrawal <agrawalgaurav@gnome.org>
  Han Han <hhan@redhat.com>
  Jamie Strandboge <jamie@canonical.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  Jonathon Jongsma <jjongsma@redhat.com>
  Julio Faracco <jcfaracco@gmail.com>
  Ján Tomko <jtomko@redhat.com>
  Laine Stump <laine@redhat.com>
  Leonid Bloch <lb.workbox@gmail.com>
  Lin Ma <LMa@suse.com>
  Marc-André Lureau <marcandre.lureau@redhat.com>
  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
  Mark Asselstine <mark.asselstine@windriver.com>
  Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
  Pavel Hrdina <phrdina@redhat.com>
  Pavel Mores <pmores@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Philipp Hahn <hahn@univention.de>
  Pino Toscano <ptoscano@redhat.com>
  Prathamesh Chavan <pc44800@gmail.com>
  Rafael Fonseca <r4f4rfs@gmail.com>
  Richard W.M. Jones <rjones@redhat.com>
  Rikard Falkeborn <rikard.falkeborn@gmail.com>
  Ryan Moeller <ryan@iXsystems.com>
  Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
  Sebastian Mitterle <smitterl@redhat.com>
  Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
  Stefan Berger <stefanb@linux.ibm.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@redhat.com>
  Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com>
  Wu Qingliang <wuqingliang4@huawei.com>
  Yi Li <yili@winhong.com>
  Your Name <you@example.com>
  Zhang Bo <oscar.zhangbo@huawei.com>
  zhenwei pi <pizhenwei@bytedance.com>
  Zhimin Feng <fengzhimin1@huawei.com>

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-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 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-pair                                blocked 
 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 16767 lines long.)


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:24:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUA6g-0002Nh-3E; Thu, 30 Apr 2020 14:24:06 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jUA6e-0002Nc-DH
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:24:04 +0000
X-Inumbo-ID: 3e2565a4-8aee-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3e2565a4-8aee-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 14:24:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=KtVkbXu8J5JaGQD+k1yDh6PpeQLj0A24a9hSkroZ2KU=; b=Zak6+IyG11Qz92Hr5YIT3Sqldu
 79Bg6dN4L8SzIlAywr8lXvRWdGUZapaDv/vkFzSyvPY49yJESYSEVzWd7x4xnU0G1JIRIIm5YSrv2
 CssDX5S3P3Lfx8ndQfwjeVLCqY6zooBg1xoGYjEdYZWPCBxygmv4gQR5puZCqC4hNlAo=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jUA6d-0004nT-He; Thu, 30 Apr 2020 14:24:03 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jUA6d-0008PW-9O; Thu, 30 Apr 2020 14:24:03 +0000
Subject: Re: [PATCH 0/2] xen: Allow EXPERT mode to be selected from the
 menuconfig directly
To: xen-devel@lists.xenproject.org
References: <20200430124343.29886-1-julien@xen.org>
From: Julien Grall <julien@xen.org>
Message-ID: <18bed481-1d94-c1ec-b5d0-381bd50fd99a@xen.org>
Date: Thu, 30 Apr 2020 15:24:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200430124343.29886-1-julien@xen.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Julien Grall <jgrall@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hmmm I have just realized I forgot to CC the REST.

I will resend it.

On 30/04/2020 13:43, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Hi all,
> 
> This small series is meant to make easier to experiment when using Xen.
> See patch #2 for more details.
> 
> Cheers,
> 
> Julien Grall (2):
>    xen/Kconfig: define EXPERT a bool rather than a string
>    xen: Allow EXPERT mode to be selected from the menuconfig directly
> 
>   xen/Kconfig                     | 11 +++++++++--
>   xen/Kconfig.debug               |  2 +-
>   xen/Makefile                    |  1 -
>   xen/arch/arm/Kconfig            | 10 +++++-----
>   xen/arch/x86/Kconfig            |  6 +++---
>   xen/common/Kconfig              | 14 +++++++-------
>   xen/common/sched/Kconfig        |  2 +-
>   xen/drivers/passthrough/Kconfig |  2 +-
>   8 files changed, 27 insertions(+), 21 deletions(-)
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:25:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:25:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUA8Q-0002Ti-Il; Thu, 30 Apr 2020 14:25:54 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jUA8P-0002Tb-Uk
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:25:53 +0000
X-Inumbo-ID: 7f56f5d9-8aee-11ea-9a5e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 7f56f5d9-8aee-11ea-9a5e-12813bfff9fa;
 Thu, 30 Apr 2020 14:25:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=VG7WoWnaGl+DZRy7pGG9xLC9EEM8+3BR/79Re4z8n4s=; b=EL1dZ/8QA3DZGj7aZ1KBq9k29B
 GkvEypeT6Mu8qlrLpWTCeFxz40vN5pcWhMq59H0QIonaJ4tEbrU9U4WeZduRb+tI2gAX/X9X5pIxx
 mXvL4IN4XYO5ow/N0GaLSTjw9ULGGbG6CvAR2JEtcYiNzYYnfQKrhG7nSxZcwHig63Zw=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jUA8N-0004p9-QR; Thu, 30 Apr 2020 14:25:51 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jUA8N-0008UY-GJ; Thu, 30 Apr 2020 14:25:51 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH RESEND 0/2] xen: Allow EXPERT mode to be selected from the
 menuconfig directly
Date: Thu, 30 Apr 2020 15:25:46 +0100
Message-Id: <20200430142548.23751-1-julien@xen.org>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Dario Faggioli <dfaggioli@suse.com>,
 Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Hi all,

This is a resend as I forgot to CC the maintainers.

This small series is meant to make easier to experiment when using Xen.
See patch #2 for more details.

Cheers,

Julien Grall (2):
  xen/Kconfig: define EXPERT a bool rather than a string
  xen: Allow EXPERT mode to be selected from the menuconfig directly

 xen/Kconfig                     | 11 +++++++++--
 xen/Kconfig.debug               |  2 +-
 xen/Makefile                    |  1 -
 xen/arch/arm/Kconfig            | 10 +++++-----
 xen/arch/x86/Kconfig            |  6 +++---
 xen/common/Kconfig              | 14 +++++++-------
 xen/common/sched/Kconfig        |  2 +-
 xen/drivers/passthrough/Kconfig |  2 +-
 8 files changed, 27 insertions(+), 21 deletions(-)

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:25:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:25:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUA8S-0002UD-TW; Thu, 30 Apr 2020 14:25:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jUA8S-0002U2-2v
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:25:56 +0000
X-Inumbo-ID: 80baa85c-8aee-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 80baa85c-8aee-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 14:25:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=LkqaSMJfdGvWDRCP/rOkol/7V/PWobTan66+EekWFD4=; b=Gjyoe0CU4QC1Jt77HcEX/kccin
 ibpqN7ioH1wzM3XEhjDpLXvnT1oxbThyxSSup3pPoToUWimkWWFC68iYTOMncU2CJ3kkMxVZopYha
 Xg718/tfsBevj5lypkXXEisGmOoICA6r6fFQFNEBsOcqjtJ+ubW+ayp3ygw+FckJNJ3w=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jUA8R-0004pR-8s; Thu, 30 Apr 2020 14:25:55 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jUA8Q-0008UY-Vr; Thu, 30 Apr 2020 14:25:55 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected from the
 menuconfig directly
Date: Thu, 30 Apr 2020 15:25:48 +0100
Message-Id: <20200430142548.23751-3-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200430142548.23751-1-julien@xen.org>
References: <20200430142548.23751-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <jgrall@amazon.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

EXPERT mode is currently used to gate any options that are in technical
preview or not security supported At the moment, the only way to select
it is to use XEN_CONFIG_EXPERT=y on the make command line.

However, if the user forget to add the option of one of the make
command (even a clean), then .config will get rewritten. This may lead
to a rather frustrating experience as it is difficult to diagnostic the
issue.

A lot of the options behind EXPERT would benefit to get more tested in
order to be mark as fully supported in the future.

In order to make easier to experiment, the option EXPERT can now be
selected from the menuconfig rather than make command line. This does
not change the fact a kernel with EXPERT mode selected will not be
security supported.

Signed-off-by: Julien Grall <jgrall@amazon.com>

---

This may require some changes in OSSTest as we select the EXPERT mode
when building (This is necessary for booting Xen on Thunder-X box).
---
 xen/Kconfig  | 10 +++++++++-
 xen/Makefile |  1 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/Kconfig b/xen/Kconfig
index 120b5f412993..34c318bfa2c7 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -35,7 +35,15 @@ config DEFCONFIG_LIST
 	default ARCH_DEFCONFIG
 
 config EXPERT
-	def_bool y if "$(XEN_CONFIG_EXPERT)" = "y"
+	bool "Configure standard Xen features (expert users)"
+	help
+	  This option allows certain base Xen options and settings
+	  to be disabled or tweaked. This is for specialized environments
+	  which can tolerate a "non-standard" Xen.
+	  Only use this if you really know what you are doing.
+	  Xen binaries built with this option enabled are not security
+	  supported.
+	default n
 
 config LTO
 	bool "Link Time Optimisation"
diff --git a/xen/Makefile b/xen/Makefile
index 2b1dacb49754..286f374b549f 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -11,7 +11,6 @@ export XEN_DOMAIN	?= $(shell ([ -x /bin/dnsdomainname ] && /bin/dnsdomainname) |
 export XEN_BUILD_DATE	?= $(shell LC_ALL=C date)
 export XEN_BUILD_TIME	?= $(shell LC_ALL=C date +%T)
 export XEN_BUILD_HOST	?= $(shell hostname)
-export XEN_CONFIG_EXPERT ?= n
 
 # Best effort attempt to find a python interpreter, defaulting to Python 3 if
 # available.  Fall back to just `python` if `which` is nowhere to be found.
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:26:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:26:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUA8W-0002VE-89; Thu, 30 Apr 2020 14:26:00 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jUA8U-0002Uu-Uw
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:25:58 +0000
X-Inumbo-ID: 8017f134-8aee-11ea-9a5e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8017f134-8aee-11ea-9a5e-12813bfff9fa;
 Thu, 30 Apr 2020 14:25:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=B5YPe1nFqxyWzM16OSEtEbJ+OP5IgkIlMTCrJ2yOq/8=; b=Bj5WcbtiqrnuVDwwomTVQsEgXH
 1weYJSdopgBCD2TtgGcuyfywIqqjzCGOUMvUz2SWiS79nXCCPjw+0mVkiBm0SgqCjXlo89J7T649Z
 gr1Hm2rOl/zVeUJQkc+F+pYlAOHM3/WTIH6ipkCNypcB6a4ZE9fAAn35oY+GNamGr30o=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jUA8P-0004pH-P3; Thu, 30 Apr 2020 14:25:53 +0000
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=ufe34d9ed68d054.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jUA8P-0008UY-FQ; Thu, 30 Apr 2020 14:25:53 +0000
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH RESEND 1/2] xen/Kconfig: define EXPERT a bool rather than a
 string
Date: Thu, 30 Apr 2020 15:25:47 +0100
Message-Id: <20200430142548.23751-2-julien@xen.org>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <20200430142548.23751-1-julien@xen.org>
References: <20200430142548.23751-1-julien@xen.org>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Paul Durrant <paul@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Dario Faggioli <dfaggioli@suse.com>,
 Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Julien Grall <jgrall@amazon.com>

Since commit f80fe2b34f08 "xen: Update Kconfig to Linux v5.4" EXPERT
can only have two values (enabled or disabled). So switch from a string
to a bool.

Take the opportunity to replace all "EXPERT = y" to "EXPERT".

Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 xen/Kconfig                     |  3 +--
 xen/Kconfig.debug               |  2 +-
 xen/arch/arm/Kconfig            | 10 +++++-----
 xen/arch/x86/Kconfig            |  6 +++---
 xen/common/Kconfig              | 14 +++++++-------
 xen/common/sched/Kconfig        |  2 +-
 xen/drivers/passthrough/Kconfig |  2 +-
 7 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/xen/Kconfig b/xen/Kconfig
index 073042f46730..120b5f412993 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -35,8 +35,7 @@ config DEFCONFIG_LIST
 	default ARCH_DEFCONFIG
 
 config EXPERT
-	string
-	default y if "$(XEN_CONFIG_EXPERT)" = "y"
+	def_bool y if "$(XEN_CONFIG_EXPERT)" = "y"
 
 config LTO
 	bool "Link Time Optimisation"
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index ee6ee33b69be..fad3050d4f7b 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -11,7 +11,7 @@ config DEBUG
 
 	  You probably want to say 'N' here.
 
-if DEBUG || EXPERT = "y"
+if DEBUG || EXPERT
 
 config CRASH_DEBUG
 	bool "Crash Debugging Support"
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d51f66072e2e..6a43576dac5e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -33,7 +33,7 @@ source "arch/Kconfig"
 
 config ACPI
 	bool
-	prompt "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT = "y"
+	prompt "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT
 	depends on ARM_64
 	---help---
 
@@ -51,7 +51,7 @@ config GICV3
 
 config HAS_ITS
         bool
-        prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
+        prompt "GICv3 ITS MSI controller support" if EXPERT
         depends on GICV3 && !NEW_VGIC
 
 config HVM
@@ -81,7 +81,7 @@ config SBSA_VUART_CONSOLE
 	  SBSA Generic UART implements a subset of ARM PL011 UART.
 
 config ARM_SSBD
-	bool "Speculative Store Bypass Disable" if EXPERT = "y"
+	bool "Speculative Store Bypass Disable" if EXPERT
 	depends on HAS_ALTERNATIVE
 	default y
 	help
@@ -91,7 +91,7 @@ config ARM_SSBD
 	  If unsure, say Y.
 
 config HARDEN_BRANCH_PREDICTOR
-	bool "Harden the branch predictor against aliasing attacks" if EXPERT = "y"
+	bool "Harden the branch predictor against aliasing attacks" if EXPERT
 	default y
 	help
 	  Speculation attacks against some high-performance processors rely on
@@ -108,7 +108,7 @@ config HARDEN_BRANCH_PREDICTOR
 	  If unsure, say Y.
 
 config TEE
-	bool "Enable TEE mediators support" if EXPERT = "y"
+	bool "Enable TEE mediators support" if EXPERT
 	default n
 	help
 	  This option enables generic TEE mediators support. It allows guests
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index a69be983d6f3..3237cb2f31f4 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -112,7 +112,7 @@ config BIGMEM
 	  If unsure, say N.
 
 config HVM_FEP
-	bool "HVM Forced Emulation Prefix support" if EXPERT = "y"
+	bool "HVM Forced Emulation Prefix support" if EXPERT
 	default DEBUG
 	depends on HVM
 	---help---
@@ -132,7 +132,7 @@ config HVM_FEP
 
 config TBOOT
 	def_bool y
-	prompt "Xen tboot support" if EXPERT = "y"
+	prompt "Xen tboot support" if EXPERT
 	select CRYPTO
 	---help---
 	  Allows support for Trusted Boot using the Intel(R) Trusted Execution
@@ -217,7 +217,7 @@ config HYPERV_GUEST
 endif
 
 config MEM_SHARING
-	bool "Xen memory sharing support" if EXPERT = "y"
+	bool "Xen memory sharing support" if EXPERT
 	depends on HVM
 
 endmenu
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index a6914fcae98b..fe9b41f72128 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -12,7 +12,7 @@ config CORE_PARKING
 	bool
 
 config GRANT_TABLE
-	bool "Grant table support" if EXPERT = "y"
+	bool "Grant table support" if EXPERT
 	default y
 	---help---
 	  Grant table provides a generic mechanism to memory sharing
@@ -128,7 +128,7 @@ config KEXEC
 	  If unsure, say Y.
 
 config EFI_SET_VIRTUAL_ADDRESS_MAP
-    bool "EFI: call SetVirtualAddressMap()" if EXPERT = "y"
+    bool "EFI: call SetVirtualAddressMap()" if EXPERT
     ---help---
       Call EFI SetVirtualAddressMap() runtime service to setup memory map for
       further runtime services. According to UEFI spec, it isn't strictly
@@ -139,7 +139,7 @@ config EFI_SET_VIRTUAL_ADDRESS_MAP
 
 config XENOPROF
 	def_bool y
-	prompt "Xen Oprofile Support" if EXPERT = "y"
+	prompt "Xen Oprofile Support" if EXPERT
 	depends on X86
 	---help---
 	  Xen OProfile (Xenoprof) is a system-wide profiler for Xen virtual
@@ -176,7 +176,7 @@ config XSM_FLASK
 
 config XSM_FLASK_AVC_STATS
 	def_bool y
-	prompt "Maintain statistics on the FLASK access vector cache" if EXPERT = "y"
+	prompt "Maintain statistics on the FLASK access vector cache" if EXPERT
 	depends on XSM_FLASK
 	---help---
 	  Maintain counters on the access vector cache that can be viewed using
@@ -249,7 +249,7 @@ config LATE_HWDOM
 	  If unsure, say N.
 
 config ARGO
-	bool "Argo: hypervisor-mediated interdomain communication" if EXPERT = "y"
+	bool "Argo: hypervisor-mediated interdomain communication" if EXPERT
 	---help---
 	  Enables a hypercall for domains to ask the hypervisor to perform
 	  data transfer of messages between domains.
@@ -321,7 +321,7 @@ config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
 	  build becoming overly verbose.
 
 config CMDLINE
-	string "Built-in hypervisor command string" if EXPERT = "y"
+	string "Built-in hypervisor command string" if EXPERT
 	default ""
 	---help---
 	  Enter arguments here that should be compiled into the hypervisor
@@ -354,7 +354,7 @@ config DOM0_MEM
 	  Leave empty if you are not sure what to specify.
 
 config TRACEBUFFER
-	bool "Enable tracing infrastructure" if EXPERT = "y"
+	bool "Enable tracing infrastructure" if EXPERT
 	default y
 	---help---
 	  Enable tracing infrastructure and pre-defined tracepoints within Xen.
diff --git a/xen/common/sched/Kconfig b/xen/common/sched/Kconfig
index 883ac87cab65..61231aacaa1c 100644
--- a/xen/common/sched/Kconfig
+++ b/xen/common/sched/Kconfig
@@ -1,5 +1,5 @@
 menu "Schedulers"
-	visible if EXPERT = "y"
+	visible if EXPERT
 
 config SCHED_CREDIT
 	bool "Credit scheduler support"
diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index e7e62ccd63c3..73f4ad89ecbc 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -14,7 +14,7 @@ config ARM_SMMU
 	  ARM SMMU architecture.
 
 config IPMMU_VMSA
-	bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs" if EXPERT = "y"
+	bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs" if EXPERT
 	depends on ARM_64
 	---help---
 	  Support for implementations of the Renesas IPMMU-VMSA found
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:32:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAFC-0003VS-9x; Thu, 30 Apr 2020 14:32:54 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jUAFB-0003VN-7n
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:32:53 +0000
X-Inumbo-ID: 78fcfcb8-8aef-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 78fcfcb8-8aef-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 14:32:52 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id AD360AEF8;
 Thu, 30 Apr 2020 14:32:50 +0000 (UTC)
Subject: Re: [PATCH 1/2] xen/Kconfig: define EXPERT a bool rather than a string
To: Julien Grall <julien@xen.org>
References: <20200430124343.29886-1-julien@xen.org>
 <20200430124343.29886-2-julien@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <d069d81b-24bf-1aac-3009-63e90a45af4b@suse.com>
Date: Thu, 30 Apr 2020 16:32:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200430124343.29886-2-julien@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Julien Grall <jgrall@amazon.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.2020 14:43, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Since commit f80fe2b34f08 "xen: Update Kconfig to Linux v5.4" EXPERT
> can only have two values (enabled or disabled). So switch from a string
> to a bool.
> 
> Take the opportunity to replace all "EXPERT = y" to "EXPERT".
> 
> Signed-off-by: Julien Grall <jgrall@amazon.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
with a remark:

> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -33,7 +33,7 @@ source "arch/Kconfig"
>  
>  config ACPI
>  	bool
> -	prompt "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT = "y"
> +	prompt "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT
>  	depends on ARM_64
>  	---help---
>  
> @@ -51,7 +51,7 @@ config GICV3
>  
>  config HAS_ITS
>          bool
> -        prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
> +        prompt "GICv3 ITS MSI controller support" if EXPERT
>          depends on GICV3 && !NEW_VGIC

Could I talk you info switching ones like the above (looks like
there aren't further ones) to ...

> @@ -81,7 +81,7 @@ config SBSA_VUART_CONSOLE
>  	  SBSA Generic UART implements a subset of ARM PL011 UART.
>  
>  config ARM_SSBD
> -	bool "Speculative Store Bypass Disable" if EXPERT = "y"
> +	bool "Speculative Store Bypass Disable" if EXPERT

... this more compact form on this occasion?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:33:27 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:33:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAFj-0003ZB-KI; Thu, 30 Apr 2020 14:33:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DLrL=6O=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jUAFi-0003Z5-Qe
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:33:26 +0000
X-Inumbo-ID: 8a10ad43-8aef-11ea-9a60-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8a10ad43-8aef-11ea-9a60-12813bfff9fa;
 Thu, 30 Apr 2020 14:33:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=f2PHan3atFIquIOoFwnOEgYO34CKeS88s5l6wkbaAIs=; b=18wUv/woJppHEfUAG5BRdb2bq
 IArQ1OzGC2OkHT8mNm0T9aac43C3EUr7H4wm4+eyq5hFAcltILDVsFCNXBFRQfvM9bUPnBa0Lajy3
 Zj0QkaG4NQRJWKkJ1qIWhEF7vVB845jwFYFYQ86zAgvSxv/XQtAyGOY15xmz25wiDeG4I=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUAFd-000500-1U; Thu, 30 Apr 2020 14:33:21 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUAFc-0005uh-OB; Thu, 30 Apr 2020 14:33:20 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jUAFc-0005mG-NW; Thu, 30 Apr 2020 14:33:20 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149885-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [qemu-mainline test] 149885: tolerable FAIL - PUSHED
X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable
 qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: qemuu=648db19685b7030aa558a4ddbd3a8e53d8c9a062
X-Osstest-Versions-That: qemuu=a7922a3c81f34f45b1ebc9670a7769edc4c42a43
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 30 Apr 2020 14:33:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149885 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149885/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149877
 test-armhf-armhf-xl-rtds    16 guest-start/debian.repeat fail REGR. vs. 149877

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149877
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149877
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149877
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149877
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149877
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 qemuu                648db19685b7030aa558a4ddbd3a8e53d8c9a062
baseline version:
 qemuu                a7922a3c81f34f45b1ebc9670a7769edc4c42a43

Last test of basis   149877  2020-04-29 14:36:19 Z    0 days
Testing same since   149885  2020-04-30 00:07:29 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  David Gibson <david@gibson.dropbear.id.au>
  Markus Armbruster <armbru@redhat.com>
  Masahiro Yamada <masahiroy@kernel.org>
  Michael S. Tsirkin <mst@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Philippe Mathieu-Daudé <f4bug@amsat.org>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/qemu-xen.git
   a7922a3c81..648db19685  648db19685b7030aa558a4ddbd3a8e53d8c9a062 -> upstream-tested


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:33:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAFo-0003aG-St; Thu, 30 Apr 2020 14:33:32 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/gX9=6O=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jUAFn-0003Zz-Qa
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:33:31 +0000
X-Inumbo-ID: 8eeb9661-8aef-11ea-9a60-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 8eeb9661-8aef-11ea-9a60-12813bfff9fa;
 Thu, 30 Apr 2020 14:33:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588257209;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=5UfxOhG2UO9dRqqHimG4omLldKZGephHFunru/KJUz0=;
 b=eKkYZQCd3ClMslvdMpO9jRInpnDoKBGjH3vehC+ii3UAbigwzLZ++ABd
 8JDGfqH1Jc0YH9+zvkFg21KF8CBq+7+n/OZytupumRz1NdnKx0d6z509J
 /eiqIfkwZpntLB4o5djgxyBzhLZ1SFOHqa7NeUHsc9hKgrjNdoNK3bZ4h E=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: jt56STdCNGd+x9LuHProSxsEaOrOVudPbxSuDBlZ1kXnNGTlCSGApQfXM1AVnJoYbLXOFOfwni
 7eUhQoGby9YjqJi8HrbvVzk4YoMbrJiMBY+uVRL5GTQt/SPIAkjQgbuq0w6EzFJzqLydtFCsX8
 YTx/5L1qsL7UlwMF9wYhOrET5DtLe9odKmaplmMSA5k1/psgAXHMP3TX8hFx+45/pujqizZTwu
 6eHGN8q9Ay5cua+Jc/NAM+SwzrVYX7uc3K5NuXpFXz5942zNfJLIZj4de1+ZGOoh7/scC6Ev+4
 CiM=
X-SBRS: 2.7
X-MesageID: 16825940
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,336,1583211600"; d="scan'208";a="16825940"
Date: Thu, 30 Apr 2020 16:33:21 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/hvm: allow for more fine grained assisted flush
Message-ID: <20200430143321.GE28601@Air-de-Roger>
References: <20200430091725.80656-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20200430091725.80656-1-roger.pau@citrix.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 11:17:25AM +0200, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 814b7020d8..1d41b6e2ea 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4011,17 +4011,42 @@ static void hvm_s3_resume(struct domain *d)
>      }
>  }
>  
> -static bool always_flush(void *ctxt, struct vcpu *v)
> +static bool flush_check(void *mask, struct vcpu *v)
>  {
> -    return true;
> +    return mask ? test_bit(v->vcpu_id, (unsigned long *)mask) : true;
>  }
>  
> -static int hvmop_flush_tlb_all(void)
> +static int hvmop_flush_tlb(XEN_GUEST_HANDLE_PARAM(xen_hvm_flush_tlbs_t) uop)
>  {
> +    xen_hvm_flush_tlbs_t op;
> +    DECLARE_BITMAP(mask, HVM_MAX_VCPUS) = { };
> +    bool valid_mask = false;
> +
>      if ( !is_hvm_domain(current->domain) )
>          return -EINVAL;
>  
> -    return paging_flush_tlb(always_flush, NULL) ? 0 : -ERESTART;
> +    if ( !guest_handle_is_null(uop) )
> +    {
> +        if ( copy_from_guest(&op, uop, 1) )
> +            return -EFAULT;
> +
> +        /*
> +         * TODO: implement support for the other features present in
> +         * xen_hvm_flush_tlbs_t: flushing a specific virtual address and not
> +         * flushing global mappings.
> +         */
> +
> +        if ( op.mask_size > ARRAY_SIZE(mask) )

This should also check that the passed in flags are correct, ie:

if ( op.mask_size > ARRAY_SIZE(mask) ||
     (op.flags & ~(HVMOP_flush_global | HVMOP_flush_va_valid)) )
     return -EINVAL;

Roger.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:50:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:50:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAVv-0005IL-Cj; Thu, 30 Apr 2020 14:50:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jUAVu-0005IG-0H
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:50:10 +0000
X-Inumbo-ID: e2cbade0-8af1-11ea-9a62-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id e2cbade0-8af1-11ea-9a62-12813bfff9fa;
 Thu, 30 Apr 2020 14:50:09 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D402EAC69;
 Thu, 30 Apr 2020 14:50:06 +0000 (UTC)
Subject: Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected from the
 menuconfig directly
To: Julien Grall <julien@xen.org>
References: <20200430142548.23751-1-julien@xen.org>
 <20200430142548.23751-3-julien@xen.org>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <3a4ec020-f626-031e-73a6-b2eee97ab9e8@suse.com>
Date: Thu, 30 Apr 2020 16:50:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200430142548.23751-3-julien@xen.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.2020 16:25, Julien Grall wrote:
> EXPERT mode is currently used to gate any options that are in technical
> preview or not security supported At the moment, the only way to select
> it is to use XEN_CONFIG_EXPERT=y on the make command line.
> 
> However, if the user forget to add the option of one of the make
> command (even a clean), then .config will get rewritten. This may lead
> to a rather frustrating experience as it is difficult to diagnostic the
> issue.

Is / will this still be true after Anthony's rework of the build
system? Right now we already have

clean-targets := %clean
no-dot-config-targets := $(clean-targets) \
                         ...

> A lot of the options behind EXPERT would benefit to get more tested in
> order to be mark as fully supported in the future.

Anyone intending to get an EXPERT-only option fully supported will
need to do focused testing; I don't think we can expect to move
items out of this category just because more people happen to test
something every now and then.

> In order to make easier to experiment, the option EXPERT can now be
> selected from the menuconfig rather than make command line. This does
> not change the fact a kernel with EXPERT mode selected will not be
> security supported.

Well, if I'm not mis-remembering it was on purpose to make it more
difficult for people to declare themselves "experts". FAOD I'm not
meaning to imply I don't see and accept the frustration aspect you
mention further up. The two need to be carefully weighed against
one another.

> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -35,7 +35,15 @@ config DEFCONFIG_LIST
>  	default ARCH_DEFCONFIG
>  
>  config EXPERT
> -	def_bool y if "$(XEN_CONFIG_EXPERT)" = "y"
> +	bool "Configure standard Xen features (expert users)"
> +	help
> +	  This option allows certain base Xen options and settings
> +	  to be disabled or tweaked. This is for specialized environments
> +	  which can tolerate a "non-standard" Xen.
> +	  Only use this if you really know what you are doing.
> +	  Xen binaries built with this option enabled are not security
> +	  supported.
> +	default n

I don't think the last line is needed.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 14:51:48 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 14:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAXS-0005OV-WD; Thu, 30 Apr 2020 14:51:47 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jUAXR-0005OP-T6
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:51:45 +0000
X-Inumbo-ID: 1c3ec5d0-8af2-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 1c3ec5d0-8af2-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 14:51:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=2VrajmXIqltPk4moElm/vF5U3FDPVMpqrn4J/I2nD7U=; b=ziEksKE4bBDdNkyDhm66UPnecO
 kEL3yYDmggIyhZP/6TSX2vjyKPU0jSvNtbmrfHJqbJQxxxBBk6xxd35fXeUsilOyPLFJcQ71t+G/V
 sGb5HF965tNNbXFHCYFYmWtKm5RQKYcsKvXz+LDn3PrHzN4xHERSvok064TyBSkrb6Bs=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jUAXO-0005LP-JS; Thu, 30 Apr 2020 14:51:42 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jUAXO-0001uW-6b; Thu, 30 Apr 2020 14:51:42 +0000
Subject: Re: [PATCH 05/12] xen: introduce reserve_heap_pages
To: Stefano Stabellini <sstabellini@kernel.org>,
 Jan Beulich <jbeulich@suse.com>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-5-sstabellini@kernel.org>
 <3129ab49-5898-9d2e-8fbb-d1fcaf6cdec7@suse.com>
 <alpine.DEB.2.21.2004291510270.28941@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <a316ed70-da35-8be0-a092-d992e56563d2@xen.org>
Date: Thu, 30 Apr 2020 15:51:39 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004291510270.28941@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 "Woodhouse, David" <dwmw@amazon.co.uk>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 29/04/2020 23:46, Stefano Stabellini wrote:
> On Fri, 17 Apr 2020, Jan Beulich wrote:
>> On 15.04.2020 03:02, Stefano Stabellini wrote:
>>> Introduce a function named reserve_heap_pages (similar to
>>> alloc_heap_pages) that allocates a requested memory range. Call
>>> __alloc_heap_pages for the implementation.
>>>
>>> Change __alloc_heap_pages so that the original page doesn't get
>>> modified, giving back unneeded memory top to bottom rather than bottom
>>> to top.
>>
>> While it may be less of a problem within a zone, doing so is
>> against our general "return high pages first" policy.
> 
> Is this something you'd be OK with anyway?
> 
> If not, do you have a suggestion on how to do it better? I couldn't find
> a nice way to do it without code duplication, or a big nasty 'if' in the
> middle of the function.
> 
> 
>>> @@ -1073,7 +1073,42 @@ static struct page_info *alloc_heap_pages(
>>>           return NULL;
>>>       }
>>>   
>>> -    __alloc_heap_pages(&pg, order, memflags, d);
>>> +    __alloc_heap_pages(pg, order, memflags, d);
>>> +    return pg;
>>> +}
>>> +
>>> +static struct page_info *reserve_heap_pages(struct domain *d,
>>> +                                            paddr_t start,
>>> +                                            unsigned int order,
>>> +                                            unsigned int memflags)
>>> +{
>>> +    nodeid_t node;
>>> +    unsigned int zone;
>>> +    struct page_info *pg;
>>> +
>>> +    if ( unlikely(order > MAX_ORDER) )
>>> +        return NULL;
>>> +
>>> +    spin_lock(&heap_lock);
>>> +
>>> +    /*
>>> +     * Claimed memory is considered unavailable unless the request
>>> +     * is made by a domain with sufficient unclaimed pages.
>>> +     */
>>> +    if ( (outstanding_claims + (1UL << order) > total_avail_pages) &&
>>> +          ((memflags & MEMF_no_refcount) ||
>>> +           !d || d->outstanding_pages < (1UL << order)) )
>>> +    {
>>> +        spin_unlock(&heap_lock);
>>> +        return NULL;
>>> +    }
>>
>> Where would such a claim come from? Given the purpose I'd assume
>> the function (as well as reserve_domheap_pages()) can actually be
>> __init. With that I'd then also be okay with them getting built
>> unconditionally, i.e. even on x86.
> 
> Yes, you are right, I'll make the function __init and also remove this
> check on claimed memory.
> 
> 
>>> +    pg = maddr_to_page(start);
>>> +    node = phys_to_nid(start);
>>> +    zone = page_to_zone(pg);
>>> +    page_list_del(pg, &heap(node, zone, order));
>>> +
>>> +    __alloc_heap_pages(pg, order, memflags, d);
>>
>> I agree with Julien in not seeing how this can be safe / correct.
> 
> I haven't seen any issues so far in my testing -- I imagine it is
> because there aren't many memory allocations after setup_mm() and before
> create_domUs()  (which on ARM is called just before
> domain_unpause_by_systemcontroller at the end of start_xen.)

I am not sure why you exclude setup_mm(). Any memory allocated (boot 
allocator, xenheap) can clash with your regions. The main memory 
allocations are for the frametable and dom0. I would say you were lucky 
to not hit them.

> 
> 
> I gave a quick look at David's series. Is the idea that I should add a
> patch to do the following:
> 
> - avoiding adding these ranges to xenheap in setup_mm, wait for later
>    (a bit like reserved_mem regions)

I guess by xenheap, you mean domheap? But the problem is not only for 
domheap, it is also for any memory allocated via the boot allocator. So 
you need to exclude those regions from any possible allocations.

> 
> - in construct_domU, add the range to xenheap and reserve it with reserve_heap_pages

I am afraid you can't give the regions to the allocator and then 
allocate them. The allocator is free to use any page for its own purpose 
or exclude them.

AFAICT, the allocator doesn't have a list of page in use. It only keeps 
track of free pages. So we can make the content of struct page_info to 
look like it was allocated by the allocator.

We would need to be careful when giving a page back to allocator as the 
page would need to be initialized (see [1]). This may not be a concern 
for Dom0less as the domain may never be destroyed but will be for 
correctness PoV.

For LiveUpdate, the original Xen will carve out space to use by the boot 
allocator in the new Xen. But I think this is not necessary in your context.

It should be sufficient to exclude the page from the boot allocators (as 
we do for other modules).

One potential issue that can arise is there is no easy way today to 
differentiate between pages allocated and pages not yet initialized. To 
make the code robust, we need to prevent a page to be used in two 
places. So for LiveUpdate we are marking them with a special value, this 
is used afterwards to check we are effictively using a reserved page.

I hope this helps.

Cheers,

[1] <20200319212150.2651419-2-dwmw2@infradead.org>

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:00:01 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:00:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAfM-0005da-Um; Thu, 30 Apr 2020 14:59:56 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jUAfL-0005dV-U0
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 14:59:55 +0000
X-Inumbo-ID: 403b78ce-8af3-11ea-9a63-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 403b78ce-8af3-11ea-9a63-12813bfff9fa;
 Thu, 30 Apr 2020 14:59:55 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 69801AC6C;
 Thu, 30 Apr 2020 14:59:53 +0000 (UTC)
Subject: Re: [PATCH v6 11/15] x86/smpboot: clone_mapping should have one exit
 path
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587735799.git.hongyxia@amazon.com>
 <7c84de54ad0ae7a2e7c0c36ac7fa43860f8de995.1587735799.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <e128e8d9-ae79-ed51-0d74-8a199fe4a604@suse.com>
Date: Thu, 30 Apr 2020 16:59:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <7c84de54ad0ae7a2e7c0c36ac7fa43860f8de995.1587735799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 16:09, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>

Like for patches 1 and 2 in this series, and as iirc mentioned already
long ago for those, "should" or alike are misleading here: It's not a
mistake that they don't, i.e. this is not a bug fix. You _want_ these
functions to have a single (main) exit path, for subsequent changes of
yours ending up easier.

> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -675,6 +675,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
>      l3_pgentry_t *pl3e;
>      l2_pgentry_t *pl2e;
>      l1_pgentry_t *pl1e;
> +    int rc = -ENOMEM;

Would you mind starting out with 0 here, ...

> @@ -715,7 +716,10 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
>              pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(linear);
>              flags = l1e_get_flags(*pl1e);
>              if ( !(flags & _PAGE_PRESENT) )
> -                return 0;
> +            {
> +                rc = 0;
> +                goto out;
> +            }

... dropping assignment and braces here, and ...

> @@ -724,7 +728,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
>      {
>          pl3e = alloc_xen_pagetable();
>          if ( !pl3e )
> -            return -ENOMEM;
> +            goto out;

... setting rc to -ENOMEM ahead of the if() up from here?
This imo makes things then not only minimally shorter, but
also fights slightly better with the nevertheless still
existing (after this patch) separate early exit paths.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:07:39 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:07:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAmg-0006VT-Q0; Thu, 30 Apr 2020 15:07:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jUAmf-0006VN-15
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:07:29 +0000
X-Inumbo-ID: 4e21efb2-8af4-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4e21efb2-8af4-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 15:07:28 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 63153AE96;
 Thu, 30 Apr 2020 15:07:26 +0000 (UTC)
Subject: Re: Cpu on/offlining crash with core scheduling
To: Sergey Dyasli <sergey.dyasli@citrix.com>
References: <1587995374653.73805@citrix.com>
 <103f3e30-a67e-77b7-9e92-572ee4b5d159@suse.com>
 <1588151726659.12791@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <55301f72-3ce0-9e17-649d-cecd34cb5739@suse.com>
Date: Thu, 30 Apr 2020 17:07:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1588151726659.12791@citrix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 29.04.20 11:15, Sergey Dyasli wrote:
> On 29/04/2020 09:09, Jürgen Groß wrote:
>> On 27.04.20 15:49, Sergey Dyasli wrote:
>>> Hi Juergen,
>>>
>>> When I'm testing vcpu pinning with something like:
>>>
>>>        # xl vcpu-pin 0 0 2
>>>        # xen-hptool cpu-offline 3
>>>
>>>        (offline / online CPUs {2,3} if the above is successful)
>>>
>>> I'm reliably seeing the following crash on the latest staging:
>>>
>>> (XEN) Watchdog timer detects that CPU1 is stuck!
>>> (XEN) ----[ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]----
>>> (XEN) CPU:    1
>>> (XEN) RIP:    e008:[<ffff82d08025266d>] common/sched/core.c#sched_wait_rendezvous_in+0x16c/0x385
>>> (XEN) RFLAGS: 0000000000000002   CONTEXT: hypervisor
>>> (XEN) rax: 000000000000f001   rbx: ffff82d0805c9118   rcx: ffff83085e750301
>>> (XEN) rdx: 0000000000000001   rsi: ffff83086499b972   rdi: ffff83085e7503a6
>>> (XEN) rbp: ffff83085e7dfe28   rsp: ffff83085e7dfdd8   r8:  ffff830864985440
>>> (XEN) r9:  ffff83085e714068   r10: 0000000000000014   r11: 00000056b6a1aab2
>>> (XEN) r12: ffff83086499e490   r13: ffff82d0805f26e0   r14: ffff83085e7503a0
>>> (XEN) r15: 0000000000000001   cr0: 0000000080050033   cr4: 0000000000362660
>>> (XEN) cr3: 0000000823a8e000   cr2: 00006026000f6fc0
>>> (XEN) fsb: 0000000000000000   gsb: ffff888138dc0000   gss: 0000000000000000
>>> (XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
>>> (XEN) Xen code around <ffff82d08025266d> (common/sched/core.c#sched_wait_rendezvous_in+0x16c/0x385):
>>> (XEN)  4c 89 f7 e8 dc a5 fd ff <4b> 8b 44 fd 00 48 8b 04 18 4c 3b 70 10 0f 85 3f
>>> (XEN) Xen stack trace from rsp=ffff83085e7dfdd8:
>>> (XEN)    00000056b42128a6 ffff83086499ff30 ffff83086498a000 ffff83085e7dfe48
>>> (XEN)    0000000100000001 00000056b42128a6 ffff83086499e490 0000000000000000
>>> (XEN)    0000000000000001 0000000000000001 ffff83085e7dfe78 ffff82d080252ae8
>>> (XEN)    ffff83086498a000 0000000180230434 ffff83085e7503a0 ffff82d0805ceb00
>>> (XEN)    ffffffffffffffff ffff82d0805cea80 0000000000000000 ffff82d0805dea80
>>> (XEN)    ffff83085e7dfeb0 ffff82d08022c232 0000000000000001 ffff82d0805ceb00
>>> (XEN)    0000000000000001 0000000000000001 0000000000000001 ffff83085e7dfec0
>>> (XEN)    ffff82d08022c2cd ffff83085e7dfef0 ffff82d08031cae9 ffff83086498a000
>>> (XEN)    ffff83086498a000 0000000000000001 0000000000000001 ffff83085e7dfde8
>>> (XEN)    ffff88813021d700 ffff88813021d700 0000000000000000 0000000000000000
>>> (XEN)    0000000000000007 ffff88813021d700 0000000000000246 0000000000007ff0
>>> (XEN)    0000000000000000 000000000001ca00 0000000000000000 ffffffff810013aa
>>> (XEN)    ffffffff8203d210 deadbeefdeadf00d deadbeefdeadf00d 0000010000000000
>>> (XEN)    ffffffff810013aa 000000000000e033 0000000000000246 ffffc900400dfeb0
>>> (XEN)    000000000000e02b 0000000000000000 0000000000000000 0000000000000000
>>> (XEN)    0000000000000000 0000e01000000001 ffff83086498a000 00000037e43bd000
>>> (XEN)    0000000000362660 0000000000000000 8000000864980002 0000060100000000
>>> (XEN)    0000000000000000
>>> (XEN) Xen call trace:
>>> (XEN)    [<ffff82d08025266d>] R common/sched/core.c#sched_wait_rendezvous_in+0x16c/0x385
>>> (XEN)    [<ffff82d080252ae8>] F common/sched/core.c#sched_slave+0x262/0x31e
>>> (XEN)    [<ffff82d08022c232>] F common/softirq.c#__do_softirq+0x8a/0xbc
>>> (XEN)    [<ffff82d08022c2cd>] F do_softirq+0x13/0x15
>>> (XEN)    [<ffff82d08031cae9>] F arch/x86/domain.c#idle_loop+0x57/0xa7
>>> (XEN)
>>> (XEN) CPU0 @ e008:ffff82d08022c2b7 (process_pending_softirqs+0x53/0x56)
>>> (XEN) CPU4 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callbacks+0x22e/0x24b)
>>> (XEN) CPU2 @ e008:ffff82d08022c26f (process_pending_softirqs+0xb/0x56)
>>> (XEN) CPU7 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callbacks+0x22e/0x24b)
>>> (XEN) CPU3 @ e008:ffff82d08022bc40 (common/rcupdate.c#rcu_process_callbacks+0x22e/0x24b)
>>> (XEN) CPU5 @ e008:ffff82d08022cc34 (_spin_lock+0x4d/0x62)
>>> (XEN) CPU6 @ e008:ffff82d08022c264 (process_pending_softirqs+0/0x56)
>>> (XEN)
>>> (XEN) ****************************************
>>> (XEN) Panic on CPU 1:
>>> (XEN) FATAL TRAP: vector = 2 (nmi)
>>> (XEN) [error_code=0000] , IN INTERRUPT CONTEXT
>>> (XEN) ****************************************
>>> (XEN)
>>> (XEN) Reboot in five seconds...
>>> (XEN) Executing kexec image on cpu1
>>> (XEN) Shot down all CPUs
>>>
>>>
>>> Is this something you can reproduce?
>>
>> Yes, I was able to hit this.
>>
>> Attached patch is fixing it for me. Could you give it a try?
> 
> The patch fixes the immediate issue:
> 
> 	Tested-by: Sergey Dyasli <sergey.dyasli@citrix.com>
> 	
> Thanks!
> 
> However, when running the following script:
> 
> 	while :; do xen-hptool cpu-offline 3; xen-hptool cpu-offline 2; xen-hptool cpu-online 3; xen-hptool cpu-online 2; sleep 0.1; done
> 	
> there was some weirdness with the utility on some invocations:
> 
> 	xen-hptool: symbol lookup error: /lib64/libxenctrl.so.4.14: undefined symbol: xc__hypercall_buffer_free
> 	Segmentation fault (core dumped)
> 	xen-hptool: symbol lookup error: /lib64/libxenctrl.so.4.14: undefined symbol: xc__hypercall_bounce_post
> 	xen-hptool: relocation error: /lib64/libxenctrl.so.4.14: symbol xencall_free_buffer, version VERS_1.0 not defined in file libxencall.so.1 with link time reference

Yes, I can reproduce those, too.

I made several tests and the result is really weird. Even if I do:

xen-hptool cpu-offline 3;       # removes the core from cpupool0
while true; do xen-hptool cpu-offline 2; xen-hptool cpu-online 2; done

I get the same errors after a while. This is really strange, as cpu 2
isn't taking part in any scheduling this way. So why is the running
program (on another cpu) impacted by on/offlining? And to me it looks
like the context of the program is clobbered sometimes. But how?

Patching the hypervisor to not add an onlined cpu to cpupool0 and doing
the same test with cpu scheduling didn't show the problem. The problem
was still there with core scheduling on the patched hypervisor. Even if
the online/offline paths are the same for both scheduling variants
(cpu or core) this way (as far as scheduler online/offline hooks are
concerned).

I suspected context loading or saving to have an issue, but even added
ASSERT()s didn't reveal anything (but I found some at least theoretical
problems, which I have a patch for, and a real bug in cpupool handling).

So I'll send out the patches I have until now and I'll continue trying
to catch this very strange problem. Any ideas what could be the reason
are very welcome. :-)


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:15:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAug-0007Mr-LS; Thu, 30 Apr 2020 15:15:46 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Mtm3=6O=suse.com=jbeulich@srs-us1.protection.inumbo.net>)
 id 1jUAuf-0007Mm-UP
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:15:45 +0000
X-Inumbo-ID: 764d5bb0-8af5-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 764d5bb0-8af5-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 15:15:44 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CF933ABB2;
 Thu, 30 Apr 2020 15:15:42 +0000 (UTC)
Subject: Re: [PATCH v6 12/15] x86/smpboot: switch pl*e to use new APIs in
 clone_mapping
To: Hongyan Xia <hx242@xen.org>
References: <cover.1587735799.git.hongyxia@amazon.com>
 <a1c29e58a5d40748413e8088ad88ba4319a328d4.1587735799.git.hongyxia@amazon.com>
From: Jan Beulich <jbeulich@suse.com>
Message-ID: <88709097-661e-ce7b-1a46-1dcecf029428@suse.com>
Date: Thu, 30 Apr 2020 17:15:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a1c29e58a5d40748413e8088ad88ba4319a328d4.1587735799.git.hongyxia@amazon.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 24.04.2020 16:09, Hongyan Xia wrote:
> From: Wei Liu <wei.liu2@citrix.com>

Nit: Why the emphasis on pl*e in the title? Is there anything left
unconverted in the function? IOW how about "switch clone_mapping()
to new page table APIs"?

> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -672,9 +672,9 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
>  {
>      unsigned long linear = (unsigned long)ptr, pfn;
>      unsigned int flags;
> -    l3_pgentry_t *pl3e;
> -    l2_pgentry_t *pl2e;
> -    l1_pgentry_t *pl1e;
> +    l3_pgentry_t *pl3e = NULL;
> +    l2_pgentry_t *pl2e = NULL;
> +    l1_pgentry_t *pl1e = NULL;

The latter two need initializers, yes, but why pl3e?

> @@ -689,8 +689,8 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
>           (linear >= XEN_VIRT_END && linear < DIRECTMAP_VIRT_START) )
>          return -EINVAL;
>  
> -    pl3e = l4e_to_l3e(idle_pg_table[root_table_offset(linear)]) +
> -        l3_table_offset(linear);
> +    pl3e = map_l3t_from_l4e(idle_pg_table[root_table_offset(linear)]);
> +    pl3e += l3_table_offset(linear);

By keeping original style (a single assignment) you'd have slightly
less of a diff, and I think keeping original style where it's not
colliding with any of our rules is generally a good idea. Doing so
won't even make you hit the slightly flawed definition of
map_l3t_from_l4e() at al (missing outer parentheses). I notice you
do so ...

> @@ -702,7 +702,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
>      }
>      else
>      {
> -        pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(linear);
> +        pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(linear);
>          flags = l2e_get_flags(*pl2e);
>          ASSERT(flags & _PAGE_PRESENT);
>          if ( flags & _PAGE_PSE )
> @@ -713,7 +713,7 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
>          }
>          else
>          {
> -            pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(linear);
> +            pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(linear);

... in both of these cases.

> @@ -724,48 +724,61 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
>          }
>      }
>  
> +    UNMAP_DOMAIN_PAGE(pl1e);
> +    UNMAP_DOMAIN_PAGE(pl2e);
> +    UNMAP_DOMAIN_PAGE(pl3e);
> +
>      if ( !(root_get_flags(rpt[root_table_offset(linear)]) & _PAGE_PRESENT) )
>      {
> -        pl3e = alloc_xen_pagetable();
> -        if ( !pl3e )
> +        mfn_t l3mfn = alloc_xen_pagetable_new();
> +
> +        if ( mfn_eq(l3mfn, INVALID_MFN) )
>              goto out;
> +
> +        pl3e = map_domain_page(l3mfn);

Seeing this recur (from other patches) I wonder whether we wouldn't
better make map_domain_page() accept INVALID_MFN and return NULL in
this case. In cases like the one here it would eliminate the need
for several local variables. Of course the downside of this is that
then we'll have to start checking map_domain_page()'s return value.
A middle ground could be to have

void *alloc_mapped_pagetable(mfn_t *mfn);

allowing to pass in NULL if the MFN is of no interest.

> @@ -781,6 +794,9 @@ static int clone_mapping(const void *ptr, root_pgentry_t *rpt)
>  
>      rc = 0;
>   out:
> +    UNMAP_DOMAIN_PAGE(pl1e);
> +    UNMAP_DOMAIN_PAGE(pl2e);
> +    UNMAP_DOMAIN_PAGE(pl3e);
>      return rc;
>  }

I don't think the writing of NULL into the variables is necessary
here. And if the needed if()-s are of concern, then perhaps we
should consider making unmap_domain_page() finally accept NULL as
input?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:16:05 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAuy-0007OP-Ue; Thu, 30 Apr 2020 15:16:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jUAux-0007OA-Ou
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:16:03 +0000
X-Inumbo-ID: 81319f00-8af5-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 81319f00-8af5-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 15:16:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 4981FAD31;
 Thu, 30 Apr 2020 15:16:01 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 1/3] xen/sched: allow rcu work to happen when syncing cpus in
 core scheduling
Date: Thu, 30 Apr 2020 17:15:57 +0200
Message-Id: <20200430151559.1464-2-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200430151559.1464-1-jgross@suse.com>
References: <20200430151559.1464-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Dario Faggioli <dfaggioli@suse.com>,
 Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

With RCU barriers moved from tasklets to normal RCU processing cpu
offlining in core scheduling might deadlock due to cpu synchronization
required by RCU processing and core scheduling concurrently.

Fix that by bailing out from core scheduling synchronization in case
of pending RCU work. Additionally the RCU softirq is now required to
be of higher priority than the scheduling softirqs in order to do
RCU processing before entering the scheduler again, as bailing out from
the core scheduling synchronization requires to raise another softirq
SCHED_SLAVE, which would bypass RCU processing again.

Reported-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Tested-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/sched/core.c   | 10 +++++++---
 xen/include/xen/softirq.h |  2 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d94b95285f..a099e37b0f 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2457,13 +2457,17 @@ static struct sched_unit *sched_wait_rendezvous_in(struct sched_unit *prev,
             v = unit2vcpu_cpu(prev, cpu);
         }
         /*
-         * Coming from idle might need to do tasklet work.
+         * Check for any work to be done which might need cpu synchronization.
+         * This is either pending RCU work, or tasklet work when coming from
+         * idle.
          * In order to avoid deadlocks we can't do that here, but have to
-         * continue the idle loop.
+         * schedule the previous vcpu again, which will lead to the desired
+         * processing to be done.
          * Undo the rendezvous_in_cnt decrement and schedule another call of
          * sched_slave().
          */
-        if ( is_idle_unit(prev) && sched_tasklet_check_cpu(cpu) )
+        if ( rcu_pending(cpu) ||
+             (is_idle_unit(prev) && sched_tasklet_check_cpu(cpu)) )
         {
             struct vcpu *vprev = current;
 
diff --git a/xen/include/xen/softirq.h b/xen/include/xen/softirq.h
index b4724f5c8b..1f6c4783da 100644
--- a/xen/include/xen/softirq.h
+++ b/xen/include/xen/softirq.h
@@ -4,10 +4,10 @@
 /* Low-latency softirqs come first in the following list. */
 enum {
     TIMER_SOFTIRQ = 0,
+    RCU_SOFTIRQ,
     SCHED_SLAVE_SOFTIRQ,
     SCHEDULE_SOFTIRQ,
     NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ,
-    RCU_SOFTIRQ,
     TASKLET_SOFTIRQ,
     NR_COMMON_SOFTIRQS
 };
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:16:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAv1-0007PY-Bh; Thu, 30 Apr 2020 15:16:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jUAuz-0007Os-Vp
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:16:06 +0000
X-Inumbo-ID: 808ec349-8af5-11ea-9a67-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 808ec349-8af5-11ea-9a67-12813bfff9fa;
 Thu, 30 Apr 2020 15:16:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id E5A86AE39;
 Thu, 30 Apr 2020 15:16:00 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/3] xen: Fix some bugs in scheduling
Date: Thu, 30 Apr 2020 17:15:56 +0200
Message-Id: <20200430151559.1464-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Dario Faggioli <dfaggioli@suse.com>,
 Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Some bugs I found when trying to find a problem with cpu-on/offlining
in core scheduling mode.

Patches 1 and 3 are fixing observed problems, while patch 2 is more
of a theoretical issue.

Juergen Gross (3):
  xen/sched: allow rcu work to happen when syncing cpus in core
    scheduling
  xen/sched: fix theoretical races accessing vcpu->dirty_cpu
  xen/cpupool: fix removing cpu from a cpupool

 xen/arch/x86/domain.c      | 14 ++++++++++----
 xen/common/sched/core.c    | 10 +++++++---
 xen/common/sched/cpupool.c |  3 +++
 xen/include/xen/sched.h    |  2 +-
 xen/include/xen/softirq.h  |  2 +-
 5 files changed, 22 insertions(+), 9 deletions(-)

-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:16:10 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAv4-0007Qi-KQ; Thu, 30 Apr 2020 15:16:10 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jUAv2-0007QH-Qs
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:16:08 +0000
X-Inumbo-ID: 81432d56-8af5-11ea-9887-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 81432d56-8af5-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 15:16:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 62BACADCD;
 Thu, 30 Apr 2020 15:16:01 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 2/3] xen/sched: fix theoretical races accessing vcpu->dirty_cpu
Date: Thu, 30 Apr 2020 17:15:58 +0200
Message-Id: <20200430151559.1464-3-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200430151559.1464-1-jgross@suse.com>
References: <20200430151559.1464-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The dirty_cpu field of struct vcpu denotes which cpu still holds data
of a vcpu. All accesses to this field should be atomic in case the
vcpu could just be running, as it is accessed without any lock held
in most cases.

There are some instances where accesses are not atomically done, and
even worse where multiple accesses are done when a single one would
be mandated.

Correct that in order to avoid potential problems.

Add some assertions to verify dirty_cpu is handled properly.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/arch/x86/domain.c   | 14 ++++++++++----
 xen/include/xen/sched.h |  2 +-
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a4428190d5..f0579a56d1 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1769,6 +1769,7 @@ static void __context_switch(void)
 
     if ( !is_idle_domain(pd) )
     {
+        ASSERT(read_atomic(&p->dirty_cpu) == cpu);
         memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
         vcpu_save_fpu(p);
         pd->arch.ctxt_switch->from(p);
@@ -1832,7 +1833,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 {
     unsigned int cpu = smp_processor_id();
     const struct domain *prevd = prev->domain, *nextd = next->domain;
-    unsigned int dirty_cpu = next->dirty_cpu;
+    unsigned int dirty_cpu = read_atomic(&next->dirty_cpu);
 
     ASSERT(prev != next);
     ASSERT(local_irq_is_enabled());
@@ -1844,6 +1845,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
     {
         /* Remote CPU calls __sync_local_execstate() from flush IPI handler. */
         flush_mask(cpumask_of(dirty_cpu), FLUSH_VCPU_STATE);
+        ASSERT(read_atomic(&next->dirty_cpu) == VCPU_CPU_CLEAN);
     }
 
     _update_runstate_area(prev);
@@ -1956,13 +1958,17 @@ void sync_local_execstate(void)
 
 void sync_vcpu_execstate(struct vcpu *v)
 {
-    if ( v->dirty_cpu == smp_processor_id() )
+    unsigned int dirty_cpu = read_atomic(&v->dirty_cpu);
+
+    if ( dirty_cpu == smp_processor_id() )
         sync_local_execstate();
-    else if ( vcpu_cpu_dirty(v) )
+    else if ( is_vcpu_dirty_cpu(dirty_cpu) )
     {
         /* Remote CPU calls __sync_local_execstate() from flush IPI handler. */
-        flush_mask(cpumask_of(v->dirty_cpu), FLUSH_VCPU_STATE);
+        flush_mask(cpumask_of(dirty_cpu), FLUSH_VCPU_STATE);
     }
+    ASSERT(read_atomic(&v->dirty_cpu) != dirty_cpu ||
+           dirty_cpu == VCPU_CPU_CLEAN);
 }
 
 static int relinquish_memory(
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 195e7ee583..008d3c8861 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -844,7 +844,7 @@ static inline bool is_vcpu_dirty_cpu(unsigned int cpu)
 
 static inline bool vcpu_cpu_dirty(const struct vcpu *v)
 {
-    return is_vcpu_dirty_cpu(v->dirty_cpu);
+    return is_vcpu_dirty_cpu(read_atomic(&v->dirty_cpu));
 }
 
 void vcpu_block(void);
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:16:12 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:16:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAv5-0007Rd-U3; Thu, 30 Apr 2020 15:16:11 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jUAv4-0007R4-Um
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:16:10 +0000
X-Inumbo-ID: 811ec43f-8af5-11ea-9a67-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 811ec43f-8af5-11ea-9a67-12813bfff9fa;
 Thu, 30 Apr 2020 15:16:03 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7ECE7AF4C;
 Thu, 30 Apr 2020 15:16:01 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 3/3] xen/cpupool: fix removing cpu from a cpupool
Date: Thu, 30 Apr 2020 17:15:59 +0200
Message-Id: <20200430151559.1464-4-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
In-Reply-To: <20200430151559.1464-1-jgross@suse.com>
References: <20200430151559.1464-1-jgross@suse.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>, George Dunlap <george.dunlap@citrix.com>,
 Dario Faggioli <dfaggioli@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit cb563d7665f2 ("xen/sched: support core scheduling for moving
cpus to/from cpupools") introduced a regression when trying to remove
an offline cpu from a cpupool, as the system would crash in this
situation.

Fix that by testing the cpu to be online.

Fixes: cb563d7665f2 ("xen/sched: support core scheduling for moving cpus to/from cpupools")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/sched/cpupool.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index d40345b585..de9e25af84 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -520,6 +520,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
     debugtrace_printk("cpupool_unassign_cpu(pool=%d,cpu=%d)\n",
                       c->cpupool_id, cpu);
 
+    if ( !cpu_online(cpu) )
+        return -EINVAL;
+
     master_cpu = sched_get_resource_cpu(cpu);
     ret = cpupool_unassign_cpu_start(c, master_cpu);
     if ( ret )
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:19:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUAyi-0007sy-Fl; Thu, 30 Apr 2020 15:19:56 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jUAyh-0007st-1v
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:19:55 +0000
X-Inumbo-ID: 0a7cdab8-8af6-11ea-ae69-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0a7cdab8-8af6-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 15:19:53 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id A26AFAF01;
 Thu, 30 Apr 2020 15:19:51 +0000 (UTC)
Subject: Re: [PATCH 2/3] xen/sched: fix theoretical races accessing
 vcpu->dirty_cpu
To: xen-devel@lists.xenproject.org
References: <20200430151559.1464-1-jgross@suse.com>
 <20200430151559.1464-3-jgross@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Message-ID: <2bc16586-4937-9019-795d-9e54ea3e2c21@suse.com>
Date: Thu, 30 Apr 2020 17:19:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200430151559.1464-3-jgross@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.20 17:15, Juergen Gross wrote:
> The dirty_cpu field of struct vcpu denotes which cpu still holds data
> of a vcpu. All accesses to this field should be atomic in case the
> vcpu could just be running, as it is accessed without any lock held
> in most cases.
> 
> There are some instances where accesses are not atomically done, and
> even worse where multiple accesses are done when a single one would
> be mandated.
> 
> Correct that in order to avoid potential problems.
> 
> Add some assertions to verify dirty_cpu is handled properly.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Please ignore this one, just realized it doesn't build for ARM.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:28:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUB7H-0000Jf-Ct; Thu, 30 Apr 2020 15:28:47 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jUB7G-0000Ja-Cj
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:28:46 +0000
X-Inumbo-ID: 475b2b64-8af7-11ea-9a69-12813bfff9fa
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id 475b2b64-8af7-11ea-9a69-12813bfff9fa;
 Thu, 30 Apr 2020 15:28:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588260524;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=T1s8bsqlCtfcMFraiOrk2yrc55rOVovm1JQ8SdwbeEg=;
 b=Dk4VKd2IbOe9dfpYAuDwq0GTXTmsbX6fywIg2PGcIEqo+T+Rn6gDqG8TZqDcTlnn0fYbHE
 WqwXHfNDhHzKswlSiaa1zxQ/RgCkxJ2abXA2vgETXJwnHFAYPADSd2QtMY+lkCji19Cv6H
 dxBIpzxv0hMhiVc7yUuOTmn4wCs3jzY=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-263-1QTZbBjaNoGrntGb_zSr5g-1; Thu, 30 Apr 2020 11:28:40 -0400
X-MC-Unique: 1QTZbBjaNoGrntGb_zSr5g-1
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com
 [10.5.11.13])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DE5BF462;
 Thu, 30 Apr 2020 15:28:37 +0000 (UTC)
Received: from [10.36.113.172] (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 9B73267651;
 Thu, 30 Apr 2020 15:28:30 +0000 (UTC)
Subject: Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with
 MHP_NO_FIRMWARE_MEMMAP
To: Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-4-david@redhat.com>
 <20b86ced-7c47-02ca-0e0e-1bd5d6cc95c1@intel.com>
From: David Hildenbrand <david@redhat.com>
Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata=
 mQINBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABtCREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT6JAlgEEwEIAEICGwMFCQlmAYAGCwkIBwMCBhUI
 AgkKCwQWAgMBAh4BAheAFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl3pImkCGQEACgkQTd4Q
 9wD/g1o+VA//SFvIHUAvul05u6wKv/pIR6aICPdpF9EIgEU448g+7FfDgQwcEny1pbEzAmiw
 zAXIQ9H0NZh96lcq+yDLtONnXk/bEYWHHUA014A1wqcYNRY8RvY1+eVHb0uu0KYQoXkzvu+s
 Dncuguk470XPnscL27hs8PgOP6QjG4jt75K2LfZ0eAqTOUCZTJxA8A7E9+XTYuU0hs7QVrWJ
 jQdFxQbRMrYz7uP8KmTK9/Cnvqehgl4EzyRaZppshruKMeyheBgvgJd5On1wWq4ZUV5PFM4x
 II3QbD3EJfWbaJMR55jI9dMFa+vK7MFz3rhWOkEx/QR959lfdRSTXdxs8V3zDvChcmRVGN8U
 Vo93d1YNtWnA9w6oCW1dnDZ4kgQZZSBIjp6iHcA08apzh7DPi08jL7M9UQByeYGr8KuR4i6e
 RZI6xhlZerUScVzn35ONwOC91VdYiQgjemiVLq1WDDZ3B7DIzUZ4RQTOaIWdtXBWb8zWakt/
 ztGhsx0e39Gvt3391O1PgcA7ilhvqrBPemJrlb9xSPPRbaNAW39P8ws/UJnzSJqnHMVxbRZC
 Am4add/SM+OCP0w3xYss1jy9T+XdZa0lhUvJfLy7tNcjVG/sxkBXOaSC24MFPuwnoC9WvCVQ
 ZBxouph3kqc4Dt5X1EeXVLeba+466P1fe1rC8MbcwDkoUo65Ag0EVcufkQEQAOfX3n0g0fZz
 Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
 T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
 CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
 NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
 lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
 AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
 N7eop7uh+6bezi+rugUI+w6DABEBAAGJAiUEGAECAA8FAlXLn5ECGwwFCQlmAYAACgkQTd4Q
 9wD/g1qA6w/+M+ggFv+JdVsz5+ZIc6MSyGUozASX+bmIuPeIecc9UsFRatc91LuJCKMkD9Uv
 GOcWSeFpLrSGRQ1Z7EMzFVU//qVs6uzhsNk0RYMyS0B6oloW3FpyQ+zOVylFWQCzoyyf227y
 GW8HnXunJSC+4PtlL2AY4yZjAVAPLK2l6mhgClVXTQ/S7cBoTQKP+jvVJOoYkpnFxWE9pn4t
 H5QIFk7Ip8TKr5k3fXVWk4lnUi9MTF/5L/mWqdyIO1s7cjharQCstfWCzWrVeVctpVoDfJWp
 4LwTuQ5yEM2KcPeElLg5fR7WB2zH97oI6/Ko2DlovmfQqXh9xWozQt0iGy5tWzh6I0JrlcxJ
 ileZWLccC4XKD1037Hy2FLAjzfoWgwBLA6ULu0exOOdIa58H4PsXtkFPrUF980EEibUp0zFz
 GotRVekFAceUaRvAj7dh76cToeZkfsjAvBVb4COXuhgX6N4pofgNkW2AtgYu1nUsPAo+NftU
 CxrhjHtLn4QEBpkbErnXQyMjHpIatlYGutVMS91XTQXYydCh5crMPs7hYVsvnmGHIaB9ZMfB
 njnuI31KBiLUks+paRkHQlFcgS2N3gkRBzH7xSZ+t7Re3jvXdXEzKBbQ+dC3lpJB0wPnyMcX
 FOTT3aZT7IgePkt5iC/BKBk3hqKteTnJFeVIT7EC+a6YUFg=
Organization: Red Hat GmbH
Message-ID: <0e30697f-a5f7-e272-6aa5-8c7197c15818@redhat.com>
Date: Thu, 30 Apr 2020 17:28:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20b86ced-7c47-02ca-0e0e-1bd5d6cc95c1@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, linux-acpi@vger.kernel.org,
 Baoquan He <bhe@redhat.com>, linux-nvdimm@lists.01.org,
 linux-s390@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Dave Hansen <dave.hansen@linux.intel.com>,
 virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
 Wei Yang <richard.weiyang@gmail.com>, Eric Biederman <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org, Dan Williams <dan.j.williams@intel.com>,
 Pavel Tatashin <pasha.tatashin@soleen.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.20 13:23, Dave Hansen wrote:
> On 4/30/20 3:29 AM, David Hildenbrand wrote:
>> Currently, when adding memory, we create entries in /sys/firmware/memmap/
>> as "System RAM". This does not reflect the reality and will lead to
>> kexec-tools to add that memory to the fixed-up initial memmap for a
>> kexec kernel (loaded via kexec_load()). The memory will be considered
>> initial System RAM by the kexec kernel.
>>
>> We should let the kexec kernel decide how to use that memory - just as
>> we do during an ordinary reboot.
> ...
>> -	rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0);
>> +	rc = add_memory(numa_node, new_res->start, resource_size(new_res),
>> +			MHP_NO_FIRMWARE_MEMMAP);
> 
> Looks fine.  But, if you send another revision, could you add a comment
> about the actual goal of MHP_NO_FIRMWARE_MEMMAP?  Maybe:
> 
> 	/*
> 	 * MHP_NO_FIRMWARE_MEMMAP ensures that future
> 	 * kexec'd kernels will not treat this as RAM.
> 	 */
> 
> Not a biggie, though.

Sure, maybe Andrew can fixup when applying (if no resend is necessary).

Thanks Dave!

> 
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
> 


-- 
Thanks,

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:28:56 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUB7P-0000K3-LU; Thu, 30 Apr 2020 15:28:55 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=H9qc=6O=suse.com=jgross@srs-us1.protection.inumbo.net>)
 id 1jUB7O-0000Jx-5D
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:28:54 +0000
X-Inumbo-ID: 4bff1bbc-8af7-11ea-9a69-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4bff1bbc-8af7-11ea-9a69-12813bfff9fa;
 Thu, 30 Apr 2020 15:28:53 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id D374EAC24;
 Thu, 30 Apr 2020 15:28:49 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v1.1 2/3] xen/sched: fix theoretical races accessing
 vcpu->dirty_cpu
Date: Thu, 30 Apr 2020 17:28:48 +0200
Message-Id: <20200430152848.20275-1-jgross@suse.com>
X-Mailer: git-send-email 2.16.4
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

The dirty_cpu field of struct vcpu denotes which cpu still holds data
of a vcpu. All accesses to this field should be atomic in case the
vcpu could just be running, as it is accessed without any lock held
in most cases.

There are some instances where accesses are not atomically done, and
even worse where multiple accesses are done when a single one would
be mandated.

Correct that in order to avoid potential problems.

Add some assertions to verify dirty_cpu is handled properly.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/arch/x86/domain.c   | 14 ++++++++++----
 xen/include/xen/sched.h |  2 +-
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a4428190d5..f0579a56d1 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1769,6 +1769,7 @@ static void __context_switch(void)
 
     if ( !is_idle_domain(pd) )
     {
+        ASSERT(read_atomic(&p->dirty_cpu) == cpu);
         memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
         vcpu_save_fpu(p);
         pd->arch.ctxt_switch->from(p);
@@ -1832,7 +1833,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 {
     unsigned int cpu = smp_processor_id();
     const struct domain *prevd = prev->domain, *nextd = next->domain;
-    unsigned int dirty_cpu = next->dirty_cpu;
+    unsigned int dirty_cpu = read_atomic(&next->dirty_cpu);
 
     ASSERT(prev != next);
     ASSERT(local_irq_is_enabled());
@@ -1844,6 +1845,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
     {
         /* Remote CPU calls __sync_local_execstate() from flush IPI handler. */
         flush_mask(cpumask_of(dirty_cpu), FLUSH_VCPU_STATE);
+        ASSERT(read_atomic(&next->dirty_cpu) == VCPU_CPU_CLEAN);
     }
 
     _update_runstate_area(prev);
@@ -1956,13 +1958,17 @@ void sync_local_execstate(void)
 
 void sync_vcpu_execstate(struct vcpu *v)
 {
-    if ( v->dirty_cpu == smp_processor_id() )
+    unsigned int dirty_cpu = read_atomic(&v->dirty_cpu);
+
+    if ( dirty_cpu == smp_processor_id() )
         sync_local_execstate();
-    else if ( vcpu_cpu_dirty(v) )
+    else if ( is_vcpu_dirty_cpu(dirty_cpu) )
     {
         /* Remote CPU calls __sync_local_execstate() from flush IPI handler. */
-        flush_mask(cpumask_of(v->dirty_cpu), FLUSH_VCPU_STATE);
+        flush_mask(cpumask_of(dirty_cpu), FLUSH_VCPU_STATE);
     }
+    ASSERT(read_atomic(&v->dirty_cpu) != dirty_cpu ||
+           dirty_cpu == VCPU_CPU_CLEAN);
 }
 
 static int relinquish_memory(
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 195e7ee583..81628e2d98 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -844,7 +844,7 @@ static inline bool is_vcpu_dirty_cpu(unsigned int cpu)
 
 static inline bool vcpu_cpu_dirty(const struct vcpu *v)
 {
-    return is_vcpu_dirty_cpu(v->dirty_cpu);
+    return is_vcpu_dirty_cpu(read_atomic((unsigned int *)&v->dirty_cpu));
 }
 
 void vcpu_block(void);
-- 
2.16.4



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:35:45 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:35:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUBDs-0001E1-Dl; Thu, 30 Apr 2020 15:35:36 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jUBDr-0001Dw-VR
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:35:36 +0000
X-Inumbo-ID: 3c0587cc-8af8-11ea-9a6e-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 3c0587cc-8af8-11ea-9a6e-12813bfff9fa;
 Thu, 30 Apr 2020 15:35:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tyZfHeYcIwisUGDk0YMJ4m3ZCUwEncCi8h2a9kvhlk4=; b=qLwmsUd0IjXhK+jjTNjDmsrksF
 jDQKagwuRVYDFg1CRMjRWvjC/2X4I3C60bs+yOIu/LO8W/GAuppK21+HduK4ZthQsYgbIHWzli+No
 YxPetGxbLKEl9xE5xGKN3gl4oXC79rmFueKU6Kw/UMiTaw7aoQnOnV3H+3Yqh3VKL30s=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jUBDo-0006M8-TH; Thu, 30 Apr 2020 15:35:32 +0000
Received: from 82.162.187.81.in-addr.arpa ([81.187.162.82]
 helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jUBDo-0005BC-Ln; Thu, 30 Apr 2020 15:35:32 +0000
Subject: Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected from the
 menuconfig directly
To: Jan Beulich <jbeulich@suse.com>
References: <20200430142548.23751-1-julien@xen.org>
 <20200430142548.23751-3-julien@xen.org>
 <3a4ec020-f626-031e-73a6-b2eee97ab9e8@suse.com>
From: Julien Grall <julien@xen.org>
Message-ID: <548a9fc5-c251-5d8b-d297-4788d60b801d@xen.org>
Date: Thu, 30 Apr 2020 16:35:28 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <3a4ec020-f626-031e-73a6-b2eee97ab9e8@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <jgrall@amazon.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi Jan,

On 30/04/2020 15:50, Jan Beulich wrote:
> On 30.04.2020 16:25, Julien Grall wrote:
>> EXPERT mode is currently used to gate any options that are in technical
>> preview or not security supported At the moment, the only way to select
>> it is to use XEN_CONFIG_EXPERT=y on the make command line.
>>
>> However, if the user forget to add the option of one of the make
>> command (even a clean), then .config will get rewritten. This may lead
>> to a rather frustrating experience as it is difficult to diagnostic the
>> issue.
> 
> Is / will this still be true after Anthony's rework of the build
> system? Right now we already have
> 
> clean-targets := %clean
> no-dot-config-targets := $(clean-targets) \
>                           ...

I haven't tried Anthony's rework yet. But I guess the problem would be 
the same if you forget to add XEN_CONFIG_EXPERT=y on make.

> 
>> A lot of the options behind EXPERT would benefit to get more tested in
>> order to be mark as fully supported in the future.
> 
> Anyone intending to get an EXPERT-only option fully supported will
> need to do focused testing; I don't think we can expect to move
> items out of this category just because more people happen to test
> something every now and then.

I didn't imply this was the only condition to get a feature security 
suported. I merely pointed out that more testing would help to harden 
the code. If you make difficult to access an option then it will be less 
tested and take longer to get it security supported.

> 
>> In order to make easier to experiment, the option EXPERT can now be
>> selected from the menuconfig rather than make command line. This does
>> not change the fact a kernel with EXPERT mode selected will not be
>> security supported.
> 
> Well, if I'm not mis-remembering it was on purpose to make it more
> difficult for people to declare themselves "experts". FAOD I'm not
> meaning to imply I don't see and accept the frustration aspect you
> mention further up. The two need to be carefully weighed against
> one another.

Some of the options behind EXPERT mode don't make sense. For instance, 
how adding a built-in command line requires to be expert? I understand 
we don't want to support it, but I don't see any reason to make the 
user's life more difficult here.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:41:32 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUBJY-00022X-8h; Thu, 30 Apr 2020 15:41:28 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=kYgy=6O=xmission.com=ebiederm@srs-us1.protection.inumbo.net>)
 id 1jUBJX-00022S-Al
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:41:27 +0000
X-Inumbo-ID: 0c7d31b0-8af9-11ea-9a6f-12813bfff9fa
Received: from out03.mta.xmission.com (unknown [166.70.13.233])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 0c7d31b0-8af9-11ea-9a6f-12813bfff9fa;
 Thu, 30 Apr 2020 15:41:25 +0000 (UTC)
Received: from in02.mta.xmission.com ([166.70.13.52])
 by out03.mta.xmission.com with esmtps
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1)
 (envelope-from <ebiederm@xmission.com>)
 id 1jUBJT-0008Qi-7v; Thu, 30 Apr 2020 09:41:23 -0600
Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]
 helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87)
 (envelope-from <ebiederm@xmission.com>)
 id 1jUBJS-0002Fp-2k; Thu, 30 Apr 2020 09:41:22 -0600
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Hildenbrand <david@redhat.com>
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-3-david@redhat.com>
Date: Thu, 30 Apr 2020 10:38:04 -0500
In-Reply-To: <20200430102908.10107-3-david@redhat.com> (David Hildenbrand's
 message of "Thu, 30 Apr 2020 12:29:07 +0200")
Message-ID: <87pnbp2dcz.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-XM-SPF: eid=1jUBJS-0002Fp-2k; ; ; mid=<87pnbp2dcz.fsf@x220.int.ebiederm.org>;
 ; ; hst=in02.mta.xmission.com; ; ; ip=68.227.160.95; ; ;
 frm=ebiederm@xmission.com; ; ; spf=neutral
X-XM-AID: U2FsdGVkX18EJxut0ZMAzA6GiTlXjw55Di06eL/sNkE=
X-SA-Exim-Connect-IP: 68.227.160.95
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa07.xmission.com
X-Spam-Level: *
X-Spam-Status: No, score=1.0 required=8.0 tests=ALL_TRUSTED,BAYES_50,
 DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,
 XMGappySubj_01,XMSubLong autolearn=disabled version=3.4.2
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
 *  0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
 *      [score: 0.5000] *  0.5 XMGappySubj_01 Very gappy subject
 *  0.7 XMSubLong Long Subject
 *  0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.
 * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
 *      [sa07 1397; Body=1 Fuz1=1 Fuz2=1]
 *  0.0 T_TooManySym_01 4+ unique symbols in subject
X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: *;David Hildenbrand <david@redhat.com>
X-Spam-Relay-Country: 
X-Spam-Timing: total 643 ms - load_scoreonly_sql: 0.04 (0.0%),
 signal_user_changed: 11 (1.7%), b_tie_ro: 10 (1.5%), parse: 1.37
 (0.2%), extract_message_metadata: 29 (4.4%), get_uri_detail_list: 4.7
 (0.7%), tests_pri_-1000: 50 (7.8%), tests_pri_-950: 1.81 (0.3%),
 tests_pri_-900: 1.57 (0.2%), tests_pri_-90: 188 (29.3%), check_bayes:
 186 (28.9%), b_tokenize: 11 (1.7%), b_tok_get_all: 91 (14.2%),
 b_comp_prob: 3.8 (0.6%), b_tok_touch_all: 76 (11.8%), b_finish: 0.97
 (0.2%), tests_pri_0: 346 (53.9%), check_dkim_signature: 0.82 (0.1%),
 check_dkim_adsp: 2.4 (0.4%), poll_dns_idle: 0.54 (0.1%), tests_pri_10:
 2.3 (0.4%), tests_pri_500: 7 (1.1%), rewrite_mail: 0.00 (0.0%)
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
 linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
 linux-s390@vger.kernel.org, linux-nvdimm@lists.01.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
 linux-acpi@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

David Hildenbrand <david@redhat.com> writes:

> Some devices/drivers that add memory via add_memory() and friends (e.g.,
> dax/kmem, but also virtio-mem in the future) don't want to create entries
> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> memory to the boot memmap of the kexec kernel.
>
> In fact, such memory is never exposed via the firmware memmap as System
> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
> wrong:
>  "kexec needs the raw firmware-provided memory map to setup the
>   parameter segment of the kernel that should be booted with
>   kexec. Also, the raw memory map is useful for debugging. For
>   that reason, /sys/firmware/memmap is an interface that provides
>   the raw memory map to userspace." [1]
>
> We don't have to worry about firmware_map_remove() on the removal path.
> If there is no entry, it will simply return with -EINVAL.
>
> [1]
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap


You know what this justification is rubbish, and I have previously
explained why it is rubbish.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

This needs to be based on weather the added memory is ultimately normal
ram or is something special.

At least when we are talking memory resources.  Keeping it out of the
firmware map that is fine.

If the hotplugged memory is the result of plugging a stick of ram
into the kernel and can and should used be like any other memory
it should be treated like any normal memory.

If the hotplugged memory is something special it should be treated as
something special.

Justifying behavior by documentation that does not consider memory
hotplug is bad thinking.








> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  include/linux/memory_hotplug.h | 8 ++++++++
>  mm/memory_hotplug.c            | 3 ++-
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 0151fb935c09..4ca418a731eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -68,6 +68,14 @@ struct mhp_params {
>  	pgprot_t pgprot;
>  };
>  
> +/* Flags used for add_memory() and friends. */
> +
> +/*
> + * Don't create entries in /sys/firmware/memmap/. The memory is detected and
> + * added via a device driver, not via the initial (firmware) memmap.
> + */
> +#define MHP_NO_FIRMWARE_MEMMAP		1
> +
>  /*
>   * Zone resizing functions
>   *
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c01be92693e3..e94ede9cad00 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res,
>  	BUG_ON(ret);
>  
>  	/* create new memmap entry */
> -	firmware_map_add_hotplug(start, start + size, "System RAM");
> +	if (!(flags & MHP_NO_FIRMWARE_MEMMAP))
> +		firmware_map_add_hotplug(start, start + size, "System RAM");
>  
>  	/* device_online() will take the lock when calling online_pages() */
>  	mem_hotplug_done();


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:50:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUBS1-0002t7-5j; Thu, 30 Apr 2020 15:50:13 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rLHY=6O=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jUBS0-0002t2-79
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:50:12 +0000
X-Inumbo-ID: 4583bc19-8afa-11ea-9a75-12813bfff9fa
Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4583bc19-8afa-11ea-9a75-12813bfff9fa;
 Thu, 30 Apr 2020 15:50:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588261811;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=cqT2umU96NpQ5kplgxo4+vPyoa6qqM52qyf1Yh2z2qI=;
 b=O77QpaUmPGSyoP7HKHp4VyCrF4HdJr3ZV3/LyKxym6DIpH9JCmKmAjnz
 RVthrpbHLD0PCz519fgGGVZu4bZ44DaMNxK4WuUbf5TQoGXVPNU+skMY6
 gYYS+ukqOHyn2vhCETLiLUJljeHhPmnXYp8KUW3ArtSnCqhwXEoYduY2A 0=;
Authentication-Results: esa1.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: PIq3lKpsbk1JDrvfa7kDyCyScDRb2dBAZ3kb+Abkt3y63kS1OFp2Vq0WvcG1g5H6utZfvuVHv8
 Fx7zjUJiY38jTBuRvzYBAvvb7zT6sLyxGuzlb41v9ECFgTMlFpqPXw4pHWXQqG2n0up7hmNtTA
 f6JWJ7UKnSzKS4Q7vuTWvw2BguOoGyOd+cXL6n4O0igaQa8S0kqufghp5shEfA0DlSCo57jCcP
 +MxhaioU1TpT+WI1Tg0TE13/gJyKsH+Hw9rkvwvLTWqSHDHFFgfc7wIesf6yQimnpQq48Ijz9e
 BeE=
X-SBRS: 2.7
X-MesageID: 16776213
X-Ironport-Server: esa1.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,336,1583211600"; d="scan'208";a="16776213"
Subject: Re: [PATCH] x86/amd: Initial support for Fam19h processors
To: Jan Beulich <jbeulich@suse.com>
References: <20200430095947.31958-1-andrew.cooper3@citrix.com>
 <471aaf7e-497f-edd2-6eb0-06d337a23538@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <9dc3a9e6-4a86-f24a-b279-59fec5ef22d8@citrix.com>
Date: Thu, 30 Apr 2020 16:50:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <471aaf7e-497f-edd2-6eb0-06d337a23538@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30/04/2020 12:09, Jan Beulich wrote:
> On 30.04.2020 11:59, Andrew Cooper wrote:
>> Fam19h is very similar to Fam17h in these regards.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thanks.

>
> Nevertheless a question:
>
>> --- a/xen/arch/x86/cpu/microcode/amd.c
>> +++ b/xen/arch/x86/cpu/microcode/amd.c
>> @@ -125,6 +125,7 @@ static bool_t verify_patch_size(uint32_t patch_size)
>>          max_size = F16H_MPB_MAX_SIZE;
>>          break;
>>      case 0x17:
>> +    case 0x19:
>>          max_size = F17H_MPB_MAX_SIZE;
>>          break;
> Didn't you indicate to me the other day that the upper bound would
> grow?

That was a very non-specific patch to Linux.  I've asked around, and the
answer seems to be 4800.

Are you happy for your review to stand with adding a new
F19H_MPB_MAX_SIZE define to this effect?

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:52:59 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:52:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUBUZ-00030m-Kw; Thu, 30 Apr 2020 15:52:51 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jUBUY-00030g-6I
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:52:50 +0000
X-Inumbo-ID: a45b94ae-8afa-11ea-9a75-12813bfff9fa
Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTP
 id a45b94ae-8afa-11ea-9a75-12813bfff9fa;
 Thu, 30 Apr 2020 15:52:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588261969;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=OP9zUYIno6x6iC1SiniLiH6Fo13bK6xGgljySSJVtbc=;
 b=MaeNsOFPzUdEg5kMeH8PcGlDdG0C8jBywQqzGykS59e2DBr6Tx96PwffEykq8hljtxMbmN
 AHqUg8Nh4p0eCjsIDiPP7ZNhoKhtZExbUa+odC/w+QiwLSl6T3qHLhdg+/y2DMBpO4nx3e
 V/fXqjSadZp8Np8uixjih65JaqXZvJw=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-370-scg0K8IrNv2RPP-fweQOMw-1; Thu, 30 Apr 2020 11:52:44 -0400
X-MC-Unique: scg0K8IrNv2RPP-fweQOMw-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 694A264AD9;
 Thu, 30 Apr 2020 15:52:42 +0000 (UTC)
Received: from [10.36.113.172] (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 758B8605DE;
 Thu, 30 Apr 2020 15:52:36 +0000 (UTC)
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
To: "Eric W. Biederman" <ebiederm@xmission.com>
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-3-david@redhat.com>
 <87pnbp2dcz.fsf@x220.int.ebiederm.org>
From: David Hildenbrand <david@redhat.com>
Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata=
 mQINBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABtCREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT6JAlgEEwEIAEICGwMFCQlmAYAGCwkIBwMCBhUI
 AgkKCwQWAgMBAh4BAheAFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl3pImkCGQEACgkQTd4Q
 9wD/g1o+VA//SFvIHUAvul05u6wKv/pIR6aICPdpF9EIgEU448g+7FfDgQwcEny1pbEzAmiw
 zAXIQ9H0NZh96lcq+yDLtONnXk/bEYWHHUA014A1wqcYNRY8RvY1+eVHb0uu0KYQoXkzvu+s
 Dncuguk470XPnscL27hs8PgOP6QjG4jt75K2LfZ0eAqTOUCZTJxA8A7E9+XTYuU0hs7QVrWJ
 jQdFxQbRMrYz7uP8KmTK9/Cnvqehgl4EzyRaZppshruKMeyheBgvgJd5On1wWq4ZUV5PFM4x
 II3QbD3EJfWbaJMR55jI9dMFa+vK7MFz3rhWOkEx/QR959lfdRSTXdxs8V3zDvChcmRVGN8U
 Vo93d1YNtWnA9w6oCW1dnDZ4kgQZZSBIjp6iHcA08apzh7DPi08jL7M9UQByeYGr8KuR4i6e
 RZI6xhlZerUScVzn35ONwOC91VdYiQgjemiVLq1WDDZ3B7DIzUZ4RQTOaIWdtXBWb8zWakt/
 ztGhsx0e39Gvt3391O1PgcA7ilhvqrBPemJrlb9xSPPRbaNAW39P8ws/UJnzSJqnHMVxbRZC
 Am4add/SM+OCP0w3xYss1jy9T+XdZa0lhUvJfLy7tNcjVG/sxkBXOaSC24MFPuwnoC9WvCVQ
 ZBxouph3kqc4Dt5X1EeXVLeba+466P1fe1rC8MbcwDkoUo65Ag0EVcufkQEQAOfX3n0g0fZz
 Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
 T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
 CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
 NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
 lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
 AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
 N7eop7uh+6bezi+rugUI+w6DABEBAAGJAiUEGAECAA8FAlXLn5ECGwwFCQlmAYAACgkQTd4Q
 9wD/g1qA6w/+M+ggFv+JdVsz5+ZIc6MSyGUozASX+bmIuPeIecc9UsFRatc91LuJCKMkD9Uv
 GOcWSeFpLrSGRQ1Z7EMzFVU//qVs6uzhsNk0RYMyS0B6oloW3FpyQ+zOVylFWQCzoyyf227y
 GW8HnXunJSC+4PtlL2AY4yZjAVAPLK2l6mhgClVXTQ/S7cBoTQKP+jvVJOoYkpnFxWE9pn4t
 H5QIFk7Ip8TKr5k3fXVWk4lnUi9MTF/5L/mWqdyIO1s7cjharQCstfWCzWrVeVctpVoDfJWp
 4LwTuQ5yEM2KcPeElLg5fR7WB2zH97oI6/Ko2DlovmfQqXh9xWozQt0iGy5tWzh6I0JrlcxJ
 ileZWLccC4XKD1037Hy2FLAjzfoWgwBLA6ULu0exOOdIa58H4PsXtkFPrUF980EEibUp0zFz
 GotRVekFAceUaRvAj7dh76cToeZkfsjAvBVb4COXuhgX6N4pofgNkW2AtgYu1nUsPAo+NftU
 CxrhjHtLn4QEBpkbErnXQyMjHpIatlYGutVMS91XTQXYydCh5crMPs7hYVsvnmGHIaB9ZMfB
 njnuI31KBiLUks+paRkHQlFcgS2N3gkRBzH7xSZ+t7Re3jvXdXEzKBbQ+dC3lpJB0wPnyMcX
 FOTT3aZT7IgePkt5iC/BKBk3hqKteTnJFeVIT7EC+a6YUFg=
Organization: Red Hat GmbH
Message-ID: <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
Date: Thu, 30 Apr 2020 17:52:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <87pnbp2dcz.fsf@x220.int.ebiederm.org>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
 linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
 linux-s390@vger.kernel.org, linux-nvdimm@lists.01.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
 linux-acpi@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.20 17:38, Eric W. Biederman wrote:
> David Hildenbrand <david@redhat.com> writes:
>=20
>> Some devices/drivers that add memory via add_memory() and friends (e.g=
.,
>> dax/kmem, but also virtio-mem in the future) don't want to create entr=
ies
>> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
>> memory to the boot memmap of the kexec kernel.
>>
>> In fact, such memory is never exposed via the firmware memmap as Syste=
m
>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>> wrong:
>>  "kexec needs the raw firmware-provided memory map to setup the
>>   parameter segment of the kernel that should be booted with
>>   kexec. Also, the raw memory map is useful for debugging. For
>>   that reason, /sys/firmware/memmap is an interface that provides
>>   the raw memory map to userspace." [1]
>>
>> We don't have to worry about firmware_map_remove() on the removal path=
.
>> If there is no entry, it will simply return with -EINVAL.
>>
>> [1]
>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-me=
mmap
>=20
>=20
> You know what this justification is rubbish, and I have previously
> explained why it is rubbish.

Actually, no, I don't think it is rubbish. See patch #3 and the cover
letter why this is the right thing to do *for special memory*, *not
ordinary DIMMs*.

And to be quite honest, I think your response is a little harsh. I don't
recall you replying to my virtio-mem-related comments.

>=20
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>=20
> This needs to be based on weather the added memory is ultimately normal
> ram or is something special.

Yes, that's what the caller are expected to decide, see patch #3.

kexec should try to be as closely as possible to a real reboot - IMHO.

>=20
> At least when we are talking memory resources.  Keeping it out of the
> firmware map that is fine.
>=20
> If the hotplugged memory is the result of plugging a stick of ram
> into the kernel and can and should used be like any other memory
> it should be treated like any normal memory.
>=20
> If the hotplugged memory is something special it should be treated as
> something special.

I am really sorry, I can't make sense of what you are trying to say here.

>=20
> Justifying behavior by documentation that does not consider memory
> hotplug is bad thinking.

Are you maybe confusing this patch series with the arm64 approach? This
is not about ordinary hotplugged DIMMs.

I'd love to get Dan's, Dave's and Michal's opinion.

--=20
Thanks,

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 15:58:50 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 15:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUBaG-0003Cu-Be; Thu, 30 Apr 2020 15:58:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DLrL=6O=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jUBaF-0003Cp-Rg
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 15:58:43 +0000
X-Inumbo-ID: 76af5f81-8afb-11ea-9a75-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 76af5f81-8afb-11ea-9a75-12813bfff9fa;
 Thu, 30 Apr 2020 15:58:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mqhPPIAktKNGL5NHi0Pyp2VNRqCGo+MNOhwYeAKBxDE=; b=LbUdLpnQmmgX5EvSK48L7JFqG
 palvKchw6mf6B/dx9y4e8Phatx0bU0g/GYql2Tc5Q7bKCnNueSWLTU1ZIpeEN/G5kvhuJ3id6n1MC
 nICwCw+1Rbty8Cz5ZMuDO1cuv7jvtdeXDVV5secpKd5YX67GIjl4jbadj0rLZeZ4TbhSE=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUBaE-0006mc-24; Thu, 30 Apr 2020 15:58:42 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUBaD-0001U6-Hp; Thu, 30 Apr 2020 15:58:41 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jUBaD-0001Lm-HA; Thu, 30 Apr 2020 15:58:41 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149887-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149887: all pass - PUSHED
X-Osstest-Versions-This: ovmf=f07fb43b2d3f92a15d6992205b72ba5df0e74fe2
X-Osstest-Versions-That: ovmf=b2034179e8feed9c7d3bc8f9d40a18fd236c5b57
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 30 Apr 2020 15:58:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149887 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149887/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 f07fb43b2d3f92a15d6992205b72ba5df0e74fe2
baseline version:
 ovmf                 b2034179e8feed9c7d3bc8f9d40a18fd236c5b57

Last test of basis   149869  2020-04-29 03:52:49 Z    1 days
Testing same since   149887  2020-04-30 04:39:28 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Dong, Eric <eric.dong@intel.com>
  Eric Dong <eric.dong@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   b2034179e8..f07fb43b2d  f07fb43b2d3f92a15d6992205b72ba5df0e74fe2 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 16:04:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 16:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUBfq-0004Z9-2O; Thu, 30 Apr 2020 16:04:30 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qeDo=6O=intel.com=dave.hansen@srs-us1.protection.inumbo.net>)
 id 1jUBfo-0004Z4-Ny
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 16:04:28 +0000
X-Inumbo-ID: 42ffe302-8afc-11ea-ae69-bc764e2007e4
Received: from mga09.intel.com (unknown [134.134.136.24])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 42ffe302-8afc-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 16:04:25 +0000 (UTC)
IronPort-SDR: yo7pSQEgU0LGPBYnDFSgyrGketN3+mxjxFa8IAI25IiR7aXgZln7ulV1AE0eQu7lbSG9bDAT53
 ivS7HrF1zD9w==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga006.jf.intel.com ([10.7.209.51])
 by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 30 Apr 2020 09:04:24 -0700
IronPort-SDR: GGSzCMoySeYAUbJAzl2mHzLAbB6NpkILcMU5FKnDmI8Hd9CO4dZEQh8q2QgRszsoQswMn9gG6D
 vRptZ69zdrKQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.73,336,1583222400"; d="scan'208";a="261827387"
Received: from rariojas-mobl.amr.corp.intel.com (HELO [10.252.135.40])
 ([10.252.135.40])
 by orsmga006.jf.intel.com with ESMTP; 30 Apr 2020 09:04:23 -0700
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
To: David Hildenbrand <david@redhat.com>,
 "Eric W. Biederman" <ebiederm@xmission.com>
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-3-david@redhat.com>
 <87pnbp2dcz.fsf@x220.int.ebiederm.org>
 <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
From: Dave Hansen <dave.hansen@intel.com>
Autocrypt: addr=dave.hansen@intel.com; keydata=
 xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC
 oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY
 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb
 ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz
 VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W
 iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn
 c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1
 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb
 ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL
 QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzShEYXZpZCBDaHJp
 c3RvcGhlciBIYW5zZW4gPGRhdmVAc3I3MS5uZXQ+wsF7BBMBAgAlAhsDBgsJCAcDAgYVCAIJ
 CgsEFgIDAQIeAQIXgAUCTo3k0QIZAQAKCRBoNZUwcMmSsMO2D/421Xg8pimb9mPzM5N7khT0
 2MCnaGssU1T59YPE25kYdx2HntwdO0JA27Wn9xx5zYijOe6B21ufrvsyv42auCO85+oFJWfE
 K2R/IpLle09GDx5tcEmMAHX6KSxpHmGuJmUPibHVbfep2aCh9lKaDqQR07gXXWK5/yU1Dx0r
 VVFRaHTasp9fZ9AmY4K9/BSA3VkQ8v3OrxNty3OdsrmTTzO91YszpdbjjEFZK53zXy6tUD2d
 e1i0kBBS6NLAAsqEtneplz88T/v7MpLmpY30N9gQU3QyRC50jJ7LU9RazMjUQY1WohVsR56d
 ORqFxS8ChhyJs7BI34vQusYHDTp6PnZHUppb9WIzjeWlC7Jc8lSBDlEWodmqQQgp5+6AfhTD
 kDv1a+W5+ncq+Uo63WHRiCPuyt4di4/0zo28RVcjtzlGBZtmz2EIC3vUfmoZbO/Gn6EKbYAn
 rzz3iU/JWV8DwQ+sZSGu0HmvYMt6t5SmqWQo/hyHtA7uF5Wxtu1lCgolSQw4t49ZuOyOnQi5
 f8R3nE7lpVCSF1TT+h8kMvFPv3VG7KunyjHr3sEptYxQs4VRxqeirSuyBv1TyxT+LdTm6j4a
 mulOWf+YtFRAgIYyyN5YOepDEBv4LUM8Tz98lZiNMlFyRMNrsLV6Pv6SxhrMxbT6TNVS5D+6
 UorTLotDZKp5+M7BTQRUY85qARAAsgMW71BIXRgxjYNCYQ3Xs8k3TfAvQRbHccky50h99TUY
 sqdULbsb3KhmY29raw1bgmyM0a4DGS1YKN7qazCDsdQlxIJp9t2YYdBKXVRzPCCsfWe1dK/q
 66UVhRPP8EGZ4CmFYuPTxqGY+dGRInxCeap/xzbKdvmPm01Iw3YFjAE4PQ4hTMr/H76KoDbD
 cq62U50oKC83ca/PRRh2QqEqACvIH4BR7jueAZSPEDnzwxvVgzyeuhwqHY05QRK/wsKuhq7s
 UuYtmN92Fasbxbw2tbVLZfoidklikvZAmotg0dwcFTjSRGEg0Gr3p/xBzJWNavFZZ95Rj7Et
 db0lCt0HDSY5q4GMR+SrFbH+jzUY/ZqfGdZCBqo0cdPPp58krVgtIGR+ja2Mkva6ah94/oQN
 lnCOw3udS+Eb/aRcM6detZr7XOngvxsWolBrhwTQFT9D2NH6ryAuvKd6yyAFt3/e7r+HHtkU
 kOy27D7IpjngqP+b4EumELI/NxPgIqT69PQmo9IZaI/oRaKorYnDaZrMXViqDrFdD37XELwQ
 gmLoSm2VfbOYY7fap/AhPOgOYOSqg3/Nxcapv71yoBzRRxOc4FxmZ65mn+q3rEM27yRztBW9
 AnCKIc66T2i92HqXCw6AgoBJRjBkI3QnEkPgohQkZdAb8o9WGVKpfmZKbYBo4pEAEQEAAcLB
 XwQYAQIACQUCVGPOagIbDAAKCRBoNZUwcMmSsJeCEACCh7P/aaOLKWQxcnw47p4phIVR6pVL
 e4IEdR7Jf7ZL00s3vKSNT+nRqdl1ugJx9Ymsp8kXKMk9GSfmZpuMQB9c6io1qZc6nW/3TtvK
 pNGz7KPPtaDzvKA4S5tfrWPnDr7n15AU5vsIZvgMjU42gkbemkjJwP0B1RkifIK60yQqAAlT
 YZ14P0dIPdIPIlfEPiAWcg5BtLQU4Wg3cNQdpWrCJ1E3m/RIlXy/2Y3YOVVohfSy+4kvvYU3
 lXUdPb04UPw4VWwjcVZPg7cgR7Izion61bGHqVqURgSALt2yvHl7cr68NYoFkzbNsGsye9ft
 M9ozM23JSgMkRylPSXTeh5JIK9pz2+etco3AfLCKtaRVysjvpysukmWMTrx8QnI5Nn5MOlJj
 1Ov4/50JY9pXzgIDVSrgy6LYSMc4vKZ3QfCY7ipLRORyalFDF3j5AGCMRENJjHPD6O7bl3Xo
 4DzMID+8eucbXxKiNEbs21IqBZbbKdY1GkcEGTE7AnkA3Y6YB7I/j9mQ3hCgm5muJuhM/2Fr
 OPsw5tV/LmQ5GXH0JQ/TZXWygyRFyyI2FqNTx4WHqUn3yFj8rwTAU1tluRUYyeLy0ayUlKBH
 ybj0N71vWO936MqP6haFERzuPAIpxj2ezwu0xb1GjTk4ynna6h5GjnKgdfOWoRtoWndMZxbA
 z5cecg==
Message-ID: <c905918d-54f6-0f17-ca5b-cd3371ada788@intel.com>
Date: Thu, 30 Apr 2020 09:04:23 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
 linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
 linux-s390@vger.kernel.org, linux-nvdimm@lists.01.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
 linux-acpi@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 4/30/20 8:52 AM, David Hildenbrand wrote:
>> Justifying behavior by documentation that does not consider memory
>> hotplug is bad thinking.
> Are you maybe confusing this patch series with the arm64 approach? This
> is not about ordinary hotplugged DIMMs.
> 
> I'd love to get Dan's, Dave's and Michal's opinion.

The impact on kexec from the DAX "kmem" driver's use of hotplug was
inadvertent and unfortunate.

The problem statement and solution seem pretty sane to me.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 16:19:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 16:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUBuI-0005WE-IV; Thu, 30 Apr 2020 16:19:26 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rLHY=6O=citrix.com=andrew.cooper3@srs-us1.protection.inumbo.net>)
 id 1jUBuG-0005W8-Oi
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 16:19:24 +0000
X-Inumbo-ID: 59832986-8afe-11ea-9a7b-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 59832986-8afe-11ea-9a7b-12813bfff9fa;
 Thu, 30 Apr 2020 16:19:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588263563;
 h=subject:to:cc:references:from:message-id:date:
 mime-version:in-reply-to:content-transfer-encoding;
 bh=uUBzPA6/hLC0qecRYft6hc4V7jTdFJeQgEvZR9Q6Yyo=;
 b=APE96icCz/4fOfATYI8XdRBLyoVX4EClN/M/tb6fqzr5FtZhdvpBkMOH
 3Ef/LOuJpvfWItEJpWjwS2FMH2yaF4yVeoiviLcSTUZu8phXq8CKQ0wDs
 l6CI77mt4xrA1PoMQL8H7kZCE+A7d+jGRp/e5GU56vQdYV87e74btSy3W A=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=andrew.cooper3@citrix.com;
 spf=Pass smtp.mailfrom=Andrew.Cooper3@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 andrew.cooper3@citrix.com) identity=pra;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="andrew.cooper3@citrix.com";
 x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 Andrew.Cooper3@citrix.com designates 162.221.158.21 as
 permitted sender) identity=mailfrom;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="Andrew.Cooper3@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="Andrew.Cooper3@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: TZikwq5VJCs0D9lB8Ft4BrVe1iDizd7+TMkj1+iXH6bvSTEQ2Fe9EYxFSDsVK5xt4NiecII5cL
 pe4qiuUKGf0RDPTukxTyx5soEF4K9PCVwSeAAZTV34nWLIabrq74Cvn4wXOjrNIqIOl6qTIgdI
 lmj+hB5Ot6ui65O/DpAw982NZGwzOypeR/xYvWVhjmitSDirKf7yiRMGtVhKwguBiJq1jGb8BW
 54WGe+a4THogXC0bOHUoHDFJHrIhc3msjVRBb8B07vLpuTQhmxpg5V03ju390b4gzoZEBkAS1M
 7Zk=
X-SBRS: 2.7
X-MesageID: 16833879
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,336,1583211600"; d="scan'208";a="16833879"
Subject: Re: [PATCH] x86/hap: be more selective with assisted TLB flush
To: Jan Beulich <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?=
 <roger.pau@citrix.com>
References: <20200429173601.77605-1-roger.pau@citrix.com>
 <4257a323-d37f-4af0-bdc6-a3f65c19438a@suse.com>
 <20200430082844.GZ28601@Air-de-Roger>
 <d5a0308b-0ac3-21f5-9a07-e1402005b663@suse.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <487fb08f-a9f5-7de9-54f0-f158fa687e6c@citrix.com>
Date: Thu, 30 Apr 2020 17:19:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <d5a0308b-0ac3-21f5-9a07-e1402005b663@suse.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, George Dunlap <george.dunlap@citrix.com>,
 Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30/04/2020 09:33, Jan Beulich wrote:
> On 30.04.2020 10:28, Roger Pau Monné wrote:
>> On Thu, Apr 30, 2020 at 09:20:58AM +0200, Jan Beulich wrote:
>>> On 29.04.2020 19:36, Roger Pau Monne wrote:
>>>> When doing an assisted flush on HAP the purpose of the
>>>> on_selected_cpus is just to trigger a vmexit on remote CPUs that are
>>>> in guest context, and hence just using is_vcpu_dirty_cpu is too lax,
>>>> also check that the vCPU is running.
>>> Am I right to understand that the change is relevant only to
>>> cover the period of time between ->is_running becoming false
>>> and ->dirty_cpu becoming VCPU_CPU_CLEAN? I.e. ...
>>>
>>>> --- a/xen/arch/x86/mm/hap/hap.c
>>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>>> @@ -719,7 +719,7 @@ static bool flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
>>>>          hvm_asid_flush_vcpu(v);
>>>>  
>>>>          cpu = read_atomic(&v->dirty_cpu);
>>>> -        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) )
>>>> +        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v->is_running )
>>> ... the previous logic would have suitably covered the switch-to
>>> path, but doesn't properly cover the switch-from one, due to our
>>> lazy context switch approach?
>> Yes. Also __context_switch is not called from context_switch when
>> switching to the idle vcpu, and hence dirty_cpu is not cleared.
>>
>>> If so, I agree with the change:
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>> It might be worth mentioning this detail in the description then,
>>> though.
>> Would you mind adding to the commit message if you agree:
>>
>> "Due to the lazy context switching done by Xen dirty_cpu won't always be
>> cleared when the guest vCPU is not running, and hence relying on
>> is_running allows more fine grained control of whether the vCPU is
>> actually running."
> Sure; I'll give it over the weekend though for others to comment, if
> so desired.

I think it is worth pointing out that this fixes a large perf regression
on Nehalem/Westmere systems, where L1 Shim using the enlightened
hypercall is 8x slower than unenlightened way.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 16:21:26 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 16:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUBwC-0006Fo-V3; Thu, 30 Apr 2020 16:21:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=kEmr=6O=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jUBwB-0006Fj-1l
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 16:21:23 +0000
X-Inumbo-ID: a151c13a-8afe-11ea-b07b-bc764e2007e4
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id a151c13a-8afe-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 16:21:22 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 6426820873;
 Thu, 30 Apr 2020 16:21:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588263681;
 bh=rNFtDOEbs8uAin7Ylu6G/jRCGahMOj0lxwRqASbytQk=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=rjGyc0rFFBnJGflR/bcpKkx/CqDvUDB3W2zATLipgHe/tPxpLQ0FSMJBpB7Gsdx+Y
 14I6xLu3qGzfunbzAvSZRxrZPe2w5BST+btYcXtBvCn09h+wixyxhzx70MdwA3y6bq
 yfJrdG3bjISNTTqFuh47AEZ8UriXISOs+szkuBHg=
Date: Thu, 30 Apr 2020 09:21:20 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 05/12] xen: introduce reserve_heap_pages
In-Reply-To: <8a517cbc-9ff7-5b9e-f2c9-08c411703d5d@suse.com>
Message-ID: <alpine.DEB.2.21.2004300907060.28941@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-5-sstabellini@kernel.org>
 <3129ab49-5898-9d2e-8fbb-d1fcaf6cdec7@suse.com>
 <alpine.DEB.2.21.2004291510270.28941@sstabellini-ThinkPad-T480s>
 <8a517cbc-9ff7-5b9e-f2c9-08c411703d5d@suse.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, 30 Apr 2020, Jan Beulich wrote:
> On 30.04.2020 00:46, Stefano Stabellini wrote:
> > On Fri, 17 Apr 2020, Jan Beulich wrote:
> >> On 15.04.2020 03:02, Stefano Stabellini wrote:
> >>> Introduce a function named reserve_heap_pages (similar to
> >>> alloc_heap_pages) that allocates a requested memory range. Call
> >>> __alloc_heap_pages for the implementation.
> >>>
> >>> Change __alloc_heap_pages so that the original page doesn't get
> >>> modified, giving back unneeded memory top to bottom rather than bottom
> >>> to top.
> >>
> >> While it may be less of a problem within a zone, doing so is
> >> against our general "return high pages first" policy.
> > 
> > Is this something you'd be OK with anyway?
> 
> As a last resort, maybe. But it really depends on why it needs to be
> this way.
> 
> > If not, do you have a suggestion on how to do it better? I couldn't find
> > a nice way to do it without code duplication, or a big nasty 'if' in the
> > middle of the function.
> 
> I'd first need to understand the problem to solve.

OK, I'll make an example.

reserve_heap_pages wants to reserve the range 0x10000000 - 0x20000000.

reserve_heap_pages get the struct page_info for 0x10000000 and calls
alloc_pages_from_buddy to allocate an order of 28.

alloc_pages_from_buddy realizes that the free memory area starting from
0x10000000 is actually of order 30, even larger than the requested order
of 28. The free area is 0x10000000 - 0x50000000.

alloc_pages_from_buddy instead of just allocating an order of 28
starting from 0x10000000, it would allocate the "top" order of 28 in the
free area. So it would allocate: 0x40000000 - 0x50000000, returning
0x40000000.

Of course, this doesn't work for reserve_heap_pages.


This patch changes the behavior of alloc_pages_from_buddy so that in a
situation like the above, it would return 0x10000000 - 0x20000000
(leaving the rest of the free area unallocated.)


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 16:37:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 16:37:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUCBa-0007EK-CR; Thu, 30 Apr 2020 16:37:18 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=kYgy=6O=xmission.com=ebiederm@srs-us1.protection.inumbo.net>)
 id 1jUCBZ-0007Do-KA
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 16:37:17 +0000
X-Inumbo-ID: d952d0f4-8b00-11ea-9887-bc764e2007e4
Received: from out02.mta.xmission.com (unknown [166.70.13.232])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id d952d0f4-8b00-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 16:37:15 +0000 (UTC)
Received: from in01.mta.xmission.com ([166.70.13.51])
 by out02.mta.xmission.com with esmtps
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1)
 (envelope-from <ebiederm@xmission.com>)
 id 1jUCBV-000583-GC; Thu, 30 Apr 2020 10:37:13 -0600
Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]
 helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87)
 (envelope-from <ebiederm@xmission.com>)
 id 1jUCBT-0003Sj-B6; Thu, 30 Apr 2020 10:37:12 -0600
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Hildenbrand <david@redhat.com>
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-3-david@redhat.com>
 <87pnbp2dcz.fsf@x220.int.ebiederm.org>
 <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
Date: Thu, 30 Apr 2020 11:33:53 -0500
In-Reply-To: <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com> (David
 Hildenbrand's message of "Thu, 30 Apr 2020 17:52:35 +0200")
Message-ID: <871ro52ary.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-XM-SPF: eid=1jUCBT-0003Sj-B6; ; ; mid=<871ro52ary.fsf@x220.int.ebiederm.org>;
 ; ; hst=in01.mta.xmission.com; ; ; ip=68.227.160.95; ; ;
 frm=ebiederm@xmission.com; ; ; spf=neutral
X-XM-AID: U2FsdGVkX1/rjTp6/iiXIJNS/hMPK4PB5d8gU9GVdPg=
X-SA-Exim-Connect-IP: 68.227.160.95
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa07.xmission.com
X-Spam-Level: *
X-Spam-Status: No, score=1.0 required=8.0 tests=ALL_TRUSTED,BAYES_50,
 DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,
 XMGappySubj_01,XMSubLong autolearn=disabled version=3.4.2
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
 *  0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
 *      [score: 0.5000] *  0.5 XMGappySubj_01 Very gappy subject
 *  0.7 XMSubLong Long Subject
 *  0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.
 * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
 *      [sa07 1397; Body=1 Fuz1=1 Fuz2=1]
 *  0.0 T_TooManySym_01 4+ unique symbols in subject
X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: *;David Hildenbrand <david@redhat.com>
X-Spam-Relay-Country: 
X-Spam-Timing: total 593 ms - load_scoreonly_sql: 0.05 (0.0%),
 signal_user_changed: 11 (1.8%), b_tie_ro: 9 (1.6%), parse: 0.91 (0.2%),
 extract_message_metadata: 12 (2.0%), get_uri_detail_list: 2.4 (0.4%),
 tests_pri_-1000: 13 (2.2%), tests_pri_-950: 1.23 (0.2%),
 tests_pri_-900: 1.02 (0.2%), tests_pri_-90: 215 (36.3%), check_bayes:
 214 (36.0%), b_tokenize: 9 (1.6%), b_tok_get_all: 87 (14.6%),
 b_comp_prob: 3.3 (0.6%), b_tok_touch_all: 110 (18.5%), b_finish: 0.89
 (0.2%), tests_pri_0: 328 (55.3%), check_dkim_signature: 0.57 (0.1%),
 check_dkim_adsp: 2.3 (0.4%), poll_dns_idle: 0.71 (0.1%), tests_pri_10:
 2.1 (0.4%), tests_pri_500: 6 (1.0%), rewrite_mail: 0.00 (0.0%)
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
 linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
 linux-s390@vger.kernel.org, linux-nvdimm@lists.01.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
 linux-acpi@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

David Hildenbrand <david@redhat.com> writes:

> On 30.04.20 17:38, Eric W. Biederman wrote:
>> David Hildenbrand <david@redhat.com> writes:
>> 
>>> Some devices/drivers that add memory via add_memory() and friends (e.g.,
>>> dax/kmem, but also virtio-mem in the future) don't want to create entries
>>> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
>>> memory to the boot memmap of the kexec kernel.
>>>
>>> In fact, such memory is never exposed via the firmware memmap as System
>>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>>> wrong:
>>>  "kexec needs the raw firmware-provided memory map to setup the
>>>   parameter segment of the kernel that should be booted with
>>>   kexec. Also, the raw memory map is useful for debugging. For
>>>   that reason, /sys/firmware/memmap is an interface that provides
>>>   the raw memory map to userspace." [1]
>>>
>>> We don't have to worry about firmware_map_remove() on the removal path.
>>> If there is no entry, it will simply return with -EINVAL.
>>>
>>> [1]
>>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
>> 
>> 
>> You know what this justification is rubbish, and I have previously
>> explained why it is rubbish.
>
> Actually, no, I don't think it is rubbish. See patch #3 and the cover
> letter why this is the right thing to do *for special memory*, *not
> ordinary DIMMs*.
>
> And to be quite honest, I think your response is a little harsh. I don't
> recall you replying to my virtio-mem-related comments.
>
>> 
>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> 
>> This needs to be based on weather the added memory is ultimately normal
>> ram or is something special.
>
> Yes, that's what the caller are expected to decide, see patch #3.
>
> kexec should try to be as closely as possible to a real reboot - IMHO.

That is very fuzzy in terms of hotplug memory.  The kexec'd kernel
should see the hotplugged memory assuming it is ordinary memory.

But kexec is not a reboot although it is quite similar.   Kexec is
swapping one running kernel and it's state for another kernel without
rebooting.

>> Justifying behavior by documentation that does not consider memory
>> hotplug is bad thinking.
>
> Are you maybe confusing this patch series with the arm64 approach? This
> is not about ordinary hotplugged DIMMs.

I think I am.

My challenge is that I don't see anything in the description that says
this isn't about ordinary hotplugged DIMMs.  All I saw was hotplug
memory.

If the class of memory is different then please by all means let's mark
it differently in struct resource so everyone knows it is different.
But that difference needs to be more than hotplug.

That difference needs to be the hypervisor loaned us memory and might
take it back at any time, or this memory is persistent and so it has
these different characteristics so don't use it as ordinary ram.

That information is also useful to other people looking at the system
and seeing what is going on.

Just please don't muddle the concepts, or assume that whatever subset of
hotplug memory you are dealing with is the only subset.

I didn't see that flag making the distinction about the kind of memory
it is.

Eric






From xen-devel-bounces@lists.xenproject.org Thu Apr 30 16:50:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 16:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUCNl-000882-JV; Thu, 30 Apr 2020 16:49:53 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jUCNk-00087x-ES
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 16:49:52 +0000
X-Inumbo-ID: 9c19c1b4-8b02-11ea-ae69-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 9c19c1b4-8b02-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 16:49:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588265391;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=B9luQcDf1oWYK0AhgcBL9GSRdmBN4OPZecF4rGENsoA=;
 b=NYLX7UVRyLItFaxQNIpRRPYDAzLGcfh6rIEWbd1aSTXPWm7VtLQED0Y1Oysjs+OVWcq+LU
 9mNrN7LUUWpEVnYAFGe1ah5Bqs5h8eA4AnTDtiyqO0aMrmqVC+fUY66na0QeJYqQ9mk5HY
 S/kZwl+iMyMdLlpTCtENIb/m3kRAa8o=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-317-v8jSMvXVN_mxbmwJaY0ocA-1; Thu, 30 Apr 2020 12:49:49 -0400
X-MC-Unique: v8jSMvXVN_mxbmwJaY0ocA-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 93C0F462;
 Thu, 30 Apr 2020 16:49:46 +0000 (UTC)
Received: from [10.36.113.172] (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 929D0512E4;
 Thu, 30 Apr 2020 16:49:40 +0000 (UTC)
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
To: "Eric W. Biederman" <ebiederm@xmission.com>
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-3-david@redhat.com>
 <87pnbp2dcz.fsf@x220.int.ebiederm.org>
 <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
 <871ro52ary.fsf@x220.int.ebiederm.org>
From: David Hildenbrand <david@redhat.com>
Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata=
 mQINBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABtCREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT6JAlgEEwEIAEICGwMFCQlmAYAGCwkIBwMCBhUI
 AgkKCwQWAgMBAh4BAheAFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl3pImkCGQEACgkQTd4Q
 9wD/g1o+VA//SFvIHUAvul05u6wKv/pIR6aICPdpF9EIgEU448g+7FfDgQwcEny1pbEzAmiw
 zAXIQ9H0NZh96lcq+yDLtONnXk/bEYWHHUA014A1wqcYNRY8RvY1+eVHb0uu0KYQoXkzvu+s
 Dncuguk470XPnscL27hs8PgOP6QjG4jt75K2LfZ0eAqTOUCZTJxA8A7E9+XTYuU0hs7QVrWJ
 jQdFxQbRMrYz7uP8KmTK9/Cnvqehgl4EzyRaZppshruKMeyheBgvgJd5On1wWq4ZUV5PFM4x
 II3QbD3EJfWbaJMR55jI9dMFa+vK7MFz3rhWOkEx/QR959lfdRSTXdxs8V3zDvChcmRVGN8U
 Vo93d1YNtWnA9w6oCW1dnDZ4kgQZZSBIjp6iHcA08apzh7DPi08jL7M9UQByeYGr8KuR4i6e
 RZI6xhlZerUScVzn35ONwOC91VdYiQgjemiVLq1WDDZ3B7DIzUZ4RQTOaIWdtXBWb8zWakt/
 ztGhsx0e39Gvt3391O1PgcA7ilhvqrBPemJrlb9xSPPRbaNAW39P8ws/UJnzSJqnHMVxbRZC
 Am4add/SM+OCP0w3xYss1jy9T+XdZa0lhUvJfLy7tNcjVG/sxkBXOaSC24MFPuwnoC9WvCVQ
 ZBxouph3kqc4Dt5X1EeXVLeba+466P1fe1rC8MbcwDkoUo65Ag0EVcufkQEQAOfX3n0g0fZz
 Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
 T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
 CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
 NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
 lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
 AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
 N7eop7uh+6bezi+rugUI+w6DABEBAAGJAiUEGAECAA8FAlXLn5ECGwwFCQlmAYAACgkQTd4Q
 9wD/g1qA6w/+M+ggFv+JdVsz5+ZIc6MSyGUozASX+bmIuPeIecc9UsFRatc91LuJCKMkD9Uv
 GOcWSeFpLrSGRQ1Z7EMzFVU//qVs6uzhsNk0RYMyS0B6oloW3FpyQ+zOVylFWQCzoyyf227y
 GW8HnXunJSC+4PtlL2AY4yZjAVAPLK2l6mhgClVXTQ/S7cBoTQKP+jvVJOoYkpnFxWE9pn4t
 H5QIFk7Ip8TKr5k3fXVWk4lnUi9MTF/5L/mWqdyIO1s7cjharQCstfWCzWrVeVctpVoDfJWp
 4LwTuQ5yEM2KcPeElLg5fR7WB2zH97oI6/Ko2DlovmfQqXh9xWozQt0iGy5tWzh6I0JrlcxJ
 ileZWLccC4XKD1037Hy2FLAjzfoWgwBLA6ULu0exOOdIa58H4PsXtkFPrUF980EEibUp0zFz
 GotRVekFAceUaRvAj7dh76cToeZkfsjAvBVb4COXuhgX6N4pofgNkW2AtgYu1nUsPAo+NftU
 CxrhjHtLn4QEBpkbErnXQyMjHpIatlYGutVMS91XTQXYydCh5crMPs7hYVsvnmGHIaB9ZMfB
 njnuI31KBiLUks+paRkHQlFcgS2N3gkRBzH7xSZ+t7Re3jvXdXEzKBbQ+dC3lpJB0wPnyMcX
 FOTT3aZT7IgePkt5iC/BKBk3hqKteTnJFeVIT7EC+a6YUFg=
Organization: Red Hat GmbH
Message-ID: <373a6898-4020-4af1-5b3d-f827d705dd77@redhat.com>
Date: Thu, 30 Apr 2020 18:49:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <871ro52ary.fsf@x220.int.ebiederm.org>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
 linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
 linux-s390@vger.kernel.org, linux-nvdimm@lists.01.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
 linux-acpi@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On 30.04.20 18:33, Eric W. Biederman wrote:
> David Hildenbrand <david@redhat.com> writes:
>=20
>> On 30.04.20 17:38, Eric W. Biederman wrote:
>>> David Hildenbrand <david@redhat.com> writes:
>>>
>>>> Some devices/drivers that add memory via add_memory() and friends (e=
.g.,
>>>> dax/kmem, but also virtio-mem in the future) don't want to create en=
tries
>>>> in /sys/firmware/memmap/ - primarily to hinder kexec from adding thi=
s
>>>> memory to the boot memmap of the kexec kernel.
>>>>
>>>> In fact, such memory is never exposed via the firmware memmap as Sys=
tem
>>>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ =
is
>>>> wrong:
>>>>  "kexec needs the raw firmware-provided memory map to setup the
>>>>   parameter segment of the kernel that should be booted with
>>>>   kexec. Also, the raw memory map is useful for debugging. For
>>>>   that reason, /sys/firmware/memmap is an interface that provides
>>>>   the raw memory map to userspace." [1]
>>>>
>>>> We don't have to worry about firmware_map_remove() on the removal pa=
th.
>>>> If there is no entry, it will simply return with -EINVAL.
>>>>
>>>> [1]
>>>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-=
memmap
>>>
>>>
>>> You know what this justification is rubbish, and I have previously
>>> explained why it is rubbish.
>>
>> Actually, no, I don't think it is rubbish. See patch #3 and the cover
>> letter why this is the right thing to do *for special memory*, *not
>> ordinary DIMMs*.
>>
>> And to be quite honest, I think your response is a little harsh. I don=
't
>> recall you replying to my virtio-mem-related comments.
>>
>>>
>>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>>
>>> This needs to be based on weather the added memory is ultimately norm=
al
>>> ram or is something special.
>>
>> Yes, that's what the caller are expected to decide, see patch #3.
>>
>> kexec should try to be as closely as possible to a real reboot - IMHO.
>=20
> That is very fuzzy in terms of hotplug memory.  The kexec'd kernel
> should see the hotplugged memory assuming it is ordinary memory.
>=20
> But kexec is not a reboot although it is quite similar.   Kexec is
> swapping one running kernel and it's state for another kernel without
> rebooting.

I agree (especially regarding the arm64 DIMM hotplug discussion).
However, for the two cases

a) dax/kmem
b) virtio-mem

We really want to let the driver take back control and figure out "what
to do with the memory".

>=20
>>> Justifying behavior by documentation that does not consider memory
>>> hotplug is bad thinking.
>>
>> Are you maybe confusing this patch series with the arm64 approach? Thi=
s
>> is not about ordinary hotplugged DIMMs.
>=20
> I think I am.
>=20
> My challenge is that I don't see anything in the description that says
> this isn't about ordinary hotplugged DIMMs.  All I saw was hotplug
> memory.

I'm sorry if that was confusing, I tried to stress that kmem and
virtio-mem is special in the description.

I squeezed a lot of that information into the cover letter and into
patch #3.

>=20
> If the class of memory is different then please by all means let's mark
> it differently in struct resource so everyone knows it is different.
> But that difference needs to be more than hotplug.
>=20
> That difference needs to be the hypervisor loaned us memory and might
> take it back at any time, or this memory is persistent and so it has
> these different characteristics so don't use it as ordinary ram.

Yes, and I think kmem took an excellent approach of explicitly putting
that "System RAM" into a resource hierarchy. That "System RAM" won't
show up as a root node under /proc/iomem (see patch #3), which already
results in kexec-tools to treat it in a special way. I am thinking about
doing the same for virtio-mem.

>=20
> That information is also useful to other people looking at the system
> and seeing what is going on.
>=20
> Just please don't muddle the concepts, or assume that whatever subset o=
f
> hotplug memory you are dealing with is the only subset.

I can certainly rephrase the subject/description/comment, stating that
this is not to be used for ordinary hotplugged DIMMs - only when the
device driver is under control to decide what to do with that memory -
especially when kexec'ing.

(previously, I called this flag MHP_DRIVER_MANAGED, but I think
MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)

Would that make it clearer?

Thanks!

--=20
Thanks,

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 17:01:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 17:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUCYC-0001Fy-Pv; Thu, 30 Apr 2020 17:00:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=kEmr=6O=kernel.org=sstabellini@srs-us1.protection.inumbo.net>)
 id 1jUCYB-0001Ft-TJ
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 17:00:39 +0000
X-Inumbo-ID: 1e27506c-8b04-11ea-9a80-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 1e27506c-8b04-11ea-9a80-12813bfff9fa;
 Thu, 30 Apr 2020 17:00:39 +0000 (UTC)
Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 533F620661;
 Thu, 30 Apr 2020 17:00:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588266038;
 bh=B93+UsnDv7RgSAjrT+Hkx5AcpSSaxP4darVD6tkMveE=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=2gZE6lvI+9otreOVVbZCl0tunJWtx0+yqXV0Q7iFjKHbbAM97MigfaKbIrDKCbS29
 vWnAWeGg7zomEbyKTeVcXc295bPQs5tZ9B0UePAx6M11xvYt9qfNOG37DYF/iVRKHm
 Q0SONajevEhxfAwYnNxcgLy2CU0VOQQwylbODj0s=
Date: Thu, 30 Apr 2020 10:00:37 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s
To: Julien Grall <julien@xen.org>
Subject: Re: [PATCH 05/12] xen: introduce reserve_heap_pages
In-Reply-To: <a316ed70-da35-8be0-a092-d992e56563d2@xen.org>
Message-ID: <alpine.DEB.2.21.2004300928240.28941@sstabellini-ThinkPad-T480s>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-5-sstabellini@kernel.org>
 <3129ab49-5898-9d2e-8fbb-d1fcaf6cdec7@suse.com>
 <alpine.DEB.2.21.2004291510270.28941@sstabellini-ThinkPad-T480s>
 <a316ed70-da35-8be0-a092-d992e56563d2@xen.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
 andrew.cooper3@citrix.com, Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 "Woodhouse, David" <dwmw@amazon.co.uk>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, 30 Apr 2020, Julien Grall wrote:
> > > > +    pg = maddr_to_page(start);
> > > > +    node = phys_to_nid(start);
> > > > +    zone = page_to_zone(pg);
> > > > +    page_list_del(pg, &heap(node, zone, order));
> > > > +
> > > > +    __alloc_heap_pages(pg, order, memflags, d);
> > > 
> > > I agree with Julien in not seeing how this can be safe / correct.
> > 
> > I haven't seen any issues so far in my testing -- I imagine it is
> > because there aren't many memory allocations after setup_mm() and before
> > create_domUs()  (which on ARM is called just before
> > domain_unpause_by_systemcontroller at the end of start_xen.)
> 
> I am not sure why you exclude setup_mm(). Any memory allocated (boot
> allocator, xenheap) can clash with your regions. The main memory allocations
> are for the frametable and dom0. I would say you were lucky to not hit them.

Maybe it is because Xen typically allocates memory top-down? So if I
chose a high range then I would see a failure? But I have been mostly
testing with ranges close to the begin of RAM (as opposed to
ranges close to the end of RAM.)

 
> > I gave a quick look at David's series. Is the idea that I should add a
> > patch to do the following:
> > 
> > - avoiding adding these ranges to xenheap in setup_mm, wait for later
> >    (a bit like reserved_mem regions)
> 
> I guess by xenheap, you mean domheap? But the problem is not only for domheap,
> it is also for any memory allocated via the boot allocator. So you need to
> exclude those regions from any possible allocations.

OK, I think we are saying the same thing but let me check.

By boot allocator you mean alloc_boot_pages, right? That boot allocator
operates on ranges given to it by init_boot_pages calls.
init_boot_pages is called from setup_mm. I didn't write it clearly but
I also meant not calling init_boot_pages on them from setup_mm.

Are we saying the same thing?



> > - in construct_domU, add the range to xenheap and reserve it with
> > reserve_heap_pages
> 
> I am afraid you can't give the regions to the allocator and then allocate
> them. The allocator is free to use any page for its own purpose or exclude
> them.
>
> AFAICT, the allocator doesn't have a list of page in use. It only keeps track
> of free pages. So we can make the content of struct page_info to look like it
> was allocated by the allocator.
> 
> We would need to be careful when giving a page back to allocator as the page
> would need to be initialized (see [1]). This may not be a concern for Dom0less
> as the domain may never be destroyed but will be for correctness PoV.
> 
> For LiveUpdate, the original Xen will carve out space to use by the boot
> allocator in the new Xen. But I think this is not necessary in your context.
> 
> It should be sufficient to exclude the page from the boot allocators (as we do
> for other modules).
> 
> One potential issue that can arise is there is no easy way today to
> differentiate between pages allocated and pages not yet initialized. To make
> the code robust, we need to prevent a page to be used in two places. So for
> LiveUpdate we are marking them with a special value, this is used afterwards
> to check we are effictively using a reserved page.
> 
> I hope this helps.

Thanks for writing all of this down but I haven't understood some of it.

For the sake of this discussion let's say that we managed to "reserve"
the range early enough like we do for other modules, as you wrote.

At the point where we want to call reserve_heap_pages() we would call
init_heap_pages() just before it. We are still relatively early at boot
so there aren't any concurrent memory operations. Why this doesn't work?

If it doesn't work, I am not following what is your alternative
suggestion about making "the content of struct page_info to look like it
was allocated by the allocator."


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:09:46 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUDcj-0006E4-5o; Thu, 30 Apr 2020 18:09:25 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/gX9=6O=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1jUDch-0006Dz-RK
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:09:23 +0000
X-Inumbo-ID: b693c0fd-8b0d-11ea-9a8d-12813bfff9fa
Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id b693c0fd-8b0d-11ea-9a8d-12813bfff9fa;
 Thu, 30 Apr 2020 18:09:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1588270162;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=62PGdF+06MeHjzW7MjMajxK6hZQfjsamzxWU86mFF14=;
 b=BVBteh+tlxD1SXuKUjNh6kehV8nE6+9fWoxChu2EoR0jLcpG8+h2sKf+
 C3L67Y9D26wVK5rEIPjY2P/1M7dCYeOyegsFF3V/Qtv3TMgm+lw+vXZ+P
 rfPcH7ffsWi9Onw+kkPI0jxq6X5kU34Nu6LAGv0FFV+Ayz3EmIJeST9zM I=;
Authentication-Results: esa5.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none;
 spf=None smtp.pra=roger.pau@citrix.com;
 spf=Pass smtp.mailfrom=roger.pau@citrix.com;
 spf=None smtp.helo=postmaster@mail.citrix.com
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible
Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of
 roger.pau@citrix.com designates 162.221.158.21 as permitted
 sender) identity=mailfrom; client-ip=162.221.158.21;
 receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="roger.pau@citrix.com";
 x-conformance=sidf_compatible; x-record-type="v=spf1";
 x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133
 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4
 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88
 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83
 ip4:168.245.78.127 ~all"
Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender
 authenticity information available from domain of
 postmaster@mail.citrix.com) identity=helo;
 client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com;
 envelope-from="roger.pau@citrix.com";
 x-sender="postmaster@mail.citrix.com";
 x-conformance=sidf_compatible
IronPort-SDR: V2L/P/HuW5hvQ3CzJkAOPntko5E2GHA/rz/1nOcH3Z0P9UjrqnbJEUHhYJA53vQa6SwcVmP4Y0
 3IOgVVpRHrC1XlwVHc/PtEqDSu+/s5KePujTwDjOG9XBVSQeAV2PaNEFYBCnmVF4n1RGgLDwSg
 BbKoro1JEA4YlEpy260k6Xrp5mDX/gk7Cw9rwmoKmdSkSvP448VIVVyTcNCtvLc1uqzbDThAlp
 mFKPDg9uNKSk5n/ovc9CuuWTRK6r2SDhVz5rL5xLAjE6+MQstEaX21TESvyhKCjoU8aTwywbZg
 rCk=
X-SBRS: 2.7
X-MesageID: 16841389
X-Ironport-Server: esa5.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.73,336,1583211600"; d="scan'208";a="16841389"
Date: Thu, 30 Apr 2020 20:09:13 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/hap: be more selective with assisted TLB flush
Message-ID: <20200430180913.GF28601@Air-de-Roger>
References: <20200429173601.77605-1-roger.pau@citrix.com>
 <4257a323-d37f-4af0-bdc6-a3f65c19438a@suse.com>
 <20200430082844.GZ28601@Air-de-Roger>
 <d5a0308b-0ac3-21f5-9a07-e1402005b663@suse.com>
 <487fb08f-a9f5-7de9-54f0-f158fa687e6c@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <487fb08f-a9f5-7de9-54f0-f158fa687e6c@citrix.com>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: xen-devel@lists.xenproject.org, Wei Liu <wl@xen.org>, George
 Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 05:19:19PM +0100, Andrew Cooper wrote:
> On 30/04/2020 09:33, Jan Beulich wrote:
> > On 30.04.2020 10:28, Roger Pau Monné wrote:
> >> On Thu, Apr 30, 2020 at 09:20:58AM +0200, Jan Beulich wrote:
> >>> On 29.04.2020 19:36, Roger Pau Monne wrote:
> >>>> When doing an assisted flush on HAP the purpose of the
> >>>> on_selected_cpus is just to trigger a vmexit on remote CPUs that are
> >>>> in guest context, and hence just using is_vcpu_dirty_cpu is too lax,
> >>>> also check that the vCPU is running.
> >>> Am I right to understand that the change is relevant only to
> >>> cover the period of time between ->is_running becoming false
> >>> and ->dirty_cpu becoming VCPU_CPU_CLEAN? I.e. ...
> >>>
> >>>> --- a/xen/arch/x86/mm/hap/hap.c
> >>>> +++ b/xen/arch/x86/mm/hap/hap.c
> >>>> @@ -719,7 +719,7 @@ static bool flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
> >>>>          hvm_asid_flush_vcpu(v);
> >>>>  
> >>>>          cpu = read_atomic(&v->dirty_cpu);
> >>>> -        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) )
> >>>> +        if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v->is_running )
> >>> ... the previous logic would have suitably covered the switch-to
> >>> path, but doesn't properly cover the switch-from one, due to our
> >>> lazy context switch approach?
> >> Yes. Also __context_switch is not called from context_switch when
> >> switching to the idle vcpu, and hence dirty_cpu is not cleared.
> >>
> >>> If so, I agree with the change:
> >>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> >>> It might be worth mentioning this detail in the description then,
> >>> though.
> >> Would you mind adding to the commit message if you agree:
> >>
> >> "Due to the lazy context switching done by Xen dirty_cpu won't always be
> >> cleared when the guest vCPU is not running, and hence relying on
> >> is_running allows more fine grained control of whether the vCPU is
> >> actually running."
> > Sure; I'll give it over the weekend though for others to comment, if
> > so desired.
> 
> I think it is worth pointing out that this fixes a large perf regression
> on Nehalem/Westmere systems, where L1 Shim using the enlightened
> hypercall is 8x slower than unenlightened way.

I might as well post the actual numbers I have.

I've measured the time of the non-local branch of flush_area_mask
inside the shim running with 32vCPUs over 100000 executions and
averaged the result on a large Westmere system (80 ways total). The
figures where fetched during the boot of a SLES 11 PV guest. The
results are as follow (less is better):

Non assisted flush with x2APIC:      112406ns
Assisted flush without this patch:   820450ns
Assisted flush with this patch:        8330ns

I can add the figures to the commit message if deemed interesting to
have in the repo. Or the above text can be appended to the commit
message if that's fine.

Roger.


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:09:52 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUDdA-0006FI-Ei; Thu, 30 Apr 2020 18:09:52 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=kYgy=6O=xmission.com=ebiederm@srs-us1.protection.inumbo.net>)
 id 1jUDd9-0006F8-Hc
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:09:51 +0000
X-Inumbo-ID: c7c7f8e8-8b0d-11ea-9a8d-12813bfff9fa
Received: from out01.mta.xmission.com (unknown [166.70.13.231])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id c7c7f8e8-8b0d-11ea-9a8d-12813bfff9fa;
 Thu, 30 Apr 2020 18:09:49 +0000 (UTC)
Received: from in02.mta.xmission.com ([166.70.13.52])
 by out01.mta.xmission.com with esmtps
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1)
 (envelope-from <ebiederm@xmission.com>)
 id 1jUDd3-0002vZ-L9; Thu, 30 Apr 2020 12:09:45 -0600
Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]
 helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87)
 (envelope-from <ebiederm@xmission.com>)
 id 1jUDd2-0000hI-EL; Thu, 30 Apr 2020 12:09:45 -0600
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Hildenbrand <david@redhat.com>
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-3-david@redhat.com>
 <87pnbp2dcz.fsf@x220.int.ebiederm.org>
 <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
 <871ro52ary.fsf@x220.int.ebiederm.org>
 <373a6898-4020-4af1-5b3d-f827d705dd77@redhat.com>
Date: Thu, 30 Apr 2020 13:06:26 -0500
In-Reply-To: <373a6898-4020-4af1-5b3d-f827d705dd77@redhat.com> (David
 Hildenbrand's message of "Thu, 30 Apr 2020 18:49:39 +0200")
Message-ID: <875zdg26hp.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-XM-SPF: eid=1jUDd2-0000hI-EL; ; ; mid=<875zdg26hp.fsf@x220.int.ebiederm.org>;
 ; ; hst=in02.mta.xmission.com; ; ; ip=68.227.160.95; ; ;
 frm=ebiederm@xmission.com; ; ; spf=neutral
X-XM-AID: U2FsdGVkX1/0nSmexEm1WkrDW9iKj+jfV8y2wWo/acY=
X-SA-Exim-Connect-IP: 68.227.160.95
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa05.xmission.com
X-Spam-Level: ***
X-Spam-Status: No, score=3.0 required=8.0 tests=ALL_TRUSTED,BAYES_50,
 DCC_CHECK_NEGATIVE,TR_XM_PhishingBody,T_TM2_M_HEADER_IN_MSG,
 T_TooManySym_01,XMGappySubj_01,XMSubLong,XM_B_Phish66
 autolearn=disabled version=3.4.2
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
 *  0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
 *      [score: 0.5000] *  0.7 XMSubLong Long Subject
 *  0.5 XMGappySubj_01 Very gappy subject
 *  0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.
 *  2.0 XM_B_Phish66 BODY: Obfuscated XMission
 * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
 *      [sa05 1397; Body=1 Fuz1=1 Fuz2=1]
 *  0.0 T_TooManySym_01 4+ unique symbols in subject
 *  0.0 TR_XM_PhishingBody Phishing flag in body of message
X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: ***;David Hildenbrand <david@redhat.com>
X-Spam-Relay-Country: 
X-Spam-Timing: total 806 ms - load_scoreonly_sql: 0.09 (0.0%),
 signal_user_changed: 13 (1.6%), b_tie_ro: 11 (1.4%), parse: 1.99
 (0.2%), extract_message_metadata: 23 (2.8%), get_uri_detail_list: 7
 (0.8%), tests_pri_-1000: 19 (2.4%), tests_pri_-950: 1.58 (0.2%),
 tests_pri_-900: 1.29 (0.2%), tests_pri_-90: 310 (38.5%), check_bayes:
 309 (38.3%), b_tokenize: 17 (2.1%), b_tok_get_all: 195 (24.2%),
 b_comp_prob: 6 (0.7%), b_tok_touch_all: 87 (10.8%), b_finish: 0.91
 (0.1%), tests_pri_0: 423 (52.5%), check_dkim_signature: 0.62 (0.1%),
 check_dkim_adsp: 2.2 (0.3%), poll_dns_idle: 0.46 (0.1%), tests_pri_10:
 1.80 (0.2%), tests_pri_500: 6 (0.7%), rewrite_mail: 0.00 (0.0%)
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
 linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
 linux-s390@vger.kernel.org, linux-nvdimm@lists.01.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
 linux-acpi@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

David Hildenbrand <david@redhat.com> writes:

> On 30.04.20 18:33, Eric W. Biederman wrote:
>> David Hildenbrand <david@redhat.com> writes:
>> 
>>> On 30.04.20 17:38, Eric W. Biederman wrote:
>>>> David Hildenbrand <david@redhat.com> writes:
>>>>
>>>>> Some devices/drivers that add memory via add_memory() and friends (e.g.,
>>>>> dax/kmem, but also virtio-mem in the future) don't want to create entries
>>>>> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
>>>>> memory to the boot memmap of the kexec kernel.
>>>>>
>>>>> In fact, such memory is never exposed via the firmware memmap as System
>>>>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>>>>> wrong:
>>>>>  "kexec needs the raw firmware-provided memory map to setup the
>>>>>   parameter segment of the kernel that should be booted with
>>>>>   kexec. Also, the raw memory map is useful for debugging. For
>>>>>   that reason, /sys/firmware/memmap is an interface that provides
>>>>>   the raw memory map to userspace." [1]
>>>>>
>>>>> We don't have to worry about firmware_map_remove() on the removal path.
>>>>> If there is no entry, it will simply return with -EINVAL.
>>>>>
>>>>> [1]
>>>>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
>>>>
>>>>
>>>> You know what this justification is rubbish, and I have previously
>>>> explained why it is rubbish.
>>>
>>> Actually, no, I don't think it is rubbish. See patch #3 and the cover
>>> letter why this is the right thing to do *for special memory*, *not
>>> ordinary DIMMs*.
>>>
>>> And to be quite honest, I think your response is a little harsh. I don't
>>> recall you replying to my virtio-mem-related comments.
>>>
>>>>
>>>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>>>
>>>> This needs to be based on weather the added memory is ultimately normal
>>>> ram or is something special.
>>>
>>> Yes, that's what the caller are expected to decide, see patch #3.
>>>
>>> kexec should try to be as closely as possible to a real reboot - IMHO.
>> 
>> That is very fuzzy in terms of hotplug memory.  The kexec'd kernel
>> should see the hotplugged memory assuming it is ordinary memory.
>> 
>> But kexec is not a reboot although it is quite similar.   Kexec is
>> swapping one running kernel and it's state for another kernel without
>> rebooting.
>
> I agree (especially regarding the arm64 DIMM hotplug discussion).
> However, for the two cases
>
> a) dax/kmem
> b) virtio-mem
>
> We really want to let the driver take back control and figure out "what
> to do with the memory".

>From reading your v1 cover letter (the description appears missing in
v2) I see what you are talking about with respect to virtio-mem.

So I will count virt-io mem as something different.

>>>> Justifying behavior by documentation that does not consider memory
>>>> hotplug is bad thinking.
>>>
>>> Are you maybe confusing this patch series with the arm64 approach? This
>>> is not about ordinary hotplugged DIMMs.
>> 
>> I think I am.
>> 
>> My challenge is that I don't see anything in the description that says
>> this isn't about ordinary hotplugged DIMMs.  All I saw was hotplug
>> memory.
>
> I'm sorry if that was confusing, I tried to stress that kmem and
> virtio-mem is special in the description.
>
> I squeezed a lot of that information into the cover letter and into
> patch #3.


>> If the class of memory is different then please by all means let's mark
>> it differently in struct resource so everyone knows it is different.
>> But that difference needs to be more than hotplug.
>> 
>> That difference needs to be the hypervisor loaned us memory and might
>> take it back at any time, or this memory is persistent and so it has
>> these different characteristics so don't use it as ordinary ram.
>
> Yes, and I think kmem took an excellent approach of explicitly putting
> that "System RAM" into a resource hierarchy. That "System RAM" won't
> show up as a root node under /proc/iomem (see patch #3), which already
> results in kexec-tools to treat it in a special way. I am thinking about
> doing the same for virtio-mem.

Reading this and your patch cover letters again my concern is that
the justification seems to be letting the tail wag the dog.

You want kexec-tools to behave in a certain way so you are changing the
kernel.

Rather it should be change the kernel to clearly reflect reality and if
you can get away without a change to kexec-tools that is a bonus.

>> That information is also useful to other people looking at the system
>> and seeing what is going on.
>> 
>> Just please don't muddle the concepts, or assume that whatever subset of
>> hotplug memory you are dealing with is the only subset.
>
> I can certainly rephrase the subject/description/comment, stating that
> this is not to be used for ordinary hotplugged DIMMs - only when the
> device driver is under control to decide what to do with that memory -
> especially when kexec'ing.
>
> (previously, I called this flag MHP_DRIVER_MANAGED, but I think
> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
>
> Would that make it clearer?

I am not certain, but Andrew Morton deliberately added that
firmware_map_add_hotplug call.  Which means that there is a reason
for putting hotplugged memory in the firmware map.

So the justification needs to take that reason into account.  The
justification can not be it is hotplugged therefore it should not belong
in the firmware memory map.  Unless you can show that
firmware_map_add_hotplug that was actually a bug and should be removed.
But as it has been that way since 2010 that seems like a long shot.

So my question is what is right for the firmware map?

Why does the firmware map support hotplug entries?

Once we have the answers to those questions we can figure out what logic
the special kinds of memory hotplug need.

Ref: d96ae5309165 ("memory-hotplug: create /sys/firmware/memmap entry for new memory")

Eric



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:27:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUDuA-0007wB-TA; Thu, 30 Apr 2020 18:27:26 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=0VdV=6O=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jUDu9-0007w6-Qo
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:27:25 +0000
X-Inumbo-ID: 3cf3584a-8b10-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 3cf3584a-8b10-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 18:27:25 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 7892AAC4A;
 Thu, 30 Apr 2020 18:27:23 +0000 (UTC)
Subject: [PATCH 0/3] Automation: improve openSUSE containers + podman
From: Dario Faggioli <dfaggioli@suse.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 30 Apr 2020 20:27:22 +0200
Message-ID: <158827088416.19371.17008531228521109457.stgit@Palanthas>
User-Agent: StGit/0.21
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Doug Goldstein <cardoe@cardoe.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hello,

This short series contains some improvements for building Xen in
openSUSE containers. In fact, the build dependencies inside the
Tumbleweed container are updated and more handy helpers are added, in
containerize, for referring to both Leap and Tumbleweed containers.

In addition to that, in patch 3, the containerize script is enhanced so
that it is now possible to use podman, instead of docker. Rootless mode
for podman also works (provided the system is properly configured) which,
IMO, is rather nice.

Docker of course continue to work, and is kept as the default.

Regards
---
Dario Faggioli (3):
      automation: update openSUSE Tumbleweed building dependencies
      automation: openSUSE distro names helpers for containerize.
      automation: implement (rootless) podman support in containerize

 automation/build/README.md                         |   10 ++++++++++
 .../build/suse/opensuse-tumbleweed.dockerfile      |    2 ++
 automation/scripts/containerize                    |   19 +++++++++++++++----
 3 files changed, 27 insertions(+), 4 deletions(-)
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:27:34 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUDuG-0007wX-55; Thu, 30 Apr 2020 18:27:32 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=0VdV=6O=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jUDuE-0007wP-Ol
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:27:30 +0000
X-Inumbo-ID: 4005399a-8b10-11ea-b07b-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 4005399a-8b10-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 18:27:30 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id CC9FBAC4A;
 Thu, 30 Apr 2020 18:27:28 +0000 (UTC)
Subject: [PATCH 1/3] automation: update openSUSE Tumbleweed building
 dependencies
From: Dario Faggioli <dfaggioli@suse.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 30 Apr 2020 20:27:28 +0200
Message-ID: <158827124854.19371.13461510910212179854.stgit@Palanthas>
In-Reply-To: <158827088416.19371.17008531228521109457.stgit@Palanthas>
References: <158827088416.19371.17008531228521109457.stgit@Palanthas>
User-Agent: StGit/0.21
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Doug Goldstein <cardoe@cardoe.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

We need python3 (and the respective -devel package), these days.

Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
---
Cc: Doug Goldstein <cardoe@cardoe.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
---
This patch was submitted already, but not as part of this series.

Anyway, changes from v1:
* add python3 instead of replacing python2 with it.
---
I think the tumbleweed image in our registry needs to be updated.
---
 .../build/suse/opensuse-tumbleweed.dockerfile      |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/automation/build/suse/opensuse-tumbleweed.dockerfile b/automation/build/suse/opensuse-tumbleweed.dockerfile
index 2676a87c85..084cce0921 100644
--- a/automation/build/suse/opensuse-tumbleweed.dockerfile
+++ b/automation/build/suse/opensuse-tumbleweed.dockerfile
@@ -56,6 +56,8 @@ RUN zypper install -y --no-recommends \
         pkg-config \
         python \
         python-devel \
+        python3 \
+        python3-devel \
         systemd-devel \
         tar \
         transfig \



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:27:38 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUDuM-0007xq-HJ; Thu, 30 Apr 2020 18:27:38 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=0VdV=6O=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jUDuK-0007xQ-FE
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:27:36 +0000
X-Inumbo-ID: 429940b8-8b10-11ea-9a92-12813bfff9fa
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 429940b8-8b10-11ea-9a92-12813bfff9fa;
 Thu, 30 Apr 2020 18:27:36 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 800D1AC4A;
 Thu, 30 Apr 2020 18:27:34 +0000 (UTC)
Subject: [PATCH 2/3] automation: openSUSE distro names helpers for
 containerize.
From: Dario Faggioli <dfaggioli@suse.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 30 Apr 2020 20:27:34 +0200
Message-ID: <158827125424.19371.11152490489435365073.stgit@Palanthas>
In-Reply-To: <158827088416.19371.17008531228521109457.stgit@Palanthas>
References: <158827088416.19371.17008531228521109457.stgit@Palanthas>
User-Agent: StGit/0.21
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Doug Goldstein <cardoe@cardoe.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
---
Cc: Doug Goldstein <cardoe@cardoe.com>
---
 automation/scripts/containerize |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index fbc4bc22d6..eb805bf96c 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -24,6 +24,8 @@ case "_${CONTAINER}" in
     _stretch|_) CONTAINER="${BASE}/debian:stretch" ;;
     _trusty) CONTAINER="${BASE}/ubuntu:trusty" ;;
     _xenial) CONTAINER="${BASE}/ubuntu:xenial" ;;
+    _opensuse-leap|_leap) CONTAINER="${BASE}/suse:opensuse-leap" ;;
+    _opensuse-tumbleweed|_tumbleweed) CONTAINER="${BASE}/suse:opensuse-tumbleweed" ;;
 esac
 
 # Use this variable to control whether root should be used



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:27:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUDuQ-0007zK-Qc; Thu, 30 Apr 2020 18:27:42 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=0VdV=6O=suse.com=dfaggioli@srs-us1.protection.inumbo.net>)
 id 1jUDuQ-0007z6-48
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:27:42 +0000
X-Inumbo-ID: 46be0406-8b10-11ea-b9cf-bc764e2007e4
Received: from mx2.suse.de (unknown [195.135.220.15])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 46be0406-8b10-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 18:27:41 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 24AABAC4A;
 Thu, 30 Apr 2020 18:27:40 +0000 (UTC)
Subject: [PATCH 3/3] automation: implement (rootless) podman support in
 containerize
From: Dario Faggioli <dfaggioli@suse.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 30 Apr 2020 20:27:39 +0200
Message-ID: <158827125993.19371.14414402068069346455.stgit@Palanthas>
In-Reply-To: <158827088416.19371.17008531228521109457.stgit@Palanthas>
References: <158827088416.19371.17008531228521109457.stgit@Palanthas>
User-Agent: StGit/0.21
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Doug Goldstein <cardoe@cardoe.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Right now only docker is supported, when using the containerize script
for building inside containers. Enable podman as well.

Note that podman can be use in rootless mode too, but for that to work
the files /etc/subuid and /etc/subgid must be properly configured.

For instance:

dario@localhost> cat /etc/subuid
dario:100000:65536

dario@localhost:> cat /etc/subgid
dario:100000:65536

Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
---
Cc: Doug Goldstein <cardoe@cardoe.com>
---
 automation/build/README.md      |   10 ++++++++++
 automation/scripts/containerize |   17 +++++++++++++----
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/automation/build/README.md b/automation/build/README.md
index 8cda2b65a5..e1fb3124de 100644
--- a/automation/build/README.md
+++ b/automation/build/README.md
@@ -34,6 +34,16 @@ the default shell.
 There are several environment variables which the containerize script
 understands.
 
+- DOCKED_CMD: Whether to use docker or podman for running the containers.
+  podman can be used as a regular user (rootless podman), but for that
+  to work, /etc/subuid and /etc/subgid needs to containe the proper
+  entries, for such user.
+  docker is the default, for running with podman, do:
+
+  ```
+  DOCKER_CMD=podman ./automation/scripts/containerize make
+  ```
+
 - CONTAINER: This overrides the container to use. For CentOS 7.2, use:
 
   ```
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index eb805bf96c..04b9fc7ba4 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -1,5 +1,14 @@
 #!/bin/bash
 
+#
+# DOCKER_CMD should be either `docker` or `podman`.
+#
+# if using (rootless) podman, remember to set /etc/subuid
+# and /etc/subgid.
+#
+docker_cmd=${DOCKER_CMD:-"docker"}
+[ "$DOCKER_CMD" = "podman" ] && userns_podman="--userns=keep-id"
+
 einfo() {
     echo "$*" >&2
 }
@@ -31,7 +40,7 @@ esac
 # Use this variable to control whether root should be used
 case "_${CONTAINER_UID0}" in
     _1)   userarg= ;;
-    _0|_) userarg="-u $(id -u)" ;;
+    _0|_) userarg="-u $(id -u) $userns_podman" ;;
 esac
 
 # Save the commands for future use
@@ -49,8 +58,8 @@ tty -s && termint=t
 #
 if [[ "_${CONTAINER_NO_PULL}" != "_1" ]]; then
     einfo "*** Ensuring ${CONTAINER} is up to date"
-    docker pull ${CONTAINER} > /dev/null ||     \
-        die "Failed to update docker container"
+    ${docker_cmd} pull ${CONTAINER} > /dev/null ||     \
+        die "Failed to update container"
 fi
 
 if hash greadlink > /dev/null 2>&1; then
@@ -82,7 +91,7 @@ fi
 
 # Kick off Docker
 einfo "*** Launching container ..."
-exec docker run \
+exec ${docker_cmd} run \
     ${userarg} \
     ${SSH_AUTH_SOCK:+-e SSH_AUTH_SOCK="/tmp/ssh-agent/${SSH_AUTH_NAME}"} \
     -v "${CONTAINER_PATH}":/build:rw \



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:28:04 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUDum-00087V-39; Thu, 30 Apr 2020 18:28:04 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ng0l=6O=xen.org=julien@srs-us1.protection.inumbo.net>)
 id 1jUDul-00087E-7O
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:28:03 +0000
X-Inumbo-ID: 536d1106-8b10-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 536d1106-8b10-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 18:28:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
 MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=XvMGg1AExOn2bF5PuPdSQImcZvoL9DZRVrvMKU0kpuM=; b=EZcoJz8LKPU/p03Ab6zQZEVGGx
 bn++xbouDs8agSMF4/8GITAMQ/irK3TpF4ArGqlUafMVMVibnI+MuwLrwhdWNttTsLt+muVOYeNQb
 skAEywUJzxItKe8mkY8j2sIrftxujBxZPmRLTYigBYebqLRIlghtdFYIGoKq3e9a6XAc=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>)
 id 1jUDug-0001jk-I8; Thu, 30 Apr 2020 18:27:58 +0000
Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <julien@xen.org>)
 id 1jUDug-0002p7-43; Thu, 30 Apr 2020 18:27:58 +0000
Subject: Re: [PATCH 05/12] xen: introduce reserve_heap_pages
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.21.2004141746350.8746@sstabellini-ThinkPad-T480s>
 <20200415010255.10081-5-sstabellini@kernel.org>
 <3129ab49-5898-9d2e-8fbb-d1fcaf6cdec7@suse.com>
 <alpine.DEB.2.21.2004291510270.28941@sstabellini-ThinkPad-T480s>
 <a316ed70-da35-8be0-a092-d992e56563d2@xen.org>
 <alpine.DEB.2.21.2004300928240.28941@sstabellini-ThinkPad-T480s>
From: Julien Grall <julien@xen.org>
Message-ID: <86e8fa89-c6f5-6c9e-4f3e-7f98e8e12c6a@xen.org>
Date: Thu, 30 Apr 2020 19:27:55 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2004300928240.28941@sstabellini-ThinkPad-T480s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Wei Liu <wl@xen.org>, andrew.cooper3@citrix.com,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@xilinx.com>, Volodymyr_Babchuk@epam.com,
 "Woodhouse, David" <dwmw@amazon.co.uk>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Hi,

On 30/04/2020 18:00, Stefano Stabellini wrote:
> On Thu, 30 Apr 2020, Julien Grall wrote:
>>>>> +    pg = maddr_to_page(start);
>>>>> +    node = phys_to_nid(start);
>>>>> +    zone = page_to_zone(pg);
>>>>> +    page_list_del(pg, &heap(node, zone, order));
>>>>> +
>>>>> +    __alloc_heap_pages(pg, order, memflags, d);
>>>>
>>>> I agree with Julien in not seeing how this can be safe / correct.
>>>
>>> I haven't seen any issues so far in my testing -- I imagine it is
>>> because there aren't many memory allocations after setup_mm() and before
>>> create_domUs()  (which on ARM is called just before
>>> domain_unpause_by_systemcontroller at the end of start_xen.)
>>
>> I am not sure why you exclude setup_mm(). Any memory allocated (boot
>> allocator, xenheap) can clash with your regions. The main memory allocations
>> are for the frametable and dom0. I would say you were lucky to not hit them.
> 
> Maybe it is because Xen typically allocates memory top-down? So if I
> chose a high range then I would see a failure? But I have been mostly
> testing with ranges close to the begin of RAM (as opposed to
> ranges close to the end of RAM.)

I haven't looked at the details of the implementation, but you can try 
to specify dom0 addresses for your domU. You should see a failure.

> 
>   
>>> I gave a quick look at David's series. Is the idea that I should add a
>>> patch to do the following:
>>>
>>> - avoiding adding these ranges to xenheap in setup_mm, wait for later
>>>     (a bit like reserved_mem regions)
>>
>> I guess by xenheap, you mean domheap? But the problem is not only for domheap,
>> it is also for any memory allocated via the boot allocator. So you need to
>> exclude those regions from any possible allocations.
> 
> OK, I think we are saying the same thing but let me check.
> 
> By boot allocator you mean alloc_boot_pages, right? That boot allocator
> operates on ranges given to it by init_boot_pages calls.

That's correct.

> init_boot_pages is called from setup_mm. I didn't write it clearly but
> I also meant not calling init_boot_pages on them from setup_mm.
> 
> Are we saying the same thing?

Yes.

> 
> 
>>> - in construct_domU, add the range to xenheap and reserve it with
>>> reserve_heap_pages
>>
>> I am afraid you can't give the regions to the allocator and then allocate
>> them. The allocator is free to use any page for its own purpose or exclude
>> them.
>>
>> AFAICT, the allocator doesn't have a list of page in use. It only keeps track
>> of free pages. So we can make the content of struct page_info to look like it
>> was allocated by the allocator.
>>
>> We would need to be careful when giving a page back to allocator as the page
>> would need to be initialized (see [1]). This may not be a concern for Dom0less
>> as the domain may never be destroyed but will be for correctness PoV.
>>
>> For LiveUpdate, the original Xen will carve out space to use by the boot
>> allocator in the new Xen. But I think this is not necessary in your context.
>>
>> It should be sufficient to exclude the page from the boot allocators (as we do
>> for other modules).
>>
>> One potential issue that can arise is there is no easy way today to
>> differentiate between pages allocated and pages not yet initialized. To make
>> the code robust, we need to prevent a page to be used in two places. So for
>> LiveUpdate we are marking them with a special value, this is used afterwards
>> to check we are effictively using a reserved page.
>>
>> I hope this helps.
> 
> Thanks for writing all of this down but I haven't understood some of it.
> 
> For the sake of this discussion let's say that we managed to "reserve"
> the range early enough like we do for other modules, as you wrote.
> 
> At the point where we want to call reserve_heap_pages() we would call
> init_heap_pages() just before it. We are still relatively early at boot
> so there aren't any concurrent memory operations. Why this doesn't work?

Because init_heap_pages() may exclude some pages (for instance MFN 0 is 
carved out) or use pages for its internal structure (see 
init_node_heap()). So you can't expect to be able to allocate the exact 
same region by reserve_heap_pages().

> 
> If it doesn't work, I am not following what is your alternative
> suggestion about making "the content of struct page_info to look like it
> was allocated by the allocator."

If you look at alloc_heap_pages(), it will allocate pages, the allocator 
will initialize some fields in struct page_info before returning the 
page. We basically need to do the same thing, so the struct page_info 
looks exactly the same whether we call alloc_heap_pages() or use memory 
that was carved out from the allocator.

David has spent more time than me on this problem, so I may be missing 
some bits. Based on what we did in the LU PoC, my suggestion would be to:
    1) Carve out the memory from any allocator (and before any memory is 
allocated).
    2) Make sure a struct page_info is allocated for those regions in 
the boot allocator
    3) Mark the regions as reserved in the frametable so we can 
differentiate from the others pages.
    4) Allocate the region when necessary

When it is necessary to allocate the region. For each page:
    1) Check if it is a valid page
    2) Check if the page is reserved
    3) Do the necessary preparation on struct page_info

At the moment, in the LU PoC, we are using count_info = PGC_allocated to 
mark the reserved page. I don't particularly like it and not sure of the 
consequence. So I am open to a different way to mark them.

The last part we need to take care is how to hand over the pages to the 
allocator. This may happen if your domain die or ballooning (although 
not in the direct map case). Even without this series, this is actually 
already a problem today because boot allocator pages may be freed 
afterwards (I think this can only happen on x86 so far). But we are 
getting away because in most of the cases you never carve out a full 
NUMA node. This is where David's patch should help.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:28:14 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUDuw-0008BC-CU; Thu, 30 Apr 2020 18:28:14 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DLrL=6O=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jUDuv-0008Ai-6l
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:28:13 +0000
X-Inumbo-ID: 55d43442-8b10-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 55d43442-8b10-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 18:28:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=m4XtGxf7MAGhA06KJFxfoZNIFGFMA4zXI9CExNGWWzs=; b=Wuc1yfc3VgFXWCA/aL6tvEkwD
 8QTJ10JUoSnlV+yRW/kY6aU4zsfO3Olu9dEn6c3ZtpgiXyguGZUT5zsqms9pNROulMF0s1/ul2ZEz
 1L8IFNnkX5c360xwa38JiYPBiUOyy5wWbnEp5bWBy0R/7vv9G8dE4gk4Ab2WgFNjesZso=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUDuo-0001kB-8y; Thu, 30 Apr 2020 18:28:06 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUDun-0000Zv-Pw; Thu, 30 Apr 2020 18:28:05 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jUDun-0002GQ-Nx; Thu, 30 Apr 2020 18:28:05 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149882-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 149882: tolerable FAIL - PUSHED
X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
X-Osstest-Versions-This: linux=1d2cc5ac6f6668cc15216d51051103c61467d7e8
X-Osstest-Versions-That: linux=96c9a7802af7d500a582d89a8b864584fe878c1b
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 30 Apr 2020 18:28:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149882 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149882/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds     18 guest-localmigrate/x10  fail blocked in 149868
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149868
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149868
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149868
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149868
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149868
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149868
 test-armhf-armhf-xl-rtds     16 guest-start/debian.repeat    fail  like 149868
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149868
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149868
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass

version targeted for testing:
 linux                1d2cc5ac6f6668cc15216d51051103c61467d7e8
baseline version:
 linux                96c9a7802af7d500a582d89a8b864584fe878c1b

Last test of basis   149868  2020-04-29 00:40:01 Z    1 days
Testing same since   149882  2020-04-29 17:08:48 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Damien Le Moal <damien.lemoal@wdc.com>
  Guenter Roeck <linux@roeck-us.net>
  Herbert Xu <herbert@gondor.apana.org.au>
  Ilie Halip <ilie.halip@gmail.com>
  Iuliana Prodan <iuliana.prodan@nxp.com>
  Kefeng Wang <wangkefeng.wang@huawei.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Palmer Dabbelt <palmerdabbelt@google.com>

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                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/linux-pvops.git
   96c9a7802af7..1d2cc5ac6f66  1d2cc5ac6f6668cc15216d51051103c61467d7e8 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:44:07 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUEA6-0001ar-WE; Thu, 30 Apr 2020 18:43:55 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EK+X=6O=redhat.com=david@srs-us1.protection.inumbo.net>)
 id 1jUEA6-0001am-BN
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:43:54 +0000
X-Inumbo-ID: 8a5ee336-8b12-11ea-b07b-bc764e2007e4
Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTP
 id 8a5ee336-8b12-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 18:43:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1588272233;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=bH/2ZwDruja4gxTnRa1DVsu56n26bMasgzm2C8WZHck=;
 b=DaXQIxhh+wTJlH27do7Aur9QN39uy85gk3k+MeV20aPINE4e4f9+FUeJqY8NrzjJQBjZny
 ndQ+JoOSc6bYjr48zbEgkewd53rS8y8BbskG9+8lia47I9F4ftqzK/kNCrBI37CC1pYN+0
 EcVIRMXxLX9jwJO58Ot8W/lTgWSb3JU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-386-hQ9NlpfEPoSF05o-EIV0pw-1; Thu, 30 Apr 2020 14:43:49 -0400
X-MC-Unique: hQ9NlpfEPoSF05o-EIV0pw-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com
 [10.5.11.23])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7677D18FE860;
 Thu, 30 Apr 2020 18:43:46 +0000 (UTC)
Received: from [10.36.113.172] (ovpn-113-172.ams2.redhat.com [10.36.113.172])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 00D3D79B6;
 Thu, 30 Apr 2020 18:43:39 +0000 (UTC)
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
To: "Eric W. Biederman" <ebiederm@xmission.com>,
 Andrew Morton <akpm@linux-foundation.org>
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-3-david@redhat.com>
 <87pnbp2dcz.fsf@x220.int.ebiederm.org>
 <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
 <871ro52ary.fsf@x220.int.ebiederm.org>
 <373a6898-4020-4af1-5b3d-f827d705dd77@redhat.com>
 <875zdg26hp.fsf@x220.int.ebiederm.org>
From: David Hildenbrand <david@redhat.com>
Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata=
 mQINBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABtCREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT6JAlgEEwEIAEICGwMFCQlmAYAGCwkIBwMCBhUI
 AgkKCwQWAgMBAh4BAheAFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl3pImkCGQEACgkQTd4Q
 9wD/g1o+VA//SFvIHUAvul05u6wKv/pIR6aICPdpF9EIgEU448g+7FfDgQwcEny1pbEzAmiw
 zAXIQ9H0NZh96lcq+yDLtONnXk/bEYWHHUA014A1wqcYNRY8RvY1+eVHb0uu0KYQoXkzvu+s
 Dncuguk470XPnscL27hs8PgOP6QjG4jt75K2LfZ0eAqTOUCZTJxA8A7E9+XTYuU0hs7QVrWJ
 jQdFxQbRMrYz7uP8KmTK9/Cnvqehgl4EzyRaZppshruKMeyheBgvgJd5On1wWq4ZUV5PFM4x
 II3QbD3EJfWbaJMR55jI9dMFa+vK7MFz3rhWOkEx/QR959lfdRSTXdxs8V3zDvChcmRVGN8U
 Vo93d1YNtWnA9w6oCW1dnDZ4kgQZZSBIjp6iHcA08apzh7DPi08jL7M9UQByeYGr8KuR4i6e
 RZI6xhlZerUScVzn35ONwOC91VdYiQgjemiVLq1WDDZ3B7DIzUZ4RQTOaIWdtXBWb8zWakt/
 ztGhsx0e39Gvt3391O1PgcA7ilhvqrBPemJrlb9xSPPRbaNAW39P8ws/UJnzSJqnHMVxbRZC
 Am4add/SM+OCP0w3xYss1jy9T+XdZa0lhUvJfLy7tNcjVG/sxkBXOaSC24MFPuwnoC9WvCVQ
 ZBxouph3kqc4Dt5X1EeXVLeba+466P1fe1rC8MbcwDkoUo65Ag0EVcufkQEQAOfX3n0g0fZz
 Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
 T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
 CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
 NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
 lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
 AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
 N7eop7uh+6bezi+rugUI+w6DABEBAAGJAiUEGAECAA8FAlXLn5ECGwwFCQlmAYAACgkQTd4Q
 9wD/g1qA6w/+M+ggFv+JdVsz5+ZIc6MSyGUozASX+bmIuPeIecc9UsFRatc91LuJCKMkD9Uv
 GOcWSeFpLrSGRQ1Z7EMzFVU//qVs6uzhsNk0RYMyS0B6oloW3FpyQ+zOVylFWQCzoyyf227y
 GW8HnXunJSC+4PtlL2AY4yZjAVAPLK2l6mhgClVXTQ/S7cBoTQKP+jvVJOoYkpnFxWE9pn4t
 H5QIFk7Ip8TKr5k3fXVWk4lnUi9MTF/5L/mWqdyIO1s7cjharQCstfWCzWrVeVctpVoDfJWp
 4LwTuQ5yEM2KcPeElLg5fR7WB2zH97oI6/Ko2DlovmfQqXh9xWozQt0iGy5tWzh6I0JrlcxJ
 ileZWLccC4XKD1037Hy2FLAjzfoWgwBLA6ULu0exOOdIa58H4PsXtkFPrUF980EEibUp0zFz
 GotRVekFAceUaRvAj7dh76cToeZkfsjAvBVb4COXuhgX6N4pofgNkW2AtgYu1nUsPAo+NftU
 CxrhjHtLn4QEBpkbErnXQyMjHpIatlYGutVMS91XTQXYydCh5crMPs7hYVsvnmGHIaB9ZMfB
 njnuI31KBiLUks+paRkHQlFcgS2N3gkRBzH7xSZ+t7Re3jvXdXEzKBbQ+dC3lpJB0wPnyMcX
 FOTT3aZT7IgePkt5iC/BKBk3hqKteTnJFeVIT7EC+a6YUFg=
Organization: Red Hat GmbH
Message-ID: <b28c9e02-8cf2-33ae-646b-fe50a185738e@redhat.com>
Date: Thu, 30 Apr 2020 20:43:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <875zdg26hp.fsf@x220.int.ebiederm.org>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
 linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
 linux-s390@vger.kernel.org, linux-nvdimm@lists.01.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
 linux-acpi@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Michal Hocko <mhocko@kernel.org>, linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

 >>> If the class of memory is different then please by all means let's m=
ark
>>> it differently in struct resource so everyone knows it is different.
>>> But that difference needs to be more than hotplug.
>>>
>>> That difference needs to be the hypervisor loaned us memory and might
>>> take it back at any time, or this memory is persistent and so it has
>>> these different characteristics so don't use it as ordinary ram.
>>
>> Yes, and I think kmem took an excellent approach of explicitly putting
>> that "System RAM" into a resource hierarchy. That "System RAM" won't
>> show up as a root node under /proc/iomem (see patch #3), which already
>> results in kexec-tools to treat it in a special way. I am thinking abo=
ut
>> doing the same for virtio-mem.
>=20
> Reading this and your patch cover letters again my concern is that
> the justification seems to be letting the tail wag the dog.
>=20
> You want kexec-tools to behave in a certain way so you are changing the
> kernel.
>=20
> Rather it should be change the kernel to clearly reflect reality and if
> you can get away without a change to kexec-tools that is a bonus.
>=20

Right, because user space has to have a way to figure out what to do.

But talking about the firmware memmap, indicating something via a "raw
firmware-provided memory map", that is not actually in the "raw
firmware-provided memory map" feels wrong to me. (below)


>>> That information is also useful to other people looking at the system
>>> and seeing what is going on.
>>>
>>> Just please don't muddle the concepts, or assume that whatever subset=
 of
>>> hotplug memory you are dealing with is the only subset.
>>
>> I can certainly rephrase the subject/description/comment, stating that
>> this is not to be used for ordinary hotplugged DIMMs - only when the
>> device driver is under control to decide what to do with that memory -
>> especially when kexec'ing.
>>
>> (previously, I called this flag MHP_DRIVER_MANAGED, but I think
>> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
>>
>> Would that make it clearer?
>=20
> I am not certain, but Andrew Morton deliberately added that
> firmware_map_add_hotplug call.  Which means that there is a reason
> for putting hotplugged memory in the firmware map.
>=20
> So the justification needs to take that reason into account.  The
> justification can not be it is hotplugged therefore it should not belon=
g
> in the firmware memory map.  Unless you can show that
> firmware_map_add_hotplug that was actually a bug and should be removed.
> But as it has been that way since 2010 that seems like a long shot.
>=20
> So my question is what is right for the firmware map?

We have documentation for that since 2008. Andrews patch is from 2010.

Documentation/ABI/testing/sysfs-firmware-memmap

It clearly talks about "raw firmware-provided memory map" and why the
interface was introduced at all ("on most architectures that
firmware-provided memory map is modified afterwards by the kernel itself"=
).

>=20
> Why does the firmware map support hotplug entries?

I assume:

The firmware memmap was added primarily for x86-64 kexec (and still, is
mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs
get hotplugged on real HW, they get added to e820. Same applies to
memory added via HyperV balloon (unless memory is unplugged via
ballooning and you reboot ... the the e820 is changed as well). I assume
we wanted to be able to reflect that, to make kexec look like a real rebo=
ot.

This worked for a while. Then came dax/kmem. Now comes virtio-mem.


But I assume only Andrew can enlighten us.

@Andrew, any guidance here? Should we really add all memory to the
firmware memmap, even if this contradicts with the existing
documentation? (especially, if the actual firmware memmap will *not*
contain that memory after a reboot)

--=20
Thanks,

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 18:58:43 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 18:58:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUEOI-0002XX-6Z; Thu, 30 Apr 2020 18:58:34 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JErk=6O=intel.com=dan.j.williams@srs-us1.protection.inumbo.net>)
 id 1jUEOG-0002XS-Og
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 18:58:32 +0000
X-Inumbo-ID: 9451f1ce-8b14-11ea-9887-bc764e2007e4
Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9451f1ce-8b14-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 18:58:29 +0000 (UTC)
Received: by mail-ej1-x642.google.com with SMTP id nv1so5592143ejb.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 11:58:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=intel-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=VO82Y+ddPqwVbejb8yp1YADHo+TiaduERH1aUXgFNdU=;
 b=ftYR3vvy7y4XQUHnig2EWsnYgRjVl+CPW2em4ftSq034hx6ZoqSueCcso+RG9w8AGa
 w0/+YALKEw0FIaP05V+9C0XKOYuOmd59KAW1siA/r09GzwZUf48N8GmxNx1dxSbliixs
 CuBWjC2ORmo5GZgQNulH0b+ykeGy5IQzQog4ZcfdBGWxbr/kGwbKqiBi3jZCbBsGvnNW
 Q5W2E6yv533qZlcTHc6rxcPndCCEwjOVK0cZ2rz6LGVrs0kCEepYAF9z3xs1VIBjMZtf
 A5p7YNgqSxKHyCub+EuUXAZ2xuX50SSxRFhOGGuo9nNwQKHccsh0XWdv0oNDM0uH1ryy
 dbvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=VO82Y+ddPqwVbejb8yp1YADHo+TiaduERH1aUXgFNdU=;
 b=kbVUav/KmM+jpjChIPAht4Je7ydFJjDr7DxaipSy3IA+QzahEXyqHdM0EGCU5qxTI5
 GppXhvHxnKWBreDsyC/TFNERYNvdeAznDomGF7jsp29o60va2+iKlz4Vfq0qTX1HeGvY
 HomORIbJWPXL2KXxAEmaJTUhGaEyrpKscrBzH4oXN/u3PSBnk3Vu0uFDnoaP56Q4M+cJ
 G5Ej129Eozqa1IkMO1ArnszDX18vKRE6ogM2N7rVG+tuJhUm0Zjk0VSVNp9GjetPVpla
 g0Q97Adlg86CHSBDhW24w6HX9nf7zEYrFmr1lr9/j1WqVKv/AErjXLxP8U+p/J7OHb2N
 AdYg==
X-Gm-Message-State: AGi0Puah2PCSwaj7HBSyzIrBm+3aZ4lxBopjRWBEx5AW1IA3sWxGBUjG
 NNRMCs6ULfokL09avnIv7vqH462Si4k9rqv20JPxkw==
X-Google-Smtp-Source: APiQypLtO6lmgP+/t4n/a1LprqtsF2znfD77bnYaqHJRks9KFzncsFlKVdj99iACRR541U4ie6ERYFDj3Eno6uEUPdw=
X-Received: by 2002:a17:906:855a:: with SMTP id
 h26mr4305126ejy.56.1588273108788; 
 Thu, 30 Apr 2020 11:58:28 -0700 (PDT)
MIME-Version: 1.0
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-3-david@redhat.com>
 <87pnbp2dcz.fsf@x220.int.ebiederm.org>
 <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
 <871ro52ary.fsf@x220.int.ebiederm.org>
 <373a6898-4020-4af1-5b3d-f827d705dd77@redhat.com>
 <875zdg26hp.fsf@x220.int.ebiederm.org>
 <b28c9e02-8cf2-33ae-646b-fe50a185738e@redhat.com>
In-Reply-To: <b28c9e02-8cf2-33ae-646b-fe50a185738e@redhat.com>
From: Dan Williams <dan.j.williams@intel.com>
Date: Thu, 30 Apr 2020 11:58:16 -0700
Message-ID: <CAPcyv4j33bwbrFMu2L0knRGRN1RDiC5kbknMNEwo-OFmPSw47w@mail.gmail.com>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
To: David Hildenbrand <david@redhat.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
 Linux ACPI <linux-acpi@vger.kernel.org>, Wei Yang <richard.weiyang@gmail.com>,
 linux-s390 <linux-s390@vger.kernel.org>,
 linux-nvdimm <linux-nvdimm@lists.01.org>,
 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 virtualization@lists.linux-foundation.org, Linux MM <linux-mm@kvack.org>,
 "Michael S . Tsirkin" <mst@redhat.com>,
 "Eric W. Biederman" <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>,
 linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 11:44 AM David Hildenbrand <david@redhat.com> wrote:
>
>  >>> If the class of memory is different then please by all means let's mark
> >>> it differently in struct resource so everyone knows it is different.
> >>> But that difference needs to be more than hotplug.
> >>>
> >>> That difference needs to be the hypervisor loaned us memory and might
> >>> take it back at any time, or this memory is persistent and so it has
> >>> these different characteristics so don't use it as ordinary ram.
> >>
> >> Yes, and I think kmem took an excellent approach of explicitly putting
> >> that "System RAM" into a resource hierarchy. That "System RAM" won't
> >> show up as a root node under /proc/iomem (see patch #3), which already
> >> results in kexec-tools to treat it in a special way. I am thinking about
> >> doing the same for virtio-mem.
> >
> > Reading this and your patch cover letters again my concern is that
> > the justification seems to be letting the tail wag the dog.
> >
> > You want kexec-tools to behave in a certain way so you are changing the
> > kernel.
> >
> > Rather it should be change the kernel to clearly reflect reality and if
> > you can get away without a change to kexec-tools that is a bonus.
> >
>
> Right, because user space has to have a way to figure out what to do.
>
> But talking about the firmware memmap, indicating something via a "raw
> firmware-provided memory map", that is not actually in the "raw
> firmware-provided memory map" feels wrong to me. (below)
>
>
> >>> That information is also useful to other people looking at the system
> >>> and seeing what is going on.
> >>>
> >>> Just please don't muddle the concepts, or assume that whatever subset of
> >>> hotplug memory you are dealing with is the only subset.
> >>
> >> I can certainly rephrase the subject/description/comment, stating that
> >> this is not to be used for ordinary hotplugged DIMMs - only when the
> >> device driver is under control to decide what to do with that memory -
> >> especially when kexec'ing.
> >>
> >> (previously, I called this flag MHP_DRIVER_MANAGED, but I think
> >> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
> >>
> >> Would that make it clearer?
> >
> > I am not certain, but Andrew Morton deliberately added that
> > firmware_map_add_hotplug call.  Which means that there is a reason
> > for putting hotplugged memory in the firmware map.
> >
> > So the justification needs to take that reason into account.  The
> > justification can not be it is hotplugged therefore it should not belong
> > in the firmware memory map.  Unless you can show that
> > firmware_map_add_hotplug that was actually a bug and should be removed.
> > But as it has been that way since 2010 that seems like a long shot.
> >
> > So my question is what is right for the firmware map?
>
> We have documentation for that since 2008. Andrews patch is from 2010.
>
> Documentation/ABI/testing/sysfs-firmware-memmap
>
> It clearly talks about "raw firmware-provided memory map" and why the
> interface was introduced at all ("on most architectures that
> firmware-provided memory map is modified afterwards by the kernel itself").
>
> >
> > Why does the firmware map support hotplug entries?
>
> I assume:
>
> The firmware memmap was added primarily for x86-64 kexec (and still, is
> mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs
> get hotplugged on real HW, they get added to e820. Same applies to
> memory added via HyperV balloon (unless memory is unplugged via
> ballooning and you reboot ... the the e820 is changed as well). I assume
> we wanted to be able to reflect that, to make kexec look like a real reboot.

I can at least say that this breakdown makes sense to me. Traditional
memory hotplug results in permanent change to the raw firmware memory
map reported by the host at next reboot. These device-driver-owned
memory regions really want a hotplug policy per-kernel boot instance
and should fall back to the default reserved state at reboot (kexec or
otherwise). When I say hotplug-policy I mean whether the current
kernel wants to treat the device range as System RAM or leave it as
device-managed. The intent is that the follow-on kernel needs to
re-decide the device policy.

>
> This worked for a while. Then came dax/kmem. Now comes virtio-mem.
>


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:44:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG2y-0002oT-Ur; Thu, 30 Apr 2020 20:44:40 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG2x-0002oO-34
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:44:39 +0000
X-Inumbo-ID: 67ddbcb8-8b23-11ea-9aaf-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 67ddbcb8-8b23-11ea-9aaf-12813bfff9fa;
 Thu, 30 Apr 2020 20:44:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=65lvQ4PbPRxi9d54dSLD9/wIHTVMii+HQcXJixzddik=; b=RYV6TpNPcZAXOe47Tm8GnwMS4n
 Ak++zpff4XuAzR+W5jzfjNi6XjfPVrIzK47yGEw9HrWmZ3errmV/NfoTp6TfDpiDJTfvFIvBazLOM
 gL/dBGhV6zvnwwb1LzIkh//lr7xOZLFBSjOwjTQ+mUlPpiwrPDajxnR+W1tw8kKqTaqg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG2u-0004Ko-Nk; Thu, 30 Apr 2020 20:44:36 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG2u-0005wj-Cw; Thu, 30 Apr 2020 20:44:36 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 00/16] Remove the direct map
Date: Thu, 30 Apr 2020 21:44:09 +0100
Message-Id: <cover.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

This series depends on Xen page table domheap conversion:
https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg01374.html.

After breaking the reliance on the direct map to manipulate Xen page
tables, we can now finally remove the direct map altogether.

This series:
- fixes many places that use the direct map incorrectly or assume the
  presence of an always-mapped direct map in a wrong way.
- includes the early vmap patches for global mappings.
- initialises the mapcache for all domains, disables the fast path that
  uses the direct map for mappings.
- maps and unmaps xenheap on-demand.
- adds a boot command line switch to enable or disable the direct map.

This previous version was in RFC state and can be found here:
https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg02647.html,
which has since been broken into small series.

Hongyan Xia (12):
  acpi: vmap pages in acpi_os_alloc_memory
  x86/numa: vmap the pages for memnodemap
  x86/srat: vmap the pages for acpi_slit
  x86: map/unmap pages in restore_all_guests.
  x86/pv: rewrite how building PV dom0 handles domheap mappings
  x86/mapcache: initialise the mapcache for the idle domain
  x86: add a boot option to enable and disable the direct map
  x86/domain_page: remove the fast paths when mfn is not in the
    directmap
  xen/page_alloc: add a path for xenheap when there is no direct map
  x86/setup: leave early boot slightly earlier
  x86/setup: vmap heap nodes when they are outside the direct map
  x86/setup: do not create valid mappings when directmap=no

Wei Liu (4):
  x86/setup: move vm_init() before acpi calls
  x86/pv: domheap pages should be mapped while relocating initrd
  x86: add Persistent Map (PMAP) infrastructure
  x86: lift mapcache variable to the arch level

 docs/misc/xen-command-line.pandoc |  12 +++
 xen/arch/arm/setup.c              |   4 +-
 xen/arch/x86/Makefile             |   1 +
 xen/arch/x86/domain.c             |   4 +-
 xen/arch/x86/domain_page.c        |  53 ++++++++-----
 xen/arch/x86/mm.c                 |   8 +-
 xen/arch/x86/numa.c               |   8 +-
 xen/arch/x86/pmap.c               |  87 +++++++++++++++++++++
 xen/arch/x86/pv/dom0_build.c      |  75 ++++++++++++++----
 xen/arch/x86/setup.c              | 125 +++++++++++++++++++++++++-----
 xen/arch/x86/srat.c               |   3 +-
 xen/arch/x86/x86_64/entry.S       |  27 ++++++-
 xen/common/page_alloc.c           |  85 +++++++++++++++++---
 xen/common/vmap.c                 |  37 +++++++--
 xen/drivers/acpi/osl.c            |   9 ++-
 xen/include/asm-arm/mm.h          |   5 ++
 xen/include/asm-x86/domain.h      |  12 +--
 xen/include/asm-x86/fixmap.h      |   3 +
 xen/include/asm-x86/mm.h          |  17 +++-
 xen/include/asm-x86/pmap.h        |  10 +++
 xen/include/xen/vmap.h            |   5 ++
 21 files changed, 495 insertions(+), 95 deletions(-)
 create mode 100644 xen/arch/x86/pmap.c
 create mode 100644 xen/include/asm-x86/pmap.h

-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:44:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG36-0002pZ-2Q; Thu, 30 Apr 2020 20:44:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG34-0002pO-Ev
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:44:46 +0000
X-Inumbo-ID: 6ad52000-8b23-11ea-ae69-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6ad52000-8b23-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 20:44:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=OnO+pVh1ubCsK0ipJDW4CA7CINr9chMuRxxDESUPwi4=; b=439Wd2ro1oGLaPPX0JahId3fzs
 2UZjHr0o8rVmfbRuWbS7GpBZCoEd1PAGXxdfto+n1F2uWiEjq5qn4kL5lvCz0NR9EMQGJQYWPuIQz
 tmGc8oqYeouUa9D4QxWaoDQIiJh0JBe4ZuFGdz7L1nX6UgpjPr1SrSMOZMc5klNivpW4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG2z-0004LB-Q1; Thu, 30 Apr 2020 20:44:41 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG2z-0005wj-GN; Thu, 30 Apr 2020 20:44:41 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 03/16] x86/numa: vmap the pages for memnodemap
Date: Thu, 30 Apr 2020 21:44:12 +0100
Message-Id: <9a007a9965461127e2a3361cc1fde6a2d217ef48.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

This avoids the assumption that there is a direct map and boot pages
fall inside the direct map.

Clean up the variables so that mfn actually stores a type-safe mfn.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/numa.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index f1066c59c7..51eca3f3fc 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -100,13 +100,13 @@ static int __init populate_memnodemap(const struct node *nodes,
 static int __init allocate_cachealigned_memnodemap(void)
 {
     unsigned long size = PFN_UP(memnodemapsize * sizeof(*memnodemap));
-    unsigned long mfn = mfn_x(alloc_boot_pages(size, 1));
+    mfn_t mfn = alloc_boot_pages(size, 1);
 
-    memnodemap = mfn_to_virt(mfn);
-    mfn <<= PAGE_SHIFT;
+    memnodemap = vmap_boot_pages(mfn, size);
+    BUG_ON(!memnodemap);
     size <<= PAGE_SHIFT;
     printk(KERN_DEBUG "NUMA: Allocated memnodemap from %lx - %lx\n",
-           mfn, mfn + size);
+           mfn_to_maddr(mfn), mfn_to_maddr(mfn) + size);
     memnodemapsize = size / sizeof(*memnodemap);
 
     return 0;
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:44:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG3A-0002qt-O6; Thu, 30 Apr 2020 20:44:52 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG39-0002qK-EF
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:44:51 +0000
X-Inumbo-ID: 6c920ebc-8b23-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6c920ebc-8b23-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 20:44:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=WTEV0oPtcbmzQwnNtr2I2AVsKwc6yGr7IZ4NoXd1nT4=; b=cdbbpPvFM/mqtoRn44qvXJUJ4E
 SAz077vwekyoVNG4sLAzgzr8i2FsuLB8SvwFl0rw55f/u0ElP8VlofANR8/aRzyeJOtHaQBSzKarT
 PiJ8oEW5NYkGxTPvhqeuh7OVM/GrUQcqaVtacXAAc/XRSz5Kxlryon/f9Swfq02cHHyA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG32-0004LP-Mo; Thu, 30 Apr 2020 20:44:44 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG32-0005wj-Cc; Thu, 30 Apr 2020 20:44:44 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 05/16] x86: map/unmap pages in restore_all_guests.
Date: Thu, 30 Apr 2020 21:44:14 +0100
Message-Id: <97a7680a1be26f6e34b91d29551747afa5235555.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

Before, it assumed the pv cr3 could be accessed via a direct map. This
is no longer true.

Note that we do not map and unmap root_pgt for now since it is still a
xenheap page.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/x86_64/entry.S | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index d55453f3f3..110cd0394f 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -154,7 +154,24 @@ restore_all_guest:
         and   %rsi, %rdi
         and   %r9, %rsi
         add   %rcx, %rdi
-        add   %rcx, %rsi
+
+         /*
+          * Without a direct map, we have to map first before copying. We only
+          * need to map the guest root table but not the per-CPU root_pgt,
+          * because the latter is still a xenheap page.
+          */
+        pushq %r9
+        pushq %rdx
+        pushq %rax
+        pushq %rdi
+        mov   %rsi, %rdi
+        shr   $PAGE_SHIFT, %rdi
+        callq map_domain_page
+        mov   %rax, %rsi
+        popq  %rdi
+        /* Stash the pointer for unmapping later. */
+        pushq %rax
+
         mov   $ROOT_PAGETABLE_FIRST_XEN_SLOT, %ecx
         mov   root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rsi), %r8
         mov   %r8, root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rdi)
@@ -166,6 +183,14 @@ restore_all_guest:
         sub   $(ROOT_PAGETABLE_FIRST_XEN_SLOT - \
                 ROOT_PAGETABLE_LAST_XEN_SLOT - 1) * 8, %rdi
         rep movsq
+
+        /* Unmap the page. */
+        popq  %rdi
+        callq unmap_domain_page
+        popq  %rax
+        popq  %rdx
+        popq  %r9
+
 .Lrag_copy_done:
         mov   %r9, STACK_CPUINFO_FIELD(xen_cr3)(%rdx)
         movb  $1, STACK_CPUINFO_FIELD(use_pv_cr3)(%rdx)
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:44:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG31-0002oe-7q; Thu, 30 Apr 2020 20:44:43 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG2z-0002oZ-Gl
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:44:41 +0000
X-Inumbo-ID: 6a0b6dc8-8b23-11ea-b9cf-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6a0b6dc8-8b23-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 20:44:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=mny4fPGI0W4kUckCGEUBvQNC9MU0BAlbEexMC4JDbrU=; b=qCRIOJB3HVKUWxuaCufWT128qC
 L1aqst12J/+1zHfzX8myHDSFQDCOCuKkgc5zDiDbEd8QTjWaXYlS5tiRH9JMfcrfWdTmJ5NyJ9vG+
 d092LdAOlkOX5j3wDWzaG3EQ+zglhFK812VPu0KH2cHEk1rpOLNL8l1+emPs5w4O0Uw8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG2y-0004L2-CB; Thu, 30 Apr 2020 20:44:40 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG2y-0005wj-2Q; Thu, 30 Apr 2020 20:44:40 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 02/16] acpi: vmap pages in acpi_os_alloc_memory
Date: Thu, 30 Apr 2020 21:44:11 +0100
Message-Id: <a71d1903267b84afdb0e54fa2ac55540ab2f9357.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

Also, introduce a wrapper around vmap that maps a contiguous range for
boot allocations.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/drivers/acpi/osl.c | 9 ++++++++-
 xen/include/xen/vmap.h | 5 +++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 4c8bb7839e..d0762dad4e 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -219,7 +219,11 @@ void *__init acpi_os_alloc_memory(size_t sz)
 	void *ptr;
 
 	if (system_state == SYS_STATE_early_boot)
-		return mfn_to_virt(mfn_x(alloc_boot_pages(PFN_UP(sz), 1)));
+	{
+		mfn_t mfn = alloc_boot_pages(PFN_UP(sz), 1);
+
+		return vmap_boot_pages(mfn, PFN_UP(sz));
+	}
 
 	ptr = xmalloc_bytes(sz);
 	ASSERT(!ptr || is_xmalloc_memory(ptr));
@@ -244,5 +248,8 @@ void __init acpi_os_free_memory(void *ptr)
 	if (is_xmalloc_memory(ptr))
 		xfree(ptr);
 	else if (ptr && system_state == SYS_STATE_early_boot)
+	{
+		vunmap(ptr);
 		init_boot_pages(__pa(ptr), __pa(ptr) + PAGE_SIZE);
+	}
 }
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 369560e620..c70801e195 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -23,6 +23,11 @@ void *vmalloc_xen(size_t size);
 void *vzalloc(size_t size);
 void vfree(void *va);
 
+static inline void *vmap_boot_pages(mfn_t mfn, unsigned int nr_pages)
+{
+    return __vmap(&mfn, nr_pages, 1, 1, PAGE_HYPERVISOR, VMAP_DEFAULT);
+}
+
 void __iomem *ioremap(paddr_t, size_t);
 
 static inline void iounmap(void __iomem *va)
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:44:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG32-0002op-IS; Thu, 30 Apr 2020 20:44:44 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG31-0002ok-Rk
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:44:43 +0000
X-Inumbo-ID: 691dd6bc-8b23-11ea-9aaf-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 691dd6bc-8b23-11ea-9aaf-12813bfff9fa;
 Thu, 30 Apr 2020 20:44:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=N6y7WNNIWMO3WocYdovup6f1egnxn9RTSj105NrfG5Q=; b=5iNBkOqMsqkMJcNQR3NM3JHRRb
 2aO9ma52JHL8rPL36/oljF/PGHY5SZKIQQ0BFSJFXel6loih+ewgqTI6TlDfFduTOxG2/d/MGFbSi
 W706jUyccJkaU4kKJxiJoqsA5Ech9GyThky18TeWGyHfDCdcj0Il4eiEWpF8rbL9NJ5U=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG2w-0004Kt-MH; Thu, 30 Apr 2020 20:44:38 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG2w-0005wj-Bb; Thu, 30 Apr 2020 20:44:38 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 01/16] x86/setup: move vm_init() before acpi calls
Date: Thu, 30 Apr 2020 21:44:10 +0100
Message-Id: <d000ae874e008bf0c9d3da67d08e43bcd3d42761.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

After the direct map removal, pages from the boot allocator are not
mapped at all in the direct map. Although we have map_domain_page, they
are ephemeral and are less helpful for mappings that are more than a
page, so we want a mechanism to globally map a range of pages, which is
what vmap is for. Therefore, we bring vm_init into early boot stage.

To allow vmap to be initialised and used in early boot, we need to
modify vmap to receive pages from the boot allocator during early boot
stage.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David Woodhouse <dwmw2@amazon.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/arm/setup.c |  4 ++--
 xen/arch/x86/setup.c | 31 ++++++++++++++++++++-----------
 xen/common/vmap.c    | 37 +++++++++++++++++++++++++++++--------
 3 files changed, 51 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7968cee47d..8f0ac87419 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -822,6 +822,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     setup_mm();
 
+    vm_init();
+
     /* Parse the ACPI tables for possible boot-time configuration */
     acpi_boot_table_init();
 
@@ -833,8 +835,6 @@ void __init start_xen(unsigned long boot_phys_offset,
      */
     system_state = SYS_STATE_boot;
 
-    vm_init();
-
     if ( acpi_disabled )
     {
         printk("Booting using Device Tree\n");
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index fc0a6e5fcc..faca8c9758 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -695,6 +695,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     int i, j, e820_warn = 0, bytes = 0;
     bool acpi_boot_table_init_done = false, relocated = false;
     int ret;
+    bool vm_init_done = false;
     struct ns16550_defaults ns16550 = {
         .data_bits = 8,
         .parity    = 'n',
@@ -1301,12 +1302,23 @@ void __init noreturn __start_xen(unsigned long mbi_p)
             continue;
 
         if ( !acpi_boot_table_init_done &&
-             s >= (1ULL << 32) &&
-             !acpi_boot_table_init() )
+             s >= (1ULL << 32) )
         {
-            acpi_boot_table_init_done = true;
-            srat_parse_regions(s);
-            setup_max_pdx(raw_max_page);
+            /*
+             * We only initialise vmap and acpi after going through the bottom
+             * 4GiB, so that we have enough pages in the boot allocator.
+             */
+            if ( !vm_init_done )
+            {
+                vm_init();
+                vm_init_done = true;
+            }
+            if ( !acpi_boot_table_init() )
+            {
+                acpi_boot_table_init_done = true;
+                srat_parse_regions(s);
+                setup_max_pdx(raw_max_page);
+            }
         }
 
         if ( pfn_to_pdx((e - 1) >> PAGE_SHIFT) >= max_pdx )
@@ -1483,6 +1495,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
     init_frametable();
 
+    if ( !vm_init_done )
+        vm_init();
+
     if ( !acpi_boot_table_init_done )
         acpi_boot_table_init();
 
@@ -1520,12 +1535,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
         end_boot_allocator();
 
     system_state = SYS_STATE_boot;
-    /*
-     * No calls involving ACPI code should go between the setting of
-     * SYS_STATE_boot and vm_init() (or else acpi_os_{,un}map_memory()
-     * will break).
-     */
-    vm_init();
 
     console_init_ring();
     vesa_init();
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 9964ab2096..e8533a8a80 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -35,9 +35,20 @@ void __init vm_init_type(enum vmap_region type, void *start, void *end)
 
     for ( i = 0, va = (unsigned long)vm_bitmap(type); i < nr; ++i, va += PAGE_SIZE )
     {
-        struct page_info *pg = alloc_domheap_page(NULL, 0);
+        mfn_t mfn;
+        int rc;
 
-        map_pages_to_xen(va, page_to_mfn(pg), 1, PAGE_HYPERVISOR);
+        if ( system_state == SYS_STATE_early_boot )
+            mfn = alloc_boot_pages(1, 1);
+        else
+        {
+            struct page_info *pg = alloc_domheap_page(NULL, 0);
+
+            BUG_ON(!pg);
+            mfn = page_to_mfn(pg);
+        }
+        rc = map_pages_to_xen(va, mfn, 1, PAGE_HYPERVISOR);
+        BUG_ON(rc);
         clear_page((void *)va);
     }
     bitmap_fill(vm_bitmap(type), vm_low[type]);
@@ -63,7 +74,7 @@ static void *vm_alloc(unsigned int nr, unsigned int align,
     spin_lock(&vm_lock);
     for ( ; ; )
     {
-        struct page_info *pg;
+        mfn_t mfn;
 
         ASSERT(vm_low[t] == vm_top[t] || !test_bit(vm_low[t], vm_bitmap(t)));
         for ( start = vm_low[t]; start < vm_top[t]; )
@@ -98,9 +109,16 @@ static void *vm_alloc(unsigned int nr, unsigned int align,
         if ( vm_top[t] >= vm_end[t] )
             return NULL;
 
-        pg = alloc_domheap_page(NULL, 0);
-        if ( !pg )
-            return NULL;
+        if ( system_state == SYS_STATE_early_boot )
+            mfn = alloc_boot_pages(1, 1);
+        else
+        {
+            struct page_info *pg = alloc_domheap_page(NULL, 0);
+
+            if ( !pg )
+                return NULL;
+            mfn = page_to_mfn(pg);
+        }
 
         spin_lock(&vm_lock);
 
@@ -108,7 +126,7 @@ static void *vm_alloc(unsigned int nr, unsigned int align,
         {
             unsigned long va = (unsigned long)vm_bitmap(t) + vm_top[t] / 8;
 
-            if ( !map_pages_to_xen(va, page_to_mfn(pg), 1, PAGE_HYPERVISOR) )
+            if ( !map_pages_to_xen(va, mfn, 1, PAGE_HYPERVISOR) )
             {
                 clear_page((void *)va);
                 vm_top[t] += PAGE_SIZE * 8;
@@ -118,7 +136,10 @@ static void *vm_alloc(unsigned int nr, unsigned int align,
             }
         }
 
-        free_domheap_page(pg);
+        if ( system_state == SYS_STATE_early_boot )
+            init_boot_pages(mfn_to_maddr(mfn), mfn_to_maddr(mfn) + PAGE_SIZE);
+        else
+            free_domheap_page(mfn_to_page(mfn));
 
         if ( start >= vm_top[t] )
         {
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:44:53 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG38-0002pu-CF; Thu, 30 Apr 2020 20:44:50 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG36-0002pi-Ro
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:44:48 +0000
X-Inumbo-ID: 6b9ad03e-8b23-11ea-9aaf-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6b9ad03e-8b23-11ea-9aaf-12813bfff9fa;
 Thu, 30 Apr 2020 20:44:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=lV7eCfKft8Va6m4uNBBmoRi9XzqEneVzvGHlaIMLHds=; b=uYUxtIHD8MR/+KYumRVW16F+UA
 YB51HnVj3v7KqMEsddmEI8nPi+vxoKYfqM+BP5L7PANMjASGaMa6pcOdFqqRuSwTQzI0binfimCJo
 /e3ehVqSE2MyPpxxG9Xb3oYsvTQxLj8r80tfxjgnhMVQWR8TIH54CDxjtes744lpQQtQ=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG31-0004LH-7y; Thu, 30 Apr 2020 20:44:43 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG30-0005wj-US; Thu, 30 Apr 2020 20:44:43 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 04/16] x86/srat: vmap the pages for acpi_slit
Date: Thu, 30 Apr 2020 21:44:13 +0100
Message-Id: <f4226fafcd333c0274fcee24601c280bf6494417.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

This avoids the assumption that boot pages are in the direct map.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/srat.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 506a56d66b..9a84c6c8a8 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -196,7 +196,8 @@ void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
 		return;
 	}
 	mfn = alloc_boot_pages(PFN_UP(slit->header.length), 1);
-	acpi_slit = mfn_to_virt(mfn_x(mfn));
+	acpi_slit = vmap_boot_pages(mfn, PFN_UP(slit->header.length));
+	BUG_ON(!acpi_slit);
 	memcpy(acpi_slit, slit, slit->header.length);
 }
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:44:55 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG3D-0002tG-3T; Thu, 30 Apr 2020 20:44:55 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG3B-0002sV-S0
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:44:53 +0000
X-Inumbo-ID: 6d691b32-8b23-11ea-9aaf-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6d691b32-8b23-11ea-9aaf-12813bfff9fa;
 Thu, 30 Apr 2020 20:44:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=X5SxQC62czR9+3XEiKLbmZlfT+782Zyy4B2JOemF0eA=; b=j45FVkk1uPTyI4beeHYTMJtL1z
 cAUwlKi4AHWpsW4uytEQGmJBL73hKK9YgJKQkYOPVT536BsDSv774j3mGtEmYZMDLNq08gqzVhl4q
 xtvpSix5xmaT8beOkXfhCJO6MdHxw5Ll21HTa8sDNXhT9nYhmaNdew61fpVrnQwkKkKA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG34-0004LV-3Z; Thu, 30 Apr 2020 20:44:46 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG33-0005wj-QZ; Thu, 30 Apr 2020 20:44:46 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 06/16] x86/pv: domheap pages should be mapped while relocating
 initrd
Date: Thu, 30 Apr 2020 21:44:15 +0100
Message-Id: <535925f046bcc38fa26e2d5fd1c47c58f4e41b37.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

Xen shouldn't use domheap page as if they were xenheap pages. Map and
unmap pages accordingly.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Wang <wawei@amazon.de>
---
 xen/arch/x86/pv/dom0_build.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 3522eb0114..b052f13462 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -515,18 +515,31 @@ int __init dom0_construct_pv(struct domain *d,
         if ( d->arch.physaddr_bitsize &&
              ((mfn + count - 1) >> (d->arch.physaddr_bitsize - PAGE_SHIFT)) )
         {
+            unsigned long nr_pages;
+            unsigned long len = initrd_len;
+
             order = get_order_from_pages(count);
             page = alloc_domheap_pages(d, order, MEMF_no_scrub);
             if ( !page )
                 panic("Not enough RAM for domain 0 initrd\n");
+
+            nr_pages = 1UL << order;
             for ( count = -count; order--; )
                 if ( count & (1UL << order) )
                 {
                     free_domheap_pages(page, order);
                     page += 1UL << order;
+                    nr_pages -= 1UL << order;
                 }
-            memcpy(page_to_virt(page), mfn_to_virt(initrd->mod_start),
-                   initrd_len);
+
+            for ( i = 0; i < nr_pages; i++, len -= PAGE_SIZE )
+            {
+                void *p = __map_domain_page(page + i);
+                memcpy(p, mfn_to_virt(initrd_mfn + i),
+                       min(len, (unsigned long)PAGE_SIZE));
+                unmap_domain_page(p);
+            }
+
             mpt_alloc = (paddr_t)initrd->mod_start << PAGE_SHIFT;
             init_domheap_pages(mpt_alloc,
                                mpt_alloc + PAGE_ALIGN(initrd_len));
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:44:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:44:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG3F-0002uu-GP; Thu, 30 Apr 2020 20:44:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG3E-0002uE-EI
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:44:56 +0000
X-Inumbo-ID: 6e33b0fe-8b23-11ea-b07b-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 6e33b0fe-8b23-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 20:44:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=9eF+qb5V9Z9xxRC1WCmcjTYdHVKPY6+x95YE0mwwEYA=; b=mGheIJdijdnAzN7nyVUP750uWf
 MJSDx6ufAsJ9VQBVZLr42scaVu1w5KybOeVRGaDszwKaqWl+0SOPu0I7is5xmXlfVs1fS/VyiVEzK
 i2XNeB4bWSsmRjzm+bjMHQ/f+CsD90G0AzYJW56DgbT4jbXMp/DH9Y7PVd8n5msiAWVk=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG35-0004Lb-I3; Thu, 30 Apr 2020 20:44:47 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG35-0005wj-8Z; Thu, 30 Apr 2020 20:44:47 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 07/16] x86/pv: rewrite how building PV dom0 handles domheap
 mappings
Date: Thu, 30 Apr 2020 21:44:16 +0100
Message-Id: <f16792ed755f806785cd4c0483e46d9c40d9f82b.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

Building a PV dom0 is allocating from the domheap but uses it like the
xenheap. This is clearly wrong. Fix.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/pv/dom0_build.c | 58 ++++++++++++++++++++++++++----------
 1 file changed, 43 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index b052f13462..adaa6afda2 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -309,6 +309,10 @@ int __init dom0_construct_pv(struct domain *d,
     l3_pgentry_t *l3tab = NULL, *l3start = NULL;
     l2_pgentry_t *l2tab = NULL, *l2start = NULL;
     l1_pgentry_t *l1tab = NULL, *l1start = NULL;
+    mfn_t l4start_mfn = INVALID_MFN;
+    mfn_t l3start_mfn = INVALID_MFN;
+    mfn_t l2start_mfn = INVALID_MFN;
+    mfn_t l1start_mfn = INVALID_MFN;
 
     /*
      * This fully describes the memory layout of the initial domain. All
@@ -535,6 +539,7 @@ int __init dom0_construct_pv(struct domain *d,
             for ( i = 0; i < nr_pages; i++, len -= PAGE_SIZE )
             {
                 void *p = __map_domain_page(page + i);
+
                 memcpy(p, mfn_to_virt(initrd_mfn + i),
                        min(len, (unsigned long)PAGE_SIZE));
                 unmap_domain_page(p);
@@ -610,23 +615,32 @@ int __init dom0_construct_pv(struct domain *d,
         v->arch.pv.event_callback_cs    = FLAT_COMPAT_KERNEL_CS;
     }
 
+#define UNMAP_MAP_AND_ADVANCE(mfn_var, virt_var, maddr) \
+do {                                                    \
+    UNMAP_DOMAIN_PAGE(virt_var);                        \
+    mfn_var = maddr_to_mfn(maddr);                      \
+    maddr += PAGE_SIZE;                                 \
+    virt_var = map_domain_page(mfn_var);                \
+} while ( false )
+
     /* WARNING: The new domain must have its 'processor' field filled in! */
     if ( !is_pv_32bit_domain(d) )
     {
         maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l4_page_table;
-        l4start = l4tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+        UNMAP_MAP_AND_ADVANCE(l4start_mfn, l4start, mpt_alloc);
+        l4tab = l4start;
         clear_page(l4tab);
-        init_xen_l4_slots(l4tab, _mfn(virt_to_mfn(l4start)),
-                          d, INVALID_MFN, true);
-        v->arch.guest_table = pagetable_from_paddr(__pa(l4start));
+        init_xen_l4_slots(l4tab, l4start_mfn, d, INVALID_MFN, true);
+        v->arch.guest_table = pagetable_from_mfn(l4start_mfn);
     }
     else
     {
         /* Monitor table already created by switch_compat(). */
-        l4start = l4tab = __va(pagetable_get_paddr(v->arch.guest_table));
+        l4start_mfn = pagetable_get_mfn(v->arch.guest_table);
+        l4start = l4tab = map_domain_page(l4start_mfn);
         /* See public/xen.h on why the following is needed. */
         maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table;
-        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+        UNMAP_MAP_AND_ADVANCE(l3start_mfn, l3start, mpt_alloc);
     }
 
     l4tab += l4_table_offset(v_start);
@@ -636,14 +650,16 @@ int __init dom0_construct_pv(struct domain *d,
         if ( !((unsigned long)l1tab & (PAGE_SIZE-1)) )
         {
             maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l1_page_table;
-            l1start = l1tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+            UNMAP_MAP_AND_ADVANCE(l1start_mfn, l1start, mpt_alloc);
+            l1tab = l1start;
             clear_page(l1tab);
             if ( count == 0 )
                 l1tab += l1_table_offset(v_start);
             if ( !((unsigned long)l2tab & (PAGE_SIZE-1)) )
             {
                 maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l2_page_table;
-                l2start = l2tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+                UNMAP_MAP_AND_ADVANCE(l2start_mfn, l2start, mpt_alloc);
+                l2tab = l2start;
                 clear_page(l2tab);
                 if ( count == 0 )
                     l2tab += l2_table_offset(v_start);
@@ -653,19 +669,19 @@ int __init dom0_construct_pv(struct domain *d,
                     {
                         maddr_to_page(mpt_alloc)->u.inuse.type_info =
                             PGT_l3_page_table;
-                        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+                        UNMAP_MAP_AND_ADVANCE(l3start_mfn, l3start, mpt_alloc);
                     }
                     l3tab = l3start;
                     clear_page(l3tab);
                     if ( count == 0 )
                         l3tab += l3_table_offset(v_start);
-                    *l4tab = l4e_from_paddr(__pa(l3start), L4_PROT);
+                    *l4tab = l4e_from_mfn(l3start_mfn, L4_PROT);
                     l4tab++;
                 }
-                *l3tab = l3e_from_paddr(__pa(l2start), L3_PROT);
+                *l3tab = l3e_from_mfn(l2start_mfn, L3_PROT);
                 l3tab++;
             }
-            *l2tab = l2e_from_paddr(__pa(l1start), L2_PROT);
+            *l2tab = l2e_from_mfn(l1start_mfn, L2_PROT);
             l2tab++;
         }
         if ( count < initrd_pfn || count >= initrd_pfn + PFN_UP(initrd_len) )
@@ -692,9 +708,9 @@ int __init dom0_construct_pv(struct domain *d,
             if ( !l3e_get_intpte(*l3tab) )
             {
                 maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l2_page_table;
-                l2tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
-                clear_page(l2tab);
-                *l3tab = l3e_from_paddr(__pa(l2tab), L3_PROT);
+                UNMAP_MAP_AND_ADVANCE(l2start_mfn, l2start, mpt_alloc);
+                clear_page(l2start);
+                *l3tab = l3e_from_mfn(l2start_mfn, L3_PROT);
             }
             if ( i == 3 )
                 l3e_get_page(*l3tab)->u.inuse.type_info |= PGT_pae_xen_l2;
@@ -705,9 +721,17 @@ int __init dom0_construct_pv(struct domain *d,
         unmap_domain_page(l2t);
     }
 
+#undef UNMAP_MAP_AND_ADVANCE
+
+    UNMAP_DOMAIN_PAGE(l1start);
+    UNMAP_DOMAIN_PAGE(l2start);
+    UNMAP_DOMAIN_PAGE(l3start);
+
     /* Pages that are part of page tables must be read only. */
     mark_pv_pt_pages_rdonly(d, l4start, vpt_start, nr_pt_pages);
 
+    UNMAP_DOMAIN_PAGE(l4start);
+
     /* Mask all upcalls... */
     for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ )
         shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1;
@@ -869,8 +893,12 @@ int __init dom0_construct_pv(struct domain *d,
      * !CONFIG_VIDEO case so the logic here can be simplified.
      */
     if ( pv_shim )
+    {
+        l4start = map_domain_page(l4start_mfn);
         pv_shim_setup_dom(d, l4start, v_start, vxenstore_start, vconsole_start,
                           vphysmap_start, si);
+        UNMAP_DOMAIN_PAGE(l4start);
+    }
 
     if ( is_pv_32bit_domain(d) )
         xlat_start_info(si, pv_shim ? XLAT_start_info_console_domU
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:45:00 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG3H-0002wh-Sp; Thu, 30 Apr 2020 20:44:59 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG3G-0002w3-Ry
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:44:58 +0000
X-Inumbo-ID: 6f1a72e6-8b23-11ea-9aaf-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 6f1a72e6-8b23-11ea-9aaf-12813bfff9fa;
 Thu, 30 Apr 2020 20:44:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=aO60ViVBWEWDKEHryOEaMwDjalPzlWCpuejw56ZNsYY=; b=Dw8P8ANR0KLecQjeUa+KKEQz93
 ch1rbKMtixX5Z80yFeFqneXkG5PjZDPNCPUUdWDfhLW9277bgqsxg5/EBnV7KzRJfbtsD6/QPWNrY
 pN4b74Fx87xXCF1D/JO90ahcNTiVhBF0uAKWn3ow7BAqHu6WTlLRhUcTuOZwXe8irHVg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG36-0004Li-Vm; Thu, 30 Apr 2020 20:44:48 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG36-0005wj-MQ; Thu, 30 Apr 2020 20:44:48 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 08/16] x86: add Persistent Map (PMAP) infrastructure
Date: Thu, 30 Apr 2020 21:44:17 +0100
Message-Id: <e92da4ad6015b6089737fcccba3ec1d6424649a5.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

The basic idea is like Persistent Kernel Map (PKMAP) in linux. We
pre-populate all the relevant page tables before system is fully set
up.

It is needed to bootstrap map domain page infrastructure -- we need
some way to map pages to set up the mapcache without a direct map.

This infrastructure is not lock-protected therefore can only be used
before smpboot. After smpboot, mapcache has to be used.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/Makefile        |  1 +
 xen/arch/x86/pmap.c          | 87 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-x86/fixmap.h |  3 ++
 xen/include/asm-x86/pmap.h   | 10 +++++
 4 files changed, 101 insertions(+)
 create mode 100644 xen/arch/x86/pmap.c
 create mode 100644 xen/include/asm-x86/pmap.h

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 44137d919b..c8e565867b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -52,6 +52,7 @@ obj-y += pci.o
 obj-y += percpu.o
 obj-y += physdev.o x86_64/physdev.o
 obj-y += platform_hypercall.o x86_64/platform_hypercall.o
+obj-bin-y += pmap.init.o
 obj-y += psr.o
 obj-y += setup.o
 obj-y += shutdown.o
diff --git a/xen/arch/x86/pmap.c b/xen/arch/x86/pmap.c
new file mode 100644
index 0000000000..44d02ece89
--- /dev/null
+++ b/xen/arch/x86/pmap.c
@@ -0,0 +1,87 @@
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/spinlock.h>
+
+#include <asm/bitops.h>
+#include <asm/fixmap.h>
+#include <asm/flushtlb.h>
+
+/*
+ * Simple mapping infrastructure to map / unmap pages in fixed map.
+ * This is used to set up the page table for mapcache, which is used
+ * by map domain page infrastructure.
+ *
+ * This structure is not protected by any locks, so it must not be used after
+ * smp bring-up.
+ */
+
+/* Bitmap to track which slot is used */
+static unsigned long __initdata inuse;
+
+void *__init pmap_map(mfn_t mfn)
+{
+    unsigned long flags;
+    unsigned int idx;
+    void *linear = NULL;
+    enum fixed_addresses slot;
+    l1_pgentry_t *pl1e;
+
+    BUILD_BUG_ON(sizeof(inuse) * BITS_PER_LONG < NUM_FIX_PMAP);
+
+    ASSERT(system_state < SYS_STATE_smp_boot);
+
+    local_irq_save(flags);
+
+    idx = find_first_zero_bit(&inuse, NUM_FIX_PMAP);
+    if ( idx == NUM_FIX_PMAP )
+        panic("Out of PMAP slots\n");
+
+    __set_bit(idx, &inuse);
+
+    slot = idx + FIX_PMAP_BEGIN;
+    ASSERT(slot >= FIX_PMAP_BEGIN && slot <= FIX_PMAP_END);
+
+    linear = fix_to_virt(slot);
+    /*
+     * We cannot use set_fixmap() here. We use PMAP when there is no direct map,
+     * so map_pages_to_xen() called by set_fixmap() needs to map pages on
+     * demand, which then calls pmap() again, resulting in a loop. Modify the
+     * PTEs directly instead. The same is true for pmap_unmap().
+     */
+    pl1e = &l1_fixmap[l1_table_offset((unsigned long)linear)];
+    l1e_write_atomic(pl1e, l1e_from_mfn(mfn, PAGE_HYPERVISOR));
+
+    local_irq_restore(flags);
+
+    return linear;
+}
+
+void __init pmap_unmap(void *p)
+{
+    unsigned long flags;
+    unsigned int idx;
+    l1_pgentry_t *pl1e;
+    enum fixed_addresses slot = __virt_to_fix((unsigned long)p);
+
+    ASSERT(system_state < SYS_STATE_smp_boot);
+    ASSERT(slot >= FIX_PMAP_BEGIN && slot <= FIX_PMAP_END);
+
+    idx = slot - FIX_PMAP_BEGIN;
+    local_irq_save(flags);
+
+    __clear_bit(idx, &inuse);
+    pl1e = &l1_fixmap[l1_table_offset((unsigned long)p)];
+    l1e_write_atomic(pl1e, l1e_empty());
+    flush_tlb_one_local(p);
+
+    local_irq_restore(flags);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-x86/fixmap.h b/xen/include/asm-x86/fixmap.h
index 8330097a74..000f3b3375 100644
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -24,6 +24,7 @@
 #include <xen/kexec.h>
 #include <asm/apicdef.h>
 #include <asm/msi.h>
+#include <asm/pmap.h>
 #include <acpi/apei.h>
 
 /*
@@ -49,6 +50,8 @@ enum fixed_addresses {
     FIX_XEN_SHARED_INFO,
 #endif /* CONFIG_XEN_GUEST */
     /* Everything else should go further down. */
+    FIX_PMAP_BEGIN,
+    FIX_PMAP_END = FIX_PMAP_BEGIN + NUM_FIX_PMAP - 1,
     FIX_APIC_BASE,
     FIX_IO_APIC_BASE_0,
     FIX_IO_APIC_BASE_END = FIX_IO_APIC_BASE_0 + MAX_IO_APICS-1,
diff --git a/xen/include/asm-x86/pmap.h b/xen/include/asm-x86/pmap.h
new file mode 100644
index 0000000000..790cd71fb3
--- /dev/null
+++ b/xen/include/asm-x86/pmap.h
@@ -0,0 +1,10 @@
+#ifndef __X86_PMAP_H__
+#define __X86_PMAP_H__
+
+/* Large enough for mapping 5 levels of page tables with some headroom */
+#define NUM_FIX_PMAP 8
+
+void *pmap_map(mfn_t mfn);
+void pmap_unmap(void *p);
+
+#endif	/* __X86_PMAP_H__ */
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:45:02 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG3K-0002zB-HR; Thu, 30 Apr 2020 20:45:02 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG3J-0002yJ-F3
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:45:01 +0000
X-Inumbo-ID: 701ee8de-8b23-11ea-b07b-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 701ee8de-8b23-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 20:44:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=wgpps+8lZONEwS5fLM70YV18IA19BevUWAZAtXCq3Wg=; b=Tycjx5YewosH0ZNVQ/Ai+rio1p
 sRQC/0oEorEhrqHDpNUyb9p7BJo/des8e7rOv6UuFAfSP9+nIxTNe0FT2TZOw/7qlW1ZM/tx/tpCt
 dxmMkwXkZfljbUe+crVha8JlCQBA/jA1mlUxFRaEyFHFQVfEZLa/IxXcjmxxA+vDI6PE=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG38-0004Lq-Dy; Thu, 30 Apr 2020 20:44:50 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG38-0005wj-4w; Thu, 30 Apr 2020 20:44:50 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 09/16] x86: lift mapcache variable to the arch level
Date: Thu, 30 Apr 2020 21:44:18 +0100
Message-Id: <0794bccd94b7613dafab85ecc30a832229af7997.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Wei Liu <wei.liu2@citrix.com>

It is going to be needed by HVM and idle domain as well, because without
the direct map, both need a mapcache to map pages.

This only lifts the mapcache variable up. Whether we populate the
mapcache for a domain is unchanged in this patch.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Wang <wawei@amazon.de>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/domain.c        |  4 ++--
 xen/arch/x86/domain_page.c   | 22 ++++++++++------------
 xen/include/asm-x86/domain.h | 12 ++++++------
 3 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a4428190d5..e73f1efe85 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -634,6 +634,8 @@ int arch_domain_create(struct domain *d,
 
     psr_domain_init(d);
 
+    mapcache_domain_init(d);
+
     if ( is_hvm_domain(d) )
     {
         if ( (rc = hvm_domain_initialise(d)) != 0 )
@@ -641,8 +643,6 @@ int arch_domain_create(struct domain *d,
     }
     else if ( is_pv_domain(d) )
     {
-        mapcache_domain_init(d);
-
         if ( (rc = pv_domain_initialise(d)) != 0 )
             goto fail;
     }
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 3a244bb500..7b22e7c6ed 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -82,11 +82,11 @@ void *map_domain_page(mfn_t mfn)
 #endif
 
     v = mapcache_current_vcpu();
-    if ( !v || !is_pv_vcpu(v) )
+    if ( !v )
         return mfn_to_virt(mfn_x(mfn));
 
-    dcache = &v->domain->arch.pv.mapcache;
-    vcache = &v->arch.pv.mapcache;
+    dcache = &v->domain->arch.mapcache;
+    vcache = &v->arch.mapcache;
     if ( !dcache->inuse )
         return mfn_to_virt(mfn_x(mfn));
 
@@ -187,14 +187,14 @@ void unmap_domain_page(const void *ptr)
     ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END);
 
     v = mapcache_current_vcpu();
-    ASSERT(v && is_pv_vcpu(v));
+    ASSERT(v);
 
-    dcache = &v->domain->arch.pv.mapcache;
+    dcache = &v->domain->arch.mapcache;
     ASSERT(dcache->inuse);
 
     idx = PFN_DOWN(va - MAPCACHE_VIRT_START);
     mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx));
-    hashent = &v->arch.pv.mapcache.hash[MAPHASH_HASHFN(mfn)];
+    hashent = &v->arch.mapcache.hash[MAPHASH_HASHFN(mfn)];
 
     local_irq_save(flags);
 
@@ -233,11 +233,9 @@ void unmap_domain_page(const void *ptr)
 
 int mapcache_domain_init(struct domain *d)
 {
-    struct mapcache_domain *dcache = &d->arch.pv.mapcache;
+    struct mapcache_domain *dcache = &d->arch.mapcache;
     unsigned int bitmap_pages;
 
-    ASSERT(is_pv_domain(d));
-
 #ifdef NDEBUG
     if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
         return 0;
@@ -261,12 +259,12 @@ int mapcache_domain_init(struct domain *d)
 int mapcache_vcpu_init(struct vcpu *v)
 {
     struct domain *d = v->domain;
-    struct mapcache_domain *dcache = &d->arch.pv.mapcache;
+    struct mapcache_domain *dcache = &d->arch.mapcache;
     unsigned long i;
     unsigned int ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES;
     unsigned int nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long));
 
-    if ( !is_pv_vcpu(v) || !dcache->inuse )
+    if ( !dcache->inuse )
         return 0;
 
     if ( ents > dcache->entries )
@@ -293,7 +291,7 @@ int mapcache_vcpu_init(struct vcpu *v)
     BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES);
     for ( i = 0; i < MAPHASH_ENTRIES; i++ )
     {
-        struct vcpu_maphash_entry *hashent = &v->arch.pv.mapcache.hash[i];
+        struct vcpu_maphash_entry *hashent = &v->arch.mapcache.hash[i];
 
         hashent->mfn = ~0UL; /* never valid to map */
         hashent->idx = MAPHASHENT_NOTINUSE;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 5b6d909266..1cee04c0c5 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -271,9 +271,6 @@ struct pv_domain
     /* Mitigate L1TF with shadow/crashing? */
     bool check_l1tf;
 
-    /* map_domain_page() mapping cache. */
-    struct mapcache_domain mapcache;
-
     struct cpuidmasks *cpuidmasks;
 };
 
@@ -306,6 +303,9 @@ struct arch_domain
     uint32_t pci_cf8;
     uint8_t cmos_idx;
 
+    /* map_domain_page() mapping cache. */
+    struct mapcache_domain mapcache;
+
     union {
         struct pv_domain pv;
         struct hvm_domain hvm;
@@ -482,9 +482,6 @@ struct arch_domain
 
 struct pv_vcpu
 {
-    /* map_domain_page() mapping cache. */
-    struct mapcache_vcpu mapcache;
-
     unsigned int vgc_flags;
 
     struct trap_info *trap_ctxt;
@@ -567,6 +564,9 @@ struct arch_vcpu
 #define async_exception_state(t) async_exception_state[(t)-1]
     uint8_t async_exception_mask;
 
+    /* map_domain_page() mapping cache. */
+    struct mapcache_vcpu mapcache;
+
     /* Virtual Machine Extensions */
     union {
         struct pv_vcpu pv;
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:50:15 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG8K-0004PE-Je; Thu, 30 Apr 2020 20:50:12 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG8J-0004Ow-U7
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:50:11 +0000
X-Inumbo-ID: 2ed536a2-8b24-11ea-9ab3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2ed536a2-8b24-11ea-9ab3-12813bfff9fa;
 Thu, 30 Apr 2020 20:50:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=PcycubMAuSqGSuNs6t/y8u3H4ytKIm03X5Wiy+SUCcU=; b=ygXMYmWskqVSzW591ZTOFCGThF
 YklHwIBhupZhlHTHjsqn+y/Un9pUUSrRKv+c5C36KmMe7ZWmbp/jWMhmTbaM67vmZ0fDRJQhUJzy4
 8OZg8fxFJ0iFV3WJXsUQC8HKjLLm3NZTRLSm/3IaNEsxjuOWsFs74oiqKt9Pnb7Jk+cY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG8I-0004UV-Es; Thu, 30 Apr 2020 20:50:10 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG3B-0005wj-IK; Thu, 30 Apr 2020 20:44:53 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 11/16] x86: add a boot option to enable and disable the direct
 map
Date: Thu, 30 Apr 2020 21:44:20 +0100
Message-Id: <7360b59e8fd39796fee56430a437b20c948d08c2.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

Also add a helper function to retrieve it. Change arch_mfn_in_direct_map
to check this option before returning.

This is added as a boot command line option, not a Kconfig. We do not
produce different builds for EC2 so this is not introduced as a
compile-time configuration.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 docs/misc/xen-command-line.pandoc | 12 ++++++++++++
 xen/arch/x86/mm.c                 |  3 +++
 xen/arch/x86/setup.c              |  2 ++
 xen/include/asm-arm/mm.h          |  5 +++++
 xen/include/asm-x86/mm.h          | 17 ++++++++++++++++-
 5 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index ee12b0f53f..7027e3a15c 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -652,6 +652,18 @@ Specify the size of the console debug trace buffer. By specifying `cpu:`
 additionally a trace buffer of the specified size is allocated per cpu.
 The debug trace feature is only enabled in debugging builds of Xen.
 
+### directmap (x86)
+> `= <boolean>`
+
+> Default: `true`
+
+Enable or disable the direct map region in Xen.
+
+By default, Xen creates the direct map region which maps physical memory
+in that region. Setting this to no will remove the direct map, blocking
+exploits that leak secrets via speculative memory access in the direct
+map.
+
 ### dma_bits
 > `= <integer>`
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index b3530d2763..64da997764 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -162,6 +162,9 @@ l1_pgentry_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
 l1_pgentry_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
     l1_fixmap_x[L1_PAGETABLE_ENTRIES];
 
+bool __read_mostly opt_directmap = true;
+boolean_param("directmap", opt_directmap);
+
 paddr_t __read_mostly mem_hotplug;
 
 /* Frame table size in pages. */
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index faca8c9758..60fc4038be 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1282,6 +1282,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     if ( highmem_start )
         xenheap_max_mfn(PFN_DOWN(highmem_start - 1));
 
+    printk("Booting with directmap %s\n", arch_has_directmap() ? "on" : "off");
+
     /*
      * Walk every RAM region and map it in its entirety (on x86/64, at least)
      * and notify it to the boot allocator.
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 7df91280bc..e6fd934113 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -366,6 +366,11 @@ int arch_acquire_resource(struct domain *d, unsigned int type, unsigned int id,
     return -EOPNOTSUPP;
 }
 
+static inline bool arch_has_directmap(void)
+{
+    return true;
+}
+
 #endif /*  __ARCH_ARM_MM__ */
 /*
  * Local variables:
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index ef7a20ac7d..7ff99ee8e3 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -454,6 +454,8 @@ int check_descriptor(const struct domain *d, seg_desc_t *desc);
 
 extern paddr_t mem_hotplug;
 
+extern bool opt_directmap;
+
 /******************************************************************************
  * With shadow pagetables, the different kinds of address start
  * to get get confusing.
@@ -637,13 +639,26 @@ extern const char zero_page[];
 /* Build a 32bit PSE page table using 4MB pages. */
 void write_32bit_pse_identmap(uint32_t *l2);
 
+static inline bool arch_has_directmap(void)
+{
+    return opt_directmap;
+}
+
 /*
  * x86 maps part of physical memory via the directmap region.
  * Return whether the input MFN falls in that range.
+ *
+ * When boot command line sets directmap=no, we will not have a direct map at
+ * all so this will always return false.
  */
 static inline bool arch_mfn_in_directmap(unsigned long mfn)
 {
-    unsigned long eva = min(DIRECTMAP_VIRT_END, HYPERVISOR_VIRT_END);
+    unsigned long eva;
+
+    if ( !arch_has_directmap() )
+        return false;
+
+    eva = min(DIRECTMAP_VIRT_END, HYPERVISOR_VIRT_END);
 
     return mfn <= (virt_to_mfn(eva - 1) + 1);
 }
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:50:16 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG8K-0004P5-9n; Thu, 30 Apr 2020 20:50:12 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG8J-0004Ov-OR
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:50:11 +0000
X-Inumbo-ID: 2ee5217a-8b24-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 2ee5217a-8b24-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 20:50:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Uv/yzMUx1QdBCN124eu+OU2bGCwQI9wMhMOGicg+2lw=; b=DShHz1Nz/o6zRMx8Lqm66YrFlZ
 yXOu6yAXfPlYM+hbeb8Rxsx0m+4okLioSESpWgPDtPww7uMPO+3wQ11/iy2Cbkx3QnDyEZ6Yrbo3X
 dMAtlAquopm2dJcrZ8z8/eouK0P2bTEpTtZpP644hLZ/O5Ll/QLrkaSpXvq1T8kwaUnA=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG8I-0004Uf-Od; Thu, 30 Apr 2020 20:50:10 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG3H-0005wj-Pa; Thu, 30 Apr 2020 20:45:00 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 15/16] x86/setup: vmap heap nodes when they are outside the
 direct map
Date: Thu, 30 Apr 2020 21:44:24 +0100
Message-Id: <dfa5598b20c83ab496f33a7b0720f659d904cb50.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

When we do not have a direct map, arch_mfn_in_direct_map() will always
return false, thus init_node_heap() will allocate xenheap pages from an
existing node for the metadata of a new node. This means that the
metadata of a new node is in a different node, slowing down heap
allocation.

Since we now have early vmap, vmap the metadata locally in the new node.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/common/page_alloc.c | 40 ++++++++++++++++++++++++++++++++--------
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 1285fc5977..1e18b45caf 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -584,22 +584,46 @@ static unsigned long init_node_heap(int node, unsigned long mfn,
         needed = 0;
     }
     else if ( *use_tail && nr >= needed &&
-              arch_mfn_in_directmap(mfn + nr) &&
               (!xenheap_bits ||
                !((mfn + nr - 1) >> (xenheap_bits - PAGE_SHIFT))) )
     {
-        _heap[node] = mfn_to_virt(mfn + nr - needed);
-        avail[node] = mfn_to_virt(mfn + nr - 1) +
-                      PAGE_SIZE - sizeof(**avail) * NR_ZONES;
+        if ( arch_mfn_in_directmap(mfn + nr) )
+        {
+            _heap[node] = mfn_to_virt(mfn + nr - needed);
+            avail[node] = mfn_to_virt(mfn + nr - 1) +
+                          PAGE_SIZE - sizeof(**avail) * NR_ZONES;
+        }
+        else
+        {
+            mfn_t needed_start = _mfn(mfn + nr - needed);
+
+            _heap[node] = __vmap(&needed_start, needed, 1, 1, PAGE_HYPERVISOR,
+                                 VMAP_DEFAULT);
+            BUG_ON(!_heap[node]);
+            avail[node] = (void *)(_heap[node]) + (needed << PAGE_SHIFT) -
+                          sizeof(**avail) * NR_ZONES;
+        }
     }
     else if ( nr >= needed &&
-              arch_mfn_in_directmap(mfn + needed) &&
               (!xenheap_bits ||
                !((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
     {
-        _heap[node] = mfn_to_virt(mfn);
-        avail[node] = mfn_to_virt(mfn + needed - 1) +
-                      PAGE_SIZE - sizeof(**avail) * NR_ZONES;
+        if ( arch_mfn_in_directmap(mfn + needed) )
+        {
+            _heap[node] = mfn_to_virt(mfn);
+            avail[node] = mfn_to_virt(mfn + needed - 1) +
+                          PAGE_SIZE - sizeof(**avail) * NR_ZONES;
+        }
+        else
+        {
+            mfn_t needed_start = _mfn(mfn);
+
+            _heap[node] = __vmap(&needed_start, needed, 1, 1, PAGE_HYPERVISOR,
+                                 VMAP_DEFAULT);
+            BUG_ON(!_heap[node]);
+            avail[node] = (void *)(_heap[node]) + (needed << PAGE_SHIFT) -
+                          sizeof(**avail) * NR_ZONES;
+        }
         *use_tail = false;
     }
     else if ( get_order_from_bytes(sizeof(**_heap)) ==
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:50:18 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG8P-0004QP-VA; Thu, 30 Apr 2020 20:50:17 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG8O-0004Q7-SE
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:50:16 +0000
X-Inumbo-ID: 2ed536a3-8b24-11ea-9ab3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2ed536a3-8b24-11ea-9ab3-12813bfff9fa;
 Thu, 30 Apr 2020 20:50:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=3jn+1WoLnrWmwaD8Flpv3LUTCB5BEWlqT9Jy2nqV9e4=; b=NUlVPCW6rftBkpIbssTQnRUstn
 cCBO6ewSmywoum6FKCJ+/2dCwHa79TXlIKq6QdlJMjtGcIKwLgGhXQd3PHJh4EP6SxE++v+0SShBD
 3mY4ZiNRk5HVg8vdBzrirflwkF8xxyA3Eb2NsU2qu9F1qryOEgLRSieWxSo587W1LRKg=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG8I-0004UZ-KR; Thu, 30 Apr 2020 20:50:10 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG3J-0005wj-7Z; Thu, 30 Apr 2020 20:45:01 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 16/16] x86/setup: do not create valid mappings when
 directmap=no
Date: Thu, 30 Apr 2020 21:44:25 +0100
Message-Id: <6e03a111f564366ca4a5d145dde2cd46e757935b.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

Create empty mappings in the second e820 pass. Also, destroy existing
direct map mappings created in the first pass.

To make xenheap pages visible in guests, it is necessary to create empty
L3 tables in the direct map even when directmap=no, since guest cr3s
copy idle domain's L4 entries, which means they will share mappings in
the direct map if we pre-populate idle domain's L4 entries and L3
tables. A helper is introduced for this.

Also, after the direct map is actually gone, we need to stop updating
the direct map in update_xen_mappings().

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/mm.c    |  2 +-
 xen/arch/x86/setup.c | 74 +++++++++++++++++++++++++++++++++++++++-----
 2 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 64da997764..33b7e3a003 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -798,7 +798,7 @@ static int update_xen_mappings(unsigned long mfn, unsigned int cacheattr)
 
     if ( unlikely(alias) && cacheattr )
         err = map_pages_to_xen(xen_va, _mfn(mfn), 1, 0);
-    if ( !err )
+    if ( arch_has_directmap() && !err )
         err = map_pages_to_xen((unsigned long)mfn_to_virt(mfn), _mfn(mfn), 1,
                      PAGE_HYPERVISOR | cacheattr_to_pte_flags(cacheattr));
     if ( unlikely(alias) && !cacheattr && !err )
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index dbb2ac1c8f..13c37f435b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -684,6 +684,57 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
 /* How much of the directmap is prebuilt at compile time. */
 #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
 
+/*
+ * This either populates a valid direct map, or allocates empty L3 tables and
+ * creates the L4 entries for virtual address between [start, end) in the
+ * direct map depending on arch_has_directmap();
+ *
+ * When directmap=no, we still need to populate empty L3 tables in the
+ * direct map region. The reason is that on-demand xenheap mappings are
+ * created in the idle domain's page table but must be seen by
+ * everyone. Since all domains share the direct map L4 entries, they
+ * will share xenheap mappings if we pre-populate the L4 entries and L3
+ * tables in the direct map region for all RAM. We also rely on the fact
+ * that L3 tables are never freed.
+ */
+static void __init populate_directmap(uint64_t pstart, uint64_t pend,
+                                      unsigned int flags)
+{
+    unsigned long vstart = (unsigned long)__va(pstart);
+    unsigned long vend = (unsigned long)__va(pend);
+
+    if ( pstart >= pend )
+        return;
+
+    BUG_ON(vstart < DIRECTMAP_VIRT_START);
+    BUG_ON(vend > DIRECTMAP_VIRT_END);
+
+    if ( arch_has_directmap() )
+        /* Populate valid direct map. */
+        BUG_ON(map_pages_to_xen(vstart, maddr_to_mfn(pstart),
+                                PFN_DOWN(pend - pstart), flags));
+    else
+    {
+        /* Create empty L3 tables. */
+        unsigned long vaddr = vstart & ~((1UL << L4_PAGETABLE_SHIFT) - 1);
+
+        for ( ; vaddr < vend; vaddr += (1UL << L4_PAGETABLE_SHIFT) )
+        {
+            l4_pgentry_t *pl4e = &idle_pg_table[l4_table_offset(vaddr)];
+
+            if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) )
+            {
+                mfn_t mfn = alloc_boot_pages(1, 1);
+                void *v = map_domain_page(mfn);
+
+                clear_page(v);
+                UNMAP_DOMAIN_PAGE(v);
+                l4e_write(pl4e, l4e_from_mfn(mfn, __PAGE_HYPERVISOR));
+            }
+        }
+    }
+}
+
 void __init noreturn __start_xen(unsigned long mbi_p)
 {
     char *memmap_type = NULL;
@@ -1366,8 +1417,17 @@ void __init noreturn __start_xen(unsigned long mbi_p)
         map_e = min_t(uint64_t, e,
                       ARRAY_SIZE(l2_directmap) << L2_PAGETABLE_SHIFT);
 
-        /* Pass mapped memory to allocator /before/ creating new mappings. */
+        /*
+         * Pass mapped memory to allocator /before/ creating new mappings.
+         * The direct map for the bottom 4GiB has been populated in the first
+         * e820 pass. In the second pass, we make sure those existing mappings
+         * are destroyed when directmap=no.
+         */
         init_boot_pages(s, min(map_s, e));
+        if ( !arch_has_directmap() )
+            destroy_xen_mappings((unsigned long)__va(s),
+                                 (unsigned long)__va(min(map_s, e)));
+
         s = map_s;
         if ( s < map_e )
         {
@@ -1376,6 +1436,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
             map_s = (s + mask) & ~mask;
             map_e &= ~mask;
             init_boot_pages(map_s, map_e);
+            if ( !arch_has_directmap() )
+                destroy_xen_mappings((unsigned long)__va(map_s),
+                                     (unsigned long)__va(map_e));
         }
 
         if ( map_s > map_e )
@@ -1389,8 +1452,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
             if ( map_e < end )
             {
-                map_pages_to_xen((unsigned long)__va(map_e), maddr_to_mfn(map_e),
-                                 PFN_DOWN(end - map_e), PAGE_HYPERVISOR);
+                populate_directmap(map_e, end, PAGE_HYPERVISOR);
                 init_boot_pages(map_e, end);
                 map_e = end;
             }
@@ -1399,13 +1461,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
         {
             /* This range must not be passed to the boot allocator and
              * must also not be mapped with _PAGE_GLOBAL. */
-            map_pages_to_xen((unsigned long)__va(map_e), maddr_to_mfn(map_e),
-                             PFN_DOWN(e - map_e), __PAGE_HYPERVISOR_RW);
+            populate_directmap(map_e, e, __PAGE_HYPERVISOR_RW);
         }
         if ( s < map_s )
         {
-            map_pages_to_xen((unsigned long)__va(s), maddr_to_mfn(s),
-                             PFN_DOWN(map_s - s), PAGE_HYPERVISOR);
+            populate_directmap(s, map_s, PAGE_HYPERVISOR);
             init_boot_pages(s, map_s);
         }
     }
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:50:23 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG8V-0004SI-Aj; Thu, 30 Apr 2020 20:50:23 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG8T-0004Rl-SK
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:50:21 +0000
X-Inumbo-ID: 2e6e8f8a-8b24-11ea-9ab3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2e6e8f8a-8b24-11ea-9ab3-12813bfff9fa;
 Thu, 30 Apr 2020 20:50:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=oWkkTLJs5F+dmSX55OPdYYCmMvWzu4b2BjRHw0fEjkE=; b=TtOV/RvoLDyCPdZUmHtj1s0Jid
 vRyibSHL+ihp465M1yP98RBGRCnp5xgGzDAJYO3TqcqSYhu0+hO8dhtJmYYcQazwyIw3wkoGAzylc
 jm42BGa4sLwwe2Hfj5Gy8ugfTNFpxFeJxh3K9ZFk0DzD9OpmSJdmQziZ1l5qlaJyC9q4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG8I-0004Ub-MK; Thu, 30 Apr 2020 20:50:10 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG39-0005wj-JL; Thu, 30 Apr 2020 20:44:51 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 10/16] x86/mapcache: initialise the mapcache for the idle
 domain
Date: Thu, 30 Apr 2020 21:44:19 +0100
Message-Id: <17fd1408a5f9e3ff2ed1f8d7f4f68427448df417.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

In order to use the mapcache in the idle domain, we also have to
populate its page tables in the PERDOMAIN region, and we need to move
mapcache_domain_init() earlier in arch_domain_create().

Note, commit 'x86: lift mapcache variable to the arch level' has
initialised the mapcache for HVM domains. With this patch, PV, HVM,
idle domains now all initialise the mapcache.

Signed-off-by: Wei Wang <wawei@amazon.de>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/domain.c | 4 ++--
 xen/arch/x86/mm.c     | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index e73f1efe85..c7e90c50e6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -539,6 +539,8 @@ int arch_domain_create(struct domain *d,
 
     spin_lock_init(&d->arch.e820_lock);
 
+    mapcache_domain_init(d);
+
     /* Minimal initialisation for the idle domain. */
     if ( unlikely(is_idle_domain(d)) )
     {
@@ -634,8 +636,6 @@ int arch_domain_create(struct domain *d,
 
     psr_domain_init(d);
 
-    mapcache_domain_init(d);
-
     if ( is_hvm_domain(d) )
     {
         if ( (rc = hvm_domain_initialise(d)) != 0 )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a17ae0004a..b3530d2763 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5828,6 +5828,9 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
         l3tab = __map_domain_page(pg);
         clear_page(l3tab);
         d->arch.perdomain_l3_pg = pg;
+        if ( is_idle_domain(d) )
+            idle_pg_table[l4_table_offset(PERDOMAIN_VIRT_START)] =
+                l4e_from_page(pg, __PAGE_HYPERVISOR_RW);
         if ( !nr )
         {
             unmap_domain_page(l3tab);
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:50:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG8Z-0004Vq-Sn; Thu, 30 Apr 2020 20:50:27 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG8Y-0004VJ-Sb
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:50:26 +0000
X-Inumbo-ID: 2e6e8f89-8b24-11ea-9ab3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2e6e8f89-8b24-11ea-9ab3-12813bfff9fa;
 Thu, 30 Apr 2020 20:50:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=uiGyNUH2p33cZ+IUo5Oln93DkD9Vx7DyiuUT3pjDMT0=; b=aey+DHDqSODtkbq0t9Hwwo/d3g
 EP6M4/fDeLHgbGAz+AerEAn1WQ5DNbCAzIQQz0lmxW78Y5aSCThHx7v4Xvhq/TTlvKhO/ly8+KIo5
 GdSKM2A33MZigBhvfQoJ10nafkunwzZbG9KpaKSH6sfagQ3b73ZKT/PVzl7baGsWDFA8=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG8I-0004UX-I4; Thu, 30 Apr 2020 20:50:10 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG3E-0005wj-LT; Thu, 30 Apr 2020 20:44:56 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 13/16] xen/page_alloc: add a path for xenheap when there is no
 direct map
Date: Thu, 30 Apr 2020 21:44:22 +0100
Message-Id: <32ae7c14babf7e78b60febb53095a74c5e865456.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, julien@xen.org,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

When there is not an always-mapped direct map, xenheap allocations need
to be mapped and unmapped on-demand.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/common/page_alloc.c | 45 ++++++++++++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 10b7aeca48..1285fc5977 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2143,6 +2143,7 @@ void init_xenheap_pages(paddr_t ps, paddr_t pe)
 void *alloc_xenheap_pages(unsigned int order, unsigned int memflags)
 {
     struct page_info *pg;
+    void *ret;
 
     ASSERT(!in_irq());
 
@@ -2151,14 +2152,27 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags)
     if ( unlikely(pg == NULL) )
         return NULL;
 
-    memguard_unguard_range(page_to_virt(pg), 1 << (order + PAGE_SHIFT));
+    ret = page_to_virt(pg);
 
-    return page_to_virt(pg);
+    if ( !arch_has_directmap() &&
+         map_pages_to_xen((unsigned long)ret, page_to_mfn(pg), 1UL << order,
+                          PAGE_HYPERVISOR) )
+        {
+            /* Failed to map xenheap pages. */
+            free_heap_pages(pg, order, false);
+            return NULL;
+        }
+
+    memguard_unguard_range(ret, 1 << (order + PAGE_SHIFT));
+
+    return ret;
 }
 
 
 void free_xenheap_pages(void *v, unsigned int order)
 {
+    unsigned long va = (unsigned long)v & PAGE_MASK;
+
     ASSERT(!in_irq());
 
     if ( v == NULL )
@@ -2166,6 +2180,12 @@ void free_xenheap_pages(void *v, unsigned int order)
 
     memguard_guard_range(v, 1 << (order + PAGE_SHIFT));
 
+    if ( !arch_has_directmap() &&
+         destroy_xen_mappings(va, va + (1UL << (order + PAGE_SHIFT))) )
+        dprintk(XENLOG_WARNING,
+                "Error while destroying xenheap mappings at %p, order %u\n",
+                v, order)
+
     free_heap_pages(virt_to_page(v), order, false);
 }
 
@@ -2189,6 +2209,7 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags)
 {
     struct page_info *pg;
     unsigned int i;
+    void *ret;
 
     ASSERT(!in_irq());
 
@@ -2201,16 +2222,28 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags)
     if ( unlikely(pg == NULL) )
         return NULL;
 
+    ret = page_to_virt(pg);
+
+    if ( !arch_has_directmap() &&
+         map_pages_to_xen((unsigned long)ret, page_to_mfn(pg), 1UL << order,
+                          PAGE_HYPERVISOR) )
+        {
+            /* Failed to map xenheap pages. */
+            free_domheap_pages(pg, order);
+            return NULL;
+        }
+
     for ( i = 0; i < (1u << order); i++ )
         pg[i].count_info |= PGC_xen_heap;
 
-    return page_to_virt(pg);
+    return ret;
 }
 
 void free_xenheap_pages(void *v, unsigned int order)
 {
     struct page_info *pg;
     unsigned int i;
+    unsigned long va = (unsigned long)v & PAGE_MASK;
 
     ASSERT(!in_irq());
 
@@ -2222,6 +2255,12 @@ void free_xenheap_pages(void *v, unsigned int order)
     for ( i = 0; i < (1u << order); i++ )
         pg[i].count_info &= ~PGC_xen_heap;
 
+    if ( !arch_has_directmap() &&
+         destroy_xen_mappings(va, va + (1UL << (order + PAGE_SHIFT))) )
+        dprintk(XENLOG_WARNING,
+                "Error while destroying xenheap mappings at %p, order %u\n",
+                v, order);
+
     free_heap_pages(pg, order, true);
 }
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:50:33 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG8f-0004Z0-8q; Thu, 30 Apr 2020 20:50:33 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG8d-0004YD-Sn
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:50:31 +0000
X-Inumbo-ID: 2ef3fdc6-8b24-11ea-9ab3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2ef3fdc6-8b24-11ea-9ab3-12813bfff9fa;
 Thu, 30 Apr 2020 20:50:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Pf2FpaoK+GE72TCueex6j/niFJJvks21euODf44DpKQ=; b=myk0BmGzVF8fak/lksv7yEF7pT
 Mp4P90HlVzy+aldv4qpMsqb3GS79SKDnwbvhBvYs9haauxpfTXMD/J+xFHgXBS95YqVnglhAUQl0I
 lHqbeROnHMkm1cgsVEMu1bymFqhvS+dfVuYXNAgcyzdqOPhLSnvtQBDSsysu/+0vsqJ4=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG8I-0004Uh-QR; Thu, 30 Apr 2020 20:50:10 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG3C-0005wj-Vj; Thu, 30 Apr 2020 20:44:55 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 12/16] x86/domain_page: remove the fast paths when mfn is not
 in the directmap
Date: Thu, 30 Apr 2020 21:44:21 +0100
Message-Id: <72c1d30ea95756ff6c8e14b084d7dd2e74b83043.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

When mfn is not in direct map, never use mfn_to_virt for any mappings.

We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with
arch_mfn_in_direct_map(mfn) because these two are equivalent. The
extra comparison in arch_mfn_in_direct_map() looks different but because
DIRECTMAP_VIRT_END is always higher, it does not make any difference.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/domain_page.c | 33 ++++++++++++++++++++++++---------
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 7b22e7c6ed..fc705f056e 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -14,8 +14,10 @@
 #include <xen/sched.h>
 #include <xen/vmap.h>
 #include <asm/current.h>
+#include <asm/fixmap.h>
 #include <asm/flushtlb.h>
 #include <asm/hardirq.h>
+#include <asm/pmap.h>
 #include <asm/setup.h>
 
 static DEFINE_PER_CPU(struct vcpu *, override);
@@ -35,10 +37,11 @@ static inline struct vcpu *mapcache_current_vcpu(void)
     /*
      * When using efi runtime page tables, we have the equivalent of the idle
      * domain's page tables but current may point at another domain's VCPU.
-     * Return NULL as though current is not properly set up yet.
+     * Return the idle domains's vcpu on that core because the efi per-domain
+     * region (where the mapcache is) is in-sync with the idle domain.
      */
     if ( efi_rs_using_pgtables() )
-        return NULL;
+        return idle_vcpu[smp_processor_id()];
 
     /*
      * If guest_table is NULL, and we are running a paravirtualised guest,
@@ -77,18 +80,24 @@ void *map_domain_page(mfn_t mfn)
     struct vcpu_maphash_entry *hashent;
 
 #ifdef NDEBUG
-    if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
+    if ( arch_mfn_in_directmap(mfn_x(mfn)) )
         return mfn_to_virt(mfn_x(mfn));
 #endif
 
     v = mapcache_current_vcpu();
-    if ( !v )
-        return mfn_to_virt(mfn_x(mfn));
+    if ( !v || !v->domain->arch.mapcache.inuse )
+    {
+        if ( arch_mfn_in_directmap(mfn_x(mfn)) )
+            return mfn_to_virt(mfn_x(mfn));
+        else
+        {
+            BUG_ON(system_state >= SYS_STATE_smp_boot);
+            return pmap_map(mfn);
+        }
+    }
 
     dcache = &v->domain->arch.mapcache;
     vcache = &v->arch.mapcache;
-    if ( !dcache->inuse )
-        return mfn_to_virt(mfn_x(mfn));
 
     perfc_incr(map_domain_page_count);
 
@@ -184,6 +193,12 @@ void unmap_domain_page(const void *ptr)
     if ( va >= DIRECTMAP_VIRT_START )
         return;
 
+    if ( va >= FIXADDR_START && va < FIXADDR_TOP )
+    {
+        pmap_unmap((void *)ptr);
+        return;
+    }
+
     ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END);
 
     v = mapcache_current_vcpu();
@@ -237,7 +252,7 @@ int mapcache_domain_init(struct domain *d)
     unsigned int bitmap_pages;
 
 #ifdef NDEBUG
-    if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
+    if ( !mem_hotplug && arch_mfn_in_directmap(max_page) )
         return 0;
 #endif
 
@@ -308,7 +323,7 @@ void *map_domain_page_global(mfn_t mfn)
             local_irq_is_enabled()));
 
 #ifdef NDEBUG
-    if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
+    if ( arch_mfn_in_directmap(mfn_x(mfn)) )
         return mfn_to_virt(mfn_x(mfn));
 #endif
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:50:37 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:50:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUG8j-0004bx-KG; Thu, 30 Apr 2020 20:50:37 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=fL57=6O=xen.org=hx242@srs-us1.protection.inumbo.net>)
 id 1jUG8i-0004bO-Sh
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 20:50:36 +0000
X-Inumbo-ID: 2dcb9211-8b24-11ea-9ab3-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 2dcb9211-8b24-11ea-9ab3-12813bfff9fa;
 Thu, 30 Apr 2020 20:50:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
 s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:
 Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tF+dQ9SLZTmEavdmofAbgYKyBZJqPPcUUiyb5AWHxN8=; b=HZ3Q9E4S5yiVy8k/Mfc9UAUXsi
 O1sw7XgIi6nF741qocRN/95JoYovNWdGd3bBrj+aNrItkexAW57YfkTs4HkGKyEaNkKkFFYXdfVhU
 eMd1JKLU1yKKp4Z4KPUjwrS/sMnihHtyOyD16eQyYgRoJFaTzFqR1qwJ94oMjm7IhaEY=;
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hx242@xen.org>)
 id 1jUG8I-0004Un-SN; Thu, 30 Apr 2020 20:50:10 +0000
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=u1bbd043a57dd5a.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89)
 (envelope-from <hx242@xen.org>)
 id 1jUG3G-0005wj-3A; Thu, 30 Apr 2020 20:44:58 +0000
From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 14/16] x86/setup: leave early boot slightly earlier
Date: Thu, 30 Apr 2020 21:44:23 +0100
Message-Id: <446c0b3b1811574d155cb84827e4fc64e3425413.1588278317.git.hongyxia@amazon.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
References: <cover.1588278317.git.hongyxia@amazon.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, julien@xen.org,
 Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

From: Hongyan Xia <hongyxia@amazon.com>

When we do not have a direct map, memory for metadata of heap nodes in
init_node_heap() is allocated from xenheap, which needs to be mapped and
unmapped on demand. However, we cannot just take memory from the boot
allocator to create the PTEs while we are passing memory to the heap
allocator.

To solve this race, we leave early boot slightly sooner so that Xen PTE
pages are allocated from the heap instead of the boot allocator. We can
do this because the metadata for the 1st node is statically allocated,
and by the time we need memory to create mappings for the 2nd node, we
already have enough memory in the heap allocator in the 1st node.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
 xen/arch/x86/setup.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 60fc4038be..dbb2ac1c8f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1507,6 +1507,22 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
     numa_initmem_init(0, raw_max_page);
 
+    /*
+     * When we do not have a direct map, memory for metadata of heap nodes in
+     * init_node_heap() is allocated from xenheap, which needs to be mapped and
+     * unmapped on demand. However, we cannot just take memory from the boot
+     * allocator to create the PTEs while we are passing memory to the heap
+     * allocator during end_boot_allocator().
+     *
+     * To solve this race, we need to leave early boot before
+     * end_boot_allocator() so that Xen PTE pages are allocated from the heap
+     * instead of the boot allocator. We can do this because the metadata for
+     * the 1st node is statically allocated, and by the time we need memory to
+     * create mappings for the 2nd node, we already have enough memory in the
+     * heap allocator in the 1st node.
+     */
+    system_state = SYS_STATE_boot;
+
     if ( max_page - 1 > virt_to_mfn(HYPERVISOR_VIRT_END - 1) )
     {
         unsigned long limit = virt_to_mfn(HYPERVISOR_VIRT_END - 1);
@@ -1536,8 +1552,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     else
         end_boot_allocator();
 
-    system_state = SYS_STATE_boot;
-
     console_init_ring();
     vesa_init();
 
-- 
2.24.1.AMZN



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 20:53:57 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 20:53:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUGBx-000571-4y; Thu, 30 Apr 2020 20:53:57 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=RHFy=6O=gmail.com=jandryuk@srs-us1.protection.inumbo.net>)
 id 1jUGBw-00056q-Bs
 for xen-devel@lists.xen.org; Thu, 30 Apr 2020 20:53:56 +0000
X-Inumbo-ID: b4446862-8b24-11ea-ae69-bc764e2007e4
Received: from mail-lf1-x141.google.com (unknown [2a00:1450:4864:20::141])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id b4446862-8b24-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 20:53:55 +0000 (UTC)
Received: by mail-lf1-x141.google.com with SMTP id j14so2408586lfg.9
 for <xen-devel@lists.xen.org>; Thu, 30 Apr 2020 13:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=SKC1Ubs64feoGoEAHeoVOPMHU64p71MzA+JDLl+lbLc=;
 b=J/fSsYMM8my3Td7IWI5u/N4Ujzb0AsdFYbPi1ODROzWXiaQwcM0d00f+b7pNZCzux5
 WEHz7QtJNQR8CnlDZ+HG19oy/bmwE33IcvyQcDrS6T3bIVSGUql2v+N4cJAqTLZjTc+o
 E0y3LV/9qRHC3MZ2WLDF0vEQ7ld1/RiD4uJKz33oPVb0pihyzPnBg/PVIpuJWvA1/k59
 AmcYQjaclbWrgmSbzuzRs9kVVs2xJHBl7A6kNjPUEW+lNFjW8JWjfpNVySZhyREBMESF
 Zo78AE8Pl8LNTu4HPOhC9Cvi2vux5ml+1+055qlslYL68yNapineAKttKyoCI+RzVXi+
 s/wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=SKC1Ubs64feoGoEAHeoVOPMHU64p71MzA+JDLl+lbLc=;
 b=Xa2KI90tW+CwYOoxtfV5uQRcLV0ASIir/Ozstw4MzHGrEQzn5AZww/KjWac2HD9hGk
 dt9myBP8ioOuOC092oMMOSpXNpAPgfbkCZRgQ3pP4OtXV04cOHEW+WR0+yORd5Ex9f5O
 MtPLtxld1dyxqO3mgOXlh/nQtLHiElqjLj7cUzJ1nS3Fmsnm02cQDPT8sMKT+b8O6Yh3
 kQ9Fxo3x8vOmOFAu1vMhs2hEy1mcXR2WTsX6jBwYDiMd9UTPp3oFif54t0vCKiq3erU/
 riUWg69pNe+Qla3qkN5vv0x8k2fdsAGtfsgNIPzpsXKENBs3GInP/aDj5riMXjDVQscn
 2bXw==
X-Gm-Message-State: AGi0PubeXrfkPNB55burOP130X/MOP13Mu1ncA+/IoPhihKbQF9YZ5kB
 ARV7wAERlQI49vejcCsxmS1tax7+ci8VCqqQLuA=
X-Google-Smtp-Source: APiQypK8ZUgAbkay/BA3dA1dtaANoskPU01mbUAjWFCgZNDTK5Lxny3armTJO92C2IRDKe4amick9pAFWODInFAfw3E=
X-Received: by 2002:a19:3848:: with SMTP id d8mr342982lfj.44.1588280034139;
 Thu, 30 Apr 2020 13:53:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAOCxVi0s5X+=Hug2_M-AyXvYpiwqfkf7G2Y66kp44MQ-xgO+KA@mail.gmail.com>
 <e92bb8ab-3dd2-bb19-d524-d78279f9508a@citrix.com>
 <CAOCxVi1PWM_9t03f=_qn0PXkKB1gN4504h+ijMpwqGU9VpR48g@mail.gmail.com>
 <CAOCxVi0=iKzeJ0gfZ8XoMTXYrZaHbok=F30pw1rNdsUhkQcXjw@mail.gmail.com>
In-Reply-To: <CAOCxVi0=iKzeJ0gfZ8XoMTXYrZaHbok=F30pw1rNdsUhkQcXjw@mail.gmail.com>
From: Jason Andryuk <jandryuk@gmail.com>
Date: Thu, 30 Apr 2020 16:53:42 -0400
Message-ID: <CAKf6xptZyZPGL34SKMcEyMyHzqvMpqoY4fdMFaabUb45dnC4bg@mail.gmail.com>
Subject: Re: Xen Compilation Error on Ubuntu 20.04
To: Ayush Dosaj <ayushdosaj2313@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 4:18 AM Ayush Dosaj <ayushdosaj2313@gmail.com> wrote:
>
> Hi Andrew, Xen Development team.
>
> I compiled and installed Xen by appending -fcf-protection=none to CFLAGS on Ubuntu 20.04 but it still crashes on startup.

Ayush, try the patch below.  EMBEDDED_EXTRA_CFLAGS ensures it is set
down in xen/arch/x86/boot/build32.mk

-Jason

diff --git a/Config.mk b/Config.mk
index 0f303c79b2..efb3d42bc4 100644
--- a/Config.mk
+++ b/Config.mk
@@ -205,6 +205,7 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))

 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
+EMBEDDED_EXTRA_CFLAGS += -fcf-protection=none

 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 4b7ab78467..c3cbae69d2 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -69,6 +69,7 @@ CFLAGS += -mno-sse $(call cc-option,$(CC),-mskip-rax-setup)
 ifeq ($(CONFIG_INDIRECT_THUNK),y)
 CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register
 CFLAGS += -fno-jump-tables
+$(call cc-option-add,CFLAGS,CC,-fcf-protection=none)
 endif

 # If supported by the compiler, reduce stack alignment to 8 bytes. But allow


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 21:39:19 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 21:39:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUGtj-000070-FI; Thu, 30 Apr 2020 21:39:11 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=aBcg=6O=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jUGth-00006r-VC
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 21:39:10 +0000
X-Inumbo-ID: 0645e338-8b2b-11ea-9887-bc764e2007e4
Received: from mail-qk1-x743.google.com (unknown [2607:f8b0:4864:20::743])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 0645e338-8b2b-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 21:39:09 +0000 (UTC)
Received: by mail-qk1-x743.google.com with SMTP id l78so7441700qke.7
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 14:39:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id;
 bh=5UcO7ftMOxojj4/6mDmCxipEpM1pYLxaKQc7yqp9D/I=;
 b=p/VLGs/cRdygdHN5Fb1gw+k2cICdymTxAWECnen88fnYR7Mvxcr0zuumiIkXdPWjqp
 T+tlb85kBoEw/l8GbYt6jmLR96m3b5HTJCr+26b9YfqDjrQfmS2KMGrsgcjKaQX1E54I
 BaRxOJdRp5Mdjeed7ApYeirJNdn4OAegPpIY9gdMz/df7W0kzrOBqKNOxFGzsKZtnK0O
 0tXHhEkP3MFNQun7/Gzp8BPp3o1Z0EHNvzXCN61o2TEqBDEr4aMKVBg+A1A9PvG5D2vS
 d01ITIB+UR3RrdvQiajS3lS3UfBvDvaety6+mu+iEbnT5ALdBmp9+XI21d5hEWUXFkUP
 gfvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id;
 bh=5UcO7ftMOxojj4/6mDmCxipEpM1pYLxaKQc7yqp9D/I=;
 b=lKec+vcO6Jgs5OO+cGY40Mx9WknT6B/ciSxnjz7ZnbtE+lEE2MiuJ4g3z9i9PEW+U4
 XH1zMBN07l8+Bzv6GU8YpIssNRa8IVEuUtw44/gMYm8TUesnQm6cPjfAvMtKbTfYjm9i
 LQV4E+J6PyixSzQlZZ7c3tWRGrgA3odCpx+C+j/B+FQZQYvsts6lFvSJcY+lPQyllsPY
 qh852LPp/llWiS4DEGOzZj166ujwbJUy5laPAtuwHqxX3UuFj7Rj2U/5JnejBp70Er05
 vG+4WirBEoAg6qV5m17jyoQNfpXDzuHS61ZI7BzbSMV9Lq4S/gWYYis1fQwycejXfKlh
 Fhdg==
X-Gm-Message-State: AGi0PuaJJNCCWCg45dNBKsgagw8O1d6vimjm0au90FYQKptbH6HdDM+H
 CRHSqMBVdFW7KPf+YBCLEMABNzklQMM=
X-Google-Smtp-Source: APiQypIXBU1y49nmsFnluRuRdm2xyir7c3+rVPs6c9L098yKxlyWGVAKl6zgyNAtqylcL1ORPQj/Aw==
X-Received: by 2002:a37:de16:: with SMTP id h22mr555115qkj.195.1588282748557; 
 Thu, 30 Apr 2020 14:39:08 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id b42sm922476qta.29.2020.04.30.14.39.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 30 Apr 2020 14:39:07 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/3] initialize xenlight go module
Date: Thu, 30 Apr 2020 17:38:58 -0400
Message-Id: <cover.1588282027.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Nick Rosbrook <rosbrookn@ainfosec.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

These patches setup an initial Go module for the xenlight package. The
go code is tracked again, since the module is defined in xen.git as
xenbits.xen.org/git-http/xen.git/tools/golang/xenlight. The final patch
adds a README and LICENSE to tools/golang/xenlight so that the package
will show up properly on pkg.go.dev and be available via the module
proxy at proxy.golang.org.

Nick Rosbrook (3):
  golang/xenlight: re-track generated go code
  golang/xenlight: init xenlight go module
  golang/xenlight: add necessary module/package documentation

 .gitignore                           |    3 -
 .hgignore                            |    2 -
 tools/Rules.mk                       |    2 +-
 tools/golang/xenlight/LICENSE        |  416 +++
 tools/golang/xenlight/Makefile       |    1 -
 tools/golang/xenlight/README.md      |   17 +
 tools/golang/xenlight/go.mod         |    1 +
 tools/golang/xenlight/helpers.gen.go | 4728 ++++++++++++++++++++++++++
 tools/golang/xenlight/types.gen.go   | 1226 +++++++
 tools/golang/xenlight/xenlight.go    |    2 +
 10 files changed, 6391 insertions(+), 7 deletions(-)
 create mode 100644 tools/golang/xenlight/LICENSE
 create mode 100644 tools/golang/xenlight/README.md
 create mode 100644 tools/golang/xenlight/go.mod
 create mode 100644 tools/golang/xenlight/helpers.gen.go
 create mode 100644 tools/golang/xenlight/types.gen.go

-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 21:39:22 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 21:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUGtn-00007M-Nc; Thu, 30 Apr 2020 21:39:15 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=aBcg=6O=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jUGtm-00007E-S5
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 21:39:14 +0000
X-Inumbo-ID: 087b2726-8b2b-11ea-b9cf-bc764e2007e4
Received: from mail-qt1-x843.google.com (unknown [2607:f8b0:4864:20::843])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 087b2726-8b2b-11ea-b9cf-bc764e2007e4;
 Thu, 30 Apr 2020 21:39:13 +0000 (UTC)
Received: by mail-qt1-x843.google.com with SMTP id i68so6432621qtb.5
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 14:39:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=I954QwFC86mA/2Znauymh9Jmb/Y7p8bIrTzd0TFH8NM=;
 b=XbbyGacKjyvNURl/ncRIru9ZGYao49z4dohVLC1aHGAeduvo6CzmnG/ntrG7YopudI
 8rbos926ZBoUzVgjPylKAwiIKoruRfOG7h//9FNBuuzwqlL3HnYDnd4xhBuweRj0aafC
 uwSCA7bkn0r0CRJVyqnlPirdwb+BHG2kddNs3LXGK2L2eYebtLSk33qzPba1IjqJxOYW
 aImZFm9rZ/6kO3IoyZJx7BdnvbBg66F9l4iTx+9PQ/JFmHHhkdjxipBHCGndIiqLGx6n
 6g4+g1usaJC/sLA+MJdjJwLOcmk4LSiog3Vu3wU/LEqkPlOcbh4tvL7QRQ5aAmWD25u7
 78kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=I954QwFC86mA/2Znauymh9Jmb/Y7p8bIrTzd0TFH8NM=;
 b=r1tQD3M3xbUtKbqgoNi9LMNy7LMTSSalXetX1kkHxgaES5ELnZCVGKiG+zc/FYInFK
 3JciL5uASeGVYAOHFknClSvO3gW9/cdHFZLIDQjylARtOIm+8S9qW5hfqHe6k7R+Kz/I
 JPRhw2EI88PgXMqow7Cjgdll78dyLfJiK/uv/vKnzTLXLHfB50/Dwr1C8c/SHwydJwCE
 Pqqgi5RmpylthVF5TgpOpC2nt+uGjZAoKfJZTzM6MC9bu2OixtM+Y32Pu3eNFRfAGchg
 gJQs/b9O+Z8nelIXHYsWCBl3Sg6QzEP28C1h2mURjaODHGTFIgjDQUya4JlfDVchgivF
 FUXA==
X-Gm-Message-State: AGi0PuZuJLhGoWn9jwRjgkoKDMIS89XAYnzwoucN2N110iNC3Zbz3guE
 8Dh9i6dkBkm4tE0bqNSJ7j3FWLfHllE=
X-Google-Smtp-Source: APiQypL+g3eOLzNH+E0UQc0KWvgHB9CM+ao2AttIYu+J1yA+crrD8AsFolbgNVZ4lsFVqZskoIXYQQ==
X-Received: by 2002:aed:3e8f:: with SMTP id n15mr607453qtf.241.1588282752123; 
 Thu, 30 Apr 2020 14:39:12 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id b42sm922476qta.29.2020.04.30.14.39.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 30 Apr 2020 14:39:11 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 2/3] golang/xenlight: init xenlight go module
Date: Thu, 30 Apr 2020 17:39:00 -0400
Message-Id: <c38afab85d9fc005edade229896008a4ad5a1929.1588282027.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588282027.git.rosbrookn@ainfosec.com>
References: <cover.1588282027.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1588282027.git.rosbrookn@ainfosec.com>
References: <cover.1588282027.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Initialize the xenlight Go module using the xenbits git-http URL,
xenbits.xen.org/git-http/xen.git/tools/golang/xenlight, and update the
XEN_GOCODE_URL variable in tools/Rules.mk accordingly.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 tools/Rules.mk               | 2 +-
 tools/golang/xenlight/go.mod | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 tools/golang/xenlight/go.mod

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 5b8cf748ad..ca33cc7b31 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -36,7 +36,7 @@ debug ?= y
 debug_symbols ?= $(debug)
 
 XEN_GOPATH        = $(XEN_ROOT)/tools/golang
-XEN_GOCODE_URL    = golang.xenproject.org
+XEN_GOCODE_URL    = xenbits.xen.org/git-http/xen.git/tools/golang
 
 ifeq ($(debug_symbols),y)
 CFLAGS += -g3
diff --git a/tools/golang/xenlight/go.mod b/tools/golang/xenlight/go.mod
new file mode 100644
index 0000000000..232d102153
--- /dev/null
+++ b/tools/golang/xenlight/go.mod
@@ -0,0 +1 @@
+module xenbits.xen.org/git-http/xen.git/tools/golang/xenlight
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 21:39:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 21:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUGtz-00009y-3r; Thu, 30 Apr 2020 21:39:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=aBcg=6O=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jUGtw-000093-W7
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 21:39:25 +0000
X-Inumbo-ID: 09c8fe46-8b2b-11ea-b07b-bc764e2007e4
Received: from mail-qt1-x835.google.com (unknown [2607:f8b0:4864:20::835])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 09c8fe46-8b2b-11ea-b07b-bc764e2007e4;
 Thu, 30 Apr 2020 21:39:15 +0000 (UTC)
Received: by mail-qt1-x835.google.com with SMTP id h26so6414019qtu.8
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 14:39:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=AncuIrtqWr0M0ryAYuV0xz3NF3lZ3Hxa1ZpzdFuZ2U4=;
 b=dZOtPdCaJ61/VEcq2spuUoOjceHhvF/sSC1VKBxuVBV/Mgv7CDP91fA5ukBtk4EFSU
 dD4fa3iC0qqjYzRPPiLZXxFwlPqEMHxk5e9yHB370Lt7gLUpTcpeX6y18A8e+06LUA6h
 yWiHKv+M05qj8/3ujRSE85cDzDWkObMoEEFNmlqjoS0kMiCVPETH92kuFyt2kVFkbPoH
 1MlMcumqQ4ncUfmz/pJLeT8NsQS4IS0KyHZadSIjxSI4Kl61hZPP1Biw+VKcFST1V7ec
 ufMJeZy7t5pdifOL60Uf5VwVfoEWVsIOAb0iGMXxZmykaUnOoBZumtju8F52kOIhSF4w
 WWrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=AncuIrtqWr0M0ryAYuV0xz3NF3lZ3Hxa1ZpzdFuZ2U4=;
 b=fx+qUu9l3fwHMcAxxvl5lvzMUuP5HKoRVzdY4nsy3mOqToa30/f2Inu4JPYvAyXGEy
 EjsiUctu4Me0eZ9vo1StroVIp2424QKt0x36iGdVDTDuL6FPJAa7HrsHa5HQ3+WY1/Lv
 G3HtyUGJn2a3pJxsEd+8O5WvcnlOHAhsL663Ptu7OW+82gTzKhGDnNKwNhgw63F1I9VK
 lBa5oiZwBcUluF9+HpVNHnEuYueTmwwAuevwqeuW0mMcYhVydl47n2+aY4CVMZg4AaC4
 WH6CRs876AbXDpZksrQMrOyijDaFe9cy0Yp2P5n4V2TYByQyAW0mbd3rM9C/lAe8uCa4
 /h8w==
X-Gm-Message-State: AGi0PuYssvkh6p47b0Ikva/3ToqHPPyzn6fVZb5WjcuSHjuWdN02GSrr
 qZHZ6tbGoUMSRW/SEjy4LLlwoUopkB8=
X-Google-Smtp-Source: APiQypK8FRqyUqtl+x0hDekMskLrXFlcPjGA/R2OXUs6k7+5nDqtncXsNCaCEle9EhlMYFOVmnyH4g==
X-Received: by 2002:ac8:32a4:: with SMTP id z33mr586119qta.363.1588282753569; 
 Thu, 30 Apr 2020 14:39:13 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id b42sm922476qta.29.2020.04.30.14.39.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 30 Apr 2020 14:39:12 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 3/3] golang/xenlight: add necessary module/package
 documentation
Date: Thu, 30 Apr 2020 17:39:01 -0400
Message-Id: <9f5000ceea14e6818e491df38eba161c800b4cf8.1588282027.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588282027.git.rosbrookn@ainfosec.com>
References: <cover.1588282027.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1588282027.git.rosbrookn@ainfosec.com>
References: <cover.1588282027.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Add a README and package comment giving a brief overview of the package.
These also help pkg.go.dev generate better documentation.

Also, add a copy of Xen's license to tools/golang/xenlight. This is
required for the package to be shown on pkg.go.dev and added to the
default module proxy, proxy.golang.org.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 tools/golang/xenlight/LICENSE     | 416 ++++++++++++++++++++++++++++++
 tools/golang/xenlight/README.md   |  17 ++
 tools/golang/xenlight/xenlight.go |   2 +
 3 files changed, 435 insertions(+)
 create mode 100644 tools/golang/xenlight/LICENSE
 create mode 100644 tools/golang/xenlight/README.md

diff --git a/tools/golang/xenlight/LICENSE b/tools/golang/xenlight/LICENSE
new file mode 100644
index 0000000000..a4bc2b2dd4
--- /dev/null
+++ b/tools/golang/xenlight/LICENSE
@@ -0,0 +1,416 @@
+
+GNU General Public License
+--------------------------
+
+Most files in this repository are licensed under the terms of the GNU
+General Public License (GPL), a copy of which is attached at the end
+of this notice. Note that the only valid version of the GPL as far as
+the files in this repository are concerned is _this_ particular
+version of the license (i.e., *only* v2, not v2.2 or v3.x or
+whatever), unless explicitly otherwise stated.
+
+Some code fragments in the hypervisor and associated subsystems
+include other license stanzas: the most common ones are listed in
+the *License Exceptions* section of this file.
+
+When these code sections are compiled as part of a
+GPLv2-licensed program, such as Xen, the result is licensed under
+GPLv2. See the FSF's definition of GPL compatibility:
+ http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
+And how this applies to a range of open source licenses:
+ http://www.gnu.org/licenses/license-list.html
+
+A number of files will also specify GPL exceptions, such as
+ - Autoconf exception
+ - Bison exception
+ - GCC exception
+
+In addition the xen directory also contains a XEN NOTICE clarifying
+what constitutes a derived work, which applies to the xen directory
+and its subdirectories (see xen/COPYING).
+
+Licensing Exceptions
+--------------------
+
+For the convenience of users and those who are porting OSes to run as
+Xen guests, certain files in this repository are not subject to the
+GPL when distributed separately or included in software packages
+outside this repository.
+
+Instead we specify more relaxed licenses, depending on need, such as
+  - BSD style license (BSD Original, BSD Modified, Intel BSD)
+  - MIT license
+  - LGPL 2.1
+
+Affected files include the Xen interface headers (xen/include/public),
+various drivers, support functions and header files within Xen-aware
+Linux source trees. In all such cases, license terms are stated at the
+top of the file or in a COPYING file in the same directory.
+
+Sphinx documentation is licensed under CC-BY 4.0.  See
+docs/README.source for more specific information.
+
+In some cases, compatible 3rd party code has been imported into the
+Xen tree, retaining the original license, such as
+  - AES-128 3.0
+  - FSF Unlimited License
+  - Laurikari License
+  - Public Domain
+  - ZLIB License
+
+Significant code imports are highlighted in a README.source file
+in the directory into which the file or code snippet was imported.
+
+Note that *any* file that is modified and then distributed within a
+Linux kernel is still subject to the GNU GPL.
+
+Contributions
+-------------
+
+Contributions are governed by the license that applies to the relevant
+specific file or by the license specified in the COPYING file, that
+governs the license of its containing directory and its subdirectories.
+
+For more information, see the CONTRIBUTING file.
+
+=====================================================================
+
+		    GNU GENERAL PUBLIC LICENSE
+		       Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+                       59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+			    Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+		    GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+			    NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+		     END OF TERMS AND CONDITIONS
+
+	    How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    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 <http://www.gnu.org/licenses/>.
+
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+    Gnomovision version 69, Copyright (C) year name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/tools/golang/xenlight/README.md b/tools/golang/xenlight/README.md
new file mode 100644
index 0000000000..42240e2132
--- /dev/null
+++ b/tools/golang/xenlight/README.md
@@ -0,0 +1,17 @@
+# xenlight
+
+## About
+
+The xenlight package provides Go bindings to Xen's libxl C library via cgo. The package is currently in an unstable "preview" state. This means the package is ready for initial use and evaluation, but is not yet fully functional. Namely, only a subset of libxl's API is implemented, and breaking changes may occur in future package versions.
+
+Much of the package is generated using the libxl IDL. Changes to the generated code can be made by modifying `tools/golang/xenlight/gengotypes.py` in the xen.git tree.
+
+## Getting Started
+
+```go
+import (
+        "xenbits.xen.org/git-http/xen.git/tools/golang/xenlight"
+)
+```
+
+The module is not yet tagged independently of xen.git, so expect to see `v0.0.0-<date>-<git hash>` as the package version. If you want to point to a Xen release, such as 4.14.0, you can run `go get xenbits.xen.org/git-http/xen.git/tools/golang/xenlight@RELEASE-4.14.0`.
diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go
index 6b4f492550..3eaa5a3d63 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -14,6 +14,8 @@
  * You should have received a copy of the GNU Lesser General Public
  * License along with this library; If not, see <http://www.gnu.org/licenses/>.
  */
+
+// Package xenlight provides bindings to Xen's libxl C library.
 package xenlight
 
 /*
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 21:39:28 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 21:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUGtz-0000A7-Cp; Thu, 30 Apr 2020 21:39:27 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=aBcg=6O=gmail.com=rosbrookn@srs-us1.protection.inumbo.net>)
 id 1jUGty-00009n-97
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 21:39:26 +0000
X-Inumbo-ID: 09744504-8b2b-11ea-9887-bc764e2007e4
Received: from mail-qk1-x741.google.com (unknown [2607:f8b0:4864:20::741])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 09744504-8b2b-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 21:39:14 +0000 (UTC)
Received: by mail-qk1-x741.google.com with SMTP id f83so58221qke.13
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 14:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :in-reply-to:references;
 bh=zO/QwmQM2eJmgFIVnT+skwr7mYqvfo4GsOBrQ+ORrQc=;
 b=NB2u25IkeBOI4eSaqCjr7OLW6OYRCYHKftFcl9gcJy5AmHjrGteWKicvisCROwbB2M
 6h/zjFZIaQJvfjBFCndM5BStyEXZ277oRFDEoZZp3A3eXb0z/f8PgnQmf/P1CJgGLuDL
 szCXa9EPOySjF3W+eHS+wkdwssOuBV40bVyjRMme3iWE7gaiwQkEyxoR/7VhgIURMLov
 unOPH8IUmp4lxH22abPVONfAcnqUMF/JXlP6rDQDAoQwBKW4LWQ/1FEykexRUKLUSFZC
 /gacntvzAwgjNEQfQHWrdOxG1y0VxWcLjT9Xpz6Iend6NTdH4Kl1OWTgRc3LjW8UVG9L
 sEOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:in-reply-to:references;
 bh=zO/QwmQM2eJmgFIVnT+skwr7mYqvfo4GsOBrQ+ORrQc=;
 b=lLZc2hTCma3m0fpGNDZCf0+ZNGoB5dvl7ED2KgJEpmkBaYrAi+t+8gAYgfEHLpx6C/
 YMvIR4aKmTJ9btfXvz3dlIptPt4z/YQDS7ls1brxVodTW0FlkwuKWEB5+tmiY3DpeFmJ
 iRAgnZJrrizjMZOiO22n2wmVcA/w9rwxBvXT236MyGG6XPwK3OkCLJjwusbC1ZN2vATV
 RHQsL64wtXOEvFvltaVXQlaTtRCCExsuHVpfLWCIZjqbIjF6fHCp6FMvQwjHA3hBFiJw
 qY4QzUAcnrD7vJJVoOPxv9CI6ZltNoO2WKVRs73LvOKzBzVmoSnAALd1uKWWGVg17K1k
 8QPg==
X-Gm-Message-State: AGi0PuZ6vdX49iO/bQefcbwzELuYdnb2fQmaEdDXFGaPqspqHd0gbECY
 bPVL6bXYcRpDhllLI8BdqmiFNkp/DuE=
X-Google-Smtp-Source: APiQypI25lMZcFA2OKC0nPPUIW81W8Dbi3f3IffkqjKicyO8SjolPOU9DfA70iiVBsaFMI7FsKz0pw==
X-Received: by 2002:a05:620a:6db:: with SMTP id
 27mr599543qky.314.1588282750776; 
 Thu, 30 Apr 2020 14:39:10 -0700 (PDT)
Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252])
 by smtp.gmail.com with ESMTPSA id b42sm922476qta.29.2020.04.30.14.39.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 30 Apr 2020 14:39:09 -0700 (PDT)
From: Nick Rosbrook <rosbrookn@gmail.com>
X-Google-Original-From: Nick Rosbrook <rosbrookn@ainfosec.com>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 1/3] golang/xenlight: re-track generated go code
Date: Thu, 30 Apr 2020 17:38:59 -0400
Message-Id: <2ccb1ae4ffa3f00a13ce303df0e4a44d249861c2.1588282027.git.rosbrookn@ainfosec.com>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <cover.1588282027.git.rosbrookn@ainfosec.com>
References: <cover.1588282027.git.rosbrookn@ainfosec.com>
In-Reply-To: <cover.1588282027.git.rosbrookn@ainfosec.com>
References: <cover.1588282027.git.rosbrookn@ainfosec.com>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Ian Jackson <ian.jackson@eu.citrix.com>,
 George Dunlap <george.dunlap@citrix.com>,
 Nick Rosbrook <rosbrookn@ainfosec.com>, Jan Beulich <jbeulich@suse.com>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

Commit df669de074c395a3b2eeb975fddd3da4c148da13 un-tracked the generated
Go code, but it was decided that we actually keep the generated code
in-tree.

Undo the changes to ignore the generated code, and re-generate it.

Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
---
 .gitignore                           |    3 -
 .hgignore                            |    2 -
 tools/golang/xenlight/Makefile       |    1 -
 tools/golang/xenlight/helpers.gen.go | 4728 ++++++++++++++++++++++++++
 tools/golang/xenlight/types.gen.go   | 1226 +++++++
 5 files changed, 5954 insertions(+), 6 deletions(-)
 create mode 100644 tools/golang/xenlight/helpers.gen.go
 create mode 100644 tools/golang/xenlight/types.gen.go

diff --git a/.gitignore b/.gitignore
index 9c8a31f896..bfa53723b3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -406,9 +406,6 @@ tools/xenstore/xenstore-watch
 tools/xl/_paths.h
 tools/xl/xl
 
-tools/golang/src
-tools/golang/*/*.gen.go
-
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
 docs/figs/*.png
diff --git a/.hgignore b/.hgignore
index 2ec52982e1..2d41670632 100644
--- a/.hgignore
+++ b/.hgignore
@@ -282,8 +282,6 @@
 ^tools/ocaml/test/xtl$
 ^tools/ocaml/test/send_debug_keys$
 ^tools/ocaml/test/list_domains$
-^tools/golang/src$
-^tools/golang/.*/.*\.gen\.go$
 ^tools/autom4te\.cache$
 ^tools/config\.h$
 ^tools/config\.log$
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
index 144c133ced..753132306a 100644
--- a/tools/golang/xenlight/Makefile
+++ b/tools/golang/xenlight/Makefile
@@ -49,7 +49,6 @@ install: build
 clean:
 	$(RM) -r $(XEN_GOPATH)$(GOXL_PKG_DIR)
 	$(RM) $(XEN_GOPATH)/pkg/*/$(XEN_GOCODE_URL)/xenlight.a
-	$(RM) *.gen.go
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
new file mode 100644
index 0000000000..109e9515a2
--- /dev/null
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -0,0 +1,4728 @@
+// DO NOT EDIT.
+//
+// This file is generated by:
+// gengotypes.py ../../libxl/libxl_types.idl
+//
+package xenlight
+
+import (
+	"errors"
+	"fmt"
+	"unsafe"
+)
+
+/*
+#cgo LDFLAGS: -lxenlight
+#include <stdlib.h>
+#include <libxl.h>
+
+typedef typeof(((struct libxl_channelinfo *)NULL)->u.pty)libxl_channelinfo_connection_union_pty;
+typedef typeof(((struct libxl_domain_build_info *)NULL)->u.hvm)libxl_domain_build_info_type_union_hvm;
+typedef typeof(((struct libxl_domain_build_info *)NULL)->u.pv)libxl_domain_build_info_type_union_pv;
+typedef typeof(((struct libxl_domain_build_info *)NULL)->u.pvh)libxl_domain_build_info_type_union_pvh;
+typedef typeof(((struct libxl_device_usbdev *)NULL)->u.hostdev)libxl_device_usbdev_type_union_hostdev;
+typedef typeof(((struct libxl_device_channel *)NULL)->u.socket)libxl_device_channel_connection_union_socket;
+typedef typeof(((struct libxl_event *)NULL)->u.domain_shutdown)libxl_event_type_union_domain_shutdown;
+typedef typeof(((struct libxl_event *)NULL)->u.disk_eject)libxl_event_type_union_disk_eject;
+typedef typeof(((struct libxl_event *)NULL)->u.operation_complete)libxl_event_type_union_operation_complete;
+typedef typeof(((struct libxl_psr_hw_info *)NULL)->u.cat)libxl_psr_hw_info_type_union_cat;
+typedef typeof(((struct libxl_psr_hw_info *)NULL)->u.mba)libxl_psr_hw_info_type_union_mba;
+*/
+import "C"
+
+// NewIoportRange returns an instance of IoportRange initialized with defaults.
+func NewIoportRange() (*IoportRange, error) {
+	var (
+		x  IoportRange
+		xc C.libxl_ioport_range
+	)
+
+	C.libxl_ioport_range_init(&xc)
+	defer C.libxl_ioport_range_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *IoportRange) fromC(xc *C.libxl_ioport_range) error {
+	x.First = uint32(xc.first)
+	x.Number = uint32(xc.number)
+
+	return nil
+}
+
+func (x *IoportRange) toC(xc *C.libxl_ioport_range) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_ioport_range_dispose(xc)
+		}
+	}()
+
+	xc.first = C.uint32_t(x.First)
+	xc.number = C.uint32_t(x.Number)
+
+	return nil
+}
+
+// NewIomemRange returns an instance of IomemRange initialized with defaults.
+func NewIomemRange() (*IomemRange, error) {
+	var (
+		x  IomemRange
+		xc C.libxl_iomem_range
+	)
+
+	C.libxl_iomem_range_init(&xc)
+	defer C.libxl_iomem_range_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *IomemRange) fromC(xc *C.libxl_iomem_range) error {
+	x.Start = uint64(xc.start)
+	x.Number = uint64(xc.number)
+	x.Gfn = uint64(xc.gfn)
+
+	return nil
+}
+
+func (x *IomemRange) toC(xc *C.libxl_iomem_range) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_iomem_range_dispose(xc)
+		}
+	}()
+
+	xc.start = C.uint64_t(x.Start)
+	xc.number = C.uint64_t(x.Number)
+	xc.gfn = C.uint64_t(x.Gfn)
+
+	return nil
+}
+
+// NewVgaInterfaceInfo returns an instance of VgaInterfaceInfo initialized with defaults.
+func NewVgaInterfaceInfo() (*VgaInterfaceInfo, error) {
+	var (
+		x  VgaInterfaceInfo
+		xc C.libxl_vga_interface_info
+	)
+
+	C.libxl_vga_interface_info_init(&xc)
+	defer C.libxl_vga_interface_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *VgaInterfaceInfo) fromC(xc *C.libxl_vga_interface_info) error {
+	x.Kind = VgaInterfaceType(xc.kind)
+
+	return nil
+}
+
+func (x *VgaInterfaceInfo) toC(xc *C.libxl_vga_interface_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vga_interface_info_dispose(xc)
+		}
+	}()
+
+	xc.kind = C.libxl_vga_interface_type(x.Kind)
+
+	return nil
+}
+
+// NewVncInfo returns an instance of VncInfo initialized with defaults.
+func NewVncInfo() (*VncInfo, error) {
+	var (
+		x  VncInfo
+		xc C.libxl_vnc_info
+	)
+
+	C.libxl_vnc_info_init(&xc)
+	defer C.libxl_vnc_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *VncInfo) fromC(xc *C.libxl_vnc_info) error {
+	if err := x.Enable.fromC(&xc.enable); err != nil {
+		return fmt.Errorf("converting field Enable: %v", err)
+	}
+	x.Listen = C.GoString(xc.listen)
+	x.Passwd = C.GoString(xc.passwd)
+	x.Display = int(xc.display)
+	if err := x.Findunused.fromC(&xc.findunused); err != nil {
+		return fmt.Errorf("converting field Findunused: %v", err)
+	}
+
+	return nil
+}
+
+func (x *VncInfo) toC(xc *C.libxl_vnc_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vnc_info_dispose(xc)
+		}
+	}()
+
+	if err := x.Enable.toC(&xc.enable); err != nil {
+		return fmt.Errorf("converting field Enable: %v", err)
+	}
+	if x.Listen != "" {
+		xc.listen = C.CString(x.Listen)
+	}
+	if x.Passwd != "" {
+		xc.passwd = C.CString(x.Passwd)
+	}
+	xc.display = C.int(x.Display)
+	if err := x.Findunused.toC(&xc.findunused); err != nil {
+		return fmt.Errorf("converting field Findunused: %v", err)
+	}
+
+	return nil
+}
+
+// NewSpiceInfo returns an instance of SpiceInfo initialized with defaults.
+func NewSpiceInfo() (*SpiceInfo, error) {
+	var (
+		x  SpiceInfo
+		xc C.libxl_spice_info
+	)
+
+	C.libxl_spice_info_init(&xc)
+	defer C.libxl_spice_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *SpiceInfo) fromC(xc *C.libxl_spice_info) error {
+	if err := x.Enable.fromC(&xc.enable); err != nil {
+		return fmt.Errorf("converting field Enable: %v", err)
+	}
+	x.Port = int(xc.port)
+	x.TlsPort = int(xc.tls_port)
+	x.Host = C.GoString(xc.host)
+	if err := x.DisableTicketing.fromC(&xc.disable_ticketing); err != nil {
+		return fmt.Errorf("converting field DisableTicketing: %v", err)
+	}
+	x.Passwd = C.GoString(xc.passwd)
+	if err := x.AgentMouse.fromC(&xc.agent_mouse); err != nil {
+		return fmt.Errorf("converting field AgentMouse: %v", err)
+	}
+	if err := x.Vdagent.fromC(&xc.vdagent); err != nil {
+		return fmt.Errorf("converting field Vdagent: %v", err)
+	}
+	if err := x.ClipboardSharing.fromC(&xc.clipboard_sharing); err != nil {
+		return fmt.Errorf("converting field ClipboardSharing: %v", err)
+	}
+	x.Usbredirection = int(xc.usbredirection)
+	x.ImageCompression = C.GoString(xc.image_compression)
+	x.StreamingVideo = C.GoString(xc.streaming_video)
+
+	return nil
+}
+
+func (x *SpiceInfo) toC(xc *C.libxl_spice_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_spice_info_dispose(xc)
+		}
+	}()
+
+	if err := x.Enable.toC(&xc.enable); err != nil {
+		return fmt.Errorf("converting field Enable: %v", err)
+	}
+	xc.port = C.int(x.Port)
+	xc.tls_port = C.int(x.TlsPort)
+	if x.Host != "" {
+		xc.host = C.CString(x.Host)
+	}
+	if err := x.DisableTicketing.toC(&xc.disable_ticketing); err != nil {
+		return fmt.Errorf("converting field DisableTicketing: %v", err)
+	}
+	if x.Passwd != "" {
+		xc.passwd = C.CString(x.Passwd)
+	}
+	if err := x.AgentMouse.toC(&xc.agent_mouse); err != nil {
+		return fmt.Errorf("converting field AgentMouse: %v", err)
+	}
+	if err := x.Vdagent.toC(&xc.vdagent); err != nil {
+		return fmt.Errorf("converting field Vdagent: %v", err)
+	}
+	if err := x.ClipboardSharing.toC(&xc.clipboard_sharing); err != nil {
+		return fmt.Errorf("converting field ClipboardSharing: %v", err)
+	}
+	xc.usbredirection = C.int(x.Usbredirection)
+	if x.ImageCompression != "" {
+		xc.image_compression = C.CString(x.ImageCompression)
+	}
+	if x.StreamingVideo != "" {
+		xc.streaming_video = C.CString(x.StreamingVideo)
+	}
+
+	return nil
+}
+
+// NewSdlInfo returns an instance of SdlInfo initialized with defaults.
+func NewSdlInfo() (*SdlInfo, error) {
+	var (
+		x  SdlInfo
+		xc C.libxl_sdl_info
+	)
+
+	C.libxl_sdl_info_init(&xc)
+	defer C.libxl_sdl_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *SdlInfo) fromC(xc *C.libxl_sdl_info) error {
+	if err := x.Enable.fromC(&xc.enable); err != nil {
+		return fmt.Errorf("converting field Enable: %v", err)
+	}
+	if err := x.Opengl.fromC(&xc.opengl); err != nil {
+		return fmt.Errorf("converting field Opengl: %v", err)
+	}
+	x.Display = C.GoString(xc.display)
+	x.Xauthority = C.GoString(xc.xauthority)
+
+	return nil
+}
+
+func (x *SdlInfo) toC(xc *C.libxl_sdl_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_sdl_info_dispose(xc)
+		}
+	}()
+
+	if err := x.Enable.toC(&xc.enable); err != nil {
+		return fmt.Errorf("converting field Enable: %v", err)
+	}
+	if err := x.Opengl.toC(&xc.opengl); err != nil {
+		return fmt.Errorf("converting field Opengl: %v", err)
+	}
+	if x.Display != "" {
+		xc.display = C.CString(x.Display)
+	}
+	if x.Xauthority != "" {
+		xc.xauthority = C.CString(x.Xauthority)
+	}
+
+	return nil
+}
+
+// NewDominfo returns an instance of Dominfo initialized with defaults.
+func NewDominfo() (*Dominfo, error) {
+	var (
+		x  Dominfo
+		xc C.libxl_dominfo
+	)
+
+	C.libxl_dominfo_init(&xc)
+	defer C.libxl_dominfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Dominfo) fromC(xc *C.libxl_dominfo) error {
+	if err := x.Uuid.fromC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+	x.Domid = Domid(xc.domid)
+	x.Ssidref = uint32(xc.ssidref)
+	x.SsidLabel = C.GoString(xc.ssid_label)
+	x.Running = bool(xc.running)
+	x.Blocked = bool(xc.blocked)
+	x.Paused = bool(xc.paused)
+	x.Shutdown = bool(xc.shutdown)
+	x.Dying = bool(xc.dying)
+	x.NeverStop = bool(xc.never_stop)
+	x.ShutdownReason = ShutdownReason(xc.shutdown_reason)
+	x.OutstandingMemkb = uint64(xc.outstanding_memkb)
+	x.CurrentMemkb = uint64(xc.current_memkb)
+	x.SharedMemkb = uint64(xc.shared_memkb)
+	x.PagedMemkb = uint64(xc.paged_memkb)
+	x.MaxMemkb = uint64(xc.max_memkb)
+	x.CpuTime = uint64(xc.cpu_time)
+	x.VcpuMaxId = uint32(xc.vcpu_max_id)
+	x.VcpuOnline = uint32(xc.vcpu_online)
+	x.Cpupool = uint32(xc.cpupool)
+	x.DomainType = DomainType(xc.domain_type)
+
+	return nil
+}
+
+func (x *Dominfo) toC(xc *C.libxl_dominfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_dominfo_dispose(xc)
+		}
+	}()
+
+	if err := x.Uuid.toC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+	xc.domid = C.libxl_domid(x.Domid)
+	xc.ssidref = C.uint32_t(x.Ssidref)
+	if x.SsidLabel != "" {
+		xc.ssid_label = C.CString(x.SsidLabel)
+	}
+	xc.running = C.bool(x.Running)
+	xc.blocked = C.bool(x.Blocked)
+	xc.paused = C.bool(x.Paused)
+	xc.shutdown = C.bool(x.Shutdown)
+	xc.dying = C.bool(x.Dying)
+	xc.never_stop = C.bool(x.NeverStop)
+	xc.shutdown_reason = C.libxl_shutdown_reason(x.ShutdownReason)
+	xc.outstanding_memkb = C.uint64_t(x.OutstandingMemkb)
+	xc.current_memkb = C.uint64_t(x.CurrentMemkb)
+	xc.shared_memkb = C.uint64_t(x.SharedMemkb)
+	xc.paged_memkb = C.uint64_t(x.PagedMemkb)
+	xc.max_memkb = C.uint64_t(x.MaxMemkb)
+	xc.cpu_time = C.uint64_t(x.CpuTime)
+	xc.vcpu_max_id = C.uint32_t(x.VcpuMaxId)
+	xc.vcpu_online = C.uint32_t(x.VcpuOnline)
+	xc.cpupool = C.uint32_t(x.Cpupool)
+	xc.domain_type = C.libxl_domain_type(x.DomainType)
+
+	return nil
+}
+
+// NewCpupoolinfo returns an instance of Cpupoolinfo initialized with defaults.
+func NewCpupoolinfo() (*Cpupoolinfo, error) {
+	var (
+		x  Cpupoolinfo
+		xc C.libxl_cpupoolinfo
+	)
+
+	C.libxl_cpupoolinfo_init(&xc)
+	defer C.libxl_cpupoolinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Cpupoolinfo) fromC(xc *C.libxl_cpupoolinfo) error {
+	x.Poolid = uint32(xc.poolid)
+	x.PoolName = C.GoString(xc.pool_name)
+	x.Sched = Scheduler(xc.sched)
+	x.NDom = uint32(xc.n_dom)
+	if err := x.Cpumap.fromC(&xc.cpumap); err != nil {
+		return fmt.Errorf("converting field Cpumap: %v", err)
+	}
+
+	return nil
+}
+
+func (x *Cpupoolinfo) toC(xc *C.libxl_cpupoolinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_cpupoolinfo_dispose(xc)
+		}
+	}()
+
+	xc.poolid = C.uint32_t(x.Poolid)
+	if x.PoolName != "" {
+		xc.pool_name = C.CString(x.PoolName)
+	}
+	xc.sched = C.libxl_scheduler(x.Sched)
+	xc.n_dom = C.uint32_t(x.NDom)
+	if err := x.Cpumap.toC(&xc.cpumap); err != nil {
+		return fmt.Errorf("converting field Cpumap: %v", err)
+	}
+
+	return nil
+}
+
+// NewChannelinfo returns an instance of Channelinfo initialized with defaults.
+func NewChannelinfo(connection ChannelConnection) (*Channelinfo, error) {
+	var (
+		x  Channelinfo
+		xc C.libxl_channelinfo
+	)
+
+	C.libxl_channelinfo_init(&xc)
+	C.libxl_channelinfo_init_connection(&xc, C.libxl_channel_connection(connection))
+	defer C.libxl_channelinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Channelinfo) fromC(xc *C.libxl_channelinfo) error {
+	x.Backend = C.GoString(xc.backend)
+	x.BackendId = uint32(xc.backend_id)
+	x.Frontend = C.GoString(xc.frontend)
+	x.FrontendId = uint32(xc.frontend_id)
+	x.Devid = Devid(xc.devid)
+	x.State = int(xc.state)
+	x.Evtch = int(xc.evtch)
+	x.Rref = int(xc.rref)
+	x.Connection = ChannelConnection(xc.connection)
+	switch x.Connection {
+	case ChannelConnectionUnknown:
+		x.ConnectionUnion = nil
+	case ChannelConnectionPty:
+		var connectionPty ChannelinfoConnectionUnionPty
+		if err := connectionPty.fromC(xc); err != nil {
+			return fmt.Errorf("converting field connectionPty: %v", err)
+		}
+		x.ConnectionUnion = connectionPty
+	case ChannelConnectionSocket:
+		x.ConnectionUnion = nil
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Connection)
+	}
+
+	return nil
+}
+
+func (x *ChannelinfoConnectionUnionPty) fromC(xc *C.libxl_channelinfo) error {
+	if ChannelConnection(xc.connection) != ChannelConnectionPty {
+		return errors.New("expected union key ChannelConnectionPty")
+	}
+
+	tmp := (*C.libxl_channelinfo_connection_union_pty)(unsafe.Pointer(&xc.u[0]))
+	x.Path = C.GoString(tmp.path)
+	return nil
+}
+
+func (x *Channelinfo) toC(xc *C.libxl_channelinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_channelinfo_dispose(xc)
+		}
+	}()
+
+	if x.Backend != "" {
+		xc.backend = C.CString(x.Backend)
+	}
+	xc.backend_id = C.uint32_t(x.BackendId)
+	if x.Frontend != "" {
+		xc.frontend = C.CString(x.Frontend)
+	}
+	xc.frontend_id = C.uint32_t(x.FrontendId)
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.state = C.int(x.State)
+	xc.evtch = C.int(x.Evtch)
+	xc.rref = C.int(x.Rref)
+	xc.connection = C.libxl_channel_connection(x.Connection)
+	switch x.Connection {
+	case ChannelConnectionUnknown:
+		break
+	case ChannelConnectionPty:
+		tmp, ok := x.ConnectionUnion.(ChannelinfoConnectionUnionPty)
+		if !ok {
+			return errors.New("wrong type for union key connection")
+		}
+		var pty C.libxl_channelinfo_connection_union_pty
+		if tmp.Path != "" {
+			pty.path = C.CString(tmp.Path)
+		}
+		ptyBytes := C.GoBytes(unsafe.Pointer(&pty), C.sizeof_libxl_channelinfo_connection_union_pty)
+		copy(xc.u[:], ptyBytes)
+	case ChannelConnectionSocket:
+		break
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Connection)
+	}
+
+	return nil
+}
+
+// NewVminfo returns an instance of Vminfo initialized with defaults.
+func NewVminfo() (*Vminfo, error) {
+	var (
+		x  Vminfo
+		xc C.libxl_vminfo
+	)
+
+	C.libxl_vminfo_init(&xc)
+	defer C.libxl_vminfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Vminfo) fromC(xc *C.libxl_vminfo) error {
+	if err := x.Uuid.fromC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+	x.Domid = Domid(xc.domid)
+
+	return nil
+}
+
+func (x *Vminfo) toC(xc *C.libxl_vminfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vminfo_dispose(xc)
+		}
+	}()
+
+	if err := x.Uuid.toC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+	xc.domid = C.libxl_domid(x.Domid)
+
+	return nil
+}
+
+// NewVersionInfo returns an instance of VersionInfo initialized with defaults.
+func NewVersionInfo() (*VersionInfo, error) {
+	var (
+		x  VersionInfo
+		xc C.libxl_version_info
+	)
+
+	C.libxl_version_info_init(&xc)
+	defer C.libxl_version_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *VersionInfo) fromC(xc *C.libxl_version_info) error {
+	x.XenVersionMajor = int(xc.xen_version_major)
+	x.XenVersionMinor = int(xc.xen_version_minor)
+	x.XenVersionExtra = C.GoString(xc.xen_version_extra)
+	x.Compiler = C.GoString(xc.compiler)
+	x.CompileBy = C.GoString(xc.compile_by)
+	x.CompileDomain = C.GoString(xc.compile_domain)
+	x.CompileDate = C.GoString(xc.compile_date)
+	x.Capabilities = C.GoString(xc.capabilities)
+	x.Changeset = C.GoString(xc.changeset)
+	x.VirtStart = uint64(xc.virt_start)
+	x.Pagesize = int(xc.pagesize)
+	x.Commandline = C.GoString(xc.commandline)
+	x.BuildId = C.GoString(xc.build_id)
+
+	return nil
+}
+
+func (x *VersionInfo) toC(xc *C.libxl_version_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_version_info_dispose(xc)
+		}
+	}()
+
+	xc.xen_version_major = C.int(x.XenVersionMajor)
+	xc.xen_version_minor = C.int(x.XenVersionMinor)
+	if x.XenVersionExtra != "" {
+		xc.xen_version_extra = C.CString(x.XenVersionExtra)
+	}
+	if x.Compiler != "" {
+		xc.compiler = C.CString(x.Compiler)
+	}
+	if x.CompileBy != "" {
+		xc.compile_by = C.CString(x.CompileBy)
+	}
+	if x.CompileDomain != "" {
+		xc.compile_domain = C.CString(x.CompileDomain)
+	}
+	if x.CompileDate != "" {
+		xc.compile_date = C.CString(x.CompileDate)
+	}
+	if x.Capabilities != "" {
+		xc.capabilities = C.CString(x.Capabilities)
+	}
+	if x.Changeset != "" {
+		xc.changeset = C.CString(x.Changeset)
+	}
+	xc.virt_start = C.uint64_t(x.VirtStart)
+	xc.pagesize = C.int(x.Pagesize)
+	if x.Commandline != "" {
+		xc.commandline = C.CString(x.Commandline)
+	}
+	if x.BuildId != "" {
+		xc.build_id = C.CString(x.BuildId)
+	}
+
+	return nil
+}
+
+// NewDomainCreateInfo returns an instance of DomainCreateInfo initialized with defaults.
+func NewDomainCreateInfo() (*DomainCreateInfo, error) {
+	var (
+		x  DomainCreateInfo
+		xc C.libxl_domain_create_info
+	)
+
+	C.libxl_domain_create_info_init(&xc)
+	defer C.libxl_domain_create_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DomainCreateInfo) fromC(xc *C.libxl_domain_create_info) error {
+	x.Type = DomainType(xc._type)
+	if err := x.Hap.fromC(&xc.hap); err != nil {
+		return fmt.Errorf("converting field Hap: %v", err)
+	}
+	if err := x.Oos.fromC(&xc.oos); err != nil {
+		return fmt.Errorf("converting field Oos: %v", err)
+	}
+	x.Ssidref = uint32(xc.ssidref)
+	x.SsidLabel = C.GoString(xc.ssid_label)
+	x.Name = C.GoString(xc.name)
+	x.Domid = Domid(xc.domid)
+	if err := x.Uuid.fromC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+	if err := x.Xsdata.fromC(&xc.xsdata); err != nil {
+		return fmt.Errorf("converting field Xsdata: %v", err)
+	}
+	if err := x.Platformdata.fromC(&xc.platformdata); err != nil {
+		return fmt.Errorf("converting field Platformdata: %v", err)
+	}
+	x.Poolid = uint32(xc.poolid)
+	x.PoolName = C.GoString(xc.pool_name)
+	if err := x.RunHotplugScripts.fromC(&xc.run_hotplug_scripts); err != nil {
+		return fmt.Errorf("converting field RunHotplugScripts: %v", err)
+	}
+	if err := x.DriverDomain.fromC(&xc.driver_domain); err != nil {
+		return fmt.Errorf("converting field DriverDomain: %v", err)
+	}
+	x.Passthrough = Passthrough(xc.passthrough)
+	if err := x.XendSuspendEvtchnCompat.fromC(&xc.xend_suspend_evtchn_compat); err != nil {
+		return fmt.Errorf("converting field XendSuspendEvtchnCompat: %v", err)
+	}
+
+	return nil
+}
+
+func (x *DomainCreateInfo) toC(xc *C.libxl_domain_create_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_domain_create_info_dispose(xc)
+		}
+	}()
+
+	xc._type = C.libxl_domain_type(x.Type)
+	if err := x.Hap.toC(&xc.hap); err != nil {
+		return fmt.Errorf("converting field Hap: %v", err)
+	}
+	if err := x.Oos.toC(&xc.oos); err != nil {
+		return fmt.Errorf("converting field Oos: %v", err)
+	}
+	xc.ssidref = C.uint32_t(x.Ssidref)
+	if x.SsidLabel != "" {
+		xc.ssid_label = C.CString(x.SsidLabel)
+	}
+	if x.Name != "" {
+		xc.name = C.CString(x.Name)
+	}
+	xc.domid = C.libxl_domid(x.Domid)
+	if err := x.Uuid.toC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+	if err := x.Xsdata.toC(&xc.xsdata); err != nil {
+		return fmt.Errorf("converting field Xsdata: %v", err)
+	}
+	if err := x.Platformdata.toC(&xc.platformdata); err != nil {
+		return fmt.Errorf("converting field Platformdata: %v", err)
+	}
+	xc.poolid = C.uint32_t(x.Poolid)
+	if x.PoolName != "" {
+		xc.pool_name = C.CString(x.PoolName)
+	}
+	if err := x.RunHotplugScripts.toC(&xc.run_hotplug_scripts); err != nil {
+		return fmt.Errorf("converting field RunHotplugScripts: %v", err)
+	}
+	if err := x.DriverDomain.toC(&xc.driver_domain); err != nil {
+		return fmt.Errorf("converting field DriverDomain: %v", err)
+	}
+	xc.passthrough = C.libxl_passthrough(x.Passthrough)
+	if err := x.XendSuspendEvtchnCompat.toC(&xc.xend_suspend_evtchn_compat); err != nil {
+		return fmt.Errorf("converting field XendSuspendEvtchnCompat: %v", err)
+	}
+
+	return nil
+}
+
+// NewDomainRestoreParams returns an instance of DomainRestoreParams initialized with defaults.
+func NewDomainRestoreParams() (*DomainRestoreParams, error) {
+	var (
+		x  DomainRestoreParams
+		xc C.libxl_domain_restore_params
+	)
+
+	C.libxl_domain_restore_params_init(&xc)
+	defer C.libxl_domain_restore_params_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DomainRestoreParams) fromC(xc *C.libxl_domain_restore_params) error {
+	x.CheckpointedStream = int(xc.checkpointed_stream)
+	x.StreamVersion = uint32(xc.stream_version)
+	x.ColoProxyScript = C.GoString(xc.colo_proxy_script)
+	if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy); err != nil {
+		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
+	}
+
+	return nil
+}
+
+func (x *DomainRestoreParams) toC(xc *C.libxl_domain_restore_params) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_domain_restore_params_dispose(xc)
+		}
+	}()
+
+	xc.checkpointed_stream = C.int(x.CheckpointedStream)
+	xc.stream_version = C.uint32_t(x.StreamVersion)
+	if x.ColoProxyScript != "" {
+		xc.colo_proxy_script = C.CString(x.ColoProxyScript)
+	}
+	if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil {
+		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
+	}
+
+	return nil
+}
+
+// NewSchedParams returns an instance of SchedParams initialized with defaults.
+func NewSchedParams() (*SchedParams, error) {
+	var (
+		x  SchedParams
+		xc C.libxl_sched_params
+	)
+
+	C.libxl_sched_params_init(&xc)
+	defer C.libxl_sched_params_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *SchedParams) fromC(xc *C.libxl_sched_params) error {
+	x.Vcpuid = int(xc.vcpuid)
+	x.Weight = int(xc.weight)
+	x.Cap = int(xc.cap)
+	x.Period = int(xc.period)
+	x.Extratime = int(xc.extratime)
+	x.Budget = int(xc.budget)
+
+	return nil
+}
+
+func (x *SchedParams) toC(xc *C.libxl_sched_params) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_sched_params_dispose(xc)
+		}
+	}()
+
+	xc.vcpuid = C.int(x.Vcpuid)
+	xc.weight = C.int(x.Weight)
+	xc.cap = C.int(x.Cap)
+	xc.period = C.int(x.Period)
+	xc.extratime = C.int(x.Extratime)
+	xc.budget = C.int(x.Budget)
+
+	return nil
+}
+
+// NewVcpuSchedParams returns an instance of VcpuSchedParams initialized with defaults.
+func NewVcpuSchedParams() (*VcpuSchedParams, error) {
+	var (
+		x  VcpuSchedParams
+		xc C.libxl_vcpu_sched_params
+	)
+
+	C.libxl_vcpu_sched_params_init(&xc)
+	defer C.libxl_vcpu_sched_params_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *VcpuSchedParams) fromC(xc *C.libxl_vcpu_sched_params) error {
+	x.Sched = Scheduler(xc.sched)
+	x.Vcpus = nil
+	if n := int(xc.num_vcpus); n > 0 {
+		cVcpus := (*[1 << 28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:n:n]
+		x.Vcpus = make([]SchedParams, n)
+		for i, v := range cVcpus {
+			if err := x.Vcpus[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Vcpus: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+func (x *VcpuSchedParams) toC(xc *C.libxl_vcpu_sched_params) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vcpu_sched_params_dispose(xc)
+		}
+	}()
+
+	xc.sched = C.libxl_scheduler(x.Sched)
+	if numVcpus := len(x.Vcpus); numVcpus > 0 {
+		xc.vcpus = (*C.libxl_sched_params)(C.malloc(C.ulong(numVcpus) * C.sizeof_libxl_sched_params))
+		xc.num_vcpus = C.int(numVcpus)
+		cVcpus := (*[1 << 28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:numVcpus:numVcpus]
+		for i, v := range x.Vcpus {
+			if err := v.toC(&cVcpus[i]); err != nil {
+				return fmt.Errorf("converting field Vcpus: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+// NewDomainSchedParams returns an instance of DomainSchedParams initialized with defaults.
+func NewDomainSchedParams() (*DomainSchedParams, error) {
+	var (
+		x  DomainSchedParams
+		xc C.libxl_domain_sched_params
+	)
+
+	C.libxl_domain_sched_params_init(&xc)
+	defer C.libxl_domain_sched_params_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DomainSchedParams) fromC(xc *C.libxl_domain_sched_params) error {
+	x.Sched = Scheduler(xc.sched)
+	x.Weight = int(xc.weight)
+	x.Cap = int(xc.cap)
+	x.Period = int(xc.period)
+	x.Budget = int(xc.budget)
+	x.Extratime = int(xc.extratime)
+	x.Slice = int(xc.slice)
+	x.Latency = int(xc.latency)
+
+	return nil
+}
+
+func (x *DomainSchedParams) toC(xc *C.libxl_domain_sched_params) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_domain_sched_params_dispose(xc)
+		}
+	}()
+
+	xc.sched = C.libxl_scheduler(x.Sched)
+	xc.weight = C.int(x.Weight)
+	xc.cap = C.int(x.Cap)
+	xc.period = C.int(x.Period)
+	xc.budget = C.int(x.Budget)
+	xc.extratime = C.int(x.Extratime)
+	xc.slice = C.int(x.Slice)
+	xc.latency = C.int(x.Latency)
+
+	return nil
+}
+
+// NewVnodeInfo returns an instance of VnodeInfo initialized with defaults.
+func NewVnodeInfo() (*VnodeInfo, error) {
+	var (
+		x  VnodeInfo
+		xc C.libxl_vnode_info
+	)
+
+	C.libxl_vnode_info_init(&xc)
+	defer C.libxl_vnode_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *VnodeInfo) fromC(xc *C.libxl_vnode_info) error {
+	x.Memkb = uint64(xc.memkb)
+	x.Distances = nil
+	if n := int(xc.num_distances); n > 0 {
+		cDistances := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.distances))[:n:n]
+		x.Distances = make([]uint32, n)
+		for i, v := range cDistances {
+			x.Distances[i] = uint32(v)
+		}
+	}
+	x.Pnode = uint32(xc.pnode)
+	if err := x.Vcpus.fromC(&xc.vcpus); err != nil {
+		return fmt.Errorf("converting field Vcpus: %v", err)
+	}
+
+	return nil
+}
+
+func (x *VnodeInfo) toC(xc *C.libxl_vnode_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vnode_info_dispose(xc)
+		}
+	}()
+
+	xc.memkb = C.uint64_t(x.Memkb)
+	if numDistances := len(x.Distances); numDistances > 0 {
+		xc.distances = (*C.uint32_t)(C.malloc(C.size_t(numDistances * numDistances)))
+		xc.num_distances = C.int(numDistances)
+		cDistances := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.distances))[:numDistances:numDistances]
+		for i, v := range x.Distances {
+			cDistances[i] = C.uint32_t(v)
+		}
+	}
+	xc.pnode = C.uint32_t(x.Pnode)
+	if err := x.Vcpus.toC(&xc.vcpus); err != nil {
+		return fmt.Errorf("converting field Vcpus: %v", err)
+	}
+
+	return nil
+}
+
+// NewRdmReserve returns an instance of RdmReserve initialized with defaults.
+func NewRdmReserve() (*RdmReserve, error) {
+	var (
+		x  RdmReserve
+		xc C.libxl_rdm_reserve
+	)
+
+	C.libxl_rdm_reserve_init(&xc)
+	defer C.libxl_rdm_reserve_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *RdmReserve) fromC(xc *C.libxl_rdm_reserve) error {
+	x.Strategy = RdmReserveStrategy(xc.strategy)
+	x.Policy = RdmReservePolicy(xc.policy)
+
+	return nil
+}
+
+func (x *RdmReserve) toC(xc *C.libxl_rdm_reserve) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_rdm_reserve_dispose(xc)
+		}
+	}()
+
+	xc.strategy = C.libxl_rdm_reserve_strategy(x.Strategy)
+	xc.policy = C.libxl_rdm_reserve_policy(x.Policy)
+
+	return nil
+}
+
+// NewDomainBuildInfo returns an instance of DomainBuildInfo initialized with defaults.
+func NewDomainBuildInfo(dtype DomainType) (*DomainBuildInfo, error) {
+	var (
+		x  DomainBuildInfo
+		xc C.libxl_domain_build_info
+	)
+
+	C.libxl_domain_build_info_init(&xc)
+	C.libxl_domain_build_info_init_type(&xc, C.libxl_domain_type(dtype))
+	defer C.libxl_domain_build_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DomainBuildInfo) fromC(xc *C.libxl_domain_build_info) error {
+	x.MaxVcpus = int(xc.max_vcpus)
+	if err := x.AvailVcpus.fromC(&xc.avail_vcpus); err != nil {
+		return fmt.Errorf("converting field AvailVcpus: %v", err)
+	}
+	if err := x.Cpumap.fromC(&xc.cpumap); err != nil {
+		return fmt.Errorf("converting field Cpumap: %v", err)
+	}
+	if err := x.Nodemap.fromC(&xc.nodemap); err != nil {
+		return fmt.Errorf("converting field Nodemap: %v", err)
+	}
+	x.VcpuHardAffinity = nil
+	if n := int(xc.num_vcpu_hard_affinity); n > 0 {
+		cVcpuHardAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:n:n]
+		x.VcpuHardAffinity = make([]Bitmap, n)
+		for i, v := range cVcpuHardAffinity {
+			if err := x.VcpuHardAffinity[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field VcpuHardAffinity: %v", err)
+			}
+		}
+	}
+	x.VcpuSoftAffinity = nil
+	if n := int(xc.num_vcpu_soft_affinity); n > 0 {
+		cVcpuSoftAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:n:n]
+		x.VcpuSoftAffinity = make([]Bitmap, n)
+		for i, v := range cVcpuSoftAffinity {
+			if err := x.VcpuSoftAffinity[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field VcpuSoftAffinity: %v", err)
+			}
+		}
+	}
+	if err := x.NumaPlacement.fromC(&xc.numa_placement); err != nil {
+		return fmt.Errorf("converting field NumaPlacement: %v", err)
+	}
+	x.TscMode = TscMode(xc.tsc_mode)
+	x.MaxMemkb = uint64(xc.max_memkb)
+	x.TargetMemkb = uint64(xc.target_memkb)
+	x.VideoMemkb = uint64(xc.video_memkb)
+	x.ShadowMemkb = uint64(xc.shadow_memkb)
+	x.IommuMemkb = uint64(xc.iommu_memkb)
+	x.RtcTimeoffset = uint32(xc.rtc_timeoffset)
+	x.ExecSsidref = uint32(xc.exec_ssidref)
+	x.ExecSsidLabel = C.GoString(xc.exec_ssid_label)
+	if err := x.Localtime.fromC(&xc.localtime); err != nil {
+		return fmt.Errorf("converting field Localtime: %v", err)
+	}
+	if err := x.DisableMigrate.fromC(&xc.disable_migrate); err != nil {
+		return fmt.Errorf("converting field DisableMigrate: %v", err)
+	}
+	if err := x.Cpuid.fromC(&xc.cpuid); err != nil {
+		return fmt.Errorf("converting field Cpuid: %v", err)
+	}
+	x.BlkdevStart = C.GoString(xc.blkdev_start)
+	x.VnumaNodes = nil
+	if n := int(xc.num_vnuma_nodes); n > 0 {
+		cVnumaNodes := (*[1 << 28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:n:n]
+		x.VnumaNodes = make([]VnodeInfo, n)
+		for i, v := range cVnumaNodes {
+			if err := x.VnumaNodes[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field VnumaNodes: %v", err)
+			}
+		}
+	}
+	x.MaxGrantFrames = uint32(xc.max_grant_frames)
+	x.MaxMaptrackFrames = uint32(xc.max_maptrack_frames)
+	x.DeviceModelVersion = DeviceModelVersion(xc.device_model_version)
+	if err := x.DeviceModelStubdomain.fromC(&xc.device_model_stubdomain); err != nil {
+		return fmt.Errorf("converting field DeviceModelStubdomain: %v", err)
+	}
+	x.DeviceModel = C.GoString(xc.device_model)
+	x.DeviceModelSsidref = uint32(xc.device_model_ssidref)
+	x.DeviceModelSsidLabel = C.GoString(xc.device_model_ssid_label)
+	x.DeviceModelUser = C.GoString(xc.device_model_user)
+	if err := x.Extra.fromC(&xc.extra); err != nil {
+		return fmt.Errorf("converting field Extra: %v", err)
+	}
+	if err := x.ExtraPv.fromC(&xc.extra_pv); err != nil {
+		return fmt.Errorf("converting field ExtraPv: %v", err)
+	}
+	if err := x.ExtraHvm.fromC(&xc.extra_hvm); err != nil {
+		return fmt.Errorf("converting field ExtraHvm: %v", err)
+	}
+	if err := x.SchedParams.fromC(&xc.sched_params); err != nil {
+		return fmt.Errorf("converting field SchedParams: %v", err)
+	}
+	x.Ioports = nil
+	if n := int(xc.num_ioports); n > 0 {
+		cIoports := (*[1 << 28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:n:n]
+		x.Ioports = make([]IoportRange, n)
+		for i, v := range cIoports {
+			if err := x.Ioports[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Ioports: %v", err)
+			}
+		}
+	}
+	x.Irqs = nil
+	if n := int(xc.num_irqs); n > 0 {
+		cIrqs := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:n:n]
+		x.Irqs = make([]uint32, n)
+		for i, v := range cIrqs {
+			x.Irqs[i] = uint32(v)
+		}
+	}
+	x.Iomem = nil
+	if n := int(xc.num_iomem); n > 0 {
+		cIomem := (*[1 << 28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:n:n]
+		x.Iomem = make([]IomemRange, n)
+		for i, v := range cIomem {
+			if err := x.Iomem[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Iomem: %v", err)
+			}
+		}
+	}
+	if err := x.ClaimMode.fromC(&xc.claim_mode); err != nil {
+		return fmt.Errorf("converting field ClaimMode: %v", err)
+	}
+	x.EventChannels = uint32(xc.event_channels)
+	x.Kernel = C.GoString(xc.kernel)
+	x.Cmdline = C.GoString(xc.cmdline)
+	x.Ramdisk = C.GoString(xc.ramdisk)
+	x.DeviceTree = C.GoString(xc.device_tree)
+	if err := x.Acpi.fromC(&xc.acpi); err != nil {
+		return fmt.Errorf("converting field Acpi: %v", err)
+	}
+	x.Bootloader = C.GoString(xc.bootloader)
+	if err := x.BootloaderArgs.fromC(&xc.bootloader_args); err != nil {
+		return fmt.Errorf("converting field BootloaderArgs: %v", err)
+	}
+	x.TimerMode = TimerMode(xc.timer_mode)
+	if err := x.NestedHvm.fromC(&xc.nested_hvm); err != nil {
+		return fmt.Errorf("converting field NestedHvm: %v", err)
+	}
+	if err := x.Apic.fromC(&xc.apic); err != nil {
+		return fmt.Errorf("converting field Apic: %v", err)
+	}
+	if err := x.DmRestrict.fromC(&xc.dm_restrict); err != nil {
+		return fmt.Errorf("converting field DmRestrict: %v", err)
+	}
+	x.Tee = TeeType(xc.tee)
+	x.Type = DomainType(xc._type)
+	switch x.Type {
+	case DomainTypeHvm:
+		var typeHvm DomainBuildInfoTypeUnionHvm
+		if err := typeHvm.fromC(xc); err != nil {
+			return fmt.Errorf("converting field typeHvm: %v", err)
+		}
+		x.TypeUnion = typeHvm
+	case DomainTypePv:
+		var typePv DomainBuildInfoTypeUnionPv
+		if err := typePv.fromC(xc); err != nil {
+			return fmt.Errorf("converting field typePv: %v", err)
+		}
+		x.TypeUnion = typePv
+	case DomainTypePvh:
+		var typePvh DomainBuildInfoTypeUnionPvh
+		if err := typePvh.fromC(xc); err != nil {
+			return fmt.Errorf("converting field typePvh: %v", err)
+		}
+		x.TypeUnion = typePvh
+	case DomainTypeInvalid:
+		x.TypeUnion = nil
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Type)
+	}
+	x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version)
+	x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart)
+	x.Altp2M = Altp2MMode(xc.altp2m)
+
+	return nil
+}
+
+func (x *DomainBuildInfoTypeUnionHvm) fromC(xc *C.libxl_domain_build_info) error {
+	if DomainType(xc._type) != DomainTypeHvm {
+		return errors.New("expected union key DomainTypeHvm")
+	}
+
+	tmp := (*C.libxl_domain_build_info_type_union_hvm)(unsafe.Pointer(&xc.u[0]))
+	x.Firmware = C.GoString(tmp.firmware)
+	x.Bios = BiosType(tmp.bios)
+	if err := x.Pae.fromC(&tmp.pae); err != nil {
+		return fmt.Errorf("converting field Pae: %v", err)
+	}
+	if err := x.Apic.fromC(&tmp.apic); err != nil {
+		return fmt.Errorf("converting field Apic: %v", err)
+	}
+	if err := x.Acpi.fromC(&tmp.acpi); err != nil {
+		return fmt.Errorf("converting field Acpi: %v", err)
+	}
+	if err := x.AcpiS3.fromC(&tmp.acpi_s3); err != nil {
+		return fmt.Errorf("converting field AcpiS3: %v", err)
+	}
+	if err := x.AcpiS4.fromC(&tmp.acpi_s4); err != nil {
+		return fmt.Errorf("converting field AcpiS4: %v", err)
+	}
+	if err := x.AcpiLaptopSlate.fromC(&tmp.acpi_laptop_slate); err != nil {
+		return fmt.Errorf("converting field AcpiLaptopSlate: %v", err)
+	}
+	if err := x.Nx.fromC(&tmp.nx); err != nil {
+		return fmt.Errorf("converting field Nx: %v", err)
+	}
+	if err := x.Viridian.fromC(&tmp.viridian); err != nil {
+		return fmt.Errorf("converting field Viridian: %v", err)
+	}
+	if err := x.ViridianEnable.fromC(&tmp.viridian_enable); err != nil {
+		return fmt.Errorf("converting field ViridianEnable: %v", err)
+	}
+	if err := x.ViridianDisable.fromC(&tmp.viridian_disable); err != nil {
+		return fmt.Errorf("converting field ViridianDisable: %v", err)
+	}
+	x.Timeoffset = C.GoString(tmp.timeoffset)
+	if err := x.Hpet.fromC(&tmp.hpet); err != nil {
+		return fmt.Errorf("converting field Hpet: %v", err)
+	}
+	if err := x.VptAlign.fromC(&tmp.vpt_align); err != nil {
+		return fmt.Errorf("converting field VptAlign: %v", err)
+	}
+	x.MmioHoleMemkb = uint64(tmp.mmio_hole_memkb)
+	x.TimerMode = TimerMode(tmp.timer_mode)
+	if err := x.NestedHvm.fromC(&tmp.nested_hvm); err != nil {
+		return fmt.Errorf("converting field NestedHvm: %v", err)
+	}
+	if err := x.Altp2M.fromC(&tmp.altp2m); err != nil {
+		return fmt.Errorf("converting field Altp2M: %v", err)
+	}
+	x.SystemFirmware = C.GoString(tmp.system_firmware)
+	x.SmbiosFirmware = C.GoString(tmp.smbios_firmware)
+	x.AcpiFirmware = C.GoString(tmp.acpi_firmware)
+	x.Hdtype = Hdtype(tmp.hdtype)
+	if err := x.Nographic.fromC(&tmp.nographic); err != nil {
+		return fmt.Errorf("converting field Nographic: %v", err)
+	}
+	if err := x.Vga.fromC(&tmp.vga); err != nil {
+		return fmt.Errorf("converting field Vga: %v", err)
+	}
+	if err := x.Vnc.fromC(&tmp.vnc); err != nil {
+		return fmt.Errorf("converting field Vnc: %v", err)
+	}
+	x.Keymap = C.GoString(tmp.keymap)
+	if err := x.Sdl.fromC(&tmp.sdl); err != nil {
+		return fmt.Errorf("converting field Sdl: %v", err)
+	}
+	if err := x.Spice.fromC(&tmp.spice); err != nil {
+		return fmt.Errorf("converting field Spice: %v", err)
+	}
+	if err := x.GfxPassthru.fromC(&tmp.gfx_passthru); err != nil {
+		return fmt.Errorf("converting field GfxPassthru: %v", err)
+	}
+	x.GfxPassthruKind = GfxPassthruKind(tmp.gfx_passthru_kind)
+	x.Serial = C.GoString(tmp.serial)
+	x.Boot = C.GoString(tmp.boot)
+	if err := x.Usb.fromC(&tmp.usb); err != nil {
+		return fmt.Errorf("converting field Usb: %v", err)
+	}
+	x.Usbversion = int(tmp.usbversion)
+	x.Usbdevice = C.GoString(tmp.usbdevice)
+	if err := x.VkbDevice.fromC(&tmp.vkb_device); err != nil {
+		return fmt.Errorf("converting field VkbDevice: %v", err)
+	}
+	x.Soundhw = C.GoString(tmp.soundhw)
+	if err := x.XenPlatformPci.fromC(&tmp.xen_platform_pci); err != nil {
+		return fmt.Errorf("converting field XenPlatformPci: %v", err)
+	}
+	if err := x.UsbdeviceList.fromC(&tmp.usbdevice_list); err != nil {
+		return fmt.Errorf("converting field UsbdeviceList: %v", err)
+	}
+	x.VendorDevice = VendorDevice(tmp.vendor_device)
+	if err := x.MsVmGenid.fromC(&tmp.ms_vm_genid); err != nil {
+		return fmt.Errorf("converting field MsVmGenid: %v", err)
+	}
+	if err := x.SerialList.fromC(&tmp.serial_list); err != nil {
+		return fmt.Errorf("converting field SerialList: %v", err)
+	}
+	if err := x.Rdm.fromC(&tmp.rdm); err != nil {
+		return fmt.Errorf("converting field Rdm: %v", err)
+	}
+	x.RdmMemBoundaryMemkb = uint64(tmp.rdm_mem_boundary_memkb)
+	x.McaCaps = uint64(tmp.mca_caps)
+	return nil
+}
+
+func (x *DomainBuildInfoTypeUnionPv) fromC(xc *C.libxl_domain_build_info) error {
+	if DomainType(xc._type) != DomainTypePv {
+		return errors.New("expected union key DomainTypePv")
+	}
+
+	tmp := (*C.libxl_domain_build_info_type_union_pv)(unsafe.Pointer(&xc.u[0]))
+	x.Kernel = C.GoString(tmp.kernel)
+	x.SlackMemkb = uint64(tmp.slack_memkb)
+	x.Bootloader = C.GoString(tmp.bootloader)
+	if err := x.BootloaderArgs.fromC(&tmp.bootloader_args); err != nil {
+		return fmt.Errorf("converting field BootloaderArgs: %v", err)
+	}
+	x.Cmdline = C.GoString(tmp.cmdline)
+	x.Ramdisk = C.GoString(tmp.ramdisk)
+	x.Features = C.GoString(tmp.features)
+	if err := x.E820Host.fromC(&tmp.e820_host); err != nil {
+		return fmt.Errorf("converting field E820Host: %v", err)
+	}
+	return nil
+}
+
+func (x *DomainBuildInfoTypeUnionPvh) fromC(xc *C.libxl_domain_build_info) error {
+	if DomainType(xc._type) != DomainTypePvh {
+		return errors.New("expected union key DomainTypePvh")
+	}
+
+	tmp := (*C.libxl_domain_build_info_type_union_pvh)(unsafe.Pointer(&xc.u[0]))
+	if err := x.Pvshim.fromC(&tmp.pvshim); err != nil {
+		return fmt.Errorf("converting field Pvshim: %v", err)
+	}
+	x.PvshimPath = C.GoString(tmp.pvshim_path)
+	x.PvshimCmdline = C.GoString(tmp.pvshim_cmdline)
+	x.PvshimExtra = C.GoString(tmp.pvshim_extra)
+	return nil
+}
+
+func (x *DomainBuildInfo) toC(xc *C.libxl_domain_build_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_domain_build_info_dispose(xc)
+		}
+	}()
+
+	xc.max_vcpus = C.int(x.MaxVcpus)
+	if err := x.AvailVcpus.toC(&xc.avail_vcpus); err != nil {
+		return fmt.Errorf("converting field AvailVcpus: %v", err)
+	}
+	if err := x.Cpumap.toC(&xc.cpumap); err != nil {
+		return fmt.Errorf("converting field Cpumap: %v", err)
+	}
+	if err := x.Nodemap.toC(&xc.nodemap); err != nil {
+		return fmt.Errorf("converting field Nodemap: %v", err)
+	}
+	if numVcpuHardAffinity := len(x.VcpuHardAffinity); numVcpuHardAffinity > 0 {
+		xc.vcpu_hard_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuHardAffinity) * C.sizeof_libxl_bitmap))
+		xc.num_vcpu_hard_affinity = C.int(numVcpuHardAffinity)
+		cVcpuHardAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:numVcpuHardAffinity:numVcpuHardAffinity]
+		for i, v := range x.VcpuHardAffinity {
+			if err := v.toC(&cVcpuHardAffinity[i]); err != nil {
+				return fmt.Errorf("converting field VcpuHardAffinity: %v", err)
+			}
+		}
+	}
+	if numVcpuSoftAffinity := len(x.VcpuSoftAffinity); numVcpuSoftAffinity > 0 {
+		xc.vcpu_soft_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuSoftAffinity) * C.sizeof_libxl_bitmap))
+		xc.num_vcpu_soft_affinity = C.int(numVcpuSoftAffinity)
+		cVcpuSoftAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:numVcpuSoftAffinity:numVcpuSoftAffinity]
+		for i, v := range x.VcpuSoftAffinity {
+			if err := v.toC(&cVcpuSoftAffinity[i]); err != nil {
+				return fmt.Errorf("converting field VcpuSoftAffinity: %v", err)
+			}
+		}
+	}
+	if err := x.NumaPlacement.toC(&xc.numa_placement); err != nil {
+		return fmt.Errorf("converting field NumaPlacement: %v", err)
+	}
+	xc.tsc_mode = C.libxl_tsc_mode(x.TscMode)
+	xc.max_memkb = C.uint64_t(x.MaxMemkb)
+	xc.target_memkb = C.uint64_t(x.TargetMemkb)
+	xc.video_memkb = C.uint64_t(x.VideoMemkb)
+	xc.shadow_memkb = C.uint64_t(x.ShadowMemkb)
+	xc.iommu_memkb = C.uint64_t(x.IommuMemkb)
+	xc.rtc_timeoffset = C.uint32_t(x.RtcTimeoffset)
+	xc.exec_ssidref = C.uint32_t(x.ExecSsidref)
+	if x.ExecSsidLabel != "" {
+		xc.exec_ssid_label = C.CString(x.ExecSsidLabel)
+	}
+	if err := x.Localtime.toC(&xc.localtime); err != nil {
+		return fmt.Errorf("converting field Localtime: %v", err)
+	}
+	if err := x.DisableMigrate.toC(&xc.disable_migrate); err != nil {
+		return fmt.Errorf("converting field DisableMigrate: %v", err)
+	}
+	if err := x.Cpuid.toC(&xc.cpuid); err != nil {
+		return fmt.Errorf("converting field Cpuid: %v", err)
+	}
+	if x.BlkdevStart != "" {
+		xc.blkdev_start = C.CString(x.BlkdevStart)
+	}
+	if numVnumaNodes := len(x.VnumaNodes); numVnumaNodes > 0 {
+		xc.vnuma_nodes = (*C.libxl_vnode_info)(C.malloc(C.ulong(numVnumaNodes) * C.sizeof_libxl_vnode_info))
+		xc.num_vnuma_nodes = C.int(numVnumaNodes)
+		cVnumaNodes := (*[1 << 28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:numVnumaNodes:numVnumaNodes]
+		for i, v := range x.VnumaNodes {
+			if err := v.toC(&cVnumaNodes[i]); err != nil {
+				return fmt.Errorf("converting field VnumaNodes: %v", err)
+			}
+		}
+	}
+	xc.max_grant_frames = C.uint32_t(x.MaxGrantFrames)
+	xc.max_maptrack_frames = C.uint32_t(x.MaxMaptrackFrames)
+	xc.device_model_version = C.libxl_device_model_version(x.DeviceModelVersion)
+	if err := x.DeviceModelStubdomain.toC(&xc.device_model_stubdomain); err != nil {
+		return fmt.Errorf("converting field DeviceModelStubdomain: %v", err)
+	}
+	if x.DeviceModel != "" {
+		xc.device_model = C.CString(x.DeviceModel)
+	}
+	xc.device_model_ssidref = C.uint32_t(x.DeviceModelSsidref)
+	if x.DeviceModelSsidLabel != "" {
+		xc.device_model_ssid_label = C.CString(x.DeviceModelSsidLabel)
+	}
+	if x.DeviceModelUser != "" {
+		xc.device_model_user = C.CString(x.DeviceModelUser)
+	}
+	if err := x.Extra.toC(&xc.extra); err != nil {
+		return fmt.Errorf("converting field Extra: %v", err)
+	}
+	if err := x.ExtraPv.toC(&xc.extra_pv); err != nil {
+		return fmt.Errorf("converting field ExtraPv: %v", err)
+	}
+	if err := x.ExtraHvm.toC(&xc.extra_hvm); err != nil {
+		return fmt.Errorf("converting field ExtraHvm: %v", err)
+	}
+	if err := x.SchedParams.toC(&xc.sched_params); err != nil {
+		return fmt.Errorf("converting field SchedParams: %v", err)
+	}
+	if numIoports := len(x.Ioports); numIoports > 0 {
+		xc.ioports = (*C.libxl_ioport_range)(C.malloc(C.ulong(numIoports) * C.sizeof_libxl_ioport_range))
+		xc.num_ioports = C.int(numIoports)
+		cIoports := (*[1 << 28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:numIoports:numIoports]
+		for i, v := range x.Ioports {
+			if err := v.toC(&cIoports[i]); err != nil {
+				return fmt.Errorf("converting field Ioports: %v", err)
+			}
+		}
+	}
+	if numIrqs := len(x.Irqs); numIrqs > 0 {
+		xc.irqs = (*C.uint32_t)(C.malloc(C.size_t(numIrqs * numIrqs)))
+		xc.num_irqs = C.int(numIrqs)
+		cIrqs := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:numIrqs:numIrqs]
+		for i, v := range x.Irqs {
+			cIrqs[i] = C.uint32_t(v)
+		}
+	}
+	if numIomem := len(x.Iomem); numIomem > 0 {
+		xc.iomem = (*C.libxl_iomem_range)(C.malloc(C.ulong(numIomem) * C.sizeof_libxl_iomem_range))
+		xc.num_iomem = C.int(numIomem)
+		cIomem := (*[1 << 28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:numIomem:numIomem]
+		for i, v := range x.Iomem {
+			if err := v.toC(&cIomem[i]); err != nil {
+				return fmt.Errorf("converting field Iomem: %v", err)
+			}
+		}
+	}
+	if err := x.ClaimMode.toC(&xc.claim_mode); err != nil {
+		return fmt.Errorf("converting field ClaimMode: %v", err)
+	}
+	xc.event_channels = C.uint32_t(x.EventChannels)
+	if x.Kernel != "" {
+		xc.kernel = C.CString(x.Kernel)
+	}
+	if x.Cmdline != "" {
+		xc.cmdline = C.CString(x.Cmdline)
+	}
+	if x.Ramdisk != "" {
+		xc.ramdisk = C.CString(x.Ramdisk)
+	}
+	if x.DeviceTree != "" {
+		xc.device_tree = C.CString(x.DeviceTree)
+	}
+	if err := x.Acpi.toC(&xc.acpi); err != nil {
+		return fmt.Errorf("converting field Acpi: %v", err)
+	}
+	if x.Bootloader != "" {
+		xc.bootloader = C.CString(x.Bootloader)
+	}
+	if err := x.BootloaderArgs.toC(&xc.bootloader_args); err != nil {
+		return fmt.Errorf("converting field BootloaderArgs: %v", err)
+	}
+	xc.timer_mode = C.libxl_timer_mode(x.TimerMode)
+	if err := x.NestedHvm.toC(&xc.nested_hvm); err != nil {
+		return fmt.Errorf("converting field NestedHvm: %v", err)
+	}
+	if err := x.Apic.toC(&xc.apic); err != nil {
+		return fmt.Errorf("converting field Apic: %v", err)
+	}
+	if err := x.DmRestrict.toC(&xc.dm_restrict); err != nil {
+		return fmt.Errorf("converting field DmRestrict: %v", err)
+	}
+	xc.tee = C.libxl_tee_type(x.Tee)
+	xc._type = C.libxl_domain_type(x.Type)
+	switch x.Type {
+	case DomainTypeHvm:
+		tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionHvm)
+		if !ok {
+			return errors.New("wrong type for union key type")
+		}
+		var hvm C.libxl_domain_build_info_type_union_hvm
+		if tmp.Firmware != "" {
+			hvm.firmware = C.CString(tmp.Firmware)
+		}
+		hvm.bios = C.libxl_bios_type(tmp.Bios)
+		if err := tmp.Pae.toC(&hvm.pae); err != nil {
+			return fmt.Errorf("converting field Pae: %v", err)
+		}
+		if err := tmp.Apic.toC(&hvm.apic); err != nil {
+			return fmt.Errorf("converting field Apic: %v", err)
+		}
+		if err := tmp.Acpi.toC(&hvm.acpi); err != nil {
+			return fmt.Errorf("converting field Acpi: %v", err)
+		}
+		if err := tmp.AcpiS3.toC(&hvm.acpi_s3); err != nil {
+			return fmt.Errorf("converting field AcpiS3: %v", err)
+		}
+		if err := tmp.AcpiS4.toC(&hvm.acpi_s4); err != nil {
+			return fmt.Errorf("converting field AcpiS4: %v", err)
+		}
+		if err := tmp.AcpiLaptopSlate.toC(&hvm.acpi_laptop_slate); err != nil {
+			return fmt.Errorf("converting field AcpiLaptopSlate: %v", err)
+		}
+		if err := tmp.Nx.toC(&hvm.nx); err != nil {
+			return fmt.Errorf("converting field Nx: %v", err)
+		}
+		if err := tmp.Viridian.toC(&hvm.viridian); err != nil {
+			return fmt.Errorf("converting field Viridian: %v", err)
+		}
+		if err := tmp.ViridianEnable.toC(&hvm.viridian_enable); err != nil {
+			return fmt.Errorf("converting field ViridianEnable: %v", err)
+		}
+		if err := tmp.ViridianDisable.toC(&hvm.viridian_disable); err != nil {
+			return fmt.Errorf("converting field ViridianDisable: %v", err)
+		}
+		if tmp.Timeoffset != "" {
+			hvm.timeoffset = C.CString(tmp.Timeoffset)
+		}
+		if err := tmp.Hpet.toC(&hvm.hpet); err != nil {
+			return fmt.Errorf("converting field Hpet: %v", err)
+		}
+		if err := tmp.VptAlign.toC(&hvm.vpt_align); err != nil {
+			return fmt.Errorf("converting field VptAlign: %v", err)
+		}
+		hvm.mmio_hole_memkb = C.uint64_t(tmp.MmioHoleMemkb)
+		hvm.timer_mode = C.libxl_timer_mode(tmp.TimerMode)
+		if err := tmp.NestedHvm.toC(&hvm.nested_hvm); err != nil {
+			return fmt.Errorf("converting field NestedHvm: %v", err)
+		}
+		if err := tmp.Altp2M.toC(&hvm.altp2m); err != nil {
+			return fmt.Errorf("converting field Altp2M: %v", err)
+		}
+		if tmp.SystemFirmware != "" {
+			hvm.system_firmware = C.CString(tmp.SystemFirmware)
+		}
+		if tmp.SmbiosFirmware != "" {
+			hvm.smbios_firmware = C.CString(tmp.SmbiosFirmware)
+		}
+		if tmp.AcpiFirmware != "" {
+			hvm.acpi_firmware = C.CString(tmp.AcpiFirmware)
+		}
+		hvm.hdtype = C.libxl_hdtype(tmp.Hdtype)
+		if err := tmp.Nographic.toC(&hvm.nographic); err != nil {
+			return fmt.Errorf("converting field Nographic: %v", err)
+		}
+		if err := tmp.Vga.toC(&hvm.vga); err != nil {
+			return fmt.Errorf("converting field Vga: %v", err)
+		}
+		if err := tmp.Vnc.toC(&hvm.vnc); err != nil {
+			return fmt.Errorf("converting field Vnc: %v", err)
+		}
+		if tmp.Keymap != "" {
+			hvm.keymap = C.CString(tmp.Keymap)
+		}
+		if err := tmp.Sdl.toC(&hvm.sdl); err != nil {
+			return fmt.Errorf("converting field Sdl: %v", err)
+		}
+		if err := tmp.Spice.toC(&hvm.spice); err != nil {
+			return fmt.Errorf("converting field Spice: %v", err)
+		}
+		if err := tmp.GfxPassthru.toC(&hvm.gfx_passthru); err != nil {
+			return fmt.Errorf("converting field GfxPassthru: %v", err)
+		}
+		hvm.gfx_passthru_kind = C.libxl_gfx_passthru_kind(tmp.GfxPassthruKind)
+		if tmp.Serial != "" {
+			hvm.serial = C.CString(tmp.Serial)
+		}
+		if tmp.Boot != "" {
+			hvm.boot = C.CString(tmp.Boot)
+		}
+		if err := tmp.Usb.toC(&hvm.usb); err != nil {
+			return fmt.Errorf("converting field Usb: %v", err)
+		}
+		hvm.usbversion = C.int(tmp.Usbversion)
+		if tmp.Usbdevice != "" {
+			hvm.usbdevice = C.CString(tmp.Usbdevice)
+		}
+		if err := tmp.VkbDevice.toC(&hvm.vkb_device); err != nil {
+			return fmt.Errorf("converting field VkbDevice: %v", err)
+		}
+		if tmp.Soundhw != "" {
+			hvm.soundhw = C.CString(tmp.Soundhw)
+		}
+		if err := tmp.XenPlatformPci.toC(&hvm.xen_platform_pci); err != nil {
+			return fmt.Errorf("converting field XenPlatformPci: %v", err)
+		}
+		if err := tmp.UsbdeviceList.toC(&hvm.usbdevice_list); err != nil {
+			return fmt.Errorf("converting field UsbdeviceList: %v", err)
+		}
+		hvm.vendor_device = C.libxl_vendor_device(tmp.VendorDevice)
+		if err := tmp.MsVmGenid.toC(&hvm.ms_vm_genid); err != nil {
+			return fmt.Errorf("converting field MsVmGenid: %v", err)
+		}
+		if err := tmp.SerialList.toC(&hvm.serial_list); err != nil {
+			return fmt.Errorf("converting field SerialList: %v", err)
+		}
+		if err := tmp.Rdm.toC(&hvm.rdm); err != nil {
+			return fmt.Errorf("converting field Rdm: %v", err)
+		}
+		hvm.rdm_mem_boundary_memkb = C.uint64_t(tmp.RdmMemBoundaryMemkb)
+		hvm.mca_caps = C.uint64_t(tmp.McaCaps)
+		hvmBytes := C.GoBytes(unsafe.Pointer(&hvm), C.sizeof_libxl_domain_build_info_type_union_hvm)
+		copy(xc.u[:], hvmBytes)
+	case DomainTypePv:
+		tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPv)
+		if !ok {
+			return errors.New("wrong type for union key type")
+		}
+		var pv C.libxl_domain_build_info_type_union_pv
+		if tmp.Kernel != "" {
+			pv.kernel = C.CString(tmp.Kernel)
+		}
+		pv.slack_memkb = C.uint64_t(tmp.SlackMemkb)
+		if tmp.Bootloader != "" {
+			pv.bootloader = C.CString(tmp.Bootloader)
+		}
+		if err := tmp.BootloaderArgs.toC(&pv.bootloader_args); err != nil {
+			return fmt.Errorf("converting field BootloaderArgs: %v", err)
+		}
+		if tmp.Cmdline != "" {
+			pv.cmdline = C.CString(tmp.Cmdline)
+		}
+		if tmp.Ramdisk != "" {
+			pv.ramdisk = C.CString(tmp.Ramdisk)
+		}
+		if tmp.Features != "" {
+			pv.features = C.CString(tmp.Features)
+		}
+		if err := tmp.E820Host.toC(&pv.e820_host); err != nil {
+			return fmt.Errorf("converting field E820Host: %v", err)
+		}
+		pvBytes := C.GoBytes(unsafe.Pointer(&pv), C.sizeof_libxl_domain_build_info_type_union_pv)
+		copy(xc.u[:], pvBytes)
+	case DomainTypePvh:
+		tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPvh)
+		if !ok {
+			return errors.New("wrong type for union key type")
+		}
+		var pvh C.libxl_domain_build_info_type_union_pvh
+		if err := tmp.Pvshim.toC(&pvh.pvshim); err != nil {
+			return fmt.Errorf("converting field Pvshim: %v", err)
+		}
+		if tmp.PvshimPath != "" {
+			pvh.pvshim_path = C.CString(tmp.PvshimPath)
+		}
+		if tmp.PvshimCmdline != "" {
+			pvh.pvshim_cmdline = C.CString(tmp.PvshimCmdline)
+		}
+		if tmp.PvshimExtra != "" {
+			pvh.pvshim_extra = C.CString(tmp.PvshimExtra)
+		}
+		pvhBytes := C.GoBytes(unsafe.Pointer(&pvh), C.sizeof_libxl_domain_build_info_type_union_pvh)
+		copy(xc.u[:], pvhBytes)
+	case DomainTypeInvalid:
+		break
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Type)
+	}
+	xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion)
+	xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart)
+	xc.altp2m = C.libxl_altp2m_mode(x.Altp2M)
+
+	return nil
+}
+
+// NewDeviceVfb returns an instance of DeviceVfb initialized with defaults.
+func NewDeviceVfb() (*DeviceVfb, error) {
+	var (
+		x  DeviceVfb
+		xc C.libxl_device_vfb
+	)
+
+	C.libxl_device_vfb_init(&xc)
+	defer C.libxl_device_vfb_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceVfb) fromC(xc *C.libxl_device_vfb) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.Devid = Devid(xc.devid)
+	if err := x.Vnc.fromC(&xc.vnc); err != nil {
+		return fmt.Errorf("converting field Vnc: %v", err)
+	}
+	if err := x.Sdl.fromC(&xc.sdl); err != nil {
+		return fmt.Errorf("converting field Sdl: %v", err)
+	}
+	x.Keymap = C.GoString(xc.keymap)
+
+	return nil
+}
+
+func (x *DeviceVfb) toC(xc *C.libxl_device_vfb) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_vfb_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	xc.devid = C.libxl_devid(x.Devid)
+	if err := x.Vnc.toC(&xc.vnc); err != nil {
+		return fmt.Errorf("converting field Vnc: %v", err)
+	}
+	if err := x.Sdl.toC(&xc.sdl); err != nil {
+		return fmt.Errorf("converting field Sdl: %v", err)
+	}
+	if x.Keymap != "" {
+		xc.keymap = C.CString(x.Keymap)
+	}
+
+	return nil
+}
+
+// NewDeviceVkb returns an instance of DeviceVkb initialized with defaults.
+func NewDeviceVkb() (*DeviceVkb, error) {
+	var (
+		x  DeviceVkb
+		xc C.libxl_device_vkb
+	)
+
+	C.libxl_device_vkb_init(&xc)
+	defer C.libxl_device_vkb_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceVkb) fromC(xc *C.libxl_device_vkb) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.Devid = Devid(xc.devid)
+	x.BackendType = VkbBackend(xc.backend_type)
+	x.UniqueId = C.GoString(xc.unique_id)
+	x.FeatureDisableKeyboard = bool(xc.feature_disable_keyboard)
+	x.FeatureDisablePointer = bool(xc.feature_disable_pointer)
+	x.FeatureAbsPointer = bool(xc.feature_abs_pointer)
+	x.FeatureRawPointer = bool(xc.feature_raw_pointer)
+	x.FeatureMultiTouch = bool(xc.feature_multi_touch)
+	x.Width = uint32(xc.width)
+	x.Height = uint32(xc.height)
+	x.MultiTouchWidth = uint32(xc.multi_touch_width)
+	x.MultiTouchHeight = uint32(xc.multi_touch_height)
+	x.MultiTouchNumContacts = uint32(xc.multi_touch_num_contacts)
+
+	return nil
+}
+
+func (x *DeviceVkb) toC(xc *C.libxl_device_vkb) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_vkb_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.backend_type = C.libxl_vkb_backend(x.BackendType)
+	if x.UniqueId != "" {
+		xc.unique_id = C.CString(x.UniqueId)
+	}
+	xc.feature_disable_keyboard = C.bool(x.FeatureDisableKeyboard)
+	xc.feature_disable_pointer = C.bool(x.FeatureDisablePointer)
+	xc.feature_abs_pointer = C.bool(x.FeatureAbsPointer)
+	xc.feature_raw_pointer = C.bool(x.FeatureRawPointer)
+	xc.feature_multi_touch = C.bool(x.FeatureMultiTouch)
+	xc.width = C.uint32_t(x.Width)
+	xc.height = C.uint32_t(x.Height)
+	xc.multi_touch_width = C.uint32_t(x.MultiTouchWidth)
+	xc.multi_touch_height = C.uint32_t(x.MultiTouchHeight)
+	xc.multi_touch_num_contacts = C.uint32_t(x.MultiTouchNumContacts)
+
+	return nil
+}
+
+// NewDeviceDisk returns an instance of DeviceDisk initialized with defaults.
+func NewDeviceDisk() (*DeviceDisk, error) {
+	var (
+		x  DeviceDisk
+		xc C.libxl_device_disk
+	)
+
+	C.libxl_device_disk_init(&xc)
+	defer C.libxl_device_disk_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceDisk) fromC(xc *C.libxl_device_disk) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.PdevPath = C.GoString(xc.pdev_path)
+	x.Vdev = C.GoString(xc.vdev)
+	x.Backend = DiskBackend(xc.backend)
+	x.Format = DiskFormat(xc.format)
+	x.Script = C.GoString(xc.script)
+	x.Removable = int(xc.removable)
+	x.Readwrite = int(xc.readwrite)
+	x.IsCdrom = int(xc.is_cdrom)
+	x.DirectIoSafe = bool(xc.direct_io_safe)
+	if err := x.DiscardEnable.fromC(&xc.discard_enable); err != nil {
+		return fmt.Errorf("converting field DiscardEnable: %v", err)
+	}
+	if err := x.ColoEnable.fromC(&xc.colo_enable); err != nil {
+		return fmt.Errorf("converting field ColoEnable: %v", err)
+	}
+	if err := x.ColoRestoreEnable.fromC(&xc.colo_restore_enable); err != nil {
+		return fmt.Errorf("converting field ColoRestoreEnable: %v", err)
+	}
+	x.ColoHost = C.GoString(xc.colo_host)
+	x.ColoPort = int(xc.colo_port)
+	x.ColoExport = C.GoString(xc.colo_export)
+	x.ActiveDisk = C.GoString(xc.active_disk)
+	x.HiddenDisk = C.GoString(xc.hidden_disk)
+
+	return nil
+}
+
+func (x *DeviceDisk) toC(xc *C.libxl_device_disk) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_disk_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	if x.PdevPath != "" {
+		xc.pdev_path = C.CString(x.PdevPath)
+	}
+	if x.Vdev != "" {
+		xc.vdev = C.CString(x.Vdev)
+	}
+	xc.backend = C.libxl_disk_backend(x.Backend)
+	xc.format = C.libxl_disk_format(x.Format)
+	if x.Script != "" {
+		xc.script = C.CString(x.Script)
+	}
+	xc.removable = C.int(x.Removable)
+	xc.readwrite = C.int(x.Readwrite)
+	xc.is_cdrom = C.int(x.IsCdrom)
+	xc.direct_io_safe = C.bool(x.DirectIoSafe)
+	if err := x.DiscardEnable.toC(&xc.discard_enable); err != nil {
+		return fmt.Errorf("converting field DiscardEnable: %v", err)
+	}
+	if err := x.ColoEnable.toC(&xc.colo_enable); err != nil {
+		return fmt.Errorf("converting field ColoEnable: %v", err)
+	}
+	if err := x.ColoRestoreEnable.toC(&xc.colo_restore_enable); err != nil {
+		return fmt.Errorf("converting field ColoRestoreEnable: %v", err)
+	}
+	if x.ColoHost != "" {
+		xc.colo_host = C.CString(x.ColoHost)
+	}
+	xc.colo_port = C.int(x.ColoPort)
+	if x.ColoExport != "" {
+		xc.colo_export = C.CString(x.ColoExport)
+	}
+	if x.ActiveDisk != "" {
+		xc.active_disk = C.CString(x.ActiveDisk)
+	}
+	if x.HiddenDisk != "" {
+		xc.hidden_disk = C.CString(x.HiddenDisk)
+	}
+
+	return nil
+}
+
+// NewDeviceNic returns an instance of DeviceNic initialized with defaults.
+func NewDeviceNic() (*DeviceNic, error) {
+	var (
+		x  DeviceNic
+		xc C.libxl_device_nic
+	)
+
+	C.libxl_device_nic_init(&xc)
+	defer C.libxl_device_nic_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceNic) fromC(xc *C.libxl_device_nic) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.Devid = Devid(xc.devid)
+	x.Mtu = int(xc.mtu)
+	x.Model = C.GoString(xc.model)
+	if err := x.Mac.fromC(&xc.mac); err != nil {
+		return fmt.Errorf("converting field Mac: %v", err)
+	}
+	x.Ip = C.GoString(xc.ip)
+	x.Bridge = C.GoString(xc.bridge)
+	x.Ifname = C.GoString(xc.ifname)
+	x.Script = C.GoString(xc.script)
+	x.Nictype = NicType(xc.nictype)
+	x.RateBytesPerInterval = uint64(xc.rate_bytes_per_interval)
+	x.RateIntervalUsecs = uint32(xc.rate_interval_usecs)
+	x.Gatewaydev = C.GoString(xc.gatewaydev)
+	x.ColoftForwarddev = C.GoString(xc.coloft_forwarddev)
+	x.ColoSockMirrorId = C.GoString(xc.colo_sock_mirror_id)
+	x.ColoSockMirrorIp = C.GoString(xc.colo_sock_mirror_ip)
+	x.ColoSockMirrorPort = C.GoString(xc.colo_sock_mirror_port)
+	x.ColoSockComparePriInId = C.GoString(xc.colo_sock_compare_pri_in_id)
+	x.ColoSockComparePriInIp = C.GoString(xc.colo_sock_compare_pri_in_ip)
+	x.ColoSockComparePriInPort = C.GoString(xc.colo_sock_compare_pri_in_port)
+	x.ColoSockCompareSecInId = C.GoString(xc.colo_sock_compare_sec_in_id)
+	x.ColoSockCompareSecInIp = C.GoString(xc.colo_sock_compare_sec_in_ip)
+	x.ColoSockCompareSecInPort = C.GoString(xc.colo_sock_compare_sec_in_port)
+	x.ColoSockCompareNotifyId = C.GoString(xc.colo_sock_compare_notify_id)
+	x.ColoSockCompareNotifyIp = C.GoString(xc.colo_sock_compare_notify_ip)
+	x.ColoSockCompareNotifyPort = C.GoString(xc.colo_sock_compare_notify_port)
+	x.ColoSockRedirector0Id = C.GoString(xc.colo_sock_redirector0_id)
+	x.ColoSockRedirector0Ip = C.GoString(xc.colo_sock_redirector0_ip)
+	x.ColoSockRedirector0Port = C.GoString(xc.colo_sock_redirector0_port)
+	x.ColoSockRedirector1Id = C.GoString(xc.colo_sock_redirector1_id)
+	x.ColoSockRedirector1Ip = C.GoString(xc.colo_sock_redirector1_ip)
+	x.ColoSockRedirector1Port = C.GoString(xc.colo_sock_redirector1_port)
+	x.ColoSockRedirector2Id = C.GoString(xc.colo_sock_redirector2_id)
+	x.ColoSockRedirector2Ip = C.GoString(xc.colo_sock_redirector2_ip)
+	x.ColoSockRedirector2Port = C.GoString(xc.colo_sock_redirector2_port)
+	x.ColoFilterMirrorQueue = C.GoString(xc.colo_filter_mirror_queue)
+	x.ColoFilterMirrorOutdev = C.GoString(xc.colo_filter_mirror_outdev)
+	x.ColoFilterRedirector0Queue = C.GoString(xc.colo_filter_redirector0_queue)
+	x.ColoFilterRedirector0Indev = C.GoString(xc.colo_filter_redirector0_indev)
+	x.ColoFilterRedirector0Outdev = C.GoString(xc.colo_filter_redirector0_outdev)
+	x.ColoFilterRedirector1Queue = C.GoString(xc.colo_filter_redirector1_queue)
+	x.ColoFilterRedirector1Indev = C.GoString(xc.colo_filter_redirector1_indev)
+	x.ColoFilterRedirector1Outdev = C.GoString(xc.colo_filter_redirector1_outdev)
+	x.ColoComparePriIn = C.GoString(xc.colo_compare_pri_in)
+	x.ColoCompareSecIn = C.GoString(xc.colo_compare_sec_in)
+	x.ColoCompareOut = C.GoString(xc.colo_compare_out)
+	x.ColoCompareNotifyDev = C.GoString(xc.colo_compare_notify_dev)
+	x.ColoSockSecRedirector0Id = C.GoString(xc.colo_sock_sec_redirector0_id)
+	x.ColoSockSecRedirector0Ip = C.GoString(xc.colo_sock_sec_redirector0_ip)
+	x.ColoSockSecRedirector0Port = C.GoString(xc.colo_sock_sec_redirector0_port)
+	x.ColoSockSecRedirector1Id = C.GoString(xc.colo_sock_sec_redirector1_id)
+	x.ColoSockSecRedirector1Ip = C.GoString(xc.colo_sock_sec_redirector1_ip)
+	x.ColoSockSecRedirector1Port = C.GoString(xc.colo_sock_sec_redirector1_port)
+	x.ColoFilterSecRedirector0Queue = C.GoString(xc.colo_filter_sec_redirector0_queue)
+	x.ColoFilterSecRedirector0Indev = C.GoString(xc.colo_filter_sec_redirector0_indev)
+	x.ColoFilterSecRedirector0Outdev = C.GoString(xc.colo_filter_sec_redirector0_outdev)
+	x.ColoFilterSecRedirector1Queue = C.GoString(xc.colo_filter_sec_redirector1_queue)
+	x.ColoFilterSecRedirector1Indev = C.GoString(xc.colo_filter_sec_redirector1_indev)
+	x.ColoFilterSecRedirector1Outdev = C.GoString(xc.colo_filter_sec_redirector1_outdev)
+	x.ColoFilterSecRewriter0Queue = C.GoString(xc.colo_filter_sec_rewriter0_queue)
+	x.ColoCheckpointHost = C.GoString(xc.colo_checkpoint_host)
+	x.ColoCheckpointPort = C.GoString(xc.colo_checkpoint_port)
+
+	return nil
+}
+
+func (x *DeviceNic) toC(xc *C.libxl_device_nic) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_nic_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.mtu = C.int(x.Mtu)
+	if x.Model != "" {
+		xc.model = C.CString(x.Model)
+	}
+	if err := x.Mac.toC(&xc.mac); err != nil {
+		return fmt.Errorf("converting field Mac: %v", err)
+	}
+	if x.Ip != "" {
+		xc.ip = C.CString(x.Ip)
+	}
+	if x.Bridge != "" {
+		xc.bridge = C.CString(x.Bridge)
+	}
+	if x.Ifname != "" {
+		xc.ifname = C.CString(x.Ifname)
+	}
+	if x.Script != "" {
+		xc.script = C.CString(x.Script)
+	}
+	xc.nictype = C.libxl_nic_type(x.Nictype)
+	xc.rate_bytes_per_interval = C.uint64_t(x.RateBytesPerInterval)
+	xc.rate_interval_usecs = C.uint32_t(x.RateIntervalUsecs)
+	if x.Gatewaydev != "" {
+		xc.gatewaydev = C.CString(x.Gatewaydev)
+	}
+	if x.ColoftForwarddev != "" {
+		xc.coloft_forwarddev = C.CString(x.ColoftForwarddev)
+	}
+	if x.ColoSockMirrorId != "" {
+		xc.colo_sock_mirror_id = C.CString(x.ColoSockMirrorId)
+	}
+	if x.ColoSockMirrorIp != "" {
+		xc.colo_sock_mirror_ip = C.CString(x.ColoSockMirrorIp)
+	}
+	if x.ColoSockMirrorPort != "" {
+		xc.colo_sock_mirror_port = C.CString(x.ColoSockMirrorPort)
+	}
+	if x.ColoSockComparePriInId != "" {
+		xc.colo_sock_compare_pri_in_id = C.CString(x.ColoSockComparePriInId)
+	}
+	if x.ColoSockComparePriInIp != "" {
+		xc.colo_sock_compare_pri_in_ip = C.CString(x.ColoSockComparePriInIp)
+	}
+	if x.ColoSockComparePriInPort != "" {
+		xc.colo_sock_compare_pri_in_port = C.CString(x.ColoSockComparePriInPort)
+	}
+	if x.ColoSockCompareSecInId != "" {
+		xc.colo_sock_compare_sec_in_id = C.CString(x.ColoSockCompareSecInId)
+	}
+	if x.ColoSockCompareSecInIp != "" {
+		xc.colo_sock_compare_sec_in_ip = C.CString(x.ColoSockCompareSecInIp)
+	}
+	if x.ColoSockCompareSecInPort != "" {
+		xc.colo_sock_compare_sec_in_port = C.CString(x.ColoSockCompareSecInPort)
+	}
+	if x.ColoSockCompareNotifyId != "" {
+		xc.colo_sock_compare_notify_id = C.CString(x.ColoSockCompareNotifyId)
+	}
+	if x.ColoSockCompareNotifyIp != "" {
+		xc.colo_sock_compare_notify_ip = C.CString(x.ColoSockCompareNotifyIp)
+	}
+	if x.ColoSockCompareNotifyPort != "" {
+		xc.colo_sock_compare_notify_port = C.CString(x.ColoSockCompareNotifyPort)
+	}
+	if x.ColoSockRedirector0Id != "" {
+		xc.colo_sock_redirector0_id = C.CString(x.ColoSockRedirector0Id)
+	}
+	if x.ColoSockRedirector0Ip != "" {
+		xc.colo_sock_redirector0_ip = C.CString(x.ColoSockRedirector0Ip)
+	}
+	if x.ColoSockRedirector0Port != "" {
+		xc.colo_sock_redirector0_port = C.CString(x.ColoSockRedirector0Port)
+	}
+	if x.ColoSockRedirector1Id != "" {
+		xc.colo_sock_redirector1_id = C.CString(x.ColoSockRedirector1Id)
+	}
+	if x.ColoSockRedirector1Ip != "" {
+		xc.colo_sock_redirector1_ip = C.CString(x.ColoSockRedirector1Ip)
+	}
+	if x.ColoSockRedirector1Port != "" {
+		xc.colo_sock_redirector1_port = C.CString(x.ColoSockRedirector1Port)
+	}
+	if x.ColoSockRedirector2Id != "" {
+		xc.colo_sock_redirector2_id = C.CString(x.ColoSockRedirector2Id)
+	}
+	if x.ColoSockRedirector2Ip != "" {
+		xc.colo_sock_redirector2_ip = C.CString(x.ColoSockRedirector2Ip)
+	}
+	if x.ColoSockRedirector2Port != "" {
+		xc.colo_sock_redirector2_port = C.CString(x.ColoSockRedirector2Port)
+	}
+	if x.ColoFilterMirrorQueue != "" {
+		xc.colo_filter_mirror_queue = C.CString(x.ColoFilterMirrorQueue)
+	}
+	if x.ColoFilterMirrorOutdev != "" {
+		xc.colo_filter_mirror_outdev = C.CString(x.ColoFilterMirrorOutdev)
+	}
+	if x.ColoFilterRedirector0Queue != "" {
+		xc.colo_filter_redirector0_queue = C.CString(x.ColoFilterRedirector0Queue)
+	}
+	if x.ColoFilterRedirector0Indev != "" {
+		xc.colo_filter_redirector0_indev = C.CString(x.ColoFilterRedirector0Indev)
+	}
+	if x.ColoFilterRedirector0Outdev != "" {
+		xc.colo_filter_redirector0_outdev = C.CString(x.ColoFilterRedirector0Outdev)
+	}
+	if x.ColoFilterRedirector1Queue != "" {
+		xc.colo_filter_redirector1_queue = C.CString(x.ColoFilterRedirector1Queue)
+	}
+	if x.ColoFilterRedirector1Indev != "" {
+		xc.colo_filter_redirector1_indev = C.CString(x.ColoFilterRedirector1Indev)
+	}
+	if x.ColoFilterRedirector1Outdev != "" {
+		xc.colo_filter_redirector1_outdev = C.CString(x.ColoFilterRedirector1Outdev)
+	}
+	if x.ColoComparePriIn != "" {
+		xc.colo_compare_pri_in = C.CString(x.ColoComparePriIn)
+	}
+	if x.ColoCompareSecIn != "" {
+		xc.colo_compare_sec_in = C.CString(x.ColoCompareSecIn)
+	}
+	if x.ColoCompareOut != "" {
+		xc.colo_compare_out = C.CString(x.ColoCompareOut)
+	}
+	if x.ColoCompareNotifyDev != "" {
+		xc.colo_compare_notify_dev = C.CString(x.ColoCompareNotifyDev)
+	}
+	if x.ColoSockSecRedirector0Id != "" {
+		xc.colo_sock_sec_redirector0_id = C.CString(x.ColoSockSecRedirector0Id)
+	}
+	if x.ColoSockSecRedirector0Ip != "" {
+		xc.colo_sock_sec_redirector0_ip = C.CString(x.ColoSockSecRedirector0Ip)
+	}
+	if x.ColoSockSecRedirector0Port != "" {
+		xc.colo_sock_sec_redirector0_port = C.CString(x.ColoSockSecRedirector0Port)
+	}
+	if x.ColoSockSecRedirector1Id != "" {
+		xc.colo_sock_sec_redirector1_id = C.CString(x.ColoSockSecRedirector1Id)
+	}
+	if x.ColoSockSecRedirector1Ip != "" {
+		xc.colo_sock_sec_redirector1_ip = C.CString(x.ColoSockSecRedirector1Ip)
+	}
+	if x.ColoSockSecRedirector1Port != "" {
+		xc.colo_sock_sec_redirector1_port = C.CString(x.ColoSockSecRedirector1Port)
+	}
+	if x.ColoFilterSecRedirector0Queue != "" {
+		xc.colo_filter_sec_redirector0_queue = C.CString(x.ColoFilterSecRedirector0Queue)
+	}
+	if x.ColoFilterSecRedirector0Indev != "" {
+		xc.colo_filter_sec_redirector0_indev = C.CString(x.ColoFilterSecRedirector0Indev)
+	}
+	if x.ColoFilterSecRedirector0Outdev != "" {
+		xc.colo_filter_sec_redirector0_outdev = C.CString(x.ColoFilterSecRedirector0Outdev)
+	}
+	if x.ColoFilterSecRedirector1Queue != "" {
+		xc.colo_filter_sec_redirector1_queue = C.CString(x.ColoFilterSecRedirector1Queue)
+	}
+	if x.ColoFilterSecRedirector1Indev != "" {
+		xc.colo_filter_sec_redirector1_indev = C.CString(x.ColoFilterSecRedirector1Indev)
+	}
+	if x.ColoFilterSecRedirector1Outdev != "" {
+		xc.colo_filter_sec_redirector1_outdev = C.CString(x.ColoFilterSecRedirector1Outdev)
+	}
+	if x.ColoFilterSecRewriter0Queue != "" {
+		xc.colo_filter_sec_rewriter0_queue = C.CString(x.ColoFilterSecRewriter0Queue)
+	}
+	if x.ColoCheckpointHost != "" {
+		xc.colo_checkpoint_host = C.CString(x.ColoCheckpointHost)
+	}
+	if x.ColoCheckpointPort != "" {
+		xc.colo_checkpoint_port = C.CString(x.ColoCheckpointPort)
+	}
+
+	return nil
+}
+
+// NewDevicePci returns an instance of DevicePci initialized with defaults.
+func NewDevicePci() (*DevicePci, error) {
+	var (
+		x  DevicePci
+		xc C.libxl_device_pci
+	)
+
+	C.libxl_device_pci_init(&xc)
+	defer C.libxl_device_pci_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DevicePci) fromC(xc *C.libxl_device_pci) error {
+	x.Func = byte(xc._func)
+	x.Dev = byte(xc.dev)
+	x.Bus = byte(xc.bus)
+	x.Domain = int(xc.domain)
+	x.Vdevfn = uint32(xc.vdevfn)
+	x.VfuncMask = uint32(xc.vfunc_mask)
+	x.Msitranslate = bool(xc.msitranslate)
+	x.PowerMgmt = bool(xc.power_mgmt)
+	x.Permissive = bool(xc.permissive)
+	x.Seize = bool(xc.seize)
+	x.RdmPolicy = RdmReservePolicy(xc.rdm_policy)
+
+	return nil
+}
+
+func (x *DevicePci) toC(xc *C.libxl_device_pci) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_pci_dispose(xc)
+		}
+	}()
+
+	xc._func = C.uint8_t(x.Func)
+	xc.dev = C.uint8_t(x.Dev)
+	xc.bus = C.uint8_t(x.Bus)
+	xc.domain = C.int(x.Domain)
+	xc.vdevfn = C.uint32_t(x.Vdevfn)
+	xc.vfunc_mask = C.uint32_t(x.VfuncMask)
+	xc.msitranslate = C.bool(x.Msitranslate)
+	xc.power_mgmt = C.bool(x.PowerMgmt)
+	xc.permissive = C.bool(x.Permissive)
+	xc.seize = C.bool(x.Seize)
+	xc.rdm_policy = C.libxl_rdm_reserve_policy(x.RdmPolicy)
+
+	return nil
+}
+
+// NewDeviceRdm returns an instance of DeviceRdm initialized with defaults.
+func NewDeviceRdm() (*DeviceRdm, error) {
+	var (
+		x  DeviceRdm
+		xc C.libxl_device_rdm
+	)
+
+	C.libxl_device_rdm_init(&xc)
+	defer C.libxl_device_rdm_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceRdm) fromC(xc *C.libxl_device_rdm) error {
+	x.Start = uint64(xc.start)
+	x.Size = uint64(xc.size)
+	x.Policy = RdmReservePolicy(xc.policy)
+
+	return nil
+}
+
+func (x *DeviceRdm) toC(xc *C.libxl_device_rdm) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_rdm_dispose(xc)
+		}
+	}()
+
+	xc.start = C.uint64_t(x.Start)
+	xc.size = C.uint64_t(x.Size)
+	xc.policy = C.libxl_rdm_reserve_policy(x.Policy)
+
+	return nil
+}
+
+// NewDeviceUsbctrl returns an instance of DeviceUsbctrl initialized with defaults.
+func NewDeviceUsbctrl() (*DeviceUsbctrl, error) {
+	var (
+		x  DeviceUsbctrl
+		xc C.libxl_device_usbctrl
+	)
+
+	C.libxl_device_usbctrl_init(&xc)
+	defer C.libxl_device_usbctrl_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceUsbctrl) fromC(xc *C.libxl_device_usbctrl) error {
+	x.Type = UsbctrlType(xc._type)
+	x.Devid = Devid(xc.devid)
+	x.Version = int(xc.version)
+	x.Ports = int(xc.ports)
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+
+	return nil
+}
+
+func (x *DeviceUsbctrl) toC(xc *C.libxl_device_usbctrl) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_usbctrl_dispose(xc)
+		}
+	}()
+
+	xc._type = C.libxl_usbctrl_type(x.Type)
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.version = C.int(x.Version)
+	xc.ports = C.int(x.Ports)
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+
+	return nil
+}
+
+// NewDeviceUsbdev returns an instance of DeviceUsbdev initialized with defaults.
+func NewDeviceUsbdev(utype UsbdevType) (*DeviceUsbdev, error) {
+	var (
+		x  DeviceUsbdev
+		xc C.libxl_device_usbdev
+	)
+
+	C.libxl_device_usbdev_init(&xc)
+	C.libxl_device_usbdev_init_type(&xc, C.libxl_usbdev_type(utype))
+	defer C.libxl_device_usbdev_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceUsbdev) fromC(xc *C.libxl_device_usbdev) error {
+	x.Ctrl = Devid(xc.ctrl)
+	x.Port = int(xc.port)
+	x.Type = UsbdevType(xc._type)
+	switch x.Type {
+	case UsbdevTypeHostdev:
+		var typeHostdev DeviceUsbdevTypeUnionHostdev
+		if err := typeHostdev.fromC(xc); err != nil {
+			return fmt.Errorf("converting field typeHostdev: %v", err)
+		}
+		x.TypeUnion = typeHostdev
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Type)
+	}
+
+	return nil
+}
+
+func (x *DeviceUsbdevTypeUnionHostdev) fromC(xc *C.libxl_device_usbdev) error {
+	if UsbdevType(xc._type) != UsbdevTypeHostdev {
+		return errors.New("expected union key UsbdevTypeHostdev")
+	}
+
+	tmp := (*C.libxl_device_usbdev_type_union_hostdev)(unsafe.Pointer(&xc.u[0]))
+	x.Hostbus = byte(tmp.hostbus)
+	x.Hostaddr = byte(tmp.hostaddr)
+	return nil
+}
+
+func (x *DeviceUsbdev) toC(xc *C.libxl_device_usbdev) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_usbdev_dispose(xc)
+		}
+	}()
+
+	xc.ctrl = C.libxl_devid(x.Ctrl)
+	xc.port = C.int(x.Port)
+	xc._type = C.libxl_usbdev_type(x.Type)
+	switch x.Type {
+	case UsbdevTypeHostdev:
+		tmp, ok := x.TypeUnion.(DeviceUsbdevTypeUnionHostdev)
+		if !ok {
+			return errors.New("wrong type for union key type")
+		}
+		var hostdev C.libxl_device_usbdev_type_union_hostdev
+		hostdev.hostbus = C.uint8_t(tmp.Hostbus)
+		hostdev.hostaddr = C.uint8_t(tmp.Hostaddr)
+		hostdevBytes := C.GoBytes(unsafe.Pointer(&hostdev), C.sizeof_libxl_device_usbdev_type_union_hostdev)
+		copy(xc.u[:], hostdevBytes)
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Type)
+	}
+
+	return nil
+}
+
+// NewDeviceDtdev returns an instance of DeviceDtdev initialized with defaults.
+func NewDeviceDtdev() (*DeviceDtdev, error) {
+	var (
+		x  DeviceDtdev
+		xc C.libxl_device_dtdev
+	)
+
+	C.libxl_device_dtdev_init(&xc)
+	defer C.libxl_device_dtdev_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceDtdev) fromC(xc *C.libxl_device_dtdev) error {
+	x.Path = C.GoString(xc.path)
+
+	return nil
+}
+
+func (x *DeviceDtdev) toC(xc *C.libxl_device_dtdev) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_dtdev_dispose(xc)
+		}
+	}()
+
+	if x.Path != "" {
+		xc.path = C.CString(x.Path)
+	}
+
+	return nil
+}
+
+// NewDeviceVtpm returns an instance of DeviceVtpm initialized with defaults.
+func NewDeviceVtpm() (*DeviceVtpm, error) {
+	var (
+		x  DeviceVtpm
+		xc C.libxl_device_vtpm
+	)
+
+	C.libxl_device_vtpm_init(&xc)
+	defer C.libxl_device_vtpm_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceVtpm) fromC(xc *C.libxl_device_vtpm) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.Devid = Devid(xc.devid)
+	if err := x.Uuid.fromC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+
+	return nil
+}
+
+func (x *DeviceVtpm) toC(xc *C.libxl_device_vtpm) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_vtpm_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	xc.devid = C.libxl_devid(x.Devid)
+	if err := x.Uuid.toC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+
+	return nil
+}
+
+// NewDeviceP9 returns an instance of DeviceP9 initialized with defaults.
+func NewDeviceP9() (*DeviceP9, error) {
+	var (
+		x  DeviceP9
+		xc C.libxl_device_p9
+	)
+
+	C.libxl_device_p9_init(&xc)
+	defer C.libxl_device_p9_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceP9) fromC(xc *C.libxl_device_p9) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.Tag = C.GoString(xc.tag)
+	x.Path = C.GoString(xc.path)
+	x.SecurityModel = C.GoString(xc.security_model)
+	x.Devid = Devid(xc.devid)
+
+	return nil
+}
+
+func (x *DeviceP9) toC(xc *C.libxl_device_p9) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_p9_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	if x.Tag != "" {
+		xc.tag = C.CString(x.Tag)
+	}
+	if x.Path != "" {
+		xc.path = C.CString(x.Path)
+	}
+	if x.SecurityModel != "" {
+		xc.security_model = C.CString(x.SecurityModel)
+	}
+	xc.devid = C.libxl_devid(x.Devid)
+
+	return nil
+}
+
+// NewDevicePvcallsif returns an instance of DevicePvcallsif initialized with defaults.
+func NewDevicePvcallsif() (*DevicePvcallsif, error) {
+	var (
+		x  DevicePvcallsif
+		xc C.libxl_device_pvcallsif
+	)
+
+	C.libxl_device_pvcallsif_init(&xc)
+	defer C.libxl_device_pvcallsif_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DevicePvcallsif) fromC(xc *C.libxl_device_pvcallsif) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.Devid = Devid(xc.devid)
+
+	return nil
+}
+
+func (x *DevicePvcallsif) toC(xc *C.libxl_device_pvcallsif) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_pvcallsif_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	xc.devid = C.libxl_devid(x.Devid)
+
+	return nil
+}
+
+// NewDeviceChannel returns an instance of DeviceChannel initialized with defaults.
+func NewDeviceChannel(connection ChannelConnection) (*DeviceChannel, error) {
+	var (
+		x  DeviceChannel
+		xc C.libxl_device_channel
+	)
+
+	C.libxl_device_channel_init(&xc)
+	C.libxl_device_channel_init_connection(&xc, C.libxl_channel_connection(connection))
+	defer C.libxl_device_channel_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceChannel) fromC(xc *C.libxl_device_channel) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.Devid = Devid(xc.devid)
+	x.Name = C.GoString(xc.name)
+	x.Connection = ChannelConnection(xc.connection)
+	switch x.Connection {
+	case ChannelConnectionUnknown:
+		x.ConnectionUnion = nil
+	case ChannelConnectionPty:
+		x.ConnectionUnion = nil
+	case ChannelConnectionSocket:
+		var connectionSocket DeviceChannelConnectionUnionSocket
+		if err := connectionSocket.fromC(xc); err != nil {
+			return fmt.Errorf("converting field connectionSocket: %v", err)
+		}
+		x.ConnectionUnion = connectionSocket
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Connection)
+	}
+
+	return nil
+}
+
+func (x *DeviceChannelConnectionUnionSocket) fromC(xc *C.libxl_device_channel) error {
+	if ChannelConnection(xc.connection) != ChannelConnectionSocket {
+		return errors.New("expected union key ChannelConnectionSocket")
+	}
+
+	tmp := (*C.libxl_device_channel_connection_union_socket)(unsafe.Pointer(&xc.u[0]))
+	x.Path = C.GoString(tmp.path)
+	return nil
+}
+
+func (x *DeviceChannel) toC(xc *C.libxl_device_channel) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_channel_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	xc.devid = C.libxl_devid(x.Devid)
+	if x.Name != "" {
+		xc.name = C.CString(x.Name)
+	}
+	xc.connection = C.libxl_channel_connection(x.Connection)
+	switch x.Connection {
+	case ChannelConnectionUnknown:
+		break
+	case ChannelConnectionPty:
+		break
+	case ChannelConnectionSocket:
+		tmp, ok := x.ConnectionUnion.(DeviceChannelConnectionUnionSocket)
+		if !ok {
+			return errors.New("wrong type for union key connection")
+		}
+		var socket C.libxl_device_channel_connection_union_socket
+		if tmp.Path != "" {
+			socket.path = C.CString(tmp.Path)
+		}
+		socketBytes := C.GoBytes(unsafe.Pointer(&socket), C.sizeof_libxl_device_channel_connection_union_socket)
+		copy(xc.u[:], socketBytes)
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Connection)
+	}
+
+	return nil
+}
+
+// NewConnectorParam returns an instance of ConnectorParam initialized with defaults.
+func NewConnectorParam() (*ConnectorParam, error) {
+	var (
+		x  ConnectorParam
+		xc C.libxl_connector_param
+	)
+
+	C.libxl_connector_param_init(&xc)
+	defer C.libxl_connector_param_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *ConnectorParam) fromC(xc *C.libxl_connector_param) error {
+	x.UniqueId = C.GoString(xc.unique_id)
+	x.Width = uint32(xc.width)
+	x.Height = uint32(xc.height)
+
+	return nil
+}
+
+func (x *ConnectorParam) toC(xc *C.libxl_connector_param) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_connector_param_dispose(xc)
+		}
+	}()
+
+	if x.UniqueId != "" {
+		xc.unique_id = C.CString(x.UniqueId)
+	}
+	xc.width = C.uint32_t(x.Width)
+	xc.height = C.uint32_t(x.Height)
+
+	return nil
+}
+
+// NewDeviceVdispl returns an instance of DeviceVdispl initialized with defaults.
+func NewDeviceVdispl() (*DeviceVdispl, error) {
+	var (
+		x  DeviceVdispl
+		xc C.libxl_device_vdispl
+	)
+
+	C.libxl_device_vdispl_init(&xc)
+	defer C.libxl_device_vdispl_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceVdispl) fromC(xc *C.libxl_device_vdispl) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.Devid = Devid(xc.devid)
+	x.BeAlloc = bool(xc.be_alloc)
+	x.Connectors = nil
+	if n := int(xc.num_connectors); n > 0 {
+		cConnectors := (*[1 << 28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:n:n]
+		x.Connectors = make([]ConnectorParam, n)
+		for i, v := range cConnectors {
+			if err := x.Connectors[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Connectors: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+func (x *DeviceVdispl) toC(xc *C.libxl_device_vdispl) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_vdispl_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.be_alloc = C.bool(x.BeAlloc)
+	if numConnectors := len(x.Connectors); numConnectors > 0 {
+		xc.connectors = (*C.libxl_connector_param)(C.malloc(C.ulong(numConnectors) * C.sizeof_libxl_connector_param))
+		xc.num_connectors = C.int(numConnectors)
+		cConnectors := (*[1 << 28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors]
+		for i, v := range x.Connectors {
+			if err := v.toC(&cConnectors[i]); err != nil {
+				return fmt.Errorf("converting field Connectors: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+// NewVsndParams returns an instance of VsndParams initialized with defaults.
+func NewVsndParams() (*VsndParams, error) {
+	var (
+		x  VsndParams
+		xc C.libxl_vsnd_params
+	)
+
+	C.libxl_vsnd_params_init(&xc)
+	defer C.libxl_vsnd_params_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *VsndParams) fromC(xc *C.libxl_vsnd_params) error {
+	x.SampleRates = nil
+	if n := int(xc.num_sample_rates); n > 0 {
+		cSampleRates := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:n:n]
+		x.SampleRates = make([]uint32, n)
+		for i, v := range cSampleRates {
+			x.SampleRates[i] = uint32(v)
+		}
+	}
+	x.SampleFormats = nil
+	if n := int(xc.num_sample_formats); n > 0 {
+		cSampleFormats := (*[1 << 28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:n:n]
+		x.SampleFormats = make([]VsndPcmFormat, n)
+		for i, v := range cSampleFormats {
+			x.SampleFormats[i] = VsndPcmFormat(v)
+		}
+	}
+	x.ChannelsMin = uint32(xc.channels_min)
+	x.ChannelsMax = uint32(xc.channels_max)
+	x.BufferSize = uint32(xc.buffer_size)
+
+	return nil
+}
+
+func (x *VsndParams) toC(xc *C.libxl_vsnd_params) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vsnd_params_dispose(xc)
+		}
+	}()
+
+	if numSampleRates := len(x.SampleRates); numSampleRates > 0 {
+		xc.sample_rates = (*C.uint32_t)(C.malloc(C.size_t(numSampleRates * numSampleRates)))
+		xc.num_sample_rates = C.int(numSampleRates)
+		cSampleRates := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:numSampleRates:numSampleRates]
+		for i, v := range x.SampleRates {
+			cSampleRates[i] = C.uint32_t(v)
+		}
+	}
+	if numSampleFormats := len(x.SampleFormats); numSampleFormats > 0 {
+		xc.sample_formats = (*C.libxl_vsnd_pcm_format)(C.malloc(C.size_t(numSampleFormats * numSampleFormats)))
+		xc.num_sample_formats = C.int(numSampleFormats)
+		cSampleFormats := (*[1 << 28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:numSampleFormats:numSampleFormats]
+		for i, v := range x.SampleFormats {
+			cSampleFormats[i] = C.libxl_vsnd_pcm_format(v)
+		}
+	}
+	xc.channels_min = C.uint32_t(x.ChannelsMin)
+	xc.channels_max = C.uint32_t(x.ChannelsMax)
+	xc.buffer_size = C.uint32_t(x.BufferSize)
+
+	return nil
+}
+
+// NewVsndStream returns an instance of VsndStream initialized with defaults.
+func NewVsndStream() (*VsndStream, error) {
+	var (
+		x  VsndStream
+		xc C.libxl_vsnd_stream
+	)
+
+	C.libxl_vsnd_stream_init(&xc)
+	defer C.libxl_vsnd_stream_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *VsndStream) fromC(xc *C.libxl_vsnd_stream) error {
+	x.UniqueId = C.GoString(xc.unique_id)
+	x.Type = VsndStreamType(xc._type)
+	if err := x.Params.fromC(&xc.params); err != nil {
+		return fmt.Errorf("converting field Params: %v", err)
+	}
+
+	return nil
+}
+
+func (x *VsndStream) toC(xc *C.libxl_vsnd_stream) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vsnd_stream_dispose(xc)
+		}
+	}()
+
+	if x.UniqueId != "" {
+		xc.unique_id = C.CString(x.UniqueId)
+	}
+	xc._type = C.libxl_vsnd_stream_type(x.Type)
+	if err := x.Params.toC(&xc.params); err != nil {
+		return fmt.Errorf("converting field Params: %v", err)
+	}
+
+	return nil
+}
+
+// NewVsndPcm returns an instance of VsndPcm initialized with defaults.
+func NewVsndPcm() (*VsndPcm, error) {
+	var (
+		x  VsndPcm
+		xc C.libxl_vsnd_pcm
+	)
+
+	C.libxl_vsnd_pcm_init(&xc)
+	defer C.libxl_vsnd_pcm_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *VsndPcm) fromC(xc *C.libxl_vsnd_pcm) error {
+	x.Name = C.GoString(xc.name)
+	if err := x.Params.fromC(&xc.params); err != nil {
+		return fmt.Errorf("converting field Params: %v", err)
+	}
+	x.Streams = nil
+	if n := int(xc.num_vsnd_streams); n > 0 {
+		cStreams := (*[1 << 28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:n:n]
+		x.Streams = make([]VsndStream, n)
+		for i, v := range cStreams {
+			if err := x.Streams[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Streams: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+func (x *VsndPcm) toC(xc *C.libxl_vsnd_pcm) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vsnd_pcm_dispose(xc)
+		}
+	}()
+
+	if x.Name != "" {
+		xc.name = C.CString(x.Name)
+	}
+	if err := x.Params.toC(&xc.params); err != nil {
+		return fmt.Errorf("converting field Params: %v", err)
+	}
+	if numVsndStreams := len(x.Streams); numVsndStreams > 0 {
+		xc.streams = (*C.libxl_vsnd_stream)(C.malloc(C.ulong(numVsndStreams) * C.sizeof_libxl_vsnd_stream))
+		xc.num_vsnd_streams = C.int(numVsndStreams)
+		cStreams := (*[1 << 28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams]
+		for i, v := range x.Streams {
+			if err := v.toC(&cStreams[i]); err != nil {
+				return fmt.Errorf("converting field Streams: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+// NewDeviceVsnd returns an instance of DeviceVsnd initialized with defaults.
+func NewDeviceVsnd() (*DeviceVsnd, error) {
+	var (
+		x  DeviceVsnd
+		xc C.libxl_device_vsnd
+	)
+
+	C.libxl_device_vsnd_init(&xc)
+	defer C.libxl_device_vsnd_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DeviceVsnd) fromC(xc *C.libxl_device_vsnd) error {
+	x.BackendDomid = Domid(xc.backend_domid)
+	x.BackendDomname = C.GoString(xc.backend_domname)
+	x.Devid = Devid(xc.devid)
+	x.ShortName = C.GoString(xc.short_name)
+	x.LongName = C.GoString(xc.long_name)
+	if err := x.Params.fromC(&xc.params); err != nil {
+		return fmt.Errorf("converting field Params: %v", err)
+	}
+	x.Pcms = nil
+	if n := int(xc.num_vsnd_pcms); n > 0 {
+		cPcms := (*[1 << 28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:n:n]
+		x.Pcms = make([]VsndPcm, n)
+		for i, v := range cPcms {
+			if err := x.Pcms[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Pcms: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+func (x *DeviceVsnd) toC(xc *C.libxl_device_vsnd) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_device_vsnd_dispose(xc)
+		}
+	}()
+
+	xc.backend_domid = C.libxl_domid(x.BackendDomid)
+	if x.BackendDomname != "" {
+		xc.backend_domname = C.CString(x.BackendDomname)
+	}
+	xc.devid = C.libxl_devid(x.Devid)
+	if x.ShortName != "" {
+		xc.short_name = C.CString(x.ShortName)
+	}
+	if x.LongName != "" {
+		xc.long_name = C.CString(x.LongName)
+	}
+	if err := x.Params.toC(&xc.params); err != nil {
+		return fmt.Errorf("converting field Params: %v", err)
+	}
+	if numVsndPcms := len(x.Pcms); numVsndPcms > 0 {
+		xc.pcms = (*C.libxl_vsnd_pcm)(C.malloc(C.ulong(numVsndPcms) * C.sizeof_libxl_vsnd_pcm))
+		xc.num_vsnd_pcms = C.int(numVsndPcms)
+		cPcms := (*[1 << 28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms]
+		for i, v := range x.Pcms {
+			if err := v.toC(&cPcms[i]); err != nil {
+				return fmt.Errorf("converting field Pcms: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+// NewDomainConfig returns an instance of DomainConfig initialized with defaults.
+func NewDomainConfig() (*DomainConfig, error) {
+	var (
+		x  DomainConfig
+		xc C.libxl_domain_config
+	)
+
+	C.libxl_domain_config_init(&xc)
+	defer C.libxl_domain_config_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DomainConfig) fromC(xc *C.libxl_domain_config) error {
+	if err := x.CInfo.fromC(&xc.c_info); err != nil {
+		return fmt.Errorf("converting field CInfo: %v", err)
+	}
+	if err := x.BInfo.fromC(&xc.b_info); err != nil {
+		return fmt.Errorf("converting field BInfo: %v", err)
+	}
+	x.Disks = nil
+	if n := int(xc.num_disks); n > 0 {
+		cDisks := (*[1 << 28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:n:n]
+		x.Disks = make([]DeviceDisk, n)
+		for i, v := range cDisks {
+			if err := x.Disks[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Disks: %v", err)
+			}
+		}
+	}
+	x.Nics = nil
+	if n := int(xc.num_nics); n > 0 {
+		cNics := (*[1 << 28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:n:n]
+		x.Nics = make([]DeviceNic, n)
+		for i, v := range cNics {
+			if err := x.Nics[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Nics: %v", err)
+			}
+		}
+	}
+	x.Pcidevs = nil
+	if n := int(xc.num_pcidevs); n > 0 {
+		cPcidevs := (*[1 << 28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:n:n]
+		x.Pcidevs = make([]DevicePci, n)
+		for i, v := range cPcidevs {
+			if err := x.Pcidevs[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Pcidevs: %v", err)
+			}
+		}
+	}
+	x.Rdms = nil
+	if n := int(xc.num_rdms); n > 0 {
+		cRdms := (*[1 << 28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:n:n]
+		x.Rdms = make([]DeviceRdm, n)
+		for i, v := range cRdms {
+			if err := x.Rdms[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Rdms: %v", err)
+			}
+		}
+	}
+	x.Dtdevs = nil
+	if n := int(xc.num_dtdevs); n > 0 {
+		cDtdevs := (*[1 << 28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:n:n]
+		x.Dtdevs = make([]DeviceDtdev, n)
+		for i, v := range cDtdevs {
+			if err := x.Dtdevs[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Dtdevs: %v", err)
+			}
+		}
+	}
+	x.Vfbs = nil
+	if n := int(xc.num_vfbs); n > 0 {
+		cVfbs := (*[1 << 28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:n:n]
+		x.Vfbs = make([]DeviceVfb, n)
+		for i, v := range cVfbs {
+			if err := x.Vfbs[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Vfbs: %v", err)
+			}
+		}
+	}
+	x.Vkbs = nil
+	if n := int(xc.num_vkbs); n > 0 {
+		cVkbs := (*[1 << 28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:n:n]
+		x.Vkbs = make([]DeviceVkb, n)
+		for i, v := range cVkbs {
+			if err := x.Vkbs[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Vkbs: %v", err)
+			}
+		}
+	}
+	x.Vtpms = nil
+	if n := int(xc.num_vtpms); n > 0 {
+		cVtpms := (*[1 << 28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:n:n]
+		x.Vtpms = make([]DeviceVtpm, n)
+		for i, v := range cVtpms {
+			if err := x.Vtpms[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Vtpms: %v", err)
+			}
+		}
+	}
+	x.P9S = nil
+	if n := int(xc.num_p9s); n > 0 {
+		cP9S := (*[1 << 28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:n:n]
+		x.P9S = make([]DeviceP9, n)
+		for i, v := range cP9S {
+			if err := x.P9S[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field P9S: %v", err)
+			}
+		}
+	}
+	x.Pvcallsifs = nil
+	if n := int(xc.num_pvcallsifs); n > 0 {
+		cPvcallsifs := (*[1 << 28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:n:n]
+		x.Pvcallsifs = make([]DevicePvcallsif, n)
+		for i, v := range cPvcallsifs {
+			if err := x.Pvcallsifs[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Pvcallsifs: %v", err)
+			}
+		}
+	}
+	x.Vdispls = nil
+	if n := int(xc.num_vdispls); n > 0 {
+		cVdispls := (*[1 << 28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:n:n]
+		x.Vdispls = make([]DeviceVdispl, n)
+		for i, v := range cVdispls {
+			if err := x.Vdispls[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Vdispls: %v", err)
+			}
+		}
+	}
+	x.Vsnds = nil
+	if n := int(xc.num_vsnds); n > 0 {
+		cVsnds := (*[1 << 28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:n:n]
+		x.Vsnds = make([]DeviceVsnd, n)
+		for i, v := range cVsnds {
+			if err := x.Vsnds[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Vsnds: %v", err)
+			}
+		}
+	}
+	x.Channels = nil
+	if n := int(xc.num_channels); n > 0 {
+		cChannels := (*[1 << 28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:n:n]
+		x.Channels = make([]DeviceChannel, n)
+		for i, v := range cChannels {
+			if err := x.Channels[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Channels: %v", err)
+			}
+		}
+	}
+	x.Usbctrls = nil
+	if n := int(xc.num_usbctrls); n > 0 {
+		cUsbctrls := (*[1 << 28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:n:n]
+		x.Usbctrls = make([]DeviceUsbctrl, n)
+		for i, v := range cUsbctrls {
+			if err := x.Usbctrls[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Usbctrls: %v", err)
+			}
+		}
+	}
+	x.Usbdevs = nil
+	if n := int(xc.num_usbdevs); n > 0 {
+		cUsbdevs := (*[1 << 28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:n:n]
+		x.Usbdevs = make([]DeviceUsbdev, n)
+		for i, v := range cUsbdevs {
+			if err := x.Usbdevs[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Usbdevs: %v", err)
+			}
+		}
+	}
+	x.OnPoweroff = ActionOnShutdown(xc.on_poweroff)
+	x.OnReboot = ActionOnShutdown(xc.on_reboot)
+	x.OnWatchdog = ActionOnShutdown(xc.on_watchdog)
+	x.OnCrash = ActionOnShutdown(xc.on_crash)
+	x.OnSoftReset = ActionOnShutdown(xc.on_soft_reset)
+
+	return nil
+}
+
+func (x *DomainConfig) toC(xc *C.libxl_domain_config) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_domain_config_dispose(xc)
+		}
+	}()
+
+	if err := x.CInfo.toC(&xc.c_info); err != nil {
+		return fmt.Errorf("converting field CInfo: %v", err)
+	}
+	if err := x.BInfo.toC(&xc.b_info); err != nil {
+		return fmt.Errorf("converting field BInfo: %v", err)
+	}
+	if numDisks := len(x.Disks); numDisks > 0 {
+		xc.disks = (*C.libxl_device_disk)(C.malloc(C.ulong(numDisks) * C.sizeof_libxl_device_disk))
+		xc.num_disks = C.int(numDisks)
+		cDisks := (*[1 << 28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:numDisks:numDisks]
+		for i, v := range x.Disks {
+			if err := v.toC(&cDisks[i]); err != nil {
+				return fmt.Errorf("converting field Disks: %v", err)
+			}
+		}
+	}
+	if numNics := len(x.Nics); numNics > 0 {
+		xc.nics = (*C.libxl_device_nic)(C.malloc(C.ulong(numNics) * C.sizeof_libxl_device_nic))
+		xc.num_nics = C.int(numNics)
+		cNics := (*[1 << 28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:numNics:numNics]
+		for i, v := range x.Nics {
+			if err := v.toC(&cNics[i]); err != nil {
+				return fmt.Errorf("converting field Nics: %v", err)
+			}
+		}
+	}
+	if numPcidevs := len(x.Pcidevs); numPcidevs > 0 {
+		xc.pcidevs = (*C.libxl_device_pci)(C.malloc(C.ulong(numPcidevs) * C.sizeof_libxl_device_pci))
+		xc.num_pcidevs = C.int(numPcidevs)
+		cPcidevs := (*[1 << 28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:numPcidevs:numPcidevs]
+		for i, v := range x.Pcidevs {
+			if err := v.toC(&cPcidevs[i]); err != nil {
+				return fmt.Errorf("converting field Pcidevs: %v", err)
+			}
+		}
+	}
+	if numRdms := len(x.Rdms); numRdms > 0 {
+		xc.rdms = (*C.libxl_device_rdm)(C.malloc(C.ulong(numRdms) * C.sizeof_libxl_device_rdm))
+		xc.num_rdms = C.int(numRdms)
+		cRdms := (*[1 << 28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:numRdms:numRdms]
+		for i, v := range x.Rdms {
+			if err := v.toC(&cRdms[i]); err != nil {
+				return fmt.Errorf("converting field Rdms: %v", err)
+			}
+		}
+	}
+	if numDtdevs := len(x.Dtdevs); numDtdevs > 0 {
+		xc.dtdevs = (*C.libxl_device_dtdev)(C.malloc(C.ulong(numDtdevs) * C.sizeof_libxl_device_dtdev))
+		xc.num_dtdevs = C.int(numDtdevs)
+		cDtdevs := (*[1 << 28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:numDtdevs:numDtdevs]
+		for i, v := range x.Dtdevs {
+			if err := v.toC(&cDtdevs[i]); err != nil {
+				return fmt.Errorf("converting field Dtdevs: %v", err)
+			}
+		}
+	}
+	if numVfbs := len(x.Vfbs); numVfbs > 0 {
+		xc.vfbs = (*C.libxl_device_vfb)(C.malloc(C.ulong(numVfbs) * C.sizeof_libxl_device_vfb))
+		xc.num_vfbs = C.int(numVfbs)
+		cVfbs := (*[1 << 28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:numVfbs:numVfbs]
+		for i, v := range x.Vfbs {
+			if err := v.toC(&cVfbs[i]); err != nil {
+				return fmt.Errorf("converting field Vfbs: %v", err)
+			}
+		}
+	}
+	if numVkbs := len(x.Vkbs); numVkbs > 0 {
+		xc.vkbs = (*C.libxl_device_vkb)(C.malloc(C.ulong(numVkbs) * C.sizeof_libxl_device_vkb))
+		xc.num_vkbs = C.int(numVkbs)
+		cVkbs := (*[1 << 28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:numVkbs:numVkbs]
+		for i, v := range x.Vkbs {
+			if err := v.toC(&cVkbs[i]); err != nil {
+				return fmt.Errorf("converting field Vkbs: %v", err)
+			}
+		}
+	}
+	if numVtpms := len(x.Vtpms); numVtpms > 0 {
+		xc.vtpms = (*C.libxl_device_vtpm)(C.malloc(C.ulong(numVtpms) * C.sizeof_libxl_device_vtpm))
+		xc.num_vtpms = C.int(numVtpms)
+		cVtpms := (*[1 << 28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:numVtpms:numVtpms]
+		for i, v := range x.Vtpms {
+			if err := v.toC(&cVtpms[i]); err != nil {
+				return fmt.Errorf("converting field Vtpms: %v", err)
+			}
+		}
+	}
+	if numP9S := len(x.P9S); numP9S > 0 {
+		xc.p9s = (*C.libxl_device_p9)(C.malloc(C.ulong(numP9S) * C.sizeof_libxl_device_p9))
+		xc.num_p9s = C.int(numP9S)
+		cP9S := (*[1 << 28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:numP9S:numP9S]
+		for i, v := range x.P9S {
+			if err := v.toC(&cP9S[i]); err != nil {
+				return fmt.Errorf("converting field P9S: %v", err)
+			}
+		}
+	}
+	if numPvcallsifs := len(x.Pvcallsifs); numPvcallsifs > 0 {
+		xc.pvcallsifs = (*C.libxl_device_pvcallsif)(C.malloc(C.ulong(numPvcallsifs) * C.sizeof_libxl_device_pvcallsif))
+		xc.num_pvcallsifs = C.int(numPvcallsifs)
+		cPvcallsifs := (*[1 << 28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:numPvcallsifs:numPvcallsifs]
+		for i, v := range x.Pvcallsifs {
+			if err := v.toC(&cPvcallsifs[i]); err != nil {
+				return fmt.Errorf("converting field Pvcallsifs: %v", err)
+			}
+		}
+	}
+	if numVdispls := len(x.Vdispls); numVdispls > 0 {
+		xc.vdispls = (*C.libxl_device_vdispl)(C.malloc(C.ulong(numVdispls) * C.sizeof_libxl_device_vdispl))
+		xc.num_vdispls = C.int(numVdispls)
+		cVdispls := (*[1 << 28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:numVdispls:numVdispls]
+		for i, v := range x.Vdispls {
+			if err := v.toC(&cVdispls[i]); err != nil {
+				return fmt.Errorf("converting field Vdispls: %v", err)
+			}
+		}
+	}
+	if numVsnds := len(x.Vsnds); numVsnds > 0 {
+		xc.vsnds = (*C.libxl_device_vsnd)(C.malloc(C.ulong(numVsnds) * C.sizeof_libxl_device_vsnd))
+		xc.num_vsnds = C.int(numVsnds)
+		cVsnds := (*[1 << 28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:numVsnds:numVsnds]
+		for i, v := range x.Vsnds {
+			if err := v.toC(&cVsnds[i]); err != nil {
+				return fmt.Errorf("converting field Vsnds: %v", err)
+			}
+		}
+	}
+	if numChannels := len(x.Channels); numChannels > 0 {
+		xc.channels = (*C.libxl_device_channel)(C.malloc(C.ulong(numChannels) * C.sizeof_libxl_device_channel))
+		xc.num_channels = C.int(numChannels)
+		cChannels := (*[1 << 28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:numChannels:numChannels]
+		for i, v := range x.Channels {
+			if err := v.toC(&cChannels[i]); err != nil {
+				return fmt.Errorf("converting field Channels: %v", err)
+			}
+		}
+	}
+	if numUsbctrls := len(x.Usbctrls); numUsbctrls > 0 {
+		xc.usbctrls = (*C.libxl_device_usbctrl)(C.malloc(C.ulong(numUsbctrls) * C.sizeof_libxl_device_usbctrl))
+		xc.num_usbctrls = C.int(numUsbctrls)
+		cUsbctrls := (*[1 << 28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:numUsbctrls:numUsbctrls]
+		for i, v := range x.Usbctrls {
+			if err := v.toC(&cUsbctrls[i]); err != nil {
+				return fmt.Errorf("converting field Usbctrls: %v", err)
+			}
+		}
+	}
+	if numUsbdevs := len(x.Usbdevs); numUsbdevs > 0 {
+		xc.usbdevs = (*C.libxl_device_usbdev)(C.malloc(C.ulong(numUsbdevs) * C.sizeof_libxl_device_usbdev))
+		xc.num_usbdevs = C.int(numUsbdevs)
+		cUsbdevs := (*[1 << 28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:numUsbdevs:numUsbdevs]
+		for i, v := range x.Usbdevs {
+			if err := v.toC(&cUsbdevs[i]); err != nil {
+				return fmt.Errorf("converting field Usbdevs: %v", err)
+			}
+		}
+	}
+	xc.on_poweroff = C.libxl_action_on_shutdown(x.OnPoweroff)
+	xc.on_reboot = C.libxl_action_on_shutdown(x.OnReboot)
+	xc.on_watchdog = C.libxl_action_on_shutdown(x.OnWatchdog)
+	xc.on_crash = C.libxl_action_on_shutdown(x.OnCrash)
+	xc.on_soft_reset = C.libxl_action_on_shutdown(x.OnSoftReset)
+
+	return nil
+}
+
+// NewDiskinfo returns an instance of Diskinfo initialized with defaults.
+func NewDiskinfo() (*Diskinfo, error) {
+	var (
+		x  Diskinfo
+		xc C.libxl_diskinfo
+	)
+
+	C.libxl_diskinfo_init(&xc)
+	defer C.libxl_diskinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Diskinfo) fromC(xc *C.libxl_diskinfo) error {
+	x.Backend = C.GoString(xc.backend)
+	x.BackendId = uint32(xc.backend_id)
+	x.Frontend = C.GoString(xc.frontend)
+	x.FrontendId = uint32(xc.frontend_id)
+	x.Devid = Devid(xc.devid)
+	x.State = int(xc.state)
+	x.Evtch = int(xc.evtch)
+	x.Rref = int(xc.rref)
+
+	return nil
+}
+
+func (x *Diskinfo) toC(xc *C.libxl_diskinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_diskinfo_dispose(xc)
+		}
+	}()
+
+	if x.Backend != "" {
+		xc.backend = C.CString(x.Backend)
+	}
+	xc.backend_id = C.uint32_t(x.BackendId)
+	if x.Frontend != "" {
+		xc.frontend = C.CString(x.Frontend)
+	}
+	xc.frontend_id = C.uint32_t(x.FrontendId)
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.state = C.int(x.State)
+	xc.evtch = C.int(x.Evtch)
+	xc.rref = C.int(x.Rref)
+
+	return nil
+}
+
+// NewNicinfo returns an instance of Nicinfo initialized with defaults.
+func NewNicinfo() (*Nicinfo, error) {
+	var (
+		x  Nicinfo
+		xc C.libxl_nicinfo
+	)
+
+	C.libxl_nicinfo_init(&xc)
+	defer C.libxl_nicinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Nicinfo) fromC(xc *C.libxl_nicinfo) error {
+	x.Backend = C.GoString(xc.backend)
+	x.BackendId = uint32(xc.backend_id)
+	x.Frontend = C.GoString(xc.frontend)
+	x.FrontendId = uint32(xc.frontend_id)
+	x.Devid = Devid(xc.devid)
+	x.State = int(xc.state)
+	x.Evtch = int(xc.evtch)
+	x.RrefTx = int(xc.rref_tx)
+	x.RrefRx = int(xc.rref_rx)
+
+	return nil
+}
+
+func (x *Nicinfo) toC(xc *C.libxl_nicinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_nicinfo_dispose(xc)
+		}
+	}()
+
+	if x.Backend != "" {
+		xc.backend = C.CString(x.Backend)
+	}
+	xc.backend_id = C.uint32_t(x.BackendId)
+	if x.Frontend != "" {
+		xc.frontend = C.CString(x.Frontend)
+	}
+	xc.frontend_id = C.uint32_t(x.FrontendId)
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.state = C.int(x.State)
+	xc.evtch = C.int(x.Evtch)
+	xc.rref_tx = C.int(x.RrefTx)
+	xc.rref_rx = C.int(x.RrefRx)
+
+	return nil
+}
+
+// NewVtpminfo returns an instance of Vtpminfo initialized with defaults.
+func NewVtpminfo() (*Vtpminfo, error) {
+	var (
+		x  Vtpminfo
+		xc C.libxl_vtpminfo
+	)
+
+	C.libxl_vtpminfo_init(&xc)
+	defer C.libxl_vtpminfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Vtpminfo) fromC(xc *C.libxl_vtpminfo) error {
+	x.Backend = C.GoString(xc.backend)
+	x.BackendId = uint32(xc.backend_id)
+	x.Frontend = C.GoString(xc.frontend)
+	x.FrontendId = uint32(xc.frontend_id)
+	x.Devid = Devid(xc.devid)
+	x.State = int(xc.state)
+	x.Evtch = int(xc.evtch)
+	x.Rref = int(xc.rref)
+	if err := x.Uuid.fromC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+
+	return nil
+}
+
+func (x *Vtpminfo) toC(xc *C.libxl_vtpminfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vtpminfo_dispose(xc)
+		}
+	}()
+
+	if x.Backend != "" {
+		xc.backend = C.CString(x.Backend)
+	}
+	xc.backend_id = C.uint32_t(x.BackendId)
+	if x.Frontend != "" {
+		xc.frontend = C.CString(x.Frontend)
+	}
+	xc.frontend_id = C.uint32_t(x.FrontendId)
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.state = C.int(x.State)
+	xc.evtch = C.int(x.Evtch)
+	xc.rref = C.int(x.Rref)
+	if err := x.Uuid.toC(&xc.uuid); err != nil {
+		return fmt.Errorf("converting field Uuid: %v", err)
+	}
+
+	return nil
+}
+
+// NewUsbctrlinfo returns an instance of Usbctrlinfo initialized with defaults.
+func NewUsbctrlinfo() (*Usbctrlinfo, error) {
+	var (
+		x  Usbctrlinfo
+		xc C.libxl_usbctrlinfo
+	)
+
+	C.libxl_usbctrlinfo_init(&xc)
+	defer C.libxl_usbctrlinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Usbctrlinfo) fromC(xc *C.libxl_usbctrlinfo) error {
+	x.Type = UsbctrlType(xc._type)
+	x.Devid = Devid(xc.devid)
+	x.Version = int(xc.version)
+	x.Ports = int(xc.ports)
+	x.Backend = C.GoString(xc.backend)
+	x.BackendId = uint32(xc.backend_id)
+	x.Frontend = C.GoString(xc.frontend)
+	x.FrontendId = uint32(xc.frontend_id)
+	x.State = int(xc.state)
+	x.Evtch = int(xc.evtch)
+	x.RefUrb = int(xc.ref_urb)
+	x.RefConn = int(xc.ref_conn)
+
+	return nil
+}
+
+func (x *Usbctrlinfo) toC(xc *C.libxl_usbctrlinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_usbctrlinfo_dispose(xc)
+		}
+	}()
+
+	xc._type = C.libxl_usbctrl_type(x.Type)
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.version = C.int(x.Version)
+	xc.ports = C.int(x.Ports)
+	if x.Backend != "" {
+		xc.backend = C.CString(x.Backend)
+	}
+	xc.backend_id = C.uint32_t(x.BackendId)
+	if x.Frontend != "" {
+		xc.frontend = C.CString(x.Frontend)
+	}
+	xc.frontend_id = C.uint32_t(x.FrontendId)
+	xc.state = C.int(x.State)
+	xc.evtch = C.int(x.Evtch)
+	xc.ref_urb = C.int(x.RefUrb)
+	xc.ref_conn = C.int(x.RefConn)
+
+	return nil
+}
+
+// NewVcpuinfo returns an instance of Vcpuinfo initialized with defaults.
+func NewVcpuinfo() (*Vcpuinfo, error) {
+	var (
+		x  Vcpuinfo
+		xc C.libxl_vcpuinfo
+	)
+
+	C.libxl_vcpuinfo_init(&xc)
+	defer C.libxl_vcpuinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Vcpuinfo) fromC(xc *C.libxl_vcpuinfo) error {
+	x.Vcpuid = uint32(xc.vcpuid)
+	x.Cpu = uint32(xc.cpu)
+	x.Online = bool(xc.online)
+	x.Blocked = bool(xc.blocked)
+	x.Running = bool(xc.running)
+	x.VcpuTime = uint64(xc.vcpu_time)
+	if err := x.Cpumap.fromC(&xc.cpumap); err != nil {
+		return fmt.Errorf("converting field Cpumap: %v", err)
+	}
+	if err := x.CpumapSoft.fromC(&xc.cpumap_soft); err != nil {
+		return fmt.Errorf("converting field CpumapSoft: %v", err)
+	}
+
+	return nil
+}
+
+func (x *Vcpuinfo) toC(xc *C.libxl_vcpuinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vcpuinfo_dispose(xc)
+		}
+	}()
+
+	xc.vcpuid = C.uint32_t(x.Vcpuid)
+	xc.cpu = C.uint32_t(x.Cpu)
+	xc.online = C.bool(x.Online)
+	xc.blocked = C.bool(x.Blocked)
+	xc.running = C.bool(x.Running)
+	xc.vcpu_time = C.uint64_t(x.VcpuTime)
+	if err := x.Cpumap.toC(&xc.cpumap); err != nil {
+		return fmt.Errorf("converting field Cpumap: %v", err)
+	}
+	if err := x.CpumapSoft.toC(&xc.cpumap_soft); err != nil {
+		return fmt.Errorf("converting field CpumapSoft: %v", err)
+	}
+
+	return nil
+}
+
+// NewPhysinfo returns an instance of Physinfo initialized with defaults.
+func NewPhysinfo() (*Physinfo, error) {
+	var (
+		x  Physinfo
+		xc C.libxl_physinfo
+	)
+
+	C.libxl_physinfo_init(&xc)
+	defer C.libxl_physinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Physinfo) fromC(xc *C.libxl_physinfo) error {
+	x.ThreadsPerCore = uint32(xc.threads_per_core)
+	x.CoresPerSocket = uint32(xc.cores_per_socket)
+	x.MaxCpuId = uint32(xc.max_cpu_id)
+	x.NrCpus = uint32(xc.nr_cpus)
+	x.CpuKhz = uint32(xc.cpu_khz)
+	x.TotalPages = uint64(xc.total_pages)
+	x.FreePages = uint64(xc.free_pages)
+	x.ScrubPages = uint64(xc.scrub_pages)
+	x.OutstandingPages = uint64(xc.outstanding_pages)
+	x.SharingFreedPages = uint64(xc.sharing_freed_pages)
+	x.SharingUsedFrames = uint64(xc.sharing_used_frames)
+	x.MaxPossibleMfn = uint64(xc.max_possible_mfn)
+	x.NrNodes = uint32(xc.nr_nodes)
+	if err := x.HwCap.fromC(&xc.hw_cap); err != nil {
+		return fmt.Errorf("converting field HwCap: %v", err)
+	}
+	x.CapHvm = bool(xc.cap_hvm)
+	x.CapPv = bool(xc.cap_pv)
+	x.CapHvmDirectio = bool(xc.cap_hvm_directio)
+	x.CapHap = bool(xc.cap_hap)
+	x.CapShadow = bool(xc.cap_shadow)
+	x.CapIommuHapPtShare = bool(xc.cap_iommu_hap_pt_share)
+
+	return nil
+}
+
+func (x *Physinfo) toC(xc *C.libxl_physinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_physinfo_dispose(xc)
+		}
+	}()
+
+	xc.threads_per_core = C.uint32_t(x.ThreadsPerCore)
+	xc.cores_per_socket = C.uint32_t(x.CoresPerSocket)
+	xc.max_cpu_id = C.uint32_t(x.MaxCpuId)
+	xc.nr_cpus = C.uint32_t(x.NrCpus)
+	xc.cpu_khz = C.uint32_t(x.CpuKhz)
+	xc.total_pages = C.uint64_t(x.TotalPages)
+	xc.free_pages = C.uint64_t(x.FreePages)
+	xc.scrub_pages = C.uint64_t(x.ScrubPages)
+	xc.outstanding_pages = C.uint64_t(x.OutstandingPages)
+	xc.sharing_freed_pages = C.uint64_t(x.SharingFreedPages)
+	xc.sharing_used_frames = C.uint64_t(x.SharingUsedFrames)
+	xc.max_possible_mfn = C.uint64_t(x.MaxPossibleMfn)
+	xc.nr_nodes = C.uint32_t(x.NrNodes)
+	if err := x.HwCap.toC(&xc.hw_cap); err != nil {
+		return fmt.Errorf("converting field HwCap: %v", err)
+	}
+	xc.cap_hvm = C.bool(x.CapHvm)
+	xc.cap_pv = C.bool(x.CapPv)
+	xc.cap_hvm_directio = C.bool(x.CapHvmDirectio)
+	xc.cap_hap = C.bool(x.CapHap)
+	xc.cap_shadow = C.bool(x.CapShadow)
+	xc.cap_iommu_hap_pt_share = C.bool(x.CapIommuHapPtShare)
+
+	return nil
+}
+
+// NewConnectorinfo returns an instance of Connectorinfo initialized with defaults.
+func NewConnectorinfo() (*Connectorinfo, error) {
+	var (
+		x  Connectorinfo
+		xc C.libxl_connectorinfo
+	)
+
+	C.libxl_connectorinfo_init(&xc)
+	defer C.libxl_connectorinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Connectorinfo) fromC(xc *C.libxl_connectorinfo) error {
+	x.UniqueId = C.GoString(xc.unique_id)
+	x.Width = uint32(xc.width)
+	x.Height = uint32(xc.height)
+	x.ReqEvtch = int(xc.req_evtch)
+	x.ReqRref = int(xc.req_rref)
+	x.EvtEvtch = int(xc.evt_evtch)
+	x.EvtRref = int(xc.evt_rref)
+
+	return nil
+}
+
+func (x *Connectorinfo) toC(xc *C.libxl_connectorinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_connectorinfo_dispose(xc)
+		}
+	}()
+
+	if x.UniqueId != "" {
+		xc.unique_id = C.CString(x.UniqueId)
+	}
+	xc.width = C.uint32_t(x.Width)
+	xc.height = C.uint32_t(x.Height)
+	xc.req_evtch = C.int(x.ReqEvtch)
+	xc.req_rref = C.int(x.ReqRref)
+	xc.evt_evtch = C.int(x.EvtEvtch)
+	xc.evt_rref = C.int(x.EvtRref)
+
+	return nil
+}
+
+// NewVdisplinfo returns an instance of Vdisplinfo initialized with defaults.
+func NewVdisplinfo() (*Vdisplinfo, error) {
+	var (
+		x  Vdisplinfo
+		xc C.libxl_vdisplinfo
+	)
+
+	C.libxl_vdisplinfo_init(&xc)
+	defer C.libxl_vdisplinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Vdisplinfo) fromC(xc *C.libxl_vdisplinfo) error {
+	x.Backend = C.GoString(xc.backend)
+	x.BackendId = uint32(xc.backend_id)
+	x.Frontend = C.GoString(xc.frontend)
+	x.FrontendId = uint32(xc.frontend_id)
+	x.Devid = Devid(xc.devid)
+	x.State = int(xc.state)
+	x.BeAlloc = bool(xc.be_alloc)
+	x.Connectors = nil
+	if n := int(xc.num_connectors); n > 0 {
+		cConnectors := (*[1 << 28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:n:n]
+		x.Connectors = make([]Connectorinfo, n)
+		for i, v := range cConnectors {
+			if err := x.Connectors[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Connectors: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+func (x *Vdisplinfo) toC(xc *C.libxl_vdisplinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vdisplinfo_dispose(xc)
+		}
+	}()
+
+	if x.Backend != "" {
+		xc.backend = C.CString(x.Backend)
+	}
+	xc.backend_id = C.uint32_t(x.BackendId)
+	if x.Frontend != "" {
+		xc.frontend = C.CString(x.Frontend)
+	}
+	xc.frontend_id = C.uint32_t(x.FrontendId)
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.state = C.int(x.State)
+	xc.be_alloc = C.bool(x.BeAlloc)
+	if numConnectors := len(x.Connectors); numConnectors > 0 {
+		xc.connectors = (*C.libxl_connectorinfo)(C.malloc(C.ulong(numConnectors) * C.sizeof_libxl_connectorinfo))
+		xc.num_connectors = C.int(numConnectors)
+		cConnectors := (*[1 << 28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors]
+		for i, v := range x.Connectors {
+			if err := v.toC(&cConnectors[i]); err != nil {
+				return fmt.Errorf("converting field Connectors: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+// NewStreaminfo returns an instance of Streaminfo initialized with defaults.
+func NewStreaminfo() (*Streaminfo, error) {
+	var (
+		x  Streaminfo
+		xc C.libxl_streaminfo
+	)
+
+	C.libxl_streaminfo_init(&xc)
+	defer C.libxl_streaminfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Streaminfo) fromC(xc *C.libxl_streaminfo) error {
+	x.ReqEvtch = int(xc.req_evtch)
+	x.ReqRref = int(xc.req_rref)
+
+	return nil
+}
+
+func (x *Streaminfo) toC(xc *C.libxl_streaminfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_streaminfo_dispose(xc)
+		}
+	}()
+
+	xc.req_evtch = C.int(x.ReqEvtch)
+	xc.req_rref = C.int(x.ReqRref)
+
+	return nil
+}
+
+// NewPcminfo returns an instance of Pcminfo initialized with defaults.
+func NewPcminfo() (*Pcminfo, error) {
+	var (
+		x  Pcminfo
+		xc C.libxl_pcminfo
+	)
+
+	C.libxl_pcminfo_init(&xc)
+	defer C.libxl_pcminfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Pcminfo) fromC(xc *C.libxl_pcminfo) error {
+	x.Streams = nil
+	if n := int(xc.num_vsnd_streams); n > 0 {
+		cStreams := (*[1 << 28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:n:n]
+		x.Streams = make([]Streaminfo, n)
+		for i, v := range cStreams {
+			if err := x.Streams[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Streams: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+func (x *Pcminfo) toC(xc *C.libxl_pcminfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_pcminfo_dispose(xc)
+		}
+	}()
+
+	if numVsndStreams := len(x.Streams); numVsndStreams > 0 {
+		xc.streams = (*C.libxl_streaminfo)(C.malloc(C.ulong(numVsndStreams) * C.sizeof_libxl_streaminfo))
+		xc.num_vsnd_streams = C.int(numVsndStreams)
+		cStreams := (*[1 << 28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams]
+		for i, v := range x.Streams {
+			if err := v.toC(&cStreams[i]); err != nil {
+				return fmt.Errorf("converting field Streams: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+// NewVsndinfo returns an instance of Vsndinfo initialized with defaults.
+func NewVsndinfo() (*Vsndinfo, error) {
+	var (
+		x  Vsndinfo
+		xc C.libxl_vsndinfo
+	)
+
+	C.libxl_vsndinfo_init(&xc)
+	defer C.libxl_vsndinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Vsndinfo) fromC(xc *C.libxl_vsndinfo) error {
+	x.Backend = C.GoString(xc.backend)
+	x.BackendId = uint32(xc.backend_id)
+	x.Frontend = C.GoString(xc.frontend)
+	x.FrontendId = uint32(xc.frontend_id)
+	x.Devid = Devid(xc.devid)
+	x.State = int(xc.state)
+	x.Pcms = nil
+	if n := int(xc.num_vsnd_pcms); n > 0 {
+		cPcms := (*[1 << 28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:n:n]
+		x.Pcms = make([]Pcminfo, n)
+		for i, v := range cPcms {
+			if err := x.Pcms[i].fromC(&v); err != nil {
+				return fmt.Errorf("converting field Pcms: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+func (x *Vsndinfo) toC(xc *C.libxl_vsndinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vsndinfo_dispose(xc)
+		}
+	}()
+
+	if x.Backend != "" {
+		xc.backend = C.CString(x.Backend)
+	}
+	xc.backend_id = C.uint32_t(x.BackendId)
+	if x.Frontend != "" {
+		xc.frontend = C.CString(x.Frontend)
+	}
+	xc.frontend_id = C.uint32_t(x.FrontendId)
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.state = C.int(x.State)
+	if numVsndPcms := len(x.Pcms); numVsndPcms > 0 {
+		xc.pcms = (*C.libxl_pcminfo)(C.malloc(C.ulong(numVsndPcms) * C.sizeof_libxl_pcminfo))
+		xc.num_vsnd_pcms = C.int(numVsndPcms)
+		cPcms := (*[1 << 28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms]
+		for i, v := range x.Pcms {
+			if err := v.toC(&cPcms[i]); err != nil {
+				return fmt.Errorf("converting field Pcms: %v", err)
+			}
+		}
+	}
+
+	return nil
+}
+
+// NewVkbinfo returns an instance of Vkbinfo initialized with defaults.
+func NewVkbinfo() (*Vkbinfo, error) {
+	var (
+		x  Vkbinfo
+		xc C.libxl_vkbinfo
+	)
+
+	C.libxl_vkbinfo_init(&xc)
+	defer C.libxl_vkbinfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Vkbinfo) fromC(xc *C.libxl_vkbinfo) error {
+	x.Backend = C.GoString(xc.backend)
+	x.BackendId = uint32(xc.backend_id)
+	x.Frontend = C.GoString(xc.frontend)
+	x.FrontendId = uint32(xc.frontend_id)
+	x.Devid = Devid(xc.devid)
+	x.State = int(xc.state)
+	x.Evtch = int(xc.evtch)
+	x.Rref = int(xc.rref)
+
+	return nil
+}
+
+func (x *Vkbinfo) toC(xc *C.libxl_vkbinfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_vkbinfo_dispose(xc)
+		}
+	}()
+
+	if x.Backend != "" {
+		xc.backend = C.CString(x.Backend)
+	}
+	xc.backend_id = C.uint32_t(x.BackendId)
+	if x.Frontend != "" {
+		xc.frontend = C.CString(x.Frontend)
+	}
+	xc.frontend_id = C.uint32_t(x.FrontendId)
+	xc.devid = C.libxl_devid(x.Devid)
+	xc.state = C.int(x.State)
+	xc.evtch = C.int(x.Evtch)
+	xc.rref = C.int(x.Rref)
+
+	return nil
+}
+
+// NewNumainfo returns an instance of Numainfo initialized with defaults.
+func NewNumainfo() (*Numainfo, error) {
+	var (
+		x  Numainfo
+		xc C.libxl_numainfo
+	)
+
+	C.libxl_numainfo_init(&xc)
+	defer C.libxl_numainfo_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Numainfo) fromC(xc *C.libxl_numainfo) error {
+	x.Size = uint64(xc.size)
+	x.Free = uint64(xc.free)
+	x.Dists = nil
+	if n := int(xc.num_dists); n > 0 {
+		cDists := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.dists))[:n:n]
+		x.Dists = make([]uint32, n)
+		for i, v := range cDists {
+			x.Dists[i] = uint32(v)
+		}
+	}
+
+	return nil
+}
+
+func (x *Numainfo) toC(xc *C.libxl_numainfo) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_numainfo_dispose(xc)
+		}
+	}()
+
+	xc.size = C.uint64_t(x.Size)
+	xc.free = C.uint64_t(x.Free)
+	if numDists := len(x.Dists); numDists > 0 {
+		xc.dists = (*C.uint32_t)(C.malloc(C.size_t(numDists * numDists)))
+		xc.num_dists = C.int(numDists)
+		cDists := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.dists))[:numDists:numDists]
+		for i, v := range x.Dists {
+			cDists[i] = C.uint32_t(v)
+		}
+	}
+
+	return nil
+}
+
+// NewCputopology returns an instance of Cputopology initialized with defaults.
+func NewCputopology() (*Cputopology, error) {
+	var (
+		x  Cputopology
+		xc C.libxl_cputopology
+	)
+
+	C.libxl_cputopology_init(&xc)
+	defer C.libxl_cputopology_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Cputopology) fromC(xc *C.libxl_cputopology) error {
+	x.Core = uint32(xc.core)
+	x.Socket = uint32(xc.socket)
+	x.Node = uint32(xc.node)
+
+	return nil
+}
+
+func (x *Cputopology) toC(xc *C.libxl_cputopology) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_cputopology_dispose(xc)
+		}
+	}()
+
+	xc.core = C.uint32_t(x.Core)
+	xc.socket = C.uint32_t(x.Socket)
+	xc.node = C.uint32_t(x.Node)
+
+	return nil
+}
+
+// NewPcitopology returns an instance of Pcitopology initialized with defaults.
+func NewPcitopology() (*Pcitopology, error) {
+	var (
+		x  Pcitopology
+		xc C.libxl_pcitopology
+	)
+
+	C.libxl_pcitopology_init(&xc)
+	defer C.libxl_pcitopology_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Pcitopology) fromC(xc *C.libxl_pcitopology) error {
+	x.Seg = uint16(xc.seg)
+	x.Bus = byte(xc.bus)
+	x.Devfn = byte(xc.devfn)
+	x.Node = uint32(xc.node)
+
+	return nil
+}
+
+func (x *Pcitopology) toC(xc *C.libxl_pcitopology) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_pcitopology_dispose(xc)
+		}
+	}()
+
+	xc.seg = C.uint16_t(x.Seg)
+	xc.bus = C.uint8_t(x.Bus)
+	xc.devfn = C.uint8_t(x.Devfn)
+	xc.node = C.uint32_t(x.Node)
+
+	return nil
+}
+
+// NewSchedCreditParams returns an instance of SchedCreditParams initialized with defaults.
+func NewSchedCreditParams() (*SchedCreditParams, error) {
+	var (
+		x  SchedCreditParams
+		xc C.libxl_sched_credit_params
+	)
+
+	C.libxl_sched_credit_params_init(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *SchedCreditParams) fromC(xc *C.libxl_sched_credit_params) error {
+	x.TsliceMs = int(xc.tslice_ms)
+	x.RatelimitUs = int(xc.ratelimit_us)
+	x.VcpuMigrDelayUs = int(xc.vcpu_migr_delay_us)
+
+	return nil
+}
+
+func (x *SchedCreditParams) toC(xc *C.libxl_sched_credit_params) (err error) {
+	xc.tslice_ms = C.int(x.TsliceMs)
+	xc.ratelimit_us = C.int(x.RatelimitUs)
+	xc.vcpu_migr_delay_us = C.int(x.VcpuMigrDelayUs)
+
+	return nil
+}
+
+// NewSchedCredit2Params returns an instance of SchedCredit2Params initialized with defaults.
+func NewSchedCredit2Params() (*SchedCredit2Params, error) {
+	var (
+		x  SchedCredit2Params
+		xc C.libxl_sched_credit2_params
+	)
+
+	C.libxl_sched_credit2_params_init(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *SchedCredit2Params) fromC(xc *C.libxl_sched_credit2_params) error {
+	x.RatelimitUs = int(xc.ratelimit_us)
+
+	return nil
+}
+
+func (x *SchedCredit2Params) toC(xc *C.libxl_sched_credit2_params) (err error) {
+	xc.ratelimit_us = C.int(x.RatelimitUs)
+
+	return nil
+}
+
+// NewDomainRemusInfo returns an instance of DomainRemusInfo initialized with defaults.
+func NewDomainRemusInfo() (*DomainRemusInfo, error) {
+	var (
+		x  DomainRemusInfo
+		xc C.libxl_domain_remus_info
+	)
+
+	C.libxl_domain_remus_info_init(&xc)
+	defer C.libxl_domain_remus_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *DomainRemusInfo) fromC(xc *C.libxl_domain_remus_info) error {
+	x.Interval = int(xc.interval)
+	if err := x.AllowUnsafe.fromC(&xc.allow_unsafe); err != nil {
+		return fmt.Errorf("converting field AllowUnsafe: %v", err)
+	}
+	if err := x.Blackhole.fromC(&xc.blackhole); err != nil {
+		return fmt.Errorf("converting field Blackhole: %v", err)
+	}
+	if err := x.Compression.fromC(&xc.compression); err != nil {
+		return fmt.Errorf("converting field Compression: %v", err)
+	}
+	if err := x.Netbuf.fromC(&xc.netbuf); err != nil {
+		return fmt.Errorf("converting field Netbuf: %v", err)
+	}
+	x.Netbufscript = C.GoString(xc.netbufscript)
+	if err := x.Diskbuf.fromC(&xc.diskbuf); err != nil {
+		return fmt.Errorf("converting field Diskbuf: %v", err)
+	}
+	if err := x.Colo.fromC(&xc.colo); err != nil {
+		return fmt.Errorf("converting field Colo: %v", err)
+	}
+	if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy); err != nil {
+		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
+	}
+
+	return nil
+}
+
+func (x *DomainRemusInfo) toC(xc *C.libxl_domain_remus_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_domain_remus_info_dispose(xc)
+		}
+	}()
+
+	xc.interval = C.int(x.Interval)
+	if err := x.AllowUnsafe.toC(&xc.allow_unsafe); err != nil {
+		return fmt.Errorf("converting field AllowUnsafe: %v", err)
+	}
+	if err := x.Blackhole.toC(&xc.blackhole); err != nil {
+		return fmt.Errorf("converting field Blackhole: %v", err)
+	}
+	if err := x.Compression.toC(&xc.compression); err != nil {
+		return fmt.Errorf("converting field Compression: %v", err)
+	}
+	if err := x.Netbuf.toC(&xc.netbuf); err != nil {
+		return fmt.Errorf("converting field Netbuf: %v", err)
+	}
+	if x.Netbufscript != "" {
+		xc.netbufscript = C.CString(x.Netbufscript)
+	}
+	if err := x.Diskbuf.toC(&xc.diskbuf); err != nil {
+		return fmt.Errorf("converting field Diskbuf: %v", err)
+	}
+	if err := x.Colo.toC(&xc.colo); err != nil {
+		return fmt.Errorf("converting field Colo: %v", err)
+	}
+	if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil {
+		return fmt.Errorf("converting field UserspaceColoProxy: %v", err)
+	}
+
+	return nil
+}
+
+// NewEvent returns an instance of Event initialized with defaults.
+func NewEvent(etype EventType) (*Event, error) {
+	var (
+		x  Event
+		xc C.libxl_event
+	)
+
+	C.libxl_event_init(&xc)
+	C.libxl_event_init_type(&xc, C.libxl_event_type(etype))
+	defer C.libxl_event_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *Event) fromC(xc *C.libxl_event) error {
+	if err := x.Link.fromC(&xc.link); err != nil {
+		return fmt.Errorf("converting field Link: %v", err)
+	}
+	x.Domid = Domid(xc.domid)
+	if err := x.Domuuid.fromC(&xc.domuuid); err != nil {
+		return fmt.Errorf("converting field Domuuid: %v", err)
+	}
+	x.ForUser = uint64(xc.for_user)
+	x.Type = EventType(xc._type)
+	switch x.Type {
+	case EventTypeDomainShutdown:
+		var typeDomainShutdown EventTypeUnionDomainShutdown
+		if err := typeDomainShutdown.fromC(xc); err != nil {
+			return fmt.Errorf("converting field typeDomainShutdown: %v", err)
+		}
+		x.TypeUnion = typeDomainShutdown
+	case EventTypeDomainDeath:
+		x.TypeUnion = nil
+	case EventTypeDiskEject:
+		var typeDiskEject EventTypeUnionDiskEject
+		if err := typeDiskEject.fromC(xc); err != nil {
+			return fmt.Errorf("converting field typeDiskEject: %v", err)
+		}
+		x.TypeUnion = typeDiskEject
+	case EventTypeOperationComplete:
+		var typeOperationComplete EventTypeUnionOperationComplete
+		if err := typeOperationComplete.fromC(xc); err != nil {
+			return fmt.Errorf("converting field typeOperationComplete: %v", err)
+		}
+		x.TypeUnion = typeOperationComplete
+	case EventTypeDomainCreateConsoleAvailable:
+		x.TypeUnion = nil
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Type)
+	}
+
+	return nil
+}
+
+func (x *EventTypeUnionDomainShutdown) fromC(xc *C.libxl_event) error {
+	if EventType(xc._type) != EventTypeDomainShutdown {
+		return errors.New("expected union key EventTypeDomainShutdown")
+	}
+
+	tmp := (*C.libxl_event_type_union_domain_shutdown)(unsafe.Pointer(&xc.u[0]))
+	x.ShutdownReason = byte(tmp.shutdown_reason)
+	return nil
+}
+
+func (x *EventTypeUnionDiskEject) fromC(xc *C.libxl_event) error {
+	if EventType(xc._type) != EventTypeDiskEject {
+		return errors.New("expected union key EventTypeDiskEject")
+	}
+
+	tmp := (*C.libxl_event_type_union_disk_eject)(unsafe.Pointer(&xc.u[0]))
+	x.Vdev = C.GoString(tmp.vdev)
+	if err := x.Disk.fromC(&tmp.disk); err != nil {
+		return fmt.Errorf("converting field Disk: %v", err)
+	}
+	return nil
+}
+
+func (x *EventTypeUnionOperationComplete) fromC(xc *C.libxl_event) error {
+	if EventType(xc._type) != EventTypeOperationComplete {
+		return errors.New("expected union key EventTypeOperationComplete")
+	}
+
+	tmp := (*C.libxl_event_type_union_operation_complete)(unsafe.Pointer(&xc.u[0]))
+	x.Rc = int(tmp.rc)
+	return nil
+}
+
+func (x *Event) toC(xc *C.libxl_event) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_event_dispose(xc)
+		}
+	}()
+
+	if err := x.Link.toC(&xc.link); err != nil {
+		return fmt.Errorf("converting field Link: %v", err)
+	}
+	xc.domid = C.libxl_domid(x.Domid)
+	if err := x.Domuuid.toC(&xc.domuuid); err != nil {
+		return fmt.Errorf("converting field Domuuid: %v", err)
+	}
+	xc.for_user = C.uint64_t(x.ForUser)
+	xc._type = C.libxl_event_type(x.Type)
+	switch x.Type {
+	case EventTypeDomainShutdown:
+		tmp, ok := x.TypeUnion.(EventTypeUnionDomainShutdown)
+		if !ok {
+			return errors.New("wrong type for union key type")
+		}
+		var domain_shutdown C.libxl_event_type_union_domain_shutdown
+		domain_shutdown.shutdown_reason = C.uint8_t(tmp.ShutdownReason)
+		domain_shutdownBytes := C.GoBytes(unsafe.Pointer(&domain_shutdown), C.sizeof_libxl_event_type_union_domain_shutdown)
+		copy(xc.u[:], domain_shutdownBytes)
+	case EventTypeDomainDeath:
+		break
+	case EventTypeDiskEject:
+		tmp, ok := x.TypeUnion.(EventTypeUnionDiskEject)
+		if !ok {
+			return errors.New("wrong type for union key type")
+		}
+		var disk_eject C.libxl_event_type_union_disk_eject
+		if tmp.Vdev != "" {
+			disk_eject.vdev = C.CString(tmp.Vdev)
+		}
+		if err := tmp.Disk.toC(&disk_eject.disk); err != nil {
+			return fmt.Errorf("converting field Disk: %v", err)
+		}
+		disk_ejectBytes := C.GoBytes(unsafe.Pointer(&disk_eject), C.sizeof_libxl_event_type_union_disk_eject)
+		copy(xc.u[:], disk_ejectBytes)
+	case EventTypeOperationComplete:
+		tmp, ok := x.TypeUnion.(EventTypeUnionOperationComplete)
+		if !ok {
+			return errors.New("wrong type for union key type")
+		}
+		var operation_complete C.libxl_event_type_union_operation_complete
+		operation_complete.rc = C.int(tmp.Rc)
+		operation_completeBytes := C.GoBytes(unsafe.Pointer(&operation_complete), C.sizeof_libxl_event_type_union_operation_complete)
+		copy(xc.u[:], operation_completeBytes)
+	case EventTypeDomainCreateConsoleAvailable:
+		break
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Type)
+	}
+
+	return nil
+}
+
+// NewPsrCatInfo returns an instance of PsrCatInfo initialized with defaults.
+func NewPsrCatInfo() (*PsrCatInfo, error) {
+	var (
+		x  PsrCatInfo
+		xc C.libxl_psr_cat_info
+	)
+
+	C.libxl_psr_cat_info_init(&xc)
+	defer C.libxl_psr_cat_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *PsrCatInfo) fromC(xc *C.libxl_psr_cat_info) error {
+	x.Id = uint32(xc.id)
+	x.CosMax = uint32(xc.cos_max)
+	x.CbmLen = uint32(xc.cbm_len)
+	x.CdpEnabled = bool(xc.cdp_enabled)
+
+	return nil
+}
+
+func (x *PsrCatInfo) toC(xc *C.libxl_psr_cat_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_psr_cat_info_dispose(xc)
+		}
+	}()
+
+	xc.id = C.uint32_t(x.Id)
+	xc.cos_max = C.uint32_t(x.CosMax)
+	xc.cbm_len = C.uint32_t(x.CbmLen)
+	xc.cdp_enabled = C.bool(x.CdpEnabled)
+
+	return nil
+}
+
+// NewPsrHwInfo returns an instance of PsrHwInfo initialized with defaults.
+func NewPsrHwInfo(ptype PsrFeatType) (*PsrHwInfo, error) {
+	var (
+		x  PsrHwInfo
+		xc C.libxl_psr_hw_info
+	)
+
+	C.libxl_psr_hw_info_init(&xc)
+	C.libxl_psr_hw_info_init_type(&xc, C.libxl_psr_feat_type(ptype))
+	defer C.libxl_psr_hw_info_dispose(&xc)
+
+	if err := x.fromC(&xc); err != nil {
+		return nil, err
+	}
+
+	return &x, nil
+}
+
+func (x *PsrHwInfo) fromC(xc *C.libxl_psr_hw_info) error {
+	x.Id = uint32(xc.id)
+	x.Type = PsrFeatType(xc._type)
+	switch x.Type {
+	case PsrFeatTypeCat:
+		var typeCat PsrHwInfoTypeUnionCat
+		if err := typeCat.fromC(xc); err != nil {
+			return fmt.Errorf("converting field typeCat: %v", err)
+		}
+		x.TypeUnion = typeCat
+	case PsrFeatTypeMba:
+		var typeMba PsrHwInfoTypeUnionMba
+		if err := typeMba.fromC(xc); err != nil {
+			return fmt.Errorf("converting field typeMba: %v", err)
+		}
+		x.TypeUnion = typeMba
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Type)
+	}
+
+	return nil
+}
+
+func (x *PsrHwInfoTypeUnionCat) fromC(xc *C.libxl_psr_hw_info) error {
+	if PsrFeatType(xc._type) != PsrFeatTypeCat {
+		return errors.New("expected union key PsrFeatTypeCat")
+	}
+
+	tmp := (*C.libxl_psr_hw_info_type_union_cat)(unsafe.Pointer(&xc.u[0]))
+	x.CosMax = uint32(tmp.cos_max)
+	x.CbmLen = uint32(tmp.cbm_len)
+	x.CdpEnabled = bool(tmp.cdp_enabled)
+	return nil
+}
+
+func (x *PsrHwInfoTypeUnionMba) fromC(xc *C.libxl_psr_hw_info) error {
+	if PsrFeatType(xc._type) != PsrFeatTypeMba {
+		return errors.New("expected union key PsrFeatTypeMba")
+	}
+
+	tmp := (*C.libxl_psr_hw_info_type_union_mba)(unsafe.Pointer(&xc.u[0]))
+	x.CosMax = uint32(tmp.cos_max)
+	x.ThrtlMax = uint32(tmp.thrtl_max)
+	x.Linear = bool(tmp.linear)
+	return nil
+}
+
+func (x *PsrHwInfo) toC(xc *C.libxl_psr_hw_info) (err error) {
+	defer func() {
+		if err != nil {
+			C.libxl_psr_hw_info_dispose(xc)
+		}
+	}()
+
+	xc.id = C.uint32_t(x.Id)
+	xc._type = C.libxl_psr_feat_type(x.Type)
+	switch x.Type {
+	case PsrFeatTypeCat:
+		tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionCat)
+		if !ok {
+			return errors.New("wrong type for union key type")
+		}
+		var cat C.libxl_psr_hw_info_type_union_cat
+		cat.cos_max = C.uint32_t(tmp.CosMax)
+		cat.cbm_len = C.uint32_t(tmp.CbmLen)
+		cat.cdp_enabled = C.bool(tmp.CdpEnabled)
+		catBytes := C.GoBytes(unsafe.Pointer(&cat), C.sizeof_libxl_psr_hw_info_type_union_cat)
+		copy(xc.u[:], catBytes)
+	case PsrFeatTypeMba:
+		tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionMba)
+		if !ok {
+			return errors.New("wrong type for union key type")
+		}
+		var mba C.libxl_psr_hw_info_type_union_mba
+		mba.cos_max = C.uint32_t(tmp.CosMax)
+		mba.thrtl_max = C.uint32_t(tmp.ThrtlMax)
+		mba.linear = C.bool(tmp.Linear)
+		mbaBytes := C.GoBytes(unsafe.Pointer(&mba), C.sizeof_libxl_psr_hw_info_type_union_mba)
+		copy(xc.u[:], mbaBytes)
+	default:
+		return fmt.Errorf("invalid union key '%v'", x.Type)
+	}
+
+	return nil
+}
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
new file mode 100644
index 0000000000..df68fd0e88
--- /dev/null
+++ b/tools/golang/xenlight/types.gen.go
@@ -0,0 +1,1226 @@
+// DO NOT EDIT.
+//
+// This file is generated by:
+// gengotypes.py ../../libxl/libxl_types.idl
+//
+package xenlight
+
+type Error int
+
+const (
+	ErrorNonspecific                  Error = -1
+	ErrorVersion                      Error = -2
+	ErrorFail                         Error = -3
+	ErrorNi                           Error = -4
+	ErrorNomem                        Error = -5
+	ErrorInval                        Error = -6
+	ErrorBadfail                      Error = -7
+	ErrorGuestTimedout                Error = -8
+	ErrorTimedout                     Error = -9
+	ErrorNoparavirt                   Error = -10
+	ErrorNotReady                     Error = -11
+	ErrorOseventRegFail               Error = -12
+	ErrorBufferfull                   Error = -13
+	ErrorUnknownChild                 Error = -14
+	ErrorLockFail                     Error = -15
+	ErrorJsonConfigEmpty              Error = -16
+	ErrorDeviceExists                 Error = -17
+	ErrorCheckpointDevopsDoesNotMatch Error = -18
+	ErrorCheckpointDeviceNotSupported Error = -19
+	ErrorVnumaConfigInvalid           Error = -20
+	ErrorDomainNotfound               Error = -21
+	ErrorAborted                      Error = -22
+	ErrorNotfound                     Error = -23
+	ErrorDomainDestroyed              Error = -24
+	ErrorFeatureRemoved               Error = -25
+	ErrorProtocolErrorQmp             Error = -26
+	ErrorUnknownQmpError              Error = -27
+	ErrorQmpGenericError              Error = -28
+	ErrorQmpCommandNotFound           Error = -29
+	ErrorQmpDeviceNotActive           Error = -30
+	ErrorQmpDeviceNotFound            Error = -31
+	ErrorQemuApi                      Error = -32
+)
+
+type DomainType int
+
+const (
+	DomainTypeInvalid DomainType = -1
+	DomainTypeHvm     DomainType = 1
+	DomainTypePv      DomainType = 2
+	DomainTypePvh     DomainType = 3
+)
+
+type RdmReserveStrategy int
+
+const (
+	RdmReserveStrategyIgnore RdmReserveStrategy = 0
+	RdmReserveStrategyHost   RdmReserveStrategy = 1
+)
+
+type RdmReservePolicy int
+
+const (
+	RdmReservePolicyInvalid RdmReservePolicy = -1
+	RdmReservePolicyStrict  RdmReservePolicy = 0
+	RdmReservePolicyRelaxed RdmReservePolicy = 1
+)
+
+type ChannelConnection int
+
+const (
+	ChannelConnectionUnknown ChannelConnection = 0
+	ChannelConnectionPty     ChannelConnection = 1
+	ChannelConnectionSocket  ChannelConnection = 2
+)
+
+type DeviceModelVersion int
+
+const (
+	DeviceModelVersionUnknown            DeviceModelVersion = 0
+	DeviceModelVersionQemuXenTraditional DeviceModelVersion = 1
+	DeviceModelVersionQemuXen            DeviceModelVersion = 2
+)
+
+type ConsoleType int
+
+const (
+	ConsoleTypeUnknown ConsoleType = 0
+	ConsoleTypeSerial  ConsoleType = 1
+	ConsoleTypePv      ConsoleType = 2
+	ConsoleTypeVuart   ConsoleType = 3
+)
+
+type DiskFormat int
+
+const (
+	DiskFormatUnknown DiskFormat = 0
+	DiskFormatQcow    DiskFormat = 1
+	DiskFormatQcow2   DiskFormat = 2
+	DiskFormatVhd     DiskFormat = 3
+	DiskFormatRaw     DiskFormat = 4
+	DiskFormatEmpty   DiskFormat = 5
+	DiskFormatQed     DiskFormat = 6
+)
+
+type DiskBackend int
+
+const (
+	DiskBackendUnknown DiskBackend = 0
+	DiskBackendPhy     DiskBackend = 1
+	DiskBackendTap     DiskBackend = 2
+	DiskBackendQdisk   DiskBackend = 3
+)
+
+type NicType int
+
+const (
+	NicTypeUnknown  NicType = 0
+	NicTypeVifIoemu NicType = 1
+	NicTypeVif      NicType = 2
+)
+
+type ActionOnShutdown int
+
+const (
+	ActionOnShutdownDestroy         ActionOnShutdown = 1
+	ActionOnShutdownRestart         ActionOnShutdown = 2
+	ActionOnShutdownRestartRename   ActionOnShutdown = 3
+	ActionOnShutdownPreserve        ActionOnShutdown = 4
+	ActionOnShutdownCoredumpDestroy ActionOnShutdown = 5
+	ActionOnShutdownCoredumpRestart ActionOnShutdown = 6
+	ActionOnShutdownSoftReset       ActionOnShutdown = 7
+)
+
+type Trigger int
+
+const (
+	TriggerUnknown  Trigger = 0
+	TriggerPower    Trigger = 1
+	TriggerSleep    Trigger = 2
+	TriggerNmi      Trigger = 3
+	TriggerInit     Trigger = 4
+	TriggerReset    Trigger = 5
+	TriggerS3Resume Trigger = 6
+)
+
+type TscMode int
+
+const (
+	TscModeDefault        TscMode = 0
+	TscModeAlwaysEmulate  TscMode = 1
+	TscModeNative         TscMode = 2
+	TscModeNativeParavirt TscMode = 3
+)
+
+type GfxPassthruKind int
+
+const (
+	GfxPassthruKindDefault GfxPassthruKind = 0
+	GfxPassthruKindIgd     GfxPassthruKind = 1
+)
+
+type TimerMode int
+
+const (
+	TimerModeUnknown               TimerMode = -1
+	TimerModeDelayForMissedTicks   TimerMode = 0
+	TimerModeNoDelayForMissedTicks TimerMode = 1
+	TimerModeNoMissedTicksPending  TimerMode = 2
+	TimerModeOneMissedTickPending  TimerMode = 3
+)
+
+type BiosType int
+
+const (
+	BiosTypeUnknown BiosType = 0
+	BiosTypeRombios BiosType = 1
+	BiosTypeSeabios BiosType = 2
+	BiosTypeOvmf    BiosType = 3
+)
+
+type Scheduler int
+
+const (
+	SchedulerUnknown  Scheduler = 0
+	SchedulerSedf     Scheduler = 4
+	SchedulerCredit   Scheduler = 5
+	SchedulerCredit2  Scheduler = 6
+	SchedulerArinc653 Scheduler = 7
+	SchedulerRtds     Scheduler = 8
+	SchedulerNull     Scheduler = 9
+)
+
+type ShutdownReason int
+
+const (
+	ShutdownReasonUnknown   ShutdownReason = -1
+	ShutdownReasonPoweroff  ShutdownReason = 0
+	ShutdownReasonReboot    ShutdownReason = 1
+	ShutdownReasonSuspend   ShutdownReason = 2
+	ShutdownReasonCrash     ShutdownReason = 3
+	ShutdownReasonWatchdog  ShutdownReason = 4
+	ShutdownReasonSoftReset ShutdownReason = 5
+)
+
+type VgaInterfaceType int
+
+const (
+	VgaInterfaceTypeUnknown VgaInterfaceType = 0
+	VgaInterfaceTypeCirrus  VgaInterfaceType = 1
+	VgaInterfaceTypeStd     VgaInterfaceType = 2
+	VgaInterfaceTypeNone    VgaInterfaceType = 3
+	VgaInterfaceTypeQxl     VgaInterfaceType = 4
+)
+
+type VendorDevice int
+
+const (
+	VendorDeviceNone      VendorDevice = 0
+	VendorDeviceXenserver VendorDevice = 1
+)
+
+type ViridianEnlightenment int
+
+const (
+	ViridianEnlightenmentBase                ViridianEnlightenment = 0
+	ViridianEnlightenmentFreq                ViridianEnlightenment = 1
+	ViridianEnlightenmentTimeRefCount        ViridianEnlightenment = 2
+	ViridianEnlightenmentReferenceTsc        ViridianEnlightenment = 3
+	ViridianEnlightenmentHcallRemoteTlbFlush ViridianEnlightenment = 4
+	ViridianEnlightenmentApicAssist          ViridianEnlightenment = 5
+	ViridianEnlightenmentCrashCtl            ViridianEnlightenment = 6
+	ViridianEnlightenmentSynic               ViridianEnlightenment = 7
+	ViridianEnlightenmentStimer              ViridianEnlightenment = 8
+	ViridianEnlightenmentHcallIpi            ViridianEnlightenment = 9
+)
+
+type Hdtype int
+
+const (
+	HdtypeIde  Hdtype = 1
+	HdtypeAhci Hdtype = 2
+)
+
+type CheckpointedStream int
+
+const (
+	CheckpointedStreamNone  CheckpointedStream = 0
+	CheckpointedStreamRemus CheckpointedStream = 1
+	CheckpointedStreamColo  CheckpointedStream = 2
+)
+
+type VuartType int
+
+const (
+	VuartTypeUnknown  VuartType = 0
+	VuartTypeSbsaUart VuartType = 1
+)
+
+type VkbBackend int
+
+const (
+	VkbBackendUnknown VkbBackend = 0
+	VkbBackendQemu    VkbBackend = 1
+	VkbBackendLinux   VkbBackend = 2
+)
+
+type Passthrough int
+
+const (
+	PassthroughDefault  Passthrough = 0
+	PassthroughDisabled Passthrough = 1
+	PassthroughEnabled  Passthrough = 2
+	PassthroughSyncPt   Passthrough = 3
+	PassthroughSharePt  Passthrough = 4
+)
+
+type IoportRange struct {
+	First  uint32
+	Number uint32
+}
+
+type IomemRange struct {
+	Start  uint64
+	Number uint64
+	Gfn    uint64
+}
+
+type VgaInterfaceInfo struct {
+	Kind VgaInterfaceType
+}
+
+type VncInfo struct {
+	Enable     Defbool
+	Listen     string
+	Passwd     string
+	Display    int
+	Findunused Defbool
+}
+
+type SpiceInfo struct {
+	Enable           Defbool
+	Port             int
+	TlsPort          int
+	Host             string
+	DisableTicketing Defbool
+	Passwd           string
+	AgentMouse       Defbool
+	Vdagent          Defbool
+	ClipboardSharing Defbool
+	Usbredirection   int
+	ImageCompression string
+	StreamingVideo   string
+}
+
+type SdlInfo struct {
+	Enable     Defbool
+	Opengl     Defbool
+	Display    string
+	Xauthority string
+}
+
+type Dominfo struct {
+	Uuid             Uuid
+	Domid            Domid
+	Ssidref          uint32
+	SsidLabel        string
+	Running          bool
+	Blocked          bool
+	Paused           bool
+	Shutdown         bool
+	Dying            bool
+	NeverStop        bool
+	ShutdownReason   ShutdownReason
+	OutstandingMemkb uint64
+	CurrentMemkb     uint64
+	SharedMemkb      uint64
+	PagedMemkb       uint64
+	MaxMemkb         uint64
+	CpuTime          uint64
+	VcpuMaxId        uint32
+	VcpuOnline       uint32
+	Cpupool          uint32
+	DomainType       DomainType
+}
+
+type Cpupoolinfo struct {
+	Poolid   uint32
+	PoolName string
+	Sched    Scheduler
+	NDom     uint32
+	Cpumap   Bitmap
+}
+
+type Channelinfo struct {
+	Backend         string
+	BackendId       uint32
+	Frontend        string
+	FrontendId      uint32
+	Devid           Devid
+	State           int
+	Evtch           int
+	Rref            int
+	Connection      ChannelConnection
+	ConnectionUnion channelinfoConnectionUnion
+}
+
+type channelinfoConnectionUnion interface {
+	ischannelinfoConnectionUnion()
+}
+
+type ChannelinfoConnectionUnionPty struct {
+	Path string
+}
+
+func (x ChannelinfoConnectionUnionPty) ischannelinfoConnectionUnion() {}
+
+type Vminfo struct {
+	Uuid  Uuid
+	Domid Domid
+}
+
+type VersionInfo struct {
+	XenVersionMajor int
+	XenVersionMinor int
+	XenVersionExtra string
+	Compiler        string
+	CompileBy       string
+	CompileDomain   string
+	CompileDate     string
+	Capabilities    string
+	Changeset       string
+	VirtStart       uint64
+	Pagesize        int
+	Commandline     string
+	BuildId         string
+}
+
+type DomainCreateInfo struct {
+	Type                    DomainType
+	Hap                     Defbool
+	Oos                     Defbool
+	Ssidref                 uint32
+	SsidLabel               string
+	Name                    string
+	Domid                   Domid
+	Uuid                    Uuid
+	Xsdata                  KeyValueList
+	Platformdata            KeyValueList
+	Poolid                  uint32
+	PoolName                string
+	RunHotplugScripts       Defbool
+	DriverDomain            Defbool
+	Passthrough             Passthrough
+	XendSuspendEvtchnCompat Defbool
+}
+
+type DomainRestoreParams struct {
+	CheckpointedStream int
+	StreamVersion      uint32
+	ColoProxyScript    string
+	UserspaceColoProxy Defbool
+}
+
+type SchedParams struct {
+	Vcpuid    int
+	Weight    int
+	Cap       int
+	Period    int
+	Extratime int
+	Budget    int
+}
+
+type VcpuSchedParams struct {
+	Sched Scheduler
+	Vcpus []SchedParams
+}
+
+type DomainSchedParams struct {
+	Sched     Scheduler
+	Weight    int
+	Cap       int
+	Period    int
+	Budget    int
+	Extratime int
+	Slice     int
+	Latency   int
+}
+
+type VnodeInfo struct {
+	Memkb     uint64
+	Distances []uint32
+	Pnode     uint32
+	Vcpus     Bitmap
+}
+
+type GicVersion int
+
+const (
+	GicVersionDefault GicVersion = 0
+	GicVersionV2      GicVersion = 32
+	GicVersionV3      GicVersion = 48
+)
+
+type TeeType int
+
+const (
+	TeeTypeNone  TeeType = 0
+	TeeTypeOptee TeeType = 1
+)
+
+type RdmReserve struct {
+	Strategy RdmReserveStrategy
+	Policy   RdmReservePolicy
+}
+
+type Altp2MMode int
+
+const (
+	Altp2MModeDisabled Altp2MMode = 0
+	Altp2MModeMixed    Altp2MMode = 1
+	Altp2MModeExternal Altp2MMode = 2
+	Altp2MModeLimited  Altp2MMode = 3
+)
+
+type DomainBuildInfo struct {
+	MaxVcpus              int
+	AvailVcpus            Bitmap
+	Cpumap                Bitmap
+	Nodemap               Bitmap
+	VcpuHardAffinity      []Bitmap
+	VcpuSoftAffinity      []Bitmap
+	NumaPlacement         Defbool
+	TscMode               TscMode
+	MaxMemkb              uint64
+	TargetMemkb           uint64
+	VideoMemkb            uint64
+	ShadowMemkb           uint64
+	IommuMemkb            uint64
+	RtcTimeoffset         uint32
+	ExecSsidref           uint32
+	ExecSsidLabel         string
+	Localtime             Defbool
+	DisableMigrate        Defbool
+	Cpuid                 CpuidPolicyList
+	BlkdevStart           string
+	VnumaNodes            []VnodeInfo
+	MaxGrantFrames        uint32
+	MaxMaptrackFrames     uint32
+	DeviceModelVersion    DeviceModelVersion
+	DeviceModelStubdomain Defbool
+	DeviceModel           string
+	DeviceModelSsidref    uint32
+	DeviceModelSsidLabel  string
+	DeviceModelUser       string
+	Extra                 StringList
+	ExtraPv               StringList
+	ExtraHvm              StringList
+	SchedParams           DomainSchedParams
+	Ioports               []IoportRange
+	Irqs                  []uint32
+	Iomem                 []IomemRange
+	ClaimMode             Defbool
+	EventChannels         uint32
+	Kernel                string
+	Cmdline               string
+	Ramdisk               string
+	DeviceTree            string
+	Acpi                  Defbool
+	Bootloader            string
+	BootloaderArgs        StringList
+	TimerMode             TimerMode
+	NestedHvm             Defbool
+	Apic                  Defbool
+	DmRestrict            Defbool
+	Tee                   TeeType
+	Type                  DomainType
+	TypeUnion             domainBuildInfoTypeUnion
+	ArchArm               struct {
+		GicVersion GicVersion
+		Vuart      VuartType
+	}
+	Altp2M Altp2MMode
+}
+
+type domainBuildInfoTypeUnion interface {
+	isdomainBuildInfoTypeUnion()
+}
+
+type DomainBuildInfoTypeUnionHvm struct {
+	Firmware            string
+	Bios                BiosType
+	Pae                 Defbool
+	Apic                Defbool
+	Acpi                Defbool
+	AcpiS3              Defbool
+	AcpiS4              Defbool
+	AcpiLaptopSlate     Defbool
+	Nx                  Defbool
+	Viridian            Defbool
+	ViridianEnable      Bitmap
+	ViridianDisable     Bitmap
+	Timeoffset          string
+	Hpet                Defbool
+	VptAlign            Defbool
+	MmioHoleMemkb       uint64
+	TimerMode           TimerMode
+	NestedHvm           Defbool
+	Altp2M              Defbool
+	SystemFirmware      string
+	SmbiosFirmware      string
+	AcpiFirmware        string
+	Hdtype              Hdtype
+	Nographic           Defbool
+	Vga                 VgaInterfaceInfo
+	Vnc                 VncInfo
+	Keymap              string
+	Sdl                 SdlInfo
+	Spice               SpiceInfo
+	GfxPassthru         Defbool
+	GfxPassthruKind     GfxPassthruKind
+	Serial              string
+	Boot                string
+	Usb                 Defbool
+	Usbversion          int
+	Usbdevice           string
+	VkbDevice           Defbool
+	Soundhw             string
+	XenPlatformPci      Defbool
+	UsbdeviceList       StringList
+	VendorDevice        VendorDevice
+	MsVmGenid           MsVmGenid
+	SerialList          StringList
+	Rdm                 RdmReserve
+	RdmMemBoundaryMemkb uint64
+	McaCaps             uint64
+}
+
+func (x DomainBuildInfoTypeUnionHvm) isdomainBuildInfoTypeUnion() {}
+
+type DomainBuildInfoTypeUnionPv struct {
+	Kernel         string
+	SlackMemkb     uint64
+	Bootloader     string
+	BootloaderArgs StringList
+	Cmdline        string
+	Ramdisk        string
+	Features       string
+	E820Host       Defbool
+}
+
+func (x DomainBuildInfoTypeUnionPv) isdomainBuildInfoTypeUnion() {}
+
+type DomainBuildInfoTypeUnionPvh struct {
+	Pvshim        Defbool
+	PvshimPath    string
+	PvshimCmdline string
+	PvshimExtra   string
+}
+
+func (x DomainBuildInfoTypeUnionPvh) isdomainBuildInfoTypeUnion() {}
+
+type DeviceVfb struct {
+	BackendDomid   Domid
+	BackendDomname string
+	Devid          Devid
+	Vnc            VncInfo
+	Sdl            SdlInfo
+	Keymap         string
+}
+
+type DeviceVkb struct {
+	BackendDomid           Domid
+	BackendDomname         string
+	Devid                  Devid
+	BackendType            VkbBackend
+	UniqueId               string
+	FeatureDisableKeyboard bool
+	FeatureDisablePointer  bool
+	FeatureAbsPointer      bool
+	FeatureRawPointer      bool
+	FeatureMultiTouch      bool
+	Width                  uint32
+	Height                 uint32
+	MultiTouchWidth        uint32
+	MultiTouchHeight       uint32
+	MultiTouchNumContacts  uint32
+}
+
+type DeviceDisk struct {
+	BackendDomid      Domid
+	BackendDomname    string
+	PdevPath          string
+	Vdev              string
+	Backend           DiskBackend
+	Format            DiskFormat
+	Script            string
+	Removable         int
+	Readwrite         int
+	IsCdrom           int
+	DirectIoSafe      bool
+	DiscardEnable     Defbool
+	ColoEnable        Defbool
+	ColoRestoreEnable Defbool
+	ColoHost          string
+	ColoPort          int
+	ColoExport        string
+	ActiveDisk        string
+	HiddenDisk        string
+}
+
+type DeviceNic struct {
+	BackendDomid                   Domid
+	BackendDomname                 string
+	Devid                          Devid
+	Mtu                            int
+	Model                          string
+	Mac                            Mac
+	Ip                             string
+	Bridge                         string
+	Ifname                         string
+	Script                         string
+	Nictype                        NicType
+	RateBytesPerInterval           uint64
+	RateIntervalUsecs              uint32
+	Gatewaydev                     string
+	ColoftForwarddev               string
+	ColoSockMirrorId               string
+	ColoSockMirrorIp               string
+	ColoSockMirrorPort             string
+	ColoSockComparePriInId         string
+	ColoSockComparePriInIp         string
+	ColoSockComparePriInPort       string
+	ColoSockCompareSecInId         string
+	ColoSockCompareSecInIp         string
+	ColoSockCompareSecInPort       string
+	ColoSockCompareNotifyId        string
+	ColoSockCompareNotifyIp        string
+	ColoSockCompareNotifyPort      string
+	ColoSockRedirector0Id          string
+	ColoSockRedirector0Ip          string
+	ColoSockRedirector0Port        string
+	ColoSockRedirector1Id          string
+	ColoSockRedirector1Ip          string
+	ColoSockRedirector1Port        string
+	ColoSockRedirector2Id          string
+	ColoSockRedirector2Ip          string
+	ColoSockRedirector2Port        string
+	ColoFilterMirrorQueue          string
+	ColoFilterMirrorOutdev         string
+	ColoFilterRedirector0Queue     string
+	ColoFilterRedirector0Indev     string
+	ColoFilterRedirector0Outdev    string
+	ColoFilterRedirector1Queue     string
+	ColoFilterRedirector1Indev     string
+	ColoFilterRedirector1Outdev    string
+	ColoComparePriIn               string
+	ColoCompareSecIn               string
+	ColoCompareOut                 string
+	ColoCompareNotifyDev           string
+	ColoSockSecRedirector0Id       string
+	ColoSockSecRedirector0Ip       string
+	ColoSockSecRedirector0Port     string
+	ColoSockSecRedirector1Id       string
+	ColoSockSecRedirector1Ip       string
+	ColoSockSecRedirector1Port     string
+	ColoFilterSecRedirector0Queue  string
+	ColoFilterSecRedirector0Indev  string
+	ColoFilterSecRedirector0Outdev string
+	ColoFilterSecRedirector1Queue  string
+	ColoFilterSecRedirector1Indev  string
+	ColoFilterSecRedirector1Outdev string
+	ColoFilterSecRewriter0Queue    string
+	ColoCheckpointHost             string
+	ColoCheckpointPort             string
+}
+
+type DevicePci struct {
+	Func         byte
+	Dev          byte
+	Bus          byte
+	Domain       int
+	Vdevfn       uint32
+	VfuncMask    uint32
+	Msitranslate bool
+	PowerMgmt    bool
+	Permissive   bool
+	Seize        bool
+	RdmPolicy    RdmReservePolicy
+}
+
+type DeviceRdm struct {
+	Start  uint64
+	Size   uint64
+	Policy RdmReservePolicy
+}
+
+type UsbctrlType int
+
+const (
+	UsbctrlTypeAuto        UsbctrlType = 0
+	UsbctrlTypePv          UsbctrlType = 1
+	UsbctrlTypeDevicemodel UsbctrlType = 2
+	UsbctrlTypeQusb        UsbctrlType = 3
+)
+
+type UsbdevType int
+
+const (
+	UsbdevTypeHostdev UsbdevType = 1
+)
+
+type DeviceUsbctrl struct {
+	Type           UsbctrlType
+	Devid          Devid
+	Version        int
+	Ports          int
+	BackendDomid   Domid
+	BackendDomname string
+}
+
+type DeviceUsbdev struct {
+	Ctrl      Devid
+	Port      int
+	Type      UsbdevType
+	TypeUnion deviceUsbdevTypeUnion
+}
+
+type deviceUsbdevTypeUnion interface {
+	isdeviceUsbdevTypeUnion()
+}
+
+type DeviceUsbdevTypeUnionHostdev struct {
+	Hostbus  byte
+	Hostaddr byte
+}
+
+func (x DeviceUsbdevTypeUnionHostdev) isdeviceUsbdevTypeUnion() {}
+
+type DeviceDtdev struct {
+	Path string
+}
+
+type DeviceVtpm struct {
+	BackendDomid   Domid
+	BackendDomname string
+	Devid          Devid
+	Uuid           Uuid
+}
+
+type DeviceP9 struct {
+	BackendDomid   Domid
+	BackendDomname string
+	Tag            string
+	Path           string
+	SecurityModel  string
+	Devid          Devid
+}
+
+type DevicePvcallsif struct {
+	BackendDomid   Domid
+	BackendDomname string
+	Devid          Devid
+}
+
+type DeviceChannel struct {
+	BackendDomid    Domid
+	BackendDomname  string
+	Devid           Devid
+	Name            string
+	Connection      ChannelConnection
+	ConnectionUnion deviceChannelConnectionUnion
+}
+
+type deviceChannelConnectionUnion interface {
+	isdeviceChannelConnectionUnion()
+}
+
+type DeviceChannelConnectionUnionSocket struct {
+	Path string
+}
+
+func (x DeviceChannelConnectionUnionSocket) isdeviceChannelConnectionUnion() {}
+
+type ConnectorParam struct {
+	UniqueId string
+	Width    uint32
+	Height   uint32
+}
+
+type DeviceVdispl struct {
+	BackendDomid   Domid
+	BackendDomname string
+	Devid          Devid
+	BeAlloc        bool
+	Connectors     []ConnectorParam
+}
+
+type VsndPcmFormat int
+
+const (
+	VsndPcmFormatS8               VsndPcmFormat = 1
+	VsndPcmFormatU8               VsndPcmFormat = 2
+	VsndPcmFormatS16Le            VsndPcmFormat = 3
+	VsndPcmFormatS16Be            VsndPcmFormat = 4
+	VsndPcmFormatU16Le            VsndPcmFormat = 5
+	VsndPcmFormatU16Be            VsndPcmFormat = 6
+	VsndPcmFormatS24Le            VsndPcmFormat = 7
+	VsndPcmFormatS24Be            VsndPcmFormat = 8
+	VsndPcmFormatU24Le            VsndPcmFormat = 9
+	VsndPcmFormatU24Be            VsndPcmFormat = 10
+	VsndPcmFormatS32Le            VsndPcmFormat = 11
+	VsndPcmFormatS32Be            VsndPcmFormat = 12
+	VsndPcmFormatU32Le            VsndPcmFormat = 13
+	VsndPcmFormatU32Be            VsndPcmFormat = 14
+	VsndPcmFormatF32Le            VsndPcmFormat = 15
+	VsndPcmFormatF32Be            VsndPcmFormat = 16
+	VsndPcmFormatF64Le            VsndPcmFormat = 17
+	VsndPcmFormatF64Be            VsndPcmFormat = 18
+	VsndPcmFormatIec958SubframeLe VsndPcmFormat = 19
+	VsndPcmFormatIec958SubframeBe VsndPcmFormat = 20
+	VsndPcmFormatMuLaw            VsndPcmFormat = 21
+	VsndPcmFormatALaw             VsndPcmFormat = 22
+	VsndPcmFormatImaAdpcm         VsndPcmFormat = 23
+	VsndPcmFormatMpeg             VsndPcmFormat = 24
+	VsndPcmFormatGsm              VsndPcmFormat = 25
+)
+
+type VsndParams struct {
+	SampleRates   []uint32
+	SampleFormats []VsndPcmFormat
+	ChannelsMin   uint32
+	ChannelsMax   uint32
+	BufferSize    uint32
+}
+
+type VsndStreamType int
+
+const (
+	VsndStreamTypeP VsndStreamType = 1
+	VsndStreamTypeC VsndStreamType = 2
+)
+
+type VsndStream struct {
+	UniqueId string
+	Type     VsndStreamType
+	Params   VsndParams
+}
+
+type VsndPcm struct {
+	Name    string
+	Params  VsndParams
+	Streams []VsndStream
+}
+
+type DeviceVsnd struct {
+	BackendDomid   Domid
+	BackendDomname string
+	Devid          Devid
+	ShortName      string
+	LongName       string
+	Params         VsndParams
+	Pcms           []VsndPcm
+}
+
+type DomainConfig struct {
+	CInfo       DomainCreateInfo
+	BInfo       DomainBuildInfo
+	Disks       []DeviceDisk
+	Nics        []DeviceNic
+	Pcidevs     []DevicePci
+	Rdms        []DeviceRdm
+	Dtdevs      []DeviceDtdev
+	Vfbs        []DeviceVfb
+	Vkbs        []DeviceVkb
+	Vtpms       []DeviceVtpm
+	P9S         []DeviceP9
+	Pvcallsifs  []DevicePvcallsif
+	Vdispls     []DeviceVdispl
+	Vsnds       []DeviceVsnd
+	Channels    []DeviceChannel
+	Usbctrls    []DeviceUsbctrl
+	Usbdevs     []DeviceUsbdev
+	OnPoweroff  ActionOnShutdown
+	OnReboot    ActionOnShutdown
+	OnWatchdog  ActionOnShutdown
+	OnCrash     ActionOnShutdown
+	OnSoftReset ActionOnShutdown
+}
+
+type Diskinfo struct {
+	Backend    string
+	BackendId  uint32
+	Frontend   string
+	FrontendId uint32
+	Devid      Devid
+	State      int
+	Evtch      int
+	Rref       int
+}
+
+type Nicinfo struct {
+	Backend    string
+	BackendId  uint32
+	Frontend   string
+	FrontendId uint32
+	Devid      Devid
+	State      int
+	Evtch      int
+	RrefTx     int
+	RrefRx     int
+}
+
+type Vtpminfo struct {
+	Backend    string
+	BackendId  uint32
+	Frontend   string
+	FrontendId uint32
+	Devid      Devid
+	State      int
+	Evtch      int
+	Rref       int
+	Uuid       Uuid
+}
+
+type Usbctrlinfo struct {
+	Type       UsbctrlType
+	Devid      Devid
+	Version    int
+	Ports      int
+	Backend    string
+	BackendId  uint32
+	Frontend   string
+	FrontendId uint32
+	State      int
+	Evtch      int
+	RefUrb     int
+	RefConn    int
+}
+
+type Vcpuinfo struct {
+	Vcpuid     uint32
+	Cpu        uint32
+	Online     bool
+	Blocked    bool
+	Running    bool
+	VcpuTime   uint64
+	Cpumap     Bitmap
+	CpumapSoft Bitmap
+}
+
+type Physinfo struct {
+	ThreadsPerCore     uint32
+	CoresPerSocket     uint32
+	MaxCpuId           uint32
+	NrCpus             uint32
+	CpuKhz             uint32
+	TotalPages         uint64
+	FreePages          uint64
+	ScrubPages         uint64
+	OutstandingPages   uint64
+	SharingFreedPages  uint64
+	SharingUsedFrames  uint64
+	MaxPossibleMfn     uint64
+	NrNodes            uint32
+	HwCap              Hwcap
+	CapHvm             bool
+	CapPv              bool
+	CapHvmDirectio     bool
+	CapHap             bool
+	CapShadow          bool
+	CapIommuHapPtShare bool
+}
+
+type Connectorinfo struct {
+	UniqueId string
+	Width    uint32
+	Height   uint32
+	ReqEvtch int
+	ReqRref  int
+	EvtEvtch int
+	EvtRref  int
+}
+
+type Vdisplinfo struct {
+	Backend    string
+	BackendId  uint32
+	Frontend   string
+	FrontendId uint32
+	Devid      Devid
+	State      int
+	BeAlloc    bool
+	Connectors []Connectorinfo
+}
+
+type Streaminfo struct {
+	ReqEvtch int
+	ReqRref  int
+}
+
+type Pcminfo struct {
+	Streams []Streaminfo
+}
+
+type Vsndinfo struct {
+	Backend    string
+	BackendId  uint32
+	Frontend   string
+	FrontendId uint32
+	Devid      Devid
+	State      int
+	Pcms       []Pcminfo
+}
+
+type Vkbinfo struct {
+	Backend    string
+	BackendId  uint32
+	Frontend   string
+	FrontendId uint32
+	Devid      Devid
+	State      int
+	Evtch      int
+	Rref       int
+}
+
+type Numainfo struct {
+	Size  uint64
+	Free  uint64
+	Dists []uint32
+}
+
+type Cputopology struct {
+	Core   uint32
+	Socket uint32
+	Node   uint32
+}
+
+type Pcitopology struct {
+	Seg   uint16
+	Bus   byte
+	Devfn byte
+	Node  uint32
+}
+
+type SchedCreditParams struct {
+	TsliceMs        int
+	RatelimitUs     int
+	VcpuMigrDelayUs int
+}
+
+type SchedCredit2Params struct {
+	RatelimitUs int
+}
+
+type DomainRemusInfo struct {
+	Interval           int
+	AllowUnsafe        Defbool
+	Blackhole          Defbool
+	Compression        Defbool
+	Netbuf             Defbool
+	Netbufscript       string
+	Diskbuf            Defbool
+	Colo               Defbool
+	UserspaceColoProxy Defbool
+}
+
+type EventType int
+
+const (
+	EventTypeDomainShutdown               EventType = 1
+	EventTypeDomainDeath                  EventType = 2
+	EventTypeDiskEject                    EventType = 3
+	EventTypeOperationComplete            EventType = 4
+	EventTypeDomainCreateConsoleAvailable EventType = 5
+)
+
+type Event struct {
+	Link      EvLink
+	Domid     Domid
+	Domuuid   Uuid
+	ForUser   uint64
+	Type      EventType
+	TypeUnion eventTypeUnion
+}
+
+type eventTypeUnion interface {
+	iseventTypeUnion()
+}
+
+type EventTypeUnionDomainShutdown struct {
+	ShutdownReason byte
+}
+
+func (x EventTypeUnionDomainShutdown) iseventTypeUnion() {}
+
+type EventTypeUnionDiskEject struct {
+	Vdev string
+	Disk DeviceDisk
+}
+
+func (x EventTypeUnionDiskEject) iseventTypeUnion() {}
+
+type EventTypeUnionOperationComplete struct {
+	Rc int
+}
+
+func (x EventTypeUnionOperationComplete) iseventTypeUnion() {}
+
+type PsrCmtType int
+
+const (
+	PsrCmtTypeCacheOccupancy PsrCmtType = 1
+	PsrCmtTypeTotalMemCount  PsrCmtType = 2
+	PsrCmtTypeLocalMemCount  PsrCmtType = 3
+)
+
+type PsrCbmType int
+
+const (
+	PsrCbmTypeUnknown   PsrCbmType = 0
+	PsrCbmTypeL3Cbm     PsrCbmType = 1
+	PsrCbmTypeL3CbmCode PsrCbmType = 2
+	PsrCbmTypeL3CbmData PsrCbmType = 3
+	PsrCbmTypeL2Cbm     PsrCbmType = 4
+	PsrCbmTypeMbaThrtl  PsrCbmType = 5
+)
+
+type PsrCatInfo struct {
+	Id         uint32
+	CosMax     uint32
+	CbmLen     uint32
+	CdpEnabled bool
+}
+
+type PsrFeatType int
+
+const (
+	PsrFeatTypeCat PsrFeatType = 1
+	PsrFeatTypeMba PsrFeatType = 2
+)
+
+type PsrHwInfo struct {
+	Id        uint32
+	Type      PsrFeatType
+	TypeUnion psrHwInfoTypeUnion
+}
+
+type psrHwInfoTypeUnion interface {
+	ispsrHwInfoTypeUnion()
+}
+
+type PsrHwInfoTypeUnionCat struct {
+	CosMax     uint32
+	CbmLen     uint32
+	CdpEnabled bool
+}
+
+func (x PsrHwInfoTypeUnionCat) ispsrHwInfoTypeUnion() {}
+
+type PsrHwInfoTypeUnionMba struct {
+	CosMax   uint32
+	ThrtlMax uint32
+	Linear   bool
+}
+
+func (x PsrHwInfoTypeUnionMba) ispsrHwInfoTypeUnion() {}
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Thu Apr 30 22:24:31 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 22:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUHbD-0004MN-2b; Thu, 30 Apr 2020 22:24:07 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CihJ=6O=linux-foundation.org=akpm@srs-us1.protection.inumbo.net>)
 id 1jUHbB-0004MI-S1
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 22:24:05 +0000
X-Inumbo-ID: 4cccbd9e-8b31-11ea-9ac1-12813bfff9fa
Received: from mail.kernel.org (unknown [198.145.29.99])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id 4cccbd9e-8b31-11ea-9ac1-12813bfff9fa;
 Thu, 30 Apr 2020 22:24:05 +0000 (UTC)
Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net
 [73.231.172.41])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 94AC1206D9;
 Thu, 30 Apr 2020 22:24:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1588285444;
 bh=U2wS06jC9o9pM52AkSococGuM+XgTOL9WOXR44wwwmQ=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=nB8mUJ6Pr+ljhrNsFLIKSdctC/llz+t2pcx7JDOh0oPr8VKQWeTBxDI7E+xMeStLC
 YJG+PTTpUS++FiCEfMHnakKMR5tEwypkxH9WzJR3NY+WaET9iOTNnwJL1dKYZQ2hQo
 n2b6cYRnfH+6fRINH9l/gw+LAzU9FuEWW69YHNxU=
Date: Thu, 30 Apr 2020 15:24:03 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Message-Id: <20200430152403.e0d6da5eb1cad06411ac6d46@linux-foundation.org>
In-Reply-To: <b28c9e02-8cf2-33ae-646b-fe50a185738e@redhat.com>
References: <20200430102908.10107-1-david@redhat.com>
 <20200430102908.10107-3-david@redhat.com>
 <87pnbp2dcz.fsf@x220.int.ebiederm.org>
 <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
 <871ro52ary.fsf@x220.int.ebiederm.org>
 <373a6898-4020-4af1-5b3d-f827d705dd77@redhat.com>
 <875zdg26hp.fsf@x220.int.ebiederm.org>
 <b28c9e02-8cf2-33ae-646b-fe50a185738e@redhat.com>
X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
 Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
 linux-acpi@vger.kernel.org, Wei Yang <richard.weiyang@gmail.com>,
 linux-s390@vger.kernel.org, linux-nvdimm@lists.01.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
 linux-mm@kvack.org, "Michael S . Tsirkin" <mst@redhat.com>,
 "Eric W. Biederman" <ebiederm@xmission.com>,
 Pankaj Gupta <pankaj.gupta.linux@gmail.com>, xen-devel@lists.xenproject.org,
 Michal Hocko <mhocko@kernel.org>, linuxppc-dev@lists.ozlabs.org
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david@redhat.com> wrote:

> > 
> > Why does the firmware map support hotplug entries?
> 
> I assume:
> 
> The firmware memmap was added primarily for x86-64 kexec (and still, is
> mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs
> get hotplugged on real HW, they get added to e820. Same applies to
> memory added via HyperV balloon (unless memory is unplugged via
> ballooning and you reboot ... the the e820 is changed as well). I assume
> we wanted to be able to reflect that, to make kexec look like a real reboot.
> 
> This worked for a while. Then came dax/kmem. Now comes virtio-mem.
> 
> 
> But I assume only Andrew can enlighten us.
> 
> @Andrew, any guidance here? Should we really add all memory to the
> firmware memmap, even if this contradicts with the existing
> documentation? (especially, if the actual firmware memmap will *not*
> contain that memory after a reboot)

For some reason that patch is misattributed - it was authored by
Shaohui Zheng <shaohui.zheng@intel.com>, who hasn't been heard from in
a decade.  I looked through the email discussion from that time and I'm
not seeing anything useful.  But I wasn't able to locate Dave Hansen's
review comments.




From xen-devel-bounces@lists.xenproject.org Thu Apr 30 22:27:24 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 22:27:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUHeO-0004TZ-G5; Thu, 30 Apr 2020 22:27:24 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jGNe=6O=invisiblethingslab.com=marmarek@srs-us1.protection.inumbo.net>)
 id 1jUHeM-0004TU-Qc
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 22:27:23 +0000
X-Inumbo-ID: c27cd6f0-8b31-11ea-ae69-bc764e2007e4
Received: from out3-smtp.messagingengine.com (unknown [66.111.4.27])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id c27cd6f0-8b31-11ea-ae69-bc764e2007e4;
 Thu, 30 Apr 2020 22:27:22 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailout.nyi.internal (Postfix) with ESMTP id EE4875C008E;
 Thu, 30 Apr 2020 18:27:21 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute3.internal (MEProxy); Thu, 30 Apr 2020 18:27:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=tu6fQI
 GLVqP401hYJBo2JmEUMbfen8l7Ynb5clEVg/o=; b=cRkop69obxub7GCuItFLxw
 WRoPuk+HaSEt9z0x9T5JHx0uUBjh97ZiSAhmJXgGyCQH8ENTHyF8LF8T0hsZMghf
 3s9zQTzTl1QLaZ4s/79tJWiZNiSuBpceELguQy6heMm2gjGZn0kvJ0u75/KzfzU6
 SAU+fXEBeFDHb33g8ZNWxgLmZ9kJXWAxtStw+TviDEZzBhad9GZ57Xeyznv2e4bQ
 7sgjVmZri8CLxjYM2MMaVqQZQIp3ezPS8mGaUA8UTRcYCP4NoLVskNFAZ+ua17tq
 H8ZMczJW7C+2rDq0ErQoNRN9ynYVkaPaKr70c9kfUpcKZzUOf7a6bYNBfdGe+Jng
 ==
X-ME-Sender: <xms:yVCrXqLZyuUnVCwr1OWB0D0NXexYRkebEal7YbmgXnCvatmSUPY0DQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieeigddtlecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu
 ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
 hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepjeehkeel
 hfdvfedviedvveehffefteeiteehteekteeileehjefhveeutdekledvnecuffhomhgrih
 hnpehhthhtphdrihhnnecukfhppeeluddrieehrdefgedrfeefnecuvehluhhsthgvrhfu
 ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvih
 hsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: <xmx:yVCrXrGzBB5hTOgzSk-XTGizVI4DUu50GfnPWddmMtmREB6RO2xvIg>
 <xmx:yVCrXspzNcTZOUJPk56rYisfR5GutrlVFv-9km11xn2uUfLBxGgh_Q>
 <xmx:yVCrXsR7llY7Iuz0zY6VGxheSlTg6ktuBu5ntUoDKV8QbPJRVcaF-A>
 <xmx:yVCrXvPCrPnJ-WLF_WBm2daChV6NZs3H1Mi1BkVCFejMm7iTk6oyGQ>
Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33])
 by mail.messagingengine.com (Postfix) with ESMTPA id 5E10F3280067;
 Thu, 30 Apr 2020 18:27:20 -0400 (EDT)
Date: Fri, 1 May 2020 00:27:17 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
To: Bobby Eshleman <bobbyeshleman@gmail.com>
Subject: Re: [RFC] UEFI Secure Boot on Xen Hosts
Message-ID: <20200430222717.GA6364@mail-itl>
References: <20200429225108.GA54201@bobbye-pc>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l"
Content-Disposition: inline
In-Reply-To: <20200429225108.GA54201@bobbye-pc>
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: michal.zygowski@3mdeb.com, daniel.kiper@oracle.com,
 krystian.hebel@3mdeb.com, xen-devel@lists.xenproject.org,
 olivier.lambert@vates.fr, piotr.krol@3mdeb.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>


--XsQoSWH+UP9D9v3l
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [RFC] UEFI Secure Boot on Xen Hosts

On Wed, Apr 29, 2020 at 05:51:08PM -0500, Bobby Eshleman wrote:
> # Option #3: Lean on Grub2's LoadFile2() Verification
>=20
> Grub2 will provide a LoadFile2() method to subsequent programs that suppo=
rts
> signature verification of arbitrary files.  Linux is moving in the
> direction of using LoadFile2() for loading the initrd [2], and Grub2 will
> support verifying the signatures of files loaded via LoadFile2().=20

This description gives me flashbacks to how xen.efi loads dom0
kernel+initramfs (Loaded Image Protocol). Practical issues encountered:

1. It works only when xen.efi is loaded via appropriate EFI boot
service directly. If xen.efi is loaded by a filesystem driver in
grub/other bootloader, it can't load dom0 kernel+initramfs.

2. Given variety of UEFI implementations and boot medias, it was almost
impossible to force bootloader to use the right file loading method
(cases like the same file accessible both via UEFI fs0: and via grub's
filesystem driver). Which means loading xen.efi via a bootloader (as
opposed to directly from UEFI) was hit or miss (mostly miss).

3. To avoid the above issue, one was forced to load xen.efi directly
=66rom EFI. This gave up any possibility to manipulate xen cmdline, or
even choose system to boot in case of some EFI implementations.

4. Even if one is lucky to boot xen.efi via grub2-efi, then still only
xen options could be modified. But not those for dom0.

5. It was impossible to load xen/kernel/initrd using fancy grub/ipxe
features like HTTP.

In practice the above points mean:

* To get a usable product, one is forced to enable all kind of
  workarounds (not only related to EFI) _in default configuration_,
  because otherwise there is very little chance to enable them only when
  needed.

* If something goes wrong, in most cases you need to boot from
  alternative media (to edit xen.cfg, or efi variables). If you happen
  to forget your rescue usb stick, you are out of luck.

So, please, can someone confirm the LoadFile2() approach wouldn't have
any of the above issues?

> This is set
> for release in GRUB 2.06 sometime in the latter half of 2020.
>=20
> In Xen, this approach could be used for loading dom0 as well, offering a =
very
> simple verified load interface.
>=20
> Currently the initrd argument passed from Linux to LoadFile2() is a vendor
> media device path GUID [3].
>=20
> Changes to Xen:
> - Xen would need to pass these device paths to Grub
> - Xen would be changed to load dom0 with the LoadFile2() interface via bo=
ot services
>=20
> Changes to Grub:
> - Xen dom0 kernel/initrd device paths would need to be introduced to Grub
>=20
> Potential Issues:
> - How will Xen handle more boot modules than just a dom0 and dom0
>   initrd?
> - Would each boot module need a unique vendor guid?

Both above points applies for example to loading dom0
kernel+initrd+microcode update+xsm.

> - Would this interfere with the DomB proposal?  I suspect not because
>   the DomB proposal suggests launching DomUs from an already booted
>   DomB, at which point other means could be used.

domB probably not, but what about dom0less, where multiple domains are
loaded by Xen itself? I know dom0less currently is ARM only (not sure
how that relates to EFI, if at all), but I think in general it would be
good to plan for supporting more modules.

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl6rUMQACgkQ24/THMrX
1yzMLwf5ARUssFF46x1oNhWhkBv9iOECgnnKvT86eUlgrxA5TP/92nZoNv72E444
NaekJSR9KbNpIvh+0uwsbSUPTIlUsaa82bUVfJpgF4EKmGtmlpct24t8dlE9Kc7m
Kln6cEcnm99bAUA0LV3IfZZFNy9lCIIBu6MvBHjIewSdV81QqXBbe6AX1Hiwo/IF
fhdHkekpct/d/osIUnXrzgzN1DcjbFs/AuLq4hebJvnnraqS2aNwczwftzREKKOp
MEEoh9ScGvAbSFdyENMQTOT/8m6sXRF+MHOJ0Jx+xpGeGBP5KFRI8kJH22y4aXKC
cQz1ASdmCWU9kPKhdQfskLisGeXRWw==
=q+QN
-----END PGP SIGNATURE-----

--XsQoSWH+UP9D9v3l--


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 22:34:42 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 22:34:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUHlL-0005L3-5j; Thu, 30 Apr 2020 22:34:35 +0000
Received: from all-amaz-eas1.inumbo.com ([34.197.232.57]
 helo=us1-amaz-eas2.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DLrL=6O=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jUHlJ-0005Ky-9O
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 22:34:33 +0000
X-Inumbo-ID: bd84e362-8b32-11ea-9ac1-12813bfff9fa
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS
 id bd84e362-8b32-11ea-9ac1-12813bfff9fa;
 Thu, 30 Apr 2020 22:34:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=9j0BF2JgExta+2a9BjXYPeYNAI7fyAVCR8W70/G6pKI=; b=5JkXErMtSwus+REqA29iQ3sDY
 bMDTRFxv6rV0TYABEvYd4W+ytS2i6pJrd2xss8G5YGXY3fljTQfqx1OTRwndj3FmtU4ye6BM4Bhkq
 r3yg2C3K693s4g1jwvUYAEKbECFNEHcda5b/07AEOTLI40QVvM06pMrRaZIDODsicr28U=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUHl9-0006SC-2U; Thu, 30 Apr 2020 22:34:23 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUHl8-000475-PL; Thu, 30 Apr 2020 22:34:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jUHl8-0001CU-Oc; Thu, 30 Apr 2020 22:34:22 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149891-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 149891: all pass - PUSHED
X-Osstest-Versions-This: ovmf=e54310451f1ac2ce4ccb90a110f45bb9b4f3ccd6
X-Osstest-Versions-That: ovmf=f07fb43b2d3f92a15d6992205b72ba5df0e74fe2
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 30 Apr 2020 22:34:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149891 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149891/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 e54310451f1ac2ce4ccb90a110f45bb9b4f3ccd6
baseline version:
 ovmf                 f07fb43b2d3f92a15d6992205b72ba5df0e74fe2

Last test of basis   149887  2020-04-30 04:39:28 Z    0 days
Testing same since   149891  2020-04-30 16:10:01 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@arm.com>
  Laszlo Ersek <lersek@redhat.com>
  Rebecca Cran <rebecca@bsdio.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   f07fb43b2d..e54310451f  e54310451f1ac2ce4ccb90a110f45bb9b4f3ccd6 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 22:43:09 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 22:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUHtU-0006Bb-1I; Thu, 30 Apr 2020 22:43:00 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=42Rk=6O=gmail.com=christopher.w.clark@srs-us1.protection.inumbo.net>)
 id 1jUHtT-0006BW-0A
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 22:42:59 +0000
X-Inumbo-ID: f04a3da0-8b33-11ea-9887-bc764e2007e4
Received: from mail-oi1-x244.google.com (unknown [2607:f8b0:4864:20::244])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id f04a3da0-8b33-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 22:42:58 +0000 (UTC)
Received: by mail-oi1-x244.google.com with SMTP id i13so1173739oie.9
 for <xen-devel@lists.xenproject.org>; Thu, 30 Apr 2020 15:42:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=MVvggUdC+lfONDYt34ZfGtwVCXwzsEurzu/RkkC0IzM=;
 b=l7te+lWwnHpQEpzauV9lpzSvgRZpYdjWGPFeqVKIyupuzpJ2rXdzF+c6TN5h9LAWhv
 SKO28ik/sxG4CMrO6Zuxz/TJ7raDHd9Czy9nFipNZtdKxZfni5kRuiz11NKs0hFZL1b+
 lgqDAXZmSjptGcE9wEIGz0svrVgOUSvzIYuxQHVgvsjUTo090E5TF1Hyf25Fj/ebABjB
 4vAgMv4/Xdh9IxRY+euiLn7LAU9v+SPyxxVWP0fJZD7vEmzgcOgm8LEWuStWmMG6S8IX
 qGwBjOJhHoFk1jdeDdKmzH4WKSUYUwG3tV7JUVz7IpqlMlz2TRNsGOmpF8v8sdIfBm8q
 FYfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=MVvggUdC+lfONDYt34ZfGtwVCXwzsEurzu/RkkC0IzM=;
 b=JbWFqb3uXgRZONhG6zUkmVanUOfI7chGXprZUv3+NaVPvL9/ipHFfAR2bjf+7pTEnD
 yLqFATMDJKO9FrsikI7Zi9uUqvo4g+d2WMri15zhydZRWTZYg7Q07K0resfBepA42dY9
 eLyZvf2aez/eQvgWNSIAvChEwfo0N9ikfPVAafIBv0mfN3Hcu5b1UKzUFnJpdQShfu32
 cTM6NYotIxO4obPjuxMtTD00h+RJu/keQwAdyzIxj0mJ0ON2VOnMkb2CD4euVDE0C28o
 ejVXDTHLlgEhmnHW1NbBkIS5g1qAZ5nSjqK0GQHgcqpAeFqUD4qa2mWyOa+5imX6d4Ib
 +rvg==
X-Gm-Message-State: AGi0PuYLVr2ZuEsYZoH11xeab/WpLy1OmIOFtwLTWXLk1WVbhnRsV42G
 umBqF2wuqA6/fB1AN9qJZiBPfpcl0Sb0fovXLec=
X-Google-Smtp-Source: APiQypI5EyFu44yb+E/KEIAdgA9ftS6JPXP3EEAIaa18e9Jc/xMlZefsjgcuV95f7dfGCP5VRtYPwsbGdoShF63lXig=
X-Received: by 2002:aca:f4d0:: with SMTP id s199mr996204oih.161.1588286577507; 
 Thu, 30 Apr 2020 15:42:57 -0700 (PDT)
MIME-Version: 1.0
References: <20200429225108.GA54201@bobbye-pc> <20200430222717.GA6364@mail-itl>
In-Reply-To: <20200430222717.GA6364@mail-itl>
From: Christopher Clark <christopher.w.clark@gmail.com>
Date: Thu, 30 Apr 2020 15:42:46 -0700
Message-ID: <CACMJ4GY+qb3qGFYNwpH9acL3HSR7rr6qeqtsSToL-BWHEghLnQ@mail.gmail.com>
Subject: Re: [RFC] UEFI Secure Boot on Xen Hosts
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, 
 Bobby Eshleman <bobbyeshleman@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Cc: michal.zygowski@3mdeb.com, Daniel Smith <dpsmith@apertussolutions.com>,
 daniel.kiper@oracle.com, krystian.hebel@3mdeb.com,
 xen-devel <xen-devel@lists.xenproject.org>,
 Olivier Lambert <olivier.lambert@vates.fr>, piotr.krol@3mdeb.com
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Apr 30, 2020 at 3:28 PM Marek Marczykowski-G=C3=B3recki
<marmarek@invisiblethingslab.com> wrote:
>
> On Wed, Apr 29, 2020 at 05:51:08PM -0500, Bobby Eshleman wrote:
> > # Option #3: Lean on Grub2's LoadFile2() Verification
> >
> > Grub2 will provide a LoadFile2() method to subsequent programs that sup=
ports
> > signature verification of arbitrary files.  Linux is moving in the
> > direction of using LoadFile2() for loading the initrd [2], and Grub2 wi=
ll
> > support verifying the signatures of files loaded via LoadFile2().
>
> This description gives me flashbacks to how xen.efi loads dom0
> kernel+initramfs (Loaded Image Protocol). Practical issues encountered:
>
> 1. It works only when xen.efi is loaded via appropriate EFI boot
> service directly. If xen.efi is loaded by a filesystem driver in
> grub/other bootloader, it can't load dom0 kernel+initramfs.
>
> 2. Given variety of UEFI implementations and boot medias, it was almost
> impossible to force bootloader to use the right file loading method
> (cases like the same file accessible both via UEFI fs0: and via grub's
> filesystem driver). Which means loading xen.efi via a bootloader (as
> opposed to directly from UEFI) was hit or miss (mostly miss).
>
> 3. To avoid the above issue, one was forced to load xen.efi directly
> from EFI. This gave up any possibility to manipulate xen cmdline, or
> even choose system to boot in case of some EFI implementations.
>
> 4. Even if one is lucky to boot xen.efi via grub2-efi, then still only
> xen options could be modified. But not those for dom0.
>
> 5. It was impossible to load xen/kernel/initrd using fancy grub/ipxe
> features like HTTP.
>
> In practice the above points mean:
>
> * To get a usable product, one is forced to enable all kind of
>   workarounds (not only related to EFI) _in default configuration_,
>   because otherwise there is very little chance to enable them only when
>   needed.
>
> * If something goes wrong, in most cases you need to boot from
>   alternative media (to edit xen.cfg, or efi variables). If you happen
>   to forget your rescue usb stick, you are out of luck.
>
> So, please, can someone confirm the LoadFile2() approach wouldn't have
> any of the above issues?
>
> > This is set
> > for release in GRUB 2.06 sometime in the latter half of 2020.
> >
> > In Xen, this approach could be used for loading dom0 as well, offering =
a very
> > simple verified load interface.
> >
> > Currently the initrd argument passed from Linux to LoadFile2() is a ven=
dor
> > media device path GUID [3].
> >
> > Changes to Xen:
> > - Xen would need to pass these device paths to Grub
> > - Xen would be changed to load dom0 with the LoadFile2() interface via =
boot services
> >
> > Changes to Grub:
> > - Xen dom0 kernel/initrd device paths would need to be introduced to Gr=
ub
> >
> > Potential Issues:
> > - How will Xen handle more boot modules than just a dom0 and dom0
> >   initrd?
> > - Would each boot module need a unique vendor guid?
>
> Both above points applies for example to loading dom0
> kernel+initrd+microcode update+xsm.

I agree with this point.

>
> > - Would this interfere with the DomB proposal?

Yes, it looks like it would.

> > I suspect not because
> > the DomB proposal suggests launching DomUs from an already booted
> > DomB, at which point other means could be used.
>
> domB probably not, but what about dom0less, where multiple domains are
> loaded by Xen itself? I know dom0less currently is ARM only (not sure
> how that relates to EFI, if at all), but I think in general it would be
> good to plan for supporting more modules.

I'd better clarify this about DomB since it is not quite accurate for
the current work in progress: We're aiming to implement it as a
dom0less mode for x86, where the initial domains are loaded by Xen
itself from the modules provided by the bootloader. A single domain,
(DomB), will then run first, alone, with the opportunity to measure or
validate and then unpause the other initial domains if it chooses to
do so.
So that will mean that support for more modules will be needed.

thanks

Christopher


From xen-devel-bounces@lists.xenproject.org Thu Apr 30 23:10:58 2020
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Apr 2020 23:10:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1jUIKO-0000Ay-VH; Thu, 30 Apr 2020 23:10:48 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DLrL=6O=xenproject.org=osstest-admin@srs-us1.protection.inumbo.net>)
 id 1jUIKO-0000Ai-2m
 for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 23:10:48 +0000
X-Inumbo-ID: cf960ee6-8b37-11ea-9887-bc764e2007e4
Received: from mail.xenproject.org (unknown [104.130.215.37])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id cf960ee6-8b37-11ea-9887-bc764e2007e4;
 Thu, 30 Apr 2020 23:10:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
 Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=C+a0WC1q5DVfDqcPVgm4ZZkJxm2gg7RAHh+MwIZ5sGA=; b=0fgYnthxpL56gWiTXvAIo1cyL
 gsY1nKZ3+09F2pOJuLraphsYPfVGM/ZCSgiBANInpUTB65rKF+FB0NAUjpRxnmiggSDaBZke0y8Op
 W8CoGxTVz0j86wRmOF9sNnyAkSrATHRCYSAZOybEJY2zvVaQhcNdjOfmE3gtGaiCRJfF8=;
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUIKG-00077t-S7; Thu, 30 Apr 2020 23:10:40 +0000
Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.89)
 (envelope-from <osstest-admin@xenproject.org>)
 id 1jUIKG-0005UP-Is; Thu, 30 Apr 2020 23:10:40 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.89) (envelope-from <osstest-admin@xenproject.org>)
 id 1jUIKG-0004s4-IF; Thu, 30 Apr 2020 23:10:40 +0000
To: xen-devel@lists.xenproject.org,
    osstest-admin@xenproject.org
Message-ID: <osstest-149889-mainreport@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 149889: tolerable FAIL - PUSHED
X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable
 xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
 xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
 xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This: xen=8065e1b41688592778de76c731c62f34e71f3129
X-Osstest-Versions-That: xen=f9bf746258eb53011f863571c7073037202b6743
From: osstest service owner <osstest-admin@xenproject.org>
Date: Thu, 30 Apr 2020 23:10:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

flight 149889 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149889/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds     16 guest-localmigrate       fail REGR. vs. 149881

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 149881
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop            fail like 149881
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop             fail like 149881
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop            fail like 149881
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 149881
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 149881
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop             fail like 149881
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop            fail like 149881
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop             fail like 149881
 test-amd64-i386-xl-pvshim    12 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-check    fail   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-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  8065e1b41688592778de76c731c62f34e71f3129
baseline version:
 xen                  f9bf746258eb53011f863571c7073037202b6743

Last test of basis   149881  2020-04-29 16:37:39 Z    1 days
Testing same since   149889  2020-04-30 09:52:27 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-arm64-arm64-xl-seattle                                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f9bf746258..8065e1b416  8065e1b41688592778de76c731c62f34e71f3129 -> master